1、2022年6月23日星期四第1頁(yè)第5章 建立分析模型o面向?qū)ο蠓治霎a(chǎn)生分析模型。分析時(shí)用例模型作為輸入，對(duì)用例模型進(jìn)行分析，把系統(tǒng)分解為相互協(xié)作的分析類：邊界類、控制類和實(shí)體類，通過(guò)類圖、對(duì)象圖來(lái)描述對(duì)象、對(duì)象的屬性和對(duì)象之間的關(guān)系，產(chǎn)生系統(tǒng)的靜態(tài)模型。通過(guò)順序圖、協(xié)作圖描述對(duì)象的交互過(guò)程，以揭示對(duì)象間如何協(xié)作來(lái)完成每個(gè)具體的用例，產(chǎn)生系統(tǒng)的動(dòng)態(tài)模型。根據(jù)對(duì)象之間發(fā)送的消息給對(duì)象分配職責(zé)，確定對(duì)象/類的操作，并根據(jù)用例描述文檔、問(wèn)題陳述文檔等確定對(duì)象/類的屬性，進(jìn)一步完善類圖。 2022年6月23日星期四第2頁(yè)第5章 建立分析模型o5.1 對(duì)象、類和對(duì)象、類的UML表示o5.2 確定關(guān)鍵抽象o

2、5.3 類之間的關(guān)系及其UML表示o5.4 分析領(lǐng)域模型o5.5 分布模式的選擇與應(yīng)用o5.6 構(gòu)建分析類o5.7 交互圖o5.8 職責(zé)分配o5.9 定義類的屬性o5.10 分析模型o總結(jié)2022年6月23日星期四第3頁(yè)5.1 對(duì)象、類和對(duì)象、類的UML表示o1. 問(wèn)題引入問(wèn)題引入n在面向?qū)ο蟮姆治鲈O(shè)計(jì)中，對(duì)象和類是核心概念。那么什么是類和對(duì)象？如何在UML中表示類和對(duì)象？2022年6月23日星期四第4頁(yè)5.1 對(duì)象、類和對(duì)象、類的UML表示o2. 解答問(wèn)題解答問(wèn)題nRumbaugh對(duì)類的定義是：類是具有相似結(jié)構(gòu)、行為和關(guān)系的一組對(duì)象的描述符【RJB99】。類包括屬性和操作。n在UML中，類表

3、示為劃分成3個(gè)格子的長(zhǎng)方形，分別表示類的類名、屬性和操作。 2022年6月23日星期四第5頁(yè)5.1 對(duì)象、類和對(duì)象、類的UML表示n對(duì)象是類的一個(gè)實(shí)例。n在UML中，對(duì)象表示為一個(gè)長(zhǎng)方形，長(zhǎng)方形內(nèi)的命名為加下劃線的“對(duì)象名：類名” 。張三 : 客戶2022年6月23日星期四第6頁(yè)5.1 對(duì)象、類和對(duì)象、類的UML表示o3. 分析問(wèn)題分析問(wèn)題n(1) 對(duì)象n(2) 對(duì)象的狀態(tài)和行為n(3) 類2022年6月23日星期四第7頁(yè)5.2 確定關(guān)鍵抽象o1. 問(wèn)題引入問(wèn)題引入n類是對(duì)象的抽象，要確定系統(tǒng)中的類必須先明確系統(tǒng)中的對(duì)象。需求分析模型通常會(huì)揭示系統(tǒng)必須能夠處理的對(duì)象，這些對(duì)象被稱為關(guān)鍵抽象，確

4、定關(guān)鍵抽象的過(guò)程就是在需求分析模型中發(fā)現(xiàn)對(duì)象的過(guò)程。2022年6月23日星期四第8頁(yè)5.2 確定關(guān)鍵抽象o以下是從客戶服務(wù)系統(tǒng)的需求說(shuō)明書(shū)上摘錄的功能需求：n(1) 客戶可以通過(guò)不同的方式（如電話，互聯(lián)網(wǎng)）對(duì)軟件產(chǎn)品或項(xiàng)目提出使用中的BUG或疑難問(wèn)題以及投訴建議等內(nèi)容。n(2) 客戶服務(wù)人員應(yīng)當(dāng)能保存客戶資料，保存客戶歷次來(lái)電內(nèi)容，并對(duì)客戶提出的問(wèn)題及時(shí)給予解答，不能在電話中處理的應(yīng)當(dāng)交由相關(guān)技術(shù)工程師繼續(xù)跟進(jìn)處理。n(3) 對(duì)需要安排上門(mén)維護(hù)的申請(qǐng)應(yīng)能及時(shí)反映給相關(guān)部門(mén)領(lǐng)導(dǎo)，并由其作出派工處理。2022年6月23日星期四第9頁(yè)5.2 確定關(guān)鍵抽象n(4) 應(yīng)能及時(shí)反饋有派工任務(wù)的消息給相關(guān)技

5、術(shù)工程師，并能保存其處理結(jié)果。n(5) 各部門(mén)領(lǐng)導(dǎo)應(yīng)能對(duì)投訴的申請(qǐng)給予及時(shí)處理，并能保存處理結(jié)果。n(6) 公司領(lǐng)導(dǎo)和部門(mén)領(lǐng)導(dǎo)應(yīng)能及時(shí)查詢客戶的來(lái)電內(nèi)容，了解產(chǎn)品使用情況及客戶服務(wù)人員的售后服務(wù)質(zhì)量等相關(guān)業(yè)務(wù)的綜合統(tǒng)計(jì)信息。o需要從中抽取重要的信息，得到關(guān)鍵抽象。 2022年6月23日星期四第10頁(yè)5.2 確定關(guān)鍵抽象o2. 解答問(wèn)題解答問(wèn)題n(1) 將功能需求中的名詞作為候選關(guān)鍵抽象提取出來(lái)，填入表5-1所示的表格中。 2022年6月23日星期四第11頁(yè)o表5-1 獲選關(guān)鍵抽象表格候選的關(guān)鍵抽象候選的關(guān)鍵抽象排除的原因排除的原因選定的名字選定的名字客戶客戶服務(wù)人員軟件產(chǎn)品和項(xiàng)目疑難問(wèn)題投訴建

6、議客戶資料來(lái)電內(nèi)容上門(mén)維護(hù)的申請(qǐng)部門(mén)領(lǐng)導(dǎo)派工任務(wù)技術(shù)工程師處理結(jié)果投訴的申請(qǐng)售后服務(wù)質(zhì)量2022年6月23日星期四第12頁(yè)5.2 確定關(guān)鍵抽象o(2) 使用使用CRC（類的職責(zé)和協(xié)作）卡片建模（類的職責(zé)和協(xié)作）卡片建模技術(shù)過(guò)濾候選關(guān)鍵抽象技術(shù)過(guò)濾候選關(guān)鍵抽象n要識(shí)別一個(gè)候選關(guān)鍵抽象是否是一個(gè)真正的關(guān)要識(shí)別一個(gè)候選關(guān)鍵抽象是否是一個(gè)真正的關(guān)鍵抽象，應(yīng)該先確定這個(gè)候選關(guān)鍵抽象是否擔(dān)鍵抽象，應(yīng)該先確定這個(gè)候選關(guān)鍵抽象是否擔(dān)負(fù)著職責(zé)，同時(shí)是否有協(xié)作關(guān)系。負(fù)著職責(zé)，同時(shí)是否有協(xié)作關(guān)系。n 選擇一個(gè)候選的關(guān)鍵抽象。選擇一個(gè)候選的關(guān)鍵抽象。o例如：例如： “派工任務(wù)派工任務(wù)”。 2022年6月23日星期四第

7、13頁(yè)5.2 確定關(guān)鍵抽象n 確定一個(gè)與該候選關(guān)鍵抽象顯著相關(guān)的用例。o例如：從上面章節(jié)的用例中尋找到與“派工任務(wù)”相關(guān)的用例：查詢自己的派工單及報(bào)告信息、接受并處理自己的派工單、填寫(xiě)報(bào)告、查詢維護(hù)人員派工單的執(zhí)行情況、安排派工任務(wù)。 2022年6月23日星期四第14頁(yè)5.2 確定關(guān)鍵抽象n 查看用例場(chǎng)景和系統(tǒng)的功能需求，用CRC卡記錄抽取出來(lái)的關(guān)鍵抽象的職責(zé)和協(xié)作關(guān)系。如表5-2所示。 2022年6月23日星期四第15頁(yè)表5-2 CRC卡類名類名-派工單派工單職責(zé)職責(zé)協(xié)作者協(xié)作者制定日期完成日期派工信息報(bào)告信息維護(hù)查詢狀態(tài)完成情況客戶資料2022年6月23日星期四第16頁(yè)5.2 確定關(guān)鍵抽象

