UML參考手冊.doc

《UML參考手冊.doc》由會員分享，可在線閱讀，更多相關《UML參考手冊.doc（364頁珍藏版）》請在裝配圖網上搜索。

1、 UML參考手冊 目錄 譯者序 i 前言 iv 第一部分 背景知識 1 第 1 章 UML綜述 1 1.1 UML簡介 1 1.2 UML 的歷史 1 1.2.1 面向對象的開發(fā)方法 1 1.2.2 統一工作 2 1.2.3 標準化 3 1.2.4 核心組員 3 1.2.5 統一的意義 3 1.3 UML的目標 4 1.4 UML概念域 5 1.5 表達式和圖表語法 6 第 2 章 模型的性質與目標 7 2.1 什么是模型 7 2.2 模型的用途 7

2、2.3 模型的層次 8 2.4 模型內容 10 2.5 模型說明了什么？ 11 第二部分 基本概念 13 第 3 章 UML初覽 14 3.1 UML視圖 14 3.2 靜態(tài)視圖 15 3.3 用例視圖 16 3.4 交互視圖 17 3.4.1 順序圖 17 3.4.2 協作圖 18 3.5 狀態(tài)機視圖 19 3.6 活動視圖 20 3.7 物理視圖 21 3.8 模型管理視圖 24 3.9 擴展組件 25 3.10 各種視圖間的關系 26 第 4 章 靜態(tài)視圖 27 4.1 概述 27 4.2 類元 27 4.3 關系 29 4.4 關聯 30 4

3、.5 泛化 33 4.5.1 繼承 34 4.5.2 多重繼承 34 4.5.3 單分類和多重分類 35 4.5.4 靜態(tài)與動態(tài)類元 35 4.6 實現 36 4.7 依賴 37 4.8 約束 38 4.9 實例 39 4.10 對象圖 39 第 5 章 用例視圖 41 5.1 概述 41 5.2 參與者 41 5.3 用例 42 第 6 章 狀態(tài)機視圖 44 6.1 概述 44 6.2 狀態(tài)機 44 6.3 事件 44 6.4 狀態(tài) 46 6.5 轉換 47 6.6 組成狀態(tài) 50 第 7 章 活動視圖 55 7.1 概述 55 7.2 活動圖

4、55 7.3 活動和其他圖 57 第 8 章 交互視圖 58 8.1 概述 58 8.2 協作 58 8.3 交互 58 8.4 順序圖 59 8.5 激活 59 8.6 合作圖 60 8.7 模板 62 第 9 章 物理視圖 64 9.1 概述 64 9.2 構件 64 9.3 節(jié)點 65 第 10 章 模型管理視圖 66 10.1 概述 66 10.2 包 66 10.3 包間的依賴關系 66 10.4 訪問與引入依賴關系 67 10.5 模型和子系統 67 第 11 章 擴展機制 69 11.1 概述 69 11.2 約束 69 11.3 標

5、簽值 70 11.4 構造型 71 11.5 裁制UML 72 第 12 章 UML環(huán)境 73 12.1 概述 73 12.2 語義職責 73 12.3 表示法職責 74 12.4 程序語言職責 74 12.5 使用建模工具建模 75 12.5.1 工具問題 75 12.5.2 工作進展過程中產生的不一致模型 75 12.5.3 空值和未詳細說明的值 75 第三部分　 參考資料 77 第 13 章 術語大全 78 第 14 章 標準元素 334 第四部分 附錄 343 附錄 UML元模型 344 索引 347 譯者序 隨著計算機硬件性能的不斷提高和價格

6、的不斷下降，其應用領域也在不斷擴大。人們在越來越多的領域希望把更多、更難的問題交給計算機去解決。這使得計算機軟件的規(guī)模和復雜性與日俱增，從而使軟件技術不斷地受到新的挑戰(zhàn)。60年代軟件危機的出現就是因為系統的復雜性超出了人們在當時的技術條件下所能駕御的程度。此后在軟件領域，從學術界到工業(yè)界，人們一直在為尋求更先進的軟件方法與技術而奮斗。每當出現一種先進的方法與技術，都會使軟件危機得到一定程度的緩和。然而這種進步又立刻促使人們把更多、更復雜的問題交給計算機去解決。于是又需要更先進的方法與技術。 開發(fā)一個具有一定規(guī)模和復雜性的軟件系統和編寫一個簡單的程序大不一樣。其間的差別，借用G. Booch的

7、比喻，如同建造一座大廈和搭一個狗窩的差別。大型的、復雜的軟件系統的開發(fā)是一項工程，必須按工程學的方法組織軟件的生產與管理，必須經過分析、設計、實現、測試、維護等一系列的軟件生命周期階段。這是人們從軟件危機中獲得的最重要的教益。這一認識促使了軟件工程學的誕生。編程仍然是重要的，但是更具有決定意義的是系統建模。只有在分析和設計階段建立了良好的系統模型，才有可能保證工程的正確實施。正是由于這一原因，許多在編程領域首先出現的新方法和新技術，總是很快地被拓展到軟件生命周期的分析與設計階段。 面向對象方法正是經歷了這樣的發(fā)展過程，它首先在編程領域興起，作為一種嶄新的程序設計范型引起世人矚目。繼Small

8、talk-80之后，20世紀80年代又有一大批面向對象的編程語言問世，標志著面向對象方法走向成熟和實用。此時，面向對象方法開始向系統設計階段延伸，出現了如Booch86、GOOD（通用面向對象的開發(fā)）、HOOD（層次式面向對象的設計）、OOSD（面向對象的結構設計）等一批OOD（“面向對象的設計”或“面向對象的開發(fā)”的縮寫）方法。但是這些早期的OOD方法不是以面向對象的分析（OOA）為基礎的，而主要是基于結構化分析。到1989年之后，面向對象方法的研究重點開始轉向軟件生命周期的分析階段，并將OOA和OOD密切地聯系在一起，出現了一大批面向對象的分析與設計（OOA&D）方法，如Booch方法、

9、Coad/Yourdon方法、 Firesmith方法、Jacobson的OOSE、 Martin/Odell方法、 Rumbaugh等人的OMT、 Shlaer/Mellor方法等等。截至1994年，公開發(fā)表并具有一定影響的OOA & D方法已達50余種。這種繁榮的局面表明面向對象方法已經深入到分析與設計領域，并隨著面向對象的測試、集成與演化技術的出現而發(fā)展為一套貫穿整個軟件生命周期的方法體系。目前，大多數較先進的軟件開發(fā)組織已經從分析、設計到編程、測試階段全面地采用面向對象方法，使面向對象無可置疑地成為當前軟件領域的主流技術。 各種面向對象的分析與設計方法都為面向對象理論與技術的發(fā)展作出

