《UML面向?qū)ο蠓治?、建模與設(shè)計(jì)》課件 第1-7章 軟件工程與面向?qū)ο蠓椒?對(duì)象圖_第1頁(yè)
《UML面向?qū)ο蠓治?、建模與設(shè)計(jì)》課件 第1-7章 軟件工程與面向?qū)ο蠓椒?對(duì)象圖_第2頁(yè)
《UML面向?qū)ο蠓治?、建模與設(shè)計(jì)》課件 第1-7章 軟件工程與面向?qū)ο蠓椒?對(duì)象圖_第3頁(yè)
《UML面向?qū)ο蠓治?、建模與設(shè)計(jì)》課件 第1-7章 軟件工程與面向?qū)ο蠓椒?對(duì)象圖_第4頁(yè)
《UML面向?qū)ο蠓治?、建模與設(shè)計(jì)》課件 第1-7章 軟件工程與面向?qū)ο蠓椒?對(duì)象圖_第5頁(yè)
已閱讀5頁(yè),還剩139頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

軟件工程與面向?qū)ο蠓椒?/p>

1.1軟件工程簡(jiǎn)介軟件工程的發(fā)展過(guò)程軟件工程的目標(biāo)軟件工程的原則軟件工程的發(fā)展過(guò)程“軟件危機(jī)”的產(chǎn)生早期的自由軟件開(kāi)發(fā)方式使得高質(zhì)量的軟件開(kāi)發(fā)變得越來(lái)越困難。不能按時(shí)完成任務(wù)、產(chǎn)品質(zhì)量得不到保證、工作效率低下和開(kāi)發(fā)經(jīng)費(fèi)嚴(yán)重超支?!败浖こ獭钡某霈F(xiàn)和發(fā)展1968年,在北大西洋公約組織舉行的一次學(xué)術(shù)會(huì)議上,首次提出了“軟件工程”的概念?,F(xiàn)代,軟件工程是指應(yīng)用計(jì)算機(jī)科學(xué)技術(shù)、數(shù)學(xué)和管理學(xué)的原理,運(yùn)用工程學(xué)的理論、方法和技術(shù),研究和指導(dǎo)軟件開(kāi)發(fā)和演化的一門(mén)交叉學(xué)科。軟件工程的目標(biāo)使軟件開(kāi)發(fā)的成本能夠控制在預(yù)計(jì)的合理范圍內(nèi)。使軟件產(chǎn)品的各項(xiàng)功能和性能能夠滿足用戶需求。提高軟件產(chǎn)品的質(zhì)量。提高軟件產(chǎn)品的可靠性。使生產(chǎn)出來(lái)的軟件產(chǎn)品易于移植、維護(hù)、升級(jí)和使用。使軟件產(chǎn)品的開(kāi)發(fā)周期能夠控制在預(yù)計(jì)的合理時(shí)間范圍內(nèi)。軟件工程的原則用分階段的生命周期計(jì)劃進(jìn)行嚴(yán)格的管理。堅(jiān)持進(jìn)行階段評(píng)審。實(shí)行嚴(yán)格的產(chǎn)品控制。采用現(xiàn)代程序設(shè)計(jì)技術(shù)。軟件工程結(jié)果應(yīng)能清楚地審查。開(kāi)發(fā)小組的人員應(yīng)該少而精。承認(rèn)不斷改進(jìn)軟件工程實(shí)踐性的必要性。1.2面向?qū)ο蠓椒ê?jiǎn)介什么是面向?qū)ο蠓椒嫦驅(qū)ο蠓椒ǖ陌l(fā)展歷史面向?qū)ο蠓椒ǖ幕靖拍顚?duì)象、類、抽象、封裝、泛化、多態(tài)面向?qū)ο蠓椒ǖ膬?yōu)勢(shì)什么是面向?qū)ο蠓椒嫦驅(qū)ο蠓椒ǎ篛bject-OrientedMethod,縮寫(xiě)為OOM。面向?qū)ο蠓椒ń鉀Q問(wèn)題的思路就是主張從客觀世界固有的事物出發(fā)來(lái)構(gòu)造系統(tǒng),提倡用人類在現(xiàn)實(shí)生活中常用的思維方法來(lái)認(rèn)識(shí)、理解和描述客觀事物,強(qiáng)調(diào)最終建立的系統(tǒng)能夠映射問(wèn)題域。面向?qū)ο蠓椒ㄊ且环N運(yùn)用一系列面向?qū)ο蟮闹笇?dǎo)軟件構(gòu)造的概念和原則(如類、對(duì)象、抽象、封裝、繼承、多態(tài)、消息等)來(lái)構(gòu)造軟件系統(tǒng)的開(kāi)發(fā)方法。面向?qū)ο蠓椒ǖ陌l(fā)展歷史第一門(mén)面向?qū)ο蟮木幊陶Z(yǔ)言:Simula-67(1967)首先引入了類、對(duì)象、繼承等概念。使面向?qū)ο蠹夹g(shù)進(jìn)入實(shí)用化的標(biāo)志:Smalltalk(1972-1981)正式使用了“面向?qū)ο蟆?。Smalltalk-80的問(wèn)世被認(rèn)為是面向?qū)ο笳Z(yǔ)言發(fā)展史上最重要的里程碑。提供了比較完整的面向?qū)ο蠹夹g(shù)解決方案,諸如類、對(duì)象、封裝、抽象、繼承、多態(tài)等。Smalltalk-80是第一個(gè)完善的、能夠?qū)嶋H應(yīng)用的面向?qū)ο笳Z(yǔ)言。面向?qū)ο蠓椒ǖ陌l(fā)展歷史面向?qū)ο蟮某绦蛟O(shè)計(jì)語(yǔ)言走向繁榮ObjectiveC、C++、Eiffel和CLOS等語(yǔ)言大量涌現(xiàn)。C++語(yǔ)言的廣泛應(yīng)用,使得面向?qū)ο蠹夹g(shù)真正從實(shí)驗(yàn)室階段走到了商業(yè)化階段。面向?qū)ο蟮能浖こ萄杆侔l(fā)展大量關(guān)于面向?qū)ο蠓椒ǖ闹鲉?wèn)世,相互之間存在不小的差異。UML將不同方法中使用的各種概念進(jìn)行統(tǒng)一,并被對(duì)象管理組織采納為規(guī)范。面向?qū)ο蠓椒ǖ幕靖拍睢獙?duì)象萬(wàn)事萬(wàn)物皆對(duì)象——Everything

Is

An

