UML三大硬傷

領測軟件測試網 UML三大硬傷

撰文/高展
程序員雜志2002年第5期


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

　

　

　

　

　

　

　

　

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

=======================================================以下為很多的評論：

tata1 (2002-6-17 16:40:37) 

感想： 高展先生的文章已引起不小的風波，有人認同，有人遲疑，有人反對。我認為，我們每個人都應該感想高先生，是他與作為“軟件開發標準技術”的UML唱了反調，他敢于挑起一場風波，而這場風波早應該發生了。 軟件開發是一個技術研究與應用實踐緊密結合的過程，程序員必需具備科學的研究精神，辯證的思考問題而不是沉迷于某項新技術，新思想的玩弄，或迷信于某個理論的說法。如果伽利略不敢否認亞里士多得，如果愛因斯坦不敢否認牛頓，那么今天會是怎么樣呢？ 我敢肯定，即使那些擁護UML的人對UML也不全是很精通的。為什么所謂標準就無澥可擊了，聘什么認為老外做的東西就是好的？中國軟件應該發起一場革命，鏟除那些形而上學，教條主義的思想，建立統一的正確的認識。用哲學的發展，全面，辯證的思想來認識問題，認識軟件工程。 


tata1 (2002-6-12 16:10:18) 

UML手冊已經說明UML是一個建模符號體系，不適合完成全過程的設計應用。所以，高先生說UML“上不著天，下不著地，一盤散沙”有點偏激了。 我認為，UML確實存在使用，普及困難的問題。UML加上RUP后，內容太多，還要學習面向對象技術，確實使軟件開發難度很大。一個設計思想或設計工具的運用主要是為了縮短開發周期，提高代碼的利用率，可維護性等方面。所以我非常同意高先生的全程建模思想，我最近也產生了一些類似的構想。我希望理想的設計工具如下：一：歸納各軟件開發階段的問題，和解決問題的方法和技巧，指導性地分析設計。二：有層次，有聯系的表達各階段，各模塊，各對象等元素的構成。三：和代碼保持同步。即設計到代碼的正反向功能。 ... 我的Mail:kmbaojun@msn.com 歡迎討論 

zy422 (2002-6-11 10:15:19) 

我是一個有個編程經驗多年的人，我也用 ROSE 來設計個一些東西，但我感覺到 ROSE 在給程序員一個交代時做得很不夠，應為程序員最關心的是這個函數要做什么事、怎么在這個函數里做，函數里到底要使用到設計的那些類和函數，這 ROSE 實在是做得不好，所以現在我們公司里的程序員一般都不看 ROSE 圖，靠和設計人員直接交流來完成對設計要求的認識。我希望 ROSE 在以后的版本中能做一些好的，能和程序員交流的工具或表達視圖。 UML 還有很長的一段路要走，我真正用好了的只有類設計，其他的我實在是用不好了。 我個人的觀點，實用的就是好的，管它是面向對象還是面向過程，關鍵是要大家都用，都能夠用好,多能方便的使用。對于 UML 我認為它站得太高了，現在很多人都還不能用好。 

gale (2002-6-7 14:38:57) 

3boy說的不錯，但離題了，希望不是槍手，更不要顧左右而言它讓我們重新看一下問題,作者說的是：UML的三大硬傷拋開工具，考慮一下思路這個UML三大硬傷的認識是錯誤的，理由我在前面的貼子已經描述過了我希望大家能就這“三大硬傷”提出意見，而不要偏離主旨 1,再駁“上不著天” 有什么形式化的方法能對問題域進行信息無損的描述？？？理論上還沒有，目前走在業界前面的，是國際標準的，就是UML了 XX建模方法我不熟悉，沒有發言權，但....這個不是國際標準 2，再駁“下不著地” XX建模方法有類和對象級的表達語法嗎？反正在這篇文章里沒有看到哎，我也不行，做不出自己的建模方法來，我“五十步笑百步” 3，再駁“一盤散沙” 昨日在《程序員》上拜讀了高先生的《XX建模方法》不用我說，各位明眼的人就能看的出哪種方法的形式化推導關系更嚴密了 

3boy (2002-6-7 9:31:32) 

我覺的以上的言論太過偏激了，火藥味太過于濃厚了，軟件分析的目的是為了讓大家都弄明白一個目的，那就是 “你該做什么？你要做什么？或則你要其別人做什么？”，而所謂的Rational產品，以及高先生的Playcase包括其它的一些建模工具都充其量和word差不多，只不過使用方便一些而已，“人”的因數還是最重要的，這就是對系統分析設計人員的素質要求。我覺的我們不能“神話”建模工具，而忽略了人，即使我們沒有好的“畫圖”工具只要有人在，我們甚至可以“手繪”全部工作流，以上的爭論好像就在討論“畫圖板”的優劣，而不是在探討軟件工程真正的要旨，我覺的應該討論的是“如何讓大家都明白，你要做什么，我能為你做什么，你有些什么可以為我而提供的，你是這樣的嗎？。。。。�！� 軟件工程是一個不確定標準的學科，不確定的原由是，每個人都有自己的主張，不管主張的好壞，至少要知道你在為誰分析，你的對象是如何的，如果你畫的東西別人都不理解，或者他們要花費很大的代價去理解，我認為那就是失敗的方法，那么我們就必須尋求其他的途徑去讓人理解。 “我的三大忠告” 1、“條條大路通羅馬” 2、“能解決問題的方法才是好方法” 3、“好的畫家，即使沒有豐富的顏料，和優良的畫筆，依舊可以做出優秀的傳世之作” 

3boy (2002-6-7 9:26:54) 

