UML系統(tǒng)分析與設計緒論ppt課件

第一章 緒 論,UML系統(tǒng)分析與設計,1,1. 面向?qū)ο?2. UML簡介 3. UML發(fā)展史,2,1.1 面向?qū)ο?20 世紀 60 年代提出概念到現(xiàn)在，逐步發(fā)展成為開發(fā)領域的主流技術。,3,面向?qū)ο笫荱ML的基礎,UML建模語言的出現(xiàn)正是由于面向?qū)ο蠼Ｋ枷氚l(fā)展的產(chǎn)物，它是軟件工程領域公認的面向?qū)ο蟮慕ＵZ言。 可以毫不夸張的說，沒有面向?qū)ο?，就沒有 UML，它們的關系密不可分。,4,面向?qū)ο蠓椒ń?jīng)歷了這樣的發(fā)展過程，它首先在編程領域興起，作為一種嶄新的程序設計范型引起世人矚目。 20世紀80年代一大批面向?qū)ο缶幊陶Z言問世，標志著面向?qū)ο蠓椒ㄗ呦虺墒旌蛯嵱?。此時面向?qū)ο蠓椒ㄩ_始向系統(tǒng)分析與設計階段延伸，出現(xiàn)了一批早期的面向?qū)ο笤O計方法。 至1994年，公開發(fā)表并具有一定影響力的面向?qū)ο蠓治雠c設計方法達到 50 余種。這些方法的主導思想及原則大體上是一致的，但也存在不同差異，這阻礙了面向?qū)ο蠓椒ㄒ恢碌姆较虬l(fā)展，給用戶選擇帶來困惑。則這種形勢下，統(tǒng)一建模語言應運而生。,面向?qū)ο笫荱ML的基礎,5,面向?qū)ο蠡靖拍?什么叫面向?qū)ο? 面向?qū)ο蠹夹g是一種以對象為基礎，以事件或消息來驅(qū)動對象執(zhí)行處理的程序設計技術。 從程序設計方法上來講，它是一種自下而上的程序設計方法，它不像面向過程程序設計那樣一開始就需要使用一個主函數(shù)來概括出整個程序，面向?qū)ο蟪绦蛟O計往往從問題的一部分著手，一點一點地構建出整個程序。,6,軟件,計算機軟件是計算機系統(tǒng)中的程序以及有關的文檔。 程序是計算任務的處理對象（數(shù)據(jù)）與處理規(guī)則（算法）的描述。 文檔是為了便于人們理解程序所需的資料說明，供程序開發(fā)與維護使用。,7,軟件的生命周期,軟件需求分析 軟件設計 編程實現(xiàn) 測試 運行 維護,8,程序設計,程序設計就是為計算機編制程序的過程。 程序設計的本質(zhì)是對計算進行描述，這里的計算是指廣義上的計算，而不是簡單的加、減、乘、除等算術運算。以不同的方式來給出計算的描述就形成了程序設計的范型。程序包括數(shù)據(jù)以及對數(shù)據(jù)的加工兩部分，程序設計范型就是指以何種觀點來看待、組織和描述他們。 目前典型的程序設計范型：過程式和對象式。,9,過程式程序設計,過程式程序設計以功能為中心，基于功能進行分解。過程式程序由一些子程序（功能單位）構成。子程序是操作的封裝體，每個子程序?qū)粋€功能，實現(xiàn)了功能的抽象。過程式程序的執(zhí)行過程體現(xiàn)為一系列的子程序調(diào)用。 在過程式程序中，數(shù)據(jù)處于附屬地位，它獨立于子程序，在子程序調(diào)用時作為參數(shù)傳給子程序使用， 下面公式刻畫了過程式程序設計的本質(zhì)特征 程序 = 算法 + 數(shù)據(jù)結構 早期的程序大多采用過程式設計。,10,對象式程序設計,對象式程序設計是一種以數(shù)據(jù)為中心、基于數(shù)據(jù)抽象的程序設計范型。一個對象式程序有一些對象構成，對象是由一些數(shù)據(jù)及可施于這些數(shù)據(jù)上的操作所構成的封裝體，對象的特征有相應的類來描述。面向?qū)ο蟪绦虻膱?zhí)行過程體現(xiàn)各個對象之間相互發(fā)送和處理消息。 面向?qū)ο蟪绦蚩珊唵蔚乇硎境上旅娴墓剑?程序 = 對象/類 + 對象/類 + 對象/類 = 數(shù)據(jù) + 操作,11,面向?qū)ο蟪绦蛟O計,面向?qū)ο蟪绦蛟O計就是把程序構造成若干對象組成，每個對象由一些數(shù)據(jù)和對這些數(shù)據(jù)所實施的操作構成； 對數(shù)據(jù)的操作通過向包含數(shù)據(jù)的對象發(fā)送消息來實現(xiàn)（調(diào)用對象的操作）； 對象的特性（數(shù)據(jù)與操作）由（對象）類來描述，一個類的特性可以從其它的類繼承。,12,面向?qū)ο蟪绦蛟O計,包含以下基本概念： 對象：對象式計算的基本單位，由：接口，數(shù)據(jù)，操作構成。 通信：引起對象式計算的唯一方式 類 ：對象特性的描述 繼承：復用機制。,13,為什么要面向?qū)ο?一個好的軟件開發(fā)方法或技術的評價標準：開發(fā)效率和軟件質(zhì)量保證。 開發(fā)效率指方法使用的難易程度和方法縮短開發(fā)周期的程度； 軟件質(zhì)量包括：外部質(zhì)量和內(nèi)部質(zhì)量； 外部質(zhì)量：與用戶有關的質(zhì)量因素，包括正確性、效率、可靠性、可用性和可擴展性等方面 內(nèi)部質(zhì)量：與軟件開發(fā)人員有關的質(zhì)量因素，包括可讀性和可維護性等。,14,為什么要面向?qū)ο?在面向?qū)ο蟪绦蛟O計之前，面向過程結構化程序設計占據(jù)主要的地位，結構化程序設計是一種自上而下的設計方法，以函數(shù)為中心，用一個主程序來概括出整個程序需要做的事，主函數(shù)是由一系列子函數(shù)組成。 對于比較復雜的問題或在開發(fā)中需求變化比較多的時候，結構化程序設計往往顯得力不從心。事實上，在問題比較復雜的時候，要求設計者自上而下一開始就對需要解決的問題有全面的理解會比較困難。當需求發(fā)生變化時，以前的問題理解也許會變得不在適用。,15,為什么要面向?qū)ο?面向過程程序設計把數(shù)據(jù)和對數(shù)據(jù)的操作分離，使得大型程序的編寫比較困難，難于調(diào)試和修改。在很多人進行協(xié)同開發(fā)的項目組中，程序員之間很難讀懂對方的代碼，代碼的重用變得十分困難。 面向?qū)ο笠詫ο鬄榛A，以事件和消息來驅(qū)動對象執(zhí)行處理的程序設計。是一種自下而上的程序設計方法，往往從問題的一部分著手，一點點地構建整個程序。,16,（1）抽 象,過程抽象來源于子程序的概念。 子程序的作用有兩個：節(jié)省勞動力和過程抽象。過程抽象把子程序的接口和實現(xiàn)分開，使用者只需要知道知道子程序的接口（功能和參數(shù)）而不需要關心其內(nèi)部實現(xiàn)，適合于基于功能分解、逐步精化的過程式程序設計。 缺點與不足：數(shù)據(jù)與操作的描述分離，不能適應需求的改變。,17,數(shù)據(jù)抽象以數(shù)據(jù)為中心，把數(shù)據(jù)及其操作作為一個整體（對象）來進行描述，對數(shù)據(jù)的操作由包含數(shù)據(jù)的對象來提供。 面向?qū)ο蟪绦蛟O計強調(diào)的是數(shù)據(jù)抽象，一方面加強了數(shù)據(jù)保護，另一方面實現(xiàn)了對世界活動的直接模擬，能較好的適應需求的變化。 不足之處：對系統(tǒng)的整體功能缺乏清楚的描述。,（1）抽 象,18,把具體實現(xiàn)細節(jié)作為一個黑匣子，對使用者隱藏的一種機制。過多的暴露實現(xiàn)細節(jié)，無論對使用者還是對實現(xiàn)者都是不利的。 對于使用者而言，如果其功能的執(zhí)行要依賴所使用的語言結構的內(nèi)部實現(xiàn)，那么，當使用的語言結構的內(nèi)部實現(xiàn)變化時，其必須也要做相應的改變； 對于實現(xiàn)者而言，如果過多地暴露實現(xiàn)細節(jié)，則不得不謹慎的處理任何實現(xiàn)上的改變，從而不至于影響太多的使用者。封裝考慮的是內(nèi)部實現(xiàn)，抽象考慮的是外部行為。,（2）封 裝,19,過程封裝實現(xiàn)了操作的封裝，而數(shù)據(jù)是公開的，缺乏數(shù)據(jù)的保護。 數(shù)據(jù)封裝實現(xiàn)了數(shù)據(jù)及其操作的封裝，加強了數(shù)據(jù)的保護。 面向?qū)ο蟪绦蛟O計實現(xiàn)了數(shù)據(jù)封裝。,（2）封 裝,20,（3）模塊化,模塊化是處理大而復雜問題的重要手段，同時也是保證軟件質(zhì)量的有力措施，一個好的軟件開發(fā)方法應能支持模塊化。 程序設計中的模塊是指可以分別編譯的程序單位或程序在物理上的劃分。 模塊包含接口和實現(xiàn)兩部分。 模塊化的目標：可分解、可結合、可理解、連續(xù)性和保護性。 面向?qū)ο髮δK有更好的支持：對象/類,21,軟件復用的層次：代碼復用、設計過程復用和分析方案復用，代碼復用最直接、最廣泛。 傳統(tǒng)的復用機制：源代碼的剪裁和子程序庫 面向?qū)ο蟮膹陀脵C制：繼承和類庫,（4）軟件復用,22,傳統(tǒng)的軟件開發(fā)方法通常是基于自頂向下、功能分解的方法，面臨的問題是：由于功能分解模型較難與現(xiàn)實世界的實際系統(tǒng)相吻合，開發(fā)的軟件系統(tǒng)難以適應需求的變化。 面向?qū)ο蠓椒ㄩ_發(fā)軟件能夠減小個階段之間的語義間隙，使得開發(fā)過程平穩(wěn)過渡，提高軟件的可維護性，特別是對需求變化的適應性。,（5）軟件開發(fā)過程,23,面向?qū)ο蟪绦蛟O計的基本內(nèi)容,1. 對象與類 對象由數(shù)據(jù)變量及其操作方法所構成的封裝體。 類是對象特性的描述，一個類刻畫了具有相同特性的對象，是創(chuàng)建對象的模板。對象是類的實例。 對象屬于值的范疇，而類屬于類型的范疇。 對象與類實現(xiàn)數(shù)據(jù)抽象、封裝、模塊。,24,面向?qū)ο蠡靖拍?2. 消息與事件 消息是指描述事件發(fā)生的信息，是對象間相互聯(lián)系和相互作用的方式。一個消息主要由 5 部分組成：消息的發(fā)送對象、消息的接收對象、消息傳遞方式、消息內(nèi)容、消息的返回。事件通常是指一種由系統(tǒng)預先定義而由用戶或系統(tǒng)發(fā)出的動作。事件作用于對象，對象識別事件并作出相應反應。 對象通過對外提供的方法在系統(tǒng)中發(fā)揮自己的作用，當系統(tǒng)中的其它對象請求這個對象執(zhí)行某個方法時，就向該對象發(fā)送一個消息，對象響應這個請求，完成指定的操作。程序的執(zhí)行取決于事件發(fā)生的順序，由消息來驅(qū)動程序的執(zhí)行。,25,3. 繼承 繼承是一種連接類與類之間的層次模型。繼承是指特殊類的對象擁有其一般類的屬性和行為。 繼承意味著“自動地擁有”，即在特殊類中不必重新對已經(jīng)在一般類中所定義過的屬性和行為進行定義，而是特殊類自動地、隱含地擁有其一般類的屬性和行為。 繼承實現(xiàn)了對類的重用性，提供一種明確表述共性的方法。即一個特殊類既有自己定義的屬性和行為，又有繼承下來的屬性和行為。,面向?qū)ο蟪绦蛟O計的基本內(nèi)容,26,面向?qū)ο蟪绦蛟O計的基本內(nèi)容,3. 繼承 繼承是實現(xiàn)軟件復用的重要機制。 在繼承機制中，類分為父類（基類）與子類（派生類），子類除了包含父類的屬性以外，也可以定義新的屬性，或重新定義父類的屬性?？梢允菃卫^承（一個類最多有一個直接父類）與多繼承（一個類可以有多個直接父類）。,27,4. 多態(tài) 多態(tài)性是指在兩個或多個屬于不同類中同一函數(shù)名對應多個具有相似功能的不同函數(shù)，可以使用相同的調(diào)用方式來調(diào)用這些具有不同功能的同名函數(shù)。,面向?qū)ο蟪绦蛟O計的基本內(nèi)容,28,面向?qū)ο蟪绦蛟O計的基本內(nèi)容,4. 多態(tài) 多態(tài)是程序設計的一個重要概念，指一個元素可以有多種解釋。 一名多用或重載，如：操作符重載或函數(shù)重載。 類屬，類屬函數(shù)與類屬類型。 消息的多態(tài)：一個公共消息可以發(fā)送到不同種類對象，得到不同的處理。 對象類型的多態(tài)：一個對象可以屬于多種類型，如：派生類的對象也屬于基類。 對象標識符的多態(tài)：基類的指針或引用可以指向或引用基類和派生類對象。 多態(tài)可以提高語言的可擴充性以及高層軟件的復用。,29,面向?qū)ο蠛晚椖吭O計,1. 用面向?qū)ο蠓椒ǚ治鲰椖啃枨?30,面向?qū)ο蠛晚椖吭O計,2. 用面向?qū)ο蟮姆椒ㄔO計系統(tǒng) 面向?qū)ο笤O計的準則包括模塊化、抽象、信息隱藏、低耦合和高內(nèi)聚等特征。 系統(tǒng)設計是問題求解及建立解答的高級策略。必須制定解決問題的基本方法，系統(tǒng)的高層結構形式包括子系統(tǒng)的分解、子系統(tǒng)分配硬軟件、數(shù)據(jù)存儲管理、人機交互接口等等。系統(tǒng)設計一般是先從高層入手，然后細化。 系統(tǒng)設計要決定整個結構及風格，這種結構為后面設計階段更詳細策略的設計提供了基礎。,31,用面向?qū)ο笏枷虢⒛Ｐ?瀑布模型 瀑布模型也被稱為生存周期模型，其核心思想是按照相應的工序?qū)栴}進行簡化，將系統(tǒng)功能的實現(xiàn)與系統(tǒng)的設計工作分開，便于項目之間的分工與協(xié)作，即采用結構化的分析與設計方法將邏輯實現(xiàn)與物理實現(xiàn)分開。瀑布模型將軟件生命周期劃分為軟件計劃、需求分析和定義、軟件設計、軟件實現(xiàn)、軟件測試、軟件運行和維護這6個階段，并且規(guī)定了它們自上而下的次序，如同瀑布一樣下落。每一個階段都是依次銜接的。,32,用面向?qū)ο笏枷虢⒛Ｐ?噴泉模型 噴泉模型是一種以對象為驅(qū)動、以用戶需求為動力的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過程。該模型認為軟件開發(fā)過程自下而上，周期的各階段是相互重疊和多次反復的，就像水噴上去又可以落下來，類似一個噴泉。,33,用面向?qū)ο笏枷虢⒛Ｐ?基于組件的開發(fā)模型 基于組件的開發(fā)模型利用模塊化方法將整個系統(tǒng)模塊化，并在一定組件模型的支持下復用構件庫中的一個或多個軟件組件，通過組合手段高效率、高質(zhì)量地構造應用軟件系統(tǒng)的過程。,34,用面向?qū)ο笏枷虢⒛Ｐ?XP開發(fā)模型 敏捷方法強調(diào)適應性而非預測性、強調(diào)以人為中心，而不以流程為中心的軟件開發(fā)過程。其特點是輕載、基于時間、緊湊、并行并基于構件。 在所有的敏捷方法中，XP（eXtreme Programming）方法是最引人注目的一種輕型開發(fā)方法。它規(guī)定了一組核心價值和方法，消除了大多數(shù)重量型開發(fā)過程中的不必要產(chǎn)物，建立了一個漸進型開發(fā)過程。,35,1.2 UML簡介,36,UML簡介,Unified Modeling Language ,“統(tǒng)一建模語言” 近十幾年來面向?qū)ο蟪绦蛟O計最重要的成果 主要由 Grady Booch， James Rumbaugh, Ivar Jacobson 等貢獻者于1995年推出 中文網(wǎng)站 http:/www. ,37,UML 用來對軟件密集系統(tǒng)進行可視化建模的一種語言，也是為面向?qū)ο箝_發(fā)系統(tǒng)的產(chǎn)品進行說明、可視化、構造和編制文檔的一種標準語言。 UML 作為一種模型語言，它使開發(fā)人會專注于建立產(chǎn)品的模型和結構，而不是選擇什么程序和算法實現(xiàn)。當模型建立后，模型可以被 UML 工具轉化成指定的程序語言代碼。,UML簡介,38,常見的UML建模工具： Rational Rose Microsoft Visio,UML簡介,39,統(tǒng)一建模語言UML是一組圖形表示法。這些表示法的背后有共同的元模型。 UML幫助描述和設計軟件系統(tǒng)，特別是面向?qū)ο箫L格建造的軟件系統(tǒng)。 圖形建模語言在軟件業(yè)已經(jīng)出現(xiàn)很長時間了。背后的基本驅(qū)動力就是：編程語言的抽象級別不夠高，不方便討論設計。,UML簡介,40,UML 擁有一套完整而成熟的建模技術，被廣泛的運用于各種不同的領域。借助于基于面向?qū)ο蟮腢ML可以幫助軟件工程的開發(fā)人員更好的了解業(yè)務流程，建立更可靠、更完善的系統(tǒng)模型，從而方便我們對各種軟件工程進行正確的描述和交流。,UML簡介,41,為什么要花時間學UML,圖形設計表示法已經(jīng)出現(xiàn)了一段時間了，UML的首要價值是溝通和理解。好的圖形經(jīng)?？梢詭椭鷾贤ㄔO計思想，特別是當你要回避許多細節(jié)時，也可以幫助你理解軟件系統(tǒng)和業(yè)務流程。作為團隊的一份子，圖形有助于理解和溝通整個團隊所理解到的東西。 在這些圖形表示法中，UML的重要性來自它在面向?qū)ο蟪绦蛟O計內(nèi)部的廣泛使用和標準化，而且UML不僅已經(jīng)是面向?qū)ο笫澜缰姓贾涞匚坏膱D形表示法，而且在非面向?qū)ο笕ψ永镆卜浅Ａ餍小?42,使用UML的方式,草稿 藍圖 編程語言,43,使用UML的方式,把UML當做草稿：開發(fā)人員使用 UML 協(xié)助溝通系統(tǒng)的某些方面，可以粗略的畫出即將要編碼的東西，通常要和團隊中的一群人討論。使用草稿的目的是來幫助溝通想法或展示所要作的事情的可選方案。你不會談論即將要寫的所有代碼，只會和同事談論一下重要的東西，像這樣的會議可以很短，如花10分鐘來討論需要幾個小時進行的編程，或者用半天來討論一個需要幾周來進行的編程。,44,把UML當作藍圖：需要關心完整性。一般由一名設計人員開發(fā)藍圖，為程序員建造詳細設計，然后程序員在此基礎上編碼。設計應該足夠完整，列出所有設計決策，程序員應該能夠跟隨設計，把編碼當做相當直接的活動。設計人員和程序員可以是同一個人，但通常設計人員是一名更高級的開發(fā)人員，他為一個團隊的程序作設計。就如同設計師出設計圖紙，移交建筑公司來建造。設計人員開發(fā)藍圖級模型一般只做到子系統(tǒng)的接口，而開發(fā)人員負責實現(xiàn)細節(jié)。 藍圖和草稿之間的界限有些模糊，但是，兩者的區(qū)別基于這個事實：草稿故意畫成不完整，強調(diào)重要信息，而藍圖傾向于全面，目的是把編程縮減成簡單的機械活動。草稿是探索性的，藍圖是定義性的。,使用UML的方式,45,把UML當作編程語言：在UML方面做的越多，編程變得越機械，顯然這時編程應該被自動化，事實上，有很多CASE工具是生成某些形式的代碼，自動化的建造系統(tǒng)的重要部分，最終達到一個境界整個系統(tǒng)可以用UML來表述。在這個環(huán)境下，開發(fā)人員畫UML圖，直接編譯為可執(zhí)行代碼UML變成了源代碼。,使用UML的方式,46,1.3 UML簡史,47,UML的產(chǎn)生和成長,UML統(tǒng)一建模語言是一種建模語言是第三代用來為面向?qū)ο箝_發(fā)系統(tǒng)的產(chǎn)品進行說明可視化和編制文檔的方法。它是由信息系統(tǒng)和面向?qū)ο箢I域的三位著名的方法學家Grady Booch、James Rumbaug和Ivar Jacobson提出的，這種建模語言得到了UML伙伴聯(lián)盟的應用與反饋，并得到工業(yè)界的廣泛支持，并由OMG組織采納作為業(yè)界標準。 這是軟件界第一次有了一個統(tǒng)一的建模語言。,48,20 世紀 80 年代，對象開始離開實驗室，邁出走向真實世界的第一步，C+誕生了，這時，各種人開始考慮面向?qū)ο髨D形設計語言。 面向?qū)ο髨D形建模語言的關鍵書籍出現(xiàn)在1988年到1992年之間。領導人物包括Grady Booch、 Peter Coad、 Ivar Jacobson、Jim Odell、Jim Rumbaugh、Sally Shally等。這些作者的每一位現(xiàn)在都非正式地領導著一組喜歡他們的思想的實踐者。所有這些方法都非常相似，然而它們之間包含許多經(jīng)常會讓人惱火的細小差別。同一個基本概念以差別很大的表示法出現(xiàn)，導致了客戶產(chǎn)生混淆。,UML的產(chǎn)生和成長,49,在這個艱難的時期，也有人談到標準化，但沒人理睬。 首次引發(fā)創(chuàng)建UML的催化劑事件是Jim Rumbaugh 離開 GE 加盟 Grady Booch所在的Rational。 Booch/Rumbaugh聯(lián)盟從一開始就被視為可以達到市場份額的臨界值。Grady 和 Jim宣稱“方法戰(zhàn)爭結束了我們贏了”，基本上就宣布了他們打算“以微軟的方式”達成標準化。許多其他方法學家建議成立一個反Booch同盟。,UML的產(chǎn)生和成長,50,在OOPSLA 95大會上，Grady和Jim首次公開描述他們合并的方法：統(tǒng)一方法文檔版本0.8。他們宣布Rational軟件購買了Objectory，因此，Ivar Jacobson將加入統(tǒng)一團隊。 接下來的一年更加開放的合并過程出現(xiàn)了，此時需要花時間和其他伙伴溝通。此時OMG擔當主角。導致OMG介入的是軟件工具廠商的呼吁，他們害怕標準被Rational控制， Rational工具會得到不公平的競爭優(yōu)勢。 1997年1月，各種組織一起提交了方法標準的建議書，以方便模型的交換。Rational和其他許多組織一起協(xié)作，發(fā)布了UML文檔版本1.0作為他們的建議，這時UML第一次被叫做統(tǒng)一建模語言。,UML的產(chǎn)生和成長,51,接下來是短回合的掰手腕的過程，各種建議書被合并。OMG采納1.1版本作為官方的OMG標準。稍后又做了一些修訂。 修訂1.2完全是走走過場。 修訂1.3更加重要。 修訂1.4圍繞組件和擴展機制添加了許多詳細的概念。 修訂1.5添加了動作語義。,UML的產(chǎn)生和成長,52,當人們談論UML時，會把創(chuàng)造者的功勞主要歸于Grady Booch、Ivar Jacobson和Jim Rumbaugh，他們一般被稱為“三友”。但實際上，UML表示法首先成型于Booch/ Rumbaugh統(tǒng)一方法，從那時候開始很多工作就由OMG委員會領導了。在后來這些階段中， Jim Rumbaugh是“三友”中唯一做出重要貢獻的。UML過程委員會的那些成員稱得上首要的UML功臣。,UML的產(chǎn)生和成長,53,54,