使用UML對圖書館系統(tǒng)進行建模

1、使用UML對系統(tǒng)進行建模面向?qū)ο蟮能浖こ?，同傳統(tǒng)的面向過程的軟件工程相比，在需求的獲取、系統(tǒng)分析、設(shè)計和實現(xiàn)方面都有著很大的區(qū)別。UML是OOA和OOD的常用工具。使用UML來構(gòu)建軟件的面向?qū)ο蟮能浖こ痰倪^程，就是一個對系統(tǒng)進行不斷精化的建模的過程。這些模型包括用例模型、分析模型、設(shè)計模型，然后，我們需要使用具體的計算機語言來建立系統(tǒng)的實現(xiàn)模型。當然，在整個軟件工程中，我們還需要建立系統(tǒng)的測試模型，以保證軟件產(chǎn)品的使用面向?qū)ο蟮墓ぞ邅順?gòu)建系統(tǒng)，就應該使用面向?qū)ο蟮能浖こ谭椒?。然我，我們?jīng)常會發(fā)現(xiàn)，在實際的開發(fā)過程中，很多開發(fā)人員雖然能夠理解UML的所有圖形，卻仍然不能得心應手的使用UML

2、來構(gòu)建整個項目，其很大的原因，是仍然在使用原有的軟件工程方法，而不清楚如何使用UML來建立系統(tǒng)的這些模型，不清楚分析和設(shè)計的區(qū)別，以及他們之間的轉(zhuǎn)化。應用軟件系統(tǒng)，就其本質(zhì)來說，是使用計算機對現(xiàn)實世界進行的數(shù)字化模擬。應用軟件的制造過程，按照UML的方法，就是建立這一些列模型的過程。本文將就一個圖書館系統(tǒng)，說明如何使用UML來對系統(tǒng)進行這一系列的建模。關(guān)于這個圖書館系統(tǒng)，基本的需求比較簡單，就是允許學生可以在圖書館借閱和歸還圖書，另外，也可以通過網(wǎng)絡或者圖書館的終端來查閱和預訂書。當然，圖書館管理員也可以對圖書進行管理。為了簡化系統(tǒng)，我們沒有把圖書館中的人員作細分。之所以采用這個相對簡單案例，

3、是因為很多人都對圖書館系統(tǒng)有很強的感性認識，這樣，讀者不需要花很多的時間來理解系統(tǒng)包含的業(yè)務知識。同時，也因為本文只是對使用UML的過程做一個探討，著眼于使用UML進行建模的過程，說明各個層次的模型之間的區(qū)別和聯(lián)系，展示系統(tǒng)演進的過程，而不會深入UML的細節(jié)方面。對于更加復雜的系統(tǒng)，其分析和設(shè)計的方法是相通的，可以舉一反三。用例模型系統(tǒng)需求的獲取用例模型定義系統(tǒng)做什么，是用來獲取系統(tǒng)需求的有效手段。用例模型由“角色”和“用例”組成。我們在構(gòu)建一個用例的時候，通常要做的第一件事情是識別角色，或者說，參與者。然后我們我們需要識別系統(tǒng)為參與者提供的服務，或者說，參與者的行為，也就是用例。最后，我們確

4、定角色和用例之間的關(guān)系。在這個圖書館系統(tǒng)中，我們可以識別出的角色有學生和圖書管理員。整個用例模型包含的用例有：借書、還書、查閱圖書、預訂圖書，以及圖書維護。用例模型可以用用例圖表示如下：學生預定圖書查閱圖書借書還書管理圖書圖書管理員確定有效用例的關(guān)鍵是，檢查用例是否包含了一個完整的功能。用例不能定的過細，不能把一個完整的功能的一個部分作為一個用例，也不能在一個用例中包含過多的功能。例如，用戶的登錄。學生在預定圖書的時候，可能會需要首先登錄系統(tǒng)，這是系統(tǒng)的一個功能。但是，這個功能只是預定圖書這個完整的功能中的一個步驟，或者說一個子功能，就不適于做成一個用例。另一方面，借書和還書，都是相對完整的功

5、能，如果把這兩個用例合并成一個類似于“處理圖書”的用例，顯然是不能明確的表達用例需要表達的含義的。描述用例需要了解的是，使用UML進行系統(tǒng)建模，并非只是意味著畫UML圖形，對UML圖的文檔說明是同樣重要的。學習UML，不僅僅要學習UML圖形，相應的文檔描述方法也同樣要學習，也同樣重要。在描述用例時，我們可以用文字來描述，也可以用其他圖形來描述，例如，順序圖或者活動圖等等。下面給出了一個RUP中推薦的描述用例的完整的結(jié)構(gòu)：名稱。名稱無疑應該表明用戶的意圖或用例的用途，女研究班招生”。標識符可選。唯一標識符，如UC1701,在項目的其他元素（如類模型）中可用它來引用這個用例。說明。概述用例的幾句話

