第9章 領域模型

1、1第9章 領域模型Domain Model2領域模型 領域模型是對領域內的概念類或現(xiàn)實中對象的可視化表示 領域模型也稱為概念模型、領域對象模型和分析對象模型 領域模型是可以在業(yè)務建?？颇恐袆?chuàng)建的制品之一 領域模型是UP業(yè)務對象模型(BOM)的特化3領域模型 領域模型是OO分析中最重要的和經(jīng)典的模型。 確定一組概念類是OO分析的核心。（每次早期迭代不超過幾個小時的時間來完成這項工作） 領域模型的范圍限定于當前迭代所開發(fā)的用例場景，通過迭代不斷演進。 領域模型與其它制品的關系見圖9-1 領域模型的示例見圖9-24圖9-1 UP制品樣例的影響5圖9-2 部分領域模型：可視化字典6領域模型是軟件業(yè)務對

2、象圖嗎圖9-3 領域模型表示真實世界概念的可視化并非表示軟件類在UML中，領域模型被描述為一組沒有定義操作的類圖7圖9-4 領域模型并非表示軟件制品或類8“領域模型”的兩個傳統(tǒng)含義 含義一：領域模型是現(xiàn)實世界中對象的概念透視圖，而非軟件透視圖 含義二：軟件對象的領域層。在表示層之下的軟件對象層是由領域對象組成的。領域對象是表示問題領域空間事物的軟件對象，并且與“業(yè)務邏輯”或“領域邏輯”方法相關 在本書中，用領域層(domain layer)來表示第二種含義9什么是概念類 概念類是思想、事物或對象。更正式地講，概念類可以從其符號、內涵和外延來考慮。圖9-5 概念類具有符號、內涵和外延10領域模型

3、和數(shù)據(jù)模型是一回事嗎 領域模型不是數(shù)據(jù)模型（持久化數(shù)據(jù)） 在領域模型中不會排除沒有明確要求記錄其相關信息的類，也不會排除沒有屬性的概念類 在領域內充當純行為角色而不是信息角色的概論類也是有效的。11動機：為什么要創(chuàng)建領域模型 理解關鍵概念和詞匯12動機：降低與OO建模之間的表示差異圖9-6 OO建模減小了表示差異13如何創(chuàng)建領域模型1. 尋找概念類2. 將其繪制為UML類圖中的類3. 添加關聯(lián)和屬性14如何找到概念類 找到概念類的三條策略 重用和修改現(xiàn)有模型。 在許多常見領域中都存在已發(fā)布的，繪制精細的領域模型和數(shù)據(jù)模型 使用分類列表（見P104表9-1） 確定名詞短語。將對領域的文本描述中的

