Icon形式
Label形式
Decoration形式
三 Actor的泛化关系
参与者(actor)之间可以存在泛化(generalization)关 系，表示一个一般性的参与者与另一个更为特殊的 参与者之间的联系。如下图所示：
actor actor
generalization
四 注意事项
错误2：只描述actor的行为，没有描述系统的 行为。
例3：下面是一个用例描述的片断： Use Case: Buy Something 参与者: Customer 主事件流：
1. 系统显示“ID and Password”屏幕。 2. 顾客键入ID和密码，然后按OK按钮。 3. 系统验证顾客ID和密码，并显示“Personal Information”屏幕 4. 顾客键入姓名、街道地址、城市、州、邮政编码、电话号码，然后 按OK按钮。 5. 系统验证用户是否为老顾客。 6. 系统显示可以卖的商品列表。 7. 顾客在准备购买的商品图片上点击，并在图片旁边输入要购买的数 量。选购商品完毕后按“Done”按钮。 8. 系统通过库存辅助系统验证要购买的商品是否有足够库存。 ...etc. 错误3：设定对用户界面的设计的要求。
扩展关n use case (对扩展关系) base use case (对包含关系)
base use case (对扩展关系)
inclusion use case (对包含关系)
包含与扩展的区别
执行基本用例时，可以执行也可以不执行扩展 用例； 执行基本用例时，一定会执行包含用例。
3.5 用例图
在UML中，一个用例模型由若干个用例图(use case diagram)描述。用例图是显示一组用例、 参与者以及它们之间关系的图。
例：金融贸易系统的用例图。
一个use case图的例子— financial trading system
3.7 用例描述
用例分析有两个主要工作： 用例图：只能描述系统大致功能，是一种视图； 用例描述：更详细地描述用例功能（最重要）。
一 含义
用例描述是指对一个用例的功能进行的文字描 述，是参与者与系统交互动作序列的说明。 一个用例的完整描述必须指明所有可能的脚本。
二 内容
用例的目标 用例如何启动 主事件流 其他事件流 用例结束后系统的状态 其它内容
用例的一个描述格式： (用例模板)
用例名称。表明用户的意图或use case的用途，如 “划拨资金”。 标识符 [可选]。唯一标识符，如 “UC1701”，在文 档的别处用标识符来引用这个用例。 用例描述。概述用例的几句话。 参与者。与此用例相关的参与者列表。 优先级。一个有序的排列，1代表优先级最高。 状态 [可选]。用例的状态，通常为以下几种之一： 进行中、等待审查、通过审查或未通过审查。
Use Case: Buy Something 参与者: Customer 主事件流：
1. 顾客使用ID和密码进入系统。 2. 系统验证顾客身份。 3. 顾客提供姓名、地址、电话号码。 4. 系统验证顾客是否为老顾客。 5. 顾客选择要购买的商品和数量。 6. 系统通过库存辅助系统验证要购买的商品是否有 足够库存。 ... etc.
1. 通过读卡机，储户插入ATM卡。 2. ATM系统从卡上读取银行ID、帐号、加密密码、并用主银行系 统验证银行ID和帐号。 3. 储户键入密码，ATM系统根据上面读出的卡上加密密码，对密 码进行验证。 4. 储户按“FASTCASH”按钮，并键入取款数量，取款数量应该 是5美元的倍数。 5. ATM系统通知主银行系统，传递储户帐号和取款数量，并接收 返回的确认信息和储户帐户余额。 6. ATM系统输出现金，ATM卡和显示帐户余额的收据。 7. ATM系统记录事务到日志文件。
collaboration
例： use case
realization
说明： 在大多数情况下，一个use case由一个 协作(collaboration)实现，因此可以不 用在模型中显式指明这种实现关系。 在UML中，一个collaboration由一组图 （协作图collaboration diagram，顺序图 sequence diagram，活动图activity diagram等）表示。
被泛化的用例：无 被包含的用例：登录 (UC1706)。 被扩展的用例：无 修改历史记录： Rene Becnel, 定义基本操作流程, 2012/10/3 Rene Becnel, 定义可选操作流程, 2012/10/6 例：提取现金的部分描述
Use Case: Withdraw Cash （提取现金） 参与者: Account Holder 主事件流：
第三章 用例分析
3.1 用例（ Use Case ）
在软件开发中采用用例驱动是I. Jacobson对软 件界最重要的贡献之一。
Use Case 驱动
需求 分析和设计
实现
测试
Use Cases 把所有这些过程绑到一起
use case对软件开发的意义
一 定义
use
case是对一个活动者(actor) 使用系统的一项功能时所进行的交 互过程的一个文字描述序列。
2. 作用：包含用例使一个用例功能可在另一用 例中使用。 它有两种场合使用： 如果两个以上用例有大量一致的功能，将其分 解至另一用例； 一个用例功能太多，可以建模子用例。
包含关系的例子：
base use case
inclusion use case
四 扩展(extend)关系
扩展(extend)关系的基本含义与泛化关系类似，但 是对于扩展Use Case有更多的规则限制，即基本 的Use Case必须声明若干“扩展点” (extension point)，而扩展Use Case只能在这些扩展点上增 加新的行为。
actor说明： Actor是虚拟的概念，可以指人，外部系 统，设备等。 一个actor可以执行多个use case；一个 use case也可以由多个actor所使用。 尽管在模型中使用actor，但actor实际 上并不是系统的一部分。
二 表示
Actor实际上是一个版型化的类，其版型(Stereotype) 是actor。可以用带有版型“<<actor>>”的类图标表 示，也可以用人形图标表示。一般用类图标表示参 与者是外部系统，用人形图标表示参与者是人。
在系统外部，同系统交互，帮助定义系统边界 事物与系统交互所扮演的角色，为群体概念； 事物与系统交互可同时扮演多个角色； 命名为业务领域名
3.3 用例图中的关系
一 关联（association） 参与者与用例之间具有使用、交互信息的关联 注意：箭头方向表示谁启动信息，非信息流动 方向
二 泛化(generalization)关系
修改历史记录 [可选]。关于用例的修改时间、修 改原因和修改人的详细信息。 问题 [可选]。与此用例的开发相关的问题的列表。 决策[可选] 。关键决策的列表，将这些决策记录 下来以便维护时使用。 频率[可选] 。参与者访问此use case的频率。如 用户每日访问一次或每月一次。
例：用例模板 用例名称：处理订单 标识符：UC1701 用例描述：当一个订单初始化或者被查询的时候 这个用例开始。它处理有关订单的初始化定义和 授权等问题。当订单业务员完成了同一个顾客的 对话的时候，它就结束了。 参与者：订单业务员 优先级：1 状态：通过审查 前置条件：订单业务员登录进系统 后置条件：下订单；库存数目减少
二 特点
用例从系统使用者的角度描述系统中的信息， 对应一个具体的用户目标； 用例不反映功能实现方式； 用例提供了一种与最终用户和领域专家进行沟 通的方法； 用例提供了一种测试系统的方法； 用例可大可小； 用例分析本质上是功能分解技术，但是OO开 发的第一步。
Use Case的实现： Use Case是与实现无关(implementation-independent)的关于 系统功能的描述。 在UML中，用协作(collaboration)来指明对use case的实现。
例4：下面是一个用例描述的片断： Use Case: Buy Something 参与者: user(或Customer) 主事件流：
3.2 参与者（ Actor ）
一 定义 Actor是指系统以外的，需要使用系统或与系 统交互的东西，包括人，设备和其它系统。 Actor有不同的译名，如：参与者, 活动者, 执 行者, 行动者等。
例：在线银行系统的一些可能的参与者： 客户：从系统获取信息并执行金融交易。 管理人员：开办系统的用户。获取并更新 信息。 厂商：接受作为转帐支付结果的资金 mail系统
前置条件。一个条件列表，如果其中包含条件，则这 些条件必须在访问用例之前得到满足。 后置条件。一个条件列表，如果其中包含条件，则这 些条件将在用例完成以后得到满足。 基本操作流程。描述用例中各项工作都正常进行时用 例的工作方式 。 可选操作流程。描述变更工作方式、出现异常或发生 错误的情况下所遵循的路径。 被泛化的用例 [可选]。此用例所泛化的用例列表。 被包含的用例 [可选]。此用例所包含的用例列表。 被扩展的用例 [可选]。此用例所扩展的用例列表。
扩展: use case之间的关系
3.3 Scenario(脚本)
脚本(scenario)：也称情景，场景，情节，剧本等。 在UML中，scenario指贯穿use case的一条单一路径， 用来显示use case中某种特殊情况。 在“订货”这个用例中，包含着几个相关的scenario：