我覺的以上的言論太過偏激了，火藥味太過于濃厚了，軟件分析的目的是為了讓大家都弄明白一個目的，那就是 “你該做什么？你要做什么？或則你要其別人做什么？”，而所謂的Rational產品，以及高先生的Playcase包括其它的一些建模工具都充其量和word差不多，只不過使用方便一些而已，“人”的因數還是最重要的，這就是對系統分析設計人員的素質要求。我覺的我們不能“神話”建模工具，而忽略了人，即使我們沒有好的“畫圖”工具只要有人在，我們甚至可以“手繪”全部工作流，以上的爭論好像就在討論“畫圖板”的優劣，而不是在探討軟件工程真正的要旨，我覺的應該討論的是“如何讓大家都明白，你要做什么，我能為你做什么，你有些什么可以為我而提供的，你是這樣的嗎？。。。。�！� 軟件工程是一個不確定標準的學科，不確定的原由是，每個人都有自己的主張，不管主張的好壞，至少要知道你在為誰分析，你的對象是如何的，如果你畫的東西別人都不理解，或者他們要花費很大的代價去理解，我認為那就是失敗的方法，那么我們就必須尋求其他的途徑去讓人理解。 “我的三大忠告” 1、“條條大路通羅馬” 2、“能解決問題的方法才是好方法” 3、“好的畫家，即使沒有豐富的顏料，和優良的畫筆，依舊可以做出優秀的傳世之作” 

gale (2002-6-3 11:07:14) 

1，技術是不分國界的，你用手在白板上畫UML圖是無需支付任何費用給US的 2，不要動不動就把技術問題上升到政治和民族主義 3，“拿來主義”，英美都能虛心拿去中國的火藥制造槍炮來打中國，你難道不能學美國的 UML來打敗US的軟件產業？？��！ 4，作為中科院的人物，講話是要負很大責任的，因為你的錯誤講影響千千萬萬的人如果你錯了并且是個權威，你將造就“十年浩劫”��！ 

chinakid (2002-6-3 10:06:48) 

我想不通！為什么高展先生一說UML不好，就有人跳出來大罵，為什么，為什么？難到美國人的東西就不能批評嗎？難倒中國人的智慧就比美國人差嗎？中國人，不要輕易低下你高貴的頭！ 


gale (2002-6-1 0:38:51) 

1，“上不著天” 錯，UML中的 Business Use Case Model 和 Business Object Model就是干這個的。最少現在還沒有比UML描述業務更通用，更清楚的 2，“下不著地” 又錯，Rose可以生成代碼，再加上 XDE與Visual Studio.NET的集成 3，“一盤散沙" 還是錯，Business UC Model--》Business UC Realizations--》Business Object Model Business Worker --》; Actor --》 Use Case --》Use Case Realization --》Analysis Model --》 Design Model --》Imp model 都是有嚴密的推導關系的什么“專家”？？��！純粹是誤人子弟��！補充：好像牛頓先生說：“我之所以偉大是因為站在巨人的肩膀上” 軟件開發領域里“巨人的肩膀”就是前人工作的結果和經驗 US的軟件比中國強原因之一是國人（我也是）都喜歡重新發明輪子 UML是一個標準，不是R$的產品，你要是真有水平應該提交UML2.0給OMG，而不是自己閉門造車弄個什么XX建模方法出來。 建議高先生好好看看UML+RUP+UCM這整個的思想體系，真正研究上一年再發表點有趣的文字。 

gale (2002-6-1 0:22:04) 

1，“上不著天” 錯，UML中的 Business Use Case Model 和 Business Object Model就是干這個的。最少現在還沒有比UML描述業務更通用，更清楚的 2，“下不著地” 又錯，Rose可以生成代碼，再加上 XDE與Visual Studio.NET的集成 3，“一盤散沙" 還是錯，Business UC Model-->Business UC Realizations-->Business Object Model Business Worker --> Actor --> Use Case -->Use Case Realization -->Analysis Model --> Design Model -->Imp model 都是有嚴密的推導關系的什么“專家”？？��！純粹是誤人子弟��！PlayCase版權費的驅動＋淺�。珶o恥 

kjxia (2002-5-29 15:15:13) 

我想csdn給我們提供的是一個技術論壇，作用是大家可以在這里進行交流和討論，通過交流可以解決一些實際問題，或是達到開闊視野、增長知識的目的，有不同的觀點自然可以提出，但目的是為了探討，有些用戶把對別人觀點的不認同轉化為了莫名的人身攻擊，這是很令人痛心的。 


ysmstoneman (2002-5-25 16:10:43) 

呵呵,我懂得中國的軟件為什么比不上國外的了。建議那些搞人身攻擊的“同志”們，或持反對觀點比較強烈的“專家”們都去看看《誰動了我的奶酪》這本書。記著，“我們都在害怕變化”。 UML強大，難道它就真的沒有缺點了嗎？是��！如果我精通Delphi，我真希望其他的開發工具都她嗎的消失。但它們消失了嗎？沒有，C#出來了，什么.net出來了，據說什么以色列的魔術師之類的東東也出來了，………………不知道以后還有什么東東…… 我知道原來我錯了，是我沒有適應那么快的變化，IT這行確實變得太快，永遠都有新東西出現，那應該是好事，要不，這世界上的技術怎么會發展的那么快呢？長期以來，分析工具一直是我國的空白，高展先生好不容易弄出了PLAYCASE（也許不是他一個人的功勞，但怎么說中國也出了這么個東東了），就因為這篇文章，用得著把人家罵成那樣嗎？ 


hostoop (2002-5-22 17:45:10) 

不管是UML還是其它的什么，它都只是個工具，是用得好還是用得差，靠的是用工具的人。每個工具在不同的領域有不同的作用，我不會用VB來寫硬件驅動程序，也不會用匯編語言寫財務軟件。我現在在Linux環境下用C語言寫郵件服務器程序，如果按照高先生的思路，我是不是該出來寫寫”VB的三大硬傷“、”Windows的X大硬傷“？ 


2001sky (2002-5-21 13:28:50) 

真正成功的軟件是不依靠什么UML和PLAYCASE的系統分析的作用就是把客戶的意思傳達到程序員那里系統分析就是一個調制解調的過程如果你行，用WORD就可以了如果你要蒙人，用什么都不行什么樣的人可以做系統分析？沒有做出過成功軟件（客戶滿意，代碼穩定）的人永遠沒資格做系統分析，博士也不行請不要攻擊任何工具，他不是萬能的，只是一個助手 

asp_boy (2002-5-21 8:57:20) 

