北京理工大學

軟件工程實踐吳際北京航空航天大學第一頁，共六十八頁。第十二講面向對象方法與UML介紹第二頁，共六十八頁。內容和目的我們的座標面向對象方法面向對象：能與不能統一建模語言UML第三頁，共六十八頁。我們的座標應用開發的變化開發工具和手段的發展開發方法和技術的發展第四頁，共六十八頁。應用開發的變化70年代：小型機（或服務器）上的數學程序80年代：單機（或以太網）上的、文本界面（或簡單圖形界面）、計算型應用90年代：互聯網（Internet）、豐富圖形界面、事務處理型應用，要求快速提交產品現在，分布于Internet、Intranet，多種界面形式（基于WebBrowser、ApplicationGUI等），多種事務處理的集成（電子商務、信息管理），多種標準的支持(XML，J2EE，Corba，.NET)，多種平臺的支持(Windows，Linux，Unix，…)第五頁，共六十八頁。開發工具和手段的發展70年代：基于匯編代碼的調試器80年代：基于高級語言的調試器（TurboC，MicrosoftC，BorlandC，TurboPascal）90年代：集成了調試器、編輯器、配置管理、框架代碼構造、及時編碼提示、應用GUI界面編輯等的集成開發環境，如VisualStudio，Delphi現在：在集成開發環境基礎上，提供更強大的開發平臺支持（.NET，JDK），同時更關注應用的平臺無關性和運行安全性第六頁，共六十八頁。開發方法和技術的發展70年代：結構化方法（設計、編碼）80年代：結構化方法（分析、設計、編碼），狀態圖，需求工程90年代：面向對象分析、設計、編碼，對象建模現在：商務建模(businessmodeling)、面向對象建模（分析、設計），體系結構設計（構件化）第七頁，共六十八頁。面向對象方法結構化與面向對象的提出面向對象方法特征面向對象主要流派第八頁，共六十八頁。結構化與面向對象的提出CFD&DFD：自頂而下的層次分解策略任何一層有變動，其下面的所有層次都必須重新進行層次分解層次間的解釋關系使得難以維護層次間的一致性強調數據、功能分解，但忽略了數據、功能的整合數據與功能分離的結構化認知觀點，實際偏離了人認知世界的基本原則：以實體為單位，以關系為核心盡管有缺點，但結構化仍有可借鑒之處：結構化原則數據字典狀態圖第九頁，共六十八頁。WhatdoyouthinkaboutOO?大幕拉開：面向對象面相對象的目標：以人的（獲接近于人的）認知方法和原則來描述事物完全不同于結構化的描述手段：類、對象繼承多態消息第十頁，共六十八頁。類、對象是核心面向對象分析、設計、編碼的基本單位數據與功能的有效封裝可直接映射到現實或抽象的實體關系、狀態、行為開發管理的基本單位類測試就是“單元測試”！第十一頁，共六十八頁。繼承：面向對象冠上明珠如果沒有繼承，誰能在一個小時之內，只使用SDK接口編寫出Notepad?如果使用繼承，你只需十分鐘（或更少）！繼承至少提供了兩個方向的設計支持：重用抽象、接口（COM、DCOM、Bean）沒有繼承，幾乎不可能有通用的容器類(ContainerorCollector)可供使用多繼承：你使用過多少次？第十二頁，共六十八頁。多態：面向對象‘自適應’中樞多態（polymorphism）：多種形態，統一語義接口描述了通訊協議多態使得基于接口的通訊能夠自適應Arg1,agr2,…第十三頁，共六十八頁。多態：面向對象‘自適應’中樞兩種多態：同一個類中的不同形態接口不同子類以不同形態實現（或重載）父類接口典型例子：畫圖程序中GraphManager類的Draw,Move,Open,…典型例子：文檔編輯中針對不同對象的統一的Cut/Copy/Paste操作第十四頁，共六十八頁。消息：可能讓你失望不要試圖用信息理論或通訊理論中的消息來理解也不要用操作系統中的消息（事件）來理解所謂兩個對象間的一個消息就是一個對象使用了另一個對象的操作(operation)，簡單說就是對象的操作調用！Windows中的SendMessage和PostMessage根本就與面向對象無關！第十五頁，共六十八頁。對象狀態對象狀態只決定于對象的數據，和全局數據、非對象的局部數據無關對象狀態和對象行為之間的關系：<s1,b1>,<s2,b2>,b1=b2iffs1=s2.如果你的程序不滿足這條定理，有兩種情況：類的某個方法使用了全局變量類的某個方法中的局部變量初始值不確定第十六頁，共六十八頁。對象關系：無法讓人滿意目前的面向對象提供了三種對象關系描述手段：繼承聚集（組成）關聯：對象之間有關系！然而，現實世界中實體之間的關系豐富多彩，豈止這三種？第十七頁，共六十八頁。面向對象分析目標：使用對象來描述問題域，進而抽象出問題域類，并把求解問題的約束分配到問題域類關注：是否完整、清晰的描述了問題域及約束雷區：使用DFD，然后把每個處理節點都抽象為一個類雷區：很快就在某個局部（通常為方法）進入算法、編碼面向對象分析模型的價值（領域重用、測試）第十八頁，共六十八頁。面向對象設計目標：引入類（族）實現問題域類（在概念層次上），同時把系統約束分解、落實到類的方法層次關注：體系結構、接口、效率雷區：有些類是‘上帝’，而有些類只是‘弱智的代表’雷區：盲目追求所謂封裝、抽象類面向對象設計模型的價值（設計pattern，風險跟蹤、測試）第十九頁，共六十八頁。適合面向對象的開發過程必須能夠管理面向對象分析、設計、實現、測試、維護各階段的模型的一致性需要給出一套基于類的開發任務管理方法（任務定義、風險管理、任務評審）能夠在開發的不同階段提供不同的知識庫（不僅僅是類庫！）以供重用RUP是個不錯的選擇第二十頁，共六十八頁。面向對象：能與不能Can使你以更有效的手段描述、實現系統提高系統的重用度有效縮短開發周期Cannot避免錯誤，尤其是分析、設計錯誤自動生成精巧的算法第二十一頁，共六十八頁。統一建模語言UML引論建模技術UML的模型圖UML的基本視圖UML的目的、主要特點和和應用領域第二十二頁，共六十八頁。引論WhyUnified?UML是一種建模語言UML的設計目標UML的發展歷程第二十三頁，共六十八頁。WhyUnified?面對眾多的建模語言，用戶沒有能力區別不同語言之間的差別。在眾多的建模語言中，實際上各有千秋，需要取長補短，日臻完善。雖然不同的建模語言大多相同，但仍存在某些細微的差別，這極大地妨礙了用戶之間的交流。第二十四頁，共六十八頁。UML是一種建模語言建模方法=建模語言+建模過程。建模語言定義了用于表示設計的符號(通常是圖形符號)；建模過程描述進行設計所需要遵循的步驟。標準建模語言UML是一種建模語言，而不是一種方法，它統一了面向對象建模的基本概念、術語及其圖形符號，為人們建立了便于交流的共同語言。第二十五頁，共六十八頁。UML的設計目標UML是由Booch，Rumbaugh和Jacobson發起，在Booch方法、OMT方法和OOSE方法的基礎上，集眾家之長，幾經修改而成。UML的設計目標是：運用面向對象概念來構造系統模型(不僅僅針對軟件)建立起從概念模型直至可執行體之間明晰的對應關系著眼于那些有重大影響的問題。創建一種對人和機器都適用的建模語言。第二十六頁，共六十八頁。

