軟件工程課件：構(gòu)架為中心

構(gòu)架為中心10.1構(gòu)架概述10.2為什么需要構(gòu)架10.3用例和構(gòu)架10.4建立構(gòu)架的步驟10.5構(gòu)架描述10.6建立軟件構(gòu)架：考勤系統(tǒng)實例研究10.7小結(jié)習題10

知識點

構(gòu)架，用例和構(gòu)架的關(guān)系，建立構(gòu)架的步驟，構(gòu)架描述。

難點

如何將理論與實踐結(jié)合。

基于工作過程的教學任務(wù)

通過本章學習，領(lǐng)會為什么需要構(gòu)架，掌握構(gòu)架的基本概念；理解用例和構(gòu)架的關(guān)系，掌握建立構(gòu)架的步驟；學習構(gòu)架描述，理解用例模型、設(shè)計模型、實施模型、實現(xiàn)模型的構(gòu)架視圖；以考勤系統(tǒng)實例研究為例，了解建立軟件構(gòu)架的過程。

開發(fā)軟件系統(tǒng)只靠用例是不夠的，要得到一個可用的系統(tǒng)還需要考慮——構(gòu)架。可以把系統(tǒng)構(gòu)架看作是所有工作人員(即開發(fā)人員和其他項目相關(guān)人員)必須達成或至少能夠接受的共同目標，構(gòu)架提供了整個系統(tǒng)的、清晰的視點，可以很好地控制系統(tǒng)的開發(fā)。

把開發(fā)一個軟件項目和建造一座能停放一輛汽車的車庫進行比較。首先，施工人員需要考慮用戶希望怎樣使用車庫，其中需要能遮蔽汽車的用例，即要能把車駛?cè)?、停放在里面，然后又能把車開出來。用戶是否還想把車庫用作其他用途呢？假如還希望把車庫用作一個家用工作間，那么施工人員就得考慮采光要求—要設(shè)計幾扇窗戶和幾盞電燈；許多工具都需要用電，因此，還要設(shè)計幾個電源插座并提供足夠的電量。從某種意義上講，施工人員是在創(chuàng)建一個簡單的構(gòu)架。

要建造一所具有10個房間的房子、一座教堂、一家購物中心或一幢摩天大樓，情況就很不一樣?，F(xiàn)在有許多建造大型建筑的方法，需要建筑設(shè)計師來設(shè)計；設(shè)計組成員需要相互了解構(gòu)架的進度，也就是說他們需要把自己的工作用其他組員能夠明白的形式記錄下來；還要用一種非專業(yè)人員(業(yè)主、用戶和其他項目相關(guān)人員)可以理解的方式表示出來；

最后，還得通過施工圖紙將構(gòu)架告知建筑商和建材供應(yīng)商。

開發(fā)構(gòu)架需要大量的時間。經(jīng)驗表明：有一個好的構(gòu)架作指導，后面的階段會大大縮短整個開發(fā)周期，對大型項目尤其重要。因此，在開發(fā)工作的初期階段就得到一個穩(wěn)定的構(gòu)架是至關(guān)重要的。

10.1構(gòu)架概述

構(gòu)架很重要，那么，“軟件系統(tǒng)構(gòu)架”到底是指什么呢？當人們探究軟件構(gòu)架的概念時，不禁會想起盲人摸象的寓言故事。大象只是每個盲人偶然間摸到的一條大蛇(大象鼻子)、一根粗繩(大象尾巴)或一棵小樹(大象腿)。與此類似，構(gòu)架的概念，就像寓言中所說的一樣。

如果仍把軟件構(gòu)架比作房屋建筑。在客戶看來，一座建筑通常是一個單一的單元；建筑設(shè)計師發(fā)現(xiàn)制作一座建筑的比例模型，加上幾幅不同視角的建筑圖紙會更有用處，這些圖紙一般都是簡圖，卻能讓客戶看懂。

但是，建筑物的修建在施工階段還需要其他工種的工作者，如木工、小工、泥瓦匠、吊頂工、水管工、電工等。他們需要更詳細和專門的建筑施工圖紙，而且在這些圖紙之間必須保持一致。

例如，通風管和水管就不能標定在同一位置。建筑設(shè)計師的職責就是創(chuàng)建整個建筑物設(shè)計中最重要的方面。因此，建筑設(shè)計師繪制出一套描述建筑物方方面面的建筑圖紙，如挖掘的地基。結(jié)構(gòu)工程師決定支撐柱子的尺寸，地基承受墻、地面和房頂?shù)闹亓浚@種結(jié)構(gòu)包括電梯、水、電、空調(diào)、衛(wèi)生等系統(tǒng)。但是，這些建筑圖紙對建筑工人的工作來說還不夠詳盡。為此，很多專業(yè)領(lǐng)域的建筑制圖人員繪制能夠反映有關(guān)材料選擇、通風子系統(tǒng)、電力子系統(tǒng)、供水子系統(tǒng)等細節(jié)的圖紙和詳細說明。建筑設(shè)計師對工程全面負責，而其他各類設(shè)計人員負責補充細節(jié)問題。

一般情況下，建筑設(shè)計師是把建筑的各個方面集成為一個整體的專家，但不是每個領(lǐng)域的專家。當繪制完所有圖紙以后，建筑圖紙只包括了建筑物最重要的部分。建筑圖紙是其他圖紙的不同視圖，和其他圖紙是一致的。

在施工過程中，不同的工作者使用建筑圖紙(詳細圖紙的不同視圖)，以獲得對建筑物的全面了解，但他們要靠詳細的施工圖紙才能完成其工作。

像建筑物一樣，軟件系統(tǒng)是一個單一的實體，但軟件構(gòu)架設(shè)計師和開發(fā)人員發(fā)現(xiàn)從不同視角展示系統(tǒng)有助于更好地理解設(shè)計。這些視角可以建立不同的系統(tǒng)模型視圖，將視圖合在一起展示了構(gòu)架。

軟件構(gòu)架包括對下面4個方面所作的決策：

軟件系統(tǒng)的組織；

構(gòu)成系統(tǒng)的結(jié)構(gòu)元素和各元素之間的接口，以及由元素間協(xié)作所規(guī)定的各元素的行為；

結(jié)構(gòu)元素和行為元素合成為逐漸增大的子系統(tǒng)；

指導組織的構(gòu)架風格：元素及其接口、協(xié)作和組合。

但是，軟件構(gòu)架不只涉及結(jié)構(gòu)和行為，還涉及到使用、功能、性能、柔性、重用、可理解性、經(jīng)濟性和技術(shù)約束以及折衷方案、美學等。

構(gòu)架可以描述為多種模型視圖：用例模型視圖、分析模型視圖、設(shè)計模型視圖等，像是帶有所有系統(tǒng)模型的一個完整的系統(tǒng)描述，但比較小。一個模型視圖是對該模型的一種抽取或是對它的一個切片，例如，用例模型視圖看起來就像是用例模型本身，它包括對構(gòu)架重要的參與者和用例。同樣，設(shè)計模型的構(gòu)架視圖看起來就像是設(shè)計模型，但它只包含用來實現(xiàn)構(gòu)架的重要用例的設(shè)計元素。

10.2為什么需要構(gòu)架

大型、復(fù)雜的軟件系統(tǒng)需要構(gòu)架設(shè)計師，以便開發(fā)人員可以向著共同的目標努力。而軟件系統(tǒng)很難想象，它并不存在于真實世界。從某些方面來講，一般是無先例可循的、獨一無二的，經(jīng)常采用未經(jīng)證實的技術(shù)或各種技術(shù)的創(chuàng)新組合，并把現(xiàn)有的技術(shù)推向極至。而且，在構(gòu)造時還必須要能適應(yīng)將來一系列的巨大變化。隨著系統(tǒng)的日益復(fù)雜，“設(shè)計問題超過了算法和數(shù)據(jù)結(jié)構(gòu)，設(shè)計和確定整個系統(tǒng)的結(jié)構(gòu)成了新的問題”。

