面向對象方法與技術面向對象分析設計

共96頁第1頁面向對象方法與技術北京理工大學宋紅共96頁第2頁第3章面向對象的分析和設計3.1面向對象分析概述3.2面向對象設計概述3.3經典分析和設計方法介紹3.4可視化建模技術（VMT） 分析模型 設計模型 實現模型靜態(tài)特性：類層次關系模型動態(tài)特性：狀態(tài)圖、事件蹤跡圖面向對象分析OOA面向對象設計OOD面向對象實現OOI客觀事物共96頁第3頁3.1面向對象分析概述3.1.0遵循的原則3.1.1靜態(tài)結構分析3.1.2動態(tài)行為分析面向對象分析的任務&目的：

通過對問題空間的分析，建立系統(tǒng)的分析模型三種分析模型：功能模型：描述用戶的功能性需求對象模型：將系統(tǒng)分解成互相協(xié)作的分析類動態(tài)模型：描述系統(tǒng)的動態(tài)行為共96頁第4頁1構造與分解相結合3.1.0遵循的原則2抽象化與具體化相結合構造：使用基本（簡單）對象組裝成復雜對象分解：將復雜對象劃分為簡單對象，細化系統(tǒng)模型抽象化： 強調對象內在最本質的屬性，忽略或暫不考慮細節(jié) 或無重要關系的問題數據抽象：將實體的屬性數據及其上的操作抽象為對象過程抽象：將對象之間的相互作用抽象為消息的傳遞與處理具體化： 在已有認識的基礎上添加細節(jié)，逐步使認識深入相結合：分層次細化共96頁第5頁3.1.0遵循的原則3封裝對象外部特性與其實現的分離（注意模塊化的相關內容）最大限度地減少對象內部改變對外部的影響4相關相互聯系和作用的對象構成系統(tǒng)。人類總是尋著與已知事物的關系去認識新事物。對象之間的相關有靜態(tài)（整體和部分等）和動態(tài)（消息傳遞等）之分。5行為約束行為約束體現了對象的語義特征。對象的創(chuàng)建、操作的執(zhí)行等都將體現為對于對象行為的約束。助于深刻理解對象和系統(tǒng)。共96頁第6頁3.1.1靜態(tài)結構分析1.泛化—特化關系（一般化—特殊化）顧名思義，靜態(tài)結構分析過程研究問題的焦點是系統(tǒng)的結構，包括構成系統(tǒng)的對象、類以及類之間的相互關系。識別對象識別類添加屬性添加操作確立類之間的關系類之間的關系一般化與特殊化關系一般采用父類與子類之間的關系描述，通過父類與子類之間的關系在部分對象之間建立系統(tǒng)的層次結構共96頁第7頁3.1.1靜態(tài)結構分析例：考察由類“人”、“職員”、“學生”、“研究生”、“本科生”、“在職研究生”等六個類形成的一個學生成績管理系統(tǒng)的框架結構

人職員學生研究生本科生在職研究生各個類以及類之間的繼承派生關系是對問題空間的抽象，這種抽象的描述構成了系統(tǒng)的層次結構模型，未來軟件系統(tǒng)系統(tǒng)的層次結構模型與此具有相當程度的對應共96頁第8頁3.1.1靜態(tài)結構分析2.聚合（整體—部分）關系整體類部分類部分類整體類整體類整體類部分類部分類部分類整體類整體類部分類部分類整體-部分關系是人類對客觀事物間內在關聯的認知與反映，是人類認識規(guī)律的具體體現.整體和部分這兩種名稱局限于某個具體的整體-部分結構中的兩個類，而且是相互對應并在一定程度程度上相互依存類A的屬性成員之一是類B的對象實例，則稱A的對象實例為容器（對象），位于A類對象實例中、類B的對象實例稱為成員對象或組成對象，即此時類B的一些對象實例做為組成部分存在于類A的對象實例的內部。稱對象實例之間具有這種關系的兩個類之間存在整體——部分共享聚合 復合聚合共96頁第9頁3.1.1靜態(tài)結構分析2.聚合（整體—部分）關系復合聚合及共享聚合所描述的類之間關系的緊密程度不同：復合聚合中相關類間關系比較密切，組成對象只存在于一個容器對象中，其存在以容器對象的存在為條件。例如：人體與器官、學校與院系。共享聚合中組成對象往往在多個類的對象實例中充當組成部分，當這種對象實例中的某些消亡后，這個組成對象依然有存在的必要，只有當所有相關容器對象全部消亡后，這個組成對象才消亡。例如：單位與人。消息窗口按鈕圖標菜單確定0..1幫助0..1消息10..1文件0..1編輯0..1消息窗口按鈕確定0..1圖標消息10..1菜單文件0..1編輯0..1幫助0..1共96頁第10頁3.關聯關系3.1.1靜態(tài)結構分析兩個類的對象實例之間具有某種（屬性上的）依賴關系稱為對象鏈接。例：圖為平面上直線L1、L2、L3、L4、L5和點P1、P2、P3、P4之間的幾何關系，它們構成了一個系統(tǒng)，其中每個點和每條線都是可以看作為對象，請給出這個系統(tǒng)的對象實例圖和類圖。L1L2L5L3L4L6P1P2P3P4直線點相交2+L1L2L4L5P1P2P3P4L3L6共96頁第11頁3.關聯關系0..*保險合同1..*保險客戶涉及持有人丈夫結婚妻子公司保險公司1涉及有0..*保險單表達為表達0..1計算機人程序員擁有1..*公司工作*人公司名3.1.1靜態(tài)結構分析方向、角色、限定、重數對象實例間存在鏈接的類之間的關系稱為關聯。共96頁第12頁3.關聯關系3.1.1靜態(tài)結構分析例： …每個為公司工作的人都可以領到一份薪水和一項工作。老板評價每個工人的工作表現?！瓎T工工資帳號工作部門公司名稱地址薪水工作職務為…工作工作效率老板管理工人人姓名身份證號碼地址共96頁第13頁關于認知多樣性示例：3.1.1靜態(tài)結構分析照相手機普通手機照相機照相手機普通手機照相機照相手機普通手機照相手機照相機照相機照相手機普通手機共96頁第14頁關于系統(tǒng)層次結構示例：3.1.1靜態(tài)結構分析汽車配件摩托配件交通工具汽車摩托車購置經銷配件人經銷商司機*****1..*擁有足球隊人足球運動員共96頁第15頁3.1.1靜態(tài)結構分析擁有持有

