实践教程：用例（UseCase）-信息系统开发方法与实践教程

2023-11-23 理论教育版权反馈

【摘要】：用例是一组动作序列的描述，系统执行这些动作，并产生传递参与者意愿的可观察结果。用例的名字是一个字符串，分为简单名和路径名两种方式。用例Mainte nance是属于包Business的。基于这些参与者及其需求，通过回答前面的问题，可以建立如下用例：●记录成绩。

用例是参与者想要系统做的事情。用例是一组动作序列的描述，系统执行这些动作，并产生传递参与者意愿的可观察结果（UML对用例的定义）。

用例具有如下特征：

●通常由某个角色来驱动执行。

●把执行的结果反馈给角色。

●在功能上具有完整性，即它从参与者接受输入，产生结果输出给参与者。

1.用例的表示

在UML中，用例用一个椭圆表示，用例的名字写在椭圆的下方，如图8-5所示。每个用例都用唯一的名字区别于其他用例。用例的名字是一个字符串，分为简单名（Simple Name）和路径名（Path Name）两种方式。路径名是在简单名的前面加上所属包的名字。如图8-6所示，左边用例使用的是简单名。右边的用例使用的是路径名。用例Mainte nance是属于包Business的。

图8-5 用例的图符

图8-6 用例的名称

根据用例是否由参与者直接启动，可把用例分为具体用例和抽象用例。一个用例为抽象用例时，可以将其名称设为斜体。从以下标准可以判断具体用例和抽象用例：

●具体用例由参与者来启动，并构成一个完整的事件流。参与者在系统中“看见”和

启动的是具体用例。

●抽象用例本身不会被实例化，它通过包含、扩展或泛化关系体现在其他用例中。

●在启动一个具体用例时，就创建了该用例的一个实例，同时还展示了与其关联的抽象

用例指定的活动。在模型中，每个用例的执行都会独立于其他用例。尽管执行一个用例时，由于共享对象原因可能会与其他用例产生隐含的依赖关系、包含关系和扩展关系。

2.识别用例

用例的获取是需求分析阶段的主要任务之一。但对于一个大系统，要直接列出用例清单常常是十分困难的。这时可先列出参与者清单，再列出每个参与者的用例，问题就会变得容易多了。

在识别出参与者之后，就可以通过回答下述问题来帮助识别用例：

●每个参与者的任务是什么？

●有参与者将要创建、存储、改变、删除或读取系统中的信息吗？

●什么用例会创建、存储、改变、删除或读取这个信息？

●参与者需要通知系统外部的突然变化吗？(www.chuimin.cn)

●系统需要通知参与者正在发生的事情吗？

●什么用例将支持和维护系统？

例如，对一个成绩管理系统进行需求分析，可识别出如下参与者及其需求：

●学生（student）：浏览系统记录的成绩。

●授课教师（teacher）：使用系统为学生记录成绩、更新成绩、浏览成绩并可通过计算

机发布报告卡。

●管理人员（administrator）：负责创建报告卡，并浏览检查报告卡。

基于这些参与者及其需求，通过回答前面的问题，可以建立如下用例：

●记录成绩（record grades）。

●更新成绩（update grades）。

●生成报告卡（generate report cards）。

●检查报告卡（check report cards）。

●分发报告卡（distribute report cards）。

●浏览成绩（view grades）。

3.区分用例优先次序

这项任务通常由系统分析人员完成，他们对哪一项任务最关键、哪一项任务最艰巨有最好的全局认识。他们还可以确定出哪个用例可以为其他用例所重用。在上例中，可以提出以下优先次序列表：

1.记录成绩

2.浏览成绩

3.更新成绩

4.生成报告卡

5.检查报告卡

6.分发报告卡

某些用例必须在其他用例之前完成，因为它们之间是相互依赖的。例如，在系统更新成绩之前，必须记录成绩。因此，record grades是最重要的用例。

实践教程：用例（UseCase）-信息系统开发方法与实践教程

相关推荐