[轉載]基於UML的需求分析和系統設計（完整案例和UML圖形演示）

小序：

從學生時代就接觸到UML，幾年的工做中也沒少使用，各類圖形的概念、圖形的元素和屬性，以及圖形的畫法都不能說不熟悉。可是怎樣在實際中有效地使用UML使之發揮應有的做用，怎樣捕捉用戶心中的需求並轉換成明確的UML圖形，怎樣把本身心中的設計意圖經過UML圖形準確地表達出來，以及各職責人員如何經過UML圖形進行有效溝通，關於這些，卻深感迷茫。

最近有幸獲得了一個臺灣人賴信仁寫的《UML團隊開發流程與管理》這本書，才拜讀了前兩章，就已經愛不釋手了，很有點欣喜若狂的感受，看了半本書以後，上述的種種疑惑均已霧開雲散了。

這本書與我以前看到過的任何一本UML的書籍都不一樣，它並無詳細介紹每種UML圖形的各類元素和屬性，而是重點講述每種UML圖形的使用場景，以及具體項目過程當中如何進行分析和設計，並使用相應的UML圖形精確傳達設計意圖。也就是說，它不是講述UML是什麼，而是結合具體項目實戰講述UML圖形應該什麼時候用、以及怎麼用。

這本書細讀下來，反覆琢磨，着實受益不淺，終於感到UML真正強大之處，同時深感有必要將書中的精華部分整理成一篇文章，既有利於之後隨時翻閱恢復記憶，又能達到快樂分享的目的，故有此文。http://yunzhu.iteye.com

 

概要：

書中共有三個部分，第一部分結合一個完整的按鈕「信仁醫院住出院系統」逐個講解UML2.0的14個圖形，講解每一個圖形的最佳使用場景以及如何構思和繪製圖形；第二部分結合另外一個完整的案例「電子化採購系統」，講解以UML驅動的整個從分析到設計到編碼到測試的全過程；第三部分則是關於如何將UML應用於團隊合做當中。

 

本文摘錄書中主要脈絡和精華部分，按照本身的想法系統地串接起來，主要講解如何在項目過程各階段採用合適的UML圖形進行分析和設計，重點關注如下問題：

• 怎樣在實際中有效地使用UML使之發揮應有的做用
• 怎樣捕捉用戶心中的需求並轉換成明確的UML圖形
• 怎樣把本身心中的設計意圖經過UML圖形準確地表達出來
• 怎樣經過UML進行項目各階段的平穩推動（分析→設計→編碼）

本文將採用兩個案例進行實例演示：

【電子化採購系統】案例背景介紹
客戶企業是一家大型家電製造商，主要業務是製造和銷售家電產品。客戶企業的信息系統包括了一個大型ERP。由於想要廠商提供更加即時快捷的服務，客戶企業委託設計一個電子化採購系統。

 

【信仁醫院住出院系統】案例背景介紹
信 仁醫院是一家區域醫院，共有200張病牀，醫院的只能科室包括內科、外科以及皮膚科。該醫院在2000年採購了一套醫院內部的醫院管理系統，其中包括門診 系統、掛號系統、收費管理系統、醫保申報系統以及財會系統。以往，信仁醫院在辦理住院出院時都必須使用人工填表的方式，只有在醫保給付、門診醫囑以及收費 管理方面，才能進入醫院管理系統進行記錄。但爲了實現「e化醫院項目」，信仁醫院須要從新設計一整套住院、出院系統。

 

書本以及本文使用的UML繪製工具是：Enterprise Architect，官方網址：http://www.sparxsystems.com

 

 

1、項目開始階段

這個階段，也就是至關於傳統軟件工程中的問題定義和可行性研究，這個階段主要是經過與用戶的訪談，以確認待開發系統「要作什麼」，並進行可行性研究，簡單來講就是從企業的角度出發研究這個項目是否能作、是否能盈利，不然最終項目失敗那對企業就會形成損失了。

 

項目開始階段的初期訪談須要抓住如下幾個重點：