顧客

利潤

交易者

生財工具

債券

股票

期貨11..*1..*1包含0..*0..*共96頁第16頁3.1.1靜態(tài)結構分析借方債權人

人員

金融機構

抵押

房屋

信貸銀行

銀行**本金比率到期**所有人財產共96頁第17頁3.1.2動態(tài)行為分析1.對象生命周期

對象的動態(tài)行為包括兩個方面的內容： 單個對象自身生命周期演化； 整個對象系統(tǒng)中對象間消息傳遞及相互作用對象狀態(tài)導致狀態(tài)轉換的事件狀態(tài)轉換時的動作S1S2S3S4event1event2event3event4狀態(tài)轉換圖共96頁第18頁3.1.2動態(tài)行為分析狀態(tài)轉換圖示例：

電梯運行過程的狀態(tài)轉換圖

在第一層向上移動空閑向下移動向一層移動上到下超時限到到上下共96頁第19頁3.1.2動態(tài)行為分析事件蹤跡圖對象間消息傳遞及相互作用使用事件蹤跡圖表示 例：打印服務器事件蹤跡圖打?。ㄎ募打印機空閑]打?。ㄎ募打印機忙]暫存（文件）:計算機類:打印服務器類:打印機類:打印隊列類打?。ㄎ募┕?6頁第20頁3.1.2動態(tài)行為分析(舉例)例：電話線通話過程狀態(tài)圖空閑撥號音撥號連接鈴響連通斷連紀錄信息超時忙音快速忙音提起話筒一位號碼一位號碼號碼忙中繼線忙有效號碼通路對方應答對方掛斷信息送完放下話筒放下話筒超時超時無效號碼共96頁第21頁3.1.2動態(tài)行為分析（舉例）例：通話事件蹤跡圖拿起耳機撥號音開始撥號4撥號8撥號3撥號2鈴聲鈴聲鈴聲停止接受對方回答鈴聲停止電話連通電話連通受話方掛機電話斷開電話斷開打電話者掛機打電話者電話線接電話者共96頁第22頁3.2面向對象設計概述3.2.1系統(tǒng)設計3.2.2對象設計分析期間建立系統(tǒng)模型設計期間模型問題空間對象面向對象設計階段在分析模型基礎上進行未來軟件的系統(tǒng)設計、對象設計，從而得到設計模型，該模型包含了解決問題的方案和策略。是確定問題具體解決方案的過程面向對象的設計原則最基本的設計原則：單一職責原則開放封閉原則依賴倒置原則接口隔離原則Liskov替換原則共96頁第23頁單一職責（SRP）原則共96頁第24頁核心思想為：一個類，最好只做一件事，只有一個引起它的變化。

低耦合、高內聚共96頁第25頁違反了SRP(單一職責原則)開放封閉原則共96頁第26頁核心思想是：軟件實體應該是可擴展的，而不可修改的。也就是，對擴展開放，對修改封閉的。

開放封閉原則是面向對象所有原則的核心，軟件設計追求的目標就是封裝變化、降低耦合，而開放封閉原則就是這一目標的最直接體現。

共96頁第27頁開放封閉原則共96頁第28頁抽象是關鍵抽象類實體類抽象服務類對修改是閉合的，實體類的實現對擴展是開放的。依賴倒置原則共96頁第29頁核心思想是：依賴于抽象。具體而言就是高層模塊不依賴于底層模塊，二者都同依賴于抽象；抽象不依賴于具體，具體依賴于抽象。依賴倒置原則共96頁第30頁如果代碼中不用依賴倒置，將面臨如下風險：使用低級類會破環(huán)高級代碼；當低級類變化時需要很多時間和代價來修改高級代碼；產生低復用的代碼；依賴于抽象，就是對接口編程，不要對實現編程。接口隔離原則共96頁第31頁核心思想是：使用多個小的專門的接口，而不要使用一個大的總接口。

接口隔離原則接口隔離原則體現在：接口應該是內聚的，應該避免“胖”接口。一個類對另外一個類的依賴應該建立在最小的接口上，不要強迫依賴不用的方法，這是一種接口污染。接口隔離強調接口的單一性。接口應該僅包含必要的方法,而不該包含其它的。接口隔離原則確保實現的接口有他們共同的職責,它們是明確的,易理解的,可復用的。共96頁第32頁接口隔離原則分離的手段主要有以下兩種：1.委托分離，通過增加一個新的類型來委托客戶的請求，隔離客戶和接口的直接依賴，但是會增加系統(tǒng)的開銷。2.多重繼承分離，通過接口多繼承來實現客戶的需求，這種方式是較好的。共96頁第33頁接口隔離原則共96頁第34頁違反接口隔離原則的一個胖接口Liskov替換原則共96頁第35頁核心思想是：子類必須能夠替換其基類。即使用基類引用的函數必須能使用繼承類的對象而不必知道它。Liskov替換原則Liskov替換原則是關于繼承機制的設計原則，違反了Liskov替換原則就必然導致違反開放封閉原則。"Liskov替換原則"正是保證繼承能夠被正確使用的方法。共96頁第36頁Liskov替換原則