8、n 基于以上的工作，更新候選關(guān)鍵抽象表格，如表5-3所示。2022年6月23日星期四第17頁(yè)表5-3 更新后候選關(guān)鍵抽象表格 候選的關(guān)鍵抽象候選的關(guān)鍵抽象排除的原因排除的原因選定的名字選定的名字客戶與客戶資料同義客戶服務(wù)人員客戶服務(wù)人員軟件產(chǎn)品和項(xiàng)目軟件產(chǎn)品項(xiàng)目疑難問(wèn)題咨詢記錄投訴建議咨詢記錄的子類客戶資料客戶資料來(lái)電內(nèi)容咨詢記錄的子類上門(mén)維護(hù)的申請(qǐng)與派工任務(wù)同義部門(mén)領(lǐng)導(dǎo)部門(mén)領(lǐng)導(dǎo)派工任務(wù)派工單技術(shù)工程師維護(hù)人員處理結(jié)果派工任務(wù)的屬性投訴的申請(qǐng)咨詢記錄的子類售后服務(wù)質(zhì)量派工任務(wù)的屬性以及咨詢記錄的屬性2022年6月23日星期四第18頁(yè)5.2 確定關(guān)鍵抽象o3. 分析問(wèn)題分析問(wèn)題n(1) 搜集關(guān)鍵

9、抽象的來(lái)源o術(shù)語(yǔ)表o軟件需求o反映領(lǐng)域知識(shí)的既往經(jīng)驗(yàn)等。n由于關(guān)鍵抽象是指那些能始終貫穿分析和設(shè)計(jì)的類及相應(yīng)對(duì)象，所以關(guān)鍵抽象往往對(duì)應(yīng)重要的實(shí)體信息。這些反映實(shí)體信息的關(guān)鍵抽象，通常被稱為實(shí)體類。 2022年6月23日星期四第19頁(yè)5.2 確定關(guān)鍵抽象n(2) 識(shí)別關(guān)鍵抽象n就建模而言，識(shí)別關(guān)鍵抽象的過(guò)程并不復(fù)雜，主要有兩個(gè)要點(diǎn)：o從上述來(lái)源中找出候選的關(guān)鍵抽象集合，根據(jù)關(guān)鍵抽象的基本含義作出相應(yīng)取舍。o將被確認(rèn)的關(guān)鍵抽象以類的形式（實(shí)體類）加入分析模型，為每個(gè)關(guān)鍵抽象作簡(jiǎn)要文字說(shuō)明。n在此所確定的類將在項(xiàng)目的進(jìn)行過(guò)程中不斷變化和演進(jìn)。這一步驟的目的不是要確定一組在整個(gè)設(shè)計(jì)過(guò)程中始終都存在的類

10、，而是要確定系統(tǒng)必須處理的核心概念。 2022年6月23日星期四第20頁(yè)5.3 類之間的關(guān)系及其類之間的關(guān)系及其UML表示表示o5.3.1 關(guān)聯(lián)o5.3.2 依賴o5.3.3 泛化o5.3.4 聚合o5.3.5 組合2022年6月23日星期四第21頁(yè)5.3.1 關(guān)聯(lián)o1. 問(wèn)題引入問(wèn)題引入n我們回過(guò)頭再去看看在確定關(guān)鍵抽象過(guò)程中的CRC卡，該卡實(shí)際上也反映出了該關(guān)鍵抽象也就是類的相關(guān)信息，即CRC中的“職責(zé)”可以表示為類中的屬性和操作，而CRC中的“協(xié)作者”其實(shí)是另一個(gè)關(guān)鍵抽象，也就是另一個(gè)類，那么我們也就可以看出類與類之間是有協(xié)作關(guān)系的。在這里就牽涉到了另一個(gè)問(wèn)題，即類之間的關(guān)系，一般來(lái)說(shuō)，

11、類之間的關(guān)系有：關(guān)聯(lián)、聚合、組合、泛化、依賴等。請(qǐng)描述上節(jié)中“派工單”與“客戶資料”之間的關(guān)系，并在UML中表示它們之間的關(guān)系。2022年6月23日星期四第22頁(yè)5.3.1 關(guān)聯(lián)o2. 解答問(wèn)題解答問(wèn)題n“派工單”與“客戶資料”之間是關(guān)聯(lián)關(guān)系，在UML中表示如圖5-3所示。圖5-3 關(guān)聯(lián)關(guān)系圖 2022年6月23日星期四第23頁(yè)5.3.1 關(guān)聯(lián)o3. 分析問(wèn)題分析問(wèn)題n關(guān)聯(lián)關(guān)系表示不同類的對(duì)象之間的結(jié)構(gòu)關(guān)系，它在一段時(shí)間內(nèi)將多個(gè)類的實(shí)例連接在一起。n在客戶服務(wù)系統(tǒng)中，派工單是對(duì)應(yīng)于某一個(gè)客戶的，為了能夠讓客戶服務(wù)人員隨時(shí)了解某客戶所對(duì)應(yīng)的派工單，系統(tǒng)就必須讓客戶對(duì)象隨時(shí)能引用到其所有的派工單對(duì)

12、象。因此可以判定它們之間是關(guān)聯(lián)關(guān)系。 2022年6月23日星期四第24頁(yè)5.3.1 關(guān)聯(lián)o(1) 關(guān)聯(lián)名稱n關(guān)聯(lián)名稱應(yīng)該是一個(gè)動(dòng)詞詞組。n關(guān)聯(lián)名稱應(yīng)放置在關(guān)聯(lián)關(guān)系路徑上或其附近。n在上述關(guān)聯(lián)關(guān)系中，可以將關(guān)系命名為“擁有”或者“申請(qǐng)”等。2022年6月23日星期四第25頁(yè)5.3.1 關(guān)聯(lián)o(2) 關(guān)聯(lián)角色n關(guān)聯(lián)關(guān)系的兩端為角色，角色規(guī)定了類在關(guān)聯(lián)關(guān)系中所起的作用。n每個(gè)角色都必須有名稱，而且對(duì)應(yīng)一個(gè)類的所有角色名稱都必須是唯一的。n角色名稱應(yīng)該是一個(gè)名詞，能夠表達(dá)被關(guān)聯(lián)關(guān)系對(duì)象的角色與關(guān)聯(lián)關(guān)系對(duì)象之間的關(guān)系。角色名稱緊鄰關(guān)聯(lián)關(guān)系線的末端。例如，在“客戶”與“派工單”的關(guān)聯(lián)關(guān)系中，由于是單向關(guān)聯(lián)

13、，所以只需要為箭頭所指向的類命名角色，派工單的合適角色名稱就可以是“派工單”或者“任務(wù)單”。o注意，關(guān)聯(lián)名稱和角色名稱的使用是互斥的：不能同時(shí)使用關(guān)聯(lián)名稱和角色名稱。通常情況下，以命名角色名稱為優(yōu)先。如果沒(méi)有命名角色，則默認(rèn)以類名命名。 2022年6月23日星期四第26頁(yè)5.3.1 關(guān)聯(lián)o(3) 導(dǎo)向性n導(dǎo)向性表示可以通過(guò)關(guān)聯(lián)關(guān)系從關(guān)聯(lián)類導(dǎo)向到目標(biāo)類上。n導(dǎo)向性用一個(gè)開(kāi)箭頭表示，該箭頭置于關(guān)聯(lián)關(guān)系線的目標(biāo)端，緊靠目標(biāo)類（即所導(dǎo)向的類）。n導(dǎo)向性有單向和雙向。2022年6月23日星期四第27頁(yè)5.3.1 關(guān)聯(lián)o(4) 多重性n對(duì)于每個(gè)角色，都可以指定其類的多重性，即該類的多少個(gè)對(duì)象可以與另一個(gè)類

