對于大中型信息系統(tǒng),，很難直接進行需求分析設計，需要借助模型來分析設計系統(tǒng),，根據系統(tǒng)調研數(shù)據,，建立起目標系統(tǒng)的邏輯模型。

在 軟件工程的歷史中,，很長時間里人們一直認為需求分析是整個軟件工程中最簡單的一個步驟,，但在過去十年中越來越多的人認識到它是整個過程中最為關鍵的一個過 程。假如在需求分析時分析者們未能正確地認識到客戶的需求的話,，那么最后的軟件實際上不可能達到客戶的要求,，或者導致需求的頻繁變更，而軟件無法在規(guī)定的 時間里完工,。

在需求分析階段,，要對經過可行性分析所確定的系統(tǒng)目標和功能作進一步的詳細論述,，確定系統(tǒng)“做什么？”的問題,，最終建立起目標系統(tǒng)的邏輯模型,。

首 先是獲得當前系統(tǒng)的物理模型。物理模型是對當前系統(tǒng)的真實寫照,，可能是一個由人工操作的過程,，也可能是一個已有的但需要改進的計算機系統(tǒng)。首先是要對現(xiàn)行 系統(tǒng)進行分析,、理解,，了解它的組織情況、數(shù)據流向,、輸入輸出,，資源利用情況等，在分析的基礎上畫出它的物理模型,。然后抽象出當前系統(tǒng)的邏輯模型,。

邏輯模型是在物理模型基礎上，去掉一些次要的因素,，建立起反映系統(tǒng)本質的邏輯模型,。接下來建立目標系統(tǒng)的邏輯模型。通過分析目標系統(tǒng)與當前系統(tǒng)在邏輯上的區(qū)別,，建立符合用戶需求的目標系統(tǒng)的邏輯模型,。最后補充目標系統(tǒng)的邏輯模型。對目標系統(tǒng)進行補充完善 ,將一些次要的因素補充進去,，例如出錯處理等,。

UML（The Unified Modeling Language，即統(tǒng)一建模語言）是一種編制系統(tǒng)藍圖的標準化語言,，可以對復雜的系統(tǒng)建立可視化的系統(tǒng)模型,，目前已經被工業(yè)標準化組織OMG（Object Management Group）接受，一經推出便得到許多著名的計算機廠商如Microsoft,、HP,、IBM、Oracle等的支持,，也在逐步開始應用到需求分析過程中,。

在使用UML建立當前系統(tǒng)邏輯模型過程中,，初學者通常會遇到一些問題：

1.什么時候真正需要業(yè)務模型,？什么時候用例模型獨立存在？

2.在進行精確的業(yè)務建模時能用哪些UML圖形,？如何知道是否用順序圖或者交互圖,？

3.業(yè)務模型如何涉及到其他模型（如領域模型,，用例模型等等）呢？如何有機地組織這些模型,？

本文將通過圖書館管理系統(tǒng)這個簡單而典型的實例來進行一次UML需求分析實踐之旅,。

許多讀者對圖書館圖書管理工作比較熟悉，主要是圍繞讀者,、圖書和工作人員的借還書展開工作,。我們先看看圖書館工作人員和部分讀者的需求。

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

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

當一位讀者還書時,，工作人員根據圖書證編號，找到讀者的借書信息,，查看是否超期,，如果已經超期，則進行超期處罰,。

如果圖書有破損,、丟失,，則進行破損處罰。清除借閱記錄,，同時系統(tǒng)自動查看是否有等待借閱登記,，如果有則發(fā)出通知，修改書庫記錄,，該書設置為已預訂狀態(tài),，否則設置為可借狀態(tài)。

圖書采購人員進行圖書采購時,，要參考各類圖書的庫存數(shù)和借閱率,，注意合理采購。如果有缺書登記則隨時進行采購,。正在采購的圖書組成一個采購中書庫,。