Liskov替換原則思想體現為對繼承機制的約束規(guī)范，只有子類能夠替換基類時，才能保證系統(tǒng)在運行期內識別子類，這是保證繼承復用的基礎。

共96頁第37頁Liskov替換原則

Liskov替換原則，主要著眼于對抽象和多態(tài)建立在繼承的基礎上，因此只有遵循了Liskov替換原則，才能保證繼承復用是可靠地。實現的方法是面向接口編程：將公共部分抽象為基類接口或抽象類，通過ExtractAbstractClass，在子類中通過覆寫父類的方法實現新的方式支持同樣的職責。共96頁第38頁Liskov替換原則共96頁第39頁如果沒有LSP，類繼承就會混亂；如果子類作為一個參數傳遞給方法，將會出現未知行為；如果沒有LSP，適用與基類的單元測試將不能成功用于測試子類；使用LSP做為一個檢查工作來測試繼承是否正確。面向對象的設計原則以上就是5個基本的設計原則，它們就像面向對象程序設計中的金科玉律，遵守它們可以使我們的代碼更加鮮活，易于復用，易于拓展，靈活優(yōu)雅。共96頁第40頁共96頁第41頁3.2.1系統(tǒng)設計1系統(tǒng)層次結構設計系統(tǒng)設計是以軟件方式實現系統(tǒng)功能而進行軟件的系統(tǒng)結構設計及程序實現中的總體的、策略性的解決方案的制定時間空間軟件硬件單一一般效率可維高層次接口模塊1模塊2模塊3應用程序模塊1模塊2模塊3核心模塊1模塊2模塊3驅動模塊1模塊2模塊3硬件模塊1模塊2模塊3對軟件系統(tǒng)進行的整體劃分。水平方向代表系統(tǒng)的不同抽象級別與層次；縱向表明每個層次所提供的功能模塊共96頁第42頁OSI&TCP/IPIP InternetprotocolICMP InternetControlMessageProtocolARP AddressResolutionProtocolRARP ReverseAddressResolutionProtocolUDP UserDatagramProtocol共96頁第43頁面向虛擬軟件企業(yè)

基于工作流的軟件生產過程控制與支撐平臺視圖控制文檔MVC(ModelViewControl)共96頁第44頁面向虛擬軟件企業(yè)

基于工作流的軟件生產過程控制與支撐平臺共96頁第45頁3.2.1系統(tǒng)設計2系統(tǒng)數據存儲設計系統(tǒng)中各種數據對象的存儲方式設計：內存數據結構、文件、數據庫等如分布環(huán)境中對象的存儲結構與單機環(huán)境下不同、持久對象等3系統(tǒng)資源訪問設計確定需要使用的資源，包括訪問機制和訪問安全性機制等如：訪問隊列等4網絡與分布設計如何將問題劃分給不同節(jié)點進行分布式運算，需考慮網絡流量、節(jié)點計算能力、系統(tǒng)效率共96頁第46頁3.2.1系統(tǒng)設計6互操作設計5并發(fā)性設計并發(fā)性控制，多進程、多線程等文件并行訪問，使用臨界區(qū)、事件、互斥量、信號燈等確定對象之間的消息傳遞方式，如過程驅動、事件驅動和并發(fā)驅動等等。相對于Client/Server而言。多個進程之間可能需要為對方提供服務?？赡鼙容^復雜，因為有可能存在平臺異構問題。例外、邊界也需要處理共96頁第47頁3.2.2對象設計靜態(tài)結構設計根據具體實現策略對分析模型進行擴充，逐步使對象的描述接近軟件的最終實現。添加人機交互、數據庫及資源訪問、網絡訪問方面的支持。為軟件實現的方便對對象模型所給出的結構進行重構，將一些對象合并或拆分?？紤]復用、可維護性等進行重構。2動態(tài)行為設計對動態(tài)行為分析模型進行擴充，獲取完整模型?？紤]計算復雜度、代碼清晰度及性能等因素。共96頁第48頁3.3經典分析和設計方法介紹3.3.1OMT3.3.2OOD3.3.3RDD3.3.4OOAD3.3.5OOSE采用面向對象技術進行分析和設計的軟件開發(fā)方法很多，各種方法都有各自的特點。共96頁第49頁OMT分析綜述3.3.1OMT(ObjectModelingTechnique)在關系數據庫設計的實體關系模型的基礎上擴展了類、繼承和行為等概念得到。產生需求建立模型開發(fā)者管理者用戶問題描述對象模型動態(tài)模型功能模型與用戶磋商學科知識實際經驗需求的描述，而不是問題的解決。哪些特性可選、哪些必需從模糊的設計和實現需求中分離出正確的需求共96頁第50頁3.3.1OMT——ATM網絡系統(tǒng)

1、問題描述目的： 描述需求，解決做什么，而不是怎樣做的問題。任務： 描述問題范圍、需求（將實現的功能）、特性設計一個支持銀行網絡系統(tǒng)的軟件，這個網絡，包括出納員和ATM自動取款機，由聯營銀行共享。每個銀行提供各自的計算機來維護它的帳務和處理面臨的事物。出納工作站屬于各銀行，且直接與銀行的計算機通信。人工出納員輸入帳務和處理數據。自動取款機與中央計算機通信，中央計算機分理事物到相應的銀行。自動取款機接受現金卡，與用戶交互，與中央系統(tǒng)通信并完成事物處理，分配現金和打印收據。系統(tǒng)需要恰當的記錄和安全保證。系統(tǒng)必須正確控制并發(fā)訪問同一賬號，銀行將提供自己的計算機軟件；請為ATM和網絡設計軟件。共享系統(tǒng)的費用根據現金卡客戶的數量由各銀行分擔。問題描述示意圖:

