JP6102136B2 - モジュール管理装置、モジュール管理システム及びモジュール管理方法 - Google Patents

Description

本発明は、オブジェクト指向言語で記述されたプログラムのモジュールを一元管理するモジュール管理基盤において、定義情報の衝突を回避させるモジュール管理装置、モジュール管理システム及びモジュール管理方法に関する。

Ｊａｖａ（登録商標）に代表される委譲モデルのクラスロード機構を持つオブジェクト指向言語では、クラスをパッケージ名と組み合わせた完全修飾クラス名で区別している。これによって同じ名前を持つクラスであっても、パッケージ名を見ることで異なるクラス定義であると区別できている。このような言語では、例えば特許文献１にあるように、提供機能ごとにパッケージやクラスをひとまとまりとしたモジュールとしてファイル化し、配布することが可能となっている。

また、コンピュータの高性能化や開発効率の向上によって、莫大な数のモジュールを使用した大規模なシステムも増えてきている。このようなシステムでは、システムを構成するモジュール間に依存関係があり、特定のバージョンのモジュールが他の特定のモジュールを参照して、特定の機能を提供することで成り立っている。

しかしながら、システム更新や機能追加によってシステムの規模が大きくなるにつれて、モジュールの名前や提供機能、バージョン、配置場所などの管理が煩雑になる。そのため、モジュール名やパッケージの衝突、想定外のバージョン依存、モジュールの重複などの問題が生じてきた。

そこで、近年では、モジュールをバンドルという単位で管理するモジュール管理基盤が開発されている。バンドルは、モジュールに加えて、そのバンドルの定義情報を含んでいる。定義情報とは、シンボリックネームという名前やバージョン番号、参照するバンドル、参照されるバンドルといったものである。モジュール管理基盤では、シンボリックネームとバージョン番号のペアでモジュールを区別する。

モジュール管理基盤は、起動時に管理下のバンドルのバージョンや依存関係を検証して、バンドルの定義情報の衝突や依存関係の不整合を事前に検知することができる。また、バンドルのライフサイクルを管理することによってバンドルの更新を動的に行なうことができる。そのため、システムを停止できないような環境においても、バンドルでの更新が可能となっている。最近では、モジュール管理基盤は、アプリケーションサーバや統合開発環境に採用され、動的なモジュールの追加・削除や、無停止でのモジュール更新といった特長が有効に活用されている。

例えば、特許文献１には、モジュールのシンボリックネーム、バージョン番号や依存関係などの定義情報を含むマニフェストファイルを自動生成することで、モジュール管理基盤におけるモジュールの管理負荷を軽減する技術が開示されている。

このように、モジュール管理基盤では、プログラムを機能ごとに分割したモジュールを名前・バージョンなどの定義を含むバンドルによって管理する。そして、モジュール管理基盤は、起動・停止の状態制御や他のバンドルとの依存関係を確認して、それらの機能をアプリケーションにサービスとして提供することができる。

しかしながら、これらのモジュール管理基盤の機能によって、アプリケーションにとっては便利になった反面、モジュールの管理の厳密性が増し、モジュールの定義情報の設定・更新には以前にも増して注意が必要となってきた。

特開２０１２−９３９７９号公報

特許文献１のようなモジュール管理基盤では、バージョン番号とシンボリックネームのペアが基盤全体で一意である必要がある。そのため、モジュール管理基盤上に同じバージョン番号とシンボリックネームを持つバンドルが既に存在していた場合、後から追加したバンドルはバンドルの定義情報の衝突によるエラーによってロードされないという課題があった。

また、一般的なモジュール管理基盤では、衝突が起こりうるバンドルをロードし、ロードした順番でバンドルＩＤを付与することができる。しかしながら、管理対象から外れたバンドルの使用を想定して追加された他のバンドルが間違ったバンドルを参照してしまい、想定外の実行結果を招く可能性があるという課題があった。

本発明の目的は、バンドル本体を修正することなくバンドルの定義情報の衝突を解決してバンドルの共存を可能とすると共に、バンドル間の依存関係を正しく構成するモジュール管理装置、モジュール管理システム、モジュール管理方法及びその管理方法を用いたプログラムを提供することにある。

本発明のモジュール管理装置は、オブジェクト指向言語で記述されたプログラムからなるモジュール及びモジュールの属性を含む定義情報を有するバンドルと、複数のバンドルからなるモジュール群と、を一元管理するモジュール管理基盤の起動時においてバンドルをフォルダからロードする際に、異なるバンドル間で定義情報が衝突する場合、定義情報を動的に変更し、バンドルの参照関係を整合する。

本発明のモジュール管理方法は、オブジェクト指向言語で記述されたプログラムからなるモジュール及びモジュールの属性を含む定義情報を有するバンドルと、複数のバンドルからなるモジュール群と、を一元管理するモジュール管理基盤の起動時においてバンドルをフォルダからロードする際に、異なるバンドル間で定義情報が衝突する場合、定義情報を動的に変更し、バンドルの参照関係を整合する。

本発明によれば、同一の定義情報を含むバンドルの定義情報の衝突を回避し、それらの両方のバンドルを動作させて、複雑な依存関係を持つ複数のモジュール群が独立に並行して動作することができる。

本発明の実施形態に係るモジュール管理装置の論理構成を示すブロック図である。 本発明の実施形態に係るモジュール管理基盤の構成例である。 本発明の実施形態に係る共通バンドルのロード処理を示すフローチャートである。 本発明の実施形態に係る個別バンドルのロード処理を示すフローチャートである。 本発明の実施形態に係るバンドル情報テーブルの一例である。 本発明の実施形態に係るシンボリックネーム変更管理テーブルの一例である。 本発明の実施例１に係るモジュール管理基盤におけるモジュール群の構成図である。 本発明の実施例１に係るバンドルの関係を示す図である。 本発明の実施例１に係るフォルダ構成を示す図である。 本発明の実施例１に係るモジュール管理基盤上のバンドルの状態を示す図である。 本発明の実施例２に係るフォルダ構成を示す図である。 本発明の実施例２に係るモジュール管理基盤上のバンドルの状態を示す図である。 本発明の実施例３に係るフォルダ構成を示す図である。 本発明の実施例３に係るモジュール管理基盤上のバンドルの状態を示す図である。 本発明の実施例４に係るフォルダ構成を示す図である。 本発明の実施例４に係るモジュール管理基盤上のバンドルの状態を示す図である。

