大多數軟體人員應該對uml並不陌生，什麼是uml？它是unified modeling language，它是一種建模語言，它是進行需求分析和概要設計的利器。在您的理解中，什麼是uml呢？它僅僅是那些圖形、文字和符號的集合嗎？還是一種用文字、圖形和符號的集合來描述現實生活中各類事物、活動、及其之間關係的語言呢？我聽到過兩種聲音：有許多軟體從業人員甚至軟體企業認為，uml是非常重要的，系統分析員、軟體設計師必須精通uml，這一觀點可以從大多數企業的招聘資訊中得到：「***職務，精通uml……」。又有一部分人說，uml似乎也沒多大用處，使用uml的圖形來畫畫流程圖倒是不錯的選擇。對於前者，有過分誇大uml之嫌疑，這也直接導致國內很多初學者在還沒有弄清楚uml是什麼的情況下盲目地學習和追捧uml，最後收效甚微；而後者呢？認為完全沒有必要使用uml，這將使得系統中各角色之間的直觀交流變得困難。
uml是什麼？
1. uml是一種標準。在這裡說標準，似乎太深奧了，說協議或許更好些。uml是一種協議，它是系統分析人員和設計人員之間、軟體從業人員與客戶之間所應遵循的一種通訊協議。就好像ftp伺服器程式與客戶端程式需要通訊，首先大家都要遵循一種協議（ftp協議）。通過使用uml，系統分析人員不僅可以很直觀地記錄客戶需求，為系統設計提供具體的、可參考的系統分析模型，而且可以很方便地與設計人員甚至客戶進行交流，因為大家都遵循同一協議，交流就變得容易和直觀了。從客戶角度來講，如果希望更好的表達自己的需求資訊，並能夠很好的與專業人員進行交流，是不是也應該多關注一下uml呢？
2. uml是統一建模語言。什麼是「統一」？它表示uml並不僅僅是軟體系統的「專利」，非軟體行業同樣可以使用uml進行建模描述。同時，它也更好地證實了「uml是一種標準」這一說法。什麼是「語言」？因為它有自己的語法和語義。uml的各個元素有著自己的語義，而元素的組織形式卻遵循著一定的語法規則。從語法強度來講，uml應該和自然語言的語法強度平級，因此uml應該會出現二義性問題。uml應該是一種描述性語言（dl），描述物件就是系統分析與系統設計的思想。
uml不是什麼？
1. uml不是方**。uml不能對問題域提供一套解決方案，這是系統分析員和軟體設計師的職責。它僅僅是一種語言，支援uml標準的軟體也僅僅是一套系統建模工具，它就像一般的程式語言一樣，比如c#語言本身並不能幫你解決實際的業務問題，具體問題如何解決，就需要程式設計人員很好地使用c#語言來程式設計實現。總的來說，系統的分析思路、設計與構架思想是來自於系統分析員與軟體設計師本身的，而不是來自於uml。而系統分析員和軟體設計師對系統的分析與設計能力卻是**於多年的專案分析、設計經驗。
2. uml不是必須的。乙個偉大的系統分析師或軟體構架師可以不懂uml，但不能沒有超強的分析設計能力。不懂uml會使得互相之間直觀的交流變得困難，但不一定會影響分析師與構架師的表達和交流能力，如果他們之間使用另一種方式進行交流，或許效果會比uml更好。
3. uml不是一定的。在使用uml建模的時候，並沒有乙個「絕對正確」或者「絕對錯誤」的模型，只能說模型的合理或者不合理。例如使用uml來對乙個基於兩層（two-layer）結構的學籍管理系統進行建模是完全可以的，但或許使用三層（three-layer）結構會更加合理。這也充分證明了「系統分析與設計的好壞在於人，而不在於uml」這一結論。
由此可見，我們應該正確對待uml，只有在了解了這些問題後，才能更好地學習、使用uml，讓uml更好地服務於我們的分析與設計。
UML 建模是什麼 為什麼要建模？
首先在我們學習建模之前我覺得應該了解建模是什麼？為什麼要建模？就好比如若你自己要建造一座小房子，首先得先給要建造的房子設計一張草圖甚至是藍圖 若要建造一座大廈，首先要做的肯定不是先去所需買材料，而是需要對建築物的大小，形狀和樣式做乙個規劃，做出相應的圖紙和模型。可能在規劃中突然有了更好的想法，還可以...
HTTP是什麼 HTTP不是什麼
http hyper text transfer protocol 超文字傳輸協議 可以拆分為兩個部分理解 http 是乙個 雙向協議，也就是說有兩個基本的參與者 a 和 b，資料可以在 a 和 b 之間雙向流動 雖然資料是在 a 和 b 之間傳輸，但是並沒有限制 a 和 b 兩個角色，允許中間有中...
UML 為什麼要使用UML
以前一提到uml，就想到了複雜的流程圖。很敬佩哪些想想就能畫出整個系統的uml圖的人，因為他們頭腦中有整個軟體架構的藍圖，這樣在編寫實現的時候，就會知道哪個地方改怎麼做，哪個地方如何擴充套件。而想成為架構師，uml也是必備的技能。這裡就根據 大象 thinking in uml 總結一些學習筆記。平...