軟件體系結(jié)構(gòu)建模——UML與設(shè)計模式主講教師：張立人前言：什么是軟件體系結(jié)構(gòu)？1.

從“體系結(jié)構(gòu)”的英文單詞理解它的含義architecture(建筑、建筑學)是最古老的藝術(shù)之一，也是一門最古老的工程學科，它研究建筑的風格、建筑的組成元素、這些元素的組織結(jié)構(gòu)以及之間的相互關(guān)系。同樣，體系結(jié)構(gòu)研究和描述系統(tǒng)元素的結(jié)構(gòu)規(guī)劃，包括它們?nèi)绾位ハ噙m應(yīng)、如何協(xié)作，以滿足系統(tǒng)的需求。很難給出軟件體系結(jié)構(gòu)的定義，因為不能描述出，對于不同領(lǐng)域和不同規(guī)模的系統(tǒng)，哪些設(shè)計細節(jié)是重要的。2.

軟件體系結(jié)構(gòu)在軟件開發(fā)中的地位體系結(jié)構(gòu)連接了系統(tǒng)需求和實現(xiàn)，它處在領(lǐng)域分

析、需求分析、風險分析之后，而在詳細設(shè)計、編碼、集成和測試之前。通過對一大批軟件產(chǎn)品開發(fā)的觀察，得出結(jié)論，一個產(chǎn)品是否成功，一個重要因素是，是否擁有能被投資者和開發(fā)小組成員很好理解的（在適當細節(jié)層次上）、好的軟件體系結(jié)構(gòu)。盡管擁有一個好的體系結(jié)構(gòu)并不能保證產(chǎn)品符合需求，但設(shè)計不當?shù)幕蛘叨x錯誤的體系結(jié)構(gòu)是絕對不能使產(chǎn)品滿足需求的。3.

軟件體系結(jié)構(gòu)的特點軟件體系結(jié)構(gòu)是指一個系統(tǒng)的有目的的設(shè)計和規(guī)劃，這個設(shè)計規(guī)劃既不描述活動，也不描述如何開發(fā)產(chǎn)品，它只描述系統(tǒng)的組成元素及其相互的交互、協(xié)作。軟件的不可見性容易導致軟件體系結(jié)構(gòu)的隱含性，于是很多人不重視軟件體系結(jié)構(gòu)，很少有軟件專業(yè)人

員認真評價軟件體系結(jié)構(gòu)的健壯性和質(zhì)量。軟件體系結(jié)構(gòu)是一種幫助管理復(fù)雜性的抽象化的工具，所以，它應(yīng)該以相對較粗的粒度定義并描述系統(tǒng)元素，應(yīng)該描述元素如何滿足系統(tǒng)需求，包括哪些元素為哪些功能負責、它們之間如何交互、它們與外界如何交互以及對運行平臺的依賴性。通過對大量軟件項目的體系結(jié)構(gòu)的研究，發(fā)現(xiàn)它

們有著一些共性和規(guī)則，這就是：包含截然不同的視

圖。有的專家把這些視圖歸納為概念視圖、模塊視圖、執(zhí)行視圖和代碼視圖。概念視圖和應(yīng)用領(lǐng)域的聯(lián)系最

為緊密，在概念視圖中，問題和解決方案主要是通過

領(lǐng)域術(shù)語來考慮的。模塊視圖中，系統(tǒng)被劃分為子系

統(tǒng)和模塊，強調(diào)的是如何用現(xiàn)有的軟件平臺以及技術(shù)

來實現(xiàn)概念視圖中的解決方案。執(zhí)行視圖中，模塊被映射為運行時平臺所提供的元素，比如內(nèi)存的使用和硬件的分配，強調(diào)的是運行平臺的控制流。代碼視圖中，要決定執(zhí)行視圖中的運行實體如何映射為部署構(gòu)件（例如，可執(zhí)行構(gòu)件），要決定模塊視圖中的模塊如何映射為源文件。執(zhí)行視圖和代碼視圖之間有一個松散的連接，一個執(zhí)行視圖中的運行時刻實體在代碼視圖中通常有一個對應(yīng)的文件，但并不是任何一個運行時刻實體都有對應(yīng)文件，例如線程。一個軟件體系結(jié)構(gòu)的架構(gòu)過程中，盡管架構(gòu)師沒有明確地把體系結(jié)構(gòu)視為不同的視圖，但實際上他已經(jīng)使用了這些視圖。使用這些視圖的原因是：把系統(tǒng)分解為不同的視圖，可以幫助人們管理復(fù)雜的系統(tǒng)。因此，在我們的開發(fā)實踐中，有意識地、按順序地

