Java建模: UML工作簿，第 3部分

需求收集是任何成功的软件开发周期中不可缺少的一步。虽然有众多的需求收集方法，但是最普通的方法是用例建模。在 先前的两个专栏中，我们已经完成了一部分将序列图同用例建模关联起来的工作。这次我将更多地谈论方法之后的理论，并且也增加一些您的建模词汇。

这次讨论中，我更关心的是阐明用户接口、系统接口和用例描述之间的关系。因为所建立的大多数系统将被设计成人机交互式的，所以将用例描述设计成以用户接口开始运行是很诱人的。但是在用例中包括用户接口逻辑通常被认为是不好的形式。这种说法的一个简单解释是，用户接口提供一个系统透视图的系统概貌。用例总是以参与者（或用户）透视图被描述。

为了真正理解为什么我们在用例描述中不包括 UI 逻辑，我想无论如何我们不得不采用亲身实践的方法。我们将使用我的 第一个专栏中的贷款申请的示例，并且您将看到用例是如何随着尺寸的增大而变得复杂的。特别地，我们要注意在用例建模中透视图的角色。随着我们的深入，您将看到透视图是怎样被用来为您工作的，或者，如果被不正确地应用，它是如何阻碍您工作的。

什么是用例模型？

一个用例模型由一张图表和一组阐明该用例的描述组成。一个用例是在一个系统中的一组可能的交互，它的参与者朝着同一个被定义的目标进行。这些描述描述了系统中该用例的功能性；这张图表提供了这些描述的可视化路标。UML 规定了建立用例图表的标准，但并不是为了编写用例描述的。结果产生了许多编写用例描述的方法，这些方法有时是互相竞争的。

最流行的编写用例描述的方法体现着 Ivar Jacobson （用例建模的发明者）的思想。Jacobson 的方法涉及一系列进入和退出的准则，分别被称作 前置条件和 后置条件，和一个称为 事件流的核心准则。这个事件流描述了一系列参与者（用户或外部系统）和被制定的系统之间的交互。这个事件流代表一个经过系统的通向成功输出的单一路径。这是用例描述的核心部分，但不是全部。

事件流的交替和例外

除描述中心事件流之外，用例描述必须说明那些发生在普通事件流之外的交互。例如录像带租用用例的主要事件流（在简单情况下）可以如下表示：

录像带租赁店店员扫描顾客的会员卡。

系统取得会员名和他目前的租赁状况。一个“允许租赁”状态表示这个顾客可以租用录像带。

录像带租赁店店员扫描每盘被租借的录像带。

系统通过扫描每盘录像带，将可出租的录像带加入到用户可见的列表中，并显示当前的可出租的录像带列表。

录像带租赁店店员输入应收取的钱的数量（如果是现金）或者扫描信用卡。

系统标记这盘录像带为已在某段时间被出租并且打印这笔交易的收据。

但是如果顾客在上次租借中欠了逾期费怎么办？在她能再次租借她所选的录像带之前，她需付清所欠的逾期费。逾期费的交互表现为一个 交替流或 例外流。事件流的交替和例外是很正常的。在某些情况下，他们可以被纠正以重新开始正常的事件流，在其他情况下，他们则达不到目标。在我们的示例中，如果顾客付了逾期费和这次的租金，那她就达到了继续租借录像带的目的了。

用例建模中的事务处理

伴随着它的交替和例外，事件流是由一系列的事务处理组成。事务处理是由参与者发起，并且当系统等候来自参与者的触发信号时完成的交互（注意完成事务处理的参与者不一定就是发起该事务处理的参与者）。事务处理允许我们把用例分割成更小的元素，并在每个决定点上将逻辑分组。决定点是在描述中参与者必须作出决定或者提供额外信息的那个点。

所有的事务处理是由一个参与者和一个系统交互组成。您将极少需要计划一个没有启动的系统，即使这个启动仅仅以时间为基础。当建立用例模型

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!