JP2001506020A

JP2001506020A - ネットワークにおけるプログラムモジュール及びパラメータファイル

Info

Publication number: JP2001506020A
Application number: JP50585398A
Authority: JP
Inventors: 大介田渕; 渉庄司; 一郎中島
Original assignee: エスエフデイ株式会社
Priority date: 1996-07-12
Filing date: 1997-07-14
Publication date: 2001-05-08
Also published as: WO1998002823A2; WO1998002823A3; EP0912931A2

Abstract

(57)【要約】アプリケーションは、関連するパラメータファイルで定められる動作を行う実行セルから構成される。ローカルパラメータファイルは実行セルに対応つけられており、各実行セルは対応するアイコンがユーザによってクリックされた時に起動される。このセルは、他のパラメータファイルをダウンロードし、対応する実行セルに対応付ける。そのランセルの動作は、ダウンロードされたパラメータファイルにより決定される。ダウンロードされたパラメータファイルは、別個のＵＲＬキャッシュに格納される。従って、アプリケーションは、分散されたパラメータファイルにより制御される。

Description

【発明の詳細な説明】発明の名称ネットワークにおけるプログラムモジュール及びパラメータファイル技術分野この発明は、コンピュータシステムとネットワークシステムに関する。背景技術マイクロコンピュータは、８ビットの単なるおもちゃからビジネスの強力な道具へと進化し、現在では、ほとんどの大規模、中規模の企業が、少なくとも１つのコンピュータをビジネスに使用している。ここ数年、大量生産により、マイクロコンピュータの価格は急激に下落し、今日では、多くの家庭や小規模な企業でも手が届くようになっている。コンピュータを有効に利用するために、多くの企業では、マイクロコンピュータをローカルエリアネットワークに接続している。今日では、広域通信ネットワークに接続し、各地のマイクロコンピュータ間で情報を共有している企業もある。このことから、これらの企業は、コンピュータ間で情報を共有することで、システム全体の生産性が向上することを知っている。しかし、各企業が所有するコンピュータは、大抵は、互いにリンクされていない。その上、各家庭や小規模な企業が所有するコンピュータは、独立のデスクトップ機であることが多い。そのため、これらのコンピュータ間で情報が共有されることはない。「インターネット」と呼ばれる広域ネットワークの登場によってこの状況は変化し、これらのすべての機器が電子的に接続され得るようになった。インターネットは、強力な広域通信ネットワークを形成するために、１９６０年代の研究から成長した。長い間、インターネットは、大学や国立の研究所の研究員が情報を共有するために利用していた。インターネットの存在がより広く知られるようになるにつれ、大企業の従業員など、学術・研究関連以外の人々が、インターネットを使って電子メールのやりとりをするようになった。１９８０年代後半には、ワールド・ワイド・ウェブ（ウェブ）と呼ばれる広域情報システムが開発された。ウェブは、情報を発信する広域のハイパーメディアであり、膨大なドキュメントにアクセスするための検索システムである。開発当初は、ウェブは、学術・研究関連の人々にのみ知られ、利用されていた。技術的知識の乏しい人々にとっては、ウェブにアクセスするための機器は、簡単に利用できるものではなかった。インターネットの発達により、「ブラウザ」と呼ばれるソフトウェアが登場した。ブラウザは、単純だが優れたグラフィックインタフェースである。ユーザは、ブラウザを用いることにより、ウェブのドキュメントを検索できるようになり、簡単なコマンドとポイント・アンド・クリックのようなよく知られた手段でウェブを利用できるようになった。ブラウザは、技術的な知識を必要とせず、使いやすいものであったため、インターネットが大衆へと広まっていった。ウェブ上でアクセスされ、読まれるドキュメントは、ハイパーテキスト・マークアップ・ランゲージ（ＨＴＭＬ）という言語で作成されている。ＨＴＭＬドキュメントは、ウェブブラウザで解釈されると、テキスト、イメージ、その他のマルチメディアコンテンツを表示することができる。しかし、ＨＴＭＬドキュメント自体は、基本テキストに特徴を付加する所定フォーマットのタグを有するＡＳＣＩＩコードのテキストドキュメントにすぎない。そのため、ＨＴＭＬドキュメントによって作成されるマルチメディアのプレゼンテーション（コンピュータディスプレイ等）の構成は、単純なものとなる。また、ＨＴＭＬを作成するのが困難であるという点も問題となる。上述の通り、ＨＴＭＬドキュメントはＡＳＣＩＩコードで作成されたドキュメントであるが、最終的な表示は、マルチメディアでのプレゼンテーションである。ＡＳＣＩＩドキュメントをマルチメディアプレゼンテーションと結びつけることは簡単ではない。ＨＴＭＬドキュメントの作成を助けるツールは存在するが、使用法が簡単ではないため、十分な知識を持った者しかＨＴＭＬドキュメントを作成することができない。そのため、多くのユーザは、他のウェブブラウザへ情報を提供することはできず、情報を受け取るのみである。最近では、基本的なウェブの構造を改良しようとする動きがある。ウェブが開発された当初の目的は、ドキュメントを共有することであった。インターネット上でプログラムも共有できることが以前から指摘されているが、このシステムにおいては、インターネットを介して、第１のコンピュータから第２のコンピュータへ、プログラムコードを送信することができる。第２のコンピュータは、受け取ったプログラムコードを実行し、ブラウザにより作成されたディスプレイを変化させることができる。この結果、ウェブは、ドキュメントを共有する受動的なシステムから、情報を処理する能動的なシステムへと変化することになる。ＪａｖａやＡｃｔｉｖｅＸがこの一例である。Ｊａｖａは、有名なプログラム言語である「Ｃ＋＋」のバリエーションであるが、ＡｃｔｉｖｅＸは、マイクロソフト社のＯｂｊｅｃｔＬｉｎｋｉｎｇａｎｄＥｍｂｅｄｄｉｎｇを基にしている。プログラムコードを共有するというのは優れたアイディアであるが、ＪａｖａやＡｃｔｉｖｅＸ等の方向性は、多くのユーザにインターネットの資源を公開しようという動きに反している。Ｊａｖａ及びＡｃｔｉｖｅＸは、経験を積んだプログラマがコンピュータプログラムを作成することを必要とする。これらのプログラムを書くことは、ＨＴＭＬ文書を書くよりも難しい。このため、ユーザは、インターネットにインタラクティブに参加しにくくなる。また、今日の市場では、多くのコンピュータが、サウンドカード、高解像度ビデオカード、カラーモニタ、と共に売られており、「マルチメディアコンピュータ」と呼ばれている。また、これらの付属品を使用するためのコンピュータアプリケーションは、マルチメディアアプリケーションと呼ばれている。マルチメディアアプリケーションは、グラフィックイメージやアイコンを基礎に置いている。ユーザのインタフェースは、通常、グラフィック・ユーザ・インタフェース（ＧＵＩ）と呼ばれる。これとは対照的に、従来のインタフェースは、１行コマンドを基礎に置いている。それに比べると、マルチメディアアプリケーションの開発はより困難となる。これは、ＧＵＩにおいては、多数のコンピュータリソースを調整しなければならないことが一因である。例えば、コマンドラインベースのインタフェースはキーボードのみをモニタすればよいのに対し、ＧＵＩにおいては、キーボードとマウスの両方をモニタしなければならない。また、コマンドラインベースのインタフェースでは、ユーザは、コマンドを行単位でしか入力できなかったが、ＧＵＩにおいては、コンピュータスクリーン上のアイコンをどこでもクリックすることができる。さらに、コマンドラインベースのインタフェースにおいては、テキストしか生成できないのに対し、ＧＵＩにおいては、グラフィックイメージ、動画及び／又はオーディオサウンドを出力できる。このれらのことから理解できるように、マルチメディアアプリケーションの作成は、簡単なことではない。マルチメディアアプリケーションの作成が困難であるとは言っても、グラフィック環境は、プログラミングの経験がほとんど、あるいは、全くない人にも、アプリケーションを作成する気を起こさせる。例えば、グラフィックデザイン、動画の作成、作曲、等の経験がある人であれば、マルチメディアコンピュータ環境で自分の技術や経験を生かすことに興味を持つだろう。今のところ、ユーザがアプリケーションを開発するためのオーサリングソフトウェアの数は少ない。マクロメディア社のＤｉｒｅｃｔｏｒ５．０がその例であるが、扱いにくく、表現の種類も限られている。そのため、簡単に使用できて、柔軟性に富んだマルチメディアソフトの開発が必要となっている。ディジタルコンピュータが実用化された当初、コンピュータのメモリの容量は非常に小さく、コンピュータプログラムのサイズも非常に小さかった。そのため、良いプログラムを書くためには、多くの機能を小さなメモリの中にできる限り詰め込まねばならず、各機能を実行するコードもまた、できる限り小さなものとしなければならなかった。メモリの容量が増大するにつれ、コンピュータプログラムのサイズを小さくすることに力を注ぐ必要はなくなった。その代わり、効率的で欠陥のない大きなアプリケーションを作成する方法を開発することに重点が移り、モジュラーソフトウェア作成の有効性が認識されるようになった。なぜなら、大きなプログラムを一つ作成するよりも、小さなプログラムをいくつか作成し、それらを適当な方法でまとめる方が、簡単だからである。この方法は、伝統的な手続指向のプログラム環境と、近時のオブジェクト指向のプログラム環境との双方において用いられている。モジュラープログラミングにおいては、複雑なシステムは、複数のサブシステムに分割される。各サブシステムは、プログラムモジュールと結びついている。サブシステムは、それ自身、下位のプログラムモジュールと結びついた下位のサブシステムに分割される。これらのプログラムモジュールは、他のプログラムモジュールと通信することができる独立のモジュールであることが理想的である。そのため、プログラマは、チームを組んでプログラミングを行い、各プログラマは、少数のプログラムモジュールに注意を払えばよい。つまり、モジュラープログラミングは、共同作業に適していると言える。さらに、各プログラムモジュールのデバッグや保守が比較的簡単である。これは、不完全な又は不満足なプログラムモジュールは分離と修正ができ、システムの残りの部分に与える影響は全くないか、最小限に抑えることができる。複数のプログラムモジュールを組み合わせて大きなアプリケーションを形成するためには、各モジュールは、相互に通信を行うことができなければならない。モジュラープログラミングをうまく用いるためには、プログラムモジュール間の通信をうまく行うことが重要である。この通信がうまくいかないと、モジュールは、有効な作業を行う代わりに、通信のために多くのコンピュータ資源を必要とし、プログラマは、プログラム間の通信を処理するコードを作成するために多大な時間を要することになる。スクロールは、グラフィックやテキストイメージを操作するための必要不可欠な手段である。グラフィックやテキストイメージを表示するウィンドウがそのイメージの全体のサイズよりも小さい場合に、スクロールの必要が生じる。つまり、ウィンドウはイメージの一部分を表示するに過ぎず、イメージの他の部分を表示するために、ユーザはイメージを「スクロール」する。一般に、ウインドウは、上下、左右等のユーザがスクロールする方向を指示する１本又は２本の「スクロールバー」を備える。ユーザは、スクロールする方向を示すため、スクロールバーエリア内のカーソルの位置を定める。カーソルの位置は、ユーザが手に持ったマウス、又は他の指示装置によって定められる。カーソルの位置は、オペレーティングシステムや、グラフィック、又は、テキストイメージを制御するワードプロセッサプログラム等のアプリケーションソフトウェアに通知される。多くの表示装置上のイメージは、定期的に、例えば、１秒に６０回、リフレッシュされ（書き換えられ）なければならない。スクロール中、書き換えられたイメージは、グラフィックやテキストイメージの移動を連続的に示す。オペレーティングシステムやアプリケーションソフトウェアは、カーソル位置によって、連続的なイメージをどのように描くかを決定する。スクロールにおける重要な要素は、最小送り量、つまり、各スクロール処理で移動する最小画素数である。それは、従来の技術においては、行単位及び文字単位であった。そのため、最小送り量は粗く、各スクロールにおける移動画素数が多かった。その結果、テキストイメージのスクロールは断続的であり、見にくいものであった。発明の概要従って、この発明は、ユーザがインターネットにインタラクティブにアクセスできるようにすることを第１の目的とする。また、この発明は、使いやすく、柔軟性に富んだマルチメディアオーサリングソフトを提供することを第２の目的とする。この発明は、プログラムモジュール間の通信を効率よく行うことを第３の目的とする。さらに、この発明は、テキストイメージを滑らかにスクロールすることができるスクロールを提供することを第４の目的とする。第１の目的は、新しいプログラミング構造である「ディジタル・セル・テクノロジー」（ＤＣＴ）をディジタル・データ・ネットワークに適用することにより達成できる。ＤＣＴにおいては、アプリケーションは、伝統的な階層構造によらない、セルと呼ばれる特別なプログラムモジュールにより形成されている。この発明では、アプリケーションを形成し、特別な構造を持つセル中で用いられるマルチメディアファイルを、データネットワークに接続された他のコンピュータから入手することができる。その結果、アプリケーション中で用いられるマルチメディアファイルの数は、飛躍的に増加する。ディジタル・セル・テクノロジーにおける各セルは、一以上のパラメータファイル（ＤＮＡファイル）と結びついている。これらのファイルは、自身と結びついたセルの特徴を示すパラメータを有している。セルの一例において、ＤＮＡファイルはセル相互の通信を可能とする手段を提供する。この発明は、これらのＤＮＡファイルをデータネットワークに接続されている様々なコンピュータに分散して配置させることに関する。この発明の第２の目的は、既存のプログラムモジュールを用いて、経験の少ないユーザが、複雑なマルチメディアプリケーションを開発することができる方法を提供することにより達成される。これらのプログラムモジュールは、ユーザやソフト開発者によって作成される。各プログラムモジュールはディスプレイウィンドウを備えている。また、希望の機能を実行するために、他のプログラムモジュールと通信を行うこともできる。ユーザは、アプリケーションを形成するために適当なプログラムモジュールを選択することができる。また、ユーザは、プログラムモジュールと結びついた各ウィンドウを自由な配置で構成することができる。これらのウィンドウの表示上の関係は、ディスプレイウィンドウ間の様々な親子関係を決めることによって定まる。この関係により、ウィンドウは、あらかじめ定められた通りに表示される。プログラムモジュールは、起動されると、指定された機能を実行するために相互に通信を行うが、各ウィンドウは、あらかじめ定められた表示上の関係を保っている。そのため、アプリケーションが、プログラミング経験のほとんどないユーザが選択し、配列したモジュールではなく、しっかりと結びつけられたプログラムモジュールを備えている印象を与える。この発明の第３の目的は、オブジェクト指向のプログラミングにおける、プログラミングの各クラス間の新しい通信方法を提供することにより達成される。この方法においては、通信を管理するために、専用の通信制御クラスが設けられる。各クラス間の通信は、直接行うことはできず、すべて、この通信制御クラスを介して行われる。そのため、各クラスは、他のクラスとの通信を行うために、クラス間の階層的な関係の履歴を維持する必要がない。上述のクラス（制御クラスを含む）は、グループ化されてプログラムモジュール（プログラムセル、とも言う）を形成する。プログラムモジュールは、さらにグループ化されてアプリケーションを形成している。上述の方法によれば、各モジュール間の通信が可能となる。特に、モジュール間の通信を制御及び管理するために、専用の通信制御モジュールが用いられる。モジュールは、通信を直接行うように設計されておらず、すべての通信は、通信制御モジュールを介して行われる。この方法は、さらに、（１）異なるアプリケーション間の通信、（２）データネットワーク内の異なったコンピュータのプログラムモジュール間の通信、を管理するために拡張しうる。この発明の第４の目的は、テキストイメージを行単位又は文字単位ではなく、画素単位でスクロールすることを可能とすることにより実現される。画素は、表示の最小単位である。よって、この方法によれば、最も質の高いテキストイメージのスクロールを可能とする。この発明は、ユーザに使用されているアプリケーションによって生成されるウィンドウ（以下、アプリケーションウィンドウ、という）と結びついた子ウィンドウの生成を含む。テキストイメージは、アプリケーションウィンドウの代わりに、子ウィンドウに書き込まれる（表示される）。子ウィンドウはアプリケーションウィンドウよりも大きい。しかし、コンピュータのスクリーンには、子ウィンドウは、アプリケーションウィンドウと重なり合う一部分しか表示されない。ユーザがスクロールを指示すれば、スクロールの方向に、子ウィンドウが画素単位で動く。その結果、ユーザは、画素単位でテキストイメージがスクロールするのを見ることができる。１行分又は１文字分、完全にスクロールされると、子ウィンドウは自分自身を消去し、元の位置に戻る。それと同時に、テキストイメージは、画素を基準としたスクロールに適合するように、子ウィンドウ上で１行又は１文字分スクロールされる。子ウィンドウは、再び、画素単位で動く。よって、ユーザは、最小単位で滑らかにスクロールするテキストイメージを見ることができる。この発明の上述及びその他の特徴及び効果は、添付図面と以下の詳細な説明から理解できる。図面の簡単な説明図１は、この発明を実現するために使用されるＤＣＴ（ディジタルセルテクノロジ）又はボスレス構造の概略図である。図２は、ディジタルセルテクノロジを用いたアプリケーションの構造を説明するための図である。図３は、セルＣＡに備えられたＤＮＡファイルの論理構成を示すブロック図である。図４は、セルＣＡの論理構成を示すブロック図である。図５は、ＤＣＴに基づくアプリケーションを実行するコンピュータシステムのブロック図である。図６は、この発明で用いられるコンピュータネットワークを示す図である。図７は、この発明のプログラムセルと結びついた複数のウィンドウを示す図である。図８は、この発明のＤＮＡファイルの構造を示す図である。図９は、この発明におけるキャッシュの構造を示すブロック図である。図１０は、この発明における分散可能なＤＮＡファイルを示す概略図である。図１１は、この発明の方法を用いたアプリケーションを作成する動作を説明するための図である。図１２は、この発明の他の方法を用いたアプリケーションを作成する動作を説明するための図である。図１３は、図１１に示したアプリケーションを実現するために使用される処理のフローチャートである。図１４は、図１２に示したアプリケーションを実現するために使用される処理のフローチャートである。図１５は、この発明に従って、独立した２つのウィンドウが親子関係を形成する過程を説明するためのフローチャートである。図１６Ａは、この発明において用いられるウィンドウの構成を示す図である。図１６Ｂは、この発明において用いられる親ウィンドウと、子ウィンドウとの関係を示す図である。図１７は、従来のクラスを用いたプログラミングの構成を示す図である。図１８は、この発明におけるプログラミングの構成を示す図である。図１９は、この発明における通信制御クラスの構成を示す図である。図２０は、図１８に示す構成の応用例を示した図である。図２１は、この発明によるプログラミングの構成を用いたマルチコンピュータアプリケーションを示す図である。図２２Ａ及び図２２Ｂは、従来の技術におけるスクロールの例を示す。図２３は、この発明におけるアプリケーションウィンドウと子ウィンドウとの関係を示す。図２４は、この発明のスクロール処理を示すフローチャートである。発明の好適実施例まず、ディジタルセルテクノロジ（ＤＳＴ）について説明する。この技術は、国際出願ＰＣＴ／ＪＰ９６／００８２１、「コンピュータプログラム用のボスレスアーキテクチャ及びディジタルセルテクノロジ」の公報に開示されている。この国際出願の内容は、参考のため、この明細書に取り込むものとする。この技術を、この発明の理解に必要な部分について概略的に説明する。ディジタルセルテクノロジの１つの特徴は、ボスレス構造にあり、各プログラムモジュール（又はセル）は、他のプログラムモジュールと同一の位置にある。プログラムの総合的な動作を制御するモジュールは存在しない。図１は、この発明のボスレスアーキテクチャに基づくアプリケーション１６０の概略図である。アプリケーション１６０はモジュール１６２〜１６５のような多数のプログラムモジュールを含む。各プログラムモジュール（以下、セル）は、他のセルと階層的に同一レベルである。セルは、履歴もリンケージ情報も記憶される必要のない方法で互いにリンクされる。各リンクは独立している。例えば、各リンクは同時に起動される必要はない。各リンクは直接的である。即ち、２つのセルは、１つ又は複数の中間のリンクを用いることなく、直接リンクされ得る。例えば、セル１６２、１６４は、線１６７、１６８を用いて中間のセルを通過する代わりに、線１６６を用いて直接リンクされうる。アプリケーションは、セルを選択し、直接リンクを用いることで形成される。図２は、この発明のボスレスアーキテクチャを用いたアプリケーション２００の構造を示す。アプリケーション２００は、ＲＡＭにロードされ、動作する複数のセルＣ１〜Ｃ５を含む。各セルはＤＮＡファイルと呼ばれる関連付けされたファイルＤ１〜Ｄ５を備えており、それらＤＮＡファイルはセルの情報を所持している。ＤＮＡという用語は、セルとファイルとの関係が、細胞とそのＤＮＡ（遺伝子）との間の生物学上の関係に類似するために、使用されている。所望の時間に、セルＣ１は、デジタルシフト（ｄｉｇｉｔａｌｓｈｉｆｔｉｎｇｆｕｎｃｔｉｏｎ（以下、ＤＳＦ））プロトコルを用いて、セルＣ２へステートメント（ＤＳＦステートメント）を送信することができる。セルＣ２は、これらのステートメントを実行する。セル、ＤＮＡファイル及びＤＳＦプロトコルの詳しい構造について、以下に説明する。アプリケーション２００において、セルＣ２はステートメントの発生元に関する情報を保持しない。即ち、プロセス間の通信履歴を記録する必要はない。従って、セルＣ１がセルＣ２へのＤＳＦステートメントの書き込みを一旦完了させると、セルＣ１とセルＣ２との間のリンクは存在しなくなる。セルＣ２は、ステートメント実行中、そのステートメントの発生元を知らない。セルＣ１がセルＣ２に新たなステートメントの組を送信することにより、セルＣ１は後に再びセルＣ２と交信可能となる。しかし、この交信は、前の交信とは関係なく、新たなＤＳＦステートメントが送信されると終了する。各セルは、どのセルに対してもＤＳＦステートメントを送信することができる。従って、セルＣ１はセルＣ３へステートメントを送信することもできる。同様に、セルＣ２はセルＣ４へステートメントを送信することができ、セルＣ４はセルＣ１へステートメントを送信することができる。また、セルＣ３もセルＣ１へステートメントを送信することができる。この実施例において、セルＣ１とセルＣ２はセルＣ４の管理者ではない。例えば、セルＣ４がＤＳＦステートメントを実行している間、セルＣ１とセルＣ２との間やセルＣ２とセルＣ４との間に如何なるリンクも保持する必要はない。アプリケーション２００においては、セルＣ４は、どのセルに対しても実行結果を報告する義務はない。ＤＳＦステートメントが送信される時間内でだけ、リンクは保持される。更に、セルＣ１によるセルＣ２へのステートメントの書き込みは、セルＣ２によるセルＣ４へのステートメントの書き込みとは無関係である。加えてセルＣ４はただ単にステートメントを実行するだけであり、そのステートメントがどこから来たかについては関与しない。この実施の形態のアーキテクチャにおいては、セルＣ２がセルＣ１により書き込まれたステートメントを実行するとき、スタックにレジスタ値を記憶する必要も、それを復元する必要もない。また、コマンドを送信する前に、中央のデータベースにセルを記憶する必要もない。実行の状態を報告するために、メッセージを送・返信する必要もない。結果として、アプリケーションの実行速度は向上する。以下に説明するように、セルはＥＸＥファイルとして実現され（Ｍｉｃｒｏｓｏｆｔ社から発売されているＭＳＤＯＳ又はＷｉｎｄｏｗｓ環境において）、実行の際、操作環境に応じた方法でＲＡＭにロードされる。セルに関連付けられたＤＮＡファイルもＲＡＭにロードされる。起動されたセルは、そのＤＮＡファイルが所持する属性を帯びる。セルの起動時又は実行中でも、ＤＮＡファイル（例えば、ＡＳＣＩＩファイル）に書き込みを行うことにより、それを変更することができる。図３は、例えばセルＣＡに関連付けられたＤＮＡファイル２５０の論理構造を示す図である。ファイル２５０は、セルＣＡ自身の特性に関連するパラメータ（自己パラメータ）を含むセクション２５２を備える。例えば、セクション２５２は、セルＣＡが起動されたとき、セルＣＡ自身の表示方法に関するパラメータ、例えば、ウインドウのサイズ、セルＣＡの背景の色、セルＣＡの名前、起動及び終了時に使用するオーディオファイルの名前、等を含む。また、ファイル２５０は、セルＣＡに関連するセルについて、セルの名前、シンボル、表示位置等を含む関連付けパラメータ（リンクパラメータ）を含むセクション２５４を備える。リンクパラメータが「クローズ（close）」であるセルが起動されたとき、そのリンクパラメータはセルＣＡを閉じる（クローズする）ものとして解釈される。また、ファイル２５０は、ＤＳＦ情報セクション２５６を含む。このＤＳＦ情報セクション２５６は、通常セクション２５７と最優先機能セクション２６４とを含む。通常セクション２５７と最優先機能セクション２６４の構成は、最優先機能セクション２６４がステートメント実行の際、より高い優先権を持つということ以外は、ほぼ同一である。これら２つのセクションは、セクションを識別するために、個々のヘッダを備えている（例えば、各セクションは異なる名前又はシンボルの見出しがある）。通常セクション２５７は、状態セクション２５８とステートメントセクション２６０とを備える。ステートメントセクション２６０は、他のセルからセルＣＡへ送信されてきたＤＳＦステートメントを有する。ステートメントセクション２６０におけるステートメントは、順次実行される。各ステートメントも、そのステートメントを実行するときの必要性に応じて、パラメータを備える。状態セクション２５８は、次の３つの要素を備える。（ａ）現時点においてステートメントセクション２６０における最後のＤＳＦステートメントを指示する第１のポインタ、（ii）セルＣＡにより処理されているＤＳＦステートメントを指示する第２ポインタ、（iii）現時点におけるセルの状態。最優先機能セクション２６４は状態セクション２６６とコマンドラインセクション２６８とを備える。状態セクション２６６の構成は、状態セクション２５８の構成と類似している。コマンドラインセクション２６８には、ＤＳＦプロトコル（又は、ＤＳＦプロトコルに類似したプロトコル）を用いて他のセルから送信された、実行可能なコマンドラインが記述される。このコマンドラインは、ステートメントセクション２６０におけるステートメントよりも高い実行優先権を有する。コマンドラインセクション２６８におけるコマンドラインは、順次実行される。図３に示す論理構造は１つ又は複数の物理的なファイルを用いて実現される。更に、論理的なセクションは物理的に混在していてもよい。例えば、ＤＮＡファイルはテキストファイルである。従って、ＤＮＡファイルの内容は、通常のテキストエディタを用いることにより、変更可能である。あるセルから他のセルへ送信されるステートメントは、ＤＳＦプロトコルに従う。送信元のセル（例えば、セルＣＳ）はセルＣＡに関連付けされたＤＮＡファイル２５０と通信リンクをセットアップする。送信元のセルは、ＤＮＡファイル２５０のアドレスを調べ、そのＤＮＡファイル２５０の状態セクション２５８で状態をチェックすることにより、そのＤＮＡファイル２５０がＤＳＦステートメントを受信可能か否かを判定する。ステートメントは、セルＣＡが受信可能なときにのみ、セルＣＳにより送信される。なお、ステートメントの発行は、例えば、ＡＳＣＩＩキャラクタをＤＮＡファイル２５０のステートメントセクション２６０へ書き込むことにより行われる。セルＣＡへステートメントを送信することが認められると、セルＣＳはＤＳＦステートメントを書き込むための適切なアドレスを決定するため、最後のＤＳＦステートメントを指示する第１ポインタを読み出す。セルＣＡの既存のステートメントに上書きしないことが重要である。セルＣＳは、ＤＮＡファイル２５０のステートメントセクション２６０へＤＳＦステートメントを書き込む。そして、セルＣＳは、ステートメントセクション２６０に新たに書き込まれた最後のＤＳＦステートメントを指示するように、状態セクション２５８の第１ポインタを更新する。その後、セルＣＡとＣＳとの間の通信リンクは終了する。セルＣＡ及びＤＮＡファイル２５０は、新たなステートメントがセルＣＳから送信されたことを示す記録（即ち、履歴）を保持しない。上述したＤＳＦプロトコルは一例であり、セルへＤＳＦステートメントを書き込むことが可能な他のプロトコルでもよい。また、第１ポインタが最後のＤＳＦステートメントの次の位置を指示するような、異なるポインタ構造を用いてもよい。状態のタイプや、状態のチェック方法についても、これに限定されない。更に、ステートメントを順番に物理的に記憶する代わりに、論理構造に従って記憶してもよい。例えば、ステートメントを、ポインタにより指示されたアドレスを有するグループに分けることも可能である。コマンドラインは、あるセルから他のセルへＤＳＦプロトコルと同様のプロトコルを用いて送信される。通常セクション２５７と最優先機能セクション２６４とはヘッダが異なるため、送信元のセルは、これら２つのセクションを識別し、適当なセクションに書き込むことができる。なお、他の方法により、これら２つのセクションを識別してもよい。セルＣＡの構造を図４に示す。セルＣＡは、コンピュータにより実行可能な命令を用いて実現される複数の部分に論理的に分類される。セルＣＡは、初期設定部３１２及びＤＮＡインタフェース部３１４を備える。ＤＮＡインタフェース部３１４は、セルＣＡによる、そのセルに関連付けられたＤＮＡファイル２５０への読み込み及び書き込み等の内部的な処理を可能とする。また、セルＣＡは、（ＤＳＦプロトコルを処理するための）ＤＳＦインタフェース部３１６を備える。このＤＳＦインタフェース部３１６は、ＤＳＦプロトコルを用いてステートメント／コマンドラインを送受信するためのコード（プログラムインストラクション）を備える。セルＣＡは、他のセルによりＤＮＡファイル２５０に書き込まれたステートメントとコマンドラインを自動的に実行するためのコードを含む実行セクション３１８を備える。このコードは、ＤＮＡファイル２５０のステートメントセクション２６０のステートメントを順番に読んで実行する。各ステートメントを実行した後、セルＣＡは、最優先機能セクション２５９に分岐し、その全てのコマンドラインを実行した後、ステートメントセクション２６０の次のステートメントを実行する。セルＣＡは、一時的な情報を格納させるためのテンポラリメモリ部３２２を備える。一実施例において、セルＣＡは実行中でも属性（ウインドウディスプレイの背景色及び表示サイズ等）を変えることができる。変化した属性は、直ちにＤＮＡファイル２５０に書き込まれるのではなく、テンポラリメモリ部３２２に一時的に格納されるようにしてもよい。この場合、テンポラリメモリ部３２２に格納された情報は、セルＣＡ終了時に、ＤＮＡファイル２５０の自己パラメータセクション２５２に書き込まれる。セルＣＡは、他のセルを起動させるセル起動部３２４を備える。一例では、セル起動部３２４は、起動対象のセルに関する情報を取得し、実際に対象セルを起動する特定セルにその情報を渡す。この特定セルの機能を、セルＣＡ及び他のセルのセル起動部３２４に加えてもよい。上述したセルＣＡ内の各部分は、論理的には分類されているが、物理的には混在している。図５は、上述のアプリケーション開発システムを実行するコンピュータシステム３８０のブロックダイアグラムである。コンピュータシステム３８０は、ＩＢＭ互換コンピュータなどのパーソナルコンピュータから構成される。パーソナルコンピュータは、ＣＰＵ、ＲＡＭ、ＲＯＭハードディスク、マルチメディアデバイス（サウンドカード、ＣＤ−ＲＯＭリーダ、ＶＩＤＥＯカードなど）を備える。パーソナルコンピュータはＭＤ−ＤＯＳ３８４とＭＳ−Ｗｉｎｄｏｗｓ３８６を搭載する。この発明のセル３９１−３９３はＭＳ−Ｗｉｎｄｏｕｗｓ３８６上で動作する。これらのセルのいくつかは、表示装置上に表示され、パーソナルコンピュータ３８２のサウンドカード上で実行される。第１の実施例この発明は、図６のコンピュータネットワークシステム４００において用いられる。システム４００は、ローカルエリアネットワーク、広域ネットワーク、インターネット等のデータ通信ネットワーク４０２と、サーバ４０４〜４０６等の複数のサーバと、コンピュータ４１０〜４１２等の複数のクライアントコンピュータと、を備える。各サーバは、マルチメディアコンテンツ（イメージ、オーディオファイル、ビデオファイル、テキストドキュメント、等）の大規模なデータベースを備えていることが望ましい。サーバは、このようなデータベースを備える他のコンピュータを示すポインタを備えていてもよい。一部のクライアントコンピュータは、ディジタル・セル・テクノロジー（ＤＣＴ）制御を用いて設計された動作環境を実現する。この発明の第１の観点は、上述のＤＣＴをデータネットワーク環境に適用するものである。（リモートサーバからダウンロードされたマルチメディアファイル）上述のように、ＤＣＴにおいては、アプリケーションは、「セル」と呼ばれる複数の小規模なプログラムモジュールを管理することにより形成されている。各セルは、パラメータファイル（ＤＣＴの用語で「ＤＮＡ」ファイルと呼ばれる）と関連付けられており、ＤＮＡファイルは、自身と結びついたセルの特徴を定義するパラメータを有している。ＤＮＡファイルはまた、セルが他のセルとインストラクション（命令）を通信する手段を提供する。例えば、第１のプログラムモジュール（セル）は、第１のコマンドセットを第２のセルと結びついたパラメータファイルに送信するプログラムコードを備える。同様に、第２のプログラムモジュール（セル）は、第２のコマンドセットを第１のセルと結びついたパラメータファイルに送信するプログラムコードを備える。第１のセルはまた、実行結果を第２のセルに送信することなく第２のコマンドの組を実行するコードを備える。同様に、第２のセルもまた、実行結果を第１のセルに送信することなく第１のコマンドの組を実行するコードを備える。ＤＣＴの実行時に、ディスプレイウィンドウを生成するセルもある。図７は、コンピュータモニタのディスプレイ４５０を示す図である。ディスプレイ４５０は、セルと結びついた４つのディスプレイウィンドウ４５２、４６４、４６８、４７４を備えている。これらのウィンドウの詳細については後述する。図８は、セルＣＡに関連付けられたＤＮＡファイル４２０の構成の一例を示す図である。セルＣＡは、コンピュータ４１０等のクライアントコンピュータに格納されている。ここで重要なのは、自己パラメータセクション４２２のステートメント４３６（つまり、「ＩＭＡＧＥ＝ｈｔｔｐ：／／ｗｗｗ．ｓｉｔｅ／ｆｉｌｅ．ＪＰＧ」）である。ＰＣＴ／ＪＰ９６／００８２１に開示されたセルでは、表示されるイメージファイルはハードディスク又はクライアントコンピュータに位置する。この発明においては、イメージファイルは、ネットワーク４０２に接続された他のコンピュータに格納されている。より詳細には、ウェブに接続されているコンピュータによってアクセスされ得る各ファイルは、ユニフォーム・リソース・ロケータ（ＵＲＬ）と呼ばれる一定のフォーマットのアドレスを有しており、これによって、世界中のコンピュータからのアクセスが可能となる。ステートメント４３６は、そのファイルイメージが、「ｗｗｗ．ｓｉｔｅ／ｆｉｌｅ．ＪＰＧ」というＵＲＬを有していることを示している。セルＣＡは、イメージファイルを入手するために、クライアントコンピュータ４１０に、イメージファイルを有しているサーバ（サーバ４０４等）に対して「ｆｉｌｅ．ＪＰＧ」という名のファイルを送るよう、ネットワーク４０２を介して、要求させる。マイクロソフト社（ＭＳ）のウィンドウズ環境においては、セルＣＡは、サーバ４０４とのＴＣＰ／ＩＰ通信を始めるために、「ＷｉｎＳｏｃｋ」モジュールをコールする。サーバ４０４は、それに応答して、自身のデータベースの中にあるファイル「ｆｉｌｅ．ＪＰＧ」をクライアントコンピュータ４１０へ送り、コンピュータ４１０は、通常のＭＳウィンドウズ通知プロトコルを用いて、該ファイルをセルＣＡへと転送する。サーバ４０４は、ＭＳウィンドウズ環境下にある場合には、コンピュータ４１０との情報の送受信に「ＷｉｎＳｏｃｋ」モジュールを用いる。よって、セルＣＡは、自身と結びついたＤＮＡファイル中のパラメータに従って、ディスプレイウィンドウを生成することができる。ダウンロードされるファイルは、イメージファイルに限られない。オーディオファイル、ビデオファイル等の他のタイプのファイルを、ＤＮＡファイルの自己パラメータセクションにおけるリモートファイルとして指定してもよい。また、通信プロトコルが、ハイパーテキスト・トランスポート・プロトコル（ＨＴＴＰ）を備えている必要はなく、ネットワーク４２０上でファイルを転送できるプロトコルであれば、任意のものを用いることができる。さらに、サーバ４０４は、ＵＮＩＸ、Ｍａｃｉｎｔｏｓｈ、ＤＣＴを含む様々なオペレーティング環境の下で動作することができる。セルＣＡは、サーバからイメージファイルを入手すると、ＰＣＴ／ＪＰ９６／００８２１に開示されている通常のセルとして機能する。例えば、ユーザは、セルを他のセルとリンクさせて操作することができる。これらリンクされたセルは、インターネット上の様々なサーバからイメージファイルを入手することができる。これらのセルは、起動されると、上述の方法によって、イメージファイル（又は、他のファイル）を入手する。この例を図７に示す。ここでは、ウィンドウ４５２は、図８に示すセルＣＡによって生成されたディスプレイであるとする。ウィンドウ４５２は、タイトル（サイト１）を備えるタイトルバー４５４２を備える。ここでは、図７中のウィンドウのタイトルはすべて、その表示イメージの起源（サーバの形式で示すサイト１、サイト２、等）を示すものとする。勿論、実際のタイトルは、単語やシンボルを含んでもよい。ウィンドウ４５２、４６４、４６８、４７４は、それぞれサイト１、２、３、２からダウンロードされたイメージを有している。ウィンドウ４５２は、ウィンドウ４５２及びその元になるセルを操作するために、複数のツール（ツール４５８等）を備えたツールバー４５６を備えている。ツールとは、例えば、ウィンドウを編集するための編集モードへアクセスする編集ツール、あらかじめ決められた他のセルを起動するためのツールである。ここでは、ディスプレイ４５０中のすべてのウィンドウがタイトルバーとツールバーとを備えている。この例では、ウィンドウ４５２は、図形４６１を含んでいる。ユーザは、ボタンセル（ボタン４６０で表されている）とビジュアルセル（シンボル４６２で表されている）をウィンドウ４５２にリンクさせることができる。これらのＤＮＡファイル中のＩＭＡＧＥパラメータは、ローカルファイル又はリモートイメージファイルを特定することができる。ウィンドウ４５２にリンクさせるセルの数は任意であり、全くリンクさせなくてもよい。ユーザがボタン４６０をクリックすると、対応するボタンセルが起動され、ウィンドウ４６４が生成される。ここでは、図形４６６を含んだイメージは、サイト２に保存されているファイル（ここでは「ファイル１」と呼ぶ）に基づいて生成される。ユーザがシンボル４６２をクリックすると、対応するビジュアルセルが起動され、ウィンドウ４６８が生成される。ここでは、図形４７０を含んだイメージは、サイト３のファイルに基づいて生成される。ユーザは、他のビジュアルセル（以下、シンボル４７２）をウィンドウ４６８に付加することもできる。ユーザがシンボル４７２をクリックすると、対応するビジュアルセルが起動され、ウィンドウ４７４が生成される。この例において、図形４７６を含んだイメージは、サイト２の他のファイル（ここでは「ファイル２」と呼ぶ）に基づいて生成される。図７に示すセルは、自己が格納するイメージファイルを有していてもよく、すべてのイメージファイルがネットワーク４０２を介してダウンロードされる必要はない。ウィンドウ４５２、４５６、４６８、４７４は、それぞれＤＮＡファイルと結びついている。各ＤＮＡファイルのリンクパラメータセクションは、対応するセルにリンクされたＤＮＡファイルのファイル名（ローカル及びリモート）を含んでいる。例えば、ウィンドウ４５２と結びついたＤＮＡファイルのリンクパラメータセクションは、ウィンドウ４６４と結びついたボタンセル、及び、ウィンドウ４６８と結びついたビジュアルセルのファイル名を含んでいる。ここでは、これらのファイルは離れた場所に位置するため、ファイル名は、ＵＲＬフォーマットで形成されている。この実施例は、ＵＲＬキャッシュを備える。このキャッシュは、クライアントコンピュータにより処理されたすべてのＵＲＬをハードディスクに格納する。図９は、ＵＲＬキャッシュの実例を含むブロック図である。例えば、セル５０２がリモートセルにアクセスしようとする場合には、「インターネット・リソース・ローダ」５０４と呼ばれるプログラムモジュールにコマンドを発行する。ローダ５０４は、予めネットワークを介してダウンロードされ、ローカルハードディスクに格納されているＵＲＬのリストを有しているキャッシュリスト５０６を参照する。そして、リスト中のＵＲＬと、ローカルハードディスク中のファイルアドレスとが対応付けられる。希望のファイルのＵＲＬがキャッシュリスト５０６の中にある場合には、ローダ５０４は、該ファイルをネットワークを介してダウンロードする代わりに、ローカルハードディスクから取り込む。希望のファイルのＵＲＬがキャッシュリスト５０６の中に存在しない場合には、ローダ５０４は、「ＷｉｎＳｏｃｋ」５０８をコールし、そのファイルをダウンロードする。ネットワークからリモートファイルを受信すると、「ＷｉｎＳｏｃｋ」５０８は、このファイルをローダ５０４に渡す。ローダ５０４は、オペレーティングシステムに、ファイルを適当なローカルファイルに格納させる。ローカルファイルのアドレスはＵＲＬと共にキャッシュリスト５０６に加えられ、以後、クライアントコンピュータは、ネットワークを介さずに該ファイルにアクセスすることができるようになる。上述の機能に精通している人は、簡単にローダ５０４を実現することができる。サーバのなかには、ファイルの中身をしばしば更新するものがある。例えば、サーバが、製品の価格と仕様とに関するファイルを有している場合には、ファイルは、これらの情報が変化する度に、アップデートされなければならない。上述の実施の形態においては、ローダ８０４がファイルをサーバからではなくキャッシュ５０６から取り込んでくるため、ユーザは、アップデートされたファイルにアクセスすることができない。この問題を解決する方法は、少なくとも３つある。第１は、ユーザがキャッシュ５０６のエントリーをクリアできるようにすることである。そうすることにより、ファイルをネットワークを介して取り込まなければならない。第２は、ユーザが選択したアプリケーションに関するエントリーをクリアできるようにすることである。そうすれば、このアプリケーションに関するファイルをネットワークを介して離れたところから持ってくることができる。第３は、ユーザがスクリーン上のすべてのファイルを再ロードすることができるようにすることである。これらは、様々な方法で実行することができる。例えば、キャッシュリストがＡＳＣＩＩフォームで形成されている場合には、ユーザは、希望通りに、エントリーを（すべて又は選択的に）消去し、選択し、元に戻すことができる。（分散可能なＤＮＡファイル）上述の実施の形態において、ＤＮＡファイルは、ＤＮＡファイル中で引用されたマルチメディアファイルが離れたところにある場合でも、クライアントコンピュータに格納されている。この発明の他の実施の形態においては、ＤＮＡファイルは、サーバに格納されてもよい。クライアントコンピュータは、適当なＤＮＡファイルをサーバからダウンロードして、アプリケーションを作成し、実行する。以下、ＭＳウィンドウズ環境下におけるこの発明の実施の形態を説明する。ＭＳウィンドウズ環境下においては、あらかじめ決められた拡張子を有するファイルをアプリケーションと結びつけることができる。例えば、拡張子「ＳＦＭ」、「ＳＦＲ」を有するファイルは、それぞれ、ＤＣＴで作動するビジュアルセル、ランセルを起動するために作られる。ここでは、すべてのＤＮＡファイルは、ＡＳＣＩＩファイルであり、これらのＤＮＡファイルは、自身の自己パラメータ及びリンクパラメータによりアプリケーションを定義する。クライアントコンピュータは、これらのＤＮＡファイルをダウンロードし、自己に関連するセルを起動することにより、プログラムコードを転送するのではなく、ＡＳＣＩＩファイルを転送することにより、サーバに格納されたアプリケーションを実行することができる。図１０は、この発明における分散可能なＤＮＡファイルを説明するための図である。クライアントコンピュータのブラウザ（図示せず）は、ダウンロードすることができるＤＮＡファイルを示すアイコン５３２、５３４を備えたウェブホームページ５３０を表示することができる。ホームページ５３０に付随するＨＴＭＬドキュメント（図示せず）は、ブラウザがアイコン５３２、５３４を生成するために必要な「タグ」を有している。この発明においては、これらのタグは、ＤＮＡファイルのＵＲＬを有している。ブラウザは、アイコンがクリックされると、付随するＤＮＡファイル（以下、ホームページＤＮＡファイル）がキャッシュ５３５の中にあるかどうかを判別するために、自己のキャッシュ５３５にアクセスする。ホームページＤＮＡファイルがキャッシュ５３５の中にあると判別されると、ブラウザは、ファイルをダウンロードすることなく、ＤＮＡファイルと結びついたセル（例えば、ビジュアルセル）を起動することができる。ホームページＤＮＡファイルがキャッシュ５３５の中にないと判別されると、ブラウザは、サーバ（例えば、サーバ５４０）からファイルをダウンロードするためにＤＮＡファイルを呼び出す。そして、ダウンロードされたＤＮＡファイルの拡張子に基づいて、対応するセルがオペレーティングシステムにより起動される。例えば、アイコン５３２は、「ＤＮＡ−１．ＳＦＲ」と呼ばれるＤＮＡファイルにリンクされる。このファイルはブラウザキャッシュ５３５の中に存在しないため、サーバ５４０からダウンロードされる。ファイルがダウンロードされると、ブラウザは、ランセル５４４を起動する。ランセル５４４と結びついたウィンドウは、ＤＮＡ−１．ＳＦＲによって特徴づけられる。ここまで、ＵＲＬキャッシュ５３６は呼び出されていないが、これは、ＵＲＬキャッシュ５３６が、ブラウザではなく、セルがファイルをダウンロードしようとする際に起動されるものだからである。ここでは、ＤＮＡファイルと結びついたセルが離れたところに位置する第２のＤＮＡファイルを参照するときに、ＵＲＬキャッシュ５３６を用いる。このとき、図８との関係で上述した手順が続く。つまり、セルがインターネット・リソース・ローダにコマンドを発行し、必要ならば、「ＷｉｎＳｏｃｋ」を呼び出し、ファイルをダウンロードする。例えば、セル５４４がリモートＤＮＡファイル（例えば、ＤＮＡ−２．ＳＦＲ）にアクセスする必要がある場合には、ファイルを入手するために、ＵＲＬキャッシュ５３６が必要となる。ＤＮＡ−２．ＳＦＲがキャッシュされていない場合には、ファイルは、サーバ（同一のサーバ５４０又は他のサーバ５４２）からダウンロードされる。好適実施例において、すべてのホームページＤＮＡファイルは、ＳＦＲ拡張子を備えている。そのため、ユーザが、ダウンロード可能なＤＮＡファイルと結びついたアイコンをクリックすると、ランセルが起動される。ランセルの機能はただ一つ、ファイルが近くにない場合には他のＤＮＡファイルをダウンロードし、対応するセル（例えば、セル５４６）をそのＤＮＡファイルに結びつけることである。ここで新しくダウンロードされたＤＮＡファイル（例えば、ＤＮＡ−２．ＳＦＲ）は、プログラマが作成したアプリケーションを備えた真のＤＮＡファイルである。この実施の形態において、ホームページＤＮＡファイルを、仮のＤＮＡファイルと考えてもよい。真のＤＮＡファイルと仮のＤＮＡファイルを区別するのは、ＤＣＴのユーザが、すべてのＤＮＡファイルを再度見て、編集することができるようにするためである。以上説明したように、ホームページＤＮＡファイルは、ブラウザキャッシュ５３５に格納される。各ブラウザは、適当なキャッシュ構造を採用し、そこに格納されたファイル（例えば、ＤＮＡ−１．ＳＦＲ）は、通常、ユーザ及びＤＣＴには制御されない。ＤＣＴは、ＵＲＬキャッシュ５３６内のファイルのみを制御する。上述の構成では、全ての真のＤＮＡファイル（例えば、ＤＮＡ−２．ＳＦＲ）は、ＵＲＬキャッシュ５３６の中にあり、ＤＣＴによって制御されうる。以上説明したように、ここでは、キャッシュリスト及びＤＮＡファイルは、ＡＳＣＩＩフォームで作成されており、ユーザは、これらのファイルを見て、編集することができる。従って、ユーザは、アプリケーションを完全に制御することができる。しかし、通常、ユーザやＤＣＴは、ブラウザのキャッシュに格納されたファイルにアクセスすることができない。（分散可能なＤＮＡファイルのアップロード）ここでは、すべてのＤＮＡファイルは、ＡＳＣＩＩファイルである。そのため、クライアントコンピュータは、簡単に、ＤＣＴテクノロジーを用いてアプリケーションを開発し、ＤＮＡファイル（及び、必要であれば、これらのＤＮＡファイルと関係のある他のファイル）をサーバに送信することができる。そして、他のクライアントコンピュータが、アプリケーションを実行するために、これらのＤＮＡファイルをダウンロードすることができる。この発明で、サーバは、ファイルを保持するために使用されているが、この発明においては、必ずしもサーバを使用しなくてもよい。例えば、第１のクライアントコンピュータが第２のクライアントコンピュータにＤＮＡファイルを送信し、第２のクライアントコンピュータがアプリケーションを実行する場合には、中間のコンピュータ（サーバ、等）を必要としない。プログラマがグループでアプリケーションを開発する際に、この発明を用いることができる。図７を参照して説明したように、アプリケーションは、それぞれＤＮＡファイルと結びついた多くのセルを有する。これらのＤＮＡファイルの開発は、異なったコンピュータを用いて作業を行うプログラマ達に割り当てられる。彼らは、自分のＤＮＡファイルをサーバにアップロードし、サーバのプログラマは、これらのＤＮＡファイルをまとめて複雑なアプリケーションを作成することもできる。または、クライアントコンピュータにファイルをダウンロードし、これらのファイルをまとめてアプリケーションを作成することも可能である。そして、完成したアプリケーションをサーバにアップロードする。ネットワークに接続されたクライアントコンピュータは、この複雑なアプリケーション中のＤＮＡファイルをダウンロードし、実行することができる。第２の実施例この実施例は、強力なアプリケーション開発ツールを提供する。図１１及び図１２は、２つの実施例を示している。図１１は、ユーザが、マイクロソフト社のＭＳウィンドウズオペレーティングシステム下でビデオアプリケーションを作成する動作を説明するための図である。ＭＳウィンドウズや他のグラフィックオペレーティング環境における他のアプリケーションの作成にも、同様の過程を用いうる。ユーザは、ウィンドウ間の関係を定めるため、ウィンドウ６００をコンピュータディスプレイ６０２上に生成するセル（即ち、プログラムモジュール）をアクティブにする（起動する）。以下、このセルを「関係セル」と呼び、このセルと結びついたウィンドウを「関係ウィンドウ」と呼ぶ。この実施の形態において、ウィンドウ６００は、ユーザが関係を定めるためのテーブルを備えている。他の手段（例えば、図１２に示す方法）を用いてもよい。関係セルの詳細については、以下に述べる。ユーザは、ディスプレイ６０２上にビデオウィンドウ６０６（破線で示す）を生成するビデオセルをアクティブにする（起動する）。ウィンドウ６０６は、映画やアニメーションを表示する。ウィンドウ６０６を用いるビデオファイルの名称は、起動している間に定められる。同じウィンドウを、異なった映画（又はアニメーション）を表示するために用いることができるよう、ビデオファイルは簡単に変更することができる。このウィンドウ６０６は、関係ウィンドウ６００に登録され、テーブルのウィンドウ欄に識別符号（例えば、Ｎｏ．１）が付される。ここでは、（１）ビデオセルが関係セルに、ビデオセルがアクティブである（起動されている）ことを示すメッセージを送り、（２）関係セルがこの情報をメモリに格納する。セルは、ビデオセルに限られず、他のタイプのセルでもよい。次に、ユーザは、コントロールバーウィンドウ６０４（破線で示す）を生成する他のセル（ここでは、コントロールセル、という）をアクティブにする。コントロールセルがアクティブにされている間に、ユーザは、ビデオウィンドウ６０６を生成するビデオセルの名前を入力する。その結果、コントロールバー６０４が、ビデオウィンドウ６０６の動作を制御（例えば、スタート、巻き戻し、ストップ）するために用いられる。コントロールバー６０４は、関係ウィンドウ６００に登録され、テーブルのウィンドウ欄に識別符号（例えば、Ｎｏ．２）が付される。最後に、ユーザは、ウィンドウ６０８を生成するビジュアルセルをアクティブにする。ウィンドウ６０８は、関係ウィンドウ６００に登録され、テーブルのウィンドウ欄に識別符号（例えば、Ｎｏ．３）が付される。以下に説明するように、ウィンドウ６０８は、ビデオウィンドウ６０６と、コントロールバー６０４とのフレームとして用いられる。以下、ウィンドウ６０８を「フレームウィンドウ」と呼ぶ。この実施の形態においては、ウィンドウ６０８は、ウィンドウ６０４及び６０６と通信を行う必要はない。ユーザは、例えば、タイトルバー（図示せず）をマウス（図示せず）を用いてドラッグすることにより、ビデオウィンドウ６０４と、コントロールバー６０６とをフレームウィンドウ６０８内の別々の場所へと移動させることができる。これらの新しい場所を、それぞれ、実線のブロック６１２、６１４で示す。この時点では、ウィンドウ６０８は、ウィンドウ６０４、及び６０６から独立したウィンドウである。次に、ユーザは、ウィンドウ６０８と、ウィンドウ６１２、６１４との間の親子関係を定めるために、関係ウィンドウ６００の「親」欄に数字を入力する。この実施例において、フレームウィンドウ６０８（Ｎｏ．３で示される）は、ウィンドウ６１２及び６１４（それぞれＮｏ．１、Ｎｏ．２で示される）の親となる。親子関係は、ウィンドウ間の関係の中でもよく知られた関係であり、多くのウィンドウベースのオペレーティングシステム（ＭＳウィンドウズ、等）で用いられる。ここで、ウィンドウ６１２、６１４対フレームウィンドウ６０８の関係が確立される。このような関係を構築するための基本メカニズムについては、後述する。親子関係が確立されると、ウィンドウ６１２及び６１４は、あたかもウィンドウ６０８の一部であるかのごとく動く。例えば、ユーザが、フレームウィンドウ６０８をディスプレイ６０２上の別の場所へ移動させると、ウィンドウ６１２及び６１４も、ウィンドウ６０８と共に移動する。これは、子ウィンドウ（つまり、ウィンドウ６１２及び６１４）の位置が、親ウィンドウ（ここでは、フレームウィンドウ６０８）との関連で決まる、という親子関係（多くのウィンドウベースのオペレーティングシステムで採用される）の特質によるものである。ここでは、ビデオウィンドウ６１２は、映画やアニメーションを表示するために用いられる。コントロールバー６１４は、ビデオウィンドウ６１２のオペレーションを制御するボタンを備えている。例えば、ユーザがコントロールバー６１４上のスタートボタン（図示せず）をクリックすると、あらかじめ定められたビデオファイルに格納されている映画がビデオウィンドウ６１２上に表示され、ストップボタン（図示せず）をクリックすると、映画はストップし、巻き戻しボタン（図示せず）をクリックすると、映画が巻き戻される。ユーザがマウスでフレームウィンドウ６０８をドラッグすると、ウィンドウ６０８のすべてのコンテンツ（ウィンドウ６１２及びコントロールバー６１４を含む）が一緒に移動する。ユーザから見れば、フレームウィンドウ６０８とビデオウィンドウ６１２とコントロールバー６１４とは、複合したアプリケーションの一部を構成する。上述の実施の形態において、コントロールセルは、コマンドをビデオセルに送信することで、ビデオセルを制御している。例えば、ユーザがスタートボタンをクリックすると、コントロールセルは、ビデオの上映を開始するコマンドをビデオセルへ送信する。ソフトウェア作成者がアプリケーションの設計をほとんど完全に制御できるという点が、この発明の優れた点の一つである。例えば、作成者は、あらかじめ作成されたコントロールバーの一部をアプリケーションにおいて用いることができる。また、ビデオウィンドウに代えて他のタイプのディスプレイウィンドウを選択することもできる。例えば、作成者は、グラフィックウィンドウやテキストウィンドウを制御するために、コントロールバーの一種であるスクロールバーを選択することができる。つまり、この発明におけるシステムは、非常にしっかりしていて、柔軟性に富んでいる。システムの保守やアップグレードが簡単である点もこの発明の利点である。例えば、ソフトウエア開発者は、最初は少数のコントロールバーやディスプレイウィンドウを備えるオーサリングソフトウエアを提供できる。そして、必要なときに、他の種類のコントロールバーやディスプレイウィンドウをオーサリングソフトウエアに付け加えることができる。さらに、アプリケーションの各構成部分間のインタフェースが同じであれば、アプリケーションを変更することなく、構成部分をアップグレードすることもできる。従来のプログラミング方法においては、上述の各ウィンドウ（６０８、６１２、６１４）の集合体は、映画再生ルーチンやコントロールルーチンを含む複雑なアプリケーションによって生成されており、各ルーチンは、しっかりと結合していた。この性質により、ユーザは、わずかな変更しかできず、アプリケーションをアップグレードするためには、他の完全なアプリケーションを再度インストールしなければならなかった。このため、従来のアプリケーションは柔軟性を欠き、保守が困難で、アップグレードに時間を要した。ユーザは、親ウィンドウと子ウィンドウとを自由に選択することができる。他のアプリケーションを作成する場合には、例えば、ビデオウィンドウ６０６を親ウィンドウとし、ウィンドウ６０８を子ウィンドウとすることができる。このため、この発明によれば、非常に柔軟性に富んだアプリケーションを開発することができる。図１４は、上述のオペレーションを示すフローチャート６３０である。ステップ６３４で、ユーザは、関係セルをアクティブにする（起動する）。この関係セルは、関係ウィンドウを表示させる。ステップ６３６で、ユーザは、ディスプレイウィンドウを表示させるプログラムセル（ビジュアルセルや他のセルでもよい）をアクティブにする。プログラムセルは、関係セルとの通信を行うプログラムコードを有している。ステップ６３８で、新しくアクティブされたプログラムセルが関係セルに登録される。これは、プログラムセルが上述の通信プロトコルを用いて関係セルにメッセージを送信することにより行われる。ステップ６４０で、ユーザは、他のセルやウィンドウをアクティブする必要があるかどうかを判断する。他のセルをアクティブする必要がある場合には、ステップ６３６へ戻り、他のセルをアクティブにする。他のセルをアクティブにする必要がない場合には、ステップ６４２へ進み、アプリケーションを設計する次の処理（つまり、関係の定義）を行う。ステップ６４２で、ユーザは、第２のディスプレイウィンドウ（関係ウィンドウ以外）内の任意の場所に第１のディスプレイウィンドウ（関係ウィンドウを除く）を移動させ、これらのウィンドウの親子関係を決定する。つまり、関係ウィンドウが、第１のウィンドウを第２のウィンドウの子ウィンドウとする。一旦、あるウィンドウが子ウィンドウとなると、関係セルは、オペレーティングシステムによって、そのウィンドウを子ウィンドウのスタイルに変形させる（ステップ６４４）。このオペレーションを実行するメカニズムは、図１５を参照して後述する。子ウィンドウの外観は、対応する親ウィンドウとの関係であらかじめ定められる（例えば、ＭＳウィンドウズ環境においては、子ウィンドウは、親ウィンドウの外へ出ることはできない）。ステップ６４６で、ユーザは、各ウィンドウ間に、さらに関係を設定するかどうかを判断する。各ウィンドウ間に、さらに関係を設定する場合には、ステップ６４２へ戻り、関係を設定する。各ウィンドウ間に、これ以上関係を設定しない場合には、フローチャート６３０の処理を終了する。アプリケーションは、親子関係の階層構造を成している場合もある。例えば、第１のウィンドウは第２のウインドウの子ウインドウであり、この第２のウインドウは第３のウィンドウの子ウィンドウである、とする。この場合において、第１のウィンドウは第２のウィンドウによって拘束され、第２のウィンドウは第３のウインドウによって拘束される。第３のウィンドウが移動すると、第１及び第２のウィンドウは、第３のウィンドウと共に移動する。親ウィンドウは、複数の子ウィンドウを、同じレベルに置くこともできる。関係セル及び関係ウィンドウを用いてセル間の関係を定めるのが、一つの方法である。他の方法を説明する。一部のセル（例えば、ビジュアルセル、ボタンセル）を編集モードに切り換え、編集ウィンドウに情報を入力することによってセルの特徴を変化させる。セルが編集モードであるときは、ダイアログボックスが表示される。ユーザは、様々なアイコンをクリックし、選択されたボックスに文字を入力することができる。編集モードが終了し、実行モードへ戻ると、セルは、ダイアログボックスに入力された情報に従って新しい働きをする。ここでは、ダイアログボックスは、ユーザが親子関係を定めるためのアイコン（以下、関係アイコン）を備えている。図１２は、関係ウインドウを必要としない実施例を示す図である。ここでは、関係ウィンドウの代わりに上述の関係アイコンを使用し、ユーザは、ウィンドウの関係を定めるために数字を入力する必要がない。図１１と図１２とでは、同一部分に同一符号を付している。この発明の実施の形態を説明するため、図１２は、編集ウィンドウ６０７の形式でビデオセルを示している。ビデオセルは、ユーザがこのウィンドウを子ウィンドウに指定するための関係アイコン６１６を備えており、ユーザは、関係アイコン６１６をクリックして、このウィンドウが、次に定める親ウィンドウの子ウィンドウとなることをシステムに通知する。次に、ユーザは親ウインドウを選択する。例えば、ユーザは、マウス６２２でビデオウィンドウ６０７のタイトルバーをドラッグして、カーソル６２０をフレームウィンドウ６０８の中に移動させる。カーソル６２０がフレームウィンドウ６０８中の適当な位置に来たところで、ボタンを離し、この位置が所望の位置であること及びフレームウィンドウ６０８が親ウィンドウとなるべきことを指示する。そして、ユーザは、編集ウィンドウ６０７で表されるビデオセルを編集モードから抜けさせる。新しいウィンドウ（ウィンドウ６１２）がフレームウィンドウ６０８の中に生成され、ビデオセルのオリジナルウィンドウ６０７は消滅する。ウィンドウ６１２は、オペレーティングシステムにより、フレームウィンドウ６０８の子ウィンドウとされる。この親子関係の創設に関するメカニズムの詳細は、図１５を参照して後述する。図１２はまた、編集ウィンドウ６０９のコントロールセルも示している。コントロールセルは、図１１を参照して述べた方法で、ビジュアルセルと通信を行い、ビジュアルセルを制御する。編集ウィンドウ６０９は、関係アイコン６１７を備え、ユーザは、関係アイコン６１７を用いて、このウィンドウを子ウィンドウに指定する。ユーザは、関係アイコン６１７をクリックし、カーソル６２０をフレームウィンドウ６０８中の適当な位置へ、マウス６２２のボタンを押すことにより移動させ、ボタンを離して子ウィンドウの表示位置を定める。編集ウィンドウ６０９が消滅すると、新しいウィンドウ（ウィンドウ６１４）がフレーム６０８中に生成される。コントロールセルに対応付けられたオリジナルウィンドウは消滅し、ウィンドウ６１４は、オペレーティングシステムにより、フレームウィンドウ６０８の子ウィンドウとされる。図１４は、上述のオペレーションを示すフローチャート６６０である。ステップ６６２で、ユーザは、第１のセル（ビジュアルセル、ビデオセル、等）、及び第１のセルに対応付けられたウィンドウをアクティブにする（起動する）。ここでは、第１のセルを親ウィンドウとする。ステップ６６４で、ユーザは第２のセル（ビジュアルセル、ビデオセル、等）及び第２のセルに対応付けられたウィンドウをアクティブにする。ユーザは、第２のセルを編集モードに切り換える。そして、関係アイコンをクリックし（ステップ６６６）、第１のセルのウインドウ内の位置を指示することにより、子ウィンドウの新しい位置を第１のセルの中に定める（ステップ６６８）。上述の例では、子ウィンドウの位置は、カーソルを移動させることで定められる。次に、第２のセルのウィンドウのスタイルが、子ウィンドウのスタイルへと変えられる（ステップ６７２）。このステップを実行するメカニズムの詳細については、図１５との関連で後述する。第２のセルのオリジナルウィンドウは消滅し、子ウィンドウが、第１のセル中の希望の位置に生成される（ステップ６７４）。フローチャート６６０の処理で、親ウィンドウとなった第１のセルのウィンドウに、さらに子ウィンドウを加えることができる。この場合には、他の子ウィンドウを第２のセルのウィンドウと同レベルに置くことができる。子ウィンドウが、他の子ウィンドウの中に位置していてもよい。ステップ６６８で、ユーザが、既存の子ウィンドウの中を指定できるようにすれば、新しく生成されたウィンドウを、既存の子ウィンドウの子ウィンドウとすることができる。そうすれば、新しい子ウィンドウは、既存の子ウィンドウの外へ移動することができなくなり、親ウィンドウの外へ移動することもできなくなる。このようにして、親子関係の階層構造が創設される。さらに、他の実施例として、親ウィンドウは同一レベルの子ウィンドウを複数備え、各ウインドウ又は全てのウィンドウは、子ウィンドウ（親ウィンドウの孫ウィンドウと言うべき）を備えるようにしてもよい。孫ウィンドウは、さらに、子ウィンドウを備えることができ、この発明における親子関係には制限がない。図１５は、子ウィンドウの作成過程を示すフローチャート７００である。ここでは、子ウィンドウとなる第１のウィンドウと、親ウィンドウとなる第２のウィンドウとの２つのウィンドウが存在する。親子関係が形成される前は、これら２つのウィンドウは、完全に独立又はＤＣＴや他のプログラム構造の下で互いに影響し合っている。第１のウィンドウは、ユーザから、第１のウィンドウを子ウィンドウとするコマンドを受け取ると、第２のウィンドウに親ウィンドウとなるよう、指示を送る（ステップ７０２）。ここでは、この指示は、第１のウィンドウのウィンドウハンドルを含む。ステップ７０４で、第２のウィンドウは、第１のウィンドウの親ウィンドウとなるのに適当か否かを判断する。適当な場合には、フローチャート７００は、ステップ７１０へ進み、第２のウィンドウが親ウィンドウとなる準備をする。ＭＳウィンドウズ環境下では、このステップで、第２のウィンドウの「ベースウィンドウ」を準備するために、「SetWindowLong」機能を使用する。第２のウィンドウは、第１のウィンドウへ通知する。ここでは、第２のウィンドウのウィンドウハンドルは、第１のウィンドウへと渡される。「ベースウィンドウ」の概念については、図１６Ａを参照して説明する。図１６Ａは、一般的なウィンドウ７３０の構成を示している。このウインドウ７３０は、ウィンドウのすべての構成要素を備えているので、このウィンドウを、「トップレベルウィンドウ」と呼ぶ。例えば、ウィンドウ７３０は、タイトルバーとツールバーとを備えた領域７３２、及び、ステータスバーを備えた領域７３３を備えている。領域７３２及び７３３は、ＭＳウィンドウズオペレーティングシステムにより生成される。ベースウィンドウ７３６は、ユーザが、ビデオ、グラフィック、テキスト、等の形式で生成した情報を表示する、領域７３２及び７３３を除いた領域である。トップレベルウィンドウは、ベースウィンドウ７３６や領域７３２、７３３を含むこれらすべてのもので成り立っている。子ウィンドウ（図１６Ｂに示すウィンドウ７５２等）が親ウィンドウ（図１６Ｂに示すウィンドウ７５０等）の内部に生成されると、完全なウィンドウ（つまり、トップレベルウィンドウ）が親ウィンドウの中に生成される。しかし、子ウィンドウの生成によって影響を受けるのは、親ウィンドウのベースウィンドウのみである。これは、ステップ７１０が第２のウィンドウのベースウィンドウのみに影響するからである。再び図１５に戻るが、ステップ７１２で、第１のウィンドウは、自らが子ウィンドウとなる準備をする。ＭＳウィンドウズ環境下では、第１のウィンドウのトップレベルウィンドウを準備するために「SetWindowLong」機能を用いる。ステップ７１４で、第１のウィンドウは、子ウィンドウとなる。ＭＳウィンドウズ環境下では、「SetParent」機能を用いる。これは、子ウィンドウを再描画するものである。ステップ７０４で、第２のウィンドウが第１のウィンドウの親ウィンドウとならないことを決定した場合には、ステップ７２０へ進み、第２のウィンドウは、自らは第１のウィンドウの親ウィンドウとならないことを、第１のウィンドウへ通知する。そして、このフローチャートの処理を終了する。第３実施例図１７は、従来のオブジェクト指向のプログラミング（ＯＯＰ）の構成８００を示す。このプログラムは、図１７に符号８０２〜８１０で示すように、多くのクラスから構成されている。多くのソフトウェアアプリケーションにおいて、これらのクラスは、階層構造を成している。構成８００において、各クラス間の通信は、階層状の経路をたどる。例えば、構成８００のブランチの末端にあるクラス８０７は、同一ブランチ内の他のクラスとは直接通信を行えるが、他のブランチ内のクラス（クラス８０９、等）とは、直接には通信できない。そのため、クラス８０７がクラス８０９と通信を行うためには、両者共通のクラス８０３を介してメッセージを送受信する。同様に、クラス８０７がクラス８０６と通信を行う場合には、両者共通のクラス８０２を介してメッセージを送受信する。上述の通信方法は、単純なアプリケーションに適している。しかし、アプリケーションが複雑になると、様々なブランチや通信経路を維持することが困難となる。さらに、あるクラスの階層中の位置が変化することにより、そのクラスと通信を行う必要のあるすべてのクラスのプログラムコードが影響を受けるため、アプリケーションのグレードアップは難しくなる。図１８は、この発明のプログラミングの構成８２０を示す。構成８２０は、図１８の８２２〜８２６に示すように、多くのクラスから構成されている。クラス８２２〜８２５は、クラス８２６とのみ通信を行う通常のＯＯＰクラスである。クラス８２６は、構成８２０におけるクラス８２２〜８２５の間の通信を管理する特別な（専用の）クラスである。この発明の他の実施の形態において、クラス８２６は、クラス８２２〜８２５と構成８２０の外のプログラムモジュール（例えば、他のアプリケーション）との通信も制御する。つまり、クラス８２６は通信制御クラスであると言うことができ、以下、コントローラ８２６と呼ぶ。クラス８２２〜８２５は、相互の通信を直接行うことはできず、コントローラ８２６を介して通信を行う。例えば、クラス８２２がクラス８２３にメッセージを送信する場合、まずコントローラ８２６にメッセージを送信する。メッセージは、（１）送信先のクラス（例えば、クラス８２３）への指示（インストラクション）を含み、（２）送信先のクラスの名前やアドレスを含んでもよい。指示が送信先のクラスに特有（固有）のものである場合には、その指示によって、送信先のクラスを識別することが可能である。この場合には、コントローラ８２６は、指示とその指示に対応するクラスとのリストを有する。そして、コントローラ８２６が送信先を示す情報を持たないメッセージを受信したときには、リストを参照してメッセージの送信先を決定する。こうして、メッセージは、正しい送信先へと転送される。上述のコントローラクラスを介した通信のプロトコルは、以下、「ローカル・ディジタル・シフティング・ファンクション」（ローカルＤＳＦ）プロトコルと呼ぶ。多くのアプリケーションにおいて、構成８２０中の各クラスは、それぞれ別個にアクティブにされる（起動される）。そのため、コントローラ８２６は、どのクラスがアクティブであるか（起動されているか）を示すトラックを保持する必要がある。各クラスは、起動プロセスの一環として、コントローラ８２６にメッセージを送信して、自分自身を登録させる。これにより、コントローラ８２６は、このクラスのためのリソース（資源）を確保する。クラスがデアクティブ（終了）されたときには、コントローラ８２６が該クラスのために確保したリソースを他のクラスのために解放するよう、コントローラ８２６にメッセージを送信しなければならない。よって、コントローラ８２６は、どのクラスがアクティブされていて、メッセージの送受信が可能であるのかを知ることができる。この実施の形態の他の例においては、クラス８２２〜８２５とコントローラ８２６との間の通信には、確認のメッセージ（又は戻り値）は不要である。例えば、クラス８２２がコントローラ８２６にメッセージを送信した場合に、コントローラ８２６はクラス８２２に、何らの返答（値又はメッセージの返送）をする必要はない。同様に、コントローラ８２６がクラス８２２からのメッセージをクラス８２３に転送する場合にも、クラス８２３はコントローラ８２６に、何らの返答をする必要はない。従って、最小のオーバーヘッドと遅延時間で通信を行うことができる。この発明の他の実施の形態において、クラス８２２〜８２５とコントローラ８２６との間のメッセージは、ＡＳＣＩＩコード化される。つまり、指示名や送信先クラスの識別符号等の任意の情報は、ＡＳＣＩＩフォーマットでコード化される。図１９は、コントローラ８２６の構造を示している。コントローラ８２６は、ローカルＤＳＦプロトコルを受信、処理、送信するプログラムコード８４０のブロックと、構成８２０の外部からの指示を受信、処理、送信するプログラムコード８４１のブロックとを備える。ブロック８４０及び８４１は、２つの記憶領域、つまり、（１）指示とその指示に対応付けられているクラスのリストとを記憶する領域８４４、及び、（２）アクティブにされているクラスの情報を記憶する領域８４５、と通信を行うことができる。領域８４４に記憶されている情報は、各指示と送信先のクラスとを結びつけるために用いられる。例えば、ブロック８４０がクラス８２２〜８２５又は構成８２０の外部から送信先が明示されていないメッセージを受信した場合、コントローラ８２６は、領域８４４内のリストを参照し、該メッセージの送信先を決定する。送信先が見つからない場合には、メッセージは無視される。領域８４５内の情報は、あるクラスがアクティブされた場合に、構成８２０内のクラスによって、コントローラ８２６に与えられる。アクティブにされたクラスは、コントローラ８２６に情報を登録し、登録情報をコントローラ８２６に提供する。この情報により、コントローラ８２６がメッセージを効果的に管理することが可能となる。この発明において、コントローラ８２６は、メッセージの通信を制御する機能のみを有する専用のプログラムモジュールである。このため、コントローラ８２６を、サイズが非常に小さく処理速度が非常に速い、というように、効率的に作成することができる。２つの数字の演算結果を表示する処理を例に、構成８２０のオペレーションについて説明する。ここでは、（１）クラス８２２は、ユーザが数字を入力する対話ボックスクラス、（２）クラス８２３は、その数字に計算処理を行う演算クラス、（３）クラス８２４は、演算クラス８２３における計算結果を含む情報を表示する表示クラス、とする。この発明においては、これらの３つのクラスの階層構造を知る必要はない。なぜなら、これら３つのクラスとコントローラ８２６との間の通信は、１対１で行われるからである。アクティベーション（起動）プロセスの一環として、クラス８２２〜８２４は、コントローラ８２６に登録される。対話ボックスクラス８２２は、ユーザがマウスやキーボードを用いて行った入力を受け付ける。数字等の適当な情報が入力されると、対話ボックスクラス８２２は、この入力を受け付け、ローカルＤＳＦプロトコルを用いてエンコードし、コントローラ８２６を介して演算クラス８２３へ送信する。演算クラス８２３は、２つの数字と「加算」オペレーションとを受け取ると、２つの数字の合計を計算する。計算結果は、コントローラ８２６を介して、演算クラス８２３から表示クラス８２４へと送られる。表示クラス８２４は、計算結果を受け取って、ウィンドウに表示する。上述の通り、各クラスは、このアプリケーションの階層構造を知る必要はない。すべての通信は、ただ１つのコントローラに向けられている。例えば、演算クラス８２３は、計算、積分、論理オペレーションを行うクラスを含む数学クラスの１ブランチであってもよい。従来の通信方法では、対話ボックスクラス８２２は、演算クラス８２３との関係で、この階層構造を知る必要があったが、この発明においては、その必要はない。このアーキテクチャにより、プログラミングの複雑さが緩和される。即ち、このアーキテクチャにより、より効率良くプログラムコードを開発、保持することができる。このため、通信制御クラスを付加して、そのクラスを介した通信を必要とするというオーバーヘッドは発生するが、コントローラ８２６に、限られたオペレーションを実行させるように設計することにより、プログラムのサイズと処理の速度という観点からは、オーバーヘッドは最小となる。（アーキテクチャの拡張）上述のアーキテクチャ（構成）は、簡単に拡張することができる。この場合においては、構成８２０は、マルチモジュールアプリケーションの１プログラムモジュールである。このアプリケーションは、従来の構成によっても、ディジタル・セル・テクノロジー（ＤＣＴ）と呼ばれる新しいプログラミング技術によってもよい。ＤＣＴにおいては、アプリケーションは、プログラムセルによって構築されている。ＤＣＴと従来の構造との主な違いは、ＤＣＴは、セルのオペレーションを制御する「ボス」を持たないことである。すべてのセルは同等のレベルに位置し、セルからセルへと、直接に指示が送られる。これとは対照的に、従来のアプリケーションは、メインプログラム（ボス）と様々なレベルのサブプログラムから構築されている。下位のサブプログラムが上位のサブプログラムと通信を行うためには、様々なレベルを通過しなければならない。第１の拡張例においては、各セルは、構成８２０と同様に設計されている。そのため、各セルは、（１）セル内の各クラス間、（２）セル内のクラスと他のセルとの間、の通信を管理する通信コントローラを備える。セル内の各クラスは、相互の通信を直接に行うことはできないように設計されている。図２０は、グループ化されて、アプリケーション８５０又はアプリケーションの一部を形成する複数のセル８５２〜８５５を示している。各セルは、図１８のセルと同様に設計されている。そのため、各セルは、セル相互間の通信を管理するために、通信制御クラス（図２０には図示せず）を備えている。アプリケーション８５０は、さらに、通信制御セル８５６を備える。通信制御セル８５６は、図１８の通信制御クラス８２６と同様の役割を果たす。各セルは、通信制御セル８５６とのみ通信を行うように設計されている。アプリケーション８５０の通信プロトコル、及び、オペレーション方法は、構成８２０のそれと同様である。アプリケーション８５０は、通信制御セル８５６を介して他のアプリケーションや、インターネット等のデータネットワークとの通信を行うことができる。図２０の構成において、セル内の各クラスは、他のセルが利用できるように形成されてもよい。この場合において、第１のセル（例えば、セル８５２）は、通信制御セル８５６を介して第２のセル（例えば、セル８５３）に指示を送る。第１のセルのコントローラクラスは、第１のセル内の適当なクラスにその指示を送る。セルは、セル内のいくつかの、又は、すべてのクラスを他のセルから見えないようにしてもよい。この配置によれば、セル内のクラスを他のセルと共有することができる。図１８及び図２０のアーキテクチャは、いかなるレベルにも応用することができる。各レベルにおける構成要素（例えば、図１８におけるクラスや、図２０におけるセル）の数や、レベルの数は、必要とされるアプリケーションの複雑さによって異なる。この発明によれば、通信は、構成要素やレベルの増加に伴って徐々に複雑になるが、従来のシステムは、クラスの数やレベルの増加に伴って急激に複雑となる。以下、上述のシステムを用いたマルチコンピュータアプリケーションの構成の例を説明する。図２１は、データネットワーク９０６に接続された複数のコンピュータ９０２〜９０４を示している。これらのコンピュータは、図２０に示すアプリケーション９５０と同様に構成されたアプリケーションを実行し、図１８のプログラミング構造９２０を使用するように設計されている。例えば、２つのコンピュータ、例えば、９０２と９０４は、コンピュータ９０２内の部分９１０ａと、コンピュータ９０４内の部分９１０ｂを実行する。部分９１０ａは、セル９１２、９１３のようなセルから構成されており、そのうちの１つ（例えば、セル９１２）は、コントローラセルである。部分９１０ｂもまた、セル９１６、９１８のようなセルから構成されており、そのうちの１つ（例えば、セル９１６）は、コントローラセルである。部分９１０ａが、コンピュータ９０４内のセル９１８を使用する必要がある場合には、コントローラセル９１２は、データネットワーク９０６を介して、コントローラセル９１６にコマンドを送る。コントローラセル９１６は、受け取ったコマンドをセル９１８へ送る。ここで述べたセル間の通信プロトコルは、上述のＰＣＴ特許出願（出願番号：ＰＣＴ／ＪＰ９６／００８２１）におけるセル間の通信プロトコル（ＤＳＦ）とは若干異なる。また、この拡張形態は、ＤＣＴ技術に限定されず、従来のプログラミング構成に適用することも可能である。この実施例の通信プロトコルは、第２の実施例に好適である。第４の実施例図２２Ａと図２２Ｂは、従来の技術におけるテキストイメージのスクロールシステムを説明するための図であり、同一部分には同一符号を付している。図２２Ａに示すように、ウィンドウ１０００の中にテキストイメージ１００２が表示されている。テキストイメージ１００２は１０行で構成されており、それぞれ“Ｔｈｉｓｉｓｌｉｎｅ”で始まり、その後に行番号を伴っている。このスクロールシステムはまた、スクロール方向を示す２つの矢印１００８、１００９を備える垂直方向のスクロールバー１００６を有している。ユーザは、テキストイメージ１００２を上下にスクロールするために、この２つの矢印１００８、１００９をクリックする。なお、テキストイメージやスクロール方向はこの発明を説明するためのものにすぎず、これらに限定されず、任意である。テキストイメージ自体は、アスキーファイルのようなテキストベースファイルに基づくコンピュータシステムによって生成されるのが一般的であり、スクロール方向も垂直方向、水平方向、斜め方向等、任意である。図２２Ｂは、矢印１００９が１回クリックされた時のテキストイメージ１００２の変化を示している。多くのコンピュータシステムにおいては、１行分スクロールするアルゴリズムが用いられている。そのため、図２２Ａにおいては第２行目であった“Ｔｈｉｓｉｓｌｉｎｅ２”が、図２２Ｂにおいては第１行目となる。つまり、従来の技術におけるテキストイメージのスクロール時の単位は１行である。マイクロソフト社のＭＳウィンドウにおいては、ＶＧＡディスプレイの解像度は６４０×４８０画素である。ＶＧＡの下でスクリーン全体に表示することができるのは、通常のフォントサイズの場合、５０行未満である。従って、１行スクロールすると、１０画素以上変化する。その結果、テキストイメージのスクロール時に、断続的なイメージしか表示できない。一部のユーザは、その断続的なイメージに困惑し、グラフィカル・ユーザ・インタフェース（ＧＵＩ）環境下で制御されるテキストイメージベースのソフトウェアの使用を敬遠する可能性がある。図２２Ａ及び図２２Ｂには、垂直方向のスクロールのみを示したが、行の代わりに１文字単位でスクロールする水平方向のスクロールでも同様のことが言える。最小シフト量が大きい原因の１つは、多くのＧＵＩベースのオペレーティングシステムが、行単位又は文字単位のアプリケーション・プログラム・インタフェース（ＡＰＩ）を提供している点にある。例えば、マイクロソフト社のウィンドウズオペレーティングシステムにおける、「ラインスクロール」機能がそうである。この機能は、垂直方向にスクロールさせる行の数や、水平方向にスクロールさせる文字の位置を指定するためのパラメータを有している。この機能によれば、垂直方向のスクロールの最小単位は１行、水平方向のスクロールの単位は１文字、となる。そのため、スクロール時のテキストイメージは断続的なものとなる。「ラインスクロール（LineScroll）」機能やそれに準ずる機能を用いる合理的理由もある。まず、テキストイメージをスクロールするためには、それが最も効率的である。プログラマは、簡潔な「ラインスクロール」機能を発行すれば良く、ウィンドウ上にテキストを表示するための複雑なルーチンを書く必要はない。また、これが、テキストイメージをスクロールするための唯一の方法である場合がある。これは、オペレーティングシステムの描画処理の形式が公になっているか否かという問題である。一般に、テキストイメージは様々なフォントやサイズの文字及び数字を含む。描画ルーチンは、テキストファイルを読み出し、適当なウィンドウに、正確なフォントサイズで体裁を整えたイメージを書き込む必要がある。しかし、サイズ、位置、ディスプレイウィンドウの形式、及びフォントラスタライザは、オペレーティングシステムによって制御され、オペレーティングシステムは十分な情報を提供せず、また、独自のスクロールルーチンのための制御を行わない。この発明は、プログラマが、ＧＵＩベースのＡＰＩを用いた場合のように行単位ではなく、画素単位でテキストイメージをスクロールすることを可能とする。画素とは、表示の最小単位である。よって、このスクロール方法によれば、最小単位でスクロールを行うことができる。図２３は、この発明におけるスクロール処理を示す概要図である。アプリケーションウィンドウ１０５０は、インフォメーションエリア１０５２とクライアントエリア１０５４とを備えている。インフォメーションエリア１０５２は、オペレーティングシステムによって生成され、一般的には、ウィンドウに関連するタイトル、メニューバー、ツールバーを備えている。クライアントエリア１０５４は、プログラマやユーザが与えた情報を表示する。例えば、通常、テキストイメージは、アプリケーションウィンドウ１０５０のクライアントエリア１０５４に表示される。図２３は、アプリケーションウィンドウ１０５０の子ウィンドウ１０６０も示す。「子」ウィンドウ、及び、「親」ウィンドウという概念は、ＧＵＩベースのシステムにおいてはよく知られている。この発明において、子ウィンドウ１０８０は、アプリケーションウィンドウ１０５０のクライアントエリア１０５４よりもわずかに大きいクライアントエリアを備えている。ウィンドウ１０６０と１０５０とは、アプリケーションウィンドウ１０５０のクライアントエリア１０５４が子ウィンドウ１０６０に重なって、子ウィンドウ１０６０の一部がコンピュータのスクリーンに表示されるように構成される。この発明においては、テキストイメージは、アプリケーションウィンドウ１０５０ではなく、子ウィンドウ１０６０のクライアントエリアに書き込まれる。アプリケーションウィンドウ１０５０のクライアントエリア１０５４は、フレームの役割を果たし、ユーザは、該フレーム中のテキストイメージを見ることができる。図２２Ａ及び図２２Ｂのテキストイメージ１００２を参照してこの発明を説明する。まず、テキストイメージ１００２が子ウィンドウ１０６０に書き込まれる。子ウィンドウ１０６０は、第１行、即ち、“Ｔｈｉｓｉｓｌｉｎｅ１”が、アプリケーションウィンドウ１０５０のクライアントエリア１０５４の最上部に位置するように配置される。その後、子ウインドウ１０６０は、一度に１画素ずつ、上側に移動される。この処理は、ＭＳウィンドウ下では、「ムーブウィンドウ（MoveWindow）」ＡＰＩ機能を用いて実行可能である。子ウィンドウ１０６０のうち、アプリケーションウィンドウ１０５０のクライアントエリア１０５４に囲まれた部分のみがコンピュータのスクリーンに表示されるため、テキストイメージ１００２は、行単位ではなく、画素単位で上方向にスクロールするように見える。子ウィンドウ１０６０が１行分完全に上方向にスクロールされる（つまり、“Ｔｈｉｓｉｓｌｉｎｅ１”の行がコンピュータのスクリーン上から消える）と、子ウィンドウ１０６０は、即座に自分自身を消去し、自分自身を元の場所に再度書き込む。それとほぼ同時に、ウィンドウズＡＰＩの「ラインスクロール（LineScroll）」機能が起動され、子ウィンドウ１０６０中のテキストイメージを１行分スクロールする。その結果、“Ｔｈｉｓｉｓｌｉｎｅ２”の行が、“Ｔｈｉｓｉｓｌｉｎｅ１”の行に置き換わる。子ウィンドウ１０６０が、元の位置に戻るため、この行は、アプリケーションウィンドウ１０５０のクライアントエリア１０５４の最上部に表示される。さらにスクロールを続けると、子ウィンドウ１０６０は再び画素単位で上に動く。子ウィンドウ１０６０のサイズは、次の点を考慮して定まる。（１）子ウィンドウ１０６０は、元の位置に戻る前に１行分上下に移動する可能性がある。このため、子ウィンドウ１０６０は、垂直スクロールの場合には、少なくとも垂直方向に２行分、アプリケーションウィンドウ１０５０よりも大きくなければならない。（２）子ウィンドウ１０６０は、元の位置に戻る前に１文字分左右に移動する可能性がある。そのため、子ウィンドウ１０６０は、水平スクロールの場合には、少なくとも水平方向に２文字分、アプリケーションウィンドウ１０５０よりも大きくなければならない。図２４は、上述の処理を説明するためのフローチャート１１００である。ステップ１１０２において、子ウィンドウは、コンピュータのスクリーン上の適当な位置に、このスクロールシステムによって生成される。子ウインドウの位置は、テキストイメージの適当な部分が、アプリケーションウィンドウ内に位置するように、アプリケーションウインドウの位置と調整される。ステップ１１０４において、オペレーティングシステムとアプリケーションソフトウェアとは、ユーザが、テキストイメージのスクロールを望んでいるか否かを判別する。ユーザがスクロールを望んでいないと判別した場合は、ユーザがスクロールを希望するまで、ステップ１１０４で待機する。ユーザが、テキストイメージのスクロールを望んでいると判別した場合は、ステップ１１０６へ進み、ユーザの指示した方向へ、子ウィンドウを１画素分移動させる。ステップ１１０８においては、ユーザがさらにスクロールを望んでいるか否かを判別する。ユーザが、これ以上はスクロールを望んでいないと判別した場合は、スクロールを停止する（ステップ１１１０）。ユーザがさらにスクロールを望んでいると判別した場合は、垂直方向に１行分又は水平方向に１文字分、完全にスクロールしたか否かを判別する（ステップ１１１２）。完全にスクロールしていない場合は、ステップ１１０６、つまり、１画素単位でのスクロールへ戻る。完全にスクロールした場合には、ステップ１１１６へ進み、子ウィンドウは自己を消去し、元の場所へ自己を再度描画する。ステップ１１１８において、テキストイメージは、ＡＰＩ機能の行単位又は文字単位のスクロール方法でスクロールされる。そして、ステップ１１０６へ戻り、１画素単位でのスクロールを行う。他の例において、ステップ１１１６において他の動作を行ってもよい。子ウィンドウを、素早く元の位置へ戻し、それと同時又はほぼ同時に、ステップ１１１８で、行単位のスクロールを実行する。この場合、ステップ１１１６の処理は、「消去と再描画」ではなく、「素早く動く」になる。上述の通り、このシステムにおいては、ＧＵＩベースのオペレーティング環境等で利用可能なＡＰＩを用いて、画素単位でのスクロールが可能である。その結果、簡単にプログラミングを行うことができる。スクロールを、行単位や文字単位で行うのではなく、画素単位で行うため、テキストイメージの動きが非常にスムーズなものとなる。図２２Ａ及び図２２Ｂ中の行数は、本発明を説明するために用いたに過ぎない。テキストイメージは、任意の文字数で構成され、任意の行数から構成される。上述のＡＰＩも、本発明を説明するために用いたに過ぎない。ここでは、特定の実施例により、この発明を説明したが、発明の広い精神とスコープからはずれることなく、様々な応用、変形が可能である。従って、上述の説明、及び、図面は、限定的なものではなく、説明のためのものであり、この発明は、請求項にのみ拘束される。ここでは、特定の実施例により、この発明を説明したが、発明の広い精神とスコープからはずれることなく、様々な応用、変形が可能である。従って、上述の説明、及び、図面は、限定的なものではなく、説明のためのものであり、この発明は、請求項にのみ拘束される。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号０８／６８０，０４９ (32)優先日平成８年７月12日(1996．7．12) (33)優先権主張国米国（ＵＳ） (31)優先権主張番号０８／６８０，７２２ (32)優先日平成８年７月12日(1996．7．12) (33)優先権主張国米国（ＵＳ） (81)指定国ＥＰ(ＤＥ，ＧＢ)，ＣＮ，ＪＰ，ＫＲ

