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

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

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

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

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

逆向透视图逻辑

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

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

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

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

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

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

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

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

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

作为这篇文章的示例所显示的那样，我们为我们的系统所建立的用户接口将成为我们从相应的参与者透视图得出的用例描述的逆转。这就是为什么不能依靠用户接口透视图来

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