本発明の実施形態について、図面を参照して説明する。なお、以下の実施形態において、バンドルは、ＯＳＧｉ（Ｏｐｅｎ Ｓｅｒｖｉｃｅｓ Ｇａｔｅｗａｙ ｉｎｉｔｉａｔｉｖｅ）に特有の属性として、シンボリックネーム、バージョン情報などのメタデータが記述されたマニフェストファイルを有するものとする。ただし、以下の実施形態は本発明の一例であり、ＪＡＶＡ以外のオブジェクト指向言語を用いたとしても、ＯＳＧｉと同様の属性管理がなされるモジュール管理システムには、本発明の実施形態に係る手法を適用できる。

（実施形態）
図１は、本発明の実施形態に係る衝突回避装置１の論理構成を示すブロック図である。なお、本実施形態に係る衝突回避装置１は、モジュールの定義情報の衝突を回避する処理を行うモジュール管理装置に相当する。図２は、本発明の実施形態に係るモジュール管理基盤の構成例である。

図３は、本発明の実施形態に係る共通バンドルのロード処理を示すフローチャートである。図４は、本発明の実施形態に係る個別バンドルのロード処理を示すフローチャートである。

また、図５にはバンドルの定義情報や依存関係などをまとめたバンドル情報テーブル５０（第１のテーブル）を、図６にはバンドルのファイルパスとシンボリックネームの変更履歴をまとめたシンボリックネーム変更管理テーブル６０（第２のテーブル）を示した。なお、バンドル情報テーブル５０及びシンボリックネーム変更管理テーブル６０は、通常主記憶装置であるメモリに格納されているものとする。ただし、バンドル情報テーブル５０及びシンボリックネーム変更管理テーブル６０は、図１の構成要素に含めてもよく、情報格納部１３の内部に格納することもできる。

（構成）
図１において、本実施形態に係る衝突回避装置１は、フォルダ走査部１０と、ロード処理部１１と、バンドル依存解決部１２と、情報格納部１３と、定義変更部１４と、衝突検知部１５とを備えている。

フォルダ走査部１０は、共通バンドル配置フォルダや個別バンドル配置フォルダ内部に、未処理のバンドルファイルがあるかどうかを確認する。なお、これ以降、共通バンドル配置フォルダをｍｏｄｕｌｅｓフォルダと記載し、個別バンドル配置フォルダをｉｎｄｉｖｉｄｕａｌｓフォルダと記載する。

ロード処理部１１は、バンドルの読み込み処理を行う。バンドルの読み込み処理では、バンドルの情報をバンドル情報テーブル５０に追加し、その更新されたバンドル情報を情報格納部１３に格納する。

依存解決処理部１２は、バンドルの依存関係の解決処理を行う。依存解決処理部１２は、バンドルファイルがロードされると、そのバンドルファイルの参照関係を整合させるために、参照先の定義情報に合わせて依存バンドルのリンク処理を行う。

情報格納部１３は、バンドルやバンドル情報を格納する。また、情報格納部１３は、テーブルの情報を追加・更新する。情報格納部１３は、バンドル情報テーブル５０及びシンボリックネーム変更管理テーブル６０といった、バンドルに関する情報を格納してもよく、それらのテーブルに記録する情報のみを格納してもよい。

定義変更部１４は、バンドルの定義情報を変更する。バンドルの定義情報は、例えば、シンボリックネームやバージョン情報などのように、バンドルを一意に特定する文字列、記号列などからなるメタ情報を有する。例えば、後述するように、シンボリックネームの先頭にサブフォルダ名の一部もしくは全部を付したり、アンダーバーなどの記号や文字を付したりすることによって、定義情報の変更をすることができる。

なお、定義情報に関しては、シンボリックネームに限らず、そのバンドルを一意に特定できるような情報であればよい。また、定義情報の変更に関しても、特定の文字の追加や削除、特別に定義された変更条件、一般的な文字列や記号列の変更方法などを用いることができる。

衝突検知部１５は、図５の定義変更部１４で変更された定義情報によって、バンドルの定義情報の衝突が起こるか否かを検知する。具体的には、バンドル情報テーブル５０を参照し、ロード済みのバンドルと、後からロードされたバンドルの間で衝突が起きるか否かを検知することになる。

図２は、本発明の実施形態に係るモジュール管理基盤２１の構成例を示す。なお、図２においては、バンドルの参照関係を矢印で示している。矢印の始点にあるバンドルは、矢印の終点にあるバンドルを参照する。図２の上段図における点線の矢印は、間違った参照によって衝突が起こることを示している。

図２の上段は、モジュール群Ａ２２に属するバンドルａ２４、バンドルｂ２５及びバンドルｃ２６、モジュール群Ｂ２３に属するバンドルｄ２７、バンドルｅ２８及びバンドルｃ２９を、定義情報の変更なしにモジュール管理基盤２１で動作させる状態を示している。なお、図２において、シンボリックネームはそれぞれのバンドル名と同一であるとする。また、図２の例においては、モジュール群Ａ２２のバンドルを先にロードし、その後モジュール群Ｂ２３のバンドルをロードするものとする。

図２の上段では、モジュール群Ａ２２のバンドルｂ２５は、バンドルａ２４及びバンドルｃ２６を参照している。また、モジュール群Ｂ２３のバンドルｅ２８は、バンドルｄ２７及びバンドルｃ２９を参照している。

また、図２の上段において、モジュール群Ａ２２のバンドルｃ２６と、モジュール群Ｂ２３のバンドルｃ２９は、シンボリックネームなどの定義情報は同じでありながら異なるバンドルであるものとする。

ここで、図２の上段の構成とした場合、後からロードされたモジュール群Ｂ２３に属するバンドルｅ２８は、先にロードされたモジュール群Ａ２２のバンドルｃ２６を誤って参照し、バンドルの定義情報の衝突が起きてしまう。バンドルｅ２８は、本来ならばモジュール群Ｂ２３に属するバンドルｃ２９を参照して動作すべきである。そのため、モジュール群Ｂ２３のバンドルｅ２８モジュール群Ａ２２に属するバンドルｃ２６を参照してしまうと、アプリケーションは意図しない動作をすることにつながる。

図２の下段は、本発明の実施形態に係るモジュール管理基盤２１の構成例を示す。図２の下段の例では、モジュール群Ａ２２に属するバンドルａ２４、バンドルｂ２５及びバンドルｃ２６のシンボリックネームは、モジュール管理基盤２１にロードされる際、それぞれバンドルＡａ、バンドルＡｂ及びバンドルＡｃへと動的に変更される。同様に、モジュール群Ｂ２３に属するバンドルｄ２７、バンドルｅ２８及びバンドルｃ２９のシンボリックネームは、それぞれバンドルＢｄ、バンドルＢｅ及びバンドルＢｃと変更される。なお、シンボリックネームの変更の際には、後述するようにバンドルの参照関係の変更も同時に行うものとする。

