UML和模式应用（软件分析设计与建模期末复习）

使用的书籍：UML和模式应用（原书第三版）

软件分析设计与建模期末复习

注意，没有出现的章节多半是无关紧要的（对于很着急的同学）

急速通过复习核心概念，冲冲冲！

注意在里面写到但是没有出现的图（例如包图等等都是重点，建议翻开书多看看，会要求画）

目录

CH1面向对象分析和设计

CH2 迭代、进化和敏捷（Iterative, Evolutionary, and Agile）

CH5 进化式需求

CH6 用例（Use - case）知识梳理

CH7--CH9

CH7 其他需求

CH8 迭代——基础

CH9 领域（domain）模型

CH10-CH12 内容整理

一、CH10 系统顺序图（SSD）

二、CH11 操作契约（Contracts）

三、CH12 从需求到设计——迭代进化

CH13、CH15-CH16 内容整理

一、CH13 逻辑架构（Logical Architecture，LA）和 UML 包图

二、CH15 UML 交互（Interaction）图

三、CH16 UML 类图

CH17 GRASP（基于职责设计对象）知识梳理

一、创建者（Creator）

二、信息专家（Information Expert）

三、低耦合（Low Coupling）

四、控制器（Controller）

五、高内聚（High Cohesion）

六、多态性（Polymorphismx

七、纯虚构（Pure Fabrication）

八、间接性（Indirection）

九、防止变异（Protected Variations）

CH18-CH20 内容整理

一、CH18 用例实现与 UML 状态机图

二、CH19 对可见性（Visibility）进行设计

三、CH20 设计到代码（design - to - code）

CH21 重构（Refactoring）

CH26 GoF设计模式梳理（迭代2）

一、适配器（Adapter）

二、工厂（Factory）

三、单实例类（Singleton）

四、策略（Strategy）

五、组合（Composition）

六、外观（Facade）

七、观察者（Observer）

一、CH39 N + 1 view model（迭代3）

额外补充

---

CH1面向对象分析和设计

一、分析与设计

（一）分析

• 定义：对问题和需求的调查研究
• 包含要点（Analysis include these points）：

• • Focus on understanding the problem（聚焦理解问题）
  • Idealized design（理想化设计）
  • Behavior（行为）
  • System structure（系统结构）
  • Functional requirements（功能需求）
  • A small model（一个小模型）

（二）设计

• 定义：解决方案
• 包含要点（While Design include the following points）：

• • Focus on understanding the solution（聚焦理解解决方案）
  • Operations and attributes（操作与属性）
  • Performance（性能）
  • Close to real code（贴近实际代码）
  • Object lifecycles（对象生命周期）
  • Implementation requirements（实现需求）

二、面向对象分析与设计

（一）面向对象分析（OOA）

• 关键任务：发现和描述对象
• 工作内容：

• • Analysis define a candidate architecture, perform architectural synthesis, and analyze behavior.（分析定义候选架构，执行架构综合，并分析行为 ）
  • 定义软件对象及它们如何协作以实现需求

（二）面向对象设计（OOD）

• 关键任务：定义软件对象及协作
• 工作内容：Design refine the architecture, define components, and design the database.（设计细化架构，定义组件，并设计数据库 ）

三、UML 相关

（一）什么是 UML

• 定义：统一建模语言，是描述、构造和文档化系统制品的可视化语言

四、建模（model）的意义

（一）为什么要建模

• Helps us to visualize a system.（帮助我们可视化我们的系统 ）
• Permits us to specify the structure or behavior of a system.（允许我们制定系统的结构和行为 ）
• Gives us a template that guides us in constructing a system.（给我们了一个构造系统的模板 ）
• Documents the decisions we have made.（记录了我们所下的决定 ）

五、对象相关概念

（一）对象

• 定义：是一个具有明确界限，并封装了状态和行为的统一体

（二）状态

• 包含：属性、关联

（三）行为

• 包含：操作（函数）、方法、状态机

CH2 迭代、进化和敏捷（Iterative, Evolutionary, and Agile）

一、RUP（Rational Unified Process）统一过程

（一）什么是 UP

• UP 是迭代（Iterative）过程
• 优点：

• • UP 实践（practices）提供了如何实施 OOA/D 的示范结构
  • UP 具有灵活性，可应用于轻量级（lightweight）和敏捷（Agile）方法

（二）什么不是 UP

• 瀑布生命周期（Waterfall Lifecycle）：试图在编程之前定义所有或大部分需求
• Freeze requirements at the start of a project to provide stability（项目开始时冻结需求以提供稳定性 ）

