使用模式集成UML視圖

2019-11-17 04:43:46

字體：大中小

來源：轉載

供稿：網友

介紹為支持軟件產品開發，我們頻繁使用通用軟件開發模型（和工具），例如統一建模語言(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 UML中表示法 vs. 集成視圖集成框架視圖集成的主要的障礙是缺乏完好定義的（工程的）模型基礎。視圖經常使用迥然不同的表示信息方法，而這使得確定它們在哪里和怎樣出現重疊非常困難。這樣，組合和比較視圖的任務經常是手工的而且潛伏著錯誤的。集成框架的目標是要補償鑒別和解決體系結構不匹配自動化輔助手段的不足。

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

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

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

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

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

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

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

此外，如圖 2 所示，視圖集成不只局限于模式，然而，模式對視圖集成構成了非常重要的基礎。我們將在后續章節中討論這種面向模式的視圖集成方向。其他非模式相關的視圖集成方向在[Egyed1999a]和[Egyed1999b]中論述。上述框架通常在UML之外也適用。介紹為支持軟件產品開發，我們頻繁使用通用軟件開發模型（和工具），例如統一建模語言(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 UML中表示法 vs. 集成
視圖集成框架視圖集成的主要的障礙是缺乏完好定義的（工程的）模型基礎。視圖經常使用迥然不同的表示信息方法，而這使得確定它們在哪里和怎樣出現重疊非常困難。這樣，組合和比較視圖的任務經常是手工的而且潛伏著錯誤的。集成框架的目標是要補償鑒別和解決體系結構不匹配自動化輔助手段的不足。

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

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

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

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

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

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

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

此外，如圖 2 所示，視圖集成不只局限于模式，然而，模式對視圖集成構成了非常重要的基礎。我們將在后續章節中討論這種面向模式的視圖集成方向。其他非模式相關的視圖集成方向在[Egyed1999a]和[Egyed1999b]中論述。上述框架通常在UML之外也適用。 QQRead.com 推出數據恢復指南教程數據恢復指南教程數據恢復故障解析常用數據恢復方案硬盤數據恢復教程數據保護方法數據恢復軟件專業數據恢復服務指南介紹為支持軟件產品開發，我們頻繁使用通用軟件開發模型（和工具），例如統一建模語言(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視圖（圖一）

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

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

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

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

此外，如圖 2 所示，視圖集成不只局限于模式，然而，模式對視圖集成構成了非常重要的基礎。我們將在后續章節中討論這種面向模式的視圖集成方向。其他非模式相關的視圖集成方向在[Egyed1999a]和[Egyed1999b]中論述。上述框架通常在UML之外也適用。 QQRead.com 推出數據恢復指南教程數據恢復指南教程數據恢復故障解析常用數據恢復方案硬盤數據恢復教程數據保護方法數據恢復軟件專業數據恢復服務指南介紹為支持軟件產品開發，我們頻繁使用通用軟件開發模型（和工具），例如統一建模語言(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視圖（圖一）