UML建模之用例图

用例模型概述

用例模型的功能

用例模型是把满足用户需求的基本功能（集）聚合起来的强大工具。

对于正在构造的新系统，用例描述系统应该做什么，对于已经构造完毕的系统，用例则反映了系统能够完成什么样的功能。

构建用例模型是通过系统开发者和系统的客户（或最终使用者）共同协商完成的，他们要反复讨论需求的规格说明，达成共识，明确系统的基本功能，为后阶段的工作打下基础。

用例模型的基本组成

用例模型的基本组成部件是用例、参与者。

用例用于描述系统的功能，也就是从外部用户的角度观察系统应具备哪些功能，帮助分析人员理解系统的行为，它是对系统功能的宏观描述。一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有基本功能（集）。

参与者是系统进行交互的外部实体，它可以是系统用户，也可以是其他系统或硬件设备，总之，凡是需要与系统交互的任何东西都可以称作参与者。

参与者

参与者(Actor)是系统交互的人或者事。所谓“与系统交互”，指的是参与者向系统发送消息，从系统中接受消息，或是在系统中交换信息。UML中用一个小人图形表示角色类。

确定参与者

（1）使用系统主要功能的人是谁？主要角色？
（2）需要借助于系统完成日常工作的人是谁？
（3）谁来维护和管理系统（次要角色），保证系统的正常工作？
（4）系统控制的硬件设备有哪些？
（5）系统需要与哪些其他系统交互？其他系统包括计算机系统，也包括该系统将要使用的计算机中的其他应用软件。其他系统也分成两类，一类是启动该系统的系统，另一类是该系统要使用的系统。
（6）对系统产生的结果感兴趣的人或事是哪些？

参与者说明

参与者对于系统而言总是外部的，它们可以处于人的控制之外。

参与者可以直接或者间接地同系统交互，或使用系统提供的服务以完成某项事务

参与者表示人或事务与系统发生交互时所扮演的角色，而不是特定的人或者特定的事物。

一个人或事物在与系统发生交互时，可以扮演多个角色。

每一个参与者需要一个具有业务一样的名字，并且必须有简短的描述（从业务角度描述参与者是什么）。

参与者可以具有属性和事件，但使用不能太频繁。

用例

什么是用例

用例是Jacobson在面向对象的软件工程中提出的，但它实际上是独立于面向对象的。

用例代表一个系统或者系统的一部分行为，是对一组动作序列的描述，系统执行该动作系列来作为参与者产生一个可观察的结果值。

用例代表的是一个完整的功能。UML中的用例是动作步骤的集合。动作是系统的一次执行（能够给某个参与者输出结果值）。

用例的特征

用例总是由参与者初始化

用例为参与者提供值

用例具有完全性

识别用例

1. 针对参与者
   1. 某个参与者要求系统为其提供什么功能？该参与者需要做哪些工作？
   2. 参与者需要阅读、创建、销毁、更新或储存系统中的某些信息吗？
   3. 系统中的事件一定要告知参与者吗？参与者需要告知系统一些什么吗？
   4. 系统新功能的识别，参与者的日常工作被简化或效率提高了吗？
2. 针对系统
   1. 系统需要什么样的输入和输出？输入来自哪里？输出到哪里去？
   2. 该系统的当前状况还存在哪些问题？
   3. 系统的改进的方向？

询问以下问题来发现用例

参与者需要从系统中获得哪种功能？参与者需要做什么？

参与者需要读取、产生、删除、修改或存储系统中的某种信息吗？

系统中发生的时间需要通知参与者吗？或者参与者需要通知系统某件事吗？这些事件和功能能干些什么？

如果用系统的新功能处理参与者的日常工作是简单化了，还是提高了工作效率？

系统需要的输入输出是什么信息？这些输入输出信息从哪里来？到哪里去？

系统当前的这种实现方法要解决的问题是什么？（也许是用自动系统代替手工操作？）

动手实践

通过包对用例进行合理规划

包图概述

包是一种组合机制把各种各样的模型元素一起成为一个整体就叫做包。包通常用于对模型进行组织管理，因此有时候又将包成为子系统。包拥有自己的模型元素，包的实例没有任何语义（含义），只有在模型执行期间，包才有意义。

用例描述

（1）用例的目标

用例的最终任务是什么？想要得到什么样的结果？即每个用例的目标一定要明确。

（2）用例是怎样的被启动的

哪个参与者在怎样的情况下启动执行用例。

（3）参与者和用例之间的消息流

参与者和用例之间的消息使用来通知对方的？哪些是修改或者检索信息的？哪些是帮助用例做决定的？系统和参与者之间的主消息流描述了什么问题？系统使用或者修改了哪些实体？

（4）用例的多种执行方案

在不同条件或者特殊情况下，用例能根据当时条件选择一种合适的执行方案。

（5）用例怎样才算完成并把值传给了参与者

描述中应明确指出在什么情况下用例才能被看做完成，当用例被看作完成时要把结果值传给参与者。