二、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的深入剖析，取長補短而建立了全程建模方法，所以理所應當向相關的物件導向大師們表示敬意。
本文在寫作過程中得到了戰復東先生的熱情幫助，在此表示感謝。
QBC的六大硬傷
硬傷 系列已經是炒得爛熟了，所以取這樣的名字也是有點怕怕 不過 在行業內混了幾年，最近看花前柳下的文章少了，發現竟然取不出更好的名字，將就吧，呵呵。以前用hql比qbc多，網上都說qbc功能比hql少，我也一直有這個感覺，但是從來沒有總結過 qbc到底比 hql差在 呢？最近實現das標準，終於 全...
制約中國遊戲發展的十大硬傷
很多人都說，中國遊戲界愛抄襲，我覺得這說得不對，中國遊戲業的硬傷就是不會抄襲。技術上只會學習或者複製片面的範疇，而且中國的程式人員往往愛把眼光放在那些所謂尖端的方向以及吸引人眼球的 視覺技術 想想 p2266 的本本都能流暢的跑星際爭霸，也許我們該反省反省，遊戲到底需要什麼技術。我們往往愛拋棄或者不...
高併發系統三大利器之降級
這是高併發系統三大利器的最後一篇文章了，前面兩篇如果沒看的話可以先去看下前面的文章 高併發系統三大利器之限流 高併發系統三大利器之快取 說到服務降級，大多數人可能會認為熔斷和降級是一樣的。我曾經也一度是這樣認為的，直到有一天乙個面試官問我熔斷和降級有啥區別嗎？我直接回答沒啥區別，然後就讓我回去等通知...