《软件工程》学习笔记（三）

9.1 用例建模概念

为什么要用用例建模

  用例模型可以很好地描述系统的功能性需求。在UML中，一个用例模型通常由若干个用例图组成，用来表示系统实现的业务过程、描述系统的工作方式。

用例模型的分类

  用例模型可以包含文本描述和用例图描述。用例图有利于宏观地了解系统,文本描述则给出了参与者和用例的具体信息。用例建模过程中更重要的是对用例进行描述,而画图只是其中的一小部分工作。

文本描述

用例图描述

用例图的主要元素

用例

定义系统的一系列行为，并通过此可为参与者提供有价值且可观测的结果。

定义一个参与者要用到的系统功能

描述系统为实现参与者价值所开展的行为序列

对参与者与系统之间的交互活动进行建模

从特定的用户角度出发，是完整的，实现特定用户价值的事件流

参与者

与系统交互的人

与系统交互的硬件组件

或者其他的外部系统

关注的重点是所承担的“角色”

参与者的名要明确定义其角色

关联

参与者与用例之间的交互通道

用一条直线表示交互——关联

有箭头的关联指出是谁发起的交互

没有箭头则表明双方都可以发起交互

9.2 用例建模过程

  用例建模包括两个步骤。

第一步（寻找参与者和用例）

  找到参与者和用例，利用客户的需求和系统的潜在使用者信息来寻找用例和参与者。（可以通过下面的一些问题进行辅助）

  找到潜在的参与者之后，我们需要进一步识别参与者。通过“是谁真正与系统发生交互”这个问题来判别参与者。

基本策略：把自己当作actor，与设想中的系统进行交互。

  确定用例和确定参与者不能截然分开。

识别用例

第二步（编写用例，补充用例的事件流）

用例的文本描述

用例的命名

命名要求：

· 表明参与者的目标或者作用

· 使用主动语态：用动词起始

· 设计一系列操作流程（to-do list）

用例建模过程中的检查项

给用例事件流程划分重要等级

用例的生命周期

用例文档模板

按照重要程度排序详细描述事件流程

9.3 用例建模精讲

明确系统边界

  不同的系统边界定义决定了与系统交互的对象、参与者与系统的交互方式，进而影响了用例模型的设计。

用例与功能分解

何时使用包含关系

何时使用扩展关系

  在定义扩展用例关系时，需要说明扩展条件以及扩展点。

用例中的主要图标

9.4 建模工具介绍

系统建模工具的主要功能

  建模工具希望通过可视效果辅助用户表达和理解模型，可辅助进行需求跟踪、团队管理等复杂的功能。

常见的系统建模工具

  适合有一定规模的开发团队使用，辅助项目管理和需求管理等操作。

JUDE的特点：在于轻量级和用户友好性，它非常专注于UML模型的构建。

JUDE不足：对于UML2.0仅仅部分支持。