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圖描述的模塊級流程與偽代碼
文章來源于領測軟件測試網 http://www.kjueaiud.com/
