建模語言uml參考手冊

11UML參考手冊UML參考手冊UML參考手冊PAGE\*ROMANPAGE\*ROMANIV目錄譯者序 i前言 iv第一部分背景知識 1第1章UML綜述 1UML簡介 1UML的歷史 1面向?qū)ο蟮拈_發(fā)方法 1統(tǒng)一工作 2標(biāo)準(zhǔn)化 3核心組員 3統(tǒng)一的意義 3UML的目標(biāo) 4UML概念域 5表達(dá)式和圖表語法 6第2章模型的性質(zhì)與目標(biāo) 7什么是模型 7模型的用途 7模型的層次 8模型內(nèi)容 10模型說明了什么？ 11第二部分基本概念 13第3章UML初覽 14UML視圖 14靜態(tài)視圖 15用例視圖 16交互視圖 17順序圖 17協(xié)作圖 18狀態(tài)機視圖 19活動視圖 20物理視圖 21模型管理視圖 24擴展組件 25各種視圖間的關(guān)系 26第4章靜態(tài)視圖 274.1概述 274.2類元 274.3關(guān)系 294.4關(guān)聯(lián) 304.5泛化 334.5.1繼承 34多重繼承 34單分類和多重分類 35靜態(tài)與動態(tài)類元 354.6實現(xiàn) 364.7依賴 374.8約束 384.9實例 394.10對象圖 39第5章用例視圖 415.1概述 415.2參與者 415.3用例 42第6章狀態(tài)機視圖 446.1概述 446.2狀態(tài)機 446.3事件 446.4狀態(tài) 466.5轉(zhuǎn)換 476.6組成狀態(tài) 50第7章活動視圖 557.1概述 55活動圖 55活動和其他圖 57第8章交互視圖 588.1概述 588.2協(xié)作 588.3交互 588.4順序圖 598.5激活 598.6合作圖 608.7模板 62第9章物理視圖 649.1概述 649.2構(gòu)件 649.3節(jié)點 65第10章模型管理視圖 6610.1概述 6610.2包 66包間的依賴關(guān)系 66訪問與引入依賴關(guān)系 67模型和子系統(tǒng) 67第11章擴展機制 6911.1概述 6911.2約束 69標(biāo)簽值 70構(gòu)造型 71裁制UML 72第12章UML環(huán)境 7312.1概述 73語義職責(zé) 73表示法職責(zé) 74程序語言職責(zé) 74使用建模工具建模 75工具問題 75工作進(jìn)展過程中產(chǎn)生的不一致模型 75空值和未詳細(xì)說明的值 75第三部分 參考資料 77第13章術(shù)語大全 78第14章標(biāo)準(zhǔn)元素 334第四部分附錄 343附錄UML元模型 344索引 1UML參考手冊UML參考手冊PAGE\*romanPAGE\*romanviii譯者序雜性與日俱增，從而使軟件技術(shù)不斷地受到新的挑戰(zhàn)。60年代軟件危機的出現(xiàn)就是因為系問題交給計算機去解決。于是又需要更先進(jìn)的方法與技術(shù)。.周期的分析與設(shè)計階段。Smalltalk-80之后，2080年代又有一大批面向?qū)ο蟮木幎窝由?，出現(xiàn)了如Booch86、GOOD（通用面向?qū)ο蟮拈_發(fā)、HOOD（層次式面向?qū)ο蟮脑O(shè)計“”1989年之后，面向?qū)ο蠓椒ǖ难芯恐攸c開始轉(zhuǎn)向軟件生命周期的分析階段，并將OOA和OOD密切地聯(lián)系在一起，出現(xiàn)了一大批面向?qū)ο蟮姆治雠c設(shè)計1994年，公開OOA&D50余種。這種繁榮的局面表明面向?qū)ο蠓椒ㄒ鸭夹g(shù)。aal..決定將他們各自的方法結(jié)合起來成為一種方法。1995年10月發(fā)布了第1“（edMtod0.8OOE.JabonRational公司，于是也加入了統(tǒng)一行動。199662UML0.9。（0.9“（fedodingangaaUML12UML1.0版，并于（OMG）申請作為一種標(biāo)準(zhǔn)建模語言。此后，又把其他幾家分頭向OMGUML伙伴組織中，并為反映他們的意見而UMLUML1.11997114OMG采納。UMLUML1.3。讀者很快會從《UML用戶指南》的前言中看到更詳細(xì)的敘述。這里想著重指出的是以下三G.Booch、J.RumbaughI.Jacobson是從事面向?qū)ο笱蠻MLUMLUML經(jīng)過數(shù)年OMG采納，成為該組織承認(rèn)的一種標(biāo)準(zhǔn)建模語言?？傊琔ML是吸收多種方法的成果、凝結(jié)許多組織和個人智慧的產(chǎn)物。UML是一種用于對軟件密集型系統(tǒng)進(jìn)行可視化、詳述、構(gòu)造和文檔化的建模語言，主要適用于分析與設(shè)計階段的系統(tǒng)建模。UML最主要的特點是表達(dá)能力豐富。因為它從各種OOA&D方法中吸取了大量的概念，并在“UML語義”、“UML表示法指南”、“對象約束語OOA&D方法。當(dāng)然，隨之而來的問題是，它的復(fù)雜性也超出了以往任何一種方法。UML的問世引起了計算機軟件界的廣泛重視，因為它代表了一種積極的方向—多種方UML進(jìn)行系統(tǒng)建模。UMLUML也相當(dāng)關(guān)注。許多研究人員和技UMLUML的豐富內(nèi)容相比，這些介紹遠(yuǎn)不能滿足讀者的要求。UMLAddisonWesley1999年出版。這套著作對UML進(jìn)行了詳細(xì)、深入而準(zhǔn)確的介紹和論述，而且語言生動、深入淺出、實例豐富、圖文《UML三本原著都是由這三位作者合著，既各自獨立、又有很強的內(nèi)在聯(lián)系。其中《UML用UMLUML的術(shù)語、規(guī)則和語言特點，以及如何運用該UMLUML參考手冊》對UML的組成和概念作了詳細(xì)的介紹，包括這些概念的語義、語法、表示法和用途，是一本UMLOMGUML只是一種建模語言，并不包含過程指導(dǎo)。實際上，UML是獨立于過程的，可UML時一直在頭UMLUML的概念進(jìn)行軟件開發(fā)提供了詳細(xì)指導(dǎo)，適合軟件專業(yè)人員使用。量。正了解所涉及的技術(shù)內(nèi)容。這套著作的內(nèi)容遠(yuǎn)遠(yuǎn)超出了UML的標(biāo)準(zhǔn)文獻(xiàn)，因為除了介紹UML的語法、語義、使用規(guī)則之外，其中還包含許多學(xué)術(shù)思想、技術(shù)策略和實踐經(jīng)驗。在希望廣大讀者對可能存在的疏漏和錯誤之處給予批評和指正。譯者200010月于北京前言目標(biāo)本書是關(guān)于統(tǒng)一建模語言（UML,UnifiedModelingLanguage）的一本全面實用的參考書,可供軟件開發(fā)人員，設(shè)計人員，項目管理員，系統(tǒng)工程師，程序設(shè)計人員，分析員，用的組成和概念UML標(biāo)準(zhǔn)中一些結(jié)論的基本原理。UMLUML元模型內(nèi)部細(xì)節(jié)的指導(dǎo)手冊。對元模型ObjectManagementGroup）制定的這些不易為人了解的細(xì)節(jié)。本書化，但是一些書中介紹的面向?qū)ο蟮母拍钊匀挥杏?，如[Rumbaugh-91]、[Booch-94]、[Jacobson-92]和[Meyer-88]等書，所以這里沒有必要重新討論這些基本概念。如果某些讀者UML，閱讀《UML用戶指南》很有幫助。UML增量的、用例驅(qū)動的開發(fā)過程—（即將由機械工業(yè)出版社出版）[Jacobson-99]就描述了這樣一種開發(fā)過程，UML的補充和對軟件開發(fā)的最好支持。本書概貌UML歷史和有關(guān)建模知識的概述；UML基本概念的綜述；UML術(shù)語和概念大全。UML綜述—UML—UML的來源和它能滿足的需求。UML所支持的各種視圖，并說明各種構(gòu)件如何協(xié)同工作。該部分首先介紹了一個用到了各書中術(shù)語和概念大全的起點。UMLUML術(shù)語，不論重要與否，在大全中都有對應(yīng)條目，大全盡可能提供全面信息。因此，凡是第二部分提到的概念，出，以便讀者查閱。參考信息部分還包括了一個按字母順序排列的UML標(biāo)準(zhǔn)元素列表。標(biāo)準(zhǔn)元素是使用UML的擴展部分，相信應(yīng)該能得到廣泛使用。UML的元模型、UML表示法小結(jié)和用于專門領(lǐng)域的標(biāo)準(zhǔn)擴展集。附錄還究這些方法和概念的形成和發(fā)展。大全部分的格式約定UMLUML的介紹性讀物，如《UML簡要定義考后面的主體解釋短文。語義了“結(jié)構(gòu)”小節(jié)。盡管在結(jié)構(gòu)編排上采取了多種方式，但該結(jié)構(gòu)對讀者來說仍然很清晰。表示法注釋說明，不是實際表示法的一部分。示例生混淆的情形來列舉。討論討論段。爭論的設(shè)計結(jié)論。只有一小部分條目有這一節(jié)。討論一般不涉及風(fēng)格上的簡單不同點。標(biāo)準(zhǔn)元素現(xiàn)。語法約定SansSerifBNF范式。標(biāo)點符號也出現(xiàn)在目標(biāo)字符串中。含字符和連字符。在代碼示例中，注釋用楷體印刷在代碼右側(cè)。下標(biāo)或上劃線為語法操作，舉例如下：expressionopt 這個表達(dá)式是任選的。expressionlist, 用逗號來分隔一系列表達(dá)式。如果出現(xiàn)了零個或者一個重復(fù)符如果一個除逗號之外的標(biāo)點符號出現(xiàn)在下標(biāo)中，則它是分隔符。=expressionopt 用上劃線來連接兩個或多個屬于同一單元的可選的或重復(fù)出現(xiàn)的單元。如果只有一個項目，可以不用上劃線。不允許出現(xiàn)兩重嵌套。SansSerif字體印刷。其他所有文字和符號都是實際的圖形表示法。CD光盤AdobeReader(PDF)文件格式收錄了本書全文，讀者可以很容易地查到一個字或短語。本書CD還包括一個可用鼠標(biāo)點擊操作的目錄表，表中包括書中文章的目點擊某一熱鏈接，即可跳到大全中對應(yīng)該字或短語條目的章節(jié)中去。CDOMGUMLOMG授權(quán)認(rèn)可的。高級用戶來說，將是一本非常有用的在線參考書。如何獲取更多信息致謝Rational軟件公司，特別是MikeDevlinPaullevy，正是他們頗具慧眼地將我們組織在一起，并發(fā)起面向?qū)ο蠼ＵZ的。各執(zhí)己見的組員達(dá)成一致（當(dāng)然我們?nèi)齻€人達(dá)成一致不會有太大的問題。他的交際才能和UMLCris還復(fù)審了全書，給出了大量有益的建議。Gunnarergaard表示感謝，感謝他對本書做了詳細(xì)的復(fù)審，以及他為完成UMLKarinPalmkvist對本書做了極為細(xì)致的校審，并指出了許多技術(shù)上的錯誤以及語法、措辭和表達(dá)方式上的缺陷。MikeBlaha、ConradBock、PerryCole、BruceDouglass、MartinFowler、、GuusRamackers、TomSchultz、EdseidewitzBranSelic，感謝他們對本書做了復(fù)審。史傳記。這些見解有的廣為人知，有的卻因為提出這些見解的人運氣不佳而不被人了解。JackDennis25年前，他就對我和我的學(xué)生在建模方面的工作進(jìn)行鼓勵。他所在的MIT的計算結(jié)構(gòu)組StructuresGroup）UML的MaryLoomisAshwinShahOMT、BillPremerlani、FredEddy和BillLorensenOMT的書籍。MadelineNick和Alex的耐心支持，就沒UML和這本書。JamesRumbaugh199811月UML參考手冊UML參考手冊11UMLUMLUML覆蓋的所有功能領(lǐng)域。第1UML綜述UML及其應(yīng)用的一個快速瀏覽。UML簡介統(tǒng)一建模語言（UML）是一個通用的可視化建模語言，用于對軟件進(jìn)行描述、可視化對系統(tǒng)的理解、設(shè)計、瀏覽、配置、維護(hù)和信息控制。UML適用于各種軟件開發(fā)方法、軟件生命周期的各個階段、各種應(yīng)用領(lǐng)域以及各種開發(fā)工具，UML是一種總結(jié)了以往建模技術(shù)的經(jīng)驗并吸收當(dāng)今優(yōu)秀成果的標(biāo)準(zhǔn)建模方法。UML包括概念的語義，表示法和說明，提工具提供了代碼生成器和報表生成器。UML標(biāo)準(zhǔn)并沒有定義一種標(biāo)準(zhǔn)的開發(fā)過程，但它適用于迭代式的開發(fā)過程。它是為支持大部分現(xiàn)存的面向?qū)ο箝_發(fā)過程而設(shè)計的。UMLUML將系統(tǒng)描述為一些離散的相互作用標(biāo)而相互進(jìn)行通信的機制。從不同但相互聯(lián)系的角度對系統(tǒng)建立的模型可用于不同的目的。UML還包括可將模型分解成包的結(jié)構(gòu)組件，以便于軟件小組將大的系統(tǒng)分解成易于處還包括用于顯示系統(tǒng)實現(xiàn)和組織運行的組件。UMLUML模型轉(zhuǎn)換為多種程UML是一種通用建模語言。對于一些專門領(lǐng)域，例如用戶圖形界面（GUI）設(shè)計、超大規(guī)模集成電路（VLSI）設(shè)計、基于規(guī)則的人工智能領(lǐng)域，使用專門的語言和工具可能會更適合些。UML是一種離散的建模語言，不適合對諸如工程和物理學(xué)領(lǐng)域中的連續(xù)系統(tǒng)建模。建模。UML的歷史UML是為了簡化和強化現(xiàn)有的大量面向?qū)ο箝_發(fā)方法這一目的而開發(fā)的。面向?qū)ο蟮拈_發(fā)方法利用傳統(tǒng)程序設(shè)計語言（Cobol和Fortran語言）20世紀(jì)7080年代被廣泛采用，其中最重要的是結(jié)構(gòu)化分析和結(jié)構(gòu)化設(shè)計方法[Yourdon-79]、Demarco、UML參考手冊UML參考手冊PAGEPAGE10—許多計算機輔助軟件工程系統(tǒng)（CASE）只是摘錄一些已實現(xiàn)的系統(tǒng)設(shè)計的報表生成器—盡管如此，這些方CASE系統(tǒng)和開發(fā)方法。大部分商業(yè)企業(yè)都獨立開發(fā)本企業(yè)內(nèi)部使用的軟件，客戶和締單，不論這種看法是否正確，反正它不需要經(jīng)過外界組織的檢查。1967Simula-67是第一個面向?qū)ο蟮恼Z言。盡管這個語言對后來的許多面向?qū)ο笳Z言的設(shè)計產(chǎn)生了很大的影響，但是它沒有后繼版本。80年代初“面向?qū)ο筮\動”C、C++、smalltalk5年后，第一批介紹面向?qū)ο筌浖_發(fā)[Coad/Yourdon[Coad-91]，緊接著又有Booch[Booch-91]Rumbaugh/Blaha/Premerlani/Eddy/Lorensen[Rumbaugh-91]和[月份以后出版的書。這些著作再加上Goldberg/Robson[Goldberg-83]Cox[Cox-86]和Meyer[Meyer-88]等有關(guān)程序語言設(shè)計的著作，開創(chuàng)了面向?qū)ο蠓椒ǖ南群?。第一階段在不同的方法，即以用例和開發(fā)過程為中心。5較常使人覺得這些概念不知依據(jù)哪個為好，特別是非專業(yè)的讀者。統(tǒng)一工作和他的同事們[Coleman-94]OMT[Rumbaugh-91]、Booch[Booch-91]、方法使用的概念進(jìn)行融合。由于這項工作沒有這些方法的原作者參與，1994RationalRumbaugh與Booch合作。他們開始合也加入了RationalRumbaugh和Booch已經(jīng)采用的概念而接受這種統(tǒng)一的思想。1996年，OMG發(fā)布了征集向外界關(guān)于面向?qū)ο蠼?biāo)準(zhǔn)方法的消息。UML的三位創(chuàng)始人開始與來自其他公司的軟件工程方法專家和開發(fā)人員一道制訂一套使OMG感興趣的接受的建模語言。與此同時，其他一些人也在做這項富有競爭性的工作。19979月，所UMLOMG慧的結(jié)晶。標(biāo)準(zhǔn)化OMG承擔(dān)了進(jìn)一UMLUMLUML精華的書出版發(fā)UML，若干軟件工程方法學(xué)UML的表示法進(jìn)行以后的研究工作。UML的出現(xiàn)似乎深受計算機界歡謂的分歧。我們希望建模語言的標(biāo)準(zhǔn)化既能促進(jìn)軟件開發(fā)人員廣泛使用面向?qū)ο蠼＜夹g(shù)，到底應(yīng)該采用哪一種開發(fā)方法。核心組員UMLUML標(biāo)準(zhǔn)修訂工作的核心組員有下列人員：數(shù)據(jù)存取公司：TomDigreDHR技術(shù)公司：EdSeidewitzHP公司：MartinGrissIBM公司：SteveBrodskySteveCookJosWarmerI—Lgix公司：EranGery,DavidHarelICONComputing公司：DesmondD'SouzaIntelliCorpandJamesMartin公司：ConradBock,JamesOdellMCI系統(tǒng)企業(yè)：CrisKobryn,JoaquinMillerObjecTime公司：JohnHoggBranSelicOracle公司：GuusRamackers鉑技術(shù)公司：DilharDesilvaRational軟件公司：GradyBooch,EdEykholt,IvarJacobson,GunnarOvergaard,KarinPalmkvistJamesRumbaughSAP公司：OliverWiegertSOFTEAM：PhilippeDesfraySterling軟件公司：JohnCheesmanKeithShortTaskon公司：TrygveReenskaug統(tǒng)一的意義UML中有下列一些相互關(guān)聯(lián)的含義：在以往出現(xiàn)的方法和表示法方面UML合并了許多面向?qū)ο蠓椒ㄖ斜黄毡榻邮艿母拍?，對每一種概念，UMLUML可以對已有的用各種方法建立的模型進(jìn)行描述，并比原來的方法描述得更好。在軟件開發(fā)的生命期方面。UML對于開發(fā)的要求具有無縫性。開發(fā)過程的不同階段可段，不必轉(zhuǎn)換概念和表示。這種無縫性對迭代式的、增量式軟件開發(fā)是至關(guān)重要的。在應(yīng)用領(lǐng)域方面。UML適用于各種應(yīng)用領(lǐng)域的建模，包括大型的、復(fù)雜的、實時的、領(lǐng)域更有用，但在大部分應(yīng)用領(lǐng)域中，UML不但不比其他的通用語言遜色并且更好。在實現(xiàn)的編程語言和開發(fā)平臺方面。UML可應(yīng)用于運行各種不同的編程實現(xiàn)語言和開的不同。。UML新出現(xiàn)的開發(fā)過程。尤其適用于我們所推薦的迭代式增量開發(fā)過程。重要的結(jié)果之一。UML的目標(biāo)UML一個通用的建模語言，各種主要的方法并可作為它們的建模語言。至少，我們希望它能夠替代OMT，Booch，件開發(fā)中的熱點問題，比如大規(guī)模、分布、并發(fā)、方式和團(tuán)體開發(fā)等。UML并不試圖成為一個完整的開發(fā)方法。它不包括一步一步的開發(fā)過程。我們認(rèn)為一個好的軟件開發(fā)過程對成功的開發(fā)軟件是至關(guān)重要的，我們向讀者推薦一本書[Jacobson-99]UMLUMLUML可以支持所有的，至少是目前現(xiàn)有的大部分軟件開發(fā)過程。UML包含了所有的概念，我們認(rèn)為這些概念對于支持基于一個健壯的構(gòu)架來解決用例驅(qū)動的需求的迭代式開發(fā)過程是必要的。UML的最終目標(biāo)是在盡可能簡單的同時能夠?qū)嶋H需要建立的系統(tǒng)的各個方面建模。UML需要有足夠的表達(dá)能力以便可以處理現(xiàn)代軟件系統(tǒng)中出現(xiàn)的所有概念，例如并發(fā)和分40年前要復(fù)雜多，因為我們對它們的要求越來越多。UML提供了多種模型，不是在一天之內(nèi)就能夠掌握的。它比先前的建模言、操作系統(tǒng)或是復(fù)雜的應(yīng)用軟件一樣。UML概念域UML的概念和模型可以分成以下幾個概念域。素統(tǒng)稱為類元，它們的行為很像在每種類元上具有一定限制的類。有兩種方式對行為建模。一種是根據(jù)一個對象與外界發(fā)生關(guān)系的生命歷史；一種狀態(tài)轉(zhuǎn)換到另一種狀態(tài)時的視圖。狀態(tài)機模型用狀態(tài)圖來描述。例，每一個用例描述了一個用例參與者或系統(tǒng)外部用戶可見的一個功能。實現(xiàn)構(gòu)造。UML模型既可用于邏輯分析又可用于物理實現(xiàn)。某些組件代表了實現(xiàn)。構(gòu)列以及構(gòu)件包括的對象，并包括節(jié)點間內(nèi)容的可能遷移。架要求。UMLUML擴充的需求而不改變語言機制可以避免語言基礎(chǔ)發(fā)生根本性變化。表達(dá)式和圖表語法盡量避免將解釋說明和實例弄混，本書采用了一些約定的格式。字體印刷。例如，模型中出現(xiàn)達(dá)式中的括弧，它不是實際語法機構(gòu)的一部分。例如：Order.create(customer,amount)在連續(xù)的文中，關(guān)鍵詞和模型元素名都用ComicSans字體印刷，如：Order或Customer。ComicSans字體替代，如：name。表達(dá)式中的黑色正文表示出現(xiàn)在目標(biāo)圖示上字面上的值。斜體或下劃線說明替換文本具有給定的性質(zhì)。例如：name.operation(argument,...)object-name:class在語法表達(dá)式中，下標(biāo)和上劃線用于指示某種語法性質(zhì)。例如：expressionopt這個表達(dá)式是任選的?，F(xiàn)在下標(biāo)中，則它是分隔符。=expressionopt用上劃線來連接兩個或多個屬于同一單元的可選的或重復(fù)出現(xiàn)的項以不用上劃線。的一部分。其他文字和符號是實際表示法的一部分。第2次：理想的，部分的和基于工具的。什么是模型使用模型。僅能夠展示這個建筑物的外觀，還可以用它來進(jìn)行工程設(shè)計和成本核算。UML。模型包含語義信息和表示法，可以采取更容易和方便。模型的用途模型有多種用途捕獲精確和表達(dá)項目的需求和應(yīng)用領(lǐng)域中的知識，以使各方面的利益相關(guān)者能夠理解建筑物的各種模型能夠準(zhǔn)確表達(dá)出這個建筑物在外觀、交通、服務(wù)設(shè)施、師、合同締約人、各個子項目的締約人、業(yè)主、出租者和市政當(dāng)局。各樣的模型。一個小型模型比較簡單，這使得設(shè)計人員不需花費什么代價就可以進(jìn)行創(chuàng)造和革新。架有全面的認(rèn)識。使具體的設(shè)計細(xì)節(jié)與需求分開。建筑物的某種模型可以展示出符合顧客要求的外觀。的需要即可。軟件系統(tǒng)的一類模型可以說明這個系統(tǒng)的外部行為和系統(tǒng)中對應(yīng)于真實世界的有關(guān)信息，另一類模型可以展示系統(tǒng)中的類以及實現(xiàn)系統(tǒng)外部行為特性所需要的內(nèi)部操種。下建筑物的偏斜度、建筑結(jié)構(gòu)中各點的應(yīng)力水平等。明、配置草案以及與其他單位技術(shù)競爭情況的對比說明。組織、查找、過濾、重獲、檢查以及編輯大型系統(tǒng)的有關(guān)信息。建筑模型用服務(wù)設(shè)施些公共信息。作進(jìn)行分組、修改模型元素以及只用一個命令修改一組模型元素等等。經(jīng)濟地研究多種設(shè)計過程中的解決方案。對同一建筑的不同設(shè)計方案的利弊在一開始時研究多種設(shè)計方案并進(jìn)行相應(yīng)的成本和風(fēng)險估算。通過研究一個大型軟件系統(tǒng)的模型可以提出多個實際方案并可以對它們進(jìn)行相互種方案所花費的成本。利用模型可以全面把握復(fù)雜的系統(tǒng)。一個關(guān)于龍卷風(fēng)襲擊建筑物的工程模型中的龍卷和理解。來哪些影響。模型的層次對應(yīng)于以下幾種目的：在項目早期所建立的高層模型用于集中利益相關(guān)者的思路和強調(diào)一些重?zé)o須涉及有關(guān)系統(tǒng)實現(xiàn)的一套概念。建立這種模型只使用了UML定義的組件的一個子集，比后期的設(shè)計階段的模型使用的組件要少得多。要對開發(fā)過程進(jìn)行回溯。在分析階段和初步設(shè)計階段所建立的模型以關(guān)鍵概念和最終者人工實現(xiàn)。處理。這不是目標(biāo)應(yīng)用系統(tǒng)的特性，而是系統(tǒng)構(gòu)造過程應(yīng)具有的特性。精心挑選的實例可以提高人們的觀察能力并使系統(tǒng)的說明和實模型內(nèi)容（（表示法。（定義UL但可給人啟迪模。上下文（語境。模型自身是一個計算機系統(tǒng)的制品，被應(yīng)用在一個給出了模型含義的大型合、創(chuàng)建和操縱模型的假定條件以及模型與其所處環(huán)境之間的關(guān)系。這種對模型的分解并不是語義方面所要求的—與一個被分解成意義前后連貫的多個包的模精確。但是要想有效地工作于一個大的單塊模型上的多個工作組不彼此相互妨害是不可能可靠的方法。UML用戶所期望的那樣成為建模工具所使用的通用語言。即使這些信息不是語義信息，例如項目管理注釋（在上面已經(jīng)討論過、代碼生成提示、模UML可見的。模型說明了什么？要考慮：的模型包含了大量的細(xì)節(jié)內(nèi)容，具有很高的精度。（（說明就是對它上一層次的實現(xiàn)。（Metamode考察。解釋的變更。用一種建模語言對模型可能會有多種的解釋?？梢远x語義變更點point）———可能會出現(xiàn)多種解釋的地方———給每一個解釋現(xiàn)過程第3UML初覽同的概念來描述一個系統(tǒng)以及如何將各種視圖組織在一起。概括性的說明不可能面面俱到，大全部分的有關(guān)細(xì)節(jié)。使用的每種組件進(jìn)行介紹。UML視圖UML中的各種組件和概念之間沒有明顯的劃分界限，但為方便起見，我們用視圖來劃特定的圖來可視化地表示視圖中的各種概念。元為研究系統(tǒng)動態(tài)行為奠定了基礎(chǔ)。類元視圖包括靜態(tài)視圖、用例視圖和實現(xiàn)視圖。述。動態(tài)行為視圖包括狀態(tài)機視圖、活動視圖和交互視圖。和子系統(tǒng)。模型管理視圖跨越了其他視圖并根據(jù)系統(tǒng)開發(fā)和配置組織這些視圖。UML還包括多種具有擴展能力的組件，這些擴展能力有限但很有用。這些組件包括約束、構(gòu)造型和標(biāo)記值，它們適用于所有的視圖元素。UML的視圖和視圖所包括的圖以及與每種圖有關(guān)的主要概念。不能把UMLUML允許使用混合視圖。表3–1UML視圖和圖主要的域視圖圖主要概念結(jié)構(gòu)靜態(tài)視圖類圖類、關(guān)聯(lián)、泛化、依賴關(guān)系、實現(xiàn)、接口用例視圖用例圖用例、參與者、關(guān)聯(lián)、擴展、包括、用例泛化實現(xiàn)視圖構(gòu)件圖構(gòu)件、接口、依賴關(guān)系、實現(xiàn)部署視圖部署圖節(jié)點、構(gòu)件、依賴關(guān)系、位置動態(tài)狀態(tài)機視圖狀態(tài)機圖狀態(tài)、事件、轉(zhuǎn)換、動作、活動視圖活動圖狀態(tài)、活動、完成轉(zhuǎn)換、分叉、結(jié)合交互視圖順序圖交互、對象、消息、激活協(xié)作圖協(xié)作、交互、協(xié)作角色、消息模型管理模型管理視圖類圖報、子系統(tǒng)、模型可擴展性所有所有約束、構(gòu)造型、標(biāo)記值靜態(tài)視圖稱之為是靜態(tài)的是因為它不描述與時間有關(guān)的系統(tǒng)行為，此種行為在其他視圖中進(jìn)行描述。以類為中心，所以稱其為類圖。出，在其他圖中可省略。3–1是售票系統(tǒng)的類圖，它只是售票系統(tǒng)領(lǐng)域模型的一部分。圖中表示了幾個重要識。屬性屬性1類范圍操作關(guān)聯(lián)ownerpurchased角色名*泛化1show0..1多重性1..*performances3..61*1限定符操作sell(c:Customer)exchange()date:Datetime:TimeOfDayseat:Stringavailable:BooleanPerformanceTicket約束{xor}0..1series:IntegerIndividaulname:StringSubscriptionSeriesShowdate:DateReservationname:Stringphone:StringCustomer圖3–1售票系統(tǒng)的類圖用例視圖統(tǒng)中的用例和參與者，并顯示哪個參與者參與了哪個用例的執(zhí)行。付錢（對售票系統(tǒng)的完整描述還要包括其他一些用例，例如換票和驗票等。例做為交互圖中的一次協(xié)作來實現(xiàn)。系統(tǒng)BoxBoxOfficeBuyticketsBuySubscription關(guān)系Makecharges用例Surveysales參與者Clerk公用電話亭信用卡服務(wù)商監(jiān)督員3–2用例圖交互視圖交互視圖描述了執(zhí)行系統(tǒng)功能的各個角色之間相互傳遞消息的順序關(guān)系。類元是對在系有不同的側(cè)重點。順序圖用來進(jìn)行一個場景說明—即一個事務(wù)的歷史過程。每條消息對應(yīng)了一個類操作或狀態(tài)機中引起轉(zhuǎn)換的觸發(fā)事件。例的執(zhí)行。順序圖中付款這個用例包括售票處與公用電話亭和信用卡服務(wù)處的兩個通信過在這個用例的順序圖中表達(dá)出來了。kjosk BoxOfficekjoskBoxOfficeCreditCardServiceShowAvailable(seat-list)SelectSeatsDemandPayment(cost)消息number,cost)authorizedprinttickets(performance,seats)ejectcard3–3順序圖協(xié)作圖（如圖3-4序用消息箭頭處的編號來說明。號傳遞過程?；リP(guān)系。請求從公用電話亭發(fā)出，要求從所有的演出中查找某次演出的資料。返回給ticketsellerdb代表了與某次演出資料的局部暫時鏈接，這個鏈接在交互過程中被聲明，其余座位解鎖。要選用這兩種圖。kjiosk主動對象1:request(count,perormance)st)kjiosk主動對象1:request(count,perormance)st),cost)鏈 被動對象<<local>>db暫時鏈消息2:db:=findDB(performance)多對象Gudiedbs3–4協(xié)作圖狀態(tài)機視圖狀態(tài)機視圖是一個類對象所可能經(jīng)歷的所有歷程的模型圖。狀態(tài)機由對象的各個狀態(tài)和與轉(zhuǎn)換相關(guān)的活動執(zhí)行時，轉(zhuǎn)換也同時發(fā)生。狀態(tài)機用狀態(tài)圖來表達(dá)。3–5Available狀態(tài)。在票開始對外出售前，也可以換其他演出的票，如果這樣的話，最初預(yù)約票也可以對外出售。生命期中跨越多個不同性質(zhì)階段的被動對象的行為，在每一階段該對象都有自己特殊的行為。初始狀態(tài)初始狀態(tài)assignedtotimeoutAvailablelock狀態(tài)LockedbuySoldunlock轉(zhuǎn)換exchange