10、了貢獻。這些方法各有自己的優(yōu)點和缺點，同時在各自不同范圍內擁有自己的用戶群。各種方法的主導思想以及所采用的主要概念與原則大體上是一致的，但是也存在不少差異。這些差異所帶來的問題是，不利于面向對象方法向一致的方向發(fā)展，也會給用戶的選擇帶來一些困惑。為此，Rational公司的G. Booch和J. Rumbaugh決定將他們各自的方法結合起來成為一種方法。1995年10月發(fā)布了第1個版本，稱作“統一方法”（Unified Method 0.8）。此時OOSE的作者I. Jacobson也加入了Rational公司，于是也加入了統一行動。1996年6月發(fā)布了第2個版本UML0.9。鑒于統一行動的產

11、物只是一種建模語言，而不是一種建模方法，（因為不包含過程指導），所以自0.9版起，改稱“統一建模語言”（Unified Modeling Language）。在此過程中，由Rationl公司發(fā)起成立了UML伙伴組織。開始時有12家公司加入，共同推出了UML1.0版，并于1997年1月提交到對象管理組織（OMG）申請作為一種標準建模語言。此后，又把其他幾家分頭向OMG提交建模語言提案的公司擴大到UML伙伴組織中，并為反映他們的意見而對UML進一步做了修改，產生了UML1.1版。該版本于1997年11月4日被OMG采納。此后UML還在繼續(xù)改進，目前最新的版本是UML1.3。 關于UML的歷史、發(fā)

12、起的動機、目標、權衡的問題等，這里不想做更多的介紹，因為讀者很快會從《UML用戶指南》的前言中看到更詳細的敘述。這里想著重指出的是以下三點：第一點是UML的三位發(fā)起人G. Booch、J. Rumbaugh和I. Jacobson是從事面向對象研究的著名專家，他們各自的方法和著作在該領域均具有很大的影響；第二點是眾多的大公司加入了UML陣營，為UML的制定和推廣提供了強有力的支持；第三點是UML經過數年的努力終于被OMG采納，成為該組織承認的一種標準建模語言。總之，UML是吸收多種方法的成果、凝結許多組織和個人智慧的產物。 UML是一種用于對軟件密集型系統進行可視化、詳述、構造和文檔化的建模

13、語言，主要適用于分析與設計階段的系統建模。UML最主要的特點是表達能力豐富。因為它從各種OOA&D方法中吸取了大量的概念，并在“UML語義”、“UML表示法指南”、“對象約束語言規(guī)約”等UML文獻中對這些概念的語義、圖形表示法和使用規(guī)則作了完整而詳細的定義?？梢哉f，UML對系統模型的表達能力超出了以往任何一種OOA&D方法。當然，隨之而來的問題是，它的復雜性也超出了以往任何一種方法。 UML的問世引起了計算機軟件界的廣泛重視，因為它代表了一種積極的方向—多種方法相互借鑒、相互融合、趨于一致、走向標準化。建模語言的標準化將為軟件開發(fā)商及其用戶帶來諸多便利。因此，在美國等國家已有大量的軟件開發(fā)組

14、織開始用UML進行系統建模。學習和使用UML已經成為一種潮流。我國軟件界對UML也相當關注。許多研究人員和技術人員已在數年前開始學習和研究UML。更有許多人想學習UML，但苦于找不到合適的書籍。由于UML的復雜性，僅通過UML的標準文獻來學習和使用它確實不是一件輕松的事。以往國內外也曾發(fā)表過一些介紹或評述UML的著作或論文，但是與UML的豐富內容相比，這些介紹遠不能滿足讀者的要求。 值得高興的是，UML的三位主要設計者G. Booch、J. Rumbaugh和I. Jacobson現在已親自撰寫了這套詳細闡述UML的著作，由Addison Wesley公司于1999年出版。這套著作對UML進

15、行了詳細、深入而準確的介紹和論述，而且語言生動、深入淺出、實例豐富、圖文并茂。這是一套教會讀者掌握和使用UML的教材和指導手冊，而不是枯燥的標準文獻。對于想學習和使用UML的廣大讀者，這是一套難得的好書。為了使中國的讀者能夠更好地從中受益，我們在機械工業(yè)出版社的懇切建議下，分頭翻譯了這三本書，即《UML用戶指南》、《UML參考手冊》和《統一軟件開發(fā)過程》。 三本原著都是由這三位作者合著，既各自獨立、又有很強的內在聯系。其中《UML用戶指南》介紹了UML的基礎知識，包括UML的術語、規(guī)則和語言特點，以及如何運用該語言去解決常見的建模問題，初學者學習UML最好從閱讀該書開始?！禪ML參考手冊》對

16、UML的組成和概念作了詳細的介紹，包括這些概念的語義、語法、表示法和用途，是一本適合軟件專業(yè)人員使用的方便而全面的參考讀物。《統一軟件開發(fā)過程》給出了一種以UML作為建模語言進行軟件開發(fā)的過程指導。其內容不是UML固有的組成部分，因為被OMG采納的UML只是一種建模語言，并不包含過程指導。實際上，UML是獨立于過程的，可以用于不同的軟件過程。但是該書介紹的軟件開發(fā)過程是三位作者在開發(fā)UML時一直在頭腦中思考的，因此很切合UML的特點。該書對于如何運用UML的概念進行軟件開發(fā)提供了詳細指導，適合軟件專業(yè)人員使用。 鑒于UML本身以及這套著作的重要意義，譯者在翻譯這些著作時采取了特別慎重和嚴謹的

17、態(tài)度，力求準確和通順。在翻譯過程中，一個重要問題是要使這套書中的專業(yè)術語的中文譯法保持一致。這三本書的譯者以往曾分別開展過一些與UML有關的研究和寫作，對有些術語的譯法互有差異。本次翻譯工作中，所有譯者在機械工業(yè)出版社的組織下進行了多次討論、研究和交流，首先對所有專業(yè)術語的譯法統一意見，達成共識。其中某些術語的譯法頗難定奪：既要確切反映英文本意，又要符合中文習慣，還要避免與國內已習慣于與其它英文詞對應的中文相混淆。經過反復切磋，大部分問題都得到滿意的解決。對個別有爭議的問題，在充分討論的基礎上采取放棄己見、服從大局的態(tài)度，從而形成了一個譯法一致的詞匯表。此后在翻譯過程中還經常以各種交流方式進行