UML的發展歷程1994.10，Booch和Rumbaugh將Booch93和OMT-2統一，1995.10.發布UM0.8。1995年秋，經過Booch等三人的努力，1996.6和1996.10發布UML0.9和UML0.91。1996年成立UML成員協會，有700多公司支持UML，占領OO市場的85%。1997.1發布UML1.0，1997.9發布UML1.1。1997.11OMG采納UML1.1作為OO技術的標準建模語言。此后，UML的維護工作由CrisKobryn領導的OMG版本修改小組RTF(RevisionTaskForce)負責.1998.6:UMLV.1.1(編輯修改版).1999.6:UMLV.1.3(技術終訂版).目前正處于UMLV.2.0階段第二十七頁，共六十八頁。UML的發展歷程(續)公眾反饋OOPSLA95UnifiedMethod0.8工業化標準化統一化分散的各部分

Booch93OMT-21996.6和1996.10UML0.9&0.91

1997.11.171997.9公布UML1.1

1997.1公布UML1.0合作伙伴意見UML1.1被OMG

接納為標準其他方法Booch91OMT-1OOSE1999.6UML1.3第二十八頁，共六十八頁。建模技術構造模型的目的建模技術要點系統的多種特性第二十九頁，共六十八頁。構造模型的目的在著手解決一個復雜問題之前，對解決方案進行檢測。用于同客戶和其他相關人員進行交流。加強視覺效果。對復雜問題進行適度簡化。模型是對事物的抽象。人們常常在正式建造實物之前，先建立模型，以便更透徹地了解它的本質，抓住問題的要害。第三十頁，共六十八頁。建模技術要點構造模型的基本技術是抽象，應突出與問題有關的特征，將與問題無關的性質略去。不必追求絕對的真實和完全，只需從期望的目的角度看其是否充分。應當刻畫問題的關鍵方面，略去相對次要的因素。建模語言應支持人的由模糊到清晰、由粗到細逐漸完善的認識過程。應采用可視化圖形建模語言。第三十一頁，共六十八頁。系統的多種特性在功能和性能方面：功能正確，性能良好（效率要高）。在非功能方面：魯棒性、可擴充性、可再用性、兼容性、可移值性、可驗證性、完整性以及易使用性等方面要好。一個系統應具有多方面的特點：一個系統要從多個視角去描述。一個視圖可能包含多個模型圖，每張模型圖都應當簡單明了，易于交流。第三十二頁，共六十八頁。UML的模型圖UML定義了5類、共9種模型圖：用例圖:從用戶角度描述系統的功能，并指出各功能的操作者。靜態圖：類圖、對象圖和包圖(在UML1.1中，包圖不再看作一種獨立的模型圖)。

