《机房收费系统》rose图---①用例图(Use Case Diagram)

本文通过《机房收费系统》这个实例来介绍一下UML中的用例图，说的不对or不妥的地方还请高手指点。

先说说用例图的功能

用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即客户希望系统具备完成什么功能，通俗的理解用例就是软件的功能模块。所以设计系统分析阶段的起点，设计人员根据客户的需求来创建和解释用例图，用来描述软件应具备哪些功能模块及这些模块间的调用关系，以求把系统的整个结构和功能反映给非技术人员(通常是软件的用户)，对应的是软件的结构和功能分解。

用例图主要包含的元素

用例图主要包括角色、用例及他们之间的关系。

一.角色(Actor)

角色有人也称其为执行者，是指用户在系统中扮演的角色。

1.如何从业务中找出用例

获取系统用例首先要找出系统的角色，我们可通过用户回答一些问题来识别角色。可参考以下问题：

①谁使用系统的主要功能(主要使用者)?

②谁需要系统支持他们日常工作?

③谁来维护、管理系统使其正常工作(辅助使用者)?

④系统需要控制哪些硬件?

⑤系统需要与其他哪些系统交互？这里包含其他计算机系统或应用程序。

⑥对系统产生结果感兴趣的是哪些人和哪些事物？

2.角色之间的关系

由于角色是类，所以它拥有与类相同的关系，在用例图中只用泛化关系描述若干个角色之间的行为。

泛化关系：是把某些角色的共同行为（原角色中的部分行为），抽取出来表示成通用行为，且把它们描述成为超类（superclass）。

例如："机房收费系统"中抽象出的角色为：一般用户、操作员、管理员，下图描述了他们之间的关系。

二.用例(Use Case)

用例是外部可见的系统功能，对系统为某一个或几个参与者提供的服务进行描述。

1.如何从业务中找出用例？

找出系统的用例，我们从角色入手，对每个角色提出一些问题，然后从角色对这些问题的答案中获取用例。

①角色要求系统提供哪些功能(角色需要做什么)?

②角色需要读、产生、修改、删除或者存储系统中的信息有哪些类型?

③角色必须提醒系统事件有哪些?把这些事件表示成系统用例。

2.用例间的关系

从原则上讲，用例间都是独立、并列的，它们之间并不存在着包含从属关系。但为了体现一些用例间的业务关系，提高可维护性和一致性，用例间可抽象出包含、扩展和泛化几种关系。

①包含关系(include)

包含关系：来自于用例的抽象，即从数个不同用例中，分离出公共部分，而成为可复用的用例。

当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注<<include>>)，箭头从基用例指向子用例。

例如："机房收费系统"中操作员完成的"注册"功能中，注册包含几个小的功能，下图描述了他们之间的包含关系。

②扩展关系(extend)

extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可完成一个完整的功能。extend的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。extend关系在用例图中使用带箭头的虚线表示(在线上标注<<extend>>)，箭头从子用例指向基用例。

例如："机房收费系统"中各"导出到Excel表"的功能就是各基用例的扩展用例，下图展示了"操作员"中需要"导出到Excel表"的用例的扩展关系图。

③泛化关系(Generalization)

泛化关系是一种继承关系，子用例将继承基用例的所有行为、关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。泛化关系在用例图中使用空心实线箭头表示，箭头方向从子用例指向基用例。

例如："机房收费系统"各用例之间没有展现泛化关系，下面这个小例子也展现了泛化关系。

三.角色与用例之间的关系<之前错误的写成了：角色与参与者之间的关系>

角色和参与者之间的关系一般是关联关系，表示该角色代表的外部系统实体与该用例描述的系统需求有关。

四.UML用例图中用到的关系汇总

附："机房收费"用例图。

下面"机房收费系统"用例图，我是按角色划分的，划分了三个角色：一般用户、操作员、管理员。

一般用户用例图

操作员用例图

管理员用例图

2012.8.9

注意：机房收费系统图中包含关系好像用的不对。

include与extend的区别：

①include：必须柏晗的，比如注册卡号之前先查询，而且必须查询卡号有没有存在。

②extend：可有可无的功能，比如打印和excel表导出。