面向對象設計類圖設計

系統(tǒng)規(guī)劃部面向對象設計_類圖設計2023/2/61主要內容類相關的基本概念使用UML的類圖設計類圖設計的一些問題分析繼承關系的分析對象持久化－與E-R模型的映射類設計相關的一些設計模式類圖設計應用－信息模型建模過程及方法2023/2/62類相關的基本概念迎接挑戰(zhàn)，共創(chuàng)成功！2023/2/63對象和類對象（Object）：對象是指某個事物，大多對應于真實世界中的某個客觀實體；但有些對象在真實世界中沒有直接的對應物，是人們對某個事物的一種抽象描述。對象的基本特征可以歸納為對象的屬性和行為兩類。類（Class）：類是指對一組具有相同特征的對象的抽象描述；任何對象都是某個類的實例。2023/2/64例:客戶類的表示客戶姓名單位電話Email客戶姓名單位電話Email客戶付款(金額)客戶付款(金額)2023/2/65類圖和對象圖類圖描述系統(tǒng)中的類及其相互之間的各種關系，反映了系統(tǒng)中包含的各種對象的類型以及對象間的各種靜態(tài)關系，主要是：關聯(lián)和子類型。類圖也可描述類的屬性和行為以及對模型中各種成分的約束。對象圖是類圖的實例，描述系統(tǒng)中各種對象(類的實例)以及對象之間的各種靜態(tài)關系。2023/2/66使用UML的類圖設計迎接挑戰(zhàn)，共創(chuàng)成功！2023/2/67使用UML的類圖設計類設計的相關UML元素類屬性操作接口關聯(lián)聚合繼承（泛化）包的使用2023/2/68類實體名稱實體方法可見性實體屬性類是對同一種類型的對象的抽象表示2023/2/69屬性UML規(guī)定其語法為：可見性名稱:類型=缺省值{約束特性}描述屬性的元素可見性：表示該屬性對類外的元素是否可見。常用的有公有、受保護和私有三種。名稱：屬性的名稱，是一個字符串。類型：定義屬性的種類(基本數據類型或用戶自定義的類型)。缺省值：屬性的初始值。約束特性：描述對屬性的約束。2023/2/610操作UML規(guī)定其語法為可見性名稱(參數表):返回類型表達式{約束特性}描述操作的元素可見性：“+”表示公有操作，“#”表示受保護的操作，“-”表示私有操作。名稱：操作的名稱，是一個字符串。參數表：其語法與屬性的參數相同，參數個數是任意的。返回類型表達式(可選項)：依賴于語言的描述。約束特性：用以描述對此操作的約束。2023/2/611可見性對“Public”、Private”和“Protected”等三個可見性標識符的含義，各種語言都有它自己的規(guī)定。UML的定義是：+(Public)：公有成員在程序的任何位置都是可見的，系統(tǒng)中的任何對象都可以使用它。-(Private)：私有成員僅可以由定義它的類使用。#(Protected)：受保護的成員僅可以由定義它的類和該類的子類中的對象使用。2023/2/612接口接口和類不同：一個類可以有它形態(tài)的真實實例，然而一個接口必須至少有一個類來實現(xiàn)它。2023/2/613關聯(lián)關聯(lián)用于描述類之間的關系每個關聯(lián)有兩個角色。例如，對于客戶和訂單之間的關聯(lián)是：客戶和訂單。關聯(lián)名稱關聯(lián)基數(Cardinality)關聯(lián)基數(Cardinality)關聯(lián)實體，描述關聯(lián)的屬性、方法2023/2/614關聯(lián)的分類雙向關聯(lián)單向關聯(lián)關聯(lián)類聚合基本聚合組合聚合自關聯(lián)（反射關聯(lián)）2023/2/615雙向關聯(lián)關聯(lián)是兩個類間的聯(lián)接。在Rose中關聯(lián)總是被假定是雙向的；這意味著，兩個類彼此知道它們間的聯(lián)系，除非你限定一些其它類型的關聯(lián)。2023/2/616單向關聯(lián)在一個單向關聯(lián)中，兩個類是相關的，但是只有一個類知道這種聯(lián)系的存在。下圖顯示單向關聯(lián)的透支財務報告的一個實例。2023/2/617關聯(lián)類在關聯(lián)建模中，在一些情況下，需要包括其它類，因為它包含了關于關聯(lián)的有價值的信息。對于這種情況，需要使用關聯(lián)類來綁定你的基本關聯(lián)。關聯(lián)類和一般類一樣表示。不同的是，主類和關聯(lián)類之間用一條相交的點線連接。2023/2/618自關聯(lián)類自身的關聯(lián)，當一個類關聯(lián)到它本身時，這并不意味著類的實例與它本身相關，而是類的一個實例與類的另一個實例相關。2023/2/619聚合聚合是一種特別類型的關聯(lián)，用于描述“總體到局部”的關系。聚合分為兩種類型：基本聚合、組合聚合基本聚合在基本聚合關系中，部分類的生命周期獨立于整體類的生命周期。組合聚合在組合聚合關系中，部分類的生命周期依賴于整體類的生命周期。2023/2/620繼承在面向對象的設計中一個非常重要的概念，繼承，指的是一個類（子類）繼承另外的一個類（超類）的屬性和方法，并增加它自己的屬性和方法，或者覆蓋父類的屬性和方法類名BankAccount和withdrawal操作使用斜體。這表示，BankAccount類是一個抽象類，而withdrawal方法是抽象的操作。換句話說，BankAccount類使用withdrawal規(guī)定抽象操作，并且CheckingAccount和SavingsAccount兩個子類都分別地執(zhí)行它們各自版本的操作。然而，超類（父類）不一定要是抽象類。標準類作為超類是正常的。2023/2/621泛化（Generalization)泛化(Generalization):抽象化特化(Specialization):實例化繼承(Inheritance):泛化關系的一種實現(xiàn)機制2023/2/622繼承與泛化繼承是實現(xiàn)泛化的一種機制。在這種機制中，超類的任何一個子類都須具有其超類的所有行為：不僅要求其操作界面在文法上一致，而且要求其行為在語義上一致。當子類中的一個操作重載其超類中相應的操作時，必須確保它提供與超類中的操作相同的服務(內容可以更多或更具體)。如沒有證明子類的行為是否與父類相同，就試圖用繼承來實現(xiàn)新類中的行為，當兩者不一致時，會導致難以預測的錯誤。2023/2/623包的引入大系統(tǒng)將問題復雜化?！肮タ恕睆碗s問題的經典方法是“分而治之”。結構化方法采用功能分解來解決這個問題，但傳統(tǒng)的結構化方法將過程與數據分離。面向對象技術解決這個問題的基本思路是將許多類集合成一個高內聚、低耦合的類的集合。UML把這種分組機制稱為包。不僅類可以運用包的機制，任何模型元素都可運用包的機制。2023/2/624類關系中的依賴性UML指導將類組成包的原則是依賴性：設有兩個元素X、Y，如果修改(語法的或語義的)元素X的定義引起對元素Y的定義的修改，則稱元素Y依賴于元素X。類之間的依賴關系：CinheritsfromRAvariableinCisofclassRAmethodofCreceivesanargumentofclassRAmethodofCsendsamessagethatreturnsanargumentofclassRAmethodofChasalocalvariableofclassRCisa“friend”ofR2023/2/625包圖關系中的依賴性包圖顯示類的包以及這些包之間的依賴關系。它們都是類圖中的元素，因此包圖是另一種類圖。如果兩個包中的任意兩個類之間存在依賴關系，則這兩個包之間存在依賴關系。但包的依賴是不傳遞的。如圖示，訂單獲取應用包屏蔽了訂單包的變化對訂單獲取界面包的影響。2023/2/626類圖設計的幾點建議在項目初始階段，不要使用所有的符號，應從簡單的概念開始。不同的開發(fā)階段應用不同的觀點畫類圖：分析階段用概念層類圖；設計階段用設計層類圖。不要為每個事物都畫一個模型，應把精力放在關鍵的領域，畫幾張較為關鍵的圖，經常使用，不斷更新。使用類圖的最大危險是過早地陷入實現(xiàn)的細節(jié)，應將重點放在概念層。2023/2/627類圖設計的一些問題分析迎接挑戰(zhàn)，共創(chuàng)成功！2023/2/628內容提要使用繼承的一些問題分析對象的持久化，向E-R模型的映射2023/2/629使用繼承的一些問題分析許多人將繼承視為面向對象設計中最好的或最有力的方法因此在面向對象設計中，會盡量多的使用繼承來解決問題這會導致：繼承關系的不恰當使用子類不恰當的獲取父類的行為類的層次結構不靈活(Awkwardorrigid)難于維護下面列舉一些沒有正確使用繼承關系的例子2023/2/630繼承的問題分析1不正確的繼承關系將繼承改為關聯(lián)2023/2/631繼承的問題分析22023/2/632一個相似的例子2023/2/633問題在我們的應用中，房間是一個立方體我們需要記錄每個房間的長、寬、高在我們的類庫中已經有‘CUBOID’類設計為：CUBOID繼承的問題分析32023/2/634一種可行的設計