18、磋商和勾通。最終使這套叢書能以一致的面貌呈獻給讀者。我們也希望這些工作能為UML術語今后在中文翻譯中的統一貢獻一份力量。 在科技著作的翻譯中，保證準確和通順的關鍵因素不僅僅是外文水平，還取決于譯者真正了解所涉及的技術內容。這套著作的內容遠遠超出了UML的標準文獻，因為除了介紹UML的語法、語義、使用規(guī)則之外，其中還包含許多學術思想、技術策略和實踐經驗。在翻譯中遇到的許多疑難問題，我們是通過進一步研究UML以及有關的學術和技術問題而得到解決的，從而避免了許多訛誤。因此，這套著作的翻譯不僅是文字方面的工作，還包含譯者在技術上的研究。我們希望這些研究最終通過較準確的翻譯文字使讀者受益。同時誠懇地希

19、望廣大讀者對可能存在的疏漏和錯誤之處給予批評和指正。 譯 者 2000年10月于北京 前言 目標 本書是關于統一建模語言（UML, Unified Modeling Language）的一本全面實用的參考書,可供軟件開發(fā)人員，設計人員，項目管理員，系統工程師，程序設計人員，分析員，用戶以及研究、設計、開發(fā)和理解復雜軟件系統的技術人員參考。書中對UML的組成和概念做了詳細介紹，包括其語義、語法、表示法和用途。對廣大專業(yè)軟件開發(fā)人員來說，這是一本使用方便、內容全面的參考讀物。此外，本書還討論了有關標準文獻沒有解釋清楚的細節(jié)問題和UML標準中一些結論的基本原理。 本書不是一本關于UM

20、L語言標準文獻和UML元模型內部細節(jié)的指導手冊。對元模型的細節(jié)感興趣的是UML工具的開發(fā)者和研究開發(fā)方法的專家，一般的軟件開發(fā)人員無需了解對象管理組織（OMG, Object Management Group）制定的這些不易為人了解的細節(jié)。本書涵蓋了能夠滿足絕大部分軟件開發(fā)人員需要的細節(jié)內容，對于某些源于原始標準的細節(jié)，往往指明了其出處。 本書所附光盤收錄了一些原始標準文獻，供讀者參考。 在閱讀本書之前，讀者應具備有關面向對象技術的基本知識。為方便初學者，書后的參考文獻中列出了我們和其他作者早期的原作。雖然這些書中采用的某些表示法現在已有了變化，但是一些書中介紹的面向對象的概念仍然有用，如[

21、Rumbaugh-91]、[Booch-94]、[Jacobson-92]和[Meyer-88]等書，所以這里沒有必要重新討論這些基本概念。如果某些讀者要個別學習如何用UML對一般問題建立模型，可參考《UML 用戶指南》（即將由機械工業(yè)出版社出版）一書。那些已經了解如OMT、Booch、Objectory、Coad-Yourdon、Fusion等面向對象方法的讀者，完全能夠讀懂本書，并能夠掌握UML及其表示法和語義。若要快速學習UML，閱讀《UML 用戶指南》很有幫助。 使用UML并不局限于某一種專門的開發(fā)過程，本書也不針對某一種開發(fā)過程進行討論和介紹。盡管UML可用于許多開發(fā)過程，但它最適

22、用于以一個健壯的構架為中心的迭代的、增量的、用例驅動的開發(fā)過程—我們認為這是開發(fā)現代復雜軟件最適宜的開發(fā)過程。《統一軟件開發(fā)過程》（即將由機械工業(yè)出版社出版）[Jacobson-99]就描述了這樣一種開發(fā)過程，我們認為這是對UML的補充和對軟件開發(fā)的最好支持。 本書概貌 本書分為三部分：對UML歷史和有關建模知識的概述；UML基本概念的綜述；UML術語和概念大全。 第一部分是UML綜述—UML的歷史、目標及使用—幫助理解UML的來源和它能滿足的需求。 第二部分是UML視圖的簡要概述，以便讀者能將概念與視圖聯系起來。該部分綜述了UML所支持的各種視圖，并說明各種構件如何協同工作。該部分首

23、先介紹了一個用到了各種UML視圖的例子，接著分章介紹每一種視圖。概述的目的不是提供一個完整的教材或對各種概念進行全面敘述，而主要是總結性地闡述UML 的各種概念，它是進一步詳細閱讀本書中術語和概念大全的起點。 第三部分包括了各種參考信息，這些信息被組織成一個個相關主題以便于查找。本書的主體是一個按字母順序排列的所有UML概念和組件的大全。所有UML術語，不論重要與否，在大全中都有對應條目，大全盡可能提供全面信息。因此，凡是第二部分提到的概念，在大全中都有更詳細的進一步闡述。相同或相似的信息有時在大全中的許多條目中都予以列出，以便讀者查閱。 參考信息部分還包括了一個按字母順序排列的UML標準

24、元素列表。標準元素是使用UML擴充機制預定義的一個特性。標準元素是UML的擴展部分，相信應該能得到廣泛使用。 附錄列出了UML的元模型、UML表示法小結和用于專門領域的標準擴展集。附錄還給出了一個有關面向對象知識的主要的參考文獻，但不包含UML或其他方法的來源。參考文獻中所列的許多文獻都提及了一些優(yōu)秀的書籍和雜志文章，有興趣的讀者可據此進一步研究這些方法和概念的形成和發(fā)展。 大全部分的格式約定 本書的大全部分是一個按字母表順序組織的條目表，每一條目都較為詳細地描述了一個概念。條目下所有的解釋性短文按照概念的不同層次組織。高層次概念通常包括其低層次概念的概括性說明，每一低層概念在一段單獨的

25、短文中有詳細解釋。各個短文中所闡述的概念彼此之間有復雜的相互參考關系。大全的這種組織形式使得每個概念在一致的層次中，避免了嵌套性的解釋說明來回查找?guī)淼穆闊?。高度格式化的編排也有利于相關概念的引用。閱讀本書時，不必根據索引查找書中內容，而可以直接到大全正文中查找有關概念和術語。但這種編排格式不適于學習UML語言。建議初學者首先閱讀本書第二部分或其他UML的介紹性讀物，如《UML 用戶指南》。 大全條目包含以下部分，但并不是所有條目都包含所有部分。 簡要定義 概念名用黑體表示，緊接在概念名之后的簡要定義用一般字體印刷。概念的定義力求抓住該概念的主旨，以簡潔的表達方式描述，因此，