6、。參與者可選。與此用例相關(guān)的參與者列表。盡管這則信息包含在用例本身中，但在沒有用例圖時，它有助于增加對該用例的理解。狀態(tài)冋選。指示用例的狀態(tài)，通常為以下幾種之一：進行中、等待審查、通過審查或未通過審查。頻率。參與者訪問此用例的頻率。這是一個自由式問題，如用戶每次錄訪問一次或每月一次。前置條件。一個條件列表，如果其中包含條件，則這些條件必須在訪問用例之前得到滿足。后置條件。一個條件列表，如果其中包含條件，則這些條件將在用例成功完成以后得到滿足。被擴展的用例可選。此用例所擴展的用例(如果存在)。擴展關(guān)聯(lián)是一種廣義關(guān)系，其中擴展用例接續(xù)基用例的行為。這是通過擴展用例向基用例的操作序列中插入附加的操作

7、序列來實現(xiàn)的。這總是使用帶有vvextend的用例關(guān)聯(lián)來建模的。被包含的用例可選。此用例所包含用例的列表。包含關(guān)聯(lián)是一種廣義關(guān)系，它表明對處于另一個用例之中的用例所描述的行為的包含關(guān)系。這總是使用帶有vvinclude的用例關(guān)聯(lián)來建模的。也稱為使用或具有(has-a)關(guān)系。假設(shè)可選。對編寫此用例時所創(chuàng)建的域的任何重要假設(shè)。您應該在一定的時候檢驗這些假設(shè)，或者將它們變?yōu)闆Q策的一部分，或者將它們添加到操作的基本流程或可選流程中?；静僮髁鞒獭⑴c者在用例中所遵循的主邏輯路徑。因為它描述了當各項工作都正常進行時用例的工作方式，所以通常稱其為適當路徑(happypath)或主路徑(mainpath)。

8、可選操作流程。用例中很少使用的邏輯路徑，那些在變更工作方式、出現(xiàn)異常或發(fā)生錯誤的情況下所遵循的路徑。修改歷史記錄冋選。關(guān)于用例的修改時間、修改原因和修改人的詳細信息。問題冋選。如果存在，貝I為與此用例的開發(fā)相關(guān)的問題或操作項目的列表。決策。關(guān)鍵決策的列表，這些決策通常由您的SME作出，并屬于用例的內(nèi)容。將這些決策記錄下來對于維護團體記憶庫(groupmemory)是相當重要的。下面，我們對借書這個用例來做描述：名稱：借書”。說明：學生在圖書館挑選好需要的圖書后，通過圖書管理員把書借回去。參與者：學生，圖書管理員頻率：每天可能會有很多次。最繁忙的情況是，借書的人非常多，按照現(xiàn)在的速度，大約每分鐘

9、完成一個人的結(jié)束工作。前置條件：無后置條件：修改所借出的圖書的剩余數(shù)量。假設(shè)：借書者總是從圖書館找到書，然后才能拿書辦理借書手續(xù)，因此，總是有足夠的書可以出借。基本操作流程：借書成功。學生將所借圖書和借書證交給圖書管理員圖書管理員將學生借書證號碼和所借圖書輸入系統(tǒng)系統(tǒng)校對借書信息，比對該學生以往借書情況和當前借書情況，如果不存在不允許借書的情況，則記錄借書交易的信息，并且修改相應的館藏圖書的數(shù)量信息。如果該學生已經(jīng)預訂了這本圖書，則撤銷該預定。報告交易成功?？蛇x操作流程：所借圖書超出最大借書數(shù)量。學生將所借圖書和借書證交給圖書管理員2）圖書管理員將學生借書證號碼和所借圖書輸入系統(tǒng)3）系統(tǒng)校對借

10、書信息，比對該學生以往借書情況和當前借書情況，發(fā)現(xiàn)已超出最大借書數(shù)量，則停止當前交易，并且提示用戶錯誤原因。4）圖書管理員可以應學生的意見，減少借書數(shù)量，并重新提交系統(tǒng)。流程活動圖：見圖一。未預定借書成功借書數(shù)量在允許范圍內(nèi)圖一：借書活動圖問題：暫無。決策：略。上面，我們就這個用例做了一個比較詳細的描述。按部就班，我們就可以逐步把整個系統(tǒng)的用例模型完成。再次強調(diào)一點，使用UML建模，文檔說明和圖形同樣重要，并且，要使用UML的方法來編寫文檔。分析模型開發(fā)者的視野在系統(tǒng)分析的過程中，我們所關(guān)注的依然是問題，但是，同用例模型不同的是，用例模型是從最終用戶的角度來看待問題，而分析模型是從開發(fā)者的角度

