關鍵字：UML視圖
摘要 模式在系統組合（合成）期間對養成重用可重復設計和體系結構配置的習慣很重要。本論文研究關于模式的知識，它也可用于系統分析檢驗系統模型的完整性。為了支持自動分析過程，該工作引入一個視圖集成框架。自從每個視圖（例如，框圖）增加一個額外針對模型的軟件系統觀點，來自一個視圖的信息可能用于驗證其它視圖的完整性。這種形式的集成要求對視圖表明什么以及它們可以共享（或約束）什么信息有更深的理解。因此關于模式在結構和行為上的知識，也是一個用于視圖集成自動化的有價值的來源。
介紹
為支持軟件產品開發，我們頻繁使用通用軟件開發模型（和工具），例如統一建模語言(UML)。然而，通常意義的軟件開發和特定的軟件設計（正是我們工作的主要焦點）要求不僅僅是大多數通用模型所能提供的內容。體系構造是關于：
1) 對實際問題充分建模
2) 解決模型問題并
3) 在現實世界中解釋模型方案
這樣做的主要重點被置于體系結構的視圖（例如框圖）內和之間不匹配的鑒別與調和上。我們經常發現這方面的情況，分析和（體系結構的）說明的解釋在大多數通用語言中是次重點的。我們構造體系不僅僅是因為我們想建立（創作），而且因為我們要理解。這樣，體系構造有許多分析和校驗產品模型的概念完整性、一致性和徹底性的工作要完成。
已完全成為事實上OO軟件開發標準的UML的出現，在這個問題上也沒有任何例外。本工作闡述在UML視圖中體系結構不匹配的原因，以及說明模式和集成技術怎么能夠以更自動化的方式應用于識別并解決他們。為了做到這一點，本工作討論視圖集成框架，它的主要活動――映射（Mapping）、變換(Transformation)和分化(Differentiation)。
本論文將研究模式的角色，而不是集中于大量的集成技術（它們支持上述活動）。這樣，我們將研究模式的知識怎樣有助于保證軟件系統模型一致性。通過那樣，我們按以往很少使用的方式利用模式：我們用模式用作系統分析，而不是將模式用作構建材料作為系統成分。
視圖和模型
在軟件開發中，我們利用模型和視圖處理軟件系統的復雜性。在這里，模型是指視圖的集合或者視圖可以看作模型的一個方面（或視點）。IEEE標準（草案）1471[AT&T1993]將視圖歸結于“提出一個或多個系統利益關聯者（Stakeholder）的利害關系”。對于利益關聯者，我們定義為分享系統注意或興趣個體或組（例如，開發者，用戶，消費者等等）。應用于我們的語境，視圖是模型的片段，它也要細小到我們能夠理解，但是也包含關于特定關系的關聯信息。在UML中，視圖本質上是圖形的，且往往通過框圖來實現。視圖（例如類或序列圖）服務于下列意圖：
介紹
為支持軟件產品開發，我們頻繁使用通用軟件開發模型（和工具），例如統一建模語言(UML)。然而，通常意義的軟件開發和特定的軟件設計（正是我們工作的主要焦點）要求不僅僅是大多數通用模型所能提供的內容。體系構造是關于：
1) 對實際問題充分建模
2) 解決模型問題并
3) 在現實世界中解釋模型方案
這樣做的主要重點被置于體系結構的視圖（例如框圖）內和之間不匹配的鑒別與調和上。我們經常發現這方面的情況，分析和（體系結構的）說明的解釋在大多數通用語言中是次重點的。我們構造體系不僅僅是因為我們想建立（創作），而且因為我們要理解。這樣，體系構造有許多分析和校驗產品模型的概念完整性、一致性和徹底性的工作要完成。
已完全成為事實上OO軟件開發標準的UML的出現，在這個問題上也沒有任何例外。本工作闡述在UML視圖中體系結構不匹配的原因，以及說明模式和集成技術怎么能夠以更自動化的方式應用于識別并解決他們。為了做到這一點，本工作討論視圖集成框架，它的主要活動――映射（Mapping）、變換(Transformation)和分化(Differentiation)。
本論文將研究模式的角色，而不是集中于大量的集成技術（它們支持上述活動）。這樣，我們將研究模式的知識怎樣有助于保證軟件系統模型一致性。通過那樣，我們按以往很少使用的方式利用模式：我們用模式用作系統分析，而不是將模式用作構建材料作為系統成分。
視圖和模型
在軟件開發中，我們利用模型和視圖處理軟件系統的復雜性。在這里，模型是指視圖的集合或者視圖可以看作模型的一個方面（或視點）。IEEE標準（草案）1471[AT&T1993]將視圖歸結于“提出一個或多個系統利益關聯者（Stakeholder）的利害關系”。對于利益關聯者，我們定義為分享系統注意或興趣個體或組（例如，開發者，用戶，消費者等等）。應用于我們的語境，視圖是模型的片段，它也要細小到我們能夠理解，但是也包含關于特定關系的關聯信息。在UML中，視圖本質上是圖形的，且往往通過框圖來實現。視圖（例如類或序列圖）服務于下列意圖：
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
