UML的三大“硬傷”

本文從UML建模連貫性方面存在的問題，以管理軟件開發為例，針對與UML模型銜接的上游、下游、模型內部關系三個方面，分析了采用UML建模造成的三大隔閡，希望與眾多建模愛好者共同探討。

　　在國內的公開報道中，幾乎眾口一致地充斥著對統一建模語言UML（Unified Modeling Language）的褒獎，即便有公開抱怨也只是怪自己無法理解三位UML創始人的深不可測，怪自己的水平不夠，沒有料到UML本身存在著種種問題。本文作者只在北京大學計算機系的同行那里發現了他們撰文對UML的有效性提出了質疑。與公開報道相左，業界私下流行觀點形象地說明了UML存在問題為軟件開發設置的障礙，那就是“上不著天、下不著地、一盤散沙”：

　?。?）“上不著天”這種隔閡使建模結果無法與用戶溝通確認所謂的需求，埋下了軟件危機的禍根；

　?。?）“下不著地”這種隔閡使千辛萬苦得到的建模結果無法指揮程序員編碼，最后得到的軟件與用戶期望的結果很遠，返工、誤工、煩惱無窮；

　?。?）“一盤散沙”這種隔閡讓建模圖形之間的關系凌亂不堪，建模過程千辛萬苦，建模結果很難自圓其說。

　　這三大隔閡造成的建模硬傷使UML辜負了人們的殷切期望，“高不成、低不就”說明了UML建模在軟件生命周期中步履蹣跚，“一盤散沙”說明了UML在建模內容中并未實現Unified的原旨，圖 1是UML存在問題的可視化表達。


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

　　誠然，掌握UML很容易謀到一份很好的系統分析員工作，但用它卻很難做好系統分析員的分內工作，使用UML肯定可以100%蒙住用戶，因為用戶對滿篇的建模圖表只有招架之功，絕無理解反駁之力，使用UML也幾乎可以100%蒙住軟件公司老板，因為老板不是系統分析員，不知道使用UML進行建模的千辛萬苦，系統分析員無法向老板反映UML存在的問題，因為這樣很容易招致水平不高的責難。

　　一、UML上不著天——與用戶/領域專家無法溝通獲得真正的需求

　　所謂“上不著天”是指使用UML建模后很難與處于軟件開發上游的企業用戶溝通，因為UML的表達方式與上游用戶的行業知識相差甚遠，用戶一看見滿篇的軟件工程術語與符號就發怵，根本無法理解使用UML所描述的業務流程，也難以真正理解UML所陳述的需求，與業務專家交流無工而返，導致軟件大廈一開始就建立在沙子上，需求不清不楚，沒完沒了的胡子工程就此落下病根，這種情況造成了軟件開中的第一個隔閡，是UML的第一大硬傷。

　　對企業用戶來講，他們關心的是如何在其組織結構、業務流程、業務信息的描述基礎上，定位企業的宏觀管理水平的需求和微觀管理操作的需求。

　　1 UML難以完整全面地描述企業的分工結構

　　圖 2是采用全程建模方法組成結構樹描述的企業分工組成，它以直觀、徹底、一目了然的方式將一個企業按層次地展現為部門、崗位、職責、步驟、直至原子步驟，如“核對數量、核對規格、簽字、填寫入庫日期”等。


圖 2 采用全程建模方法描述的分工組成結構可以細化到原子級工作步驟

　　圖 3是采用UML的Use Case 圖來描述組織結構，它只能描述到崗位職責，對崗位職責中的工作步驟無法描述。對業務的描述粗枝大葉，結果需求也是粗枝大葉，但用戶往往不知道需要特別重視這一點，更不知道這種粗枝大葉會給項目帶來災難。這是糾纏不清的胡子工程問題點之一。


圖 3 采用UML描述的分工組成結構至多只能描述到職責級

　　2 UML難以從宏觀把控業務流程的完整與準確

　　圖 4是用全程建模方法順序圖描述的業務協作流程——“采購”，它將業務事件序列與業務活動有機地集成在一個圖形中，用戶可以直觀地判斷軟件開發人員描述的業務流程是否正確、完整。


圖 4 采用全程建模方法的順序圖描述業務協作流程

　　圖 5與圖 6分別用UML順序圖和活動圖描述的業務協作流程——“采購”，問題其一是用戶需要左一眼、右一眼、上一眼、下一眼地對照兩張圖，費時費力，檢查兩種圖時在所難免地會出現遺漏、不一致；問題其二是UML順序圖缺少條件分支的表達方法，表達內容不完整；問題其三是UML順序圖和活動圖從形式上到內容上不存在等價關系。

　　使用UML描述業務流程很難讓人放心，因為描述業務流程時產生的遺漏、不一致、不完整，同樣會給項目帶來災難。這是糾纏不清的胡子工程問題點之二。





　　3 UML無法從微觀把控業務信息的操作過程

　　圖 7從微觀上用全程建模方法PAD圖描述了職責細化流程——庫管員如何“入庫”，它不僅描述了崗位職責展開的具體邏輯步驟，同時也描述了如何對業務信息進行操作，如對“入庫單”的 “實際入庫數量、入庫日期”等欄目進行填寫操作，對“入庫單”的 “商品規格、采購數量”等欄目及“采購計劃”的等“商品規格、計劃采購數量”等欄目進行讀取操作。


圖 7 采用全程建模方法的PAD圖描述的職責細化流程