（三）迭代（Iterative）

• 开发被组织成一系列固定的「短期」小项目
• 迭代和增量/进化式开发（Iterative and incremental/evolutionary development）：随着一次次迭代的递进，系统增量式地发展

二、UP 四阶段

（一）初始（Inception）

• 不是需求分析，而是可行性分析
• 预见项目的范围、设想和业务案例（approximate vision, business case, scope, vague estimates ）
• 时长：一周之内

（二）细化（Elaboration）

• 不是需求分析或设计过程，而是迭代式实现核心体系结构，缓解高风险问题
• 内容：refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates.

直到迭代的结束点

（三）构造（Construction）

• 实现遗留下来的风险较低和比较容易的元素，准备部署
• 内容：iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.

（四）移交（Transition）

• 测试、部署

三、UP 六最佳实践

1. 迭代开发（Develop Iteratively）
2. 需求管理（Manage Requirements）
3. 基于构件的体系结构（Use Component Architectures）
4. 可视化软件建模（Model Visually (UML)）
5. 验证软件质量（Continuously Verify Quality）
6. 控制软件变更（Manage Change）

四、UP 的科目（discipline）

（一）组成

• 活动 + 制品（artifact）

（二）部分科目

1. 业务建模（Business Modeling）：领域模型 （不是软件类，是一个对象，对应着现实生活中的某个实体或者对象）
2. 需求：

• • 用例模型
  • 设想（glossary）
  • 补充性规格说明（Supplementary Specification）
  • 词汇表（Glossary）

1. 设计：

• • 设计模型
  • 软件架构文档
  • 数据模型

1. 实现：实现模型

（三）与迭代的关系

• 一次迭代会跨越大部分或全部科目
• 早期的迭代有更多的需求、设计

CH5 进化式需求

CH6 用例（Use - case）知识梳理

一、基础定义与术语

（一）定义

用例是文本形式的情节描述，由一组相关的成功和失败场景集合构成 ，用于描述 actor（参与者）使用系统某项功能时，所进行的交互过程的文字序列。

（二）关键术语

• 参与者（Actor）：与系统交互的外部实体（如用户、其他系统等 ）。
• 场景（Scenario）：用例的实例，聚焦参与者与系统间一系列特定活动和交互（Interactions ）。
• 用例模型：所有书面用例的集合，是对系统功能性和环境的建模。

二、用例的表示法

表示法：

（一）摘要与非正式格式

摘要：

非正式

（二）详述

• 范围[Scope]：明确用例所属的系统边界或模块。
• 级别[Level]：分为用户目标级、子功能级，定义用例粒度。
• 主要参与者[Primary Actor]：核心交互的参与者（驱动用例执行 ）。
• 涉众及其关注点[Stakeholders and Interests]：列出关注该用例的角色，及他们的需求/利益点。
• 前置条件[Preconditions]：用例执行前需满足的条件。
• 成功保证[Success Guarantee]（后置条件 ）：用例执行成功后，系统需达成的状态。
• 主成功场景

• • 理想的成功场景
  • 场景记录的三种步骤

• • • 参与者之间的交互
    • 确认过程（通常由系统来完成）
    • 系统完成的状态变更

（三） 扩展（Extensions）

处理主成功场景的分支逻辑，包含：

• 扩展条件：主流程中可能触发分支的条件（如“大多数步骤都可能发生的扩展条件” ）。

• 序号标记：扩展分支通过序号关联主场景（如“第一个描述条件及相应的扩展被标记为 3a” ），示例：“3.收银员输入商品条码” 。

三、用例的补充要素

（一）其他属性

• Special Requirements（特殊需求 ）：非功能性需求（如性能、安全约束 ）。
• Technology and Data Variations[变元] List（技术与数据变体列表 ）：记录用例执行中，技术实现或数据输入的可变情况。
• 出现频率[Frequency of Occurrence]：用例被触发的频率（辅助优先级、资源规划 ）。
• 未决问题[Miscellaneous]：记录用例设计中暂未解决的疑问、待确认点。

（二）用例的适用性判定

题目观点：“Use case are an object oriented way to handle requirement. Therefore they don’t fit very well into non - object oriented projects.（用例是面向对象处理需求的方式，因此不太适配非面向对象项目 ）”
判定结果：F（错误） —— 虽用例源于面向对象方法，但核心思想（场景化需求描述 ）也可灵活适配非面向对象项目，通过调整表达形式，同样能梳理需求逻辑。

