本節(jié)和大家學習一下UML建模案例分析，以圖書管理系統(tǒng)向大家介紹，為了便于大家理解采用圖示講解，希望通過本節(jié)的學習你對UML建模案例分析有一定的認識。

UML建模案例分析    

UML（TheUnifiedModelingLanguage，即統(tǒng)一建模語言）是一種編制系統(tǒng)藍圖的標準化語言，可以對復(fù)雜的系統(tǒng)建立可視化的系統(tǒng)模型，目前已經(jīng)被工業(yè)標準化組織OMG（ObjectManagementGroup）接受，一經(jīng)推出便得到許多著名的計算機廠商如Microsoft、HP、IBM、Oracle等的支持，也在逐步開始應(yīng)用到需求分析過程中。
許多讀者對圖書館圖書管理工作比較熟悉，主要是圍繞讀者、圖書和工作人員的借還書展開工作。我們先看看圖書館工作人員和部分讀者的需求。

讀者來圖書館借書，可能先查詢書庫的圖書記錄。查詢可以按書名、作者、圖書編號、關(guān)鍵字查詢。查詢有兩種結(jié)果，如果查到則記下書號，交給工作人員，然后等候辦理借書手續(xù)。如果該書已經(jīng)被全部借出，則可做借書登記，等待有書時被通知。如果圖書館沒有該書的記錄，則做缺書登記。

辦理借書手續(xù)時先要出示圖書證，沒有圖書證則去申請圖書證。如果借書數(shù)量超出規(guī)定，則提示“借書數(shù)量超限，不能繼續(xù)借閱”。工作人員登記借閱人信息、借閱的圖書信息、借出時間和應(yīng)還書時間。系統(tǒng)自動修改書庫的圖書記錄、讀者庫信息。

UML建模案例分析時要了解系統(tǒng)需求。當一位讀者還書時，工作人員根據(jù)圖書證編號，找到讀者的借書信息，查看是否超期，如果已經(jīng)超期，則進行超期處罰。
如果圖書有破損、丟失，則進行破損處罰。清除借閱記錄，同時系統(tǒng)自動查看是否有等待借閱登記，如果有則發(fā)出通知，修改書庫記錄，該書設(shè)置為已預(yù)訂狀態(tài)，否則設(shè)置為可借狀態(tài)。
圖書采購人員進行圖書采購時，要參考各類圖書的庫存數(shù)和借閱率，注意合理采購。如果有缺書登記則隨時進行采購。正在采購的圖書組成一個采購中書庫。
采購到貨后，進行驗收，編號，同時加入圖書庫，修改采購中書庫，并且查看訂閱庫，發(fā)出到書通知，并且已經(jīng)修改書庫的圖書記錄為已預(yù)訂狀態(tài)。

借書登記是當欲借的書被借空后，讀者自愿選擇的一種操作，它應(yīng)該記錄讀者名和聯(lián)系方式，一旦有這本書后可通知讀者。
到書通知，當讀者預(yù)訂的書來到之后，按照讀者給出的聯(lián)系方式發(fā)出通知。
缺書登記是當讀者需要的書庫內(nèi)查詢沒有記錄時，將此信息轉(zhuǎn)入缺貨庫，通知采購員采購。
圖書注銷，如果圖書丟失或舊書淘汰，則將該書從書庫中清除。

根據(jù)需求描述整理一張需求表：

UML建模案例分析時首先要識別出系統(tǒng)的參與者，在簡單的圖書館管理系統(tǒng)中，可以劃分出兩種參與者：讀者和管理員。當然，根據(jù)業(yè)務(wù)的復(fù)雜程度，參與者也可以進行細分，比如讀者可以再分為學生讀者、教師讀者、校外讀者，管理員根據(jù)業(yè)務(wù)和權(quán)限的不同可以再細分為庫房管理員、借還書操作員、系統(tǒng)維護人員、圖書館管理人員等不同角色。在這里，為了簡化處理，我們只列出了讀者和管理員。對參與者描述如下：

（1）讀者

描述：讀者可以借閱、預(yù)定、歸還物理書刊，可以對書籍和個人信息進行查詢，可以取消預(yù)定，可以提出辦卡申請。

示例：持有借閱卡的任何人和組織。

（2）管理員

描述：圖書管理員對系統(tǒng)進行維護，包括讀者信息的創(chuàng)建、修改、刪除，書刊信息的維護，條目信息的維護，還有系統(tǒng)信息的維護。

示例：圖書管理員。

通過識別的參與者，對需求進一步分析，將業(yè)務(wù)需求進行分解，獲得每個參與者的使用用例。在本例中，我們可以得到以下用例：

1.書籍借出：提供借閱物理書刊的功能。

2.書籍歸還：提供歸還物理書刊的功能。

3.讀者辦卡：提供為讀者辦理借閱卡的功能。

4.預(yù)定書刊：提供對某一個種類的書刊的預(yù)約功能。

5.取消預(yù)定：提供對預(yù)定進行取消的功能。

6.書籍查詢：為讀者提供網(wǎng)上的書籍查詢功能。

7.信息查詢：為讀者提供信息查詢的功能。

8.讀者信息維護：提供讀者信息的錄入、修改、查詢、刪除的功能。

