UML之用例视图

介绍

用例图是表示一个系统中用例与参与者之间关系的图，它描述了系统中相关用户和系统对不同用户提供的功能和服务。
对于用户而言，最关心的是一个系统具有的功能与呈现的外部特性，而并不十分关注实际过程及实现方法本身。用例视图就相当于从用户的视角来描述和建模整个系统，分析系统的功能和行为。
用例视图中主要元素包括参与者，用例以及元素之间的关系，此外，用例视图还可以包括注释和约束，也可以使用包将图中的元素组合成模块。
用例视图用于展示参与者和用例

参与者

描述了一个或一组与系统产生交互的外部用户或外部事物，参与者以某种方式参与系统中一个或一组用例的执行
参与者位于系统边界之外，而不是系统中的一部分。参与者是从现实世界中与系统有交互的事物中抽象出来的，而并非系统中的一个类。
参与者是从现实世界中抽象出来的一种形式，却不一定确切的对应现实中的某个特定对象，一个现实中的对象可以根据不同目的抽象成多个参与者，多个现实中的对象也可以按照对系统的相同目的抽象为一个参与者。比如，一个人可以是一个网站的管理员和普通用户，那么可以将他抽象为两个参与者；一个网站有多个用户，但他们对网站的操作和权限等是一样的，那么他们全体被抽象为一个参与者。

如何确定参与者

可以重点考虑如何与系统交互这一问题便于进一步确定系统的边界。可以从以下几个角度考虑：

• 为系统提供输入的人或事物
• 接收系统输出的人或事物
• 需要接入的第三方系统或设备
• 时间是否会触发某些事件？
• 负责支持或维护系统中信息的人

除了从以上角度考虑参与者，还可以参考参与者的分类进行确定。系统中的参与者一般可以分为四类：

1. 主要业务参与者：主要从用例的执行中获得好处的关联人员。主要业务参与者可能会发起一个业务事件
2. 主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联人员。主要系统参与者可能会与主要业务参与者进行交互，以便使用系统
3. 外部服务参与者：响应来自用例的请求的关联人员
4. 外部接收参与者：从用例中接收某些价值或输出的非主要的关联人员。

用例模型
用例模型是系统既定功能及系统环境的模型，可以作为客户和开发人员之间的契约。用例是贯穿了整个系统开发的一条主线，用例模型即为需求工作流程的结果，可以当作分析设计工作流程以及测试工作流程的输入使用。

表示法

参与者有两种表示方法：

• 人形图
• 使用带有<<actor>>构造型的矩形表示。

一般情况下，使用人形图表示人，用矩形图表示事物

用例

用例是整个开发过程中的驱动元素，是用例视图中最重要的元素。从开发者层面来说，多个独立无关的部分需要通力协作，最终完成一个或多个用例；从用户层面来说，用例直接显示出了用户的需求。可以说用例是系统中的对象最终得以实现其意义的核心力量。

什么是用例

用例是类元（一般是系统，子系统或类）提供的一个内聚的功能单元。一个用例就是就是系统的一个目标。用例的目的就是要定义一个系统或子系统的行为，但不揭示系统的内部结构。
简单来说，用例就是某一个参与者在系统中做某件事从开始到结束的一系列活动，以及结束时应该返回的可观测，有意义的结果，其中也包含可能的各种分支的情况。
表示法：UML中用例使用椭圆来表示。其中用例的名称可以显示在椭圆内部，或椭圆下方。

用例与参与者

一个用例可以隶属于多个参与者，一个参与者也可以参与一个或多个用例。用例和参与者之间存在关联关系，即参与者实例通过与用例实例通过消息实例来与系统进行通信。用例实例是一个用例的执行，由一条来自参与者实例的消息发起，作为响应，用例实例执行一系列用例指定的动作（包括给多个参与者实例发送消息），这种交互一直持续到用例的结束。因此在确定用例时可以从以下几个角度考虑：

• 参与者的主要任务是什么？
• 参与者需要系统的什么信息？
• 参与者可以为系统提供什么信息？
• 系统需要通知参与者发生的变化和事件吗？
• 参与者是否需要通知系统发生的变化和事件吗？

用例的特征

1. 用例是动宾短语。用例表达的是一个交互序列，因此需要使用一个动词词组或动宾短语来命名。比如，用例可以是“登录系统”，“取款”这样的名字，而不应该是“登陆器”，“取款单”等
2. 用例是相对独立的。所谓独立是指用例在功能上是完备的，即不需要与其他用例交互从而独立完成参与者的某项目的。用例本质上体现了参与者的愿望，因此，设计的用例必须要实现一个完整的目的。比如在ATM取款机旁边时，“取钱”是一个较好的用例，因为他满足了用户的一个目的，但是“输入密码”不能完整的实现参与者的目标，因此不能作为一个用例。
3. 用例是由参与者启动的。用例是参与者请求或触发的一系列行为。因此不存在没有参与者的用例。用例不应该自启动，多个用例之间也不应该相互启动。参与者的愿望或需求是用例启动或存在的原因。
4. 用例要有可观测的执行结果。不是所有的执行过程都最终成为用例。用例可以返回一些可以观测的执行结果，如“登录系统”时应该通知用户“登陆成功”。
5. 一个用例是一个单元。

用例的粒度

用例的粒度并没有一个标准的规则。但是不管标准如何，都要符合用例的特征。

用例图中的关系

用例图中的关系包括：参与者之间的关系；参与者与用例的关系；用例之间的关系

参与者的关系

