1UML基礎(chǔ)UMLUnifiedModelingLanguage(UML)又稱統(tǒng)一建模語言或標(biāo)準(zhǔn)建模語言，是始于1997年一個(gè)OMG標(biāo)準(zhǔn)，它是一個(gè)支持模型化和軟件系統(tǒng)開發(fā)的圖形化語言，為軟件開發(fā)的所有階段提供模型化和可視化支持，包括由需求分析到規(guī)格，到構(gòu)造和配置。2標(biāo)準(zhǔn)建模語言UML的出現(xiàn)

公認(rèn)的面向?qū)ο蠼ＵZ言出現(xiàn)于70年代中期。從1989年到1994年，其數(shù)量從不到十種增加到了五十多種。在眾多的建模語言中，語言的創(chuàng)造者努力推崇自己的產(chǎn)品，并在實(shí)踐中不斷完善。但是，OO方法的用戶并不了解不同建模語言的優(yōu)缺點(diǎn)及相互之間的差異，因而很難根據(jù)應(yīng)用特點(diǎn)選擇合適的建模語言，于是爆發(fā)了一場(chǎng)“方法大戰(zhàn)”。90年代中，一批新方法出現(xiàn)了，其中最引人注目的是Booch1993、OOSE和OMT-2等。

3標(biāo)準(zhǔn)建模語言UML的出現(xiàn)

Booch是面向?qū)ο蠓椒ㄗ钤绲某珜?dǎo)者之一，他提出了面向?qū)ο筌浖こ痰母拍睢?991年，他將以前面向Ada的工作擴(kuò)展到整個(gè)面向?qū)ο笤O(shè)計(jì)領(lǐng)域。Booch1993比較適合于系統(tǒng)的設(shè)計(jì)和構(gòu)造。Rumbaugh等人提出了面向?qū)ο蟮慕＜夹g(shù)（OMT）方法，采用了面向?qū)ο蟮母拍睿⒁敫鞣N獨(dú)立于語言的表示符。這種方法用對(duì)象模型、動(dòng)態(tài)模型、功能模型和用例模型，共同完成對(duì)整個(gè)系統(tǒng)的建模，所定義的概念和符號(hào)可用于軟件開發(fā)的分析、設(shè)計(jì)和實(shí)現(xiàn)的全過程，軟件開發(fā)人員不必在開發(fā)過程的不同階段進(jìn)行概念和符號(hào)的轉(zhuǎn)換。OMT-2特別適用于分析和描述以數(shù)據(jù)為中心的信息系統(tǒng)。Jacobson于1994年提出了OOSE方法，其最大特點(diǎn)是面向用例(Use-Case)，并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，但用例貫穿于整個(gè)開發(fā)過程，包括對(duì)系統(tǒng)的測(cè)試和驗(yàn)證。OOSE比較適合支持商業(yè)工程和需求分析。4標(biāo)準(zhǔn)建模語言UML的出現(xiàn)

1994年10月，GradyBooch和JimRumbaugh開始致力于這一工作。他們首先將Booch93和OMT-2統(tǒng)一起來，并于1995年10月發(fā)布了第一個(gè)公開版本，稱之為統(tǒng)一方法UM0.8（UnitiedMethod）。1995年秋，OOSE的創(chuàng)始人IvarJacobson加盟到這一工作。經(jīng)過Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分別發(fā)布了兩個(gè)新的版本，即UML0.9和UML0.91，并將UM重新命名為UML（UnifiedModelingLanguage）。1996年，一些機(jī)構(gòu)將UML作為其商業(yè)策略已日趨明顯。UML的開發(fā)者得到了來自公眾的正面反應(yīng)，并倡議成立了UML成員協(xié)會(huì)，以完善、加強(qiáng)和促進(jìn)UML的定義工作。當(dāng)時(shí)的成員有DEC、HP、I－Logix、Itellicorp、IBM、ICONComputing、MCISystemhouse、Microsoft、Oracle、RationalSoftware、TI以及Unisys。這一機(jī)構(gòu)對(duì)UML1.0（1997年1月）及UML1.1（1997年11月17日）的定義和發(fā)布起了重要的促進(jìn)作用。5標(biāo)準(zhǔn)建模語言UML的出現(xiàn)

