(57)【要約】【課題】システム構造の可視性を高めてそれらの構築を容易にし、また変更に対しても柔軟に対応できるようにしたイベント駆動型情報処理装置を提供する。【解決手段】システム全体を小さな処理ブロックに分割してイベント処理部１ａ〜１ｈと成し、それら各々の間をイベントを伝達するイベント伝達部５で接続し、イベント伝達部５に方向性を持たせ、イベント処理部１ａ〜１ｈとイベント伝達部５間のインターフェイス部分を共通化し、イベント処理部１ａ〜１ｈ間の接続はイベント伝達部５をつなぎ替えるだけで自由に設定できるようにし、またイベント処理部１ａ〜１ｈは、受け取り側のイベント伝達部は多くても１個、送り側のイベント伝達部は複数持つことを可能に構成して、どの送り側イベント伝達部を使用するかを選択できるようにする。【選択図】図１
2005346332.tif 000002
【特許請求の範囲】
【請求項１】
各種イベントにより処理が実行されるイベント駆動動作部分を少なくとも一部に持ったイベント駆動型情報処理装置において、同期または非同期で入力を受ける入力部と、入力されたデータやイベントに対して処理を行うイベント処理部と、その処理結果を出力する出力部とを纏めて一つのイベント伝達部とし、このイベント処理部を複数個使用し、伝達方向を持たせたデータやイベントを伝達するためのイベント伝達部によって一方の上記イベント処理部の上記出力部と他方の上記イベント処理部の入力部間を接続したことを特徴とするイベント駆動型情報処理装置。
【請求項２】
請求項１に記載のものにおいて、いずれか一つの上記イベント処理部は、一つの上記イベント伝達部を接続した上記入力部と、データやイベントを選択的に送り出すことができると共に複数の上記イベント伝達部を接続可能な上記出力部を有して構成したことを特徴とするイベント駆動型情報処理装置。
【請求項３】
請求項１に記載のものにおいて、上記イベント伝達部は、送信側と受信側のそれぞれに接続した上記一方のイベント処理部のイベントの書き込みまたは読み出しに対して、上記他方のイベント処理部の読み出しまたは書き込みの状態に影響を受けないで読み出しまたは書き込みを行った後、次のプログラム処理へ待ち無しで移行できる待ち無し手段と、他方の読み出しまたは書き込みが行われるまでは待ち状態を保持する待ち有り手段とを有し、上記待ち無し手段および上記待ち有り手段とを選択可能に構成したことを特徴とするイベント駆動型情報処理装置。
【請求項４】
請求項１に記載のものにおいて、上記イベント伝達手段は、複数の上記イベント処理部からのイベントを受け付け、一つに纏めて他の上記イベント処理部へ伝達する機能を有することを特徴とするイベント駆動型情報処理装置。
【請求項５】
請求項１に記載のものにおいて、上記イベント処理部に対してそれぞれイベントを伝達するイベント伝達手段を複数束ね、この束ねられたイベント伝達手段のイベント受信側に任意の上記イベント処理部に対してイベントを伝達する共通の送信先制御部を設けたことを特徴とするイベント駆動型情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、イベント駆動型処理部を有するイベント駆動型情報処理装置に関する。
【背景技術】
【０００２】
従来のイベント駆動型情報処理装置では、システムの複雑化と開発短納期化に伴ってシステム開発の生産性を向上させることが要求されており、イベントを抽象化することによって各処理部の共通化を図る方法（例えば、特許文献１参照）や、イベント駆動の制御機構をアプリケーションプログラムから独立させる方法（例えば、特許文献２参照）等が提案されている。
【０００３】
【特許文献１】特開平７−１５２５６７号公報
【特許文献２】特開平１０−３０１７６４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、従来のイベント駆動型情報処理装置では、システムの複雑化また情報処理技術の急速な進歩により、開発担当者全てのメンバーが必ずしも開発ターゲットであるシステムに使用する全技術を習得しているとは限らず、システム開発者がシステム全体の処理構造を把握することを困難にし、システム機能の変更等が発生したときに、柔軟にしかも素早く対応することを阻んでいる。
【０００５】
そこで本発明の目的は、システム構造の可視性を高めてそれらの構築を容易にし、また変更に対しても柔軟に対応できるようにしたイベント駆動型情報処理装置を提供することにある。
【課題を解決するための手段】
【０００６】
本発明は上記目的を達成するために、各種イベントにより処理が実行されるイベント駆動動作部分を少なくとも一部に持ったイベント駆動型情報処理装置において、同期または非同期で入力を受ける入力部と、入力されたデータやイベントに対して処理を行うイベント処理部と、その処理結果を出力する出力部とを纏めて一つのイベント伝達部とし、このイベント処理部を複数個使用し、伝達方向を持たせたデータやイベントを伝達するためのイベント伝達部によって一方の上記イベント処理部の上記出力部と他方の上記イベント処理部の入力部間を接続したことを特徴とする。
【０００７】
また請求項２に記載の本発明は、請求項１に記載のものにおいて、いずれか一つの上記イベント処理部は、一つの上記イベント伝達部を接続した上記入力部と、データやイベントを選択的に送り出すことができると共に複数の上記イベント伝達部を接続可能な上記出力部を有して構成したことを特徴とする。
【０００８】
さらに請求項３に記載の本発明は、請求項１に記載のものにおいて、上記イベント伝達部は、送信側と受信側のそれぞれに接続した上記一方のイベント処理部のイベントの書き込みまたは読み出しに対して、上記他方のイベント処理部の読み出しまたは書き込みの状態に影響を受けないで読み出しまたは書き込みを行った後、次のプログラム処理へ待ち無しで移行できる待ち無し手段と、他方の読み出しまたは書き込みが行われるまでは待ち状態を保持する待ち有り手段とを有し、上記待ち無し手段および上記待ち有り手段とを選択可能に構成したことを特徴とする。
【０００９】
さらに請求項４に記載の本発明は、請求項１に記載のものにおいて、上記イベント伝達手段は、複数の上記イベント処理部からのイベントを受け付け、一つに纏めて他の上記イベント処理部へ伝達する機能を有することを特徴とする。
【００１０】
さらに請求項５に記載の本発明は、請求項１に記載のものにおいて、上記イベント処理部に対してそれぞれイベントを伝達するイベント伝達手段を複数束ね、この束ねられたイベント伝達手段のイベント受信側に任意の上記イベント処理部に対してイベントを伝達する共通の送信先制御部を設けたことを特徴とする。
【発明の効果】
【００１１】
本発明によるイベント駆動型情報処理装置によれば、イベント駆動型システム内の処理をブロック化すると共に、それらの処理ブロックを自由にしてシステム全体を構成することにより、システム構築を簡単化することが可能であるのと同時に、システム処理構造の可視性を高めることも可能である。また、各処理ブロックが他の処理ブロックとのインタフェース部分を共通的に持つことにより、開発担当者は他の処理との関連を意識することなく担当処理部機能のみの作成に専念することができ、システムの生産性の向上が可能である。
【００１２】
請求項２に記載の本発明によるイベント駆動型情報処理装置によれば、イベント処理部に複数のイベント伝達部を接続可能にしているため、異なるプロセス間のデータやイベントの送信などが容易になり、システム構成の自由度を一層高めることができる。一方で、イベント処理部であるプールへのデータやイベントの入力を一つに絞ることで、入力されたデータやイベントに対しては順次処理を行うことが保証され、個々のイベント処理部であるプールの構造は簡略化され、処理の複雑化を避けることができる。
【００１３】
また請求項３に記載の本発明によるイベント駆動型情報処理装置によれば、待ち無し手段および待ち有り手段とを選択可能に構成したため、同期処理あるいは非同期処理を規定することが容易になる。
【００１４】
さらに請求項４に記載の本発明によるイベント駆動型情報処理装置によれば、複数のイベント処理部からのイベントを一つに纏めて他のイベント処理部へ送信することができ、いろいろな処理結果を纏めるといった機能を実現することで適応範囲を広めることが可能となる。
【００１５】
さらに請求項５に記載の本発明によるイベント駆動型情報処理装置によれば、送信先制御部で受け取った処理結果を読み込み、どのイベント伝達部へ処理結果を送信するかを選択するので、イベント伝達部への送信を動的に変更することができるようになる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施の形態を図面に基づいて説明する。
図１は、本発明の一実施の形態によるイベント駆動型情報処理装置を示すブロック構成図である。
イベント駆動型情報処理装置のシステム全体は複数の小さなイベント処理部１ａ〜１ｈに分割しており、これらの各イベント処理部１ａ〜１ｈは、同期または非同期で入力を受ける入力部２ａ〜２ｈと、入力されたデータやイベントに対して処理を行う処理部３ａ〜３ｈと、その処理結果を出力する出力部４ａ〜４ｈとをそれぞれ有している。これら各々のイベント処理部１ａ〜１ｈを方向性を持ったイベント伝達部５で接続して、全システム機能を実現すると同時に、各イベント処理部１ａ〜１ｈの追加削除あるいは各イベント処理部１ａ〜１ｈの接続をイベント伝達部５をつなぎ替えることで、システム機能の変更や拡張に柔軟に対応できるようにしている。
【００１７】
図２は、上述したイベント駆動型情報処理装置の処理概念を理解し易くするための要部斜視図で、システム機能を構築する上で、データやイベントのフローに着眼し、プログラムのデータフローをあたかも流体の流れのように考え、その流体が各イベント処理部を通り抜ける度に、色を変えたり匂いをつけたりして次第に加工されて希望する流体へと変化するというアナロジーで考え、説明を分かり易くするために、流れ込んだ流体を蓄えて流体を加工するブロック化されたイベント処理部をプール、各プールを連結しているイベント伝達部をチューブと称する。
【００１８】
キーボード１３などからデータやイベントが流体のようにプール６に流れ込むと、プール６で加工された後にチューブ１０によってプール７に流入する。このプール７で流体が加工された後、今度は二本のチューブ１１，１２を通して流体はプール８およびプール９に流入してそれぞれ加工される。その後、プール８からはディスプレ１４などに送られ、プール９からはファイル１５などに送られる構成となっている。
【００１９】
各プール６〜９は、それぞれ上流にあるプールから流体であるデータやイベントが流れ込んで初めて液体の加工処理を行い、この加工処理した流体であるデータやイベントを下流のプールへ流すイベントドリブン型の処理を行う構成である。また各プール６〜９は、一つ一つ独立した機能を有し、その一つ一つが全てシーケンシャルに動作する必要はない。また、流体として示すデータを受け取ったときにのみ動作し、データを受け取らないときにはアイドル状態である。
【００２０】
チューブ１０〜１２は、プールからプールへのデータやイベントの通り道であり、データやイベントは、双方向ではなく必ず一方向へ流れ、最初に流入したデータやイベントから順に流出して順序の保持を行うものである。プール６〜９、例えばプール７は一本の流入チューブ１０からデータやイベントを受け取り、他のプール８，９へデータやイベントを送るときには、複数のチューブ１１，１２に対して同じデータやイベントを、あるいは異なったデータやイベントを送ることが可能である。同じチューブで連結されたプール同士は上述のように同期して動作する必要があるが、お互いに連結のないプールはそれぞれ独立して動作することが可能である。
【００２１】
プール６〜９は、イベント受け取りとイベント送り用のチューブを必ず二種類持つ必要はなく、どちらか一方のチューブに接続されているだけでもよい。このように図１に示したイベント処理部１ａ〜１ｈをプール、イベント伝達部５をチューブと考えることで、自然とデータフローが明らかになり、各イベント処理部を抽出してそれらを接続するという単純な発想で、システムの構築を行うことが可能になる。また、各イベント処理部１ａ〜１ｈ間の接続図を見るだけで、処理構造が把握できるためシステム構造の可視性が向上することができる。
【００２２】
上述したチューブ１０〜１２に伝達の方向性を持たせるために、図３に示すようにチューブ３７内にバッファ数１以上のＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）型のバッファ１６と、このバッファ１６に詳細を後述する書き込み手段１７，１８と、読み出し手段１９，２０を設け、それらを所定のインターフェイス仕様として解放する。これと同時に、図４に示すようにプール４０のデータやイベントを受け取る入力部２にはバッファから読み出し手段を設け、データやイベントを送る出力部４にはバッファへ書き込み手段を設ける。
【００２３】
このようにＦＩＦＯ型のバッファ１６への書き込み手段を持つプールから、ＦＩＦＯ型のバッファ１６からの読み出し手段を持つプールへデータやイベントが流れると、データやイベントのフローの順序や方向が保証され、システム構築の際に考え易くすることができる。ここではＦＩＦＯ型のバッファ１６について説明したが、特殊なケースとしてＦＩＬＯ（Ｆｉｒｓｔ  Ｉｎ  Ｌａｓｔ  Ｏｕｔ）型バッファを採用してもバッファへの書き込み手段を持つプールからバッファからの読み出し手段を持つプールへのデータやイベントの流れを保証することができる。
【００２４】
さらに、図３に示すようにチューブ３７内のバルブ２１ａ，２１ｂを開閉するなどの抽象的な処理手段２２ａ，２２ｂを追加し、図５に示すように異なる方式によるデータ伝達方式であっても、同じインターフェイスを持つイベント伝達部であるチューブを複数種類準備する。この図５は、イベント伝達部の共通処理と独自処理をオブジェクト指向型言語で作成した場合のクラス図である。これを実現し易いのは、オブジェクト指向によって抽象的チューブクラス２３を作成し、その派生として、プロセス間通信に使用するチューブクラス２４、ＴＣＰ／ＩＰ通信を使用するチューブクラス２５等を作成する方法である。この場合、伝送手段が異なっていてもチューブとしての読み出し／書き込みなどのインターフェイス仕様は同じに見えることが重要である。例えば、ＵＤＰ／ＩＰの伝送手段を用いた場合には、後述するように書き込み側が非同期型、読み出し側が同期型の動作チューブとして見える。
【００２５】
このように異なった方式のイベント伝達部であるチューブを持つことで、システム構造の変更に対する柔軟性を増すことができる。例えば、開発当初は、図２に示すように同じマシン内の同じプロセス内で、各プール６〜９をマルチスレッド方式で作成していたものの、後ほどマシンリソースの問題等で、図６に示すように異なるプロセス２６，２７と、異なるマシン２８，２９に各処理を配置し直す必要が生じたとする。通常、このようなシステム構造の変更は、システム全体の処理を見直すことになり、大きな後戻り作業が発生する。
【００２６】
しかしながら、本発明を採用してシステムを構築していた場合、これまでスレッド間を接続するためのチューブの種類を変更するだけでよい。例えば、図６においてチューブ１０を図５に示したプロセス間チューブ２４へ、チューブ１２を図５に示したＴＣＰ／ＩＰ通信チューブ２５へそれぞれ変更すれば、それ以外の修正は発生しない。何故ならば、各プールからは接続したチューブのみが見え、相手先がどこに接続されているかを意識する必要がない。例えば、プール７は、プール８とプール９がどこに存在しているか知る必要がなく、チューブ１１の接続先プールおよびチューブ１２の接続先プールという認識を持っているだけである。従って、プール９を別のマシン上に移行したとしても、プール７にとってはチューブ１２しか意識していないため、プール７内の処理は一切変更する必要がなく、チューブ１２をマシン間接続用のチューブ３０に取り替えるだけである。逆にプール９にとってもプール７は、チューブ１２の接続元としての認識しかないため、内部処理を一切変更する必要がない。プール８が別のプロセスへ変更されたとしても同様である。このように異なる通信方式であっても、同じインターフェイスでを持つチューブを複数種類持つことでシステム構成変更に対して柔軟に対応することができる。またチューブとの接続を行うプールは、図４に示すように入力側に同期型および非同期型の二種類の接続手段を有し、チューブの接続をそのいずれかの種類の接続手段を用いて行うことでプールの動作方法を規定する。
【００２７】
図７は、プールが提供する二種類の接続手段を実現するための処理構造をＰＡＤ図で示したものである。
同図においてプールは、動作を開始したならばステップＳ１で直ちに立ち上がり処理を行い、ステップＳ２の無限プールへ移行する。この無限プールは、外部から終了指示があるまで継続し、終了指示を受け取ったならば無限プールを抜け、ステップＳ３の終了処理を行った後、プールの動作を終了する。無限プール内では、ステップＳ４で流入側チューブの接続種類を調べ、ステップＳ５のデータ待ちを行うか否かを判断する。その後のステップＳ６では流入側チューブよりデータを読み出し、ステップＳ７でデータが存在するか否かの判定を行い、データ有りのときはステップＳ８独自処理を行い、一方、データが存在しなければ、ステップＳ９でデータ無しとときの独自処理を行う。その後、ステップＳ１０で接続された流出チューブが存在するか否かを判定し、流出チューブが存在すれば、一回のプール処理の最後の処理としてステップＳ１１で流出側チューブにデータを書き込む。
【００２８】
同図において、ステップＳ１、ステップＳ３、ステップＳ８およびステップＳ９の部分は各プールの独自な処理を追加する箇所であり、一方、それ以外の部分は全てのプールに実装する箇所である。独自処理を追加し易いのは、オブジェクト指向によって抽象的プールクラスを作成し、その派生としてデータを解析するクラス、データを作成するクラスなどを作成する方法である。このようにチューブとのインターフェイス部分などを共通化することによって各プールの独自処理開発担当者は、自分の担当する処理の作成だけに専念すればよいことになる。
【００２９】
また、図４に示すようにプール４０に、データやイベントの流入側には多くても一本のイベント伝達部である流入側チューブ３１を接続し、一方、データやイベントの流出側には複数のイベント伝達部である流出側チューブ３２，３３を接続し、さらに、イベント処理部であるプール４０内の処理では、マルチスレッドで動作させるなどの共通処理部３４を内部に持つ一方で、伝達するデータやイベントをどのイベント伝達部であるチューブに書き込むかは、独自処理３５内で自由に選択できる処理構造を有するイベント駆動型情報処理装置とする。
【００３０】
このようなイベント駆動型情報処理装置によれば、データやイベントの送出先を複数選べるので、システム構築の自由度を増大化させることができる。一方で、イベント処理部であるプールへのデータやイベントの入力を一つに絞ることで、入力されたデータやイベントに対しては順次処理を行うことが保証され、個々のイベント処理部であるプールの構造は簡略化され、処理の複雑化を避けることができる。すなわち、個々のイベント処理部であるプールは単純な構造とし、それらの接続に柔軟性を持たせることで、複雑化を抑制しつつシステム構造の設計の自由度の確保を実現することができる。
【００３１】
また、図３に示したイベント駆動型情報処理装置は、イベント伝達部であるチューブ３７において、バッファ１６への書き込み手段として、バッファ満杯時の待ち有り書き込み手段１７と、バッファ満杯時の待ち無し書き込み手段１８との二種類を持ち、さらに、バッファ１６からの読み出し手段としても、バッファ空時の読み出し待ち有り読み出し手段１９と、バッファ空時の読み出し待ち無し読み出し手段２０との二種類を有し、接続されるイベント処理部であるプールが、そのいずれかの種類の書き込みおよび読み出し手段１７〜２０を使用するかを選択できる機能を有している。
【００３２】
図８および図９は、イベント伝達部であるチューブが提供する二種類の書き込み手段１７，１８を実現するための処理構造をＰＡＤ図で示したものである。
図８に示したバッファ書き込み待ち無しの場合、動作を開始したならばステップＳ１２でバッファ１６の空きがあるか否かを判定し、その結果、空きがある場合はステップＳ１３でデータあるいはイベントのバイナリー化処理を行い、ステップＳ１４でデータ書き込みを行って動作終了となる。また図９に示したバッファ書き込み待ち有りの場合は、ステップＳ１５でのデータ空き待ち後、ステップＳ１６でデータあるいはイベントのバイナリー化処理を行い、ステップＳ１７でデータ書き込みを行って動作終了となる。
【００３３】
また図１０および図１１は、イベント伝達部であるチューブが提供する二種類の読み出し手段１９，２０を実現するための処理構造を示したＰＡＤ図である。
図１０に示したバッファ読み出し待ち無しの場合、動作を開始したならばステップＳ１８でバッファ１６のデータがあるか否かを判定し、その結果、データがある場合はステップＳ１９でデータを読み出し、ステップＳ２０で読み出したデータの復元化を行って動作終了となる。また図１１に示したバッファ読み出し待ち有りの場合は、ステップＳ２１でのデータ書き込み待ち後、ステップＳ２２でデータの読み出しを行い、ステップＳ２３で読み出したデータの復元化を行って動作終了となる。
【００３４】
上述した図８〜図１１において、ステップＳ１３およびステップＳ１６でのデータのバイナリー化処理、またステップＳ２０およびステップＳ２３での復元化処理は、二つのプロセスにまたがってイベントを伝達するイベント伝達部、つまり図５におけるプロセス間チューブ２４の場合には実装が必要であるが、同一プロセス内で動作するスレッド間チューブ３６の場合には、必ずしも必要ではない。また、図５に示すようにデータの読み出し待ちあるいは書き込み待ちを実現するためにプロセス間チューブ２４を使用する場合には、セマフォ等を使用して実現するが、スレッド間チューブ３６の場合には、ミューテックス排他処理等でも実現することが可能である。すなわち、チューブという概念は、それらの異なる処理方式を内部に隠蔽し、チューブを使用する側からは、同一の仕様と見せるための仕組みである。
【００３５】
上述した図３におけるイベント伝達部であるチューブ３７内のＦＩＦＯ型バッファ１６のバッファ数を１とし、バッファ書き込み手段としてバッファ満杯時の待ち有り書き込み手段１７を使用すると、このイベント伝達部であるチューブ３７の先に接続されたイベント処理部であるプール３８がイベント伝達部であるチューブ３７内のデータやイベントを読み終わるまでは、送り側はデータやイベントを送信できずにそのまま待ち状態となる。すなわち、データやイベントを読み出す側のイベント処理部であるプール３８に対して、イベントを書き込む側のイベント処理部であるプール３９が処理を同期させることになる。
【００３６】
一方、バッファ数を十分に取り、イベントを読み出す側がバッファ空時の待ち有り読み出し手段１９を使用すると、先の説明の例とは逆に、データやイベントを読み出す側のイベント処理部であるプール３８が、データやイベントを書き込む側のイベント処理部であるプール３９の処理に同期させることになる。すなわち、バッファ１６の満杯あるいは空の振る舞いが異なる書き込み手段あるいは読み出し手段を選択することで、システム設計者は、同期処理あるいは非同期処理を規定することが可能となる。また伝送方式によれば、前述のセマフォなどを用いなくてもチューブを同期あるいは非同期の動作を行わせることが可能である。例えば、伝送方式にＵＤＰ／ＩＰ通信を用いれば、書き込み側は非同期方式、読み出し側は同期方式となる。一方、ＴＣＰ／ＩＰ通信を用いれば書き込み側が非同期方式、読み出し側が同期方式のチューブが二本、お互いに反対方向に送信用、受信用として一対生成されると考えられる。
【００３７】
また、図３に示したイベント駆動型情報処理装置として、一本のイベント伝達部であるチューブ３７のデータ書き込み手段１７，１８を、図４に示した複数のイベント処理部であるプール４０のデータ流出側に接続可能に構成すると、いろいろな処理結果を纏めるといった機能を実現することで適応範囲を広めることが可能となる。
【００３８】
以上説明したイベント駆動型情報処理装置によれば、イベント駆動型システム内の処理をブロック化すると同時に、それらの処理ブロックを自由にしてシステム全体を構成することにより、システム構築を簡単化することが可能であるのと同時に、システム処理構造の可視性を高めることも可能である。また、各処理ブロックが他の処理ブロックとのインタフェース部分を共通的に持つことにより、開発担当者は他の処理との関連を意識することなく担当処理部機能のみの作成に専念することができ、システムの生産性の向上が可能である。さらに、処理ブロックの独自処理部分を変更するだけで、システムの構成変更に対して柔軟に対応することが可能となる。
【００３９】
図１２は、本発明の他の実施の形態によるイベント駆動型情報処理装置のプール配置例を示す斜視図である。
このイベント駆動型情報処理装置では、図１２に示すように複数のイベント伝達部であるチューブ４１ａ，４１ｂ，４１ｃを束としてあたかも一つのイベント伝達部であるチューブ４１であるかのように扱い、その束ねられたイベント伝達部であるチューブ４１のイベント受付を複数のイベント処理部であるプール４０ａ，４０ｂ，４０ｃが共有し、各プール４０ａ，４０ｂ，４０ｃから複数本のうちのどのイベント伝達部であるチューブに流出するかは各プール４０ａ，４０ｂ，４０ｃ内の処理によって選択するように構成している。このような構成のイベント駆動型情報処理装置によれば、各イベント処理部であるプール４０ａ，４０ｂ，４０ｃは、どのイベント伝達部であるチューブ４１ａ，４１ｂ，４１ｃにデータを流すかを選択することができるため、イベント処理部であるプール４０ａ，４０ｂ，４０ｃは送り先のイベント処理部であるプールを意識せずにどのイベント伝達部であるチューブ４１ａ，４１ｂ，４１ｃを使用するかだけを意識すればよい。また、イベント伝達部であるチューブおよびその束を用いることにより、イベント処理部であるプール４０ａ，４０ｂ，４０ｃの接続を自由に配置できシステムの構築が容易となる。
【００４０】
図１３は、上述したイベント駆動型情報処理装置を適用した設備管理装置の概略構成図である。
設備管理装置４２は、２台のＰＣ４３ａ，４３ｂと、１台のプリンタ４４とで構成し、それぞれＴＣＰ／ＩＰ４５によってネットワーク４６に接続している。また、所内設備４７、ゲート設備４８、取水設備４９等の他の装置も同じネットワーク４６に接続している。設備管理装置４２は、ネットワーク４６上のシーケンサー（ＳＱＣ）５０を経由して所内設備４７やゲート設備４８からの機器情報を取得し、それらの結果を集計および編集し、故障状態、機器状態変化、操作状況等を表示画面５１に表示すると同時に、電力日報、電力月報、ゲート操作記録等を作成してプリンタ４４で印刷する機能を有しており、基本的には、各機器からのイベントと、表示画面５１からのオペレータ操作イベントとにより動作するイベント駆動型システムである。
【００４１】
図１４は、上述した設備管理装置４２の開発当初の機能図である。
同図に示すように、基本的な処理を４つのイベント処理部５２〜５５に分割し、各イベント処理部５２〜５５をそれぞれイベント伝達部５６〜５８を用いて接続した構造のシステムを構築している。これら４つのイベント処理部５２〜５５とは、ビット列で送られてきた情報を各機器に対応させて意味のある情報に置き替える通信データ翻訳機能を担当する通信データ翻訳処理部５２と、前回値からの差分により履歴等を解析するデータ解析処理部５３と、データ解析から送られてきた情報から重大性を区分して画面レイアウトを作成し画面に表示する表示データ作成処理部５４と、印刷用のフォーマットを生成および集計する印刷データ作成処理部５５とである。これら４つの処理部をすでに説明したイベント処理部すなわちプールクラスの派生として作成している。
【００４２】
また、これら４つのイベント処理部５２〜５５のうち、通信データ翻訳処理部５２とデータ解析処理部５３とをイベント伝達部５６で接続し、データ解析処理部５３と表示データ作成処理部５４とをイベント伝達部５７で接続し、またデータ解析処理部５３と印刷データ作成処理部５５とをイベント伝達部５８で接続している。これら３つのイベント伝達部５６〜５８は、すでに説明したイベント伝達部であるチューブクラスの派生として作成している。このうち、同一プロセス５９内に配置された通信データ翻訳処理部５２とデータ解析処理部５３を接続したイベント伝達部５６と、データ解析処理部５３と表示データ作成処理部５４を接続したイベント伝達部５７には、図５に示したスレッド間チューブ３６を使用し、異なるプロセス６０内に配置されたデータ解析処理部５３と印刷データ作成処理部５５のイベント伝達部５８には、図５に示したプロセス間チューブ２４を使用している。全てのイベント処理部５２〜５５は、これら３つのイベント伝達部５６〜５８の何れも、すでに説明したデータ書き込み待ち無し関数、データ読み出し待ち有り関数を使用し、全てのイベント伝達部５６〜５８は、４つのイベント処理部５２〜５５の何れも同期型で接続している。
【００４３】
図１５は、上述したシステムを製造したときの工程図である。
まず、イベント処理部とイベント伝達部の基本クラスを作成し、メイン処理に組み込む。これにより、メインルーチン（全体統括部）と各機能の結合部分（インターフェイス部分）の動作が保証される。メイン処理をリリースした後に、各イベント処理部の独自な処理を作成して行く。このとき、すでに作成している基本クラスにて他の処理との関連がある処理（インターフェイス部分等）は作成済みなので、他の処理との関連が分からない開発担当者でも、独自処理作成に必要な技術だけを習得していれば、イベント処理部の独自処理を作成することができ、さらに、各イベント処理部の独自処理を並行して作成することができるため、生産性を向上させることができる。また、すでにシステムのメイン構成は決定しているため、処理担当者が異なることによりしばしば発生する各処理間のインターフェイスの食い違いによる後戻り作業を避けることもできる。
【００４４】
さらに、システムの変更に対して柔軟に対応することができる。つまり、開発当初は、一つのプロセス５９内に通信データ翻訳処理部５２、データ解析処理部５３、表示データ作成処理部５４を配置し、さらに別プロセス６０内に印刷データ作成処理部５５を配置していたが、データ表示は不要なときにはストップさせたいという顧客からの要求により、図１６に示すように表示データ作成処理部５４を新たに別なプロセス６１上に配置することにした。このとき、従来技術でシステムを構築していた場合には、別のプロセス６１に分けるインターフェイス部分を中心に、他の関連する処理にまで変更が発生する可能性がある。しかし、本発明を適用して構築したシステムでは、データ解析処理部５３と表示データ作成処理部５４を接続しているイベント伝達部５７を、図５に示したスレッド間チューブ３６からプロセス間チューブ２４に変更するだけで、データ解析処理部５３、表示データ作成処理部５４等の他の処理には一切変更は発生しない。
【００４５】
図１７は、本発明の他の実施の形態によるイベント駆動型情報処理装置を適用したクライアント・サーバシステムを示すブロック構成図である。
クライアント・サーバシステムは、一台のサーバ６２と複数台のＰＣで構成され、それぞれはＴＣＰ／ＩＰによってネットワークで接続されている場合を考える。サーバ６２とクライアント６３，６４間のデータ送受信処理は、クライアントからの要求により動作するイベント駆動型システムである。基本的な処理をイベント処理部６５〜６９に分割し、各処理部をそれぞれイベント伝達部７５〜８１を用いて接続した場合を例示している。
【００４６】
各イベント処理部としては、クライアント６３，６４からサーバ６２へデータを送信するクライアント送信部７０と、サーバ６２からクライアント６３，６４へのデータを受信するクライアント受信部７１と、クライアント６３，６４からデータを受信しサーバ個別処理６５へデータを送信するサーバ受信部７２と、サーバ個別処理６５からデータを受信し送信先を選択してデータを送信する送信先制御部７３と、この送信先制御部７３からデータを受信しクライアント６３，６４へデータを送信するサーバ送信部７４とを有しており、これらのイベント処理部６５〜６９をプールクラスの派生として作成する。
【００４７】
これらのイベント処理部６５〜６９を接続するイベント伝達部としては、クライアント個別処理６８とクライアント送信部７０を接続するイベント伝達部７５と、クライアント送信部７０とサーバ受信部７２を接続するイベント伝達部７６と、サーバ受信部７２とサーバ個別処理６５を接続するイベント伝達部７７と、サーバ個別処理６５と送信先側御部７３を接続するイベント伝達部７８と、送信先制御部７３とサーバ送信部７４を接続するイベント伝達部７９と、サーバ送信部７４とクライアント受信部７１を接続するイベント伝達部８０と、クライアント受信部７１とクライアント個別処理６８を接続するイベント伝達部８１とを有しており、これらの各イベント伝達部をチューブクラスの派生として作成する。このうち、クライアント送信部７０とサーバ受信部７２を接続するイベント伝達部７６と、サーバ送信部７４とクライアント受信部７１を接続するイベント伝達部８０は、異なるネットワークに配置されており、図５に示したＴＣＰ／ＩＰ通信によるマシン間チューブ２５を使用し、その他のイベント伝達部は同一プロセス内に配置されているので、図５に示したスレッド間チューブ３６を便用する。全てのイベント処理部６５〜６９は、これら各イベント伝達部７５〜８１は、何れもすでに説明したデータ書き込み待ち無し関数、データ読み出し待ち有り関数を使用し、各イベント処理郡６５〜６９の何れとも同期型で接続している。
【００４８】
次に、上述したクライアント・サーバシステムの処理動作について説明する。
先ず、クライアント６３が起動されると、クライアント送信部７０がサーバ６２の受付処理８２に回線オープン（図３でのバルブオープン）を要求し、受付処理８２がクライアント担当処理６６を生成する。クライアント担当処理６６にはサーバ受信部７２とサーバ送信部７４が含まれており、クライアント６３とサーバ６２間のデータの送受信は、クライアント送信部７０とサーバ受信部７２間、サーバ送信部７４とクライアント受信部７１間で実行される。このため、クライアント担当処理６６が正常に生成されると、クライアント６３とサーバ６２間の通信が確立される。クライアント担当処理６６の生成の際、サーバ受信部７２とサーバ個別処理６５間のイベント伝達部７７であるチューブを、他のクライアント担当処理６７のサーバ受信部７２のチューブと一つに纏めると同時に、送信先制御部７３のチューブ束に、送信先制御部７３とサーバ送信部７４間のイベント伝達部７９であるチューブを追加し、送信先制御部７３がどのチューブにデータを送信するかを選択することができるようにする。
【００４９】
通信確立後、クライアント送信部７０がクライアント個別処理６８から送られてきたイベントデータをサーバ受信部７２へ送信し、これを受信したサーバ受信部７２がサーバ個別処理６５へイベントデータを送信する。サーバ個別処理６５からイベントデータを受信したサーバ個別処理６５はイベントデータに対応した処理を実行し、その処理結果を送信先制御部７３へ送信する。送信先制御部７３は、サーバ個別処理６５から受け取った処理結果を読み込み、どのイベント伝達部であるチューブへ処理結果を入れるか、つまりどのクライアントへ処理結果を送信するかを選択する。その後、送信先制御部７３からサーバ送信部７４が処理結果を受信すると、通信が確立されているクライアント受信部７１へ送信し、これを受信したクライアント受信部７１がクライアント個別処理６８へ処理結果を送信する。
【００５０】
このようなクライアント・サーバシステムによれば、クライアント起動後、回線オープンの要求が来てからクライアント担当処理６６，６７を生成することができ、生成されたクライアント担当処理６６，６７がサーバ個別処理６５へのチューブの接続と、送信先制御部７３へのチューブの接続を動的に変更することができる。
【産業上の利用可能性】
【００５１】
本発明は上述した実施の形態に限定されず、他のイベント駆動型情報処理装置に適用することができる。
【図面の簡単な説明】
【００５２】
【図１】本発明の一実施の形態によるイベント駆動型情報処理装置のブロック構成図である。
【図２】図１に示したイベント駆動型情報処理装置におけるシステムアーキテクチャの基本的構想の処理アナロジー図である。
【図３】図１に示したイベント駆動型情報処理装置におけるチューブの内部構造図である。
【図４】図１に示したイベント駆動型情報処理装置におけるプールの内部構造図である。
【図５】図１に示したイベント駆動型情報処理装置におけるオブジェクト指向型言語を使用した場合のチューブのクラス図である。
【図６】図１に示したイベント駆動型情報処理装置における汎用化したプールとチューブの接続例を示す説明図である。
【図７】図１に示したイベント駆動型情報処理装置におけるチューブ内部のバッファ書き込み関数のＰＡＤ図である。
【図８】図１に示したイベント駆動型情報処理装置におけるチューブ内部のバッファ読み出し関数のＰＡＤ図である。
【図９】図１に示したイベント駆動型情報処理装置におけるチューブ内部の他のバッファ読み出し関数のＰＡＤ図である。
【図１０】図１に示したイベント駆動型情報処理装置におけるプール内部のバッファ読み出し関数のＰＡＤ図である。
【図１１】図１に示したイベント駆動型情報処理装置におけるプール内部の他のバッファ読み出し関数のＰＡＤ図である。
【図１２】本発明の他の実施の形態によるイベント駆動型情報処理装置におけるチューブによって接続されたプールの配置例を示す斜視図である。
【図１３】本発明のさらに他の実施の形態によるイベント駆動型情報処理装置を適用した設備管理装置の構成図である。
【図１４】図１３に示したイベント駆動型情報処理装置における設備管理装置の開発当初の機能図である。
【図１５】図１３に示したイベント駆動型情報処理装置における設備管理装置のシステム製造工程図である。
【図１６】図１３に示したイベント駆動型情報処理装置における設備管理装置のシステム構成変更後の機能図である。
【図１７】本発明のさらに他の実施の形態によるイベント駆動型情報処理装置を適用したクライアント・サーバシステムを示すブロック構成図である。
【符号の説明】
【００５３】
１ａ〜１ｈ  イベント処理部
２ａ〜２ｈ  入力部
３ａ〜３ｈ  処理部
４ａ〜４ｈ  出力部
５  イベント伝達部
【図１】
2005346332.tif 000003
【図２】
2005346332.tif 000004
【図３】
2005346332.tif 000005
【図４】
2005346332.tif 000006
【図５】
2005346332.tif 000007
【図６】
2005346332.tif 000008
【図７】
2005346332.tif 000009
【図８】
2005346332.tif 000010
【図９】
2005346332.tif 000011
【図１０】
2005346332.tif 000012
【図１１】
2005346332.tif 000013
【図１２】
2005346332.tif 000014
【図１３】
2005346332.tif 000015
【図１４】
2005346332.tif 000016
【図１５】
2005346332.tif 000017
【図１６】
2005346332.tif 000018
【図１７】
2005346332.tif 000019