ATM銀行計算機銀行計算機中央計算機帳戶帳戶帳戶帳戶ATMATM柜員機共96頁第51頁2、對象模型：類的識別3.3.1OMT——ATM網絡系統(tǒng)

提取名詞排除虛假的類需求說明試探性的對象類對象類軟件銀行計算機中央計算機保存記錄裝置銀行網絡帳戶現金卡安全裝置出納員業(yè)務用戶存取出納工作站現金費用聯營帳目數據收據客戶銀行業(yè)務數據系統(tǒng)ATM與類對應的經常是問題描述中的名詞共96頁第52頁保留正確類3.3.1OMT——ATM網絡系統(tǒng)

費用不相干存取軟件實現賬目數據收據現金業(yè)務數據屬性系統(tǒng)安全裝置保存記錄裝置銀行網絡模糊用戶冗余冗余類： 對描述同一信息的多個類只保留一個。如：客戶與用戶無關類： 刪除與所述問題無關的類。如費用的分擔不在ATM事物處理范圍內模糊類： 邊界不明顯或范圍過寬。如系統(tǒng)、屬性： 用于描述對象性質的名詞為屬性。應具體分析，如：房間操作： 帶有動詞性質的名詞有時為動作，應描述為操作。如：傳呼角色： 類名應反映事物固有性質，而不是關聯中的角色。如：擁有者、駕駛員實現結構： 脫離實際的結構在分析模型中刪除。如：子程序、數據庫結構、數組等共96頁第53頁2、對象模型：制定數據字典銀行計算機中央計算機帳戶現金卡ATM出納員業(yè)務客戶出納工作站聯營銀行3.3.1OMT——ATM網絡系統(tǒng)

帳戶： 銀行中的一個戶頭，與交易中使用的帳戶類似。帳戶可能有許多不同的類型，至少有支票帳戶和儲蓄帳戶兩類。一位客戶可以擁有不止一個帳戶ATM: 允許客戶用現金卡做為身分證明進入自己的帳戶的一種機器。ATM與客戶交互，通過收集業(yè)務處理信息，并把該信息送至中心計算機和方式證明客戶的合法性后進行處理，把現金分配給客戶。銀行： 一個金融機構，它代管客戶帳目，發(fā)行現金卡給客戶并授權客戶可以通過ATM網絡進入自己的帳戶，存取現金等出納員： 銀行的雇員。被授權把業(yè)務信息輸入柜員機，接收或分配現金和支票給客戶。柜員處理的業(yè)務、現金、和支票必須記錄，并對其全部負責。

共96頁第54頁3.3.1OMT——ATM網絡系統(tǒng)

出納工作站：柜員為客戶輸入業(yè)務信息的一套設備。柜員用此套設備開出支票和接收現金，并打印收據。柜員機與銀行計算機通信，使業(yè)務生效并進行處理。中心處理機：由聯營機構操縱的計算機。它協(xié)調ATM與銀行計算機之間的業(yè)務，中心處理機負責驗明銀行代碼的有效性，但并不直接處理業(yè)務。聯營：多個銀行組成的一個組織機構。授命指揮和操作ATM網絡。該網絡僅處理屬于聯營機構中的銀行之間的業(yè)務。業(yè)務：客戶對帳目的一個單一而完整的操作要求。我們只詳述ATM必須分發(fā)現金，但不排除打印支票或者接收現金、支票的可能性，因為我們應該考慮為客戶訪問自己帳目提供更多的方便和靈活性，盡管現在還不具備條件。不同的操作必須正確地結算。共96頁第55頁3.3.1OMT——ATM網絡系統(tǒng)

客戶：在銀行有一個或多個帳戶的所有者?？蛻粲梢粋€或多個人或公司組成。通信方面與客戶組成無關，在不同的銀行有帳戶的同一個人視為不同的客戶。銀行計算機：銀行所擁有的、與ATM網絡以及該銀行柜員機相連接的計算機。一個銀行可能擁有一個用于處理內部帳務的計算機網絡，但我們只關注與網絡通信的這臺計算機?，F金卡：銀行分發(fā)給客戶的卡片?？蛻艨梢酝ㄟ^ATM用現金卡訪問自己的帳戶。每個卡包含一個銀行代碼和卡片號碼。銀行代碼唯一確定聯營機構中的一個銀行。卡片號決定了該卡可訪問的帳戶。一張現金卡只屬于一個客戶，但可能會存在若干個拷貝，必須考慮在不同計算機上相同的現金卡同時使用的可能性。共96頁第56頁2、對象模型：關聯的識別3.3.1OMT——ATM網絡系統(tǒng)

