【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、1台ないしそれ以上のコンピュータ上で動作するアプリケーション・プログラムを制御する機構に関するものである。 特に、アプリケーション・プログラムの起動，終了，メッセージ配送処理などの制御をおこなうことにより、複数のアプリケーション間の連係を可能にする機構に関するものである。

【０００２】

【従来の技術】近年、パーソナルコンピュータやワークステーション上でウィンドウ・システムを利用したGUI
（グラフィカル・ユーザ・インタフェース）の普及がめざましい。 それに伴いユーザに提供されるべきアプリケーションも、かつてのGUI以前のプログラム環境におけるアプリケーションにくらべ、より複雑かつ多様な機能をより洗練させた形で提供することが要求されるようになってきた。

【０００３】このような要求に対し、単独のアプリケーションの拡張により対応するのではなく、アプリケーション間の協調動作メカニズムの提供により、比較的単純なアプリケーションを複数組み合わせることを可能にし、さまざまな状況に対応しようとするシステムが現れてきている。

【０００４】このような要求に対し、以下のような２つの実現方法が提案され試みられている。 即ち、 （１）アプリケーション連係の要となるアプリケーション・プログラム（これをマスタ・アプリケーションと呼ぶ）が1つ存在し、これが他のアプリケーション（スレーブ・アプリケーションと呼ぶ）をコントロールする方法． （２） 全てのアプリケーションが対等にコミュニケーションを行い、互いに処理を分担し合う方法． である。 ここでは方法（１）をマスタ方式、方法（２）
をコミュニケーション方式と呼ぶことにする。

【０００５】各方式の特徴をまとめると、 ・マスタ方式 … アプリケーションの連係と統合のメカニズムがマスタに集中する。 このためスレーブの作成は容易になるが、その分マスタのプログラムが複雑化する。 また、マスタに負荷が集中しやすい． ・コミュニケーション方式 … 各アプリケーションが連係・統合のメカニズムをそれぞれ持っている。 このため、個々の各アプリケーションが複雑となるが、代わりに負荷の分散がやりやすい。 また、１つのアプリケーションのトラブルが全体に及ぼす影響が小さい。

【０００６】一般に、マスタ方式では、複雑なアプリケーション制御をマスタが集中しておこなうことができるのに対し、コミュニケーション方式ではアプリケーション間のプロトコルを規定しなければ高度な処理を実現することが難しい。 このため、特に同じプログラムが単純なデータ交換のみ行うような場合をのぞき、マスタ方式が採用されることが多い。

【０００７】

【発明が解決しようとする課題】しかしながら、マスタ方式では連係して動作しているアプリケーション群に新しいアプリケーションを追加したり、新たな連係プロトコルを導入しようとすると、マスタ・アプリケーションのプログラム（マスタ・プログラム）の修正が必要となり、全面書き替えを要求されることさえある。

【０００８】またマスタの修正が小規模なものであったとしても、関連するアプリケーションの構成が動的に変化するような環境では、個々のマスタ・プログラムの修正によって対応することは不可能である。 この要求は、
LANやWANなどの発達により複数のコンピュータを作業環境とすることが普及するに従ってより切実なものとなってきている。 このため動的に構成が変化し得る複雑なアプリケーション連係に対応可能な柔軟なアプリケーション連係コントロール機構の実現が要求されるようになってきた。

【０００９】本発明は、上記の問題点に鑑みてなされたものであって、動的に構成要素が変動しうる複雑な環境に対応可能な、柔軟なマスタ・アプリケーションを提供することを可能とする情報処理方法及び装置及びシステムを提供することを目的とする。

【００１０】また、本発明の他の目的は、動的に構成要素が変動しうる複雑な環境を特に意識することなく、その環境で動作するアプリケーションを容易に構築することを可能とする情報処理方法及び装置及びシステムを提供することを目的とする。

【００１１】

【課題を解決するための手段】上記の目的を達成するための本発明の情報処理システムは以下の構成を備えている。 即ち、１台もしくは複数台のコンピュータによって構成される作業環境上でアプリケーション群を連携動作させる情報処理システムであって、前記アプリケーション群の個々のアプリケーション毎に連係動作に関するイベントの処理内容を示すイベント情報群を保持する保持手段と、１つのアプリケーションにおいてイベントが発行されたとき、該イベントに対応する当該アプリケーションのイベント情報を前記保持手段のイベント情報群より検索する検索手段と、前記検索手段で検索されたイベント情報に基づいて前記イベントの処理を実行する実行手段とを備える。

【００１２】また、好ましくは、前記保持手段におけるイベント情報群のイベント構成を変更する変更手段を更に備える。 動的に変化する作業環境やアプリケーション群に柔軟に対応することが可能となるからである。

【００１３】また、好ましくは、前記保持手段における各イベント情報の、イベントの処理内容を変更する変更手段を更に備える。 動的に変化する作業環境やアプリケーション群に柔軟に対応することが可能となるからである。