11、來描述問題。用例模型的主要工作是描述現(xiàn)實世界的業(yè)務流程，而很少會涉及系統(tǒng)的概念。分析，則是從系統(tǒng)的角度來來看待軟件應該為用戶提供的服務。同樣，同設(shè)計不同的是，分析仍然停留在“做什么”的層次，。而設(shè)計，則需要解決“怎么做的問題”。開發(fā)語言等技術(shù)選擇通常不會在分析模型中考慮。分析模型是獨立于實現(xiàn)的，這樣，可以提供最大的復用，并且，可以幫助開發(fā)人員方知過早的陷入技術(shù)的細節(jié)中去，從而能夠從一個更加一般的角度去理清思路。靜態(tài)模型的建立進行分析建模的第一步，通常是識別對象，然后提取出類?？紤]著名的MVC模式，我們需要識別實體、控制和邊界三種對象。按照MVC模式來為識別對象做指導，是非常好的做法。對象識別的

12、結(jié)果，就是我們所需要的靜態(tài)模型，通常表現(xiàn)為類圖。我們首先識別出實體對象，這些對象通常來說是比較明顯的，例如系統(tǒng)中的角色，系統(tǒng)需要處理的資料，如本系統(tǒng)中需要處理的圖書資料等；有些實體對象需要稍微分析一下才能得到，例如，在本系統(tǒng)中，為了記錄圖書借還的信息，我們可能需要一個對象來專門記錄這一信息。這些對象就是所謂的Modal(實體類)。然后我們需要識別為了完成系統(tǒng)業(yè)務邏輯而需要的業(yè)務邏輯對象，以及同用戶進行交互的界面類，在MVC模式中，他們分別對應于Control(控制類)和View(邊界類)。在分析階段，這些對象通常都按照比較自然的方式來組織，例如，為了完成一個業(yè)務功能，我們通常需要一個控制類和一

13、個邊界類，控制類執(zhí)行業(yè)務邏輯，邊界類同客戶進行交互。當然，這不是絕對的，在進行進一步深入的分析后，這些類可能會被分解和合并。一口不能把所有的飯都吃掉，系統(tǒng)分析也是這樣。我們需要一個一個用例的來進行分析。現(xiàn)在，我們首先來分析借書這個用例。在這個用例中，我們首先可以識別出一些直接的對象，包括圖書管理員(BookAdmin)、學生(Student)、圖書(Book)，然后，稍作分析，我們會發(fā)現(xiàn)我們需要一個實體對象來記錄圖書的借還信息(BorrowInfo)。最后，我們發(fā)現(xiàn)，在借書的過程中，我們會使用到預定圖書的信息(SubscribrInfo)。到這一步，我們基本完成了實體對象的識別。然后，我們發(fā)現(xiàn)

14、我們需要一個借書的控制類(Borrow)來執(zhí)行借書的動作，以及一個用戶界面(BorrowInterface)來接受用戶的輸入。這樣，初步的模型我們就可以建立了。Book圖二：借書類圖在分析模型中，我們也需要識別出類的一些屬性和方法。同樣的，為了避免過早的陷入細節(jié)中，以及適應將來在設(shè)計時類的變化，在分析模型中，我們一般只把一些主要的屬性和方法標識出來。例如，對于Student類，我們只需要Name和CardNo（借書證號）屬性，對于Book，我們只需要BooKID、AllCount（書的總數(shù)）、CurrentCount（當前數(shù)量）等屬性?，F(xiàn)在，我們?yōu)槲覀兊念悎D添加上述屬性，就可以得到下面的結(jié)果：

