UML業(yè)務建模實例分析四例.doc

UML業(yè)務建模實例分析在我國十年前ATM（自動取款機）還是一個很新鮮的事物，現(xiàn)在在城市的大街小巷隨處可見。我們在日常生活中也經(jīng)常和ATM打交道。本章我們將以簡化的ATM系統(tǒng)為例將前面幾章中學到的用例圖、類圖、順序圖、狀態(tài)圖、活動圖及協(xié)作圖知識運用到此例中。5.1用例圖參與者銀行儲戶和ATM機。簡化后的ATM機僅有取款、存款及其余功能。其余功能不做詳細說明。圖5.1 自動取款機（ATM）系統(tǒng)用例圖 銀行儲戶在ATM機上完成取款、存款及其他業(yè)務。5.2類圖圖5.2所示的銀行系統(tǒng)類圖和圖3.5是類似的，只是將工作人員換成了ATM。整個銀行系統(tǒng)包括了帳戶庫、銀行儲戶庫及ATM系統(tǒng)。許多單個的帳戶組成了帳戶庫。帳戶具有帳戶類型、帳戶號、余額三個屬性，均為private，其類型分別為char，int，double。六個操作分別為setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance為protected其余均為public。 setType設置帳戶類型，返回類型為void，參數(shù)類型為char，輸入帳戶類型。 getType獲取帳戶類型，返回類型為char，無參數(shù)。 setAccountNumbe設置帳戶號，返回類型為void，參數(shù)類型為int，輸入帳戶號。 getAccountNumbe獲取帳戶號，返回類型為int，無參數(shù)。 caculateBalance計算余額，返回類型為void，參數(shù)為double，第一個參數(shù)為輸入存取款數(shù)額，第二個參數(shù)為存款余額，既為輸入也為輸出。 getBalance獲取帳戶余額，返回類型為double，無參數(shù)。許多銀行儲戶組成了儲戶庫。ATM系統(tǒng)包含了許多ATM機。銀行儲戶及ATM機兩個類包含哪些屬性，哪些操作，它們的可見性及操作的返回類型、參數(shù)個數(shù)、參數(shù)類型從類圖上都一目了然。更多的屬性及操作都可以一一加上，使這個類圖更詳細更完整，從而使參與項目的每個成員都能無歧義的明了整個設計的類的結構。同樣對于一個真正的銀行系統(tǒng)，這個類圖過于簡單。比如帳戶類型我們可以先定義一個abstract class，它包含一個帳戶最基本的屬性及操作。而有些操作先定義為abstract，如余額的計算。然后再繼承這個abstract class，我們可以有saving account 和checking account等等。不同的帳戶有不同的余額計算方法，我們可以加上具體的算法。對于不同的帳戶可能還有一些它特有的操作，我們也可以加上，比如saving account在存款達到多少時可以享受機票打折的優(yōu)惠。通過類圖不僅可以使設計者明確的表達自己的設計意圖，也能幫組自己整理思路，充實及優(yōu)化自己的設計。 圖5.2 銀行系統(tǒng)類圖5.3順序圖圖5.3描述了顧客在ATM機上取款時信息的流動情況。以時間為順序。因為僅是示例，所以整個過程是沒有出現(xiàn)任何故障時的流程，并且只畫到了取款結束。通過這個圖，我們可以看出消息是如何在系統(tǒng)中不同對象之間進行交互。通過流程圖我們可以很清楚地看到系統(tǒng)是如何工作的，系統(tǒng)各部分之間的信息及控制是如何發(fā)送的，整個流程是否合理。流程圖對我們的設計起到了很好的幫助作用。注意在本圖沒有一個生命線終端有一個X，這是因為這個流程中還未遇到有對象生命結束。當有對象生命結束時需在對應的生命線終端畫X，表明這個對象在這時被銷毀。首先銀行儲戶將ATM卡插入讀卡機，讀卡機將信息傳給客戶管理，客戶管理提出查詢密碼，顯示部分將輸入密碼請求顯示出來.因為這個順序圖較長，且很清晰，即便是初學者也很容易讀懂，在此就不對本圖做過多的解釋。圖5.3 ATM取款順序圖圖5.4描述了顧客在ATM機上進行操作會經(jīng)歷的幾種狀態(tài)，及各種狀態(tài)之間轉換的條件。因為是簡化了的例子，所以除了等待顧客插入磁卡的起始狀態(tài)和結束服務的終止狀態(tài)，顧客會處于輸入密碼、選擇服務類型、存款及取款四種狀態(tài)。 插入磁卡后進入輸密碼狀態(tài)，當密碼輸入正確時進入選擇服務類型狀態(tài)，當輸入密碼不正確時，停留在原狀態(tài)，但如果三次不正確，服務結束。進入選擇服務類型后根據(jù)選擇的不同，顧客可進入存款和取款狀態(tài)。存、取款結束后，顧客既可以選擇結束服務到最終狀態(tài)，也可以選擇繼續(xù)服務回到選擇服務類型狀態(tài)。通過狀態(tài)圖我們可以無歧義的了解各個活動角色是如何在不同狀況下轉換的，轉換的條件是什么，是否會出現(xiàn)死鎖現(xiàn)象，是否有條件沒考慮周全，是否有狀態(tài)無法達到。狀態(tài)圖可以幫助我們發(fā)現(xiàn)問題，并及時改正。 5.5活動圖圖5.5參考了Randy Miller的A Hands-On Introduction for Developers一文，5.3圖中的客戶管理和事物管理對應于5.5圖中的Bank，圖5.3中的讀卡機、顯示、輸入設備及點鈔機對應于5.5圖中的ATM Machina，銀行儲戶就是Customer。初看活動圖和順序圖表達的意義很接近。但我們可以注意到順序圖著重時間的順序，而活動圖側重于各部分之間的相互制約，對于一些并行的活動能夠有效的表示出來。例如5.5圖中fork和join處，我們可以很清楚的看到一些并行活動的存在。這個活動圖以顧客插入卡為開始，以顧客取卡結束。我們可以看到活動圖的重點雖然不在時間順序，但我們同樣可以得到時間的信息。 圖5.5 ATM銀行系統(tǒng)活動圖5.6協(xié)作圖在第四章中我們知道協(xié)作圖和順序圖是可以無信息損失的相互轉換，只是它們的側重點是不一樣的。順序圖著重于對象間消息傳遞的時間順序，協(xié)作圖著重于表達對象之間的靜態(tài)連接關系。圖5.6將5.3圖轉換為協(xié)作圖。1. 插入ATM卡2. 接受ATM卡3. 查詢密碼4. 顯示輸入密碼請求5. 輸入密碼6. 密碼傳遞7. 請求確認密碼合法性8. 確認密碼合法性9. 詢問服務類別10. 顯示輸入服務服務類別請求11. 輸入取款請求12. 取款請求 13. 詢問取款數(shù)額14. 顯示輸入數(shù)額請求15. 輸入取款數(shù)額16. 傳遞取款數(shù)額17. 詢問取款數(shù)額確認18. 顯示確認數(shù)額請求19. 輸入確認20. 傳遞確認信息21. 數(shù)額合法性確認請求22. 確認數(shù)額和法性23. 出鈔請求24. 計算帳戶余額25. 出鈔26. 取鈔27. 傳遞余額并詢問是否還需要其他服務28. 顯示帳戶余額并提示選擇下面的服務 從圖上我們可以看出協(xié)作圖的角色和順序圖的對象是一一對應的，而協(xié)作圖上的各對象上的協(xié)作關系和順序圖上的消息傳遞是一一對應的。 摘要 本文以實例的方式，展示了如何使用UML進行面向對象的分析與設計。本文將假設讀者對UML、面向對象等領域的基本內容已了然于胸，所以將不會過多闡述，而將重點放在應用過程上。本文的目的是通過一個完整的實例，展現(xiàn)基于UML的OOA&D過程的一個簡化模式，幫助朋友們更好的認識UML在OOA&D中起的作用。前言 經(jīng)常聽到有朋友抱怨，說學了UML不知該怎么用，或者畫了UML卻覺得沒什么作用。其實，就UML本身來說，它只是一種交流工具，它作為一種標準化交流符號，在OOA&D過程中開發(fā)人員間甚至開發(fā)人員與客戶之間傳遞信息。另外，UML也可以看做是OO思想的一種表現(xiàn)形式，可以說“OO是神，而UML是型”。所以，想用好UML，扎實的OO思想基礎是必不可少的。然而，在UML應用到開發(fā)過程中時，還是有一定的模式可以遵循的。（注意，是模式而不是教條，我下面給出的流程只是一個啟發(fā)式過程，而不是說一定要遵循這個流程。）下面，我們通過一個CMS系統(tǒng)的分析設計實例，看看如何將UML應用到實際的開發(fā)中。1.從需求到業(yè)務用例圖 OOA&D的第一步，就是了解用戶需求，并將其轉換為業(yè)務用例圖。我們的CMS系統(tǒng)需求非常簡單，大致課做如下描述：這個系統(tǒng)主要用來發(fā)布新聞，管理員只需要一個，登錄后可以在后臺發(fā)布新聞。任何人可以瀏覽新聞，瀏覽者可以注冊成為系統(tǒng)會員，注冊后可對新聞進行評論。管理員在后臺可以對新聞、評論、注冊會員進行管理，如修改、刪除等。 通過以上需求描述，我們畫出如下的業(yè)務用例圖： 這里要注意三點： 1.業(yè)務用例是僅從系統(tǒng)業(yè)務角度關注的用例，而不是具體系統(tǒng)的用例。它描述的是“該實現(xiàn)什么業(yè)務”，而不是“系統(tǒng)該提供什么操作”。例如，在實際系統(tǒng)中，“登錄”肯定要作為一個用例，但是這是軟件系統(tǒng)中的操作，而用戶所關注的業(yè)務是不包含“登錄”的。 2.業(yè)務用例僅包含客戶“感興趣”的內容。 3.業(yè)務用例所有的用例名應該讓客戶能看懂，如果某個用例的名字客戶看不懂什么意思，它也許就不適合作為業(yè)務用例。2.從業(yè)務用例圖到活動圖 完成了業(yè)務用例圖后，我們要為每一個業(yè)務用例繪制一幅活動圖?；顒訄D描述了這個業(yè)務用例中，用戶可能會進行的操作序列?；顒訄D有個很重要的使命：從業(yè)務用例分析出系統(tǒng)用例。例如，下面是“新聞管理”的活動圖： 可以看到，一個“新聞管理”這個業(yè)務用例，分解出N多系統(tǒng)操作。這里要特別注意這些操作，其中很多“活動”都很可能是一個系統(tǒng)用例（當然，不是每個都是）。例如，由這個活動圖可以看出，系統(tǒng)中至少要包含以下備選系統(tǒng)用例：登錄、注銷登錄、查看新聞列表、修改新聞、刪除新聞。 這樣，將每個業(yè)務用例都繪制出相應的活動圖，再將其中的“活動”整合，就得出所有備選系統(tǒng)用例。3.從活動圖到系統(tǒng)用例圖 找出所有的備選系統(tǒng)用例后，我們要對他們進行合并和篩選。合并就是將相同的用例合并成一個，篩選就是將不符合系統(tǒng)用例條件的備選用例去掉。 一個系統(tǒng)用例應該是實際使用系統(tǒng)的用戶所進行的一個操作，例如，“查看新聞列表”就不能算一個系統(tǒng)用例，因為他只是某系統(tǒng)用例的一個序列項。 最終我們得出的系統(tǒng)用例圖如下：4.從系統(tǒng)用例圖到用例規(guī)約 得出系統(tǒng)用例圖后，我們應該對每一個系統(tǒng)用例給出用例規(guī)約。關于用例規(guī)約，沒有一個通用的格式，大家可以按照習慣的格式進行編寫。對用例規(guī)約唯一的要求就是“清晰易懂”。 下面給出“登錄”這個系統(tǒng)用例的一個規(guī)約：5.繪制業(yè)務領域類圖 完成了上面幾步，下面應該是繪制業(yè)務領域類圖了。所謂業(yè)務領域類圖要描述一下三點： 1.系統(tǒng)中有哪些實體。 2.這些實體能做什么操作。 3.實體間的關系。 這里要特別強調：這里的實體不是Actor，而是Actor使用系統(tǒng)時使用的所調用的實體，是處在系統(tǒng)邊界之內的實體。例如，管理員就沒有作為一個實體出現(xiàn)在這里，因為管理員處在系統(tǒng)邊界之外，它所有的工作都可以通過調用這三個類的方法完成。并且，這里的“注冊會員”實體也不是剛才用例圖中注冊會員這個Actor，而是作為一個系統(tǒng)內的業(yè)務實體，供Actor們使用的。例如，其中的注冊功能是給注冊會員這個Actor使用，而移除則是給管理員這個Actor使用的。 理解以上這段話非常重要，我經(jīng)?？吹接捎诨煜藢嶓w和Actor的關系而導致畫出的領域類圖不準確或職責分配不準確。大家可能還注意到，我們這里沒有給出每個實體的屬性。其實，在領域分析階段，實體的屬性并不重要，重要的是找出實體的操作。 6.繪制實現(xiàn)類圖 以上這幾步，就是分析的過程。而下面的步驟就是設計了。 設計沒有分析那么好描述，因為分析是“客戶面”，它只關心系統(tǒng)本身的功能和業(yè)務，而不關心任何和計算機有關的東西。但是，設計和平臺、語言、開發(fā)模型等內容關系緊密，因而很難找出一個一致的過程。但是，一般在設計過程中實現(xiàn)類圖是要繪制的。 實現(xiàn)類圖和領域類圖不一樣，它描述的是真正系統(tǒng)的靜態(tài)結構，是和最后的代碼完全一致的。因此，它和平臺關系密切，必須準確給出系統(tǒng)中的實體類、控制類、界面類、接口等元素以及其中的關系。因此，實現(xiàn)類圖是很復雜的，而且是平臺技術有關的。所以，我在這里不可能給出一個準確的實現(xiàn)類圖，不過為了描述，我還是給出一個簡化了的實現(xiàn)類圖，當然，它是不準確的，而只是從形式上給出實現(xiàn)類圖的樣子。 我們假設這個系統(tǒng)建構于.NET 3.5平臺上，并且使用ASP.NET MVC作為表示層，整體使用三層架構。那么，用戶模塊體系的實現(xiàn)類圖大體是這樣子（不準確）：7.繪制序列圖 有了靜態(tài)結構，我們還要給出動態(tài)結構，這樣，才能看清系統(tǒng)間的類是如何交互的，從而有效幫助程序員進行編碼工作。 上圖給出的是用戶登錄的序列圖。首先注冊會員作為Actor，調用UserController的Login方法啟動序列，然后序列按圖示步驟執(zhí)行。其中UserServices作為業(yè)務組件，首先調用數(shù)據(jù)訪問組件的GetByName確定用戶是否存在，如果存在，再調用GetByNameAndPassword確定輸入密碼是否是此用戶的密碼。從而完成業(yè)務功能。 要注意，序列圖在實際中是很多的，幾乎每個類方法都配有相應的序列圖。8.后面的步驟 在完成了上面的過程后，就可以進行編碼、調試、測試等工作了。但這些已經(jīng)超出了本文討論的范圍?？偨Y 本文簡要給出了使用UML進行OOA&D的過程。當然，由于示例較小，而且本人水平有限，所以給出的相關內容可能不是很準確。而且軟件分析設計本來就不是一個固定模式的過程，隨著系統(tǒng)的不同整個過程會有變化。本文只是想起到一個拋磚引玉的作用，讓朋友們大致了解UML的使用流程。至于實際的分析設計，還需要深入的學習和實踐的積累。UML業(yè)務建模實例分析作者: 范里程 出處:軟件世界對于大中型信息系統(tǒng)，很難直接進行需求分析設計，需要借助模型來分析設計系統(tǒng)，根據(jù)系統(tǒng)調研數(shù)據(jù)，建立起目標系統(tǒng)的邏輯模型。 在軟件工程的歷史中，很長時間里人們一直認為需求分析是整個軟件工程中最簡單的一個步驟，但在過去十年中越來越多的人認識到它是整個過程中最為關鍵的一個過程。假如在需求分析時分析者們未能正確地認識到客戶的需求的話，那么最后的軟件實際上不可能達到客戶的要求，或者導致需求的頻繁變更，而軟件無法在規(guī)定的時間里完工。 在需求分析階段，要對經(jīng)過可行性分析所確定的系統(tǒng)目標和功能作進一步的詳細論述，確定系統(tǒng)“做什么？”的問題，最終建立起目標系統(tǒng)的邏輯模型。 首先是獲得當前系統(tǒng)的物理模型。物理模型是對當前系統(tǒng)的真實寫照，可能是一個由人工操作的過程，也可能是一個已有的但需要改進的計算機系統(tǒng)。首先是要對現(xiàn)行系統(tǒng)進行分析、理解，了解它的組織情況、數(shù)據(jù)流向、輸入輸出，資源利用情況等，在分析的基礎上畫出它的物理模型。然后抽象出當前系統(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)模型，目前已經(jīng)被工業(yè)標準化組織OMG（Object Management Group）接受，一經(jīng)推出便得到許多著名的計算機廠商如Microsoft、HP、IBM、Oracle等的支持，也在逐步開始應用到需求分析過程中。 在使用UML建立當前系統(tǒng)邏輯模型過程中，初學者通常會遇到一些問題： 1.什么時候真正需要業(yè)務模型？什么時候用例模型獨立存在？ 2.在進行精確的業(yè)務建模時能用哪些UML圖形？如何知道是否用順序圖或者交互圖？ 3.業(yè)務模型如何涉及到其他模型（如領域模型，用例模型等等）呢？如何有機地組織這些模型？ 本文將通過圖書館管理系統(tǒng)這個簡單而典型的實例來進行一次UML需求分析實踐之旅。 許多讀者對圖書館圖書管理工作比較熟悉，主要是圍繞讀者、圖書和工作人員的借還書展開工作。我們先看看圖書館工作人員和部分讀者的需求。 讀者來圖書館借書，可能先查詢書庫的圖書記錄。查詢可以按書名、作者、圖書編號、關鍵字查詢。查詢有兩種結果，如果查到則記下書號，交給工作人員，然后等候辦理借書手續(xù)。如果該書已經(jīng)被全部借出，則可做借書登記，等待有書時被通知。如果圖書館沒有該書的記錄，則做缺書登記。 辦理借書手續(xù)時先要出示圖書證，沒有圖書證則去申請圖書證。如果借書數(shù)量超出規(guī)定，則提示“借書數(shù)量超限，不能繼續(xù)借閱”。工作人員登記借閱人信息、借閱的圖書信息、借出時間和應還書時間。系統(tǒng)自動修改書庫的圖書記錄、讀者庫信息。 當一位讀者還書時，工作人員根據(jù)圖書證編號，找到讀者的借書信息，查看是否超期，如果已經(jīng)超期，則進行超期處罰。 如果圖書有破損、丟失，則進行破損處罰。清除借閱記錄，同時系統(tǒng)自動查看是否有等待借閱登記，如果有則發(fā)出通知，修改書庫記錄，該書設置為已預訂狀態(tài)，否則設置為可借狀態(tài)。 圖書采購人員進行圖書采購時，要參考各類圖書的庫存數(shù)和借閱率，注意合理采購。如果有缺書登記則隨時進行采購。正在采購的圖書組成一個采購中書庫。 采購到貨后，進行驗收，編號，同時加入圖書庫，修改采購中書庫，并且查看訂閱庫，發(fā)出到書通知，并且已經(jīng)修改書庫的圖書記錄為已預訂狀態(tài)。 借書登記是當欲借的書被借空后，讀者自愿選擇的一種操作，它應該記錄讀者名和聯(lián)系方式，一旦有這本書后可通知讀者。 到書通知，當讀者預訂的書來到之后，按照讀者給出的聯(lián)系方式發(fā)出通知。 缺書登記是當讀者需要的書庫內查詢沒有記錄時，將此信息轉入缺貨庫，通知采購員采購。 圖書注銷，如果圖書丟失或舊書淘汰，則將該書從書庫中清除。 根據(jù)需求描述整理一張需求表： 需求分析時首先要識別出系統(tǒng)的參與者，在簡單的圖書館管理系統(tǒng)中，可以劃分出兩種參與者：讀者和管理員。當然，根據(jù)業(yè)務的復雜程度，參與者也可以進行細分，比如讀者可以再分為學生讀者、教師讀者、校外讀者，管理員根據(jù)業(yè)務和權限的不同可以再細分為庫房管理員、借還書操作員、系統(tǒng)維護人員、圖書館管理人員等不同角色。在這里，為了簡化處理，我們只列出了讀者和管理員。對參與者描述如下： （1）讀者 描述：讀者可以借閱、預定、歸還物理書刊，可以對書籍和個人信息進行查詢，可以取消預定，可以提出辦卡申請。 示例：持有借閱卡的任何人和組織。（2）管理員 描述：圖書管理員對系統(tǒng)進行維護，包括讀者信息的創(chuàng)建、修改、刪除，書刊信息的維護，條目信息的維護，還有系統(tǒng)信息的維護。 示例：圖書管理員。 通過識別的參與者，對需求進一步分析，將業(yè)務需求進行分解，獲得每個參與者的使用用例。在本例中，我們可以得到以下用例： 1.書籍借出：提供借閱物理書刊的功能。 2.書籍歸還：提供歸還物理書刊的功能。 3.讀者辦卡：提供為讀者辦理借閱卡的功能。 4.預定書刊：提供對某一個種類的書刊的預約功能。 5.取消預定：提供對預定進行取消的功能。 6.書籍查詢：為讀者提供網(wǎng)上的書籍查詢功能。 7.信息查詢：為讀者提供信息查詢的功能。 8.讀者信息維護：提供讀者信息的錄入、修改、查詢、刪除的功能。 9.書刊信息維護：提供物理書刊的錄入、修改、查詢、刪除的功能。 10.條目信息維護：提供書刊條目的錄入、修改、查詢、刪除的功能。 11.系統(tǒng)信息維護：提供對系統(tǒng)的參數(shù)的設置。 12.登錄：管理員需要先登錄才能進入系統(tǒng)。 并且，可以畫出如下系統(tǒng)用例圖： 通過用例圖，可以對系統(tǒng)功能有一個大概的了解，對于復雜系統(tǒng)，我們可以結合IDEF方法，通過分層分解，逐步細化的方法來描述系統(tǒng)的功能。對于用例圖，建議不要畫的過于復雜，特別是用例之間的關系，因為復雜的用例圖不僅不能讓需求分析人員與客戶之間更好的溝通，反而是制造了一種溝通障礙。 下一步就是編制每一個用例的詳細說明，對用例說明的主要信息包括有：用例名稱、編號、用例的簡短描述、用例的參與者、與其他用例的管理、用例啟動的前提條件、用例結束后的事后條件、用例的輸入、輸出、用例的執(zhí)行事件流等。在實際項目中，我們并不一定要面面俱到，而是根據(jù)實際情況對用例描述進行裁減。其中有幾點重要信息是不能裁減的：用例名稱、描述、輸入、輸出、執(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ù)據(jù)庫和數(shù)據(jù)實體類的表示方式。建模時，可以構造出系統(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ù)據(jù)庫，是否存在該種物理書刊，如果不存在，顯示提示信息，用例結束;是否存在借閱者信息，如果不存在，顯示提示信息，用例結束;否則，管理員單擊確認按鈕后，該圖書借閱給該借閱者，系統(tǒng)存儲借閱信息到數(shù)據(jù)庫。 用戶界面的組織 用戶界面布局圖能夠幫助組織系統(tǒng)頁面、文件、服務的布局結構。在UML 中，對于頁面和文件的組織，可以使用構件圖(ponent 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生成程序代碼框架，并對代碼框架進行修改和補充，形成完整代碼;而且，還可根據(jù)代碼逆向生成 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)中從活動到活動的流。 UML實例：銷售管理系統(tǒng)的UML分析與設計 作者：王文豪|轉貼自：|點擊數(shù)：1553|更新時間：20XX-8-29|文章錄入： 摘 要 銷售管理系統(tǒng)是現(xiàn)代企業(yè)管理系統(tǒng)的一個重要組成部分，傳統(tǒng)的系統(tǒng)分析設計方法已經(jīng)難以保證軟件開發(fā)的效率和質量，通過將UML應用于銷售管理系統(tǒng)建模，可以加速軟件開發(fā)進程，提高軟件質量，支持動態(tài)的業(yè)務需求，并方便地集成已有的企業(yè)管理資源。 關鍵詞 銷售管理系統(tǒng)；UML；分析；實現(xiàn)1 引言當前社會對信息系統(tǒng)的需求日益增長，需求變化也越來越快，軟件開發(fā)的技術發(fā)展方向已經(jīng)從“提升被開發(fā)系統(tǒng)的執(zhí)行效率”轉變?yōu)椤疤嵘_發(fā)效率”。面向對象（OO）技術降低了解決方法域與問題域的差別，提供了良好的復用機制，能夠更加有效提高軟件開發(fā)效率，完全順應了軟件開發(fā)技術的發(fā)展方向。UML(The Unified Modeling Language,即統(tǒng)一建模語言) 是一個通用的標準建模語言，可以對復雜的系統(tǒng)建立可視化系統(tǒng)模型，目前已經(jīng)被工業(yè)標準組織OMG(Object Management Group)接受，一經(jīng)推出便得到許多著名計算機廠商如Microsoft,HP,IBM,Oracle等支持，在國際上應用日益廣泛。本文通過一個銷售管理系統(tǒng)的分析與設計，闡述如何通過UML降低開發(fā)難度和提高開發(fā)效率。2 銷售管理系統(tǒng)的基本特征和功能模塊本系統(tǒng)以“訂單”為核心，構建出了以“客戶”為中心的管理模式。該系統(tǒng)具有以下一些特征：（1） 先進的系統(tǒng)結構，面向銷售流程，能適應原有銷售工作流程并進行合理的改進，從而更貼近實際的應用；（2） 針對大型企業(yè)銷售管理人員多，銷售管理復雜的特點，通過系統(tǒng)提供的靈活的人員權限設置和全面的財務核算方式，實現(xiàn)真正的銷售網(wǎng)絡化辦公；（3） 在實現(xiàn)訂單的電子化、工作流程的數(shù)字化同時，幫助公司領導提高決策的科學化水平；（4） 通過對客戶信息的管理，實現(xiàn)對客戶廣告走勢和重要客戶情況統(tǒng)計和分析。整個系統(tǒng)操作業(yè)務人員包括：銷售員、銷售經(jīng)理、倉庫管理員、審計員、公司銷售主管、和系統(tǒng)管理員。各個角色承擔不同的系統(tǒng)任務，通過網(wǎng)絡和通信系統(tǒng)，連接到銷售管理系統(tǒng)，使用統(tǒng)一的訪問界面，進行日常的銷售業(yè)務操作，最終實現(xiàn)銷售部門業(yè)務的正常運轉。3 系統(tǒng)的UML分析與實現(xiàn)UML概述及特點UML是一種編制系統(tǒng)藍圖的標準化語言，可以對大型復雜系統(tǒng)的各種成分可視化說明并構造系統(tǒng)模型，以及建立各種必要的文檔。UML通過三類圖形建立系統(tǒng)模型：Use Case圖，靜態(tài)結構圖（類圖，對象圖，組件圖，配置圖）和動態(tài)行為圖（順序圖，協(xié)同圖，狀態(tài)圖，活動圖），這些圖可以從不同抽象角度使系統(tǒng)可視化。UML具有面向對象、可視化、獨立與開發(fā)過程和程序設計語言以及易于掌握使用等特點。UML適用于各種規(guī)模的系統(tǒng)開發(fā)，能促進軟件復用，方便地集成已有的系統(tǒng)并有效減少開發(fā)中的各種風險。UML在銷售管理系統(tǒng)中的實際應用UML是一種建模語言，是系統(tǒng)開發(fā)的一個組成部分，本身并沒有關于開發(fā)過程概念的定義和表示符號。UML的創(chuàng)始人 booch,Jacobson和Rum Baugh在rational公司的支持下綜合了多種系統(tǒng)開發(fā)過程的長處，提出新的面向對象的開發(fā)過程，稱為Rational統(tǒng)一過程（Rational Unified Process,RUP）。RUP過程的核心工作流程包括：業(yè)務建模、需求分析、系統(tǒng)分析與設計和實現(xiàn)、實現(xiàn)、測試和系統(tǒng)部署。下面通過UML來分析并構造銷售管理系統(tǒng)模型，并結合Rational統(tǒng)一過程加以描述，圖形使用Rational Rose 工具軟件繪制。3.1 銷售管理系統(tǒng)的業(yè)務建模和需求分析業(yè)務模型和需求分析的目的是對系統(tǒng)進行評估，采集和分析系統(tǒng)的需求，理解系統(tǒng)要解決的問題，重點是充分考慮系統(tǒng)的實用性。結果可以用一個業(yè)務用例（Business Use Case）框圖表達，根據(jù)銷售系統(tǒng)的基本特征和功能可得到 本系統(tǒng)的用例圖，如圖2。圖1 銷售管理系統(tǒng)業(yè)務用例框圖模型中的活動者代表外部與系統(tǒng)交互的單元，包括銷售員、銷售經(jīng)理、倉庫管理員、審計員、公司銷售主管、和系統(tǒng)管理員；業(yè)務用例框圖是對系統(tǒng)需求的描述，表達了系統(tǒng)的功能和所提供的服務，包括客戶管理子系統(tǒng)、訂單管理子系統(tǒng)、銷售統(tǒng)計子系統(tǒng)、產品管理子系統(tǒng)系統(tǒng)管理子系統(tǒng)。圖2是銷售管理系統(tǒng)層次的用例模型，只包含了最基本的Use Case模型，是系統(tǒng)的高層抽象。在開發(fā)過程中，隨著對系統(tǒng)需求認識的不斷加深，用例模型可以從頂向下不斷細化，演化出更加詳細的Use Case模型。 根據(jù)系統(tǒng)的用例圖，可以對系統(tǒng)的持久對象進行設計，下圖是本系統(tǒng)持久對象類及類之間關系圖。圖2 核心業(yè)務對象類及類之間關系3.2 銷售管理系統(tǒng)設計系統(tǒng)分析與設計是研究欲采用的實現(xiàn)環(huán)境和系統(tǒng)結構，結果是產生一個對象模型，也就是設計模型。設計模型包含了Use Case的實現(xiàn)，可以表現(xiàn)對象如何相互通信和運作來實現(xiàn)Use Case流的。對于系統(tǒng)的靜態(tài)結構，可以通過類圖、對象圖、組件圖和配置圖來描述；對于系統(tǒng)的動態(tài)行為，可以通過順序圖、協(xié)同圖、狀態(tài)圖、活動圖描述。這些圖在加上說明文檔就構成一個完整的設計模型。3.2.1系統(tǒng)架構設計銷售管理系統(tǒng)擁有大量銷售信息資源，這些資源包括各種客戶、訂單、和產品等信息。其數(shù)據(jù)量大、信息變化快，非結構化信息與結構化信息共存。使用UML對銷售管理系統(tǒng)進行基于面向對象的分析和實現(xiàn)，可以從開發(fā)的第一步開始，從系統(tǒng)的底層就把握住銷售信息資源的特征，為下一步具體實現(xiàn)打好基礎。在銷售管理系統(tǒng)建立模型時要涉及到處理大量的模型元素，如類、進口、組件、節(jié)點、圖等，可以將語意上相近的模型元素組織在一起，這就構成了UML的包，包從較高的層次來組織管理系統(tǒng)模型。系統(tǒng)主要有以下四個包：（1）用戶接口包（ser Interface Package）用戶接口包在其他包的頂層次，為系統(tǒng)用戶提供訪問信息和服務。要注意一點，由于開發(fā)工具使用不同，該接口描述也是有區(qū)別的。如果采用Java Web開發(fā)，就要以JSP(Java Server Pages)為基礎，如果采取Microsoft的A開發(fā)，其基礎就是標準化控件組。本系統(tǒng)在此將使用Java Web開發(fā)，下面有關代碼的描述都是基于Java的。（2）業(yè)務邏輯包(Business Rule Package)該包是銷售管理系統(tǒng)業(yè)務的核心實現(xiàn)部分，包括客戶管理、訂單管理、產品管理等，其他包可以通過訪問該包提供的接口，實現(xiàn)業(yè)務邏輯，如客戶管理業(yè)務等。（3）數(shù)據(jù)持久訪問包(Data Persistence Package)該包實現(xiàn)數(shù)據(jù)的持久化，也就是與數(shù)據(jù)庫交互，實現(xiàn)數(shù)據(jù)的存取、修改等操作。（4）通用工具包（til Package）該包主要包括應用程序安全檢查的類，可以為上面三個包提供安全檢查，如客戶端檢查和服務器端業(yè)務規(guī)則檢查等，同時包括一些系統(tǒng)異常檢查與拋出處理以及系統(tǒng)日志服務等。3.2.2系統(tǒng)詳細設計詳細設計主要是描述在系統(tǒng)分析階段產生的類，與分析階段類的區(qū)別就是偏重于技術層面和類的細節(jié)實現(xiàn)。銷售管理系統(tǒng)提供的各種服務都是建立在分布、開放的信息結構之上，依托高速、可靠的網(wǎng)絡環(huán)境來完成的。每項服務都可以看作一個事件流，由若干相關的對象交互合作來完成。對于這種系統(tǒng)內部的協(xié)作關系和過程行為，可以通過繪制序列（Sequence）框圖和協(xié)作（Collaboration）框圖來幫助觀察和理解。此外，描述工作流和并發(fā)行為還可以通過活動框圖，表達從一個活動到另一個活動的控制流。同時，可以在理解這些圖的基礎上，抽象出系統(tǒng)的類圖，為系統(tǒng)編碼階段繼續(xù)細化提供基礎。下面以Java Web開發(fā)為例，介紹客戶管理子系統(tǒng)的詳細設計1.客戶管理子系統(tǒng)的基本結構建模：下圖是客戶管理子系統(tǒng)主要類極其關系的詳細設計圖3 客戶關系子系統(tǒng)類的詳細設計及類之間關系2.序列圖：序列圖是一種對象交互圖，著重強調了時間序列，而不是靜態(tài)對象的關系，通過序列圖可以清楚地看到“誰在什么時間對誰說了寫什么”。圖4 客戶管理的序列框圖圖5 銷售人員對客戶管理的順序框圖圖4是一個客戶管理的序列框圖例子。描述了先加載某個客戶；顯示某些狀態(tài)；再更改某些屬性值，最后更新數(shù)據(jù)庫狀態(tài)的一次執(zhí)行過程。此圖可設計Customer類的load