• 項目的範圍：先找出目前已存在的系統，瞭解該系統是否提供了相關的集成接口，這一點與你所要開發的項目的複雜度有至關大的關係。
• 必要的業務流程：在摸索業務流程時，初期應該儘量只捕捉就「必要的」業務流程，在該業務流程中，儘可能避免對細節的研究。
• 項目的技術限制：包括使用的技術以及其餘系統間的交流接口規範。
• 項目的成功關鍵因素：要充分了解利益相關方對於總體項目成功與否最關切的問題是什麼，而且評估問題和項目成敗的風險是否相關。

上述四個重點，其實在一開始就決定了項目是否會成功，若是在項目開始時就落入了細節性的討論，反而容易形成項目的失敗，對於開發團隊來講不可不慎。

 

本階段結束以後，若是正式立項，那麼便進入下一個階段——需求分析。

 

2、需求分析階段

需求分析階段，主要是跟客戶（領域專家）溝通，進行需求的收集和分析，而後經過標準的文書準確地表達出來，並造成需求規格說明書之類的文檔，交由設計人員進行後續的系統設計工做。

UML中的用例圖正是用於需求收集和表達的有力工具，可是如何找出用例並不是易事，這是由於從用戶那裏收集來的信息極可能是零散的、沒有系統性的，要直接從中找出正確的用例很是困難。

所以在分析用例以前，能夠先對企業級的業務流程進行規劃和設計，抓住企業的本質工做流，爲後續進行詳細的需求收集和用例分析作好準備。

 

一、業務流程設計

對於企業的經營管理團隊來講，業務流程規劃與企業的永續經營之間存在着密切關係。簡單來講，業務流程就是爲了服務客戶而執行的一連串業務內部活動。業務流程分析的目的在於瞭解總體流程對企業目標的支持分別有何貢獻，進而對流程的細節進行規劃。

那 麼如何進行業務流程的設計呢？Jacbson認爲，利用「用例」的「目標導向」特性，能夠經過一個「企業級的用例」來完善工做流程的規劃與設計。不過衡量 實際情況，大部分領域專家對「用例」的接受度較差，所以可使用另外一個工具來進行企業的建模，這個工具是由Erickson和Penker所提出的一個活 動圖的構造型，稱爲「Eriksson-Penker業務擴展模型」。

 

1）業務流程規劃——Eriksson-Penker業務擴展模型

Eriksson-Penker業務擴展模型是一種「目標導向」的流程分析方式，主要是將與業務流程相關的重要人、事、物以及這個業務流程所要實現的目標作一個連接，描述了企業中重要的人、事、物與流程的關係，這個圖中一般不會過多地介紹業務流程的內部細節。在項目開始階段，需求分析人員能夠經過「Eriksson-Penker業務擴展模型」找出要開發系統的重要性，利用「目標導向」方式，對業務流程進行適當的切割。

關於Eriksson-Penker業務擴展模型，詳細請看Enterprise Architect官方網站的介紹：業務過程建模→「Eriksson-Penker 業務建模 Profile」節

 

★ Eriksson-Penker業務擴展模型示例

針對一家大型家電製造商要開發的電子化採購系統的業務流程：http://yunzhu.iteye.com

※　圖中之因此分紅兩個不一樣的流程，是由於兩個流程有不一樣的「實現目標」。

2）業務流程分析——活動圖

在 與領域專家進一步溝通後，就能夠對「Eriksson-Penker業務擴展模型」中的每個「處理」繪製一個對應的活動圖，在繪製活動圖時，應該將重點 放在「活動」自己，而不須要加入其餘因素（文件、數據、表單等）。在活動圖中，這些因素應該要在上層的「Eriksson-Penker業務擴展模型」就 表達完成。

 

活動圖最適合用來描述企業的本質工做流。在繪製活動圖時千萬不要去研究活動的細節，活動圖所要捕捉的是總體業務流程的「大方向」。有關細節的相關描述應該是在討論「用例」時才須要捕捉。

活動圖的使用場景：

• 項目起始階段，需求分析人員可使用活動圖，針對與項目相關的企業活動，與領域專家一塊兒設計流程
• 項目上線階段，能夠用利用起始階段的活動圖做爲集成測試的重要參考依據
• 項目維護階段，企業管理人員能夠經過活動圖瞭解企業現行的流程以及將來能夠改善的方向

 

在設計活動圖時須要遵循如下原則：