26、它只是一個簡要定義。概念的精確涵義參考后面的主體解釋短文。 語義 該部分詳細解釋概念的含義，包括該概念使用和執(zhí)行順序上的約束。盡管某些例子要用到表示法，但該部分不包括表示法。首先給出概念的概括語義。對于具有從屬結構特性的概念，在概括性語義說明后面的“結構”子標題下有一系列特性名。在大多數情況下，特性按特性名的字母表順序排列。如果某一特性還有更多的選擇項，那么每一選擇項均縮排。在更復雜的情況下，特性專門用一段短文敘述，以避免嵌套過多引起混亂。有時，對一個主要概念的說明分散在多個邏輯子項中而不是在一處。此時，附加說明段接在“結構”小節(jié)之后或替代了“結構”小節(jié)。盡管在結構編排上采取了多種

27、方式，但該結構對讀者來說仍然很清晰。 表示法 本節(jié)對概念的表示法進行詳細的描述。通常，表示法段與其參考的語義描述段平行，并且通常與語義描述段有相同的劃分。表示法段一般都有一個或多個圖表，用來說明有關概念。為了幫助讀者更好地理解表示法，許多圖表中用楷體表示注釋說明。所有用楷體表示的都是注釋說明，不是實際表示法的一部分。 示例 本小節(jié)展示如何使用表示法以及有關概念的運用。這些例子一般都針對復雜的或容易產生混淆的情形來列舉。 討論 本節(jié)討論難以理解和把握的問題，澄清疑惑和容易混淆的要點，并且包括一些其他方面的細節(jié)問題，這些細節(jié)問題有可能分散讀者對語義說明段的注意力

28、。只有一小部分的條目有討論段。 本節(jié)還解釋了在UML的開發(fā)過程中產生的設計結論，特別是有違直覺和容易引起激烈爭論的設計結論。 只有一小部分條目有這一節(jié)。討論一般不涉及風格上的簡單不同點。 標準元素 本節(jié)列出了標準約束、標記、構造型和其他約定，這些是預先規(guī)定好的。這一節(jié)很少出現。 語法約定 語法表達式。語法表達式是用Sans Serif 字體印刷的經過修改的BNF范式。 標點符號也出現在目標字符串中。 文中的斜體表示能夠被目標字符串中另一個字串或另一語法產生式替換的變量，可以包含字符和連字符。 在代碼示例中，注釋用楷體印刷在代碼右側。 下標

29、或上劃線為語法操作，舉例如下： expression opt 這個表達式是任選的。 expression list, 用逗號來分隔一系列表達式。如果出現了零個或者一個重復符號，則不需要分隔符。每個重復符號都要用一個單獨的替換符號。如果一個除逗號之外的標點符號出現在下標中，則它是分隔符。 =expression opt 用上劃線來連接兩個或多個屬于同一單元的可選的或重復出現的項目。在這個例子中，等號和表達式構成一個可以使用或省略的單元。如果只有一個項目，可以不用上劃線。 不允許出現兩重嵌套。 字符串。在連續(xù)的文本中，關鍵字、模型元素名稱和模型中的字符串例用 Sans

30、Serif字體印刷。 圖表。在圖表中，楷體和箭頭是注釋，即，對圖中表示法的解釋不出現在實際圖表中。其他所有文字和符號都是實際的圖形表示法。 CD光盤 本書所附光盤以Adobe Reader(PDF)文件格式收錄了本書全文，讀者可以很容易地查到一個字或短語。本書CD 還包括一個可用鼠標點擊操作的目錄表，表中包括書中文章的目錄、索引、Adobe Reader的一小部分以及各個條目主體部分的可擴展熱鏈接。用鼠標簡單地點擊某一熱鏈接，即可跳到大全中對應該字或短語條目的章節(jié)中去。 這張CD還收錄了OMG的有關UML標準詳細說明的全文，這是經過OMG授權認可的。 我們認為這張CD對U

31、ML高級用戶來說，將是一本非常有用的在線參考書。 如何獲取更多信息 有關UML的另外一些原始文件和最新信息及相關方面的主題可在萬維網上查找。網址為：和。 致謝 我們感謝所有使UML成為現實的人。首先，我們必須感謝Rational軟件公司，特別是Mike Devlin 和 Paul levy，正是他們頗具慧眼地將我們組織在一起，并發(fā)起面向對象建模語言的統一工作，歷經四年的努力直至這項工作勝利完成。我們還得感謝OMG匯集了各方面的不同的觀點，并使這些觀點統一成被普遍接受的一致觀點，這遠非個人的力量所能夠做到的。 我們尤其要感謝Cris Kobryn，他既是制定UML標準的

32、技術小組的負責人，并且使眾位各執(zhí)己見的組員達成一致（當然我們三個人達成一致不會有太大的問題）。他的交際才能和技術上的斡旋能力使制定UML的努力沒有因各種不同觀點的影響而白費。Cris 還復審了全書，給出了大量有益的建議。 我們要對Gunnar 卾ergaard 表示感謝，感謝他對本書做了詳細的復審，以及他為完成大量UML文獻所做的辛勤勞動。這些文獻不適于寫入本書，但具有正確和有益的參考價值。 我們還要感謝Karin Palmkvist 對本書做了極為細致的校審，并指出了許多技術上的錯誤以及語法、措辭和表達方式上的缺陷。 我們還要感謝 Mike Blaha、Conrad Bock、Pe

33、rry Cole、Bruce Douglass、Martin Fowler、Eran Gery、Pete Mcbreen、Guus Ramackers、Tom Schultz、Ed seidewitz 和Bran Selic ，感謝他們對本書做了復審。 尤其重要的是，我們要對所有對UML思想作出貢獻的人表示感謝。他們提出了許多有益的見解和想法，這些想法涉及面向對象技術、軟件方法、程序設計語言、用戶界面、可視化編程和許許多多計算機方面的其他領域。在此我們不可能一一列舉他們的名字，不經過學術上的討論也難以理解他們的見解所具有的影響，并且本書是一本工程方面的書，并不是歷史傳記。這些見解有的廣為人知

