JP2007213233A - 複数のアプリケーションの参照関係を管理する管理システム - Google Patents

Abstract

【課題】複数のアプリケーションの連携を考慮したシステム開発において、開発者の負荷を軽減し、保守管理を容易にする。
【解決手段】複数のアプリケーションの参照関係を管理する管理システム１００は、参照先のアプリケーション名が対応づけられている参照関係テーブル１０３、１０４を記憶するための記憶手段１０８と、複数のアプリケーション１０１、１０２を実行するためのシステム制御部１０５と、を備える。システム制御部１０５は、複数のアプリケーション１０１、１０２のそれぞれの参照関係テーブル１０３、１０４を取得し、これらに基づいて全アプリケーション被参照関係テーブル４０３を作成し、実行するアプリケーションのアプリケーション名に基づいて全アプリケーション被参照関係テーブル４０３を検索して対応する参照元のアプリケーションを抽出し、抽出された前記参照元のアプリケーションの実行必要性フラグをイネーブルにする。
【選択図】図１

Description

本発明は、複数のアプリケーションの参照関係を管理する管理システムに関する。

従来、ソフトウェア開発においてはオブジェクト指向を用いたプログラミング（C++、JAVA（登録商標）等を用いたプログラミング）によりソフトウェアを機能毎に部品化をし、それらを組み合わせて開発する事が主流になってきている。このようにソフトウェアを機能毎に部品化することにより、一部を修正した場合に、ソフトウェア全体を再度コンパイルすることなく、修正した箇所のみを再度コンパイルすればよいというメリットがある。また、ソフトウェアの一部分をバージョンアップする場合、その部分のみを交換するだけでよく、保守の面で非常に優れている。

しかしながら、ソフトウェアが部品化されたことにより、そのソフトウェアを効率よく利用するためには、各プログラム間の相互連携や情報共有の手法をソフトウェアが判断する事が必須となった。その手法としてアプリケーション間の関係をテーブルデータとしてもつ方法が提案されている。

特許文献１は、クラスごとに参照先のアプリケーションプログラムを定めた定義テーブルを利用する技術を開示している。特許文献１では、定義テーブルを用いることによって、アプリケーションプログラムを起動させたときに、このアプリケーションプログラムのユーザーインターフェース上で他のアプリケーションを直接起動させることができる。
特開２００４−１０２４５３号公報

しかしながら、特許文献１では、各アプリケーションプログラムがどのアプリケーションプログラムを参照先としているかは分からない。そのため、ユーザは、アプリケーションプログラムを修正・追加等する必要がある場合には、各アプリケーションプログラムの参照関係を全て把握しなければならず、システム開発や保守に過大な負荷がかかっていた。そこで、複数のアプリケーションの連携を考慮したシステム開発において、開発者の負荷が少なく、保守管理が容易なシステムが望まれていた。

本発明は、上記の問題点に鑑みてなされたものであり、開発者の開発・保守の負荷を軽減することができるシステムを提供することを目的とする。

本発明は、複数のアプリケーションの参照関係を管理する管理システムに係り、複数のアプリケーションのそれぞれのアプリケーション名に対してその参照先のアプリケーション名が対応づけられている参照関係テーブルを記憶するための記憶手段と、前記複数のアプリケーションを実行するためのシステム制御部と、を備え、前記システム制御部は、前記記憶手段から前記複数のアプリケーションのそれぞれの前記参照関係テーブルを取得し、取得した前記参照関係テーブルに基づいて前記複数のアプリケーションのそれぞれのアプリケーション名とその参照元のアプリケーション名とが対応づけられている全アプリケーション被参照関係テーブルを作成し、実行するアプリケーションのアプリケーション名に基づいて前記全アプリケーション被参照関係テーブルを検索して対応する参照元のアプリケーションを抽出し、抽出された前記参照元のアプリケーションの実行必要性フラグをイネーブルにする手段を有することを特徴とする管理システム。

本発明によれば、開発者の開発・保守の負荷を軽減することができるシステムを提供することができる。

以下に、本発明の好適な実施の形態に係る管理システムについて添付の図面に基づいて詳細に説明する。

