そういえばinterfaceを拡張しようとしていた
Command-Queryが分離した指標をメイヤー指標と呼ぶことにしよう。メイヤー指標のモデル（理論的な実装）をメイヤーオートマトンと呼ぶ。もちろん、インスティチューションになる。
いつだか忘れたが、昔、IDLの構文に、when accept xxx とか issues Event, results NewState とか、そんなキーワードを入れてinterface構文を拡張しようとしていた。今にして思えば：
- ステージ遷移とステージ内の状態遷移を記述したかった。
- 外部からのメッセージ（刺激、イベント）を受け取って、それをきっかけにする動作（イベントハンドリング）を記述したかった。
- 状態遷移に伴って、外部にメッセージ（イベント）を発行することも記述したかった。
- メッセージ／イベントの受け口や出口をポートという名前で定式化しようとしていた。
コンポネントの挙動をどっちかというと並列動作とメッセージベースで考えていたわけだ。
その後、クリーネ代数とかでしばらく直列計算を考えていたが、結局、直列計算も並列計算も両方できないとダメ。現実には、直列と並列が混じり合っているのだから。
現実には、空間的境界（データ型経由）と時間的境界（プロトコル経由）の通信を区別するのは難しい。バッファやデータ転送により、相互に変換できるから。だが、区別しないと、いつまでも曖昧なママなのだ。
やっぱり、n-セルとn-重圏が必要そうだ。
