使用模式集成UML視圖(1)

2019-11-17 04:49:02

字體：大中小

來源：轉載

供稿：網友

介紹為支持軟件產品開發，我們頻繁使用通用軟件開發模型（和工具），例如統一建模語言(UML)。然而，通常意義的軟件開發和特定的軟件設計（正是我們工作的主要焦點）要求不僅僅是大多數通用模型所能提供的內容。體系構造是關于：

1) 對實際問題充分建模

2) 解決模型問題并

3) 在現實世界中解釋模型方案

這樣做的主要重點被置于體系結構的視圖（例如框圖）內和之間不匹配的鑒別與調和上。我們經常發現這方面的情況，分析和（體系結構的）說明的解釋在大多數通用語言中是次重點的。我們構造體系不僅僅是因為我們想建立（創作），而且因為我們要理解。這樣，體系構造有許多分析和校驗產品模型的概念完整性、一致性和徹底性的工作要完成。

已完全成為事實上OO軟件開發標準的UML的出現，在這個問題上也沒有任何例外。本工作闡述在UML視圖中體系結構不匹配的原因，以及說明模式和集成技術怎么能夠以更自動化的方式應用于識別并解決他們。為了做到這一點，本工作討論視圖集成框架，它的主要活動――映射（Mapping）、變換(Transformation)和分化(Differentiation)。

本論文將研究模式的角色，而不是集中于大量的集成技術（它們支持上述活動）。這樣，我們將研究模式的知識怎樣有助于保證軟件系統模型一致性。通過那樣，我們按以往很少使用的方式利用模式：我們用模式用作系統分析，而不是將模式用作構建材料作為系統成分。

視圖和模型在軟件開發中，我們利用模型和視圖處理軟件系統的復雜性。在這里，模型是指視圖的集合或者視圖可以看作模型的一個方面（或視點）。IEEE標準（草案）1471[AT&T1993]將視圖歸結于“提出一個或多個系統利益關聯者（Stakeholder）的利害關系”。對于利益關聯者，我們定義為分享系統注重或愛好個體或組（例如，開發者，用戶，消費者等等）。應用于我們的語境，視圖是模型的片段，它也要細小到我們能夠理解，但是也包含關于特定關系的關聯信息。在UML中，視圖本質上是圖形的，且往往通過框圖來實現。視圖（例如類或序列圖）服務于下列意圖：

抽象并簡化模型

使得不同的利益關聯者協調工作

為不同解釋進行補充（不同觀眾/利益相關者）

提取關于特定關聯的相關信息

因此，將會用到什么類型的視圖以及什么時候用到它們是強烈依靠于哪個人正在使用和需要完成的相關任務。然而，視圖并不是軟件開發的銀彈，因為它們具體表達基本問題；它們內部及它們之間表現出對等數量的建模元素冗余。

要給出一個簡單例子，考慮我們有個設計（例如按照UML類圖的形式）的軟件開發案例和產品實現（例如，C++代碼）。類圖和代碼表述不同的視圖，用不同的方法表達相同或類似的信息。雖然，代碼可以從設計中自動產生，這種逼近是有限的，還必須多次加入一些信息。更糟糕的是，現在這些冗余的信息片斷必須保持一致――后者大多是手工活動。這樣，無論什么時候設計變更了，代碼就會變得不一致（反之亦然），我們要應用一些視圖調和活動找到產生的不一致并一再保證模型概念的完整性。

視圖不匹配和冗余既然視圖是我們處理復雜性唯一有效手段，我們不能指望用某些較少冗余的事物來替代它們。我們需要視圖在任何給定的時間對軟件開發者不得不處理的信息總數進行分解。“這不是帶來復雜性的細節數量本身，而是我們不得不同時了解的細節的數量。”[Siegfried 1996]

然而，冗余性是一個必需的不幸。這暗示我們需要某種鑒別和解決視圖之間不匹配的自動化活動的方法。這樣，我們所需要就是一些集成和分析視圖的框架形體。有趣的是，視圖不匹配問題可能的逼近方法是基于它特有的問題――冗余性。我們利用一套視圖之間的冗余性意味著一個視圖包含關于其它視圖并可用作約束該視圖的信息。這樣，我們使用冗余信息來檢驗視圖之間的一致性和完整性。