運用這些視圖，可以幫助我們有條不紊地組織開發(fā)

過程。以上視圖的劃分方法適合應(yīng)用于大型企業(yè)信息

系統(tǒng)的體系結(jié)構(gòu)架構(gòu)過程。從我們的主要需要出發(fā)，我們將使用一種簡化了的視圖劃分方法，既只把體

系結(jié)構(gòu)劃分為概念領(lǐng)域和系統(tǒng)領(lǐng)域兩種視圖，我們

以后的開發(fā)實例將按照這兩種領(lǐng)域的順序來建立體

系結(jié)構(gòu)。相關(guān)術(shù)語軟件體系結(jié)構(gòu)風格（例如管道、過濾器）設(shè)計模式：設(shè)計模式有時和體系結(jié)構(gòu)相關(guān)，有時和詳細設(shè)計相關(guān)，區(qū)別的方法是看它是描述體系結(jié)構(gòu)元素之間的交互，還是描述體系結(jié)構(gòu)元素內(nèi)部的結(jié)構(gòu)與交互。軟件體系結(jié)構(gòu)描述語言ADL（例如UML）第一部分

UML及其應(yīng)用實例第一章UML簡介在本章中，你將學習如下內(nèi)容：為什么需要UML??UML的誕生。各種UML圖。為什么使用UML提供的不同類型的圖對我們來說很重要?UML(Unified

Modeling

Language，統(tǒng)一建模語言)是一種可視化的建模語言，它能讓系統(tǒng)構(gòu)造者用標準的、易于理解的方式建立起能夠表達出他們想象力的系統(tǒng)藍圖，并且提供了便于不同的人之間有效地共享和交流設(shè)計結(jié)果的機制。交流思想是極為重要的。在UML出現(xiàn)以前，系統(tǒng)開發(fā)往往是無計劃的議題。系統(tǒng)分析員盡力去獲取客戶的需求，用某種他自己能夠理解(但客戶不一定總能理解)的表示法來產(chǎn)生需求分析文檔，然后將這個分析轉(zhuǎn)交給—個程序員或者一個程序員小組，并且期待著最后所開發(fā)出的系統(tǒng)正是客戶所需要的。由于系統(tǒng)開發(fā)是—項人力活動，因此在開發(fā)過程

的每個階段中都很可能潛伏著錯誤。系統(tǒng)分析員可能

沒有正確理解客戶的需求。他編制的文檔存戶可能不

能理解。系統(tǒng)分析的結(jié)果對程序員來說可能很不明確，隨后程序員據(jù)此構(gòu)造出的程序很可能不僅難以使用而

且根本不是客戶所需要的最初問題的解決方案。1.1

在紛繁復(fù)雜中尋求解決問題的辦法在計算機時代的早期，程序員們在編制程序之前幾乎很少對手頭問題進行詳細的分析。通常他們一開始就自底向上地編寫程序，隨著時間的進展代碼不斷擴充。在今天這樣一個高商業(yè)風險的社會里，這樣做被證明是不適當?shù)摹ｋS著世界變得越來越復(fù)雜，存在于這個世界中的基于計算機的系統(tǒng)也增加了復(fù)雜性。這些計算機系統(tǒng)通常包括多個硬件和軟件單元、跨越長距離的網(wǎng)絡(luò)設(shè)施，還要連接到信息量堆積如山的數(shù)據(jù)庫上。如果你要創(chuàng)建一個成功的系統(tǒng)，怎么來對付這些問題的復(fù)雜性呢?最關(guān)鍵的一點是要用一種系統(tǒng)分析員、客戶、程序員和其他系統(tǒng)開發(fā)所涉及到的人員之間能夠照解和達成一致的方式來組織系統(tǒng)的設(shè)計過程。UML就提供了這種組織方式。如今，一個經(jīng)過深思熟慮的計劃至關(guān)重要。客戶必須理解開發(fā)組做什么，如果開發(fā)組沒有充分理解客戶需求的話(或者如果客戶在半路改變了自己的想法)，客戶必須能夠指出需求所發(fā)生的變化。不儀如此，系統(tǒng)開發(fā)還是一個典型的群組工作，因此小組的每個成員必須要知道自己的那部分作品應(yīng)該放到整體作品中的哪個位置。通過使用UML，所有和系統(tǒng)有關(guān)的人們都能滿足自己的要求。短的開發(fā)周期是當今系統(tǒng)開發(fā)的又一個顯著特征。當所要求的截止日期一個又一個地接踵而來時，可靠

