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

核心提示： 逆向透视图逻辑上面的图表说明了互连系统的系统建模中的两个重要方面，第一，Java 建模: UML 工作簿，第 3部分(6)，从信息顺序透视图我们可以容易地将贷款提交和商业资信咨询机构系统作为单一的系统来进行建模，图 5 显示了这两个系统是如何在一个单一的图表中被建模成一个系统的，您现在知道为什么

逆向透视图逻辑

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

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

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

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

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

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

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

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

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

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

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

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