例如，假如我們使用一些體系結構模式的形態來構造系統（例如，分層風格），那么設計必須反映體系結構對立的約束。這意味著假如體系結構定義了三層結構，那么體系結構隱含地定義了處理中第一層不使用第二層而與第三層直接對話是不答應的。假如后來系統使用UML設計（例如，使用類和序列圖），那么設計元素之內的調用依靠要求與上述的體系結構約束一致。我們將在后面說明一個例子。

UML視圖描述 vs 集成啟用視圖集成來確定和調和視圖要求兩個層次的集成――符號集成和語義集成。對于符號集成，意思是模型需要完整表達視圖的能力。語義集成通過定義什么信息可以交換以及怎樣交換作更進一步精煉。只有在什么和怎樣在確立之后，不一致性才可以確定。

統一建模語言（UML），像其他通用軟件系統開發模型一樣，只是不能很滿足上述語義集成。UML提供一個模型用于表達不同框圖的視圖來處理類、對象、活動、狀態、包及其它（參看圖 1 ）。然而，UML 不擅長集成他們。在UML視圖之間的關聯和依靠關系很少被捕捉。假如后者沒有完成，模型僅僅是松散耦合的或完全無關聯的視圖集。雖然UML及其元模型在細節上定義了單個視圖的符號和語義特征，視圖內關聯的獲取仍然是不夠的（在視圖之間只存在一些微弱形式的依靠關系，例如類和對象）。

圖 1 也表明問題的另一個方面――那就是擴展UML以表達新的和外部概念（例如，風格和模式）。例如，怎樣才能在UML中使用更高級的模式例如分層的體系結構模式【[1]】或代理設計模式？在UML中，我們需要再次區分僅僅表述模式和完整集成它們。使用模式集成UML視圖(1)（圖一）

圖 1 UML中表示法 vs. 集成視圖集成框架視圖集成的主要的障礙是缺乏完好定義的（工程的）模型基礎。視圖經常使用迥然不同的表示信息方法，而這使得確定它們在哪里和怎樣出現重疊非常困難。這樣，組合和比較視圖的任務經常是手工的而且潛伏著錯誤的。集成框架的目標是要補償鑒別和解決體系結構不匹配自動化輔助手段的不足。

如前面簡短的敘述，這樣做的時候，我們的框架需要處理什么信息和怎樣進行交換。我們在那里寫到什么信息可被交換以及它怎么能交換的判定需求。在我們的視圖集成框架中，我們提到映射和變換這兩個活動。我們也說只有在這些活動定義之后，才能夠嘗試鑒別不一致性。后者我們稱之為分化（參看圖 2 ）。

圖 2 在高層次式樣上描寫我們的視圖集成框架。在那里，系統模型用于表達軟件系統的知識基礎。軟件開發者使用視圖增加新的數據到系統模型并且復審現有數據（視圖綜合）。對于UML，系統模型可能被看作通過UML設計工具（例如Rational Rose）完成的UML模型和視圖綜合。

系統模型和視圖綜合兩者交互影響就是視圖分析。一旦加入新的信息，它就可以針對系統模型進行驗證以保證其概念完整性。圖 2 表示視圖分析可以怎樣進一步細分為其上述三個主要活動：使用模式集成UML視圖(1)（圖二）

圖 2 視圖集成活動
映射：通過使用命名字典、跟蹤和跟蹤仿真（例如相同物理類和方法的使用）以及某種關聯/模式形式（例如公共接口）來確定相關的信息片。

變換：在視圖中操作模型元素以便它們（或它們的片段）可以在其他視圖中共享（或在系統模型自身中表述）。例如，我們可以使用抽象技術泛化一個具體的框圖，我們可使用視圖轉化在不同類型的視圖之間交換信息，或者我們可以按不同的風格重新排列模型元素（或片段）產生新的視角（例如拼結和分割）。

分化：具體研究系統模型鑒別系統模型中（潛在的）不匹配。（潛在的）不匹配按規則和約束的形式討論。此外，不匹配解決規則可與將要怎樣解決它們可選方法的不匹配標識規則相關聯。分化是強依靠于變換和映射的。

