用户模型视图——用例图

编写系统的用例图有助于在初始开发阶段构建系统的业务需求。

用例模型描述的就是外部参与者所理解的系统功能。用例模型用于需求分析阶段，是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。

 

• 首先，它描述了待开发系统的功能需求；
• 其他，它将系统看做黑盒，从外部执行者的角度理解系统；
• 第三，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统。

用例图可以显示谁将是相关的用户，用于希望系统提供什么服务，以及用户需要为系统提供的服务，用来为系统的功能建模。用例图常用来描述系统与子系统。简单的说，用例图就是参数者，用例，以及它们之间的关系构成的图，该图说明了用例模型中的关系。

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）泛化关系没有扩展，也没有包含，例如“数据查询”是基础用例，那么“基础查询”和“高级查询”就是“数据查询”的扩展。

 

总体设计+分块设计