15、BookBooklDoAHCount?CurrentCount圖三：借書類圖不過，把這些屬性都標上后，圖形就比較難布置。因為文章版面的問題，在以后的文字中，除非必要，一般會把屬性都隱藏起來，這樣，看起來會整潔一些。依樣畫葫蘆，我們把還書、查閱圖書、預定圖書、管理圖書這些用例一并分析后，我們就能夠得到整個系統(tǒng)的靜態(tài)分析模型。Manage|nterfaceManageStudent圖書管理員ReturnInterfaceReturn(fromUseCase.BorrowinterfaceBorrowBookSearchInterfaceSearch學生Subscribrinfo產(chǎn)、Tr(fromU

16、seCase.SubscribeinterfaceSubscribe當然，我們隨后需要對這個初步的模型作進一步的整理和分析，類圖會發(fā)生變化，各個類之間會產(chǎn)生一些聯(lián)系。我們也可能會使用一些分析模式，來進一步優(yōu)化我們的分析結(jié)果關(guān)于分析模型的知識，可以參見MartinFowler所著的AnalysisPatternsReusableObjectModels一書。在這里，我們就不進一步做探討了。動態(tài)模型的建立在面向?qū)ο蟮南到y(tǒng)中，業(yè)務流程表現(xiàn)為對象之間的交互。我們有了上面分析的得到的對象后，就可以來描述他們是怎么進行交互和協(xié)作的了。在UML中，我們可以使用順序圖、活動圖或者狀態(tài)圖來建模這些動態(tài)的過程。同

17、樣的，我們首先來看借書這個用例。在借書這個用例中，有兩個事件流：借書成功（正常事件流）和所借圖書超出最大借書數(shù)量（非正常事件流）。我們首先來做“借書成功”這個事件流，下面是這個事件流的順序圖：分析過程中，消息的傳遞同后面的設(shè)計模型和實現(xiàn)模型相比，可能會有區(qū)別，也不太嚴密，例如，Borrow的過程中，記錄BorrowInfo的動作，到最后，可能不會是BorrowInfo這個實體類自己來記錄（往往會有一個實體訪問類來完成這個功能，如JDO中的PersistanceManager，這取決于你采用的具體的技術(shù)框架），但是，在這里，我們可以這樣來傳遞消息，表示需要記錄這個信息。同樣的，我們也可以為“所借

18、圖書超出最大借書數(shù)量”來作他的順序圖，這個圖相對簡單一些：:圖書管理員:BorrowInterface:Borrow:Student1:打開借書界面n旳丿2:輸入借書信息htT3:提交借書請求4:Borrow()5:檢查借書數(shù)目6:INVALID戈:FAILMessage8:顯示借書失敗同樣的，我們也可以為其他用例的其他事件流創(chuàng)建動態(tài)模型，在這里就不一一畫出來了。動態(tài)模型和靜態(tài)模型的建立是一個交互的過程。在建立動態(tài)模型的過程中，我們會發(fā)現(xiàn)一些新的類，也會為已有的類找到一些新的屬性和方法，這樣，我們會需要去修改我們的類圖。反之亦然。當分析模型完成后，我們就對系統(tǒng)需要完成的功能有了一個比較完整和清

19、晰的認識，下面，就可以開始我們的設(shè)計工作了。系統(tǒng)設(shè)計實現(xiàn)方案設(shè)計是對系統(tǒng)的詳細描述。我們需要在這里提供詳細的解決方案。設(shè)計同分析所使用的工具一樣，也需要建立靜態(tài)和動態(tài)的模型，也同樣使用類圖、順序圖、協(xié)作圖、活動圖、狀態(tài)圖等來表示。在正式進行設(shè)計之前，我們還有一些工作需要完成，那就是選擇我們的技術(shù)方案，這會影響到我們設(shè)計。技術(shù)選擇設(shè)計前的工作設(shè)計是為實現(xiàn)服務的，實現(xiàn)時準備采用的技術(shù)會影響設(shè)計方案的采用。以下這些技術(shù)問題是需要考慮的：準備使用什么樣的客戶端？準備采用什么編程語言？準備采用什么框架技術(shù)？如果是分布式系統(tǒng)，那么，準備采用什么通信機制？在這個圖書館系統(tǒng)中，我們發(fā)現(xiàn)，對于借書和還書來說，總

20、是在圖書館內(nèi)部發(fā)生，并且客戶端的數(shù)量是有限的數(shù)個，其使用的頻率比較高，效率和使用的方便性是需要注重考慮的，而客戶端軟件的維護工作量相對比較少，可以不用考慮太多，因此我們準備采用傳統(tǒng)的WindowsForm的客戶端。但是，對于圖書的查閱以及預定來說，我們希望在整個校園網(wǎng)內(nèi)提供這個功能，使得學生無論在什么地方都能夠使用這個功能，所以，我們會考慮采用Web瀏覽器的客戶端，這樣會方便系統(tǒng)的部署。也就是說，我們的系統(tǒng)需要同時支持兩種不的客戶，顯然，采用N層系統(tǒng)結(jié)構(gòu)，把系統(tǒng)邏輯集中在應用服務器上是一個比較好的方案。最后，為了系統(tǒng)的安全，我們希望把Web服務器和應用服務器分開。這樣，我們的系統(tǒng)的架構(gòu)的拓撲圖

21、就基本上如下所示：這是一個典型的分布式系統(tǒng)，在考慮了各種平臺和技術(shù)之后，我們決定采用EJB技術(shù)來構(gòu)建這個系統(tǒng)，他已經(jīng)為我們提供了構(gòu)建應用系統(tǒng)所需要的優(yōu)秀的技術(shù)框架，同時，我希望在客戶端和應用服務器的調(diào)用中，采用WebService的方式（試驗一下新技術(shù)：）。WindowsForm的客戶端，我們使用Java來創(chuàng)建一個Windows應用程序，Web客戶，則采用JSP技術(shù)。當然，你也可以采用微軟的Net平臺以及C#語言來完成這個工作，但是由于微軟在Net平臺上尚未提供象J2EE，或者JDO樣成熟的應用系統(tǒng)框架，因此，你必須自己來設(shè)計這個框架。在這個方面，鄙人也設(shè)計了一個自己的Websharp框架，或

22、許可以幫助你省略這方面的工作。關(guān)于Websharp的內(nèi)容，可以參見拙作面向?qū)ο蟮膽梅諏釉O(shè)計。這樣，我們在具體技術(shù)方面的決策基本上就完成了，可以開始進行具體設(shè)計了。當然，在實際項目中，可能還有很多細節(jié)的工作需要去做，例如系統(tǒng)的約定，設(shè)計規(guī)范等，但這不是本文討論的內(nèi)容。設(shè)計包或者子系統(tǒng)首先我們需要來對系統(tǒng)進行一個劃分。因為我們的系統(tǒng)是一個N層的分布式系統(tǒng)，包含了應用服務器和客戶端，而客戶端又包含了WindowsForm客戶端和Web客戶端，所以，我們首先把系統(tǒng)分成3個包：應用服務器、Winform客戶和Web客戶：因為我們的系統(tǒng)包含了5個用例，每個用例都是一個完整的子系統(tǒng)，因此，我們可以在上述

