オブジェクト指向設計の入門書って、クラス図を挙げてからその説明のために他の図を用いているけど、これってどうなんだろ？
出来合いのアプリケーションを例に挙げて「どうすれば分かりやすく説明できるか」を考えているようだけど、それは説明のためのアプリな訳で、説明している工程は実際の工程とは違うでしょ。
オブジェクト指向設計では、動的なことを表す図が作られるたびに静的なことを表す図（というかクラス図）が加筆されて詳細になっていくものなんじゃないかと思う。
だって個々のクラスをどう定義するか考えるにはクラス同士の連携を考える必要があるでしょ？
クラス同士の連携を考えるときには個々のクラスの内部状態を考えることもあるし。
だからクラス図が表すような静的モデルは設計の結果で、動的モデルは設計の過程を表すものなんじゃないかと思う。
設計の進捗状況はクラス図の詳細さに表れるんじゃないだろうか。
曖昧なことから始めるのは正しそうだけど、本当に正しいのは「思いついたことから始めること」だと思う。
抽象化、具体化の両方を繰り返して設計は進むものだし。
手続き指向に長けた人ならアルゴリズムをクラス分けするほうが飲み込みやすいだろうし、そうじゃないなら使いそうなクラスと、それらの関係を考えることから始めるのが良いと思う。何指向から始まってもやり方が正しければ行き着く成果は同じ。
得意指向を問わずプログラミング初心者の場合は、作ろうとしているものから1つだけ機能を絞って、その中で「クラスがどう連携するか」を「メソッドの呼び出し方」で考えるのが良いんじゃないだろうか。メソッド呼び出しには呼び出し順やコードの切り分け方、データの型/形式/スコープなどが関わるから。
というわけで「何を考えるときにどの図を使うか」を教示するのが大事なんじゃないだろうか。
工程が一続きになっていなくても、読者に得意な考え方から読んでもらう形のほうが良いかも知れない。