UML是一種定義良好、易于表達(dá)、功能強(qiáng)大且普遍適用的建模語言。它溶入了軟件工程領(lǐng)域的新思想、新方法和新技術(shù)。它的作用域不限于支持面向?qū)ο蟮姆治雠c設(shè)計(jì)，還支持從需求分析開始的軟件開發(fā)的全過程。截止1996年10月，UML獲得了工業(yè)界、科技界和應(yīng)用界的廣泛支持，已有700多個(gè)公司表示支持采用UML作為建模語言。1996年底，UML已穩(wěn)占面向?qū)ο蠹夹g(shù)市場(chǎng)的85％，成為可視化建模語言事實(shí)上的工業(yè)標(biāo)準(zhǔn)。1997年11月17日，OMG采納UML1.1作為基于面向?qū)ο蠹夹g(shù)的標(biāo)準(zhǔn)建模語言。2003年6月12日－上周巴黎的OMG技術(shù)會(huì)議上，分析和設(shè)計(jì)專案小組（theAnalysisandDesignTaskForce）投票通過了UML2.0Superstructure規(guī)約，至此，本行業(yè)最重要的軟件建模符號(hào)的主要升級(jí)宣告完成。6UML的特點(diǎn)首先，UML融合了Booch、OMT和OOSE方法中的基本概念，而且這些基本概念與其他面向?qū)ο蠹夹g(shù)中的基本概念大多相同，因而，UML必然成為這些方法以及其他方法的使用者樂于采用的一種簡單一致的建模語言；其次，UML不僅僅是上述方法的簡單匯合，而是在這些方法的基礎(chǔ)上廣泛征求意見，集眾家之長，幾經(jīng)修改而完成的，UML擴(kuò)展了現(xiàn)有方法的應(yīng)用范圍；第三，UML是標(biāo)準(zhǔn)的建模語言，而不是標(biāo)準(zhǔn)的開發(fā)過程。7標(biāo)準(zhǔn)建模語言UML的內(nèi)容作為一種建模語言，UML的定義包括UML語義和UML表示法兩個(gè)部分。(1)UML語義。 描述基于UML的精確元模型定義。元模型為UML的所有元素在語法和語義上提供了簡單、一致、通用的定義性說明，使開發(fā)者能在語義上取得一致，消除了因人而異的最佳表達(dá)方法所造成的影響。此外UML還支持對(duì)元模型的擴(kuò)展定義。(2)UML表示法。 定義UML符號(hào)的表示法，為開發(fā)者或開發(fā)工具使用這些圖形符號(hào)和文本語法為系統(tǒng)建模提供了標(biāo)準(zhǔn)。這些圖形符號(hào)和文字所表達(dá)的是應(yīng)用級(jí)的模型，在語義上它是UML元模型的實(shí)例。8標(biāo)準(zhǔn)建模語言UML的內(nèi)容第一類是用例圖，從用戶角度描述系統(tǒng)功能，并指出各功能的操作者。9標(biāo)準(zhǔn)建模語言UML的內(nèi)容第二類是靜態(tài)圖(Staticdiagram)，包括類圖、對(duì)象圖和包圖。其中類圖描述系統(tǒng)中類的靜態(tài)結(jié)構(gòu)。不僅定義系統(tǒng)中的類，表示類之間的聯(lián)系如關(guān)聯(lián)、依賴、聚合等，也包括類的內(nèi)部結(jié)構(gòu)（類的屬性和操作）。類圖描述的是一種靜態(tài)關(guān)系，在系統(tǒng)的整個(gè)生命周期都是有效的。對(duì)象圖是類圖的實(shí)例，幾乎使用與類圖完全相同的標(biāo)識(shí)。他們的不同點(diǎn)在于對(duì)象圖顯示類的多個(gè)對(duì)象實(shí)例，而不是實(shí)際的類。一個(gè)對(duì)象圖是類圖的一個(gè)實(shí)例。由于對(duì)象存在生命周期，因此對(duì)象圖只能在系統(tǒng)某一時(shí)間段存在。包由包或類組成，表示包與包之間的關(guān)系。包圖用于描述系統(tǒng)的分層結(jié)構(gòu)。10標(biāo)準(zhǔn)建模語言UML的內(nèi)容第三類是行為圖（Behaviordiagram），描述系統(tǒng)的動(dòng)態(tài)模型和組成對(duì)象間的交互關(guān)系。其中狀態(tài)圖描述類的對(duì)象所有可能的狀態(tài)以及事件發(fā)生時(shí)狀態(tài)的轉(zhuǎn)移條件。通常，狀態(tài)圖是對(duì)類圖的補(bǔ)充。在實(shí)用上并不需要為所有的類畫狀態(tài)圖，僅為那些有多個(gè)狀態(tài)其行為受外界環(huán)境的影響并且發(fā)生改變的類畫狀態(tài)圖。而活動(dòng)圖描述滿足用例要求所要進(jìn)行的活動(dòng)以及活動(dòng)間的約束關(guān)系，有利于識(shí)別并行活動(dòng)。11標(biāo)準(zhǔn)建模語言UML的內(nèi)容第四類是交互圖（Interactivediagram），描述對(duì)象間的交互關(guān)系。其中順序圖顯示對(duì)象之間的動(dòng)態(tài)合作關(guān)系，它強(qiáng)調(diào)對(duì)象之間消息發(fā)送的順序，同時(shí)顯示對(duì)象之間的交互；合作圖描述對(duì)象間的協(xié)作關(guān)系，合作圖跟順序圖相似，顯示對(duì)象間的動(dòng)態(tài)合作關(guān)系。除顯示信息交換外，合作圖還顯示對(duì)象以及它們之間的關(guān)系。如果強(qiáng)調(diào)時(shí)間和順序，則使用順序圖；如果強(qiáng)調(diào)上下級(jí)關(guān)系，則選擇合作圖。這兩種圖合稱為交互圖。