不知道分析員是不是都是高高在上的，還是在CSDN中的特產。只要提出一個不能被多數人接受的觀點，就會被罵得狗血淋頭。 爭論是一定會有的。但如果指人，這與市井流氓有什么區別？有人說“PLAYCASE那玩意純熟垃圾”，想必他能設計一個比PLAYCASE更好的玩意，如果設計不出，也應該指出PLAYCASE的不足�？湛谡f白話，誰不會說啊。 最后一點， PLAYCASE是免費的，卻有人說“鄙人初次接觸PlayCase, 就發現PlayCase有許多優點......高展先生，您的PlayCase賣了幾套了？”。 可見，很多人都是推崇自己正在使用的工具。 存在偏見的人不會是好的分析員。 

shhao (2002-5-20 15:50:44) 

我認為主要問題是作者未理解（當然更談不上掌握）面向對象的思想和方法。 

zhaott (2002-5-20 13:15:12) 

工具不是主要的，主要的是人，是規格 

telescope (2002-5-20 13:06:05) 

一個老農拿鞭子敲敲拖拉機罵道，這東西沒他媽我的驢好使，不懂人話，就算費點勁把它開起來，還不得把我的地壓硬嘍？驢一拉就走，這東西他媽不要說讓我拉，就是驢也拉不動，然后還得花油錢，這是拖拉機的硬傷啊。 

telescope (2002-5-20 13:04:30) 

一個老農拿鞭子敲敲拖拉機罵道，這東西沒他媽我的驢好使，不懂人話，就算費點勁把它開起來，還不得把我的地壓硬嘍？驢一拉就走，這東西他媽不要說讓我拉，就是驢也拉不動，然后還得花油錢，這是拖拉機的硬傷啊。 

blacktigers (2002-5-20 12:07:57) 

推薦一篇文章：轉載自企業工程論壇 http://www.ee-forum.org/ 標題：復雜系統的層級原理與模型驅動軟件體系結構　 作者：余彤鷹 2002-5-17 -------------------------------------------------------------------------------- 寫在前面　　最近看到模型驅動在國內漸漸被更多的人注意，前幾天又看到一些關于UML優劣和應用方面的爭論。作為繁忙工作中的一種休息，從過往的研究筆記中整理一點東西放在這里，與大家交流。 層級理論是構建復雜軟件體系的基本原則　　諾貝爾獎獲得者赫伯特 A. 西蒙曾論述到：“要構造一門關于復雜系統的比較正規的理論，有一條路就是求助于層級理論……我們可以期望，在一個復雜性必然是從簡單性進化而來的世界中，復雜系統是層級結構的”。對于軟件這樣復雜的人造事務，發現層級和運用層級，是分析和構建的基本原則。 軟件的體系結構是層級的　　粗略地觀察一下軟件表述方式（語言）的發展：從穿孔紙帶（機器的語言）開始，首先是匯編語言，然后是高級語言，再往后有面向對象語言和所謂第四代語言（FGL）出現……應當留意：每一代的語言并不是在“取代”前一代語言，而是用上一代語言來“寫”下一代語言。在這個自然的進化過程中，西蒙所論述的復雜體系的層級特征清晰地出現了。 　　進一步看，在由簡單到復雜的進化道路上，軟件的體系結構、軟件開發的體系結構、軟件開發工具的體系結構等等，都呈現出層級的特征�！昂谩钡能浖�體系具有更加清晰的層級。 一維語言之后是模型　　這里不想展開討論這個問題，只是提出一些思考的結果。與自然語言類似，現有的“程序設計語言”是單維的，它的基本語法是以前后順序為基礎的。當系統的復雜程度提高時，用這樣的語言精確描述復雜系統變得越發困難，更遑論有效地修改維護；可視化開發平臺、代碼管理工具（甚至某種意義上共享組件也可包括在內）等的出現對此是一種補充，但仍然不是最終的解決方法。軟件描述體系進化到這里，面臨著一次突變，將有新的物種出現，這個新物種可能就是模型。筆者認為，模型與程序語言主要的區別不在于圖形化，也不在于抽象的程度，而在于表達方式突破了“單一順序”的限制，最簡單的例子就是二維表。模型可以更容易和直接地表達復雜的結構。 模型和語言都是對系統的描述　　傳統的編程語言和模型都是一種表述的體系，前者適合表述順序過程，后者適合表述復雜結構。模型的必要性可以通過下面這個例子看出來： 　　為了精確地復現，你可以用語言精確地敘述一個立方體，甚至10個立方體組合的形狀，但你不會試圖用語言描述一棟房子，適當的方式是用工程圖紙。 　　建立企業應用系統的情形可以從以上例子得到啟發，企業系統要表述的，主要是復雜的結構，過程占的比重很小，因此，模型就變得更加重要乃至必要了。 OMG組織的MDA戰略　　OMG最新的戰略，是建立模型驅動體系架構（Model Driven Architecture, MDA），它的意義不是三言兩語可以說清楚的，但從軟件進化的角度來說，可能帶有一種必然性，從上面的討論，至少可以引申出兩個理由： 更有效地描述復雜系統的需要； 系統復雜化帶來的層級區分的需要。 關于模型的幾個分析要素　　筆者認為，以下特征對軟件體系中模型的運用是十分重要，或者有特殊意義的： 模型的時效性（time-effectiveness of model）：關于這一點最重要的區分在于，是“運行期模型”（Run-Time Model），還是開發期模型？這個區別，有點類似于解釋的語言和編譯的語言間的區別，但其意義卻非同一般，筆者認為，“運行期模型”，揭示了模型驅動的本質。 模型的可進化性（evolutionableness of model）：是否可以在系統的應用過程中，持續地適應應用環境與需求的變化，不斷地由應用者或自適應地對模型進行改進？這是對模型“性能”的一種度量。 模型的層級性（hierarchy of model）：正如語言有多個層次一樣，沒有理由認為模型只有一個層次，當系統足夠復雜時，模型的層次劃分將會是必要的。 UML和企業模型　　運用上面的要素分析一下，可以發現： 　　UML是“緊貼”高級軟件語言（例如C++）的模型體系，其時效是在軟件生命周期的開發期間，而不是運行期間，其描述的層級是在軟件的組件、對象一級，典型要素是軟件中的對象，軟件上一個操作的動作等。 　　企業模型（比如ARIS, CIM-OSA, GERAM），典型的要素是組織，產品，過程等，它們是從企業的業務對象著眼的。二者在層級上有差距，而且企業模型追求的最終結果，是從“開發期模型”到達“運行期模型”，并且，筆者認為它最終應當是一種可進化的模型，這與UML的設計目標并不符合。 　　它們兩者間并不相互排斥，而應當考慮它們的“層接”。按照筆者的理解，OMG的MDA即使全面實現，也仍然不能做為或替代企業模型，但有可能成為企業模型的基礎，這不是模型好壞或能力的問題，而是層級定位的問題。 寫在后面　　面向對象（Object Oriented, OO）作為軟件體系結構方面的一種演進而出現，也曾經被一些人誤解為對過程化語言（或面向過程的體系結構）的取代。筆者認為，盡管OO反應了一種世界觀，是一種思維的方式，但并不代表一切；且從層級和進化的觀點上，也不應當將它看作是對既有東西的一種簡單的取代。模型或模型驅動同樣如此，它可能是繼面向對象之后，軟件體系結構的又一個重大的進化，但不是用來取代面向對象或結構化設計。筆者在1998年撰寫《邁向21世紀的企業信息技術應用》一文時，對于模型的地位和作用并沒有今天這樣的認識，現在我堅信，對于企業信息系統這樣復雜的系統，要想做到有效、可控制地規劃與構建乃至具有“柔性”、可在運行期間不斷地調整，“模型”是必須的，而且，表達與構建復雜企業系統時所需的模型，可能是多層次的，所謂“通用企業平臺上的專用執行系統”，就應當是一個由運行期模型驅動的系統。 -------------------------------------------------------------------------------- 

