概念性領域塑模

你必須瞭解問題領域中的基本概念。

你的需求文件，雖然可以有效的瞭解你的使用者曾經想要建構的是什麼，但

沒有辦法有效地瞭解最終所要建構的為何。你需要一些技術幫你充實所要建

構的細節。概念領域模型(Conceptual domain modeling)，也可以稱之為概

念塑模或領域塑模，主要的工作是發掘問題空間中，代表各種事務或概念的

個體型別(entity types)，及其中的關聯性。概念領域塑模的另一種角度是，

概念模型是用來描述你對系統問題空間瞭解的詳細程度。舉例來說，在大學

資訊系統中，概念模型的個體型別可能包括，學生、講師、終身職教授、研

討會、成績單、及註冊主任等。你也可以想像，需求模型中的名詞及名詞片

語，應該是各種概念不錯的候選者，應該存在於你的概念模型當中。許多出

現在你的概念模型中的個體，一般也會出現在你的詞彙表中（第 7 章）。概

念塑模一般也稱為領域塑模-雖然有些人會區隔這兩種塑模型態的不同，但是

我不會去區別此二者。

為什麼我不用『類別』而使用『個體』這個名詞？因為這樣你在概念塑模時，

才可以有許多不同的選擇。

其次，類別責任合作(Class Responsibility Collaborator, CRC)模型及 UML 類別

圖是物件導向塑模的作品。雖然你可以論證(黑頤 2003)，物件導向作品可以將

技術議題帶入分析的工作中，而實際上，現代大多數的系統都是採用物件技術，

因此在我的觀念中，這種觀念只是一種假設而已。你還有另外兩種選擇，物件

角色模型(Object-Role Model, ORM)圖及邏輯資料模型(Logical Data Models, LDMs)，這兩種模型並非物件導向模型。ORM 圖，接著你將會看到，可以視為

與技術無關的塑模技術。而 LDMs 則偏向資料導向技術。表 8.1 彙總各種可以

用來作為概念領域塑模的模型。

8

8-2

讓我們探索各種型態的模型，你可以應用這些模型來做概念領域塑模：

穩健圖(Robustness diagrams)

物件角色模型圖(Object Role Model (ORM) diagrams)

類別責任合作模型(Class Responsibility Collaborator (CRC) models)

UML 類別圖

邏輯資料模型(Logical Data Models (LDMs))

分析樣式；及

UML 物件圖

提示：隨時在手邊保留一份常用的術語表

艾文斯 (2004)所著《領域驅動設計：抓住軟體核心的複雜度 (Domain

Driven Design: Tacking Complexity in the Heart of Software)》中，說明一

種設計樣式語言(design pattern language)，這種語言『開頭』就是概念

領域塑模。

8.1 穩健圖

在《應用 UML 於使用案例驅動物件塑模(Use Case Driven Object Modeling with UML) 》一書中，道格拉斯及史考特(1999)描述一種技術稱為穩健

分析(robustness analysis)，有時在 RUP 中相對的就是使用案例分析(use case analysis)(IBM 2003)。其基本概念是，你可以用分析使用案例的步

驟，來驗證使用案例中的事務邏輯，同時確認所用的術語，是與之前分

析的其他使用案例是一致的。換言之，你可以應用這些技術來確認，你

的使用案例的用語(terminology)是否夠穩健，能代表系統的使用需求。其

它的應用則是，識別可能的物件或物件責任，以支援在此使用案例中呼

叫的邏輯，有效地成為與其他圖形（如 UML 循序圖（第 11 章）及 UML類別圖（8.4 節））的橋樑。

8-3

8 概念性領域塑模

表 8.1 概念領域塑模工具

模型 說明

類別圖 (Class diagram)

是一種 UML 圖形，可以顯示問題領域（或其中某部分）

中的類別，以及類別之間的關聯(associations)。

類別責任合作模型

(CRC model)

CRC 卡的集合，這些 CRC 卡組成系統全部或部分的模

型。CRC 卡是一種標準的索引卡，卡片上區隔成三部分。

第一部份標示這張卡片所代表的類別名稱，第二部份列出

這個類別的責任。而第三部分，列出與這個類別合作完成