14、的一個(gè)對(duì)象相關(guān)聯(lián)。n多重性由角色上的文本表達(dá)式指出。表達(dá)式是一個(gè)由逗號(hào)隔開(kāi)的整數(shù)范圍列表。一個(gè)整數(shù)范圍由一個(gè)整數(shù)下限、兩個(gè)圓點(diǎn)和一個(gè)整數(shù)上限來(lái)表示。單個(gè)整數(shù)也是有效的范圍，而符號(hào)n或者*表示“許多”，即對(duì)象的數(shù)量不受限制。符號(hào)n本身等價(jià)于0.n，即包括零在內(nèi)的任何數(shù)，這是默認(rèn)值。一個(gè)可選角色的多重性為 0.1。n關(guān)聯(lián)關(guān)系的多重性有三種：一對(duì)一的關(guān)聯(lián)、一對(duì)多的關(guān)聯(lián)和多對(duì)多的關(guān)聯(lián)，如圖5-4所示。 2022年6月23日星期四第28頁(yè)5.3.1 關(guān)聯(lián)n在圖5-3的事例中，“派工單”角色的多重性被標(biāo)識(shí)為0.n表示1個(gè)客戶可以有0個(gè)或者多個(gè)派工單；在“客戶資料”的一端標(biāo)識(shí)為“1”，表示1張派工單屬于1個(gè)

15、客戶。 人車(chē)擁有圖書(shū)館書(shū)*1 1*飛機(jī)飛行員1*1*教師學(xué)生*一對(duì)一的關(guān)聯(lián) 一對(duì)多的關(guān)聯(lián) 多對(duì)一的關(guān)聯(lián) 多對(duì)多的關(guān)聯(lián) 圖5-4 關(guān)聯(lián)關(guān)系的多重性2022年6月23日星期四第29頁(yè)5.3.1 關(guān)聯(lián)o(5) 關(guān)聯(lián)類n關(guān)聯(lián)類是一種關(guān)聯(lián)關(guān)系，它具有類的特征（例如屬性、操作和關(guān)聯(lián)關(guān)系）。n它用一條從關(guān)聯(lián)關(guān)系路徑到類符號(hào)的虛線表示，其中類符號(hào)包含此關(guān)聯(lián)關(guān)系的屬性、操作和關(guān)聯(lián)關(guān)系。這些屬性、操作和關(guān)聯(lián)關(guān)系適用于原始關(guān)聯(lián)關(guān)系本身。n關(guān)聯(lián)關(guān)系中的每個(gè)鏈接都有指定的特征。n關(guān)聯(lián)類最常見(jiàn)的用途是協(xié)調(diào)多對(duì)多關(guān)系。2022年6月23日星期四第30頁(yè)5.3.1 關(guān)聯(lián)o討論：n學(xué)生與課程之間的選課關(guān)系：一個(gè)學(xué)生可以選擇多門(mén)

16、課程，而一門(mén)課程可以被多個(gè)學(xué)生選擇。學(xué)生的成績(jī)?nèi)绾伪硎灸兀?022年6月23日星期四第31頁(yè)5.3.1 關(guān)聯(lián)o關(guān)聯(lián)關(guān)系是非常重要的一種關(guān)系，這里以實(shí)現(xiàn)時(shí)相應(yīng)的Java代碼來(lái)幫助理解關(guān)聯(lián)關(guān)系。在上述的關(guān)聯(lián)關(guān)系中，如果使用代碼實(shí)現(xiàn)，則代碼如下所示。2022年6月23日星期四第32頁(yè)5.3.1 關(guān)聯(lián)o客戶資料類代碼：opublic class CustomerInfooo Long cid;o String name;o o /關(guān)聯(lián)關(guān)系表示一個(gè)客戶可以有關(guān)聯(lián)關(guān)系表示一個(gè)客戶可以有0個(gè)或多個(gè)派工單，個(gè)或多個(gè)派工單，o /聲明一個(gè)派工單類型的數(shù)組，則可以體現(xiàn)這樣一種關(guān)系。聲明一個(gè)派工單類型的數(shù)組，則可以

17、體現(xiàn)這樣一種關(guān)系。 public MissionInfo missioninfo;o public CustomerInfo()o o .o o 派工單類代碼：public class MissionInfo Long mid; String type; public MissionInfo () . 2022年6月23日星期四第33頁(yè)5.3.2 依賴o1. 問(wèn)題引入問(wèn)題引入n在確定關(guān)鍵抽象時(shí)，經(jīng)過(guò)分析知道“維護(hù)人員”的職責(zé)有：接受派工任務(wù)、填寫(xiě)維護(hù)報(bào)告、查詢派工任務(wù)等。根據(jù)此結(jié)果，可以得到“維護(hù)人員”的類定義，如圖5-6所示。該類定義中沒(méi)有定義類的屬性，屬性部分將在后面章節(jié)中介紹。在該類中定

18、義了三個(gè)方法，其中“接受派工任務(wù)”方法的主要功能是將某個(gè)派工任務(wù)進(jìn)行處理，那么該方法必須定義一個(gè)輸入?yún)?shù)，而且該參數(shù)應(yīng)該就是“派工單”類型。那么“維護(hù)人員”類與“派工單”類之間是什么關(guān)系？ 圖5-6 維護(hù)人員類定義 2022年6月23日星期四第34頁(yè)5.3.2 依賴o2. 解答問(wèn)題解答問(wèn)題n該例中兩個(gè)類之間的情況可以總結(jié)為：一個(gè)類是另一個(gè)類的操作的參數(shù)類型。那么它們之間的關(guān)系是依賴關(guān)系。n在UML中依賴關(guān)系是使用虛線箭頭連接兩個(gè)類來(lái)表示，箭頭方向是“維護(hù)人員”指向“派工單”，表示為維護(hù)人員依賴于派工單。如圖5-7所示。 2022年6月23日星期四第35頁(yè)5.3.2 依賴圖5-7 依賴關(guān)系 20

19、22年6月23日星期四第36頁(yè)5.3.2 依賴o3. 分析問(wèn)題分析問(wèn)題n與關(guān)聯(lián)關(guān)系不同，依賴關(guān)系表示兩個(gè)實(shí)例之間的臨時(shí)關(guān)聯(lián)關(guān)系，且本身不生成專門(mén)的實(shí)現(xiàn)代碼。n對(duì)于類而言，依賴關(guān)系可能由各種原因引起，如一個(gè)類向另一個(gè)類發(fā)送消息，或者一個(gè)類是另一個(gè)類的操作的參數(shù)類型等。n依賴關(guān)系不只是局限于表示類之間的關(guān)系，其他建模元素，如用例之間，包之間都可以使用依賴關(guān)系來(lái)表示。2022年6月23日星期四第37頁(yè)5.3.3 泛化泛化o1. 問(wèn)題引入問(wèn)題引入n客戶服務(wù)系統(tǒng)中需要管理的用戶包括客戶服務(wù)人員、維護(hù)人員、部門(mén)領(lǐng)導(dǎo)等，這三類用戶有一個(gè)共同特征就是都屬于系統(tǒng)用戶，都具有用戶ID、姓名、性別等屬性，需要使用U

20、ML將這些用戶類描述出來(lái)。2022年6月23日星期四第38頁(yè)5.3.3 泛化泛化o2. 解答問(wèn)題解答問(wèn)題n客戶服務(wù)人員、維護(hù)人員、部門(mén)領(lǐng)導(dǎo)同屬于系統(tǒng)用戶，都具有用戶ID、姓名、性別等屬性，根據(jù)重用原則，可以創(chuàng)建一個(gè)“系統(tǒng)用戶”類。該類包含了各個(gè)系統(tǒng)用戶的公有特征，客戶服務(wù)人員、維護(hù)人員和部門(mén)領(lǐng)導(dǎo)通過(guò)泛化（繼承）與“系統(tǒng)用戶”類建立聯(lián)系，如下圖5-8所示。n圖中，“系統(tǒng)用戶類”的類名為斜體，表明該類被定義為抽象類。 2022年6月23日星期四第39頁(yè)5.3.3 泛化泛化圖5-8 類之間的泛化關(guān)系 2022年6月23日星期四第40頁(yè)5.3.3 泛化泛化o3. 分析問(wèn)題分析問(wèn)題n泛化關(guān)系是一般元素和