另外，經(jīng)常存在用現(xiàn)有系統(tǒng)來實現(xiàn)規(guī)劃系統(tǒng)某些功能的情況。在沒有文檔或文檔極少的情況下，要弄清楚現(xiàn)有系統(tǒng)能做什么以及開發(fā)人員可以重用哪些遺留代碼，更增加了開發(fā)的難度和復(fù)雜性。

因此，需要構(gòu)架的原因主要為理解系統(tǒng)、組織開發(fā)、鼓勵重用、演化系統(tǒng)四個方面。

1．理解系統(tǒng)

對于從事系統(tǒng)開發(fā)的組織，所有相關(guān)人員必須理解系統(tǒng)，主要有下面的原因。

系統(tǒng)包含復(fù)雜的行為；

系統(tǒng)在復(fù)雜的環(huán)境中運行；

系統(tǒng)使用復(fù)雜的技術(shù)；

系統(tǒng)經(jīng)常把分布式計算、商用產(chǎn)品和平臺(例如操作系統(tǒng)和數(shù)據(jù)庫管理系統(tǒng))以及可重用構(gòu)件和框架集成在一起；

系統(tǒng)必須滿足個人和組織的需求；

在某些情況下，系統(tǒng)過于龐大，管理層不得不把開發(fā)工作分為在地理上經(jīng)常處于不同地點的多個項目，增加了協(xié)調(diào)的難度。

以構(gòu)架為中心進行開發(fā)，可以防止出現(xiàn)這種無法理解的現(xiàn)象。因此，對于構(gòu)架的第一個需求就是：必須使開發(fā)人員、管理人員、客戶以及其他項目相關(guān)人員能夠詳細理解要做的工作，以利于系統(tǒng)的開發(fā)。

2．組織開發(fā)

軟件項目組織越龐大，開發(fā)人員協(xié)調(diào)工作所付出的開銷也就越大。當項目分散在不同地點時，交流的開銷也會增加。將系統(tǒng)劃分為明確定義接口的子系統(tǒng)，并讓一個開發(fā)組或個人負責每個子系統(tǒng)，無論他們是在同一幢大樓里還是在不同的地域，構(gòu)架設(shè)計師都可以減少負責不同子系統(tǒng)的開發(fā)組之間的交流工作量?！昂玫摹睒?gòu)架應(yīng)該明確定義接口，盡可能減少子系統(tǒng)間的通信。一個良好定義的接口，可以有效地向開發(fā)人員雙方“傳達”對方小組正在進行的工作。

3．鼓勵重用

下面來了解構(gòu)架對重用的重要性。例如，管線產(chǎn)業(yè)很早就已經(jīng)標準化，管線承包商從標準化的零部件“獲益匪淺”。管道工只需選取標準化零部件，而不必去搭配來自于各地的不同尺寸的“新型”零部件。就像在管線產(chǎn)業(yè)中推行標準化用了幾個世紀的時間一樣，軟件構(gòu)件標準化也需要積累經(jīng)驗，還有很長的一段路要走。

軟件產(chǎn)業(yè)要達到硬件領(lǐng)域已經(jīng)達到的標準化水平，好的構(gòu)架和明確的接口是實現(xiàn)這一目標的關(guān)鍵。好的構(gòu)架為開發(fā)人員提供了可以在其上開展工作的穩(wěn)定的骨架，構(gòu)架設(shè)計師的任務(wù)就是定義該骨架和開發(fā)人員使用的可重用子系統(tǒng)，通過精心設(shè)計得到可重用的子系統(tǒng)，使它們可以裝配起來使用，一個好的構(gòu)架有助于開發(fā)人員知道在哪里能有效地尋找到可重用的元素以及發(fā)現(xiàn)合適的可重用構(gòu)件。UML可以加速構(gòu)件化產(chǎn)品的進程，標準建模語言是構(gòu)造特定領(lǐng)域可重用構(gòu)件的先決條件。

4．演化系統(tǒng)

有一件事情很確定，那就是任何相當規(guī)模的系統(tǒng)都要不斷演化，甚至在開發(fā)過程中就需要這種演化，在投入使用后，變化的環(huán)境也會要求對其進一步完善。在這兩個過程中，系統(tǒng)應(yīng)該易于變更；也就是說，開發(fā)人員應(yīng)該可以改變部分設(shè)計和實現(xiàn)，而不必擔心這種改變會對整個系統(tǒng)產(chǎn)生非期望的效果。多數(shù)情況下，開發(fā)人員應(yīng)該可以在系統(tǒng)中實現(xiàn)新功能(即用例)，而不會對現(xiàn)有的設(shè)計和實現(xiàn)造成太大的影響；換句話說，系統(tǒng)本身應(yīng)該對變化具有一定的柔性。也就是說，系統(tǒng)應(yīng)該能夠適度地演化。相反，構(gòu)架拙劣的系統(tǒng)經(jīng)常會隨著時間的推移和很多補丁程序的使用而出現(xiàn)功能退化，直至最后無法有效地更新。

10.3用

例

和

構(gòu)

架

如果系統(tǒng)提供了適當?shù)挠美脩艟涂梢允褂迷撓到y(tǒng)來完成自己的任務(wù)。但如何實現(xiàn)這一目標呢？這就需要構(gòu)造一個允許無論是現(xiàn)在還是將來都能有效實現(xiàn)用例的構(gòu)架。

首先來看一下什么會影響構(gòu)架(如圖10-1所示)，然后再看看什么會影響用例，以便了解這種相互作用是如何產(chǎn)生的。圖10-1影響設(shè)計架構(gòu)的因素

如圖10-1所示，不同種類的需求和產(chǎn)品影響構(gòu)架，而不僅僅是用例影響構(gòu)架。先前工作中的經(jīng)驗和確認為構(gòu)架模式的結(jié)構(gòu)也有助于設(shè)計構(gòu)架。

構(gòu)架受用例的影響，用例是構(gòu)架的驅(qū)動力。構(gòu)架不僅會受到對構(gòu)架重要的用例的影響，還會受到下列因素的影響：

軟件產(chǎn)品要構(gòu)造在哪些系統(tǒng)上，如操作系統(tǒng)或具體的關(guān)系數(shù)據(jù)庫管理系統(tǒng)等；

要使用哪些中間件產(chǎn)品，例如，需要選擇一個對象請求代理(ORB)來創(chuàng)建圖形用戶界面，或是一個與平臺無關(guān)的框架；

要在系統(tǒng)中使用哪些遺留系統(tǒng)。在構(gòu)架中使用遺留系統(tǒng)，如現(xiàn)有的銀行系統(tǒng)，可以重用許多現(xiàn)有的功能，但需要調(diào)整構(gòu)架來與“遺留”產(chǎn)品相互配合；

需要適應(yīng)哪些政策和公司標準，例如，可選擇OMG的接口定義語言(IDL)來確定類的所有接口，或選擇遠程通信規(guī)范TMN來說明系統(tǒng)中的對象；

通用的非功能性需求，如可用性、恢復(fù)時間或內(nèi)存使用等方面的需求；

需要說明系統(tǒng)是如何分布的，也許可以通過客戶機/服務(wù)器構(gòu)架來分布系統(tǒng)。

可以把圖10-1中右側(cè)的幾項看作是以某種方式來建立構(gòu)架的約束和使能因素。

構(gòu)架在細化階段的迭代過程中創(chuàng)建。下面是一個簡化的思維模型，開始先確定構(gòu)架的高層設(shè)計，例如一個分層構(gòu)架，然后，在第一次迭代的幾次構(gòu)造中逐步確立構(gòu)架。

