开篇
UML画图既是对UML的学习,也是对机房收费系统的再次学习。机房结束有一段时间,对于里边的一些内容可能已经忘了,所以,画图之前重新分析机房收费系统是一个必不可少的工作,借此争取让我们对机房有一个更清晰的认识。
用例图(Use Case Diagram)是由软件需求分析到最终实现的第一步,说明的是谁要使用系统,以及他们使用该系统可以做些什么,是九种图里面最为基础且非常重要的一张图。
用例图三巨头
用例图包括三方面的内容:参与者,用例和关系。
1、参与者
(1)参与者是指存在于系统外部并直接与系统进行交互的实体。而这个实体不仅仅是人,它代表一个集合,可以是人,可以是计算机系统,也可以是硬件设备,还可以是时间。
在机房收费系统中,参与者大致可以分为三类,一般用户,操作员和管理员。一般用户是系统大多时候的使用者,对于系统进行最基础的操作。再者就是操作员,对于系统有更高的权限,可以对系统进行更高级的设置。最后就是管理员,拥有最高的权限,可以对所有内容进行操作。
(2)分类
a、主要参与者和次要参与者。主要参与者是指执行系统主要功能的参与者,次要参与者是指使用系统次要功能的参与者。标出主要参与者有利于找出系统的核心功能,往往也是用户最关系的功能。
b、发起参与者和参加参与者。发起参与者发起了用例的执行过程,一个用例只有一个发起参与者,但可以有若干个参加参与者。
(3)注意事项
参与者可以表示人,但参与者不是指人或事物本身,而是表示人或事物当时所扮演的角色。例如小王是图书管理员,当他借阅图书时,他的身份又变成了图书借阅者,所以参与者的名字应该是图书管理员和图书借阅者,而不是小王。
(4)参与者表示图例
(5)参与者之间的关系
参与者之间常见的关系是泛化,也就是继承,泛化针对的是父类,继承针对的是子类。
2、用例
(1)用例是对系统的用户需求(主要是功能需求)的描述,表达了系统的功能和所提供的服务,用来描述“做什么?”用例和参与者之间的关系是关联关系,又称为“通信关系”。
(2)用例粒度:指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大,用例包含的功能越多,反之功能越少。
(3)用例规约(主要属性)
a、事件流:包括基本流和备选流。基本流描述用例的基本流程,备选流描述的是用例执行过程中可能发生的异常或偶尔发生的情况。
b、用例场景:用例在执行时发生的不同情况成为用例场景。包括成功场景和失败场景。
c、特殊需求:指的是一个用例的非功能性需求(包括可靠性,性能,可用性 和可扩展性等)和设计约束(包括开发工具,操作系统,环境,兼容性等)。例如法律或法规方面的需求。
d、前置条件:执行用例前系统必须所处的状态。例如:前置条件要求用户有访问权限或是要求某个用例必须已经执行完成。
e、后置条件:用例执行完成成系统可能处于的一组状态。例如:要求在某个用例执行完成后,必须执行另一个用例。
3、关系
(1)泛化关系
泛化关系指的是父用例和子用例之间的关系,一个父用例可以被泛化出多个子用例。子用例继承父用例所有的结构,行为和关系,同时还可以添加行为。父用例通常是抽象的。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。
泛化关系是用带空心三角箭头的直线表示。
(2)扩展关系
在一定条件下,把新的行为加入到已有的用例中,获得新的用例叫做扩展用例,原有的用例叫做基础用例,从扩展用例到基础用例叫做扩展关系。
扩展关系是带箭头的虚线加<extend>字样来表示。
好处:
a、降低系统复杂度,提高系统性能;
b、易于处理基础用例中不易描述的问题,是系统显得更加清晰,易于理解。
(3)包含关系
包含关系代表基础用例会用到被包含的用例,具体将就是将被包含用例的事件流插入到基础用例的事件流中。
主要有两种情况使用包含关系,一种是把几个用例的公共部分抽象出来成为一个新的用例(例如下图中前部分抽象出的用户管理),另一种是一个用例的功能过多,事件流过于复杂,可以把某几个用例抽象成一个用例(例如下图中后半部分抽象出的登录)。
包含关系用带箭头的虚线加<include>字样来表示。
包含关系和扩展关系的区别:
a、基础用例的执行并不一定会涉及到扩展用例,扩展用例只有在满足一定条件下才会被执行。而在包含关系中,当基础用例执行后,被包含用例是一定会被执行的。
b、即使没有扩展用例,扩展关系中的基础用例本身就是完整的。而对于包含关系,基础用例在没有被包含用例的情况下就是不完整的存在。
c、在扩展关系中,基础用例提供了一个或者多个插入点,扩展用例为这些插入点提供了需要的插入行为。而在包含关系中,插入点只有一个。
机房收费系统用例图展示
整体用例图:
一般用户用例图:
操作员用例图:
管理员用例图:
小结
第一次画图,认识的还很粗浅,如有不正确的地方,还望大牛给与纠正。