今天学习了一下UML建模部分的用例图,做个总结:
用例图的定义:
由Actor 、 Use Case以及他们之间的关系构成的用于描述系统功能的动态视图称为用例图。
用例图是需求分析中的产物,主要作用是描述参与者和用例之间的关系, 帮助开发人员可视化的了解系统的功能。
用例图的组成:
参与者:
参与者(Actor)是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。通常而言一个参与者可以代表一个人,一个计算机子系统,硬件设备或者时间等。
如何确定参与者呢?
确定参与者可以从以下几个问题入手:
.系统开发出来后,使用系统主要功能的是谁?
.谁需要借助系统来完成日常的工作?
.系统需要从哪些人或其他系统中获得数据?
.系统会为哪些人或其他系统提供数据?
.系统会与哪些其他系统交互?其他系统可以分为两类,一类是该系统要使用的系统,二是启动该系统的系统,包括计算机系统和计算机中的其他应用软件。
.系统是由谁来维护和管理的,以保证系统处于工作状态?
.系统控制的硬件设备有哪些?
.谁对本系统产生的结果感兴趣?
参与者之间的关系:
参与者之间也存在一定的关系,例如泛化关系,泛化关系可以理解为面向对象语言中的继承,用一个空心箭头符号表示,例如职员是销售经理的父类,那么在UML中可以做如下表示:
用例:
用例的概念:
用例其实对于参与者来说就是可以感受到的系统服务或者功能单元。它定义了系统如何被参与者使用的。
比如对于一个教学管理系统来说,用例可以是登录模块,可以是成绩录入模块,可以是修改成绩模块等等。
非常重要的是,用例也是一个类,而不是一个具体实例,他描述的是代表的功能的各个方面,包含了用例执行期间可能发生的各种情况。
用例的识别:
那么如何确定一个用例呢?同样也可以从以下问题入手来寻找用例:
参与者希望系统提供什么功能?
参与者是否会读取,创建,修改,删除,存储系统的某种信息?如果是的话,参与者又是如何完成这些操作的?
参与者是否会将外部的某些事件通知给系统?
系统中发生的时间是否通知参与者?
是否存在影响系统的外部事件?
总而言之,用例图的主要目的就是帮助人民了解系统功能,便于开发人员与用户之间的交流,所以确定用例的一个很重要的标准就是用例应当易于理解。
3.用例的粒度
用例的粒度是指用例所包含的系统服务或者功能单元的多少。用例的粒度越大,用例包含的功能越多,反之则包含的功能越少。
比如一个维护学生信息可以分解成添加学生信息,修改学生信息,删除学生信息等子用例。
关联:
接下来谈论一下比较重要的概念是关联,关联有以下几种关系:包含(Include)、扩展(Extend)、和泛化(Generalization)。
1.包含关系:
包含关系是指用例可以简单地包含其他用例具有的行为,并把它所包含的用例行为作为自身行为的一部分。
图形表示是这样的:
具体的说:
多个用例如果用到同一段的行为,则可以吧这段共同的行为单独抽象成为一个用例,然后让其他用例来包含这一用例。
举个栗子:
比如现在有添加资源和修改资源两个用例,其中,添加资源和修改资源都具有预览的功能或者动作,那么就可以这么做:
2.扩展关系:
在一定条件下,把新的行为加入到已有的用例中,获得的新用例称为扩展用例(Extension),原有的用例就称为基础用例(Base),从扩展用例到基础用例的关系就是扩展关系。
如图所示:
需要注意的是:扩展和包含是有本质区别的,其中扩展关系中基础用例本身就是完整的,然而对于包含关系来说,基础用例在没有被包含的用例的情况下就是不完整的存在。
比如上面的添加资源如果没有预览资源,就是不完整的。
3.泛化关系:
泛化关系指的是一个父用例可以被特化成多个自用例,父用例和子用例之间的关系就是泛化关系。在泛化关系中,子用例继承了父用例所有的结构、行为和关系,自用例就是父用例的特殊形式,这个和面向对象中的继承类似。
例如订票和电话订票、网上订票就是这样一种泛化关系。子用例继承父用例的所有特性,再在父用例上加上自己的一些特性,这和包含关系有本质不同,包含关系中是把多个基础用例中的共性抽象为一个被包含用例,可以说被包含用例就是基础用例中的一部分,基础用例的额执行必然会引起被包含用例的执行。