まあ酒を飲んでいるわけだが，オブジェクト指向開発についてちょっと．
最近オブジェクト指向の開発プロセスの本を眺めていることが多い．
今の疑問,酒飲んでいるから日本語めちゃくちゃだけど
１． なんか知らないうちにオブジェクトがクラスになってねー？：
ユースケースやらシーケンス図やらアクティビティ図やらシステムの機能を表現しようとするような絵では，
クラスではなくオブジェクトを使って表現したりオブジェクト間の通信を書いたりする．で，あれ？っていう感じで，
どこからクラス図が出来ている．これは結構不思議．これによって2点の問題がある
- ある特定のオブジェクトに必要な構造と，クラスに必要な構造は違うはず：
確かに一般的にクラスの名前と外の振る舞いに関係する属性は，オブジェクトとクラスで一致することが多い．しかし，
内部の状態を表すような属性，メソッド内部の振る舞いに影響を与える属性なんかは，
単一のユースケースやシーケンス図からは出てこないことが多い． 本当は，
複数のユースケースの動作(一つの中でも正常と異常ケース)の組み合わせまで分析して，
初めてそこに登場するオブジェクトを代表するクラスが決定できそうな気がするが，
そのような説明(例が無いだけかもしれないけど)がなされていないし，そこは重要だと思う． - あと，オブジェクトのライフサイクルの設計が甘くなる． ： なんか3分間クッキングよろしく，
都合よく出来合いのオブジェクトが出てくるシーケンス図とか描いていると，オブジェクトをいつ生成し，
いつ破棄すべきかが適当な分析になってしまう．
２． パターンっていつ使うんよ？： 素直にプロセスの本のやり方を踏襲すると，パターン本の「適用の可能性」
に出てくるような状況を顕在化するような分析は可能であろうか? 大体デザインパターンの「適用の可能性」って，なんていうか，
複数オブジェクトとその相互作用に関する制約(〓しなければならない，〓する必要がある)という形で表現されていることが多い．一方，
プロセス本って，大前提として，問題をwell-structuredに捉えて，
段階的に物事を詳細化できるに違いないでゲスって言う前提で書いているんだよなあ．だから，
こういう制約解消的な決まりが分析において掬い取られる場面に出会わない(ように書いてある)．
その意味でパターンの利用タイミングっていまだ職人的に感に基づきそうなんだよ．
ちょっと，もう少し分析しましょう．←おれ
border="0" /> "http://www.amazon.co.jp/exec/obidos/ASIN/4894710773/sakatayuji-22"> border="0" /> "http://www.amazon.co.jp/exec/obidos/ASIN/4894713772/sakatayuji-22"> border="0" /> "http://www.amazon.co.jp/exec/obidos/ASIN/4877830138/sakatayuji-22">
