基于軟件體系結(jié)構(gòu)的版本管理模型的研究

1、第一章 引言 傳統(tǒng)的軟件配置管理建立在文件版本控制的基礎(chǔ)之上，現(xiàn)代大型軟件系統(tǒng)的開發(fā)要求在更大粒度上進行版本控制。同時，基于軟件體系結(jié)構(gòu)的軟件開發(fā)是當(dāng)前的發(fā)展趨勢，也需要適應(yīng)其特點的版本管理模型的支持。1.1 版本管理模型概述1.1.1 配置管理概念隨著軟件開發(fā)規(guī)模的不斷增大，一個項目中的中間軟件產(chǎn)品的數(shù)目也越來越大，中間軟件產(chǎn)品之間的關(guān)系也越來越復(fù)雜，對中間產(chǎn)品的管理也越來越困難，有效的配置管理則有助于解決這一問題?，F(xiàn)在人們逐漸認(rèn)識到，配置管理是適應(yīng)軟件開發(fā)需求的一種非常有效和現(xiàn)實的技術(shù)1。配置管理是軟件過程的關(guān)鍵要素。它是一種按規(guī)則實施的管理軟件開發(fā)和維護過程及其軟件產(chǎn)品的方法。軟件配置管

2、理系統(tǒng)在軟件質(zhì)量管理中也起著重要作用，它不僅是CMM的核心內(nèi)容之一，是絕大多數(shù)軟件過程工程和管理過程不可缺少的部分，也是國際標(biāo)準(zhǔn)化組織IS09000質(zhì)量管理體系的核心內(nèi)容之一。IEEE定義了軟件配置管理（SCM）的標(biāo)準(zhǔn)2，在這個標(biāo)準(zhǔn)中，SCM應(yīng)該定義四個主要方面：1）配置標(biāo)識（configuration identification）：產(chǎn)品、產(chǎn)品結(jié)構(gòu)和產(chǎn)品中組件的標(biāo)識及其類型；2）配置控制（configuration control）：控制配置項及其組件的演化；3）配置狀態(tài)統(tǒng)計（configuration status accounting）：記錄報告產(chǎn)品狀態(tài)和變更請求，收集組件統(tǒng)計信息；4）

3、審計、審查（audits and reviews）：維護產(chǎn)品完整性和一致性。后來，隨著異質(zhì)平臺開發(fā)、團隊協(xié)作的出現(xiàn)，配置管理的定義得到進一步的擴展。SCM還包括：5）生產(chǎn)（manufacture）：管理產(chǎn)品組裝和構(gòu)建；6）過程管理（process management）：執(zhí)行組織的過程、策略和生命周期模型；7）團隊合作（team work）：支持開發(fā)者間的協(xié)作。1.1.2 版本管理概念版本管理是SCM的核心功能3，版本管理的基本任務(wù)就是同時管理一個數(shù)據(jù)元素的多個版本4。版本管理應(yīng)該具備以下的基本功能：1）創(chuàng)建新本版；2）通過某種選擇機制來訪問特定的版本；3）對版本添加用戶定義的名字或標(biāo)識；4）

4、刪除版本；5）維護版本間的關(guān)系；6）修改已存在的版本，這個操作一般是不允許的，至少不能是直接的；7）鎖定特定版本；8）版本合并；9）賦給版本狀態(tài)值和屬性值；10）允許用戶自定義數(shù)據(jù)對象間的關(guān)系。為支持版本管理，需要一個合適的版本模型。該模型需要定義進行版本化的元素，版本的標(biāo)識及其組織，版本的查詢，版本的創(chuàng)建等等。版本模型可因版本化的元素，版本的組織結(jié)構(gòu)、版本的粒度、面向狀態(tài)的版本或者面向變更的版本、版本的選擇規(guī)則的不同而不同。5中定義了組成版本模型的基本術(shù)語，如圖1.1所示：圖1.1 版本模型基本術(shù)語1）版本、版本元素、配置項版本v代表著演化元素i的某一個狀態(tài)。版本v可以通過表達式v = (p

5、s, vs)來表示，ps、vs分別代表版本v在產(chǎn)品空間和版本空間中的狀態(tài)。版本元素指由版本庫維護其演化的元素。配置是指一個復(fù)雜對象的某一版本，例如：軟件系統(tǒng)的一個配置是由需求文檔、軟件體系結(jié)構(gòu)、程序源代碼的某一版本組成。2）增量兩個版本之間的差別稱之為增量。一個版本通過對基版本使用一組變更來創(chuàng)建新版本就是直接增量存儲。而對于內(nèi)嵌增量和選擇增量存儲，某一元素的所有的版本是存儲在一起的，因此各版本間的共同部分可以共享。內(nèi)嵌增量方式通過指針指向其片斷來組成一個版本，選擇增量方式通過可見性表達式來決定一個版本。3）版本演化各版本沿著時間軸方向順序演化稱之為修訂。這樣的演化一般是指修改前一版本的錯誤。而

6、對于各版本需要并行演化的稱之為分支。4）版本描述面向狀態(tài)的版本管理是指只關(guān)心版本元素的狀態(tài)的版本管理。面向狀態(tài)的版本管理通過修改和分支來描述一個版本。面向變更的版本管理通過對基線版本使用一組變更來描述一個版本。這樣就可以跟蹤每個版本到底執(zhí)行了那些變更。面向變更的版本管理有許多的優(yōu)點：j允許基于規(guī)則的版本查詢，而非以枚舉的方式瀏覽版本樹；k可以容易的獲取各文件的一致性版本，而無須以手工的方式創(chuàng)建；l非常容易比較兩個版本間的差別。但面向變更的版本管理也存在問題：j變更的選項是線性增長的。當(dāng)選項的數(shù)量超過一定值時，用戶將面對繁多的選項而無法進行選擇；k選項的命名一旦被確定將無法改變，這將導(dǎo)致以后若有

7、類似的選項將非常難于命名；例如：假設(shè)已經(jīng)存在一個“fill”的選項，如果以后需要增加一個新的“fill”選項，其命名可能就只能是“newfill”；l由于選項是屬于布爾型的，其取值只能是TRUE，F(xiàn)ALSE和UNSET。則在某些情況下，會導(dǎo)致大量的選項出現(xiàn)。例如：若需要管理一個操作系統(tǒng)的屬性，則對每種操作系統(tǒng)都需要增加一個選項（DOS，WINDOWS，UNIX等等）；m面向變更的版本管理中版本之間沒有什么明顯的關(guān)系，每個版本都可以作為一個分支，缺乏一個版本的演化歷史。n選項間并不是獨立的，有可能存在多種關(guān)系；例如：互斥關(guān)系，一組選項中只有一個能取值為TRUE；依賴關(guān)系，選項的設(shè)置依賴于其他選項

8、的設(shè)置，比如我們不會設(shè)置SunOS選項，除非我們已經(jīng)將UNIX選項設(shè)置為TRUE；面向狀態(tài)的版本模型的優(yōu)點：j可以清楚地看到版本的演化歷史；k完整的保存各版本實體的內(nèi)容；l可以容易的創(chuàng)建基線，配置等等。面向狀態(tài)的版本模型存在的問題：j每個版本只代表一個狀態(tài)信息，所以不能確定每個版本具體進行了哪些修改。k對一個版本描述一般來說只包含該版本與其父版本之間的差別，這樣的描述既不精確也不全面。l版本之間的差別不能量化，難以實現(xiàn)自由版本查詢。m版本選擇大體是通過手工的方式進行。5）版本空間 分支和修訂來組成一個版本圖來代表一個版本空間。而網(wǎng)格通過將版本放置入一個n維的空間中來代表一個版本空間，空間中每一