的系統(tǒng)設(shè)計是絕對必要的。可靠的設(shè)計需要一種能被系統(tǒng)分析員、開發(fā)人員和客戶接受為標準的設(shè)計表示法，就象電子工程師在繪制電路圖時所用的標準表示法和在機械工程中被作為標準的三視圖所用的表示法那樣。UML就是軟件開發(fā)領(lǐng)域的這種表示法。1.2 UML的誕生UML是GradyBooch、James

Rumbaugh和IvarJacobson智慧的結(jié)晶。他們被人們稱為“三個好朋友”。這幾位先生在20世紀80年代和90年代的初期分別在不同的組織里工作，各自設(shè)計他們自己的面向?qū)ο蠓治雠c設(shè)計方法學。他們的方法學和其他同行競爭者相比取得了卓越的成果。到90年代中期，他們開始相互借鑒，然后決定相互合作共同推進這項工作。1994年，Rumbaugh加入到Ratinoal軟件公司工作，而Booch早已經(jīng)在那里工作。第二年Jacobson也加入了

Rational公司的行列。后面的事情，是具有歷史意義的。

UML草案版開始在軟件工業(yè)界流傳開來，并且根據(jù)大

量的反饋信息做了大幅度修改。由于許多公司感到

UML能夠適應(yīng)這些公司的戰(zhàn)略目標，因此一個UML聯(lián)盟蓬勃發(fā)展起來。聯(lián)盟的成員包括DEC、Hewlett-Packard、Intellicorp、Microsoft、OracIe、Rational和其他—些公司。1997年，應(yīng)“對象管理組織”(OMG)向外界征求標準建模語言的建議，聯(lián)盟制訂了UML1.0版并提交給OMG。后來聯(lián)盟繼續(xù)發(fā)展，產(chǎn)生了UML1.1版，提交給

OMG后，于1997年被OMG采納為標準。1998年OMG接管了UML標準的維護工作，并且又制訂了兩個新

的UML修訂版。UML成為軟件工業(yè)界事實上的標準，并且仍在不斷發(fā)展。現(xiàn)在UML已經(jīng)到了1.3版。1.3 UML的組成UML包括了一些可以相互組合圖表的圖形元素。由于UML是一種話言，所以UML具有組合這些元素的語法規(guī)則。這里先不介紹這些元素和規(guī)則，而是直接介紹UML各種圖的用法，因為這些圖是進行系統(tǒng)分析時要用到的。UML提供這些圖的目的是用多個視圖來展示一個系統(tǒng)，這組視圖被稱為一個模型(model)。一個系統(tǒng)的UML模型有點像一個建筑物按照比例縮小并經(jīng)藝術(shù)家粉飾后的建筑模型。在這里要注意的重要一點是一個UML模型只描述了一個系統(tǒng)要做什么，它并沒告訴我們系統(tǒng)是如何被實施的。在科學和工程技術(shù)領(lǐng)域中模型是一個很有用途的概念。在最通常的意義下，當你建立了一個模型后，你其實就在運用你已經(jīng)了解的很多知識來幫助你理解暫時還不知道的很多東西。在某些領(lǐng)域中，一個模型可能是一組數(shù)學方程式；而在另一些領(lǐng)域中，一個模型可能是計算機仿真程序。模型可能有許多種類型。就我們的目的而言，一個模型是一組UML圖，為了理解和開發(fā)一個系統(tǒng)，我們可以檢查、獲取和修改這些圖。1.3.1

