談談UML使用

若是有不瞭解UML的，請先看一下IBM developerworks這篇講解UML的簡短可是高質量的文章 http://www.ibm.com/developerworks/cn/rational/r-uml/

在以前的工做中，我瞭解UML，會簡單使用UML，可是有一種觀點，UML只是一個建模方法，目的主要是爲了向人們闡述清楚工程的設計目的，工程的基本流程......，應用的場合也只在面向對象的程序設計。我的感受用不用均可以，由於其餘的方法好比書面的解釋，簡單的圖形講解......也能完成使用UML一樣的功能。

可是在慢慢地實踐和與人的交流中我才感覺到了UML思想的強大，（要感謝Chuanyi Zheng讓我真正瞭解UML）。

UML系統開發中的三個主要模型：

功能模型：從用戶的角度展現系統的功能，包括用例圖。

對象模型：採用對象，屬性，操做，關聯等概念展現系統的結構和基礎，包括類圖。

動態模型：展示系統的內部行爲。包括序列圖，活動圖，狀態圖。

我先拋開對象模型不談，由於他彷彿只適用於面向對象的設計。

先看看功能模型中的用例圖。用例圖主要目的是幫助開發團隊以一種可視化的方式理解系統的功能需求。有不少方式可讓團隊理解系統的功能需求，文檔解釋，ppt， office visio圖形。可是對於團隊來講，不一樣的人有不一樣的喜愛，確定有某些人不愛讀通篇的文字（好比我），ppt的繪製關係圖效果太差，visio太麻煩。可是我以爲UML的用例圖不但方便繪製，在功能關係體現上更加直觀，簡單。並且一般能獲得你們一致的承認。

對於動態模型，我以爲更有必要去了解使用它，記得我在以前《怎樣寫好一個方法》這篇文章中對本身寫好一個方法進行了經驗總結，首先在這個方法內把這個方法要處理的流程寫下來，好比1.作容錯（校驗參數有效性），2.若有須要申請資源......5.釋放資源，而後再去實現代碼編寫。也許會有人認爲這是畫蛇添足，可是每每咱們在工做中卻容易把某些流程忽略掉致使低質量的程序實現甚至錯誤的邏輯。在進行一個業務或者程序設計時若是咱們以序列圖或者狀態圖的方式把咱們的設計邏輯和程序調用邏輯」躍然紙上「，等梳理好這些邏輯後再去作代碼實現我敢說必定會下降不少邏輯或者流程方面的錯誤發生率，並且有利於團隊的交流，你想一想看，你是願意看密密麻麻的代碼來分析對方的邏輯仍是更願意看清晰的時序圖或者狀態圖？對於TCP協議的理解，一個狀態圖必定勝於千言萬語......

其實UML還有不少能夠用到實際工做中的功能，總之多學多使用必定是×××的，對於這些規範化的模型你固然能夠不使用或者用其餘的方式取代，可是我想規範化，專業化能更好的提升本身的工做效率和提升團隊的協做能力。