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)
- Processing Or Creating Images (AREA)
- Devices For Executing Special Programs (AREA)
Abstract
(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。
め要約のデータは記録されません。
Description
【発明の詳細な説明】
【0001】
【産業上の利用分野】本発明は、コンピュータ・システ
ムおよび通信システムのためのプログラム仕様を開発す
る方法および装置に関する。 【0002】 【従来の技術】コンピュータおよび電気通信システムの
作用を制御するための複雑なコンピュータ・プログラム
やソフトウェア・システムの開発には、大きな作業努力
を必要とする。コンピュータ・プログラマ(ソフトウェ
ア開発者)は、複雑なソフトウェア・システムの設計、
コーディングおよび検査に多大な努力を費やす。複雑な
システムに対しては、ソフトウェア開発サイクルと言わ
れる設計、執筆およびコーディングの行程に何年もかか
ることもしばしばある。長年に渡りソフトウェア開発者
が学んだことは、ソフトウェアの検査にサイクルをあま
り費やさず、ソフトウェアに対する必要条件の立案、ソ
フトウェアの設計、およびコーディングに大部分を費や
せば、開発周期が短縮されると言うことである。この知
識が、ソフトウェア技術の進歩と相まって、さらに複雑
なソフトウェア・システムの開発をもたらした。 【0003】ソフトウェア技術の進歩にもかかわらず、
ますます複雑化するコンピュータ・ソフトウェアおよび
ソフトウェア稼働システムの開発は、依然として困難で
ある。この難しさのために、効率的かつ完全なソフトウ
ェア設計システムの重要性が増してきた。仕様設計が、
ソフトウェアの開発を容易にするための重要な第1歩で
ある。仕様書は、ソフトウェア・システムが満足しなけ
ればならない必要条件を含み、システムがどのように作
用しなければならないかを指定するものである。仕様書
は、その記述対象であるソフトウェア・システムと同様
に、生成がますます困難になってきた。これに対する1
つの理由は、仕様の生成に必要なソフトウェア環境の詳
細な知識である。 【0004】ソフトウェア・システムの作用をモデル化
することによって仕様の開発および検査を行うことの難
しさを軽減するために、ソフトウェア開発者はソフトウ
ェア・シミュレータを使用する。シミュレータは、シス
テムに関する入力に基づいて、そのシステムの作用をモ
デル化するプログラムを生成する。シミュレータは、仕
様の開発に役立つが、問題もいくつかある。第1に、シ
ミュレータは、単純でなじみ深いモデルを基にしておら
ず、システムの適切なモデルを生成するには、少なくと
もシミュレータ「言語」のプログラム作製知識が必要と
なる。開発者は、シミュレーションされるシステムがい
かに作用するかということに関わらなければならないだ
けでなく、シミュレーション・プログラムの開発にかな
りの量の思考を充てる必要がある。こうして、ソフトウ
ェアの仕様設計過程に複雑さが加わることになる。 【0005】次に、シミュレータは、1つのシステムの
独立した部分に対し特定の入力を要求するとともに特定
の出力を与えて、その部分を別個の実体として表す。こ
れらの実体の入力と出力が一致しない限り(しばしば一
致しない)、実体どうしが互いに作用し合う(「接続」
される)ことができないので、問題である。このように
、シミュレータを使用する開発者は、システムの部分の
全体的な統合を常にみることはできない。 【0006】最後に、シミュレーション中に開発者が、
誤りを発見したり、システムの作用のある部分を望む場
合、開発者は、シミュレーションを停止し、所望の変更
を行い、シミュレートするべきプログラムをコンパイル
しなおしてから、シミュレーションを最初から始めなけ
ればならない。このように、開発者は、変更結果を直ち
に見ることができないため、変更を行う処理に時間がか
かり、時間を非効率的に使用する結果となる。 【0007】 【発明が解決しようとする課題】従って、従来の技術の
課題は、利用者の広範なプログラミング知識を必要とし
ないソフトウェアの効率的な仕様設計手段を与えること
である。 【0008】 【課題を解決するための手段】前記の問題を解決するた
めの本発明の一実施例は、仕様の画像記録およびアニメ
ーションのための(GRAS=Graphical R
ecording and Animation of
Specifications)システムである。G
RASシステムは、プログラム仕様の記録、シミュレー
シ(アニメーション)、および洗練をグラフィカルに行
うために使用される。このシステムは、実例によるプロ
グラム仕様の設計に対応している。 【0009】GRASシステムの目的は、プログラミン
グの知識が少ない利用者がプログラム仕様を容易に作る
ための便宜を与えることである。この目的は、馴染み深
いモデルに基づくユーザ・フレンドリな環境を与えるこ
とによって達成される。GRASシステムは、プログラ
ム用の仕様の作製が演劇の作製、演出、テープ録画、お
よび編集に類似するビデオ・スタジオの隠喩(meta
phor)(VSM)に基づいている。ビデオ・スタジ
オ・メタファは、リハーサルによるプログラミングで用
いられる劇場の隠喩(theater metapho
r)を拡張する。例えば、ゼロックス社の1986年5
月のSCL−84−1のローラ・グールド(Laura
Gould)およびウィリアム・フィンツァ(Wil
liam Finzer)による「リハーサルによるプ
ログラミング(Programming by Reh
earsal)」を参照。VSMに基づくシステムを用
いて仕様を作製するには、プログラミングの知識はあま
り必要ない。技術者は、仕様設計システムには注意をほ
とんど向けずに、目的のシステムが如何に作用するべき
かに集中することができるので、ソフトウェアの仕様設
計過程において複雑さが軽減され、好都合である。 【0010】GRASシステムでは、仕様のソフト的記
録手段である「テープ」に対し、利用者が入力を与える
。GRASシステムは、一群のシナリオ例のステップを
記録することにより、またそれらのシナリオ例に対する
追加的なグラフィック規則を引き出すことにより、テー
プを生成する。1つのステップにより、シミュレートさ
れるテープのアクタどうしの間のメッセージ渡しによる
相互作用が指定される。(後述のように、「アクタ(a
ctor)」の概念は、人工知能の分野で周知である。 ) 【0011】アクタは、データとそのデータを操作する
手続きとを備えたコンピュータ・ソフトウェア構造であ
る。GRASで使用されるアクタも、知識ベースおよび
そのデータへの変更の履歴を持っている。アクタは、電
話若しくは電話交換システムなどのシステムの物理的構
成要素、またはプロセス若しくはデーターベースなどの
ソフトウェア構成要素、またはそのシステムと相互に作
用する作因、人などを表す。GRASでは、シナリオ例
の1ステップを記録するために、利用者は、そのステッ
プ用のセンダ(sender)およびレシーバ(rec
eiver)のアクタ、センダのアクタからレシーバの
アクタに送られるメッセージ、およびそのステップが実
行される前にシステムに存在していなければならない条
件を指定する。 各ステップは、テープ上に規則として記録され、そのシ
ナリオ例において実行される。利用者は、そのシナリオ
例の実行(そのテープの再生)、修正の実施、新たなス
テップの追加、または新たなシナリオ例の生成によって
、そのテープを対話的に洗練することができる。 【0012】コンピュータ・システムに対するコンピュ
ータ・ログイン・シーケンスの設計は、GRASの簡単
な使用例となる。コンピュータ・ログイン・シーケンス
のためのアクタは、コンピュータ、端末、および利用者
である。GRASを使用する技術者が、コンピュータ・
ログイン・シーケンスを次のように実現することを希望
するものと仮定する。即ち、(1)コンピュータが、「
sendlogin」要求メッセージを端末に送ること
によって、そのシーケンスを活性化する。(2)次に、
端末が、ログイン・プロンプトを利用者に表示する。(
3)利用者が、ログイン・ネームをキーボード入力を介
して端末に送る。(4)端末が、そのログイン・ネーム
をコンピュータに送信する。(5)コンピュータが、そ
の端末にパスワード入力手順を開始するようにメッセー
ジを送る。(6)端末が、パスワード・プロンプトを利
用者に表示する。(7)利用者が、パスワードをキーボ
ード入力を介して端末に送る。そして、(8)端末が、
そのパスワードをコンピュータに送る。 【0013】このコンピュータ・ログイン・シーケンス
のテープのための入力を与えるために、GRASの利用
者は、そのシーケンスの最初のステップを指定すること
によって開始する。これを行うことで、利用者は、1つ
のシナリオ例の最初のステップを指定することになる。 完全なプログラムは、複数のシナリオ例によって記述さ
れる。前記のステップ(1)を指定するには、まずセン
ダのアクタをコンピュータに、レシーバのアクタを端末
に、渡されるメッセージを「send login」に
指定する。 このステップは、利用者にグラフィカルに表示される一
方、そのシナリオ例の一部として記録される。前記のス
テップ(2)を指定するために、利用者は、センダ・ア
クタを端末に、レシーバ・アクタを利用者に、そして渡
されるメッセージを「ログインして下さい:」と指定す
る。やはり、このステップも、記録されつつ、利用者に
グラフィカルに表示される。そして、利用者は、そのシ
ーケンスの残りのステップを同じ要領で指定する。シー
ケンスを記録した後、利用者は、そのテープを再生する
ことにより、そのコンピュータ・ログイン・シーケンス
をグラフィカルにシミュレートする。コンピュータ・ロ
グイン・シーケンス全体のGRASによるグラフィカル
な表示を図5に例示する。 【0014】利用者は、記録中いつでも記録を停止して
、既に指定したステップをシミュレートするためにテー
プを再生することができる。ステップが正しくなければ
、そのステップの対話的な「アンドゥ」、アクタの変更
、メッセージの変更、またはそのステップに対する事前
条件の変更を行った後、そのステップを再び再生するこ
とができる。これにより、プログラム仕様の編集および
洗練が対話的に可能となる。 【0015】前記の例は、本発明の作用を説明するもの
であるが、本発明の原理によれば、コンピュータが利用
者の入力に対話的に応じてプログラムの仕様を生成する
。当分野はさておき、このプログラム仕様システムによ
って、仕様に対し対話的に与えられる変更に応じて、そ
の仕様のプログラムを再コンパイルすることなく、それ
らの変更のシミュレーションを直ちにグラフィカルに表
示する便宜が提供される。開発者は、より迅速に、より
効率的に、しかもシミュレーション・システムの操作の
知識もほとんど無しに、仕様を作製することができるの
で、好都合である。 【0016】当分野からさらに逸れるが、本発明により
、アクタ(これは、データの構造とプログラム手順から
なるソフトウェア対象である)の合併、およびアクタの
作用の合併がサポートされる。「アクタ」という考えは
、人工知能に由来する周知の概念である。例えば、19
86年、MITプレス刊のガル・アーガ(Gul Ag
ha)による「アクタ−−−−分散システムにおける同
時処理のモデル(Actors: A Modelof
Concurrent Computation i
n Distributed Systems)」を参
照のこと。この合併処理により、開発者は、プログラム
・システムの部品の全体的な統合を見ることが可能とな
る。 【0017】本発明の典型的な実施例であるGRASは
、VSMに基づくオブジェクト指向で知識ベースの視覚
的プログラミング・システムである。GRASは、利用
者の入力を用いてシステムの視覚的シミュレーションと
仕様データーベースを生成し、さらに詳細な入力を受信
した時、そのデーターベースを増強する。VSMは、親
しみやすい単純なモデルを提供するので、プログラミン
グについても、そのシステムについても詳しい知識なし
に仕様を生成することができるので、好都合である。 【0018】仕様のシナリオ例の記録(入力)、再生(
実行)、およびアンドゥ(逆向きの実行)を行うための
機構が、GRASのソフトコーダ(SoftCoder
)モジュールによって提供される。ソフトコーダは、ア
クタ間の作用の規則を記述する「(ビデオ)テープ・プ
ログラム」を処理して、仕様プログラムの実行の完全な
履歴からなる「テープ・シナリオ」を生成する仮想的な
装置である。テープ・プログラムの各ステップは、算術
演算および(または)論理演算の集合、アクタ・データ
、およびステップを「アンドゥ」することによって逆戻
りすることができるために仕様の一部を対話的に変更す
る機構を利用者に提供するアクタ間の通信を表すメッセ
ージからなる。効率的に誤りを訂正し、シミュレーショ
ン中に仕様の変更を行って、その結果を直ちに見ること
ができるので、好都合である。GRASのビジュアル・
オブジェクト網管理(MoVon=managemen
t of visual object networ
ks)モジュールおよびアクタ・フレーム(AF)モジ
ュールにより、アクタおよびアクタの作用を合併する機
構が提供されるため、利用者は、全体的に統合された仕
様を見ることが可能となる。GRASは、仕様の別個の
部分の統合および組み合わされた作用を見る便宜を利用
者に与えるので、好都合である。 【0019】プログラム用の仕様を対話的に生成する方
法は、キーボードやマウスなどの入力装置を介したアク
タ・データの受信に応じて、複数のテープ・シナリオに
対するアクタを指定すること、およびそのアクタ・デー
タを格納することからなる。アクタの指定には、新たな
アクタの生成、以前に生成されたアクタの選択、および
アクタ・データの修正が含まれる。システムは、入力装
置を介して作用ステップを受信すると、これに応じて、
そのステップを後の実行のために記録する。これらのス
テップは、アクタ間の通信、アクタ間の関係、アクタに
対する論理的または算術的な演算、および複数のテープ
・シナリオに対する判断点からなる。最初の判断の選択
を入力装置を介して受信すると、これに応じて指定の一
貫性を評価するために、最初のテープ・シナリオが実行
される。最初のテープ・シナリオの実行は、一組の所定
の条件の発生に基づいてシナリオのステップをシミュレ
ートし、そのシミュレーションの結果を記録することか
らなる。シミュレートすることは、アクタ間の関係の表
明、アクタ間の通信の実行、アクタに対する論理的また
は算術的な演算の実行、または判断による選択の入力の
要求のうちの1つまたはそれ以上からなる。最終的に、
判断の選択が入力装置を介して代わる代わる受信され、
それに応じて、追加のテープ・シナリオが順次実行され
る。 【0020】このシステムは、作用ステップのシミュレ
ーション中に入力装置を介して受信した命令に応じて、
指定された作用ステップの後にシミュレーションを停止
するようになっている。そして、入力データの受信に応
じて、追加のアクタ・データおよび追加の作用ステップ
をシステムが格納し、その追加のステップおよびアクタ
を含めて、シミュレーションが再開される。対話的に仕
様の追加を行い、それらの追加の結果を直ちに見ること
ができるので、好都合である。作用ステップは、シミュ
レーション中に逆進可能(「アンドゥ可能」)である。 復元(アンドゥ)されたステップは修正されて、シミュ
レーションが再開され、その復元されたステップは、修
正された内容で再びシミュレートされる。仕様の変更を
対話的に行い、その変更結果を直ちに見ることができる
ので、好都合である。 【0021】作用ステップをシミュレートすることは、
プログラム経路が指定されていない判断箇所の選択を自
動的に識別すること、これらの選択および不完全なプロ
グラム経路を利用者に通知することからなる。また、作
用ステップをシミュレートすることには、アクタ・デー
タが完全であるかどうかを確認し、不完全なデータを利
用者に知らせることも含まれる。このように、不完全な
仕様もシミュレートできるので都合がよい。本システム
では、複数の水準の表示が可能であり、各水準は、シミ
ュレーションの詳細水準に対応する。利用者は、各作用
ステップに対し、異なる水準集合を指定することができ
る。テープ・シナリオを実行する場合、GRASシステ
ムは、その集合の要素である水準にあるステップに限り
、その結果を表示するが、実際には、他の指定された水
準のすべてのステップをシミュレートしている。利用者
は、情報がさらに利用できるようになったときに、より
詳細なステップを仕様に追加し、それらのより詳細なス
テップのシミュレーション結果を見ることによって、仕
様を対話的に洗練することができるので、好都合である
。 【0022】GRASシステムでは、2つ以上の作用ス
テップを同時にシミュレートすることが許される。本発
明のシステムでは、同時に発生するプログラム経路の両
方に共通のアクタがある場合、その共通のアクタのデー
タにアクセスしようとする他のアクタどうしが、同じデ
ータを同時にアクセスしないことが保証される。本シス
テムでは、そのテープ・シナリオのあるステップのシミ
ュレーションを所定の時間だけ遅らせたり、または最初
の作用ステップシミュレーション時刻からシミュレーシ
ョン中に算出された時間だけ遅らせたり、あるいは最初
の作用ステップのシミュレーションを2番目の作用ステ
ップがシミュレートされるまで遅らせたりすることが可
能である。本システムでは、呼び出されたテープ・プロ
グラムを呼び出しているテープ・プログラムの実行の一
部として実行し、その呼び出されたテープ・プログラム
の実行に続いて、呼び出しているテープ・プログラムに
戻ることも可能である。また本システムでは、第1のテ
ープ・プログラムの第1の作用ステップのシミュレーシ
ョンの後と前記第1のテープ・プログラムの第2のステ
ップのシミュレーションの前との間に、第2のテープ・
プログラムの部分集合のコピーを挿入することも可能で
ある。作用ステップの同時シミュレーションによって、
システムの作用の現実的な考察が与えられる結果、首尾
一貫した仕様が生成され、好都合である。 【0023】 【実施例】仕様に関するグラフィカルな記憶および動画
(GRAS=Graphical Recording
and Animation of Specifi
cations)のシステムは、この種のシステムにと
って有用な特別な術語体系で記述された主要な概念に基
づく。これらの専門用語を理解することは、GRASシ
ステムの理解に役立つので、GRASで使用される特殊
な専門用語を以下において定義する。 【0024】重要用語集 バックステージ:所与の制作スタジオに所属する各アク
タ(役者の意)は、その特有のアドレス(例えば、出生
名と住所、社会保証番号)で分かる。一度に利用できる
全アクタの集合をバックステージ(舞台裏の意)と呼ぶ
。各アクタは、仮にそれが幾つかのテープで使用され、
そのGRASシステムで現在利用可能なテープの間で物
理的に共有されていても、この文脈においては、ただ1
つの存在でしかない。テープが録音される前かされてい
る間に、1つ以上のスタジオ室を選択することができる
。各スタジオ室は、異なる視野または眺望を記録するの
に使用でき、各スタジオは、記録カメラを持っている。 必要に応じて、記録の前か記録中に、アクタの選択/追
加が行われる。 【0025】フレーム:フレームは、情報の分類または
概念の組織化に使用される柔軟なデータ構造である。こ
のデータ構造の柔軟性は、フレームが通常、拡張可能か
つ再定義可能であると言う事実からきている。フレーム
・システムは、通常、IS−AまたはAKO(A−ki
nd−of)分類法に基づく階層的な継承機構を備えて
いる。 【0026】アクタ:アクタは、オブジェクトの拡張で
ある。オブジェクトは、データとそれを操作する手続き
(プロシージャ)からなる。アクタは、データを(スロ
ットと値を用いて)オブジェクトととしてカプセルに包
む。しかし、カプセル化された集合のスロットだけでな
く、それらのスロットの値も、時間と共に変化すること
ができ、これらの変化は、可逆的である。隠喩的観点か
らすれば、アクタは、情報の範疇および情報の値を記憶
したり忘れるだけでなく、その寿命期間内の特定の瞬間
にそれが持っていた情報を思い出すことも可能である。 この特徴を実現するために、アクタは、そのデータ空間
(スロットおよび値)に為された変更の履歴をとってい
る。アクタは、任意の時刻にその時点のデータ空間の記
号による記述を生成したり(自己記述)、2つの異なる
時刻における記号的データ空間の間の差の記号による記
述を生成したりすることができる。これらの記述内容は
、アクタ・システムの実施によって、履歴に維持される
。 【0027】アクタの実施:GRASに対しアクタを実
施することにより、次の可能性がサポートされる。アク
タの一般的な性質として、新たな役割を記憶し、前の役
割を忘れ、存在する情報を変形させ、新たな情報を獲得
し、他のアクタに情報を伝達し、(オプションで)種々
の衣装でいるのが見られる(可視的表現は、このような
アクタにあってもなくてもいい属性である)という能力
がある。アクタは、共有、再利用、合併、分割、幾つか
のアクタの組み合わせとしての生成、またはサブアクタ
への分解が可能である。論理的または算術的な演算に基
づいて、アクタの役割を特定の状況によって変更するこ
とができる。 【0028】アクタの知識ベース:蓄積(記憶)および
削除(忘却)が可能なアクタの属性の集合が、アクタの
動的で機密性の知識ベースを構成する。ここでは知識ベ
ースの機密性は、次の意味で定義される。即ち、知識は
、他のアクタと共有されておらず、他のアクタが直接利
用することはできない。あるアクタの情報を他のアクタ
が利用できるのは、他のアクタが処理中に明確にそれを
要求した場合に限られる。アクタの知識ベースは、アク
タの環境を用いて定義される。アクタのデータ空間の記
述D(A,t)の実現。 【0029】アクタと継承:アクタのフレームの記述に
用いられるAKO関係は、フレームの分類を与えるため
に内部的に使用される。しかし、GRASにおいては、
利用者がAKO関係を直接利用することはできない。ア
クタに関し利用できる操作(処理)の集合は、利用者が
多重継承を必要とすることなく通信のアクタ指向モデル
を設計するに十分である。GRASがアクタ・システム
によって半自動的に維持できるならば、継承がGRAS
の利用者に与えられるだけである。 【0030】アクタの合併および融合:アクタ・モデル
では、合併という概念とその実現とによって、さらに柔
軟性が提供される。次のようにいろいろな水準の合併が
可能である。 【0031】1)改名:アクタのステージ名を新たなス
テージ名で置き換え、そのアクタは同じ規則の集合を使
用する。ここで、ステージ名は、特定のシナリオの実行
において、このアクタを参照するために使用される名称
である。 【0032】2)アドレスの変更:アクタのアドレス(
識別情報)を変更する。新たなアドレスが既存のアクタ
のアドレスである場合、実際に合併が行われる。 【0033】3)合併:アクタAが既存のもう1つのア
クタBと合併される場合、合併の種類は、結果としての
新たなアクタCがB(属性と関係)になるものから、C
がAになったり、CがAおよびBの属性と関係との組み
合わせになるものまで、連続的に変化し得る。ただし、
何れの場合も、結果として得られるアクタCは、Aおよ
びBのすべての規則を継承している。これらの規則の適
用可能性は、Cの結果としての属性と前の規則との関数
である。全く適合しない規則ならば、それらを取り除い
ても良い。規則の管理の一部は、論理的分析および到達
可能性アルゴリズムに基づいて自動化することができる
。 【0034】4)融合:アクタが第2のアクタに完全に
加えられ融合する(C=A+B)。これは、完全な合併
の場合である。この結果は、その融合が起こる前に何れ
かのアクタが使用された場所ならどこでも使用される新
たなアクタである。従って、新たなアクタは、両方のア
クタのすべての規則を継承する。また、新たなアクタは
、両方のアクタからすべての関係および構成要素も継承
するという意味では「怪物」である。例えば、端末を普
通の旧式電話サービスの(POTS)電話と融合する場
合、結果として得られる「怪物」は、端末とPOTS電
話との両方の特徴を持った電話端末である。この「怪物
」は、POTS電話の特徴を持った端末とも、端末の特
徴を持ったPOTS電話とも解釈することができる。 この特徴は、新たな設計について実験を行う場合に役立
つ。 【0035】2つのアクタを合併することは、アクタと
それらの関係から成る2つのネットワークを合併するこ
とになる可能性がある。アクタのネットワーク(アクタ
網)は、関係によって接続された一群のアクタから成る
。例えば、アクタ網は、一種の(AKO=A−Kind
−Of)関係に基づくことができる。1つのアクタ網(
NA)が、一種の(A−Kind−Of)ドイツ人であ
るすべてのアクタから成ることもあれば、別のアクタ網
(NB)が、一種の(A−Kind−Of)フランス人
であるすべてのアクタから成ることもある。アクタAが
一種のドイツ人であり、かつアクタBが一種のフランス
人である場合、(NA)と(NB)との合併は、すべて
のドイツ人がフランス人になるか、すべてのフランス人
がドイツ人になるか、すべてのドイツ人およびフランス
人がフランス系ドイツ人、即ち両人種の組み合わせにな
るかの何れかになる可能性がある。 【0036】アクタに与えられる合併処理は、動的であ
り、利用者が実行時に呼び出すことができる。さらに、
アクタは、それ自体の属性および関係の変化を記憶する
能力を持っているので、アクタに関する他のすべての処
理と同様に、合併処理を元どうりにする機構(undo
)を実行することができる。 【0037】分解機構を与え、1つの複雑なアクタから
1組のさらに単純なアクタどうしの間の通信機構へと設
計の展開を助けるために、分割作用素を利用できるよう
にする。これは、伝達情報の送信または処理が最小単位
の処理であるから、特に重要である。分割により、伝達
情報をさらに小さな単位の処理へと分解する機構が与え
られる。 【0038】アクタとオブジェクト:アクタは、メッセ
ージ伝達方法を明確に定義されることがない代わりに、
属性および作用の記憶および忘却、伝達情報の送信およ
び処理、ならびに作用のシミュレーションを行う基本的
な方法を、そのアクタのクラスから継承する。はじめか
ら種々の(所定の)クラスから継承する代わりに、必要
に応じて新たな情報のスロットおよび値を追加なり、変
更なり、削除なりを行って、アクタを累進的に定義・洗
練することができる。比喩的に言えば、あるアクタの「
個性」、即ち一般的な作用は、前もっては分からないが
、このアクタが演じているすべてのテープから実験的観
察に基づいて集められる。アクタは、所定の組の作用に
関して、従来のオブジェクトのように独自に存在してい
るわけではなく、種々の作用がそれらのために利用でき
るようになる種々のシナリオを背景として存在するので
ある。 【0039】オーディション:所与の作業(タスク)を
行うアクタを選択するために用いられる処理(プロセス
)を指す。アクタは才能によって選択される。ここで、
才能は、アクタの属性(属性は、そのアクタの作用と直
接連絡している)とそのアクタおよび他のアクタの間の
現在の関係的依存状態の集合との関数として定義される
。オーディションの処理(audit)には、アクタの
要員の中から所与の作業を行う適任者を特定することが
伴う。 【0040】生成(creation):才能の記述に
従って新たなアクタを生成する処理である。新たなアク
タのデータ構造は、前記の記述に匹敵する内部の属性に
よって作られる。生成処理によって、アクタと関係から
成る集合(アクタ網)を生成する結果になることがある
。才能の記述が空の場合、最小のアクタのデータ構造が
生成される。アクタの才能の記述に特定のアクタのアド
レス(識別情報)が入っている、つまりアクタの才能の
記述の評価結果が特定のアクタのアドレスとなるならば
、そのアドレスにはアクタが既に存在し、そのアクタが
再利用される。 【0041】破壊:これは、アクタ要員アドレスからあ
るアクタのアドレスを削除し、その履歴を停止し、さら
にそのアクタのデータ構造、他のアクタとの関係および
(オプションで)現在見えている装置からそのアクタの
可視表示を削除する作用である。システムの実現状態の
よって、この処理が「ガーベジ・コレクション」(不要
になったデータの削除)を伴うことがあったり、なかっ
たりする。代用:アクタが作業を完成することができな
い場合、その代わりに代用アクタを選択することができ
る。代用は、オーディション処理を用いて行われる。 【0042】転送:2つのアクタがある場合、AからB
への転送は、AおよびBのそれぞれのアドレス(識別情
報)は維持しながら、すべての属性および関係をAから
Bに与えることになる。 【0043】クローン生成:アクタのクローン生成によ
り、元のもののすべての属性を持つ、そのアクタの新た
なインスタンスが作られる。クローンは、クローンと元
のアクタの何れか一方の属性の中の1つに変更が為され
るまでは(空間を節約するために)元のアクタと属性を
共有することができるが、変更されると、属性は物理的
に分離される。アクタ自体であるアクタの属性は別とし
て、最初は、デフォルトによって、すべての値が、元の
アクタとクローンとの間で共有される。例えば、システ
ムにおいて、あるアクタが2つの属性、即ち送受話器お
よび電話番号を持つ電話であると仮定する。すると、送
受話器もアクタとなり得る。この例において、送受話器
もアクタである場合、この電話をクローン生成すると、
クローンとオリジナル(元のアクタ)は、はじめ電話番
号の値を共有するが、同じ送受話器は共有しない。これ
は、クローンの送受話器の「属性」が新しいアクタだか
らである。値だけが、クローンとオリジナルとの間で共
有されるのであって、アクタは共有されない。 【0044】アクタをクローン生成すると、ある関係に
よって互いに接続されたアクタ網(例えば、1つのアク
タと、部分の関係(Part−Of relation
)にあるその幾つかの構成要素と)のクローンを生成す
ることがある。クローンはそのオリジナルとは異なった
アドレスを持つ。クローン生成は、(データが、変更さ
れるまでは再利用されるので)費用のかからないコピー
を作る機構である。 クローンの(オプションの)視覚的表現は、例示された
アクタの名称でのインスタンス番号の追加を除けば、オ
リジナルと同じである。 【0045】作用規則:ビデオ・スタジオの比喩(VS
M=Video Studio Metaphor)で
は、作用の規則は、(事実の独立した知識ベースとして
使用される)アクタの集合、これらの知識ベースの叙述
子の組み合わせ、アクタ間の通信メッセージの集合、お
よび計算と表明の集合を含めるための、前記の定義の拡
張である。アクタ集合Aについての作用規則Rは、次の
形式を用いて記述することができる。 R(A):f(P(A))=>M(A)=>g(Q(A
,M(A)))ただし、Aはアクタの集合であり、P(
A)はアクタに関する叙述子の集合であり、f(P(A
))は、これらの叙述子の関数(例えば、ブール表現)
であり、M(A)は、アクタ間の通信のオプションの集
合であり、Q(A,M(A))は、そのアクタの知識と
通信集合M(A)から得られる情報とに基づいて集合A
のアクタに対して行われる計算およびその結果としての
表明の集合であり、gは、規則R(A)の完成の尺度と
して用いられる合成関数(例えば、ブール表現)である
。ブール的仮定の下では、R(A)の実行が成功裏に終
了した場合、g(Q(A,M(A)))は、真でなけれ
ばならない。 【0046】R(A)の定義において、集合Aは、A=
a1、a2、....、のようにあからさまに(即ち、
列挙して)定義することも、抽象的に定義することも可
能である。Aが抽象的に定義される場合、規則R(A)
に対するアクタを特定する論理規則の集合A=Audi
t{X1,X2,...,Xn}を用いてAを記述する
ことができる。これらの論理規則によって、所与の役割
を演じるために各アクタに要求される特性{X1,X2
,...,Xn}を描写することができる。特性は、ア
クタの属性と値とで構成されたパタン一致表現でよい。 例えば、種類の検査、クラス依存状態の検査、接続種類
の検査(「a」と「b」との間にワイヤ接続がるか?)
、または値の照合(この局に800という電話番号があ
るか?)をアクタの特性に含めることができる。R(A
)に対する特性の集合によって記述される候補のアクタ
を特定するために、オーディション処理(audit)
が使用される。Aのアクタを記述する規則によって、新
たなアクタの生成、既存のアクタの再利用または組み合
わせを要求することができる。 【0047】OOスクリプト:センダ(sender)
のアクタとレシーバ(receiver)のアクタとの
間の単一処理を表すのに使用される特定のフォーマット
およびシンタックスを指す。OOスクリプトは、2つの
アクタの間の単一処理の特定のテキスト表現である。各
OOスクリプトを使用して、1つ乃至2つのアクタを伴
う作用の1つの規則を記述するすることができる。しか
し、OOスクリプトのシンタックスでは、アクタの記述
ができない。OOスクリプトの表現は、先に定義した作
用規則に対する正式な表現の部類に属する。GRASの
実施において、(推論エンジンによって維持される)内
部の規則構造と利用者(または外部のアプリケーション
・システム)との間のインタフェースをとる単純なテキ
スト・フォーマットを与えるために、例えば、OOスク
リプトのタプル(一定数の要素の集合)が用いられる。 【0048】役割:アクタの役割は、所与の状況におい
てそのアクタに適用されるすべての作用規則の集合であ
る。1つのアクタに対する各作用規則は、他のアクタと
の相互作用を必要とするため、アクタの作用を動的に変
更することが可能である。 【0049】VSMにおけるテープ テープ・プログラム:テープ・プログラムには、アクタ
の初期(およびオプション)の集合と、スクリプト規則
の集合またはアクタ間の作用規則を定義する一般スクリ
プトとが入っている。テープ・プログラムは、その実行
に必要なすべてのアクタを備えている場合、アクタ妥当
(actor correct)であると言う。同様に
、テープ・プログラムは、その実行に必要な作用規則を
備えている場合、規則妥当であると言い、その実行に必
要なテープ・プログラムへの参照情報をすべて備えてい
る場合、サブテープ妥当という。テープ・プログラムに
は、その実行に必要なすべてのアクタおよびすべての規
則(または他のテープ)が掲げられている。スクリプト
規則または一般スクリプトを用いて初期のアクタを生成
することができるので、テープ・プログラムは、初期の
アクタの空集合を持つこともある。 【0050】テープ・シナリオ:テープ・プログラムの
実行によって、1つ以上のテープ・シナリオが演出され
る。テープ・シナリオは、シナリオの変形に対応する元
のテープ・プログラムからの所与の集合のスクリプト規
則の実行履歴である。 【0051】テープ:テープを構成するのは、未来のリ
ール、即ちテープ・プログラムおよび(1つ以上の実行
済みのテープ・シナリオからなる)過去のリールと言う
2つのリール、テープ・カウンタ、初期アクタのオプシ
ョン集合、その視覚化に必要なオプションの多重視野の
記述、および参照と参考情報の利用に使用される追加的
な情報である。未来のリールは、利用可能な作用の集合
を表し、過去のリールは、そのテープの実行の履歴を表
す。過去のリールには、前に使用された規則のインスタ
ンス、それらの規則に関与したアクタの履歴が入ってい
る。テープ・カウンタは、そのテープ(過去のリール)
において既に実行されたステップ数に対する模擬計数(
または回数)を示す。テープが完全に巻き戻されると、
過去のリールは空になる、つまり実行の履歴が失われ、
未来のリールには、それまで得たすべての規則の集合が
入る。 【0052】テープのクラス:テープのクラスによって
、ビデオ・テープまたはフィルムの編集の類似性に基づ
いて半自動(支援付き)プログラム操作をサポートする
のに必要な計算体および作用素のクラスが規定される。 【0053】テープ・シェルフ:テープ・シェルフは、
テープの集合である。 【0054】伸縮可能テープ:テープは、スーパー8ム
ービーのように編集、切断および張り合わせができるの
で、何本かのテープを1本にまとめ組み合わせるだけで
なく、スクリプトおよび作用を容易に変更することもで
きる。テープは、特定の通信について新たな情報や詳細
をさらに受信するために、録音中に自動的に延長される
。また、GRASシステムによって生成されたり利用者
の入力に応じた追加的なスクリプト規則を2つの既存の
ものの間に挿入する余地を与えるために、テープは自動
的に延長される。テープの実現により、いろいろな詳細
水準での多重(各テープは、多重トラックを有する)録
音がサポートされる。VSMでは、録音によって既存の
スクリプトがテープから消去されるのではなく、新たな
スクリプトが既存のスクリプトの間に挿入される。スク
リプトの削除は、切断またはスクリプト規則を削除する
ためのメニュー選択(コマンド)によって行われる。 【0055】テープの切断:テープの切断は、現在の位
置(シミュレートされた時刻)で起こり、それ自体で有
効な2つのテープを生成する。テープを切断するには、
フィルム・エディタを選択する。切断後、これらのテー
プは、共にテープ・シェルフに格納される。テープは、
切断される前にコピーが取られる。テープを切断すると
一方の側に未来のリールを追加し、他方の側に過去のリ
ールを追加することによって、自動的に修復された2つ
の半分のテープが作られ、2つの新たな実行可能なテー
プが出来る。利用者は、新たな2つのテープを指名する
ように促される。 【0056】テープの接合:テープの接合は、2つ以上
のテープを一続きのテープに継ぎ合わせる。テープを接
合するには、フィルム・エディタを選択する。テープは
接合される前にコピーされ、第1のテープの過去のリー
ルおよび第2のテープの過去のリールは、解かれないな
くてもよい。次ぎに、第1のテープの最後が、他方のテ
ープの先頭に接合され、この処理の間に、2つの余った
リールは消滅する。 【0057】利用者は、2つ以上のテープを一緒に接合
することができる。いくつかのテープを接合すると、そ
れらのテープの内部表現は同一でも、順次シミュレーシ
ョン・モードで映されるテープは連続実行となり、同時
シミュレーション・モードでは並列実行となる。 【0058】テープの照会:テープの照会により、アク
タおよび伝達情報の部分的な記述が記録されたテープが
参照される。部分的な記述は、事前条件、事後条件およ
びメッセージに対するオーディション表現およびパタン
・マッチング表現とすることができる。スクリプト構造
体についてのパタン・マッチングによって所与の集合の
スクリプト規則から同様の伝達情報を検索するために、
テープの照会によるアクタ間の通信が使用される。 【0059】内部テープ呼び出し:現在のテープを実行
しながら、テープ・シェルフから直接テープ(サブテー
プ)を呼び出すこと。呼び出しは、現在のテープにおけ
るスクリプト規則に対する事後条件が契機となる。そし
て、現在のソフトコーダ(SOFTCODER)の状況
下で実行されるテープのインスタンスが生成される。現
在使用されているアクタ・システムは、設計者の裁量で
サブテープによって再利用されることもあれば、されな
いこともある。そのサブテープが、呼び出しているテー
プで使用されているアクタを特に参照する場合、このア
クタは再利用される。再帰的なテープ呼び出しは、現在
のテープの特別な例であるか、またはそれ自体を呼び出
しているサブテープの特別な例である。 【0060】テープ・コンパイラ:これは、編集および
ウンドゥの可能な損害に対するさらに効率的な実行を与
えるテープを定義するシステム規則の集合に関する処理
機構である。結果は、コンパイル(編集)されたテープ
である。テープ・コンパイラは、アクタのグラフィック
表現、ならびにそのテープ内のアクタ間の通信および接
続のグラフィカルな副作用を除去することにより、より
効率的な実行を与えることができる。また、テープ・コ
ンパイラは、最適化のためにテープのスクリプト規則の
集合を修正し、高速実行のためにスクリプト規則の前計
算されたラチスを生成する。 【0061】ビジュアルな照会:これは、照会を定式化
してテープ・シェルフから情報を検索するために設計さ
れた対話的かつビジュアルな処理の集合である。同様の
機構は、標準のテープの録音に使用されるビジュアルな
照会を定式化するのにも、テープの照会が生成されたの
ちテープ・シェルフからのテープの一部に照合されると
言う点を除いて、使用される。テープ・シェルフに適用
される照会結果は、対のリストを伴ったテープの順序集
合である。各対は、候補との一致の信頼値である数およ
びテープ・プログラムにおけるその候補のある位置への
ポインタからなる。ビジュアルな照会の結果として、利
用者は、候補との一致が成功した位置の付近の各テープ
のグラフィカルなシミュレーションを調べることができ
る。これは、設計情報の検索および既存のものから新た
な設計を組み立てるのに役立つ。 【0062】VSMにおけるアクタ VSMにおいて、アクタは、劇および映画の制作の場合
と同様の概念を表す。バックステージにあるアクタの要
員の中からアクタを利用することができる。アクタは、
必要に応じて(新たに)生成したり、前に生成したアク
タの要員から得たりする。アクタは、生活(存在)し、
演じ(上演し)、そして死ぬ(破壊される)。さらに、
アクタは、コンピュータの実体であるから、それらの複
写、再利用、合併、分離、および置換が可能である。あ
るスクリプトに対してアクタを大まかに定義することが
できるが、この場合のオーディション処理(audit
)は、適切な特性のアクタを要員から選択するように行
われる。ユーザの視点からすれば、アクタは、知識を蓄
え、それを利用し、さらに計算を行う非常に柔軟性のあ
る作用主体として見えなければならない。 【0063】アクタは、ゼロ、または1つ以上のテープ
の構成員であり得る。テープには、そのテープのシミュ
レーションから得られるシナリオにおいて演じるすべて
のアクタのアドレスが表として掲げてある。このリスト
は時間で変化する。VSMでは、テープは元来、例から
作られている。例によって作用が構成されると言うこと
は、テープの録音中に、アクタの特定のインスタンスが
生成されて使用されることを意味する。 【0064】スクリプトの構造 GRASシステムにおける作用の規則を実施するために
使用されるデータ構造は、つぎのような形式である。S
address=(Type,Sid,Group−S
address,Pre−Saddress,Post
−Saddress,Sender,Sundo,Re
ceiver,Rundo,Precondition
s,Message and Arduments,P
ostconditions,Documentati
on).スクリプトの引数は、次のように定義される。 【0065】「Saddress」は、所与のプロセッ
サにおけるスクリプト構造体のアドレスである。スクリ
プト構造体がいくつかの独立したプロセッサ上に分散し
ている場合、Saddressは、プロセッサのアドレ
スを与える接頭語(例えば、SaddressをPro
cAddress:Saddressとする)を持つこ
とができる。 【0066】「Type」は、Rule(規則)、Ge
neral(一般)、Instance(インスタンス
)、Group(グループ)、Wait(待機)、Un
doable(アンドゥ不能)、Sent(送信済み)
、Precessed(処理済み)などのスクリプトの
型の合法的な組み合わせである。この型は、スクリプト
の型の記述に従ってスクリプト構造体を処理するために
、推論エンジンによって使用される。Rule、Gen
eralおよびInstanceの各型は、Group
型と共に組み合わせることができる。Instance
型およびWait型は、Undoable型と組み合わ
せることができる。Instance型は、Sent型
またはProcessed型と組み合わせることができ
る。 【0067】Sid:これは、他のスクリプト構造体に
おける記号(シンボル)による参照および利用者への記
号表現に使用される識別子である。 【0068】Group−Saddress:スクリプ
ト構造体がグループ型である場合、そのグループの構成
員であるスクリプト構造体の集合を参照するのに使用さ
れる。 【0069】Pre−SaddressおよびPost
−Saddress:これらは、他のスクリプト構造体
へのSaddress(複数)の構造体である。それは
、特定のアーキテクチャに対するGRASの働きを高め
る効率的な実行機構の設計を支援するために使用される
。例えば、スクリプト構造体SのPre−Saddre
ssは、Sの実行の直前のスクリプト構造体のアドレス
であり、Post−Saddressは、Sの実行に直
に続くスクリプト構造体を示す。これによって、スクリ
プト構造体のいくつもの大きな集合の実行を効率的に実
施したり破棄したりするためのラチス構造が与えられる
。 【0070】SenderおよびReceiver:こ
れらは、このスクリプト構造体におけるセンダのアクタ
およびレシーバのアクタを参照する表現である。そのス
クリプトの型によって、この表現は、異なって解釈され
る。 【0071】SundoおよびRundo:これらは、
スクリプト構造体の実行によってセンダのアクタおよび
レシーバのアクタに対しそれぞれ行われた変更をすべて
復元するために必要とされる処理の集合を記述する表現
である。SundoおよびRundoは、Rule型お
よびGeneral型のスクリプト構造体に対しては、
空である。 【0072】Precondition(事前条件):
事前条件の表現は、関数と、現在のシミュレーション時
刻におけるスクリプトのアクタの属性に関する論理検査
との組み合わせ(例えば、ブール表現)である。センダ
のアクタおよびレシーバのアクタに基づく事前条件によ
って設計を簡単にすることは許されるが、好ましい方法
は、センダのアクタに関する事前条件およびレシーバの
アクタに関する事前条件を分離することである。レシー
バについての情報にアクセスするためには、まずレシー
バに要求を送る必要があり、その応答の結果を次の規則
の事前条件において使用しなければならない。アクタの
集合がスクリプトを実行している各プロセッサ上では、
必要であればクロックが利用でき、そして、そうならば
、スクリプト構造体の有限な実行履歴が維持される。こ
れらの仮定の下で、事前条件に時間従属関係を含めるこ
とができるが、これは、時間作用素および他のスクリプ
ト構造体の実行時間を用いて形成されたタイミング表現
である。タイミング表現は、スクリプト構造体の実行を
(それらに特有のスクリプト識別子に基づいて)指示す
るのに使用される。GRASの実現においては、シミュ
レートされた時間の強制は、OOスクリプトの表記に基
づく。 【0073】Message and Argumen
ts(メッセージと引数):「Message」は、セ
ンダのアクタとレシーバのアクタとの間で渡されるオプ
ションのメッセージのシンボル名である。メッセージは
、アクタ間で情報を伝達するために使用される。引数が
指定されるとき、引数は、センダのアクタからのデータ
に基づいて、任意のデータの集合または計算式から成る
。 【0074】Postconditions(事後条件
):属性の初期値に施された計算に基づいて、さらにレ
シーバのアクタの場合は、計算されたりそのレシーバに
渡されたメッセージを介して転送されたりしたデータに
基づいて、アクタの属性に対して行われた変更が、事後
条件の表現によって記述される。Postcondit
ionsは、センダのアクタに対する事後条件表現とレ
シーバのアクタに対する事後条件表現とに分解する方が
好ましい。 Documentation:スクリプト構造体の機能
の解説に使用されるフィールドである。ドキュメンテー
ションには、そのスクリプト構造体の全アクタおよびそ
れらの属性およびデータへのシンボルによる参照情報を
含めることができる。ドキュメンテーションは、少なく
ともテキストによる記述であるが、実現方法によっては
、グラフィックス、ビデオおよびオーディオを使用して
も良い。 【0075】事前条件において検査されるか、事後条件
において変更されるアクタの属性により、アクタの間の
関係(センダのアクタとレシーバのアクタとの間の関係
)を表すことができる。さらに、外界と共に入出力関数
を実行する項目(例えば、利用者に質問することなど)
は、事前条件、メッセージおよび事後条件において受け
付けられるが、事後条件以外では受け付けないことを推
奨する。事前条件はすべて並列的に検査され、メッセー
ジの属性はすべて並列的に通信され、事後条件は、すべ
て並列的に実行される。このため、アクタには並列的な
通信モデルが強いられる。連続的な実行が望ましい場合
には、別個のスクリプトと連続したスクリプトグループ
が用いられる。 【0076】スクリプトの型 スクリプト規則:Rule型のスクリプト構造体は、例
示されたセンダのアクタおよびレシーバのアクタを持た
ないが、代わりに、シンボル名または1つのアクタ・ア
ドレスに評価される表現を用いてアクタを参照する。こ
れは、生成、再利用、または多くとも1つのアクタ・ア
ドレスに戻るアクタ処理によって、行うことができる。 スクリプト規則は、実行されるスクリプトではないので
、維持するべきアンドゥ情報がないため、空のSund
oフィールドおよびRundoフィールドを有する。 【0077】一般スクリプト:一般(General)
型のスクリプト構造体では、そのアクタを指定するため
にオーディション表現を用いる。センダとレシーバは、
アクタ・アドレス(センダ・アドレスおよびレシーバ・
アドレス)の対の集合を生成する2つのオーディション
表現を指定する。一般スクリプトは、空のSundoフ
ィールドおよびRundoフィールドを有する。 【0078】スクリプト・インスタンス:インスタンス
型のスクリプト構造体は、スクリプト規則または一般ス
クリプトの例示によって生じる。スクリプト規則の場合
、センダおよびレシーバがそれらのアドレスによって特
定されると、センダのアクタおよびレシーバのアクタが
それらのアドレスによって置き換えられる場合、スクリ
プト・インスタンスが生成される。一般スクリプトの場
合、アクタ・アドレスの各対に対応してスクリプト・イ
ンスタンスの集合が生成される。スクリプト・インスタ
ンスは、実行されると空でないSundoおよびRun
doフィールドを有する。これらのフィールドには、ス
クリプト・インスタンスを一度実行することの影響を元
に戻すために終えなければならない処理が記述されてい
る。 【0079】スクリプト・グループ:スクリプト構造体
の集合を直接参照するスクリプト構造体である。例えば
、オーディション処理が1つ以上のアクタ対(例えば、
通信放送)を返す場合、一般スクリプトはグループ・ス
クリプトに例えることができる。並列実行のため、スク
リプト・インスタンスも推論エンジン(ソフトコーダ(
SOFTCODER))によって自動的にグループ化さ
れる。 スクリプト規則の実行を同じプロセッサにさせるために
グループを定義することも可能である。例示されたスク
リプト・グループは、空でないSundoフィールドお
よびRundoフィールドを有する。 【0080】待機スクリプト:シミュレートされた時間
の期間中に実行を遅らせるためにソフトコーダによって
生成されるスクリプト構造体である。これは、シミュレ
ーション時間のある期間中に実行可能なスクリプトが無
いこともあり得るので、必要である。例えば、送信され
るメッセージは、受信され処理される前に数単位分のシ
ミュレートされた時間を要することがある。また、メッ
セージが受信されても、後まで処理できなかったりする
。 【0081】アンドゥ不能スクリプト:実行が終了しか
つ逆に実行される(元通りにされる)べき必要なSun
doおよびRundo表現を持つ待機スクリプトまたは
スクリプト・インスタンスである。Sundo表現また
はRundo表現により、スクリプト・インスタンスが
最初に実行されたシミュレーション時刻以降に変更され
たすべてのスロットおよび値が、対応するアクタのデー
タ空間から削除される。スクリプト・インスタンスが実
行される前に存在していたスロットおよび値は、これに
よって回復される。 【0082】GRASシステムの説明 図1は、GRASシステムの概念的構造図である。ビデ
オ・スタジオ・メタファ(VSM)インタフェース・モ
ジュール100は、単一統合メタファの下でのシステム
設計およびシミュレーションの環境全体に対する簡単な
ユーザ・インタフェースと直接アクセスとを提供するた
めのソフトウェア・モジュールである。VSMにより、
利用者は、ビジュアル・プログラミング技法を用いてシ
ステム作用の例をテープ・シナリオへと記録し、さらに
グラフィカルな動画的シミュレーションおよび実行をと
おして指定されたシステムの作用の視覚的フィードバッ
クを維持しながら、それらの例をテープ・プログラムへ
と組み合わせかつ洗練させることができる。利用者は、
VSMにおけるビデオ・コネクタおよび種々のエディタ
(フィルム・エディタ)の使用によって、設計案の補足
、通信、編集、および結合を行うことができる。 【0083】また、VSMモジュールは、このシステム
の利用者に対し必要な仕事を行うために、より低い水準
の適切なGRASモジュールを呼び出すことができる。 ビジュアル・オブジェクト網管理(MoVon=Man
agementof Visual Object N
etworks)モジュール(MOVON)110、ソ
フトウェア・ビデオ・レコーダ(ソフトコーダ)モジュ
ール(SOFTCODER)120、およびビデオ・コ
ネクタ(VC)モジュール(VC)130から成る次の
水準のモジュールは、利用者に対し透過的である。VS
Mインタフェースは、双方向メッセージ・リンク(11
1、121、および131)を介して、これらのモジュ
ールと通信を行う。 【0084】ビジュアル・オブジェクト網管理(MoV
on)は、システムの構成要素および構成要素網の視覚
化を多重表示、多重階層、および多重詳細水準でサポー
トするアクタの実現である。ビジュアル・オブジェクト
網管理モジュール(MOVON)110は、その関数を
実行するために、アクタ・フレーム・モジュール(AF
)140、およびプレスクリプト・モジュール(PRE
SCRIPT)160を要請する。 【0085】ソフトコーダ・モジュール(SOFTCO
DER)120は、アクタの処理および通信を記録し、
かつシミュレートまたは実行するビジュアルな機構であ
る。ソフトコーダ・モジュール120により、単一また
は複合の画面上の対話によって供給される指定事項を記
録(入力)、再生(実行)およびアンドゥ(逆向きの実
行)を行う一般的な機構が提供される。これらの対話は
、情報の転送および計算を伴うアクタ間の通信を表す。 ソフトコーダのビジュアルな機構は、アクタ間の作用の
規則を記述するテープ・プログラムを処理し、アクタお
よび規則を例示し、さらにこのシステムの実行の完全な
軌跡であるテープ・シナリオを生成する。テープ・プロ
グラムにおける各実行段階において、1組の処理が実行
される。各段階は、それをアウドゥすることによって逆
戻りすることができる。 【0086】また、ソフトコーダのビジュアルな機構は
、アクタの通信および状態の変化をとらえ、シュミレー
トする。ソフトコーダは、録音中に、メニューによる視
覚的な対話(アクタの処理の記録)をとおして利用者に
よって与えられる特定の例からソフトウェア区分を一般
的な作用規則へと自動的にコード化する。各作用規則は
、利用者からの入力と対話する専用のソフトウェア・ル
ーチン群によって対話的に洗練され(特殊効果)、別の
状態を記録する場合には、再利用および変更を容易に行
うことができる。 【0087】各段階の連続的な実行により、その例が、
入力されたとおりに再生される。その例によって記述さ
れた作用は、作用をすべて予め確かめられる状態で記述
するプログラムへと対話的に洗練される。作用のアクタ
および規則は、アクタの状態、通信中に実行された計算
および交わされた情報に関する他の情報を変更したり、
削除したり、あるいは追加したりするために、いつでも
編集することができる。利用者の裁量によって、アクタ
の状態およびグラフィカルな表現の変更は、永久的にも
一時的にもなる(反転可能)。結果的に得られる規則は
、実際にテープ・プログラムを形成する。 【0088】ビデオ・コネクタ・モジュール(VC)1
30は、利用者にプログラム対話、編集、ならびにファ
イル・システムおよびGRASの外部の他のシステムへ
の接続のための機構を利用者に提供する。モジュール1
30は、ソフトコーダによって使用される内部テープ表
現のための一般的な変換および通信の機構である。モジ
ュール130は、利用者による読み出しおよび編集、ま
たは外部システムとの通信のうち何れかが可能なテキス
ト形式でテープ、アクタおよびスクリプトを示すのに使
用される。モジュール130により、GRASとファイ
ル・システムとの間の双方向接続機構、およびGRAS
と外部システムとの間の双方向接続が提供される。提供
されるコネクタの例としては、OOスクリプト、メッセ
ージ、テープ、アクタ(オブジェクト)、スクリプト、
およびアイコンがある。ビデオ・コネクタを介して外部
のシステムに接続されると、外部のシステムは、GRA
Sの実行を遠隔制御できるだけでなく、GRASを調べ
ることができる。 【0089】プレスクリプトは、GRASの一部で、ア
クタおよび伝達情報の表示およびアニメーションのため
のグラフィカルなプログラミング言語である。プレスク
リプト・モジュール160は、アクタの視覚的な表現を
担う。アクタ(アクタ=視覚的なオブジェクト+フレー
ム+作用)を定義するために、視覚的なオブジェクトは
フレーム表現に関係付けられる。視覚的なオブジェクト
はコンピュータ端末上に表示される。視覚的なオブジェ
クトは、他の視覚的なオブジェクトと合併することがで
き、シナリオ(またはシナリオの集合)を定義するテー
プの構成員であるだけでなく、テープ・フレームの構成
員でもある。プレスクリプト・モジュール160は、O
S175によって与えられるウィンドウおよびグラフィ
ックの諸機能(WG)170を利用する。 【0090】アクタ・フレーム・モジュール(AF)1
40は、フレームおよびアクタの知識の時間的履歴を支
持する知識表現および記憶の機構である。アクタ・フレ
ームは、フレーム・オブジェクト言語および実行環境(
FOLIE)に基づく。FOLIEは、GRASシステ
ムの一部であり、フレーム・ベースの分離(分散)およ
び分散された部分集合からの合併によるフレーム・ベー
スの再構築、多数の階層およびローカル・クラス優先リ
スト、および多数の階層におけるメッセージの放送をサ
ポートするフレーム表現言語である。放送されたメッセ
ージが、方法、関数、手続き、またはコンパイルあるい
は変換された形式のラムダ表現への参照情報から成る場
合、それは、少なくとも1つの関数引数と共に、その階
層における現在のフレームと称する。ラムダ表現は、必
要な引数(例えば、現在のフレーム)と共にそれが呼び
出されると仮定した場合、その実行に必要なすべての環
境変数を備えた、独立型のコンピュータのコード・セグ
メントである。 【0091】GRASシステムにおいて、テープの実行
機構は、アクタの動的な属性に基づく。テープの編集処
理は、アクタの静的な属性と動的な属性との組み合わせ
に影響を与える。静的な編集の柔軟性は、アクタ・フレ
ーム・モジュール140の一部であるFOLIEモジュ
ールによってサポートされる。FOLIEモジュールは
、次の関数からなる。即ち、(1)シンボルによる自己
記述:伸長性で型指定が無く、フレーム集合のシンボル
による自己記述は順序依存的であり、フレーム間のすべ
ての依存関係は2重リンクを用いて自動的に維持され、
そのフレーム要素からのフレーム集合の定義は、任意の
順序で行うことができる。(2)多元的継承:フレーム
がそのすべての母体から性質の統一体(集合)を受け継
ぐことができる。(3)継承の多重階層性:フレームは
、AKO階層、PART−OF階層、またはその化の任
意の関係から、性質を継承することができる。 (4)所与の階層のフレームに対する母体の順序集合か
ら成るローカル・クラス優先リスト(LCPL):多重
階層性により、多数のLCPLがもたらされる。(5)
フレームの放送:所与の階層のすべてのローカル・クラ
ス優先構成員に作用素を放送(一斉送信)することがで
きる。(6)フレーム網の統合:他のフレームとの関係
のネットワークの内部でフレームが定義される。各フレ
ームは、自己記述的である、即ち、フレームは他のフレ
ームとの関係網をシンボル的に記述する。他のフレーム
がない場合でもフレームの統合が可能である。(7)フ
レーム網の合併:フレームのオブジェクトを共有する2
つのフレーム網は、同一のシステムの中でリンク(ロー
ド)されると、自動的に合併される。(8)再利用、結
合、上書きおよび忘却という4種類の合併の原型を備え
たフレームの合併。(9)フレームの転送:これにより
、フレーム網の一貫性を維持しながら、フレームを他の
フレームによって全体的に(グローバルに)置換するこ
とが可能となる。交換用のフレームが既に存在する場合
、転送は、合併によって行われる。この機能により、ア
クタの交換およびアクタの合併に対する支持が与えられ
る。 【0092】ウィンドウおよびグラフィックス・システ
ムのモジュール(WG)170(商業的に入手可能なX
Window SystemTM、SunViewT
M、シンボリックス(Symbolics)社のGEN
ERA(登録商標)のウィンドウと類似)により、GR
ASに視覚的な能力が与えられる。Common Li
sp(CL)180は、ANSI X3J13委員会(
準備中のCommon Lispのための全米規格)の
仕様に従うCommon Lisp言語を実現したもの
である。GRASでは、実行可能なサイズを小さくする
ために、CLのサブセットが用いられる。CLのサブセ
ットは、GRASを実行するのに必要なLisp関数の
みから成り、GRAS全体のコードを調べ、そのコード
において参照されたすべての関数を集めることによって
生成されている。その他のコンピュータ言語でも、AN
SI仕様による定義と類似の機能を与える限り、CLと
置き換えることができる。 【0093】オペレーティング・システム(OS)17
5は、コンピュータのオペレーティング・システムであ
り、(オプションにより)統合化された環境(例えば、
UNIX(登録商標)、シンボリックス社のGENER
A(登録商標))である。UNIXは、AT&Tの登録
商標である。GENERAは、シンボリックス社の登録
商標である。OSは、次の構成要素の実行の制御および
維持を行う。即ち、WG(170)、CL(180)、
FS(185)およびNW(186)である。 【0094】ファイル・システム(FS)185は、静
的なデータ記憶および検索のためのアクセス機構を実現
する構成要素である。これは、UNIXのファイル・シ
ステムを基にしている。 【0095】ハードウェア(HW)176は、データ(
シンボル、オブジェクト、データーベース)を操作し、
論理演算および算術計算を行う1つ以上のプロセッサ、
およびデータの記憶および検索に使用される1つ以上の
記憶用の機構および装置から成る(記憶装置は、静的な
ものや動的なものがあり、シーケンシャル・アクセスで
あったり、ランダム・アクセスであったりする)。 ハードウェアの必要条件は、ここで定義されるGRAS
のすべての構成要素の実行を支持するに十分なデータ記
憶装置および処理能力を与えることである。GRASの
実現および頒布のために適切であると分かった現在入手
可能なコンピュータ・ハードウェアには、次のものがあ
る。AT&Tの6386WGS、AT&Tのグラフィッ
クス端末またはX Window端末を付けた他のUN
IXコンピュータ・メインフレーム、サン・マイクロシ
ステムズのSun−3およびSun−4シリーズ、イン
テル80386ベースのパーソナル・コンピュータ、シ
ンボリックスの3600(登録商標)およびXLシリー
ズ、ゼロックス1100シリーズ、テキサス・インスツ
ルメンツExplorers(登録商標)、およびデジ
タル・エクイップメント・コーポレーションのDEC2
000および3000シリーズ。 【0096】(オプションの)ネットワーク(NW)1
86は、VSMベースのシステムの集合の間でデータ通
信を提供するために、HW構成要素と共に利用できるか
、またはそれに付け加えて利用できるハードウェアおよ
びソフトウェアの要素を備えている。現在利用可能で適
切なネットワーク技術には、モデム付きの電話回線、イ
ーサネット、AT&T STARLAN、広帯域パケッ
ト網がある。ネットワーク要素は、VSCデータを電気
的に伝達する(例えば、テープ・プログラムを離れた場
所で利用する)ために必要とされるに過ぎない。 【0097】図1に示したように、VSMモジュール1
00は、MOVON、ソフトコーダおよびVCへ双方向
の接続を持っている。(VSMからの)直接の接続は、
1)アクタおよびアクタ処理(MOVON)、2)スク
リプトおよびテープ・プログラムの視覚的な記録、洗練
、およびシミュレーション(ソフトコーダ)、ならびに
3)外部のテープ・プログラムだけでなくテキスト形式
のテープ・プログラムの編集(VC)、に対する利用者
の制御およびアクセスを表す。VCと外部のシステムと
の間に存在する(オプションの実行時の)双方向接続は
、図には表していない。(MOVON、ソフトコーダま
たはVCから)VSMへの接続は、ユーザ・インタフェ
ースの表示へのビジュアルなフィードバックおよびテキ
ストのフィードバックを意味し、表示画面上の1つ以上
の視覚表現に変化をもたらす。このフィードバック・ル
ープは、実際にはMOVON−PRESCRIPT−W
Gを通る共通経路によって実現され、すべてのグラフィ
カルな変化は、アクタの視覚的表現に対する変化として
実現される。また、VSMは、利用者によって制御され
る指示装置およびキーボード装置にWG経由で接続され
る。VSMモジュールは、図示されていない利用者から
直接の入力を受信する。同じ入力をVC遠隔制御機能に
よって外部のシステムから受信することも可能である。 ソフトコーダおよびVCは、スクリプト、テープ・プロ
グラム、およびテープ・シナリオのほか、ソフトコーダ
制御コマンド(例えば、テープのロード、テープの削除
、詳細水準の変更、ビューの変更など)も送信する。M
OVONおよびソフトコーダは、アクタおよびアクタの
内容を送る。MOVONは、PRESCRIPTにアク
タのビジュアル・オブジェクトを要求し、AFにアクタ
・フレームを要求することができる。VCは、FSおよ
び外部システムへの接続をCLおよびFSまたはNWを
介して要求することができる。PRESCRIPTは、
WGを介して表示の変更を求めることができ、CLを介
してプリスクリプト・オブジェクトの割り当てを(また
は再生をオプションで)要求することができる。 AFは、CLを介してフレーム、スクリプトおよびテー
プの構造体の割り当てを(または再生をオプションで)
要求することができる。CLは、OSおよびFSを介し
てHWにコンピュータ・オブジェクトの割り当ておよび
再生を要求することができる。 【0098】MOVON、ソフトコーダ、VC、および
概念構造のその他の構成要素の間の接続をさらに説明す
るために、VSMの言語を使用することができる。テー
プ・プログラムをビデオ店から借りると(VSMによる
利用者の要求)、VCは、CLを介してFSまたはNW
への接続を開き、ソフトコーダは、その開かれた接続か
らの入力をテープ・シェルフ(VSM)の上に置かれた
テープ・プログラムへと記録する。テープがソフトコー
ダにロードされる(VSMコマンド)と、ソフトコーダ
は、アクタを要求し、MOVONからのビューを表示し
た後、ソフトコーダは、適切な実行アルゴリズムを呼び
出す。ソフトコーダがそのテープ・プログラムからスク
リプトを実行するにともない、1)AFによって時間的
履歴において制御され、かつ2)MOVON−PRES
CRIPT−WGを介してアクタの視覚的表現(例えば
、アニメーション)に影響を及ぼし得るアクタに変更が
指示される。変更、または実行選択肢を試行のために利
用者が実行を休止すると、変更が、スクリプトの変更お
よびアクタの変更に翻訳されてMOVONおよびAFに
伝えられ、そこにおいて、それらの変化は一時的または
永久に組み込まれる。アクタおよびスクリプトに対する
変更は、ソフトコーダがそれらの変更を実施し、それら
をMOVONを介して伝達すると、直ちに見ることがで
きる。 【0099】ビデオ・スタジオ・メタファにおいて、例
としてのシナリオが対話的にテープに記録される。シナ
リオ例は、既存のシステムまたは設計予定のシステムに
対する一連の作用を指定するために使用される。新たな
条件に対するシステムの作用の新しい面を取り入れ、す
べての許容可能な条件のためにテープ・プログラムへと
発展させるために、テープ・シナリオが対話的に洗練さ
れる。十分に洗練した後、テープ・プログラムにより、
表されたシステムまたは設計中のシステムの完全なシミ
ュレーションが与えられる。テープ(シナリオまたはプ
ログラム)には、アクタの集合、アクタ間の作用および
通信を記述する規則の集合が入る。アクタは、規則の実
行によって駆動される通信活動および処理活動に関与す
る処理主体である。アクタは、規則の実行に使用される
独立した知識ベースを備えている。規則は、アクタの知
識ベースに関する事前条件、アクタ間の通信、および通
信とアクタの知識ベースへの表明とからなる事後処理を
含んでいる。 【0100】アクタ・フレーム・モジュールフレームの
概念構造により、利用者は、「ロード」および「接合」
により2つの独立したテープを統合することができる。 アクタおよび規則を共有する2つのテープは、それらを
1つの環境にロードし、テープの接合および編集を適用
することによって統合することができる。役割および関
数を共有してもアクタの識別情報が一致しない2つのテ
ープは、アクタの移転(アクタの交換を選択する)およ
び前記のステップを実行することによって、合併するこ
とができる。同じ特徴の仕様を持つ断片部品を組み立て
てみれば、前記のような環境に統合のための独特なコン
ピュータ支援があることが分かる。 【0101】テープの編集および合併に付いての柔軟性
は、フレーム表現言語(FOLIE)、ビジュアル・オ
ブジェクト網管理(MOVON)、およびアクタの規則
に基ずく作用の定義に用いられる基礎的なスクリプト言
語(例えば、OOスクリプト)と言う3つの要素の統合
からくるものである。フレームの合併により、テープお
よび(または)アクタのスロット、値および関係(例え
ば、継承、構成員関係)の合併がサポートされる。フレ
ームまたはそれらの関係の集合が、ノードがフレームを
表し弧が関係を表すようなグラフによって表される場合
、そのような2つのフレーム集合を合併することは、か
くグラフのノードを合併し、合併したグラフのノード間
で弧を(合併の型に応じて)追加したり削除したりする
ことによって、それらのグラフを構成するに等しい。 アクタの交換処理は、オブジェクト指向言語における「
become」の拡張として見ることができるが、これ
を用いて、あるアクタを他のものに替えたり、交換先が
既存のアクタである場合には、2つのアクタを合併した
りすることが可能である。ビジュアル・オブジェクトの
合併により、システムの構成要素の統合、即ち、スロッ
ト値、さらにグラフィックスの属性として定義される状
態の合併がサポートされる。規則に基づくテープ・プロ
グラムの実行は、規則集合の結合を行うことにより種々
のテープからアクタの作用の統合をサポートする。標準
のプログラミング言語における関数、オブジェクト、ま
たは命令の集合の結合によるプログラムの結合によって
、通常は、有用なまたは有意義な結果を生じることはな
い。なぜなら、プログラムの各命令の実行は、他の周囲
のプログラム命令によって定義される外部の暗黙の制御
フローによって条件付けられるからである。しかし、ス
クリプト規則、一般スクリプトおよび関係するアクタの
集合結合によるテープ・プログラムの結合は、結合され
ているテープからの機能性の追加を、次のような少なく
とも2つの利点を伴って、もたらし得る。第1に、テー
プ・プログラムの各「命令」は、アクタまたはアクタの
記述、実行条件および結果としての処理および通信(メ
ッセージ)から成るスクリプト規則または一般スクリプ
トであり、従って、自立したプログラム命令である。第
2に、結合されている異なるテープ・プログラムからの
2つのスクリプト規則が、一致しない場合、この矛盾は
、明確に定義されている型であり、1)それらの規則が
意味論的に矛盾するか、2)両方の規則が同一のアクタ
・スロットを同時に更新しようとする状態が存在するか
、または3)1つ以上の規則が到達不可能であるかの何
れかである。最初の2つの矛盾の場合は、結合されたテ
ープ・プログラムの実行のアニメーションまたはシミュ
レーションの間に視覚的に現れる。第2および第3の矛
盾の場合も、結合された規則集合の静的な分析を用いて
検出することができる。 【0102】GRASにおいて、FOLIE、MOVO
N、および内部のスクリプト構造体(例えば、OOスク
リプト)を結合する根元的な知識表現は、上述の合併処
理(規則集合の結合によるフレーム・グラフの合併およ
び作用の統合)に内部的に基づく仕様の独特な柔軟性を
備えている。 【0103】VSMのためのデータの記憶および検索を
サポートする基本的な知識表現は、GRASのアクタ・
フレーム要素によって与えられる。AFは、アクタ間の
通信スクリプトの可逆的な実行のために必要な時間履歴
機構を提供するもので、根元的なフレーム表現言語FO
LIEの上に構築されている。AFにより、アクタへの
通信またはアクタからの通信によりフレームの属性また
は関係が変化する度にそのアクタ・フレームのローカル
・スナップ・ショットを記録しておくことにより、(前
に形式化された)アクタに必要な時間履歴機構が与えら
れる。この時間履歴の他に、GRASの実現に必要とさ
れるAFのすべての特徴は、FOLIEの直接的な特徴
である。 【0104】VSMにおけるテープの実行機構は、アク
タの動的な属性の記録および復活(読み出し)に基づく
。前記のテープ編集処理は、アクタの動的な属性と静的
な属性との組み合わせに影響を及ぼす。変更および編集
の実施は、根底にあるフレーム表現言語FOLIEによ
って直接サポートされる。動的な変更の実施は、FOL
IEの特性とアクタに関連したフレームの属性のスナッ
プ・ショットを記録・復活できる履歴機構との組み合わ
せによって与えられる。アクタの静的属性および動的属
性に関して必要な処理をサポートするFOLIEフレー
ム言語の重要な特徴を以下に述べる。 【0105】シンボリック自己記述:フレームは、それ
が定義されているコンピュータ環境とは独立したシンボ
ルによる記述フォーマットを用いて「それ自体をプリン
トする」ことができる。自己記述フォーマットは伸縮性
があり、フレームが変化すると、その変化を取り込むた
めに、同じフォーマットが、延長されたり短縮された形
式で使用される。コンピュータに依存できるフォーマッ
トならば型の特殊性はない。フレーム集合のシンボルに
よる自己記述は、順序に依存しない。フレームの集合{
f1,f2,...,fn}が与えられた場合、このフ
レーム集合の自己記述を任意の順序で記録し、同等のフ
レーム集合を生成するために、GRASシステムの別の
場合に異なる順序でそれらを復活させることが可能であ
る。 【0106】2重リンク:フレーム間のすべての関係は
、2重リンクを用いて維持され、2重リンクの半分を記
録することは、2重リンクの全体を記録すること同じで
ある。この性質により、フレーム集合の自己記述の順序
独立性がサポートされる。 【0107】フレーム網:フレームは、他のフレームと
の関係のネットワークと解釈することができる。各フレ
ームは、他のフレームとの関係網をシンボルによって記
述し、他のフレームが無くなると、フレームの統合が可
能となる。従って、フレームの不完全なネットワークを
記録・復活しても差し支えない。それがフレームの集合
F={f1,f2,...,fn}である。ここで、F
の要素fiは、Fの要素でないfjを参照する。 【0108】継承の多重階層:フレームは、所与のフレ
ーム階層におけるすべての母体から属性と関係の統一体
(集合)を継承することができる。多重継承は、他のフ
レーム言語およびオブジェクト指向言語についても一般
に利用可能であるが、多重階層による多重継承は、FO
LIEの新奇な特徴である。フレームは、AKO階層、
PART−OF階層、またはGRASにおいて定義され
たその他の関係から、特性を継承する。それぞれの双対
関係によって、それ自体のフレームの階層が定義される
。 【0109】ローカル・クラス優先リスト(LCPL)
:これによって、所与の階層におけるフレームに対する
母体の順序集合が構成される。多重階層によって多数の
LCPLに備えている。 【0110】フレームの放送:作用素または関数を放送
して、それを所与の階層におけるLCPLのすべての要
素に適用することができる。 【0111】フレームの合併:これは、フレームに格納
された情報の結合および再利用するための機構である。 4つの基本的な合併の原型、即ち再利用、結合、上書き
、および忘却によって、いくつかのフレームを合併する
ことができる。2つのフレームf1およびf2を合併し
て、フレームf(1+2)を構成する場合、以下のとお
りである。 1)再利用:f(1+2)は、f1に優先してf1およ
びf2から継承する。f1の属性および関係が残り、f
2からの重複しない属性と関係が追加される。 2)結合:f(1+2)は、f1およびf2から同等に
継承する。f1およびf2からの属性および関係が、統
一集合としてf(1+2)に格納される。 3)上書き:f(1+2)は、f2に優先してf1およ
びf2から継承する。これは、f2とf1との間の再利
用を伴った合併と同じである。 4)忘却:f(1+2)=f2 合併されたフレーム
は、元のフレームf2によって置き換えられる。 【0112】フレームの転送:これは、フレーム網の一
貫性を維持しながらフレームをもう1つのフレームで全
体的に置き換えることにより、現存の2重リンクを維持
することに備えるものである。交換フレームが既に存在
する場合、転送は、合併によって行われる。この特徴に
より、アクタの交換、先に述べたクローン生成および合
併が直接サポートされる。 【0113】フレーム網の合併:共通のフレームを共有
する2つのフレーム網は、同一のVSMベースのシステ
ムにおいて復活されると、自動的に合併される。 【0114】GRASにおけるテープの編集および合併
に付いての柔軟性は、概念構造の次の3つの主な構成要
素の間の相互作用から生じるものである。即ち、時間履
歴を統合したフレーム表現言語(AFおよびFOLIE
)、ビジュアル・オブジェクト網管理(MOVON)、
およびアクタの規則に基ずく作用を表すのに用いられる
スクリプト構造体の根底にある特性(ソフトコーダ)で
ある。次の例により、これらのソフトウェア構成要素の
統合を説明する。 【0115】1)フレームの合併により、テープ、アク
タおよび関係(例えば、継承、構成員、副構成要素)の
静的または動的な合併がサポートされる。各グラフが、
アクタの作用を記述するスクリプト構造体にテープ結合
され、アクタに結合され、副構成要素のアクタへと結合
されると言うような場合、この型の合併は、グラフの合
併に等しい。 【0116】2)一般的なアクタ交換処理によって、ア
クタを新しいものと交換したり、2つ以上の既存のアク
タを合併できる。これはアクタの交換、クローン生成を
可能とし、新たな設計構成要素についての利用者の実験
をサポートする。 【0117】3)ビジュアル・オブジェクトの合併は、
システムの構成要素およびそれらのグラフィック表現の
統合をサポートし、交換、クローン生成、または合併が
発生した場合に利用者に対して直接的かつ視覚的なフィ
ードバックを与える。 4)スクリプト構造体およびソフトコーダによるそれら
の実行によって与えられるようなアクタの間の規則ベー
スの通信によって、規則集合の統一を行うことによる多
数のテープ・プログラムからの特徴および構成要素の統
合がサポートされる。 【0118】GRASにおいては、AF、MOVON、
およびソフトコーダを結合する根元的な知識表現によっ
て、システム設計に関する使用および実験の新奇な柔軟
性が提供される。既存の設計と新たな設計のシミュレー
ション、結合および分析を非常にとりつき易くユーザ・
フレンドリに行うことが可能である。使用の柔軟性は、
AF、MOVON、およびソフトコーダと言うGRAS
概念構造の3つの基本的な構成要素の統合によって与え
られる作用規則の合併および統合のような処理に対する
独自の半自動化された支援の結果である。 【0119】FOLIE 次に、フレーム・オブジェクト言語および実行環境(F
OLIE)を説明する。明確になるよう、FOLIEを
定義するために、ここではCommon Lisp(1
984年デジタル・プレス社刊のG.L.スチール(S
teele)二世による「CommonLisp ザ・
言語(Common Lisp the Langua
ge)」)を改良したLisp風のシンタックス(構文
法)を用い、いくつかの例を掲げる。ここで定義するF
OLIE作用素は、Common LispおよびCo
mmon Lispオブジェクト・システム仕様(CL
OS)(1987年D.ボブロウ(Bobrow)によ
るゼロックス・ドキュメント87−002「CLOS」
、および在ニュー・ヨークのアヂソン・ウェスレイ(A
ddison Wesley)社1989年刊のS.E
.キーネ(Keene)による「Common Lis
pによるオブジェクト指向プログラミング CLOS
へのプログラマーズ・ガイド(Object−Orie
nted Programming in Commo
n Lisp, A Programmer’s Gu
ide to CLOS)」)に類似した命名規約によ
って命名する。FOLIEにおけるローカル・クラス優
先リストの定義は、CLOSにおけるクラス優先リスト
の定義から行われたものである。 【0120】1)表記および定義 FUN1(ARG1 ARG2)を2つの引数ARG
1およびARG2の関数であるFUN1の宣言とする。 「&optional」はオプションの引数を宣言し、
「&rest」は関数の残りのすべての引数の集まりを
宣言するものとする。「&optional(DEPT
H 0)」は、デフォルト値0を有するDEPTHと
命名されたオプションの引数に対する宣言であるとする
。 (FUN1 ARG1 ARG2)は、引数ARG
1およびARG2を付けた関数FUN1の呼び出しを表
す関数コール表現とする。引数は、埋め込まれた関数コ
ールを表して、それ自体が関数コール表現となり得る。 ::=は、「結合」記号とする。従って、VAR::=
(FUN1 ARG1ARG2)は、VARが、その
関数コールの結果に結合されることを示す。=は、「定
義により等号」とする。−>は、「戻り値」の記号とす
る。例えば、V1::=123ならば、V1−>123
である。Fは、唯一のLispオブジェクト(例えば、
ある記号)によって識別される任意のフレーム・オブジ
ェクトとする。FBは、任意のフレーム・ベースである
ものとする。ただし、FBは、フレーム・オブジェクト
の集合からなる構造体である。MFB(マルチプル・フ
レーム・ベース)は、FOLIEで定義された一般型(
一般のクラス)のフレーム・ベース・オブジェクトであ
るものとする。NXは、n個のスロット列NX=(X1
X2...Xn)であり、X=XiはNXにおけるス
ロットであり、BNXiはXiより前のNXの部分数列
であり、ANBiはXiより後のNXの部分数列である
ものとする(ANXiまたはBNXiまたは両者は、空
の数列()である可能性もある)。従って、NX=BN
Xi|(Xi)|ANXiとなる。ただし、|は数列の
連結を表す。 【0121】2)フレーム・ベースの生成MFB(&r
est F−set) これは、Fフレーム・オブジ
ェクトの集まりである簡単なフレーム・ベースを生成す
る。 例:(MFB F1 F2 F3)−>(F1...F
2...F3...) これは、そのフレーム・ベー
スがF1、F2およびF3を含むことを示す。 【0122】3)多数のフレーム・ベースの生成MAK
E−MFB(&optional FB F NX−s
et(MERGE−TYPE:COMBINE))
これは、フレームおよびフレーム・ベースの生成および
合併である。ここで、引数はすべてオプションであり、
NX−setは集合NX(一連のNX)であり、MER
GE−TYPEは以前に定義したような(:REUSE
:COMBINE:OVERWRITE)のうちの1つ
であり、MERGE−TYPEのデフォルト値は:CO
MBINEである。 例:FB::=(MAKE−MFB) これは、空の
フレーム・ベースを生成する。(MAKE−MFB F
B F) これは、フレーム・ベースFBに空のフレ
ームFを追加する。(MAKE−MFB FB F (
NX1...NXp)) これは、スロット列(NX
1...NXp)の集合を備えたフレームFをFBに追
加する。Fが既にFBの要素である場合、(NX1..
.NXp)は、既存のフレームFとの結合によって合併
される。(MAKE−MFB FB F (NX’1.
..NX’p):FORGET) これは、フレーム
Fの既存の定義を新しいもので置き換える。 【0123】4)アクセサとアサータ GETMFB(&OPTIONAL FB F &re
st NX)は、FBにおけるフレームFのNXスロッ
トの記述にアクセスする。GETMFB(&OPTIO
NAL FB F &rest NX)::=VALU
Eは、フレームFに対するNX位置においてVALUE
を加える。値として空の数列()を加えることは、Fに
おける位置NXにおける現在の値フレームを削除するこ
とと同じである。GETMFBの値として真のフレーム
文Tを加えることは、FにおけるNXを表明することに
等しい。なお、VALUEが()でない場合、所与の値
(値フレーム)を含むローカル・フレームを生成するこ
とによってVALUEがFに加えられること、ならびに
値の「追加」は合併によって行われることに注意を要す
る。従って、FOLIEにおいては、フレーム・ベース
は、その各副構成要素がフレーム・ベースであるという
点で、多重フレーム・ベースである。{(GETMFB
FB F X1...Xn)::=T}=(MAKE
−MFB FB F (X1...Xn))であること
に注意を要する。 【0124】例:(GETMFB FB F X1 X
2)::=VALUE12である場合:(GETMFB
FB F X1 X2)−>(VALUE12...
)は、値VALUE12を含みそして恐らくはその他の
前の値をも含むような値フレームが、FBのフレームF
におけるスロット位置(X1 X2)に存在することを
示す。(GETMFB FB F X1 X2 VAL
UE12)−>(T)は、スロット位置(X1 X2
VALUE12)に真の値フレーム(空でないフレーム
)が存在することを示す。(GETMFB FB F
X1)−>(X2(VALUE12...)...)は
、VALUE12を含む値フレームが位置(X2)に入
っている値フレームが、フレームFにおけるスロット位
置(X1)に存在することを示す。 (GETMFB FB F X1 X2)=(GETM
FB(GETMFB FB F X1)X2)(GET
MFB FB F X1 X2)=(GETMFB(G
ETMFB(GETMFB FB)F)X1)X2) (GETMFB FB F X1 X2)::=NEW
VALUE(GETMFB FB F X1 X2)−
>(NEWVALUE...VALUE12...)は
、両方の値が今やFにおける位置(X1 X2)の値
フレームの要素であることを示す。 (GETMFB FB F X1 X2 VALUE1
2)::=0(GETMFB FB F X1 X2)
−>(NEWVALUE...)は、VALUE12が
Fにおける位置(X1 X2)の値フレームの要素で
ないことを示す。 (GETMFB FB F X1 X2 VALUE1
2)−>0【0125】5)多重アサータ フレーム、またはGETMFBのスロット引数のうちの
1つが、それ自体フレーム・ベースであり、表明に対し
てGETMFBが呼び出された場合、その表明は、多重
化され、そのフレーム・ベース引数のすべての要素に分
配される。 【0126】例:X::=(MFB A B C)−>
(A...B...C...)とし、NX=BNX|(
X)|ANXである場合:{(GETMFB FB F
NX)::=Y}={(GETMFB FB F|B
NX|(A)|ANX|かつ(GETMFB FB F
|BNX|(B)|ANX|かつ(GETMFB F
B F |BNX|(C)|ANX|)} (GETMFB FB F |NX|)::=()は、
これらすべての表明を削除する。特に:(GETMFB
FB FB |NX)::=Tは、フレーム・ベース
FBのすべてのフレーム要素にNXを表明する。 (GETMFB FB FB)=(GETMFB FB
)かつ(GETMFB FB FB)::=()は、F
Bのすべての要素からすべての事実を削除する。 【0127】6)関係アクセサおよび関係アサータフレ
ーム・オブジェクト間の記号関係を指定するために、ス
ロット列NXを使用することができる。特に、FOLI
Eにおいては次のような構文法を用いて多重スロット列
を用いて、双対関係を定義することが可能である。即ち
、:>を「前方」リンク記号とし、:<を「後方」リン
ク記号とすると、(GETMFB FB A :> B
)::=Tは、フレーム・ベースFBのフレームAとフ
レームBとの間の双対関係を表明する。FOLIEで定
義されるフレーム・オブジェクトに関するすべての処理
において、以下に定義される同等関係を実施することに
より関係の双対性が維持される。FBを現在のフレーム
・ベースとする。フレーム・ベースFBにおいて表明N
Xが真であることを示すために、(GETFMBFB
NX)::=Tを短縮形[NX]=X1 X2...X
nで表すものとする。<=>を同値記号とする。要素と
してA、BおよびCを含むフレーム・ベース(MFB
A B C)を短縮形(A B C)によっ
て表すものとする。すると、FOLIEにおける関係に
ついての次の表明は真である。 a)直接関係同値 A:>B<=>B:<A b)多対1関係の分配性 (A B):>C<=>{A:>C かつ A:>C}
c)sink関係の分配性 FB:>OMEGA<=>FBのすべてのFに対し{F
:>OMEGA}d)1対多関係の分配性 A:>(B C)<=>{A:>B かつ A:>C}
e)トポロジー関係の分配性 ALPHA:>FB<=>FBのすべてのFに対し{A
LPHA:>F}f)N項関係の同値 A X1 X2...Xn:>Z <=> Z X1
X2...Xn:<Aさらに、前記のa)からe)まで
の表明は、N項関係に対しても同様に真である。 【0128】例: (A B C) CONNECT
SATELLITE :> VEGA<=>{A CO
NNECT SATELLITE :> VEGAかつ
B CONNECT SATELLITE :> V
EGAかつ C CONNECT SATELLITE
:> VEGA}<=>{VEGA CONNECT
SATELLITE :< Aかつ VEGA CO
NNECT SATELLITE :< Bかつ VE
GA CONNECT SATELLITE :< C
}【0129】7)作用素の設定 FBが、次の処理を行う間にすべての双対関係を表明す
るために「ルート」として使用される現在のフレーム・
ベースであるとする。MFB−MERGE(TYPE
FB1 &rest FB−set) これは、(:
REUSE:COMBINE:OVERWRITE:F
ORGET)の一要素であるTYPEにしたがって、フ
レーム・ベースの集合BF−setをFB1へと合併す
る(FB1を変更する)。MFB−INTERSECT
ION(FB1 &rest FB−set) FB
1を、それ自体(その表明)とフレーム・ベースの集合
(からのすべての表明)との交事象(積集合)にする。 MFB−DIFF(FB1 &rest FB−set
) フレーム・ベース集合からのすべての表明をFB
1から削除する。MFB−TRANSFER(FB1
FB2)=MFB−MERGE(:REUSE FB2
FB1) FB2において全く相似を持たないFB
1からのすべての表明を加えてFB2とすることに相当
する合併の使用。MFB−UNION(FB1 &re
st FB−set)=MFB−MERGE(:COM
BINE FB1 &rest FB=set) フ
レーム・ベースの集合からのすべての表明の集合統一に
相当する合併の使用。MFB−REPLACE(FB1
FB2)=MFB−MERGE(:FORGET F
B2 FB1) FB2をフレーム・ベースにあるF
B1によって置き換えることに相当する合併の使用。M
FB−XOR(FB1 &restFB−set)
FB1とFB−setにおける各フレーム・ベースとの
両者に対して対をなして真でない表明の集合となるよう
に、FB1を変更する。 【0130】8)叙述子(Precidate)MFB
−INCLUDE−P(&rest FB−set)
これは、FB−setが包含関係に対する順序集合で
ある場合、真となる。例えば、(MFB−INCLUD
E−P FB1 FB2)ー>Tは、FB1がFB2の
サブフレーム・ベースに等しく、FB1において真であ
るすべての表明はFB2においても真であると言うこと
を意味する。MFB−MINIMAL−P(FB)
FBについて真であるような表明が存在しないならば、
真となる。例えば、(MFB−MINIMAL−P(M
AKE−MFB))−>Tである。MFB−EQUAL
(FB1 FB2 &optional DEPTH)
(MFB−INCLUDE−P FB1 FB2)
および(MFB−INCLUDE−P FB2 FB1
)が共に真の場合、真となる。 【0131】注意事項:ある種の処理の効率のために、
ここと以下においてオプションの引数DEPTHを使用
する。()というデフォルトのDEPTHは、フレーム
・ベース全体が検討されることを示す。0というデフォ
ルトのDEPTHは、フレーム・ベースの第1の水準が
検討されることを示す。DEPTHが数である場合、そ
の数は、検討されるスロット列NXの最大サイズから1
を引いた数を示す。 【0132】9)ユーティリティ MFB−COPY(FB &optional DEP
TH) FBのコピーを作る。 MFB−CLOSE(FB &rest FB−set
) FB−setのフレーム・ベースに対するすべて
の双対リンクを(閉じられる各双対リンクへの参照とし
てFBを用いて)閉じる。MFB−PRINT(SUB
FB &optional STREAM DEPTH
) フレーム・ベースSUBFBのシンボル表現を与
える。SUBFBは、フレーム・ベースFBの部分集合
でもFB全体でも良い。STREAMが指定されていれ
ば、それが、SUBFBを対応するSTREAM装置に
印刷するために、使用される。MFB−READ(FB
&optional STREAM DEPTH)
STREAMからフレーム・ベースの集合のシンボル
表現を読み、結果としてのフレーム・ベースをFBへと
合併する。 【0133】10)マッパー MAP−MFB(FCN FB &optional
(DEPTH 0)) FBのすべてのスロットと値
とに対し関数定義FCNをDEPTHまで適用する。M
AP−MFB−SLOT(FCN FB &optio
nal (DEPTH 0)) FBのすべてのスロ
ットに対し関数定義FCNをDEPTHまで適用する。 MAP−MFB−VALUE(FCN FB &opt
ional (DEPTH 0)) FBのすべての
値に対し関数定義FCNをDEPTHまで適用する。 【0134】11)ローカル・クラス優先リスト(LC
PL) LCPLに用いられる定義は、CLOS仕様(Comm
on Lispオブジェクト仕様)から生まれたもので
ある。CLOSではCPLが単一継承分の階層に対して
定義されるのに対し、FOLIEでは、(NXによって
定義される)N項関係によって指定される任意の階層に
対してLCPLが定義される。 【0135】MFB−LCPL(FB F NX &o
ptional DEPTH) NXによって指定さ
れる階層関係に局限されたFB内のFのクラス優先階層
を構成するフレーム・オブジェクトの順序集合を返す。 【0136】例:FBが、以下の(短縮形の)表明が真
であるようなフレーム・ベースであるとする。 この場合、関係(B C)に関しFBにおけるAに対す
るローカル・クラス優先リストは、(MFB−LCPL
FB A (A B))−>(A D D1 E E
1 Z)である。関係(B C)に対しAの継承された
属性を探す場合、この属性に対する(A D D1E
E1 Z)を連続的に見る。継承された属性の探査は、
以下で定義するMFB−BROADCASTを用いて行
われる。 【0137】12)関数の放送 MFB−BROADCAST(FCN FB F NX
&optionalDEPTH) フレーム・オブ
ジェクトFおよびフレーム・ベースにおけるNXによっ
て定義される階層においてFに先行するすべてのオブジ
ェクトに対し関数定義FCNを適用する。MFB−BR
OADCAST−COLLECT(FCN FB F
NX &optional DEPTH) MFB−
BROADCASTに似ているが、その階層におけるF
のすべての先行例に対するFCNの適用結果を収集する
。 【0138】プレスクリプト GRAS風の対話的アクタと規則ベースの環境における
システム作用のビジュアル・プログラミングと対話的・
動的かつ柔軟性のある編集は、ビジュアル・オブジェク
トの定義によって可能となる。アクタ・フレーム構造体
は、GRASにおけるアクタの視覚的表現を実現するた
めに、オプションでビジュアル・オブジェクトによって
拡大することができる。つまり、Actor = D(
A,t)= Base−Frame+ {Visual
Object} + {Beheavor}であり、
このアクタは、時刻tにおけるデータ空間の記述D(A
,t)によって完全に指定される。しかし、データ空間
の記述は、ビジュアル・オブジェクト成分、基本フレー
ム記述、および現在時刻における可能な作用の継承され
た(恐らくは空の)集合を引き出し得る元の作用指定子
の集合に分解することができる。 【0139】ビジュアル・オブジェクトは、自己表示お
よび自己記述を行い、他のビジュアル・オブジェクトと
合併することが可能であり、さらに種々の視覚的表現(
例えば、アイコン、テキスト、ボタン、幾何学的な形、
グラフィックスの原形の組み合わせ)を持つことが可能
である。さらに、アクタに関係付けられたビジュアル・
オブジェクトは、テープの直接の構成員であり得る。そ
のビジュアル・オブジェクトに対応するフレームも、そ
のテープ・フレームに連結される。従って、1つのアク
タは、それが使用されるテープの各インスタンスについ
て2つのリンクを持つことができる。即ち、そのテープ
とそのビジュアル・オブジェクトとの間のリンク、およ
びそのフレーム記述とそのテープに関係付けられたフレ
ーム記述との間の双方向リンクである。 【0140】ビジュアル・オブジェクト表現の基礎とな
るのは、プレスクリプト(PreScript)グラフ
ィックス言語である。プリスクリプトでは、プリスクリ
プトのインタープリタ、コンパイラおよびデバッガのほ
か、接頭語表記およびLisp風の構文法も使用される
。プリスクリプトは、指示装置(例えば、マウス、カー
ソル)および利用者の入力をとらえ出力機構を与える機
構の定義を含めるために拡張された2次元、3次元また
はそれ以上の次元のベクトル空間代数を直接的に実現し
たものである。 【0141】プリスクリプトの実現には、ベクトル、ノ
ルム、距離、ベクトル演算(スカラー積、加算、減算、
ベクトル積)、直交性、平行性、点、線、平面、超平面
、射影、配景、原始的幾何学的対象(線分、線筋、2次
曲線、多角形、平行6面体、円柱、曲面モデル)、空間
位置の原形(内側、外側、交わり、合併、要素関係、隠
れた曲面)、線形変換およびアフィン変換、相似(回転
、移動、尺度構成、点対象および面対象)に対する定義
が含まれる。また、プレスクリプトのグラフィックス言
語には、表示装置、多数の視点、きめ、色、字体(フォ
ント)、テキストおよび座標の入出力装置、イメージ(
グラフィック要素の配列)、タイル、グラフィカルな周
期性および反復性の定義も含まれる。 【0142】プレスクリプト・コマンドの実行中にエラ
ーが発生すると、エラー・メッセージが、返され、説明
表示部位(Explaination View)に表
示され、現在のプレスクリプト表現の実行は中止される
が、プレスクリプトの実行が阻止されるわけではない。 描画中のエラーは、次のような意味で決して致命的では
ない。即ち、所与のプレスクリプト・オブジェクトの表
示中のエラーにより、次のようなプレスクリプト・オブ
ジェクトの表示が妨げられることはない。しかし、第2
の表示結果が第1のものに依存する場合、第2の表示結
果は、正しくない可能性がある。 【0143】プレスクリプト・オブジェクトは、プレス
クリプト作用素、ならびに型引数(例えば、数型)およ
び仮想的評価環境において束縛される推測されるシンボ
ル引数からなる良く構成されたプレスクリプト表現であ
る。視覚的なオブジェクトは、4つのプレスクリプト要
素の組み合わせによって定義される。4つのプレスクリ
プト要素とは、P=(d,e,i,s)である。ここで
、d=「描画(drawing)」、e=「エクステリ
ア(exterior)」、i=「インテリア(int
erior)」、およびs=「センサ(sensor)
」である。さらに、4つのセンサ方式(利用者対話作用
)S=(in,ex,bc,ac)がある。ただし、i
n=「センサに入る手順」、ex=「センサから出る手
順」、bc=「クリック前の手順」、ac=「クリック
後の手順」である。 【0144】プレスクリプトの要素は、次のように定義
される。即ち、描画(d)は、視覚的対象の(表示装置
から独立した)描き方と初期の描画から動画を与えるオ
プションの変換関数とを記述するプレスクリプト・オブ
ジェクトである。エクステリア(e)またはマスクは、
所与の表示部位(view)において視覚的表現対象に
範囲を定めるために使用される明確に定義されたインテ
リアを有するプレスクリプト・オブジェクトである。イ
ンテリア(i)または範囲は、ビジュアル・オブジェク
トの実質的な内部に範囲を定めるために使用される明確
に定義された内部を有するプレスクリプト・オブジェク
トである。センサ(s)は、指示装置の指示に感応する
領域に範囲を定めるために使用される明確に定義された
インテリアを有するプレスクリプト・オブジェクトであ
る。 【0145】図4における利用者アクタによって例示し
たようなプレスクリプト・オブジェクトの例を以下に示
す。 【数1】 【0146】このプレスクリプト・オブジェクトP1は
、P1の設定環境(letで設定される)におけるd1
に従って、表示装置上のx、y座標(806,276)
の周囲を中心とした位置に表示される。変数「icon
」が指定された位置に表示される。変数「name」が
、使用されて、指定の位置にヘルベチカ(Helvet
ica)フォント(サイズ14、肉太型)で印字された
後、枠が描かれる。エクステリアe1は、座標P1を中
心とし、半径150の円の外部によって定義される。イ
ンテリア(i)は、座標P1を中心とする幅「w」およ
び高さ「h」の四角の内部である。そして、センサ領域
s1は、「name」の表示を囲む四角i1の底にある
さらに小さい四角によって範囲が決定される。 【0147】センサ方式は、次のように定義される。即
ち、センサに入る手順(in)は、指示装置が視覚対象
のセンサ領域に入ったときに呼び出される手順である。 デフォルトの手順は、マウスがセンサ領域に入ったとき
、そのセンサ領域が強調されることである。センサから
出る手順(ex)は、指示装置がセンサ領域から出たと
きに呼び出される手順である。デフォルトの手順は、マ
ウスがセンサ領域から離れた場合、センサ領域が強調さ
れなくなることである。クリック前の手順(bc)は、
指示装置がセンサ領域において選択を行うために使用さ
れるとき(例えば、マウスがクリックされるとき)に呼
び出される手順である。センサ領域を色付けしたり再描
画したりする、現在の表示部位において視覚対象のポイ
ンタに関連した動きを与える、現在の評価環境における
記号的事実を変更する、視覚対象に関する操作のメニュ
ーを出す、またはいくつかの手順の組み合わせを含む、
いくつかのデフォルト手順が利用できる。クリック後の
手順(ac)は、センサ領域における指示装置の選択が
解除されたときに呼び出される手順である。デフォルト
の手順は、恐らくは変化した評価環境においてセンサ領
域を再描画するときに利用できる。 【0148】P1の表示された名前を変更するP1に対
するクリック前の手順を、前記のP1の例に従って、以
下において定義する。 【数2】 この定義、ならびに「in」、「ex」および「ac」
の手順に関する前記のデフォルトの定義の結果として、
次のように言える。指示装置が、P1のセンサ領域s1
(「name」の表示の周囲の見えない四角)に入ると
、「in」の手順が呼び出され、四角s1が強調される
。指示装置を用いてP1のセンサ領域で選択を行うと、
P1の「bc」手順が呼び出され、これによって、(「
previous−name」(前の名前)と称する新
たな変数の下に「name」という現在の変数を格納し
た後に)P1の環境における「name」の値が「Ma
rgaret」に変化する。指示装置が解放されると、
P1に関するデフォルトの「ac」手順が呼び出される
ことによって、プレスクリプトの要素d1がP1の(変
化した)環境において実行される。従って、最上部にア
イコンがあり、最下部にヘルベチカ・フォントで「Ma
rgaret」(特定の利用者の名前)という語が印字
された四角として、P1が表示される。指示装置が、第
2の選択のインサイドs1のために使用された場合、P
1の名前は、P1の環境において定義された利用可能な
「previous−name」の値に変更される。従
って、名前「user」が、P1の環境における変数「
name」の値として復活する。第2の選択の内側s1
の解放時に呼び出される「ac」手順によって、P1の
表示は、最上部にアイコンがあり、最下部に「usr」
と言う語がある四角へと変化して戻る。指示装置がP1
のs1領域を離れると、「ex」のデフォルト手順が呼
び出され、s1は強調されなくなる。 【0149】アクタの選択可能な視覚表現を対話的に設
計するために、GRASでは前記のようなクリック手順
が使用される。それによって、ボタン、スイッチ、およ
び種々の入出力ビジュアル・オブジェクトが提供される
。これらの構成物をさらに込み入ったシステム要素へと
結合するために、アクタの合成が用いられる。例えば、
電話のオブジェクトは、ケース・アクタ、押しボタンア
クタの集合、液晶表示、および送受話器から構成される
。 【0150】クリック手順は、引数付きで定義された場
合、指示装置を介して行われる選択の型について選択的
である(例えば、左ボタンの選択に対し右ボタンの選択
と異なった定義をすることができるなど)。クリック手
順のための評価環境を形成するために、現在の環境が用
いられる。指示装置において行われるビジュアル・オブ
ジェクト、現在の表示部位、および選択の型は、これら
の手順に対する引数として渡される。さらに、ビジュア
ル・オブジェクトの階層(例えば、成分関係)が所与で
あるとし、ビジュアル・オブジェクトAが、その階層に
おいてビジュアル・オブジェクトBの下位のものである
ならば、Aは、その上位の属性への明確な参照を用いる
ことによって、Bの環境へのアクセスも有する。 【0151】例えば、電話オブジェクトPh1が、押し
ボタンPB1のサブオブジェクトを有する場合、PB1
の環境において、Wはその押しボタンの幅であり、(S
UPERIOR W)は、PB1の上位のもの(su
perior)、つまり電話オブジェクトPh1、の幅
である。 【0152】デフォルトのクリック手順によって、現在
のビュー(表示部位)Vにあるビジュアル・オブジェク
トAの動きが、ビューVにおけるAに与えられる強制関
数にならって与えられる。運動は、(成分の階層にある
)Aの上位のものの程度分だけさらに強制される。成分
の階層のAの最上位のものは、現在のビューにおけるす
べてのアクタの運動が入っているビューV用のビデオ・
モニタである。 【0153】例えば、Ph1のサブオブジェクトC1(
カーソル)が動いているならば、C1の運動は、Ph1
の内部(interior)領域に限られる(Ph1の
「i」要素)。 【0154】アクタのプレスクリプト評価環境は、3つ
の環境の組み合わせからなる。 1)そのアクタの局部知識ベースを記述する環境:(l
et al=V1,...,an=vn,...)ただ
し、「ai」は、その知識ベースにおける事実の記号名
を表し、「vi」は、対応する値または表現である。 2)そのアクタの関連する特性を記述する環境:(le
t self=vself,name=vname,i
name=Viname,icon1=vicon1,
...,x1=vx1,x2=vx2,...,xp=
vxp,...)ただし、「self」(アクタ自体)
は、「vself」、即ちこのアクタに特有の識別子(
例えば、そのアドレス)に束縛される。「name」は
、アクタのステージ名に束縛される。「iname」は
、そのアクタの内部名(またはシンボル・アドレス)に
束縛される。 「icon1」は、アイコン表現「vicon」、即ち
アイコン・ライブラリにあるアイコンの記号的な識別子
に束縛され、可視イメージを生成するために、使用され
る。「xi」は、p次元の絶対座標系におけるアクタの
座標に固定された絶対的な関連で束縛される。 3)所与のテープに対して定義され、ビューの集合{v
iewj}(j=1,...,q)に対するアクタの視
覚的表現および属性に関する変換と強制の集合を定義す
る環境:この環境は、次のものからなる。則ち、(a)
異なるビューに対する異なる座標:T:{xi} −>
(view1/t1({xi}),...,view
q/tq({xi}))T(viewj):{xi}
−> tj({xi})ただし、tjは、その絶対座標
に基づくj番目のビューにあるアクタの座標を得る変換
関数である。その変換がビューにおいて線形ならば、そ
の変換は、座標変換行列Mj({xi}=Mj{xi/
view})を用いて表すことができる。(b)ビュー
の集合における座標の移動に関する強制: C:{xi} −> (view0/c0({xi})
,view1/c1({xi}),..,viewq/
cq({xi})) C(viewj):{xi} −> cj({xi})
ただし、cjは、j番目のビューにおいて観察されるア
クタの座標に対する強制関数である。絶対座標系に単一
の強制関数c0が与えられる場合、ビューqを発生する
線形変換Mjが存在し、さらに各ビューに対して使用さ
れる強制関数が cj=c0 o Mj であると仮定する。 (c)すべてのビューに対する記号翻訳関数の集合:こ
の関数のアクタは次のように表される。 viewj −> trj ただし、trjは、アクタの環境(name、inam
e,iconなど)からの記号特性または局部知識ベー
ス(ai)からの要素の名前をj番目のビューで使用さ
れる新たな名前に変換する。デフォルトの翻訳関数は、
無変換である。 【0155】j番目のビューにおけるアクタの視覚的表
現は、ビューがviewjであることを知っているその
アクタのプレスクリプト環境の中でアクタに関係付けら
れたビジュアル・オブジェクトの第1のプレスクリプト
表現(描画)を評価することによって得られる。アクタ
のプレスクリプト環境は、そのアクタのビジュアル・オ
ブジェクト(それぞれエクステリア、インテリア、およ
びセンサ)の定義ならびに利用者の対話中の適切なセン
サおよびクリック手順の呼び出しに使用される他の3つ
のプレスクリプト・オブジェクト(e、iおよびs)の
評価にも使用される。 【0156】すべてのビューにおけるグラフィカルな変
化は、時刻tにおけるアクタ環境のプレスクリプト評価
によるアクタの知識ベースへの論理的変更によって直接
的にもたらされる。アクタのグラフィック表現を記述す
るプレスクリプト表現は、このアクタの設定環境(le
t環境)の束縛事項(ai)を使用する。従って、「a
i」スロットのの値は、アクタのプレスクリプト・オブ
ジェクトのプレスクリプト要素(d、e、i、s)の指
定に自由に使用される。この性質により、アクタのle
t環境として実現されるアクタの知識ベースの変更を反
映する表示の変更がサポートされる。グラフィック・エ
ディタは、使用規則、前記のような論理的変更、および
グラフィカルな効果を関係付け結合させるコードを自動
的に生成する。他の実施例では、論理的変更とグラフィ
カルな効果との間のデーターベースが維持されるものも
ある。GRASシステムのユーザ・インタフェースは、
そのようなビジュアル・オブジェクト(アクタの視覚的
表現)を用いて作った。この表現方法の柔軟性は、ビジ
ュアル・オブジェクトを用いて作ったシステム(への)
インタフェースは数日で完全に設計し直すことができる
ほどである。この環境は、それ自体のインタフェース、
例えば、ボタンの外観および感知力の変更、新たなボタ
ンの追加、および対応するコマンドなどを編集するよう
に、設定することができる。これは、それ自体の中でV
SMベースのシステムを再設計する仮定における第1段
階である。 【0157】実行中は、アクタの知識ベースの履歴がソ
フトコーダによって自動的に維持され、グラフィックス
と状態の完全に可逆的な実行を与えている。各アクタは
、中でそれが使用されている各テープに対して自動的に
維持されているそのアクタの属性の変化の履歴を持って
いる。この履歴は、有効な変更の記録であり、そのアク
タがあるテープで使用されていなければ、その履歴は、
そのテープに対しては空である。アクタの属性への変更
により、アクタのグラフィック表現に影響を与えること
が可能であり、テープのシミュレーション中にアクタの
視覚表現に可能な唯一の変更は、その属性の変更による
ものである。従って、維持される履歴は、アクタの内部
的な属性とその視覚的な表現の両方の完全な記録を与え
るに十分な機構である。 【0158】アクタ間の通信 アクタ間の通信は、ソフトコーダによるスクリプト規則
の実行を介して行われる。通信には、アクタ間の情報の
伝送、およびその伝送にともなうすべての処理が含まれ
る。通信機能が低下した場合、アクタからそれ自体への
伝送を伴い、そのアクタ環境における内部処理と同じに
なる。通信には2つのモード、即ち(1)相互同意によ
る通信、および(2)送付(delivery)による
通信が定義される。 【0159】(1)相互同意による通信:2つの異なる
アクタの間のメッセージ転送を伴うスクリプト規則の実
行の場合を考えると、メッセージが送信される前にセン
ダとレシーバの両アクタの事前条件が同時に満たされる
とき、この通信は、相互の同意によって実行される。ま
たこの通信は、同期通信とも称し、次式を使って表され
る。 P(S,R)=>M(S,R)=>Q(S,R)ここで
、Sはセンダ、Rはレシーバ、P、MおよびQはそれぞ
れ事前条件、MSGおよび事後条件である。同期通信は
、アクタ・システムにおける最小単位の処理である。 【0160】(2)送付による通信:スクリプト規則が
与えられ、センダのアクタの事前条件がレシーバのアク
タの事前条件より先に満たされた場合、通信は送付(d
elivery)を介して行われる。センダのアクタは
、その環境において構成されたメッセージを事前条件の
満足時に発行する。すると、そのスクリプト・インスタ
ンスは、「Sent」(送信済み)というスクリプト型
を用いて印が付けられ、ソフトコーダは、レシーバのア
クタに送付するために、その通信を待ち行列に加え、さ
らにセンダのアクタの事後条件が実行される。この通信
は、非同期通信とも呼ばれ、前の表記を用いて次のよう
に表すことができる。 P(S)=>M(S,Sent)=>Q(S)(wai
t) P(R)=>M(Delivered,R)=>Q(R
) M(S,Sent)は、メッセージが、センダの環境に
おいてそれが送られるときに、構成されることを示す。 M(Delivered,R)は、メッセージがRによ
って受信された時、Rの環境は、送付されたメッセージ
からの環境を含めるために、一時的に拡大され、次に、
この一時的な環境において、Rの事後条件Q(R)が実
行される。 【0161】アクタ間の一般的な通信モデルにおいて、
アクタは、いくつかの通信を平行して送受信などの処理
を行うことができる。ただし、これが所与のアプリケー
ションにとって望ましくないならば、この問題を避ける
ようにスクリプト規則を設計することができる。アクタ
の事後条件が平行して実行されたために、現在のアクタ
環境の同一の属性に多重に変更が起こる場合、矛盾の可
能性がある。このような矛盾は、実行時に容易に検出さ
れるので、目的のアプリケーションにとって容認できる
技法を用いて解決することができる(無作為抽出、多重
値、変更上書き、エラー信号など)。 【0162】問題のアクタが関与するテープ・プログラ
ムの実行中に、利用者が、アクタを削除したり、アクタ
の記述を変更したりすると、可能な別の矛盾例が発生す
る。問題は、その変更が特定のシナリオの実行に限られ
るのか、あるいはそのアクタのオリジナルの記述に対し
て報告された(グローバルな)ものか、ということであ
る。この矛盾は、利用者に局部的(ローカルな)変更か
全体的(グローバルな)変更かを選択させることによっ
て解決される。変更が局部的な場合、現在時刻のAのデ
ータ空間だけが、Aの将来の履歴のように影響を受けて
る。変更が全体的な場合、最初は、その変更が局部的に
行われ、アクタの履歴が空でなければ、その変更もAの
初期のデータ空間の記述に報告されている。削除されて
いるアクタによって、その変更が、スクリプト規則の集
合の削除を必要とする場合、利用者はそれらの規則の削
除に関する確認させられ、そして手の施しようのない矛
盾を避けるために、テープ・プログラム実行の自動巻き
戻しが行われる可能性がある。 【0163】所与のテープ・プログラムの実行中に、実
行の履歴の中で以前に現れたスクリプト規則を削除しよ
うと思うことがある、つまり、このスクリプト規則に対
するスクリプト・インスタンスが存在するのである。ま
たは、その履歴が再び再生されれば、利用者は、そのス
クリプト規則の出現または他のスクリプト規則の異なる
仕方での出現を禁止したり、そのきっかけを作ったりす
ることになるような方法でスクリプト規則やアクタを編
集する可能性もある。この種の矛盾は、前記のように手
に終えない結果を招く可能性がある。実行の履歴を築く
ために既に使用された規則の編集には、その履歴の再構
築を必要とする可能性がある。修正された規則の集合を
用いては、アクタ・システムの現在の状態を回復できな
いこともある。この場合、テープ・プログラムの実行を
巻き戻し、そのアクタ・システムの匹敵する状態が回復
可能かどうかを検査するために古い履歴を再実行するこ
とが推奨される。 【0164】MOVON アクタのデータ空間および履歴:実現の実際性のために
、アクタに対して維持される履歴は、データ空間の変化
の測度(measure)に基づく。 D(A,t) mDS(A,t) dD(A,t1,t2) dmDS(A,t1,t2)
が、それぞれ時刻tにおけるアクタAのデータ空間(D
)、時刻tにおけるこのデータ空間の測度(mDSの値
は数である)、時刻t1およびt2の間のAのデータ空
間における差(dD)、および時刻t1およびt2の間
のアクタAに対するデータ空間の変化の測度(dmDS
,数)である。ここで、アクタAの履歴は、アクタAの
データ空間に対する相当な変化の有限集合として定義す
ることができる。例えば、アクタAの初期のデータ空間
: D(A,t0) が分かると、アクタAに対し粒状性(e)を有するサイ
ズnの有限履歴は、 He(A)={(ti,dD(A,ti,ti−1))
|dmDS(A,ti,ti−1)>=e} 1=<
i=<n として定義される。さらに、 T(He(A))={ti} 1=<i=<nは、A
の履歴からのタイム・スタンプの集合を表す。つぎに、 D(A,tj)=D(A,t0)+{+dD(A,ti
,ti−1)} 1=<i=<jを用いて、Aの中間
的なデータ空間が得られる。また、次のようなアクタA
に対するデータ空間の変化の空間効率的な記述を用いて
、アクタの履歴のモデルを洗練することが可能である。 【数3】 He,g(a)により、粒状性eおよび効率gを有する
アクタ履歴のモデルが定義される。従って、時刻tにお
けるAの中間的なデータ空間をAの履歴から以下を用い
て導くことができる。 【数4】 アクタAは、その初期のデータ空間およびデータ空間の
履歴が分かる時間の階段状の関数であるアクタのデータ
空間記述D(A,t)によって時刻tに完全に明記され
る。アクタの履歴は、そのアクタが変更された時刻とそ
れに対応するそのアクタのデータ空間への変更の記述と
のリストに過ぎない。その形式のアクタ・データ空間の
変化(dD)によって記述されるのは、新たなスロット
および(若しくは)新たな値の追加、ならびに(または
)新たなスロットおよび(若しくは)新たな値の削除、
ならびに(または)値の変更である。アクタAのアドレ
スa(t)は、Aのデータ空間の特別な要素であり、ア
クタ・システムにおいてAに特有の識別子を与えるもの
である。 【0165】アクタ・システムにおける可逆性:アクタ
の履歴により、各アクタごとに限られた履歴管理機構が
与えられる。アクタ間の通信システムでは、アクタのデ
ータ空間は、そのアクタが伝達情報を送信したり処理し
たりするときに、変更できるに過ぎない。さらに、伝達
情報の送信および処理は、最小単位の処理である。従っ
て、アクタ・システムにおける各変更の範囲は、各通信
について完全に明記されるため、すべてのアクタのデー
タ空間の測度が固定値で制限されているという仮定の下
で、すべてのアクタの履歴を線形時間で維持することが
可能である。このモデルにより、維持されるアクタの履
歴の大きさを限度内で完全に可逆性の処理がサポートさ
れる。このモデルのコンピュータ処理に関する重要な利
点は、処理歴のアクタ間の分散であり、これによって、
分散アクタ・システムにおいて可逆的なコンピュータ処
理がサポートされる。 【0166】アクタ環境:アクタによるGRASの実施
においては、時刻tにおけるアクタAのデータ空間D(
A,t)を表すためにlet環境を使用する。 (let a1=v1,...,an=vn;...)
ここで、aiはAのスロットの記号的表現、viはそれ
に対応する値またはその値を表す表現、そしてnは時刻
tにおけるスロットの総数であり、さらに「=」記号は
値の割当を表す。時刻tにおけるAのデータ空間の測度
は、mDS(A,t)=nであり、使用される履歴の定
義は、H1(A)(e=1)である。アクタの環境によ
って、時刻tのそのアクタが完全に記述される。アクタ
の作用の記述は、そのアクタの環境と、そのアクタが演
ずるテープから利用できる作用とから全体的に引き出す
ことができる。 【0167】アクタの関係および接続:アクタは、双方
向性リンクによるフレーム表現を用いる関係として実現
される静的または動的な従属関係にも関与する。静的な
従属関係には、クラス・メンバーシップ(AKO)、成
分メンバーシップ(COMPONENTまたはPART
−OF)、接続、テープ・メンバーシップおよびその他
が含まれる。動的な従属関係には、アクタ間の接続(例
えば、データ通信のための回線接続)が含まれる。なお
、応用分野に適合するようにアクタ間に新しい型の関係
を定義することもできる。新たな関係を表し作るために
属性として視覚表現の参照を利用することができる。 各種の関係に(グラフィックスの組み合わせによる)視
覚的な表現を(オプションで)与えるために、グラフィ
ックスの原形の有限集合が使用される。関係属性は、他
のアクタとの関係を定義するために使用されるアクタの
属性の集合である。例えばCOMPONENT(成分)
関係であるが、この場合、アクタの分解が、成分および
下位成分によって与えられる。各成分は、1つのアクタ
であり、従って、他のアクタと通信することができるが
、成分は、それを所有するアクタの物理的な部分でもあ
る(例えば、スピーカーと押しボタンを有する電話機)
。 【0168】VSMの関数 GRASシステムは、VSMモジュールによって利用者
の水準で実現される。VSMモジュールは、利用者の要
求を果たすためにさらに低い水準のモジュールを要求す
るユーザ・レベルの関数から成る。 【0169】特殊効果:作用の規則を洗練するために、
録音の最中かその後で特殊効果のソフトウェア・モジュ
ールを利用することができる。例えば、スクリプト規則
において、アクタ、事前条件、事後条件、転送されたメ
ッセージおよびデータを修正することができる。トラッ
キング装置の入力およびメニューの選択によって、その
変更結果が与えられる。一般スクリプトに対するアクタ
対の集合を定義するオーディション表現を生成するため
に特性の対話的な指定(例えば、属性の値に関するパタ
ン照合表現)を含む一般規則(General Scr
ipt)を洗練するために、さらに特殊効果を利用する
ことができる。 【0170】図6は、テープ生成(CREATE TA
PE)関数の流れ図である。テープ・生成関数は、MO
VONにテープ・ビジュアル・オブジェクトを要求する
(作用ブロック601)。次に、MOVONは、指名さ
れた新たなテープにフレーム構造体を割り当てる(作用
ブロック602)。MOVONは、ロードされたテープ
のフレームにそのフレーム構造体をリンクする(作用ブ
ロック604)。そのフレームを環境に存在するビデオ
・モニタ(view)のフレームにリンクすることによ
り、その新たなテープを現在のテープとする(作用ブロ
ック606)。新たなテープは、ソフトコーダにロード
(LOAD TAPE参照)され(作用ブロック608
)、未来のリールと過去のリールにリンクされ、シミュ
レーション・カウンタが内部的に設定される。MOVO
Nにより、新たなテープが表示され(作用ブロック61
0)、ビデオ・モニタの再表示が行われる。 【0171】図7は、テープ・ロード関数(LOAD
TAPE)の流れ図である。ロード・テープ関数により
テープがロードされることになる(作用ブロック702
)。テープの過去のリールおよび未来のリールが、ソフ
トコーダの過去のリール要素および未来のリール要素に
リンクされ、スクリプトのインスタンスおよび規則がソ
フトコーダに組み込まれることになる(作用ブロック7
04)。テープ・カウンタの値を用いて、シミュレーシ
ョン・カウンタが設定される。MOVONにより、その
テープから既存のアクタがビデオ・モニタの適切な表示
部位に表示される(作用ブロック706)。ソフトコー
ダは、初期シミュレーション・モード、動画の速度およ
び詳細水準を随意選択するために、予備的な評価を行う
(作用ブロック708)。再生(PLAY)関数(後述
)が呼び出され(作用ブロック710)、MOVONに
より、実行可能なスクリプトの最初の集合からアクタが
それらに関係付けられたview(スクリプト・タッグ
による)にリンクされ、アクタ、適切なviewにおい
て交わされるメッセージおよびデータが表示される(作
用ブロック712)。 【0172】図8は、テープ・コピー関数(COPY
TAPE)の流れ図である。まず、コピー・テープ関数
は、コピーが取られるべき元となるテープを要求し(デ
フォルトにより現在のテープがロードされる)、次に元
のテープをコピーする先のテープを要求する(作用ブロ
ック802)。コピー先のテープが既に存在し(判断8
04)、かつこのテープを再利用することになった(判
断806)場合、元のテープのフレーム構造体が、先の
テープのフレーム構造体へと(再利用を伴う)合併され
る(作用ブロック808)。先にテープが存在しなけれ
ば、新たなフレーム構造体が割り当てられ(作用ブロッ
ク810)、そのフレームが、ロードされたテープのフ
レームにリンクされ(作用ブロック812)、元のテー
プのフレーム構造体が新たなコピー先の構造体へと合併
される(作用ブロック808)。 【0173】図9は、テープ削除関数(REMOVE
TAPE)の流れ図である。テープ削除関数は、取り除
くべきテープを決定し(作用ブロック902)、そのテ
ープと共にアクタも削除するべきかどうかを判断する(
作用ブロック904)。MOVONは、そのテープのフ
レーム構造体をロードされたテープのフレームから切り
離す(作用ブロック906)。テープと共にアクタも削
除するべき場合(作用ブロック908)、この関数は、
そのテープ中で使用され、かつ他のロードされたテープ
においては使用されないアクタをすべて取り除く(削除
する)(作用ブロック910)。一方、アクタはテープ
と共に削除すべきでない場合、そのテープで使用され他
のロードされたテープでも使用されるアクタは切り離す
が、他のロードされたテープへのリンクは維持する(作
用ブロック912)。次に、そのテープのフレーム構造
体を削除し(作用ブロック914)、他のフレームへの
そのリンクをすべて消去する。 【0174】図10は、テープ・ファイル貸出関数(R
ENT TAPE FILE)の流れ図である。テープ
・ファイル貸出関数は、テープ・ファイル・フォーマッ
トおよびそのテープ・ファイルへのパスを要求する(作
用ブロック1002)。そのファイルに格納されている
テープの数が決められる(作用ブロック1004)。各
テープに対しテープ生成関数が呼び出される(作用ブロ
ック1006)。MOVONが、テープがファイルから
生成されるのに必要とされるアクタの生成または(再利
用を伴う)合併を行う(作用ブロック1008)。MO
VONは、それらのテープによって必要とされる各ビュ
ーに対しビデオ・モニタを生成し、テープ・ファイルか
らのリンク情報によってアクタをビューにリンクする(
作用ブロック1010)。次に、ソフトコーダが、テー
プ・ファイルから読み出されたスクリプト構造体に従っ
て、各テープを生成しリンクする(作用ブロック101
2)。 【0175】図11は、アクタ生成関数(CREAT
ACTOR)の流れ図である。アクタ生成関数は、生成
されるべきアクタの識別情報を要求する(作用ブロック
1102)。MOVONが、アクタのフレーム構造体を
割り当て、最小の内部属性およびグラフィカルな属性を
備えるように、その構造体を初期化する(作用ブロック
1104)。次にMOVONは、そのアクタ・フレーム
構造体を現在のテープ(作用ブロック1106)および
現在のビュー(作用ブロック1108)にリンクする。 MOVONは、次に、そのアクタが生成された現在のビ
ューと同じビューをサポートするすべてのビデオ・モニ
タに、そのアクタを表示する(作用ブロック1110)
。 【0176】図12は、アクタ選択関数(SELECT
ACTOR)の流れ図である。このアクタ選択関数は
、アクタ選択の型を要求する(作用ブロック1201)
。新たなオブジェクトが選択される場合(判断1202
)、アクタ生成関数が使用される(作用ブロック120
4)。すべてのオブジェクトが選択される場合(判断1
202)、MOVONは、ロードされた全アクタ(バッ
クステージ・アクタ)を現在のビューにリンクし、それ
らを対応するビデオ・モニタに表示する(作用ブロック
1206)。アクタの選択にキーワード探索を用いる場
合、キーワードを入力するように利用者を促す(作用ブ
ロック1208)。一致するアクタが見つからない場合
(判断1210)、新たな選択が必要になる(作用ブロ
ック1202)。一致するアクタが見つかった場合、特
定のアクタが要求され(作用ブロック1214)、(1
つでもある場合)そのアクタが、現在のビューにリンク
されて表示される(作用ブロック1216)。 【0177】図13は、アイコン状態設定関数(SET
ACON STATE)の流れ図である。この関数は
、実行された直後のスクリプト・インスタンスの集合の
中の1つのスクリプトを要求する(作用ブロック130
2)。つぎに、そのスクリプトからセンダのアクタまた
はレシーバのアクタを要求する(作用ブロック1304
)。MOVONが、前記のアクタによって使用される現
在のアイコン決定し、このアイコンに対する可能なアイ
コン状態の集合をアイコン・ライブラリから検索する(
作用ブロック1306)。次にアイコン状態設定関数が
、可能なアイコン状態の集合の中から1つのアイコン状
態を要求する(作用ブロック1308)。そのスクリプ
ト集合について、ソフトコーダのアンドゥ関数が呼び出
される(作用ブロック1310)。ソフトコーダは、選
ばれたスクリプトの事後条件リストにおけるアクタの状
態を変更するために、条件表現を追加する(作用ブロッ
ク1312)。ソフトコーダの再生関数が呼び出され、
MOVONが、アクタへの対応する変更を変更されたス
クリプト定義の実行結果として表示する(作用ブロック
1314)。 【0178】図14は、アクタ接続関数(CONNEC
T ACTORS)の流れ図である。アクタ接続関数は
、実行直後のスクリプトの集合の中の1つのスクリプト
(作用ブロック1402)と接続の型(記号的名称)と
を要求する(作用ブロック1404)。その接続の型に
対応するグラフィック表現(例えば、単線、2重線、会
議線)が決定される(作用ブロック1406)。接続す
るアクタ数が要求される(作用ブロック1408)。接
続するアクタが要求される(作用ブロック1410)。 ソフトコーダのアンドゥ関数が呼び出される(作用ブロ
ック1412)。「CONNECT{接続型}[選択さ
れたアクタのリスト]」という形式の条件が選択された
スクリプトの事後条件リストに加えられる(作用ブロッ
ク1414)。ソフトコーダの再生(PLAY)関数が
呼び出され(作用ブロック1416)、変更されたスク
リプトの実行結果として、選択されたアクタ間の接続が
、生成されて、適切なビューに表示される。 【0179】図15は、アクタ視覚化関数(MAKE
ACTORS VISIBLE)の流れ図である。この
関数は、実行直後のスクリプトの集合のうちの1つのス
クリプトを要求する(作用ブロック1502)。視覚化
するべきアクタが要求される(作用ブロック1504)
。ソフトコーダのアンドゥ関数が呼び出される(作用ブ
ロック1506)。 選択されたスクリプトの事後条件リストに「VISIB
LE[選択されたアクタのリスト]」という形式の条件
を追加する(作用ブロック1508)。ソフトコーダの
再生関数が呼び出され(作用ブロック1510)、その
変更されたスクリプトの実行結果として、前記のアクタ
が視覚化され(るか、または恐らくは生成された上で視
覚化され)て、適切な表示部位に表示される。 【0180】図16は、アクタ状態の設定関数(SET
STATE OF ACTOR)の流れ図である。ア
クタ状態設定関数は、実行直後のスクリプト・インスタ
ンスの集合の中からスクリプトを1つ要求する(作用ブ
ロック1602)。つぎに、そのスクリプトからセンダ
またはレシーバのアクタを要求する(作用ブロック16
04)。MOVONが、スロット名が要求される前記の
アクタから現在のスロットの集合を決定する(作用ブロ
ック1606)。このスロットは、そのアクタの状態を
変更するために使用される。そのスロットに対する新た
な値が決定される(作用ブロック1608)。そのスク
リプト集合にソフトコーダのアンドゥ関数が呼び出され
る(作用ブロック1610)。ソフトコーダは、そのア
クタのスロットを新たな値に変更するために、選択され
たスクリプトの事後条件リストにおいて条件表現を追加
する(作用ブロック1612)。その追加される条件は
、「SET{スロット名}{スロット値}」と言う形式
のものである。ソフトコーダの再生関数が呼び出され、
MOVONが、そのアクタに対応する変化を変更された
スクリプト定義の実行結果として表示する(作用ブロッ
ク1616)。 【0181】図17は、メッセージ経由のデータ渡し関
数(PASS DATA VIA MESSAGE)の
流れ図である。メッセージ経由のデータ渡し関数は、実
行直後のスクリプトの集合からスクリプトを要求する(
作用ブロック1702)。次に、前記のスクリプトのセ
ンダのアクタからのスロット名が要求される(作用ブロ
ック1704)。このスロット[slot−from]
が、もう一方のアクタに送られるべきデータとして使用
される。レシーバのアクタからのスロット[slot−
to]の名前が要求される(作用ブロック1706)。 そして、ソフトコーダのアンドゥ関数が呼び出される(
作用ブロック1708)。センダのアクタのスロット値
がそのメッセージを介して渡されること、およびそれが
受信されたときのシンボル名が{slot−from}
であることを示す「{slot−from}{slot
−from−values}」という書式が、選択され
たスクリプトのメッセージ表現に追加される(作用ブロ
ック1708)。 「SET{slot−to}{slot−from}」
という形式の条件が、選択されたスクリプトに対しレシ
ーバのアクタの事後条件リストに追加される(作用ブロ
ック1710)。 ソフトコーダの再生関数が呼び出され(作用ブロック1
712)、変更されたスクリプトの実行結果として、セ
ンダのアクタからのスロットの値が、レシーバのアクタ
の[slot−to]の値を更新するために渡されて、
適切な表示部位に表示される。 【0182】図18は、クローン・アクタ関数(CLO
NE ACTOR)の流れ図である。クローン・アクタ
関数は、コピーされるべきアクタを要求する(作用ブロ
ック1802)。MOVONが、そのアクタに対するフ
レーム構造体を割り当てる(作用ブロック1804)。 MOVONは、コピーされるアクタに対するアドレスを
、基となるアクタの名前とそのアドレスを唯一のものと
するコピー番号とを用いて生成する(作用ブロック18
06)。MOVONは、新たなアクタを現在のview
にリンクし、コピーされたアクタを同じviewを有す
るすべてのビデオ・モニタに表示する(作用ブロック1
808)。 【0183】図19は、アクタ合併関数(MERGE
ACTOR)の流れ図である。アクタ合併関数は、他の
アクタ{act−to}へと合併されるべきアクタ{a
ct−from}を要求する(作用ブロック1902)
。MOVONが、それらのアクタ・フレーム構造体を合
併する(作用ブロック1904)。ソフトコーダが、a
ct−fromのアドレスへの参照をすべてact−t
oへのアドレスで置き換える。(作用ブロック1906
)。 【0184】図20は、チャネル設定関数(SET C
HANNEL)の流れ図である。チャネル設定関数は、
そのチャネルを変更するビデオ・モニタを要求し(作用
ブロック2002)、さらにチャネルの選択を要求する
(作用ブロック2004)。選択されたチャネルが「全
チャネル」の場合(判断2006)、ソフトコーダが、
デフォルトのスクリプト構造体のタグ(名前)をそのビ
デオ・モニタにおける「Sid」に設定し(作用ブロッ
ク2008)、さらにMOVONが、そのチャネルの指
定を空にしたまま、そのビデオ・モニタを表示する(作
用ブロック2010)。選択されたチャネルが「新たな
チャネル」の場合、それに対応するスクリプト構造体の
タグが決定される(作用ブロック2012)。次に、ソ
フトコーダは、デフォルトのタグをビデオ・モニタにお
ける要求されたタグに設定する(作用ブロック2014
)。次に、MOVONが、ビデオ・モニタを表示し、そ
の表示にチャネル・タグを示す(作用ブロック2016
)。このビデオ・モニタにおいて記録する場合、そのタ
グは、そのビデオ・モニタのviewとこのviewに
おいて生成されたスクリプト構造体の集合との間の相互
参照の役に立つ。 【0185】図21は、変換テーブル関数(TRANS
LATION TABLE)の流れ図である。テーブル
操作に対する要求がVSMを介して利用者に送られる(
作用ブロック2102)。同時に発生するスクリプトの
現在のグループの中から1つのスクリプトを求める要求
が送られる(作用ブロック2104)。センダのアクタ
が、レシーバのアクタと同一でない場合(判断2106
)、VSMを介してエラー・メッセージが表示されて(
作用ブロック2107)、この関数は終了する。その他
の場合は、スクリプトによって、アクタ(センダ=レシ
ーバ)に対し内部で処理する仕事が記述され、変換テー
ブルを生成または編集することができる(判断2108
)。(判断2108において)スクリプト中に変換テー
ブルの表現が全く存在しない場合、新たな変換テーブル
の生成が必要となる。この場合、変換テーブルへの入り
口スロットとして使用するためのアクタの状態(スロッ
ト1)が選択され(作用ブロック2110)、さらに変
換テーブルによって変換された値の結果を格納するため
のアクタの状態(スロット2)が選択される(作用ブロ
ック2112)。データ変換のための値のリストが要求
される(作用ブロック2114)。変換テーブルが割り
当てられ、(新たな)変換表現が選択されたスクリプト
に挿入される(作用ブロック2116)。(判断210
8において)変換テーブルの編集作用が選択され、さら
に(判断2109において)スクリプト中に変換テーブ
ルの表現が存在しない場合、エラー・メッセージが表示
されて(作用ブロック2111)、この変換関数は終了
する。 (判断2108において)変換テーブルの編集作用が選
択され、(判断2109において)スクリプトに変換テ
ーブルの表現が存在する場合、MOVONによってVS
Mを介して変換テーブルが編集可能な形式で表示され、
利用者によって編集される(作用ブロック2113)。 次に、ソフトコーダが、修正された変換テーブル表現を
含むように、スクリプトの事後条件リストを変更する(
作用ブロック2115)。変換テーブル表現は、「se
t slot−2(select slot−1){(
entry,値の表現)の対のリスト}」という形式で
ある(作用ブロック2117)。 【0186】ビデオ・モニタは、アクタ間の一組の処理
を表示したり、テープへと視覚的に記録するために使用
される。ビデオ・モニタは、シミュレーションまたは生
成されているシステムの単純化した描画を表示または記
録することができる。ビデオ・モニタは、再生の特定の
部分のズーム・イン(拡大)およびズーム・アウト(縮
小)を行う機構を与えるために、表示部位の間の切り替
えに使用されるチャネル制御と詳細水準の制御とを備え
ている。記録モードでは、チャネル制御変更は画面上で
異なる視点または視野を得るためのカメラの変更に相当
し、詳細水準の変更は、そのカメラへのズーム・イン/
ズーム・アウト制御に相当する。ビデオ・モニタは、設
定および変更を動的に行うことができる種々の特性を持
っている。例えば、利用者は、ビデオ・チャネルを設定
することができる。モニタのチャネルを変更することに
より、それに表示される表示部位が変化する。大きさ、
色(カラーの場合)、表題、アニメーションの水準およ
び速さ、メモリの大きさ(即ち、モニタ上に一度にいく
つのイベントを思い出すことができるかという持続性)
、静的な表示と動的な表示、表示される詳細の解像度ま
たは水準、およびデフォルトのメッセージ名の位置(セ
ンダおよびレシーバのアクタに関するメッセージ表示の
デフォルトの位置が変えられる)などの特性は、すべて
利用者がビデオ・モニタからメニューまたはアイコンに
よって選択することが可能である。 【0187】ビデオ・モニタは、テープの再生、活性化
、または表示、処理のためのステージの記録または設定
に使用することが可能である。VSMインタフェースに
よって、テープの生成、編集、表示、および実行に対す
る直接的な制御が与えられる。新たな指示の入力を記録
することによって、実行中に変更を取り入れることがで
きる。記録または再生の間に、テープの詳細水準を(例
えば、スライド・バーを用いて)変化させて、高い詳細
水準の表示の間にズーム効果を与えることができる。ビ
デオ・モニタは、「再生(play)」モードで活動さ
せられているイベントおよび特殊効果を変更するための
描画/編集板として役立つ。ビデオ・モニタは、同時に
何百ものオブジェクトを表示することができるが、通常
は、20乃至30以下のオブジェクトが、標準的なグラ
フィックス表示技術に基づいた良好な視覚的図式の目安
である。1つのテープで30以上のオブジェクトが必要
な場合は、特殊効果を使用することができる。特殊効果
によって、個々の視覚的な対象の表示/非表示が自在に
可能である。 【0188】GRASのビデオ・モニタは、多数のビュ
ーポイントを用いて実現される。設計の使用には大きな
ものもあるので、利用者から不要な情報を隠すために射
影(多重表示)がサポートされている。GRASシステ
ムは、同時の記録およびアニメーションを多重表示でサ
ポートする。各ビデオ・モニタが、記録およびアニメー
ションに使用されるビデオ・チャネルと抽象(要約)水
準とを持っている。ウィンドウとグラフィックスをサポ
ートし、さらに視覚的なオブジェクトのみならずビデオ
・モニタも実現するために、目標とするコンピュータ・
システム(例えば、SunViewTM、X Wind
ow SystemTM、OPEN LOOKTM、S
ymbolics Windows、XeroxWin
dows)によって専用のウィンドウおよびグラフィッ
クスのシステムが使用される。SunViewはサン・
マイクロシステムズ(Sun Microsystem
s)の商標であり、X Window Systemは
MITの商標であり、OPEN LOOKはAT&Tの
商標である。 【0189】多重ビューポイントの特徴の応用により、
要約表示と詳細な表示との間にズーム操作が提供される
。例えば、提出された表示内容の利用者ならば、高水準
の要約表示を見ることになり、表示内容の開発者であれ
ば、内部の交換構造を示す詳細な表示を見るであろう。 2つの表示を「ハードウェア」の動作と「ソフトウェア
」の動作とを分離するために使用しても良い。 【0190】GRASウィンドウなどの使用により、ウ
ィンドウの使用が高められる。例えば、SunWiew
下のSunワークステーションは、ウィンドウを64ま
で持つことができる。Sun上のGRASは、VSM/
GRASアプリケーションと同時に実行中の他のSun
Wiewの(メール、テキスト編集、およびその他の)
アプリケーションによって残りのウィンドウを使用しな
がらでも、10以上のビデオ・モニタ・ウィンドウを使
用することができる。 【0191】Lispが動作する機械であれば、数百の
ウィンドウを持つことも可能である(この数はディスク
の容量によってのみ制限される)。Lisp機上のVS
M/GRASは、(例えば、多重表示のように)希望の
数だけビデオ・モニタを持つことができる。この概念は
、同じシナリオや異なるシナリオの実行のいくつかの異
なる表示を与える異なるチャネルに調節されたいくつか
のテレビ・モニタを持つことに似ている。 【0192】編集ルーム(Editing Room)
によって、テープ・シェルフのテープ、およびビデオ・
テープまたはフィルムの編集の類似性を用いてテープを
編集・操作するために使用される作用素の集合に直接ア
クセスすることができる。そして、テープを編集を行う
ことが、プログラムの操作に対する唯一の手段である。 アクタおよびアクタ環境の実現、ならびにアクタ間の通
信過程におけるアクタの使用によって与えられる実行状
況の結末に基づいて、各スクリプト構造体は、ソフトコ
ーダの仮想機械によって実行される独立した単位処理と
して扱うことが可能であり、基本的なプログラム要素と
して操作することができる。テープ・プログラムには、
スクリプト構造体の閉集合が常にある。2つのテープを
接着することにより、おそらく両方のテープからさらに
機能性が得られることになり、これによって、GRAS
の背景において機能的統合が半自動化の可能な処理とな
る。テープを2つのサブテープに切断することも可能で
あるが、両方のサブテープが完結し、一貫性が維持され
る位置でテープを切断する必要があるので、いっそう注
意が必要となる。テープの切断および接着により、別個
の作業努力による機能性を結合する簡単な機構が与えら
れる。このことは、アクタどうしを合併できることと結
びついて、プログラム・システムにおける新たな特徴の
連続的な統合に取り組む強力な骨組みを提供する。 【0193】ソフトコーダ(SoftCoder)GR
ASのソフトコーダは、テープ・プログラムのスクリプ
ト規則(Script Rule)と一般スクリプト(
General Script)からなる未来のリール
、およびテープ・プログラムの実行履歴をたどるアンド
ゥ可能なスクリプトの集合からなる過去のリールを備え
ている。過去のリールでは、すべてのスクリプト・イン
スタンスが、逆向きの実行が可能である。つまり、すべ
てのスクリプト・インスタンスに、Sundo表現とR
undo表現がある。過去のリールには、実行の履歴と
その実行中に入力されたデータが入っているので、試験
用のシナリオとして使用することができる。 【0194】図29は、ソフトコーダの視覚的な表現で
ある。テープは、記録されたスクリプト規則と一般スク
リプトの集合であり、過去のリール2910は、シミュ
レーション中の現在時刻以前にシミュレータによって選
択され発動されたスクリプト・インスタンスに相当し、
未来のリール2920には、残りの規則か、またはシミ
ュレーションの生成モードにある完全なテープ・プログ
ラムの何れかが入っている。各リールは、時計回りに回
転し、シミュレーション中は、一度に1ステップ以上前
進する。固定の(再生)ヘッド2930によって、スク
リプト規則と一般規則の集合を読んで実行する。アンド
ゥ・ヘッド2950により、スクリプト・インスタンス
にアンドゥを行う情報で印を付ける。記録ヘッド294
0は、新たな規則の記録および挿入を行うために何時で
も利用することができる。先取りヘッド2960は、シ
ミュレーションにおいて次に発動するべき規則の集合を
捜すのに使用される。 【0195】ソフトコーダは、次の制御を有する「制御
パネル」を備えている。自動再生:テープ・プログラム
を現在の位置から最後まで(停止位置まで)選択された
アニメーション速度で自動的に再生する。図22は、自
動再生制御関数(AUTOPLAY)の流れ図である。 自動再生関数は、テープ・プログラムの最後に到達する
か、または自動再生の開始後に停止関数が呼び出される
まで(判断2204)、再生関数を繰り返し呼び出す(
作用ブロック2202)。 【0196】再生:現在発動可能な動作の規則の集合を
実行することによって一度に1ステップ(1フレーム)
だけテープの再生を行う。図23は、再生制御関数(P
LAY)流れ図である。再生関数は、再生の背景的条件
を定義する次の変数を確認する(作用ブロック2302
)。 即ち、ロードされた現在のテープおよびそのリール(未
来のリールおよび過去のリール)、現在のアニメーショ
ン速度、シミュレーション・モード、アニメーションお
よびシミュレーションの水準である。次に、その再生の
背景的条件において、再生関数は、スクリプト規則と一
般スクリプトの適切な集合を未来のリールから見つける
(作用ブロック2303)(このシミュレーション・モ
ードの関数としての動作の次の詳細な説明を参照のこと
)。そのスクリプトの集合が空の場合(判断2304)
、テープ・プログラムの最後に達したことが利用者に知
らされて(作用ブロック2305)、再生関数が終了す
る。さらにスクリプトが利用できる場合(作用ブロック
2306)、テープ・プログラムの実行の他の変形が可
能であることが利用者に知らされて(作用ブロック23
07)、再生関数が終了する。スクリプトの適切な集合
が空でない場合(判断2304)、そのスクリプトが再
生され(作用ブロック2310)(次の詳細な説明を参
照のこと)、アニメーション速度によりシミュレータを
待たせる必要がある場合(判断2308)、スクリプト
の再生の前に時間的遅延が導入され(作用ブロック23
09)、それから再生関数を終える。 【0197】記録:新たな通信を記録し、それを自動的
に現在のテープ位置に挿入する。図24は、記録関数(
RECORD)の流れ図である。記録関数は、記録の背
景条件を定義する次の変数をまず確認する(作用ブロッ
ク2402)。即ち、現在のテープ・プログラム、現在
のビューおよびチャネル、現在のアニメーション、シミ
ュレーションおよび記録の水準を確認する。次に、記録
関数は、記録中の新たな通信に対するセンダのアクタを
要求する(作用ブロック2403)。センダが指定され
ると(判断2405)、そのアクタを(オーディション
処理によって)確認するか、または生成するかする(作
用ブロック2406)。センダが指定されなければ、記
録関数は終了させられる。センダのアクタが分かると、
レシーバのアクタを要求する(作用ブロック2407)
。レシーバのアクタが指定されると(作用ブロック24
08)、それは確認されるかまたは生成される(作用ブ
ロック2409)。指定されない場合、記録関数は終了
する。次に、記録関数は、スクリプト規則を選択するよ
うに要求する(作用ブロック2410)。スクリプトが
全く指定されない場合(判断2411)、この関数は終
了する。指定された場合、スクリプト規則または一般ス
クリプトが生成されが、それがない場合、既存のものか
らクローンが生成させる(作用ブロック2412)。新
たなスクリプトがテープ・プログラムの未来のリールに
挿入され(作用ブロック2413)、再生関数が呼び出
される(作用ブロック2415)。最後の記録関数以来
はじめて停止関数が呼び出された場合(作用ブロック2
416)、記録関数は停止するが、そうでなければ、記
録関数は再開する(作用ブロック2401)。 【0198】停止:現在のテープに対し行っている自動
実行、記録またはアンドゥを終了させる。図25は、停
止制御関数の流れ図である。停止関数は、割り込みによ
って起動される。即ち、停止ボタンが押されると(判断
2502)、停止の事象が待ち行列に加えられる(作用
ブロック2503)。前述のように、再生(自動再生)
、記録、およびアンドゥ(自動アンドゥ)の関数も停止
事象の有無を確認する。 【0199】カウンタ:テープの開始から実行されたス
テップ数を示す。カウンタは、入力素子でもあり出力素
子でもある。カウンタを特定の位置に設定すると、テー
プをその位置まで自動的に進めたり巻き戻したりする。 図26は、カウンタ制御関数の流れ図である。カウンタ
関数は、表示か設定かによって2通りに呼び出すことが
できる(判断2602)。表示の場合、カウンタ関数は
現在のシミュレーション計数を得て(作用ブロック26
04)、カウンタの表示を更新する(作用ブロック26
05)。ここで、現在のシミュレーション計数は、現在
のテープ・プログラムの開始以来経過したシミュレーシ
ョン時間単位の数である。カウンタの設定の場合、カウ
ンタ関数は、カウンタ値を要求する(作用ブロック26
06)。カウンタ値が現在のシミュレーション計数を越
える場合(作用ブロック2607)、所望のカンウタ値
に達するか、停止関数が呼び出されるか、またはテープ
の終わりに達するまで、自動再生関数が呼び出される(
作用ブロック2608)。それ以外の場合、所望のカウ
ンタ値に達するまで、自動アンドゥ関数が呼び出される
(作用ブロック2609)。 【0200】アンドゥ:通信の最後の集合(起動された
スクリプト・インスタンスの最後の集合)の影響を取り
消す。最終ステップを巻き戻し、最終グループの処理の
影響を逆にする。図27に、アンドゥ制御関数(UND
O)の流れ図を示す。アンドゥ関数は、次の変数からア
ンドゥの背景条件を確認する(作用ブロック2702)
。即ち、シミュレーション・モード、シミュレーション
水準、現在のテープ・プログラム(未来のリールおよび
過去のリール)、多重ビューおよびアニメーションの水
準を確認する。次に、アンドゥ関数は、過去のリールか
ら復元されるべきスクリプト・インスタンスの集合を得
る(作用ブロック2703)。次に、アンドゥ関数は、
復元されるべきスクリプト・インスタンスの集合に対し
、1)そのスクリプト集合に関与するすべてのアクタの
データ空間をこのスクリプト集合の実行時刻に先立つシ
ミュレーション時刻におけるそれらのデータ空間にまで
戻すとともに、2)そのスクリプト・インスタンスが視
覚的な副作用を有する場合、対応するグラフィックスの
アンドゥ関数を実行する(作用ブロック2704)。次
に、アンドゥ関数は、過去のリールから前記のスクリプ
ト・インスタンスを削除し(作用ブロック2705)、
現在のシミュレーション計数および現在のスクリプト集
合を更新する(作用ブロック2706)。アンドゥ関数
に関する説明は、他に次のシミュレーション・モードの
詳細説明にもある。 【0201】自動アンドゥ:テープの始まりか、または
停止ボタンでテープを停止させるまで自動巻き戻しを行
う。また、自動アンドゥは、自動実行の影響を選択され
たアニメーション速度で完全に逆にする。図28は、自
動アンドゥ関数(AUTOUNDO)の流れ図である。 自動アンドゥ関数は、過去のリールがなくなるか、また
は停止関数が呼び出されるまで(判断2804)、アン
ドゥ関数を繰り返し呼び出す(作用ブロック2802)
。 【0202】UNDOおよびAUTOUNDOは、完全
なアンドゥ機構である。再生(およびその視覚的な副作
用)の影響は、何れかの制御を使用している間に完全に
元どうりになる。これにより、デバッグおよび検査に対
する簡単で効果的な手段が与えられる。シナリオを途中
で停止させ、特定の点まで巻き戻し、変更してから、マ
ウスを数回クリックして先を続けることができる。オブ
ジェクトの状態の変化および処理の動的なアニメーショ
ンによって、デバッグまたは検査の間に、または活動し
ている対象を単に見ている間に、視覚的なフィードバッ
クが連続的に与えられる。 【0203】仕様の誤りは、シミュレーションの後続部
分が間違っているか、または矛盾することを利用者に警
告する警告メッセージが印字される契機となる。この不
完全性を(一時的に)無視して、設計の他の要素を継続
することは利用者の自由である。シミュレーション・エ
ラーは、誤ったデータ、不正な規則または規則の不正な
組み合わせの何れかによって発生する。利用者は、アン
ドゥや再生を行って仕様に目を通し、間違ったデータま
たは規則の場所を突き止めたのち、それらをその場で編
集し、さらに再生を用いてシミュレーションを継続する
ことができる。 【0204】VSMの範囲内でソフトコーダの仮想機械
を使用することにより、利用者は、その動作の例の中か
らプログラムを指定することが許される。VSMにおけ
る画像的なシミュレーションは、画像フレームの単純な
列ではなく、「プログラム可能な映画」である。つまり
、利用者の入力データによって、映画の結末は異なった
ものになる。 【0205】特定のシナリオの各ステップを順番に実行
すると、そのシナリオ例が新たに再生されるが、その再
生は、入力されたとおり行われるが、前に供給されたア
クタ入力またはその特定のシナリオに関係する他の例の
シナリオ入力がある場合、それによって修正されたとお
りに行われる。その例によって記述される動作は、さら
にアクタのデータを追加したり、模範的なシナリオを追
加することによって、対話的に1つのプログラムへと洗
練することができる。アクタ系の動作は、アクタの状態
の変化に応じて変化し、新たなデータがアクタ間で交わ
される。アクタの状態、実行された処理、および通信中
に交わされる情報に関する他の情報の変更、削除、また
は追加を行うために、アクタおよび動作規則は、何時で
も編集することができる。アクタの状態および画像表現
の変更は、利用者の裁量によって、永久的であるか局部
的であるかの何れかであればよい(可逆的)。結果とし
て得られる規則が、テープ・プログラムを形成する。 【0206】ソフトコーダのシミュレーション・モード
テープ・プログラムは、スクリプト規則と一般スクリプ
トの集まりであるが、(部分的な)優先順位を持つ動作
の集まりでもある。テープの全体的な順序化は、テープ
・シナリオの生成をもたらすテープ・プログラムのシミ
ュレーションによって実行時に見られるに過ぎない、ソ
フトコーダは、4つのシミュレーション・モードを有す
る。即ち、(1)連続モード、(2)スマート・モード
、(3)同時モード、(4)生成モードである。 【0207】4つのシミュレーション・モードは、同一
のテープを再生する、つまり1つの使用を実行する4つ
の異なる方法に対応する。これらの4つのモードは、進
歩する洗練段階に相当し、それらの段階は、単純に連続
するシナリオから始まり、種々の状況において所与の特
徴(異なるデータ、実行の異なる道筋、エラー処理、同
時性)をシミュレートできる実行可能な規則ベースで終
わる。 【0208】連続シミュレーション・モードの視覚的な
表現を図30に示す。連続シミュレーション・モードで
は、各スクリプト規則および一般スクリプトが、テープ
が本来記録された順序で再生される。固定ヘッド303
0は、発動された最後のスクリプト上に常に位置する。 【0209】スマート・シミュレーション・モードの視
覚的な表現を図31に示す。スマート・シミュレーショ
ン・モードでは、各スクリプト規則は、それが現在のテ
ープ・ステージから論理的に実行(発動)されるべきか
どうかを調べるために、実行前に検査される。発動され
得る最初のスクリプト規則が、発動され、テープの未来
のリール3120から過去のリール3110へと移され
、中間のスクリプト規則は省略される。 【0210】同時シミュレーション・モードの視覚表現
を図32に示す。同時シミュレーション・モードは、ス
マート・シミュレーション・モードの拡張である。この
モードでは、各スクリプト規則は、それが現在のテープ
状態から論理的に発動さ得るかどうかを調べるために、
実行前に検査される。同時に発動可能なスクリプト規則
のグループがあることもしばしばある。このような場合
、同時シミュレーション・モードによって、並列実行を
用いてスクリプト規則を同時に発動することが許される
。 【0211】生成シミュレーション・モードは、同時シ
ミュレーション・モードの拡張である。このモードでは
、テープが閉ループに接着され、スクリプト規則および
一般スクリプトのシーケンスを繰り返し発動することが
できる。このモードは、同時発動がある標準的な生成規
則システムに類似している。さらに、この生成モードで
は、時間依存性および完全な可逆的実行がサポートされ
る。繰り返し発動するスクリプト規則の集合によって形
成されるループは、終端条件(例えば、カウンタが所定
の値に達するなど)が満たされるまで実行し続ける。 【0212】仮定:PRおよびFRが、ソフトコーダに
ロードされた現在のテープ・プログラムの過去および未
来のリールをそれぞれ示すものとする。また、f、r、
u、およびlaが、ソフトコーダの固定ヘッド、記録ヘ
ッド、Undoヘッド、および先取り(look−ah
ead)ヘッドであるとする。時刻tにおいて、 PR(t)=(U1,U2,...,Unt)FR(t
)=(R1,R2,...,Rpt)連続シミュレーシ
ョン・モードでは、各スクリプト規則および一般スクリ
プトは、テープが本来記録された順番に再生される。固
定ヘッドは、常に、最後に発動されたスクリプト上に位
置する。 【0213】連続モードは、次のように実現される。 1)PR(t)およびFR(t)は、2つのスタック・
オブジェクトの現在の内容を表す。 2)次のスクリプト規則を再生するためには:時刻tに
おいて、f(t)をFRスタックの最も上にある規則R
1に最初に結合する。規則R1は、そのアクタおよび視
覚的効果(画像的なアンドゥ・コマンドの集合)に対す
るアンドゥ(回復)表現を生成し記録することにより、
アンドゥを行う準備がなされ、その規則は、アンドゥ可
能型と印が付けられて、u(t)となる。次に、f(t
)=R1というメッセージが、センダのアクタからレシ
ーバのアクタへと送られ、f(t)からの事後条件が(
そのアクタの属性をいくつか変更して)実行され、対応
する視覚効果が表示され、FRスタックが一回ポップ(
pop)され、さらにu(t)は、それがU1となりt
が単位時間だけインクリメントされるPRスタックへと
プッシュ(push)される。発動可能な規則が見つか
らない場合、再生が停止し、テープ・プログラムの終了
したことが利用者に知らされる。 3)記録の場合、r(t)は、記録直後の規則を示し、
FRスタックにプッシュされ、次のステップが時刻tで
再生される。 4)アンドゥを1ステップ行う場合、u(t)は、U1
をアンドゥする次の規則を示す。この規則の事実上の影
響は、オプションのメッセージ表示も含めて、元どうり
にされ、そのアクタのアンドゥ表現は、この規則が発動
される前の初期状態までそれらを復元しながら、実行さ
れる。アンドゥ表現はu(t)から削除され、元の型の
規則が復元され、それがf(t)となり、PRスタック
が一度ポップされ、さらにf(t)は、それがR1とな
りtが単位時間だけデクリメントされるFRスタック上
にプッシュされる。 5)自動再生するには、FRスタックが空になり、他の
規則が記録されていなくなるまで、再生ステップを反復
する。 6)自動アンドゥをするには、PRスタックが空になる
まで、アンドゥ・ステップを繰り返す。 7)停止するには、最後の規則の実行またはアンドゥが
完全に行われた後(例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど)、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【0214】スマート・シミュレーション・モードでは
、各スクリプト規則は、それが現在のテープ・ステージ
から論理的に実行(発動)されるべきかどうかを調べる
ために、実行前に検査される。発動可能な最初のスクリ
プト規則が、発動され、テープの未来のリールから過去
のリールへと移され、中間のスクリプト規則は省略され
る。 【0215】スマート・モードは次のように実現される
。 1)PR(t)およびFR(t)は、2つのスタック・
オブジェクトの現在の内容を表す。 2)次のスクリプト規則を再生するためには:時刻tに
おいて、f(t)をFRスタックの最も上にある規則R
1に結合する。この規則の事前条件が検査され、条件が
満たされない場合は、FRスタックがポップされ、f(
t)がPRにプッシュされ(この規則はアンドゥ可能型
には変更されない)、条件が満たされる場合には、この
規則は、そのアクタおよび視覚的効果(画像的なアンド
ゥ・コマンドの集合)に対するアンドゥ(回復)表現を
生成し記録することにより、アンドゥを行う準備がなさ
れ、その規則は、アンドゥ可能型と印が付けられて、u
(t)となる。次に、f(t)=R1というメッセージ
が、センダのアクタからレシーバのアクタへと送られ、
f(t)からの事後条件が(そのアクタの属性をいくつ
か変更して)実行され、対応する視覚効果が表示され、
FRスタックが一回ポップされ、さらにu(t)は、そ
れがU1となりtが単位時間だけインクリメントされる
PRスタックへとプッシュされる。発動可能な規則が見
つからない場合、再生が停止し、テープ・プログラムの
終了したことが利用者に知らされる。 3)記録の場合、r(t)は、記録直後の規則を示し、
FRスタックにプッシュされ、次のステップが時刻tで
再生される。 4)アンドゥを1ステップ行う場合、u(t)は、U1
をアンドゥする次の規則を示す。U1がアンドゥ可能型
でない場合、スタックPRがポップされ、u(t)がF
R上にプッシュされる。U1がアンドゥ可能型の場合、
この規則の事実上の影響は、オプションのメッセージ表
示も含めて、元どうりにされ、そのアクタのアンドゥ表
現が実行されて、この規則が発動される前の初期状態に
までそれらを復元する。アンドゥ表現はu(t)から削
除され、元の型の規則が復元され、それがf(t)とな
り、PRスタックが一度ポップされ、さらにf(t)は
、それがR1となりtが単位時間だけデクリメントされ
るFRスタック上にプッシュされる。 5)自動再生するには、利用者の入力が要求されるか、
またはFRスタックが空になり、かつ他の規則が記録さ
れていなくなるまで、再生ステップを反復する。 6)自動アンドゥをするには、PRスタックが空になる
まで、アンドゥ・ステップを繰り返す。 7)停止するには、最後の規則の実行またはアンドゥが
完全に行われた後(例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど)、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【0216】同時シミュレーション・モードは、スマー
ト・シミュレーション・モードの拡張である。このモー
ドでは、各スクリプト規則は、それが現在のテープ状態
から論理的に発動さ得るかどうかを調べるために、実行
前に検査される。同時に発動可能なスクリプト規則のグ
ループがあることもしばしばある。このような場合、同
時シミュレーション・モードによって、並列実行を用い
てスクリプト規則を同時に発動することが許される。 【0217】同時モードは次のように実現される。 1)PR(t)は、スタック・オブジェクトの現在の内
容を表し、FR(t)は、スタック=シーケンス・オブ
ジェクトの結合体の内容である。つまり、FRは、プッ
シュおよびポップを行うことができるスタックであると
同時に、ポップ操作もプッシュ操作もない直接アクセス
による探索および修正が可能なシーケンスでもある。 2)次のスクリプト規則を再生するためには:時刻tに
おいて、f(t)をFRスタックの最も上にある規則R
1に結合する。この規則の事前条件が検査され、条件が
満たされない場合またはその規則が既にグループ型と印
が付けられている場合、FRスタックがポップされ、f
(t)がPRにプッシュされ(この規則はアンドゥ可能
型には変更されない)、条件が満たされる場合(この規
則は時刻tにおいて発動可能であると言う)には、それ
は最初の発動可能な規則であり、f(t)は、グループ
型と記され、それ自体のGroup−Saddress
フィールドに追加され、f(t)として存続し、la(
t)がFR(t)に適用される。発動可能な規則が見つ
からない場合、再生が停止され、テープ・プログラムの
最後に達したことが利用者に知らされる。先取り処理で
は、la(t)がFR(t)全体の高速探査を行って他
のすべての発動可能な規則を一度に集め、発見された各
規則がグループ型と記され、続いて、la(t)によっ
て発見された規則の集合がf(t)の現在のGroup
−Saddress集合(これは、最初は{f(t)}
である)に結合される。 グループ型のf(t)規則は、そのすべてのアクタ(そ
のGroup−Saddress集合からのアクタ)お
よび視覚的効果(画像的なアンドゥ・コマンドの集合)
に対するアンドゥ(回復)表現を生成し記録することに
より、アンドゥを行う準備がなされ、その規則集合が、
アンドゥ可能グループの型と印が付けられて、u(t)
となる。次に、f(t)=R1のGroup−Sadd
ressからのメッセージ集合が、センダのアクタの集
合からレシーバのアクタの集合へと並列に送られ、f(
t)のGroup−Saddressからの事後条件が
、その集合の各規則に対する別個の背景条件において、
対応するアクタの属性をいくつか変更して並列的に実行
され、対応する視覚効果が表示され、FRスタックが一
回ポップされ、さらにu(t)は、それがU1となりt
が単位時間だけインクリメントされるPRスタックへと
プッシュされる。 3)記録の場合、r(t)は、記録直後の規則を示し、
FRスタックにプッシュされ、次のステップが時刻tで
再生される。 4)アンドゥを1ステップ行う場合、u(t)は、U1
をアンドゥする次の規則を示す。U1がアンドゥ可能型
でない場合、スタックPRがポップされ、u(t)がF
R上にプッシュされる。u(t)のGroup−Sad
dressの規則と同様に、U1がアンドゥ可能型の場
合、各規則の事実上の影響は、(オプションのメッセー
ジ表示も含めて)元どうりにされ、そのアクタのアンド
ゥ表現が実行されて、この規則が発動される前の初期状
態にまでそれらを復元し、アンドゥ表現がu(t)から
削除され、元の型の各規則が復元され、最も上の規則が
f(t)となり、PRスタックが一度ポップされ、さら
にf(t)は、それがR1となりtが単位時間だけデク
リメントされるFRスタック上にプッシュされる。 5)自動再生するには、利用者の入力が要求されるか、
またはFRスタックが空になり、かつ他の規則が記録さ
れていなくなるまで、再生ステップを反復する。 6)自動アンドゥをするには、PRスタックが空になる
まで、アンドゥ・ステップを繰り返す。 7)停止するには、最後の規則の実行またはアンドゥが
完全に行われた後(例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど)、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【0218】生成シミュレーション・モードは、同時シ
ミュレーション・モードの拡張である。このモードでは
、テープが閉ループに接着されるので、一連のスクリプ
ト規則および一般スクリプトを繰り返し発動することが
できる。このモードは、同時発動がある標準的な生成規
則システムに類似している。さらに、この生成モードで
は、時間依存性および完全な可逆的実行がサポートされ
る。繰り返し発動するスクリプト規則の集合によって形
成されるループは、終端条件(例えば、カウンタが満期
になるなど)が満たされるまで実行し続ける。 【0219】生成モードは、次のように実現される。 1)PR(t)は、スタック・オブジェクトの現在の内
容を表し、FR(t)は、シーケンス=ハッシュ・テー
ブル=格子オブジェクトの結合体の内容である。つまり
、FRは、ハッシュ・テーブル、即ちキーが符号化され
た一種のコンピュータ・オブジェクトであるため、FR
にいかに多くのスクリプト規則が格納されていても、ス
クリプト規則をその記号的参照情報(Sid)によって
効率的に検索することができる。FRは、所与の規則集
合の後に発動できる次の規則集合がFRの限られた部分
集合に含まれることが分かるように、予め計算された相
互間の論理的依存状態に基づいてスクリプト構造体が予
め配列されているような格子である。生成モードにおい
ては、再生、自動再生、アンドゥ、または自動アンドゥ
の最中にFRは(例えば、ポップやプッシュによって)
変更されない。しかし、FRは、スクリプト規則の記録
および消去(削除)の間に変更され再構成される。再生
またはアンドゥの間に記録も消去も起こらないと仮定し
て、FR=(R1,R2,...,Rp)とする。時刻
tにおいて、pt≦pとしたSFR(t)=S(FR,
t)=(R1,R2,...,Rpt)を時刻tに発動
するべき候補であるスクリプト規則のFRからの有限部
分集合とする。SFRは、tの前に発動された規則を知
ることによってFR格子から得られる。 2)次のスクリプト規則を再生するためには:f(t)
をSFR(t)からの最初の規則である規則R1に結合
する。この規則の事前条件が検査され、条件が満たされ
ない場合、その規則は無視され、f(t)は、SFR(
t)からの次の規則のインスタンスに結合され、それは
、f(t)が発動可能な規則となるかSFR(t)から
のすべての規則が不成功のうちに検査されるまで、検査
される。この時点で、発動可能な規則が見つからない場
合、f(t)は、待機型またはアンドゥ可能型の規則の
インスタンスに結合され、f(t)はPR上にプッシュ
され、tが単位時間だけインクリメントされる。f(t
)の事前条件が満たされる、即ち時刻tにおいて規則が
発動可能である場合、それはSFRからの最初の発動可
能な規則であり、元の規則を変更することを防止するた
めにf(t)は、それ自体のインスタンスによって置き
換えられ、グループ型と印が付けられ、それ自体のGr
oup−Saddressフィールドに加えられる。そ
れは、f(t)として存続し、la(t)がSFR(t
)に適用される。先取り処理では、la(t)がSFR
(t)全体の高速探査を行って時刻tにおいて発動可能
な他のすべての規則を集め、発見された各規則はグルー
プ型と印を付けられたそれ自体のインスタンスとして集
められ、続いて、la(t)によって収集された規則イ
ンスタンスの集合がf(t)の現在のGroup−Sa
ddress集合(これは、最初は{f(t)}である
)に結合される。グループ型のf(t)規則は、そのす
べてのアクタ(そのGroup−Saddress集合
からのアクタ)および視覚的効果(画像的なアンドゥ・
コマンドの集合)に対するアンドゥ(回復)表現を生成
し記録することにより、アンドゥを行う準備がなされ、
その規則集合が、アンドゥ可能グループの型と印が付け
られて、u(t)となる。次に、f(t)=R1のGr
oup−Saddressからのメッセージ集合が、セ
ンダのアクタの集合からレシーバのアクタの集合へと並
列に送られ、f(t)のGroup−Saddress
からの事後条件が、その集合の各規則に対する別個の背
景条件において、対応するアクタの属性をいくつか変更
して並列的に実行される。対応する視覚効果が表示され
、さらにu(t)は、それがU1となりtが単位時間だ
けインクリメントされるPRスタックへとプッシュされ
る。 3)記録の場合、r(t)は、記録直後の規則を示し、
SFR(t)の要素としてFR格子に挿入され、必要で
あれば前の配列を復元するためにFR格子が再計算され
て、時刻tにおいて次のステップが再生される。 4)アンドゥを1ステップ行う場合、u(t)は、U1
をアンドゥする次の規則を示す。U1がアンドゥ可能型
でない場合、誤りが存在する。U1がアンドゥ可能で待
機型の場合、U1は捨てられ、tが単位時間だけデクリ
メントされる。U1が、アンドゥ可能で待機(グループ
)型でない場合、u(t)のGroup−Saddre
ssの規則と同様に、各規則の事実上の影響は、オプシ
ョンのメッセージ表示も含めて、元どうりにされ、その
アクタのアンドゥ表現が実行されて、この規則が発動さ
れる前の初期状態にまでそれらを復元し、アンドゥ表現
がu(t)から削除され、元の型の各規則が復元され、
最も上の規則がf(t)となり、PRスタックが一度ポ
ップされ、さらにf(t)はそのまま存続し、tが単位
時間だけデクリメントされる。 5)自動再生するには、利用者の入力が要求されるか、
または停止ボタンが押されるまで、再生ステップを反復
する。 6)自動アンドゥをするには、PRスタックが空になる
まで、アンドゥ・ステップを繰り返す。 7)停止するには、最後の規則の実行またはアンドゥが
完全に行われた後(例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど)、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【0220】動作の規則の記録、消去、および照会GR
ASの使用およびソフトコーダの実行能力におけるいく
つかの利点は、何時でも変更を行い、機械の処理能力に
限定される穏当な時間でその変更を自動的に有効にする
柔軟性に由来するものである。上述の再生およびアンド
ゥの機構は、ソフトコーダによって提供されるそのよう
な柔軟な処理モデルの実例である。テープ・プログラム
のシミュレーションの最中にアクタ間の新たな通信を記
録したり、関係する動作規則を取り除いたりできること
も、仕様決定、システム設計、および試験に対するソフ
トコーダ方式の威力の例である。 【0221】アクタ間の動作規則を記録するには、3つ
のステップが必要である。 1)ビジュアル・プログラミング:ビジュアル・クルー
(clue)、タイプ入力、メニュー項目によって収集
された必要な情報を用いて、基本的なスクリプト構造体
を生成する。 2)規則の挿入:現在の規則ベースに新たなスクリプト
構造体を挿入する。 3)修正されたテープ・プログラムを(前節の説明のよ
うに)さらに一段階再生する。 【0222】ビジュアル・プログラミング:GRAS画
面上で現在活性なビデオ・モニタのうちの1つからセン
ダのアクタとレシーバのアクタを選択したり、メニュー
選択およびキーワード捜索をしたり、バックステージか
らアクタを検索するためにオーディション表現を選択し
たりすることによって、基本的なスクリプト構造体R0
を作る。オーディション表現は、利用者によって編集お
よびカスタマイズすることも可能である。スクリプト構
造体R0は、記号による新たな参照情報(Sid)が与
えられ、センダおよびレシーバの属性には、選択された
アクタ(またはアクタのオーディション記述)が書き込
まれ、センダおよびレシーバのT(真)に対するデフォ
ルトの事前条件が定義され、事後条件は全く定義されな
い。次に、新たなメッセージを(利用者がタイプ入力で
)指定するか、またはメニューと既存のスクリプト構造
体の集合に対するキーワード捜索とによって選択する。 新たなメッセージが指定された場合、R0のメッセージ
・フィールドには、指定されたメッセージが書き込まれ
る。既存のスクリプト構造体R1が選択された場合、R
1の事前条件と事後条件とメッセージ表現とのインスタ
ンスが生成され、R0の対応するフィールドを埋めるた
めに使用される。何れの場合も、新たに記録された規則
が前に発動された規則の集合の結果として発動される可
能性を保証する必要があるならば、R0の事前条件が変
更される。例えば、R2の発動後にR0が記録される場
合、「R0はR1の後に発動しなければならない」とい
うデフォルトの事前条件が、目標の規則記述言語で生成
される。 【0223】規則の挿入:この点において、規則R0は
、未来のリールに挿入する用意ができている。連続、ス
マート、および同時の各モードにおいては、R0は、単
にFRスタックの上にプッシュされ、このとき2つの記
録モードが可能である。 【0224】1)接続モードでは、発動するべきR0の
前例(前記の例ではR1)に以前は依存していたFR内
のすべての規則は、発動をR0に現在依存するように、
自動的に更新される。FRにおけるある規則の事前条件
は、そのように変更される。 【0225】2)並列モードでは、FRの何れの規則も
変更されず、従って、R0は、正常ならば前例の後に(
前記の例では、R1の後に)発動するはずの他の規則と
平行して発動すると予測される。生成モードでは、R0
は、SFR(t)に最初の要素として挿入され、FRの
格子構造の変更は、自動的に計算されるが、この場合、
記録モードに依存する。 【0226】1)接続モードでは、発動するべきR0の
前例(前記の例ではR1)に以前は依存していたSFR
(t)内のすべての規則は、発動をR0に現在依存する
ように、自動的に更新される。SFR(t)におけるあ
る規則の事前条件は、そのように変更され、さらに変更
は、FR格子の組織内に伝えられる。 【0227】2)並列モードでは、SFR(t)の何れ
の規則も変更されず、従って、R0は、正常ならば前例
の後に(前記の例では、R1の後に)発動するはずのS
FR(t)からの他の規則と平行して発動すると予測さ
れる。 【0228】既存の動作規則を消去する場合、ソフトコ
ーダによって提供される基本的な操作により、発動され
た最後のスクリプト規則を利用者が削除できる。この最
後の規則がグループ型の場合、利用者は、その集合から
規則を1つ選択するように促される。次に、テープ・プ
ログラムが1ステップだけ戻されて、選択されたスクリ
プト構造体がFR(または生成モードではSFR)から
削除される。そして、発動のために削除された規則にか
つて依存していたすべての規則に、発動のために依存す
るのに最適な代替規則が与えられる。生成モードでは、
次に、FRの格子構造が再編成され、規則の間の新たな
予配列が生じる。次に、その変化の影響を表示するため
に、テープ・プログラムが1ステップだけ再生され、削
除された規則に代わって別の規則が発動することになる
。規則集合の大きな塊を消去する場合、規則集合の一部
を切り取って捨てる方法が、フィルム・エディタによっ
て提供される。 【0229】ある型の規則(または規則の部分集合)の
未来または過去の実行のための既存の規則集合への照会
は、テープ・プログラムの実行を利用者に取って関心の
ある点に迅速に位置付ける機構を提供する。ソフトコー
ダの進歩したプログラム実行性を用いれば、実行履歴ま
たは実行の将来における所望の位置へテープ・プログラ
ムを自動的に位置決めすることを要求することができる
。これは、所望の点の例を記述する視覚的照会を記録し
、PRにおいて一致する一連の実行済み規則を捜し、照
合が成功した場合、必要とされるカウンタ位置への自動
アンドゥによってテープを位置決めし、成功しなかった
場合には、一致するまで自動再生を実行することにより
テープを位置決めする。 【0230】ビデオ・コネクタ ビデオ・コネクタは、GRASと異質のシステムとの間
の物理的または仮想的なデータ・リンクと結び付いたソ
フトウェアの通信プロトコルである。ビデオ・コネクタ
は、ビデオ信号源(カメラ、ミキサ、テレビ・ケーブル
)をVCRに連結する同軸ケーブルに似ている。しかし
、VSMでは、ビデオ・コネクタにより、外部のシステ
ムからテープへと事象を記録するとともに、外部のシス
テムからGRASを遠隔制御するための通信路が提供さ
れる。 【0231】GRASでは、利用者が処理を描写する(
指定する)のをカメラが追うように、利用者の対話から
得られる仕様をすべてのビデオ・モニタから記録するこ
とができる。記録中の各ビデオ・モニタは、アクタどお
しの間の作用がカメラで記録されるビデオ・スタジオの
一部である。ビデオ・スタジオ内のカメラは、仮想的な
ビデオ・コネクタによってソフトコーダに結合されてい
る。 【0232】ビデオ・コネクタのインタフェースは、ア
プリケーションがGRASにデータ跡を送ると同時にG
RASを遠隔制御できるように実現される。例えば、ア
プリケーションは、新たなテープを生成し、そのテープ
の遠隔記録(つまり、メッセージの照会)を開始し、詳
細水準を変更し、アニメーション・ビューを変更するこ
とができると同時に、GRASは、そのデータ跡の動画
化を同期モードまたは非同期モードで開始することがで
きる。所望により、アプリケーションは、使用される画
像表現を完全に制御することができる。GRASの遠隔
制御は、如何なる双方向データ・リンクによってもサポ
ート可能な標準のリモート・エバリュエーション・プロ
トコル(遠隔関数呼び出し)に基づく。 【0233】OOスクリプト OOスクリプトは、2つのアクタの間の単一処理を定義
する要素体である。OOスクリプトは、アクタの1つの
動作の一面を記述する最小の実体である。各OOスクリ
プトにより、センダおよびレシーバとして知られる1つ
または2つのアクタが関与する動作の1つの規則が記述
される。 【0234】オブジェクト対オブジェクトのスクリプト
(OOスクリプト)は、正式には、(スクリプト識別子
(sid),センダ,レシーバ,前提条件リスト(pr
econd−list),事後条件リスト(postc
ond−list),メッセージ,オプションの参考情
報)という数学的なタプル(特定数要素の集合)として
定義される。各OOスクリプトは、特有の識別子(si
d)に関係付けられている。「センダ」は、「レシーバ
」に呼び掛けるために「メッセージ」を発動する実体を
指す。「前提条件リスト(precond−list)
」は、OOスクリプトが活性化されるために満たされな
ければならない前提条件を与える。「事後条件リスト(
postcond−list)」は、そのOOスクリプ
トがの実行終了後には真となるべきシステムの事後条件
を与える。「メッセージ」は、オプションの引数を伴う
メッセージまたは関数の名前である。表された処理また
は関係するオブジェクトに関するコメントをオプション
の参考情報に含めることができる。 【0235】OOスクリプトのシンタックスを次に述べ
る。事前条件リストおよび事後条件リストは、両方とも
括弧で囲み、オプションの参考情報は、引用符(“ ”
)で囲む。引数のないメッセージは、それを囲む括弧を
付けても付けなくても良いが、引数付きのメッセージは
、引数を従えた第1の要素としてメッセージ名を伴う括
弧付きのリストとして表す。渡される文字データ・メッ
セージは、引用符で囲まれた文字列として示される。 【0236】OOスクリプトにより、センダがレシーバ
にメッセージを送る処理においてセンダとレシーバとの
間の相互作用を包含する規則が具体化される。メッセー
ジは、関数の呼び出し(例えば、プロシージャ・コール
の場合のような作用の要求)、データ伝送、またはその
両方で構成することができる。規則は、どの実体がセン
ダおよびレシーバであるか、前記のような相互作用が起
こる時期を支配する条件の記述、および相互作用の結果
である状態を指定する。スクリプトは、特定の状況また
は一連の事象に対するシステムの作用規則を包含するO
Oスクリプト集合である。 【0237】図2〜図5は、コンピュータのログイン手
順の仕様およびシミュレーションを与えるためにOOス
クリプトがどのように使用されるかの例を示す。図2は
、実施のコンピュータ手順の流れ図であり、図3は、コ
ンピュータのログイン手順の実施に使用される対応する
OOスクリプトを示し、図4および図5は、GRASに
よるログイン手順のシミュレーションの画像表示である
。 【0238】コンピュータ400は、端末410に「s
end−login」メッセージ405を送ることによ
ってコンピュータのログイン手順を開始する(作用ブロ
ック210)。開始ステップに対応するOOスクリプト
を図3のOOスクリプト310として示す。端末410
は、「send−login」メッセージ405に対し
、ログイン・プロンプト・メッセージ415を利用者4
20に表示して応答する(作用ブロック220およびO
Oスクリプト320)。ログイン・プロンプト・メッセ
ージ415に対し、利用者420は、自分のログイン・
ネームを端末のキーボード425上で入力することによ
って応答する(作用ブロック230およびOOスクリプ
ト330)。 手順の次のステップは、GRASの詳細水準に依存する
。前記のように、OOスクリプト識別子によって、多重
詳細水準が可能である。詳細水準が高いほど、経験がよ
り豊かな利用者のためのシナリオの深入りしたステップ
まで示されるが、詳細水準が低くなると、要約水準の高
いシミュレーションが示される。詳細水準を「1」と決
定した場合(判断240)、水準が低い方の2つのステ
ップがシミュレートされ(図5)てから、次の水準「0
」のステップがシミュレートされる。詳細水準が「1」
の場合(判断240)、端末510は、利用者のキーボ
ード入力内容525をログイン・ネーム・データ・メッ
セージ535によってコンピュータ500へ送る(作用
ブロック245およびOOスクリプト340)。 次に、コンピュータ500が、利用者520と共にパス
ワード入力手順を開始するようにメッセージ545を端
末510に送る(作用ブロック247およびOOスクリ
プト350)。シミュレーションの次のステップは、水
準0および水準1の両方に対して同じである。そのシミ
ュレーションに付いては、図4を参照する。端末410
が、「パスワード・プロンプト」メッセージ435を利
用者に送る(作用ブロック250およびOOスクリプト
360)。次に、利用者420が、キーボードでパスワ
ードを入力すことによって、パスワード・データ445
を端末410に送る(作用ブロック260およびOOス
クリプト370)。そして、シミュレーションの詳細水
準が「0」か「1」かをGRASシステムが判断する(
判断470)。詳細水準が「0」ならば、そのシミュレ
ーションは終了する(作用ブロック280)が、詳細水
準が「1」の場合(図5参照)は、端末510が、パス
ワード・データ・メッセージ575をコンピュータ50
0に送る(作用ブロック275およびOOスクリプト3
80)。そして、シミュレーションが終了する。 【0239】以上の説明は、本発明の一実施例に関する
もので、この技術分野の当業者であれば、本発明の種々
の変形例が考えられるが、それらはいずれも本発明の技
術的範囲に包含される。 【0240】 【発明の効果】以上述べたように、本発明によれば、プ
ログラム仕様についての労力をあまり要求することなく
、プログラムの作用をいっそう完璧にモデル化してプロ
グラム仕様を作ることができる。
ムおよび通信システムのためのプログラム仕様を開発す
る方法および装置に関する。 【0002】 【従来の技術】コンピュータおよび電気通信システムの
作用を制御するための複雑なコンピュータ・プログラム
やソフトウェア・システムの開発には、大きな作業努力
を必要とする。コンピュータ・プログラマ(ソフトウェ
ア開発者)は、複雑なソフトウェア・システムの設計、
コーディングおよび検査に多大な努力を費やす。複雑な
システムに対しては、ソフトウェア開発サイクルと言わ
れる設計、執筆およびコーディングの行程に何年もかか
ることもしばしばある。長年に渡りソフトウェア開発者
が学んだことは、ソフトウェアの検査にサイクルをあま
り費やさず、ソフトウェアに対する必要条件の立案、ソ
フトウェアの設計、およびコーディングに大部分を費や
せば、開発周期が短縮されると言うことである。この知
識が、ソフトウェア技術の進歩と相まって、さらに複雑
なソフトウェア・システムの開発をもたらした。 【0003】ソフトウェア技術の進歩にもかかわらず、
ますます複雑化するコンピュータ・ソフトウェアおよび
ソフトウェア稼働システムの開発は、依然として困難で
ある。この難しさのために、効率的かつ完全なソフトウ
ェア設計システムの重要性が増してきた。仕様設計が、
ソフトウェアの開発を容易にするための重要な第1歩で
ある。仕様書は、ソフトウェア・システムが満足しなけ
ればならない必要条件を含み、システムがどのように作
用しなければならないかを指定するものである。仕様書
は、その記述対象であるソフトウェア・システムと同様
に、生成がますます困難になってきた。これに対する1
つの理由は、仕様の生成に必要なソフトウェア環境の詳
細な知識である。 【0004】ソフトウェア・システムの作用をモデル化
することによって仕様の開発および検査を行うことの難
しさを軽減するために、ソフトウェア開発者はソフトウ
ェア・シミュレータを使用する。シミュレータは、シス
テムに関する入力に基づいて、そのシステムの作用をモ
デル化するプログラムを生成する。シミュレータは、仕
様の開発に役立つが、問題もいくつかある。第1に、シ
ミュレータは、単純でなじみ深いモデルを基にしておら
ず、システムの適切なモデルを生成するには、少なくと
もシミュレータ「言語」のプログラム作製知識が必要と
なる。開発者は、シミュレーションされるシステムがい
かに作用するかということに関わらなければならないだ
けでなく、シミュレーション・プログラムの開発にかな
りの量の思考を充てる必要がある。こうして、ソフトウ
ェアの仕様設計過程に複雑さが加わることになる。 【0005】次に、シミュレータは、1つのシステムの
独立した部分に対し特定の入力を要求するとともに特定
の出力を与えて、その部分を別個の実体として表す。こ
れらの実体の入力と出力が一致しない限り(しばしば一
致しない)、実体どうしが互いに作用し合う(「接続」
される)ことができないので、問題である。このように
、シミュレータを使用する開発者は、システムの部分の
全体的な統合を常にみることはできない。 【0006】最後に、シミュレーション中に開発者が、
誤りを発見したり、システムの作用のある部分を望む場
合、開発者は、シミュレーションを停止し、所望の変更
を行い、シミュレートするべきプログラムをコンパイル
しなおしてから、シミュレーションを最初から始めなけ
ればならない。このように、開発者は、変更結果を直ち
に見ることができないため、変更を行う処理に時間がか
かり、時間を非効率的に使用する結果となる。 【0007】 【発明が解決しようとする課題】従って、従来の技術の
課題は、利用者の広範なプログラミング知識を必要とし
ないソフトウェアの効率的な仕様設計手段を与えること
である。 【0008】 【課題を解決するための手段】前記の問題を解決するた
めの本発明の一実施例は、仕様の画像記録およびアニメ
ーションのための(GRAS=Graphical R
ecording and Animation of
Specifications)システムである。G
RASシステムは、プログラム仕様の記録、シミュレー
シ(アニメーション)、および洗練をグラフィカルに行
うために使用される。このシステムは、実例によるプロ
グラム仕様の設計に対応している。 【0009】GRASシステムの目的は、プログラミン
グの知識が少ない利用者がプログラム仕様を容易に作る
ための便宜を与えることである。この目的は、馴染み深
いモデルに基づくユーザ・フレンドリな環境を与えるこ
とによって達成される。GRASシステムは、プログラ
ム用の仕様の作製が演劇の作製、演出、テープ録画、お
よび編集に類似するビデオ・スタジオの隠喩(meta
phor)(VSM)に基づいている。ビデオ・スタジ
オ・メタファは、リハーサルによるプログラミングで用
いられる劇場の隠喩(theater metapho
r)を拡張する。例えば、ゼロックス社の1986年5
月のSCL−84−1のローラ・グールド(Laura
Gould)およびウィリアム・フィンツァ(Wil
liam Finzer)による「リハーサルによるプ
ログラミング(Programming by Reh
earsal)」を参照。VSMに基づくシステムを用
いて仕様を作製するには、プログラミングの知識はあま
り必要ない。技術者は、仕様設計システムには注意をほ
とんど向けずに、目的のシステムが如何に作用するべき
かに集中することができるので、ソフトウェアの仕様設
計過程において複雑さが軽減され、好都合である。 【0010】GRASシステムでは、仕様のソフト的記
録手段である「テープ」に対し、利用者が入力を与える
。GRASシステムは、一群のシナリオ例のステップを
記録することにより、またそれらのシナリオ例に対する
追加的なグラフィック規則を引き出すことにより、テー
プを生成する。1つのステップにより、シミュレートさ
れるテープのアクタどうしの間のメッセージ渡しによる
相互作用が指定される。(後述のように、「アクタ(a
ctor)」の概念は、人工知能の分野で周知である。 ) 【0011】アクタは、データとそのデータを操作する
手続きとを備えたコンピュータ・ソフトウェア構造であ
る。GRASで使用されるアクタも、知識ベースおよび
そのデータへの変更の履歴を持っている。アクタは、電
話若しくは電話交換システムなどのシステムの物理的構
成要素、またはプロセス若しくはデーターベースなどの
ソフトウェア構成要素、またはそのシステムと相互に作
用する作因、人などを表す。GRASでは、シナリオ例
の1ステップを記録するために、利用者は、そのステッ
プ用のセンダ(sender)およびレシーバ(rec
eiver)のアクタ、センダのアクタからレシーバの
アクタに送られるメッセージ、およびそのステップが実
行される前にシステムに存在していなければならない条
件を指定する。 各ステップは、テープ上に規則として記録され、そのシ
ナリオ例において実行される。利用者は、そのシナリオ
例の実行(そのテープの再生)、修正の実施、新たなス
テップの追加、または新たなシナリオ例の生成によって
、そのテープを対話的に洗練することができる。 【0012】コンピュータ・システムに対するコンピュ
ータ・ログイン・シーケンスの設計は、GRASの簡単
な使用例となる。コンピュータ・ログイン・シーケンス
のためのアクタは、コンピュータ、端末、および利用者
である。GRASを使用する技術者が、コンピュータ・
ログイン・シーケンスを次のように実現することを希望
するものと仮定する。即ち、(1)コンピュータが、「
sendlogin」要求メッセージを端末に送ること
によって、そのシーケンスを活性化する。(2)次に、
端末が、ログイン・プロンプトを利用者に表示する。(
3)利用者が、ログイン・ネームをキーボード入力を介
して端末に送る。(4)端末が、そのログイン・ネーム
をコンピュータに送信する。(5)コンピュータが、そ
の端末にパスワード入力手順を開始するようにメッセー
ジを送る。(6)端末が、パスワード・プロンプトを利
用者に表示する。(7)利用者が、パスワードをキーボ
ード入力を介して端末に送る。そして、(8)端末が、
そのパスワードをコンピュータに送る。 【0013】このコンピュータ・ログイン・シーケンス
のテープのための入力を与えるために、GRASの利用
者は、そのシーケンスの最初のステップを指定すること
によって開始する。これを行うことで、利用者は、1つ
のシナリオ例の最初のステップを指定することになる。 完全なプログラムは、複数のシナリオ例によって記述さ
れる。前記のステップ(1)を指定するには、まずセン
ダのアクタをコンピュータに、レシーバのアクタを端末
に、渡されるメッセージを「send login」に
指定する。 このステップは、利用者にグラフィカルに表示される一
方、そのシナリオ例の一部として記録される。前記のス
テップ(2)を指定するために、利用者は、センダ・ア
クタを端末に、レシーバ・アクタを利用者に、そして渡
されるメッセージを「ログインして下さい:」と指定す
る。やはり、このステップも、記録されつつ、利用者に
グラフィカルに表示される。そして、利用者は、そのシ
ーケンスの残りのステップを同じ要領で指定する。シー
ケンスを記録した後、利用者は、そのテープを再生する
ことにより、そのコンピュータ・ログイン・シーケンス
をグラフィカルにシミュレートする。コンピュータ・ロ
グイン・シーケンス全体のGRASによるグラフィカル
な表示を図5に例示する。 【0014】利用者は、記録中いつでも記録を停止して
、既に指定したステップをシミュレートするためにテー
プを再生することができる。ステップが正しくなければ
、そのステップの対話的な「アンドゥ」、アクタの変更
、メッセージの変更、またはそのステップに対する事前
条件の変更を行った後、そのステップを再び再生するこ
とができる。これにより、プログラム仕様の編集および
洗練が対話的に可能となる。 【0015】前記の例は、本発明の作用を説明するもの
であるが、本発明の原理によれば、コンピュータが利用
者の入力に対話的に応じてプログラムの仕様を生成する
。当分野はさておき、このプログラム仕様システムによ
って、仕様に対し対話的に与えられる変更に応じて、そ
の仕様のプログラムを再コンパイルすることなく、それ
らの変更のシミュレーションを直ちにグラフィカルに表
示する便宜が提供される。開発者は、より迅速に、より
効率的に、しかもシミュレーション・システムの操作の
知識もほとんど無しに、仕様を作製することができるの
で、好都合である。 【0016】当分野からさらに逸れるが、本発明により
、アクタ(これは、データの構造とプログラム手順から
なるソフトウェア対象である)の合併、およびアクタの
作用の合併がサポートされる。「アクタ」という考えは
、人工知能に由来する周知の概念である。例えば、19
86年、MITプレス刊のガル・アーガ(Gul Ag
ha)による「アクタ−−−−分散システムにおける同
時処理のモデル(Actors: A Modelof
Concurrent Computation i
n Distributed Systems)」を参
照のこと。この合併処理により、開発者は、プログラム
・システムの部品の全体的な統合を見ることが可能とな
る。 【0017】本発明の典型的な実施例であるGRASは
、VSMに基づくオブジェクト指向で知識ベースの視覚
的プログラミング・システムである。GRASは、利用
者の入力を用いてシステムの視覚的シミュレーションと
仕様データーベースを生成し、さらに詳細な入力を受信
した時、そのデーターベースを増強する。VSMは、親
しみやすい単純なモデルを提供するので、プログラミン
グについても、そのシステムについても詳しい知識なし
に仕様を生成することができるので、好都合である。 【0018】仕様のシナリオ例の記録(入力)、再生(
実行)、およびアンドゥ(逆向きの実行)を行うための
機構が、GRASのソフトコーダ(SoftCoder
)モジュールによって提供される。ソフトコーダは、ア
クタ間の作用の規則を記述する「(ビデオ)テープ・プ
ログラム」を処理して、仕様プログラムの実行の完全な
履歴からなる「テープ・シナリオ」を生成する仮想的な
装置である。テープ・プログラムの各ステップは、算術
演算および(または)論理演算の集合、アクタ・データ
、およびステップを「アンドゥ」することによって逆戻
りすることができるために仕様の一部を対話的に変更す
る機構を利用者に提供するアクタ間の通信を表すメッセ
ージからなる。効率的に誤りを訂正し、シミュレーショ
ン中に仕様の変更を行って、その結果を直ちに見ること
ができるので、好都合である。GRASのビジュアル・
オブジェクト網管理(MoVon=managemen
t of visual object networ
ks)モジュールおよびアクタ・フレーム(AF)モジ
ュールにより、アクタおよびアクタの作用を合併する機
構が提供されるため、利用者は、全体的に統合された仕
様を見ることが可能となる。GRASは、仕様の別個の
部分の統合および組み合わされた作用を見る便宜を利用
者に与えるので、好都合である。 【0019】プログラム用の仕様を対話的に生成する方
法は、キーボードやマウスなどの入力装置を介したアク
タ・データの受信に応じて、複数のテープ・シナリオに
対するアクタを指定すること、およびそのアクタ・デー
タを格納することからなる。アクタの指定には、新たな
アクタの生成、以前に生成されたアクタの選択、および
アクタ・データの修正が含まれる。システムは、入力装
置を介して作用ステップを受信すると、これに応じて、
そのステップを後の実行のために記録する。これらのス
テップは、アクタ間の通信、アクタ間の関係、アクタに
対する論理的または算術的な演算、および複数のテープ
・シナリオに対する判断点からなる。最初の判断の選択
を入力装置を介して受信すると、これに応じて指定の一
貫性を評価するために、最初のテープ・シナリオが実行
される。最初のテープ・シナリオの実行は、一組の所定
の条件の発生に基づいてシナリオのステップをシミュレ
ートし、そのシミュレーションの結果を記録することか
らなる。シミュレートすることは、アクタ間の関係の表
明、アクタ間の通信の実行、アクタに対する論理的また
は算術的な演算の実行、または判断による選択の入力の
要求のうちの1つまたはそれ以上からなる。最終的に、
判断の選択が入力装置を介して代わる代わる受信され、
それに応じて、追加のテープ・シナリオが順次実行され
る。 【0020】このシステムは、作用ステップのシミュレ
ーション中に入力装置を介して受信した命令に応じて、
指定された作用ステップの後にシミュレーションを停止
するようになっている。そして、入力データの受信に応
じて、追加のアクタ・データおよび追加の作用ステップ
をシステムが格納し、その追加のステップおよびアクタ
を含めて、シミュレーションが再開される。対話的に仕
様の追加を行い、それらの追加の結果を直ちに見ること
ができるので、好都合である。作用ステップは、シミュ
レーション中に逆進可能(「アンドゥ可能」)である。 復元(アンドゥ)されたステップは修正されて、シミュ
レーションが再開され、その復元されたステップは、修
正された内容で再びシミュレートされる。仕様の変更を
対話的に行い、その変更結果を直ちに見ることができる
ので、好都合である。 【0021】作用ステップをシミュレートすることは、
プログラム経路が指定されていない判断箇所の選択を自
動的に識別すること、これらの選択および不完全なプロ
グラム経路を利用者に通知することからなる。また、作
用ステップをシミュレートすることには、アクタ・デー
タが完全であるかどうかを確認し、不完全なデータを利
用者に知らせることも含まれる。このように、不完全な
仕様もシミュレートできるので都合がよい。本システム
では、複数の水準の表示が可能であり、各水準は、シミ
ュレーションの詳細水準に対応する。利用者は、各作用
ステップに対し、異なる水準集合を指定することができ
る。テープ・シナリオを実行する場合、GRASシステ
ムは、その集合の要素である水準にあるステップに限り
、その結果を表示するが、実際には、他の指定された水
準のすべてのステップをシミュレートしている。利用者
は、情報がさらに利用できるようになったときに、より
詳細なステップを仕様に追加し、それらのより詳細なス
テップのシミュレーション結果を見ることによって、仕
様を対話的に洗練することができるので、好都合である
。 【0022】GRASシステムでは、2つ以上の作用ス
テップを同時にシミュレートすることが許される。本発
明のシステムでは、同時に発生するプログラム経路の両
方に共通のアクタがある場合、その共通のアクタのデー
タにアクセスしようとする他のアクタどうしが、同じデ
ータを同時にアクセスしないことが保証される。本シス
テムでは、そのテープ・シナリオのあるステップのシミ
ュレーションを所定の時間だけ遅らせたり、または最初
の作用ステップシミュレーション時刻からシミュレーシ
ョン中に算出された時間だけ遅らせたり、あるいは最初
の作用ステップのシミュレーションを2番目の作用ステ
ップがシミュレートされるまで遅らせたりすることが可
能である。本システムでは、呼び出されたテープ・プロ
グラムを呼び出しているテープ・プログラムの実行の一
部として実行し、その呼び出されたテープ・プログラム
の実行に続いて、呼び出しているテープ・プログラムに
戻ることも可能である。また本システムでは、第1のテ
ープ・プログラムの第1の作用ステップのシミュレーシ
ョンの後と前記第1のテープ・プログラムの第2のステ
ップのシミュレーションの前との間に、第2のテープ・
プログラムの部分集合のコピーを挿入することも可能で
ある。作用ステップの同時シミュレーションによって、
システムの作用の現実的な考察が与えられる結果、首尾
一貫した仕様が生成され、好都合である。 【0023】 【実施例】仕様に関するグラフィカルな記憶および動画
(GRAS=Graphical Recording
and Animation of Specifi
cations)のシステムは、この種のシステムにと
って有用な特別な術語体系で記述された主要な概念に基
づく。これらの専門用語を理解することは、GRASシ
ステムの理解に役立つので、GRASで使用される特殊
な専門用語を以下において定義する。 【0024】重要用語集 バックステージ:所与の制作スタジオに所属する各アク
タ(役者の意)は、その特有のアドレス(例えば、出生
名と住所、社会保証番号)で分かる。一度に利用できる
全アクタの集合をバックステージ(舞台裏の意)と呼ぶ
。各アクタは、仮にそれが幾つかのテープで使用され、
そのGRASシステムで現在利用可能なテープの間で物
理的に共有されていても、この文脈においては、ただ1
つの存在でしかない。テープが録音される前かされてい
る間に、1つ以上のスタジオ室を選択することができる
。各スタジオ室は、異なる視野または眺望を記録するの
に使用でき、各スタジオは、記録カメラを持っている。 必要に応じて、記録の前か記録中に、アクタの選択/追
加が行われる。 【0025】フレーム:フレームは、情報の分類または
概念の組織化に使用される柔軟なデータ構造である。こ
のデータ構造の柔軟性は、フレームが通常、拡張可能か
つ再定義可能であると言う事実からきている。フレーム
・システムは、通常、IS−AまたはAKO(A−ki
nd−of)分類法に基づく階層的な継承機構を備えて
いる。 【0026】アクタ:アクタは、オブジェクトの拡張で
ある。オブジェクトは、データとそれを操作する手続き
(プロシージャ)からなる。アクタは、データを(スロ
ットと値を用いて)オブジェクトととしてカプセルに包
む。しかし、カプセル化された集合のスロットだけでな
く、それらのスロットの値も、時間と共に変化すること
ができ、これらの変化は、可逆的である。隠喩的観点か
らすれば、アクタは、情報の範疇および情報の値を記憶
したり忘れるだけでなく、その寿命期間内の特定の瞬間
にそれが持っていた情報を思い出すことも可能である。 この特徴を実現するために、アクタは、そのデータ空間
(スロットおよび値)に為された変更の履歴をとってい
る。アクタは、任意の時刻にその時点のデータ空間の記
号による記述を生成したり(自己記述)、2つの異なる
時刻における記号的データ空間の間の差の記号による記
述を生成したりすることができる。これらの記述内容は
、アクタ・システムの実施によって、履歴に維持される
。 【0027】アクタの実施:GRASに対しアクタを実
施することにより、次の可能性がサポートされる。アク
タの一般的な性質として、新たな役割を記憶し、前の役
割を忘れ、存在する情報を変形させ、新たな情報を獲得
し、他のアクタに情報を伝達し、(オプションで)種々
の衣装でいるのが見られる(可視的表現は、このような
アクタにあってもなくてもいい属性である)という能力
がある。アクタは、共有、再利用、合併、分割、幾つか
のアクタの組み合わせとしての生成、またはサブアクタ
への分解が可能である。論理的または算術的な演算に基
づいて、アクタの役割を特定の状況によって変更するこ
とができる。 【0028】アクタの知識ベース:蓄積(記憶)および
削除(忘却)が可能なアクタの属性の集合が、アクタの
動的で機密性の知識ベースを構成する。ここでは知識ベ
ースの機密性は、次の意味で定義される。即ち、知識は
、他のアクタと共有されておらず、他のアクタが直接利
用することはできない。あるアクタの情報を他のアクタ
が利用できるのは、他のアクタが処理中に明確にそれを
要求した場合に限られる。アクタの知識ベースは、アク
タの環境を用いて定義される。アクタのデータ空間の記
述D(A,t)の実現。 【0029】アクタと継承:アクタのフレームの記述に
用いられるAKO関係は、フレームの分類を与えるため
に内部的に使用される。しかし、GRASにおいては、
利用者がAKO関係を直接利用することはできない。ア
クタに関し利用できる操作(処理)の集合は、利用者が
多重継承を必要とすることなく通信のアクタ指向モデル
を設計するに十分である。GRASがアクタ・システム
によって半自動的に維持できるならば、継承がGRAS
の利用者に与えられるだけである。 【0030】アクタの合併および融合:アクタ・モデル
では、合併という概念とその実現とによって、さらに柔
軟性が提供される。次のようにいろいろな水準の合併が
可能である。 【0031】1)改名:アクタのステージ名を新たなス
テージ名で置き換え、そのアクタは同じ規則の集合を使
用する。ここで、ステージ名は、特定のシナリオの実行
において、このアクタを参照するために使用される名称
である。 【0032】2)アドレスの変更:アクタのアドレス(
識別情報)を変更する。新たなアドレスが既存のアクタ
のアドレスである場合、実際に合併が行われる。 【0033】3)合併:アクタAが既存のもう1つのア
クタBと合併される場合、合併の種類は、結果としての
新たなアクタCがB(属性と関係)になるものから、C
がAになったり、CがAおよびBの属性と関係との組み
合わせになるものまで、連続的に変化し得る。ただし、
何れの場合も、結果として得られるアクタCは、Aおよ
びBのすべての規則を継承している。これらの規則の適
用可能性は、Cの結果としての属性と前の規則との関数
である。全く適合しない規則ならば、それらを取り除い
ても良い。規則の管理の一部は、論理的分析および到達
可能性アルゴリズムに基づいて自動化することができる
。 【0034】4)融合:アクタが第2のアクタに完全に
加えられ融合する(C=A+B)。これは、完全な合併
の場合である。この結果は、その融合が起こる前に何れ
かのアクタが使用された場所ならどこでも使用される新
たなアクタである。従って、新たなアクタは、両方のア
クタのすべての規則を継承する。また、新たなアクタは
、両方のアクタからすべての関係および構成要素も継承
するという意味では「怪物」である。例えば、端末を普
通の旧式電話サービスの(POTS)電話と融合する場
合、結果として得られる「怪物」は、端末とPOTS電
話との両方の特徴を持った電話端末である。この「怪物
」は、POTS電話の特徴を持った端末とも、端末の特
徴を持ったPOTS電話とも解釈することができる。 この特徴は、新たな設計について実験を行う場合に役立
つ。 【0035】2つのアクタを合併することは、アクタと
それらの関係から成る2つのネットワークを合併するこ
とになる可能性がある。アクタのネットワーク(アクタ
網)は、関係によって接続された一群のアクタから成る
。例えば、アクタ網は、一種の(AKO=A−Kind
−Of)関係に基づくことができる。1つのアクタ網(
NA)が、一種の(A−Kind−Of)ドイツ人であ
るすべてのアクタから成ることもあれば、別のアクタ網
(NB)が、一種の(A−Kind−Of)フランス人
であるすべてのアクタから成ることもある。アクタAが
一種のドイツ人であり、かつアクタBが一種のフランス
人である場合、(NA)と(NB)との合併は、すべて
のドイツ人がフランス人になるか、すべてのフランス人
がドイツ人になるか、すべてのドイツ人およびフランス
人がフランス系ドイツ人、即ち両人種の組み合わせにな
るかの何れかになる可能性がある。 【0036】アクタに与えられる合併処理は、動的であ
り、利用者が実行時に呼び出すことができる。さらに、
アクタは、それ自体の属性および関係の変化を記憶する
能力を持っているので、アクタに関する他のすべての処
理と同様に、合併処理を元どうりにする機構(undo
)を実行することができる。 【0037】分解機構を与え、1つの複雑なアクタから
1組のさらに単純なアクタどうしの間の通信機構へと設
計の展開を助けるために、分割作用素を利用できるよう
にする。これは、伝達情報の送信または処理が最小単位
の処理であるから、特に重要である。分割により、伝達
情報をさらに小さな単位の処理へと分解する機構が与え
られる。 【0038】アクタとオブジェクト:アクタは、メッセ
ージ伝達方法を明確に定義されることがない代わりに、
属性および作用の記憶および忘却、伝達情報の送信およ
び処理、ならびに作用のシミュレーションを行う基本的
な方法を、そのアクタのクラスから継承する。はじめか
ら種々の(所定の)クラスから継承する代わりに、必要
に応じて新たな情報のスロットおよび値を追加なり、変
更なり、削除なりを行って、アクタを累進的に定義・洗
練することができる。比喩的に言えば、あるアクタの「
個性」、即ち一般的な作用は、前もっては分からないが
、このアクタが演じているすべてのテープから実験的観
察に基づいて集められる。アクタは、所定の組の作用に
関して、従来のオブジェクトのように独自に存在してい
るわけではなく、種々の作用がそれらのために利用でき
るようになる種々のシナリオを背景として存在するので
ある。 【0039】オーディション:所与の作業(タスク)を
行うアクタを選択するために用いられる処理(プロセス
)を指す。アクタは才能によって選択される。ここで、
才能は、アクタの属性(属性は、そのアクタの作用と直
接連絡している)とそのアクタおよび他のアクタの間の
現在の関係的依存状態の集合との関数として定義される
。オーディションの処理(audit)には、アクタの
要員の中から所与の作業を行う適任者を特定することが
伴う。 【0040】生成(creation):才能の記述に
従って新たなアクタを生成する処理である。新たなアク
タのデータ構造は、前記の記述に匹敵する内部の属性に
よって作られる。生成処理によって、アクタと関係から
成る集合(アクタ網)を生成する結果になることがある
。才能の記述が空の場合、最小のアクタのデータ構造が
生成される。アクタの才能の記述に特定のアクタのアド
レス(識別情報)が入っている、つまりアクタの才能の
記述の評価結果が特定のアクタのアドレスとなるならば
、そのアドレスにはアクタが既に存在し、そのアクタが
再利用される。 【0041】破壊:これは、アクタ要員アドレスからあ
るアクタのアドレスを削除し、その履歴を停止し、さら
にそのアクタのデータ構造、他のアクタとの関係および
(オプションで)現在見えている装置からそのアクタの
可視表示を削除する作用である。システムの実現状態の
よって、この処理が「ガーベジ・コレクション」(不要
になったデータの削除)を伴うことがあったり、なかっ
たりする。代用:アクタが作業を完成することができな
い場合、その代わりに代用アクタを選択することができ
る。代用は、オーディション処理を用いて行われる。 【0042】転送:2つのアクタがある場合、AからB
への転送は、AおよびBのそれぞれのアドレス(識別情
報)は維持しながら、すべての属性および関係をAから
Bに与えることになる。 【0043】クローン生成:アクタのクローン生成によ
り、元のもののすべての属性を持つ、そのアクタの新た
なインスタンスが作られる。クローンは、クローンと元
のアクタの何れか一方の属性の中の1つに変更が為され
るまでは(空間を節約するために)元のアクタと属性を
共有することができるが、変更されると、属性は物理的
に分離される。アクタ自体であるアクタの属性は別とし
て、最初は、デフォルトによって、すべての値が、元の
アクタとクローンとの間で共有される。例えば、システ
ムにおいて、あるアクタが2つの属性、即ち送受話器お
よび電話番号を持つ電話であると仮定する。すると、送
受話器もアクタとなり得る。この例において、送受話器
もアクタである場合、この電話をクローン生成すると、
クローンとオリジナル(元のアクタ)は、はじめ電話番
号の値を共有するが、同じ送受話器は共有しない。これ
は、クローンの送受話器の「属性」が新しいアクタだか
らである。値だけが、クローンとオリジナルとの間で共
有されるのであって、アクタは共有されない。 【0044】アクタをクローン生成すると、ある関係に
よって互いに接続されたアクタ網(例えば、1つのアク
タと、部分の関係(Part−Of relation
)にあるその幾つかの構成要素と)のクローンを生成す
ることがある。クローンはそのオリジナルとは異なった
アドレスを持つ。クローン生成は、(データが、変更さ
れるまでは再利用されるので)費用のかからないコピー
を作る機構である。 クローンの(オプションの)視覚的表現は、例示された
アクタの名称でのインスタンス番号の追加を除けば、オ
リジナルと同じである。 【0045】作用規則:ビデオ・スタジオの比喩(VS
M=Video Studio Metaphor)で
は、作用の規則は、(事実の独立した知識ベースとして
使用される)アクタの集合、これらの知識ベースの叙述
子の組み合わせ、アクタ間の通信メッセージの集合、お
よび計算と表明の集合を含めるための、前記の定義の拡
張である。アクタ集合Aについての作用規則Rは、次の
形式を用いて記述することができる。 R(A):f(P(A))=>M(A)=>g(Q(A
,M(A)))ただし、Aはアクタの集合であり、P(
A)はアクタに関する叙述子の集合であり、f(P(A
))は、これらの叙述子の関数(例えば、ブール表現)
であり、M(A)は、アクタ間の通信のオプションの集
合であり、Q(A,M(A))は、そのアクタの知識と
通信集合M(A)から得られる情報とに基づいて集合A
のアクタに対して行われる計算およびその結果としての
表明の集合であり、gは、規則R(A)の完成の尺度と
して用いられる合成関数(例えば、ブール表現)である
。ブール的仮定の下では、R(A)の実行が成功裏に終
了した場合、g(Q(A,M(A)))は、真でなけれ
ばならない。 【0046】R(A)の定義において、集合Aは、A=
a1、a2、....、のようにあからさまに(即ち、
列挙して)定義することも、抽象的に定義することも可
能である。Aが抽象的に定義される場合、規則R(A)
に対するアクタを特定する論理規則の集合A=Audi
t{X1,X2,...,Xn}を用いてAを記述する
ことができる。これらの論理規則によって、所与の役割
を演じるために各アクタに要求される特性{X1,X2
,...,Xn}を描写することができる。特性は、ア
クタの属性と値とで構成されたパタン一致表現でよい。 例えば、種類の検査、クラス依存状態の検査、接続種類
の検査(「a」と「b」との間にワイヤ接続がるか?)
、または値の照合(この局に800という電話番号があ
るか?)をアクタの特性に含めることができる。R(A
)に対する特性の集合によって記述される候補のアクタ
を特定するために、オーディション処理(audit)
が使用される。Aのアクタを記述する規則によって、新
たなアクタの生成、既存のアクタの再利用または組み合
わせを要求することができる。 【0047】OOスクリプト:センダ(sender)
のアクタとレシーバ(receiver)のアクタとの
間の単一処理を表すのに使用される特定のフォーマット
およびシンタックスを指す。OOスクリプトは、2つの
アクタの間の単一処理の特定のテキスト表現である。各
OOスクリプトを使用して、1つ乃至2つのアクタを伴
う作用の1つの規則を記述するすることができる。しか
し、OOスクリプトのシンタックスでは、アクタの記述
ができない。OOスクリプトの表現は、先に定義した作
用規則に対する正式な表現の部類に属する。GRASの
実施において、(推論エンジンによって維持される)内
部の規則構造と利用者(または外部のアプリケーション
・システム)との間のインタフェースをとる単純なテキ
スト・フォーマットを与えるために、例えば、OOスク
リプトのタプル(一定数の要素の集合)が用いられる。 【0048】役割:アクタの役割は、所与の状況におい
てそのアクタに適用されるすべての作用規則の集合であ
る。1つのアクタに対する各作用規則は、他のアクタと
の相互作用を必要とするため、アクタの作用を動的に変
更することが可能である。 【0049】VSMにおけるテープ テープ・プログラム:テープ・プログラムには、アクタ
の初期(およびオプション)の集合と、スクリプト規則
の集合またはアクタ間の作用規則を定義する一般スクリ
プトとが入っている。テープ・プログラムは、その実行
に必要なすべてのアクタを備えている場合、アクタ妥当
(actor correct)であると言う。同様に
、テープ・プログラムは、その実行に必要な作用規則を
備えている場合、規則妥当であると言い、その実行に必
要なテープ・プログラムへの参照情報をすべて備えてい
る場合、サブテープ妥当という。テープ・プログラムに
は、その実行に必要なすべてのアクタおよびすべての規
則(または他のテープ)が掲げられている。スクリプト
規則または一般スクリプトを用いて初期のアクタを生成
することができるので、テープ・プログラムは、初期の
アクタの空集合を持つこともある。 【0050】テープ・シナリオ:テープ・プログラムの
実行によって、1つ以上のテープ・シナリオが演出され
る。テープ・シナリオは、シナリオの変形に対応する元
のテープ・プログラムからの所与の集合のスクリプト規
則の実行履歴である。 【0051】テープ:テープを構成するのは、未来のリ
ール、即ちテープ・プログラムおよび(1つ以上の実行
済みのテープ・シナリオからなる)過去のリールと言う
2つのリール、テープ・カウンタ、初期アクタのオプシ
ョン集合、その視覚化に必要なオプションの多重視野の
記述、および参照と参考情報の利用に使用される追加的
な情報である。未来のリールは、利用可能な作用の集合
を表し、過去のリールは、そのテープの実行の履歴を表
す。過去のリールには、前に使用された規則のインスタ
ンス、それらの規則に関与したアクタの履歴が入ってい
る。テープ・カウンタは、そのテープ(過去のリール)
において既に実行されたステップ数に対する模擬計数(
または回数)を示す。テープが完全に巻き戻されると、
過去のリールは空になる、つまり実行の履歴が失われ、
未来のリールには、それまで得たすべての規則の集合が
入る。 【0052】テープのクラス:テープのクラスによって
、ビデオ・テープまたはフィルムの編集の類似性に基づ
いて半自動(支援付き)プログラム操作をサポートする
のに必要な計算体および作用素のクラスが規定される。 【0053】テープ・シェルフ:テープ・シェルフは、
テープの集合である。 【0054】伸縮可能テープ:テープは、スーパー8ム
ービーのように編集、切断および張り合わせができるの
で、何本かのテープを1本にまとめ組み合わせるだけで
なく、スクリプトおよび作用を容易に変更することもで
きる。テープは、特定の通信について新たな情報や詳細
をさらに受信するために、録音中に自動的に延長される
。また、GRASシステムによって生成されたり利用者
の入力に応じた追加的なスクリプト規則を2つの既存の
ものの間に挿入する余地を与えるために、テープは自動
的に延長される。テープの実現により、いろいろな詳細
水準での多重(各テープは、多重トラックを有する)録
音がサポートされる。VSMでは、録音によって既存の
スクリプトがテープから消去されるのではなく、新たな
スクリプトが既存のスクリプトの間に挿入される。スク
リプトの削除は、切断またはスクリプト規則を削除する
ためのメニュー選択(コマンド)によって行われる。 【0055】テープの切断:テープの切断は、現在の位
置(シミュレートされた時刻)で起こり、それ自体で有
効な2つのテープを生成する。テープを切断するには、
フィルム・エディタを選択する。切断後、これらのテー
プは、共にテープ・シェルフに格納される。テープは、
切断される前にコピーが取られる。テープを切断すると
一方の側に未来のリールを追加し、他方の側に過去のリ
ールを追加することによって、自動的に修復された2つ
の半分のテープが作られ、2つの新たな実行可能なテー
プが出来る。利用者は、新たな2つのテープを指名する
ように促される。 【0056】テープの接合:テープの接合は、2つ以上
のテープを一続きのテープに継ぎ合わせる。テープを接
合するには、フィルム・エディタを選択する。テープは
接合される前にコピーされ、第1のテープの過去のリー
ルおよび第2のテープの過去のリールは、解かれないな
くてもよい。次ぎに、第1のテープの最後が、他方のテ
ープの先頭に接合され、この処理の間に、2つの余った
リールは消滅する。 【0057】利用者は、2つ以上のテープを一緒に接合
することができる。いくつかのテープを接合すると、そ
れらのテープの内部表現は同一でも、順次シミュレーシ
ョン・モードで映されるテープは連続実行となり、同時
シミュレーション・モードでは並列実行となる。 【0058】テープの照会:テープの照会により、アク
タおよび伝達情報の部分的な記述が記録されたテープが
参照される。部分的な記述は、事前条件、事後条件およ
びメッセージに対するオーディション表現およびパタン
・マッチング表現とすることができる。スクリプト構造
体についてのパタン・マッチングによって所与の集合の
スクリプト規則から同様の伝達情報を検索するために、
テープの照会によるアクタ間の通信が使用される。 【0059】内部テープ呼び出し:現在のテープを実行
しながら、テープ・シェルフから直接テープ(サブテー
プ)を呼び出すこと。呼び出しは、現在のテープにおけ
るスクリプト規則に対する事後条件が契機となる。そし
て、現在のソフトコーダ(SOFTCODER)の状況
下で実行されるテープのインスタンスが生成される。現
在使用されているアクタ・システムは、設計者の裁量で
サブテープによって再利用されることもあれば、されな
いこともある。そのサブテープが、呼び出しているテー
プで使用されているアクタを特に参照する場合、このア
クタは再利用される。再帰的なテープ呼び出しは、現在
のテープの特別な例であるか、またはそれ自体を呼び出
しているサブテープの特別な例である。 【0060】テープ・コンパイラ:これは、編集および
ウンドゥの可能な損害に対するさらに効率的な実行を与
えるテープを定義するシステム規則の集合に関する処理
機構である。結果は、コンパイル(編集)されたテープ
である。テープ・コンパイラは、アクタのグラフィック
表現、ならびにそのテープ内のアクタ間の通信および接
続のグラフィカルな副作用を除去することにより、より
効率的な実行を与えることができる。また、テープ・コ
ンパイラは、最適化のためにテープのスクリプト規則の
集合を修正し、高速実行のためにスクリプト規則の前計
算されたラチスを生成する。 【0061】ビジュアルな照会:これは、照会を定式化
してテープ・シェルフから情報を検索するために設計さ
れた対話的かつビジュアルな処理の集合である。同様の
機構は、標準のテープの録音に使用されるビジュアルな
照会を定式化するのにも、テープの照会が生成されたの
ちテープ・シェルフからのテープの一部に照合されると
言う点を除いて、使用される。テープ・シェルフに適用
される照会結果は、対のリストを伴ったテープの順序集
合である。各対は、候補との一致の信頼値である数およ
びテープ・プログラムにおけるその候補のある位置への
ポインタからなる。ビジュアルな照会の結果として、利
用者は、候補との一致が成功した位置の付近の各テープ
のグラフィカルなシミュレーションを調べることができ
る。これは、設計情報の検索および既存のものから新た
な設計を組み立てるのに役立つ。 【0062】VSMにおけるアクタ VSMにおいて、アクタは、劇および映画の制作の場合
と同様の概念を表す。バックステージにあるアクタの要
員の中からアクタを利用することができる。アクタは、
必要に応じて(新たに)生成したり、前に生成したアク
タの要員から得たりする。アクタは、生活(存在)し、
演じ(上演し)、そして死ぬ(破壊される)。さらに、
アクタは、コンピュータの実体であるから、それらの複
写、再利用、合併、分離、および置換が可能である。あ
るスクリプトに対してアクタを大まかに定義することが
できるが、この場合のオーディション処理(audit
)は、適切な特性のアクタを要員から選択するように行
われる。ユーザの視点からすれば、アクタは、知識を蓄
え、それを利用し、さらに計算を行う非常に柔軟性のあ
る作用主体として見えなければならない。 【0063】アクタは、ゼロ、または1つ以上のテープ
の構成員であり得る。テープには、そのテープのシミュ
レーションから得られるシナリオにおいて演じるすべて
のアクタのアドレスが表として掲げてある。このリスト
は時間で変化する。VSMでは、テープは元来、例から
作られている。例によって作用が構成されると言うこと
は、テープの録音中に、アクタの特定のインスタンスが
生成されて使用されることを意味する。 【0064】スクリプトの構造 GRASシステムにおける作用の規則を実施するために
使用されるデータ構造は、つぎのような形式である。S
address=(Type,Sid,Group−S
address,Pre−Saddress,Post
−Saddress,Sender,Sundo,Re
ceiver,Rundo,Precondition
s,Message and Arduments,P
ostconditions,Documentati
on).スクリプトの引数は、次のように定義される。 【0065】「Saddress」は、所与のプロセッ
サにおけるスクリプト構造体のアドレスである。スクリ
プト構造体がいくつかの独立したプロセッサ上に分散し
ている場合、Saddressは、プロセッサのアドレ
スを与える接頭語(例えば、SaddressをPro
cAddress:Saddressとする)を持つこ
とができる。 【0066】「Type」は、Rule(規則)、Ge
neral(一般)、Instance(インスタンス
)、Group(グループ)、Wait(待機)、Un
doable(アンドゥ不能)、Sent(送信済み)
、Precessed(処理済み)などのスクリプトの
型の合法的な組み合わせである。この型は、スクリプト
の型の記述に従ってスクリプト構造体を処理するために
、推論エンジンによって使用される。Rule、Gen
eralおよびInstanceの各型は、Group
型と共に組み合わせることができる。Instance
型およびWait型は、Undoable型と組み合わ
せることができる。Instance型は、Sent型
またはProcessed型と組み合わせることができ
る。 【0067】Sid:これは、他のスクリプト構造体に
おける記号(シンボル)による参照および利用者への記
号表現に使用される識別子である。 【0068】Group−Saddress:スクリプ
ト構造体がグループ型である場合、そのグループの構成
員であるスクリプト構造体の集合を参照するのに使用さ
れる。 【0069】Pre−SaddressおよびPost
−Saddress:これらは、他のスクリプト構造体
へのSaddress(複数)の構造体である。それは
、特定のアーキテクチャに対するGRASの働きを高め
る効率的な実行機構の設計を支援するために使用される
。例えば、スクリプト構造体SのPre−Saddre
ssは、Sの実行の直前のスクリプト構造体のアドレス
であり、Post−Saddressは、Sの実行に直
に続くスクリプト構造体を示す。これによって、スクリ
プト構造体のいくつもの大きな集合の実行を効率的に実
施したり破棄したりするためのラチス構造が与えられる
。 【0070】SenderおよびReceiver:こ
れらは、このスクリプト構造体におけるセンダのアクタ
およびレシーバのアクタを参照する表現である。そのス
クリプトの型によって、この表現は、異なって解釈され
る。 【0071】SundoおよびRundo:これらは、
スクリプト構造体の実行によってセンダのアクタおよび
レシーバのアクタに対しそれぞれ行われた変更をすべて
復元するために必要とされる処理の集合を記述する表現
である。SundoおよびRundoは、Rule型お
よびGeneral型のスクリプト構造体に対しては、
空である。 【0072】Precondition(事前条件):
事前条件の表現は、関数と、現在のシミュレーション時
刻におけるスクリプトのアクタの属性に関する論理検査
との組み合わせ(例えば、ブール表現)である。センダ
のアクタおよびレシーバのアクタに基づく事前条件によ
って設計を簡単にすることは許されるが、好ましい方法
は、センダのアクタに関する事前条件およびレシーバの
アクタに関する事前条件を分離することである。レシー
バについての情報にアクセスするためには、まずレシー
バに要求を送る必要があり、その応答の結果を次の規則
の事前条件において使用しなければならない。アクタの
集合がスクリプトを実行している各プロセッサ上では、
必要であればクロックが利用でき、そして、そうならば
、スクリプト構造体の有限な実行履歴が維持される。こ
れらの仮定の下で、事前条件に時間従属関係を含めるこ
とができるが、これは、時間作用素および他のスクリプ
ト構造体の実行時間を用いて形成されたタイミング表現
である。タイミング表現は、スクリプト構造体の実行を
(それらに特有のスクリプト識別子に基づいて)指示す
るのに使用される。GRASの実現においては、シミュ
レートされた時間の強制は、OOスクリプトの表記に基
づく。 【0073】Message and Argumen
ts(メッセージと引数):「Message」は、セ
ンダのアクタとレシーバのアクタとの間で渡されるオプ
ションのメッセージのシンボル名である。メッセージは
、アクタ間で情報を伝達するために使用される。引数が
指定されるとき、引数は、センダのアクタからのデータ
に基づいて、任意のデータの集合または計算式から成る
。 【0074】Postconditions(事後条件
):属性の初期値に施された計算に基づいて、さらにレ
シーバのアクタの場合は、計算されたりそのレシーバに
渡されたメッセージを介して転送されたりしたデータに
基づいて、アクタの属性に対して行われた変更が、事後
条件の表現によって記述される。Postcondit
ionsは、センダのアクタに対する事後条件表現とレ
シーバのアクタに対する事後条件表現とに分解する方が
好ましい。 Documentation:スクリプト構造体の機能
の解説に使用されるフィールドである。ドキュメンテー
ションには、そのスクリプト構造体の全アクタおよびそ
れらの属性およびデータへのシンボルによる参照情報を
含めることができる。ドキュメンテーションは、少なく
ともテキストによる記述であるが、実現方法によっては
、グラフィックス、ビデオおよびオーディオを使用して
も良い。 【0075】事前条件において検査されるか、事後条件
において変更されるアクタの属性により、アクタの間の
関係(センダのアクタとレシーバのアクタとの間の関係
)を表すことができる。さらに、外界と共に入出力関数
を実行する項目(例えば、利用者に質問することなど)
は、事前条件、メッセージおよび事後条件において受け
付けられるが、事後条件以外では受け付けないことを推
奨する。事前条件はすべて並列的に検査され、メッセー
ジの属性はすべて並列的に通信され、事後条件は、すべ
て並列的に実行される。このため、アクタには並列的な
通信モデルが強いられる。連続的な実行が望ましい場合
には、別個のスクリプトと連続したスクリプトグループ
が用いられる。 【0076】スクリプトの型 スクリプト規則:Rule型のスクリプト構造体は、例
示されたセンダのアクタおよびレシーバのアクタを持た
ないが、代わりに、シンボル名または1つのアクタ・ア
ドレスに評価される表現を用いてアクタを参照する。こ
れは、生成、再利用、または多くとも1つのアクタ・ア
ドレスに戻るアクタ処理によって、行うことができる。 スクリプト規則は、実行されるスクリプトではないので
、維持するべきアンドゥ情報がないため、空のSund
oフィールドおよびRundoフィールドを有する。 【0077】一般スクリプト:一般(General)
型のスクリプト構造体では、そのアクタを指定するため
にオーディション表現を用いる。センダとレシーバは、
アクタ・アドレス(センダ・アドレスおよびレシーバ・
アドレス)の対の集合を生成する2つのオーディション
表現を指定する。一般スクリプトは、空のSundoフ
ィールドおよびRundoフィールドを有する。 【0078】スクリプト・インスタンス:インスタンス
型のスクリプト構造体は、スクリプト規則または一般ス
クリプトの例示によって生じる。スクリプト規則の場合
、センダおよびレシーバがそれらのアドレスによって特
定されると、センダのアクタおよびレシーバのアクタが
それらのアドレスによって置き換えられる場合、スクリ
プト・インスタンスが生成される。一般スクリプトの場
合、アクタ・アドレスの各対に対応してスクリプト・イ
ンスタンスの集合が生成される。スクリプト・インスタ
ンスは、実行されると空でないSundoおよびRun
doフィールドを有する。これらのフィールドには、ス
クリプト・インスタンスを一度実行することの影響を元
に戻すために終えなければならない処理が記述されてい
る。 【0079】スクリプト・グループ:スクリプト構造体
の集合を直接参照するスクリプト構造体である。例えば
、オーディション処理が1つ以上のアクタ対(例えば、
通信放送)を返す場合、一般スクリプトはグループ・ス
クリプトに例えることができる。並列実行のため、スク
リプト・インスタンスも推論エンジン(ソフトコーダ(
SOFTCODER))によって自動的にグループ化さ
れる。 スクリプト規則の実行を同じプロセッサにさせるために
グループを定義することも可能である。例示されたスク
リプト・グループは、空でないSundoフィールドお
よびRundoフィールドを有する。 【0080】待機スクリプト:シミュレートされた時間
の期間中に実行を遅らせるためにソフトコーダによって
生成されるスクリプト構造体である。これは、シミュレ
ーション時間のある期間中に実行可能なスクリプトが無
いこともあり得るので、必要である。例えば、送信され
るメッセージは、受信され処理される前に数単位分のシ
ミュレートされた時間を要することがある。また、メッ
セージが受信されても、後まで処理できなかったりする
。 【0081】アンドゥ不能スクリプト:実行が終了しか
つ逆に実行される(元通りにされる)べき必要なSun
doおよびRundo表現を持つ待機スクリプトまたは
スクリプト・インスタンスである。Sundo表現また
はRundo表現により、スクリプト・インスタンスが
最初に実行されたシミュレーション時刻以降に変更され
たすべてのスロットおよび値が、対応するアクタのデー
タ空間から削除される。スクリプト・インスタンスが実
行される前に存在していたスロットおよび値は、これに
よって回復される。 【0082】GRASシステムの説明 図1は、GRASシステムの概念的構造図である。ビデ
オ・スタジオ・メタファ(VSM)インタフェース・モ
ジュール100は、単一統合メタファの下でのシステム
設計およびシミュレーションの環境全体に対する簡単な
ユーザ・インタフェースと直接アクセスとを提供するた
めのソフトウェア・モジュールである。VSMにより、
利用者は、ビジュアル・プログラミング技法を用いてシ
ステム作用の例をテープ・シナリオへと記録し、さらに
グラフィカルな動画的シミュレーションおよび実行をと
おして指定されたシステムの作用の視覚的フィードバッ
クを維持しながら、それらの例をテープ・プログラムへ
と組み合わせかつ洗練させることができる。利用者は、
VSMにおけるビデオ・コネクタおよび種々のエディタ
(フィルム・エディタ)の使用によって、設計案の補足
、通信、編集、および結合を行うことができる。 【0083】また、VSMモジュールは、このシステム
の利用者に対し必要な仕事を行うために、より低い水準
の適切なGRASモジュールを呼び出すことができる。 ビジュアル・オブジェクト網管理(MoVon=Man
agementof Visual Object N
etworks)モジュール(MOVON)110、ソ
フトウェア・ビデオ・レコーダ(ソフトコーダ)モジュ
ール(SOFTCODER)120、およびビデオ・コ
ネクタ(VC)モジュール(VC)130から成る次の
水準のモジュールは、利用者に対し透過的である。VS
Mインタフェースは、双方向メッセージ・リンク(11
1、121、および131)を介して、これらのモジュ
ールと通信を行う。 【0084】ビジュアル・オブジェクト網管理(MoV
on)は、システムの構成要素および構成要素網の視覚
化を多重表示、多重階層、および多重詳細水準でサポー
トするアクタの実現である。ビジュアル・オブジェクト
網管理モジュール(MOVON)110は、その関数を
実行するために、アクタ・フレーム・モジュール(AF
)140、およびプレスクリプト・モジュール(PRE
SCRIPT)160を要請する。 【0085】ソフトコーダ・モジュール(SOFTCO
DER)120は、アクタの処理および通信を記録し、
かつシミュレートまたは実行するビジュアルな機構であ
る。ソフトコーダ・モジュール120により、単一また
は複合の画面上の対話によって供給される指定事項を記
録(入力)、再生(実行)およびアンドゥ(逆向きの実
行)を行う一般的な機構が提供される。これらの対話は
、情報の転送および計算を伴うアクタ間の通信を表す。 ソフトコーダのビジュアルな機構は、アクタ間の作用の
規則を記述するテープ・プログラムを処理し、アクタお
よび規則を例示し、さらにこのシステムの実行の完全な
軌跡であるテープ・シナリオを生成する。テープ・プロ
グラムにおける各実行段階において、1組の処理が実行
される。各段階は、それをアウドゥすることによって逆
戻りすることができる。 【0086】また、ソフトコーダのビジュアルな機構は
、アクタの通信および状態の変化をとらえ、シュミレー
トする。ソフトコーダは、録音中に、メニューによる視
覚的な対話(アクタの処理の記録)をとおして利用者に
よって与えられる特定の例からソフトウェア区分を一般
的な作用規則へと自動的にコード化する。各作用規則は
、利用者からの入力と対話する専用のソフトウェア・ル
ーチン群によって対話的に洗練され(特殊効果)、別の
状態を記録する場合には、再利用および変更を容易に行
うことができる。 【0087】各段階の連続的な実行により、その例が、
入力されたとおりに再生される。その例によって記述さ
れた作用は、作用をすべて予め確かめられる状態で記述
するプログラムへと対話的に洗練される。作用のアクタ
および規則は、アクタの状態、通信中に実行された計算
および交わされた情報に関する他の情報を変更したり、
削除したり、あるいは追加したりするために、いつでも
編集することができる。利用者の裁量によって、アクタ
の状態およびグラフィカルな表現の変更は、永久的にも
一時的にもなる(反転可能)。結果的に得られる規則は
、実際にテープ・プログラムを形成する。 【0088】ビデオ・コネクタ・モジュール(VC)1
30は、利用者にプログラム対話、編集、ならびにファ
イル・システムおよびGRASの外部の他のシステムへ
の接続のための機構を利用者に提供する。モジュール1
30は、ソフトコーダによって使用される内部テープ表
現のための一般的な変換および通信の機構である。モジ
ュール130は、利用者による読み出しおよび編集、ま
たは外部システムとの通信のうち何れかが可能なテキス
ト形式でテープ、アクタおよびスクリプトを示すのに使
用される。モジュール130により、GRASとファイ
ル・システムとの間の双方向接続機構、およびGRAS
と外部システムとの間の双方向接続が提供される。提供
されるコネクタの例としては、OOスクリプト、メッセ
ージ、テープ、アクタ(オブジェクト)、スクリプト、
およびアイコンがある。ビデオ・コネクタを介して外部
のシステムに接続されると、外部のシステムは、GRA
Sの実行を遠隔制御できるだけでなく、GRASを調べ
ることができる。 【0089】プレスクリプトは、GRASの一部で、ア
クタおよび伝達情報の表示およびアニメーションのため
のグラフィカルなプログラミング言語である。プレスク
リプト・モジュール160は、アクタの視覚的な表現を
担う。アクタ(アクタ=視覚的なオブジェクト+フレー
ム+作用)を定義するために、視覚的なオブジェクトは
フレーム表現に関係付けられる。視覚的なオブジェクト
はコンピュータ端末上に表示される。視覚的なオブジェ
クトは、他の視覚的なオブジェクトと合併することがで
き、シナリオ(またはシナリオの集合)を定義するテー
プの構成員であるだけでなく、テープ・フレームの構成
員でもある。プレスクリプト・モジュール160は、O
S175によって与えられるウィンドウおよびグラフィ
ックの諸機能(WG)170を利用する。 【0090】アクタ・フレーム・モジュール(AF)1
40は、フレームおよびアクタの知識の時間的履歴を支
持する知識表現および記憶の機構である。アクタ・フレ
ームは、フレーム・オブジェクト言語および実行環境(
FOLIE)に基づく。FOLIEは、GRASシステ
ムの一部であり、フレーム・ベースの分離(分散)およ
び分散された部分集合からの合併によるフレーム・ベー
スの再構築、多数の階層およびローカル・クラス優先リ
スト、および多数の階層におけるメッセージの放送をサ
ポートするフレーム表現言語である。放送されたメッセ
ージが、方法、関数、手続き、またはコンパイルあるい
は変換された形式のラムダ表現への参照情報から成る場
合、それは、少なくとも1つの関数引数と共に、その階
層における現在のフレームと称する。ラムダ表現は、必
要な引数(例えば、現在のフレーム)と共にそれが呼び
出されると仮定した場合、その実行に必要なすべての環
境変数を備えた、独立型のコンピュータのコード・セグ
メントである。 【0091】GRASシステムにおいて、テープの実行
機構は、アクタの動的な属性に基づく。テープの編集処
理は、アクタの静的な属性と動的な属性との組み合わせ
に影響を与える。静的な編集の柔軟性は、アクタ・フレ
ーム・モジュール140の一部であるFOLIEモジュ
ールによってサポートされる。FOLIEモジュールは
、次の関数からなる。即ち、(1)シンボルによる自己
記述:伸長性で型指定が無く、フレーム集合のシンボル
による自己記述は順序依存的であり、フレーム間のすべ
ての依存関係は2重リンクを用いて自動的に維持され、
そのフレーム要素からのフレーム集合の定義は、任意の
順序で行うことができる。(2)多元的継承:フレーム
がそのすべての母体から性質の統一体(集合)を受け継
ぐことができる。(3)継承の多重階層性:フレームは
、AKO階層、PART−OF階層、またはその化の任
意の関係から、性質を継承することができる。 (4)所与の階層のフレームに対する母体の順序集合か
ら成るローカル・クラス優先リスト(LCPL):多重
階層性により、多数のLCPLがもたらされる。(5)
フレームの放送:所与の階層のすべてのローカル・クラ
ス優先構成員に作用素を放送(一斉送信)することがで
きる。(6)フレーム網の統合:他のフレームとの関係
のネットワークの内部でフレームが定義される。各フレ
ームは、自己記述的である、即ち、フレームは他のフレ
ームとの関係網をシンボル的に記述する。他のフレーム
がない場合でもフレームの統合が可能である。(7)フ
レーム網の合併:フレームのオブジェクトを共有する2
つのフレーム網は、同一のシステムの中でリンク(ロー
ド)されると、自動的に合併される。(8)再利用、結
合、上書きおよび忘却という4種類の合併の原型を備え
たフレームの合併。(9)フレームの転送:これにより
、フレーム網の一貫性を維持しながら、フレームを他の
フレームによって全体的に(グローバルに)置換するこ
とが可能となる。交換用のフレームが既に存在する場合
、転送は、合併によって行われる。この機能により、ア
クタの交換およびアクタの合併に対する支持が与えられ
る。 【0092】ウィンドウおよびグラフィックス・システ
ムのモジュール(WG)170(商業的に入手可能なX
Window SystemTM、SunViewT
M、シンボリックス(Symbolics)社のGEN
ERA(登録商標)のウィンドウと類似)により、GR
ASに視覚的な能力が与えられる。Common Li
sp(CL)180は、ANSI X3J13委員会(
準備中のCommon Lispのための全米規格)の
仕様に従うCommon Lisp言語を実現したもの
である。GRASでは、実行可能なサイズを小さくする
ために、CLのサブセットが用いられる。CLのサブセ
ットは、GRASを実行するのに必要なLisp関数の
みから成り、GRAS全体のコードを調べ、そのコード
において参照されたすべての関数を集めることによって
生成されている。その他のコンピュータ言語でも、AN
SI仕様による定義と類似の機能を与える限り、CLと
置き換えることができる。 【0093】オペレーティング・システム(OS)17
5は、コンピュータのオペレーティング・システムであ
り、(オプションにより)統合化された環境(例えば、
UNIX(登録商標)、シンボリックス社のGENER
A(登録商標))である。UNIXは、AT&Tの登録
商標である。GENERAは、シンボリックス社の登録
商標である。OSは、次の構成要素の実行の制御および
維持を行う。即ち、WG(170)、CL(180)、
FS(185)およびNW(186)である。 【0094】ファイル・システム(FS)185は、静
的なデータ記憶および検索のためのアクセス機構を実現
する構成要素である。これは、UNIXのファイル・シ
ステムを基にしている。 【0095】ハードウェア(HW)176は、データ(
シンボル、オブジェクト、データーベース)を操作し、
論理演算および算術計算を行う1つ以上のプロセッサ、
およびデータの記憶および検索に使用される1つ以上の
記憶用の機構および装置から成る(記憶装置は、静的な
ものや動的なものがあり、シーケンシャル・アクセスで
あったり、ランダム・アクセスであったりする)。 ハードウェアの必要条件は、ここで定義されるGRAS
のすべての構成要素の実行を支持するに十分なデータ記
憶装置および処理能力を与えることである。GRASの
実現および頒布のために適切であると分かった現在入手
可能なコンピュータ・ハードウェアには、次のものがあ
る。AT&Tの6386WGS、AT&Tのグラフィッ
クス端末またはX Window端末を付けた他のUN
IXコンピュータ・メインフレーム、サン・マイクロシ
ステムズのSun−3およびSun−4シリーズ、イン
テル80386ベースのパーソナル・コンピュータ、シ
ンボリックスの3600(登録商標)およびXLシリー
ズ、ゼロックス1100シリーズ、テキサス・インスツ
ルメンツExplorers(登録商標)、およびデジ
タル・エクイップメント・コーポレーションのDEC2
000および3000シリーズ。 【0096】(オプションの)ネットワーク(NW)1
86は、VSMベースのシステムの集合の間でデータ通
信を提供するために、HW構成要素と共に利用できるか
、またはそれに付け加えて利用できるハードウェアおよ
びソフトウェアの要素を備えている。現在利用可能で適
切なネットワーク技術には、モデム付きの電話回線、イ
ーサネット、AT&T STARLAN、広帯域パケッ
ト網がある。ネットワーク要素は、VSCデータを電気
的に伝達する(例えば、テープ・プログラムを離れた場
所で利用する)ために必要とされるに過ぎない。 【0097】図1に示したように、VSMモジュール1
00は、MOVON、ソフトコーダおよびVCへ双方向
の接続を持っている。(VSMからの)直接の接続は、
1)アクタおよびアクタ処理(MOVON)、2)スク
リプトおよびテープ・プログラムの視覚的な記録、洗練
、およびシミュレーション(ソフトコーダ)、ならびに
3)外部のテープ・プログラムだけでなくテキスト形式
のテープ・プログラムの編集(VC)、に対する利用者
の制御およびアクセスを表す。VCと外部のシステムと
の間に存在する(オプションの実行時の)双方向接続は
、図には表していない。(MOVON、ソフトコーダま
たはVCから)VSMへの接続は、ユーザ・インタフェ
ースの表示へのビジュアルなフィードバックおよびテキ
ストのフィードバックを意味し、表示画面上の1つ以上
の視覚表現に変化をもたらす。このフィードバック・ル
ープは、実際にはMOVON−PRESCRIPT−W
Gを通る共通経路によって実現され、すべてのグラフィ
カルな変化は、アクタの視覚的表現に対する変化として
実現される。また、VSMは、利用者によって制御され
る指示装置およびキーボード装置にWG経由で接続され
る。VSMモジュールは、図示されていない利用者から
直接の入力を受信する。同じ入力をVC遠隔制御機能に
よって外部のシステムから受信することも可能である。 ソフトコーダおよびVCは、スクリプト、テープ・プロ
グラム、およびテープ・シナリオのほか、ソフトコーダ
制御コマンド(例えば、テープのロード、テープの削除
、詳細水準の変更、ビューの変更など)も送信する。M
OVONおよびソフトコーダは、アクタおよびアクタの
内容を送る。MOVONは、PRESCRIPTにアク
タのビジュアル・オブジェクトを要求し、AFにアクタ
・フレームを要求することができる。VCは、FSおよ
び外部システムへの接続をCLおよびFSまたはNWを
介して要求することができる。PRESCRIPTは、
WGを介して表示の変更を求めることができ、CLを介
してプリスクリプト・オブジェクトの割り当てを(また
は再生をオプションで)要求することができる。 AFは、CLを介してフレーム、スクリプトおよびテー
プの構造体の割り当てを(または再生をオプションで)
要求することができる。CLは、OSおよびFSを介し
てHWにコンピュータ・オブジェクトの割り当ておよび
再生を要求することができる。 【0098】MOVON、ソフトコーダ、VC、および
概念構造のその他の構成要素の間の接続をさらに説明す
るために、VSMの言語を使用することができる。テー
プ・プログラムをビデオ店から借りると(VSMによる
利用者の要求)、VCは、CLを介してFSまたはNW
への接続を開き、ソフトコーダは、その開かれた接続か
らの入力をテープ・シェルフ(VSM)の上に置かれた
テープ・プログラムへと記録する。テープがソフトコー
ダにロードされる(VSMコマンド)と、ソフトコーダ
は、アクタを要求し、MOVONからのビューを表示し
た後、ソフトコーダは、適切な実行アルゴリズムを呼び
出す。ソフトコーダがそのテープ・プログラムからスク
リプトを実行するにともない、1)AFによって時間的
履歴において制御され、かつ2)MOVON−PRES
CRIPT−WGを介してアクタの視覚的表現(例えば
、アニメーション)に影響を及ぼし得るアクタに変更が
指示される。変更、または実行選択肢を試行のために利
用者が実行を休止すると、変更が、スクリプトの変更お
よびアクタの変更に翻訳されてMOVONおよびAFに
伝えられ、そこにおいて、それらの変化は一時的または
永久に組み込まれる。アクタおよびスクリプトに対する
変更は、ソフトコーダがそれらの変更を実施し、それら
をMOVONを介して伝達すると、直ちに見ることがで
きる。 【0099】ビデオ・スタジオ・メタファにおいて、例
としてのシナリオが対話的にテープに記録される。シナ
リオ例は、既存のシステムまたは設計予定のシステムに
対する一連の作用を指定するために使用される。新たな
条件に対するシステムの作用の新しい面を取り入れ、す
べての許容可能な条件のためにテープ・プログラムへと
発展させるために、テープ・シナリオが対話的に洗練さ
れる。十分に洗練した後、テープ・プログラムにより、
表されたシステムまたは設計中のシステムの完全なシミ
ュレーションが与えられる。テープ(シナリオまたはプ
ログラム)には、アクタの集合、アクタ間の作用および
通信を記述する規則の集合が入る。アクタは、規則の実
行によって駆動される通信活動および処理活動に関与す
る処理主体である。アクタは、規則の実行に使用される
独立した知識ベースを備えている。規則は、アクタの知
識ベースに関する事前条件、アクタ間の通信、および通
信とアクタの知識ベースへの表明とからなる事後処理を
含んでいる。 【0100】アクタ・フレーム・モジュールフレームの
概念構造により、利用者は、「ロード」および「接合」
により2つの独立したテープを統合することができる。 アクタおよび規則を共有する2つのテープは、それらを
1つの環境にロードし、テープの接合および編集を適用
することによって統合することができる。役割および関
数を共有してもアクタの識別情報が一致しない2つのテ
ープは、アクタの移転(アクタの交換を選択する)およ
び前記のステップを実行することによって、合併するこ
とができる。同じ特徴の仕様を持つ断片部品を組み立て
てみれば、前記のような環境に統合のための独特なコン
ピュータ支援があることが分かる。 【0101】テープの編集および合併に付いての柔軟性
は、フレーム表現言語(FOLIE)、ビジュアル・オ
ブジェクト網管理(MOVON)、およびアクタの規則
に基ずく作用の定義に用いられる基礎的なスクリプト言
語(例えば、OOスクリプト)と言う3つの要素の統合
からくるものである。フレームの合併により、テープお
よび(または)アクタのスロット、値および関係(例え
ば、継承、構成員関係)の合併がサポートされる。フレ
ームまたはそれらの関係の集合が、ノードがフレームを
表し弧が関係を表すようなグラフによって表される場合
、そのような2つのフレーム集合を合併することは、か
くグラフのノードを合併し、合併したグラフのノード間
で弧を(合併の型に応じて)追加したり削除したりする
ことによって、それらのグラフを構成するに等しい。 アクタの交換処理は、オブジェクト指向言語における「
become」の拡張として見ることができるが、これ
を用いて、あるアクタを他のものに替えたり、交換先が
既存のアクタである場合には、2つのアクタを合併した
りすることが可能である。ビジュアル・オブジェクトの
合併により、システムの構成要素の統合、即ち、スロッ
ト値、さらにグラフィックスの属性として定義される状
態の合併がサポートされる。規則に基づくテープ・プロ
グラムの実行は、規則集合の結合を行うことにより種々
のテープからアクタの作用の統合をサポートする。標準
のプログラミング言語における関数、オブジェクト、ま
たは命令の集合の結合によるプログラムの結合によって
、通常は、有用なまたは有意義な結果を生じることはな
い。なぜなら、プログラムの各命令の実行は、他の周囲
のプログラム命令によって定義される外部の暗黙の制御
フローによって条件付けられるからである。しかし、ス
クリプト規則、一般スクリプトおよび関係するアクタの
集合結合によるテープ・プログラムの結合は、結合され
ているテープからの機能性の追加を、次のような少なく
とも2つの利点を伴って、もたらし得る。第1に、テー
プ・プログラムの各「命令」は、アクタまたはアクタの
記述、実行条件および結果としての処理および通信(メ
ッセージ)から成るスクリプト規則または一般スクリプ
トであり、従って、自立したプログラム命令である。第
2に、結合されている異なるテープ・プログラムからの
2つのスクリプト規則が、一致しない場合、この矛盾は
、明確に定義されている型であり、1)それらの規則が
意味論的に矛盾するか、2)両方の規則が同一のアクタ
・スロットを同時に更新しようとする状態が存在するか
、または3)1つ以上の規則が到達不可能であるかの何
れかである。最初の2つの矛盾の場合は、結合されたテ
ープ・プログラムの実行のアニメーションまたはシミュ
レーションの間に視覚的に現れる。第2および第3の矛
盾の場合も、結合された規則集合の静的な分析を用いて
検出することができる。 【0102】GRASにおいて、FOLIE、MOVO
N、および内部のスクリプト構造体(例えば、OOスク
リプト)を結合する根元的な知識表現は、上述の合併処
理(規則集合の結合によるフレーム・グラフの合併およ
び作用の統合)に内部的に基づく仕様の独特な柔軟性を
備えている。 【0103】VSMのためのデータの記憶および検索を
サポートする基本的な知識表現は、GRASのアクタ・
フレーム要素によって与えられる。AFは、アクタ間の
通信スクリプトの可逆的な実行のために必要な時間履歴
機構を提供するもので、根元的なフレーム表現言語FO
LIEの上に構築されている。AFにより、アクタへの
通信またはアクタからの通信によりフレームの属性また
は関係が変化する度にそのアクタ・フレームのローカル
・スナップ・ショットを記録しておくことにより、(前
に形式化された)アクタに必要な時間履歴機構が与えら
れる。この時間履歴の他に、GRASの実現に必要とさ
れるAFのすべての特徴は、FOLIEの直接的な特徴
である。 【0104】VSMにおけるテープの実行機構は、アク
タの動的な属性の記録および復活(読み出し)に基づく
。前記のテープ編集処理は、アクタの動的な属性と静的
な属性との組み合わせに影響を及ぼす。変更および編集
の実施は、根底にあるフレーム表現言語FOLIEによ
って直接サポートされる。動的な変更の実施は、FOL
IEの特性とアクタに関連したフレームの属性のスナッ
プ・ショットを記録・復活できる履歴機構との組み合わ
せによって与えられる。アクタの静的属性および動的属
性に関して必要な処理をサポートするFOLIEフレー
ム言語の重要な特徴を以下に述べる。 【0105】シンボリック自己記述:フレームは、それ
が定義されているコンピュータ環境とは独立したシンボ
ルによる記述フォーマットを用いて「それ自体をプリン
トする」ことができる。自己記述フォーマットは伸縮性
があり、フレームが変化すると、その変化を取り込むた
めに、同じフォーマットが、延長されたり短縮された形
式で使用される。コンピュータに依存できるフォーマッ
トならば型の特殊性はない。フレーム集合のシンボルに
よる自己記述は、順序に依存しない。フレームの集合{
f1,f2,...,fn}が与えられた場合、このフ
レーム集合の自己記述を任意の順序で記録し、同等のフ
レーム集合を生成するために、GRASシステムの別の
場合に異なる順序でそれらを復活させることが可能であ
る。 【0106】2重リンク:フレーム間のすべての関係は
、2重リンクを用いて維持され、2重リンクの半分を記
録することは、2重リンクの全体を記録すること同じで
ある。この性質により、フレーム集合の自己記述の順序
独立性がサポートされる。 【0107】フレーム網:フレームは、他のフレームと
の関係のネットワークと解釈することができる。各フレ
ームは、他のフレームとの関係網をシンボルによって記
述し、他のフレームが無くなると、フレームの統合が可
能となる。従って、フレームの不完全なネットワークを
記録・復活しても差し支えない。それがフレームの集合
F={f1,f2,...,fn}である。ここで、F
の要素fiは、Fの要素でないfjを参照する。 【0108】継承の多重階層:フレームは、所与のフレ
ーム階層におけるすべての母体から属性と関係の統一体
(集合)を継承することができる。多重継承は、他のフ
レーム言語およびオブジェクト指向言語についても一般
に利用可能であるが、多重階層による多重継承は、FO
LIEの新奇な特徴である。フレームは、AKO階層、
PART−OF階層、またはGRASにおいて定義され
たその他の関係から、特性を継承する。それぞれの双対
関係によって、それ自体のフレームの階層が定義される
。 【0109】ローカル・クラス優先リスト(LCPL)
:これによって、所与の階層におけるフレームに対する
母体の順序集合が構成される。多重階層によって多数の
LCPLに備えている。 【0110】フレームの放送:作用素または関数を放送
して、それを所与の階層におけるLCPLのすべての要
素に適用することができる。 【0111】フレームの合併:これは、フレームに格納
された情報の結合および再利用するための機構である。 4つの基本的な合併の原型、即ち再利用、結合、上書き
、および忘却によって、いくつかのフレームを合併する
ことができる。2つのフレームf1およびf2を合併し
て、フレームf(1+2)を構成する場合、以下のとお
りである。 1)再利用:f(1+2)は、f1に優先してf1およ
びf2から継承する。f1の属性および関係が残り、f
2からの重複しない属性と関係が追加される。 2)結合:f(1+2)は、f1およびf2から同等に
継承する。f1およびf2からの属性および関係が、統
一集合としてf(1+2)に格納される。 3)上書き:f(1+2)は、f2に優先してf1およ
びf2から継承する。これは、f2とf1との間の再利
用を伴った合併と同じである。 4)忘却:f(1+2)=f2 合併されたフレーム
は、元のフレームf2によって置き換えられる。 【0112】フレームの転送:これは、フレーム網の一
貫性を維持しながらフレームをもう1つのフレームで全
体的に置き換えることにより、現存の2重リンクを維持
することに備えるものである。交換フレームが既に存在
する場合、転送は、合併によって行われる。この特徴に
より、アクタの交換、先に述べたクローン生成および合
併が直接サポートされる。 【0113】フレーム網の合併:共通のフレームを共有
する2つのフレーム網は、同一のVSMベースのシステ
ムにおいて復活されると、自動的に合併される。 【0114】GRASにおけるテープの編集および合併
に付いての柔軟性は、概念構造の次の3つの主な構成要
素の間の相互作用から生じるものである。即ち、時間履
歴を統合したフレーム表現言語(AFおよびFOLIE
)、ビジュアル・オブジェクト網管理(MOVON)、
およびアクタの規則に基ずく作用を表すのに用いられる
スクリプト構造体の根底にある特性(ソフトコーダ)で
ある。次の例により、これらのソフトウェア構成要素の
統合を説明する。 【0115】1)フレームの合併により、テープ、アク
タおよび関係(例えば、継承、構成員、副構成要素)の
静的または動的な合併がサポートされる。各グラフが、
アクタの作用を記述するスクリプト構造体にテープ結合
され、アクタに結合され、副構成要素のアクタへと結合
されると言うような場合、この型の合併は、グラフの合
併に等しい。 【0116】2)一般的なアクタ交換処理によって、ア
クタを新しいものと交換したり、2つ以上の既存のアク
タを合併できる。これはアクタの交換、クローン生成を
可能とし、新たな設計構成要素についての利用者の実験
をサポートする。 【0117】3)ビジュアル・オブジェクトの合併は、
システムの構成要素およびそれらのグラフィック表現の
統合をサポートし、交換、クローン生成、または合併が
発生した場合に利用者に対して直接的かつ視覚的なフィ
ードバックを与える。 4)スクリプト構造体およびソフトコーダによるそれら
の実行によって与えられるようなアクタの間の規則ベー
スの通信によって、規則集合の統一を行うことによる多
数のテープ・プログラムからの特徴および構成要素の統
合がサポートされる。 【0118】GRASにおいては、AF、MOVON、
およびソフトコーダを結合する根元的な知識表現によっ
て、システム設計に関する使用および実験の新奇な柔軟
性が提供される。既存の設計と新たな設計のシミュレー
ション、結合および分析を非常にとりつき易くユーザ・
フレンドリに行うことが可能である。使用の柔軟性は、
AF、MOVON、およびソフトコーダと言うGRAS
概念構造の3つの基本的な構成要素の統合によって与え
られる作用規則の合併および統合のような処理に対する
独自の半自動化された支援の結果である。 【0119】FOLIE 次に、フレーム・オブジェクト言語および実行環境(F
OLIE)を説明する。明確になるよう、FOLIEを
定義するために、ここではCommon Lisp(1
984年デジタル・プレス社刊のG.L.スチール(S
teele)二世による「CommonLisp ザ・
言語(Common Lisp the Langua
ge)」)を改良したLisp風のシンタックス(構文
法)を用い、いくつかの例を掲げる。ここで定義するF
OLIE作用素は、Common LispおよびCo
mmon Lispオブジェクト・システム仕様(CL
OS)(1987年D.ボブロウ(Bobrow)によ
るゼロックス・ドキュメント87−002「CLOS」
、および在ニュー・ヨークのアヂソン・ウェスレイ(A
ddison Wesley)社1989年刊のS.E
.キーネ(Keene)による「Common Lis
pによるオブジェクト指向プログラミング CLOS
へのプログラマーズ・ガイド(Object−Orie
nted Programming in Commo
n Lisp, A Programmer’s Gu
ide to CLOS)」)に類似した命名規約によ
って命名する。FOLIEにおけるローカル・クラス優
先リストの定義は、CLOSにおけるクラス優先リスト
の定義から行われたものである。 【0120】1)表記および定義 FUN1(ARG1 ARG2)を2つの引数ARG
1およびARG2の関数であるFUN1の宣言とする。 「&optional」はオプションの引数を宣言し、
「&rest」は関数の残りのすべての引数の集まりを
宣言するものとする。「&optional(DEPT
H 0)」は、デフォルト値0を有するDEPTHと
命名されたオプションの引数に対する宣言であるとする
。 (FUN1 ARG1 ARG2)は、引数ARG
1およびARG2を付けた関数FUN1の呼び出しを表
す関数コール表現とする。引数は、埋め込まれた関数コ
ールを表して、それ自体が関数コール表現となり得る。 ::=は、「結合」記号とする。従って、VAR::=
(FUN1 ARG1ARG2)は、VARが、その
関数コールの結果に結合されることを示す。=は、「定
義により等号」とする。−>は、「戻り値」の記号とす
る。例えば、V1::=123ならば、V1−>123
である。Fは、唯一のLispオブジェクト(例えば、
ある記号)によって識別される任意のフレーム・オブジ
ェクトとする。FBは、任意のフレーム・ベースである
ものとする。ただし、FBは、フレーム・オブジェクト
の集合からなる構造体である。MFB(マルチプル・フ
レーム・ベース)は、FOLIEで定義された一般型(
一般のクラス)のフレーム・ベース・オブジェクトであ
るものとする。NXは、n個のスロット列NX=(X1
X2...Xn)であり、X=XiはNXにおけるス
ロットであり、BNXiはXiより前のNXの部分数列
であり、ANBiはXiより後のNXの部分数列である
ものとする(ANXiまたはBNXiまたは両者は、空
の数列()である可能性もある)。従って、NX=BN
Xi|(Xi)|ANXiとなる。ただし、|は数列の
連結を表す。 【0121】2)フレーム・ベースの生成MFB(&r
est F−set) これは、Fフレーム・オブジ
ェクトの集まりである簡単なフレーム・ベースを生成す
る。 例:(MFB F1 F2 F3)−>(F1...F
2...F3...) これは、そのフレーム・ベー
スがF1、F2およびF3を含むことを示す。 【0122】3)多数のフレーム・ベースの生成MAK
E−MFB(&optional FB F NX−s
et(MERGE−TYPE:COMBINE))
これは、フレームおよびフレーム・ベースの生成および
合併である。ここで、引数はすべてオプションであり、
NX−setは集合NX(一連のNX)であり、MER
GE−TYPEは以前に定義したような(:REUSE
:COMBINE:OVERWRITE)のうちの1つ
であり、MERGE−TYPEのデフォルト値は:CO
MBINEである。 例:FB::=(MAKE−MFB) これは、空の
フレーム・ベースを生成する。(MAKE−MFB F
B F) これは、フレーム・ベースFBに空のフレ
ームFを追加する。(MAKE−MFB FB F (
NX1...NXp)) これは、スロット列(NX
1...NXp)の集合を備えたフレームFをFBに追
加する。Fが既にFBの要素である場合、(NX1..
.NXp)は、既存のフレームFとの結合によって合併
される。(MAKE−MFB FB F (NX’1.
..NX’p):FORGET) これは、フレーム
Fの既存の定義を新しいもので置き換える。 【0123】4)アクセサとアサータ GETMFB(&OPTIONAL FB F &re
st NX)は、FBにおけるフレームFのNXスロッ
トの記述にアクセスする。GETMFB(&OPTIO
NAL FB F &rest NX)::=VALU
Eは、フレームFに対するNX位置においてVALUE
を加える。値として空の数列()を加えることは、Fに
おける位置NXにおける現在の値フレームを削除するこ
とと同じである。GETMFBの値として真のフレーム
文Tを加えることは、FにおけるNXを表明することに
等しい。なお、VALUEが()でない場合、所与の値
(値フレーム)を含むローカル・フレームを生成するこ
とによってVALUEがFに加えられること、ならびに
値の「追加」は合併によって行われることに注意を要す
る。従って、FOLIEにおいては、フレーム・ベース
は、その各副構成要素がフレーム・ベースであるという
点で、多重フレーム・ベースである。{(GETMFB
FB F X1...Xn)::=T}=(MAKE
−MFB FB F (X1...Xn))であること
に注意を要する。 【0124】例:(GETMFB FB F X1 X
2)::=VALUE12である場合:(GETMFB
FB F X1 X2)−>(VALUE12...
)は、値VALUE12を含みそして恐らくはその他の
前の値をも含むような値フレームが、FBのフレームF
におけるスロット位置(X1 X2)に存在することを
示す。(GETMFB FB F X1 X2 VAL
UE12)−>(T)は、スロット位置(X1 X2
VALUE12)に真の値フレーム(空でないフレーム
)が存在することを示す。(GETMFB FB F
X1)−>(X2(VALUE12...)...)は
、VALUE12を含む値フレームが位置(X2)に入
っている値フレームが、フレームFにおけるスロット位
置(X1)に存在することを示す。 (GETMFB FB F X1 X2)=(GETM
FB(GETMFB FB F X1)X2)(GET
MFB FB F X1 X2)=(GETMFB(G
ETMFB(GETMFB FB)F)X1)X2) (GETMFB FB F X1 X2)::=NEW
VALUE(GETMFB FB F X1 X2)−
>(NEWVALUE...VALUE12...)は
、両方の値が今やFにおける位置(X1 X2)の値
フレームの要素であることを示す。 (GETMFB FB F X1 X2 VALUE1
2)::=0(GETMFB FB F X1 X2)
−>(NEWVALUE...)は、VALUE12が
Fにおける位置(X1 X2)の値フレームの要素で
ないことを示す。 (GETMFB FB F X1 X2 VALUE1
2)−>0【0125】5)多重アサータ フレーム、またはGETMFBのスロット引数のうちの
1つが、それ自体フレーム・ベースであり、表明に対し
てGETMFBが呼び出された場合、その表明は、多重
化され、そのフレーム・ベース引数のすべての要素に分
配される。 【0126】例:X::=(MFB A B C)−>
(A...B...C...)とし、NX=BNX|(
X)|ANXである場合:{(GETMFB FB F
NX)::=Y}={(GETMFB FB F|B
NX|(A)|ANX|かつ(GETMFB FB F
|BNX|(B)|ANX|かつ(GETMFB F
B F |BNX|(C)|ANX|)} (GETMFB FB F |NX|)::=()は、
これらすべての表明を削除する。特に:(GETMFB
FB FB |NX)::=Tは、フレーム・ベース
FBのすべてのフレーム要素にNXを表明する。 (GETMFB FB FB)=(GETMFB FB
)かつ(GETMFB FB FB)::=()は、F
Bのすべての要素からすべての事実を削除する。 【0127】6)関係アクセサおよび関係アサータフレ
ーム・オブジェクト間の記号関係を指定するために、ス
ロット列NXを使用することができる。特に、FOLI
Eにおいては次のような構文法を用いて多重スロット列
を用いて、双対関係を定義することが可能である。即ち
、:>を「前方」リンク記号とし、:<を「後方」リン
ク記号とすると、(GETMFB FB A :> B
)::=Tは、フレーム・ベースFBのフレームAとフ
レームBとの間の双対関係を表明する。FOLIEで定
義されるフレーム・オブジェクトに関するすべての処理
において、以下に定義される同等関係を実施することに
より関係の双対性が維持される。FBを現在のフレーム
・ベースとする。フレーム・ベースFBにおいて表明N
Xが真であることを示すために、(GETFMBFB
NX)::=Tを短縮形[NX]=X1 X2...X
nで表すものとする。<=>を同値記号とする。要素と
してA、BおよびCを含むフレーム・ベース(MFB
A B C)を短縮形(A B C)によっ
て表すものとする。すると、FOLIEにおける関係に
ついての次の表明は真である。 a)直接関係同値 A:>B<=>B:<A b)多対1関係の分配性 (A B):>C<=>{A:>C かつ A:>C}
c)sink関係の分配性 FB:>OMEGA<=>FBのすべてのFに対し{F
:>OMEGA}d)1対多関係の分配性 A:>(B C)<=>{A:>B かつ A:>C}
e)トポロジー関係の分配性 ALPHA:>FB<=>FBのすべてのFに対し{A
LPHA:>F}f)N項関係の同値 A X1 X2...Xn:>Z <=> Z X1
X2...Xn:<Aさらに、前記のa)からe)まで
の表明は、N項関係に対しても同様に真である。 【0128】例: (A B C) CONNECT
SATELLITE :> VEGA<=>{A CO
NNECT SATELLITE :> VEGAかつ
B CONNECT SATELLITE :> V
EGAかつ C CONNECT SATELLITE
:> VEGA}<=>{VEGA CONNECT
SATELLITE :< Aかつ VEGA CO
NNECT SATELLITE :< Bかつ VE
GA CONNECT SATELLITE :< C
}【0129】7)作用素の設定 FBが、次の処理を行う間にすべての双対関係を表明す
るために「ルート」として使用される現在のフレーム・
ベースであるとする。MFB−MERGE(TYPE
FB1 &rest FB−set) これは、(:
REUSE:COMBINE:OVERWRITE:F
ORGET)の一要素であるTYPEにしたがって、フ
レーム・ベースの集合BF−setをFB1へと合併す
る(FB1を変更する)。MFB−INTERSECT
ION(FB1 &rest FB−set) FB
1を、それ自体(その表明)とフレーム・ベースの集合
(からのすべての表明)との交事象(積集合)にする。 MFB−DIFF(FB1 &rest FB−set
) フレーム・ベース集合からのすべての表明をFB
1から削除する。MFB−TRANSFER(FB1
FB2)=MFB−MERGE(:REUSE FB2
FB1) FB2において全く相似を持たないFB
1からのすべての表明を加えてFB2とすることに相当
する合併の使用。MFB−UNION(FB1 &re
st FB−set)=MFB−MERGE(:COM
BINE FB1 &rest FB=set) フ
レーム・ベースの集合からのすべての表明の集合統一に
相当する合併の使用。MFB−REPLACE(FB1
FB2)=MFB−MERGE(:FORGET F
B2 FB1) FB2をフレーム・ベースにあるF
B1によって置き換えることに相当する合併の使用。M
FB−XOR(FB1 &restFB−set)
FB1とFB−setにおける各フレーム・ベースとの
両者に対して対をなして真でない表明の集合となるよう
に、FB1を変更する。 【0130】8)叙述子(Precidate)MFB
−INCLUDE−P(&rest FB−set)
これは、FB−setが包含関係に対する順序集合で
ある場合、真となる。例えば、(MFB−INCLUD
E−P FB1 FB2)ー>Tは、FB1がFB2の
サブフレーム・ベースに等しく、FB1において真であ
るすべての表明はFB2においても真であると言うこと
を意味する。MFB−MINIMAL−P(FB)
FBについて真であるような表明が存在しないならば、
真となる。例えば、(MFB−MINIMAL−P(M
AKE−MFB))−>Tである。MFB−EQUAL
(FB1 FB2 &optional DEPTH)
(MFB−INCLUDE−P FB1 FB2)
および(MFB−INCLUDE−P FB2 FB1
)が共に真の場合、真となる。 【0131】注意事項:ある種の処理の効率のために、
ここと以下においてオプションの引数DEPTHを使用
する。()というデフォルトのDEPTHは、フレーム
・ベース全体が検討されることを示す。0というデフォ
ルトのDEPTHは、フレーム・ベースの第1の水準が
検討されることを示す。DEPTHが数である場合、そ
の数は、検討されるスロット列NXの最大サイズから1
を引いた数を示す。 【0132】9)ユーティリティ MFB−COPY(FB &optional DEP
TH) FBのコピーを作る。 MFB−CLOSE(FB &rest FB−set
) FB−setのフレーム・ベースに対するすべて
の双対リンクを(閉じられる各双対リンクへの参照とし
てFBを用いて)閉じる。MFB−PRINT(SUB
FB &optional STREAM DEPTH
) フレーム・ベースSUBFBのシンボル表現を与
える。SUBFBは、フレーム・ベースFBの部分集合
でもFB全体でも良い。STREAMが指定されていれ
ば、それが、SUBFBを対応するSTREAM装置に
印刷するために、使用される。MFB−READ(FB
&optional STREAM DEPTH)
STREAMからフレーム・ベースの集合のシンボル
表現を読み、結果としてのフレーム・ベースをFBへと
合併する。 【0133】10)マッパー MAP−MFB(FCN FB &optional
(DEPTH 0)) FBのすべてのスロットと値
とに対し関数定義FCNをDEPTHまで適用する。M
AP−MFB−SLOT(FCN FB &optio
nal (DEPTH 0)) FBのすべてのスロ
ットに対し関数定義FCNをDEPTHまで適用する。 MAP−MFB−VALUE(FCN FB &opt
ional (DEPTH 0)) FBのすべての
値に対し関数定義FCNをDEPTHまで適用する。 【0134】11)ローカル・クラス優先リスト(LC
PL) LCPLに用いられる定義は、CLOS仕様(Comm
on Lispオブジェクト仕様)から生まれたもので
ある。CLOSではCPLが単一継承分の階層に対して
定義されるのに対し、FOLIEでは、(NXによって
定義される)N項関係によって指定される任意の階層に
対してLCPLが定義される。 【0135】MFB−LCPL(FB F NX &o
ptional DEPTH) NXによって指定さ
れる階層関係に局限されたFB内のFのクラス優先階層
を構成するフレーム・オブジェクトの順序集合を返す。 【0136】例:FBが、以下の(短縮形の)表明が真
であるようなフレーム・ベースであるとする。 この場合、関係(B C)に関しFBにおけるAに対す
るローカル・クラス優先リストは、(MFB−LCPL
FB A (A B))−>(A D D1 E E
1 Z)である。関係(B C)に対しAの継承された
属性を探す場合、この属性に対する(A D D1E
E1 Z)を連続的に見る。継承された属性の探査は、
以下で定義するMFB−BROADCASTを用いて行
われる。 【0137】12)関数の放送 MFB−BROADCAST(FCN FB F NX
&optionalDEPTH) フレーム・オブ
ジェクトFおよびフレーム・ベースにおけるNXによっ
て定義される階層においてFに先行するすべてのオブジ
ェクトに対し関数定義FCNを適用する。MFB−BR
OADCAST−COLLECT(FCN FB F
NX &optional DEPTH) MFB−
BROADCASTに似ているが、その階層におけるF
のすべての先行例に対するFCNの適用結果を収集する
。 【0138】プレスクリプト GRAS風の対話的アクタと規則ベースの環境における
システム作用のビジュアル・プログラミングと対話的・
動的かつ柔軟性のある編集は、ビジュアル・オブジェク
トの定義によって可能となる。アクタ・フレーム構造体
は、GRASにおけるアクタの視覚的表現を実現するた
めに、オプションでビジュアル・オブジェクトによって
拡大することができる。つまり、Actor = D(
A,t)= Base−Frame+ {Visual
Object} + {Beheavor}であり、
このアクタは、時刻tにおけるデータ空間の記述D(A
,t)によって完全に指定される。しかし、データ空間
の記述は、ビジュアル・オブジェクト成分、基本フレー
ム記述、および現在時刻における可能な作用の継承され
た(恐らくは空の)集合を引き出し得る元の作用指定子
の集合に分解することができる。 【0139】ビジュアル・オブジェクトは、自己表示お
よび自己記述を行い、他のビジュアル・オブジェクトと
合併することが可能であり、さらに種々の視覚的表現(
例えば、アイコン、テキスト、ボタン、幾何学的な形、
グラフィックスの原形の組み合わせ)を持つことが可能
である。さらに、アクタに関係付けられたビジュアル・
オブジェクトは、テープの直接の構成員であり得る。そ
のビジュアル・オブジェクトに対応するフレームも、そ
のテープ・フレームに連結される。従って、1つのアク
タは、それが使用されるテープの各インスタンスについ
て2つのリンクを持つことができる。即ち、そのテープ
とそのビジュアル・オブジェクトとの間のリンク、およ
びそのフレーム記述とそのテープに関係付けられたフレ
ーム記述との間の双方向リンクである。 【0140】ビジュアル・オブジェクト表現の基礎とな
るのは、プレスクリプト(PreScript)グラフ
ィックス言語である。プリスクリプトでは、プリスクリ
プトのインタープリタ、コンパイラおよびデバッガのほ
か、接頭語表記およびLisp風の構文法も使用される
。プリスクリプトは、指示装置(例えば、マウス、カー
ソル)および利用者の入力をとらえ出力機構を与える機
構の定義を含めるために拡張された2次元、3次元また
はそれ以上の次元のベクトル空間代数を直接的に実現し
たものである。 【0141】プリスクリプトの実現には、ベクトル、ノ
ルム、距離、ベクトル演算(スカラー積、加算、減算、
ベクトル積)、直交性、平行性、点、線、平面、超平面
、射影、配景、原始的幾何学的対象(線分、線筋、2次
曲線、多角形、平行6面体、円柱、曲面モデル)、空間
位置の原形(内側、外側、交わり、合併、要素関係、隠
れた曲面)、線形変換およびアフィン変換、相似(回転
、移動、尺度構成、点対象および面対象)に対する定義
が含まれる。また、プレスクリプトのグラフィックス言
語には、表示装置、多数の視点、きめ、色、字体(フォ
ント)、テキストおよび座標の入出力装置、イメージ(
グラフィック要素の配列)、タイル、グラフィカルな周
期性および反復性の定義も含まれる。 【0142】プレスクリプト・コマンドの実行中にエラ
ーが発生すると、エラー・メッセージが、返され、説明
表示部位(Explaination View)に表
示され、現在のプレスクリプト表現の実行は中止される
が、プレスクリプトの実行が阻止されるわけではない。 描画中のエラーは、次のような意味で決して致命的では
ない。即ち、所与のプレスクリプト・オブジェクトの表
示中のエラーにより、次のようなプレスクリプト・オブ
ジェクトの表示が妨げられることはない。しかし、第2
の表示結果が第1のものに依存する場合、第2の表示結
果は、正しくない可能性がある。 【0143】プレスクリプト・オブジェクトは、プレス
クリプト作用素、ならびに型引数(例えば、数型)およ
び仮想的評価環境において束縛される推測されるシンボ
ル引数からなる良く構成されたプレスクリプト表現であ
る。視覚的なオブジェクトは、4つのプレスクリプト要
素の組み合わせによって定義される。4つのプレスクリ
プト要素とは、P=(d,e,i,s)である。ここで
、d=「描画(drawing)」、e=「エクステリ
ア(exterior)」、i=「インテリア(int
erior)」、およびs=「センサ(sensor)
」である。さらに、4つのセンサ方式(利用者対話作用
)S=(in,ex,bc,ac)がある。ただし、i
n=「センサに入る手順」、ex=「センサから出る手
順」、bc=「クリック前の手順」、ac=「クリック
後の手順」である。 【0144】プレスクリプトの要素は、次のように定義
される。即ち、描画(d)は、視覚的対象の(表示装置
から独立した)描き方と初期の描画から動画を与えるオ
プションの変換関数とを記述するプレスクリプト・オブ
ジェクトである。エクステリア(e)またはマスクは、
所与の表示部位(view)において視覚的表現対象に
範囲を定めるために使用される明確に定義されたインテ
リアを有するプレスクリプト・オブジェクトである。イ
ンテリア(i)または範囲は、ビジュアル・オブジェク
トの実質的な内部に範囲を定めるために使用される明確
に定義された内部を有するプレスクリプト・オブジェク
トである。センサ(s)は、指示装置の指示に感応する
領域に範囲を定めるために使用される明確に定義された
インテリアを有するプレスクリプト・オブジェクトであ
る。 【0145】図4における利用者アクタによって例示し
たようなプレスクリプト・オブジェクトの例を以下に示
す。 【数1】 【0146】このプレスクリプト・オブジェクトP1は
、P1の設定環境(letで設定される)におけるd1
に従って、表示装置上のx、y座標(806,276)
の周囲を中心とした位置に表示される。変数「icon
」が指定された位置に表示される。変数「name」が
、使用されて、指定の位置にヘルベチカ(Helvet
ica)フォント(サイズ14、肉太型)で印字された
後、枠が描かれる。エクステリアe1は、座標P1を中
心とし、半径150の円の外部によって定義される。イ
ンテリア(i)は、座標P1を中心とする幅「w」およ
び高さ「h」の四角の内部である。そして、センサ領域
s1は、「name」の表示を囲む四角i1の底にある
さらに小さい四角によって範囲が決定される。 【0147】センサ方式は、次のように定義される。即
ち、センサに入る手順(in)は、指示装置が視覚対象
のセンサ領域に入ったときに呼び出される手順である。 デフォルトの手順は、マウスがセンサ領域に入ったとき
、そのセンサ領域が強調されることである。センサから
出る手順(ex)は、指示装置がセンサ領域から出たと
きに呼び出される手順である。デフォルトの手順は、マ
ウスがセンサ領域から離れた場合、センサ領域が強調さ
れなくなることである。クリック前の手順(bc)は、
指示装置がセンサ領域において選択を行うために使用さ
れるとき(例えば、マウスがクリックされるとき)に呼
び出される手順である。センサ領域を色付けしたり再描
画したりする、現在の表示部位において視覚対象のポイ
ンタに関連した動きを与える、現在の評価環境における
記号的事実を変更する、視覚対象に関する操作のメニュ
ーを出す、またはいくつかの手順の組み合わせを含む、
いくつかのデフォルト手順が利用できる。クリック後の
手順(ac)は、センサ領域における指示装置の選択が
解除されたときに呼び出される手順である。デフォルト
の手順は、恐らくは変化した評価環境においてセンサ領
域を再描画するときに利用できる。 【0148】P1の表示された名前を変更するP1に対
するクリック前の手順を、前記のP1の例に従って、以
下において定義する。 【数2】 この定義、ならびに「in」、「ex」および「ac」
の手順に関する前記のデフォルトの定義の結果として、
次のように言える。指示装置が、P1のセンサ領域s1
(「name」の表示の周囲の見えない四角)に入ると
、「in」の手順が呼び出され、四角s1が強調される
。指示装置を用いてP1のセンサ領域で選択を行うと、
P1の「bc」手順が呼び出され、これによって、(「
previous−name」(前の名前)と称する新
たな変数の下に「name」という現在の変数を格納し
た後に)P1の環境における「name」の値が「Ma
rgaret」に変化する。指示装置が解放されると、
P1に関するデフォルトの「ac」手順が呼び出される
ことによって、プレスクリプトの要素d1がP1の(変
化した)環境において実行される。従って、最上部にア
イコンがあり、最下部にヘルベチカ・フォントで「Ma
rgaret」(特定の利用者の名前)という語が印字
された四角として、P1が表示される。指示装置が、第
2の選択のインサイドs1のために使用された場合、P
1の名前は、P1の環境において定義された利用可能な
「previous−name」の値に変更される。従
って、名前「user」が、P1の環境における変数「
name」の値として復活する。第2の選択の内側s1
の解放時に呼び出される「ac」手順によって、P1の
表示は、最上部にアイコンがあり、最下部に「usr」
と言う語がある四角へと変化して戻る。指示装置がP1
のs1領域を離れると、「ex」のデフォルト手順が呼
び出され、s1は強調されなくなる。 【0149】アクタの選択可能な視覚表現を対話的に設
計するために、GRASでは前記のようなクリック手順
が使用される。それによって、ボタン、スイッチ、およ
び種々の入出力ビジュアル・オブジェクトが提供される
。これらの構成物をさらに込み入ったシステム要素へと
結合するために、アクタの合成が用いられる。例えば、
電話のオブジェクトは、ケース・アクタ、押しボタンア
クタの集合、液晶表示、および送受話器から構成される
。 【0150】クリック手順は、引数付きで定義された場
合、指示装置を介して行われる選択の型について選択的
である(例えば、左ボタンの選択に対し右ボタンの選択
と異なった定義をすることができるなど)。クリック手
順のための評価環境を形成するために、現在の環境が用
いられる。指示装置において行われるビジュアル・オブ
ジェクト、現在の表示部位、および選択の型は、これら
の手順に対する引数として渡される。さらに、ビジュア
ル・オブジェクトの階層(例えば、成分関係)が所与で
あるとし、ビジュアル・オブジェクトAが、その階層に
おいてビジュアル・オブジェクトBの下位のものである
ならば、Aは、その上位の属性への明確な参照を用いる
ことによって、Bの環境へのアクセスも有する。 【0151】例えば、電話オブジェクトPh1が、押し
ボタンPB1のサブオブジェクトを有する場合、PB1
の環境において、Wはその押しボタンの幅であり、(S
UPERIOR W)は、PB1の上位のもの(su
perior)、つまり電話オブジェクトPh1、の幅
である。 【0152】デフォルトのクリック手順によって、現在
のビュー(表示部位)Vにあるビジュアル・オブジェク
トAの動きが、ビューVにおけるAに与えられる強制関
数にならって与えられる。運動は、(成分の階層にある
)Aの上位のものの程度分だけさらに強制される。成分
の階層のAの最上位のものは、現在のビューにおけるす
べてのアクタの運動が入っているビューV用のビデオ・
モニタである。 【0153】例えば、Ph1のサブオブジェクトC1(
カーソル)が動いているならば、C1の運動は、Ph1
の内部(interior)領域に限られる(Ph1の
「i」要素)。 【0154】アクタのプレスクリプト評価環境は、3つ
の環境の組み合わせからなる。 1)そのアクタの局部知識ベースを記述する環境:(l
et al=V1,...,an=vn,...)ただ
し、「ai」は、その知識ベースにおける事実の記号名
を表し、「vi」は、対応する値または表現である。 2)そのアクタの関連する特性を記述する環境:(le
t self=vself,name=vname,i
name=Viname,icon1=vicon1,
...,x1=vx1,x2=vx2,...,xp=
vxp,...)ただし、「self」(アクタ自体)
は、「vself」、即ちこのアクタに特有の識別子(
例えば、そのアドレス)に束縛される。「name」は
、アクタのステージ名に束縛される。「iname」は
、そのアクタの内部名(またはシンボル・アドレス)に
束縛される。 「icon1」は、アイコン表現「vicon」、即ち
アイコン・ライブラリにあるアイコンの記号的な識別子
に束縛され、可視イメージを生成するために、使用され
る。「xi」は、p次元の絶対座標系におけるアクタの
座標に固定された絶対的な関連で束縛される。 3)所与のテープに対して定義され、ビューの集合{v
iewj}(j=1,...,q)に対するアクタの視
覚的表現および属性に関する変換と強制の集合を定義す
る環境:この環境は、次のものからなる。則ち、(a)
異なるビューに対する異なる座標:T:{xi} −>
(view1/t1({xi}),...,view
q/tq({xi}))T(viewj):{xi}
−> tj({xi})ただし、tjは、その絶対座標
に基づくj番目のビューにあるアクタの座標を得る変換
関数である。その変換がビューにおいて線形ならば、そ
の変換は、座標変換行列Mj({xi}=Mj{xi/
view})を用いて表すことができる。(b)ビュー
の集合における座標の移動に関する強制: C:{xi} −> (view0/c0({xi})
,view1/c1({xi}),..,viewq/
cq({xi})) C(viewj):{xi} −> cj({xi})
ただし、cjは、j番目のビューにおいて観察されるア
クタの座標に対する強制関数である。絶対座標系に単一
の強制関数c0が与えられる場合、ビューqを発生する
線形変換Mjが存在し、さらに各ビューに対して使用さ
れる強制関数が cj=c0 o Mj であると仮定する。 (c)すべてのビューに対する記号翻訳関数の集合:こ
の関数のアクタは次のように表される。 viewj −> trj ただし、trjは、アクタの環境(name、inam
e,iconなど)からの記号特性または局部知識ベー
ス(ai)からの要素の名前をj番目のビューで使用さ
れる新たな名前に変換する。デフォルトの翻訳関数は、
無変換である。 【0155】j番目のビューにおけるアクタの視覚的表
現は、ビューがviewjであることを知っているその
アクタのプレスクリプト環境の中でアクタに関係付けら
れたビジュアル・オブジェクトの第1のプレスクリプト
表現(描画)を評価することによって得られる。アクタ
のプレスクリプト環境は、そのアクタのビジュアル・オ
ブジェクト(それぞれエクステリア、インテリア、およ
びセンサ)の定義ならびに利用者の対話中の適切なセン
サおよびクリック手順の呼び出しに使用される他の3つ
のプレスクリプト・オブジェクト(e、iおよびs)の
評価にも使用される。 【0156】すべてのビューにおけるグラフィカルな変
化は、時刻tにおけるアクタ環境のプレスクリプト評価
によるアクタの知識ベースへの論理的変更によって直接
的にもたらされる。アクタのグラフィック表現を記述す
るプレスクリプト表現は、このアクタの設定環境(le
t環境)の束縛事項(ai)を使用する。従って、「a
i」スロットのの値は、アクタのプレスクリプト・オブ
ジェクトのプレスクリプト要素(d、e、i、s)の指
定に自由に使用される。この性質により、アクタのle
t環境として実現されるアクタの知識ベースの変更を反
映する表示の変更がサポートされる。グラフィック・エ
ディタは、使用規則、前記のような論理的変更、および
グラフィカルな効果を関係付け結合させるコードを自動
的に生成する。他の実施例では、論理的変更とグラフィ
カルな効果との間のデーターベースが維持されるものも
ある。GRASシステムのユーザ・インタフェースは、
そのようなビジュアル・オブジェクト(アクタの視覚的
表現)を用いて作った。この表現方法の柔軟性は、ビジ
ュアル・オブジェクトを用いて作ったシステム(への)
インタフェースは数日で完全に設計し直すことができる
ほどである。この環境は、それ自体のインタフェース、
例えば、ボタンの外観および感知力の変更、新たなボタ
ンの追加、および対応するコマンドなどを編集するよう
に、設定することができる。これは、それ自体の中でV
SMベースのシステムを再設計する仮定における第1段
階である。 【0157】実行中は、アクタの知識ベースの履歴がソ
フトコーダによって自動的に維持され、グラフィックス
と状態の完全に可逆的な実行を与えている。各アクタは
、中でそれが使用されている各テープに対して自動的に
維持されているそのアクタの属性の変化の履歴を持って
いる。この履歴は、有効な変更の記録であり、そのアク
タがあるテープで使用されていなければ、その履歴は、
そのテープに対しては空である。アクタの属性への変更
により、アクタのグラフィック表現に影響を与えること
が可能であり、テープのシミュレーション中にアクタの
視覚表現に可能な唯一の変更は、その属性の変更による
ものである。従って、維持される履歴は、アクタの内部
的な属性とその視覚的な表現の両方の完全な記録を与え
るに十分な機構である。 【0158】アクタ間の通信 アクタ間の通信は、ソフトコーダによるスクリプト規則
の実行を介して行われる。通信には、アクタ間の情報の
伝送、およびその伝送にともなうすべての処理が含まれ
る。通信機能が低下した場合、アクタからそれ自体への
伝送を伴い、そのアクタ環境における内部処理と同じに
なる。通信には2つのモード、即ち(1)相互同意によ
る通信、および(2)送付(delivery)による
通信が定義される。 【0159】(1)相互同意による通信:2つの異なる
アクタの間のメッセージ転送を伴うスクリプト規則の実
行の場合を考えると、メッセージが送信される前にセン
ダとレシーバの両アクタの事前条件が同時に満たされる
とき、この通信は、相互の同意によって実行される。ま
たこの通信は、同期通信とも称し、次式を使って表され
る。 P(S,R)=>M(S,R)=>Q(S,R)ここで
、Sはセンダ、Rはレシーバ、P、MおよびQはそれぞ
れ事前条件、MSGおよび事後条件である。同期通信は
、アクタ・システムにおける最小単位の処理である。 【0160】(2)送付による通信:スクリプト規則が
与えられ、センダのアクタの事前条件がレシーバのアク
タの事前条件より先に満たされた場合、通信は送付(d
elivery)を介して行われる。センダのアクタは
、その環境において構成されたメッセージを事前条件の
満足時に発行する。すると、そのスクリプト・インスタ
ンスは、「Sent」(送信済み)というスクリプト型
を用いて印が付けられ、ソフトコーダは、レシーバのア
クタに送付するために、その通信を待ち行列に加え、さ
らにセンダのアクタの事後条件が実行される。この通信
は、非同期通信とも呼ばれ、前の表記を用いて次のよう
に表すことができる。 P(S)=>M(S,Sent)=>Q(S)(wai
t) P(R)=>M(Delivered,R)=>Q(R
) M(S,Sent)は、メッセージが、センダの環境に
おいてそれが送られるときに、構成されることを示す。 M(Delivered,R)は、メッセージがRによ
って受信された時、Rの環境は、送付されたメッセージ
からの環境を含めるために、一時的に拡大され、次に、
この一時的な環境において、Rの事後条件Q(R)が実
行される。 【0161】アクタ間の一般的な通信モデルにおいて、
アクタは、いくつかの通信を平行して送受信などの処理
を行うことができる。ただし、これが所与のアプリケー
ションにとって望ましくないならば、この問題を避ける
ようにスクリプト規則を設計することができる。アクタ
の事後条件が平行して実行されたために、現在のアクタ
環境の同一の属性に多重に変更が起こる場合、矛盾の可
能性がある。このような矛盾は、実行時に容易に検出さ
れるので、目的のアプリケーションにとって容認できる
技法を用いて解決することができる(無作為抽出、多重
値、変更上書き、エラー信号など)。 【0162】問題のアクタが関与するテープ・プログラ
ムの実行中に、利用者が、アクタを削除したり、アクタ
の記述を変更したりすると、可能な別の矛盾例が発生す
る。問題は、その変更が特定のシナリオの実行に限られ
るのか、あるいはそのアクタのオリジナルの記述に対し
て報告された(グローバルな)ものか、ということであ
る。この矛盾は、利用者に局部的(ローカルな)変更か
全体的(グローバルな)変更かを選択させることによっ
て解決される。変更が局部的な場合、現在時刻のAのデ
ータ空間だけが、Aの将来の履歴のように影響を受けて
る。変更が全体的な場合、最初は、その変更が局部的に
行われ、アクタの履歴が空でなければ、その変更もAの
初期のデータ空間の記述に報告されている。削除されて
いるアクタによって、その変更が、スクリプト規則の集
合の削除を必要とする場合、利用者はそれらの規則の削
除に関する確認させられ、そして手の施しようのない矛
盾を避けるために、テープ・プログラム実行の自動巻き
戻しが行われる可能性がある。 【0163】所与のテープ・プログラムの実行中に、実
行の履歴の中で以前に現れたスクリプト規則を削除しよ
うと思うことがある、つまり、このスクリプト規則に対
するスクリプト・インスタンスが存在するのである。ま
たは、その履歴が再び再生されれば、利用者は、そのス
クリプト規則の出現または他のスクリプト規則の異なる
仕方での出現を禁止したり、そのきっかけを作ったりす
ることになるような方法でスクリプト規則やアクタを編
集する可能性もある。この種の矛盾は、前記のように手
に終えない結果を招く可能性がある。実行の履歴を築く
ために既に使用された規則の編集には、その履歴の再構
築を必要とする可能性がある。修正された規則の集合を
用いては、アクタ・システムの現在の状態を回復できな
いこともある。この場合、テープ・プログラムの実行を
巻き戻し、そのアクタ・システムの匹敵する状態が回復
可能かどうかを検査するために古い履歴を再実行するこ
とが推奨される。 【0164】MOVON アクタのデータ空間および履歴:実現の実際性のために
、アクタに対して維持される履歴は、データ空間の変化
の測度(measure)に基づく。 D(A,t) mDS(A,t) dD(A,t1,t2) dmDS(A,t1,t2)
が、それぞれ時刻tにおけるアクタAのデータ空間(D
)、時刻tにおけるこのデータ空間の測度(mDSの値
は数である)、時刻t1およびt2の間のAのデータ空
間における差(dD)、および時刻t1およびt2の間
のアクタAに対するデータ空間の変化の測度(dmDS
,数)である。ここで、アクタAの履歴は、アクタAの
データ空間に対する相当な変化の有限集合として定義す
ることができる。例えば、アクタAの初期のデータ空間
: D(A,t0) が分かると、アクタAに対し粒状性(e)を有するサイ
ズnの有限履歴は、 He(A)={(ti,dD(A,ti,ti−1))
|dmDS(A,ti,ti−1)>=e} 1=<
i=<n として定義される。さらに、 T(He(A))={ti} 1=<i=<nは、A
の履歴からのタイム・スタンプの集合を表す。つぎに、 D(A,tj)=D(A,t0)+{+dD(A,ti
,ti−1)} 1=<i=<jを用いて、Aの中間
的なデータ空間が得られる。また、次のようなアクタA
に対するデータ空間の変化の空間効率的な記述を用いて
、アクタの履歴のモデルを洗練することが可能である。 【数3】 He,g(a)により、粒状性eおよび効率gを有する
アクタ履歴のモデルが定義される。従って、時刻tにお
けるAの中間的なデータ空間をAの履歴から以下を用い
て導くことができる。 【数4】 アクタAは、その初期のデータ空間およびデータ空間の
履歴が分かる時間の階段状の関数であるアクタのデータ
空間記述D(A,t)によって時刻tに完全に明記され
る。アクタの履歴は、そのアクタが変更された時刻とそ
れに対応するそのアクタのデータ空間への変更の記述と
のリストに過ぎない。その形式のアクタ・データ空間の
変化(dD)によって記述されるのは、新たなスロット
および(若しくは)新たな値の追加、ならびに(または
)新たなスロットおよび(若しくは)新たな値の削除、
ならびに(または)値の変更である。アクタAのアドレ
スa(t)は、Aのデータ空間の特別な要素であり、ア
クタ・システムにおいてAに特有の識別子を与えるもの
である。 【0165】アクタ・システムにおける可逆性:アクタ
の履歴により、各アクタごとに限られた履歴管理機構が
与えられる。アクタ間の通信システムでは、アクタのデ
ータ空間は、そのアクタが伝達情報を送信したり処理し
たりするときに、変更できるに過ぎない。さらに、伝達
情報の送信および処理は、最小単位の処理である。従っ
て、アクタ・システムにおける各変更の範囲は、各通信
について完全に明記されるため、すべてのアクタのデー
タ空間の測度が固定値で制限されているという仮定の下
で、すべてのアクタの履歴を線形時間で維持することが
可能である。このモデルにより、維持されるアクタの履
歴の大きさを限度内で完全に可逆性の処理がサポートさ
れる。このモデルのコンピュータ処理に関する重要な利
点は、処理歴のアクタ間の分散であり、これによって、
分散アクタ・システムにおいて可逆的なコンピュータ処
理がサポートされる。 【0166】アクタ環境:アクタによるGRASの実施
においては、時刻tにおけるアクタAのデータ空間D(
A,t)を表すためにlet環境を使用する。 (let a1=v1,...,an=vn;...)
ここで、aiはAのスロットの記号的表現、viはそれ
に対応する値またはその値を表す表現、そしてnは時刻
tにおけるスロットの総数であり、さらに「=」記号は
値の割当を表す。時刻tにおけるAのデータ空間の測度
は、mDS(A,t)=nであり、使用される履歴の定
義は、H1(A)(e=1)である。アクタの環境によ
って、時刻tのそのアクタが完全に記述される。アクタ
の作用の記述は、そのアクタの環境と、そのアクタが演
ずるテープから利用できる作用とから全体的に引き出す
ことができる。 【0167】アクタの関係および接続:アクタは、双方
向性リンクによるフレーム表現を用いる関係として実現
される静的または動的な従属関係にも関与する。静的な
従属関係には、クラス・メンバーシップ(AKO)、成
分メンバーシップ(COMPONENTまたはPART
−OF)、接続、テープ・メンバーシップおよびその他
が含まれる。動的な従属関係には、アクタ間の接続(例
えば、データ通信のための回線接続)が含まれる。なお
、応用分野に適合するようにアクタ間に新しい型の関係
を定義することもできる。新たな関係を表し作るために
属性として視覚表現の参照を利用することができる。 各種の関係に(グラフィックスの組み合わせによる)視
覚的な表現を(オプションで)与えるために、グラフィ
ックスの原形の有限集合が使用される。関係属性は、他
のアクタとの関係を定義するために使用されるアクタの
属性の集合である。例えばCOMPONENT(成分)
関係であるが、この場合、アクタの分解が、成分および
下位成分によって与えられる。各成分は、1つのアクタ
であり、従って、他のアクタと通信することができるが
、成分は、それを所有するアクタの物理的な部分でもあ
る(例えば、スピーカーと押しボタンを有する電話機)
。 【0168】VSMの関数 GRASシステムは、VSMモジュールによって利用者
の水準で実現される。VSMモジュールは、利用者の要
求を果たすためにさらに低い水準のモジュールを要求す
るユーザ・レベルの関数から成る。 【0169】特殊効果:作用の規則を洗練するために、
録音の最中かその後で特殊効果のソフトウェア・モジュ
ールを利用することができる。例えば、スクリプト規則
において、アクタ、事前条件、事後条件、転送されたメ
ッセージおよびデータを修正することができる。トラッ
キング装置の入力およびメニューの選択によって、その
変更結果が与えられる。一般スクリプトに対するアクタ
対の集合を定義するオーディション表現を生成するため
に特性の対話的な指定(例えば、属性の値に関するパタ
ン照合表現)を含む一般規則(General Scr
ipt)を洗練するために、さらに特殊効果を利用する
ことができる。 【0170】図6は、テープ生成(CREATE TA
PE)関数の流れ図である。テープ・生成関数は、MO
VONにテープ・ビジュアル・オブジェクトを要求する
(作用ブロック601)。次に、MOVONは、指名さ
れた新たなテープにフレーム構造体を割り当てる(作用
ブロック602)。MOVONは、ロードされたテープ
のフレームにそのフレーム構造体をリンクする(作用ブ
ロック604)。そのフレームを環境に存在するビデオ
・モニタ(view)のフレームにリンクすることによ
り、その新たなテープを現在のテープとする(作用ブロ
ック606)。新たなテープは、ソフトコーダにロード
(LOAD TAPE参照)され(作用ブロック608
)、未来のリールと過去のリールにリンクされ、シミュ
レーション・カウンタが内部的に設定される。MOVO
Nにより、新たなテープが表示され(作用ブロック61
0)、ビデオ・モニタの再表示が行われる。 【0171】図7は、テープ・ロード関数(LOAD
TAPE)の流れ図である。ロード・テープ関数により
テープがロードされることになる(作用ブロック702
)。テープの過去のリールおよび未来のリールが、ソフ
トコーダの過去のリール要素および未来のリール要素に
リンクされ、スクリプトのインスタンスおよび規則がソ
フトコーダに組み込まれることになる(作用ブロック7
04)。テープ・カウンタの値を用いて、シミュレーシ
ョン・カウンタが設定される。MOVONにより、その
テープから既存のアクタがビデオ・モニタの適切な表示
部位に表示される(作用ブロック706)。ソフトコー
ダは、初期シミュレーション・モード、動画の速度およ
び詳細水準を随意選択するために、予備的な評価を行う
(作用ブロック708)。再生(PLAY)関数(後述
)が呼び出され(作用ブロック710)、MOVONに
より、実行可能なスクリプトの最初の集合からアクタが
それらに関係付けられたview(スクリプト・タッグ
による)にリンクされ、アクタ、適切なviewにおい
て交わされるメッセージおよびデータが表示される(作
用ブロック712)。 【0172】図8は、テープ・コピー関数(COPY
TAPE)の流れ図である。まず、コピー・テープ関数
は、コピーが取られるべき元となるテープを要求し(デ
フォルトにより現在のテープがロードされる)、次に元
のテープをコピーする先のテープを要求する(作用ブロ
ック802)。コピー先のテープが既に存在し(判断8
04)、かつこのテープを再利用することになった(判
断806)場合、元のテープのフレーム構造体が、先の
テープのフレーム構造体へと(再利用を伴う)合併され
る(作用ブロック808)。先にテープが存在しなけれ
ば、新たなフレーム構造体が割り当てられ(作用ブロッ
ク810)、そのフレームが、ロードされたテープのフ
レームにリンクされ(作用ブロック812)、元のテー
プのフレーム構造体が新たなコピー先の構造体へと合併
される(作用ブロック808)。 【0173】図9は、テープ削除関数(REMOVE
TAPE)の流れ図である。テープ削除関数は、取り除
くべきテープを決定し(作用ブロック902)、そのテ
ープと共にアクタも削除するべきかどうかを判断する(
作用ブロック904)。MOVONは、そのテープのフ
レーム構造体をロードされたテープのフレームから切り
離す(作用ブロック906)。テープと共にアクタも削
除するべき場合(作用ブロック908)、この関数は、
そのテープ中で使用され、かつ他のロードされたテープ
においては使用されないアクタをすべて取り除く(削除
する)(作用ブロック910)。一方、アクタはテープ
と共に削除すべきでない場合、そのテープで使用され他
のロードされたテープでも使用されるアクタは切り離す
が、他のロードされたテープへのリンクは維持する(作
用ブロック912)。次に、そのテープのフレーム構造
体を削除し(作用ブロック914)、他のフレームへの
そのリンクをすべて消去する。 【0174】図10は、テープ・ファイル貸出関数(R
ENT TAPE FILE)の流れ図である。テープ
・ファイル貸出関数は、テープ・ファイル・フォーマッ
トおよびそのテープ・ファイルへのパスを要求する(作
用ブロック1002)。そのファイルに格納されている
テープの数が決められる(作用ブロック1004)。各
テープに対しテープ生成関数が呼び出される(作用ブロ
ック1006)。MOVONが、テープがファイルから
生成されるのに必要とされるアクタの生成または(再利
用を伴う)合併を行う(作用ブロック1008)。MO
VONは、それらのテープによって必要とされる各ビュ
ーに対しビデオ・モニタを生成し、テープ・ファイルか
らのリンク情報によってアクタをビューにリンクする(
作用ブロック1010)。次に、ソフトコーダが、テー
プ・ファイルから読み出されたスクリプト構造体に従っ
て、各テープを生成しリンクする(作用ブロック101
2)。 【0175】図11は、アクタ生成関数(CREAT
ACTOR)の流れ図である。アクタ生成関数は、生成
されるべきアクタの識別情報を要求する(作用ブロック
1102)。MOVONが、アクタのフレーム構造体を
割り当て、最小の内部属性およびグラフィカルな属性を
備えるように、その構造体を初期化する(作用ブロック
1104)。次にMOVONは、そのアクタ・フレーム
構造体を現在のテープ(作用ブロック1106)および
現在のビュー(作用ブロック1108)にリンクする。 MOVONは、次に、そのアクタが生成された現在のビ
ューと同じビューをサポートするすべてのビデオ・モニ
タに、そのアクタを表示する(作用ブロック1110)
。 【0176】図12は、アクタ選択関数(SELECT
ACTOR)の流れ図である。このアクタ選択関数は
、アクタ選択の型を要求する(作用ブロック1201)
。新たなオブジェクトが選択される場合(判断1202
)、アクタ生成関数が使用される(作用ブロック120
4)。すべてのオブジェクトが選択される場合(判断1
202)、MOVONは、ロードされた全アクタ(バッ
クステージ・アクタ)を現在のビューにリンクし、それ
らを対応するビデオ・モニタに表示する(作用ブロック
1206)。アクタの選択にキーワード探索を用いる場
合、キーワードを入力するように利用者を促す(作用ブ
ロック1208)。一致するアクタが見つからない場合
(判断1210)、新たな選択が必要になる(作用ブロ
ック1202)。一致するアクタが見つかった場合、特
定のアクタが要求され(作用ブロック1214)、(1
つでもある場合)そのアクタが、現在のビューにリンク
されて表示される(作用ブロック1216)。 【0177】図13は、アイコン状態設定関数(SET
ACON STATE)の流れ図である。この関数は
、実行された直後のスクリプト・インスタンスの集合の
中の1つのスクリプトを要求する(作用ブロック130
2)。つぎに、そのスクリプトからセンダのアクタまた
はレシーバのアクタを要求する(作用ブロック1304
)。MOVONが、前記のアクタによって使用される現
在のアイコン決定し、このアイコンに対する可能なアイ
コン状態の集合をアイコン・ライブラリから検索する(
作用ブロック1306)。次にアイコン状態設定関数が
、可能なアイコン状態の集合の中から1つのアイコン状
態を要求する(作用ブロック1308)。そのスクリプ
ト集合について、ソフトコーダのアンドゥ関数が呼び出
される(作用ブロック1310)。ソフトコーダは、選
ばれたスクリプトの事後条件リストにおけるアクタの状
態を変更するために、条件表現を追加する(作用ブロッ
ク1312)。ソフトコーダの再生関数が呼び出され、
MOVONが、アクタへの対応する変更を変更されたス
クリプト定義の実行結果として表示する(作用ブロック
1314)。 【0178】図14は、アクタ接続関数(CONNEC
T ACTORS)の流れ図である。アクタ接続関数は
、実行直後のスクリプトの集合の中の1つのスクリプト
(作用ブロック1402)と接続の型(記号的名称)と
を要求する(作用ブロック1404)。その接続の型に
対応するグラフィック表現(例えば、単線、2重線、会
議線)が決定される(作用ブロック1406)。接続す
るアクタ数が要求される(作用ブロック1408)。接
続するアクタが要求される(作用ブロック1410)。 ソフトコーダのアンドゥ関数が呼び出される(作用ブロ
ック1412)。「CONNECT{接続型}[選択さ
れたアクタのリスト]」という形式の条件が選択された
スクリプトの事後条件リストに加えられる(作用ブロッ
ク1414)。ソフトコーダの再生(PLAY)関数が
呼び出され(作用ブロック1416)、変更されたスク
リプトの実行結果として、選択されたアクタ間の接続が
、生成されて、適切なビューに表示される。 【0179】図15は、アクタ視覚化関数(MAKE
ACTORS VISIBLE)の流れ図である。この
関数は、実行直後のスクリプトの集合のうちの1つのス
クリプトを要求する(作用ブロック1502)。視覚化
するべきアクタが要求される(作用ブロック1504)
。ソフトコーダのアンドゥ関数が呼び出される(作用ブ
ロック1506)。 選択されたスクリプトの事後条件リストに「VISIB
LE[選択されたアクタのリスト]」という形式の条件
を追加する(作用ブロック1508)。ソフトコーダの
再生関数が呼び出され(作用ブロック1510)、その
変更されたスクリプトの実行結果として、前記のアクタ
が視覚化され(るか、または恐らくは生成された上で視
覚化され)て、適切な表示部位に表示される。 【0180】図16は、アクタ状態の設定関数(SET
STATE OF ACTOR)の流れ図である。ア
クタ状態設定関数は、実行直後のスクリプト・インスタ
ンスの集合の中からスクリプトを1つ要求する(作用ブ
ロック1602)。つぎに、そのスクリプトからセンダ
またはレシーバのアクタを要求する(作用ブロック16
04)。MOVONが、スロット名が要求される前記の
アクタから現在のスロットの集合を決定する(作用ブロ
ック1606)。このスロットは、そのアクタの状態を
変更するために使用される。そのスロットに対する新た
な値が決定される(作用ブロック1608)。そのスク
リプト集合にソフトコーダのアンドゥ関数が呼び出され
る(作用ブロック1610)。ソフトコーダは、そのア
クタのスロットを新たな値に変更するために、選択され
たスクリプトの事後条件リストにおいて条件表現を追加
する(作用ブロック1612)。その追加される条件は
、「SET{スロット名}{スロット値}」と言う形式
のものである。ソフトコーダの再生関数が呼び出され、
MOVONが、そのアクタに対応する変化を変更された
スクリプト定義の実行結果として表示する(作用ブロッ
ク1616)。 【0181】図17は、メッセージ経由のデータ渡し関
数(PASS DATA VIA MESSAGE)の
流れ図である。メッセージ経由のデータ渡し関数は、実
行直後のスクリプトの集合からスクリプトを要求する(
作用ブロック1702)。次に、前記のスクリプトのセ
ンダのアクタからのスロット名が要求される(作用ブロ
ック1704)。このスロット[slot−from]
が、もう一方のアクタに送られるべきデータとして使用
される。レシーバのアクタからのスロット[slot−
to]の名前が要求される(作用ブロック1706)。 そして、ソフトコーダのアンドゥ関数が呼び出される(
作用ブロック1708)。センダのアクタのスロット値
がそのメッセージを介して渡されること、およびそれが
受信されたときのシンボル名が{slot−from}
であることを示す「{slot−from}{slot
−from−values}」という書式が、選択され
たスクリプトのメッセージ表現に追加される(作用ブロ
ック1708)。 「SET{slot−to}{slot−from}」
という形式の条件が、選択されたスクリプトに対しレシ
ーバのアクタの事後条件リストに追加される(作用ブロ
ック1710)。 ソフトコーダの再生関数が呼び出され(作用ブロック1
712)、変更されたスクリプトの実行結果として、セ
ンダのアクタからのスロットの値が、レシーバのアクタ
の[slot−to]の値を更新するために渡されて、
適切な表示部位に表示される。 【0182】図18は、クローン・アクタ関数(CLO
NE ACTOR)の流れ図である。クローン・アクタ
関数は、コピーされるべきアクタを要求する(作用ブロ
ック1802)。MOVONが、そのアクタに対するフ
レーム構造体を割り当てる(作用ブロック1804)。 MOVONは、コピーされるアクタに対するアドレスを
、基となるアクタの名前とそのアドレスを唯一のものと
するコピー番号とを用いて生成する(作用ブロック18
06)。MOVONは、新たなアクタを現在のview
にリンクし、コピーされたアクタを同じviewを有す
るすべてのビデオ・モニタに表示する(作用ブロック1
808)。 【0183】図19は、アクタ合併関数(MERGE
ACTOR)の流れ図である。アクタ合併関数は、他の
アクタ{act−to}へと合併されるべきアクタ{a
ct−from}を要求する(作用ブロック1902)
。MOVONが、それらのアクタ・フレーム構造体を合
併する(作用ブロック1904)。ソフトコーダが、a
ct−fromのアドレスへの参照をすべてact−t
oへのアドレスで置き換える。(作用ブロック1906
)。 【0184】図20は、チャネル設定関数(SET C
HANNEL)の流れ図である。チャネル設定関数は、
そのチャネルを変更するビデオ・モニタを要求し(作用
ブロック2002)、さらにチャネルの選択を要求する
(作用ブロック2004)。選択されたチャネルが「全
チャネル」の場合(判断2006)、ソフトコーダが、
デフォルトのスクリプト構造体のタグ(名前)をそのビ
デオ・モニタにおける「Sid」に設定し(作用ブロッ
ク2008)、さらにMOVONが、そのチャネルの指
定を空にしたまま、そのビデオ・モニタを表示する(作
用ブロック2010)。選択されたチャネルが「新たな
チャネル」の場合、それに対応するスクリプト構造体の
タグが決定される(作用ブロック2012)。次に、ソ
フトコーダは、デフォルトのタグをビデオ・モニタにお
ける要求されたタグに設定する(作用ブロック2014
)。次に、MOVONが、ビデオ・モニタを表示し、そ
の表示にチャネル・タグを示す(作用ブロック2016
)。このビデオ・モニタにおいて記録する場合、そのタ
グは、そのビデオ・モニタのviewとこのviewに
おいて生成されたスクリプト構造体の集合との間の相互
参照の役に立つ。 【0185】図21は、変換テーブル関数(TRANS
LATION TABLE)の流れ図である。テーブル
操作に対する要求がVSMを介して利用者に送られる(
作用ブロック2102)。同時に発生するスクリプトの
現在のグループの中から1つのスクリプトを求める要求
が送られる(作用ブロック2104)。センダのアクタ
が、レシーバのアクタと同一でない場合(判断2106
)、VSMを介してエラー・メッセージが表示されて(
作用ブロック2107)、この関数は終了する。その他
の場合は、スクリプトによって、アクタ(センダ=レシ
ーバ)に対し内部で処理する仕事が記述され、変換テー
ブルを生成または編集することができる(判断2108
)。(判断2108において)スクリプト中に変換テー
ブルの表現が全く存在しない場合、新たな変換テーブル
の生成が必要となる。この場合、変換テーブルへの入り
口スロットとして使用するためのアクタの状態(スロッ
ト1)が選択され(作用ブロック2110)、さらに変
換テーブルによって変換された値の結果を格納するため
のアクタの状態(スロット2)が選択される(作用ブロ
ック2112)。データ変換のための値のリストが要求
される(作用ブロック2114)。変換テーブルが割り
当てられ、(新たな)変換表現が選択されたスクリプト
に挿入される(作用ブロック2116)。(判断210
8において)変換テーブルの編集作用が選択され、さら
に(判断2109において)スクリプト中に変換テーブ
ルの表現が存在しない場合、エラー・メッセージが表示
されて(作用ブロック2111)、この変換関数は終了
する。 (判断2108において)変換テーブルの編集作用が選
択され、(判断2109において)スクリプトに変換テ
ーブルの表現が存在する場合、MOVONによってVS
Mを介して変換テーブルが編集可能な形式で表示され、
利用者によって編集される(作用ブロック2113)。 次に、ソフトコーダが、修正された変換テーブル表現を
含むように、スクリプトの事後条件リストを変更する(
作用ブロック2115)。変換テーブル表現は、「se
t slot−2(select slot−1){(
entry,値の表現)の対のリスト}」という形式で
ある(作用ブロック2117)。 【0186】ビデオ・モニタは、アクタ間の一組の処理
を表示したり、テープへと視覚的に記録するために使用
される。ビデオ・モニタは、シミュレーションまたは生
成されているシステムの単純化した描画を表示または記
録することができる。ビデオ・モニタは、再生の特定の
部分のズーム・イン(拡大)およびズーム・アウト(縮
小)を行う機構を与えるために、表示部位の間の切り替
えに使用されるチャネル制御と詳細水準の制御とを備え
ている。記録モードでは、チャネル制御変更は画面上で
異なる視点または視野を得るためのカメラの変更に相当
し、詳細水準の変更は、そのカメラへのズーム・イン/
ズーム・アウト制御に相当する。ビデオ・モニタは、設
定および変更を動的に行うことができる種々の特性を持
っている。例えば、利用者は、ビデオ・チャネルを設定
することができる。モニタのチャネルを変更することに
より、それに表示される表示部位が変化する。大きさ、
色(カラーの場合)、表題、アニメーションの水準およ
び速さ、メモリの大きさ(即ち、モニタ上に一度にいく
つのイベントを思い出すことができるかという持続性)
、静的な表示と動的な表示、表示される詳細の解像度ま
たは水準、およびデフォルトのメッセージ名の位置(セ
ンダおよびレシーバのアクタに関するメッセージ表示の
デフォルトの位置が変えられる)などの特性は、すべて
利用者がビデオ・モニタからメニューまたはアイコンに
よって選択することが可能である。 【0187】ビデオ・モニタは、テープの再生、活性化
、または表示、処理のためのステージの記録または設定
に使用することが可能である。VSMインタフェースに
よって、テープの生成、編集、表示、および実行に対す
る直接的な制御が与えられる。新たな指示の入力を記録
することによって、実行中に変更を取り入れることがで
きる。記録または再生の間に、テープの詳細水準を(例
えば、スライド・バーを用いて)変化させて、高い詳細
水準の表示の間にズーム効果を与えることができる。ビ
デオ・モニタは、「再生(play)」モードで活動さ
せられているイベントおよび特殊効果を変更するための
描画/編集板として役立つ。ビデオ・モニタは、同時に
何百ものオブジェクトを表示することができるが、通常
は、20乃至30以下のオブジェクトが、標準的なグラ
フィックス表示技術に基づいた良好な視覚的図式の目安
である。1つのテープで30以上のオブジェクトが必要
な場合は、特殊効果を使用することができる。特殊効果
によって、個々の視覚的な対象の表示/非表示が自在に
可能である。 【0188】GRASのビデオ・モニタは、多数のビュ
ーポイントを用いて実現される。設計の使用には大きな
ものもあるので、利用者から不要な情報を隠すために射
影(多重表示)がサポートされている。GRASシステ
ムは、同時の記録およびアニメーションを多重表示でサ
ポートする。各ビデオ・モニタが、記録およびアニメー
ションに使用されるビデオ・チャネルと抽象(要約)水
準とを持っている。ウィンドウとグラフィックスをサポ
ートし、さらに視覚的なオブジェクトのみならずビデオ
・モニタも実現するために、目標とするコンピュータ・
システム(例えば、SunViewTM、X Wind
ow SystemTM、OPEN LOOKTM、S
ymbolics Windows、XeroxWin
dows)によって専用のウィンドウおよびグラフィッ
クスのシステムが使用される。SunViewはサン・
マイクロシステムズ(Sun Microsystem
s)の商標であり、X Window Systemは
MITの商標であり、OPEN LOOKはAT&Tの
商標である。 【0189】多重ビューポイントの特徴の応用により、
要約表示と詳細な表示との間にズーム操作が提供される
。例えば、提出された表示内容の利用者ならば、高水準
の要約表示を見ることになり、表示内容の開発者であれ
ば、内部の交換構造を示す詳細な表示を見るであろう。 2つの表示を「ハードウェア」の動作と「ソフトウェア
」の動作とを分離するために使用しても良い。 【0190】GRASウィンドウなどの使用により、ウ
ィンドウの使用が高められる。例えば、SunWiew
下のSunワークステーションは、ウィンドウを64ま
で持つことができる。Sun上のGRASは、VSM/
GRASアプリケーションと同時に実行中の他のSun
Wiewの(メール、テキスト編集、およびその他の)
アプリケーションによって残りのウィンドウを使用しな
がらでも、10以上のビデオ・モニタ・ウィンドウを使
用することができる。 【0191】Lispが動作する機械であれば、数百の
ウィンドウを持つことも可能である(この数はディスク
の容量によってのみ制限される)。Lisp機上のVS
M/GRASは、(例えば、多重表示のように)希望の
数だけビデオ・モニタを持つことができる。この概念は
、同じシナリオや異なるシナリオの実行のいくつかの異
なる表示を与える異なるチャネルに調節されたいくつか
のテレビ・モニタを持つことに似ている。 【0192】編集ルーム(Editing Room)
によって、テープ・シェルフのテープ、およびビデオ・
テープまたはフィルムの編集の類似性を用いてテープを
編集・操作するために使用される作用素の集合に直接ア
クセスすることができる。そして、テープを編集を行う
ことが、プログラムの操作に対する唯一の手段である。 アクタおよびアクタ環境の実現、ならびにアクタ間の通
信過程におけるアクタの使用によって与えられる実行状
況の結末に基づいて、各スクリプト構造体は、ソフトコ
ーダの仮想機械によって実行される独立した単位処理と
して扱うことが可能であり、基本的なプログラム要素と
して操作することができる。テープ・プログラムには、
スクリプト構造体の閉集合が常にある。2つのテープを
接着することにより、おそらく両方のテープからさらに
機能性が得られることになり、これによって、GRAS
の背景において機能的統合が半自動化の可能な処理とな
る。テープを2つのサブテープに切断することも可能で
あるが、両方のサブテープが完結し、一貫性が維持され
る位置でテープを切断する必要があるので、いっそう注
意が必要となる。テープの切断および接着により、別個
の作業努力による機能性を結合する簡単な機構が与えら
れる。このことは、アクタどうしを合併できることと結
びついて、プログラム・システムにおける新たな特徴の
連続的な統合に取り組む強力な骨組みを提供する。 【0193】ソフトコーダ(SoftCoder)GR
ASのソフトコーダは、テープ・プログラムのスクリプ
ト規則(Script Rule)と一般スクリプト(
General Script)からなる未来のリール
、およびテープ・プログラムの実行履歴をたどるアンド
ゥ可能なスクリプトの集合からなる過去のリールを備え
ている。過去のリールでは、すべてのスクリプト・イン
スタンスが、逆向きの実行が可能である。つまり、すべ
てのスクリプト・インスタンスに、Sundo表現とR
undo表現がある。過去のリールには、実行の履歴と
その実行中に入力されたデータが入っているので、試験
用のシナリオとして使用することができる。 【0194】図29は、ソフトコーダの視覚的な表現で
ある。テープは、記録されたスクリプト規則と一般スク
リプトの集合であり、過去のリール2910は、シミュ
レーション中の現在時刻以前にシミュレータによって選
択され発動されたスクリプト・インスタンスに相当し、
未来のリール2920には、残りの規則か、またはシミ
ュレーションの生成モードにある完全なテープ・プログ
ラムの何れかが入っている。各リールは、時計回りに回
転し、シミュレーション中は、一度に1ステップ以上前
進する。固定の(再生)ヘッド2930によって、スク
リプト規則と一般規則の集合を読んで実行する。アンド
ゥ・ヘッド2950により、スクリプト・インスタンス
にアンドゥを行う情報で印を付ける。記録ヘッド294
0は、新たな規則の記録および挿入を行うために何時で
も利用することができる。先取りヘッド2960は、シ
ミュレーションにおいて次に発動するべき規則の集合を
捜すのに使用される。 【0195】ソフトコーダは、次の制御を有する「制御
パネル」を備えている。自動再生:テープ・プログラム
を現在の位置から最後まで(停止位置まで)選択された
アニメーション速度で自動的に再生する。図22は、自
動再生制御関数(AUTOPLAY)の流れ図である。 自動再生関数は、テープ・プログラムの最後に到達する
か、または自動再生の開始後に停止関数が呼び出される
まで(判断2204)、再生関数を繰り返し呼び出す(
作用ブロック2202)。 【0196】再生:現在発動可能な動作の規則の集合を
実行することによって一度に1ステップ(1フレーム)
だけテープの再生を行う。図23は、再生制御関数(P
LAY)流れ図である。再生関数は、再生の背景的条件
を定義する次の変数を確認する(作用ブロック2302
)。 即ち、ロードされた現在のテープおよびそのリール(未
来のリールおよび過去のリール)、現在のアニメーショ
ン速度、シミュレーション・モード、アニメーションお
よびシミュレーションの水準である。次に、その再生の
背景的条件において、再生関数は、スクリプト規則と一
般スクリプトの適切な集合を未来のリールから見つける
(作用ブロック2303)(このシミュレーション・モ
ードの関数としての動作の次の詳細な説明を参照のこと
)。そのスクリプトの集合が空の場合(判断2304)
、テープ・プログラムの最後に達したことが利用者に知
らされて(作用ブロック2305)、再生関数が終了す
る。さらにスクリプトが利用できる場合(作用ブロック
2306)、テープ・プログラムの実行の他の変形が可
能であることが利用者に知らされて(作用ブロック23
07)、再生関数が終了する。スクリプトの適切な集合
が空でない場合(判断2304)、そのスクリプトが再
生され(作用ブロック2310)(次の詳細な説明を参
照のこと)、アニメーション速度によりシミュレータを
待たせる必要がある場合(判断2308)、スクリプト
の再生の前に時間的遅延が導入され(作用ブロック23
09)、それから再生関数を終える。 【0197】記録:新たな通信を記録し、それを自動的
に現在のテープ位置に挿入する。図24は、記録関数(
RECORD)の流れ図である。記録関数は、記録の背
景条件を定義する次の変数をまず確認する(作用ブロッ
ク2402)。即ち、現在のテープ・プログラム、現在
のビューおよびチャネル、現在のアニメーション、シミ
ュレーションおよび記録の水準を確認する。次に、記録
関数は、記録中の新たな通信に対するセンダのアクタを
要求する(作用ブロック2403)。センダが指定され
ると(判断2405)、そのアクタを(オーディション
処理によって)確認するか、または生成するかする(作
用ブロック2406)。センダが指定されなければ、記
録関数は終了させられる。センダのアクタが分かると、
レシーバのアクタを要求する(作用ブロック2407)
。レシーバのアクタが指定されると(作用ブロック24
08)、それは確認されるかまたは生成される(作用ブ
ロック2409)。指定されない場合、記録関数は終了
する。次に、記録関数は、スクリプト規則を選択するよ
うに要求する(作用ブロック2410)。スクリプトが
全く指定されない場合(判断2411)、この関数は終
了する。指定された場合、スクリプト規則または一般ス
クリプトが生成されが、それがない場合、既存のものか
らクローンが生成させる(作用ブロック2412)。新
たなスクリプトがテープ・プログラムの未来のリールに
挿入され(作用ブロック2413)、再生関数が呼び出
される(作用ブロック2415)。最後の記録関数以来
はじめて停止関数が呼び出された場合(作用ブロック2
416)、記録関数は停止するが、そうでなければ、記
録関数は再開する(作用ブロック2401)。 【0198】停止:現在のテープに対し行っている自動
実行、記録またはアンドゥを終了させる。図25は、停
止制御関数の流れ図である。停止関数は、割り込みによ
って起動される。即ち、停止ボタンが押されると(判断
2502)、停止の事象が待ち行列に加えられる(作用
ブロック2503)。前述のように、再生(自動再生)
、記録、およびアンドゥ(自動アンドゥ)の関数も停止
事象の有無を確認する。 【0199】カウンタ:テープの開始から実行されたス
テップ数を示す。カウンタは、入力素子でもあり出力素
子でもある。カウンタを特定の位置に設定すると、テー
プをその位置まで自動的に進めたり巻き戻したりする。 図26は、カウンタ制御関数の流れ図である。カウンタ
関数は、表示か設定かによって2通りに呼び出すことが
できる(判断2602)。表示の場合、カウンタ関数は
現在のシミュレーション計数を得て(作用ブロック26
04)、カウンタの表示を更新する(作用ブロック26
05)。ここで、現在のシミュレーション計数は、現在
のテープ・プログラムの開始以来経過したシミュレーシ
ョン時間単位の数である。カウンタの設定の場合、カウ
ンタ関数は、カウンタ値を要求する(作用ブロック26
06)。カウンタ値が現在のシミュレーション計数を越
える場合(作用ブロック2607)、所望のカンウタ値
に達するか、停止関数が呼び出されるか、またはテープ
の終わりに達するまで、自動再生関数が呼び出される(
作用ブロック2608)。それ以外の場合、所望のカウ
ンタ値に達するまで、自動アンドゥ関数が呼び出される
(作用ブロック2609)。 【0200】アンドゥ:通信の最後の集合(起動された
スクリプト・インスタンスの最後の集合)の影響を取り
消す。最終ステップを巻き戻し、最終グループの処理の
影響を逆にする。図27に、アンドゥ制御関数(UND
O)の流れ図を示す。アンドゥ関数は、次の変数からア
ンドゥの背景条件を確認する(作用ブロック2702)
。即ち、シミュレーション・モード、シミュレーション
水準、現在のテープ・プログラム(未来のリールおよび
過去のリール)、多重ビューおよびアニメーションの水
準を確認する。次に、アンドゥ関数は、過去のリールか
ら復元されるべきスクリプト・インスタンスの集合を得
る(作用ブロック2703)。次に、アンドゥ関数は、
復元されるべきスクリプト・インスタンスの集合に対し
、1)そのスクリプト集合に関与するすべてのアクタの
データ空間をこのスクリプト集合の実行時刻に先立つシ
ミュレーション時刻におけるそれらのデータ空間にまで
戻すとともに、2)そのスクリプト・インスタンスが視
覚的な副作用を有する場合、対応するグラフィックスの
アンドゥ関数を実行する(作用ブロック2704)。次
に、アンドゥ関数は、過去のリールから前記のスクリプ
ト・インスタンスを削除し(作用ブロック2705)、
現在のシミュレーション計数および現在のスクリプト集
合を更新する(作用ブロック2706)。アンドゥ関数
に関する説明は、他に次のシミュレーション・モードの
詳細説明にもある。 【0201】自動アンドゥ:テープの始まりか、または
停止ボタンでテープを停止させるまで自動巻き戻しを行
う。また、自動アンドゥは、自動実行の影響を選択され
たアニメーション速度で完全に逆にする。図28は、自
動アンドゥ関数(AUTOUNDO)の流れ図である。 自動アンドゥ関数は、過去のリールがなくなるか、また
は停止関数が呼び出されるまで(判断2804)、アン
ドゥ関数を繰り返し呼び出す(作用ブロック2802)
。 【0202】UNDOおよびAUTOUNDOは、完全
なアンドゥ機構である。再生(およびその視覚的な副作
用)の影響は、何れかの制御を使用している間に完全に
元どうりになる。これにより、デバッグおよび検査に対
する簡単で効果的な手段が与えられる。シナリオを途中
で停止させ、特定の点まで巻き戻し、変更してから、マ
ウスを数回クリックして先を続けることができる。オブ
ジェクトの状態の変化および処理の動的なアニメーショ
ンによって、デバッグまたは検査の間に、または活動し
ている対象を単に見ている間に、視覚的なフィードバッ
クが連続的に与えられる。 【0203】仕様の誤りは、シミュレーションの後続部
分が間違っているか、または矛盾することを利用者に警
告する警告メッセージが印字される契機となる。この不
完全性を(一時的に)無視して、設計の他の要素を継続
することは利用者の自由である。シミュレーション・エ
ラーは、誤ったデータ、不正な規則または規則の不正な
組み合わせの何れかによって発生する。利用者は、アン
ドゥや再生を行って仕様に目を通し、間違ったデータま
たは規則の場所を突き止めたのち、それらをその場で編
集し、さらに再生を用いてシミュレーションを継続する
ことができる。 【0204】VSMの範囲内でソフトコーダの仮想機械
を使用することにより、利用者は、その動作の例の中か
らプログラムを指定することが許される。VSMにおけ
る画像的なシミュレーションは、画像フレームの単純な
列ではなく、「プログラム可能な映画」である。つまり
、利用者の入力データによって、映画の結末は異なった
ものになる。 【0205】特定のシナリオの各ステップを順番に実行
すると、そのシナリオ例が新たに再生されるが、その再
生は、入力されたとおり行われるが、前に供給されたア
クタ入力またはその特定のシナリオに関係する他の例の
シナリオ入力がある場合、それによって修正されたとお
りに行われる。その例によって記述される動作は、さら
にアクタのデータを追加したり、模範的なシナリオを追
加することによって、対話的に1つのプログラムへと洗
練することができる。アクタ系の動作は、アクタの状態
の変化に応じて変化し、新たなデータがアクタ間で交わ
される。アクタの状態、実行された処理、および通信中
に交わされる情報に関する他の情報の変更、削除、また
は追加を行うために、アクタおよび動作規則は、何時で
も編集することができる。アクタの状態および画像表現
の変更は、利用者の裁量によって、永久的であるか局部
的であるかの何れかであればよい(可逆的)。結果とし
て得られる規則が、テープ・プログラムを形成する。 【0206】ソフトコーダのシミュレーション・モード
テープ・プログラムは、スクリプト規則と一般スクリプ
トの集まりであるが、(部分的な)優先順位を持つ動作
の集まりでもある。テープの全体的な順序化は、テープ
・シナリオの生成をもたらすテープ・プログラムのシミ
ュレーションによって実行時に見られるに過ぎない、ソ
フトコーダは、4つのシミュレーション・モードを有す
る。即ち、(1)連続モード、(2)スマート・モード
、(3)同時モード、(4)生成モードである。 【0207】4つのシミュレーション・モードは、同一
のテープを再生する、つまり1つの使用を実行する4つ
の異なる方法に対応する。これらの4つのモードは、進
歩する洗練段階に相当し、それらの段階は、単純に連続
するシナリオから始まり、種々の状況において所与の特
徴(異なるデータ、実行の異なる道筋、エラー処理、同
時性)をシミュレートできる実行可能な規則ベースで終
わる。 【0208】連続シミュレーション・モードの視覚的な
表現を図30に示す。連続シミュレーション・モードで
は、各スクリプト規則および一般スクリプトが、テープ
が本来記録された順序で再生される。固定ヘッド303
0は、発動された最後のスクリプト上に常に位置する。 【0209】スマート・シミュレーション・モードの視
覚的な表現を図31に示す。スマート・シミュレーショ
ン・モードでは、各スクリプト規則は、それが現在のテ
ープ・ステージから論理的に実行(発動)されるべきか
どうかを調べるために、実行前に検査される。発動され
得る最初のスクリプト規則が、発動され、テープの未来
のリール3120から過去のリール3110へと移され
、中間のスクリプト規則は省略される。 【0210】同時シミュレーション・モードの視覚表現
を図32に示す。同時シミュレーション・モードは、ス
マート・シミュレーション・モードの拡張である。この
モードでは、各スクリプト規則は、それが現在のテープ
状態から論理的に発動さ得るかどうかを調べるために、
実行前に検査される。同時に発動可能なスクリプト規則
のグループがあることもしばしばある。このような場合
、同時シミュレーション・モードによって、並列実行を
用いてスクリプト規則を同時に発動することが許される
。 【0211】生成シミュレーション・モードは、同時シ
ミュレーション・モードの拡張である。このモードでは
、テープが閉ループに接着され、スクリプト規則および
一般スクリプトのシーケンスを繰り返し発動することが
できる。このモードは、同時発動がある標準的な生成規
則システムに類似している。さらに、この生成モードで
は、時間依存性および完全な可逆的実行がサポートされ
る。繰り返し発動するスクリプト規則の集合によって形
成されるループは、終端条件(例えば、カウンタが所定
の値に達するなど)が満たされるまで実行し続ける。 【0212】仮定:PRおよびFRが、ソフトコーダに
ロードされた現在のテープ・プログラムの過去および未
来のリールをそれぞれ示すものとする。また、f、r、
u、およびlaが、ソフトコーダの固定ヘッド、記録ヘ
ッド、Undoヘッド、および先取り(look−ah
ead)ヘッドであるとする。時刻tにおいて、 PR(t)=(U1,U2,...,Unt)FR(t
)=(R1,R2,...,Rpt)連続シミュレーシ
ョン・モードでは、各スクリプト規則および一般スクリ
プトは、テープが本来記録された順番に再生される。固
定ヘッドは、常に、最後に発動されたスクリプト上に位
置する。 【0213】連続モードは、次のように実現される。 1)PR(t)およびFR(t)は、2つのスタック・
オブジェクトの現在の内容を表す。 2)次のスクリプト規則を再生するためには:時刻tに
おいて、f(t)をFRスタックの最も上にある規則R
1に最初に結合する。規則R1は、そのアクタおよび視
覚的効果(画像的なアンドゥ・コマンドの集合)に対す
るアンドゥ(回復)表現を生成し記録することにより、
アンドゥを行う準備がなされ、その規則は、アンドゥ可
能型と印が付けられて、u(t)となる。次に、f(t
)=R1というメッセージが、センダのアクタからレシ
ーバのアクタへと送られ、f(t)からの事後条件が(
そのアクタの属性をいくつか変更して)実行され、対応
する視覚効果が表示され、FRスタックが一回ポップ(
pop)され、さらにu(t)は、それがU1となりt
が単位時間だけインクリメントされるPRスタックへと
プッシュ(push)される。発動可能な規則が見つか
らない場合、再生が停止し、テープ・プログラムの終了
したことが利用者に知らされる。 3)記録の場合、r(t)は、記録直後の規則を示し、
FRスタックにプッシュされ、次のステップが時刻tで
再生される。 4)アンドゥを1ステップ行う場合、u(t)は、U1
をアンドゥする次の規則を示す。この規則の事実上の影
響は、オプションのメッセージ表示も含めて、元どうり
にされ、そのアクタのアンドゥ表現は、この規則が発動
される前の初期状態までそれらを復元しながら、実行さ
れる。アンドゥ表現はu(t)から削除され、元の型の
規則が復元され、それがf(t)となり、PRスタック
が一度ポップされ、さらにf(t)は、それがR1とな
りtが単位時間だけデクリメントされるFRスタック上
にプッシュされる。 5)自動再生するには、FRスタックが空になり、他の
規則が記録されていなくなるまで、再生ステップを反復
する。 6)自動アンドゥをするには、PRスタックが空になる
まで、アンドゥ・ステップを繰り返す。 7)停止するには、最後の規則の実行またはアンドゥが
完全に行われた後(例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど)、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【0214】スマート・シミュレーション・モードでは
、各スクリプト規則は、それが現在のテープ・ステージ
から論理的に実行(発動)されるべきかどうかを調べる
ために、実行前に検査される。発動可能な最初のスクリ
プト規則が、発動され、テープの未来のリールから過去
のリールへと移され、中間のスクリプト規則は省略され
る。 【0215】スマート・モードは次のように実現される
。 1)PR(t)およびFR(t)は、2つのスタック・
オブジェクトの現在の内容を表す。 2)次のスクリプト規則を再生するためには:時刻tに
おいて、f(t)をFRスタックの最も上にある規則R
1に結合する。この規則の事前条件が検査され、条件が
満たされない場合は、FRスタックがポップされ、f(
t)がPRにプッシュされ(この規則はアンドゥ可能型
には変更されない)、条件が満たされる場合には、この
規則は、そのアクタおよび視覚的効果(画像的なアンド
ゥ・コマンドの集合)に対するアンドゥ(回復)表現を
生成し記録することにより、アンドゥを行う準備がなさ
れ、その規則は、アンドゥ可能型と印が付けられて、u
(t)となる。次に、f(t)=R1というメッセージ
が、センダのアクタからレシーバのアクタへと送られ、
f(t)からの事後条件が(そのアクタの属性をいくつ
か変更して)実行され、対応する視覚効果が表示され、
FRスタックが一回ポップされ、さらにu(t)は、そ
れがU1となりtが単位時間だけインクリメントされる
PRスタックへとプッシュされる。発動可能な規則が見
つからない場合、再生が停止し、テープ・プログラムの
終了したことが利用者に知らされる。 3)記録の場合、r(t)は、記録直後の規則を示し、
FRスタックにプッシュされ、次のステップが時刻tで
再生される。 4)アンドゥを1ステップ行う場合、u(t)は、U1
をアンドゥする次の規則を示す。U1がアンドゥ可能型
でない場合、スタックPRがポップされ、u(t)がF
R上にプッシュされる。U1がアンドゥ可能型の場合、
この規則の事実上の影響は、オプションのメッセージ表
示も含めて、元どうりにされ、そのアクタのアンドゥ表
現が実行されて、この規則が発動される前の初期状態に
までそれらを復元する。アンドゥ表現はu(t)から削
除され、元の型の規則が復元され、それがf(t)とな
り、PRスタックが一度ポップされ、さらにf(t)は
、それがR1となりtが単位時間だけデクリメントされ
るFRスタック上にプッシュされる。 5)自動再生するには、利用者の入力が要求されるか、
またはFRスタックが空になり、かつ他の規則が記録さ
れていなくなるまで、再生ステップを反復する。 6)自動アンドゥをするには、PRスタックが空になる
まで、アンドゥ・ステップを繰り返す。 7)停止するには、最後の規則の実行またはアンドゥが
完全に行われた後(例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど)、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【0216】同時シミュレーション・モードは、スマー
ト・シミュレーション・モードの拡張である。このモー
ドでは、各スクリプト規則は、それが現在のテープ状態
から論理的に発動さ得るかどうかを調べるために、実行
前に検査される。同時に発動可能なスクリプト規則のグ
ループがあることもしばしばある。このような場合、同
時シミュレーション・モードによって、並列実行を用い
てスクリプト規則を同時に発動することが許される。 【0217】同時モードは次のように実現される。 1)PR(t)は、スタック・オブジェクトの現在の内
容を表し、FR(t)は、スタック=シーケンス・オブ
ジェクトの結合体の内容である。つまり、FRは、プッ
シュおよびポップを行うことができるスタックであると
同時に、ポップ操作もプッシュ操作もない直接アクセス
による探索および修正が可能なシーケンスでもある。 2)次のスクリプト規則を再生するためには:時刻tに
おいて、f(t)をFRスタックの最も上にある規則R
1に結合する。この規則の事前条件が検査され、条件が
満たされない場合またはその規則が既にグループ型と印
が付けられている場合、FRスタックがポップされ、f
(t)がPRにプッシュされ(この規則はアンドゥ可能
型には変更されない)、条件が満たされる場合(この規
則は時刻tにおいて発動可能であると言う)には、それ
は最初の発動可能な規則であり、f(t)は、グループ
型と記され、それ自体のGroup−Saddress
フィールドに追加され、f(t)として存続し、la(
t)がFR(t)に適用される。発動可能な規則が見つ
からない場合、再生が停止され、テープ・プログラムの
最後に達したことが利用者に知らされる。先取り処理で
は、la(t)がFR(t)全体の高速探査を行って他
のすべての発動可能な規則を一度に集め、発見された各
規則がグループ型と記され、続いて、la(t)によっ
て発見された規則の集合がf(t)の現在のGroup
−Saddress集合(これは、最初は{f(t)}
である)に結合される。 グループ型のf(t)規則は、そのすべてのアクタ(そ
のGroup−Saddress集合からのアクタ)お
よび視覚的効果(画像的なアンドゥ・コマンドの集合)
に対するアンドゥ(回復)表現を生成し記録することに
より、アンドゥを行う準備がなされ、その規則集合が、
アンドゥ可能グループの型と印が付けられて、u(t)
となる。次に、f(t)=R1のGroup−Sadd
ressからのメッセージ集合が、センダのアクタの集
合からレシーバのアクタの集合へと並列に送られ、f(
t)のGroup−Saddressからの事後条件が
、その集合の各規則に対する別個の背景条件において、
対応するアクタの属性をいくつか変更して並列的に実行
され、対応する視覚効果が表示され、FRスタックが一
回ポップされ、さらにu(t)は、それがU1となりt
が単位時間だけインクリメントされるPRスタックへと
プッシュされる。 3)記録の場合、r(t)は、記録直後の規則を示し、
FRスタックにプッシュされ、次のステップが時刻tで
再生される。 4)アンドゥを1ステップ行う場合、u(t)は、U1
をアンドゥする次の規則を示す。U1がアンドゥ可能型
でない場合、スタックPRがポップされ、u(t)がF
R上にプッシュされる。u(t)のGroup−Sad
dressの規則と同様に、U1がアンドゥ可能型の場
合、各規則の事実上の影響は、(オプションのメッセー
ジ表示も含めて)元どうりにされ、そのアクタのアンド
ゥ表現が実行されて、この規則が発動される前の初期状
態にまでそれらを復元し、アンドゥ表現がu(t)から
削除され、元の型の各規則が復元され、最も上の規則が
f(t)となり、PRスタックが一度ポップされ、さら
にf(t)は、それがR1となりtが単位時間だけデク
リメントされるFRスタック上にプッシュされる。 5)自動再生するには、利用者の入力が要求されるか、
またはFRスタックが空になり、かつ他の規則が記録さ
れていなくなるまで、再生ステップを反復する。 6)自動アンドゥをするには、PRスタックが空になる
まで、アンドゥ・ステップを繰り返す。 7)停止するには、最後の規則の実行またはアンドゥが
完全に行われた後(例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど)、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【0218】生成シミュレーション・モードは、同時シ
ミュレーション・モードの拡張である。このモードでは
、テープが閉ループに接着されるので、一連のスクリプ
ト規則および一般スクリプトを繰り返し発動することが
できる。このモードは、同時発動がある標準的な生成規
則システムに類似している。さらに、この生成モードで
は、時間依存性および完全な可逆的実行がサポートされ
る。繰り返し発動するスクリプト規則の集合によって形
成されるループは、終端条件(例えば、カウンタが満期
になるなど)が満たされるまで実行し続ける。 【0219】生成モードは、次のように実現される。 1)PR(t)は、スタック・オブジェクトの現在の内
容を表し、FR(t)は、シーケンス=ハッシュ・テー
ブル=格子オブジェクトの結合体の内容である。つまり
、FRは、ハッシュ・テーブル、即ちキーが符号化され
た一種のコンピュータ・オブジェクトであるため、FR
にいかに多くのスクリプト規則が格納されていても、ス
クリプト規則をその記号的参照情報(Sid)によって
効率的に検索することができる。FRは、所与の規則集
合の後に発動できる次の規則集合がFRの限られた部分
集合に含まれることが分かるように、予め計算された相
互間の論理的依存状態に基づいてスクリプト構造体が予
め配列されているような格子である。生成モードにおい
ては、再生、自動再生、アンドゥ、または自動アンドゥ
の最中にFRは(例えば、ポップやプッシュによって)
変更されない。しかし、FRは、スクリプト規則の記録
および消去(削除)の間に変更され再構成される。再生
またはアンドゥの間に記録も消去も起こらないと仮定し
て、FR=(R1,R2,...,Rp)とする。時刻
tにおいて、pt≦pとしたSFR(t)=S(FR,
t)=(R1,R2,...,Rpt)を時刻tに発動
するべき候補であるスクリプト規則のFRからの有限部
分集合とする。SFRは、tの前に発動された規則を知
ることによってFR格子から得られる。 2)次のスクリプト規則を再生するためには:f(t)
をSFR(t)からの最初の規則である規則R1に結合
する。この規則の事前条件が検査され、条件が満たされ
ない場合、その規則は無視され、f(t)は、SFR(
t)からの次の規則のインスタンスに結合され、それは
、f(t)が発動可能な規則となるかSFR(t)から
のすべての規則が不成功のうちに検査されるまで、検査
される。この時点で、発動可能な規則が見つからない場
合、f(t)は、待機型またはアンドゥ可能型の規則の
インスタンスに結合され、f(t)はPR上にプッシュ
され、tが単位時間だけインクリメントされる。f(t
)の事前条件が満たされる、即ち時刻tにおいて規則が
発動可能である場合、それはSFRからの最初の発動可
能な規則であり、元の規則を変更することを防止するた
めにf(t)は、それ自体のインスタンスによって置き
換えられ、グループ型と印が付けられ、それ自体のGr
oup−Saddressフィールドに加えられる。そ
れは、f(t)として存続し、la(t)がSFR(t
)に適用される。先取り処理では、la(t)がSFR
(t)全体の高速探査を行って時刻tにおいて発動可能
な他のすべての規則を集め、発見された各規則はグルー
プ型と印を付けられたそれ自体のインスタンスとして集
められ、続いて、la(t)によって収集された規則イ
ンスタンスの集合がf(t)の現在のGroup−Sa
ddress集合(これは、最初は{f(t)}である
)に結合される。グループ型のf(t)規則は、そのす
べてのアクタ(そのGroup−Saddress集合
からのアクタ)および視覚的効果(画像的なアンドゥ・
コマンドの集合)に対するアンドゥ(回復)表現を生成
し記録することにより、アンドゥを行う準備がなされ、
その規則集合が、アンドゥ可能グループの型と印が付け
られて、u(t)となる。次に、f(t)=R1のGr
oup−Saddressからのメッセージ集合が、セ
ンダのアクタの集合からレシーバのアクタの集合へと並
列に送られ、f(t)のGroup−Saddress
からの事後条件が、その集合の各規則に対する別個の背
景条件において、対応するアクタの属性をいくつか変更
して並列的に実行される。対応する視覚効果が表示され
、さらにu(t)は、それがU1となりtが単位時間だ
けインクリメントされるPRスタックへとプッシュされ
る。 3)記録の場合、r(t)は、記録直後の規則を示し、
SFR(t)の要素としてFR格子に挿入され、必要で
あれば前の配列を復元するためにFR格子が再計算され
て、時刻tにおいて次のステップが再生される。 4)アンドゥを1ステップ行う場合、u(t)は、U1
をアンドゥする次の規則を示す。U1がアンドゥ可能型
でない場合、誤りが存在する。U1がアンドゥ可能で待
機型の場合、U1は捨てられ、tが単位時間だけデクリ
メントされる。U1が、アンドゥ可能で待機(グループ
)型でない場合、u(t)のGroup−Saddre
ssの規則と同様に、各規則の事実上の影響は、オプシ
ョンのメッセージ表示も含めて、元どうりにされ、その
アクタのアンドゥ表現が実行されて、この規則が発動さ
れる前の初期状態にまでそれらを復元し、アンドゥ表現
がu(t)から削除され、元の型の各規則が復元され、
最も上の規則がf(t)となり、PRスタックが一度ポ
ップされ、さらにf(t)はそのまま存続し、tが単位
時間だけデクリメントされる。 5)自動再生するには、利用者の入力が要求されるか、
または停止ボタンが押されるまで、再生ステップを反復
する。 6)自動アンドゥをするには、PRスタックが空になる
まで、アンドゥ・ステップを繰り返す。 7)停止するには、最後の規則の実行またはアンドゥが
完全に行われた後(例えば、アクタ間の通信の割り込み
不可能な並列実行が終了したときなど)、現在の自動再
生または自動アンドゥのシーケンスに割り込みをかける
。 【0220】動作の規則の記録、消去、および照会GR
ASの使用およびソフトコーダの実行能力におけるいく
つかの利点は、何時でも変更を行い、機械の処理能力に
限定される穏当な時間でその変更を自動的に有効にする
柔軟性に由来するものである。上述の再生およびアンド
ゥの機構は、ソフトコーダによって提供されるそのよう
な柔軟な処理モデルの実例である。テープ・プログラム
のシミュレーションの最中にアクタ間の新たな通信を記
録したり、関係する動作規則を取り除いたりできること
も、仕様決定、システム設計、および試験に対するソフ
トコーダ方式の威力の例である。 【0221】アクタ間の動作規則を記録するには、3つ
のステップが必要である。 1)ビジュアル・プログラミング:ビジュアル・クルー
(clue)、タイプ入力、メニュー項目によって収集
された必要な情報を用いて、基本的なスクリプト構造体
を生成する。 2)規則の挿入:現在の規則ベースに新たなスクリプト
構造体を挿入する。 3)修正されたテープ・プログラムを(前節の説明のよ
うに)さらに一段階再生する。 【0222】ビジュアル・プログラミング:GRAS画
面上で現在活性なビデオ・モニタのうちの1つからセン
ダのアクタとレシーバのアクタを選択したり、メニュー
選択およびキーワード捜索をしたり、バックステージか
らアクタを検索するためにオーディション表現を選択し
たりすることによって、基本的なスクリプト構造体R0
を作る。オーディション表現は、利用者によって編集お
よびカスタマイズすることも可能である。スクリプト構
造体R0は、記号による新たな参照情報(Sid)が与
えられ、センダおよびレシーバの属性には、選択された
アクタ(またはアクタのオーディション記述)が書き込
まれ、センダおよびレシーバのT(真)に対するデフォ
ルトの事前条件が定義され、事後条件は全く定義されな
い。次に、新たなメッセージを(利用者がタイプ入力で
)指定するか、またはメニューと既存のスクリプト構造
体の集合に対するキーワード捜索とによって選択する。 新たなメッセージが指定された場合、R0のメッセージ
・フィールドには、指定されたメッセージが書き込まれ
る。既存のスクリプト構造体R1が選択された場合、R
1の事前条件と事後条件とメッセージ表現とのインスタ
ンスが生成され、R0の対応するフィールドを埋めるた
めに使用される。何れの場合も、新たに記録された規則
が前に発動された規則の集合の結果として発動される可
能性を保証する必要があるならば、R0の事前条件が変
更される。例えば、R2の発動後にR0が記録される場
合、「R0はR1の後に発動しなければならない」とい
うデフォルトの事前条件が、目標の規則記述言語で生成
される。 【0223】規則の挿入:この点において、規則R0は
、未来のリールに挿入する用意ができている。連続、ス
マート、および同時の各モードにおいては、R0は、単
にFRスタックの上にプッシュされ、このとき2つの記
録モードが可能である。 【0224】1)接続モードでは、発動するべきR0の
前例(前記の例ではR1)に以前は依存していたFR内
のすべての規則は、発動をR0に現在依存するように、
自動的に更新される。FRにおけるある規則の事前条件
は、そのように変更される。 【0225】2)並列モードでは、FRの何れの規則も
変更されず、従って、R0は、正常ならば前例の後に(
前記の例では、R1の後に)発動するはずの他の規則と
平行して発動すると予測される。生成モードでは、R0
は、SFR(t)に最初の要素として挿入され、FRの
格子構造の変更は、自動的に計算されるが、この場合、
記録モードに依存する。 【0226】1)接続モードでは、発動するべきR0の
前例(前記の例ではR1)に以前は依存していたSFR
(t)内のすべての規則は、発動をR0に現在依存する
ように、自動的に更新される。SFR(t)におけるあ
る規則の事前条件は、そのように変更され、さらに変更
は、FR格子の組織内に伝えられる。 【0227】2)並列モードでは、SFR(t)の何れ
の規則も変更されず、従って、R0は、正常ならば前例
の後に(前記の例では、R1の後に)発動するはずのS
FR(t)からの他の規則と平行して発動すると予測さ
れる。 【0228】既存の動作規則を消去する場合、ソフトコ
ーダによって提供される基本的な操作により、発動され
た最後のスクリプト規則を利用者が削除できる。この最
後の規則がグループ型の場合、利用者は、その集合から
規則を1つ選択するように促される。次に、テープ・プ
ログラムが1ステップだけ戻されて、選択されたスクリ
プト構造体がFR(または生成モードではSFR)から
削除される。そして、発動のために削除された規則にか
つて依存していたすべての規則に、発動のために依存す
るのに最適な代替規則が与えられる。生成モードでは、
次に、FRの格子構造が再編成され、規則の間の新たな
予配列が生じる。次に、その変化の影響を表示するため
に、テープ・プログラムが1ステップだけ再生され、削
除された規則に代わって別の規則が発動することになる
。規則集合の大きな塊を消去する場合、規則集合の一部
を切り取って捨てる方法が、フィルム・エディタによっ
て提供される。 【0229】ある型の規則(または規則の部分集合)の
未来または過去の実行のための既存の規則集合への照会
は、テープ・プログラムの実行を利用者に取って関心の
ある点に迅速に位置付ける機構を提供する。ソフトコー
ダの進歩したプログラム実行性を用いれば、実行履歴ま
たは実行の将来における所望の位置へテープ・プログラ
ムを自動的に位置決めすることを要求することができる
。これは、所望の点の例を記述する視覚的照会を記録し
、PRにおいて一致する一連の実行済み規則を捜し、照
合が成功した場合、必要とされるカウンタ位置への自動
アンドゥによってテープを位置決めし、成功しなかった
場合には、一致するまで自動再生を実行することにより
テープを位置決めする。 【0230】ビデオ・コネクタ ビデオ・コネクタは、GRASと異質のシステムとの間
の物理的または仮想的なデータ・リンクと結び付いたソ
フトウェアの通信プロトコルである。ビデオ・コネクタ
は、ビデオ信号源(カメラ、ミキサ、テレビ・ケーブル
)をVCRに連結する同軸ケーブルに似ている。しかし
、VSMでは、ビデオ・コネクタにより、外部のシステ
ムからテープへと事象を記録するとともに、外部のシス
テムからGRASを遠隔制御するための通信路が提供さ
れる。 【0231】GRASでは、利用者が処理を描写する(
指定する)のをカメラが追うように、利用者の対話から
得られる仕様をすべてのビデオ・モニタから記録するこ
とができる。記録中の各ビデオ・モニタは、アクタどお
しの間の作用がカメラで記録されるビデオ・スタジオの
一部である。ビデオ・スタジオ内のカメラは、仮想的な
ビデオ・コネクタによってソフトコーダに結合されてい
る。 【0232】ビデオ・コネクタのインタフェースは、ア
プリケーションがGRASにデータ跡を送ると同時にG
RASを遠隔制御できるように実現される。例えば、ア
プリケーションは、新たなテープを生成し、そのテープ
の遠隔記録(つまり、メッセージの照会)を開始し、詳
細水準を変更し、アニメーション・ビューを変更するこ
とができると同時に、GRASは、そのデータ跡の動画
化を同期モードまたは非同期モードで開始することがで
きる。所望により、アプリケーションは、使用される画
像表現を完全に制御することができる。GRASの遠隔
制御は、如何なる双方向データ・リンクによってもサポ
ート可能な標準のリモート・エバリュエーション・プロ
トコル(遠隔関数呼び出し)に基づく。 【0233】OOスクリプト OOスクリプトは、2つのアクタの間の単一処理を定義
する要素体である。OOスクリプトは、アクタの1つの
動作の一面を記述する最小の実体である。各OOスクリ
プトにより、センダおよびレシーバとして知られる1つ
または2つのアクタが関与する動作の1つの規則が記述
される。 【0234】オブジェクト対オブジェクトのスクリプト
(OOスクリプト)は、正式には、(スクリプト識別子
(sid),センダ,レシーバ,前提条件リスト(pr
econd−list),事後条件リスト(postc
ond−list),メッセージ,オプションの参考情
報)という数学的なタプル(特定数要素の集合)として
定義される。各OOスクリプトは、特有の識別子(si
d)に関係付けられている。「センダ」は、「レシーバ
」に呼び掛けるために「メッセージ」を発動する実体を
指す。「前提条件リスト(precond−list)
」は、OOスクリプトが活性化されるために満たされな
ければならない前提条件を与える。「事後条件リスト(
postcond−list)」は、そのOOスクリプ
トがの実行終了後には真となるべきシステムの事後条件
を与える。「メッセージ」は、オプションの引数を伴う
メッセージまたは関数の名前である。表された処理また
は関係するオブジェクトに関するコメントをオプション
の参考情報に含めることができる。 【0235】OOスクリプトのシンタックスを次に述べ
る。事前条件リストおよび事後条件リストは、両方とも
括弧で囲み、オプションの参考情報は、引用符(“ ”
)で囲む。引数のないメッセージは、それを囲む括弧を
付けても付けなくても良いが、引数付きのメッセージは
、引数を従えた第1の要素としてメッセージ名を伴う括
弧付きのリストとして表す。渡される文字データ・メッ
セージは、引用符で囲まれた文字列として示される。 【0236】OOスクリプトにより、センダがレシーバ
にメッセージを送る処理においてセンダとレシーバとの
間の相互作用を包含する規則が具体化される。メッセー
ジは、関数の呼び出し(例えば、プロシージャ・コール
の場合のような作用の要求)、データ伝送、またはその
両方で構成することができる。規則は、どの実体がセン
ダおよびレシーバであるか、前記のような相互作用が起
こる時期を支配する条件の記述、および相互作用の結果
である状態を指定する。スクリプトは、特定の状況また
は一連の事象に対するシステムの作用規則を包含するO
Oスクリプト集合である。 【0237】図2〜図5は、コンピュータのログイン手
順の仕様およびシミュレーションを与えるためにOOス
クリプトがどのように使用されるかの例を示す。図2は
、実施のコンピュータ手順の流れ図であり、図3は、コ
ンピュータのログイン手順の実施に使用される対応する
OOスクリプトを示し、図4および図5は、GRASに
よるログイン手順のシミュレーションの画像表示である
。 【0238】コンピュータ400は、端末410に「s
end−login」メッセージ405を送ることによ
ってコンピュータのログイン手順を開始する(作用ブロ
ック210)。開始ステップに対応するOOスクリプト
を図3のOOスクリプト310として示す。端末410
は、「send−login」メッセージ405に対し
、ログイン・プロンプト・メッセージ415を利用者4
20に表示して応答する(作用ブロック220およびO
Oスクリプト320)。ログイン・プロンプト・メッセ
ージ415に対し、利用者420は、自分のログイン・
ネームを端末のキーボード425上で入力することによ
って応答する(作用ブロック230およびOOスクリプ
ト330)。 手順の次のステップは、GRASの詳細水準に依存する
。前記のように、OOスクリプト識別子によって、多重
詳細水準が可能である。詳細水準が高いほど、経験がよ
り豊かな利用者のためのシナリオの深入りしたステップ
まで示されるが、詳細水準が低くなると、要約水準の高
いシミュレーションが示される。詳細水準を「1」と決
定した場合(判断240)、水準が低い方の2つのステ
ップがシミュレートされ(図5)てから、次の水準「0
」のステップがシミュレートされる。詳細水準が「1」
の場合(判断240)、端末510は、利用者のキーボ
ード入力内容525をログイン・ネーム・データ・メッ
セージ535によってコンピュータ500へ送る(作用
ブロック245およびOOスクリプト340)。 次に、コンピュータ500が、利用者520と共にパス
ワード入力手順を開始するようにメッセージ545を端
末510に送る(作用ブロック247およびOOスクリ
プト350)。シミュレーションの次のステップは、水
準0および水準1の両方に対して同じである。そのシミ
ュレーションに付いては、図4を参照する。端末410
が、「パスワード・プロンプト」メッセージ435を利
用者に送る(作用ブロック250およびOOスクリプト
360)。次に、利用者420が、キーボードでパスワ
ードを入力すことによって、パスワード・データ445
を端末410に送る(作用ブロック260およびOOス
クリプト370)。そして、シミュレーションの詳細水
準が「0」か「1」かをGRASシステムが判断する(
判断470)。詳細水準が「0」ならば、そのシミュレ
ーションは終了する(作用ブロック280)が、詳細水
準が「1」の場合(図5参照)は、端末510が、パス
ワード・データ・メッセージ575をコンピュータ50
0に送る(作用ブロック275およびOOスクリプト3
80)。そして、シミュレーションが終了する。 【0239】以上の説明は、本発明の一実施例に関する
もので、この技術分野の当業者であれば、本発明の種々
の変形例が考えられるが、それらはいずれも本発明の技
術的範囲に包含される。 【0240】 【発明の効果】以上述べたように、本発明によれば、プ
ログラム仕様についての労力をあまり要求することなく
、プログラムの作用をいっそう完璧にモデル化してプロ
グラム仕様を作ることができる。
【図1】GRASシステムの概念的構造のブロック図で
ある。
ある。
【図2】GRASシステムを用いて指定するべきコンピ
ュータ・ログイン・シーケンスの流れ図である。
ュータ・ログイン・シーケンスの流れ図である。
【図3】コンピュータ・ログイン・シーケンスを指定す
るためのスクリプトの内容を例示するデータ図である。
るためのスクリプトの内容を例示するデータ図である。
【図4】コンピュータ・ログイン・シーケンスを模擬実
験した後のGRASシステムの表示を例示する図である
。
験した後のGRASシステムの表示を例示する図である
。
【図5】コンピュータ・ログイン・シーケンスを模擬実
験した後のGRASシステムの表示を例示する図である
。
験した後のGRASシステムの表示を例示する図である
。
【図6】GRASシステムの種々の関数を例示する流れ
図である。
図である。
【図7】GRASシステムの種々の関数を例示する流れ
図である。
図である。
【図8】GRASシステムの種々の関数を例示する流れ
図である。
図である。
【図9】GRASシステムの種々の関数を例示する流れ
図である。
図である。
【図10】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図11】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図12】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図13】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図14】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図15】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図16】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図17】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図18】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図19】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図20】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図21】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図22】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図23】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図24】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図25】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図26】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図27】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図28】GRASシステムの種々の関数を例示する流
れ図である。
れ図である。
【図29】ビデオ・スタジオ・メタファ(VSM)によ
る、GRASシステムのシミュレーション・モードを例
示する図である。
る、GRASシステムのシミュレーション・モードを例
示する図である。
【図30】ビデオ・スタジオ・メタファ(VSM)によ
る、GRASシステムのシミュレーション・モードを例
示する図である。
る、GRASシステムのシミュレーション・モードを例
示する図である。
【図31】ビデオ・スタジオ・メタファ(VSM)によ
る、GRASシステムのシミュレーション・モードを例
示する図である。
る、GRASシステムのシミュレーション・モードを例
示する図である。
【図32】ビデオ・スタジオ・メタファ(VSM)によ
る、GRASシステムのシミュレーション・モードを例
示する図である。
る、GRASシステムのシミュレーション・モードを例
示する図である。
100 VSMインタフェース
110 ビジュアル・オブジェクト網管理モジュール(
MOVON) 111、121、および131双方向メッセージ・リン
ク 120 ソフトウェア・ビデオ・レコーダ・モジュール
(SOFTCODER) 130 ビデオ・コネクタ
・モジュール(VC) 140 アクタ・フレーム・モジュール(AF)160
プレスクリプト・モジュール(PRESCRIPT) 170 ウィンドウおよびグラフィックの諸機能(WG
) 175 オペレーティング・システム(OS)1
76 ハードウェア(HW) 180 Common Lisp(CL)185 ファ
イル・システム(FS) 186 ネットワーク(NW)
MOVON) 111、121、および131双方向メッセージ・リン
ク 120 ソフトウェア・ビデオ・レコーダ・モジュール
(SOFTCODER) 130 ビデオ・コネクタ
・モジュール(VC) 140 アクタ・フレーム・モジュール(AF)160
プレスクリプト・モジュール(PRESCRIPT) 170 ウィンドウおよびグラフィックの諸機能(WG
) 175 オペレーティング・システム(OS)1
76 ハードウェア(HW) 180 Common Lisp(CL)185 ファ
イル・システム(FS) 186 ネットワーク(NW)
Claims (40)
- 【請求項1】 コンピュータ・プログラムのための仕
様を対話的に生成するコンピュータ・システムにおいて
、入力装置を介して受信可能なアクタ・データの受信に
応じて、複数のテープ・シナリオにおいて使用するため
のアクタを指定して、前記アクタに対するデータを格納
し、前記指定が、新たなアクタの生成、以前に生成され
たアクタの選択、およびアクタ・データの修正を含むス
テップと、複数のシナリオの作用ステップに対し前記入
力装置を介して受信可能な仕様データを受信し、これに
応じて引き続き実行するために、前記アクタ間の通信、
前記アクタ間の関係、前記アクタに対する論理的または
算術的な演算、および前記複数のシナリオに対する判断
点を格納するステップと、前記入力装置を介して判断の
選択を受信し、以後それに応じてシナリオのステップを
実行する実行ステップとを備え、前記実行ステップが、
前記作用ステップのうちのいくつかのステップに対する
所定の条件が発生により、前記作用ステップのうちの前
記いくつかのステップをシミュレートするシミュレーシ
ョン・ステップと、前記シミュレーションの結果を格納
する格納ステップとを含み、さらに前記シミュレーショ
ンが、前記アクタ間の通信の実行、前記アクタ間の関係
の表明、前記アクタに対する論理的または算術的な演算
の実行、または判断選択の入力の各ステップのうちの少
なくとも1つは含むことを特徴とするプログラム仕様の
対話的な設計を支援する方法。 - 【請求項2】 前記実行ステップが、前記アクタ間の
通信の実行、前記アクタ間の関係の表明、前記アクタに
対する論理的または算術的な演算の実行のステップをす
べて備えたことを特徴とする請求項1記載の方法。 - 【請求項3】 前記実行ステップが、判断選択の入力
を要求するステップをさらに備えたことを特徴とする請
求項2記載の方法。 - 【請求項4】 前記入力装置が、グラフィカルな表示
を指定するためのものであり、前記シミュレーション・
ステップが、前記作用ステップのうちの前記いくつかの
ステップのうちのいくつかをグラフィカルに動画表示す
るステップをさらに含むことを特徴とする請求項1記載
の方法。 - 【請求項5】 前記作用ステップのうちの前記いくつ
かのステップの前記シミュレーションの最中に前記入力
装置を介して受信された指示に応じて、前記作用ステッ
プのうちの1つをシミュレートした後、前記シミュレー
ションを停止するステップと、前記入力装置を介して入
力データを受信し、これに応じて、追加的なアクタまた
は追加的な作用ステップを格納するステップと、前記入
力装置を介して受信した別の指示に応じて、前記の追加
的なアクタまたは追加的な作用ステップを含む前記作用
ステップの前記シミュレーションを再開するステップと
をさらに備えたことを特徴とする請求項1記載の方法。 - 【請求項6】 前記作用ステップの前記シミュレーシ
ョンの最中に前記入力装置を介して受信した指示に応じ
て、前記作用ステップの前記シミュレーションを次々と
逆処理し、前記作用ステップのうちの特定のステップを
逆処理した後、前記逆処理を停止する逆処理ステップと
、前記入力装置を介して受信した入力データに応じて、
前記作用ステップのうちの前記特定のステップを修正す
るステップと、前記入力装置を介して受信した別の指示
に応じて、前記作用ステップのうちの前記特定のステッ
プで前記シミュレーションを再開するステップとをさら
に備えたことを特徴とする請求項1記載の方法。 - 【請求項7】 前記逆処理ステップが、前記シミュレ
ーションの前記結果を次々と削除することを含むことを
特徴とする請求項6記載の方法。 - 【請求項8】 前記シミュレーションス・テップが、
プログラム経路の指定されていない判断点の選択を自動
的に識別することも含むことを特徴とする請求項1記載
の方法。 - 【請求項9】 他のプログラム仕様システムから情報
を受信する複数のシナリオにおける点である入力点を前
記入力装置を介して受信し、これに応じて、前記の入力
点を特定するデータを格納するステップをさらに備えた
ことを特徴とする請求項1記載の方法。 - 【請求項10】 アクタ間の通信、アクタ間の関係、
アクタに対する論理的または算術的な演算、およびアク
タに対する判断点のうちの少なくとも1つを指定する規
則を複数備えたテープ・プログラムを構成するステップ
をさらに備えたことを特徴とする請求項1記載の方法。 - 【請求項11】 テープ・プログラムの集合を結合し
て、新たなシナリオ・グループを実行するための単一の
合成テープ・プログラムにする結合ステップをさらに備
えたことを特徴とする請求項10記載の方法。 - 【請求項12】 前記結合ステップが、前記複数の規
則の集合合併体を実行することを含むことを特徴とする
請求項11記載の方法。 - 【請求項13】 前記アクタの各々がデータ集合を含
み、前記シミュレーションステップが、アクタのデータ
が前記作用ステップのうちの前記いくつかのステップを
実行するのに十分かどうかを確かめるステップをさらに
備えたことを特徴とする請求項1記載の方法。 - 【請求項14】 アクタのデータが不十分であること
を利用者に知らせるステップをさらに備えたことを特徴
とする請求項13記載の方法。 - 【請求項15】 アクタのデータに対して行われた変
更の履歴のデーターベースが前記データ集合に含まれ、
前記格納ステップが、前記アクタ・データへの変更を前
記履歴データーベースに格納することを含むことを特徴
とする請求項13記載の方法。 - 【請求項16】 前記のアクタの履歴データーベース
における変更に応じて、アクタのグラフィカルな表示を
変更するステップをさらに備えたことを特徴とする請求
項15記載の方法。 - 【請求項17】 複数水準のシミュレーションを利用
することが可能で、各シミュレーションに対しシミュレ
ーション水準の集合を個別に指定しても良く、各作用ス
テップに対して、シミュレーション水準を確認するステ
ップと、前記作用ステップの1つの結果を格納するとき
に、前記作用ステップの前記結果をその適切なシミュレ
ーション水準で格納するステップをさらに備えたことを
特徴とする請求項1記載の方法。 - 【請求項18】 複数の表示水準を利用することが可
能で、前記表示水準の各々がシミュレーション水準に対
応し、各作用ステップに対してシミュレーション水準の
集合を確認するステップと、シナリオを実行するときに
、前記集合の要素である水準に等しいか、それを下回る
ような作用ステップに対してのみ、結果を表示するステ
ップをさらに備えたことを特徴とする請求項17記載の
方法。 - 【請求項19】 前記シナリオの前記作用ステップの
1つのシミュレーションが、1つのアクタから他のアク
タへと記号的メッセージを送ることを含むことを特徴と
する請求項1記載の方法。 - 【請求項20】 各アクタがデータ集合を含み、前記
シミュレーションステップが、作用ステップのシミュレ
ーションの一部としてアクタ・データを変更する変更ス
テップを含み、その変更ステップが、そのアクタの属性
の追加または削除を含むことを特徴とする請求項19記
載の方法。 - 【請求項21】 前記変更ステップが、既存のアクタ
・データおよびそのアクタによって受信されたメッセー
ジ・データの関数として変更することを含むことを特徴
とする請求項20記載の方法。 - 【請求項22】 所定の状態の発生が、前記作用ステ
ップの2つ以上のステップの同時シミュレーションの契
機となり、前記の同時発生する作用ステップに共通のア
クタがある場合、その共通のアクタのデータをアクセス
しようとする他のアクタが、その同じデータを同時にア
クセスしないことを保証する保証ステップをさらに備え
たことを特徴とする請求項1記載の方法。 - 【請求項23】 前記保証ステップが、ある作用ステ
ップのシミュレーションの前に、計算された所定の時間
だけ他の作用ステップの時刻から遅らせるステップを含
むことを特徴とする請求項22記載の方法。 - 【請求項24】 前記保証ステップが、第1の作用ス
テップのシミュレーションを、第2の作用ステップのシ
ミュレーションが終わるまで遅らせるステップを含むこ
とを特徴とする請求項22記載の方法。 - 【請求項25】 テープ・プログラムが複数のテープ
・シナリオからなる場合、呼び出されたテープ・プログ
ラムを呼び出しているテープ・プログラムの実行の一部
として実行し、前記の呼び出されたテープ・プログラム
の実行に続いて、前記の呼び出しているテープ・プログ
ラムに戻るステップをさらに備えたことを特徴とする請
求項22記載の方法。 - 【請求項26】 第1のテープ・プログラムの第1の
作用ステップのシミュレーションの後に、前記第1のテ
ープ・プログラムの第2の作用ステップのシミュレーシ
ョンに先立ち、第2のテープ・プログラムの部分集合を
シミュレートするステップをさらに備えたことを特徴と
する請求項22記載の方法。 - 【請求項27】 引き続き他のテープ・プログラムに
おいて再利用するために第2のテープ・プログラムの部
分集合を取り去るステップをさらに備えたことを特徴と
する請求項22記載の方法。 - 【請求項28】 コンピュータ・プログラムのための
仕様を対話的に生成するコンピュータ・システムにおい
て、入力装置を介して受信可能なアクタ・データの受信
に応じて、複数のテープ・シナリオにおいて使用するた
めのアクタを指定して、前記アクタに対するデータを格
納し、前記指定が、新たなアクタの生成、以前に生成さ
れたアクタの選択、およびアクタ・データの修正を含む
ステップと、前記入力装置を介して受信可能なアクタ・
データを受信し、これに応じて引き続き実行するために
、前記アクタ間の通信、前記アクタ間の関係、前記アク
タに対する論理的または算術的な演算、および前記複数
のシナリオに対する判断点を格納するステップとを備え
たことを特徴とするプログラム仕様の対話的な設計を支
援する方法。 - 【請求項29】 複数のシナリオの作用ステップのた
めの蓄積アクタ・データおよび蓄積仕様データを含むシ
ステムにおいて、前記入力装置を介して受信可能な第1
の判断選択を受信し、これに応じて、複数のテープ・シ
ナリオの第1のシナリオを実行する実行ステップを備え
、この実行ステップが、各作用ステップに対する所定の
条件が発生により、前記第1のシナリオの作用ステップ
をシミュレートするシミュレーション・ステップと、前
記シミュレーションの結果を格納する格納ステップとを
含み、さらに前記シミュレーションが、アクタ間の通信
の実行、アクタ間の関係の表明、アクタに対する論理的
または算術的な演算の実行、または判断選択の入力の各
ステップのうちの少なくとも1つは含むことを特徴とす
るプログラム仕様の対話的な検査を支援する方法。 - 【請求項30】 前記シミュレーションステップが、
2つ以上のアクタを合併する合併ステップをさらに備え
たことを特徴とする請求項1記載の方法。 - 【請求項31】 前記合併ステップが、第1のアクタ
の識別情報を第2のアクタの識別情報に変更することを
含むことを特徴とする請求項30記載の方法。 - 【請求項32】 前記合併ステップが、第1のアクタ
と第2のアクタとを結合して第3のアクタとする結合ス
テップを含み、この結合ステップが、前記第1のアクタ
および前記第2のアクタのアクタ通信データを前記第3
のアクタに割り当てるステップと、前記第1のアクタの
アクタ属性データおよびアクタ関係データを前記第3の
アクタに割り当てるステップ、前記第2のアクタのアク
タ属性データおよびアクタ関係データを前記第3のアク
タに割り当てるステップ、前記第1のアクタおよび前記
第2のアクタからアクタ属性データおよびアクタ関係デ
ータを選択的に組み合わせたものを前記第3のアクタに
割り当てるステップ、および前記第1のアクタおよび前
記第2のアクタのアクタ属性データおよびアクタ関係デ
ータを前記第3のアクタに割り当てるステップのうちの
少なくとも1つのステップとを備えたことを特徴とする
請求項30記載の方法。 - 【請求項33】 入力装置を介して受信可能なアクタ
・データの受信に応じて、複数のテープ・シナリオにお
いて使用するためのアクタの指定を、新たなアクタの生
成、以前に生成されたアクタの選択、およびアクタ・デ
ータの修正などによって行い、かつ前記アクタに対する
データを格納する手段と、前記入力装置を介して受信可
能な作用ステップを受信し、これに応じて引き続き実行
するために、前記アクタ間の通信、前記アクタ間の関係
、前記アクタに対する論理的または算術的な演算、およ
び前記複数のシナリオに対する判断点を格納する手段と
を備えたことを特徴とするプログラム仕様の対話的な設
計を支援するシステム。 - 【請求項34】 複数のシナリオの作用ステップのた
めに蓄積(格納)されたアクタ・データおよび仕様デー
タを収容しているコンピュータ・プログラム仕様検査シ
ステムにおいて、作用ステップのための前記の蓄積アク
タ・データおよび蓄積仕様データを検査する手段と、入
力装置を介して受信可能な第1の判断選択の受信に応じ
て、仕様(指定)の首尾一貫性を評価するために複数の
テープ・シナリオの第1のシナリオを実行し、この実行
が、各作用ステップに対する所定の条件の発生によって
前記第1のシナリオの作用ステップをシミュレートする
ことを含むような手段と、前記シミュレーションの結果
を格納する手段とを備え、前記シミュレーションが、ア
クタ間の通信の実行、アクタ間の関係の表明、アクタに
対する論理的または算術的な演算の実行、および判断選
択の入力の要求のステップのうちの少なくとも1つは含
むことを特徴とするコンピュータ・プログラム仕様検査
システム。 - 【請求項35】 前記作用ステップの前記シミュレー
ション中に前記入力装置を介して受信される指示の受信
に応じて、前記作用ステップの前記シミュレーションを
次々と逆処理し、かつ前記作用ステップの1ステップに
おいて前記逆処理を停止する逆処理手段をさらに備えた
ことを特徴とする請求項34記載のシステム。 - 【請求項36】 前記入力装置を介して受信した入力
データに応じて、前記作用ステップのうちの前記1ステ
ップを修正する手段をさらに備えたことを特徴とする請
求項35記載のシステム。 - 【請求項37】 前記入力装置を介して受信した別の
指示に応じて、前記作用ステップのうちの前記1ステッ
プにおいて前記シミュレーションを再開する手段をさら
に備えたことを特徴とする請求項36記載のシステム。 - 【請求項38】 前記の逆処理手段が、実行された個
々のステップのシミュレーション結果を次々と削除する
手段を含むことを特徴とする請求項35記載のシステム
。 - 【請求項39】 前記アクタがフレームからなり、前
記フレーム間の関係が双対リンクを用いて維持され、前
記方法が、前記フレームの1つの自己記述を格納するス
テップを備え、さらに前記自己記述が、前記フレームの
前記1つが定義されるコンピュータ環境から独立してい
ることを特徴とする請求項1記載の方法。 - 【請求項40】 フレームが、その母体から複数の属
性および複数の関係を継承することを特徴とする請求項
39記載の方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US510373 | 1990-04-17 | ||
US07/510,373 US5247651A (en) | 1990-04-17 | 1990-04-17 | Interactive computer program specification and simulation system |
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 |
GB2278250B (en) * | 1990-08-31 | 1995-03-15 | Canon Kk | Image processing |
EP0544637B1 (en) * | 1991-11-27 | 1999-01-20 | Telefonaktiebolaget Lm Ericsson | Software structure for telecommunication switching systems |
US5903454A (en) | 1991-12-23 | 1999-05-11 | Hoffberg; Linda Irene | Human-factored interface corporating adaptive pattern recognition based controller apparatus |
US8352400B2 (en) | 1991-12-23 | 2013-01-08 | Hoffberg Steven M | Adaptive pattern recognition based controller apparatus and method and human-factored interface therefore |
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 |
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 |
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 |
CA2151102C (en) | 1994-06-07 | 2004-07-20 | Thomas Gerard Marsh | Computer based training system |
DE69518123T2 (de) * | 1994-06-23 | 2001-03-29 | International Business Machines Corp., Armonk | 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 |
DE69622078T2 (de) * | 1995-04-18 | 2003-02-27 | Siemens Corp. Research, Inc. | Animationsverfahren für zusammengesetzte Verhalten von Szenarien |
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 |
US5764989A (en) * | 1996-02-29 | 1998-06-09 | Supercede, Inc. | Interactive software development system |
US5848274A (en) * | 1996-02-29 | 1998-12-08 | Supercede, Inc. | Incremental byte code compilation 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 |
US5774119A (en) * | 1996-08-14 | 1998-06-30 | International Business Machines Corporation | Graphical interface method, apparatus and application for selection of target object |
US5818444A (en) * | 1996-08-14 | 1998-10-06 | International Business Machines Corporation | Method, apparatus and application for object selective but global attribute modification |
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 |
US5774120A (en) * | 1996-08-14 | 1998-06-30 | International Business Machines Corporation | Refresh and select-all actions in graphical user interface |
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 |
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 |
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 |
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 |
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 |
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 |
US5917498A (en) * | 1996-11-12 | 1999-06-29 | International Business Machines Corporation | Multi-object views in an object modeling tool |
US6011559A (en) * | 1996-11-12 | 2000-01-04 | International Business Machines Corporation | Layout method for arc-dominated labelled graphs |
US5960199A (en) * | 1996-11-12 | 1999-09-28 | International Business Machines Corporation | Model trace view for object-oriented systems |
JP2001506028A (ja) * | 1996-12-13 | 2001-05-08 | メイヴス インターナショナル ソフトウェア,インコーポレイテッド | コンピュータソフトウェアアプリケーションの開発および実行のための方法、システムおよびデータ構造 |
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 |
WO2000019333A1 (en) * | 1998-09-30 | 2000-04-06 | 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 |
US7966078B2 (en) | 1999-02-01 | 2011-06-21 | Steven Hoffberg | Network media 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 |
US6761637B2 (en) | 2000-02-22 | 2004-07-13 | Creative Kingdoms, Llc | Method of game play using RFID tracking device |
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 |
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 |
AU2002252222A1 (en) * | 2001-03-08 | 2002-09-24 | Richard M. Adler | 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 |
EP2290532A3 (en) | 2001-07-26 | 2013-04-24 | 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 |
US7321804B2 (en) * | 2004-12-15 | 2008-01-22 | The Boeing Company | Method for process-driven bill of material |
US20060129970A1 (en) * | 2004-12-15 | 2006-06-15 | Haas Martin C | Systems and methods for production planning analysis using discrete event simulation |
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 |
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 |
US7797672B2 (en) * | 2006-05-30 | 2010-09-14 | Motorola, Inc. | Statechart generation using frames |
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 |
CN101578582A (zh) * | 2007-01-11 | 2009-11-11 | 皇家飞利浦电子股份有限公司 | 用于提供撤消/重做机制的方法和设备 |
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 |
US20110029864A1 (en) * | 2009-07-30 | 2011-02-03 | Aaron Michael Stewart | Touch-Optimized Approach for Controlling Computer Function Using Touch Sensitive Tiles |
US8656314B2 (en) * | 2009-07-30 | 2014-02-18 | Lenovo (Singapore) Pte. Ltd. | Finger touch gesture for joining and unjoining discrete touch objects |
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 |
---|---|
EP0453152A3 (en) | 1993-05-26 |
EP0453152A2 (en) | 1991-10-23 |
CA2035949A1 (en) | 1991-10-18 |
CA2035949C (en) | 1995-08-29 |
US5247651A (en) | 1993-09-21 |
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 | |
Davoli et al. | Parallel computing in networks of workstations with paralex | |
Coutaz et al. | Applications: A dimension space for user interface management systems | |
US20020147963A1 (en) | Method and apparatus for generating machine control instructions | |
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 | |
Zhong et al. | An investigation of reorganization algorithms | |
CN111459547B (zh) | 一种函数调用链路的展示方法和装置 | |
JPH04227539A (ja) | プログラム仕様の生成を支援する方法 | |
Takeda et al. | MERA: Meta language for software engineering | |
Frank et al. | Inference bear: designing interactive interfaces through before and after snapshots | |
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 | |
Wetherall | An interactive programming system for media computation | |
Nutt et al. | Software support for a virtual planning room | |
Caldeira | A Multi-Robot GSPN Software Framework to Execute and Visualize Plans | |
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 |