9、維代表了一個需要選擇的屬性。6）版本集 一個版本元素的所有版本定義為集合V。V可以通過精確（枚舉）或隱含（版本謂語）方式來定義。對于外延版本，V通過枚舉方式進行定義：V = v1,vn?；谕庋影姹镜陌姹竟芾碇С謾z出之前創(chuàng)建的版本vi，然后再檢入新版本vi+1。內(nèi)沿版本支持靈活的創(chuàng)建一致的版本。對于內(nèi)延版本，V通過一個邏輯的約束進行定義：V = v|con(v)。所有滿足約束con的版本都屬于V。通過一個選擇謂語evd來選擇集合V中的一個特定版本：evd(v)Ùcon(v)，然后創(chuàng)建新版本。7）版本規(guī)則 內(nèi)沿版本是建立在版本規(guī)則的基礎(chǔ)上。約束定義了合法性規(guī)則，偏好定義了用戶優(yōu)先選擇的

10、規(guī)則，默認(rèn)定義了在沒有指定的情況下的規(guī)則。8）粒度從用戶的角度，版本的粒度可以是組件、完全、產(chǎn)品粒度：對于組件粒度，只有原子組件是在版本管理之下的，每個原子組件都有其自身的版本空間，可以將組件的特定版本組合成配置；對于完全粒度，不僅僅是原子組件，而是所有的組件包括配置都是在版本管理之下的；對于產(chǎn)品粒度，所有組件包括配置都在一個統(tǒng)一的全局的版本空間之下，例如：所有的面向變更的版本模型都采用這種版本粒度。9）工作區(qū) 為進行開發(fā)和維護工作，用戶必須在版本庫之外建立一個工作區(qū)，在工作區(qū)可以進行編輯、編譯操作。工作區(qū)可以通過檢出版本庫中的數(shù)據(jù)至文件系統(tǒng)來創(chuàng)建，也可以通過選擇謂語evd選擇某一版本來提供一

11、個虛擬的工作區(qū)。1.2 版本管理模型分類1.2.1 按術(shù)語集分類使用§1.1節(jié)中定義的術(shù)語，可以對現(xiàn)有的配置管理工具的版本模型進行分類。圖1.2中將13種配置管理工具的版本模型按照版本描述和版本粒度分為四類。該分類從術(shù)語的角度進行分類，而不關(guān)心每個術(shù)語功能的實現(xiàn)程度。每一類中各個配置管理工具按照出現(xiàn)的年代及其繼承關(guān)系排列。圖1.2 基于術(shù)語的分類1）面向狀態(tài)-組件粒度版本模型SCCS6是一個簡單的管理文本文件的配置管理工具，版本通過版本樹的形式進行存儲。用戶將一個版本檢出到工作區(qū)中，當(dāng)完成變更任務(wù)后，他將修改后的版本檢入到SCCS版本庫中。在SCCS中，文件的組織結(jié)構(gòu)是不可見的。RC

12、S7繼承于SCCS，在許多方面進行了改進。RCS使用直接增量進行存儲，主分支上的最新版本可以直接訪問，其他版本通過向后和向前增量進行創(chuàng)建。此外，RCS提供一組內(nèi)嵌的屬性集用以標(biāo)記版本狀態(tài)和助記名，助記名可以用來標(biāo)記一個由所有組件的一致性版本組成的配置。RCS還能簡單的支持內(nèi)延版本（檢出操作中可以包含屬性規(guī)則）。但操作時RCS還是必須要先選擇產(chǎn)品結(jié)構(gòu)，并且不能對產(chǎn)品結(jié)構(gòu)的版本進行建模。2）面向狀態(tài)-完全粒度版本模型DSEE8整合了Make和SCCS/RCS的功能，支持基于規(guī)則的配置創(chuàng)建和網(wǎng)絡(luò)的并行開發(fā)。DSEE使用一個系統(tǒng)模型來描述配置，系統(tǒng)模型描述了軟件系統(tǒng)中的對象及其它們之間的關(guān)系。系統(tǒng)模型

13、中不包含各實體的版本，它們是通過配置規(guī)則來進行選擇的。用戶首先選擇系統(tǒng)模型中的產(chǎn)品結(jié)構(gòu)，然后再通過配置規(guī)則選擇進行版本的綁定。ClearCase9繼承于DSEE，它不僅對文件進行版本化，也對目錄進行版本化，所有版本對象都統(tǒng)一稱為元素。與DSEE不同，ClearCase像訪問其他元素一樣訪問系統(tǒng)模型。3）面向變更-產(chǎn)品粒度版本模型Aide-de-Camp10通過一組變更集和基線來描述產(chǎn)品的版本。全局變更可以同時影響多個文件。在Aide-de-Camp中，變更集是完全順序的，如果變更集c1先于變更集c2創(chuàng)建。則某一個產(chǎn)品的版本如果包含c2，則首先必須先包含c1。每一個變更集可以看作一個開關(guān)：或者開

14、或者關(guān)。但Aide-de-Camp不支持關(guān)系。在COV4中，版本數(shù)據(jù)庫由一組片斷組成，而每個片段都有一個邏輯的表達式稱之為可見性（visibility）。可見性是一組全局的布爾選項（option），這組布爾選項組成了n-維的版本網(wǎng)格。COV通過選擇（choice）和目標(biāo)（ambition）規(guī)則來進行版本的讀取和修改，選擇中指定了所要選擇版本的選項綁定，而目標(biāo)通過選項綁定決定了修改會影響到的版本空間。4）面向變更-完全粒度版本模型 Asgard11實現(xiàn)在ClearCase之上，在版本圖之上提供了面向變更的版本管理。每一個組件的版本通過活動（activity）進行標(biāo)記，工作區(qū)通過基線和一組活動進行

15、定義。從上面的比較可以看出，版本模型從面向狀態(tài)向面向狀態(tài)和面向變更相結(jié)合的方向發(fā)展；從面向組件的粒度向面向完全的粒度方向發(fā)展。同時還可以看出雖然很多的版本管理模型實現(xiàn)的功能是相似的，但實現(xiàn)的程度卻相差非常之大。因此在本文中實現(xiàn)的版本管理模型應(yīng)該從實現(xiàn)功能的通行性方面和實現(xiàn)的程度方面來增強改進。1.2.2 按概念集分類還可以從版本管理模型提供的概念集，將版本管理模型分為以下四類12：檢入/檢出模式（CheckIn/CheckOut Model）這個模式提供單系統(tǒng)組件的版本管理。這樣版本管理模型有兩個獨立的工具組成：版本庫工具和創(chuàng)建工具。版本庫工具負(fù)責(zé)存儲文件的各個版本以及提供創(chuàng)建新版本的機制。創(chuàng)