然而，必須注明的是，那些活動不是相互正交的。顯然地，我們只有在知道模型元素的正確映射時才能做出有用的變換。這種依靠關系反之也是成立的。通過視圖變換導出的信息可以澄清許多映射中的二義性。這樣，一個視圖可以用于澄清其它視圖中的二義性。

此外，如圖 2 所示，視圖集成不只局限于模式，然而，模式對視圖集成構成了非常重要的基礎。我們將在后續章節中討論這種面向模式的視圖集成方向。其他非模式相關的視圖集成方向在[Egyed1999a]和[Egyed1999b]中論述。上述框架通常在UML之外也適用。產品訂貨系統案例我們將使用一個簡單的產品訂貨系統貫穿全文進行指導，該系統被分成兩個主要的子系統――訂單獲取子系統和訂單處理子系統。第一個子系統通過銷售代表從消費者獲取訂單和付款信息。后一個子系統獲取倉庫治理員對產品訂單隊列的處理。產品訂貨系統合成兩個COTS（Commercial off the Shelf，已下架的商品化）產品：存貨系統處理產品存貨，而訂單倉庫作為數據庫（后者既用于產品訂貨系統又用于存貨系統）。

表格 1 表示我們的系統體系結構使用分層模式（或分層風格）進行設計。該體系結構模式將在后面由設計模式和其他設計特征補足。

表格 1 討論產品訂貨系統的分層體系結構模式

產品訂貨系統

- 用戶界面（訂單獲取界面，訂單處理用戶界面，存貨用戶界面）

- 訂單框架（消費者，付款，訂單，訂單行，記錄器）

- 存貨系統

- 網絡（LAN）

- 訂單倉庫

模式怎樣有助于視圖集成？在文章展開論述時，我們將揭示關于產品訂貨系統更多的細節。雖然，由于篇幅的限制，我們既不能在此表述整個系統，也不能闡述所有的集成技術。相反，如前面提到的，我們將集中于視圖集成時模式承擔的角色上。對應于圖 2 中簡述的三個集成活動，模式支持如下活動（下節將說明例子）：

映射

模式支持不同抽象層次的視圖之間的映射（交叉引用）。例如，一個高層框圖指出使用一個已知后來在低層次框圖中實現的模式。這樣，這類模式存在于低層次框圖的知識以及該模式粗略了解（如在[Gamma et al. 1994]和[Buschman et al 1996]中定義）的知識有助于在低層框圖中自動鑒別。

模式也支持不同類型視圖的映射。例如，模式描述經常指定其結構和它們的動態行為。那么，可以在我們的模型中使用這些知識來交叉引用結構化的和動態的信息。

變換

模式應用于變換的方法與它們在映射中的用途類似。對于變換，我們可以把它們用作抽象和轉化。對于抽象，我們意指簡化視圖的處理。例如，假如我們想知道高層視圖和低層視圖是否一致，那么我們需要精煉高層視圖或者抽象低層視圖以使直接比較成為可能。前者不能自動進行，而后者可以。為了抽象視圖，需要確定相關的片段，然后，它們被更加簡單的事物替換。對此，模式是完美的原始資料，因為它們提供哪些片段屬于一起的知識。我們可以使用模式知識抽象低層模式到高層模式（或者對等的單個部件）。

模式也可以如我們在映射中討論的那樣用于靜態與動態結構之間的轉化。既然模式經常用兩種式樣描述，我們可以通過結構推導行為（反之亦然）。這樣，利用模式我們也可以轉化視圖。

分化

如圖 2 中簡述，分化強依靠于映射和變換。這意味著要在視圖中找出不一致性，我們需要確定其建模元素的關系，并且需要找出從一個視圖到另一個視圖變換信息的方法。沒有前一個步驟我們不能知道要比較什么信息，沒有后一步，我們不知道怎樣比較。一旦上述步驟完成，我們可以使用兩個主要技術比較視圖：

（圖形）比較：依靠變換的視圖和原始視圖的對比進行比較。該技術暗示：一個視圖可以保留充分完整的風格變換為另一個視圖。

約束和規則檢查：我們頻繁地發現視圖不能廣泛的變換為另一個視圖，但它的少部分和片段可以。在這種情況下，我們可以使用規則和約束來論述和分析這些片段。

