補充1-1-統(tǒng)一建模語言UML

補充1

統(tǒng)一建模語言UML

軟件工程領(lǐng)域在1995年至1997年取得了前所未有的進展，其成果超過軟件工程領(lǐng)域過去15年來的成就總和。其中最重要的、具有劃時代意義的成果之一就是統(tǒng)一建模語言(UnifiedModelingLanguage,UML)的出現(xiàn)。在世界范圍內(nèi),至少在近10年內(nèi),UML將是面向?qū)ο蠹夹g(shù)領(lǐng)域內(nèi)占主導(dǎo)地位的標準建模語言。1補充1

統(tǒng)一建模語言UML掌握UML特點和基本圖標元素的表示符掌握UML軟件系統(tǒng)體系結(jié)構(gòu)的5種視圖和10種基本模型圖了解UML的用例模型、靜態(tài)模型、動態(tài)模型的簡單建模方法了解UML的系統(tǒng)體系結(jié)構(gòu)模型掌握UML與軟件開發(fā)統(tǒng)一過程目的：2補充1統(tǒng)一建模語言UML2.1UML模型系統(tǒng)體系結(jié)構(gòu)2.2UML系統(tǒng)模型與建模2.3UML系統(tǒng)體系結(jié)構(gòu)模型2.4UML的擴展、調(diào)整機制（略）2.5UML與面向?qū)ο蟮能浖_發(fā)統(tǒng)一過程32.1

UML模型系統(tǒng)體系結(jié)構(gòu)2.1.1UML的誕生與發(fā)展2.1.2UML的特點和主要作用2.1.3