類圖事物很自然地都有其各自所屬的種類(汽車、家具、洗衣機……)。我們把這些種類稱為類。一個類是一類或者一組具有類似屬性和共同行為的事物。舉一個例子，屬于洗衣機(Washing

machine)類的事物都具有諸如品牌(brand

name)、型號(model

name)、序列號(serial

number)和容量(capacity)等屬性。這類事物的行為包括“加衣物(add

clothes)”、“加洗滌劑(adddetergent)”、“開機(turn

on)”和“取出衣物(remove

clothes)”等操作。下圖是一個用UML表示法表示的洗衣機屬性和行為的一個例子。矩形方框代表類的圖標，它被分成3個區(qū)域。最上面的區(qū)域中是類名，中間區(qū)域是類的屬性，最下面區(qū)域里列的是類的操作。類圖就是由這些類框和表明類之間如何關(guān)聯(lián)的連線所組成。類圖的重要意義：1.為了與我們所處的這個復(fù)雜世界進行交互，大部分現(xiàn)代軟件都模擬現(xiàn)實世界的某些方面。幾十年的經(jīng)驗告訴我們，當軟件代表了現(xiàn)實世界中的事物的類時采用這種模擬方式開發(fā)軟件最容易。類圖就能為開發(fā)人員提供這種模仿現(xiàn)實世界的表達方式。2.類圖對系統(tǒng)分析也有很大幫助。它可以讓分析員使用客戶所采用的術(shù)語和客戶交流，這樣就可以促使客戶說出所要解決的問題的重要細節(jié)。1.3.2

對象圖對象是一個類的實例，是具有具體屬性值和行為的一個具體事物。下圖說明了如何用UML來表示對象。注意對象的圖標也是個矩形，和類的圖標一樣，但是對象名下面要帶下劃線。具體實例的名字位于冒號的左邊而該實例所屬的類名位于冒號的右邊。1.3.3

用例圖用例(usecase)是從用戶的觀點對系統(tǒng)行為的一個描述。對于系統(tǒng)開發(fā)人員來說，用例是一個有價值的工具：它是用來從用戶的觀察角度收集系統(tǒng)需求的靠得住的一項技術(shù)。這對于那些試圖建立一個由人使用的(而不是計算機設(shè)備使用的)系統(tǒng)是很重要的。我們后面還要詳細討論用例。這里先舉一個簡單的例子。你使用一臺洗衣機，顯然是為了洗衣服(washclothes)。下圖說明了如何用UML用例圖來描述這個需求。代表洗衣機用戶的直立小人形被稱為參與者

(actor)。橢圓形代表用例。注意參與者(它是發(fā)起用例的實體)可以是一個人也可以是另一個系統(tǒng)。1.3.4

狀態(tài)圖在任一給定的時刻，一個對象總是處于某一特定的狀態(tài)。一個人可以是新生兒、嬰兒、兒童、少年、青年或者成人。一個電梯可以處于上升、停止或下降狀態(tài)。一臺洗衣機可以處于浸泡(soak)、洗滌(Wash)、漂洗(Rinse)、脫水(Spin)或者關(guān)機(off)狀態(tài)。表示洗衣機狀態(tài)的UML狀態(tài)圖如下圖所示，該圖能夠描述上面所提及的狀態(tài)，并且說明洗衣機可以從一個狀態(tài)轉(zhuǎn)移到另一個狀態(tài)。在上圖中，最頂端的符號代表起始狀態(tài)，而最底端的符號表示終止狀態(tài)。1.3.5

順序圖類圖和對象圖表達的是系統(tǒng)的靜態(tài)結(jié)構(gòu)。在一個運行的系統(tǒng)中，對象之間要發(fā)生交互，并且這些交互要經(jīng)歷一定的時間。UML順序圖所表達的正是這種基于時間的動態(tài)交互。仍以洗衣機為例，洗衣視的構(gòu)件包括一個注水的進水管(Water

Pipe)、一個用來裝衣物的洗滌缸

