UML的核心元素

版型

uml每一个元模型都是一个版型，比如：业务用例，业务用例实现，边界类，控制类等。版型可以自定义。

参与者

参与者是系统之外与系统交互的某个人或者某个事物

1. 参与者位于边界之外
2. 参与者可以非人

找出参与者

帮助找出参与者的两个问题

1. 谁对系统有着明确的目标和要求并主动发出动作
2. 系统是为谁服务

案例截图

确定参与者的n个问题

1. 谁负责提供、使用或者删除信息？
2. 谁将使用此功能？
3. 谁对某个特定功能感兴趣？
4. 在组织中的什么地方使用系统？
5. 谁负责支持和维护系统？
6. 系统有哪些外部资源？
7. 其他还有哪些系统将需要与该系统进行交互？

参与者的版型

业务主角

1. 业务主角是客户实际业务里的参与者，没有计算机系统，没有抽象的计算机角色，必须在实际业务里能找到对应的岗位或人员
2. 业务人员而非计算机用户
3. 建立业务模型、查找业务用例都必须使用业务主角，而不是普通参与者

获得业务主角的n个问题

1. 业务主角的名称是否是客户的业务术语
2. 业务主角的职责是否在客户的岗位手册里有对应的定义
3. 业务主角的业务用例是否都是客户的业务术语
4. 客户是否对业务主角能顺利理解

业务工人

