オブジェクト指向の分析／設計でインターフェースの話がでる。
書いたけど、やっぱやめた。をやめた。
システムとアクタの境界（アクタとバウンダリ）、
バウンダリとコントローラの境界、
コントローラとエンティティの境界、
ＢＣＥ分析に限らず、クラス間の役割を明確にすることが大きなウェイトを占めてる。
モデルの良し悪しは二の次で、その役割が明確になっていることの方が重要な感じ。
＝インターフェースが大事みたいな感じ。
ユースケースは、「システム−アクタ間のシーケンスを引け」＝「システム−アクタ間のインターフェースを確認して、システムの役割を明確にしろ」みたいな。
それをシステム開発のプロジェクトに置き換えても同じことが言えるハズ。
ＰＭと呼ばれる役割の人がいて、
分析者と呼ばれる役割の人がいて、
設計者と呼ばれる役割の人がいて、
…
メンバの役割を明確にして、インターフェースを見出す…この場合は成果物。
成果物を生み出し、アウトプットを出して、誰かがそれを使って、新たな成果物を生み出す。
メンバ構成はともかく、役割を明確にして作業をすることが大事な感じ。
システム開発のプロジェクトは、結構具体的な事象で、それを抽象化すると会社のビジネス活動になると捉えてみる。
SI会社のビジネス活動の一部として、システム開発のプロジェクトが存在するみたいな。
ビジネス活動にも、いろいろな役割の人がいて、そのメンバの役割を明確にして、業務を行っていく。
RUPやCMMiなんかは、ここを重要視していると勝手に思ってみる（プロセス指向）。
RUPの繰り返しは、CMMiのIDEALモデルのことを言ってて、そのプロセス改善をオブジェクト指向で解決しろ、と言ってるだけみたいな。
ということで、そういうことやってたら必然的にプロセスやリソースをオブジェクト指向的に捉えるのが自然に思えてくるような気がして、それがSOAなんかの基本的なスタンスなんだろうと思ってみる。
サービス＝プロセスって感じ。
ビジネスフローの一つのアクティビティが、サービス（の候補）になるって直感的に判るんだけどね…
台形の面積求める公式（上辺＋下辺）×高さ÷２を覚えたらＯＫ？でも、公式が積分の解法を元にしてるって知っているのとでは違うんじゃないかな？みたいな感じ（謎
