ソフトウェア開発メモ

日々のソフトウェア設計、実装で考えている、気づいた事を書いています。それが真実か否かは保証しません。悪しからず。

責務の見つけ方

はじめに

書籍「オブジェクトデザイン」の4.2章、「責務はどこから見つかるか」の所を見直して再解釈しました。あくまで自分流の解釈になるので書籍を読む事をお勧めします。実際はシーケンス図やコミュニケーション図と併用する、追加クラスの発見と併用する形になると思います。

ユースケースを噛み砕く。

以下の事を繰り返します。

  1. ユースケース記述から、アクション、情報保持、判断を識別する。
  2. それらを責務の記述に書き直す。
  3. 曖昧さがなくなるまで1, 2を繰り返し、適切なクラスに割当、あるいは新しいクラスを作り直す。
ユースケースや仕様の抜けを埋める。

仕様を詳細化してそこから責務を踏み込むという形になる。機能仕様があれば不要?  

実現手段をどんどん掘り下げて、プリミティブな形に分解して行く。 構造化設計でいう機能分解に近い形になる?

ユーザーイベントへのアクションを考える。

他のオブジェクト、下位のオブジェクトから上がってくる報連相に誰がどう対応するかという事を考えます。だれ(どのクラスが)がどういう反応するかというのはGUIアプリを作っている人なら当たり前に身に付いているかと。

まとめ。

「オブジェクトデザイン」のとおり、システム全体の責務から考えて、レイヤやオブジェクト分解を意識しつつプリミティブな責務まで分解していくという事でしょうか? 実際の所はクラス発見、責務の発見と分配、コラボレーションの検討をグルグル廻していく形になるのかなと思います。そうしないと単なる構造化設計の機能分割とあんまり変わらないような。。。