在第一次構(gòu)造中處理的是通用部分，對所討論的領(lǐng)域是通用的，而不是專用于計劃開發(fā)的系統(tǒng)，即并非專用于選擇使用的系統(tǒng)軟件、中間件、遺留系統(tǒng)、標準和政策。在實施模型中，需要決定包括哪些節(jié)點以及這些節(jié)點應(yīng)該如何進行交互，還要決定如何處理一般的非功能性需求，如可用性需求等。在第一次構(gòu)造中，對應(yīng)用有一個大致的了解就足夠了。

在第二次構(gòu)造中，處理構(gòu)架中的專用應(yīng)用部分。首先選取一個與構(gòu)架相關(guān)的用例集，捕獲需求，并對它們進行分析、設(shè)計、實現(xiàn)和測試，最后，得到一個新的、用構(gòu)架實現(xiàn)的子系統(tǒng)，來支持所選擇的用例。在第一次構(gòu)造中實現(xiàn)的對構(gòu)架至關(guān)重要的構(gòu)件可能也要進行某些改變(當時沒有從用例的角度考慮)，為了實現(xiàn)用例，需要對變化的構(gòu)件和新的構(gòu)件進行開發(fā)，使構(gòu)架更適合于所選擇的用例。然后，再進行下一次構(gòu)造，依次下去，直到完成這次迭代過程。如果這次終結(jié)剛好出現(xiàn)在細化階段的最后，構(gòu)架也就應(yīng)該穩(wěn)定了。

在建立了穩(wěn)定的構(gòu)架后，就可以在構(gòu)造階段實現(xiàn)其余的用例以實現(xiàn)系統(tǒng)的全部功能。在開發(fā)構(gòu)造階段中，實現(xiàn)的用例主要是以客戶和用戶需求作為輸入，這些用例也會受到細化階段所確定的構(gòu)架的影響，如圖10-2所示。

圖10-2用例的實現(xiàn)與已存架構(gòu)的關(guān)系

在捕獲新的用例時，可以使用已存在構(gòu)架的知識來更好地完成工作。在評估每個選擇用例的價值和成本時，也是根據(jù)現(xiàn)存的構(gòu)架進行的。一些用例很容易實現(xiàn)，而另一些用例實現(xiàn)起來則較為困難。

舉例：使用例適應(yīng)已存在的構(gòu)架

客戶希望獲得一種監(jiān)控處理器負載的功能，可以將這個要求說明為測量計算機高優(yōu)先級負載的用例。要實現(xiàn)該用例，需要對現(xiàn)在所用的實時操作系統(tǒng)進行一些改動。開發(fā)組則建議，通過一個獨立的外部設(shè)備呼叫系統(tǒng)并測量應(yīng)答時間來實現(xiàn)所需的功能。這樣，客戶得到了一種更可靠的方法，而開發(fā)組也避免了對關(guān)鍵的底層構(gòu)架進行改動。

通過與客戶協(xié)商，來確定是否可以改變用例，以使用例和設(shè)計結(jié)果與已有的構(gòu)架更加一致，從而使實現(xiàn)更簡潔。這種一致性意味著必須考慮現(xiàn)有的子系統(tǒng)、接口、用例、用例實現(xiàn)、類等，通過使用例與構(gòu)架保持一致，便可以利用現(xiàn)有的資源，有效地創(chuàng)建新的用例、子系統(tǒng)和類。

所以，一方面構(gòu)架受到系統(tǒng)支持的用例的影響，用例驅(qū)動構(gòu)架；另一方面，將需求捕獲為用例時，可以利用構(gòu)架的知識來更好地完成任務(wù)，構(gòu)架指導用例(如圖10-3所示)。

圖10-3用例驅(qū)動構(gòu)架的開發(fā)，構(gòu)架指導用例的實現(xiàn)

用例和構(gòu)架哪一個先出現(xiàn)呢？這是一個典型的“雞與蛋”的問題，這種問題最好通過迭代來解決。首先，在很好地了解領(lǐng)域范圍的基礎(chǔ)上建立一個臨時的構(gòu)架，而不考慮具體的用例。接著，選取幾個重要的用例，進一步使構(gòu)架支持這些用例。然后，再選取更多的用例并建立更加完善的構(gòu)架，依此類推。在每次迭代中，都選取并實現(xiàn)一組用例來確認構(gòu)架。如果必要，對構(gòu)架進行改進。隨著每次迭代的進行，還在所選用例的基礎(chǔ)上進一步實現(xiàn)構(gòu)架的專用應(yīng)用部分。因此，在通過迭代實現(xiàn)整個系統(tǒng)時，用例有助于逐漸完善構(gòu)架，這就是用例驅(qū)動開發(fā)的一種好處。

總之，一個好的構(gòu)架無論是現(xiàn)在還是將來，都能有效地補充適當?shù)挠美?/p>

10.4建立構(gòu)架的步驟

構(gòu)架主要是在細化階段的迭代過程中開發(fā)的。每次迭代的進行都從需求開始，然后是分析、設(shè)計、實現(xiàn)和測試，但側(cè)重于與構(gòu)架相關(guān)的用例和其他需求。細化階段的最終結(jié)果是構(gòu)架基線(一個只有很少軟件“肌肉”的系統(tǒng)骨架)。

哪些用例對構(gòu)架更重要呢？對構(gòu)架重要的用例就是那些有助于降低最重大風險的用例，那些對用戶最重要的用例，那些有助于實現(xiàn)所有重要功能而不遺留任何問題的用例。實現(xiàn)、集成和測試構(gòu)架基線使構(gòu)架設(shè)計師及其他工作人員確信，構(gòu)架必須是可操作的，這是無法通過“紙上”的分析和設(shè)計來實驗的，可操作的構(gòu)架基線向那些提出反饋的工作人員展示了系統(tǒng)能工作的證據(jù)。

10.4.1構(gòu)架基線是一個“小的、皮包骨的”系統(tǒng)

在細化階段最后，要從構(gòu)架的角度開發(fā)出代表最重要的用例及其實現(xiàn)的系統(tǒng)模型，例如，用例模型、分析模型、設(shè)計模型以及其他模型等，這些模型的集合就是構(gòu)架基線，是一個“小的、皮包骨的”系統(tǒng)。它包含構(gòu)造階段末期性能完善的系統(tǒng)中所有模型的各種版本，包括與最終系統(tǒng)相同的子系統(tǒng)骨架、構(gòu)件和節(jié)點，不是所有的“肌肉部分”都存在。

但是，它們確實具有行為，而且是可執(zhí)行的代碼，“皮包骨的”系統(tǒng)逐漸演化為性能完善的系統(tǒng)，有可能對結(jié)構(gòu)和行為做一些細微的改變。改變較小的原因是：在細化階段最后已經(jīng)定義了一個穩(wěn)定的構(gòu)架。如果沒有達到這個目標，細化階段必須進行下去，直到達到該目標為止。

在圖10-4中，每種模型的陰影部分表示在細化階段最后已經(jīng)開發(fā)出的模型版本，即屬于構(gòu)架基線的模型版本。

圖10-4構(gòu)架基線是以描述構(gòu)架為主的系統(tǒng)內(nèi)部發(fā)布的版本

整個矩形(帶陰影和不帶陰影的部分)表示在移交階段末期開發(fā)出的模型版本，即代表客戶版本基線(不要從圖10-4中顯示的陰影部分的大小而得出諸多結(jié)論，這里只是用作解釋之用)。在構(gòu)架基線和客戶版本基線中間還有幾個代表模型新版本的內(nèi)部版本基線，可以把這些新版本解釋為以構(gòu)架基線為起點逐漸累加增量的結(jié)果，每個模型的新版本都是由上一個版本演化得到的。當然，圖10-4中的不同模型不是相互獨立地開發(fā)。例如，用例模型的每個用例都對應(yīng)著分析模型和設(shè)計模型中的某個用例實現(xiàn)，或測試模型中的測試用例。