【００１４】

【作用】上記の構成によれば、あるアプリケーションにおいて、稼働中の作業環境でアプリケーションの連携動作を行うためのイベントが発生すると、前記アプリケーション群の個々のアプリケーション毎に連係動作に関するイベントの処理内容を示すイベント情報群より、該イベントに対応する当該アプリケーションのイベント情報が検索され、検索されたイベント情報に基づいて当該イベントの処理が実行される。

【００１５】

【実施例】以下に添付の図面を参照して本発明の好適な実施例を説明する。

【００１６】＜実施例１＞図１は実施例１による統合アプリケーション管理システムの概要図である。 この統合アプリケーション管理システムは、複数のアプリケーションを連係させあたかも１つのアプリケーションであるかのように振る舞わせる。 本実施例において、この連係して動作する複数のアプリケーションを一括して管理する論理的単位を「統合アプリケーション」とよぶ。 統合アプリケーション管理システムは、この統合アプリケーションを実現するメカニズムを提供する。

【００１７】図１において、ワークステーション１０１
は、本実施例の処理を実行するＣＰＵ１１１と、本統合アプリケーション管理システムの基本ソフトウェアであるDesktopMgr１０２を保持する主記憶１１２を計算機バス１１３で結合して構成されている。

【００１８】DesktopMgr１０２がアプリケーションを管理するために使用するデータをアプリケーション情報１
０３と呼び、DesktopMgr１０２がデータベース１０４を利用して管理している。 このデータベース１０４は、リレーショナル・データベースやオブジェクト指向データベースなどのデータ検索が可能な一般的なデータベースである。 データベース１０４とワークステーション１０
１は、イーサネット・ケーブル１１４で結合されている。 データベース１０４は、統合アプリケーションの動作を規定するスクリプト情報１０５の管理にも使用される。 また、ユーザが入出力などのアプリケーションの操作をおこなうためのユーザインタフェースはディスプレイ１０６上に表示される。

【００１９】DesktopMgr１０２は、内部的に以下の4つのソフトウェア・モジュールから構成されている。 即ち、アプリケーション情報管理モジュール１０７、スクリプト情報管理モジュール１０８、スクリプト実行モジュール１０９及びイベント制御モジュールである。 以下に、各モジュールについて説明する。

【００２０】［アプリケーション情報管理モジュール１
０７］アプリケーション情報管理モジュール（AppServi
ce）１０７は、アプリケーション情報１０３の管理と、
アプリケーションの起動，終了など、アプリケーション情報に基づいたアプリケーション制御の手段を、ユーザやアプリケーションあるいは他のソフトウェア・モジュールに提供する。

【００２１】［スクリプト情報管理モジュール１０８］
スクリプト情報管理モジュール（ScriptService）１０
８は、スクリプト情報１０５ の管理をおこなう。 スクリプト情報１０５は、統合アプリケーションに対しておこなわれた操作（これを統合アプリケーションに対する「出来事」とみなし、これを「イベント」よぶ）に対してDesktopMgrがどのように振る舞うべきかを規定する情報である。 本実施例では、この「振る舞い」は簡単なスクリプト言語によって記述されている。 このスクリプト言語によって記述されたプログラムを単にスクリプトと呼ぶ。

【００２２】［スクリプト実行モジュール１０９］スクリプト実行モジュール（ScriptEngine）１０９はスクリプト情報１０５に記述された処理を実行する。 即ち、スクリプト情報を記述するために使用されるスクリプト言語のインタプリタとして実現されている。

【００２３】［イベント制御モジュール１１０］イベント制御モジュール（EventService）１１０は、ユーザやアプリケーションから送られてきたイベントを受け取り処理するというDesktopMgr１０２全体の動作の制御をおこなう。

【００２４】なお、本実施例では、これらのモジュールはDesktopMgrという1つのプログラムにまとめられているが、各モジュールが独立したプログラムとして機能するという形態の実装も可能である。

【００２５】図２は本実施例におけるアプリケーション連係の様子をあらわす概念図である。 図２において、参照番号２０１から２１０までの各構成は図１における参照番号１０１から１１０までの各構成に対応している。
この図ではアプリケーションＡ２１１，アプリケーションＢ２１２，アプリケーションＣ２１３がDesktopMgr２
０２の管理下にあり、1つの統合アプリケーション２１
４を形成している。 また、アプリケーション２１１，２
１２，２１３のように統合アプリケーションの構成要素となっているアプリケーションを要素アプリケーションと呼ぶ。 本実施例における要素アプリケーションは、従来例におけるマスタ方式およびコミュニケーション方式と同様に、それぞれが連係して動作するためにプロセス間通信機構をもっている。

