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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

26、能，而且定義了其要求的外部功能，從而顯式地表達(dá)了構(gòu)件對(duì)環(huán)境的依賴，提高了構(gòu)件接口規(guī)約的表達(dá)能力。構(gòu)件的接口定義了所有對(duì)外交互的信息，構(gòu)件在實(shí)現(xiàn)時(shí)不是直接使用其他構(gòu)件提供的功能，而是使用它在接口處定義的對(duì)外要求的功能。構(gòu)件之間的連接是在所要求的功能和所提供的功能之間進(jìn)行匹配，因此，通過接口就可以定義系統(tǒng)中構(gòu)件之間的所有連接。l插頭插座式體系風(fēng)格：當(dāng)接口定義的功能數(shù)量很大時(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) ”的方式來實(shí)現(xiàn)的，每個(gè)部件提供若干進(jìn)程及它感興趣的事件，并把每個(gè)事件與一個(gè)過程聯(lián)系在一起，當(dāng)某個(gè)部件產(chǎn)生一個(gè)事件時(shí)，若其它部件定義了這個(gè)事件，那么與該事件聯(lián)系在一起的過程將被自動(dòng)調(diào)用，從而間接地完成了過程的調(diào)用。4）分層系統(tǒng)風(fēng)格 一個(gè)分層系統(tǒng)就是把整個(gè)系統(tǒng)組織成層次結(jié)構(gòu)，每一層都提供若干服務(wù)給上一層使用，并且它也使用其下一層所提供的服務(wù)?？梢詫⑦@種風(fēng)格細(xì)分為兩種：j基于層次消息總線的結(jié)構(gòu)風(fēng)格：消息總線是系統(tǒng)的連接器，負(fù)責(zé)消息的分派、傳遞和過濾以及處理結(jié)果的返

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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