Day05-系统设计-面向对象分析与设计

0、开篇：从"面向过程"到"面向对象"

在上一篇中，给大家讲解完结构化方法（SASD）。它把系统按功能拆成模块，让数据在模块之间流动。

但这种方法有一个天然盲区：它把"数据"和"行为"分开了。数据字典管数据，DFD 管数据怎么流动。数据和行为是割裂开的。

面向对象（Object-Oriented）可以解决这个问题。它的核心思想就一句话：

把数据和处理数据的行为，封装在同一个"对象"里。

面向对象你可以理解为：一个人：有 姓名、年龄、身高是属性（数据），会吃饭、说话、走路是方法（行为）——属性和方法绑定在一起，构成一个完整的个体。而人类的共同特征（一个脑袋两条腿）则是类——类是对象的模板，对象是类的实例。

理解了它，那我们怎么用一套统一的语言，把对象和对象之间的关系画出来？答案就是 UML。

1、UML 统一建模语言的"骨架"

1.1 什么是 UML？

UML（Unified Modeling Language）是一种可视化的标准化建模语言，用于软件系统的描述、可视化、构建和文档化。

UML 的结构由三个部分构成：构造块、规则和公共机制。

1.2 UML的4+1 视图：五个视角看同一个系统

UML 最有价值的框架就是 4+1 视图——从不同角色的视角审视系统架构：

⚠️ 这个 4+1 视图和 RUP 的 4+1 视图一模一样。核心视图是用例视图，它是其他四个视图的源头——先搞清楚"要做什么"，再谈"怎么做"。

1.3 UML 图的分类：结构图 vs 行为图

UML的关系有4种，依赖、关联、泛化（又叫继承）、实现。其他的关系是基于这4种中的某一种关系的延申。比如用例图中的包含和扩展都属于依赖关系。类图中的组合和聚合属于关联关系。

UML 2.0 一共有 14 种图，分为两大类：

结构图 — 描述事物之间的关系（静态）：

行为图 — 描述参与者和用例之间的交互（动态）：

考试重点关注 用例图、类图、活动图、状态图、顺序图 五种，其他了解即可。

2、类图 — 面向对象设计的核心

2.1 类的三个"格子"

一个类在 UML 中用一个三格矩形表示：

2.2 类图的六种关系

类图的核心是表达类与类之间的关系。共有六种，包括：依赖、组合、聚合、关联、继承、实现。

① 依赖关系

构造这个类的时候，需要用到别的类。就像动物依赖水和氧气。

虚线箭头，指向被依赖方。

② 关联关系 — "我有一个属性是别的类"

这个类有一个属性，类型是另一个类。

实线箭头。

③ 聚合关系 — "整体-部分"，部分可以独立存活

聚合是关联关系的一种，是强关联。

空心菱形实线，菱形指向整体。

关键特征：部分对象的生命周期不由整体管理。整体没了，部分还能活。比如大雁脱离雁群依然可以存活。

④ 组合关系 — "整体-部分"，同生共死

组合也是关联关系的一种，比聚合更强。

实心菱形实线，菱形指向整体。

关键特征：部分与整体生命期一致。同时创建、同时消亡。比如鸟与翅膀——鸟死了，翅膀也不再是"翅膀"。

⚠️ 考试高频区分：聚合（空心菱形）vs 组合（实心菱形）。一句话：聚合是"可以分手，好聚好散"，组合是"生死与共"。聚合关系是关联关系的一种，是强的关联关系 ；组合关系同样是关联关系的一种，是比聚合关系还要强的关系。

⑤ 继承（泛化）关系 — "is-a"关系

子类特化父类的所有特征和行为。

空心三角实线，三角指向父类。

鸟是动物的一种；企鹅、鸭、大雁是鸟的一种。

⑥ 实现关系 — 接口与实现类

类与接口的关系，表示类是接口所有特征和行为的实现。

空心三角虚线，三角指向接口。

类图讲清楚了"系统内部的组织结构"。但在这之前还有一件事没解决：用户到底能用系统干什么？ 这就是用例图能做的了。

3、用例图 — 站在用户视角定义系统边界

3.1 什么是用例图？

用例图是一种静态图，由参与者、用例、边界以及它们之间的关系构成，用于描述系统功能的视图。

注意一个关键点：用例图是静态图并且它只展示"有哪些功能、谁在用"，不描述操作的顺序。

3.2 四个基本元素

3.3 用例图的四种关系

用例图中共有四种关系：关联、泛化、包含、扩展。

