聚焦UML實踐第一步

"知道UML是好東西但是用不起來。嘗試過，結果上司要求文檔中要充分使用UML，事無巨細皆UML，結果本來很簡單的一份設計文檔加了一堆圖。評審的時候團隊還有牛人指出UML圖中這裡的菱形應該是實心的，那裡的要用半個箭頭… ”“你給我推薦的《UML Distilled》也不怎麼樣… …” 這個抱怨讓我很惱火，斷定他看得是中文版，果然！我毅然用貨到付款的方式為他定了一本英文影印版《UML Distilled》.重讀《UML Distilled》，撥開迷霧走出UML實踐第一步！

我獨不解中國人何以于舊狀況那麼心平氣和;于較新的機運就這麼疾首蹙額;于已成之局那麼委曲求全;于初興之事就這麼求全責備?

----魯迅

引子

前段時間和一個朋友在MSN上聊到UML，他一聲歎息：“知道UML是好東西但是用不起來。嘗試過，結果上司要求文檔中要充分使用UML，事無巨細皆UML，結果本來很簡單的一份設計文檔加了一堆圖。評審的時候團隊還有牛人指出UML圖中這裡的菱形應該是實心的，那裡的要用半個箭頭… …結果開會大部分時間都在炒圖怎麼畫。上司覺得這也沒帶來什麼好處，同僚們樂得擺脫，後來就不了了之了”

然後順便抱怨了我一下： “你給我推薦的《UML Distilled》也不怎麼樣… …”

這個抱怨讓我很惱火，斷定他看得是中文版，果然！我毅然用貨到付款的方式為他定了一本英文影印版《UML Distilled》.問題還要解決, 故有此文.

為什麼要用UML
定位：怎麼用UML
UML規範=束縛？
UML第一步

為什麼要用UML？

1970年以前，軟體開發人員把軟體開發工作比作探險活動，但是由于系統日趨複雜，個人英雄主義的時代在軟體危機的爆發中宣告終結。危機引出了工程化方法，并催生了各種圖形符号工具。面向對象理論出現之後，相關設計方法層出不窮，存在多種設計格式。

多種設計格式帶來交流的不便，溝通的障礙，一個統一的模組化語言需求已經是迫在眉睫。是以可以這樣講，UML的意義不在于它提供的内容而在于它的規範性和統一性。為了得到更好的設計我們需要更好的溝通,更好的溝通需要基于共同的語言進行，友善溝通這是建立UML的初衷，也是應該是使用UML最佳理由。後面的論述中希望你不要忘記了我們最初是為什麼而出發的.

UML還繼承了圖形模組化語言(graphical modeling language )的優良傳統：高屋建瓴的抽象能力。而普通的程式設計語言恰恰缺乏這種描述設計思想的能力:"The fundamental driver behind them all is that programming languages are not at a high enough level of abstraction to facilitate discussions about design."抽象化主要是為了使複雜度降低，以得到論域中較簡單的概念，好讓人們能夠控制其過程或以綜觀的角度來了解許多特定的事态。抽象過程必然包含舍棄的細枝末節，是一個裁剪的過程。抽象的結果，決定于從什麼角度上來抽象，抽象的角度取決于分析問題的目的。

關于視角，《UML Distilled》有一段精彩的三層視角的論述，這段文字被無數設計模式、領域模組化的書引了又引，比如《Design Patterns Explained》。《視角的力量--再說OO設計原則》一文中我曾經探讨過下面的三個問題：1.為什麼我們過早的糾纏于細節？問題的本質是什麼？2.救命稻草--Martin Fowler的三層視角理論3.三層視角--回頭再說OO設計原則文中的最後我完整引用了作者三層視角的論述,我是把它作為走出思維泥沼的明燈來看的。這裡不再贅述,詳情請檢視:源文檔 <http://www.cnblogs.com/me-sa/archive/2008/04/15/ooview.html>在第三版中,作者對視角的觀點做了修正:規約視角和實作視角之間的界限是很難劃厘清楚的.實踐過程中發現也沒有做這種界限的劃分的必要.

定位:怎麼使用UML？

"黑夜給了我黑色的眼睛，我卻用它尋找光明."同樣一件東西怎麼用确是不一定的，對于UML怎麼使用也要有一個定位。Martin Fowler先生給出了三種使用使用UML的方式：藍圖blueprints ，骨架 sketches，程式設計語言。

