1、第一章引言傳統的軟件配置治理建立在文件版本操縱的基礎之上， 現代大型軟件系統的開發要求在更大粒度上進行版本操縱。同 時，基于軟件體系結構的軟件開發是當前的進展趨勢，也需要適應其特點的版本治理模型的支持。1.1 版本治理模型概述1.1.1 配置治理概念隨著軟件開發規模的不斷增大， 一個項目中的中間軟件產品 的數目也越來越大，中間軟件產品之間的關系也越來越復雜，對中間產品的治理也越來越困難，有效的配置治理則有助于解決這一問題。現在人們逐漸認識到， 配置治理是適應軟件開發需求的 一種特不有效和現實的技術1 O配置治理是軟件過程的關鍵要素。它是一種按規則實施的治 理軟件開發和維護過程及其軟件產品的方法

2、。軟件配置治理系統在軟件質量治理中也起著重要作用，它不僅是CM的核心內容之一，是絕大多數軟件過程工程和治理過程不可缺少的部分，也是國際標準化組織IS09000質量治理體系的核心內容之一。IEEE定 義了軟件配置治理（SCM的標準2,在那個標準中，SCMZ該 定義四個要緊方面：1）酉已置標識（configuration identification ）：產品、產 品結構和產品中組件的標識及其類型；2）配置操縱（configuration control ）:操縱配置項及其 組件的演化；3）酉已置狀態統計 （ configuration status accounting ）: 記錄報告產品狀態和

3、變更請求，收集組件統計信息；4）審計、審查（audits and reviews ）:維護產品完整性和 一致性。后來，隨著異質平臺開發、團隊協作的出現，配置治理的定義得到進一步的擴展。SCI包括：5）生產（manufacture ）:治理產品組裝和構建；6）過程治理（process management:執行組織的過程、策 略和生命周期模型；7）團隊合作（team work）：支持開發者間的協作。1.1.2 版本治理概念版本治理是SCI）核心功能3,版本治理的差不多任務確實 是同時治理一個數據元素的多個版本 4 o版本治理應該具備以 下的差不多功能：1）創建新本版；2）通過某種選擇機制來訪問特

4、定的版本；3）對版本添加用戶定義的名字或標識；4）刪除版本；5）維護版本間的關系；6）修改已存在的版本，那個操作一 般是不同意的，至少不能是直接的；7）鎖定特定版本；8）版本合弁；9）賦給版本狀態值和屬性值；10）同意用戶自定義數據 對象間的關系。為支持版本治理，需要一個合適的版本模型。該模型需要定 義進行版本化的元素，版本的標識及其組織，版本的查詢，版本 的創建等等。版本模型可因版本化的元素，版本的組織結構、版 本的粒度、面向狀態的版本或者面向變更的版本、版本的選擇規則的不同而不同。5中定義了組成版本模型的差不多術語，如 圖1.1所示：版本版本元素和/項用玨版本化r11|立按噌艮內戰增艮選擇

5、增后砥訂分支版本述版木廣同111間同狀態的取木面向變更的版本 版本用網路w集版本外延小本集內延木柒的泉浦好默認m Ttj1111bE到件粒度完全粒度產晶粒度物理工作優鹿扭_1_作區圖1.1版本模型差不多術語1）版本、版本元素、配置項版本v代表著演化元素i的某一個狀態。版本v能夠通過表達式v = （ ps, vs）來表示，ps、vs分不代表版本 v在產品空間和版本空間中的狀態。版本元素指由版本庫維護其演化的元素。配置是指一個復雜對象的某一版本， 例如：軟件系統的一個配置是由需求文檔、軟件體系結構、程序源代碼的某一版本組成。2）增量兩個版本之間的差不稱之為增量。 一個版本通過對基版本使用一組變更來

6、創建新版本確實是直接增量存儲。而關于內嵌增量和選擇增量存儲，某一元素的所有的版本是存儲在一起的，因此各版本間的共同部分能夠共享。 內嵌增量方式通過指針指向其片 斷來組成一個版本，選擇增量方式通過可見性表達式來決定一個 版本。3）版本演化各版本沿著時刻軸方向順序演化稱之為修訂。如此的演化一般是指修改前一版本的錯誤。 而關于各版本需要并行演化的稱之 為分支。4）版本描述面向狀態的版本治理是指只關懷版本元素的狀態的版本治理。面向狀態的版本治理通過修改和分支來描述一個版本。面向變更的版本治理通過對基線版本使用一組變更來描述一個版本。如此就能夠跟蹤每個版本到底執行了那些變更。面向變更的版本治理有許多的優

