课件

9.2 用例建模过程.pdf

构建用例模型的步骤

用例建模包含两个步骤：

• 第一步：找到所有的参与者和用例。利用客户的需求和系统的潜在使用者信息来寻找用例和参与者。
• 第二步：编写用例。补充用例的事件流。

第一步：寻找参与者

1.1 抽取使用者角色

可以通过一些问题进行辅助。例如：

• 是谁或者是什么在使用系统？理解系统的设计目的服务于哪些人或者物，根据不同的用户类型表示为不同的参与者。
• 系统外部与系统进行交换的人或者物也应该设计为参与者，它们用来传输消息或者接受消息。
• 公司的哪个部门会使用这个系统？
• 谁负责系统的维护？
• 哪些系统会使用当前的系统？

通过这些问题可以帮助我们抽取使用者的角色。

1.2 进一步识别参与者

找到潜在的参与者之后，需要进一步识别参与者，通过一个非常简单的问题来识别，这个问题就是：是谁真正与系统发生交互？下面举例说明：

在最开始的时候学生是不能直接操作中心选课系统的，是通过教务人员根据学生的需要操作选课系统进行相入课程的录入，随后产生了在线选课系统，在这个时候学生是可以直接与在线系统进行交互的，所以在中心选课系统中，学生并不是参与者，而在在线选课系统中学生是参与者之一。

1.3 参与者描述

确认了参与者之后，则需要在用例文档描述中对参与者信息细化：

参与者定义时考虑的是用户的身份，因此参与者的名称应该要明确指明参与者与系统交互时的身份，同时要注意参与者的命名要唯一，以便与其他参与者进行区分。一个命名为用户的参与者是非常不恰当的，因为这个名字很难了解用户真正的身份。随后要对参与者进行简要的描述，具体的内容包括“这个参与者代表了哪些用户”、“为什么会需要这个参与者”、“参与者对于系统的需求具体的是什么”。紧接着给出参与者与用例的关系。这里再向大家额外介绍一种特殊的参与者，在一些系统中用例通常是在特定的时间被触发，例如月底、每天零时等，这里我们可以抽象出一类特殊的参与者，可以将其命名为调度器或者时钟，相比较而言使用调度器作为参与者的名称更好，因为这个可以是人或者非人为的控制器，而时钟则更像是设计模型中的一个具体对象。

1.4 参与者建模的检查项

最后我们可以根据下述的标准去判断对于参与者的建模是否合理：

• 是否找全所有的参与者？是否对系统环境中所有的角色进行了描述和建模？
• 每个参与者是否至少与系统中的一个用例发生了交互？
• 是否可以为每一个角色找到至少两个应用实例？
• 不同参与者与系统的交互是否一致，扮演的角色是否相似？如果有这样的情形出现，则需要考虑将这些参与者合并为同一种角色

1.5 寻找用例

在寻找参与者的同时要描述系统为参与者提供的服务，以至参与者如何与系统交互，这个就是寻找用例的过程。最好的方式就是把自己也当作参与者，与设想中的系统进行交互。

在寻找用例时需要注意的问题是，不要一开始就尝试去捕捉所有的细节，我们要全面的认识和定义每一个用例，要点是与穷举的方式去考虑每个参与者与系统的交互情况。要注意寻找用例和寻找参与者的过程是不能完全分开的。

1.6 识别用例

可以通过下述的问题，来辅助寻找和识别用例的过程：

• 每个参与者的目标是什么？
• 为什么需要这个系统？
• 参与者是否需要对系统中的数据进行创建，存储，更改，删除或读取的操作？为什么？
• 参与者是否需要将外部事件或发生的改变告知系统？
• 参与者是否需要知道系统内部发生的事件或改变？
• 同时也不要忘记系统启动终止或维护等这些用例、调度器根据时间触发的用例等等

注意在设计过程中，避免用例颗粒度过细或过粗的现象。一些简单的辨别规则请参考用《用例建模概念》里的介绍。

1.7 用例的描述

确定了用例之后，需要对其进行文本描述。