21、具體元素之間的一種分類關(guān)系。具體元素與一般元素完全一致，但包含一些額外的信息。n在實(shí)際生活中，有許多東西都具有共同的特征。例如，狗和貓都是動(dòng)物。n泛化關(guān)系表示一個(gè)類對(duì)另一個(gè)類的繼承。繼承而得的類稱為后代。被繼承的類稱為祖先。繼承意味著祖先的定義對(duì)于后代的對(duì)象也是有效的。n泛化關(guān)系是從后代類到其祖先類的關(guān)系。nUML中用一頭為空心三角形的連線表示泛化關(guān)系。 2022年6月23日星期四第41頁(yè)5.3.4 聚合o1. 問(wèn)題引入問(wèn)題引入n假設(shè)需求中說(shuō)明：客戶來(lái)電咨詢和維護(hù)人員上門(mén)維護(hù)時(shí)都需要進(jìn)行客戶評(píng)價(jià)，包括客戶意見(jiàn)、客戶評(píng)分等屬性。那么需要?jiǎng)?chuàng)建一個(gè)“客戶評(píng)價(jià)”對(duì)象包含在“來(lái)電咨詢”和“派工單”對(duì)象中

22、，請(qǐng)描述“客戶評(píng)價(jià)”類與“來(lái)電咨詢”以及“派工單”類之間的關(guān)系。 2022年6月23日星期四第42頁(yè)5.3.4 聚合o2. 解答問(wèn)題解答問(wèn)題n“客戶評(píng)價(jià)”與“來(lái)電咨詢”以及“派工單”類之間的關(guān)系可以使用關(guān)聯(lián)關(guān)系來(lái)表示，但是在需求描述中有用到“包含”、“組成”等詞語(yǔ)，所以將它們之間的關(guān)系用“聚合”來(lái)表示；n聚合是一種特殊形式的關(guān)聯(lián)。n在UML中，聚合關(guān)系表示為帶空心菱形頭的實(shí)線，如圖5-9所示，空心菱形位于“整體”類的一端。 2022年6月23日星期四第43頁(yè)5.3.4 聚合圖5-9 聚合關(guān)系 2022年6月23日星期四第44頁(yè)5.3.4 聚合o3. 分析問(wèn)題分析問(wèn)題n圖5-9中的“派工單”類和

23、“客戶評(píng)價(jià)”之間是聚合關(guān)系。一個(gè)“派工單”類可以有客戶評(píng)價(jià)和客戶意見(jiàn)這些客戶評(píng)價(jià)方面的屬性，可以用一個(gè)“客戶評(píng)價(jià)”對(duì)象來(lái)表示這些屬性，但同一個(gè)“客戶評(píng)價(jià)”對(duì)象也可以表示別的對(duì)象如“來(lái)電咨詢”的一些客戶評(píng)價(jià)方面的屬性。n“客戶評(píng)價(jià)”對(duì)象也可以用在別的地方，是可以共享的。如果“派工單”這個(gè)對(duì)象不存在了，不一定意味著“客戶評(píng)價(jià)”這個(gè)對(duì)象也不存在了。 2022年6月23日星期四第45頁(yè)5.3.5 組合o1. 問(wèn)題引入問(wèn)題引入n假設(shè)根據(jù)客戶需求，“客戶資料”類包括客戶ID、客戶名稱以及客戶聯(lián)系方式，其中客戶聯(lián)系方式可以單獨(dú)作為一個(gè)類來(lái)描述，那么“客戶資料”類與“客戶聯(lián)系方式”類之間是什么關(guān)系？ 2022

24、年6月23日星期四第46頁(yè)5.3.5 組合o2. 解答問(wèn)題解答問(wèn)題n上節(jié)中，聚合關(guān)系描述的對(duì)象是整體與部分之間的關(guān)系，且兩者具有不同的生命周期。n在這個(gè)例子中，客戶資料對(duì)象與客戶聯(lián)系方式對(duì)象雖然也是整體-部分關(guān)系，但是兩者具有相同的生命周期，即客戶資料不存在了，該客戶資料的客戶聯(lián)系方式也不存在。所以將它們兩者的關(guān)系定義為組合關(guān)系。n組合是一種特殊形式的聚合。nUML中，組合關(guān)系表示為帶有實(shí)心菱形頭的實(shí)線，如圖5-10所示，實(shí)心菱形位于“整體”類的一端。 2022年6月23日星期四第47頁(yè)5.3.5 組合圖5-10 組合關(guān)系 2022年6月23日星期四第48頁(yè)5.3.5 組合o3. 分析問(wèn)題分析

25、問(wèn)題n聚合和組合是類圖中很重要的兩個(gè)概念，但也是比較容易混淆的概念，在實(shí)際應(yīng)用時(shí)往往很難界定究竟是使用聚合關(guān)系還是使用組合關(guān)系。n事實(shí)上，在設(shè)計(jì)類圖時(shí)，設(shè)計(jì)人員根據(jù)需求分析描述的上下文來(lái)確定是使用聚合關(guān)系還是使用組合關(guān)系。對(duì)于同一個(gè)設(shè)計(jì)，可能采用聚合關(guān)系和采用組合關(guān)系都是可以的，不同的只是采用哪種關(guān)系更貼切些。 2022年6月23日星期四第49頁(yè)5.3.5 組合o聚合和組合之間的一些區(qū)別：n聚合關(guān)系也稱為“has a”關(guān)系，組合關(guān)系也稱為“contains a”關(guān)系。n聚合關(guān)系表示事物的整體/部分關(guān)系的較弱的情況，組合關(guān)系表示事物的整體/部分關(guān)系的較強(qiáng)的情況。n在聚合關(guān)系中，代表部分事物的對(duì)象

26、可以屬于多個(gè)聚合對(duì)象，可以為多個(gè)聚合對(duì)象所共享，而且可以隨時(shí)改變它所從屬的聚合對(duì)象。代表部分事物的對(duì)象與代表聚合事物的對(duì)象的生存期無(wú)關(guān)。在組合關(guān)系中，代表整體事物的對(duì)象負(fù)責(zé)創(chuàng)建和刪除代表部分事物的對(duì)象，代表部分事物的對(duì)象只屬于一個(gè)組合對(duì)象。 2022年6月23日星期四第50頁(yè)5.4 建立領(lǐng)域模型o1. 問(wèn)題引入問(wèn)題引入n領(lǐng)域模型表示的是關(guān)鍵抽象之間的關(guān)系，建立領(lǐng)域模型就是發(fā)現(xiàn)系統(tǒng)業(yè)務(wù)實(shí)體的過(guò)程，這將為下一階段的系統(tǒng)分析打好基礎(chǔ)。請(qǐng)使用UML描述客戶服務(wù)系統(tǒng)關(guān)鍵抽象之間的關(guān)系。 2022年6月23日星期四第51頁(yè)5.4 建立領(lǐng)域模型o2. 解答問(wèn)題解答問(wèn)題n在上節(jié)中，我們分析得到關(guān)鍵抽象包括以下

27、內(nèi)容：o客戶服務(wù)人員o維護(hù)人員o部門(mén)領(lǐng)導(dǎo)o軟件產(chǎn)品及項(xiàng)目o咨詢記錄o客戶資料o派工單n領(lǐng)域模型圖如下圖5-11所示。2022年6月23日星期四第52頁(yè)5.4 建立領(lǐng)域模型產(chǎn)品及項(xiàng)目客戶資料10.n10.n來(lái)電咨詢10.n10.n客服人員0.n10.n1記錄經(jīng)驗(yàn)庫(kù)信息0.n10.n添加1部門(mén)領(lǐng)導(dǎo)維護(hù)人員派工單10.n10.n0.n10.n1分派0.n10.n處理1產(chǎn)生擁有產(chǎn)生圖5-11 領(lǐng)域模型 2022年6月23日星期四第53頁(yè)5.4 建立領(lǐng)域模型o3. 分析問(wèn)題分析問(wèn)題n領(lǐng)域模型是對(duì)領(lǐng)域內(nèi)的概念類或現(xiàn)實(shí)世界中對(duì)象的可視化表示。又稱概念模型、領(lǐng)域?qū)ο竽Ｐ?、分析?duì)象模型。它專注于分析問(wèn)題領(lǐng)域本身

28、，發(fā)掘重要的業(yè)務(wù)領(lǐng)域概念，并建立業(yè)務(wù)領(lǐng)域概念之間的關(guān)系。n領(lǐng)域模型設(shè)計(jì)是需求分析的關(guān)鍵步驟。它幫助用戶及需求分析人員建立業(yè)務(wù)概念，確定用戶業(yè)務(wù)的問(wèn)題域，系統(tǒng)涉及的業(yè)務(wù)范圍等等。 2022年6月23日星期四第54頁(yè)5.4 建立領(lǐng)域模型o領(lǐng)域模型設(shè)計(jì)的步驟為：n(1) 從業(yè)務(wù)描述中提取名詞；n(2) 從提取出來(lái)的名詞中總結(jié)業(yè)務(wù)實(shí)體，區(qū)分名詞中的屬性、角色、實(shí)體、實(shí)例，形成問(wèn)題域中操作實(shí)體的集合；n(3) 從業(yè)務(wù)實(shí)體集合中抽象業(yè)務(wù)模型，建立問(wèn)題域的概念；n(4) 用UML提供的方法和圖例進(jìn)行領(lǐng)域模型設(shè)計(jì)、確定模型之間的關(guān)系。 2022年6月23日星期四第55頁(yè)5.5 分布模式的選擇與應(yīng)用o1. 問(wèn)題

