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發表,除匿名指正筆誤與劉教授的意見外,因沒有其他反應意見,所以暫時「打入」草稿,現蒙劉立頌教授的鼓勵,我略作修正重新發表,提供修習物件導向軟體工程的學生參考,謹向劉教授致萬分謝意。

留言

  1. 左圖是Beck/Cunningham的原圖,但非標準圖形,"CARD cards"並無標準型態....

    應該是筆誤吧! CRC cards

    回覆刪除
  2. 很高興有機會再次看到CRC Card的介紹!的確「溝通」是合作的關鍵,可是我們常常沒有頭緒的溝通,也沒有好方法做個紀錄。其實不倚賴「高科技」工具,可以隨時使用的方法倒是可讓我們更沒有負擔的去做合作與溝通。

    回覆刪除
  3. 劉教授說『溝通是合作的關鍵』,是無庸質疑,良好的溝通可以說是軟體發展成敗的關鍵之一,Cockburn主張,最有效率的溝通方式是人與人之間『面對面』透過諸如白板、紙張或是索引卡(index card)做為溝通的工具,如果使用CRC card技術來分析以至於設計,有所謂CRC card session的機制,這種session的成員大致5-6人,包括主事者(facilitator),範疇專家以及發展者,每位成員都可毫無『顧忌』地互相交換意見,不過不管如何溝通,最重要的溝通因素必須是友善(amicability),也就是說,每一位參與溝通的成員都願意聽他人的想法(Cockburn 2002),這是成功最重要的因素。(關於CRC card session有空再來深論。)

    回覆刪除
  4. (文章的部分補充說明)如果你/妳想使用CRC cards做分析與設計,首先必須先辨識『類別』,辨識最常用的方法是由問題敘述或use cases或user stories中選取名詞或名詞片語作為類別的候選(R. J. Abbott 1983),但是use cases等一般是使用自然語言撰寫,因此語意常有模稜兩可的現象,同時非單純non-trivial)的use case念起來會冗長而乏味,而且難予瞭解,如此我建議或許可採用Grady Booch提出來的key abstraction機制,Key abstraction是一個類別或物件,其代表問題領域的詞彙,辨識這種類別有兩種活動,即『發現』與『創造』,前者是領域專家使用的觀念(諸如ATM的帳戶、存款、提款等),透過創造我們會設計新但不屬use case敘述的類別或物件(如UI),CRC card session的參與者包括1-2位領域專家,如果專家經常提到的key abstraction,則多半是重要的類別。

    回覆刪除
  5. 大致在1980年代中期,使用「正規方法」來分析與設計正式進入物件導向時代,不過大部份的小型或中型專案的應用,正規方法其實影響不大,許多軟體發展專案比較「喜好」使用「非正規技術」(informal techniques),CRC cards有利支援這種技術,因為CRC cards雖屬非正規但具彈性,而且應用在發展前期如需求、分析甚至設計階段容易客製化,因此,以CRC cards導引進入正規方法可能是不錯的方式,也許正規方法的「愛好者」,對於這種說法可能不以為然,老實說,雖然我多年教正規方法,但我並不迷信它。

    回覆刪除
  6. "CRC Cards"一文po了數月,除匿名指正筆誤與劉立頌教授的comment外,只有我自己在「老王賣瓜,自吹自擂」,如果這篇文章無法引起正反意見,我想將它關閉可也!

    回覆刪除
  7. 剛認識CRC card,尋找中文資料不易,受益了!

    回覆刪除
  8. 古老,但是國考仍入題,受教了

    回覆刪除
  9. 古老,但是國考仍入題,受教了

    回覆刪除

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

給我測試案例,其他免談(一)