4-用例图

2.1 视与图

2.1.1 视(重要)

概念

从多个方面来描述一个复杂的系统，不同的视描述系统的不同方面。

4+1视(重要)

软件系统结构可用5个视来描述：用例视、设计视、过程视、实现视和配置视，UML的各种图为系统的不同的视建模提供工具。

各个视之间的关系

5个视彼此相关、交互作用，运用它们可对软件系统进行全方位的描述。

各个视与对应的UML(重要)

用例视

通过用例描述了可以为最终用户、分析人员和测试人员所看到的系统行为。视的静态方面由用例图描述，动态方面由交互作用图、状态图、活动图描述。

设计视

包括问题域词汇表和解决方案的类、接口和协作，支持系统功能需求，即系统提供给最终用户的服务。视的静态方面由类图和对象图描述，动态方面由交互作用图、状态图、活动图描述。

过程视

包括形成系统的并发和同步机制的线程和过程，描述系统的性能、可扩展性和总处理能力。视的静态方面由类图和对象图描述，动态方面由交互图、状态图、活动图描述。

实现视

包括用于组装物理系统的组件和文件，主要描述系统版本的配置管理。系统版本由独立的组件和文件构成的可运行系统。视的静态方面由组件图描述，动态方面由交互图、状态图、活动图描述。

配置视

包括构成用于运行软件系统的系统硬件拓扑的节点，主要描述物理系统组成部分的分布、交付和安装。视的静态方面由配置图描述，动态方面由交互图、状态图、活动图描述。

4.2 用例图

4.2.1 用例图 (重要)

描述了用例、参与者以及它们之间的关系。

1. 用例（Use Case）
2. 参与者（Actor）
3. 依赖、类属和关联关系
4. 系统边界

用例模型

用例模型处于需求分析阶段，是系统开发者与用户反复讨论的结果，表示开发者与用户之间对需求规格定义达成了共识。UML中，一个用例模型由若干个用例图描述，用例图的主要元素是用例和参与者。

用例图示例(重要)

下图中，用例与参与者之间是双向导航关联关系。一般而言，参与者与用例间是多对多的关系。用例捕捉系统行为但不规定如何实现这些行为，通过协作来实现，协作是实现用例的类和其它元素的总称。

下图中，“Pay for bill”用例由“Deal with bill”协作来实现。每个给定的用例都由一个相应的协作来实现，因而一般不必显式地为这种关系建模。

类属关系(泛化,Generalization)

类属、包含、扩充关系。应用这些关系抽取出公共行为和变种。

【箭头指向】：指向父用例

扩充关系(Extend)

说明可选的、只在特定条件下运行的行为，基于参与者的选择可运行几个不同的流。

基用例可独立存在，但在特定条件下，它的行为将被另一个用例的行为扩充。基用例只在被称为扩充点的特定点被扩充。可认为，扩充用例将行为推进基用例。

如果一个用例明显地混合了两种或两种以上不同的场景，可以将这个用例分为一个基础用例和一个扩展用例.扩展关系用<>关系表示，箭头指向基本用例（也就是从子类指向父类）。

与此同时，扩展用例是基础用例在某些特定条件下触发产生的，扩展用例不是基础用例必须存在的部分，扩展用例可以单独存在，扩展用例知道基础用例的存在而基础用例不知道基础用例的存在。

一个用例可以有多个扩充点，每个扩充点也可出现多次。

下图中，考试失败是扩充点，特定条件下的行为置于补考用例中

元素符 总览(重要)

2.为系统的需求建模

需求规定了用户期望系统做什么。系统的全部或大部分需求可以表达为用例。为系统需求建模时：

1. 确定环绕系统的参与者，建立系统上下文
2. 考虑每个参与者期望的行为
3. 抽取常见的行为作为用例
4. 确定被其它用例使用的用例或用来扩充其他用例的用例
5. 在用例图中描述用例、参与者及它们的关系
6. 用注释来描述非功能需求