來源: http://blog.163.com/lzxin_2005/blog/static/15368423200826104042609/
大多數軟體人員應該對UML並不陌生,什麼是UML。它是Unified Modeling Language,它是一種建模語言,它是進行需求分析和概要設計的利器。在您的理解中,什麼是UML呢。它僅僅是那些圖形、文本和符號的集合嗎。還是一種用文本、圖形和符號的集合來描述現實生活中各類事物、活動、及其之間關係的語言呢。我聽到過兩種聲音:有許多軟體從業人員甚至軟體企業認為,UML是非常重要的,系統分析員、軟體設計師必須精通UML,這一觀點可以從大多數企業的招聘資訊中得到:“xxx職務,精通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更好地服務於我們的分析與設計。