任務的其他類別名稱。

邏輯資料模型 (Logical Data Models, LDMs)

描述領域個體及個體間關聯的模型。

物件圖 (Object Diagram)

一種 UML 圖形，用來描述物件及某幾個物件在某一時間

點物件之間的關聯，一般是類別圖或通訊(communication)圖的一個特例。

物件角色模型圖 (Object Role Model (ORM) diagram)

描述物件（個體型別(entity types)）及物件之間的關聯（事

務型別(fact types)）的圖形。其中包括，物件所扮演在這

些關聯中所扮演的角色，問題領域中的限制條件，選擇性，

及範例（稱為事務型別表）。

穩健圖 (Robustness diagram)

簡化的 UML 通訊圖/合作圖（第 11 章），使用圖形的記號

代表介面/邊界、程序/控制、及個體類別。穩健圖在識別

使用需求(Usage requirements)（第五章）捕捉到的領域

概念，非常有用。

穩健圖是一種簡化的 UML 通訊圖/合作圖（第 11 章），穩健圖使用圖形

的記號描述，如圖 8.1 所示。穩健圖中的概念如下所示：

8-4

圖 8.1 穩健圖中所使用的視覺化造型(visual stereotypes)

圖 8.2 『在大學註冊』使用案例的穩健圖

8-5

8 概念性領域塑模

參與者(Actors)：參與者的概念與 UML 使用案例圖中的參與者一樣。

邊界元素(Boundary elements)：代表一種軟體的元素，如畫面、報

表、HTML 網頁、或與參與者互動的系統介面，也稱為介面元素。

控制元素(Control elements)：就像是邊界元素與個體元素之間的黏

膠，實作管理各種元素與元素間互動所需的邏輯。也稱為程序元素

或簡稱控制項（controllers）。值得注意的是，你可能想要在你的設

計中實作控制項，而非物件-例如，有許多控制項是非常簡單，以某

個個體或邊界類別的方法來實作就可以了。

個體元素(Entity elements)：在你的概念模型中一般可以找到一些個

體型別。例如學生及研討會。

使用案例(Use cases)（選擇性的）：因為使用案例可以觸發其它的使

用案例，你必須能夠在你的穩健圖當中描述這些情況。

圖 8.2 顯示一張在白板上手書的穩健圖，這個穩健圖呈現圖 8.3 中『在大

學中註冊』使用案例所包含的邏輯。畫這張圖的時候，我只是依循使用

案例的邏輯，以及應用下列的推導方式：

在每一個主要使用者介面元素中加入一個邊界元素，如畫面或報

表。雖然有些非常詳細的使用案例，會描述參與者如何按鈕或在編

輯欄位中輸入資料；我比較喜歡維持在較高階的層次，而不是描述

得這麼詳細。然而，我確實在圖中顯示了一個 Create Student Icon（登

錄學籍的圖示）。但是事後諸葛，我們發現使用 Desktop 標示這個邊

界類別更為恰當。我沒有更新這張圖，那是因為我是遵循 AM 的做

法：只在模型發生問題時才去修改模型，同時這麼微小的缺陷也不

是那麼重要的。如果你有做介面流程圖的話，這些類別將會出現在

你的介面流程圖中（第六章）。

在情節塑模中加入一個控制項(controller)，管理所有的程序。在圖

8.2 中這是一個『在大學註冊』元素。如你所見，這就像是將各個圖

形接合在一起的膠水。在你的設計當中，這個元素極可能以類別來

實作，其中有幾個操作或某種的工作流程(workflow)引擎。

8-6

在每一個事務規則當中加入一個控制項。這樣子有助於讓你的事務

規則在圖形中更明確。有些人完全不對事務規則塑模，以維持他們

的圖形簡單，然而因此也遺漏了圖形中非常重要的資訊。兩種方式

都試試，看看哪一種比較適合你。

在包含許多其他元素的活動上加一個控制項。Create Student（登錄

學籍）就是一個例子，這個元素與一個事務規則及學生個體互動。

在每一個事務概念上加入一個個體。Student（學生）及 Student Fee（學費）這兩個類別就是這樣的例子。如果你選擇建構概念模型，