总结：CH6 围绕用例的定义、结构（含主场景、扩展 ）、补充要素展开，核心是用场景化文本清晰描述系统需求，同时需注意用例在不同项目类型中的灵活应用 。

一个例题

一、CH7 其他需求

（一）补充（Supplementary）规约 vs 用例规约

• 补充（Supplementary）规约：对应非功能性需求，如性能、安全、兼容性等约束
• 用例规约：对应功能性需求，描述系统具体功能交互

二、CH8 迭代——基础

（一）需求和重点

• 是 OOA/D（面向对象分析与设计 ）技术的核心
• 迭代开发特点：

• • 并非一次就实现（Implement）所有需求
  • 对同一用例进行增量式开发（Incremental Development）：在多个迭代中逐步完善功能

三、CH9 领域（domain）模型

（一）定义

• 对领域内的概念类或现实世界中对象的可视化表示
• 是没有操作的类图（聚焦概念、关联，暂不涉及行为 ）

（二）内容

• 概念类：领域内抽象的概念实体
• 类的关联和属性：描述概念类之间的关系，及类自身的特征

CH10-CH12 内容整理

一、CH10 系统顺序图（SSD）

• 核心任务：讨论系统相关的输入和输出事件
• 形式：通过可视化图表（顺序图 ）呈现系统与外部参与者的交互流程（因图中图表细节难完整提取，聚焦文字逻辑 ）

朋友，这里出现的所有图几乎都是考试重点，看看吧

二、CH11 操作契约（Contracts）

（一）内容构成

1. 操作[Operation]：含名称 & 参数，定义操作的标识与输入信息
2. 交叉引用[Cross References]：关联会发生此操作的用例，明确操作的需求来源
3. 前置条件[Preconditions]：操作执行前需满足的系统状态、外部条件
4. 后置条件[Postconditions]：操作执行后，系统必须达成的状态（最重要，体现操作对系统的改变 ）

（二）通俗理解

• 本质：回答 “who do what”（谁执行操作、做什么 ），通过前后置条件约束操作逻辑
• 系统操作：系统在公共接口提供的操作（对外暴露的功能入口 ）

三、CH12 从需求到设计——迭代进化

（一）核心思想

• 尽早引发变更：在迭代早期暴露需求、设计问题，以便后期目标更稳定
• 高效分析建模：完成所有分析和建模工作不需要几个星期，强调迭代式、渐进式推进（契合敏捷开发理念 ）

CH13、CH15-CH16 内容整理

一、CH13 逻辑架构（Logical Architecture，LA）和 UML 包图

（一）逻辑架构核心要点

• 定义：

• • 是软件类的宏观（large - scale）组织结构，将软件类组织为包、子系统、层等。

• 层的职责与通信：

• • 对类、包或子系统进行粗粒度（coarse - grained）分组。
  • 职责：对系统主要方面进行内聚（cohesive）划分。
  • 通信：较高层可以调用较低层的服务，体现分层架构的依赖关系。

• OO 系统常包含的层：

• • 用户界面层
  • 应用逻辑和领域对象层
  • 技术服务层

二、CH15 UML 交互（Interaction）图

（一）作用与分类

• 作用：用于动态对象建模，聚焦对象间的交互行为。
• 分类：

朋友朋友，这两个图很重要，自己翻开CH15看几个例子 o.0

• • 顺序图（sequence diagram）：表现类之间的合作（collaborate），通过时间顺序展示对象交互流程。
  • 通信图（communication diagram）：强调对象间的通信关系，以拓扑结构呈现交互。

三、CH16 UML 类图

（一）类元（classifier）

• 定义：是对众多 UML 元素（类、接口、用例等 ）的泛化（generalization），抽象描述元素的共性。

（二）构造相关概念

• 构造型（Stereotype）：

• • 表示对现有建模概念的精化，使用符号 “« »” 表示（如 «authorship» ）。
  • 可应用到许多 UML 元素中，扩展 UML 语义。

• 简档（Profile）：一组相关构造型、约束、标记的集合，用于定制 UML 以适配特定领域需求。
• 标记（tag）：构造型、简档中用于补充元数据的标识，丰富模型信息。

CH17 GRASP（基于职责设计对象）知识梳理

GRASP 是面向对象设计中 分配职责 的核心模式集合，用于指导“如何合理将职责（如创建、行为、数据处理等 ）分配给类/对象”，以下按思维导图拆解：

