祈祷連歌

もちろん、オブジェクト間のメッセージという概念には、一番抽象的なレベルでは、 同期か非同期かといった区別は存在しない。

ただ、抽象化のレベルをどんどん下がっていくと、どこかで同期メッセージと 非同期メッセージの区別が生じるところがあることは確かである。 一番底辺のマシンコードのレベルまで降りてくると、そこでは理論上は全ての メッセージがマシン語のサブルーチン呼び出しのコードにまで分解される。

このマシン語のサブルーチン呼び出し自体は同期呼び出しである。 当然ながら、上位の抽象レベルでのメッセージがそのままマシン語のサブルーチン呼び出しになっているわけではない。 しかし、最終的にはメカニズムとして同期するような仕組みにまで分解されることは確かで、だから非同期式のメッセージも同期式のサブルーチン呼び出しや割り込み機構によって実現される。

すると、非同期メッセージというのは同期メッセージによって実現できるのではないだろうか、と考えることができる。実際、マシン語のレベルにいたるまでのどこかでは全ての非同期メッセージは同期式のサブルーチン呼び出しに分解されているわけなので、少なくともこの考えは方向として間違ってはいないはずである。

抽象化のレベルの階梯を上から下がっていくと、 どこか途中で同期非同期の区別が必要となり、 さらに下がるとどこかで同期式に統一されるということになる。 この区別が必要となる条件はどのようなものなのだろうか。 同期と非同期というのは、どちらがより本質的なものなのだろうか。 単に歴史的経緯がその区別を必要なものにしてしまっているだけのような気もするが。

ここ1ヶ月ほど大量のシーケンス図を描く機会に恵まれた。 今まではシーケンス図などは、ちょっと設計を確認する場合とか、 後になってからドキュメントを書くときにちょろっと必要になる程度だったので、 あまり積極的には活用してこなかった。 しかし、最近はなるべくＭＤＡなどを意識してしまうことが多く、 シーケンス図などからコード生成させる方法などを考えてしまうので、 いきおい、シーケンス図が必要になったときにはなるべくそこに全てを記述しようと 試みることになる。

シーケンス図そのものはソフトの挙動のほんの一スナップショットを例示しているに 過ぎない。だから、それだけでコード生成に足る記述は本質的にはできない。 ソフトの動的な側面を完全に記述するには、シーケンス図に加えて、 フローチャートなりアクティビティ図なりなんらかの別の手法を組み合わせて、 挙動の抽象的な側面を補足する必要があるのだ。

つまり、ソフトの動的な側面を記述するだけでもいくつかの抽象化のレベルをまたいだ仕組みが 必要になるというわけで、シーケンス図自体でもそういうことになるだろうと思う。 すると、まず最初に思い浮かぶのがオブジェクト間のメッセージで、 その記述自体もその抽象度のレベルに合わせて何段階かあるだろうということになる。

で、思ったのが同期非同期の区別はどこまで本質的なものなのだろうかということであったわけだ。

非同期メッセージは同期式のサブルーチン呼び出しに分解できるのは上で見たとおりだ。 ある特定のＣＰＵに、あるいは、ある特定の言語の、さらにいえばあるライブラリセットの、 プラットフォーム依存の形では全てのメッセージは同期式のなにかに分解される。 逆にプラットフォーム非依存の形においては同期非同期の区別はどこまで必要なのだろうか。

非同期メッセージは同期メカニズムに分解できる。 一方、同期メッセージも非同期メカニズムに分解可能だ。 マシン語のレベルまで下がろうとすると非同期から同期へ分解されることになるが、 そこにいたるまでのプラットフォームによっては全てが非同期というのも、極端だが、考えることができる。全てが、というわけではないが、ウィンドウメッセージなどそのいい例だろう。

同期非同期がらみで、抽象化のレベルとそれらの区別の必要性の条件というのをはっきりさせないと、シーケンス図をはじめとする動的なソフトの挙動の記述からコードを生成する仕組みは、 膨大な経験則の塊になってしまうのではないかと危惧する。 より本質的な部分とより実用的な部分、この二つの観点の切り分けをはっきりさせる必要がる。 今年の１００プログラムには、ちょっと初心にもどって、このシーケンス図も含めることにしよう。