29、引入問(wèn)題引入n客戶服務(wù)系統(tǒng)是一個(gè)多用戶的系統(tǒng)，用戶分布范圍廣，在系統(tǒng)性能方面，需求明確規(guī)定系統(tǒng)需要達(dá)到滿足未來(lái)200人同時(shí)使用系統(tǒng)的應(yīng)用規(guī)模；系統(tǒng)維護(hù)目標(biāo)是一旦系統(tǒng)出現(xiàn)BUG、故障或數(shù)據(jù)錯(cuò)誤時(shí)，應(yīng)能及時(shí)而準(zhǔn)確地解決問(wèn)題，保證系統(tǒng)正常、準(zhǔn)確地運(yùn)行。為此，需要為系統(tǒng)選擇一個(gè)正確的分布模式來(lái)滿足用戶需求。2022年6月23日星期四第56頁(yè)5.5 分布模式的選擇與應(yīng)用o2. 解答問(wèn)題解答問(wèn)題n為了滿足系統(tǒng)性能和維護(hù)方面的用戶需求，選擇“胖服務(wù)器”三層分布模式也就是B/S（Browser/Server）三層體系結(jié)構(gòu)，該體系結(jié)構(gòu)的典型的例子是運(yùn)行一組HTML頁(yè)面的 Web 瀏覽器應(yīng)用程序，在客戶機(jī)上幾乎根

30、本沒(méi)有應(yīng)用程序。幾乎所有的工作均發(fā)生在一臺(tái)或多臺(tái) Web 服務(wù)器和數(shù)據(jù)服務(wù)器上。體系結(jié)構(gòu)如圖5-12所示。 2022年6月23日星期四第57頁(yè)5.5 分布模式的選擇與應(yīng)用 瀏覽器 業(yè)務(wù)服務(wù) 數(shù)據(jù)服務(wù) 圖5-12 B/S三層體系結(jié)構(gòu) 2022年6月23日星期四第58頁(yè)5.5 分布模式的選擇與應(yīng)用o3. 分析問(wèn)題分析問(wèn)題n很多情況下系統(tǒng)工作量不能由單處理器處理。太多并行用戶會(huì)超出一個(gè)處理器的支持能力。n系統(tǒng)中存在許多典型的分布模式，它們?nèi)Q于系統(tǒng)的功能和應(yīng)用程序的類型。在許多情況下，一般使用分布模式來(lái)描述系統(tǒng)的“體系結(jié)構(gòu)”。2022年6月23日星期四第59頁(yè)5.5 分布模式的選擇與應(yīng)用o(1) 客

31、戶機(jī)/服務(wù)器體系結(jié)構(gòu)n存在專門(mén)的網(wǎng)絡(luò)處理器節(jié)點(diǎn)，分別稱為客戶機(jī)和服務(wù)器?？蛻魴C(jī)是服務(wù)器提供服務(wù)的使用者?？蛻魴C(jī)通常服務(wù)于單個(gè)用戶，并經(jīng)常處理最終用戶的表示服務(wù)（GUI）；而服務(wù)器通常同時(shí)向數(shù)臺(tái)客戶機(jī)提供服務(wù)，所提供的服務(wù)通常是數(shù)據(jù)庫(kù)服務(wù)、安全性服務(wù)或打印服務(wù)。n在圖5-13中，客戶機(jī) A 顯示了兩層體系結(jié)構(gòu)的示例，大部分應(yīng)用邏輯均位于服務(wù)器中?？蛻魴C(jī) B 顯示了典型的 3 層體系結(jié)構(gòu)，其中業(yè)務(wù)服務(wù)在業(yè)務(wù)對(duì)象服務(wù)器中實(shí)現(xiàn)?？蛻魴C(jī)C 顯示了典型的基于 Web 的應(yīng)用程序。2022年6月23日星期四第60頁(yè)5.5 分布模式的選擇與應(yīng)用圖5-13 客戶機(jī)/服務(wù)器體系結(jié)構(gòu) 2022年6月23日星期四第6

32、1頁(yè)5.5 分布模式的選擇與應(yīng)用o(2) 三層體系結(jié)構(gòu)n是“客戶機(jī)服務(wù)器體系結(jié)構(gòu)”的特例，系統(tǒng)的功能被分成了 3 個(gè)邏輯分區(qū)：應(yīng)用程序服務(wù)、業(yè)務(wù)服務(wù)和數(shù)據(jù)服務(wù)。n應(yīng)用程序服務(wù)主要處理GUI 表示問(wèn)題，它們傾向于在帶有圖形化、窗口化的操作環(huán)境的專用桌面工作站中執(zhí)行。n數(shù)據(jù)服務(wù)傾向于使用數(shù)據(jù)庫(kù)服務(wù)器技術(shù)來(lái)實(shí)現(xiàn)。n業(yè)務(wù)服務(wù)反映業(yè)務(wù)流程的具體編碼。它們處理并合成從數(shù)據(jù)服務(wù)獲取的信息，并提供給應(yīng)用程序服務(wù)。 2022年6月23日星期四第62頁(yè)5.5 分布模式的選擇與應(yīng)用o(3) 胖客戶機(jī)體系結(jié)構(gòu)n應(yīng)用程序服務(wù)、業(yè)務(wù)服務(wù)和數(shù)據(jù)服務(wù)均駐留在客戶機(jī)上，數(shù)據(jù)庫(kù)服務(wù)器通常位于另一臺(tái)機(jī)器上。n“胖客戶機(jī)”的設(shè)計(jì)和構(gòu)

33、建相對(duì)簡(jiǎn)單，但卻比較難以分布和維護(hù)。 2022年6月23日星期四第63頁(yè)5.5 分布模式的選擇與應(yīng)用o(4) 胖服務(wù)器體系結(jié)構(gòu)胖服務(wù)器體系結(jié)構(gòu)n與“胖客戶機(jī)”截然不同的另一面是“胖服務(wù)器”或“瘦客戶機(jī)”。這種結(jié)構(gòu)易于分布，易于變更。開(kāi)發(fā)和支持它們的代價(jià)相對(duì)較低。 2022年6月23日星期四第64頁(yè)5.6 構(gòu)建分析類o1. 問(wèn)題引入問(wèn)題引入n我們已經(jīng)得出客戶服務(wù)系統(tǒng)的需求模型（包括用例圖、用例描述等），以及整個(gè)系統(tǒng)的領(lǐng)域模型和分布模式。而接下來(lái)就是需要對(duì)用例進(jìn)行分析，使用用例驅(qū)動(dòng)的方法，得出系統(tǒng)的分析模型。具體的說(shuō)，就是為系統(tǒng)中的每個(gè)用例，實(shí)現(xiàn)與它們綁定的類圖、順序圖和協(xié)作圖，從而為設(shè)計(jì)模型的實(shí)

34、現(xiàn)作好準(zhǔn)備。現(xiàn)在需要對(duì)“維護(hù)客戶資料”用例進(jìn)行分析，構(gòu)建分析類，得出該用例的分析模型。 2022年6月23日星期四第65頁(yè)5.6 構(gòu)建分析類o2. 解答問(wèn)題解答問(wèn)題n系統(tǒng)往往在三個(gè)維度易于發(fā)生變化：o第一，系統(tǒng)與外部要素之間交互的邊界；o第二，系統(tǒng)要記錄和維護(hù)的信息；o第三，系統(tǒng)在運(yùn)行中的控制邏輯。n通常按照這三個(gè)變化將分析類劃分為三種類型：邊界類、控制類和實(shí)體類，在UML中分別用構(gòu)造型、 來(lái)表示。n分析客戶資料維護(hù)用例，我們得到以下分析類。 2022年6月23日星期四第66頁(yè)5.6 構(gòu)建分析類o(1) 邊界類n代表了整個(gè)系統(tǒng)與外部的接口。這包括硬件接口和軟件接口。在客戶服務(wù)系統(tǒng)中，包括了用戶