但是，構(gòu)架基線(即細化階段末期系統(tǒng)的內(nèi)部版本)不僅僅靠模型制品來表示，還包括構(gòu)架描述，它們是同時建立的，甚至經(jīng)常比構(gòu)架基線中產(chǎn)生模型版本的活動更早。構(gòu)架描述的作用是在系統(tǒng)的整個生命周期內(nèi)指導整個開發(fā)組——不只是用于當前周期的各次迭代，還用于所有以后的周期，是開發(fā)人員目前和將來都要遵循的標準，既然構(gòu)架已經(jīng)穩(wěn)定了，那么標準也就是穩(wěn)定的。

構(gòu)架描述可以有不同的形式，可以是對組成構(gòu)架基線的模型的抽取，也可以是以一種便于閱讀的形式進行描述。在以后的階段中，隨著系統(tǒng)的進化和模型的增大，還會包括模型新版本的視圖。

10.4.2使用構(gòu)架模式

建筑設(shè)計大師ChristopherAlexander關(guān)于如何用“模式語言”對建筑和社區(qū)設(shè)計中重要的原則進行系統(tǒng)化和實用化的觀點，啟發(fā)了很多面向?qū)ο箢I(lǐng)域的專業(yè)人士定義、收集和測試各種軟件模式。

構(gòu)架模式主要是針對粗粒度的子系統(tǒng)甚至系統(tǒng)的結(jié)構(gòu)和交互，存在很多種構(gòu)架模式，這里簡單討論一些值得關(guān)注的模式。

代理模式是一種管理對象分布的通用機制，允許對象通過一個代理調(diào)用其他的遠程對象，代理將調(diào)用請求轉(zhuǎn)發(fā)到目標對象節(jié)點。這種轉(zhuǎn)發(fā)是透明的，就是說調(diào)用者無需知道被調(diào)用的對象是否為遠程的。代理模式經(jīng)常利用委托方式，提供一個與遠程對象接口相同的本地代理對象，使分布式的通信形式和細節(jié)透明化。

還有其他一些模式有助于了解所構(gòu)造系統(tǒng)的硬件，有助于基于此硬件來設(shè)計系統(tǒng)，如客戶機/服務(wù)器模式、三層模式和端對端模式。這些模式定義了實施模型的結(jié)構(gòu)，并建議構(gòu)件應(yīng)該如何分布到節(jié)點上。例如，對ATM系統(tǒng)，使用客戶機／服務(wù)器模式，客戶機節(jié)點將執(zhí)行所有的用戶界面代碼和針對實際ATM的業(yè)務(wù)邏輯(控制類)代碼，而服務(wù)器節(jié)點則包含了實際的賬戶和每個事務(wù)需要得到驗證的業(yè)務(wù)規(guī)則。

層次模式適用于很多系統(tǒng)。該模式定義了如何分層組織設(shè)計內(nèi)容，就是說一層的構(gòu)件只能參與恰好處于其下層中的構(gòu)件。這種模式很重要，它簡化了理解和組織開發(fā)復(fù)雜系統(tǒng)的工作。層次模式降低了依賴，因為低層不必關(guān)心高層的細節(jié)和接口。它有助于確定什么可以重用，提出了一個有助于決定買什么或構(gòu)造什么的結(jié)構(gòu)。

具有分層構(gòu)架的系統(tǒng)在頂層具有單獨的應(yīng)用子系統(tǒng)，是在低層子系統(tǒng)的基礎(chǔ)上(如框架和類庫)構(gòu)造的，如圖10-5所示。通用應(yīng)用層包含的子系統(tǒng)不是專用于一個單獨的應(yīng)用，而是在相同的領(lǐng)域或業(yè)務(wù)內(nèi)能被很多不同的應(yīng)用重用。

圖10-5分層構(gòu)架通過多層子系統(tǒng)來組織系統(tǒng)

層次是具有相同程度的通用性和接口易變性的子系統(tǒng)集合。低層通常用于多個應(yīng)用，必須具有較穩(wěn)定的接口；高層更適用于具體應(yīng)用，接口穩(wěn)定性較差。既然低層提供的接口一般很少改變，那么高層的開發(fā)人員可以基于穩(wěn)定的低層來構(gòu)造。不同層次中的子系統(tǒng)可重用用例、其他低層子系統(tǒng)、類、接口、協(xié)作和低層的構(gòu)件。許多構(gòu)架模式可用于單獨的系統(tǒng)中。構(gòu)成實施模型的模式(例如，客戶機/服務(wù)器模式、三層模式或端對端模式)可以與層次模式相結(jié)合，其中層次模式可以輔助構(gòu)成設(shè)計模型。

用來處理不同模型中結(jié)構(gòu)的模式彼此間通常是正交的，甚至處理同一模型的各種模式之間通常也能很好地結(jié)合。代理模式處理如何解決對象透明分布的問題，層次模式用來顯示如何組織整個設(shè)計。實際上，一般將代理模式實現(xiàn)為中間件層的一個子系統(tǒng)。

注意，有時候一種模式占主導地位。例如，在分層系統(tǒng)中，層次模式定義了整個構(gòu)架和任務(wù)分解(將層分配給不同組)，管道和過濾可用于一個或多個層次內(nèi)部。反之，在管道和過濾系統(tǒng)中，整個構(gòu)架就表示為過濾模式間的流，而分層則用于一些過濾程序。

10.4.3描述構(gòu)架

細化階段開發(fā)的構(gòu)架基線以構(gòu)架描述的形式保存下來，產(chǎn)生不同模型的版本，如圖10-6所示。構(gòu)架描述是一種抽象，或者說是構(gòu)架基線中模型的視圖集合，視圖包括對構(gòu)架重要的元素。當然，許多組成構(gòu)架基線的模型元素會出現(xiàn)在構(gòu)架描述中，但是，并不是所有的元素都是如此，因為要得到一個可操作的基線，可能需要開發(fā)一些對構(gòu)架不重要但對生成可執(zhí)行代碼必要的模型元素，所以，構(gòu)架基線不只是用于開發(fā)構(gòu)架，也在一定程度上用于說明系統(tǒng)需求，以便制定出詳細的計劃。

圖10-6系統(tǒng)構(gòu)造階段架構(gòu)描述的變化

如圖10-6所示，在構(gòu)造階段，各種模型趨于完成(右上角填充陰影的圖形)。因為大多數(shù)構(gòu)架在細化階段定義，所以構(gòu)架描述沒有明顯變化(右下圖)。構(gòu)架的細微變化確實發(fā)生(由不同的填充圖案表示)。

在整個系統(tǒng)生命周期內(nèi)，構(gòu)架描述會不斷更新，以反映與構(gòu)架有關(guān)的變化和補充。這些變化通常很小，大致包括下面內(nèi)容：

發(fā)現(xiàn)了新的抽象類和接口；

為現(xiàn)有的子系統(tǒng)添加新功能；

升級到可重用構(gòu)件的新版本；

重新安排處理結(jié)構(gòu)。

構(gòu)架描述本身可能需要修改，但不必增加規(guī)模，只是對有關(guān)內(nèi)容進行更新。

構(gòu)架描述用于展示模型的視圖，包括用例、子系統(tǒng)、接口、一些類和構(gòu)件、節(jié)點以及協(xié)作。構(gòu)架描述還包括用例沒有描述的對構(gòu)架有意義的需求，這些需求是非功能性的，作為補充需求來說明，例如，關(guān)于分布和并發(fā)涉及到的安全及重點約束等需求。構(gòu)架描述還應(yīng)包括對平臺、遺留系統(tǒng)和將使用的業(yè)務(wù)軟件的簡單說明，例如，Java中用于對象分布的遠程方法調(diào)用(RemoteMethodInvocation，RMI)。