［第１の実施形態］
図１は、本発明の好適な実施の形態に係る管理システム及びそのハードウェアの構成を示す図である。図１（ａ）は、本発明の好適な実施の形態に係る管理システムの構成を示し、図１（ｂ）は、この管理システムを実現するためのハードウェアの構成を示す。各アプリケーション１０１、１０２は、そのアプリケーション名とデータを更新する際に参照する参照先のアプリケーション名とが対応づけられたアプリケーション参照関係テーブル１０３、１０４をそれぞれ有する。アプリケーションが参照関係にある場合には、あるアプリ−ションは他のアプリケーションのデータを使って自身のデータを作成する。各アプリケーション１０１、１０２は、記憶手段１０８に記憶される。システム制御部１０５は、ユーザからの入出力を受け取る入出力インターフェース部１０７と全アプリケーション参照関係テーブル４０２を制御することができる。また、システム制御部１０５は、アプリケーション１０１、１０２の実行やその必要性の制御、アプリケーション１０１、１０２からのデータ更新通知受信を行うことができる。また、システム制御部１０５は、アプリケーション参照関係テーブル１０３、１０４を各アプリケーション１０１、１０２から受信し、全アプリケーション参照関係テーブル４０２を作成し、参照関係にあるアプリケーションを検索する機能を有する。記憶手段１０８は、例えば、２次記憶装置１１６の記憶領域に割り当てることが好ましいが、他の記憶手段に割り当ててもよい。記憶手段１０６は、例えば、主記憶装置１１５の記憶領域に割り当てることが好ましいが、他の記憶手段に割り当ててもよい。

各アプリケーションは、アプリケーション参照関係テーブルを例えば図２（ａ）に示すような配列データ２０１として持つことができる。配列データ２０１の中には、自分自身の実行に必要な直接参照するアプリケーション名が登録されている。図２（ｂ）は、これを模式的に表した図である。図２（ｂ）を例に挙げると、アプリケーション「２」は、アプリケーション「１」とアプリケーション「３」を参照先としていることが分かる。したがって、図２（ａ）は、“application１”と“application３”のデータを使って“application２”のデータの更新を行うことを意味する。

図３は、ソフトウェアがコンピュータ上で起動された時の処理の流れをUML２.０シーケンスで示す図である。ユーザによってソフトウェアが起動されたとき（図３−１）、システム制御部１０５は、２次記憶装置１１６内に記憶されたアプリケーション１０１、１０２を主記憶装置１１５内にロードする（図３−２）。ロードされたアプリケーション１０１、１０２は、それぞれ自身がもつアプリケーション参照関係テーブル１０３、１０４をシステム制御部１０５に送信する（図３−２）。システム制御部１０５は、全てのアプリケーションのロード及びテーブル１０３、１０４の送信が終了すると、ロードしたアプリケーション１０１、１０２の全ての参照関係を記した全アプリケーション参照関係テーブル４０２を構築する（図３−４）。

システム制御部１０５は、アプリケーション参照関係テーブルを構築する際、図４に示すように２種類のテーブルを構築することができる。一つは、各アプリケーションから渡されたアプリケーション参照関係テーブル情報４０１を一つにまとめた全アプリケーション参照関係テーブル４０２である。もう一つは、各アプリケーションから渡されたアプリケーション参照関係テーブル情報４０１より構築したアプリケーション被参照関係テーブル４０３である。

アプリケーション被参照関係テーブル４０３とは、あるアプリケーションがどのアプリケーションから参照されているかを示すテーブルである。図４を参照してアプリケーション被参照関係テーブル４０３を説明する。アプリケーション参照関係テーブル情報４０１において、アプリケーション「１」はアプリケーション「２」、「３」から参照されている。従って、アプリケーション「１」は、全アプリケーション被参照関係テーブル４０３では、アプリケーション「２」、「３」をテーブルとして持つ。以上の二種類のテーブルは、システム制御部１０５がソフトウェアを起動する時に構築されることが望ましい。

図５は、図４のアプリケーション参照関係テーブル情報４０１の全アプリケーションの参照関係をTree構造で表した図である。図５よりシステム制御部１０５ではアプリケーション「４」が直接参照するアプリケーションは「３」であるが、「３」は「１」を参照しているため、「４」のデータを更新するためには「１」、「３」を更新する必要があることが分かる。なお、参照先のアプリケーションには、直接参照するアプリケーションだけではなく、他のアプリケーションを介して間接的に参照するアプリケーションも含まれる。したがって、例えば図４の場合では、アプリケーション「４」の参照先のアプリケーションには、アプリケーション「１」及びアプリケーション「３」が含まれる。

図６は、システム制御部１０５がアプリケーションの参照関係を検索するときの流れをアプリケーション「４」の参照関係を検索する場合を例として示す図である。まず、アプリケーション「４」が直接参照するアプリケーションを調べ、その結果アプリケーション「３」が検索にヒットするので、更に検索を行い、アプリケーション「３」が直接参照しているアプリケーションを検索する。その結果、アプリケーション「３」において「１」が検索にヒットするので、更に検索を行い、アプリケーション「１」は参照するアプリケーションがないので、この時点で検索が終了する。このように再帰的に検索する事により間接的に参照するアプリケーションを調べる事が出来る。その結果アプリケーション「４」の直接的及び間接的に参照するアプリケーションは「１」、「３」となる。

ユーザがアプリケーションを実行するときのパターンとしては、参照される側のアプリケーションが実行される場合と参照する側のアプリケーションが実行される場合の二通りがある。