Claims

【特許請求の範囲】１．複数のコンピュータ（４０４−４１０，４１０−４１２）を接続する通信ネットワークを備えたシステムであって、前記システムは、第１のプログラムモジュール（４６０）と前記第１のプログラムモジュールに対応付けられた第１のパラメータファイルと、第２のプログラムモジュールと前記第２のプログラムモジュールに対応付けられた第２のパラメータファイルと、を備え、前記第１のプログラムモジュールは、第１のコマンドを前記第２のパラメータファイルへ送信する手段を備え、前記第２のプログラムモジュールは、第２のコマンドを前記第１のパラメータファイルへ送信する手段を備え、前記第１のプログラムモジュールは、実行結果を前記第２のプログラムモジュールへ送信することなく前記第２のコマンドを実行する手段を備え、前記第２のプログラムモジュールは、実行結果を前記第１のプログラムモジュールへ送信することなく前記第１のコマンドを実行する手段を備え、前記第１のパラメータファイルは、第１のコンピュータに格納され、前記第１及び第２のプログラムモジュールは、第２のコンピュータに格納され、前記システムは、前記第１のパラメータファイルの少なくとも一部を第２のコンピュータにダウンロードするダウンロード手段と、前記第１のパラメータファイルのダウンロードに応答して前記第１のプログラムモジュールを起動する起動手段と、をさらに備える、ことを特徴とするシステム。２．前記第１及び第２のパラメータファイルはＡＳＣＩＩファイルである、ことを特徴とする請求項１に記載のシステム。３．前記起動手段は、前記第１のプログラムモジュールを起動するために前記第１のパラメータファイルの拡張子を使用する手段を備える、ことを特徴とする請求項１に記載のシステム。４．各パラメータファイルは、アクセス可能なネットワークアドレスを有し、前記システムは、ダウンロードされたパラメータファイル及び付随するアドレスを格納し、前記第２のコンピュータに格納されたキャッシュ（５３６）をさらに備える、ことを特徴とする請求項１に記載のシステム。５．前記アドレスは、ユニフォーム・リソース・ロケータを備える、ことを特徴とする請求項４に記載のシステム。６．前記第２のコンピュータは、ダウンロード可能なパラメータファイルを示すアイコンを備えたディスプレイウィンドウ（４５２，４６２，４７２，４７４）をさらに備え、前記アイコンにより示されたパラメータファイルは、第３のプログラムモジュールを起動することができ、前記第３のプログラムモジュールは、前記第３のプログラムモジュールを起動した前記アイコンにより示されたパラメータファイルと関連するパラメータファイルをさらにダウンロードする、ことを特徴とする請求項４に記載のシステム。７．前記ダウンロードする手段は、ハイパーテキスト・トランスポート・プロトコルを備える、ことを特徴とする請求項１に記載のシステム。８．前記第１のコンピュータ（４０４−４０６）はサーバであり、前記第２のコンピュータ（４１０−４１２）はクライアントである、ことを特徴とする請求項１に記載のシステム。９．前記第１のパラメータファイルは、第３のコンピュータで作成され、前記第３のコンピュータはクライアントであり、前記システムは、前記第１のパラメータファイルを前記第３のコンピュータから前記第１のコンピュータへとアップロードする手段をさらに備える、ことを特徴とする請求項８に記載のシステム。１０．複数のクライアント（４１０−４１２）とサーバ（４０４−４０６）を接続する通信ネットワークに接続されたコンピュータであって、前記コンピュータは、第１のプログラムモジュールと前記第１のプログラムモジュールに対応付けられた第１のパラメータファイルと、第２のプログラムモジュールと前記第２のプログラムモジュールに対応付けられた第２のパラメータファイルと、を備え、前記第１のプログラムモジュールは、第１のコマンドを前記第２のパラメータファイルへ送信する手段を備え、前記第２のプログラムモジュールは、第２のコマンドを前記第１のパラメータファイルへ送信する手段を備え、前記第１のプログラムモジュールは、実行結果を前記第２のプログラムモジュールへ送信することなく前記第２のコマンドを実行する手段を備え、前記第２のプログラムモジュールは、実行結果を前記第１のプログラムモジュールへ送信することなく前記第１のコマンドを実行する手段を備え、前記第１のパラメータファイルは、前記クライアントと前記サーバとのいずれかに格納されたリモートファイルのアドレスを含み、前記第１のプログラムモジュールは、前記リモートファイルで決定された動作を行う、ことを特徴とするコンピュータ。１１．ハイパーテキスト・トランスポート・プロトコルを用いて、前記クライアント（４１０−４１２）及び前記サーバ（４０４−４０６）と通信する通信手段をさらに備える、ことを特徴とする請求項１０に記載のコンピュータ。１２．前記アドレスは、ユニフォーム・リソース・ロケータである、ことを特徴とする請求項１０に記載のコンピュータ。１３．前記第１及び第２のプログラムモジュールからアクセス可能であり、前記通信手段によって処理されたアドレスを格納する第１のキャッシュ（５３６）をさらに備える、ことを特徴とする請求項１１に記載のコンピュータ。１４．パラメータファイルと結びついたアイコン（８３２，８３４）を表示するブラウザ（５３０）と、前記ブラウザによって処理されたアドレスを格納し、前記ブラウザと結びついている第２のキャッシュ（５３５）と、をさらに備える、ことを特徴とする請求項１３に記載のコンピュータ。１５．それぞれがディスプレイウィンドウ（６０４，６０６，６０８）に対応付けられ、他のプログラムモジュールと通信を行うことができる複数のプログラムモジュールを提供するステップと、前記複数のプログラムモジュールから、第１のディスプレイウィンドウ（６０４）に対応付けられた第１のプログラムモジュールと、第２のディスプレイウィンドウ（６０６）に対応付けられ、前記第１のプログラムモジュールにより自己のオペレーションが制御される第２のプログラムモジュールと、を選択するステップと、前記複数のプログラムモジュールから、第３のディスプレイウィンドウ（６０８）に対応付けられた第３のプログラムモジュールを選択するステップと、前記第３のディスプレイウィンドウと前記第１及び第２のディスプレイウィンドウとの間の位置的関係を定めるステップと、前記第１及び第２のディスプレイウィンドウを、前記第３のディスプレイウィンドウの子ウィンドウに変化させる変化ステップと、を備えることを特徴とするグラフィック・ユーザ・インタフェースベースのアプリケーション設計方法。１６．前記複数のプログラムモジュールから、前記第１、第２、第３のプログラムモジュールの親子関係を示す関係ウィンドウに対応付けられた第４のプログラムモジュールを選択するステップをさらに備える、ことを特徴とする請求項１５に記載のアプリケーション設計方法。１７．前記関係ウインドウは、ユーザがウィンドウ間の関係を変化させる変化手段を備え、前記変化ステップは、前記関係ウィンドウ（６００）を用いて作動する、ことを特徴とする請求項１６に記載のアプリケーション設計方法。１８．前記第１及び第２のディスプレイウィンドウは、ユーザが、前記第１及び第２のディスプレイウィンドウを、それぞれ、子ウィンドウに指定することができる指定手段を備える、ことを特徴とする請求項１５に記載のアプリケーション設計方法。１９．前記指定手段は、アイコン（６１６，６１７）を備える、ことを特徴とする請求項１８に記載のアプリケーション設計方法。２０．前記グラフィック・ユーザ・インタフェースベースのアプリケーションは、マイクロソフトウインドウズに基づいたアプリケーションである、ことを特徴とする請求項１５に記載のアプリケーション設計方法。２１．前記複数のプログラムモジュールは、ディジタルセル技術を用いて設計されたプログラムセルである、ことを特徴とする請求項１５に記載のアプリケーション設計方法。２２．それぞれがディスプレイウィンドウ（６０７−６０９）を備え、他と相互に通信を行うことができる複数のプログラムモジュールを提供するステップと、前記複数のプログラムモジュールから、第１のディスプレイウィンドウと第１のアイコン（６１６，６１７）とに対応付けられた第１のプログラムモジュールを選択するステップと、前記複数のプログラムモジュールから、第２のディスプレイウィンドウ（６０８）に対応付けられた第２のプログラムモジュールを選択するステップと、ユーザによる前記第１のディスプレイウィンドウの前記第１のアイコンのクリックにより、第１のディスプレイウィンドウを子ウィンドウに変化させることを指示するステップと、前記第１のディスプレイウィンドウを前記第２のウィンドウ内に位置させるステップと、前記第１のディスプレイウィンドウを、前記第２のディスプレイウィンドウの子ウィンドウへと変化させるステップと、を備えることを特徴とするグラフィック・ユーザ・インタフェースベースのアプリケーション設計方法。２３．前記グラフィック・ユーザ・インタフェースベースのアプリケーションは、マイクロソフトウィンドウズベースのアプリケーションである、ことを特徴とする請求項２２に記載のアプリケーション設計方法。２４．前記複数のプログラムモジュールは、ディジタル・セル・テクノロジーを用いて作成されたプログラムセルである、ことを特徴とする請求項２２に記載のアプリケーション設計方法。２５．通信を管理するためのオブジェクト指向の所定のクラス（８２６）を配置するステップと、前記所定のクラスとのみ通信し、相互の通信が不可能である、複数のオブジェクト指向プログラミングクラスを配置するステップと、前記複数のクラスのうちの少なくとも第１のクラスにより、前記所定のクラスに最初のメッセージを送信する第１送信ステップと、前記所定のクラスにより、前記第１のメッセージと関連する第２のメッセージを前記複数のクラスの内の少なくとも第２のクラスに送信する第２送信ステップと、を備えることを特徴とするオブジェクト指向のプログラミングクラスの通信管理方法。２６．前記第１及び第２のメッセージは、ＡＳＣＩＩフォーマットに従ってコード化されている、ことを特徴とする請求項２５に記載の通信管理方法。２７．前記第１のメッセージは、送信先のクラスのアドレスと前記送信元のクラスへの指示とを示す情報を含み、前記送信先のクラスは、前記複数のクラスに属している、ことを特徴とする請求項２５に記載の通信管理方法。２８．前記第１のメッセージを送信する前に、前記複数のクラスのうちの第１のクラスから、登録メッセージを前記所定のクラスに送信するステップをさらに含む、ことを特徴とする請求項２５に記載の通信管理方法。２９．前記複数のクラスの前記第１のクラスを終了するとき、前記第１のクラスから終了メッセージを前記所定のクラスに送信するステップをさらに含む、ことを特徴とする請求項２８に記載の通信管理方法。３０．指示及びその送信先のリストを作成するステップをさらに含み、前記送信ステップは、前記第１のメッセージに含まれる指示の送信先を決定するために前記リストをサーチするステップを含む、ことを特徴とする請求項２５に記載の通信管理方法。３１．前記複数のクラスに属するクラスは複数のコンピュータ内に存在し、前記第１及び第２のメッセージの内少なくとも一方はデータネットワークを介して伝達される、ことを特徴とする請求項２５に記載の通信管理方法。３２．通信を管理するオブジェクト指向プログラミングの所定のクラス（８２０）と、各々が前記所定のクラスへのみメッセージを送信することができ、複数のクラスの他のクラスへはメッセージを送信することができない、複数のオブジェクト指向プログラミングクラス（８２２−８２５）と、を備え、前記所定のクラスは、前記複数のクラスの第一のクラスから送信されたメッセージに応答して、第２のメッセージを前記複数のクラスの第二のクラスへと送信する手段を備える、ことを特徴とするオブジェクト指向のプログラミングクラスの通信管理システム。３３．前記第１及び第２のメッセージは、ＡＳＣＩＩフォーマットに従ってコード化されている、ことを特徴とする請求項３２に記載の通信管理システム。３４．前記第１のメッセージは、送信先のクラスのアドレス及び送信先への指示を含み、前記送信先のクラスは、前記複数のクラスに属している、ことを特徴とする請求項３２に記載の通信管理システム。３５．前記所定のクラスは、前記複数のクラスに属するクラスから送信された登録メッセージを受信する手段と、前記複数のクラスに属するクラスの内、起動されているクラスの情報を記憶する手段と、指示とその送信先とのリストを記憶する手段と、前記複数のクラスの内、少なくとも１つのクラスから送信された終了メッセージを受信する手段と、をさらに備える、ことを特徴とする請求項３４に記載の通信管理システム。３６．前記複数のクラスは、複数のコンピュータ内に存在する、ことを特徴とする請求項３２に記載の通信管理システム。３７．テキストベースのファイルに基づいてコンピュータシステムによって生成された文字及び数字を含むテキストイメージのスクロール方法であって、前記コンピュータシステムは、文字に基づいて定められた所定単位で前記テキストイメージをスクロールする手段を含み、前記テキストイメージのスクロール方法は、クライアントエリア（１０５４）を備え、コンピュータのモニタ上に表示される第１のウィンドウ（１０５０）を生成するステップと、前記第１のウィンドウの前記クライアントエリアよりも大きいクライアントエリアを備える第２のウィンドウ（１０６０）を生成するステップと、前記第１のウィンドウの前記クライアントエリアが、前記第２のウィンドウの前記クライアントエリアの中に完全に位置するように、前記第２のウィンドウの前記クライアントエリアの位置を定めるステップと、前記第１のウィンドウの前記クライアントエリアと重なり合っている前記クライアントエリアの部分を除いては、前記第２のウィンドウが前記コンピュータの前記モニタ上に表示されないようにするステップと、前記テキストベースのファイルの第１のテキストイメージ（１００）を、前記第２のウィンドウの前記クライアントエリアに書き込むステップと、前記第２のウィンドウを元の位置から前記ユーザが希望した方向に移動させ、前記テキストイメージの異なる部分を前記コンピュータの前記モニタ上に表示させる移動ステップと、を備える、ことを特徴とするテキストイメージのスクロール方法。３８．前記第２のウィンドウの前記クライアントエリアは、前記第１のウィンドウの前記クライアントエリアよりも垂直方向に少なくとも１文字分大きい、ことを特徴とする請求項３７に記載のテキストイメージのスクロール方法。３９．前記第２のウィンドウの前記クライアントエリアは、前記第１のウィンドウの前記クライアントエリアよりも水平方向に少なくとも１文字分大きい、ことを特徴とする請求項３８に記載のテキストイメージのスクロール方法。４０．前記第２のウィンドウは、前記第１のウィンドウの子ウィンドウである、ことを特徴とする請求項３７に記載のテキストイメージのスクロール方法。４１．前記移動ステップは、前記第２のウィンドウを画素単位で移動させる、ことを特徴とする請求項３７に記載のテキストイメージのスクロール方法。４２．前記第１のテキストイメージが、前記移動ステップにより、前記所定単位だけ移動した後、前記第２のウィンドウを元の位置に戻すステップと、前記第１のテキストイメージと第２のテキストイメージが、前記所定単位だけ異なるように、前記第２のテキストイメージを、前記テキストベースのファイルから前記第２のウィンドウの前記クライアントエリアに描画するステップと、をさらに備えることを特徴とする請求項３７に記載のテキストイメージのスクロール方法。４３．前記第２のウィンドウの前記クライアントエリアは、前記第１のウィンドウの前記クライアントエリアよりも垂直方向に少なくとも１文字分大きい、ことを特徴とする請求項４２に記載のテキストイメージのスクロール方法。４４．前記第２のウィンドウの前記クライアントエリアは、前記第１のウィンドウの前記クライアントエリアよりも水平方向に少なくとも１文字分大きい、ことを特徴とする請求項４３に記載のテキストイメージのスクロール方法。４５．前記第２のウィンドウは、前記第１のウィンドウの子ウィンドウである、ことを特徴とする請求項４２に記載のテキストイメージのスクロール方法。４６．前記移動ステップは、前記第２のウィンドウを画素単位で移動させる、ことを特徴とする請求項４２に記載のテキストイメージのスクロール方法。