その結果、図２の下段の例では、図２の上段のような誤った参照はされず、バンドルの参照関係が正しく維持されることになる。よって、モジュールＢ群２３に属するバンドルＢｅは、誤ってモジュール群Ａ２２のバンドルＡｃを参照することもないため、バンドルの定義情報の衝突は回避され、アプリケーションは正しい動作をすることになる。

（動作）
本発明の実施形態に係るモジュール管理装置では、上述の構成を備えた衝突回避装置を使って、以下の動作でバンドルの定義情報の衝突を回避する。

以下の動作では、工程１において、共通バンドル配置フォルダであるｍｏｄｕｌｅｓフォルダ内におけるバンドルのロード処理を行う。続いて、工程２において、個別バンドル配置フォルダであるｉｎｄｉｖｉｄｕａｌｓフォルダのロード処理を行う。

〔工程１〕
まず、図３を用いて、モジュール管理基盤２１が起動し、バンドルのロード処理を実行する工程１を説明する。

図３において、工程１のロード処理では、まず、フォルダ走査部１０が、ｍｏｄｕｌｅｓフォルダに未処理のバンドルファイルがあるか否かを確認する(ステップ３１)。

未処理のバンドルがあればロード処理に移行する（ステップ３２へ進む）。未処理のバンドルがなければ、工程１のフローは終了とし、工程２のロード処理に移行する。

次に、衝突検知部１５がバンドル情報テーブル５０を参照して、ロード済みバンドルの定義情報（第１の定義情報に相当）と未処理バンドルの定義情報（第２の定義情報に相当）の衝突が発生するか否かを確認する(ステップ３２)。

ロード済みバンドルと未処理バンドルの定義情報が衝突していない場合、ロード処理部１１は未処理バンドルの読み込み処理を行なう(ステップ３３)。

ステップ３２において、ロード済みバンドルと未処理バンドルの定義情報との衝突が発生した場合は、エラーとしてロード処理を終了する。

バンドルの読み込み処理では、バンドル情報テーブル５０にバンドルの情報を追加し、情報格納部１３にバンドル情報を格納する（ステップ３３）。

その後、バンドル依存解決処理として、依存解決処理部１２は依存バンドルのリンク処理を行う(ステップ３４)。バンドル依存解決処理が終了したら、ステップ３１に戻る。

依存するバンドルが同じフォルダ内にあり（ステップ３５でＹｅｓ）、それが未処理のバンドルであれば（ステップ３６でＹｅｓ）、フォルダ走査部１０はそのバンドルのロード処理を行なう（ステップ３３）。

ここで、ステップ３３〜３６の処理は、バンドルの定義情報の衝突が解決されるまで繰り返される。

同一フォルダに依存するバンドルがないか（ステップ３５でＮｏ）、もしくは依存するバンドルに未処理のバンドルがない場合（ステップ３６でＮｏ）、ｍｏｄｕｌｅｓフォルダ内にある他の未処理バンドルのロード処理を行う（ステップ３１に戻る）。

以上が工程１の手順である。なお、以上の手順は本実施形態の一例であり、工程１においては、共通バンドル配置フォルダから、バンドルの定義情報の衝突がなく、正しい依存関係でバンドルをロードできさえすればよい。

このように、ｍｏｄｕｌｅｓフォルダ内における全てのバンドルのロード処理（工程１）が完了すると、フォルダ走査部１０は、ｉｎｄｉｖｉｄｕａｌｓフォルダ内のバンドルのロード処理（工程２）に移る。

〔工程２〕
次に、図４を用いて、ｉｎｄｉｖｉｄｕａｌｓフォルダのロード処理を実行する工程２を説明する。

図４において、フォルダ走査部１０は、ｉｎｄｉｖｉｄｕａｌｓフォルダ内に未処理のサブフォルダがあるか否かを確認する(ステップ４１)。

未処理のサブフォルダがある場合(ステップ４１でＹｅｓ)、そのサブフォルダに移動する(ステップ４２)。

サブフォルダがない場合(ステップ４１でＮｏ)は、ロード処理を終了する。

フォルダ走査部１０は、サブフォルダに移動すると、サブフォルダ内に未処理のバンドルがあるか否かを確認する(ステップ４３)。

定義変更部１４は、未処理のバンドルをみつけると、そのバンドルの定義情報を変更する(ステップ４４)。

図２に示した例では、ステップ４４に示したバンドルの定義情報の変更において、バンドルの定義名であるシンボリックネームの先頭にサブフォルダ名を付加し、シンボリックネーム変更管理テーブル６０に情報を追加している。

その後、衝突検知部１５は、バンドル情報テーブル５０及びシンボリックネーム変更管理テーブル６０を参照して、衝突の有無を確認する(ステップ４５)。ここで、ステップ４４、４５は、バンドルの定義情報の衝突が解決されるまで継続される。なお、これらのステップで衝突があった場合に変更した定義情報は、第３の定義情報に相当する。

バンドルの定義情報の衝突が発生していない場合(ステップ４５でＹｅｓ)、ロード処理部１１が読み込み処理を行う(ステップ４６)。

バンドルの定義情報の衝突が発生していた場合(ステップ４５でＮｏ)、再度バンドルの定義情報を変更する（ステップ４４に戻る）。

例えば、ステップ４５において、バンドルの定義情報の衝突が発生していた場合、バンドルのシンボリックネームにアンダーバーなどの記号や文字を追加して、さらにシンボリックネームを衝突しない値に変更する(ステップ４４)。

ロード処理が完了すると、情報格納部１３にバンドル情報を配置し、バンドル情報テーブル５０とシンボリックネーム変更管理テーブル６０に情報を追加する。

ロードされたバンドルは、依存解決処理部１２によって依存バンドルのリンク処理が行われる（ステップ４７）。この際、ロードしたバンドルと依存するバンドルが同フォルダ内のものであれば、バンドル情報テーブル内の各バンドルの依存シンボリックネームを変更後の値に書き換えて、シンボリックネームを変更した同フォルダ内のバンドルを参照できるようにする。

依存するバンドルが同フォルダにあり（ステップ４８でＹｅｓ）、それらが未処理のバンドルであれば（ステップ４９でＹｅｓ）、フォルダ走査部１０はそのバンドルのロード処理を行う（ステップ４６）。

依存するバンドルが同フォルダにない（ステップ４８でＮｏ）、もしくは未処理のバンドルが無ければ（ステップ４９でＮｏ）、他の未処理バンドルのロード処理を行う（ステップ４１へ戻る）。

上記のステップ４３〜４９を繰り返し、サブフォルダ内に未処理のバンドルが無くなったら他のサブフォルダに移動し、ロード処理を行なう(ステップ４１へ戻る)。

