2. UML笔记 - 用例图
Posted 鱼鱼不愚
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了2. UML笔记 - 用例图相关的知识，希望对你有一定的参考价值。
2. 用例图
2.0 目录
2.0 目录
2.1 用例图的构成
2.1.1 系统
2.1.2 参与者
2.1.3 用例
2.1.4 关系
2.2 泛化
2.2.1 泛化用例
2.2.2 泛化参与者
2.3 描述用例
2.4 用例之间的关系
2.5 END.
2.1 用例图的构成
-
系统：指本系统，用一个方框表示，方框的边界即系统的边界。 -
参与者：可以是人，也可以是本系统外部的设备、系统。 -
用例：一个用例表示系统的一个功能。 -
关系：交互关系，有参与者与用例之间的关系和用例与用例之间的关系。
2.1.1 系统
这里的系统表示的其实是能够为用户执行某类功能的一个或多个软件构建，一个软件工程可以是一个大系统，大系统内部还能分出各小系统，每个系统都可以单独画一份用例图其实。
之所以会把系统放在第一个这里，是因为每次画用例图之前都要识别出这个用例图中系统的基本功能是什么，再此为基础定义一个稳定、精确的架构，最后便可以逐步完善这个系统。
如下，在设计一个系统时确认了系统的功能：
2.1.2 参与者
参与者是系统外的实体，其通过向系统输入或要求系统提供某种信息来进行交互。
在用例图中，参与者可以理解为是本系统的使用者，但在实际开发时，参与者的身份其实就是本系统的接口，如下图：
设计系统时，识别参与者主要需要根据以下几个问题以帮助发现系统的参与者：
-
谁系统的主要客户？ -
谁使用系统完成日常工作？ -
谁负责系统维护？ -
系统控制的硬件设置有什么？ -
系统需要和哪些其它系统进行交互？ -
在预定时刻是否有自动事件发生？ -
系统从何处获取信息？
识别参与者之后，可以把所有的参与者分为两类：主要参与者和次要参与者。简单点，主要参与者就是客户，而次要参与者是本系统的员工，客户和员工都会经常和本系统进行交互，但毕竟客户是上帝，所以作为主要参与者较频繁地与系统进行业务类的交互，而员工则主要是负责系统的维护等杂活累活儿。
2.1.3 用例
用例是用户期望系统具备的功，其定义了系统的行为特征。在用例图中，一个用例只负责系统的一个行为，并且不对外显示其内部结构，仍然是一个黑盒模式。但允许其通过关联关系与参与者进行交互。
通常情况下用例图中的用例名是一个动词加一个名词，如检查纸张、设备自检等，在图中用一个椭圆表示。
设计用例过程时，一般情况下是不用担心想的不全面的，因为本身就是先想几个出来，然后再迭代多几个一直完善下去的。识别用例也是问几个问题的：
-
参与者需要哪些功能？ -
参与者是否需要增删改查系统内的某种信息？ -
系统的状态改变时，需不需要通知参与者？ -
是否存在影响系统的外部事件？ -
系统需要什么样的输入输出？
2.1.4 关系
用例与参与者之间的连线就是关系，也就是说，用例本身就可以作为接口直接与参与者进行交互，如下图：
差不多如下图，但在关联关系中，两个表示交互的箭头可以直接改为一条实线，表示该参与者可以使用对应的用例。
2.2 泛化
2.2.1 泛化用例
对应面向对象中的继承关系。即一个用例可以有两种或多种实现方式，而这个用例就是所有实现方式所对应用例的泛指。例如彩色打印文档和黑白打印文档都是打印文档，那么打印文档就可以泛指这两个用例。
2.2.2 泛化参与者
用例可以泛化，参与者也可以，但没必要多敲几个字。
2.3 描述用例
用例只是说明了系统有什么功能，与什么参与者有关联关系，这点一般还是不够的。例如打印文档之前，必须得把打印设备打开了才可以打印，为了让人知道这一点，一般用两个方法，一是描述用例，二就是直接在旁边打注释。这小节说的是描述用例。
| 用例描述 | 打印文档 |
|---|---|
| 参与者 | 学生或老师 |
| 前置条件 | 设备已打开 |
| 后置条件 | 输出打印纸张，设备关闭 |
| 基本操作流程 | 1. 参与者提交打印文档 2. 系统开始处理打印任务 3. 输出处理结果 |
| 可选操作流程 | 如纸张不足，系统会直接输出纸张不足，无法打印 |
2.4 用例之间的关系
主要有两种：包含关系和拓展关系。
-
包含关系是我这个用例在执行的时候，一定会调用到你这个用例。 -
拓展关系是如果我执行期间出了什么事情，就可能会调用你这个用例。
需要注意的是：两种关系的箭头是方向相反的！
根据上图，可以知道，参与者每次开关设备时，系统都会进行一次自检，以确保系统稳定安全。一般只有在自检时检测出故障，才会调用系统修复功能，所以系统修复用例是作为系统自检用例的拓展用例存在的。
2.5 END.
以上是关于2. UML笔记 - 用例图的主要内容，如果未能解决你的问题，请参考以下文章