這些元素會出現在你的概念模型當中。

當加入情節時，立即加入一個使用案例。我會說明如何使用 UML標準使用案例表示法，推導出『註冊研討會』這個使用案例。此外

你也可以將使用案例視為控制項，但是依我的經驗，對關係人而言，

這不是很清晰的方式。還記得 AM 中內容比表達的方式重要這項原

則嗎？同時也要依據你的情況作最佳的選擇。

名稱：在大學註冊

編號：UC19.

描述： 幫某人辦理大學註冊。

先決條件(Preconditions)： 註冊人員已經登入系統。 應用系統已經在內部初始檢查，看此人是否有資格辦理註冊。

達成條件(Postconditions): 應用系統將符合資格的學生在大學中註冊。

活動的基本步驟： 1. 一個申請人要辦理大學註冊。 2. 申請人先在 UI13『大學申請的畫面』中填寫表格，並提交給註冊人員。[替

代步驟 A：未填寫申請書的畫面] 3. 註冊人員從畫面中審查這些表格。 4. 註冊人員判定這些表格是否填寫正確。[替代步驟 B：表格未正確填寫] 5. 註冊人員按下 Create Student（登錄學籍）圖示。 6. 系統顯示 UI89『登錄學籍畫面』。

8-7

8 概念性領域塑模

7. 註冊人員輸入申請人的姓名、地址、及電話號碼。[延伸點：UC34『執行安全檢查』。跳至步驟 17]

8. 系統依據 BR37『新生內部比對標準』，檢查申請人是否已存在系統中。[替代步驟 F：此學生已存在於系統中]

9. 系統審查此申請人是否在合格的名單中。[替代步驟 G：此人員不符合註冊資格]

10. 系統將申請人加入記錄中。此時此申請人已被視為是一個學生了。 11. 註冊人員透過 UC17『註冊研討會』這個使用案例，幫助學生註冊研討會。 12. 系統依據 BR16『計算註冊費』，計算應付的初始費用。 13. 系統顯示 UI15『費用總計畫面』。 14. 註冊人員依據 BR19『支付費用選項』，要求學生支付初始費用。 15. 學生支付初始費用。[替代步驟 D：學生無法立即支付] 16. 系統印出收據。 17. 註冊人員將收據交付給學生。 18. 使用案例結束。

替代步驟 A：........

圖 8.3 『在大學註冊』使用案例

透過繪製穩健圖，我們可以很快的瞭解，實作這個使用案例應作的工作；

因為穩健圖可以提供檢視，我們必須建構可能的元素。邊界元素可以幫

你將使用案例，過渡到使用者介面開發（第六章），同時也有助於你對舊

有系統的分析工作（第 14 章）。這些類別中有一些是個體元素，也是應

當要出現在概念模型的中的。控制項比較接近設計概念，因此穩健圖有

助於過渡至設計。

你如何維持穩健圖的靈活性？依我的經驗，遵循 AM 的實務做法是關鍵：

關係人的主動參與：穩健圖是一種非常好的技術，在某些情況，和

你的關係人共同做分析。如圖 8.2 中所示穩健圖示相當直接，而且很

容易繪製。

丟棄暫時的模型：穩健圖一般是在白板上繪製，是用來分析使用案

例的邏輯。一旦使用案例修正完成，穩健圖便保留下來一段時間，

作為進入開發下一步驟的橋樑，然後便可以擦掉了。

8-8

使用正確的工具：有些塑模人員，包括我，如果他們的關係人的邏

輯，是習慣於從使用案例跳到其它開發作品（如循序圖）；此時塑模

人員也就不再建構穩健圖。換言之，穩健圖是用來幫助關係人抽象

思考，一旦達到目的，便可以丟棄的一種技術。而有些塑模人員會

持續使用穩健圖，因為這些模型可以顯著提升他們整體的工作價值。

做完穩健圖，接著要做什麼？穩健圖一般就像是使用案例，與其他模型

（如 UML 的循序圖）之間的橋樑（第 11 章），穩健圖呈現支援使用案例

所需要的設計邏輯細節。一般也會將焦點放在系統的使用者介面，可能

