第2章軟件體系結(jié)構(gòu)2.1軟件體系結(jié)構(gòu)的產(chǎn)生與發(fā)展2.2軟件體系結(jié)構(gòu)建模2.3基于體系結(jié)構(gòu)的描述2.4基于體系結(jié)構(gòu)的軟件設(shè)計2.5小結(jié)

2.1軟件體系結(jié)構(gòu)的產(chǎn)生與發(fā)展

20世紀(jì)60年代的軟件危機使得人們開始重視軟件工程的研究。起初，人們把軟件設(shè)計的重點放在數(shù)據(jù)結(jié)構(gòu)和算法的選擇上，隨著軟件系統(tǒng)規(guī)模越來越大、越來越復(fù)雜，整個系統(tǒng)的結(jié)構(gòu)和規(guī)格說明顯得越來越重要。軟件危機的程度日益加劇，現(xiàn)有的軟件工程方法對此顯得力不從心。對于大規(guī)模的復(fù)雜軟件系統(tǒng)來說，對總體的系統(tǒng)結(jié)構(gòu)設(shè)計和規(guī)格說明的選擇比起對計算的算法和數(shù)據(jù)結(jié)構(gòu)的選擇已經(jīng)變得明顯重要很多。在此背景下，人們認(rèn)識到軟件體系結(jié)構(gòu)的重要性，并認(rèn)為對軟件體系結(jié)構(gòu)的系統(tǒng)、深入的研究將會成為提高軟件生產(chǎn)率和解決軟件維護(hù)問題的新的最有希望的途徑。自從軟件系統(tǒng)首次被分成許多模塊，模塊之間有相互作用，組合起來有整體的屬性，軟件系統(tǒng)就具有了體系結(jié)構(gòu)。好的開發(fā)者常常會使用一些體系結(jié)構(gòu)模式作為軟件系統(tǒng)結(jié)構(gòu)的設(shè)計策略，但他們并沒有規(guī)范地、明確地表達(dá)出來，這樣就無法將他們的知識與別人交流。軟件體系結(jié)構(gòu)是設(shè)計抽象的進(jìn)一步發(fā)展，滿足了更好地理解軟件系統(tǒng)，更方便地開發(fā)更大、更復(fù)雜的軟件系統(tǒng)的需要。

事實上，軟件總是有體系結(jié)構(gòu)的，不存在沒有體系結(jié)構(gòu)的軟件。體系結(jié)構(gòu)(Architecture)一詞在英文里就是“建筑”的意思。把軟件比作一座樓房，從整體上講，是因為它有基礎(chǔ)、主體和裝飾，即操作系統(tǒng)之上的基礎(chǔ)設(shè)施軟件、實現(xiàn)計算邏輯的主體應(yīng)用程序、方便使用的用戶界面程序。從細(xì)節(jié)上來看每一個程序也是有結(jié)構(gòu)的，早期的結(jié)構(gòu)化程序就是以語句組成模塊，模塊的聚集和嵌套形成層層調(diào)用的程序結(jié)構(gòu)，也就是它的體系結(jié)構(gòu)。結(jié)構(gòu)化程序的程序(表達(dá))結(jié)構(gòu)和(計算的)邏輯結(jié)構(gòu)的一致性及自頂向下的開發(fā)方法自然而然地形成了體系結(jié)構(gòu)。由于在結(jié)構(gòu)化程序設(shè)計時代程序的規(guī)模不大，通過強調(diào)結(jié)構(gòu)化程序設(shè)計方法學(xué)，自頂向下、逐步求精，并注意模塊的耦合性就可以得到相對良好的結(jié)構(gòu)，所以并未去特別研究軟件體系結(jié)構(gòu)。我們可以作個簡單的比喻，結(jié)構(gòu)化程序設(shè)計時代是以磚、瓦、灰、沙、石、預(yù)制梁、柱、屋面板蓋平房和小樓，而面向?qū)ο髸r代以整面墻、整間房、一層樓梯的預(yù)制件蓋高樓大廈。構(gòu)件怎樣搭配才合理？體系結(jié)構(gòu)怎樣構(gòu)造容易？重要構(gòu)件有了更改后，如何保證整棟高樓不倒？每種應(yīng)用領(lǐng)域需要什么構(gòu)件(醫(yī)院、工廠、旅館)？有哪些實用、美觀、強度高、造價合理的構(gòu)件骨架使建造出來的建筑(即體系結(jié)構(gòu))更能滿足用戶的需求？如同土木工程進(jìn)入到現(xiàn)代建筑學(xué)一樣，軟件也從傳統(tǒng)的軟件工程進(jìn)入到現(xiàn)代面向?qū)ο蟮能浖こ?，研究整個軟件系統(tǒng)的體系結(jié)構(gòu)，尋求建構(gòu)最快、成本最低、質(zhì)量最好的構(gòu)造過程。軟件體系結(jié)構(gòu)雖脫胎于軟件工程，但其形成同時借鑒了計算機體系結(jié)構(gòu)和網(wǎng)絡(luò)體系結(jié)構(gòu)中很多寶貴的思想和方法。最近幾年軟件體系結(jié)構(gòu)研究已完全獨立于軟件工程的研究，成為計算機科學(xué)的一個最新的研究方向和獨立的學(xué)科分支。軟件體系結(jié)構(gòu)研究的主要內(nèi)容涉及軟件體系結(jié)構(gòu)描述、軟件體系結(jié)構(gòu)風(fēng)格、軟件體系結(jié)構(gòu)評價和軟件體系結(jié)構(gòu)的形式化方法等。解決好軟件的重用、質(zhì)量和維護(hù)問題，是研究軟件體系結(jié)構(gòu)的根本目的。2.1.1軟件體系結(jié)構(gòu)的定義

雖然軟件體系結(jié)構(gòu)已經(jīng)在軟件工程領(lǐng)域中有著廣泛的應(yīng)用，但迄今為止還沒有一個被大家所公認(rèn)的定義。許多專家學(xué)者從不同角度和不同側(cè)面對軟件體系結(jié)構(gòu)進(jìn)行了刻畫，較為典型的定義有：

(1)?DewaynePerry和AlexWolf曾這樣定義：軟件體系結(jié)構(gòu)是具有一定形式的結(jié)構(gòu)化元素，即構(gòu)件的集合，包括處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件。處理構(gòu)件負(fù)責(zé)對數(shù)據(jù)進(jìn)行加工，數(shù)據(jù)構(gòu)件是被加工的信息，連接構(gòu)件把體系結(jié)構(gòu)的不同部分組合連接起來。這一定義注重區(qū)分處理構(gòu)件、數(shù)據(jù)構(gòu)件和連接構(gòu)件，該特點在其他的定義和方法中基本上得到了保持。

(2)?MaryShaw和DavidGarlan認(rèn)為軟件體系結(jié)構(gòu)是軟件設(shè)計過程中的一個層次，這一層次超越計算過程中的算法設(shè)計和數(shù)據(jù)結(jié)構(gòu)設(shè)計。體系結(jié)構(gòu)問題包括總體組織和全局控制，通信協(xié)議，同步與數(shù)據(jù)存取，給設(shè)計元素分配特定功能，設(shè)計元素的組織、規(guī)模和性能，在各設(shè)計方案間進(jìn)行選擇等。軟件體系結(jié)構(gòu)處理算法與數(shù)據(jù)結(jié)構(gòu)之上關(guān)于整體系統(tǒng)結(jié)構(gòu)設(shè)計和描述方面的一些問題，包括全局組織和全局控制結(jié)構(gòu)，關(guān)于通信、同步與數(shù)據(jù)存取的協(xié)議，設(shè)計構(gòu)件功能定義，物理分布與合成，設(shè)計方案的選擇、評估與實現(xiàn)等。

(3)?Kruchten指出，軟件體系結(jié)構(gòu)有四個角度，它們從不同方面對系統(tǒng)進(jìn)行描述：概念角度描述系統(tǒng)的主要構(gòu)件及它們之間的關(guān)系；模塊角度包含功能分解與層次結(jié)構(gòu)；運行角度描述了一個系統(tǒng)的動態(tài)結(jié)構(gòu)；代碼角度描述了各種代碼和庫函數(shù)在開發(fā)環(huán)境中的組織。

(4)?HayesRoth則認(rèn)為軟件體系結(jié)構(gòu)是一個抽象的系統(tǒng)規(guī)范，主要包括用其行為來描述的功能構(gòu)件和構(gòu)件之間的相互連接、接口和關(guān)系。

(5)?DavidGarlan和DewnePerry于1995年在IEEE軟件工程學(xué)報上又發(fā)表了如下定義：軟件體系結(jié)構(gòu)是一個程序/系統(tǒng)各構(gòu)件的結(jié)構(gòu)及其相互關(guān)系，以及進(jìn)行設(shè)計的原則和隨時間進(jìn)化的指導(dǎo)方針。

(6)?BarryBoehm和他的學(xué)生提出，一個軟件體系結(jié)構(gòu)包括一個軟件和系統(tǒng)構(gòu)件、互聯(lián)及約束的集合、一個系統(tǒng)需求說明的集合以及一個基本原理，用以說明這一構(gòu)件、互聯(lián)和約束能夠滿足系統(tǒng)需求。

(7)1997年，Bass、Ctements和Kazman在《使用軟件體系結(jié)構(gòu)》一書中給出如下定義：一個程序或計算機系統(tǒng)的軟件體系結(jié)構(gòu)包括一個或一組軟件構(gòu)件、軟件構(gòu)件外部的可見特性及其相互關(guān)系。其中，“軟件外部的可見特性”是指軟件構(gòu)件提供的服務(wù)、性能、特性、錯誤處理、共享資源使用等。綜上所述，軟件體系結(jié)構(gòu)為軟件系統(tǒng)提供了一個結(jié)構(gòu)、行為和屬性的高級抽象，由構(gòu)成系統(tǒng)的元素的描述、這些元素的相互作用、指導(dǎo)元素集成的模式以及這些模式的約束組成。軟件體系結(jié)構(gòu)不僅指定了系統(tǒng)的組織結(jié)構(gòu)和拓?fù)浣Y(jié)構(gòu)，而且顯示了系統(tǒng)需求和構(gòu)成元素之間的對應(yīng)關(guān)系，提供了一些設(shè)計決策的基本原理。2.1.2軟件體系結(jié)構(gòu)的發(fā)展史

在軟件系統(tǒng)的規(guī)模迅速增大的同時，軟件開發(fā)方法也經(jīng)歷了一系列的變革。在此過程中，軟件體系結(jié)構(gòu)也由最初模糊的概念發(fā)展成為漸趨成熟的理論和技術(shù)。

20世紀(jì)70年代以前，尤其是在以ALGOL68為代表的高級語言出現(xiàn)以前，軟件開發(fā)基本上都是匯編程序設(shè)計，此階段系統(tǒng)規(guī)模較小，很少明確考慮系統(tǒng)結(jié)構(gòu)，一般不存在系統(tǒng)建模工作。70年代中后期，由于結(jié)構(gòu)化開發(fā)方法的出現(xiàn)與廣泛應(yīng)用，軟件開發(fā)中出現(xiàn)了概要設(shè)計與詳細(xì)設(shè)計，而且主要任務(wù)是數(shù)據(jù)流設(shè)計與控制流設(shè)計，因此，此時軟件結(jié)構(gòu)已作為一個明確的概念出現(xiàn)在系統(tǒng)的開發(fā)中。