行為圖：狀態圖，活動圖。交互圖：順序圖，合作圖。實現圖：構件圖描述部件的物理結構以及各部件之間的依賴關系；配置圖定義系統中軟硬件的物理構架。第三十三頁，共六十八頁。關于保險業務的一張用例圖保險銷售人員客戶客戶統計表簽署保險文件銷售統計表第三十四頁，共六十八頁。靜態圖：類圖、對象圖和包圖靜態圖包括類圖、對象圖和包圖，用以描述模型中類及其實例之間的靜態關系。類圖用于定義系統中的類，包括描述類之間的關系(關聯、繼承、聚合)以及類的內部結構，即類的屬性和操作。對象圖顯示類的對象實例，一個對象圖是類圖的一個實例。包圖由包或類組成，主要表示包與包、或包與類之間的關系。包圖用于描述系統的分層結構。第三十五頁，共六十八頁。關于金融貿易的一張類圖客戶業務量商人11..*

Owns1..*1..*

HandlesContains0..*0..*證券債券互助基金股票第三十六頁，共六十八頁。類圖和對象圖類圖展示類Uses0..11..*計算機名字：String內存：Integer作者名字：String年齡：Integer小影：作者名字=“王小影”年齡=32小影的工作PC：計算機名字=“DellPIV”內存=256MB小影的工作PC：計算機名字=“HPPIII”內存=128對象圖展示類的實例第三十七頁，共六十八頁。行為圖：狀態圖，活動圖行為圖包括狀態圖和活動圖，描述系統的動態模型和組成對象間的交互關系。狀態圖描述一類對象的所有可能的狀態以及事件發生時狀態的轉移條件。活動圖描述為滿足用例要求所要進行的活動以及活動間的約束關系。使用活動圖可以很方便地表示并行活動。第三十八頁，共六十八頁。一部電梯的狀態圖上升[幾層]在第一層上升[幾層]向第一層下降下降狀態空閑狀態上升狀態到達[第幾層]到達[第幾層]下降[幾層]超時[]第三十九頁，共六十八頁。一臺打印機服務器的活動圖創建附加文件顯示"磁盤已滿"的信息顯示"正在打印"的信息[磁盤已滿][尚有磁盤空間]打印機,打印[文件]刪除顯示信息的對話框第四十頁，共六十八頁。交互圖：順序圖，合作圖交互圖包括順序圖和合作圖，它描述對象間的交互(動態合作)關系。順序圖：用以顯示對象之間在時間順序方面的動態合作關系。因此，如果強調時間和順序，應當使用順序圖。合作圖：著重描述對象間的通信方面的動態合作關系。因此，如果強調通信關系，則可以選擇合作圖。第四十一頁，共六十八頁。一臺打印機服務器的順序圖:計算機:打印服務程序:打印機:打印隊列〔打印機空閑〕打印〔文件〕〔打印機忙〕打印〔文件〕打印〔文件〕第四十二頁，共六十八頁。一臺打印機服務器的合作圖[打印機忙]1.2保存[文件]:計算機:打印隊列1:打印[文件]:打印服務程序:打印機[打印機空閑]1.1打印[文件]第四十三頁，共六十八頁。實現圖：構件圖，配置圖實現圖包括構件圖和配置圖。構件圖：描述部件的物理結構以及各部件之間的依賴關系。配置圖：定義系統中(特別是在分布式及網絡環境中)軟硬件的物理構架。第四十四頁，共六十八頁。反映程序代碼構件之間