當然，說明實現(xiàn)通用機制的框架也很重要，例如，在關(guān)系數(shù)據(jù)庫中存儲或檢索對象。這些機制可在多個用例實現(xiàn)中得到重用，因為它們就是為實現(xiàn)可重用的協(xié)作而設(shè)計的。構(gòu)架描述還應(yīng)該對所有使用過的構(gòu)架模式進行歸檔。

構(gòu)架描述強調(diào)了最重要的設(shè)計問題，將它們明確表示出來供他人探討和提出反饋。然后，需要對這些問題進行討論、分析，最終加以解決。例如，這些分析可能包括評估負載性能或內(nèi)存需要，以及設(shè)想將來可能會危及到構(gòu)架的需求。

盡管構(gòu)架描述考慮得很周全，但是，它終究是一種頂層視圖。一方面，不要指望它闡明一切，而且也不應(yīng)該把參與者淹沒在太多的細節(jié)中，它是一張行車路線圖，而不是整個系統(tǒng)的詳細說明。另一方面，它必須體現(xiàn)出每個參與者的需要，所以即使有100多頁也不算多。如果把人們的所有需求以易于理解的方式納入其中，可能需要使用一個巨大的文檔。構(gòu)架描述應(yīng)該做到：它應(yīng)該包括開發(fā)人員為了完成其工作所需要的內(nèi)容。

構(gòu)架描述不包括那些只是為了確認或驗證構(gòu)架所需要的信息。因此，它不包括測試用例和測試規(guī)程，也不包括測試模型的構(gòu)架視圖，它們不屬于構(gòu)架范疇。但是，構(gòu)架基線包含所有模型的版本，其中也有測試模型的版本。這樣，作為構(gòu)架描述基礎(chǔ)的基線便會經(jīng)歷測試——所有的基線都這樣。

10.4.4構(gòu)架設(shè)計師創(chuàng)建構(gòu)架

構(gòu)架是由構(gòu)架設(shè)計師和其他開發(fā)人員共同創(chuàng)建的。他們致力于實現(xiàn)一個高性能、高質(zhì)量的系統(tǒng)，而且要功能強大、可測試、對用戶友好、可靠、高可用、精度高、可擴展、可變更、健壯、可維護、易攜帶、安全、可靠而且經(jīng)濟。他們很清楚自己需要在這些約束范圍內(nèi)求生存，還要從中找到折衷方案——這就是需要構(gòu)架設(shè)計師的原因，構(gòu)架設(shè)計師對此承擔最主要的技術(shù)責任，他們選取構(gòu)架模式和現(xiàn)存產(chǎn)品，規(guī)劃子系統(tǒng)的依賴，使其從不同側(cè)面分別考察問題，當其中某個子系統(tǒng)發(fā)生變化時不會對其他子系統(tǒng)造成影響。

構(gòu)架的根本目標是以當前的技術(shù)狀況和該應(yīng)用可承受的成本、用最佳的方式來滿足應(yīng)用的需要，換句話說，也就是能夠在現(xiàn)在和將來有效地實現(xiàn)應(yīng)用功能(即用例)。這里，UML具有強有力的結(jié)構(gòu)來系統(tǒng)地闡明構(gòu)架，統(tǒng)一過程詳細地介紹了構(gòu)造良好構(gòu)架的原則。即使如此，所選定的構(gòu)架最終仍然是基于技術(shù)和經(jīng)驗進行判斷的，構(gòu)架設(shè)計師負責做出決策。細化階段末期，當構(gòu)架設(shè)計師將構(gòu)架描述提交給項目經(jīng)理時，就意味著，“現(xiàn)在已經(jīng)清楚了，可以構(gòu)造出系統(tǒng)而不會遇到太大的技術(shù)難題?！?/p>

合格的構(gòu)架設(shè)計師需要具備兩種能力。一種是他所從事的領(lǐng)域知識，因為他必須與所有項目相關(guān)人員配合，不只是開發(fā)人員。另一種就是軟件開發(fā)知識，甚至是最基本的編碼能力，因為他必須向開發(fā)人員說明構(gòu)架，協(xié)調(diào)他們的工作，了解他們的反饋。

開發(fā)構(gòu)架需要大量的時間。將這段時間安排在開發(fā)日程的最前面，可能會令那些已經(jīng)習慣于把大部分時間用于實現(xiàn)和測試的項目經(jīng)理感到不安。但是，經(jīng)驗表明，有一個好的構(gòu)架作指導，后面的各階段會大大縮短整個開發(fā)周期，對大型項目尤其重要。

10.4.5構(gòu)架師

軟件構(gòu)架師和其他高級開發(fā)人員一起，決定系統(tǒng)構(gòu)架，包括技術(shù)選擇和子系統(tǒng)設(shè)計。構(gòu)架上的各種機制，諸如錯誤處理和緩沖策略等，必須在實際開發(fā)之前確定。接下來的任務(wù)包括針對構(gòu)架的一致性，對詳細設(shè)計進行評估，修訂構(gòu)架，以及鼓勵開發(fā)人員使用好的OO原則和軟件工程方法，包括UML、經(jīng)過驗證的OO設(shè)計原則、設(shè)計模式、迭代式開發(fā)，以及對設(shè)計和代碼組織評審等。

軟件構(gòu)架師需要具備豐富的面向?qū)ο笙到y(tǒng)的開發(fā)經(jīng)驗，應(yīng)該具有擔任技術(shù)“門將”的背景。編程語言以及技術(shù)上的專業(yè)知識也是必需的，如果沒有親自深入到細節(jié)中去，沒有切實的體驗和認識，根本不可能選擇出正確的技術(shù)，并將一個解決方案正確地分解為多個組成部分。

良好的交流和溝通技巧也同樣重要。構(gòu)架師必須立場堅定，能容忍其他意見，明辨是非，否則項目就會缺乏技術(shù)前瞻性。另一方面，構(gòu)架師必須協(xié)調(diào)團隊達成一致意見，指導開發(fā)人員。構(gòu)架師有責任拒絕過分的、具有破壞性的進度要求，必須和項目經(jīng)理緊密合作，控制風險并保證項目如期成功完成。

一個好的構(gòu)架師能夠從眾多參加者那里接收信息“輸入”，之后，在高級技術(shù)人員中建立一致的意見和認識，但是，最終的責任是不能共同承擔的，一致的解決方案從來都不是由委員會提出的。一旦整體方案建立起來，每個單獨的部分就能夠分派給各個設(shè)計人員，但整個團隊必須對系統(tǒng)持一致的觀點，并且有一個人全權(quán)負責。

10.4.6建立構(gòu)架的過程

建立堅實、可靠的構(gòu)架需要經(jīng)過確定目標、將類分組、展示技術(shù)、抽取子系統(tǒng)、應(yīng)用原則和目標對構(gòu)架進行評估等5個步驟。

1.確定目標

系統(tǒng)可能面臨著可擴展性、可維護性、可靠性和可伸縮性等方面的目標。無論哪種情況，最重要的是必須確定目標，對其相對重要性做到心中有數(shù)。

為眾多目標設(shè)立清晰的優(yōu)先級是進行風險管理的有力武器。風險管理跟蹤所有想避免的問題。從某種意義上講，目標只是希望培育出的結(jié)果。無論從哪方面講，確立優(yōu)先級并不需要無一遺漏。絕大多數(shù)的系統(tǒng)需要的只是1～2頁非正式的文檔，即便如此，也使其受益匪淺。

