1、第四講：面向?qū)ο蟮能浖O(shè)計(jì)方法,董威，文艷軍，陳振邦 國防科技大學(xué)計(jì)算機(jī)學(xué)院,軟件設(shè)計(jì)與體系結(jié)構(gòu),2,內(nèi)容,4.1基于UML的分析與設(shè)計(jì)過程 4.2用例分析與設(shè)計(jì) 4.3概念模型和頂層架構(gòu)設(shè)計(jì) 4.4用戶界面設(shè)計(jì) 4.5數(shù)據(jù)模型設(shè)計(jì) 4.6設(shè)計(jì)精化 4.7類設(shè)計(jì) 4.8部署模型設(shè)計(jì),3,基于UML的分析與設(shè)計(jì),UML是獨(dú)立于軟件開發(fā)過程的，它幾乎可以用于任何類型的軟件開發(fā)過程，包括瀑布式、迭代式、螺旋式等不同模型。 在軟件分析和設(shè)計(jì)中，可以根據(jù)項(xiàng)目的特征、開發(fā)組織在已有實(shí)踐中定義的相關(guān)規(guī)范、設(shè)計(jì)人員本身的偏好等因素，對基于UML的軟件設(shè)計(jì)過程進(jìn)行定制。,4,基于UML的分析與設(shè)計(jì)過程,5,內(nèi)容

2、,4.1基于UML的分析與設(shè)計(jì)過程 4.2用例分析與設(shè)計(jì) 4.3概念模型和頂層架構(gòu)設(shè)計(jì) 4.4用戶界面設(shè)計(jì) 4.5數(shù)據(jù)模型設(shè)計(jì) 4.6設(shè)計(jì)精化 4.7類設(shè)計(jì) 4.8部署模型設(shè)計(jì),6,案例：銀行ATM自動(dòng)柜員機(jī)的需求簡述,本案例將要開發(fā)的ATM系統(tǒng)能夠?yàn)轭櫩吞峁┮韵禄痉?wù)（它們統(tǒng)一稱為交易）： 取款服務(wù)。顧客可以用銀行卡從對應(yīng)的賬戶中支取現(xiàn)金，現(xiàn)金必須是100元的整數(shù)倍，且每次取款不能超過2000元。 存款服務(wù)。顧客可以把現(xiàn)金存入與銀行卡對應(yīng)的賬戶中。 轉(zhuǎn)帳服務(wù)。顧客可以把一個(gè)銀行卡對應(yīng)的賬戶中的款項(xiàng)轉(zhuǎn)帳到另一個(gè)銀行賬戶中。 查詢服務(wù)。顧客能夠查詢一個(gè)銀行卡對應(yīng)的賬戶中的余額。,7,（1）確定

3、用例,采用用例模型描述系統(tǒng)需求時(shí)，首先需要開發(fā)人員從業(yè)務(wù)需求描述出發(fā)獲取參與者（Actor）和場景，對場景進(jìn)行匯總、分類、抽象，形成用例。 場景是從單個(gè)參與者的角度觀察目標(biāo)軟件系統(tǒng)的功能和外部行為，這種功能通過系統(tǒng)與用戶之間的交互來表示。 場景是用例的實(shí)例，而用例是某類場景的共同抽象。,8,獲取場景,目標(biāo)軟件系統(tǒng)有哪些參與者？ 參與者希望系統(tǒng)執(zhí)行的任務(wù)有哪些？ 參與者希望獲得哪些信息？這些信息由誰生成？由誰修改？ 參與者需要通知系統(tǒng)哪些事件？系統(tǒng)響應(yīng)這些事件時(shí)會表現(xiàn)出哪些外部行為？ 系統(tǒng)將通告參與者哪些事件？,9,定義用例,在場景確定之后，通過對場景的匯總、分類歸并、抽象即可形成用例。 需要特

4、別注意的是，參與者并只限于人員，其它與目標(biāo)軟件發(fā)生交互的外部實(shí)體或系統(tǒng)也是參與者；用例應(yīng)該是對參與者可見的系統(tǒng)需求或功能，否則不能作為用例。,10,ATM案例的參與者,“顧客”（Customer） “操作管理人員”（Operator） “銀行服務(wù)器”（Bank System） “讀卡器”（Card Reader） “存款器”（Cash Acceptor） “取款器”（Cash Dispenser） “打印機(jī)”（Printer）,11,ATM案例的用例,“取款”（Withdrawal） “存款”（Deposit） “轉(zhuǎn)帳”（Transfer） “查詢余額”（Inquiry） “開機(jī)”（Syste