4、名詞和名詞短語作為候選的概念類或屬性。（見P106用例的文本描述）15示例：尋找和描述概念類(NextGen POS） 根據(jù)分類列表衙名詞短語分析，可以得到該領域候選概念類的列表 根據(jù)迭代1所考慮的需求和簡化的處理銷售用例，即基本的現(xiàn)金交易場景，可以得到如P107所示的候選概念類的列表。 沒有什么所謂“正確”列表。上述列表中的抽象事物和領域詞匯在一定程度上是隨意收集的，但都是建模者認為重要的。 實踐中，可以不會創(chuàng)建文本列表，而是直接繪制成UML類圖。見圖9-7.16StoreRegisterSaleItemCashPaymentSalesLineItemCashierCustomerProdu

5、ctCatalogProductDescriptionLedger圖9-7 初始的POS領域模型17案例：Monopoly領域圖9-8 初始的Monopoly領域模型18準則：敏捷建模-繪制類圖的草圖 注意圖9-8中UML類圖的風格，讓類框的底部和右側呈開放狀態(tài)，以方便擴展。19準則：敏捷建模-是否要使用工具維護模型 在后期的草圖設計中或編程中發(fā)現(xiàn)新的概念類，是否需要更新早期的概念模型？視情況而定 通常，進化的軟件領域層對大部分重要術語會給予提示，而且長生命期的OO分析領域模型不會增加價值。20準則：報表對象-模型中是否要包括“票據(jù)” 一般來說，在領域模型中顯示其它信息的報表并沒有意義，因為其

6、所有信息都是源于或復制于其他信息源的。這是排除它的理由 另一方面，就業(yè)務規(guī)則而言，票據(jù)有特殊的作用：通常持有（紙質）票據(jù)的人有退貨的權利。這是在模型中要表示它的原因在本次迭代中沒有考慮退貨，所以不應包括票據(jù)。在解決“處理退貨”用例的迭代中，再考慮將其包含在內。21準則：像地圖繪制者一樣思考：使用領域術語 使用地域中現(xiàn)有的名稱。在圖書館模型中，將顧客命名為“借書者”、“贊助者”等，這是圖書館職員使用的術語。 排除無關或超出范圍的特性 不要憑空增加事物22準則：如何對非現(xiàn)實世界建模 有些軟件系統(tǒng)的領域與自然領域或業(yè)務領域幾乎沒有類似之處，例如：電信軟件。 此時需要高度的抽象，對常見的非OO設計進行

7、回顧，并且認真汲取領域專家所使用的核心詞匯和概念。 例如，電信軟件的候選概念類：消息、連接、端口、會話、路由、協(xié)議。23準則：屬性與類的常見錯誤 常見錯誤：把應該是概念類的事物表示為屬性 判別準則：如果我們認為某概念類X不是現(xiàn)實世界中的數(shù)字或文本，那么X可能是概念類而不是屬性。SalestoreSaleStorephoneNumberFlightdestinationFlightAirportname或?或?24準則：何時使用“描述”類建模 描述述(description class)包含描述其它事物的信息。如：ProductDescription記錄Item的價格、圖片和文字描述。命名方式：

8、項目-描述符25 準則：何時需要描述類準則：何時需要描述類1.需要有關商品或服務的描述，獨立于任何商務或服務現(xiàn)有實例2.刪除其所描述事物(如Item)的實例后，導致信息丟失，而這些信息是需 要維護的，但是被錯誤地與所刪除的事物關聯(lián)起來3.減少冗余或重復信息圖9-9 關于其它事物的描述26示例：航空領域中的描述圖9-10 對其它事物的描述27關聯(lián)(association) 關聯(lián)是類（更精確也說，是這些類的實例）之間的關系，表示有意義和值得關注的連接。 在UML中，關聯(lián)被定義為“兩個或多個類之間的語義聯(lián)系，涉及這些類元實例之間的連接。圖9-11 關聯(lián)28準則：何時表示關聯(lián) 在領域模型中要考慮如下關

9、聯(lián)： 如果存在需要保持一段時間的關系，將這種語義表示為關聯(lián)（“需要記住”的關聯(lián)）。 從常見關聯(lián)列表中派生的關聯(lián)（見P115表9-2）29準則：為什么應該避免加入大量關聯(lián) 節(jié)點間可以有(n*n(n-1)/2個關聯(lián) 太多關聯(lián)，會產生“視覺干擾，使圖變混亂。 要謹慎地增加關聯(lián)線，并重點關注”需要記住“的關聯(lián)。30觀點：關聯(lián)是否會在軟件中實現(xiàn) 在領域建模中，關聯(lián)不是關于數(shù)據(jù)流、數(shù)據(jù)庫外鍵聯(lián)系、實例變量或軟件方案中的對象連接語句；關聯(lián)聲明是針對現(xiàn)實領域從純概念角度看有意義的關系。 這些關系的大部分將作為（設計模型和數(shù)據(jù)模型中的）導航和可見性路徑在軟件中加以實現(xiàn)。31應用UML:關聯(lián)表示法圖9-12 關聯(lián)

10、的UML表示法32準則：在UML中如何對關聯(lián)命名 以“類名-動詞短語-類名”的格式為關聯(lián)命名，其中的動詞短語構成了可讀的和有意義的順序。 例 Sale paid-by CashPayment 反面示例（動詞短語沒有增加意義），Sale Uses CashPayment Player is-on Square 反面示例（動詞短語沒有增加意義），Player Has Square 關聯(lián)名首字母應該大寫，因為關聯(lián)表示的是實例之間鏈接的類元。33應用UML：角色 關聯(lián)的每一端稱為角色(role)。角色具有如下可選項 多重性表達式 名稱 導航34應用UML：多重性圖9-13 關聯(lián)的多重性圖9-14 多重

11、性的取值多重性(mumltiplicity)定義了類A有多少個實例可以和類B的一個實例關聯(lián)35多重性是和語境有關的圖9-15 多重性是和語境有關的36應用UML：兩個類之間的多重關聯(lián)FlightAirportFlies-toFlies-from*11圖9-16 多重關聯(lián)37示例：NextGen POS中的關聯(lián)RegisterItemStoreSaleCashPaymentSalesLineItemCashierCustomerProductCatalogProductDescriptionStocks*Houses1.*Used-by*Contains1.*Describes*Captured

12、-onContained-in1.*Records-sale-of 0.1Paid-byIs-forLogs-completed* Works-on11111.*11111110.111LedgerRecords-accounts-for11圖9-17 NextGen POS部分領域模型38示例：Monopoly中的關聯(lián)圖9-18 Monopoly部分領域模型39屬性 屬性(attribute)是對象的邏輯數(shù)據(jù)值 確定概念類的屬性是有助的，能夠滿足當前所開發(fā)場景的信息需求。40準則：何時展示屬性 當需求(例如：用例)建議或暗示需要記住信息時，引入屬性。41應用UML：屬性表示法圖9-19 類和

13、屬性42更多表示法圖9-20 UML屬性表示法在UML中，屬性的完整語法是：visibility name:type multiplicity = default property-string43準則：在哪里記錄屬性需求 middleName:0.1等是嵌入到領域模型的需求或領域規(guī)則 建議把所有這種屬性需求置于UP詞匯表中（UP詞匯表可充當數(shù)據(jù)字典）44導出屬性圖9-21 在銷售項目中記錄售出的商品數(shù)量45準則：什么樣的屬性類型是適當圖9-22 使用關聯(lián)而不是屬性表示關系領域模型中屬性的類型更應該是數(shù)據(jù)類型。十分常見的數(shù)據(jù)類型包括：Boolean,Date,Number,Character,

14、String, Time等，其它常見的類型有Address,Color,Geometrics,Phone Numer,Social Security Number,Universal Product Code(UPC),SKU,ZIP，枚舉類型等46準則：何時定義新的數(shù)據(jù)類型類 見P120表9-347準則：通過關聯(lián)而不是屬性來表示概念類之間的關系圖9-23 不要用屬性表示復雜概念48應用UML：在何處描述這些數(shù)據(jù)類型類OKOKProductDescriptionProductDescriptionitemId : ItemID1StoreStoreaddress : Address111Ite

15、mIDidmanufacturerCodecountryCodeAddressstreet1street2cityName.圖9-24 表示對象的數(shù)據(jù)類型特性的兩種方式49準則：任何屬性都不表示外鍵圖9-25 不要將屬性作為外鍵可以用許多方法來表示對象之間的關系，外鍵是其中的一種50準則：對數(shù)量和單位建模圖9-26 對數(shù)量建模51示例：NextGen POS中的屬性RegisteridItemStorenameaddressSaledateTime/ totalCashPaymentamountTenderedSalesLineItemquantityCashieridCustomerProductCatalogProductDescriptionitemIDdescriptionpr