2.將類分組

可以把相互協(xié)作的類放在一起而將它們歸到同一個包內(nèi)，也可以從職責相似的角度對類進行分組。要對類進行分組，就必須在考慮可變性和可用性的同時充分考慮耦合性和內(nèi)聚性的因素。

一般來說，可以在不同環(huán)境下重用的類應(yīng)該按照職責將其組織到相同的包中，按照職責而不是協(xié)作關(guān)系進行分組有助于使用，專門針對一個協(xié)作的那些類應(yīng)該與支持類位于同一個包內(nèi)。

當然，也可以從職責的角度對分析類分組。例如，如果每個實體類，都有多個控制類對其進行訪問，那么所有的實體類應(yīng)該屬于一個層次，對控制類來說同樣如此，因為，每個控制類都能和同一邊界類的不同版本進行交互。

3.展示技術(shù)

對于技術(shù)選擇，其步驟相對的機械、呆板，每使用一項技術(shù)都必須將其添加到包依賴關(guān)系圖中。

4.抽取子系統(tǒng)

子系統(tǒng)有助于提高開發(fā)效率，對系統(tǒng)的可配置性提供支持，使系統(tǒng)的各個部分能夠按照需求的變化相對獨立地演化?？梢酝ㄟ^尋找有清晰定義的接口，與系統(tǒng)的其他部分松散耦合的包來確定候選子系統(tǒng)。在候選對象中，進一步尋找能夠獨立開發(fā)且/或封裝了易發(fā)生變化的需求的包。

5.應(yīng)用原則和目標對構(gòu)架進行評估

必須針對系統(tǒng)目標，以高內(nèi)聚和低耦合的原則定期地對構(gòu)架進行評估。UML和建模工具不但有助于評審和修訂系統(tǒng)模型，而且還能將廢棄部分減到最小，UML還便于與其他開發(fā)人員進行高效的交流。

10.5構(gòu)架描述

構(gòu)架描述是對構(gòu)架的表達，構(gòu)架描述的第一個版本就是對第一個生命周期中細化階段末期的模型版本的抽取。如果不想將這些抽取改寫為更易讀的形式，構(gòu)架描述看起來與系統(tǒng)的一般模型非常相似，這種外部特征意味著用例模型的構(gòu)架視圖看起來就像一般的用例模型。唯一的區(qū)別就是用例模型的構(gòu)架視圖只包括對構(gòu)架重要的用例，最終的用例模型則包含所有用例。

構(gòu)架描述包括五個部分，每部分說明一個模型：用例模型視圖、分析模型視圖(不一定總有)、設(shè)計模型視圖、實施模型視圖和實現(xiàn)模型視圖。構(gòu)架描述不包括測試模型視圖，因為它對描述構(gòu)架不起作用，它只是用來驗證構(gòu)架基線。

1．用例模型的構(gòu)架視圖

用例模型的構(gòu)架視圖展示了最重要的參與者和用例。ATM系統(tǒng)用例模型如圖8-3所示。

舉例：ATM系統(tǒng)中用例模型的構(gòu)架視圖

在ATM的例子中，“取款”是最重要的用例。沒有它，也就沒有實際的ATM系統(tǒng)?！按婵睢焙汀稗D(zhuǎn)賬”用例對一般的銀行儲戶來講不太重要。

所以在定義構(gòu)架時，構(gòu)架設(shè)計師認為“取款”用例要在細化階段完全實現(xiàn)，而其他用例(或用例中的一部分)對于構(gòu)架的目標意義不大(實際操作中，做出這樣的決定還為時過早，這里只是為了討論方便)。

因此，用例模型的構(gòu)架視圖應(yīng)該顯示出“取款”用例的完整描述。

2．設(shè)計模型的構(gòu)架視圖

設(shè)計模型的構(gòu)架視圖展示了設(shè)計模型中對構(gòu)架最重要的類元：最重要的子系統(tǒng)和接口，還有一些很重要的類(主要是主動類，是指具有主動發(fā)起動作的類，是行為的發(fā)起者，非主動類不會主動發(fā)起動作，只是被動的被觸發(fā)或調(diào)用)。它還展示了最重要的用例是如何按照這些類元實現(xiàn)的，即如何實現(xiàn)用例的。

舉例：ATM系統(tǒng)中設(shè)計模型的構(gòu)架視圖

在ATM系統(tǒng)中，有三個主動類：“客戶管理”、“事務(wù)管理”和“賬戶管理”(如圖10-7所示，這是一個描述主動類的類圖)，都應(yīng)該包含在設(shè)計模型的構(gòu)架視圖中。

圖10-7ATM系統(tǒng)中設(shè)計模型的構(gòu)架視圖的靜態(tài)結(jié)構(gòu)

對于三個子系統(tǒng)(“ATM接口”、“事務(wù)管理”和“賬戶管理”)之間的關(guān)系應(yīng)該清楚，如圖10-8所示，這是描述子系統(tǒng)及其接口的類圖。這些子系統(tǒng)用于實現(xiàn)“取款”用例，對構(gòu)架很重要。設(shè)計模型還包括很多其他的子系統(tǒng)，這里不做討論。

圖10-8ATM系統(tǒng)中設(shè)計模型的構(gòu)架視圖的靜態(tài)結(jié)構(gòu)

“ATM接口”子系統(tǒng)處理儲戶的所有輸入和輸出，如打印收據(jù)和接受銀行儲戶的指令?！百~戶管理”子系統(tǒng)中保存所有長期賬戶的信息，用于處理所有賬戶事務(wù)?！笆聞?wù)管理”子系統(tǒng)包含用例專用行為的類，如“取款”用例的專用行為。用例專用的類通常包含在不同的服務(wù)子系統(tǒng)中，例如在“事務(wù)管理”子系統(tǒng)中，就有“取款”類、“轉(zhuǎn)賬”類和“存款”類的服務(wù)子系統(tǒng)（圖10-8中未表示出來）。實際上，每個服務(wù)子系統(tǒng)通常包括幾個類，這里進行了簡化。

圖10-8中的子系統(tǒng)通過接口彼此提供一定的行為，如由“賬戶管理”提供的“轉(zhuǎn)賬”接口。還有“轉(zhuǎn)賬”、“存款”和“歷史”接口，這些接口沒有包括在所涉及的用例中，所以不對其進行解釋。

只有靜態(tài)結(jié)構(gòu)是不夠的，還需要說明設(shè)計模型中對構(gòu)架重要的用例是如何通過子系統(tǒng)實現(xiàn)的。因此，這里從子系統(tǒng)和參與者相交互的角度再次說明“取款”用例，如圖10-9中的協(xié)作圖所示。子系統(tǒng)所屬類的對象相互之間進行交互來執(zhí)行一個用例實例。對象間相互傳遞消息如圖所示，消息攜帶有指明子系統(tǒng)接口所屬操作的名稱，由“：：”符號表示。如“取款：：執(zhí)行（數(shù)額，賬戶）”，這里“取款”是“事務(wù)管理”子系統(tǒng)中的類所提供的接口。

圖10-9執(zhí)行“取款”用例的子系統(tǒng)間的協(xié)作

下面內(nèi)容簡要說明了用例實現(xiàn)中的流。前提條件是儲戶有一個可以用于ATM的銀行賬戶。

(1)參與者“儲戶”選擇取款并向“ATM接口”表明身份，可以通過使用具有編號的磁卡和PIN（個人身份號碼）來實現(xiàn)。儲戶還要說明取多少現(xiàn)金并從哪個賬戶中提取。這里假定“ATM接口”子系統(tǒng)能夠確認身份。