三種使用方式比較容易區分出來的是：作為程式設計語言使用.ExecutedUML對工具的要求是非常高的-需要處理代碼和圖的同步問題等等.這裡不做展開讨論，大家可以到國家文獻中心找到更多相關資料：

源文檔 <http://s.wanfangdata.com.cn/paper.aspx?q=executed%20UML&n=10&f=top> UML作為程式設計語言,典型應用時MDA.UML是MDA的事實标準，占領了90%的市場佔有率.“MDA 的願景是定義一種描述和建立系統的新的途徑。MDA 使得UML 的用途走得更遠，而不僅僅是美麗的圖畫。很多專家預言MDA 有可能會帶領我們進入軟體開發的另一個黃金時代"。

Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.

源文檔 <http://en.wikipedia.org/wiki/Model-driven_architecture>

Executable UML,often abbreviated to xtUML or xUML , is the evolution of the Shlaer-Mellor method[3] to UML. Executable UML graphically specifies a system using a profile of the UML. The models are testable, and can be compiled into a less abstract programming language to target a specific implementation.Executable UML supports MDA through specification of platform-independent models, and the compilation of the platform-independent models into platform-specific models.

源文檔 <http://en.wikipedia.org/wiki/Executable_UML>

難以區分的是藍圖blueprints 和骨架 sketches,從中文說文解字的角度我們無法獲得一個滿意的答案.按照Martin Fowler先生的論述我将二者的差別通過表格的形式列了出來，通過比較還是能看出各中端倪的：

Mode

Essence

Forward engineering

Reverse engineering

Tools

Practice

Sketch

selectivity

communicate ideas and alternatives

explain how some part of a system works

lightweight drawing tools

To help communicate some aspects of a system.

Do it quickly and collaboratively, so a common medium is a whiteboard.

Blueprint

completeness

detailed design for a programmer to code up

convey detailed information about the code

CASE Tools

(much more sophisticated )

Reducing programming to a simple and fairly mechanical activity

從上面的比較中可以看出sketches勾勒重點，藍圖blueprints注重完整性，無微不至.前者是一種探索性的explorative，後者是定義性的definitive。對于後者，一旦藍圖确定，編碼工作基本上就沒有什麼創造性了.

UML規範=束縛？

談到UML就不難以避開UML規範的話題.多年來學習程式設計語言的習慣,語言規格說明是必經之路,金科玉律一般.但是UML規範怎麼在實踐中怎麼就成為了束縛了呢？

UML 規範和c#語言規範不同的是：混亂的c#代碼可能直接無法通過編譯，但是不符合的UML規範的應用卻沒有那樣顯示的錯誤提示
UML從1.0到2.0版本之間就有差異，在新版本中很多規範都是指導性的。”指導性“反而讓我們難以抉擇。
有時候你按照規範來做了，但是卻大家卻不習慣

大師們是怎麼給我們建議的呢？

習慣用法優于規範
為了更好的表達你的意圖，時刻準備着違反規範
隻要合适，可以引入非UML圖表，不要猶豫

Okay，甩掉包袱，我們可以輕裝上陣了.

UML第一步,怎麼開始？從哪裡開始？

怎麼走出UML應用的第一步呢？像我的朋友遇到的情況先把UML規格說明熟讀麼？然後發誓把UML各種圖表能用的全用上麼？

請注意這裡有如下事實:

你已經忘記了目的地，使用UML的目的是更好的溝通，而不是充分使用UML的各種圖
即使是UML的發明者們也不能熟練使用UML所有的圖，人們需要的往往是一個很小的集合
人們買來電器之後第一件事是全面學習使用手冊麼？不是，基本規則會了就先用起來，不會的時候再去找,這個就是行動思維

我們就釋然了，沒有必要使用所有的圖，更沒有必要熟悉所有的UML規格說明，不應成為負擔。歸根究底，成為負擔的是對我們沒用的東西，銘記奧卡姆剃刀原則Occam\'s Razor：如無必要，勿增實體，大膽的舍棄對自己沒有的東西！

從哪裡開始？Martin先生給出的建議是從類圖和序列圖開始，這兩種圖是基本的，常用的，最有用的圖形。掌握了這兩種圖之後，可以嘗試其它圖，如果新的圖沒有給你帶來什麼幫助，大膽的舍棄它！

然後呢？Ok,我們行動吧!

參考書目：

發表于

2009-05-26 08:16

堅強2002

閱讀(4811)

評論(16)

編輯

舉報