JPH04227538A - プログラム仕様の対話的な設計・検査を支援する方法およびシステム - Google Patents
プログラム仕様の対話的な設計・検査を支援する方法およびシステムInfo
- Publication number
- JPH04227538A JPH04227538A JP3103546A JP10354691A JPH04227538A JP H04227538 A JPH04227538 A JP H04227538A JP 3103546 A JP3103546 A JP 3103546A JP 10354691 A JP10354691 A JP 10354691A JP H04227538 A JPH04227538 A JP H04227538A
- Authority
- JP
- Japan
- Prior art keywords
- actor
- tape
- actors
- data
- simulation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims description 120
- 238000013461 design Methods 0.000 title claims description 26
- 238000007689 inspection Methods 0.000 title claims description 7
- 238000004088 simulation Methods 0.000 claims abstract description 118
- 230000008859 change Effects 0.000 claims abstract description 55
- 230000004044 response Effects 0.000 claims abstract description 23
- 230000009471 action Effects 0.000 claims description 194
- 230000006870 function Effects 0.000 claims description 161
- 230000006854 communication Effects 0.000 claims description 72
- 238000004891 communication Methods 0.000 claims description 70
- 238000012545 processing Methods 0.000 claims description 47
- 230000002441 reversible effect Effects 0.000 claims description 16
- 230000002452 interceptive effect Effects 0.000 claims description 10
- 230000009977 dual effect Effects 0.000 claims description 7
- 238000004590 computer program Methods 0.000 claims description 6
- 230000002730 additional effect Effects 0.000 claims description 3
- 239000002131 composite material Substances 0.000 claims description 2
- 230000002776 aggregation Effects 0.000 claims 1
- 238000004220 aggregation Methods 0.000 claims 1
- 235000021474 generally recognized As safe (food) Nutrition 0.000 abstract description 107
- 235000021473 generally recognized as safe (food ingredients) Nutrition 0.000 abstract description 107
- 230000000007 visual effect Effects 0.000 abstract description 101
- 238000013515 script Methods 0.000 description 253
- 230000014509 gene expression Effects 0.000 description 66
- 230000007246 mechanism Effects 0.000 description 34
- 230000000694 effects Effects 0.000 description 33
- 230000008569 process Effects 0.000 description 33
- 238000010586 diagram Methods 0.000 description 30
- 230000006399 behavior Effects 0.000 description 16
- 230000003993 interaction Effects 0.000 description 16
- 230000010354 integration Effects 0.000 description 13
- 239000013598 vector Substances 0.000 description 13
- 238000006243 chemical reaction Methods 0.000 description 12
- 230000001960 triggered effect Effects 0.000 description 12
- 230000003068 static effect Effects 0.000 description 11
- 230000005540 biological transmission Effects 0.000 description 10
- 238000012546 transfer Methods 0.000 description 10
- 230000018109 developmental process Effects 0.000 description 9
- 238000007726 management method Methods 0.000 description 9
- 238000011156 evaluation Methods 0.000 description 8
- 238000004519 manufacturing process Methods 0.000 description 8
- 230000009466 transformation Effects 0.000 description 8
- 238000004364 calculation method Methods 0.000 description 7
- 238000010367 cloning Methods 0.000 description 7
- 238000011161 development Methods 0.000 description 7
- 230000033001 locomotion Effects 0.000 description 7
- 238000007792 addition Methods 0.000 description 6
- 230000002457 bidirectional effect Effects 0.000 description 6
- 238000005520 cutting process Methods 0.000 description 6
- 238000012217 deletion Methods 0.000 description 6
- 230000037430 deletion Effects 0.000 description 6
- 238000013519 translation Methods 0.000 description 6
- 238000010304 firing Methods 0.000 description 5
- 238000002360 preparation method Methods 0.000 description 5
- 238000003860 storage Methods 0.000 description 5
- 238000012360 testing method Methods 0.000 description 5
- 102100030356 Arginase-2, mitochondrial Human genes 0.000 description 4
- 101000792835 Homo sapiens Arginase-2, mitochondrial Proteins 0.000 description 4
- 230000008901 benefit Effects 0.000 description 4
- 230000001419 dependent effect Effects 0.000 description 4
- 238000011084 recovery Methods 0.000 description 4
- 230000008929 regeneration Effects 0.000 description 4
- 238000011069 regeneration method Methods 0.000 description 4
- 210000002784 stomach Anatomy 0.000 description 4
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 4
- 238000004458 analytical method Methods 0.000 description 3
- 238000013500 data storage Methods 0.000 description 3
- 238000009826 distribution Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000005304 joining Methods 0.000 description 3
- 239000000203 mixture Substances 0.000 description 3
- 230000001360 synchronised effect Effects 0.000 description 3
- 238000012800 visualization Methods 0.000 description 3
- 102100021723 Arginase-1 Human genes 0.000 description 2
- 101000752037 Homo sapiens Arginase-1 Proteins 0.000 description 2
- 101000800287 Homo sapiens Tubulointerstitial nephritis antigen-like Proteins 0.000 description 2
- VYGQUTWHTHXGQB-FFHKNEKCSA-N Retinol Palmitate Chemical compound CCCCCCCCCCCCCCCC(=O)OC\C=C(/C)\C=C\C=C(/C)\C=C\C1=C(C)CCCC1(C)C VYGQUTWHTHXGQB-FFHKNEKCSA-N 0.000 description 2
- 238000004026 adhesive bonding Methods 0.000 description 2
- 238000005267 amalgamation Methods 0.000 description 2
- 238000013473 artificial intelligence Methods 0.000 description 2
- 244000309464 bull Species 0.000 description 2
- 238000004422 calculation algorithm Methods 0.000 description 2
- 230000006378 damage Effects 0.000 description 2
- 238000000354 decomposition reaction Methods 0.000 description 2
- 230000004927 fusion Effects 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 150000002500 ions Chemical class 0.000 description 2
- 235000021190 leftovers Nutrition 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- WTEVQBCEXWBHNA-YFHOEESVSA-N neral Chemical compound CC(C)=CCC\C(C)=C/C=O WTEVQBCEXWBHNA-YFHOEESVSA-N 0.000 description 2
- 239000000047 product Substances 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 238000000844 transformation Methods 0.000 description 2
- 235000021419 vinegar Nutrition 0.000 description 2
- 239000000052 vinegar Substances 0.000 description 2
- PXFBZOLANLWPMH-UHFFFAOYSA-N 16-Epiaffinine Natural products C1C(C2=CC=CC=C2N2)=C2C(=O)CC2C(=CC)CN(C)C1C2CO PXFBZOLANLWPMH-UHFFFAOYSA-N 0.000 description 1
- XILIYVSXLSWUAI-UHFFFAOYSA-N 2-(diethylamino)ethyl n'-phenylcarbamimidothioate;dihydrobromide Chemical compound Br.Br.CCN(CC)CCSC(N)=NC1=CC=CC=C1 XILIYVSXLSWUAI-UHFFFAOYSA-N 0.000 description 1
- 244000118350 Andrographis paniculata Species 0.000 description 1
- 241000283690 Bos taurus Species 0.000 description 1
- NLZUEZXRPGMBCV-UHFFFAOYSA-N Butylhydroxytoluene Chemical compound CC1=CC(C(C)(C)C)=C(O)C(C(C)(C)C)=C1 NLZUEZXRPGMBCV-UHFFFAOYSA-N 0.000 description 1
- 241000282994 Cervidae Species 0.000 description 1
- WTEVQBCEXWBHNA-UHFFFAOYSA-N Citral Natural products CC(C)=CCCC(C)=CC=O WTEVQBCEXWBHNA-UHFFFAOYSA-N 0.000 description 1
- 102100026190 Class E basic helix-loop-helix protein 41 Human genes 0.000 description 1
- 101000765033 Homo sapiens Class E basic helix-loop-helix protein 41 Proteins 0.000 description 1
- 101000836983 Homo sapiens Secretoglobin family 1D member 1 Proteins 0.000 description 1
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 244000025221 Humulus lupulus Species 0.000 description 1
- 231100000743 Maximale Arbeitsplatzkonzentration Toxicity 0.000 description 1
- 241000238413 Octopus Species 0.000 description 1
- 241000577979 Peromyscus spicilegus Species 0.000 description 1
- 241000287462 Phalacrocorax carbo Species 0.000 description 1
- 208000009989 Posterior Leukoencephalopathy Syndrome Diseases 0.000 description 1
- 102100028659 Secretoglobin family 1D member 1 Human genes 0.000 description 1
- 239000011717 all-trans-retinol Substances 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 239000000872 buffer Substances 0.000 description 1
- 150000001768 cations Chemical class 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- QBWCMBCROVPCKQ-UHFFFAOYSA-N chlorous acid Chemical compound OCl=O QBWCMBCROVPCKQ-UHFFFAOYSA-N 0.000 description 1
- WTEVQBCEXWBHNA-JXMROGBWSA-N citral A Natural products CC(C)=CCC\C(C)=C\C=O WTEVQBCEXWBHNA-JXMROGBWSA-N 0.000 description 1
- 239000003086 colorant Substances 0.000 description 1
- 230000002301 combined effect Effects 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 238000007596 consolidation process Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000012938 design process Methods 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 238000007639 printing Methods 0.000 description 1
- 235000019172 retinyl palmitate Nutrition 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 230000035945 sensitivity Effects 0.000 description 1
- 230000001953 sensory effect Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000003786 synthesis reaction Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
- 238000004804 winding Methods 0.000 description 1
- 230000003245 working effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/10—Requirements analysis; Specification techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
- G06F8/24—Object-oriented
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
- G06F9/45508—Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
- G06F9/45512—Command shells
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09B—EDUCATIONAL OR DEMONSTRATION APPLIANCES; APPLIANCES FOR TEACHING, OR COMMUNICATING WITH, THE BLIND, DEAF OR MUTE; MODELS; PLANETARIA; GLOBES; MAPS; DIAGRAMS
- G09B19/00—Teaching not covered by other main groups of this subclass
- G09B19/0053—Computers, e.g. programming
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- Computer Hardware Design (AREA)
- Entrepreneurship & Innovation (AREA)
- Educational Administration (AREA)
- Educational Technology (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
- Devices For Executing Special Programs (AREA)
- Processing Or Creating Images (AREA)
Abstract
(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。
め要約のデータは記録されません。
Description
【発明の詳細な説明】
【０００１】
【産業上の利用分野】本発明は、コンピュータ・システ
ムおよび通信システムのためのプログラム仕様を開発す
る方法および装置に関する。 【０００２】 【従来の技術】コンピュータおよび電気通信システムの
作用を制御するための複雑なコンピュータ・プログラム
やソフトウェア・システムの開発には、大きな作業努力
を必要とする。コンピュータ・プログラマ（ソフトウェ
ア開発者）は、複雑なソフトウェア・システムの設計、
コーディングおよび検査に多大な努力を費やす。複雑な
システムに対しては、ソフトウェア開発サイクルと言わ
れる設計、執筆およびコーディングの行程に何年もかか
ることもしばしばある。長年に渡りソフトウェア開発者
が学んだことは、ソフトウェアの検査にサイクルをあま
り費やさず、ソフトウェアに対する必要条件の立案、ソ
フトウェアの設計、およびコーディングに大部分を費や
せば、開発周期が短縮されると言うことである。この知
識が、ソフトウェア技術の進歩と相まって、さらに複雑
なソフトウェア・システムの開発をもたらした。 【０００３】ソフトウェア技術の進歩にもかかわらず、
ますます複雑化するコンピュータ・ソフトウェアおよび
ソフトウェア稼働システムの開発は、依然として困難で
ある。この難しさのために、効率的かつ完全なソフトウ
ェア設計システムの重要性が増してきた。仕様設計が、
ソフトウェアの開発を容易にするための重要な第１歩で
ある。仕様書は、ソフトウェア・システムが満足しなけ
ればならない必要条件を含み、システムがどのように作
用しなければならないかを指定するものである。仕様書
は、その記述対象であるソフトウェア・システムと同様
に、生成がますます困難になってきた。これに対する１
つの理由は、仕様の生成に必要なソフトウェア環境の詳
細な知識である。 【０００４】ソフトウェア・システムの作用をモデル化
することによって仕様の開発および検査を行うことの難
しさを軽減するために、ソフトウェア開発者はソフトウ
ェア・シミュレータを使用する。シミュレータは、シス
テムに関する入力に基づいて、そのシステムの作用をモ
デル化するプログラムを生成する。シミュレータは、仕
様の開発に役立つが、問題もいくつかある。第１に、シ
ミュレータは、単純でなじみ深いモデルを基にしておら
ず、システムの適切なモデルを生成するには、少なくと
もシミュレータ「言語」のプログラム作製知識が必要と
なる。開発者は、シミュレーションされるシステムがい
かに作用するかということに関わらなければならないだ
けでなく、シミュレーション・プログラムの開発にかな
りの量の思考を充てる必要がある。こうして、ソフトウ
ェアの仕様設計過程に複雑さが加わることになる。 【０００５】次に、シミュレータは、１つのシステムの
独立した部分に対し特定の入力を要求するとともに特定
の出力を与えて、その部分を別個の実体として表す。こ
れらの実体の入力と出力が一致しない限り（しばしば一
致しない）、実体どうしが互いに作用し合う（「接続」
される）ことができないので、問題である。このように
、シミュレータを使用する開発者は、システムの部分の
全体的な統合を常にみることはできない。 【０００６】最後に、シミュレーション中に開発者が、
誤りを発見したり、システムの作用のある部分を望む場
合、開発者は、シミュレーションを停止し、所望の変更
を行い、シミュレートするべきプログラムをコンパイル
しなおしてから、シミュレーションを最初から始めなけ
ればならない。このように、開発者は、変更結果を直ち
に見ることができないため、変更を行う処理に時間がか
かり、時間を非効率的に使用する結果となる。 【０００７】 【発明が解決しようとする課題】従って、従来の技術の
課題は、利用者の広範なプログラミング知識を必要とし
ないソフトウェアの効率的な仕様設計手段を与えること
である。 【０００８】 【課題を解決するための手段】前記の問題を解決するた
めの本発明の一実施例は、仕様の画像記録およびアニメ
ーションのための（ＧＲＡＳ＝Ｇｒａｐｈｉｃａｌ Ｒ
ｅｃｏｒｄｉｎｇ ａｎｄ Ａｎｉｍａｔｉｏｎ ｏｆ
Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ）システムである。Ｇ
ＲＡＳシステムは、プログラム仕様の記録、シミュレー
シ（アニメーション）、および洗練をグラフィカルに行
うために使用される。このシステムは、実例によるプロ
グラム仕様の設計に対応している。 【０００９】ＧＲＡＳシステムの目的は、プログラミン
グの知識が少ない利用者がプログラム仕様を容易に作る
ための便宜を与えることである。この目的は、馴染み深
いモデルに基づくユーザ・フレンドリな環境を与えるこ
とによって達成される。ＧＲＡＳシステムは、プログラ
ム用の仕様の作製が演劇の作製、演出、テープ録画、お
よび編集に類似するビデオ・スタジオの隠喩（ｍｅｔａ
ｐｈｏｒ）（ＶＳＭ）に基づいている。ビデオ・スタジ
オ・メタファは、リハーサルによるプログラミングで用
いられる劇場の隠喩（ｔｈｅａｔｅｒ ｍｅｔａｐｈｏ
ｒ）を拡張する。例えば、ゼロックス社の１９８６年５
月のＳＣＬ−８４−１のローラ・グールド（Ｌａｕｒａ
Ｇｏｕｌｄ）およびウィリアム・フィンツァ（Ｗｉｌ
ｌｉａｍ Ｆｉｎｚｅｒ）による「リハーサルによるプ
ログラミング（Ｐｒｏｇｒａｍｍｉｎｇ ｂｙ Ｒｅｈ
ｅａｒｓａｌ）」を参照。ＶＳＭに基づくシステムを用
いて仕様を作製するには、プログラミングの知識はあま
り必要ない。技術者は、仕様設計システムには注意をほ
とんど向けずに、目的のシステムが如何に作用するべき
かに集中することができるので、ソフトウェアの仕様設
計過程において複雑さが軽減され、好都合である。 【００１０】ＧＲＡＳシステムでは、仕様のソフト的記
録手段である「テープ」に対し、利用者が入力を与える
。ＧＲＡＳシステムは、一群のシナリオ例のステップを
記録することにより、またそれらのシナリオ例に対する
追加的なグラフィック規則を引き出すことにより、テー
プを生成する。１つのステップにより、シミュレートさ
れるテープのアクタどうしの間のメッセージ渡しによる
相互作用が指定される。（後述のように、「アクタ（ａ
ｃｔｏｒ）」の概念は、人工知能の分野で周知である。 ） 【００１１】アクタは、データとそのデータを操作する
手続きとを備えたコンピュータ・ソフトウェア構造であ
る。ＧＲＡＳで使用されるアクタも、知識ベースおよび
そのデータへの変更の履歴を持っている。アクタは、電
話若しくは電話交換システムなどのシステムの物理的構
成要素、またはプロセス若しくはデーターベースなどの
ソフトウェア構成要素、またはそのシステムと相互に作
用する作因、人などを表す。ＧＲＡＳでは、シナリオ例
の１ステップを記録するために、利用者は、そのステッ
プ用のセンダ（ｓｅｎｄｅｒ）およびレシーバ（ｒｅｃ
ｅｉｖｅｒ）のアクタ、センダのアクタからレシーバの
アクタに送られるメッセージ、およびそのステップが実
行される前にシステムに存在していなければならない条
件を指定する。 各ステップは、テープ上に規則として記録され、そのシ
ナリオ例において実行される。利用者は、そのシナリオ
例の実行（そのテープの再生）、修正の実施、新たなス
テップの追加、または新たなシナリオ例の生成によって
、そのテープを対話的に洗練することができる。 【００１２】コンピュータ・システムに対するコンピュ
ータ・ログイン・シーケンスの設計は、ＧＲＡＳの簡単
な使用例となる。コンピュータ・ログイン・シーケンス
のためのアクタは、コンピュータ、端末、および利用者
である。ＧＲＡＳを使用する技術者が、コンピュータ・
ログイン・シーケンスを次のように実現することを希望
するものと仮定する。即ち、（１）コンピュータが、「
ｓｅｎｄｌｏｇｉｎ」要求メッセージを端末に送ること
によって、そのシーケンスを活性化する。（２）次に、
端末が、ログイン・プロンプトを利用者に表示する。（
３）利用者が、ログイン・ネームをキーボード入力を介
して端末に送る。（４）端末が、そのログイン・ネーム
をコンピュータに送信する。（５）コンピュータが、そ
の端末にパスワード入力手順を開始するようにメッセー
ジを送る。（６）端末が、パスワード・プロンプトを利
用者に表示する。（７）利用者が、パスワードをキーボ
ード入力を介して端末に送る。そして、（８）端末が、
そのパスワードをコンピュータに送る。 【００１３】このコンピュータ・ログイン・シーケンス
のテープのための入力を与えるために、ＧＲＡＳの利用
者は、そのシーケンスの最初のステップを指定すること
によって開始する。これを行うことで、利用者は、１つ
のシナリオ例の最初のステップを指定することになる。 完全なプログラムは、複数のシナリオ例によって記述さ
れる。前記のステップ（１）を指定するには、まずセン
ダのアクタをコンピュータに、レシーバのアクタを端末
に、渡されるメッセージを「ｓｅｎｄ ｌｏｇｉｎ」に
指定する。 このステップは、利用者にグラフィカルに表示される一
方、そのシナリオ例の一部として記録される。前記のス
テップ（２）を指定するために、利用者は、センダ・ア
クタを端末に、レシーバ・アクタを利用者に、そして渡
されるメッセージを「ログインして下さい：」と指定す
る。やはり、このステップも、記録されつつ、利用者に
グラフィカルに表示される。そして、利用者は、そのシ
ーケンスの残りのステップを同じ要領で指定する。シー
ケンスを記録した後、利用者は、そのテープを再生する
ことにより、そのコンピュータ・ログイン・シーケンス
をグラフィカルにシミュレートする。コンピュータ・ロ
グイン・シーケンス全体のＧＲＡＳによるグラフィカル
な表示を図５に例示する。 【００１４】利用者は、記録中いつでも記録を停止して
、既に指定したステップをシミュレートするためにテー
プを再生することができる。ステップが正しくなければ
、そのステップの対話的な「アンドゥ」、アクタの変更
、メッセージの変更、またはそのステップに対する事前
条件の変更を行った後、そのステップを再び再生するこ
とができる。これにより、プログラム仕様の編集および
洗練が対話的に可能となる。 【００１５】前記の例は、本発明の作用を説明するもの
であるが、本発明の原理によれば、コンピュータが利用
者の入力に対話的に応じてプログラムの仕様を生成する
。当分野はさておき、このプログラム仕様システムによ
って、仕様に対し対話的に与えられる変更に応じて、そ
の仕様のプログラムを再コンパイルすることなく、それ
らの変更のシミュレーションを直ちにグラフィカルに表
示する便宜が提供される。開発者は、より迅速に、より
効率的に、しかもシミュレーション・システムの操作の
知識もほとんど無しに、仕様を作製することができるの
で、好都合である。 【００１６】当分野からさらに逸れるが、本発明により
、アクタ（これは、データの構造とプログラム手順から
なるソフトウェア対象である）の合併、およびアクタの
作用の合併がサポートされる。「アクタ」という考えは
、人工知能に由来する周知の概念である。例えば、１９
８６年、ＭＩＴプレス刊のガル・アーガ（Ｇｕｌ Ａｇ
ｈａ）による「アクタ−−−−分散システムにおける同
時処理のモデル（Ａｃｔｏｒｓ： Ａ Ｍｏｄｅｌｏｆ
Ｃｏｎｃｕｒｒｅｎｔ Ｃｏｍｐｕｔａｔｉｏｎ ｉ
ｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ）」を参
照のこと。この合併処理により、開発者は、プログラム
・システムの部品の全体的な統合を見ることが可能とな
る。 【００１７】本発明の典型的な実施例であるＧＲＡＳは
、ＶＳＭに基づくオブジェクト指向で知識ベースの視覚
的プログラミング・システムである。ＧＲＡＳは、利用
者の入力を用いてシステムの視覚的シミュレーションと
仕様データーベースを生成し、さらに詳細な入力を受信
した時、そのデーターベースを増強する。ＶＳＭは、親
しみやすい単純なモデルを提供するので、プログラミン
グについても、そのシステムについても詳しい知識なし
に仕様を生成することができるので、好都合である。 【００１８】仕様のシナリオ例の記録（入力）、再生（
実行）、およびアンドゥ（逆向きの実行）を行うための
機構が、ＧＲＡＳのソフトコーダ（ＳｏｆｔＣｏｄｅｒ
）モジュールによって提供される。ソフトコーダは、ア
クタ間の作用の規則を記述する「（ビデオ）テープ・プ
ログラム」を処理して、仕様プログラムの実行の完全な
履歴からなる「テープ・シナリオ」を生成する仮想的な
装置である。テープ・プログラムの各ステップは、算術
演算および（または）論理演算の集合、アクタ・データ
、およびステップを「アンドゥ」することによって逆戻
りすることができるために仕様の一部を対話的に変更す
る機構を利用者に提供するアクタ間の通信を表すメッセ
ージからなる。効率的に誤りを訂正し、シミュレーショ
ン中に仕様の変更を行って、その結果を直ちに見ること
ができるので、好都合である。ＧＲＡＳのビジュアル・
オブジェクト網管理（ＭｏＶｏｎ＝ｍａｎａｇｅｍｅｎ
ｔ ｏｆ ｖｉｓｕａｌ ｏｂｊｅｃｔ ｎｅｔｗｏｒ
ｋｓ）モジュールおよびアクタ・フレーム（ＡＦ）モジ
ュールにより、アクタおよびアクタの作用を合併する機
構が提供されるため、利用者は、全体的に統合された仕
様を見ることが可能となる。ＧＲＡＳは、仕様の別個の
部分の統合および組み合わされた作用を見る便宜を利用
者に与えるので、好都合である。 【００１９】プログラム用の仕様を対話的に生成する方
法は、キーボードやマウスなどの入力装置を介したアク
タ・データの受信に応じて、複数のテープ・シナリオに
対するアクタを指定すること、およびそのアクタ・デー
タを格納することからなる。アクタの指定には、新たな
アクタの生成、以前に生成されたアクタの選択、および
アクタ・データの修正が含まれる。システムは、入力装
置を介して作用ステップを受信すると、これに応じて、
そのステップを後の実行のために記録する。これらのス
テップは、アクタ間の通信、アクタ間の関係、アクタに
対する論理的または算術的な演算、および複数のテープ
・シナリオに対する判断点からなる。最初の判断の選択
を入力装置を介して受信すると、これに応じて指定の一
貫性を評価するために、最初のテープ・シナリオが実行
される。最初のテープ・シナリオの実行は、一組の所定
の条件の発生に基づいてシナリオのステップをシミュレ
ートし、そのシミュレーションの結果を記録することか
らなる。シミュレートすることは、アクタ間の関係の表
明、アクタ間の通信の実行、アクタに対する論理的また
は算術的な演算の実行、または判断による選択の入力の
要求のうちの１つまたはそれ以上からなる。最終的に、
判断の選択が入力装置を介して代わる代わる受信され、
それに応じて、追加のテープ・シナリオが順次実行され
る。 【００２０】このシステムは、作用ステップのシミュレ
ーション中に入力装置を介して受信した命令に応じて、
指定された作用ステップの後にシミュレーションを停止
するようになっている。そして、入力データの受信に応
じて、追加のアクタ・データおよび追加の作用ステップ
をシステムが格納し、その追加のステップおよびアクタ
を含めて、シミュレーションが再開される。対話的に仕
様の追加を行い、それらの追加の結果を直ちに見ること
ができるので、好都合である。作用ステップは、シミュ
レーション中に逆進可能（「アンドゥ可能」）である。 復元（アンドゥ）されたステップは修正されて、シミュ
レーションが再開され、その復元されたステップは、修
正された内容で再びシミュレートされる。仕様の変更を
対話的に行い、その変更結果を直ちに見ることができる
ので、好都合である。 【００２１】作用ステップをシミュレートすることは、
プログラム経路が指定されていない判断箇所の選択を自
動的に識別すること、これらの選択および不完全なプロ
グラム経路を利用者に通知することからなる。また、作
用ステップをシミュレートすることには、アクタ・デー
タが完全であるかどうかを確認し、不完全なデータを利
用者に知らせることも含まれる。このように、不完全な
仕様もシミュレートできるので都合がよい。本システム
では、複数の水準の表示が可能であり、各水準は、シミ
ュレーションの詳細水準に対応する。利用者は、各作用
ステップに対し、異なる水準集合を指定することができ
る。テープ・シナリオを実行する場合、ＧＲＡＳシステ
ムは、その集合の要素である水準にあるステップに限り
、その結果を表示するが、実際には、他の指定された水
準のすべてのステップをシミュレートしている。利用者
は、情報がさらに利用できるようになったときに、より
詳細なステップを仕様に追加し、それらのより詳細なス
テップのシミュレーション結果を見ることによって、仕
様を対話的に洗練することができるので、好都合である
。 【００２２】ＧＲＡＳシステムでは、２つ以上の作用ス
テップを同時にシミュレートすることが許される。本発
明のシステムでは、同時に発生するプログラム経路の両
方に共通のアクタがある場合、その共通のアクタのデー
タにアクセスしようとする他のアクタどうしが、同じデ
ータを同時にアクセスしないことが保証される。本シス
テムでは、そのテープ・シナリオのあるステップのシミ
ュレーションを所定の時間だけ遅らせたり、または最初
の作用ステップシミュレーション時刻からシミュレーシ
ョン中に算出された時間だけ遅らせたり、あるいは最初
の作用ステップのシミュレーションを２番目の作用ステ
ップがシミュレートされるまで遅らせたりすることが可
能である。本システムでは、呼び出されたテープ・プロ
グラムを呼び出しているテープ・プログラムの実行の一
部として実行し、その呼び出されたテープ・プログラム
の実行に続いて、呼び出しているテープ・プログラムに
戻ることも可能である。また本システムでは、第１のテ
ープ・プログラムの第１の作用ステップのシミュレーシ
ョンの後と前記第１のテープ・プログラムの第２のステ
ップのシミュレーションの前との間に、第２のテープ・
プログラムの部分集合のコピーを挿入することも可能で
ある。作用ステップの同時シミュレーションによって、
システムの作用の現実的な考察が与えられる結果、首尾
一貫した仕様が生成され、好都合である。 【００２３】 【実施例】仕様に関するグラフィカルな記憶および動画
（ＧＲＡＳ＝Ｇｒａｐｈｉｃａｌ Ｒｅｃｏｒｄｉｎｇ
ａｎｄ Ａｎｉｍａｔｉｏｎ ｏｆ Ｓｐｅｃｉｆｉ
ｃａｔｉｏｎｓ）のシステムは、この種のシステムにと
って有用な特別な術語体系で記述された主要な概念に基
づく。これらの専門用語を理解することは、ＧＲＡＳシ
ステムの理解に役立つので、ＧＲＡＳで使用される特殊
な専門用語を以下において定義する。 【００２４】重要用語集 バックステージ：所与の制作スタジオに所属する各アク
タ（役者の意）は、その特有のアドレス（例えば、出生
名と住所、社会保証番号）で分かる。一度に利用できる
全アクタの集合をバックステージ（舞台裏の意）と呼ぶ
。各アクタは、仮にそれが幾つかのテープで使用され、
そのＧＲＡＳシステムで現在利用可能なテープの間で物
理的に共有されていても、この文脈においては、ただ１
つの存在でしかない。テープが録音される前かされてい
る間に、１つ以上のスタジオ室を選択することができる
。各スタジオ室は、異なる視野または眺望を記録するの
に使用でき、各スタジオは、記録カメラを持っている。 必要に応じて、記録の前か記録中に、アクタの選択／追
加が行われる。 【００２５】フレーム：フレームは、情報の分類または
概念の組織化に使用される柔軟なデータ構造である。こ
のデータ構造の柔軟性は、フレームが通常、拡張可能か
つ再定義可能であると言う事実からきている。フレーム
・システムは、通常、ＩＳ−ＡまたはＡＫＯ（Ａ−ｋｉ
ｎｄ−ｏｆ）分類法に基づく階層的な継承機構を備えて
いる。 【００２６】アクタ：アクタは、オブジェクトの拡張で
ある。オブジェクトは、データとそれを操作する手続き
（プロシージャ）からなる。アクタは、データを（スロ
ットと値を用いて）オブジェクトととしてカプセルに包
む。しかし、カプセル化された集合のスロットだけでな
く、それらのスロットの値も、時間と共に変化すること
ができ、これらの変化は、可逆的である。隠喩的観点か
らすれば、アクタは、情報の範疇および情報の値を記憶
したり忘れるだけでなく、その寿命期間内の特定の瞬間
にそれが持っていた情報を思い出すことも可能である。 この特徴を実現するために、アクタは、そのデータ空間
（スロットおよび値）に為された変更の履歴をとってい
る。アクタは、任意の時刻にその時点のデータ空間の記
号による記述を生成したり（自己記述）、２つの異なる
時刻における記号的データ空間の間の差の記号による記
述を生成したりすることができる。これらの記述内容は
、アクタ・システムの実施によって、履歴に維持される
。 【００２７】アクタの実施：ＧＲＡＳに対しアクタを実
施することにより、次の可能性がサポートされる。アク
タの一般的な性質として、新たな役割を記憶し、前の役
割を忘れ、存在する情報を変形させ、新たな情報を獲得
し、他のアクタに情報を伝達し、（オプションで）種々
の衣装でいるのが見られる（可視的表現は、このような
アクタにあってもなくてもいい属性である）という能力
がある。アクタは、共有、再利用、合併、分割、幾つか
のアクタの組み合わせとしての生成、またはサブアクタ
への分解が可能である。論理的または算術的な演算に基
づいて、アクタの役割を特定の状況によって変更するこ
とができる。 【００２８】アクタの知識ベース：蓄積（記憶）および
削除（忘却）が可能なアクタの属性の集合が、アクタの
動的で機密性の知識ベースを構成する。ここでは知識ベ
ースの機密性は、次の意味で定義される。即ち、知識は
、他のアクタと共有されておらず、他のアクタが直接利
用することはできない。あるアクタの情報を他のアクタ
が利用できるのは、他のアクタが処理中に明確にそれを
要求した場合に限られる。アクタの知識ベースは、アク
タの環境を用いて定義される。アクタのデータ空間の記
述Ｄ（Ａ，ｔ）の実現。 【００２９】アクタと継承：アクタのフレームの記述に
用いられるＡＫＯ関係は、フレームの分類を与えるため
に内部的に使用される。しかし、ＧＲＡＳにおいては、
利用者がＡＫＯ関係を直接利用することはできない。ア
クタに関し利用できる操作（処理）の集合は、利用者が
多重継承を必要とすることなく通信のアクタ指向モデル
を設計するに十分である。ＧＲＡＳがアクタ・システム
によって半自動的に維持できるならば、継承がＧＲＡＳ
の利用者に与えられるだけである。 【００３０】アクタの合併および融合：アクタ・モデル
では、合併という概念とその実現とによって、さらに柔
軟性が提供される。次のようにいろいろな水準の合併が
可能である。 【００３１】１）改名：アクタのステージ名を新たなス
テージ名で置き換え、そのアクタは同じ規則の集合を使
用する。ここで、ステージ名は、特定のシナリオの実行
において、このアクタを参照するために使用される名称
である。 【００３２】２）アドレスの変更：アクタのアドレス（
識別情報）を変更する。新たなアドレスが既存のアクタ
のアドレスである場合、実際に合併が行われる。 【００３３】３）合併：アクタＡが既存のもう１つのア
クタＢと合併される場合、合併の種類は、結果としての
新たなアクタＣがＢ（属性と関係）になるものから、Ｃ
がＡになったり、ＣがＡおよびＢの属性と関係との組み
合わせになるものまで、連続的に変化し得る。ただし、
何れの場合も、結果として得られるアクタＣは、Ａおよ
びＢのすべての規則を継承している。これらの規則の適
用可能性は、Ｃの結果としての属性と前の規則との関数
である。全く適合しない規則ならば、それらを取り除い
ても良い。規則の管理の一部は、論理的分析および到達
可能性アルゴリズムに基づいて自動化することができる
。 【００３４】４）融合：アクタが第２のアクタに完全に
加えられ融合する（Ｃ＝Ａ＋Ｂ）。これは、完全な合併
の場合である。この結果は、その融合が起こる前に何れ
かのアクタが使用された場所ならどこでも使用される新
たなアクタである。従って、新たなアクタは、両方のア
クタのすべての規則を継承する。また、新たなアクタは
、両方のアクタからすべての関係および構成要素も継承
するという意味では「怪物」である。例えば、端末を普
通の旧式電話サービスの（ＰＯＴＳ）電話と融合する場
合、結果として得られる「怪物」は、端末とＰＯＴＳ電
話との両方の特徴を持った電話端末である。この「怪物
」は、ＰＯＴＳ電話の特徴を持った端末とも、端末の特
徴を持ったＰＯＴＳ電話とも解釈することができる。 この特徴は、新たな設計について実験を行う場合に役立
つ。 【００３５】２つのアクタを合併することは、アクタと
それらの関係から成る２つのネットワークを合併するこ
とになる可能性がある。アクタのネットワーク（アクタ
網）は、関係によって接続された一群のアクタから成る
。例えば、アクタ網は、一種の（ＡＫＯ＝Ａ−Ｋｉｎｄ
−Ｏｆ）関係に基づくことができる。１つのアクタ網（
ＮＡ）が、一種の（Ａ−Ｋｉｎｄ−Ｏｆ）ドイツ人であ
るすべてのアクタから成ることもあれば、別のアクタ網
（ＮＢ）が、一種の（Ａ−Ｋｉｎｄ−Ｏｆ）フランス人
であるすべてのアクタから成ることもある。アクタＡが
一種のドイツ人であり、かつアクタＢが一種のフランス
人である場合、（ＮＡ）と（ＮＢ）との合併は、すべて
のドイツ人がフランス人になるか、すべてのフランス人
がドイツ人になるか、すべてのドイツ人およびフランス
人がフランス系ドイツ人、即ち両人種の組み合わせにな
るかの何れかになる可能性がある。 【００３６】アクタに与えられる合併処理は、動的であ
り、利用者が実行時に呼び出すことができる。さらに、
アクタは、それ自体の属性および関係の変化を記憶する
能力を持っているので、アクタに関する他のすべての処
理と同様に、合併処理を元どうりにする機構（ｕｎｄｏ
）を実行することができる。 【００３７】分解機構を与え、１つの複雑なアクタから
１組のさらに単純なアクタどうしの間の通信機構へと設
計の展開を助けるために、分割作用素を利用できるよう
にする。これは、伝達情報の送信または処理が最小単位
の処理であるから、特に重要である。分割により、伝達
情報をさらに小さな単位の処理へと分解する機構が与え
られる。 【００３８】アクタとオブジェクト：アクタは、メッセ
ージ伝達方法を明確に定義されることがない代わりに、
属性および作用の記憶および忘却、伝達情報の送信およ
び処理、ならびに作用のシミュレーションを行う基本的
な方法を、そのアクタのクラスから継承する。はじめか
ら種々の（所定の）クラスから継承する代わりに、必要
に応じて新たな情報のスロットおよび値を追加なり、変
更なり、削除なりを行って、アクタを累進的に定義・洗
練することができる。比喩的に言えば、あるアクタの「
個性」、即ち一般的な作用は、前もっては分からないが
、このアクタが演じているすべてのテープから実験的観
察に基づいて集められる。アクタは、所定の組の作用に
関して、従来のオブジェクトのように独自に存在してい
るわけではなく、種々の作用がそれらのために利用でき
るようになる種々のシナリオを背景として存在するので
ある。 【００３９】オーディション：所与の作業（タスク）を
行うアクタを選択するために用いられる処理（プロセス
）を指す。アクタは才能によって選択される。ここで、
才能は、アクタの属性（属性は、そのアクタの作用と直
接連絡している）とそのアクタおよび他のアクタの間の
現在の関係的依存状態の集合との関数として定義される
。オーディションの処理（ａｕｄｉｔ）には、アクタの
要員の中から所与の作業を行う適任者を特定することが
伴う。 【００４０】生成（ｃｒｅａｔｉｏｎ）：才能の記述に
従って新たなアクタを生成する処理である。新たなアク
タのデータ構造は、前記の記述に匹敵する内部の属性に
よって作られる。生成処理によって、アクタと関係から
成る集合（アクタ網）を生成する結果になることがある
。才能の記述が空の場合、最小のアクタのデータ構造が
生成される。アクタの才能の記述に特定のアクタのアド
レス（識別情報）が入っている、つまりアクタの才能の
記述の評価結果が特定のアクタのアドレスとなるならば
、そのアドレスにはアクタが既に存在し、そのアクタが
再利用される。 【００４１】破壊：これは、アクタ要員アドレスからあ
るアクタのアドレスを削除し、その履歴を停止し、さら
にそのアクタのデータ構造、他のアクタとの関係および
（オプションで）現在見えている装置からそのアクタの
可視表示を削除する作用である。システムの実現状態の
よって、この処理が「ガーベジ・コレクション」（不要
になったデータの削除）を伴うことがあったり、なかっ
たりする。代用：アクタが作業を完成することができな
い場合、その代わりに代用アクタを選択することができ
る。代用は、オーディション処理を用いて行われる。 【００４２】転送：２つのアクタがある場合、ＡからＢ
への転送は、ＡおよびＢのそれぞれのアドレス（識別情
報）は維持しながら、すべての属性および関係をＡから
Ｂに与えることになる。 【００４３】クローン生成：アクタのクローン生成によ
り、元のもののすべての属性を持つ、そのアクタの新た
なインスタンスが作られる。クローンは、クローンと元
のアクタの何れか一方の属性の中の１つに変更が為され
るまでは（空間を節約するために）元のアクタと属性を
共有することができるが、変更されると、属性は物理的
に分離される。アクタ自体であるアクタの属性は別とし
て、最初は、デフォルトによって、すべての値が、元の
アクタとクローンとの間で共有される。例えば、システ
ムにおいて、あるアクタが２つの属性、即ち送受話器お
よび電話番号を持つ電話であると仮定する。すると、送
受話器もアクタとなり得る。この例において、送受話器
もアクタである場合、この電話をクローン生成すると、
クローンとオリジナル（元のアクタ）は、はじめ電話番
号の値を共有するが、同じ送受話器は共有しない。これ
は、クローンの送受話器の「属性」が新しいアクタだか
らである。値だけが、クローンとオリジナルとの間で共
有されるのであって、アクタは共有されない。 【００４４】アクタをクローン生成すると、ある関係に
よって互いに接続されたアクタ網（例えば、１つのアク
タと、部分の関係（Ｐａｒｔ−Ｏｆ ｒｅｌａｔｉｏｎ
）にあるその幾つかの構成要素と）のクローンを生成す
ることがある。クローンはそのオリジナルとは異なった
アドレスを持つ。クローン生成は、（データが、変更さ
れるまでは再利用されるので）費用のかからないコピー
を作る機構である。 クローンの（オプションの）視覚的表現は、例示された
アクタの名称でのインスタンス番号の追加を除けば、オ
リジナルと同じである。 【００４５】作用規則：ビデオ・スタジオの比喩（ＶＳ
Ｍ＝Ｖｉｄｅｏ Ｓｔｕｄｉｏ Ｍｅｔａｐｈｏｒ）で
は、作用の規則は、（事実の独立した知識ベースとして
使用される）アクタの集合、これらの知識ベースの叙述
子の組み合わせ、アクタ間の通信メッセージの集合、お
よび計算と表明の集合を含めるための、前記の定義の拡
張である。アクタ集合Ａについての作用規則Ｒは、次の
形式を用いて記述することができる。 Ｒ（Ａ）：ｆ（Ｐ（Ａ））＝＞Ｍ（Ａ）＝＞ｇ（Ｑ（Ａ
，Ｍ（Ａ）））ただし、Ａはアクタの集合であり、Ｐ（
Ａ）はアクタに関する叙述子の集合であり、ｆ（Ｐ（Ａ
））は、これらの叙述子の関数（例えば、ブール表現）
であり、Ｍ（Ａ）は、アクタ間の通信のオプションの集
合であり、Ｑ（Ａ，Ｍ（Ａ））は、そのアクタの知識と
通信集合Ｍ（Ａ）から得られる情報とに基づいて集合Ａ
のアクタに対して行われる計算およびその結果としての
表明の集合であり、ｇは、規則Ｒ（Ａ）の完成の尺度と
して用いられる合成関数（例えば、ブール表現）である
。ブール的仮定の下では、Ｒ（Ａ）の実行が成功裏に終
了した場合、ｇ（Ｑ（Ａ，Ｍ（Ａ）））は、真でなけれ
ばならない。 【００４６】Ｒ（Ａ）の定義において、集合Ａは、Ａ＝
ａ１、ａ２、．．．．、のようにあからさまに（即ち、
列挙して）定義することも、抽象的に定義することも可
能である。Ａが抽象的に定義される場合、規則Ｒ（Ａ）
に対するアクタを特定する論理規則の集合Ａ＝Ａｕｄｉ
ｔ｛Ｘ１，Ｘ２，．．．，Ｘｎ｝を用いてＡを記述する
ことができる。これらの論理規則によって、所与の役割
を演じるために各アクタに要求される特性｛Ｘ１，Ｘ２
，．．．，Ｘｎ｝を描写することができる。特性は、ア
クタの属性と値とで構成されたパタン一致表現でよい。 例えば、種類の検査、クラス依存状態の検査、接続種類
の検査（「ａ」と「ｂ」との間にワイヤ接続がるか？）
、または値の照合（この局に８００という電話番号があ
るか？）をアクタの特性に含めることができる。Ｒ（Ａ
）に対する特性の集合によって記述される候補のアクタ
を特定するために、オーディション処理（ａｕｄｉｔ）
が使用される。Ａのアクタを記述する規則によって、新
たなアクタの生成、既存のアクタの再利用または組み合
わせを要求することができる。 【００４７】ＯＯスクリプト：センダ（ｓｅｎｄｅｒ）
のアクタとレシーバ（ｒｅｃｅｉｖｅｒ）のアクタとの
間の単一処理を表すのに使用される特定のフォーマット
およびシンタックスを指す。ＯＯスクリプトは、２つの
アクタの間の単一処理の特定のテキスト表現である。各
ＯＯスクリプトを使用して、１つ乃至２つのアクタを伴
う作用の１つの規則を記述するすることができる。しか
し、ＯＯスクリプトのシンタックスでは、アクタの記述
ができない。ＯＯスクリプトの表現は、先に定義した作
用規則に対する正式な表現の部類に属する。ＧＲＡＳの
実施において、（推論エンジンによって維持される）内
部の規則構造と利用者（または外部のアプリケーション
・システム）との間のインタフェースをとる単純なテキ
スト・フォーマットを与えるために、例えば、ＯＯスク
リプトのタプル（一定数の要素の集合）が用いられる。 【００４８】役割：アクタの役割は、所与の状況におい
てそのアクタに適用されるすべての作用規則の集合であ
る。１つのアクタに対する各作用規則は、他のアクタと
の相互作用を必要とするため、アクタの作用を動的に変
更することが可能である。 【００４９】ＶＳＭにおけるテープ テープ・プログラム：テープ・プログラムには、アクタ
の初期（およびオプション）の集合と、スクリプト規則
の集合またはアクタ間の作用規則を定義する一般スクリ
プトとが入っている。テープ・プログラムは、その実行
に必要なすべてのアクタを備えている場合、アクタ妥当
（ａｃｔｏｒ ｃｏｒｒｅｃｔ）であると言う。同様に
、テープ・プログラムは、その実行に必要な作用規則を
備えている場合、規則妥当であると言い、その実行に必
要なテープ・プログラムへの参照情報をすべて備えてい
る場合、サブテープ妥当という。テープ・プログラムに
は、その実行に必要なすべてのアクタおよびすべての規
則（または他のテープ）が掲げられている。スクリプト
規則または一般スクリプトを用いて初期のアクタを生成
することができるので、テープ・プログラムは、初期の
アクタの空集合を持つこともある。 【００５０】テープ・シナリオ：テープ・プログラムの
実行によって、１つ以上のテープ・シナリオが演出され
る。テープ・シナリオは、シナリオの変形に対応する元
のテープ・プログラムからの所与の集合のスクリプト規
則の実行履歴である。 【００５１】テープ：テープを構成するのは、未来のリ
ール、即ちテープ・プログラムおよび（１つ以上の実行
済みのテープ・シナリオからなる）過去のリールと言う
２つのリール、テープ・カウンタ、初期アクタのオプシ
ョン集合、その視覚化に必要なオプションの多重視野の
記述、および参照と参考情報の利用に使用される追加的
な情報である。未来のリールは、利用可能な作用の集合
を表し、過去のリールは、そのテープの実行の履歴を表
す。過去のリールには、前に使用された規則のインスタ
ンス、それらの規則に関与したアクタの履歴が入ってい
る。テープ・カウンタは、そのテープ（過去のリール）
において既に実行されたステップ数に対する模擬計数（
または回数）を示す。テープが完全に巻き戻されると、
過去のリールは空になる、つまり実行の履歴が失われ、
未来のリールには、それまで得たすべての規則の集合が
入る。 【００５２】テープのクラス：テープのクラスによって
、ビデオ・テープまたはフィルムの編集の類似性に基づ
いて半自動（支援付き）プログラム操作をサポートする
のに必要な計算体および作用素のクラスが規定される。 【００５３】テープ・シェルフ：テープ・シェルフは、
テープの集合である。 【００５４】伸縮可能テープ：テープは、スーパー８ム
ービーのように編集、切断および張り合わせができるの
で、何本かのテープを１本にまとめ組み合わせるだけで
なく、スクリプトおよび作用を容易に変更することもで
きる。テープは、特定の通信について新たな情報や詳細
をさらに受信するために、録音中に自動的に延長される
。また、ＧＲＡＳシステムによって生成されたり利用者
の入力に応じた追加的なスクリプト規則を２つの既存の
ものの間に挿入する余地を与えるために、テープは自動
的に延長される。テープの実現により、いろいろな詳細
水準での多重（各テープは、多重トラックを有する）録
音がサポートされる。ＶＳＭでは、録音によって既存の
スクリプトがテープから消去されるのではなく、新たな
スクリプトが既存のスクリプトの間に挿入される。スク
リプトの削除は、切断またはスクリプト規則を削除する
ためのメニュー選択（コマンド）によって行われる。 【００５５】テープの切断：テープの切断は、現在の位
置（シミュレートされた時刻）で起こり、それ自体で有
効な２つのテープを生成する。テープを切断するには、
フィルム・エディタを選択する。切断後、これらのテー
プは、共にテープ・シェルフに格納される。テープは、
切断される前にコピーが取られる。テープを切断すると
一方の側に未来のリールを追加し、他方の側に過去のリ
ールを追加することによって、自動的に修復された２つ
の半分のテープが作られ、２つの新たな実行可能なテー
プが出来る。利用者は、新たな２つのテープを指名する
ように促される。 【００５６】テープの接合：テープの接合は、２つ以上
のテープを一続きのテープに継ぎ合わせる。テープを接
合するには、フィルム・エディタを選択する。テープは
接合される前にコピーされ、第１のテープの過去のリー
ルおよび第２のテープの過去のリールは、解かれないな
くてもよい。次ぎに、第１のテープの最後が、他方のテ
ープの先頭に接合され、この処理の間に、２つの余った
リールは消滅する。 【００５７】利用者は、２つ以上のテープを一緒に接合
することができる。いくつかのテープを接合すると、そ
れらのテープの内部表現は同一でも、順次シミュレーシ
ョン・モードで映されるテープは連続実行となり、同時
シミュレーション・モードでは並列実行となる。 【００５８】テープの照会：テープの照会により、アク
タおよび伝達情報の部分的な記述が記録されたテープが
参照される。部分的な記述は、事前条件、事後条件およ
びメッセージに対するオーディション表現およびパタン
・マッチング表現とすることができる。スクリプト構造
体についてのパタン・マッチングによって所与の集合の
スクリプト規則から同様の伝達情報を検索するために、
テープの照会によるアクタ間の通信が使用される。 【００５９】内部テープ呼び出し：現在のテープを実行
しながら、テープ・シェルフから直接テープ（サブテー
プ）を呼び出すこと。呼び出しは、現在のテープにおけ
るスクリプト規則に対する事後条件が契機となる。そし
て、現在のソフトコーダ（ＳＯＦＴＣＯＤＥＲ）の状況
下で実行されるテープのインスタンスが生成される。現
在使用されているアクタ・システムは、設計者の裁量で
サブテープによって再利用されることもあれば、されな
いこともある。そのサブテープが、呼び出しているテー
プで使用されているアクタを特に参照する場合、このア
クタは再利用される。再帰的なテープ呼び出しは、現在
のテープの特別な例であるか、またはそれ自体を呼び出
しているサブテープの特別な例である。 【００６０】テープ・コンパイラ：これは、編集および
ウンドゥの可能な損害に対するさらに効率的な実行を与
えるテープを定義するシステム規則の集合に関する処理
機構である。結果は、コンパイル（編集）されたテープ
である。テープ・コンパイラは、アクタのグラフィック
表現、ならびにそのテープ内のアクタ間の通信および接
続のグラフィカルな副作用を除去することにより、より
効率的な実行を与えることができる。また、テープ・コ
ンパイラは、最適化のためにテープのスクリプト規則の
集合を修正し、高速実行のためにスクリプト規則の前計
算されたラチスを生成する。 【００６１】ビジュアルな照会：これは、照会を定式化
してテープ・シェルフから情報を検索するために設計さ
れた対話的かつビジュアルな処理の集合である。同様の
機構は、標準のテープの録音に使用されるビジュアルな
照会を定式化するのにも、テープの照会が生成されたの
ちテープ・シェルフからのテープの一部に照合されると
言う点を除いて、使用される。テープ・シェルフに適用
される照会結果は、対のリストを伴ったテープの順序集
合である。各対は、候補との一致の信頼値である数およ
びテープ・プログラムにおけるその候補のある位置への
ポインタからなる。ビジュアルな照会の結果として、利
用者は、候補との一致が成功した位置の付近の各テープ
のグラフィカルなシミュレーションを調べることができ
る。これは、設計情報の検索および既存のものから新た
な設計を組み立てるのに役立つ。 【００６２】ＶＳＭにおけるアクタ ＶＳＭにおいて、アクタは、劇および映画の制作の場合
と同様の概念を表す。バックステージにあるアクタの要
員の中からアクタを利用することができる。アクタは、
必要に応じて（新たに）生成したり、前に生成したアク
タの要員から得たりする。アクタは、生活（存在）し、
演じ（上演し）、そして死ぬ（破壊される）。さらに、
アクタは、コンピュータの実体であるから、それらの複
写、再利用、合併、分離、および置換が可能である。あ
るスクリプトに対してアクタを大まかに定義することが
できるが、この場合のオーディション処理（ａｕｄｉｔ
）は、適切な特性のアクタを要員から選択するように行
われる。ユーザの視点からすれば、アクタは、知識を蓄
え、それを利用し、さらに計算を行う非常に柔軟性のあ
る作用主体として見えなければならない。 【００６３】アクタは、ゼロ、または１つ以上のテープ
の構成員であり得る。テープには、そのテープのシミュ
レーションから得られるシナリオにおいて演じるすべて
のアクタのアドレスが表として掲げてある。このリスト
は時間で変化する。ＶＳＭでは、テープは元来、例から
作られている。例によって作用が構成されると言うこと
は、テープの録音中に、アクタの特定のインスタンスが
生成されて使用されることを意味する。 【００６４】スクリプトの構造 ＧＲＡＳシステムにおける作用の規則を実施するために
使用されるデータ構造は、つぎのような形式である。Ｓ
ａｄｄｒｅｓｓ＝（Ｔｙｐｅ，Ｓｉｄ，Ｇｒｏｕｐ−Ｓ
ａｄｄｒｅｓｓ，Ｐｒｅ−Ｓａｄｄｒｅｓｓ，Ｐｏｓｔ
−Ｓａｄｄｒｅｓｓ，Ｓｅｎｄｅｒ，Ｓｕｎｄｏ，Ｒｅ
ｃｅｉｖｅｒ，Ｒｕｎｄｏ，Ｐｒｅｃｏｎｄｉｔｉｏｎ
ｓ，Ｍｅｓｓａｇｅ ａｎｄ Ａｒｄｕｍｅｎｔｓ，Ｐ
ｏｓｔｃｏｎｄｉｔｉｏｎｓ，Ｄｏｃｕｍｅｎｔａｔｉ
ｏｎ）．スクリプトの引数は、次のように定義される。 【００６５】「Ｓａｄｄｒｅｓｓ」は、所与のプロセッ
サにおけるスクリプト構造体のアドレスである。スクリ
プト構造体がいくつかの独立したプロセッサ上に分散し
ている場合、Ｓａｄｄｒｅｓｓは、プロセッサのアドレ
スを与える接頭語（例えば、ＳａｄｄｒｅｓｓをＰｒｏ
ｃＡｄｄｒｅｓｓ：Ｓａｄｄｒｅｓｓとする）を持つこ
とができる。 【００６６】「Ｔｙｐｅ」は、Ｒｕｌｅ（規則）、Ｇｅ
ｎｅｒａｌ（一般）、Ｉｎｓｔａｎｃｅ（インスタンス
）、Ｇｒｏｕｐ（グループ）、Ｗａｉｔ（待機）、Ｕｎ
ｄｏａｂｌｅ（アンドゥ不能）、Ｓｅｎｔ（送信済み）
、Ｐｒｅｃｅｓｓｅｄ（処理済み）などのスクリプトの
型の合法的な組み合わせである。この型は、スクリプト
の型の記述に従ってスクリプト構造体を処理するために
、推論エンジンによって使用される。Ｒｕｌｅ、Ｇｅｎ
ｅｒａｌおよびＩｎｓｔａｎｃｅの各型は、Ｇｒｏｕｐ
型と共に組み合わせることができる。Ｉｎｓｔａｎｃｅ
型およびＷａｉｔ型は、Ｕｎｄｏａｂｌｅ型と組み合わ
せることができる。Ｉｎｓｔａｎｃｅ型は、Ｓｅｎｔ型
またはＰｒｏｃｅｓｓｅｄ型と組み合わせることができ
る。 【００６７】Ｓｉｄ：これは、他のスクリプト構造体に
おける記号（シンボル）による参照および利用者への記
号表現に使用される識別子である。 【００６８】Ｇｒｏｕｐ−Ｓａｄｄｒｅｓｓ：スクリプ
ト構造体がグループ型である場合、そのグループの構成
員であるスクリプト構造体の集合を参照するのに使用さ
れる。 【００６９】Ｐｒｅ−ＳａｄｄｒｅｓｓおよびＰｏｓｔ
−Ｓａｄｄｒｅｓｓ：これらは、他のスクリプト構造体
へのＳａｄｄｒｅｓｓ（複数）の構造体である。それは
、特定のアーキテクチャに対するＧＲＡＳの働きを高め
る効率的な実行機構の設計を支援するために使用される
。例えば、スクリプト構造体ＳのＰｒｅ−Ｓａｄｄｒｅ
ｓｓは、Ｓの実行の直前のスクリプト構造体のアドレス
であり、Ｐｏｓｔ−Ｓａｄｄｒｅｓｓは、Ｓの実行に直
に続くスクリプト構造体を示す。これによって、スクリ
プト構造体のいくつもの大きな集合の実行を効率的に実
施したり破棄したりするためのラチス構造が与えられる
。 【００７０】ＳｅｎｄｅｒおよびＲｅｃｅｉｖｅｒ：こ
れらは、このスクリプト構造体におけるセンダのアクタ
およびレシーバのアクタを参照する表現である。そのス
クリプトの型によって、この表現は、異なって解釈され
る。 【００７１】ＳｕｎｄｏおよびＲｕｎｄｏ：これらは、
スクリプト構造体の実行によってセンダのアクタおよび
レシーバのアクタに対しそれぞれ行われた変更をすべて
復元するために必要とされる処理の集合を記述する表現
である。ＳｕｎｄｏおよびＲｕｎｄｏは、Ｒｕｌｅ型お
よびＧｅｎｅｒａｌ型のスクリプト構造体に対しては、
空である。 【００７２】Ｐｒｅｃｏｎｄｉｔｉｏｎ（事前条件）：
事前条件の表現は、関数と、現在のシミュレーション時
刻におけるスクリプトのアクタの属性に関する論理検査
との組み合わせ（例えば、ブール表現）である。センダ
のアクタおよびレシーバのアクタに基づく事前条件によ
って設計を簡単にすることは許されるが、好ましい方法
は、センダのアクタに関する事前条件およびレシーバの
アクタに関する事前条件を分離することである。レシー
バについての情報にアクセスするためには、まずレシー
バに要求を送る必要があり、その応答の結果を次の規則
の事前条件において使用しなければならない。アクタの
集合がスクリプトを実行している各プロセッサ上では、
必要であればクロックが利用でき、そして、そうならば
、スクリプト構造体の有限な実行履歴が維持される。こ
れらの仮定の下で、事前条件に時間従属関係を含めるこ
とができるが、これは、時間作用素および他のスクリプ
ト構造体の実行時間を用いて形成されたタイミング表現
である。タイミング表現は、スクリプト構造体の実行を
（それらに特有のスクリプト識別子に基づいて）指示す
るのに使用される。ＧＲＡＳの実現においては、シミュ
レートされた時間の強制は、ＯＯスクリプトの表記に基
づく。 【００７３】Ｍｅｓｓａｇｅ ａｎｄ Ａｒｇｕｍｅｎ
ｔｓ（メッセージと引数）：「Ｍｅｓｓａｇｅ」は、セ
ンダのアクタとレシーバのアクタとの間で渡されるオプ
ションのメッセージのシンボル名である。メッセージは
、アクタ間で情報を伝達するために使用される。引数が
指定されるとき、引数は、センダのアクタからのデータ
に基づいて、任意のデータの集合または計算式から成る
。 【００７４】Ｐｏｓｔｃｏｎｄｉｔｉｏｎｓ（事後条件
）：属性の初期値に施された計算に基づいて、さらにレ
シーバのアクタの場合は、計算されたりそのレシーバに
渡されたメッセージを介して転送されたりしたデータに
基づいて、アクタの属性に対して行われた変更が、事後
条件の表現によって記述される。Ｐｏｓｔｃｏｎｄｉｔ
ｉｏｎｓは、センダのアクタに対する事後条件表現とレ
シーバのアクタに対する事後条件表現とに分解する方が
好ましい。 Ｄｏｃｕｍｅｎｔａｔｉｏｎ：スクリプト構造体の機能
の解説に使用されるフィールドである。ドキュメンテー
ションには、そのスクリプト構造体の全アクタおよびそ
れらの属性およびデータへのシンボルによる参照情報を
含めることができる。ドキュメンテーションは、少なく
ともテキストによる記述であるが、実現方法によっては
、グラフィックス、ビデオおよびオーディオを使用して
も良い。 【００７５】事前条件において検査されるか、事後条件
において変更されるアクタの属性により、アクタの間の
関係（センダのアクタとレシーバのアクタとの間の関係
）を表すことができる。さらに、外界と共に入出力関数
を実行する項目（例えば、利用者に質問することなど）
は、事前条件、メッセージおよび事後条件において受け
付けられるが、事後条件以外では受け付けないことを推
奨する。事前条件はすべて並列的に検査され、メッセー
ジの属性はすべて並列的に通信され、事後条件は、すべ
て並列的に実行される。このため、アクタには並列的な
通信モデルが強いられる。連続的な実行が望ましい場合
には、別個のスクリプトと連続したスクリプトグループ
が用いられる。 【００７６】スクリプトの型 スクリプト規則：Ｒｕｌｅ型のスクリプト構造体は、例
示されたセンダのアクタおよびレシーバのアクタを持た
ないが、代わりに、シンボル名または１つのアクタ・ア
ドレスに評価される表現を用いてアクタを参照する。こ
れは、生成、再利用、または多くとも１つのアクタ・ア
ドレスに戻るアクタ処理によって、行うことができる。 スクリプト規則は、実行されるスクリプトではないので
、維持するべきアンドゥ情報がないため、空のＳｕｎｄ
ｏフィールドおよびＲｕｎｄｏフィールドを有する。 【００７７】一般スクリプト：一般（Ｇｅｎｅｒａｌ）
型のスクリプト構造体では、そのアクタを指定するため
にオーディション表現を用いる。センダとレシーバは、
アクタ・アドレス（センダ・アドレスおよびレシーバ・
アドレス）の対の集合を生成する２つのオーディション
表現を指定する。一般スクリプトは、空のＳｕｎｄｏフ
ィールドおよびＲｕｎｄｏフィールドを有する。 【００７８】スクリプト・インスタンス：インスタンス
型のスクリプト構造体は、スクリプト規則または一般ス
クリプトの例示によって生じる。スクリプト規則の場合
、センダおよびレシーバがそれらのアドレスによって特
定されると、センダのアクタおよびレシーバのアクタが
それらのアドレスによって置き換えられる場合、スクリ
プト・インスタンスが生成される。一般スクリプトの場
合、アクタ・アドレスの各対に対応してスクリプト・イ
ンスタンスの集合が生成される。スクリプト・インスタ
ンスは、実行されると空でないＳｕｎｄｏおよびＲｕｎ
ｄｏフィールドを有する。これらのフィールドには、ス
クリプト・インスタンスを一度実行することの影響を元
に戻すために終えなければならない処理が記述されてい
る。 【００７９】スクリプト・グループ：スクリプト構造体
の集合を直接参照するスクリプト構造体である。例えば
、オーディション処理が１つ以上のアクタ対（例えば、
通信放送）を返す場合、一般スクリプトはグループ・ス
クリプトに例えることができる。並列実行のため、スク
リプト・インスタンスも推論エンジン（ソフトコーダ（
ＳＯＦＴＣＯＤＥＲ））によって自動的にグループ化さ
れる。 スクリプト規則の実行を同じプロセッサにさせるために
グループを定義することも可能である。例示されたスク
リプト・グループは、空でないＳｕｎｄｏフィールドお
よびＲｕｎｄｏフィールドを有する。 【００８０】待機スクリプト：シミュレートされた時間
の期間中に実行を遅らせるためにソフトコーダによって
生成されるスクリプト構造体である。これは、シミュレ
ーション時間のある期間中に実行可能なスクリプトが無
いこともあり得るので、必要である。例えば、送信され
るメッセージは、受信され処理される前に数単位分のシ
ミュレートされた時間を要することがある。また、メッ
セージが受信されても、後まで処理できなかったりする
。 【００８１】アンドゥ不能スクリプト：実行が終了しか
つ逆に実行される（元通りにされる）べき必要なＳｕｎ
ｄｏおよびＲｕｎｄｏ表現を持つ待機スクリプトまたは
スクリプト・インスタンスである。Ｓｕｎｄｏ表現また
はＲｕｎｄｏ表現により、スクリプト・インスタンスが
最初に実行されたシミュレーション時刻以降に変更され
たすべてのスロットおよび値が、対応するアクタのデー
タ空間から削除される。スクリプト・インスタンスが実
行される前に存在していたスロットおよび値は、これに
よって回復される。 【００８２】ＧＲＡＳシステムの説明 図１は、ＧＲＡＳシステムの概念的構造図である。ビデ
オ・スタジオ・メタファ（ＶＳＭ）インタフェース・モ
ジュール１００は、単一統合メタファの下でのシステム
設計およびシミュレーションの環境全体に対する簡単な
ユーザ・インタフェースと直接アクセスとを提供するた
めのソフトウェア・モジュールである。ＶＳＭにより、
利用者は、ビジュアル・プログラミング技法を用いてシ
ステム作用の例をテープ・シナリオへと記録し、さらに
グラフィカルな動画的シミュレーションおよび実行をと
おして指定されたシステムの作用の視覚的フィードバッ
クを維持しながら、それらの例をテープ・プログラムへ
と組み合わせかつ洗練させることができる。利用者は、
ＶＳＭにおけるビデオ・コネクタおよび種々のエディタ
（フィルム・エディタ）の使用によって、設計案の補足
、通信、編集、および結合を行うことができる。 【００８３】また、ＶＳＭモジュールは、このシステム
の利用者に対し必要な仕事を行うために、より低い水準
の適切なＧＲＡＳモジュールを呼び出すことができる。 ビジュアル・オブジェクト網管理（ＭｏＶｏｎ＝Ｍａｎ
ａｇｅｍｅｎｔｏｆ Ｖｉｓｕａｌ Ｏｂｊｅｃｔ Ｎ
ｅｔｗｏｒｋｓ）モジュール（ＭＯＶＯＮ）１１０、ソ
フトウェア・ビデオ・レコーダ（ソフトコーダ）モジュ
ール（ＳＯＦＴＣＯＤＥＲ）１２０、およびビデオ・コ
ネクタ（ＶＣ）モジュール（ＶＣ）１３０から成る次の
水準のモジュールは、利用者に対し透過的である。ＶＳ
Ｍインタフェースは、双方向メッセージ・リンク（１１
１、１２１、および１３１）を介して、これらのモジュ
ールと通信を行う。 【００８４】ビジュアル・オブジェクト網管理（ＭｏＶ
ｏｎ）は、システムの構成要素および構成要素網の視覚
化を多重表示、多重階層、および多重詳細水準でサポー
トするアクタの実現である。ビジュアル・オブジェクト
網管理モジュール（ＭＯＶＯＮ）１１０は、その関数を
実行するために、アクタ・フレーム・モジュール（ＡＦ
）１４０、およびプレスクリプト・モジュール（ＰＲＥ
ＳＣＲＩＰＴ）１６０を要請する。 【００８５】ソフトコーダ・モジュール（ＳＯＦＴＣＯ
ＤＥＲ）１２０は、アクタの処理および通信を記録し、
かつシミュレートまたは実行するビジュアルな機構であ
る。ソフトコーダ・モジュール１２０により、単一また
は複合の画面上の対話によって供給される指定事項を記
録（入力）、再生（実行）およびアンドゥ（逆向きの実
行）を行う一般的な機構が提供される。これらの対話は
、情報の転送および計算を伴うアクタ間の通信を表す。 ソフトコーダのビジュアルな機構は、アクタ間の作用の
規則を記述するテープ・プログラムを処理し、アクタお
よび規則を例示し、さらにこのシステムの実行の完全な
軌跡であるテープ・シナリオを生成する。テープ・プロ
グラムにおける各実行段階において、１組の処理が実行
される。各段階は、それをアウドゥすることによって逆
戻りすることができる。 【００８６】また、ソフトコーダのビジュアルな機構は
、アクタの通信および状態の変化をとらえ、シュミレー
トする。ソフトコーダは、録音中に、メニューによる視
覚的な対話（アクタの処理の記録）をとおして利用者に
よって与えられる特定の例からソフトウェア区分を一般
的な作用規則へと自動的にコード化する。各作用規則は
、利用者からの入力と対話する専用のソフトウェア・ル
ーチン群によって対話的に洗練され（特殊効果）、別の
状態を記録する場合には、再利用および変更を容易に行
うことができる。 【００８７】各段階の連続的な実行により、その例が、
入力されたとおりに再生される。その例によって記述さ
れた作用は、作用をすべて予め確かめられる状態で記述
するプログラムへと対話的に洗練される。作用のアクタ
および規則は、アクタの状態、通信中に実行された計算
および交わされた情報に関する他の情報を変更したり、
削除したり、あるいは追加したりするために、いつでも
編集することができる。利用者の裁量によって、アクタ
の状態およびグラフィカルな表現の変更は、永久的にも
一時的にもなる（反転可能）。結果的に得られる規則は
、実際にテープ・プログラムを形成する。 【００８８】ビデオ・コネクタ・モジュール（ＶＣ）１
３０は、利用者にプログラム対話、編集、ならびにファ
イル・システムおよびＧＲＡＳの外部の他のシステムへ
の接続のための機構を利用者に提供する。モジュール１
３０は、ソフトコーダによって使用される内部テープ表
現のための一般的な変換および通信の機構である。モジ
ュール１３０は、利用者による読み出しおよび編集、ま
たは外部システムとの通信のうち何れかが可能なテキス
ト形式でテープ、アクタおよびスクリプトを示すのに使
用される。モジュール１３０により、ＧＲＡＳとファイ
ル・システムとの間の双方向接続機構、およびＧＲＡＳ
と外部システムとの間の双方向接続が提供される。提供
されるコネクタの例としては、ＯＯスクリプト、メッセ
ージ、テープ、アクタ（オブジェクト）、スクリプト、
およびアイコンがある。ビデオ・コネクタを介して外部
のシステムに接続されると、外部のシステムは、ＧＲＡ
Ｓの実行を遠隔制御できるだけでなく、ＧＲＡＳを調べ
ることができる。 【００８９】プレスクリプトは、ＧＲＡＳの一部で、ア
クタおよび伝達情報の表示およびアニメーションのため
のグラフィカルなプログラミング言語である。プレスク
リプト・モジュール１６０は、アクタの視覚的な表現を
担う。アクタ（アクタ＝視覚的なオブジェクト＋フレー
ム＋作用）を定義するために、視覚的なオブジェクトは
フレーム表現に関係付けられる。視覚的なオブジェクト
はコンピュータ端末上に表示される。視覚的なオブジェ
クトは、他の視覚的なオブジェクトと合併することがで
き、シナリオ（またはシナリオの集合）を定義するテー
プの構成員であるだけでなく、テープ・フレームの構成
員でもある。プレスクリプト・モジュール１６０は、Ｏ
Ｓ１７５によって与えられるウィンドウおよびグラフィ
ックの諸機能（ＷＧ）１７０を利用する。 【００９０】アクタ・フレーム・モジュール（ＡＦ）１
４０は、フレームおよびアクタの知識の時間的履歴を支
持する知識表現および記憶の機構である。アクタ・フレ
ームは、フレーム・オブジェクト言語および実行環境（
ＦＯＬＩＥ）に基づく。ＦＯＬＩＥは、ＧＲＡＳシステ
ムの一部であり、フレーム・ベースの分離（分散）およ
び分散された部分集合からの合併によるフレーム・ベー
スの再構築、多数の階層およびローカル・クラス優先リ
スト、および多数の階層におけるメッセージの放送をサ
ポートするフレーム表現言語である。放送されたメッセ
ージが、方法、関数、手続き、またはコンパイルあるい
は変換された形式のラムダ表現への参照情報から成る場
合、それは、少なくとも１つの関数引数と共に、その階
層における現在のフレームと称する。ラムダ表現は、必
要な引数（例えば、現在のフレーム）と共にそれが呼び
出されると仮定した場合、その実行に必要なすべての環
境変数を備えた、独立型のコンピュータのコード・セグ
メントである。 【００９１】ＧＲＡＳシステムにおいて、テープの実行
機構は、アクタの動的な属性に基づく。テープの編集処
理は、アクタの静的な属性と動的な属性との組み合わせ
に影響を与える。静的な編集の柔軟性は、アクタ・フレ
ーム・モジュール１４０の一部であるＦＯＬＩＥモジュ
ールによってサポートされる。ＦＯＬＩＥモジュールは
、次の関数からなる。即ち、（１）シンボルによる自己
記述：伸長性で型指定が無く、フレーム集合のシンボル
による自己記述は順序依存的であり、フレーム間のすべ
ての依存関係は２重リンクを用いて自動的に維持され、
そのフレーム要素からのフレーム集合の定義は、任意の
順序で行うことができる。（２）多元的継承：フレーム
がそのすべての母体から性質の統一体（集合）を受け継
ぐことができる。（３）継承の多重階層性：フレームは
、ＡＫＯ階層、ＰＡＲＴ−ＯＦ階層、またはその化の任
意の関係から、性質を継承することができる。 （４）所与の階層のフレームに対する母体の順序集合か
ら成るローカル・クラス優先リスト（ＬＣＰＬ）：多重
階層性により、多数のＬＣＰＬがもたらされる。（５）
フレームの放送：所与の階層のすべてのローカル・クラ
ス優先構成員に作用素を放送（一斉送信）することがで
きる。（６）フレーム網の統合：他のフレームとの関係
のネットワークの内部でフレームが定義される。各フレ
ームは、自己記述的である、即ち、フレームは他のフレ
ームとの関係網をシンボル的に記述する。他のフレーム
がない場合でもフレームの統合が可能である。（７）フ
レーム網の合併：フレームのオブジェクトを共有する２
つのフレーム網は、同一のシステムの中でリンク（ロー
ド）されると、自動的に合併される。（８）再利用、結
合、上書きおよび忘却という４種類の合併の原型を備え
たフレームの合併。（９）フレームの転送：これにより
、フレーム網の一貫性を維持しながら、フレームを他の
フレームによって全体的に（グローバルに）置換するこ
とが可能となる。交換用のフレームが既に存在する場合
、転送は、合併によって行われる。この機能により、ア
クタの交換およびアクタの合併に対する支持が与えられ
る。 【００９２】ウィンドウおよびグラフィックス・システ
ムのモジュール（ＷＧ）１７０（商業的に入手可能なＸ
Ｗｉｎｄｏｗ ＳｙｓｔｅｍＴＭ、ＳｕｎＶｉｅｗＴ
Ｍ、シンボリックス（Ｓｙｍｂｏｌｉｃｓ）社のＧＥＮ
ＥＲＡ（登録商標）のウィンドウと類似）により、ＧＲ
ＡＳに視覚的な能力が与えられる。Ｃｏｍｍｏｎ Ｌｉ
ｓｐ（ＣＬ）１８０は、ＡＮＳＩ Ｘ３Ｊ１３委員会（
準備中のＣｏｍｍｏｎ Ｌｉｓｐのための全米規格）の
仕様に従うＣｏｍｍｏｎ Ｌｉｓｐ言語を実現したもの
である。ＧＲＡＳでは、実行可能なサイズを小さくする
ために、ＣＬのサブセットが用いられる。ＣＬのサブセ
ットは、ＧＲＡＳを実行するのに必要なＬｉｓｐ関数の
みから成り、ＧＲＡＳ全体のコードを調べ、そのコード
において参照されたすべての関数を集めることによって
生成されている。その他のコンピュータ言語でも、ＡＮ
ＳＩ仕様による定義と類似の機能を与える限り、ＣＬと
置き換えることができる。 【００９３】オペレーティング・システム（ＯＳ）１７
５は、コンピュータのオペレーティング・システムであ
り、（オプションにより）統合化された環境（例えば、
ＵＮＩＸ（登録商標）、シンボリックス社のＧＥＮＥＲ
Ａ（登録商標））である。ＵＮＩＸは、ＡＴ＆Ｔの登録
商標である。ＧＥＮＥＲＡは、シンボリックス社の登録
商標である。ＯＳは、次の構成要素の実行の制御および
維持を行う。即ち、ＷＧ（１７０）、ＣＬ（１８０）、
ＦＳ（１８５）およびＮＷ（１８６）である。 【００９４】ファイル・システム（ＦＳ）１８５は、静
的なデータ記憶および検索のためのアクセス機構を実現
する構成要素である。これは、ＵＮＩＸのファイル・シ
ステムを基にしている。 【００９５】ハードウェア（ＨＷ）１７６は、データ（
シンボル、オブジェクト、データーベース）を操作し、
論理演算および算術計算を行う１つ以上のプロセッサ、
およびデータの記憶および検索に使用される１つ以上の
記憶用の機構および装置から成る（記憶装置は、静的な
ものや動的なものがあり、シーケンシャル・アクセスで
あったり、ランダム・アクセスであったりする）。 ハードウェアの必要条件は、ここで定義されるＧＲＡＳ
のすべての構成要素の実行を支持するに十分なデータ記
憶装置および処理能力を与えることである。ＧＲＡＳの
実現および頒布のために適切であると分かった現在入手
可能なコンピュータ・ハードウェアには、次のものがあ
る。ＡＴ＆Ｔの６３８６ＷＧＳ、ＡＴ＆Ｔのグラフィッ
クス端末またはＸ Ｗｉｎｄｏｗ端末を付けた他のＵＮ
ＩＸコンピュータ・メインフレーム、サン・マイクロシ
ステムズのＳｕｎ−３およびＳｕｎ−４シリーズ、イン
テル８０３８６ベースのパーソナル・コンピュータ、シ
ンボリックスの３６００（登録商標）およびＸＬシリー
ズ、ゼロックス１１００シリーズ、テキサス・インスツ
ルメンツＥｘｐｌｏｒｅｒｓ（登録商標）、およびデジ
タル・エクイップメント・コーポレーションのＤＥＣ２
０００および３０００シリーズ。 【００９６】（オプションの）ネットワーク（ＮＷ）１
８６は、ＶＳＭベースのシステムの集合の間でデータ通
信を提供するために、ＨＷ構成要素と共に利用できるか
、またはそれに付け加えて利用できるハードウェアおよ
びソフトウェアの要素を備えている。現在利用可能で適
切なネットワーク技術には、モデム付きの電話回線、イ
ーサネット、ＡＴ＆Ｔ ＳＴＡＲＬＡＮ、広帯域パケッ
ト網がある。ネットワーク要素は、ＶＳＣデータを電気
的に伝達する（例えば、テープ・プログラムを離れた場
所で利用する）ために必要とされるに過ぎない。 【００９７】図１に示したように、ＶＳＭモジュール１
００は、ＭＯＶＯＮ、ソフトコーダおよびＶＣへ双方向
の接続を持っている。（ＶＳＭからの）直接の接続は、
１）アクタおよびアクタ処理（ＭＯＶＯＮ）、２）スク
リプトおよびテープ・プログラムの視覚的な記録、洗練
、およびシミュレーション（ソフトコーダ）、ならびに
３）外部のテープ・プログラムだけでなくテキスト形式
のテープ・プログラムの編集（ＶＣ）、に対する利用者
の制御およびアクセスを表す。ＶＣと外部のシステムと
の間に存在する（オプションの実行時の）双方向接続は
、図には表していない。（ＭＯＶＯＮ、ソフトコーダま
たはＶＣから）ＶＳＭへの接続は、ユーザ・インタフェ
ースの表示へのビジュアルなフィードバックおよびテキ
ストのフィードバックを意味し、表示画面上の１つ以上
の視覚表現に変化をもたらす。このフィードバック・ル
ープは、実際にはＭＯＶＯＮ−ＰＲＥＳＣＲＩＰＴ−Ｗ
Ｇを通る共通経路によって実現され、すべてのグラフィ
カルな変化は、アクタの視覚的表現に対する変化として
実現される。また、ＶＳＭは、利用者によって制御され
る指示装置およびキーボード装置にＷＧ経由で接続され
る。ＶＳＭモジュールは、図示されていない利用者から
直接の入力を受信する。同じ入力をＶＣ遠隔制御機能に
よって外部のシステムから受信することも可能である。 ソフトコーダおよびＶＣは、スクリプト、テープ・プロ
グラム、およびテープ・シナリオのほか、ソフトコーダ
制御コマンド（例えば、テープのロード、テープの削除
、詳細水準の変更、ビューの変更など）も送信する。Ｍ
ＯＶＯＮおよびソフトコーダは、アクタおよびアクタの
内容を送る。ＭＯＶＯＮは、ＰＲＥＳＣＲＩＰＴにアク
タのビジュアル・オブジェクトを要求し、ＡＦにアクタ
・フレームを要求することができる。ＶＣは、ＦＳおよ
び外部システムへの接続をＣＬおよびＦＳまたはＮＷを
介して要求することができる。ＰＲＥＳＣＲＩＰＴは、
ＷＧを介して表示の変更を求めることができ、ＣＬを介
してプリスクリプト・オブジェクトの割り当てを（また
は再生をオプションで）要求することができる。 ＡＦは、ＣＬを介してフレーム、スクリプトおよびテー
プの構造体の割り当てを（または再生をオプションで）
要求することができる。ＣＬは、ＯＳおよびＦＳを介し
てＨＷにコンピュータ・オブジェクトの割り当ておよび
再生を要求することができる。 【００９８】ＭＯＶＯＮ、ソフトコーダ、ＶＣ、および
概念構造のその他の構成要素の間の接続をさらに説明す
るために、ＶＳＭの言語を使用することができる。テー
プ・プログラムをビデオ店から借りると（ＶＳＭによる
利用者の要求）、ＶＣは、ＣＬを介してＦＳまたはＮＷ
への接続を開き、ソフトコーダは、その開かれた接続か
らの入力をテープ・シェルフ（ＶＳＭ）の上に置かれた
テープ・プログラムへと記録する。テープがソフトコー
ダにロードされる（ＶＳＭコマンド）と、ソフトコーダ
は、アクタを要求し、ＭＯＶＯＮからのビューを表示し
た後、ソフトコーダは、適切な実行アルゴリズムを呼び
出す。ソフトコーダがそのテープ・プログラムからスク
リプトを実行するにともない、１）ＡＦによって時間的
履歴において制御され、かつ２）ＭＯＶＯＮ−ＰＲＥＳ
ＣＲＩＰＴ−ＷＧを介してアクタの視覚的表現（例えば
、アニメーション）に影響を及ぼし得るアクタに変更が
指示される。変更、または実行選択肢を試行のために利
用者が実行を休止すると、変更が、スクリプトの変更お
よびアクタの変更に翻訳されてＭＯＶＯＮおよびＡＦに
伝えられ、そこにおいて、それらの変化は一時的または
永久に組み込まれる。アクタおよびスクリプトに対する
変更は、ソフトコーダがそれらの変更を実施し、それら
をＭＯＶＯＮを介して伝達すると、直ちに見ることがで
きる。 【００９９】ビデオ・スタジオ・メタファにおいて、例
としてのシナリオが対話的にテープに記録される。シナ
リオ例は、既存のシステムまたは設計予定のシステムに
対する一連の作用を指定するために使用される。新たな
条件に対するシステムの作用の新しい面を取り入れ、す
べての許容可能な条件のためにテープ・プログラムへと
発展させるために、テープ・シナリオが対話的に洗練さ
れる。十分に洗練した後、テープ・プログラムにより、
表されたシステムまたは設計中のシステムの完全なシミ
ュレーションが与えられる。テープ（シナリオまたはプ
ログラム）には、アクタの集合、アクタ間の作用および
通信を記述する規則の集合が入る。アクタは、規則の実
行によって駆動される通信活動および処理活動に関与す
る処理主体である。アクタは、規則の実行に使用される
独立した知識ベースを備えている。規則は、アクタの知
識ベースに関する事前条件、アクタ間の通信、および通
信とアクタの知識ベースへの表明とからなる事後処理を
含んでいる。 【０１００】アクタ・フレーム・モジュールフレームの
概念構造により、利用者は、「ロード」および「接合」
により２つの独立したテープを統合することができる。 アクタおよび規則を共有する２つのテープは、それらを
１つの環境にロードし、テープの接合および編集を適用
することによって統合することができる。役割および関
数を共有してもアクタの識別情報が一致しない２つのテ
ープは、アクタの移転（アクタの交換を選択する）およ
び前記のステップを実行することによって、合併するこ
とができる。同じ特徴の仕様を持つ断片部品を組み立て
てみれば、前記のような環境に統合のための独特なコン
ピュータ支援があることが分かる。 【０１０１】テープの編集および合併に付いての柔軟性
は、フレーム表現言語（ＦＯＬＩＥ）、ビジュアル・オ
ブジェクト網管理（ＭＯＶＯＮ）、およびアクタの規則
に基ずく作用の定義に用いられる基礎的なスクリプト言
語（例えば、ＯＯスクリプト）と言う３つの要素の統合
からくるものである。フレームの合併により、テープお
よび（または）アクタのスロット、値および関係（例え
ば、継承、構成員関係）の合併がサポートされる。フレ
ームまたはそれらの関係の集合が、ノードがフレームを
表し弧が関係を表すようなグラフによって表される場合
、そのような２つのフレーム集合を合併することは、か
くグラフのノードを合併し、合併したグラフのノード間
で弧を（合併の型に応じて）追加したり削除したりする
ことによって、それらのグラフを構成するに等しい。 アクタの交換処理は、オブジェクト指向言語における「
ｂｅｃｏｍｅ」の拡張として見ることができるが、これ
を用いて、あるアクタを他のものに替えたり、交換先が
既存のアクタである場合には、２つのアクタを合併した
りすることが可能である。ビジュアル・オブジェクトの
合併により、システムの構成要素の統合、即ち、スロッ
ト値、さらにグラフィックスの属性として定義される状
態の合併がサポートされる。規則に基づくテープ・プロ
グラムの実行は、規則集合の結合を行うことにより種々
のテープからアクタの作用の統合をサポートする。標準
のプログラミング言語における関数、オブジェクト、ま
たは命令の集合の結合によるプログラムの結合によって
、通常は、有用なまたは有意義な結果を生じることはな
い。なぜなら、プログラムの各命令の実行は、他の周囲
のプログラム命令によって定義される外部の暗黙の制御
フローによって条件付けられるからである。しかし、ス
クリプト規則、一般スクリプトおよび関係するアクタの
集合結合によるテープ・プログラムの結合は、結合され
ているテープからの機能性の追加を、次のような少なく
とも２つの利点を伴って、もたらし得る。第１に、テー
プ・プログラムの各「命令」は、アクタまたはアクタの
記述、実行条件および結果としての処理および通信（メ
ッセージ）から成るスクリプト規則または一般スクリプ
トであり、従って、自立したプログラム命令である。第
２に、結合されている異なるテープ・プログラムからの
２つのスクリプト規則が、一致しない場合、この矛盾は
、明確に定義されている型であり、１）それらの規則が
意味論的に矛盾するか、２）両方の規則が同一のアクタ
・スロットを同時に更新しようとする状態が存在するか
、または３）１つ以上の規則が到達不可能であるかの何
れかである。最初の２つの矛盾の場合は、結合されたテ
ープ・プログラムの実行のアニメーションまたはシミュ
レーションの間に視覚的に現れる。第２および第３の矛
盾の場合も、結合された規則集合の静的な分析を用いて
検出することができる。 【０１０２】ＧＲＡＳにおいて、ＦＯＬＩＥ、ＭＯＶＯ
Ｎ、および内部のスクリプト構造体（例えば、ＯＯスク
リプト）を結合する根元的な知識表現は、上述の合併処
理（規則集合の結合によるフレーム・グラフの合併およ
び作用の統合）に内部的に基づく仕様の独特な柔軟性を
備えている。 【０１０３】ＶＳＭのためのデータの記憶および検索を
サポートする基本的な知識表現は、ＧＲＡＳのアクタ・
フレーム要素によって与えられる。ＡＦは、アクタ間の
通信スクリプトの可逆的な実行のために必要な時間履歴
機構を提供するもので、根元的なフレーム表現言語ＦＯ
ＬＩＥの上に構築されている。ＡＦにより、アクタへの
通信またはアクタからの通信によりフレームの属性また
は関係が変化する度にそのアクタ・フレームのローカル
・スナップ・ショットを記録しておくことにより、（前
に形式化された）アクタに必要な時間履歴機構が与えら
れる。この時間履歴の他に、ＧＲＡＳの実現に必要とさ
れるＡＦのすべての特徴は、ＦＯＬＩＥの直接的な特徴
である。 【０１０４】ＶＳＭにおけるテープの実行機構は、アク
タの動的な属性の記録および復活（読み出し）に基づく
。前記のテープ編集処理は、アクタの動的な属性と静的
な属性との組み合わせに影響を及ぼす。変更および編集
の実施は、根底にあるフレーム表現言語ＦＯＬＩＥによ
って直接サポートされる。動的な変更の実施は、ＦＯＬ
ＩＥの特性とアクタに関連したフレームの属性のスナッ
プ・ショットを記録・復活できる履歴機構との組み合わ
せによって与えられる。アクタの静的属性および動的属
性に関して必要な処理をサポートするＦＯＬＩＥフレー
ム言語の重要な特徴を以下に述べる。 【０１０５】シンボリック自己記述：フレームは、それ
が定義されているコンピュータ環境とは独立したシンボ
ルによる記述フォーマットを用いて「それ自体をプリン
トする」ことができる。自己記述フォーマットは伸縮性
があり、フレームが変化すると、その変化を取り込むた
めに、同じフォーマットが、延長されたり短縮された形
式で使用される。コンピュータに依存できるフォーマッ
トならば型の特殊性はない。フレーム集合のシンボルに
よる自己記述は、順序に依存しない。フレームの集合｛
ｆ１，ｆ２，．．．，ｆｎ｝が与えられた場合、このフ
レーム集合の自己記述を任意の順序で記録し、同等のフ
レーム集合を生成するために、ＧＲＡＳシステムの別の
場合に異なる順序でそれらを復活させることが可能であ
る。 【０１０６】２重リンク：フレーム間のすべての関係は
、２重リンクを用いて維持され、２重リンクの半分を記
録することは、２重リンクの全体を記録すること同じで
ある。この性質により、フレーム集合の自己記述の順序
独立性がサポートされる。 【０１０７】フレーム網：フレームは、他のフレームと
の関係のネットワークと解釈することができる。各フレ
ームは、他のフレームとの関係網をシンボルによって記
述し、他のフレームが無くなると、フレームの統合が可
能となる。従って、フレームの不完全なネットワークを
記録・復活しても差し支えない。それがフレームの集合
Ｆ＝｛ｆ１，ｆ２，．．．，ｆｎ｝である。ここで、Ｆ
の要素ｆｉは、Ｆの要素でないｆｊを参照する。 【０１０８】継承の多重階層：フレームは、所与のフレ
ーム階層におけるすべての母体から属性と関係の統一体
（集合）を継承することができる。多重継承は、他のフ
レーム言語およびオブジェクト指向言語についても一般
に利用可能であるが、多重階層による多重継承は、ＦＯ
ＬＩＥの新奇な特徴である。フレームは、ＡＫＯ階層、
ＰＡＲＴ−ＯＦ階層、またはＧＲＡＳにおいて定義され
たその他の関係から、特性を継承する。それぞれの双対
関係によって、それ自体のフレームの階層が定義される
。 【０１０９】ローカル・クラス優先リスト（ＬＣＰＬ）
：これによって、所与の階層におけるフレームに対する
母体の順序集合が構成される。多重階層によって多数の
ＬＣＰＬに備えている。 【０１１０】フレームの放送：作用素または関数を放送
して、それを所与の階層におけるＬＣＰＬのすべての要
素に適用することができる。 【０１１１】フレームの合併：これは、フレームに格納
された情報の結合および再利用するための機構である。 ４つの基本的な合併の原型、即ち再利用、結合、上書き
、および忘却によって、いくつかのフレームを合併する
ことができる。２つのフレームｆ１およびｆ２を合併し
て、フレームｆ（１＋２）を構成する場合、以下のとお
りである。 １）再利用：ｆ（１＋２）は、ｆ１に優先してｆ１およ
びｆ２から継承する。ｆ１の属性および関係が残り、ｆ
２からの重複しない属性と関係が追加される。 ２）結合：ｆ（１＋２）は、ｆ１およびｆ２から同等に
継承する。ｆ１およびｆ２からの属性および関係が、統
一集合としてｆ（１＋２）に格納される。 ３）上書き：ｆ（１＋２）は、ｆ２に優先してｆ１およ
びｆ２から継承する。これは、ｆ２とｆ１との間の再利
用を伴った合併と同じである。 ４）忘却：ｆ（１＋２）＝ｆ２ 合併されたフレーム
は、元のフレームｆ２によって置き換えられる。 【０１１２】フレームの転送：これは、フレーム網の一
貫性を維持しながらフレームをもう１つのフレームで全
体的に置き換えることにより、現存の２重リンクを維持
することに備えるものである。交換フレームが既に存在
する場合、転送は、合併によって行われる。この特徴に
より、アクタの交換、先に述べたクローン生成および合
併が直接サポートされる。 【０１１３】フレーム網の合併：共通のフレームを共有
する２つのフレーム網は、同一のＶＳＭベースのシステ
ムにおいて復活されると、自動的に合併される。 【０１１４】ＧＲＡＳにおけるテープの編集および合併
に付いての柔軟性は、概念構造の次の３つの主な構成要
素の間の相互作用から生じるものである。即ち、時間履
歴を統合したフレーム表現言語（ＡＦおよびＦＯＬＩＥ
）、ビジュアル・オブジェクト網管理（ＭＯＶＯＮ）、
およびアクタの規則に基ずく作用を表すのに用いられる
スクリプト構造体の根底にある特性（ソフトコーダ）で
ある。次の例により、これらのソフトウェア構成要素の
統合を説明する。 【０１１５】１）フレームの合併により、テープ、アク
タおよび関係（例えば、継承、構成員、副構成要素）の
静的または動的な合併がサポートされる。各グラフが、
アクタの作用を記述するスクリプト構造体にテープ結合
され、アクタに結合され、副構成要素のアクタへと結合
されると言うような場合、この型の合併は、グラフの合
併に等しい。 【０１１６】２）一般的なアクタ交換処理によって、ア
クタを新しいものと交換したり、２つ以上の既存のアク
タを合併できる。これはアクタの交換、クローン生成を
可能とし、新たな設計構成要素についての利用者の実験
をサポートする。 【０１１７】３）ビジュアル・オブジェクトの合併は、
システムの構成要素およびそれらのグラフィック表現の
統合をサポートし、交換、クローン生成、または合併が
発生した場合に利用者に対して直接的かつ視覚的なフィ
ードバックを与える。 ４）スクリプト構造体およびソフトコーダによるそれら
の実行によって与えられるようなアクタの間の規則ベー
スの通信によって、規則集合の統一を行うことによる多
数のテープ・プログラムからの特徴および構成要素の統
合がサポートされる。 【０１１８】ＧＲＡＳにおいては、ＡＦ、ＭＯＶＯＮ、
およびソフトコーダを結合する根元的な知識表現によっ
て、システム設計に関する使用および実験の新奇な柔軟
性が提供される。既存の設計と新たな設計のシミュレー
ション、結合および分析を非常にとりつき易くユーザ・
フレンドリに行うことが可能である。使用の柔軟性は、
ＡＦ、ＭＯＶＯＮ、およびソフトコーダと言うＧＲＡＳ
概念構造の３つの基本的な構成要素の統合によって与え
られる作用規則の合併および統合のような処理に対する
独自の半自動化された支援の結果である。 【０１１９】ＦＯＬＩＥ 次に、フレーム・オブジェクト言語および実行環境（Ｆ
ＯＬＩＥ）を説明する。明確になるよう、ＦＯＬＩＥを
定義するために、ここではＣｏｍｍｏｎ Ｌｉｓｐ（１
９８４年デジタル・プレス社刊のＧ．Ｌ．スチール（Ｓ
ｔｅｅｌｅ）二世による「ＣｏｍｍｏｎＬｉｓｐ ザ・
言語（Ｃｏｍｍｏｎ Ｌｉｓｐ ｔｈｅ Ｌａｎｇｕａ
ｇｅ）」）を改良したＬｉｓｐ風のシンタックス（構文
法）を用い、いくつかの例を掲げる。ここで定義するＦ
ＯＬＩＥ作用素は、Ｃｏｍｍｏｎ ＬｉｓｐおよびＣｏ
ｍｍｏｎ Ｌｉｓｐオブジェクト・システム仕様（ＣＬ
ＯＳ）（１９８７年Ｄ．ボブロウ（Ｂｏｂｒｏｗ）によ
るゼロックス・ドキュメント８７−００２「ＣＬＯＳ」
、および在ニュー・ヨークのアヂソン・ウェスレイ（Ａ
ｄｄｉｓｏｎ Ｗｅｓｌｅｙ）社１９８９年刊のＳ．Ｅ
．キーネ（Ｋｅｅｎｅ）による「Ｃｏｍｍｏｎ Ｌｉｓ
ｐによるオブジェクト指向プログラミング ＣＬＯＳ
へのプログラマーズ・ガイド（Ｏｂｊｅｃｔ−Ｏｒｉｅ
ｎｔｅｄ Ｐｒｏｇｒａｍｍｉｎｇ ｉｎ Ｃｏｍｍｏ
ｎ Ｌｉｓｐ， Ａ Ｐｒｏｇｒａｍｍｅｒ’ｓ Ｇｕ
ｉｄｅ ｔｏ ＣＬＯＳ）」）に類似した命名規約によ
って命名する。ＦＯＬＩＥにおけるローカル・クラス優
先リストの定義は、ＣＬＯＳにおけるクラス優先リスト
の定義から行われたものである。 【０１２０】１）表記および定義 ＦＵＮ１（ＡＲＧ１ ＡＲＧ２）を２つの引数ＡＲＧ
１およびＡＲＧ２の関数であるＦＵＮ１の宣言とする。 「＆ｏｐｔｉｏｎａｌ」はオプションの引数を宣言し、
「＆ｒｅｓｔ」は関数の残りのすべての引数の集まりを
宣言するものとする。「＆ｏｐｔｉｏｎａｌ（ＤＥＰＴ
Ｈ ０）」は、デフォルト値０を有するＤＥＰＴＨと
命名されたオプションの引数に対する宣言であるとする
。 （ＦＵＮ１ ＡＲＧ１ ＡＲＧ２）は、引数ＡＲＧ
１およびＡＲＧ２を付けた関数ＦＵＮ１の呼び出しを表
す関数コール表現とする。引数は、埋め込まれた関数コ
ールを表して、それ自体が関数コール表現となり得る。 ：：＝は、「結合」記号とする。従って、ＶＡＲ：：＝
（ＦＵＮ１ ＡＲＧ１ＡＲＧ２）は、ＶＡＲが、その
関数コールの結果に結合されることを示す。＝は、「定
義により等号」とする。−＞は、「戻り値」の記号とす
る。例えば、Ｖ１：：＝１２３ならば、Ｖ１−＞１２３
である。Ｆは、唯一のＬｉｓｐオブジェクト（例えば、
ある記号）によって識別される任意のフレーム・オブジ
ェクトとする。ＦＢは、任意のフレーム・ベースである
ものとする。ただし、ＦＢは、フレーム・オブジェクト
の集合からなる構造体である。ＭＦＢ（マルチプル・フ
レーム・ベース）は、ＦＯＬＩＥで定義された一般型（
一般のクラス）のフレーム・ベース・オブジェクトであ
るものとする。ＮＸは、ｎ個のスロット列ＮＸ＝（Ｘ１
Ｘ２．．．Ｘｎ）であり、Ｘ＝ＸｉはＮＸにおけるス
ロットであり、ＢＮＸｉはＸｉより前のＮＸの部分数列
であり、ＡＮＢｉはＸｉより後のＮＸの部分数列である
ものとする（ＡＮＸｉまたはＢＮＸｉまたは両者は、空
の数列（）である可能性もある）。従って、ＮＸ＝ＢＮ
Ｘｉ｜（Ｘｉ）｜ＡＮＸｉとなる。ただし、｜は数列の
連結を表す。 【０１２１】２）フレーム・ベースの生成ＭＦＢ（＆ｒ
ｅｓｔ Ｆ−ｓｅｔ） これは、Ｆフレーム・オブジ
ェクトの集まりである簡単なフレーム・ベースを生成す
る。 例：（ＭＦＢ Ｆ１ Ｆ２ Ｆ３）−＞（Ｆ１．．．Ｆ
２．．．Ｆ３．．．） これは、そのフレーム・ベー
スがＦ１、Ｆ２およびＦ３を含むことを示す。 【０１２２】３）多数のフレーム・ベースの生成ＭＡＫ
Ｅ−ＭＦＢ（＆ｏｐｔｉｏｎａｌ ＦＢ Ｆ ＮＸ−ｓ
ｅｔ（ＭＥＲＧＥ−ＴＹＰＥ：ＣＯＭＢＩＮＥ））
これは、フレームおよびフレーム・ベースの生成および
合併である。ここで、引数はすべてオプションであり、
ＮＸ−ｓｅｔは集合ＮＸ（一連のＮＸ）であり、ＭＥＲ
ＧＥ−ＴＹＰＥは以前に定義したような（：ＲＥＵＳＥ
：ＣＯＭＢＩＮＥ：ＯＶＥＲＷＲＩＴＥ）のうちの１つ
であり、ＭＥＲＧＥ−ＴＹＰＥのデフォルト値は：ＣＯ
ＭＢＩＮＥである。 例：ＦＢ：：＝（ＭＡＫＥ−ＭＦＢ） これは、空の
フレーム・ベースを生成する。（ＭＡＫＥ−ＭＦＢ Ｆ
Ｂ Ｆ） これは、フレーム・ベースＦＢに空のフレ
ームＦを追加する。（ＭＡＫＥ−ＭＦＢ ＦＢ Ｆ （
ＮＸ１．．．ＮＸｐ）） これは、スロット列（ＮＸ
１．．．ＮＸｐ）の集合を備えたフレームＦをＦＢに追
加する。Ｆが既にＦＢの要素である場合、（ＮＸ１．．
．ＮＸｐ）は、既存のフレームＦとの結合によって合併
される。（ＭＡＫＥ−ＭＦＢ ＦＢ Ｆ （ＮＸ’１．
．．ＮＸ’ｐ）：ＦＯＲＧＥＴ） これは、フレーム
Ｆの既存の定義を新しいもので置き換える。 【０１２３】４）アクセサとアサータ ＧＥＴＭＦＢ（＆ＯＰＴＩＯＮＡＬ ＦＢ Ｆ ＆ｒｅ
ｓｔ ＮＸ）は、ＦＢにおけるフレームＦのＮＸスロッ
トの記述にアクセスする。ＧＥＴＭＦＢ（＆ＯＰＴＩＯ
ＮＡＬ ＦＢ Ｆ ＆ｒｅｓｔ ＮＸ）：：＝ＶＡＬＵ
Ｅは、フレームＦに対するＮＸ位置においてＶＡＬＵＥ
を加える。値として空の数列（）を加えることは、Ｆに
おける位置ＮＸにおける現在の値フレームを削除するこ
とと同じである。ＧＥＴＭＦＢの値として真のフレーム
文Ｔを加えることは、ＦにおけるＮＸを表明することに
等しい。なお、ＶＡＬＵＥが（）でない場合、所与の値
（値フレーム）を含むローカル・フレームを生成するこ
とによってＶＡＬＵＥがＦに加えられること、ならびに
値の「追加」は合併によって行われることに注意を要す
る。従って、ＦＯＬＩＥにおいては、フレーム・ベース
は、その各副構成要素がフレーム・ベースであるという
点で、多重フレーム・ベースである。｛（ＧＥＴＭＦＢ
ＦＢ Ｆ Ｘ１．．．Ｘｎ）：：＝Ｔ｝＝（ＭＡＫＥ
−ＭＦＢ ＦＢ Ｆ （Ｘ１．．．Ｘｎ））であること
に注意を要する。 【０１２４】例：（ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ
２）：：＝ＶＡＬＵＥ１２である場合：（ＧＥＴＭＦＢ
ＦＢ Ｆ Ｘ１ Ｘ２）−＞（ＶＡＬＵＥ１２．．．
）は、値ＶＡＬＵＥ１２を含みそして恐らくはその他の
前の値をも含むような値フレームが、ＦＢのフレームＦ
におけるスロット位置（Ｘ１ Ｘ２）に存在することを
示す。（ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２ ＶＡＬ
ＵＥ１２）−＞（Ｔ）は、スロット位置（Ｘ１ Ｘ２
ＶＡＬＵＥ１２）に真の値フレーム（空でないフレーム
）が存在することを示す。（ＧＥＴＭＦＢ ＦＢ Ｆ
Ｘ１）−＞（Ｘ２（ＶＡＬＵＥ１２．．．）．．．）は
、ＶＡＬＵＥ１２を含む値フレームが位置（Ｘ２）に入
っている値フレームが、フレームＦにおけるスロット位
置（Ｘ１）に存在することを示す。 （ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２）＝（ＧＥＴＭ
ＦＢ（ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１）Ｘ２）（ＧＥＴ
ＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２）＝（ＧＥＴＭＦＢ（Ｇ
ＥＴＭＦＢ（ＧＥＴＭＦＢ ＦＢ）Ｆ）Ｘ１）Ｘ２） （ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２）：：＝ＮＥＷ
ＶＡＬＵＥ（ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２）−
＞（ＮＥＷＶＡＬＵＥ．．．ＶＡＬＵＥ１２．．．）は
、両方の値が今やＦにおける位置（Ｘ１ Ｘ２）の値
フレームの要素であることを示す。 （ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２ ＶＡＬＵＥ１
２）：：＝０（ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２）
−＞（ＮＥＷＶＡＬＵＥ．．．）は、ＶＡＬＵＥ１２が
Ｆにおける位置（Ｘ１ Ｘ２）の値フレームの要素で
ないことを示す。 （ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２ ＶＡＬＵＥ１
２）−＞０【０１２５】５）多重アサータ フレーム、またはＧＥＴＭＦＢのスロット引数のうちの
１つが、それ自体フレーム・ベースであり、表明に対し
てＧＥＴＭＦＢが呼び出された場合、その表明は、多重
化され、そのフレーム・ベース引数のすべての要素に分
配される。 【０１２６】例：Ｘ：：＝（ＭＦＢ Ａ Ｂ Ｃ）−＞
（Ａ．．．Ｂ．．．Ｃ．．．）とし、ＮＸ＝ＢＮＸ｜（
Ｘ）｜ＡＮＸである場合：｛（ＧＥＴＭＦＢ ＦＢ Ｆ
ＮＸ）：：＝Ｙ｝＝｛（ＧＥＴＭＦＢ ＦＢ Ｆ｜Ｂ
ＮＸ｜（Ａ）｜ＡＮＸ｜かつ（ＧＥＴＭＦＢ ＦＢ Ｆ
｜ＢＮＸ｜（Ｂ）｜ＡＮＸ｜かつ（ＧＥＴＭＦＢ Ｆ
Ｂ Ｆ ｜ＢＮＸ｜（Ｃ）｜ＡＮＸ｜）｝ （ＧＥＴＭＦＢ ＦＢ Ｆ ｜ＮＸ｜）：：＝（）は、
これらすべての表明を削除する。特に：（ＧＥＴＭＦＢ
ＦＢ ＦＢ ｜ＮＸ）：：＝Ｔは、フレーム・ベース
ＦＢのすべてのフレーム要素にＮＸを表明する。 （ＧＥＴＭＦＢ ＦＢ ＦＢ）＝（ＧＥＴＭＦＢ ＦＢ
）かつ（ＧＥＴＭＦＢ ＦＢ ＦＢ）：：＝（）は、Ｆ
Ｂのすべての要素からすべての事実を削除する。 【０１２７】６）関係アクセサおよび関係アサータフレ
ーム・オブジェクト間の記号関係を指定するために、ス
ロット列ＮＸを使用することができる。特に、ＦＯＬＩ
Ｅにおいては次のような構文法を用いて多重スロット列
を用いて、双対関係を定義することが可能である。即ち
、：＞を「前方」リンク記号とし、：＜を「後方」リン
ク記号とすると、（ＧＥＴＭＦＢ ＦＢ Ａ ：＞ Ｂ
）：：＝Ｔは、フレーム・ベースＦＢのフレームＡとフ
レームＢとの間の双対関係を表明する。ＦＯＬＩＥで定
義されるフレーム・オブジェクトに関するすべての処理
において、以下に定義される同等関係を実施することに
より関係の双対性が維持される。ＦＢを現在のフレーム
・ベースとする。フレーム・ベースＦＢにおいて表明Ｎ
Ｘが真であることを示すために、（ＧＥＴＦＭＢＦＢ
ＮＸ）：：＝Ｔを短縮形［ＮＸ］＝Ｘ１ Ｘ２．．．Ｘ
ｎで表すものとする。＜＝＞を同値記号とする。要素と
してＡ、ＢおよびＣを含むフレーム・ベース（ＭＦＢ
Ａ Ｂ Ｃ）を短縮形（Ａ Ｂ Ｃ）によっ
て表すものとする。すると、ＦＯＬＩＥにおける関係に
ついての次の表明は真である。 ａ）直接関係同値 Ａ：＞Ｂ＜＝＞Ｂ：＜Ａ ｂ）多対１関係の分配性 （Ａ Ｂ）：＞Ｃ＜＝＞｛Ａ：＞Ｃ かつ Ａ：＞Ｃ｝
ｃ）ｓｉｎｋ関係の分配性 ＦＢ：＞ＯＭＥＧＡ＜＝＞ＦＢのすべてのＦに対し｛Ｆ
：＞ＯＭＥＧＡ｝ｄ）１対多関係の分配性 Ａ：＞（Ｂ Ｃ）＜＝＞｛Ａ：＞Ｂ かつ Ａ：＞Ｃ｝
ｅ）トポロジー関係の分配性 ＡＬＰＨＡ：＞ＦＢ＜＝＞ＦＢのすべてのＦに対し｛Ａ
ＬＰＨＡ：＞Ｆ｝ｆ）Ｎ項関係の同値 Ａ Ｘ１ Ｘ２．．．Ｘｎ：＞Ｚ ＜＝＞ Ｚ Ｘ１
Ｘ２．．．Ｘｎ：＜Ａさらに、前記のａ）からｅ）まで
の表明は、Ｎ項関係に対しても同様に真である。 【０１２８】例： （Ａ Ｂ Ｃ） ＣＯＮＮＥＣＴ
ＳＡＴＥＬＬＩＴＥ ：＞ ＶＥＧＡ＜＝＞｛Ａ ＣＯ
ＮＮＥＣＴ ＳＡＴＥＬＬＩＴＥ ：＞ ＶＥＧＡかつ
Ｂ ＣＯＮＮＥＣＴ ＳＡＴＥＬＬＩＴＥ ：＞ Ｖ
ＥＧＡかつ Ｃ ＣＯＮＮＥＣＴ ＳＡＴＥＬＬＩＴＥ
：＞ ＶＥＧＡ｝＜＝＞｛ＶＥＧＡ ＣＯＮＮＥＣＴ
ＳＡＴＥＬＬＩＴＥ ：＜ Ａかつ ＶＥＧＡ ＣＯ
ＮＮＥＣＴ ＳＡＴＥＬＬＩＴＥ ：＜ Ｂかつ ＶＥ
ＧＡ ＣＯＮＮＥＣＴ ＳＡＴＥＬＬＩＴＥ ：＜ Ｃ
｝【０１２９】７）作用素の設定 ＦＢが、次の処理を行う間にすべての双対関係を表明す
るために「ルート」として使用される現在のフレーム・
ベースであるとする。ＭＦＢ−ＭＥＲＧＥ（ＴＹＰＥ
ＦＢ１ ＆ｒｅｓｔ ＦＢ−ｓｅｔ） これは、（：
ＲＥＵＳＥ：ＣＯＭＢＩＮＥ：ＯＶＥＲＷＲＩＴＥ：Ｆ
ＯＲＧＥＴ）の一要素であるＴＹＰＥにしたがって、フ
レーム・ベースの集合ＢＦ−ｓｅｔをＦＢ１へと合併す
る（ＦＢ１を変更する）。ＭＦＢ−ＩＮＴＥＲＳＥＣＴ
ＩＯＮ（ＦＢ１ ＆ｒｅｓｔ ＦＢ−ｓｅｔ） ＦＢ
１を、それ自体（その表明）とフレーム・ベースの集合
（からのすべての表明）との交事象（積集合）にする。 ＭＦＢ−ＤＩＦＦ（ＦＢ１ ＆ｒｅｓｔ ＦＢ−ｓｅｔ
） フレーム・ベース集合からのすべての表明をＦＢ
１から削除する。ＭＦＢ−ＴＲＡＮＳＦＥＲ（ＦＢ１
ＦＢ２）＝ＭＦＢ−ＭＥＲＧＥ（：ＲＥＵＳＥ ＦＢ２
ＦＢ１） ＦＢ２において全く相似を持たないＦＢ
１からのすべての表明を加えてＦＢ２とすることに相当
する合併の使用。ＭＦＢ−ＵＮＩＯＮ（ＦＢ１ ＆ｒｅ
ｓｔ ＦＢ−ｓｅｔ）＝ＭＦＢ−ＭＥＲＧＥ（：ＣＯＭ
ＢＩＮＥ ＦＢ１ ＆ｒｅｓｔ ＦＢ＝ｓｅｔ） フ
レーム・ベースの集合からのすべての表明の集合統一に
相当する合併の使用。ＭＦＢ−ＲＥＰＬＡＣＥ（ＦＢ１
ＦＢ２）＝ＭＦＢ−ＭＥＲＧＥ（：ＦＯＲＧＥＴ Ｆ
Ｂ２ ＦＢ１） ＦＢ２をフレーム・ベースにあるＦ
Ｂ１によって置き換えることに相当する合併の使用。Ｍ
ＦＢ−ＸＯＲ（ＦＢ１ ＆ｒｅｓｔＦＢ−ｓｅｔ）
ＦＢ１とＦＢ−ｓｅｔにおける各フレーム・ベースとの
両者に対して対をなして真でない表明の集合となるよう
に、ＦＢ１を変更する。 【０１３０】８）叙述子（Ｐｒｅｃｉｄａｔｅ）ＭＦＢ
−ＩＮＣＬＵＤＥ−Ｐ（＆ｒｅｓｔ ＦＢ−ｓｅｔ）
これは、ＦＢ−ｓｅｔが包含関係に対する順序集合で
ある場合、真となる。例えば、（ＭＦＢ−ＩＮＣＬＵＤ
Ｅ−Ｐ ＦＢ１ ＦＢ２）ー＞Ｔは、ＦＢ１がＦＢ２の
サブフレーム・ベースに等しく、ＦＢ１において真であ
るすべての表明はＦＢ２においても真であると言うこと
を意味する。ＭＦＢ−ＭＩＮＩＭＡＬ−Ｐ（ＦＢ）
ＦＢについて真であるような表明が存在しないならば、
真となる。例えば、（ＭＦＢ−ＭＩＮＩＭＡＬ−Ｐ（Ｍ
ＡＫＥ−ＭＦＢ））−＞Ｔである。ＭＦＢ−ＥＱＵＡＬ
（ＦＢ１ ＦＢ２ ＆ｏｐｔｉｏｎａｌ ＤＥＰＴＨ）
（ＭＦＢ−ＩＮＣＬＵＤＥ−Ｐ ＦＢ１ ＦＢ２）
および（ＭＦＢ−ＩＮＣＬＵＤＥ−Ｐ ＦＢ２ ＦＢ１
）が共に真の場合、真となる。 【０１３１】注意事項：ある種の処理の効率のために、
ここと以下においてオプションの引数ＤＥＰＴＨを使用
する。（）というデフォルトのＤＥＰＴＨは、フレーム
・ベース全体が検討されることを示す。０というデフォ
ルトのＤＥＰＴＨは、フレーム・ベースの第１の水準が
検討されることを示す。ＤＥＰＴＨが数である場合、そ
の数は、検討されるスロット列ＮＸの最大サイズから１
を引いた数を示す。 【０１３２】９）ユーティリティ ＭＦＢ−ＣＯＰＹ（ＦＢ ＆ｏｐｔｉｏｎａｌ ＤＥＰ
ＴＨ） ＦＢのコピーを作る。 ＭＦＢ−ＣＬＯＳＥ（ＦＢ ＆ｒｅｓｔ ＦＢ−ｓｅｔ
） ＦＢ−ｓｅｔのフレーム・ベースに対するすべて
の双対リンクを（閉じられる各双対リンクへの参照とし
てＦＢを用いて）閉じる。ＭＦＢ−ＰＲＩＮＴ（ＳＵＢ
ＦＢ ＆ｏｐｔｉｏｎａｌ ＳＴＲＥＡＭ ＤＥＰＴＨ
） フレーム・ベースＳＵＢＦＢのシンボル表現を与
える。ＳＵＢＦＢは、フレーム・ベースＦＢの部分集合
でもＦＢ全体でも良い。ＳＴＲＥＡＭが指定されていれ
ば、それが、ＳＵＢＦＢを対応するＳＴＲＥＡＭ装置に
印刷するために、使用される。ＭＦＢ−ＲＥＡＤ（ＦＢ
＆ｏｐｔｉｏｎａｌ ＳＴＲＥＡＭ ＤＥＰＴＨ）
ＳＴＲＥＡＭからフレーム・ベースの集合のシンボル
表現を読み、結果としてのフレーム・ベースをＦＢへと
合併する。 【０１３３】１０）マッパー ＭＡＰ−ＭＦＢ（ＦＣＮ ＦＢ ＆ｏｐｔｉｏｎａｌ
（ＤＥＰＴＨ ０）） ＦＢのすべてのスロットと値
とに対し関数定義ＦＣＮをＤＥＰＴＨまで適用する。Ｍ
ＡＰ−ＭＦＢ−ＳＬＯＴ（ＦＣＮ ＦＢ ＆ｏｐｔｉｏ
ｎａｌ （ＤＥＰＴＨ ０）） ＦＢのすべてのスロ
ットに対し関数定義ＦＣＮをＤＥＰＴＨまで適用する。 ＭＡＰ−ＭＦＢ−ＶＡＬＵＥ（ＦＣＮ ＦＢ ＆ｏｐｔ
ｉｏｎａｌ （ＤＥＰＴＨ ０）） ＦＢのすべての
値に対し関数定義ＦＣＮをＤＥＰＴＨまで適用する。 【０１３４】１１）ローカル・クラス優先リスト（ＬＣ
ＰＬ） ＬＣＰＬに用いられる定義は、ＣＬＯＳ仕様（Ｃｏｍｍ
ｏｎ Ｌｉｓｐオブジェクト仕様）から生まれたもので
ある。ＣＬＯＳではＣＰＬが単一継承分の階層に対して
定義されるのに対し、ＦＯＬＩＥでは、（ＮＸによって
定義される）Ｎ項関係によって指定される任意の階層に
対してＬＣＰＬが定義される。 【０１３５】ＭＦＢ−ＬＣＰＬ（ＦＢ Ｆ ＮＸ ＆ｏ
ｐｔｉｏｎａｌ ＤＥＰＴＨ） ＮＸによって指定さ
れる階層関係に局限されたＦＢ内のＦのクラス優先階層
を構成するフレーム・オブジェクトの順序集合を返す。 【０１３６】例：ＦＢが、以下の（短縮形の）表明が真
であるようなフレーム・ベースであるとする。 この場合、関係（Ｂ Ｃ）に関しＦＢにおけるＡに対す
るローカル・クラス優先リストは、（ＭＦＢ−ＬＣＰＬ
ＦＢ Ａ （Ａ Ｂ））−＞（Ａ Ｄ Ｄ１ Ｅ Ｅ
１ Ｚ）である。関係（Ｂ Ｃ）に対しＡの継承された
属性を探す場合、この属性に対する（Ａ Ｄ Ｄ１Ｅ
Ｅ１ Ｚ）を連続的に見る。継承された属性の探査は、
以下で定義するＭＦＢ−ＢＲＯＡＤＣＡＳＴを用いて行
われる。 【０１３７】１２）関数の放送 ＭＦＢ−ＢＲＯＡＤＣＡＳＴ（ＦＣＮ ＦＢ Ｆ ＮＸ
＆ｏｐｔｉｏｎａｌＤＥＰＴＨ） フレーム・オブ
ジェクトＦおよびフレーム・ベースにおけるＮＸによっ
て定義される階層においてＦに先行するすべてのオブジ
ェクトに対し関数定義ＦＣＮを適用する。ＭＦＢ−ＢＲ
ＯＡＤＣＡＳＴ−ＣＯＬＬＥＣＴ（ＦＣＮ ＦＢ Ｆ
ＮＸ ＆ｏｐｔｉｏｎａｌ ＤＥＰＴＨ） ＭＦＢ−
ＢＲＯＡＤＣＡＳＴに似ているが、その階層におけるＦ
のすべての先行例に対するＦＣＮの適用結果を収集する
。 【０１３８】プレスクリプト ＧＲＡＳ風の対話的アクタと規則ベースの環境における
システム作用のビジュアル・プログラミングと対話的・
動的かつ柔軟性のある編集は、ビジュアル・オブジェク
トの定義によって可能となる。アクタ・フレーム構造体
は、ＧＲＡＳにおけるアクタの視覚的表現を実現するた
めに、オプションでビジュアル・オブジェクトによって
拡大することができる。つまり、Ａｃｔｏｒ ＝ Ｄ（
Ａ，ｔ）＝ Ｂａｓｅ−Ｆｒａｍｅ＋ ｛Ｖｉｓｕａｌ
Ｏｂｊｅｃｔ｝ ＋ ｛Ｂｅｈｅａｖｏｒ｝であり、
このアクタは、時刻ｔにおけるデータ空間の記述Ｄ（Ａ
，ｔ）によって完全に指定される。しかし、データ空間
の記述は、ビジュアル・オブジェクト成分、基本フレー
ム記述、および現在時刻における可能な作用の継承され
た（恐らくは空の）集合を引き出し得る元の作用指定子
の集合に分解することができる。 【０１３９】ビジュアル・オブジェクトは、自己表示お
よび自己記述を行い、他のビジュアル・オブジェクトと
合併することが可能であり、さらに種々の視覚的表現（
例えば、アイコン、テキスト、ボタン、幾何学的な形、
グラフィックスの原形の組み合わせ）を持つことが可能
である。さらに、アクタに関係付けられたビジュアル・
オブジェクトは、テープの直接の構成員であり得る。そ
のビジュアル・オブジェクトに対応するフレームも、そ
のテープ・フレームに連結される。従って、１つのアク
タは、それが使用されるテープの各インスタンスについ
て２つのリンクを持つことができる。即ち、そのテープ
とそのビジュアル・オブジェクトとの間のリンク、およ
びそのフレーム記述とそのテープに関係付けられたフレ
ーム記述との間の双方向リンクである。 【０１４０】ビジュアル・オブジェクト表現の基礎とな
るのは、プレスクリプト（ＰｒｅＳｃｒｉｐｔ）グラフ
ィックス言語である。プリスクリプトでは、プリスクリ
プトのインタープリタ、コンパイラおよびデバッガのほ
か、接頭語表記およびＬｉｓｐ風の構文法も使用される
。プリスクリプトは、指示装置（例えば、マウス、カー
ソル）および利用者の入力をとらえ出力機構を与える機
構の定義を含めるために拡張された２次元、３次元また
はそれ以上の次元のベクトル空間代数を直接的に実現し
たものである。 【０１４１】プリスクリプトの実現には、ベクトル、ノ
ルム、距離、ベクトル演算（スカラー積、加算、減算、
ベクトル積）、直交性、平行性、点、線、平面、超平面
、射影、配景、原始的幾何学的対象（線分、線筋、２次
曲線、多角形、平行６面体、円柱、曲面モデル）、空間
位置の原形（内側、外側、交わり、合併、要素関係、隠
れた曲面）、線形変換およびアフィン変換、相似（回転
、移動、尺度構成、点対象および面対象）に対する定義
が含まれる。また、プレスクリプトのグラフィックス言
語には、表示装置、多数の視点、きめ、色、字体（フォ
ント）、テキストおよび座標の入出力装置、イメージ（
グラフィック要素の配列）、タイル、グラフィカルな周
期性および反復性の定義も含まれる。 【０１４２】プレスクリプト・コマンドの実行中にエラ
ーが発生すると、エラー・メッセージが、返され、説明
表示部位（Ｅｘｐｌａｉｎａｔｉｏｎ Ｖｉｅｗ）に表
示され、現在のプレスクリプト表現の実行は中止される
が、プレスクリプトの実行が阻止されるわけではない。 描画中のエラーは、次のような意味で決して致命的では
ない。即ち、所与のプレスクリプト・オブジェクトの表
示中のエラーにより、次のようなプレスクリプト・オブ
ジェクトの表示が妨げられることはない。しかし、第２
の表示結果が第１のものに依存する場合、第２の表示結
果は、正しくない可能性がある。 【０１４３】プレスクリプト・オブジェクトは、プレス
クリプト作用素、ならびに型引数（例えば、数型）およ
び仮想的評価環境において束縛される推測されるシンボ
ル引数からなる良く構成されたプレスクリプト表現であ
る。視覚的なオブジェクトは、４つのプレスクリプト要
素の組み合わせによって定義される。４つのプレスクリ
プト要素とは、Ｐ＝（ｄ，ｅ，ｉ，ｓ）である。ここで
、ｄ＝「描画（ｄｒａｗｉｎｇ）」、ｅ＝「エクステリ
ア（ｅｘｔｅｒｉｏｒ）」、ｉ＝「インテリア（ｉｎｔ
ｅｒｉｏｒ）」、およびｓ＝「センサ（ｓｅｎｓｏｒ）
」である。さらに、４つのセンサ方式（利用者対話作用
）Ｓ＝（ｉｎ，ｅｘ，ｂｃ，ａｃ）がある。ただし、ｉ
ｎ＝「センサに入る手順」、ｅｘ＝「センサから出る手
順」、ｂｃ＝「クリック前の手順」、ａｃ＝「クリック
後の手順」である。 【０１４４】プレスクリプトの要素は、次のように定義
される。即ち、描画（ｄ）は、視覚的対象の（表示装置
から独立した）描き方と初期の描画から動画を与えるオ
プションの変換関数とを記述するプレスクリプト・オブ
ジェクトである。エクステリア（ｅ）またはマスクは、
所与の表示部位（ｖｉｅｗ）において視覚的表現対象に
範囲を定めるために使用される明確に定義されたインテ
リアを有するプレスクリプト・オブジェクトである。イ
ンテリア（ｉ）または範囲は、ビジュアル・オブジェク
トの実質的な内部に範囲を定めるために使用される明確
に定義された内部を有するプレスクリプト・オブジェク
トである。センサ（ｓ）は、指示装置の指示に感応する
領域に範囲を定めるために使用される明確に定義された
インテリアを有するプレスクリプト・オブジェクトであ
る。 【０１４５】図４における利用者アクタによって例示し
たようなプレスクリプト・オブジェクトの例を以下に示
す。 【数１】 【０１４６】このプレスクリプト・オブジェクトＰ１は
、Ｐ１の設定環境（ｌｅｔで設定される）におけるｄ１
に従って、表示装置上のｘ、ｙ座標（８０６，２７６）
の周囲を中心とした位置に表示される。変数「ｉｃｏｎ
」が指定された位置に表示される。変数「ｎａｍｅ」が
、使用されて、指定の位置にヘルベチカ（Ｈｅｌｖｅｔ
ｉｃａ）フォント（サイズ１４、肉太型）で印字された
後、枠が描かれる。エクステリアｅ１は、座標Ｐ１を中
心とし、半径１５０の円の外部によって定義される。イ
ンテリア（ｉ）は、座標Ｐ１を中心とする幅「ｗ」およ
び高さ「ｈ」の四角の内部である。そして、センサ領域
ｓ１は、「ｎａｍｅ」の表示を囲む四角ｉ１の底にある
さらに小さい四角によって範囲が決定される。 【０１４７】センサ方式は、次のように定義される。即
ち、センサに入る手順（ｉｎ）は、指示装置が視覚対象
のセンサ領域に入ったときに呼び出される手順である。 デフォルトの手順は、マウスがセンサ領域に入ったとき
、そのセンサ領域が強調されることである。センサから
出る手順（ｅｘ）は、指示装置がセンサ領域から出たと
きに呼び出される手順である。デフォルトの手順は、マ
ウスがセンサ領域から離れた場合、センサ領域が強調さ
れなくなることである。クリック前の手順（ｂｃ）は、
指示装置がセンサ領域において選択を行うために使用さ
れるとき（例えば、マウスがクリックされるとき）に呼
び出される手順である。センサ領域を色付けしたり再描
画したりする、現在の表示部位において視覚対象のポイ
ンタに関連した動きを与える、現在の評価環境における
記号的事実を変更する、視覚対象に関する操作のメニュ
ーを出す、またはいくつかの手順の組み合わせを含む、
いくつかのデフォルト手順が利用できる。クリック後の
手順（ａｃ）は、センサ領域における指示装置の選択が
解除されたときに呼び出される手順である。デフォルト
の手順は、恐らくは変化した評価環境においてセンサ領
域を再描画するときに利用できる。 【０１４８】Ｐ１の表示された名前を変更するＰ１に対
するクリック前の手順を、前記のＰ１の例に従って、以
下において定義する。 【数２】 この定義、ならびに「ｉｎ」、「ｅｘ」および「ａｃ」
の手順に関する前記のデフォルトの定義の結果として、
次のように言える。指示装置が、Ｐ１のセンサ領域ｓ１
（「ｎａｍｅ」の表示の周囲の見えない四角）に入ると
、「ｉｎ」の手順が呼び出され、四角ｓ１が強調される
。指示装置を用いてＰ１のセンサ領域で選択を行うと、
Ｐ１の「ｂｃ」手順が呼び出され、これによって、（「
ｐｒｅｖｉｏｕｓ−ｎａｍｅ」（前の名前）と称する新
たな変数の下に「ｎａｍｅ」という現在の変数を格納し
た後に）Ｐ１の環境における「ｎａｍｅ」の値が「Ｍａ
ｒｇａｒｅｔ」に変化する。指示装置が解放されると、
Ｐ１に関するデフォルトの「ａｃ」手順が呼び出される
ことによって、プレスクリプトの要素ｄ１がＰ１の（変
化した）環境において実行される。従って、最上部にア
イコンがあり、最下部にヘルベチカ・フォントで「Ｍａ
ｒｇａｒｅｔ」（特定の利用者の名前）という語が印字
された四角として、Ｐ１が表示される。指示装置が、第
２の選択のインサイドｓ１のために使用された場合、Ｐ
１の名前は、Ｐ１の環境において定義された利用可能な
「ｐｒｅｖｉｏｕｓ−ｎａｍｅ」の値に変更される。従
って、名前「ｕｓｅｒ」が、Ｐ１の環境における変数「
ｎａｍｅ」の値として復活する。第２の選択の内側ｓ１
の解放時に呼び出される「ａｃ」手順によって、Ｐ１の
表示は、最上部にアイコンがあり、最下部に「ｕｓｒ」
と言う語がある四角へと変化して戻る。指示装置がＰ１
のｓ１領域を離れると、「ｅｘ」のデフォルト手順が呼
び出され、ｓ１は強調されなくなる。 【０１４９】アクタの選択可能な視覚表現を対話的に設
計するために、ＧＲＡＳでは前記のようなクリック手順
が使用される。それによって、ボタン、スイッチ、およ
び種々の入出力ビジュアル・オブジェクトが提供される
。これらの構成物をさらに込み入ったシステム要素へと
結合するために、アクタの合成が用いられる。例えば、
電話のオブジェクトは、ケース・アクタ、押しボタンア
クタの集合、液晶表示、および送受話器から構成される
。 【０１５０】クリック手順は、引数付きで定義された場
合、指示装置を介して行われる選択の型について選択的
である（例えば、左ボタンの選択に対し右ボタンの選択
と異なった定義をすることができるなど）。クリック手
順のための評価環境を形成するために、現在の環境が用
いられる。指示装置において行われるビジュアル・オブ
ジェクト、現在の表示部位、および選択の型は、これら
の手順に対する引数として渡される。さらに、ビジュア
ル・オブジェクトの階層（例えば、成分関係）が所与で
あるとし、ビジュアル・オブジェクトＡが、その階層に
おいてビジュアル・オブジェクトＢの下位のものである
ならば、Ａは、その上位の属性への明確な参照を用いる
ことによって、Ｂの環境へのアクセスも有する。 【０１５１】例えば、電話オブジェクトＰｈ１が、押し
ボタンＰＢ１のサブオブジェクトを有する場合、ＰＢ１
の環境において、Ｗはその押しボタンの幅であり、（Ｓ
ＵＰＥＲＩＯＲ Ｗ）は、ＰＢ１の上位のもの（ｓｕ
ｐｅｒｉｏｒ）、つまり電話オブジェクトＰｈ１、の幅
である。 【０１５２】デフォルトのクリック手順によって、現在
のビュー（表示部位）Ｖにあるビジュアル・オブジェク
トＡの動きが、ビューＶにおけるＡに与えられる強制関
数にならって与えられる。運動は、（成分の階層にある
）Ａの上位のものの程度分だけさらに強制される。成分
の階層のＡの最上位のものは、現在のビューにおけるす
べてのアクタの運動が入っているビューＶ用のビデオ・
モニタである。 【０１５３】例えば、Ｐｈ１のサブオブジェクトＣ１（
カーソル）が動いているならば、Ｃ１の運動は、Ｐｈ１
の内部（ｉｎｔｅｒｉｏｒ）領域に限られる（Ｐｈ１の
「ｉ」要素）。 【０１５４】アクタのプレスクリプト評価環境は、３つ
の環境の組み合わせからなる。 １）そのアクタの局部知識ベースを記述する環境：（ｌ
ｅｔ ａｌ＝Ｖ１，．．．，ａｎ＝ｖｎ，．．．）ただ
し、「ａｉ」は、その知識ベースにおける事実の記号名
を表し、「ｖｉ」は、対応する値または表現である。 ２）そのアクタの関連する特性を記述する環境：（ｌｅ
ｔ ｓｅｌｆ＝ｖｓｅｌｆ，ｎａｍｅ＝ｖｎａｍｅ，ｉ
ｎａｍｅ＝Ｖｉｎａｍｅ，ｉｃｏｎ１＝ｖｉｃｏｎ１，
．．．，ｘ１＝ｖｘ１，ｘ２＝ｖｘ２，．．．，ｘｐ＝
ｖｘｐ，．．．）ただし、「ｓｅｌｆ」（アクタ自体）
は、「ｖｓｅｌｆ」、即ちこのアクタに特有の識別子（
例えば、そのアドレス）に束縛される。「ｎａｍｅ」は
、アクタのステージ名に束縛される。「ｉｎａｍｅ」は
、そのアクタの内部名（またはシンボル・アドレス）に
束縛される。 「ｉｃｏｎ１」は、アイコン表現「ｖｉｃｏｎ」、即ち
アイコン・ライブラリにあるアイコンの記号的な識別子
に束縛され、可視イメージを生成するために、使用され
る。「ｘｉ」は、ｐ次元の絶対座標系におけるアクタの
座標に固定された絶対的な関連で束縛される。 ３）所与のテープに対して定義され、ビューの集合｛ｖ
ｉｅｗｊ｝（ｊ＝１，．．．，ｑ）に対するアクタの視
覚的表現および属性に関する変換と強制の集合を定義す
る環境：この環境は、次のものからなる。則ち、（ａ）
異なるビューに対する異なる座標：Ｔ：｛ｘｉ｝ −＞
（ｖｉｅｗ１／ｔ１（｛ｘｉ｝），．．．，ｖｉｅｗ
ｑ／ｔｑ（｛ｘｉ｝））Ｔ（ｖｉｅｗｊ）：｛ｘｉ｝
−＞ ｔｊ（｛ｘｉ｝）ただし、ｔｊは、その絶対座標
に基づくｊ番目のビューにあるアクタの座標を得る変換
関数である。その変換がビューにおいて線形ならば、そ
の変換は、座標変換行列Ｍｊ（｛ｘｉ｝＝Ｍｊ｛ｘｉ／
ｖｉｅｗ｝）を用いて表すことができる。（ｂ）ビュー
の集合における座標の移動に関する強制： Ｃ：｛ｘｉ｝ −＞ （ｖｉｅｗ０／ｃ０（｛ｘｉ｝）
，ｖｉｅｗ１／ｃ１（｛ｘｉ｝），．．，ｖｉｅｗｑ／
ｃｑ（｛ｘｉ｝）） Ｃ（ｖｉｅｗｊ）：｛ｘｉ｝ −＞ ｃｊ（｛ｘｉ｝）
ただし、ｃｊは、ｊ番目のビューにおいて観察されるア
クタの座標に対する強制関数である。絶対座標系に単一
の強制関数ｃ０が与えられる場合、ビューｑを発生する
線形変換Ｍｊが存在し、さらに各ビューに対して使用さ
れる強制関数が ｃｊ＝ｃ０ ｏ Ｍｊ であると仮定する。 （ｃ）すべてのビューに対する記号翻訳関数の集合：こ
の関数のアクタは次のように表される。 ｖｉｅｗｊ −＞ ｔｒｊ ただし、ｔｒｊは、アクタの環境（ｎａｍｅ、ｉｎａｍ
ｅ，ｉｃｏｎなど）からの記号特性または局部知識ベー
ス（ａｉ）からの要素の名前をｊ番目のビューで使用さ
れる新たな名前に変換する。デフォルトの翻訳関数は、
無変換である。 【０１５５】ｊ番目のビューにおけるアクタの視覚的表
現は、ビューがｖｉｅｗｊであることを知っているその
アクタのプレスクリプト環境の中でアクタに関係付けら
れたビジュアル・オブジェクトの第１のプレスクリプト
表現（描画）を評価することによって得られる。アクタ
のプレスクリプト環境は、そのアクタのビジュアル・オ
ブジェクト（それぞれエクステリア、インテリア、およ
びセンサ）の定義ならびに利用者の対話中の適切なセン
サおよびクリック手順の呼び出しに使用される他の３つ
のプレスクリプト・オブジェクト（ｅ、ｉおよびｓ）の
評価にも使用される。 【０１５６】すべてのビューにおけるグラフィカルな変
化は、時刻ｔにおけるアクタ環境のプレスクリプト評価
によるアクタの知識ベースへの論理的変更によって直接
的にもたらされる。アクタのグラフィック表現を記述す
るプレスクリプト表現は、このアクタの設定環境（ｌｅ
ｔ環境）の束縛事項（ａｉ）を使用する。従って、「ａ
ｉ」スロットのの値は、アクタのプレスクリプト・オブ
ジェクトのプレスクリプト要素（ｄ、ｅ、ｉ、ｓ）の指
定に自由に使用される。この性質により、アクタのｌｅ
ｔ環境として実現されるアクタの知識ベースの変更を反
映する表示の変更がサポートされる。グラフィック・エ
ディタは、使用規則、前記のような論理的変更、および
グラフィカルな効果を関係付け結合させるコードを自動
的に生成する。他の実施例では、論理的変更とグラフィ
カルな効果との間のデーターベースが維持されるものも
ある。ＧＲＡＳシステムのユーザ・インタフェースは、
そのようなビジュアル・オブジェクト（アクタの視覚的
表現）を用いて作った。この表現方法の柔軟性は、ビジ
ュアル・オブジェクトを用いて作ったシステム（への）
インタフェースは数日で完全に設計し直すことができる
ほどである。この環境は、それ自体のインタフェース、
例えば、ボタンの外観および感知力の変更、新たなボタ
ンの追加、および対応するコマンドなどを編集するよう
に、設定することができる。これは、それ自体の中でＶ
ＳＭベースのシステムを再設計する仮定における第１段
階である。 【０１５７】実行中は、アクタの知識ベースの履歴がソ
フトコーダによって自動的に維持され、グラフィックス
と状態の完全に可逆的な実行を与えている。各アクタは
、中でそれが使用されている各テープに対して自動的に
維持されているそのアクタの属性の変化の履歴を持って
いる。この履歴は、有効な変更の記録であり、そのアク
タがあるテープで使用されていなければ、その履歴は、
そのテープに対しては空である。アクタの属性への変更
により、アクタのグラフィック表現に影響を与えること
が可能であり、テープのシミュレーション中にアクタの
視覚表現に可能な唯一の変更は、その属性の変更による
ものである。従って、維持される履歴は、アクタの内部
的な属性とその視覚的な表現の両方の完全な記録を与え
るに十分な機構である。 【０１５８】アクタ間の通信 アクタ間の通信は、ソフトコーダによるスクリプト規則
の実行を介して行われる。通信には、アクタ間の情報の
伝送、およびその伝送にともなうすべての処理が含まれ
る。通信機能が低下した場合、アクタからそれ自体への
伝送を伴い、そのアクタ環境における内部処理と同じに
なる。通信には２つのモード、即ち（１）相互同意によ
る通信、および（２）送付（ｄｅｌｉｖｅｒｙ）による
通信が定義される。 【０１５９】（１）相互同意による通信：２つの異なる
アクタの間のメッセージ転送を伴うスクリプト規則の実
行の場合を考えると、メッセージが送信される前にセン
ダとレシーバの両アクタの事前条件が同時に満たされる
とき、この通信は、相互の同意によって実行される。ま
たこの通信は、同期通信とも称し、次式を使って表され
る。 Ｐ（Ｓ，Ｒ）＝＞Ｍ（Ｓ，Ｒ）＝＞Ｑ（Ｓ，Ｒ）ここで
、Ｓはセンダ、Ｒはレシーバ、Ｐ、ＭおよびＱはそれぞ
れ事前条件、ＭＳＧおよび事後条件である。同期通信は
、アクタ・システムにおける最小単位の処理である。 【０１６０】（２）送付による通信：スクリプト規則が
与えられ、センダのアクタの事前条件がレシーバのアク
タの事前条件より先に満たされた場合、通信は送付（ｄ
ｅｌｉｖｅｒｙ）を介して行われる。センダのアクタは
、その環境において構成されたメッセージを事前条件の
満足時に発行する。すると、そのスクリプト・インスタ
ンスは、「Ｓｅｎｔ」（送信済み）というスクリプト型
を用いて印が付けられ、ソフトコーダは、レシーバのア
クタに送付するために、その通信を待ち行列に加え、さ
らにセンダのアクタの事後条件が実行される。この通信
は、非同期通信とも呼ばれ、前の表記を用いて次のよう
に表すことができる。 Ｐ（Ｓ）＝＞Ｍ（Ｓ，Ｓｅｎｔ）＝＞Ｑ（Ｓ）（ｗａｉ
ｔ） Ｐ（Ｒ）＝＞Ｍ（Ｄｅｌｉｖｅｒｅｄ，Ｒ）＝＞Ｑ（Ｒ
） Ｍ（Ｓ，Ｓｅｎｔ）は、メッセージが、センダの環境に
おいてそれが送られるときに、構成されることを示す。 Ｍ（Ｄｅｌｉｖｅｒｅｄ，Ｒ）は、メッセージがＲによ
って受信された時、Ｒの環境は、送付されたメッセージ
からの環境を含めるために、一時的に拡大され、次に、
この一時的な環境において、Ｒの事後条件Ｑ（Ｒ）が実
行される。 【０１６１】アクタ間の一般的な通信モデルにおいて、
アクタは、いくつかの通信を平行して送受信などの処理
を行うことができる。ただし、これが所与のアプリケー
ションにとって望ましくないならば、この問題を避ける
ようにスクリプト規則を設計することができる。アクタ
の事後条件が平行して実行されたために、現在のアクタ
環境の同一の属性に多重に変更が起こる場合、矛盾の可
能性がある。このような矛盾は、実行時に容易に検出さ
れるので、目的のアプリケーションにとって容認できる
技法を用いて解決することができる（無作為抽出、多重
値、変更上書き、エラー信号など）。 【０１６２】問題のアクタが関与するテープ・プログラ
ムの実行中に、利用者が、アクタを削除したり、アクタ
の記述を変更したりすると、可能な別の矛盾例が発生す
る。問題は、その変更が特定のシナリオの実行に限られ
るのか、あるいはそのアクタのオリジナルの記述に対し
て報告された（グローバルな）ものか、ということであ
る。この矛盾は、利用者に局部的（ローカルな）変更か
全体的（グローバルな）変更かを選択させることによっ
て解決される。変更が局部的な場合、現在時刻のＡのデ
ータ空間だけが、Ａの将来の履歴のように影響を受けて
る。変更が全体的な場合、最初は、その変更が局部的に
行われ、アクタの履歴が空でなければ、その変更もＡの
初期のデータ空間の記述に報告されている。削除されて
いるアクタによって、その変更が、スクリプト規則の集
合の削除を必要とする場合、利用者はそれらの規則の削
除に関する確認させられ、そして手の施しようのない矛
盾を避けるために、テープ・プログラム実行の自動巻き
戻しが行われる可能性がある。 【０１６３】所与のテープ・プログラムの実行中に、実
行の履歴の中で以前に現れたスクリプト規則を削除しよ
うと思うことがある、つまり、このスクリプト規則に対
するスクリプト・インスタンスが存在するのである。ま
たは、その履歴が再び再生されれば、利用者は、そのス
クリプト規則の出現または他のスクリプト規則の異なる
仕方での出現を禁止したり、そのきっかけを作ったりす
ることになるような方法でスクリプト規則やアクタを編
集する可能性もある。この種の矛盾は、前記のように手
に終えない結果を招く可能性がある。実行の履歴を築く
ために既に使用された規則の編集には、その履歴の再構
築を必要とする可能性がある。修正された規則の集合を
用いては、アクタ・システムの現在の状態を回復できな
いこともある。この場合、テープ・プログラムの実行を
巻き戻し、そのアクタ・システムの匹敵する状態が回復
可能かどうかを検査するために古い履歴を再実行するこ
とが推奨される。 【０１６４】ＭＯＶＯＮ アクタのデータ空間および履歴：実現の実際性のために
、アクタに対して維持される履歴は、データ空間の変化
の測度（ｍｅａｓｕｒｅ）に基づく。 Ｄ（Ａ，ｔ） ｍＤＳ（Ａ，ｔ） ｄＤ（Ａ，ｔ１，ｔ２） ｄｍＤＳ（Ａ，ｔ１，ｔ２）
が、それぞれ時刻ｔにおけるアクタＡのデータ空間（Ｄ
）、時刻ｔにおけるこのデータ空間の測度（ｍＤＳの値
は数である）、時刻ｔ１およびｔ２の間のＡのデータ空
間における差（ｄＤ）、および時刻ｔ１およびｔ２の間
のアクタＡに対するデータ空間の変化の測度（ｄｍＤＳ
，数）である。ここで、アクタＡの履歴は、アクタＡの
データ空間に対する相当な変化の有限集合として定義す
ることができる。例えば、アクタＡの初期のデータ空間
： Ｄ（Ａ，ｔ０） が分かると、アクタＡに対し粒状性（ｅ）を有するサイ
ズｎの有限履歴は、 Ｈｅ（Ａ）＝｛（ｔｉ，ｄＤ（Ａ，ｔｉ，ｔｉ−１））
｜ｄｍＤＳ（Ａ，ｔｉ，ｔｉ−１）＞＝ｅ｝ １＝＜
ｉ＝＜ｎ として定義される。さらに、 Ｔ（Ｈｅ（Ａ））＝｛ｔｉ｝ １＝＜ｉ＝＜ｎは、Ａ
の履歴からのタイム・スタンプの集合を表す。つぎに、 Ｄ（Ａ，ｔｊ）＝Ｄ（Ａ，ｔ０）＋｛＋ｄＤ（Ａ，ｔｉ
，ｔｉ−１）｝ １＝＜ｉ＝＜ｊを用いて、Ａの中間
的なデータ空間が得られる。また、次のようなアクタＡ
に対するデータ空間の変化の空間効率的な記述を用いて
、アクタの履歴のモデルを洗練することが可能である。 【数３】 Ｈｅ，ｇ（ａ）により、粒状性ｅおよび効率ｇを有する
アクタ履歴のモデルが定義される。従って、時刻ｔにお
けるＡの中間的なデータ空間をＡの履歴から以下を用い
て導くことができる。 【数４】 アクタＡは、その初期のデータ空間およびデータ空間の
履歴が分かる時間の階段状の関数であるアクタのデータ
空間記述Ｄ（Ａ，ｔ）によって時刻ｔに完全に明記され
る。アクタの履歴は、そのアクタが変更された時刻とそ
れに対応するそのアクタのデータ空間への変更の記述と
のリストに過ぎない。その形式のアクタ・データ空間の
変化（ｄＤ）によって記述されるのは、新たなスロット
および（若しくは）新たな値の追加、ならびに（または
）新たなスロットおよび（若しくは）新たな値の削除、
ならびに（または）値の変更である。アクタＡのアドレ
スａ（ｔ）は、Ａのデータ空間の特別な要素であり、ア
クタ・システムにおいてＡに特有の識別子を与えるもの
である。 【０１６５】アクタ・システムにおける可逆性：アクタ
の履歴により、各アクタごとに限られた履歴管理機構が
与えられる。アクタ間の通信システムでは、アクタのデ
ータ空間は、そのアクタが伝達情報を送信したり処理し
たりするときに、変更できるに過ぎない。さらに、伝達
情報の送信および処理は、最小単位の処理である。従っ
て、アクタ・システムにおける各変更の範囲は、各通信
について完全に明記されるため、すべてのアクタのデー
タ空間の測度が固定値で制限されているという仮定の下
で、すべてのアクタの履歴を線形時間で維持することが
可能である。このモデルにより、維持されるアクタの履
歴の大きさを限度内で完全に可逆性の処理がサポートさ
れる。このモデルのコンピュータ処理に関する重要な利
点は、処理歴のアクタ間の分散であり、これによって、
分散アクタ・システムにおいて可逆的なコンピュータ処
理がサポートされる。 【０１６６】アクタ環境：アクタによるＧＲＡＳの実施
においては、時刻ｔにおけるアクタＡのデータ空間Ｄ（
Ａ，ｔ）を表すためにｌｅｔ環境を使用する。 （ｌｅｔ ａ１＝ｖ１，．．．，ａｎ＝ｖｎ；．．．）
ここで、ａｉはＡのスロットの記号的表現、ｖｉはそれ
に対応する値またはその値を表す表現、そしてｎは時刻
ｔにおけるスロットの総数であり、さらに「＝」記号は
値の割当を表す。時刻ｔにおけるＡのデータ空間の測度
は、ｍＤＳ（Ａ，ｔ）＝ｎであり、使用される履歴の定
義は、Ｈ１（Ａ）（ｅ＝１）である。アクタの環境によ
って、時刻ｔのそのアクタが完全に記述される。アクタ
の作用の記述は、そのアクタの環境と、そのアクタが演
ずるテープから利用できる作用とから全体的に引き出す
ことができる。 【０１６７】アクタの関係および接続：アクタは、双方
向性リンクによるフレーム表現を用いる関係として実現
される静的または動的な従属関係にも関与する。静的な
従属関係には、クラス・メンバーシップ（ＡＫＯ）、成
分メンバーシップ（ＣＯＭＰＯＮＥＮＴまたはＰＡＲＴ
−ＯＦ）、接続、テープ・メンバーシップおよびその他
が含まれる。動的な従属関係には、アクタ間の接続（例
えば、データ通信のための回線接続）が含まれる。なお
、応用分野に適合するようにアクタ間に新しい型の関係
を定義することもできる。新たな関係を表し作るために
属性として視覚表現の参照を利用することができる。 各種の関係に（グラフィックスの組み合わせによる）視
覚的な表現を（オプションで）与えるために、グラフィ
ックスの原形の有限集合が使用される。関係属性は、他
のアクタとの関係を定義するために使用されるアクタの
属性の集合である。例えばＣＯＭＰＯＮＥＮＴ（成分）
関係であるが、この場合、アクタの分解が、成分および
下位成分によって与えられる。各成分は、１つのアクタ
であり、従って、他のアクタと通信することができるが
、成分は、それを所有するアクタの物理的な部分でもあ
る（例えば、スピーカーと押しボタンを有する電話機）
。 【０１６８】ＶＳＭの関数 ＧＲＡＳシステムは、ＶＳＭモジュールによって利用者
の水準で実現される。ＶＳＭモジュールは、利用者の要
求を果たすためにさらに低い水準のモジュールを要求す
るユーザ・レベルの関数から成る。 【０１６９】特殊効果：作用の規則を洗練するために、
録音の最中かその後で特殊効果のソフトウェア・モジュ
ールを利用することができる。例えば、スクリプト規則
において、アクタ、事前条件、事後条件、転送されたメ
ッセージおよびデータを修正することができる。トラッ
キング装置の入力およびメニューの選択によって、その
変更結果が与えられる。一般スクリプトに対するアクタ
対の集合を定義するオーディション表現を生成するため
に特性の対話的な指定（例えば、属性の値に関するパタ
ン照合表現）を含む一般規則（Ｇｅｎｅｒａｌ Ｓｃｒ
ｉｐｔ）を洗練するために、さらに特殊効果を利用する
ことができる。 【０１７０】図６は、テープ生成（ＣＲＥＡＴＥ ＴＡ
ＰＥ）関数の流れ図である。テープ・生成関数は、ＭＯ
ＶＯＮにテープ・ビジュアル・オブジェクトを要求する
（作用ブロック６０１）。次に、ＭＯＶＯＮは、指名さ
れた新たなテープにフレーム構造体を割り当てる（作用
ブロック６０２）。ＭＯＶＯＮは、ロードされたテープ
のフレームにそのフレーム構造体をリンクする（作用ブ
ロック６０４）。そのフレームを環境に存在するビデオ
・モニタ（ｖｉｅｗ）のフレームにリンクすることによ
り、その新たなテープを現在のテープとする（作用ブロ
ック６０６）。新たなテープは、ソフトコーダにロード
（ＬＯＡＤ ＴＡＰＥ参照）され（作用ブロック６０８
）、未来のリールと過去のリールにリンクされ、シミュ
レーション・カウンタが内部的に設定される。ＭＯＶＯ
Ｎにより、新たなテープが表示され（作用ブロック６１
０）、ビデオ・モニタの再表示が行われる。 【０１７１】図７は、テープ・ロード関数（ＬＯＡＤ
ＴＡＰＥ）の流れ図である。ロード・テープ関数により
テープがロードされることになる（作用ブロック７０２
）。テープの過去のリールおよび未来のリールが、ソフ
トコーダの過去のリール要素および未来のリール要素に
リンクされ、スクリプトのインスタンスおよび規則がソ
フトコーダに組み込まれることになる（作用ブロック７
０４）。テープ・カウンタの値を用いて、シミュレーシ
ョン・カウンタが設定される。ＭＯＶＯＮにより、その
テープから既存のアクタがビデオ・モニタの適切な表示
部位に表示される（作用ブロック７０６）。ソフトコー
ダは、初期シミュレーション・モード、動画の速度およ
び詳細水準を随意選択するために、予備的な評価を行う
（作用ブロック７０８）。再生（ＰＬＡＹ）関数（後述
）が呼び出され（作用ブロック７１０）、ＭＯＶＯＮに
より、実行可能なスクリプトの最初の集合からアクタが
それらに関係付けられたｖｉｅｗ（スクリプト・タッグ
による）にリンクされ、アクタ、適切なｖｉｅｗにおい
て交わされるメッセージおよびデータが表示される（作
用ブロック７１２）。 【０１７２】図８は、テープ・コピー関数（ＣＯＰＹ
ＴＡＰＥ）の流れ図である。まず、コピー・テープ関数
は、コピーが取られるべき元となるテープを要求し（デ
フォルトにより現在のテープがロードされる）、次に元
のテープをコピーする先のテープを要求する（作用ブロ
ック８０２）。コピー先のテープが既に存在し（判断８
０４）、かつこのテープを再利用することになった（判
断８０６）場合、元のテープのフレーム構造体が、先の
テープのフレーム構造体へと（再利用を伴う）合併され
る（作用ブロック８０８）。先にテープが存在しなけれ
ば、新たなフレーム構造体が割り当てられ（作用ブロッ
ク８１０）、そのフレームが、ロードされたテープのフ
レームにリンクされ（作用ブロック８１２）、元のテー
プのフレーム構造体が新たなコピー先の構造体へと合併
される（作用ブロック８０８）。 【０１７３】図９は、テープ削除関数（ＲＥＭＯＶＥ
ＴＡＰＥ）の流れ図である。テープ削除関数は、取り除
くべきテープを決定し（作用ブロック９０２）、そのテ
ープと共にアクタも削除するべきかどうかを判断する（
作用ブロック９０４）。ＭＯＶＯＮは、そのテープのフ
レーム構造体をロードされたテープのフレームから切り
離す（作用ブロック９０６）。テープと共にアクタも削
除するべき場合（作用ブロック９０８）、この関数は、
そのテープ中で使用され、かつ他のロードされたテープ
においては使用されないアクタをすべて取り除く（削除
する）（作用ブロック９１０）。一方、アクタはテープ
と共に削除すべきでない場合、そのテープで使用され他
のロードされたテープでも使用されるアクタは切り離す
が、他のロードされたテープへのリンクは維持する（作
用ブロック９１２）。次に、そのテープのフレーム構造
体を削除し（作用ブロック９１４）、他のフレームへの
そのリンクをすべて消去する。 【０１７４】図１０は、テープ・ファイル貸出関数（Ｒ
ＥＮＴ ＴＡＰＥ ＦＩＬＥ）の流れ図である。テープ
・ファイル貸出関数は、テープ・ファイル・フォーマッ
トおよびそのテープ・ファイルへのパスを要求する（作
用ブロック１００２）。そのファイルに格納されている
テープの数が決められる（作用ブロック１００４）。各
テープに対しテープ生成関数が呼び出される（作用ブロ
ック１００６）。ＭＯＶＯＮが、テープがファイルから
生成されるのに必要とされるアクタの生成または（再利
用を伴う）合併を行う（作用ブロック１００８）。ＭＯ
ＶＯＮは、それらのテープによって必要とされる各ビュ
ーに対しビデオ・モニタを生成し、テープ・ファイルか
らのリンク情報によってアクタをビューにリンクする（
作用ブロック１０１０）。次に、ソフトコーダが、テー
プ・ファイルから読み出されたスクリプト構造体に従っ
て、各テープを生成しリンクする（作用ブロック１０１
２）。 【０１７５】図１１は、アクタ生成関数（ＣＲＥＡＴ
ＡＣＴＯＲ）の流れ図である。アクタ生成関数は、生成
されるべきアクタの識別情報を要求する（作用ブロック
１１０２）。ＭＯＶＯＮが、アクタのフレーム構造体を
割り当て、最小の内部属性およびグラフィカルな属性を
備えるように、その構造体を初期化する（作用ブロック
１１０４）。次にＭＯＶＯＮは、そのアクタ・フレーム
構造体を現在のテープ（作用ブロック１１０６）および
現在のビュー（作用ブロック１１０８）にリンクする。 ＭＯＶＯＮは、次に、そのアクタが生成された現在のビ
ューと同じビューをサポートするすべてのビデオ・モニ
タに、そのアクタを表示する（作用ブロック１１１０）
。 【０１７６】図１２は、アクタ選択関数（ＳＥＬＥＣＴ
ＡＣＴＯＲ）の流れ図である。このアクタ選択関数は
、アクタ選択の型を要求する（作用ブロック１２０１）
。新たなオブジェクトが選択される場合（判断１２０２
）、アクタ生成関数が使用される（作用ブロック１２０
４）。すべてのオブジェクトが選択される場合（判断１
２０２）、ＭＯＶＯＮは、ロードされた全アクタ（バッ
クステージ・アクタ）を現在のビューにリンクし、それ
らを対応するビデオ・モニタに表示する（作用ブロック
１２０６）。アクタの選択にキーワード探索を用いる場
合、キーワードを入力するように利用者を促す（作用ブ
ロック１２０８）。一致するアクタが見つからない場合
（判断１２１０）、新たな選択が必要になる（作用ブロ
ック１２０２）。一致するアクタが見つかった場合、特
定のアクタが要求され（作用ブロック１２１４）、（１
つでもある場合）そのアクタが、現在のビューにリンク
されて表示される（作用ブロック１２１６）。 【０１７７】図１３は、アイコン状態設定関数（ＳＥＴ
ＡＣＯＮ ＳＴＡＴＥ）の流れ図である。この関数は
、実行された直後のスクリプト・インスタンスの集合の
中の１つのスクリプトを要求する（作用ブロック１３０
２）。つぎに、そのスクリプトからセンダのアクタまた
はレシーバのアクタを要求する（作用ブロック１３０４
）。ＭＯＶＯＮが、前記のアクタによって使用される現
在のアイコン決定し、このアイコンに対する可能なアイ
コン状態の集合をアイコン・ライブラリから検索する（
作用ブロック１３０６）。次にアイコン状態設定関数が
、可能なアイコン状態の集合の中から１つのアイコン状
態を要求する（作用ブロック１３０８）。そのスクリプ
ト集合について、ソフトコーダのアンドゥ関数が呼び出
される（作用ブロック１３１０）。ソフトコーダは、選
ばれたスクリプトの事後条件リストにおけるアクタの状
態を変更するために、条件表現を追加する（作用ブロッ
ク１３１２）。ソフトコーダの再生関数が呼び出され、
ＭＯＶＯＮが、アクタへの対応する変更を変更されたス
クリプト定義の実行結果として表示する（作用ブロック
１３１４）。 【０１７８】図１４は、アクタ接続関数（ＣＯＮＮＥＣ
Ｔ ＡＣＴＯＲＳ）の流れ図である。アクタ接続関数は
、実行直後のスクリプトの集合の中の１つのスクリプト
（作用ブロック１４０２）と接続の型（記号的名称）と
を要求する（作用ブロック１４０４）。その接続の型に
対応するグラフィック表現（例えば、単線、２重線、会
議線）が決定される（作用ブロック１４０６）。接続す
るアクタ数が要求される（作用ブロック１４０８）。接
続するアクタが要求される（作用ブロック１４１０）。 ソフトコーダのアンドゥ関数が呼び出される（作用ブロ
ック１４１２）。「ＣＯＮＮＥＣＴ｛接続型｝［選択さ
れたアクタのリスト］」という形式の条件が選択された
スクリプトの事後条件リストに加えられる（作用ブロッ
ク１４１４）。ソフトコーダの再生（ＰＬＡＹ）関数が
呼び出され（作用ブロック１４１６）、変更されたスク
リプトの実行結果として、選択されたアクタ間の接続が
、生成されて、適切なビューに表示される。 【０１７９】図１５は、アクタ視覚化関数（ＭＡＫＥ
ＡＣＴＯＲＳ ＶＩＳＩＢＬＥ）の流れ図である。この
関数は、実行直後のスクリプトの集合のうちの１つのス
クリプトを要求する（作用ブロック１５０２）。視覚化
するべきアクタが要求される（作用ブロック１５０４）
。ソフトコーダのアンドゥ関数が呼び出される（作用ブ
ロック１５０６）。 選択されたスクリプトの事後条件リストに「ＶＩＳＩＢ
ＬＥ［選択されたアクタのリスト］」という形式の条件
を追加する（作用ブロック１５０８）。ソフトコーダの
再生関数が呼び出され（作用ブロック１５１０）、その
変更されたスクリプトの実行結果として、前記のアクタ
が視覚化され（るか、または恐らくは生成された上で視
覚化され）て、適切な表示部位に表示される。 【０１８０】図１６は、アクタ状態の設定関数（ＳＥＴ
ＳＴＡＴＥ ＯＦ ＡＣＴＯＲ）の流れ図である。ア
クタ状態設定関数は、実行直後のスクリプト・インスタ
ンスの集合の中からスクリプトを１つ要求する（作用ブ
ロック１６０２）。つぎに、そのスクリプトからセンダ
またはレシーバのアクタを要求する（作用ブロック１６
０４）。ＭＯＶＯＮが、スロット名が要求される前記の
アクタから現在のスロットの集合を決定する（作用ブロ
ック１６０６）。このスロットは、そのアクタの状態を
変更するために使用される。そのスロットに対する新た
な値が決定される（作用ブロック１６０８）。そのスク
リプト集合にソフトコーダのアンドゥ関数が呼び出され
る（作用ブロック１６１０）。ソフトコーダは、そのア
クタのスロットを新たな値に変更するために、選択され
たスクリプトの事後条件リストにおいて条件表現を追加
する（作用ブロック１６１２）。その追加される条件は
、「ＳＥＴ｛スロット名｝｛スロット値｝」と言う形式
のものである。ソフトコーダの再生関数が呼び出され、
ＭＯＶＯＮが、そのアクタに対応する変化を変更された
スクリプト定義の実行結果として表示する（作用ブロッ
ク１６１６）。 【０１８１】図１７は、メッセージ経由のデータ渡し関
数（ＰＡＳＳ ＤＡＴＡ ＶＩＡ ＭＥＳＳＡＧＥ）の
流れ図である。メッセージ経由のデータ渡し関数は、実
行直後のスクリプトの集合からスクリプトを要求する（
作用ブロック１７０２）。次に、前記のスクリプトのセ
ンダのアクタからのスロット名が要求される（作用ブロ
ック１７０４）。このスロット［ｓｌｏｔ−ｆｒｏｍ］
が、もう一方のアクタに送られるべきデータとして使用
される。レシーバのアクタからのスロット［ｓｌｏｔ−
ｔｏ］の名前が要求される（作用ブロック１７０６）。 そして、ソフトコーダのアンドゥ関数が呼び出される（
作用ブロック１７０８）。センダのアクタのスロット値
がそのメッセージを介して渡されること、およびそれが
受信されたときのシンボル名が｛ｓｌｏｔ−ｆｒｏｍ｝
であることを示す「｛ｓｌｏｔ−ｆｒｏｍ｝｛ｓｌｏｔ
−ｆｒｏｍ−ｖａｌｕｅｓ｝」という書式が、選択され
たスクリプトのメッセージ表現に追加される（作用ブロ
ック１７０８）。 「ＳＥＴ｛ｓｌｏｔ−ｔｏ｝｛ｓｌｏｔ−ｆｒｏｍ｝」
という形式の条件が、選択されたスクリプトに対しレシ
ーバのアクタの事後条件リストに追加される（作用ブロ
ック１７１０）。 ソフトコーダの再生関数が呼び出され（作用ブロック１
７１２）、変更されたスクリプトの実行結果として、セ
ンダのアクタからのスロットの値が、レシーバのアクタ
の［ｓｌｏｔ−ｔｏ］の値を更新するために渡されて、
適切な表示部位に表示される。 【０１８２】図１８は、クローン・アクタ関数（ＣＬＯ
ＮＥ ＡＣＴＯＲ）の流れ図である。クローン・アクタ
関数は、コピーされるべきアクタを要求する（作用ブロ
ック１８０２）。ＭＯＶＯＮが、そのアクタに対するフ
レーム構造体を割り当てる（作用ブロック１８０４）。 ＭＯＶＯＮは、コピーされるアクタに対するアドレスを
、基となるアクタの名前とそのアドレスを唯一のものと
するコピー番号とを用いて生成する（作用ブロック１８
０６）。ＭＯＶＯＮは、新たなアクタを現在のｖｉｅｗ
にリンクし、コピーされたアクタを同じｖｉｅｗを有す
るすべてのビデオ・モニタに表示する（作用ブロック１
８０８）。 【０１８３】図１９は、アクタ合併関数（ＭＥＲＧＥ
ＡＣＴＯＲ）の流れ図である。アクタ合併関数は、他の
アクタ｛ａｃｔ−ｔｏ｝へと合併されるべきアクタ｛ａ
ｃｔ−ｆｒｏｍ｝を要求する（作用ブロック１９０２）
。ＭＯＶＯＮが、それらのアクタ・フレーム構造体を合
併する（作用ブロック１９０４）。ソフトコーダが、ａ
ｃｔ−ｆｒｏｍのアドレスへの参照をすべてａｃｔ−ｔ
ｏへのアドレスで置き換える。（作用ブロック１９０６
）。 【０１８４】図２０は、チャネル設定関数（ＳＥＴ Ｃ
ＨＡＮＮＥＬ）の流れ図である。チャネル設定関数は、
そのチャネルを変更するビデオ・モニタを要求し（作用
ブロック２００２）、さらにチャネルの選択を要求する
（作用ブロック２００４）。選択されたチャネルが「全
チャネル」の場合（判断２００６）、ソフトコーダが、
デフォルトのスクリプト構造体のタグ（名前）をそのビ
デオ・モニタにおける「Ｓｉｄ」に設定し（作用ブロッ
ク２００８）、さらにＭＯＶＯＮが、そのチャネルの指
定を空にしたまま、そのビデオ・モニタを表示する（作
用ブロック２０１０）。選択されたチャネルが「新たな
チャネル」の場合、それに対応するスクリプト構造体の
タグが決定される（作用ブロック２０１２）。次に、ソ
フトコーダは、デフォルトのタグをビデオ・モニタにお
ける要求されたタグに設定する（作用ブロック２０１４
）。次に、ＭＯＶＯＮが、ビデオ・モニタを表示し、そ
の表示にチャネル・タグを示す（作用ブロック２０１６
）。このビデオ・モニタにおいて記録する場合、そのタ
グは、そのビデオ・モニタのｖｉｅｗとこのｖｉｅｗに
おいて生成されたスクリプト構造体の集合との間の相互
参照の役に立つ。 【０１８５】図２１は、変換テーブル関数（ＴＲＡＮＳ
ＬＡＴＩＯＮ ＴＡＢＬＥ）の流れ図である。テーブル
操作に対する要求がＶＳＭを介して利用者に送られる（
作用ブロック２１０２）。同時に発生するスクリプトの
現在のグループの中から１つのスクリプトを求める要求
が送られる（作用ブロック２１０４）。センダのアクタ
が、レシーバのアクタと同一でない場合（判断２１０６
）、ＶＳＭを介してエラー・メッセージが表示されて（
作用ブロック２１０７）、この関数は終了する。その他
の場合は、スクリプトによって、アクタ（センダ＝レシ
ーバ）に対し内部で処理する仕事が記述され、変換テー
ブルを生成または編集することができる（判断２１０８
）。（判断２１０８において）スクリプト中に変換テー
ブルの表現が全く存在しない場合、新たな変換テーブル
の生成が必要となる。この場合、変換テーブルへの入り
口スロットとして使用するためのアクタの状態（スロッ
ト１）が選択され（作用ブロック２１１０）、さらに変
換テーブルによって変換された値の結果を格納するため
のアクタの状態（スロット２）が選択される（作用ブロ
ック２１１２）。データ変換のための値のリストが要求
される（作用ブロック２１１４）。変換テーブルが割り
当てられ、（新たな）変換表現が選択されたスクリプト
に挿入される（作用ブロック２１１６）。（判断２１０
８において）変換テーブルの編集作用が選択され、さら
に（判断２１０９において）スクリプト中に変換テーブ
ルの表現が存在しない場合、エラー・メッセージが表示
されて（作用ブロック２１１１）、この変換関数は終了
する。 （判断２１０８において）変換テーブルの編集作用が選
択され、（判断２１０９において）スクリプトに変換テ
ーブルの表現が存在する場合、ＭＯＶＯＮによってＶＳ
Ｍを介して変換テーブルが編集可能な形式で表示され、
利用者によって編集される（作用ブロック２１１３）。 次に、ソフトコーダが、修正された変換テーブル表現を
含むように、スクリプトの事後条件リストを変更する（
作用ブロック２１１５）。変換テーブル表現は、「ｓｅ
ｔ ｓｌｏｔ−２（ｓｅｌｅｃｔ ｓｌｏｔ−１）｛（
ｅｎｔｒｙ，値の表現）の対のリスト｝」という形式で
ある（作用ブロック２１１７）。 【０１８６】ビデオ・モニタは、アクタ間の一組の処理
を表示したり、テープへと視覚的に記録するために使用
される。ビデオ・モニタは、シミュレーションまたは生
成されているシステムの単純化した描画を表示または記
録することができる。ビデオ・モニタは、再生の特定の
部分のズーム・イン（拡大）およびズーム・アウト（縮
小）を行う機構を与えるために、表示部位の間の切り替
えに使用されるチャネル制御と詳細水準の制御とを備え
ている。記録モードでは、チャネル制御変更は画面上で
異なる視点または視野を得るためのカメラの変更に相当
し、詳細水準の変更は、そのカメラへのズーム・イン／
ズーム・アウト制御に相当する。ビデオ・モニタは、設
定および変更を動的に行うことができる種々の特性を持
っている。例えば、利用者は、ビデオ・チャネルを設定
することができる。モニタのチャネルを変更することに
より、それに表示される表示部位が変化する。大きさ、
色（カラーの場合）、表題、アニメーションの水準およ
び速さ、メモリの大きさ（即ち、モニタ上に一度にいく
つのイベントを思い出すことができるかという持続性）
、静的な表示と動的な表示、表示される詳細の解像度ま
たは水準、およびデフォルトのメッセージ名の位置（セ
ンダおよびレシーバのアクタに関するメッセージ表示の
デフォルトの位置が変えられる）などの特性は、すべて
利用者がビデオ・モニタからメニューまたはアイコンに
よって選択することが可能である。 【０１８７】ビデオ・モニタは、テープの再生、活性化
、または表示、処理のためのステージの記録または設定
に使用することが可能である。ＶＳＭインタフェースに
よって、テープの生成、編集、表示、および実行に対す
る直接的な制御が与えられる。新たな指示の入力を記録
することによって、実行中に変更を取り入れることがで
きる。記録または再生の間に、テープの詳細水準を（例
えば、スライド・バーを用いて）変化させて、高い詳細
水準の表示の間にズーム効果を与えることができる。ビ
デオ・モニタは、「再生（ｐｌａｙ）」モードで活動さ
せられているイベントおよび特殊効果を変更するための
描画／編集板として役立つ。ビデオ・モニタは、同時に
何百ものオブジェクトを表示することができるが、通常
は、２０乃至３０以下のオブジェクトが、標準的なグラ
フィックス表示技術に基づいた良好な視覚的図式の目安
である。１つのテープで３０以上のオブジェクトが必要
な場合は、特殊効果を使用することができる。特殊効果
によって、個々の視覚的な対象の表示／非表示が自在に
可能である。 【０１８８】ＧＲＡＳのビデオ・モニタは、多数のビュ
ーポイントを用いて実現される。設計の使用には大きな
ものもあるので、利用者から不要な情報を隠すために射
影（多重表示）がサポートされている。ＧＲＡＳシステ
ムは、同時の記録およびアニメーションを多重表示でサ
ポートする。各ビデオ・モニタが、記録およびアニメー
ションに使用されるビデオ・チャネルと抽象（要約）水
準とを持っている。ウィンドウとグラフィックスをサポ
ートし、さらに視覚的なオブジェクトのみならずビデオ
・モニタも実現するために、目標とするコンピュータ・
システム（例えば、ＳｕｎＶｉｅｗＴＭ、Ｘ Ｗｉｎｄ
ｏｗ ＳｙｓｔｅｍＴＭ、ＯＰＥＮ ＬＯＯＫＴＭ、Ｓ
ｙｍｂｏｌｉｃｓ Ｗｉｎｄｏｗｓ、ＸｅｒｏｘＷｉｎ
ｄｏｗｓ）によって専用のウィンドウおよびグラフィッ
クスのシステムが使用される。ＳｕｎＶｉｅｗはサン・
マイクロシステムズ（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍ
ｓ）の商標であり、Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍは
ＭＩＴの商標であり、ＯＰＥＮ ＬＯＯＫはＡＴ＆Ｔの
商標である。 【０１８９】多重ビューポイントの特徴の応用により、
要約表示と詳細な表示との間にズーム操作が提供される
。例えば、提出された表示内容の利用者ならば、高水準
の要約表示を見ることになり、表示内容の開発者であれ
ば、内部の交換構造を示す詳細な表示を見るであろう。 ２つの表示を「ハードウェア」の動作と「ソフトウェア
」の動作とを分離するために使用しても良い。 【０１９０】ＧＲＡＳウィンドウなどの使用により、ウ
ィンドウの使用が高められる。例えば、ＳｕｎＷｉｅｗ
下のＳｕｎワークステーションは、ウィンドウを６４ま
で持つことができる。Ｓｕｎ上のＧＲＡＳは、ＶＳＭ／
ＧＲＡＳアプリケーションと同時に実行中の他のＳｕｎ
Ｗｉｅｗの（メール、テキスト編集、およびその他の）
アプリケーションによって残りのウィンドウを使用しな
がらでも、１０以上のビデオ・モニタ・ウィンドウを使
用することができる。 【０１９１】Ｌｉｓｐが動作する機械であれば、数百の
ウィンドウを持つことも可能である（この数はディスク
の容量によってのみ制限される）。Ｌｉｓｐ機上のＶＳ
Ｍ／ＧＲＡＳは、（例えば、多重表示のように）希望の
数だけビデオ・モニタを持つことができる。この概念は
、同じシナリオや異なるシナリオの実行のいくつかの異
なる表示を与える異なるチャネルに調節されたいくつか
のテレビ・モニタを持つことに似ている。 【０１９２】編集ルーム（Ｅｄｉｔｉｎｇ Ｒｏｏｍ）
によって、テープ・シェルフのテープ、およびビデオ・
テープまたはフィルムの編集の類似性を用いてテープを
編集・操作するために使用される作用素の集合に直接ア
クセスすることができる。そして、テープを編集を行う
ことが、プログラムの操作に対する唯一の手段である。 アクタおよびアクタ環境の実現、ならびにアクタ間の通
信過程におけるアクタの使用によって与えられる実行状
況の結末に基づいて、各スクリプト構造体は、ソフトコ
ーダの仮想機械によって実行される独立した単位処理と
して扱うことが可能であり、基本的なプログラム要素と
して操作することができる。テープ・プログラムには、
スクリプト構造体の閉集合が常にある。２つのテープを
接着することにより、おそらく両方のテープからさらに
機能性が得られることになり、これによって、ＧＲＡＳ
の背景において機能的統合が半自動化の可能な処理とな
る。テープを２つのサブテープに切断することも可能で
あるが、両方のサブテープが完結し、一貫性が維持され
る位置でテープを切断する必要があるので、いっそう注
意が必要となる。テープの切断および接着により、別個
の作業努力による機能性を結合する簡単な機構が与えら
れる。このことは、アクタどうしを合併できることと結
びついて、プログラム・システムにおける新たな特徴の
連続的な統合に取り組む強力な骨組みを提供する。 【０１９３】ソフトコーダ（ＳｏｆｔＣｏｄｅｒ）ＧＲ
ＡＳのソフトコーダは、テープ・プログラムのスクリプ
ト規則（Ｓｃｒｉｐｔ Ｒｕｌｅ）と一般スクリプト（
Ｇｅｎｅｒａｌ Ｓｃｒｉｐｔ）からなる未来のリール
、およびテープ・プログラムの実行履歴をたどるアンド
ゥ可能なスクリプトの集合からなる過去のリールを備え
ている。過去のリールでは、すべてのスクリプト・イン
スタンスが、逆向きの実行が可能である。つまり、すべ
てのスクリプト・インスタンスに、Ｓｕｎｄｏ表現とＲ
ｕｎｄｏ表現がある。過去のリールには、実行の履歴と
その実行中に入力されたデータが入っているので、試験
用のシナリオとして使用することができる。 【０１９４】図２９は、ソフトコーダの視覚的な表現で
ある。テープは、記録されたスクリプト規則と一般スク
リプトの集合であり、過去のリール２９１０は、シミュ
レーション中の現在時刻以前にシミュレータによって選
択され発動されたスクリプト・インスタンスに相当し、
未来のリール２９２０には、残りの規則か、またはシミ
ュレーションの生成モードにある完全なテープ・プログ
ラムの何れかが入っている。各リールは、時計回りに回
転し、シミュレーション中は、一度に１ステップ以上前
進する。固定の（再生）ヘッド２９３０によって、スク
リプト規則と一般規則の集合を読んで実行する。アンド
ゥ・ヘッド２９５０により、スクリプト・インスタンス
にアンドゥを行う情報で印を付ける。記録ヘッド２９４
０は、新たな規則の記録および挿入を行うために何時で
も利用することができる。先取りヘッド２９６０は、シ
ミュレーションにおいて次に発動するべき規則の集合を
捜すのに使用される。 【０１９５】ソフトコーダは、次の制御を有する「制御
パネル」を備えている。自動再生：テープ・プログラム
を現在の位置から最後まで（停止位置まで）選択された
アニメーション速度で自動的に再生する。図２２は、自
動再生制御関数（ＡＵＴＯＰＬＡＹ）の流れ図である。 自動再生関数は、テープ・プログラムの最後に到達する
か、または自動再生の開始後に停止関数が呼び出される
まで（判断２２０４）、再生関数を繰り返し呼び出す（
作用ブロック２２０２）。 【０１９６】再生：現在発動可能な動作の規則の集合を
実行することによって一度に１ステップ（１フレーム）
だけテープの再生を行う。図２３は、再生制御関数（Ｐ
ＬＡＹ）流れ図である。再生関数は、再生の背景的条件
を定義する次の変数を確認する（作用ブロック２３０２
）。 即ち、ロードされた現在のテープおよびそのリール（未
来のリールおよび過去のリール）、現在のアニメーショ
ン速度、シミュレーション・モード、アニメーションお
よびシミュレーションの水準である。次に、その再生の
背景的条件において、再生関数は、スクリプト規則と一
般スクリプトの適切な集合を未来のリールから見つける
（作用ブロック２３０３）（このシミュレーション・モ
ードの関数としての動作の次の詳細な説明を参照のこと
）。そのスクリプトの集合が空の場合（判断２３０４）
、テープ・プログラムの最後に達したことが利用者に知
らされて（作用ブロック２３０５）、再生関数が終了す
る。さらにスクリプトが利用できる場合（作用ブロック
２３０６）、テープ・プログラムの実行の他の変形が可
能であることが利用者に知らされて（作用ブロック２３
０７）、再生関数が終了する。スクリプトの適切な集合
が空でない場合（判断２３０４）、そのスクリプトが再
生され（作用ブロック２３１０）（次の詳細な説明を参
照のこと）、アニメーション速度によりシミュレータを
待たせる必要がある場合（判断２３０８）、スクリプト
の再生の前に時間的遅延が導入され（作用ブロック２３
０９）、それから再生関数を終える。 【０１９７】記録：新たな通信を記録し、それを自動的
に現在のテープ位置に挿入する。図２４は、記録関数（
ＲＥＣＯＲＤ）の流れ図である。記録関数は、記録の背
景条件を定義する次の変数をまず確認する（作用ブロッ
ク２４０２）。即ち、現在のテープ・プログラム、現在
のビューおよびチャネル、現在のアニメーション、シミ
ュレーションおよび記録の水準を確認する。次に、記録
関数は、記録中の新たな通信に対するセンダのアクタを
要求する（作用ブロック２４０３）。センダが指定され
ると（判断２４０５）、そのアクタを（オーディション
処理によって）確認するか、または生成するかする（作
用ブロック２４０６）。センダが指定されなければ、記
録関数は終了させられる。センダのアクタが分かると、
レシーバのアクタを要求する（作用ブロック２４０７）
。レシーバのアクタが指定されると（作用ブロック２４
０８）、それは確認されるかまたは生成される（作用ブ
ロック２４０９）。指定されない場合、記録関数は終了
する。次に、記録関数は、スクリプト規則を選択するよ
うに要求する（作用ブロック２４１０）。スクリプトが
全く指定されない場合（判断２４１１）、この関数は終
了する。指定された場合、スクリプト規則または一般ス
クリプトが生成されが、それがない場合、既存のものか
らクローンが生成させる（作用ブロック２４１２）。新
たなスクリプトがテープ・プログラムの未来のリールに
挿入され（作用ブロック２４１３）、再生関数が呼び出
される（作用ブロック２４１５）。最後の記録関数以来
はじめて停止関数が呼び出された場合（作用ブロック２
４１６）、記録関数は停止するが、そうでなければ、記
録関数は再開する（作用ブロック２４０１）。 【０１９８】停止：現在のテープに対し行っている自動
実行、記録またはアンドゥを終了させる。図２５は、停
止制御関数の流れ図である。停止関数は、割り込みによ
って起動される。即ち、停止ボタンが押されると（判断
２５０２）、停止の事象が待ち行列に加えられる（作用
ブロック２５０３）。前述のように、再生（自動再生）
、記録、およびアンドゥ（自動アンドゥ）の関数も停止
事象の有無を確認する。 【０１９９】カウンタ：テープの開始から実行されたス
テップ数を示す。カウンタは、入力素子でもあり出力素
子でもある。カウンタを特定の位置に設定すると、テー
プをその位置まで自動的に進めたり巻き戻したりする。 図２６は、カウンタ制御関数の流れ図である。カウンタ
関数は、表示か設定かによって２通りに呼び出すことが
できる（判断２６０２）。表示の場合、カウンタ関数は
現在のシミュレーション計数を得て（作用ブロック２６
０４）、カウンタの表示を更新する（作用ブロック２６
０５）。ここで、現在のシミュレーション計数は、現在
のテープ・プログラムの開始以来経過したシミュレーシ
ョン時間単位の数である。カウンタの設定の場合、カウ
ンタ関数は、カウンタ値を要求する（作用ブロック２６
０６）。カウンタ値が現在のシミュレーション計数を越
える場合（作用ブロック２６０７）、所望のカンウタ値
に達するか、停止関数が呼び出されるか、またはテープ
の終わりに達するまで、自動再生関数が呼び出される（
作用ブロック２６０８）。それ以外の場合、所望のカウ
ンタ値に達するまで、自動アンドゥ関数が呼び出される
（作用ブロック２６０９）。 【０２００】アンドゥ：通信の最後の集合（起動された
スクリプト・インスタンスの最後の集合）の影響を取り
消す。最終ステップを巻き戻し、最終グループの処理の
影響を逆にする。図２７に、アンドゥ制御関数（ＵＮＤ
Ｏ）の流れ図を示す。アンドゥ関数は、次の変数からア
ンドゥの背景条件を確認する（作用ブロック２７０２）
。即ち、シミュレーション・モード、シミュレーション
水準、現在のテープ・プログラム（未来のリールおよび
過去のリール）、多重ビューおよびアニメーションの水
準を確認する。次に、アンドゥ関数は、過去のリールか
ら復元されるべきスクリプト・インスタンスの集合を得
る（作用ブロック２７０３）。次に、アンドゥ関数は、
復元されるべきスクリプト・インスタンスの集合に対し
、１）そのスクリプト集合に関与するすべてのアクタの
データ空間をこのスクリプト集合の実行時刻に先立つシ
ミュレーション時刻におけるそれらのデータ空間にまで
戻すとともに、２）そのスクリプト・インスタンスが視
覚的な副作用を有する場合、対応するグラフィックスの
アンドゥ関数を実行する（作用ブロック２７０４）。次
に、アンドゥ関数は、過去のリールから前記のスクリプ
ト・インスタンスを削除し（作用ブロック２７０５）、
現在のシミュレーション計数および現在のスクリプト集
合を更新する（作用ブロック２７０６）。アンドゥ関数
に関する説明は、他に次のシミュレーション・モードの
詳細説明にもある。 【０２０１】自動アンドゥ：テープの始まりか、または
停止ボタンでテープを停止させるまで自動巻き戻しを行
う。また、自動アンドゥは、自動実行の影響を選択され
たアニメーション速度で完全に逆にする。図２８は、自
動アンドゥ関数（ＡＵＴＯＵＮＤＯ）の流れ図である。 自動アンドゥ関数は、過去のリールがなくなるか、また
は停止関数が呼び出されるまで（判断２８０４）、アン
ドゥ関数を繰り返し呼び出す（作用ブロック２８０２）
。 【０２０２】ＵＮＤＯおよびＡＵＴＯＵＮＤＯは、完全
なアンドゥ機構である。再生（およびその視覚的な副作
用）の影響は、何れかの制御を使用している間に完全に
元どうりになる。これにより、デバッグおよび検査に対
する簡単で効果的な手段が与えられる。シナリオを途中
で停止させ、特定の点まで巻き戻し、変更してから、マ
ウスを数回クリックして先を続けることができる。オブ
ジェクトの状態の変化および処理の動的なアニメーショ
ンによって、デバッグまたは検査の間に、または活動し
ている対象を単に見ている間に、視覚的なフィードバッ
クが連続的に与えられる。 【０２０３】仕様の誤りは、シミュレーションの後続部
分が間違っているか、または矛盾することを利用者に警
告する警告メッセージが印字される契機となる。この不
完全性を（一時的に）無視して、設計の他の要素を継続
することは利用者の自由である。シミュレーション・エ
ラーは、誤ったデータ、不正な規則または規則の不正な
組み合わせの何れかによって発生する。利用者は、アン
ドゥや再生を行って仕様に目を通し、間違ったデータま
たは規則の場所を突き止めたのち、それらをその場で編
集し、さらに再生を用いてシミュレーションを継続する
ことができる。 【０２０４】ＶＳＭの範囲内でソフトコーダの仮想機械
を使用することにより、利用者は、その動作の例の中か
らプログラムを指定することが許される。ＶＳＭにおけ
る画像的なシミュレーションは、画像フレームの単純な
列ではなく、「プログラム可能な映画」である。つまり
、利用者の入力データによって、映画の結末は異なった
ものになる。 【０２０５】特定のシナリオの各ステップを順番に実行
すると、そのシナリオ例が新たに再生されるが、その再
生は、入力されたとおり行われるが、前に供給されたア
クタ入力またはその特定のシナリオに関係する他の例の
シナリオ入力がある場合、それによって修正されたとお
りに行われる。その例によって記述される動作は、さら
にアクタのデータを追加したり、模範的なシナリオを追
加することによって、対話的に１つのプログラムへと洗
練することができる。アクタ系の動作は、アクタの状態
の変化に応じて変化し、新たなデータがアクタ間で交わ
される。アクタの状態、実行された処理、および通信中
に交わされる情報に関する他の情報の変更、削除、また
は追加を行うために、アクタおよび動作規則は、何時で
も編集することができる。アクタの状態および画像表現
の変更は、利用者の裁量によって、永久的であるか局部
的であるかの何れかであればよい（可逆的）。結果とし
て得られる規則が、テープ・プログラムを形成する。 【０２０６】ソフトコーダのシミュレーション・モード
テープ・プログラムは、スクリプト規則と一般スクリプ
トの集まりであるが、（部分的な）優先順位を持つ動作
の集まりでもある。テープの全体的な順序化は、テープ
・シナリオの生成をもたらすテープ・プログラムのシミ
ュレーションによって実行時に見られるに過ぎない、ソ
フトコーダは、４つのシミュレーション・モードを有す
る。即ち、（１）連続モード、（２）スマート・モード
、（３）同時モード、（４）生成モードである。 【０２０７】４つのシミュレーション・モードは、同一
のテープを再生する、つまり１つの使用を実行する４つ
の異なる方法に対応する。これらの４つのモードは、進
歩する洗練段階に相当し、それらの段階は、単純に連続
するシナリオから始まり、種々の状況において所与の特
徴（異なるデータ、実行の異なる道筋、エラー処理、同
時性）をシミュレートできる実行可能な規則ベースで終
わる。 【０２０８】連続シミュレーション・モードの視覚的な
表現を図３０に示す。連続シミュレーション・モードで
は、各スクリプト規則および一般スクリプトが、テープ
が本来記録された順序で再生される。固定ヘッド３０３
０は、発動された最後のスクリプト上に常に位置する。 【０２０９】スマート・シミュレーション・モードの視
覚的な表現を図３１に示す。スマート・シミュレーショ
ン・モードでは、各スクリプト規則は、それが現在のテ
ープ・ステージから論理的に実行（発動）されるべきか
どうかを調べるために、実行前に検査される。発動され
得る最初のスクリプト規則が、発動され、テープの未来
のリール３１２０から過去のリール３１１０へと移され
、中間のスクリプト規則は省略される。 【０２１０】同時シミュレーション・モードの視覚表現
を図３２に示す。同時シミュレーション・モードは、ス
マート・シミュレーション・モードの拡張である。この
モードでは、各スクリプト規則は、それが現在のテープ
状態から論理的に発動さ得るかどうかを調べるために、
実行前に検査される。同時に発動可能なスクリプト規則
のグループがあることもしばしばある。このような場合
、同時シミュレーション・モードによって、並列実行を
用いてスクリプト規則を同時に発動することが許される
。 【０２１１】生成シミュレーション・モードは、同時シ
ミュレーション・モードの拡張である。このモードでは
、テープが閉ループに接着され、スクリプト規則および
一般スクリプトのシーケンスを繰り返し発動することが
できる。このモードは、同時発動がある標準的な生成規
則システムに類似している。さらに、この生成モードで
は、時間依存性および完全な可逆的実行がサポートされ
る。繰り返し発動するスクリプト規則の集合によって形
成されるループは、終端条件（例えば、カウンタが所定
の値に達するなど）が満たされるまで実行し続ける。 【０２１２】仮定：ＰＲおよびＦＲが、ソフトコーダに
ロードされた現在のテープ・プログラムの過去および未
来のリールをそれぞれ示すものとする。また、ｆ、ｒ、
ｕ、およびｌａが、ソフトコーダの固定ヘッド、記録ヘ
ッド、Ｕｎｄｏヘッド、および先取り（ｌｏｏｋ−ａｈ
ｅａｄ）ヘッドであるとする。時刻ｔにおいて、 ＰＲ（ｔ）＝（Ｕ１，Ｕ２，．．．，Ｕｎｔ）ＦＲ（ｔ
）＝（Ｒ１，Ｒ２，．．．，Ｒｐｔ）連続シミュレーシ
ョン・モードでは、各スクリプト規則および一般スクリ
プトは、テープが本来記録された順番に再生される。固
定ヘッドは、常に、最後に発動されたスクリプト上に位
置する。 【０２１３】連続モードは、次のように実現される。 １）ＰＲ（ｔ）およびＦＲ（ｔ）は、２つのスタック・
オブジェクトの現在の内容を表す。 ２）次のスクリプト規則を再生するためには：時刻ｔに
おいて、ｆ（ｔ）をＦＲスタックの最も上にある規則Ｒ
１に最初に結合する。規則Ｒ１は、そのアクタおよび視
覚的効果（画像的なアンドゥ・コマンドの集合）に対す
るアンドゥ（回復）表現を生成し記録することにより、
アンドゥを行う準備がなされ、その規則は、アンドゥ可
能型と印が付けられて、ｕ（ｔ）となる。次に、ｆ（ｔ
）＝Ｒ１というメッセージが、センダのアクタからレシ
ーバのアクタへと送られ、ｆ（ｔ）からの事後条件が（
そのアクタの属性をいくつか変更して）実行され、対応
する視覚効果が表示され、ＦＲスタックが一回ポップ（
ｐｏｐ）され、さらにｕ（ｔ）は、それがＵ１となりｔ
が単位時間だけインクリメントされるＰＲスタックへと
プッシュ（ｐｕｓｈ）される。発動可能な規則が見つか
らない場合、再生が停止し、テープ・プログラムの終了
したことが利用者に知らされる。 ３）記録の場合、ｒ（ｔ）は、記録直後の規則を示し、
ＦＲスタックにプッシュされ、次のステップが時刻ｔで
再生される。 ４）アンドゥを１ステップ行う場合、ｕ（ｔ）は、Ｕ１
をアンドゥする次の規則を示す。この規則の事実上の影
響は、オプションのメッセージ表示も含めて、元どうり
にされ、そのアクタのアンドゥ表現は、この規則が発動
される前の初期状態までそれらを復元しながら、実行さ
れる。アンドゥ表現はｕ（ｔ）から削除され、元の型の
規則が復元され、それがｆ（ｔ）となり、ＰＲスタック
が一度ポップされ、さらにｆ（ｔ）は、それがＲ１とな
りｔが単位時間だけデクリメントされるＦＲスタック上
にプッシュされる。 ５）自動再生するには、ＦＲスタックが空になり、他の
規則が記録されていなくなるまで、再生ステップを反復
する。 ６）自動アンドゥをするには、ＰＲスタックが空になる
まで、アンドゥ・ステップを繰り返す。 ７）停止するには、最後の規則の実行またはアンドゥが
完全に行われた後（例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど）、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【０２１４】スマート・シミュレーション・モードでは
、各スクリプト規則は、それが現在のテープ・ステージ
から論理的に実行（発動）されるべきかどうかを調べる
ために、実行前に検査される。発動可能な最初のスクリ
プト規則が、発動され、テープの未来のリールから過去
のリールへと移され、中間のスクリプト規則は省略され
る。 【０２１５】スマート・モードは次のように実現される
。 １）ＰＲ（ｔ）およびＦＲ（ｔ）は、２つのスタック・
オブジェクトの現在の内容を表す。 ２）次のスクリプト規則を再生するためには：時刻ｔに
おいて、ｆ（ｔ）をＦＲスタックの最も上にある規則Ｒ
１に結合する。この規則の事前条件が検査され、条件が
満たされない場合は、ＦＲスタックがポップされ、ｆ（
ｔ）がＰＲにプッシュされ（この規則はアンドゥ可能型
には変更されない）、条件が満たされる場合には、この
規則は、そのアクタおよび視覚的効果（画像的なアンド
ゥ・コマンドの集合）に対するアンドゥ（回復）表現を
生成し記録することにより、アンドゥを行う準備がなさ
れ、その規則は、アンドゥ可能型と印が付けられて、ｕ
（ｔ）となる。次に、ｆ（ｔ）＝Ｒ１というメッセージ
が、センダのアクタからレシーバのアクタへと送られ、
ｆ（ｔ）からの事後条件が（そのアクタの属性をいくつ
か変更して）実行され、対応する視覚効果が表示され、
ＦＲスタックが一回ポップされ、さらにｕ（ｔ）は、そ
れがＵ１となりｔが単位時間だけインクリメントされる
ＰＲスタックへとプッシュされる。発動可能な規則が見
つからない場合、再生が停止し、テープ・プログラムの
終了したことが利用者に知らされる。 ３）記録の場合、ｒ（ｔ）は、記録直後の規則を示し、
ＦＲスタックにプッシュされ、次のステップが時刻ｔで
再生される。 ４）アンドゥを１ステップ行う場合、ｕ（ｔ）は、Ｕ１
をアンドゥする次の規則を示す。Ｕ１がアンドゥ可能型
でない場合、スタックＰＲがポップされ、ｕ（ｔ）がＦ
Ｒ上にプッシュされる。Ｕ１がアンドゥ可能型の場合、
この規則の事実上の影響は、オプションのメッセージ表
示も含めて、元どうりにされ、そのアクタのアンドゥ表
現が実行されて、この規則が発動される前の初期状態に
までそれらを復元する。アンドゥ表現はｕ（ｔ）から削
除され、元の型の規則が復元され、それがｆ（ｔ）とな
り、ＰＲスタックが一度ポップされ、さらにｆ（ｔ）は
、それがＲ１となりｔが単位時間だけデクリメントされ
るＦＲスタック上にプッシュされる。 ５）自動再生するには、利用者の入力が要求されるか、
またはＦＲスタックが空になり、かつ他の規則が記録さ
れていなくなるまで、再生ステップを反復する。 ６）自動アンドゥをするには、ＰＲスタックが空になる
まで、アンドゥ・ステップを繰り返す。 ７）停止するには、最後の規則の実行またはアンドゥが
完全に行われた後（例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど）、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【０２１６】同時シミュレーション・モードは、スマー
ト・シミュレーション・モードの拡張である。このモー
ドでは、各スクリプト規則は、それが現在のテープ状態
から論理的に発動さ得るかどうかを調べるために、実行
前に検査される。同時に発動可能なスクリプト規則のグ
ループがあることもしばしばある。このような場合、同
時シミュレーション・モードによって、並列実行を用い
てスクリプト規則を同時に発動することが許される。 【０２１７】同時モードは次のように実現される。 １）ＰＲ（ｔ）は、スタック・オブジェクトの現在の内
容を表し、ＦＲ（ｔ）は、スタック＝シーケンス・オブ
ジェクトの結合体の内容である。つまり、ＦＲは、プッ
シュおよびポップを行うことができるスタックであると
同時に、ポップ操作もプッシュ操作もない直接アクセス
による探索および修正が可能なシーケンスでもある。 ２）次のスクリプト規則を再生するためには：時刻ｔに
おいて、ｆ（ｔ）をＦＲスタックの最も上にある規則Ｒ
１に結合する。この規則の事前条件が検査され、条件が
満たされない場合またはその規則が既にグループ型と印
が付けられている場合、ＦＲスタックがポップされ、ｆ
（ｔ）がＰＲにプッシュされ（この規則はアンドゥ可能
型には変更されない）、条件が満たされる場合（この規
則は時刻ｔにおいて発動可能であると言う）には、それ
は最初の発動可能な規則であり、ｆ（ｔ）は、グループ
型と記され、それ自体のＧｒｏｕｐ−Ｓａｄｄｒｅｓｓ
フィールドに追加され、ｆ（ｔ）として存続し、ｌａ（
ｔ）がＦＲ（ｔ）に適用される。発動可能な規則が見つ
からない場合、再生が停止され、テープ・プログラムの
最後に達したことが利用者に知らされる。先取り処理で
は、ｌａ（ｔ）がＦＲ（ｔ）全体の高速探査を行って他
のすべての発動可能な規則を一度に集め、発見された各
規則がグループ型と記され、続いて、ｌａ（ｔ）によっ
て発見された規則の集合がｆ（ｔ）の現在のＧｒｏｕｐ
−Ｓａｄｄｒｅｓｓ集合（これは、最初は｛ｆ（ｔ）｝
である）に結合される。 グループ型のｆ（ｔ）規則は、そのすべてのアクタ（そ
のＧｒｏｕｐ−Ｓａｄｄｒｅｓｓ集合からのアクタ）お
よび視覚的効果（画像的なアンドゥ・コマンドの集合）
に対するアンドゥ（回復）表現を生成し記録することに
より、アンドゥを行う準備がなされ、その規則集合が、
アンドゥ可能グループの型と印が付けられて、ｕ（ｔ）
となる。次に、ｆ（ｔ）＝Ｒ１のＧｒｏｕｐ−Ｓａｄｄ
ｒｅｓｓからのメッセージ集合が、センダのアクタの集
合からレシーバのアクタの集合へと並列に送られ、ｆ（
ｔ）のＧｒｏｕｐ−Ｓａｄｄｒｅｓｓからの事後条件が
、その集合の各規則に対する別個の背景条件において、
対応するアクタの属性をいくつか変更して並列的に実行
され、対応する視覚効果が表示され、ＦＲスタックが一
回ポップされ、さらにｕ（ｔ）は、それがＵ１となりｔ
が単位時間だけインクリメントされるＰＲスタックへと
プッシュされる。 ３）記録の場合、ｒ（ｔ）は、記録直後の規則を示し、
ＦＲスタックにプッシュされ、次のステップが時刻ｔで
再生される。 ４）アンドゥを１ステップ行う場合、ｕ（ｔ）は、Ｕ１
をアンドゥする次の規則を示す。Ｕ１がアンドゥ可能型
でない場合、スタックＰＲがポップされ、ｕ（ｔ）がＦ
Ｒ上にプッシュされる。ｕ（ｔ）のＧｒｏｕｐ−Ｓａｄ
ｄｒｅｓｓの規則と同様に、Ｕ１がアンドゥ可能型の場
合、各規則の事実上の影響は、（オプションのメッセー
ジ表示も含めて）元どうりにされ、そのアクタのアンド
ゥ表現が実行されて、この規則が発動される前の初期状
態にまでそれらを復元し、アンドゥ表現がｕ（ｔ）から
削除され、元の型の各規則が復元され、最も上の規則が
ｆ（ｔ）となり、ＰＲスタックが一度ポップされ、さら
にｆ（ｔ）は、それがＲ１となりｔが単位時間だけデク
リメントされるＦＲスタック上にプッシュされる。 ５）自動再生するには、利用者の入力が要求されるか、
またはＦＲスタックが空になり、かつ他の規則が記録さ
れていなくなるまで、再生ステップを反復する。 ６）自動アンドゥをするには、ＰＲスタックが空になる
まで、アンドゥ・ステップを繰り返す。 ７）停止するには、最後の規則の実行またはアンドゥが
完全に行われた後（例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど）、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【０２１８】生成シミュレーション・モードは、同時シ
ミュレーション・モードの拡張である。このモードでは
、テープが閉ループに接着されるので、一連のスクリプ
ト規則および一般スクリプトを繰り返し発動することが
できる。このモードは、同時発動がある標準的な生成規
則システムに類似している。さらに、この生成モードで
は、時間依存性および完全な可逆的実行がサポートされ
る。繰り返し発動するスクリプト規則の集合によって形
成されるループは、終端条件（例えば、カウンタが満期
になるなど）が満たされるまで実行し続ける。 【０２１９】生成モードは、次のように実現される。 １）ＰＲ（ｔ）は、スタック・オブジェクトの現在の内
容を表し、ＦＲ（ｔ）は、シーケンス＝ハッシュ・テー
ブル＝格子オブジェクトの結合体の内容である。つまり
、ＦＲは、ハッシュ・テーブル、即ちキーが符号化され
た一種のコンピュータ・オブジェクトであるため、ＦＲ
にいかに多くのスクリプト規則が格納されていても、ス
クリプト規則をその記号的参照情報（Ｓｉｄ）によって
効率的に検索することができる。ＦＲは、所与の規則集
合の後に発動できる次の規則集合がＦＲの限られた部分
集合に含まれることが分かるように、予め計算された相
互間の論理的依存状態に基づいてスクリプト構造体が予
め配列されているような格子である。生成モードにおい
ては、再生、自動再生、アンドゥ、または自動アンドゥ
の最中にＦＲは（例えば、ポップやプッシュによって）
変更されない。しかし、ＦＲは、スクリプト規則の記録
および消去（削除）の間に変更され再構成される。再生
またはアンドゥの間に記録も消去も起こらないと仮定し
て、ＦＲ＝（Ｒ１，Ｒ２，．．．，Ｒｐ）とする。時刻
ｔにおいて、ｐｔ≦ｐとしたＳＦＲ（ｔ）＝Ｓ（ＦＲ，
ｔ）＝（Ｒ１，Ｒ２，．．．，Ｒｐｔ）を時刻ｔに発動
するべき候補であるスクリプト規則のＦＲからの有限部
分集合とする。ＳＦＲは、ｔの前に発動された規則を知
ることによってＦＲ格子から得られる。 ２）次のスクリプト規則を再生するためには：ｆ（ｔ）
をＳＦＲ（ｔ）からの最初の規則である規則Ｒ１に結合
する。この規則の事前条件が検査され、条件が満たされ
ない場合、その規則は無視され、ｆ（ｔ）は、ＳＦＲ（
ｔ）からの次の規則のインスタンスに結合され、それは
、ｆ（ｔ）が発動可能な規則となるかＳＦＲ（ｔ）から
のすべての規則が不成功のうちに検査されるまで、検査
される。この時点で、発動可能な規則が見つからない場
合、ｆ（ｔ）は、待機型またはアンドゥ可能型の規則の
インスタンスに結合され、ｆ（ｔ）はＰＲ上にプッシュ
され、ｔが単位時間だけインクリメントされる。ｆ（ｔ
）の事前条件が満たされる、即ち時刻ｔにおいて規則が
発動可能である場合、それはＳＦＲからの最初の発動可
能な規則であり、元の規則を変更することを防止するた
めにｆ（ｔ）は、それ自体のインスタンスによって置き
換えられ、グループ型と印が付けられ、それ自体のＧｒ
ｏｕｐ−Ｓａｄｄｒｅｓｓフィールドに加えられる。そ
れは、ｆ（ｔ）として存続し、ｌａ（ｔ）がＳＦＲ（ｔ
）に適用される。先取り処理では、ｌａ（ｔ）がＳＦＲ
（ｔ）全体の高速探査を行って時刻ｔにおいて発動可能
な他のすべての規則を集め、発見された各規則はグルー
プ型と印を付けられたそれ自体のインスタンスとして集
められ、続いて、ｌａ（ｔ）によって収集された規則イ
ンスタンスの集合がｆ（ｔ）の現在のＧｒｏｕｐ−Ｓａ
ｄｄｒｅｓｓ集合（これは、最初は｛ｆ（ｔ）｝である
）に結合される。グループ型のｆ（ｔ）規則は、そのす
べてのアクタ（そのＧｒｏｕｐ−Ｓａｄｄｒｅｓｓ集合
からのアクタ）および視覚的効果（画像的なアンドゥ・
コマンドの集合）に対するアンドゥ（回復）表現を生成
し記録することにより、アンドゥを行う準備がなされ、
その規則集合が、アンドゥ可能グループの型と印が付け
られて、ｕ（ｔ）となる。次に、ｆ（ｔ）＝Ｒ１のＧｒ
ｏｕｐ−Ｓａｄｄｒｅｓｓからのメッセージ集合が、セ
ンダのアクタの集合からレシーバのアクタの集合へと並
列に送られ、ｆ（ｔ）のＧｒｏｕｐ−Ｓａｄｄｒｅｓｓ
からの事後条件が、その集合の各規則に対する別個の背
景条件において、対応するアクタの属性をいくつか変更
して並列的に実行される。対応する視覚効果が表示され
、さらにｕ（ｔ）は、それがＵ１となりｔが単位時間だ
けインクリメントされるＰＲスタックへとプッシュされ
る。 ３）記録の場合、ｒ（ｔ）は、記録直後の規則を示し、
ＳＦＲ（ｔ）の要素としてＦＲ格子に挿入され、必要で
あれば前の配列を復元するためにＦＲ格子が再計算され
て、時刻ｔにおいて次のステップが再生される。 ４）アンドゥを１ステップ行う場合、ｕ（ｔ）は、Ｕ１
をアンドゥする次の規則を示す。Ｕ１がアンドゥ可能型
でない場合、誤りが存在する。Ｕ１がアンドゥ可能で待
機型の場合、Ｕ１は捨てられ、ｔが単位時間だけデクリ
メントされる。Ｕ１が、アンドゥ可能で待機（グループ
）型でない場合、ｕ（ｔ）のＧｒｏｕｐ−Ｓａｄｄｒｅ
ｓｓの規則と同様に、各規則の事実上の影響は、オプシ
ョンのメッセージ表示も含めて、元どうりにされ、その
アクタのアンドゥ表現が実行されて、この規則が発動さ
れる前の初期状態にまでそれらを復元し、アンドゥ表現
がｕ（ｔ）から削除され、元の型の各規則が復元され、
最も上の規則がｆ（ｔ）となり、ＰＲスタックが一度ポ
ップされ、さらにｆ（ｔ）はそのまま存続し、ｔが単位
時間だけデクリメントされる。 ５）自動再生するには、利用者の入力が要求されるか、
または停止ボタンが押されるまで、再生ステップを反復
する。 ６）自動アンドゥをするには、ＰＲスタックが空になる
まで、アンドゥ・ステップを繰り返す。 ７）停止するには、最後の規則の実行またはアンドゥが
完全に行われた後（例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど）、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【０２２０】動作の規則の記録、消去、および照会ＧＲ
ＡＳの使用およびソフトコーダの実行能力におけるいく
つかの利点は、何時でも変更を行い、機械の処理能力に
限定される穏当な時間でその変更を自動的に有効にする
柔軟性に由来するものである。上述の再生およびアンド
ゥの機構は、ソフトコーダによって提供されるそのよう
な柔軟な処理モデルの実例である。テープ・プログラム
のシミュレーションの最中にアクタ間の新たな通信を記
録したり、関係する動作規則を取り除いたりできること
も、仕様決定、システム設計、および試験に対するソフ
トコーダ方式の威力の例である。 【０２２１】アクタ間の動作規則を記録するには、３つ
のステップが必要である。 １）ビジュアル・プログラミング：ビジュアル・クルー
（ｃｌｕｅ）、タイプ入力、メニュー項目によって収集
された必要な情報を用いて、基本的なスクリプト構造体
を生成する。 ２）規則の挿入：現在の規則ベースに新たなスクリプト
構造体を挿入する。 ３）修正されたテープ・プログラムを（前節の説明のよ
うに）さらに一段階再生する。 【０２２２】ビジュアル・プログラミング：ＧＲＡＳ画
面上で現在活性なビデオ・モニタのうちの１つからセン
ダのアクタとレシーバのアクタを選択したり、メニュー
選択およびキーワード捜索をしたり、バックステージか
らアクタを検索するためにオーディション表現を選択し
たりすることによって、基本的なスクリプト構造体Ｒ０
を作る。オーディション表現は、利用者によって編集お
よびカスタマイズすることも可能である。スクリプト構
造体Ｒ０は、記号による新たな参照情報（Ｓｉｄ）が与
えられ、センダおよびレシーバの属性には、選択された
アクタ（またはアクタのオーディション記述）が書き込
まれ、センダおよびレシーバのＴ（真）に対するデフォ
ルトの事前条件が定義され、事後条件は全く定義されな
い。次に、新たなメッセージを（利用者がタイプ入力で
）指定するか、またはメニューと既存のスクリプト構造
体の集合に対するキーワード捜索とによって選択する。 新たなメッセージが指定された場合、Ｒ０のメッセージ
・フィールドには、指定されたメッセージが書き込まれ
る。既存のスクリプト構造体Ｒ１が選択された場合、Ｒ
１の事前条件と事後条件とメッセージ表現とのインスタ
ンスが生成され、Ｒ０の対応するフィールドを埋めるた
めに使用される。何れの場合も、新たに記録された規則
が前に発動された規則の集合の結果として発動される可
能性を保証する必要があるならば、Ｒ０の事前条件が変
更される。例えば、Ｒ２の発動後にＲ０が記録される場
合、「Ｒ０はＲ１の後に発動しなければならない」とい
うデフォルトの事前条件が、目標の規則記述言語で生成
される。 【０２２３】規則の挿入：この点において、規則Ｒ０は
、未来のリールに挿入する用意ができている。連続、ス
マート、および同時の各モードにおいては、Ｒ０は、単
にＦＲスタックの上にプッシュされ、このとき２つの記
録モードが可能である。 【０２２４】１）接続モードでは、発動するべきＲ０の
前例（前記の例ではＲ１）に以前は依存していたＦＲ内
のすべての規則は、発動をＲ０に現在依存するように、
自動的に更新される。ＦＲにおけるある規則の事前条件
は、そのように変更される。 【０２２５】２）並列モードでは、ＦＲの何れの規則も
変更されず、従って、Ｒ０は、正常ならば前例の後に（
前記の例では、Ｒ１の後に）発動するはずの他の規則と
平行して発動すると予測される。生成モードでは、Ｒ０
は、ＳＦＲ（ｔ）に最初の要素として挿入され、ＦＲの
格子構造の変更は、自動的に計算されるが、この場合、
記録モードに依存する。 【０２２６】１）接続モードでは、発動するべきＲ０の
前例（前記の例ではＲ１）に以前は依存していたＳＦＲ
（ｔ）内のすべての規則は、発動をＲ０に現在依存する
ように、自動的に更新される。ＳＦＲ（ｔ）におけるあ
る規則の事前条件は、そのように変更され、さらに変更
は、ＦＲ格子の組織内に伝えられる。 【０２２７】２）並列モードでは、ＳＦＲ（ｔ）の何れ
の規則も変更されず、従って、Ｒ０は、正常ならば前例
の後に（前記の例では、Ｒ１の後に）発動するはずのＳ
ＦＲ（ｔ）からの他の規則と平行して発動すると予測さ
れる。 【０２２８】既存の動作規則を消去する場合、ソフトコ
ーダによって提供される基本的な操作により、発動され
た最後のスクリプト規則を利用者が削除できる。この最
後の規則がグループ型の場合、利用者は、その集合から
規則を１つ選択するように促される。次に、テープ・プ
ログラムが１ステップだけ戻されて、選択されたスクリ
プト構造体がＦＲ（または生成モードではＳＦＲ）から
削除される。そして、発動のために削除された規則にか
つて依存していたすべての規則に、発動のために依存す
るのに最適な代替規則が与えられる。生成モードでは、
次に、ＦＲの格子構造が再編成され、規則の間の新たな
予配列が生じる。次に、その変化の影響を表示するため
に、テープ・プログラムが１ステップだけ再生され、削
除された規則に代わって別の規則が発動することになる
。規則集合の大きな塊を消去する場合、規則集合の一部
を切り取って捨てる方法が、フィルム・エディタによっ
て提供される。 【０２２９】ある型の規則（または規則の部分集合）の
未来または過去の実行のための既存の規則集合への照会
は、テープ・プログラムの実行を利用者に取って関心の
ある点に迅速に位置付ける機構を提供する。ソフトコー
ダの進歩したプログラム実行性を用いれば、実行履歴ま
たは実行の将来における所望の位置へテープ・プログラ
ムを自動的に位置決めすることを要求することができる
。これは、所望の点の例を記述する視覚的照会を記録し
、ＰＲにおいて一致する一連の実行済み規則を捜し、照
合が成功した場合、必要とされるカウンタ位置への自動
アンドゥによってテープを位置決めし、成功しなかった
場合には、一致するまで自動再生を実行することにより
テープを位置決めする。 【０２３０】ビデオ・コネクタ ビデオ・コネクタは、ＧＲＡＳと異質のシステムとの間
の物理的または仮想的なデータ・リンクと結び付いたソ
フトウェアの通信プロトコルである。ビデオ・コネクタ
は、ビデオ信号源（カメラ、ミキサ、テレビ・ケーブル
）をＶＣＲに連結する同軸ケーブルに似ている。しかし
、ＶＳＭでは、ビデオ・コネクタにより、外部のシステ
ムからテープへと事象を記録するとともに、外部のシス
テムからＧＲＡＳを遠隔制御するための通信路が提供さ
れる。 【０２３１】ＧＲＡＳでは、利用者が処理を描写する（
指定する）のをカメラが追うように、利用者の対話から
得られる仕様をすべてのビデオ・モニタから記録するこ
とができる。記録中の各ビデオ・モニタは、アクタどお
しの間の作用がカメラで記録されるビデオ・スタジオの
一部である。ビデオ・スタジオ内のカメラは、仮想的な
ビデオ・コネクタによってソフトコーダに結合されてい
る。 【０２３２】ビデオ・コネクタのインタフェースは、ア
プリケーションがＧＲＡＳにデータ跡を送ると同時にＧ
ＲＡＳを遠隔制御できるように実現される。例えば、ア
プリケーションは、新たなテープを生成し、そのテープ
の遠隔記録（つまり、メッセージの照会）を開始し、詳
細水準を変更し、アニメーション・ビューを変更するこ
とができると同時に、ＧＲＡＳは、そのデータ跡の動画
化を同期モードまたは非同期モードで開始することがで
きる。所望により、アプリケーションは、使用される画
像表現を完全に制御することができる。ＧＲＡＳの遠隔
制御は、如何なる双方向データ・リンクによってもサポ
ート可能な標準のリモート・エバリュエーション・プロ
トコル（遠隔関数呼び出し）に基づく。 【０２３３】ＯＯスクリプト ＯＯスクリプトは、２つのアクタの間の単一処理を定義
する要素体である。ＯＯスクリプトは、アクタの１つの
動作の一面を記述する最小の実体である。各ＯＯスクリ
プトにより、センダおよびレシーバとして知られる１つ
または２つのアクタが関与する動作の１つの規則が記述
される。 【０２３４】オブジェクト対オブジェクトのスクリプト
（ＯＯスクリプト）は、正式には、（スクリプト識別子
（ｓｉｄ），センダ，レシーバ，前提条件リスト（ｐｒ
ｅｃｏｎｄ−ｌｉｓｔ），事後条件リスト（ｐｏｓｔｃ
ｏｎｄ−ｌｉｓｔ），メッセージ，オプションの参考情
報）という数学的なタプル（特定数要素の集合）として
定義される。各ＯＯスクリプトは、特有の識別子（ｓｉ
ｄ）に関係付けられている。「センダ」は、「レシーバ
」に呼び掛けるために「メッセージ」を発動する実体を
指す。「前提条件リスト（ｐｒｅｃｏｎｄ−ｌｉｓｔ）
」は、ＯＯスクリプトが活性化されるために満たされな
ければならない前提条件を与える。「事後条件リスト（
ｐｏｓｔｃｏｎｄ−ｌｉｓｔ）」は、そのＯＯスクリプ
トがの実行終了後には真となるべきシステムの事後条件
を与える。「メッセージ」は、オプションの引数を伴う
メッセージまたは関数の名前である。表された処理また
は関係するオブジェクトに関するコメントをオプション
の参考情報に含めることができる。 【０２３５】ＯＯスクリプトのシンタックスを次に述べ
る。事前条件リストおよび事後条件リストは、両方とも
括弧で囲み、オプションの参考情報は、引用符（“ ”
）で囲む。引数のないメッセージは、それを囲む括弧を
付けても付けなくても良いが、引数付きのメッセージは
、引数を従えた第１の要素としてメッセージ名を伴う括
弧付きのリストとして表す。渡される文字データ・メッ
セージは、引用符で囲まれた文字列として示される。 【０２３６】ＯＯスクリプトにより、センダがレシーバ
にメッセージを送る処理においてセンダとレシーバとの
間の相互作用を包含する規則が具体化される。メッセー
ジは、関数の呼び出し（例えば、プロシージャ・コール
の場合のような作用の要求）、データ伝送、またはその
両方で構成することができる。規則は、どの実体がセン
ダおよびレシーバであるか、前記のような相互作用が起
こる時期を支配する条件の記述、および相互作用の結果
である状態を指定する。スクリプトは、特定の状況また
は一連の事象に対するシステムの作用規則を包含するＯ
Ｏスクリプト集合である。 【０２３７】図２〜図５は、コンピュータのログイン手
順の仕様およびシミュレーションを与えるためにＯＯス
クリプトがどのように使用されるかの例を示す。図２は
、実施のコンピュータ手順の流れ図であり、図３は、コ
ンピュータのログイン手順の実施に使用される対応する
ＯＯスクリプトを示し、図４および図５は、ＧＲＡＳに
よるログイン手順のシミュレーションの画像表示である
。 【０２３８】コンピュータ４００は、端末４１０に「ｓ
ｅｎｄ−ｌｏｇｉｎ」メッセージ４０５を送ることによ
ってコンピュータのログイン手順を開始する（作用ブロ
ック２１０）。開始ステップに対応するＯＯスクリプト
を図３のＯＯスクリプト３１０として示す。端末４１０
は、「ｓｅｎｄ−ｌｏｇｉｎ」メッセージ４０５に対し
、ログイン・プロンプト・メッセージ４１５を利用者４
２０に表示して応答する（作用ブロック２２０およびＯ
Ｏスクリプト３２０）。ログイン・プロンプト・メッセ
ージ４１５に対し、利用者４２０は、自分のログイン・
ネームを端末のキーボード４２５上で入力することによ
って応答する（作用ブロック２３０およびＯＯスクリプ
ト３３０）。 手順の次のステップは、ＧＲＡＳの詳細水準に依存する
。前記のように、ＯＯスクリプト識別子によって、多重
詳細水準が可能である。詳細水準が高いほど、経験がよ
り豊かな利用者のためのシナリオの深入りしたステップ
まで示されるが、詳細水準が低くなると、要約水準の高
いシミュレーションが示される。詳細水準を「１」と決
定した場合（判断２４０）、水準が低い方の２つのステ
ップがシミュレートされ（図５）てから、次の水準「０
」のステップがシミュレートされる。詳細水準が「１」
の場合（判断２４０）、端末５１０は、利用者のキーボ
ード入力内容５２５をログイン・ネーム・データ・メッ
セージ５３５によってコンピュータ５００へ送る（作用
ブロック２４５およびＯＯスクリプト３４０）。 次に、コンピュータ５００が、利用者５２０と共にパス
ワード入力手順を開始するようにメッセージ５４５を端
末５１０に送る（作用ブロック２４７およびＯＯスクリ
プト３５０）。シミュレーションの次のステップは、水
準０および水準１の両方に対して同じである。そのシミ
ュレーションに付いては、図４を参照する。端末４１０
が、「パスワード・プロンプト」メッセージ４３５を利
用者に送る（作用ブロック２５０およびＯＯスクリプト
３６０）。次に、利用者４２０が、キーボードでパスワ
ードを入力すことによって、パスワード・データ４４５
を端末４１０に送る（作用ブロック２６０およびＯＯス
クリプト３７０）。そして、シミュレーションの詳細水
準が「０」か「１」かをＧＲＡＳシステムが判断する（
判断４７０）。詳細水準が「０」ならば、そのシミュレ
ーションは終了する（作用ブロック２８０）が、詳細水
準が「１」の場合（図５参照）は、端末５１０が、パス
ワード・データ・メッセージ５７５をコンピュータ５０
０に送る（作用ブロック２７５およびＯＯスクリプト３
８０）。そして、シミュレーションが終了する。 【０２３９】以上の説明は、本発明の一実施例に関する
もので、この技術分野の当業者であれば、本発明の種々
の変形例が考えられるが、それらはいずれも本発明の技
術的範囲に包含される。 【０２４０】 【発明の効果】以上述べたように、本発明によれば、プ
ログラム仕様についての労力をあまり要求することなく
、プログラムの作用をいっそう完璧にモデル化してプロ
グラム仕様を作ることができる。
ムおよび通信システムのためのプログラム仕様を開発す
る方法および装置に関する。 【０００２】 【従来の技術】コンピュータおよび電気通信システムの
作用を制御するための複雑なコンピュータ・プログラム
やソフトウェア・システムの開発には、大きな作業努力
を必要とする。コンピュータ・プログラマ（ソフトウェ
ア開発者）は、複雑なソフトウェア・システムの設計、
コーディングおよび検査に多大な努力を費やす。複雑な
システムに対しては、ソフトウェア開発サイクルと言わ
れる設計、執筆およびコーディングの行程に何年もかか
ることもしばしばある。長年に渡りソフトウェア開発者
が学んだことは、ソフトウェアの検査にサイクルをあま
り費やさず、ソフトウェアに対する必要条件の立案、ソ
フトウェアの設計、およびコーディングに大部分を費や
せば、開発周期が短縮されると言うことである。この知
識が、ソフトウェア技術の進歩と相まって、さらに複雑
なソフトウェア・システムの開発をもたらした。 【０００３】ソフトウェア技術の進歩にもかかわらず、
ますます複雑化するコンピュータ・ソフトウェアおよび
ソフトウェア稼働システムの開発は、依然として困難で
ある。この難しさのために、効率的かつ完全なソフトウ
ェア設計システムの重要性が増してきた。仕様設計が、
ソフトウェアの開発を容易にするための重要な第１歩で
ある。仕様書は、ソフトウェア・システムが満足しなけ
ればならない必要条件を含み、システムがどのように作
用しなければならないかを指定するものである。仕様書
は、その記述対象であるソフトウェア・システムと同様
に、生成がますます困難になってきた。これに対する１
つの理由は、仕様の生成に必要なソフトウェア環境の詳
細な知識である。 【０００４】ソフトウェア・システムの作用をモデル化
することによって仕様の開発および検査を行うことの難
しさを軽減するために、ソフトウェア開発者はソフトウ
ェア・シミュレータを使用する。シミュレータは、シス
テムに関する入力に基づいて、そのシステムの作用をモ
デル化するプログラムを生成する。シミュレータは、仕
様の開発に役立つが、問題もいくつかある。第１に、シ
ミュレータは、単純でなじみ深いモデルを基にしておら
ず、システムの適切なモデルを生成するには、少なくと
もシミュレータ「言語」のプログラム作製知識が必要と
なる。開発者は、シミュレーションされるシステムがい
かに作用するかということに関わらなければならないだ
けでなく、シミュレーション・プログラムの開発にかな
りの量の思考を充てる必要がある。こうして、ソフトウ
ェアの仕様設計過程に複雑さが加わることになる。 【０００５】次に、シミュレータは、１つのシステムの
独立した部分に対し特定の入力を要求するとともに特定
の出力を与えて、その部分を別個の実体として表す。こ
れらの実体の入力と出力が一致しない限り（しばしば一
致しない）、実体どうしが互いに作用し合う（「接続」
される）ことができないので、問題である。このように
、シミュレータを使用する開発者は、システムの部分の
全体的な統合を常にみることはできない。 【０００６】最後に、シミュレーション中に開発者が、
誤りを発見したり、システムの作用のある部分を望む場
合、開発者は、シミュレーションを停止し、所望の変更
を行い、シミュレートするべきプログラムをコンパイル
しなおしてから、シミュレーションを最初から始めなけ
ればならない。このように、開発者は、変更結果を直ち
に見ることができないため、変更を行う処理に時間がか
かり、時間を非効率的に使用する結果となる。 【０００７】 【発明が解決しようとする課題】従って、従来の技術の
課題は、利用者の広範なプログラミング知識を必要とし
ないソフトウェアの効率的な仕様設計手段を与えること
である。 【０００８】 【課題を解決するための手段】前記の問題を解決するた
めの本発明の一実施例は、仕様の画像記録およびアニメ
ーションのための（ＧＲＡＳ＝Ｇｒａｐｈｉｃａｌ Ｒ
ｅｃｏｒｄｉｎｇ ａｎｄ Ａｎｉｍａｔｉｏｎ ｏｆ
Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ）システムである。Ｇ
ＲＡＳシステムは、プログラム仕様の記録、シミュレー
シ（アニメーション）、および洗練をグラフィカルに行
うために使用される。このシステムは、実例によるプロ
グラム仕様の設計に対応している。 【０００９】ＧＲＡＳシステムの目的は、プログラミン
グの知識が少ない利用者がプログラム仕様を容易に作る
ための便宜を与えることである。この目的は、馴染み深
いモデルに基づくユーザ・フレンドリな環境を与えるこ
とによって達成される。ＧＲＡＳシステムは、プログラ
ム用の仕様の作製が演劇の作製、演出、テープ録画、お
よび編集に類似するビデオ・スタジオの隠喩（ｍｅｔａ
ｐｈｏｒ）（ＶＳＭ）に基づいている。ビデオ・スタジ
オ・メタファは、リハーサルによるプログラミングで用
いられる劇場の隠喩（ｔｈｅａｔｅｒ ｍｅｔａｐｈｏ
ｒ）を拡張する。例えば、ゼロックス社の１９８６年５
月のＳＣＬ−８４−１のローラ・グールド（Ｌａｕｒａ
Ｇｏｕｌｄ）およびウィリアム・フィンツァ（Ｗｉｌ
ｌｉａｍ Ｆｉｎｚｅｒ）による「リハーサルによるプ
ログラミング（Ｐｒｏｇｒａｍｍｉｎｇ ｂｙ Ｒｅｈ
ｅａｒｓａｌ）」を参照。ＶＳＭに基づくシステムを用
いて仕様を作製するには、プログラミングの知識はあま
り必要ない。技術者は、仕様設計システムには注意をほ
とんど向けずに、目的のシステムが如何に作用するべき
かに集中することができるので、ソフトウェアの仕様設
計過程において複雑さが軽減され、好都合である。 【００１０】ＧＲＡＳシステムでは、仕様のソフト的記
録手段である「テープ」に対し、利用者が入力を与える
。ＧＲＡＳシステムは、一群のシナリオ例のステップを
記録することにより、またそれらのシナリオ例に対する
追加的なグラフィック規則を引き出すことにより、テー
プを生成する。１つのステップにより、シミュレートさ
れるテープのアクタどうしの間のメッセージ渡しによる
相互作用が指定される。（後述のように、「アクタ（ａ
ｃｔｏｒ）」の概念は、人工知能の分野で周知である。 ） 【００１１】アクタは、データとそのデータを操作する
手続きとを備えたコンピュータ・ソフトウェア構造であ
る。ＧＲＡＳで使用されるアクタも、知識ベースおよび
そのデータへの変更の履歴を持っている。アクタは、電
話若しくは電話交換システムなどのシステムの物理的構
成要素、またはプロセス若しくはデーターベースなどの
ソフトウェア構成要素、またはそのシステムと相互に作
用する作因、人などを表す。ＧＲＡＳでは、シナリオ例
の１ステップを記録するために、利用者は、そのステッ
プ用のセンダ（ｓｅｎｄｅｒ）およびレシーバ（ｒｅｃ
ｅｉｖｅｒ）のアクタ、センダのアクタからレシーバの
アクタに送られるメッセージ、およびそのステップが実
行される前にシステムに存在していなければならない条
件を指定する。 各ステップは、テープ上に規則として記録され、そのシ
ナリオ例において実行される。利用者は、そのシナリオ
例の実行（そのテープの再生）、修正の実施、新たなス
テップの追加、または新たなシナリオ例の生成によって
、そのテープを対話的に洗練することができる。 【００１２】コンピュータ・システムに対するコンピュ
ータ・ログイン・シーケンスの設計は、ＧＲＡＳの簡単
な使用例となる。コンピュータ・ログイン・シーケンス
のためのアクタは、コンピュータ、端末、および利用者
である。ＧＲＡＳを使用する技術者が、コンピュータ・
ログイン・シーケンスを次のように実現することを希望
するものと仮定する。即ち、（１）コンピュータが、「
ｓｅｎｄｌｏｇｉｎ」要求メッセージを端末に送ること
によって、そのシーケンスを活性化する。（２）次に、
端末が、ログイン・プロンプトを利用者に表示する。（
３）利用者が、ログイン・ネームをキーボード入力を介
して端末に送る。（４）端末が、そのログイン・ネーム
をコンピュータに送信する。（５）コンピュータが、そ
の端末にパスワード入力手順を開始するようにメッセー
ジを送る。（６）端末が、パスワード・プロンプトを利
用者に表示する。（７）利用者が、パスワードをキーボ
ード入力を介して端末に送る。そして、（８）端末が、
そのパスワードをコンピュータに送る。 【００１３】このコンピュータ・ログイン・シーケンス
のテープのための入力を与えるために、ＧＲＡＳの利用
者は、そのシーケンスの最初のステップを指定すること
によって開始する。これを行うことで、利用者は、１つ
のシナリオ例の最初のステップを指定することになる。 完全なプログラムは、複数のシナリオ例によって記述さ
れる。前記のステップ（１）を指定するには、まずセン
ダのアクタをコンピュータに、レシーバのアクタを端末
に、渡されるメッセージを「ｓｅｎｄ ｌｏｇｉｎ」に
指定する。 このステップは、利用者にグラフィカルに表示される一
方、そのシナリオ例の一部として記録される。前記のス
テップ（２）を指定するために、利用者は、センダ・ア
クタを端末に、レシーバ・アクタを利用者に、そして渡
されるメッセージを「ログインして下さい：」と指定す
る。やはり、このステップも、記録されつつ、利用者に
グラフィカルに表示される。そして、利用者は、そのシ
ーケンスの残りのステップを同じ要領で指定する。シー
ケンスを記録した後、利用者は、そのテープを再生する
ことにより、そのコンピュータ・ログイン・シーケンス
をグラフィカルにシミュレートする。コンピュータ・ロ
グイン・シーケンス全体のＧＲＡＳによるグラフィカル
な表示を図５に例示する。 【００１４】利用者は、記録中いつでも記録を停止して
、既に指定したステップをシミュレートするためにテー
プを再生することができる。ステップが正しくなければ
、そのステップの対話的な「アンドゥ」、アクタの変更
、メッセージの変更、またはそのステップに対する事前
条件の変更を行った後、そのステップを再び再生するこ
とができる。これにより、プログラム仕様の編集および
洗練が対話的に可能となる。 【００１５】前記の例は、本発明の作用を説明するもの
であるが、本発明の原理によれば、コンピュータが利用
者の入力に対話的に応じてプログラムの仕様を生成する
。当分野はさておき、このプログラム仕様システムによ
って、仕様に対し対話的に与えられる変更に応じて、そ
の仕様のプログラムを再コンパイルすることなく、それ
らの変更のシミュレーションを直ちにグラフィカルに表
示する便宜が提供される。開発者は、より迅速に、より
効率的に、しかもシミュレーション・システムの操作の
知識もほとんど無しに、仕様を作製することができるの
で、好都合である。 【００１６】当分野からさらに逸れるが、本発明により
、アクタ（これは、データの構造とプログラム手順から
なるソフトウェア対象である）の合併、およびアクタの
作用の合併がサポートされる。「アクタ」という考えは
、人工知能に由来する周知の概念である。例えば、１９
８６年、ＭＩＴプレス刊のガル・アーガ（Ｇｕｌ Ａｇ
ｈａ）による「アクタ−−−−分散システムにおける同
時処理のモデル（Ａｃｔｏｒｓ： Ａ Ｍｏｄｅｌｏｆ
Ｃｏｎｃｕｒｒｅｎｔ Ｃｏｍｐｕｔａｔｉｏｎ ｉ
ｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍｓ）」を参
照のこと。この合併処理により、開発者は、プログラム
・システムの部品の全体的な統合を見ることが可能とな
る。 【００１７】本発明の典型的な実施例であるＧＲＡＳは
、ＶＳＭに基づくオブジェクト指向で知識ベースの視覚
的プログラミング・システムである。ＧＲＡＳは、利用
者の入力を用いてシステムの視覚的シミュレーションと
仕様データーベースを生成し、さらに詳細な入力を受信
した時、そのデーターベースを増強する。ＶＳＭは、親
しみやすい単純なモデルを提供するので、プログラミン
グについても、そのシステムについても詳しい知識なし
に仕様を生成することができるので、好都合である。 【００１８】仕様のシナリオ例の記録（入力）、再生（
実行）、およびアンドゥ（逆向きの実行）を行うための
機構が、ＧＲＡＳのソフトコーダ（ＳｏｆｔＣｏｄｅｒ
）モジュールによって提供される。ソフトコーダは、ア
クタ間の作用の規則を記述する「（ビデオ）テープ・プ
ログラム」を処理して、仕様プログラムの実行の完全な
履歴からなる「テープ・シナリオ」を生成する仮想的な
装置である。テープ・プログラムの各ステップは、算術
演算および（または）論理演算の集合、アクタ・データ
、およびステップを「アンドゥ」することによって逆戻
りすることができるために仕様の一部を対話的に変更す
る機構を利用者に提供するアクタ間の通信を表すメッセ
ージからなる。効率的に誤りを訂正し、シミュレーショ
ン中に仕様の変更を行って、その結果を直ちに見ること
ができるので、好都合である。ＧＲＡＳのビジュアル・
オブジェクト網管理（ＭｏＶｏｎ＝ｍａｎａｇｅｍｅｎ
ｔ ｏｆ ｖｉｓｕａｌ ｏｂｊｅｃｔ ｎｅｔｗｏｒ
ｋｓ）モジュールおよびアクタ・フレーム（ＡＦ）モジ
ュールにより、アクタおよびアクタの作用を合併する機
構が提供されるため、利用者は、全体的に統合された仕
様を見ることが可能となる。ＧＲＡＳは、仕様の別個の
部分の統合および組み合わされた作用を見る便宜を利用
者に与えるので、好都合である。 【００１９】プログラム用の仕様を対話的に生成する方
法は、キーボードやマウスなどの入力装置を介したアク
タ・データの受信に応じて、複数のテープ・シナリオに
対するアクタを指定すること、およびそのアクタ・デー
タを格納することからなる。アクタの指定には、新たな
アクタの生成、以前に生成されたアクタの選択、および
アクタ・データの修正が含まれる。システムは、入力装
置を介して作用ステップを受信すると、これに応じて、
そのステップを後の実行のために記録する。これらのス
テップは、アクタ間の通信、アクタ間の関係、アクタに
対する論理的または算術的な演算、および複数のテープ
・シナリオに対する判断点からなる。最初の判断の選択
を入力装置を介して受信すると、これに応じて指定の一
貫性を評価するために、最初のテープ・シナリオが実行
される。最初のテープ・シナリオの実行は、一組の所定
の条件の発生に基づいてシナリオのステップをシミュレ
ートし、そのシミュレーションの結果を記録することか
らなる。シミュレートすることは、アクタ間の関係の表
明、アクタ間の通信の実行、アクタに対する論理的また
は算術的な演算の実行、または判断による選択の入力の
要求のうちの１つまたはそれ以上からなる。最終的に、
判断の選択が入力装置を介して代わる代わる受信され、
それに応じて、追加のテープ・シナリオが順次実行され
る。 【００２０】このシステムは、作用ステップのシミュレ
ーション中に入力装置を介して受信した命令に応じて、
指定された作用ステップの後にシミュレーションを停止
するようになっている。そして、入力データの受信に応
じて、追加のアクタ・データおよび追加の作用ステップ
をシステムが格納し、その追加のステップおよびアクタ
を含めて、シミュレーションが再開される。対話的に仕
様の追加を行い、それらの追加の結果を直ちに見ること
ができるので、好都合である。作用ステップは、シミュ
レーション中に逆進可能（「アンドゥ可能」）である。 復元（アンドゥ）されたステップは修正されて、シミュ
レーションが再開され、その復元されたステップは、修
正された内容で再びシミュレートされる。仕様の変更を
対話的に行い、その変更結果を直ちに見ることができる
ので、好都合である。 【００２１】作用ステップをシミュレートすることは、
プログラム経路が指定されていない判断箇所の選択を自
動的に識別すること、これらの選択および不完全なプロ
グラム経路を利用者に通知することからなる。また、作
用ステップをシミュレートすることには、アクタ・デー
タが完全であるかどうかを確認し、不完全なデータを利
用者に知らせることも含まれる。このように、不完全な
仕様もシミュレートできるので都合がよい。本システム
では、複数の水準の表示が可能であり、各水準は、シミ
ュレーションの詳細水準に対応する。利用者は、各作用
ステップに対し、異なる水準集合を指定することができ
る。テープ・シナリオを実行する場合、ＧＲＡＳシステ
ムは、その集合の要素である水準にあるステップに限り
、その結果を表示するが、実際には、他の指定された水
準のすべてのステップをシミュレートしている。利用者
は、情報がさらに利用できるようになったときに、より
詳細なステップを仕様に追加し、それらのより詳細なス
テップのシミュレーション結果を見ることによって、仕
様を対話的に洗練することができるので、好都合である
。 【００２２】ＧＲＡＳシステムでは、２つ以上の作用ス
テップを同時にシミュレートすることが許される。本発
明のシステムでは、同時に発生するプログラム経路の両
方に共通のアクタがある場合、その共通のアクタのデー
タにアクセスしようとする他のアクタどうしが、同じデ
ータを同時にアクセスしないことが保証される。本シス
テムでは、そのテープ・シナリオのあるステップのシミ
ュレーションを所定の時間だけ遅らせたり、または最初
の作用ステップシミュレーション時刻からシミュレーシ
ョン中に算出された時間だけ遅らせたり、あるいは最初
の作用ステップのシミュレーションを２番目の作用ステ
ップがシミュレートされるまで遅らせたりすることが可
能である。本システムでは、呼び出されたテープ・プロ
グラムを呼び出しているテープ・プログラムの実行の一
部として実行し、その呼び出されたテープ・プログラム
の実行に続いて、呼び出しているテープ・プログラムに
戻ることも可能である。また本システムでは、第１のテ
ープ・プログラムの第１の作用ステップのシミュレーシ
ョンの後と前記第１のテープ・プログラムの第２のステ
ップのシミュレーションの前との間に、第２のテープ・
プログラムの部分集合のコピーを挿入することも可能で
ある。作用ステップの同時シミュレーションによって、
システムの作用の現実的な考察が与えられる結果、首尾
一貫した仕様が生成され、好都合である。 【００２３】 【実施例】仕様に関するグラフィカルな記憶および動画
（ＧＲＡＳ＝Ｇｒａｐｈｉｃａｌ Ｒｅｃｏｒｄｉｎｇ
ａｎｄ Ａｎｉｍａｔｉｏｎ ｏｆ Ｓｐｅｃｉｆｉ
ｃａｔｉｏｎｓ）のシステムは、この種のシステムにと
って有用な特別な術語体系で記述された主要な概念に基
づく。これらの専門用語を理解することは、ＧＲＡＳシ
ステムの理解に役立つので、ＧＲＡＳで使用される特殊
な専門用語を以下において定義する。 【００２４】重要用語集 バックステージ：所与の制作スタジオに所属する各アク
タ（役者の意）は、その特有のアドレス（例えば、出生
名と住所、社会保証番号）で分かる。一度に利用できる
全アクタの集合をバックステージ（舞台裏の意）と呼ぶ
。各アクタは、仮にそれが幾つかのテープで使用され、
そのＧＲＡＳシステムで現在利用可能なテープの間で物
理的に共有されていても、この文脈においては、ただ１
つの存在でしかない。テープが録音される前かされてい
る間に、１つ以上のスタジオ室を選択することができる
。各スタジオ室は、異なる視野または眺望を記録するの
に使用でき、各スタジオは、記録カメラを持っている。 必要に応じて、記録の前か記録中に、アクタの選択／追
加が行われる。 【００２５】フレーム：フレームは、情報の分類または
概念の組織化に使用される柔軟なデータ構造である。こ
のデータ構造の柔軟性は、フレームが通常、拡張可能か
つ再定義可能であると言う事実からきている。フレーム
・システムは、通常、ＩＳ−ＡまたはＡＫＯ（Ａ−ｋｉ
ｎｄ−ｏｆ）分類法に基づく階層的な継承機構を備えて
いる。 【００２６】アクタ：アクタは、オブジェクトの拡張で
ある。オブジェクトは、データとそれを操作する手続き
（プロシージャ）からなる。アクタは、データを（スロ
ットと値を用いて）オブジェクトととしてカプセルに包
む。しかし、カプセル化された集合のスロットだけでな
く、それらのスロットの値も、時間と共に変化すること
ができ、これらの変化は、可逆的である。隠喩的観点か
らすれば、アクタは、情報の範疇および情報の値を記憶
したり忘れるだけでなく、その寿命期間内の特定の瞬間
にそれが持っていた情報を思い出すことも可能である。 この特徴を実現するために、アクタは、そのデータ空間
（スロットおよび値）に為された変更の履歴をとってい
る。アクタは、任意の時刻にその時点のデータ空間の記
号による記述を生成したり（自己記述）、２つの異なる
時刻における記号的データ空間の間の差の記号による記
述を生成したりすることができる。これらの記述内容は
、アクタ・システムの実施によって、履歴に維持される
。 【００２７】アクタの実施：ＧＲＡＳに対しアクタを実
施することにより、次の可能性がサポートされる。アク
タの一般的な性質として、新たな役割を記憶し、前の役
割を忘れ、存在する情報を変形させ、新たな情報を獲得
し、他のアクタに情報を伝達し、（オプションで）種々
の衣装でいるのが見られる（可視的表現は、このような
アクタにあってもなくてもいい属性である）という能力
がある。アクタは、共有、再利用、合併、分割、幾つか
のアクタの組み合わせとしての生成、またはサブアクタ
への分解が可能である。論理的または算術的な演算に基
づいて、アクタの役割を特定の状況によって変更するこ
とができる。 【００２８】アクタの知識ベース：蓄積（記憶）および
削除（忘却）が可能なアクタの属性の集合が、アクタの
動的で機密性の知識ベースを構成する。ここでは知識ベ
ースの機密性は、次の意味で定義される。即ち、知識は
、他のアクタと共有されておらず、他のアクタが直接利
用することはできない。あるアクタの情報を他のアクタ
が利用できるのは、他のアクタが処理中に明確にそれを
要求した場合に限られる。アクタの知識ベースは、アク
タの環境を用いて定義される。アクタのデータ空間の記
述Ｄ（Ａ，ｔ）の実現。 【００２９】アクタと継承：アクタのフレームの記述に
用いられるＡＫＯ関係は、フレームの分類を与えるため
に内部的に使用される。しかし、ＧＲＡＳにおいては、
利用者がＡＫＯ関係を直接利用することはできない。ア
クタに関し利用できる操作（処理）の集合は、利用者が
多重継承を必要とすることなく通信のアクタ指向モデル
を設計するに十分である。ＧＲＡＳがアクタ・システム
によって半自動的に維持できるならば、継承がＧＲＡＳ
の利用者に与えられるだけである。 【００３０】アクタの合併および融合：アクタ・モデル
では、合併という概念とその実現とによって、さらに柔
軟性が提供される。次のようにいろいろな水準の合併が
可能である。 【００３１】１）改名：アクタのステージ名を新たなス
テージ名で置き換え、そのアクタは同じ規則の集合を使
用する。ここで、ステージ名は、特定のシナリオの実行
において、このアクタを参照するために使用される名称
である。 【００３２】２）アドレスの変更：アクタのアドレス（
識別情報）を変更する。新たなアドレスが既存のアクタ
のアドレスである場合、実際に合併が行われる。 【００３３】３）合併：アクタＡが既存のもう１つのア
クタＢと合併される場合、合併の種類は、結果としての
新たなアクタＣがＢ（属性と関係）になるものから、Ｃ
がＡになったり、ＣがＡおよびＢの属性と関係との組み
合わせになるものまで、連続的に変化し得る。ただし、
何れの場合も、結果として得られるアクタＣは、Ａおよ
びＢのすべての規則を継承している。これらの規則の適
用可能性は、Ｃの結果としての属性と前の規則との関数
である。全く適合しない規則ならば、それらを取り除い
ても良い。規則の管理の一部は、論理的分析および到達
可能性アルゴリズムに基づいて自動化することができる
。 【００３４】４）融合：アクタが第２のアクタに完全に
加えられ融合する（Ｃ＝Ａ＋Ｂ）。これは、完全な合併
の場合である。この結果は、その融合が起こる前に何れ
かのアクタが使用された場所ならどこでも使用される新
たなアクタである。従って、新たなアクタは、両方のア
クタのすべての規則を継承する。また、新たなアクタは
、両方のアクタからすべての関係および構成要素も継承
するという意味では「怪物」である。例えば、端末を普
通の旧式電話サービスの（ＰＯＴＳ）電話と融合する場
合、結果として得られる「怪物」は、端末とＰＯＴＳ電
話との両方の特徴を持った電話端末である。この「怪物
」は、ＰＯＴＳ電話の特徴を持った端末とも、端末の特
徴を持ったＰＯＴＳ電話とも解釈することができる。 この特徴は、新たな設計について実験を行う場合に役立
つ。 【００３５】２つのアクタを合併することは、アクタと
それらの関係から成る２つのネットワークを合併するこ
とになる可能性がある。アクタのネットワーク（アクタ
網）は、関係によって接続された一群のアクタから成る
。例えば、アクタ網は、一種の（ＡＫＯ＝Ａ−Ｋｉｎｄ
−Ｏｆ）関係に基づくことができる。１つのアクタ網（
ＮＡ）が、一種の（Ａ−Ｋｉｎｄ−Ｏｆ）ドイツ人であ
るすべてのアクタから成ることもあれば、別のアクタ網
（ＮＢ）が、一種の（Ａ−Ｋｉｎｄ−Ｏｆ）フランス人
であるすべてのアクタから成ることもある。アクタＡが
一種のドイツ人であり、かつアクタＢが一種のフランス
人である場合、（ＮＡ）と（ＮＢ）との合併は、すべて
のドイツ人がフランス人になるか、すべてのフランス人
がドイツ人になるか、すべてのドイツ人およびフランス
人がフランス系ドイツ人、即ち両人種の組み合わせにな
るかの何れかになる可能性がある。 【００３６】アクタに与えられる合併処理は、動的であ
り、利用者が実行時に呼び出すことができる。さらに、
アクタは、それ自体の属性および関係の変化を記憶する
能力を持っているので、アクタに関する他のすべての処
理と同様に、合併処理を元どうりにする機構（ｕｎｄｏ
）を実行することができる。 【００３７】分解機構を与え、１つの複雑なアクタから
１組のさらに単純なアクタどうしの間の通信機構へと設
計の展開を助けるために、分割作用素を利用できるよう
にする。これは、伝達情報の送信または処理が最小単位
の処理であるから、特に重要である。分割により、伝達
情報をさらに小さな単位の処理へと分解する機構が与え
られる。 【００３８】アクタとオブジェクト：アクタは、メッセ
ージ伝達方法を明確に定義されることがない代わりに、
属性および作用の記憶および忘却、伝達情報の送信およ
び処理、ならびに作用のシミュレーションを行う基本的
な方法を、そのアクタのクラスから継承する。はじめか
ら種々の（所定の）クラスから継承する代わりに、必要
に応じて新たな情報のスロットおよび値を追加なり、変
更なり、削除なりを行って、アクタを累進的に定義・洗
練することができる。比喩的に言えば、あるアクタの「
個性」、即ち一般的な作用は、前もっては分からないが
、このアクタが演じているすべてのテープから実験的観
察に基づいて集められる。アクタは、所定の組の作用に
関して、従来のオブジェクトのように独自に存在してい
るわけではなく、種々の作用がそれらのために利用でき
るようになる種々のシナリオを背景として存在するので
ある。 【００３９】オーディション：所与の作業（タスク）を
行うアクタを選択するために用いられる処理（プロセス
）を指す。アクタは才能によって選択される。ここで、
才能は、アクタの属性（属性は、そのアクタの作用と直
接連絡している）とそのアクタおよび他のアクタの間の
現在の関係的依存状態の集合との関数として定義される
。オーディションの処理（ａｕｄｉｔ）には、アクタの
要員の中から所与の作業を行う適任者を特定することが
伴う。 【００４０】生成（ｃｒｅａｔｉｏｎ）：才能の記述に
従って新たなアクタを生成する処理である。新たなアク
タのデータ構造は、前記の記述に匹敵する内部の属性に
よって作られる。生成処理によって、アクタと関係から
成る集合（アクタ網）を生成する結果になることがある
。才能の記述が空の場合、最小のアクタのデータ構造が
生成される。アクタの才能の記述に特定のアクタのアド
レス（識別情報）が入っている、つまりアクタの才能の
記述の評価結果が特定のアクタのアドレスとなるならば
、そのアドレスにはアクタが既に存在し、そのアクタが
再利用される。 【００４１】破壊：これは、アクタ要員アドレスからあ
るアクタのアドレスを削除し、その履歴を停止し、さら
にそのアクタのデータ構造、他のアクタとの関係および
（オプションで）現在見えている装置からそのアクタの
可視表示を削除する作用である。システムの実現状態の
よって、この処理が「ガーベジ・コレクション」（不要
になったデータの削除）を伴うことがあったり、なかっ
たりする。代用：アクタが作業を完成することができな
い場合、その代わりに代用アクタを選択することができ
る。代用は、オーディション処理を用いて行われる。 【００４２】転送：２つのアクタがある場合、ＡからＢ
への転送は、ＡおよびＢのそれぞれのアドレス（識別情
報）は維持しながら、すべての属性および関係をＡから
Ｂに与えることになる。 【００４３】クローン生成：アクタのクローン生成によ
り、元のもののすべての属性を持つ、そのアクタの新た
なインスタンスが作られる。クローンは、クローンと元
のアクタの何れか一方の属性の中の１つに変更が為され
るまでは（空間を節約するために）元のアクタと属性を
共有することができるが、変更されると、属性は物理的
に分離される。アクタ自体であるアクタの属性は別とし
て、最初は、デフォルトによって、すべての値が、元の
アクタとクローンとの間で共有される。例えば、システ
ムにおいて、あるアクタが２つの属性、即ち送受話器お
よび電話番号を持つ電話であると仮定する。すると、送
受話器もアクタとなり得る。この例において、送受話器
もアクタである場合、この電話をクローン生成すると、
クローンとオリジナル（元のアクタ）は、はじめ電話番
号の値を共有するが、同じ送受話器は共有しない。これ
は、クローンの送受話器の「属性」が新しいアクタだか
らである。値だけが、クローンとオリジナルとの間で共
有されるのであって、アクタは共有されない。 【００４４】アクタをクローン生成すると、ある関係に
よって互いに接続されたアクタ網（例えば、１つのアク
タと、部分の関係（Ｐａｒｔ−Ｏｆ ｒｅｌａｔｉｏｎ
）にあるその幾つかの構成要素と）のクローンを生成す
ることがある。クローンはそのオリジナルとは異なった
アドレスを持つ。クローン生成は、（データが、変更さ
れるまでは再利用されるので）費用のかからないコピー
を作る機構である。 クローンの（オプションの）視覚的表現は、例示された
アクタの名称でのインスタンス番号の追加を除けば、オ
リジナルと同じである。 【００４５】作用規則：ビデオ・スタジオの比喩（ＶＳ
Ｍ＝Ｖｉｄｅｏ Ｓｔｕｄｉｏ Ｍｅｔａｐｈｏｒ）で
は、作用の規則は、（事実の独立した知識ベースとして
使用される）アクタの集合、これらの知識ベースの叙述
子の組み合わせ、アクタ間の通信メッセージの集合、お
よび計算と表明の集合を含めるための、前記の定義の拡
張である。アクタ集合Ａについての作用規則Ｒは、次の
形式を用いて記述することができる。 Ｒ（Ａ）：ｆ（Ｐ（Ａ））＝＞Ｍ（Ａ）＝＞ｇ（Ｑ（Ａ
，Ｍ（Ａ）））ただし、Ａはアクタの集合であり、Ｐ（
Ａ）はアクタに関する叙述子の集合であり、ｆ（Ｐ（Ａ
））は、これらの叙述子の関数（例えば、ブール表現）
であり、Ｍ（Ａ）は、アクタ間の通信のオプションの集
合であり、Ｑ（Ａ，Ｍ（Ａ））は、そのアクタの知識と
通信集合Ｍ（Ａ）から得られる情報とに基づいて集合Ａ
のアクタに対して行われる計算およびその結果としての
表明の集合であり、ｇは、規則Ｒ（Ａ）の完成の尺度と
して用いられる合成関数（例えば、ブール表現）である
。ブール的仮定の下では、Ｒ（Ａ）の実行が成功裏に終
了した場合、ｇ（Ｑ（Ａ，Ｍ（Ａ）））は、真でなけれ
ばならない。 【００４６】Ｒ（Ａ）の定義において、集合Ａは、Ａ＝
ａ１、ａ２、．．．．、のようにあからさまに（即ち、
列挙して）定義することも、抽象的に定義することも可
能である。Ａが抽象的に定義される場合、規則Ｒ（Ａ）
に対するアクタを特定する論理規則の集合Ａ＝Ａｕｄｉ
ｔ｛Ｘ１，Ｘ２，．．．，Ｘｎ｝を用いてＡを記述する
ことができる。これらの論理規則によって、所与の役割
を演じるために各アクタに要求される特性｛Ｘ１，Ｘ２
，．．．，Ｘｎ｝を描写することができる。特性は、ア
クタの属性と値とで構成されたパタン一致表現でよい。 例えば、種類の検査、クラス依存状態の検査、接続種類
の検査（「ａ」と「ｂ」との間にワイヤ接続がるか？）
、または値の照合（この局に８００という電話番号があ
るか？）をアクタの特性に含めることができる。Ｒ（Ａ
）に対する特性の集合によって記述される候補のアクタ
を特定するために、オーディション処理（ａｕｄｉｔ）
が使用される。Ａのアクタを記述する規則によって、新
たなアクタの生成、既存のアクタの再利用または組み合
わせを要求することができる。 【００４７】ＯＯスクリプト：センダ（ｓｅｎｄｅｒ）
のアクタとレシーバ（ｒｅｃｅｉｖｅｒ）のアクタとの
間の単一処理を表すのに使用される特定のフォーマット
およびシンタックスを指す。ＯＯスクリプトは、２つの
アクタの間の単一処理の特定のテキスト表現である。各
ＯＯスクリプトを使用して、１つ乃至２つのアクタを伴
う作用の１つの規則を記述するすることができる。しか
し、ＯＯスクリプトのシンタックスでは、アクタの記述
ができない。ＯＯスクリプトの表現は、先に定義した作
用規則に対する正式な表現の部類に属する。ＧＲＡＳの
実施において、（推論エンジンによって維持される）内
部の規則構造と利用者（または外部のアプリケーション
・システム）との間のインタフェースをとる単純なテキ
スト・フォーマットを与えるために、例えば、ＯＯスク
リプトのタプル（一定数の要素の集合）が用いられる。 【００４８】役割：アクタの役割は、所与の状況におい
てそのアクタに適用されるすべての作用規則の集合であ
る。１つのアクタに対する各作用規則は、他のアクタと
の相互作用を必要とするため、アクタの作用を動的に変
更することが可能である。 【００４９】ＶＳＭにおけるテープ テープ・プログラム：テープ・プログラムには、アクタ
の初期（およびオプション）の集合と、スクリプト規則
の集合またはアクタ間の作用規則を定義する一般スクリ
プトとが入っている。テープ・プログラムは、その実行
に必要なすべてのアクタを備えている場合、アクタ妥当
（ａｃｔｏｒ ｃｏｒｒｅｃｔ）であると言う。同様に
、テープ・プログラムは、その実行に必要な作用規則を
備えている場合、規則妥当であると言い、その実行に必
要なテープ・プログラムへの参照情報をすべて備えてい
る場合、サブテープ妥当という。テープ・プログラムに
は、その実行に必要なすべてのアクタおよびすべての規
則（または他のテープ）が掲げられている。スクリプト
規則または一般スクリプトを用いて初期のアクタを生成
することができるので、テープ・プログラムは、初期の
アクタの空集合を持つこともある。 【００５０】テープ・シナリオ：テープ・プログラムの
実行によって、１つ以上のテープ・シナリオが演出され
る。テープ・シナリオは、シナリオの変形に対応する元
のテープ・プログラムからの所与の集合のスクリプト規
則の実行履歴である。 【００５１】テープ：テープを構成するのは、未来のリ
ール、即ちテープ・プログラムおよび（１つ以上の実行
済みのテープ・シナリオからなる）過去のリールと言う
２つのリール、テープ・カウンタ、初期アクタのオプシ
ョン集合、その視覚化に必要なオプションの多重視野の
記述、および参照と参考情報の利用に使用される追加的
な情報である。未来のリールは、利用可能な作用の集合
を表し、過去のリールは、そのテープの実行の履歴を表
す。過去のリールには、前に使用された規則のインスタ
ンス、それらの規則に関与したアクタの履歴が入ってい
る。テープ・カウンタは、そのテープ（過去のリール）
において既に実行されたステップ数に対する模擬計数（
または回数）を示す。テープが完全に巻き戻されると、
過去のリールは空になる、つまり実行の履歴が失われ、
未来のリールには、それまで得たすべての規則の集合が
入る。 【００５２】テープのクラス：テープのクラスによって
、ビデオ・テープまたはフィルムの編集の類似性に基づ
いて半自動（支援付き）プログラム操作をサポートする
のに必要な計算体および作用素のクラスが規定される。 【００５３】テープ・シェルフ：テープ・シェルフは、
テープの集合である。 【００５４】伸縮可能テープ：テープは、スーパー８ム
ービーのように編集、切断および張り合わせができるの
で、何本かのテープを１本にまとめ組み合わせるだけで
なく、スクリプトおよび作用を容易に変更することもで
きる。テープは、特定の通信について新たな情報や詳細
をさらに受信するために、録音中に自動的に延長される
。また、ＧＲＡＳシステムによって生成されたり利用者
の入力に応じた追加的なスクリプト規則を２つの既存の
ものの間に挿入する余地を与えるために、テープは自動
的に延長される。テープの実現により、いろいろな詳細
水準での多重（各テープは、多重トラックを有する）録
音がサポートされる。ＶＳＭでは、録音によって既存の
スクリプトがテープから消去されるのではなく、新たな
スクリプトが既存のスクリプトの間に挿入される。スク
リプトの削除は、切断またはスクリプト規則を削除する
ためのメニュー選択（コマンド）によって行われる。 【００５５】テープの切断：テープの切断は、現在の位
置（シミュレートされた時刻）で起こり、それ自体で有
効な２つのテープを生成する。テープを切断するには、
フィルム・エディタを選択する。切断後、これらのテー
プは、共にテープ・シェルフに格納される。テープは、
切断される前にコピーが取られる。テープを切断すると
一方の側に未来のリールを追加し、他方の側に過去のリ
ールを追加することによって、自動的に修復された２つ
の半分のテープが作られ、２つの新たな実行可能なテー
プが出来る。利用者は、新たな２つのテープを指名する
ように促される。 【００５６】テープの接合：テープの接合は、２つ以上
のテープを一続きのテープに継ぎ合わせる。テープを接
合するには、フィルム・エディタを選択する。テープは
接合される前にコピーされ、第１のテープの過去のリー
ルおよび第２のテープの過去のリールは、解かれないな
くてもよい。次ぎに、第１のテープの最後が、他方のテ
ープの先頭に接合され、この処理の間に、２つの余った
リールは消滅する。 【００５７】利用者は、２つ以上のテープを一緒に接合
することができる。いくつかのテープを接合すると、そ
れらのテープの内部表現は同一でも、順次シミュレーシ
ョン・モードで映されるテープは連続実行となり、同時
シミュレーション・モードでは並列実行となる。 【００５８】テープの照会：テープの照会により、アク
タおよび伝達情報の部分的な記述が記録されたテープが
参照される。部分的な記述は、事前条件、事後条件およ
びメッセージに対するオーディション表現およびパタン
・マッチング表現とすることができる。スクリプト構造
体についてのパタン・マッチングによって所与の集合の
スクリプト規則から同様の伝達情報を検索するために、
テープの照会によるアクタ間の通信が使用される。 【００５９】内部テープ呼び出し：現在のテープを実行
しながら、テープ・シェルフから直接テープ（サブテー
プ）を呼び出すこと。呼び出しは、現在のテープにおけ
るスクリプト規則に対する事後条件が契機となる。そし
て、現在のソフトコーダ（ＳＯＦＴＣＯＤＥＲ）の状況
下で実行されるテープのインスタンスが生成される。現
在使用されているアクタ・システムは、設計者の裁量で
サブテープによって再利用されることもあれば、されな
いこともある。そのサブテープが、呼び出しているテー
プで使用されているアクタを特に参照する場合、このア
クタは再利用される。再帰的なテープ呼び出しは、現在
のテープの特別な例であるか、またはそれ自体を呼び出
しているサブテープの特別な例である。 【００６０】テープ・コンパイラ：これは、編集および
ウンドゥの可能な損害に対するさらに効率的な実行を与
えるテープを定義するシステム規則の集合に関する処理
機構である。結果は、コンパイル（編集）されたテープ
である。テープ・コンパイラは、アクタのグラフィック
表現、ならびにそのテープ内のアクタ間の通信および接
続のグラフィカルな副作用を除去することにより、より
効率的な実行を与えることができる。また、テープ・コ
ンパイラは、最適化のためにテープのスクリプト規則の
集合を修正し、高速実行のためにスクリプト規則の前計
算されたラチスを生成する。 【００６１】ビジュアルな照会：これは、照会を定式化
してテープ・シェルフから情報を検索するために設計さ
れた対話的かつビジュアルな処理の集合である。同様の
機構は、標準のテープの録音に使用されるビジュアルな
照会を定式化するのにも、テープの照会が生成されたの
ちテープ・シェルフからのテープの一部に照合されると
言う点を除いて、使用される。テープ・シェルフに適用
される照会結果は、対のリストを伴ったテープの順序集
合である。各対は、候補との一致の信頼値である数およ
びテープ・プログラムにおけるその候補のある位置への
ポインタからなる。ビジュアルな照会の結果として、利
用者は、候補との一致が成功した位置の付近の各テープ
のグラフィカルなシミュレーションを調べることができ
る。これは、設計情報の検索および既存のものから新た
な設計を組み立てるのに役立つ。 【００６２】ＶＳＭにおけるアクタ ＶＳＭにおいて、アクタは、劇および映画の制作の場合
と同様の概念を表す。バックステージにあるアクタの要
員の中からアクタを利用することができる。アクタは、
必要に応じて（新たに）生成したり、前に生成したアク
タの要員から得たりする。アクタは、生活（存在）し、
演じ（上演し）、そして死ぬ（破壊される）。さらに、
アクタは、コンピュータの実体であるから、それらの複
写、再利用、合併、分離、および置換が可能である。あ
るスクリプトに対してアクタを大まかに定義することが
できるが、この場合のオーディション処理（ａｕｄｉｔ
）は、適切な特性のアクタを要員から選択するように行
われる。ユーザの視点からすれば、アクタは、知識を蓄
え、それを利用し、さらに計算を行う非常に柔軟性のあ
る作用主体として見えなければならない。 【００６３】アクタは、ゼロ、または１つ以上のテープ
の構成員であり得る。テープには、そのテープのシミュ
レーションから得られるシナリオにおいて演じるすべて
のアクタのアドレスが表として掲げてある。このリスト
は時間で変化する。ＶＳＭでは、テープは元来、例から
作られている。例によって作用が構成されると言うこと
は、テープの録音中に、アクタの特定のインスタンスが
生成されて使用されることを意味する。 【００６４】スクリプトの構造 ＧＲＡＳシステムにおける作用の規則を実施するために
使用されるデータ構造は、つぎのような形式である。Ｓ
ａｄｄｒｅｓｓ＝（Ｔｙｐｅ，Ｓｉｄ，Ｇｒｏｕｐ−Ｓ
ａｄｄｒｅｓｓ，Ｐｒｅ−Ｓａｄｄｒｅｓｓ，Ｐｏｓｔ
−Ｓａｄｄｒｅｓｓ，Ｓｅｎｄｅｒ，Ｓｕｎｄｏ，Ｒｅ
ｃｅｉｖｅｒ，Ｒｕｎｄｏ，Ｐｒｅｃｏｎｄｉｔｉｏｎ
ｓ，Ｍｅｓｓａｇｅ ａｎｄ Ａｒｄｕｍｅｎｔｓ，Ｐ
ｏｓｔｃｏｎｄｉｔｉｏｎｓ，Ｄｏｃｕｍｅｎｔａｔｉ
ｏｎ）．スクリプトの引数は、次のように定義される。 【００６５】「Ｓａｄｄｒｅｓｓ」は、所与のプロセッ
サにおけるスクリプト構造体のアドレスである。スクリ
プト構造体がいくつかの独立したプロセッサ上に分散し
ている場合、Ｓａｄｄｒｅｓｓは、プロセッサのアドレ
スを与える接頭語（例えば、ＳａｄｄｒｅｓｓをＰｒｏ
ｃＡｄｄｒｅｓｓ：Ｓａｄｄｒｅｓｓとする）を持つこ
とができる。 【００６６】「Ｔｙｐｅ」は、Ｒｕｌｅ（規則）、Ｇｅ
ｎｅｒａｌ（一般）、Ｉｎｓｔａｎｃｅ（インスタンス
）、Ｇｒｏｕｐ（グループ）、Ｗａｉｔ（待機）、Ｕｎ
ｄｏａｂｌｅ（アンドゥ不能）、Ｓｅｎｔ（送信済み）
、Ｐｒｅｃｅｓｓｅｄ（処理済み）などのスクリプトの
型の合法的な組み合わせである。この型は、スクリプト
の型の記述に従ってスクリプト構造体を処理するために
、推論エンジンによって使用される。Ｒｕｌｅ、Ｇｅｎ
ｅｒａｌおよびＩｎｓｔａｎｃｅの各型は、Ｇｒｏｕｐ
型と共に組み合わせることができる。Ｉｎｓｔａｎｃｅ
型およびＷａｉｔ型は、Ｕｎｄｏａｂｌｅ型と組み合わ
せることができる。Ｉｎｓｔａｎｃｅ型は、Ｓｅｎｔ型
またはＰｒｏｃｅｓｓｅｄ型と組み合わせることができ
る。 【００６７】Ｓｉｄ：これは、他のスクリプト構造体に
おける記号（シンボル）による参照および利用者への記
号表現に使用される識別子である。 【００６８】Ｇｒｏｕｐ−Ｓａｄｄｒｅｓｓ：スクリプ
ト構造体がグループ型である場合、そのグループの構成
員であるスクリプト構造体の集合を参照するのに使用さ
れる。 【００６９】Ｐｒｅ−ＳａｄｄｒｅｓｓおよびＰｏｓｔ
−Ｓａｄｄｒｅｓｓ：これらは、他のスクリプト構造体
へのＳａｄｄｒｅｓｓ（複数）の構造体である。それは
、特定のアーキテクチャに対するＧＲＡＳの働きを高め
る効率的な実行機構の設計を支援するために使用される
。例えば、スクリプト構造体ＳのＰｒｅ−Ｓａｄｄｒｅ
ｓｓは、Ｓの実行の直前のスクリプト構造体のアドレス
であり、Ｐｏｓｔ−Ｓａｄｄｒｅｓｓは、Ｓの実行に直
に続くスクリプト構造体を示す。これによって、スクリ
プト構造体のいくつもの大きな集合の実行を効率的に実
施したり破棄したりするためのラチス構造が与えられる
。 【００７０】ＳｅｎｄｅｒおよびＲｅｃｅｉｖｅｒ：こ
れらは、このスクリプト構造体におけるセンダのアクタ
およびレシーバのアクタを参照する表現である。そのス
クリプトの型によって、この表現は、異なって解釈され
る。 【００７１】ＳｕｎｄｏおよびＲｕｎｄｏ：これらは、
スクリプト構造体の実行によってセンダのアクタおよび
レシーバのアクタに対しそれぞれ行われた変更をすべて
復元するために必要とされる処理の集合を記述する表現
である。ＳｕｎｄｏおよびＲｕｎｄｏは、Ｒｕｌｅ型お
よびＧｅｎｅｒａｌ型のスクリプト構造体に対しては、
空である。 【００７２】Ｐｒｅｃｏｎｄｉｔｉｏｎ（事前条件）：
事前条件の表現は、関数と、現在のシミュレーション時
刻におけるスクリプトのアクタの属性に関する論理検査
との組み合わせ（例えば、ブール表現）である。センダ
のアクタおよびレシーバのアクタに基づく事前条件によ
って設計を簡単にすることは許されるが、好ましい方法
は、センダのアクタに関する事前条件およびレシーバの
アクタに関する事前条件を分離することである。レシー
バについての情報にアクセスするためには、まずレシー
バに要求を送る必要があり、その応答の結果を次の規則
の事前条件において使用しなければならない。アクタの
集合がスクリプトを実行している各プロセッサ上では、
必要であればクロックが利用でき、そして、そうならば
、スクリプト構造体の有限な実行履歴が維持される。こ
れらの仮定の下で、事前条件に時間従属関係を含めるこ
とができるが、これは、時間作用素および他のスクリプ
ト構造体の実行時間を用いて形成されたタイミング表現
である。タイミング表現は、スクリプト構造体の実行を
（それらに特有のスクリプト識別子に基づいて）指示す
るのに使用される。ＧＲＡＳの実現においては、シミュ
レートされた時間の強制は、ＯＯスクリプトの表記に基
づく。 【００７３】Ｍｅｓｓａｇｅ ａｎｄ Ａｒｇｕｍｅｎ
ｔｓ（メッセージと引数）：「Ｍｅｓｓａｇｅ」は、セ
ンダのアクタとレシーバのアクタとの間で渡されるオプ
ションのメッセージのシンボル名である。メッセージは
、アクタ間で情報を伝達するために使用される。引数が
指定されるとき、引数は、センダのアクタからのデータ
に基づいて、任意のデータの集合または計算式から成る
。 【００７４】Ｐｏｓｔｃｏｎｄｉｔｉｏｎｓ（事後条件
）：属性の初期値に施された計算に基づいて、さらにレ
シーバのアクタの場合は、計算されたりそのレシーバに
渡されたメッセージを介して転送されたりしたデータに
基づいて、アクタの属性に対して行われた変更が、事後
条件の表現によって記述される。Ｐｏｓｔｃｏｎｄｉｔ
ｉｏｎｓは、センダのアクタに対する事後条件表現とレ
シーバのアクタに対する事後条件表現とに分解する方が
好ましい。 Ｄｏｃｕｍｅｎｔａｔｉｏｎ：スクリプト構造体の機能
の解説に使用されるフィールドである。ドキュメンテー
ションには、そのスクリプト構造体の全アクタおよびそ
れらの属性およびデータへのシンボルによる参照情報を
含めることができる。ドキュメンテーションは、少なく
ともテキストによる記述であるが、実現方法によっては
、グラフィックス、ビデオおよびオーディオを使用して
も良い。 【００７５】事前条件において検査されるか、事後条件
において変更されるアクタの属性により、アクタの間の
関係（センダのアクタとレシーバのアクタとの間の関係
）を表すことができる。さらに、外界と共に入出力関数
を実行する項目（例えば、利用者に質問することなど）
は、事前条件、メッセージおよび事後条件において受け
付けられるが、事後条件以外では受け付けないことを推
奨する。事前条件はすべて並列的に検査され、メッセー
ジの属性はすべて並列的に通信され、事後条件は、すべ
て並列的に実行される。このため、アクタには並列的な
通信モデルが強いられる。連続的な実行が望ましい場合
には、別個のスクリプトと連続したスクリプトグループ
が用いられる。 【００７６】スクリプトの型 スクリプト規則：Ｒｕｌｅ型のスクリプト構造体は、例
示されたセンダのアクタおよびレシーバのアクタを持た
ないが、代わりに、シンボル名または１つのアクタ・ア
ドレスに評価される表現を用いてアクタを参照する。こ
れは、生成、再利用、または多くとも１つのアクタ・ア
ドレスに戻るアクタ処理によって、行うことができる。 スクリプト規則は、実行されるスクリプトではないので
、維持するべきアンドゥ情報がないため、空のＳｕｎｄ
ｏフィールドおよびＲｕｎｄｏフィールドを有する。 【００７７】一般スクリプト：一般（Ｇｅｎｅｒａｌ）
型のスクリプト構造体では、そのアクタを指定するため
にオーディション表現を用いる。センダとレシーバは、
アクタ・アドレス（センダ・アドレスおよびレシーバ・
アドレス）の対の集合を生成する２つのオーディション
表現を指定する。一般スクリプトは、空のＳｕｎｄｏフ
ィールドおよびＲｕｎｄｏフィールドを有する。 【００７８】スクリプト・インスタンス：インスタンス
型のスクリプト構造体は、スクリプト規則または一般ス
クリプトの例示によって生じる。スクリプト規則の場合
、センダおよびレシーバがそれらのアドレスによって特
定されると、センダのアクタおよびレシーバのアクタが
それらのアドレスによって置き換えられる場合、スクリ
プト・インスタンスが生成される。一般スクリプトの場
合、アクタ・アドレスの各対に対応してスクリプト・イ
ンスタンスの集合が生成される。スクリプト・インスタ
ンスは、実行されると空でないＳｕｎｄｏおよびＲｕｎ
ｄｏフィールドを有する。これらのフィールドには、ス
クリプト・インスタンスを一度実行することの影響を元
に戻すために終えなければならない処理が記述されてい
る。 【００７９】スクリプト・グループ：スクリプト構造体
の集合を直接参照するスクリプト構造体である。例えば
、オーディション処理が１つ以上のアクタ対（例えば、
通信放送）を返す場合、一般スクリプトはグループ・ス
クリプトに例えることができる。並列実行のため、スク
リプト・インスタンスも推論エンジン（ソフトコーダ（
ＳＯＦＴＣＯＤＥＲ））によって自動的にグループ化さ
れる。 スクリプト規則の実行を同じプロセッサにさせるために
グループを定義することも可能である。例示されたスク
リプト・グループは、空でないＳｕｎｄｏフィールドお
よびＲｕｎｄｏフィールドを有する。 【００８０】待機スクリプト：シミュレートされた時間
の期間中に実行を遅らせるためにソフトコーダによって
生成されるスクリプト構造体である。これは、シミュレ
ーション時間のある期間中に実行可能なスクリプトが無
いこともあり得るので、必要である。例えば、送信され
るメッセージは、受信され処理される前に数単位分のシ
ミュレートされた時間を要することがある。また、メッ
セージが受信されても、後まで処理できなかったりする
。 【００８１】アンドゥ不能スクリプト：実行が終了しか
つ逆に実行される（元通りにされる）べき必要なＳｕｎ
ｄｏおよびＲｕｎｄｏ表現を持つ待機スクリプトまたは
スクリプト・インスタンスである。Ｓｕｎｄｏ表現また
はＲｕｎｄｏ表現により、スクリプト・インスタンスが
最初に実行されたシミュレーション時刻以降に変更され
たすべてのスロットおよび値が、対応するアクタのデー
タ空間から削除される。スクリプト・インスタンスが実
行される前に存在していたスロットおよび値は、これに
よって回復される。 【００８２】ＧＲＡＳシステムの説明 図１は、ＧＲＡＳシステムの概念的構造図である。ビデ
オ・スタジオ・メタファ（ＶＳＭ）インタフェース・モ
ジュール１００は、単一統合メタファの下でのシステム
設計およびシミュレーションの環境全体に対する簡単な
ユーザ・インタフェースと直接アクセスとを提供するた
めのソフトウェア・モジュールである。ＶＳＭにより、
利用者は、ビジュアル・プログラミング技法を用いてシ
ステム作用の例をテープ・シナリオへと記録し、さらに
グラフィカルな動画的シミュレーションおよび実行をと
おして指定されたシステムの作用の視覚的フィードバッ
クを維持しながら、それらの例をテープ・プログラムへ
と組み合わせかつ洗練させることができる。利用者は、
ＶＳＭにおけるビデオ・コネクタおよび種々のエディタ
（フィルム・エディタ）の使用によって、設計案の補足
、通信、編集、および結合を行うことができる。 【００８３】また、ＶＳＭモジュールは、このシステム
の利用者に対し必要な仕事を行うために、より低い水準
の適切なＧＲＡＳモジュールを呼び出すことができる。 ビジュアル・オブジェクト網管理（ＭｏＶｏｎ＝Ｍａｎ
ａｇｅｍｅｎｔｏｆ Ｖｉｓｕａｌ Ｏｂｊｅｃｔ Ｎ
ｅｔｗｏｒｋｓ）モジュール（ＭＯＶＯＮ）１１０、ソ
フトウェア・ビデオ・レコーダ（ソフトコーダ）モジュ
ール（ＳＯＦＴＣＯＤＥＲ）１２０、およびビデオ・コ
ネクタ（ＶＣ）モジュール（ＶＣ）１３０から成る次の
水準のモジュールは、利用者に対し透過的である。ＶＳ
Ｍインタフェースは、双方向メッセージ・リンク（１１
１、１２１、および１３１）を介して、これらのモジュ
ールと通信を行う。 【００８４】ビジュアル・オブジェクト網管理（ＭｏＶ
ｏｎ）は、システムの構成要素および構成要素網の視覚
化を多重表示、多重階層、および多重詳細水準でサポー
トするアクタの実現である。ビジュアル・オブジェクト
網管理モジュール（ＭＯＶＯＮ）１１０は、その関数を
実行するために、アクタ・フレーム・モジュール（ＡＦ
）１４０、およびプレスクリプト・モジュール（ＰＲＥ
ＳＣＲＩＰＴ）１６０を要請する。 【００８５】ソフトコーダ・モジュール（ＳＯＦＴＣＯ
ＤＥＲ）１２０は、アクタの処理および通信を記録し、
かつシミュレートまたは実行するビジュアルな機構であ
る。ソフトコーダ・モジュール１２０により、単一また
は複合の画面上の対話によって供給される指定事項を記
録（入力）、再生（実行）およびアンドゥ（逆向きの実
行）を行う一般的な機構が提供される。これらの対話は
、情報の転送および計算を伴うアクタ間の通信を表す。 ソフトコーダのビジュアルな機構は、アクタ間の作用の
規則を記述するテープ・プログラムを処理し、アクタお
よび規則を例示し、さらにこのシステムの実行の完全な
軌跡であるテープ・シナリオを生成する。テープ・プロ
グラムにおける各実行段階において、１組の処理が実行
される。各段階は、それをアウドゥすることによって逆
戻りすることができる。 【００８６】また、ソフトコーダのビジュアルな機構は
、アクタの通信および状態の変化をとらえ、シュミレー
トする。ソフトコーダは、録音中に、メニューによる視
覚的な対話（アクタの処理の記録）をとおして利用者に
よって与えられる特定の例からソフトウェア区分を一般
的な作用規則へと自動的にコード化する。各作用規則は
、利用者からの入力と対話する専用のソフトウェア・ル
ーチン群によって対話的に洗練され（特殊効果）、別の
状態を記録する場合には、再利用および変更を容易に行
うことができる。 【００８７】各段階の連続的な実行により、その例が、
入力されたとおりに再生される。その例によって記述さ
れた作用は、作用をすべて予め確かめられる状態で記述
するプログラムへと対話的に洗練される。作用のアクタ
および規則は、アクタの状態、通信中に実行された計算
および交わされた情報に関する他の情報を変更したり、
削除したり、あるいは追加したりするために、いつでも
編集することができる。利用者の裁量によって、アクタ
の状態およびグラフィカルな表現の変更は、永久的にも
一時的にもなる（反転可能）。結果的に得られる規則は
、実際にテープ・プログラムを形成する。 【００８８】ビデオ・コネクタ・モジュール（ＶＣ）１
３０は、利用者にプログラム対話、編集、ならびにファ
イル・システムおよびＧＲＡＳの外部の他のシステムへ
の接続のための機構を利用者に提供する。モジュール１
３０は、ソフトコーダによって使用される内部テープ表
現のための一般的な変換および通信の機構である。モジ
ュール１３０は、利用者による読み出しおよび編集、ま
たは外部システムとの通信のうち何れかが可能なテキス
ト形式でテープ、アクタおよびスクリプトを示すのに使
用される。モジュール１３０により、ＧＲＡＳとファイ
ル・システムとの間の双方向接続機構、およびＧＲＡＳ
と外部システムとの間の双方向接続が提供される。提供
されるコネクタの例としては、ＯＯスクリプト、メッセ
ージ、テープ、アクタ（オブジェクト）、スクリプト、
およびアイコンがある。ビデオ・コネクタを介して外部
のシステムに接続されると、外部のシステムは、ＧＲＡ
Ｓの実行を遠隔制御できるだけでなく、ＧＲＡＳを調べ
ることができる。 【００８９】プレスクリプトは、ＧＲＡＳの一部で、ア
クタおよび伝達情報の表示およびアニメーションのため
のグラフィカルなプログラミング言語である。プレスク
リプト・モジュール１６０は、アクタの視覚的な表現を
担う。アクタ（アクタ＝視覚的なオブジェクト＋フレー
ム＋作用）を定義するために、視覚的なオブジェクトは
フレーム表現に関係付けられる。視覚的なオブジェクト
はコンピュータ端末上に表示される。視覚的なオブジェ
クトは、他の視覚的なオブジェクトと合併することがで
き、シナリオ（またはシナリオの集合）を定義するテー
プの構成員であるだけでなく、テープ・フレームの構成
員でもある。プレスクリプト・モジュール１６０は、Ｏ
Ｓ１７５によって与えられるウィンドウおよびグラフィ
ックの諸機能（ＷＧ）１７０を利用する。 【００９０】アクタ・フレーム・モジュール（ＡＦ）１
４０は、フレームおよびアクタの知識の時間的履歴を支
持する知識表現および記憶の機構である。アクタ・フレ
ームは、フレーム・オブジェクト言語および実行環境（
ＦＯＬＩＥ）に基づく。ＦＯＬＩＥは、ＧＲＡＳシステ
ムの一部であり、フレーム・ベースの分離（分散）およ
び分散された部分集合からの合併によるフレーム・ベー
スの再構築、多数の階層およびローカル・クラス優先リ
スト、および多数の階層におけるメッセージの放送をサ
ポートするフレーム表現言語である。放送されたメッセ
ージが、方法、関数、手続き、またはコンパイルあるい
は変換された形式のラムダ表現への参照情報から成る場
合、それは、少なくとも１つの関数引数と共に、その階
層における現在のフレームと称する。ラムダ表現は、必
要な引数（例えば、現在のフレーム）と共にそれが呼び
出されると仮定した場合、その実行に必要なすべての環
境変数を備えた、独立型のコンピュータのコード・セグ
メントである。 【００９１】ＧＲＡＳシステムにおいて、テープの実行
機構は、アクタの動的な属性に基づく。テープの編集処
理は、アクタの静的な属性と動的な属性との組み合わせ
に影響を与える。静的な編集の柔軟性は、アクタ・フレ
ーム・モジュール１４０の一部であるＦＯＬＩＥモジュ
ールによってサポートされる。ＦＯＬＩＥモジュールは
、次の関数からなる。即ち、（１）シンボルによる自己
記述：伸長性で型指定が無く、フレーム集合のシンボル
による自己記述は順序依存的であり、フレーム間のすべ
ての依存関係は２重リンクを用いて自動的に維持され、
そのフレーム要素からのフレーム集合の定義は、任意の
順序で行うことができる。（２）多元的継承：フレーム
がそのすべての母体から性質の統一体（集合）を受け継
ぐことができる。（３）継承の多重階層性：フレームは
、ＡＫＯ階層、ＰＡＲＴ−ＯＦ階層、またはその化の任
意の関係から、性質を継承することができる。 （４）所与の階層のフレームに対する母体の順序集合か
ら成るローカル・クラス優先リスト（ＬＣＰＬ）：多重
階層性により、多数のＬＣＰＬがもたらされる。（５）
フレームの放送：所与の階層のすべてのローカル・クラ
ス優先構成員に作用素を放送（一斉送信）することがで
きる。（６）フレーム網の統合：他のフレームとの関係
のネットワークの内部でフレームが定義される。各フレ
ームは、自己記述的である、即ち、フレームは他のフレ
ームとの関係網をシンボル的に記述する。他のフレーム
がない場合でもフレームの統合が可能である。（７）フ
レーム網の合併：フレームのオブジェクトを共有する２
つのフレーム網は、同一のシステムの中でリンク（ロー
ド）されると、自動的に合併される。（８）再利用、結
合、上書きおよび忘却という４種類の合併の原型を備え
たフレームの合併。（９）フレームの転送：これにより
、フレーム網の一貫性を維持しながら、フレームを他の
フレームによって全体的に（グローバルに）置換するこ
とが可能となる。交換用のフレームが既に存在する場合
、転送は、合併によって行われる。この機能により、ア
クタの交換およびアクタの合併に対する支持が与えられ
る。 【００９２】ウィンドウおよびグラフィックス・システ
ムのモジュール（ＷＧ）１７０（商業的に入手可能なＸ
Ｗｉｎｄｏｗ ＳｙｓｔｅｍＴＭ、ＳｕｎＶｉｅｗＴ
Ｍ、シンボリックス（Ｓｙｍｂｏｌｉｃｓ）社のＧＥＮ
ＥＲＡ（登録商標）のウィンドウと類似）により、ＧＲ
ＡＳに視覚的な能力が与えられる。Ｃｏｍｍｏｎ Ｌｉ
ｓｐ（ＣＬ）１８０は、ＡＮＳＩ Ｘ３Ｊ１３委員会（
準備中のＣｏｍｍｏｎ Ｌｉｓｐのための全米規格）の
仕様に従うＣｏｍｍｏｎ Ｌｉｓｐ言語を実現したもの
である。ＧＲＡＳでは、実行可能なサイズを小さくする
ために、ＣＬのサブセットが用いられる。ＣＬのサブセ
ットは、ＧＲＡＳを実行するのに必要なＬｉｓｐ関数の
みから成り、ＧＲＡＳ全体のコードを調べ、そのコード
において参照されたすべての関数を集めることによって
生成されている。その他のコンピュータ言語でも、ＡＮ
ＳＩ仕様による定義と類似の機能を与える限り、ＣＬと
置き換えることができる。 【００９３】オペレーティング・システム（ＯＳ）１７
５は、コンピュータのオペレーティング・システムであ
り、（オプションにより）統合化された環境（例えば、
ＵＮＩＸ（登録商標）、シンボリックス社のＧＥＮＥＲ
Ａ（登録商標））である。ＵＮＩＸは、ＡＴ＆Ｔの登録
商標である。ＧＥＮＥＲＡは、シンボリックス社の登録
商標である。ＯＳは、次の構成要素の実行の制御および
維持を行う。即ち、ＷＧ（１７０）、ＣＬ（１８０）、
ＦＳ（１８５）およびＮＷ（１８６）である。 【００９４】ファイル・システム（ＦＳ）１８５は、静
的なデータ記憶および検索のためのアクセス機構を実現
する構成要素である。これは、ＵＮＩＸのファイル・シ
ステムを基にしている。 【００９５】ハードウェア（ＨＷ）１７６は、データ（
シンボル、オブジェクト、データーベース）を操作し、
論理演算および算術計算を行う１つ以上のプロセッサ、
およびデータの記憶および検索に使用される１つ以上の
記憶用の機構および装置から成る（記憶装置は、静的な
ものや動的なものがあり、シーケンシャル・アクセスで
あったり、ランダム・アクセスであったりする）。 ハードウェアの必要条件は、ここで定義されるＧＲＡＳ
のすべての構成要素の実行を支持するに十分なデータ記
憶装置および処理能力を与えることである。ＧＲＡＳの
実現および頒布のために適切であると分かった現在入手
可能なコンピュータ・ハードウェアには、次のものがあ
る。ＡＴ＆Ｔの６３８６ＷＧＳ、ＡＴ＆Ｔのグラフィッ
クス端末またはＸ Ｗｉｎｄｏｗ端末を付けた他のＵＮ
ＩＸコンピュータ・メインフレーム、サン・マイクロシ
ステムズのＳｕｎ−３およびＳｕｎ−４シリーズ、イン
テル８０３８６ベースのパーソナル・コンピュータ、シ
ンボリックスの３６００（登録商標）およびＸＬシリー
ズ、ゼロックス１１００シリーズ、テキサス・インスツ
ルメンツＥｘｐｌｏｒｅｒｓ（登録商標）、およびデジ
タル・エクイップメント・コーポレーションのＤＥＣ２
０００および３０００シリーズ。 【００９６】（オプションの）ネットワーク（ＮＷ）１
８６は、ＶＳＭベースのシステムの集合の間でデータ通
信を提供するために、ＨＷ構成要素と共に利用できるか
、またはそれに付け加えて利用できるハードウェアおよ
びソフトウェアの要素を備えている。現在利用可能で適
切なネットワーク技術には、モデム付きの電話回線、イ
ーサネット、ＡＴ＆Ｔ ＳＴＡＲＬＡＮ、広帯域パケッ
ト網がある。ネットワーク要素は、ＶＳＣデータを電気
的に伝達する（例えば、テープ・プログラムを離れた場
所で利用する）ために必要とされるに過ぎない。 【００９７】図１に示したように、ＶＳＭモジュール１
００は、ＭＯＶＯＮ、ソフトコーダおよびＶＣへ双方向
の接続を持っている。（ＶＳＭからの）直接の接続は、
１）アクタおよびアクタ処理（ＭＯＶＯＮ）、２）スク
リプトおよびテープ・プログラムの視覚的な記録、洗練
、およびシミュレーション（ソフトコーダ）、ならびに
３）外部のテープ・プログラムだけでなくテキスト形式
のテープ・プログラムの編集（ＶＣ）、に対する利用者
の制御およびアクセスを表す。ＶＣと外部のシステムと
の間に存在する（オプションの実行時の）双方向接続は
、図には表していない。（ＭＯＶＯＮ、ソフトコーダま
たはＶＣから）ＶＳＭへの接続は、ユーザ・インタフェ
ースの表示へのビジュアルなフィードバックおよびテキ
ストのフィードバックを意味し、表示画面上の１つ以上
の視覚表現に変化をもたらす。このフィードバック・ル
ープは、実際にはＭＯＶＯＮ−ＰＲＥＳＣＲＩＰＴ−Ｗ
Ｇを通る共通経路によって実現され、すべてのグラフィ
カルな変化は、アクタの視覚的表現に対する変化として
実現される。また、ＶＳＭは、利用者によって制御され
る指示装置およびキーボード装置にＷＧ経由で接続され
る。ＶＳＭモジュールは、図示されていない利用者から
直接の入力を受信する。同じ入力をＶＣ遠隔制御機能に
よって外部のシステムから受信することも可能である。 ソフトコーダおよびＶＣは、スクリプト、テープ・プロ
グラム、およびテープ・シナリオのほか、ソフトコーダ
制御コマンド（例えば、テープのロード、テープの削除
、詳細水準の変更、ビューの変更など）も送信する。Ｍ
ＯＶＯＮおよびソフトコーダは、アクタおよびアクタの
内容を送る。ＭＯＶＯＮは、ＰＲＥＳＣＲＩＰＴにアク
タのビジュアル・オブジェクトを要求し、ＡＦにアクタ
・フレームを要求することができる。ＶＣは、ＦＳおよ
び外部システムへの接続をＣＬおよびＦＳまたはＮＷを
介して要求することができる。ＰＲＥＳＣＲＩＰＴは、
ＷＧを介して表示の変更を求めることができ、ＣＬを介
してプリスクリプト・オブジェクトの割り当てを（また
は再生をオプションで）要求することができる。 ＡＦは、ＣＬを介してフレーム、スクリプトおよびテー
プの構造体の割り当てを（または再生をオプションで）
要求することができる。ＣＬは、ＯＳおよびＦＳを介し
てＨＷにコンピュータ・オブジェクトの割り当ておよび
再生を要求することができる。 【００９８】ＭＯＶＯＮ、ソフトコーダ、ＶＣ、および
概念構造のその他の構成要素の間の接続をさらに説明す
るために、ＶＳＭの言語を使用することができる。テー
プ・プログラムをビデオ店から借りると（ＶＳＭによる
利用者の要求）、ＶＣは、ＣＬを介してＦＳまたはＮＷ
への接続を開き、ソフトコーダは、その開かれた接続か
らの入力をテープ・シェルフ（ＶＳＭ）の上に置かれた
テープ・プログラムへと記録する。テープがソフトコー
ダにロードされる（ＶＳＭコマンド）と、ソフトコーダ
は、アクタを要求し、ＭＯＶＯＮからのビューを表示し
た後、ソフトコーダは、適切な実行アルゴリズムを呼び
出す。ソフトコーダがそのテープ・プログラムからスク
リプトを実行するにともない、１）ＡＦによって時間的
履歴において制御され、かつ２）ＭＯＶＯＮ−ＰＲＥＳ
ＣＲＩＰＴ−ＷＧを介してアクタの視覚的表現（例えば
、アニメーション）に影響を及ぼし得るアクタに変更が
指示される。変更、または実行選択肢を試行のために利
用者が実行を休止すると、変更が、スクリプトの変更お
よびアクタの変更に翻訳されてＭＯＶＯＮおよびＡＦに
伝えられ、そこにおいて、それらの変化は一時的または
永久に組み込まれる。アクタおよびスクリプトに対する
変更は、ソフトコーダがそれらの変更を実施し、それら
をＭＯＶＯＮを介して伝達すると、直ちに見ることがで
きる。 【００９９】ビデオ・スタジオ・メタファにおいて、例
としてのシナリオが対話的にテープに記録される。シナ
リオ例は、既存のシステムまたは設計予定のシステムに
対する一連の作用を指定するために使用される。新たな
条件に対するシステムの作用の新しい面を取り入れ、す
べての許容可能な条件のためにテープ・プログラムへと
発展させるために、テープ・シナリオが対話的に洗練さ
れる。十分に洗練した後、テープ・プログラムにより、
表されたシステムまたは設計中のシステムの完全なシミ
ュレーションが与えられる。テープ（シナリオまたはプ
ログラム）には、アクタの集合、アクタ間の作用および
通信を記述する規則の集合が入る。アクタは、規則の実
行によって駆動される通信活動および処理活動に関与す
る処理主体である。アクタは、規則の実行に使用される
独立した知識ベースを備えている。規則は、アクタの知
識ベースに関する事前条件、アクタ間の通信、および通
信とアクタの知識ベースへの表明とからなる事後処理を
含んでいる。 【０１００】アクタ・フレーム・モジュールフレームの
概念構造により、利用者は、「ロード」および「接合」
により２つの独立したテープを統合することができる。 アクタおよび規則を共有する２つのテープは、それらを
１つの環境にロードし、テープの接合および編集を適用
することによって統合することができる。役割および関
数を共有してもアクタの識別情報が一致しない２つのテ
ープは、アクタの移転（アクタの交換を選択する）およ
び前記のステップを実行することによって、合併するこ
とができる。同じ特徴の仕様を持つ断片部品を組み立て
てみれば、前記のような環境に統合のための独特なコン
ピュータ支援があることが分かる。 【０１０１】テープの編集および合併に付いての柔軟性
は、フレーム表現言語（ＦＯＬＩＥ）、ビジュアル・オ
ブジェクト網管理（ＭＯＶＯＮ）、およびアクタの規則
に基ずく作用の定義に用いられる基礎的なスクリプト言
語（例えば、ＯＯスクリプト）と言う３つの要素の統合
からくるものである。フレームの合併により、テープお
よび（または）アクタのスロット、値および関係（例え
ば、継承、構成員関係）の合併がサポートされる。フレ
ームまたはそれらの関係の集合が、ノードがフレームを
表し弧が関係を表すようなグラフによって表される場合
、そのような２つのフレーム集合を合併することは、か
くグラフのノードを合併し、合併したグラフのノード間
で弧を（合併の型に応じて）追加したり削除したりする
ことによって、それらのグラフを構成するに等しい。 アクタの交換処理は、オブジェクト指向言語における「
ｂｅｃｏｍｅ」の拡張として見ることができるが、これ
を用いて、あるアクタを他のものに替えたり、交換先が
既存のアクタである場合には、２つのアクタを合併した
りすることが可能である。ビジュアル・オブジェクトの
合併により、システムの構成要素の統合、即ち、スロッ
ト値、さらにグラフィックスの属性として定義される状
態の合併がサポートされる。規則に基づくテープ・プロ
グラムの実行は、規則集合の結合を行うことにより種々
のテープからアクタの作用の統合をサポートする。標準
のプログラミング言語における関数、オブジェクト、ま
たは命令の集合の結合によるプログラムの結合によって
、通常は、有用なまたは有意義な結果を生じることはな
い。なぜなら、プログラムの各命令の実行は、他の周囲
のプログラム命令によって定義される外部の暗黙の制御
フローによって条件付けられるからである。しかし、ス
クリプト規則、一般スクリプトおよび関係するアクタの
集合結合によるテープ・プログラムの結合は、結合され
ているテープからの機能性の追加を、次のような少なく
とも２つの利点を伴って、もたらし得る。第１に、テー
プ・プログラムの各「命令」は、アクタまたはアクタの
記述、実行条件および結果としての処理および通信（メ
ッセージ）から成るスクリプト規則または一般スクリプ
トであり、従って、自立したプログラム命令である。第
２に、結合されている異なるテープ・プログラムからの
２つのスクリプト規則が、一致しない場合、この矛盾は
、明確に定義されている型であり、１）それらの規則が
意味論的に矛盾するか、２）両方の規則が同一のアクタ
・スロットを同時に更新しようとする状態が存在するか
、または３）１つ以上の規則が到達不可能であるかの何
れかである。最初の２つの矛盾の場合は、結合されたテ
ープ・プログラムの実行のアニメーションまたはシミュ
レーションの間に視覚的に現れる。第２および第３の矛
盾の場合も、結合された規則集合の静的な分析を用いて
検出することができる。 【０１０２】ＧＲＡＳにおいて、ＦＯＬＩＥ、ＭＯＶＯ
Ｎ、および内部のスクリプト構造体（例えば、ＯＯスク
リプト）を結合する根元的な知識表現は、上述の合併処
理（規則集合の結合によるフレーム・グラフの合併およ
び作用の統合）に内部的に基づく仕様の独特な柔軟性を
備えている。 【０１０３】ＶＳＭのためのデータの記憶および検索を
サポートする基本的な知識表現は、ＧＲＡＳのアクタ・
フレーム要素によって与えられる。ＡＦは、アクタ間の
通信スクリプトの可逆的な実行のために必要な時間履歴
機構を提供するもので、根元的なフレーム表現言語ＦＯ
ＬＩＥの上に構築されている。ＡＦにより、アクタへの
通信またはアクタからの通信によりフレームの属性また
は関係が変化する度にそのアクタ・フレームのローカル
・スナップ・ショットを記録しておくことにより、（前
に形式化された）アクタに必要な時間履歴機構が与えら
れる。この時間履歴の他に、ＧＲＡＳの実現に必要とさ
れるＡＦのすべての特徴は、ＦＯＬＩＥの直接的な特徴
である。 【０１０４】ＶＳＭにおけるテープの実行機構は、アク
タの動的な属性の記録および復活（読み出し）に基づく
。前記のテープ編集処理は、アクタの動的な属性と静的
な属性との組み合わせに影響を及ぼす。変更および編集
の実施は、根底にあるフレーム表現言語ＦＯＬＩＥによ
って直接サポートされる。動的な変更の実施は、ＦＯＬ
ＩＥの特性とアクタに関連したフレームの属性のスナッ
プ・ショットを記録・復活できる履歴機構との組み合わ
せによって与えられる。アクタの静的属性および動的属
性に関して必要な処理をサポートするＦＯＬＩＥフレー
ム言語の重要な特徴を以下に述べる。 【０１０５】シンボリック自己記述：フレームは、それ
が定義されているコンピュータ環境とは独立したシンボ
ルによる記述フォーマットを用いて「それ自体をプリン
トする」ことができる。自己記述フォーマットは伸縮性
があり、フレームが変化すると、その変化を取り込むた
めに、同じフォーマットが、延長されたり短縮された形
式で使用される。コンピュータに依存できるフォーマッ
トならば型の特殊性はない。フレーム集合のシンボルに
よる自己記述は、順序に依存しない。フレームの集合｛
ｆ１，ｆ２，．．．，ｆｎ｝が与えられた場合、このフ
レーム集合の自己記述を任意の順序で記録し、同等のフ
レーム集合を生成するために、ＧＲＡＳシステムの別の
場合に異なる順序でそれらを復活させることが可能であ
る。 【０１０６】２重リンク：フレーム間のすべての関係は
、２重リンクを用いて維持され、２重リンクの半分を記
録することは、２重リンクの全体を記録すること同じで
ある。この性質により、フレーム集合の自己記述の順序
独立性がサポートされる。 【０１０７】フレーム網：フレームは、他のフレームと
の関係のネットワークと解釈することができる。各フレ
ームは、他のフレームとの関係網をシンボルによって記
述し、他のフレームが無くなると、フレームの統合が可
能となる。従って、フレームの不完全なネットワークを
記録・復活しても差し支えない。それがフレームの集合
Ｆ＝｛ｆ１，ｆ２，．．．，ｆｎ｝である。ここで、Ｆ
の要素ｆｉは、Ｆの要素でないｆｊを参照する。 【０１０８】継承の多重階層：フレームは、所与のフレ
ーム階層におけるすべての母体から属性と関係の統一体
（集合）を継承することができる。多重継承は、他のフ
レーム言語およびオブジェクト指向言語についても一般
に利用可能であるが、多重階層による多重継承は、ＦＯ
ＬＩＥの新奇な特徴である。フレームは、ＡＫＯ階層、
ＰＡＲＴ−ＯＦ階層、またはＧＲＡＳにおいて定義され
たその他の関係から、特性を継承する。それぞれの双対
関係によって、それ自体のフレームの階層が定義される
。 【０１０９】ローカル・クラス優先リスト（ＬＣＰＬ）
：これによって、所与の階層におけるフレームに対する
母体の順序集合が構成される。多重階層によって多数の
ＬＣＰＬに備えている。 【０１１０】フレームの放送：作用素または関数を放送
して、それを所与の階層におけるＬＣＰＬのすべての要
素に適用することができる。 【０１１１】フレームの合併：これは、フレームに格納
された情報の結合および再利用するための機構である。 ４つの基本的な合併の原型、即ち再利用、結合、上書き
、および忘却によって、いくつかのフレームを合併する
ことができる。２つのフレームｆ１およびｆ２を合併し
て、フレームｆ（１＋２）を構成する場合、以下のとお
りである。 １）再利用：ｆ（１＋２）は、ｆ１に優先してｆ１およ
びｆ２から継承する。ｆ１の属性および関係が残り、ｆ
２からの重複しない属性と関係が追加される。 ２）結合：ｆ（１＋２）は、ｆ１およびｆ２から同等に
継承する。ｆ１およびｆ２からの属性および関係が、統
一集合としてｆ（１＋２）に格納される。 ３）上書き：ｆ（１＋２）は、ｆ２に優先してｆ１およ
びｆ２から継承する。これは、ｆ２とｆ１との間の再利
用を伴った合併と同じである。 ４）忘却：ｆ（１＋２）＝ｆ２ 合併されたフレーム
は、元のフレームｆ２によって置き換えられる。 【０１１２】フレームの転送：これは、フレーム網の一
貫性を維持しながらフレームをもう１つのフレームで全
体的に置き換えることにより、現存の２重リンクを維持
することに備えるものである。交換フレームが既に存在
する場合、転送は、合併によって行われる。この特徴に
より、アクタの交換、先に述べたクローン生成および合
併が直接サポートされる。 【０１１３】フレーム網の合併：共通のフレームを共有
する２つのフレーム網は、同一のＶＳＭベースのシステ
ムにおいて復活されると、自動的に合併される。 【０１１４】ＧＲＡＳにおけるテープの編集および合併
に付いての柔軟性は、概念構造の次の３つの主な構成要
素の間の相互作用から生じるものである。即ち、時間履
歴を統合したフレーム表現言語（ＡＦおよびＦＯＬＩＥ
）、ビジュアル・オブジェクト網管理（ＭＯＶＯＮ）、
およびアクタの規則に基ずく作用を表すのに用いられる
スクリプト構造体の根底にある特性（ソフトコーダ）で
ある。次の例により、これらのソフトウェア構成要素の
統合を説明する。 【０１１５】１）フレームの合併により、テープ、アク
タおよび関係（例えば、継承、構成員、副構成要素）の
静的または動的な合併がサポートされる。各グラフが、
アクタの作用を記述するスクリプト構造体にテープ結合
され、アクタに結合され、副構成要素のアクタへと結合
されると言うような場合、この型の合併は、グラフの合
併に等しい。 【０１１６】２）一般的なアクタ交換処理によって、ア
クタを新しいものと交換したり、２つ以上の既存のアク
タを合併できる。これはアクタの交換、クローン生成を
可能とし、新たな設計構成要素についての利用者の実験
をサポートする。 【０１１７】３）ビジュアル・オブジェクトの合併は、
システムの構成要素およびそれらのグラフィック表現の
統合をサポートし、交換、クローン生成、または合併が
発生した場合に利用者に対して直接的かつ視覚的なフィ
ードバックを与える。 ４）スクリプト構造体およびソフトコーダによるそれら
の実行によって与えられるようなアクタの間の規則ベー
スの通信によって、規則集合の統一を行うことによる多
数のテープ・プログラムからの特徴および構成要素の統
合がサポートされる。 【０１１８】ＧＲＡＳにおいては、ＡＦ、ＭＯＶＯＮ、
およびソフトコーダを結合する根元的な知識表現によっ
て、システム設計に関する使用および実験の新奇な柔軟
性が提供される。既存の設計と新たな設計のシミュレー
ション、結合および分析を非常にとりつき易くユーザ・
フレンドリに行うことが可能である。使用の柔軟性は、
ＡＦ、ＭＯＶＯＮ、およびソフトコーダと言うＧＲＡＳ
概念構造の３つの基本的な構成要素の統合によって与え
られる作用規則の合併および統合のような処理に対する
独自の半自動化された支援の結果である。 【０１１９】ＦＯＬＩＥ 次に、フレーム・オブジェクト言語および実行環境（Ｆ
ＯＬＩＥ）を説明する。明確になるよう、ＦＯＬＩＥを
定義するために、ここではＣｏｍｍｏｎ Ｌｉｓｐ（１
９８４年デジタル・プレス社刊のＧ．Ｌ．スチール（Ｓ
ｔｅｅｌｅ）二世による「ＣｏｍｍｏｎＬｉｓｐ ザ・
言語（Ｃｏｍｍｏｎ Ｌｉｓｐ ｔｈｅ Ｌａｎｇｕａ
ｇｅ）」）を改良したＬｉｓｐ風のシンタックス（構文
法）を用い、いくつかの例を掲げる。ここで定義するＦ
ＯＬＩＥ作用素は、Ｃｏｍｍｏｎ ＬｉｓｐおよびＣｏ
ｍｍｏｎ Ｌｉｓｐオブジェクト・システム仕様（ＣＬ
ＯＳ）（１９８７年Ｄ．ボブロウ（Ｂｏｂｒｏｗ）によ
るゼロックス・ドキュメント８７−００２「ＣＬＯＳ」
、および在ニュー・ヨークのアヂソン・ウェスレイ（Ａ
ｄｄｉｓｏｎ Ｗｅｓｌｅｙ）社１９８９年刊のＳ．Ｅ
．キーネ（Ｋｅｅｎｅ）による「Ｃｏｍｍｏｎ Ｌｉｓ
ｐによるオブジェクト指向プログラミング ＣＬＯＳ
へのプログラマーズ・ガイド（Ｏｂｊｅｃｔ−Ｏｒｉｅ
ｎｔｅｄ Ｐｒｏｇｒａｍｍｉｎｇ ｉｎ Ｃｏｍｍｏ
ｎ Ｌｉｓｐ， Ａ Ｐｒｏｇｒａｍｍｅｒ’ｓ Ｇｕ
ｉｄｅ ｔｏ ＣＬＯＳ）」）に類似した命名規約によ
って命名する。ＦＯＬＩＥにおけるローカル・クラス優
先リストの定義は、ＣＬＯＳにおけるクラス優先リスト
の定義から行われたものである。 【０１２０】１）表記および定義 ＦＵＮ１（ＡＲＧ１ ＡＲＧ２）を２つの引数ＡＲＧ
１およびＡＲＧ２の関数であるＦＵＮ１の宣言とする。 「＆ｏｐｔｉｏｎａｌ」はオプションの引数を宣言し、
「＆ｒｅｓｔ」は関数の残りのすべての引数の集まりを
宣言するものとする。「＆ｏｐｔｉｏｎａｌ（ＤＥＰＴ
Ｈ ０）」は、デフォルト値０を有するＤＥＰＴＨと
命名されたオプションの引数に対する宣言であるとする
。 （ＦＵＮ１ ＡＲＧ１ ＡＲＧ２）は、引数ＡＲＧ
１およびＡＲＧ２を付けた関数ＦＵＮ１の呼び出しを表
す関数コール表現とする。引数は、埋め込まれた関数コ
ールを表して、それ自体が関数コール表現となり得る。 ：：＝は、「結合」記号とする。従って、ＶＡＲ：：＝
（ＦＵＮ１ ＡＲＧ１ＡＲＧ２）は、ＶＡＲが、その
関数コールの結果に結合されることを示す。＝は、「定
義により等号」とする。−＞は、「戻り値」の記号とす
る。例えば、Ｖ１：：＝１２３ならば、Ｖ１−＞１２３
である。Ｆは、唯一のＬｉｓｐオブジェクト（例えば、
ある記号）によって識別される任意のフレーム・オブジ
ェクトとする。ＦＢは、任意のフレーム・ベースである
ものとする。ただし、ＦＢは、フレーム・オブジェクト
の集合からなる構造体である。ＭＦＢ（マルチプル・フ
レーム・ベース）は、ＦＯＬＩＥで定義された一般型（
一般のクラス）のフレーム・ベース・オブジェクトであ
るものとする。ＮＸは、ｎ個のスロット列ＮＸ＝（Ｘ１
Ｘ２．．．Ｘｎ）であり、Ｘ＝ＸｉはＮＸにおけるス
ロットであり、ＢＮＸｉはＸｉより前のＮＸの部分数列
であり、ＡＮＢｉはＸｉより後のＮＸの部分数列である
ものとする（ＡＮＸｉまたはＢＮＸｉまたは両者は、空
の数列（）である可能性もある）。従って、ＮＸ＝ＢＮ
Ｘｉ｜（Ｘｉ）｜ＡＮＸｉとなる。ただし、｜は数列の
連結を表す。 【０１２１】２）フレーム・ベースの生成ＭＦＢ（＆ｒ
ｅｓｔ Ｆ−ｓｅｔ） これは、Ｆフレーム・オブジ
ェクトの集まりである簡単なフレーム・ベースを生成す
る。 例：（ＭＦＢ Ｆ１ Ｆ２ Ｆ３）−＞（Ｆ１．．．Ｆ
２．．．Ｆ３．．．） これは、そのフレーム・ベー
スがＦ１、Ｆ２およびＦ３を含むことを示す。 【０１２２】３）多数のフレーム・ベースの生成ＭＡＫ
Ｅ−ＭＦＢ（＆ｏｐｔｉｏｎａｌ ＦＢ Ｆ ＮＸ−ｓ
ｅｔ（ＭＥＲＧＥ−ＴＹＰＥ：ＣＯＭＢＩＮＥ））
これは、フレームおよびフレーム・ベースの生成および
合併である。ここで、引数はすべてオプションであり、
ＮＸ−ｓｅｔは集合ＮＸ（一連のＮＸ）であり、ＭＥＲ
ＧＥ−ＴＹＰＥは以前に定義したような（：ＲＥＵＳＥ
：ＣＯＭＢＩＮＥ：ＯＶＥＲＷＲＩＴＥ）のうちの１つ
であり、ＭＥＲＧＥ−ＴＹＰＥのデフォルト値は：ＣＯ
ＭＢＩＮＥである。 例：ＦＢ：：＝（ＭＡＫＥ−ＭＦＢ） これは、空の
フレーム・ベースを生成する。（ＭＡＫＥ−ＭＦＢ Ｆ
Ｂ Ｆ） これは、フレーム・ベースＦＢに空のフレ
ームＦを追加する。（ＭＡＫＥ−ＭＦＢ ＦＢ Ｆ （
ＮＸ１．．．ＮＸｐ）） これは、スロット列（ＮＸ
１．．．ＮＸｐ）の集合を備えたフレームＦをＦＢに追
加する。Ｆが既にＦＢの要素である場合、（ＮＸ１．．
．ＮＸｐ）は、既存のフレームＦとの結合によって合併
される。（ＭＡＫＥ−ＭＦＢ ＦＢ Ｆ （ＮＸ’１．
．．ＮＸ’ｐ）：ＦＯＲＧＥＴ） これは、フレーム
Ｆの既存の定義を新しいもので置き換える。 【０１２３】４）アクセサとアサータ ＧＥＴＭＦＢ（＆ＯＰＴＩＯＮＡＬ ＦＢ Ｆ ＆ｒｅ
ｓｔ ＮＸ）は、ＦＢにおけるフレームＦのＮＸスロッ
トの記述にアクセスする。ＧＥＴＭＦＢ（＆ＯＰＴＩＯ
ＮＡＬ ＦＢ Ｆ ＆ｒｅｓｔ ＮＸ）：：＝ＶＡＬＵ
Ｅは、フレームＦに対するＮＸ位置においてＶＡＬＵＥ
を加える。値として空の数列（）を加えることは、Ｆに
おける位置ＮＸにおける現在の値フレームを削除するこ
とと同じである。ＧＥＴＭＦＢの値として真のフレーム
文Ｔを加えることは、ＦにおけるＮＸを表明することに
等しい。なお、ＶＡＬＵＥが（）でない場合、所与の値
（値フレーム）を含むローカル・フレームを生成するこ
とによってＶＡＬＵＥがＦに加えられること、ならびに
値の「追加」は合併によって行われることに注意を要す
る。従って、ＦＯＬＩＥにおいては、フレーム・ベース
は、その各副構成要素がフレーム・ベースであるという
点で、多重フレーム・ベースである。｛（ＧＥＴＭＦＢ
ＦＢ Ｆ Ｘ１．．．Ｘｎ）：：＝Ｔ｝＝（ＭＡＫＥ
−ＭＦＢ ＦＢ Ｆ （Ｘ１．．．Ｘｎ））であること
に注意を要する。 【０１２４】例：（ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ
２）：：＝ＶＡＬＵＥ１２である場合：（ＧＥＴＭＦＢ
ＦＢ Ｆ Ｘ１ Ｘ２）−＞（ＶＡＬＵＥ１２．．．
）は、値ＶＡＬＵＥ１２を含みそして恐らくはその他の
前の値をも含むような値フレームが、ＦＢのフレームＦ
におけるスロット位置（Ｘ１ Ｘ２）に存在することを
示す。（ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２ ＶＡＬ
ＵＥ１２）−＞（Ｔ）は、スロット位置（Ｘ１ Ｘ２
ＶＡＬＵＥ１２）に真の値フレーム（空でないフレーム
）が存在することを示す。（ＧＥＴＭＦＢ ＦＢ Ｆ
Ｘ１）−＞（Ｘ２（ＶＡＬＵＥ１２．．．）．．．）は
、ＶＡＬＵＥ１２を含む値フレームが位置（Ｘ２）に入
っている値フレームが、フレームＦにおけるスロット位
置（Ｘ１）に存在することを示す。 （ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２）＝（ＧＥＴＭ
ＦＢ（ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１）Ｘ２）（ＧＥＴ
ＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２）＝（ＧＥＴＭＦＢ（Ｇ
ＥＴＭＦＢ（ＧＥＴＭＦＢ ＦＢ）Ｆ）Ｘ１）Ｘ２） （ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２）：：＝ＮＥＷ
ＶＡＬＵＥ（ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２）−
＞（ＮＥＷＶＡＬＵＥ．．．ＶＡＬＵＥ１２．．．）は
、両方の値が今やＦにおける位置（Ｘ１ Ｘ２）の値
フレームの要素であることを示す。 （ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２ ＶＡＬＵＥ１
２）：：＝０（ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２）
−＞（ＮＥＷＶＡＬＵＥ．．．）は、ＶＡＬＵＥ１２が
Ｆにおける位置（Ｘ１ Ｘ２）の値フレームの要素で
ないことを示す。 （ＧＥＴＭＦＢ ＦＢ Ｆ Ｘ１ Ｘ２ ＶＡＬＵＥ１
２）−＞０【０１２５】５）多重アサータ フレーム、またはＧＥＴＭＦＢのスロット引数のうちの
１つが、それ自体フレーム・ベースであり、表明に対し
てＧＥＴＭＦＢが呼び出された場合、その表明は、多重
化され、そのフレーム・ベース引数のすべての要素に分
配される。 【０１２６】例：Ｘ：：＝（ＭＦＢ Ａ Ｂ Ｃ）−＞
（Ａ．．．Ｂ．．．Ｃ．．．）とし、ＮＸ＝ＢＮＸ｜（
Ｘ）｜ＡＮＸである場合：｛（ＧＥＴＭＦＢ ＦＢ Ｆ
ＮＸ）：：＝Ｙ｝＝｛（ＧＥＴＭＦＢ ＦＢ Ｆ｜Ｂ
ＮＸ｜（Ａ）｜ＡＮＸ｜かつ（ＧＥＴＭＦＢ ＦＢ Ｆ
｜ＢＮＸ｜（Ｂ）｜ＡＮＸ｜かつ（ＧＥＴＭＦＢ Ｆ
Ｂ Ｆ ｜ＢＮＸ｜（Ｃ）｜ＡＮＸ｜）｝ （ＧＥＴＭＦＢ ＦＢ Ｆ ｜ＮＸ｜）：：＝（）は、
これらすべての表明を削除する。特に：（ＧＥＴＭＦＢ
ＦＢ ＦＢ ｜ＮＸ）：：＝Ｔは、フレーム・ベース
ＦＢのすべてのフレーム要素にＮＸを表明する。 （ＧＥＴＭＦＢ ＦＢ ＦＢ）＝（ＧＥＴＭＦＢ ＦＢ
）かつ（ＧＥＴＭＦＢ ＦＢ ＦＢ）：：＝（）は、Ｆ
Ｂのすべての要素からすべての事実を削除する。 【０１２７】６）関係アクセサおよび関係アサータフレ
ーム・オブジェクト間の記号関係を指定するために、ス
ロット列ＮＸを使用することができる。特に、ＦＯＬＩ
Ｅにおいては次のような構文法を用いて多重スロット列
を用いて、双対関係を定義することが可能である。即ち
、：＞を「前方」リンク記号とし、：＜を「後方」リン
ク記号とすると、（ＧＥＴＭＦＢ ＦＢ Ａ ：＞ Ｂ
）：：＝Ｔは、フレーム・ベースＦＢのフレームＡとフ
レームＢとの間の双対関係を表明する。ＦＯＬＩＥで定
義されるフレーム・オブジェクトに関するすべての処理
において、以下に定義される同等関係を実施することに
より関係の双対性が維持される。ＦＢを現在のフレーム
・ベースとする。フレーム・ベースＦＢにおいて表明Ｎ
Ｘが真であることを示すために、（ＧＥＴＦＭＢＦＢ
ＮＸ）：：＝Ｔを短縮形［ＮＸ］＝Ｘ１ Ｘ２．．．Ｘ
ｎで表すものとする。＜＝＞を同値記号とする。要素と
してＡ、ＢおよびＣを含むフレーム・ベース（ＭＦＢ
Ａ Ｂ Ｃ）を短縮形（Ａ Ｂ Ｃ）によっ
て表すものとする。すると、ＦＯＬＩＥにおける関係に
ついての次の表明は真である。 ａ）直接関係同値 Ａ：＞Ｂ＜＝＞Ｂ：＜Ａ ｂ）多対１関係の分配性 （Ａ Ｂ）：＞Ｃ＜＝＞｛Ａ：＞Ｃ かつ Ａ：＞Ｃ｝
ｃ）ｓｉｎｋ関係の分配性 ＦＢ：＞ＯＭＥＧＡ＜＝＞ＦＢのすべてのＦに対し｛Ｆ
：＞ＯＭＥＧＡ｝ｄ）１対多関係の分配性 Ａ：＞（Ｂ Ｃ）＜＝＞｛Ａ：＞Ｂ かつ Ａ：＞Ｃ｝
ｅ）トポロジー関係の分配性 ＡＬＰＨＡ：＞ＦＢ＜＝＞ＦＢのすべてのＦに対し｛Ａ
ＬＰＨＡ：＞Ｆ｝ｆ）Ｎ項関係の同値 Ａ Ｘ１ Ｘ２．．．Ｘｎ：＞Ｚ ＜＝＞ Ｚ Ｘ１
Ｘ２．．．Ｘｎ：＜Ａさらに、前記のａ）からｅ）まで
の表明は、Ｎ項関係に対しても同様に真である。 【０１２８】例： （Ａ Ｂ Ｃ） ＣＯＮＮＥＣＴ
ＳＡＴＥＬＬＩＴＥ ：＞ ＶＥＧＡ＜＝＞｛Ａ ＣＯ
ＮＮＥＣＴ ＳＡＴＥＬＬＩＴＥ ：＞ ＶＥＧＡかつ
Ｂ ＣＯＮＮＥＣＴ ＳＡＴＥＬＬＩＴＥ ：＞ Ｖ
ＥＧＡかつ Ｃ ＣＯＮＮＥＣＴ ＳＡＴＥＬＬＩＴＥ
：＞ ＶＥＧＡ｝＜＝＞｛ＶＥＧＡ ＣＯＮＮＥＣＴ
ＳＡＴＥＬＬＩＴＥ ：＜ Ａかつ ＶＥＧＡ ＣＯ
ＮＮＥＣＴ ＳＡＴＥＬＬＩＴＥ ：＜ Ｂかつ ＶＥ
ＧＡ ＣＯＮＮＥＣＴ ＳＡＴＥＬＬＩＴＥ ：＜ Ｃ
｝【０１２９】７）作用素の設定 ＦＢが、次の処理を行う間にすべての双対関係を表明す
るために「ルート」として使用される現在のフレーム・
ベースであるとする。ＭＦＢ−ＭＥＲＧＥ（ＴＹＰＥ
ＦＢ１ ＆ｒｅｓｔ ＦＢ−ｓｅｔ） これは、（：
ＲＥＵＳＥ：ＣＯＭＢＩＮＥ：ＯＶＥＲＷＲＩＴＥ：Ｆ
ＯＲＧＥＴ）の一要素であるＴＹＰＥにしたがって、フ
レーム・ベースの集合ＢＦ−ｓｅｔをＦＢ１へと合併す
る（ＦＢ１を変更する）。ＭＦＢ−ＩＮＴＥＲＳＥＣＴ
ＩＯＮ（ＦＢ１ ＆ｒｅｓｔ ＦＢ−ｓｅｔ） ＦＢ
１を、それ自体（その表明）とフレーム・ベースの集合
（からのすべての表明）との交事象（積集合）にする。 ＭＦＢ−ＤＩＦＦ（ＦＢ１ ＆ｒｅｓｔ ＦＢ−ｓｅｔ
） フレーム・ベース集合からのすべての表明をＦＢ
１から削除する。ＭＦＢ−ＴＲＡＮＳＦＥＲ（ＦＢ１
ＦＢ２）＝ＭＦＢ−ＭＥＲＧＥ（：ＲＥＵＳＥ ＦＢ２
ＦＢ１） ＦＢ２において全く相似を持たないＦＢ
１からのすべての表明を加えてＦＢ２とすることに相当
する合併の使用。ＭＦＢ−ＵＮＩＯＮ（ＦＢ１ ＆ｒｅ
ｓｔ ＦＢ−ｓｅｔ）＝ＭＦＢ−ＭＥＲＧＥ（：ＣＯＭ
ＢＩＮＥ ＦＢ１ ＆ｒｅｓｔ ＦＢ＝ｓｅｔ） フ
レーム・ベースの集合からのすべての表明の集合統一に
相当する合併の使用。ＭＦＢ−ＲＥＰＬＡＣＥ（ＦＢ１
ＦＢ２）＝ＭＦＢ−ＭＥＲＧＥ（：ＦＯＲＧＥＴ Ｆ
Ｂ２ ＦＢ１） ＦＢ２をフレーム・ベースにあるＦ
Ｂ１によって置き換えることに相当する合併の使用。Ｍ
ＦＢ−ＸＯＲ（ＦＢ１ ＆ｒｅｓｔＦＢ−ｓｅｔ）
ＦＢ１とＦＢ−ｓｅｔにおける各フレーム・ベースとの
両者に対して対をなして真でない表明の集合となるよう
に、ＦＢ１を変更する。 【０１３０】８）叙述子（Ｐｒｅｃｉｄａｔｅ）ＭＦＢ
−ＩＮＣＬＵＤＥ−Ｐ（＆ｒｅｓｔ ＦＢ−ｓｅｔ）
これは、ＦＢ−ｓｅｔが包含関係に対する順序集合で
ある場合、真となる。例えば、（ＭＦＢ−ＩＮＣＬＵＤ
Ｅ−Ｐ ＦＢ１ ＦＢ２）ー＞Ｔは、ＦＢ１がＦＢ２の
サブフレーム・ベースに等しく、ＦＢ１において真であ
るすべての表明はＦＢ２においても真であると言うこと
を意味する。ＭＦＢ−ＭＩＮＩＭＡＬ−Ｐ（ＦＢ）
ＦＢについて真であるような表明が存在しないならば、
真となる。例えば、（ＭＦＢ−ＭＩＮＩＭＡＬ−Ｐ（Ｍ
ＡＫＥ−ＭＦＢ））−＞Ｔである。ＭＦＢ−ＥＱＵＡＬ
（ＦＢ１ ＦＢ２ ＆ｏｐｔｉｏｎａｌ ＤＥＰＴＨ）
（ＭＦＢ−ＩＮＣＬＵＤＥ−Ｐ ＦＢ１ ＦＢ２）
および（ＭＦＢ−ＩＮＣＬＵＤＥ−Ｐ ＦＢ２ ＦＢ１
）が共に真の場合、真となる。 【０１３１】注意事項：ある種の処理の効率のために、
ここと以下においてオプションの引数ＤＥＰＴＨを使用
する。（）というデフォルトのＤＥＰＴＨは、フレーム
・ベース全体が検討されることを示す。０というデフォ
ルトのＤＥＰＴＨは、フレーム・ベースの第１の水準が
検討されることを示す。ＤＥＰＴＨが数である場合、そ
の数は、検討されるスロット列ＮＸの最大サイズから１
を引いた数を示す。 【０１３２】９）ユーティリティ ＭＦＢ−ＣＯＰＹ（ＦＢ ＆ｏｐｔｉｏｎａｌ ＤＥＰ
ＴＨ） ＦＢのコピーを作る。 ＭＦＢ−ＣＬＯＳＥ（ＦＢ ＆ｒｅｓｔ ＦＢ−ｓｅｔ
） ＦＢ−ｓｅｔのフレーム・ベースに対するすべて
の双対リンクを（閉じられる各双対リンクへの参照とし
てＦＢを用いて）閉じる。ＭＦＢ−ＰＲＩＮＴ（ＳＵＢ
ＦＢ ＆ｏｐｔｉｏｎａｌ ＳＴＲＥＡＭ ＤＥＰＴＨ
） フレーム・ベースＳＵＢＦＢのシンボル表現を与
える。ＳＵＢＦＢは、フレーム・ベースＦＢの部分集合
でもＦＢ全体でも良い。ＳＴＲＥＡＭが指定されていれ
ば、それが、ＳＵＢＦＢを対応するＳＴＲＥＡＭ装置に
印刷するために、使用される。ＭＦＢ−ＲＥＡＤ（ＦＢ
＆ｏｐｔｉｏｎａｌ ＳＴＲＥＡＭ ＤＥＰＴＨ）
ＳＴＲＥＡＭからフレーム・ベースの集合のシンボル
表現を読み、結果としてのフレーム・ベースをＦＢへと
合併する。 【０１３３】１０）マッパー ＭＡＰ−ＭＦＢ（ＦＣＮ ＦＢ ＆ｏｐｔｉｏｎａｌ
（ＤＥＰＴＨ ０）） ＦＢのすべてのスロットと値
とに対し関数定義ＦＣＮをＤＥＰＴＨまで適用する。Ｍ
ＡＰ−ＭＦＢ−ＳＬＯＴ（ＦＣＮ ＦＢ ＆ｏｐｔｉｏ
ｎａｌ （ＤＥＰＴＨ ０）） ＦＢのすべてのスロ
ットに対し関数定義ＦＣＮをＤＥＰＴＨまで適用する。 ＭＡＰ−ＭＦＢ−ＶＡＬＵＥ（ＦＣＮ ＦＢ ＆ｏｐｔ
ｉｏｎａｌ （ＤＥＰＴＨ ０）） ＦＢのすべての
値に対し関数定義ＦＣＮをＤＥＰＴＨまで適用する。 【０１３４】１１）ローカル・クラス優先リスト（ＬＣ
ＰＬ） ＬＣＰＬに用いられる定義は、ＣＬＯＳ仕様（Ｃｏｍｍ
ｏｎ Ｌｉｓｐオブジェクト仕様）から生まれたもので
ある。ＣＬＯＳではＣＰＬが単一継承分の階層に対して
定義されるのに対し、ＦＯＬＩＥでは、（ＮＸによって
定義される）Ｎ項関係によって指定される任意の階層に
対してＬＣＰＬが定義される。 【０１３５】ＭＦＢ−ＬＣＰＬ（ＦＢ Ｆ ＮＸ ＆ｏ
ｐｔｉｏｎａｌ ＤＥＰＴＨ） ＮＸによって指定さ
れる階層関係に局限されたＦＢ内のＦのクラス優先階層
を構成するフレーム・オブジェクトの順序集合を返す。 【０１３６】例：ＦＢが、以下の（短縮形の）表明が真
であるようなフレーム・ベースであるとする。 この場合、関係（Ｂ Ｃ）に関しＦＢにおけるＡに対す
るローカル・クラス優先リストは、（ＭＦＢ−ＬＣＰＬ
ＦＢ Ａ （Ａ Ｂ））−＞（Ａ Ｄ Ｄ１ Ｅ Ｅ
１ Ｚ）である。関係（Ｂ Ｃ）に対しＡの継承された
属性を探す場合、この属性に対する（Ａ Ｄ Ｄ１Ｅ
Ｅ１ Ｚ）を連続的に見る。継承された属性の探査は、
以下で定義するＭＦＢ−ＢＲＯＡＤＣＡＳＴを用いて行
われる。 【０１３７】１２）関数の放送 ＭＦＢ−ＢＲＯＡＤＣＡＳＴ（ＦＣＮ ＦＢ Ｆ ＮＸ
＆ｏｐｔｉｏｎａｌＤＥＰＴＨ） フレーム・オブ
ジェクトＦおよびフレーム・ベースにおけるＮＸによっ
て定義される階層においてＦに先行するすべてのオブジ
ェクトに対し関数定義ＦＣＮを適用する。ＭＦＢ−ＢＲ
ＯＡＤＣＡＳＴ−ＣＯＬＬＥＣＴ（ＦＣＮ ＦＢ Ｆ
ＮＸ ＆ｏｐｔｉｏｎａｌ ＤＥＰＴＨ） ＭＦＢ−
ＢＲＯＡＤＣＡＳＴに似ているが、その階層におけるＦ
のすべての先行例に対するＦＣＮの適用結果を収集する
。 【０１３８】プレスクリプト ＧＲＡＳ風の対話的アクタと規則ベースの環境における
システム作用のビジュアル・プログラミングと対話的・
動的かつ柔軟性のある編集は、ビジュアル・オブジェク
トの定義によって可能となる。アクタ・フレーム構造体
は、ＧＲＡＳにおけるアクタの視覚的表現を実現するた
めに、オプションでビジュアル・オブジェクトによって
拡大することができる。つまり、Ａｃｔｏｒ ＝ Ｄ（
Ａ，ｔ）＝ Ｂａｓｅ−Ｆｒａｍｅ＋ ｛Ｖｉｓｕａｌ
Ｏｂｊｅｃｔ｝ ＋ ｛Ｂｅｈｅａｖｏｒ｝であり、
このアクタは、時刻ｔにおけるデータ空間の記述Ｄ（Ａ
，ｔ）によって完全に指定される。しかし、データ空間
の記述は、ビジュアル・オブジェクト成分、基本フレー
ム記述、および現在時刻における可能な作用の継承され
た（恐らくは空の）集合を引き出し得る元の作用指定子
の集合に分解することができる。 【０１３９】ビジュアル・オブジェクトは、自己表示お
よび自己記述を行い、他のビジュアル・オブジェクトと
合併することが可能であり、さらに種々の視覚的表現（
例えば、アイコン、テキスト、ボタン、幾何学的な形、
グラフィックスの原形の組み合わせ）を持つことが可能
である。さらに、アクタに関係付けられたビジュアル・
オブジェクトは、テープの直接の構成員であり得る。そ
のビジュアル・オブジェクトに対応するフレームも、そ
のテープ・フレームに連結される。従って、１つのアク
タは、それが使用されるテープの各インスタンスについ
て２つのリンクを持つことができる。即ち、そのテープ
とそのビジュアル・オブジェクトとの間のリンク、およ
びそのフレーム記述とそのテープに関係付けられたフレ
ーム記述との間の双方向リンクである。 【０１４０】ビジュアル・オブジェクト表現の基礎とな
るのは、プレスクリプト（ＰｒｅＳｃｒｉｐｔ）グラフ
ィックス言語である。プリスクリプトでは、プリスクリ
プトのインタープリタ、コンパイラおよびデバッガのほ
か、接頭語表記およびＬｉｓｐ風の構文法も使用される
。プリスクリプトは、指示装置（例えば、マウス、カー
ソル）および利用者の入力をとらえ出力機構を与える機
構の定義を含めるために拡張された２次元、３次元また
はそれ以上の次元のベクトル空間代数を直接的に実現し
たものである。 【０１４１】プリスクリプトの実現には、ベクトル、ノ
ルム、距離、ベクトル演算（スカラー積、加算、減算、
ベクトル積）、直交性、平行性、点、線、平面、超平面
、射影、配景、原始的幾何学的対象（線分、線筋、２次
曲線、多角形、平行６面体、円柱、曲面モデル）、空間
位置の原形（内側、外側、交わり、合併、要素関係、隠
れた曲面）、線形変換およびアフィン変換、相似（回転
、移動、尺度構成、点対象および面対象）に対する定義
が含まれる。また、プレスクリプトのグラフィックス言
語には、表示装置、多数の視点、きめ、色、字体（フォ
ント）、テキストおよび座標の入出力装置、イメージ（
グラフィック要素の配列）、タイル、グラフィカルな周
期性および反復性の定義も含まれる。 【０１４２】プレスクリプト・コマンドの実行中にエラ
ーが発生すると、エラー・メッセージが、返され、説明
表示部位（Ｅｘｐｌａｉｎａｔｉｏｎ Ｖｉｅｗ）に表
示され、現在のプレスクリプト表現の実行は中止される
が、プレスクリプトの実行が阻止されるわけではない。 描画中のエラーは、次のような意味で決して致命的では
ない。即ち、所与のプレスクリプト・オブジェクトの表
示中のエラーにより、次のようなプレスクリプト・オブ
ジェクトの表示が妨げられることはない。しかし、第２
の表示結果が第１のものに依存する場合、第２の表示結
果は、正しくない可能性がある。 【０１４３】プレスクリプト・オブジェクトは、プレス
クリプト作用素、ならびに型引数（例えば、数型）およ
び仮想的評価環境において束縛される推測されるシンボ
ル引数からなる良く構成されたプレスクリプト表現であ
る。視覚的なオブジェクトは、４つのプレスクリプト要
素の組み合わせによって定義される。４つのプレスクリ
プト要素とは、Ｐ＝（ｄ，ｅ，ｉ，ｓ）である。ここで
、ｄ＝「描画（ｄｒａｗｉｎｇ）」、ｅ＝「エクステリ
ア（ｅｘｔｅｒｉｏｒ）」、ｉ＝「インテリア（ｉｎｔ
ｅｒｉｏｒ）」、およびｓ＝「センサ（ｓｅｎｓｏｒ）
」である。さらに、４つのセンサ方式（利用者対話作用
）Ｓ＝（ｉｎ，ｅｘ，ｂｃ，ａｃ）がある。ただし、ｉ
ｎ＝「センサに入る手順」、ｅｘ＝「センサから出る手
順」、ｂｃ＝「クリック前の手順」、ａｃ＝「クリック
後の手順」である。 【０１４４】プレスクリプトの要素は、次のように定義
される。即ち、描画（ｄ）は、視覚的対象の（表示装置
から独立した）描き方と初期の描画から動画を与えるオ
プションの変換関数とを記述するプレスクリプト・オブ
ジェクトである。エクステリア（ｅ）またはマスクは、
所与の表示部位（ｖｉｅｗ）において視覚的表現対象に
範囲を定めるために使用される明確に定義されたインテ
リアを有するプレスクリプト・オブジェクトである。イ
ンテリア（ｉ）または範囲は、ビジュアル・オブジェク
トの実質的な内部に範囲を定めるために使用される明確
に定義された内部を有するプレスクリプト・オブジェク
トである。センサ（ｓ）は、指示装置の指示に感応する
領域に範囲を定めるために使用される明確に定義された
インテリアを有するプレスクリプト・オブジェクトであ
る。 【０１４５】図４における利用者アクタによって例示し
たようなプレスクリプト・オブジェクトの例を以下に示
す。 【数１】 【０１４６】このプレスクリプト・オブジェクトＰ１は
、Ｐ１の設定環境（ｌｅｔで設定される）におけるｄ１
に従って、表示装置上のｘ、ｙ座標（８０６，２７６）
の周囲を中心とした位置に表示される。変数「ｉｃｏｎ
」が指定された位置に表示される。変数「ｎａｍｅ」が
、使用されて、指定の位置にヘルベチカ（Ｈｅｌｖｅｔ
ｉｃａ）フォント（サイズ１４、肉太型）で印字された
後、枠が描かれる。エクステリアｅ１は、座標Ｐ１を中
心とし、半径１５０の円の外部によって定義される。イ
ンテリア（ｉ）は、座標Ｐ１を中心とする幅「ｗ」およ
び高さ「ｈ」の四角の内部である。そして、センサ領域
ｓ１は、「ｎａｍｅ」の表示を囲む四角ｉ１の底にある
さらに小さい四角によって範囲が決定される。 【０１４７】センサ方式は、次のように定義される。即
ち、センサに入る手順（ｉｎ）は、指示装置が視覚対象
のセンサ領域に入ったときに呼び出される手順である。 デフォルトの手順は、マウスがセンサ領域に入ったとき
、そのセンサ領域が強調されることである。センサから
出る手順（ｅｘ）は、指示装置がセンサ領域から出たと
きに呼び出される手順である。デフォルトの手順は、マ
ウスがセンサ領域から離れた場合、センサ領域が強調さ
れなくなることである。クリック前の手順（ｂｃ）は、
指示装置がセンサ領域において選択を行うために使用さ
れるとき（例えば、マウスがクリックされるとき）に呼
び出される手順である。センサ領域を色付けしたり再描
画したりする、現在の表示部位において視覚対象のポイ
ンタに関連した動きを与える、現在の評価環境における
記号的事実を変更する、視覚対象に関する操作のメニュ
ーを出す、またはいくつかの手順の組み合わせを含む、
いくつかのデフォルト手順が利用できる。クリック後の
手順（ａｃ）は、センサ領域における指示装置の選択が
解除されたときに呼び出される手順である。デフォルト
の手順は、恐らくは変化した評価環境においてセンサ領
域を再描画するときに利用できる。 【０１４８】Ｐ１の表示された名前を変更するＰ１に対
するクリック前の手順を、前記のＰ１の例に従って、以
下において定義する。 【数２】 この定義、ならびに「ｉｎ」、「ｅｘ」および「ａｃ」
の手順に関する前記のデフォルトの定義の結果として、
次のように言える。指示装置が、Ｐ１のセンサ領域ｓ１
（「ｎａｍｅ」の表示の周囲の見えない四角）に入ると
、「ｉｎ」の手順が呼び出され、四角ｓ１が強調される
。指示装置を用いてＰ１のセンサ領域で選択を行うと、
Ｐ１の「ｂｃ」手順が呼び出され、これによって、（「
ｐｒｅｖｉｏｕｓ−ｎａｍｅ」（前の名前）と称する新
たな変数の下に「ｎａｍｅ」という現在の変数を格納し
た後に）Ｐ１の環境における「ｎａｍｅ」の値が「Ｍａ
ｒｇａｒｅｔ」に変化する。指示装置が解放されると、
Ｐ１に関するデフォルトの「ａｃ」手順が呼び出される
ことによって、プレスクリプトの要素ｄ１がＰ１の（変
化した）環境において実行される。従って、最上部にア
イコンがあり、最下部にヘルベチカ・フォントで「Ｍａ
ｒｇａｒｅｔ」（特定の利用者の名前）という語が印字
された四角として、Ｐ１が表示される。指示装置が、第
２の選択のインサイドｓ１のために使用された場合、Ｐ
１の名前は、Ｐ１の環境において定義された利用可能な
「ｐｒｅｖｉｏｕｓ−ｎａｍｅ」の値に変更される。従
って、名前「ｕｓｅｒ」が、Ｐ１の環境における変数「
ｎａｍｅ」の値として復活する。第２の選択の内側ｓ１
の解放時に呼び出される「ａｃ」手順によって、Ｐ１の
表示は、最上部にアイコンがあり、最下部に「ｕｓｒ」
と言う語がある四角へと変化して戻る。指示装置がＰ１
のｓ１領域を離れると、「ｅｘ」のデフォルト手順が呼
び出され、ｓ１は強調されなくなる。 【０１４９】アクタの選択可能な視覚表現を対話的に設
計するために、ＧＲＡＳでは前記のようなクリック手順
が使用される。それによって、ボタン、スイッチ、およ
び種々の入出力ビジュアル・オブジェクトが提供される
。これらの構成物をさらに込み入ったシステム要素へと
結合するために、アクタの合成が用いられる。例えば、
電話のオブジェクトは、ケース・アクタ、押しボタンア
クタの集合、液晶表示、および送受話器から構成される
。 【０１５０】クリック手順は、引数付きで定義された場
合、指示装置を介して行われる選択の型について選択的
である（例えば、左ボタンの選択に対し右ボタンの選択
と異なった定義をすることができるなど）。クリック手
順のための評価環境を形成するために、現在の環境が用
いられる。指示装置において行われるビジュアル・オブ
ジェクト、現在の表示部位、および選択の型は、これら
の手順に対する引数として渡される。さらに、ビジュア
ル・オブジェクトの階層（例えば、成分関係）が所与で
あるとし、ビジュアル・オブジェクトＡが、その階層に
おいてビジュアル・オブジェクトＢの下位のものである
ならば、Ａは、その上位の属性への明確な参照を用いる
ことによって、Ｂの環境へのアクセスも有する。 【０１５１】例えば、電話オブジェクトＰｈ１が、押し
ボタンＰＢ１のサブオブジェクトを有する場合、ＰＢ１
の環境において、Ｗはその押しボタンの幅であり、（Ｓ
ＵＰＥＲＩＯＲ Ｗ）は、ＰＢ１の上位のもの（ｓｕ
ｐｅｒｉｏｒ）、つまり電話オブジェクトＰｈ１、の幅
である。 【０１５２】デフォルトのクリック手順によって、現在
のビュー（表示部位）Ｖにあるビジュアル・オブジェク
トＡの動きが、ビューＶにおけるＡに与えられる強制関
数にならって与えられる。運動は、（成分の階層にある
）Ａの上位のものの程度分だけさらに強制される。成分
の階層のＡの最上位のものは、現在のビューにおけるす
べてのアクタの運動が入っているビューＶ用のビデオ・
モニタである。 【０１５３】例えば、Ｐｈ１のサブオブジェクトＣ１（
カーソル）が動いているならば、Ｃ１の運動は、Ｐｈ１
の内部（ｉｎｔｅｒｉｏｒ）領域に限られる（Ｐｈ１の
「ｉ」要素）。 【０１５４】アクタのプレスクリプト評価環境は、３つ
の環境の組み合わせからなる。 １）そのアクタの局部知識ベースを記述する環境：（ｌ
ｅｔ ａｌ＝Ｖ１，．．．，ａｎ＝ｖｎ，．．．）ただ
し、「ａｉ」は、その知識ベースにおける事実の記号名
を表し、「ｖｉ」は、対応する値または表現である。 ２）そのアクタの関連する特性を記述する環境：（ｌｅ
ｔ ｓｅｌｆ＝ｖｓｅｌｆ，ｎａｍｅ＝ｖｎａｍｅ，ｉ
ｎａｍｅ＝Ｖｉｎａｍｅ，ｉｃｏｎ１＝ｖｉｃｏｎ１，
．．．，ｘ１＝ｖｘ１，ｘ２＝ｖｘ２，．．．，ｘｐ＝
ｖｘｐ，．．．）ただし、「ｓｅｌｆ」（アクタ自体）
は、「ｖｓｅｌｆ」、即ちこのアクタに特有の識別子（
例えば、そのアドレス）に束縛される。「ｎａｍｅ」は
、アクタのステージ名に束縛される。「ｉｎａｍｅ」は
、そのアクタの内部名（またはシンボル・アドレス）に
束縛される。 「ｉｃｏｎ１」は、アイコン表現「ｖｉｃｏｎ」、即ち
アイコン・ライブラリにあるアイコンの記号的な識別子
に束縛され、可視イメージを生成するために、使用され
る。「ｘｉ」は、ｐ次元の絶対座標系におけるアクタの
座標に固定された絶対的な関連で束縛される。 ３）所与のテープに対して定義され、ビューの集合｛ｖ
ｉｅｗｊ｝（ｊ＝１，．．．，ｑ）に対するアクタの視
覚的表現および属性に関する変換と強制の集合を定義す
る環境：この環境は、次のものからなる。則ち、（ａ）
異なるビューに対する異なる座標：Ｔ：｛ｘｉ｝ −＞
（ｖｉｅｗ１／ｔ１（｛ｘｉ｝），．．．，ｖｉｅｗ
ｑ／ｔｑ（｛ｘｉ｝））Ｔ（ｖｉｅｗｊ）：｛ｘｉ｝
−＞ ｔｊ（｛ｘｉ｝）ただし、ｔｊは、その絶対座標
に基づくｊ番目のビューにあるアクタの座標を得る変換
関数である。その変換がビューにおいて線形ならば、そ
の変換は、座標変換行列Ｍｊ（｛ｘｉ｝＝Ｍｊ｛ｘｉ／
ｖｉｅｗ｝）を用いて表すことができる。（ｂ）ビュー
の集合における座標の移動に関する強制： Ｃ：｛ｘｉ｝ −＞ （ｖｉｅｗ０／ｃ０（｛ｘｉ｝）
，ｖｉｅｗ１／ｃ１（｛ｘｉ｝），．．，ｖｉｅｗｑ／
ｃｑ（｛ｘｉ｝）） Ｃ（ｖｉｅｗｊ）：｛ｘｉ｝ −＞ ｃｊ（｛ｘｉ｝）
ただし、ｃｊは、ｊ番目のビューにおいて観察されるア
クタの座標に対する強制関数である。絶対座標系に単一
の強制関数ｃ０が与えられる場合、ビューｑを発生する
線形変換Ｍｊが存在し、さらに各ビューに対して使用さ
れる強制関数が ｃｊ＝ｃ０ ｏ Ｍｊ であると仮定する。 （ｃ）すべてのビューに対する記号翻訳関数の集合：こ
の関数のアクタは次のように表される。 ｖｉｅｗｊ −＞ ｔｒｊ ただし、ｔｒｊは、アクタの環境（ｎａｍｅ、ｉｎａｍ
ｅ，ｉｃｏｎなど）からの記号特性または局部知識ベー
ス（ａｉ）からの要素の名前をｊ番目のビューで使用さ
れる新たな名前に変換する。デフォルトの翻訳関数は、
無変換である。 【０１５５】ｊ番目のビューにおけるアクタの視覚的表
現は、ビューがｖｉｅｗｊであることを知っているその
アクタのプレスクリプト環境の中でアクタに関係付けら
れたビジュアル・オブジェクトの第１のプレスクリプト
表現（描画）を評価することによって得られる。アクタ
のプレスクリプト環境は、そのアクタのビジュアル・オ
ブジェクト（それぞれエクステリア、インテリア、およ
びセンサ）の定義ならびに利用者の対話中の適切なセン
サおよびクリック手順の呼び出しに使用される他の３つ
のプレスクリプト・オブジェクト（ｅ、ｉおよびｓ）の
評価にも使用される。 【０１５６】すべてのビューにおけるグラフィカルな変
化は、時刻ｔにおけるアクタ環境のプレスクリプト評価
によるアクタの知識ベースへの論理的変更によって直接
的にもたらされる。アクタのグラフィック表現を記述す
るプレスクリプト表現は、このアクタの設定環境（ｌｅ
ｔ環境）の束縛事項（ａｉ）を使用する。従って、「ａ
ｉ」スロットのの値は、アクタのプレスクリプト・オブ
ジェクトのプレスクリプト要素（ｄ、ｅ、ｉ、ｓ）の指
定に自由に使用される。この性質により、アクタのｌｅ
ｔ環境として実現されるアクタの知識ベースの変更を反
映する表示の変更がサポートされる。グラフィック・エ
ディタは、使用規則、前記のような論理的変更、および
グラフィカルな効果を関係付け結合させるコードを自動
的に生成する。他の実施例では、論理的変更とグラフィ
カルな効果との間のデーターベースが維持されるものも
ある。ＧＲＡＳシステムのユーザ・インタフェースは、
そのようなビジュアル・オブジェクト（アクタの視覚的
表現）を用いて作った。この表現方法の柔軟性は、ビジ
ュアル・オブジェクトを用いて作ったシステム（への）
インタフェースは数日で完全に設計し直すことができる
ほどである。この環境は、それ自体のインタフェース、
例えば、ボタンの外観および感知力の変更、新たなボタ
ンの追加、および対応するコマンドなどを編集するよう
に、設定することができる。これは、それ自体の中でＶ
ＳＭベースのシステムを再設計する仮定における第１段
階である。 【０１５７】実行中は、アクタの知識ベースの履歴がソ
フトコーダによって自動的に維持され、グラフィックス
と状態の完全に可逆的な実行を与えている。各アクタは
、中でそれが使用されている各テープに対して自動的に
維持されているそのアクタの属性の変化の履歴を持って
いる。この履歴は、有効な変更の記録であり、そのアク
タがあるテープで使用されていなければ、その履歴は、
そのテープに対しては空である。アクタの属性への変更
により、アクタのグラフィック表現に影響を与えること
が可能であり、テープのシミュレーション中にアクタの
視覚表現に可能な唯一の変更は、その属性の変更による
ものである。従って、維持される履歴は、アクタの内部
的な属性とその視覚的な表現の両方の完全な記録を与え
るに十分な機構である。 【０１５８】アクタ間の通信 アクタ間の通信は、ソフトコーダによるスクリプト規則
の実行を介して行われる。通信には、アクタ間の情報の
伝送、およびその伝送にともなうすべての処理が含まれ
る。通信機能が低下した場合、アクタからそれ自体への
伝送を伴い、そのアクタ環境における内部処理と同じに
なる。通信には２つのモード、即ち（１）相互同意によ
る通信、および（２）送付（ｄｅｌｉｖｅｒｙ）による
通信が定義される。 【０１５９】（１）相互同意による通信：２つの異なる
アクタの間のメッセージ転送を伴うスクリプト規則の実
行の場合を考えると、メッセージが送信される前にセン
ダとレシーバの両アクタの事前条件が同時に満たされる
とき、この通信は、相互の同意によって実行される。ま
たこの通信は、同期通信とも称し、次式を使って表され
る。 Ｐ（Ｓ，Ｒ）＝＞Ｍ（Ｓ，Ｒ）＝＞Ｑ（Ｓ，Ｒ）ここで
、Ｓはセンダ、Ｒはレシーバ、Ｐ、ＭおよびＱはそれぞ
れ事前条件、ＭＳＧおよび事後条件である。同期通信は
、アクタ・システムにおける最小単位の処理である。 【０１６０】（２）送付による通信：スクリプト規則が
与えられ、センダのアクタの事前条件がレシーバのアク
タの事前条件より先に満たされた場合、通信は送付（ｄ
ｅｌｉｖｅｒｙ）を介して行われる。センダのアクタは
、その環境において構成されたメッセージを事前条件の
満足時に発行する。すると、そのスクリプト・インスタ
ンスは、「Ｓｅｎｔ」（送信済み）というスクリプト型
を用いて印が付けられ、ソフトコーダは、レシーバのア
クタに送付するために、その通信を待ち行列に加え、さ
らにセンダのアクタの事後条件が実行される。この通信
は、非同期通信とも呼ばれ、前の表記を用いて次のよう
に表すことができる。 Ｐ（Ｓ）＝＞Ｍ（Ｓ，Ｓｅｎｔ）＝＞Ｑ（Ｓ）（ｗａｉ
ｔ） Ｐ（Ｒ）＝＞Ｍ（Ｄｅｌｉｖｅｒｅｄ，Ｒ）＝＞Ｑ（Ｒ
） Ｍ（Ｓ，Ｓｅｎｔ）は、メッセージが、センダの環境に
おいてそれが送られるときに、構成されることを示す。 Ｍ（Ｄｅｌｉｖｅｒｅｄ，Ｒ）は、メッセージがＲによ
って受信された時、Ｒの環境は、送付されたメッセージ
からの環境を含めるために、一時的に拡大され、次に、
この一時的な環境において、Ｒの事後条件Ｑ（Ｒ）が実
行される。 【０１６１】アクタ間の一般的な通信モデルにおいて、
アクタは、いくつかの通信を平行して送受信などの処理
を行うことができる。ただし、これが所与のアプリケー
ションにとって望ましくないならば、この問題を避ける
ようにスクリプト規則を設計することができる。アクタ
の事後条件が平行して実行されたために、現在のアクタ
環境の同一の属性に多重に変更が起こる場合、矛盾の可
能性がある。このような矛盾は、実行時に容易に検出さ
れるので、目的のアプリケーションにとって容認できる
技法を用いて解決することができる（無作為抽出、多重
値、変更上書き、エラー信号など）。 【０１６２】問題のアクタが関与するテープ・プログラ
ムの実行中に、利用者が、アクタを削除したり、アクタ
の記述を変更したりすると、可能な別の矛盾例が発生す
る。問題は、その変更が特定のシナリオの実行に限られ
るのか、あるいはそのアクタのオリジナルの記述に対し
て報告された（グローバルな）ものか、ということであ
る。この矛盾は、利用者に局部的（ローカルな）変更か
全体的（グローバルな）変更かを選択させることによっ
て解決される。変更が局部的な場合、現在時刻のＡのデ
ータ空間だけが、Ａの将来の履歴のように影響を受けて
る。変更が全体的な場合、最初は、その変更が局部的に
行われ、アクタの履歴が空でなければ、その変更もＡの
初期のデータ空間の記述に報告されている。削除されて
いるアクタによって、その変更が、スクリプト規則の集
合の削除を必要とする場合、利用者はそれらの規則の削
除に関する確認させられ、そして手の施しようのない矛
盾を避けるために、テープ・プログラム実行の自動巻き
戻しが行われる可能性がある。 【０１６３】所与のテープ・プログラムの実行中に、実
行の履歴の中で以前に現れたスクリプト規則を削除しよ
うと思うことがある、つまり、このスクリプト規則に対
するスクリプト・インスタンスが存在するのである。ま
たは、その履歴が再び再生されれば、利用者は、そのス
クリプト規則の出現または他のスクリプト規則の異なる
仕方での出現を禁止したり、そのきっかけを作ったりす
ることになるような方法でスクリプト規則やアクタを編
集する可能性もある。この種の矛盾は、前記のように手
に終えない結果を招く可能性がある。実行の履歴を築く
ために既に使用された規則の編集には、その履歴の再構
築を必要とする可能性がある。修正された規則の集合を
用いては、アクタ・システムの現在の状態を回復できな
いこともある。この場合、テープ・プログラムの実行を
巻き戻し、そのアクタ・システムの匹敵する状態が回復
可能かどうかを検査するために古い履歴を再実行するこ
とが推奨される。 【０１６４】ＭＯＶＯＮ アクタのデータ空間および履歴：実現の実際性のために
、アクタに対して維持される履歴は、データ空間の変化
の測度（ｍｅａｓｕｒｅ）に基づく。 Ｄ（Ａ，ｔ） ｍＤＳ（Ａ，ｔ） ｄＤ（Ａ，ｔ１，ｔ２） ｄｍＤＳ（Ａ，ｔ１，ｔ２）
が、それぞれ時刻ｔにおけるアクタＡのデータ空間（Ｄ
）、時刻ｔにおけるこのデータ空間の測度（ｍＤＳの値
は数である）、時刻ｔ１およびｔ２の間のＡのデータ空
間における差（ｄＤ）、および時刻ｔ１およびｔ２の間
のアクタＡに対するデータ空間の変化の測度（ｄｍＤＳ
，数）である。ここで、アクタＡの履歴は、アクタＡの
データ空間に対する相当な変化の有限集合として定義す
ることができる。例えば、アクタＡの初期のデータ空間
： Ｄ（Ａ，ｔ０） が分かると、アクタＡに対し粒状性（ｅ）を有するサイ
ズｎの有限履歴は、 Ｈｅ（Ａ）＝｛（ｔｉ，ｄＤ（Ａ，ｔｉ，ｔｉ−１））
｜ｄｍＤＳ（Ａ，ｔｉ，ｔｉ−１）＞＝ｅ｝ １＝＜
ｉ＝＜ｎ として定義される。さらに、 Ｔ（Ｈｅ（Ａ））＝｛ｔｉ｝ １＝＜ｉ＝＜ｎは、Ａ
の履歴からのタイム・スタンプの集合を表す。つぎに、 Ｄ（Ａ，ｔｊ）＝Ｄ（Ａ，ｔ０）＋｛＋ｄＤ（Ａ，ｔｉ
，ｔｉ−１）｝ １＝＜ｉ＝＜ｊを用いて、Ａの中間
的なデータ空間が得られる。また、次のようなアクタＡ
に対するデータ空間の変化の空間効率的な記述を用いて
、アクタの履歴のモデルを洗練することが可能である。 【数３】 Ｈｅ，ｇ（ａ）により、粒状性ｅおよび効率ｇを有する
アクタ履歴のモデルが定義される。従って、時刻ｔにお
けるＡの中間的なデータ空間をＡの履歴から以下を用い
て導くことができる。 【数４】 アクタＡは、その初期のデータ空間およびデータ空間の
履歴が分かる時間の階段状の関数であるアクタのデータ
空間記述Ｄ（Ａ，ｔ）によって時刻ｔに完全に明記され
る。アクタの履歴は、そのアクタが変更された時刻とそ
れに対応するそのアクタのデータ空間への変更の記述と
のリストに過ぎない。その形式のアクタ・データ空間の
変化（ｄＤ）によって記述されるのは、新たなスロット
および（若しくは）新たな値の追加、ならびに（または
）新たなスロットおよび（若しくは）新たな値の削除、
ならびに（または）値の変更である。アクタＡのアドレ
スａ（ｔ）は、Ａのデータ空間の特別な要素であり、ア
クタ・システムにおいてＡに特有の識別子を与えるもの
である。 【０１６５】アクタ・システムにおける可逆性：アクタ
の履歴により、各アクタごとに限られた履歴管理機構が
与えられる。アクタ間の通信システムでは、アクタのデ
ータ空間は、そのアクタが伝達情報を送信したり処理し
たりするときに、変更できるに過ぎない。さらに、伝達
情報の送信および処理は、最小単位の処理である。従っ
て、アクタ・システムにおける各変更の範囲は、各通信
について完全に明記されるため、すべてのアクタのデー
タ空間の測度が固定値で制限されているという仮定の下
で、すべてのアクタの履歴を線形時間で維持することが
可能である。このモデルにより、維持されるアクタの履
歴の大きさを限度内で完全に可逆性の処理がサポートさ
れる。このモデルのコンピュータ処理に関する重要な利
点は、処理歴のアクタ間の分散であり、これによって、
分散アクタ・システムにおいて可逆的なコンピュータ処
理がサポートされる。 【０１６６】アクタ環境：アクタによるＧＲＡＳの実施
においては、時刻ｔにおけるアクタＡのデータ空間Ｄ（
Ａ，ｔ）を表すためにｌｅｔ環境を使用する。 （ｌｅｔ ａ１＝ｖ１，．．．，ａｎ＝ｖｎ；．．．）
ここで、ａｉはＡのスロットの記号的表現、ｖｉはそれ
に対応する値またはその値を表す表現、そしてｎは時刻
ｔにおけるスロットの総数であり、さらに「＝」記号は
値の割当を表す。時刻ｔにおけるＡのデータ空間の測度
は、ｍＤＳ（Ａ，ｔ）＝ｎであり、使用される履歴の定
義は、Ｈ１（Ａ）（ｅ＝１）である。アクタの環境によ
って、時刻ｔのそのアクタが完全に記述される。アクタ
の作用の記述は、そのアクタの環境と、そのアクタが演
ずるテープから利用できる作用とから全体的に引き出す
ことができる。 【０１６７】アクタの関係および接続：アクタは、双方
向性リンクによるフレーム表現を用いる関係として実現
される静的または動的な従属関係にも関与する。静的な
従属関係には、クラス・メンバーシップ（ＡＫＯ）、成
分メンバーシップ（ＣＯＭＰＯＮＥＮＴまたはＰＡＲＴ
−ＯＦ）、接続、テープ・メンバーシップおよびその他
が含まれる。動的な従属関係には、アクタ間の接続（例
えば、データ通信のための回線接続）が含まれる。なお
、応用分野に適合するようにアクタ間に新しい型の関係
を定義することもできる。新たな関係を表し作るために
属性として視覚表現の参照を利用することができる。 各種の関係に（グラフィックスの組み合わせによる）視
覚的な表現を（オプションで）与えるために、グラフィ
ックスの原形の有限集合が使用される。関係属性は、他
のアクタとの関係を定義するために使用されるアクタの
属性の集合である。例えばＣＯＭＰＯＮＥＮＴ（成分）
関係であるが、この場合、アクタの分解が、成分および
下位成分によって与えられる。各成分は、１つのアクタ
であり、従って、他のアクタと通信することができるが
、成分は、それを所有するアクタの物理的な部分でもあ
る（例えば、スピーカーと押しボタンを有する電話機）
。 【０１６８】ＶＳＭの関数 ＧＲＡＳシステムは、ＶＳＭモジュールによって利用者
の水準で実現される。ＶＳＭモジュールは、利用者の要
求を果たすためにさらに低い水準のモジュールを要求す
るユーザ・レベルの関数から成る。 【０１６９】特殊効果：作用の規則を洗練するために、
録音の最中かその後で特殊効果のソフトウェア・モジュ
ールを利用することができる。例えば、スクリプト規則
において、アクタ、事前条件、事後条件、転送されたメ
ッセージおよびデータを修正することができる。トラッ
キング装置の入力およびメニューの選択によって、その
変更結果が与えられる。一般スクリプトに対するアクタ
対の集合を定義するオーディション表現を生成するため
に特性の対話的な指定（例えば、属性の値に関するパタ
ン照合表現）を含む一般規則（Ｇｅｎｅｒａｌ Ｓｃｒ
ｉｐｔ）を洗練するために、さらに特殊効果を利用する
ことができる。 【０１７０】図６は、テープ生成（ＣＲＥＡＴＥ ＴＡ
ＰＥ）関数の流れ図である。テープ・生成関数は、ＭＯ
ＶＯＮにテープ・ビジュアル・オブジェクトを要求する
（作用ブロック６０１）。次に、ＭＯＶＯＮは、指名さ
れた新たなテープにフレーム構造体を割り当てる（作用
ブロック６０２）。ＭＯＶＯＮは、ロードされたテープ
のフレームにそのフレーム構造体をリンクする（作用ブ
ロック６０４）。そのフレームを環境に存在するビデオ
・モニタ（ｖｉｅｗ）のフレームにリンクすることによ
り、その新たなテープを現在のテープとする（作用ブロ
ック６０６）。新たなテープは、ソフトコーダにロード
（ＬＯＡＤ ＴＡＰＥ参照）され（作用ブロック６０８
）、未来のリールと過去のリールにリンクされ、シミュ
レーション・カウンタが内部的に設定される。ＭＯＶＯ
Ｎにより、新たなテープが表示され（作用ブロック６１
０）、ビデオ・モニタの再表示が行われる。 【０１７１】図７は、テープ・ロード関数（ＬＯＡＤ
ＴＡＰＥ）の流れ図である。ロード・テープ関数により
テープがロードされることになる（作用ブロック７０２
）。テープの過去のリールおよび未来のリールが、ソフ
トコーダの過去のリール要素および未来のリール要素に
リンクされ、スクリプトのインスタンスおよび規則がソ
フトコーダに組み込まれることになる（作用ブロック７
０４）。テープ・カウンタの値を用いて、シミュレーシ
ョン・カウンタが設定される。ＭＯＶＯＮにより、その
テープから既存のアクタがビデオ・モニタの適切な表示
部位に表示される（作用ブロック７０６）。ソフトコー
ダは、初期シミュレーション・モード、動画の速度およ
び詳細水準を随意選択するために、予備的な評価を行う
（作用ブロック７０８）。再生（ＰＬＡＹ）関数（後述
）が呼び出され（作用ブロック７１０）、ＭＯＶＯＮに
より、実行可能なスクリプトの最初の集合からアクタが
それらに関係付けられたｖｉｅｗ（スクリプト・タッグ
による）にリンクされ、アクタ、適切なｖｉｅｗにおい
て交わされるメッセージおよびデータが表示される（作
用ブロック７１２）。 【０１７２】図８は、テープ・コピー関数（ＣＯＰＹ
ＴＡＰＥ）の流れ図である。まず、コピー・テープ関数
は、コピーが取られるべき元となるテープを要求し（デ
フォルトにより現在のテープがロードされる）、次に元
のテープをコピーする先のテープを要求する（作用ブロ
ック８０２）。コピー先のテープが既に存在し（判断８
０４）、かつこのテープを再利用することになった（判
断８０６）場合、元のテープのフレーム構造体が、先の
テープのフレーム構造体へと（再利用を伴う）合併され
る（作用ブロック８０８）。先にテープが存在しなけれ
ば、新たなフレーム構造体が割り当てられ（作用ブロッ
ク８１０）、そのフレームが、ロードされたテープのフ
レームにリンクされ（作用ブロック８１２）、元のテー
プのフレーム構造体が新たなコピー先の構造体へと合併
される（作用ブロック８０８）。 【０１７３】図９は、テープ削除関数（ＲＥＭＯＶＥ
ＴＡＰＥ）の流れ図である。テープ削除関数は、取り除
くべきテープを決定し（作用ブロック９０２）、そのテ
ープと共にアクタも削除するべきかどうかを判断する（
作用ブロック９０４）。ＭＯＶＯＮは、そのテープのフ
レーム構造体をロードされたテープのフレームから切り
離す（作用ブロック９０６）。テープと共にアクタも削
除するべき場合（作用ブロック９０８）、この関数は、
そのテープ中で使用され、かつ他のロードされたテープ
においては使用されないアクタをすべて取り除く（削除
する）（作用ブロック９１０）。一方、アクタはテープ
と共に削除すべきでない場合、そのテープで使用され他
のロードされたテープでも使用されるアクタは切り離す
が、他のロードされたテープへのリンクは維持する（作
用ブロック９１２）。次に、そのテープのフレーム構造
体を削除し（作用ブロック９１４）、他のフレームへの
そのリンクをすべて消去する。 【０１７４】図１０は、テープ・ファイル貸出関数（Ｒ
ＥＮＴ ＴＡＰＥ ＦＩＬＥ）の流れ図である。テープ
・ファイル貸出関数は、テープ・ファイル・フォーマッ
トおよびそのテープ・ファイルへのパスを要求する（作
用ブロック１００２）。そのファイルに格納されている
テープの数が決められる（作用ブロック１００４）。各
テープに対しテープ生成関数が呼び出される（作用ブロ
ック１００６）。ＭＯＶＯＮが、テープがファイルから
生成されるのに必要とされるアクタの生成または（再利
用を伴う）合併を行う（作用ブロック１００８）。ＭＯ
ＶＯＮは、それらのテープによって必要とされる各ビュ
ーに対しビデオ・モニタを生成し、テープ・ファイルか
らのリンク情報によってアクタをビューにリンクする（
作用ブロック１０１０）。次に、ソフトコーダが、テー
プ・ファイルから読み出されたスクリプト構造体に従っ
て、各テープを生成しリンクする（作用ブロック１０１
２）。 【０１７５】図１１は、アクタ生成関数（ＣＲＥＡＴ
ＡＣＴＯＲ）の流れ図である。アクタ生成関数は、生成
されるべきアクタの識別情報を要求する（作用ブロック
１１０２）。ＭＯＶＯＮが、アクタのフレーム構造体を
割り当て、最小の内部属性およびグラフィカルな属性を
備えるように、その構造体を初期化する（作用ブロック
１１０４）。次にＭＯＶＯＮは、そのアクタ・フレーム
構造体を現在のテープ（作用ブロック１１０６）および
現在のビュー（作用ブロック１１０８）にリンクする。 ＭＯＶＯＮは、次に、そのアクタが生成された現在のビ
ューと同じビューをサポートするすべてのビデオ・モニ
タに、そのアクタを表示する（作用ブロック１１１０）
。 【０１７６】図１２は、アクタ選択関数（ＳＥＬＥＣＴ
ＡＣＴＯＲ）の流れ図である。このアクタ選択関数は
、アクタ選択の型を要求する（作用ブロック１２０１）
。新たなオブジェクトが選択される場合（判断１２０２
）、アクタ生成関数が使用される（作用ブロック１２０
４）。すべてのオブジェクトが選択される場合（判断１
２０２）、ＭＯＶＯＮは、ロードされた全アクタ（バッ
クステージ・アクタ）を現在のビューにリンクし、それ
らを対応するビデオ・モニタに表示する（作用ブロック
１２０６）。アクタの選択にキーワード探索を用いる場
合、キーワードを入力するように利用者を促す（作用ブ
ロック１２０８）。一致するアクタが見つからない場合
（判断１２１０）、新たな選択が必要になる（作用ブロ
ック１２０２）。一致するアクタが見つかった場合、特
定のアクタが要求され（作用ブロック１２１４）、（１
つでもある場合）そのアクタが、現在のビューにリンク
されて表示される（作用ブロック１２１６）。 【０１７７】図１３は、アイコン状態設定関数（ＳＥＴ
ＡＣＯＮ ＳＴＡＴＥ）の流れ図である。この関数は
、実行された直後のスクリプト・インスタンスの集合の
中の１つのスクリプトを要求する（作用ブロック１３０
２）。つぎに、そのスクリプトからセンダのアクタまた
はレシーバのアクタを要求する（作用ブロック１３０４
）。ＭＯＶＯＮが、前記のアクタによって使用される現
在のアイコン決定し、このアイコンに対する可能なアイ
コン状態の集合をアイコン・ライブラリから検索する（
作用ブロック１３０６）。次にアイコン状態設定関数が
、可能なアイコン状態の集合の中から１つのアイコン状
態を要求する（作用ブロック１３０８）。そのスクリプ
ト集合について、ソフトコーダのアンドゥ関数が呼び出
される（作用ブロック１３１０）。ソフトコーダは、選
ばれたスクリプトの事後条件リストにおけるアクタの状
態を変更するために、条件表現を追加する（作用ブロッ
ク１３１２）。ソフトコーダの再生関数が呼び出され、
ＭＯＶＯＮが、アクタへの対応する変更を変更されたス
クリプト定義の実行結果として表示する（作用ブロック
１３１４）。 【０１７８】図１４は、アクタ接続関数（ＣＯＮＮＥＣ
Ｔ ＡＣＴＯＲＳ）の流れ図である。アクタ接続関数は
、実行直後のスクリプトの集合の中の１つのスクリプト
（作用ブロック１４０２）と接続の型（記号的名称）と
を要求する（作用ブロック１４０４）。その接続の型に
対応するグラフィック表現（例えば、単線、２重線、会
議線）が決定される（作用ブロック１４０６）。接続す
るアクタ数が要求される（作用ブロック１４０８）。接
続するアクタが要求される（作用ブロック１４１０）。 ソフトコーダのアンドゥ関数が呼び出される（作用ブロ
ック１４１２）。「ＣＯＮＮＥＣＴ｛接続型｝［選択さ
れたアクタのリスト］」という形式の条件が選択された
スクリプトの事後条件リストに加えられる（作用ブロッ
ク１４１４）。ソフトコーダの再生（ＰＬＡＹ）関数が
呼び出され（作用ブロック１４１６）、変更されたスク
リプトの実行結果として、選択されたアクタ間の接続が
、生成されて、適切なビューに表示される。 【０１７９】図１５は、アクタ視覚化関数（ＭＡＫＥ
ＡＣＴＯＲＳ ＶＩＳＩＢＬＥ）の流れ図である。この
関数は、実行直後のスクリプトの集合のうちの１つのス
クリプトを要求する（作用ブロック１５０２）。視覚化
するべきアクタが要求される（作用ブロック１５０４）
。ソフトコーダのアンドゥ関数が呼び出される（作用ブ
ロック１５０６）。 選択されたスクリプトの事後条件リストに「ＶＩＳＩＢ
ＬＥ［選択されたアクタのリスト］」という形式の条件
を追加する（作用ブロック１５０８）。ソフトコーダの
再生関数が呼び出され（作用ブロック１５１０）、その
変更されたスクリプトの実行結果として、前記のアクタ
が視覚化され（るか、または恐らくは生成された上で視
覚化され）て、適切な表示部位に表示される。 【０１８０】図１６は、アクタ状態の設定関数（ＳＥＴ
ＳＴＡＴＥ ＯＦ ＡＣＴＯＲ）の流れ図である。ア
クタ状態設定関数は、実行直後のスクリプト・インスタ
ンスの集合の中からスクリプトを１つ要求する（作用ブ
ロック１６０２）。つぎに、そのスクリプトからセンダ
またはレシーバのアクタを要求する（作用ブロック１６
０４）。ＭＯＶＯＮが、スロット名が要求される前記の
アクタから現在のスロットの集合を決定する（作用ブロ
ック１６０６）。このスロットは、そのアクタの状態を
変更するために使用される。そのスロットに対する新た
な値が決定される（作用ブロック１６０８）。そのスク
リプト集合にソフトコーダのアンドゥ関数が呼び出され
る（作用ブロック１６１０）。ソフトコーダは、そのア
クタのスロットを新たな値に変更するために、選択され
たスクリプトの事後条件リストにおいて条件表現を追加
する（作用ブロック１６１２）。その追加される条件は
、「ＳＥＴ｛スロット名｝｛スロット値｝」と言う形式
のものである。ソフトコーダの再生関数が呼び出され、
ＭＯＶＯＮが、そのアクタに対応する変化を変更された
スクリプト定義の実行結果として表示する（作用ブロッ
ク１６１６）。 【０１８１】図１７は、メッセージ経由のデータ渡し関
数（ＰＡＳＳ ＤＡＴＡ ＶＩＡ ＭＥＳＳＡＧＥ）の
流れ図である。メッセージ経由のデータ渡し関数は、実
行直後のスクリプトの集合からスクリプトを要求する（
作用ブロック１７０２）。次に、前記のスクリプトのセ
ンダのアクタからのスロット名が要求される（作用ブロ
ック１７０４）。このスロット［ｓｌｏｔ−ｆｒｏｍ］
が、もう一方のアクタに送られるべきデータとして使用
される。レシーバのアクタからのスロット［ｓｌｏｔ−
ｔｏ］の名前が要求される（作用ブロック１７０６）。 そして、ソフトコーダのアンドゥ関数が呼び出される（
作用ブロック１７０８）。センダのアクタのスロット値
がそのメッセージを介して渡されること、およびそれが
受信されたときのシンボル名が｛ｓｌｏｔ−ｆｒｏｍ｝
であることを示す「｛ｓｌｏｔ−ｆｒｏｍ｝｛ｓｌｏｔ
−ｆｒｏｍ−ｖａｌｕｅｓ｝」という書式が、選択され
たスクリプトのメッセージ表現に追加される（作用ブロ
ック１７０８）。 「ＳＥＴ｛ｓｌｏｔ−ｔｏ｝｛ｓｌｏｔ−ｆｒｏｍ｝」
という形式の条件が、選択されたスクリプトに対しレシ
ーバのアクタの事後条件リストに追加される（作用ブロ
ック１７１０）。 ソフトコーダの再生関数が呼び出され（作用ブロック１
７１２）、変更されたスクリプトの実行結果として、セ
ンダのアクタからのスロットの値が、レシーバのアクタ
の［ｓｌｏｔ−ｔｏ］の値を更新するために渡されて、
適切な表示部位に表示される。 【０１８２】図１８は、クローン・アクタ関数（ＣＬＯ
ＮＥ ＡＣＴＯＲ）の流れ図である。クローン・アクタ
関数は、コピーされるべきアクタを要求する（作用ブロ
ック１８０２）。ＭＯＶＯＮが、そのアクタに対するフ
レーム構造体を割り当てる（作用ブロック１８０４）。 ＭＯＶＯＮは、コピーされるアクタに対するアドレスを
、基となるアクタの名前とそのアドレスを唯一のものと
するコピー番号とを用いて生成する（作用ブロック１８
０６）。ＭＯＶＯＮは、新たなアクタを現在のｖｉｅｗ
にリンクし、コピーされたアクタを同じｖｉｅｗを有す
るすべてのビデオ・モニタに表示する（作用ブロック１
８０８）。 【０１８３】図１９は、アクタ合併関数（ＭＥＲＧＥ
ＡＣＴＯＲ）の流れ図である。アクタ合併関数は、他の
アクタ｛ａｃｔ−ｔｏ｝へと合併されるべきアクタ｛ａ
ｃｔ−ｆｒｏｍ｝を要求する（作用ブロック１９０２）
。ＭＯＶＯＮが、それらのアクタ・フレーム構造体を合
併する（作用ブロック１９０４）。ソフトコーダが、ａ
ｃｔ−ｆｒｏｍのアドレスへの参照をすべてａｃｔ−ｔ
ｏへのアドレスで置き換える。（作用ブロック１９０６
）。 【０１８４】図２０は、チャネル設定関数（ＳＥＴ Ｃ
ＨＡＮＮＥＬ）の流れ図である。チャネル設定関数は、
そのチャネルを変更するビデオ・モニタを要求し（作用
ブロック２００２）、さらにチャネルの選択を要求する
（作用ブロック２００４）。選択されたチャネルが「全
チャネル」の場合（判断２００６）、ソフトコーダが、
デフォルトのスクリプト構造体のタグ（名前）をそのビ
デオ・モニタにおける「Ｓｉｄ」に設定し（作用ブロッ
ク２００８）、さらにＭＯＶＯＮが、そのチャネルの指
定を空にしたまま、そのビデオ・モニタを表示する（作
用ブロック２０１０）。選択されたチャネルが「新たな
チャネル」の場合、それに対応するスクリプト構造体の
タグが決定される（作用ブロック２０１２）。次に、ソ
フトコーダは、デフォルトのタグをビデオ・モニタにお
ける要求されたタグに設定する（作用ブロック２０１４
）。次に、ＭＯＶＯＮが、ビデオ・モニタを表示し、そ
の表示にチャネル・タグを示す（作用ブロック２０１６
）。このビデオ・モニタにおいて記録する場合、そのタ
グは、そのビデオ・モニタのｖｉｅｗとこのｖｉｅｗに
おいて生成されたスクリプト構造体の集合との間の相互
参照の役に立つ。 【０１８５】図２１は、変換テーブル関数（ＴＲＡＮＳ
ＬＡＴＩＯＮ ＴＡＢＬＥ）の流れ図である。テーブル
操作に対する要求がＶＳＭを介して利用者に送られる（
作用ブロック２１０２）。同時に発生するスクリプトの
現在のグループの中から１つのスクリプトを求める要求
が送られる（作用ブロック２１０４）。センダのアクタ
が、レシーバのアクタと同一でない場合（判断２１０６
）、ＶＳＭを介してエラー・メッセージが表示されて（
作用ブロック２１０７）、この関数は終了する。その他
の場合は、スクリプトによって、アクタ（センダ＝レシ
ーバ）に対し内部で処理する仕事が記述され、変換テー
ブルを生成または編集することができる（判断２１０８
）。（判断２１０８において）スクリプト中に変換テー
ブルの表現が全く存在しない場合、新たな変換テーブル
の生成が必要となる。この場合、変換テーブルへの入り
口スロットとして使用するためのアクタの状態（スロッ
ト１）が選択され（作用ブロック２１１０）、さらに変
換テーブルによって変換された値の結果を格納するため
のアクタの状態（スロット２）が選択される（作用ブロ
ック２１１２）。データ変換のための値のリストが要求
される（作用ブロック２１１４）。変換テーブルが割り
当てられ、（新たな）変換表現が選択されたスクリプト
に挿入される（作用ブロック２１１６）。（判断２１０
８において）変換テーブルの編集作用が選択され、さら
に（判断２１０９において）スクリプト中に変換テーブ
ルの表現が存在しない場合、エラー・メッセージが表示
されて（作用ブロック２１１１）、この変換関数は終了
する。 （判断２１０８において）変換テーブルの編集作用が選
択され、（判断２１０９において）スクリプトに変換テ
ーブルの表現が存在する場合、ＭＯＶＯＮによってＶＳ
Ｍを介して変換テーブルが編集可能な形式で表示され、
利用者によって編集される（作用ブロック２１１３）。 次に、ソフトコーダが、修正された変換テーブル表現を
含むように、スクリプトの事後条件リストを変更する（
作用ブロック２１１５）。変換テーブル表現は、「ｓｅ
ｔ ｓｌｏｔ−２（ｓｅｌｅｃｔ ｓｌｏｔ−１）｛（
ｅｎｔｒｙ，値の表現）の対のリスト｝」という形式で
ある（作用ブロック２１１７）。 【０１８６】ビデオ・モニタは、アクタ間の一組の処理
を表示したり、テープへと視覚的に記録するために使用
される。ビデオ・モニタは、シミュレーションまたは生
成されているシステムの単純化した描画を表示または記
録することができる。ビデオ・モニタは、再生の特定の
部分のズーム・イン（拡大）およびズーム・アウト（縮
小）を行う機構を与えるために、表示部位の間の切り替
えに使用されるチャネル制御と詳細水準の制御とを備え
ている。記録モードでは、チャネル制御変更は画面上で
異なる視点または視野を得るためのカメラの変更に相当
し、詳細水準の変更は、そのカメラへのズーム・イン／
ズーム・アウト制御に相当する。ビデオ・モニタは、設
定および変更を動的に行うことができる種々の特性を持
っている。例えば、利用者は、ビデオ・チャネルを設定
することができる。モニタのチャネルを変更することに
より、それに表示される表示部位が変化する。大きさ、
色（カラーの場合）、表題、アニメーションの水準およ
び速さ、メモリの大きさ（即ち、モニタ上に一度にいく
つのイベントを思い出すことができるかという持続性）
、静的な表示と動的な表示、表示される詳細の解像度ま
たは水準、およびデフォルトのメッセージ名の位置（セ
ンダおよびレシーバのアクタに関するメッセージ表示の
デフォルトの位置が変えられる）などの特性は、すべて
利用者がビデオ・モニタからメニューまたはアイコンに
よって選択することが可能である。 【０１８７】ビデオ・モニタは、テープの再生、活性化
、または表示、処理のためのステージの記録または設定
に使用することが可能である。ＶＳＭインタフェースに
よって、テープの生成、編集、表示、および実行に対す
る直接的な制御が与えられる。新たな指示の入力を記録
することによって、実行中に変更を取り入れることがで
きる。記録または再生の間に、テープの詳細水準を（例
えば、スライド・バーを用いて）変化させて、高い詳細
水準の表示の間にズーム効果を与えることができる。ビ
デオ・モニタは、「再生（ｐｌａｙ）」モードで活動さ
せられているイベントおよび特殊効果を変更するための
描画／編集板として役立つ。ビデオ・モニタは、同時に
何百ものオブジェクトを表示することができるが、通常
は、２０乃至３０以下のオブジェクトが、標準的なグラ
フィックス表示技術に基づいた良好な視覚的図式の目安
である。１つのテープで３０以上のオブジェクトが必要
な場合は、特殊効果を使用することができる。特殊効果
によって、個々の視覚的な対象の表示／非表示が自在に
可能である。 【０１８８】ＧＲＡＳのビデオ・モニタは、多数のビュ
ーポイントを用いて実現される。設計の使用には大きな
ものもあるので、利用者から不要な情報を隠すために射
影（多重表示）がサポートされている。ＧＲＡＳシステ
ムは、同時の記録およびアニメーションを多重表示でサ
ポートする。各ビデオ・モニタが、記録およびアニメー
ションに使用されるビデオ・チャネルと抽象（要約）水
準とを持っている。ウィンドウとグラフィックスをサポ
ートし、さらに視覚的なオブジェクトのみならずビデオ
・モニタも実現するために、目標とするコンピュータ・
システム（例えば、ＳｕｎＶｉｅｗＴＭ、Ｘ Ｗｉｎｄ
ｏｗ ＳｙｓｔｅｍＴＭ、ＯＰＥＮ ＬＯＯＫＴＭ、Ｓ
ｙｍｂｏｌｉｃｓ Ｗｉｎｄｏｗｓ、ＸｅｒｏｘＷｉｎ
ｄｏｗｓ）によって専用のウィンドウおよびグラフィッ
クスのシステムが使用される。ＳｕｎＶｉｅｗはサン・
マイクロシステムズ（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍ
ｓ）の商標であり、Ｘ Ｗｉｎｄｏｗ Ｓｙｓｔｅｍは
ＭＩＴの商標であり、ＯＰＥＮ ＬＯＯＫはＡＴ＆Ｔの
商標である。 【０１８９】多重ビューポイントの特徴の応用により、
要約表示と詳細な表示との間にズーム操作が提供される
。例えば、提出された表示内容の利用者ならば、高水準
の要約表示を見ることになり、表示内容の開発者であれ
ば、内部の交換構造を示す詳細な表示を見るであろう。 ２つの表示を「ハードウェア」の動作と「ソフトウェア
」の動作とを分離するために使用しても良い。 【０１９０】ＧＲＡＳウィンドウなどの使用により、ウ
ィンドウの使用が高められる。例えば、ＳｕｎＷｉｅｗ
下のＳｕｎワークステーションは、ウィンドウを６４ま
で持つことができる。Ｓｕｎ上のＧＲＡＳは、ＶＳＭ／
ＧＲＡＳアプリケーションと同時に実行中の他のＳｕｎ
Ｗｉｅｗの（メール、テキスト編集、およびその他の）
アプリケーションによって残りのウィンドウを使用しな
がらでも、１０以上のビデオ・モニタ・ウィンドウを使
用することができる。 【０１９１】Ｌｉｓｐが動作する機械であれば、数百の
ウィンドウを持つことも可能である（この数はディスク
の容量によってのみ制限される）。Ｌｉｓｐ機上のＶＳ
Ｍ／ＧＲＡＳは、（例えば、多重表示のように）希望の
数だけビデオ・モニタを持つことができる。この概念は
、同じシナリオや異なるシナリオの実行のいくつかの異
なる表示を与える異なるチャネルに調節されたいくつか
のテレビ・モニタを持つことに似ている。 【０１９２】編集ルーム（Ｅｄｉｔｉｎｇ Ｒｏｏｍ）
によって、テープ・シェルフのテープ、およびビデオ・
テープまたはフィルムの編集の類似性を用いてテープを
編集・操作するために使用される作用素の集合に直接ア
クセスすることができる。そして、テープを編集を行う
ことが、プログラムの操作に対する唯一の手段である。 アクタおよびアクタ環境の実現、ならびにアクタ間の通
信過程におけるアクタの使用によって与えられる実行状
況の結末に基づいて、各スクリプト構造体は、ソフトコ
ーダの仮想機械によって実行される独立した単位処理と
して扱うことが可能であり、基本的なプログラム要素と
して操作することができる。テープ・プログラムには、
スクリプト構造体の閉集合が常にある。２つのテープを
接着することにより、おそらく両方のテープからさらに
機能性が得られることになり、これによって、ＧＲＡＳ
の背景において機能的統合が半自動化の可能な処理とな
る。テープを２つのサブテープに切断することも可能で
あるが、両方のサブテープが完結し、一貫性が維持され
る位置でテープを切断する必要があるので、いっそう注
意が必要となる。テープの切断および接着により、別個
の作業努力による機能性を結合する簡単な機構が与えら
れる。このことは、アクタどうしを合併できることと結
びついて、プログラム・システムにおける新たな特徴の
連続的な統合に取り組む強力な骨組みを提供する。 【０１９３】ソフトコーダ（ＳｏｆｔＣｏｄｅｒ）ＧＲ
ＡＳのソフトコーダは、テープ・プログラムのスクリプ
ト規則（Ｓｃｒｉｐｔ Ｒｕｌｅ）と一般スクリプト（
Ｇｅｎｅｒａｌ Ｓｃｒｉｐｔ）からなる未来のリール
、およびテープ・プログラムの実行履歴をたどるアンド
ゥ可能なスクリプトの集合からなる過去のリールを備え
ている。過去のリールでは、すべてのスクリプト・イン
スタンスが、逆向きの実行が可能である。つまり、すべ
てのスクリプト・インスタンスに、Ｓｕｎｄｏ表現とＲ
ｕｎｄｏ表現がある。過去のリールには、実行の履歴と
その実行中に入力されたデータが入っているので、試験
用のシナリオとして使用することができる。 【０１９４】図２９は、ソフトコーダの視覚的な表現で
ある。テープは、記録されたスクリプト規則と一般スク
リプトの集合であり、過去のリール２９１０は、シミュ
レーション中の現在時刻以前にシミュレータによって選
択され発動されたスクリプト・インスタンスに相当し、
未来のリール２９２０には、残りの規則か、またはシミ
ュレーションの生成モードにある完全なテープ・プログ
ラムの何れかが入っている。各リールは、時計回りに回
転し、シミュレーション中は、一度に１ステップ以上前
進する。固定の（再生）ヘッド２９３０によって、スク
リプト規則と一般規則の集合を読んで実行する。アンド
ゥ・ヘッド２９５０により、スクリプト・インスタンス
にアンドゥを行う情報で印を付ける。記録ヘッド２９４
０は、新たな規則の記録および挿入を行うために何時で
も利用することができる。先取りヘッド２９６０は、シ
ミュレーションにおいて次に発動するべき規則の集合を
捜すのに使用される。 【０１９５】ソフトコーダは、次の制御を有する「制御
パネル」を備えている。自動再生：テープ・プログラム
を現在の位置から最後まで（停止位置まで）選択された
アニメーション速度で自動的に再生する。図２２は、自
動再生制御関数（ＡＵＴＯＰＬＡＹ）の流れ図である。 自動再生関数は、テープ・プログラムの最後に到達する
か、または自動再生の開始後に停止関数が呼び出される
まで（判断２２０４）、再生関数を繰り返し呼び出す（
作用ブロック２２０２）。 【０１９６】再生：現在発動可能な動作の規則の集合を
実行することによって一度に１ステップ（１フレーム）
だけテープの再生を行う。図２３は、再生制御関数（Ｐ
ＬＡＹ）流れ図である。再生関数は、再生の背景的条件
を定義する次の変数を確認する（作用ブロック２３０２
）。 即ち、ロードされた現在のテープおよびそのリール（未
来のリールおよび過去のリール）、現在のアニメーショ
ン速度、シミュレーション・モード、アニメーションお
よびシミュレーションの水準である。次に、その再生の
背景的条件において、再生関数は、スクリプト規則と一
般スクリプトの適切な集合を未来のリールから見つける
（作用ブロック２３０３）（このシミュレーション・モ
ードの関数としての動作の次の詳細な説明を参照のこと
）。そのスクリプトの集合が空の場合（判断２３０４）
、テープ・プログラムの最後に達したことが利用者に知
らされて（作用ブロック２３０５）、再生関数が終了す
る。さらにスクリプトが利用できる場合（作用ブロック
２３０６）、テープ・プログラムの実行の他の変形が可
能であることが利用者に知らされて（作用ブロック２３
０７）、再生関数が終了する。スクリプトの適切な集合
が空でない場合（判断２３０４）、そのスクリプトが再
生され（作用ブロック２３１０）（次の詳細な説明を参
照のこと）、アニメーション速度によりシミュレータを
待たせる必要がある場合（判断２３０８）、スクリプト
の再生の前に時間的遅延が導入され（作用ブロック２３
０９）、それから再生関数を終える。 【０１９７】記録：新たな通信を記録し、それを自動的
に現在のテープ位置に挿入する。図２４は、記録関数（
ＲＥＣＯＲＤ）の流れ図である。記録関数は、記録の背
景条件を定義する次の変数をまず確認する（作用ブロッ
ク２４０２）。即ち、現在のテープ・プログラム、現在
のビューおよびチャネル、現在のアニメーション、シミ
ュレーションおよび記録の水準を確認する。次に、記録
関数は、記録中の新たな通信に対するセンダのアクタを
要求する（作用ブロック２４０３）。センダが指定され
ると（判断２４０５）、そのアクタを（オーディション
処理によって）確認するか、または生成するかする（作
用ブロック２４０６）。センダが指定されなければ、記
録関数は終了させられる。センダのアクタが分かると、
レシーバのアクタを要求する（作用ブロック２４０７）
。レシーバのアクタが指定されると（作用ブロック２４
０８）、それは確認されるかまたは生成される（作用ブ
ロック２４０９）。指定されない場合、記録関数は終了
する。次に、記録関数は、スクリプト規則を選択するよ
うに要求する（作用ブロック２４１０）。スクリプトが
全く指定されない場合（判断２４１１）、この関数は終
了する。指定された場合、スクリプト規則または一般ス
クリプトが生成されが、それがない場合、既存のものか
らクローンが生成させる（作用ブロック２４１２）。新
たなスクリプトがテープ・プログラムの未来のリールに
挿入され（作用ブロック２４１３）、再生関数が呼び出
される（作用ブロック２４１５）。最後の記録関数以来
はじめて停止関数が呼び出された場合（作用ブロック２
４１６）、記録関数は停止するが、そうでなければ、記
録関数は再開する（作用ブロック２４０１）。 【０１９８】停止：現在のテープに対し行っている自動
実行、記録またはアンドゥを終了させる。図２５は、停
止制御関数の流れ図である。停止関数は、割り込みによ
って起動される。即ち、停止ボタンが押されると（判断
２５０２）、停止の事象が待ち行列に加えられる（作用
ブロック２５０３）。前述のように、再生（自動再生）
、記録、およびアンドゥ（自動アンドゥ）の関数も停止
事象の有無を確認する。 【０１９９】カウンタ：テープの開始から実行されたス
テップ数を示す。カウンタは、入力素子でもあり出力素
子でもある。カウンタを特定の位置に設定すると、テー
プをその位置まで自動的に進めたり巻き戻したりする。 図２６は、カウンタ制御関数の流れ図である。カウンタ
関数は、表示か設定かによって２通りに呼び出すことが
できる（判断２６０２）。表示の場合、カウンタ関数は
現在のシミュレーション計数を得て（作用ブロック２６
０４）、カウンタの表示を更新する（作用ブロック２６
０５）。ここで、現在のシミュレーション計数は、現在
のテープ・プログラムの開始以来経過したシミュレーシ
ョン時間単位の数である。カウンタの設定の場合、カウ
ンタ関数は、カウンタ値を要求する（作用ブロック２６
０６）。カウンタ値が現在のシミュレーション計数を越
える場合（作用ブロック２６０７）、所望のカンウタ値
に達するか、停止関数が呼び出されるか、またはテープ
の終わりに達するまで、自動再生関数が呼び出される（
作用ブロック２６０８）。それ以外の場合、所望のカウ
ンタ値に達するまで、自動アンドゥ関数が呼び出される
（作用ブロック２６０９）。 【０２００】アンドゥ：通信の最後の集合（起動された
スクリプト・インスタンスの最後の集合）の影響を取り
消す。最終ステップを巻き戻し、最終グループの処理の
影響を逆にする。図２７に、アンドゥ制御関数（ＵＮＤ
Ｏ）の流れ図を示す。アンドゥ関数は、次の変数からア
ンドゥの背景条件を確認する（作用ブロック２７０２）
。即ち、シミュレーション・モード、シミュレーション
水準、現在のテープ・プログラム（未来のリールおよび
過去のリール）、多重ビューおよびアニメーションの水
準を確認する。次に、アンドゥ関数は、過去のリールか
ら復元されるべきスクリプト・インスタンスの集合を得
る（作用ブロック２７０３）。次に、アンドゥ関数は、
復元されるべきスクリプト・インスタンスの集合に対し
、１）そのスクリプト集合に関与するすべてのアクタの
データ空間をこのスクリプト集合の実行時刻に先立つシ
ミュレーション時刻におけるそれらのデータ空間にまで
戻すとともに、２）そのスクリプト・インスタンスが視
覚的な副作用を有する場合、対応するグラフィックスの
アンドゥ関数を実行する（作用ブロック２７０４）。次
に、アンドゥ関数は、過去のリールから前記のスクリプ
ト・インスタンスを削除し（作用ブロック２７０５）、
現在のシミュレーション計数および現在のスクリプト集
合を更新する（作用ブロック２７０６）。アンドゥ関数
に関する説明は、他に次のシミュレーション・モードの
詳細説明にもある。 【０２０１】自動アンドゥ：テープの始まりか、または
停止ボタンでテープを停止させるまで自動巻き戻しを行
う。また、自動アンドゥは、自動実行の影響を選択され
たアニメーション速度で完全に逆にする。図２８は、自
動アンドゥ関数（ＡＵＴＯＵＮＤＯ）の流れ図である。 自動アンドゥ関数は、過去のリールがなくなるか、また
は停止関数が呼び出されるまで（判断２８０４）、アン
ドゥ関数を繰り返し呼び出す（作用ブロック２８０２）
。 【０２０２】ＵＮＤＯおよびＡＵＴＯＵＮＤＯは、完全
なアンドゥ機構である。再生（およびその視覚的な副作
用）の影響は、何れかの制御を使用している間に完全に
元どうりになる。これにより、デバッグおよび検査に対
する簡単で効果的な手段が与えられる。シナリオを途中
で停止させ、特定の点まで巻き戻し、変更してから、マ
ウスを数回クリックして先を続けることができる。オブ
ジェクトの状態の変化および処理の動的なアニメーショ
ンによって、デバッグまたは検査の間に、または活動し
ている対象を単に見ている間に、視覚的なフィードバッ
クが連続的に与えられる。 【０２０３】仕様の誤りは、シミュレーションの後続部
分が間違っているか、または矛盾することを利用者に警
告する警告メッセージが印字される契機となる。この不
完全性を（一時的に）無視して、設計の他の要素を継続
することは利用者の自由である。シミュレーション・エ
ラーは、誤ったデータ、不正な規則または規則の不正な
組み合わせの何れかによって発生する。利用者は、アン
ドゥや再生を行って仕様に目を通し、間違ったデータま
たは規則の場所を突き止めたのち、それらをその場で編
集し、さらに再生を用いてシミュレーションを継続する
ことができる。 【０２０４】ＶＳＭの範囲内でソフトコーダの仮想機械
を使用することにより、利用者は、その動作の例の中か
らプログラムを指定することが許される。ＶＳＭにおけ
る画像的なシミュレーションは、画像フレームの単純な
列ではなく、「プログラム可能な映画」である。つまり
、利用者の入力データによって、映画の結末は異なった
ものになる。 【０２０５】特定のシナリオの各ステップを順番に実行
すると、そのシナリオ例が新たに再生されるが、その再
生は、入力されたとおり行われるが、前に供給されたア
クタ入力またはその特定のシナリオに関係する他の例の
シナリオ入力がある場合、それによって修正されたとお
りに行われる。その例によって記述される動作は、さら
にアクタのデータを追加したり、模範的なシナリオを追
加することによって、対話的に１つのプログラムへと洗
練することができる。アクタ系の動作は、アクタの状態
の変化に応じて変化し、新たなデータがアクタ間で交わ
される。アクタの状態、実行された処理、および通信中
に交わされる情報に関する他の情報の変更、削除、また
は追加を行うために、アクタおよび動作規則は、何時で
も編集することができる。アクタの状態および画像表現
の変更は、利用者の裁量によって、永久的であるか局部
的であるかの何れかであればよい（可逆的）。結果とし
て得られる規則が、テープ・プログラムを形成する。 【０２０６】ソフトコーダのシミュレーション・モード
テープ・プログラムは、スクリプト規則と一般スクリプ
トの集まりであるが、（部分的な）優先順位を持つ動作
の集まりでもある。テープの全体的な順序化は、テープ
・シナリオの生成をもたらすテープ・プログラムのシミ
ュレーションによって実行時に見られるに過ぎない、ソ
フトコーダは、４つのシミュレーション・モードを有す
る。即ち、（１）連続モード、（２）スマート・モード
、（３）同時モード、（４）生成モードである。 【０２０７】４つのシミュレーション・モードは、同一
のテープを再生する、つまり１つの使用を実行する４つ
の異なる方法に対応する。これらの４つのモードは、進
歩する洗練段階に相当し、それらの段階は、単純に連続
するシナリオから始まり、種々の状況において所与の特
徴（異なるデータ、実行の異なる道筋、エラー処理、同
時性）をシミュレートできる実行可能な規則ベースで終
わる。 【０２０８】連続シミュレーション・モードの視覚的な
表現を図３０に示す。連続シミュレーション・モードで
は、各スクリプト規則および一般スクリプトが、テープ
が本来記録された順序で再生される。固定ヘッド３０３
０は、発動された最後のスクリプト上に常に位置する。 【０２０９】スマート・シミュレーション・モードの視
覚的な表現を図３１に示す。スマート・シミュレーショ
ン・モードでは、各スクリプト規則は、それが現在のテ
ープ・ステージから論理的に実行（発動）されるべきか
どうかを調べるために、実行前に検査される。発動され
得る最初のスクリプト規則が、発動され、テープの未来
のリール３１２０から過去のリール３１１０へと移され
、中間のスクリプト規則は省略される。 【０２１０】同時シミュレーション・モードの視覚表現
を図３２に示す。同時シミュレーション・モードは、ス
マート・シミュレーション・モードの拡張である。この
モードでは、各スクリプト規則は、それが現在のテープ
状態から論理的に発動さ得るかどうかを調べるために、
実行前に検査される。同時に発動可能なスクリプト規則
のグループがあることもしばしばある。このような場合
、同時シミュレーション・モードによって、並列実行を
用いてスクリプト規則を同時に発動することが許される
。 【０２１１】生成シミュレーション・モードは、同時シ
ミュレーション・モードの拡張である。このモードでは
、テープが閉ループに接着され、スクリプト規則および
一般スクリプトのシーケンスを繰り返し発動することが
できる。このモードは、同時発動がある標準的な生成規
則システムに類似している。さらに、この生成モードで
は、時間依存性および完全な可逆的実行がサポートされ
る。繰り返し発動するスクリプト規則の集合によって形
成されるループは、終端条件（例えば、カウンタが所定
の値に達するなど）が満たされるまで実行し続ける。 【０２１２】仮定：ＰＲおよびＦＲが、ソフトコーダに
ロードされた現在のテープ・プログラムの過去および未
来のリールをそれぞれ示すものとする。また、ｆ、ｒ、
ｕ、およびｌａが、ソフトコーダの固定ヘッド、記録ヘ
ッド、Ｕｎｄｏヘッド、および先取り（ｌｏｏｋ−ａｈ
ｅａｄ）ヘッドであるとする。時刻ｔにおいて、 ＰＲ（ｔ）＝（Ｕ１，Ｕ２，．．．，Ｕｎｔ）ＦＲ（ｔ
）＝（Ｒ１，Ｒ２，．．．，Ｒｐｔ）連続シミュレーシ
ョン・モードでは、各スクリプト規則および一般スクリ
プトは、テープが本来記録された順番に再生される。固
定ヘッドは、常に、最後に発動されたスクリプト上に位
置する。 【０２１３】連続モードは、次のように実現される。 １）ＰＲ（ｔ）およびＦＲ（ｔ）は、２つのスタック・
オブジェクトの現在の内容を表す。 ２）次のスクリプト規則を再生するためには：時刻ｔに
おいて、ｆ（ｔ）をＦＲスタックの最も上にある規則Ｒ
１に最初に結合する。規則Ｒ１は、そのアクタおよび視
覚的効果（画像的なアンドゥ・コマンドの集合）に対す
るアンドゥ（回復）表現を生成し記録することにより、
アンドゥを行う準備がなされ、その規則は、アンドゥ可
能型と印が付けられて、ｕ（ｔ）となる。次に、ｆ（ｔ
）＝Ｒ１というメッセージが、センダのアクタからレシ
ーバのアクタへと送られ、ｆ（ｔ）からの事後条件が（
そのアクタの属性をいくつか変更して）実行され、対応
する視覚効果が表示され、ＦＲスタックが一回ポップ（
ｐｏｐ）され、さらにｕ（ｔ）は、それがＵ１となりｔ
が単位時間だけインクリメントされるＰＲスタックへと
プッシュ（ｐｕｓｈ）される。発動可能な規則が見つか
らない場合、再生が停止し、テープ・プログラムの終了
したことが利用者に知らされる。 ３）記録の場合、ｒ（ｔ）は、記録直後の規則を示し、
ＦＲスタックにプッシュされ、次のステップが時刻ｔで
再生される。 ４）アンドゥを１ステップ行う場合、ｕ（ｔ）は、Ｕ１
をアンドゥする次の規則を示す。この規則の事実上の影
響は、オプションのメッセージ表示も含めて、元どうり
にされ、そのアクタのアンドゥ表現は、この規則が発動
される前の初期状態までそれらを復元しながら、実行さ
れる。アンドゥ表現はｕ（ｔ）から削除され、元の型の
規則が復元され、それがｆ（ｔ）となり、ＰＲスタック
が一度ポップされ、さらにｆ（ｔ）は、それがＲ１とな
りｔが単位時間だけデクリメントされるＦＲスタック上
にプッシュされる。 ５）自動再生するには、ＦＲスタックが空になり、他の
規則が記録されていなくなるまで、再生ステップを反復
する。 ６）自動アンドゥをするには、ＰＲスタックが空になる
まで、アンドゥ・ステップを繰り返す。 ７）停止するには、最後の規則の実行またはアンドゥが
完全に行われた後（例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど）、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【０２１４】スマート・シミュレーション・モードでは
、各スクリプト規則は、それが現在のテープ・ステージ
から論理的に実行（発動）されるべきかどうかを調べる
ために、実行前に検査される。発動可能な最初のスクリ
プト規則が、発動され、テープの未来のリールから過去
のリールへと移され、中間のスクリプト規則は省略され
る。 【０２１５】スマート・モードは次のように実現される
。 １）ＰＲ（ｔ）およびＦＲ（ｔ）は、２つのスタック・
オブジェクトの現在の内容を表す。 ２）次のスクリプト規則を再生するためには：時刻ｔに
おいて、ｆ（ｔ）をＦＲスタックの最も上にある規則Ｒ
１に結合する。この規則の事前条件が検査され、条件が
満たされない場合は、ＦＲスタックがポップされ、ｆ（
ｔ）がＰＲにプッシュされ（この規則はアンドゥ可能型
には変更されない）、条件が満たされる場合には、この
規則は、そのアクタおよび視覚的効果（画像的なアンド
ゥ・コマンドの集合）に対するアンドゥ（回復）表現を
生成し記録することにより、アンドゥを行う準備がなさ
れ、その規則は、アンドゥ可能型と印が付けられて、ｕ
（ｔ）となる。次に、ｆ（ｔ）＝Ｒ１というメッセージ
が、センダのアクタからレシーバのアクタへと送られ、
ｆ（ｔ）からの事後条件が（そのアクタの属性をいくつ
か変更して）実行され、対応する視覚効果が表示され、
ＦＲスタックが一回ポップされ、さらにｕ（ｔ）は、そ
れがＵ１となりｔが単位時間だけインクリメントされる
ＰＲスタックへとプッシュされる。発動可能な規則が見
つからない場合、再生が停止し、テープ・プログラムの
終了したことが利用者に知らされる。 ３）記録の場合、ｒ（ｔ）は、記録直後の規則を示し、
ＦＲスタックにプッシュされ、次のステップが時刻ｔで
再生される。 ４）アンドゥを１ステップ行う場合、ｕ（ｔ）は、Ｕ１
をアンドゥする次の規則を示す。Ｕ１がアンドゥ可能型
でない場合、スタックＰＲがポップされ、ｕ（ｔ）がＦ
Ｒ上にプッシュされる。Ｕ１がアンドゥ可能型の場合、
この規則の事実上の影響は、オプションのメッセージ表
示も含めて、元どうりにされ、そのアクタのアンドゥ表
現が実行されて、この規則が発動される前の初期状態に
までそれらを復元する。アンドゥ表現はｕ（ｔ）から削
除され、元の型の規則が復元され、それがｆ（ｔ）とな
り、ＰＲスタックが一度ポップされ、さらにｆ（ｔ）は
、それがＲ１となりｔが単位時間だけデクリメントされ
るＦＲスタック上にプッシュされる。 ５）自動再生するには、利用者の入力が要求されるか、
またはＦＲスタックが空になり、かつ他の規則が記録さ
れていなくなるまで、再生ステップを反復する。 ６）自動アンドゥをするには、ＰＲスタックが空になる
まで、アンドゥ・ステップを繰り返す。 ７）停止するには、最後の規則の実行またはアンドゥが
完全に行われた後（例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど）、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【０２１６】同時シミュレーション・モードは、スマー
ト・シミュレーション・モードの拡張である。このモー
ドでは、各スクリプト規則は、それが現在のテープ状態
から論理的に発動さ得るかどうかを調べるために、実行
前に検査される。同時に発動可能なスクリプト規則のグ
ループがあることもしばしばある。このような場合、同
時シミュレーション・モードによって、並列実行を用い
てスクリプト規則を同時に発動することが許される。 【０２１７】同時モードは次のように実現される。 １）ＰＲ（ｔ）は、スタック・オブジェクトの現在の内
容を表し、ＦＲ（ｔ）は、スタック＝シーケンス・オブ
ジェクトの結合体の内容である。つまり、ＦＲは、プッ
シュおよびポップを行うことができるスタックであると
同時に、ポップ操作もプッシュ操作もない直接アクセス
による探索および修正が可能なシーケンスでもある。 ２）次のスクリプト規則を再生するためには：時刻ｔに
おいて、ｆ（ｔ）をＦＲスタックの最も上にある規則Ｒ
１に結合する。この規則の事前条件が検査され、条件が
満たされない場合またはその規則が既にグループ型と印
が付けられている場合、ＦＲスタックがポップされ、ｆ
（ｔ）がＰＲにプッシュされ（この規則はアンドゥ可能
型には変更されない）、条件が満たされる場合（この規
則は時刻ｔにおいて発動可能であると言う）には、それ
は最初の発動可能な規則であり、ｆ（ｔ）は、グループ
型と記され、それ自体のＧｒｏｕｐ−Ｓａｄｄｒｅｓｓ
フィールドに追加され、ｆ（ｔ）として存続し、ｌａ（
ｔ）がＦＲ（ｔ）に適用される。発動可能な規則が見つ
からない場合、再生が停止され、テープ・プログラムの
最後に達したことが利用者に知らされる。先取り処理で
は、ｌａ（ｔ）がＦＲ（ｔ）全体の高速探査を行って他
のすべての発動可能な規則を一度に集め、発見された各
規則がグループ型と記され、続いて、ｌａ（ｔ）によっ
て発見された規則の集合がｆ（ｔ）の現在のＧｒｏｕｐ
−Ｓａｄｄｒｅｓｓ集合（これは、最初は｛ｆ（ｔ）｝
である）に結合される。 グループ型のｆ（ｔ）規則は、そのすべてのアクタ（そ
のＧｒｏｕｐ−Ｓａｄｄｒｅｓｓ集合からのアクタ）お
よび視覚的効果（画像的なアンドゥ・コマンドの集合）
に対するアンドゥ（回復）表現を生成し記録することに
より、アンドゥを行う準備がなされ、その規則集合が、
アンドゥ可能グループの型と印が付けられて、ｕ（ｔ）
となる。次に、ｆ（ｔ）＝Ｒ１のＧｒｏｕｐ−Ｓａｄｄ
ｒｅｓｓからのメッセージ集合が、センダのアクタの集
合からレシーバのアクタの集合へと並列に送られ、ｆ（
ｔ）のＧｒｏｕｐ−Ｓａｄｄｒｅｓｓからの事後条件が
、その集合の各規則に対する別個の背景条件において、
対応するアクタの属性をいくつか変更して並列的に実行
され、対応する視覚効果が表示され、ＦＲスタックが一
回ポップされ、さらにｕ（ｔ）は、それがＵ１となりｔ
が単位時間だけインクリメントされるＰＲスタックへと
プッシュされる。 ３）記録の場合、ｒ（ｔ）は、記録直後の規則を示し、
ＦＲスタックにプッシュされ、次のステップが時刻ｔで
再生される。 ４）アンドゥを１ステップ行う場合、ｕ（ｔ）は、Ｕ１
をアンドゥする次の規則を示す。Ｕ１がアンドゥ可能型
でない場合、スタックＰＲがポップされ、ｕ（ｔ）がＦ
Ｒ上にプッシュされる。ｕ（ｔ）のＧｒｏｕｐ−Ｓａｄ
ｄｒｅｓｓの規則と同様に、Ｕ１がアンドゥ可能型の場
合、各規則の事実上の影響は、（オプションのメッセー
ジ表示も含めて）元どうりにされ、そのアクタのアンド
ゥ表現が実行されて、この規則が発動される前の初期状
態にまでそれらを復元し、アンドゥ表現がｕ（ｔ）から
削除され、元の型の各規則が復元され、最も上の規則が
ｆ（ｔ）となり、ＰＲスタックが一度ポップされ、さら
にｆ（ｔ）は、それがＲ１となりｔが単位時間だけデク
リメントされるＦＲスタック上にプッシュされる。 ５）自動再生するには、利用者の入力が要求されるか、
またはＦＲスタックが空になり、かつ他の規則が記録さ
れていなくなるまで、再生ステップを反復する。 ６）自動アンドゥをするには、ＰＲスタックが空になる
まで、アンドゥ・ステップを繰り返す。 ７）停止するには、最後の規則の実行またはアンドゥが
完全に行われた後（例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど）、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【０２１８】生成シミュレーション・モードは、同時シ
ミュレーション・モードの拡張である。このモードでは
、テープが閉ループに接着されるので、一連のスクリプ
ト規則および一般スクリプトを繰り返し発動することが
できる。このモードは、同時発動がある標準的な生成規
則システムに類似している。さらに、この生成モードで
は、時間依存性および完全な可逆的実行がサポートされ
る。繰り返し発動するスクリプト規則の集合によって形
成されるループは、終端条件（例えば、カウンタが満期
になるなど）が満たされるまで実行し続ける。 【０２１９】生成モードは、次のように実現される。 １）ＰＲ（ｔ）は、スタック・オブジェクトの現在の内
容を表し、ＦＲ（ｔ）は、シーケンス＝ハッシュ・テー
ブル＝格子オブジェクトの結合体の内容である。つまり
、ＦＲは、ハッシュ・テーブル、即ちキーが符号化され
た一種のコンピュータ・オブジェクトであるため、ＦＲ
にいかに多くのスクリプト規則が格納されていても、ス
クリプト規則をその記号的参照情報（Ｓｉｄ）によって
効率的に検索することができる。ＦＲは、所与の規則集
合の後に発動できる次の規則集合がＦＲの限られた部分
集合に含まれることが分かるように、予め計算された相
互間の論理的依存状態に基づいてスクリプト構造体が予
め配列されているような格子である。生成モードにおい
ては、再生、自動再生、アンドゥ、または自動アンドゥ
の最中にＦＲは（例えば、ポップやプッシュによって）
変更されない。しかし、ＦＲは、スクリプト規則の記録
および消去（削除）の間に変更され再構成される。再生
またはアンドゥの間に記録も消去も起こらないと仮定し
て、ＦＲ＝（Ｒ１，Ｒ２，．．．，Ｒｐ）とする。時刻
ｔにおいて、ｐｔ≦ｐとしたＳＦＲ（ｔ）＝Ｓ（ＦＲ，
ｔ）＝（Ｒ１，Ｒ２，．．．，Ｒｐｔ）を時刻ｔに発動
するべき候補であるスクリプト規則のＦＲからの有限部
分集合とする。ＳＦＲは、ｔの前に発動された規則を知
ることによってＦＲ格子から得られる。 ２）次のスクリプト規則を再生するためには：ｆ（ｔ）
をＳＦＲ（ｔ）からの最初の規則である規則Ｒ１に結合
する。この規則の事前条件が検査され、条件が満たされ
ない場合、その規則は無視され、ｆ（ｔ）は、ＳＦＲ（
ｔ）からの次の規則のインスタンスに結合され、それは
、ｆ（ｔ）が発動可能な規則となるかＳＦＲ（ｔ）から
のすべての規則が不成功のうちに検査されるまで、検査
される。この時点で、発動可能な規則が見つからない場
合、ｆ（ｔ）は、待機型またはアンドゥ可能型の規則の
インスタンスに結合され、ｆ（ｔ）はＰＲ上にプッシュ
され、ｔが単位時間だけインクリメントされる。ｆ（ｔ
）の事前条件が満たされる、即ち時刻ｔにおいて規則が
発動可能である場合、それはＳＦＲからの最初の発動可
能な規則であり、元の規則を変更することを防止するた
めにｆ（ｔ）は、それ自体のインスタンスによって置き
換えられ、グループ型と印が付けられ、それ自体のＧｒ
ｏｕｐ−Ｓａｄｄｒｅｓｓフィールドに加えられる。そ
れは、ｆ（ｔ）として存続し、ｌａ（ｔ）がＳＦＲ（ｔ
）に適用される。先取り処理では、ｌａ（ｔ）がＳＦＲ
（ｔ）全体の高速探査を行って時刻ｔにおいて発動可能
な他のすべての規則を集め、発見された各規則はグルー
プ型と印を付けられたそれ自体のインスタンスとして集
められ、続いて、ｌａ（ｔ）によって収集された規則イ
ンスタンスの集合がｆ（ｔ）の現在のＧｒｏｕｐ−Ｓａ
ｄｄｒｅｓｓ集合（これは、最初は｛ｆ（ｔ）｝である
）に結合される。グループ型のｆ（ｔ）規則は、そのす
べてのアクタ（そのＧｒｏｕｐ−Ｓａｄｄｒｅｓｓ集合
からのアクタ）および視覚的効果（画像的なアンドゥ・
コマンドの集合）に対するアンドゥ（回復）表現を生成
し記録することにより、アンドゥを行う準備がなされ、
その規則集合が、アンドゥ可能グループの型と印が付け
られて、ｕ（ｔ）となる。次に、ｆ（ｔ）＝Ｒ１のＧｒ
ｏｕｐ−Ｓａｄｄｒｅｓｓからのメッセージ集合が、セ
ンダのアクタの集合からレシーバのアクタの集合へと並
列に送られ、ｆ（ｔ）のＧｒｏｕｐ−Ｓａｄｄｒｅｓｓ
からの事後条件が、その集合の各規則に対する別個の背
景条件において、対応するアクタの属性をいくつか変更
して並列的に実行される。対応する視覚効果が表示され
、さらにｕ（ｔ）は、それがＵ１となりｔが単位時間だ
けインクリメントされるＰＲスタックへとプッシュされ
る。 ３）記録の場合、ｒ（ｔ）は、記録直後の規則を示し、
ＳＦＲ（ｔ）の要素としてＦＲ格子に挿入され、必要で
あれば前の配列を復元するためにＦＲ格子が再計算され
て、時刻ｔにおいて次のステップが再生される。 ４）アンドゥを１ステップ行う場合、ｕ（ｔ）は、Ｕ１
をアンドゥする次の規則を示す。Ｕ１がアンドゥ可能型
でない場合、誤りが存在する。Ｕ１がアンドゥ可能で待
機型の場合、Ｕ１は捨てられ、ｔが単位時間だけデクリ
メントされる。Ｕ１が、アンドゥ可能で待機（グループ
）型でない場合、ｕ（ｔ）のＧｒｏｕｐ−Ｓａｄｄｒｅ
ｓｓの規則と同様に、各規則の事実上の影響は、オプシ
ョンのメッセージ表示も含めて、元どうりにされ、その
アクタのアンドゥ表現が実行されて、この規則が発動さ
れる前の初期状態にまでそれらを復元し、アンドゥ表現
がｕ（ｔ）から削除され、元の型の各規則が復元され、
最も上の規則がｆ（ｔ）となり、ＰＲスタックが一度ポ
ップされ、さらにｆ（ｔ）はそのまま存続し、ｔが単位
時間だけデクリメントされる。 ５）自動再生するには、利用者の入力が要求されるか、
または停止ボタンが押されるまで、再生ステップを反復
する。 ６）自動アンドゥをするには、ＰＲスタックが空になる
まで、アンドゥ・ステップを繰り返す。 ７）停止するには、最後の規則の実行またはアンドゥが
完全に行われた後（例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど）、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【０２２０】動作の規則の記録、消去、および照会ＧＲ
ＡＳの使用およびソフトコーダの実行能力におけるいく
つかの利点は、何時でも変更を行い、機械の処理能力に
限定される穏当な時間でその変更を自動的に有効にする
柔軟性に由来するものである。上述の再生およびアンド
ゥの機構は、ソフトコーダによって提供されるそのよう
な柔軟な処理モデルの実例である。テープ・プログラム
のシミュレーションの最中にアクタ間の新たな通信を記
録したり、関係する動作規則を取り除いたりできること
も、仕様決定、システム設計、および試験に対するソフ
トコーダ方式の威力の例である。 【０２２１】アクタ間の動作規則を記録するには、３つ
のステップが必要である。 １）ビジュアル・プログラミング：ビジュアル・クルー
（ｃｌｕｅ）、タイプ入力、メニュー項目によって収集
された必要な情報を用いて、基本的なスクリプト構造体
を生成する。 ２）規則の挿入：現在の規則ベースに新たなスクリプト
構造体を挿入する。 ３）修正されたテープ・プログラムを（前節の説明のよ
うに）さらに一段階再生する。 【０２２２】ビジュアル・プログラミング：ＧＲＡＳ画
面上で現在活性なビデオ・モニタのうちの１つからセン
ダのアクタとレシーバのアクタを選択したり、メニュー
選択およびキーワード捜索をしたり、バックステージか
らアクタを検索するためにオーディション表現を選択し
たりすることによって、基本的なスクリプト構造体Ｒ０
を作る。オーディション表現は、利用者によって編集お
よびカスタマイズすることも可能である。スクリプト構
造体Ｒ０は、記号による新たな参照情報（Ｓｉｄ）が与
えられ、センダおよびレシーバの属性には、選択された
アクタ（またはアクタのオーディション記述）が書き込
まれ、センダおよびレシーバのＴ（真）に対するデフォ
ルトの事前条件が定義され、事後条件は全く定義されな
い。次に、新たなメッセージを（利用者がタイプ入力で
）指定するか、またはメニューと既存のスクリプト構造
体の集合に対するキーワード捜索とによって選択する。 新たなメッセージが指定された場合、Ｒ０のメッセージ
・フィールドには、指定されたメッセージが書き込まれ
る。既存のスクリプト構造体Ｒ１が選択された場合、Ｒ
１の事前条件と事後条件とメッセージ表現とのインスタ
ンスが生成され、Ｒ０の対応するフィールドを埋めるた
めに使用される。何れの場合も、新たに記録された規則
が前に発動された規則の集合の結果として発動される可
能性を保証する必要があるならば、Ｒ０の事前条件が変
更される。例えば、Ｒ２の発動後にＲ０が記録される場
合、「Ｒ０はＲ１の後に発動しなければならない」とい
うデフォルトの事前条件が、目標の規則記述言語で生成
される。 【０２２３】規則の挿入：この点において、規則Ｒ０は
、未来のリールに挿入する用意ができている。連続、ス
マート、および同時の各モードにおいては、Ｒ０は、単
にＦＲスタックの上にプッシュされ、このとき２つの記
録モードが可能である。 【０２２４】１）接続モードでは、発動するべきＲ０の
前例（前記の例ではＲ１）に以前は依存していたＦＲ内
のすべての規則は、発動をＲ０に現在依存するように、
自動的に更新される。ＦＲにおけるある規則の事前条件
は、そのように変更される。 【０２２５】２）並列モードでは、ＦＲの何れの規則も
変更されず、従って、Ｒ０は、正常ならば前例の後に（
前記の例では、Ｒ１の後に）発動するはずの他の規則と
平行して発動すると予測される。生成モードでは、Ｒ０
は、ＳＦＲ（ｔ）に最初の要素として挿入され、ＦＲの
格子構造の変更は、自動的に計算されるが、この場合、
記録モードに依存する。 【０２２６】１）接続モードでは、発動するべきＲ０の
前例（前記の例ではＲ１）に以前は依存していたＳＦＲ
（ｔ）内のすべての規則は、発動をＲ０に現在依存する
ように、自動的に更新される。ＳＦＲ（ｔ）におけるあ
る規則の事前条件は、そのように変更され、さらに変更
は、ＦＲ格子の組織内に伝えられる。 【０２２７】２）並列モードでは、ＳＦＲ（ｔ）の何れ
の規則も変更されず、従って、Ｒ０は、正常ならば前例
の後に（前記の例では、Ｒ１の後に）発動するはずのＳ
ＦＲ（ｔ）からの他の規則と平行して発動すると予測さ
れる。 【０２２８】既存の動作規則を消去する場合、ソフトコ
ーダによって提供される基本的な操作により、発動され
た最後のスクリプト規則を利用者が削除できる。この最
後の規則がグループ型の場合、利用者は、その集合から
規則を１つ選択するように促される。次に、テープ・プ
ログラムが１ステップだけ戻されて、選択されたスクリ
プト構造体がＦＲ（または生成モードではＳＦＲ）から
削除される。そして、発動のために削除された規則にか
つて依存していたすべての規則に、発動のために依存す
るのに最適な代替規則が与えられる。生成モードでは、
次に、ＦＲの格子構造が再編成され、規則の間の新たな
予配列が生じる。次に、その変化の影響を表示するため
に、テープ・プログラムが１ステップだけ再生され、削
除された規則に代わって別の規則が発動することになる
。規則集合の大きな塊を消去する場合、規則集合の一部
を切り取って捨てる方法が、フィルム・エディタによっ
て提供される。 【０２２９】ある型の規則（または規則の部分集合）の
未来または過去の実行のための既存の規則集合への照会
は、テープ・プログラムの実行を利用者に取って関心の
ある点に迅速に位置付ける機構を提供する。ソフトコー
ダの進歩したプログラム実行性を用いれば、実行履歴ま
たは実行の将来における所望の位置へテープ・プログラ
ムを自動的に位置決めすることを要求することができる
。これは、所望の点の例を記述する視覚的照会を記録し
、ＰＲにおいて一致する一連の実行済み規則を捜し、照
合が成功した場合、必要とされるカウンタ位置への自動
アンドゥによってテープを位置決めし、成功しなかった
場合には、一致するまで自動再生を実行することにより
テープを位置決めする。 【０２３０】ビデオ・コネクタ ビデオ・コネクタは、ＧＲＡＳと異質のシステムとの間
の物理的または仮想的なデータ・リンクと結び付いたソ
フトウェアの通信プロトコルである。ビデオ・コネクタ
は、ビデオ信号源（カメラ、ミキサ、テレビ・ケーブル
）をＶＣＲに連結する同軸ケーブルに似ている。しかし
、ＶＳＭでは、ビデオ・コネクタにより、外部のシステ
ムからテープへと事象を記録するとともに、外部のシス
テムからＧＲＡＳを遠隔制御するための通信路が提供さ
れる。 【０２３１】ＧＲＡＳでは、利用者が処理を描写する（
指定する）のをカメラが追うように、利用者の対話から
得られる仕様をすべてのビデオ・モニタから記録するこ
とができる。記録中の各ビデオ・モニタは、アクタどお
しの間の作用がカメラで記録されるビデオ・スタジオの
一部である。ビデオ・スタジオ内のカメラは、仮想的な
ビデオ・コネクタによってソフトコーダに結合されてい
る。 【０２３２】ビデオ・コネクタのインタフェースは、ア
プリケーションがＧＲＡＳにデータ跡を送ると同時にＧ
ＲＡＳを遠隔制御できるように実現される。例えば、ア
プリケーションは、新たなテープを生成し、そのテープ
の遠隔記録（つまり、メッセージの照会）を開始し、詳
細水準を変更し、アニメーション・ビューを変更するこ
とができると同時に、ＧＲＡＳは、そのデータ跡の動画
化を同期モードまたは非同期モードで開始することがで
きる。所望により、アプリケーションは、使用される画
像表現を完全に制御することができる。ＧＲＡＳの遠隔
制御は、如何なる双方向データ・リンクによってもサポ
ート可能な標準のリモート・エバリュエーション・プロ
トコル（遠隔関数呼び出し）に基づく。 【０２３３】ＯＯスクリプト ＯＯスクリプトは、２つのアクタの間の単一処理を定義
する要素体である。ＯＯスクリプトは、アクタの１つの
動作の一面を記述する最小の実体である。各ＯＯスクリ
プトにより、センダおよびレシーバとして知られる１つ
または２つのアクタが関与する動作の１つの規則が記述
される。 【０２３４】オブジェクト対オブジェクトのスクリプト
（ＯＯスクリプト）は、正式には、（スクリプト識別子
（ｓｉｄ），センダ，レシーバ，前提条件リスト（ｐｒ
ｅｃｏｎｄ−ｌｉｓｔ），事後条件リスト（ｐｏｓｔｃ
ｏｎｄ−ｌｉｓｔ），メッセージ，オプションの参考情
報）という数学的なタプル（特定数要素の集合）として
定義される。各ＯＯスクリプトは、特有の識別子（ｓｉ
ｄ）に関係付けられている。「センダ」は、「レシーバ
」に呼び掛けるために「メッセージ」を発動する実体を
指す。「前提条件リスト（ｐｒｅｃｏｎｄ−ｌｉｓｔ）
」は、ＯＯスクリプトが活性化されるために満たされな
ければならない前提条件を与える。「事後条件リスト（
ｐｏｓｔｃｏｎｄ−ｌｉｓｔ）」は、そのＯＯスクリプ
トがの実行終了後には真となるべきシステムの事後条件
を与える。「メッセージ」は、オプションの引数を伴う
メッセージまたは関数の名前である。表された処理また
は関係するオブジェクトに関するコメントをオプション
の参考情報に含めることができる。 【０２３５】ＯＯスクリプトのシンタックスを次に述べ
る。事前条件リストおよび事後条件リストは、両方とも
括弧で囲み、オプションの参考情報は、引用符（“ ”
）で囲む。引数のないメッセージは、それを囲む括弧を
付けても付けなくても良いが、引数付きのメッセージは
、引数を従えた第１の要素としてメッセージ名を伴う括
弧付きのリストとして表す。渡される文字データ・メッ
セージは、引用符で囲まれた文字列として示される。 【０２３６】ＯＯスクリプトにより、センダがレシーバ
にメッセージを送る処理においてセンダとレシーバとの
間の相互作用を包含する規則が具体化される。メッセー
ジは、関数の呼び出し（例えば、プロシージャ・コール
の場合のような作用の要求）、データ伝送、またはその
両方で構成することができる。規則は、どの実体がセン
ダおよびレシーバであるか、前記のような相互作用が起
こる時期を支配する条件の記述、および相互作用の結果
である状態を指定する。スクリプトは、特定の状況また
は一連の事象に対するシステムの作用規則を包含するＯ
Ｏスクリプト集合である。 【０２３７】図２〜図５は、コンピュータのログイン手
順の仕様およびシミュレーションを与えるためにＯＯス
クリプトがどのように使用されるかの例を示す。図２は
、実施のコンピュータ手順の流れ図であり、図３は、コ
ンピュータのログイン手順の実施に使用される対応する
ＯＯスクリプトを示し、図４および図５は、ＧＲＡＳに
よるログイン手順のシミュレーションの画像表示である
。 【０２３８】コンピュータ４００は、端末４１０に「ｓ
ｅｎｄ−ｌｏｇｉｎ」メッセージ４０５を送ることによ
ってコンピュータのログイン手順を開始する（作用ブロ
ック２１０）。開始ステップに対応するＯＯスクリプト
を図３のＯＯスクリプト３１０として示す。端末４１０
は、「ｓｅｎｄ−ｌｏｇｉｎ」メッセージ４０５に対し
、ログイン・プロンプト・メッセージ４１５を利用者４
２０に表示して応答する（作用ブロック２２０およびＯ
Ｏスクリプト３２０）。ログイン・プロンプト・メッセ
ージ４１５に対し、利用者４２０は、自分のログイン・
ネームを端末のキーボード４２５上で入力することによ
って応答する（作用ブロック２３０およびＯＯスクリプ
ト３３０）。 手順の次のステップは、ＧＲＡＳの詳細水準に依存する
。前記のように、ＯＯスクリプト識別子によって、多重
詳細水準が可能である。詳細水準が高いほど、経験がよ
り豊かな利用者のためのシナリオの深入りしたステップ
まで示されるが、詳細水準が低くなると、要約水準の高
いシミュレーションが示される。詳細水準を「１」と決
定した場合（判断２４０）、水準が低い方の２つのステ
ップがシミュレートされ（図５）てから、次の水準「０
」のステップがシミュレートされる。詳細水準が「１」
の場合（判断２４０）、端末５１０は、利用者のキーボ
ード入力内容５２５をログイン・ネーム・データ・メッ
セージ５３５によってコンピュータ５００へ送る（作用
ブロック２４５およびＯＯスクリプト３４０）。 次に、コンピュータ５００が、利用者５２０と共にパス
ワード入力手順を開始するようにメッセージ５４５を端
末５１０に送る（作用ブロック２４７およびＯＯスクリ
プト３５０）。シミュレーションの次のステップは、水
準０および水準１の両方に対して同じである。そのシミ
ュレーションに付いては、図４を参照する。端末４１０
が、「パスワード・プロンプト」メッセージ４３５を利
用者に送る（作用ブロック２５０およびＯＯスクリプト
３６０）。次に、利用者４２０が、キーボードでパスワ
ードを入力すことによって、パスワード・データ４４５
を端末４１０に送る（作用ブロック２６０およびＯＯス
クリプト３７０）。そして、シミュレーションの詳細水
準が「０」か「１」かをＧＲＡＳシステムが判断する（
判断４７０）。詳細水準が「０」ならば、そのシミュレ
ーションは終了する（作用ブロック２８０）が、詳細水
準が「１」の場合（図５参照）は、端末５１０が、パス
ワード・データ・メッセージ５７５をコンピュータ５０
０に送る（作用ブロック２７５およびＯＯスクリプト３
８０）。そして、シミュレーションが終了する。 【０２３９】以上の説明は、本発明の一実施例に関する
もので、この技術分野の当業者であれば、本発明の種々
の変形例が考えられるが、それらはいずれも本発明の技
術的範囲に包含される。 【０２４０】 【発明の効果】以上述べたように、本発明によれば、プ
ログラム仕様についての労力をあまり要求することなく
、プログラムの作用をいっそう完璧にモデル化してプロ
グラム仕様を作ることができる。
【図１】ＧＲＡＳシステムの概念的構造のブロック図で
ある。
ある。
【図２】ＧＲＡＳシステムを用いて指定するべきコンピ
ュータ・ログイン・シーケンスの流れ図である。
ュータ・ログイン・シーケンスの流れ図である。
【図３】コンピュータ・ログイン・シーケンスを指定す
るためのスクリプトの内容を例示するデータ図である。
るためのスクリプトの内容を例示するデータ図である。
【図４】コンピュータ・ログイン・シーケンスを模擬実
験した後のＧＲＡＳシステムの表示を例示する図である
。
験した後のＧＲＡＳシステムの表示を例示する図である
。
【図５】コンピュータ・ログイン・シーケンスを模擬実
験した後のＧＲＡＳシステムの表示を例示する図である
。
験した後のＧＲＡＳシステムの表示を例示する図である
。
【図６】ＧＲＡＳシステムの種々の関数を例示する流れ
図である。
図である。
【図７】ＧＲＡＳシステムの種々の関数を例示する流れ
図である。
図である。
【図８】ＧＲＡＳシステムの種々の関数を例示する流れ
図である。
図である。
【図９】ＧＲＡＳシステムの種々の関数を例示する流れ
図である。
図である。
【図１０】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図１１】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図１２】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図１３】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図１４】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図１５】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図１６】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図１７】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図１８】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図１９】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図２０】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図２１】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図２２】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図２３】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図２４】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図２５】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図２６】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図２７】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図２８】ＧＲＡＳシステムの種々の関数を例示する流
れ図である。
れ図である。
【図２９】ビデオ・スタジオ・メタファ（ＶＳＭ）によ
る、ＧＲＡＳシステムのシミュレーション・モードを例
示する図である。
る、ＧＲＡＳシステムのシミュレーション・モードを例
示する図である。
【図３０】ビデオ・スタジオ・メタファ（ＶＳＭ）によ
る、ＧＲＡＳシステムのシミュレーション・モードを例
示する図である。
る、ＧＲＡＳシステムのシミュレーション・モードを例
示する図である。
【図３１】ビデオ・スタジオ・メタファ（ＶＳＭ）によ
る、ＧＲＡＳシステムのシミュレーション・モードを例
示する図である。
る、ＧＲＡＳシステムのシミュレーション・モードを例
示する図である。
【図３２】ビデオ・スタジオ・メタファ（ＶＳＭ）によ
る、ＧＲＡＳシステムのシミュレーション・モードを例
示する図である。
る、ＧＲＡＳシステムのシミュレーション・モードを例
示する図である。
１００ ＶＳＭインタフェース
１１０ ビジュアル・オブジェクト網管理モジュール（
ＭＯＶＯＮ） １１１、１２１、および１３１双方向メッセージ・リン
ク １２０ ソフトウェア・ビデオ・レコーダ・モジュール
（ＳＯＦＴＣＯＤＥＲ） １３０ ビデオ・コネクタ
・モジュール（ＶＣ） １４０ アクタ・フレーム・モジュール（ＡＦ）１６０
プレスクリプト・モジュール（ＰＲＥＳＣＲＩＰＴ） １７０ ウィンドウおよびグラフィックの諸機能（ＷＧ
） １７５ オペレーティング・システム（ＯＳ）１
７６ ハードウェア（ＨＷ） １８０ Ｃｏｍｍｏｎ Ｌｉｓｐ（ＣＬ）１８５ ファ
イル・システム（ＦＳ） １８６ ネットワーク（ＮＷ）
ＭＯＶＯＮ） １１１、１２１、および１３１双方向メッセージ・リン
ク １２０ ソフトウェア・ビデオ・レコーダ・モジュール
（ＳＯＦＴＣＯＤＥＲ） １３０ ビデオ・コネクタ
・モジュール（ＶＣ） １４０ アクタ・フレーム・モジュール（ＡＦ）１６０
プレスクリプト・モジュール（ＰＲＥＳＣＲＩＰＴ） １７０ ウィンドウおよびグラフィックの諸機能（ＷＧ
） １７５ オペレーティング・システム（ＯＳ）１
７６ ハードウェア（ＨＷ） １８０ Ｃｏｍｍｏｎ Ｌｉｓｐ（ＣＬ）１８５ ファ
イル・システム（ＦＳ） １８６ ネットワーク（ＮＷ）
Claims (40)
- 【請求項１】 コンピュータ・プログラムのための仕
様を対話的に生成するコンピュータ・システムにおいて
、入力装置を介して受信可能なアクタ・データの受信に
応じて、複数のテープ・シナリオにおいて使用するため
のアクタを指定して、前記アクタに対するデータを格納
し、前記指定が、新たなアクタの生成、以前に生成され
たアクタの選択、およびアクタ・データの修正を含むス
テップと、複数のシナリオの作用ステップに対し前記入
力装置を介して受信可能な仕様データを受信し、これに
応じて引き続き実行するために、前記アクタ間の通信、
前記アクタ間の関係、前記アクタに対する論理的または
算術的な演算、および前記複数のシナリオに対する判断
点を格納するステップと、前記入力装置を介して判断の
選択を受信し、以後それに応じてシナリオのステップを
実行する実行ステップとを備え、前記実行ステップが、
前記作用ステップのうちのいくつかのステップに対する
所定の条件が発生により、前記作用ステップのうちの前
記いくつかのステップをシミュレートするシミュレーシ
ョン・ステップと、前記シミュレーションの結果を格納
する格納ステップとを含み、さらに前記シミュレーショ
ンが、前記アクタ間の通信の実行、前記アクタ間の関係
の表明、前記アクタに対する論理的または算術的な演算
の実行、または判断選択の入力の各ステップのうちの少
なくとも１つは含むことを特徴とするプログラム仕様の
対話的な設計を支援する方法。 - 【請求項２】 前記実行ステップが、前記アクタ間の
通信の実行、前記アクタ間の関係の表明、前記アクタに
対する論理的または算術的な演算の実行のステップをす
べて備えたことを特徴とする請求項１記載の方法。 - 【請求項３】 前記実行ステップが、判断選択の入力
を要求するステップをさらに備えたことを特徴とする請
求項２記載の方法。 - 【請求項４】 前記入力装置が、グラフィカルな表示
を指定するためのものであり、前記シミュレーション・
ステップが、前記作用ステップのうちの前記いくつかの
ステップのうちのいくつかをグラフィカルに動画表示す
るステップをさらに含むことを特徴とする請求項１記載
の方法。 - 【請求項５】 前記作用ステップのうちの前記いくつ
かのステップの前記シミュレーションの最中に前記入力
装置を介して受信された指示に応じて、前記作用ステッ
プのうちの１つをシミュレートした後、前記シミュレー
ションを停止するステップと、前記入力装置を介して入
力データを受信し、これに応じて、追加的なアクタまた
は追加的な作用ステップを格納するステップと、前記入
力装置を介して受信した別の指示に応じて、前記の追加
的なアクタまたは追加的な作用ステップを含む前記作用
ステップの前記シミュレーションを再開するステップと
をさらに備えたことを特徴とする請求項１記載の方法。 - 【請求項６】 前記作用ステップの前記シミュレーシ
ョンの最中に前記入力装置を介して受信した指示に応じ
て、前記作用ステップの前記シミュレーションを次々と
逆処理し、前記作用ステップのうちの特定のステップを
逆処理した後、前記逆処理を停止する逆処理ステップと
、前記入力装置を介して受信した入力データに応じて、
前記作用ステップのうちの前記特定のステップを修正す
るステップと、前記入力装置を介して受信した別の指示
に応じて、前記作用ステップのうちの前記特定のステッ
プで前記シミュレーションを再開するステップとをさら
に備えたことを特徴とする請求項１記載の方法。 - 【請求項７】 前記逆処理ステップが、前記シミュレ
ーションの前記結果を次々と削除することを含むことを
特徴とする請求項６記載の方法。 - 【請求項８】 前記シミュレーションス・テップが、
プログラム経路の指定されていない判断点の選択を自動
的に識別することも含むことを特徴とする請求項１記載
の方法。 - 【請求項９】 他のプログラム仕様システムから情報
を受信する複数のシナリオにおける点である入力点を前
記入力装置を介して受信し、これに応じて、前記の入力
点を特定するデータを格納するステップをさらに備えた
ことを特徴とする請求項１記載の方法。 - 【請求項１０】 アクタ間の通信、アクタ間の関係、
アクタに対する論理的または算術的な演算、およびアク
タに対する判断点のうちの少なくとも１つを指定する規
則を複数備えたテープ・プログラムを構成するステップ
をさらに備えたことを特徴とする請求項１記載の方法。 - 【請求項１１】 テープ・プログラムの集合を結合し
て、新たなシナリオ・グループを実行するための単一の
合成テープ・プログラムにする結合ステップをさらに備
えたことを特徴とする請求項１０記載の方法。 - 【請求項１２】 前記結合ステップが、前記複数の規
則の集合合併体を実行することを含むことを特徴とする
請求項１１記載の方法。 - 【請求項１３】 前記アクタの各々がデータ集合を含
み、前記シミュレーションステップが、アクタのデータ
が前記作用ステップのうちの前記いくつかのステップを
実行するのに十分かどうかを確かめるステップをさらに
備えたことを特徴とする請求項１記載の方法。 - 【請求項１４】 アクタのデータが不十分であること
を利用者に知らせるステップをさらに備えたことを特徴
とする請求項１３記載の方法。 - 【請求項１５】 アクタのデータに対して行われた変
更の履歴のデーターベースが前記データ集合に含まれ、
前記格納ステップが、前記アクタ・データへの変更を前
記履歴データーベースに格納することを含むことを特徴
とする請求項１３記載の方法。 - 【請求項１６】 前記のアクタの履歴データーベース
における変更に応じて、アクタのグラフィカルな表示を
変更するステップをさらに備えたことを特徴とする請求
項１５記載の方法。 - 【請求項１７】 複数水準のシミュレーションを利用
することが可能で、各シミュレーションに対しシミュレ
ーション水準の集合を個別に指定しても良く、各作用ス
テップに対して、シミュレーション水準を確認するステ
ップと、前記作用ステップの１つの結果を格納するとき
に、前記作用ステップの前記結果をその適切なシミュレ
ーション水準で格納するステップをさらに備えたことを
特徴とする請求項１記載の方法。 - 【請求項１８】 複数の表示水準を利用することが可
能で、前記表示水準の各々がシミュレーション水準に対
応し、各作用ステップに対してシミュレーション水準の
集合を確認するステップと、シナリオを実行するときに
、前記集合の要素である水準に等しいか、それを下回る
ような作用ステップに対してのみ、結果を表示するステ
ップをさらに備えたことを特徴とする請求項１７記載の
方法。 - 【請求項１９】 前記シナリオの前記作用ステップの
１つのシミュレーションが、１つのアクタから他のアク
タへと記号的メッセージを送ることを含むことを特徴と
する請求項１記載の方法。 - 【請求項２０】 各アクタがデータ集合を含み、前記
シミュレーションステップが、作用ステップのシミュレ
ーションの一部としてアクタ・データを変更する変更ス
テップを含み、その変更ステップが、そのアクタの属性
の追加または削除を含むことを特徴とする請求項１９記
載の方法。 - 【請求項２１】 前記変更ステップが、既存のアクタ
・データおよびそのアクタによって受信されたメッセー
ジ・データの関数として変更することを含むことを特徴
とする請求項２０記載の方法。 - 【請求項２２】 所定の状態の発生が、前記作用ステ
ップの２つ以上のステップの同時シミュレーションの契
機となり、前記の同時発生する作用ステップに共通のア
クタがある場合、その共通のアクタのデータをアクセス
しようとする他のアクタが、その同じデータを同時にア
クセスしないことを保証する保証ステップをさらに備え
たことを特徴とする請求項１記載の方法。 - 【請求項２３】 前記保証ステップが、ある作用ステ
ップのシミュレーションの前に、計算された所定の時間
だけ他の作用ステップの時刻から遅らせるステップを含
むことを特徴とする請求項２２記載の方法。 - 【請求項２４】 前記保証ステップが、第１の作用ス
テップのシミュレーションを、第２の作用ステップのシ
ミュレーションが終わるまで遅らせるステップを含むこ
とを特徴とする請求項２２記載の方法。 - 【請求項２５】 テープ・プログラムが複数のテープ
・シナリオからなる場合、呼び出されたテープ・プログ
ラムを呼び出しているテープ・プログラムの実行の一部
として実行し、前記の呼び出されたテープ・プログラム
の実行に続いて、前記の呼び出しているテープ・プログ
ラムに戻るステップをさらに備えたことを特徴とする請
求項２２記載の方法。 - 【請求項２６】 第１のテープ・プログラムの第１の
作用ステップのシミュレーションの後に、前記第１のテ
ープ・プログラムの第２の作用ステップのシミュレーシ
ョンに先立ち、第２のテープ・プログラムの部分集合を
シミュレートするステップをさらに備えたことを特徴と
する請求項２２記載の方法。 - 【請求項２７】 引き続き他のテープ・プログラムに
おいて再利用するために第２のテープ・プログラムの部
分集合を取り去るステップをさらに備えたことを特徴と
する請求項２２記載の方法。 - 【請求項２８】 コンピュータ・プログラムのための
仕様を対話的に生成するコンピュータ・システムにおい
て、入力装置を介して受信可能なアクタ・データの受信
に応じて、複数のテープ・シナリオにおいて使用するた
めのアクタを指定して、前記アクタに対するデータを格
納し、前記指定が、新たなアクタの生成、以前に生成さ
れたアクタの選択、およびアクタ・データの修正を含む
ステップと、前記入力装置を介して受信可能なアクタ・
データを受信し、これに応じて引き続き実行するために
、前記アクタ間の通信、前記アクタ間の関係、前記アク
タに対する論理的または算術的な演算、および前記複数
のシナリオに対する判断点を格納するステップとを備え
たことを特徴とするプログラム仕様の対話的な設計を支
援する方法。 - 【請求項２９】 複数のシナリオの作用ステップのた
めの蓄積アクタ・データおよび蓄積仕様データを含むシ
ステムにおいて、前記入力装置を介して受信可能な第１
の判断選択を受信し、これに応じて、複数のテープ・シ
ナリオの第１のシナリオを実行する実行ステップを備え
、この実行ステップが、各作用ステップに対する所定の
条件が発生により、前記第１のシナリオの作用ステップ
をシミュレートするシミュレーション・ステップと、前
記シミュレーションの結果を格納する格納ステップとを
含み、さらに前記シミュレーションが、アクタ間の通信
の実行、アクタ間の関係の表明、アクタに対する論理的
または算術的な演算の実行、または判断選択の入力の各
ステップのうちの少なくとも１つは含むことを特徴とす
るプログラム仕様の対話的な検査を支援する方法。 - 【請求項３０】 前記シミュレーションステップが、
２つ以上のアクタを合併する合併ステップをさらに備え
たことを特徴とする請求項１記載の方法。 - 【請求項３１】 前記合併ステップが、第１のアクタ
の識別情報を第２のアクタの識別情報に変更することを
含むことを特徴とする請求項３０記載の方法。 - 【請求項３２】 前記合併ステップが、第１のアクタ
と第２のアクタとを結合して第３のアクタとする結合ス
テップを含み、この結合ステップが、前記第１のアクタ
および前記第２のアクタのアクタ通信データを前記第３
のアクタに割り当てるステップと、前記第１のアクタの
アクタ属性データおよびアクタ関係データを前記第３の
アクタに割り当てるステップ、前記第２のアクタのアク
タ属性データおよびアクタ関係データを前記第３のアク
タに割り当てるステップ、前記第１のアクタおよび前記
第２のアクタからアクタ属性データおよびアクタ関係デ
ータを選択的に組み合わせたものを前記第３のアクタに
割り当てるステップ、および前記第１のアクタおよび前
記第２のアクタのアクタ属性データおよびアクタ関係デ
ータを前記第３のアクタに割り当てるステップのうちの
少なくとも１つのステップとを備えたことを特徴とする
請求項３０記載の方法。 - 【請求項３３】 入力装置を介して受信可能なアクタ
・データの受信に応じて、複数のテープ・シナリオにお
いて使用するためのアクタの指定を、新たなアクタの生
成、以前に生成されたアクタの選択、およびアクタ・デ
ータの修正などによって行い、かつ前記アクタに対する
データを格納する手段と、前記入力装置を介して受信可
能な作用ステップを受信し、これに応じて引き続き実行
するために、前記アクタ間の通信、前記アクタ間の関係
、前記アクタに対する論理的または算術的な演算、およ
び前記複数のシナリオに対する判断点を格納する手段と
を備えたことを特徴とするプログラム仕様の対話的な設
計を支援するシステム。 - 【請求項３４】 複数のシナリオの作用ステップのた
めに蓄積（格納）されたアクタ・データおよび仕様デー
タを収容しているコンピュータ・プログラム仕様検査シ
ステムにおいて、作用ステップのための前記の蓄積アク
タ・データおよび蓄積仕様データを検査する手段と、入
力装置を介して受信可能な第１の判断選択の受信に応じ
て、仕様（指定）の首尾一貫性を評価するために複数の
テープ・シナリオの第１のシナリオを実行し、この実行
が、各作用ステップに対する所定の条件の発生によって
前記第１のシナリオの作用ステップをシミュレートする
ことを含むような手段と、前記シミュレーションの結果
を格納する手段とを備え、前記シミュレーションが、ア
クタ間の通信の実行、アクタ間の関係の表明、アクタに
対する論理的または算術的な演算の実行、および判断選
択の入力の要求のステップのうちの少なくとも１つは含
むことを特徴とするコンピュータ・プログラム仕様検査
システム。 - 【請求項３５】 前記作用ステップの前記シミュレー
ション中に前記入力装置を介して受信される指示の受信
に応じて、前記作用ステップの前記シミュレーションを
次々と逆処理し、かつ前記作用ステップの１ステップに
おいて前記逆処理を停止する逆処理手段をさらに備えた
ことを特徴とする請求項３４記載のシステム。 - 【請求項３６】 前記入力装置を介して受信した入力
データに応じて、前記作用ステップのうちの前記１ステ
ップを修正する手段をさらに備えたことを特徴とする請
求項３５記載のシステム。 - 【請求項３７】 前記入力装置を介して受信した別の
指示に応じて、前記作用ステップのうちの前記１ステッ
プにおいて前記シミュレーションを再開する手段をさら
に備えたことを特徴とする請求項３６記載のシステム。 - 【請求項３８】 前記の逆処理手段が、実行された個
々のステップのシミュレーション結果を次々と削除する
手段を含むことを特徴とする請求項３５記載のシステム
。 - 【請求項３９】 前記アクタがフレームからなり、前
記フレーム間の関係が双対リンクを用いて維持され、前
記方法が、前記フレームの１つの自己記述を格納するス
テップを備え、さらに前記自己記述が、前記フレームの
前記１つが定義されるコンピュータ環境から独立してい
ることを特徴とする請求項１記載の方法。 - 【請求項４０】 フレームが、その母体から複数の属
性および複数の関係を継承することを特徴とする請求項
３９記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US07/510,373 US5247651A (en) | 1990-04-17 | 1990-04-17 | Interactive computer program specification and simulation system |
| US510373 | 1990-04-17 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH04227538A true JPH04227538A (ja) | 1992-08-17 |
Family
ID=24030485
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP3103546A Pending JPH04227538A (ja) | 1990-04-17 | 1991-04-10 | プログラム仕様の対話的な設計・検査を支援する方法およびシステム |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5247651A (ja) |
| EP (1) | EP0453152A3 (ja) |
| JP (1) | JPH04227538A (ja) |
| CA (1) | CA2035949C (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8151242B1 (en) | 1999-04-06 | 2012-04-03 | Ns Solutions Corporation | Description support apparatus and method for requisition sheet, and recording medium |
Families Citing this family (143)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5610828A (en) * | 1986-04-14 | 1997-03-11 | National Instruments Corporation | Graphical system for modelling a process and associated method |
| US5586314A (en) * | 1990-05-02 | 1996-12-17 | Electronic Data Systems Corporation | Graphic information modeling and icon-based intermediate text language generation |
| GB2247597B (en) * | 1990-08-31 | 1995-03-08 | Canon Res Ct Europe Ltd | Image processing |
| WO1993011484A2 (en) * | 1991-11-27 | 1993-06-10 | Telefonaktiebolaget Lm Ericsson | Software structure for telecommunication switching systems |
| US6418424B1 (en) | 1991-12-23 | 2002-07-09 | Steven M. Hoffberg | Ergonomic man-machine interface incorporating adaptive pattern recognition based control system |
| US6850252B1 (en) | 1999-10-05 | 2005-02-01 | Steven M. Hoffberg | Intelligent electronic appliance system and method |
| US5903454A (en) | 1991-12-23 | 1999-05-11 | Hoffberg; Linda Irene | Human-factored interface corporating adaptive pattern recognition based controller apparatus |
| US10361802B1 (en) | 1999-02-01 | 2019-07-23 | Blanding Hovenweep, Llc | Adaptive pattern recognition based control system and method |
| US6400996B1 (en) | 1999-02-01 | 2002-06-04 | Steven M. Hoffberg | Adaptive pattern recognition based control system and method |
| US8352400B2 (en) | 1991-12-23 | 2013-01-08 | Hoffberg Steven M | Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore |
| US6678864B1 (en) * | 1992-02-25 | 2004-01-13 | Irving Tsai | Method and apparatus for linking designated portions of a received document image with an electronic address |
| US5367683A (en) * | 1992-06-26 | 1994-11-22 | Digital Equipment Corporation | Smart recompilation of performing matchup/difference after code generation |
| US5446899A (en) * | 1992-06-26 | 1995-08-29 | Digital Equipment Corporation | Hint generation in smart recompilation |
| US5625822A (en) * | 1992-06-26 | 1997-04-29 | Digital Equipment Corporation | Using sorting to do matchup in smart recompilation |
| GB2270242A (en) * | 1992-08-29 | 1994-03-02 | Ibm | A method of editing for an object oriented computer system |
| JP2597460B2 (ja) * | 1992-11-12 | 1997-04-09 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 複合データ構造を生成及び記憶する方法及び装置 |
| JPH06161919A (ja) * | 1992-11-25 | 1994-06-10 | Fujitsu Ltd | メッセージ制御方式 |
| US5517663A (en) * | 1993-03-22 | 1996-05-14 | Kahn; Kenneth M. | Animated user interface for computer program creation, control and execution |
| AU669799B2 (en) * | 1993-03-31 | 1996-06-20 | Apple Inc. | Time-based script sequences |
| JPH06332680A (ja) * | 1993-05-21 | 1994-12-02 | Tadao Shogetsu | プログラム自動生成装置 |
| US6126329A (en) | 1993-06-08 | 2000-10-03 | Rational Software Coporation | Method and apparatus for accurate profiling of computer programs |
| US5442740A (en) * | 1993-07-13 | 1995-08-15 | International Business Machines Corporation | Method and apparatus for visual display of program performance trace data |
| JP3294691B2 (ja) * | 1993-11-26 | 2002-06-24 | 株式会社日立製作所 | オブジェクト指向システム構築方法 |
| US5423043A (en) * | 1994-01-21 | 1995-06-06 | International Business Machines Corporation | Method and apparatus for creating and monitoring logical associations among desktop objects |
| US5566295A (en) * | 1994-01-25 | 1996-10-15 | Apple Computer, Inc. | Extensible simulation system and graphical programming method |
| US5638539A (en) * | 1994-02-28 | 1997-06-10 | International Business Machines Corporation | Tool for defining complex systems |
| US5508718A (en) * | 1994-04-25 | 1996-04-16 | Canon Information Systems, Inc. | Objective-based color selection system |
| US5615320A (en) * | 1994-04-25 | 1997-03-25 | Canon Information Systems, Inc. | Computer-aided color selection and colorizing system using objective-based coloring criteria |
| AU695912B2 (en) * | 1994-06-07 | 1998-08-27 | Skillsoft Ireland Limited | A computer based training system |
| DE69518123T2 (de) * | 1994-06-23 | 2001-03-29 | Ibm | Visualisierung von objektorientierter Software |
| US5553227A (en) * | 1994-08-26 | 1996-09-03 | International Business Machines Corporation | Method and system for visually programming state information using a visual switch |
| US5652867A (en) * | 1994-09-08 | 1997-07-29 | Sabre Decision Technologies, A Division Of The Sabre Group, Inc. | Airline flight reservation system simulator for optimizing revenues |
| JP3696906B2 (ja) * | 1994-10-25 | 2005-09-21 | キヤノン株式会社 | データ入力方法及びその装置 |
| US5850548A (en) * | 1994-11-14 | 1998-12-15 | Borland International, Inc. | System and methods for visual programming based on a high-level hierarchical data flow model |
| US5590330A (en) * | 1994-12-13 | 1996-12-31 | International Business Machines Corporation | Method and system for providing a testing facility in a program development tool |
| EP0738964B1 (en) * | 1995-04-18 | 2002-07-03 | Siemens Corporate Research, Inc. | Method for animating composite behavior of scenarios |
| US6205575B1 (en) * | 1995-04-18 | 2001-03-20 | Siemens Corporate Research, Inc. | Scenario presentation tool |
| US5606699A (en) * | 1995-04-28 | 1997-02-25 | International Business Machines Corporation | Storing and querying execution information for object-oriented programs |
| US5926387A (en) * | 1995-06-30 | 1999-07-20 | Beckman Instruments, Inc. | Ultracentrifuge operation by computer system |
| US6272543B1 (en) * | 1995-09-19 | 2001-08-07 | Kabushiki Kaisha Toshiba | Network-computer system build support system and support method |
| US5774368A (en) * | 1995-10-20 | 1998-06-30 | Motorola, Inc. | Controller structure template and method for designing a controller structure |
| US5870588A (en) * | 1995-10-23 | 1999-02-09 | Interuniversitair Micro-Elektronica Centrum(Imec Vzw) | Design environment and a design method for hardware/software co-design |
| US5865624A (en) * | 1995-11-09 | 1999-02-02 | Hayashigawa; Larry | Reactive ride simulator apparatus and method |
| US5859962A (en) * | 1995-12-21 | 1999-01-12 | Ncr Corporation | Automated verification of digital design |
| US5691909A (en) * | 1995-12-29 | 1997-11-25 | Western Atlas | Method of virtual machining to predict the accuracy of part to be made with machine tools |
| US5848274A (en) * | 1996-02-29 | 1998-12-08 | Supercede, Inc. | Incremental byte code compilation system |
| US5764989A (en) * | 1996-02-29 | 1998-06-09 | Supercede, Inc. | Interactive software development system |
| US6307925B1 (en) * | 1996-04-10 | 2001-10-23 | Harris Corporation | Use of wizards/experts in a PBX environment |
| US5799193A (en) * | 1996-04-29 | 1998-08-25 | Siemens Corporate Research, Inc. | Scenario based iterative method for development of an object oriented system model |
| US5933836A (en) * | 1996-05-16 | 1999-08-03 | Lucent Technologies Inc. | Database quality management system |
| US5745738A (en) * | 1996-05-29 | 1998-04-28 | Microsoft Corporation | Method and engine for automating the creation of simulations for demonstrating use of software |
| US5819068A (en) * | 1996-05-31 | 1998-10-06 | United Defense, Lp | Temporally driven simulation engine |
| US6084979A (en) * | 1996-06-20 | 2000-07-04 | Carnegie Mellon University | Method for creating virtual reality |
| US6104395A (en) * | 1996-08-14 | 2000-08-15 | International Business Machines Corporation | Graphical interface method, apparatus and application for opening window of all designated container objects |
| US5781193A (en) * | 1996-08-14 | 1998-07-14 | International Business Machines Corporation | Graphical interface method, apparatus and application for creating multiple value list from superset list |
| US5774120A (en) * | 1996-08-14 | 1998-06-30 | International Business Machines Corporation | Refresh and select-all actions in graphical user interface |
| US5872568A (en) * | 1996-08-14 | 1999-02-16 | International Business Machines Corporation | Application and method for creating a list from pre-defined and user values |
| US5774119A (en) * | 1996-08-14 | 1998-06-30 | International Business Machines Corporation | Graphical interface method, apparatus and application for selection of target object |
| US5867157A (en) * | 1996-08-14 | 1999-02-02 | International Business Machines Corporation | Graphical interface method, apparatus and application for creating and modifying a list of values with multiple components |
| US6195096B1 (en) | 1996-08-14 | 2001-02-27 | International Business Machines Corporation | Graphical interface method, apparatus and application for creating and modifying a multiple-value text list |
| US5818444A (en) * | 1996-08-14 | 1998-10-06 | International Business Machines Corporation | Method, apparatus and application for object selective but global attribute modification |
| US5784057A (en) * | 1996-08-14 | 1998-07-21 | International Business Machines Corporation | Dynamically modifying a graphical user interface window title |
| US5778059A (en) * | 1996-08-30 | 1998-07-07 | Digital Technics, Inc. | Distributed predictive and event-driven processing environment |
| US6011559A (en) * | 1996-11-12 | 2000-01-04 | International Business Machines Corporation | Layout method for arc-dominated labelled graphs |
| US5917498A (en) * | 1996-11-12 | 1999-06-29 | International Business Machines Corporation | Multi-object views in an object modeling tool |
| US5960199A (en) * | 1996-11-12 | 1999-09-28 | International Business Machines Corporation | Model trace view for object-oriented systems |
| US5991536A (en) * | 1996-11-12 | 1999-11-23 | International Business Machines Corporation | Object-oriented tool for registering objects for observation and causing notifications to be made in the event changes are made to an object which is being observed |
| US5907706A (en) * | 1996-11-12 | 1999-05-25 | International Business Machines Corporation | Interactive modeling agent for an object-oriented system |
| US5983016A (en) * | 1996-11-12 | 1999-11-09 | International Business Machines Corporation | Execution engine in an object modeling tool |
| US5893913A (en) * | 1996-11-12 | 1999-04-13 | International Business Machines Corporation | Method for synchronizing classes, objects, attributes and object properties across an object-oriented system |
| EP1015966A2 (en) * | 1996-12-13 | 2000-07-05 | Maves International Software, Inc. | Method, system and data structures for computer software application development and execution |
| US5960432A (en) * | 1996-12-31 | 1999-09-28 | Intel Corporation | Multi-level captioning for enhanced data display |
| US6199193B1 (en) * | 1997-03-18 | 2001-03-06 | Fujitsu Limited | Method and system for software development and software design evaluation server |
| JP3484325B2 (ja) * | 1997-09-02 | 2004-01-06 | 富士通株式会社 | 条件付き回答対応エージェントシステム装置およびプログラム記憶媒体 |
| US6898782B1 (en) | 1997-10-14 | 2005-05-24 | International Business Machines Corporation | Reference-based associations using reference attributes in an object modeling system |
| US6189137B1 (en) * | 1997-11-21 | 2001-02-13 | International Business Machines Corporation | Data processing system and method for simulating “include” files in javascript |
| US6226783B1 (en) * | 1998-03-16 | 2001-05-01 | Acuity Imaging, Llc | Object oriented method of structuring a software step program |
| US6317706B1 (en) * | 1998-03-31 | 2001-11-13 | Sony Corporation | Simulation development tool for an embedded system |
| US6256618B1 (en) * | 1998-04-23 | 2001-07-03 | Christopher Spooner | Computer architecture using self-manipulating trees |
| GB2338090A (en) * | 1998-06-05 | 1999-12-08 | Ibm | A framework customization tool |
| FR2781584B1 (fr) * | 1998-07-03 | 2000-10-20 | Aerospatiale | Systeme de validation par simulation de la specification formalisee des fonctions de systemes complexes |
| AU6269999A (en) * | 1998-09-30 | 2000-04-17 | Alive, Inc. | Interactive method for operating a computer to perform financial projections |
| US6263303B1 (en) * | 1998-10-26 | 2001-07-17 | Sony Corporation | Simulator architecture |
| US6298481B1 (en) * | 1998-10-30 | 2001-10-02 | Segasoft, Inc. | System for modifying the functionality of compiled computer code at run-time |
| US6683613B1 (en) * | 1998-12-23 | 2004-01-27 | Adobe Systems Incorporated | Multi-level simulation |
| US6426748B1 (en) | 1999-01-29 | 2002-07-30 | Hypercosm, Inc. | Method and apparatus for data compression for three-dimensional graphics |
| US7904187B2 (en) | 1999-02-01 | 2011-03-08 | Hoffberg Steven M | Internet appliance system and method |
| US7749089B1 (en) | 1999-02-26 | 2010-07-06 | Creative Kingdoms, Llc | Multi-media interactive play system |
| US7593983B2 (en) * | 1999-04-30 | 2009-09-22 | Canon Kabushiki Kaisha | Data processing apparatus, data processing method, and storage medium storing computer-readable program |
| US6812941B1 (en) | 1999-12-09 | 2004-11-02 | International Business Machines Corp. | User interface management through view depth |
| US6549221B1 (en) | 1999-12-09 | 2003-04-15 | International Business Machines Corp. | User interface management through branch isolation |
| US7878905B2 (en) | 2000-02-22 | 2011-02-01 | Creative Kingdoms, Llc | Multi-layered interactive play experience |
| US7445550B2 (en) | 2000-02-22 | 2008-11-04 | Creative Kingdoms, Llc | Magical wand and interactive play experience |
| US6761637B2 (en) | 2000-02-22 | 2004-07-13 | Creative Kingdoms, Llc | Method of game play using RFID tracking device |
| US6934423B1 (en) * | 2000-03-20 | 2005-08-23 | Intel Corporation | Incorporating camera effects into existing video sequences |
| JP2002073348A (ja) * | 2000-08-31 | 2002-03-12 | Mitsubishi Electric Corp | シナリオ解析型制御システム装置 |
| WO2002020111A2 (en) * | 2000-09-07 | 2002-03-14 | Omnisky Corporation | Coexistent interaction between a virtual character and the real world |
| US7066781B2 (en) | 2000-10-20 | 2006-06-27 | Denise Chapman Weston | Children's toy with wireless tag/transponder |
| AU2002214209A1 (en) * | 2000-11-03 | 2002-05-15 | Wilde Technologies Limited | A software development process |
| US6975970B2 (en) * | 2000-12-15 | 2005-12-13 | Soliloquy, Inc. | Method for designing an interactive system |
| WO2002073860A2 (en) * | 2001-03-08 | 2002-09-19 | Adler Richard M | System for analyzing strategic business decisions |
| US6894690B2 (en) * | 2001-06-20 | 2005-05-17 | Engineering Technology Associates, Inc. | Method and apparatus for capturing and viewing a sequence of 3-D images |
| EP2287723A3 (en) | 2001-07-26 | 2012-11-14 | IRiSE | System and process for gathering, recording and validating requirements for computer applications |
| US7576756B1 (en) * | 2002-02-21 | 2009-08-18 | Xerox Corporation | System and method for interaction of graphical objects on a computer controlled system |
| US6967566B2 (en) | 2002-04-05 | 2005-11-22 | Creative Kingdoms, Llc | Live-action interactive adventure game |
| US20070066396A1 (en) | 2002-04-05 | 2007-03-22 | Denise Chapman Weston | Retail methods for providing an interactive product to a consumer |
| US7674184B2 (en) | 2002-08-01 | 2010-03-09 | Creative Kingdoms, Llc | Interactive water attraction and quest game |
| US9446319B2 (en) | 2003-03-25 | 2016-09-20 | Mq Gaming, Llc | Interactive gaming toy |
| US7487073B2 (en) * | 2003-05-21 | 2009-02-03 | At&T Corp. | Using symbolic evaluation to validate models that have incomplete information |
| US7668824B2 (en) * | 2004-03-01 | 2010-02-23 | Denso Corporation | Interface device, inferring system, and visual expression method |
| US7624383B2 (en) * | 2004-04-30 | 2009-11-24 | Cornell University | System for and method of improving discrete event simulation using virtual machines |
| US20050268173A1 (en) * | 2004-05-11 | 2005-12-01 | National Instruments Corporation | Programmatically analyzing a graphical program by traversing objects in the graphical program |
| US7369977B1 (en) * | 2004-09-20 | 2008-05-06 | The Mathworks, Inc. | System and method for modeling timeouts in discrete event execution |
| US20060129970A1 (en) * | 2004-12-15 | 2006-06-15 | Haas Martin C | Systems and methods for production planning analysis using discrete event simulation |
| US7321804B2 (en) * | 2004-12-15 | 2008-01-22 | The Boeing Company | Method for process-driven bill of material |
| US7979848B2 (en) * | 2005-04-29 | 2011-07-12 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Systems, methods and apparatus for pattern matching in procedure development and verification |
| US7496869B1 (en) | 2005-10-04 | 2009-02-24 | Xilinx, Inc. | Method and apparatus for implementing a program language description of a circuit design for an integrated circuit |
| US8996151B2 (en) * | 2005-11-09 | 2015-03-31 | The Boeing Company | Visualization of product build using precedence transversal method |
| US20070106410A1 (en) * | 2005-11-09 | 2007-05-10 | The Boeing Company | Systems and methods for production planning by visualizing products and resources in a manufacturing process |
| US7761272B1 (en) | 2006-03-10 | 2010-07-20 | Xilinx, Inc. | Method and apparatus for processing a dataflow description of a digital processing system |
| US7380232B1 (en) * | 2006-03-10 | 2008-05-27 | Xilinx, Inc. | Method and apparatus for designing a system for implementation in a programmable logic device |
| US8087007B2 (en) * | 2006-05-08 | 2011-12-27 | Assima Ltd. | System and method for software prototype-development and validation and for automatic software simulation re-grabbing |
| US7797672B2 (en) * | 2006-05-30 | 2010-09-14 | Motorola, Inc. | Statechart generation using frames |
| US7657434B2 (en) * | 2006-05-30 | 2010-02-02 | Motorola, Inc. | Frame goals for dialog system |
| US7505951B2 (en) * | 2006-05-30 | 2009-03-17 | Motorola, Inc. | Hierarchical state machine generation for interaction management using goal specifications |
| US8578325B2 (en) * | 2006-10-04 | 2013-11-05 | The Florida International University Board Of Trustees | Communication virtual machine |
| US20080147364A1 (en) * | 2006-12-15 | 2008-06-19 | Motorola, Inc. | Method and apparatus for generating harel statecharts using forms specifications |
| US20080148222A1 (en) * | 2006-12-19 | 2008-06-19 | Moxa Technologies Co., Ltd. | Programmable automatic triggering system and apparatus |
| KR101524015B1 (ko) | 2007-01-11 | 2015-05-29 | 코닌클리케 필립스 엔.브이. | 실행취소/재실행 메커니즘을 제공하는 방법 및 장치 |
| US8234624B2 (en) * | 2007-01-25 | 2012-07-31 | International Business Machines Corporation | System and method for developing embedded software in-situ |
| US20100004916A1 (en) * | 2008-07-03 | 2010-01-07 | The Boeing Company | Process Analyzer |
| US20110029904A1 (en) * | 2009-07-30 | 2011-02-03 | Adam Miles Smith | Behavior and Appearance of Touch-Optimized User Interface Elements for Controlling Computer Function |
| US8656314B2 (en) * | 2009-07-30 | 2014-02-18 | Lenovo (Singapore) Pte. Ltd. | Finger touch gesture for joining and unjoining discrete touch objects |
| US20110029864A1 (en) * | 2009-07-30 | 2011-02-03 | Aaron Michael Stewart | Touch-Optimized Approach for Controlling Computer Function Using Touch Sensitive Tiles |
| EP2625606A4 (en) | 2010-10-08 | 2014-11-26 | Irise | SYSTEM AND METHOD FOR EXTENDING A VISUALIZATION PLATFORM |
| US20130030899A1 (en) * | 2011-07-29 | 2013-01-31 | Shane Ehlers | System and method for preventing termination of online transaction |
| US20160162168A1 (en) * | 2014-12-05 | 2016-06-09 | Microsoft Technology Licensing, Llc | Interaction sensing and recording of a process to control a computer system |
| US20160260060A1 (en) | 2015-03-03 | 2016-09-08 | International Business Machines Corporation | Determining compatibility of multiple specifications |
| US10712734B2 (en) * | 2017-03-31 | 2020-07-14 | Cae Inc. | Continuous monitoring of a model in an interactive computer simulation station |
| US10248385B1 (en) * | 2017-11-30 | 2019-04-02 | International Business Machines Corporation | Extracting mobile application workflow from design files |
| WO2021123100A1 (en) * | 2019-12-20 | 2021-06-24 | Abstraktor Ab | System and method for testing of system under test |
| CN112685206B (zh) * | 2021-01-07 | 2024-04-12 | 北京全路通信信号研究设计院集团有限公司 | 一种交互数据正确性判断方法、装置、电子设备和介质 |
| US20220374428A1 (en) * | 2021-05-24 | 2022-11-24 | Nvidia Corporation | Simulation query engine in autonomous machine applications |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4656580A (en) * | 1982-06-11 | 1987-04-07 | International Business Machines Corporation | Logic simulation machine |
| US4677587A (en) * | 1985-05-14 | 1987-06-30 | Sanders Associates, Inc. | Program simulation system including means for ensuring interactive enforcement of constraints |
| US4845665A (en) * | 1985-08-26 | 1989-07-04 | International Business Machines Corp. | Simulation of computer program external interfaces |
| US4951195A (en) * | 1988-02-01 | 1990-08-21 | International Business Machines Corporation | Condition code graph analysis for simulating a CPU processor |
| US5050074A (en) * | 1988-03-28 | 1991-09-17 | Digital Equipment Corporation | System for facilitating coordination of activities by a plurality of actors with an object database and state/action identification |
-
1990
- 1990-04-17 US US07/510,373 patent/US5247651A/en not_active Expired - Fee Related
-
1991
- 1991-02-07 CA CA002035949A patent/CA2035949C/en not_active Expired - Fee Related
- 1991-04-09 EP EP19910303111 patent/EP0453152A3/en not_active Withdrawn
- 1991-04-10 JP JP3103546A patent/JPH04227538A/ja active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8151242B1 (en) | 1999-04-06 | 2012-04-03 | Ns Solutions Corporation | Description support apparatus and method for requisition sheet, and recording medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CA2035949A1 (en) | 1991-10-18 |
| EP0453152A3 (en) | 1993-05-26 |
| CA2035949C (en) | 1995-08-29 |
| US5247651A (en) | 1993-09-21 |
| EP0453152A2 (en) | 1991-10-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH04227538A (ja) | プログラム仕様の対話的な設計・検査を支援する方法およびシステム | |
| Sukaviriya et al. | Coupling a UI framework with automatic generation of context-sensitive animated help | |
| Woodside et al. | Performance by unified model analysis (PUMA) | |
| MacIntyre et al. | A distributed 3D graphics library | |
| Zhang et al. | Design, construction, and application of a generic visual language generation environment | |
| Phillips | Architectures for synchronous groupware | |
| Davoli et al. | Parallel computing in networks of workstations with paralex | |
| Spiteri et al. | An architecture to support storage and retrieval of events | |
| Coutaz et al. | Applications: A dimension space for user interface management systems | |
| US20020147963A1 (en) | Method and apparatus for generating machine control instructions | |
| ENGELS et al. | Object-oriented modeling of multimedia applications | |
| Zhong et al. | An investigation of reorganization algorithms | |
| Sun et al. | A demonstration-based model transformation approach to automate model scalability | |
| Attali et al. | Semantic-based visualization for parallel object-oriented programming | |
| Miriyala et al. | Visualizing actor programs using predicate transition nets | |
| CN111459547B (zh) | 一种函数调用链路的展示方法和装置 | |
| JPH04227539A (ja) | プログラム仕様の生成を支援する方法 | |
| Takeda et al. | MERA: Meta language for software engineering | |
| Niu et al. | OOPN: Object-oriented Petri Nets and Its Integrated Development Environment | |
| Astley et al. | A visualization model for concurrent systems | |
| Buffo | Experiences in coordination programming | |
| Kuraj et al. | Exploring the role of sequential computation in distributed systems: motivating a programming paradigm shift | |
| Corley | Exploring efficient and scalable omniscient debugging for MDE | |
| Liao et al. | A Functional Reactive DSL Service Facility for Mixed-Reality Interactive Performance Art | |
| King et al. | Multimedia document engineering in MCF |