觸發(fā)器事件3–5狀態(tài)圖活動視圖活動視圖用活動圖來體現(xiàn)。（這個例子僅供參考，不必太認(rèn)真地憑著看戲的經(jīng)驗而把問題復(fù)雜化。箭頭說明活動間的順序依賴關(guān)系—例排好整個劇目的進(jìn)度后，可以進(jìn)行宣傳報道、購買劇本、雇用演員、準(zhǔn)備道具、設(shè)計照明、加工戲服等，所有這些活動都可同時進(jìn)行。在進(jìn)行彩排之前，劇本和演員必須已經(jīng)具備。動的執(zhí)行行為，而不涉及建立協(xié)作圖所必須的消息傳送細(xì)節(jié)?；顒臃植鎝ublicizeshowbuyscriptandmusichireartistsdesignlighting 完成轉(zhuǎn)換dress結(jié)合perform3–6活動圖物理視圖類映射成物理構(gòu)件和節(jié)點的機制。物理視圖有兩種：實現(xiàn)視圖和部署視圖。實現(xiàn)視圖為系統(tǒng)的構(gòu)件建模型—構(gòu)件即構(gòu)造應(yīng)用的軟件單元—還包括各構(gòu)件之間的依賴關(guān)系，以便通過這些依賴關(guān)系來估計對系統(tǒng)構(gòu)件的修改給系統(tǒng)可能帶來的影響。和公用電話亭之間的接口、售票員與在線訂票系統(tǒng)之間的接口和監(jiān)督員查詢售票情況的接實際物理配置中，可能有某個構(gòu)件的多個備份。3–7構(gòu)件圖人票可以通過公用電話亭訂購也可直接向售票員購買，但購買團(tuán)體票只能通過售票員。設(shè)備或存儲器。這個視圖允許評估分配結(jié)果和資源分配。3–8是售票系統(tǒng)的描述層部署圖。圖中表示了系統(tǒng)中的各構(gòu)件和每個節(jié)點包含的構(gòu)件。節(jié)點用立方體圖形表示。圖3–8部署圖（描述層）3–9是售票系統(tǒng)的實例層部署圖。圖中顯示了各節(jié)點和它們之間的連接。這個模型3–8的描述層中的內(nèi)容相互對應(yīng)的。圖3–9部署圖（實例層）模型管理視圖（如類、狀態(tài)機和用例）構(gòu)成的(package)一個模型元素包含于包中或包含于其他模型元素中。的包。為一個單獨的構(gòu)件來實現(xiàn)。模型管理信息通常在類圖中表達(dá)。3–10顯示了將整個劇院系統(tǒng)分解所得到的包和它們之間的依賴關(guān)系。售票處子系包含了多個包。圖3–10包擴展組件UML包含三種主要的擴展組件：約束、構(gòu)造型和標(biāo)記值。約束是用某種形式化語言或命名的信息塊。UMLUML定義的元模型自身UML用戶定制版本。圖3–11舉例說明了約束、構(gòu)造型，和標(biāo)記值的使用。對劇目類的約束保證了劇目具有唯一的名稱。圖3–11說明了兩個關(guān)聯(lián)的異或約束，一個對象某一時刻只能具有兩個關(guān)UML的概念不直接支持文字描述。名的構(gòu)造型定義一個圖標(biāo)，作為可視化的輔助工具。盡管如此，可以使用文字形式說明。SchedulingFrankMartin要在年底世紀(jì)前完成計劃的制定。可以將任常沒有標(biāo)記值。3–11擴展組件各種視圖間的關(guān)系3-2中。3-2不同視圖元素間的部分關(guān)系元素 元素 關(guān)系類 擁有 狀態(tài)機操作 交互 實現(xiàn)用例 合作 實現(xiàn)用例 交互實例 樣本場景構(gòu)件實例 節(jié)點實例 位置動作 操作 調(diào)用動作 信號 發(fā)送活動 操作 調(diào)用消息 動作 激發(fā)包 類 擁有角色 類 分類第4概述網(wǎng)絡(luò)訂票和冗余信息等。立的對象結(jié)構(gòu)中。靜態(tài)視圖包括所有的傳統(tǒng)數(shù)據(jù)結(jié)構(gòu)思想，同時也包括了數(shù)據(jù)操作的組織。數(shù)據(jù)和操作都可量化為類。根據(jù)面向?qū)ο蟮挠^點，數(shù)據(jù)和行為是緊密相關(guān)的。比如，Ticket留這張票或以一定折扣計算它的價格。動態(tài)交互的事物—如果不首先說清楚什么是交互作用，就無法說清楚交互作用怎樣進(jìn)行的。靜態(tài)視圖是建立其他視圖的基礎(chǔ)。實現(xiàn)目的位于像子系統(tǒng)、構(gòu)件和節(jié)點這幾種類元之后。并且使用時或多或少地獨立于其他的模型—這是掌握描述系統(tǒng)的更細(xì)節(jié)的包的基礎(chǔ)。個體。類元之間的關(guān)系有關(guān)聯(lián)、泛化及各種不同的依賴關(guān)系，包括實現(xiàn)和使用關(guān)系。類元類元功能 表示法參與者系統(tǒng)的外部用戶 4–1類元功能 表示法參與者系統(tǒng)的外部用戶 類模型系統(tǒng)中的概念 name狀態(tài)類局限于某個給定狀態(tài)的類 Name[S]類元角色在合作中局限于某個使用的類元 roleName構(gòu)件系統(tǒng)的一個物理組成單元數(shù)據(jù)類型接口無身份得一組原始值的描述符 Name刻劃行為特征的操作命名集 Iname節(jié)點計算資源信號對象間的異步通信 <<Signal>>子系統(tǒng)作為且有規(guī)范、實現(xiàn)和身份的單元的包<<subsystem>>用例與外界代理交互中的實體行為說明表4–1各種類元類類代表了被建模的應(yīng)用領(lǐng)域中的離散概念—物理實體（如飛機、商業(yè)事物（如一份訂單、邏輯事物（如廣播計劃、應(yīng)用事物（如取消鍵、計算機領(lǐng)域的事物（如哈希表）或行為事物（如一項任務(wù)。類是有著相同結(jié)構(gòu)、行為和關(guān)系的一組對象的描述符號。所用的屬性與操作都被附在類或其他類元上。類是面向?qū)ο笙到y(tǒng)組織結(jié)構(gòu)的核心。類是用來理解和描述眾多個別對象的個別概念。4–1所示。Subscriptionseries:StringSubscriptionseries:StringpriceCategory:Categorynumber:Integercost():moneyreserve(series:String,level:SeatLevel)cancel()操作圖4–1類表示法零個或多個父類（超類）和零個或多個后代（子類。一個類從它的雙親和祖先那里繼承狀態(tài)和行為描述，并且定義它的后代所繼承的狀態(tài)和行為描述。類。類對它的包含者來說是可見性，可見性說明它如何被位于它的可見者之外的類所利用。（零個或多個，沒有明確限制接口類都可以實現(xiàn)接口中的操作。數(shù)據(jù)類型不改變數(shù)據(jù)值，但是可以把數(shù)據(jù)值作為結(jié)果返回。含義分層法這些實現(xiàn)方面的概念與真實世界的概念無關(guān)（它們是設(shè)計層的概念。分析層的類代表了及到執(zhí)行和構(gòu)造的情況下，充分說明系統(tǒng)的必要邏輯組成。能。設(shè)計層類包含真實世界和計算機系統(tǒng)兩方面的內(nèi)容。不能直接用語言來實現(xiàn)，那么不得不放棄它們。實現(xiàn)層類直接與程序代碼相對應(yīng)。實現(xiàn)類表示用特定程序設(shè)計語言聲明一個類，它得到了一個按照語言所要求的準(zhǔn)確格式的類。然而，在許多情況下，分析、設(shè)計和實現(xiàn)信息可嵌套在一個單獨的類中。關(guān)系（參見表4–2?；プ饔玫倪B接。其余的關(guān)系涉及到類元自身的描述，而不是它們的實例。（們共有的關(guān)系，而不用重復(fù)說明。現(xiàn)的結(jié)構(gòu)。一個或多個類可以實現(xiàn)一個接口，而每個類分別實現(xiàn)接口中的操作。對象的不同版本）和拷貝（從現(xiàn)有對象創(chuàng)造出一個新的對象）兩種。賴關(guān)系，包括跟蹤關(guān)系（不同模型中元素之間的一種松散連接、精化關(guān)系（兩個不同層次數(shù)指定值。使用依賴關(guān)系經(jīng)常被用來表示具體實現(xiàn)間的關(guān)系，如代碼層實現(xiàn)關(guān)系。在概括的約束可通過依賴關(guān)系來表示。表4–2關(guān)系的種類關(guān)系 功能 表示法關(guān)聯(lián) 類實例之間連接的描述依賴 兩個模型元素間的關(guān)系流 在相繼時間內(nèi)一個對象的兩種形式的關(guān)系泛化 更概括的描述和更具體的種類間的關(guān)系，適用于繼承實現(xiàn) 說明和實現(xiàn)間的關(guān)系使用 一個元素需要別的元素提供適當(dāng)功能的情況關(guān)聯(lián)含一對對象。立的類。一個類在一個關(guān)聯(lián)中出現(xiàn)兩次，那么兩個實例就不必是同一個對象，通常的情況都如此。一個類的關(guān)聯(lián)的任何一個連接點都叫做關(guān)聯(lián)端，與類有關(guān)的許多信息都附在它的端點n4–2所示，連線上有相互關(guān)聯(lián)的角色名而多重性則加在各個端點上。Priority