以上が工程２のフローである。なお、以上のフローは本実施形態の一例であり、工程２においては、個別バンドル配置フォルダから、バンドルの定義情報の衝突がなく、正しい依存関係でバンドルをロードできさえすればよい。

以上の工程１及び工程２を終えれば、全てのバンドルのロードが完了する。

以上のように、本発明の実施形態に係る衝突回避装置による処理は、フォルダ内のバンドルを連続してロードするだけである。その結果、工程１でロードしたバンドルはモジュール管理基盤全体で共有することができ、工程２でロードしたｉｎｄｉｖｉｄｕａｌｓフォルダ以下のサブフォルダ内のバンドルは、そのフォルダ内にあるバンドルとの依存関係を構成して動作することができる。

本発明では、モジュール管理基盤で管理されたモジュールが同じ空間内で参照されることによる定義情報の衝突や誤参照を、各バンドルが所属するフォルダに基づいて定義情報を変更して空間を分けることで解決する。これにより、バンドルの定義情報の衝突を避けることが出来るほか、バンドルをフォルダで分けることによってモジュール管理基盤上でバンドルの共有化と個別化が実現できる。

また、本発明の実施形態に係るモジュール管理装置によれば、ＯＳＧｉにおいて、バンドルをロードするときにメモリ上で定義情報を書き換えることで衝突を回避したロードを可能とし、正しい依存関係の構築を行なうことができる。

一般に、モジュールを構成するバンドルは、バージョン番号とシンボリックネームのペアが基盤全体で一意である必要がある。そのため、モジュール管理基盤上に同じバージョン番号とシンボリックネームを持つバンドルが既に存在していた場合、後から追加したバンドルは衝突によるエラーでロードされない。

一般的なモジュール管理基盤の設定によっては、衝突が起こりうるバンドルをロードすることも可能である。その場合、ロードした順番で付与されるバンドルＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）というＩＤのみによって区別されることになる。そのため、間違いなく目的のバンドルを特定することが難しくなっている。

このようにして、一般的なモジュール管理基盤においては、衝突したバンドルは管理対象から外れるものの、そのバンドルの使用を想定して追加された他のバンドルは先にロードされていたバンドルと依存関係を構築する。そのため、状況によってはバンドルの参照関係が変わってしまい、想定外の実行結果を招く可能性がある。

これまでは、このような一般的なモジュール管理基盤の問題を解決するために、バンドルのシンボリックネームの衝突を考慮してバンドルを作成し、衝突が発生した際には逐一バンドルを修正する必要があった。

また、一般的なモジュール管理基盤では、例えば、システムのある機能を提供するモジュール群を特定のモジュール管理基盤上に移行した場合、ブラックボックスであるモジュール群に含まれているバンドルがＯＳＳ（Ｏｐｅｎ Ｓｏｕｒｃｅ Ｓｏｆｔｗａｒｅ）などを基にして作られていると、既に登録されていた同じＯＳＳを基にしたバンドルと定義情報の衝突が発生し、登録できない状況が考えられる。

このような状況になると、一般的なモジュール管理基盤では、衝突したバンドルのうち初めに登録されていたバンドルを使用し、そのバンドル内の定義情報に沿って依存関係を構成する。しかしながら、衝突した２つのバンドルが全く同じものであるとはかぎらない。そのため、２つのバンドルが異なる機能を提供していたり、異なるバンドルに依存していたりした場合、モジュール群全体として想定とは異なる依存関係を構成してしまうことで挙動が変わってしまうことになった。

本発明の実施形態では、プログラムを機能ごとに分割したモジュールを一元管理するモジュール管理基盤において、一般的な管理基盤と比べてモジュールを分けて配置し、ロードする順番を変えている。そのため、ロード時にメモリ上で定義情報を動的に変更するモジュール（バンドル）の定義名（シンボリックネーム）の衝突や、それによって引き起こされる誤った依存関係の構築を、モジュール自体を修正することなく回避することができる。

また、本発明の実施形態における定義情報の変更では、例えば、ロード時にバンドルの定義名を変更したり、フォルダ内のバンドルを解析後再構築して１つのバンドルにまとめたり、衝突しない定義情報を付け直す方法を用いてバンドルの定義情報の衝突を回避する。

これによって、これまではモジュールの衝突によって動作しなかったような莫大な数の複雑な依存関係をもったモジュール群の並行動作が可能となり、システムの拡張、運用、保守の容易性が実現できる。なお、本発明の実施形態の説明で用いた例は一例であり、本発明の範囲を限定するものではない。

以下において、実施例をあげて本発明について詳細に説明していく。なお、それぞれの実施例中で用いるバンドル情報テーブルおよびシンボリックネーム変更履歴テーブルは、図５及び図６のテーブルに記載された値とは異なる情報をもつ。しかしながら、項目名や情報を更新する箇所を明示するために、バンドル情報テーブル５０およびシンボリックネーム変更履歴テーブル６０を参照して説明していくが、実際の値を反映させたテーブルの図面は省略する。

（実施例１）
図７〜１０を用いて、実施例１を説明する。実施例１は、モジュール管理基盤Ａ７１で動作しているモジュール群Ａ７２と、モジュール管理基盤Ｂ７３で動作しているモジュール群Ｂ７４を、モジュール管理基盤Ｃ１０１に移植して並行稼働させる例である。

（構成）
図７には、モジュール管理基盤Ａ７１、モジュール管理基盤Ｂ７３におけるバンドルの構成図を示した。図８には、バンドルａ００２、バンドルｂ００２、バンドルｘ００２の関係を示した。図９には、モジュール管理基盤Ｃ１０１が動作する環境におけるバンドルａ００１、ａ００２、ｂ００１、ｂ００２のフォルダ構成を示した。

モジュール群Ａ７２は、バンドルａ００１及びバンドルａ００２から構成されている。バンドルａ００１は、バンドルａ００２のｐというパッケージを参照している。また、モジュール群Ｂ７４は、バンドルｂ００１及びバンドルｂ００２から構成されている。バンドルｂ００１は、バンドルｂ００２のｐというパッケージを参照している。

バンドルａ００２とバンドルｂ００２は、ともにバンドルｘ００２を継承して作られている。そのため、バンドルａ００２及びバンドルｂ００２は、共通のパッケージｐのほか、それぞれ異なるクラスを持つ。また、バンドルａ００２とバンドルｂ００２は、バンドルの定義情報に、共通のシンボリックネームｓｎａｍｅとバージョン番号１．０を持つ。

（動作）
図１０には、実施例１において、バンドルのロード後におけるモジュール管理基盤Ｃ１０１の状態を示す。図１０の上段は、シンボリックネームを変更しない一般例であり、下段はシンボリックネームを変更する本発明に係る実施例である。図１０の上段では、バンドルｂ００１は、後からロードされたバンドルｂ００２を参照すべきところ、先にロードされたａ００２を参照していることを点線の矢印で示しており、その結果バンドルの定義情報の衝突が起こることを模式的に示している。