図７は、ユーザがソフトウェア上で参照される側のアプリケーションを実行したときのフローをUML２.０シーケンスで示す図である。図７では、アプリケーション「１」を実行したときを例示的に示す。ここで、アプリケーション「１」は、図５に示すようにアプリケーション「２」、「３」、「４」から直接的又は間接的に参照されている場合を例に挙げる。

ユーザがアプリケーション「１」を実行するときは、まずユーザーインターフェース（ウィンドウ、コマンド入力）を介してシステム制御部１０５にアプリケーション「１」の実行命令を送信する（図７−１）。システム制御部１０５は、アプリケーション「１」に対して実行命令を出す（図７−２）。アプリケーション「１」は処理終了後、データ変更の通知をシステム制御部１０５に送信する（図７−３）。システム制御部１０５はデータ更新通知が送られたら全アプリケーション被参照関係テーブル４０３から、実行命令のあったアプリケーション「１」と参照関係にあるアプリケーションを検索する（図７−４）。そして検索されたアプリケーション「２」、「３」、「４」の実行必要性フラグをTRUE（イネーブル）に変更する（図７−５）。図８に示すように、アプリケーション「１」実行後の各アプリケーションの実行必要性フラグは、アプリケーション「１」の実行が完了しているのでFALSE（ディセーブル）となっており、「２」、「３」、「４」のフラグは未実行のためTRUEとなっている。

図９は、ユーザが参照する側のアプリケーションを実行した場合のフローをUML２.０シーケンスを示す図である。図９ではアプリケーション「１」の実行完了後にアプリケーション「４」を実行した場合を例に挙げる。ユーザはアプリケーション「４」の実行命令をシステム制御部１０５に送信する（図９−１）。システム制御部１０５はアプリケーション「４」が参照するアプリケーションを全アプリケーション参照関係テーブル４０２から検索する（図９−２）。アプリケーション「４」の場合は図５よりアプリケーション「１」、「３」が検索される。次にシステム制御部１０５はアプリケーション「１」、「３」の実行必要性フラグを確認する（図９−３）。この場合は図８よりアプリケーション「３」がTRUEになっているので、システム制御部１０５はアプリケーション「４」を実行する前にアプリケーション「３」を実行する必要があると判断する。システム制御部１０５は、アプリケーション「１」の実行必要性フラグがFALSEなので、アプリケーション「４」と参照関係にはあるが、実行の必要はないと判断し、アプリケーション「１」の実行は行わない。よって、システム制御部１０５は、まずアプリケーション「４」の実行前にアプリケーション「３」に実行命令を出す（図９−４）。アプリケーション「３」は、アプリケーション「１」からデータを取得し、処理を実行する（図９−５）。アプリケーション「３」は、処理が完了したらシステム制御部１０５にデータ変更の通知を送信する（図９−６）。システム制御部１０５はアプリケーション「３」の実行が完了したので、アプリケーション「３」の実行必要性フラグをFALSEに変更する（図９−７）。次に、システム制御部１０５は、アプリケーション「３」の実行が完了したので、アプリケーション「４」に実行命令を出す（図９−８）。アプリケーション「４」は、アプリケーション「３」からデータを取得し、処理を実行する（図９−９）。アプリケーション「４」は、処理が完了したら、システム制御部１０５にデータ変更の通知を送信する（図９−１０）。システム制御部１０５は、アプリケーション「４」の実行が完了したので、アプリケーション「４」の実行必要性フラグをFALSEに変更する（図９−１１）。アプリケーション「４」は処理結果をシステム制御部１０５に送信し（図９−１２）、ユーザは結果を確認することになる（図９−１３）。

アプリケーション「４」の実行後の各アプリケーションの実行必要性フラグは、図１０に示すようにアプリケーション「１」、「３」、「４」実行が完了しているのでFALSEとなっているが、「２」のフラグは未実行のためTRUEとなっている。

以上により、ユーザは実行するアプリケーションのみを意識すればよく、その参照関係や計算の必要性などは全てシステム制御部で管理するため、ユーザービリティーの高いシステムとして利用することが可能である。

［第２の実施形態］
本発明の好適な第２の実施形態は、システム制御部１０５に、アプリケーションの実行時刻を記録する機能と、アプリケーションの処理結果をウィンドウに表示する際にアプリケーション種別情報及びその表示時刻を記録する機能と、を持たせたものである。これによって、アプリケーション実行後の処理結果が表示されているウィンドウ（他のアプリケーションでの実行も含む）を、全て最新の情報に自動的に更新することができる。