關(guān)聯(lián)名0..1*0..1*ReservationSubscription0..1

自身關(guān)聯(lián)0..1previoussource角色名tickets

多重性參與類圖4–2關(guān)聯(lián)表示法（如圖4–（圖4-4字和身份代碼是很重要的，同時它也是設(shè)計模型的索引。參與類*參與類*donor*關(guān)聯(lián)類所有為一元素關(guān)聯(lián)屬性DonationLevelyearAmount:MoneylifeAmount:MoneyPersonOrganziation4–3關(guān)聯(lián)類

Showperformance:DateShowperformance:Dateseat:SeatNumbersaleTicket0..1

限定關(guān)聯(lián)限定屬性

限多重性圖4–4限定關(guān)聯(lián)C++4–5表示了一些關(guān)聯(lián)的設(shè)計特性。AddressPersonaddressAddressPerson11導(dǎo)航TransactionEntryhistoryTransactionEntry定序?qū)傩?修改屬性圖4–5關(guān)聯(lián)的設(shè)計特性1.1.聚集和組成合在一起，現(xiàn)在整組關(guān)聯(lián)就像一棵樹。圖4–6表示了聚集關(guān)聯(lián)和組成關(guān)聯(lián)。11LineItem11LineItem1OrderSubscription**Performance*部分 部分圖4–6聚集和組成2.2.鏈的實例或此類后代的實例。系統(tǒng)中的鏈組成了系統(tǒng)的部分狀態(tài)。鏈并不獨立于對象而存在，它們從與之相關(guān)的對象中得到自己的身份（在數(shù)據(jù)庫術(shù)語中，對象列表是鏈的鍵。在概念為與其相連的類分離的包含體對象來實現(xiàn)。3.3.雙向性（語不能互換一樣。關(guān)聯(lián)有時被認(rèn)為是雙向性的，這意味著邏輯關(guān)系在兩個方向上都起作用。這個觀點經(jīng)常被錯誤理解，甚至包括一些方法學(xué)家。這并不意味著每個類“了解”其他類，就被認(rèn)為有導(dǎo)航性。泛化父而抵押則是子。泛化在類元（類、接口、數(shù)據(jù)類型、用例、參與者、信號等等、包、狀態(tài)機和其他元素中使用。在類中，術(shù)語超類和子類代表父和子。泛化用從子指向父的箭頭表示，指向父的是一個空三角形（如圖4–7表示。多個泛OrderdateOrderdate:DateConfirm()超類(文)抽象操作BoxOfficeOrderholdBoxOfficeOrderhold:BooleanConfirm()MailOrderdateFilled:DateConfirm()子類(類)圖4–7泛化表示法泛化的用途泛化有兩個用途。第一個用途是用來定義下列情況：當(dāng)一個變量（如參數(shù)或過程變量）BarbaraLiskov提出。該原則表明無論何時祖先被聲明了，則后代的一個實例可以被使用。例如，如果一個變量被聲明擁有借貸，那么一個抵押對象就是一個合法的值。作的實現(xiàn)。這種不完整操作是抽象的（其名稱用斜體表示。似的方法起作用。繼承有祖先的可繼承的特性。它的完整特性包括繼承特性和直接聲明的特性。的接口一致（（其中的一種方法。我們發(fā)現(xiàn)如果在后代類中重新定義方法會更簡單、安全。元素中的約束是元素本身及它所有祖先的約束的聯(lián)合體，如果它們存在不一致，那么模型形式錯誤。定義或從祖先那里繼承而來的。多重繼承如果一個類元有多個父類，那么它從每一父類那里都可得到繼承信息（如圖4-8（決原則要安全，而這些原則經(jīng)常使開發(fā)者大吃一驚。父confirm()date:Date父confirm()date:DateReservation父stamp()received:Time子類不需要新特性

