用例建模上的用户接口逻辑

在用例建模上的用户接口逻辑

顾问, TogetherSoft
2001 年 6 月 13 日

在 这一部分的 Java 建模中，Granville引领您进入介于建模和方法之间的区域，同时看一下通过用例建模所收集的需求。他特别着重讨论了用户接口、系统接口和用例描述之 间的关系。尽管现在正试图在用例中包括用户接口逻辑，但这通常被认为是不好的形式。接着，Grancille用序列图和系统接口告诉您具体原因。请点击文 章顶部或底部的 讨论，参与讨论论坛，与本文作者和其他读者分享您对本文的想法。

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

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

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

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

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

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

• 录像带租赁店店员扫描顾客的会员卡。
• 系统取得会员名和他目前的租赁状况。一个“允许租赁”状态表示这个顾客可以租用录像带。
• 录像带租赁店店员扫描每盘被租借的录像带。
• 系统通过扫描每盘录像带，将可出租的录像带加入到用户可见的列表中，并显示当前的可出租的录像带列表。
• 录像带租赁店店员输入应收取的钱的数量（如果是现金）或者扫描信用卡。
• 系统标记这盘录像带为已在某段时间被出租并且打印这笔交易的收据。

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