面向对象系统分析与设计

间坐小窗读周易

不知春去几多时

面向对象考试重点总结。

1-1 概述

1.1 分析与设计

1. 什么是面向对象的分析？

   面向对象的分析强调的是在问题域内发现和描述对象。

2. 什么是面向对象的设计？

   面向对象的设计强调的是如何定义对象以及它们是如何协作的。

3. 什么是面向对象的分析与设计？

   分析是识别现实世界中的对象；设计是找到软件世界中的对象。

1.2 面向对象

• 面向对象的优点是什么？

  复用、应变、沟通、市场、士气？？？

• 面向对象是什么？

  对现实世界的理解和抽象的方法。

1.3 UML建模

UML是一种很统一的、标准化的，应用面很广泛的建模语言。

1. 为什么使用UML建模？

   • 利用UML20%就可以为80%的问题建模
   • 一图胜过千言万语

2. UML建模过程

   • 定义用例
   • 定义领域模型
   • 定义交互图
   • 定义设计类图

3. 定义领域模型（OOA）

   领域模型并不是对软件对象的描述，它是真实世界领域中概念和想象可视化，又称为概念模型。

4. 定义交互图

   • 关注的是软件对象的定义，以及它们的职责和协作
   • 顺序图/时序图是描述协作的常用手法
   • 顺序图展示出软件对象之间的消息流

1.4 可视化建模

可视化建模的优点：

• 观察全景
• 发现和分析对象之间的联系
• 忽略或隐藏细枝末节

1-2 迭代、进化和敏捷

2.1 软件过程

1. 什么是软件过程？

   软件过程定义了软件开发、部署和维护的步骤。

2. 软件过程本身就是软件，是一种由人构成的虚拟机执行的软件。

2.2 迭代式开发

1. 瀑布式生命周期

   试图在编写代码之前定义所有的需求，以及详尽的时间表。

2. 迭代式的生命周期

   • 通过多次的迭代获得周期性的反馈，以这些反馈为驱动力，对系统进行不断的扩展和精化
   • 迭代式开发将软件开发过程分解为一系列小的，固定的周期项目，每个小项目称为一次迭代
   • 迭代的周期固定，一般为2-6周

3. 迭代式开发的优势

   • 能够较早地应对风险高的内容
   • 能够让人明确地看到进展
   • 能够较早地获得反馈，鼓励用户参与，靠近用户的需求
   • 控制复杂性

2.3 统一过程（Unified Process, UP）

1. UP是迭代过程的一种，提出人Ivar Jacobsn
2. UP具有灵活性，可以应用于敏捷方法
3. 4个主要阶段
   • 初始
   • 细化
   • 构造
   • 移交

2.4 敏捷方法

1. 敏捷开发
   • 进化式精进的计划
   • 需求和设计的短时间迭代
   • 简易，轻量，沟通
2. 敏捷宣言
   • 个体和交流
   • 工作的软件
   • 与客户协作
   • 积极响应变更
   • 过程和工具
   • 完善的文档
   • 合同谈判
   • 严格履行计划
3. 敏捷原则
   • 通过早期和持续交付满足客户
   • 欢迎变更需求
   • 以两周-两月为周期，频繁交付软件
   • 每天开发人员都要和业务人员交流合作
   • 依靠有干劲的个体推动项目的开发
   • 衡量进度的重要尺度是可运行的软件
   • 提倡开发和集成
4. 什么是敏捷建模？
   • 不对所有或大部分软件设计建模或应用UML
   • 尽可能使用最简单的软件
   • 不单独建模
   • 并行建模
   • 明白“任何模型都不准确”
   • 开发者为自己进行建模

1-3 敏捷开发？？

3.1 敏捷开发原则

敏捷开发10原则？？？

3.2 Srum

Scrum是一个敏捷的过程，使我们能够专注于在最短的时间内提供最高的业务价值。

2 需求&用例

2.1 需求

1. 什么是需求？

   需求是一套系统或者项目所要满足的能力和条件。

2. 需求类型

2.2 用例

1. 参与者种类

   • 主要参与者
   • 辅助参与者
   • 幕后参与者

2. 用例定义

   • 站在用户角度定义软件系统的外部特征
   • 可表示为系统提供的某种服务或者行为
   • 把现实世界捕获下来的方法

3. 用例和需求的关系

   用例就是需求，需求不是用例？？？

