软件工程和设计原则

类与类的关系

is - a 是一个

has - a 有一个

use - a 用一个

(6种关系)

1.什么是软件工程？

2.软件工程又是怎么来的呢？

在20世纪60年代，计算机刚刚投入实际使用时，软件大多是为了特定的需求(应用)，而进行设计，汇编语言进行编码，很少使用系统化的方式进行开发，个人作坊式的开发(个人设计、个人使用、个人操作--自给自足式开发)

随着时代的发展，人们对软件的功能需求越来越庞大，软件的功能、规模及复杂程度与日俱增，会导致开发者对软件的控制难度急剧上升。

后果：软件的可靠性下降

开发效率降低

维护极为困难等

--- 称为“软件危机”

出现软件危机后，原本个人设计、个人使用、个人操作--自给自足式开发，不能再满足日益增长的需要，因此需要迫切的改变软件的生产方式，提升软件生产效率。因此，软件工程被提出

什么是软件工程呢？

采用工程化的方法来开发和维护软件，把工程管理技术和技术方法结合起来，以经济的开发出高质量的软件，并有效的去维护他，将开发过程系统化、规范化，可定量化的过程，就是软件工程

对于工程的概念，maven工程(项目)，它的项目(工程)结构

软件生命周期(开发阶段)，在每个开发阶段都要产生健全的、符合工程规范的文档，因此，软件产品不仅仅是程序，而是这些文档的总和。

在不同的生命周期阶段，需要提供那些文档？

1.可行性分析：可行性分析报告

2.需求分析：软件需求规格说明书--明白“做什么”

3.系统设计：概要设计、详细设计、数据库设计说明--明白“怎么做”

4.编码：通过单元测试的源代码

5.测试：软件测试报告

6.维护：软件问题报告、软件变动记录、软件维护记录

大部分的错误，都是发生在编码阶段之前，错误发现得越晚，那么改正该错误所需付出的代价也就越高。需求的修改--开发人员最痛恨的一件事，其他各个阶段的文档和代码也要随之修改，以保证项目的一致性。

为了更好的使软件生命周期的任务可以有序的进行，用一定的软件工程模型对各阶段的各项任务予以规划和约束。

根据需要，以及各种模型之间的特点，选用不同的模型。

瀑布模型、螺旋模型、增量模型和喷泉模型等

瀑布模型：反映软件生命周期给个阶段的明确任务，自上而下，逐级过渡的结构模式，项目开发阶段从一个阶段“流向“另一个阶段，因此就把这种结构模式叫做瀑布模式;

特点：

阶段间，都是有顺序性和依赖性(必须要等到前一个阶段的工作完成之后，才能顺序开启后一阶段的工作)

质量的保证(每个阶段都必须完成后(文档交付)，才能进行下一阶段，每个阶段结束前，都会对完成的文档进行评审，以便及早的发现问题，改正错误)

缺点：过于理想化(人在工作过程中，不可能不犯错，当在后面阶段发现前面阶段的错误时，再回到前面阶段，逐级修改错误)

喷泉模型：以用户需求为动力，以对象为驱动的模型，主要就是用来描述面向对象的软件开发过程。

为什么叫做喷泉模型呢？该模型认为，软件开发过程自下而上的，周期的各个阶段是相互重叠和多次反复对的，就像水碰上去又落下来一样，类似一个喷泉，因此被叫做喷泉模型。

特点：各个阶段间没有明确的界限，所以同时进行多个阶段的任务工作，提高软件开发效率，节约开发时间。

缺点：

开发过程中，就需要大量的开发人员(人力成本就很大)，

面临可能随时加入各种信息、需求和资料的情况

UML：统一建模语言，是一种用于软件系统设计和架构建模的一种可视化建模语言。

UML图有很多种，用例图、类图、活动图。至少掌握使用最频繁的一种--类图。

什么事类图？显示系统中类、接口以及它们之间的静态结构和关系的一种静态模型，其中最基本的元素是类和接口。

目标：学会类图的绘画

1. 类图表示类：类图是一个矩形，并且划分了三层，第一层显示类的名称，第二层显示类的特性--属性，第三层显示类的行为--方法

   特例：抽象类和抽象方法以斜体表示

   访问修饰符 -：私有（private）

   +: 共有(public)

   #:受保护的(protected)

   ~:默认

   练习：三个类

   Person；name；intro(name)

   Student；age，gender；study() 继承与Person

   Teacher；age，lesson；teach() 继承与Person

   以前用的是EA，EA没有Mac，现在用亿图图示

2. 类图表示接口：用一个双层矩形，表示接口，第一层，头部<<interface>>，然后在其下方书写接口名称；第二层，接口方法

   练习：两个接口

   Swimming(游泳)；swim()--游泳

   Run(跑步)；longRun()--长跑;sprint()--短跑；

3. 类图表示包：两个大小不一的矩形，上面的一个空白小矩形，下面是大矩形，大矩形中书写包名

用类图表示类与类的关系(6种)

like - a(实现关系)：接口及其实现类之间的关系

使用虚线+空心三角形表示，由实现类去指向接口

is - a 是一个(泛化关系)：对象与对象之间的继承关系

使用实线+空心三角形表示，由子类指向父类

use - a 用一个(依赖关系)：如果A指向B，则说明A中使用了B，使用方式包括，A类中有B类的实例化对象局部变量；A类中有方法把B类实例化对象当做了参数

使用虚线+箭头表示，由使用者指向被使用者

关联关系：A类中有B类的成员变量

使用实线+箭头，由拥有者指向被拥有者(一个类(拥有者)“知道”另一类(被拥有者)时)

鸭子“知道/了解”溪水水温 (春江水暖鸭先知)

has - a 有一个(聚合)：一个类是另一个类的属性，但是和关联关系不同，这两个类之间有逻辑关系。

使用空白菱形+实线+箭头表示，由整体指向部分。如果A(部门)指向B(员工)，则说明A类中有B类变量且包含逻辑关系，A(部门)为整体，B(员工)为部分。A类(部门)由B类(员工)构成，同时B类(员工)不存在，A类(部门)也可以单独存在

组合关系：指一个类是另一个类的属性。是整体中不可分割的一部分，属于强聚合

使用实心菱形+实线+箭头表示，由整体指向部分。如果A指向B，说明A类中有B类对象，和关联关系不同，A和B有逻辑关系，A是整体，B是部分。A类由B类构成。但是组合与聚合不同，如果B类不存在，则A类无法单独存在

设计原则

1.单一职责原则：对一个类而言，应当只有一个引起它变化的原因，永远不要让一个类存在多个改变的理由。因此，一个类应该只做一个职责相关的业务，不要把过多的职责放在同一个类中完成。

2.开闭原则：一个软件实体(类、方法、模块)，应该对扩展开放，对修改关闭。软件需要变化，尽量通过扩展软件实体的方式来完成，而不是通过修改原有代码来完成。开闭原则是设计原则中的核心原则。

3.里式替换原则：在一个软件系统中，子类能够完全替换父类出现的地方，并且进过替换后，不会改变原有的行为

4.依赖倒置原则：高层模块不应该依赖底层模块，二者都依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象

-- 功能实现不能依赖于实体的类，应该依赖于抽象的接口，通过实现接口的方式来实现功能

5.聚合/组合原则:尽可能使用聚合/组合的方式，而不是使用继承来达到代码的复用

6.接口隔离原则：使用专门的接口比用统一接口好，便于项目的组织和分工。不要让开发者面对用不到的方法。

7.迪米特法则：一个对象应该对其他对象保持最少的了解，要很好的封装类，仅向外部暴露你提供的服务，内部的细节不需要让外界知道。