小序：
從學生時代就接觸到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
一、項目開始階段
這個階段，也就是相當於傳統軟件工程中的問題定義和可行性研究，這個階段主要是通過與用戶的訪談，以確認待開發系統“要做什麼”，並進行可行性研究，簡單來說就是從企業的角度出發研究這個項目是否能做、是否能盈利，否則最終項目失敗那對企業就會造成損失了。
項目開始階段的初期訪談需要抓住以下幾個重點：
- 項目的範圍：先找出目前已存在的系統，瞭解該系統是否提供了相關的集成接口，這一點與你所要開發的項目的複雜度有相當大的關係。
- 必要的業務流程：在摸索業務流程時，初期應該儘可能只捕捉就“必要的”業務流程，在該業務流程中，儘量避免對細節的研究。
- 項目的技術限制：包括使用的技術以及其他系統間的交流接口規範。
- 項目的成功關鍵因素：要充分了解利益相關方對於整體項目成功與否最關切的問題是什麼，並且評估問題和項目成敗的風險是否相關。
上述四個重點，其實在一開始就決定了項目是否會成功，如果在項目開始時就落入了細節性的討論，反而容易造成項目的失敗，對於開發團隊來說不可不慎。
本階段結束之後，如果正式立項，那麼便進入下一個階段——需求分析。
二、需求分析階段
需求分析階段，主要是跟客戶（領域專家）溝通，進行需求的收集和分析，然後通過標準的文書準確地表達出來，並形成需求規格說明書之類的文檔，交由設計人員進行後續的系統設計工作。
UML中的用例圖正是用於需求收集和表達的有力工具，但是如何找出用例並非易事，這是因爲從用戶那裏收集來的信息很可能是零散的、沒有系統性的，要直接從中找出正確的用例非常困難。
因此在分析用例之前，可以先對企業級的業務流程進行規劃和設計，抓住企業的本質工作流，爲後續進行詳細的需求收集和用例分析做好準備。
1、業務流程設計
對於企業的經營管理團隊來說，業務流程規劃與企業的永續經營之間存在着密切關係。簡單來說，業務流程就是爲了服務客戶而執行的一連串業務內部活動。業務流程分析的目的在於瞭解整體流程對企業目標的支持分別有何貢獻，進而對流程的細節進行規劃。
那 麼如何進行業務流程的設計呢？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
在完成各主要業務流程的分析，繪製出活動圖以後，便可以開始下個分階段的工作——從業務流程中找出用例，進行需求收集，完成用例模型。
2、需求收集——用例圖
1）關於用例的相關介紹
用例是一個系統中所進行的一連串的處置活動，該活動主要是要能夠滿足系統外部的執行者對於系統的某種期望。
每一個信息系統的用例代表着用戶對於系統的“某一個完整期望”。
通常來說，用例是“需求收集及整理”的工具，通過用例與執行者的關係，可以讓需求分析人員“聚焦”在特定的“相關人員”（也就是執行者）與”主題“（也就是用例）中。
2）找出用例的三個步驟
根據前面所繪製的業務流程的活動圖，可以通過以下三個步驟找出用例：
① 利用與用戶的對話找出信息系統的用例
將活動圖中的每個“活動”當作“用例”的候選，接着針對每個”活動“詢問用戶以下幾個問題：
- 在這個活動中誰是主要參與者？
- 這個活動的進行中需要系統提供服務嗎？
- 系統需要提供什麼服務？
- 系統需要其他信息系統的支持嗎？
然後對候選用例進行必要的合併和關係（比如“包含”）分析， 從而得出業務流程相關的用例圖。
★ 業務流程相關的用例圖示例
針對上面請購流程的活動圖進行上述分析，可以得出以下用例圖：http://yunzhu.iteye.com
② 完成用例的正常流敘述
編寫用例敘述時遵循的原則：
- 每個敘述都必須是肯定句
- 在敘述中，切記不要描述過多細節
③ 完成用例的替代流及意外處理敘述
替 代流本身僅僅只是正常流的“分支”而非“主幹”。舉例來說，如果在正常流2有三個替代流，則在替代流的區塊中，就會有2a、2b、2c三個分支，而在這三 個分支的編寫中，仍然必須遵循着每一句都是“肯定句”的原則。如果在其中又有替代流，則一樣必須要利用分支的方式來編寫。這樣，由於每個敘述都是簡短的肯 定句，自然而然增加了未來的擴展空間。
配合“迭代增量”的開發方式，這三個步驟不是一次就全部完成，而必須要分批完成。
- 項目開始階段（通常是一到兩個星期）必須完成第一個步驟，也就是找出六成用例，在這個部分，切記要保留未來增加用例的空間。
- 接着，針對用例進行開發順序的權重排序，這個排序主要針對“複雜度”、“與外部系統的關係”以及“重要性”來進行，權重越高的用例應該要越早開發。
- 在每個用例中，第二個步驟（找出用例正常流敘述）必須是開發的第一個迭代，在該開發迭代進行到系統設計以及編碼階段時，需求分析師才需要進行第三個步驟的分析，也就是收集更詳細的信息以及相關的替代流。
3）關於用例的用例敘述
用例的敘述一般來說至少分成四種：
- 用例的簡述：通常是用一兩句話來說明這個用例的目的是什麼。
- 用例的正常流：在這個流程中，必須說明執行者與系統交互的過程，不過在這個交互過程中，必須假設整個流程都必須實現，也就是說這是一個“快樂路徑”，在這個流程描述中，所有句子都必須是“肯定句”。
- 用例的替代流：在正常流中，如果有“替代路徑”，必須要利用另外的替代流來說明，而不是直接在正常流中寫“if-then-else“。
- 用例的意外處理：通常指系統例外狀態的處理，與替代流不同，替代流往往是執行者對於流程有不同的指示，因爲將流程導向不同的結束點，而意外處理則通常是系統發生錯誤導致的正常流的意外狀況。
用例的敘述是非常關鍵的部分，必須能夠準確地把握用戶的真正期望是什麼，後續的設計工作都將圍繞用例特別是用例敘述來展開。
4）編寫用例的測試案例
一般來說，在找出用例後就應該編寫用例的測試案例，測試案例的編寫主要利用“輸入→預期產出“的方式來描述，每個測試案例都需要準備對應的測試數據。
三、系統設計階段
前一階段的主要產物是用例圖，後續的設計和開發階段都將以用例驅動，圍繞用例展開，而系統設計階段的主要工作，便是實現用例。
1、實現用例
實現用例的目的在於保證系統的設計可以滿足用戶的功能性需求，在實現用例的過程中，應該利用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）系統設計階段的開發流程
① 通過對用例的理解以及對用例敘述的分析，找出系統的控制對象及其操作。
② 通過與領域專家的訪談過程，找出系統的實體對象以及重要熟悉。
③ 設計人員利用兩階段繪製的序列圖，驗證前述的控制對象及操作的正確性。
前面通過三種分析類實現用例的方式，會從用例出發分別找出控制對象、實體對象和邊界對象，在找出這些“對象”（這裏的對象並非指類的實現，而是指一種分析類）之後，便可以建立完整的“領域模型”了。
2、建立領域模型
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
3、表達對象交互
一般來說，我們在用例分析中將系統應該滿足的用戶期望找出來了；而在類圖中則將系統的架構構造出來。但是，針對每個特定的用例的場景，要如何利用類圖所規範的對象，通過交互協作來完成用例所交付的任務，就必須要用序列圖來表達。
1）序列圖
序列圖的主要目的在陳述用例的正常事件流中，對象彼此之間的交互關係。也就是說，序列圖的主要來源是用例的敘述。
序列圖的主要任務包括：
- 表達設計人員心中關於將來程序在運行時的對象協作模型
- 驗證軟件領域模型的正確性
- 爲程序員提供編碼的藍圖
繪製序列圖的兩點重要建議：
- 在繪製序列圖時，要首先打破一個迷思：序列圖並不需要“務求精細”，因爲它畢竟只是一個“藍圖”，並非是完整的“施工計劃”。
- 在設計“序列圖”時，要遵循一個原則：一個序列圖的大小，最好能夠限制在一張A4紙可以打印的範圍內，最大也不要超過一張A3紙的打印範圍。超過這個範圍的序列圖通常是無效的產出。爲了達到這一點，最好把正常流與替代流分開來繪製不同的序列圖，每個序列圖有自己的重點，不要把所有的邏輯都表達在同一個序列圖中。
★ 登記出院記錄序列圖
針對“登記出院記錄”的用例，根據用例敘述，得到以下序列圖。http://yunzhu.iteye.com
驗證領域模型正確性
從前面的類圖來看，“登記出院記錄BPO”是與“住院事件”想關聯的，但在序列圖中，“登記出院記錄BPO”卻是和“病牀”有消息傳遞，這似乎並不符合類圖所表達的領域模型。我們可以進一步通過另一個表達對象交互協作的通信圖來進行驗證。
2）通信圖
通信圖與序列圖其實都是在表達同一件事情：對象相互合作，以實現用例的“事件流”。
爲什麼要使用通信圖進一步驗證呢？
由於序列圖是以時間做橫軸，因此對未來的程序設計而言，序列圖具有“藍圖”的效果，但如果需要同時表達對象的結構與彼此間的協作關係，則只有通信圖才能較爲完整地進行呈現。
究竟項目設計人員在設計序列圖時，心中是否對象模型，因此希望項目設計人員能利用“通信圖”來重新審視自己對對象模型的理解，來確認序列圖有沒有違反領域模型。
★ 登記出院記錄通信圖http://yunzhu.iteye.com
3）交互概述圖
在繪製序列圖和通信圖等交互圖時，需要注意：
- 不能“務求精細”過於詳盡，因爲交互圖只需要描述一個“藍圖”而不是完整的“”施工計劃；
- 一張交互圖不能太大，最好能在一張A4紙的可以打印的範圍內，頂多一張A3紙，否則會成爲無效的產出；
- 每個交互圖應該有表達的重點，不要在一個圖中表達所有的邏輯，如果有替代流，那麼就針對一個替代流再繪製一個單獨的交互圖。
那麼，這些分散的交互圖怎麼才能組合在一起呢？這時可以利用交互概述圖。
交互概述圖主要是利用活動圖作爲基礎，只是在“控制流”間連接的UML元素並非活動，而是交互圖（包括：序列圖、通信圖、時間圖以及交互概述圖）。
4、表達微觀設計
1）對象圖
對象圖旨在描述特定時間點中所有對象在系統中的結構；因此，可以將對象圖當成系統在某一個時間點的快照。
對象圖表達的是在某一個特定時間點中，系統所存在的所有對象的快照，其主要目的是驗證設計師設計的類圖是否符合實際狀況。
對象圖的使用場景：
當與領域專家溝通時，可以用對象圖解釋類圖的設計，以驗證類圖的正確性。
當與編碼人員溝通時，可以利用部分的對象圖，來解釋類圖中的複雜結構。
★ 住出院系統對象圖
針對前面設計的信仁醫院住出院系統的領域模型，可以參考日劇《白色巨塔》作爲範本，將該劇中最重要的一個“佐佐木先生”住院事件轉換爲對象圖。http://yunzhu.iteye.com
2）狀態機圖
類圖中某一個實體對象，它的狀態遷移分散在不同的用例中，需要在這些狀態和事件之間進行一番整理，才能讓項目開發人員更簡便地完成設計，這時可以使用狀態機圖來表達。
爲了成功地設計軟件，將“狀態”分配到不同的“領域模型”中，並利用“狀態機圖”來表達這些狀態的遷移情形。
★ 病牀狀態機圖
在信仁醫院住出院系統的領域模型中，有一個“病牀”實體對象，它的狀態遷移分散在不同的用例中，可以使用如下狀態機圖統一表達這些狀態的遷移。http://yunzhu.iteye.com
3）時間圖
如果在狀態遷移中牽涉到時間因素，則可以利用時間圖來強調事件因素的重要性。設計人員可以把時間圖當成狀態機圖的輔助說明工具。
★ 過期取消預定時間圖
關於前面病牀的撞他，如果病人預定了病牀，但是後來一直沒有去使用病牀，那麼這個病牀該怎麼辦呢？總不能直接空着吧？關於這一點，信仁醫院的處理是這樣的：超過半小時病牀狀態要自動遷移到Empty。這個設計內容很難在狀態機圖中表達，這時可以使用時間圖。http://yunzhu.iteye.com
總結和展望
到此爲止，本文已經講解了需求分析階段和系統設計階段使用的主要UML圖形，除了這些圖形之外，還有以下UML圖形，本文不做詳細介紹：
- 總則圖 ：UML2.4規範新增，主要用於將團隊開發中重要的觀念或技術使用“構造型”加以整理，讓所有團隊成員可以共享這些共同的知識，其主要目的在於彙集團隊成員的共同詞彙，以求在整體上暢通地進行溝通。
- 組合結構圖 ：UML2.4規範新增，主要用於表達要開發系統與外部系統間的關係，非常適合讓架構師在初期階段作爲評估系統複雜度的工具，也可作爲未來系統維護的參考圖形。
- 組建圖 ：從系統實現的角度進行繪製，主要目的是呈現系統在實現時如何把設計的類分配給不同的物理組件。
- 部署圖 ：描述物理組件與實體計算機之間的關係，總體上是規劃物理組件的實際位置的一個圖。一般來說，當開發一個大型系統時，會比較需要組建圖和部署圖這兩個圖。
後記
總 算寫完了，從拿到這本書開始，看了整整一個月，寫這篇博客又花了半個月，從未在一本書上花過這麼的時間，但還是覺得很值。一個字一個字的敲出來，一個圖一 個圖的畫出來，雖說耗時甚多，但也使得印象更加深刻了。加上反覆琢磨反覆鑽研，對UML終於有了深刻的認識，對於UML的實際應用，也有了瞭然於胸的感 覺。同時也殷切地希望這篇文章能夠對您有所幫助。真心覺得這本書值得一看。