對于分化，設計模式并非直接有用，然而，我們通過映射和變換收集到的有關視圖的信息卻可以。我們已經簡短地討論模式怎樣有助于映射和變換視圖。在這些例子中，比較視圖是直接的，因為映射和變換啟用直接（圖形）比較。無論如何，模式在約束和規則檢查中也非常有用。例如，我們在表格 1 中介紹的分層模式定義了自然的約束：用戶界面只答應與訂單框架對話，訂單框架依次只能與存貨系統對話等等。該體系結構的模式影響了設計的結構和它的行為。

在產品訂貨系統中使用模式本節通過說明模式可以怎樣在我們的產品訂貨系統語境中應用于集成活動的例子補充上述論述。分化圖 3 使用UML包說明我們系統的高層設計視圖。該圖顯示主要訂單系統部件（或子系統）的交互。關于分層體系結構的知識現在可以幫助我們在表格 1 中的體系結構和圖 3 的設計之間自動確定不匹配。表格 2 總結兩個視圖對立的約束。

體系結構視圖約束從表格 1 導出。它們定義我們系統層次之間的調用依靠關系（例如，用戶界面依靠于訂單框架）。圖 3 是設計視圖約束的基礎。該圖說明一個含有一套包以及它們之間調用依靠的UML包圖（包和依靠的語義在[Booch-Jacobson-Rambaugh 1997]中定義）。表格 2 體系結構上和設計視圖對立的約束

體系結構的視圖約束

體系結構[用戶界面取決于訂單框架]；

體系結構[訂單框架取決于存貨系統]；

體系結構[存貨系統取決于網絡]；

體系結構[網絡取決于訂單倉庫]；

設計視圖約束

設計[訂單獲取UI取決于訂單框架]；

設計[訂單處理UI取決于訂單框架]；

設計[存貨UI取決于存貨系統]；

設計[訂單框架取決于存貨系統]；

設計[訂單框架取決于網絡]；

設計[存貨系統取決于網絡]；

設計[網絡取決于訂單倉庫]；

映射

設計[訂單獲取UI] 映射到體系結構[用戶界面]

設計[訂單處理UI] 映射到體系結構[用戶界面]

設計[存貨UI] 映射到體系結構[用戶界面]

設計[訂單框架] 映射到體系結構[訂單框架]

設計[存貨系統] 映射到體系結構[存貨系統]

設計[網絡] 映射到體系結構[網絡]

設計[訂單倉庫] 映射到體系結構[訂單倉庫]

完整性規則

對于所有體系結構的視圖約束存在設計視圖約束；

例如：

體系結構[用戶界面取決于訂單框架] =>

存在：設計[訂單獲取UI取決于訂單框架] 或者

設計[訂單處理UI取決于訂單框架] 或者

設計[存貨UI取決于訂單框架]

一致性規則

對于所以設計視圖約束存在體系結構約束；

例子：

設計[訂單處理UI取決于訂單框架] =>

存在：體系結構[用戶界面取決于訂單框架]；

表格 3 描述產品訂貨系統的分層體系結構模式

產品訂貨系統用戶界面（訂單獲取UI,訂單處理UI,存貨UI）訂單框架存貨系統網絡（LAN）訂單倉庫

　　建立這些約束是變換的責任，并且在這種情形下能夠自動完成。例如，利用我們在表格 1 中的分層模式的知識我們可以自動導出層間的調用依靠關系。優點是模式的語義只需要定義一次并且可以在以后重用。視圖的語義和符號也可以看作模式。這樣，圖 3 的包圖帶有一套預定義的相關約束。一旦定義，就可以對包圖的不同實例導出設計約束。

表格 2 的映射部分定義了體系結構視圖（表格 1 ）和設計視圖（圖 3 ）部件之間的關系。在這個例子中，用于映射的模式使用不是那么明顯。我們將在后面討論它們對于映射的使用。

表格 2 中最后兩個部分是部分的分化活動。在那里，定義了兩類規則，一個用于一致性，另一個用于完整性。假如體系結構定義的一些部件或連接器沒有反映在設計中，就可能顯示潛在的不完整。在另一方面，假如設計與體系結構抵觸，那么這可能指出潛在的不一致性。另外，對于每套我們比較的視圖，規則只需要定義一次；那些規則然后可以重用。在體系結構和設計實現之間確定不匹配現在是評估規則和約束的事情。這樣揭示了沒有完整性方面的不匹配情況，然而，有些不一致性方面的不匹配：