一个系统中可以具有多个参与者，当系统中的几个参与者既扮演自身的角色，同时也有更一般化的角色时，可以通过建立泛化关系进行描述。对参与者建立泛化关系，可以将这些具有共同行为的一般角色抽象为父参与者，子参与者可以继承父参与者的行为和含义，并能拥有自己特有的行为和含义。
在泛化关系中，父参与者可以是抽象的（抽象元素表现为斜体），即不能创建一个父参与者的直接实例。

参与者和用例的关系

参与者与用例之间存在关联关系。
用例在执行过程中，一个用例不一定仅仅对应于一个参与者实例，一旦出现了多个参与者实例共同参与一个用例的发起和执行，参与者们就有了主次之分。用例行为被满足的这个参与者被称为用例的主参与者，而其他仅仅和系统有通信的参与者们被称为次参与者。主参与者是用例的重要服务对象，而次参与者处于一种协作地位。
在UML中，关联关系使用实线箭头来表示，如果箭头指向用例，则表明参与者发起用例，即用例的主要参与者；如果没有箭头或箭头指向参与者，则表明用例与外部服务参与者或外部接受参与者之间有交互，即用例的次参与者。
《TODO：图4.7》

用例之间的泛化关系

与参与者之间的泛化关系类似，用例的泛化关系将特化的用例和一般化的用例联系起来，子用例继承了父用例的属性，操作和行为序列，并且可以增加属于自己的附加属性和操作。

用例之间的依赖关系

除泛化关系之外，用例之间存在着多种依赖关系，这里主要介绍两种依赖关系：

包含

包含指的是一个用例（基用例）可以包含其他用例（包含用例）具有的行为，其中包含用例定义的行为将被插入基用例定义的 行为中。使用包含关系需要遵循两个约束条件：

1. 基用例可以看到包含用例，并需要依赖于包含用例的执行结果，但他对包含用例的内部结构没有了解；
2. 基用例一定会要求包含用例的执行，即对包含用例的使用是无条件的

比如，在某个在线交易系统的用例视图中，用户创建订单的用例一定是需要包含选择商品的行为序列，且创建订单的行为依赖于选择商品的结果。因此二者构成包含关系。

在UML中，包含表示为一个虚线箭头加上<<include>>，箭头从基用例指向包含用例。
《TODO：图4-9》
一般情况下，当某个动作片段在多个用例中都出现时，可以将其分离出来从而形成一个单独用例，将其作为多个用例的包含用例，以此达到复用的效果。

扩展

扩展指的是一个用例（扩展用例）对另一个用例（基用例）行为的增强。在这一关系中，扩展用例包含了一个或多个片段，每个片段都可以插入基用例中的一个单独的位置上，而基用例对于扩展是毫不知情的。使用扩展用例，可以在不改变基用例的同时，根据需要自由的向用例中添加行为。
扩展使用一个附加了<>的虚线箭头表示。箭头指向基用例。需要注意的是，扩展与包含的箭头方向是相反的，这表明扩展取决于扩展用例而非基用例，扩展用例决定扩展的执行时机，基用例对此一无所知。
扩展用例的使用包含四个部分：

1. 基用例：需要被扩展的用例
2. 扩展用例：提供新增的行为序列的用例
3. 扩展关系：使用虚线箭头表示，箭头指向基用例
4. 扩展点：基用例中一个或多个位置，表示在该位置会根据某条件来决定是否要中断基用例的执行从而执行扩展用例中的片段。扩展点实际上是一个决定是否执行扩展用例的分支条件，类似于if语句。

扩展用例执行完毕之后，基用例从中断的位置继续执行，也就是说，扩展用例是否被执行取决于扩展点的条件，如果条件不满足则不执行扩展用例。在基用例的执行过程中，可以通过扩展点的数量和位置来使同一个扩展用例执行多次

用例描述

通过用例说明文档来进行用例描述，补充用例视图无法表述的细节等信息。
一般的用例描述包含几个部分：

1. 用例名称：描述用例的意图或实现目标，一般为动词或动宾短语
2. 用例编号：用例的唯一标识，在其他位置可以使用该标识来引用用例
3. 参与者：描述用例的参与者（主要参与者和其他参与者）
4. 用例描述：对用例的一段简单的概括描述
5. 触发器：触发用例执行的一个事件，如“生成订单”用例的触发器是“用户提交了一个新订单”
6. 前置条件：用例执行前系统状态的约束条件（TODO）
7. 基本事件流：用例的常规活动序列，包含参与者发起的动作与系统执行的响应活动
8. 扩展事件流：
9. 结论：描述用例何时结束。如“生成订单”的用例结论是，“用户收到订单确认的通知”
10. 后置条件：用例执行后系统状态的约束条件
11. 补充约束：用例实现时需要考虑的业务规则，实现约束等信息。

用例文档模板

用例名称	提交订单
用例编号	UC001
参与者	会员
用例描述	该用例描述一个系统会员提交一份订单的行为
触发器	当订单被提交时，触发用例
前置条件	提交订单的一方需要完成登录操作
后置条件	如果订单中的商品有库存则发货，否则提示用户当前缺货
基本事件流	1. 用户将订单提交之系统；2. 系统验证用户信息；3. … 7. 生成订单确认页并发送给用户
扩展事件流
结论	当会员收到系统发送的订单确认页面时，用例结束
数据需求	订单信息包括订单号，参与者会员账号，商品种类数量等
业务规则	只有当订单中的商品信息确认无误后才能要求会员进行支付