• 活動圖的目的在於表達「流程完整性」而非活動細節。
• 活動圖中的元素（主要是活動）沒必要考慮複用性。
• 若是在活動圖中繪製了一個「分叉點「，則必定要有一個」會合點「與之對應。
• 活動圖中儘可能不要表達」文件「或」數據「。

 

關於設計活動圖時的兩點重要建議：

• 繪製活動圖時，最好和領域專家直接當面溝通，最好在訪談過程當中直接繪製活動圖，並根據活動圖附屬一次在訪談中所收集到的相關信息。這樣，活動圖所收集到的信息將更加貼近實際。
• 在繪製活動圖時千萬不要去研究活動的細節，活動圖所要捕捉的是總體業務流程的「大方向」。有關細節的相關描述應該是在討論「用例」時才須要捕捉。

 

★ 表達業務流程的活動圖示例

針對上面的電子化採購系統業務流程圖中的——「請購流程」，在與領域專家詳細溝通後，能夠繪製出以下請購流程的活動圖。http://yunzhu.iteye.com

在完成各主要業務流程的分析，繪製出活動圖之後，即可以開始下個分階段的工做——從業務流程中找出用例，進行需求收集，完成用例模型。

 

二、需求收集——用例圖

1）關於用例的相關介紹

用例是一個系統中所進行的一連串的處置活動，該活動主要是要可以知足系統外部的執行者對於系統的某種指望。
每個信息系統的用例表明着用戶對於系統的「某一個完整指望」。
一般來講，用例是「需求收集及整理」的工具，經過用例與執行者的關係，可讓需求分析人員「聚焦」在特定的「相關人員」（也就是執行者）與」主題「（也就是用例）中。

 

2）找出用例的三個步驟

根據前面所繪製的業務流程的活動圖，能夠經過如下三個步驟找出用例：

 

① 利用與用戶的對話找出信息系統的用例

將活動圖中的每一個「活動」看成「用例」的候選，接着針對每一個」活動「詢問用戶如下幾個問題：

• 在這個活動中誰是主要參與者？
• 這個活動的進行中須要系統提供服務嗎？
• 系統須要提供什麼服務？
• 系統須要其餘信息系統的支持嗎？

而後對候選用例進行必要的合併和關係（好比「包含」）分析， 從而得出業務流程相關的用例圖。

 

★ 業務流程相關的用例圖示例

針對上面請購流程的活動圖進行上述分析，能夠得出如下用例圖：http://yunzhu.iteye.com

② 完成用例的正常流敘述

編寫用例敘述時遵循的原則：

• 每一個敘述都必須是確定句
• 在敘述中，切記不要描述過多細節

③ 完成用例的替代流及意外處理敘述

替 代流自己僅僅只是正常流的「分支」而非「主幹」。舉例來講，若是在正常流2有三個替代流，則在替代流的區塊中，就會有2a、2b、2c三個分支，而在這三 個分支的編寫中，仍然必須遵循着每一句都是「確定句」的原則。若是在其中又有替代流，則同樣必需要利用分支的方式來編寫。這樣，因爲每一個敘述都是簡短的肯 定句，天然而然增長了將來的擴展空間。

 

配合「迭代增量」的開發方式，這三個步驟不是一次就所有完成，而必需要分批完成。

• 項目開始階段（一般是一到兩個星期）必須完成第一個步驟，也就是找出六成用例，在這個部分，切記要保留將來增長用例的空間。
• 接着，針對用例進行開發順序的權重排序，這個排序主要針對「複雜度」、「與外部系統的關係」以及「重要性」來進行，權重越高的用例應該要越早開發。
• 在每一個用例中，第二個步驟（找出用例正常流敘述）必須是開發的第一個迭代，在該開發迭代進行到系統設計以及編碼階段時，需求分析師才須要進行第三個步驟的分析，也就是收集更詳細的信息以及相關的替代流。

 

3）關於用例的用例敘述

用例的敘述通常來講至少分紅四種：