依賴關系的構件圖

main.obj:主類comhnd.obj:命令處理器Whnd.obj:窗口處理器client.exe:客戶程序graphic.dll:圖形庫comhnd.cpp:命令處理器Whnd.cpp:窗口處理器

main.cpp:主類第四十五頁，共六十八頁。描述系統物理構架的配置圖《DecNet協議》客戶A：個人電腦PC客戶B：個人電腦PC《TCP/IP協議》《TCP/IP協議》服務器：02數據庫服務器:VAX第四十六頁，共六十八頁。UML的基本視圖UML的用例視圖UML的邏輯視圖UML的構件視圖UML的并發視圖UML的配置視圖第四十七頁，共六十八頁。UML的五類基本視圖構件示圖用例視圖配置視圖邏輯視圖并發視圖第四十八頁，共六十八頁。UML的五類基本視圖(續)用例視圖：從系統外部執行者的角度理解、展示系統功能。邏輯視圖：從系統的靜態結構和動態行為的角度展示系統內部功能性設計。構件示圖：展示代碼構件的組織結構。并發視圖：展示系統的并發性，刻畫并發系統中的通訊和同步問題。配置視圖：展示系統的物理的體系結構，其中用到的計算機和各種設備稱作節點。第四十九頁，共六十八頁。UML的用例視圖從系統外部執行者的角度理解系統的功能：它描述執行者與系統的交互，其執行者可以是一個用戶，也可以是另一個系統。用例圖面向客戶、建模人員、開發人員和測試人員，是系統模型圖的核心。用例視圖：用例圖和活動圖描述。一張用例圖是系統的一種用途的描述；一組用例圖描述了整個系統所期望的用途。第五十頁，共六十八頁。UML的邏輯視圖描述系統如何提供要求的功能：靜態結構：類(界面，內部結構)；對象；關系用類圖和對象圖描述。動態行為：對象之間相互發送消息而引發的動態合作關系用狀態圖、順序圖、合作圖和活動圖描述各種特性：永久性，并發性主要是面向設計人員和開發人員第五十一頁，共六十八頁。UML的構件視圖描述實現的各個模塊及其相互之間的關系：模塊的內部結構模塊間的依賴關系關于各構件的一些附加信息：資源分配(構件的責任)其它管理信息，如開發工作的進展報告等主要面向開發人員構件視圖：由構件圖組成，其中構件表示不同類型的代碼模塊第五十二頁，共六十八頁。UML的并發視圖系統中進程和處理器的劃分與任務的分配屬于非功能性特性：著眼于資源的有效利用并行執行，并發地執行多線程控制，處理線程之間的通信和同步處理來自外部環境的同步事件面向開發人員和系統集成人員描述并發視圖的主要模型圖：動態圖：狀態圖，合作圖，活動圖實現圖：構件圖，配置圖第五十三頁，共六十八頁。UML的配置視圖展示系統的物理配置，如計算機和其它設備(統稱結點)及其相互之間的連接關系，包括在物理的體系結構中如何配置構件的映像關系。面向開發、集成和測試人員。配置視圖用配置圖描述。第五十四頁，共六十八頁。面向對象描述的三個層面概念層說明層實現層BusinessModelArchitectureDetailing 1：層次間沒有分解對應關系 2：每個面向對象描述元素都可對應到這三個層面!第五十五頁，共六十八頁。UML的主要特點、目的和應用領域UML的主要特點使用UML的目的UML的應用領域第五十六頁，共六十八頁。

