系统分析之三 使用用例建模系统需求

使用用例建模系统需求

 

一、用例建模的系统概念

一）用例建模的产物

1、 用例图

以图形化的方式将系统描述成用例、参与者及其之间的关系。在高层交流了系统必须处理的业务事件的范围。

2、 用例描述

填充了每个业务事件，并说明了用户如何同系统交互的细节。

二）用例建模中的基本概念

1、 用例：

用于描述业务事件或系统功能。

一个用例代表了系统的一个单一的目标，描述为实现此目标的活动和用户交互的一个序列。

用例在项目的整个生命周期中不断细化：需求获取阶段，捕捉业务问题的本质，建模建议的系统的高层功能，确定系统的数据实体或对象的起点；需求分析阶段，用例被细化，更详细的建模系统的使用；设计阶段，继续细化，建模用户如何实际使用系统，考虑界面和系统约束条件，辅助确定对象或系统行为，设计界面和代码说明，并作为测试系统的计划；构造阶段，辅助开发人员进行编码和测试。

2、 参与者

发起或者触发用例的外部用户称为参与者。参与者可以是一个人、一个外部系统、一个组织、一个外部设备，甚至可以是时间。

分类：主要业务参与者（从用例执行中获得好处的关联人员）、主要系统参与者（直接同系统交互，发起或触发业务或系统事件的关联人员）、外部服务参与者（响应来自用例的请求的关联人员）、外部接收参与者（从用例接收某些可度量的或可观察的输出的关联人员）。

3、 关系

1） 关联关系

用例和参与者之间的关系。实线箭头表示参与者发起用例；没有箭头的关联关系表示用例与外部服务参与者或外部接收参与者交互。

2） 扩展关系

一个用例包含多个步骤的复杂功能，可以将复杂的步骤提取出来作为专门的用例，这个用例与原用例之间的关系为扩展关系。

用例2和用例3是用例1的扩展用例。扩展关系用例不在需求阶段确定，而在分析阶段确定。

3） 使用（包含）关系

多个用例包含相同的功能步骤时，提取为独立的用例，该用例称为抽象用例。抽象用例代表了某种形式的复用，可以降低用例冗余。

如下图用例2和用例3包含用例1，用例1为抽象用例。抽象用例不在需求阶段确定，而在分析阶段确定。

4） 依赖关系

用于建模用例之间的依赖关系。为项目安排和用例开发顺序提供

下图表示，用例2和用例3依赖用例1。

5） 继承关系

参与者之间的关系。当多个参与者共享同样的行为时，将这些公共的行为分配给一个新的抽象参与者，降低与系统通信的冗余。

二、需求用例建模过程

构建需求用例模型的目的是提取和分析足够的需求信息，准备一个模型，该模型表述了用户需要什么，而不涉及系统将如何构造和实现的特定细节。

一）确定业务参与者

信息源：上下文图，现有系统的文档和用户手册，项目会议和研讨会的记录，现有的需求文档、项目章程或工作陈述。

回答下面问题：谁或者什么为系统提供输入？谁或者什么接收系统的输出？需要与其它系统连接的接口吗？是否存在在预定的时间自动触发的事件？谁将维护系统中的信息。

二）确定业务需求用例

用例使用输入的名词前加一个行动动词命名。

回答下面问题：参与者的主要任务是什么？参与者需要系统什么信息？参与者为系统提供什么信息？系统需要通知参与者发生的变化或时间吗？参与者需要通知系统发生的变化和事件吗？

触发组织内的业务事件的主要输入被认为是用例，系统请求的结果并不作为输入。

三）构造用例模型图

四）记录业务需求用例描述

参照下面的用例描述模块进行用例描述

三、用例和项目管理

一）分级和评估用例

二）确定用例依赖关系

四、过程模板

一）参与者词汇表

参与者

同义词

描述

行业用户

 

 

维护用户

 

 

主站系统

 

与子站系统通讯，并发送命令请求给子站系统。

保护装置

 

与子站系统通讯，并发送保护信息给子站系统，接收子站系统的查询命令

自动控制装置

 

 

录波器装置

 

 

 

 

 

 

二）用例描述的高层版本：

保护故障信息子站系统

作者：

 

 

 

 

日期：

 

 

 

 

版本：

用例名称

 

用例类型：

业务需求

用例ID

 

优先权

 

来源

 

主要业务参与者

 

其它参与者

 

其它有兴趣的关联人员

 

描述

 

 

三）用例描述的扩展版本：

保护故障信息子站系统

作者：

 

 

 

 

日期：

 

 

 

 

版本：

用例名称

 

用例类型：

业务需求

用例ID

 

优先权

 

来源

 

主要业务参与者

 

其它参与者

 

其它有兴趣的关联人员

 

描述

 

前置条件

 

 

 

触发器

 

 

 

典型事件过程

参与者动作

系统响应

 

 

 

 

 

 

 

 

替代事件过程

 

结论

 

后置条件

 

业务规则

 

实现约束和说明

 

假设

 

开放问题

 

 

四）用例分级和评估矩阵：

说明：

该工具用于评估首先开发哪些用例。按照以下分级进行打分，总分越高，优先级越高，越需要提前开发。

分级标准中的1到6分别指1、对架构设计的重要影响；2、容易实现单包含重要功能；3、包含有风险、时间紧迫或者复杂的功能；4、需要大量的研究或者新的、有风险的技术；5、包含主要的业务功能；6、将增加或者减少费用。

用例名称

分级标准（1-6）

总分

优先级

构建周期

1

2

3

4

5

6

用例a

5

5

5

5

5

5

30

高

1