• 用例的簡述：一般是用一兩句話來講明這個用例的目的是什麼。
• 用例的正常流：在這個流程中，必須說明執行者與系統交互的過程，不過在這個交互過程當中，必須假設整個流程都必須實現，也就是說這是一個「快樂路徑」，在這個流程描述中，全部句子都必須是「確定句」。
• 用例的替代流：在正常流中，若是有「替代路徑」，必需要利用另外的替代流來講明，而不是直接在正常流中寫「if-then-else「。
• 用例的意外處理：一般指系統例外狀態的處理，與替代流不一樣，替代流每每是執行者對於流程有不一樣的指示，由於將流程導向不一樣的結束點，而意外處理則一般是系統發生錯誤致使的正常流的意外情況。

用例的敘述是很是關鍵的部分，必須可以準確地把握用戶的真正指望是什麼，後續的設計工做都將圍繞用例特別是用例敘述來展開。

 

4）編寫用例的測試案例

通常來講，在找出用例後就應該編寫用例的測試案例，測試案例的編寫主要利用「輸入→預期產出「的方式來描述，每一個測試案例都須要準備對應的測試數據。

 

 

3、系統設計階段

前一階段的主要產物是用例圖，後續的設計和開發階段都將以用例驅動，圍繞用例展開，而系統設計階段的主要工做，即是實現用例。

 

一、實現用例

實現用例的目的在於保證系統的設計能夠知足用戶的功能性需求，在實現用例的過程當中，應該利用Jacobson所分類的三種分析類：

• 控制對象（Control Object）     ：控制對象包裝了一個或多個用例的功能性需求，屬於功能性對象，並且這個功能與用例有至關密切的關係。
• 實體對象（Entity Object）        ：實體對象管理了信息及其衍生資源的存取，是屬於系統本質面的概念性對象，這類對象並不會隨着用例的增多而有所變更。
• 邊界對象（Boundary Object）  ：邊界對象是屬於與外部橋接的對象，這類對象將與外部直接接軌，直接受到外部的限制。（注意：這裏的「對象」並不是指類的實例那種對象）

 

1）勾勒用例的控制對象

①  針對每一個用例提供一個「控制對象」
②  明確這個控制對象的責任（Responsibility）是什麼
      從「主執行者」在正常流的敘述中出現的次數來決定系統要提供幾個服務；
      再從每個「對話塊」中，「系統」當主語的最後一句話，找出這個責任的名稱。
③  明確這個服務的輸入輸出
      判斷這個服務中，是否須要「主執行者」提供什麼信息，而「系統」又須要回覆主執行者什麼信息
④  進入到服務內部，審視服務的實現方式
      在控制對象的內部，每個以「系統」當主語的敘述均可以獨立成一個新的功能函數；
      只是該功能函數並不是是提供給主執行者的，所以是一個「私有」的函數，只提供給控制對象使用。

 

勾勒用例的控制對象示例過程

針對前面用例圖中的第一個用例「產生請購需求（RFP）」，咱們能夠提供一個「產生請購需求（RFP）控制對象」。

 

「產生請購需求（RFP）」的「正常流」敘述：

(1) ERP系統提供[年度物料採購計劃]給系統。
(2) 系統根據[BR1]產生[廠商詢價推薦名單]。
(3) 系統依照[廠商詢價推薦名單]請通知系統將[物料請購需求]傳給名單上的廠商。

 

分析過程以下：

從（1）得知「主執行者」是：ERP系統；

「主執行者」總共出現了1次，也就是所只有一個「對話塊」，因此係統要提供1個服務；

「對話塊」中「系統」當主語的最後一句（3），可得知系統所需提供的服務是：產生廠商詢價推薦名單；

從（1）可知服務的輸入是：年度物料採購計劃；

從（3）可知服務的輸出是：廠商詢價推薦名單；

從（2）可知服務內部必須完成的第一件事：根據[BR1]產生[廠商詢價推薦名單]；

從（3）可知服務內部必須完成的第二件事：依照[廠商詢價推薦名單]請通知系統將[物料請購需求]傳給名單上的廠商；

因此從上面兩步可知控制對象內部須要兩個「私有函數」。

 

★ 控制對象的類圖示例http://yunzhu.iteye.com

2）針對控制對象繪製序列圖

前面探討了如何找出信息系統中所需的控制對象，但這樣仍然不夠，由於前面並無完整描述出究竟對象與對象之間是如何通力協做，來知足用例所描述的用戶需求。所以，必需要使用序列圖來講明這個交互過程。

 

