UML图总结-需求分析阶段用例图的使用
1 前言
最近过年因为新冠病毒的肆虐各公司都开始放长假了,初步估计都是要出了元宵才能回成都上班,虽然返岗之前要在家办公(上班),但是还是得做点欠着的事情舍,其中比较重要的一个就是我的毕业设计嘞,一两个月就要交初稿了,但是我还没开始嘞
由于毕业设计需要用到各种UML图,所以就趁这个机会好好复习和总结一下软件工程课程有关UML图的相关内容吧,毕竟这个在软件设计和分析的流程中还是占据比较重要的地位,也是软件分析的利器,能帮助我们快速分析我们要做的事情,也能使我们要做的东西一目了然,接下来就直接开始总结和复习吧,就以我的毕业设计——一个简单的在线考试系统为例开始我们的学习之旅
2 什么是用例图
用例图是指由参与者(Actor)、用例(Use Case),边界以及它们之间的关系构成的用于描述系统功能的视图。
用例图(User Case)是外部用户(被称为参与者)所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者,一些用例,以及它们之间的关系,主要用于对系统、子系统或类的功能行为进行建模。
例如我们在线考试系统的业务用例图:
teacher用例
3 用例图的构成要素
简单来说就是:用例图是由参与者(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成的一个表达系统功能的图示。
接下来分别介绍其成分。
3.1 参与者
参与者(Actor)是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。
简单来说就是:一个系统的使用者,可能涉及的角色就是一个参与者
比如说我们在线考试系统中的老师和学生就分别是两个参与者
每个参与者可以参与一个或多个用例,每个用例也可以有一个或多个参与者。
在用例图中使用一个人形图标来表示参与者,参与者的名字写在人形图标下面。
Actor
3.2 用例
简单来说就是:用例是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。
简单打个比方,比如说我们考试系统中一个老师可以登录系统,那么登录系统这个动作就是一个用例,当然老师还可以做一些其他的事,可以发布考试,创建试卷,那么发布考试和创建试卷这两个行为也分别是老师的两个用例
3.3 系统边界
系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分,边界外表示系统外部。系统边界在画图中用方框来表示,同时附上系统的名称,参与者画在边界的外面,用例画在边界里面。因为系统边界的作用有时候不是很明显,所以我个人理解,在画图时可省略。
4 如何构建较完整的用例图
4.1 如何识别用例
要创建用例,我们需要分析哪些可以作为用例,如何识别,可以从以下几点来确定用例:
- 通过参与者分析:
- 参与者希望系统能够提供什么样的功能?
- 参与者是否会读取、创建、修改、删除、存储系统的某种信息?如何完成这些操作?
- 参与者是否会将外部的某些事件通知给系统?
- 通过系统分析:
- 系统中发生的事件是否通知参与者?
- 是否存在影响系统的外部事件?
4.2 用例的粒度
用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大,用例包含的功能越多,反之则包含的功能越少。
简单来说就是:如果用例的粒度很小,得到的用例数就会太多。反之,如果用例的粒度很大,那么得到的用例数就会很少。
比如在我们的考试系统中:我们的老师可以对试卷进行管理,那么展示出来的粒度较大的用例可以是这样:
粒度较大用例
如果我们按照具体的操作把它抽象成多个用例(粒度变小),它也可以是这样的:
粒度较小用例
它展示的系统需求和单个用例是完全一样的。
4.3 用例之间的关系
用例之间的关系包括以下几种:
- 包含
- 扩展
- 泛化
1.包含
包含关系指用例可以简单地包含其他用例具有的行为,并把它所包含的用例行为作为自身行为的一部分。在UML中,包含关系是通过带箭头的虚线段加<>字样来表示,箭头由基础用例(Base)指向被包含用例(Inclusion)。