Object。三種對(duì)象客觀對(duì)象:現(xiàn)實(shí)中的實(shí)體問(wèn)題對(duì)象:抽象客觀對(duì)象某些屬性和方法來(lái)研究在某個(gè)問(wèn)題或場(chǎng)景中的性質(zhì)計(jì)算機(jī)對(duì)象:?jiǎn)栴}對(duì)象通過(guò)封裝等過(guò)程稱為計(jì)算機(jī)中的一個(gè)包含有數(shù)據(jù)和操作的集合體面向?qū)ο蠓椒ǖ幕靖拍睢獙?duì)象對(duì)象的四個(gè)特性:自治性封閉性通信性被動(dòng)性面向?qū)ο蠓椒ǖ幕靖拍睢愵愂菗碛泄餐慕Y(jié)構(gòu)、行為和語(yǔ)義的一組對(duì)象的抽象。對(duì)類的四個(gè)角度的理解:類是面向?qū)ο蟪绦蛑械臉?gòu)造單位。類是面向?qū)ο蟪绦蛟O(shè)計(jì)語(yǔ)言的基本成分。類是抽象數(shù)據(jù)類型的具體表現(xiàn)。類刻畫(huà)了一組相似對(duì)象的共同特性。面向?qū)ο蠓椒ǖ幕靖拍睢橄蟪橄缶褪墙沂疽粋€(gè)事物區(qū)別于其他事物的本質(zhì)特征,去除從某一個(gè)角度看來(lái)不重要的細(xì)節(jié)的行為。抽象取決于使用者的目的,并沒(méi)有唯一的答案。抽象具有靜態(tài)與動(dòng)態(tài)的屬性。面向?qū)ο蠓椒ǖ幕靖拍睢庋b封裝,即對(duì)其客戶隱藏對(duì)象的屬性和實(shí)現(xiàn)細(xì)節(jié),僅對(duì)外公開(kāi)接口,并控制在程序中屬性的讀和修改的訪問(wèn)級(jí)別。封裝強(qiáng)調(diào)兩個(gè)概念,即獨(dú)立和封閉。獨(dú)立是指對(duì)象是一個(gè)不可分割的整體,它集成了事物全部的屬性和操作,并且它的存在不依賴于外部事物。封閉是指與外部的事物通信時(shí),對(duì)象要盡量地隱藏其內(nèi)部的實(shí)現(xiàn)細(xì)節(jié),它的內(nèi)部信息對(duì)外界來(lái)說(shuō)是隱蔽的,外界不能直接訪問(wèn)對(duì)象的內(nèi)部信息,而只能通過(guò)有限的接口與對(duì)象發(fā)生聯(lián)系。面向?qū)ο蠓椒ǖ幕靖拍睢夯c多態(tài)泛化是類元的一般描述和具體描述之間的關(guān)系。實(shí)現(xiàn)泛化關(guān)系的機(jī)制為繼承。一個(gè)子類繼承一個(gè)或多個(gè)父類,從而實(shí)現(xiàn)了不同的抽象層次,實(shí)現(xiàn)兩者之間的泛化關(guān)系。多態(tài)是在同一接口下表現(xiàn)多種行為的能力,是面向?qū)ο蠹夹g(shù)的根本特征。當(dāng)一個(gè)對(duì)象接收到進(jìn)行某項(xiàng)操作的消息時(shí),多態(tài)機(jī)制將根據(jù)對(duì)象所屬的類,動(dòng)態(tài)地選用該類中定義的操作。面向?qū)ο蠓椒ǖ膬?yōu)勢(shì)更符合人類的思維習(xí)慣穩(wěn)定性復(fù)用性改善軟件結(jié)構(gòu)增強(qiáng)擴(kuò)展性支持迭代式開(kāi)發(fā)統(tǒng)一建模語(yǔ)言UML

2.1軟件建模簡(jiǎn)介什么是模型建模的重要性建模的基本原理什么是模型模型是用某種媒介對(duì)相同媒介或其他媒介里的一些事物的表現(xiàn)形式。模型就是對(duì)現(xiàn)實(shí)的簡(jiǎn)化。建立模型的過(guò)程,稱為建模。模型提供了系統(tǒng)的藍(lán)圖。軟件系統(tǒng)的模型用建模語(yǔ)言來(lái)表達(dá),包括語(yǔ)義信息和表示法。建模的重要性捕獲和精確表達(dá)項(xiàng)目的需求和應(yīng)用領(lǐng)域的知識(shí),以使全部涉眾能夠理解并達(dá)成一致。完成系統(tǒng)設(shè)計(jì)。分離需求與具體實(shí)現(xiàn)細(xì)節(jié)。幫助生成有用的工作產(chǎn)品。方便研究多種解決方案。全面把握復(fù)雜的系統(tǒng)。建模的基本原理選擇創(chuàng)建什么模型對(duì)如何解決問(wèn)題和如何形成相應(yīng)解決方案意義深遠(yuǎn)??梢栽诓煌膶哟渭?jí)別上表示不同模型。最好的模型總是與現(xiàn)實(shí)世界聯(lián)系密切。單個(gè)模型或視圖是不充分的。2.2UML簡(jiǎn)述統(tǒng)一建模語(yǔ)言(UML)是一種通用的可視化建模語(yǔ)言,可以用來(lái)描述、可視化、構(gòu)造和文檔化軟件密集型系統(tǒng)的各種工件。UML創(chuàng)始人:GradyBooch、JamesRumbaugh、IvarJacobsonUML用來(lái)捕獲系統(tǒng)靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為的信息。UML是獨(dú)立于過(guò)程的,它適用于各種軟件開(kāi)發(fā)方法、軟件生命周期的各個(gè)階段、各種應(yīng)用領(lǐng)域以及各種開(kāi)發(fā)工具。UML不是一種程序設(shè)計(jì)語(yǔ)言,其描述的模型可以和各種編程語(yǔ)言相聯(lián)系。2.3UML的發(fā)展歷史UML的出現(xiàn)背景UML的誕生及其標(biāo)準(zhǔn)化UML2規(guī)范UML的出現(xiàn)背景早起面向?qū)ο蠓椒▽W(xué)的發(fā)展引發(fā)了“方法大戰(zhàn)”。Booch方法:在項(xiàng)目的設(shè)計(jì)和構(gòu)造階段的表達(dá)力極強(qiáng)。OOSE:對(duì)以用例驅(qū)動(dòng)需求獲取、分析和高層設(shè)計(jì)的開(kāi)發(fā)過(guò)程提供了極好的支持。OMT:對(duì)分析和數(shù)據(jù)密集型信息系統(tǒng)最為有用。早期方法統(tǒng)一的嘗試:Fushion方法UML的前身:UM0.8UML的誕生及其標(biāo)準(zhǔn)化1996年6月,UML0.9發(fā)布;10月,UML0.91發(fā)布。同年,UMLPartners組織建立。1997年1月,UML1.0規(guī)范草案發(fā)布并交付給OMG組織。7月,修改后的UML1.1作為最終成果發(fā)布并被提交給OMG進(jìn)行標(biāo)準(zhǔn)化審查。1997年11月,UML1.1規(guī)范被OMG全體成員通過(guò),并被采納為規(guī)范。在1997年至2002年間,OMG陸續(xù)開(kāi)發(fā)了UML的1.3、1.4和1.5版本。2005年,UML1.4.2被ISO正式發(fā)布為國(guó)際標(biāo)準(zhǔn)。UML2規(guī)范UML的全面升級(jí):自2000年11月起開(kāi)始起草,至2003年7月完成。2005年7月,最終的UML2.0規(guī)范發(fā)布。2012年,UML2.4.1被ISO正式確定為國(guó)際標(biāo)準(zhǔn)。目前最新版本的UML是2015年6月發(fā)布的UML2.5。2.4UML的目標(biāo)與應(yīng)用范圍UML的目標(biāo)UML的應(yīng)用范圍UML的目標(biāo)為建模者提供可用的、富有表達(dá)力的、可視化的建模語(yǔ)言,以開(kāi)發(fā)和交換有意義的模型。提供可擴(kuò)展性和特殊化機(jī)制以延伸核心概念。支持獨(dú)立于編程語(yǔ)言和開(kāi)發(fā)過(guò)程的規(guī)范。為理解建模語(yǔ)言提供正式的基礎(chǔ)。推動(dòng)面向?qū)ο蠼9ぞ呤袌?chǎng)的成長(zhǎng)。支持更高級(jí)的開(kāi)發(fā)概念。UML的應(yīng)用范圍需求分析階段:通過(guò)建立用例圖等模型來(lái)描述系統(tǒng)的使用者對(duì)系統(tǒng)的功能要求。分析和設(shè)計(jì)階段:通過(guò)類和對(duì)象等主要概念及其關(guān)系建立靜態(tài)模型,對(duì)類、用例等概念之間的協(xié)作進(jìn)行動(dòng)態(tài)建模,為開(kāi)發(fā)工作提供詳盡的規(guī)格說(shuō)明。開(kāi)發(fā)階段:將設(shè)計(jì)的模型轉(zhuǎn)化為編程語(yǔ)言的實(shí)際代碼,指導(dǎo)并減輕編碼工作。測(cè)試階段:用UML圖作為測(cè)試依據(jù)。2.5UML建模工具RationalRoseEnterpriseArchitectRationalSoftwareArchitectStarUMLProcessOnRationalRose31EnterpriseArchitect32RationalSoftwareArchitect33StarUML34ProcessOn35RationalRose工具概述