23、3個包的下面，又各自劃分成5個子包。但是，在這里，因為系統(tǒng)比較簡單，每個用例需要完成的功能都比較簡單，因此，在這里我們就不錯進一步的劃分了。設(shè)計應用服務器下面，我們首先來設(shè)計應用服務器部分。我們還是從借書這個用例開始設(shè)計。從分析模型中，我們知道，需要一個控制類來完成借書的業(yè)務邏輯，在這里，我們設(shè)計一個BorrowLogic類來完成這個功能，這個類被設(shè)計成SessionBean；同時，因為我們需要向客戶端提供服務，而我們又不希望直接把業(yè)務邏輯暴露給客戶端，所以，設(shè)計BorrowServer這個WebService來向客戶端提供服務。這樣，實際上，在分析模型中的Borrow類，在這里，被映射成了B

24、orrowLogic和BorrowServer兩個類。同樣的，我們需要Book類來記錄圖書的信息，Student來標識學生，我們也需要BorrowInfo和SubscribeInfo類來分別記錄借書和圖書預定的情況。這樣，建立設(shè)計模型中的靜態(tài)模型所需要的類基本上已經(jīng)齊全了。當然，到最后階段，我們需要為這些類補充完整屬性和方法。這些實體類，最后都被設(shè)計成EntityBean。這個部分的整個設(shè)計模型看上去就基本上會是這個樣子：然后，我們來為借書成功這個事件流設(shè)計他的動態(tài)模型。我們還是使用順序圖來表示之。設(shè)計客戶端現(xiàn)在，我們?yōu)榻钑晒@個事件流來設(shè)計客戶端?？蛻舳嗽谶@里比較簡單，他需要一個界面來接受輸入，然后，通過一個BorrowServer的客戶端把借書的請求發(fā)送給BorrowServer，我們把這個類設(shè)計成BorrowClient。類圖如下所示：其Sequent圖可以表示如下：A:圖書管理員:FormBorrow:BorrowClient:BorrowServer1:Open()Juu12:SubmitBorrow()3:Borrow()4:Borrow()5:OKMessage6:OKMessage7：DisplaySuccessMessage這樣，對于借書這個用例，我們就完成了他的設(shè)計。依葫蘆畫瓢，我們就能夠完成其他用例的設(shè)計。當然，在設(shè)計的過程中，我們可