4. 什么是用例图？

   一个用例模型由若干个用例描述，用例图是显示一组用例，参与者以及他们之间关系的图。

5. 用例图的组成

   • 一组用例
   • 一组参与者
   • 一组关系

6. 用例图的应用

   • 从用户角度来描述软件的需求

   • 分析产品的功能和行为
   • 定义和描述了系统的外部可见行为

7. 参与者

   • 定义：在系统之外，通过系统边界与系统进行直接有意义交互的任何事物。
   • 关键词：系统外、责任边界、

8. 如何识别用例？

   1. 选择系统边界
   2. 确定主要参与者
   3. 确定每个主要参与者的目标
   4. 定义满足用户目标的用例，并根据其目标命名

9. 用例的粒度

   阶段	粒度	例子
   业务建模 （描述功能性需求）	用例名称能够说明一个完整业务流程	取钱、报装电话、借书等
   概念建模	用例描述一项完整业务的一个步骤	提供申请资料、受理业务等
   系统建模	用例能够描述操作者与计算机的一次完整交互为宜	填写申请单、审核任务单、验证密码等

10. 用例描述

描述用例的流程细节。

1. 用例描述四种形式

   • 命名
   • 摘要
   • 非正式
   • 详述

2. 用例描述组成

   • 用例名称
   • 范围
   • 级别
   • 主要参与者
   • 涉众及观众点
   • 前置条件
   • 成功保证
   • 主成功场景：基本事件流
   • 扩展
   • 后置条件

3. 用例描述举例

1. 用例描述总原则

   如果涉众不能理解和验证，就不是需求。（如果删除他，会不会有涉众的利益受到伤害）

2. 主成功场景编写要点

   • 只书写“可理解、可验证、可观测”的
   • 每个步骤一个句子
   • 使用主动语句，理清责任
   • 句子以参与者或者系统为主语

3 域模型与类图

3.1 概念类

1. 概念类定义

   概念类是描述现实世界的实体或者概念，是现实世界问题域的概念。

2. 如何找到概念类

   • 重用或者修改现有模型
   • 使用分类列表
   • 确定名词短语，作为候选的关键抽象

3.2 领域模型

1. 定义

   • 也称为域模型，概念模型，是对领域内的概念类或者对现实中对象的可视化表示。

   • 在UML中，领域模型被描述为一组没有定义操作的类图。

2. 领域模型不是数据模型，与概念数据模型类似

3.3 关键抽象方法

从软件需求规格说明书或用例即用例描述中将所有名词抽取出来，填入“候选关键抽象表格”，从而识别出所有的关键抽象。

1. 候选的关键抽象表格由以下三列组成
   • 候选的关键抽象
   • 排除的原因，属性，同义词，无关类。
   • 选定的名词
2. CRC分析法(Class-Responsibility-Collaborator)
   • 是一种收集并整理卡片的开发方式
   • 是一种面向文本建模技术，具有影响力的敏捷思想
   • 步骤：
     • 选择一个候选的关键抽象
     • 确定一个与该候选关键抽象相关的的用例
     • 查看用例描述和系统的功能需求来确定职责和协作的关系
     • 用CRC卡片记录抽取出来的关键抽象
     • 基于以上的工作，更新候选关键抽象表格
3. 排除候选关键抽象的原因：
   • **的属性
   • 仅有一个实例
   • 系统外部的
   • 与**重复
   • 可以和**合并

3.4 类图

类图由以下元素组成：

1. 类的组成

   • 名字
   • 属性
   • 操作
   • 可见性
     • 私有
     • 公有

2. 关联

   关联是类之间的关系，表示有意义和值得关注的连接。

3. 为什么应该避免加入大量关联？

   • 节点间可以有(n * n * (n - 1) / 2)个关联？
   • 太多关联会导致混乱
   • 重点关注需要被记住的关联

4. 关联的多重性

   • 1个A的实例与多少个B的实例关联
   • 1个B的实例与多少个A的实例关联

4 交互图

4.1 交互图概述

1. 顺序图，按照时间顺序来描述对象的交互
2. 通信图，围绕着对象和对象之间的链接来描述对象的交互

4.2 顺序图

1. 定义：显示一组对象为了实现某种功能，而彼此发送和接收一串消息，这组对象可能是类，接口，节点等或者是具体的实例。
2. 建模元素
   • 对象
   • 生命线
   • 消息
   • 执行规格条

4.3 系统顺序图

4.4 通信图