12標(biāo)準(zhǔn)建模語言UML的內(nèi)容第五類是實(shí)現(xiàn)圖(Implementationdiagram)。其中構(gòu)件圖描述代碼部件的物理結(jié)構(gòu)及各部件之間的依賴關(guān)系。一個(gè)部件可能是一個(gè)資源代碼部件、一個(gè)二進(jìn)制部件或一個(gè)可執(zhí)行部件。它包含邏輯類或?qū)崿F(xiàn)類的有關(guān)信息。部件圖有助于分析和理解部件之間的相互影響程度。配置圖定義系統(tǒng)中軟硬件的物理體系結(jié)構(gòu)。它可以顯示實(shí)際的計(jì)算機(jī)和設(shè)備（用節(jié)點(diǎn)表示）以及它們之間的連接關(guān)系，也可顯示連接的類型及部件之間的依賴性。在節(jié)點(diǎn)內(nèi)部，放置可執(zhí)行部件和對(duì)象以顯示節(jié)點(diǎn)跟可執(zhí)行軟件單元的對(duì)應(yīng)關(guān)系。13標(biāo)準(zhǔn)建模語言UML的應(yīng)用領(lǐng)域UML的目標(biāo)是以面向?qū)ο髨D的方式來描述任何類型的系統(tǒng)，具有很寬的應(yīng)用領(lǐng)域。其中最常用的是建立軟件系統(tǒng)的模型。UML適用于系統(tǒng)開發(fā)過程中從需求規(guī)格描述到系統(tǒng)完成后測(cè)試的不同階段。在需求分析階段，可以用用例來捕獲用戶需求。通過用例建模，描述對(duì)系統(tǒng)感興趣的外部角色及其對(duì)系統(tǒng)（用例）的功能要求。分析階段主要關(guān)心問題域中的主要概念（如抽象、類和對(duì)象等）和機(jī)制，需要識(shí)別這些類以及它們相互間的關(guān)系，并用UML類圖來描述。為實(shí)現(xiàn)用例，類之間需要協(xié)作，這可以用UML動(dòng)態(tài)模型來描述。UML模型還可作為測(cè)試階段的依據(jù)。系統(tǒng)通常需要經(jīng)過單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試和驗(yàn)收測(cè)試。14標(biāo)準(zhǔn)建模語言UML的建模機(jī)制靜態(tài)建模動(dòng)態(tài)建模15靜態(tài)建模1.用例圖：用例模型描述的是外部執(zhí)行者(Actor)所理解的系統(tǒng)功能。用例模型用于需求分析階段，它的建立是系統(tǒng)開發(fā)者和用戶反復(fù)討論的結(jié)果，表明了開發(fā)者和用戶對(duì)需求規(guī)格達(dá)成的共識(shí)。首先，它描述了待開發(fā)系統(tǒng)的功能需求；其次，它將系統(tǒng)看作黑盒，從外部執(zhí)行者的角度來理解系統(tǒng)；第三，它驅(qū)動(dòng)了需求分析之后各階段的開發(fā)工作，不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實(shí)現(xiàn)，而且被用于驗(yàn)證和檢測(cè)所開發(fā)的系統(tǒng)，從而影響到開發(fā)工作的各個(gè)階段和UML的各個(gè)模型。16用例(usecase)用例(usecase)從本質(zhì)上講，一個(gè)用例是用戶與計(jì)算機(jī)之間的一次典型交互作用。以字處理軟件為例，“將某些正文置為黑體”和“創(chuàng)建一個(gè)索引”便是兩個(gè)典型的用例。在UML中，用例被定義成系統(tǒng)執(zhí)行的一系列動(dòng)作，動(dòng)作執(zhí)行的結(jié)果能被指定執(zhí)行者察覺到。在UML中，用例表示為一個(gè)橢圓。用例捕獲某些用戶可見的需求，實(shí)現(xiàn)一個(gè)具體的用戶目標(biāo)。用例由執(zhí)行者激活，并提供確切的值給執(zhí)行者。用例可大可小，但它必須是對(duì)一個(gè)具體的用戶目標(biāo)實(shí)現(xiàn)的完整描述。17執(zhí)行者(Actor)執(zhí)行者(Actor)執(zhí)行者是指用戶在系統(tǒng)中所扮演的角色。其圖形化的表示是一個(gè)小人。盡管執(zhí)行者在用例圖中是用類似人的圖形來表示的，但執(zhí)行者未必是人。例如，執(zhí)行者也可以是一個(gè)外界系統(tǒng)，該外界系統(tǒng)可能需要從當(dāng)前系統(tǒng)中獲取信息，與當(dāng)前系統(tǒng)有進(jìn)行交互。18

