本文通过《机房收费系统》这个实例来介绍一下UML中的用例图,说的不对or不妥的地方还请高手指点。
先说说用例图的功能
用例图主要用来图示化系统的主事件流程,它主要用来描述客户的需求,即客户希望系统具备完成什么功能,通俗的理解用例就是软件的功能模块。所以设计系统分析阶段的起点,设计人员根据客户的需求来创建和解释用例图,用来描述软件应具备哪些功能模块及这些模块间的调用关系,以求把系统的整个结构和功能反映给非技术人员(通常是软件的用户),对应的是软件的结构和功能分解。
用例图主要包含的元素
用例图主要包括角色、用例及他们之间的关系。
一.角色(Actor)
角色有人也称其为执行者,是指用户在系统中扮演的角色。
1.如何从业务中找出用例
获取系统用例首先要找出系统的角色,我们可通过用户回答一些问题来识别角色。可参考以下问题:
①谁使用系统的主要功能(主要使用者)?
②谁需要系统支持他们日常工作?
③谁来维护、管理系统使其正常工作(辅助使用者)?
④系统需要控制哪些硬件?
⑤系统需要与其他哪些系统交互?这里包含其他计算机系统或应用程序。
⑥对系统产生结果感兴趣的是哪些人和哪些事物?
2.角色之间的关系
由于角色是类,所以它拥有与类相同的关系,在用例图中只用泛化关系描述若干个角色之间的行为。
泛化关系:是把某些角色的共同行为(原角色中的部分行为),抽取出来表示成通用行为,且把它们描述成为超类(superclass)。
例如:"机房收费系统"中抽象出的角色为:一般用户、操作员、管理员,下图描述了他们之间的关系。
二.用例(Use Case)
用例是外部可见的系统功能,对系统为某一个或几个参与者提供的服务进行描述。
1.如何从业务中找出用例?
找出系统的用例,我们从角色入手,对每个角色提出一些问题,然后从角色对这些问题的答案中获取用例。
①角色要求系统提供哪些功能(角色需要做什么)?
②角色需要读、产生、修改、删除或者存储系统中的信息有哪些类型?
③角色必须提醒系统事件有哪些?把这些事件表示成系统用例。
2.用例间的关系
从原则上讲,用例间都是独立、并列的,它们之间并不存在着包含从属关系。但为了体现一些用例间的业务关系,提高可维护性和一致性,用例间可抽象出包含、扩展和泛化几种关系。
①包含关系(include)
包含关系:来自于用例的抽象,即从数个不同用例中,分离出公共部分,而成为可复用的用例。
当两个或多个用例中共用一组相同的动作,这时可以将这组相同的动作抽出来作为一个独立的子用例,供多个基用例所共享。因为子用例被抽出,基用例并非一个完整的用例,所以include关系中的基用例必须和子用例一起使用才够完整,子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注<<include>>),箭头从基用例指向子用例。
例如:"机房收费系统"中操作员完成的"注册"功能中,注册包含几个小的功能,下图描述了他们之间的包含关系。
②扩展关系(extend)
extend关系是对基用例的扩展,基用例是一个完整的用例,即使没有子用例的参与,也可完成一个完整的功能。extend的基用例中将存在一个扩展点,只有当扩展点被激活时,子用例才会被执行。extend关系在用例图中使用带箭头的虚线表示(在线上标注<<extend>>),箭头从子用例指向基用例。
例如:"机房收费系统"中各"导出到Excel表"的功能就是各基用例的扩展用例,下图展示了"操作员"中需要"导出到Excel表"的用例的扩展关系图。
③泛化关系(Generalization)
泛化关系是一种继承关系,子用例将继承基用例的所有行为、关系和通信关系,也就是说在任何使用基用例的地方都可以用子用例来代替。泛化关系在用例图中使用空心实线箭头表示,箭头方向从子用例指向基用例。
例如:"机房收费系统"各用例之间没有展现泛化关系,下面这个小例子也展现了泛化关系。
三.角色与参与者之间的关系
角色和参与者之间的关系一般是关联关系,表示该角色代表的外部系统实体与该用例描述的系统需求有关。
四.UML用例图中用到的关系汇总
附:"机房收费"用例图。
下面"机房收费系统"用例图,我是按角色划分的,划分了三个角色:一般用户、操作员、管理员。
一般用户用例图
操作员用例图
管理员用例图