20世紀(jì)80年代初到90年代中期，是面向?qū)ο箝_發(fā)方法興起與成熟的階段。由于對象是數(shù)據(jù)與基于數(shù)據(jù)之上操作的封裝，因而在面向?qū)ο箝_發(fā)方法下，數(shù)據(jù)流設(shè)計與控制流設(shè)計則統(tǒng)一為對象建模。同時，面向?qū)ο蠓椒ㄟ€提出了一些其他的結(jié)構(gòu)視圖，如在OMT(ObjectModelingTechnology，對象建模技術(shù))方法中提出了功能視圖、對象視圖與動態(tài)視圖(包括狀態(tài)圖和事件追蹤圖)；在Booch方法中則提出了類視圖、對象視圖、狀態(tài)遷移圖、交互作用圖、模塊圖、進(jìn)程圖；而1997年出現(xiàn)的統(tǒng)一建模語言(UML)則用功能模型(用例視圖)、靜態(tài)模型(包括類圖、對象圖、構(gòu)件圖、包圖)、動態(tài)模型(協(xié)作圖、順序圖、狀態(tài)圖和活動圖)、配置模型(配置圖)描述應(yīng)用系統(tǒng)的結(jié)構(gòu)。

20世紀(jì)90年代以后則進(jìn)入基于構(gòu)件的軟件開發(fā)階段，該階段以過程為中心，強調(diào)軟件開發(fā)采用構(gòu)件化技術(shù)和體系結(jié)構(gòu)技術(shù)，要求開發(fā)出的軟件具備很強的自適應(yīng)性、互操作性、可擴展性和可重用性。此階段中，軟件體系結(jié)構(gòu)已經(jīng)作為一個明確的文檔和中間產(chǎn)品存在于軟件開發(fā)過程中；同時，軟件體系結(jié)構(gòu)作為一門學(xué)科逐漸得到人們的重視，并成為軟件工程領(lǐng)域的研究熱點。因而Perry和Wolf認(rèn)為：未來的年代將是研究軟件體系結(jié)構(gòu)的時代。

縱觀軟件體系結(jié)構(gòu)技術(shù)的發(fā)展過程，從最初的“無體系結(jié)構(gòu)”設(shè)計到現(xiàn)行的基于體系結(jié)構(gòu)的軟件開發(fā)，可以認(rèn)為經(jīng)歷了四個階段：

(1)“無體系結(jié)構(gòu)”設(shè)計階段，以匯編語言進(jìn)行小規(guī)模應(yīng)用程序開發(fā)為特征。

(2)萌芽階段，出現(xiàn)了程序結(jié)構(gòu)設(shè)計主題，以控制流圖和數(shù)據(jù)流圖構(gòu)成軟件結(jié)構(gòu)為特征。

(3)初期階段，出現(xiàn)了從不同側(cè)面描述系統(tǒng)的結(jié)構(gòu)模型，以UML為典型代表。

(4)高級階段，以描述系統(tǒng)的高層抽象結(jié)構(gòu)為中心，不關(guān)心具體的建模細(xì)節(jié)，劃分了體系結(jié)構(gòu)模型與傳統(tǒng)軟件結(jié)構(gòu)的界限，該階段以Kruchten提出的“4+1”模型為標(biāo)志。由于概念尚不統(tǒng)一，描述規(guī)范也不能達(dá)成一致認(rèn)識，在軟件開發(fā)實踐中軟件體系結(jié)構(gòu)尚不能發(fā)揮重要作用。2.1.3軟件體系結(jié)構(gòu)的研究現(xiàn)狀

(1)形成研究熱點，仍處于非形式化水平。自20世紀(jì)90年代后期以來，軟件體系結(jié)構(gòu)的研究成為一個熱點。廣大軟件工作者已經(jīng)認(rèn)識到軟件體系結(jié)構(gòu)研究的重大意義和它對軟件系統(tǒng)設(shè)計開發(fā)的重要性，開展了很多研究和實踐工作。

從軟件體系結(jié)構(gòu)研究的現(xiàn)狀來看，當(dāng)前的研究和對軟件體系結(jié)構(gòu)的描述，在很大程度上來說還停留在非形式化的基礎(chǔ)上。軟件構(gòu)架師仍然缺乏必要的工具，這種工具應(yīng)該是顯式描述、有獨立性的形式化工具。在目前通用的軟件開發(fā)方法中，對軟件體系結(jié)構(gòu)的描述通常采用非形式化的圖和文本，不能描述存在于構(gòu)件之間的接口，更不能描述不同的系統(tǒng)組成成分間的組合關(guān)系。這種描述方法難以被開發(fā)人員理解，不能用來分析其一致性和完整性等特性。

當(dāng)一個軟件系統(tǒng)中的構(gòu)件幾乎以一種非形式化的方法描述時，系統(tǒng)的重用性也會受到影響，在設(shè)計一個系統(tǒng)結(jié)構(gòu)過程中的努力很難移植到另一個系統(tǒng)中去。對系統(tǒng)構(gòu)件和連接關(guān)系的結(jié)構(gòu)化假設(shè)沒有得到顯式的、形式化的描述時，把這樣的系統(tǒng)構(gòu)件移植到另一個系統(tǒng)中去將是有風(fēng)險的，甚至是不可能的。

(2)軟件體系結(jié)構(gòu)的形式化方法研究。軟件體系結(jié)構(gòu)研究如果僅僅停留在非形式化的框圖階段，已經(jīng)難以適應(yīng)進(jìn)一步發(fā)展的需要。為支持基于體系結(jié)構(gòu)的開發(fā)，需要有形式化建模符號、體系結(jié)構(gòu)說明的分析與開發(fā)工具。從軟件體系結(jié)構(gòu)研究的現(xiàn)狀來看，在這一領(lǐng)域近來已經(jīng)有不少進(jìn)展，其中比較有代表性的是美國卡耐基梅隆大學(xué)(CarnegieMellonUniversity)的RobertJ.?Allen于1997年提出的Wright系統(tǒng)。Wright是一種結(jié)構(gòu)描述語言，該語言基于一種形式化的、抽象的系統(tǒng)模型，為描述和分析軟件體系結(jié)構(gòu)和結(jié)構(gòu)化方法提供了一種實用的工具。Wright主要側(cè)重于描述系統(tǒng)的軟件構(gòu)件和連接的結(jié)構(gòu)、配置和方法，它使用顯式的、獨立的連接模型來作為交互的方式，這使得該系統(tǒng)可以用邏輯謂詞符號系統(tǒng)，而不依賴特定的系統(tǒng)實例來描述系統(tǒng)的抽象行為。該系統(tǒng)還可以通過一組靜態(tài)檢查來判斷系統(tǒng)結(jié)構(gòu)規(guī)格說明的一致性和完整性。從這些特性的分析來說，Wright系統(tǒng)的確適用于對大型系統(tǒng)的描述和分析。

(3)軟件體系結(jié)構(gòu)的建模研究。研究軟件體系結(jié)構(gòu)的首要問題是如何表示軟件體系結(jié)構(gòu)，即如何對軟件體系結(jié)構(gòu)建模。根據(jù)建模的側(cè)重點的不同，可以將軟件體系結(jié)構(gòu)的模型分為5種：結(jié)構(gòu)模型、框架模型、動態(tài)模型、過程模型和功能模型。在這5種模型中，最常用的是結(jié)構(gòu)模型和動態(tài)模型。這一問題將在后續(xù)章節(jié)中進(jìn)一步詳細(xì)闡述。

(4)發(fā)展基于體系結(jié)構(gòu)的軟件開發(fā)模型。軟件開發(fā)模型是跨越整個軟件生存周期的系統(tǒng)開發(fā)、運行、維護(hù)所實施的全部工作和任務(wù)的結(jié)構(gòu)框架，給出了軟件開發(fā)活動各階段之間的關(guān)系。目前，常見的軟件開發(fā)模型大致可分為以下三種類型：

①以軟件需求完全確定為前提的瀑布模型。

②在軟件開發(fā)初始階段只能提供基本需求時采用的漸進(jìn)式開發(fā)模型，如螺旋模型等。

③以形式化開發(fā)方法為基礎(chǔ)的變換模型。所有開發(fā)方法都是要解決需求與實現(xiàn)之間的差距，但是，這三種類型的軟件開發(fā)模型都存在這樣或那樣的缺陷，不能很好地支持基于軟件體系結(jié)構(gòu)的開發(fā)過程。因此，研究人員在發(fā)展基于體系結(jié)構(gòu)的軟件開發(fā)模型方面做了一定的工作。

(5)軟件產(chǎn)品線體系結(jié)構(gòu)的研究。軟件體系結(jié)構(gòu)的開發(fā)是大型軟件系統(tǒng)開發(fā)的關(guān)鍵環(huán)節(jié)。體系結(jié)構(gòu)在軟件生產(chǎn)線的開發(fā)中起著至關(guān)重要的作用。在這種開發(fā)生產(chǎn)中，基于同一個軟件體系結(jié)構(gòu)，可以創(chuàng)建具有不同功能的多個系統(tǒng)。在軟件產(chǎn)品族之間共享體系結(jié)構(gòu)和一組可重用的構(gòu)件，可以增加軟件工程和降低開發(fā)、維護(hù)成本。一個產(chǎn)品線代表著一組具有公共的系統(tǒng)需求集的軟件系統(tǒng)，它們都是根據(jù)基本的用戶需求對標(biāo)準(zhǔn)的產(chǎn)品線構(gòu)架進(jìn)行定制，將可重用構(gòu)件與系統(tǒng)獨有的部分集成而得到的。采用軟件生產(chǎn)線模式進(jìn)行軟件生產(chǎn)，將產(chǎn)生巨型編程企業(yè)，但目前生產(chǎn)的軟件產(chǎn)品族大部分是處于同一領(lǐng)域的。2.1.4軟件體系結(jié)構(gòu)的影響

軟件體系結(jié)構(gòu)貫穿于軟件研發(fā)的整個生命周期，具有重要的影響。這主要從以下三個方面來進(jìn)行考察：

(1)相關(guān)人員之間的交流。軟件體系結(jié)構(gòu)是一種常見的對系統(tǒng)的抽象。代碼級別的系統(tǒng)抽象僅僅可以成為程序員的交流工具，而包括程序員在內(nèi)的絕大多數(shù)系統(tǒng)的利益相關(guān)人員都借助軟件體系結(jié)構(gòu)來進(jìn)行彼此理解、協(xié)商、達(dá)成共識或者相互溝通。

(2)系統(tǒng)設(shè)計的前期決策。軟件體系結(jié)構(gòu)是我們所開發(fā)的軟件系統(tǒng)最早期設(shè)計決策的體現(xiàn)，而這些早期決策對軟件系統(tǒng)的后續(xù)開發(fā)、部署和維護(hù)都有相當(dāng)重要的影響，這也是能夠?qū)λ_發(fā)系統(tǒng)進(jìn)行分析的最早時間點。

(3)可傳遞的系統(tǒng)級抽象。軟件體系結(jié)構(gòu)是關(guān)于系統(tǒng)構(gòu)造以及系統(tǒng)各個元素工作機制的相對較小、卻又能夠突出反映問題的模型。由于軟件系統(tǒng)具有的一些共通特性，這種模型可以在多個系統(tǒng)之間傳遞，特別是可以應(yīng)用到具有相似質(zhì)量屬性和功能需求的系統(tǒng)中，并能夠促進(jìn)大規(guī)模軟件的系統(tǒng)級復(fù)用。2.1.5軟件體系結(jié)構(gòu)的發(fā)展方向

當(dāng)前，體系結(jié)構(gòu)仍是一個非常新的研究領(lǐng)域，其概念還相當(dāng)模糊。但軟件體系結(jié)構(gòu)作為軟件工程領(lǐng)域中的一個組成部分，已經(jīng)取得了長足的發(fā)展，受到大多數(shù)軟件系統(tǒng)設(shè)計和研究人員的重視。

(1)各種體系結(jié)構(gòu)描述語言之間的信息互換?，F(xiàn)有的體系結(jié)構(gòu)描述語言大多是與領(lǐng)域相關(guān)的，所以不利于對不同領(lǐng)域體系結(jié)構(gòu)的說明，但這些針對不同領(lǐng)域的體系結(jié)構(gòu)描述語言在某些方面又大同小異，造成資源的冗余。其實，大多數(shù)體系結(jié)構(gòu)描述語言具有一系列的共同概念，如何用一種公共形式把各種語言綜合起來，從而能夠交換各種體系結(jié)構(gòu)描述信息，將是今后軟件體系結(jié)構(gòu)研究和實踐的重點之一。

