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

序列图中的事务处理

事务处理在序列图中是很容易识别的。在我的第一个专栏中，我介绍了只有两个事务处理的方案。当申请者请求新的贷款申请时，第一个事务处理被启动。这个事务处理以系统等待申请者填写请求和提交请求为结束。当申请者在线提交了贷款申请时，第二个事务处理被启动。它以系统请求商业资信咨询机构的信用报告为结束。

图 1 让我们再看一下建立用来描述这个方案的序列图 -- 提交贷款请求和它的两个事务处理。这个图表建立了从开始到结束的两个事务处理的模型。您将会想起，这是一个一般的序列图，它允许我们在以后添加更多的方案（从而加入更多的事务处理）。至少就这个开发循环的分析阶段而言，当我们添加方案时，我们将完成这个用例。然而，当我们转向设计的时候，我们可能发现我们需要添加更多的事务处理。例如，如果我们选择作屏幕到屏幕的确认（代替当前在提交时的单一确认），我们必须在每一步确认时添加一个事务处理。

现在看一下图 1，仔细注意事务处理的描述。以识别信息的方向从参与者到出现在最接近顶部的一个类或者实例为开始。正如您在下面的图表中看到，第一个事务处理通常是从左边开始。沿着箭头的顺序直到您到达了另外一个参与者或者顺序结束。当顺序结束时，它返回到最初的参与者。这就是一个事务处理。在图 1 中您应该能看到两个完整的事务处理。

图 1. 一个提交贷款请求用例的部分序列图

象其他大多数用例那样，提交贷款请求用例使用多重的事务处理。迄今为止，我们只列出了其中的两个图表，但是一个普通的用例使用大约 3 到 15 个事务处理。

为了理解透视图和事务处理的关系，我们可以看一下当两个系统通讯时事务处理是如何表现的。一些软件系统实际上是一系列互连的较小系统。这些较小系统相互合作提供整个系统的功能性。每个较小系统只提供整个系统功能的一个子集。他们通过一组协议和机器接口进行通讯，这将把我们的用例模型提高一个全新的复杂程度。

互连系统的系统建模

当考虑到互连系统时，这对建立由较小互连系统组成的大系统有意义。您可以交换一个系统并且用其它的系统替换它。您也可以独立地建立每一个系统。并且您可以用许多站点或厂商来完成整个系统。

这样一个系统的最好示例是典型的电话网络。电话网络的一部分提供拨入通道，另一部分传送声音或数据，还有另一部分提供帐单服务，以及有许多其它部分开展象呼叫转移和语音邮件这样的服务。电话网络也许是由互连系统组成的系统的一个最大的示例，并且它的连续工作也证明了这种系统的有效性。同样的，懂得如何构思和建立这样的系统模型是十分重要的。

一个相似的示例

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

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

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

正如我们前面图表说明的那样，图 3 从贷款提交系统的透视图中显示了提交贷款请求用例

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