我獨(dú)不解中國(guó)人何以于舊狀況那么心平氣和;于較新的機(jī)運(yùn)就這么疾首蹙額;于已成之局那么委曲求全;于初興之事就這么求全責(zé)備?

                                                                                                                                                                                 ----魯迅

    引子

           前段時(shí)間和一個(gè)朋友在MSN上聊到UML，他一聲嘆息：“知道UML是好東西但是用不起來。嘗試過，結(jié)果領(lǐng)導(dǎo)要求文檔中要充分使用UML，事無巨細(xì)皆UML，結(jié)果本來很簡(jiǎn)單的一份設(shè)計(jì)文檔加了一堆圖。評(píng)審的時(shí)候團(tuán)隊(duì)還有牛人指出UML圖中這里的菱形應(yīng)該是實(shí)心的，那里的要用半個(gè)箭頭… …結(jié)果開會(huì)大部分時(shí)間都在炒圖怎么畫。領(lǐng)導(dǎo)覺得這也沒帶來什么好處，同事們樂得擺脫，后來就不了了之了”

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

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

         

    1. 為什么要用UML
    2. 定位：怎么用UML
    3. UML規(guī)范=束縛？
    4. UML第一步

      

    為什么要用UML？

            1970年以前，軟件開發(fā)人員把軟件開發(fā)工作比作探險(xiǎn)活動(dòng)，但是由于系統(tǒng)日趨復(fù)雜，個(gè)人英雄主義的時(shí)代在軟件危機(jī)的爆發(fā)中宣告終結(jié)。危機(jī)引出了工程化方法，并催生了各種圖形符號(hào)工具。面向?qū)ο罄碚摮霈F(xiàn)之后，相關(guān)設(shè)計(jì)方法層出不窮，存在多種設(shè)計(jì)格式。

            多種設(shè)計(jì)格式帶來交流的不便，溝通的障礙，一個(gè)統(tǒng)一的建模語(yǔ)言需求已經(jīng)是迫在眉睫。所以可以這樣講，UML的意義不在于它提供的內(nèi)容而在于它的規(guī)范性和統(tǒng)一性。為了得到更好的設(shè)計(jì)我們需要更好的溝通,更好的溝通需要基于共同的語(yǔ)言進(jìn)行，方便溝通這是創(chuàng)建UML的初衷，也是應(yīng)該是使用UML最佳理由。后面的論述中希望你不要忘記了我們最初是為什么而出發(fā)的.

          

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

          關(guān)于視角，《UML Distilled》有一段精彩的三層視角的論述，這段文字被無數(shù)設(shè)計(jì)模式、領(lǐng)域建模的書引了又引，比如《Design Patterns Explained》。《視角的力量--再說OO設(shè)計(jì)原則 》一文中我曾經(jīng)探討過下面的三個(gè)問題：1.為什么我們過早的糾纏于細(xì)節(jié)？問題的本質(zhì)是什么？2.救命稻草--Martin Fowler的三層視角理論3.三層視角--回頭再說OO設(shè)計(jì)原則文中的最后我完整引用了作者三層視角的論述,我是把它作為走出思維泥沼的明燈來看的。這里不再贅述,詳情請(qǐng)查看:源文檔 <http://www.rzrgm.cn/me-sa/archive/2008/04/15/ooview.html>在第三版中,作者對(duì)視角的觀點(diǎn)做了修正:規(guī)約視角和實(shí)現(xiàn)視角之間的界限是很難劃分清楚的.實(shí)踐過程中發(fā)現(xiàn)也沒有做這種界限的劃分的必要.

     

    定位:怎么使用UML？

            "黑夜給了我黑色的眼睛，我卻用它尋找光明."同樣一件東西怎么用確是不一定的，對(duì)于UML怎么使用也要有一個(gè)定位。Martin Fowler先生給出了三種使用使用UML的方式：藍(lán)圖blueprints ，骨架 sketches，編程語(yǔ)言。

            三種使用方式比較容易區(qū)分出來的是：作為編程語(yǔ)言使用.ExecutedUML對(duì)工具的要求是非常高的-需要處理代碼和圖的同步問題等等.這里不做展開討論，大家可以到國(guó)家文獻(xiàn)中心找到更多相關(guān)資料：

    源文檔 <http://s.wanfangdata.com.cn/paper.aspx?q=executed%20UML&n=10&f=top> UML作為編程語(yǔ)言,典型應(yīng)用時(shí)MDA.UML是MDA的事實(shí)標(biāo)準(zhǔn)，占領(lǐng)了90%的市場(chǎng)份額.“MDA 的愿景是定義一種描述和創(chuàng)建系統(tǒng)的新的途徑。MDA 使得UML 的用途走得更遠(yuǎn)，而不僅僅是美麗的圖畫。很多專家預(yù)言MDA 有可能會(huì)帶領(lǐng)我們進(jìn)入軟件開發(fā)的另一個(gè)黃金時(shí)代"。

    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>

     

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

     

        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勾勒重點(diǎn)，藍(lán)圖blueprints注重完整性，無微不至.前者是一種探索性的explorative，后者是定義性的definitive。對(duì)于后者，一旦藍(lán)圖確定，編碼工作基本上就沒有什么創(chuàng)造性了.

     

    UML規(guī)范=束縛？

          談到UML就不難以避開UML規(guī)范的話題.多年來學(xué)習(xí)編程語(yǔ)言的習(xí)慣,語(yǔ)言規(guī)格說明是必經(jīng)之路,金科玉律一般.但是UML規(guī)范怎么在實(shí)踐中怎么就成為了束縛了呢？

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

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

    1. 習(xí)慣用法優(yōu)于規(guī)范
    2. 為了更好的表達(dá)你的意圖，時(shí)刻準(zhǔn)備著違反規(guī)范
    3. 只要合適，可以引入非UML圖表，不要猶豫

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

     

    UML第一步,怎么開始？從哪里開始？

           怎么走出UML應(yīng)用的第一步呢？像我的朋友遇到的情況先把UML規(guī)格說明熟讀么？然后發(fā)誓把UML各種圖表能用的全用上么？

        請(qǐng)注意這里有如下事實(shí):

    • 你已經(jīng)忘記了目的地，使用UML的目的是更好的溝通，而不是充分使用UML的各種圖
    •  即使是UML的發(fā)明者們也不能熟練使用UML所有的圖，人們需要的往往是一個(gè)很小的集合
    • 人們買來電器之后第一件事是全面學(xué)習(xí)使用手冊(cè)么？不是，基本規(guī)則會(huì)了就先用起來，不會(huì)的時(shí)候再去找,這個(gè)就是行動(dòng)思維

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

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

     

    然后呢？Ok,我們行動(dòng)吧!

        

     

     

參考書目：