1. 定义

   关注对象在参与具体的交互时，对象之间如何链接以及传递什么消息。

2. 3个元素

   • 对象
   • 链
   • 消息

4.5 鲁棒图

1. 鲁棒图的对象元素、职责、与MVC架构的元素对应关系

   鲁棒图的元素	职责	组成架构的元素	MVC架构的元素
   边界对象	交互	连接元素	视图
   控制对象	控制	处理元素	控制器
   实体对象	信息	数据元素	模型

2. 鲁棒图建图原则

   • 参与者只能与边界交谈
   • 边界对象只能与控制体和参与者交流
   • 实体对象也能与控制体交流
   • 控制体可以和实体对象和边界对象交流，但接触不到参与者

5 用例关系和类图

5.1 识别用例关系

1. 用例关系

   • 包含
   • 扩展
   • 泛化

2. 扩展关系VS包含关系

   包含关系	扩展关系
   标示«include»的带箭头虚线	标示«extend»的带箭头虚线
   基础用例指向被包含的小用例	小用例指向被扩充的基础用例
   一定要执行小用例	条件成立（扩展点）才执行小用例

5.2 类图

1. 常用类图表示

   

2. 依赖关系（虚线+开口箭头）VS关联关系（实线+开口箭头）

   • 从时间角度区分：依赖关系是一种短暂，动态的关系；关联关系是一种持久，静态的关系；
   • 从类之间关系的强弱区分：关联关系比较强；依赖关系弱；
   • 设计类之间关系需要遵循的原则：首先判断是不是“关联”关系，再判断是不是“依赖”关系
   • 依赖关系是单向的，关联关系之间的导航一般是双向的，关联关系体现在代码中一般是成员变量

3. 泛化关系（实线+空心闭合箭头）：一般类与具体类之间的关系（继承）

4. 接口（表示为空心圆圈）与实现（实现类虚线+空心闭合箭头指向接口）

5. 保护等级

   

6 面向对象

6.1 面向对象的设计原则

1. 什么是面向对象设计？

   • 找到软件对象
   • 分配职责，协调

2. 面向对象的设计原则有什么意义？

   • 是指导面向对象设计的基本思想
   • 评价面向对象设计的价值观体系
   • 设计模式的出发点和归宿

3. 设计目标

   • 可扩展性
   • 灵活性
   • 健壮性
   • 可插入性

4. 好的设计

   • 容易理解
   • 容易修改和扩展
   • 容易复用
   • 容易实现和应用
   • 简单、紧凑，经济适用

5. 坏的设计

   • 僵化
   • 脆弱
   • 牢固
   • 粘滞
   • 不必要的复杂性
   • 不必要的重复
   • 晦涩

6. 设计原则

   • LSP：Liskov替换原则，子类对象必须可以替换基类对象
   • Meyer原则
   • OCP原则：开放-封闭原则，软件实体是可拓展但不可修改的
   • SRP原则：单一职责原则，一个类仅有一个引起它变化的原因
   • ISP原则：接口隔离原则，客户不依赖用不到的接口，只提供所需要的接口
   • DIP原则：依赖倒置原则，高层不依赖低层，二者依赖于抽象；针对接口编程

6.2 设计模式

1. 设计模式的基本思想

   1. 松耦合
   2. 针对接口编程
   3. 继承、组合、委托、多态、参数化

2. GRASP：通用职责分配软件模式

   • 创建者
   • 信息专家
   • 低耦合
   • 控制器
   • 高内聚
     • 不要给一个类太多的职责
     • 不相关的职责和功能不要分给一个类
   • 多态
   • 纯虚构
   • 间接性
   • 防止变异：避免系统或对象内部的变化影响其他模块和元素。

7 GOF设计模式

7.1 适配器模式

• 问题：如何解决接口不相容的问题，如何为具有不同接口的相似组件提供一个统一稳定的接口
• 解决方案：通过一个中间的适配器对象，使一个组件的原有接口变为另一个接口

7.2 工厂模式

• 问题：谁有责任创建写特殊考虑的对象？比如说有复杂的创建逻辑，为了更好地内聚性而希望分离创建职责
• 解决方案：创建一个称为工厂的纯虚构对象来处理。

7.3 单例模式

• 问题：如何使得一个类严格地只有一个实例？
• 解决方案：对类定义静态方法，返回实例。

• Previous
  博客中使用Latex公式
• Next
  LRU Cache