最近，或許是跟微軟一直在倡導跟軟體品質、軟體生命週期有關的一些理論有關，很多朋友都對UML(Unified Modeling Language)有興趣，也來跟我討論了一些問題。比較有趣的是，這些朋友大多上過一些UML的課，卻還是不清楚，究竟要怎樣將UML應用在實務上。還有一些書籍，自己創造了一些翻譯的名詞(Use case diagram –> 用例圖 ??)，讓想好好學UML的人一開始接觸就一頭霧水…
如何學習UML，必須要先從 "你希望UML可以為你做甚麼 ?" 開始看起。UML 大致上分成兩個部分：Notation 與 Metadata。所謂的Notation，指的就是在繪製UML圖表的時候，所使用的 "標記"，像是最簡單的Actor (動作項目)：
而在UML的定義中，所有的Notation都有特定的Attributes，彼此之間也都有特別的關連與限制，這些就是在UML模型後面的Metadata。然而，對於90%以上的UML使用者來說，學會正確的使用Notation表達系統的設計，會比去搞懂Metadata來得重要。Metadata主要是給研究UML的大師們討論，以及開發UML工具的廠商使用的；對於一般使用者而言，深入了解像是”Classifier”的定義為何，不會是學習UML的重點。
"我該使用甚麼工具好 ?"
自從UML被神化之後，很多人一開始接觸UML，就開始先比較這個工具支援多少種UML模型圖、可不可以產生程式碼或是反向工程等等的課題 ---- 忽略掉原本UML的初衷，是要用來幫助專案開發團隊溝通的一種模型。
理論上，UML模型是系統的藍圖，藍圖做好了，根據藍圖來產生程式碼，應該是沒有太大問題。但就像是建築學發展了幾千年，到目前為止，藍圖畫好了，也沒有辦法直接變成大樓一樣；你永遠不要期望任何UML工具，可以在模型建置好之後，可以直接建立系統出來。就算你所使用的工具有這樣的能力，但是在這個很多PM連使用案例圖(Use case diagram)都畫不好的情況下，你又如何能確保你的模型是完整的 ?
雖然在UML 2當中，定義了十多種的圖形，然而在實務上，通常使用其中的4、5種模型圖就可以將系統描述得很清楚。若是各位有興趣學習UML，請記得學習如何建立基本的UML模型圖，遠比學習UML工具來的重要 -- 沒有人規定不可以用小畫家繪製UML模型圖，不是嗎 ?
因此，要學習UML，只需要使用容易上手，具親合力的工具即可。簡單、容易上手的工具，可以讓UML更容易導入專案當中；而過於複雜的工具，雖然看起來很厲害，但往往因為加了太多東西而導致不容易使用，反而增加專案與開發團隊的困擾…
另外，因為UML模型不可能脫離系統文件與專案的程式而獨立存在，因此你所選用的UML模型工具，最好還要支援專案團隊所使用的專案管理平台(ex: Team Foundation Server)，以及開發團隊所使用的開發工具(ex: Visual Studio)，以確保在專案開發的過程中，任何的角色都可以在任何時候存取或是修正UML模型。
我在新書<<Visual C# 2010與UML 開發實戰>>的最後一章，介紹了如何使用Visual Studio 2010 在解決方案當中建立UML模型，其中也包含了UML基本圖形的介紹。如果各位有使用Visual Studio 2010開發工具，或是對於UML模型有興趣的，不妨參考看看。
這是6/29號的首頁文字，可以看到無障礙Logo
<-- 無障礙 Logo長這樣
