（大二下）软件建模与设计复习笔记

软件建模与设计

一、面向对象和UML

控制软件复杂性的基本方法：分解、抽象、模块化、封装

1. 面向对象

1.1 定义

面向对象=对象+类+继承+通信

1.2 特性

面向对象的特性：标识、分类、继承、多态

• 标识

​ 识别系统中的对象（Object）

• 分类

​ 拥有相同数据结构（属性）和行为（操作）的对象被组成一个类（Class）

• 继承

​ 在用层次关系组织的类中共享属性（attribute）和操作（operation）

• 多态

​ 对于不同的类来说，相同的操作会产生不同的动作

1.3 优点

开发的系统比较稳定、易于理解、可靠性好、适应性好（适应需求的变化，利于构建大型系统）

• 适应性（以java接口为例）

​ 原本：每多一种类型就要多写一个方法

​ 使用接口：定义一个接口，让Teacher和School去实现它的detail方法

• 可靠性（以包为例）

​ 把要一起使用的方法放在同一个包里，使用时不会少用方法，这些方法也不会别乱使用

1.4 开发模型

瀑布模型、迭代模型

2. UML

UML的特点：统一的标准、面向对象、可视化、独立于过程、概念明确

二、类建模

1. 对象和类的UML表示法

2. 链接和关联的UML表示法

3. 关联

3.1关联的多重性

一对一、一对多、多对多

3.2 关联端名

3.3 自关联

类与自身关联，关联两端不同角色

public class Person{
    public Person[] parent;
    public Person[] child;
}

3.4 关联类

关联关系之间衍生出的类。多对多必须使用。

3.5 限定关联

加一个限定符降低多重性。本

来一个bank有很多个account，加了个id后要么有要么没有。

