前些时间参加了潘加宇老师的技术讲座,UML建模技术受益匪浅。我也把平时的一些积累和上次的收获总结在这篇文章中,主要讲解用例图相关的知识。
用例图是软件需求分析到最终实现的第一步,它描述用户如何使用系统及使用系统什么样的功能。用例图从业务角度上体现谁来使用系统、用户希望系统提供什么样的服务,以及用户需要为系统提供的服务,也便于软件开发人员最终实现这些功能。用例图在开发中被广泛的应用,但是它最常用来描述系统提供了什么样的功能给什么样的用户使用。
在官方文档中用例图包含六个元素,分别是:执行者(Actor)、用例(Use Case)、关联关系(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。但是有些UML的绘图工具多提供了一种直接关联关系(DirectedAssociation)。
用例图可一个包含注释和约束,还可一个包含包,用于将模型中的元素组合成更大的模块。有时,可以将用例的实例引入到图中。用例图模型如下所示,执行者用人形图标来标识,用例用椭圆来表示,连线表示它们之间的关系。
一、执行者(Actor)
1、执行者概念
是指用户在系统中扮演的角色。如图1-1是一个用户管理的用例图,图中的用户、管理员就是用例的执行者。
图1-1
2、从业务中找出执行者
获取系统用例首先要找出系统的执行者。我们可以通过用户回答一些问题的答案来识别执行者。可以参考以下问题:
谁使用系统的主要功能(主要使用者)?
谁需要系统支持他们日常工作?
谁来维护、管理系统使其正常工作(辅助使用者)?
系统需要控制哪些硬件?
系统需要其他哪些系统交互?这里包含其他计算机系统或者应用程序。
对系统产生结果感兴趣的是哪些人和哪些事物?
3、执行者之间关系
因为执行者是类,所以多个执行者之间可以具有与类相同的关系。在用例图中,使用了泛化关系来描述多个执行者之间的公共行为。如果系统中存在几个执行者,它们既扮演自身的角色,同时也扮演更具一般化的角色,那么就用泛化关系来描述它们。这种情况往往发生在一般角色的行为在执行者超类中描述的场合。特殊化的执行者继承了该超类的行为,然后在某些方面扩展了此行为。执行者之间的泛化关系用一个三角箭头来表示,指向扮演一般角色的超类。这与UML中类之间的返还关系符号相同。图1-2
图1-2
二、用例(Use Case)
1、用例概念
用例就是外部可见的系统功能,对系统提供的服务进行描述。
2、从业务中找出用例
找出系统的用例,我们从执行者入手,对每个执行者提出一些问题,然后从执行者对这些问题的答案中获取用例。可以参考以下问题:
执行者要求系统提供哪些功能(执行者需要做什么)?
执行者需要读、产生、修改、删除或者存储系统中的信息有哪些类型?
执行者必须提醒系统事件有哪些?把这些事件表示成系统用例。
3、用例之间关系
二、用例之间关系
1、关联关系(Association)
关联关系是连接执行者和用例,表示该执行者代表的外部系统实体与该用例描述的系统需求有关。
图1-3
2、包含关系(Include)
包含关系是来自于用例的抽象,即从数个不同的Use Case中,分离出公共的部分,而成为可以复用的用例。
图1-4
3、扩展关系(Extend)
扩展关系表示某一个用例的对话流程中,可能会根据条件临时插入另外一个用例,而前者称为基础用例后者称为扩展用例。
图1-5
4、泛化关系(Generalization)
一个用例可以被特别列举为一个或多个用例,这被称为用例泛化,如果系统中一个或多个用例是某个一般用例的特殊化时,就需要使用用例的泛化关系。