软考之用例模型

用例概念理解

用例模型主要由以下模型元素构成：

参与者(Actor)

• 参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。

用例(Use Case)

• 用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

通讯关联(Communication Association)

• 通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。

这大三种模型元素在UML中的表述如下图所示

• 

通讯关联表示的是参与者和用例之间的关系，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者；如果你不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在参与者和用例之间的信息流不是由通讯关联来表示的，该信息流是缺省存在的（用例本身描述的就是参与者和系统之间的对话），并且信息流向是双向的，它与通讯关联箭头所指的方向亳无关系。

事件流

• 用例描述的是参与者与系统之间的对话，对话的细节
  用事件流进行描述。

事件流分类

基本事件流

• 描述正常流程
  备选事件流
• 描述异常终止流程

小结

优点：

• 用例方法站在用户的角度（从系统外部）来描述系统的功能，将需求与设计分离，在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。

• 用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。

用例建模

用例模型主要包括以下两部分内容：

用例图(Use Case Diagram)

• 确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。

用例规约(Use Case Specification)

• 针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。

寻找参与者

所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：

• 系统开发完成之后，有哪些人会使用这个系统？
• 系统需要从哪些人或其他系统中获得数据？
• 系统会为哪些人或其他系统提供数据？
• 系统会与哪些其他系统相关联？
• 系统是由谁来维护和管理的？

这些问题有助于我们抽象出系统的参与者。对于ATM机的例子，回答这些问题可以使我们找到更多的参与者：操作员负责维护和管理ATM机系统、ATM机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。

系统边界决定了参与者

参与者是由系统的边界所决定的，如果我们所要定义的系统边界仅限于ATM机本身，那么后台服务器就是一个外部的系统，可以抽象为一个参与者。

如果我们所要定义的系统边界扩大至整个银行系统，ATM机和后台服务器都是整个银行系统的一部分，这时候后台服务器就不再被抽象成为一个参与者。

用例规约

用例规约用以描述每一个用例的详情，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的，RUP-统一软件过程中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：

简要说明 (Brief Description)

• 简要介绍该用例的作用和目的。

事件流 (Flow of Event)

• 包括基本流和备选流，事件流应该表示出所有的场景。

用例场景 (Use-Case Scenario)

• 包括成功场景和失败场景，场景主要是由基本流和备
  选流组合而成的。

特殊需求 (Special Requirement)

• 描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。

前置条件 (Pre-Condition)

• 执行用例之前系统必须所处的状态。

后置条件 (Post-Condition)

• 用例执行完毕后系统可能处于的一组状态。

注：用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。

基本流

基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。我们建议用以下格式来描述基本流：

• 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。

• 用一句简短的标题来概括每一步骤的主要内容。

• 当整个用例模型基本稳定之后，我们再针对每一步骤详细描述参与者和系统之间所发生的交互。建议采用双向(roundtrip)描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应。

在描述参与者和系统之间的信息交换时，需指出来回传递的具体信息。例如，只表述参与者输入了客户信息就不够明确，最好明确地说参与者输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内，可以在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。

备选流

备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。在描述备选流时，应该包括以下几个要素：

• 起点：该备选流从事件流的哪一步开始；

• 条件：在什么条件下会触发该备选流；

• 动作：系统在该备选流下会采取哪些动作；

• 恢复：该备选流结束之后，该用例应如何继续执行。

备选流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容，编号前可以加以字母前缀A(Alternative)以示与基本流步骤相区别。

用例场景

用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；在用例规约中，场景的描述可以由基本流和备选流的组合来表示。场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。

特殊需求

特殊需求通常是非功能性需求，它为一个用例所专有，但不适合在用例的事件流文本中进行说明。特殊需求的例子包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些设计约束，如操作系统及环境、兼容性需求等，也可以在此节中记录。

需要注意的是，这里记录的是专属于该用例的特殊需求；对于一些全局的非功能性需求和设计约束，它们并不是该用例所专有的，应把它们记录在《补充规约》中。

前置和后置条件

前置条件是执行用例之前必须存在的系统状态，后置条件是用例一执行完毕后系统可能处于的一组状态。

检查用例模型

用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查：

功能需求的完备性

• 现有的用例模型是否完整地描述了系统功能，这也是我们判断用例建模工作是否结束的标志。

模型是否易于理解

• 用例模型最大的优点就在于它应该易于被不同的涉众所理解，因而用例建模最主要的指导原则就是它的可理解性。用例的粒度、个数以及模型元素之间的关系复杂程度都应该由该指导原则决定。

