軟件架構中的層次依賴
—jack.wang 2009年大年初一
摘要：在描述大而復雜的軟件中，最復雜的抽象層次就是軟件架構。因此，在這個抽象層次我們能更好的理解構件組裝原理和交互方式。軟件架構被認為是軟件開發方面的驅動力，他允許指定每層那些方面和模型需要依照架構來設計。早期的架構描述語言 ADL，比較獨立，側重結構抽象層次而忽略行為描述層次、觀念層次和元模型層次。這篇文章描述了適當的“理性的”軟件架構視圖并用 C3 元模型描述（最小的并且完整的描述語言），我們提供了一個機制集合以處理不同層次的不同級別，我也提出了一新的用C3元模型描述的連接件的增強定義。
關鍵字：構件；連接件；軟件架構；層次架構；
目錄
1. 簡介
2. 目標
3. C3 原模型
3.1 表述模型
3.1.1 構件
3.1.2 連接件
3.1.3 配置
3.1.4 接口
3.2 推理模型
3.2.1 結構級別(Structural Hierarchy--SH)
3.2.2 行為級別(Behavioral Hierarchy—BH)
3.2.3 概念級別(Conceptual Hierarchy—CH)
3.2.4 元模型級別(Metamodeling Hierarchy —CH)
4. 案例研究
6. 參考文獻
寫在前面
這是篇有關架構的論文，通過連接件的增強來描述了不同層級的依賴關系，文中定義了6種類型的連接件有別于傳統的ADL描述語言的連接關系。由于翻譯的比較倉促也沒有復查，一定會有大量的錯誤，如果想看可以下載原文！本翻譯后共 7530字，英文原文.pdf
1. 簡介
如今，已經有了一個完整的新方法來構建可靠的軟件系統，他將大的復雜的系統分解為小的精確定義的單元---構件（構件或控件）。
通常情況下，構件被定義為由良好定義的服務接口和需要接口組成，以及在特定場景下的行為。一個基于構件開發的應用系統由獨立的構件構成，他們之間通過接口由精確定義的鏈接件鏈接。
沒有外部可觀測的內部結構，并用一種特定語言實現的構件叫做原子構件。如果有內部結構，即構件由內部構件組成嵌套關系叫做復合構件。一個配置結構一般關聯到架構配置，一般用ADL描述[1]。
軟件架構由構件、鏈接件、配置和約束組成。軟件架構其實就是系統的模型或者說是系統的抽象。軟件體系結構的研究人員需要可擴展的、有彈性的ADL，以及清晰的易操作的機制來操作這些架構層次的核心元素。
一個清晰的軟件架構定義沒有今天，就沒有過去，最近Medvidovic給出了如下定義[7]：一個軟件架構是關于系統的設計決策的集合。因此，如果這些決策不正確，可能致使你的軟件被取消，因為，這些決策包括了系統設計的方方面面，如下：
1. 系統結構方面的決策：比如一個系統應該包括三種構件：數據存儲、商業邏輯、用戶接口。
2. 關于行為方面的決策—功能決策：比如數據處理、存儲和可視化將單獨被處理。
3. 非功能性需求決策：可靠性、可維護性、易操作性等等。
4. 當然，我們也可以引出其他的設計決策，比如開發過程或者商業定位（產品線架構）等等。
在架構設計符號和方法的廣泛研究下，我們圍繞構件、鏈接件和配置給出了架構的描述模型 C3(component, connector, configuration)模型。他和Taylor提出的C2[16]沒有關系也和Pérez-Martínez [12]提出的C3模型不同。
2. 目標
這篇文章的目的就是提出一個通用的、最小的且完整的架構描述模型。最小的是因為我們只關注每個ADL的核心觀念。完整的是因為用這些最小集合的模型能描述所有的架構需求。
然而，僅僅描述架構是不能保證軟件系統的正確和可靠。本文我們更注重模型表述以及四個不同類型的層次(每一層提供架構的一個視圖),下面開始細細的描述這些層次。
3. C3 原模型
為了設計一完整的C3模型，我們定義了兩個互補的模型來描述和推理系統架構。我們用表述模型來描述基于C3元素的架構，用推理模型來理解和分析表述模型。
3.1 表述模型
表述模型的核心元素是構件、連接件、配置，每個元素都有接口和他所在的ENV（環境）交互，如圖所示C3元模型。
3.1.1構件
構件是一個計算或存儲單元，因此構件包括運算和狀態。一個構件可以小到一個過程大到整個軟件系統。他可能需要自己的數據和計算空間或者和其他構件共享[8]。
為了能夠更好的理解構件和他所在的架構。C3模型必須能夠提供一種機制來指定構件的需求，比如架構中其他構件的服務需求。因此接口就可作為一種約定來限制構件的使用方式。
構件的任何一個交互點都叫做端口 (Port),端口我們區分提供端口和需要端口，并從接口的概念繼承而來，端口可以被一個或多個服務所使用。
構件語義上被建模為能夠被演化、分析、約束增強和一致映射從一個層次到另一個抽象層次。構件的結構被描述為提供的和需要的端口，構件的行為被描述為隨環境變化的服務。
3.1.2連接件
連接件就像建筑中的磚塊用來建模構件和規則間的交互。為了能夠提供適當的構件鏈接和交互，他必須提供服務接口。C3提供的交互點叫做角色，顯示的鏈接到構件的端口和其他連接件的角色，這需要架構中的配置元素參與。角色有些像構件的端口，連接件能夠提供的服務用內部的膠水代碼表示[15]。連接件接口被描述為交互點的集合，他能夠推理架構配置的合理性。
在這個層次我們的貢獻在于增強了連接件的結構，在其內部封裝了附件連接，如圖所示。
因此，應用構建者將不用費力在連接件和組件及配置的兼容上。因此開發者只需要選擇和構件或配置接口相兼容的連接件類型就可以了。
我們的連接件符號定義：
通過在連接件內部封裝附件的方式更好的定義了連接件的接口，結果使得構件和配置更簡單、更有條理的組裝在一起，就像搭積木一樣。
3.1.3配置
架構的配置或拓撲結構是構件和鏈接件的連接圖用來描述架構的結構。次信息可以檢測構件是否適當的連接；他們的接口是否匹配；連接件是否能夠適當的交互；他們的組合語義上是否是我們所期望的。
配置的目的是為了抽象構件和連接件的描述細節，來固定他們的交互。配置在一個較高的層次描述了系統組成，為不同的技術專家提供了系統視圖。
為了清晰可見，C3模型中的每個構件和連接件對外都被看作為原型元素，但在內部他可以是一個原子元素也可以是一個組合元素。一個配置可能提供像構件一樣的端口。一個端口提供內外環境交互的橋。C3模型中這個橋用連接件表示。一般的配置可以層次化，比如構件和連接件的內部可以表示子配置，如圖一。
3.1.4接口
任何一個架構元素都有一個接口。任何一個接口都有一個類型，是一個操作的集合。元素通過接口來發布他需要的服務和提供的服務，并且元素通過這些接口相互連接。因此，接口就是元素向外部環境提供的一個契約他必須執行。
我們通過構件和配置提供/需要的端口以及連接件提供/需要的角色來建立元素間的連接。我們將服務分派到適當的端口和角色以及連接過程中的約束集合。端口、角色、服務都是繼承自接口，如圖一所示。在模型層次我們用基數來描述架構元素連接的多重性。這個基數描述了構件和配置的端口數以及連接件的角色數，每個端口和角色像管道一樣對外提供服務。在我們的方法中構件和連接件更容易和更有條理的組合，不需要額外的描述元素間的鏈接關系，因為在連接件外層增加了附件描述，兩個構件的連接只需要找到適當類型的連接件就可以了。這個方法加快了構件的開發，提高了可測試性、一致性、可維護性和市場適應性
先前定義的架構元素通過預先定義的機制在推理模型中操作和使用。本質上，我們是在用實例化、特化、組合和分解以及連接機制，在下面的幾節中我們將一一說明。
3.2 推理模型
在我們的方法中，計劃用不同等級的視圖來分析軟件架構，如圖3表述了基于C3模型的推理模型。
這個模型分為四種不同的等級，每個等級表示在C3表述模型上的視圖并與其他等級相互區別。1.結構等級用來描述等級內部層次的不同。2.行為描述等級顯示了行為層次的不同，一般表示為協議的不同。 3. 概念級別描述架構各層次的結構和行為元素的一致性。4. 元模型級別用來定位我們的模型從何而來，說明我們能夠做什么的問題。
我們為每個等級提供了兩種視圖。第一個是對外邏輯架構圖，這是給設計者和開發者看的；第二個視圖是對內的物理架構圖，這用來表示邏輯架構的內存視圖。一些更細致的討論請看[11]。下面我們將分別討論每個級別類型以及每個級別可能的層級。
3.2.1結構級別(Structural Hierarchy--SH)
結構等級也叫做抽象等級為系統架構提供了結構上的視圖，并用ADL來描述架構元素，主要的ADLs 有Aesop, MetaH, Rapide, SADL。當然在工業界也可以用 CORBA,CCM/CORBA,EJB/J2EE 來描述，這些只能提供一個扁平的架構描述。
用這些ADL來描述架構，只能提供構件通過連接件連接，沒有內部元素，沒有結構等級性。這種方式對構件配置和連接件配置的定義和操作是分開的。
在我們的C3模型中，用構件、連接件和配置來描述架構。在這些配置元素中可以是原始的或者是子配置元素，每個配置元素都包含構件和連接件的配置信息。
在C3表述元模型中，每個等級我們一系列的層次描述。分多少層取決于問題的復雜度。要說明的是所有的架構方案內部都有一個層次性。因此，真正的軟件架構可以視為一個圖，圖中的非葉子節點表示一個配置，葉子節點表示一個原子構件，節點之間表示為連接件。如圖4所示。
根節點用雙圓圈表示第一個抽象層次，他也是一個全局的配置包括了架構中的所有元素。白色的圈表示原子構件，黑色的圈表示子配置。連接件穿越層次，表示了元素間的父子關系，這種父子關系不一定有真正的連接件對應。
為了不同層次的導航我們定義了如下類型的連接件。
3.2.1.1 組合-分解連接件(CDC)
這種類型的連接件用來連接配置和他的孩子元素（配置或原子構件）。因此這種類型的連接件允許層次件的導航。因此我們可以判斷孩子或者爸爸是否在這個導航中。如下圖表示節點7，8，9表述的抽象細節和節點4的一致性。圖4.a 可用七個CDC連接件來表示。
圖5.a 描述了兩個服務連接型的連接件。第一個被表述為隱式的連接叫做綁定。實際上就是引用連接，第二種被很多ADL定義過叫做附著連接。實際上是通過配置文件將構件連接在一起，比如 Spring 的IOC依賴注入連接。如下圖：
3.2.1.2 附著連接(AC)
附著連接被表示為實線如圖5.a。用這種連接件來連接同一抽象層次的原子構件或者配置。更細節的描述見圖 5.b。
這種連接件起到了映射的作用。
l a 提供的服務通過AC的映射被x 調用(e1=s1)。
l b 提供的服務通過AC的映射被z 調用(e2=s2)。
l c 提供的服務通過AC的映射被y 調用(e3=s3)。
在結構級別我們用層次性來處理輸入接口和輸出接口。當我們從 level I 導航到 level i-1 時，輸入接口需要擴展。當我們從 level i-1 導航到 level I 時，輸出接口需要組合。在我們切換層次時數據的格式也需要轉換，下面我們定義擴展和組合連接件。
3.2.1.3 擴展和組合連接件(ECC)
ECC連接件用帶方向的點線表述，如圖5.a，圖5.c描述的更詳細些。我們用這種類型的連接件來建立配置和他下面元素的服務連接，有些ADL中把這種類型的連接件叫做綁定（比如 Acme）或者代理（比如UML）。下圖我們對輸入進行了擴展，對輸出進行了組合。不同的架構元素間通過接口連接，因此接口類型將用來兼容與否的檢測。結果，在結構等級上通過語義來控制元素的組合。
3.2.2行為級別(Behavioral Hierarchy—BH)
行為級別描述系統行為的不同層次，每一原子元素都有自己的行為。下圖描述了系統整體上的行為等級，這個行為用全局協議 P0描述。高層次上，系統架構被視為一個黑匣子提供輸入輸出接口。低層次上，每個構件、連接件、配置、端口、角色都有自己的行為（比如膠水代碼描述連接件行為）。元素行為也可以描述為狀態圖或者 Petri 網絡。協議是一種機制來制定架構元素的功能行為，通過定義元素狀態間的關系以及產生一致性結果的能力。下圖描述了如何分解Ln層的P0協議到Ln-1層的子協議，這個分解產生了一個協議子集(P01,P02,P03), Ln-1層協議又被分解為更低層次的協議子集。直到L0。這個等級的最后一個層次是一個協議的集合，描述了架構中可見的原子行為?？偟膮f議層次集合描述了系統架構的行為等級。
為了描述行為層次間的父子關系，我們定義如下類型的連接件。
3.2.2.1 組合-分解連接件(CDC)
CDC連接件用來連接協議和子協議，因此，這種類型的連接件允許行為等級層次間導航。也可以決定協議間的父子關系，如圖6.b。
3.2.2.2 附著連接(AC)
在行為等級，附著連接件用來連接同一層次的協議。比如一個以轉換為基礎的系統，通過簡單的在在第一個協議的結束狀態和第二個協議的開始狀態間傳輸。每個協議的輸入輸出分別表示為請求的和提供的服務。
3.2.2.3 綁定標識連接件(BIC)
綁定標識連接件用來保持標識和協議輸入輸出的可追溯性。這和結構級別不同，行為級別在改變層次時我們既沒有擴展輸入也沒有組合輸出。結果，所有層次我們都用相同的機制和工具集。因此，我們把一些高層的功能采樣到底層，為的是更好的理解和分析復雜的系統。
元素組合的語義檢查，不能確保架構被驗證正確，只能保證接口的兼容性問題，也就是說元素信息交換的兼容性，而不能保證元素協作時產生結構的一致性。因此，在行為級別開發時，我們要確保每個層次的協議匹配[5] [17].。
必須說明的是，結構級別和行為級別沒有先后順序的關系，因此，設計者可以從任何一個開始設計，這取決于設計者第一手信息。但是，一般如果結構級別適合作為設計的開始，然后在結構級別的每個層次開展行為級別的設計。
3.2.3概念級別(Conceptual Hierarchy—CH)
概念級別允許架構師建模同一系列元素間的關系，如圖7.a 所示，架構的實體表示組件類型。
每種類型都是一個元素，每個元素都有自己的子元素。因此，我們用這圖表來描述同系列的實體級別。每個圖形都有自己的層級編號，最高級別的元素是可重用的基本元素，中間層的元素重用他前面的元素，這些中間元素用來產生其他的或者描述架構的終端元素。最后層次的元素類型用來描述架構。
通過這些特化機制，架構師可以依據目標領域架構開發需求創建和分類元素。子類型的層次數是有限的，但是我們也要在適當的層次來折中考慮架構元素的使用和重用。為了實現概念級別我們定義了下面類型的連接件。
3.2.3.1 特化---一般化連接件(SGC)
這種類型的連接件用來連接相同類型的元素（這種連接件可用Java中的繼承機制實現）。因此，我們能夠簡單的構件所有的樹來分類類型元素，如圖7. b 表示所采用的元素。
3.2.4元模型級別(Metamodeling Hierarchy —CH)
元模型級別可看作4個逐步實例化的層次組成的塔形，如圖8.a。每一層必須遵照上層的約束來描述，每一層為下層提供語義上的支持，A3是最上層，A0是下面一層代表應用系統實例。
A0 層即是系統應用層，他是A1層的實例，在這個層次開發者可能依據系統描述的需要在任意時刻選擇并實例化元素。實例的類型是A1層定義的，元素的創建和組合要依據A1層所定義的約束條件。
A1層也叫架構層，這個層的架構模型是用A2層次定義的語言或者符號集合來定義的，比如 C3 元模型、UML2.0 等等，每個架構模型都是 A2 層元模型的實例。
A2 層用來定義A1層所需要的語言或者符號，屬于元架構層次。這個層次用來修改或改編描述語言，所有操作的開展都要依據高層的定義。
A3 層是元元架構層次。該層擁有最高層次的用來定義新架構描述語言和符號的概念和元素。以前的工作中也定義一種元模型描述語言MADL[14],因此，我們的C3模型順應MADL，MADL類似MOF但是他是面向構件的。
為了建立架構元素到他的類型的連接我們定義如下連接件。
3.2.4.1 實例化連接件(IOC)
這種連接件表示層次間的實例化連接關系，如下圖：
4. 案例研究
為了簡單起見，圖9描述了C/S架構。下面我們將按照文章中介紹的級別類型分別介紹和分析。在下面的圖中我們用數字符號來表示一下元素：
1- 客戶服務器架構
2- 客戶構件
3- 服務器配置
4- 連接管理構件
5- 安全管理構件
6- 數據基礎構件
4.1 結構級別
結構級別對于客戶服務器的例子可以表示為3個層次。如圖10.a 所示，我們用兩個圖來表示這個級別，每個圖都給出了相同節點集合的詳細視圖。每個節點表示為系統的一個元素，左邊的圖用CDC連接件表示組合-分解視圖，右邊的圖用物理連接結構表示同樣的級別，用到了ECC和AC連接件。從這張圖可以看出客戶服務器系統的所有結構元素都被描述了。
圖10.b 描述了RPC連接件（AC的實例），表示客戶構件到服務器配置的一個連接關系。
4.2 行為級別
為了簡化行為級別的描述，我們用了3張圖來表示，每張圖都用到了行為級別的連接件類型，圖11.a 我們用到了兩個CDC描述了行為協議的組合和分解。我們在L2層用P1描述了全局協議，在L1層定義了P2表示客戶端協議，P3表示服務器端協議，在L0層我們用P4、P5、P6協助描述了連接管理、安全管理和數據庫構件。
在圖11.b我們用了BIC連接件描述了可追溯的輸入與輸出，但是在圖12我們只關注了連續的協議流，并在每層用AC連接件表示。
4.3 概念級別
概念級別如圖13.a 表示，用A2層次描述，在這個層次我們用SGC 連接件派生了5個元連接件類型，SGC元連接件是其他類型的連接件的紐帶，所以我們也可以用SGC連接件來描述A1或A0層次的架構元素。
4.4 元模型級別
元模型級別在圖13.b 中描述A1層表示模型類型A0表示對應的實例，A2表示的C3中構件的元模型。這三層用IOC連接件來表示，當然在圖13.a 中我們也用了IOC連接件來表示RPC帶AC連接件的實例化，以及如何從RPC又生成RPC1，RPC2，RPC3都用到IOC。
5. 結論
在這篇文章中，我們定義了一個最小的且完整的表示模型C3模型從不同的視圖來描述和推理軟件架構。C3的核心元素是構件、連接件、配置，各元素通過接口組合，并通過語法語義來檢查接口匹配和協議配置的正確與否。視圖是通過不同的級別定義的，我們結構級別描述結構分解級別，行為描述行為功能分解，概念級別描述子架構元素，概念級別產生的新元素豐富了構件庫。最后，我們展示了如何定義C3模型以及如何使用它。相比傳統的ADL描述語言，它只定義了一種附著連接件，而我們的C3模型定義了6種類型的連接件來處理不同的連接。結構級別用到了組合分解連接件、擴展和組合連接件、附著連接件。行為級別用到了組合分解連接件、綁定標識連接件、附著連接件。概念級別用到了特化連接件。最終元模型級別用到了實例化連接件。
將來的工作：
1. 建立不同級別視圖的關系，這在整合視圖方面是個關鍵的部分。
2. 用UML2.0來定義我們的C3元模型。這個可以把C3模型元素映射到UML元素上。
這一部分也將支持用C3模型到應用代碼的轉換（工具支持）。
6. 參考文獻
[1] Allen, R.J. A Formal Approach to Software Architecture.Ph.D. Thesis, School of Computer Science, Carnegie Mellon University, 1997.
[2] Amirat, A., Oussalah, M., and Khammaci, T. Towards an Approach for Building Reliable Architectures. In Proceedings of (IEEE IRI’07) International Conference on Information Reuse and Integration (IEEE IRI’07), Las
Vegas, Nevada, USA, August 2007, 467-472.
[3] Frakes, W. B. and, Kang, K. Software Reuse Research: Status and Future. IEEE Transactions on Software Engineering, 31, 7, (July 2005), 529-536.
[4] Garlan, D., Monroe, R.T., and Wile, D. Acme: Architectural Description Component-Based Systems, Foundations of Component-Based Systems. Cambridge Univ. Press, 2000,47-68.
[5] Lanoix, A., Hatebur, D., Heisel, M., and Souquières, J.Enhancing Dependability of Component-Based Systems. InProceedings of the International Conference on Reliable Software Technologies (Ada-Europe’07), 2007, 41-54.
[6] Matevska-Meyer, J., Hasselbring, W., and Reussner, R.Software architecture description supporting component
deployment and system runtime reconfiguration. In the Proceedings of WCOP 2004, Workshop on Component-
Oriented Programming , Oslo, June 2004.
[7] Medvidovic, N., Dashofy, E., and Taylor, R.N. MovingArchitectural Description from Under the Technology
Lamppost. Information and Software Technology, 49, 1,(January 2007), 12-31.
[8] Medvidovic, N. Architecture-Based Specification-Time Software Evolution. Ph.D. Thesis, University of California,Irvine, 1999.
[9] OMG. Unified Modeling Superstructure. From http://www.omg.org/docs/ptc/06-04-02.pdf, 2006.
[10] OMG. Unified Modeling Language: Infrastructure. From http://www.omg.org/docs/formal/07-02-06.pdf, 2007.
[11] Oussalah, M., Amirat, A., and Khammaci, T. Software Architecture Based Connection Manager. In Proceedings of the International Conference on Software Engineering and Data Engineering (SEDE’07), Las Vegas, Nevada, USA,July 2007, 194-199.
[12] Pérez-Martínez, J.E. Heavyweight extensions to the UML metamodel to describe the C3 architectural style. ACM SIGSOFT Software Engineering Notes, 28, 3, (May 2003).
[13] Pinto, M., Fluentes, L., and Troya, M. A Dynamic Component and Aspect-Oriented Platform. The Computer
Journal , 48, 4, (July 2005), 401-420.
[14] Smeda, A., Oussalah, M., and Khammaci, T. MADL: Meta Architecture Description Language. In Proceedings of the International conference on Software Engineering Research, Management & Applications (SERA’05), Pleasant, Michigan, USA, August 2005, 152-159.
[15] Smeda, A., Oussalah, M., and Khammaci, T. Improving Component-Based Software Architecture by Separating Computations from Interactions. In Proceedings of the ECOOP Workshop on Coordination and Adaptation Techniques for Software Entities (WCAT'04), Oslo, Norway,2004.
[16] Taylor, R. N., Medvidovic, N., Anderson, K. M., Whitehead, JR., Robbins, J. E., Nies, K. A., Oreizy, P., and Dubrow, D. L. A component and message-based architectural style for GUI software. IEEE Trans. Soft. Eng., 22, 6, (June 1996),390–406.
[17] Schmidt, H., Trustworthy components-compositionality and prediction. Journal of Systems and Software, Special issue on: Component-based software engineering, Elsevier Science Inc., 65, 3, (March 2003), 215-225.
本博客為學習交流用，凡未注明引用的均為本人作品，轉載請注明出處，如有版權問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學習進步。