在繪製序列圖時，能夠採用兩階段序列圖繪製法：

① 把信息系統當黑箱，利用用例敘述找出系統所應負責的服務。

     這個步驟能夠先繪製一個序列圖，而後把用例敘述放在該序列圖的右方（這樣便於對比），而後參照用例圖，把相對應的用例轉換爲一個叫作「系統」的對象。

② 把黑箱打開，加入找出的分析對象，並把系統所需實現的責任分配給適當的對象。

     把上個步驟獲得的「黑箱」序列圖中的「系統」換成實際的控制對象，而且依據找出的控制對象的責任，看看是否一致，這樣就完成了序列圖的設計了。

 

★ 控制對象的「黑箱」序列圖示例

針對上面的產生請購需求的控制對象，根據步驟①，把信息系統看成一個「黑箱」，即可獲得如下序列圖：http://yunzhu.iteye.com

3）找出用例的實體對象

可 以經過Peter Coad的「交易模式」找出用例的實體對象，這個模式的假設是：當發現企業所關心的問題領域存在必需要記錄的某些事件時，這表明着這個事件是一個交易。而 系統設計人員能夠從交易出發，依次去找出與這些交易相關的企業概念（人、地、物），如此就能夠迅速地得出這個企業的概念模型。

總之，實體對象主要是根據對於問題領域的理解來找出問題領域中的重要概念，對於實體對象的分析，不管是對於進行「實體關係圖的」的數據庫設計，或是利用「對象模型」作的「結構分析」來講，都是至關重要的設計準則。

實體對象屬於領域模型的重要概念，將在下一節「創建領域模型」中重點講解。

 

4）系統設計階段的開發流程

①  經過對用例的理解以及對用例敘述的分析，找出系統的控制對象及其操做。

②  經過與領域專家的訪談過程，找出系統的實體對象以及重要熟悉。

③  設計人員利用兩階段繪製的序列圖，驗證前述的控制對象及操做的正確性。

 

前面經過三種分析類實現用例的方式，會從用例出發分別找出控制對象、實體對象和邊界對象，在找出這些「對象」（這裏的對象並不是指類的實現，而是指一種分析類）以後，即可以創建完整的「領域模型」了。

 

二、創建領域模型

1）「領域模型」的概念

要了解領域模型，就要先了解何爲軟件的「本質」：「本質」指得就是要想辦法直指想要解決的問題的「核心」。

從軟件結構的層面來看，「本質」指的就是你所要解決的問題領域中的重要「概念」在抽象層次的呈現。通常來講，這樣的呈現方式的會經過「概念模型」來表示。
「概念模型」就是可以用最簡化的方式表達一個完整的「問題領域」的抽象表示法。概念模型的原始定義是表達問題領域中的概念，所以，一般將概念模型稱爲「領域模型」。

 

2）使用類圖表達領域模型

在UML中一般建議使用「類圖」做爲表達領域模型的圖形。
類圖主要表達的是問題領域的「抽象概念」，在這個抽象概念中，除了表達該抽象概念的名稱外，另外須要表達該抽象概念的「屬性」與」行爲」。
類圖的主要目的是在進行軟件開發前，先對軟件所需面對問題領域的本質做一個通盤性的瞭解，但類圖在軟件設計之初並不徹底正確，必須經過後續的檢查纔可以逐漸趨近於真實世界的領域模型。

 

3) 信仁醫院住出院管理系統案例演示

接下來將採用信仁醫院住出院管理系統的案例來進行演示，爲了分析和設計流程的連貫性，將從業務流程分析的部分開始。

 

（1）住出院系統業務流程

在項目立項以後，需求分析師與醫院的領域專家經過面對面的訪談，整理出了醫院實際上的住院出院流程，並繪製成活動圖。http://yunzhu.iteye.com

 

（2）住出院系統用例模型

需求分析師基於企業的業務流程圖，與領域專家經過進一步溝通，進行需求的收集，最終繪製出用例圖。固然下圖中沒有包含用例敘述。http://yunzhu.iteye.com

（3）住出院系統領域模型