9.書刊信息維護：提供物理書刊的錄入、修改、查詢、刪除的功能。

10.條目信息維護：提供書刊條目的錄入、修改、查詢、刪除的功能。

11.系統(tǒng)信息維護：提供對系統(tǒng)的參數(shù)的設(shè)置。

12.登錄：管理員需要先登錄才能進入系統(tǒng)。

并且，可以畫出如下系統(tǒng)用例圖：

通過用例圖，可以對系統(tǒng)功能有一個大概的了解，對于復(fù)雜系統(tǒng)，我們可以結(jié)合IDEF方法，通過分層分解，逐步細化的方法來描述系統(tǒng)的功能。對于用例圖，建議不要畫的過于復(fù)雜，特別是用例之間的關(guān)系，因為復(fù)雜的用例圖不僅不能讓需求分析人員與客戶之間更好的溝通，反而是制造了一種溝通障礙。

下一步就是編制每一個用例的詳細說明，對用例說明的主要信息包括有：用例名稱、編號、用例的簡短描述、用例的參與者、與其他用例的管理、用例啟動的前提條件、用例結(jié)束后的事后條件、用例的輸入、輸出、用例的執(zhí)行事件流等。在實際項目中，我們并不一定要面面俱到，而是根據(jù)實際情況對用例描述進行裁減。其中有幾點重要信息是不能裁減的：用例名稱、描述、輸入、輸出、執(zhí)行事件流、參與者。另外，如果實際情況需要，還可以使用MSVisio等工具畫出界面的示意圖來。

如上例所述，我們對每一個用例都進行詳細的描述，建立當前系統(tǒng)的功能用例模型。需求溝通與分析是一個迭代的過程，通過與用戶的不斷溝通，最終達成對目標系統(tǒng)的一致理解。如果用戶確認了需求分析的成果，一般是需求規(guī)格說明書之后，項目開始進入系統(tǒng)分析設(shè)計階段，也就是開始構(gòu)造目標系統(tǒng)的邏輯模型。

為了讓系統(tǒng)設(shè)計能夠以結(jié)構(gòu)、組織方式和代碼重用的形式表現(xiàn)出來，要對系統(tǒng)進行設(shè)計規(guī)劃，設(shè)計階段應(yīng)該與分析階段交迭。需求是不斷地發(fā)展，而設(shè)計本身也會推動需求的發(fā)展(反之亦然)。在圖書館管理系統(tǒng)的建模設(shè)計中，以下3個方面的問題是要關(guān)注的：業(yè)務(wù)對象的表示、業(yè)務(wù)服務(wù)的實現(xiàn)、用戶界面的組織。

業(yè)務(wù)對象的表示

在圖書館管理系統(tǒng)系統(tǒng)中，業(yè)務(wù)對象主要是數(shù)據(jù)庫和數(shù)據(jù)實體類的表示方式。UML建模案例分析時，可以構(gòu)造出系統(tǒng)的靜態(tài)模型，也就是系統(tǒng)類圖來表示。如下圖則描述了借書這一用例的靜態(tài)結(jié)構(gòu)圖。為了體現(xiàn)類之間的關(guān)系，在下圖中沒有顯示出每一個類的屬性和基本操作。

業(yè)務(wù)服務(wù)的實現(xiàn)

業(yè)務(wù)服務(wù)的實現(xiàn)需要完成的功能是各種業(yè)務(wù)規(guī)則和邏輯的實現(xiàn),如借書處理的業(yè)務(wù)邏輯。每個模塊的信息錄入、修改、刪除、查詢等。業(yè)務(wù)規(guī)則和邏輯的實現(xiàn)基本相似，沒有太多的規(guī)律可循。采用UML來進行業(yè)務(wù)服務(wù)的建模，可以使用UML的序列圖、狀態(tài)圖、活動圖。這個部分的工作,通常通過一系列的類之間的交互來完成。為了在更動態(tài)的層面上描述系統(tǒng)，UML提供了許多其他類型的圖。

對于B/S系統(tǒng)設(shè)計而言，情節(jié)圖(ScenarioDiagram)特別有用。情節(jié)圖分成兩種：協(xié)作圖(CollaborationDiagram)，序列圖(SequenceDiagram)。UML建模工具RationalRose能夠從協(xié)作圖生成序列圖也可以從序列圖生成協(xié)作圖。例如，借閱書刊的業(yè)務(wù)過程可以采用如下序列圖來描述：

借閱書刊過程主要包括：管理員選擇“借閱書刊”菜單，彈出對話框，管理員輸入書刊信息和用戶信息，系統(tǒng)查找數(shù)據(jù)庫，是否存在該種物理書刊，如果不存在，顯示提示信息，用例結(jié)束;是否存在借閱者信息，如果不存在，顯示提示信息，用例結(jié)束;否則，管理員單擊確認按鈕后，該圖書借閱給該借閱者，系統(tǒng)存儲借閱信息到數(shù)據(jù)庫。

【編輯推薦】

1. 實例講解UML建模分析與設(shè)計
2. UML實例教程 圖書管理系統(tǒng)中UML建模分析與設(shè)計
3. 專家指導 UML建模分析步驟
4. UML建模時需要注意的四大問題
5. 解析九大UML建模圖形用法