【００２６】ここで、ユーザ２１５がアプリケーションＡ２１１上で、統合アプリケーション２１４全体で処理されるべき操作をおこなったと仮定する。 本実施例では、この統合アプリケーション２１４全体で処理されるべきユーザの操作をイベントと定義する。 さらに、このようなユーザ操作によって２次的に引き起こされる統合アプリケーション２１４全体で処理されるべき「出来事」もイベントとして扱う。

【００２７】イベントには名前（イベント名）がつけられ、イベント発生時におこなわれる処理を規定するスクリプト情報をアプリケーション情報管理モジュール２０
７に登録することにより、本システムにおけるイベントが定義される。 アプリケーションＡ２１１は、このようなユーザの操作をイベントとしてDesktopMgr２０２に通知する。 このイベント通知メカニズムは、例えばユーザの操作をトリガとして、イベントの名前をあらわす文字列をメッセージとしてDesktopMgr２０２に発行することによって実現できる。

【００２８】ただし、１つの統合アプリケーションに属するすべての要素アプリケーションがこの機構をもっている必要はなく、最低１つがその機構をもっていれば一応統合アプリケーションとして機能する。 この機構をもつ要素アプリケーションは、統合アプリケーションのユーザインタフェースを提供することができるため、UIプロバイダ（UI provider）ともよぶ。

【００２９】さて、DesktopMgr２０２は通知されたイベントに対応するスクリプト情報が存在したならば、そのスクリプト情報を評価・実行する。 多くの場合は、 （１） 他のアプリケーション２１２，２１３やアプリケーションＡ２１１自身にメッセージを送る． （２） 動作中のアプリケーションの終了． （３） 新たなアプリケーションの起動． などの処理が実行され、統合アプリケーション２１４全体の処理として扱われる。

【００３０】図３は、図２におけるDesktopMgr２０２の内部でおこなわれる処理の様子をあらわす図である。 なお、図３における３０１から３１５までの各構成は、図２における２０１から２１５までの項目に対応している。 また、図４は、実施例１における処理の流れを表すフローチャートである。 以下、図３及び図４を参照して本実施例１の処理を説明する。

【００３１】アプリケーションＡ３１１から送られてきたイベント３１６は、EventService３１０によって受け取られる（ステップＳ４０１）。 EventService３１０
は、AppService３０７にイベントの発行元であるアプリケーションＡ３１１のアプリケーション情報３０３の検索を依頼する。 ここで検索のキーとして使用されるアプリケーション名は、送られてきたイベントに必ず付加されているものとする。 AppService３０７はこのイベントに付加されたアプリケーション名をキーとしてデータベース３０４からアプリケーション情報３０３を取り出す（ステップＳ４０２）。

【００３２】ここで、アプリケーション情報３０３は、
本実施例ではＣ++プログラム言語のデータ構造として、 class ApplicationInfo { char* appName; int portNumber; int processNumber; ... ApplicationInfo* integrated_in; ListOf<ApplicationInfo> components; ListOf<char*> eventNames; }; のように定義されている。

【００３３】appNameはアプリケーションの識別子として使用されるアプリケーション名である。 アプリケーション情報３０３内の属性eventNamesでは、そのアプリケーションに関連するイベント名のリストが管理されている。 このイベント名はスクリプト情報検索時のキーとして使用される。 またintegrated_inには、このアプリケーションが統合アプリケーションの１部になっている場合に、その統合アプリケーションのアプリケーション情報への参照子（ポインタ）が登録される。 また、このアプリケーション自身が統合アプリケーションならば、co
mponentsでその構成要素となっているアプリケーションの情報へのポインタが管理される。

【００３４】また、本実施例では、統合アプリケーション自身も対応するアプリケーション情報をもつ。 このようにすることにより、ある統合アプリケーションが別の統合アプリケーションの構成要素となるような状況に対応することができる。 統合アプリケーションを含むアプリケーション情報の生成機構については後述する。 また、その他アプリケーションの制御や通信に必要なプロセス番号processNumberやポートportNumberなどの情報もアプリケーション情報内で管理される。

【００３５】さて、EventService３１０は、次にスクリプト情報管理モジュール３０８に処理対象であるイベント３１６と関連づけられたスクリプト情報３０５の検索を依頼する。 スクリプト情報管理モジュール３０８は、
取り出されたアプリケーション情報３０３と、処理対象であるイベント３１６の名前をキーとしてスクリプト情報３０５を取り出す（ステップＳ４０３）。

【００３６】スクリプト情報自身の定義は、例えばＣ++
プログラム言語により以下のように定義されている:

usterhout, Addison-Wesley, 1994. 参照のこと）。 他のスクリプト言語に同様な拡張をおこなうことにより、

ＴＣＬプログラム言語を置換することも可能である。 このスクリプトをScriptEngine３０９が評価することによりイベントの処理がおこなわれる（ステップＳ４０

４）。

【００３７】本実施例におけるＴＣＬプログラムの拡張コマンド群により、個々の要素アプリケーションが提供する機能を組み合わせることが可能となる。 追加されたコマンド群は以下の３つのカテゴリに分類される。 即ち、 ・アプリケーション情報の操作 ・アプリケーションの操作 ・スクリプト情報の操作 である。 以下、各カテゴリについて詳しく説明する。