本発明に係る実施例１の説明を、図１０の下段の図を用いて説明する。

モジュール管理基盤Ｃ１０１が起動すると、フォルダ走査部１０は、あらかじめバンドルの格納先として設定されていたｍｏｄｕｌｅｓフォルダを確認し、バンドルのロードを開始する。

実施例１では、ｍｏｄｕｌｅｓフォルダ内にはバンドルを配置していないので、ロード処理は行なわれない。そのため、フォルダ走査部１０はここでは何も行なわずに、ｉｎｄｉｖｉｄｕａｌｓフォルダ以下のサブフォルダに格納されているバンドルのロードを開始する。

まず、フォルダ走査部１０は、ｉｎｄｉｖｉｄｕａｌｓ/Ａフォルダ以下にあるモジュール群Ａ７２のロードを行なう。

モジュール群Ａ７２のロードでは、Ａフォルダ内のバンドルをロードする際に、定義変更部１４がバンドルのシンボリックネームの先頭に「Ａ」を付加してロードを行なう。その結果、バンドルａ００１のロードでは、バンドルａ００１のシンボリックネームはＡａ００１となる。このとき衝突検知部１５は、図５のバンドル情報テーブル５０と図６のシンボリックネーム変更管理テーブル６０を参照して、ロード済みバンドルと新たにロードするバンドルとの衝突の有無を確認する。

実施例１では、現時点では読み込んだバンドルが無いため、エラーは発生せずにロードが成功する。

バンドルのロード処理が成功すると、情報格納部１３にバンドルを配置し、メモリ上のバンドル情報テーブル５０とシンボリックネーム変更管理テーブル６０に情報を追加する。

バンドルａ００２のロードについても同様に、定義変更部１４がバンドルａ００２のシンボリックネームをＡｓｎａｍｅに変更し、衝突検知部１５が衝突の有無を確認し、情報格納部１３がテーブルへの情報の追加を行なう。

このとき、依存解決処理部１２は、バンドルａ００２がバンドルｂ００１を参照していることを確認し、バンドル情報テーブル５０の依存バンドル名をａ００１からＡａ００１に変更するリンク処理を行う。

次に、フォルダ走査部１０は、ｉｎｄｉｖｉｄｕａｌｓ/Ｂフォルダ以下にあるモジュール群Ｂ７４のロードを行なう。

バンドルｂ００１のロードでは、定義変更部１４がバンドルｂ００１のシンボリックネームをＢｂ００１に変更して、衝突検知部１５でロード済みバンドルとの衝突を確認して、情報格納部１３にバンドル情報の追加を行なう。ここで、バンドルｂ００２のロードでは、定義変更部１４がバンドルｂ００２のシンボリックネームをＢｓｎａｍｅに変更して、衝突検知部１５が衝突の確認をし、情報格納部１３がテーブルへの情報の追加を行なう。また、ここでもバンドルｂ００２はバンドルｂ００１に依存するので、依存解決処理部１２がバンドルｂ００２のバンドル情報テーブル５０における依存バンドル名をｂ００１からＢｂ００１に変更する。

この結果、モジュール群Ａ７２とモジュール群Ｂ７４は、それぞれのバンドル間での依存関係を保ったままモジュール管理基盤Ｃ１０１にロードされ、モジュール管理基盤Ａ７１、モジュール管理基盤Ｂ７３で動作していたように独立して動作する。

実施例１では、ｉｎｄｉｖｉｄｕａｌｓ/Ａフォルダのバンドルａ００２と、ｉｎｄｉｖｉｄｕａｌｓ/Ｂフォルダのバンドルｂ００２のシンボリックネームを変更したことによって、バンドルの定義情報の衝突を回避した（図１０の下段）。仮にシンボリックネームの変更を行なわない場合、バンドルａ００２のシンボリックネームｓｎａｍｅとバンドルｂ００２のシンボリックネームｓｎａｍｅとの間で衝突が発生し、エラーとなっていた（図１０の上段）。

ここで、ｉｎｄｉｖｉｄｕａｌｓ/Ａフォルダ及びｉｎｄｉｖｉｄｕａｌｓ/Ｂフォルダのロードの順番は、モジュール管理基盤の実装に依存する。本発明の実施形態においては、モジュール群Ｂ７４が先にロードされた場合でも、モジュール群Ａ７２内のバンドルでシンボリックネームの変更処理が実行され、動作する。

（実施例２）
実施例２は、モジュール管理基盤で３つのバンドルが動作し、二つのバンドルと参照・被参照関係をもつバンドルのシンボリックネームを変更する例である。

実施例２のフォルダ構成を図１１に、全体構成図を図１２に示す。図１２の上段は、シンボリックネームを変更しない一般例であり、下段はシンボリックネームを変更する本発明の実施形態に係る実施例である。図１２の上段では、バンドルｄ００１は、後からロードされたバンドルｄ００２を参照すべきところ、先にロードされたａ００２を参照していることを点線の矢印で示しており、その結果バンドルの定義情報の衝突が起こることを模式的に示している。

（構成）
図１２の下段図を用いて、実施例２の説明をする。３つのバンドルから構成されるモジュール群Ｄ１１３において、各バンドルをそれぞれバンドルｄ００１、バンドルｄ００２、バンドルｄ００３とする。バンドルｄ００１はバンドルｄ００２のパッケージｐを参照し、バンドルｄ００２はバンドルｄ００３のパッケージｐを参照するものとする。

バンドルｄ００２は、バンドルａ００２及びバンドルｂ００２と同様に、バンドルｘ００２を継承しており、共通のパッケージｐのほか、固有のクラスをもつ。

バンドルｄ００２のバンドル定義情報は、バンドルａ００２と共通のシンボリックネームｓｎａｍｅを持ち、バンドルｄ００２とバンドルａ００２の両方をロードした場合、そのままでは衝突が発生するものとする。

（動作）
本発明に係る実施例２の説明を、図１２の下段の図を用いて説明する。

まず、モジュール管理基盤Ｃ１１１がｍｏｄｕｌｅｓフォルダのロード処理を完了し、モジュール群Ｄ１１３のロード処理を行なう。

モジュール群Ｄ１１３はｉｎｄｉｖｉｄｕａｌｓ/Ｄフォルダに入っている。まず、フォルダ走査部１０によってバンドルｄ００１がロードされる。

定義変更部１４がバンドルｄ００１のシンボリックネームをＤｄ００１に変更し、衝突検知部１５でバンドル定義情報の衝突は発生しないことを確認して、情報格納部１３にバンドル情報を配置してロードが完了する。