是透過雛形，或最好是直接進入實際的程式編寫；因為穩健圖包含詳盡

的邊界/介面元素。除此之外，因為穩健圖描述主要的事務個體；一般會

使用這些個體，作為概念/領域塑模工作的輸入。

8.2 物件角色模型(ORM)圖

ORM 圖在《資訊塑模與關聯資料庫(Information Modeling and Relational Databases )(荷平 2001) http://www.orm.net》一書中有詳細的說明。依我

所見，ORM 是與你的關係人共同發掘領域概念，愈來愈有效的方式。ORM圖主要是描述物件（個體型別(entity types)），物件之間的關聯（事務型

別(fact types)），物件在這些關聯中所扮演的角色，問題領域中的限制，

及可有可無的範例（稱為事務型別表(fact-type tables)）

8-9

8 概念性領域塑模

圖 8.4 簡單的 ORM 圖

圖 8.4 是一個簡單的 ORM 圖。其中的橢圓形代表個體型別（荷平使用物

件這個名詞，但使用 ORM 圖塑模的系統，並不一定就是使用物件的技

術），而四方形代表物件在關聯之中所扮演的角色。其中值得注意的是，

角色從兩個方向的描述：在關聯的上端，Student 是 takes（選課）的角色，

而 Seminar 則是扮演 is taken by（被選）的角色。兩個角色上方的雙向箭

頭代表唯一的限制。因為雙向箭頭是跨在 takes/is taken by 兩個角色上

方，表示 student/seminar 的關聯，在其關聯中必須是唯一的-一個學生可

以選多個研討會，而一個研討會可以被許多學生選課。但對某個研討會，

每個學生最多只能選一次課。再考慮下面這個關聯，雙向箭頭指只放在

assisted by（被出席）這個角色上，這表示研討會只能在事務型別表中出

現一次（換言之，這是一對多的關聯）。你可以在事務型別表中看到，每

一個 seminar 出現一次，然而 Sally Jones 出現兩次-因為在 assists（助教）

這個角色並沒有唯一性的限制，所以允許這樣做。如果在每個角色上方

各別有其箭頭，這表示這個角色是一對一關聯，也就是每個物件在其角

色中，最多只能出現一次。而如果角色上頭都沒有出現箭頭，表示這是

一種無限制多對多的關聯（例如，某個學生可以同時多選某一個研討會）。

8-10

圖 8.5 複雜的 ORM 圖

在圖 8.4 中，在每一個橢圓形中列出每一個物件的一個屬性-Student 的

name 及 Seminar 的 number-而隨之在角色下方，將範例資料列在事務型

別表中。ORM 圖的風格一般視為一種知識庫(knowledge base)的圖形，而

既使為求簡化，我也不會擔心不同風格 OR 圖形之間的差異。知識庫可

以用來提供關聯的例子，這些例子是當個體型別履行其角色時所經歷

的；因此可以讓你與關係人，很容易且明確地探索這些關聯。在關聯不

是很清楚的時候，一般我會畫一個知識庫，尤其是當我們在探索其多重

性(multiplicity)時。

圖 8.5 顯示一個更複雜的例子。圖中並未包含事務型別表，因此可以探

索更廣泛的概念-這是在白板上可以應用的最大限度。同時 AM 也建議你

要以小步驟漸進成長的方式塑模。介於 Student 及 Seminar 之間的關聯已

經更充實了不少。頂層的關聯從二元的關聯發展成三元的關聯，並包含

了三個個體型別。我們可以在 ORM 圖上發展 n 層的關聯；最簡單的做

8-11

8 概念性領域塑模

法就是在關聯中加入幾個角色；但是我發現很少有機會需要這麼做。你

可以在 takes 及 assists 角色關聯中，找到一個互斥(exclusive)或（XOR）

的關聯，就是在一個圈圈中加個叉叉來代表；這代表一個學生可以選一

個研討會，或者擔任研討會助教，但不得同時兼有這兩種角色。而如果

圓圈內只有一點沒有叉叉，這代表是一種或(OR)的關聯。ORM 定義了許

多限制的表示法可供應用，而我發現 OR 及 XOR 是最常用到的。

在 Professor 及 teaches 角色之間有一條線，而在線的一端有一大大的黑

