本文從UML建模連貫性方面存在的問題，以管理軟件開發(fā)為例，針對(duì)與UML模型銜接的上游、下游、模型內(nèi)部關(guān)系三個(gè)方面，分析了采用UML建模造成的三大隔閡，希望與眾多建模愛好者共同探討。
在國內(nèi)的公開報(bào)道中，幾乎眾口一致地充斥著對(duì)統(tǒng)一建模語言UML（Unified Modeling Language）的褒獎(jiǎng)，即便有公開抱怨也只是怪自己無法理解三位UML創(chuàng)始人的深不可測，怪自己的水平不夠，沒有料到UML本身存在著種種問題。本文作者只在北京大學(xué)計(jì)算機(jī)系的同行那里發(fā)現(xiàn)了他們撰文對(duì)UML的有效性提出了質(zhì)疑。與公開報(bào)道相左，業(yè)界私下流行觀點(diǎn)形象地說明了UML存在問題為軟件開發(fā)設(shè)置的障礙，那就是“上不著天、下不著地、一盤散沙”：
（1）“上不著天”這種隔閡使建模結(jié)果無法與用戶溝通確認(rèn)所謂的需求，埋下了軟件危機(jī)的禍根；
（2）“下不著地”這種隔閡使千辛萬苦得到的建模結(jié)果無法指揮程序員編碼，最后得到的軟件與用戶期望的結(jié)果很遠(yuǎn)，返工、誤工、煩惱無窮；
（3）“一盤散沙”這種隔閡讓建模圖形之間的關(guān)系凌亂不堪，建模過程千辛萬苦，建模結(jié)果很難自圓其說。
這三大隔閡造成的建模硬傷使UML辜負(fù)了人們的殷切期望，“高不成、低不就”說明了UML建模在軟件生命周期中步履蹣跚，“一盤散沙”說明了UML在建模內(nèi)容中并未實(shí)現(xiàn)Unified的原旨，圖 1是UML存在問題的可視化表達(dá)。

圖 1 采用UML描述的建模結(jié)果“分崩離析”

誠然，掌握UML很容易謀到一份很好的系統(tǒng)分析員工作，但用它卻很難做好系統(tǒng)分析員的分內(nèi)工作，使用UML肯定可以100%蒙住用戶，因?yàn)橛脩魧?duì)滿篇的建模圖表只有招架之功，絕無理解反駁之力，使用UML也幾乎可以100%蒙住軟件公司老板，因?yàn)槔习宀皇窍到y(tǒng)分析員，不知道使用UML進(jìn)行建模的千辛萬苦，系統(tǒng)分析員無法向老板反映UML存在的問題，因?yàn)檫@樣很容易招致水平不高的責(zé)難。 軟件開發(fā)網(wǎng)

一、UML上不著天——與用戶/領(lǐng)域?qū)＜覠o法溝通獲得真正的需求
所謂“上不著天”是指使用UML建模后很難與處于軟件開發(fā)上游的企業(yè)用戶溝通，因?yàn)閁ML的表達(dá)方式與上游用戶的行業(yè)知識(shí)相差甚遠(yuǎn)，用戶一看見滿篇的軟件工程術(shù)語與符號(hào)就發(fā)怵，根本無法理解使用UML所描述的業(yè)務(wù)流程，也難以真正理解UML所陳述的需求，與業(yè)務(wù)專家交流無工而返，導(dǎo)致軟件大廈一開始就建立在沙子上，需求不清不楚，沒完沒了的胡子工程就此落下病根，這種情況造成了軟件開中的第一個(gè)隔閡，是UML的第一大硬傷。 http://www.

對(duì)企業(yè)用戶來講，他們關(guān)心的是如何在其組織結(jié)構(gòu)、業(yè)務(wù)流程、業(yè)務(wù)信息的描述基礎(chǔ)上，定位企業(yè)的宏觀管理水平的需求和微觀管理操作的需求。

圖 2是采用全程建模方法組成結(jié)構(gòu)樹描述的企業(yè)分工組成，它以直觀、徹底、一目了然的方式將一個(gè)企業(yè)按層次地展現(xiàn)為部門、崗位、職責(zé)、步驟、直至原子步驟，如“核對(duì)數(shù)量、核對(duì)規(guī)格、簽字、填寫入庫日期”等。

http://www.