16、建工具提供一個文件描述用于生成應(yīng)用及自動生成導(dǎo)出文件。在版本庫中的文件不能直接訪問，只能通過檢出操作，檢出后的文件被保存至文件系統(tǒng)，從而能對其進行讀寫。版本庫的并發(fā)控制機制可以協(xié)調(diào)多用戶的讀寫活動。文件系統(tǒng)是用戶真正的工作區(qū)。版本庫工具沒有提供對工作區(qū)的支持，而是依賴于文件系統(tǒng)來提供用戶一個互斥的寫訪問工作區(qū)。用戶按照尋常方式來使用創(chuàng)建工具等工具，文件的版本對于這些工具來說是透明的。創(chuàng)建工具通過解釋文件系統(tǒng)中的文件描述來創(chuàng)建一個系統(tǒng)。這些文件描述可以存儲在倉庫中并像一般文件那樣進行版本化。RCS13就屬于這種類型的版本管理模型。組合模式（Composition Model）組合模式通過版本選擇

17、來創(chuàng)建系統(tǒng)配置，組合模型是檢入/檢出模式的發(fā)展，它同樣采用了版本庫和工作區(qū)的概念，使用文件鎖來進行并發(fā)控制。其主要的改進是支持創(chuàng)建配置，維護配置的歷史。在該模式中，配置作為版本管理模型的實體。一個配置由一個系統(tǒng)模型和版本選擇規(guī)則組成。系統(tǒng)模型列出了組成系統(tǒng)所需的所有組件，版本選擇規(guī)則指明每個組件的版本。組合和選擇的過程可以通過一個AND/OR圖來表示。首先將組件組合成一個配置（AND節(jié)點），然后為每個元素選擇合適的版本（OR節(jié)點），當(dāng)然這個元素還可以是一個配置。DSEE14是屬于這種類型的版本管理模型。長事務(wù)模式（Long Transaction Model）長事務(wù)模式將系統(tǒng)的演化描述為一系列

18、的配置項版本和一系列并發(fā)的活動。系統(tǒng)的演化過程一系列原子變更的過程，通過開發(fā)者來協(xié)調(diào)系統(tǒng)的這些變更。開發(fā)者對配置進行操作而不是對單個組件。選擇一個配置作為變更的起點，對該配置所進行的修改外界是看不到的直到該事務(wù)提交。多個事務(wù)間通過并發(fā)控制進行協(xié)調(diào)。一系列變更的結(jié)果是一組順序的配置版本，稱之為開發(fā)路徑。配置版本可以從已有的開發(fā)路徑分支。在長事務(wù)模型中，開發(fā)者首先選擇系統(tǒng)配置的一個版本，然后再關(guān)注系統(tǒng)的結(jié)構(gòu)。組件的版本隱含的由配置決定。長事務(wù)由兩個基本的概念組成：工作區(qū)和并發(fā)控制模式。工作區(qū)取代了文件系統(tǒng)，支持開發(fā)者在工作區(qū)內(nèi)執(zhí)行變更活動序列。通過將工作區(qū)中的配置進行提交，從而使得變更變得可見，同

19、時這個配置將會添加到最初的配置版本之后。此時一個事務(wù)結(jié)束。NSE15是屬于這種類型的版本管理模型。變更集模式（Change Set Model）變更集模式關(guān)注于版本的邏輯變更，對于文件而言，變更集代表兩個文件版本間的差別。對于配置而言，變更集代表兩個配置間的差別。在這種模式中，配置由基線和變更集共同組成。如對系統(tǒng)發(fā)布版本的補丁程序就可以看成是一種變更集。變更集用來對邏輯變更進行跟蹤，通過在邏輯變更的基礎(chǔ)上定義新的配置。變更集模式本身不提供鎖機制來進行并發(fā)控制，而是通常與檢入/檢出模式共同使用。Aide-De-Camp16就是屬于這種類型的配置管理系統(tǒng)。 但以這種方式進行的分類存在一個缺點就是各

20、種分類不是正交的，其中的某一分類可能同時也屬于另一分類。本文中的版本管理模型的目標(biāo)應(yīng)該在概念集上包含以上各種分類，因此在版本模型的設(shè)計上應(yīng)該從不同的層次上對以上的概念集進行支持。1.3 軟件體系結(jié)構(gòu)概述1.3.1 軟件復(fù)用復(fù)用是成熟的工程領(lǐng)域的一個基本特征，例如，土木工程、化學(xué)工程、計算機硬件工程等，通過大量復(fù)用經(jīng)過實踐檢驗的系統(tǒng)體系結(jié)構(gòu)和標(biāo)準(zhǔn)化的構(gòu)件，使得對于常規(guī)的設(shè)計問題都可以直接利用現(xiàn)成的解決方案，避免了系統(tǒng)開發(fā)時不斷地重復(fù)設(shè)計，從而可以大幅度地降低開發(fā)成本、提高生產(chǎn)效率和產(chǎn)品質(zhì)量。同樣，復(fù)用也是軟件工程走向成熟的必由之路,將為軟件危機的解決提供一條現(xiàn)實可行的途徑?；跇?gòu)件的軟件復(fù)用作為

21、一種提高軟件生產(chǎn)率和軟件質(zhì)量的有效途徑，是近幾年軟件工程界研究的重點之一，被認(rèn)為是繼面向?qū)ο蠓椒ㄖ蟮囊粋€新的技術(shù)熱潮17。通過基于構(gòu)件的軟件復(fù)用，在應(yīng)用系統(tǒng)開發(fā)中可以充分地利用已有的構(gòu)件，消除了在分析、設(shè)計、編碼、測試等方面的許多重復(fù)勞動，可以提高軟件開發(fā)的效率；同時，通過復(fù)用高質(zhì)量的已有的構(gòu)件，避免了重新開發(fā)可能引入的錯誤，可以提高軟件的質(zhì)量。因此，基于構(gòu)件的軟件復(fù)用可以大大降低軟件開發(fā)的費用，并顯著地提高生產(chǎn)率和產(chǎn)品質(zhì)量。與軟件復(fù)用相關(guān)的兩個基本開發(fā)活動是面向復(fù)用的構(gòu)件開發(fā)和基于構(gòu)件復(fù)用的開發(fā)，前者是生產(chǎn)可復(fù)用構(gòu)件的過程，后者是利用現(xiàn)有的可復(fù)用構(gòu)件生產(chǎn)新系統(tǒng)的過程?？蓮?fù)用構(gòu)件為有計劃地、

22、系統(tǒng)地進行復(fù)用提供了手段，是實現(xiàn)軟件復(fù)用的基石。軟件復(fù)用最終體現(xiàn)為在軟件體系結(jié)構(gòu)的指導(dǎo)下對可復(fù)用構(gòu)件的組裝。1.3.2 軟件體系結(jié)構(gòu)概念自20世紀(jì)90年代初期開始，軟件體系結(jié)構(gòu)(software architecture，簡稱SA)的研究受到了廣泛的關(guān)注和重視，并被認(rèn)為將會在軟件開發(fā)中發(fā)揮十分重要的作用。它將大型軟件系統(tǒng)的總體結(jié)構(gòu)作為研究的對象，認(rèn)為系統(tǒng)中的計算元素和它們之間交互的高層組織是系統(tǒng)設(shè)計的一個關(guān)鍵方面18。其研究和實踐旨在將一個系統(tǒng)的體系結(jié)構(gòu)顯式化,以在高抽象層次處理諸如全局組織和控制結(jié)構(gòu)、功能到計算元素的分配、計算元素間的高層交互等設(shè)計問題19。SA是對軟件總體結(jié)構(gòu)的描述，即對其

