【UML】NO.54.EBook.6.UML.2.002-【Thinking In UML 大象 第二版】- UML 核心元素

1.0.0 Summary

Tittle：【UML】NO.54.EBook.6.UML.2.002-【Thinking In UML 大象 第二版】- UML 核心元素

Style：DesignPattern

Series：DesignPattern

Since：2017-11-13

End：....

Total Hours：...

Degree Of Diffculty：2

Degree Of Mastery：2

Practical Level：2

Desired Goal：2

Archieve Goal：....

Gerneral Evaluation：...

Writer:kingdelee

Related Links：

http://www.cnblogs.com/kingdelee/

1.版型 stereotype

Actor（参与者/执行者）

1.1 发现/如何找到参与者

1.2 参与者确定举例

1.2 业务主角（Business Actor）

1.3 业务工人（Business Worker）

1.4 涉众（stakeholder）　　

1.5 参与者与用户的关系

1.6 参与者与角色的关系

1.7 参与者的核心地位

2. 用例

用例，就是需要实现的一个事情/方法/愿景。

一个完整的用例，包含：参与者、前置条件、场景、后置条件。

2.1 用例特征

2.1.1 用例是相对独立的

用例从功能上，是完备的，提现了系统参与者的愿望。

如：取钱是用例，填写取款单不是用例。因为完整的目的是取钱，而不是去银行填写取款单。

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

后台进程对用户来说是不可观测的，他作为系统需求的一个补充约定而不是用户的需求。

如：登录是用例，输入密码不是。

2.1.3 用例必须有一个发起者

不存在没有参与者的用例。

如：ATM取款是用例，ATM吐钞不是。

2.1.4 用例必须是动宾短语形式出现

如：喝水是用例，喝不是用例；

计算、统计、报表、输出、录入 都不是规范的，应为 计算报表、统计报表、输出报表、输入表报...

2.1.5 用例的单元

一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元、部署单元，一旦决定了用例，软件开发的其他活动都以这个用例为基础进行，如驱动软件开发活动。

2.2 用例的粒度

用例的粒度划分是以该用例是否完成了参与者某个完整目的为依据。

业务建模阶段：一个用例能够说完整一个事情。

　　如：取钱，报装电话。

　　而不是，验证密码，填写报装单....

概念建模阶段（用例分析阶段）：一个用例能够说完整一个事件流，或者说 一个用例描述一个完整业务的一个步骤

系统建模阶段：一个用例描述操作中与计算机的一次完整的交互

2.3 用例的获得

2.4 用例练习：

2.5 用例和功能的误区

描述事物的观点

2.6 边界的误区

上图已经足够说明，而下图则会显得层次不明，超越边界

同一需求阶段，保持所有用例的粒度在同一量级

2.7 业务用例（Business Use Case）

业务用例是普通用例的一个版型，用于业务建模。

软件需求的真正来源是系统范围，也就是系统模型。业务模型是系统模型的最重要的输入。

2.8 业务用例实例

3. 分析类

3.1 边界类