UML參考手冊.doc

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

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

2、2.3 模型的層次 8 2.4 模型內(nèi)容 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 協(xié)作圖 18 3.5 狀態(tài)機(jī)視圖 19 3.6 活動視圖 20 3.7 物理視圖 21 3.8 模型管理視圖 24 3.9 擴(kuò)展組件 25 3.10 各種視圖間的關(guān)系 26 第 4 章 靜態(tài)視圖 27 4.1 概述 27 4.2 類元 27 4.3 關(guān)系 29 4.4 關(guān)聯(lián) 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 實現(xiàn) 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)機(jī)視圖 44 6.1 概述 44 6.2 狀態(tài)機(jī) 44 6.3 事件 44 6.4 狀態(tài) 46 6.5 轉(zhuǎn)換 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 協(xié)作 58 8.3 交互 58 8.4 順序圖 59 8.5 激活 59 8.6 合作圖 60 8.7 模板 62 第 9 章 物理視圖 64 9.1 概述 64 9.2 構(gòu)件 64 9.3 節(jié)點 65 第 10 章 模型管理視圖 66 10.1 概述 66 10.2 包 66 10.3 包間的依賴關(guān)系 66 10.4 訪問與引入依賴關(guān)系 67 10.5 模型和子系統(tǒng) 67 第 11 章 擴(kuò)展機(jī)制 69 11.1 概述 69 11.2 約束 69 11.3 標(biāo)

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

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

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

8、talk-80之后，20世紀(jì)80年代又有一大批面向?qū)ο蟮木幊陶Z言問世，標(biāo)志著面向?qū)ο蠓椒ㄗ呦虺墒旌蛯嵱?。此時，面向?qū)ο蠓椒ㄩ_始向系統(tǒng)設(shè)計階段延伸，出現(xiàn)了如Booch86、GOOD（通用面向?qū)ο蟮拈_發(fā)）、HOOD（層次式面向?qū)ο蟮脑O(shè)計）、OOSD（面向?qū)ο蟮慕Y(jié)構(gòu)設(shè)計）等一批OOD（“面向?qū)ο蟮脑O(shè)計”或“面向?qū)ο蟮拈_發(fā)”的縮寫）方法。但是這些早期的OOD方法不是以面向?qū)ο蟮姆治觯∣OA）為基礎(chǔ)的，而主要是基于結(jié)構(gòu)化分析。到1989年之后，面向?qū)ο蠓椒ǖ难芯恐攸c開始轉(zhuǎn)向軟件生命周期的分析階段，并將OOA和OOD密切地聯(lián)系在一起，出現(xiàn)了一大批面向?qū)ο蟮姆治雠c設(shè)計（OOA&D）方法，如Booch方法、

9、Coad/Yourdon方法、 Firesmith方法、Jacobson的OOSE、 Martin/Odell方法、 Rumbaugh等人的OMT、 Shlaer/Mellor方法等等。截至1994年，公開發(fā)表并具有一定影響的OOA & D方法已達(dá)50余種。這種繁榮的局面表明面向?qū)ο蠓椒ㄒ呀?jīng)深入到分析與設(shè)計領(lǐng)域，并隨著面向?qū)ο蟮臏y試、集成與演化技術(shù)的出現(xiàn)而發(fā)展為一套貫穿整個軟件生命周期的方法體系。目前，大多數(shù)較先進(jìn)的軟件開發(fā)組織已經(jīng)從分析、設(shè)計到編程、測試階段全面地采用面向?qū)ο蠓椒?，使面向?qū)ο鬅o可置疑地成為當(dāng)前軟件領(lǐng)域的主流技術(shù)。 各種面向?qū)ο蟮姆治雠c設(shè)計方法都為面向?qū)ο罄碚撆c技術(shù)的發(fā)展作出

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

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

