编写系统的用例图有助于在初始开发阶段构建系统的业务需求。
用例模型描述的就是外部参与者所理解的系统功能。用例模型用于需求分析阶段,是系统开发者和用户反复讨论的结果,表明了开发者和用户对需求规格达成的共识。
- 首先,它描述了待开发系统的功能需求;
- 其他,它将系统看做黑盒,从外部执行者的角度理解系统;
- 第三,它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统。
用例图可以显示谁将是相关的用户,用于希望系统提供什么服务,以及用户需要为系统提供的服务,用来为系统的功能建模。用例图常用来描述系统与子系统。简单的说,用例图就是参数者,用例,以及它们之间的关系构成的图,该图说明了用例模型中的关系。
1 用例图的元素——用例(use case)
用例的定义:在不展现一个系统或子系统内部结构的情况下,对系统和子系统的某个连贯的功能单元的定义和描述。本质上讲:一个用例是参与者与计算机之间的一次典型交互作用。用例是一个叙述性的文档,用来描述一个参与者使用系统完成某个事情时事情发生的顺序。
用例的特点:
- 用例捕获某些用户可见的需求,实现一个具体的用户目标。
- 用例由执行者激活,并提供确切的值给执行者
- 用例可大可小,但它必须是对一个具体的用户实现目标的完整描述。
用例符号:
2 用例图的元素——参与者(actor)
参与者是系统外部的一个实体(可以是任何事物或人),以某种方式参与了用例的执行过程,通过向系统输入或请求系统输入某些事件来触发系统的执行。参与者种类有:系统用户、与所建造的系统交互的其他系统和一些可以运行的进程。
参与者符号:
用例之间的关系:
泛化(Generalization)、包含(Include)、扩展(Extend)。
关联:参与者与其参与执行的用例之间的通信途径
消费者是一个actor,“登录”,“修改信息”,“购买商品”等行为是用例,那么消费者和这些行为之间存在着关联关系。
扩展:在基础用例上插入基础用例不能说明的扩展部分
由用例A连向用例B,表示用例B描述了一项基本需求,而用例A描述了该基本需求的特殊情况。
上图中,“电话订餐”扩展了“打电话”。
泛化:用例之间的一半和特殊关系,其中特殊用例继承了一般用例的特性并增加了新的特性。
用例和用例、参与者与参与者之间存在着父子关系,则可以使用泛化。
“上网”是一种行为,那么“手机上网”和“PC上网”是“上网”的2种特殊形式,则称这2种特殊形式泛化了“上网”行为。
包含:在基础用例上插入附加的行为,并具有明确的描述
包含关系是一种(因子化)重组关系,当几个用例具有共同的行为时,这个共同行为可以抽象为一个公共用例。由用例A连接用例B,表示用例A包含用例B中的行为或功能。
ATM系统中,取款、查询余额、转账都需要确认用户信息,那么可以将“确认用户信息”抽象为公共用例,其他3个用例包含这个公共用例。
举例:
ATM取款机系统用例图
一个ATM取款机的基本功能:客户可以登录、存钱、取钱、查询余额、转账和修改密码,通过分析,得知参与者只有一个,就是客户,用例包括:
(1)存款
(2)取款
(3)查询
(4)登录
(5)转账
(6)汇款
(7)修改密码
(8)打印收据
上图中,用户(actor)可以有取款、转账、登录、查询、存款、打印收据等用例行为,而这些行为都必须包含“确认用户信息”这一公共用例。
用例图的四种关系:
(1)一般情况下是关联。
(2)如果几个用例共同包含一个用例,且这个公共用例只是那几个用例的一个步骤时,比如“打印收据”和”确认用户信息“,只有先确认完用户信息,才能打印收据,但确认用户信息又是公共用例,则采用包含关系。
(3)特殊化和一般化,类似于类和实例之间的关系,使用泛化。
(4)在一个用例之上增加一些新规则,比如“电话订餐”不仅仅是“打电话”,而且还包含了订餐的步骤,则使用扩展关系。
(5)当一个用例需要细化时,可以考虑包含关系,例如:用户管理包含新建用户、编辑信息和删除用户3个用例。
(6)扩展用例为基础用例增加新的行为,例如“查看报表”是基础用例,那么“打印报表”就是扩展用例。
(7)泛化关系没有扩展,也没有包含,例如“数据查询”是基础用例,那么“基础查询”和“高级查询”就是“数据查询”的扩展。
总体设计+分块设计