軟件架構(gòu)中的層次依賴
—jack.wang 2009年大年初一
摘要：在描述大而復(fù)雜的軟件中，最復(fù)雜的抽象層次就是軟件架構(gòu)。因此，在這個(gè)抽象層次我們能更好的理解構(gòu)件組裝原理和交互方式。軟件架構(gòu)被認(rèn)為是軟件開發(fā)方面的驅(qū)動(dòng)力，他允許指定每層那些方面和模型需要依照架構(gòu)來設(shè)計(jì)。早期的架構(gòu)描述語言 ADL，比較獨(dú)立，側(cè)重結(jié)構(gòu)抽象層次而忽略行為描述層次、觀念層次和元模型層次。這篇文章描述了適當(dāng)?shù)?#8220;理性的”軟件架構(gòu)視圖并用 C3 元模型描述（最小的并且完整的描述語言），我們提供了一個(gè)機(jī)制集合以處理不同層次的不同級別，我也提出了一新的用C3元模型描述的連接件的增強(qiáng)定義。
關(guān)鍵字：構(gòu)件；連接件；軟件架構(gòu)；層次架構(gòu)；
目錄
1. 簡介
2. 目標(biāo)
3. C3 原模型
3.1 表述模型
3.1.1 構(gòu)件
3.1.2 連接件
3.1.3 配置
3.1.4 接口
3.2 推理模型
3.2.1 結(jié)構(gòu)級別(Structural Hierarchy--SH)
3.2.2 行為級別(Behavioral Hierarchy—BH)
3.2.3 概念級別(Conceptual Hierarchy—CH)
3.2.4 元模型級別(Metamodeling Hierarchy —CH)
4. 案例研究
6. 參考文獻(xiàn)
寫在前面
這是篇有關(guān)架構(gòu)的論文，通過連接件的增強(qiáng)來描述了不同層級的依賴關(guān)系，文中定義了6種類型的連接件有別于傳統(tǒng)的ADL描述語言的連接關(guān)系。由于翻譯的比較倉促也沒有復(fù)查，一定會有大量的錯(cuò)誤，如果想看可以下載原文！本翻譯后共 7530字，英文原文.pdf
1. 簡介
如今，已經(jīng)有了一個(gè)完整的新方法來構(gòu)建可靠的軟件系統(tǒng)，他將大的復(fù)雜的系統(tǒng)分解為小的精確定義的單元---構(gòu)件（構(gòu)件或控件）。
通常情況下，構(gòu)件被定義為由良好定義的服務(wù)接口和需要接口組成，以及在特定場景下的行為。一個(gè)基于構(gòu)件開發(fā)的應(yīng)用系統(tǒng)由獨(dú)立的構(gòu)件構(gòu)成，他們之間通過接口由精確定義的鏈接件鏈接。
沒有外部可觀測的內(nèi)部結(jié)構(gòu)，并用一種特定語言實(shí)現(xiàn)的構(gòu)件叫做原子構(gòu)件。如果有內(nèi)部結(jié)構(gòu)，即構(gòu)件由內(nèi)部構(gòu)件組成嵌套關(guān)系叫做復(fù)合構(gòu)件。一個(gè)配置結(jié)構(gòu)一般關(guān)聯(lián)到架構(gòu)配置，一般用ADL描述[1]。
軟件架構(gòu)由構(gòu)件、鏈接件、配置和約束組成。軟件架構(gòu)其實(shí)就是系統(tǒng)的模型或者說是系統(tǒng)的抽象。軟件體系結(jié)構(gòu)的研究人員需要可擴(kuò)展的、有彈性的ADL，以及清晰的易操作的機(jī)制來操作這些架構(gòu)層次的核心元素。
一個(gè)清晰的軟件架構(gòu)定義沒有今天，就沒有過去，最近Medvidovic給出了如下定義[7]：一個(gè)軟件架構(gòu)是關(guān)于系統(tǒng)的設(shè)計(jì)決策的集合。因此，如果這些決策不正確，可能致使你的軟件被取消，因?yàn)椋@些決策包括了系統(tǒng)設(shè)計(jì)的方方面面，如下：
1. 系統(tǒng)結(jié)構(gòu)方面的決策：比如一個(gè)系統(tǒng)應(yīng)該包括三種構(gòu)件：數(shù)據(jù)存儲、商業(yè)邏輯、用戶接口。
2. 關(guān)于行為方面的決策—功能決策：比如數(shù)據(jù)處理、存儲和可視化將單獨(dú)被處理。
3. 非功能性需求決策：可靠性、可維護(hù)性、易操作性等等。
4. 當(dāng)然，我們也可以引出其他的設(shè)計(jì)決策，比如開發(fā)過程或者商業(yè)定位（產(chǎn)品線架構(gòu)）等等。
在架構(gòu)設(shè)計(jì)符號和方法的廣泛研究下，我們圍繞構(gòu)件、鏈接件和配置給出了架構(gòu)的描述模型 C3(component, connector, configuration)模型。他和Taylor提出的C2[16]沒有關(guān)系也和Pérez-Martínez [12]提出的C3模型不同。
2. 目標(biāo)
這篇文章的目的就是提出一個(gè)通用的、最小的且完整的架構(gòu)描述模型。最小的是因?yàn)槲覀冎魂P(guān)注每個(gè)ADL的核心觀念。完整的是因?yàn)橛眠@些最小集合的模型能描述所有的架構(gòu)需求。
然而，僅僅描述架構(gòu)是不能保證軟件系統(tǒng)的正確和可靠。本文我們更注重模型表述以及四個(gè)不同類型的層次(每一層提供架構(gòu)的一個(gè)視圖),下面開始細(xì)細(xì)的描述這些層次。
3. C3 原模型
為了設(shè)計(jì)一完整的C3模型，我們定義了兩個(gè)互補(bǔ)的模型來描述和推理系統(tǒng)架構(gòu)。我們用表述模型來描述基于C3元素的架構(gòu)，用推理模型來理解和分析表述模型。
3.1 表述模型
表述模型的核心元素是構(gòu)件、連接件、配置，每個(gè)元素都有接口和他所在的ENV（環(huán)境）交互，如圖所示C3元模型。
3.1.1構(gòu)件
構(gòu)件是一個(gè)計(jì)算或存儲單元，因此構(gòu)件包括運(yùn)算和狀態(tài)。一個(gè)構(gòu)件可以小到一個(gè)過程大到整個(gè)軟件系統(tǒng)。他可能需要自己的數(shù)據(jù)和計(jì)算空間或者和其他構(gòu)件共享[8]。
為了能夠更好的理解構(gòu)件和他所在的架構(gòu)。C3模型必須能夠提供一種機(jī)制來指定構(gòu)件的需求，比如架構(gòu)中其他構(gòu)件的服務(wù)需求。因此接口就可作為一種約定來限制構(gòu)件的使用方式。
構(gòu)件的任何一個(gè)交互點(diǎn)都叫做端口 (Port),端口我們區(qū)分提供端口和需要端口，并從接口的概念繼承而來，端口可以被一個(gè)或多個(gè)服務(wù)所使用。
構(gòu)件語義上被建模為能夠被演化、分析、約束增強(qiáng)和一致映射從一個(gè)層次到另一個(gè)抽象層次。構(gòu)件的結(jié)構(gòu)被描述為提供的和需要的端口，構(gòu)件的行為被描述為隨環(huán)境變化的服務(wù)。
3.1.2連接件
連接件就像建筑中的磚塊用來建模構(gòu)件和規(guī)則間的交互。為了能夠提供適當(dāng)?shù)臉?gòu)件鏈接和交互，他必須提供服務(wù)接口。C3提供的交互點(diǎn)叫做角色，顯示的鏈接到構(gòu)件的端口和其他連接件的角色，這需要架構(gòu)中的配置元素參與。角色有些像構(gòu)件的端口，連接件能夠提供的服務(wù)用內(nèi)部的膠水代碼表示[15]。連接件接口被描述為交互點(diǎn)的集合，他能夠推理架構(gòu)配置的合理性。
在這個(gè)層次我們的貢獻(xiàn)在于增強(qiáng)了連接件的結(jié)構(gòu)，在其內(nèi)部封裝了附件連接，如圖所示。
因此，應(yīng)用構(gòu)建者將不用費(fèi)力在連接件和組件及配置的兼容上。因此開發(fā)者只需要選擇和構(gòu)件或配置接口相兼容的連接件類型就可以了。
我們的連接件符號定義：
通過在連接件內(nèi)部封裝附件的方式更好的定義了連接件的接口，結(jié)果使得構(gòu)件和配置更簡單、更有條理的組裝在一起，就像搭積木一樣。
3.1.3配置
架構(gòu)的配置或拓?fù)浣Y(jié)構(gòu)是構(gòu)件和鏈接件的連接圖用來描述架構(gòu)的結(jié)構(gòu)。次信息可以檢測構(gòu)件是否適當(dāng)?shù)倪B接；他們的接口是否匹配；連接件是否能夠適當(dāng)?shù)慕换ィ凰麄兊慕M合語義上是否是我們所期望的。
配置的目的是為了抽象構(gòu)件和連接件的描述細(xì)節(jié)，來固定他們的交互。配置在一個(gè)較高的層次描述了系統(tǒng)組成，為不同的技術(shù)專家提供了系統(tǒng)視圖。
為了清晰可見，C3模型中的每個(gè)構(gòu)件和連接件對外都被看作為原型元素，但在內(nèi)部他可以是一個(gè)原子元素也可以是一個(gè)組合元素。一個(gè)配置可能提供像構(gòu)件一樣的端口。一個(gè)端口提供內(nèi)外環(huán)境交互的橋。C3模型中這個(gè)橋用連接件表示。一般的配置可以層次化，比如構(gòu)件和連接件的內(nèi)部可以表示子配置，如圖一。
3.1.4接口
任何一個(gè)架構(gòu)元素都有一個(gè)接口。任何一個(gè)接口都有一個(gè)類型，是一個(gè)操作的集合。元素通過接口來發(fā)布他需要的服務(wù)和提供的服務(wù)，并且元素通過這些接口相互連接。因此，接口就是元素向外部環(huán)境提供的一個(gè)契約他必須執(zhí)行。
我們通過構(gòu)件和配置提供/需要的端口以及連接件提供/需要的角色來建立元素間的連接。我們將服務(wù)分派到適當(dāng)?shù)亩丝诤徒巧约斑B接過程中的約束集合。端口、角色、服務(wù)都是繼承自接口，如圖一所示。在模型層次我們用基數(shù)來描述架構(gòu)元素連接的多重性。這個(gè)基數(shù)描述了構(gòu)件和配置的端口數(shù)以及連接件的角色數(shù)，每個(gè)端口和角色像管道一樣對外提供服務(wù)。在我們的方法中構(gòu)件和連接件更容易和更有條理的組合，不需要額外的描述元素間的鏈接關(guān)系，因?yàn)樵谶B接件外層增加了附件描述，兩個(gè)構(gòu)件的連接只需要找到適當(dāng)類型的連接件就可以了。這個(gè)方法加快了構(gòu)件的開發(fā)，提高了可測試性、一致性、可維護(hù)性和市場適應(yīng)性
先前定義的架構(gòu)元素通過預(yù)先定義的機(jī)制在推理模型中操作和使用。本質(zhì)上，我們是在用實(shí)例化、特化、組合和分解以及連接機(jī)制，在下面的幾節(jié)中我們將一一說明。
3.2 推理模型
在我們的方法中，計(jì)劃用不同等級的視圖來分析軟件架構(gòu)，如圖3表述了基于C3模型的推理模型。
這個(gè)模型分為四種不同的等級，每個(gè)等級表示在C3表述模型上的視圖并與其他等級相互區(qū)別。1.結(jié)構(gòu)等級用來描述等級內(nèi)部層次的不同。2.行為描述等級顯示了行為層次的不同，一般表示為協(xié)議的不同。 3. 概念級別描述架構(gòu)各層次的結(jié)構(gòu)和行為元素的一致性。4. 元模型級別用來定位我們的模型從何而來，說明我們能夠做什么的問題。
我們?yōu)槊總€(gè)等級提供了兩種視圖。第一個(gè)是對外邏輯架構(gòu)圖，這是給設(shè)計(jì)者和開發(fā)者看的；第二個(gè)視圖是對內(nèi)的物理架構(gòu)圖，這用來表示邏輯架構(gòu)的內(nèi)存視圖。一些更細(xì)致的討論請看[11]。下面我們將分別討論每個(gè)級別類型以及每個(gè)級別可能的層級。
3.2.1結(jié)構(gòu)級別(Structural Hierarchy--SH)
結(jié)構(gòu)等級也叫做抽象等級為系統(tǒng)架構(gòu)提供了結(jié)構(gòu)上的視圖，并用ADL來描述架構(gòu)元素，主要的ADLs 有Aesop, MetaH, Rapide, SADL。當(dāng)然在工業(yè)界也可以用 CORBA,CCM/CORBA,EJB/J2EE 來描述，這些只能提供一個(gè)扁平的架構(gòu)描述。
用這些ADL來描述架構(gòu)，只能提供構(gòu)件通過連接件連接，沒有內(nèi)部元素，沒有結(jié)構(gòu)等級性。這種方式對構(gòu)件配置和連接件配置的定義和操作是分開的。
在我們的C3模型中，用構(gòu)件、連接件和配置來描述架構(gòu)。在這些配置元素中可以是原始的或者是子配置元素，每個(gè)配置元素都包含構(gòu)件和連接件的配置信息。
在C3表述元模型中，每個(gè)等級我們一系列的層次描述。分多少層取決于問題的復(fù)雜度。要說明的是所有的架構(gòu)方案內(nèi)部都有一個(gè)層次性。因此，真正的軟件架構(gòu)可以視為一個(gè)圖，圖中的非葉子節(jié)點(diǎn)表示一個(gè)配置，葉子節(jié)點(diǎn)表示一個(gè)原子構(gòu)件，節(jié)點(diǎn)之間表示為連接件。如圖4所示。
根節(jié)點(diǎn)用雙圓圈表示第一個(gè)抽象層次，他也是一個(gè)全局的配置包括了架構(gòu)中的所有元素。白色的圈表示原子構(gòu)件，黑色的圈表示子配置。連接件穿越層次，表示了元素間的父子關(guān)系，這種父子關(guān)系不一定有真正的連接件對應(yīng)。
為了不同層次的導(dǎo)航我們定義了如下類型的連接件。
3.2.1.1 組合-分解連接件(CDC)
這種類型的連接件用來連接配置和他的孩子元素（配置或原子構(gòu)件）。因此這種類型的連接件允許層次件的導(dǎo)航。因此我們可以判斷孩子或者爸爸是否在這個(gè)導(dǎo)航中。如下圖表示節(jié)點(diǎn)7，8，9表述的抽象細(xì)節(jié)和節(jié)點(diǎn)4的一致性。圖4.a 可用七個(gè)CDC連接件來表示。
圖5.a 描述了兩個(gè)服務(wù)連接型的連接件。第一個(gè)被表述為隱式的連接叫做綁定。實(shí)際上就是引用連接，第二種被很多ADL定義過叫做附著連接。實(shí)際上是通過配置文件將構(gòu)件連接在一起，比如 Spring 的IOC依賴注入連接。如下圖：
3.2.1.2 附著連接(AC)
附著連接被表示為實(shí)線如圖5.a。用這種連接件來連接同一抽象層次的原子構(gòu)件或者配置。更細(xì)節(jié)的描述見圖 5.b。
這種連接件起到了映射的作用。
l a 提供的服務(wù)通過AC的映射被x 調(diào)用(e1=s1)。
l b 提供的服務(wù)通過AC的映射被z 調(diào)用(e2=s2)。
l c 提供的服務(wù)通過AC的映射被y 調(diào)用(e3=s3)。
在結(jié)構(gòu)級別我們用層次性來處理輸入接口和輸出接口。當(dāng)我們從 level I 導(dǎo)航到 level i-1 時(shí)，輸入接口需要擴(kuò)展。當(dāng)我們從 level i-1 導(dǎo)航到 level I 時(shí)，輸出接口需要組合。在我們切換層次時(shí)數(shù)據(jù)的格式也需要轉(zhuǎn)換，下面我們定義擴(kuò)展和組合連接件。
3.2.1.3 擴(kuò)展和組合連接件(ECC)
ECC連接件用帶方向的點(diǎn)線表述，如圖5.a，圖5.c描述的更詳細(xì)些。我們用這種類型的連接件來建立配置和他下面元素的服務(wù)連接，有些ADL中把這種類型的連接件叫做綁定（比如 Acme）或者代理（比如UML）。下圖我們對輸入進(jìn)行了擴(kuò)展，對輸出進(jìn)行了組合。不同的架構(gòu)元素間通過接口連接，因此接口類型將用來兼容與否的檢測。結(jié)果，在結(jié)構(gòu)等級上通過語義來控制元素的組合。
3.2.2行為級別(Behavioral Hierarchy—BH)
行為級別描述系統(tǒng)行為的不同層次，每一原子元素都有自己的行為。下圖描述了系統(tǒng)整體上的行為等級，這個(gè)行為用全局協(xié)議 P0描述。高層次上，系統(tǒng)架構(gòu)被視為一個(gè)黑匣子提供輸入輸出接口。低層次上，每個(gè)構(gòu)件、連接件、配置、端口、角色都有自己的行為（比如膠水代碼描述連接件行為）。元素行為也可以描述為狀態(tài)圖或者 Petri 網(wǎng)絡(luò)。協(xié)議是一種機(jī)制來制定架構(gòu)元素的功能行為，通過定義元素狀態(tài)間的關(guān)系以及產(chǎn)生一致性結(jié)果的能力。下圖描述了如何分解Ln層的P0協(xié)議到Ln-1層的子協(xié)議，這個(gè)分解產(chǎn)生了一個(gè)協(xié)議子集(P01,P02,P03), Ln-1層協(xié)議又被分解為更低層次的協(xié)議子集。直到L0。這個(gè)等級的最后一個(gè)層次是一個(gè)協(xié)議的集合，描述了架構(gòu)中可見的原子行為。總的協(xié)議層次集合描述了系統(tǒng)架構(gòu)的行為等級。
為了描述行為層次間的父子關(guān)系，我們定義如下類型的連接件。
3.2.2.1 組合-分解連接件(CDC)
CDC連接件用來連接協(xié)議和子協(xié)議，因此，這種類型的連接件允許行為等級層次間導(dǎo)航。也可以決定協(xié)議間的父子關(guān)系，如圖6.b。
3.2.2.2 附著連接(AC)
在行為等級，附著連接件用來連接同一層次的協(xié)議。比如一個(gè)以轉(zhuǎn)換為基礎(chǔ)的系統(tǒng)，通過簡單的在在第一個(gè)協(xié)議的結(jié)束狀態(tài)和第二個(gè)協(xié)議的開始狀態(tài)間傳輸。每個(gè)協(xié)議的輸入輸出分別表示為請求的和提供的服務(wù)。
3.2.2.3 綁定標(biāo)識連接件(BIC)
綁定標(biāo)識連接件用來保持標(biāo)識和協(xié)議輸入輸出的可追溯性。這和結(jié)構(gòu)級別不同，行為級別在改變層次時(shí)我們既沒有擴(kuò)展輸入也沒有組合輸出。結(jié)果，所有層次我們都用相同的機(jī)制和工具集。因此，我們把一些高層的功能采樣到底層，為的是更好的理解和分析復(fù)雜的系統(tǒng)。
元素組合的語義檢查，不能確保架構(gòu)被驗(yàn)證正確，只能保證接口的兼容性問題，也就是說元素信息交換的兼容性，而不能保證元素協(xié)作時(shí)產(chǎn)生結(jié)構(gòu)的一致性。因此，在行為級別開發(fā)時(shí)，我們要確保每個(gè)層次的協(xié)議匹配[5] [17].。
必須說明的是，結(jié)構(gòu)級別和行為級別沒有先后順序的關(guān)系，因此，設(shè)計(jì)者可以從任何一個(gè)開始設(shè)計(jì)，這取決于設(shè)計(jì)者第一手信息。但是，一般如果結(jié)構(gòu)級別適合作為設(shè)計(jì)的開始，然后在結(jié)構(gòu)級別的每個(gè)層次開展行為級別的設(shè)計(jì)。
3.2.3概念級別(Conceptual Hierarchy—CH)
概念級別允許架構(gòu)師建模同一系列元素間的關(guān)系，如圖7.a 所示，架構(gòu)的實(shí)體表示組件類型。
每種類型都是一個(gè)元素，每個(gè)元素都有自己的子元素。因此，我們用這圖表來描述同系列的實(shí)體級別。每個(gè)圖形都有自己的層級編號，最高級別的元素是可重用的基本元素，中間層的元素重用他前面的元素，這些中間元素用來產(chǎn)生其他的或者描述架構(gòu)的終端元素。最后層次的元素類型用來描述架構(gòu)。
通過這些特化機(jī)制，架構(gòu)師可以依據(jù)目標(biāo)領(lǐng)域架構(gòu)開發(fā)需求創(chuàng)建和分類元素。子類型的層次數(shù)是有限的，但是我們也要在適當(dāng)?shù)膶哟蝸碚壑锌紤]架構(gòu)元素的使用和重用。為了實(shí)現(xiàn)概念級別我們定義了下面類型的連接件。
3.2.3.1 特化---一般化連接件(SGC)
這種類型的連接件用來連接相同類型的元素（這種連接件可用Java中的繼承機(jī)制實(shí)現(xiàn)）。因此，我們能夠簡單的構(gòu)件所有的樹來分類類型元素，如圖7. b 表示所采用的元素。
3.2.4元模型級別(Metamodeling Hierarchy —CH)
元模型級別可看作4個(gè)逐步實(shí)例化的層次組成的塔形，如圖8.a。每一層必須遵照上層的約束來描述，每一層為下層提供語義上的支持，A3是最上層，A0是下面一層代表應(yīng)用系統(tǒng)實(shí)例。
A0 層即是系統(tǒng)應(yīng)用層，他是A1層的實(shí)例，在這個(gè)層次開發(fā)者可能依據(jù)系統(tǒng)描述的需要在任意時(shí)刻選擇并實(shí)例化元素。實(shí)例的類型是A1層定義的，元素的創(chuàng)建和組合要依據(jù)A1層所定義的約束條件。
A1層也叫架構(gòu)層，這個(gè)層的架構(gòu)模型是用A2層次定義的語言或者符號集合來定義的，比如 C3 元模型、UML2.0 等等，每個(gè)架構(gòu)模型都是 A2 層元模型的實(shí)例。
A2 層用來定義A1層所需要的語言或者符號，屬于元架構(gòu)層次。這個(gè)層次用來修改或改編描述語言，所有操作的開展都要依據(jù)高層的定義。
A3 層是元元架構(gòu)層次。該層擁有最高層次的用來定義新架構(gòu)描述語言和符號的概念和元素。以前的工作中也定義一種元模型描述語言MADL[14],因此，我們的C3模型順應(yīng)MADL，MADL類似MOF但是他是面向構(gòu)件的。
為了建立架構(gòu)元素到他的類型的連接我們定義如下連接件。
3.2.4.1 實(shí)例化連接件(IOC)
這種連接件表示層次間的實(shí)例化連接關(guān)系，如下圖：
4. 案例研究
為了簡單起見，圖9描述了C/S架構(gòu)。下面我們將按照文章中介紹的級別類型分別介紹和分析。在下面的圖中我們用數(shù)字符號來表示一下元素：
1- 客戶服務(wù)器架構(gòu)
2- 客戶構(gòu)件
3- 服務(wù)器配置
4- 連接管理構(gòu)件
5- 安全管理構(gòu)件
6- 數(shù)據(jù)基礎(chǔ)構(gòu)件
4.1 結(jié)構(gòu)級別
結(jié)構(gòu)級別對于客戶服務(wù)器的例子可以表示為3個(gè)層次。如圖10.a 所示，我們用兩個(gè)圖來表示這個(gè)級別，每個(gè)圖都給出了相同節(jié)點(diǎn)集合的詳細(xì)視圖。每個(gè)節(jié)點(diǎn)表示為系統(tǒng)的一個(gè)元素，左邊的圖用CDC連接件表示組合-分解視圖，右邊的圖用物理連接結(jié)構(gòu)表示同樣的級別，用到了ECC和AC連接件。從這張圖可以看出客戶服務(wù)器系統(tǒng)的所有結(jié)構(gòu)元素都被描述了。
圖10.b 描述了RPC連接件（AC的實(shí)例），表示客戶構(gòu)件到服務(wù)器配置的一個(gè)連接關(guān)系。
4.2 行為級別
為了簡化行為級別的描述，我們用了3張圖來表示，每張圖都用到了行為級別的連接件類型，圖11.a 我們用到了兩個(gè)CDC描述了行為協(xié)議的組合和分解。我們在L2層用P1描述了全局協(xié)議，在L1層定義了P2表示客戶端協(xié)議，P3表示服務(wù)器端協(xié)議，在L0層我們用P4、P5、P6協(xié)助描述了連接管理、安全管理和數(shù)據(jù)庫構(gòu)件。
在圖11.b我們用了BIC連接件描述了可追溯的輸入與輸出，但是在圖12我們只關(guān)注了連續(xù)的協(xié)議流，并在每層用AC連接件表示。
4.3 概念級別
概念級別如圖13.a 表示，用A2層次描述，在這個(gè)層次我們用SGC 連接件派生了5個(gè)元連接件類型，SGC元連接件是其他類型的連接件的紐帶，所以我們也可以用SGC連接件來描述A1或A0層次的架構(gòu)元素。
4.4 元模型級別
元模型級別在圖13.b 中描述A1層表示模型類型A0表示對應(yīng)的實(shí)例，A2表示的C3中構(gòu)件的元模型。這三層用IOC連接件來表示，當(dāng)然在圖13.a 中我們也用了IOC連接件來表示RPC帶AC連接件的實(shí)例化，以及如何從RPC又生成RPC1，RPC2，RPC3都用到IOC。
5. 結(jié)論
在這篇文章中，我們定義了一個(gè)最小的且完整的表示模型C3模型從不同的視圖來描述和推理軟件架構(gòu)。C3的核心元素是構(gòu)件、連接件、配置，各元素通過接口組合，并通過語法語義來檢查接口匹配和協(xié)議配置的正確與否。視圖是通過不同的級別定義的，我們結(jié)構(gòu)級別描述結(jié)構(gòu)分解級別，行為描述行為功能分解，概念級別描述子架構(gòu)元素，概念級別產(chǎn)生的新元素豐富了構(gòu)件庫。最后，我們展示了如何定義C3模型以及如何使用它。相比傳統(tǒng)的ADL描述語言，它只定義了一種附著連接件，而我們的C3模型定義了6種類型的連接件來處理不同的連接。結(jié)構(gòu)級別用到了組合分解連接件、擴(kuò)展和組合連接件、附著連接件。行為級別用到了組合分解連接件、綁定標(biāo)識連接件、附著連接件。概念級別用到了特化連接件。最終元模型級別用到了實(shí)例化連接件。
將來的工作：
1. 建立不同級別視圖的關(guān)系，這在整合視圖方面是個(gè)關(guān)鍵的部分。
2. 用UML2.0來定義我們的C3元模型。這個(gè)可以把C3模型元素映射到UML元素上。
這一部分也將支持用C3模型到應(yīng)用代碼的轉(zhuǎn)換（工具支持）。
6. 參考文獻(xiàn)
[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.
本博客為學(xué)習(xí)交流用，凡未注明引用的均為本人作品，轉(zhuǎn)載請注明出處，如有版權(quán)問題請及時(shí)通知。由于博客時(shí)間倉促，錯(cuò)誤之處敬請諒解，有任何意見可給我留言，愿共同學(xué)習(xí)進(jìn)步。