34、，有的卻因為提出這些見解的人運氣不佳而不被人了解。 要是在一個更私人的場合，我希望能夠表達對Jack Dennis教授的感謝。早在25年前，他就對我和我的學生在建模方面的工作進行鼓勵。他所在的MIT的 計算結構組（Computations Structures Group）所提出的見解已產生了豐碩的成果，這些見解對UML的影響也是不小的。我還必須感謝Mary Loomis和Ashwin Shah，我和他們一起萌發(fā)了OMT的思想，還有我在GE 公司研發(fā)中心的同事Mike Blaha、Bill Premerlani、Fred Eddy和 Bill Lorensen，我和他們一起撰寫了OMT的書籍

35、。 最后要說的是，沒有我的妻子 Madeline 及兩個兒子Nick 和 Alex 的耐心支持，就沒有UML和這本書。 James Rumbaugh 于加州 Cupertino 1998年11月 第一部分 背景知識 這一部分介紹了UML的基本原理，包括UML建模的性質和目標以及UML覆蓋的所有功能領域。 第 1 章 UML綜述 本章是UML及其應用的一個快速瀏覽。 1.1 UML簡介 統一建模語言（UML）是一個通用的可視化建模語言，用于對軟件進行描述、可視化處理、構造和建立軟件系統制品的文檔。它記錄了對必須構造的系統的決定和理解，可用于對系統的理解、設計、瀏

36、覽、配置、維護和信息控制。UML適用于各種軟件開發(fā)方法、軟件生命周期的各個階段、各種應用領域以及各種開發(fā)工具，UML 是一種總結了以往建模技術的經驗并吸收當今優(yōu)秀成果的標準建模方法。UML包括概念的語義，表示法和說明，提供了靜態(tài)、動態(tài)、系統環(huán)境及組織結構的模型。它可被交互的可視化建模工具所支持，這些工具提供了代碼生成器和報表生成器。UML標準并沒有定義一種標準的開發(fā)過程，但它適用于迭代式的開發(fā)過程。它是為支持大部分現存的面向對象開發(fā)過程而設計的。 UML描述了一個系統的靜態(tài)結構和動態(tài)行為。UML將系統描述為一些離散的相互作用的對象并最終為外部用戶提供一定的功能的模型結構。靜態(tài)結構定義了系統中

37、的重要對象的屬性和操作以及這些對象之間的相互關系。動態(tài)行為定義了對象的時間特性和對象為完成目標而相互進行通信的機制。從不同但相互聯系的角度對系統建立的模型可用　于不同的目的。 UML還包括可將模型分解成包的結構組件，以便于軟件小組將大的系統分解成易于處理的塊結構，并理解和控制各個包之間的依賴關系，在復雜的開發(fā)環(huán)境中管理模型單元。它還包括用于顯示系統實現和組織運行的組件。 UML不是一門程序設計語言。但可以使用代碼生成器工具將UML模型轉換為多種程序設計語言代碼，或使用反向生成器工具將程序源代碼轉換為UML。UML不是一種可用于定理證明的高度形式化的語言，這樣的語言有很多種，但它們通用性較差

38、，不易理解和使用。UML是一種通用建模語言。對于一些專門領域，例如用戶圖形界面（GUI）設計、超大規(guī)模集成電路（VLSI）設計、基于規(guī)則的人工智能領域，使用專門的語言和工具可能會更適合些。UML是一種離散的建模語言，不適合對諸如工程和物理學領域中的連續(xù)系統建模。它是一個綜合的通用建模語言，適合對諸如由計算機軟件、固件或數字邏輯構成的離散系統建模。 1.2 UML 的歷史 UML是為了簡化和強化現有的大量面向對象開發(fā)方法這一目的而開發(fā)的。 1.2.1 面向對象的開發(fā)方法 利用傳統程序設計語言（如Cobol和 Fortran語言）的軟件開發(fā)方法出現于20世紀70年代，在80年代被廣泛采

39、用，其中最重要的是結構化分析和結構化設計方法[Yourdon-79]和它的變體，如實時結構化設計方法[Ward-85]等。這些方法最初由Constantine、Demarco、Mellor、Ward、Yourdon和其他一些人發(fā)明和推廣，在一些大型系統，特別是和政府簽約的航空和國防領域的系統中取得了一定突破，在這些系統中，主持項目的政府官員強調開發(fā)過程的有組織性和開發(fā)設計文檔的完備和充分。結果不總是像預料的那么好—許多計算機輔助軟件工程系統（CASE）只是摘錄一些已實現的系統設計的報表生成器—盡管如此，這些方法中仍包含一些好的思想，有時在一些大系統中是很有效的。商業(yè)應用軟件更不愿采用大型的CA

40、SE系統和開發(fā)方法。大部分商業(yè)企業(yè)都獨立開發(fā)本企業(yè)內部使用的軟件，客戶和締約人之間沒有對立關系，而這種關系正是大型政府工程的特征。一般都認為商用系統比較簡單，不論這種看法是否正確，反正它不需要經過外界組織的檢查。 普遍認為，誕生于1967年的Simula-67是第一個面向對象的語言。盡管這個語言對后來的許多面向對象語言的設計產生了很大的影響，但是它沒有后繼版本。80年代初Smalltalk，語言的廣泛使用掀起了一場“面向對象運動”，隨之誕生了面向對象的C、C++、Eiffel和CLOS等語言。起初，盡管面向對象編程語言在實際使用中有一定的局限性，但它仍然吸引了廣泛的注意力。在smalltal

41、k語言成名約5 年后，第一批介紹面向對象軟件開發(fā)方法的書籍出現了。包括Shlaer/Mellor [Shlaer-88]和Coad/Yourdon [Coad-91]，緊接著又有Booch的[Booch-91]、Rumbaugh/Blaha/Premerlani/Eddy/Lorensen的[Rumbaugh-91]和Wirfs-Brock/Wilkerson/Wiener [Wirfs-Brock-90]（注意：圖書年代往往包括了上一年度7月份以后出版的書）。這些著作再加上　　　Goldberg/Robson[Goldberg-83] Cox[Cox-86]和Meyer[Meyer-88]

42、等有關程序語言設計的著作，開創(chuàng)了面向對象方法的先河。第一階段在1990年末完成。稍晚[Jacobson-92]出版了，它建立在以前的成果的基礎上，介紹了一種稍微不同的方法，即以用例和開發(fā)過程為中心。 在以后的5年中，大批關于面向對象方法的書籍問世，各有自己的一套概念、定義、表示法、術語和適用的開發(fā)過程。有些書提出了一些新概念，但總的來說各個作者所使用的概念大同小異。許多后繼出版的書都照搬前人，自己再做一些小的擴充或修改。最早的著作者也沒閑著，他們大部分人都更新了自己前期的著作，采納了其他人一些好的思想。總之，出現了一些被廣泛使用的核心概念，另外還有一大批被個別人采納的概念。即使在被廣泛接受的