【００３８】［アプリケーション情報の操作］アプリケーション情報の参照・更新をおこなう。 以下のコマンドがこのカテゴリに属している。 即ち、 （１） AppInfo "アプリ名" create （２） AppInfo "アプリ名" info "属性名" ?"
属性値"? である。

【００３９】（１）がアプリケーション情報の生成、
（２）はアプリケーション情報の参照および更新である。 属性名はApplicationInfoクラスで宣言されているインスタンス変数の名前をあらわす文字列である。 ここで「？」で両端を囲まれた項目は、指定してもしなくてもよいことをあらわす。 （２）の場合、「属性値」が与えられた場合は「属性名」であらわされるアプリケーション情報の属性の値を更新する。 「属性値」が与えられない場合は参照を意味する。

【００４０】［アプリケーションの操作］アプリケーションの制御をおこなう以下のコマンドがこのカテゴリに属している。 即ち、 （３） launchApp "アプリ名" （４） terminateApp "アプリ名" である。

【００４１】（３）と（４）は、それぞれ指定されたアプリケーションの起動と終了をおこなう。 これらの操作は最終的に本実施例が起動されているオペレーティング・システムの機能を利用しておこなわれるが、そのために必要な情報はアプリケーション情報から取り出される。

【００４２】また、メッセージの配送をおこなうための、 （５） forwardMessage "アプリ名" "メッセージのテキスト" というコマンドもこのカテゴリに属している。 （５）
は、指定されたアプリケーションにメッセージを転送する。 このコマンドにより要素アプリケーションが提供する機能を利用する。 本実施例ではメッセージは文字列として扱われる。

【００４３】［スクリプト情報の操作］イベントに対応するスクリプト情報の参照・更新をおこなう。 コマンドとしては、 （６） ScriptInfo "イベント名" info "属性名" "属性値" がある。 （６）は指定されたイベント対応するスクリプト情報の属性値の参照および更新をおこなうコマンドである。

【００４４】以下に上記のコマンド群を組み合わせアプリケーションの連係を可能にするスクリプトの例を挙げる。

【００４５】［例１］統合アプリケーションIntegWork
の起動をイベントとして定義する。 そのスクリプトは、 set component_tools [AppInfo IntegWork info components]; foreach tool $component_tools { launchApp $tool; } となる。 このスクリプトは、IntegWorkのアプリケーション情報から要素アプリケーションのリストcomponents
の値を取り出し、リスト中の全アプリケーションを起動する。

【００４６】［例２］同じくIntegWorkの終了は、 set component_tools [AppInfo IntegWork info components]; foreach tool $component_tools { terminateApp $tool; } 要素アプリケーションの終了を引き起こす。

【００４７】［例３］IntegWorkに対するdo_something
というイベントを、例えばEditorという要素アプリケーションに処理させるならば、 forwardMessage Editor "do-something"; と記述する。

【００４８】次に図５および図６を用いて、上記のように動作する統合アプリケーションの作成機構について説明する。 図５は、統合アプリケーション作成処理の概要を説明する図である。 図６は、統合アプリケーション作成処理の手順を表すフローチャートである。 図５における参照番号５０１から５１０の各構成は図１における参照番号１０１から１１０までの各構成に対応している。
また、図中のウィンドウ５１１はディスプレイ５０６上でユーザ５１２に、統合アプリケーションの作成のためのユーザインタフェースを提供する。

【００４９】ユーザがウインドウ５１１で作成されるべき統合アプリケーション名を指定すると、EventService
５１０がその要求を受け取り、指定されたアプリケーション名をキーとしてアプリケーション情報管理モジュール５０７に統合アプリケーションのアプリケーション情報５０３の検索を依頼する（ステップＳ６０１）。 このとき、指定したアプリケーション情報５０３が存在しなかったら、新たにアプリケーション情報を生成する（ステップＳ６０２，Ｓ６０３）。

【００５０】アプリケーション情報５０３が得られると、イベント名のリストである属性eventNamesから、関連づけられているイベント名のリストを取り出し、ウィンドウ５１０に表示する（ステップＳ６０４）。 このとき、上述のステップＳ６０３で作成されたばかりのアプリケーション情報なら、表示されるべきイベント名のリストは空である。 イベント名のリストが表示されると、
ユーザによって処理の終了が指示されるまでステップＳ
６０５からステップＳ６１６までの処理が繰り返される。

【００５１】ユーザ５１２は、ウィンドウ５１１を介して、DesktopMgr５０２に新たなイベントの追加・削除を指示することができる。 ユーザによって処理の終了が指示されなかった場合、処理はステップＳ６０５よりステップＳ６０６へ進む。