システム制御部１０５は、アプリケーション参照関係に基づく処理の他、ソフトウェアのメニュー、ツールバー及び表示ウィンドウの制御を行う。システム制御部１０５は、ユーザからアプリケーションの実行命令を受け取り、アプリケーションにこれを通知して処理を行わせ、アプリケーションの処理結果を受け取る。そして、システム制御部１０５は、表示用ウィンドウを作成してその処理結果を表示する。ユーザは、表示用ウィンドウを通して、この処理結果を確認することができる。また、本実施形態に係る管理システムは、マルチウィンドウシステムとして構成することができる。これによって、本実施形態に係る管理システムは、複数のウィンドウに情報を分けて表示したり、異なるアプリケーションの実行結果を別々のウィンドウに表示したりすることができる。

また、システム制御部１０５は、ウィンドウへ表示を行う際に、そのウィンドウがどのアプリケーションからデータ転送されたのかを示すアプリケーション種別情報及びその表示が実行された時刻を、ウィンドウ毎に主記憶装置１１５に記録する。これと同時に、システム制御部１０５は、そのアプリケーションが実行された時刻を主記憶装置１１５に記録する。アプリケーション種別情報としては、例えば、システム制御部１０５が、ソフトウェアの起動時に各アプリケーションに割り振った固有の値を用いることができる。

図１１は、ユーザがアプリケーションを実行してからウィンドウに結果が表示されるまでのフローをUML２.０シーケンスで示す図である。図１１では、ユーザがアプリケーションの実行命令を出したときに（図１１−１）、本発明の好適な実施の形態に係るシステム制御部１０５が、該当するアプリケーション及び参照関係にあるアプリケーションに実行命令を出す（図１１−２）。システム制御部１０５は、アプリケーションの実行時刻を主記憶装置１１５に記録する（図１１−３）。アプリケーションの実行が完了すると、アプリケーションからシステム制御部１０５に処理結果情報が渡される（図１１−４）。そして、システム制御部１０５は、表示用のウィンドウを作成する（図１１−５）。その際、システム制御部１０５は、表示用のウィンドウに処理結果が表示されるアプリケーションの種別情報と、アプリケーションがそのウィンドウに処理結果を表示する時刻と、を主記憶装置１１５に記録する（図１１−６,７）。システム制御部１０５は、表示用のウィンドウに処理結果を表示し（図１１−８）、ユーザは、その処理結果を確認する（図１１−９）。

表示用のウィンドウは複数個作成が可能であり、一つのアプリケーションから二つ以上のウィンドウを作成することも可能である。図１１−１０〜１１−２４は、アプリケーションが二つのウィンドウを作成した場合の例を示す。二つのウィンドウを作成した場合の処理は、上述の処理と同様であり、必要なウィンドウの数だけ処理がループされる。

このように、システム制御部１０５に、アプリケーションの実行時刻を記録する機能と、アプリケーションの処理結果をウィンドウに表示する際にアプリケーション種別情報及びその表示時刻を記録する機能と、を持たせる。これにより、ウィンドウの表示を自動的に更新する機能（ウィンドウ表示自動更新機能）を実現することができる。

以下、図５を用いてこの機能について説明する。ここでは、アプリケーション「１」を“レンズ構成データ変更アプリケーション”とし、アプリケーション「３」を“光線追跡図表示アプリケーション”とする。また、１番目のウィンドウを“ズーム番号１の光線追跡図表示”とし、２番目のウィンドウを“ズーム番号２の光線追跡図表示”とする。また、アプリケーション「１」でデータ入力を行い、そのデータを参照してアプリケーション「３」でウィンドウに光線追跡図を表示するものとする。

図１２に示すように、ユーザ１２０１の操作により、上述の管理システムを実行すると、「光学ＣＡＤシステム」とタイトル表示されたソフトウェアメインウィンドウ１２０４が表示される。ソフトウェアメインウィンドウ１２０４のメニューバーには、「レンズデータ構成」と「光線追跡」とが表示されている。ユーザ１２０１は、「レンズデータ構成」をマウス等で選択すると、アプリケーション「１」が実行されて、レンズデータ構成ウィンドウ１２０５が表示される。同様に、ユーザ１２０１は、「光線追跡」をマウス等で選択すると、アプリケーション「３」が実行されて、光線追跡図ウィンドウ１２０６が表示される。ここでは、レンズデータ構成ウィンドウ１２０５が既に表示されているものとする。そして、ユーザ１２０１が、レンズデータ構成ウィンドウ１２０５でデータを入力し、メニューバーに表示された「光線追跡」を選択すると（１２０２）、アプリケーション「１」の処理結果を利用してアプリケーション「３」が実行される。システム制御部１０５は、アプリケーション「３」の実行結果を表示するための光線追跡図ウィンドウ１２０６を作成し、そのウィンドウ内に図形を表示する。図１２では、システム制御部１０５は、２つの光線追跡図ウィンドウ１２０６を作成したが、これに限定されない。この場合、システム制御部１０５は、アプリケーションの実行時刻と、作成されたウィンドウに表示を行ったアプリケーションの種別情報及びその表示時刻と、を記録する。