軟件系統(tǒng)體系結(jié)構(gòu)的描述2.1.4UML模型元素42.1.1UML的誕生與發(fā)展一.UML簡介UML是軟件界第一個統(tǒng)一的建模語言可用于多種類型軟件系統(tǒng)開發(fā)建模的各個階段，具有創(chuàng)建系統(tǒng)的靜態(tài)結(jié)構(gòu)和動態(tài)行為等多種結(jié)構(gòu)模型的能力，具有可擴展性和通用性，適合于多種多變結(jié)構(gòu)系統(tǒng)的建模。UML的價值在于它綜合體現(xiàn)了國際上各種面向?qū)ο蠓椒▽嵺`的最好經(jīng)驗，支持用例驅(qū)動，以體系結(jié)構(gòu)為中心以增量和迭代的方式進行軟件開發(fā)。52.1.1UML的誕生與發(fā)展一.UML簡介Unified:表示UML在全世界的使用范圍非常廣泛，被應(yīng)用于很多領(lǐng)域。Modeling:表示UML的主要用途是進行系統(tǒng)建模，即進行系統(tǒng)規(guī)劃的描述。Language:表示UML只是一種建模語言，而不是一種編程語言或某種標記語言。61994年10月，GradyBooch和JamesRumbaugh開始致力于UML開發(fā)工作。他們首先對Booch方法和OMT方法進行了合并，并于1995年10月發(fā)布了第一個公開版本，稱之為統(tǒng)一方法UM0.8（UnitiedMethod）。1995年秋,IvarJacobson加入GradyBooch和JamesRumbaugh的這一工作中來，并引入了其用例（UseCase）思想。經(jīng)過

Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分別發(fā)布了兩個新的版本，即UML0.9和UML0.91,并將UM重新命名為UML（UnifiedModelingLanguage）。

二.UML的誕生與發(fā)展2.1.1UML的誕生與發(fā)展71996年底，UML已穩(wěn)占面向?qū)ο蠹夹g(shù)市場85%的份額，已經(jīng)逐漸成為可視化建模語言事實上的工業(yè)標準。1997年1月，UML1.0版本被提交到OMG(對象管理組織)，作為軟件建模語言標準化的候選。1997年11月7日OMG正式采納，并把UML作為業(yè)界標準。1998年OMG接管了UML標準的維護工作，推出了UML的1.3版、1.4版、1.5版，后來又推出了2.0版。

2.1.1UML的誕生與發(fā)展二.UML的誕生與發(fā)展8UML的簡要發(fā)展歷程如圖所示：2.1.1UML的誕生與發(fā)展9102.1.2UML的特點和主要作用一.UML的特點統(tǒng)一標準：UML統(tǒng)一了Booch、OMT和OOSE等方法中的基本概念，已成為OMG的正式標準，提供了標準的面向?qū)ο蟮哪Ｐ驮氐亩x和表示。面向?qū)ο螅篣ML還吸取了面向?qū)ο蠹夹g(shù)領(lǐng)域中其他流派的長處。UML符號表示考慮了各種方法的圖形表示，刪掉了大量易引起混亂的、多余的和極少使用的符號，也添加了一些新符號。112.1.2UML的特點和主要作用一.UML的特點可視化、表達能力強：系統(tǒng)的邏輯模型或?qū)崿F(xiàn)模型都能用UML模型清晰地表示，可用于復(fù)雜軟件系統(tǒng)的建模。獨立于過程：UML是系統(tǒng)建模語言，不依賴特定的程序設(shè)計語言，獨立于開發(fā)過程。易掌握、易用：由于UML的概念明確，建模表示法簡潔明了，圖形結(jié)構(gòu)清晰，易于掌握使用。122.1.2UML的特點和作用

1.為軟件系統(tǒng)建立可視化模型

UML符號具有良好的語義，不會引起歧義；基于UML的可視化模型，使系統(tǒng)結(jié)構(gòu)直觀、易于理解；使用UML進行軟件系統(tǒng)的模型不但有利于系統(tǒng)開發(fā)人員和系統(tǒng)用戶的交流，還有利于系統(tǒng)維護。概括起來說，UML主要有如下作用：二.UML的主要作用132.1.2UML的特點和作用2.為軟件系統(tǒng)建立構(gòu)件

UML不是面向?qū)ο蟮木幊陶Z言，但它的模型可以直接對應(yīng)到各種各樣的編程語言。例如：它可以使用代碼生成器工具將UML模型轉(zhuǎn)換為多種程序設(shè)計語言代碼，如：可生成C++、XMLDTD、JAVA、VisualBasic等語言的代碼，或使用反向生成器工具將程序源代碼轉(zhuǎn)換為UML；甚至還可以生成關(guān)系數(shù)據(jù)庫中的表。二.UML的主要作用142.1.2UML的特點和作用3.為軟件系統(tǒng)建立文檔

UML可以為系統(tǒng)的體系結(jié)構(gòu)及其所有細節(jié)建立文檔。不同的UML模型圖可以作為項目不同階段的軟件開發(fā)文檔。

二.UML的主要作用152.1.3

軟件系統(tǒng)體系結(jié)構(gòu)的描述

UML利用若干視圖從不同角度來觀察和描述一個軟件系統(tǒng)的體系結(jié)構(gòu)，從某個角度觀察到的系統(tǒng)就構(gòu)成了系統(tǒng)的一個視圖。每個視圖都是整個系統(tǒng)描述的一個投影，說明了系統(tǒng)的某個特殊側(cè)面，若干個不同的視圖可以完整地描述所建造的系統(tǒng)。每種視圖用若干幅圖來描述，一幅圖包含了系統(tǒng)的某一特殊方面的信息，它闡明了系統(tǒng)的一個特定部分或方面。由于不同視圖之間存在一些交叉，因此一幅圖可以作為多個視圖的一部分。162.1.3

軟件系統(tǒng)體系結(jié)構(gòu)的描述

UML可以從下列5種視圖來觀察系統(tǒng)：

1.用例視圖

2.邏輯視圖

3.構(gòu)件視圖

4.進程視圖

5.配置視圖172.1.3

軟件系統(tǒng)體系結(jié)構(gòu)的描述1.用例視圖作用：描述系統(tǒng)的功能需求，找出用例和執(zhí)行者；適用對象：客戶、分析者、設(shè)計者、開發(fā)者和測試者；描述使用的圖：用例圖和活動圖；重要性：系統(tǒng)的中心，它決定了其他視圖的開發(fā)，用于確認和最終驗證系統(tǒng)。

182.1.3

軟件系統(tǒng)體系結(jié)構(gòu)的描述2.邏輯視圖作用：描述如何實現(xiàn)系統(tǒng)內(nèi)部的功能；適用對象：分析者、設(shè)計者、開發(fā)者；描述使用的圖：類圖和對象圖、狀態(tài)圖、順序圖、合作圖和活動圖；重要性：描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)和因發(fā)送消息而出現(xiàn)的動態(tài)協(xié)作關(guān)系。

192.1.3

軟件系統(tǒng)體系結(jié)構(gòu)的描述3.構(gòu)件視圖作用：描述系統(tǒng)代碼構(gòu)件組織和實現(xiàn)模塊，及它們之間的依賴關(guān)系；適用對象：設(shè)計者、開發(fā)者；描述使用的圖：構(gòu)件圖；重要性：描述系統(tǒng)如何劃分軟件構(gòu)件，如何進行編程。

202.1.3

軟件系統(tǒng)體系結(jié)構(gòu)的描述4.進程視圖作用：描述系統(tǒng)的并發(fā)性，并處理這些線程間的通信和同步；適用對象：開發(fā)者和系統(tǒng)集成者；描述使用的圖：狀態(tài)圖、順序圖、合作圖、活動圖、構(gòu)件圖和配置圖；重要性：將系統(tǒng)分割成并發(fā)執(zhí)行的控制線程及處理這些線程的通信和同步。

212.1.3

軟件系統(tǒng)體系結(jié)構(gòu)的描述5.配置視圖作用：描述系統(tǒng)的物理設(shè)備配置，如計算機、硬件設(shè)備以及它們相互間的連接；適用對象：開發(fā)者、系統(tǒng)集成者和測試者；描述使用的圖：配置圖；重要性：描述硬件設(shè)備的連接和哪個程序或?qū)ο篑v留在哪臺計算機上執(zhí)行。

222.1.4UML模型元素UML利用若干視圖從不同角度來描述一個系統(tǒng)，每種視圖由若干幅模型圖進行描述，每幅模型圖由若干個模型元素來描述。模型元素：指建模過程中涉及的一些基本概念，如類、對象、用例、結(jié)點、狀態(tài)、接口、包(子系統(tǒng))、注解、構(gòu)件等。模型元素符號/建模圖符：在UML模型中，表示模型元素的圖形符號。232.1.4UML模型元素24

模型元素與模型元素之間的連接關(guān)系也是模型元素。關(guān)聯(lián)：連接（connect）模型元素及鏈接（link）實例。依賴：表示一個元素以某種方式依賴于另一種元素。泛化：表示一般與特殊的關(guān)系，即“一般”元素是“特殊”元素的泛化。聚合：表示整體與部分的關(guān)系。2.1.4UML模型元素252.2

UML系統(tǒng)模型與建模2.2.1用例模型及組成成分2.2.2靜態(tài)模型與系統(tǒng)體系結(jié)構(gòu)建模2.2.3

動態(tài)模型與行為控制流建模262.2UML系統(tǒng)模型與建模

UML分析和設(shè)計模型由3大類10種圖表示。用例模型圖：由用例圖組成。靜態(tài)模型圖：由類圖、對象圖、包圖、構(gòu)件圖和

配置圖組成。動態(tài)模型圖：由活動圖、順序圖、狀態(tài)圖和合作圖組成。272.2.1

用例模型及組成成分用例模型(usecasemodel)：描述的是外部執(zhí)行者所理解的系統(tǒng)功能。用例模型由若干用例圖組成，主要用于需求分析階段，它的建立是系統(tǒng)開發(fā)者和用戶反復(fù)討論的結(jié)果，表明了

開發(fā)者和用戶對需求規(guī)格說明達成的共識。用例模型驅(qū)動了需求分析之后各階段的開發(fā)工作，不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實現(xiàn)，而且被用于

驗證和檢測所開發(fā)的系統(tǒng)，從而影響到開發(fā)工作的各個階段和UML的各個模型。282.2.1

用例模型及組成成分用例圖(UseCase):主要描述了用例與執(zhí)行者間的交互。用例描述的是用戶可見的需求，一個具體的用戶目標。執(zhí)行者是系統(tǒng)的主體，表示提供或接收系統(tǒng)信息的人或系統(tǒng)。用例圖主要用來描述用戶的需求，它從用戶的角度描述系統(tǒng)的功能，并指出各功能的執(zhí)行者，強調(diào)誰在使用系統(tǒng)，系統(tǒng)為執(zhí)行者完成哪些功能。292.2.1

用例模型及組成成分302.2.2

靜態(tài)模型與系統(tǒng)體系結(jié)構(gòu)建模靜態(tài)建模：指對系統(tǒng)中對象之間互相進行的聯(lián)系構(gòu)建模型，而這些關(guān)系不隨時間變化。UML靜態(tài)模型用于描述系統(tǒng)體系結(jié)構(gòu)。UML靜態(tài)建模機制包括：

1.類圖（classdiagram）

2.對象圖（objectdiagram）

3.包圖（packagediagram）

4.構(gòu)件圖（componentdiagram）

5.配置圖（deploymentdiagram）311.類圖（Classdiagram）類圖:用類和它們之間的關(guān)系描述系統(tǒng)的一種圖示，展示了系統(tǒng)中類的靜態(tài)結(jié)構(gòu)和類與類之間的相互聯(lián)系，表示一個系統(tǒng)的邏輯結(jié)構(gòu)。類圖是構(gòu)件其他圖的基礎(chǔ)，類是面向?qū)ο竽Ｐ妥罨镜哪Ｐ驮亍ｎ悎D主要描述系統(tǒng)中類的靜態(tài)結(jié)構(gòu)。在類圖中不僅需要定義系統(tǒng)中的類，詳細表示類的內(nèi)部結(jié)構(gòu)，如類的屬性和方法。另一方面還需要詳細表示類與類之間的聯(lián)系，如關(guān)聯(lián)、依賴、聚合等。類圖描述的是一種靜態(tài)關(guān)系，在系統(tǒng)的整個生命周期都是有效的。

321.類圖（Classdiagram）類圖組成：類名、屬性和操作。類及類型名均用英文大寫字母開頭，屬性及操作名為小寫字母開頭。注：類圖符號中的屬性只注明類型而不能有具體值。332.對象圖(Objectdiagram)對象圖:用來描述系統(tǒng)中對象及對象之間的聯(lián)系。類圖和對象圖的差別：首先對象圖表示的是類圖的一個實例，及時具體地反映了系統(tǒng)執(zhí)行到某處時系統(tǒng)的工作狀況；其次由于對象存在生命周期，因此對象圖與類圖的生命周期也不一樣，它只能在系統(tǒng)的某一時間段存在。

UML中的類圖與對象圖表達了對象模型的靜態(tài)結(jié)構(gòu)，能夠有效地建立專業(yè)領(lǐng)域的計算機系統(tǒng)的對象模型。342.對象圖(Objectdiagram)353.包圖(Packagediagram)

包圖:一種組合機制，由關(guān)系密切的一組模型元素構(gòu)成，還可以由其他包嵌套構(gòu)成。即主要由包或類組成，主要表示包與包、包與類之間的關(guān)系。作用：主要用來描述系統(tǒng)的分層結(jié)構(gòu)；引入包是為了降低系統(tǒng)的復(fù)雜性，包是維護和控制系統(tǒng)總體結(jié)構(gòu)的重要建模工具。

注意：包擁有自己的模型元素，包與包之間不能共用一個相同的模型元素，包的實例沒有任何語義，僅在模型執(zhí)行期間包才有意義。363.包圖(Packagediagram)

374.構(gòu)件圖(Componentdiagram)—組件圖構(gòu)件圖:顯示代碼本身的邏輯結(jié)構(gòu)，描述系統(tǒng)中存在的軟件構(gòu)件以及它們之間的依賴關(guān)系。構(gòu)件圖的元素：構(gòu)件、依賴關(guān)系和界面。構(gòu)件：系統(tǒng)體系結(jié)構(gòu)中獨立的物理可替換單位，代表系統(tǒng)的一個物理模塊，表達的是系統(tǒng)代碼本身的結(jié)構(gòu)，可以看作包與類對應(yīng)的物理代碼模塊，邏輯上與包、類對應(yīng)，實際上是一個文件。分為簡單構(gòu)件與擴充構(gòu)件。384.構(gòu)件圖(Componentdiagram)395.配置圖（deploymentdiagram）配置圖:描述了系統(tǒng)中硬件和軟件的物理配置情況和系統(tǒng)體系結(jié)構(gòu)，顯示系統(tǒng)運行時刻的結(jié)構(gòu)。配置圖的元素：結(jié)點和連接。結(jié)點:指實際的物理設(shè)備（即計算機資源，如服務(wù)器、客戶機或其他硬件設(shè)備）以及在該結(jié)點上運行的構(gòu)件或?qū)ο?。連接：配置圖各結(jié)點之間進行交互的通信路徑。表示系統(tǒng)中的結(jié)點之間的聯(lián)系，用連線表示，連線上要標注通信類型。405.配置圖

412.2.3動態(tài)模型與行為控制流建模

動態(tài)模型：主要描述系統(tǒng)的動態(tài)行為和控制結(jié)構(gòu)。動態(tài)行為：包括系統(tǒng)中對象生存期內(nèi)可能的狀態(tài)以及事件發(fā)生時狀態(tài)的遷移，還包括對象之間動態(tài)合作關(guān)系，顯示對象之間的交互過程以及交互順序，同時描述了為滿足用例要求所進行的活動以及活動間的約束關(guān)系。動態(tài)模型包括：

1.順序圖（sequencediagram）

2.合作圖（collaborationdiagram）

3.狀態(tài)圖（statediagram）

4.活動圖（activitydiagram）42順序圖:用來描述對象之間動態(tài)的交互關(guān)系,著重體現(xiàn)對象間消息傳遞的時間順序。1.順序圖（SequenceDiagram）

順序圖存在兩個軸：水平軸表示不同的對象，垂直軸表示時間。順序圖中的對象：用一個帶有垂直虛線的矩形框表示，并標有對象名和類名。對象的生命線：垂直虛線，用于表示在某段時間內(nèi)對象是存在的。對象間的通信通過對象的生命線之間的消息來表示。表示消息的箭頭類型指明了消息的類型，在消息箭頭線的上方可以標明傳送的消息順序號、名稱、內(nèi)容和要求返回的信息。當收到消息時，接收消息的對象立即開始執(zhí)行活動，即該對象被激活了，通過在對象生命線上顯示一個細長矩形框來表示對象的激活狀態(tài)。43442.合作圖（collaborationdiagram）—協(xié)作圖

合作圖:用于描述相互合作的對象間的交互關(guān)系和連接關(guān)系。順序圖與合作圖的相同點：也展示了對象間的動態(tài)協(xié)作關(guān)系。順序圖與合作圖的區(qū)別：順序圖強調(diào)時間和順序；合作圖強調(diào)對象間的相互關(guān)系。合作圖除了說明消息的交換外，還顯示對象之間的連接關(guān)系，

描述信息在連接對象之間的傳遞。452.合作圖合作圖畫成對象圖，圖中的消息箭頭表示對象間的消息流向，消息箭頭必須附加標記，說明消息發(fā)送的先后順序，還可顯示條件，重復(fù)和回送值等。463.狀態(tài)圖（statediagram）狀態(tài)圖:用來描述一個特定對象的所有可能的狀態(tài)及其引起狀態(tài)遷移的事件。一個系統(tǒng)或?qū)ο髲漠a(chǎn)生到結(jié)束或從創(chuàng)建到清除，可以處于一系列不同的狀態(tài)。這些狀態(tài)的數(shù)目有限時，可以由狀態(tài)圖來表示。狀態(tài)圖是對行為描述的補充，說明該類對象所有可能的狀態(tài)以及哪些事件導(dǎo)致了狀態(tài)的改變。事件：一條消息或者是滿足了某些條件。狀態(tài)遷移：狀態(tài)的改變稱為遷移。遷移動作：與狀態(tài)遷移相關(guān)的動作，指出狀態(tài)遷移時應(yīng)做什么。并不是所有的類都能夠畫狀態(tài)圖，只有那些具有個數(shù)有限、意義明確的狀態(tài)的類，并且其行為受不同狀態(tài)的影響而發(fā)生改變，這些類才需要畫狀態(tài)圖。473.狀態(tài)圖484.活動圖（activitydiagram

）活動圖:由狀態(tài)圖變化而來，它們各自用于不同的目的。狀態(tài)圖：著重描述對象的狀態(tài)變化以及觸發(fā)狀態(tài)變化的事件。交互模型(順序圖和合作圖)：描述對象之間的動態(tài)交互行為?；顒訄D：描述系統(tǒng)中各種活動的執(zhí)行順序，刻畫一個方法中所要進行的各項活動的執(zhí)行流程?；顒訄D的應(yīng)用可用來描述操作(類的方法)的行為；也可用來描述用例和對象內(nèi)部的工作過程；并可用于表示并行過程。494.活動圖（activitydiagram

）活動圖：顯示動作及其結(jié)果，著重描述操作實現(xiàn)中完成的工作以及用例或?qū)ο髢?nèi)部的活動。在狀態(tài)圖中狀態(tài)的變遷通常需要事件的觸發(fā)，而活動圖中某個活動結(jié)束后將立即進入下一個活動。構(gòu)成活動的模型元素有：活動、遷移、對象、信號、泳道等。活動是構(gòu)成活動圖的核心元素，是具有內(nèi)部動作的狀態(tài)，由隱含的事件觸發(fā)活動的遷移?；顒拥慕忉屢蕾囉谧鲌D的目的和抽象層次。在概念層描述中，活動表示要完成的一些任務(wù)。在說明層和實現(xiàn)層中，活動表示類中的方法。504.活動圖（activitydiagram

）514.活動圖（activitydiagram

）522.3

UML系統(tǒng)體系結(jié)構(gòu)模型

一個復(fù)雜的面向?qū)ο笙到y(tǒng)由很多子系統(tǒng)組成，子系統(tǒng)可以由一組模型來描述，一個模型可以由若干視圖表達，而一個視圖可以由一組相關(guān)的模型圖進行描述。將這些子系統(tǒng)和模型按軟件的系統(tǒng)體系結(jié)構(gòu)層次有機地組織起來，形成一個結(jié)構(gòu)合理、層次清晰的系統(tǒng)分析和設(shè)計模型是非常重要的工作。532.3

UML系統(tǒng)體系結(jié)構(gòu)模型2.3.1子系統(tǒng)組織的系統(tǒng)體系結(jié)構(gòu)2.3.2系統(tǒng)模型組織的系統(tǒng)體系結(jié)構(gòu)2.3.3

系統(tǒng)體系結(jié)構(gòu)模型的描述方式542.3.1

子系統(tǒng)組織的系統(tǒng)體系結(jié)構(gòu)

子系統(tǒng)：描述系統(tǒng)某個行為的相對獨立的抽象單位。每個子系統(tǒng)都有自己的接口，通過接口各個子系統(tǒng)相互交換信息，協(xié)同工作。如果采用由子系統(tǒng)包來描述系統(tǒng)的體系結(jié)構(gòu)圖，其最底層（葉結(jié)點）元素必須由模型包描述，而模型包一般用右上角帶有三角圖形的圖標元素“包”表示。552.3.1

子系統(tǒng)組織的系統(tǒng)體系結(jié)構(gòu)

562.3.2

系統(tǒng)模型組織的系統(tǒng)體系結(jié)構(gòu)

系統(tǒng)可以由一組模型來描述，模型可以從不同的角度和不同的抽象層次建立。系統(tǒng)分析人員、設(shè)計人員和功能測試人員需要用例模型來描述系統(tǒng)。系統(tǒng)開發(fā)人員需要系統(tǒng)中的類圖模型和對象圖模型，了解每個類或?qū)ο蟮膶傩?、操作和相互間的聯(lián)系等詳細描述，以便具體實現(xiàn)系統(tǒng)。一個模型包含了它所描述的那個系統(tǒng)所需要的全部模型元素，這些模型按照最高層的包/子系統(tǒng)的層次結(jié)構(gòu)進行組織，最高層的包/子系統(tǒng)代表系統(tǒng)的全貌，是系統(tǒng)的物理系統(tǒng)邊界。572.3.2

系統(tǒng)模型組織的系統(tǒng)體系結(jié)構(gòu)

582.3.3

系統(tǒng)體系結(jié)構(gòu)模型的描述方式在UML中一個系統(tǒng)體系結(jié)構(gòu)層次可以有兩種描述方式：基于模型的系統(tǒng)體系結(jié)構(gòu)層次：系統(tǒng)結(jié)構(gòu)層次中的所有元素都由系統(tǒng)模型組成?；谧酉到y(tǒng)的系統(tǒng)體系結(jié)構(gòu)層次：系統(tǒng)體系結(jié)構(gòu)層次中的元素由子系統(tǒng)組成，但最底層的元素必須由系統(tǒng)模型組成。一般情況下，為了簡便起見，系統(tǒng)分析和設(shè)計人員在用包圖描述一個系統(tǒng)的多層體系結(jié)構(gòu)時，并不區(qū)分子系統(tǒng)包和模型包，而采用簡單的包圖（不帶分支或三角圖符的包）來建立系統(tǒng)的體系結(jié)構(gòu)圖。這樣就不用隨時關(guān)注系統(tǒng)體系結(jié)構(gòu)圖的最低層（葉結(jié)點）元素必須是模型包了。592.3.3

系統(tǒng)體系結(jié)構(gòu)模型的描述方式602.3.3

系統(tǒng)體系結(jié)構(gòu)模型的描述方式612.5

UML與面向?qū)ο蟮?/p>

軟件開發(fā)統(tǒng)一過程2.5.1UML支持迭代、漸增式的軟件開發(fā)過程2.5.2軟件開發(fā)步驟及核心支持活動2.5.3

UML軟件開發(fā)過程產(chǎn)生的模型與文檔2.5.4UML軟件開發(fā)過程的基本特征622.5UML與軟件開發(fā)統(tǒng)一過程

UML：給出了面向?qū)ο蠼５姆柋硎竞鸵?guī)則，是一種用于軟件開發(fā)的系統(tǒng)分析和系統(tǒng)設(shè)計的建模語言工具，獨立于軟件開發(fā)過程，UML并沒有描述如何工作，而且是為不同規(guī)模和目標的過程而設(shè)計的，在開發(fā)軟件時須視軟件的種類、大小等因素決定其使用的過程。面向?qū)ο蟮能浖_發(fā)統(tǒng)一過程(UnifiedProcess,UP)：將核心過程模型化，綜合以前多種軟件開發(fā)過程的優(yōu)點，全面考慮了軟件開發(fā)的技術(shù)因素和管理因素，是一種良好的開發(fā)模式。UML與UP相結(jié)合進行軟件系統(tǒng)的開發(fā)是面向?qū)ο笙到y(tǒng)開發(fā)的最好途徑。632.5UML與軟件開發(fā)統(tǒng)一過程

642.5.1

迭代、漸增式的開發(fā)過程

1.開始階段

開始階段主要任務(wù)是確定項目的范圍和目標，并進行可行性分析。主要工作如下：理解問題領(lǐng)域的各種業(yè)務(wù)過程及其之間的關(guān)系?？紤]和分析項目的成本及可能得到的效益和風(fēng)險。明確待開發(fā)項目的意義和價值。確定是否要開發(fā)此項目。652.5.1

迭代、漸增式的開發(fā)過程

2.詳細規(guī)劃階段

詳細規(guī)劃階段的主要任務(wù)是在開始階段工作基礎(chǔ)上，收集更詳細的系統(tǒng)需求，進行高層次的系統(tǒng)分析和系統(tǒng)設(shè)計：對開發(fā)項目的問題領(lǐng)域和功能作詳細分析，畫出用例圖。建立系統(tǒng)的基礎(chǔ)體系結(jié)構(gòu)。進行風(fēng)險分析，并制定相應(yīng)的對策。制定開發(fā)計劃。

制定開發(fā)計劃實際上是為系統(tǒng)構(gòu)造階段制定迭代開發(fā)的順序。制定計劃包括以下活動：(1)用例分類(2)確定每次迭代的開發(fā)周期(3)將用例分配到各次迭代中66(1)用例分類1）將用例的優(yōu)先級分為三級：一級：首先必須要實現(xiàn)的功能。二級：短期內(nèi)可以沒有的功能。三級：較長時間內(nèi)可以沒有的功能。2）體系結(jié)構(gòu)方面的風(fēng)險分為三級：一級：高風(fēng)險。二級：可能的風(fēng)險。三級：幾乎不可能的風(fēng)險。注：該風(fēng)險為當暫時不實現(xiàn)某個用例時，是否會在以后的迭代開發(fā)中導(dǎo)致大量的改寫工作。2.詳細規(guī)劃階段

2.5.1

迭代、漸增式的開發(fā)過程

672.5.1

迭代、漸增式的開發(fā)過程

3）進度風(fēng)險分為三級：一級：無法估算。二級：只能估算到人·月。三級：確信自己對時間的估算。注：估算時應(yīng)考慮分析、設(shè)計、實現(xiàn)、測試、文檔編寫等所需的時間，應(yīng)盡量精確到人·周2.詳細規(guī)劃階段

(2)確定每次迭代的開發(fā)周期迭代周期：對整個項目可制定固定的迭代周期，以便能定期提交產(chǎn)品。迭代周期的長短：由項目的大小、開發(fā)的要求以及開發(fā)人員的多少和經(jīng)驗等因素決定。迭代次數(shù)：整個項目的迭代次數(shù)不宜過多，通常以3-5次為宜。683.系統(tǒng)構(gòu)造階段

2.5.1

迭代、漸增式的開發(fā)過程

系統(tǒng)構(gòu)造階段是迭代、漸增地建造系統(tǒng)的過程，通過若干次迭代、循環(huán)、重復(fù)的工作具體建造軟件系統(tǒng)。每次迭代可看作開發(fā)一個小項目，它應(yīng)包含分析、設(shè)計、實現(xiàn)、測試全過程。這種迭代、漸增式的開發(fā)有助于及早發(fā)現(xiàn)和修改錯誤，減少開發(fā)的風(fēng)險。2.詳細規(guī)劃階段

(3)將用例分配到各次迭代中通常具有高優(yōu)先級、高體系結(jié)構(gòu)風(fēng)險和高進度風(fēng)險的用例應(yīng)盡早實現(xiàn)，不要將風(fēng)險留到最后。692.5.1

迭代、漸增式的開發(fā)過程

4.移交階段

移交階段一般不再開發(fā)新的功能，該階段的工作主要有系統(tǒng)測試、產(chǎn)品包裝、用戶培訓(xùn)等。漸增式開發(fā)每次迭代都是在前次迭代的基礎(chǔ)上增加另外一些新用例的開發(fā)。集成測試新用例開發(fā)完成后要與前次迭代結(jié)果集成，進行系統(tǒng)測試。測試演示向用戶演示測試過程及結(jié)果，以表明相關(guān)的用例已被正確實現(xiàn)。保存測試案例

所有測試案例都應(yīng)保存，以便在以后的迭代中進行回歸測試。3.系統(tǒng)構(gòu)造階段

702.5.2

軟件開發(fā)步驟及核心支持活動

UML開發(fā)過程中的核心活動成分就是進行軟件項目開發(fā)時要執(zhí)行的活動的一般描述，主要步驟如下：1.需求分析

2.系統(tǒng)設(shè)計

3.實現(xiàn)

4.測試

5.配置

6.核心支持工作712.5.2

軟件開發(fā)步驟及核心支持活動

需求分析包括建立問題領(lǐng)域的業(yè)務(wù)模型和用戶需求分析模型。1.需求分析過程：首先獲取需求，得到描述系統(tǒng)所需功能的用例、業(yè)務(wù)流程或清晰的正文，它從系統(tǒng)外部觀察系統(tǒng)，而不涉及在技術(shù)上如何做這些事。在需求分析過程創(chuàng)建的UML圖有：用例圖、類圖、對象圖、順序圖、合作圖、狀態(tài)圖和活動圖。722.5.2

軟件開發(fā)步驟及核心支持活動

設(shè)計是分析結(jié)果在技術(shù)上的擴充和改編，它的注意力集中于在計算機中如何實現(xiàn)該系統(tǒng)。2.系統(tǒng)設(shè)計設(shè)計階段可以分為兩個部分：結(jié)構(gòu)設(shè)計和詳細設(shè)計。

結(jié)構(gòu)設(shè)計：高層設(shè)計，任務(wù)是定義包(子系統(tǒng))，包括包與包之間的依賴性和主要通信機制。詳細設(shè)計：細化包的內(nèi)容，使編程人員得到所有類的足夠清晰的描述。詳細設(shè)計活動應(yīng)給出所有類的規(guī)格說明,包括必須的實現(xiàn)屬性，它們的詳細接口和操作描述。規(guī)約應(yīng)該足夠詳細，它們與模型中的圖一起提供了編碼需要的所有信息。在設(shè)計階段創(chuàng)建的圖有：類圖、對象圖、包圖、順序圖、合作圖、狀態(tài)圖、活動圖、構(gòu)件圖和配置圖。732.5.2

軟件開發(fā)步驟及核心支持活動

實現(xiàn)活動：即編寫代碼，包括最終的設(shè)計決策，把設(shè)計模型圖和規(guī)約轉(zhuǎn)換成程序代碼，還包括反復(fù)的編譯、連接、排錯等過程。3.實現(xiàn)注意：編寫程序時，按照建立可復(fù)用構(gòu)件的標準完成軟件的編碼，逐漸形成自己的可復(fù)用構(gòu)件庫。742.5.2

軟件開發(fā)步驟及核心支持活動

測試的目的：發(fā)現(xiàn)代碼中的錯誤，測試包括一些測試案例，每個測試案例要指明做什么，使用哪些數(shù)據(jù)，期望得到什么結(jié)果，測試的結(jié)果要記錄在測試報告中。4.測試回歸測試：在系統(tǒng)被修改之后都要進行回歸測試，用來檢查每一次改動是否對其他功能有所影響。在測試階段：依靠用例圖來驗證系統(tǒng)，集成測試還會用到配置圖、順序圖和合作圖。752.5.2

軟件開發(fā)步驟及核心支持活動

配置：在系統(tǒng)建模階段后期和移交階段進行的。主要工作：根據(jù)系統(tǒng)工作環(huán)境的硬件設(shè)備，將組成系統(tǒng)體系結(jié)構(gòu)的軟件構(gòu)件分配到相應(yīng)的計算機上。由構(gòu)件圖和配置圖進行描述。5.配置762.5.2

軟件開發(fā)步驟及核心支持活動

(1)配置與變化管理貫穿于整個開發(fā)過程的各個階段。主要工作：協(xié)調(diào)各開發(fā)活動之間因環(huán)境配置發(fā)生變化所引起的矛盾，調(diào)整各個活動的進度及相互之間的連接。6.核心支持工作核心支持工作包括：配置與變化管理項目管理環(huán)境設(shè)置。772.5.2

軟件開發(fā)步驟及核心支持活動

6.核心支持工作(2)項目管理貫穿于整個開發(fā)過程的各個階段。主要工作：為開發(fā)過程的各個階段和循環(huán)迭代中相應(yīng)的活動制定計劃、檢查計劃執(zhí)行情況、調(diào)整進度、調(diào)配人員、經(jīng)費使用管理等。還要協(xié)調(diào)與項目有關(guān)的投資方、用戶和開發(fā)人員之間的關(guān)系。用計劃書和調(diào)配單進行控制。(3)環(huán)境設(shè)置在開始階段和詳細規(guī)劃階段進行。包括：硬件環(huán)境、軟件系統(tǒng)使用環(huán)境、企業(yè)文化背景和最終用戶操作人員的素質(zhì)等。782.5.3UML軟件開發(fā)過程產(chǎn)生的模型與文檔

UML的最終產(chǎn)物：最后提交的可執(zhí)行的軟件系統(tǒng)和

相應(yīng)的軟件文檔資料。UML開發(fā)過程的產(chǎn)物包括兩大類：模型和文檔。一部分將來要交付給項目的投資者或最終用戶；另一部分供開發(fā)人員在開發(fā)過程中使用。792.5.3UML軟件開發(fā)過程產(chǎn)生的模型與文檔

1.模型

(1)業(yè)務(wù)模型：建立問題領(lǐng)域的組織結(jié)構(gòu)和業(yè)務(wù)流程的抽象。

描述方式：需求分析規(guī)格說明書。(2)領(lǐng)域模型：建立問題領(lǐng)域的需求分析說明。

描述方式：需求分析規(guī)格說明書。(3)用例模型：表達系統(tǒng)的功能。

描述方式：用例圖、活動圖及需求分析規(guī)格說明書?？梢暬⑽臋n化的模型是現(xiàn)實世界的簡化，用于更好地理解系統(tǒng)。UML在開發(fā)過程產(chǎn)生9種模型：80(4)

分析模型（任選）：只有復(fù)雜的系統(tǒng)才需要建立獨立的分析模型。分析模型包括：

基本功能分析。實現(xiàn)功能的對象。對象之間的關(guān)系。描述方式：類圖、對象圖、包圖、順序圖、合作圖、狀態(tài)圖和活動圖。2.5.3UML軟件開發(fā)過程產(chǎn)生的模型與文檔

1.模型

81(5)

設(shè)計模型：系統(tǒng)具體解決方案，由調(diào)整和完善分析模型而成。

描述方式：類圖、對象圖、包圖、順序圖、合作圖、狀態(tài)圖和活動圖。(6)

進程模型（任選）：描述系統(tǒng)并發(fā)和同步機制。有多線程的并發(fā)系統(tǒng)才建立。描述方式：狀態(tài)圖、順序圖、合作圖、活動圖、構(gòu)件圖和配置圖。2.5.3UML軟件開發(fā)過程產(chǎn)生的模型與文檔

1.模型

(7)

實現(xiàn)模型：軟件的系統(tǒng)體系結(jié)構(gòu)。描述方式：包圖和構(gòu)件圖。82(8)

配置模型：描述系統(tǒng)軟件在各個硬件上的配置。

描述方式：配置圖。(9)測試模型：描述驗證系統(tǒng)功能的途徑。

描述方式：測試案例和測試報告。2.5.3UML軟件開發(fā)過程產(chǎn)生的模型與文檔

1.模型

832.文檔2.5.3UML軟件開發(fā)過程產(chǎn)生的模型與文檔

文檔資料是UML開發(fā)過程所獲得的信息集。

包括：技術(shù)文檔和管理文檔。技術(shù)文檔1)

需求分析信息集：軟件需求規(guī)格說明書、需求補充說明、業(yè)