【００５２】イベントの追加は、追加するイベントのイベント名を与えることにより（ステップＳ６０６）、そのイベント名がアプリケーション情報５０３のeventNam
es属性に属性値として追加され（ステップＳ６０７）、
さらに新たなスクリプト情報５０５が生成される（ステップＳ６０８）。 この時点でのスクリプト情報５０５の
eventName属性とowner属性は指定されているが、script
Text属性の値はNULL文字列である。

【００５３】イベントの削除は、ユーザがイベント名を与えず（ステップＳ６０６）、削除するイベント名をウィンドウ５１１上のリストで選択し（ステップＳ６０
９）、さらにユーザがDesktopMgr５０２に削除を要求する（ステップＳ６１０）ことによって実行される。 この場合、選択されたイベント名に対応するスクリプト情報５０５が取り出されて削除される（ステップＳ６１
１）。 次に、アプリケーション情報５０３のeventNames
からそのイベント名が削除される（ステップＳ６１
２）。

【００５４】また、すでに登録されているイベントに対する処理を変更することも可能である。 即ち、ユーザがウインドウ５１１上でイベント名を指定した時に（ステップＳ６０９）、ユーザが削除要求をおこなわなかった場合（ステップＳ６１０）、対応するスクリプト情報５
０５を取り出し（ステップＳ６１３）、ウインドウ５１
１上に表示する（ステップＳ６１４）。 本実施例では、
scriptText属性に登録されているスクリプトのみ更新が可能である。

【００５５】ここで、ユーザはウインドウ５１１上で表示されたスクリプトの編集をおこなう。 変更がおこなわれた場合（ステップＳ６１５）、変更されたスクリプトはscriptText属性の新しい値となりデータベースにストアされる（ステップＳ６１６）。 変更後、あるいは変更がおこなわれなかった場合（ステップＳ６１５）は、ステップＳ６０５に戻って、操作の継続か処理の終了かを判断し、ユーザからの終了指示がなければ上述の処理を繰り返す。

【００５６】以上の機構を利用すると、アプリケーション情報５０３のeventNames属性に登録されているイベント名リストとスクリプト情報５０５のscriptText属性に登録されているスクリプトを修正することにより、既に作成されていた統合アプリケーションのアプリケーション構成やイベントの数および処理などを変更することや、新たに統合アプリケーションを作成することが可能となる。

【００５７】例えば、図３に示した例に、新たにアプリケーションＡ３１１をアプリケーションＡ'で置き換える場合、統合アプリケーション３１４に対応するアプリケーション情報に登録されているイベント中の、アプリケーションＡ３１１が発行元となるイベントを、アプリケーションＡ'が発行元となるイベントで置き換えればよい。

【００５８】アプリケーションＡ３１１に統合アプリケーション３１４からforwardMessageコマンドによりメッセージを送るようなスクリプトが指定されていた場合も、その部分をアプリケーションＡ'が受け入れられるように変更することにより、アプリケーションＡ'にアプリケーションＡ３１１の代わりに動作させることが可能である。

【００５９】また、図３に示した例に、新たにアプリケーションＤを追加するような場合でも、統合アプリケーション３１４に対応するアプリケーション情報にアプリケーションＤが発行元となるイベントを追加し、既存のイベントに対応するスクリプト情報内のスクリプトを、
アプリケーションＤの追加を考慮して修正することにより、マスタの全面書き替えをおこなうことなくカスタマイズすることが可能である。

【００６０】また、本実施例における統合アプリケーションは１つのユーザ環境内でのアプリケーション連係機構を提供するが、本実施例で説明した統合アプリケーション管理システムをそのまま適用することにより、複数のユーザ環境上で同時に動作する複数のアプリケーションを連係させて、複数のユーザ環境下における協調作業環境を実現することも可能である。

【００６１】以上の様にして本実施例では、統合アプリケーションで処理されるべきイベントを定義することを可能とし、拡張したＴＣＬスクリプト言語を提供して、
スクリプト情報でイベントと関連づけることにより、イベントに対する処理を要素アプリケーションの連係動作として記述することを可能としている。

【００６２】また、アプリケーション情報とスクリプト情報の導入により、統合アプリケーションで処理されるべきイベントの種類とそのイベントに対する処理を任意に変更することを可能にした。

【００６３】このため、DesktopMgrで記述されるスクリプトにより要素アプリケーションがコントロールされるため、個々の要素アプリケーションが統合アプリケーションがどのように構成されているかを意識する必要がなくなるという効果がある。 また、各要素アプリケーションの外部インタフェースの差異を統合アプリケーションのイベント処理によって吸収することも可能となる。

【００６４】さらに、構成が動的に変化する様な統合アプリケーションの実現が可能になり、変更が必要になってもアプリケーション情報とスクリプト情報を修正するだけで対応することができる。

【００６５】＜実施例２＞上記の実施例１において、統合アプリケーション管理システムへの適用例について述べたが、本実施例２では、実施例１で述べたものと同様な統合アプリケーションを実現するマスタ・アプリケーション生成システムについて説明する。