父類的屬性和操作圖4–8多重繼承單分類和多重分類—多重繼承可以免去再聲明一個新類，這可提高效率。靜態(tài)與動態(tài)類元新對象一樣。態(tài)類有時被稱作角色或類型。一個常見的建模模式是每個對象有一個唯一的靜態(tài)的固有類（映射到關(guān)聯(lián)上。實現(xiàn)接聲明。雖然實現(xiàn)關(guān)系意味著要有像接口這樣的說明元素，它也可以用一個具體的實現(xiàn)元式和一個簡單低效的形式之間的關(guān)系。連接起來（素連接起來（系與具體類是不相關(guān)的。（–9（–10。圖4–9實現(xiàn)關(guān)系接口接口名

Sub 類mitJobmitJob實現(xiàn)kStatusPrinterServerSetPrintProperties圖4–10接口和實現(xiàn)圖標(biāo)依賴賴關(guān)系中客戶的變化。4–3UML基本模型中的一些依賴關(guān)系。依賴關(guān)系

功能 關(guān)鍵字訪問 允許一個包訪問另一個包的內(nèi)容 access綁定 為模板參數(shù)指定值，以生成一個新的模型元素 bind調(diào)用 聲明一個類調(diào)用其他類的操作的方法 call派生聲明一個實例可以從另一個實例導(dǎo)出 derive友員允許一個元素訪問另一個元素，不管被訪問的元素是否具有可見性friend輸入允許一個包訪問另一個包的內(nèi)容并為被訪問包的組成部分增加別名import實例化 關(guān)于一個類的方法創(chuàng)建了另一個類的實例的聲明 instantiate參數(shù) 一個操作和它的參數(shù)之間的關(guān)系 parameter實現(xiàn) 說明和對這個說明的具體實現(xiàn)之間的映射關(guān)系 realize精化 聲明具有兩個不同語義層次上的元素之間的映射 refine發(fā)送 信號發(fā)送者和信號接收者之間的關(guān)系 send跟蹤 聲明不同模型中的元素之間存在一些連接，但不如映射精確 trace使用 的另一個模型元素這樣才能正確實現(xiàn)使用者的功能（包括了調(diào)用、實例化、參數(shù)、發(fā)送）