重点重点重点章

一、创建者（Creator）

（一）核心问题

• 需求：决定“谁创建 A？”（即哪个类负责创建另一个类的实例 ）

（二）分配条件（满足其一即可，越多越优先 ）

若以下条件为真，将创建 A 实例的职责分配给 B：

• B 包含 / 组成了 A（如“订单类”包含“订单项类”，则订单类可创建订单项 ）。
• B 记录 A（如“日志类”记录“操作记录类”，日志类可创建操作记录 ）。
• B 紧密地使用 A（高频交互，如“购物车类”频繁操作“商品类”，购物车可创建商品 ）。
• B 拥有 A 的初始化数据（创建 A 所需的初始信息在 B 中 ）。

二、信息专家（Information Expert）

（一）核心原则

• 对象设计和职责分配的基本准则：
  将职责分配给具有履行该职责所需信息的类（即“谁最懂这件事，就交给谁做” ）。

（二）示例

• 计算订单总价：订单类（包含商品列表、单价、数量等信息 ）负责计算，因它掌握所有必要数据。

三、低耦合（Low Coupling）

（一）目标

• 减少因变化产生的影响（一个类的修改，尽量少牵连其他类 ）。

（二）优点

• 降低维护成本（修改时无需大量改动关联类 ）。
• 易于单独理解（类的职责清晰，依赖少 ）。
• 有利于复用（低依赖的类，可独立复用到其他场景 ）。

四、控制器（Controller）

（一）功能

• 对输入系统的事件进行响应（如用户操作、外部系统调用 ）。

（二）定位

• 是 UI 层之上第一个接受控制的系统操作对象（作为“入口”协调业务逻辑，解耦 UI 与领域逻辑 ）。

系统内部不应该显示调用UI层对象，应该通过控制层作为中介

五、高内聚（High Cohesion）

（一）目标

• 使对象有重点、可理解、可管理，同时支持低耦合（内聚高 → 职责集中；耦合低 → 依赖少 ）。

六、多态性（Polymorphism）

（一）适用情境

• 行为基于类型而变化（不同子类需重写父类行为 ）。

（二）职责分配

• 将行为职责分配给行为所变化的类型（即让子类自己实现个性化行为 ）。

（三）优点

• 易于增加新变化所需的扩展（新增子类时，直接重写行为即可，无需修改上层逻辑 ）。

七、纯虚构（Pure Fabrication）

（一）解决问题

• 当遵循“高内聚、低耦合”或其他模式会产生矛盾时（如核心领域类因职责过多变得臃肿 ），需引入“纯虚构”类。

（二）职责分配

• 将一组高内聚的职责，分配给人为创建的、不直接对应领域概念的类（即“纯虚构”类，专注处理特定逻辑 ）。

（三）优点

• 保持高内聚、低耦合（让领域类职责更纯粹，虚构类聚焦辅助逻辑 ）。

例如Sale类需要操作销售数据库，但是操作数据库需要进行很多复杂的配置，很多与核心类职责无关的代码，但是按照信息专家等又按道理就是此类进行操作，此时我们纯虚构一个对象来对销售数据库进行操作（起始就是SaleDao层）这样就是一种纯虚构

八、间接性（Indirection）

（一）目标

• 避免直接耦合（减少类之间的直接依赖 ）。

（二）职责分配

• 将职责分配给中介对象，通过中介间接交互，避免类与类直接关联。

（三）优点

• 降低耦合（依赖中介，而非直接依赖多个类 ）。

九、防止变异（Protected Variations）

（一）解决问题

• 如何设计对象，使“变化/不稳定部分”不会对“其他元素”产生不良影响？

（二）职责分配

• 预测变化或不稳定之处，分配职责以“在这些变化之外创建稳定接口”（如通过抽象类/接口隔离变化 ）。

（三）优点

• 易于增加新变化所需的扩展（变化被隔离在接口实现中 ）。
• 可引入新实现而不影响客户端（客户端依赖稳定接口 ）。
• 低耦合（变化部分与其他模块解耦 ）。
• 降低变化的成本或影响（修改仅需改动实现类，不影响调用逻辑 ）。

总结：GRASP 模式围绕“职责分配”展开，通过 9 种模式从不同角度（创建、行为、耦合、内聚等 ）指导设计，让类的职责更清晰、系统更易维护和扩展，是面向对象设计的核心方法论 。

CH18-CH20 内容整理

一、CH18 用例实现与 UML 状态机图

（一）18.1 用例实现