(2)設(shè)計工具和環(huán)境。軟件體系結(jié)構(gòu)設(shè)計既然作為軟件工程的一部分，它的計算機輔助實現(xiàn)手段是相當(dāng)重要的。我們應(yīng)當(dāng)開發(fā)出一些軟件工具來實現(xiàn)體系結(jié)構(gòu)的描述和分析，還應(yīng)開發(fā)轉(zhuǎn)換工具以實現(xiàn)階段成果的自動轉(zhuǎn)換，例如把需求規(guī)格說明自動轉(zhuǎn)換為構(gòu)件等。目前關(guān)于這方面的研究成果很少，特別是可以應(yīng)用到實際項目開發(fā)中的工具和環(huán)境就更少。

(3)體系結(jié)構(gòu)再工程。當(dāng)今軟件系統(tǒng)的規(guī)模變得越來越大，結(jié)構(gòu)也越來越復(fù)雜，同時從頭開始構(gòu)建的大系統(tǒng)數(shù)量在急劇地減少，因而很多遺留系統(tǒng)正在被逐步地利用。從遺留系統(tǒng)軟件代碼和系統(tǒng)中抽取結(jié)構(gòu)信息，經(jīng)過描述、統(tǒng)一、抽象、一般化與實例化等處理，可總結(jié)出系統(tǒng)的體系結(jié)構(gòu)。在這種情況下，軟件再工程變得越來越重要，因為它提供了一條把遺留系統(tǒng)轉(zhuǎn)換為可進(jìn)化系統(tǒng)的現(xiàn)實可行的途徑，是一種可以改進(jìn)人們對軟件的理解和改進(jìn)軟件本身的活動。這類研究的目的是為一些特定的應(yīng)用領(lǐng)域的軟件系統(tǒng)提供一些體系結(jié)構(gòu)框架，如控制系統(tǒng)、移動機器人和用戶接口界面等，通過這些框架可以很方便地構(gòu)造一個新的軟件系統(tǒng)。 2.2軟件體系結(jié)構(gòu)建模

研究軟件體系結(jié)構(gòu)的首要問題是如何表示軟件體系結(jié)構(gòu)，即如何對軟件體系結(jié)構(gòu)建模。根據(jù)建模的側(cè)重點的不同，可以將軟件體系結(jié)構(gòu)的模型分為5種：結(jié)構(gòu)模型、框架模型、動態(tài)模型、過程模型和功能模型。在這5種模型中，最常用的是結(jié)構(gòu)模型和動態(tài)模型。

(1)結(jié)構(gòu)模型。結(jié)構(gòu)模型是一個最直觀、最普遍的建模方法。這種方法以體系結(jié)構(gòu)的構(gòu)件、連接件和其他概念來刻畫結(jié)構(gòu)，并力圖通過結(jié)構(gòu)來反映系統(tǒng)的重要語義內(nèi)容，包括系統(tǒng)的配置、約束、隱含的假設(shè)條件、風(fēng)格、性質(zhì)等。研究結(jié)構(gòu)模型的核心是體系結(jié)構(gòu)描述語言。

(2)框架模型?？蚣苣Ｐ团c結(jié)構(gòu)模型類似，但它不太側(cè)重描述結(jié)構(gòu)的細(xì)節(jié)而更側(cè)重于整體的結(jié)構(gòu)?？蚣苣Ｐ椭饕砸恍┨厥獾膯栴}為目標(biāo)建立只針對和適應(yīng)該問題的結(jié)構(gòu)。

(3)動態(tài)模型。動態(tài)模型是對結(jié)構(gòu)或框架模型的補充，研究系統(tǒng)的“大顆?！钡男袨樾再|(zhì)。例如，描述系統(tǒng)的重新配置或演化。其動態(tài)可能指系統(tǒng)總體結(jié)構(gòu)的配置、建立或拆除通信通道或計算的過程。這類系統(tǒng)常是激勵型的。

(4)過程模型。過程模型研究構(gòu)造系統(tǒng)的步驟和過程，因而其結(jié)構(gòu)是遵循某些過程腳本的結(jié)果。

(5)功能模型。功能模型認(rèn)為體系結(jié)構(gòu)由一組功能構(gòu)件按層次組成，下層為上層提供服務(wù)。它可以看做是一種特殊的框架模型。2.2.1“4+1”視圖模型

上面提到的5種模型各有所長，也許將5種模型有機地統(tǒng)一在一起，形成一個完整的模型來刻畫軟件體系結(jié)構(gòu)更合適。例如，Kruchten在1995年提出了一個“4+1”的視角模型。“4+1”模型從5個不同的視角(包括邏輯視角、過程視角、物理視角、開發(fā)視角和場景視角)來描述軟件體系結(jié)構(gòu)，每一個視角只關(guān)心系統(tǒng)的一個側(cè)面，5個視角結(jié)合在一起才能夠反映系統(tǒng)的軟件體系結(jié)構(gòu)的全部內(nèi)容。“4+1”模型如圖2.1所示。圖2.1“4+1”模型

1．邏輯視圖

邏輯視圖(logicview)主要支持系統(tǒng)的功能需求，即系統(tǒng)提供給最終用戶的服務(wù)。在邏輯視圖中，系統(tǒng)分解成一系列的功能抽象，這些抽象主要來自問題領(lǐng)域。這種分解不但可以用來進(jìn)行功能分析，而且可用作標(biāo)識整個系統(tǒng)的各個不同部分的通用機制和設(shè)計元素。在面向?qū)ο蠹夹g(shù)中，通過抽象、封裝和繼承，可以用對象模型來代表邏輯視圖，用類圖(classdiagram)來描述邏輯視圖。我們可以從Booch標(biāo)記法中導(dǎo)出邏輯視圖的標(biāo)記法，從體系結(jié)構(gòu)級的范疇來考慮這些符號，用RationalRose進(jìn)行體系結(jié)構(gòu)設(shè)計。圖2.2是邏輯視圖中使用的符號集合。圖2.2邏輯視圖中使用的符號集合類圖用于表示類的存在以及類與類之間的關(guān)系，是從系統(tǒng)構(gòu)成的角度來描述正在開發(fā)的系統(tǒng)的。一個類的存在不是孤立的，類與類之間以不同方式互相合作，共同完成某些系統(tǒng)功能。關(guān)聯(lián)關(guān)系表示兩個類之間存在著某種語義上的聯(lián)系，其真正含義要由附加在橫線上的一個短語予以說明。在表示包含關(guān)系的圖符中，帶有實心圓的一端表示整體，相反的一端表示部分；在表示使用關(guān)系的圖符中，帶有空心圓的一端連接在請求服務(wù)的類，相反的一端連接在提供服務(wù)的類；在表示繼承關(guān)系的圖符中，箭頭由子類指向基類。邏輯視圖中使用的風(fēng)格為面向?qū)ο蟮娘L(fēng)格，邏輯視圖設(shè)計中要注意的主要問題是要保持一個單一的、內(nèi)聚的對象模型并使其貫穿于整個系統(tǒng)。例如，圖2.3是某通信系統(tǒng)體系結(jié)構(gòu)(ACS)中的主要類。

ACS的功能是在終端之間建立連接，這種終端可以是電話機、主干線、專用線路、特殊電話線、數(shù)據(jù)線或ISDN線路等，不同線路由不同的線路接口卡來支持。線路控制器對象的作用是譯碼并把所有符號加入到線路接口卡中；終端對象的作用是保持終端的狀態(tài)，代表本條路線的利益參與協(xié)商服務(wù)；會話對象代表一組參與會話的終端，使用轉(zhuǎn)換服務(wù)(目錄、邏輯地址映射到物理地址、路由等)和連接服務(wù)，在終端之間建立語音路徑。圖2.3通信系統(tǒng)體系結(jié)構(gòu)邏輯視圖對于更大規(guī)模的系統(tǒng)來說，體系結(jié)構(gòu)級中可能包含數(shù)十甚至數(shù)百個類。例如，圖2.4是一個空中交通管制系統(tǒng)的頂級類圖，該圖包含了8組類。圖2.4空中交通管制系統(tǒng)的頂級類圖

2．開發(fā)視圖

開發(fā)視圖(developmentview)也稱模塊視圖(moduleview)，主要側(cè)重于軟件模塊的組織和管理。軟件可通過程序庫或子系統(tǒng)進(jìn)行組織，這樣，對于一個軟件系統(tǒng)，就可以由不同的人進(jìn)行開發(fā)。開發(fā)視圖要考慮軟件內(nèi)部的需求，如軟件開發(fā)的容易性、軟件重用、軟件的通用性，還要充分考慮由于具體開發(fā)工具的不同而帶來的局限性。

開發(fā)視圖通過系統(tǒng)輸入輸出關(guān)系的模型圖和子系統(tǒng)圖來描述?？梢栽诖_定了軟件包含的所有元素之后描述完整的開發(fā)角度，也可以在確定每個元素之前，列出開發(fā)視圖原則。

與邏輯視圖一樣，我們可以使用Booch標(biāo)記法中的某些符號來表示開發(fā)視圖，如圖2.5所示。圖2.5開發(fā)視圖中使用的標(biāo)記符號在開發(fā)視圖中，最好采用4～6層子系統(tǒng)，而且每個子系統(tǒng)只能與同層或更低層的子系統(tǒng)通信，這樣可以使每個層次的接口既完備又精練，避免了各個模塊之間很復(fù)雜的依賴關(guān)系。而且，設(shè)計時要充分考慮，對于各個層次，層次越低，通用性越強，這樣可以保證應(yīng)用程序的需求發(fā)生改變時，所做的改動最小。開發(fā)視圖所用的風(fēng)格通常是層次結(jié)構(gòu)風(fēng)格。例如，圖2.6表示的是空中交通管制系統(tǒng)的5層結(jié)構(gòu)圖。

圖2.6是圖2.4的開發(fā)視圖。第1層和第2層組成了一個領(lǐng)域無關(guān)的分布式基礎(chǔ)設(shè)施，貫穿于整個產(chǎn)品線中，并且與硬件平臺、操作系統(tǒng)或數(shù)據(jù)庫管理系統(tǒng)等無關(guān)。第3層增加了空中交通管制系統(tǒng)的框架，以形成一個領(lǐng)域特定的軟件體系結(jié)構(gòu)。第4層使用該框架建立一個功能平臺。第5層則依賴于具體客戶和產(chǎn)品，包括了大部分用戶接口以及外部系統(tǒng)接口。圖2.6空中交通管制系統(tǒng)的5層結(jié)構(gòu)

3．進(jìn)程視圖

進(jìn)程視圖(processview)側(cè)重于系統(tǒng)的運行特性，主要關(guān)注一些非功能性的需求，例如系統(tǒng)的性能和可用性，進(jìn)程視圖強調(diào)并發(fā)性、分布性、系統(tǒng)集成性和容錯能力。它也定義了邏輯視圖中的各個類的操作具體是在哪一個線程(thread)中被執(zhí)行的。

進(jìn)程視圖可以描述成多層抽象，每個級別分別關(guān)注不同的方面。在最高層抽象中，進(jìn)程結(jié)構(gòu)可以看做是構(gòu)成一個執(zhí)行單元的一組任務(wù)，也可看成一系列獨立的、通過邏輯網(wǎng)絡(luò)相互通信的程序，它們是分布的，通過總線或局域網(wǎng)、廣域網(wǎng)等硬件資源連接起來。通過進(jìn)程視圖可以從進(jìn)程測量一個目標(biāo)系統(tǒng)最終的執(zhí)行情況。例如在以計算機網(wǎng)絡(luò)作為運行環(huán)境的圖書管理系統(tǒng)中，服務(wù)器需對來自各個不同的客戶機的進(jìn)程進(jìn)行管理，決定某個特定進(jìn)程(如查詢子進(jìn)程、借還書子進(jìn)程)的喚醒、啟動、關(guān)閉等操作，從而控制整個網(wǎng)絡(luò)協(xié)調(diào)、有序地工作。