23、構(gòu)件和構(gòu)件間交互的高層組織的描述18。它作為一種高層的設(shè)計，對系統(tǒng)開發(fā)發(fā)揮著重要的影響，基于構(gòu)件的SA的設(shè)計已成為軟件系統(tǒng)設(shè)計中的核心問題。一個好的SA設(shè)計成為大型軟件系統(tǒng)成功的重要因素。SA的最重要的一個貢獻是將構(gòu)件之間的交互顯式的表示為連接器(Connector)，并將連接器視為和構(gòu)件同等重要的一階實體。構(gòu)件通過接口定義了同外界的信息傳遞以及所承擔(dān)的系統(tǒng)責(zé)任，構(gòu)件接口包括了構(gòu)件同周圍環(huán)境的全部交互內(nèi)容，也是構(gòu)件同外界唯一的交互途徑。除此之外，環(huán)境不應(yīng)對構(gòu)件作任何其他與接口無關(guān)的假設(shè)，例如實現(xiàn)細(xì)節(jié)等。連接器在構(gòu)件請求接口與其他構(gòu)件提供的接口之間搭建一座橋梁，起到了代理作用。在SA的設(shè)計過程中

24、，人們針對不同的需求采用了不同的軟件構(gòu)架風(fēng)格。體系結(jié)構(gòu)風(fēng)格定義了一系列系統(tǒng)的結(jié)構(gòu)組織的模式20，它是對一類具有相似結(jié)構(gòu)的系統(tǒng)體系結(jié)構(gòu)的抽象。體系結(jié)構(gòu)風(fēng)格既定義了構(gòu)件及連接方式的各種屬性, 又規(guī)定了它們的組合規(guī)則和限制18。近十年中人們設(shè)計了許多SA風(fēng)格：1）管道-過濾器風(fēng)格每個過濾器都有輸入端口和輸出端口，從輸入端口讀入數(shù)據(jù)流，進行局部的數(shù)據(jù)變換(計算或處理) 以后，在輸出端口輸出新生成的數(shù)據(jù)；管道則負(fù)責(zé)數(shù)據(jù)的傳輸，把數(shù)據(jù)從一個過濾器的輸出端口傳送到另一個過濾器的輸入端口。這個過程是順序漸增的過程，而且過濾器必需是相互獨立的實體。這里的過濾器是指體系結(jié)構(gòu)中的構(gòu)件，管道是體系結(jié)構(gòu)中的連接器。2）

25、面向抽象和面向?qū)ο蠼M織風(fēng)格這種風(fēng)格中，數(shù)據(jù)表示和與之相連的原語操作被封裝在一個抽象數(shù)據(jù)類型或?qū)ο笾?。這種風(fēng)格的構(gòu)件是對象，也可稱為抽象數(shù)據(jù)類型的實例。對象通過函數(shù)和過程調(diào)用進行交互。這種風(fēng)格可以細(xì)分為三種風(fēng)格：j對象連接式風(fēng)格：在這種類型的體系結(jié)構(gòu)中,構(gòu)件的接口只定義了其對外提供的服務(wù)，而沒有定義構(gòu)件對外要求的服務(wù)，其中以面向?qū)ο笾械膶ο蠼涌跒榈湫痛?。這種接口定義的非對稱性使得構(gòu)件在集成時，構(gòu)件對外要求的服務(wù)被隱藏在代碼的實現(xiàn)細(xì)節(jié)中，即構(gòu)件之間的連接關(guān)系無法直接在接口處定義，只能是從一個構(gòu)件的實現(xiàn)到另一個構(gòu)件的接口。k接口連接式風(fēng)格：在這種類型的體系結(jié)構(gòu)中，構(gòu)件的接口不但定義了其對外提供的功

26、能，而且定義了其要求的外部功能，從而顯式地表達了構(gòu)件對環(huán)境的依賴，提高了構(gòu)件接口規(guī)約的表達能力。構(gòu)件的接口定義了所有對外交互的信息，構(gòu)件在實現(xiàn)時不是直接使用其他構(gòu)件提供的功能，而是使用它在接口處定義的對外要求的功能。構(gòu)件之間的連接是在所要求的功能和所提供的功能之間進行匹配，因此，通過接口就可以定義系統(tǒng)中構(gòu)件之間的所有連接。l插頭插座式體系風(fēng)格：當(dāng)接口定義的功能數(shù)量很大時，帶來了規(guī)模上的問題。在這種體系結(jié)構(gòu)風(fēng)格中，通過把這樣的彼此間關(guān)系緊密的功能(包括提供的功能和要求的功能)組織成組，并封裝為服務(wù)，使得接口中直接包含的內(nèi)容減少，降低了接口中功能的規(guī)模。3）基于事件的隱式調(diào)用風(fēng)格這種風(fēng)格與面向?qū)ο?/p>

27、結(jié)構(gòu)風(fēng)格類似，不同的是，在這種風(fēng)格中，部件之間的交互不是直接調(diào)用，而是通過一種稱之為“隱式調(diào)用(implicit invocation) ”的方式來實現(xiàn)的，每個部件提供若干進程及它感興趣的事件，并把每個事件與一個過程聯(lián)系在一起，當(dāng)某個部件產(chǎn)生一個事件時，若其它部件定義了這個事件，那么與該事件聯(lián)系在一起的過程將被自動調(diào)用，從而間接地完成了過程的調(diào)用。4）分層系統(tǒng)風(fēng)格 一個分層系統(tǒng)就是把整個系統(tǒng)組織成層次結(jié)構(gòu)，每一層都提供若干服務(wù)給上一層使用，并且它也使用其下一層所提供的服務(wù)?？梢詫⑦@種風(fēng)格細(xì)分為兩種：j基于層次消息總線的結(jié)構(gòu)風(fēng)格：消息總線是系統(tǒng)的連接器，負(fù)責(zé)消息的分派、傳遞和過濾以及處理結(jié)果的返

28、回。各個構(gòu)件掛接在消息總線上，向總線登記感興趣的消息類型，構(gòu)件根據(jù)需要發(fā)出消息，由消息總線負(fù)責(zé)把該消息分配到系統(tǒng)中所有對此消息感興趣的構(gòu)件，消息是構(gòu)件之間通訊的唯一方式。構(gòu)件接收到消息后，根據(jù)自身狀態(tài)對消息進行響應(yīng)，并通過總線返回處理結(jié)果。kC2風(fēng)格：C2構(gòu)架中的基本元素是構(gòu)件、連接器。每個構(gòu)件定義有一個頂端接口和一個底端接口，構(gòu)件通過這兩個接口連接到構(gòu)架中，這使得構(gòu)架中構(gòu)件的增加、刪除、重組更為簡單方便。每個連接器也定義有頂端接口和底端接口，但接口的數(shù)量與連接在其上的構(gòu)件和連接器的數(shù)量有關(guān)，這也有利于實現(xiàn)在運行時的動態(tài)綁定。構(gòu)件之間不存在直接的通信手段，構(gòu)架中各元素構(gòu)件、連接器之間的通信只有