chinakid (2002-5-20 9:41:02) 

偶爾路過看到這些評論，我很氣憤。一幫美國的走狗！ UML，CMM都是人家美國人定下的標準，可笑的是軟件公司象哈巴狗一樣，跟在美國人后面搖尾巴。高展的playcase我沒有用過，但我知道一點：中國人從來不輸給別人�。。。�！政府能扶助制造自己的CPU，自己的操作系統，自己的Office軟件，也可以再扶助一個建模軟件！這樣我們就不用再仰視別人的鼻息�。�！美國人的一套Rose多少錢？賺去了中國人多少血汗錢？而高展的playcase是免費下載的�。�！為國家安全和產業利益，政府都應該對自主開發的軟件進行扶持！起來，挑戰UML霸權！ 

bigbat (2002-5-19 21:25:25) 

"UML 沒有排斥任何特殊的軟件開發方法或過程；它只不過標準化了標記法的格式。"Granville Miller 語不是UML的問題。是開發者對面向對象的方法掌握的問題。高先生的方法是可能是一種好方法。但你應弄清楚你只是其中的一種。不要弄不清楚問題的實質就大貶一通。我覺得你說的三個發面都不對！ 1“上不著天”這種隔閡使建模結果無法與用戶溝通確認所謂的需求，埋下了軟件危機的禍根； USE CASE 圖是一種很好的用來表達用戶需求的工具。何以“上不著天”？ 2“下不著地”這種隔閡使千辛萬苦得到的建模結果無法指揮程序員編碼，最后得到的軟件與用戶期望的結果很遠，返工、誤工、煩惱無窮； CLASS 圖是程序編寫的圖紙�？粗�它就可以來寫代碼。coder 們不需要了解設計的全部就可以施工。何以“下不著地”？ 3“一盤散沙”這種隔閡讓建模圖形之間的關系凌亂不堪，建模過程千辛萬苦，建模結果很難自圓其說。目前在 UML 規范中有九種圖。重不同的視角反映需求。你的設計“一盤散沙”。UML有何罪之有？ 高先生你認真對待你的“驚世”高論。您是一位學者�。。。。。�！ 

elkel (2002-5-19 19:31:36) 

真好笑，作者根本不懂UML，拿著Rose胡畫，還對UML妄加評論。惡心... 本人忍受胃痙攣的痛苦，讀完此文。力圖修正作者使用UML的錯誤，提醒初學者不要象他一樣胡畫。（其實我也是初學者:)）對于Playcase，我沒用過，不敢妄加評論，以免犯與作者一樣的錯誤。但我可以確定我今生今世都不會用它。 西門吹雪忽然道：“你學劍?” 葉孤城道：“我就是劍�！� 西門吹雪道：“你知不知道劍的精義何在?” 葉孤城道：“你說�！� 西門吹雪道：“在于誠。 葉孤城道：“誠?” 西門吹雪道：“唯有誠心正義，才能到達劍術的顛峰，不誠的人，根本不足論劍�！� 好，現在開始切入正題 1. 圖3，作者應該畫的是用例圖吧。首先，用例圖不能用來描述企業的組織結構。其次，作者用包來表示企業和部門是胡畫，包在C++和java中分別映射為namespace和package。另外，作者用用例表示職責，算沾了一點邊，但是這仍然是錯誤的，用例應該代表業務過程中角色的行為。作者所提的“不能直觀地將職責展開為步驟”，應該用協作圖表示。以作者的觀點看來，建模是以企業組織結構為中心，而UML的觀點是以業務為中心。以企業組織結構為中心，就要根據企業組織結構建立業務流，以業務為中心，企業組織結構要適應業務流程。哪個合理，很明顯。（扯的太遠了） 2. 圖5，作者的目的是描述業務流程嗎？那么請用協作圖吧，雖然順序圖和協作圖可以互相轉換，但它們是有區別的，順序圖是針對開發人員的，協作圖才是針對領域專家的。 3. 圖6，作者畫了泳道吧？胡畫��！角色的職責應該在這里表現，每一個泳道應屬于一個角色，泳道內的活動就是角色的職責。這是活動圖嗎？起始和結束點在哪呢？ 作者提出的UML三大硬傷，更本不能成立，作者根本不懂UML。 

grantguo (2002-5-19 14:59:52) 

還是那句話：沒有銀彈。。。。軟件開發過程中沒有銀彈 啊。 

kendy_yin (2002-5-19 11:24:16) 