我們通過擴展Booch對Ada任務(wù)的表示法來表示進(jìn)程視圖。從體系結(jié)構(gòu)角度來看，進(jìn)程視圖的標(biāo)記元素如圖2.7所示。圖2.7進(jìn)程視圖中使用的標(biāo)記符號有很多風(fēng)格適用于進(jìn)程視圖，如管道和過濾器風(fēng)格、客戶/服務(wù)器(多客戶/單服務(wù)器，多客戶/多服務(wù)器)風(fēng)格等。圖2.8是2.2.1節(jié)中的ACS系統(tǒng)的局部進(jìn)程視圖。

在圖2.8中，所有終端均由同一個終端進(jìn)程進(jìn)行處理，由其輸入隊列中的消息驅(qū)動?？刂破鲗ο笤诮M成控制器進(jìn)程的三個任務(wù)之一中執(zhí)行，慢周期(200?ms)控制器任務(wù)掃描所有掛起(suspend)終端，把任何一個活動的終端置入快周期(10?ms)控制器任務(wù)的掃描列表；快周期控制器任務(wù)檢測任何顯著的狀態(tài)改變，并把改變的狀態(tài)傳遞給主控制器任務(wù)；主控制器任務(wù)解釋改變，通過消息與相應(yīng)的終端進(jìn)行通信。在這里，通過共享內(nèi)存來實現(xiàn)在控制器進(jìn)程中傳遞消息的功能。圖2.8ACS系統(tǒng)的局部進(jìn)程視圖

4．物理視圖

物理視圖(physicalview)主要考慮如何把軟件映射到硬件上，它通常要考慮系統(tǒng)性能、規(guī)模、可靠性等，以解決系統(tǒng)拓?fù)浣Y(jié)構(gòu)、系統(tǒng)安裝、通信等問題。當(dāng)軟件運行于不同的結(jié)點上時，各視圖中的構(gòu)件都直接或間接地對應(yīng)于系統(tǒng)的不同結(jié)點。因此，從軟件到結(jié)點的映射要有較高的靈活性，當(dāng)環(huán)境改變時，對系統(tǒng)其他視圖的影響要小。

大型系統(tǒng)的物理視圖可能會變得十分混亂，因此可以與進(jìn)程視圖的映射一起，以多種形式出現(xiàn)，也可單獨出現(xiàn)。圖2.9是物理視圖的標(biāo)記元素集合。圖2.9物理視圖中使用的標(biāo)記符號圖2.10所示是一個大型ACS系統(tǒng)可能的硬件配置，圖2.11和圖2.12是進(jìn)程視圖的兩個不同的物理視圖映射，分別對應(yīng)一個小型的ACS和一個大型的ACS。圖中，C、F和K是三個不同容量的計算機類型，支持三個不同的可執(zhí)行文件。圖2.10ACS系統(tǒng)的物理視圖圖2.11具有進(jìn)程分配的小型ACS系統(tǒng)的物理視圖圖2.12具有進(jìn)程分配的大型ACS系統(tǒng)的物理視圖

5．場景

場景(scenarios)可以看做是那些重要系統(tǒng)活動的抽象，它使4個視圖有機地聯(lián)系起來，從某種意義上說，場景是最重要的需求抽象。在開發(fā)體系結(jié)構(gòu)時，它可以幫助設(shè)計者找到體系結(jié)構(gòu)的構(gòu)件和它們之間的作用關(guān)系；同時，也可以用場景來分析一個特定的視圖，或描述不同視圖構(gòu)件間的相互作用。場景可以用文本表示，也可以用圖形表示。例如，圖2.13是一個小型ACS系統(tǒng)的場景片段，相應(yīng)的文本表示如下過程：

①小王的電話控制器檢測和驗證電話從掛機到摘機狀態(tài)的轉(zhuǎn)變，且發(fā)送一個消息以喚醒相應(yīng)的終端對象。②終端分配一定的資源，且通知控制器發(fā)出某種撥號音。

③控制器接收所撥號碼并傳給終端。

④終端使用編號計劃分析號碼。

⑤當(dāng)一個有效的撥號序列進(jìn)入時，終端打開一個會話。

從以上分析可知，邏輯視圖和開發(fā)視圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，而進(jìn)程視圖和物理視圖描述系統(tǒng)的動態(tài)結(jié)構(gòu)。對于不同的軟件系統(tǒng)來說，側(cè)重的角度也有所不同。例如，對于管理信息系統(tǒng)，比較側(cè)重于從邏輯視圖和開發(fā)視圖來描述系統(tǒng)，而對于實時控制系統(tǒng)，則比較注重于從進(jìn)程視圖和物理視圖來描述系統(tǒng)。圖2.13本地呼叫場景的一個原型2.2.2軟件體系結(jié)構(gòu)的核心模型

綜合軟件體系結(jié)構(gòu)的概念，體系結(jié)構(gòu)的核心模型由五種元素組成：構(gòu)件、連接件、配置(configuration)、端口(port)和角色(role)。其中構(gòu)件、連接件和配置是最基本的元素。

構(gòu)件是具有某種功能的可重用的軟件模板單元，表示了系統(tǒng)中主要的計算元素和數(shù)據(jù)存儲。構(gòu)件有兩種：復(fù)合構(gòu)件和原子構(gòu)件。復(fù)合構(gòu)件由其他復(fù)合構(gòu)件和原子構(gòu)件連接而成；原子構(gòu)件是不可再分的構(gòu)件，底層由實現(xiàn)該構(gòu)件的類組成。這種構(gòu)件的劃分提供了體系結(jié)構(gòu)的分層表示能力，有助于簡化體系結(jié)構(gòu)的設(shè)計。連接件表示了構(gòu)件之間的交互。簡單的連接件如管道(pipe)、過程調(diào)用(procedurecall)、事件廣播(eventbroadcast)等。更為復(fù)雜的交互有客戶/服務(wù)器(client/server)通信協(xié)議、數(shù)據(jù)庫和應(yīng)用之間的SQL連接等。

配置表示了構(gòu)件和連接件的拓?fù)溥壿嫼图s束。

另外，構(gòu)件作為一個封裝的實體，只能通過其接口與外部環(huán)境交互。構(gòu)件的接口由一組端口組成，每個端口都表示了構(gòu)件和外部環(huán)境的交互點。通過不同的端口類型，一個構(gòu)件可以提供多重接口。一個端口可以非常簡單，如過程調(diào)用，也可以表示更為復(fù)雜的界面(包含一些約束)，如必須以某種順序調(diào)用的一組過程調(diào)用。連接件作為建模軟件體系結(jié)構(gòu)的主要實體，同樣也有接口。連接件的接口由一組角色組成，每一個角色都定義了該連接件表示的交互參與者。二元連接件有兩個角色，如RPC的角色為caller和callee，pipe的角色是reading和writing，消息傳遞連接件的角色是sender和receiver。有的連接件有多于兩個的角色，如事件廣播有一個事件發(fā)布者角色和任意多個事件接收者角色。

綜上所述，我們可將軟件體系結(jié)構(gòu)的核心模型表示為圖2.14。圖2.14軟件體系結(jié)構(gòu)的核心模型2.2.3軟件體系結(jié)構(gòu)的生命周期模型

對于軟件項目的開發(fā)來說，一個清晰的軟件體系結(jié)構(gòu)是首要的。傳統(tǒng)的軟件開發(fā)過程可以劃分為從概念直到實現(xiàn)的若干個階段，包括問題定義、需求分析、軟件設(shè)計、軟件實現(xiàn)及軟件測試等。軟件體系結(jié)構(gòu)的建立應(yīng)在需求分析之后，軟件設(shè)計之前。在建立軟件體系結(jié)構(gòu)時，設(shè)計者主要從結(jié)構(gòu)的角度對整個系統(tǒng)進(jìn)行分析，選擇恰當(dāng)?shù)臉?gòu)件、構(gòu)件間的相互作用以及它們的約束，最后形成一個系統(tǒng)框架以滿足用戶的需求，為軟件設(shè)計奠定基礎(chǔ)。

下面從各個階段的功能出發(fā)，分析這幾個層次之間的關(guān)系。

1．需求分析階段

需求分析階段的任務(wù)是根據(jù)需求，決定系統(tǒng)的功能。在此階段，設(shè)計者應(yīng)對目標(biāo)對象和環(huán)境做細(xì)致深入的調(diào)查，收集目標(biāo)對象的基本信息，從中找出有用的信息。這是一個抽象思維、邏輯推理的過程，其結(jié)果是生成軟件規(guī)格說明。需求是指用戶對目標(biāo)軟件系統(tǒng)在功能、行為、性能、設(shè)計約束等方面的期望，需求分析過程主要是獲取用戶需求，確定系統(tǒng)中所要用到的構(gòu)件。體系結(jié)構(gòu)需求包括需求獲取、生成類圖、對類分組、把類打包成構(gòu)件和需求評審等過程。其中需求獲取主要是定義開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足業(yè)務(wù)上的功能需求。與此同時，還要獲得軟件質(zhì)量屬性，滿足一些非功能需求。獲取了需求之后，就可以利用工具(例如RationalRose)自動生成類圖，然后對類進(jìn)行分組，簡化類圖結(jié)構(gòu)，使之更清晰。分組之后，再把類簇打包成構(gòu)件，這些構(gòu)件可以分組合并成更大的構(gòu)件。

最后進(jìn)行需求評審，即組織一個由不同代表(如分析人員、客戶、設(shè)計人員、測試人員)組成的小組，對體系結(jié)構(gòu)需求及相關(guān)構(gòu)件進(jìn)行仔細(xì)的審查。審查的主要內(nèi)容包括所獲取的需求是否真實反映了用戶的要求、類的分組是否合理以及構(gòu)件合并是否合理等。

2．建立軟件體系結(jié)構(gòu)階段

在這個階段，體系結(jié)構(gòu)設(shè)計師主要從結(jié)構(gòu)的角度對整個系統(tǒng)進(jìn)行分析，選擇恰當(dāng)?shù)臉?gòu)件，根據(jù)構(gòu)件間的相互作用關(guān)系以及對它們的約束，形成一個系統(tǒng)框架以滿足用戶需求，為設(shè)計奠定基礎(chǔ)。

在建立體系結(jié)構(gòu)的初期，選擇一個合適的體系結(jié)構(gòu)風(fēng)格是首要的。選擇了風(fēng)格之后，把在體系結(jié)構(gòu)需求階段已確認(rèn)的構(gòu)件映射到體系結(jié)構(gòu)中，將產(chǎn)生一個中間結(jié)構(gòu)。然后，為了把所有已確認(rèn)的構(gòu)件集成到體系結(jié)構(gòu)中，必須認(rèn)真分析這些構(gòu)件的相互作用和關(guān)系。一旦決定了關(guān)鍵構(gòu)件之間的相互作用和關(guān)系，就可以在前面得到的中間結(jié)構(gòu)的基礎(chǔ)上進(jìn)行細(xì)化。

3．設(shè)計階段

設(shè)計階段主要是對系統(tǒng)進(jìn)行模塊化并決定描述各個構(gòu)件間的詳細(xì)接口、算法和數(shù)據(jù)類型，對上支持建立軟件體系結(jié)構(gòu)階段所形成的框架，對下提供實現(xiàn)基礎(chǔ)。

一旦設(shè)計了軟件體系結(jié)構(gòu)，我們必須邀請獨立于系統(tǒng)開發(fā)的外部人員對體系結(jié)構(gòu)進(jìn)行評審。

4．實現(xiàn)階段