図１３は、ウィンドウ表示自動更新機能を例示的に示す図である。図１３に示すように、ユーザ１３０１の操作により上述の管理システムを実行すると、ソフトウェアメインウィンドウ１３０３が表示される。ユーザ１３０１がソフトウェアメインウィンドウ１３０３で「光線追跡」を選択すると、アプリケーション「３」が実行される。そして、ソフトウェアメインウィンドウ１３０３に光線追跡図ウィンドウ１３０５が表示される。光線追跡図ウィンドウ１３０５が表示されているときに、ユーザが「レンズデータ構成」を選択してアプリケーション「１」を実行させると、レンズデータ構成ウィンドウ１３０４が表示される。ユーザ１３０１が、レンズデータ構成ウィンドウ１３０４からデータを入力し（１３０２）、アプリケーション「１」を実行させると、アプリケーション「１」のデータが更新される。このとき、ユーザ１３０１がアプリケーション「３」を明示的に実行させなくても、アプリケーション「１」に新しく入力されたデータ（１３０２）に基づいて、光線追跡図ウィンドウ１３０６が自動的に作成され、新たな図形が表示される。

図１４は、図１３に示す自動更新機能の仕組みをUML２.０シーケンスで示す図である。ユーザ１３０１は、アプリケーション「３」により光線追跡図ウィンドウ１３０６が表示されているときに、「レンズデータ構成」を選択して、アプリケーション「１」の実行命令をシステム制御部１０５に出す（図１４−１）。システム制御部１０５は、ユーザ１３０１から実行命令が出されたアプリケーション「１」を実行する（図１４−２）。アプリケーション「１」は、アプリケーション「１」の処理が終了すると、データ変更の通知をシステム制御部１０５に渡す（図１４−３）。システム制御部１０５は、図４の全アプリケーション被参照関係テーブル４０３を用いて、アプリケーション「１」の参照元のアプリケーションを検索する（図１４−４）。そして、システム制御部１０５は、検索されたアプリケーションの実行必要性フラグをTRUE（イネーブル）に変更する。例えば、図５に示す参照関係の場合には、アプリケーション「２」、「３」及び「４」が参照元のアプリケーションとして検索される。そして、アプリケーション「１」は、その処理結果をシステム制御部１０５に渡す（図１４−６）。ここまでは、上述の管理システムと同様である。次いで、システム制御部１０５は、現在表示が行われているウィンドウの属性を確認する。具体的には、先頭のウィンドウ（１番目のウィンドウ）の属性を確認し、表示が実行されているアプリケーションの情報を取得する（図１４−７）。この場合、上述のように、アプリケーション「３」が既に実行されているため、１番目のウィンドウはアプリケーション「３」により表示されたという情報を持っている。そこで、システム制御部１０５は、アプリケーション「３」で実行された表示であると判断する。次いで、システム制御部１０５は、アプリケーション「３」の実行必要性フラグを確認する（図１４−８）。システム制御部１０５は、アプリケーション「３」の実行必要性フラグがFALSEであれば実行しないが、TRUEであればアプリケーション「３」に実行命令を出す。ここでは、アプリケーション「３」の実行必要性フラグは、図１４−５によりTRUEに変更されているので、システム制御部１０５は、アプリケーション「３」に実行命令を出す（図１４−９）。アプリケーション「３」は、既に最新のデータに変更されているデータをアプリケーション「１」から取得し、その処理を実行する（図１４−１０）。アプリケーション「３」は、その処理が終了すると、システム制御部１０５にデータ変更の通知を行う（図１４−１１）。システム制御部１０５は、アプリケーション「３」の実行必要性フラグをFALSEにする（図１４−１２）。アプリケーション「３」は、その処理結果をシステム制御部１０５に転送する（図１４−１３）。システム制御部１０５は、更新された最新のデータを１番目のウィンドウに表示する（図１４−１４）。ウィンドウ表示後は、上記のウィンドウ属性記録の仕組みに従って、ウィンドウ表示を行っているアプリケーションの情報、ウィンドウ表示を行った時刻、及びアプリケーションの実行時刻を記録する（図１４−１５）。

以上の仕組みにより、アプリケーション「１」のデータ変更後に、アプリケーション「３」によって表示されている先頭のウィンドウ（第１番目のウィンドウ）の自動更新が可能である。２番目以降のウィンドウも、アプリケーション「３」によって表示されているウィンドウであるため、更新するにはアプリケーション「３」の再実行が必要となる。しかしながら、図１４−１２により、既にアプリケーション「３」の実行必要性フラグがFALSEになっている。そのため、システム制御部１０５は、２番目以降のウィンドウについては、図１４−８のアプリケーション実行必要性の確認により、アプリケーション「３」に実行命令を出すことが出来ない。そこで、同一アプリケーションにより複数ウィンドウが表示される場合、２番目以降のウィンドウについては、先頭のウィンドウが更新されたときのそのアプリケーションの実行時刻（図１４−１５の時刻）と、ウィンドウ表示が行われた時刻とを比較する。そして、時刻に差があった場合は、以下のようにそのアプリケーションの実行命令を出すものとする。

