软件项目实训及课程设计指导——UML用例事件流和用例规约的描述示例

软件项目实训及课程设计指导——UML用例事件流和用例规约的描述示例

1.1 用例事件流和用例规约

1、UML中的用例模型方法所存在的主要问题

（1）采用用例图对软件系统需求的描述是不全面的

由于用例图仅能描述软件系统中的功能性的需求，而不适合描述非功能性的需求和设计约束等方面的信息；另外，用例图也不能描述出软件系统中的每个用例所对应的业务流的实现过程等方面的信息。下图所示为某个BBS论坛系统的后台管理的用例图局部截图：

（2）还应该辅助采用UML顺序图和活动图

因此，为了能够准确和全面地描述软件系统中的功能性的需求，除了要采用UML用例图描述软件系统的功能性需求以外，还应该辅助采用UML的顺序图或者UML的活动图描述每个用例的业务流的实现过程。下图所示为某个BBS论坛系统中用户发表文章用例的活动图，该活动图实现对一个参与者所触发的用例实现过程的描述，从而也可以说明BBS论坛系统中用户发表文章用例的实现过程。

2、UML中的用例实现的事件流

（1）用例的事件流也称为用例规约（Use Case Specification）

用例的事件流是对完成用例行为所需的各个事件的描述——事件流描述了一个用例的行为实现的主要过程。用例事件流的主要作用在于能够通过一个清晰的、易被用户理解的时间流来说明一个用例的行为过程——应该要针对每一个用例都设计有一个用例事件流文档与之相对应。

在Rose工具中是将某个用例的事件流直接写在该用例的属性对话框的文本框中，下图所示为某个系统中的“系统登陆”用例及对应的事件流描述内容的局部截图。

（2）为什么要采用用例事件流辅助进行用例建模

UML用例图只是在总体上大致地描述了软件应用系统所应该要提供的各种功能，但这样的描述是比较“粗糙”的，还需要描述每一个用例实现过程的更加详细的信息——因为用例模型是由用例图和每一个用例的用例规约所组成的。

通过对用例的业务实现过程的分析和理解，一方面能够帮助开发人员对所获得的软件系统中的各个用例进一步地细化和了解，另一方面也为后续的动态建模提供一定的分析基础。用例事件流的描述方式可以采用结构化语言和UML的活动图或者顺序图等方式实现。

3、采用结构化语言描述用例的事件流

（1）一个完整的用例事件流的组成部分

1）简要说明（Brief Description）：简要介绍该用例的作用和目的；

2）前置条件（Pre-Condition）：开始使用该用例之前必须满足的系统和环境的状态和条件，该条件为必要条件而不是充分条件；

3）用例主事件流或者基本路径（Flow of Event）：用例的正常流程（事件流是关注系统干什么，而不是怎么干），也称为用例的路径；

4）其它（备选）事件流：用例的非正常流程，如错误流程等。基本路径和备选事件流组合在一起而形成用例场景（Use-Case Scenario）；

5）后置条件（Post-Condition）：用例成功结束后系统应该具备的状态和条件（但不是每个用例都有后置条件）。

（2）采用结构化语言描述用例的事件流的示例

在用例事件流中要对事件流进行结构化说明并描述出主事件流和备选事件流的内容。下表所示为银行账户信息管理系统中用户成功登录系统后，可以修改自己的个人注册信息——如密码等信息用例的事件流。

（3）采用结构化语言来描述用例的事件流所存在的缺陷

不能反映出某个用例随着时间的变化情况——它只能够反映出该用例的基本实现流程，而且也不能够表示出完成这个用例时所需要涉及到系统中的哪些对象及这些对象之间的交互状况等方面的信息。

1.2 利用UML顺序图描述用例的事件流

1、UML顺序图及主要的特性

UML顺序图能够描述软件系统中对象之间的交互状况——强调消息按照时间顺序的交互状况，因为对象通过相互间的通信（也就是消息传递）进行合作，并在其生命周期中根据通信的结果而不断地改变自身的状态。

通常，顺序图显示特定用例产生的事件并且侧重于描述消息在对象之间是如何传送的。实现按时间顺序对控制流建模——体现用例的实现过程。它能够显示出随着时间的变化对象之间是如何通信的、同时也清楚地表示在实现某个用例时所涉及的各个对象等信息。

顺序图中的纵向维坐标代表时间，按时间的先后依次向下排序；而横向维坐标则代表交互过程中的不同对象。因此，UML顺序图能够便于分析对象交互的时序、而且也非常适用于表示面向对象程序中消息流的交互建模中的有关信息。

2、顺序图面向软件系统开发中不同角色的人员所起的作用

（1）软件系统的使用者用户

软件系统的使用者用户从中可以看到业务实现过程的细节——因为每个用例可以通过顺序图中的一个或者多个场景来精确地描述出。

（2）系统分析人员

