3.1 版型

版型（stereotype)，是对一个UML元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。

• uml中每个元模型都有很多版型，例如用例有业务用例、业务用例实现等版型，类有接口、边界类、实体类、控制类等版型。
• 版型也是可以自己定义的，例如包元素有子系统、组织结构、模块等默认版型

3.2 参与者

建模是从寻找抽象角度开始的，那么定义人，就是定义参与者，就是我们寻找抽象角度的开始。

基本概念

actor是在系统之外与系统交互的某人或某事物。

参与者只可能存在边界之外，边界之内所有人和事物都不是参与者

要弄懂谁是参与者，首先弄懂系统边界，可以通过回答下面两个问题确定：

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

参与者可以非人

例如有这样一个需求：每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。这个需求的参与者是谁？（计时器）

任何需求都必须至少有一个启动者，如果找不到启动者，那么可以肯定地说这不是一个功能性需求。

例如这样一个需求：客户提出要建立的系统界面要很友好，在每个页面上都要有操作提示。这个要求就找不到启动者，我们可以肯定他不是一个功能性需求

那它是什么呢？实际上它是补充规约中的一个要求，具体说是系统可用性的一个具体要求。

发现参与者

参与者的一个重要来源是涉众，从涉众中找出那些直接对系统发出动作，或者直接从系统中接收反馈的涉众。

另一个来源是客户岗位设置，为他假定一个参与者

• 列出他在系统要做的事情
• 再与另一些客户代表访谈
• 分析可以在系统中要做的事情，找出共同性

可以询问以下问题以帮助确定参与者：

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

查找参与者时，参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者

业务主角

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

在软件项目里，业务范围和系统范围是不同的。

• 业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都客观存在
• 系统范围是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集。但是一些系统功能会超出业务范围：操作日志

业务主角的特殊性在于，它针对的是业务任务而非计算机用户，没有抽象的计算机角色。必须在实际业务里找到对应的岗位或人员

要建设一个符合客户需要的计算机系统，首要条件是完全彻底地搞清楚客户的业务，而不是预先假设已经有了一个计算机系统，再让客户来假想需要计算机系统帮他们做什么

如果你对获得的业务主角不是很自信，请回答以下问题：

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

业务工人

有些人员参与了业务，但是身份很尴尬，他是被动参与业务的，不好说他有什么具体目的，但是他又的确在业务过程中做了事情，到底要不要为这样的人建模？例如人工坐席

这种困扰是因为违背了参与者的定义：参与者必须要在边界之外。如果视图把边界内和边界外的参与了业务的人都叫做参与者而建立模型，就会出现混乱和尴尬。

那么如何区分是参与者还是业务工人呢？三个问题帮助澄清：

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

如果是否定的，那一定是业务工人

参与者与涉众的关系

涉众，也称为干系人，是与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响系统的建设。

例如一个系统的建设是由一家国际风险投资机构投资的，这个系统必然与这家投资机构有着利益关系，有时系统必须满足投资方的一些特殊要求，作为涉众，投资方的意见或许有些约束，但不会参与系统建设。

• 参与者是涉众的代表
• 参与者通过对系统提出要求来获得他说代表的涉众的利益

参与者与用户的关系

• 用户是系统的使用者，用户是参与者的代表，或者说是参与者的实例或代理
• 并非所有的参与者都是用户，但一个用户可以代理多个参与者

参与者与角色的关系

• 角色是参与者的职责，从众多参与者的职责中抽象出相同的那一部分，将其命名而形成一个角色
• 角色一般适合在概念阶段的模型里，以表达业务的逻辑理解
• 一个用户可以代理多个参与者，可以拥有多个职责，也就是可以被指定多个角色

参与者的核心地位

• 参与者代表涉众对系统的利益要求，并向系统提出建设要求
• 通过代理给其他用户或将自身实例化成用户来使用系统
• 参与者的职责可以用角色来归纳，用户被指定扮演哪个角色

