面向对象系统分析与设计
面向对象系统分析与设计
- OOA概述
- 1. 分析与设计
- 什么是分析
- 什么是设计
- 总结
- 2. 面向对象
- 什么是面向对象的设计
- 面向对象的优点
- UML
- 3. 软件开发
- 软件过程
- 软件过程的谱系
- 迭代式开发
- 统一过程（UP）
- 用例图（use case diagram）
- 1. 用例图的组成
- 2. 用例之间的关系
- 3. 用例关系的对比
- 4. 用例描述
- 5. 要点：用例的粒度
- 类图（class diagram）
- 1. 分析类与设计类
- 2. 类图
- 3. 类图的组成
- 4. 类之间的关系
- 5. 概念类
- 6. 领域模型
- 交互图
- 1. UML动态模型
- 2. 顺序图
- 3. 通信图
- 链
- 实例
- 4. 系统顺序图
- 5. BCE模式
- 6. 鲁棒性分析
- 项目工时
- 1. Gustav Karner的用例点模型估算工时
- GRASP：基于职责设计对象
- 1. 设计模式（Patterns）
- 2. 设计模式的基本要素
- 设计模式
- 基本概念
- 关系
- 面向对象设计模式
- 模式分类
- 应用GoF设计模式
OOA概述
面向对象分析方法（Object-Oriented Analysis, OOA），是在一个系统的开发过程中进行了系统业务调查之后，按照面向对象的思想来分析问题。
1. 分析与设计
什么是分析
强调的是对问题和需求的调查研究，而不是解决方案。
- 需求分析：通常简称需求或分析，调查研究系统要成功所必须满足的需求。
- 面向对象分析：调查研究领域对象以发现重要信息来满足需求。
什么是设计
强调的是满足需求的概念上的解决方案（在软件或硬件方面）。设计不是实现，虽然一个好的设计在完成后可以被（编程）实现。
总结
- 分析：做正确的事（do the right thing）——确定做什么事？
- 设计：正确地做事（do the thing right）——怎样把确定的事情做好？
| 分析 | 设计 |
|---|---|
| 用户视角 | 计算机视角 |
| 卖的视角 | 做的视角 |
| 具体 | 抽象 |
| 产品当项目做 | 项目当产品做 |
2. 面向对象
什么是面向对象的设计
面向对象是一种对现实世界理解和抽象的方法。
面向对象的分析（Object Oriented Analysis，OOA）强调的是在问题域内发现和描述对象（或概念类）。
面向对象的优点
- 复用：通过抽象、继承、关联、封装等手段
- 应变：弹性应对需求变化
- 沟通：开发人员、用户、管理人员
- 市场：应付市场的变化
- 士气：员工的士气
UML
统一建模语言（Unified Modeling Language，UML）是用于指定、构造和记录系统工件的一种可视化语言。
The Unified Modeling Language is a visual language for specifying, constructing and documenting the artifacts of systems.
3. 软件开发
软件过程
软件过程：定义了软件开发、部署和维护的步骤。
软件过程本身就是软件：软件过程是一种被由人构成的虚拟机执行的软件。
软件过程的谱系
- 迭代式开发
- 统一过程（Unified Process）
- 敏捷UP
迭代式开发
- 瀑布生命周期
在瀑布生命周期过程中，试图在编写代码之前定义几乎所有的需求，以及明确详尽的时间表。 - 迭代式的生命周期
通过多次的迭代获得周期性的反馈，以这些反馈为驱动力，对系统进行不断的扩展和精化。
迭代式开发将软件开发过程分解为一系列小的，固定周期的（比如，4个星期）的小项目，每个小项目成为一个迭代。
统一过程（UP）
UP项目将工作和迭代组织分为4个主要的阶段：
- 初始（Inception） = 需求
- 细化（Elaboration） = 设计
- 构造（Construction） = 实现
- 移交（Transition）
用例图（use case diagram）
1. 用例图的组成
一个用例模型由若干个用例图（use case diagram）描述。用例图是显示一组用例、参与者以及它们之间关系的图。说明的是谁要使用系统，以及他们使用该系统可以做些什么。
用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和行为。用例图定义和描述了系统的外部可见行为，是分析、设计直至组装测试的重要依据。
- 参与者（actor）：系统以外的，在使用系统与系统交互中所扮演的角色。
- 用例（use case）：对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。简单来说，用例是参与者想要系统做的事情。
- 系统边界：用来表示正在建模系统的边界。
2. 用例之间的关系
- 包含关系：用例可以简单地包含其他用例具有的行为。箭头由基础（Base）用例指向被包含（Inclusion）用例。提取公共交互，提高复用
- 拓展关系：在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，从扩展用例到基础用例的关系就是扩展关系。“冻结”基础用例以保持稳定
例如：
- 泛化关系：用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。子用例继承了父用例所有的结构、行为和关系，并且可以添加、覆盖、改变继承的行为。三角箭头从子用例指向父用例。同一业务目的的不同技术实现
例如：
3. 用例关系的对比
| 包含关系 | 扩展关系 |
|---|---|
| 标示include的带箭头虚线 | 标示extend的带箭头虚线 |
| 基础用例指向被包含的小用例 | 小用例指向被扩充的基础用例 |
| 一定要执行小用例 | **条件成立（扩展点）才执行小用例 |
4. 用例描述
5. 要点：用例的粒度
“四轮马车”：
- C(Create)
- R(Read)
- U(Update)
- D(Delete)
类图（class diagram）
1. 分析类与设计类
分析类三高：
- 高于设计实现，不必应用采用的设计模式，系统框架等
- 高于语言实现，不必理会哪一种特性的语言来编码
- 高于实现方式，可以不考虑采用哪一种具体的实现方式
设计类： - 设计类是系统实施中一个或多个对象的抽象
- 设计类所对应的对象取决于实施语言
2. 类图
用例图：外观
类图：内部机理
类图（class diagram）：用来表达业务领域或系统内部的静态结构。
分析人员通过类图进行业务建模，描述业务领域内概念类机器之间关系的静态结构。设计人员通过类图进行系统设计，将数以万计的程序代码分门别类，构成了系统内部的静态结构。
3. 类图的组成
- 名字
- 属性
- 操作
- 可见性：私有，公有
4. 类之间的关系
- 依赖关系
表示的是两个或多个模型元素之间语义上的连接关系。它表示，提供者的某些变化会要求或指示依赖关系中客户的变化，也就是说，依赖关系将行为和实现与影响其他类的类联系起来。
- 泛化关系
描述类的一般和具体之间的关系。具体描述建立在对类的一般描述的基础之上，并对其进行扩展。因此，在具体描述中不仅包含一般描述中所拥有的所有特性、成员和关系，而且还包含了具体描述补充的信息。
- 关联关系
是一种结构关系，指出了一个事物的对象与另一个事物的对象之间的语义上的连接。描述了系统中对象或实例之间的离散连接，它将一个含有两个或多个有序表的类，在允许复制的情况下连接起来。一个类的关联的任何一个连接点都叫做关联端，与类有关的许多信息都附在它的端点上。关联端有名称、角色、可见性以及多重性等特征。
- 实现关系
将一种模型元素（如类）与另一种模型元素（如接口）连接起来，是说明和其实现之间的关系。
5. 概念类
概念类是思想、事物或类（对象）。概念类可以从其符号、内涵和外延来考虑。
- 符号：表示概念类的词语或图形
- 内涵：概念类的定义
- 外延：概念类所适用
抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征。
如何找到概念类 - 重用和修改现有模型
- 使用分类列表
- 确定名次短语：将对领域的文本描述中的名词和名词短语作为候选的概念类或属性。——关键抽象
确定关键抽象的方法 - 从软件需求规格说明书或用例及用例描述中将所有名词抽取出来，填入“候选关键抽象”表格，从而识别出所有的关键抽象。
- 用CRC（Class-Responsibility-Collaborator）分析法确定最基本的一组关键抽象。
候选的关键抽象表格
三个属性： - 候选的关键抽象：包含了所有从软件需求说明书中找出来的名词
- 排除的原因
- 选定的名字：填写被提取出来作为关键抽象的类名
CRC（Class-Responsibility-Collaborator）分析法
6. 领域模型
领域模型：也称为域模型、概念模型、领域对象模型和分析对象模型，是对领域内的概念类或现实中对象的可视化表示。
应用UML表示法，领域模型被描述为一组没有定义操作的类图。是OO分析中最重要的和经典的模型。
交互图
1. UML动态模型
- 交互图（interaction diagram） 包括：
顺序图（sequence diagram，时序图，序列图）：最常用，按照时间顺序来描述对象的交互，强调了消息发生的时间顺序。
通信图（communication diagram，UML2.0之前称为协作图）：围绕着对象和对象之间的链接来描述对象的交互，强调对象的组织结构。
（顺序图强调了消息发生的时间顺序，而通信图强调对象的组织结构。顺序图中对象之间的链接是隐含的，通信图中对象之间的链接是显式的。） - 状态图（state diagram）
对一个类的生命循环建模，对复杂的动态行为有用。 - 活动图（activity diagram）
活动到活动之间的控制流，用于对业务过程、工作流建模，也可以对用例实现建模。
| 用例图 | 类图 | 交互图 |
|---|---|---|
| 动态行为（系统外在行为） | 静态结构（系统内在结构） | 动态行为（系统内在行为） |
| 参与者、用例 | 类 | 对象（object） |
| 包含、扩展 | 关联 | 消息（message） |
| 用例描述 | 关键抽象、CRC | BCE模式 |
| 业务流程 | 领域概念 | 概念与流程的关联 |
2. 顺序图
顺序图：显示一组对象为了实现某种功能，而彼此发送和接收的一串消息，这组对象可能是类、接口、构件、节点和系统的具体的或原型化的实例。强调消息时间顺序。
组成元素：
- 对象（Object）
- 生命线（Lifeline）
- 消息（Message）
- 执行规格条（Execution Specification bar）
3. 通信图
通信图：关注对象在参与具体的交互时，对象之间如何链接以及传递什么消息。是对象间消息的结构化视图。
组成元素：
- 对象（Object）
- 链（Link）
- 消息（Message）
链
链是连接两个对象的路径，它指明了对象间某种可能的导航和可见性。更正式的说，链是关联的实例。
实例
注意：create()方法在链上，而不是在类中。
4. 系统顺序图
系统顺序图（SSD）：阐述与所讨论系统相关的输入和输出事件而快速、简单创造的制品（顺序图）。
对于用例的一个特定场景，SSD展示了直接与系统交互的外部参与者对系统（作为黑盒）发起的系统事件以及其（系统事件）顺序。
系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。
5. BCE模式
BCE模式：将对象分为三类，边界类（boundary class），控制类（control class），实体类（entity class）。
应用BCE模式规则：
- 针对每一个用户，可以对应生成一个控制类
- 参与者对象只能和边界对象互动
- 实体对象不能发送消息给边界对象和控制对象
序列图关联了类图和用例图两个方面，可通过BCE确定序列图。
6. 鲁棒性分析
项目工时
1. Gustav Karner的用例点模型估算工时
Karner建议：
- 未经调整的用例点 = 参与者总权重 + 用例总权重
- 技术复杂系数 = 0.6 + (0.01 * 技术总权重)
- 环境系数 = 1.4 + (-0.03 * 环境总权重)
例子：项目一个100个用例点，团队成员5人，每人每天工作8小时，一周共工作5天。最后估算花费10周的时间。
计算过程：
每个用例点估算人时：20人时
用例点：100个
团队成员：5人
每天工作时数：8小时
每周工作天数：5天
计算过程：
20（人时） × 100（用例点） = 2000（人时）
8（小时） × 5（工作天） = 40(工时)
2000（人时） ÷ 5（人） ÷ 40（工时） = 10（周）
估计工时：10周
GRASP：基于职责设计对象
1. 设计模式（Patterns）
设计模式：一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。
使用设计模式的目的：为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。设计模式使代码编写真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。
例如：
模式名：信息专家（Information Expert）
问题：分配职责给对象的基本原则是什么？
解决方案：将职责分配给信息专家——含有满足职责所需信息的类。
2. 设计模式的基本要素
- 名称：用于助记，形象表示这个模式
- 问题：这个模式可以解决什么问题
- 解决方案：这个模式怎样解决这个问题的步骤与方法
- 效果：使用这个模式与不使用这个模式有什么区别，它有什么优点和缺点
设计模式
基本概念
设计模式是在面向对象的基础之上，对软件的架构进行合理的组合，按照一定的原则使软件架构达到一种松散耦合、以求得对变化的适用。
设计模式的前提就是面向对象，其利用接口对模块进行隔离（门面模式，桥梁模式），利用多态对变化进行封装（策略模式，状态模式，装饰模式），对创建进行合理规划（静态工厂模式，工厂模式，单例模式，多例模式）。
找出我们所面对的事情共同的部分抽象之后形成一般性解决方案就形成了设计模式。
关系
面向对象思想的前提是抽象，从现实世界中抽象出一些对象或者类的共性之后封装成类或者抽象类或者接口。这些类也罢接口也好是为了增加代码的复用性，既然是为了复用，当然需要子类来继承。在继承的过程中为了满足子类个性化的需求，于是多态就自然的出现了。为了更好地体现面向对象的思想我们有了一系列的设计原则，而设计模式只不过是设计原则的具体的表现罢了。
面向对象设计模式
面向对象设计模式解决的是“类与相互通信的对象之间的组织关系”，包括它们的角色、职责、协作方式几个方面。
- 三大特性：
- 封装，隐藏内部实现
- 继承，复用现有代码
- 多态，改写对象行为
- 设计原则
- 针对接口编程，而不是针对实现编程
- 优先使用对象组合，而不是类继承
- 封装变化点（把变的封装当一个地方，把不变的封装到另一个地方，松耦合）
模式分类
- 从目的来看
- 创建型（Creational）：负责对象创建
工厂方法模式，抽象工厂模式，建造者模式，单例模式，原型模式
involve object instantiation and all provide a way to decouple a client from the objects it needs to instantiate. - 结构型（Structural）：处理类与对象之间的组合
适配器模式，装饰器模式，代理模式，外观模式，桥接模式，组合模式，享元模式
let you compose classes or objects into larger structures. - 行为型（Behavioral）：类与对象交互中的职责分配
策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式
concerned with how classes and objects interact and distribute responsibility.
- 从范围来看
- 类模块处理类与子类的静态关系
- 对象模式处理对象间的动态关系
应用GoF设计模式
常用模式：
- 适配器模式（Adapter）
- 工厂模式（Factory）
- 单实例类模式（Singleton）
- 策略模式（Strategy）
- 组合模式（Composite）
- 外观模式（Facade）
- 观察者模式（Observer）
