课件

9.1 用例建模概念.pdf

用例在需求管理过程中的作用

在产品开发过程中，需求的管理尤为重要，高效管理需求的工具多种多样，用例建模便是其中之一。

随着项目的开展我们可以通过一系列的需求活动管理，去挖掘系统的相关信息，通过分析问题理解干系人的需求。
在定义系统的过程中，我们可以利用简略地用例规约对系统的功能和业务过程进行表示。
融入领域相关信息后，对系统进行细化完善，形成更加详细的用例规约描述。在这过程中，我们逐步形成了完整的用例模型，进而可以管理变化的需求。

为什么需要用例建模

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

首先我们可以通过用例模型将干系人的需求和软件的需求建立关联，确认与系统交互的人或者对象，即我们所谓的参与者，定义系统的边界，捕捉和表达系统的理想行为（也就是用例）。

这个模型就像我们去餐馆看到的菜单，通过菜单我们知道这个餐厅可以提供哪些菜品、所属菜系、相应价格等相关的信息。这就如同我们通过用例模型来理解以及表示系统为我们提供的服务。所以通过用例模型有利于对需求进行验证和确认，并辅助规划开发的过程。

用例模型的表示

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

文本描述中包含用例模型概要以及用例规约描述：

模型概要中简要介绍系统的功能与意义
列出相关的参与者
列出相关用例

在每一个具体的用例规约中，将详细描述用例中会发生什么操作或事件、涉及的非功能性需求、规则约束等。也就是要对每一个用例的事件流进行描述。

用例模型的另一种表示是用例图。用例图用来显示一组用例参与者以及它们之间的关系。下图是银行ATM机的用例模型案例，先思考下以下问题：

ATM涉及哪些业务？
ATM会与哪些系统或对象进行交互？
不同对象、系统是如何和ATM进行交互的？

图中包含了四种不同的身份的用户、五个用例及它们之间的关联关系。除了上述的三个问题之外我们可以从中发现更丰富的信息，比如发现用例的优先级，这个信息有利于在开发过程中进行进度规划，就这个例子而言，最重要的莫过于取款功能，如果缺失了这个功能则整个ATM系统就没有存在的价值了，其它的类似于存款转账等更多的是给系统锦上添花的功能。这是一种划分用例优先级的判断规则，同时我们也可以根据用例服务的对象来判断，为主要客户和参与者提供的业务服务一定是优先级很高的用例，其它的功能另类似于提供额外的管理或者技术操作的用例并非系统的主要业务，也并不直接服务于主要参与者，所以相对优先级较低，例如图中的收取存款和日常维护等用例，再如打印日志、开启服务、备份系统等一类管理性的用例是系统所必需的但非首要的用例，可以在其它的用例图中进行组织。

用例图的主要元素

基于ATM机系统的用例模型认识，下面讲解用例图中的元素和相关表示方法。

参与者：即与系统交互的人或外部系统；
用例：即系统为参与者提供的有价值的服务功能，用椭圆表示；
关联：用例图中描述用例与参与者之间的交互关系。通常用直线或带箭头的直线表示；

用例

用例定义了系统的一系列行为，通过此可以为参与者提供有价值且可观测的结果。有几个地方需要额外注意：

首先是用例的命名，表示系统的功能服务，因此这应该是一个动宾结构。例如应该命名为注册课程而不是课程注册。再看定义中用例用来表示系统的行为，代表功能性需求，要牢记系统是这个服务的提供商。同时这个功能实际上涵盖了一系列的原子操作，代表着参与者和系统之间的交互过程，这些操作是原子性的，每一个都应该是完全执行或者完全不执行的。
用例往往用来和用户确认需求，辅助开发团队规划开发进度，因此定义的用例的服务对象一定是系统最终的使用用户，也就是参与者。而不要为了开发人员或者需求分析师定义用例，而且这些用例一定要有可观测的结果，这样才可以用来确认系统是否达到了用户的预期目标。
如何定义一个有价值的用例是比较具有挑战的，应该注意用例定义的力度要适中，过细的力度定义体现为用例不能为参与者提供足够的价值，这个时候需要和其它的用例合并，形成一个相对完整的流程来达到参与者的目的。另外一种情况是过粗力度的定义，比如说选课系统中一个叫做操作选课系统的用例就太过宽泛了，我们可以根据不同角色用户的使用目的或者使用方式，将这个用例拆分细化

