软件工程04：面向对象分析

1. UML

发展阶段：各自为政 -> 统一阶段 -> 标准化阶段 -> 工业化应用
定义：是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示。

1.1. 特点

它不是一种可视化的程序设计语言，而是一种可视化的建模语言；
它不是工具或知识库的规格说明，而是一种建模语言规格说明，是一种表示的标准；
它不是过程，也不是方法，但允许任何一种过程和方法使用它。

1.2. 基本结构

(1). 基本构造块（事物、关系、图）
(2). 语义规则
(3). 通用机制
(4). 事物
(5). 关系（依赖、关系、继承、实现）

1.3. UML 4+1视图

定义：UML用模型来描述系统的结构（静态特征）以及行为（动态特征）。从不同的视角为系统的架构建模，形成系统的不同视图（view），称为4+1视图。

1.3.1. UML 4+1视图的作用

用例视图：强调从用户的角度看到的或需要的系统功能；
逻辑视图：展现系统的静态或结构组成及特征；
进程视图：描述设计的并发和同步等特性，关注系统非功能性需求；
构件视图：关注软件代码的静态组织与管理；
部署视图：描述硬件的拓扑结构以及软件和硬件的映射问题，关注系统非功能性需求（性能、可靠性等）；

1.3.2. UML的9个基本图

用例图、类图、对象图、顺序图、协作图、状态图、活动图、构件图、部署图。

1.3.3. UML视图与图的关系

用例视图：使用用例图和活动图；
逻辑视图：使用类图、对象图，顺序图/协作图；
进程视图：使用状态图和活动图；
构件视图：使用构件图；
部署视图：使用部署图。

2. 面向对象的需求分析建模

包含两个模型：领域模型、用例模型。
领域模型表示了需求分析阶段当前系统逻辑模型的静态结构及业务流程；
用例模型是目标系统的逻辑模型，定义了“目标系统”做什么的需求。

2.1. 领域模型

定义：针对某一特定领域内概念类或者对象的抽象可视化表示。
主要用途：概括地描述业务背景及重要的业务流程，并通过UML的类图和活动图进行展示，帮助软件开发人员在短时间内了解业务。
业务背景：可由需求定义或者用例说明中具有代表业务概念或者业务对象的词汇获得，这些词汇可统称为概念类；并通过能够代表关系的词汇建立概念类之间的关系，表示成能够代表业务知识结构的类图；
业务流程：一般由角色及其执行的活动（活动及任务节点）构成，活动的输出一般有数据对象和传给另一个活动的消息组成，建议使用UML的活动图进行描述。

2.1.1. 领域模型与软件模型的区别

(1). 领域模型描述的内容与软件对象无关，是纯粹对现实客观世界的抽象描述。
(2). 内在的联系：面向对象的一种核心思想是利用领域模型中概念类的名称、属性等信息启发式地进行系统领域层类的设计，运用这种方法可以大大降低需求和设计之间的跳转差异。

2.1.2. 识别概念类

通过对用例描述中的名词或名词短语寻找和识别概念类。
注意：名词可以是概念类，也可能是概念类中表示特征的属性（属性一般可赋值，概念类不行），举棋不定时归为概念类。

2.1.3. 创建领域模型的步骤

(1). 找出当前需求中的候选概念类；
(2). 在领域模型中描述这些概念类。用问题域中的词汇对概念类进行命名，将与当前需求无关的概念类排除在外；
(3). 在概念类之间添加必要的关联来记录那些需要保存记忆的关系，概念之间的关系用关联、继承、组合/聚合来表示；
(4). 在概念类中添加用来实现需求的必要属性。

2.1.4. 关联

分为两种：需要知道（需要将概念之间的关系信息保持一段时间，着重考虑）和只需理解型关联。

2.1.5. UML类图

用于描述类以及类之间的关系。

类包含三个部分：类名、属性、操作。

2.1.6. 类的关系

2.1.6.1. 依赖

类A 把 类B 的实例作为方法里的参数使用；
类A 的某个方法里使用了类B 的实例作为局部变量；
类A 调用了 类B的静态方法。

2.1.6.2. 关联

一个类可以将另一个类的某些属性或者类对象的整体作为其属性时，存在关联关系。

2.1.6.3. 聚合

类A（整体类）拥有另一个类B（部分类），同时其他的类C也可以分享类B。

2.1.6.4. 组合

类A（整体类）完全拥有另一个类B（部分类），且其他任何类都不能分享类B。

2.1.6.5. 继承

类A是类B的父类。

2.1.6.6. 关联类

2.1.6.7. 综合举例

2.2. 用例模型

四部分组成：用例图、用例说明、系统顺序图、操作契约。

2.2.1. 用例图

角色（Actor）：称为角色或者参与者，表示使用系统的对象，代表角色的不一定是人，也可以是组织、系统或设备；
用例（Use case）：描述角色如何使用系统功能实现需求目标的一组成功场景和一系列失败场景的集合（一系列动作）；
关联（Association）：表示角色与用例之间的关系，以及用例和子用例之间的关系；

2.2.2. 基本用例和子用例

基本用例：与角色直接相关的用例，表示系统的功能需求，必须执行；
子用例：通过场景描述分析归纳出的用例，也表示了系统的功能，但这些用例与角色无直接关系，而与基本用例存在关联关系，可能执行；
包含子用例，扩展子用例。

2.2.3. 用例说明

基于已经找到的用例和子用例，并参考之前的需求定义以及场景描述的内容，将用例交互的成功场景和失败场景以标准的格式归纳描述。

2.2.4. 系统顺序图

在用例描述的基础上需要进一步确定角色与系统之间的交互信息，并以可编程的方式将其命名；
一般只需要三个UML的符号元素：角色、代表软件系统的对象、交互信息。

2.2.5. 操作契约

参考领域模型中业务对象接收到相同的系统事件后，执行必须的业务处理时各业务对象的状态以及系统操作执行的结果，以便软件设计时进行参考。