關聯常對應于靜態(tài)動詞或動詞短語常見的有：實際位置： 下接，其中一部分， 包含在，在...之上引導動作： 驅動，駕駛通信： 與...交談?chuàng)碛校?有，其中一部分滿足的條件： 為...工作，與...結婚 通信、擁有、與類的識別過程類似，識別關聯時首先將問題描述中的所有可能的關聯（動詞短語）列表，然后逐條刪去不正確的關聯，保留正確的。銀行網絡包括出納員和ATM聯營共享ATM銀行提供銀行計算機ATM與中央計算機通信銀行有出納工作站出納工作站與銀行計算機通信銀行雇傭出納員.............共96頁第57頁動詞詞組：網絡包括柜員機和自動取款機（ATM）(ATM)由聯營機構共享每個銀行提供各自的計算機計算機來維護它的帳戶計算機處理面臨的事務柜員機屬于各銀行柜員機直接與銀行計算機通信柜員輸入帳務柜員處理數據ATM與中心處理機通信。中心處理機分理事務到相應的銀行ATM接收現金卡ATM與用戶交互ATM與中心計算機通信，完成事務處理ATM與中心計算機通信，分配現金ATM與中心計算機通信，打印收據系統(tǒng)控制并發(fā)訪問銀行提供軟件銀行根據現金卡數量來分擔費用隱含的動詞詞組：聯營機構擁有中心處理機銀行保存帳目用戶擁有現金卡銀行組成聯營機構ATM處理遠程業(yè)務從問題域的知識中得到的動詞詞組：用戶擁有現金卡現金卡中存儲現金帳目銀行雇傭柜員共96頁第58頁聯營機構由銀行組成銀行擁有柜員機柜員機上有柜員業(yè)務柜員業(yè)務涉及帳戶銀行雇傭柜員柜員輸入柜員業(yè)務聯營機構擁有中心處理機中心處理機與ATM通信

ATM處理遠程業(yè)務遠程業(yè)務涉及帳戶帳戶保存在銀行計算機帳戶由現金卡存取帳戶擁有現金卡遠程業(yè)務由現金卡授權處理中心處理機與銀行計算機通信銀行擁有銀行計算機銀行計算機與多臺柜員機通信最終的關聯：共96頁第59頁3.3.1OMT——ATM網絡系統(tǒng)

建立關聯由...組成持有通信擁有通信通信擁有雇傭涉及存取有被授權進入被進入擁有進入銀行聯營中央計算機ATM遠程業(yè)務出納業(yè)務現金卡銀行代碼出納工作站出納員銀行計算機發(fā)行帳戶擁有客戶涉及共96頁第60頁3.3.1OMT——ATM網絡系統(tǒng)

建立關聯由...組成持有通信擁有通信通信擁有雇傭涉及存取有被授權進入被授權擁有進入銀行聯營中央計算機ATM遠程業(yè)務出納業(yè)務現金卡銀行代碼出納工作站出納員銀行計算機發(fā)行帳戶擁有客戶涉及共96頁第61頁3.3.1OMT——ATM網絡系統(tǒng)

2、對象模型：識別屬性屬性通常對應于所有格短語修飾的名字汽車的顏色是藍色的，光標的位置是...，xxx的出生年月，xxx的身高是...屬性眾多，只需考慮與特殊應用直接相關的屬性，其他待以后添加共96頁第62頁3.3.1OMT——ATM網絡系統(tǒng)

添加屬性由...組成持有通信擁有通信通信擁有雇傭涉及存取有被授權進入被進入擁有進入銀行名稱聯營中央計算機ATM現有現金遠程業(yè)務種類日期總數出納業(yè)務種類日期總數現金卡密碼卡片代碼帳戶代碼銀行代碼站代碼出納工作站站代碼雇員代碼出納員姓名銀行計算機發(fā)行站代碼帳戶余額信貸限制類型銀行代碼擁有客戶名稱地址涉及共96頁第63頁3.3.1OMT——ATM網絡系統(tǒng)

用繼承性改進由...組成持有通信擁有通信通信擁有雇傭涉及存取有被授權進入被進入擁有進入銀行名稱聯營中央計算機ATM現有現金遠程出納業(yè)務本地出納業(yè)務現金卡密碼卡片代碼帳戶代碼銀行代碼站代碼出納工作站站代碼雇員代碼出納員姓名銀行計算機發(fā)行站代碼帳戶余額信貸限制類型銀行代碼擁有客戶名稱地址出納業(yè)務種類日期總數進入工作站共96頁第64頁3、動態(tài)模型：ATM通常情況下的腳本腳本：1）ATM要求用戶插入一張現金卡；用戶插入一張現金卡2）ATM接收磁卡并讀其序號3）ATM要求密碼；用戶輸入密碼4）ATM通過聯營機構核實序號和密碼：聯營機構聯系對應的營業(yè)部鑒別密碼后通知該ATM5）ATM要求用戶選擇業(yè)務方式（提款、匯兌、查詢）；用戶選擇提款方式6）ATM詢問現金數額；用戶輸入現金數額7）ATM核實數額范圍：提交聯營機構，將業(yè)務傳送給營業(yè)部，確認成交返回帳戶新余額8）ATM分配現金并要求用戶提款；用戶取走現金9）ATM詢問用戶是否要繼續(xù)提款；用戶表示否定10）ATM打印收據、退出現金卡并提示用戶拿走，用戶得到現金卡11）ATM要求另一個用戶插入現金卡3.3.1OMT——ATM網絡系統(tǒng)

共96頁第65頁3.3.1OMT——ATM網絡系統(tǒng)3、動態(tài)模型：有例外情況的ATM腳本腳本：1）ATM要求用戶插入一張現金卡；用戶插入一張現金卡2）ATM接收磁卡并讀其序號3）ATM要求密碼；用戶輸入密碼4）ATM通過聯營機構核實序號和密碼，聯營機構聯系對應的營業(yè)部鑒別密碼后拒絕此密碼5）ATM提出密碼錯誤并要求用戶重新輸入，用戶輸入密碼，ATM通過聯營機構核實成功6）ATM要求用戶選擇業(yè)務方式（提款、匯兌、查詢）；用戶選擇提款方式7）ATM詢問現金數額；用戶改變想法，輸入“取消”8）ATM退出現金卡并提示用戶拿走，用戶得到現金卡9）ATM要求另一個用戶插入現金卡共96頁第66頁客戶ATM聯營機構銀行營業(yè)部插入銀行卡要求密碼輸入密碼驗證帳號與銀行驗證卡銀行帳戶合法帳戶合法要求業(yè)務種類輸入業(yè)務種類要求金額總數輸入金額總數分配現金要求取走現金詢問繼續(xù)打印收據回答“終止”