检查点

统一过程的官方文档给出了一个检查点列表，回答这个检查点列表中的问题非常有助于检查发现的参与者是否正确：

3.3 用例

用例是对对象施加这一外力的元素，正是用例使得其他哪些“孤独”的uML元素能够共同组成一篇有意义的文字。

基本概念

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

一个用例就是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集和。

用例的作用：捕捉功能性需求

一个系统的功能性是由一些对系统有愿望的参与者要做的一些事情构成的，事情完成后就达成了参与者的一个愿望，当全部参与者的所有愿望都能通过用例来达到，那么这个系统就被确定下来了。

用例的特征

1. 用例是相对独立的：意味着它不需要与其他用例交互而独自完成参与者的目的

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

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

5. 用例必然是以动宾语短语形式出现的

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

用例的粒度

• 在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。例如：取钱、报装电话，不用细到验证密码、填写申请单等业务中的一个步骤
• 在用例分析阶段，用例的粒度以每个用例能够描述一个完整的事件流为宜。需要注意的是：这个阶段需要采用一些面向对象的方法，归纳和抽象出业务用例中的关键概念模型并为之建模。例如，宽带业务需求中有申请包装和申请迁移地址用例，在用例分析时，可归纳和分解为提供申请资料、受理业务、现场安装等多个业务流程中使用的概念用例
• 在系统建模阶段，用例视角是针对计算机的，用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。在RUP中，项目计划要依据系统模型编写，因此另一个可参考的粒度是一个用例的开发工作量在一周左右为宜。

用例粒度的划分依据最标准的方法是以该用例是否完成了参与者的某个完整目的为依据的。例如：某人去图书馆，查询了书目，出示了借书证，图书管理员查询了该人以前的借阅记录以确保没有未归还的书，最后借到了书。这段话的实际用例就是借书，所有的操作都是围绕着这个展开的。

一般情况下，一个系统的业务用例定义在多于10个，少于50个之间，否则就应该考虑一下粒度选择是否合适了。

用例的获得

用例的来源就是参与者对系统的期望

可以开始对主角，进行访谈，有以下需注意的点：

• 不要视图让业务代表为你描述整个业务流程
• 不要涉及表单填写一类的业务细节
• 你可以不关系业务规则
• 不要试图让业务代表理解将来的计算机系统如何工作

你只需要让业务代表从他自己的本职工作出发来谈谈他的期望：

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

在这个过程中，你应当确保：

• 一个明确的有效的目标才是一个用例的来源
• 一个真实的目标应当完备地表达主角的期望
• 一个有效的目标应当在系统边界内，由主角发动，并具有明确的结果。

若需要重新访谈，你需要调整一下策略：

• 调整系统边界和主角
• 扩大或缩小系统边界
• 变更主角
• 重新开始

用例和功能的误区

1. 功能是脱离使用者的愿望存在的。我们常说某某工具有某个功能，他是描述工具的，而不是站在使用者的角度描述使用者愿望的。
2. 功能是孤立的，给一个输入，通过计算就有一个固定的输出——只要按下开关灯就亮
3. 如果非要从功能的角度解释用例，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场景，这些“功能”体现不同的组合方式。

目标和步骤的误区

用例粒度的误区

• 分不清目标和步骤
• 在同一个需求阶段的用例粒度大小不一

业务用例

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

业务用例实现

概念用例

系统用例

用例实现

3.4 边界

边界决定视界

边界决定抽象层次

灵活使用边界

3.5 业务实体

业务实体的属性

业务实体的方法

获取业务实体

3.6 包

3.7 分析类

边界类

控制类

实体类

分析类的三高

3.8 设计类

类

属性

方法

可见性

3.9 关系

关联关系

依赖关系

扩展关系

包含关系

实现关系

精化关系

泛化关系

聚合关系

组合关系

3.10 组件

完备性

独立性

逻辑性

透明性

使用组件

3.11 节点

分布式应用环境

多设备应用环境