43、核心概念里，在各個面向對象方法中也有一些小的差異。這些面向對象方法之間的細微比較常使人覺得這些概念不知依據哪個為好，特別是非專業(yè)的讀者。 1.2.2 統一工作 在UML之前，已經有一些試圖將各種方法中使用的概念進行統一的初期嘗試，比較有名的一次是Coleman和他的同事們[Coleman-94]對OMT[Rumbaugh-91]、Booch[Booch-91]、CRC[Wirfs-Brock-90]方法使用的概念進行融合。由于這項工作沒有這些方法的原作者參與，實際上僅僅形成了一種新方法，而不能替換現存的各種方法。第一次成功合并和替換現存的各種方法的嘗試始于1994 年在Rational

44、軟件公司Rumbaugh與 Booch合作。他們開始合并OMT和Booch 方法中使用的概念，于1995年提出了第一個建議。此時，Jacobson 也加入了Rational公司開始與Rumbaugh和Booch一同工作。他們共同致力于設計統一建模語言。三位最優(yōu)秀的面向對象方法學的創(chuàng)始人共同合作，為這項工作注入了強大的動力，打破了面向對象軟件開發(fā)領域內原有的平衡。而在此之前，各種方法的擁護者覺得沒有必要放棄自己已經采用的概念而接受這種統一的思想。 1996年，OMG發(fā)布了征集向外界關于面向對象建模標準方法的消息。UML的三位創(chuàng)始人開始與來自其他公司的軟件工程方法專家和開發(fā)人員一道制訂一套使OM

45、G感興趣的方法，并設計一種能被軟件開發(fā)工具提供者、軟件開發(fā)方法學家和開發(fā)人員這些最終用戶所接受的建模語言。與此同時，其他一些人也在做這項富有競爭性的工作。1997年9月，所有建議終于被合并成一套UML方法提交到OMG。 最后的成果是許多人共同努力的結果。我們發(fā)起了創(chuàng)建UML的工作并提出了一些有益的建議，但是這些建議的最終成型是集體智慧的結晶。 1.2.3 標準化 1997年11月，UML被OMG全體成員一致通過，并被采納為標準。OMG承擔了進一步完善UML標準的工作。在UML標準通過前，就已經有許多概括UML精華的書出版發(fā)行。許多軟件開發(fā)工具供應商聲稱他們的產品支持或計劃支持UML，若干

46、軟件工程方法學家宣布他們將使用UML的表示法進行以后的研究工作。UML的出現似乎深受計算機界歡迎，因為它是由官方出面集中了許多專家的經驗而形成的，減少了各種軟件開發(fā)工具之間無謂的分歧。我們希望建模語言的標準化既能促進軟件開發(fā)人員廣泛使用面向對象建模技術，同時也能帶來UML支持工具和培訓市場的繁榮，因為不論是用戶還是供應商都不用再考慮到底應該采用哪一種開發(fā)方法。 1.2.4 核心組員 提出UML建議或進行UML標準修訂工作的核心組員有下列人員： 數據存取公司：Tom Digre DHR 技術公司：Ed Seidewitz HP 公司：Martin Griss IBM 公司：Stev

47、e Brodsky, Steve Cook, Jos Warmer I—Lgix 公司：Eran Gery, David Harel ICON Computing 公司：Desmond DSouza IntelliCorp and James Martin 公司：Conrad Bock, James Odell MCI 系統企業(yè)：Cris Kobryn, Joaquin Miller ObjecTime 公司：John Hogg, Bran Selic Oracle 公司：Guus Ramackers 鉑技術公司：Dilhar Desilva Rational 軟件公司：

48、Grady Booch, Ed Eykholt, Ivar Jacobson, Gunnar Overgaard, Karin Palmkvist, James Rumbaugh SAP 公司：Oliver Wiegert SOFTEAM：Philippe Desfray Sterling 軟件公司：John Cheesman, Keith Short Taskon 公司：Trygve Reenskaug 1.2.5 統一的意義 “統一”這個詞在UML中有下列一些相互關聯的含義： 在以往出現的方法和表示法方面。UML合并了許多面向對象方法中被普遍接受的概念，對每一種概念，UM

49、L都給出了清晰的定義、表示法和有關術語。使用UML可以對已有的用各種方法建立的模型進行描述，并比原來的方法描述得更好。 在軟件開發(fā)的生命期方面。UML對于開發(fā)的要求具有無縫性。開發(fā)過程的不同階段可以采用相同的一套概念和表示法，在同一個模型中它們可以混合使用。在開發(fā)的不同階段，不必轉換概念和表示。這種無縫性對迭代式的、增量式軟件開發(fā)是至關重要的。 在應用領域方面。UML適用于各種應用領域的建模，包括大型的、復雜的、實時的、分布式的、集中式數據或計算的、嵌入式的系統。也許用某種專用語言來描述一些專門領域更有用，但在大部分應用領域中，UML 不但不比其他的通用語言遜色并且更好。 在實現的編程語

50、言和開發(fā)平臺方面。 UML可應用于運行各種不同的編程實現語言和開發(fā)平臺的系統。其中包括程序設計語言、數據庫、4GL、組織文檔及固件等。在各種情況下，前部分工作應當相同或相似，后部分工作因各種開發(fā)媒介的不同而有某種程度上的不同。 在開發(fā)全過程方面。UML是一個建模型語言，不是對開發(fā)過程的細節(jié)進行描述的工具。就像通用程序設計語言可以用于許多風格的程序設計一樣，UML適用于大部分現有的或新出現的開發(fā)過程。尤其適用于我們所推薦的迭代式增量開發(fā)過程。 在內部概念方面。在構建UML元模型的過程中，我們特別注意揭示和表達各種概念之間的內在聯系并試圖用多種適用于已知和未知情況的辦法去把握建模中的概念。這個

51、過程會增強對概念及其適用性的理解。這不是統一各種標準的初衷，但卻是統一各種標準最重要的結果之一。 1.3 UML的目標 UML語言的開發(fā)有多個目標。首先，最重要的目標是使UML一個通用的建模語言，可供所有建模者使用。它并非某人專有，且建立在計算機界普遍認同的基礎上，即它包括了各種主要的方法并可作為它們的建模語言。至少，我們希望它能夠替代OMT，Booch，Objectory方法以及參與UML建議制訂的其他人所使用的方法建立的模型。其次，我們希望 UML 采用源自OMT Booch, Objectory及其他主要方法的表示法，即盡可能地它能夠很好地支持設計工作，像封裝、分塊、記錄模型構造思

