オブジェクト指向開発〜静的分析その1

静的モデリングの導入。何がクラスになり、何がならないか、とか。

クラスの抽出

クラスを探し出す作業は、システムの仕様から名詞を探す作業。分析段階では、問題領域のクラスのみを考える。GUIにボタンを使うなどのコンピュータ領域に関しては、この段階では考えない。名詞であっても、クラスになるとは限らない。

分析時の視点からのクラス

名前
クラスの本質を表した名前をつける事を心がける。
属性
そのクラスの成り立ちを示すデータが属性。プログラム的にはデータメンバに相当する。
操作
クラスに用意された、クラスに対する命令の受付窓口が操作。プログラム的には、メンバ関数に相当する。

クラス図の作成

クラス図に書かれている事が最終的にシステムの構成を決定する。
クラスの操作と属性を導き出す流れは以下の順序で行われる。

  • クラス仕様の決定(シナリオ)
  • 操作の洗い出し
  • 必要な属性を考える

属性よりも操作の洗い出しが先である事に注意する。隠蔽される属性よりも外部に公開される操作の方が重要。

クラス仕様の範囲

オブジェクト指向では、ある仕様がどのクラスの仕様であるかと言う認識は重要。何をするかだけでなく、「誰が何をするのか」が重要になる。「誰が」を探す場合は、その文章の主語を考えて判断する。

操作の抽出

操作名は大抵動詞になり、また操作する側が主語である事が原則。

属性の抽出

クラスのモデリングに正解はないが、クラスの分析段階で操作や属性として考えない方が良い物がある。例えば、「表示」の様なコンピュータ領域の概念が関わるものはこの時点では考えるべきではない。分析段階では「いかにして動かすか」という事は考えない。また、一般的にクラスの属性にクラスを持たせるという分析はしない。複数のクラス同士は基本的に対等の関係。

クラス候補がクラスになる基準

ある名詞(クラス候補)を考えるときに、属性が1つでその属性の設定取得といった操作しか考えられないとき、それは他のクラスの属性として吸収される。

プロフィール

このブログ記事について

このページは、koshigoeが2005年12月10日 18:02に書いたブログ記事です。

ひとつ前のブログ記事は「Web2.0はオブジェクト指向?」です。

次のブログ記事は「オブジェクト指向開発〜静的分析その2/関連」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。