在獲得用例圖以後，便進入實現用例的階段，能夠經過上一節所介紹的三種分析類找到問題領域中的重要概念，從而獲得領域模型，而後經過類圖來表達。

好比針對上一節用例圖中的「登記出院記錄」用例，經過分析能夠獲得一個控制對象（登記出院記錄BPO）和多個實體對象（病牀、病人、醫生、護士、病症等），並繪製成以下的類圖。http://yunzhu.iteye.com

4）包圖

一般領域模型中會包含不少的類，必須對這些類進行分類，放置在不一樣的命名空間中，利用命名空間之間的關係圖，來限制住不一樣分類對象之間的訪問，這就是「包圖」的使用場景。

「包圖」是一個高階的視圖，因爲全部的類都必須屬於某一個包，所以當包之間的關係被限定時，該包內部全部的類，都會受到包圖中設置的影響。

 

★ 住出院系統包圖

好比最基本的分類就是按照上面所說的三種分析類，對上面的領域模型，按照這種方式進行分類，即可以繪製出以下包圖：http://yunzhu.iteye.com

 

 

三、表達對象交互

通常來講，咱們在用例分析中將系統應該知足的用戶指望找出來了；而在類圖中則將系統的架構構造出來。可是，針對每一個特定的用例的場景，要如何利用類圖所規範的對象，經過交互協做來完成用例所交付的任務，就必需要用序列圖來表達。

 

1）序列圖

序列圖的主要目的在陳述用例的正常事件流中，對象彼此之間的交互關係。也就是說，序列圖的主要來源是用例的敘述。

 

序列圖的主要任務包括：

• 表達設計人員心中關於未來程序在運行時的對象協做模型
• 驗證軟件領域模型的正確性
• 爲程序員提供編碼的藍圖

繪製序列圖的兩點重要建議：

• 在繪製序列圖時，要首先打破一個迷思：序列圖並不須要「務求精細」，由於它畢竟只是一個「藍圖」，並不是是完整的「施工計劃」。
• 在設計「序列圖」時，要遵循一個原則：一個序列圖的大小，最好可以限制在一張A4紙能夠打印的範圍內，最大也不要超過一張A3紙的打印範圍。超過這個範圍的序列圖一般是無效的產出。爲了達到這一點，最好把正常流與替代流分開來繪製不一樣的序列圖，每一個序列圖有本身的重點，不要把全部的邏輯都表達在同一個序列圖中。

 

★ 登記出院記錄序列圖

針對「登記出院記錄」的用例，根據用例敘述，獲得如下序列圖。http://yunzhu.iteye.com

 

驗證領域模型正確性

從前面的類圖來看，「登記出院記錄BPO」是與「住院事件」想關聯的，但在序列圖中，「登記出院記錄BPO」倒是和「病牀」有消息傳遞，這彷佛並不符合類圖所表達的領域模型。咱們能夠進一步經過另外一個表達對象交互協做的通訊圖來進行驗證。

 

2）通訊圖

通訊圖與序列圖其實都是在表達同一件事情：對象相互合做，以實現用例的「事件流」。

 

爲何要使用通訊圖進一步驗證呢？

因爲序列圖是以時間作橫軸，所以對將來的程序設計而言，序列圖具備「藍圖」的效果，但若是須要同時表達對象的結構與彼此間的協做關係，則只有通訊圖才能較爲完整地進行呈現。

究竟項目設計人員在設計序列圖時，心中是否對象模型，所以但願項目設計人員能利用「通訊圖」來從新審視本身對對象模型的理解，來確認序列圖有沒有違反領域模型。

 

★ 登記出院記錄通訊圖http://yunzhu.iteye.com

 

3）交互概述圖

在繪製序列圖和通訊圖等交互圖時，須要注意：

• 不能「務求精細」過於詳盡，由於交互圖只須要描述一個「藍圖」而不是完整的「」施工計劃；
• 一張交互圖不能太大，最好能在一張A4紙的能夠打印的範圍內，頂多一張A3紙，不然會成爲無效的產出；
• 每一個交互圖應該有表達的重點，不要在一個圖中表達全部的邏輯，若是有替代流，那麼就針對一個替代流再繪製一個單獨的交互圖。

那麼，這些分散的交互圖怎麼才能組合在一塊兒呢？這時能夠利用交互概述圖。