退出銀行卡取走銀行卡顯示主屏處理業(yè)務業(yè)務成功處理銀行業(yè)務業(yè)務處理成功3、動態(tài)模型：取款事件蹤跡圖共96頁第67頁ATM對象狀態(tài)圖

3、動態(tài)模型：不可讀的do：不可讀的卡片信息

do：核實帳戶

取消do:取消消息do：請求業(yè)務種類

do：請求總金額

do：業(yè)務處理中斷do:取消消息等待網絡響應

主屏do:顯示主屏卡片彈出do：彈出卡片要求取走卡片

結束do：打印收據do：請求繼續(xù)do：分配現金請求取走現金

do:非法帳戶信息do：請求密碼do：失敗信息插卡[可讀]

錯誤密碼鍵入密碼

取消帳戶合法鍵入業(yè)務種類插卡[不可讀]

取消取消取消帳戶非法鍵入總數業(yè)務失敗取消業(yè)務成功取現金終止取消繼續(xù)網絡響應取卡其中：網絡響應=合法帳戶、非法帳戶、非法營業(yè)部代碼、非法密碼、業(yè)務成功、業(yè)務失敗等待5秒共96頁第68頁3、動態(tài)模型：聯營機構對象狀態(tài)圖

do：驗證銀行營業(yè)部代碼do：與銀行驗證現金卡do：處理銀行營業(yè)部業(yè)務

業(yè)務處理業(yè)務失敗業(yè)務成功核實帳戶[合法代碼]合法密碼非法營業(yè)部密碼/非法密碼非法營業(yè)部帳戶/非法帳戶非法營業(yè)部代碼共96頁第69頁3、動態(tài)模型：銀行營業(yè)部對象類狀態(tài)圖do：驗證卡號do：與銀行驗證現金卡do：修改帳目處理營業(yè)部業(yè)務[失敗]/營業(yè)部業(yè)務失敗[成功]/營業(yè)部業(yè)務成功驗證營業(yè)部代碼[有效]合法營業(yè)部帳戶

非法營業(yè)部帳戶[無效]/營業(yè)部代碼共96頁第70頁4、函數模型:

ATM系統(tǒng)的輸入和輸出值現金卡客戶ATM密碼業(yè)務種類帳戶類型金額總數現金收據提示信息營業(yè)部代碼卡片代碼系統(tǒng)邊界共96頁第71頁4、函數模型:

ATM系統(tǒng)的頂層數據流圖現金卡讀入數據完成業(yè)務用戶現金收據提示信息密碼業(yè)務種類帳戶類型金額總數營業(yè)部代碼卡代碼帳目余額產生輸出共96頁第72頁4、函數模型:完成業(yè)務的處理數據流程選擇營業(yè)部選擇卡驗證密碼選擇帳戶聯營營業(yè)部代碼

卡代碼密碼

帳戶類型

總數，業(yè)務種類

帳戶

修改帳目現金，收據業(yè)務失敗

帳戶非法密碼卡授權

非法營業(yè)部代碼無效卡代碼非法帳戶共96頁第73頁3.3.1OMT——ATM網絡系統(tǒng)4、函數模型:函數模型的操作說明對應完成業(yè)務的處理數據流程中的修改帳目處理：

修改帳目（帳戶，金額總數，業(yè)務種類）現金，收據，通信如果提取之值超過帳目余額，禁止該項業(yè)務且不分發(fā)現金。如果提取值不超過帳目余額，記入借方帳且分發(fā)所需現金。如果是一個儲蓄業(yè)務，記入貸方帳且不分發(fā)現金。任何情況下接受并顯示ATM號碼，日期，時間，帳戶號碼業(yè)務種類，處理金額（若有），新余額。共96頁第74頁3.3.1OMT——ATM網絡系統(tǒng)5、系統(tǒng)設計：ATM系統(tǒng)的結構用戶

ATM現金卡業(yè)務站代碼業(yè)務柜員柜員機帳目客戶卡授權業(yè)務網絡連接網絡連接聯營機構營業(yè)部代碼共96頁第75頁3.3.1OMT——ATM網絡系統(tǒng)5、系統(tǒng)設計說明：1）ATM系統(tǒng)軟件總體結構：交互式界面和事務處理型系統(tǒng)的混合體。用分析模型表示系統(tǒng)的總體結構包括：對象模型——表示事務處理的各部分。動態(tài)模型——說明系統(tǒng)固有的分布形式及并發(fā)訪問的處理過程。函數模型——數據輸入/輸出及轉換。2）ATM系統(tǒng)分為三個系統(tǒng)層次：

ATM事務處理層營業(yè)部事務處理層聯營機構事務處理層共96頁第76頁3.3.1OMT——ATM網絡系統(tǒng)

5、系統(tǒng)設計說明：3）ATM系統(tǒng)構成一個簡單的星型拓撲結構。4）事務處理的數據庫在營業(yè)部計算機中集中存放?？杀欢鄠€并發(fā)的ATM通過聯營機構確定連接訪問。數據處理是單一的批處理型系統(tǒng)（指一個帳號被封鎖直到處理結束）。5）聯營計算機通過電話線與各營業(yè)部計算機連接。并通過站代碼和營業(yè)部代碼區(qū)分ATM業(yè)務到營業(yè)部的業(yè)務處理。