在面向对象分析方法中，对象间的交互是通过对象间消息的传递来完成的。当一个对象调用另一个对象中的方法时，也就完成了一次消息的传递。而当对象中的方法执行完成后，控制流便返回到调用者中。因此，系统分析人员利用顺序图不仅能够发现出系统中的各个类中的方法，也能够验证这些类中的方法是否合理。

（3）编程开发人员

编程开发人员利用顺序图能够了解到需要开发的各个对象和它们内部的方法，因为对象间的通信其实也就体现在各个对象之间的方法相互调用。

（4）测试人员

测试人员利用顺序图能够看到业务实现过程的细节，并根据这个业务实现过程和功能要求开发出对应的测试用例程序。下图为某个项目中用户登录的顺序图示例：

3、采用UML顺序图描述用例的事件流

顺序图显示参与交互作用的参与者和用例实现过程中的各个对象、以及按时间排序的事件——能够体现用例的实现过程。

在UML中的消息图形表示方法是用带有箭头的线段将消息的发送者和接收者联系起来，箭头的类型表示消息的类型、方向为从源对象指向目标接收者对象，其上标有表示消息的文字内容的标签。下图所示为银行账户信息管理系统中的转账用例的事件流的实现过程的顺序图。

顺序图反映了参与者与系统之间的交互状况，应该尽力保持消息的顺序从左到右排列——在图中的最左边放置参与者、并依次放置其他对象。并采用和用例图中一致的名称命名参与者，同时也应该采用和类图中一致的类名称来命名顺序图中的各个类——请见前图所示的图例。

4、采用UML顺序图描述用例事件流的优缺点

顺序图不仅能够反映出某个用例随着时间的变化情况，而且也还能够表示出完成这个用例时所涉及到的各个对象，从而为需求分析中发现出系统中的类提供一定的帮助——它能够辅助分析人员发现出应用系统中的各个类。当然，采用顺序图描述用例的事件流同样也存在有一定的不足。

1）首先，顺序图不适合描述复杂的并发关系的业务流；

2）另一方面也无法描述包含有复杂的逻辑关系（如条件判断等）的业务流。

此时，应该再辅助采用UML活动图来完善对用例事件流的描述。

1.3 利用UML活动图完善对用例事件流的描述

1、UML动态建模中的活动图

UML中的活动图本质上就是面向过程设计方法中的流程图——它可以图示某个用例的业务实现过程。从系统内部视角来看，UML活动图反映的是系统功能所要完成的动作过程。通过活动图定义出工作流从哪里开始、到哪里结束，在工作流中发生了哪些活动及其顺序等方面的信息。

活动图中的活动是工作流执行期间完成的任务，并且活动具有原子性（不能被分解成更小的部分）、不可中断（一旦开始就必须运行到结束）和瞬时性（动作状态所占用的处理时间通常是极短的，甚至是可以被忽略的）。

当然，对活动图中的活动的理解依赖于对应用系统分析的抽象层次——比如，在系统的业务抽象的概念层次描述中，每个活动则表示需要完成的一项任务。而在功能实现层次的描述中，活动则表示类中的方法。

2、UML动态建模中的活动图主要的作用

利用活动图不仅可以为参与者对系统的操作行为进行建模，也可以描述某个用例的实现过程（业务流）——UML活动图本质上就是面向过程设计方法中的流程图，因此也可以图示某个用例的业务实现过程。但与顺序图也存在许多不同点——顺序图重点描述对象在不同的时间段内的表现，而活动图是基于对象的状态变迁而绘制出的UML视图。

3、带泳道的UML活动图

活动图中的活动可以被分成为几个不同的区域，每个区域在活动图中由于采用虚线分开而形成泳道——每一个泳道可以对应于一个协同，其中的活动可以由一个或多个相互连接的类对象实例实现、并且属于某个泳道的活动应该要放在该泳道所对应的矩形框内。

泳道能够将活动图中的各个活动分组，并指定负责每一组活动的业务组织对象。因此，采用带泳道的活动图可以用于建模某些复杂的业务活动实现的过程。因为活动图中的泳道能够区分活动的不同职责，每一个活动都只能明确地属于一个泳道和该泳道所对应的对象。下图所示为某个网上书店项目中的团体购书的客户活动图局部截图：

4、采用UML活动图描述用例的事件流

在UML中的动作状态使用带圆端的方框表示，并且在活动图中可以有活动状态、分支、合并、泳道、对象流状态、状态类、信号发送和信号接收等组成元素。下图所示为银行账户信息管理系统中普通用户请求成为VIP用户的请求过程的带泳道活动图。

注意：

仅仅从上面所罗列出的对系统的“功能性需求”进行描述的不同方式中可以了解到，采用单一的“UML图”是无法全面和完整地描述应用系统中的需求。对于一个比较复杂的应用系统，用一个或者一种形式的“UML图”是不足以说明清楚的。

因此，需要从多个不同的角度来描述系统。当然，对于一个比较简单的应用系统，只需要选择一个角度并且以部分视图进行描述。