(2)“ATM接口”請求“事務(wù)管理”子系統(tǒng)取款?！笆聞?wù)管理”子系統(tǒng)負責將提取現(xiàn)金的整個動作序列作為一個原子事務(wù)來執(zhí)行，以便從賬戶中扣除取款金額，并將現(xiàn)金分發(fā)給儲戶。

(3)“事務(wù)管理”請求“賬戶管理”子系統(tǒng)取款?！百~戶管理”子系統(tǒng)決定能否取出現(xiàn)金，如果能，就從賬戶中扣除取款的金額并返回一個應(yīng)答，表明可以執(zhí)行取款動作。

(4)“事務(wù)管理”授權(quán)“ATM接口”子系統(tǒng)分發(fā)貨幣。

(5)“ATM接口”將現(xiàn)金分發(fā)給“儲戶”。

3．實施模型的構(gòu)架視圖

實施模型根據(jù)相互連接的節(jié)點定義實際的系統(tǒng)構(gòu)架，這些節(jié)點是軟件構(gòu)件能夠在其上運行的硬件單元。通常實際系統(tǒng)構(gòu)架看起來就像著手開發(fā)系統(tǒng)之前的樣子，這樣，便可以在需求工作流期間盡早將節(jié)點和連接在實施模型中進行模型化。

在設(shè)計期間，需要確定哪些類是主動的，即確定線程或過程；還要確定每個主動對象應(yīng)該做什么，這些主動對象的生命周期應(yīng)該怎樣，以及主動對象如何通信、同步和共享信息；需要將主動對象分配到實施模型的節(jié)點上，在將主動對象分配給節(jié)點時，需要考慮節(jié)點的性能(如處理能力和內(nèi)存大小等)以及連接的特點(如帶寬和可用性等)。

實施模型的節(jié)點和連接以及分配給節(jié)點的主動對象可以在實施圖中表示出來，這些圖還可以表明如何將可運行的構(gòu)件分配給節(jié)點。

舉例：ATM系統(tǒng)中實施模型的構(gòu)架視圖

“儲戶”通過“ATM客戶機”節(jié)點訪問系統(tǒng)，該節(jié)點通過訪問“ATM應(yīng)用服務(wù)器”來執(zhí)行事務(wù)(如圖10-10所示)，“ATM應(yīng)用服務(wù)器”又利用“ATM數(shù)據(jù)服務(wù)器”對賬戶執(zhí)行具體的事務(wù)。不僅對“取款”用例(對構(gòu)架重要的用例)是這樣，對其他用例(如“存款”和“轉(zhuǎn)賬”用例)也是如此。

圖10-10實施模型定義的三個節(jié)點

定義這些節(jié)點，就可以將功能部署到節(jié)點上。為簡單起見，將每個子系統(tǒng)(如圖10-8所示)作為一個整體部署在一個節(jié)點上?！癆TM接口”子系統(tǒng)部署在“ATM客戶機”節(jié)點上，“事務(wù)管理”子系統(tǒng)部署在“ATM應(yīng)用服務(wù)器”上，“賬戶管理”子系統(tǒng)部署在“ATM數(shù)據(jù)服務(wù)器”上。因此，這些子系統(tǒng)中的每個主動類(如圖10-7所示)都部署在相應(yīng)的節(jié)點上，具體表現(xiàn)為運行于該節(jié)點上的一個進程。主動對象的部署如圖10-11所示。ATM系統(tǒng)的主動類分布到幾個節(jié)點上，主動類用粗邊框的矩形表示。

這是系統(tǒng)分布的一個簡單例子。在實際的系統(tǒng)中，分布必然更復(fù)雜。對分布問題的另一種方案是使用某些用于對象分布的中間件，如對象請求代理(ORB)。

圖10-11實施模型的構(gòu)架視圖

4．實現(xiàn)模型的構(gòu)架視圖

實現(xiàn)模型是從設(shè)計模型和實施模型直接映射得到的，每個設(shè)計服務(wù)子系統(tǒng)通常會為它所安裝的節(jié)點類型產(chǎn)生一個構(gòu)件(但并不總是如此)。有時候，同一個構(gòu)件(如緩沖區(qū)管理構(gòu)件)可能會在幾個節(jié)點上實例化并運行，一些語言(如JavaBeans)提供了封裝構(gòu)件的結(jié)構(gòu)。否則，就要將類組織到所選構(gòu)件集合的代碼中。

在ATM中，“取款管理”服務(wù)子系統(tǒng)有可能實現(xiàn)為兩個構(gòu)件：“在服務(wù)器端取款”和“在客戶機端取款”。“在服務(wù)器端取款”構(gòu)件可以實現(xiàn)為“取款”類，而“在客戶機端取款”構(gòu)件可以實現(xiàn)為“取款代理”類。這里進行了簡化，每個構(gòu)件只實現(xiàn)一個類。在實際的系統(tǒng)中，每個服務(wù)子系統(tǒng)應(yīng)該有更多的類，所以一個構(gòu)件通常要實現(xiàn)多個類。

5．清晰地理解創(chuàng)建構(gòu)架擬采用的技術(shù)

建立一個堅實、可靠的構(gòu)架需要針對項目付出專門的努力。在建立構(gòu)架過程中，嚴格遵循一個合理且嚴格定義的過程會在整個項目的生命周期內(nèi)都受益。

在創(chuàng)建構(gòu)架之前，必須對問題以及將要采用的技術(shù)有一個清晰的理解。

(1)清晰準確地理解問題。

對于用例模型中具有代表性的子集，需要可靠的需求、各種分析類以及多個交互圖。這樣的系統(tǒng)模型構(gòu)成了對要解決的問題的理解。如果不能從用戶的角度理解問題，就會導致在第一次大規(guī)模演示程序時，面對用戶提出的要求，只能做出“那很好，但是…”的反應(yīng)；如果不能從開發(fā)人員的角度理解問題，往往會孕育出一個脆弱的、不能滿足系統(tǒng)功能需求的構(gòu)架。

(2)清晰準確地理解候選技術(shù)。

要清晰準確地理解各種候選技術(shù)，包括它們的優(yōu)勢、不足、兼容性和合適性，這些信息對組織出合理的解決方案簡直就是無價之寶。在某些情況下，各種技術(shù)之間可能并不直接互相兼容。例如，為了能在系統(tǒng)中使用某個可用的商業(yè)類庫，就必須實現(xiàn)額外的一部分系統(tǒng)以與之適配。在另一些情況下，要采用的技術(shù)可能不支持某種希望的結(jié)果。項目前期花費在技術(shù)理解上的時間避免了大量的問題，能夠顯著地減小失敗的風險，

在將系統(tǒng)劃分為多個部分時，還應(yīng)該考慮到采用某項技術(shù)的困難程度。畢竟，在現(xiàn)實中，負責實現(xiàn)系統(tǒng)每個部分的開發(fā)人員不可能通曉所有的技術(shù)。因此，必須確保系統(tǒng)每個部分的技術(shù)需求都落在要采用的技術(shù)能力范圍之內(nèi)，這樣用組織中相當小的一部分開發(fā)人員就能掌握要求的技術(shù)。

10.6建立軟件構(gòu)架：考勤系統(tǒng)實例研究

下面就以考勤系統(tǒng)為例，建立系統(tǒng)的軟件構(gòu)架。考勤系統(tǒng)的技術(shù)選擇工作在此不做闡述，這里為考勤系統(tǒng)選擇的實現(xiàn)技術(shù)是EJB，因此，下面的設(shè)計決策是在此前提下做出的。

10.6.1確立目標

第一步，確立系統(tǒng)目標。在某些情況下，系統(tǒng)目標是由外在的需求確立的。例如，在補充需求中，經(jīng)常會明確地提出可靠性和可伸縮性等方面的需求，可維護性和可擴展性往往由開發(fā)人員決定，因為只有開發(fā)人員才知道系統(tǒng)是如何開發(fā)的，能夠估計出需求的穩(wěn)定性。