點，這代表教授有義務(mandatory)教導一個研討會。其中黑點可以放在

任一端，但是我比較喜歡放在物件端（有時候一個物件會參與多個義務

性的關聯，可能會讓你的圖形顯的凌亂，因此你可以選擇將黑點移至另

一端）。

虛線的橢圓形代表物件的一個屬性，我們可以更詳細地顯示研討會的概

念，即研討會擁有一個編號，而不像我們在圖 8.4 中那麼簡短的表示法。

我比較喜歡依循簡單地描述模型這個實務做法，採用比較簡短的表示

法。但我還是希望提供比較長的表示法例子供你參考。

另一個有趣的概念是，遞迴(recursive)/自我(self)的關聯。如圖中 Profesor所參與的一個關聯。一個教授可以是其他教授的指導(mentor)，而一個教

授也可以是被其他許多教授指導。

製作 ORM 圖時，你要如何維持你的靈活性？我比較喜歡和我的關係人

共用 ORM 圖，在白板上和他們共同討論，以便共同發掘問題領域。雖

然表示法相當複雜，我發現關係人也能夠很快地達到基本程度，尤其是，

如果一開始便常常使用事務型別表的話。當我們使用 ORM 圖探索問題

時，一旦我們對某一個議題有更深入的瞭解（一般我會從一個較高階的

工具獲得資訊，如 UML 類別圖（8.4 小節）），而當我充分瞭解時，我便

會將 ORM 圖擦掉。有時我會完全跳過類別圖，直接開始寫程式，這完

全視情況而定。

如果你的關係人不喜歡 ORM的表示方式，你可以試試 UML的物件圖（8.7小節），UML 的物件圖就像是 CRC 模型。

8-12

圖 8.6 CRC 卡的格式

8.3 類別責任合作卡

類別責任合作模型(貝克及康寧漢 1989; 威爾金森 1995; 安布勒 1998a)是使用一種標準的索引卡，每張卡上都區隔成三個部分如圖 8.6 所示。

類別表示一組相同的物件，責任則是此類別所知或所做的事，而合作則

是與這個類別互動，以達成其責任的其它類別。

雖然 CRC 卡原本是用來教導物件導向概念的一種技術，同時也成功用來

作為一種成熟的塑模技術。依我的經驗，CRC 模型是一種極為有效的概

念塑模工具，同時也可以作為細節設計之用。CRC 卡的功能在 XP(貝克

2000)中當做是一種設計技術。在此，我的焦點是放在，與你的關係人合

作，應用 CRC 卡作為概念塑模之用。

一個類別代表是一組相同的物件。物件可以是一個人、地方、東西、事

件或系統相關的概念。例如，在大學資訊系統中，類別可以代表學生、

終生職教授及研討會。類別名稱寫在 CRC 卡頂端的區域中，一般是一個

單數名詞或單數名詞片語，如 Student、Proessor、或 Seminar。使用單數

名稱的原因是，每一個類別代表一個單一物件的一般化版本。既使可能

有一個學生叫做 John O'Brien，你還是要將類別稱之為 Student。一個學

生的資訊所描述的是單一個人，不是一群人。因此，使用 Student 是比較

正確的，而非 Students。類別名稱同樣也要簡單。例如，下面哪一個名

稱比較好：選課的學生或某人？

類別名稱

責 任 合 作 類 別

8-13

8 概念性領域塑模

圖 8.7 CRC 卡的一個範例

責任是一個類所知或所做。例如學生有名稱、地址、電話。即學生所知

的三件事。學生可以選課、退選及申請成績單。即學生所做的三件事。

類別所知及所做組合成它的責任。請注意：類別可以改變他所知事物的

值，但不能改變其他類別所知的值。

有時，類別有某些職責必須達成，但沒有足夠的資訊可以完成。例如圖

8.7 所示，學生註冊研討會。要能達成這個目的，學生必須知道研討會中

是否還有名額，如果有，他便需要加入這個研討會。然而，學生只知道

他本身的資訊（他的姓名等等），他不擁有研討會的資訊。因此學生必須