use4–3依賴關(guān)系種類的模型所起的變化。精化是表示位于不同的開發(fā)階段或處于不同的抽象層次中的一個概念的兩種形式之間可預(yù)知的方式發(fā)生相互關(guān)系。導(dǎo)出表示一個元素可以通過計算另一個元素來得到(而被導(dǎo)出的元素可以被明確包含在系統(tǒng)中以避免花費太多代價進(jìn)行迭代計算)。導(dǎo)出、實現(xiàn)、精化和跟蹤是抽象的依賴—它們將同一個潛在事物的不同形式聯(lián)系起來。系統(tǒng)的一部分（如，使用預(yù)定義的構(gòu)件或函數(shù)庫。特別的使用關(guān)系可以被詳細(xì)說明，但是因為關(guān)系的目的就為了突出依賴，所以它常常被忽略。確切的細(xì)節(jié)可以從實現(xiàn)代碼中獲得。個類的方法創(chuàng)建了另一個類的實例。若干種使用依賴允許某些元素訪問其他元素。訪問依賴允許一個包看到另一個包的內(nèi)員依賴是一種訪問依賴，允許客戶看到提供者的私有內(nèi)容。必須連接模型同一層的元素（或者都是分析層，或者都是設(shè)計層，并且在同一抽象層。跟蹤和精化依賴更模糊一些，可以將不同模型或不同抽象層的元素連接起來。（（如對象（如類）的實例。依賴用一個從客戶指向提供者的虛箭頭表示，用一個構(gòu)造型的關(guān)鍵字來區(qū)分它的種類，4–11所示。依賴類型關(guān)鍵字BoxOffice<<use>>SchedulingEngine依賴客戶4–11依賴