5、m Startup） “關(guān)機(jī)”（System Shutdown）,12,（2）生成用例圖,生成用例圖是一個(gè)逐步精化的過程，首先可以建立初步的用例圖，包括前面發(fā)現(xiàn)的參與者和用例； 然后對用例圖進(jìn)行細(xì)化，定義用例之間“包含”、“擴(kuò)展”、“繼承”等關(guān)系，并可能需要定義新的用例，以能夠更準(zhǔn)確地使用用例圖描述系統(tǒng)需求。,13,生成初步用例圖,14,用例圖的細(xì)化,包含（include）關(guān)系 擴(kuò)展（extend）關(guān)系 繼承關(guān)系,15,細(xì)化后ATM用例圖,16,（3）用例描述,對用例的完整描述包括用例名稱、參與者、前置條件、一個(gè)主事件流、0到多個(gè)輔事件流、后置條件。 主事件流表示正常情況下參與者與系統(tǒng)之間的信

6、息交互及動(dòng)作序列， 輔事件流則表示特殊情況或異常情況下的信息交互及動(dòng)作序列。,17,“取款用例”描述,用例名稱：Withdrawal 參與者：Customer，Bank System，Card Reader，Cash Dispenser，Printer 前置條件：顧客已插入銀行卡，密碼驗(yàn)證正確，顧客按下“取款”按鈕 主事件流： 顧客輸入取款金額，并確認(rèn)。 系統(tǒng)認(rèn)可取款金額，并發(fā)送指令給取款器。 取款器把相應(yīng)金額的現(xiàn)金送出。 打印機(jī)打印回執(zhí)。 輔事件流： 如果取款金額不是100的整數(shù)倍，則顯示信息“輸入金額必須是100的整數(shù)倍，請重新輸入”，并返回主事件流中步驟（1）。 如果取款金額超過2000

7、元，則顯示信息“輸入金額不能超過2000元，請重新輸入” ，并返回主事件流中步驟（1）。 如果賬戶余額小于取款金額，則顯示信息“賬戶余額不足，請重新輸入” ，并返回主事件流中步驟（1）。 顧客在確認(rèn)取款金額前可以選擇取消交易。 后置條件：如果取款成功，系統(tǒng)從賬戶余額中減去相應(yīng)數(shù)額，并返回等待狀態(tài)；如果顧客取消交易，則返回等待狀態(tài)。,18,用順序圖描述用例,19,內(nèi)容,4.1基于UML的分析與設(shè)計(jì)過程 4.2用例分析與設(shè)計(jì) 4.3概念模型和頂層架構(gòu)設(shè)計(jì) 4.4用戶界面設(shè)計(jì) 4.5數(shù)據(jù)模型設(shè)計(jì) 4.6設(shè)計(jì)精化 4.7類設(shè)計(jì) 4.8部署模型設(shè)計(jì),20,（1）概念模型設(shè)計(jì),在用戶需求和相關(guān)的業(yè)務(wù)領(lǐng)域中

8、，往往有一些全局性的概念對于理解需求至關(guān)重要，因此，有必要抽取這些概念，研究這些概念之間的關(guān)系。 UML類圖非常適合用來建立領(lǐng)域概念模型，描述在問題域中存在哪些主要概念和對象，并表示出它們之間的關(guān)系，例如關(guān)聯(lián)、聚集、繼承等。 為建立以UML類圖表示的領(lǐng)域概念模型，首先必須標(biāo)識關(guān)鍵概念。,21,關(guān)鍵概念的來源,（1）業(yè)務(wù)需求描述、用例說明； （2）業(yè)務(wù)領(lǐng)域中的相關(guān)規(guī)范、標(biāo)準(zhǔn)、術(shù)語定義。 （3）反映業(yè)務(wù)領(lǐng)域知識的既往經(jīng)驗(yàn)。,22,分析類,描述概念模型的UML類圖主要由分析類組成。 分析類是指直接服務(wù)于用戶功能性需求的概念層面的類，它們與待開發(fā)軟件系統(tǒng)的具體實(shí)現(xiàn)技術(shù)無關(guān)。 概念層UML類圖也可以稱為