バンドルｄ００２のロード処理では、定義変更部１４がｄ００２のシンボリックネームをＤｓｎａｍｅに変更してロードを行なうことで、バンドルｄ００２とバンドルａ００２との衝突を回避する。このとき依存解決処理部１２は、ロード済みであるバンドルｄ００２を参照するバンドルｄ００１に関するメモリ上のバンドル情報テーブル５０の参照先を、Ｄｓｎａｍｅに書き換える。

最後に、バンドルｄ００３のロード処理を実行する。バンドルｄ００３のロード処理では、定義変更部１４がバンドルｄ００３のシンボリックネームをＤｄ００３に変更して、衝突検知部１５で衝突が無いことを確認し、情報格納部１３にバンドルを配置させる。

その後、依存解決処理部１２は、シンボリックネーム変更管理テーブル６０において、依存するバンドルｄ００２のシンボリックネームが変更になっていることを確認して、バンドル情報テーブル５０上におけるバンドルｄ００３の被参照バンドルのシンボリックネーム名をＤｓｎａｍｅに変更する。

このように、バンドルｄ００１及びバンドルｄ００３のバンドルｄ００２に対する参照情報を変更してロード処理を完了する。

（実施例３）
実施例３は、ｉｎｄｉｖｉｄｕａｌｓフォルダ以下のサブフォルダにあるバンドルが、ｍｏｄｕｌｅｓフォルダのバンドルを参照する例である。

実施例３のフォルダ構成を図１３に、ロード処理が完了した時点の全体構成図を図１４に示す。図１４の上段は、シンボリックネームを変更しない一般例であり、下段はシンボリックネームを変更する本発明の実施形態に係る実施例である。図１４の上段では、バンドルｅ００１は、後からロードされたバンドルｅ００２を参照すべきところ、先にロードされたａ００２を参照していることを点線の矢印で示している。その結果、バンドルの定義情報の衝突が起こることを模式的に示している。なお、図１４において、モジュール群Ｅ１４２を２つに分けて描いているのは、それらのバンドルが存在するフォルダの違い、また、シンボリックネームの変更の有無を区別するためである。また、以下の説明においては、モジュール群Ａ７２は、既にロードされていたものとする。

（構成）
モジュール群Ｅ１４２は、バンドルｅ００１、バンドルｅ００２、バンドルｅ００３の３つのバンドルから構成される。バンドルｅ００２は、バンドルａ００２と同様に、バンドルｘ００２から継承して作られているとする。バンドルａ００２とバンドルｅ００２は共通のシンボリックネームｓｎａｍｅを持つため、同時にロードすると衝突が発生するものとする。また、バンドルｅ００１はバンドルｅ００２のパッケージｐを参照し、バンドルｅ００２はバンドルｅ００３を参照する。

ただし、バンドルｅ００３は共通的な機能を提供するバンドルとして、他のバンドルも利用できるものとする。さらにモジュール群Ｅ１４２に属するバンドルは、全てモジュール管理基盤Ｅ（図示しない）においては同ディレクトリに格納されていたとする。なお、バンドルｅ００１、バンドルe００２をｉｎｄｉｖｉｄｕａｌｓ/Ｅフォルダに配置するが、バンドルｅ００３は共通的な機能を提供するバンドルなので、ｍｏｄｕｌｅｓフォルダに配置し、他のバンドルも参照できるようにする。

（動作）
図１４の下段の図を用いて実施例３に係るモジュール管理装置の動作を説明する。

まず、モジュール群Ｅ１４２をモジュール管理基盤Ｃ１４１に移行し、ロードさせる。モジュール管理基盤Ｃ１４１がロード処理を開始すると、まず初めに、フォルダ走査部１０はｍｏｄｕｌｅｓフォルダにあるバンドルｅ００３をロードする。

ｍｏｄｕｌｅｓフォルダでは、シンボリックネームの変更を行なわないので、衝突検知部１５がロード済みバンドルとの衝突がないことを確認し、情報格納部１３にバンドルｅ００３の情報を格納してバンドル情報テーブル５０に追加後、ロード処理を完了する。依存解決処理部１２では、バンドルｅ００３が被参照のみであることを確認する。

これでｍｏｄｕｌｅｓフォルダのバンドルのロードが全て完了する。フォルダ走査部１０の処理は、ｉｎｄｉｖｉｄｕａｌｓフォルダ以下にあるモジュール群のロード処理に移る。

ｉｎｄｉｖｉｄｕａｌｓ/Ｅのロード処理では、まず、定義変更部１４は、バンドルｅ００１のシンボリックネームをＥｅ００１に変更し、衝突検知部１５がバンドルの定義情報の衝突はないことを確認し、ロードは問題なく完了する。

バンドルｅ００２のロードでは、定義変更部１４がバンドルｅ００２のシンボリックネームをＥｓｎａｍｅに変更し、衝突検知部１５が衝突のないことを確認後、情報格納部１３にバンドル情報を格納する。ここで、依存解決処理部１２は、バンドルｅ００２を参照するバンドルｅ００１のバンドル情報テーブル５０の参照情報を更新して、変更後のシンボリックネームを参照するようにする。ただし、バンドルｅ００２が参照していたｍｏｄｕｌｅｓフォルダにあるバンドルｅ００３のメモリ上の参照情報は、バンドルｅ００３が被参照のみであることから変更しない。

これにより、ｉｎｄｉｖｉｄｕａｌｓフォルダ以下にあるサブフォルダ内のバンドルはｍｏｄｕｌｅｓフォルダにある共通機能を持つバンドルｅ００３を参照することができる。

（実施例４）
実施例４は、サブフォルダ内の全バンドルのシンボリックネームを変更する代わりに、ｉｎｄｉｖｉｄｕａｌｓフォルダ以下のサブフォルダごとに空のバンドルを用意し、そのフォルダ内のバンドルを空のバンドル内部に埋め込んで新たなバンドルを作成して、定義情報の衝突を回避する例である。

実施例４では、サブフォルダ内の各バンドルを一度独立したモジュール管理基盤でロードし、バンドル間の依存関係を解決した後に、それらを空のバンドルにバンドル定義情報を持たないモジュールとして埋め込む。

空のバンドルの定義情報には、サブフォルダ名のシンボリックネームを付ける。また、依存情報には、そのフォルダ内のバンドルの外部（サブフォルダ外）への依存だけを抽出して書く。これによって、ｉｎｄｉｖｉｄｕａｌｓフォルダのサブフォルダごとに独立したバンドルを作成し、モジュール管理基盤上で同時にロードしたときに起こるバンドルの定義情報の衝突を回避する。

以下に具体例を用いて説明する。

