Chap面向對象的軟件設計方法實用教案

1、1第1頁/共50頁第一頁，共51頁。2基于UML的分析(fnx)與設計 UML是獨立于軟件開發(fā)過程的，它幾乎可以用于任何類型的軟件開發(fā)過程，包括瀑布式、迭代式、螺旋式等不同模型。 在軟件分析和設計中，可以根據(jù)項目的特征、開發(fā)組織在已有實踐中定義的相關(xinggun)規(guī)范、設計人員本身的偏好等因素，對基于UML的軟件設計過程進行定制。 第2頁/共50頁第二頁，共51頁。3基于(jy)UML的分析與設計過程第3頁/共50頁第三頁，共51頁。4第4頁/共50頁第四頁，共51頁。5案例：銀行ATM自動柜員機的需求(xqi)簡述 本案例將要開發(fā)的ATM系統(tǒng)能夠為顧客提供以下基本服務（它們統(tǒng)一稱為交易）

2、： 取款服務。顧客可以用銀行卡從對應的賬戶中支取現(xiàn)金(xinjn)，現(xiàn)金(xinjn)必須是100元的整數(shù)倍，且每次取款不能超過2000元。 存款服務。顧客可以把現(xiàn)金(xinjn)存入與銀行卡對應的賬戶中。 轉帳服務。顧客可以把一個銀行卡對應的賬戶中的款項轉帳到另一個銀行賬戶中。 查詢服務。顧客能夠查詢一個銀行卡對應的賬戶中的余額。第5頁/共50頁第五頁，共51頁。6（1）確定(qudng)用例 采用用例模型描述系統(tǒng)需求時，首先需要開發(fā)人員從業(yè)務需求描述出發(fā)獲取參與者（Actor）和場景，對場景進行匯總、分類、抽象，形成用例。 場景是從單個參與者的角度觀察目標軟件系統(tǒng)的功能和外部行為，這種功能

3、通過系統(tǒng)與用戶(yngh)之間的交互來表示。 場景是用例的實例，而用例是某類場景的共同抽象。 第6頁/共50頁第六頁，共51頁。7獲取(huq)場景目標軟件系統(tǒng)有哪些參與者？參與者希望系統(tǒng)執(zhí)行的任務有哪些？參與者希望獲得哪些信息？這些(zhxi)信息由誰生成？由誰修改？參與者需要通知系統(tǒng)哪些事件？系統(tǒng)響應這些(zhxi)事件時會表現(xiàn)出哪些外部行為？系統(tǒng)將通告參與者哪些事件？第7頁/共50頁第七頁，共51頁。8定義(dngy)用例 在場景確定之后，通過對場景的匯總(huzng)、分類歸并、抽象即可形成用例。 需要特別注意的是，參與者并只限于人員，其它與目標軟件發(fā)生交互的外部實體或系統(tǒng)也是參與者；

4、用例應該是對參與者可見的系統(tǒng)需求或功能，否則不能作為用例。 第8頁/共50頁第八頁，共51頁。9ATM案例(n l)的參與者 “顧客”（Customer） “操作(cozu)管理人員”（Operator） “銀行服務器”（Bank System） “讀卡器”（Card Reader） “存款器”（Cash Acceptor） “取款器”（Cash Dispenser） “打印機”（Printer）第9頁/共50頁第九頁，共51頁。10ATM案例(n l)的用例 “取款”（Withdrawal） “存款”（Deposit） “轉帳(zhun zhn)”（Transfer） “查詢余額”（Inqu

5、iry） “開機”（System Startup） “關機”（System Shutdown）第10頁/共50頁第十頁，共51頁。11（2）生成(shn chn)用例圖 生成用例圖是一個逐步精化的過程，首先可以建立初步的用例圖，包括前面發(fā)現(xiàn)的參與者和用例； 然后對用例圖進行細化，定義用例之間“包含”、“擴展”、“繼承”等關系(gun x)，并可能需要定義新的用例，以能夠更準確地使用用例圖描述系統(tǒng)需求。 第11頁/共50頁第十一頁，共51頁。12生成(shn chn)初步用例圖第12頁/共50頁第十二頁，共51頁。13用例圖的細化 包含(bohn)（include）關系 擴展（extend）關系