9、分析類圖。,23,三種分析類,邊界類。負(fù)責(zé)目標(biāo)軟件系統(tǒng)與參與者之間的交互。 控制類。作為完成用例任務(wù)的責(zé)任承擔(dān)者，負(fù)責(zé)協(xié)調(diào)、控制其它類共同完成用例規(guī)定的功能或行為。 實(shí)體類。負(fù)責(zé)保存目標(biāo)軟件系統(tǒng)中具有持久意義的信息項(xiàng)并向其它類提供讀、寫信息項(xiàng)內(nèi)容的必要操作接口，一般不涉及業(yè)務(wù)邏輯處理。,24,（2）頂層架構(gòu)設(shè)計(jì),頂層架構(gòu)的主要目的是為后續(xù)的分析和設(shè)計(jì)活動(dòng)建立一種結(jié)構(gòu)和劃分，以便開發(fā)人員在不同的開發(fā)階段，以及同一開發(fā)階段的不同開發(fā)人員，能夠聚焦于系統(tǒng)的不同部分。 頂層架構(gòu)是分析和設(shè)計(jì)的階段成果的承載體。 隨著開發(fā)過程的推進(jìn)，框架中的內(nèi)容不斷豐富、翔實(shí)，最終演進(jìn)為完整的面向?qū)ο筌浖Y(jié)構(gòu)。,25,頂

10、層架構(gòu)設(shè)計(jì),頂層架構(gòu)的設(shè)計(jì)可以把體系結(jié)構(gòu)設(shè)計(jì)方法與概念模型得到的結(jié)果結(jié)合起來考慮，利用一定的體系結(jié)構(gòu)模式（例如分層模式、模型視圖控制器MVC模式等）對概念模型中的相關(guān)元素進(jìn)行組織，同時(shí)需要考慮目標(biāo)軟件系統(tǒng)與其它作為參與者的外部 系統(tǒng)之間的聯(lián)系和交互方式。UML包圖非常適合于表示軟件頂層架構(gòu)，可以從某種視角將具有比較密切的關(guān)聯(lián)的一些類劃分為一個(gè)包，分屬不同包的兩個(gè)類之間的關(guān)聯(lián)則比較松散。,26,內(nèi)容,4.1基于UML的分析與設(shè)計(jì)過程 4.2用例分析與設(shè)計(jì) 4.3概念模型和頂層架構(gòu)設(shè)計(jì) 4.4用戶界面設(shè)計(jì) 4.5數(shù)據(jù)模型設(shè)計(jì) 4.6設(shè)計(jì)精化 4.7類設(shè)計(jì) 4.8部署模型設(shè)計(jì),27,用戶界面設(shè)計(jì)的內(nèi)

11、容,用戶界面包含兩方面內(nèi)容： 首先要完整地包括用戶在使用軟件過程中所需的各種元素，例如窗口、菜單、按鈕、輸入文本框、選擇列表、提示信息等，缺乏這些元素中的某些將會導(dǎo)致軟件功能無法被用戶正常完成； 其次要求具有良好的外觀和布局，例如背景顏色、按鈕等元素的位置、選擇列表中條目的順序等，這些因素的不足可能不會影響軟件功能的正確使用，但會給用戶帶來不便、迷惑甚至反感。,28,用戶界面的層次和結(jié)構(gòu),層次： 屏幕 窗口 用戶界面的結(jié)構(gòu)可以由UML類圖描述，屏幕和窗口用類進(jìn)行表示，并給出它們之間的關(guān)系。 用構(gòu)造型和分別表示屏幕和窗口。 而屏幕之間的切換過程可以用UML狀態(tài)圖表示。,29,屏幕結(jié)構(gòu)類圖,30,

12、屏幕變化狀態(tài)圖,31,屏幕結(jié)構(gòu)包圖,32,內(nèi)容,4.1基于UML的分析與設(shè)計(jì)過程 4.2用例分析與設(shè)計(jì) 4.3概念模型和頂層架構(gòu)設(shè)計(jì) 4.4用戶界面設(shè)計(jì) 4.5數(shù)據(jù)模型設(shè)計(jì) 4.6設(shè)計(jì)精化 4.7類設(shè)計(jì) 4.8部署模型設(shè)計(jì),33,持久數(shù)據(jù)模型設(shè)計(jì)步驟,確定設(shè)計(jì)模型中需要持久保存的類的對象及其屬性，其中實(shí)體類是主要關(guān)注對象。 確定持久存儲的數(shù)據(jù)之間的組織方式。 確定數(shù)據(jù)模型中的操作行為，例如數(shù)據(jù)完整性驗(yàn)證、數(shù)據(jù)讀取、存儲與更新、數(shù)據(jù)求和、求數(shù)據(jù)平均值等。 進(jìn)一步優(yōu)化持久數(shù)據(jù)操作的性能，例如使用數(shù)據(jù)索引、存儲過程、觸發(fā)器等方式。,34,關(guān)系數(shù)據(jù)庫建模,可以把類對應(yīng)于關(guān)系數(shù)據(jù)模型中的表格（table