可擴展性。所有的系統(tǒng)都會發(fā)生變化，但是，考勤應(yīng)用程序的目標看起來已經(jīng)相當集中了—從用戶那里獲取考勤卡數(shù)據(jù)，不分析這些數(shù)據(jù)，也不給用戶開賬單，也不計算每位雇員應(yīng)得的薪酬。因此，可擴展性不是問題，所以，優(yōu)先級不高。

可維護性?？记谙到y(tǒng)必須易于理解和維護。公司有不同的團隊負責系統(tǒng)維護和新項目開發(fā)，所以該系統(tǒng)會移交給新的團隊負責。

可靠性。作為公司基礎(chǔ)設(shè)施的一部分，考勤系統(tǒng)必須高度可靠。它畢竟不是為處理信用卡或支持生命系統(tǒng)而建造的，所以限制范圍內(nèi)的停機時間是可以接受的，但是，不可預(yù)測的停機時間是不應(yīng)該出現(xiàn)的。

可伸縮性。因為公司計劃快速發(fā)展，所以考勤系統(tǒng)必須能夠擴大以適應(yīng)更多的數(shù)據(jù)和更多的用戶。

明確定義的目標以及合理界定的優(yōu)先級對構(gòu)架的建立和設(shè)計方面的重大決策意義重大，在這里，如果條件允許，可以在一定程度上犧牲可擴展性來提高可伸縮性。

10.6.2將類分組并評估每個類

下一步就是將這些類劃分為候選包，對其內(nèi)聚性進行評估。為了完成此任務(wù)，需要再次識別分析模型中的一組類，檢查其職責。要想每組類的關(guān)系都清晰明確，包就必須具有清晰的、嚴格定義的目的和職責。

1.將類分組

通過分析(第9章)，識別出了五組分析類。

實體類；

用戶界面類；

控制類；

系統(tǒng)接口類；

定位器類。

下面，以這些組為候選包，對其內(nèi)聚進行評估。如果一個包的內(nèi)聚很高，就使用分析時建立的類圖來進一步評估其耦合度。在某些情況下，這種過分簡化了的分層方法會失敗，因為不同類型的類之間的協(xié)作甚至強于相同類型的類之間的協(xié)作，這就是最簡單的方法。

下面，以這些組為候選包，對其內(nèi)聚進行評估。如果一個包的內(nèi)聚很高，就使用分析時建立的類圖來進一步評估其耦合度。在某些情況下，這種過分簡化了的分層方法會失敗，

因為不同類型的類之間的協(xié)作甚至強于相同類型的類之間的協(xié)作，這就是最簡單的方法。

另外，還需要為包重新命名，因為實體類過于簡單，而且含糊不清。由于所有的類都是考勤模型的一部分，所以稱之為TimeCardDomain很合適。圖10-12顯示了該包及其中

的類。

用戶界面類是第二組類，如圖9-23所示。這一組類完全封裝了數(shù)據(jù)顯示和系統(tǒng)與用戶就工時條目進行交互的邏輯。如果用Servlet技術(shù)來處理用戶界面，就沒有理由將AdministrativeLoginUI和RccordTimeAdministrativeUI劃分為單獨的類。

圖10-12TimeCardDomain包

包的名稱應(yīng)該反映出應(yīng)用程序的功能和所使用的技術(shù)，因而可將其命名為TimeCardUI，圖10-13顯示了包中的類。

圖10-13TimeCardUI包

控制類是第三組類，如圖9-24所示。所有這些類封裝了考勤卡條目或考勤處理工作流，所有的工作流看起來都使用了相同的實體類且關(guān)系密切。由于每個類都包含了考勤系統(tǒng)的一個工作流程，所以包的名稱就是TimeCardWorkflow。圖10-14顯示了包中的類。

圖10-14TimeCardWorkflow包

支付系統(tǒng)接口BillingSystemInterface類是第四組類，如圖9-23所示。看起來，這個包也應(yīng)是ExportRequest類的所在，就是剛才從TimeCardDomain包中移出來的。該包封裝了生成輸出數(shù)據(jù)的邏輯，包含了輸出請求，其內(nèi)聚性看起來足夠了。由于該類是支付系統(tǒng)的一個接口，所以此包命名為BillingSystemInterface是很恰當?shù)摹D10-15顯示了該包中

的類。

圖10-15BillingSystemInterface包

定位器類是因為用EJB技術(shù)來實現(xiàn)實體類，所以不需要任何單獨的定位器類。Home接口為每個實體類提供了此項功能。

正像上面所描述的，每個包都有一個明確的目的，并且包內(nèi)的各個類強內(nèi)聚。下面來看一看包之間的耦合程度。

2.描述包之間的耦合程度

下面，用包依賴關(guān)系圖來評估包之間的耦合程度。如果包A中的某個類與包B中的某個類之間存在關(guān)系，那么包A就依賴于包B。圖9-28～圖9-30顯示了每個用例的各個類間的依賴關(guān)系。現(xiàn)在，將這三個類圖合并為一個，然后將這個圖概括為一個包依賴關(guān)系圖。

圖10-16～圖10-18重現(xiàn)了它們在第9章中的樣子。

圖10-16參與“Login”用例的類的類圖圖10-17參與“RecordTime”用例的類的類圖圖10-18參與“ExportTimeEntries”用例的類的類圖

從這些類圖出發(fā)，可以生成一個顯示所有類之間依賴關(guān)系的類圖，這是非常機械、繁瑣的過程，要將每個類圖中的每個關(guān)系添加到一個類圖中。

圖10-19為所有類以及其關(guān)系。在生成該圖的過程中，ExportEntriesUI直接依賴來自TimeCardDomain包中的類，看起來有點怪，因為其他的用戶界面類都依賴TimeCardWorkflow包中的類，后者又依賴TimeCardDomain包。

圖10-19參與考勤系統(tǒng)的類及相互間的關(guān)系簡圖

下面就需要從類之間的關(guān)系生成包依賴關(guān)系圖。從一個類到另一個位于不同包中的類之間的關(guān)系都引起包依賴，例如，從RecordTimeUI類(在TimeCardUI包中)到RecordTimeWorkflow類(在TimeCardWorkflow包中)的關(guān)系就引起了從TimeCardUI包到TimeCardWorkflow包的依賴，如圖10-20所示。與前面的工作一樣，最好交給工具來完成。

因為不存在循環(huán)依賴，所以包之間的依賴關(guān)系相當合理。此外，那些想要可重用的包，如TimeCardDomain和BillingSystermInterface之間不存在依賴關(guān)系。每個包中的各個類之間是強內(nèi)聚，而包之間是松耦合，這樣，系統(tǒng)已經(jīng)有了一個初步的結(jié)構(gòu)。

圖10-20包依賴關(guān)系

10.6.3展示技術(shù)

實體類和控制類將采用EJB來實現(xiàn)，用戶界面類將采用Servlet來實現(xiàn)，圖10-21顯示了更新后的依賴關(guān)系圖。

此外，對于BillingSystermInterface類，選擇XML技術(shù)。現(xiàn)在需要做的就是在包依賴關(guān)系圖中添加這些技術(shù)包。用一條從源包到技術(shù)包的依賴線來表示使用了某種技術(shù)。例如，TimeCardUI包依賴于Servlets包。

圖10-21包含所采用技術(shù)的包之間依賴關(guān)系

10.6.4抽取子系統(tǒng)

下一步是識別子系統(tǒng)。目標可以在具有定義清晰的接口，同時又與系統(tǒng)的其他部分松散耦合的包中尋找。有了候選的子系統(tǒng)，進一步在其中尋找能夠獨立開發(fā)或封裝了易發(fā)生變化的