3.1Rose簡(jiǎn)述RationalRose是由Rational公司研發(fā)的一種面向?qū)ο蟮目梢暬9ぞ摺ationalRose對(duì)UML的支持:提供基本的繪圖功能提供模型庫(kù)提供導(dǎo)航功能提供代碼生成功能提供逆向工程功能3.3RationalRose的使用標(biāo)題欄菜單欄標(biāo)準(zhǔn)工具欄瀏覽器框圖工具欄文檔窗口日志模型繪制區(qū)UML概念模型

4.1構(gòu)造塊事物關(guān)系圖事物事物的分類:結(jié)構(gòu)事物、行為事物、分組事物、注釋事物。結(jié)構(gòu)事物:作為UML模型的靜態(tài)部分,用于描述概念元素或物理元素。例:類、接口、用例、組件、節(jié)點(diǎn)等行為事物:是UML模型的動(dòng)態(tài)部分,用于描述UML模型中的動(dòng)態(tài)元素。例:狀態(tài)機(jī)、活動(dòng)等分組事物:是UML模型的組織部分,是用來(lái)組織系統(tǒng)設(shè)計(jì)的事物。例:包注釋事物:是UML模型的解釋部分,用來(lái)描述、說(shuō)明和標(biāo)注模型的元素。例:注解關(guān)系關(guān)系是模型元素之間具體化的語(yǔ)義連接,負(fù)責(zé)聯(lián)系UML的各類事物,構(gòu)造出結(jié)構(gòu)良好的UML模型。四種關(guān)系:關(guān)聯(lián)關(guān)系:描述不同類元的實(shí)例之間的連接。依賴關(guān)系:描述一對(duì)模型元素之間的內(nèi)在聯(lián)系。泛化關(guān)系:描述特殊到一般的一種歸納和分類關(guān)系。實(shí)現(xiàn)關(guān)系:描述規(guī)格說(shuō)明和其實(shí)現(xiàn)的元素之間的連接的一種關(guān)系。圖UML圖根據(jù)基本功能和作用,可分為:結(jié)構(gòu)圖與行為圖。結(jié)構(gòu)圖:捕獲事物與事物之間的靜態(tài)關(guān)系,用來(lái)描述系統(tǒng)的靜態(tài)結(jié)構(gòu)模型。行為圖:捕獲事物的交互過(guò)程如何產(chǎn)生系統(tǒng)的行為,用來(lái)描述系統(tǒng)的動(dòng)態(tài)行為模型。UML1.x與UML2規(guī)范所包含的圖的不同UML1.4中的圖UML2中的圖UML

1.4與UML2中不同圖的對(duì)比UML1.4UML2對(duì)比說(shuō)明

包圖盡管UML1.4使用包圖說(shuō)明規(guī)范的組織結(jié)構(gòu),但是沒(méi)有對(duì)包圖進(jìn)行明確定義。狀態(tài)圖狀態(tài)機(jī)圖只是名稱不同,技術(shù)上完全相同?;顒?dòng)圖活動(dòng)圖UML2的活動(dòng)圖獨(dú)立于狀態(tài)機(jī)存在。

組合結(jié)構(gòu)圖顯示結(jié)構(gòu)化類元或協(xié)作的內(nèi)部結(jié)構(gòu),和普通類圖之間沒(méi)有嚴(yán)格界限。

交互圖UML2中的交互圖是順序圖、通信圖、交互概覽圖和時(shí)間圖的統(tǒng)稱,與活動(dòng)圖密切相關(guān)。協(xié)作圖通信圖UML2中多用更加精確的通信圖來(lái)代替協(xié)作圖的大部分功能;UML2中協(xié)作圖作為一種組合結(jié)構(gòu)圖存在。

交互概覽圖活動(dòng)圖的變體,合并了序列圖片段和控制流構(gòu)造。

時(shí)間圖UML2中新增的時(shí)間圖是一種特殊的序列圖形式,顯式地表示了生命線上的狀態(tài)變化和標(biāo)度時(shí)間。4.2通用機(jī)制規(guī)格說(shuō)明修飾通用劃分?jǐn)U展機(jī)制構(gòu)造型標(biāo)記值約束規(guī)格說(shuō)明UML的規(guī)格說(shuō)明用來(lái)對(duì)系統(tǒng)的細(xì)節(jié)進(jìn)行描述,在增加模型的規(guī)格說(shuō)明時(shí)可以確定系統(tǒng)的更多性質(zhì),細(xì)化對(duì)系統(tǒng)的描述。例如,在一個(gè)類的符號(hào)中暗示了一種規(guī)格說(shuō)明:它提供類所有的屬性、操作等信息的全面描述。修飾修飾是對(duì)規(guī)格說(shuō)明的文字的或圖形的表示。例如,通過(guò)對(duì)類名添加斜體修飾來(lái)表明這是一個(gè)抽象類。在UML中的每個(gè)元素符號(hào)都以一個(gè)基本的符號(hào)開(kāi)始,在其上添加一些具有獨(dú)特性的修飾。例如,這里有一個(gè)類,我們可以通過(guò)不同的修飾來(lái)標(biāo)示出它是一個(gè)抽象類,擁有兩個(gè)公有性的操作,一個(gè)保護(hù)性的操作和一個(gè)私有性的操作。通用劃分在面向?qū)ο笙到y(tǒng)建模中,通常有幾種劃分方法,其中最常見(jiàn)的有兩種劃分:類型-實(shí)例:是通用描述與某個(gè)特定元素的對(duì)應(yīng)。例如,類和對(duì)象就是一種典型的類型-實(shí)例劃分。接口-實(shí)現(xiàn):接口是一個(gè)系統(tǒng)或?qū)ο蟮男袨橐?guī)范,這種規(guī)范預(yù)先告知使用者或外部的其它對(duì)象這個(gè)系統(tǒng)或?qū)ο蟮哪稠?xiàng)能力,和其提供的服務(wù)。實(shí)現(xiàn)是接口的具體行為,它負(fù)責(zé)執(zhí)行接口的全部語(yǔ)義,是具體的服務(wù)兌現(xiàn)過(guò)程。例如,接口與實(shí)現(xiàn)它的類或組件、操作與實(shí)現(xiàn)它的方法等。擴(kuò)展機(jī)制為了擴(kuò)充在某些細(xì)節(jié)方面的描述能力,UML允許建模者在不改變整體語(yǔ)言風(fēng)格的基礎(chǔ)上定義一些通用性的擴(kuò)展。UML的三種擴(kuò)展機(jī)制:構(gòu)造型標(biāo)記值約束構(gòu)造型構(gòu)造型是將一個(gè)已有的元素模型進(jìn)行修改或精化,創(chuàng)造出一種新的模型元素。構(gòu)造型的信息內(nèi)容和形式與已存在的基本模型元素相同,但擁有不同的含義與用法。每個(gè)構(gòu)造型都從一個(gè)基本的模型元素派生而來(lái)。該構(gòu)造型的所有元素都具有基本模型元素的特性。構(gòu)造型的表示方法為一個(gè)雙尖括號(hào)內(nèi)附構(gòu)造型名稱,一般放在已有的基本模型元素符號(hào)上方。標(biāo)記值標(biāo)記值是關(guān)于模型元素本身的一個(gè)屬性的定義,即一個(gè)元屬性的定義。標(biāo)記定義被構(gòu)造型所擁有。標(biāo)記可以用來(lái)存儲(chǔ)元素的任意信息,它是一個(gè)名稱-值組合,表現(xiàn)為形如”property=value”的字符串形式。約束約束是使用某種文本語(yǔ)言中的陳述句表達(dá)的語(yǔ)義條件或者限制。通常約束可以附加在任何一個(gè)或一組模型元素上,它表達(dá)了附加在元素上的額外語(yǔ)義信息。約束使用大括號(hào)({})中的文本串表示,可以應(yīng)用于大部分UML元素。4.3“4+1”視圖模型“4+1”視圖模型的概念和組成“4+1”視圖模型的要解決的問(wèn)題運(yùn)用“4+1”視圖方法進(jìn)行軟件架構(gòu)設(shè)計(jì)“4+1”視圖模型的概念和組成在“4+1”視圖模型中,軟件開(kāi)發(fā)者從五個(gè)不同視角描述軟件體系結(jié)構(gòu)的一組視圖模型。邏輯視圖:負(fù)責(zé)反映出系統(tǒng)內(nèi)部是如何組織和協(xié)作來(lái)實(shí)現(xiàn)功能的。開(kāi)發(fā)視圖:面向開(kāi)發(fā)人員,用來(lái)描述軟件的各個(gè)模塊的組織方式。進(jìn)程視圖:主要描述系統(tǒng)的運(yùn)行特性,關(guān)注運(yùn)行時(shí)概念。物理視圖:主要描述硬件配置。場(chǎng)景視圖:從項(xiàng)目需求入手,將四個(gè)視圖結(jié)合為一個(gè)整體。四個(gè)視圖的元素需要協(xié)同工作以實(shí)現(xiàn)場(chǎng)景視圖中給出的用例,它是距離用戶需要最近的視圖,也是軟件開(kāi)發(fā)中的重要驅(qū)動(dòng)要素?!?+1”視圖模型的概念和組成“4+1”視圖模型的要解決的問(wèn)題從工程上簡(jiǎn)化一個(gè)問(wèn)題,一種首要的思路就是分而治之。通常使用的分而治之策略有分層法、模塊法等等。其中,對(duì)于模塊化而言,對(duì)于每個(gè)模塊實(shí)行不同的較為單一的操作,透明化模塊內(nèi)部的信息,是一種重要的方法論?!?+1”視圖方法是一種視圖模型設(shè)計(jì)的多重視圖方法,屬于一種特殊的模塊法。運(yùn)用“4+1”視圖方法進(jìn)行軟件架構(gòu)設(shè)計(jì)首要問(wèn)題:需求首要視圖:場(chǎng)景視圖邏輯視圖:細(xì)化場(chǎng)景處理視圖、開(kāi)發(fā)視圖和物理視圖:針對(duì)不同方面解決問(wèn)題用例圖

