图 9 显示了一个更加复杂的行为案例。一个UML序列图在这里用于描述创建一个新的消费者订单的可能场景。在某些用户输入被校验之后，它检验消费者是否存在。如果不存在，新的消费者被创建，在此之后，建立新的订单。该场景描写低层次设计视图（图 5 ）某些行为方面。照此我们可以使用图 5 自动检验类（或对象）之间的调用依赖，在这种情况下没有揭示不匹配情况。该序列图也符合我们的体系结构，因为所有的层次约束都观察到了（两者都可以自动检验）。既然按照组件的行为结构视图具有高度二义性，我们可以再次利用我们的模式知识精炼行为的信息。
图 9 利用订单仓库代理，网络，和Oracle数据库以及在映射中我们发现的那些对应代理设计模式的类。如在[Buschman et al 1996]中所发现的那样，图 10 显示代理模式结构的和行为的定义。效应上，行为定义是结构的一个转化。这样，我们可以使用该知识来检验图 9 的正确性。
因为在图 10 中的代理定义和图 9 中代理实例化之间的抽象级别并不相同，我们需要先抽象图 9 。基本上，我们可以使用Rose/Architect概念通过合并网络到订单仓库代理中来抽象网络（这是有效的，因为网络是代理的一部分）。此后，定义和实例化之间的直接比较是可能的。在该案例中没有发现不匹配。
图 10 代理模式的结构和行为
由于篇幅的限制，我们不可能进一步讨论这个过程更多的细节。请参考[Egyed 1999a]和[Egyed 1999b]得到更多信息。
相关的工作
视图集成的缺乏并不是新发现。相反，很多模型描述都谈论到保持视图一致的需求。有时，处理模型提供有关什么任务可以提升体系结构概念完整性的附加方针。例如，一个关于使用WinWin Spiral Model(螺旋模型)[Boehm et al 1998]的案例研究建议在LCO(life-cycle objectives, 生命周期目标)和LCA(life-cycle architecture，生命周期体系结构)阶段之后使用体系结构复审板（Architecture Review Boards）[AT&T 1993]来检验和证实分析和设计的完整性。类似的观点可以在其他多不胜数的研究工作中看到：
[Sage-Lynch 1998]讨论集成（企业范围）的不同方面。他们一再地强调“体系结构在系统集成中承担重要的角色。”他们针对三个主要的视图表达需求：企业视图，系统过程和管理视图以及技术实现视图――并且他们强调在这些视图之间保证一致性。
[Rechtin 1991]非常强烈地要求和接口定义同等地强调需求的有效性和一致性。他进一步促成问题检测和诊断的需要。
[IEEE 1998]体系结构评估演说。“评估的意图就是要确定一个体系结构的描述质量，以及通过它评定关联的体系结构的质量”。他们进一步陈述了确定哪种体系结构可以进行校验的评价准则需求。
[Nuseibeh 1995]写到“不一致性是一个复杂的、增量软件开发过程不可避免的部分”，还有“增量软件系统开发包括不一致性的检测和处理”。
[Perry0Wolf 1992]早就了解到软件体系结构的重要性，并且他们将它陈述为体系结构四个主要好处之一，它们是“用于依赖性和一致性分析的基础”。
文章来源于领测软件测试网 https://www.ltesting.net/