圖 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]體系結構評估演說�！霸u估的意圖就是要確定一個體系結構的描述質量，以及通過它評定關聯的體系結構的質量”。他們進一步陳述了確定哪種體系結構可以進行校驗的評價準則需求。
[Nuseibeh 1995]寫到“不一致性是一個復雜的、增量軟件開發過程不可避免的部分”，還有“增量軟件系統開發包括不一致性的檢測和處理”。
[Perry0Wolf 1992]早就了解到軟件體系結構的重要性，并且他們將它陳述為體系結構四個主要好處之一，它們是“用于依賴性和一致性分析的基礎”。
文章來源于領測軟件測試網 http://www.kjueaiud.com/