5.1用例圖的基本概念用例圖是表示一個(gè)系統(tǒng)中用例與參與者關(guān)系之間的圖。它描述了系統(tǒng)中相關(guān)的用戶和系統(tǒng)對(duì)不同用戶提供的功能和服務(wù)。用例圖相當(dāng)于從用戶的視角來(lái)描述和建模整個(gè)系統(tǒng),分析系統(tǒng)的功能與行為。用例圖中的主要元素包括參與者、用例以及元素之間的關(guān)系。此外,用例圖還可以包括注解和約束,也可以使用包將圖中的元素組合成模塊。5.1用例圖的基本概念5.2參與者參與者的概念確定參與者參與者的泛化關(guān)系參與者的概念參與者是與系統(tǒng)主體交互的外部實(shí)體的類元,描述了一個(gè)或一組與系統(tǒng)產(chǎn)生交互的外部用戶或外部事物。參與者位于系統(tǒng)邊界之外,而不是系統(tǒng)的一部分。參與者是從現(xiàn)實(shí)世界中抽象出來(lái)的一種形式,卻不一定確切對(duì)應(yīng)的現(xiàn)實(shí)中的某個(gè)特定對(duì)象。確定參與者通過(guò)對(duì)參與者進(jìn)行關(guān)注和分析,我們可以把重點(diǎn)放在如何與系統(tǒng)交互這一問(wèn)題上,便于進(jìn)一步確定系統(tǒng)的邊界。另外,參與者也決定了系統(tǒng)需求的完整性。確定參與者可以從以下幾個(gè)角度來(lái)考慮:為系統(tǒng)提供輸入的人或事物接收系統(tǒng)輸出的人或事物需要接入的第三方系統(tǒng)或設(shè)備時(shí)間是否會(huì)觸發(fā)某些事件負(fù)責(zé)支持或維護(hù)系統(tǒng)中信息的人確定參與者系統(tǒng)中的參與者一般可以分為四類:主要業(yè)務(wù)參與者:主要從用例的執(zhí)行中獲得好處的關(guān)聯(lián)人員。主要系統(tǒng)參與者:直接同系統(tǒng)交互以發(fā)起或觸發(fā)業(yè)務(wù)或系統(tǒng)事件的關(guān)聯(lián)人員。外部服務(wù)參與者:響應(yīng)來(lái)自用例的請(qǐng)求的關(guān)聯(lián)人員。外部接收參與者:從用例中接收某些價(jià)值或輸出的非主要的關(guān)聯(lián)人員。參與者的泛化關(guān)系當(dāng)系統(tǒng)中的幾個(gè)參與者既扮演自身的角色,同時(shí)也有更一般化的角色時(shí),可以通過(guò)建立泛化關(guān)系來(lái)進(jìn)行描述。與類相似,父參與者可以是抽象的,即不能創(chuàng)建一個(gè)父參與者的直接實(shí)例,這就要求屬于抽象父參與者的外部對(duì)象一定能夠?qū)儆谄渥訁⑴c者之一。5.3用例用例的概念用例與參與者用例的特征用例的粒度用例的概念用例是類元提供的一個(gè)內(nèi)聚的的功能單元,表明系統(tǒng)與一個(gè)或多個(gè)參與者之間信息交換的順序,也表明了系統(tǒng)執(zhí)行的動(dòng)作。簡(jiǎn)單來(lái)說(shuō),用例就是某一個(gè)參與者在系統(tǒng)中做某件事從開(kāi)始到結(jié)束的一系列活動(dòng)的集合,以及結(jié)束時(shí)應(yīng)該返回的可觀測(cè)、有意義的結(jié)果,其中也包含可能的各種分支情況。用例與用例圖被廣泛使用于系統(tǒng)的需求建模階段,并在系統(tǒng)的整個(gè)生命周期中被不斷細(xì)化。用例與參與者一個(gè)用例可以隸屬一個(gè)或多個(gè)參與者,一個(gè)參與者也可以參與一個(gè)或多個(gè)用例。用例與參與者之間存在關(guān)聯(lián)關(guān)系。主參與者與次參與者:通常來(lái)說(shuō)主參與者是用例的重要服務(wù)對(duì)象,而次參與者處于一種協(xié)作地位。用例與參與者在確定用例時(shí)可以通過(guò)參與者入手來(lái)尋找用例:參與者的主要任務(wù)是什么?參與者需要系統(tǒng)的什么信息?參與者可以為系統(tǒng)提供什么信息?系統(tǒng)需要通知參與者發(fā)生的變化和事件嗎?參與者需要通知系統(tǒng)發(fā)生的變化和事件嗎?用例的特征用例的特征保證用例能夠正確地捕捉功能性需求,同時(shí)也是判斷用例是否準(zhǔn)確的依據(jù)。用例是動(dòng)賓短語(yǔ)用例是相對(duì)獨(dú)立的用例是由參與者啟動(dòng)的用例要有可觀測(cè)的執(zhí)行結(jié)果一個(gè)用例是一個(gè)單元用例的粒度用例粒度指的是用例組織信息的方式和細(xì)化程度。用例的粒度在業(yè)務(wù)建模階段,用例的粒度以每個(gè)用例描述一個(gè)完整的事情為宜。在概念建模階段,用例的粒度以每個(gè)用例能描述一個(gè)完整的事件流為宜。在系統(tǒng)建模階段,用例的粒度以一個(gè)用例能夠描述參與者與計(jì)算機(jī)的一次完整交互為宜。5.4用例之間的關(guān)系泛化關(guān)系依賴關(guān)系包含擴(kuò)展泛化關(guān)系與參與者的泛化關(guān)系相似,用例的泛化關(guān)系將特化的用例與一般化的用例聯(lián)系起來(lái)。子用例繼承了父用例的屬性、操作和行為序列,并且可以增加屬于自己的附加屬性和操作。父用例同樣可以定義為抽象用例。依賴關(guān)系——包含包含指的是一個(gè)用例(基用例)可以包含其他用例(包含用例)具有的行為,其中包含用例中定義的行為將被插入基用例定義的行為中。包含的兩個(gè)基本約束:基用例可以看到包含用例,并需要依賴于包含用例的執(zhí)行結(jié)果,但是它對(duì)包含用例的內(nèi)部結(jié)構(gòu)沒(méi)有了解;基用例一定會(huì)要求包含用例執(zhí)行。依賴關(guān)系——擴(kuò)展擴(kuò)展指的是一個(gè)用例(擴(kuò)展用例)對(duì)另一個(gè)用例(基用例)行為的增強(qiáng)。在這一關(guān)系中,擴(kuò)展用例包含了一個(gè)或多個(gè)片段,每個(gè)片段都可以插入到基用例中的一個(gè)單獨(dú)的位置上,而基用例對(duì)于擴(kuò)展的存在是毫不知情的。使用擴(kuò)展用例我們就可以在不改變基用例的同時(shí),根據(jù)需要自由地向用例中添加行為。依賴關(guān)系——擴(kuò)展擴(kuò)展用例的使用包括四個(gè)部分:基用例:需要被擴(kuò)展的用例,如圖5-10中的“注冊(cè)”用例。擴(kuò)展用例:提供所添加的行為序列的用例,如圖5-10中的“檢查實(shí)名信息”用例。擴(kuò)展關(guān)系:使用虛線箭頭表示,箭頭指向基用例。擴(kuò)展點(diǎn):基用例中的一個(gè)或多個(gè)位置,表示在該位置會(huì)根據(jù)某條件來(lái)決定是否要中斷基用例的執(zhí)行從而執(zhí)行擴(kuò)展用例中的片段。依賴關(guān)系特性includeextend作用增強(qiáng)基用例的行為增強(qiáng)基用例的行為執(zhí)行過(guò)程包含用例一定會(huì)執(zhí)行擴(kuò)展用例可能被執(zhí)行對(duì)基用例的要求在沒(méi)有包含用例的情況下,基用例可以是也可以不是良構(gòu)的在沒(méi)有擴(kuò)展用例的情況下,基用例一定是良構(gòu)的表示法箭頭指向包含用例箭頭指向基用例基用例對(duì)增強(qiáng)行為的可見(jiàn)性基用例可以看到包含用例,并決定包含用例的執(zhí)行基用例對(duì)擴(kuò)展用例一無(wú)所知基用例每執(zhí)行一次,增強(qiáng)行為的執(zhí)行次數(shù)只執(zhí)行一次取決于條件(0到多次)