其實你未必要去評論uml的好壞，就象linux的愛好者去說windows的壞話一樣。如果你的產品真的好地話，時間可以證明一切的。覺得還是多花點心事集他人之長，補己之短吧。希望能見到你更好的產品。其實我都不知道作者是寫什么的，從上面評論看，你是不是playcase的作者呀？ 


maxsuy (2002-5-18 19:17:38) 

作者的人品確實存在問題。 PLAYCASE我用過，我承認國內的公司能弄出這么一個東西確實不容易，可是你也犯不著這么咒罵UML吧。 PLAYCASE那玩意純熟垃圾。做出設計來到最后呢，還是沒有用。放廁所里都嫌PLAYCASE臭。 

pattern (2002-5-18 19:07:48) 

作為一個又搞分析，又編碼的軟件工程師（存在于大多數有中國特色的軟件公司）。有一條經驗應該銘記在心：不要指望可以完全掌握用戶的需求，大多情況下，業務領域專家也無法給你一個細化到原子級的需求。所以，才有object-oriented 軟件工程的出現，才有增量開發方法，才有敏捷建模，這些都是告訴我們要順應人的思維習慣，漸進開發，逐步挖掘需求，層次建模。軟件工程與建筑工程有很多共通點，但他們有一個根本的不同就是：軟件最終是可以被修改的，但你不會為一個不很合理的自動扶梯設計而修改造好的大樓，只能將就著用。所以建筑工程的需求可以被認為是確定的，而軟件則是相反。 

whack (2002-5-17 23:53:21) 

呵呵，弄了半天才是一個軟件的作者在說自己的軟件比別人的好，怪不得口氣和論述都是說得那么具有商業的味道。那我們也不妨來看看文中的幾個技術的例子： 1。面向對象開發中和用戶交流的關鍵描述工具是use case圖。所以一個工具在這個階段對用戶最重要的就是構造use case描述（必要地時候也需要對一些重要的類或者包，以及相關的一些交互細節做某種程度的描述），通常component的構造細節在和用戶交流過程中通常用到得很少。 那么use case圖作者會怎么描述呢？從文章中的對一個需求的建模結果看，也是類似的一系列圖形和符號描述方式，但是不同的是在作者的表達方式和uml有所不同，更重要的是作者列舉自己的建模圖例和uml的圖例的時候，設計的程度是不一樣的，作者的建模圖例其實是uml中的“靜態圖（類，包等）+ 一些usecase + 一些時序圖（或者順序圖）”，也就是說作者的圖形里面其實是夾雜了uml中的好幾種圖形（當然是把uml的描述方式有所簡化和變化），但是在列舉uml的設計圖形的時候，卻缺少了類的動態成分的表達（也就是方法及其順序），但是在uml中有很多的圖可以更進一步細化類或者包的設計（序列圖，交互圖，conponent圖等）。 這反映了作者對于面向對象系統描述的理解不同，uml之所以把幾種圖形分別描述，一是當需求比較復雜的時候，幾種圖加在一起的方式可能會變得無法描述，因為一張圖形可能變得已經畫不下來了。二是uml的方式認為系統具有一系列的特性，不同的特性需要有專門的方式來分別描述。圖形多看不過來，但是混合在一起，如果描述同樣的細節程度，恐怕還是很長。 2。對于微觀設計，那就要看是系統分析階段還是系統開發了。系統分析的時候做很多細節，有必要嗎？本來系統開發就是有很多細節要到系統實現階段來進行的。而且同樣的，對于任何一個小模塊，同樣地畫出component 圖，序列圖，交互圖（只不過粒度不同），想不出來這時候為什么不可以編碼？所謂的偽代碼不就是一種這些圖形的文字描述方式嗎？在描述留成的時候，其本質上是同構的（只不過偽代碼是結構化的流程圖方式來描述類或者方法的關系）。 3。實在弄不懂作者遺漏用戶需求的意思，遺漏了用戶功能是系統分析沒做完的問題，和怎么描述實在聯系不上。作者在某個流程上加了個注解，這是解決方法��？ 4。作者認為uml中間的好幾種圖形和某些元素無關，或者不能轉化為邏輯語句。這就是對uml的語法的理解問題了。這些圖形用系統工具現在都可以直接生成c++或者java代碼，那么語法轉化還需要什么。 5。uml的描述方法里面還存在著某些復雜性或者戎余，包括rose工具對于某些圖形的構造方法也存在著需要改進的部分，這些不用多討論了，只要是軟件或者標準，都是在不斷進行版本修訂中。 看了一下原文我怎么有點兒懷疑作者到底用uml做了多少項目，如果是為了宣傳產品，沒有必要做那些并不特別的例子，有些例子就只有一個自己的分析結果，就來了個結論。要知道很多在編碼過程中好像很“好看”的東西，構造成一個產品后，就成了一堆不能維護的零件了。大家都用自己“喜歡”的，結果卻往往是不能用的。 

andy2ray (2002-5-17 21:44:20) 

UML三位大師開宗明義，UML是一種語言，而不是方法，因此他本身不提供軟件開發的過程指導。如果你不清楚或想獲得在軟件開發上的過程指導，可以參考RUP。這點不知高先生是否注意到？ 

111222 (2002-5-17 15:41:31) 

寫的很好，UML本來就是垃圾！ 

enlightenment (2002-5-17 15:22:06) 

有句話是對的：盡信XX則不如無XX！ 

wuhan_wanhui (2002-5-17 14:14:50) 