29、通過連接器傳遞消息來實現(xiàn)。處于低層的構(gòu)件向高層的構(gòu)件發(fā)出服務(wù)請求消息，消息經(jīng)由連接器送到相應(yīng)的構(gòu)件。各種不同的SA風(fēng)格的設(shè)計均是基于不同類型的連接器20。文獻21中，連接器被劃分成8種類型：過程調(diào)用類型(Process Call)、事件類型(Event)、流類型(Stream)、分布者類型(Distributor)、數(shù)據(jù)接入類型(Data Access)、仲裁者類型(Arbitrator)、適配器類型(Adaptor)、聯(lián)接類型(Linkage)。文獻22中，非功能屬性(如保密性，服務(wù)質(zhì)量等)被認(rèn)為是連接器描述中的重要組成部分。1.4 軟件體系結(jié)構(gòu)描述語言1.4.1 軟件體系結(jié)構(gòu)描述語言概述S

30、A研究的主要成果表現(xiàn)為體系結(jié)構(gòu)描述語言(architecture description language,簡稱ADL)。從構(gòu)件組裝的角度來看，ADL可以視為對構(gòu)件描述語言(CDL)的進一步擴展。構(gòu)件描述語言的基本思想是將構(gòu)件看成是一個黑盒，通過描述構(gòu)件接口的語法和語義，使得復(fù)用者不必過多地涉及構(gòu)件代碼細(xì)節(jié)，就可以在構(gòu)件描述這一抽象層次之上進行構(gòu)件組裝。而ADL除了描述構(gòu)件接口的語法和語義之外，還負(fù)責(zé)描述：系統(tǒng)中包括的構(gòu)件和連接子以及它們之間的交互關(guān)系、構(gòu)件的非功能類性質(zhì)以及構(gòu)件間協(xié)議，從而為構(gòu)件組裝提供了更為有力的支持。體系結(jié)構(gòu)描述語言(ADL) 是為軟件系統(tǒng)的體系結(jié)構(gòu)提供具體的語法和概念框

31、架的一種形式化符號。迄今為止，研究者已經(jīng)從不同的角度出發(fā)，針對不同的目標(biāo)，提出了各種通用的和專用的ADL：1）Rapide2324：一種事件驅(qū)動的ADL，它以體系結(jié)構(gòu)定義作為開發(fā)框架，支持基于構(gòu)件的開發(fā)。該語言提供了建模、分析、仿真和代碼生成的能力，但是沒有將連接器顯式化為一階實體。2）Wright25：具有代表性的ADL之一。其主要特點是將通信順序進程26（Communicating Sequential Processes，簡稱CSP）用于不同風(fēng)格軟件體系結(jié)構(gòu)的描述，從而完成對體系結(jié)構(gòu)描述的某些形式化推理(包括相容性檢查和死鎖檢查等)。3）UniCon27：將一組預(yù)定義的連接器映射到具體實

32、現(xiàn)，從而提供了從模塊到可執(zhí)行代碼、從體系結(jié)構(gòu)設(shè)計生成應(yīng)用的可能性。但是目前它只支持一組已選定的連接器，存在一定的局限。4）Aesop28：支持精確的編碼并能夠定義一個新的體系結(jié)構(gòu)的風(fēng)格，然后通過加上某些約束和利用它們的所有性質(zhì)來使用這個風(fēng)格。5）xArch29：一種基于XML的ADL。它使用XML 定義了描述體系結(jié)構(gòu)的核心元素,可以作為其他更高級的基于XML的ADL的基礎(chǔ)。也可以用做體系結(jié)構(gòu)描述的交換機制。6）ACME30：支持ADL之間映射及工具集成的體系結(jié)構(gòu)互交換語言。其目標(biāo)是作為體系結(jié)構(gòu)設(shè)計的一個共同的互交換格式,將現(xiàn)有的各種ADL在這個框架下統(tǒng)一起來。1.4.2 Wright構(gòu)架描述語

33、言Wright ADL是基于CSP的形式化構(gòu)架描述語言。CSP26中使用的基本記號如下所示：1）進程（process）：使用一系列事件序列來表示一個進程實體，例如上文中提到的各個role、port均是一個進程。STOP是一個特殊進程，表示什么事都不做的進程。2）字母表（alphabet）：進程所能執(zhí)行的事件的總和；特殊事件：事件“Ö”代表進程成功結(jié)束。進程P的字母表表示為aP。3）前綴（prefix）：設(shè)有一事件為x，有一進程為P，則另一進程先執(zhí)行事件x，然后按照進程P的說明進行動作；用（xP）表示。4）非確定性選擇（non-deterministic choice）：進程A或者按照

34、P動作，或者按照Q動作，而這種選擇是進程自發(fā)做出的。用PÕQ表示。5）確定性選擇（deterministic choice）：進程A或者按照P動作，或者按照Q動作，而這種選擇是環(huán)境做出的。用PQ表示。6）通信（communication）：使用二元對c.v來描述的一個事件，c是發(fā)生通信的通道（channel）的名字，v是通道傳遞的消息（message）。使用“？”表示接受消息，“！”表示發(fā)送消息。7）屏蔽（concealment）：設(shè)C是進程P需要屏蔽掉的事件的集合，用PC表示，它代表了一個似P動作的進程，只是在C中的任何事件的發(fā)生都被屏蔽掉了。8）并發(fā)（parallel）：進程P和

35、Q的并發(fā)表示為P|Q，它代表P，Q字母表中共有的事件需要同步執(zhí)行，非共有事件不需要同步。9）進程標(biāo)記（process labeling）：標(biāo)記為l的進程P表示為l:P。則進程中所有的事件也標(biāo)記上與其所屬進程相同的名字。在進程表達式中的優(yōu)先級高于，Õ，|操作符。所以efP|gQ=（efP）|（gQ）。對于其他操作符，未定義顯示的優(yōu)先級，所以在使用時用括號來確定優(yōu)先級。有了CSP的基本記號，我們就可以對客觀事物描述其動態(tài)行為，從而為推理、驗證事物行為提供了強有力的工具。如圖1.3所示，Wright ADL描述的軟件體系結(jié)構(gòu)一共由三部分組成：1）構(gòu)件及連接器類型定義：構(gòu)件類型由一組端口（p

36、ort）描述和構(gòu)件功能描述組成，每一個端口是構(gòu)件與其他構(gòu)件交互的邏輯單位；連接器類型由一組角色（role）和一個粘接器組成，角色描述了連接器所期待構(gòu)件的行為，粘接器描述了各角色行為之間的同步。圖1.3 Wright構(gòu)架描述語言2）一組構(gòu)件和連接器的實例定義。3）構(gòu)件實例與連接器實例間交互定義，將構(gòu)件實例的端口綁定到連接器實例的角色上，從而完成構(gòu)件間的交互。圖1.4 倉庫風(fēng)格的Wright ADL描述圖1.5 管道過濾器風(fēng)格的Wright ADL描述Wright ADL可以用來描述各種軟件體系風(fēng)格的軟件構(gòu)架。如圖1.4所示的倉庫風(fēng)格，圖1.5所示的管道過濾器風(fēng)格。1.5 相關(guān)工作配置管理中的版本