35、和管理員使用客戶服務(wù)系統(tǒng)的圖形用戶界面接口。而在維護(hù)客戶資料用例中，只有客戶服務(wù)人員會(huì)與系統(tǒng)發(fā)生交互，在分析模型的構(gòu)造中，它是獨(dú)立于設(shè)計(jì)模型和最后實(shí)現(xiàn)的。故而，在此使用 CustomerInfoForm 類來(lái)抽象客戶服務(wù)人員與系統(tǒng)交互的圖形界面或者瀏覽器頁(yè)面。 2022年6月23日星期四第67頁(yè)5.6 構(gòu)建分析類o(2) 控制類n代表了一個(gè)特定用例的控制器。一般來(lái)說(shuō)，在分析模型階段，由這個(gè)控制類實(shí)現(xiàn)與它綁定的用例所有的業(yè)務(wù)邏輯控制，如果業(yè)務(wù)邏輯過(guò)于復(fù)雜，在構(gòu)建分析模型的后期或者構(gòu)建設(shè)計(jì)模型的前期可以將其分化為多個(gè)控制類。在此用例中，CustomerInfoController 就被賦予控制類的

36、職責(zé)。 2022年6月23日星期四第68頁(yè)5.6 構(gòu)建分析類o(3) 實(shí)體類n代表了系統(tǒng)中各個(gè)模塊之間流動(dòng)數(shù)據(jù)信息的抽象。每一個(gè)實(shí)體類的實(shí)例都代表和抽象了一個(gè)實(shí)物的存在。根據(jù)用例分析，客戶服務(wù)人員在維護(hù)客戶資料時(shí)要接觸的實(shí)體是“客戶資料”。所以，我們?cè)谙到y(tǒng)中設(shè)計(jì)了CustomerInfo實(shí)體類對(duì)應(yīng)該實(shí)體。 2022年6月23日星期四第69頁(yè)5.6 構(gòu)建分析類o除了發(fā)掘出用例中所有的邊界類、控制類和實(shí)體類后，還必須得出它們之間的關(guān)系。比如 CustomerInfoController控制類和 CustomerInfoForm邊界類之間為一對(duì)一關(guān)系，因?yàn)橛脩羰褂玫慕缑嬷挥幸粋€(gè)，而控制類也只需一個(gè)；

37、然而，控制類與 CustomerInfo實(shí)體類的關(guān)系則是 0.1 對(duì) 0.n ，因?yàn)?，同一個(gè)控制類可能要同時(shí)處理不同的客戶資料。分析模型如下圖5-14所示。 2022年6月23日星期四第70頁(yè)5.6 構(gòu)建分析類CustomerInfoFormCustomerInfoController11CustomerInfo0.n0.1110.n0.1圖5-14 分析模型2022年6月23日星期四第71頁(yè)5.6 構(gòu)建分析類o3. 分析問(wèn)題分析問(wèn)題n分析類是概念層面的內(nèi)容，與應(yīng)用邏輯直接相關(guān)。n分析類直接針對(duì)軟件的功能需求，因而分析類的行為來(lái)自于對(duì)軟件功能需求的描述（用例的內(nèi)容）。n分析類分為三種類型：邊界

38、類、控制類和實(shí)體類。 2022年6月23日星期四第72頁(yè)5.6 構(gòu)建分析類o(1) 邊界類n邊界類提供了對(duì)參與者或外部系統(tǒng)交互協(xié)議的接口。邊界類將系統(tǒng)和外界的變化隔離開(kāi)來(lái)。n一個(gè)系統(tǒng)可能會(huì)有多種邊界類：o用戶界面類：幫助與系統(tǒng)用戶進(jìn)行通信的類。o系統(tǒng)接口類：幫助與其他系統(tǒng)進(jìn)行通信的類。o設(shè)備接口類：為監(jiān)測(cè)外部事件的設(shè)備（如傳感器）提供接口的類。 2022年6月23日星期四第73頁(yè)5.6 構(gòu)建分析類o對(duì)邊界類初步的確定是為每對(duì)參與者/用例確定一個(gè)邊界類，可以認(rèn)為此對(duì)象擔(dān)負(fù)著協(xié)調(diào)與參與者之間交互的職責(zé)。這對(duì)于基于窗口的 GUI 應(yīng)用程序來(lái)說(shuō)更是如此。在這些應(yīng)用程序中，通常每個(gè)窗口或?qū)υ捒蚨紝?duì)應(yīng)一個(gè)

39、邊界類。圖5-15顯示了“維護(hù)客戶資料”用例的邊界類。 2022年6月23日星期四第74頁(yè)5.6 構(gòu)建分析類oCustomerInfoForm邊界對(duì)象包含客戶資料列表。它會(huì)顯示當(dāng)前客戶資料供客戶服務(wù)人員選擇。 客服人員維護(hù)客戶信息CustomerInfoForm對(duì)應(yīng)邊界類 圖5-15用例對(duì)應(yīng)的邊界類及邊界類的兩種UML表示形式 2022年6月23日星期四第75頁(yè)5.6 構(gòu)建分析類o(2) 控制類n控制類用于封裝一個(gè)或幾個(gè)用例特有的行為。n控制類增強(qiáng)了系統(tǒng)的可理解性，因?yàn)樗鼈兘⒘讼到y(tǒng)的動(dòng)態(tài)行為模型。n一些復(fù)雜的用例可能需要多個(gè)控制類來(lái)協(xié)調(diào)其它對(duì)象的行為?？刂祁愑行У胤蛛x了邊界對(duì)象和實(shí)體對(duì)象，使

40、系統(tǒng)更能承受系統(tǒng)邊界的變更。n但是邊界類和實(shí)體類之間并非始終需要一個(gè)控制類。當(dāng)事件流比較復(fù)雜并具有可以獨(dú)立于系統(tǒng)的接口（邊界類）或者信息存儲(chǔ)（實(shí)體類）的動(dòng)態(tài)行為時(shí)，有必要使用一個(gè)控制類。n控制類的例子包括事務(wù)管理器、資源協(xié)調(diào)器和錯(cuò)誤處理器。 2022年6月23日星期四第76頁(yè)5.6 構(gòu)建分析類o對(duì)于控制類，推薦的方法是為每個(gè)用例設(shè)置一個(gè)控制類。隨著分析的發(fā)展可能會(huì)變?yōu)槎鄠€(gè)控制類。每個(gè)控制類負(fù)責(zé)控制對(duì)相關(guān)用例所描述的功能實(shí)現(xiàn)的處理。圖5-16顯示了“維護(hù)客戶信息”用例的控制類。 CustomerInfoControllerCustomerInfoController圖5-16 控制類的兩種UML

41、表現(xiàn)形式 2022年6月23日星期四第77頁(yè)5.6 構(gòu)建分析類o(3) 實(shí)體類n實(shí)體類是用于對(duì)必須存儲(chǔ)的信息和相關(guān)行為建模的類，它們的主要職責(zé)是存儲(chǔ)和管理系統(tǒng)中的信息。n實(shí)體類通常都是持久性的，它們所具有的屬性和關(guān)系是長(zhǎng)期需要的，有時(shí)甚至在系統(tǒng)的整個(gè)生存期都需要。 2022年6月23日星期四第78頁(yè)5.6 構(gòu)建分析類o對(duì)于實(shí)體類，可以參考關(guān)鍵抽象集合，在當(dāng)前用例的文字描述中挖掘必要的實(shí)體信息。o如果需求中的某一實(shí)體信息有可能被多個(gè)類引用，或者該實(shí)體信息具有明顯的行為特征，通常將其建模為一個(gè)獨(dú)立的實(shí)體類。圖5-17顯示了“維護(hù)客戶信息”用例的實(shí)體類CustomerInfo。 2022年6月23日

42、星期四第79頁(yè)5.6 構(gòu)建分析類CustomerInfoCustomerInfo圖5-17 實(shí)體類的兩種UML表現(xiàn)形式 2022年6月23日星期四第80頁(yè)5.7 交互圖o類圖表示了一個(gè)系統(tǒng)的靜態(tài)結(jié)構(gòu)，而系統(tǒng)既有靜態(tài)方面也有動(dòng)態(tài)方面，動(dòng)態(tài)方面可以通過(guò)考慮對(duì)象之間的交互來(lái)實(shí)現(xiàn)。oUML中，可以用交互圖來(lái)對(duì)一個(gè)系統(tǒng)的動(dòng)態(tài)行為建模。o交互圖有兩種：順序圖和協(xié)作圖。這兩種圖展示了對(duì)象以及它們執(zhí)行腳本時(shí)交換的信息。 2022年6月23日星期四第81頁(yè)5.7 交互圖o5.7.1 順序圖o5.7.2 協(xié)作圖2022年6月23日星期四第82頁(yè)5.7.1 順序圖o1. 問(wèn)題引入問(wèn)題引入n分析類的確定使得我們?cè)谙到y(tǒng)