與標示為 Seminar 的卡片合作或互動，才能註冊研討會。因此 Seminar便出現在 Student 卡片的合作欄裡。

合作的方式有兩種形式：請求資訊或請求執行某些事。例如，Student 卡向 Seminar 卡詢問，是否還有名額，便是請求資訊。學生請求註冊研討

會，便是請求做某些事。執行這個邏輯的另一種方式，就是 Stuednt 僅是

向 Seminar 提出註冊的請求，而讓 Seminar 執行查詢名額的工作。如果還

有名額，便幫此學生註冊。若否，便通知學生註冊失敗。

那麼你要如何建構 CRC 模型？反覆進行下列的步驟：

1. 找尋類別：我會應用各種策略來找尋可能的類別。首先，我會找尋

某種的客戶類別，如大學資訊系統中的學生類別。在航空服務系統

中則是旅客類別。我是「跟著錢走」，從系統相關的產品及服務，找

出如何賺錢及錢花在哪裡，以便識別出核心的業務類別。我會很快

地找出三到五個主要類別。如大學資訊系統中的學生、教授、課程、

研討會、及教室。在你的詞彙表中的業務名詞，是你的系統可能的

8-14

類別。事件，如大學中的畢業及授予學位，也是潛在的類別，因為

其中需要提供重要的責任來支援這項活動（例如，畢業必須知道如

何安排人員清單，因此需要有一份畢業學生名單，及知道畢業日期

及畢業典禮的地點）。我有時候會在 CRC 模型中加入報表，如成績

單。因為已經有使用者介面雛形，因此我不用詳細說明成績單中的

細節。一般我只會加入一行註解『**請參閱雛形**』，如圖 8.8 所示，

並且一直保留不動-我們不要將相同的資訊放在許多地方。

2. 找尋類別的責任：此時你應該想想，這個類別要做什麼事。例如，

成績單類別應該可以計算平均分數，而教室類別應該能夠指示何時

有空（以便研討會類別可以據以安排教室）。另一種識別責任的方式

就是，想想這個類別需要記錄哪些資訊。對 Student 類別而言，必須

記錄其姓名、地址、學號及電號號碼。當一個類別需要與其他類別

合作時，這表示另一個類別有責任達成這項合作。換句話說，當你

找尋責任，你需要定義合作，而當你定義合作，你會發現新的責任。

3. 定義合作：所謂合作，最重要的觀念就是，當一個類別需要的資訊

是他本身所沒有的，便會產生合作關係。同樣的，當一個類別需要

修改非屬於它自己的資訊，便會發生合作，因為所有的類別只能修

改它自己本身的資訊。這表示，如果需要更新其他類別中的資訊，

就必須要求擁有這些資訊的類別去修改。

4. 隨意移動這些卡片：CRC 塑模一般是由一群人，坐在一張大桌子

旁，共同執行。當 CRC 卡書寫完成後，便放在桌子上，以便所有的

人都可以看到。兩張有合作關係的卡片必須放在一起，沒有合作關

係的卡片則放得比較遠。除此之外，合作關係愈密切的卡片，放得

愈近。因為合作的卡片放得愈近，愈容易瞭解兩個類別之間的關聯。

最大的優點是，當你從上面俯視這些卡片時（這正是你站在桌旁時

的觀點），你可以得到整個系統的概觀，瞭解每一個類別如何與其他

類別互動。除此之外，你可以集中注意力於系統的特定區域，而將

所有的卡片參與這個區域的活動。另一個優點就是，如果有人想要

移動某張卡片，一般都會引起一陣的討論，如「你不可以移動這張

卡片，因為 XYZ 在這裡與它合作」。這樣的討論有助於你們增長這

個模型。很可能會找出新的責任，同時有助於每個人瞭解模型中細

8-15

8 概念性領域塑模

微的差異。最後，當你將 CRC 卡轉換成一個類別模型（請參閱 8.4小節），桌上的卡片所在的位置，顯然是最合理轉成類別模型同樣的

位置。

圖 8.8 是大學資訊系統中一個小小的 CRC 模型。這些卡片是與關係人密

切合作找出來的，這位關係人瞭解領域中的這一部份。因為 CRC 卡是一