37、管理模型一直是軟件工程界研究的熱點。在31中提出了版本管理模型的基本概念：軟件對象、版本圖、系統(tǒng)創(chuàng)建、基于AND/OR圖的版本選擇，并試圖統(tǒng)一版本模型術(shù)語。之后版本模型不僅僅支持保存單文件的版本，而且支持創(chuàng)建一致性的配置32。隨著不同版本模型的不斷出現(xiàn)，12中根據(jù)版本模型概念集將版本管理模型分為四類：檢入/檢出模型、組合模型、長事務(wù)模型、變更集模型，但是這四種分類結(jié)果并不是正交的，一般的版本模型包含一個或多個以上的模型。在33中將版本管理模型分為以下幾個方面：版本集的組織、動態(tài)配置機制、層次組合、版本族機制、變更傳播、對象共享。但這些版本管理模型缺乏一個高層視圖的支持，雖然在版本模型中可以用戶

38、自定義配置，但所有的配置按照何種規(guī)格以及以何種規(guī)則進行組織在這些版本模型中都沒有討論。隨著軟件工程技術(shù)的不斷發(fā)展，新技術(shù)不斷的涌現(xiàn)，人們將配置管理技術(shù)同其他技術(shù)結(jié)合，從而發(fā)展出新的版本管理模型。軟件過程建模技術(shù)343536同傳統(tǒng)版本管理模型結(jié)合產(chǎn)生支持過程建模的版本管理模型3738，該版本模型中定義的產(chǎn)品空間被擴展用以包含過程建模，同時須對產(chǎn)品空間與過程建模間的交互進行設(shè)計。將基于構(gòu)件的軟件開發(fā)技術(shù)同傳統(tǒng)的版本管理模型結(jié)合，發(fā)展為基于構(gòu)件的軟件版本管理模型3940。但當(dāng)前的基于構(gòu)件的版本管理模型主要關(guān)心的是原代碼模塊間的依賴關(guān)系，缺乏管理軟件對象間關(guān)系的能力。同時基于構(gòu)件的開發(fā)沒有在一個軟件構(gòu)

39、架的支持下進行。1.5 存在的問題隨著CBSE的發(fā)展，當(dāng)前CBSE的版本管理模型中存在如下問題：未能與CBSE結(jié)合，對基于構(gòu)件開發(fā)的支持非常有限，很多系統(tǒng)只是簡單的將構(gòu)件作為一系列文件的集合，而對于構(gòu)件擁有的語義、構(gòu)件間的依賴關(guān)系、構(gòu)件中各組成部分的依賴關(guān)系的定義非常不足，未有支持SA的版本管理模型；在粒度管理方面只是通過簡單的組合來創(chuàng)建一個版本管理的粒度，未能按照用戶的自定義來定制版本管理的粒度；未能將版本模型和數(shù)據(jù)模型分開，所有功能模塊交錯在一起。為此，本文提出一個分層的基于構(gòu)架的版本管理模型SAVM，在版本模型層上，同時支持面向狀態(tài)和面向變更的版本操作，以統(tǒng)一的方式對待所有的數(shù)據(jù)元素，從

40、而實現(xiàn)了一個通用的版本引擎；在版本引擎之上，將數(shù)據(jù)模型層分為兩個子層，一個子層實現(xiàn)數(shù)據(jù)元素及數(shù)據(jù)元素間關(guān)系的組合，一個子層負(fù)責(zé)基于軟件體系結(jié)構(gòu)的數(shù)據(jù)模型，使得版本管理模型能夠支持基于軟件體系結(jié)構(gòu)的開發(fā)。在數(shù)據(jù)模型層之上進行事務(wù)管理和過程管理，從而為軟件組織提供了并行開發(fā)的控制和支持軟件開發(fā)模型的支持。第二章 SAVM的體系結(jié)構(gòu)版本管理模型SAVM針對上面的這些問題提出了解決方法，它是一個主要實現(xiàn)了版本管理、數(shù)據(jù)管理、過程管理、并發(fā)控制以及支持基于軟件體系結(jié)構(gòu)面向構(gòu)件的軟件開發(fā)方法等功能，從而實現(xiàn)了比較全面的軟件版本管理模型。2.1 SAVM設(shè)計的基本要求作為一個基于軟件體系結(jié)構(gòu)的版本管理模型應(yīng)

41、該具備兩個方面的功能：1）通用版本管理模型所擁有的功能；2）支持基于軟件體系結(jié)構(gòu)的開發(fā)所擁有的功能。因此在設(shè)計該模型時，需對這兩方面功能的要求進行定義。2.1.1 基本要求根據(jù)§1.1.2節(jié)中對版本管理模型術(shù)語的一個分類，可以對SAVM所要滿足的要求定義如下：1）一般性要求：SAVM必須滿足版本空間和產(chǎn)品空間的基本要求。用戶可以在產(chǎn)品空間中自由的設(shè)定需進行版本管理的版本元素；也可以自由的設(shè)定版本元素的版本空間。從而為用戶提供一個足夠通用的版本引擎，使得用戶可以自定義的將其轉(zhuǎn)化為任何一種特定的版本模型。2）增量的選擇要求：在增量的選擇上，需要對存儲效率和執(zhí)行效率進行考量。由于這屬于物理

42、實現(xiàn)層面上，因此SAVM版本模型不對此進行設(shè)計。3）版本演化的要求：版本的演化應(yīng)該同時支持分支和修訂，而且分支和修訂對于不同粒度的版本元素應(yīng)該按照一個統(tǒng)一的方式進行，即在版本空間中，應(yīng)該統(tǒng)一對待所有的數(shù)據(jù)元素。4）版本描述的要求：需要同時支持面向狀態(tài)和面向變更的版本管理方式。面向狀態(tài)和面向變更這兩種方式間應(yīng)該是正交的，即它們之間不存在互相的關(guān)系。5）版本空間表示的要求：對于面向變更的版本管理適用于使用n維網(wǎng)格進行表示，而面向狀態(tài)的版本管理適合使用版本圖來進行描述，因此需要將這兩種描述方式有機的結(jié)合在一起。6）版本集定義的要求：面向狀態(tài)的版本管理自然的支持外延版本，而面向變更的版本管理自然的支持

43、內(nèi)延版本；但面向狀態(tài)的版本管理應(yīng)該同時能支持內(nèi)延版本，而面向變更的版本管理也能支持外延版本。7）版本規(guī)則的要求：對于內(nèi)延版本而言，需要有版本規(guī)則的支持。而對于外延版本而言，使用版本規(guī)則可以定義基線、配置等概念。8）選擇粒度的要求：版本模型應(yīng)該能夠提供產(chǎn)品、各組成成分的選擇粒度，以滿足用戶在不同時刻的不同要求。9）工作區(qū)管理的要求：工作區(qū)應(yīng)該同外部工具版本在一起，從而實現(xiàn)版本模型與工具間的集成。2.1.2 基于SA的要求SAVM是支持基于軟件體系結(jié)構(gòu)開發(fā)的版本管理模型，因此在版本模型中需要對SA的基本概念提供支持，并且支持基于構(gòu)件的軟件開發(fā)方法。版本模型應(yīng)滿足的要求如下：1）支持構(gòu)件定義：構(gòu)件包