共96頁第77頁3.3.1OMT——ATM網絡系統(tǒng)

5、系統(tǒng)設計說明：

6）每一時刻ATM上只有一個業(yè)務活動，聯營計算機和營業(yè)部計算機可同時處理多個并發(fā)的業(yè)務活動。一個業(yè)務通過三個物理片段來完成，缺一不可。7）系統(tǒng)應該具有增加和刪除ATM和營業(yè)部處理層的能力。8）系統(tǒng)的安全保證至關重要。必須包括：存取權限、數據一致性保證、出錯處理等解決方案。共96頁第78頁3.3.1OMT——ATM網絡系統(tǒng)6、對象設計:

對象設計的步驟：（此過程反復迭代進行）

組合三個模型

為實現設計算法

優(yōu)化數據存取路徑

調整類結構及關聯

封裝類為模塊

設計主控程序路徑共96頁第79頁ATM

主

控

程

序

路

徑

設

計

主屏

請求密碼驗證帳戶請求類型（業(yè)務）請求輸入金額數

處理業(yè)務分發(fā)現金繼續(xù)否結束

彈出卡

取走卡終止繼續(xù)失敗輸入業(yè)務類型號成功合法帳戶

輸密碼插入卡

非法帳戶

取現金6、對象設計:共96頁第80頁3.3.1OMT——飲料自動售貨機

一、問題描述：設置

一個飲料自動售貨機可以放置五種不同或部分相同的飲料，可由廠商根據銷售情況自行調配，并可隨時重新設置售價，但售貨機最多僅能放置50罐飲料，其按鈕設計在各種飲料樣本的下方，若經金額計算器累計金額足夠，則選擇鍵燈會亮；若某一種飲料已銷售完畢，則售完燈會亮。共96頁第81頁3.3.1OMT——飲料自動售貨機銷售

顧客將硬幣投入售貨機，經累加金額足額的飲料選擇鍵燈亮，等待顧客按鍵選擇。顧客按鍵后飲料由取物口掉出，并自動結算及找零。取消交易

顧客可在按下選擇鍵前任何一個時刻，拉動退幣桿取消交易，收回硬幣。共96頁第82頁3.3.1OMT——飲料自動售貨機二、系統(tǒng)分析1、對象模型：尋找對象：顧客(customer)、售貨機(machine)、金額計算器(account)、選擇鍵(button)、退幣桿(bar)、存量計算器(caculator)確定類及關聯的屬性數據共96頁第83頁3.3.1OMT——飲料自動售貨機

屬于

金額計算器

金額

累加找零重置屬于

販賣機飲料號碼飲料價格接受投幣飲料掉出金額顯示按鈕退幣售完顯示

存量計算器飲料號碼存量

遞減售完顯示重置

退幣桿

退幣桿狀態(tài)

拉動

選擇扭

選擇扭狀態(tài)

燈亮燈熄售完燈亮按鈕

顧客

姓名，硬幣

投幣拿取飲料屬于屬于拉動選取對象模型：共96頁第84頁3.3.1OMT——飲料自動售貨機數據字典顧客：是個別的消費者，持有硬幣，擁有飲料及交易成交與否的選擇權售貨機：在顧客投入硬幣時，判斷硬幣是否有效及金額的面值，累加后顯示，待顧客按下選擇鍵后掉出飲料金額計算器：將投入的硬幣依序完成累加，并不斷將結果傳回售貨機顯示選擇鍵：不同飲料有不同價格，待金額計算器累加到該飲料售價時則該選擇鍵燈亮時，顧客按下后將選擇傳回售貨機共96頁第85頁3.3.1OMT——飲料自動售貨機退幣桿：在顧客按下選擇鍵完成交易前，若拉動退幣桿則將所有金額退還顧客存量計算器：售貨機掉出飲料后，存量計算器則將該種飲料的存量遞減，并同時判斷是否為0，若售完燈亮時，顯示無存量，否則繼續(xù)成備用狀態(tài)共96頁第86頁3.3.1OMT——飲料自動售貨機2、動態(tài)模型：事件蹤跡圖顧客售貨機金額計算器選擇鍵存量計算器售完燈燈亮累加選擇按鍵總額顯示總額選擇鍵號飲料結算余額找零扣減存量存量為零燈亮投入硬幣共96頁第87頁3.3.1OMT——飲料自動售貨機2、動態(tài)模型：販賣機狀態(tài)圖初態(tài)do:顯示售貨機在備用所有燈都關閉do:顯示金額總數do:顯示總額已夠/飲料選擇燈亮取出飲料/結算找零扣減存量/完成交易飲料“售完”燈亮投入硬幣（有效的）按下選擇飲料鍵存量為零返回備用狀態(tài)返回備用狀態(tài)取消取消/無效硬幣投入硬幣（有效的）金額不足再投幣有足夠金額共96頁第88頁3.3.1OMT——飲料自動售貨機3、功能模型：販賣機輸入、輸出數據顧客自動售貨機投幣、按鍵選擇、取消交易顯示投幣金額總數、選擇鍵燈亮、輸出飲料、找零、售完燈亮系統(tǒng)邊界共96頁第89頁3.3.1OMT——飲料自動售貨機3、功能模型：數據流程圖顧客計算并判斷是否售完執(zhí)行交易產生輸出獲得投幣輸入計算顧客投入硬幣選擇飲料按鈕送出信息，輸出飲料，找零共96頁第90頁3.3.1OMT——飲料自動售貨機三、系統(tǒng)設計