7、點：同意基于規則的版本查詢，而非以枚舉的方式掃瞄版本樹；能夠容易的獵取各文件的一致性版本，而無須以手工的方式創建；特不容易比較兩個版本間的差不。但面向變更的版本治理也存在問題：變更的選項是線性增長的。當選項的數量超過一定值時，用戶將面對繁多的選項而無法進行選擇；選項的命名一旦被確定將無法改變，這將導致以后若有類似的選項將特不難于命名；例如：假設差不多存在一個“ fill ” 的選項，假如以后需要增加一個新的“ fill ”選項，其命名可能 就只能是“ newfill ”；由于選項是屬于布爾型的，其取值只能是TRUE FALSERUNSET則在某些情況下，會導致大量的選項出現。例如：若需 要治理

8、一個操作系統的屬性，則對每種操作系統都需要增加一個 選項（DOS WINDOWSUNI痔等）；面向變更的版本治理中版本之間沒有什么明顯的關系，每個版本都能夠作為一個分支，缺乏一個版本的演化歷史。選項間并不是獨立的，有可能存在多種關系；例如：互斥關系，一組選項中只有一個能取值為 TRUE依靠關系，選項的設置依靠于其他選項的設置，比如我們可不能設置SunO魄項，除非我們差不多將UNIX選項設置為TRUE面向狀態的版本模型的優點：能夠清晰地看到版本的演化歷史；完整的保存各版本實體的內容；能夠容易的創建基線，配置等等。面向狀態的版本模型存在的問題：每個版本只代表一個狀態信息，因此不能確定每個版本具體進

9、行了哪些修改。對一個版本描述一般來講只包含該版本與其父版本之間的差不，如此的描述既不精確也不全面。版本之間的差不不能量化，難以實現自由版本查詢。版本選擇大體是通過手工的方式進行。5）版本空間分支和修訂來組成一個版本圖來代表一個版本空間。而網格通過將版本放置入一個 n維的空間中來代表一個版本空間，空間中每一維代表了 一個需要選擇的屬性O6）版本集一個版本元素的所有版本定義為集合 V。V夠通過精確（枚舉）或隱含（版本謂語）方式來定義。關于外延版本，V1過枚舉方式進行定義：V = V1,，Vn。基于外延版本的版本治 理支持檢出之前創建的版本 Vi,然后再檢入新版本Vi+i。內沿版本 支持靈活的創建一

10、致的版本。關于內延版本，V通過一個邏輯的約束進行定義：V = v|con（v）。所有滿足約束con的版本都屬 于V。通過一個選擇謂語evd來選擇集合V中的一個特定版本： evd（ v） con（v）,然后創建新版本。7）版本規則內沿版本是建立在版本規則的基礎上。 約束定義了合法 性規則，偏好定義了用戶優先選擇的規則， 默認定義了在沒有指 定的情況下的規則。8）粒度從用戶的角度，版本的粒度能夠是組件、完全、產品粒度： 關于組件粒度，只有原子組件是在版本治理之下的，每個原子組件都有其自身的版本空間，能夠將組件的特定版本組合成配置； 關于完全粒度，不僅僅是原子組件，而是所有的組件包括配置差不多上在版

11、本治理之下的； 關于產品粒度，所有組件包括配置都在一個統一的全局的版本空間之下，例如：所有的面向變更的版本模型都采納這種版本粒度。9）工作區為進行開發和維護工作，用戶必須在版本庫之外建立一 個工作區，在工作區能夠進行編輯、編譯操作。工作區能夠通過 檢出版本庫中的數據至文件系統來創建，也能夠通過選擇謂語 evd選擇某一版本來提供一個虛擬的工作區。1.2 版本治理模型分類1.2.1 按術語集分類使用 1.1節中定義的術語，能夠對現有的配置治理工具的 版本模型進行分類。圖1.2中將13種配置治理工具的版本模型按 照版本描述和版本粒度分為四類。該分類從術語的角度進行分 類，而不關懷每個術語功能的實現程