采購到貨后，進行驗收,，編號,，同時加入圖書庫，修改采購中書庫,，并且查看訂閱庫,，發(fā)出到書通知，并且已經修改書庫的圖書記錄為已預訂狀態(tài),。

借書登記是當欲借的書被借空后,，讀者自愿選擇的一種操作，它應該記錄讀者名和聯(lián)系方式,，一旦有這本書后可通知讀者,。

到書通知，當讀者預訂的書來到之后,，按照讀者給出的聯(lián)系方式發(fā)出通知,。

缺書登記是當讀者需要的書庫內查詢沒有記錄時，將此信息轉入缺貨庫,，通知采購員采購,。

圖書注銷，如果圖書丟失或舊書淘汰,，則將該書從書庫中清除,。

根據需求描述整理一張需求表：

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

（1）讀者

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

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

（2）管理員

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

示例：圖書管理員。

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

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

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

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

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

5.取消預定：提供對預定進行取消的功能,。

6.書籍查詢：為讀者提供網上的書籍查詢功能,。

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

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

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

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

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

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

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

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

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

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

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

業(yè)務對象的表示

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

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

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

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

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

用戶界面的組織

用戶界面布局圖能夠幫助組織系統(tǒng)頁面,、文件、服務的布局結構,。在UML 中,，對于頁面和文件的組織，可以使用構件圖(Component Diagram) 或類圖(Class Diagram) 建模型,。本系統(tǒng)中使用類圖對界面組織建模,，頁面結構以及各種業(yè)務服務被捆綁到不同的區(qū)域,。

在 UML 中，系統(tǒng)的體系結構使用部署圖(DeploymentDiagram) 來完成,。應用部署的規(guī)劃對于規(guī)劃整個B/ S 系統(tǒng)是很有用的,。它確定了一種有效的應用部署的規(guī)劃組織方式,還可以作為一個模式在多個類似B/ S 系統(tǒng)上應用。

在建模完成后,，開發(fā)人員利用一些UML Case工具如Rational ROSE生成程序代碼框架,，并對代碼框架進行修改和補充，形成完整代碼;而且,，還可根據代碼逆向生成 UML模型,。這就較好地保證了模型與代碼的一致性。

測試必須在整個項目周期中進行,，對每個階段都要用所建立的模型進行測試,，這樣才能保證開發(fā)的質量，減少開發(fā)的風險,。

統(tǒng) 一建模語言 UML 是國際軟件工程領域具有劃時代意義的重要成果,，適用于以面向對象技術來描述任何類型的系統(tǒng),，而且適用于系統(tǒng)開發(fā)的不同階段,，從需求規(guī)格描述直至系統(tǒng)完成后 的測試和維護。軟件系統(tǒng)的規(guī)模越來越大,，復雜度不斷提高,，RUP迭代式增量開發(fā)方式可以降低風險，同時可以適應需求變化的需要,。

在本次UML實踐之旅中,，我們通過對圖書館管理系統(tǒng)的需求進行分析，將 UML 應用于系統(tǒng)開發(fā)的各個階段,，建立了系統(tǒng)的需求模型,、靜態(tài)模型和動態(tài)模型，同時遵循Rationl統(tǒng)一過程(RUP)的核心思想和基本原則,，采用以用例為驅 動,、以體系構架為核心的迭代化面向對象分析和設計過程。

圖1：系統(tǒng)用例圖

圖2：用況活動圖

圖3：借書部分的類結構圖

UML行為圖

用況圖（use case diagram）描述了一組用況和參與者（一種特殊的類）以及它們之間的關系,。

交互圖（interaction diagram）是順序圖和協(xié)作圖的統(tǒng)稱,。

順序圖(sequence diagram)是強調消息的時間次序的交互圖。

協(xié)作圖(collaboration diagram)是強調收發(fā)消息的對象的結構組織的交互圖,。

狀態(tài)圖顯示了一個由狀態(tài),，轉換，事件和活動組成的狀態(tài)機,。

活動圖顯示了系統(tǒng)中從活動到活動的流,。