種簡單的技術，你會發現，你的關係人很快便能夠熟悉如何使用，有一

部份是因為這是一種高階概念性的塑模。

下面是我這些年來使用 CRC 塑模所得到的一些要點：

1. 一個合作者在一張卡片上只列一次：在圖 8.8 中 Seminar 類別與

Student 的合作有好多次，但是卡片上只列出一次。另一種方式就是

在責任前列出合作者，這樣做對我而言似乎是多做一些沒必要的工。

2. 除非有合作關係，否則不要列出合作者：有時兩個類別之間的合作

是屬雙向的，有時則只是單向。例如，Transcript 及 Seminar 之間的

合作關係是單向的。Transcript 需要向 Seminar 請求資訊，而 Seminar則不會向 Transcript 要求任何東西。因此，我將 Seminar 標示為

Transcript 的合作者，而相對的不會將 Transcript 標示為 Seminar 的

合作者。一般而言，除非 A 類別為 B 類別做了某些事，否則不會將

A 類別列為 B 類別的合作。

3. 有時候合作者會承擔大部分的工作：舉例來說，學生註冊研討會。

Student 與 Seminar 合作，以便瞭解是否還有名額，如果有，便要求

登錄。此時 Seminar 做了所有的工作。Seminar 必須瞭解還有多少名

額，以及更新研討會中的學生列表。另一方面，Student 只是管理（指

導）這整個流程。

8-16

圖 8.8 大學資訊系統中的某些 CRC 卡

4. 一開始便預期會不斷地移動卡片：因為一般人會先識別出比較明顯

的責任，而這些責任比較容易導出主要的合作，你將發現，你會很

快地注意到卡片的『正確』位置。

5. 把比較忙碌的卡片放在桌子的中央：最忙碌的卡片一般是系統的核

心，因此應該放在中央的核心位置。依照經驗法則，客戶一般就放

在桌子的中央，或靠近中央。

8-17

8 概念性領域塑模

6. 立即建立卡片：當你找出一個類別時，就應該立即建立一張卡片。

你應該這麼想：花時間決定這是否是一個類別的成本，比建一張卡

片多太多了。

7. 實際移動你的卡片：一般人的習慣，填好一張卡片，便只是在桌上

找一個空間擺放。別低估移動卡片的好處。

8. 當你移動卡片，便很容易找出類別之間的關聯：一般而言，有人會

拿起一張卡片，放在某一張卡片旁邊，並聲稱這兩張卡片可以合作。

而另一個可能會說，不是，應該放在另一個地方，因為這張卡片應

該與另外一張卡片合作。你應該仔細聽聽這些人的交談，同時記下

任何的關聯，或從中而生的事務規則。

9. 哪些是類別，哪些是責任，是由背景(context)所決定：為什麼不用

Student name（學生姓名）當作一個類別，而以姓、名、中間名等當

作是責任(responsibility)呢？嗯，這要看你所在的領域而定，人名或

許可以是一個合格的類別。但是對大學資訊系統而言，則不恰當。

依照經驗法則，所有格代名詞，如 Student name 中的名詞 Student，似乎已經點出 Student 是一個類別，而學生的姓名則是這個類別的一

個責任。

10. 選擇『資料』的責任時，盡量保持風格的一致性：這是一個有趣的

風格議題，就是如何描寫資料導向(data-oriented)的責任。Student這張卡片中的責任有 Name 及 Phone number，而實際的責任是 Know name（識別名）及 Know phone number（識別電話號碼）。雖然有

人堅持使用識別名的格式，我比較喜歡使用簡短的格式-Name；因

為這樣比較容易使用。雖然兩種技術都可用，我比較喜歡依循 AM的實務做法簡單地描述模型。重點是，一旦你選擇了一種風格，便

要堅持下去，在所有模型中保持不變-亦即遵循應用塑模標準這個

實務做法。

在塑模的過程當中，當我要讓關係人主動參與時，我都會應用 CRC 模

型。不錯，關係人也參與其他形式的概念領域塑模，但 CRC 塑模往往是

比較容易上手；因為我們使用的是實質的卡片。在我的經驗當中，卡片

往往比圖形更好用，因為卡片比較容易瞭解及應用在工作上。