(Drum)及一個排水管(Drain)。當然，這些構(gòu)件也是對象(以后你將會看到，一個對象之中還可以包含其他對象)。當“洗衣服”這個用例被執(zhí)行時，將會依次發(fā)生什么事情呢?假設(shè)你已經(jīng)完成了“加衣物”、“加洗滌劑”和“開機”操作，那么步騾應(yīng)按照如下順序進行：通過進水管向洗滌缸中注水。洗滌缸保持5分鐘靜止狀態(tài)。水注滿．停止注水。洗滌缸往返旋轉(zhuǎn)15分鐘。通過排水管排掉洗滌后的臟水。重新開始注水。洗滌缸繼續(xù)往返旋轉(zhuǎn)洗滌。停止向洗衣機中注水。通過排水管排掉漂洗衣物的水。洗滌缸加快速度單方向旋轉(zhuǎn)5分鐘。洗滌缸停止旋轉(zhuǎn)，洗衣過程結(jié)束。下圖用一個順序圖說明了進水管、洗滌缸和排

水管(由順序圖頂端的矩形圖標代表)之間隨時間變化所經(jīng)歷的交互過程。在此圖中，進程是從上到下的。1.3.6

活動圖用例和對象的行為中的各個活動之間的時間順序還可用活動圖來表達，下圖顯示了“洗衣物”用例中步驟4到步驟6之間按順序的UML活動圖。1.3.7

協(xié)作圖系統(tǒng)的工作目標是由系統(tǒng)中各組成元素相互協(xié)

作完成的，建模語言必須具備這種協(xié)作關(guān)系的表達

方式。UML協(xié)作圖就是為此目的設(shè)計的，下圖是協(xié)作圖的一個例子。在這個例子中，洗衣機構(gòu)件的類集中又增加了一個內(nèi)部計時器(Internal

timer)。在經(jīng)過某一段時間后，定時器停止注水，然后啟動洗滌缸往返旋轉(zhuǎn)。圖中的序號代表命令消息的發(fā)送順序，計時器對象先向洗滌缸對象發(fā)送往返旋轉(zhuǎn)(Rotatebackandforth)消息，后向進水管對象發(fā)送停止注水(Stop)消息。1.3.8

構(gòu)件圖構(gòu)件圖和部署圖與整個計算機系統(tǒng)密切相關(guān)。現(xiàn)代軟件開發(fā)是基于構(gòu)件的，這種開發(fā)方式對群組開發(fā)尤為重要。這里不對此做詳細介紹，僅用下圖來說明如何用UML表示軟件構(gòu)件。1.3.9

部署圖UML部署圖顯示了基于計算機系統(tǒng)的物理體系結(jié)構(gòu)。它可以描述計算機和設(shè)備，展示它們之間的連接，以及駐留在每臺機器中的軟件。每臺計算機用一個立方體來表示，立方體之間的連線表示這些計算機之間的通信關(guān)系。下圖是部署圖的一個例子。1.4

其它特征UML提供了一些用來組織和擴展模型圖的特征。1.4.1

包有時你可能需要將圖中的組織元素分組。或者你想在你的圖中說明一些類或構(gòu)件是某個特定子系統(tǒng)的一部分。可以通過將這些元素組織成包

(package)來達到此目的。包用一邊突起的公文夾形圖標來表示，如下圖所示。1.4.2

注釋有時圖中的某—部分都會給出明確的解釋。此時UML注釋(note)很有用。可以把注釋看成是圖形化的黃頁。注釋的圖標是一個帶折角的矩形。矩形框中是解釋性文字。下圖是注釋的一個例子。注釋和被注釋的圖元素之間用一條虛線連接。1.4.3

構(gòu)造型UML提供了很多有用的項，但絕不是一個完全徹底的模型元素集。有時你所設(shè)計的系統(tǒng)需要對某個項目進行裁制。構(gòu)造型(stereotype)使你能夠使用現(xiàn)有的UML元素來定制新的元素。這有點像你從貨架中買了一套衣服然后再把這套衣服裁剪成你所需要的尺寸(而不是買—堆布料從頭開始制作)。構(gòu)造型用兩對括號括起來的一個名稱來表示，這個括號叫做雙尖括號。然后就可以在需要的地方使用這個被括起來的名稱。接口這個概念是使用構(gòu)造型的一個好例子。接口(interface)是一個沒有屬性而只有操作的類。它是可以在整個模型中反復(fù)使用的一組行為。無需