【００６６】このマスタ・アプリケーション生成システムは、統合アプリケーションをコントロールするマスタ・アプリケーションのプログラムを自動生成するプログラムである。 第１の実施例とは異なり、マスタ・アプリケーション生成システム自身は直接アプリケーションの制御をおこなわない。

【００６７】本実施例２が作成するマスタ・アプリケーションは、他のアプリケーションをコントロールする機能だけをもつものであるが、生成されたプログラムを基礎として他の機能を追加することが可能である。

【００６８】図７は本実施例２のマスタ・アプリケーション生成システムの概略図である。 同図において、２次記憶ディスク７０１には、アプリケーション情報７０２
が蓄積されている。 このアプリケーション情報７０２
は、ユーザ７１２がマスタ・アプリケーションを作成するために必要となるアプリケーションの機能に関する情報である。 本実施例２におけるアプリケーション情報７
０２は実施例１におけるアプリケーション情報１０３からポート番号やプロセス番号など動的な情報を取り除き、代りにイベント名をキーとしてそのイベントに対する処理内容と変更履歴等の付加情報を管理するハッシュ・テーブルを付加した物である。 このハッシュ・テーブルをイベント・スクリプト対応表と呼ぶ。

【００６９】マスタ・アプリケーション生成サーバ７０
４は、アプリケーション情報の管理と、それらを組み合わせてマスタ・アプリケーションの生成を支援するユーザインタフェースの提供および、最終結果としてのマスタ・プログラムの作成をおこなう。 マスタ・アプリケーション生成サーバ７０４は２個のソフトウェア・モジュールから構成される。

【００７０】７０５はアプリケーション情報管理モジュールである。 本実施例におけるアプリケーション情報管理モジュール７０５は、データベース１０４の機能を利用していた実施例１におけるアプリケーション情報管理モジュール１０７とは異なり、アプリケーション名をキーとするハッシュ・テーブルの機能を利用して、二次記憶ディスク７０１上のアプリケーション情報７０２の管理をおこなう。 アプリケーション情報７０２自身も前述したように実施例１におけるアプリケーション情報１０
３とは異なる構造を持っている。

【００７１】さらに、このアプリケーション情報管理モジュール７０５は、アプリケーション情報７０２と同様のメカニズムにより、スクリプト・テンプレート情報７
０７をも管理している。 このスクリプト・テンプレート情報７０７はスクリプト・プログラムの骨格の代表的パターンを記述したスケルトン・プログラムである。 ユーザはスケルトン・プログラムを基に実際に実行可能なスクリプトを作成することができる。

【００７２】７１１はプログラム生成モジュールである。 このモジュールは、メイン・ルーチンプログラム７
０９とアプリケーション情報７０２をユーザからの指定に基づいて結合し、マスタ・アプリケーションのプログラムを作成する。 メイン・ルーチンプログラム７０９はアプリケーションからイベントを受け取ると、対応するスクリプトを実行するだけの単純なプログラムである。

【００７３】７１０はユーザインタフェースを提供するウィンドウである。 ここでユーザは、マスタによって統合されるべきアプリケーションの指定、各アプリケーションのイベントに対応するスクリプトの記述および登録などをおこなう。

【００７４】ここで、本実施例におけるアプリケーション情報は以下の様に定義される。 即ち、 class ApplicationInfo { class EventInfo { char* eventName; ApplicationInfo* owner; char* info; char* scriptText; }; char* appName; ... ApplicationInfo* integrated_in; ListOf<ApplicationInfo> components; HashTable<char*, EventInfo> eventHandlers; }; となる。

【００７５】アプリケーション情報における、イベントに対する処理内容と変更履歴等の付加情報は、イベント・スクリプト対応表eventHandlersで管理され、第1の実施例におけるスクリプト情報とほぼ同じ構造を持っている。 本実施例ではイベント処理が少しずつ改良されていくことが重要であるため、変更履歴等の付加情報を記述する項目infoが付加されている。 本実施例では、処理内容と変更履歴等の付加情報をイベント情報とよぶ。

【００７６】本実施例２と実施例１との主な相違は、アプリケーション情報とイベントに関する情報の関連が、
実施例１ではイベント名による緩やかなものであったのに対し、本実施例２ではアプリケーション情報に組み込まれていることである。

【００７７】図８はメイン・ルーチンプログラムの動作概要を説明する図である。 また、図９はメイン・ルーチンプログラムの処理を表すフローチャートである。

【００７８】メイン・ルーチンプログラムにはイベント・スクリプト対応表から取り出されたスクリプト・テキスト８０１とイベント・スクリプト対応表８０２自身が付加される。 アプリケーション情報でイベント・スクリプト対応表８０２内で管理されていたスクリプト・テキストが、メイン・ルーチンプログラムに付加される時に分離される理由は、生成されたマスタ・プログラムを後から変更する場合の便宜を図るためである。 もちろん図に示す様に、イベント・スクリプト対応表８０２とスクリプト・テキスト８０１の対応関係は、イベント・スクリプト対応表がスクリプト・テキスト８０１への参照子８０３を保持していることにより、保存されている。

