uml是一扇窗，開啟了它，你就能看見更多東西。
當你感嘆uml是集計算機專家思想大成之作時，你肯定體會到了這些圖的精妙之處。
首先來聯想幾個常見的場景。
北京奧運會，中國長卷氣勢恢巨集，精彩場景萬眾矚目。從張藝謀到控制烟花的操作手，每乙個環節都不容差錯，如何快速溝通？在讓子彈飛的同時，也讓思路回歸到軟體設計。在這個設計過程中，使用者會提出複雜的需求，每次的每個業務都可能不一樣。而程式設計師則有自己所擅長的技術，輕鬆套用乙個框架當然最好了。可是，最後很容易出現程式所表達的核心功能和客戶的核心業務不一致，很多軟體作坊也在不知不覺中走進了修修補補的誤區。年末賀歲大片大戰，從《阿凡達》、《十月圍城》到《讓子彈飛》，片場情節紛繁複雜，每乙個環節都會體現不同的設計思想。如何選擇乙個合適的方式，讓演員和片場工作人員都充分領會導演的意圖？
1．uml有多大的價值？
到底誰服從誰呢？毫無疑問，我們要尊重客戶的需求。
對於程式設計師而言，框架、技術、設計技巧是死的，分析業務是最難的。如果沒有好的方法學去分析業務，那麼，設計出來的模型肯定不太能客觀反應現實。然後，即使有再好的框架、技術、分層架構、orm、快取，都沒用了。由此，我們會引申出乙個話題：怎麼選擇一種最合適的表達方式，讓大家的溝通更順暢？
或許有人會說，我覺得大部分uml不需要使用工具畫出來。很多時候用白板畫一下，大家都理解了，然後就可以擦掉了。
或許還有人說，我們公司做電子商務的，我們一般用到狀態圖，其他的不怎麼用到。
再或者，其實很多公司是為了寫uml文件而寫uml，uml的作用到底有多大，很多人都持懷疑態度？難道，大家就只是迷戀工具，因為別人uml，所以我也uml？由此認為，乙個工具就能搞定所有的疑惑。
這就是撰寫本書的初衷，我們需要重新解讀uml。也許，需求與uml沒有直接關係，但是uml可以專業的表述需求。細細品讀一下，為了能夠更清新的把握務求，uml其實發揮著十分重要的作用。比如，溝通、記錄、啟發、存檔；理解客戶需求，最終形成開發文件。
每個人對需求的理解方式都不一樣。歸納起來，uml只是把大家的理解統一了一種表達形式，有助於相互之間的溝通，便於團隊成員之間傳遞一致的需求，從而達到需求概念的一致性：需求分析人員使用uml模型與客戶溝通，直接明了，同時通過uml模型傳遞客戶需求給設計人員；設計人員使用uml模型描述客戶需求，傳遞給開發人員；開發人員使用統一的概念和語義理解uml模型，最終使團隊各個角色在需求上達到一致的理解。
2．解決學習uml的困惑
在日常交流中，我們發現，很多程式設計師有這樣的第一感覺：看不懂uml。或者，很多程式設計師做uml的時候，明明腦子裡有乙個路線圖，可是不知道該用什麼圖來表達自己的設計意圖。還有人會直截了當的提出：有必要把整個系統用uml表達出來嗎？
當然，許多專案經理也有自己的困惑。比如，明明自己心裡很清楚，可是，當他面對乙個新人的時候，卻不知道怎麼解釋系統模型、流程。無形之中，形成了一種交流上的溝壑。
當我們討論這些話題的時候，很自然的會延伸到許多概念。比如，模型驅動設計，領域驅動設計。概念越來越多，而我們的腦袋卻越來越暈。試想，專案一旦複雜後uml類圖就會複雜化，讓人看不懂。乙個大型專案裡面的類和關係都會很複雜，uml類圖會膨脹，有的時候程式需要改動了，uml也要及時更新了。於是，有人又提出了類似領域邊界的概念。如此反覆，更多的人也許就會被弄暈了！
其實，uml很簡單，就是不要把uml當回事。我們可以嘗試以下思路：
l 畫uml就像做數學題打草稿，是幫助我們嘗試觀點，弄清題意的。
l 在表述uml結構時，先從大的概念上進行模組劃分，然後再從區域性詳細處理。
l 把注意力集中到業務上來。這就是說，我們要解決的是問題，但大家總是把注意力集中到解決問題的工具上。當問題被解決後，大家心裡有數了，進而可以告之，換個工具可能更好，有什麼優點。
按照這個思路，進而去討論uml，那就是十三種圖，常用的幾種與不常用的幾種，知道各怎麼用，表達什麼意思也就游刃有餘了。
3.uml中常用的檢視
uml是unified modeling language（統一建模語言）的簡稱，如果給其乙個權威的定義的話，booche在其經典著作《the unified modeling language user guide》中這樣描述：uml是對軟體密集型系統中的製品進行視覺化、詳述、構造和文件化的語言。此處的製品主要是指軟體開發過程中各個階段的產物，比如需求用例、源**、測試用例等。
uml建模機制可以分為靜態建模機制和動態建模機制，靜態建模機制所建立的模型都是靜態的,包括用例圖、類圖(包含包)、物件圖、元件圖和配置圖等五個圖形；動態建模機制所建立的模型或者可以執行,或者表示執行時的時序狀態或互動關係。它包括狀態圖、活**、順序圖和協作圖等四個圖形。那建立這些圖能夠起到什麼作用，達到什麼目的呢？
l 使用模型可以更容易理解問題
l 使用模型可以更好地加強人員之間的溝通
l 使用模型可以更早地發現和糾正錯誤，甚至規避錯誤
l 使用模型可以得到需求結果和設計結果
l 使用模型可以使團隊新成員更快地融入專案中
l 使用模型可以為源**留下原型
uml本身是個整體，尤其要明白，為什麼要有這些圖，為什麼不是其他圖，這些圖就夠了嗎？時序圖缺少了哪些資訊？而狀態機缺少了哪些資訊？為什麼這些圖有機結合在一起就能很好的刻畫乙個系統。例如狀態機檢視是可以有乙個完全嚴格的實現的，相對嚴格，而時序圖則不行。來自一位熟悉的朋友的建議：
（1）狀態機的變遷，即最早的狀態遷移圖，mealy裝調劑，more狀態機，以及後來的安全狀態機等等。為什麼會有這些變遷，以及這些不同狀態機的差異，和主要應用領域。尤其是清楚狀態機應該應用的什麼場合。言外之意，就是什麼地方不適合狀態機。
（2）uml狀態機自身的缺陷，然後用物件導向給出乙個狀態機模式的實現，分析不同實現方法的優缺點。它本身是和物件導向思想是緊密聯絡的，對比辨析一下，狀態機思想和物件導向思想的差異和聯絡。
（3）狀態機的特點是可以有效的降低乙個複雜系統的複雜度。很少人能體會到狀態機的強大之處，要解釋一下狀態機為什麼會很好的降低問題的複雜度，他對程式架構有和幫助。
乙個網友的提問： 16:29:54
1. 看了 《uml和模式應用》，書中的例子 pos 機，作者把 「處理銷售」 定為乙個 系統用例， 這個明顯是 主參與者的乙個完整業務目標， 但按我過去的理解這個應該是 業務用例才對。 我可否這樣理解： uml和模式應用 一書中的所謂系統用例其實就是我所謂的業務用例，都是乙個級別的，只是採用的名字不同罷了 ？
2. 再說邊界，書中邊界是以 pos機為系統邊界，定義出主角是 收銀員 而 不是 購買者， 但是我看的其他書中在需求分析的時候一般是按業務目標來劃分邊界的。是不是可以理解為邊界的定義方式可以有多種呢 ？
3. uml和模式應用 一書，裡頭沒有分析模型，而是從領域模型開始直接到設計模型，但是這裡運用了所謂的 grasp 原則為各個物件分配職責。但是一般來說，我們是根據系統用例場景繪製時序圖，然後從時序圖里為 分析類的3個元素：邊界類，控制類，實體類 分配職責的。
4. 分析模型的意義主要在於嚴格按軟體工程中要求的做需求和實現同步（高於語言實現層次），或者乙個專案要賣給不同客戶，而不用客戶要求的實現語言平台不同，這時候分析模型抽成層次高，可以通用。grasp 裡面的原則也是根據時序圖，結合領域模型給物件分配職責，只是它好像是語言級別的，不像分析類那樣用文本來表示乙個訊息。
以上4個問題哪位能解答一下
帶我信樂 17:26:25 我是純開發人員 我的理解
1.系統用例是人機互動的,業務用例帶有業務目標性質,如果「處理銷售」我會理解成乙個業務用例
2.邊界定義,根據業務來吧,也可以按業務目標,也能按部門,也可以按行為..應該是多種方式吧
3.查了下資料在rup中分析模型是可選模型需求向設計模型轉換的過渡，人、事、規則、物 對應 參與者、邊界類、控制類、實體類,是更高層次的抽象.
4.這個應該和pd中建立er圖一樣的道理吧,概念模型（cdm）轉物理模型（pdm） 可以轉成sqlserver、mysql、oracle等。
產品設計 網際網路產品設計
產品設計有三種層次的水平 本能水平的設計,行為水平的設計和反思水平的設計.本能水平的設計，涉及產品外形的初始效果 行為水平的設計，使用者使用產品的經驗，約等於 使用者體驗 反思水平的設計，包括產品給人的感覺.它描述了乙個什麼形象,它的擁有者是什麼品位.設計者在設計新的產品時,應綜合考慮設計的這三種水...
產品經理 網際網路產品設計
1 互動設計 1.以使用者為中心的設計 a.產品 功能 b.體驗 c.使用者 產品是用的不是用來學的 d.核心思想 在產品開發的每乙個環節都想把使用者的需求納入考慮 妥協是存在的，但不隨便妥協 每個功能，每個階段都在有方法工作 有依據的產品設計 2.模式 a.互動邏輯 按照使用者使用習慣組織功能和內...
軟體 網際網路產品設計流程
1.產品調研 產品的調研屬於市場範疇，由市場部門負責。產品調研是為了提高產品決策質量，解決存在於產品設計及產品上線後銷售中的問題而系統 客觀的收集 分析市場綜合情況的行為。所以與內部產品不同的是，外部產品調研需要撰寫市場需求文件即mrd，只有符合公司戰略和市場需求的產品，方可進入產品立項階段。而內部...