| 對于大中型信息系統，很難直接進(jìn)行需求分析設計，需要借助模型來(lái)分析設計系統，根據系統調研數據，建立起目標系統的邏輯模型。 在 軟件工程的歷史中，很長(cháng)時(shí)間里人們一直認為需求分析是整個(gè)軟件工程中最簡(jiǎn)單的一個(gè)步驟，但在過(guò)去十年中越來(lái)越多的人認識到它是整個(gè)過(guò)程中最為關(guān)鍵的一個(gè)過(guò) 程。假如在需求分析時(shí)分析者們未能正確地認識到客戶(hù)的需求的話(huà)，那么最后的軟件實(shí)際上不可能達到客戶(hù)的要求，或者導致需求的頻繁變更，而軟件無(wú)法在規定的 時(shí)間里完工。 在需求分析階段，要對經(jīng)過(guò)可行性分析所確定的系統目標和功能作進(jìn)一步的詳細論述，確定系統“做什么？”的問(wèn)題，最終建立起目標系統的邏輯模型。 首 先是獲得當前系統的物理模型。物理模型是對當前系統的真實(shí)寫(xiě)照，可能是一個(gè)由人工操作的過(guò)程，也可能是一個(gè)已有的但需要改進(jìn)的計算機系統。首先是要對現行 系統進(jìn)行分析、理解，了解它的組織情況、數據流向、輸入輸出，資源利用情況等，在分析的基礎上畫(huà)出它的物理模型。然后抽象出當前系統的邏輯模型。 邏輯模型是在物理模型基礎上，去掉一些次要的因素，建立起反映系統本質(zhì)的邏輯模型。接下來(lái)建立目標系統的邏輯模型。通過(guò)分析目標系統與當前系統在邏輯上的區別，建立符合用戶(hù)需求的目標系統的邏輯模型。最后補充目標系統的邏輯模型。對目標系統進(jìn)行補充完善 ,將一些次要的因素補充進(jìn)去，例如出錯處理等。 UML（The Unified Modeling Language，即統一建模語(yǔ)言）是一種編制系統藍圖的標準化語(yǔ)言，可以對復雜的系統建立可視化的系統模型，目前已經(jīng)被工業(yè)標準化組織OMG（Object Management Group）接受，一經(jīng)推出便得到許多著(zhù)名的計算機廠(chǎng)商如Microsoft、HP、IBM、Oracle等的支持，也在逐步開(kāi)始應用到需求分析過(guò)程中。 在使用UML建立當前系統邏輯模型過(guò)程中，初學(xué)者通常會(huì )遇到一些問(wèn)題： 1.什么時(shí)候真正需要業(yè)務(wù)模型？什么時(shí)候用例模型獨立存在？ 2.在進(jìn)行精確的業(yè)務(wù)建模時(shí)能用哪些UML圖形？如何知道是否用順序圖或者交互圖？ 3.業(yè)務(wù)模型如何涉及到其他模型（如領(lǐng)域模型，用例模型等等）呢？如何有機地組織這些模型？ 本文將通過(guò)圖書(shū)館管理系統這個(gè)簡(jiǎn)單而典型的實(shí)例來(lái)進(jìn)行一次UML需求分析實(shí)踐之旅。 許多讀者對圖書(shū)館圖書(shū)管理工作比較熟悉，主要是圍繞讀者、圖書(shū)和工作人員的借還書(shū)展開(kāi)工作。我們先看看圖書(shū)館工作人員和部分讀者的需求。 讀 者來(lái)圖書(shū)館借書(shū)，可能先查詢(xún)書(shū)庫的圖書(shū)記錄。查詢(xún)可以按書(shū)名、作者、圖書(shū)編號、關(guān)鍵字查詢(xún)。查詢(xún)有兩種結果，如果查到則記下書(shū)號，交給工作人員，然后等候 辦理借書(shū)手續。如果該書(shū)已經(jīng)被全部借出，則可做借書(shū)登記，等待有書(shū)時(shí)被通知。如果圖書(shū)館沒(méi)有該書(shū)的記錄，則做缺書(shū)登記。 辦理借書(shū)手續時(shí)先要出示圖書(shū)證，沒(méi)有圖書(shū)證則去申請圖書(shū)證。如果借書(shū)數量超出規定，則提示“借書(shū)數量超限，不能繼續借閱”。工作人員登記借閱人信息、借閱的圖書(shū)信息、借出時(shí)間和應還書(shū)時(shí)間。系統自動(dòng)修改書(shū)庫的圖書(shū)記錄、讀者庫信息。 當一位讀者還書(shū)時(shí)，工作人員根據圖書(shū)證編號，找到讀者的借書(shū)信息，查看是否超期，如果已經(jīng)超期，則進(jìn)行超期處罰。 如果圖書(shū)有破損、丟失，則進(jìn)行破損處罰。清除借閱記錄，同時(shí)系統自動(dòng)查看是否有等待借閱登記，如果有則發(fā)出通知，修改書(shū)庫記錄，該書(shū)設置為已預訂狀態(tài)，否則設置為可借狀態(tài)。 圖書(shū)采購人員進(jìn)行圖書(shū)采購時(shí)，要參考各類(lèi)圖書(shū)的庫存數和借閱率，注意合理采購。如果有缺書(shū)登記則隨時(shí)進(jìn)行采購。正在采購的圖書(shū)組成一個(gè)采購中書(shū)庫。 采購到貨后，進(jìn)行驗收，編號，同時(shí)加入圖書(shū)庫，修改采購中書(shū)庫，并且查看訂閱庫，發(fā)出到書(shū)通知，并且已經(jīng)修改書(shū)庫的圖書(shū)記錄為已預訂狀態(tài)。 借書(shū)登記是當欲借的書(shū)被借空后，讀者自愿選擇的一種操作，它應該記錄讀者名和聯(lián)系方式，一旦有這本書(shū)后可通知讀者。 到書(shū)通知，當讀者預訂的書(shū)來(lái)到之后，按照讀者給出的聯(lián)系方式發(fā)出通知。 缺書(shū)登記是當讀者需要的書(shū)庫內查詢(xún)沒(méi)有記錄時(shí)，將此信息轉入缺貨庫，通知采購員采購。 圖書(shū)注銷(xiāo)，如果圖書(shū)丟失或舊書(shū)淘汰，則將該書(shū)從書(shū)庫中清除。 根據需求描述整理一張需求表： 需 求分析時(shí)首先要識別出系統的參與者，在簡(jiǎn)單的圖書(shū)館管理系統中，可以劃分出兩種參與者：讀者和管理員。當然，根據業(yè)務(wù)的復雜程度，參與者也可以進(jìn)行細分， 比如讀者可以再分為學(xué)生讀者、教師讀者、校外讀者，管理員根據業(yè)務(wù)和權限的不同可以再細分為庫房管理員、借還書(shū)操作員、系統維護人員、圖書(shū)館管理人員等不 同角色。在這里，為了簡(jiǎn)化處理，我們只列出了讀者和管理員。對參與者描述如下： （1）讀者 描述：讀者可以借閱、預定、歸還物理書(shū)刊，可以對書(shū)籍和個(gè)人信息進(jìn)行查詢(xún)，可以取消預定，可以提出辦卡申請。 示例：持有借閱卡的任何人和組織。 （2）管理員 描述：圖書(shū)管理員對系統進(jìn)行維護，包括讀者信息的創(chuàng )建、修改、刪除，書(shū)刊信息的維護，條目信息的維護，還有系統信息的維護。 示例：圖書(shū)管理員。 通過(guò)識別的參與者，對需求進(jìn)一步分析，將業(yè)務(wù)需求進(jìn)行分解，獲得每個(gè)參與者的使用用例。在本例中，我們可以得到以下用例： 1.書(shū)籍借出：提供借閱物理書(shū)刊的功能。 2.書(shū)籍歸還：提供歸還物理書(shū)刊的功能。 3.讀者辦卡：提供為讀者辦理借閱卡的功能。 4.預定書(shū)刊：提供對某一個(gè)種類(lèi)的書(shū)刊的預約功能。 5.取消預定：提供對預定進(jìn)行取消的功能。 6.書(shū)籍查詢(xún)：為讀者提供網(wǎng)上的書(shū)籍查詢(xún)功能。 7.信息查詢(xún)：為讀者提供信息查詢(xún)的功能。 8.讀者信息維護：提供讀者信息的錄入、修改、查詢(xún)、刪除的功能。 9.書(shū)刊信息維護：提供物理書(shū)刊的錄入、修改、查詢(xún)、刪除的功能。 10.條目信息維護：提供書(shū)刊條目的錄入、修改、查詢(xún)、刪除的功能。 11.系統信息維護：提供對系統的參數的設置。 12.登錄：管理員需要先登錄才能進(jìn)入系統。 并且，可以畫(huà)出如下系統用例圖： 通 過(guò)用例圖，可以對系統功能有一個(gè)大概的了解，對于復雜系統，我們可以結合IDEF方法，通過(guò)分層分解，逐步細化的方法來(lái)描述系統的功能。對于用例圖，建議 不要畫(huà)的過(guò)于復雜，特別是用例之間的關(guān)系，因為復雜的用例圖不僅不能讓需求分析人員與客戶(hù)之間更好的溝通，反而是制造了一種溝通障礙。 下一步就是編制每一個(gè)用例的詳細說(shuō)明，對用例說(shuō)明的主要信息包括有：用例名稱(chēng)、 編號、用例的簡(jiǎn)短描述、用例的參與者、與其他用例的管理、用例啟動(dòng)的前提條件、用例結束后的事后條件、用例的輸入、輸出、用例的執行事件流等。在實(shí)際項目 中，我們并不一定要面面俱到，而是根據實(shí)際情況對用例描述進(jìn)行裁減。其中有幾點(diǎn)重要信息是不能裁減的：用例名稱(chēng)、描述、輸入、輸出、執行事件流、參與者。 另外，如果實(shí)際情況需要，還可以使用MS Visio等工具畫(huà)出界面的示意圖來(lái)。 如上例所述，我們對每一個(gè)用例都進(jìn) 行詳細的描述，建立當前系統的功能用例模型。需求溝通與分析是一個(gè)迭代的過(guò)程，通過(guò)與用戶(hù)的不斷溝通，最終達成對目標系統的一致理解。如果用戶(hù)確認了需求 分析的成果，一般是需求規格說(shuō)明書(shū)之后，項目開(kāi)始進(jìn)入系統分析設計階段，也就是開(kāi)始構造目標系統的邏輯模型。 為了讓系統設計能夠以結構、組織方式和代碼重用的形式表現出來(lái)，要對系統進(jìn)行設計規劃，設計階段應該與分析階段交迭。需求是不斷地發(fā)展，而設計本身也會(huì )推動(dòng)需求的發(fā)展(反之亦然) 。在圖書(shū)館管理系統的建模設計中，以下3個(gè)方面的問(wèn)題是要關(guān)注的：業(yè)務(wù)對象的表示、業(yè)務(wù)服務(wù)的實(shí)現、用戶(hù)界面的組織。 業(yè)務(wù)對象的表示 在圖書(shū)館管理系統系統中，業(yè)務(wù)對象主要是數據庫和數據實(shí)體類(lèi)的表示方式。建模時(shí)，可以構造出系統的靜態(tài)模型，也就是系統類(lèi)圖來(lái)表示。如下圖則描述了借書(shū)這一用例的靜態(tài)結構圖。為了體現類(lèi)之間的關(guān)系，在下圖中沒(méi)有顯示出每一個(gè)類(lèi)的屬性和基本操作。 業(yè)務(wù)服務(wù)的實(shí)現 業(yè)務(wù)服務(wù)的實(shí)現需要完成的功能是各種業(yè)務(wù)規則和邏輯的實(shí)現,如借書(shū)處理的業(yè)務(wù)邏輯。每個(gè)模塊的信息錄入、修改、刪除、查詢(xún)等。業(yè)務(wù)規則和邏輯的實(shí)現基本相似，沒(méi)有太多的規律可循。采用UML來(lái)進(jìn)行業(yè)務(wù)服務(wù)的建模，可以使用UML 的序列圖、狀態(tài)圖、活動(dòng)圖。這個(gè)部分的工作,通常通過(guò)一系列的類(lèi)之間的交互來(lái)完成。為了在更動(dòng)態(tài)的層面上描述系統，UML 提供了許多其他類(lèi)型的圖。 對于B/S系統設計而言，情節圖(Scenario Diagram) 特別有用。情節圖分成兩種：協(xié)作圖(Collaboration Diagram) ，序列圖(Sequence Diagram) 。UML 建模工具Rational Rose 能夠從協(xié)作圖生成序列圖也可以從序列圖生成協(xié)作圖。例如，借閱書(shū)刊的業(yè)務(wù)過(guò)程可以采用如下序列圖來(lái)描述： 借 閱書(shū)刊過(guò)程主要包括：管理員選擇“借閱書(shū)刊”菜單，彈出對話(huà)框，管理員輸入書(shū)刊信息和用戶(hù)信息，系統查找數據庫，是否存在該種物理書(shū)刊，如果不存在，顯示 提示信息，用例結束;是否存在借閱者信息，如果不存在，顯示提示信息，用例結束;否則，管理員單擊確認按鈕后，該圖書(shū)借閱給該借閱者，系統存儲借閱信息到 數據庫。 用戶(hù)界面的組織 用戶(hù)界面布局圖能夠幫助組織系統頁(yè)面、文件、服務(wù)的布局結構。在UML 中，對于頁(yè)面和文件的組織，可以使用構件圖(Component Diagram) 或類(lèi)圖(Class Diagram) 建模型。本系統中使用類(lèi)圖對界面組織建模，頁(yè)面結構以及各種業(yè)務(wù)服務(wù)被捆綁到不同的區域。 在 UML 中，系統的體系結構使用部署圖(DeploymentDiagram) 來(lái)完成。應用部署的規劃對于規劃整個(gè)B/ S 系統是很有用的。它確定了一種有效的應用部署的規劃組織方式,還可以作為一個(gè)模式在多個(gè)類(lèi)似B/ S 系統上應用。 在建模完成后，開(kāi)發(fā)人員利用一些UML Case工具如Rational ROSE生成程序代碼框架，并對代碼框架進(jìn)行修改和補充，形成完整代碼;而且，還可根據代碼逆向生成 UML模型。這就較好地保證了模型與代碼的一致性。 測試必須在整個(gè)項目周期中進(jìn)行，對每個(gè)階段都要用所建立的模型進(jìn)行測試，這樣才能保證開(kāi)發(fā)的質(zhì)量，減少開(kāi)發(fā)的風(fēng)險。 統 一建模語(yǔ)言 UML 是國際軟件工程領(lǐng)域具有劃時(shí)代意義的重要成果，適用于以面向對象技術(shù)來(lái)描述任何類(lèi)型的系統，而且適用于系統開(kāi)發(fā)的不同階段，從需求規格描述直至系統完成后 的測試和維護。軟件系統的規模越來(lái)越大，復雜度不斷提高，RUP迭代式增量開(kāi)發(fā)方式可以降低風(fēng)險，同時(shí)可以適應需求變化的需要。 在本次UML實(shí)踐之旅中，我們通過(guò)對圖書(shū)館管理系統的需求進(jìn)行分析，將 UML 應用于系統開(kāi)發(fā)的各個(gè)階段，建立了系統的需求模型、靜態(tài)模型和動(dòng)態(tài)模型，同時(shí)遵循Rationl統一過(guò)程(RUP)的核心思想和基本原則，采用以用例為驅 動(dòng)、以體系構架為核心的迭代化面向對象分析和設計過(guò)程。
UML行為圖 用況圖（use case diagram）描述了一組用況和參與者（一種特殊的類(lèi)）以及它們之間的關(guān)系。 交互圖（interaction diagram）是順序圖和協(xié)作圖的統稱(chēng)。 順序圖(sequence diagram)是強調消息的時(shí)間次序的交互圖。 協(xié)作圖(collaboration diagram)是強調收發(fā)消息的對象的結構組織的交互圖。 狀態(tài)圖顯示了一個(gè)由狀態(tài)，轉換，事件和活動(dòng)組成的狀態(tài)機。 活動(dòng)圖顯示了系統中從活動(dòng)到活動(dòng)的流。 |
聯(lián)系客服