【００７９】本実施例２におけるスクリプトからこの対応表８０２を参照するには、イベント名を引き数としてとりスクリプトのテキストを返すEventTableという名前の関数として参照する。 イベントループ８０４がイベントを受け取ると（ステップＳ９０１）、イベントに付加されているイベント名をキーとしてイベント・スクリプト対応表８０２から対応するスクリプト・テキスト８０
１を取り出し（ステップＳ９０２）、そのスクリプト・
テキストに制御を移す（ステップＳ９０３）。 メイン・
ルーチンプログラムは基本的にこの動作を繰り返すだけの単純なプログラムである。

【００８０】本実施例２においては、スクリプト言語としてLispプログラム言語を拡張したものを使用するが、
プログラム生成モジュールは最終的にLispスクリプトをＣ言語によるプログラムに変換する（Lispプログラム言語については、 Guy L. Steel Jr. et al., 井田昌之訳, "Common LISP"（共立出版株式会社）を参照）。

【００８１】この変換メカニズムそのものは一般的なプログラム翻訳機構を利用している。 本実施例２における
Lispスクリプトの拡張は以下コマンドの追加によってなされる。 即ち、 （１）（launchApp "アプリ名"） （２）（terminateApp "アプリ名"） （３）（forwardMessage "アプリ名" "メッセージのテキスト"） である。 コマンド（１），（２），（３）の機能は、実施例１における同名のコマンドと同じく、アプリケーションの起動,終了およびメッセージの配送である。

【００８２】本実施例２では、必要な情報をマスタのプログラムに組み込むことができるので、アプリケーション情報などを取得するために特別なコマンドは必要がない。 このため上記のアプリケーションの制御のためのコマンドのみ用意される。 これらの機能は、オペレーティングシステムの基本的な機能として提供されるので、それらの機能をLispから利用するだけでよい。

【００８３】さて、図７と図１０及び図１１を用いてプログラム生成モジュール７１１の動作を説明する。 図１
０及び図１１は、プログラム生成モジュールの処理手順を表すフローチャートである。

【００８４】ユーザがウインドウ７１０で作成されるべき統合アプリケーション名を指定すると、アプリケーション生成サーバ７０４はそのアプリケーション名をキーとしてアプリケーション管理モジュール７０５にアプリケーション情報７０２の検索を依頼する（ステップＳ１
００１）。 アプリケーション情報が存在しなかった場合は（ステップＳ１００２）、新たにアプリケーション情報を生成する（ステップＳ１００３）。

【００８５】アプリケーション情報７０２が得られると、アプリケーション情報７０２のeventHandlersから、イベント・スクリプト対応表が取り出され、ウィンドウ７１０に表示される（ステップＳ１００４）。 イベント名のリストが表示されると、ユーザによって処理の終了が指示されるまで（ステップＳ１００５）、ステップＳ１００６からステップＳ１０１６までの処理が繰り返される。

【００８６】本実施例２においても、実施例１と同様にイベントの追加・削除・更新が可能である。

【００８７】即ち、ユーザによって処理の終了が指示されなかった場合（ステップＳ１００５）、イベントの追加は、追加するイベントのイベント名を与えることにより（ステップＳ１００６）、あらたにイベント情報が生成され（ステップＳ１００７）、イベント・スクリプト対応表に追加される（ステップＳ１００８）。 この時点でのイベント情報のeventName属性とowner属性は指定されているが、scriptText属性とinfo属性の値はNULL文字列である。

【００８８】また、イベントの削除は、イベント名がユーザによって与えられず（ステップＳ１００６）、イベント名がウィンドウ７１０上のリストで選択され（ステップＳ１００９）、さらにユーザがマスタ・アプリケーション作成サーバ７０４に削除を要求することによって実行される（ステップＳ１０１０）。 この場合、選択されたイベント情報がイベント・スクリプト対応表から削除される。 即ち、ステップＳ１０１１において指定されたイベント情報を削除し、ステップＳ１０１２においてアプリケーション情報から選択されたイベント情報を削除する。

【００８９】また、イベント処理の変更に対しては、ユーザがウインドウ７１０上でイベントを指定した時に（ステップＳ１００９）、ユーザが削除要求をおこなわなければ（ステップＳ１０１０）、対応するイベント情報がイベント・スクリプト対応表から取り出され（ステップＳ１０１３）、ウインドウ７１０上に表示される（ステップＳ１０１４）。 本実施例２では、scriptText
属性に登録されているスクリプトとinfo属性に登録されている付加情報のみ更新が可能である。 ユーザはウインドウ７１０上で必要に応じてスクリプトおよび付加情報を編集することによりイベント情報を更新する。

