前回のエントリ「イマドキのオブジェクト指向」は僕が思っていた以上に注目がありました。気づいた人もいるのかもしれませんが、僕はオブジェクト指向というものをきちんと学んだことがありません。なので「オブジェクト指向ってオブジェクトが大事なんだなー」ぐらいにしか思っていなかったのが事実。
というわけで、はてブではyojikさんに
メッセージ指向vsクラス指向は最初期からあった対立軸だと思う。
と言われて、あと、よういちろうさんには「メッセージ指向なオブジェクト指向でのUMLって?」で、
太古の昔から、オブジェクトは「メッセージのやり取りによる処理の委譲の繰り返し」だったはず。
と言われました。両方ともなるほど。この原因としてよういちろうさんが、
JavaやC++など、構造化言語から派生した言語を習得することによってオブジェクト指向を学んでしまった人間にとっては、メッセージのやり取りという発想ではなく、あくまで「関数(=メソッド)を呼び出す」という発想しかない。つまり、他のオブジェクトに対しての処理の委譲について、基本的に完全な同期処理しか体験できないために、メッセージングの手法が限定され、結果としてメッセージングという考えに行き着かない、ということなんだろう。
というのに納得。僕、まさにこのパターンです。最初はCOBOLとVBやって、次にDelphi、そしてJava。C++をやっていた人に「Javaだとメッセージって概念が薄いよね」と言われてのですが、正直言って僕にはピンと来ないのです。
だからこそ「あぁ、メッセージなんだな」というのは僕にとっては新しい発見だったわけです。2000年以降にJavaをやったような人には、僕の発見は共感してもらえるのではないかな?と思っています。
モデリングは「言葉のデザイン」
さて、もう1つ。僕が「UMLも関係性のデザインについては非常に弱い」と書いたことを受けて、よういちろうさんに
純粋にオブジェクト指向の領域において、UMLは他のどのコンピュータ言語よりも、素直にメッセージングに関する記述ができるはず。
と言われたことで気づいたのですが、僕が記述したいのは「言葉の関係性」なのです。クラスとメッセージではなくて、純粋に「関係性」。
僕はモデリングを「言葉のデザイン」だと思っているところがあって、提案書を書く作業と非常に似ていると感じます。まずは相手のドメインにおいて言葉がどのように使われているかを知り、理解していく。そして単に言葉を分類するだけでなく、それらを特定の関係性の上で組み合わせて世界を表現します。最後に、その言葉を使いながら、あるべき世界を作っていく作業。提案書も同じですね。僕の中では提案書を書く過程が概要モデリングになっています。
UMLは好きですが、書いていてもクラス同士の関係性がはっきりとは見えてこない。線を引いくだけじゃだめだから、脚注をつけて、色をつけて、マークをいれたりするけど、それでも足りない。そもそも1枚で表現できないのも不満があって、なんとかならんもんかと、いつも思います。
もっと豊かに関係性の表現ができる手法があれば、さらに楽しくモデリングができるのではないでしょうか。感覚論で申し訳ないが。
コンポーネントの再利用性が低いのは関係性を安定させられないから
ところで関係性という視点で色々なことを考えると面白い。例えばソフトウェア・コンポーネントの再利用が困難な理由を考えてみます。
工業製品ではコンポーネントの再利用性が高いのですが、これは「再利用性の高いコンポーネントを作ったから」ということではなく、「コンポーネント同士の関係性を安定させているから」と考えることができます。車のエンジンの再利用性を高めるには、ボディやシャーシなど、他の部品との関係性が一定の範囲に収まっている必要があります。この安定が工業製品は非常にやりやすい。
一方でソフトウェアの場合には関係性を安定させることが難しい。コンポーネントは必ず特定のドメインの中にデプロイされます。その際、そのコンポーネントと、そのドメインの他のコンポーネントの関係を安定させることは非常に難しい。同じ企業がないように、同じドメインは2つとありません。ドメインを超えて安定している関係といえば、たとえば法律やデファクトとして規定されているものに限られます。だからクレジットカードの与信コンポーネントは再利用性が高いのです。
つまり、ソフトウェア・コンポーネントの再利用性が低いのは「ドメインを超えてコンポーネント同士の関係性を安定させることが難しいから」と解釈することができます。逆にいえば関係性が安定するような枠組みをいれないと再利用性は高まりません。だから業界団体を作って標準化プロセスを行うわけですね(その割に不安定な関係性を引きずったまま標準化するから混乱する)。
というわけで、思ったことをわらわらと書いてみました。なんか、やっぱりソフトウェアは楽しいなぁ。ITっで情報技術の略ですけど、感覚的には「言葉を扱うための技術」なんですよね。

コメント (4)
UML = クラス図 ではないと思うんですけど...
メッセージのやりとりをするのはオブジェクトに対してなので、クラス図ではどうしてもその関係性を表すのは難しいと思います。クラス図はどうしても静的な情報しか書けないので。
それよりも、コミュニティ図とかシーケンス図とかを使う方がいいのではないでしょうか。特に関係性を表すというのであればコミュニティ図を使うのがいいと思います。
私が新人らにオブジェクト指向を教えるときは、まずメッセージありきで教えます。たとえば、人間同士が言葉でやりとりしているものを、メッセージのやりとりとして見つめ直し、メッセージのやりとりをシーケンス図もしくはコミュニティ図で書いてみようというところからはじめます。クラス図はもっと後になってからですね。
投稿者: さくらば | 2008年01月31日 10:33
日時: 2008年01月31日 10:33
なるほど。さくらばさんの教え方、すごく良いですね。
メッセージのやり取りで表現するわけですよね、ふむふむ。参考になります。もっと積極的に使うようにしてみます。
ちなみにコミュニティ図というのはコラボレーション図(コミュニケーション図)のことですか?
投稿者: yusuke | 2008年01月31日 16:20
日時: 2008年01月31日 16:20
こんなところで間違えているとは orz
コミュニケーション図のことです。
投稿者: さくらば | 2008年01月31日 23:52
日時: 2008年01月31日 23:52
動的な認識が先にあり、静的モデルにして安定化し、客観性を持たせるというのが順番です。
人間の認知は静からは難しいでしょう。だから活動の観測が大切だし、その中でどう活動するかの結果で建物があるのでしょう。
投稿者: はぎわら | 2008年05月10日 19:01
日時: 2008年05月10日 19:01