一个相似的示例

　　我们将使用一个相似的贷款处理申请来建立一个由互连系统组成的系统的模型。到现在，我们已经建立了提交贷款请求用例的模型，但是这个用例实际上只是一个较大的贷款处理系统的一部分。贷款提交系统和其进行交互的商业资信咨询机构是两个必须合作以提供必要的数据来处理贷款请求的系统。在现实生活中，还会涉及额外的系统。然而，我们的示例仅仅讨论两个系统。图 2 显示了两个系统、贷款提交和商业资信咨询机构系统以及我们将在这个专栏的余下部分着重讨论的交互。(注意，图 2 不是一个 UML 图表;它是一个真实世界的图表，目的是简单地图示这两个系统和它们之间的交互。)

　　图 2. 两个系统之间的交互

　　正如我们前面图表说明的那样，图 3 从贷款提交系统的透视图中显示了提交贷款请求用例的子集。这张图说明了我们第二次事务处理的结束是在申请者提交贷款请求时开始，在贷款提交系统 ( CreditChecker ) 给代表商业资信咨询机构 ( CreditBureau ) 的参与者发出请求时结束。

　　图 3. 一个提交贷款请求用例的系统部分的子集

　　现在，让我们注意来自于商业资信咨询机构系统的透视图的这个请求。我们将以代表请求一份信用报告的一个外部系统 ( CreditInstitution ) 的参与者开始。从商业资信咨询机构的透视图来看，当参与者请求报告时事务处理开始并且在商业资信咨询机构系统 ( CreditReporter ) 返回这个报告时结束，就如图 4 中的图表所示。

　　图 4. 商业资信咨询机构系统的一个序列图

　　回到贷款提交系统，我们现在能扩展提交贷款请求用例以包括报告的接收。当 CreditReporter 返回报告时，一个新的事务处理开始，并且报告被加入到与申请相联系的信息中。然后我们可以通知贷款官员(一个新的参与者)新的申请已到达。这将是我们的贷款提交方案中的第三个事务处理。为了创建整个用例，我们需要再加几个事务处理，但是我们将那个练习留到以后来做。

　　逆向透视图逻辑

　　上面的图表说明了互连系统的系统建模中的两个重要方面。第一，从信息顺序透视图我们可以容易地将贷款提交和商业资信咨询机构系统作为单一的系统来进行建模。图 5 显示了这两个系统是如何在一个单一的图表中被建模成一个系统的。

　　图 5. 一个单系统的信用报告功能视图

　　这项技术在我们开发循环的分析阶段中一直起作用。然而，当我们进入设计阶段时，两个系统中的通讯机制建模的必要性使得单一的图表过于复杂。除非我们使用一种象 CORBA 这样的通讯技术，否则我们一旦进入设计阶段，就必须分别为这两个系统建模。要分离它们，我们将插入一些参与者(就如图 3 和图 4 中所示)来分别互相代表两个系统。

　　第二个观察更加微妙，也是我们这周讨论的中心：我们能对这些服务形成一个概念上的理解，这些服务必须通过系统通过观察其它系统的需要来提供的。换句话说，我们可以通过查看其它系统的用例中的事务处理信息的子集来为每个系统确定概念上的接口。

　　接着考虑贷款提交系统的第二和第三个事务处理。尤其得让我们查看第二个事务处理的 系统部分和第三个事务处理的 参与者部分。如果从概念上研究我们的商业资信咨询机构，参与者部分 ( CreditReporter ) 是贷款提交系统的系统部分的一个子集。也就是说，贷款提交系统用例表示“系统向商业资信咨询机构发送一个请求要求信用报告的一个副本。”

　　另一方面，商业资信咨询机构系统用例表示“这个信用机构参与者请求信用报告的一个副本。”这样，商业资信咨询机构事务处理的参与者部分是贷款提交系统的第二个事务处理的系统部分的一个子集。这对于第三个事务处理也是一样的，商业资信咨询机构事务处理的系统部分是第三个事务处理的参与者部分的一个子集。换句话说，事务处理的部分可以在两个系统间逆转。

　　在两个系统间概念上的逆转事务处理提供了在两个互连系统间的概念上的粘合。例如，我们知道我们需要一个进入商业资信咨询机构的接口，以提供来自于贷款提交系统接口的信用报告，贷款提交系统接口同样请求这些报告。

　　怎样把这个应用到用户接口

　　我们并不是经常建立互连系统。然而，我们确实为我们所建立的大多数系统创建用户接口。我们通过逆转它们的用例事务处理将两个系统间的机器接口概念化。如果我们用一个用户接口替换一个机器接口，这也是对的。

　　作为这篇文章的示例所显示的那样，我们为我们的系统所建立的用户接口将成为我们从相应的参与者透视图得出的用例描述的逆转。这就是为什么不能依靠用户接口透视图来编写出我们的用例。这儿的逻辑是创建概念上的用户接口，但是事务处理将不得不在应用之前被逆转。

　　也就是说，如果您已经在编写基于 UI 的用例并能够以这种方法提供的话，那就坚持下去。您的提供能力比那些制定标准的头头们制定的标准远远重要。然而，如果使用这种方法陷入混乱，那么，您现在知道为什么了。

　　下次我们将着眼于在灵活处理中捕获请求的不同机制，以及何时和为什么您应该使用那些特色、用户经历和在一个开发项目中的用例。下次见!