UML软件工程组织

分布式应用软件的优势在于这项技术是如此的灵活，使得几乎所有的公司都可以与其他公司进行挂钩，并创建对双方都有用处的数据交换。它的不足在于这样的应用软件出现故障的几率则要大得多。

为一个ERP环境设计健全的应用软件是很困难的，在这里多个数据源都被用于为用户即时创造实时记录。要将应用软件在商业领域中进行扩展并超出公司的界限就更加地困难。设计并实现一个让国内和国外的用户都感到满意的应用软件，特别是一个实时应用软件，是一个相当大的成就。但是如果你没有考虑到出现故障的可能性，你就只做到了一半的工作。

诱惑

有没有人还记得Tinkertoys？他们设计了一套很棒的木制建筑部件和塑料的连接插头，孩子们可以用它们来建造出任何东西。这种灵活的部件可以让你在你所建造的东西上不断地增加部件，直到它无法承受自身的重量而倒下来。

J2EE，Web服务，.NET和所有相关的事物都存在着类似的问题。现在，创建一个独立于平台的应用软件，将其分布在所有公司的商业伙伴之中，让它服务于多种数据源，给每个用户提供一些完善的功能，这样做已经是可行的事实。而要建构这样的一个应用软件，所需的成本只比在五年前建构一个单用户，单数据库的应用软件所需的成本稍高一点。

就像Tinkertoys玩具一样，为此我们所付出的代价是，太多的地方会出现故障。这造成了一系列的问题，其中每一个都比在传统形式的应用软件中的问题更加严重：

故障点通常很难找到。
公司中很少有人所具有的专业技术能设计所有的故障点。
可能出现的故障点超出了你的部门的范围。
所有的故障点可能具有不同的模式，影响到不同的用户。
故障点还可能会切断为用户提供的错误信息的沟通路径。

这个结果确实很糟糕。我们该怎么办？这里有一些办法，不过你必须事先对他们进行考虑，而且最好与其他相关的团体进行协作（特别是用户）。

在设计阶段确认所有的问题点

还记得一个叫Get Smart!的老电视剧嘛？里面有个叫Don Adams的特工人员，他要穿过一系列的门进到电话亭中才能被带回到特工人员的秘密总部。在一个分布式应用软件中，特别是存在于互联网上的那种，数据就要穿过这样的一系列的门。如果任何一个门没有能够打开，数据就无法到达，应用软件就会出问题。因此你必须对每个门进行确认并将其视为一个可能的障碍。

当面对不熟悉的数据传输技术或依靠于外部的服务供应商时，这一点并不是很容易做到的。你要做出额外的工作，深入探查什么样的问题会影响你的应用软件。如果你使用行销商所提供的软件，你无法对其进行控制，你也可以进行类似的工作并找出它所存在的弱点，同样列出这些可能的故障点，故障点的跟踪应该包括从源数据库的起始点到用户端之间，数据出现的每一个点。

为日后的审查建立检查点

现在看一看对故障点的跟踪，确认记录了数据成功通过的所有点。你所记录的内容取决于你，而且应由数据沟通的性质，数据传输路径的复杂性和问题的严重性所决定。记录的内容可以很简单，就像在临时文件中的一个本地服务器的文本消息，可以在应用软件成功终止后被删除。

创建这个故障跟踪轨迹对于分布式应用软件来说是很关键的，如果应用软件中有很多的数据传递的话。这是因为现今的分布式应用软件的特性是产生特定于用户的结果且可以在从源数据库开始的路径上的不同点进行访问。

在分布式应用软件中，特别是存在于互联网上的，数据的支出经常会有所差别。不同的用户群组，特别是那些公司范围外的用户，对数据的要求会有很大的不同，可能会从一个公共的数据源中选择出自定义的子集。而且，一些用户可能对数据不感兴趣，但是却对他们的用途感兴趣。例如，一个咨询行销的合作伙伴也许只对你公司的Web站点的信息通信感兴趣，而并不关心所传递的数据。这些用户和他们所收集的数据，都属于应用软件之中的一部分，即使是把他们看成是外围设备。

建构成功

如果你的分布式应用软件具有多个数据源，你应该考虑一下几点。首先，让你的终端用户知道信息源是由应用软件进行访问的，不论是在实时中还是通过基于命令的登陆。这个策略是很重要的，因为在一个具有多个数据源的分布式应用软件中，应用软件可能会部分地出现问题。你的用户可能位于公司之外，在不同的物理地点实时地访问你的目录数据库，接收数据。也许这些数据库中有五分之四成功地送交了数据，而另外五分之一却没有。你就必须让用户知道所给出的信息是不完整的。想办法让用户了解发生了什么事情，并付诸行动。

对于应用软件的使用，部分的成功（或部分的故障）是相对于彻底的成功和出现故障的另一个选择。在很多应用软件中，有一些信息总比一点没有要强，而且它的有效性只是一个程度问题。然而，如果你真这样做的话，就必须对具体内容进行细化，让用户事先知道数据是不完整的，并了解数据的来源（或者详细说明没有能够成功访问的数据源）。

为所有潜在的故障点建立故障模式

当出现问题时，你要确保让用户知道，而且是越详细越好。不论用户是需要这个数据还是把它发送到别的地方，如果数据传送没有实际发生，你就要第一个通知用户（确定你所选择的应用软件开发环境可以提供灵活而可靠的错误处理机制，Java在这一方面做得很好）。

对用户给出的故障通知应该提供补救的详细情况。如果可能的话，错误信息中应该包括什么东西出现错误和有关的情况联系人。当无法做到这一点时，你就应该通知用户（另一方面，或者是系统管理员）所需数据到达的最后一个点，这样至少可以将故障点确定下来。

这里还有一个额外的步骤你需要采取。如果所出现的故障点超出了你公司的界限，或是超出了你的团队管辖的范围，那么你就需要与Web服务或是服务器的管理者就故障发生的地点事先进行沟通，取得一致意见。当发生故障时，有了故障协议就可以实现对故障的快速诊断和修复，指导Web服务给出一个符合要求的故障通知，这样当出现问题时外部用户就能够接收到这个有关数据情况的错误通知。

你怎么看待这额外的工作？你仅仅需要两分钟：你先想象一下你的应用软件中所有的东西都不见了，想象一下故障清单上的任何一个细节，然后再想象一下对故障进行跟踪要花费多少时间，同时设想你就是一个用户，不知道发生了什么事情而感到纳闷。这样你就可以得出结论了。