文章目錄
領域模型
association vs attribute
association 用於實例之間關係,attribute則用於需要記住的信息
一般來說人們會比較實例的址而比較屬性的值
value object更像是data type
ID
考慮這樣的productId,由countryCode+manufacturaterCode+id組成,但是我覺得這樣的情況應該視爲邏輯編碼,除了用來查詢外不應當做唯一id使用,更加不能解析該id,因爲countryCode有可能改變(換了國家),另外manufacturaterCode沒有包含countryCode也是令人奇怪.
number attribute
一般來說涉及到數量的時候會有單位,典型的就是Money
示例
s:開始 r:精化
| 科目 | 製品 | 初始 | 細化 E1->En | 構造 C1-Cn | 移交 T1->Tn |
|---|---|---|---|---|---|
| 業務建模 | 領域模型 | s | |||
| 需求 | 用例模型 | s | r | ||
| 設想 | s | r | |||
| 補充性規格說明 | s | r | |||
| 詞彙表 | s | r | |||
| 設計 | 設計模型 | s | r | ||
| 軟件架構文檔 | s | ||||
| 數據模型 | s | r |
從理論的角度來看,理論與實踐應當是一致的
從實踐的角度來講,實踐與理論其實是不同的
概念分類列表
- 有形對象
CreditCard , Check- 事務
CashPayment , CreditPayment , CheckPayment- 其他外部的計算機或機電系統
CreditAuthorizationService- 抽象名詞概念
- 機構組織
- 金融,工作,合同,法律事務等的記錄
將概念類劃分爲子類的動機
- 子類有額外的有意義的屬性
- 子類有額外的有意義的關聯
- 子類概念操作,處理,反應或使用不同於其超類或其他子類,而這些方式是我們所關注的
- 子類概念表示了一個活動體(如動物,機器人),其行爲與超類或者其他子類不同,而這些行爲使我們所關注的.
簡化繼承樹
abstract conceptual class
定義
如果類C的每個成員也必須是某個子類的成員,則類C被稱爲抽象概念類
準則
識別抽象類,在領域模型中使用斜體字標識抽象類的名稱,或者使用{abstract}關鍵字標識
狀態
準則
不要講概念X的狀態建模爲X的子類,有兩個辦法可供選擇
- 定義狀態類層次結構,並將其與類X關聯
- 在領域模型中忽略概念的狀態,而在狀態圖中加以反映
繼承
採用一種面嚮對象語言,通過創建類層次結構,軟件子類繼承超類的屬性和操作定義.繼承是使超類的特性適應於子類的軟件機制,它支持對子類代碼的重構,將其置入超類之中,形成類層次結構.因此,在領域模型中討論繼承沒有意義,而當我們轉向設計和實現視圖時它纔有重要意義.
association class
準則
在領域模型中增加關聯類的可能線索有:
有某個屬性與關聯相關
關聯類的實例具有依賴於關聯的生命週期
兩個概念之間有多對多關聯,並且存在與自身相關的信息
aggregation & composite
準則
在下述情形下,可以考慮組合關係
- 部分的生命期在組成的生命期界限內,部分的創建和刪除依賴於整體
- 在物理或者邏輯組裝上,整體-部分關係很明確
- 組成的某些屬性(例如位置)會傳遞給部分
- 對組成的操作(例如銷燬,移動等)可能傳遞給部分
益處
有利於澄清部分對整體依賴的領域約束
有助於使用GRASP creator模式
對整體的複製,拷貝這些操作會傳遞給部分
時間間隔
文中舉了一個價格變動的問題,提出了兩種解決方案,一種是產品只記錄當前價格,然後在銷售時複製產品價格到訂單,另一種方案是產品有多個價格.作者傾向於後者,因爲這樣有利於以後對價格變動進行分析.圖形如下
作爲概念的角色 & 關聯中的角色
文中提到下面一種編碼更清晰,但是不夠靈活,無法處理一個人同時擁有多個角色的情況
導出元素
準則
要避免在圖中顯示導出元素,因爲這些導出元素在沒有增加新信息的情況下還會增加複雜性.然而,如果導出元素是重要的術語,而缺乏這一術語會削弱理解,這時就需要在圖中增加導出元素.
對於上面的準則,書中給出的特例是Sale的total屬性
受限關聯
看上去讓關聯更清晰(也許能從Set轉爲Map),但是書中認爲這個做法並不好,因爲沒有增加信息(我認爲是增加了的),除非這種受限關聯有價值,否則不用(在我看來,就是Map的key如果是自身的id的話就沒啥用,如果是另一個東西的id也許就有用,特別的是指向current的指向)
類圖
屬性
三種方法
- 屬性文本表示法
- 關聯線表示法
- 兩者皆有
屬性文本格式
visibility name:type multiplicity=default(property-string)
準則:如果沒有給出可見性,則通常假設屬性是私有的
關聯性
- 導航性箭頭 由源對象指向目標對象
- 多重性放置在目標一端,而不是源一端
- 角色名只放置在目標一端,用以表示屬性名稱
集合
composition
組合關係有以下幾層含義
- 在某一時刻,部分的實例只屬於一個組成實例
- 部分必須總是屬於組成(不存在遊離的)
- 組成要負責創建和刪除其部分,既可以自己來也可以與其他對象協作
個人觀點,由於創建時總會有必填項與外鍵關聯,所以上面要求組成要創建部分的限定不夠厲害,而另一方面,幾乎不存在刪除操作,所以組成要刪除部分的約束也沒啥用
限定關聯
當存在一對多,特別是一的一方的主鍵是多的一方的邏輯主鍵時,可以通過補充缺失的字段來鎖定唯一
關聯類
這個在DB中作爲多對多的關係表,由於有了額外的屬性,所以也就需要一個專門的類,爲何不改成兩個一對多的關係呢?我認爲是改了之後就修改了原有的語義.(何況關聯類可能是當初沒有的,後來新增的,當然對設計不能大改)
方法
格式
visibility name(parameter-list):return-type(property-string)
準則:如果沒有表示可見性,則通常假設操作是公共的
create
使用<<contructor>>來標識構造方法
getter
一般省略
關鍵字
| 關鍵字 | 含義 | 用法示例 |
|---|---|---|
| <<actor>> | 類元爲參與者 | 置於類名稱之上 |
| <<interface>> | 類元爲藉口 | 置於類名稱之上 |
| {abstract} | 抽象元素,不能實例化 | 置於類元名稱或操作名稱之後 |
| {ordered} | 具有強制順序的一組對象 | 置於關聯的端點 |
單實例類
作圖上就是右上角標個1,我覺得還不如<<singleton>>來的明確,另外單實例類有點違背OO
主動類
active object運行於自己控制的執行線程之上.毫無疑問,主動對象的類即爲主動類.在UML中,主動類使用左右兩邊爲雙豎線的類框來表示