变换
模式和抽象
单独的介于图 4 中的高层视图以及图 5 的低层视图之间的映射不足以确定不匹配。例如，在图 4 可以看到付款是消费者的一部分，然而在图 5 中这种关系更加复杂。为校验两个图是按相同的方法讨论关系，我们可以使用Rose/Architect概念。
Rose/Architect [Egyed-Kruchten 1999]认为模式分组为三类，并且使用及物关系替换为更简单的模式。在类图中，及物关系论述那些不直接连结的类之间的关系。然而一个关系可以通过其他类（例如helper类）存在，它在它们之间形成了一个桥（例如，假设上述例子中付款和消费者并不直接相连，但是它仍然通过helper（帮助者）类事务（transaction）和账目（account）类给出关系）。这样，如果发现某些公式，它们可以按有效精度导出及物关系，那么，可以按工具形式提供简化和抽象类图方面的自动支持。这将允许设计者通过删除“帮助者类”从现有的、更细节化的模型中抽象出重要的类，这样将使得它们更进一步描写和分析类之间中间关系，即使这些类分散在整个模型的不同位置（例如，不同的框图，或者在不同的包和名字空间中）。 RA提供这种机制而[Egyed-Kruchten 1999]详细地讨论了这种技术。当前，RA模型由大概80条抽象规则组成。例如规则4，论述了一个类被第二个类泛化（继承的反义词）并且父类是第三个类的聚集（部分）（参看图 7 ）的情形。这种三类模式现在可以删除中间类来简化并创建一个从第一个类到第三个类的及物关系（在该例子中的一个聚集）。下面的RA模型讨论这些规则以及必须怎样应用它们来产出有效的结果。 图 7 表明我们的低层设计视图（图 5 ）中的付款给消费者关系案例的RA精炼步骤。在应用两个规则（分别是规则4和规则17）之后我们得到一个具有两个类以及它们之间依赖关系的简化模式。如果这也可以对其他类以及在映射小节中讨论的模式【[4]】进行处理，我们就可以自动产生更高层次的类图（图 8 ）。产生的这个抽象视图现在就可以与我们在图 4 中描写的原始的更高层次类图直接进行比较了。这样，通过模式的使用我们可以转换视图以便它以非常类似其它视图的方式表达信息。比较视图现在可以简单地使用一些图形比较算法（也可参看上面所说的分化）的形式来完成。图 8 也显示了可能的不一致性。例如，从付款到订单的聚集丢失了，存货系统对Oracle数据库的调用没有使用网络部件，以及一些链接是不同的（例如，使用关联链接而不是依赖链接）。在变换（抽象）之后，这些不匹配可以容易地识别。 必须注意的是抽象没有彻底地自动完成。虽然，模式有助于在某些建模信息之间确定映射和变换，它们不能完全自动化该过程。因此，需要一些手工辅助来导出图 8 。而且，RA工具当前只能对付如图 7 讨论的简单的三类模式而不能处理图 6 中讨论的更加高级的设计模式。这样，由于该作业的缘故，抽象设计模式（例如代理）由手工完成。然而，一旦更加复杂的设计模式概念体现到RA中，这种抽象可以是自动的。对此，设计模式需要按照它们的输入（源）和目的以及它们的访问点进行讨论。
图 7 通过Rose/Architect的模式抽象
当前，另外一个RA缺点是它只能用于抽象类图信息。虽然该技术也可以扩展到抽象其它类型的视图，但是当我们想要比较不同类型视图的建模元素时它仍然对我们没有帮助。下一小节将论述这种情况。
模式和转化
鉴于抽象处理简化视图的情形，转化处理在不同类型视图之间共享建模信息的情况。例如，上述讨论中，我们广泛使用类和类图，它们按结构化形式表达信息。既然结构视图在表示系统行为通常是不足的，那么行为视图例如序列图就要用来填补这个缺口。 例如，再考虑表格 1 中体系结构分层模式的约束（与高层设计视图的约束一起）。在那里体系结构的约束决没有覆盖全部分层体系结构的行为。一个分层的体系结构不只是限制哪些层允许互相对话，它也限制交互的方向。虽然结构框图比如类图可以描写某些方向性的依赖，但是它可能忽略其它的方面。
图 8 使用Rose/Architect和设计模式抽象的类图
图 9 关于新订单创建的序列图（对应于低层次框图）
图 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]早就了解到软件体系结构的重要性，并且他们将它陈述为体系结构四个主要好处之一，它们是“用于依赖性和一致性分析的基础”。
[Shaw-Garlan 1996] 非常激奋地讨论体系结构，作为“系统设计的实质上的民间传说，很少具有一致性和精确性”。他进一步陈述“软件体系结构在框图和通俗散文中找到它的根基。不幸的是，框图和描述是高度二义性的。” 这些以及更多的参考文献，谈论到集成的需要（或缺失）。然而，他们通常不详细地讨论包含的活动（也有些例外）。有时这些工作并不是出于对集成逼近特别的喜爱。在另一方面，有时提议的技术经常只是打算让人们能够互相交流。例如，体系结构复审板[AT&T 1993]或者检查过程（Inspection Process）[NASA 1993]主要地应用于使大多数有能力的人们在一起工作，以便他们能够共享信息。这些技术可能遵循已定义好的过程（例如，检查单）并且可能出产有效的结果，但是实际上，确定和解决瑕疵的活动仍要手工完成，没有多少自动协助。
结论
本工作讨论了在UML视图中体系结构不匹配的原因以及说明了集成技术可以怎样按更自动化的方式应用于鉴别和解决它们。我们用统一建模语言(UML)的语境及其视图（框图）来表述本工作，并使用一个例子来引导视图集成的主要阶段。在本论文中表达的视图集成框架并不限制于UML。它也可以应用于其它模型和视图（例如体系结构描述语言）。 本工作进一步介绍了在分析软件系统模型概念完整性中的模式使用。既然模式是完好描述和文档化的，在结构和行为两方面，我们可以频繁地使用这些知识用于视图分析。照此，我们说明了关于模式的知识可以用于映射视图（相关建模信息的交叉引用），也可以从一个视图到另一个变换信息。后来我们说明了抽象（Rose/Architect）和变换技术。 虽然视图集成框架创建的意图是支持自动的视图分析，手工介入经常还是有必要的。既然本文只是集中于模式，其他集成技术也就没有讨论（也可参看[Egyed 1999b]）。我们将发表的内容为：
发现（或开发）覆盖更加广泛视图范围的集成技术
处理可量化性
增加更多的精确性到UML中澄清二义性。
论述自动化支持的不匹配解决的情况（而不仅仅是不匹配的自动确定）
不管这些问题，我们已经取得在该领域广泛的进步并且我们感觉到使用集成技术的好处，例如在本文中所讨论的，是无限的。我们已经表明不匹配鉴别的任务自动化是可能的（至少部分可以），既然计算机在比较视图无疑更加有效率，这就意味着本质上节省了人工劳动。我们近似的另一个好处是不匹配可以在它们创建的时候就确定。每逢新的数据加入到模型中，工具就可以验证它们。
参考文献
AT&T (1993) “最佳趋势实践：软件体系结构确认,” AT&T, Murray Hill, NJ.
Egyed, A. (1999a) “UML中体系结构视图集成,” 提交给 ESEC/FSE’99, http://sunset.usc.edu/TechRpts/Papers/usccse99-511/usccse99-511.pdf. Egyed, A. (1999b) “在UML中集成体系结构视图,” 资格报告, 技术报告,软件工程中心, 南加州大学, USC-CSE-99-514, http://sunset.usc.edu/TechRpts/Papers/usccse99-514/usccse99-514.pdf. Egyed, A. and Kruchten, P. (1999) “Rose/ 设计师：可视化软件体系工具”, 第三十二届系统科学会议年报议题 Booch, G., Jacobson, I., 和 Rumbaugh, J. (1997) “用于面向对象开发的统一建模语言,” 文集, 版本 1.0, 瑞理软件公司
Buschman, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. (1996) “模式系统：面向模式的软件体系,” Wiley.
Boehm, B., Egyed, A., Kwan, J., and Madachy, R. (1998), “使用 WinWin 螺旋模型：案例研究,” IEEE 计算机, July, pp. 33-44.
Gamma, E., Helm, R., Johnson,R., Vlissides, J. (1994) “设计模式：可重用面向对象软件元素:,” Addison-Wesley.
NASA (1993) “正式软件检验过程标准,” NASA-STD-2202-93.
Nuseibeh, B. (1995) “软件开发中的计算机辅助非一致性管理,” 技术报告 DoC 95/4, 计算系, 帝国大学, 伦敦 SW7 2BZ.
Rechtin, E. (1991) “系统体系，创建和建立复杂系统,” Prentice Hall, Englewood Cliffs, NJ.
Perry, D. E. and Wolf, A. L. (1992) “软件体系结构研究基础,” ACM SIGSOFT 软件工程笔记, 十月号.
Sage, Andrew P., Lynch, Charles L. (1998) “系统集成和体系构造：原理概述，实践和远景,” 系统工程, 国际系统工程会议期刊, Wiley Publishers, 卷 1, 第 3, 176-226页。
Shaw, M. and Garlan, D. (1996) “软件体系结构：形成原理的透视,” Prentice Hall. Siegfried, S. (1996) “理解面向对象软件工程,” IEEE Press.
