(^o^)o>して、そのモデル中の「ローズオブジェクト」と「ジャックオブジェク>ト」を人間に置き換えようとした場合、彼らが利用すべき道具であるプ>ログラム群がそのモデルから自動生成できるのか、できないとしても、>どの程度プログラミングのための仕様情報を抽き出せるのか。そこらへ>んに興味があります。コストの問題を度外視すれば、それが可能ならビ>ジネスアプリでもOOは利用できるはずなのですが...仕事をしている人間は、役割を持ったプロセスと性質が一致します。注文していた荷物が届いたから倉庫の適切な場所に運ぶ、ということは、荷物が届いたというイベントから始まるイベントドリブンのプログラムでモデル化することができます。それを(機能的)オブジェクトとしてもいいのですが、1つ上のレイヤのシステムオブジェクトのメソッド操作にしても構いません。どちらにせよ、イベントハンドラ(プログラム)には、すでに、荷物オブジェクト、倉庫オブジェクト(ファイル、テーブル、ベルトコンベア(倉庫自動搬入機)でも可)のクラス(概念)がある必要があります。新人なら倉庫の位置を教えないと仕事できませんし、もしかすると倉庫って何か教えないといけないかもしれません。それが、ローズオブジェクトが倉庫オブジェクトへの参照を持っていたり、倉庫搬入関数が、倉庫オブジェクトへの参照を引数に持ったりします。引数に倉庫オブジェクトを指定するような面倒なことが無いので便利の思えるかもしれません。それは、倉庫に関するデータをグローバルに参照している限り、容易にプログラミングできるわけで、もし、倉庫が2種類あるとすると、倉庫番号などのデータが引数として必要になってきます。サブ処理は、倉庫搬入関数モジュールのローカルサブ関数になったり、ローズ(搬入係)オブジェクトのプライベート関数になったりします。どちらにせよ、彼らが利用すべき道具であるプログラム群が近くにあります。このように機能的なことであれば、オブジェクトでも関数(プロセス)でも構いません。一般に、システムの外部に公開するのは、関数になります。プロセスを管理する必要が生じた場合は、オブジェクトである方が適当です。ローズ・搬入リーダーが、倉庫管理のスティーブと、力持ちのブルートの手を借りないとできない仕事が来たとします。空き場所検索関数があるとします。ブルートには、「手で運べ!」と「フォークリフトを使いまわせ!」と「休んでいいぞ」の命令ができるとします。(これらも関数とする)いま、スティーブの担当と、ブルートの担当を分けましたが、関数が多くなると、このような担当分けが重要になってきます。ブルートに荷物搬入チェックをしてもいいのですが、チェックに関する知識(データ)が無いのでできません。(スティーブに聞けばできますけど非効率です)スティーブに荷物搬入チェックをさせれば、(メンバ変数として)知識や経験からすぐに仕事の内容を理解し(プログラミングでき)仕事を完了します。このように、データの集合と関数の集合という組み合わせで、関連が深い傾向があるので、クラスとしてまとめた方がいいのです。話を進めると、スティーブはいつも倉庫管理ばかりしてるわけではありません。ブルートもたまにはデスクワークもします。力持ちの「役」を持ったブルートをインターフェイスとして、ローズ・リーダーは命令(プログラムの実行)をしています。リーダーは、会社の代表として搬入作業というイベントハンドラ関数を公開し、受け付けます。>どの程度プログラミングのための仕様情報を抽き出せるのか。ローズ・リーダーにとっては、荷物搬入という「場」(クラスまたは関数)から、倉庫管理の「役割」インターフェイスと、力持ちの「役割」インターフェイスを操るだけですから、その詳細は知る必要がありません。ローズ・リーダーにとっては、いったいスティーブは何やってるんだろうか興味のあるところです。それは、インターフェイス関数の内容を見ればわかること。そこには、スティーブの知識(メンバ変数)を駆使して作業が進められていることがわかります。ローズさんは、それを知って大変だなぁ、と同情しても、自分じゃしたくねーな、スティーブに任せよう、と思うでしょうし、そんな知識(データ)を持つ(与える)ために勉強したくないな、スティーブが知ってるからいいや、と思うでしょうね。何でも知っていて、仕事をバリバリこなすスーパーマンがいればいいですけど、普通の人間は「役割」という社会が生み出した概念が与えられていて、必要な知識と作業内容(手に職)が分担されています。リーダーは、担当者に仕事を分担しているだけです。いった組織をシミュレーションするための手法がオブジェクト指向です。オブジェクト指向だけでは、次のケースがおきます。ブルートに、この荷物をここへ。細かすぎる指示を出すと「俺にいちいち指図するな!馬鹿にするな!」となります。一人前の役割が与えられないからです。「そんなに言うんなら自分でやれ」と言われます。いうわけで、「とにかく、荷物を倉庫に入れておけ」という指示になります。ほとんどの場合、オブジェクトの最終状態(出力)が出てきます。処理は、終了すると特定の静的状態(データ構造)になりますから。なると、プロセスよりも、データが主導(DOA)になります。「なぜ、スティーブとブルートが必要なのだ?」と言われます。そこでは、リーダ自身のプロセスを説明して、この場面でブルートを使いました、と説明が要ります。報告書にはそれを考慮しないといけません。システムは、その報告を事前に行うので、仕様書には、プロセスが書かれている必要があり、プロセス指向になります。