用例图的构成
1 角色:人员角色——人、事;
角色不一定局限于人,还可以是事物、事儿
2用例:功能的描述;
每一个用例描述了一个完整的系统服务
3 系统边界
4 关系:执行者与用例之间的关系。
泛化
依赖
关联
聚合,组合
实现
从图中可以看书,角色,系统边界,用例和角色与用例间的关系。所有的用例都在系统边界内,表示它属于一个系统。角色则放在系统边界外面。表名角色并不属于系统,但是角色负责直接驱动与之关联的用例的执行。
1 角色
通常用一个稻草人图符表示。
角色由用户承担。角色的存在是因为角色与系统具有交互行为。否则角色就不必要了。再次角色是一个类,而不是一个对象。因此可以引入类之间的继承关系。
角色之间的关系
由于角色实质上也是类,所以它拥有与类相同的关系描述,即角色之间存在着泛化关系,泛化关系的含义把某些角色的共同行为提取出来表示为通行的行为。
2 用例
用例用来描述角色可以感受到的完整的功能,在UML规格文本中,用例被定义为“由系统执行的一个动作序列。并能产生可观察的结果值给某个特定的角色。
(1) 用例通常由某个角色来驱动执行。
(2) 用例把执行结果的值反馈给角色。
(3) 用例在功能上具有完整性。
图符表示为椭圆形
用例的主要属性
l 事件流
l 前置条件
l 后置条件
l 特殊要求
l 扩展点
l 问题说明
事件流描述一个用例在执行者与系统之间的交互过程,这个过程包含多个分支。包含
基本流
备选流
===================================================================================
用例之间的关系
l 包含关系
业务中,总是存在着维护某某信息的功能,如果将它作为一个用例,那新建、编辑以及修改都要在用例详述中描述,过于复杂;如果分成新建用例、编辑用例和删除用例,则划分太细。这时包含关系可以用来理清关系。
l 泛化关系
子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。
扩展关系
系统中允许用户对查询的结果进行导出、打印。对于查询而言,能不能导出、打印查询都是一样的,导出、打印是不可见的。导出、打印和查询相对独立,而且为查询添加了新行为。扩展关系的基本含义和泛化关系类似,但在扩展关系中,对于扩展用例有更多的规则限制,基本用例必须声明扩展点,而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样,扩展关系也是依赖关系的版型。在扩展关系中,箭头的方向是从扩展用例到基本用例,这与包含关系是不同的
用例的粒度和范围
l 概述级
l 用户目标
l 子功能
用例的粒度,子功能抽象,成为复用的关系。
关系
n 泛化
n 依赖
n 关联
n 实现
具体的用例分析中,可能需要实际分析,期间的困难是难免的。这里就给大家实例一个例子。
下图是机房收费系统的具体用例图事例
作者信息见(网易博客 http://hanhan2010.blog.163.com/ )