系統(tǒng)結構設計對象設計共96頁第91頁3.3.2OOD（ObjectOrientedDesign)OOD方法的過程包括以下步驟：在給定的抽象層次上識別類和對象識別這些對象和類的語義識別這些類和對象之間的關系實現類和對象

不斷細化的迭代和漸增的開發(fā)過程共96頁第92頁3.3.3RDD（ResponsibilityDrivenDesign)RDD方法探索階段和精化階段探索階段確定類－>確定類的責任—>確定類間的合作精化階段精化類繼承層次－>確定子系統(tǒng)－>確定協(xié)議CRC卡(classresponsibilitycollaboration)共96頁第93頁3.3.3RDD（ResponsibilityDrivenDesign)

共96頁第94頁3.3.3OOAD嚴格區(qū)分面向對象分析OOA和面向對象設計OODOOA—確定類及對象—識別結構—定義主題—定義屬性—定義服務共96頁第95頁3.3.3OOADOOD—設計問題域（細化分析結果）—設計人機交互部分（設計用戶界面）—設計任務管理部分（確定系統(tǒng)資源分配）—設計數據管理部分（依賴于存儲技術）共96頁第96頁3.3.4OOSE涉及到整個軟件生命周期，包括需求分析、設計、實現和測試等四個階段。從usecase的描述發(fā)現設計對象，并描述對象的屬性、行為和關聯。把usecase的行為分派給對象。共96頁第97頁3.3.4OOSE領域對象模型。usecase模型根據領域來表示。分析模型。usecase模型通過分析來構造。設計模型。usecase模型通過設計來具體化。實現模型。該模型依據具體化的設計來實現usecase模型。測試模型。用來測試具體化的usecase模型。共96頁第98頁3.4可視化建模技術（VMT）VMT以OMT為骨架，繼承了OMT、OOSE、RDD、CRC、事件蹤跡圖等面向對象分析方法的優(yōu)點。OMT的缺點：對于需求分析階段的技術支持不夠，無方便而有效的機制支持和描述需求分析初期與用戶的高層次交流

VMT在此方面引入OOSE的用例方法分析的重點在類之間的關系上，對于每個類的屬性和方法以及每個類對整個系統(tǒng)功能的貢獻沒有有力的支持，很難從從功能模型過渡到單個對象功能分析與設計

VMT引入RDD的CRC方法，定義類的責任和合作共96頁第99頁參與者： 透過系統(tǒng)邊界，與系統(tǒng)進行交互的事物系統(tǒng)邊界： 一個系統(tǒng)所包含的所有系統(tǒng)組成部分與系統(tǒng)以外各種事物的分界線 被開發(fā)的計算機軟硬件，而不是泛指問題空間的全部事物所構成的現實系統(tǒng)在OOA和OOD中定義，并在編程時加以實現的系統(tǒng)元素3.4可視化建模技術（VMT）共96頁第100頁參與者1參與者2事務處理1事務處理2事務處理3系統(tǒng)3.4可視化建模技術（VMT）用例：獲得某項服務時參與者與系統(tǒng)之間進行的交互序列。用例的描述沒有統(tǒng)一的規(guī)范，應在開發(fā)組內形成一個統(tǒng)一的風格。

收款員.收款

……for

顧客選購的每個商品do

輸入商品編號endfor

……用于描述系統(tǒng)功能從而給出用戶需求模型共96頁第101頁預定刪除預定借出書目返還書目增加標題刪改標題增加書目刪除書目增加借書者刪改借書者維護圖書管理員借書者圖書管理員圖書館信息系統(tǒng)3.4可視化建模技術（VMT）用例·借出書目1.如果借書者沒有預定：

a.標記標題

b.標記可用的該題目下的書目

c.標記借書者

d.圖書館借出標記的書目2.如果借書者已經預定：

a.標記借書者

b.標記標題

c.標記可用的該題目下的書目

d.圖書館借出標記的書目

e.增加一條新的借書記錄

f.刪除預定記錄共96頁第102頁關于CRC卡：Class:

本地出納業(yè)務ResponsibilitiesCollaorator身份驗證出納員，出納工作站存取款單填寫出納員工作站提交出納工作站3.4可視化建模技術（VMT）共96頁第103頁3.4可視化建模技術（VMT）3.4.1.VMT的分析過程根據初始需求文檔，在用戶參與下，定義參與者和用例，使用可視化工具建立GUI原型根據問題陳述和用例模型，建立初始對象模型。該模型概要給出了描述問題域應用語義的類以及這些類間關系和原始屬性初始對象模型，用例以及GUI原型一起表達了問題的需求模型。定義了系統(tǒng)的邊界及附加接口。建立CRC卡。確定各個類的責任，明確對象模型中各對象的服務和屬性，根據CRC卡中類之間的合作方式，可以重新定義和精化類之間的關系參照對象模型，從用例和服務建立事件蹤跡圖和狀態(tài)圖描述系統(tǒng)的動態(tài)特性。目的、任務……共96頁第104頁3.4可視化建模技術（VMT）3.4.2.VMT的設計過程系統(tǒng)設計、對象設計、持久對象設計目的、任務……高層系統(tǒng)決策基礎軟件系統(tǒng)結構解決方案結構化精化對象模型選擇實際的實現環(huán)境識別附加對象類尋找可復用部件對象的存儲方式與數據庫的接口共96頁第105頁3.4可視化建模技術（VMT）在全球范圍擁有支行的銀行向顧客提供各種服務，例如自動取款機、信用卡和外幣現金兌換(FCE)。FCE應用系統(tǒng)按照當前的匯率向顧客提供交易現金和旅行支票服務