12、度。每一類中各個配置治理 工具按照出現的年代及其繼承關系排列版小電間版淮空向弓產黑空祠的交、雙小乂*版本描述，融水*;出國外利曲向狀態1也而變5谷: 4 -. Am耨件毋自12sees*4+XX2&KCS nsfcE+*+KXXTDAMOK LES+十+XX5Pt It+XftShape*+、X7P01 VI+十-4X除怒K-4X9ClmrCnsc二*XX!0FIE+十+XXIIAide de Camp+X12COV*+W2?ZXX413.3期3*.十十+X圖1.2基于術語的分類1）面向狀態-組件粒度版本模型SCCS6是一個簡單的治理文本文件的配置治理工具，版本 通過版本樹的形式進行存儲。用戶

13、將一個版本檢出到工作區中， 當完成變更任務后，他將修改后的版本檢入到SCC飄本庫中。在 SCCSP,文件的組織結構是不可見的。RCS7繼承于SCCS在許多方面進行了改進。RC虢用直接 增量進行存儲，主分支上的最新版本能夠直接訪問，其他版本通過向后和向前增量進行創建。止匕外，RCSt供一組內嵌的屬性集用以標記版本狀態和助記名， 助記名能夠用來標記一個由所有組 件的一致性版本組成的配置。 RC鏈能簡單的支持內延版本（檢 出操作中能夠包含屬性規則）。但操作時RCSfc舊必須要先選擇產 品結構，同時不能對產品結構的版本進行建模。2）面向狀態-完全粒度版本模型DSEE8整合了 Mak酢口SCCS/RC的

14、功能，支持基于規則的配置創建和網絡的并行開發。DSEE1用一個系統模型來描述配置，系統模型描述了軟件系統中的對象及其它們之間的關系。系統模型中不包含各實體的版本，它們是通過配置規則來進行選擇的。用戶首先選擇系統模型中的產品結構，然后再通過配置規則選擇進行版本的綁定。ClearCase9繼承于DSEE它不僅對文件進行版本化，也對 目錄進行版本化，所有版本對象都統一稱為元素。與 DSE不同， ClearCase像訪問其他元素一樣訪問系統模型。3）面向變更-產品粒度版本模型Aide-de-Camp10通過一組變更集和基線來描述產品的版 本。全局變更能夠同時阻礙多個文件。在 Aide-de-Camp中

15、，變更 集是完全順序的，假如變更集 Ci先于變更集C2創建。則某一個產 品的版本假如包含C2,則首先必須先包含Cio每一個變更集能夠 看作一個開關：或者開或者關。但Aide-de-Camp不支持關系。在COV4中，版本數據庫由一組片斷組成， 而每個片段都有 一個邏輯的表達式稱之為可見性（visibility ）。可見性是一組 全局的布爾選項（option ）,這組布爾選項組成了 n-維的版本網 格。COV1過選擇（choice ）和目標（ambition ）規則來進行版本的讀取和修改，選擇中指定了所要選擇版本的選項綁定，而目標通過選項綁定決定了修改會阻礙到的版本空間。4)面向變更-完全粒度版本

16、模型Asgard11 實現在ClearCase之上，在版本圖之上提供 了面向變更的版本治理。每一個組件的版本通過活動(activity ) 進行標記，工作區通過基線和一組活動進行定義。從上面的比較能夠看出，版本模型從面向狀態向面向狀態和 面向變更相結合的方向進展；從面向組件的粒度向面向完全的粒度方向進展。同時還能夠看出盡管專門多的版本治理模型實現的 功能是相似的，但實現的程度卻相差特不之大。因此在本文中實現的版本治理模型應該從實現功能的通行性方面和實現的程度 方面來增強改進。1.2.2 按概念集分類還能夠從版本治理模型提供的概念集，將版本治理模型分為 以下四類12:檢入 / 檢出模式(Chec

17、kIn/CheckOut Model )那個模式提供單系統組件的版本治理。如此版本治理模型有 兩個獨立的工具組成：版本庫工具和創建工具。版本庫工具負責 存儲文件的各個版本以及提供創建新版本的機制。創建工具提供 一個文件描述用于生成應用及自動生成導出文件。在版本庫中的文件不能直接訪問，只能通過檢出操作，檢出后的文件被保存至文件系統，從而能對其進行讀寫。版本庫的并發操縱機制能夠協調多用戶的讀寫活動。文件系統是用戶真正的工作區。版本庫工具沒有提供對工作區的支持，而是依靠于文件系統來提供用戶一個互斥的寫訪問工作區。用戶按照平常方式來使用創建工具等工具，文件的版本關于這些工具來講是透明的。創建工具通過解

