第4章 分析
テキスト分析によって、今まで作成してきたユースケースを顧客が必要とする内容を表現するクラスやメソッドに変換する方法を学ぶ。
ソフトウェアは理想の世界ではなく、現実世界で動作する必要がある。
システムを不確実性が高く混沌とした現実世界の状況で動作させるのに役立つのが分析である。
良い分析の第1歩は潜在的な問題を把握すること
問題点
今回の例では、所有者の犬ではない犬が吠えた場合でもドアが開いてしまう。
そのため、所有者の犬の鳴き声と所有者の犬ではない鳴き声を識別できるようにする。
ユースケースの更新
ユースケース内の名詞(人・もの・場所)に着目する。
ユースケース内の名詞は通常、クラスとして作成する必要があり、システム内で注意を払う必要がある。
ユースケース内の名詞(と動詞)に着目して、クラスとメソッドを識別することをテキスト分析と呼ぶ。
| メインパス | 代替パス |
|---|---|
| 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つのユーザ目標だけを詳細化すべきである。
元のユースケースのユーザ目標は、犬を出入りさせること。
新しく追加したユースケースのユーザ目標は、犬の鳴き声を記録すること。
| ユースケース |
|---|
| 1. 所有者の犬が犬用ドアに向かって吠える |
| 2. 犬用ドアが所有者の犬の鳴き声を記録する |
テキスト分析=何に着目するべきかを明らかにする
テキスト分析は、何に着目するかを明らかにするのであって、どのクラスを作成すべきかだけを扱っているのではない。
今までは「所有者の犬の鳴き声」に着目していたが、「所有者の犬」に着目すべきだったことが明らかになる。
- 再確認 ユースケース内の名詞に着目する ユースケース内の動詞は、システム内のオブジェクトのメソッドになりやすい。
DogDoorクラスのopen(),close()・RemoteクラスのpressButton()がこれに当たる。
ではなぜDogクラスが存在しないのか
- 犬はシステムの外部にある、アクターだから。システムの外部にある事柄を通常クラスで表現する必要がない。
- Dogはソフトウェアオブジェクトではない。生物に関する長期的な情報をシステムが記録するのでなければ、通常は生物をクラスで表現しない。 UserやManagerというクラスはよく存在するが、それらはシステムにおける役割を表現しているか、クレジットカードや住所などの情報を格納しているかのいずれか。
- Dogクラスがあっても、システムの他の部分には役立ちそうにない。