提供者約束UML以模型元素圖的形式為建模系統(tǒng)提供一組概念和關(guān)系，而它們中的一些用文字表OLO入門》和[Warmer-99]等書。在特性（XC條件成立）和通用特性（對于YyD必須成立。詳見第1寫成注釋或附加在依賴關(guān)系的箭頭旁。圖4–12表示了一些約束。圖4–12約束關(guān)系實例個值，隨著對實例進(jìn)行操作值也會被改變。立在其上的各種動態(tài)視圖定義了系統(tǒng)的結(jié)構(gòu)和行為。分類對象可能是多個類的直接實例。同樣，鏈?zhǔn)顷P(guān)聯(lián)的實例，數(shù)值是數(shù)據(jù)類型的實例。束（其中既包括明確的約束又包括如多重性的內(nèi)嵌的約束。的所有約束，則說明系統(tǒng)的狀態(tài)是有效的系統(tǒng)實例。出現(xiàn)。某些快照可能在靜態(tài)下合法但在系統(tǒng)的動態(tài)圖下可能不會被動態(tài)地達(dá)到。UML的行為部分描述了快照的有效順序，快照可能作為部和內(nèi)外部行為影響的結(jié)果出現(xiàn)。動態(tài)圖定義了系統(tǒng)如何從一個快照轉(zhuǎn)換到另一個快照。對象圖圖4-13視圖中定義，且建立定義視圖是建模和設(shè)計的目標(biāo)。靜態(tài)視圖描述了可能出現(xiàn)的實例。除了樣本外，實際的實例不總是直接在模型中出現(xiàn)。4–13對象圖第5概述與一個或多個參與者之間的一系列消息來描述系統(tǒng)中的交互作用。參與者可以是人,也可以5–1表述了一個電話目錄銷售的用例視圖。此例是實際系統(tǒng)簡化后的例子。5–1用例圖參與者者的不同實例。用例所在的系統(tǒng)或類發(fā)生了交互作用被一組定義它的狀態(tài)的屬性充分描述。參與者可以通過泛化關(guān)系來定義,在這種泛化關(guān)系中，一個參與者的抽象描述可以被一個或多個具體的參與者所共享。寫在下面的小人表示。用例用例是外部可見的一個系統(tǒng)功能單元,這些功能由系統(tǒng)單元所提供,并通過一系列系統(tǒng)單準(zhǔn)行為的不同變形、一般行為下的所有異常情況及其預(yù)期反應(yīng)。從用戶角度來看,上述情況很可能是異常情況；從系統(tǒng)角度來看,它們是必須被描述和處理的附加情況。在模型中,每個用例的執(zhí)行獨立于其他用例，雖然在具體執(zhí)行一個用例功能時由于用例一個用例都是一個縱向的功能塊，這個功能塊的執(zhí)行會和其他用例的執(zhí)行發(fā)生混雜。個協(xié)作，因此也參與了多個用例。系統(tǒng)內(nèi)其他有特殊作用的類的。一個類可以有多個用例。每個用例必須與實現(xiàn)系統(tǒng)的類相映射。用例的行為與類的狀態(tài)轉(zhuǎn)換和類所定義的操作相對色所涉及的用例功能。用例功能靠類間的協(xié)作來實現(xiàn)。（如表–1。關(guān)系 功能 表示法關(guān)聯(lián) 參與者與其參與執(zhí)行的用例之間的通信途徑擴展 在基礎(chǔ)用例上插入基礎(chǔ)用例不能說明的擴展部分

<<extend>>用例泛化 用例之間的一般和特殊關(guān)系，其中特殊用例繼承了 一般用例的特性并增加了新的特性包括 在基礎(chǔ)用例上插入附加的行為，并且具有明確的描述

<<include>>表5–1用例之間的關(guān)系5–2，用例用一個名字在里面的橢圓表示，用例和與它通信的參與者之間用實線連接。圖5–2用例之間的關(guān)系種情況下，新用例不是初始用例的一個特殊例子，而且不能被初始用例代替。一個用例也可以被定義為基用例的增量擴展,這叫做擴展關(guān)系。同一個基用例的幾個擴,此時是本用例而不是擴展用例被作為例子使用。包含和擴展關(guān)系可以用含有關(guān)鍵字<<include>>和<<extend>>的帶箭頭的虛線表示。包含關(guān)系箭頭指向被包含的用例，擴展關(guān)系箭頭指向被擴展的用例。使用時，任何子用例也可以被使用。5–2表示了銷售中的用例關(guān)系。第6概述件表示對象可以探測到的事物的一種運動變化—如接受到從一個對象到另一個對象的調(diào)用所發(fā)生的事物的模型通過從外部世界到系統(tǒng)的信號來建造的。狀態(tài)是給定類的對象的一組屬性值,這組屬性值對所發(fā)生的事件具有相同性質(zhì)的反應(yīng)。鍵做出不同的反應(yīng)。被其他元素所直接應(yīng)用。狀態(tài)機行過程。狀態(tài)機是一個類的對象所有可能的生命歷程的模型。對象被孤立地從系統(tǒng)中抽出和考行為建立模型。用戶接口和設(shè)備控制器這樣的控制機。事件6–1是幾種事件類型及其描述。事件類型描述語法調(diào)用事件接受等待應(yīng)答的對象的明確形式的同步請求op(a:T)改變事件對布爾表達(dá)式值的修改When(exp)信號事件Sname(a:T)時間事件絕對時間的到達(dá)或者相對時間段的終結(jié)After(time)表6–1事件的種類1.信號事件以是同一個對象。信號可以在類圖中被聲明為類元，并用關(guān)鍵字《signal》表示，信號的參數(shù)被聲明為屬的參數(shù)，并且可以觸發(fā)依賴于父信號的轉(zhuǎn)換（如圖6–1所示。圖6–1信號的等級組織UML參考手冊UML參考手冊PAGEPAGE1002.調(diào)用事件不是用方法來實現(xiàn)操作就是觸發(fā)一個狀態(tài)轉(zhuǎn)換來實現(xiàn)這個操作。操作的參數(shù)即事件的參數(shù)。一旦調(diào)用的接收對象通過由事件觸發(fā)的轉(zhuǎn)換完成了對調(diào)用事件的處理或調(diào)用失敗而沒有進(jìn)繼續(xù)它自己的執(zhí)行過程，與調(diào)用者處于并行狀態(tài)。3.修改事件是涉及全局的計算過程（是一種遠(yuǎn)距離的動作，因為被測試的值可能是遠(yuǎn)距離的。這既有更明確表達(dá)形式的通信形式顯得不自然時。被再賦值。而修改事件被多次賦值直到條件為真，這時轉(zhuǎn)換也會被激發(fā)。4.時間事件（天數(shù)為相對形式（從某一指定事件發(fā)生開始所經(jīng)歷的時間。在高層模型中，時間事件可以被認(rèn)可能是操作系統(tǒng)也可能是應(yīng)用中的對象。狀態(tài)有名字。觸發(fā)狀態(tài)轉(zhuǎn)換的觸發(fā)器事件很敏感。6-2所示。Credit圖6–2狀態(tài)轉(zhuǎn)換義一個轉(zhuǎn)換要有引起轉(zhuǎn)換的觸發(fā)器事件、監(jiān)護(hù)條件、轉(zhuǎn)換的動作和轉(zhuǎn)換的目標(biāo)狀態(tài)。表6–2列出了幾種轉(zhuǎn)換和由轉(zhuǎn)換所引起的隱含動作。轉(zhuǎn)換的種類 描述 語法入口動作 進(jìn)入某一狀態(tài)時執(zhí)行的動作 entry/action出口動作 離開某一狀態(tài)時執(zhí)行的動作 exit/action外部轉(zhuǎn)換 包括引起入口動作和出口動作被執(zhí)行的轉(zhuǎn)換內(nèi)部轉(zhuǎn)換 引起一個動作的執(zhí)行但不引起狀態(tài)的改變或不引起入口動作或出口動作的執(zhí)行