UML”三大硬傷”之我見 2002年第5期高展先生的文章《UML“三大硬傷“》以管理軟件為實例，闡述了UML的三大硬傷，敘述的十分精彩。軟件開發過程中的一些問題都被高先生提出，使我受益匪淺。但是高先生的許多觀點，我不敢茍同。 UML是一種建模語言，語言是來供人們來交流，也就是供不同領域的人來交流的一個標準，就好像世界語。因此UML不是一種方法，UML建模和軟件開發過程是兩個不同的概念。UML適用于很多重軟件開發過程。因此高先生有把用UML建模的軟件開發過程和UML混淆的嫌疑，把軟件開發過程中出現的硬傷歸于UML，實屬誤解。 “上不著天”論。文中說，“建模結果無法于用戶溝通確認所謂的需求”，“用戶專家無法理解UML所描述的業務流程”。實際上業務流程是很細致的，以前我們用系統流程圖直接處理這些業務流程，用戶專家能得到很好的溝通。而現在用UML來描述業務流程，是不是有點趕時髦的嫌疑？軟件開發過程中的問題并不是UML建模都能解決的，可以這么說用UML來描述業務流程曲解了建模的本義。三位大師的著作《UML參考手冊》中說道，“模型從某一個建模觀點出發，抓住事物最重要的方面而簡化或忽略其他方面”，“ U M L是一個建模型語言，不是對開發過程的細節進行描述的工具”�？梢娊�模是要抓關鍵和重要的東西，高展先生文中說到，“UML難以從宏觀把控業務流程的完整與準確”，并舉了UML不能描述到原子級工作步驟，這與建模的思想是相違背的，建模需要的只是到關鍵的一定層次（如文中所述的職責級），而不是詳細的細枝末節�？梢哉f這正是UML的精華之處，只關注重要和關鍵而不關心細節。詳細的細節問題屬于軟件開發過程中的問題。 “下不著地”論。建模只是建立了一個模型，至于具體的詳細設計、編碼當然需要程序員去理解和思想。試想，模型和詳細設計之間不存在這個隔閡的話，從事詳細設計的軟件藍領都不要下崗了？UML存在的意義在于作為一種通用的建模語言，提供了一種建模者之間交流的標準，這當然也適用于上游的分析員和下游程序員之間的交流。UML其實也向下著地，著于這種相互之間的交流上。從模型轉換到程序代碼屬于case工具的范疇，并不能說是UML的硬傷。再說現在Rational Rose對于模型到代碼的轉換工作已經取得令人驚喜的效果。 

dearmite (2002-5-17 11:31:19) 

看了這么多，想寫點什么，其實我這兩種工具都沒用過，ROSE只是聽說，不過，沒下過雞蛋，總還見過，別人用的時候，唉，我總是很羨慕！為什么？不是UML多么高、多么好，也不是他那東西真的能轉換多少價值， 因為他開的錢比我多！我們學這些、那些建模做什么，不是做事業，我們是為了錢！ 從文章的受益度講，從文章的深度講，我想這一點，高先生一定是最高分！ 但是問題是為什么IBM的OS/2沒有比過MICROSOFT的Windows呢，因為市場！如果是我，boss讓我又做建模，又做程序，那我一定不用UML，用高先生的東西沒錯！因為一切為了實用嘛， 但是問題是，建模的人不寫代碼，寫代碼的人不建模，建模的人把關系搞好就能弄到錢，你的程序多好，你的公司通過cmm,但是你賣的程序真的用了CMM了么，不是！，都是為了多掙一點錢罷了，所以我只能以心靈上贊助高先生，如果我要學，我還是要學UML，因為這就是錢！全程建模大家一看就懂，那還了得，客戶還能買單？他不懂就對了，這就是UML的最最高明之處！ 

SouthPole (2002-5-17 11:10:11) 

我想很多讀者(包括我自己)對這篇文章非常不滿，主要是因為： 1 作者對UML及其產品缺乏足夠了解和實際使用經驗，所指的所謂“硬傷”，很多并不是UML的問題，而是對基于UML產品的錯誤理解。例如：“采用UML的Use Case 圖來描述組織結構，它只能描述到崗位職責，對崗位職責中的工作步驟無法描述” UML本身主要是用于REQUIREMENT和HIGH-LEVEL DESIGN，如你希望描述工作步驟，使用UP中USE CASE TEMPLATE即可 2 作者對UML的許多評價偏激，“上不著天、下不著地、一盤散沙“，近于全盤否定，就是當年批判GOTO時恐怕也沒到這種地步 

twinsant124 (2002-5-17 10:28:23) 

1、文章的論點：關于UML，我可沒有啥敢維護的，我是UML的初學者^_^，犯不著一上來就維護這么一個只不過是工具的東西；關于什么全程建模，咋更不敢放什么厥詞了，偶可沒有高老師對自己都不熟悉的東西大加批判，點人家死穴的勇氣和魄力。 2、作者寫技術論文的作風：作為國內很有名的軟件過程專家，請注意自己的言行可能造成初學者的迷茫和彷徨，三思而行，文章之道也。 


waterusage (2002-5-17 9:25:11) 

很多人不是在駁斥高展的論點，而是在批評他的PLAYCASE，批評他的為人了。 本來還是一個技術上的爭論，現在就成了鬧劇。 該收場了吧？吵完以后，誰也得不到好處。 但是，肯定也有人旁觀了這場爭論后，再使用UML時，多留了一個心眼。 

rayking (2002-5-17 8:58:14) 

從高先生以前寫的文章看，所用的手段都是比較傳統的。UML其實比較年輕，正是為了彌補數據流圖（所謂的“地”）和業務流程圖（所謂的“天”）等的不足而產生的。UML當然有缺點，這些缺點在幾乎所有UML書籍里都有提及。希望高先生自己先用一下UML，相信會喜歡上她的。 

softdance (2002-5-16 23:08:54) 

高先生批評UML本著學術自由的原則沒錯，高先生的PlayCase我用過在也還算不錯，而且我也相信大部分的同志也絕對不是攻擊PlayCase這種工具本身，那高先生錯在何處啊，何以招致如此多人群起而攻之。在這我只想說一句話：你可以批評大象皮糙肉厚，身體笨重，行走緩慢不如你的騾子外觀漂亮，身輕體健，奔跑如飛，我保證沒人說你什么，但是如果你批評大象不如你的騾子鼻子長牙俏,我同樣可以保證保險公司都不敢保你。點穴要點死穴才能要人命，希望高先生下一次能準一點。 

softdance (2002-5-16 22:56:59) 

高先生批評UML本著學術自由的原則沒錯，高先生的PlayCase我用過在也還算不錯，而且我也相信大部分的同志也絕對不是攻擊PlayCase這種工具本身，那高先生錯在何處啊，何以招致如此多人群起而攻之。在這我只想說一句話：你可以批評大象皮糙肉厚，身體笨重，行走緩慢不如你的騾子外觀漂亮，身輕體健，奔跑如飛，我保證沒人說你什么，但是如果你批評大象不如你的騾子鼻子長牙俏,我同樣可以保證保險公司都不敢保你。點穴要點死穴才能要人命，希望高先生下一次能準一點。 