6、 繼承關系 第13頁/共50頁第十三頁，共51頁。14細化后ATM用例圖第14頁/共50頁第十四頁，共51頁。15（3）用例描述(mio sh) 對用例的完整描述包括用例名稱、參與者、前置條件、一個主事件流、0到多個輔事件流、后置條件。 主事件流表示正常(zhngchng)情況下參與者與系統(tǒng)之間的信息交互及動作序列， 輔事件流則表示特殊情況或異常情況下的信息交互及動作序列。 第15頁/共50頁第十五頁，共51頁。16“取款用例”描述(mio sh)(mio sh) 用例名稱：Withdrawal 參與者：Customer，Bank System，Card Reader，Cash Dispens

7、er，Printer 前置條件：顧客已插入銀行卡，密碼驗證正確，顧客按下“取款”按鈕 主事件流： 顧客輸入取款金額，并確認。 系統(tǒng)認可取款金額，并發(fā)送指令給取款器。 取款器把相應金額的現(xiàn)金送出。 打印機打印回執(zhí)。 輔事件流： 如果取款金額不是100的整數(shù)倍，則顯示信息“輸入金額必須是100的整數(shù)倍，請重新輸入”，并返回主事件流中步驟（1）。 如果取款金額超過2000元，則顯示信息“輸入金額不能超過2000元，請重新輸入” ，并返回主事件流中步驟（1）。 如果賬戶余額小于取款金額，則顯示信息“賬戶余額不足，請重新輸入” ，并返回主事件流中步驟（1）。 顧客在確認取款金額前可以(ky)選擇取消交易

8、。 后置條件：如果取款成功，系統(tǒng)從賬戶余額中減去相應數(shù)額，并返回等待狀態(tài)；如果顧客取消交易，則返回等待狀態(tài)。第16頁/共50頁第十六頁，共51頁。17用順序(shnx)圖描述用例第17頁/共50頁第十七頁，共51頁。18第18頁/共50頁第十八頁，共51頁。19（1）概念模型設計(shj) 在用戶需求和相關的業(yè)務領域中，往往有一些全局性的概念對于(duy)理解需求至關重要，因此，有必要抽取這些概念，研究這些概念之間的關系。 UML類圖非常適合用來建立領域概念模型，描述在問題域中存在哪些主要概念和對象，并表示出它們之間的關系，例如關聯(lián)、聚集、繼承等。 為建立以UML類圖表示的領域概念模型，首先必

9、須標識關鍵概念。 第19頁/共50頁第十九頁，共51頁。20關鍵概念(ginin)的來源（1）業(yè)務需求描述、用例說明；（2）業(yè)務領域中的相關規(guī)范、標準、術語定義(dngy)。（3）反映業(yè)務領域知識的既往經(jīng)驗。第20頁/共50頁第二十頁，共51頁。21分析(fnx)類 描述概念模型的UML類圖主要由分析類組成。 分析類是指直接服務于用戶功能性需求的概念層面的類，它們(t men)與待開發(fā)軟件系統(tǒng)的具體實現(xiàn)技術無關。 概念層UML類圖也可以稱為分析類圖。 第21頁/共50頁第二十一頁，共51頁。22三種(sn zhn)分析類 邊界類。負責目標軟件系統(tǒng)與參與者之間的交互。 控制類。作為完成(wn c

10、hng)用例任務的責任承擔者，負責協(xié)調、控制其它類共同完成(wn chng)用例規(guī)定的功能或行為。 實體類。負責保存目標軟件系統(tǒng)中具有持久意義的信息項并向其它類提供讀、寫信息項內容的必要操作接口，一般不涉及業(yè)務邏輯處理。 第22頁/共50頁第二十二頁，共51頁。23（2）頂層(dn cn)架構設計 頂層架構的主要目的是為后續(xù)的分析和設計活動建立一種(y zhn)結構和劃分，以便開發(fā)人員在不同的開發(fā)階段，以及同一開發(fā)階段的不同開發(fā)人員，能夠聚焦于系統(tǒng)的不同部分。 頂層架構是分析和設計的階段成果的承載體。 隨著開發(fā)過程的推進，框架中的內容不斷豐富、翔實，最終演進為完整的面向對象軟件結構。 第23頁