實現(xiàn)階段將設(shè)計階段設(shè)計的算法及數(shù)據(jù)類型用程序語言表示，以滿足設(shè)計體系結(jié)構(gòu)和需求分析的要求，從而得到滿足設(shè)計需求的目標(biāo)系統(tǒng)。整個實現(xiàn)過程是以復(fù)審后的文檔化的體系結(jié)構(gòu)說明書為基礎(chǔ)的，每個構(gòu)件都必須滿足軟件體系結(jié)構(gòu)中說明的對其他構(gòu)件的責(zé)任。這些決定(即實現(xiàn)的約束)是在系統(tǒng)級或整個項目范圍內(nèi)做出的，每個構(gòu)件上工作的實現(xiàn)者是看不見的。

在體系結(jié)構(gòu)說明書中，已經(jīng)定義了系統(tǒng)中的構(gòu)件與構(gòu)件之間的關(guān)系。在體系結(jié)構(gòu)層次上，因為構(gòu)件接口約束對外唯一地代表了構(gòu)件，所以可以從構(gòu)件庫中查找符合接口約束的構(gòu)件，必要時還可開發(fā)新的滿足要求的構(gòu)件。然后，按照設(shè)計提供的結(jié)構(gòu)，通過組裝支持工具把這些構(gòu)件的實現(xiàn)體組裝起來，完成整個軟件系統(tǒng)的連接與合成。

最后一步是測試，包括單個構(gòu)件的功能性測試和組裝應(yīng)用的整體功能與性能測試。

由此可見，軟件體系結(jié)構(gòu)在系統(tǒng)開發(fā)的全過程中起著基礎(chǔ)的作用，是設(shè)計的起點和依據(jù)，同時也是裝配和維護(hù)的指南。與軟件本身一樣，軟件體系結(jié)構(gòu)也有其生命周期，圖2.15形象地表示了體系結(jié)構(gòu)的生命周期。圖2.15軟件體系結(jié)構(gòu)的生命周期模型

(1)軟件體系結(jié)構(gòu)的非形式化描述。在軟件體系結(jié)構(gòu)的非形式化描述(softwarearchitectureinformaldescription)階段，對軟件體系結(jié)構(gòu)的描述盡管常用自然語言，但是該階段的工作卻是創(chuàng)造性和開拓性的。一種軟件體系結(jié)構(gòu)產(chǎn)生時，其思想通常是簡單的，并常常由軟件設(shè)計師用非形式化的自然語言表示概念、原則。例如，客戶/服務(wù)器體系結(jié)構(gòu)就是為適應(yīng)分布式系統(tǒng)的要求，從主從式演變而來的一種軟件體系結(jié)構(gòu)。

(2)軟件體系結(jié)構(gòu)的規(guī)范描述和分析。軟件體系結(jié)構(gòu)的規(guī)范描述和分析(softwarearchitecturespecificationandanalysis)階段通過運用合適的形式化數(shù)學(xué)理論模型對第1階段的體系結(jié)構(gòu)的非形式化描述進(jìn)行規(guī)范定義，從而得到軟件體系結(jié)構(gòu)的形式化規(guī)范描述，以使軟件體系結(jié)構(gòu)的描述精確、無歧義，進(jìn)而分析軟件體系結(jié)構(gòu)的性質(zhì)，如無死鎖性、安全性、健壯性等。分析軟件體系結(jié)構(gòu)的性質(zhì)有利于在系統(tǒng)設(shè)計時選擇合適的軟件體系結(jié)構(gòu)，避免盲目選擇。

(3)軟件體系結(jié)構(gòu)的求精及其驗證。軟件體系結(jié)構(gòu)的求精及其驗證(softwarearchitecturerefinementandverification)階段對已設(shè)計好的軟件體系結(jié)構(gòu)進(jìn)行驗證和求精。大型系統(tǒng)的軟件體系結(jié)構(gòu)總是通過從抽象到具體、逐步求精而達(dá)到的。一般來說，抽象是人們在處理復(fù)雜問題和對象時必不可少的思維方式，軟件體系結(jié)構(gòu)也不例外，但是過高的抽象卻使軟件體系結(jié)構(gòu)難以真正在系統(tǒng)設(shè)計中實施。如果軟件體系結(jié)構(gòu)的抽象粒度過大，就需要對體系結(jié)構(gòu)進(jìn)行求精、細(xì)化，直至其能夠在系統(tǒng)設(shè)計中實施為止。在軟件體系結(jié)構(gòu)的每一步求精過程中，需要對不同抽象層次的軟件體系結(jié)構(gòu)進(jìn)行驗證，以判斷較具體的軟件體系結(jié)構(gòu)是否與較抽象的軟件體系結(jié)構(gòu)的語義一致，能否實現(xiàn)抽象的軟件體系結(jié)構(gòu)。

(4)軟件體系結(jié)構(gòu)的實施。軟件體系結(jié)構(gòu)的實施(softwarearchitectureenactment)階段將求精后的軟件體系結(jié)構(gòu)實施于系統(tǒng)的設(shè)計中，并將軟件體系結(jié)構(gòu)的構(gòu)件和連接件等有機地組織在一起，形成系統(tǒng)設(shè)計的框架。

(5)軟件體系結(jié)構(gòu)的演化和擴展。當(dāng)體系結(jié)構(gòu)實施后，就進(jìn)入軟件體系結(jié)構(gòu)的演化和擴展(softwarearchitectureevolutionandextension)階段。在實施軟件體系結(jié)構(gòu)時，性能、容錯、安全性、互操作性、自適應(yīng)性等非功能性質(zhì)將影響軟件體系結(jié)構(gòu)的擴展和改動，這稱為軟件體系結(jié)構(gòu)的演化。由于對軟件體系結(jié)構(gòu)的演化常常由非功能性質(zhì)的非形式化需求描述引起，因而需要重復(fù)第(1)步。如果由于功能和非功能性質(zhì)對以前的軟件體系結(jié)構(gòu)進(jìn)行演化，就要涉及軟件體系結(jié)構(gòu)的理解，需要進(jìn)行軟件體系結(jié)構(gòu)的逆向工程和再造工程。

(6)軟件體系結(jié)構(gòu)的提供、評價和度量。軟件體系結(jié)構(gòu)的提供、評價和度量(softwarearchitectureprovision，evaluationandmetric)階段根據(jù)將軟件體系結(jié)構(gòu)實施于系統(tǒng)設(shè)計后系統(tǒng)的實際運行情況，對軟件體系結(jié)構(gòu)進(jìn)行定性的評價和定量的度量，以利于對軟件體系結(jié)構(gòu)的重用，并取得經(jīng)驗教訓(xùn)。

(7)軟件體系結(jié)構(gòu)的終結(jié)。如果一個軟件系統(tǒng)的軟件體系結(jié)構(gòu)進(jìn)行了多次演化和修改，軟件體系結(jié)構(gòu)已變得難以理解，甚至不能達(dá)到系統(tǒng)設(shè)計的要求，不能適應(yīng)系統(tǒng)的發(fā)展，這就說明該軟件體系結(jié)構(gòu)已經(jīng)過時，應(yīng)該擯棄，以全新的滿足系統(tǒng)設(shè)計要求的軟件體系結(jié)構(gòu)取而代之。這個階段被稱為軟件體系結(jié)構(gòu)的終結(jié)(softwarearchitecturetermination)階段。 2.3基于體系結(jié)構(gòu)的描述

2.3.1軟件體系結(jié)構(gòu)的描述方法

1．圖形表達(dá)工具

對于軟件體系結(jié)構(gòu)的描述和表達(dá)，一種簡潔易懂且使用廣泛的方法是采用由矩形框和有向線段組合而成的圖形表達(dá)工具。在這種方法中，矩形框代表抽象構(gòu)件，框內(nèi)標(biāo)注的文字為抽象構(gòu)件的名稱，有向線段代表輔助各構(gòu)件進(jìn)行通信、控制或關(guān)聯(lián)的連接件。圖2.16表示某軟件輔助理解和測試工具的部分體系結(jié)構(gòu)描述。圖2.16某軟件輔助理解和測試工具的部分體系結(jié)構(gòu)描述目前，這種圖形表達(dá)工具在軟件設(shè)計中占據(jù)著主導(dǎo)地位。盡管由于在術(shù)語和表達(dá)語義上存在著一些不規(guī)范和不精確，以矩形框和線段為基礎(chǔ)的傳統(tǒng)圖形表達(dá)方法在不同系統(tǒng)和不同文檔之間有著許多不一致甚至矛盾，但該方法仍然以其簡潔易用的特點在實際的設(shè)計和開發(fā)工作中被廣泛使用，并為工作人員傳遞了大量重要的體系結(jié)構(gòu)思想。

為了克服傳統(tǒng)圖形表達(dá)方法中所缺乏的語義特征，有關(guān)研究人員試圖通過增加含有語義的圖元素的方式來擴展圖形表達(dá)方法。

2．模塊內(nèi)連接語言

軟件體系結(jié)構(gòu)的第二種描述和表達(dá)方法是采用將一種或幾種傳統(tǒng)程序設(shè)計語言的模塊連接起來的模塊內(nèi)連接語言(ModuleInterconnectionLanguage，MIL)。由于程序設(shè)計語言和模塊內(nèi)連接語言具有嚴(yán)格的語義基礎(chǔ)，因此它們能對較大的軟件單元進(jìn)行描述，諸如定義/使用和扇入/扇出等操作。例如，Ada語言采用use實現(xiàn)包的重用，Pascal語言采用過程(函數(shù))模塊的交互等。

MIL方式對模塊化的程序設(shè)計和分段編譯等程序設(shè)計與開發(fā)技術(shù)確實發(fā)揮了很大的作用。但是由于這些語言處理和描述的軟件設(shè)計開發(fā)層次過于依賴程序設(shè)計語言，因而限制了它們處理和描述比程序設(shè)計語言元素更為抽象的高層次軟件體系結(jié)構(gòu)元素的能力。

3．基于軟構(gòu)件的系統(tǒng)描述語言

軟件體系結(jié)構(gòu)的第三種描述和表達(dá)方法是采用基于軟構(gòu)件的系統(tǒng)描述語言?；谲洏?gòu)件的系統(tǒng)描述語言將軟件系統(tǒng)描述成一種由許多以特定形式相互作用的特殊軟件實體構(gòu)造而成的組織或系統(tǒng)。例如，一種多變配置語言(ProteusConfigurationLanguage，PCL)就可以在一個較高的抽象層次上對系統(tǒng)的體系結(jié)構(gòu)建模；Darwin最初用作設(shè)計和構(gòu)造復(fù)雜分布式系統(tǒng)的配置說明語言，因其具有動態(tài)特性，也可用來描述動態(tài)體系結(jié)構(gòu)。這種表達(dá)和描述方式雖然也是較好的一種以構(gòu)件為單位的軟件系統(tǒng)描述方法，但是它們所面向和針對的系統(tǒng)元素仍然是一些層次較低的以程序設(shè)計為基礎(chǔ)的通信協(xié)作軟件實體單元，而且這些語言所描述和表達(dá)的系統(tǒng)一般而言都是面向特定應(yīng)用的特殊系統(tǒng)，這些特性使得基于軟構(gòu)件的系統(tǒng)描述仍然不是十分適合軟件體系結(jié)構(gòu)的描述和表達(dá)。

4．軟件體系結(jié)構(gòu)描述語言

