アジャイルモデリング(AM)
公式サイト
モデリング成果物>CRCモデル

CRC (Class Responsibility Collaborator) モデルの概要

by Scott W. Ambler, Copyright 2003

CRC (Class Responsibility Collaborator) モデル (Beck & Cunningham 1989; Wilkinson 1995; Ambler 1998a) とは、普通のインデックスカードの集合です。このインデックスカードは、図1に示すように3つの区画に分かれています。クラス (class) は同じようなオブジェクトの集合であり、責務 (responsibility) はクラスが知っている、あるいは行う事柄であり、協調クラス (collaborator) はクラスが責務を果たすために相互作用する他のクラスです。図2に手書きのCRCカードの例を2つ示します。

図1. CRCカードの区画

図2. 手書きのCRCカード

CRCカードは、もともとオブジェクト指向の概念を教えるために導入されたものですが、十分に実開発で使えるモデリング手法としても使われ続けています。私の経験では、CRCモデルは概念モデリングの他、詳細設計にも非常に効果的なツールです。CRCカードは、エクストリーム・プログラミング(XP) (Beck 2000)においても、設計手法として非常に重要な役割を果たしています。ここでは、利害関係者と一緒に概念モデリングを行う場合のCRCカードの適用方法に焦点を合わせます。

「クラス」とは、同じようなオブジェクトの集合です。オブジェクトとは、対象としているシステムに関係する人や、場所、もの、できごと、概念です。たとえば、大学システムでは、クラスは学生や、教授、ゼミを表すことになるでしょう。クラスの名前は、CRCカードの上部に書くもので、通常は「学生」「教授」「ゼミ」のように単数形の名詞または名詞句になります。名前を単数形にするのは、各クラスが表しているのが1つのオブジェクトを汎化したものだからです。John O’Brienという学生がいるのかもしれませんが、モデリングするのは「学生」というクラスです。学生に関する情報が描写するのは1人の人であり、人のグループではありません。ですから、複数形ではなく単数形にする方が理にかなっています(日本語の場合は複数形がないので末尾に「群」などをつけるなどの工夫が必要)。また、クラス名は簡潔にもするべきです。たとえば、「学生」と「ゼミに参加する人」のどちらがよいでしょうか。

「責務」とは、クラスが”知っている”あるいは”行う”事柄です。たとえば、学生は名前、住所、電話番号を持っています。これらは学生が知っている事柄です。学生は、ゼミに登録し、ゼミから脱退し、成績証明書を請求することもあります。これらは学生が行う事柄です。クラスが知り、行う事柄が、クラスの責務の構成要素となります。重要: クラスは自分が知っているものの値を変えることはできますが、他のクラスが知っているものの値を変えることはできません。

クラスが責務を果たさなければならないにもかかわらず、そのために必要な情報を持っていないこともあります。たとえば図3では、学生はゼミに登録します。学生はそのために、ゼミに空きがあるかどうかを知り、空きがあればゼミに加えてもらう必要があります。しかし、学生が知っているのは自分に関する情報(名前など)だけで、ゼミに関しては知りません。学生がゼミに登録するには、「ゼミ」と書かれたカードと協調/相互作用する必要があります。そのため、「学生」の協調クラスの一覧には「ゼミ」が含まれているのです。

 

図3. 学生のCRCカード

 

あるクラスは、自分自身の責務を果たすため、協調クラスに”情報を求めたり”、”何かをしてくれ”という依頼を行います。このように他のクラスに依頼して責務を果たすことを協調と呼びます。たとえば、「学生」カードは「ゼミ」カードに、空きがあるかどうかを示してくれと依頼します。つまり、情報を求める依頼です。その後「学生」は、「ゼミ」に加えてくれと依頼します。つまり、何かをしてくれという依頼です。しかし、このロジックを実行するには、単に「学生」が「ゼミ」に自分を登録してくれと頼むという方法もあります。そして、「ゼミ」に空きがあるかどうかを確認させるのです。「ゼミ」は、空きがあれば学生を登録し、なければ学生に登録されなかったことを知らせます。

では、CRCモデルはどのように作成すればよいでしょうか。以下のステップを反復的に行ってください。

  • クラスを見つける:クラスを見つけるのは基本的に分析時の作業です。アプリケーションを作るための部品を明らかにすることだからです。経験則では、図4の「学生」「ゼミ」「教授」など、3つから5つの中心となるクラスをまず見つけるとうまくいきます。私は「成績証明書」や「「学生スケジュール」(どちらも帳票です)といったUIクラスを含めることもありますが、エンティティクラスだけにこだわる人もいます。また、利害関係者が現実の学生(アクター)とシステム上の学生(エンティティ)という概念をうまく理解できないでいる場合には、私はアクターを表すカードを追加することもあります。

  • 責務を見つける:クラスが何をするか、そのクラスに関してどのような情報を保持したいかも考えなければなりません。別のクラスとの協調動作を行うための責務が明らかになることもよくあります。

  • 協調クラスを定義する:クラスが自分の責務を果たすための十分な情報を持っていないこともよくあります。その結果、クラスは仕事を果たすために別のクラスと協調動作しなければなりません。協調動作は次の2つのいずれかの形で現れます。情報を求める依頼か、任務を実行してくれという依頼です。クラスの協調クラスを識別するには、責務のそれぞれについて「クラスはこの責務を果たす能力があるか」を考えます。ない場合には、足りない機能を実行する能力を持っているクラスか、実行するのが順当であるクラスを探します。その過程で、別のクラスに新しい責務が必要だと判明することも多いでしょうし、ときには新しいクラスが必要になることもあります。

  • カードをあちこち動かす:誰もがよりよくシステムを理解できるように、カードはよく考えてテーブルに配置するべきです。互いに協調動作する2枚のカードはテーブルの上で近くに置き、協調動作しない2枚のカードは離して置くべきです。さらに、2枚のカード間の協調動作が多いほど、机の上でも近くに置きます。互いに協調動作するカードを近くに置くことで、クラス間の関係を理解しやすくなります。

 

図4. CRCモデル

 

CRCモデリングの作業をアジャイルに保つにはどうすればよいでしょうか。「少しずつモデリングしよう」というAMのプラクティスに従ってください。このためにもっともよい方法は、システムの要求全体ではなく、ユーザストーリービジネスルールシステムユースケースといった1つの要求に対して、CRCモデルを作成することです。CRCカードは非常にシンプルなツールであるため誰もが参加しやすく、AMの「利害関係者の積極的な参加」のプラクティスに従うことができます。

CRCモデルが絶対的なものではないと理解しておくことが重要です。それを発展させて、UMLクラス図や場合によっては直接コードを作成するときに、だんだんとそのスキーマを変更することになります。責務が見つかったり、新しいクラスが持ち込まれたり、もともとあったクラスがなくなったりすることでしょう。これは、進化型のアプローチで開発を行うときに起きることなのです。

 

注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。


推奨文献

 

その他の文献

アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。

 アジャイルモデリング

 

Let Us Help (以下、北米での話ですのでご注意ください)

Ronin International, Inc. continues to help numerous organizations to learn about and hopefully adopt agile techniques and philosophies.  We offer both consulting and training offerings.  In addition we host several sites - Agile Modeling, Agile Database Techniques, UML Modeling Style Guidelines, Enterprise Unified Process (EUP) - that you may find of value.

You might find several of my books to be of interest, including The Object Primer, Agile Modeling, The Elements of UML Style, and Agile Database Techniques.

For more information please contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).

 

visits since November 17, 2003.