概括而言，用例描述了系统的功能性需求，每个用例给出的是一个细化的系统行为需求。用例表示系统为参与者提供的服务和价值，参与者与系统的每种不同的交互方式都是一个用例，穷举所有的用例可得到完整的需求描述。用例的特点在于通过自然语言描述参与者与系统的交互活动、描述系统的职责、描述系统必须做什么而非如何做，这就像系统将销售记录写入数据库这样的用例是并不合时宜的。因此用例模型的一个重要作用就是作为黑箱测试设计的参考，同时用例提供需求的上下文情境，将系统的需求用逻辑序列进行表述，解释说明为什么需要这个系统，其易理解的性质便于确保与干系人的理解是一致的，规范化的表达形式让其拥有较强的复用性，可以应用于文档撰写和系统设计、测试等各个环节。

参与者

在定义用例的时候，我们往往需要依赖参与者的信息，那设计参与者的时候应该注意哪些问题？

首先来看参与者通常表示什么，这里需要在系统的实际使用用户和参与者之间做一个转换，不同的使用者用同样的模式与系统进行交互，同时一个使用者也以不同的身份使用相同的系统。例如学生可能是选课同学也可能是助教，银行柜台人员可能是银行的客户等等。所以我们应该注重用户所承担的角色，在命名的时候要体现出角色的特性。

举例，参与者定义与角色划分：

例如在选课系统中有两个使用者成为两个用户实例，即李雷和韩梅梅。李雷和寒梅梅都具有学生的角色，所以他们都具有注册课程的权利，而李雷作为教授身份的时候还具有提交成绩的权利，因此参与者的定义是依据角色而划分的，我们需要将用户角色和用户实例进行区分。

关联

关联表示参与者与用例之间的交互通道，通常用一条直线来表示这种交互关系。系统中往往有很多参与者与同一个用例相关联，通常将获取用例提供价值的参与者定义为主参与者，主参与者是服务的主要受益方，但并不一定是主动发起交互的一方。在用例模型中我们通常使用箭头来表示交互的发起方和接收方，箭头代表的信息约束性较强，因此建议仅当有明确需求说明时按照箭头的使用规范进行表示。

通过火警报警器的例子说明一下箭头的使用规范：

在这两个图中，均有系统交互人员主动发起交互，监控火警报警器，两个图的区别在于上图中明确表明了被动传感器与警报器的交互模式，被动传感器需要接收系统的消息，等待系统询问当前状态进而与监控系统进行交互，而主动传感器相反需要主动传递信息，例如定时给系统上传自己当前的状态，混合传感器不指明交互箭头表示可以作为消息的发起方或者接收方，例如定时每60秒上传状态信息，当超过75秒后系统若仍未收到其信息将会向混合传感器发起询问消息。下图中没有箭头则表示对于主被动传感器的交互方式无明确的约束。

根据箭头的意义我们可以明确箭头的使用约束：

如果图中标明了箭头相应的信息，也应该在用例文本描述中有所体现，标志在何种情况下进入用例
箭头表示并不是必须的，仅当需求中有明确的定义时才进行使用
一种异常的表示是如果有两个或两个以上的箭头指向了同一个用例，在大部分情形下是一个指向用例的箭头，其余的箭头应该是由力指出或无方向
箭头的方向只表示消息的传递方向，而不表示那个参与者创建用例或者是用例服务的受益方

关联代表一个完整的对话：

一个交互代表着参与者与系统之间的一个完整对话。以注册课程为例，学生登录到系统，系统验证学生登录成功后，学生可向系统发起请求获取课程信息，随后系统向课程目录系统发起信息查询的请求，课程目录系统返回相关的课程的信息，系统再将相应的信息展现给学生，学生进而可以选择课程，系统进一步处理请求，将相关的课程纳入课程表。以上的过程形成了一个完整的事件流，在用例的文本描述中进行撰写。

场景(Scenario)—用例的实例

上述的过程仅仅是我们平常与选课颗系统交互的情境之一，很多时候系统会根据我们不同的信息进入不同的场景，因此我们可以将场景理解为用例的一个实例，一个用例会有不同的场景也就意味着会有不同的事件流，在文本描述时需要将这些不同的场景分别进行描述。例如下图给出的两个场景样例：

场景可以表达正面的行为需求，也可以表达反面的，不希望发生的交互还可以包括并行机制，在每个选择点进行一种情况的具体描述。而例外是是情境的重要变体，表明了会对企业产生严重影响的事件流，后面将给出例子。