一、UML活動圖和用例圖
——我一直不太信任自己的記憶力，是以我把它們都寫下來
在小公司裡各種因素的限制，導緻工程師根本無法在工作中接觸到科學的軟體設計方式。每次新項目開工的時候都是老闆把大家召集在一起告訴大家這個項目是給誰做的，幹啥的，大小如何；再說一些大體的業務。然後孩子們在模棱兩可中根據項目的大小選擇個架構然後開工，碼代的過程中遇到問題就去問老闆，有時候老闆突然一拍腦門告訴我們有一些東西忘記了，大家改改。。fuck。。。有時候做到一半的時候發現裡面存在很多問題，導緻跟下遊的業務完全無法對接……真的是受夠這種工作方式了，效率低就不說了，主要是太打擊程式猿的信心了。
剛畢業那會兒就聽過UML（統一模組化語言），知道這個東東是軟體開發初期設計用的，然後就沒有下文了，瘋狂的投入到碼代事業中。但是今年尤其是最近又有新項目，還是跟以前一樣的拍腦門絕對軟體怎麼弄的時候我實在是受夠了，決定必須找到一套行之有效的方法，讓大家能完整的了解軟體項目的需求。其實不管什麼活動圖、用例圖、時序圖、類圖……都是為了讓軟體人員能完整的全方位的了解項目的需求，做出客戶期望的軟體産品，并且有利于後期維護。
上面紅字部分才是我們學習UML的目的，就像軟體設計師用例驅動一樣，在項目開始之前我們就應該明确我們的目的。下面先看 活動圖 和 用例圖。UML工具軟體常用的visio、Rose等，MAC用Omnigraffle。下面的執行個體都是在Omnigraffle中設計的。
活動圖：闡明了業務用例實作的工作流程（強烈建議活動圖用泳道方式分隔開，每個泳道可以是使用者或者部門）
下面是醫藥企業進貨業務的活動圖，左邊是普通的活動圖，右邊加了泳道。我想是否使用泳道表示的原因一目了然
活動圖在上面時候使用呢？
1）項目開始階段，确定業務需求時通過活動圖與客戶設計業務流程。
2）企業管理成也可以根據活動圖修改現有的流程。
3）內建測試階段根據活動圖明确測試的結果。
活動圖要點？
活動圖關注的業務的流程完整性，而不是業務的具體實作。
活動圖制作過程中不要關注資料。
用例圖：用例圖也是在項目需求前期确定階段常用的分析方式，它是站在使用者的角度，研究的是使用者的目的，必須立足于使用者的“期望”，而不是以我們自己單純的意願決定使用者的操作。
同樣還是上面的業務，用例圖表現如下
用例圖和活動圖都是在需求确定階段研究業務流程和業務關系的，是以也有很多相似的地方。