5.5用例描述與文檔用例描述概述前置條件與后置條件事件流補(bǔ)充約束用例文檔實(shí)踐用例描述概述一個(gè)完整的用例模型應(yīng)該不僅僅包括用例圖部分,還要有完整的用例描述部分。一般的用例描述主要包括以下幾部分內(nèi)容:用例名稱:描述用例的意圖或?qū)崿F(xiàn)的目標(biāo),一般為動(dòng)詞或動(dòng)賓短語(yǔ)。用例編號(hào):用例的唯一標(biāo)識(shí)符,在其他位置可以使用該標(biāo)識(shí)符來(lái)引用用例。參與者:描述用例的參與者,包括主要參與者和其他參與者。用例描述:對(duì)用例的一段簡(jiǎn)單的概括描述。用例描述概述觸發(fā)器:觸發(fā)用例執(zhí)行的一個(gè)事件。前置條件:用例執(zhí)行前系統(tǒng)狀態(tài)的約束條件?;臼录鳎ǖ湫瓦^(guò)程):用例的常規(guī)活動(dòng)序列,包括參與者發(fā)起的動(dòng)作與系統(tǒng)執(zhí)行的響應(yīng)活動(dòng)。擴(kuò)展事件流(替代過(guò)程):記錄如果典型過(guò)程出現(xiàn)異?;蜃兓瘯r(shí)的用例行為,即典型過(guò)程以外的其他活動(dòng)步驟。結(jié)論:描述用例何時(shí)結(jié)束。后置條件:用例執(zhí)行后系統(tǒng)狀態(tài)的約束條件。補(bǔ)充約束:用例實(shí)現(xiàn)時(shí)需要考慮的業(yè)務(wù)規(guī)則、實(shí)現(xiàn)約束等信息。前置條件與后置條件前置條件指的是用例執(zhí)行前系統(tǒng)和參與者應(yīng)處于的狀態(tài)。前置條件是用例的入口限制,它便于我們?cè)谶M(jìn)行系統(tǒng)分析及設(shè)計(jì)的時(shí)候注意到,在何時(shí)何地才可以合法地觸發(fā)這個(gè)事件。后置條件是用例執(zhí)行完畢后系統(tǒng)處于的狀態(tài)。后置條件是對(duì)用例執(zhí)行完畢后系統(tǒng)狀況的總結(jié),用來(lái)確保用戶理解用例執(zhí)行完畢后的結(jié)果,并非其他用例的觸發(fā)器。前置條件與后置條件分別是用例在開(kāi)始和結(jié)束時(shí)的必要條件。事件流事件流是對(duì)用例在使用場(chǎng)景下的交互動(dòng)作的抽象,應(yīng)該包括用例何時(shí)以及怎樣開(kāi)始和結(jié)束,用例何時(shí)與參與者交互,該行為的基本流和可選擇的流?;臼录鳎好枋龅氖怯美凶詈诵牡氖录?,是用例大部分時(shí)間所進(jìn)行的場(chǎng)景。擴(kuò)展事件流:描述的是用例處理過(guò)程中的一些分支或異常情況。補(bǔ)充約束補(bǔ)充約束用來(lái)描述用例在系統(tǒng)功能之外的內(nèi)容,例如非功能需求、業(yè)務(wù)規(guī)則等等。數(shù)據(jù)需求:與該用例相關(guān)的一些數(shù)據(jù)項(xiàng)的說(shuō)明。業(yè)務(wù)規(guī)則:與業(yè)務(wù)相關(guān)的邏輯和操作規(guī)則。非功能性需求:例如性能、支持的并發(fā)量等。設(shè)計(jì)約束:是從多個(gè)角度對(duì)用例或系統(tǒng)的約定。用例文檔實(shí)踐用例名稱提交訂單用例編號(hào)UC002參與者會(huì)員用例描述該用例描述一個(gè)系統(tǒng)會(huì)員提交一份訂單的行為觸發(fā)器當(dāng)訂單被提交時(shí),用例觸發(fā)。前置條件提交訂單的一方需要完成登錄操作后置條件如果訂單中的商品有庫(kù)存,則發(fā)貨;否則提示用戶當(dāng)前缺貨基本事件流1參與者將訂單信息提交至系統(tǒng)。2系統(tǒng)驗(yàn)證用戶信息及訂單信息合法后作出響應(yīng)。3對(duì)于訂單中的每種產(chǎn)品,系統(tǒng)根據(jù)訂單中的數(shù)量檢查產(chǎn)品庫(kù)存數(shù)量。4系統(tǒng)統(tǒng)計(jì)訂單中產(chǎn)品的總價(jià)格。5系統(tǒng)從會(huì)員的系統(tǒng)賬戶余額中扣除相應(yīng)金額。6系統(tǒng)生成并保存訂單信息并將訂單發(fā)送至分銷中心。7系統(tǒng)生成訂單確認(rèn)頁(yè)面并發(fā)送給會(huì)員。擴(kuò)展事件流A-2如果訂單信息非法,系統(tǒng)通知會(huì)員并提示重新提交訂單。A-3如果訂單中產(chǎn)品數(shù)量超過(guò)產(chǎn)品庫(kù)存量,則提示會(huì)員庫(kù)存不足,暫無(wú)法購(gòu)買(mǎi),取消訂單同時(shí)終止用例。A-5如果會(huì)員賬戶余額不足,系統(tǒng)給出相應(yīng)提示,取消訂單并終止用例。結(jié)論當(dāng)會(huì)員收到系統(tǒng)發(fā)送的訂單確認(rèn)頁(yè)面或其他異常信息時(shí),用例結(jié)束。數(shù)據(jù)需求D-1訂單信息包括訂單號(hào)、參與者的會(huì)員賬戶名、商品種類數(shù)量、商品種類名稱以及每種商品的數(shù)量。業(yè)務(wù)規(guī)則B-1只有當(dāng)訂單中商品信息確認(rèn)無(wú)誤后才能要求會(huì)員進(jìn)行支付。5.6應(yīng)用用例圖建模用例圖建模技術(shù)用例圖使用要點(diǎn)用例圖建模技術(shù)對(duì)系統(tǒng)的語(yǔ)境建模識(shí)別系統(tǒng)邊界。識(shí)別參與者。如果需要,將具有相同特征的參與者使用泛化關(guān)系加以組織。如果需要,對(duì)某些參與者應(yīng)用一個(gè)構(gòu)造型以便加深理解。將參與者應(yīng)用到用例圖中,并描述參與者與用例間的通信路徑。用例圖建模技術(shù)對(duì)系統(tǒng)的需求建模識(shí)別參與者。對(duì)于某個(gè)參與者,考慮其期望系統(tǒng)提供的行為或與系統(tǒng)的交互。將行為提煉成用例。完善其他用例。分解用例中的公共行為與擴(kuò)展行為,放入新的用例中以供其他用例使用。創(chuàng)建用例圖。如果需要,在用例圖中添加一些注解或約束來(lái)陳述系統(tǒng)的非功能需求。用例圖使用要點(diǎn)構(gòu)建結(jié)構(gòu)良好的用例。用例圖中應(yīng)該只包含對(duì)系統(tǒng)而言必不可少的用例與相關(guān)的參與者。用例的名稱不應(yīng)該簡(jiǎn)化到使讀者誤解其主要語(yǔ)義的程度。擺放元素時(shí)應(yīng)盡量減少連接線的交叉,以提供更好的可視化效果。組織元素時(shí)應(yīng)使在語(yǔ)義上接近的用例和參與者在圖的位置上也同樣接近,便于讀者理解用例圖。可以使用注解或給元素添加顏色等方式突出圖中相對(duì)重要的內(nèi)容。用例圖中不應(yīng)該有太多的關(guān)系種類。5.7實(shí)驗(yàn):使用Rose繪制用例圖5.7.1用例圖的Rose操作5.7.2繪制機(jī)票預(yù)訂系統(tǒng)的用例圖類圖與對(duì)象圖

