『Head First オブジェクト指向設計』第4章

第4章 分析

テキスト分析によって、今まで作成してきたユースケースを顧客が必要とする内容を表現するクラスやメソッドに変換する方法を学ぶ。
ソフトウェアは理想の世界ではなく、現実世界で動作する必要がある。
システムを不確実性が高く混沌とした現実世界の状況で動作させるのに役立つのが分析である。

良い分析の第1歩は潜在的な問題を把握すること

問題点

今回の例では、所有者の犬ではない犬が吠えた場合でもドアが開いてしまう。
そのため、所有者の犬の鳴き声と所有者の犬ではない鳴き声を識別できるようにする。

ユースケースの更新

  1. ユースケースは、作成者、上司、顧客に対して意味があるように作成する。
  2. 分析とユースケースは顧客、マネージャ、その他の開発者に対して、現実世界の状況におけるシステムの動作方法を明確にする。

ユースケース内の名詞(人・もの・場所)に着目する。
ユースケース内の名詞は通常、クラスとして作成する必要があり、システム内で注意を払う必要がある。

ユースケース内の名詞(と動詞)に着目して、クラスとメソッドを識別することをテキスト分析と呼ぶ。

インパス 代替パス
1. 所有者のに出たいと吠える
2. 鳴き声認識装置鳴き声を検知する 2.1 所有者鳴き声を聞く
3. 鳴き声認識装置ドアを開くための要求を送信する 3.1 所有者リモコンボタンを押す
4. 犬用ドアが開く
5. 所有者のに出る
6. 所有者のが用を済ます
  6.1 ドアが自動的に閉まる
  6.2 所有者のに入りたいと吠える
  6.3 鳴き声認識装置が再び鳴き声を検知する
  6.4 鳴き声認識装置ドアを開くための要求を送信する
  6.5 犬用ドアが再び開く


6.3.1 所有者がふたたび所有者の鳴き声を聞く
6.4.1 所有者リモコンボタンを押す
7. 所有者のが家のに戻る
8. ドアが自動的に閉まる
鳴き声認識装置 犬用ドア 所有者 要求 リモコン ボタン 中/外 鳴き声
BarkRecognizer DogDoor DogDoor.Open() Remote Bark
  • 「所有者の犬」は名詞だが犬はアクターでありシステムの外部に位置するのでそのためのクラスは必要ない。
  • 要求もクラスにはなってないが、鳴き声認識装置が犬用ドアのopen()メソッドを呼び出すことを表してる。

新しいユースケースの追加

元のユースケースのユーザ目標は、犬を出入りさせること。
新しく追加したユースケースのユーザ目標は、犬の鳴き声を記録すること。

ユースケース
1. 所有者の犬が犬用ドアに向かって吠える
2. 犬用ドアが所有者の犬の鳴き声を記録する

テキスト分析=何に着目するべきかを明らかにする

テキスト分析は、何に着目するかを明らかにするのであって、どのクラスを作成すべきかだけを扱っているのではない。

今までは「所有者の犬の鳴き声」に着目していたが、「所有者の犬」に着目すべきだったことが明らかになる。

  • 再確認 ユースケース内の名詞に着目する ユースケース内の動詞は、システム内のオブジェクトのメソッドになりやすい。
  • DogDoorクラスのopen(),close()・RemoteクラスのpressButton()がこれに当たる。

  • ではなぜDogクラスが存在しないのか

  • 犬はシステムの外部にある、アクターだから。システムの外部にある事柄を通常クラスで表現する必要がない。
  • Dogはソフトウェアオブジェクトではない。生物に関する長期的な情報をシステムが記録するのでなければ、通常は生物をクラスで表現しない。 UserやManagerというクラスはよく存在するが、それらはシステムにおける役割を表現しているか、クレジットカードや住所などの情報を格納しているかのいずれか。
  • Dogクラスがあっても、システムの他の部分には役立ちそうにない。