UML核心元素--读书笔记

1. 参与者：系统之外与系统交互，发起动作且为之服务。

• 业务主角 —— 参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。
• 业务工人 —— 系统之内
• 用户 —— 参与者的代表
• 角色 —— 参与者的职责

2. 用例：与参与者交互，并给参与者者提供可预测的有意义的结果的一系列活动的集合。注意三个建模阶段用例的粒度。

• 业务用例 —— 用例的一个版型，专门用于需求阶段，不能把计算机引用进来。
• 业务用例实现 —— 业务用例的一种实现方式，可以有多个实现方式。
• 概念用例 —— 少被采用，但推荐使用，用来获取业务用例中的核心业务逻辑。
• 系统用例 —— 通常说的用例，用来定义系统范围，获取功能性需求的。
• 用例实现 —— 代表用例的一种实现方式。

3. 边界

4. 业务实体 —— 类的一种版型。注意分析哪些作为业务实体的属性，哪些应单独建模。

5. 包 —— 高内聚低耦合。

6. 分析类 —— 从业务需求向系统设计转化过程中最为主要的元素，在高层次抽象出系统实现业务需求的原型。

• 边界类 —— 用于对系统外部环境与其内部运作之间的交互进行建模的类。
• 控制类 —— 源于对用例场景中行为的定义，建议在边界类与边界类、边界类与实体类、实体类与实体类之间默认加入控制类。
• 实体类 —— 源于业务模型中的业务实体。主要位于数据持久层。

7. 设计类 —— 系统实施中一个或多个对象的抽象，编程语言密切相关。

8. 关系

• 关联 —— 一个对象在一段时间“知道”另一个对象。如A保存了B的ID。
• 依赖 —— 一个对象的修改会导致另一个对象的修改。如A使用了B的属性或方法，B的修改会导致A的修改。
• 扩展 —— 表示 一个场景中的“支流”。如保持通话用例。
• 包含 —— 与扩展用例不同，它表示的是“必需”，而非“可选”
• 实现 —— 用不同方式实现基本用例的业务功能。
• 精化 —— 一个基本用例可以分解出更小的关键精化用例。
• 泛化 —— 两个对象之间有继承关系。
• 聚合 —— 表达整体与部分之间的关系，不是强依赖。
• 组合  —— 表达整体与部分之间的关系，是强依赖。

9. 组件

   使用组件的情形：分布式运用，应用集成，第三方系统，SOA服务

10. 节点

至少带一个处理器、内存以及其它处理设备的处理单元。

使用情形：分布式应用环境、多设备应用环境

总结：主谓宾