　　UML根本無法從微觀上描述業務信息的操作過程，只能等到編程時再由有經驗、責任心強的程序員去了解，這無疑于邊蓋樓邊考慮在哪里開窗戶，最后各種問題盤根錯節，摁倒葫蘆起了瓢。軟件公司練就了不少救火高手，但不容否認的是充滿了救火隊員項目常常意味著滅頂之災。這是糾纏不清的胡子工程問題點之三。

　　4 UML無法徹底全面描述用戶的需求

　　圖 8是采用全程建模方法組成結構樹進行功能定義，它可以細致到原子工作步驟級，比如“簽字入庫”仍然需要手工進行。


圖 8 采用全程建模方法組成結構樹進行功能定義

　　采用UML無法對這種功能需求直觀地定位，結果是開發人員好心好意地實現了電子簽名，而客戶卻毫不領情，應為中國用戶不相信計算機的簽名，去掉這個功能也是一件麻煩事。

　　另外常常發生的情況是開發軟件遺漏了大量用戶需要的功能，如用戶需要計算機自動核對“采購計劃”中的“計劃采購數量”與“入庫單”中的“計劃采購數量”，如果需求定位沒有細致到這種程度，程序員如果沒有經驗或責任心不強，自然會忘記這些，那么在測試階段或者系統上線運行后用戶肯定會發現要求修改，改來改去的麻煩又會特別多，反反復復修改的工作量極大地加大了軟件公司的開發成本。這是糾纏不清的胡子工程問題點之三。

　　5 UML是造成信息不對稱的“功臣”

　　可以說UML為用戶（甲方）與開發方（乙方）的信息不對稱提供了“有力的手段”，雙方都互占“便宜”，因為這種信息不對稱不但表現在有關信息產品和信息技術的知識上，還表現在乙方對甲方的業務理解上。由于乙方對甲方的業務術語理解不一定全面和準確，有可能在乙方看來含義非常簡單的一個業務功能在甲方的經典著作或國家標準中含義非常豐富，需要做大量的工作。這樣在使用UML的情況下，乙方按照自己的理解與甲方簽了協議，但真正實施時卻必須按甲方的國家標準去實施，這種扯皮的事在項目實施過程中大量存在。在信息項目的對策模型中，很難說乙方就一定能在合同中處于優勢。

　　由于信息化熱潮的影響，許多公司紛紛進入IT項目建設市場，這些公司中難免有不少是屬于魚目混珠一類的，他們可以在報價中拚命地壓低價格贏得標書，但在實際建設中卻以各種手段欺騙用戶，使用戶蒙受巨大損失。還有一些很有名氣的院校和公司承接IT項目建設業務之后，由于各種業務量太大，對其中一些中小項目投入精力不夠，雇請一些新手作項目，囫圇吞棗，出了問題要么說用戶當時沒有說清楚，要么說用戶水平太低不會用。

　　即使乙方很勤奮，將方案做得很先進、很完美，充分考慮各模塊的設置，也重視信息安全等問題，在使用UML的情況下，因為UML存在的種種問題，仍有可能因為乙方對甲方業務信息的理解能力不夠，而使得乙方的方案和產品偏離甲方的真實需求。



　　二、UML下不著地——無法提供直接到位的素材指導程序員編程

　　所謂“下不著地”是指費盡心力地使用UML建模后，很難讓處于軟件開發下游的程序員直接接受去編程，因為UML的表達方式不直接支持詳細設計，程序員還得費盡周折地琢磨如何把建模結果轉換成程序代碼，這種情況造成了軟件開中的第二個隔閡，是UML的第二大硬傷。

　　與現代編譯器對接的是結構化程序設計，如偽代碼、PAD（問題分析圖），前者為80%的美國公司使用，后者為80%的日本公司使用。偽代碼的優點是從語法結構上與通常的高級語言非常接近，PAD由于可視化的特點十分便于人的理解，在圖 9中，全程建模方法建立了這兩種詳細設計的聯系，可以輕松地將PAD轉換成偽代碼。


圖 9 采用全程建模方法PAD圖描述的模塊級流程與偽代碼

　　另外，UML沒有對系統級、模塊級接口的考慮，這在大型復雜系統開發重視不可想象的，圖 10采用全程建模方法中數據匯總圖自動描述的系統之間的接口。


圖 10 采用全程建模方法中數據匯總圖描述的系統之間的接口

　　三、UML一盤散沙——沒有在細微之處建立建模圖形之間的聯系

　　UML建模圖形之間的內部聯系十分松散，這種隔閡造成了UML的第三大硬傷，由于篇幅的關系，這種硬傷造成的潛在危害不再討論，本文只是將“散沙”“羅列”如下：

　　1 狀態轉移圖中，事件與外部Actor、Class、Package等無關；

　　2 無法從語法上建立狀態轉移圖與順序圖的聯系；

　　3 無法從語法上活動圖應與順序圖在流程描述關系；

　　4 協作圖和順序圖中與Message相伴的參數與類圖無關。

　　雖然UML有這樣那樣的問題，不過UML也是從版本0.9發展到現在的1.4版，我們期待UML的升級，但在將要發布的2.0版中卻沒有“改過”的跡象。

　　本文對UML攻擊頗多，實際上全程建模方法從UML及其前身OMT（Object Modeling Technique）獲益匪淺，作者也是經過對OMT、OOSE、UML以及OOA/OOD的深入剖析，取長補短而建立了全程建模方法，所以理所應當向相關的面向對象大師們表示敬意。

　　本文在寫作過程中得到了戰復東先生的熱情幫助，在此表示感謝。

原文轉自：http://www.anti-gravitydesign.com