12、起的動機(jī)、目標(biāo)、權(quán)衡的問題等，這里不想做更多的介紹，因為讀者很快會從《UML用戶指南》的前言中看到更詳細(xì)的敘述。這里想著重指出的是以下三點：第一點是UML的三位發(fā)起人G. Booch、J. Rumbaugh和I. Jacobson是從事面向?qū)ο笱芯康闹麑＜?，他們各自的方法和著作在該領(lǐng)域均具有很大的影響；第二點是眾多的大公司加入了UML陣營，為UML的制定和推廣提供了強(qiáng)有力的支持；第三點是UML經(jīng)過數(shù)年的努力終于被OMG采納，成為該組織承認(rèn)的一種標(biāo)準(zhǔn)建模語言?？傊琔ML是吸收多種方法的成果、凝結(jié)許多組織和個人智慧的產(chǎn)物。 UML是一種用于對軟件密集型系統(tǒng)進(jìn)行可視化、詳述、構(gòu)造和文檔化的建模

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

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

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

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

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

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

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

20、L語言標(biāo)準(zhǔn)文獻(xiàn)和UML元模型內(nèi)部細(xì)節(jié)的指導(dǎo)手冊。對元模型的細(xì)節(jié)感興趣的是UML工具的開發(fā)者和研究開發(fā)方法的專家，一般的軟件開發(fā)人員無需了解對象管理組織（OMG, Object Management Group）制定的這些不易為人了解的細(xì)節(jié)。本書涵蓋了能夠滿足絕大部分軟件開發(fā)人員需要的細(xì)節(jié)內(nèi)容，對于某些源于原始標(biāo)準(zhǔn)的細(xì)節(jié)，往往指明了其出處。 本書所附光盤收錄了一些原始標(biāo)準(zhǔn)文獻(xiàn)，供讀者參考。 在閱讀本書之前，讀者應(yīng)具備有關(guān)面向?qū)ο蠹夹g(shù)的基本知識。為方便初學(xué)者，書后的參考文獻(xiàn)中列出了我們和其他作者早期的原作。雖然這些書中采用的某些表示法現(xiàn)在已有了變化，但是一些書中介紹的面向?qū)ο蟮母拍钊匀挥杏?，如[

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

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

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

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

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

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

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

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

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

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

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

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

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

34、，有的卻因為提出這些見解的人運(yùn)氣不佳而不被人了解。 要是在一個更私人的場合，我希望能夠表達(dá)對Jack Dennis教授的感謝。早在25年前，他就對我和我的學(xué)生在建模方面的工作進(jìn)行鼓勵。他所在的MIT的 計算結(jié)構(gòu)組（Computations Structures Group）所提出的見解已產(chǎn)生了豐碩的成果，這些見解對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建模的性質(zhì)和目標(biāo)以及UML覆蓋的所有功能領(lǐng)域。 第 1 章 UML綜述 本章是UML及其應(yīng)用的一個快速瀏覽。 1.1 UML簡介 統(tǒng)一建模語言（UML）是一個通用的可視化建模語言，用于對軟件進(jìn)行描述、可視化處理、構(gòu)造和建立軟件系統(tǒng)制品的文檔。它記錄了對必須構(gòu)造的系統(tǒng)的決定和理解，可用于對系統(tǒng)的理解、設(shè)計、瀏

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

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

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

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

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

41、k語言成名約5 年后，第一批介紹面向?qū)ο筌浖_發(fā)方法的書籍出現(xiàn)了。包括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、等有關(guān)程序語言設(shè)計的著作，開創(chuàng)了面向?qū)ο蠓椒ǖ南群?。第一階段在1990年末完成。稍晚[Jacobson-92]出版了，它建立在以前的成果的基礎(chǔ)上，介紹了一種稍微不同的方法，即以用例和開發(fā)過程為中心。 在以后的5年中，大批關(guān)于面向?qū)ο蠓椒ǖ臅畣柺?，各有自己的一套概念、定義、表示法、術(shù)語和適用的開發(fā)過程。有些書提出了一些新概念，但總的來說各個作者所使用的概念大同小異。許多后繼出版的書都照搬前人，自己再做一些小的擴(kuò)充或修改。最早的著作者也沒閑著，他們大部分人都更新了自己前期的著作，采納了其他人一些好的思想?？傊?，出現(xiàn)了一些被廣泛使用的核心概念，另外還有一大批被個別人采納的概念。即使在被廣泛接受的