18、釋文件系統中的文件描述來創建一個系統。這些文件描述能夠存儲在倉庫中并像一般文件那樣進行版本化。RCS13就屬于這種類型的版本治理模型。組合模式(Composition Model )組合模式通過版本選擇來創建系統配置，組合模型是檢入 / 檢出模式的進展，它同樣采納了版本庫和工作區的概念， 使用文 件鎖來進行并發操縱。其要緊的改進是支持創建配置，維護配置 的歷史。在該模式中，配置作為版本治理模型的實體。一個配置由一個系統模型和版本選擇規則組成。系統模型列出了組成系統所需的所有組件，版本選擇規則指明每個組件的版本。組合和選擇的過程能夠通過一個AND/OI來表示。首先將組件組合成一個配置（AN市點）

19、,然后為每個元素選擇合適的版本（ O甫點），因此 那個元素還能夠是一個配置。DSEE14是屬于這種類型的版本治理模型。長事務模式（Long Transaction Model ）長事務模式將系統的演化描述為一系列的配置項版本和一 系列并發的活動。系統的演化過程一系列原子變更的過程，通過開發者來協調系統的這些變更。開發者對配置進行操作而不是對單個組件。選擇一個配置作 為變更的起點，對該配置所進行的修改外界是看不到的直到該事 務提交。多個事務間通過并發操縱進行協調。一系列變更的結果 是一組順序的配置版本， 稱之為開發路徑。配置版本能夠從已有 的開發路徑分支。在長事務模型中，開發者首先選擇系統配置的

20、 一個版本，然后再關注系統的結構。 組件的版本隱含的由配置決 定。長事務由兩個差不多的概念組成：工作區和并發操縱模式。工作區取代了文件系統，支持開發者在工作區內執行變更活動序 列。通過將工作區中的配置進行提交，從而使得變更變得可見， 同時那個配置將會添加到最初的配置版本之后。現在一個事務結束。NSE15是屬于這種類型的版本治理模型。變更集模式(Change Set Model )變更集模式關注于版本的邏輯變更，關于文件而言，變更集代表兩個文件版本間的差不。關于配置而言，變更集代表兩個配置間的差不。在這種模式中，配置由基線和變更集共同組成。如 對系統公布版本的補丁程序就能夠看成是一種變更集。變更

21、集用來對邏輯變更進行跟蹤，通過在邏輯變更的基礎上定義新的配置。變更集模式本身不提供鎖機制來進行并發操縱，而是通常與檢入/檢出模式共同使用。Aide-De-Camp16確實是屬于這種類型的配置治理系統。但以這種方式進行的分類存在一個缺點確實是各種分類不是正交的，其中的某一分類可能同時也屬于另一分類。本文中的版本治理模型的目標應該在概念集上包含以上各種分類，因此在版本模型的設計上應該從不同的層次上對以上的概念集進 行支持。1.3 軟件體系結構概述1.3.1 軟件復用復用是成熟的工程領域的一個差不多特征，例如，土木工程、化學工程、計算機硬件工程等，通過大量復用通過實踐檢驗的系統體系結構和標準化的構件

22、， 使得關于常規的設計問題都能夠直 接利用現成的解決方案， 幸免了系統開發時不斷地重復設計，從而能夠大幅度地降低開發成本、提高生產效率和產品質量。同樣， 復用也是軟件工程走向成熟的必由之路,將為軟件危機的解決提 供一條現實可行的途徑。基于構件的軟件復用作為一種提高軟件生產率和軟件質量的有效途徑，是近幾年軟件工程界研究的重點之一，被認為是繼面向對象方法之后的一個新的技術熱潮 17 o通過基于構件的軟 件復用，在應用系統開發中能夠充分地利用已有的構件，消除了在分析、設計、編碼、測試等方面的許多重復勞動，能夠提高軟 件開發的效率；同時，通過復用高質量的已有的構件，幸免了重 新開發可能引入的錯誤，能夠