交互概述圖主要是利用活動圖做爲基礎，只是在「控制流」間鏈接的UML元素並不是活動，而是交互圖（包括：序列圖、通訊圖、時間圖以及交互概述圖）。

 

四、表達微觀設計

 

1）對象圖

對象圖旨在描述特定時間點中全部對象在系統中的結構；所以，能夠將對象圖當成系統在某一個時間點的快照。

對象圖表達的是在某一個特定時間點中，系統所存在的全部對象的快照，其主要目的是驗證設計師設計的類圖是否符合實際情況。

對象圖的使用場景：
當與領域專家溝通時，能夠用對象圖解釋類圖的設計，以驗證類圖的正確性。
當與編碼人員溝通時，能夠利用部分的對象圖，來解釋類圖中的複雜結構。

 

★ 住出院系統對象圖

針對前面設計的信仁醫院住出院系統的領域模型，能夠參考日劇《白色巨塔》做爲範本，將該劇中最重要的一個「佐佐木先生」住院事件轉換爲對象圖。http://yunzhu.iteye.com

 

2）狀態機圖

類圖中某一個實體對象，它的狀態遷移分散在不一樣的用例中，須要在這些狀態和事件之間進行一番整理，才能讓項目開發人員更簡便地完成設計，這時可使用狀態機圖來表達。
爲了成功地設計軟件，將「狀態」分配到不一樣的「領域模型」中，並利用「狀態機圖」來表達這些狀態的遷移情形。

 

★ 病牀狀態機圖

在信仁醫院住出院系統的領域模型中，有一個「病牀」實體對象，它的狀態遷移分散在不一樣的用例中，可使用以下狀態機圖統一表達這些狀態的遷移。http://yunzhu.iteye.com

 

3）時間圖

若是在狀態遷移中牽涉到時間因素，則能夠利用時間圖來強調事件因素的重要性。設計人員能夠把時間圖當成狀態機圖的輔助說明工具。

 

★ 過時取消預約時間圖

關於前面病牀的撞他，若是病人預約了病牀，可是後來一直沒有去使用病牀，那麼這個病牀該怎麼辦呢？總不能直接空着吧？關於這一點，信仁醫院的處理是這樣的：超過半小時病牀狀態要自動遷移到Empty。這個設計內容很難在狀態機圖中表達，這時可使用時間圖。http://yunzhu.iteye.com

 

總結和展望

到此爲止，本文已經講解了需求分析階段和系統設計階段使用的主要UML圖形，除了這些圖形以外，還有如下UML圖形，本文不作詳細介紹：

• 總則圖         ：UML2.4規範新增，主要用於將團隊開發中重要的觀念或技術使用「構造型」加以整理，讓全部團隊成員能夠共享這些共同的知識，其主要目的在於聚集團隊成員的共同詞彙，以求在總體上暢通地進行溝通。
• 組合結構圖  ：UML2.4規範新增，主要用於表達要開發系統與外部系統間的關係，很是適合讓架構師在初期階段做爲評估系統複雜度的工具，也可做爲將來系統維護的參考圖形。
• 組建圖         ：從系統實現的角度進行繪製，主要目的是呈現系統在實現時如何把設計的類分配給不一樣的物理組件。
• 部署圖         ：描述物理組件與實體計算機之間的關係，整體上是規劃物理組件的實際位置的一個圖。通常來講，當開發一個大型系統時，會比較須要組建圖和部署圖這兩個圖。

後記

總 算寫完了，從拿到這本書開始，看了整整一個月，寫這篇博客又花了半個月，從未在一本書上花過這麼的時間，但仍是以爲很值。一個字一個字的敲出來，一個圖一 個圖的畫出來，雖然說耗時甚多，但也使得印象更加深入了。加上反覆琢磨反覆鑽研，對UML終於有了深入的認識，對於UML的實際應用，也有了瞭然於胸的感 覺。同時也殷切地但願這篇文章可以對您有所幫助。真心以爲這本書值得一看。

在此感謝親愛的老婆在生活和精神上的鼎立支持，也感謝即將出生的親愛的小寶寶

 

博客同步發佈地址：http://yunzhu.iteye.com/blog/1914288