1) 存貨UI部件對于存貨系統的依靠與分層體系沖突，用戶界面不答應不經過訂單框架直接與存貨系統進行交流。

2) 類似地，訂單系統要求使用存貨系統訪問網絡。使用模式集成UML視圖(1)（圖三）

圖 3 UML中的高層設計（包圖和依靠）確定這些不匹配并沒有對他們的起因給出任何反饋。例如，是體系結構還是設計錯誤？表格 3 說明通過提升存貨系統到訂單框架同一個級別來解決上述所有不匹配而不會引入新的不匹配的可能方法。我們不相信實際的不匹配解決方法將徹底地自動完成。這種方法與先前的自我糾錯源代碼編譯器的嘗試相同，這種努力最后因為所包含的社會和技術的復雜性而失敗了。可是，我們相信提供給設計者不僅僅使用（潛在的）不匹配，而且用關于怎樣在處理不匹配以及理解它們這兩者高度有利的情況下解決它們。此外，它可能對發現處理具有更好選擇情形的技術非常有好處。我們將在[Egyed 1996]中更具體地討論這種情形。

映射

圖 4 表明我們系統的另一個視圖，圖 3 的一個精煉。另外，該視圖可以對修訂的體系結構和高層設計都能進行校驗，然而，并沒有發現不匹配。該視圖用另外的設計模式例如模板【[2]】（Template）模式（通過<>構造型指定）和代理【[3]】（PRoxy）模式（通過《Proxy》構造型指定）。我們將使用它們進一步探究模式在視圖集成中的價值。使用模式集成UML視圖(1)（圖四）

圖 4 高層設計視圖使用UML類和包的精煉

使用模式集成UML視圖(1)（圖五）

圖 5 低層設計視圖使用UML類圖圖 5 描寫了對應的低層實現，它不只是解決用于圖 4 中的模式，而且也精煉其它的一些建模元素。頂部三個類對應用戶界面層，存貨系統可以通過存貨代理來訪問，倉庫可以類似地通過倉庫代理來訪問。要找出該視圖是否和先前的視圖一致，我們可以運用幾個集成技術。

首先，我們需要找出哪些模型元素互相對應（映射）。這有幾種技術可以應用，例如名字的相似性等等。可是，在該例子中模式的廣泛使用使我們能夠開發關于它們用于映射的知識。通過圖4中的高層設計我們明白幾個事實：

模板模式用于訂單行（OrderLine）代理模式用于橋接訂單行（OrderLine）（產品）與存貨系統

代理模式用于使用Oracle 數據庫橋接訂單框架子系統

接口特征（例如，消費者類與訂單、付款、和消費者UI接口）使用模式集成UML視圖(1)（圖六）

圖 6 結構化模式知識（改編自[Buschman et al. 1996]）雖然從技術上講，最后一項并不是一個清楚定義的模式，然而它構成類配置的知識――這樣，接口特征可以看作模式，即使它們大部分只是領域模式。關于領域的模式知識如同預定義的模式（參看圖 6 ）一樣使我們現在可以推論建模信息的關系。映射圖 4 和圖 5 的任務被精簡為使用如圖 6 所論述的預定義結構化模式知識來確定上述模式和（接口）特征的位置。

用圖 6 作為指導，我們可以輕易地確定模板模式（產品，隊列，以及產品隊列對應于訂單行（OrderLine））的對應。雖然，它也可以輕易找到代理模式，怎樣能夠區分它們卻不夠清楚。注重到目標是使得計算機自動鑒別它們。要在后來做到這一點，我們可以使用上面討論的接口特征（模式）。想法是，至少存在一些映射或者能夠通過名稱相似性來建立。使用該額外信息它可能自動從Oracle模式區分存貨（Inventory）模式。

不幸的是，通過模式的映射仍然比上述例子可說明的要更困難一些。我們作了簡化的假定，就是模式的結構和行為是靜態的。雖然，通常模式不是那些精確定義的，并且我們需要它們更一般的描述。圖 5 表明這樣一個例子，倉庫代理模式看上去不象定義的那樣。然而，既然網絡是部分代理類，它就可以合并到代理類中，并且代理類繼續它所有的依靠關系（下一節的Rose/Architect將表達一個模型來這樣做）。

