UML核心元素

版型就是类型

业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都客观存在。系统范围是指软件将要实现的那些对应于业务功能的系统功能。

参与者 actor

在系统之外与系统交互的某人或某事物。也叫主角。

l  要找参与者，首先要确定边界。

l  确定参与者两个问题

1. 谁对系统有着明确的目标和要求，并且主动发出动作？

2. 系统为谁服务？

l  参与者可以是非人，但一定要有一个参与者。

l  业务主角（business actor）:参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。业务主角针对业务人员而非计算机用户，查找业务主角必须抛开计算机。

l  业务工人（business worker）:参与业务的执行过程，但位于系统边界以内，目标是完成参与者（或叫主角）的业务目标。区分参与者和业务工人要看系统边界之外还是之内。

l  涉众（Stakeholder）:是与要建设的这个系统有利益相关的一切人和事。涉众的利益要求会影响系统建设。参与者是涉众的代表。

l  用户（user）是系统操作员，用户是参与者的代表。

l  角色（role）是参与者的职责，一个用户可以有多个角色。

用例 Use case

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

l  用例场景 (use case scenario):做一件事情可以有很多不同的办法和步骤，也可能遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中称为用例场景。一个场景就是用例的一个实例。

l  用例前置条件：启动用例的前提。用例的后置条件：用例执行完了的结果。

l  完整的用例定义：包括参与者，前置条件，场景和后置条件：

l  用例理解：煮饭是个用例，煮饭的不同做法即用例场景，米是煮饭的前置条件，米饭是用例的后置条件。

l  用例特征（可用于判定用例）

1. 用例是相对独立的。

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

3. 用例必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。

4. 用例必然是以动宾短语形式出现。

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

l  用例粒度：在项目过程中，不同的阶段使用不同的粒度。在业务建模阶段，一个用例可以描述一项完整的业务流程；在分析阶段（概念建模），用例的粒度以每个用例能描述一个完整的事件流为宜，即一个用例描述一项完整业务中的一个步骤；在系统建模（设计模型）阶段，用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。

在同一个需求阶段，所有的用例粒度必须是同一个量级的。

l  用例获得：1.发现参与者，确定系统边界。2.跟客户代表谈，了解参与者的期望，目标，完后总结。

l  误区：

1. 用例不是功能的划分和描述，功能不是UML术语，功能是从开发者角度出发的，而用例是从客户角度出发的。

2. 步骤不是用例，因为步骤不能完整的反应参与者的目标。

---------------------------

业务用例 business use case

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

业务用例面对的问题领域是没有将来的计算机系统参与的，目前客观存在的业务领域。参与者是业务主角，站在业务主角的立场上看到的边界是业务边界而不是系统边界。

----------------------------

业务用例实现 business use case realization

即业务用例的一种实现方式。一个业务用例可以有多种实现方式。

业务用例实现是用例的一种版型，专门用于需求建模阶段的业务建模。

例子：电话使用者交电话费–业务用例；通过不同方式交 ---不同的业务用例实现。

-----------------------------

概念用例

概念用例用于概念建模，概念用例用来获取业务用例中的核心业务逻辑，这些核心业务逻辑揭示了业务模式。

-----------------------------

系统用例 =用例

系统用例是软件系统开发的全部范围，是我们得到的最终需求。

------------------------------

用例实现

一个用例实现代表了用例的一种实现方式。

边界

边界决定了视界，决定了抽象层次。

能否准确的把我边界，能否灵活的变换边界，能否控制边界的粒度是做好需求分析和系统设计的关键。

业务实体

业务实体代表了业务角色执行业务用例时所处理或使用的“事物”。即对用例有价值的事物。

l  一般而言，一个好的业务实体不包含关于其使用主体和使用方法。

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

l  例如饭店中的业务实体有菜单和饮料。

l  业务实体的理解：

1. 业务实体来自现实世界。

2. 业务实体一定在分析业务流程的过程中发现的。

3. 业务实体作为类的一个版型，具有对象的所有性质，包括属性和方法

l  业务实体的属性

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

一般如果只有一个对象可以直接使用这个属性，或者只能通过对象才能访问这个属性，那么它就当做一个属性存在，否则应该把它单独建模成一个业务实体。比如地址只能是属性，而邮票需要单独建模。

l  业务实体的方法

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

l  寻找业务实体的方法

先建业务用例场景，然后分析动词后边的名词，即业务实体备选对象，最后根据对象对业务目标是否有贡献这一筛选条件从备选列表中挑出符合的对象。

包