44、括構(gòu)件接口和構(gòu)件實體兩部分。同時構(gòu)件接口同構(gòu)件實體間存在著互相依賴關(guān)系，一方的改變可能導(dǎo)致另一方的改變。而且構(gòu)件接口中應(yīng)該包含語義信息用以描述構(gòu)件的行為，接口類型可以根據(jù)SA風(fēng)格的不同而不同。構(gòu)件實體可以是一組相關(guān)的目錄、文件，文件間存在著依賴關(guān)系、包含關(guān)系等多種關(guān)系。2）支持連接器定義：連接器包括角色和粘接器兩部分組成。連接器作為構(gòu)件實體間的連接代理，連接器的角色和構(gòu)件的端口應(yīng)該滿足相容的關(guān)系25。角色和端口都應(yīng)該包含語義信息。3）支持SA定義：SA由構(gòu)件、連接器以及它們之間的連接關(guān)系組成。版本管理模型不僅需要將構(gòu)件、連接器作為實體來對待，而且需要將連接關(guān)系作為實體來看待。SA是版本管理模型

45、中的最大粒度，用戶可以根據(jù)不同的需求按照各種不同的粒度來查看整個SA。這里不僅需要設(shè)計構(gòu)件、連接器、SA版本演化規(guī)則，而且需對它們之間在演化過程中的相互影響進行定義。4）支持基于軟件體系結(jié)構(gòu)的軟件開發(fā)方法：17中提出了一個基于體系結(jié)構(gòu)、面向構(gòu)件的軟件開發(fā)方法，方法中定義了一個開發(fā)的流程。版本管理模型中需要設(shè)計一個新型的過程管理定義語言對所有通用的軟件開發(fā)模型進行定義，從而支持基于構(gòu)件的軟件開發(fā)的過程管理。5）支持基于軟件體系結(jié)構(gòu)的并行開發(fā)：當(dāng)前的軟件開發(fā)的規(guī)模已經(jīng)不是僅僅靠一個人就能完成的了的，需要一個團隊合作完成。版本管理模型需要提供并發(fā)控制機制和用戶權(quán)限管理功能。以上SA中的所有元素將通過

46、Wright描述語言定義，版本模型應(yīng)該提供將描述語言自動的轉(zhuǎn)化為適合版本管理模型管理的實體的能力，同時不應(yīng)丟失語言中描述的任何信息。2.2 SAVM結(jié)構(gòu)設(shè)計根據(jù)§2.1節(jié)中定義的SAVM的基本要求，我們可以看到SAVM版本管理模型涉及版本空間、產(chǎn)品空間和過程管理。首先遇到的問題是如何將版本空間、產(chǎn)品空間、過程管理這些概念有機的組合在一起來提供一個高效、通用的版本管理模型。我們可以正交的對待版本、產(chǎn)品和過程，從而實現(xiàn)一個分層的版本管理模型。這樣有利于對版本模型的修改和擴展，當(dāng)發(fā)生修改時也可以使修改范圍定位的足夠??；同時當(dāng)版本模型需要進行擴展功能時，非常容易定位增加功能所處的層次，只需擴

47、展該層就可實現(xiàn)整體功能的擴展。為決定一個系統(tǒng)的構(gòu)架，并按分層的方式把以上三個概念組合起來，SAVM版本模型必須對以下幾個問題做出決定：1）數(shù)據(jù)模型和版本模型之間的關(guān)系這決定了產(chǎn)品空間與版本空間之間的關(guān)系，數(shù)據(jù)模型定義了產(chǎn)品數(shù)據(jù)的基本概念（如構(gòu)架、構(gòu)件、簡單文件）。版本模型定義了版本標(biāo)識及其組織，同時還定義了查詢和創(chuàng)建一個新版本的操作等等。數(shù)據(jù)模型和版本模型的關(guān)系可以有以下幾種方式：j版本模型位于數(shù)據(jù)模型之上；k版本模型和數(shù)據(jù)模型結(jié)合在一起；l數(shù)據(jù)模型位于版本模型之上。SAVM版本模型是一個層次模型，因此應(yīng)該將版本模型和數(shù)據(jù)模型分開放置在不同的層。同時根據(jù)用戶可以選擇不同粒度的版本，因此數(shù)據(jù)模型

48、應(yīng)該位于版本模型之上。2）選擇一個增量表示 增量可以分為三類：直接增量、內(nèi)嵌增量、選擇增量。作為一個物理層面上的是實現(xiàn)，應(yīng)當(dāng)考慮存儲效率和執(zhí)行效率問題。SAVM只是一個基于軟件體系結(jié)構(gòu)的版本管理模型原型，因此不對增量存儲進行定義。3）定義基本的版本概念 版本模型中需要定義一個基本的概念，高層的其它概念必須可以通過這個基本的概念組合而成。為使版本模型足夠的通用，所有在版本模型中的元素都是原子的，稱之為片段（fragment）。片段之間可以在數(shù)據(jù)模型層組合形成數(shù)據(jù)元素，而對片段的管理是既允許進行面向狀態(tài)的版本管理也允許面向變更的版本管理。4）外延版本和內(nèi)延版本的關(guān)系大部分面向狀態(tài)的版本管理具有外延

49、版本的特點；而大部分面向變更的版本管理具有內(nèi)延版本的特點。內(nèi)延版本和外延版本的關(guān)系可以分為三種：j內(nèi)延版本位于外延版本之上；k外延版本位于內(nèi)延版本之上；l外延版本正交與內(nèi)延版本。為滿足通用型，用戶可以選擇面向狀態(tài)的版本管理也可以選擇面向變更的版本管理，或者兼而有之。因此SAVM提供外延版本與外延版本正交。5）定義數(shù)據(jù)模型基本對象集數(shù)據(jù)模型中需要定義一個基本概念集，同時允許擴充該概念集。例如在軟件對象的生命周期中，軟件對象如需求定義、設(shè)計、構(gòu)件、文檔、測試數(shù)據(jù)等等均可定義為基本概念。其它概念必須可以通過這個基本的概念組合而成，例如構(gòu)架就由構(gòu)件和連接器組合而成。數(shù)據(jù)模型中的所有元素均可由版本模型中

50、的片段組成。對數(shù)據(jù)模型層進行分解：底層為基于ER模型的數(shù)據(jù)模型，定義所有的數(shù)據(jù)元素；高層為基于SA的數(shù)據(jù)模型。6）定義并發(fā)控制 SAVM中通過事務(wù)管理來進行并發(fā)控制，定義了一系列的基本變更傳播規(guī)則來控制不同用戶間的一致性工作，同時針對每種數(shù)據(jù)類型可以增加特有的傳播規(guī)則。SAVM沒有采用鎖機制，因此不會產(chǎn)生死鎖或者特定版本被鎖定（除非用戶自己鎖定）。當(dāng)發(fā)生沖突時，SAVM可以選擇多種解決方式進行沖突解決。7）定義過程管理模式過程管理不僅支持基于軟件體系結(jié)構(gòu)的過程模型，同時還應(yīng)該支持允許用戶自定義過程模型。SAVM中提供一個過程管理模式，將過程模型中的一系列階段和活動使用過程模式進行分解，將每一特

51、定的階段同相關(guān)的軟件產(chǎn)品關(guān)聯(lián)，以活動來驅(qū)動整個軟件過程的執(zhí)行。根據(jù)以上的決定，可以得出SAVM的分層版本管理模型的總體結(jié)構(gòu)，如圖2.1所示：這些層可以整合成兩大類，即版本引擎和版本管理倉庫。1）版本引擎版本引擎提供基本的版本功能而不包含任何的產(chǎn)品空間。這僅僅假定版本元素的元素標(biāo)識是由數(shù)據(jù)模型層提供。版本模型與數(shù)據(jù)模型正交，這意味著版本引擎可以應(yīng)用于任何數(shù)據(jù)模型。對于一個對象元素，都有一組不同的片段，每個片段都包含一個對象標(biāo)識和一個可見性（visibility）。對象標(biāo)識表明該片斷所屬的對象元素；可見性即數(shù)據(jù)元素的版本標(biāo)識，是一個由選項（option）組成的邏輯表達式，每個選項的值可以是TRUE