注意下面的这个表格，考试要考。

① 关联关系 — 参与者与用例之间

参与者与用例之间的通信，任何一方都可发送或接受消息。

无箭头，将参与者与用例相连。

② 泛化关系 — 参与者/用例的继承

子用例和父用例相似，但表现出更特别的行为。子用例继承父用例的所有结构、行为和关系。

箭头指向父用例。

③ 包含关系 — 必须执行的分解

把一个较复杂的用例分解成较小的步骤。最典型的应用就是复用。

箭头指向被分解出来的功能用例。

例如：维护用户信息 → 包含「新增用户」「修改用户」「删除用户」。

④ 扩展关系 — 可选执行的延伸

为基用例提供一个可选的附加功能。扩展用例从基用例声明的扩展点上扩展，使基用例更简练。

关键特征：扩展用例对基用例不可见（调用方向单向）；扩展用例可以访问基用例的属性来决定是否执行自己。

用例图四种关系速记

用例图描述了系统外部的人或系统（Actor），为了达成某个可观测、可量化的业务目标，而与系统进行的一系列有意义的交互。但用户执行一次交互时，对象之间是怎么一步步协作的？这就引出交互图。

4、交互图 — 对象之间的"对话"

4.1 顺序图（时序图/序列图）— 按时间线看调用

顺序图是一种 UML 交互图，按时间顺序展示各个对象之间如何调用。

它的元素包括：对象/生命线、交互片段、执行发生、状态不变式。

以微信支付流程为例：

顺序图的三种消息类型

区分：同步消息会阻塞等待，异步消息不阻塞。返回消息通常伴随同步消息一起出现。

4.2 通信图（协作图）— 按对象关系看协作

通信图描述一组对象在协作过程中如何互相通信，强调对象之间的结构关系。

组成：对象（类的实例）+ 链（对象之间的结构关系）+ 消息（对象间的调用）。

4.3 通信图与顺序图的区别

5、活动图 — 流程与并发的可视化

活动图描述事物或对象的活动变化流程，类似流程图，但支持并发。

适用场景：业务建模、需求分析、类设计。

举例：

活动图与之前结构化方法中讲的流程图（PFD）最大的不同在于：活动图天然支持并发（分叉/汇合），而传统流程图只能串行。 这是面向对象带来的表达能力跃迁。

到这里，UML 的几种核心图已经讲清楚了。但还有一道灵魂拷问：有了这些图，接下来的分析和设计该怎么组织？

这就进入了面向对象方法论的完整流程：OOA → OOD。

6、面向对象分析（OOA）— 用对象建模"要做什么"

OOA（Object-Oriented Analysis）运用面向对象方法对问题域进行分析，识别对象、类、属性、关系，构建独立于技术实现的分析模型。

简单说：在编码之前，用面向对象的方式把问题搞清楚。

关于OOA，在教材中提到了2个重要的模型，分别是用例模型和分析模型。这两个模型需要掌握。

用例模型（用例图表示） — 站在用户视角，说清"系统要做什么"。

分析模型（类图表示） — 站在系统视角，说清"怎么实现功能"。

6.1 用例模型：用例图表示，界定功能边界

从用户和业务角度描述系统的功能及其处理过程，帮助分析人员与用户达成需求共识。

组成元素：系统、参与者、用例、关系。

构建用例模型的 4 个阶段：识别参与者 → 合并需求获得用例 → 细化用例描述 → 调整用例模型。

识别参与者 — 不局限于"人"

参与者可以是任何驱动系统执行功能的外部角色：

6.2 分析模型：类图表示

分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）。把用户需求转化为系统内部结构与行为的抽象描述，描述“怎么实现功能”。

组成元素：其实就是由类图通过类与对象（模板与实例）、属性（特征描述）、操作（行为动作）和关系（关联、聚合、组合、泛化、依赖、实现等）描述系统的静态结构；交互图（如序列图）则通过消息传递展示对象间的动态协作过程。两者结合，分别从静态和动态视角完整刻画系统的结构与行为组合在一起的。

7、面向对象设计（OOD）— 把分析模型进行可实现

OOD 是 OOA 的延续。核心思想：抽象、封装和可扩展性（通过继承和多态实现）。

OOD 的核心工作之一，就是把分析阶段识别出来的类，按照职责进行分类。

7.1 三种类：各有各的职责

快速判断口诀：

• 实体类 → 名词（学生、课程、订单）
• 控制类 → 动词+名词（身份验证器、订单处理器）
• 边界类 → 对外接口（窗口、报表、API）