二、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的深入剖析，取長補短而建立了全程建模方法，所以理所應當向相關的面向對象大師們表示敬意。
本文在寫作過程中得到了戰復東先生的熱情幫助，在此表示感謝。進入討論組討論。
