構(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)實(shí)例研究10.7小結(jié)習(xí)題10

知識(shí)點(diǎn)

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

難點(diǎn)

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

基于工作過(guò)程的教學(xué)任務(wù)

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

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

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

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

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

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

10.1構(gòu)架概述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1．理解系統(tǒng)

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

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

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

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

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

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

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

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

2．組織開(kāi)發(fā)

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

3．鼓勵(lì)重用

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

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

4．演化系統(tǒng)

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

10.3用

例

和

構(gòu)

架

如果系統(tǒng)提供了適當(dāng)?shù)挠美?，用戶就可以使用該系統(tǒng)來(lái)完成自己的任務(wù)。但如何實(shí)現(xiàn)這一目標(biāo)呢？這就需要構(gòu)造一個(gè)允許無(wú)論是現(xiàn)在還是將來(lái)都能有效實(shí)現(xiàn)用例的構(gòu)架。

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

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

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

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

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

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

需要適應(yīng)哪些政策和公司標(biāo)準(zhǔn)，例如，可選擇OMG的接口定義語(yǔ)言(IDL)來(lái)確定類(lèi)的所有接口，或選擇遠(yuǎn)程通信規(guī)范TMN來(lái)說(shuō)明系統(tǒng)中的對(duì)象；

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

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

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

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

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

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

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

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

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

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

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

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

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

圖10-3用例驅(qū)動(dòng)構(gòu)架的開(kāi)發(fā)，構(gòu)架指導(dǎo)用例的實(shí)現(xiàn)

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

總之，一個(gè)好的構(gòu)架無(wú)論是現(xiàn)在還是將來(lái)，都能有效地補(bǔ)充適當(dāng)?shù)挠美?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.4.3描述構(gòu)架

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

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

如圖10-6所示，在構(gòu)造階段，各種模型趨于完成(右上角填充陰影的圖形)。因?yàn)榇蠖鄶?shù)構(gòu)架在細(xì)化階段定義，所以構(gòu)架描述沒(méi)有明顯變化(右下圖)。構(gòu)架的細(xì)微變化確實(shí)發(fā)生(由不同的填充圖案表示)。

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

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

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

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

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

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

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

當(dāng)然，說(shuō)明實(shí)現(xiàn)通用機(jī)制的框架也很重要，例如，在關(guān)系數(shù)據(jù)庫(kù)中存儲(chǔ)或檢索對(duì)象。這些機(jī)制可在多個(gè)用例實(shí)現(xiàn)中得到重用，因?yàn)樗鼈兙褪菫閷?shí)現(xiàn)可重用的協(xié)作而設(shè)計(jì)的。構(gòu)架描述還應(yīng)該對(duì)所有使用過(guò)的構(gòu)架模式進(jìn)行歸檔。

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

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

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

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

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

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

合格的構(gòu)架設(shè)計(jì)師需要具備兩種能力。一種是他所從事的領(lǐng)域知識(shí)，因?yàn)樗仨毰c所有項(xiàng)目相關(guān)人員配合，不只是開(kāi)發(fā)人員。另一種就是軟件開(kāi)發(fā)知識(shí)，甚至是最基本的編碼能力，因?yàn)樗仨毾蜷_(kāi)發(fā)人員說(shuō)明構(gòu)架，協(xié)調(diào)他們的工作，了解他們的反饋。

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

10.4.5構(gòu)架師

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

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

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

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

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

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

1.確定目標(biāo)

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

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

2.將類(lèi)分組

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

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

當(dāng)然，也可以從職責(zé)的角度對(duì)分析類(lèi)分組。例如，如果每個(gè)實(shí)體類(lèi)，都有多個(gè)控制類(lèi)對(duì)其進(jìn)行訪問(wèn)，那么所有的實(shí)體類(lèi)應(yīng)該屬于一個(gè)層次，對(duì)控制類(lèi)來(lái)說(shuō)同樣如此，因?yàn)椋總€(gè)控制類(lèi)都能和同一邊界類(lèi)的不同版本進(jìn)行交互。

3.展示技術(shù)

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

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

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

5.應(yīng)用原則和目標(biāo)對(duì)構(gòu)架進(jìn)行評(píng)估

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

10.5構(gòu)架描述

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

構(gòu)架描述包括五個(gè)部分，每部分說(shuō)明一個(gè)模型：用例模型視圖、分析模型視圖(不一定總有)、設(shè)計(jì)模型視圖、實(shí)施模型視圖和實(shí)現(xiàn)模型視圖。構(gòu)架描述不包括測(cè)試模型視圖，因?yàn)樗鼘?duì)描述構(gòu)架不起作用，它只是用來(lái)驗(yàn)證構(gòu)架基線。

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

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

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

在ATM的例子中，“取款”是最重要的用例。沒(méi)有它，也就沒(méi)有實(shí)際的ATM系統(tǒng)。“存款”和“轉(zhuǎn)賬”用例對(duì)一般的銀行儲(chǔ)戶來(lái)講不太重要。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(2)“ATM接口”請(qǐng)求“事務(wù)管理”子系統(tǒng)取款。“事務(wù)管理”子系統(tǒng)負(fù)責(zé)將提取現(xiàn)金的整個(gè)動(dòng)作序列作為一個(gè)原子事務(wù)來(lái)執(zhí)行，以便從賬戶中扣除取款金額，并將現(xiàn)金分發(fā)給儲(chǔ)戶。

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

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

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

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

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

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