包是一种容器，用来分类，形成逻辑单元的。

l  包可以容纳任何UML元素， 包之间的关系定义只有依赖关系。

l  分包原则：

1. 被分入同一个包中的那些元素应该相互紧密，甚至不可分割。同时这些元素又具有相同的性质，使得包可以抽象出一些接口来代表包内事物与包外事物交互。

2. 包最理想的情况是修改任意一个包，其它包不受影响。

3. 如果难以做到完全解除依赖关系，至少应该保证包之间的依赖关系不会被传递。

4. 包之间的依赖关系应该是单向的，尽量避免双向依赖和循环依赖。

l  包的版型：领域包，子系统，组织结构，层和自定义包。

分析类

分析类用于获取系统中主要的“职责族”，它们代表了系统的原型类，是系统必须处理的主要抽象概念的第一个关口。分析类包括边界类，控制类和实体类，它们都是类的版型。

边界类（boundary）

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

边界类的常用场景：

1. 参与者与用例之间应该建立边界类。

2. 用例与用例之间交互，应该建立边界类。

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

4. 在相关联的业务对象有明显的独立需求，即他们可能在各自的领域内发展和变化，但又希望互不影响时，应为他们建立边界类。

控制类（control）

控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通常控制其他对象，因此他们的行为具有协调性质。

UML定义中，控制类主要起协调对象的作用，列如从边界类通过控制类访问实体类，或者实体类通过控制类访问另一个实体类。

实体类（entity）

实体类是用于对必须存储的信息和相关行为建模的类。实体对象（实体类的实例）用于保存和更新一些现象的有关信息。实体类通常是永久性的，他们所具有的属性和关系是长期需要的。

分析类的三高

1. 高于设计实现 2.高于语言实现 3. 高于实现方式

设计类

即对应到编程语言中的类。设计类是系统实施中的一个或多个对象的抽象；设计类所对应的对象取决于实施语言。设计类用于设计模型中，它直接使用与编程语言相同的语言来描述。

UML中设计类的定义：设计类由类型，属性和方法构成。设计类的名称属性和方法直接映射到编码中相应的class, property和method.

类（class）

类说明了对象是什么，同时也就决定了对象拥有什么属性方法。在C++中类 就是一个class.

属性（property）

是对象特征，属性同时表明了对象的唯一性。只有对象单独具有的特征才能建模为属性。

方法（method）

访问对象或影响其他对象的属性或关系的唯一途径就是方法。

关系

即对象之间的关系

关联关系：

即A和B都相互知道对方的存在。在最终的代码里，关联对象通常是以实例变量（成员变量）的形式实现的。

关联关系是一种静态关系，通常与运行状态无关。

单向关联：， A知道B，而B不知道A。

依赖关系：

描述一个对象在运行期会使用到另一个对象的关系。它是一种临时性的关系，通常是在运行期产生，且随着运行场景不同，依赖关系也可能发生变化。

一般而言，依赖关系在最终代码里体现为类构造方法，类方法等的传入参数。

也有双向依赖，但那是非常不好的结构。

扩展关系：

特别用于在用例模型中说明向基本用例中的某个扩展点插入扩展用例（比如通话时保留通话就是一个扩展用例）。

扩展关系表示的是可选，而不是必须。

包含关系：

（A包含B）

特别用于用例模型，说明在执行基本用例的用例实例过程中插入的行为段。

包含用例是必须而不是可选。没有基本用例，包含用例是不能单独存在的（比如核对账号是取钱转账等基本用例的包含用例）。

实现关系：

特别用于用例模型中连接用例和用例实现，说明基本用例的一个实现方式。

精化关系：

（A精化了B）

特别用于用例建模，一个基本的用例可以分解出许多更小的关键精化用例，这些更小的精化用例更细致的展示了基本用例的核心业务。

泛化关系(继承关系)：

表示一个类对另一个类的继承。

聚合关系：

（B由A组成）

表示整体由部分构成的语义。整体不存在了，部分仍然存在。

例如部门由许多人员构成。

组合关系：

（B由A构成）

整体拥有部分的语义。整体不存在了，部分也将消亡。

例如母公司拥有许多子公司。

组件

组件是系统中实际存在的可更换部分，它实现特定的功能，符合一套接口标准并实现一组接口。一个组件应当具有完备性，独立性，逻辑性和透明性。

节点

节点带有至少一个处理器，内存以及可能还带有其他设备的处理元素。在实际工作中，一般说来服务器，工作站或者客户机都可以称为一个节点。

节点的应用场合：

分布式应用环境和多设备应用环境。