軟件體系結(jié)構(gòu)的第四種描述和表達(dá)方法是參照傳統(tǒng)程序設(shè)計語言的設(shè)計和開發(fā)經(jīng)驗，重新設(shè)計、開發(fā)和使用針對軟件體系結(jié)構(gòu)特點的專門的軟件體系結(jié)構(gòu)描述語言(ArchitectureDescriptionLanguage，ADL)。由于ADL是在吸收了傳統(tǒng)程序設(shè)計中語義嚴(yán)格精確的特點基礎(chǔ)上，針對軟件體系結(jié)構(gòu)的整體性和抽象性特點，定義和確定適合于軟件體系結(jié)構(gòu)表達(dá)與描述的有關(guān)抽象元素的，因此，ADL是當(dāng)前軟件開發(fā)和設(shè)計方法學(xué)中一種發(fā)展很快的軟件體系結(jié)構(gòu)描述方法。目前，已經(jīng)有幾十種常見的ADL。我們將在2.3.3節(jié)詳細(xì)介紹幾種主要的軟件體系結(jié)構(gòu)描述語言。2.3.2軟件體系結(jié)構(gòu)的描述框架標(biāo)準(zhǔn)

鑒于體系結(jié)構(gòu)描述的概念與實踐的不統(tǒng)一，IEEE于1995年8月成立了體系結(jié)構(gòu)工作組。該工作組綜合體系結(jié)構(gòu)描述研究成果，并參考業(yè)界的體系結(jié)構(gòu)描述的實踐，負(fù)責(zé)起草了體系結(jié)構(gòu)描述框架標(biāo)準(zhǔn)IEEEP1471，并于2000年9月21日通過IEEE-SA標(biāo)準(zhǔn)委員會評審。

IEEEP1471適用于軟件密集的系統(tǒng)，其目標(biāo)在于：便于體系結(jié)構(gòu)的表達(dá)與交流，并通過體系結(jié)構(gòu)要素及其實踐標(biāo)準(zhǔn)化，奠定質(zhì)量與成本的基礎(chǔ)。該標(biāo)準(zhǔn)詳細(xì)介紹了一套體系結(jié)構(gòu)描述的概念框架，并給出建立框架的思路。同時，該標(biāo)準(zhǔn)還討論了體系結(jié)構(gòu)描述實踐。在應(yīng)用體系結(jié)構(gòu)描述的推薦標(biāo)準(zhǔn)時，應(yīng)該遵循如下要求：

●體系結(jié)構(gòu)的存檔要求；

●能識別人員及其關(guān)系；

●體系結(jié)構(gòu)視點的選擇(視點的具體規(guī)格說明)；

●體系結(jié)構(gòu)視點；

●體系結(jié)構(gòu)視點之間的一致性；

●體系結(jié)構(gòu)原理。

IEEEP1471僅僅提供了體系結(jié)構(gòu)描述的概念框架及體系結(jié)構(gòu)描述實踐應(yīng)該遵循的規(guī)范，但對如何描述以及具體的描述技術(shù)等方面卻缺乏更進(jìn)一步的指導(dǎo)。在IEEEP1471推薦的體系結(jié)構(gòu)描述的概念框架基礎(chǔ)上，Rational起草了可重用的軟件資產(chǎn)規(guī)格說明，專門討論了體系結(jié)構(gòu)描述的規(guī)格說明，提出了一套易于重用的體系結(jié)構(gòu)描述規(guī)范。該建議草案已經(jīng)提交OMG，可望成為體系結(jié)構(gòu)描述的行業(yè)規(guī)范。

可重用的體系結(jié)構(gòu)描述框架建議，基于RUP(RationalUnitedProcess)、采用UML模型描述軟件的體系結(jié)構(gòu)，認(rèn)為體系結(jié)構(gòu)描述的關(guān)鍵是定義視點、視圖以及建模元素之間的映射關(guān)系?？梢詮乃膫€視點出發(fā)描述體系結(jié)構(gòu)，即需求視點、設(shè)計視點、實現(xiàn)視點和測試視點，并在此基礎(chǔ)上提出了七種體系結(jié)構(gòu)視圖，即用例視圖、域視圖、非功能需求視圖、邏輯視圖、實現(xiàn)視圖、過程視圖和部署視圖。然后，從系統(tǒng)建模的角度考慮多個視圖之間的映射關(guān)系，并建議了這些視圖的表示和視圖之間的映射關(guān)系的表示。

Rational的建議標(biāo)準(zhǔn)采納了IEEEP1471中提出的體系結(jié)構(gòu)描述概念模型，覆蓋了“4+1”，體系結(jié)構(gòu)模型中的四個視圖，并在原則上討論了視圖以及視圖之間映射的表示問題。與IEEEP1471相比，該建議標(biāo)準(zhǔn)的體系結(jié)構(gòu)描述方案涉及面比較窄，所注重的層次比較低，因而更具體。同時由于將體系結(jié)構(gòu)的描述限于UML和RUP，因而具有一定的局限性。但該建議標(biāo)準(zhǔn)結(jié)合了業(yè)界已經(jīng)廣泛采用的建模語言和開發(fā)過程，因此易于推廣。2.3.3軟件體系結(jié)構(gòu)的描述語言

ADL是這樣一種形式化語言，它在底層語義模型的支持下，為軟件系統(tǒng)的概念體系結(jié)構(gòu)建模提供了具體語法和概念框架?；诘讓诱Z義的工具為體系結(jié)構(gòu)的表示、分析、演化、細(xì)化、設(shè)計過程等提供支持，有如下三個基本元素：

●構(gòu)件：計算或數(shù)據(jù)存儲單元。

●連接件：用于構(gòu)件之間交互建模的體系結(jié)構(gòu)構(gòu)造塊及支配這些交互的規(guī)則。

●體系結(jié)構(gòu)配置：描述體系結(jié)構(gòu)的構(gòu)件與連接件的連接圖。主要的體系結(jié)構(gòu)描述語言有Aesop、MetaH、C2、Rapide、SADL、UniCon和Wright等，盡管它們都描述軟件體系結(jié)構(gòu)，卻有不同的特點。Aesop支持體系結(jié)構(gòu)風(fēng)格的應(yīng)用；MetaH為設(shè)計者提供了關(guān)于實時電子控制軟件系統(tǒng)的設(shè)計指導(dǎo)；C2支持基于消息傳遞風(fēng)格的用戶界面系統(tǒng)的描述；Rapide支持體系結(jié)構(gòu)設(shè)計的模擬并提供了分析模擬結(jié)果的工具；SADL提供了關(guān)于體系結(jié)構(gòu)求精的形式化基礎(chǔ)；Unicon支持異構(gòu)的構(gòu)件和連接類型，并提供了關(guān)于體系結(jié)構(gòu)的高層編譯器；Wright支持體系結(jié)構(gòu)構(gòu)件之間交互的說明和分析。這些ADL強調(diào)了體系結(jié)構(gòu)不同的側(cè)面，對體系結(jié)構(gòu)的研究和應(yīng)用起到了重要的作用，但其也有負(fù)面的影響。每一種ADL都以獨立的形式存在，描述語法不同且互不兼容,同時又有許多共同的特征，這使設(shè)計人員很難選擇一種合適的ADL。如果要設(shè)計特定領(lǐng)域的軟件體系結(jié)構(gòu)，就需要從頭開始描述。

1．ADL與其他語言的比較

按照MaryShaw和DavidGarlan的觀點，典型的ADL在充分繼承和吸收傳統(tǒng)程序設(shè)計語言的精確性和嚴(yán)格性特點的同時，還應(yīng)該具有構(gòu)造、抽象、重用、組合、異構(gòu)和分析推理等各種能力和特性。其中：

●構(gòu)造能力指的是ADL能夠使用較小的獨立體系結(jié)構(gòu)元素來建造大型軟件系統(tǒng)。

●抽象能力指的是ADL使得軟件體系結(jié)構(gòu)中的構(gòu)件和連接件描述可以只關(guān)注它們的抽象特性，而不管其具體的實現(xiàn)細(xì)節(jié)?！裰赜媚芰χ傅氖茿DL使得組成軟件系統(tǒng)的構(gòu)件、連接件甚至是軟件體系結(jié)構(gòu)都成為軟件系統(tǒng)開發(fā)和設(shè)計的可重用部件。

●組合能力指的是ADL使得其描述的每一系統(tǒng)元素都有其自己的局部結(jié)構(gòu)，這種描述局部結(jié)構(gòu)的特點使得ADL支持軟件系統(tǒng)的動態(tài)變化組合。

●異構(gòu)能力指的是ADL允許多個不同的體系結(jié)構(gòu)描述可以存在關(guān)聯(lián)。

●分析和推理能力指的是ADL允許對其描述的體系結(jié)構(gòu)進(jìn)行多種不同的性能和功能上的多種推理分析。根據(jù)這些特點，我們可以將下面這樣的語言排除在ADL之外：高層設(shè)計符號語言、MIL、編程語言、面向?qū)ο蟮慕７?、形式化說明語言。ADL與需求語言的區(qū)別在于后者描述的是問題空間，而前者則扎根于解空間。ADL與建模語言的區(qū)別在于后者對整體行為的關(guān)注要大于對部分的關(guān)注，而ADL集中在構(gòu)件的表示上。ADL與傳統(tǒng)的程序設(shè)計語言的構(gòu)成元素既有許多相同和相似之處，又有著很大的不同。

表2.1和表2.2給出了程序設(shè)計語言和ADL的典型元素的屬性和含義比較，以及軟件體系結(jié)構(gòu)中經(jīng)常出現(xiàn)的一些構(gòu)件和連接件元素。表2.1典型元素含義比較表2.2常見的軟件體系結(jié)構(gòu)元素

2．ADL的構(gòu)成要素

前面，我們提到了體系結(jié)構(gòu)描述的基本構(gòu)成要素有構(gòu)件、連接件和體系結(jié)構(gòu)配置，可參見圖2.14。

1)構(gòu)件

構(gòu)件是一個計算單元或數(shù)據(jù)存儲，也就是說，構(gòu)件是計算與狀態(tài)存在的場所。在體系結(jié)構(gòu)中，一個構(gòu)件可能小到只有一個過程或大到整個應(yīng)用程序，它可以要求自己的數(shù)據(jù)或執(zhí)行空間，也可以與其他構(gòu)件共享這些空間。作為軟件體系結(jié)構(gòu)構(gòu)造塊的構(gòu)件，其自身也包含了多種屬性，如接口、類型、語義、約束、演化和非功能屬性等。接口是構(gòu)件與外部世界的一組交互點。與面向?qū)ο蠓椒ㄖ械念愓f明相同，ADL中的構(gòu)件接口說明了構(gòu)件提供的服務(wù)(消息、操作、變量)。為了能夠充分地推斷構(gòu)件及包含它的體系結(jié)構(gòu)，ADL提供了能夠說明構(gòu)件需要的工具，這樣，接口就定義了構(gòu)件能夠提出的計算委托及其用途上的約束。

構(gòu)件作為一個封裝的實體，只能通過其接口與外部環(huán)境交互。構(gòu)件的接口由一組端口組成，每個端口表示了構(gòu)件和外部環(huán)境的交互點。通過不同的端口類型，一個構(gòu)件可以提供多重接口。一個端口可以非常簡單，如過程調(diào)用；也可以表示更為復(fù)雜的界面，如必須以某種順序調(diào)用的一組過程調(diào)用。構(gòu)件類型是實現(xiàn)構(gòu)件重用的手段，它保證了構(gòu)件能夠在體系結(jié)構(gòu)描述中多次實例化，并且每個實例可以對應(yīng)于構(gòu)件的不同實現(xiàn)。抽象構(gòu)件類型也可以參數(shù)化，進(jìn)一步促進(jìn)重用?，F(xiàn)有的ADL都將構(gòu)件類型與實例區(qū)分開來。

由于基于體系結(jié)構(gòu)開發(fā)的系統(tǒng)大都是大型、長時間運行的系統(tǒng)，因而系統(tǒng)的演化能力顯得格外重要。構(gòu)件的演化能力是系統(tǒng)演化的基礎(chǔ)。ADL是通過構(gòu)件的子類型及其特性的細(xì)化來支持演化過程的。目前，只有少數(shù)幾種ADL部分地支持演化，對演化的支持程度通常依賴于所選擇的程序設(shè)計語言，其他ADL將構(gòu)件模型看做是靜態(tài)的。

2)連接件

