用UML設計Java應用程序之需求分析
本節向大家介紹一下如何用UML設計Java應用程序， 這里就以圖書館借閱和預定圖書和雜志的應用程序為例向大家講解，主要有需求分析和域分析等內容，相信本節的學習一定會讓你對UML設計有新的理解。
用UML設計Java應用程序
本文的案例學習提供了一個例子，說明如何將UML用在現實中。一個處理圖書館借閱和預定圖書和雜志的應用程序，可以大到足夠檢驗UML解決現實問題能力的程度。但是如果太大的話，則不適合在雜志上發表。
在分析模型中，用用例和域分析描述了應用程序。我們進一步把它擴展成設計模型。在設計模型中，我們描述了典型的技術解決方案細節。***，我們編寫了一段Java代碼（代碼連同完整的分析和設計模型放在網上，以一種包括評估版在內的RationalRose能夠識別的格式在線提供。）
必須注意，這里只是一個可行的解決方案。可能會有許多其他的解決方案。沒有絕對正確的方案。當然，有的方案更好一些，但只有不斷的實踐和努力的工作才能掌握相應的技能。
1．需求（Requirements）
典型地，由系統最終用戶的代表寫出文本形式的需求規范文檔。UML設計中對于該圖書館應用程序來說，需求規范文檔應該類似于這樣：
1.這是一個圖書館支持系統；
2.圖書館將圖書和雜志借給借書者。借書者已經預先注冊，圖書和雜志也預先注冊；
3.圖書館負責新書的購買。每一本圖書都購進多本書。當舊書超期或破舊不堪時，從圖書館中去掉。
4.圖書管理員是圖書館的員工。他們的工作就是和讀者打交道并在軟件系統的支持下工作。
5.借閱人可以預定當前沒有的圖書和雜志。這樣，當他所預定的圖書和雜志歸還回來或購進時，就通知預定人。當預定了某書的借書者借閱了該書后，預定就取消。或者通過顯式的取消過程強行取消預定。
6.圖書館能夠容易地建立、修改和刪除標題、借書者、借閱信息和預定信息。
7.系統能夠運行在所有流行的技術環境中，包括Unix,Windows和OS/2，并應有一個現代的圖形用戶界面(GUI)。
8.系統容易擴展新功能。
系統的***版不必考慮預定的圖書到達后通知預定人的功能，也不必檢查借書過期的情況。
2．分析（Analysis）
系統分析的目的是捕獲和描述所有的系統需求，并且建立一個模型來定義系統中主要的域類。通過系統分析達到開發者和需求者的理解和溝通。因此，分析一般都是分析員和用戶協作的產物。在這個階段，程序開發者不應該考慮代碼或程序的問題；它只是理解需求和實現系統的***步。
2．1需求分析（RequirementsAnalysis）
UML設計中需求分析的***步是確定系統能夠做什么？誰來使用這個系統？這些分別叫角色（actors）和用例（usecases）。用例描述了系統提供什么樣的功能。通過閱讀和分析文檔，以及和潛在的用戶討論系統來分析用例。#p#
圖書館的角色定為圖書管理員和借書人。圖書管理員是軟件系統的用戶；而借書者則是來借閱或預定圖書雜志的客戶。偶爾，圖書管理員或圖書館的其他工作人員也可能是一個借書者。借書者不直接和系統交互，借書人的功能由圖書管理員代為執行。
圖書館系統中的用例有：
1.借書
2.還書
3.預定
4.取消預定
5.增加標題
6.修改或刪除標題
7.增加書目
8.刪除書目
9.增加借書者
10.修改或刪除借書者
由于一本書通常有多個備份，因此系統必須將書的標題和書目的概念區分開。
UML設計中圖書館系統分析的結果寫在UML用例圖中。每一個用例都附帶有文本文檔，描述用例和客戶交互的細節。文本是通過與客戶討論得到的。用例“借書”描述如下：
1．如果借閱者沒有預定：
◆確定標題
◆確定該標題下有效的書目
◆確定借書者
◆圖書館將書借出
◆登記一個新的借閱
2．如果借閱者有預定：
◆確定借書人
◆確定標題
◆確定該標題下有效的書目
◆圖書館將相應的書目借出
◆登記一個新的借閱
◆取消預定
除了定義系統的功能需求之外，在分析過程中用例用于檢查是否有相應的域類已經被定義，然后他們可以被用在設計階段，確保解決方案可以有效地處理系統功能。可以在順序圖中可視化實現細節。
圖1：角色和用例。分析中的***步就是指出系統能被用來做什么，誰將去使用它。它們分別就是用例和角色。所有的用例必須始于角色，而且有些用例也結束于角色。角色是位于你所工作的系統外部的人或其他系統。一臺打印機或一個數據庫都可能是一個角色。本系統有兩個角色：借閱者和圖書管理員。通過與用戶或客戶的討論，可以將每一個用例用文字進行說明。
2．2域分析（DomainAnalysis）
UML設計時系統分析也詳細地列出了域（系統中的關鍵類）。為了導出一個域分析，可以閱讀規范文檔（specifications）和用例，查找哪一些概念應該被系統處理。或者組織一個集體討論，在用戶及領域專家共同的參與下指出系統中必須處理的關鍵概念，以及它們之間的關系。
圖書館系統中的域類如下：borrowerinformation（如此命名是為了與用例圖中的角色borrower區分開來），title，booktitle,magazinetitle,item,reservation和loan。這些類以及它們之間的關系記錄在類圖文檔中，如圖2所示。域類定義為Businessobject版型，Businessobject版型是一個用戶自定義的版型，指定該類的對象是關鍵域的一部分，并且應該在系統中持久存儲。
其中有些類有UML狀態圖，用來顯示這些類的對象可能具有的不同狀態，以及觸發他們的狀態發生改變的事件。該例子中有狀態圖的類是item和title類。
用例lenditem（借閱者沒有預定的情況）的順序圖顯示在圖3中。所有用例的順序圖都可從在線模型中查到。
圖2：域類結構。域分析詳細說明了系統中的關鍵類。對每一個對象而言，如果它調用了其他對象的方法，那么在他們之間就用一條直線連結起來，以顯示他們之間的關系。每一個代表類的四邊形被分成了三部分，最頂層包括類的名稱，中間一層是類的屬性，***層是類的方法。類之間的直線是關聯，用來指出一個對象調用另一個對象的方法。如果再仔細看，將會發現在Loan和Item之間的關聯關系中靠近Loan的一端有“0..1”,這代表關聯的重數。重數“0..1表示Item可以感知0個到1個loan。其他可能出現的重數還有：“0..*”表示0或多；“1”表示就是1；“0”表示就是0，“1..*”表示1或多。
當對順序圖建模時，必須提供窗體和對話框作為人機交互的界面。在本分析當中，只要知道借書、預定和還書需要窗體就可以了。在此，詳細的界面不必考慮。
為了把系統中的窗體類和域類分開，所有的窗體類組織在一起放在GUIPackage包中。域類組織在一起放在BusinessPackage包中。
圖3：Lenditem場景的順序圖。UML設計中場景是從頭到尾實現一個用例的一次特定的過程。場景總是始于角色，而角色是屬于系統外部的。場景描繪了從所有角色的觀點出發，完成一次系統動作的完整過程。UML在用順序圖來圖示場景。本用例圖顯示了在借閱者沒有預定圖書的情況下的Lend用例。橫在圖的頂部的是參與交互的對象。自上而下表示時間的流逝。首先，圖書管理員嘗試去查找標題。標有“LendingWindow”的是用戶界面，在分析階段作為一個粗略的對象。橫在順序圖中的每一個箭頭都是一次方法的調用，箭頭的首端是調用的對象，箭頭的末端是被調用的對象。
【編輯推薦】