• 聚焦某个用例基于协作（collaborating）对象，如何在设计模型中实现（即从需求到设计的映射 ）。

（二）UML 状态机图核心元素

• 事件（event）：触发状态变化的外部/内部信号。
• 状态（state）：对象在生命周期中的某个阶段（如“订单”的“未支付”“已支付” ）。
• 转换（transition）：状态之间的转移（如“未支付”→“已支付” ）。

二、CH19 对可见性（Visibility）进行设计

（一）可见性定义

• 对象“看到或引用（reference）其他对象的能力”，决定类之间的交互范围。

（二）A 到 B 的可见性类型

1. 属性可见性：B 是 A 的属性 → 相对持久（permanent）。
2. 参数（parameter）可见性：B 是 A 中方法的参数 → 相对暂时（temporary）。
3. 局部可见性：B 是 A 中方法的局部对象 → 作用域仅限方法内。
4. 全局可见性：B 具有某种全局可见性（如单例对象、全局变量 ）。

三、CH20 设计到代码（design - to - code）

（一）20.8 实现的顺序（按耦合度从低到高 ）

• 耦合度低的先实现：依赖少的模块/类优先开发，减少阻塞。
• 被依赖的先实现（拓扑）：遵循“依赖倒置”，基础、被依赖的组件先完成（如框架、工具类 ），再实现上层业务逻辑。

总结：CH18 衔接用例与设计模型，通过状态机图管理对象行为；CH19 聚焦类之间的可见性设计，控制交互范围；CH20 指导从设计到代码的落地顺序，按耦合度和依赖关系规划实现流程 。

CH21 重构（Refactoring）知识梳理

CH21 围绕代码重构展开，核心是通过“处理坏味代码”和“设计复用”，优化代码质量与可维护性，以下拆解：

一、处理坏味代码（Code Smell）

（一）重构样例（常见优化手段 ）

1. 提炼（Extract）方法：

• • 场景：一段代码逻辑重复、功能内聚 → 提取为独立方法，增强可读性与复用性。
  • 作用：解耦复杂逻辑，让主流程更清晰。

1. 提炼常量（Constant）：

• • 场景：代码中存在硬编码的魔法值（如固定字符串、数字 ）→ 提取为命名常量。
  • 作用：统一管理可变值，修改时只需改常量定义，避免遗漏。

1. 引入解释变量：

• • 场景：复杂表达式难以理解（如嵌套运算、长条件 ）→ 用变量分步存储中间结果，命名解释逻辑。
  • 作用：让代码意图更明确，调试更便捷。

1. 使用工厂方法代替构造器调用：

• • 场景：对象创建逻辑复杂（如需初始化多参数、依赖其他服务 ）→ 用工厂类/方法封装创建过程。
  • 作用：解耦对象创建与使用，集中管理复杂初始化，符合“单一职责”。

二、为复用设计（Design for Reuse）

（一）复用策略

1. A 策略：

• • 内容：Define a persistence framework that provides services for persisting objects.（定义持久化框架，提供对象持久化服务 ）。
  • 思路：通过框架封装通用功能（如数据库存储、缓存 ），让业务代码聚焦领域逻辑，复用框架能力。

1. B 策略：

• • 内容：Use design patterns, wherein complete solutions are already defined.（使用设计模式，复用已验证的完整解决方案 ）。
  • 思路：利用单例、工厂、观察者等设计模式，复用成熟的设计思路，解决共性问题（如对象创建、解耦交互 ）。

CH26 GoF设计模式梳理（迭代2）

一、适配器（Adapter）

（一）核心信息

• 目的：解决不相容的接口问题
• 定义：通过中介适配器对象，将构件的原有接口转换为其他接口
• 与GRASP原则的联系：实现「多态」、「间接性」、「纯虚构」，进而支持「低耦合」、「高内聚」，支持「防止变异」
• 与其他GoF设计模式的联系：是一种「外观」

二、工厂（Factory）

（一）核心信息

• 问题：当有特殊考虑（例如存在复杂创建逻辑、为了改良内聚而分离创建职责等）时，应该由谁来负责创建对象？
• 答案：创建称为工厂的纯虚构对象来处理这些创建职责
• 与GRASP原则的联系：是「创建者」、「纯虚构」对象，确保「高内聚」
• 与其他GoF设计模式的联系：通常用「单实例」来访问

三、单实例类（Singleton）

（一）核心信息

• 问题：只有唯一实例的类即为“单实例类”
• 答案：对类定义静态方法用以返回单实例
• 与其他GoF设计模式的联系：通常运用于「工厂」、「外观」