連接件是用來建立構(gòu)件間的交互以及支配這些交互規(guī)則的體系結(jié)構(gòu)構(gòu)造模塊。與構(gòu)件不同，連接件可以不與實現(xiàn)系統(tǒng)中的編譯單元對應(yīng)，它們可能以兼容消息路由設(shè)備實現(xiàn)(如C2)，也可以共享變量、表入口、緩沖區(qū)、對連接器的指令、動態(tài)數(shù)據(jù)結(jié)構(gòu)、內(nèi)嵌在代碼中的過程調(diào)用序列、初始化參數(shù)、客戶服務(wù)協(xié)議、管道、數(shù)據(jù)庫、應(yīng)用程序之間的SQL語句等形式出現(xiàn)。大多數(shù)ADL都將連接件作為第一類實體，也有不將連接件作為第一類實體的ADL。

連接件作為建模軟件體系結(jié)構(gòu)的主要實體，同樣也有接口。連接件的接口由一組角色組成，每一個角色定義了該連接件表示的交互參與者。二元連接有兩個角色，如消息傳遞連接件的角色是發(fā)送者和接收者。有的連接件有多于兩個的角色，如事件廣播有一個事件發(fā)布者角色和任意多個事件接受者角色。

顯然，連接件的接口是一組它與所連接構(gòu)件之間的交互點。為了保證體系結(jié)構(gòu)中的構(gòu)件連接以及它們之間的通信正確，連接件應(yīng)該導(dǎo)出所期待的服務(wù)作為它的接口。連接件能夠推導(dǎo)出軟件體系結(jié)構(gòu)的形成情況。體系結(jié)構(gòu)配置中要求構(gòu)件端口與連接件角色是顯式連接。

體系結(jié)構(gòu)級的通信需要用復(fù)雜協(xié)議來表達(dá)。為了抽象這些協(xié)議并使之能夠重用,ADL應(yīng)該將連接件構(gòu)造為類型。構(gòu)造連接件特性可以把用通信協(xié)議定義的類型系統(tǒng)化并使其獨立于實現(xiàn)，或者作為內(nèi)嵌的、基于它們的實現(xiàn)機制的枚舉類型。為完成對構(gòu)件接口的有用分析，保證跨體系結(jié)構(gòu)抽象層細(xì)化的一致性，強調(diào)互聯(lián)與通信約束等，體系結(jié)構(gòu)描述提供了連接件協(xié)議以及變換語法。為了確保執(zhí)行正確的交互協(xié)議，建立起內(nèi)部連接件依賴關(guān)系，確定用途邊界，就必須說明連接件約束。ADL可以通過強制風(fēng)格不變性來實現(xiàn)約束,或通過接受屬性限制給定角色的服務(wù)。

3)體系結(jié)構(gòu)配置

體系結(jié)構(gòu)配置或拓?fù)涫敲枋鲶w系結(jié)構(gòu)的構(gòu)件與連接件的連接圖。體系結(jié)構(gòu)配置提供信息來確定構(gòu)件是否正確連接、接口是否匹配、連接件構(gòu)成的通信是否正確，并說明實現(xiàn)要求行為的組合語義。體系結(jié)構(gòu)適合于描述大的、生命周期長的系統(tǒng)。利用配置來支持系統(tǒng)的變化，使不同技術(shù)人員都能理解并熟悉系統(tǒng)。為幫助開發(fā)人員在一個較高的抽象層上理解系統(tǒng)，就需要對軟件體系結(jié)構(gòu)進(jìn)行說明。為了使開發(fā)者與有關(guān)人員之間的交流容易些，ADL必須以簡單的、可理解的語法來配置結(jié)構(gòu)化信息。理想的情況是從配置說明中澄清系統(tǒng)結(jié)構(gòu)，即不需研究構(gòu)件與連接件就能使構(gòu)建系統(tǒng)的各種參與者理解系統(tǒng)。體系結(jié)構(gòu)配置說明除文本形式外，有些ADL還提供了圖形說明形式。文本描述與圖形描述可以互換。多視圖、多場景的體系結(jié)構(gòu)說明方法在最新的研究中得到了明顯的加強。為了在不同細(xì)節(jié)層次上描述軟件系統(tǒng)，ADL將整個體系結(jié)構(gòu)作為另一個較大系統(tǒng)的單個構(gòu)件，也就是說，體系結(jié)構(gòu)具有復(fù)合或等級復(fù)合的特性。另一方面，體系結(jié)構(gòu)配置支持采用異構(gòu)構(gòu)件與連接件。這是因為軟件體系結(jié)構(gòu)的目的之一是促進(jìn)大規(guī)模系統(tǒng)的開發(fā)，即傾向于使用已有的構(gòu)件與不同粒度的連接件，這些構(gòu)件與連接件的設(shè)計者、形式模型、開發(fā)者、編程語言、操作系統(tǒng)、通信協(xié)議可能都不相同。另外一個事實是，大型的、長期運行的系統(tǒng)是在不斷增長的，因而，ADL必須支持可能增長的系統(tǒng)的說明與開發(fā)。大多數(shù)ADL提供了復(fù)合特性，所以，任意尺度的配置都可以相對簡潔地在足夠的抽象高度表示出來。我們知道，體系結(jié)構(gòu)設(shè)計是整個軟件生命周期中關(guān)鍵的一環(huán)，一般在需求分析之后、軟件設(shè)計之前進(jìn)行。而形式化的、規(guī)范化的體系結(jié)構(gòu)描述對于體系結(jié)構(gòu)的設(shè)計和理解都是

非常重要的。因此，ADL如何能夠承上啟下將是十分重要的問題，一方面是體系結(jié)構(gòu)描述如何向其他文檔轉(zhuǎn)移，另一方面是如何利用需求分析成果來直接生成系統(tǒng)的體系結(jié)構(gòu)說明?，F(xiàn)有的ADL大多是與領(lǐng)域相關(guān)的，這不利于對不同領(lǐng)域的體系結(jié)構(gòu)進(jìn)行說明。這些針對不同領(lǐng)域的ADL在某些方面又大同小異，造成了資源的冗余。有些ADL可以實現(xiàn)構(gòu)件與連接件的演化，但這樣的演化能力是有限的，這樣的演化大多是通過子類型實現(xiàn)的。盡管現(xiàn)有的ADL都提供了支持工具集，但將這些ADL與工具應(yīng)用于實際系統(tǒng)開發(fā)中的成功范例還很有限。支持工具的可用性與有效性較差，嚴(yán)重地阻礙了這些ADL的廣泛應(yīng)用。

2.4基于體系結(jié)構(gòu)的軟件設(shè)計

2.4.1基于體系結(jié)構(gòu)的設(shè)計模式

1．設(shè)計模式概述

隨著面向?qū)ο蠹夹g(shù)的出現(xiàn)和廣泛使用，一方面軟件的可重用性在一定程度上已經(jīng)有所解決，另一方面對軟件可重用性的要求也越來越高。設(shè)計面向?qū)ο蟮能浖茈y，而設(shè)計可重復(fù)使用的面向?qū)ο蟮能浖y度則更大。開發(fā)人員必須找到適當(dāng)?shù)膶ο?，將它們分解到粒度合適的類、定義類接口和繼承體系，并建立它們之間的關(guān)聯(lián)。在某個時候，設(shè)計師的設(shè)計可能是針對當(dāng)前的具體問題而進(jìn)行的，但應(yīng)該努力使其通用化以適應(yīng)未來的問題和需求。在一個設(shè)計完成之前，有經(jīng)驗的面向?qū)ο蟮脑O(shè)計師往往要重復(fù)設(shè)計若干次，而且每次都要進(jìn)行改進(jìn)。他們知道，不能只用最初的方法解決每個問題，但可以常常重復(fù)使用那些過去用過的解決方案。這些經(jīng)驗正是他們成為專家的法寶，也就是設(shè)計經(jīng)驗的價值。

因此，我們可將設(shè)計面向?qū)ο筌浖慕?jīng)驗記錄成“設(shè)計模式(designpattern)”。每個設(shè)計模式都有系統(tǒng)命名、解釋和評價了的面向?qū)ο笙到y(tǒng)中的一個重要的設(shè)計。我們的目標(biāo)是將設(shè)計經(jīng)驗收集成人們可以有效利用的模型。為此，可以記錄一些最重要的設(shè)計模式，并以目錄的形式表現(xiàn)出來。利用設(shè)計模式可方便地重用成功的設(shè)計和結(jié)構(gòu)。把已經(jīng)證實的技術(shù)表示為設(shè)計模式，使它們更加容易被新系統(tǒng)的開發(fā)者所接受。設(shè)計模式幫助設(shè)計師選擇可使系統(tǒng)重用的設(shè)計方案，避免選擇危害可重用性的方案，它還提供了類和對象接口的明確的說明書和這些接口的潛在意義。

設(shè)計模式的概念最早是由名為ChristopherAlexander的建筑師提出來的，他試圖找到一種結(jié)構(gòu)化、可重用的方法，以在圖紙上捕捉到建筑物的基本要素。逐漸地他的思想影響了軟件研究，并開始流行起來。Alexander提出的模式是指經(jīng)過時間考驗的解決方案，使用此模式可以降低解決問題的復(fù)雜度。在編程時，很多情況下代碼都不是從頭編寫，而是模仿得來的，即從別處搬過來，再經(jīng)過一定改造使之適應(yīng)當(dāng)前情況。設(shè)計模式可以視為這種模仿的一種抽象，包含一組規(guī)則，描述了如何在軟件開發(fā)領(lǐng)域中完成一定的任務(wù)。從這個意義上講，所有的算法都屬于編程領(lǐng)域的設(shè)計模式。面向?qū)ο蟮脑O(shè)計模式用來解決如何在面向?qū)ο筌浖_發(fā)中完成一定的任務(wù)。

在介紹設(shè)計模式的具體定義之前，我們先看一個例子：模型—視圖—控制器(Model-View-Controller，MVC)模式。在開發(fā)人機界面軟件時考慮這種模式。用戶界面承擔(dān)著向用戶顯示問題模型、與用戶進(jìn)行輸入/輸出交互的作用。用戶希望保持交互操作界面的相對穩(wěn)定，但更希望根據(jù)需要改變和調(diào)整顯示的內(nèi)容和形式。例如，要求支持不同的界面標(biāo)準(zhǔn)或得到不同的顯示效果，適應(yīng)不同的操作需求。這就要求界面結(jié)構(gòu)能夠在不改變軟件功能的情況下，支持用戶對界面結(jié)構(gòu)的調(diào)整。要做到這一點，從界面構(gòu)成的角度看，困難在于：在滿足對界面要求的同時，如何使軟件的計算模型獨立于界面的構(gòu)成。MVC就是這樣的一種交互界面的結(jié)構(gòu)組織模型。對于界面設(shè)計可變性的需求，MVC把交互系統(tǒng)的組成分解成模型、視圖、控制三種構(gòu)件。其中模型構(gòu)件獨立于外在顯示內(nèi)容和形式，是軟件所處理的問題邏輯的內(nèi)在抽象，它封裝了問題的核心數(shù)據(jù)、邏輯和功能的計算關(guān)系，獨立于具體的界面表達(dá)和輸入/輸出操作；視圖構(gòu)件把表示模型數(shù)據(jù)及邏輯關(guān)系和狀態(tài)的信息以特定形式展示給用戶，它從模型獲得顯示信息，對于相同的信息可以有多個不同的顯示形式或視圖；控制構(gòu)件處理用戶與軟件的交互操作，其職責(zé)是決定軟件的控制流程，確保用戶界面與模型間的對應(yīng)聯(lián)系，它接收用戶的輸入，將輸入反饋給模型，進(jìn)而實現(xiàn)對模型的計算控制，它是使模型和視圖協(xié)調(diào)工作的部件。模型、視圖與控制器的分離，使得一個模型可以具有多個顯示視圖。如果用戶通過某個視圖的控制器改變了模型的數(shù)據(jù)，所有其他依賴于這些數(shù)據(jù)的視圖都應(yīng)反映出這些變化。因此，無論何時發(fā)生了何種數(shù)據(jù)變化，控制器都會將變化通知給所有的視圖，導(dǎo)致顯示的更新。

