UML核心元素

3.1 版型

类型、构造型

“接口”、“边界类”、“实体类”、“控制类”等都是类的版型，甚至“参与者”本身也是一个特殊的类的版型。

参与者

以人为本

3.2.1 基本概念

参与者在建模过程中是处于核心地位的。

UML官方文档定义：actor是在系统之外与系统交互的某人或某事物。

3.2.1.1 参与者位于边界之外

3.2.1.2 参与者可以非人

3.2.2 发现参与者

注意区分参与者与业务工人

3.2.3 业务主角

业务主角是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。

完全彻底地高清粗客户的业务，而不是预先假设已经有了一个计算机系统，再让客户假想需要计算机系统帮他们做什么。

3.2.4 业务工人

• 他是主动向系统发出动作的吗？

• 他有完整的业务目标吗？

• 系统是为他服务的吗？

3.2.5 参与者与涉众的关系

涉众（stakeholder）也称为干系人。

参与者是涉众代表。

3.2.6 参与者与用户的关系

用户（user）是指系统的使用者，通俗一点说就是系统的操作员。用户是参与者的代表，或者说是参与者的实例或代理。

3.2.7 参与者与角色的关系

角色（role）是参与者的职责。

3.2.8 参与者的核心地位

系统是以参与者的观点来决定的。

3.2.9 检查点

• 您是否已找到所有的参与者？

• 每个参与者是否至少涉及到一个用例？

• 您能否列出至少两名可以作为特定参与者的人员？

• 是否由参与者担任与系统相关的相似角色？

• 是否有两个参与者担任与用例相关的同一角色？

• 特定的参与者是否将以几种（完全不同的）方式使用系统？

• 参与者是否有直观名称和描述名称？

3.3 用例

用例是UML建模中最重要的一个元素。其他元素都是“封装”、独立”的

3.3.1 基本概念

用例是一种把现实世界的需求捕获下来的方法。

官方文档定义：用例定义了一组用例实例，其中每一个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。

一个用例就是与参与者交互的。

一个场景就是一个用例的实例。

3.3.2 用例的特征

• 用例是相对独立的。

• 用例的执行结果对参与者来说是可观测的和有意义的。

• 这件事必须由一个参与者发起。

• 用例必然是以动宾短语形式出现的。

• 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元甚至部署单元。

3.3.3 用例的粒度

原则：同一个需求阶段，所有用例的粒度应该是同一个量级的。

粒度选择问题本质是因为边界认定不同而产生的。

3.3.4 用例的获得

• 主角是位于系统边界外的。

• 主角对系统有着明确的期望和回报要求。

• 主角的期望和回报要求在系统边界之内。

3.3.5 用例和功能的误区

用例 != 功能

3.3.6 目标和步骤的误区

两个用例大小不同，边界不同，参与者也不同，它们显然不应该同时出现在同一个视图里。

3.3.7 用例粒度的误区

产生用例粒度错误的原因首先是分不清目标和步骤。

3.3.8 业务用例

业务用例（bussiness use case）是用例版型中的一种，专门用于需求阶段的业务建模。

3.3.9 业务用例实现

（bussiness use case realization），也称业务用例实例。专门用于需求阶段的业务建模。

3.3.10 概念用例

概念模型中的核心元素。

3.3.11 系统用例

用来定义系统范围，获取功能性需求的。

• 业务用例：业务视角

• 系统用例：系统视角

3.3.12 用例实现

用例实现是连接起用例模型和系统实现之间的桥梁。

3.4 边界

边界本质上是面向对象方法的一个很重要的概念，与封装的概念师出同源。

3.4.1 边界决定视界

边界是可大可小的，由建模者主管臆定。

3.4.2 边界决定抽象层次

分治，划分子问题。

3.4.3 灵活使用边界

边界是无形的，是一种分析方法。

用边界来决定抽象的层次和视角。

3.5 业务实体

业务实体是类的一种版型。特别用于业务建模阶段建立领域模型。

官方定义：业务实体代表业务角色执行业务用例时所处理或使用的“事务”。

3.5.1 业务实体的属性

属性是用来保存业务实体特征的一个记录，业务实体的属性集合决定了它的唯一性。

3.5.2 业务实体的方法

方法是访问一个业务实体的句柄，它规定了外部可以怎样来使用它。

3.5.3 获取业务实体

一个业务实体经常代表某个对多个业务用例或用例实例有价值的事务。

3.6 包

包是一种容器，如同文件夹一样，它将某些信息分类，形成逻辑单元。

使用包的目的是为了整合复杂的信息。

UML认为好的分包具有高内聚，低耦合的性质。

常见的包的版型：

• 领域包（domain package）

• 子系统（subsystem）

• 组织结构（organization unit）

• 层（layer）

3.7 分析类

分析类用于获取系统中主要的“职责簇”。

• 分析类是从功能性需求向计算机实现转化的“第一个关口”。

• 分析类可以产生系统的设计类和子系统。

分析类分为：边界类（boundary）、控制类（control）和实体类（entity）

3.7.1 边界类

边界类是一种对系统外部环境与其内部运作之间交互进行建模的类。

adapter？listener？controller？

• 参与者与用例之间应当建立边界类。前后端交互的controller接口

• 用例与用例之间如果有交互，应当为其建立边界类。退货->退款通过消息的listener交互

• 如果用例与系统边界之外的非人对象有交互，例如第三方系统，应当为其建立边界类。adapter

• 相关联的业务对象有明显的独立性要求，应当建立边界类。

3.7.2 控制类

控制类用于对一个或几个用例所特有的控制行为进行建模。

主要起到协调对象的作用。

3.7.3 实体类

用于对必须存储的信息和相关行为建模的类。

3.7.4 分析类的三高

• 高于设计实现

• 高于语言实现

• 高于实现方式

3.8 设计类

设计类是系统实施中一个或多个对象的抽象。

3.8.1 类

类对对象进行定义，而对象有实现（实施）用例。

对象是类实例化的结果。

3.8.2 属性

属性是对象的特征，表明了对象的唯一性。

3.8.3 方法

原则：一个对象的属性只应该由他自己的方法来改变。

3.8.4 可见性

• 共有

• 保护

• 私有

• 实施

3.9 关系

3.9.1 关联关系

无方向

3.9.2 依赖关系

3.9.3 扩展关系

抽象性质，表示了用例场景中的某个“支流”。

3.9.4 包含关系

3.9.5 实现关系

用例，用例实现

精化关系

用例实例，概念用例

泛化关系

不建议在用例中使用泛化关系。

3.9.8 聚合关系

整体和部分不是强依赖的

组合关系

强依赖的特殊聚合关系

3.10 组件

组件代表系统中的一部分物理实施。

UML中把组件定义为任何的逻辑代码快。

完备性、独立性、逻辑性和透明性

3.10.1 完备性

不需要多个组件来完成一个业务请求。

3.10.2 独立性

独立部署

3.10.3 逻辑性

3.10.4 透明性

3.10.5 使用组件

• 分布式应用

• 应用集成

• 第三方系统

• SOA 服务

3.11 节点

节点是带有至少一个处理器、内存以及可能还带有其他设备的处理元素。

应用程序的部署单元。

3.11.1 分布式应用环境

3.11.2 多设备应用环境