この論文で初めてUIMSという言葉が使われたらしい。

トロント大学のMENULAYというUIMS。表示したい出力をエディットすると、 そのUIを示すプログラムが出力される。設計者はそれと実際の動作を行う関数を リンクすることによって目的のシステムを得る。例示によるプログラミングの考えに つながる。

状態遷移図を使ったU/I記述ツール"USE"の解説 状態遷移機械では以下のような記述ができないという欠点があるといっている。

• 入力のバッファリングの有無の記述
• 入力文字列の最大長の設定
• 復改文字以外による入力の終了
• 特殊キーによる分岐
• 入力エコーの有無
• 時間切れによる遷移

また、次のような点も問題になる。

• 遷移図がすぐに複雑になる
• 一時的に値を記憶したり動作の結果を調べたりできない
USEは、状態遷移図に、上のような点を克服するための機能を付け加えたものである。 遷移図の各ノードには対応する動作と出力を指定し、 各アークには遷移をひきおこす 入力条件を指定する。 この他、遷移設計エディタとかログをとる機能とかがある。

状態遷移機械をDialogに使用したUIMS。 UIはネットワークを通じてプロセスで実行される。 Seeheimモデルを採用している(古い?)

文脈自由文法で記述したU/I

Sassafrasの開発にいて判明したUIMS設計における重要な点について述べている。 問題となるのは、 並行動作 通信 ランタイムにおけるUIの修正 UIMSとアプリケーションの整合 UIMSとAPの分離の可能 構文解析 vs. プログラム言語 非プログラマによる設計 などである。 複数入力の並行動作、複数dialogの並行動作、APとUIMSの並行動作のどれも 大事である。UIMSとAPのどちらが主導権をもっていてもまずいので、これらの間の 通信が重要である。実行中にそれを中断して別のインタフェースをすぐに実験 できるのが良い。アプリケーションはUIMS用に改造してでも両者をマッチさせる のが好ましい。UIMSとAPを論理的に分離することは、直接操作を考えても 不可能であるので、ファイルを分けるなどの物理的に分離する方法が良い。 dialog記述に構文解析機のようなものを用いるのはだめで、意味操作のできる プログラム言語に近いもののほうが良い。UI設計は非プログラマにやらせるのが よいというのは間違いで、ある程度プログラムの経験のある者のほうが良い。

◎Sassafrasの目標 ○インタフェースの変更を何回も迅速に行なえること 良いインタフェースを作るには何回も実験することが大事である。 世の中のUIDSの研究動向は、いかに簡単にUIを指定するかとか いかに幅広いインタフェースをサポートするかとかいうことであるが いくら簡単に指定できても実現できないインタフェースが有ったら しかたがないので、指定は複雑でも汎用なものを作る。 ○UIにおける並行性 並行した出力、入力、ダイアログが必要である。 複数の入力装置を同時に操作できなければならない。 ◎既存UIMSの問題点 ○並行入力ができない ○アプリケーションとの双方向通信がうまくいかない ○同期の問題 ◎Sassafrasの特徴 ○複数並行ダイアログのサポート ○入出力ルーチンとアプリケーションの通信サポート ○同期機構 ◎上の機構の実現方法 ○局所的並行ダイアログを記述する言語ERL これはJacobのRTN(Recursive Transition Network)みたいなのよりも 強力である ○モジュール間の通信と同期をサポートするLEBM \\ ◎実験によってわかったこと ○UIのダイアログ記述においてもある程度計算能力は必要である。 例えば座標の計算をするためだけのためにアプリケーションを 呼ぶのはばかばかしい。その点CSPは計算能力が有る。 ○UIとAPのロジカルな分離は難しい。しかしフィジカルな分離は 可能である。 ○UIデザイナーはプログラマであるほうが良い

これはオブジェクト指向をうたったUIMSで、UIMS を字句解析部、構文解析部、 意味解析部に分けてその間に またがるオブジェクトを定義し、オブジェクト間のメッセー ジ通信によりインタフェースの動作が行なわれる。 各オブ ジェクトがある程度の知識をもっているため、例えばメニュー の形状の Xなどのように簡単な処理は意味解析部まで行く 前に処理される。 このときその情報はそのオブジェクトの みが持っているため、オブジェクトの セーブ機構が用意さ れている。 簡単な構文チェックもそのオブジェクト内で行 なわれる。 このような機能のおかげで直接操作にも対応で きるようになっている。(増井)

Apogee UIMSにおける制約の使用について。 Apogee UIMSではアプリケーションとインタフェースは共有データ を介して通信を行なう。ユーザは共有データをエディットし、 アプリケーションはプログラムで共有データを操作する。 共有データはactive valueとなっており、属性が変更されると 自動的にアクションが起動される。 属性間には制約を設定することができ、依存している属性が変更を うけるとスプレッドシート的に再計算が行なわれる。 このメカニズムは、値が変更されたら単純にアクションを 起動するというものではなく、インクリメンタルに無駄のないよう行なわれる。 品はオブジェクト指向的にできており、部品間は「コネクタ」で結合される。 このあたりの記述には特別の言語を使用している。

特別の言語を使っているが、APも同じ言語を使わなければならない のだろうか。やっぱり汎用言語を使いたい。 制約はグラフィックには重要だろうが電子手帳には全然 役にたたないのではないだろうか。制約だけでは 困るような... (増井)

SeeheimにおけるIFIP/EG Workshop on User INterface Management System (October 1983) の論文集

Seeheimモデルは直接操作には向かないため、アプリケーションとUIMSが意味データを 共有しているようなモデルを提案している。

SeeheimモデルにもとづいたUIMSを作っている。 Seeheimモデルとは、アプリケー ションと物理装置の間を３つのモジュールに分けてUIMSを定義しようというものである。 Dialog Controlには状態遷移表、文法によるもの、イベント駆動方式の すべてを サポートしている。イベント駆動方式とは、Presentation Component または Application Interface Modelからのイベントに応じての動作を規定したプログラム によるUI定義である。定義が複雑になるが、並行動作を記述できるといちおう どんなUIでも記述できるというメリットがある。 Application Interface Modelはデータ／手続き部、UI/AP接続部に分かれており、 UI/AP接続部はユーザ主導／AP主導／混合方式のいずれにも対応している。 ３個のモジュールは別プロセスのように動作しなければならないため、 スケジューラが疑似並行動作をさせている。

Garnetのマニュアル

UIMSのサーベイ