13、），對象對應(yīng)于記錄（record），屬性對應(yīng)于表格中的字段（field）或者列（column）。,35,數(shù)據(jù)模型,36,內(nèi)容,4.1基于UML的分析與設(shè)計(jì)過程 4.2用例分析與設(shè)計(jì) 4.3概念模型和頂層架構(gòu)設(shè)計(jì) 4.4用戶界面設(shè)計(jì) 4.5數(shù)據(jù)模型設(shè)計(jì) 4.6設(shè)計(jì)精化 4.7類設(shè)計(jì) 4.8部署模型設(shè)計(jì),37,設(shè)計(jì)精化的任務(wù),（1）精化軟件架構(gòu) （2）調(diào)整軟件組成類 （3）精化交互模型 （4）精化類之間關(guān)系,38,（1）精化軟件架構(gòu),精化軟件架構(gòu)的主要目的是尋找一種理想的包劃分方案，使得每個(gè)包中直接包含的類的數(shù)量規(guī)模適中，包的邊界清晰、自然，并且包間的耦合度較低。 隨著分析和設(shè)計(jì)不斷深入，原有包圖

14、中的包可能包含了過多的類，此時(shí)需要對其進(jìn)行分拆。 按照軟件工程強(qiáng)內(nèi)聚、松耦合的原則，這種分拆應(yīng)該具有某種自然劃分的性質(zhì)，并且盡可能降低劃分以后的子包之間的耦合度。,39,有關(guān)原則,避免包間的循環(huán)依賴關(guān)系，即，排除包P1依賴于包P2、P2又依賴于P1的情形。 在層次結(jié)構(gòu)中，位于較低層次的通用包不應(yīng)當(dāng)依賴于較高層次中的專用包。 在層次結(jié)構(gòu)中，較高層次的包可以依賴于較低層次的包，但應(yīng)盡量在相鄰的層次間發(fā)生。 如果針對某些子系統(tǒng)專門劃分了接口包和實(shí)現(xiàn)包，那么，其它與該子系統(tǒng)相關(guān)的包只能依賴于接口包，不能依賴于實(shí)現(xiàn)包。,40,（2）調(diào)整軟件構(gòu)成類,增加輔助類 合并相互通信頻繁的類 分拆規(guī)模過大的類,41

15、,（3）精化交互模型,對交互圖進(jìn)行精化時(shí)，需要考慮以下內(nèi)容： 要考慮軟件架構(gòu)和組成類被調(diào)整之后對交互模型會產(chǎn)生哪些影響，新出現(xiàn)的對象或拆分后的對象如何參與交互過程，在其中起到什么樣的作用。 對象在交互過程中的消息傳遞需要哪些參數(shù)和返回值。 交互過程是否需要細(xì)化，例如增加必要的消息，或?qū)植恳靡粋€(gè)更加具體的交互圖。,42,（4）精化類之間的關(guān)系,根據(jù)這些連接的語義強(qiáng)度將它們精確地判定為UML的依賴、關(guān)聯(lián)、聚合或構(gòu)成關(guān)系之一； 確定連接的方向及參與連接的類對象之間的數(shù)量對應(yīng)關(guān)系； 根據(jù)軟件復(fù)用的要求及軟件結(jié)構(gòu)簡潔化、清晰化的要求，優(yōu)化類之間的關(guān)系。,43,內(nèi)容,4.1基于UML的分析與設(shè)計(jì)過程

16、4.2用例分析與設(shè)計(jì) 4.3概念模型和頂層架構(gòu)設(shè)計(jì) 4.4用戶界面設(shè)計(jì) 4.5數(shù)據(jù)模型設(shè)計(jì) 4.6設(shè)計(jì)精化 4.7類設(shè)計(jì) 4.8部署模型設(shè)計(jì),44,類設(shè)計(jì)的任務(wù),（1）對類的屬性與操作進(jìn)行精化。 （2）對類的對象實(shí)例在其生命周期中對外部消息的響應(yīng)和狀態(tài)變化過程進(jìn)行建模。 （3）對類中重要操作的實(shí)現(xiàn)過程或算法進(jìn)行描述。,45,（1）精化類的屬性與操作,對于類的每項(xiàng)屬性，在設(shè)計(jì)模型中，可以定義屬性的名稱、類型、初始值、取值范圍及屬性說明，后三項(xiàng)內(nèi)容是可選的。 操作的基本內(nèi)容包括名稱、參數(shù)表（含參數(shù)的名稱和類型）、返回類型、功能描述。 如果操作比較復(fù)雜，還需要用文字或UML活動(dòng)圖說明操作的實(shí)現(xiàn)算法。,46,（2）類的行為模型設(shè)計(jì),針對整個(gè)類使用UML狀