1. 业务工人是完成主角的业务目标
2. 被动参与业务(比如购票系统中的人工座席就是业务工人）

区分参与者还是业务工人的三个问题

1. 他是主动向系统发出动作的吗？
2. 他有完整的业务目标吗？
3. 系统是为他服务的吗？

用例

与参与者交互,并且给参与者提供可观测的有意义的结果的一系列活动的集合

构成

参与者 + 前置条件 + 场景 + 后置条件

用例的特征

1. 用例是相互独立的
2. 用例的执行结果对参与者是可观测的和有意义的
3. 不存在没有参与者的用例，这件事必须由一个参与者发起
4. 用例必然是以动宾短语形式出现
5. 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元。甚至部署单元

用例的粒度

1. 业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，用来描述一项完整的业务流程以帮助明确需求范围
2. 概念建模阶段（用例分析阶段）。用例的粒度以能描述一个完整的事件流为宜，用来描述一项完整业务中的一个步骤（使用面向对象的方法，归纳和抽象出关键概念模型并为之建模）
3. 系统建模阶段，用例的粒度以能描述操作者与计算机的一次完整交互为宜，用来描述一个操作界面或者一个页面流
4. 用例的粒度没有具体的标准，但是原则是同一个需求阶段，所有用例的粒度应该是同一个量级
5. 粒度选择的问题本质上是因为边界认定不同而产生的。

用例的获得

准备工作

1. 发现参与者，确定参与者的同时就确定了系统边界

2. 理解一下几个问题 2.1 主角是位于系统边界外的 2.2 主角对系统有着明确的期望和明确的回报要求 2.3 主角的期望和回报要求在系统边界之内

引导业务代表的n个问题

1. 你对系统有什么期望
2. 您打算在这个系统里做些什么事情
3. 您做这件事的目的是什么？
4. 您做完这件事希望有一个什么样的结果

业务访谈的目标

1. 从杂乱无章或者非专业描述的谈话中找出主角期望的真实和有效目标
2. 去伪存真，求同存异
3. 不同主角的目标可能会相互重叠，应当小心求证是否是某个完整目标的一个部分，对用例进行合并
4. 确保一个明确的有效目标才是一个用例的来源
5. 一个真实的目标应当完备的表达主角期望
6. 一个有效的目标应当在系统边界内，由主角发起，并有明确的后果
7. 重新访谈应该调整策略: 调整系统边界和主角；扩大或者缩小系统边界；变更主角。

最终系统边界内应该充满了主角的期望，将每一个有效期望用用例绘制出来，取名字完成用例获取的工作

用例的版型

业务用例

1. 用来描述客户现有业务，无计算机系统参与
2. 参加者是业务主角
3. 用来获取功能性业务， 用例是用例描述功能性需求

业务用例实现

1. 专门用于需求阶段的业务建模
2. 是业务用例的一种实现方式
3. 表达了同一项业务的不同实现，比如营业厅交费、预存话费和银行卡缴费的业务用例实现来实现交纳电话费业务用例
4. 根据业务用例实现得出关键业务对象

概念用例

1. 用于概念建模
2. 用来获取业务模型中的关键概念，用来获取业务用例中的核心业务逻辑
3. 业务用例到系统用例过渡时起到重要的指导

系统用例

1. 用来定义系统范围、获取功能性需求，即我们通常说的用例
2. 系统用例采用系统视角

用例实现

1. 系统用例的实现

边界

1. 边界决定视角，所以在建模过程中，如果对建模结果感到疑惑，就可以试着改变边界设定，得到不同的参与者和用例，在通过相互印证的方式得到更好的结果
2. 边界决定抽象层次， 可采用自顶向下或者自底向上的方式，缩小或者扩大边界
3. 灵活使用边界，实现需求的任务交给分析模型，将扩展能力交给框架设计。

业务实体

业务实体代表业务角色执行业务用例时所处理或使用的“事物“

用途

1. 类的一种版型，特别用于在业务建模阶段建立领域模型
2. 描述用什么来达到业务目标以及通过什么来纪录这个业务目标

特征

1. 业务实体是来自显示世界的
2. 业务实体一定是在分析业务流程的过程当中发现的，而业务流程实际上就是业务用例场景，必须至少被一个业务用例场景使用或者创建
3. 作为类的一个版型，具有对象的所有性质，包括属性和方案等

获得业务实体

1. 建立业务用例场景，业务用例场景是参与者实现其业务目标的过程描述（寄信人到邮局寄信的用例场景：寄信人到达邮局、购买信封， 写上地址，计算邮资，购买邮票、贴上邮票、邮寄信件、拿走回执）
2. 从业务用例场景中逐个分析动词后面的名词，作为业务实体的备选对象（邮局、信、信封、地址、邮资、信件、回执等）
3. 分析这些业务实体之间的关系，并决定哪些应当独立建模，哪些应当作为属性

包

作用和用同

容纳并为其他元素分类

分包的原则

1. 包应该具有高内聚的性质。如果将元素分成三个包 A、B、C。那么每个包的元素应当是相互联系紧密，且不可分割。同时又具有某些相同的性质，使得包可以抽象出一些接口来代表包内的事物和包外的事物交互，以避免包外的事物频繁直接访问包内元素。
2. 包之间应该无依赖关系或者松耦合关系，它们之间可以保持消息通信。修改一个包的元素，其他包的内容应该不受到影响
3. 无法完全解除包之间的依赖关系，至少保证包之间依赖关系不会传递。
4. 包之间的依赖关系应当是单向的，应当尽量避免双向依赖和循环依赖

包的版型

领域包

用于分类业务领域内的业务单元，每个包代表业务的一个领域

子系统

用于分类系统内的逻辑对象并形成子系统

组织结构

用于分类业务领域中的组织结构，可以直接用来表述企业的组织结构

层

用于分类软件中的层次、展示软件的架构信息

分析类

用于获取系统中主要的职责簇，带别系统的原型类，是系统必须处理的主要抽象概念的第一个关口

性质

1. 分析类代表系统中的主要职责簇，意味中分析类是从功能性需求像计算机实现转化过程中的第一个关口
2. 分析类可以产生系统的设计类和子系统，意味着计算机实现是可以通过某种途径产生出来的，而不是拍脑袋拍出来的

本质

分析类 = 边界类 + 控制类 + 实体类

版型

边界类

用于对系统外部环境与其内部运作之间的交互进行建模的类，这种交互包括转换事件并记录系统表示方式中的变更。

常用场景

1. 参与者与用例之间应当建立边界类（一组网页、一组windows窗口、一个字符终端、或者一个鼠标使用用例的功能）
2. 用例和用例之间如果有交互，应当为其建立边界类
3. 如果用例与系统边界之外的非人对象有交互，比如第三方系统，应当为其建立边界类
4. 在相关联的业务对象有明显的独立性要求，即它们可能在各自领域内发展和变化，但又希望互不影响，应当建立边界类

好的边界类的特点

1. 边界类应该有助于提供系统的可用性
2. 边界类应该尽可能地保持在较高的层次上
3. 边界类应该合理封装介于系统与主角之间的交互
4. 如果主角改变他们为系统提供输入的方式，边界类就应该是唯一需要改变的对象
5. 如果系统改变为主角提供输出的方式，边界类就应该是唯一需要改变的队形
6. 边界类必须知道其他对象类型的需求，以便它们能够得以实施，并相对于系统内部元素保持其可用性和有效性

控制类

用于对一个或几个用例所特有的控制行为建模，来源于对用例场景当中的动词的分析和定义，包括限制动词描述

指导原则

1. 认真考察用例场景中的行为，如果这些行为在执行步骤、执行要求或者执行结果上具有类似特征，应当适当抽象（合并或者抽取超类）
2. 认真考察用例场景中的行为，如果这些行为是否对要建设的系统产生影响而进行一些取舍。比如装入、写上、贴上是寄信人的人工行为，对系统无影响，因为可以舍去

实体类

用于对必须存储的信息和相关行为建模的类，来源于业务模型中的业务实体

设计类

系统实施中的一个或多个对象的抽象；直接映射到实现累吗，依赖于实施语言。由类型、属性和方法构成

关系

用来描述不同类的对象之间的结构关系，它在一段时间内将多个类的势力连接在一起

关联关系

描述不同类的对象之间的结构关系，表示某个对象一段时间内一直知道另一个对象的存在。与依赖关系不同的是，依赖关系通常表示两个实例的临时关联关系。

单向关联关系

依赖关系

描述一个对象的修改会导致另一个对象的修改这样的关系。与关联关系不同的是，依赖关系除了”知道“其他对象的存在，还会使用其他对象的属性或者方法

扩展关系

用于在用例模型中说明基本用例中的某个扩展点插入扩展用例。与包含关系不同的是，扩展表示的可选，而不是必需

使用扩展关系的理由

1. 表明用例的某一部分是可选的系统行为，这样可以将模型中的可选行为和必选行为分开
2. 表明只在特定的条件下才执行分支流，如触发警报
3. 表明可能有一组行为段，其中的一个或者多个段可以用基本用例的扩展点处插入，所插入的行为段将取决于在执行基本用例时与主角进行的交互
4. 表明多个基本用例中都有可能触发一个可选的分支流，扩展用例也代表了多个用例的可复用部分

包含关系

用于用例模型，说明执行基本用例的用例实现过程中插入的行为段，表示是必须的，没有这个包含用例，基本用例是不完整的。是不能单独存在的

使用包含关系的理由

1. 从基本用例中分解出这样的行为：它对于了解基本用例的主要目的并不是必须的，只有他的结果才比较重要
2. 分解出两个或者更多用例所共有的行为

实现关系

基本用例的一个实现方式，描述了用例实现与基本用例之间的关系

精化关系

用于用例模型，一个基本用例分解出许多更小的关键精化用例，这些精化用例更细致地展示了基本用例的核心业务。精化关系用来连接基本用例和精化用例，表示基本对象可分解为更为明确、精细的子对象

泛化关系

用于建模过程中的任意一个阶段，说明两个对象之间的继承关系

聚合关系

用于类图，用于实体对象之间的关系，表达整体由部分构成的语义。与组合关系不同的是，整体和部分不是强依赖的

组合关系

用于类图，用于表示实体对象的关系，表达整体拥有部分的语义，是一种强依赖的特殊聚合关系，整体不存在了，部分也将消亡

组件

是系统中实际存在的可更换的部分，实现特定的功能，符合一套接口标准并实现一组接口。组件代表胸痛中的一部分物理实施

特性

1. 完备性
2. 独立性
3. 逻辑性
4. 透明性

使用场景

1. 分布式应用
2. 应用集成
3. 第三方系统
4. SOA服务

节点

用于部署视图，描述应用程序在物理结构上是如何部署在应用环境中的，一种包括软、硬件环境在内的拓扑结构描述。至少一个处理器、内存以及可能还带有其他设备的处理元素。

使用场景

1. 分布式应用环境
2. 多设备应用环境

----------------------------------第一章：URL的核心元素 完结， 撒花-------------------------------