不知爲何，連續發了4次(每次都重新把圖貼上），都把我的圖給弄沒了，崩潰......
與其說是使用心得，不如說是再次溫習了UML後，結合10多年自身的項目經驗以及看到的項目所進行的紙上推演。這種推演能夠讓我對UML在未來項目實施中到底該怎麼用、用到什麼程度有一個相對更清晰的概念，因此寫此文一方面整理思路，一方面也請大蝦們指正。
1.需求分析階段
在需求分析中一般首先使用的是功能模塊圖，來標示出大的功能劃分，比如監控模塊、日誌模塊等等。然後在功能模塊圖的基礎上，使用Use Case圖和Sequence圖。
如果說功能模塊圖是Level1的需求分解，那麼use case圖就是level 2的需求分解，而Sequence圖就是Level3的需求分解。一般是把level1做完了再去做level2，level2做完了再去做level3，是一個WBS(Work Breakdown)的過程.當然我們有可能會在做level3的時候發現level2沒有想全，又返回去補充level2，從而完成一個迭代過程。然而如果因爲有可能會出現的迭代，就去垂直的在level2想清楚一個User Case後，馬上就開始做level3的事情，則由於在思維的來回切換，會導致level 2有更多的遺漏，更不易保證其完備性。
我在網上看到過有人說這種做法是錯誤的，use case是不應該被以功能模塊劃分的，應該直接是use case.然而如果一個大型系統，其use case可能是非常多的，如果沒有level1的劃分，基本上無法全面的整理use case。而且這種模塊劃分的方法很適合分層彙報：向大領導彙報時使用功能模塊，向中層領導彙報時使用use case，而sequence圖就是具體業務人員才關心的了。
1.1 Use Case圖
用例圖是被稱爲參與者的外部用戶所能觀察到的系統功能的模型圖.用例圖列出系統中的用例和系統外的參與者，並顯示哪個參與者參與了哪個用例的執行。用例圖多用於靜態建模階段(主要是業務建模和需求建模)。
如下圖所示例子：
參與者之間的泛化關係，如下面例子：
在參與者之間不存在泛化關係的情況下，各個參與者參與用例的情況分別是：經理參與用例管理人事和批准預算；安全主管參與用例批准安全證書；保安參與用例監視周邊。由於安全主管與經理，安全主管與保安之間泛化關係的存在，意味着安全主管可以擔任經理和保安的角色，就能夠參與經理和保安參與的用例。這樣，安全主管就可以參與全部4個用例。但經理或者保安卻不能擔任安全主管的角色，也就不能參與用例批准安全證書。
1.2 Sequence圖
如下圖所示例子：
這裏售票中心可能在實現的時候就不是一個類。
Sequence圖一般用來描述主流程，而一些異常流程單獨以文字形式列出，稱爲備選流程(alternative sequence)。