23、提高軟件的質量。因此，基于構件 的軟件復用能夠大大降低軟件開發的費用，并顯著地提高生產率和產品質量。與軟件復用相關的兩個差不多開發活動是面向復用的構件開發和基于構件復用的開發， 前者是生產可復用構件的過程， 后 者是利用現有的可復用構件生產新系統的過程。可復用構件為有打算地、系統地進行復用提供了手段，是實現軟件復用的基石。軟件復用最終體現為在軟件體系結構的指導下對可復用構件的 組裝。1.3.2 軟件體系結構概念自20世紀90年代初期開始，軟件體系結構(software architecture ,簡稱SA)的研究受到了廣泛的關注和重視，并被 認為將會在軟件開發中發揮十分重要的作用。它將大型軟件

24、系統的總體結構作為研究的對象， 認為系統中的計算元素和它們之間 交互的高層組織是系統設計的一個關鍵方面18。其研究和實踐旨在將一個系統的體系結構顯式化,以在高抽象層次處理諸如全 局組織和操縱結構、功能到計算元素的分配、計算元素間的高層 交互等設計問題19 oS渥對軟件總體結構的描述，即對其構件和構件間交互的高 層組織的描述18 o它作為一種高層的設計，對系統開發發揮著重要的阻礙，基于構件的SA勺設計已成為軟件系統設計中的核心 問題。一個好的SAS計成為大型軟件系統成功的重要因素。SA的最重要的一個貢獻是將構件之間的交互顯式的表示為連接器 (Connector),并將連接器視為和構件同等重要的一

25、階實體。構 件通過接口定義了同外界的信息傳遞以及所承擔的系統責任，構件接口包括了構件同周圍環境的全部交互內容，也是構件同外界唯一的交互途徑。除此之外，環境不應對構件作任何其他與接口無關的假設，例如實現細節等。連接器在構件請求接口與其他構 件提供的接口之間搭建一座橋梁，起到了代理作用。在SA勺設計過程中，人們針對不同的需求采納了不同的軟件 構架風格。體系結構風格定義了一系列系統的結構組織的模式 20,它是對一類具有相似結構的系統體系結構的抽象。體系結構風格既定義了構件及連接方式的各種屬性,又規定了它們的組合規則和限制18 o近十年中人們設計了許多 SM格：1）管道-過濾器風格每個過濾器都有輸入端

26、口和輸出端口， 從輸入端口讀入數據 流，進行局部的數據變換（計算或處理）以后，在輸出端口輸出 新生成的數據；管道則負責數據的傳輸，把數據從一個過濾器的 輸出端口傳送到另一個過濾器的輸入端口。 那個過程是順序漸增 的過程，而且過濾器必需是相互獨立的實體。 那個地點的過濾器 是指體系結構中的構件，管道是體系結構中的連接器。2）面向抽象和面向對象組織風格這種風格中，數據表示和與之相連的原語操作被封裝在一個 抽象數據類型或對象中o 這種風格的構件是對象， 也可稱為抽象 數據類型的實例。對象通過函數和過程調用進行交互。這種風格 能夠細分為三種風格:對象連接式風格：在這種類型的體系結構中，構件的接口只定義

27、了其對外提供的服務，而沒有定義構件對外要求的服務， 其中以面向對象中的對象接口為典型代表。這種接口定義的非對稱性使得構件在集成時，構件對外要求的服務被隱藏在代碼的實 現細節中，即構件之間的連接關系無法直接在接口處定義，只能是從一個構件的實現到另一個構件的接口。接口連接式風格：在這種類型的體系結構中， 構件的接口 不但定義了其對外提供的功能，而且定義了其要求的外部功能， 從而顯式地表達了構件對環境的依靠， 提高了構件接口規約的表 達能力。構件的接口定義了所有對外交互的信息，構件在實現時不是直接使用其他構件提供的功能， 而是使用它在接口處定義的 對外要求的功能。構件之間的連接是在所要求的功能和所提

28、供的 功能之間進行匹配，因此，通過接口就能夠定義系統中構件之間 的所有連接。插頭插座式體系風格：當接口定義的功能數量專門大時， 帶來了規模上的問題。在這種體系結構風格中， 通過把如此的彼 此間關系緊密的功能（包括提供的功能和要求的功能）組織成組， 并封裝為服務，使得接口中直接包含的內容減少， 降低了接口中 功能的規模。3)基于事件的隱式調用風格這種風格與面向對象結構風格類似，不同的是，在這種風格中，部件之間的交互不是直接調用，而是通過一種稱之為“隱式調用(implicit invocation) ”的方式來實現的，每個部件提供若干進程及它感興趣的事件，并把每個事件與一個過程聯系在一起，當某個部