43、核心概念里，在各個面向?qū)ο蠓椒ㄖ幸灿幸恍┬〉牟町?。這些面向?qū)ο蠓椒ㄖg的細(xì)微比較常使人覺得這些概念不知依據(jù)哪個為好，特別是非專業(yè)的讀者。 1.2.2 統(tǒng)一工作 在UML之前，已經(jīng)有一些試圖將各種方法中使用的概念進(jìn)行統(tǒng)一的初期嘗試，比較有名的一次是Coleman和他的同事們[Coleman-94]對OMT[Rumbaugh-91]、Booch[Booch-91]、CRC[Wirfs-Brock-90]方法使用的概念進(jìn)行融合。由于這項工作沒有這些方法的原作者參與，實際上僅僅形成了一種新方法，而不能替換現(xiàn)存的各種方法。第一次成功合并和替換現(xiàn)存的各種方法的嘗試始于1994 年在Rational

44、軟件公司Rumbaugh與 Booch合作。他們開始合并OMT和Booch 方法中使用的概念，于1995年提出了第一個建議。此時，Jacobson 也加入了Rational公司開始與Rumbaugh和Booch一同工作。他們共同致力于設(shè)計統(tǒng)一建模語言。三位最優(yōu)秀的面向?qū)ο蠓椒▽W(xué)的創(chuàng)始人共同合作，為這項工作注入了強(qiáng)大的動力，打破了面向?qū)ο筌浖_發(fā)領(lǐng)域內(nèi)原有的平衡。而在此之前，各種方法的擁護(hù)者覺得沒有必要放棄自己已經(jīng)采用的概念而接受這種統(tǒng)一的思想。 1996年，OMG發(fā)布了征集向外界關(guān)于面向?qū)ο蠼?biāo)準(zhǔn)方法的消息。UML的三位創(chuàng)始人開始與來自其他公司的軟件工程方法專家和開發(fā)人員一道制訂一套使OM

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

46、軟件工程方法學(xué)家宣布他們將使用UML的表示法進(jìn)行以后的研究工作。UML的出現(xiàn)似乎深受計算機(jī)界歡迎，因為它是由官方出面集中了許多專家的經(jīng)驗而形成的，減少了各種軟件開發(fā)工具之間無謂的分歧。我們希望建模語言的標(biāo)準(zhǔn)化既能促進(jìn)軟件開發(fā)人員廣泛使用面向?qū)ο蠼＜夹g(shù)，同時也能帶來UML支持工具和培訓(xùn)市場的繁榮，因為不論是用戶還是供應(yīng)商都不用再考慮到底應(yīng)該采用哪一種開發(fā)方法。 1.2.4 核心組員 提出UML建議或進(jìn)行UML標(biāo)準(zhǔn)修訂工作的核心組員有下列人員： 數(shù)據(jù)存取公司：Tom Digre DHR 技術(shù)公司：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 系統(tǒng)企業(yè)：Cris Kobryn, Joaquin Miller ObjecTime 公司：John Hogg, Bran Selic Oracle 公司：Guus Ramackers 鉑技術(shù)公司：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 統(tǒng)一的意義 “統(tǒng)一”這個詞在UML中有下列一些相互關(guān)聯(lián)的含義： 在以往出現(xiàn)的方法和表示法方面。UML合并了許多面向?qū)ο蠓椒ㄖ斜黄毡榻邮艿母拍?，對每一種概念，UM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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