図１４を参照すると、まずシステム制御部１０５は、２番目のウィンドウの属性を確認する（図１４−１６）。２番目のウィンドウに表示を行っているアプリケーションは「３」である。システム制御部１０５は、２番目のウィンドウに表示が行われた時刻と、図１４−１５でシステム制御部１０５が記録したアプリケーションの実行時刻とを比較する（図１４−１７）。システム制御部１０５は、比較した時刻に差があると、アプリケーション「３」に実行命令を出す（図１４−１８）。そして、アプリケーション「３」は、アプリケーション「１」のデータを取得する（図１４−１９）。アプリケーション「３」は、その処理が終了すると、データ変更通知をシステム制御部に送る（図１４−２０）。システム制御部１０５は、アプリケーション「３」の実行必要性フラグをFALSEにする（図１４−２１）。アプリケーション「３」は、その処理結果情報をシステム制御部１０５に転送する（図１４−２２）。そして、システム制御部１０５は、２番目のウィンドウに結果を表示し（図１４−２３）、その後、ウィンドウ属性を変更する（図１４−２４）。このようにして、ユーザは、アプリケーション「１」を実行するだけで、最新のデータによるアプリケーション「３」の表示結果を確認することができる。（図１４−２５）。

［第３の実施形態］
本発明の好適な第３の実施形態は、システム制御部１０５に、ウィンドウ表示自動更新判定フラグと、そのフラグをユーザが変更することができるユーザーインターフェースと、を持たせたものである。これによって、ユーザが、ウィンドウ表示更新機能を自由なタイミングで実行することができ、利便性の向上につながる。

上記のウィンドウ自動更新の仕組みにおいて、システム制御部１０５は、ウィンドウ毎にウィンドウ表示自動更新判定フラグを持つ。ユーザは、このフラグの設定を変更することによって、ウィンドウ表示の更新を自動で行うか手動で行うかを選択することができる。ユーザは、メニューやGUIウィンドウなどのユーザーインターフェースを用いて、このフラグの設定変更をシステム制御部１０５に要求することができる。

図１４−７、図１４−１６に示すように、システム制御部１０５は、ウィンドウ属性を確認する前に、このウィンドウ表示自動更新判定フラグを確認する。ウィンドウ表示自動更新判定フラグがTRUEであれば、上記の仕組みによって、ウィンドウ表示が自動更新される。ウィンドウ表示自動更新判定がFALSEの場合は、図１４を例に挙げると、１番目のウィンドウが自動更新オフの設定である場合には、図１４−７〜１５までは実行はされない。また、２番目のウィンドウが自動更新オフの設定である場合には、図１４−１６〜２４は実行されない。

システム制御部１０５は、ウィンドウ表示の更新を行うユーザーインターフェース（メニューやツールバーボタン）を提供する。ユーザは、このユーザーインターフェースを利用することによって、図１４−７〜１５、図１４−１６〜２４の処理を自由なタイミングで実行することができる。

図１５は、ウィンドウ表示手動更新処理をUML２.０シーケンスで示す図である。ユーザは、システム制御部１０５に対して、更新したいウィンドウを指定し、ウィンドウ更新命令を出す（図１５−１）。システム制御部１０５は、指定されたウィンドウの属性を確認し、そのウィンドウ表示を行った時刻とシステムが記録している現在のアプリケーションの実行時刻とを比較する。両者に差があった場合には、システム制御部１０５は、アプリケーションに対して実行命令を出す（図１５−２〜４）。処理終了後に、アプリケーションは、システム制御部１０５にデータ変更通知をする。システム制御部１０５は、このアプリケーションの実行フラグをFALSEにする（図１５−５,６）。アプリケーションは、処理結果情報をシステム制御部１０５に転送し、システム制御部１０５は、結果をウィンドウに表示する（図１５−７,８）。その後、ウィンドウ属性の変更をシステム制御部１０５が行い（図１５−９）、ユーザは、更新した結果を確認することができる（図１５−１０）。

［第４の実施形態］
本発明の好適な第４の実施形態は、データ変更前のデータを主記憶装置１１５の別の記憶領域に退避させるものである。これによって、ユーザがデータ変更後の値を一度確認して求める解でなかった場合に、変更前のデータを回復することができ、ユーザービリティーの向上につながる。