【００９０】イベント情報がウィンドウ７１０上で変更された場合（ステップＳ１０１５）、その変更は２次記憶ディスク７０１上のアプリケーション情報７０３に書き込まれる（ステップＳ１０１６）。 変更後、あるいは変更がおこなわれなかった場合（ステップＳ１０１５）
は、ステップＳ１００５に戻って、操作の継続か処理の終了かを判断し、ユーザからの終了指示がなければ、上述のステップＳ１００６からステップＳ１０１６までの処理を続行する。

【００９１】イベント情報のチェックの終了がユーザにより指示されると（ステップＳ１００５）、プログラム生成モジュール７０８はアプリケーション情報からイベント・スクリプト対応表を取り出し（ステップＳ１０１
７）、さらにイベント・スクリプト対応表からスクリプト・テキストを分離する（ステップＳ１０１８）。

【００９２】次に、メイン・ルーチン・プログラム７０
９とイベント・スクリプト対応表および取り出したスクリプト・テキストをマージしてLispプログラム言語によるマスタ・プログラムを作成する（ステップＳ１０１
９）。 最後に生成されたLispマスタ・プログラムをＣプログラム言語に変換することにより最終的なマスタ・プログラムが生成される（ステップＳ１０２０）。

【００９３】本実施例２では、以上の機構を利用することにより、統合アプリケーションに変更が必要な時も、
変更前のアプリケーション情報を基に適当な変更をアプリケーション情報に加えることにより、変更に対応したバージョンのマスタ・プログラムを生成することが可能となる。

【００９４】また、本実施例２において提供されたマスタ・プログラムによる統合アプリケーションも、実施例１で実現された統合アプリケーションと同様に、複数のユーザ環境上で同時に動作する複数のアプリケーションを連係させて、複数のユーザ環境下における協調作業環境を実現することが可能である。

【００９５】以上の様にして本実施例では、 ・統合アプリケーションにおける、ユーザ間で反映されるべきユーザ操作をイベントとして定義する手段を提供し、 ・拡張したLispプログラム言語を提供してイベント・スクリプト変換テーブル生成手段を導入する ことにより、イベントの処理を各ユーザ環境で動作するアプリケーションの連係動作として記述する手段を提供した。

【００９６】また、アプリケーション情報とスクリプト情報から半自動的にマスタ・プログラムを生成する手段を提供することにより、統合アプリケーションで処理されるべきイベントの構成と、そのイベントに対する処理を変更する手段が提供される。

【００９７】本実施例によれば、共同作業のおける参加者や使用アプリケーションなどの変更によりマスタ・プログラムの変更が必要となった時にも、２次記憶ディスクで管理されているアプリケーション情報を更新することにより、マスタ・プログラムを容易に修正する事が可能となる。

【００９８】また、生成されたマスタ・プログラム自身は対象となるアプリケーション連係に特化した制御をおこなうことができるので、効率的な処理を実現することが可能である。

【００９９】尚、本発明は、複数の機器から構成されるシステムに適用しても１つの機器からなる装置に適用しても良い。 また、本発明はシステム或いは装置に本発明により規定される処理を実行させるプログラムを供給することによって達成される場合にも適用できることはいうまでもない。

【０１００】

【発明の効果】以上説明したように、本発明によれば、
動的に構成要素が変動しうる複雑な環境に対応可能な、
柔軟なマスタ・アプリケーションを提供することが可能となる。

【０１０１】また、動的に構成要素が変動しうる複雑な環境を特に意識することなく、その環境で動作するアプリケーションを構築することが可能になる。

【０１０２】

【図面の簡単な説明】

【図１】実施例１による統合アプリケーション管理システムの概要図である。

【図２】本実施例におけるアプリケーション連係の様子をあらわす概念図である。

【図３】図２におけるDesktopMgrの内部でおこなわれる処理の様子を表す図である。

【図４】実施例１における処理の流れを表すフローチャートである。

【図５】統合アプリケーション作成処理の概要を説明する図である。

【図６】統合アプリケーション作成処理の手順を表すフローチャートである。

【図７】本実施例２のマスタ・アプリケーション生成システムの概略図である。

【図８】メイン・ルーチンプログラムの動作概要を説明する図である。

【図９】メイン・ルーチンプログラムの処理を表すフローチャートである。

【図１０】プログラム生成モジュールの処理手順を表すフローチャートである。

【図１１】プログラム生成モジュールの処理手順を表すフローチャートである。

【符号の説明】

１０１ ワークステーション １０２ DesktopMgr １０３ アプリケーション情報 １０４ データベース １０５ スクリプト情報 １０６ ディスプレイ １０７ アプリケーション情報管理モジュール １０８ スクリプト情報管理モジュール １０９ スクリプト実行モジュール １１０ イベント制御モジュール １１１ ＣＰＵ １１２ 主記憶装置 １１３ 計算機バス １１４ ネットワークケーブル