52、路。此外，我們希望UML 準確表達當前軟件開發(fā)中的熱點問題，比如大規(guī)模、分布、并發(fā)、方式和團體開發(fā)等。 UML并不試圖成為一個完整的開發(fā)方法。它不包括一步一步的開發(fā)過程。我們認為一個好的軟件開發(fā)過程對成功的開發(fā)軟件是至關重要的，我們向讀者推薦一本書[Jacobson-99]。UML和使用UML的軟件開發(fā)過程是兩回事，這一些很重要。我們希望UML可以支持所有的，至少是目前現有的大部分軟件開發(fā)過程。UML包含了所有的概念，我們認為這些概念對于支持基于一個健壯的構架來解決用例驅動的需求的迭代式開發(fā)過程是必要的。 UML的最終目標是在盡可能簡單的同時能夠對實際需要建立的系統的各個方面建模。UML需

53、要有足夠的表達能力以便可以處理現代軟件系統中出現的所有概念，例如并發(fā)和分布，以及軟件工程中使用的技巧，如封裝和組件。它必須是一個通用語言，像任何一種通用程序設計語言一樣。然而，這樣就意味著UML必將十分龐大，不可能像描述一個近乎于玩具一樣的軟件系統那樣簡單?，F代語言和操作系統比起40年前要復雜多，因為我們對它們的要求越來越多。UML提供了多種模型，不是在一天之內就能夠掌握的。它比先前的建模語言更復雜，因為它更全面。但是你不必一下就完全學會它，就像學習任何一種程序設計語言、操作系統或是復雜的應用軟件一樣。 1.4 UML概念域 UML的概念和模型可以分成以下幾個概念域。 靜態(tài)結構。任何

54、一個精確的模型必須首先定義所涉及的范圍，即確定有關應用、內部特性及其相互關系的關鍵概念。UML的靜態(tài)組件稱為靜態(tài)視圖。靜態(tài)視圖用類構造模型來表達應用，每個類由一組包含信息和實現行為的離散對象組成。對象包含的信息被作為屬性，它們執(zhí)行的行為被作為操作。多個類通過泛化處理可以具有一些共同的結構。子類在繼承它們共同的父類的結構和行為的基礎上增加了新的結構和行為。對象與其他對象之間也具有運行時間連接，這種對象與對象之間的關系被稱為類間的關聯。一些元素通過依賴關系組織在一起，這些依賴關系包括在抽象級上進行模型轉換、模板參數的捆綁、授予許可以及通過一種元素使用另一種元素等。另一類關系包括用例和數據流的合并。

55、靜態(tài)視圖主要使用類圖。靜態(tài)視圖可用于生成程序中用到的大多數數據結構聲明。在UML視圖中還要用到其他類型的元素，比如接口、數據類型、用例和信號等，這些元素統稱為類元，它們的行為很像在每種類元上具有一定限制的類。 動態(tài)行為。有兩種方式對行為建模。一種是根據一個對象與外界發(fā)生關系的生命歷史；另一種是一系列相關對象之間當它們相互作用實現行為時的通信方式。孤立對象的視圖是狀態(tài)機—當對象基于當前狀態(tài)對事件產生反應，執(zhí)行作為反應的一部分的動作，并從一種狀態(tài)轉換到另一種狀態(tài)時的視圖。狀態(tài)機模型用狀態(tài)圖來描述。 相互作用對象的系統視圖是一種協作，一種與語境有關的對象視圖和相互之間的鏈，通過數據鏈對象間存在著

56、消息流。視圖點將數據結構、控制流和數據流在一個視圖中統一起來。協作和互操作用順序圖和協作圖來描述。對所有行為視圖起指導作用的是一組用例，每一個用例描述了一個用例參與者或系統外部用戶可見的一個功能。 實現構造。UML模型既可用于邏輯分析又可用于物理實現。某些組件代表了實現。構件是系統中物理上的可替換的部分，它按照一組接口來設計并實現。它可以方便地被一個具有同樣規(guī)格說明的構件替換。節(jié)點是運行時間計算資源，資源定義了一個位置。它包括構件和對象。部署圖描述了在一個實際運行的系統中節(jié)點上的資源配置和構件的排列以及構件包括的對象，并包括節(jié)點間內容的可能遷移。 模型組織。計算機能夠處理大型的單調的模型，

57、但人力不行。對于一個大型系統，建模信息必須被劃分成連貫的部分，以便工作小組能夠同時工作在不同部分上。即使是一個小系統，人的理解能力也要求將整個模型的內容組織成一個個適當大小的包。包是UML模型通用的層次組織單元，它們可以用于存儲、訪問控制、置以管理配及構造包含可重用的模型單元庫。包之間的依賴關系是對包的組成部分之間的依賴關系的歸納。系統整個構架可以在包之間施加依賴關系。因此，包的內容必須符合包的依賴關系和有關的構架要求。 擴展機制。無論一種語言能夠提供多么完善的機制，人們總是想擴展它的功能。我們已使UML具有一定的擴展能力，相信能夠滿足大多數對UML擴充的需求而不改變語言的基礎部分。構造型是

58、一種新的模型元素，與現有的模型元素具有相同的結構，但是加上了一些附加限制，具有新的解釋和圖標。代碼生成器和其他的工具對它的處理過程也發(fā)生了變化。標記值是一對任意的標記值字符串，能夠被連接到任何一種模型元素上并代表任何信息，如項目管理信息、代碼生成指示信息和構造型所需要的值。標記和值用字符串代表。約束是用某種特定語言（如程序設計語言）的文本字符串表達的條件專用語言或自然語言。UML提供了一個表達約束的語言，名為OCL。與所有其他擴展機制一樣，必須小心使用這些擴展機制，因為有可能形成一些別人無法理解的方言。但這些機制可以避免語言基礎發(fā)生根本性變化。 1.5 表達式和圖表語法 本書列舉了許多演