一種更為通用的設計繼承的問題分析3續(xù)2023/2/635繼承的問題分析42023/2/636對象模型向ER模型的映射對于實體類，一般會選擇關系數據庫做數據的存儲，因此會涉及對象模型如何向E-R模型轉換的問題：簡單關聯(lián)關系的映射繼承關系的映射聚合關系的映射2023/2/637簡單關聯(lián)關系的映射2023/2/638繼承關系的映射2023/2/639三種方案的進一步分析三種方案優(yōu)缺點的進一步分析：如果行數有限，那么優(yōu)先考慮將應用程序與將來可能的改變隔離開來，提供一個更為健壯的數據庫設計。因此方案1可能是最靈活的，但這個方案的性能是最差的（它涉及到許多連接）。如果超類中屬性數目與子類的數目相比較小，那么方案3可能是最謹慎的選擇。它可以提供比方案1更好的性能，以后擴展模型時添加更多的類也較為容易。如果子類中的數據量較少，那么方案2是最好的。該方案提供了最佳的性能，但其靈活性最差。2023/2/640聚合關系的映射在類圖中，聚合關系表示的是兩個類之間的整體與部分之間的關系。從本質上講，聚合關系是類之間的關聯(lián)關系的一種，在向E-R模型轉換時，與簡單關聯(lián)關系的映射規(guī)則相同。按照一對多的關系映射為E-R模型2023/2/641類設計相關的設計模式迎接挑戰(zhàn)，共創(chuàng)成功！2023/2/642類設計相關的設計模式模式是對特定環(huán)境下經常出現(xiàn)的有代表性的問題的通用核心解決方案，并且該方案可以被多次使用；設計模式可以幫助復用和溝通，可以提高信息模型的質量，使模型的結構更為合理，具有良好的適應能力，能夠可以提供可擴展的結構；在信息模型中使用的設計模式主要有：實體-實體規(guī)格分離模式角色對象模式模板模式合成模式實體屬性規(guī)格/實體屬性模式實體/實體狀態(tài)分離模式2023/2/643實體－實體規(guī)格分離模式將實體的不變的、相對固定的特性和行為與其可變的特性、行為分開定義。通過規(guī)格的定義，將通用的規(guī)則、屬性分離出來單獨定義，形成實體的模板。記錄某一類實體的通用屬性記錄某一實體的屬性2023/2/644模板模式將具有相同分類或特點的類中通用的屬性、方法抽象出來，形成抽象類作為父類，子類繼承和擴展父類的屬性、方法。在面向對象的建模中，抽象層次是非常重要的關于繼承模板模式是基于繼承的復用技術采用繼承的復用技術要比采用委托的復用技術耦合程度要高，使用繼承關系要謹慎2023/2/645模板模式的應用將子類與其它類的關聯(lián)關系中具有通用性的關聯(lián)抽象到父類與其它類的關聯(lián)，使實體之間的關聯(lián)關系更具有通用型和擴展性2023/2/646角色對象模式問題的引出：一些業(yè)務實體，需要扮演多個角色，如某個人可以是企業(yè)的客戶，同時又是企業(yè)的員工；某個公司可以是企業(yè)的客戶，同時也是企業(yè)的代銷商，也可以是企業(yè)的提供商，如何對這些關系進行建模，在信息模型中，采用實體、實體角色（角色對象）分離的模式來解決：實體是相對固定的，實體扮演的角色是可以獨立與實體靈活的變化和擴展2023/2/647角色對象模式的應用將與系統(tǒng)相關的個人、組織抽象成參與者，將參與者所扮演的角色用參與者角色表示，具體類型的角色使用子類來表示。2023/2/648合成模式合成模式又稱為部分－整體模式。合成模式將對象組織到樹結構中，可以用來描述整體與部分的關系。合成模式可以使客戶端將原子元素與復合元素同等看待。合成模式有安全式和透明式兩種。透明式的合成模式將原子元素與復合元素完全同等看待，定義同樣的接口，缺點是不夠安全；安全式的合成模式是將原子元素與復合元素區(qū)別對待，可以有不同的接口，缺點是不夠透明。2023/2/649合成模式的應用變更服務規(guī)格是服務規(guī)格的一種，如新裝、改名、過戶等。可以是原子的，也可以是組合的，但是通過服務規(guī)格將他們同等處理。2023/2/650實體屬性規(guī)格/實體屬性模式問題的引出：有些業(yè)務實體，如通信服務，不同的通信服務可以