29、件產生一個事件時，若其它部件定義了那個事件，那么與該事件聯系在一起的過程將被自動調用，從而間接地完成了過程的調用。4)分層系統風格一個分層系統確實是把整個系統組織成層次結構，每一層都提供若干服務給上一層使用，同時它也使用其下一層所提供的服務。能夠將這種風格細分為兩種：基于層次消息總線的結構風格：消息總線是系統的連接器，負責消息的分派、傳遞和過濾以及處理結果的返回。各個構件掛接在消息總線上，向總線登記感興趣的消息類型，構件依照需要發出消息，由消息總線負責把該消息分配到系統中所有對此消息感興趣的構件，消息是構件之間通訊的唯一方式。構件接收到消息后，依照自身狀態對消息進行響應，并通過總線返回處理 結

30、果。C2M格：C2勾架中的差不多元素是構件、連接器。每個構 件定義有一個頂端接口和一個底端接口，構件通過這兩個接口連接到構架中，這使得構架中構件的增加、刪除、重組更為簡單方 便。每個連接器也定義有頂端接口和底端接口，但接口的數量與連接在其上的構件和連接器的數量有關，這也有利于實現在運行 時的動態綁定。構件之間不存在直接的通信手段，構架中各元素構件、連接器之間的通信只有通過連接器傳遞消息來實現。處于低層的構件向高層的構件發出服務請求消息，消息經由連接器送到相應的構件。各種不同的SAM格的設計均是基于不同類型的連接器20 o文獻21中，連接器被劃分成8種類型：過程調用類型(Process Call

31、)、事件類型(Event)、流類型(Stream)、分布者類型 (Distributor) 、數據接入類型(Data Access)、仲裁者類型 (Arbitrator) 、適配器類型(Adaptor)、聯接類型(Linkage)。文 獻22中，非功能屬性(如保密性，服務質量等)被認為是連接器 描述中的重要組成部分。1.4 軟件體系結構描述語言1.4.1 軟件體系結構描述語言概述SAW究的要緊成果表現為體系結構描述語言(architecturedescription language,簡稱ADL)。從構件組裝的角度來看，ADL能夠視為對構件描述語言(CDL)的進一步擴展。構件描述語言的差不多思

32、想是將構件看成是一個黑盒，通過描述構件接口的語法和語義，使得復用者不必過多地涉及構件代碼細節，就能夠在構件描述這一抽象層次之上進行構件組裝。而ADLBT描述構件接口的語法和語義之外，還負責描述：系統中包括的構件和連接子 以及它們之間的交互關系、構件的非功能類性質以及構件間協 議，從而為構件組裝提供了更為有力的支持。體系結構描述語言(ADL)是為軟件系統的體系結構提供具體的語法和概念框架的一種形式化符號。 迄今為止，研究者差不 多從不同的角度動身，針對不同的目標，提出了各種通用的和專 用的ADL1） Rapide2324: 一種事件驅動的ADL,它以體系結構定 義作為開發框架，支持基于構件的開發