59、示實際模型的表達式和圖表，以及表達式的語法和圖表的注釋。為了盡量避免將解釋說明和實例弄混，本書采用了一些約定的格式。 在圖表和文本表達式中實際的表示法部分用Comic Sans字體印刷。例如，模型中出現的Helvetica字體的類名是一個合法的名稱。語法表達式中的括弧是一個可能出現在實際表達式中的括弧，它不是實際語法機構的一部分。例如：e(customer,amount) 在連續(xù)的文中，關鍵詞和模型元素名都用Comic Sans字體印刷，如：Order或Customer。 在一個語法表達式子中，句法單元名可以被實際的一段文字用藍色Comic Sans字體替代，如：name。表達式中的黑色

60、正文表示出現在目標圖示上字面上的值。斜體或下劃線說明替換文本具有給定的性質。例如： tion(argument,...) object-name:class 在語法表達式中，下標和上劃線用于指示某種語法性質。例如： expressionopt 這個表達式是任選的。 expressionlist, 用逗號來分隔一系列表達式。如果出現了零個或者一個重復符號，則不需要分隔符。每個重復符號都要用一個單獨的替換符號。如果一個除逗號之外的標點符號出現在下標中，則它是分隔符。 用上劃線來連接兩個或多個屬于同一單元的可選的或重復出現的項目。在這個例子中，等號和表達式構成一個可以使用或省略的單元

61、。如果只有一個項目，可以不用上劃線。 在圖表中，中文楷體、藍色的文字與箭頭是注釋，它們是解釋性說明而不是實際表示法的一部分。其他文字和符號是實際表示法的一部分。 第 2 章 模型的性質與目標 本章將解釋什么是模型，模型有何用途以及如何使用模型。本章還要解釋模型的不同層次：理想的，部分的和基于工具的。 2.1 什么是模型 模型是用某種工具對同類或其他工具的表達方式。模型從某一個建模觀點出發(fā)，抓住事物最重要的方面而簡化或忽略其他方面。工程、建筑和其他許多需要具有創(chuàng)造性的領域中都使用模型。 表達模型的工具要求便于使用。建筑模型可以是圖紙上所繪的建筑圖，也可以是用厚紙板制作的三維模

62、型，還可以用存于計算機中的有限元方程來表示。一個建筑物的結構模型不僅能夠展示這個建筑物的外觀，還可以用它來進行工程設計和成本核算。 軟件系統的模型用建模語言來表達，如UML。模型包含語義信息和表示法，可以采取圖形和文字等多種不同形式。建立模型的目的是因為在某些用途中模型使用起來比操縱實物更容易和方便。 2.2 模型的用途 模型有多種用途 捕獲精確和表達項目的需求和應用領域中的知識，以使各方面的利益相關者能夠理解并達成一致。建筑物的各種模型能夠準確表達出這個建筑物在外觀、交通、服務設施、抗風和抗震性能，消費及其他需求。各方面的利益相關者則包括建筑設計師、建筑工程師、合同締約人、各個子項

63、目的締約人、業(yè)主、出租者和市政當局。 軟件系統的不同模型可以捕獲關于這個軟件的應用領域、使用方法、試題手段和構造模式等方面的需求信息。各方面的利益相關者包括軟件結構設計師、系統分析員、程序員、項目經理、顧客、投資者、最終用戶和使用軟件的操作員。在UML中要使用各種各樣的模型。 進行系統設計。建筑設計師可以用畫在圖紙上的模型圖、存于計算機中的模型或實際的三維模型使自己的設計結果可視化，并用這些模型來做設計方面的的試驗。建造、修改一個小型模型比較簡單，這使得設計人員不需花費什么代價就可以進行創(chuàng)造和革新。 在編寫程序代碼以前，軟件系統的模型可以幫助軟件開發(fā)人員方便地研究軟件的多種構架和設計方案

64、。在進行詳細設計以前，一種好的建模語言可以讓設計者對軟件的構架有全面的認識。 使具體的設計細節(jié)與需求分開。建筑物的某種模型可以展示出符合顧客要求的外觀。另一類模型可以說明建筑物內部的電氣線路、管線和通風管道的設置情況。實現這些設置有多種方案。最后確定的建筑模型一定是建筑設計師認為最好的一個設計方案。顧客可以對此方案進行檢查驗證，但通常顧客對具體的設計細節(jié)并不關心，只要能滿足他們的需要即可。 軟件系統的一類模型可以說明這個系統的外部行為和系統中對應于真實世界的有關信息，另一類模型可以展示系統中的類以及實現系統外部行為特性所需要的內部操作。實現這些行為有多種方法。最后的設計結果對應的模型一定是

65、設計者認為最好的一種。 生成有用的實際產品。建筑模型可以有多種相關產品，包括建筑材料清單、在各種風速下建筑物的偏斜度、建筑結構中各點的應力水平等。 利用軟件系統的模型，可以獲得類的聲明、過程體、用戶界面、數據庫、合法使用的說明、配置草案以及與其他單位技術競爭情況的對比說明。 組織、查找、過濾、重獲、檢查以及編輯大型系統的有關信息。建筑模型用服務設施來組織信息：建筑結構、電器、管道、通風設施、裝潢等等。除非利用計算機存儲，否則對這些信息的查找和修改沒那么容易。相反，如果整個模型和相關信息均存儲在計算機中，則這些工作很容易進行，并且可方便地研究多種設計方案，這些設計方案共享一些公共信息。

66、軟件系統用視圖來組織信息：靜態(tài)結構視圖、狀態(tài)機視圖、交互視圖、反映需求的視圖等等。每一種視圖均是針對某一目的從模型中挑選的一部分信息的映射。沒有模型管理工具的支持不可能使模型做得任意精確。一個交互視圖編輯工具可以用不同的格式表示信息，可以針對特定的目的隱藏暫時不需要的信息并在以后再展示出來，可以對操作進行分組、修改模型元素以及只用一個命令修改一組模型元素等等。 經濟地研究多種設計過程中的解決方案。對同一建筑的不同設計方案的利弊在一開始可能不很清楚。例如，建筑物可以采用的不同的子結構彼此之間可能有復雜的相互影響，建筑工程師可能無法對這些做出正確的評價。在實際建造建筑物以前，利用模型可以同時研究多種設計方案并進行相應的成本和風險估算。 通過研究一個大型軟件系統的模型可以提出多個實際方案并可以對它們進行相互比較。當然模型不可能做得足夠精細，但即使一個粗糙的模型也能夠說明在最終設計中所要解決的許多問題。利用模型可以研究多種設計方案，所花費的成本只是實現其中一種方案所花費的成本。 利用模型可以全面把握復雜的系統。一個關于龍卷風襲擊建筑物的工程模型中的龍卷風不可能是真實世界里的龍卷風，僅僅