四、策略（Strategy）

（一）核心信息

• 目的：如何设计变化但相关的算法/政策？如何让算法/政策可变更？
• 答案：在单独的类中定义每种算法/政策/策略，使其具有共同接口
• 特性：Strategy pattern allow one of a family of algorithms to be selected on-the-fly at runtime.（运行时动态选择算法 ）
• 与GRASP原则的联系：基于「多态」，为变化的算法提供「防止变异」
• 创建方式：通常由「工厂」创建

五、组合（Composition）

（一）核心信息

• 问题：如何像处理原子对象一样，处理一组对象或组合结构的对象？
• 答案：定义组合和原子对象的类，使它们实现相同的接口
• 与GRASP原则的联系：基于「多态」，提供「防止变异」
• 协同模式：常与「策略」模式一起使用

六、外观（Facade）

（一）核心信息

• 问题：对一组不同实现/接口需公共统一接口，或子系统易与其他模块耦合、实现易变时如何处理？
• 答案：对子系统定义唯一接触点（外观对象 ），封装子系统，提供统一接口并协作
• 通俗理解：将子系统隐藏在一个对象之后
• 与GRASP原则的联系：提供「防止变异」，通过增加「间接性」对象，支持「低耦合」
• 与其他GoF设计模式的联系：包含「适配器」，通常用「单实例」来访问

七、观察者（Observer）

（一）核心信息

• 问题：不同类型的订阅者对象关注于发布者对象的状态变化或事件，并且想要在发布者产生事件时以自己独特的方式作出反应。此外，发布者想要保持与订阅者的低耦合。如何对此进行设计呢？
• 答案：发布者只通过接口感知订阅者，订阅者可动态注册/取消注册，由订阅者实现响应逻辑
• 与GRASP原则的联系：

• • 基于「多态」
  • 在对象通信上提供「低耦合」（发布者依赖接口，不依赖具体订阅者 ）
  • 对发布者提供「防止变异」（新增订阅者无需修改发布者 ）

• 典型应用：
  题目需求：报告生成模块需「新数据生成时自动刷新UI展示最大值」+「支持多视图类型」
  最佳方案：Establish subscribe/notify mechanism between the view and model layers so that the views get notified of the change.（在视图与模型层间建立订阅/通知机制，让视图感知变化 ）

以下是对这两张思维导图内容的整理，分模块呈现核心信息：

一、CH39 N + 1 view model（迭代3）

（一）起源与核心

从 4 + 1 视图演变而来，通过不同视图面向不同角色，呈现系统多维度信息。

（二）各视图详解

视图类型	面向角色	核心展示内容	通俗说明
用例视图（+1）	终端用户（End - user）	系统功能（Functionality）	让用户直观看到系统能做什么
逻辑视图	设计者（Designers）	系统架构结构（Structure）	给设计师看系统“骨架”怎么搭
进程视图	系统整合者（System integrators）	性能（Performance）、可扩展性（Scalability）、吞吐量（Throughput）	帮整合者评估系统运行能力
实现视图	编程者（Programmers）	软件管理（Software management）	给程序员看代码组织、模块分工
部署视图	系统工程师（System engineering）	系统拓扑（System topology）、交付（Delivery）、安装（Installation）、通信（communication）	指导系统工程师搭建运行环境

额外补充

relationships（关系梳理）

（一）类图之间的关系

关系类型	含义与示例
依赖（Dependency）	构造另一对象实例 / 依赖其提供的服务
联合（Association） - 聚合（Aggregation）	is a part - of 关系，如“车 & 轮子”（车包含轮子，轮子可独立存在）
联合（Association） - 组合（Composition）	比聚合更强的“整体 - 部分”关系，如“AB & A、B”（A、B 是 AB 不可分割的部分 ）
泛化（Generalization）	即继承关系，体现“一般 - 特殊”层次

（二）用例之间的关系

关系类型	图示与说明
包括（Include）	一个用例“包含”另一个用例的基础行为（如“执行查询”包含“导出查询结果” ）
延伸（Extend）	对基础用例的扩展，在特定条件下触发额外行为（如“请假审批”延伸出“紧急请假特殊流程” ）
泛化（Generalization）	用例间的“继承”，子用例继承父用例行为并可扩展（如“审批”泛化出“工资调整审批”“请假审批” ）

包括

延申

泛化

其实除了箭头和边有些不同我也看不出有什么不同