11、/共50頁第二十三頁，共51頁。24頂層(dn cn)架構設計 頂層架構的設計可以把體系結構設計方法與概念模型得到的結果結合起來考慮，利用(lyng)一定的體系結構模式（例如分層模式、模型視圖控制器MVC模式等）對概念模型中的相關元素進行組織，同時需要考慮目標軟件系統(tǒng)與其它作為參與者的外部 系統(tǒng)之間的聯(lián)系和交互方式。UML包圖非常適合于表示軟件頂層架構，可以從某種視角將具有比較密切的關聯(lián)的一些類劃分為一個包，分屬不同包的兩個類之間的關聯(lián)則比較松散。 第24頁/共50頁第二十四頁，共51頁。25第25頁/共50頁第二十五頁，共51頁。26用戶界面(yn h ji min)設計的內容 用戶界面包含

12、兩方面內容： 首先要完整地包括用戶在使用軟件過程中所需的各種元素(yun s)，例如窗口、菜單、按鈕、輸入文本框、選擇列表、提示信息等，缺乏這些元素(yun s)中的某些將會導致軟件功能無法被用戶正常完成； 其次要求具有良好的外觀和布局，例如背景顏色、按鈕等元素(yun s)的位置、選擇列表中條目的順序等，這些因素的不足可能不會影響軟件功能的正確使用，但會給用戶帶來不便、迷惑甚至反感。 第26頁/共50頁第二十六頁，共51頁。27用戶界面(yn h ji min)的層次和結構 層次： 屏幕 窗口 用戶界面(yn h ji min)的結構可以由UML類圖描述，屏幕和窗口用類進行表示，并給出它們之

13、間的關系。 用構造型和分別表示屏幕和窗口。 而屏幕之間的切換過程可以用UML狀態(tài)圖表示。第27頁/共50頁第二十七頁，共51頁。28屏幕(pngm)結構類圖第28頁/共50頁第二十八頁，共51頁。29屏幕(pngm)變化狀態(tài)圖第29頁/共50頁第二十九頁，共51頁。30屏幕(pngm)結構包圖第30頁/共50頁第三十頁，共51頁。31第31頁/共50頁第三十一頁，共51頁。32持久數(shù)據(jù)模型設計(shj)步驟確定設計模型中需要持久保存的類的對象及其屬性，其中(qzhng)實體類是主要關注對象。確定持久存儲的數(shù)據(jù)之間的組織方式。確定數(shù)據(jù)模型中的操作行為，例如數(shù)據(jù)完整性驗證、數(shù)據(jù)讀取、存儲與更新、數(shù)

14、據(jù)求和、求數(shù)據(jù)平均值等。進一步優(yōu)化持久數(shù)據(jù)操作的性能，例如使用數(shù)據(jù)索引、存儲過程、觸發(fā)器等方式。第32頁/共50頁第三十二頁，共51頁。33關系數(shù)據(jù)庫建模 可以把類對應于關系數(shù)據(jù)模型中的表格（table），對象對應于記錄( jl)（record），屬性對應于表格中的字段（field）或者列（column）。 第33頁/共50頁第三十三頁，共51頁。34數(shù)據(jù)模型第34頁/共50頁第三十四頁，共51頁。35第35頁/共50頁第三十五頁，共51頁。36設計(shj)精化的任務（1）精化軟件(run jin)架構（2）調整軟件(run jin)組成類（3）精化交互模型（4）精化類之間關系第36頁/共5