52、，F(xiàn)ALSE，UNSET。全部選項組成了一個面向變更的版本空間。在每一個可見性下，都存在一個面向狀態(tài)的版本空間。因此版本引擎既提供了面向變更的版本管理也可以提供面向狀態(tài)的版本管理。圖2.1 SAVM分層版本管理模型版本模型由面向變更的版本模型和面向狀態(tài)的版本模型組成。面向變更的版本模型和面向狀態(tài)的版本模型有機的結(jié)合在一起，統(tǒng)一的定義了修訂、分支、版本圖和網(wǎng)格、外延版本和內(nèi)延版本等版本模型中的基本術(shù)語。2）版本管理倉庫在版本引擎之上，版本管理倉庫提供了數(shù)據(jù)模型層、事務(wù)模型層、過程模型層。數(shù)據(jù)模型層由兩個子層組成：（1）基于ER模型的數(shù)據(jù)模型；（2）基于SA的數(shù)據(jù)模型。基于ER模型的數(shù)據(jù)模型負(fù)責(zé)提

53、供基本的數(shù)據(jù)模型給它以上的各層，同時屏蔽它以下的各層。在這一層上，客戶端完成查詢和更新操作，但他卻感受不到數(shù)據(jù)元素是經(jīng)過版本標(biāo)識的?；赟A的數(shù)據(jù)模型負(fù)責(zé)提供軟件體系結(jié)構(gòu)及其語義信息。事務(wù)層提供了協(xié)作、并發(fā)控制、長事務(wù)模型，所有的軟件開發(fā)或維護的活動都包含在某一個事務(wù)中。每一個事務(wù)被限制在產(chǎn)品空間和版本空間的子集上。過程模型負(fù)責(zé)定義用戶開發(fā)的一個過程。工作區(qū)支持則為用戶的操作提供接口。SAVM版本管理倉庫由兩個部分組成：一個是用于保存片段集的內(nèi)容數(shù)據(jù)庫，一個是包含選項定義、全局版本規(guī)則、版本圖的元數(shù)據(jù)庫。元數(shù)據(jù)庫包括兩個部分：j選項定義：選項可以表示一個變更、一個特定的屬性等等。n個選項可以組

54、成一個n維的網(wǎng)格。選項使用名字進行過行標(biāo)識，例如：GUI：設(shè)置成TRUE表示程序版本有一個圖形的用戶界面；Linux：設(shè)置成TRUE表示程序版本運行在Linux操作系統(tǒng)上；SpeedOpt：表示版本是否經(jīng)過優(yōu)化。k全局版本規(guī)則：根據(jù)選項的取值，可得n個選項可有3n種組合，但只有其中一些可以認(rèn)為是合法的。為了管理這些復(fù)雜的版本選擇，我們需要一個全局的版本規(guī)則庫。而且，可以將用戶描述的高層版本描述（基于用戶自身偏好）會自動轉(zhuǎn)化為低層的版本描述（基于選項的描述）。全局版本規(guī)則可以分為五類：一般性約束：定義了選項間的依賴關(guān)系，即只有當(dāng)某一選項設(shè)置為TRUE時，另一選項才能進行設(shè)置。選項族：族內(nèi)的選項必

55、須互斥，即族內(nèi)之多一個選項的值可以設(shè)置為TRUE。合法性檢查：有效性表達了某些版本是被鎖定的，從而有效的支持了基線的存在。偏愛：允許用戶設(shè)定自己的偏好。默認(rèn)：用于解決二義性的選擇。l版本圖：每一個可見性下都對應(yīng)著一個面向狀態(tài)的版本空間。版本圖中保存著每個版本元素在相同可見性下的版本演化歷史。2.3 SAVM總結(jié)可以看出SAVM模型具有以下的優(yōu)點：1）是在統(tǒng)一的框架中定義的版本模型，因此SAVM模型可以使不同版本模型之間的比較更加容易；2）SAVM是建立在少量基本概念之上，通過這些基本的概念可以表述各種類型的版本模型；3）版本引擎作為一個可復(fù)用的核心構(gòu)件來構(gòu)建版本管理模型；4）統(tǒng)一版本模型的一個

56、重要特點就是版本模型和數(shù)據(jù)模型正交；數(shù)據(jù)模型用于代表軟件元素和他們之間的關(guān)系；5）版本引擎支持基于規(guī)則的軟件配置項的創(chuàng)建。6）非常方便的進行擴展，支持基于軟件體系結(jié)構(gòu)的開發(fā)以及過程管理。SAVM的總體結(jié)構(gòu)中應(yīng)該實現(xiàn)以下幾個方面的功能：1）類型和結(jié)構(gòu)SAVM基本功能就是提供存儲和管理配置的能力。構(gòu)件可以是任何類型的軟件對象，例如：源文件、對象文件，設(shè)計文檔、測試用例。SAVM必須提供一個通用的類型系統(tǒng)，這樣子才可以對不同的構(gòu)件進行區(qū)分并能完成：j控制配置的組合；k對某種類型的對象嵌入一些語義知識；l對于不同類型的對象使用不同的語義和管理規(guī)則；m類型系統(tǒng)應(yīng)該可以擴展，以便加入用戶定義的類型和描述。

57、同時應(yīng)該提供某種方式來將構(gòu)件組合成更大的結(jié)構(gòu)。2）持久性數(shù)據(jù)需要持久的存儲以便進行管理。3）構(gòu)件標(biāo)識j對象標(biāo)識（OID）是由系統(tǒng)提供的，唯一且不變的鍵值。該標(biāo)識獨立于對象的其他屬性。k對象標(biāo)識是SAVM的基本要求。但同時還存在面向值系統(tǒng)，在這種模型中，對象通過值來進行標(biāo)識，而該值既不唯一也不恒不變。4）變更控制軟件配置不是一個靜態(tài)元素；變更會貫穿其整個生命周期，不僅僅在初期的開發(fā)階段，更重要的是在后期的維護和再開發(fā)。SAVM一個很重要方面是管理這樣的變更。它包括兩個方面：記錄執(zhí)行的變更和執(zhí)行變更。j變更記錄與傳統(tǒng)的數(shù)據(jù)庫不同，變更記錄不僅僅是執(zhí)行這些變更那么簡單。在SCM中，每一個數(shù)據(jù)元素不僅僅只有一個版本，但一個變更被執(zhí)行時，我們不是去完全替換老版本，而是同時保存未變更和變更的版本。這樣子就可以方便的取回先前的版本。k變更處理過程控制變更的處理過程，它至少包括以下幾個方面：生成一個變更請求；存儲變更請求并對其進行作用：將正式的變更請求記錄到數(shù)據(jù)庫中，并尋找出受該變更影響的構(gòu)件及相應(yīng)的負(fù)責(zé)人；處理變更請求的規(guī)則依賴于當(dāng)前產(chǎn)品的狀態(tài)：產(chǎn)品在生命周期的所處的階段及