實(shí)施模型的節(jié)點(diǎn)和連接以及分配給節(jié)點(diǎn)的主動(dòng)對(duì)象可以在實(shí)施圖中表示出來(lái)，這些圖還可以表明如何將可運(yùn)行的構(gòu)件分配給節(jié)點(diǎn)。

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

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

圖10-10實(shí)施模型定義的三個(gè)節(jié)點(diǎn)

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

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

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

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

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

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

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

建立一個(gè)堅(jiān)實(shí)、可靠的構(gòu)架需要針對(duì)項(xiàng)目付出專(zhuān)門(mén)的努力。在建立構(gòu)架過(guò)程中，嚴(yán)格遵循一個(gè)合理且嚴(yán)格定義的過(guò)程會(huì)在整個(gè)項(xiàng)目的生命周期內(nèi)都受益。

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

(1)清晰準(zhǔn)確地理解問(wèn)題。

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

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

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

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

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

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

10.6.1確立目標(biāo)

第一步，確立系統(tǒng)目標(biāo)。在某些情況下，系統(tǒng)目標(biāo)是由外在的需求確立的。例如，在補(bǔ)充需求中，經(jīng)常會(huì)明確地提出可靠性和可伸縮性等方面的需求，可維護(hù)性和可擴(kuò)展性往往由開(kāi)發(fā)人員決定，因?yàn)橹挥虚_(kāi)發(fā)人員才知道系統(tǒng)是如何開(kāi)發(fā)的，能夠估計(jì)出需求的穩(wěn)定性。

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

可維護(hù)性。考勤系統(tǒng)必須易于理解和維護(hù)。公司有不同的團(tuán)隊(duì)負(fù)責(zé)系統(tǒng)維護(hù)和新項(xiàng)目開(kāi)發(fā)，所以該系統(tǒng)會(huì)移交給新的團(tuán)隊(duì)負(fù)責(zé)。

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

可伸縮性。因?yàn)楣居?jì)劃快速發(fā)展，所以考勤系統(tǒng)必須能夠擴(kuò)大以適應(yīng)更多的數(shù)據(jù)和更多的用戶。

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

10.6.2將類(lèi)分組并評(píng)估每個(gè)類(lèi)

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

1.將類(lèi)分組

通過(guò)分析(第9章)，識(shí)別出了五組分析類(lèi)。

實(shí)體類(lèi)；

用戶界面類(lèi)；

控制類(lèi)；

系統(tǒng)接口類(lèi)；

定位器類(lèi)。

下面，以這些組為候選包，對(duì)其內(nèi)聚進(jìn)行評(píng)估。如果一個(gè)包的內(nèi)聚很高，就使用分析時(shí)建立的類(lèi)圖來(lái)進(jìn)一步評(píng)估其耦合度。在某些情況下，這種過(guò)分簡(jiǎn)化了的分層方法會(huì)失敗，因?yàn)椴煌?lèi)型的類(lèi)之間的協(xié)作甚至強(qiáng)于相同類(lèi)型的類(lèi)之間的協(xié)作，這就是最簡(jiǎn)單的方法。

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

因?yàn)椴煌?lèi)型的類(lèi)之間的協(xié)作甚至強(qiáng)于相同類(lèi)型的類(lèi)之間的協(xié)作，這就是最簡(jiǎn)單的方法。

另外，還需要為包重新命名，因?yàn)閷?shí)體類(lèi)過(guò)于簡(jiǎn)單，而且含糊不清。由于所有的類(lèi)都是考勤模型的一部分，所以稱(chēng)之為T(mén)imeCardDomain很合適。圖10-12顯示了該包及其中

的類(lèi)。

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

圖10-12TimeCardDomain包

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

圖10-13TimeCardUI包

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

圖10-14TimeCardWorkflow包

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

的類(lèi)。

圖10-15BillingSystemInterface包

定位器類(lèi)是因?yàn)橛肊JB技術(shù)來(lái)實(shí)現(xiàn)實(shí)體類(lèi)，所以不需要任何單獨(dú)的定位器類(lèi)。Home接口為每個(gè)實(shí)體類(lèi)提供了此項(xiàng)功能。

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

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

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

圖10-16～圖10-18重現(xiàn)了它們?cè)诘?章中的樣子。

圖10-16參與“Login”用例的類(lèi)的類(lèi)圖圖10-17參與“RecordTime”用例的類(lèi)的類(lèi)圖圖10-18參與“ExportTimeEntries”用例的類(lèi)的類(lèi)圖

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

圖10-19為所有類(lèi)以及其關(guān)系。在生成該圖的過(guò)程中，ExportEntriesUI直接依賴(lài)來(lái)自TimeCardDomain包中的類(lèi)，看起來(lái)有點(diǎn)怪，因?yàn)槠渌挠脩艚缑骖?lèi)都依賴(lài)TimeCardWorkflow包中的類(lèi)，后者又依賴(lài)TimeCardDomain包。

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

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

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

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

10.6.3展示技術(shù)

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

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

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

10.6.4抽取子系統(tǒng)

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