表6–2轉(zhuǎn)換的種類及隱含動作1.外部轉(zhuǎn)換態(tài)的箭頭表示，其他屬性以文字串附加在箭頭旁（如圖6–3所示。圖6–3外部轉(zhuǎn)換2.觸發(fā)器事件MouseButton作為eutonDwn（如圖6–。換前或處延遲被解除前，這類事件被保存起來。如果兩個事件同時發(fā)生，它們被每次處理件要比詳細(xì)指明所有事件容易得多。3.監(jiān)護(hù)條件一個事件的發(fā)生只能同時引起一個轉(zhuǎn)換（在一個控制線程中。如果一個事件可能引起多個生了哪個轉(zhuǎn)換。這兩個轉(zhuǎn)換隨機地發(fā)生一個，或者由系統(tǒng)的實現(xiàn)細(xì)節(jié)決定究竟發(fā)生哪一個，但是對建模者來說，無法預(yù)料這種轉(zhuǎn)換產(chǎn)生的后果。4.完成轉(zhuǎn)換沒有標(biāo)明觸發(fā)器事件的轉(zhuǎn)換是由狀態(tài)中的活動的完成引起的（即完成轉(zhuǎn)換。完成轉(zhuǎn)換也可以帶一個監(jiān)護(hù)條件，這個監(jiān)護(hù)條件是在狀態(tài)中的活動完成時被賦值的（而不是完成以后。5.動作過程，通常是一個賦值操作或算術(shù)計算。另外還有一些動作，包括給另一個對象發(fā)送消息、實際上任何動作的執(zhí)行都要耗費一定時間，新到來的事件必須被安置在一個隊列中。性的。一旦開始執(zhí)行，它必須執(zhí)行到底并且不能與同時處于活動狀態(tài)的動作發(fā)生交互作用。作的執(zhí)行過程應(yīng)該很簡潔，否則系統(tǒng)不能夠做到實時響應(yīng)。表6–3列出了各種動作及描述。動作種類描述語法賦值對一個變量賦值target:=expression表6–3動作的種類6.狀態(tài)改變當(dāng)動作執(zhí)行完畢后，轉(zhuǎn)換的目標(biāo)狀態(tài)被激活，這時會觸發(fā)出口動作或入口動作的執(zhí)行。7.嵌套狀態(tài)狀態(tài)可以被嵌套在其他的組成狀態(tài)之內(nèi)（看下一段。從一個外部狀態(tài)出發(fā)的轉(zhuǎn)換可以要每個嵌套狀態(tài)顯式地單獨處理異常。8.入口和出口動作態(tài)的出口動作。態(tài)內(nèi)的動作在執(zhí)行前都可以假定狀態(tài)的初始化工作已經(jīng)完成，不需要考慮如何進(jìn)入這個狀況以使對象的狀態(tài)保持前后一致。入口動作和出口動作原則上依附于進(jìn)來的和出去的轉(zhuǎn)換，但是將它們聲明為特殊的動作可以使?fàn)顟B(tài)的定義不依賴狀態(tài)的轉(zhuǎn)換，因此起到封裝的作用。9.內(nèi)部轉(zhuǎn)換信息屏。entryexit法。64口動作、出口動作和內(nèi)部轉(zhuǎn)換。圖6–4內(nèi)部轉(zhuǎn)、入口動作和出口動作組成狀態(tài)6–4列出了各種狀態(tài)。表6–4狀態(tài)的種類態(tài)。外部狀態(tài)表達(dá)了每一個內(nèi)部狀態(tài)都具有的條件。（最外層最先執(zhí)行）和出口動作（最內(nèi)層最先執(zhí)行義，使?fàn)顟B(tài)的定義與進(jìn)出狀態(tài)的轉(zhuǎn)換無關(guān)。模型。6–5狀態(tài)機6–6展示了選修一門大學(xué)課程的并發(fā)分解。6-5狀態(tài)機6–6帶有并發(fā)組成狀態(tài)的狀態(tài)機圖6–7子機器狀態(tài)6-7器，需要在子機器引用狀態(tài)中安置一個或多個樁狀態(tài)。樁狀態(tài)用于在子機器中標(biāo)識狀態(tài)。第7概述的過程中沒有外部事件引起的中斷，否則，普通的狀態(tài)機更適于描述這種情況?；顒訝顟B(tài)會異常終止。處于活動狀態(tài)時不允許發(fā)生轉(zhuǎn)換。動作狀態(tài)通常用于短的記帳操作。表達(dá)并發(fā)流程控制，如果排除了這一點，活動圖很像一個傳統(tǒng)的流程圖?；顒訄D活動圖是活動視圖的表示法（如圖7-1。它包括一些方便的速記符號，這些符號實際上可以用于任何狀態(tài)圖，盡管活動圖和狀態(tài)圖的混合表示法多數(shù)時候都很難看。7–1表示訂單處理的活動圖。7–1活動圖在等待某信號的一個特殊內(nèi)嵌符號。發(fā)送可同樣表示。然而，如果有許多事件驅(qū)動的轉(zhuǎn)換，那么用一個普通的狀態(tài)圖表示更可取。1.泳道7–2表示了泳道。圖7–2泳道和對象流2.對象流符號。7–2表示一個活動和對象流狀態(tài)都被分配到泳道中的活動圖?；顒雍推渌麍D協(xié)的設(shè)計工作。第8概述以獨立的對象為中心進(jìn)行考察，另一種以互相作用的一組對象為中心進(jìn)行考察。關(guān)系的模型。協(xié)作協(xié)作描述了在一定的語境中一組對象以及用以實現(xiàn)某些行為的這些對象間的相互作用。它描述了為實現(xiàn)某種目的而相互合作的“對象社會靜態(tài)視圖描述了類固有的內(nèi)在屬性。例如，Vehicle需要有一個所有者。協(xié)作圖描述了類實例的特性，因為它在協(xié)作中起特殊的作用，例如，在一個RentalCar的協(xié)作中，rentalVehiclerentalDriver，它通常與交通工具不直接相關(guān)但它是協(xié)作的基本部分。hotelGuest。不經(jīng)常出現(xiàn)的情況是一個對象在同一個協(xié)作中可能擔(dān)當(dāng)多個角色。個交互，每個交互描述了一系列消息，協(xié)作中的對象為了達(dá)到目標(biāo)交換這些消息。中的三個主要結(jié)構(gòu)的統(tǒng)一，即數(shù)據(jù)結(jié)構(gòu)、控制流和數(shù)據(jù)流的統(tǒng)一。交互執(zhí)行、用例或其他行為實體建模。有返回控制機制的操作的同步調(diào)用。可行的。步通過不同線程間消息的約束建模。同步結(jié)構(gòu)能夠?qū)Ψ植婵刂?、結(jié)合控制和分支控制建模。息的對象間的關(guān)系。順序圖虛線表示，當(dāng)對象的過程處于激活狀態(tài)時，生命線是一個雙道線。上到下排列。圖8–1為帶有異步消息的典型的順序圖。8–1順序圖激活8–2為含有過程控制流的一個順序圖，包括一個遞歸調(diào)用和一個對象的創(chuàng)建。在被調(diào)用時接受控制，而當(dāng)它們返回時將控制放棄。在一個單獨的圖中最好不要混合使用過程調(diào)用和信號。圖8–2帶有激活的順序圖合作圖關(guān)聯(lián)角色描述了對象的配置和當(dāng)一個協(xié)作的實例執(zhí)行時可能出現(xiàn)的連接。當(dāng)協(xié)作被實例化或《local）或調(diào)用同一個對象《self。雖然整個系統(tǒng)中可能有其他的對象，但只有涉及8-3為一個交互圖。8–3合作圖（使用約束w（roe；在交互作用中創(chuàng)建并銷使用約束ra決定控制如何流向圖中正確的對象去實現(xiàn)操作。視圖可以通過描述對象所有操作的協(xié)作的聯(lián)合來構(gòu)造。1.1.消息不同線程內(nèi)的消息是并行的。各種實現(xiàn)的細(xì)節(jié)會被加入，如同步與異步消息的區(qū)別。2.2.流次有不同的位置和狀態(tài)。個的轉(zhuǎn)換。它用帶有構(gòu)造型《become》的箭頭表示，并且可以用順序號標(biāo)記表示它何時出現(xiàn)（如圖–4構(gòu)造型《copy》不經(jīng)常出現(xiàn)，它表示通過拷貝另一個對象值而得到的一個對象值。表8–1表示了幾種對象流的關(guān)系。圖8–4變成流流功能表示法變成拷貝從一個對象值變化到另一個對象值拷貝一個對象，從此以后，該對象為獨立對象<<become>><<copy>>8–1流關(guān)系的種類3.3.協(xié)作圖與順序圖設(shè)計。模板際類或受限于更大的協(xié)作中的角色。8-5handler角色?，F(xiàn)的結(jié)構(gòu)的一種方法。圖8–5表示了Observer模板的使用。圖8–5模板的使用第9概述兩種視圖來表示實現(xiàn)單元：實現(xiàn)視圖和部署視圖。例如類）的具體實現(xiàn)。構(gòu)件是系統(tǒng)高層的可重用的組成部件。出執(zhí)行過程中的瓶頸。構(gòu)件統(tǒng)設(shè)計中特定類的實現(xiàn)。良好定義的構(gòu)件不直接依賴于其他構(gòu)件而依賴于構(gòu)件所支持的接口。在這種情況下，系統(tǒng)中的一個構(gòu)件可以被支持正確接口的其他構(gòu)件所替代。形式，一種是含有依賴關(guān)系的可用構(gòu)件（構(gòu)件庫）的集合，它是構(gòu)造系統(tǒng)的物理組織單元。與給它提供服務(wù)的其他構(gòu)件連接，這些連接必須與構(gòu)件的接口要求相符合。（如圖9–。（9–2支持構(gòu)件替代。圖9–1帶接口構(gòu)件9–2構(gòu)件圖節(jié)點CPU、設(shè)備和內(nèi)存等。節(jié)點可以包含對象和構(gòu)件實例。9–3部署圖可選（如圖9–3。節(jié)點也有泛化關(guān)系，將節(jié)點的一般描述與具體的特例聯(lián)系起來。以表示出來。第10概述分別處理這些信息的工作組之間不會互相干擾。模型管理由包及包之間的依賴關(guān)系組成。包現(xiàn)和公用觀點等。UML對如何組包并不強制使用什么規(guī)則，但是良好的解組會很大地增強模型的可維護(hù)性。素的“家”包。可能被別的包引用，但是其所有權(quán)屬于家包。在一個好的配置控制系統(tǒng)中，建模者必須能夠?qū)野M(jìn)行訪問以修改元素的內(nèi)容，這為處理大的模型提供了訪問控制機制。包也是任何版本出版機制的單元。模型中一般之間的依賴關(guān)系組合而成。包之間的依賴關(guān)系概述了包的內(nèi)容之間的依賴關(guān)系。包間的依賴關(guān)系系導(dǎo)出。一個存在聲明不包含任何更深的信息，它僅僅是一個概要。中兩種方法有它們自己的地位，即使是在單個的系統(tǒng)中也是這樣。獨立元素之間屬于同一類別的多個依賴關(guān)系被聚集到包間的一個獨立的包層依賴關(guān)系用在依賴關(guān)系，子系統(tǒng)和的任何一個實現(xiàn)都將只包括其中一個變。10-1包和包間的關(guān)系訪問與引入依賴關(guān)系也可用于類的內(nèi)容（屬性和操作。一個類的后代可以看到它的祖先中具有公共或受保護(hù)可素，則第一個包必須訪問或引入第二個包，且目標(biāo)元素在第二個包中必須有公共可見性。起來。予建立引用的權(quán)限。引入依賴關(guān)系用來將名字加入到客戶包的名字域作為路徑名的別名。模型和子系統(tǒng)連接的存在，是不同模型的元素之間的一種較弱形式的依賴關(guān)系，它不用特殊的語義說明。出發(fā)的系統(tǒng)的所有細(xì)節(jié)。（如圖1-1。第11概述義。UML擴展機制包括約束、標(biāo)記值和構(gòu)造型。擴展機制之前，建模者應(yīng)該仔細(xì)權(quán)衡它的好處和代價，特別是當(dāng)現(xiàn)有機制能夠合理工作時。言的優(yōu)點和缺點。約束以是正式的數(shù)學(xué)符號，如set-theoretic表示符號；或是一種基于計算機的約束語言，如OCL；或是一種編程語言，如C++；或是偽代碼或非正式的自然語言。當(dāng)然，如果這種語言表示，也不意味著它自動為有效約束。UML元素的條件時約束特別有用。11-111-1約束標(biāo)簽值特性的名字，而值是給定元素的特性的值。例如，標(biāo)記可以是author，而值是對元素負(fù)責(zé)CharlesBabbage。（這是因為標(biāo)記和屬性在一起會被認(rèn)為是一個元素的屬性并且可以被工具一起訪問14。用哪種實現(xiàn)方式。其他標(biāo)記可為加入工具使用，如項目計劃生成器和報表書寫器。（我們將在下面討論。（如圖11-211-2標(biāo)簽值構(gòu)造型素的關(guān)系上和它們的使用上有特殊的約束。用途工具自動地確定，但是它們可以被用手動執(zhí)行或被理解構(gòu)造型的加入工具確定。素的符號。11-3構(gòu)造型味著應(yīng)用域的用戶可以使建模語言適應(yīng)應(yīng)用域的需要，還能夠共享在所有領(lǐng)域中通用的概念。第12UML環(huán)境概述UMLUML語義職責(zé)到它。對此有興趣的讀者可以參閱配套光盤上的原始標(biāo)準(zhǔn)文獻(xiàn)[UML-98]?？梢允褂?。劃定支持模型片段的界限和支持結(jié)構(gòu)不完善的模型用哪種語義。UMLUML，UML義的擴展。不論是否支持?jǐn)U展，任何擴展的使用都會使用戶偏離語言標(biāo)準(zhǔn)所提供標(biāo)準(zhǔn)定義，并損害模型的互換性和易理解性。當(dāng)然，使用特殊的類庫也會偏離所謂的最完美的互換性，所以不用擔(dān)心這些。當(dāng)擴展有幫助時就使用，但當(dāng)擴展不必要時則避免使用它。表示法職責(zé)經(jīng)常為用戶加入一些內(nèi)在涵義，如在一張圖中基于相近意義的兩個概念的密切聯(lián)系。UML文檔[UML-98]和本書定義了一套規(guī)范的UML刷格式中，但在使用交互式工具中也應(yīng)該采用合理的擴展。有自己的圖標(biāo)。對其他的表示法的擴展也是允許的，但用戶要謹(jǐn)慎使用這些擴展機制。程序語言職責(zé)UML必須在沒有與不同的實現(xiàn)語言明確地合并時與它們共同使用。我們認(rèn)為UMLUML理方法（如果能夠處理這些語義。一個問題。應(yīng)使用適合于你的目標(biāo)語言的語義模型。這是語義變更點的一個例子。UMLUMLUML沒有一種標(biāo)準(zhǔn)化的實際設(shè)置方法。目前不同的工具均使用對自己有競爭優(yōu)勢的代碼生成器，但最終將會出現(xiàn)缺省設(shè)置并發(fā)展為成熟的標(biāo)準(zhǔn)。使用建模工具建模在的資料，工具有助于在大型模型中查找信息。工具問題UML必須予以考慮。＊二義性和未詳盡說明的信息在初期階段，許多事物不能用語言表達(dá)。工具必須能夠調(diào)整模型的精確性并且不能強迫每個值都要進(jìn)行詳細(xì)說明?？蓞⒖匆韵聝尚」?jié)。＊表示選項用戶不想在任何時候都看到所有的信息。工具必須能夠過濾和隱藏那些12.3UML對于軟件工程過程十分重要，并且位于元模型的上層。＊與其他工具的接口模型需要由代碼生成器、規(guī)格計算機、報表書寫器、執(zhí)行引擎適合保存這些信息。工作進(jìn)展過程中產(chǎn)生的不一致模型作?？罩岛臀丛敿?xì)說明的值小是無限的，所以具有空值與否實際上取決于一種數(shù)據(jù)類型的可能值的范圍。UML第三部分 參考資料第13抽象

(concrete)。見抽象操作(abstractoperation)，可泛化元素(generalizableelement)。語義不完整的一個抽象的葉類是沒用的（它可以作為葉在框架中出現(xiàn)，但是最終它必須被說明。（具體操作可以只使用聲明它們的類所知道的特征（屬性和操作。繼承的目的之一即將一個或多個未實現(xiàn)操作的類自然是抽象的。分解公用的行為，模型變得更小和易