圖2.17所示的對象模型技術(shù)類圖描述了MVC解決方案。圖2.17MVC解決方案從圖2.17中我們可以導(dǎo)出軟件體系結(jié)構(gòu)模式的屬性：一個模式關(guān)注一個在特定設(shè)計環(huán)境中出現(xiàn)的設(shè)計問題，并為它提供一個解決方案。在我們的例子中，問題是支持用戶界面的可變性。開發(fā)人機交互軟件系統(tǒng)時，這個問題就會出現(xiàn)。

所謂設(shè)計模式，簡單地理解，就是一些設(shè)計面向?qū)ο蟮能浖_發(fā)的經(jīng)驗總結(jié)。一個設(shè)計模式事實上是系統(tǒng)地命名、解釋和評價某一個重要的可重現(xiàn)的面向?qū)ο蟮脑O(shè)計方案。正如Alexander所說：“每一個模式都描述了一個在我們身邊一再發(fā)生的問題，它告訴我們這個問題的解的關(guān)鍵，以使我們可以成千上萬次地利用這個解，而不需要再一次去重新解它。”盡管Alexander所說的是有關(guān)建筑和城鎮(zhèn)的模式，但它同樣適用于面向?qū)ο蟮脑O(shè)計模式，只不過要解決的問題是軟件開發(fā)中一再出現(xiàn)的問題。受到普通認(rèn)可的設(shè)計模式的定義是由DirkRiehle和HeinzZullighoven給出的：“模式是指從某個具體的形式中得到的一種抽象，在特殊的非任意性的環(huán)境中，該形式不斷地重復(fù)出現(xiàn)?！?/p>

模式的概念是“隨設(shè)計中要解決的問題的變化而變化的”。更明確地說，重復(fù)發(fā)生的具體形式就是這一重復(fù)出現(xiàn)的問題的解。但是一個模式又并不僅僅是具體問題的解，因為具體問題是在一個特殊的環(huán)境中發(fā)生的，因此有很多復(fù)雜的考慮因素。給定一個環(huán)境后，所提出的問題包含了一些平衡各方面考慮的結(jié)構(gòu)，或稱為“權(quán)衡”。使用模式的形式，解決方案的描述可以把握住方案所體現(xiàn)的本質(zhì)，故而別人可以從中學(xué)到一些東西，進(jìn)而在相似的情況下可以進(jìn)行應(yīng)用。每個模式都有一個名字，幫助我們討論模式和它所給出的信息。綜上所述，我們認(rèn)為，一個軟件體系結(jié)構(gòu)的模式描述了一個出現(xiàn)在特定設(shè)計語境中的特殊的再現(xiàn)設(shè)計問題，并為它的解決提供了一個經(jīng)過充分驗證的通用方案。解決方案通過描述其組成構(gòu)件及其責(zé)任和相互關(guān)系以及它們的協(xié)作方式來具體指定。

一個好的模式必須做到以下幾點。

●解決一個問題：從模式可以得到解，而不僅僅是抽象的原則或策略。

●是一個被證明了的方案：模式通過一個記錄得到解，而不是通過理論或推測。

●解并不是顯然的：許多解決問題的方法(比如軟件設(shè)計范例或方法)是從最基本的原理得到解；而還有一些是以非直接的方式得到解。●描述了一種關(guān)系：模式并不僅僅描述模塊，它給出了更深層的系統(tǒng)結(jié)構(gòu)和機理。

●模式有重要的人為因素：所有的軟件服務(wù)于人類的舒適或生活質(zhì)量，而最好的模式追求它的實用性和美學(xué)。

關(guān)于設(shè)計模式，目前的研究方向主要有：設(shè)計模式與其他面向?qū)ο笤O(shè)計方法(如特定領(lǐng)域的框架)的關(guān)系，它們各自的優(yōu)劣和適應(yīng)范圍。除此而外，人們還在各個方面總結(jié)設(shè)計模式(如通信等領(lǐng)域)，并研究如何讓設(shè)計模式的使用更加自動化等。關(guān)于設(shè)計模式還有很多工作要做，而且它并不是一個只要看一遍就能掌握的方法。在工作中要不斷總結(jié)、不斷回顧以前使用過的設(shè)計模式。不同的模式之間有聯(lián)系，同時也有各自的優(yōu)缺點，在應(yīng)用中要注意仔細(xì)考慮、權(quán)衡利弊、加以取舍，只有這樣才可能真正用好設(shè)計模式。

2．設(shè)計模式的組成

1)設(shè)計模式的基本成分

一般來說，一個模式有以下四個基本成分：

(1)模式名稱。模式名稱通常用來描述一個設(shè)計問題及其解法和結(jié)果，由一到兩個詞組成。模式名稱的產(chǎn)生使我們可以在更高的抽象層次上進(jìn)行設(shè)計并交流設(shè)計思想，因此，尋找好的模式名稱是一個很重要也很困難的工作。

(2)問題。問題告訴我們什么時候要使用設(shè)計模式、解釋問題及其背景。例如，模型—視圖—控制器模式關(guān)心用戶界面經(jīng)常變化的問題，它可能描述諸如如何將一個算法表示成一個對象這樣的特殊設(shè)計問題。在應(yīng)用這個模式之前，也許還要給出一些該模式的適用條件。模式的問題陳述用一個強制條件(force)集來表示。force最初是從建筑學(xué)和Alexander那里借用來的，模式組織使用術(shù)語“強制條件”來說明問題要解決時應(yīng)該考慮的各個方面，例如：

●解決方案必須滿足的需求，如對等進(jìn)程間通信必須是高效的。

●必須考慮的約束，如進(jìn)程間通信必須遵循特定協(xié)議。

●解決方案必須具有的期望特性，如軟件更改應(yīng)該是容易的。●模型一視圖一控制器模式指出了它的強制條件：用戶界面必須易于修改，但軟件的核心功能不能被修改所影響。一般地，強制條件從多個角度討論問題并有助于設(shè)計師了解它的細(xì)節(jié)，它可以相互補充或相互矛盾。例如，系統(tǒng)的可擴展性與代碼的最小化構(gòu)成了兩個相互矛盾的強制條件。如果希望系統(tǒng)可擴展，那么就應(yīng)傾向于使用抽象超類；如果想使代碼最小化(例如用于嵌入式系統(tǒng))，就不能承受抽象超類的“奢侈”。但更重要的是，強制條件是解決問題的關(guān)鍵，它們平衡得越好，對問題的解決方案就越好。所以，強制條件的詳細(xì)討論是問題陳述的重要部分。

(3)解決方案。解決方案描述設(shè)計的基本要素、它們的關(guān)系、各自的任務(wù)以及相互之間的合作。解決方案并不是針對某一個特殊問題而給出的。設(shè)計模式提供有關(guān)設(shè)計問題的一個抽象描述以及如何解決問題。一個模式就像一個可以在許多不同環(huán)境下使用的模板，抽象的描述使我們可以把該模式應(yīng)用于解決許多不同的問題。

模式的解決方案部分給出了如何解決問題，或者更恰當(dāng)?shù)卣f是如何平衡與之相關(guān)的強制條件。在軟件體系結(jié)構(gòu)中，這樣的解決方案包括兩個方面。

●每個模式規(guī)定了一個特定的結(jié)構(gòu)，即元素的一個空間配置。例如，MVC模式的描述包括以下語句：“把一個交互應(yīng)用程序劃分成三部分：處理、輸入和輸出。”●每個模式規(guī)定了運行期間的行為。例如，MVC模式的解決方案部分包括以下陳述：“控制器接收輸入，而輸入往往是鼠標(biāo)移動、單擊鼠標(biāo)按鍵或鍵盤輸入等事件。事件轉(zhuǎn)換成服務(wù)請求，這些請求再發(fā)送給模型或視圖。”

值得注意的是：解決方案不必解決與問題相關(guān)的所有強制條件，可以僅僅集中于特殊的強制條件，而對于剩下的強制條件進(jìn)行部分解決或完全不解決，特別是在強制條件相互矛盾時。

(4)結(jié)果。結(jié)果描述應(yīng)用設(shè)計模式后的結(jié)果和權(quán)衡，比較與其他設(shè)計方法的異同，得到應(yīng)用設(shè)計模式的代價和優(yōu)點。對于軟件設(shè)計來說，通常要考慮的是空間和時間的權(quán)衡，也會涉及語言問題和實現(xiàn)問題。對于一個面向?qū)ο蟮脑O(shè)計而言，可重用性很重要，結(jié)果還包括對系統(tǒng)靈活性、可擴充性及可移植性的影響。

另外，不同的觀點會影響人們對什么是設(shè)計模式的解釋。某一個人的模式對另一個人來說可能只是一個基本的構(gòu)造塊。這里把設(shè)計模式處理到一定的抽象程度，它不用于直接編碼或類重用，也不是復(fù)雜到可作為一個完整的應(yīng)用或子系統(tǒng)的領(lǐng)域?qū)Ｓ迷O(shè)計，而是對一定的對象與類的關(guān)系進(jìn)行描述，進(jìn)而可對其進(jìn)行一定程度的修改，解決在一定條件下的通用設(shè)計問題。設(shè)計模式命名、抽象并確定了一個普遍的設(shè)計結(jié)構(gòu)，有助于得到可重用的面向?qū)ο蟮脑O(shè)計，還確定了參與的類和實例、它們的地位和協(xié)作以及責(zé)任的分配。每一個設(shè)計模式都集中于特定的面向?qū)ο笤O(shè)計問題，描述了何時使用、是否能在其他設(shè)計約束條件下使用及使用后的結(jié)果和折中。

2)設(shè)計模式的描述

如果我們要理解和討論模式，就必須以適當(dāng)形式描述模式。好的描述有助于我們立即抓住模式的本質(zhì)，即模式關(guān)心的問題是什么，以及提出的解決方案是什么。

模式也應(yīng)該以統(tǒng)一的方式來描述，這有助于我們對模式進(jìn)行比較，尤其在我們?yōu)橐粋€問題尋求可選擇的解決方案時。那么，如何描述一個設(shè)計模式呢?僅僅依靠圖示的方法是不夠的。盡管圖示的方法很重要也很有用，但它們只能把設(shè)計的最終結(jié)果表示成一些類和對象的關(guān)系。事實上，為了重用該設(shè)計，我們還應(yīng)該記錄產(chǎn)生這個設(shè)計的決策和權(quán)衡過程。具體的實例也很重要，從中可以看到設(shè)計模式的運轉(zhuǎn)過程。模式概念的創(chuàng)始者Alexander采用下面的格式來描述設(shè)計模式：

IFyoufindyourselfinCONTEXT

ForexampleEXAMPLES,

WithPROBLEM

EntailingFORCESS

THENforsomeREASONS,

ApplyDESIGNFORMAND/ORRULE

ToconstructSOLUTION

LeadingtoNEWCONTEXTandOTHERPATTERNS

ErichGamma等人采用下面的固定模式來描述，這也是目前最常用的格式。

●模式名稱和分類：模式名稱和一個簡短的摘要。

●目的：回答下面的問題，即本設(shè)計模式的用處，它的基本原理和目的，它針對的是什么特殊的設(shè)計問題。

●別名：由于設(shè)計模式的提取是由許多專家得到的，同一個模式可能會被不同的專家冠以不同的命名。

●動機：描述一個設(shè)計問題的方案，以及模式中類和對象的結(jié)構(gòu)是如何解決這個問題的。

●應(yīng)用：在什么情況下可以應(yīng)用本設(shè)計模式，如何辨認(rèn)這些情況?！窠Y(jié)構(gòu)：用對象模型技術(shù)對本模