15、0頁第三十六頁，共51頁。37（1）精化(jn hu)軟件架構 精化軟件架構的主要目的是尋找一種理想的包劃分方案，使得每個包中直接包含的類的數(shù)量規(guī)模適中，包的邊界清晰、自然，并且包間的耦合度較低。 隨著分析和設計不斷深入，原有包圖中的包可能(knng)包含了過多的類，此時需要對其進行分拆。 按照軟件工程強內聚、松耦合的原則，這種分拆應該具有某種自然劃分的性質，并且盡可能(knng)降低劃分以后的子包之間的耦合度。 第37頁/共50頁第三十七頁，共51頁。38有關(yugun)原則避免(bmin)包間的循環(huán)依賴關系，即，排除包P1依賴于包P2、P2又依賴于P1的情形。在層次結構中，位于較低層次的

16、通用包不應當依賴于較高層次中的專用包。在層次結構中，較高層次的包可以依賴于較低層次的包，但應盡量在相鄰的層次間發(fā)生。如果針對某些子系統(tǒng)專門劃分了接口包和實現(xiàn)包，那么，其它與該子系統(tǒng)相關的包只能依賴于接口包，不能依賴于實現(xiàn)包。第38頁/共50頁第三十八頁，共51頁。39（2）調整軟件(run jin)構成類 增加輔助類 合并相互通信(tng xn)頻繁的類 分拆規(guī)模過大的類 第39頁/共50頁第三十九頁，共51頁。40（3）精化(jn hu)交互模型 對交互圖進行精化時，需要考慮以下內容： 要考慮軟件架構和組成類被調整之后對交互模型會產生哪些影響，新出現(xiàn)的對象或拆分后的對象如何參與交互過程，在其

17、中起到什么樣的作用。 對象在交互過程中的消息傳遞需要哪些參數(shù)和返回值。 交互過程是否需要細化，例如(lr)增加必要的消息，或對局部引用一個更加具體的交互圖。第40頁/共50頁第四十頁，共51頁。41（4）精化(jn hu)類之間的關系根據(jù)這些連接的語義強度將它們精確地判定為UML的依賴、關聯(lián)、聚合或構成關系(gun x)之一；確定連接的方向及參與連接的類對象之間的數(shù)量對應關系(gun x)；根據(jù)軟件復用的要求及軟件結構簡潔化、清晰化的要求，優(yōu)化類之間的關系(gun x)。第41頁/共50頁第四十一頁，共51頁。42第42頁/共50頁第四十二頁，共51頁。43類設計(shj)的任務（1）對類的屬

18、性(shxng)與操作進行精化。（2）對類的對象實例在其生命周期中對外部消息的響應和狀態(tài)變化過程進行建模。（3）對類中重要操作的實現(xiàn)過程或算法進行描述。第43頁/共50頁第四十三頁，共51頁。44（1）精化(jn hu)類的屬性與操作 對于類的每項屬性，在設計模型中，可以定義屬性的名稱、類型、初始值、取值范圍及屬性說明(shumng)，后三項內容是可選的。 操作的基本內容包括名稱、參數(shù)表（含參數(shù)的名稱和類型）、返回類型、功能描述。 如果操作比較復雜，還需要用文字或UML活動圖說明(shumng)操作的實現(xiàn)算法。 第44頁/共50頁第四十四頁，共51頁。45（2）類的行為模型(mxng)設計針對整個類使用(shyng)UML狀態(tài)圖描述其行為。針對類中某些重要的方法，用UML活動圖描述其執(zhí)行過程或步驟。第45頁/共50頁第四十五頁，共51頁。46第46頁/共50頁第四十六頁，共51頁。47部署模型(mxng)設計的內容 最終開發(fā)完成的軟件包括哪些制品形式； 軟件運行環(huán)境存在哪些類型的物理(wl)節(jié)點； 不同節(jié)點之間的連接和通信形式是什么； 軟件制品應該如何在物理(wl)節(jié)點上進行部署，即它們的部署映射關系。第47頁/共50頁第四十七頁，共51頁。48ATM系統(tǒng)(xtng)部署模