UML的主要特點UML統一了Booch，OMT和OOSE等方法中的基本概念：用例圖從OOSE來；類圖從OMT和Booch等方法來；實現圖(構件圖和配置圖)從Booch的模塊圖和過程圖來。UML吸取了OO技術領域各流派的長處：狀態圖從Harel而來；活動圖從工作流圖而來；合作圖從Booch的對象圖和Fusion的對象交互作用圖等而來；等等。在演變過程中UML提出了一些新的概念。第五十七頁，共六十八頁。使用UML的目的軟件開發的過程猶如雕琢一件藝術品，由無形到有形，由粗到細。但軟件開發的最終形式必須生成程序代碼。因此當考慮使用UML時，一定要想清楚，使用UML的目的以及對編寫代碼有何幫助。學習面向對象技術和領域專家交流幫助理解全局第五十八頁，共六十八頁。學習面向對象技術UML的各種模型圖，其中用例圖描述系統的功能及其外部的使用者，確定誰使用系統以及做什么。類圖描述系統的靜態構架，即構成系統的各種對象類及其相互關系。對象圖是類圖的實例化，描述系統在某個時刻可能包含的對象和相互關系。行為圖和交互圖描述系統的動態行為。構件圖和配置圖描述系統實現體的構成及其在硬件環境中的配置情況。第五十九頁，共六十八頁。和領域專家交流有效的方法是使用用例。一個用例描述了系統的某一側面，所有用例構成了系統的整個外觀。用例也有助于制訂項目規劃和對問題進行深入理解。類圖很有用，但應注重在概念層上使用。應將每個類對應用戶心中一個概念，并用用戶的語言來命名和定義。對于側重于工作流過程的應用系統，活動圖非常有用。活動圖也有助于對實際業務流程中的并行特性進行自然描述。第六十頁，共六十八頁。幫助理解全局對于大型項目，常常只見樹木不見森林，采用UML有助于理解全局。譬如，類圖可了解系統中有哪些類型的事物，哪些需要作進一步的考察。對大型軟件，無論概念層、說明層或實現層，其模型都可能十分龐大。此時通常需要分層次地繪制很多張模型圖，并為整個軟件系統建立全局路線圖。在較高的抽象層次，用包圖刻畫類圖的分組情況。第六十一頁，共六十八頁。UML的應用領域UML是一個通用的標準建模語言，可對任何具有靜態結構和動態行為的系統進行建模。UML適用于系統開發的不同階段：需求分析階段用用例；分析階段用類圖；實現階段用動態模型；構造階段用OO編程語言。在測試階段：單元測試用類圖；集成測試用部件圖和合作圖；系統測試用用例圖。在應用標準建模語言UML