プランの記述と可視化
「設計」（design）より「プラン」（plan）という言葉を使おうと思う。これはH氏の提案だ。英辞郎でplanを引くと：
- 計画、企画、予定、今後の進め方
- 設計図、図面、平面図、伏図
- 意向、つもり、考え、意図 ◆通常複数形で使う
とあり、もともと絵図の意味を持つようだ。素晴らしい。
システム構造のプラン記述法として、僕が想定しているのはロバストネス図だ。だが、ユースケース図やロバストネス図を意識するより前に、Catyを設計しているので、Catyの用語法はユースケース図／ロバストネス図のそれとはズレている。
| ロバストネス図 | Caty | Catyキーワード |
|---|---|---|
| バウンダリー | クライアント状態 | state |
| コントロール | コマンド／アクション | command/action |
| エンティティ | ファシリティ／エンティティ | facility/enitity |
| アクター | ユーザーロール | userrole |
用語"entity"が一致してるのは、最近導入して、意図的に同じ名称を採用したから。他は違う言葉だ。このズレを無理に直すと不都合もあるから、しばらくは気にしないことにする。むしろ、出自も言葉も違うのに、同じ概念を指し示している符合と必然性のほうに注目すべきだろう。
これらのプラン要素を描いた図を4つ、本編から拾って以下に貼る（原寸大、けっこう横幅ある）。レイアウト方法は違っているが：
という色目は共通している。
それと、昨日の「アクションとエンティティの関係」の図。
これらの図を眺めていると、システムやサービスの構造を定義する行為（＝プランニング）は、次の3つに分けると良さそうだ。
- インタラクション・プランニング ： アクター、バウンダリー、コントロールの関係を定義する。Catyだと、クライアント状態（≒画面）の遷移がどのようなアクションを経由して行われるかを定義することになる。図（有向グラフ）では、状態→アクションのリクエスト辺、アクション→状態のレスポンス辺、アクション→アクションのリダイレクト辺などの繋がり具合いを描く。
- エンティティ・プランニング ： コントロールとエンティティの関係を定義する。Catyだと、コマンド／アクションが、どのエンティティを利用するかを定義（宣言）することになる。図（有向グラフ）では、コマンド／アクションとエンティティのあいだに、reads, updates, uses の辺を描く。
- アルゴリズム・プランニング ： これは、コマンドの内部を記述すること。プリミティブコマンドは別にして、コマンド／アクションはスクリプトコードとして実装される。スクリプトの構造はデータフローグラフ（＝制御フローグラフ＝フローチャート）として描ける。
コマンドが"中央”の位置にあると考えれば：
- インタラクション・プランニングは、コマンドのフロント側のプランニング
- エンティティ・プランニングは、コマンドのバック側のプランニング
- アルゴリズム・プランニングは、コマンド自体（その挙動）のプランニング
と考えることができる。
このような分類は層（tier）に分けることだが、それとは別に、分割統治原理に従いモジュールやパッケージの機構は準備している。複数のモジュールを繋ぎ合わせるメカニズムはポートと呼ぶ。次の図の、輪郭が点線の楕円がポートだ。ポートに入る矢印は、他のモジュールにある実際のノードに繋がることになる。繋がり具合いは別に定義する。（ポートを繋ぐ部分がまだ出来てない。）
CatyScriptはもともと、良く構造化された（well-structured）シェル言語として設計されている。プランニング言語を意図したわけではないが、ひるがえって「プランニング言語はどうあるべきか？」と考えると、それは「徹底的な可視化が可能な、良く構造化されたシェル言語」じゃないのか、とも思える。