実施例４のフォルダ構成図を図１５に、全体構成図を図１６に示す。図１６の上段は、シンボリックネームを変更しない一般例であり、下段はシンボリックネームを変更する本発明に係る実施例である。なお、図１６において、モジュール群Ｊ１６２を２つに分けて描いているのは、それらのバンドルが存在するフォルダの違い、またはシンボリックネームの変更の有無を区別するためである。

実施例４では、モジュール管理基盤Ｊ（図示しない）で動作しているモジュール群Ｊ１６２およびモジュール管理基盤Ｋ（図示しない）で動作しているモジュール群Ｋ１６３を、モジュール管理基盤Ｃ１６１で動作させる。

（構成）
モジュール群Ｊ１６２は、バンドルｊ００１、バンドルｊ００２、バンドルｊ００３からなる。バンドルｊ００１は、バンドルｊ００２のパッケージｐに依存し、バンドルｊ００２は、バンドルｊ００３のパッケージｐｐに依存しているものとする。またバンドルｊ００２は、シンボリックネームｓｎａｍｅ、パッケージｐを有し、バンドルｊ００３は、シンボリックネームｓｎａｍｅ２、パッケージｐｐを有する。バンドルｊ００３は一般的な機能を提供するものとする。

モジュール群Ｋ１６３は、バンドルｋ００１、バンドルｋ００２からなり、バンドルｋ００１はバンドルｋ００２のパッケージｐに依存している。バンドルｋ００１はシンボリックネームｋ００１を有し、バンドルｋ００２はシンボリックネームｓｎａｍｅ、パッケージｐを有する。

バンドルｊ００２及びバンドルｋ００２は、バンドルｘ００２を継承して作成されており、共通のパッケージｐのほか独自に開発された機能を含む。

実施例４では、空バンドルｚ１７０を用意する。空バンドルｚ１７０は、バンドル定義情報とモジュールの格納部分を持つが、いずれも空であるとする。

（動作）
図１６の下段の図を用いて実施例４に係るモジュール管理装置の動作を説明する。

まず、モジュール管理基盤Ｃ１６１にモジュール群Ｊ１６２、モジュール群Ｋ１６３を移行させる。ただし、バンドルｊ００３は一般的な機能を提供するため、共通フォルダであるｍｏｄｕｌｅｓフォルダに配置するものとする。

実施例４では、モジュール管理基盤Ｃ１６１上でロード処理を行なう際に、定義変更部１４によってｉｎｄｉｖｉｄｕａｌｓフォルダ以下のサブフォルダをそれぞれ一度独立したモジュール管理基盤Ｃ１６１で読み込みを行なう。その後、バンドル情報の解析を行って、バンドルの再構築処理を行なう。

まず、ｉｎｄｉｖｉｄｕａｌｓ／Ｊフォルダにあるモジュール群Ｊ１６２のロード処理では、バンドルｊ００１、バンドルｊ００２がロードされ、バンドルの定義情報に従ってバンドルｊ００１からバンドルj００２への依存関係が設定される。バンドルj００２からバンドルj００３への依存については、バンドルj００３はｉｎｄｉｖｉｄｕａｌｓ／Ｊフォルダではなく、ｍｏｄｕｌｅｓフォルダにあることから、ここではバンドルｊ００３へ依存している事実だけを確認するものとする。

このとき、空バンドルｚ１７０を用意する。空バンドルｚ１７０は、バンドル定義情報とモジュール格納部分を持つが、それらは現時点では空であるとする。

ここで、前のステップで独立したモジュール管理基盤Ｃ１６１で読み込んだ結果として、バンドルｊ００１、バンドルｊ００２およびそれらの依存関係が判明している。そこで、バンドルｊ００１、バンドルｊ００２からバンドル定義情報を取り出して、モジュール部分だけを空バンドルｚ１７０のモジュール格納部分に配置する。これにより、バンドルｊ００１からバンドルｊ００２への依存関係は、同一のバンドル内に格納することによってロード時に解決されることになる。また、バンドルｊ００３への依存については、空バンドルｚ１７０のバンドル定義部分に依存情報の記述を移す。

このようにして、空バンドルｚ１７０でモジュール群Ｊ１６２を包むことによって、バンドルｚｊ１７１が完成する。ただしバンドルｚｊ１７１のシンボリックネームはフォルダ名Ｊとする。

完成したバンドルｚｊ１７１をモジュール管理基盤Ｃ１６１に移し、衝突検知部１５でバンドル情報テーブル５０を参照して衝突が発生しないことを確認し、ロード処理部１１でロード処理を行なう。

バンドルｚｊ１７１は、バンドルｊ００３のみに依存するバンドルであるので、ロードしたバンドル情報を情報格納部１３に格納した後、バンドル情報テーブル５０に追加する。

その後、依存解決処理部１２で先にロードされているバンドルｊ００３への依存関係を構築し、ロード処理を完了する。ロード処理では、新しく構成したバンドルｚｊ１７１がクラスローダによって読み込まれ、その中身であるモジュールｊ００１、モジュールｊ００２のパッケージがロードされる。

モジュールｊ００１、ｊ００２を単独でロードした場合は、それぞれに一つのクラスローダが使われて、モジュール管理基盤Ｃ１６１を通して参照が行なわれる。それに対して、本実施例のように一つのバンドルに統合した構成では、一つのクラスローダ内でパッケージの参照が行なわれる。

モジュール群Ｋ１６３も同様に空バンドルｚ１７０を使ってシンボリックネームＫをもつバンドルｚｋ１７２を作成し、モジュール管理基盤Ｃ１６１でロードを行なう。

バンドルｚｊ１７１、バンドルｚｋ１７２では、シンボリックネームの衝突は発生せず、誤った依存関係も構築されない。そのため、本発明によりｉｎｄｉｖｉｄｕａｌｓフォルダ以下のモジュール群の独立性を保ちながらロード処理を完了する。

以上の実施例から、本発明の実施形態に係るモジュール管理装置、モジュール管理システム、モジュール管理方法の特徴をまとめると以下のようになる。

モジュール管理基盤においてバンドルの定義情報の衝突を、バンドル本体の修正なく解決できる。

バンドルの定義情報の衝突によって発生していた意図に反したバンドル間の依存関係構築を回避できる。

バンドル間の定義情報の衝突を避けて、複雑な依存関係をもったモジュール群を複数並行稼働することができる。

バンドルの配置場所によって、他のバンドルと共有するバンドル、個別のバンドルに分けることができる。

このように、本発明の実施形態によれば、アプリケーションの更新時におけるバンドルの定義情報の衝突による想定外の依存関係の構成を防ぎ、モジュール群ごとに更新の影響を局所化して、運用、管理、拡張面の容易性を実現することが可能となる。

