UML学习之机房收费系统用例图

用例图概念

         描述角色以及角色与用例之间的连接关系。说明的是谁将是相关的用户、用户可以用系统做些什么又可以为系统做什么。概括讲就是通过建模的方式使系统功能展示给用户，达到可视化。用例图最常用来描述系统及子系统。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。

 

用例图包含的6元素

①     参与者（Actor）

②     用例（Use Case）

③     关联关系（Association）

④     包含关系（Include）

⑤     扩展关系（Extend）

⑥     泛化关系（Generalization）

 

各元素讲解：

参与者（Actor）

用来与程序或系统交互的用户、组织或外部系统，参与用例的执行过程，用小人来表示。通常使用泛化关系来描述参与者之间的公共行为。

用例（Use Case）

其实就是一种功能单元，但不深入到系统内部具体结构。识别用例时要结合参与者，要理清参与者是如何使用系统的。

 

关联关系（Association）

最简单的一个关系，就是表示参与者与用例之间的通信，任何一方都可发送或接受消息。

 

包含关系（Include）

官方解释：使用包含用例来封装一组跨越过个用例的相似动作（行为片段），以便多个基（Base）用例复用。

通俗的讲就是具有相似功能或动作的一些用例统一包装好形成一个基本用例，这样可使用例图更加简单清楚，帮助理清关系。若是展开细分，则相对详细复杂。这又让我想起了面向对象中的继承和封装。

扩展关系（Extend）

官方解释：讲基用例中一段相对独立并且可选的动作，用拓展（Extension）用例加以封装，再让它从基用例中声明的扩展点（ExtensionPoint）上进行拓展，从而使基用例行为更简练和目标更集中。

机房收费系统中有一些查询操作，查询结果可采用打印报表或者导出为excel来显示。其中查询、打印、导出相互独立，打印导出又是为查询添加了新的行为。

泛化关系（Generalization）

官方解释：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

机房收费系统中我概括出两组泛化关系，其中一组是学生下机可以为一个父用例，操作员进行全部下机或者部分下机为子用例。另一组是操作员和管理员分别享有一般用户和操作员的全部功能。

 

区别

说了半天总觉得其中的包含拓展和泛化三大关系这么混淆人呢，看来还是有必要区分一下的。

 

包含(include)、扩展(extend)、泛化(Inheritance) 的区别：

　　条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；

　　直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include中被包含的用例为参与者提供间接服务。

　　对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。

       对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；

 

 

　  下面附上我第一次画的用例图，以及总结后重新画的用例图，真是觉得第一次画会有很多欠缺啊。

 

第一次画的时候没有搞清楚各参与者和用例之间的关系，都认为是简单的关联关系，并没有深入，之后理解深了就重新画了画，感觉理解的还行，有什么不恰当的欢迎指出！