• 用例的名称应该是唯一的，清楚地表达了参与者与系统交互的目标，所以我们要注意使用动宾结构作为名称
• 用例的简要描述中介绍了参与者和系统如何交互，系统需要进行哪些原子操作等。在敏捷开发的过程中，每一次迭代可以选择部分用例进行细化描述，通过这样的方式设置用例的优先级可以保证重要的功能尽快完成交付
• 最后需要建立参与者与用例之间的关联关系

1.8 用例的命名

用例的命名应该表明参与者的目标或者作用，应该使用主动的语态而且是一个动宾结构（从动词开始），并且，这个用例的背后应该包含设计一系列操作流程。

基于命名规范请分析下述的表达形式有什么问题：

有一种默认的判别规则来判别用例命名是否合适，那就是将主参与者的名称与应用的名称连成句子去看是否有实际的意义。

1.9 用例建模过程中的检查项

完成了用例的定义之后，可以通过下述规则来验证用例模型是否完善：

• 用例建模是为了表示系统的行为。所以我们可以通过用例模型很好地理解系统的相关操作
• 用例模型中应该标识所有的用例，来表达客户所有的需求
• 系统的任何一个特性都可以找到对应的用例
• 用例模型并不包含多余的行为，所有的用例都可以追湖到系统的功能性需求以作为验证
• 在设计用例的时候很多人会加上“创建、查找、更新、删除”等一类的用例，我们简称其为CRUD类的用例，对于这一类的用例，可以用一个更通用的用例来概括，比如“增加顾客、删除顾客、更新顾客信息和查看顾客信息”合并，叫做维护顾客信息

第二步：编写用例

构建模型的第二步就是要为每一个用例进行具体的文档描述，具体包括给用例事件流程划分重要等级、按照重要程度排序详细描述事件流程。

在第一步寻找用例和参与者的过程中，已经对用例进行了简要描述，在第二步中编写用例的过程就是将上一步所得到的简单描述进行扩展，形成用例提纲。用例提纲涵盖了大致的事件流程，随后我们将其细化，增加条件说明等形成更加详细的规约。

后面将以注册课程为例进行说明。

用例的全生命周期

用例建模的过程是逐步扩充、迭代细化的。首先我们通过分析需求，识别到用例。例如下订单，进一步我们需要简要描述这个用例的意义，大概用两到三句话描述清楚即可。通过这个简述的内容我们把基础事件流抽取出来形成用例提纲，通过提纲可以大致了解用例的规模和复杂程度。通过将事件流中的选择条件、约束等进一步细化，增加前置、后置条件，完成用例详细规约描述，这个细化过程往往是配合开发过程迭代进行的，所以需要考虑需求的优先程度。

例子，下订单这个用例的简述表示形式：

• 用例描述：只需要用简练的语言表达清楚用例的意图即可。
• 需要涵盖事件流的主要部分

用例概述例子：

• 将主体事件流抽出，需要兼顾不同的场景

详细用例规约的例子：

用例文档模板

UC_id：用例名
描述：对该用例的一句或两句的描述。
参与者：参与该用例的参与者。
包含：该用例所包含的用例，以及包含它的用例。
扩展：该用例可以扩展的用例，以及扩展它的用例。
泛化：若该用例的子用例和父用例。
前置条件：启动此用例所必须具备的条件。
细节：该用例的细节。(基本流与可选流)
后置条件：在该用例结束时确保成立的条件。
例外：在该用例的执行的过程中可能引起的例外。
限制：在应用中可能出现的任何限制。
注释：提供可能对该用例是重要的任何附加信息。

总结：Use Case模型的建立步骤

1. 找出系统外部的参与者和外部系统，确定系统的边界和范围
2. 确定每一个参与者所期待的系统的行为
3. 把这些系统的行为命名为Use Case，也就是用例
4. 通过泛化、包含、扩展等关系处理系统行为的公共或者变更的部分
5. 为每一个用例编制脚本
6. 绘制相应的用例图
7. 区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单独的用例进行处理
8. 最后细化用例图，解决用例之间可能存在的重复和冲突的问题