washine (2002-5-16 20:39:35) 

什么是好的建模工具？我認為其本身有多精辟或有多深奧并不重要，重要的是是否簡單易懂。 為什么要建模呢？就是要越來越生動，便于理解，說得難聽點，最好讓傻瓜也一看就懂。 建模是給誰看的呢？并不是給軟件設計者和項目經理看的，它是連接開發人員和客戶的橋梁。 成功的建模應該具備極強的溝通能力及連貫性，條理清晰且容易接受。在這一點上UML明顯先天不足（說老實話有很多程序員都看不懂更別說客戶了）。從某種意義上說UML過于專業，熟悉面向對象的軟件設計師或許能體會它的精妙，但從一般的客戶及普通程序員來講，他們需要的是一個生動的模型，而這個模型或許并不是UML。 國人有能力有魄力推出有價值的東西，我們為何不站出來給予支持呢？哪怕它僅有一個優點，也勝過一味地跟隨。全程建模有他的可取之處，肯定也有許多不足之處（比如不夠面向對象），但一般人（包括不懂設計的程序員）卻更容易看懂它。我們要討論的不是要用誰，摒棄誰，而是哪種方法更適合項目開發，給出更佳的效率。對任何事物都不要一棍子打死，難道就不能讓它們共存么？ 

wangqiyy (2002-5-16 17:17:45) 

各打50大板！ 1、人無完人，金無足赤。每一種軟件工程方法都有其獨到的特點和所要解決的問題，UML的方法著重業務模型的建立，而I2DEF的全程建模的思想確實不錯，對于工具Rose和Playcase我都接觸過。我認為UML主要在描述做什么，逐步逐步提升到怎么做，最后到內部的類，最后編程實現；而I2DEF的感覺就像是崗位責任書，每個角色各司其職，所有的責任和角色組成整個業務。如果單單使用某一表示方法，我還沒有聽說哪家公司成功過，例如Rational自己，它就有一系列產品（像什么Request之類的工具）支持，只有把這些都用上了，才有可能是解決軟件工程問題的方法，而單獨使用都是有缺陷的，Rose內部也是建議使用大量的文檔嵌入來描述其細節和關系的。老實說，如果全部使用符合UML的工具來分析實現系統，我認為首先要解決的問題是成本（資金、時間），其次是思想的普及，只有深刻理解了UML的思想，才可能真正正確的是用它表示業務。 2、順應潮流，如果和外界交流，用UML吧！英語比起我們的漢語，那算什么��！原始的垃圾！但是老外都說，沒辦法，學唄！ 3、UML是發展的，它的存在是合理的。 4、與其在此爭執孰是孰非，不如靜下心，學習吧！ 

youyuan (2002-5-16 16:17:35) 

看到此君的文章不禁想起了馮小剛電影《大腕》中那個搜狗網的c*o,他說要想網站要想火就要雇一幫寫手，誰火啐誰，誰火滅誰，它就像這種寫手，哈哈哈，我看他是想造個轟動效果，借以讓自己成名，無聊的很，我想uml的用況在誕生時就已經說得很清楚: Use Cases are a critical technique in developing an application. Within the UML Use Cases are used primarily to capture the high level user-functional requirements of a system. This long winded description is important because Use Cases cannot usefully be used to capture non-functional requirements. Nor can they usefully be used to capture "internal" functional requirements. Attempting either or both is a sure path to disaster for two reasons. Firstly because Use Cases are an informal and imprecise modelling technique. But then they were never intended to be anything else. Secondly because the other use that we make of Use Cases is to define the fundamental structure of our application. The Use Case is not only important as a unit of requirement definition but also as our unit of estimation and our unit of work. 

softdance (2002-5-16 12:20:58) 

C++三大死穴 看了高先生的三大硬傷猶如提壺灌頂，真是頓覺自己愚笨。我的PlayC++ 已經誕生五年有余了，但一直是皇上老婆沒人要，讓我沮喪不已。但與PlayC++相比，C++是傷痕累累啊，經我以及清華的一些同事對C++的深入研究發現它的三大死穴。 一. 運行效率無與輪比的差。C++雖然編譯速度挺快，但是運行效率卻是太差，據我反復測試在同樣的操作環境中比PlayC++慢了3-5倍。 二. 語言表達不夠簡練，豐富。別的且不說，就說程序的開始,C++ 用的是Begin.... end 格式，而且變量的聲明以及函數的格式都太死板一點不靈活，根本無法滿足我們多變的編程風格。反觀我的PlayC++用花括號：{}代表開始結束，變量可以隨用隨叫，多么簡潔。 三. 不支持面向過程編程。盡管目前是面向對象的天下，但是還是有很多場合要用面向過程的方法進行開發，例如最近非�；鸨�的CASE工具PlayCase就是一款優秀的過程工具。但是C++這一點做的太差，徹底拋棄了他們，采用了純面向對象的方式，據我深入研究，C++的任何類型都是類結構，這對于廣大的面向過程愛好者是及不公平的。不過不用擔心，現在PlayC++可以讓你為所欲為，它支持面向對象同樣也沒有忘記面向過程，這樣你就可以用面向對象的語言來開發面向過程的設計，你以前的方法都可以保留。 當然C++也不是一無是處，例如它的垃圾回收功能，數組的上下界自動檢測。但這些功能的實現是要付出代價的。 本文對C++攻擊頗多，實際上PlayC++從C++獲益匪淺，鄙人也是經過對C++非常深入的剖析，取長補短而建立了PlayC++，能有今天的成就理所應當向相關的面向對象大師們表示敬意。 

wildhorseli (2002-5-16 9:40:03) 