6.1類圖的基本概念類圖是顯示一組類、接口、協(xié)作以及它們之間關(guān)系的圖。一個(gè)類圖主要通過(guò)系統(tǒng)中的類以及各個(gè)類之間的關(guān)系來(lái)描述系統(tǒng)的靜態(tài)結(jié)構(gòu)。類圖主要包含7種元素:類、接口、協(xié)作、依賴關(guān)系、泛化關(guān)系、實(shí)現(xiàn)關(guān)系和關(guān)聯(lián)關(guān)系。類圖中還可以含有包或子系統(tǒng),用來(lái)把模型元素聚集成更大的組塊。與其他UML圖類似,類圖同樣可以創(chuàng)建約束和注解等。6.1類圖的基本概念6.2類圖的組成元素類接口類圖中的關(guān)系涉及類的其他概念類類是一組擁有相同的屬性、操作、方法、關(guān)系和行為的對(duì)象描述符。類定義了一組有著狀態(tài)與行為的對(duì)象。類的狀態(tài)由屬性和關(guān)聯(lián)來(lái)描述,個(gè)體行為由操作來(lái)描述,對(duì)象的生命周期則由附加給類的狀態(tài)機(jī)來(lái)描述。在UML中,類表達(dá)成一個(gè)有三個(gè)分隔區(qū)的矩形。其中頂端顯示類名,中間顯示類的屬性,尾端顯示類的操作。類——類名類名是一個(gè)文本串,作為區(qū)別于其他類的名稱。類名有兩種表示方法:簡(jiǎn)單名:Person路徑名:java::awt::Rectangle類的命名規(guī)范:一般以大寫(xiě)字母開(kāi)頭,大小寫(xiě)混合,每個(gè)單詞首字母大寫(xiě),避免使用特殊符號(hào)。類——屬性屬性是已被命名的類的特性,它描述了該特性的實(shí)例可以取值的范圍。屬性的語(yǔ)法格式:可見(jiàn)性opt

屬性名?:類型?opt

多重性opt?=初始值?opt?{特性}?opt屬性名:屬性的標(biāo)識(shí)符。在描述屬性時(shí),屬性名是必須的,其他部分可選。屬性的命名規(guī)范一般以小寫(xiě)字母開(kāi)頭,非首單詞的首字母大寫(xiě)。對(duì)屬性名添加下劃線修飾表示該屬性為靜態(tài)屬性。類——屬性可見(jiàn)性英文限定符UML標(biāo)準(zhǔn)圖示Rose圖示說(shuō)明公有public+其他類可以訪問(wèn)私有private-只對(duì)本類可見(jiàn),不能被其他類訪問(wèn)保護(hù)protected#對(duì)本類及其派生類可見(jiàn)可見(jiàn)性:描述了該屬性在那些范圍內(nèi)可以被使用。類型:屬性的數(shù)據(jù)類型,可以系統(tǒng)固有,也可以用戶自定義。屬性的類型決定了該屬性的所有可能取值的集合。類——屬性多重性:屬性的多重性表示為一個(gè)包含于方括號(hào)中的數(shù)字表達(dá)式,位于類型名后,相當(dāng)于編程語(yǔ)言中的數(shù)組概念。例如:inTp[10]初始值:作為創(chuàng)建該類對(duì)象時(shí)這個(gè)屬性的默認(rèn)值。例如:inti=10;特性:即對(duì)屬性性質(zhì)的約束,UML定義了3中可以用于屬性的特性,即可變、只增與凍結(jié)。類——操作操作是一個(gè)可以由類的對(duì)象請(qǐng)求以影響其行為的服務(wù)的實(shí)現(xiàn),也即是對(duì)一個(gè)對(duì)象所做的事情的抽象,并且由這個(gè)類的所有對(duì)象共享。操作是類的行為特征或動(dòng)態(tài)特征。操作的語(yǔ)法格式為:可見(jiàn)性opt