ユーザは、アプリケーション実行時に、ユーザーインターフェースとして図１６に示すようなGUIウィンドウ１６０１を利用する。GUIウィンドウ１６０１は、例えば、「OK」、「キャンセル」及び「試行」の３つのボタンを備える。ユーザがGUIウィンドウ１６０１でデータを変更した後に、「OK」ボタンを押すことによりデータ更新が行われ、上述したウィンドウ表示自動更新機能により参照関係にあるアプリケーションが全て実行される。その結果、最新のデータによってウィンドウ表示が自動的に更新される。ユーザがGUIウィンドウ１６０１で「キャンセル」ボタンを押すと、データ変更の値は破棄されて処理が終了する。ユーザがGUIウィンドウ１６０１で「試行」ボタンを押すと、データ変更後の値で一度実行して確認することができ、また再度ウィンドウでのデータ入力が可能になる。

その後、ユーザがGUIウィンドウ１６０１で「OK」ボタン又は「キャンセル」ボタンを押すことにより、データ変更を適用するのかしないのかを選択することができる。試行ボタンは何回も押すことが可能である。

図１７を参照して上記の試行機能の処理フローを示す。まず、ユーザからの操作によりウィンドウがオープンされると（Ｓ００１）、アプリケーションは、現在の主記憶装置１１５上のデータを一時的に別の記憶領域にコピー（バックアップ）する（Ｓ００２）。ユーザは、このウィンドウ上のデータ入力欄にデータを入力することによって、入力データを変更する（Ｓ００３）。データ入力後に、ユーザが「OK」、「キャンセル」及び「試行」の３つのボタンのいずれかを押すことにより、処理を選択することができる（Ｓ００４）。

ユーザが「OK」ボタンを押した場合には、ウィンドウで入力した値によりアプリケーションが実行され（Ｓ００５）、主記憶装置１１５上のデータが更新され（Ｓ００６）、ウィンドウがクローズされる（Ｓ００７）。アプリケーションの実行によりデータが更新されたので、そのアプリケーションと参照関係にあるアプリケーションも再実行される。そして、表示ウィンドウが最新の状態に自動的に更新され（Ｓ００８）、処理が終了する（Ｓ１００）。

ユーザが「キャンセル」を押した場合には、ウィンドウで変更した値は主記憶装置１１５にセットされず、そのままウィンドウがクローズして（Ｓ００９）、処理が終了する（Ｓ１００）。

ユーザが「試行」ボタンが押した場合には、変更後のデータでアプリケーションが実行される（Ｓ０１０）。その結果を最初にコピーした一時的な記憶領域にセットし、実行したアプリケーションと参照関係にあるアプリケーションを実行し、表示ウィンドウを更新する（Ｓ０１２）。Ｓ０１２の処理を終了した後、再度Ｓ００３に戻り、再度入力ウィンドウ上でデータ更新が可能となる。再度ウィンドウ上でボタンを選択することができ、ユーザが「OK」ボタンを押した場合には、変更後の値を主記憶装置１１５にセットする。ユーザが「キャンセル」ボタンを押した場合には、バックアップでコピーしておいた変更前の値に戻して、ウィンドウが開く前の状態に戻す。このとき、再度データを変更し、試行ボタンを押すことも可能である。なお、主記憶装置１１５としてはメモリやファイルが利用可能である。

以上のように、第１〜第４の実施形態に係るシステムによれば、多数のアプリケーションを定義した場合でも、そのアプリケーション自身の参照関係を定義するだけで、ソフトウェア全体の参照関係テーブルを自動的に構築できる。そのため、開発者はアプリケーションの参照関係を意識しなくてもよい。

また、システム制御部は、予め定められた場所にアプリケーションを全てロードする機能をもつ。そのため、ユーザは利用可能なアプリケーションの数を気にせず、新規にアプリケーションを追加する場合には、統一のテーブルデータ構造をもたせて、その場所に置くだけでよい。したがって、システムに修正を加える必要がなく、ソフトウェアの拡張を行うことができる。

その結果、開発者にとって、システムの拡張が容易になり、開発・保守の負荷が軽減される。また、アプリケーションの実行の際に、そのアプリケーションを実行するのに必要な処理を、全てシステム制御部が自動的に判断する。そのため、利用者は、数多くの操作手順を覚える必要がない。また、アプリケーションの実行の必要性をシステム制御部が自動的に判断することによって、少ない操作で無駄のない最適な処理を行うことができ、ユーザービリティーの向上につながる。

ソフトウェア及びハードウェア構成を示す図である。 アプリケーション参照関係テーブルを示す図である。 ソフトウェア起動時の処理シーケンスを示す図である。 システム制御部テーブルを示す図である。 アプリケーション参照関係Tree構造を示す図である。 アプリケーション参照関係検索フローを示す図である。 アプリケーション実行処理シーケンスを示す図である（参照されるアプリケーション実行時）。 アプリケーション「１」実行後の実行必要性フラグ結果を示す図である。 アプリケーション実行処理シーケンスを示す図である（参照するアプリケーション実行時）。 アプリケーション「４」実行後の実行必要性フラグ結果を示す図である。 アプリケーションの処理結果をウィンドウ表示するシーケンスを示す図である。 ユーザによりアプリケーションを実行する様子を示す図である。 表示ウィンドウ自動更新処理を示す図である。 表示ウィンドウ自動更新処理シーケンスを示す図である。 表示ウィンドウ手動更新処理シーケンスを示す図である。 アプリケーションウィンドウを示す図である。 試行機能処理フローチャートを示す図である。