用例模型的獲取幾乎在任何情況下都可以使用用例。用例用來獲取需求，規(guī)劃和控制項(xiàng)目。用例的獲取是需求分析階段的主要任務(wù)之一，而且是首先要做的工作。大部分用例將在項(xiàng)目的需求分析階段產(chǎn)生，并且隨著工作的深入會(huì)發(fā)現(xiàn)更多的用例，這些都應(yīng)及時(shí)增添到已有的用例集中。用例集中的每個(gè)用例都是一個(gè)潛在的需求。19獲取執(zhí)行者獲取用例首先要找出系統(tǒng)的執(zhí)行者?？梢酝ㄟ^用戶回答一些問題的答案來識(shí)別執(zhí)行者。以下問題可供參考：誰使用系統(tǒng)的主要功能(主要使用者)。誰需要系統(tǒng)支持他們的日常工作。誰來維護(hù)、管理使系統(tǒng)正常工作(輔助使用者)。系統(tǒng)需要操縱哪些硬件。系統(tǒng)需要與哪些其它系統(tǒng)交互，包含其它計(jì)算機(jī)系統(tǒng)和其它應(yīng)用程序。對(duì)系統(tǒng)產(chǎn)生的結(jié)果感興趣的人或事物。20獲取用例一旦獲取了執(zhí)行者，就可以對(duì)每個(gè)執(zhí)行者提出問題以獲取用例。以下問題可供參考：執(zhí)行者要求系統(tǒng)提供哪些功能(執(zhí)行者需要做什么)?執(zhí)行者需要讀、產(chǎn)生、刪除、修改或存儲(chǔ)的信息有哪些類型。必須提醒執(zhí)行者的系統(tǒng)事件有哪些?或者執(zhí)行者必須提醒系統(tǒng)的事件有哪些?怎樣把這些事件表示成用例中的功能?為了完整地描述用例，還需要知道執(zhí)行者的某些典型功能能否被系統(tǒng)自動(dòng)實(shí)現(xiàn)?還有一些不針對(duì)具體執(zhí)行者問題(即針對(duì)整個(gè)系統(tǒng)的問題)：系統(tǒng)需要何種輸入輸出?輸入從何處來?輸出到何處?當(dāng)前運(yùn)行系統(tǒng)(也許是一些手工操作而不是計(jì)算機(jī)系統(tǒng))的主要問題?需要注意，最后兩個(gè)問題并不是指沒有執(zhí)行者也可以有用例，只是獲取用例時(shí)尚不知道執(zhí)行者是什么。21ATM系統(tǒng)用例圖22物流中心用例圖23課堂習(xí)題請(qǐng)繪制某高校的圖書館管理系統(tǒng)的用例圖24事件圖（ACTIVITY）描述滿足用例要求所要進(jìn)行的活動(dòng)以及活動(dòng)間