43、分析階段又更進(jìn)了一步，但是這僅僅能夠描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，我們還需要了解在各個(gè)用例中這些類是如何交互的。請(qǐng)根據(jù)“維護(hù)客戶信息”用例的說(shuō)明，描述分析類在修改客戶資料功能中的交互過(guò)程。 2022年6月23日星期四第83頁(yè)5.7.1 順序圖o2. 解答問(wèn)題解答問(wèn)題n根據(jù)已經(jīng)繪制的“維護(hù)客戶信息”用例的分析類圖，可以采用順序圖來(lái)反映類之間的交互過(guò)程。n順序圖主要反映了系統(tǒng)中各個(gè)類，模塊或者角色之間，交互方法的先后調(diào)用次序，強(qiáng)調(diào)的是時(shí)間的先后關(guān)系。n使用 Rational Rose 繪制的“維護(hù)客戶信息”用例的修改功能順序圖如圖5-18所示。2022年6月23日星期四第84頁(yè) : 客服人員 : Custo

44、merInfoForm : CustomerInfoController : CustomerInfo1: getAllCustomerInfo( )2: getAllCustomerInfo( )3: getAllCustomerInfo( )4: displayAllCustomerInfo( )5: selectCustomer( )6: getCustomerInfo( )7: getCustomerInfo( )8: displayCustomerInfo( )9: updateCustomerInfo( )11: updateCustomerInfo( )12: updateCus

45、tomerInfo( )10: verifyCustomerInfo( )13: getAllCustomerInfo( )14: displayAllCustomerInfo( )圖5-18 順序圖 2022年6月23日星期四第85頁(yè)5.7.1 順序圖o其他功能，如查詢、新增、刪除等可以參照這個(gè)順序圖完成。2022年6月23日星期四第86頁(yè)5.7.1 順序圖o3. 分析問(wèn)題分析問(wèn)題n從修改客戶資料的順序圖中可以看出，整個(gè)修改過(guò)程的業(yè)務(wù)流程是：首先，由客服人員通過(guò)用戶界面向 CustomerInfoController 控制類發(fā)出獲取所有客戶資料的請(qǐng)求，CustomerInfoControll

46、er 類通過(guò)CustomerInfo 實(shí)體類獲取數(shù)據(jù)顯示在CustomerInfoForm邊界類中，然后客服人員選擇一個(gè)需要修改的客戶，CustomerInfoForm邊界類向CustomerInfoController控制類發(fā)送獲取特定客戶資料的請(qǐng)求，CustomerInfoController 類通過(guò)CustomerInfo 實(shí)體類獲取特定客戶數(shù)據(jù)顯示在邊界類中，客戶修改數(shù)據(jù)，然后確定更新，CustomerInfoForm 邊界類向CustomerInfoController 控制類發(fā)送更新數(shù)據(jù)的請(qǐng)求，CustomerInfoController 類通過(guò)CustomerInfo 實(shí)體類更新

47、數(shù)據(jù)，然后CustomerInfoController 類通過(guò)CustomerInfo 實(shí)體類重新獲得所有客戶資料顯示在邊界類中，完成整個(gè)更新過(guò)程。2022年6月23日星期四第87頁(yè)5.7.1 順序圖o在順序圖中可以按照任意的順序放置對(duì)象，它們?cè)谒椒较蛏系奈恢貌粫?huì)影響圖表的語(yǔ)意，但是消息的順序?qū)?huì)影響理解順序圖的難易程度。o在順序圖中放置對(duì)象的一般方法是：按對(duì)象由高到低的活躍程度在順序圖中從左到右放置。通過(guò)安排對(duì)象的順序可以使順序圖更易于理解，同時(shí)，也使得大多數(shù)消息能從左到右流動(dòng)。2022年6月23日星期四第88頁(yè)5.7.1 順序圖n順序圖中的對(duì)象是匿名對(duì)象，但也可以為其命名。匿名對(duì)象具有類

48、的名稱，但是沒(méi)有對(duì)象名稱。它們被用來(lái)表示一個(gè)類里的許多潛在對(duì)象，或者這個(gè)個(gè)體對(duì)象的名稱是未知的，或者這個(gè)名稱對(duì)于理解順序圖是無(wú)關(guān)緊要的。匿名對(duì)象的表示方法：類名加下劃線，并在類名前加冒號(hào)。圖5-18中的所有對(duì)象都是匿名對(duì)象。n順序圖中的時(shí)間流用從每個(gè)對(duì)象發(fā)出的垂直虛線來(lái)表示，這些虛線稱為對(duì)象的生命線。對(duì)象生命線也稱為時(shí)間線，它們表示的是在交互中一個(gè)對(duì)象的生命周期。在對(duì)象之間，用水平箭頭表示從一個(gè)對(duì)象生命線到另一個(gè)對(duì)象生命線所傳遞的基本消息。發(fā)送消息的對(duì)象稱為客戶，將請(qǐng)求服務(wù)。接收消息的對(duì)象稱為供應(yīng)者，為客戶對(duì)象提供服務(wù)。消息箭頭通常從客戶指向供應(yīng)者。一個(gè)對(duì)象也可以把消息發(fā)給自己，稱為自身委托，

49、如圖5-18中的消息verifyCustomerInfo即為自身委托。 2022年6月23日星期四第89頁(yè)5.7.1 順序圖o在UML中，可以表示三種消息：簡(jiǎn)單消息、同步消息和異步消息。n同步消息通常作為一個(gè)操作調(diào)用在兩個(gè)對(duì)象之間的同一個(gè)線程中被執(zhí)行。n異步消息表示的是發(fā)送消息的對(duì)象在它自己的線程內(nèi)保持控制焦點(diǎn)，接收消息的對(duì)象在它自己的線程里處理消息，調(diào)用操作不會(huì)在消息處理之后收到一個(gè)直接的回復(fù)。n異步消息通常用在實(shí)時(shí)系統(tǒng)中。 2022年6月23日星期四第90頁(yè)5.7.2 協(xié)作圖o1. 問(wèn)題引入問(wèn)題引入n順序圖強(qiáng)調(diào)的是交互的時(shí)間先后關(guān)系，很難從中看出分析類之間的協(xié)作情況，請(qǐng)以另一種描述方式來(lái)更

50、好地表達(dá)分析類之間的協(xié)作問(wèn)題。 2022年6月23日星期四第91頁(yè)5.7.2 協(xié)作圖o2. 解答問(wèn)題解答問(wèn)題n與順序圖不同，協(xié)作圖主要強(qiáng)調(diào)了各個(gè)類或者模塊之間的協(xié)作關(guān)系。n根據(jù)已經(jīng)繪制的修改客戶資料的順序圖，使用 Rational Rose 繪制的修改客戶資料用例的協(xié)作圖如圖5-19（可以不用手動(dòng)繪制，使用快捷鍵F5可以直接生成與順序圖相對(duì)應(yīng)的協(xié)作圖）所示。 2022年6月23日星期四第92頁(yè) : 客服人員 : CustomerInfoForm : CustomerInfoController : CustomerInfo1: getAllCustomerInfo( )2: getAllCus

51、tomerInfo( )4: displayAllCustomerInfo( )5: selectCustomer( )6: getCustomerInfo( )8: displayCustomerInfo( )9: updateCustomerInfo( )10: verifyCustomerInfo( )11: updateCustomerInfo( )14: displayAllCustomerInfo( )3: getAllCustomerInfo( )7: getCustomerInfo( )12: updateCustomerInfo( )13: getAllCustomerInf