符号の説明

１００ 管理システム
１０１、１０２ アプリケーション
１０３、１０４ 参照関係テーブル
１０５ システム制御部
１０６、１０８ 記憶手段
４０３ 全アプリケーション被参照関係テーブル

Claims (10)

1. 複数のアプリケーションの参照関係を管理する管理システムであって、
   複数のアプリケーションのそれぞれのアプリケーション名に対してその参照先のアプリケーション名が対応づけられている参照関係テーブルを記憶するための記憶手段と、
   前記複数のアプリケーションを実行するためのシステム制御部と、
   を備え、
   前記システム制御部は、前記記憶手段から前記複数のアプリケーションのそれぞれの前記参照関係テーブルを取得し、取得した前記参照関係テーブルに基づいて前記複数のアプリケーションのそれぞれのアプリケーション名とその参照元のアプリケーション名とが対応づけられている全アプリケーション被参照関係テーブルを作成し、実行するアプリケーションのアプリケーション名に基づいて前記全アプリケーション被参照関係テーブルを検索して対応する参照元のアプリケーションを抽出し、抽出された前記参照元のアプリケーションの実行必要性フラグをイネーブルにする手段を有することを特徴とする管理システム。
2. 前記システム制御部は、前記取得された参照関係テーブルに基づいて前記複数のアプリケーションのそれぞれのアプリケーション名とその参照先のアプリケーション名とが対応づけられている全アプリケーション参照関係テーブルを作成し、前記実行するアプリケーションのアプリケーション名に基づいて前記全アプリケーション参照関係テーブルを検索して対応する参照先のアプリケーションを抽出し、抽出された前記参照先のアプリケーションのうち前記実行必要性フラグがイネーブルであるアプリケーションに実行命令を送信する手段を有することを特徴とする請求項１に記載の管理システム。
3. 前記システム制御部は、前記実行命令を送信するアプリケーションに更に参照先となるアプリケーションが存在する場合には、更に参照先となる前記アプリケーションに優先的に前記実行命令を送信する手段を有することを特徴とする請求項２に記載の管理システム。
4. 前記システム制御部は、前記更に参照先となるアプリケーションの実行が完了した場合には、そのアプリケーションの前記実行必要性フラグをディセーブルとし、その実行結果をその参照元のアプリケーションに送信する手段を有することを特徴とする請求項３に記載の管理システム。
5. 前記システム制御部は、実行した前記アプリケーションの実行時刻を前記記憶手段に記憶し、その処理結果をウィンドウに表示する手段を備えることを特徴とする請求項１乃至請求項４のいずれか１項に記載の管理システム。
6. 前記システム制御部は、表示した前記ウィンドウに対応するアプリケーションの種別情報とその処理結果の表示時刻とをそのウィンドウと対応づけて前記記憶手段に記憶する手段を備えることを特徴とする請求項５に記載の管理システム。
7. 前記システム制御部は、現在表示されている前記ウィンドウを確認し、そのウィンドウに対応づけられた前記アプリケーションの種別情報に基づいて前記実行必要性フラグがイネーブルであるか否かを判断し、前記実行必要性フラグがイネーブルである場合には、そのアプリケーションを自動的に実行する手段を有することを特徴とする請求項６に記載の管理システム。
8. 前記システム制御部は、前記ウィンドウが複数表示されている場合には、各ウィンドウに対応づけられた前記アプリケーションの種別情報に基づいて同一アプリケーションの処理結果が表示されているか否かを判断し、同一のアプリケーションの処理結果が表示されている場合には、そのアプリケーションの前記実行必要性フラグをイネーブルにすることを特徴とする請求項７に記載の管理システム。
9. 前記システム制御部は、前記自動的に実行する処理を行う否かを示すウィンドウ表示自動更新判定フラグを前記ウィンドウ毎に設定する手段を備えることを特徴とする請求項７に記載の管理システム。
10. 前記システム制御部は、入力された第１のデータに従って前記アプリケーションを実行してその処理結果を前記記憶手段の第１の記憶領域に記憶し、入力された第２のデータに従って前記アプリケーションを実行してその処理結果を前記記憶手段の第２の記憶領域に記憶し、前記アプリケーションからの処理命令に応じて、利用する記憶領域を前記第１、第２の記憶領域の間で切り換える手段を備えることを特徴とする請求項１乃至請求項９のいずれか１項に記載の管理システム。

Images