關鍵字：UML 硬傷 本文從UML建模連貫性方面存在的問題，以管理軟件開發為例，針對與UML模型銜接的上游、下游、模型內部關系三個方面，分析了采用UML建模造成的三大隔閡，希望與眾多建模愛好者共同探討。
在國內的公開報道中，幾乎眾口一致地充斥著對統一建模語言UML（Unified Modeling Language）的褒獎，即便有公開抱怨也只是怪自己無法理解三位UML創始人的深不可測，怪自己的水平不夠，沒有料到UML本身存在著種種問題。本文作者只在北京大學計算機系的同行那里發現了他們撰文對UML的有效性提出了質疑。與公開報道相左，業界私下流行觀點形象地說明了UML存在問題為軟件開發設置的障礙，那就是“上不著天、下不著地、一盤散沙”：
（1）“上不著天”這種隔閡使建模結果無法與用戶溝通確認所謂的需求，埋下了軟件危機的禍根；
（2）“下不著地”這種隔閡使千辛萬苦得到的建模結果無法指揮程序員編碼，最后得到的軟件與用戶期望的結果很遠，返工、誤工、煩惱無窮；
（3）“一盤散沙”這種隔閡讓建模圖形之間的關系凌亂不堪，建模過程千辛萬苦，建模結果很難自圓其說。
這三大隔閡造成的建模硬傷使UML辜負了人們的殷切期望，“高不成、低不就”說明了UML建模在軟件生命周期中步履蹣跚，“一盤散沙”說明了UML在建模內容中并未實現Unified的原旨，圖 1是UML存在問題的可視化表達。
圖 1 采用UML描述的建模結果“分崩離析”
誠然，掌握UML很容易謀到一份很好的系統分析員工作，但用它卻很難做好系統分析員的分內工作，使用UML肯定可以100%蒙住用戶，因為用戶對滿篇的建模圖表只有招架之功，絕無理解反駁之力，使用UML也幾乎可以100%蒙住軟件公司老板，因為老板不是系統分析員，不知道使用UML進行建模的千辛萬苦，系統分析員無法向老板反映UML存在的問題，因為這樣很容易招致水平不高的責難。
一、UML上不著天——與用戶/領域專家無法溝通獲得真正的需求
所謂“上不著天”是指使用UML建模后很難與處于軟件開發上游的企業用戶溝通，因為UML的表達方式與上游用戶的行業知識相差甚遠，用戶一看見滿篇的軟件工程術語與符號就發怵，根本無法理解使用UML所描述的業務流程，也難以真正理解UML所陳述的需求，與業務專家交流無工而返，導致軟件大廈一開始就建立在沙子上，需求不清不楚，沒完沒了的胡子工程就此落下病根，這種情況造成了軟件開中的第一個隔閡，是UML的第一大硬傷。
對企業用戶來講，他們關心的是如何在其組織結構、業務流程、業務信息的描述基礎上，定位企業的宏觀管理水平的需求和微觀管理操作的需求。
1 UML難以完整全面地描述企業的分工結構
圖 2是采用全程建模方法組成結構樹描述的企業分工組成，它以直觀、徹底、一目了然的方式將一個企業按層次地展現為部門、崗位、職責、步驟、直至原子步驟，如“核對數量、核對規格、簽字、填寫入庫日期”等。
文章來源于領測軟件測試網 http://www.kjueaiud.com/