首先聲明，本人不會寫程序，本人用過高先生的東東（只是一個工具）；本人以為，UML只是一種符號，表達一種思想，正如高先生的東東一樣，只是為了大家方便，清晰；以OO為思想，目的是代碼的復用，可讀，效率，適應外界的變化（這是重點）；本人認為UML的表達確實不錯，本人不會寫代碼，但從用例上來看，清晰的很，業務清晰的很，一切看起來很自然，最起碼你能感覺到是面向對象；由此可見，UML不在UML，在OO的功底，但從另一方面UML完全適應OO并且很適應，PlayCase或其他，我覺得大家完全可以用word，當然高先生可以用wps（國產的），甚或用草紙一樣做出大家都能理解的UML； 

zergcom (2002-5-15 18:22:49) 

什么樣的人可以評論UML： 1。真正了解和熟悉UML的人，而不是仇視UML的人。 2。用UML真正做過應用的人，而不是紙上談兵的人。 3。能提出更好方案的人，而不是吹毛求疵的人。 4。不是井底之蛙的人。 

hamzsy (2002-5-15 16:44:57) 

高先生的PLAYCASE早就開始用了，除非不得已，用戶有要求，否則我是不會用UML的，可能是我沒有很好的理解UML的緣故。高先生的觀點我很容易接受，所以PLAYCASE也用的很順暢。 UML確實很好，由于其是面向對象的，在分析時整體把握還可以，遇到一些細節時就有點力不從心了，而往往這些細節是項目成敗的關鍵�！�—很少有軟件整體把握出錯的！高先生的話或許有些偏激，但您有沒有具體的思考過是不是真象他說的那樣“糟糕”。希望大家不要象許多老百姓那樣給人“害怕新事物”的感覺。也難怪，國產軟件在程序員中的地位確實比較低��！但PLAYCASE絕對是國產中的精品，雖然她還沒有長大！大家還是來多關心關心他吧，不要老是躺在別人的床上高枕無憂！ 

lwd2k (2002-5-15 13:20:56) 

原來作者是playcase的作者，在此表示敬意。我學習使用playcase，覺的簡單易用，生成代碼很好，所以一直有一個版本保存。但出于商業和拓展市場的需要，用戶要求的文檔應符合UML標準，其實Visio功能比Rose多，但由于介紹Rose的書多，所以就用了Rose. 對于分析工具來說，做為用戶，分析員，程序員之間的交流工具，只要說清楚了問題，不必看是用了什么方法。但目前來說，本人非常相信UML，所以一直想弄好它. 

mach (2002-5-15 13:06:43) 

使用UML可以清楚的描述業務流程，但不是用序列圖，而是活動圖，對于高先生的全程建模我還不太理解，粗淺的認為大概就是標準的RUP過程加上其中作為選項的業務建模吧。至于用活動圖描述業務流程，這是肯定可以的，而且很方便，用活動圖可以非常清楚地定義工作流，不僅可以在業務層次上抽象，包括在其后的系統分析、設計過程中，可以繼續細該活動圖得到業務過程的具體實現方式。從高先生文章中的論述，和其對用例圖、序列圖的使用方法來看，可以斷定，高先生對UML還不是太了解。至于Playcase，我只是下載過，不是很理解其中應用的方法論，因此沒有資格對其進行評價。 

jnwen (2002-5-15 11:28:07) 

我覺得關鍵是語言還沒有對信息流很好的支持,什么面向對象的建模方法都不好,面向過程的方法最自然. 

JohnYale (2002-5-15 10:40:32) 

平心而論，高先生的PlayCase是比較少見的優秀產品（至少在國內），肯定花費了高先生很大的心血，但不被市場認可，我們應該考慮這是什么原因？如果說國內公司不相信國內公司的產品尚可解釋的話，可是世界上那么多大公司，為什么鮮有發現PlayCase的？PlayCase使用的IDEF(具體拼法已記不清了)，在國內只發現一本書予以介紹，與連篇累牘的介紹UML的書籍形成巨大反差，難道真的是整個IT業都錯了？真理往往掌握在少數人手里？ 

HYhuyan (2002-5-15 9:30:13) 

眾人皆醒我獨醉 1.任何技術上的爭論我們都應該支持； 2.任何帶有利己目的的攻擊我們都應該鄙視。 

fltwt (2002-5-15 9:13:07) 

只是覺得原作者還沒有很好的理解UML。也沒有真正的用過UML。從這篇文章中，看得出作者很推崇結構化，看不出面向對象。 UML的核心應該是建立在面向對象上的吧。用UML進行面向過程的系統設計開發，好象牛頭不對馬嘴。 

mis98zb (2002-5-15 8:28:54) 

不過RUP幾大核心工作流之間的銜接、UML幾大視圖的演化，以及業務模型到實現模型的轉化，確實很少有講解的資料，這也使得現實中ROSE建模缺乏連貫性。 

JohnYale (2002-5-14 23:47:36) 

眾人皆醉我獨醒。高展先生為了推廣 全程建模方法，幾年來一直極力攻擊UML, 其執著比麥克尼利有過之而無不及，在如今建模方面尚無完美方案的情況下，全程建模方法 無疑是當今世上絕無僅有的、至高至上的、無可匹敵的解決方案，是中國軟件的代表，高展先生萬歲萬歲萬萬歲�。�！ 2年（？）前，鄙人初次接觸PlayCase, 就發現PlayCase有許多優點，但由于本人愚魯，未能成功說服公司采用PlayCase（老板是蠢材？），致使公司現在一直使用Rose建模（邊用邊摸索），真是罪該萬死。沒有辦法，市場決定一切。高展先生，您的PlayCase賣了幾套了？ 

//www.csdn.net/develop/Article/13/13680.shtm CSDN是技術交流與傳播的平臺，我們鼓勵技術的討論與爭論。 我們不會因為不同意別人的觀點而刪除任何文章，只會刪除人身攻擊和粗言穢語等有污視聽的帖子。 

ripper (2002-5-14 21:27:48) 

使用UML描述業務流程很難讓人放心，因為描述業務流程時產生的遺漏、不一致、不完整，同樣會給項目帶來災難。這是糾纏不清的胡子工程問題點之二 看看這句話，再看看下面對比用的圖，高展這老小子連順序圖是做什么的都沒有搞明白就信口開河 

討論文章見：UML 誰的硬傷 http://www.csdn.net/develop/Article/13/13680.shtm

 

延伸閱讀

文章來源于領測軟件測試網 http://www.kjueaiud.com/