操作名?(參數(shù)列表)?opt?:返回類型?opt?{特性}?opt操作名:操作的標(biāo)識(shí)符。在描述操作時(shí),操作名是必須的,其他部分可選。對(duì)操作名添加下劃線修飾表示該屬性為靜態(tài)操作。類——操作可見(jiàn)性:同樣描述該操作在那些范圍內(nèi)可以使用,與屬性的可見(jiàn)性相同。參數(shù)列表:是一些按照順序排列的屬性定義了操作的輸入。例如:oper(outarg1:int,arg2:double=3.2)返回類型即回送調(diào)用對(duì)象消息的類型。void關(guān)鍵字表示無(wú)返回值。特性是對(duì)操作性質(zhì)的約束說(shuō)明。類——職責(zé)職責(zé)是類的契約或責(zé)任。當(dāng)創(chuàng)建一個(gè)類時(shí),就聲明了這個(gè)類的所有對(duì)象具有相同種類的狀態(tài)和相同種類的行為。在較高的抽象層次上,這些相應(yīng)的屬性和操作正式要完成類的職責(zé)的特征。類的職責(zé)是自由形式的文本,在非正式的類圖中,可以將職責(zé)列在類圖操作下的另一分割欄中。接口接口是一個(gè)被命名的操作集合,用于描述類或組件的一個(gè)服務(wù)。接口不包含屬性與方法實(shí)現(xiàn),但可以有一些操作。接口的所有內(nèi)容都是公有的。接口代表了一份契約,實(shí)現(xiàn)該接口的類元必須履行它。在UML中,接口由一個(gè)帶名稱的小圓圈表示;也可以表示為帶有<<interface>>構(gòu)造型的類。類圖中的關(guān)系在類圖中,很少有類是獨(dú)立為系統(tǒng)發(fā)揮作用的,大部分的類以某些方式彼此協(xié)作進(jìn)行工作。在進(jìn)行系統(tǒng)建模時(shí),不僅要抽象出形成系統(tǒng)詞匯的事物,還必須對(duì)這些事物之間的關(guān)系進(jìn)行建模。類圖中涉及到了UML中最常用的四種關(guān)系,即關(guān)聯(lián)關(guān)系、泛化關(guān)系、依賴關(guān)系和實(shí)現(xiàn)關(guān)系。類圖中的關(guān)系——關(guān)聯(lián)關(guān)系關(guān)聯(lián)的實(shí)例被稱為鏈,每個(gè)鏈由一組有序或無(wú)序的對(duì)象組成。關(guān)聯(lián)關(guān)系靠近被關(guān)聯(lián)元素的部分稱為關(guān)聯(lián)端,關(guān)聯(lián)的大部分描述都包含在一組關(guān)聯(lián)端的列表里,每個(gè)端用來(lái)描述關(guān)聯(lián)中類的對(duì)象的參與。最普通也是最常用的關(guān)聯(lián)關(guān)系是二元關(guān)聯(lián),二元關(guān)聯(lián)即有兩個(gè)關(guān)聯(lián)端的關(guān)聯(lián)關(guān)系。特別地,一個(gè)類與自身的關(guān)聯(lián)稱為自關(guān)聯(lián)。當(dāng)3個(gè)或以上的類之間存在關(guān)聯(lián)關(guān)系時(shí),便無(wú)法使用二元關(guān)聯(lián)的表示法了,此時(shí)稱之為N元關(guān)聯(lián)。類圖中的關(guān)系——關(guān)聯(lián)關(guān)系二元關(guān)聯(lián)自關(guān)聯(lián)三元關(guān)聯(lián)類圖中的關(guān)系——關(guān)聯(lián)關(guān)系關(guān)聯(lián)名稱:放在關(guān)聯(lián)路徑的旁邊,但遠(yuǎn)離關(guān)聯(lián)端。角色:放在靠近關(guān)聯(lián)端的部分,表示該關(guān)聯(lián)端連接的類在這一關(guān)聯(lián)關(guān)系中擔(dān)任的角色。角色名上也可使用可見(jiàn)性修飾符號(hào)。多重性:放在靠近關(guān)聯(lián)端的部分,表示在關(guān)聯(lián)關(guān)系中源端的一個(gè)對(duì)象可以與目標(biāo)類的多少個(gè)對(duì)象之間有關(guān)聯(lián)。導(dǎo)航性:一個(gè)布爾值,用來(lái)說(shuō)明運(yùn)行時(shí)刻是否可能穿越一個(gè)關(guān)聯(lián)。限定符:是二元關(guān)聯(lián)上的屬性組成的列表的插槽,其中的屬性值用來(lái)從整個(gè)對(duì)象集合里選擇一個(gè)唯一的關(guān)聯(lián)對(duì)象或者關(guān)聯(lián)對(duì)象的集合。約束:關(guān)聯(lián)間的約束關(guān)系。類圖中的關(guān)系——關(guān)聯(lián)關(guān)系角色多重性導(dǎo)航性限定符約束類圖中的關(guān)系——關(guān)聯(lián)關(guān)系兩種特殊的關(guān)聯(lián)關(guān)系:聚合關(guān)系與組合關(guān)系聚合關(guān)系描述“整體-部分”的關(guān)聯(lián)關(guān)系聚合關(guān)系沒(méi)有改變整體與部分之間整個(gè)關(guān)聯(lián)的導(dǎo)航含義,也與整體和部分的生命周期無(wú)關(guān)。組合關(guān)系描述“整體-部分”的關(guān)聯(lián)關(guān)系組合關(guān)系中的部分要完全依賴于整體。類圖中的關(guān)系——關(guān)聯(lián)關(guān)系派生關(guān)聯(lián):屬于一種派生元素。它不增加語(yǔ)義信息,只是一種可以由兩個(gè)或兩個(gè)以上的基礎(chǔ)關(guān)聯(lián)推算出來(lái)的虛擬關(guān)聯(lián)。派生語(yǔ)義在模型中不添加任何額外的語(yǔ)義,只是為了方便關(guān)聯(lián)的使用。類圖中的關(guān)系——泛化關(guān)系泛化關(guān)系定義為一個(gè)較普通的元素與一個(gè)較特殊的元素之間的類元關(guān)系。其中描述一般的元素稱為父,描述特殊的元素稱為子。通過(guò)泛化對(duì)應(yīng)的繼承機(jī)制使子類共享父類的屬性和操作,縮小了模型的規(guī)模,同時(shí)也防止了模型的更新所導(dǎo)致的定義不一致的意外。泛化關(guān)系的特征:傳遞性:一個(gè)類的子類同樣繼承了這個(gè)類的特性。在父方向上經(jīng)過(guò)了一個(gè)或幾個(gè)泛化的元素被稱為祖先,在子方向上則被稱為后代。反對(duì)稱性:泛化關(guān)系不能成環(huán),即一個(gè)類不可能是自己的祖先和自己的后代。類圖中的關(guān)系——泛化關(guān)系泛化關(guān)系的兩種情況單繼承:每個(gè)類之多能擁有一個(gè)父類。編程語(yǔ)言:C#、Java等多重繼承:子類可以有多個(gè)父類并繼承了所有父類的結(jié)構(gòu)、行為和約束。編程語(yǔ)言:C++等類圖中的關(guān)系——依賴關(guān)系依賴關(guān)系表示的是兩個(gè)元素之間語(yǔ)義上的連接關(guān)系。對(duì)于兩個(gè)元素X和Y,如果元素X的變化會(huì)引起對(duì)另一個(gè)元素Y的變化,則稱元素Y依賴于X。其中,X被稱為提供者,Y被稱為客戶。對(duì)于類圖而言,主要有以下需要使用依賴的情況:客戶類向提供者類發(fā)送消息。提供者類是客戶類的屬性類型。提供者類是客戶類操作的參數(shù)類型。類圖中的關(guān)系——實(shí)現(xiàn)關(guān)系實(shí)現(xiàn)關(guān)系用來(lái)表示規(guī)格說(shuō)明與實(shí)現(xiàn)之間的關(guān)系。在類圖中,實(shí)現(xiàn)關(guān)系主要用于接口與實(shí)現(xiàn)該接口的類之間。一個(gè)類可以實(shí)現(xiàn)多個(gè)接口,一個(gè)接口也可以被多個(gè)類實(shí)現(xiàn)。實(shí)現(xiàn)關(guān)系的兩種表示法:當(dāng)接口元素以帶構(gòu)造型的類的方式表示時(shí),用虛線三角形箭頭表示。當(dāng)接口元素以小圓圈方式表示時(shí),用實(shí)線表示。涉及類的其他概念類的高級(jí)概念:抽象類模板類關(guān)聯(lián)類分析類涉及類的其他概念——抽象類抽象類即不可實(shí)例化的類,也就是說(shuō),抽象類沒(méi)有直接的實(shí)例。在UML中,抽象類通過(guò)對(duì)類名添加斜體修飾來(lái)表示。涉及類的其他概念——模板類模板又稱為參數(shù)化元素是對(duì)一類帶有一個(gè)或者多個(gè)未綁定的形式參數(shù)的元素的描述。模板應(yīng)用在類上時(shí)稱為模板類。對(duì)應(yīng)概念:C++中的模板與Java中的泛型模板類可以根據(jù)參數(shù)來(lái)定義類,而不用說(shuō)明屬性和操作參數(shù)及返回值的具體類型,使用時(shí)通過(guò)實(shí)際值代替參數(shù)即可創(chuàng)建新的類,這樣就可以避免建立大量功能相似的類。涉及類的其他概念——關(guān)聯(lián)類具有類的特性的關(guān)聯(lián)關(guān)系,稱為關(guān)聯(lián)類。關(guān)聯(lián)類具有關(guān)聯(lián)和類二者的特性,它既可以關(guān)聯(lián)類元素,也可以擁有屬性和操作。關(guān)聯(lián)類在UML中被表示為一個(gè)類符號(hào),并通過(guò)一條虛線連接到關(guān)聯(lián)路徑。涉及類的其他概念——分析類分析類是一個(gè)主要用于開(kāi)發(fā)過(guò)程中的概念,用來(lái)獲取系統(tǒng)中主要的“職責(zé)簇”,代表系統(tǒng)的原型類,是帶有某些構(gòu)造型的類元素。邊界類:用于對(duì)系統(tǒng)外部環(huán)境與其內(nèi)部運(yùn)作之間的交互進(jìn)行建模的類??刂祁悾簩?duì)一個(gè)或多個(gè)用例所特有的控制行為進(jìn)行建模的類。實(shí)體類:用于對(duì)必須存儲(chǔ)的信息和相關(guān)行為建模的類。涉及類的其他概念——分析類6.4類圖的建模技術(shù)類圖的建模技術(shù)正向工程與逆向工程面向?qū)ο笤O(shè)計(jì)的原則類圖的建模技術(shù)對(duì)系統(tǒng)的詞匯建模識(shí)別用戶或系統(tǒng)開(kāi)發(fā)人員用于描述問(wèn)題或解決問(wèn)題的那些實(shí)體??梢允褂没谟美治龅募夹g(shù)幫助用戶發(fā)現(xiàn)這些抽象。對(duì)于每個(gè)抽象,識(shí)別一個(gè)職責(zé)集。要明確地定義每個(gè)類,而且這些指責(zé)要在所有的類之間很好的均衡。提供為實(shí)現(xiàn)每個(gè)類的職責(zé)所需的屬性和操作。類圖的建模技術(shù)對(duì)簡(jiǎn)單協(xié)作建模識(shí)別要建模的機(jī)制。機(jī)制描述了正在建模的部分系統(tǒng)的一些功能和行為,這些功能起因于類、接口以及其他一些事物所組成的群體的相互作用。識(shí)別元素及其關(guān)系。對(duì)于每一種機(jī)制,分別識(shí)別參與協(xié)作的類、接口和其他協(xié)作,并識(shí)別這些事物之間的關(guān)系。用腳本排演這些事物。通過(guò)這種方法,可發(fā)現(xiàn)模型的哪些部分被遺漏以及哪些部分有明顯語(yǔ)義錯(cuò)誤。把元素和其包含的內(nèi)容聚集在一起。對(duì)于類而言,要做好職責(zé)的平均分配,然后逐漸把它們轉(zhuǎn)換成具體的屬性和操作。類圖的建模技術(shù)對(duì)邏輯數(shù)據(jù)庫(kù)模式建模識(shí)別模型中那些狀態(tài)必須超過(guò)應(yīng)用程序生存時(shí)間的類作為需要作為永久數(shù)據(jù)存儲(chǔ)的類。創(chuàng)建一個(gè)包含這些類的類圖??梢宰约憾x相關(guān)的構(gòu)造型和標(biāo)記值組合。對(duì)類的結(jié)構(gòu)細(xì)節(jié)進(jìn)行細(xì)化。包括屬性的細(xì)節(jié)、類之間的關(guān)聯(lián)及其多重性。注意那些增加數(shù)據(jù)庫(kù)設(shè)計(jì)復(fù)雜化的公共模式并盡量簡(jiǎn)化,如循環(huán)關(guān)聯(lián)、一對(duì)一的關(guān)聯(lián)和N元關(guān)聯(lián)等??紤]類的行為。這些行為主要包括對(duì)數(shù)據(jù)存取和數(shù)據(jù)完整性約束重要的操作。一般情況下,這些業(yè)務(wù)規(guī)則應(yīng)該被封裝在這些永久類的上一層中。正向工程與逆向工程正向工程:是通過(guò)到實(shí)現(xiàn)語(yǔ)言的映射而把模型轉(zhuǎn)換為代碼的過(guò)程。使用正向工程將模型轉(zhuǎn)換為代碼將導(dǎo)致一些信息丟失。正向工程的策略:確定映射到實(shí)現(xiàn)語(yǔ)言的規(guī)則。根據(jù)所選擇的語(yǔ)言,限制某些UML的特性。例如,當(dāng)所選擇的語(yǔ)言是Java時(shí),要禁止多重繼承的使用。使用標(biāo)記值來(lái)幫助實(shí)現(xiàn)目標(biāo)語(yǔ)言的細(xì)節(jié)。使用工具生成代碼。正向工程與逆向工程逆向工程:通過(guò)從特定語(yǔ)言的映射而把代碼轉(zhuǎn)換為模型的過(guò)程。一方面,逆向工程會(huì)產(chǎn)生大量的冗余信息;另一方面,逆向工程是不完整的。逆向工程的策略:確定實(shí)現(xiàn)語(yǔ)言進(jìn)行映射的規(guī)則。指定要進(jìn)行逆向工程的代碼。期望從一大塊代碼中逆向生成一個(gè)簡(jiǎn)明的模型是不切實(shí)際的。應(yīng)該選擇部分代碼,從底部建造模型。使用工具,通過(guò)查詢模型來(lái)創(chuàng)建類圖。人工為模型增加在逆向工程中丟失或隱藏的相關(guān)信息。面向?qū)ο笤O(shè)計(jì)的原則——開(kāi)閉原則內(nèi)容:軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開(kāi)放,對(duì)修改關(guān)閉。通俗來(lái)講,開(kāi)閉原則就是軟件系統(tǒng)中的各組件,應(yīng)該能夠在不修改現(xiàn)有內(nèi)容的基礎(chǔ)上,引入新功能。為了達(dá)到開(kāi)閉原則,對(duì)于類圖的設(shè)計(jì)應(yīng)該盡可能地使用接口或泛化進(jìn)行封裝,并且通過(guò)使用多態(tài)機(jī)制進(jìn)行調(diào)用。接口和泛化的使用可以使操作的定義與實(shí)現(xiàn)分離,使得新添加的模塊依賴于原有模塊的接口。多態(tài)的使用使得在使用時(shí)可以通過(guò)創(chuàng)建父類的間接實(shí)例通過(guò)多態(tài)的支持進(jìn)行操作,

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論