なお、本発明の実施形態に係る管理方法は、その方法をコンピュータに実行させるプログラム、そのプログラムを用いたソフトウェア・システム、アプリケーションサーバ、アプリケーション等に適用することが可能である。

本発明のモジュール管理装置、モジュール管理システム、モジュール管理方法及びその管理方法を用いたプログラムは、モジュール管理基盤を採用しているアプリケーションサーバの開発および、その上で動作する大規模なアプリケーションの開発に適用できる。例えば、他のモジュール管理基盤上で正常に動作しているモジュール群を移植する場合や、既に構築済みの環境で新規にモジュールを追加する場合に、移行の容易性を実現する。具体的には、モジュール自体の修正を行なわずに、バンドルのシンボリックネームの衝突を回避し、バンドルの共有と個別化を可能とすることによって、移行の容易性を実現することができる。

以上、本発明を上記実施形態及び実施例に即して説明したが、本発明は、上記実施形態の構成や動作にのみ限定されるものではなく、本発明の範囲内で当業者であればなしうることが可能な各種変形、修正を含むことはもちろんである。

１ 衝突回避装置
１０ フォルダ走査部
１１ ロード処理部
１２ 依存解決処理部
１３ 情報格納部
１４ 定義変更部
１５ 衝突検知部
２１ モジュール管理基盤
２２ モジュール群Ａ
２３ モジュール群Ｂ
２４ バンドルａ
２５ バンドルｂ
２６、２９ バンドルｃ
２７ バンドルｄ
２８ バンドルｅ
５０ バンドル情報テーブル
６０ シンボリックネーム変更管理テーブル
７１ モジュール管理基盤Ａ
７２ モジュール群Ａ
７３ モジュール管理基盤Ｂ
７４ モジュール群Ｂ
１０１、１１１、１４１、１６１ モジュール管理基盤Ｃ
１１３ モジュール群Ｄ
１４２ モジュール群Ｅ
１６２ モジュール群Ｊ
１６３ モジュール群Ｋ
１７０ 空バンドルｚ
１７１ バンドルｚｊ
１７２ バンドルｚｋ

Claims (9)

1. オブジェクト指向言語で記述されたプログラムからなるモジュール及び前記モジュールの属性を含む定義情報を有するバンドルを配置したフォルダを走査するフォルダ走査部と、
   前記バンドルの読み込みを行うロード処理部と、
   前記バンドルの参照関係を整合させる依存解決処理部と、
   前記バンドルの情報を格納する情報格納部と、
   前記バンドルの前記定義情報を変更する定義変更部と、
   前記定義変更部で変更された前記定義情報によって衝突が起こるか否かを検知する衝突検知部と、を備え、
   前記バンドルと、複数の前記バンドルからなるモジュール群と、を一元管理するモジュール管理基盤の起動時において前記バンドルを前記フォルダからロードする際に、
   異なる前記バンドル間で前記定義情報が衝突する場合、
   前記定義変更部は、前記定義情報を動的に変更し、
   前記依存解決処理部は、前記バンドルの参照関係を整合し、
   前記衝突検知部は、前記ロード処理部によってロード済みの前記バンドルの第１の定義情報と、前記フォルダ走査部によって検出された未処理の前記バンドルの第２の定義情報とが衝突するか否かを検証し、
   前記第１の定義情報と前記第２の定義情報とが衝突する場合、
   前記定義変更部は、前記第２の定義情報を新たな第３の定義情報に変更し、
   前記依存解決処理部は、前記第１の定義情報と前記第３の定義情報との参照関係を整合し、
   前記情報格納部は、前記第３の定義情報に関する情報及び参照関係を更新することを特徴とするモジュール管理装置。
2. 前記定義情報は、前記バンドルのシンボリックネームであることを特徴とする請求項１に記載のモジュール管理装置。
3. 前記定義変更部は、前記シンボリックネームを変更する際に、前記バンドルが格納されている前記フォルダの名前に応じた記号を前記シンボリックネームに付与することを特徴とする請求項２に記載のモジュール管理装置。
   
4. さらに、異なる前記バンドル間におけるお互いの参照関係と前記シンボリックネームとを含む第１のテーブルと、
   前記バンドルのファイルパスに対応させた前記定義情報の変更履歴を含む第２のテーブルと、を備え、
   前記第１及び第２のテーブル上の前記定義情報を変更することを特徴とする請求項３に記載のモジュール管理装置。
5. 前記バンドルを外部のアプリケーションによって共有化できるように格納する共通フォルダと、前記バンドルを外部のアプリケーションによって共有化されないように格納する個別フォルダとから、前記バンドルをロードする際に、
   前記共通フォルダからは前記バンドルを公開できる状態でロードし、前記個別フォルダからは前記バンドルを公開されない状態でロードすることを特徴とする請求項１乃至４のいずれか一項に記載のモジュール管理装置。
6. 同一の前記モジュール群に含まれる複数の前記バンドルを、前記共通フォルダと前記個別フォルダに振り分けてロードすることを特徴とする請求項５に記載のモジュール管理装置。
7. 定義情報及びモジュール格納部分が空白である空バンドルに、複数の前記バンドルに含まれるモジュールを前記バンドルの参照関係を維持したままで配置し、前記空バンドルに対して衝突が起こらない定義情報を与え、前記定義情報の参照関係を整合することを特徴とする請求項１乃至６のいずれか一項に記載のモジュール管理装置。
8. 前記モジュール管理装置を備えることを特徴とする請求項１乃至７のいずれか一項に記載のモジュール管理システム。
9. オブジェクト指向言語で記述されたプログラムからなるモジュール及び前記モジュールの属性を含む定義情報を有するバンドルを配置したフォルダを走査し、
   前記バンドルの読み込みを行い、
   前記バンドルの参照関係を整合させ、
   前記バンドルの情報を格納し、
   前記バンドルの前記定義情報を変更し、
   変更された前記定義情報によって衝突が起こるか否かを検知し、
   前記バンドルと、複数の前記バンドルからなるモジュール群と、を一元管理するモジュール管理基盤の起動時において前記バンドルを前記フォルダからロードする際に、
   異なる前記バンドル間で前記定義情報が衝突する場合、
   前記定義情報を動的に変更し、前記バンドルの参照関係を整合し、
   ロード済みの前記バンドルの第１の定義情報と、検出された未処理の前記バンドルの第２の定義情報とが衝突するか否かを検証し、
   前記第１の定義情報と前記第２の定義情報とが衝突する場合、
   前記第２の定義情報を新たな第３の定義情報に変更し、
   前記第１の定義情報と前記第３の定義情報との参照関係を整合し、
   前記第３の定義情報に関する情報及び参照関係を更新することを特徴とするモジュール管理方法。

Images