52、o( )圖5-19 協(xié)作圖 2022年6月23日星期四第93頁(yè)5.7.2 協(xié)作圖o3. 分析問(wèn)題分析問(wèn)題n與順序圖一樣，協(xié)作圖也屬于交互圖的一種。n從協(xié)作圖中，我們更容易看出系統(tǒng)中的一個(gè)類或模塊，在整個(gè)系統(tǒng)中參與業(yè)務(wù)流程的多少。n雖然協(xié)作圖和順序圖反映的信息是一樣的，但是協(xié)作圖顯示了不同的流視圖，更容易看出對(duì)象之間的關(guān)系，但對(duì)象之間發(fā)送消息的順序關(guān)系則不夠明顯，需要用編號(hào)來(lái)表示消息的順序。 2022年6月23日星期四第94頁(yè)5.8 職責(zé)分配o1. 問(wèn)題引入問(wèn)題引入n用例分析的目的是用面向?qū)ο蟮姆椒ㄞD(zhuǎn)述需求中的應(yīng)用邏輯。在查找分析類中找出了用于轉(zhuǎn)述需求的分析元素。用面向?qū)ο蟮姆椒ㄞD(zhuǎn)述用例中的內(nèi)容

53、，就是用分布在一組分析類中的職責(zé)分擔(dān)用例所要求的行為。對(duì)于客戶服務(wù)人員維護(hù)客戶資料用例，所涉及的分析類已經(jīng)明確。根據(jù)消息與職責(zé)的關(guān)系，請(qǐng)確定對(duì)于修改客戶資料功能而言每個(gè)類的職責(zé)。 2022年6月23日星期四第95頁(yè)5.8 職責(zé)分配o2. 解答問(wèn)題解答問(wèn)題n根據(jù)“消息”和“職責(zé)”的對(duì)應(yīng)關(guān)系，依據(jù)順序圖，可以確認(rèn)在分析類中的職責(zé)。如圖5-20所示。2022年6月23日星期四第96頁(yè)5.8 職責(zé)分配圖5-20 分析類 2022年6月23日星期四第97頁(yè)5.8 職責(zé)分配o3. 分析問(wèn)題分析問(wèn)題n描述分析類實(shí)例之間的消息傳遞過(guò)程就是將這些職責(zé)指派到分析類的過(guò)程。這個(gè)過(guò)程是從軟件需求過(guò)渡到設(shè)計(jì)內(nèi)容的關(guān)鍵環(huán)

54、節(jié)，其中的核心概念是“消息”和“職責(zé)”的對(duì)應(yīng)關(guān)系。n消息的發(fā)出者要求消息的接受者通過(guò)承擔(dān)相應(yīng)的職責(zé)作為對(duì)消息發(fā)出者的回應(yīng)。n一個(gè)分析類的實(shí)例在事件序列中接受的消息集合是該分析類應(yīng)承擔(dān)責(zé)任的依據(jù)。 2022年6月23日星期四第98頁(yè)5.8 職責(zé)分配n消息在概念上具有顯著的動(dòng)態(tài)特征，和分析類的實(shí)例相關(guān)聯(lián)；而職責(zé)在概念上具有顯著的靜態(tài)特征，和分析類的定義相關(guān)聯(lián)。n消息在客觀上是有次序的，但職責(zé)并沒(méi)有次序的概念。一種類型的職責(zé)往往能夠響應(yīng)多種消息。n職責(zé)是從交互圖提供的消息中得到的。對(duì)每一條消息，檢查接收它的對(duì)象所屬的類。如果職責(zé)尚不存在，則創(chuàng)建一個(gè)新的職責(zé)以便提供需要的行為。n職責(zé)大多沿用消息的名稱

55、，如圖5-21所示。2022年6月23日星期四第99頁(yè)5.8 職責(zé)分配 : Client : Suppiler/PerformResponsibility Suppiler/PerformResponsibility() 交互圖 類圖 圖5-21 從消息到類職責(zé)的映射 2022年6月23日星期四第100頁(yè)5.8 職責(zé)分配o在Rational Rose的順序圖中，右擊消息線，在彈出的快捷菜單中選擇，如圖5-22所示。然后定義職責(zé)名稱，如：selectCustomerInfo()。2022年6月23日星期四第101頁(yè)圖5-22 定義職責(zé) 2022年6月23日星期四第102頁(yè)5.8 職責(zé)分配n消息與

56、職責(zé)并不是一回事。n類圖與交互圖直接相關(guān)聯(lián)。當(dāng)在順序圖或協(xié)作圖中為消息定義了一項(xiàng)職責(zé)，在類圖中相應(yīng)地就為消息的接收對(duì)象所對(duì)應(yīng)的類添加了一項(xiàng)操作，如圖5-23所示。 2022年6月23日星期四第103頁(yè)5.8 職責(zé)分配圖5-23 在順序圖中為對(duì)象分配職責(zé)后的類圖 2022年6月23日星期四第104頁(yè)5.9 定義類的屬性o1. 問(wèn)題引入問(wèn)題引入n對(duì)象包含了狀態(tài)和職責(zé)（對(duì)應(yīng)于類的屬性和操作），在上一節(jié)中我們已經(jīng)為對(duì)象分配了職責(zé)，也即是定義了類的操作，本節(jié)將討論類的屬性如何定義。在一個(gè)類中屬性描述了類的對(duì)象所包含的數(shù)據(jù)。屬性沒(méi)有唯一性。多個(gè)不同的對(duì)象可以具有相同的屬性。例如，客戶服務(wù)系統(tǒng)中所有的客戶對(duì)

57、象都有姓名和聯(lián)系電話屬性。所有的屬性都有值，稱為“屬性值”，也就是對(duì)象所包含的數(shù)據(jù)。一個(gè)類中所有對(duì)象有相同的屬性名，但這些屬性所包含的值可以不同。例如，客戶服務(wù)系統(tǒng)中所有的客戶對(duì)象都有name（姓名）屬性，但不同的客戶有不同的名字。我們?nèi)绾蝸?lái)發(fā)現(xiàn)一個(gè)類的屬性呢？ 2022年6月23日星期四第105頁(yè)5.9 定義類的屬性o2. 解答問(wèn)題解答問(wèn)題n要發(fā)現(xiàn)類的屬性，可以使用：o用例描述o確定關(guān)鍵抽象時(shí)所排除的名詞o問(wèn)題描述n如：“客戶資料”類的屬性可定義為如圖5-24所示。 2022年6月23日星期四第106頁(yè)5.9 定義類的屬性圖5-24 “客戶資料”類的屬性 2022年6月23日星期四第107頁(yè)

58、5.9 定義類的屬性o3. 分析問(wèn)題分析問(wèn)題n首先我們可以從用例描述的事件流中發(fā)現(xiàn)屬性。如“維護(hù)客戶資料”用例的主事件流： 2022年6月23日星期四第108頁(yè)5.9 定義類的屬性1、Actor選擇“維護(hù)客戶資料”功能啟動(dòng)該用例；2、系統(tǒng)顯示維護(hù)客戶資料的主界面，其中列出查詢界面；3、Actor選擇新增客戶資料；4、系統(tǒng)提示錄入客戶資料；5、Actor輸入客戶編號(hào)、來(lái)源（售后、培訓(xùn)、電話咨詢、關(guān)系客戶）、類型（代理商、終端客戶、關(guān)系客戶）、省份、公司名稱、聯(lián)系人，聯(lián)系電話、EMAIL、登記時(shí)間、地址、郵編等。輸入完成后提交這些信息；6、系統(tǒng)驗(yàn)證輸入數(shù)據(jù)是否正確； 如驗(yàn)證不正確則提示用戶重輸入；

59、如檢驗(yàn)正確則增加這個(gè)客戶信息，并返回到客戶資料維護(hù)主界面；7、Actor選擇退出，該用例結(jié)束。2022年6月23日星期四第109頁(yè)5.9 定義類的屬性o從主事件流的第5步我們可以發(fā)現(xiàn)“客戶資料”類的屬性有：客戶編號(hào)、來(lái)源、類型、省份、公司名稱、聯(lián)系人、聯(lián)系電話、EMAIL、登記時(shí)間、地址、郵編。 2022年6月23日星期四第110頁(yè)5.9 定義類的屬性o也可從問(wèn)題描述文檔發(fā)現(xiàn)屬性。o在問(wèn)題描述和用例描述事件流中包含了許多代表問(wèn)題域的名詞。但在確定關(guān)鍵抽象時(shí)對(duì)這些名詞進(jìn)行分析后，會(huì)發(fā)現(xiàn)其中一些名詞并不代表可行的類，而是代表類的屬性，如在確定關(guān)鍵抽象時(shí)找出來(lái)的名詞“處理結(jié)果”就不是一個(gè)可行的類，而是“派工單”類的屬性。o