是否存在不一致性

• 系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成的，所以要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在模型内部产生不一致性。不一致性会直接影响到需求定义的准确性。

避免二义性语义

• 好的需求定义应该是无二义性的，即不同的人对于同一需求的理解应该是一致的。在用例规约的描述中，应该避免定义含义模糊的需求，即无二义性。

系统需求

RUP中根据FURPS+模型将系统需求分为以下几类：

• 功能(Functionality)
• 可用性(Usability)
• 可靠性(Reliability)
• 性能(Performance)
• 可支持性(Supportability)
• 设计约束等

除了第一项功能性需求之外的其他需求都归之为非功能性需求。

需求工件集

用例模型主要用于描述系统的功能性需求，对于其他的非功能性需要用其他文档来记录。RUP中定义了如下的需求工件集合。

• 用例模型：记录功能性需求
• 用例图：描述参与者和用例之间的关系
• 用例规约：描述每一个用例的细节信息
• 补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等
• 词汇表：记录一些系统需求相关的术语

在实际应用中，除了这些工件之外，我们还可以根据实际需求灵活选用其他形式的文档来补充说明需求。并不是所有的系统需求都适保合用用例模型来描述的，如编译器，我们很难用用例方法来表述它所处理的语言的方法规则，在这种情况下，采用传统的BNF范式来表述更加合适一些。在电信软件行业中，很多电信标准都是采用SDL语言来描述的，我们也不必用UML来改写这些标准（UML对SDL存在着这样的兼容性），只需将SDL形式的电信标准作为需求工件之一，在其他工件中对其加以引用就可以了。总之，万万不可拘泥于用例建模的形式，应灵活运用各种方式的长处

补充规约

补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容。

功能性

• 功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。有些功能性需求是全局性的，适用于所有的用例，如出错处理、I18N支持等，我们不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。

可用性

• 记录所有可用性相关的需求，如系统的使用者所需要的培训时间、是否应附合一些常见的可用性标准如Windows界面风格等。

可靠性

• 定义系统可靠性相关的各种指标，包括：
  • 可用性：指出可用时间百分比(xx.xx%)，系统处于使用、维护、降级模式等操作的小时数；
  • 平均故障间隔时间(MTBF)：通常表示为小时数，但也可表示为天数、月数或年数；
  • 平均修复时间(MTTR)：系统在发生故障后可以暂停运行的时间；
  • 精确度：指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）；
  • 最高错误或缺陷率：通常表示为bugs/KLOC（每千行代码的错误数目）或bugs/function-point（每个功能点的错误数目）。

性能

• 记录系统性能相关的各种指标，包括：
  • 对事务的响应时间（平均、最长）；
  • 吞吐量（例如每秒处理的事务数）；
  • 容量（例如系统可以容纳的客户或事务数）；
  • 降级模式（当系统以某种形式降级时可接受的运行模式）；
  • 资源利用情况：内存、磁盘、通信等。

可支持性

• 定义所有与系统的可支持性或可维护性相关的需求，其中包括编码标准、命名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。

设计约束

• 设计约束代表已经批准并必须遵循的设计决定，其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等等。

词汇表

词汇表主要用于定义项目特定的术语，它有助于开发人员对项目中所用的术语有统一的理解和使用，它也是后续阶段中进行对象抽象的基础。

调整用例模型

关系描述

参与者与用例

参与者与参与者

• 泛化
• 继承

用例与用例

• 包含(include)
• 扩展(extend)
• 泛化(generalization)

包含

• 包含关系是通过在关联关系上应用<< include>>构造型来表示的，如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion)，具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。

graph LRA(基础用例) -->|include| B(被包含用例)

在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例"打印回执"，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。

graph LRA(银行客户) --> B(查询)A --> C(提款)A --> D(转账)B -->|include|E(打印回执)C -->|include|ED -->|include| E

扩展

• 扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。

• 对于包含关系而言，子用例中的事件流是一定插入到基础用例中去的，并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。

graph TBA(扩展用例) --> B(打电话) C(呼叫等待) --> |extend|BD(呼叫转移) --> |extend|B

例如对于电话业务，可以在基本通话(Call)业务上扩展出一些增值业务如：呼叫等待(Call Waiting)和呼叫转移(Call Transfer)。我们可以用扩展关系将这些业务的用例模型描述如下。

graph LRA(电话用户) -->|extend| B(基础用例)

泛化

• 当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。

graph BTA(子用例1) --> B(父用例)C(子用例2) --> B

• 在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。