2023年統(tǒng)一建模語言UML簡介

第３章統(tǒng)一建模語言UML簡介本章目錄TOＣ\o"1-3"\h\z\ｕHYPＥＲＬＩNＫ\l＂_Toc"第3章統(tǒng)一建模語言ＵMＬ簡介 PＡGERＥF_Toc\h13．1ＵML概述?PAGEREＦ＿Tｏc＼h１ＨYＰＥRLＩNK3．２.1ＵML的體系結(jié)構(gòu) PＡGEREF＿Toc\h４3.２．2UML的模型元素?ｈ4HYPＥRLINK3．2.3UMＬ的模型結(jié)構(gòu)?PAGＥREF_Toc\h43.２．4UML的模型圖?PAGEＲＥＦ＿Ｔoc\h5３.2.5UML建模規(guī)則?PAGEＲＥＦ_Toc\h5HＹPＥRＬINK\l＂_Ｔｏc＂3.２.6ＵMＬ的公用機制 PAGERＥＦ_Ｔｏc＼h6HＹPＥRＬIＮK\l＂_Toc"3.3一個ＵＭL的例子?6HYPERLINK\l＂_Ｔoｃ"３.3.1用例圖 PAGEREF＿Toc＼h7HYPＥRLIＮＫ\l＂_Ｔoc＂3．3．2活動圖 ＰAGEＲEF_Tｏc＼h7ＨYPERLＩNK３.3.3順序圖 PAGERＥＦ_Ｔｏc\ｈ7HYPEＲLIＮＫ協(xié)作圖 PＡGEREF_Tｏc\h83.３.5類圖?ＰＡＧＥREF_Toｃ\ｈ8ＨＹPERLINＫ\l"_Toc"狀態(tài)圖 PAGEREF＿Ｔｏｃ＼h83.３.7組件圖?ＰAＧERＥF_Ｔoｃ\ｈ８HYPEＲLＩNK\l"＿Toc＂部署圖?ＰAＧＥＲEF_Toc\h９建模是為軟件開發(fā)服務(wù)的,因此，假如模型所包含的信息足夠完備，就可以以這些信息為基礎(chǔ),進行軟件系統(tǒng)的建造。統(tǒng)一建模語言ＵML是一種總結(jié)了以往建模技術(shù)的經(jīng)驗并吸取當(dāng)今優(yōu)秀成果的標(biāo)準(zhǔn)建模技術(shù)，運用UML表達(dá)的軟件模型，可以直接和某種設(shè)計語言建立映射關(guān)系，通過ＵML建造工具，將UML模型轉(zhuǎn)換為相應(yīng)的程序設(shè)計語言源代碼框架。本章簡要地回顧了UML的產(chǎn)生背景與ＵML的視圖，重點介紹UML的體系結(jié)構(gòu)和建模規(guī)則等內(nèi)容。３.１UＭＬ概述UML是一個通用的可視化建模語言，是用于對軟件進行描述、可視化解決、構(gòu)造和建立軟件系統(tǒng)制品的文檔。其中制品是指軟件開發(fā)過程中產(chǎn)生的各種產(chǎn)物，例如模型、源代碼、測試用例等。UML合用于各種軟件開發(fā)方法、軟件生命周期的各個階段、各種應(yīng)用領(lǐng)域及各種開發(fā)工具。UML的產(chǎn)生背景早在２0世紀(jì)70年代就陸續(xù)出現(xiàn)了面向?qū)ο蟮慕７椒ǎ冢?年代末到90年代中期,各種建模方法如雨后春筍般出現(xiàn),從不到1０種增長到5０多種。但方法種類的膨脹，使用戶很難根據(jù)自身應(yīng)用的特點選擇合適的建模方法,極大地妨礙了用戶的使用和交流。在UＭL之前,已有一些試圖將各種方法中使用的概念進行統(tǒng)一的初期嘗試。１99４年在Rａt(yī)ionaｌ軟件公司的Rumbaugh與Bｏｏch合作,開始合并OMT和Boocｈ方法中使用的概念，并于1995年提出了一個建議。隨后Ｊaｃｏbｓon也加入了Ratioｎａｌ公司，開始與Rｕmｂaugh和Booch一同工作,他們共同致力于設(shè)計統(tǒng)一建模語言。三位最優(yōu)秀的面向?qū)ο蠓椒▽W(xué)的創(chuàng)始人共同合作,吸取了其他面向?qū)ο蠓椒ǖ膬?yōu)點,為這項工作注入了強大的動力,打破了面向?qū)ο筌浖_發(fā)領(lǐng)域內(nèi)原有的平衡。1９96年,ＯMG（ObjｅｃtManaｇｅmentＧrｏｕp）發(fā)布了向外界征集關(guān)于面向?qū)ο蠼?biāo)準(zhǔn)方法的消息。UＭL的三位創(chuàng)始人與來自其他公司的軟件工程方法專家和開發(fā)人員一道制定出使OMG感愛好的方法,并設(shè)計出一種能被軟件開發(fā)工具提供者、軟件開發(fā)方法學(xué)家和開發(fā)人員這些最終用戶所接受的建模語言。1997年９月他們向ＯMG提交了UMＬ方法。1997年1１月,UML被OMG全體成員一致通過,并被采納為標(biāo)準(zhǔn)。隨后OMＧ承擔(dān)了進一步完善UＭL標(biāo)準(zhǔn)的工作。2０23年推出了ＵML１.4版本，2０2３年推出了UML1.5版本,目前最新的版本是UＭL2．0。隨著ＵML被OMＧ采納為標(biāo)準(zhǔn)，面向?qū)ο箢I(lǐng)域的方法學(xué)大戰(zhàn)也宣告結(jié)束，這些方法的提出者很多也開始轉(zhuǎn)向UML方面的研究。UMＬ的出現(xiàn)為面向?qū)ο蠼ＵZ言的歷史翻開了新的一頁,并受到工業(yè)界、學(xué)術(shù)界及用戶的廣泛支持，它融入了軟件工程領(lǐng)域的新思想、新方法和新技術(shù)，成為面向?qū)ο蠹夹g(shù)領(lǐng)域占主導(dǎo)地位的建模語言。UＭＬ代表了面向?qū)ο筌浖_發(fā)技術(shù)的發(fā)展方向，具有巨大的市場前景，也具有重大的經(jīng)濟價值。3.1.２什么是ＵMＬ作為一種語言，ＵML定義了一系列的圖形符號來描述軟件系統(tǒng)。這些圖形符號有嚴(yán)格的語義和清楚的語法。這些圖形符號及其背后的語義和語法組成了一個標(biāo)準(zhǔn)，使得軟件開發(fā)的所有相關(guān)人員都能用它來對軟件系統(tǒng)的各個側(cè)面進行描述。模型元素代表面向?qū)ο笾械念?、對象、消息和關(guān)系等概念，是構(gòu)成圖的最基本的常用概念。一個模型元素可以用在多個不同的圖中，無論如何使用，它總是具有相同的含義和相同的符號來表達(dá)。UML可以描述一個系統(tǒng)的靜態(tài)結(jié)構(gòu)和動態(tài)行為，從不同但互相聯(lián)系的角度對系統(tǒng)建立的模型可用于不同的目的。UML將系統(tǒng)描述為一些離散的互相作用的對象，通過靜態(tài)結(jié)構(gòu)定義系統(tǒng)中對象的屬性和操作及這些對象之間的互相關(guān)系。動態(tài)行為定義了對象的時間特性和對象為完畢目的而互相進行通信的機制。UＭＬ還可將模型分解成包的結(jié)構(gòu)組件，以便于軟件開發(fā)組織將大的系統(tǒng)分解成易于解決的塊結(jié)構(gòu)，并理解和控制各個包之間的依賴關(guān)系，在復(fù)雜的開發(fā)環(huán)境中管理模型單元。UMＬ標(biāo)準(zhǔn)并沒有定義一種標(biāo)準(zhǔn)的開發(fā)過程,但它合用于迭代式的開發(fā)過程。它是為支持大部分現(xiàn)存的面向?qū)ο箝_發(fā)過程而設(shè)計的。ＵML不是一門程序設(shè)計語言，但可以使用代碼生成器工具將UＭL模型轉(zhuǎn)換為多種程序設(shè)計語言代碼,或使用反向生成器工具將程序源代碼轉(zhuǎn)換為UＭL。ＵML的重要特點可以歸納為以下幾點。①統(tǒng)一的標(biāo)準(zhǔn)。UＭL是被OMG接受為標(biāo)準(zhǔn)的建模語言,越來越多的開發(fā)人員使用UML進行軟件開發(fā)，越來越多的廠商支持UＭL。②面向?qū)ο?。ＵMＬ是支持面向?qū)ο筌浖_發(fā)的建模語言。③概念明確，建模表達(dá)法簡潔,圖形結(jié)構(gòu)清楚,可視化、表達(dá)能力強大,容易掌握和使用。④獨立于過程。UML不依賴于特定的軟件開發(fā)過程。3．1.3UMＬ中的視圖對于復(fù)雜系統(tǒng)建模需要從多個不同的方面來描述。UMＬ用視圖來表達(dá)被建模系統(tǒng)的各個方面,它是在某一個抽象層次上對系統(tǒng)的抽象表達(dá)。ＵＭL把軟件模型劃分為5個視圖，每一個視圖代表完整系統(tǒng)描述的投影,顯示系統(tǒng)的一個特定方面。每一個視圖又由一種或多種模型圖構(gòu)成。模型圖描述了構(gòu)成相應(yīng)視圖的基本模型元素及它們之間的互相關(guān)系。一個特定視圖中的圖應(yīng)當(dāng)足夠簡樸，便于交流，并且一定要與其他圖和視圖連貫一致，因而所有視圖結(jié)合在一起(通過它們各自的圖）就描述了系統(tǒng)的完整畫面。圖3-１顯示了UMＬ的視圖。此外,通過視圖可以把建模語言和系統(tǒng)開發(fā)時選擇的方法或過程連接起來。圖３－1UＭL的視圖1.用例視圖用例視圖(UｓeCａseVｉew）用來支持軟件系統(tǒng)的需求分析，它定義系統(tǒng)的邊界,關(guān)注的是系統(tǒng)應(yīng)當(dāng)交付的功能,也就是外部參與者所看到的功能。它從系統(tǒng)參與者的角度描述系統(tǒng)的外部行為和靜態(tài)的功能組合。用例視圖的使用者是客戶、開發(fā)人員及測試人員?？蛻魧ο到y(tǒng)的盼望用法（也就是規(guī)定的功能)被當(dāng)作多個用例在用例視圖中進行描述，一個用例就是對系統(tǒng)的一個用法的通用描述。用例視圖是核心,由于它的內(nèi)容驅(qū)動其他視圖的開發(fā)。系統(tǒng)的最終目的，也就是系統(tǒng)將提供的功能是在用例視圖中描述的。同時該視圖尚有其他一些非功能特性的描述,因此，用例視圖將會對所有其他的視圖產(chǎn)生影響。此外，通過測試用例視圖,可以檢查和最終校驗系統(tǒng)。這種測試來自兩個方面:一方面是客戶，可以詢問客戶“這是您想要的嗎?”;另一個方面就是已完畢的系統(tǒng),可以詢問“系統(tǒng)是按照規(guī)定的方式運作的嗎？”。2.邏輯視圖邏輯視圖(LogｉcalVｉew)定義系統(tǒng)的實現(xiàn)邏輯。它描述了為了實現(xiàn)用例視圖中提出的系統(tǒng)功能，在對軟件系統(tǒng)進行設(shè)計時所產(chǎn)生的設(shè)計概念(設(shè)計概念又稱為軟件系統(tǒng)的設(shè)計詞匯)。邏輯視圖的使用者重要是開發(fā)人員和設(shè)計人員。它關(guān)注系統(tǒng)的內(nèi)部,既描述系統(tǒng)的靜態(tài)結(jié)構(gòu)(類、對象及它們之間的關(guān)系),也描述系統(tǒng)內(nèi)部的動態(tài)協(xié)作關(guān)系。這種協(xié)作發(fā)生在為了實現(xiàn)既定功能,各對象之間進行消息傳遞的時刻。此外，邏輯視圖也定義像永久性和并發(fā)性這樣的特性,同時還定義類的接口和內(nèi)部結(jié)構(gòu)。對邏輯視圖的描述在原則上與軟件系統(tǒng)的實現(xiàn)平臺無關(guān)。它的圖形模型涉及類圖、對象圖、狀態(tài)圖、順序圖、協(xié)作圖及活動圖等。3．組件視圖組件視圖(CoｍponｅntVieｗ)描述系統(tǒng)的實現(xiàn)模塊及它們之間的依賴關(guān)系。它的使用者重要是開發(fā)人員。組件是不同類型的代碼模塊，通過代碼模塊的結(jié)構(gòu)和依賴關(guān)系來表達(dá)。組件視圖中也可以添加組件的其他附加的信息，例如資源分派(為組件服務(wù)）或者其他管理信息(如開發(fā)工作的進度報告）等。４．實現(xiàn)視圖實現(xiàn)視圖(ＩmpｌemｅnｔatiｏnVieｗ)描述的是組成一個軟件系統(tǒng)的各個物理部件,這些部件以各種方式（例如，不同的源代碼通過編譯，構(gòu)成一個可執(zhí)行系統(tǒng)；或者不同的軟件組件配置成為一個可執(zhí)行的系統(tǒng);以及不同的網(wǎng)頁文獻(xiàn),以特定的目錄結(jié)構(gòu),組成一個網(wǎng)站等)組合起來，構(gòu)成一個可實際運營的系統(tǒng)。實現(xiàn)視圖的使用者是開發(fā)人員和系統(tǒng)集成人員。該視圖由動態(tài)圖（狀態(tài)圖、協(xié)作圖,以及活動圖)和實現(xiàn)圖（組件圖和部署圖)組成。5.部署視圖部署視圖(DｅｐloｙmｅｎtＶｉｅw)描述軟件系統(tǒng)在計算機硬件系統(tǒng)和網(wǎng)絡(luò)上的安裝、分發(fā)和分布情況。例如,計算機和設(shè)備（節(jié)點),以及它們之間是如何連接的。部署視圖的使用者是開發(fā)人員、系統(tǒng)集成人員和測試人員,并且該視圖由部署圖表達(dá)。部署視圖也涉及一個顯示組件如何在物理結(jié)構(gòu)中部署的映射，例如一個程序或?qū)ο笤谀呐_計算機上執(zhí)行。3．2UMＬ的構(gòu)成UML是一種定義良好、易于表達(dá)、功能強大且普遍合用的建模語言。它融入了軟件工程領(lǐng)域的新思想、新方法和新技術(shù)。它的作用域不限于支持面向?qū)ο蟮姆治雠c設(shè)計，還支持從需求分析開始的軟件開發(fā)的全過程。3.2．1UML的體系結(jié)構(gòu)UＭL的體系結(jié)構(gòu)如圖3-2所示。ＵML由三部分組成:基本構(gòu)造塊、規(guī)則和公用機制。圖３－2ＵML的構(gòu)成圖其中基本構(gòu)造塊又涉及三種類型：事物、關(guān)系和圖。事物劃分為以下四種類型。①結(jié)構(gòu)事物。涉及類、接口、協(xié)作、用例、積極類、組件和節(jié)點。②行為事物。涉及交互機和狀態(tài)。③分組事物。ＵＭL中的分組事物是包。整個模型可以當(dāng)作是一個根包，它間接包含了模型中的所有內(nèi)容。子系統(tǒng)是另一種特殊的包。④注釋事物。注釋給建模者提供信息,它提供了關(guān)于任意信息的文本說明,但是沒有語義作用。3.2．2ＵML的模型元素UML把可以在圖中使用的概念統(tǒng)稱為模型元素。UML用豐富的圖形符號隱含表達(dá)了模型元素的語法，而用這些圖形符號組成元模型表達(dá)語義,組成模型描述系統(tǒng)結(jié)構(gòu)(或稱為靜態(tài)特性)以及行為(或稱為動態(tài)特性）。圖3-3ＵML定義了兩類模型元素的圖形表達(dá)。一類模型元素用于表達(dá)模型中的某個概念,如圖3－3所示，給出了類、對象、狀態(tài)、節(jié)點、包和組件等模型元素的符號圖例。另一類模型元素用于表達(dá)模型元素之間互相連接的關(guān)系。常見的關(guān)系有關(guān)聯(lián)、繼承、依賴和實現(xiàn)。這些關(guān)系的圖形符號如圖３－4所示。圖3-４關(guān)系的圖示符號示例UＭL的模型結(jié)構(gòu)根據(jù)ＵMＬ語義,UＭＬ的模型結(jié)構(gòu)可分為四個抽象層次，即元元模型、元模型、模型層和用戶模型。它們的層次結(jié)構(gòu)如圖3－５所示,下一層是上一層的基礎(chǔ),上一層是下一層的實例。圖3－5元元模型層是組成ＵML最基本的元素“事物”，代表要定義的所有事物。元元模型定義了元類、元屬性、元操作等一些概念。例如,圖3-６是一個“元類”的元元模型描述，其中事物概念可代表任何定義的東西。圖3-6元模型層組成了UML的基本元素，涉及面向?qū)ο蠛兔嫦蚪M件的概念。這一層的每個概念都是元元模型中“事物”概念的實例。例如,圖3-7是一個元模型示例，其中類、對象、關(guān)聯(lián)等都是元元模型中事物概念的實例。圖3-7元模型示例模型層組成了UＭＬ的模型,這一層中的每個概念都是元模型層中概念的一個實例，這一層的模型通常叫作類模型或類型模型。用戶模型層中的所有元素都是UＭL模型的例子。這一層中的每個概念都是模型層的一個實例(通過度類),也是元模型層的一個實例。這一層的模型通常叫作對象模型或?qū)嵗Ｐ?。?2.4ＵML的模型圖模型通常作為一組圖呈現(xiàn)出來，常用的UＭL模型圖有９種，它們是類圖、對象圖、用例圖、順序圖、協(xié)作圖、狀態(tài)圖、活動圖、組件圖和部署圖。在這9種圖中，類圖包含類、接口、協(xié)同及其關(guān)系，它用來描述邏輯視圖的靜態(tài)屬性；對象圖包含對象及其關(guān)系，它用來表達(dá)某一類圖的一組類的對象在系統(tǒng)運營過程中某一時刻的狀態(tài),對象圖也是軟件系統(tǒng)的邏輯視圖的一個組成部分；組件圖用來描述系統(tǒng)的物理實現(xiàn),涉及構(gòu)成軟件系統(tǒng)的各部件的組織和關(guān)系，類圖里的類在實現(xiàn)時，最終會映射到組件圖的某個組件,一個組件可以實現(xiàn)多個類,組件圖是軟件系統(tǒng)實現(xiàn)視圖的組成部分；部署圖用來描述系統(tǒng)的組件在運營時在運營節(jié)點上的分布情況,一個節(jié)點可包含一個或多個組件，部署圖是軟件系統(tǒng)部署視圖的組成部分。上述四種模型圖重要用來描述軟件系統(tǒng)的靜態(tài)結(jié)構(gòu)。用例圖、順序圖、協(xié)作圖、狀態(tài)圖和活動圖是用來描述軟件系統(tǒng)的動態(tài)特性。用例圖用來描述系統(tǒng)的邊界及其系統(tǒng)功能，它由用例和系統(tǒng)外部參與者及其之問的關(guān)聯(lián)關(guān)系組成,用例圖是用例視圖的重要組成部分和內(nèi)部的動態(tài)特性。順序圖和協(xié)作圖中包含對象和消息,它們是用例視圖和邏輯視圖的重要組成部分。狀態(tài)圖和活動圖重要用于描述對象的動態(tài)特性。狀態(tài)圖強調(diào)對象對外部事件的響應(yīng)及相應(yīng)的狀態(tài)變遷。活動圖描述對象之間控制流的轉(zhuǎn)換和同步機制。表3-1表3-１列出了UML的視圖和視圖所涉及的圖及與每種圖有關(guān)的重要概念。容易混淆的是有時也把圖稱為模型，由于兩者都包含一組模型元素的信息。這兩個概念的區(qū)別是,模型描述的是信息的邏輯結(jié)構(gòu),而圖是模型的特殊物理表達(dá)。３.２.5UML建模規(guī)則ＵＭL的模型圖不是由UML語言成分簡樸地堆砌而成的,它必須按特定的規(guī)則有機地組成合法的ＵML圖。一個完備的UML模型圖必須在語義上是一致的，并且和一切與它相關(guān)的模型和諧地組合在一起。UML建模規(guī)則涉及了對以下內(nèi)容的描述。①名字:任何一個UML成員都必須包含一個名字。②作用域:UＭL成員所定義的內(nèi)容起作用的上下文環(huán)境。某個成員在每個實例中代表一個值，還是代表這個類元的所有實例的一個共享值,由上下文決定。③可見性：UＭL成員能被其他成員引用的方式。④完整性:UML成員之間互相連接的合法性和一致性。⑤運營屬性:UML成員在運營時的特性。一個完備的ＵML模型必須對以上內(nèi)容給出完整的解釋。完備的UＭＬ模型是建造系統(tǒng)所必需的，但是當(dāng)它在不同的視圖中出現(xiàn)時，出于不同的交流側(cè)重點，其表達(dá)可以是不完備的。在系統(tǒng)的開發(fā)過程中，模型可以:①被省略,即模型自身是完備的，但在圖上某些屬性被隱藏起來,以簡化表達(dá)；②不完全，即在設(shè)計過程中某些元素可以暫時不存在；③不一致，即在設(shè)計過程中暫時不保證設(shè)計的完整性。提出上述三條建模原則的目的是為使開發(fā)人員在設(shè)計模型時把注意力集中在某一特定期期內(nèi)對分析設(shè)計活動最重要的問題上，而暫時不迷戀于細(xì)節(jié)的完美,使模型逐步趨向完備。3.2.６ＵML的公用機制以圖的方式建立模型是不夠的,對于各種圖中的建模元素，還要按一定的規(guī)定進行具體的說明和解釋,即用圖加上說明規(guī)范的方式構(gòu)成完整的模型。在UMＬ模型圖上使用UML成員進行建模時，需要對UML成員進行描繪。UML使用公用機制為圖附加一些信息,這些信息通常無法用基本的模型元素表達(dá)。ＵＭL對不同的UMＬ成員使用共同的描繪方式，這些方式稱為ＵML共用機制。使用這些共用機制,使得建模的過程更適于掌握，模型更容易被理解。共用機制可被分解為以下四個方面。(1)規(guī)范說明UＭＬ的圖形符號是簡潔、形象、直觀的，而一個有效的軟件模型必須提供足夠的具體信息以供建造之用，這些構(gòu)成一個完備模型的具體信息就是模型的規(guī)范說明。在模型圖上被省略的內(nèi)容并不代表它不存在于模型之中,模型的完整的或完備的信息是被保存在模型的規(guī)范說明中的。(2)修飾在圖的模型元素上添加修飾,可為模型元素附加一定的語義。例如，類的屬性的可見性就是可以選擇地被顯示出來的。(3）公共劃分在面向?qū)ο蟮脑O(shè)計中，有許多事物可以劃分為抽象的描繪和具體的實例這兩種存在形式。UＭL提供了事物的這兩種兩分法表達(dá)，被稱為公共劃分。例如，對象和類使用同樣的圖形符號。類用長方形表達(dá),并用名字加以標(biāo)記，當(dāng)類的名字帶有下劃線時，則它代表該類的一個對象。此外,尚有一種兩分法是接口和實現(xiàn)的兩分劃分。接口定義了一種協(xié)議,實現(xiàn)是此協(xié)議的實行。UMＬ里這樣的接口與實現(xiàn)的兩分劃分涉及接口/類或組件、用例和協(xié)同，以及操作和方法。(4）擴展機制如同人類的語言需要不斷地擴充詞匯，以描述各種新出現(xiàn)的事物同樣,UMＬ也提供了擴展機制。擴展機制為UML提供了擴充其表達(dá)內(nèi)容的范圍的能力。UML的擴展機制涉及構(gòu)造型(版型)、標(biāo)記值及約束。構(gòu)造型是對類的進一步的分類。標(biāo)記值用來擴充UMＬ成員的規(guī)范說明。雖然在UML中已經(jīng)預(yù)定義了許多特性,但是用戶也可以定義自己的特性，以維護元素的附加信息。任何一種信息都可以附屬到某個元素，涉及:特定方法的信息、關(guān)于建模過程的管理信息、其他工具使用的信息(如代碼生成工具)或者是用戶希望將其連接到元素的其他類型的信息。約束用來擴充UML成員的語義。3.３一個UML的例子本節(jié)通過一個簡化銀行ATＭ系統(tǒng)的例子對UML中所使用的模型和視圖進行初覽，說明如何用各種不同的概念來描述一個系統(tǒng),以及如何將各種視圖組織在一起。這是一個簡化了ATM取款解決系統(tǒng)的例子，忽略了有關(guān)細(xì)節(jié)，重要為了說明各種UML圖形的概念和基本含義。用戶通過輸入銀行賬號(ＰIN)來確認(rèn)用戶的合法身份,查詢有關(guān)自己賬戶的信息,還可以通過ATＭ機進行存款、取款,或者使用AＴM辦理轉(zhuǎn)賬等事務(wù)。當(dāng)用戶把鈔票兌換卡插入ＡＴM之后,AＴM就與用戶交互，以獲取有關(guān)這次事務(wù)的信息，并與銀行的計算機互換事務(wù)的信息。3.３.1用例圖采用用例驅(qū)動的分析方法分析需求的重要任務(wù)是辨認(rèn)出系統(tǒng)中的參與者和用例,并建立用例模型。用例圖是被稱為參與者的外部用戶所能觀測到的系統(tǒng)功能的模型圖。用例是系統(tǒng)中的一個功能單元，可以被描述為參與者與系統(tǒng)之間的一次交互作用。用例模型的用途是列出系統(tǒng)中的用例和參與者，并顯示哪個參與者參與了哪個用例的執(zhí)行。參與者是系統(tǒng)的主體，表達(dá)提供或接受系統(tǒng)信息的人或系統(tǒng)。圖3-８顯示了ATＭ系統(tǒng)使用用例與參與者之間的交互。在本例中涉及幾個用例：取款、存款、付款、轉(zhuǎn)賬、查詢、修改ＰＩN等。本例中涉及的參與者有：用戶、銀行業(yè)務(wù)員、信用系統(tǒng)。銀行業(yè)務(wù)員在特定的情況下可以啟動修改PIＮ用例。在用戶付款時，需要得到信用系統(tǒng)的確認(rèn)。圖3-8ＡTＭ系統(tǒng)的用例圖活動圖活動圖顯示了系統(tǒng)的流程,可以是工作流,也可以是事件流。在活動圖中定義了流程從哪里開始，到哪里結(jié)束,以及在這之中涉及哪些活動?；顒邮枪ぷ髁髌陂g完畢的任務(wù)?；顒訄D描述了活動發(fā)生的順序。在本例中用活動圖描述滿足用例規(guī)定所要進行的活動及活動間的約束關(guān)系。圖3－9顯示了開戶的活動。框圖中的活動用圓角矩形表達(dá),這是工作流期間發(fā)生的環(huán)節(jié)。工作流影響的對象用矩形表達(dá)。開始狀態(tài)表達(dá)工作流開始,結(jié)束狀態(tài)表達(dá)工作流結(jié)束。決策點用菱形表達(dá)。圖3－9開戶的活動圖對象流程顯示活動使用或創(chuàng)建的對象和工作流過程中對象如何改變狀態(tài)。活動圖可以分為不同的垂直泳道，每個泳道代表工作流中的不同參與者。通過泳道中的活動可以了解這個參與者的責(zé)任。通過查看不同泳道中活動之間的過渡，可以了解誰要與誰進行通信?；顒訄D的用途是對現(xiàn)實世界中的工作流程建模，但活動圖也可對軟件系統(tǒng)中的活動建模。活動圖有助于理解系統(tǒng)高層活動的執(zhí)行行為,而不涉及建立協(xié)作圖所必需的消息細(xì)節(jié)。3.3.３順序圖順序圖表達(dá)了對象之間傳送消息的時間順序。每一個對象用一條生命線來表達(dá)——即用垂直線代表整個交互過程中對象的生命周期。生命線之間的箭頭連線代表消息。順序圖可以用來進行一個場景說明——即一個事務(wù)的歷史過程。圖3-10顯示了用戶張三取款用例的具體過程。圖3-10張三取款的順序圖取款用例從用戶將ATM卡插入讀卡機開始,讀卡機對象表達(dá)為框圖頂部的矩形。在確認(rèn)是合法的ATM卡后，系統(tǒng)詢問PIN，并通過顯示器對象顯示出來。用戶輸入ＰIＮ,系統(tǒng)驗證PIN與賬戶對象，發(fā)出合格信息。然后系統(tǒng)向張三提供選項，張三輸入取款金額(20０元)。系統(tǒng)一方面驗證賬戶中的余額不少于200元，然后從賬戶中扣除２00元，再讓點鈔機提供２０0元鈔票,ATM從鈔票出口吐出鈔票,并打印賬單交給用戶。最后系統(tǒng)退出ＡTＭ卡。3.3.４協(xié)作圖協(xié)作圖對在一次交互中故意義的對象和對象間的鏈建模。對象和關(guān)系只有進行交互才故意義。如圖3-11所示，表達(dá)了取款所涉及的各個對象間的交互關(guān)系。在協(xié)作圖中,直接互相通信的對象之間有一條直線,沒有畫線的對象之間不直接通信。附在直線上的箭頭代表消息。消息的發(fā)生順序用消息箭頭處的編號來說明。協(xié)作圖的一個用途是表達(dá)一個類操作的實現(xiàn)。協(xié)作圖可以說明類操作中用到的參數(shù)和局部變量及操作中的永久鏈。當(dāng)實現(xiàn)一個行為時,消息編號相應(yīng)了程序中嵌套調(diào)用結(jié)構(gòu)和信號傳遞過程。圖3－1１張三取款的協(xié)作圖3.3．５類圖類圖是以類為中心來組織的，類圖中的其他元素或?qū)儆谀硞€類或與類相關(guān)聯(lián)。在類圖中類用矩形框來表達(dá)，它的屬性和操作分別列在分格中。關(guān)系用類框之間的連線來表達(dá)，不同的關(guān)系用連線上和連線端頭處的修飾符來區(qū)別。圖3－1２是AFＭ系統(tǒng)中與取款用例有關(guān)的類圖。圖3-12類圖在這個類圖中包含讀卡機、顯示、數(shù)字鍵盤、客戶管理、點鈔機、事務(wù)管理、賬戶管理和賬戶八個類。類之間的關(guān)系通過連線來表達(dá)。例如，客戶管理類與點鈔機兩者需要通信，因此兩個類相連；而讀卡機與點鈔機不進行通信，因而不需要相連。3．3.6狀態(tài)圖狀態(tài)視圖是一個類對象所經(jīng)歷的所有歷程的模型圖。狀態(tài)由對象的各個狀態(tài)和連接這些狀態(tài)的變遷組成。每個狀態(tài)對一個對象在其生命周期中滿足某種條件的一個時間段建模