該映射技術的另一個問題是模式，在識別的時候，有時可能只是粗糙地指出它們的位置。例如，對應于隊列，產品，和產品隊列，訂單行隊列（OrderLine Queue）可以在低層框圖中找到。雖然這也是正確的，但是它丟失了同時在低層框圖中表示的組成訂單行（OrderLine）。 QQread.com 推出各大專業服務器評測 linux服務器的安全性能 SUN服務器 HP服務器 DELL服務器 IBM服務器聯想服務器浪潮服務器曙光服務器同方服務器華碩服務器寶德服務器變換

模式和抽象

單獨的介于圖 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中，這種抽象可以是自動的。對此，設計模式需要按照它們的輸入（源）和目的以及它們的訪問點進行討論。使用模式集成UML視圖(1)（圖七）

圖 7 通過Rose/Architect的模式抽象
當前，另外一個RA缺點是它只能用于抽象類圖信息。雖然該技術也可以擴展到抽象其它類型的視圖，但是當我們想要比較不同類型視圖的建模元素時它仍然對我們沒有幫助。下一小節將論述這種情況。

模式和轉化鑒于抽象處理簡化視圖的情形，轉化處理在不同類型視圖之間共享建模信息的情況。例如，上述討論中，我們廣泛使用類和類圖，它們按結構化形式表達信息。既然結構視圖在表示系統行為通常是不足的，那么行為視圖例如序列圖就要用來填補這個缺口。

例如，再考慮表格 1 中體系結構分層模式的約束（與高層設計視圖的約束一起）。在那里體系結構的約束決沒有覆蓋全部分層體系結構的行為。一個分層的體系結構不只是限制哪些層答應互相對話，它也限制交互的方向。雖然結構框圖比如類圖可以描寫某些方向性的依靠，但是它可能忽略其它的方面。使用模式集成UML視圖(1)（圖八）

圖 8 使用Rose/Architect和設計模式抽象的類圖

使用模式集成UML視圖(1)（圖九）

圖 9 關于新訂單創建的序列圖（對應于低層次框圖）圖 9 顯示了一個更加復雜的行為案例。一個UML序列圖在這里用于描述創建一個新的消費者訂單的可能場景。在某些用戶輸入被校驗之后，它檢驗消費者是否存在。假如不存在，新的消費者被創建，在此之后，建立新的訂單。該場景描寫低層次設計視圖（圖 5 ）某些行為方面。照此我們可以使用圖 5 自動檢驗類（或對象）之間的調用依靠，在這種情況下沒有揭示不匹配情況。該序列圖也符合我們的體系結構，因為所有的層次約束都觀察到了（兩者都可以自動檢驗）。既然按照組件的行為結構視圖具有高度二義性，我們可以再次利用我們的模式知識精煉行為的信息。

圖 9 利用訂單倉庫代理，網絡，和Oracle數據庫以及在映射中我們發現的那些對應代理設計模式的類。如在[Buschman et al 1996]中所發現的那樣，圖 10 顯示代理模式結構的和行為的定義。效應上，行為定義是結構的一個轉化。這樣，我們可以使用該知識來檢驗圖 9 的正確性。

因為在圖 10 中的代理定義和圖 9 中代理實例化之間的抽象級別并不相同，我們需要先抽象圖 9 。基本上，我們可以使用Rose/Architect概念通過合并網絡到訂單倉庫代理中來抽象網絡（這是有效的，因為網絡是代理的一部分）。此后，定義和實例化之間的直接比較是可能的。在該案例中沒有發現不匹配。使用模式集成UML視圖(1)（圖十）

圖 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.

[1] 注重我們如[Bushman et al 1996]所作，可互換地使用術語模式和風格。

[2] 對共同使用的模板隱藏源模板和類元

[3] 為其他對象提供一個代理限制對它的訪問[Gamma et al 1994]

[4] 注重：我們可以用高層代理簡化較低層次設計模式 (責任編輯：銘銘)

上一篇：用UML描述工作流管理(1)

下一篇：解析UML的靜態建模機制(1)