`

3.6 泛化和继承

父类和子类。箭头指向父类

二、高级类建模

1. 枚举

不要用泛化

enum Suit {  
  spades, clubs, hearts, diamonds  
}

2. 属性多重性

属性的实例可能取值个数。

3. 可见性

公用可见性（+）

私有可见性（-）

保护可见性（#）

包可见性（~）

4. N元关联

无法被表示，把关联提升为类。

5. 聚合

一种强类型的关联，一个聚集对象由多个部件构成，具有传递性。

整体与部分的生命周期可以不一样。circle不在了，style可能还在

6. 组合

生命周期相同，是特殊的聚合。如果circle不在了，point也不在了

7. 关联，聚合，组合的区别

关联，聚合，组合只是在语义上的区别，在语法实现上没有太大的区别

8. 抽象类及其UML表示法

斜体字标识抽象类和抽象方法

9. 多重继承解决方案

产生二义性。不知道用哪一个方法。

使用委派（组合），用多个部件替换多个继承

将LandOperation和WaterOperation作为Vehicle的抽象方法

9.1 委派

职责分散，将一个操作重定向给另一个对象（班长-> 学习委员、宣传委员……）

在类里定义抽象对象，由抽象类去自己实现。（组合+继承）

何时使用：当需要使用方法而不需要修改方法时。

9.2 继承和委派

将Employee分出一部分职责分给另一个类，自己只负责原来一部分功能，本质还是委派（组合+继承）

10. 依赖和关联的区别

依赖是偶然性的、临时性的、非常弱的（代码中是使用关系）

关联是非偶然性、长期性的、比较强的（代码中被关联类以属性存在于关联类中）

11. 类图的画法

三、状态建模

1. 状态模型的作用

描述对象响应外部激励而发生的操作序列

2. 事件、状态、迁移

2.1 事件

某个时刻发生的事件

外部事件（按下按钮），内部事件（堆栈溢出）

事件种类：调用事件、信号事件、变化事件、时间事件

2.2 状态

所有对象都具有状态

会发生变化

2.3 迁移

从一个状态到另一个状态的瞬时变化

组成：源状态、事件触发器、警戒条件、效应、目标状态

3. 状态图及其画法

3.1 嵌套状态

子状态

3.2 状态的并发

类的聚合关系，到状态图中就有并发

4. 类模型和状态模型的关系

状态模型详细描述了类模型中对象所允许的变化序列。

状态图描述了某个给定类的对象的全部或部分行为。

四、交互建模

1. 什么是交互模型

交互模型描述对象要如何交互才能产生有用的结果

交互模型描述多个对象的整体行为

2. 交互模型的类型与作用

用例模型，顺序模型，活动模型

3. 用例模型

3.1 用例、参与者

用例：是系统、子系统和外部参与者交互的动作序列说明，包括可选动作序列和异常动作序列

参与者：在系统外，是与系统进行交互的外部实体（用户角色、其他系统）

3.2 用例描述

采用自然语言描述参与者与系统进行交互时双方的行为，不追求形式化的语言表达

3.3 用例图及画法

3.4 用例的三种关系

包含、扩展、泛化

• 包含（include）

• 扩展（extend）

• 泛化（generalization）

  

3.5 用例关系准则

不要过度使用用例关系。

不要将用例关系用到编程中。

4. 顺序模型

包含两种模型：场景和顺序图

4.1 场景

系统在某个特定的执行期内所发生的一系列事件。

可以包含系统中所有事件或只包括与某些对象有密切联系或由这些对象产生的事件。

场景可表示为文本描述列表。

4.2 顺序图及画法

是显示对象之间交互的图，这些对象是按时间顺序排列的。

顺序图显示了参与交互的对象及对象之间消息交互的顺序。

顺序图强调消息的时间顺序。

4.3 建立顺序模型的准则

至少为每个用例编写一种场景。

把场景抽象成顺序图。

划分复杂的交互。

为每种错误条件绘制一张顺序图。

5. 活动模型

5.1 活动、动作状态、活动状态、泳道

• 活动

表示某流程中的任务的执行，可以表示某算法过程中语句的执行。

• 动作状态

是原子的，不能被分解，没有内部转移，没有内部活动。

动作状态的工作所占用的时间是可忽略的。

可被视作活动状态的特例

• 活动状态

不是原子的，可分解。

活动状态的工作的完成需要一定的时间。

• 泳道

是活动图中的区域划分

根据每个活动的职责对所有活动进行划分，每个泳道代表一个责任区

一个泳道可能由一个或多个类来实现

5.2 活动图及画法

带泳道的活动图

5.3 活动图与顺序图的区别

顺序图强调的是从对象到对象之间的控制流。

活动图强调的是从步骤（活动）到步骤的控制流。

五、软件系统分析

1. 软件开发阶段

1. 系统构思

   构思并描述临时性需求

2. 分析

   通过构造模型深入理解需求

   a) 领域分析

   b)应用分析

3. 系统设计

   设计系统架构

4. 类设计

   设置真实模型及算法

5. 实现

6. 测试

7. 培训

8. 部署

9. 维护

2. 软件开发生命周期

2.1 瀑布开发

适用于需求非常明确的应用。

完全的瀑布式开发极少。

通常在高版本号的软件开发中才可能出现。

2.2 迭代开发

多数软件开发的首选方式。

灵活，及时响应变化。

开发风险小。

3. 问题陈述

3.1 目标

描述待构建的系统的目标

提出构建系统的总体方案

3.2 注意

区分：需求、设计和实现。

描述要做什么，而不是怎么做。

该阶段的概念文档可包含一个实现示例。

问题陈述本身可能不完整，甚至错误。

4. 系统分析

4.1 模型描述对象的三个方面

1. 类模型——描述对象的静态结构

2. 交互模型——描述对象之间的交互

3. 状态模型——描述对象的生存期

4.2 两个阶段

1. 领域分析：分析问题的本质

2. 应用分析：从应用的角度分析

5. 领域分析

构造领域类模型步骤：

1. 寻找类

2. 准备数据字典

3. 寻找关联

4. 寻找对象和链接的属性

5. 使用继承组织和简化类

6. 验证可能查询的访问路径

7. 迭代并细化模型

8. 重新考虑类的抽象层次

9. 把类组织成包

六、应用分析

补充类模型和状态模型。

1. 应用的交互模型

1. 确定系统边界

2. 构建用例模型

​ - 识别参与者

​ - 识别用例

3. 构建场景和顺序图

4. 构建复杂用例的活动图

5. 检查用例和类模型

2. 应用的类模型

界定了应用程序本身，面向计算机

步骤：

1. 用户界面
2. 定义边界类（负责资源通信，还有实体类，控制类）
3. 确定控制器 Controller
4. 检查交互模型（是否满足交互行为）

3. 应用状态模型

1. 用多个状态来确定应用类。
2. 使用交互模型来寻找类的事件。
3. 用状态图为每个类组织许可的事件序列。
4. 检查状态图，确保公共事件的匹配。
5. 用类和交互模型检查状态图，确保一致。

七、软件系统设计

确定系统整体结构和风格，设计解决方法

1. 系统设计（总体设计）

1. 估算系统性能

只需要做大致的估算

目的是确定软件系统是否可行

2 制定复用计划

可复用的事物：类库，模型，框架，模式

1.3 划分子系统

水平分层，垂直分区

1.4 确定并发性

判断并发：不交互的情况下，可以同一时间发生。

1.5 分配子系统硬件

1.6 管理数据存储

1.7 处理全局资源

1.8 选择软件控制策略

1.9 处理边界条件

解决系统以下问题：初始化，终止，失效

1.10 权衡优先级

1.11 架构风格

常见架构风格：

1. 批处理转换，不与外部发生交互，编译器

2. 连续性转换，依赖输入更新来更新输出，是一个增量计算，GUI的放大。

3. 交互式界面，各种查询系统

4. 动态仿真，分子运动建模。

5. 实时系统，时间要求严格，通信设备。

6. 事务管理器，订票系统。

2. 详细设计（类设计）

把分析阶段得到的类代入设计阶段，在类设计阶段细化对其进行细化。

2.1 填补需求间的鸿沟

功能和可用资源

2.2 用操作实现用例

2.3 定义操作的算法

成本最低，合适的数据结构

2.4 向下递归

按功能、机制递归

按功能、机制分层（MVC）

2.5 重构模型

2.6 优化数据访问路径

2.7 实现具体的行为

2.8 调整类结构

2.9 组织类和关联

3. 抽象类和接口

4. 理解面向对象的基本设计原则

4.1 开闭原则（最重要的原则）

在扩展性方面开发，在更改性方面封闭

使用接口、抽象机制、多态

4.2 Liskov替换原则

子类必须能够替换掉它们的基（父）类型，否则继承关系就是不正确的。

4.3 依赖倒置原则

依赖关系应尽量依赖接口（或抽象类），而不是依赖具体类。即依赖抽象而不是具体。

4.4 接口分离原则

使用多个专门的接口比使用单一的通用接口要好

将一个大接口分成几个小接口

八、软件系统实现

1. 实现建模

主要步骤：微调类、微调泛化关系、实现关联、准备好测试

1.1 微调类

拆分、合并类

拆分、合并属性

1.2 微调泛化关系

增加、删除

1.3 实现关联

单向关联、双向关联

用关联类实现关联（最常用）

1.4 准备好测试

单元测试、集成测试、系统测试

2. 数据库建模

主要步骤：实现类、实现关联、实现泛化、实线标识

2.1 实现类

类映射表，属性映射列

可以增加列，表示对象标识符和关联

2.2 实现关联

多对多——用一张表来实现

一对多——在多方添加外键

一对一——任意方添加外键

2.3 实现泛化

每个父类和子类都有一张表

每张表有含义相同的主键

2.4 实现标识

对象标识：每个表添加一个ID作为主键（推荐）

本设计原则

4.1 开闭原则（最重要的原则）

在扩展性方面开发，在更改性方面封闭

使用接口、抽象机制、多态

4.2 Liskov替换原则

子类必须能够替换掉它们的基（父）类型，否则继承关系就是不正确的。

4.3 依赖倒置原则

依赖关系应尽量依赖接口（或抽象类），而不是依赖具体类。即依赖抽象而不是具体。

4.4 接口分离原则

使用多个专门的接口比使用单一的通用接口要好

将一个大接口分成几个小接口

八、软件系统实现

1. 实现建模

主要步骤：微调类、微调泛化关系、实现关联、准备好测试

1.1 微调类

拆分、合并类

拆分、合并属性

1.2 微调泛化关系

增加、删除

1.3 实现关联

单向关联、双向关联

用关联类实现关联（最常用）

1.4 准备好测试

单元测试、集成测试、系统测试

2. 数据库建模

主要步骤：实现类、实现关联、实现泛化、实线标识

2.1 实现类

类映射表，属性映射列

可以增加列，表示对象标识符和关联

2.2 实现关联

多对多——用一张表来实现

一对多——在多方添加外键

一对一——任意方添加外键

2.3 实现泛化

每个父类和子类都有一张表

每张表有含义相同的主键

2.4 实现标识

对象标识：每个表添加一个ID作为主键（推荐）

值的标识：使用值得组合