CRC cards - 非正規物件導向發展技術

最近看到Kent Beck與Martin Fowler講的一句『諺語』，說："Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文，提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』，溝通在軟體發展的過程中十分重要，尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto)，此地不宜對宣言多做闡述)，問題是你要使用何種工具或方法來溝通？我想除use cases外，CRC cards可能是最佳工具之一，它是隨時隨地可得的低技術工具，易學易用。

軟體開發與維護時，工作夥伴的合作十分重要，換言之，團隊合作是發展工作成敗的關鍵，夥伴合作必須有好的工具或技術協助，CRC cards可能是適當的工具之一，據我所知，在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997)，而這種技術雖然簡單，但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別，因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術，而且也希望各界人士能予指正。

CRC cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html)，其出現時期與WWW相同，至今約有20幾年的歷史，這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作，後來的演變卻超乎在教室內的需要，而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach)，雖然屬非正規方法，但CRC cards可做為正規方法的輸入或前端作業，如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOSE、Shlaer/Mellor方法、Unified Process以及Rebecca Wirfs-Brock的RDD(Responsibility-Driven Design)等等，因此CRC cards適用於『任何』軟體發展方法上。

使用CRC cards技術時對於「物件」一詞的想法應有所改變，Craig Larman在"Applying UML and Patterns"一書裡，以隱喻(metaphor)的方式說：『軟體物件有如人們具有責任(responsibilities)，有些責任必需與他人合作(collaborte)才能完成工作』，CRC cards就是這種隱喻的圖形表示，其與UML表示物件的方式不同，UML思考物件是"data+algorithms"(下圖右)，而CRC cards的物件是"roles+responsibilities"(下圖左)，其中roles是物件所扮演的角色，同一個物件可以扮演各種不同的角色，責任也就依所扮演的角色而異。

左圖是Beck/Cunningham的原圖，但非標準圖形，CRC cards並無標準型態，使用者可以依需要客製化，但卡片至少需具載類別名稱、類別責任與合作者三項，一般使用所謂index card，其大小可以是3in x5in或4in x6in，卡片左上角書寫的類別名稱，也可以是原件、子系統、角色、或其它物件，卡片後面可以簡單說明類別的特性或屬性。卡片中「責任」是以高層次(不涉及實作)的方式說明類別的目的，責任包含3種型態：(1) 物件執行的動作，即doing責任；(2) 物件保養的認知或資訊，即knowing責任；(3) 物件主要的決定以影響其它物件，即decision making責任。

那麼，UML工具為何不支持CRC cards，我們要從Martin Fowler所提出的3種模式層次來看，這3種抽象層次包括(可能有更多層次，但3種層次已夠說明)，即：

• 觀念層次(conceptual level)或範疇層次(domain level) ─ 說明一群責任；
• 規格層次(specification level) ─ 說明一群涵蓋的方法(methods)；
• 實作層次(implementation level) ─ 說明程式與資料。

但大部分的UML工具重點放在從規格轉成實作層次，而有點忽略觀念層次的觀點價值，如果UML工具能夠涵蓋處理觀念層次，我想喜愛使用工具發展軟體的人士應會樂觀其成。由於CRC cards的基本優點在於描述觀念層次，這就是我們說CRC cards技術可以連接各種正規方法做為分析甚至設計工具的理由。

至於物件可扮演何種角色，Wirfs-Brock用角色型別 ( role stereotypes)來定義6種物件可能扮演的角色，每一種角色有不同的責任，這些角色都可以使用CRC cards來描述，包括：

• 資訊保持者(information holder) ─ 知道或提供資訊，也就是說保持事實，例如郵件地址，帳號，交易記錄等；
• 結構者(structurer) ─ 保養物件間的關聯以及與這些關聯相關的資訊，例如檔案系統的folder；
• 服務提供者(service provider) ─ 執行工作，一般來說提供運算服務，例如信用授權；
• 協調者(coordinator) ─ 委託工作，例如交通號誌燈，文字處理器的字體管理；
• 管制者(controller) ─ 決定並指揮它物的行動，例如交通指揮員；
• 介面者(interfacer) ─ 支持系統內外各部門的間通訊，例如ATM的金錢出口。

確定物件屬於何種角色有助於擬定物件的責任以及要完成某責任的合作物件，每一種物件都有可能(但不一定)扮演兩種以上的角色，例如EmailAddress(Wirffs-Brock 2003)將扮演「資訊保持者」與「服務提供者」，因此EmailAddress物件知道送與受者以及SMTP資訊地址，此外它可輸送訊息，為要完成這些責任，他必須與Mailer與UserProfile合作，否則無法完成EmailAddress的運作，上述責任與合作者可以以下列CRC card表示 (使用CRC工具繪製)：

物件導向軟體發展法的首要工作，就是先定義與問題範疇相關的物件， CRC cards是提供發展者集體透過腦力擊盪設計軟體系統的工具，這種集體工作稱為CRC session，理想參與的成員大約5-6人，包括主事者(facilitator)，這種人必須熟練物件導向技術，此外須有範疇專家(domain expert)以及發展者。這種集體腦力擊盪的工作方式，其優點是，使用CRC cards作業可以沒有風險(nonthreatening)而且非正規(informal)，而且允許參與的任何人提供意見，這也是CRC cards的強項。(註：上圖STMP是SMTP之誤)

為何要使用CRC cards來分析與設計？可以綜合下列幾點：

• CRC cards便宜、具彈性而且垂手可得，最重要的是具可攜性(portable)，也就是說，不必依 賴電腦而且在任何地方皆可使用，如果修改或不需要時可隨時撕毀；
• 可以讓參與的團隊第一時間就可討論系統如何運作而不必依賴電腦工具；
• 可用於教授物件導向發展方法 (Beck/Cunningham發明CRC cards的原意)；
• 可做為許多正規方法的前端，如Booch，Wirfs-Brock ，Jacobson等人的方法。

至於本身可用來當做發展軟體的方法(methodology)，這一點可參考下面圖示，以說明如何使用下圖所示的發展流程來發展軟體：           (上圖發展流程請參考2011年TCSE研討會論文集Session 1C: Software Processs內本人 一  篇小文章："From CRC Cards to MDA: A Software Development Process")

CRC cards的非正規性與彈性，以及與其相關的發展流程是其強項之一，這種流程易予客製化，當然，因其非正規化，所以對物件導向的初學者會有某種程度的困擾，例如不同的專案可能會有不同但適合該專案的句法 (syntax)，不過初期能擬定指引，而該指引或許可成為適合團隊使用的標準，一旦使用者熟習CRC cards技術，則CRC cards將可顯示發展者的觀念，以及幫助其對於需求的了解，從這種角度來看，CRC cards技術的彈性與易予客製化可以說是其優點，而且CRC cards技術可以讓你/妳在發展初期容易發揮你/妳的智慧，或無庸置疑。

這篇報告只約略介紹CRC cards及其技術，其主要用在『責任導向設計』方法 (RDD)的部分，希望有機會再來『輕鬆談』。

這篇報告原在2012/12/8發表，除匿名指正筆誤與劉教授的意見外，因沒有其他反應意見，所以暫時「打入」草稿，現蒙劉立頌教授的鼓勵，我略作修正重新發表，提供修習物件導向軟體工程的學生參考，謹向劉教授致萬分謝意。