33、。該語言提供了建模、分 析、仿真和代碼生成的能力，然而沒有將連接器顯式化為一階實 體。2） Wright25:具有代表性的AD之一。其要緊特點是將通 信順序進程26 (Communicating Sequential Processes ,簡稱 CSP用于不同風格軟件體系結構的描述，從而完成對體系結構描述的某些形式化推理（包括相容性檢查和死鎖檢查等）3） UniCon27:將一組預定義的連接器映射到具體實現， 從而提供了從模塊到可執行代碼、從體系結構設計生成應用的可 能性。然而目前它只支持一組已選定的連接器，存在一定的局限。4） Aesop28:支持精確的編碼并能夠定義一個新的體系結 構的風格

34、，然后通過加上某些約束和利用它們的所有性質來使用 那個風格。5） xArch29: 一種基于XMLADL它使用XML定義了描述 體系結構的核心元素,能夠作為其他更高級的基于XMLADlL勺基 礎。也能夠用做體系結構描述的交換機制。6） ACME30:支持AD之間映射及工具集成的體系結構互交 換語言。其目標是作為體系結構設計的一個共同的互交換格式,將現有的各種AD在那個框架下統一起來。1.4.2 Wright 構架描述語言Wright AD是基于CSP勺形式化構架描述語言。CSP26中使 用的差不多記號如下所示：1）進程（process ）：使用一系列事件序列來表示一個進程 實體，例如上文中提到

35、的各個 role、port均是一個進程。STOP 是一個專門進程，表示什么事都不做的進程。2）字母表（alphabet ）：進程所能執行的事件的總和；專門 事件：事件 ”代表進程成功結束。進程P的字母表表示為Po3）前綴（prefix ）：設有一事件為x,有一進程為P,則另一 進程先執行事件x,然后按照進程P的講明進行動作；用（x-P） 表7K 04）非確定性選擇（non-deterministic choice ）:進程 AK 者按照P動作，或者按照Q動作，而這種選擇是進程自發做出的。用P球示。5）確定性選擇（deterministic choice ）:進程A或者按照P 動作，或者按照Q動

36、作，而這種選擇是環境做出的。用 P Q我示。6）通信（communication ）:使用二元對c.v來描述的一個事 件，c是發生通信的通道（channel ）的名字，v是通道傳遞的消 息（messaga。使用“？ ”表示同意消息，表示發送消息。7）屏蔽（concealment ）:設 B進程P需要屏蔽掉的事件的 集合,用PC表示，它代表了一個似P動作的進程，只是在C中的 任何事件的發生都被屏蔽掉了。8）并發（parallel ）:進程可口Q勺并發表示為P|Q ,它代表 P, Q字母表中共有的事件需要同步執行，非共有事件不需要同步。9）進程標記（process labeling ）:標記為l的

37、進程昧示為 l：P o則進程中所有的事件也標記上與其所屬進程相同的名字。在進程表達式中一的優先級高于，|操作符。因此e-f-P|g -Q= （e-f-P） | （g-Q。關于其他操作符，未定 義顯示的優先級，因此在使用時用括號來確定優先級。有了 CSP 的差不多記號，我們就能夠對客觀事物描述其動態行為，從而為推理、驗證事物行為提供了強有力的工具。如圖1.3所示，Wright ADL描述的軟件體系結構一共由三部 分組成：1）構件及連接器類型定義：構件類型由一組端口（ port ） 描述和構件功能描述組成，每一個端口是構件與其他構件交互的 邏輯單位；連接器類型由一組角色（role ）和一個粘接器組

38、成， 角色描述了連接器所期待構件的行為，粘接器描述了各角色行為之間的同步。SimrlcExainpltCoitjioncnt ServerPori provide小松用證的打為協議 s曄/構fi &EF的描述I（miponcnt ClientPort request requestSpec /新件C法惟的描述Connect ii r C-S-conneccorHele cfNi.t的行為協黨hole sczcr小爐門”兩方纖劭切 due l汕琮的打為協議7lnHngs: Serverc: ClientC$: C-S-CbnnCclDrAtLachmunts% ,provide 15 c5,sc

39、n cr;c.rcquW as csxLicnl;end SimpleFx ainple,圖1.3 Wright構架描述語言2） 一組構件和連接器的實例定義。3）構件實例與連接器實例間交互定義，將構件實例的端口綁定到連接器實例的角色上，從而完成構件間的交互。eaunectar Shared Dstai =role Useii = -Use門 n gut-User： n 1rok User： =5rt-User： n get-User： H J glue 二 User；一售t-glue Ugei：sei 一段加。Uscti get-+glue | User】 geegluw 、/圖1.4倉庫風格

40、的Wright ADL描述rounctCkiPtpe role Writ er =-Writer n dow- Jrolt Reader - kt ExitOtily =/iu let DoRead = (read-Rende-f Q read-eof ExirOul )in EkiRead Fl ExitOnly虱 nr = let ReadOiily = Re ader read-Rea dOnlyRj? ader.read-e6f - Readw. c lo&e* JReadcrxlose 7in kt WnteOiiK = Writer.writeriteOnlv Writer.close_* J iu WYiter MTke-glue J Reader read-glueWriterlo suReadOulv 口 Reader.clos?-AVnteOillv圖1.5管道過濾器風格的 Wright ADL描述Wright ADl夠用來描述各種軟件體系風格的軟件構架。如圖1.4所示的倉庫風格，圖1.5所示的管道過濾器風格。1.5相關工作配置治理中的版本治理模型一直是軟件工程界研究的熱點。在31中提出了版本治理模型的