1UML基礎UMLUnifiedModelingLanguage(UML)又稱統一建模語言或標準建模語言，是始于1997年一個OMG標準，它是一個支持模型化和軟件系統開發的圖形化語言，為軟件開發的所有階段提供模型化和可視化支持，包括由需求分析到規格，到構造和配置。2標準建模語言UML的出現

公認的面向對象建模語言出現于70年代中期。從1989年到1994年，其數量從不到十種增加到了五十多種。在眾多的建模語言中，語言的創造者努力推崇自己的產品，并在實踐中不斷完善。但是，OO方法的用戶并不了解不同建模語言的優缺點及相互之間的差異，因而很難根據應用特點選擇合適的建模語言，于是爆發了一場“方法大戰”。90年代中，一批新方法出現了，其中最引人注目的是Booch1993、OOSE和OMT-2等。

3標準建模語言UML的出現

Booch是面向對象方法最早的倡導者之一，他提出了面向對象軟件工程的概念。1991年，他將以前面向Ada的工作擴展到整個面向對象設計領域。Booch1993比較適合于系統的設計和構造。Rumbaugh等人提出了面向對象的建模技術（OMT）方法，采用了面向對象的概念，并引入各種獨立于語言的表示符。這種方法用對象模型、動態模型、功能模型和用例模型，共同完成對整個系統的建模，所定義的概念和符號可用于軟件開發的分析、設計和實現的全過程，軟件開發人員不必在開發過程的不同階段進行概念和符號的轉換。OMT-2特別適用于分析和描述以數據為中心的信息系統。Jacobson于1994年提出了OOSE方法，其最大特點是面向用例(Use-Case)，并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，但用例貫穿于整個開發過程，包括對系統的測試和驗證。OOSE比較適合支持商業工程和需求分析。4標準建模語言UML的出現

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

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

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

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