ダイコン時代の設計手法 - CRC分析

CRCはClass-Responsibility-Collaboratorの略です。
Responsibilityはクラスの責務、
Collaboratorは協調して動くクラスを表します。
これが、ダイコン時代のコンポーネントの設計にはぴったりなんですよ。
Responsibilityがinterfaceのメソッド、Collaboratorが
DIされるコンポーネントを表すので。


一般にCRC Cardを使って設計するときは、ClassやResponsibilityを
きちんと見つけ出すことがポイントであり、難しい部分でもあります。
でも、ダイコン時代の設計手法を使えば簡単です。
ロバストネス分析をして、見つけ出したコントロールをバウンダリごとに
1つのクラス(interface)にまとめます。こいつがLogicクラスです。
コントロールクラスがエンティティと関連がある場合、エンティティごとに
Daoクラスを作成し、LogicクラスのCollaboratorにします。
Daoクラスにも適切なResponsibility(メソッド)を割り当てます。


Responsibilityが適切かどうかを検証するために、
シナリオ分析します。
シナリオはバウンダリがコントロールを呼び出して、
次のバウンダリに遷移するまでとします。
最初に考えるのは、「しなければいけない」シナリオ。
通常はコントロールごとに1つでしょう。
次が「〜ならばできること」のシナリオ。
条件が複数あるなら別のシナリオにします。
最後が「例外」のシナリオです。
本来のCRC分析では、「〜してもいいこと」のシナリオも検討するのですが
コントロールまでフォーカスが絞れていればいらないような気がします。
また、シナリオの範囲もバウンダリからバウンダリまでと
対象を絞っていますが、業務フロー全体を対象にしてしまうと
ちょっと大変(実際にやるとしんどい)な感じ。
このシナリオは、Responsibilityの検証に使いますが、
結合テストのシナリオのインプットにもなります。