第二部分 面向对象分析
2.1 面向对象分析(OOA)的定义？
OOA——面向对象的分析，就是运用面向对象方法进行系统分析，对问题域(问题所涉及的范围)和系统责任(所开发的系统应具备的职能)进行分析与理解，找出描述问题及系统责任所需要对象，定义对象的属性、操作以及它们之间的关系。
2.2 面向对象分析(OOA)的优点？
- 加强了了对问题域和系统责任的理解；
- 改进与分析有关的各类人员之间的交流；
- 对需求的变化具有较强的适应性；
- 支持软件复用。
2.3 面向对象工具——UML(Unified Modeling Language)统一建模语言
UML是对软件密集型系统中的制品(模型、源代码、测试用例等)进行可视化、详述、构造和文档化的语言。
（1）UML特点
- 统一的标准
- 面向对象
- 可视化、表示能力强大
- 独立于过程
- 概念明确，建模表示法简洁，图形结构清晰，容易掌握和使用
（2）UML的构成
UML中的3类主要元素是基本构造块、规则、公共机制
（3）UML中的视图
UML中的视图包括用例视图、逻辑视图、实现视图、进程视图、部署视图，被称为“4+1”视图
- 用例视图：用于表达系统的功能性需求
- 逻辑视图：用于表示系统的概念设计和子系统结构等
- 实现视图：用于说明代码的结构
- 进程视图：用于说明系统中并发执行和同步的情况
- 部署视图：用于定义硬件结点的物理结构
2.4 面向对象分析(OOA)模型及其规约
OOA模型是指运用面向对象的分析方法建立的系统模型，包括基本模型、需求模型和辅助模型三部分。
基本模型：基本模型以直观的方式表达了最重要的系统结构信息
需求模型：需求模型用于定义用户需求
辅助模型：辅助模型提供几种对基本模型进行组织或者加强理解的辅助图形
模型规约：对模型进行详细的描述
2.4.1 基本模型——类图
构成类图的主要成分是类、属性、操作、一般-特殊结构、整体-部分结构、关联和消息。这些成分所表达的模型信息可以从下面三个层次来看待：
- 对象层——给出系统中所有反映问题域与系统责任的对象，即描述系统中应设立哪些类的对象
- 特征层——给出每一个类(及其所代表的对象)的内部特征，即给出每个类的属性与操作，描述对象的内部构成情况
- 关系层——给出各个类(及其所代表的对象)彼此之间的关系，包括：
（1）继承关系(即泛化关系)——通过一般-特殊结构表示
泛化关系"a kind of"，类与类之间的关系即继承关系
（2）聚集与组合关系——通过整体-部分结构表示
聚集关系"has-a"，组合关系"contains-a"：聚集关系表示事物的整体-部分关系较弱的情况，组合关系表示事物的整体-部分关系较强的情况
区别：组合关系中的整体和部分具有同样的生命周期。在聚集关系中，代表部分事物的对象可以属于多个聚集对象，可以为多个聚集对象所共享，而且可以随时改变它所从属的聚集对象。代表部分事物的对象与代表聚集事物对象的生存期无关，一旦删除了它的一个聚集对象，不一定也就随便删除代表部分事物的对象。在组合关系中，代表整体事物的对象负责创建和删除代表部分事物的对象，代表部分事物的对象只属于一个组合对象。一旦删除了组合对象，也就随即删除了相应的代表部分事物的对象。
（3）关联关系——用静态关系表示，分为自返关联、二元关联、N元关联
关联(association)是对具有共同的结构特性、行为特性、关系和语义的链(链表示对象与对象之间的关系，关联表示类与类之间的关系)的描述
（4）依赖关系——用消息表示对象之间在行为上的依赖关系
假设有两个元素X、Y，如果修改X的定义可能会导致对另一个元素Y的定义的修改，则称元素Y依赖于元素X。对于类而言，如果两个类之间有关联关系，那么一般只要表示出关联关系即可，不用再表示这两个类之间还有依赖关系。
建立类图的步骤：
- 研究问题领域，确定系统的需求
- 确定类，明确类的含义和职责，确定属性和操作
- 确定类之间的关系
- 调整和细化已得到的类和类之间的关系，解决诸如命名冲突、功能重复等问题
- 绘制类图并增加相应的说明
ps：抽象类与接口区别：
抽象类是不能直接产生实例的类，因为抽象类中的方法往往只是一些声明，而没有具体的实现，因此不能抽象类实例化。接口与抽象类很相似，但两者之间存在不同的地方：接口不能含有属性，而抽象类可以含有属性；接口中声明的所有方法都没有实现部分，而抽象类中的某些方法可以有具体的实现。
2.4.2 需求模型——用例图(用况图)
用例是系统、子系统或类和外部的参与者(actor)进行交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。而参与者是指系统以外的、需要使用系统或与系统交互的东西，包括人、设备、外部系统等。用例间的关系主要有关联、扩展(extend)、泛化、包含(include)关系等。
（1）泛化关系：子用例继承了父用例的行为和含义，子用例也可以增加新的行为和含义或覆盖父用例中的行为和含义
（2）包含关系<<include>>：指两个用例之间，其中一个用例的行为包含了另一个用例，包含关系是比较特殊的依赖关系。在包含关系中，箭头的方向是从基本用例指向包含用例，即基本用例依赖于包含用例。
（3）扩展关系<<extend>>：扩展关系是对扩展用例有更多的规则限制，即基本用例必须声明若干扩展点，而扩展用例只能在这些扩展点上增加新的行为和含义。在扩展关系中，箭头的方向是从扩展用例到基本用例，也就是说，扩展用例是依赖于基本用例的。
注意区别包含关系与扩展关系：在包含关系中，在执行基本用例时，一定会执行包含用例；在扩展关系中，一个基本用例执行时，可以执行、也可以不执行扩展部分，简言之，满足条件就执行，不满足条件就不执行。
用例图：把用例、参与者以及它们之间的关系用一些图像符号进行可视化表示，便得到用例图。它是直接描述需求的，所以是一个需求模型。
寻找用例的步骤：
- 找出系统外部的参与者和外部系统，确定系统的边界和范围
- 确定每一个参与者所期望的系统行为
- 把这些系统行为命名为用例
- 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分
- 编制每一个用例的脚本
- 区分主事件流和异常情况的事件流，如果需要，可以把表示异常情况的事件流作为单独的用例处理
- 细化用例图，解决用例间的重复与冲突问题
2.4.3辅助模型——包图、顺序图、活动图及其他
（1）包图：包(package)是一种将其他模型元素组织起来，形成较大粒度的系统单位的机制。UML中，包是分组事物的一种，它是在建模时用来组织模型中的元素的，在系统运行时并不存在包的实例，这点和类不一样，类在运行时会有实例。
设计包的原则：
- 重用等价原则：指把类放入包中时，应考虑把包作为可重用的单元
- 共同闭包原则：指把那些需要同时改变的类放在一个包中
- 共同重用原则：指的是不会一起使用的类不要放入同一个包中
- 非循环依赖原则：指的是包之间的依赖关系不要形成循环
ps：重用等级原则、共同闭包原则、共同重用原则这3个原则事实上是相互排斥的，不可能同时被满足。它们是从不同使用者的角度提出的，重用等价原则和共同重用原则是从重用人员的角度考虑的，而共同闭包原则是从维护人员的角度考虑的。共同闭包原则希望包越大越好，而共同重用原则却要求包越小越好。
（2）顺序图：用来描述一组相互协作的对象在完成一项功能时彼此之间的交互情况。它按时间顺序把各个对象所执行的操作以及它们之间所传达的消息展现出来，因此可以清晰直观地表示对象之间的行为依赖关系以及操作与消息的时序关系。
建立顺序图的步骤：
- 确定交互过程的上下文
- 识别参与交互过程的对象
- 为每个对象设置生命线，即确定哪些对象存在于整个交互过程中，哪些对象在交互过程中被创建和撤销
- 从引发这个交互过程的初始消息开始，在生命线之间自顶向下依次画出随后的各个消息
- 如果需要表示消息的嵌套，或表示消息发生时的时间点，则采用控制焦点(控制焦点是顺序图中表示时间段的符号，表示为在生命线上的小矩形)
- 如果需要说明时间约束，则在消息旁边加上约束说明
- 如果需要，可以为每个消息附上前置条件和后置条件
(3) 活动图：活动图的作用是对系统的行为建模，它把系统中的一项行为表示成一个可以由计算机、人或者其他执行者执行的活动，通过给出活动中的各个动作以及动作之间的转移关系来描述系统的行为。类图中的每个类都要定义它应该提供的操作，但是并不能把每个操作的执行过程具体地表示出来。顺序图表现了一组对象是如何通过消息进行交互的，以及有关的操作和消息的时间顺序，但是也没有详细地表示每个操作内部的执行情况。对此，活动图可以起到很好的补充作用。一般活动图可以对系统的工作流程建模，即对系统的业务过程建模，也可对具体的操作建模，用于描述计算机过程的细节。
活动(activity)表示的是某流程中的任务的执行，它可以表示某算法过程中语句的执行。在活动图中注意区分动作状态和活动状态。动作状态是原子的，不能被分解，没有内部转移，没有内部活动，动作状态的工作所占用的时间是可以忽略的，动作状态的目的是执行进入动作，然后转向另一个状态。活动状态是可分解的，不是原子的，其工作的完成需要一定的时间。
泳道：泳道是活动图中的区域划分，根据每个活动的职责对所有活动进行划分，每个泳道代表一个责任区。泳道和类并不是一一对应的关系，泳道关心的是其所代表的职责，一个泳道可能由一个类实现，也可能由多个类实现。
在活动图中，对于同一个触发事件，可以根据不同的警戒条件转向不同的活动，每个可能的转移是一个分支。如果要表示系统或对象中的并发行为，则可以使用分叉(fork)和汇合(join)这两种建模元素。分叉表示的是一个控制流被两个或多个控制流代替，经过分叉后，这些控制流是并发执行的；汇合正好与分叉相反，表示两个或多个控制流被一个控制流代替。
（4）构件图和部署图：构件图和部署图是对面向对象系统物理方面建模的两个图
- 构件图：对源代码文件之间的相互关系建模；对可执行文件之间的相互关系建模
- 部署图：部署图可以用来显示系统中计算结点的拓扑结构和通信路径与结点上运行的软构件等。一个系统模型只有一个部署图
基本概念：
构件：构件是系统中遵从一组接口且提供其实现的物理的、可替换的部分。构件包括部署构件(如dll文件、exe文件数据库表等)、工作产品构件(如源代码文件、数据文件等)、执行构件(系统执行后得到的构件)
构件图中的构件与类图中的类区别：
- 类是逻辑抽象，构件是物理抽象，即构件可以位于结点上
- 构件是对其他逻辑元素，如类、协作的物理实现
- 类可以有属性和操作，构件通常只有操作，而且这些操作只能通过构件的接口才能使用
部署图两个基本概念：结点和连接
结点是存在于运行时的代表计算资源的物理元素，结点一般都具有一些内存而且常常具有处理能力，结点可以代表一个物理设备以及运行在该设备上的软件系统。结点之间的连线表示系统之间进行交互的通信路径，这个通信路径称为连接。部署图的结点分为两类，即处理机和设备
- 处理机是可以执行程序的硬件构件，如处理机有哪些进程、进程的优先级与进程调度方式
- 设备是无计算能力的硬件构件，如调制解调器、终端等
连接表示两个硬件之间的关联关系。
2.5 面向对象分析(OOA)过程
OOA过程包括以下主要活动
（1）建立需求模型——用例图
- 确定系统边界
- 发现参与者
- 定义用例
（2）建立基本模型——类图
- 发现对象、定义它们的类
- 定义对象的内部特征——属性和操作
- 定义对象的外部关系——一般-特殊结构、整体-部分结构、关联和消息
（3）建立辅助模型
- 划分包，建立包图
- 建立顺序图
- 建立活动图
- 建立构件图
- 建立部署图
- 建立其他模型图
（4）建立模型规约：对模型中的成分进行规范的定义和文字说明
（5）原型开发：可选，结合其他活动反复进行
以上各个OOA过程总体来说是一个反复进行，不断完善的过程，以建立基本模型为中心，进行需求模型、基本模型、辅助模型的建立、修复与完善。
参考书籍
《面向对象的系统分析》(第2版) 邵维忠 杨芙清 著
《UML面向对象技术教程》 王少锋 编著