最後。本当はサンプルを作りながらだけど、それは今後の課題に。要点だけまとめる。
オブジェクト指向分析
まず、「そのシステムの対象になっている領域はどのようになっているか」を考える。
- 仕様
- 「誰が何をするのか」を基本に、問題領域から仕様を起こす。この時点での仕様は、文章になっていれば箇条書きを列挙する形でいい。
- 名詞の抽出
-
仕様の中に存在する名詞を洗い出し、クラス候補を考える。洗い出した名詞について、明らかに処理系に依存する様な分析段階にふさわしくない様なものなどを消し、ふさわしい物をクラス候補とする。この時、最初から刈り取っていくのではなく、候補として残せる物は残しておいた方がいい。必要な物が無いまま分析を進めると、その必要な属性や操作がシステム中に分散して存在する事になってしまう。
この時点で、名称だけのクラス図を書いておく。 - 関連の洗い出し
-
クラス候補の羅列に続き、関連を洗い出す作業に移る。クラス間に関連をひいて、それに名前を付けていく。クラス中にN個のクラスがある場合、原理的には最大N^2個の関連が存在する事になるが、実際はそのような複雑さは稀でいいスステムとも言えない。関連が必要以上に多いと、クラスの再利用性も損なわれる。
関連の有無は操作の有無で、関連の有無が曖昧な場合はそこに関連があるとして進めた方が安全。 - 操作の洗い出し
-
各クラスに存在する操作を洗い出す。この段階ではあまり詳細な操作を導きだす事はやや難しい。この時、無理をしてそのとき出来る以上の事をしようとしない事は、重要な判断だと言える。
オブジェクト指向開発では、様々な分析を並行して行えるため、先に進み必要になれば戻りそれを反映させていけばいい。 - 属性の洗い出し
- 各クラスの属性を洗い出す。ある程度洗い出したら、不足だと思いつつも次に進む。この段階で十分な解が出る事は無い。オブジェクト指向開発では、「他の分析に移る」事は「この分析が終わった」事を意味しない。必要になれば戻ってくる事になる。
- 動的分析
- 処理の流れをシーケンス図で作成する。このときに発見できた属性や関連などは、その時点で反映させる。
- クラスの吸収
- 属性とその設定と取得しか操作が無い様な場合は、別のクラスの属性として吸収する。
- 派生属性
- 分析レベルでは概念的にあった方がいいが、実際は他の属性などから計算で求められるような属性は、物理的に存在する必要が無い。
- クラス属性
- インスタンス単位でなく、クラス単位で持つべき属性。クラス全体の性格を表すもの。
- 集約
- あるクラスが別のクラスの一部を構成する様な場合の関連(集約関連)。集約関連は、必ずしも全体を表す様な大きいクラスから、それを構成する小さいクラスに向かって順序よく繋がる様に並ぶ物とは限らない。
- 継承
- 継承によってクラスが増える事で関連も変化するため、それを見直す事を忘れてはいけない。
- アプリケーションクラス
-
アプリケーションが稼働している間存在し続ける、問題領域の根幹になる様なクラスの生成とその間の関連の作成が、アプリケーションクラスの重要な役割。
通常の関連で結ばれるクラスの間で、生成する/されるといった関連が存在すると、問題領域の本質とは関係ない上下関係がクラス間に出来上がる。そのため、一段階大きなクラスが、両方を生成して関連を張る様な設計にした方がいい。 - 表示
- それぞれの処理系に適した形で表示すればいい。
- 管理のためのクラス
-
例えば、「ある数字が使われている場合それは利用不可能にする」という管理を行いたい場合、その機能を存在する問題領域のクラスに持たせる事は避けるべき。無理にこれを行うと、そのクラスがこのロジックに縛られて問題の本質から離れてしまいがち。
問題領域に登場するクラスだけでなく、このような機能をクラス化したものはよく使用される。 - 細部の決定
-
クラス属性は「クラス内にstaticで領域を確保する変数」、派生属性は「クラス内に領域をとらずに計算で求める値」であり、両方をかねる事は矛盾する。このような判断が必要な場合は、実装レベルでオーバーヘッドなどを考慮して決定する事になる。
設計工程が進み、プログラミング工程の直前になると、関連を設定するための操作などのプログラムを動かすための操作や属性が必要になる。これもこの段階で追加していく。
クラス図の洗練
クラス図がある程度充実してくると、やや荒削りな部分が目立ってくる。そこで、これを1度見直してみる。
設計
まとめ
オブジェクト指向では、処理系に依存する部分はアプリケーションクラスだけになるよう設計される。そのため、ほとんどのクラスをそのまま利用する事が出来る。移植を考えれば、問題領域のクラスは処理系に依存しないため、アプリケーションクラスを処理系に従って作るだけでいい事になる。
オブジェクト指向は、アプリケーションを動かすための技術ではなく、物事の本質に根ざした、深いところに根拠を持つ方法。

