(57)【要約】【課題】  設計者個人の経験や能力に大きく依存しないディレクトリ設計を可能とするディレクトリ設計支援装置を得る。【解決手段】  設計支援部１０が、ユーザにＧＵＩを提供してディレクトリ設計情報の入力を促し、データ抽出部２０が入力データに基づいてディレクトリ設計データを生成し、ディレクトリ構成部３０がディレクトリ設計データに基づいて、６つのディレクトリ構造パターンの中から最適なディレクトリ構成を決定し、出力部４０が決定されたディレクトリ構成を出力する。【選択図】        図１
2005092612.tif 000002
【特許請求の範囲】
【請求項１】
ディレクトリ設計情報の入力インタフェースを提供し、入力されたデータを取得する設計支援部と、
上記入力されたデータに基づいてディレクトリ構造の決定に必要なデータを抽出するデータ抽出部と、
上記データ抽出部において抽出されたデータに基づいてディレクトリ構造を決定するディレクトリ構成部と、
上記ディレクトリ構成部で決定されたディレクトリ構造を通知する出力部とを備えたディレクトリ設計支援装置。
【請求項２】
設計支援部が提供するディレクトリ設計情報の入力インタフェースは、オブジェクト指向の静的モデルの表記方法により、ディレクトリシステムで管理される情報をオブジェクトで表し、それらのオブジェクトの関連情報をクラス間の関係として入力させる部分を有することを特徴とする請求項１記載のディレクトリ設計支援装置。
【請求項３】
設計支援部が提供するディレクトリ設計情報の入力インタフェースは、相手クラスの１つのオブジェクトに対して１つのオブジェクトが対応するか、あるいは複数のオブジェクトが対応するかを表す多重度を入力させる部分を有し、
相手クラスの１つのオブジェクトに対して複数のオブジェクトが対応する場合に、対応するオブジェクト数の平均を表す平均値を入力させる部分を有することを特徴とする請求項２記載のディレクトリ設計支援装置。
【請求項４】
設計支援部が提供するディレクトリ設計情報の入力インタフェースは、クラス間の関連に条件が存在するか否かの情報を入力させる部分を有することを特徴とする請求項２記載のディレクトリ設計支援装置。
【請求項５】
ディレクトリ構成部は、有限複数のディレクトリ構造パターンの中から、１つのディレクトリ構造を選択することにより、ディレクトリ構造を決定することを特徴とする請求項１から請求項４のうちのいずれか１項記載のディレクトリ設計支援装置。
【請求項６】
ディレクトリ構成部は、インデックス機能を実装したディレクトリシステムでは、そのインデックス機能が効果的に機能するか否かの情報に基づいて、ディレクトリ構造を決定することを特徴とする請求項１から請求項５のうちのいずれか１項記載のディレクトリ設計支援装置。
【請求項７】
入力されたディレクトリ設計情報に基づいてコンピュータが生成し、コンピュータがディレクトリ構造を決定するために用いるディレクトリ設計データのデータ構造であって、
ディレクトリシステムで管理される情報をオブジェクトで表したときのクラス名と、
相手クラスの１つのオブジェクトに対して１つのオブジェクトが対応するか、あるいは複数のオブジェクトが対応するかを表す多重度と、
相手クラスの１つのオブジェクトに対して複数のオブジェクトが対応する場合に、対応するオブジェクト数の平均を表す平均値と、
クラス間の関連に条件が存在するか否かを表す条件有無情報と、
クラスが持つ属性情報とを含むことを特徴とするディレクトリ設計データのデータ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ネットワーク上の情報資源を管理するディレクトリシステムを構築するディレクトリ設計支援装置、およびそのディレクトリ設計支援装置で利用するディレクトリ設計データ構造に関するものである。
【背景技術】
【０００２】
近年、ネットワーク上の情報資源を効率的に管理するディレクトリシステム（ディレクトリサービス）の利用が拡大しつつある。ディレクトリが利用され始めた当初は、運用管理ツールなどによるネットワーク接続されたコンピュータ等の資源の管理や、利用者の権限を管理するための手段として利用されていた。例えば、ネットワークＯＳによってネットワークを利用するユーザやネットワークに接続されるコンピュータ・機器を管理する際の手段に使用されていた。従って、一般的にはユーザがディレクトリを意識することはほとんどなかった。
【０００３】
しかし、ディレクトリの標準化が進んで世の中に認知され始め、企業の情報システムの情報を管理することをコンセプトとしたディレクトリ製品がリリースされるようになった。このような製品は、リレーショナルデータベースと同等の管理機能をサポートしていることが特徴である。このような状況で、企業の情報システムを構築する道具としてディレクトリが利用され始め、ディレクトリ設計の良し悪しがシステムの成功に大きく関与し始めている。
【０００４】
しかし、ディレクトリスキーマの設計においては標準的な設計モデルがなく、現状は使用目的や要件から直接ディレクトリスキーマを定義している。
【０００５】
なお、従来の、ディレクトリシステムのデータをアプリケーションシステムで利用する例として、特許文献１に開示されたディレクトリデータ変換方法がある。特許文献１に開示されたディレクトリデータ変換方法は、ディレクトリサーバに格納されたディレクトリデータを、アプリケーションプログラムで用いられるデータのスキーマに合わせて変換し、アプリケーションプログラムのデータとして反映させるものである。
【０００６】
【特許文献１】特開２０００−１６３３０３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
従来のディレクトリ構造の設計技術では、ディレクトリ設計者とユーザ間での円滑な意思疎通を実現できず、ユーザにとっては所望のディレクトリ構成を設計することが困難となっている。また、現状ではディレクトリ設計の方法論が確立していないため、設計されたディレクトリ構成の完成度は設計者個人の経験や能力に大きく依存してしまう。例えば、リレーショナルデータベースでは「正規化」という方法論が確立されており、このような課題はおおむね解消できている。ディレクトリ設計においても、ユーザとの合意の下に適切なディレクトリスキーマを設計する技法が必要である。
【０００８】
この発明は上記のような課題を解決するためになされたもので、第１の目的は、設計者個人の経験や能力に大きく依存しないディレクトリ設計を可能とするディレクトリ設計支援装置、およびそのディレクトリ設計支援装置で利用するディレクトリ設計データ構造を得るものである。
【課題を解決するための手段】
【０００９】
この発明に係るディレクトリ設計支援装置は、ディレクトリ設計情報の入力インタフェースを提供し、入力されたデータを取得する設計支援部と、入力されたデータに基づいてディレクトリ構造の決定に必要なデータを抽出するデータ抽出部と、データ抽出部において抽出されたデータに基づいてディレクトリ構造を決定するディレクトリ構成部と、ディレクトリ構成部で決定されたディレクトリ構造を通知する出力部とを備えたものである。
【発明の効果】
【００１０】
この発明のディレクトリ設計支援装置によれば、利用者にディレクトリ設計情報の入力インタフェースを提供し、入力されたデータを取得する設計支援部と、入力されたデータに基づいてディレクトリ構造の決定に必要なデータを抽出するデータ抽出部と、データ抽出部において抽出されたデータに基づいてディレクトリ構造を決定するディレクトリ構成部と、ディレクトリ構成部で決定されたディレクトリ構造を出力する出力部とを備えたので、設計者個人の経験や能力に大きく依存せず、ディレクトリの利用目的に適合したディレクトリの構築が可能となる。
【発明を実施するための最良の形態】
【００１１】
以下、この発明の実施の形態を説明する。
実施の形態１．
実施の形態１のディレクトリ設計支援装置が対象とするディレクトリサービスシステムは、ＣＣＩＴＴ（Ｃｏｎｓｕｌｔａｔｉｖｅ  Ｃｏｍｍｉｔｔｅｅ  ｆｏｒ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｐｈｏｎｙ  ａｎｄ  Ｔｅｌｅｇｒａｐｈｙ）勧告のＸ．５００で定義される構造を持ち、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）で定義されているＬＤＡＰ（Ｌｉｇｈｔｗｅｉｇｈｔ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）のインタフェースを有するものとする。
【００１２】
図１は、この発明の実施の形態１によるディレクトリ設計支援装置１００の構成を示すブロック図である。
図に示すように、ディレクトリ設計支援装置１００は、設計支援部１０、データ抽出部２０、ディレクトリ構成部３０、出力部４０、ディレクトリモデル記憶部５０を備えている。
設計支援部１０、データ抽出部２０、ディレクトリ構成部３０、及び出力部４０は、ディレクトリ設計支援装置１００のプロセッサを、プロセッサの動作を制御するプログラムのモジュールに従って便宜的に分割したものである。
【００１３】
また、ディレクトリモデル記憶部５０は、後述するディレクトリ構造パターンのデータが格納されている記憶装置である。
【００１４】
次に、ディレクトリ設計支援装置１００の動作について説明する。
設計支援部１０は、例えばＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）を利用して、ユーザが入力装置（図示せず）を介して行うディレクトリ設計情報の入力を支援する。ユーザは、設計支援部１０によってディスプレイ（図示せず）に表示されるＧＵＩを利用して、設計対象となるディレクトリシステムの情報を入力する。
【００１５】
図２は、実施の形態１による、設計支援部１０によって提供されるＧＵＩを説明する図である。実施の形態１では、ユーザが設計対象となるディレクトリシステムをオブジェクト指向の静的モデルを利用してモデル化することができるようになっている。ここでは、ディレクトリシステムで管理される組織や人などの情報をそれぞれオブジェクトとしてとらえ、各々のオブジェクトを総称するクラス間の関係により、ディレクトリシステムの構造を表現するようになっている。
【００１６】
図２において、クラス２１及びクラス２２は、ディレクトリシステムで管理される組織や人などのオブジェクトを総称するクラスを表す。クラス２１及びクラス２２には、それぞれクラス名２１１、クラス名２２１が設定される。クラス２１及びクラス２２は、１つ以上の属性２１３及び属性２２３を有する。属性２１３及び属性２２３は、クラス２１及びクラス２２に属するオブジェクトの属性の集合である。属性２１３及び属性２２３には、それぞれ属性名２１４及び属性名２２４が設定される。
多重度２１５及び多重度２２５は、クラス２１とクラス２２の間の関係を表す情報である。多重度２１５及び多重度２２５には、平均値および条件有無情報が含まれる。平均値は、多重度が１でない場合、すなわち、親子関係にあるクラスのうちの子クラスのように、相手クラスの１つのオブジェクトに対して、複数のオブジェクトが関連する場合に、その関連するオブジェクト数の平均を表す値である。条件有無情報は、２つのクラス間の関連に条件があるかどうかを表す
関連２３はクラス２１とクラス２２が関連することを表す記号である。
【００１７】
具体的な入力方法について説明する。
図２において、例えば、一方のクラス２１（親クラス）のオブジェクトが、他方のクラス２２（子クラス）の複数のオブジェクトと関連する場合、親クラス側の多重度２１５は「１」、子クラス側の多重度２２５は、関連するオブジェクトが複数であることを表す「＊」に設定する。また、多重度２１５（「１」）の付加情報の平均値は「１」とし、多重度２２５（「＊」）の平均値はその多重の平均値を指定する。また、条件有無情報については、親クラス側（クラス２１）は「無」とする。子クラス側（クラス２２）については、親クラスのそれぞれのオブジェクトが子クラスとの関連において条件設定できる場合「有」、設定できない場合「無」とする。条件設定ができる場合とは、例えば、ある親オブジェクトと関連する子オブジェクトの条件として、「子オブジェクトの属性２２３−１がＡかつ属性２２３−２がＢ」等の条件が設定できる場合である。また、クラス２１及びクラス２２の多重度が共に「＊」の場合、すなわち、２つのクラスが多対多の関係である場合には、多重度の平均値が小さいクラスを親クラスとし、もう一方のクラスを子クラスとして設定する。
【００１８】
ユーザによるディレクトリ設計情報の入力が完了すると、データ抽出部２０は、図２で示したモデルを利用して記述されたディレクトリ構造から、任意の関連する２つのクラスと関連情報を抽出し、ディレクトリ設計のためのディレクトリ設計データを生成する。
図３は、データ抽出部２０によって生成されるディレクトリ設計データの内容を示す図である。
図中、クラス情報３１は図２におけるクラス２１についての情報、クラス情報３２は図２におけるクラス２２についての情報である。クラス名３１１は図２のクラス名２１１、多重度３１５は多重度２１５、平均値３１６は多重度２１５の平均値、条件有無情報３１７は多重度２１５の条件有無情報、属性３１３ａ、属性３１３ｂ・・・は、属性２１３の情報である。同様に、クラス名３２１は図２のクラス名２２１、多重度３２５は多重度２２５、平均値３２６は多重度２２５の平均値、条件有無情報３２７は多重度２２５の条件有無情報、属性３２３ａ、属性３２３ｂ・・・は、属性２２３の情報である。図２の関連２３で表されるクラス間の関連は、リンク３３で表される。
【００１９】
次に、ディレクトリ構成部３０は、データ抽出部２０から出力されたディレクトリ設計データを用いてディレクトリ構造の決定処理を行う。
ディレクトリ構成部３０は、データ抽出部２０から出力されたディレクトリ設計データに含まれる任意の関連する２つのクラスの情報（例えば、図３のクラス情報３１とクラス情報３２）を抽出し、それらの２クラス間の適切なディレクトリスキーマを決定する。ディレクトリスキーマ構造の決定は、ディレクトリ設計データに含まれるすべての関連する２クラスの組について行う。
【００２０】
図４は、この発明の実施の形態１による、ディレクトリ構成部３０における、関連する２つのクラス間のディレクトリ構造決定処理のフローチャートである。図４に示す処理は、上述したように、すべての関連する２つのクラスの組についての処理が終了するまで、繰り返し行われる。
【００２１】
まず、ディレクトリ構成部３０は、ディスプレイ等を介して、ユーザに、設計対象のディレクトリサービスシステムにおいて、インデックス機能が有効に機能するかどうかの入力を要求する（ステップＳＴ１）。
【００２２】
次に、図３で示したディレクトリ設計データ上の多重度３１５と多重度３２５を参照し、少なくともどちらか一方の値が「１」であるかどうかを判定する（ステップＳＴ２）。
【００２３】
ステップＳＴ２で多重度３１５及び多重度３２５のどちらかの値が「１」と判定された場合には、多重度が１である方のクラスを親クラスとする。ここでは、多重度３１５が「１」であるとし、クラス情報３１を親クラスとする（ステップＳＴ３）。
【００２４】
また、ステップＳＴ３で親クラスとしなかった方のクラスを子クラスとする（ステップＳＴ４）。ここではクラス情報３２を子クラスとする。
【００２５】
次に、クラス名３１１とクラス名３２１が同一かどうかを判定する（ステップＳＴ５）。
【００２６】
ステップＳＴ５でクラス名３１１とクラス名３２１が同一であると判定された場合には、再帰的な関係にある２つのクラス間の場合に適したディレクトリ構造である、パターン１のディレクトリ構成を選択する（ステップＳＴ７）。
【００２７】
実施の形態１では、ディレクトリ構成部３０は、予め決められた６つのディレクトリ構造パターンの中から、２つのクラスのディレクトリ設計データに基づいて、最も適したパターンを選択する。この６つのディレクトリ構造パターンは、一般的にディレクトリシステムの構造（ディレクトリスキーマ）として利用される６種類であり、この中から最適なディレクトリ構造を選択することにより、有効なディレクトリ設計が可能になると考えられる。
図５から図１０は、実施の形態１によるディレクトリ構成部３０で選択される６つのディレクトリ構造パターンを図示したものである。図５〜図１０は、それぞれパターン１〜パターン６の構造を模式的に表したものである。
【００２８】
図中、エントリ１１は、親クラスに属する１つのオブジェクトに対応する。エントリ１２は、その親クラスに関連する子クラスのオブジェクトに対応する。関係１３は、上位エントリが下位エントリの直接の上位エントリであることを表している。エントリ１４は第３のエントリで、これは、ディレクトリシステムの物理的な構成を作成する際に発生するエントリ（オブジェクト）であり、論理モデル上には存在しない。属性１５は、親エントリの識別子を値としてもつ子エントリの属性である。属性１６は親エントリまたは子エントリのＤＮ（Ｄｉｓｔｉｎｇｕｉｓｈｅｄ  Ｎａｍｅ）を値としてもつ属性である。属性１７はエントリの一般属性であり、属性１８は関連条件を値としてもつ属性である。なお、属性１７及び属性１８は、ユーザがディレクトリ構成情報の入力の際に設定した、元々定義されている属性である。
【００２９】
図５のパターン１から図７のパターン３は、クラス間の関連が１対多の場合に選択されるディレクトリ構造を示している。
図５に示すパターン１（直接リンク構造）は、親エントリと子エントリが同一のクラスの場合、すなわち再帰的に１対多となる場合に選択される。１対多の関係はこの直接リンク構造を適用することができるが、例えば、親クラス、子クラスおよび第３のクラスの関連が１対多対１の場合、子エントリが２つ以上の直接上位エントリをもつことができないため、この構造は選択できない。従って、原則的にはこの構造を選ぶべきではない。
【００３０】
図６に示すパターン２（間接リンク構造）は、子エントリが親エントリの識別子を属性としてもつ構造である。識別子とは、同一クラスのオブジェクトを一意に識別するためにオブジェクトが持つ属性をいう。例えば、社員クラスにおける社員番号や、組織クラスにおける組織コードなどが該当する。間接リンク構造は、親エントリから子エントリを検出するとき、子クラスに対応するすべての子エントリをスコープとして、当該親エントリの識別子をもつ子エントリを検索することを前提としたスキーマ構造である。このとき、性能上の観点から、ディレクトリサービスシステムが、子エントリの持つ親属性に付すことができるインデックス機能を有しかつ有効に機能することが必要であるため、インデックス機能を有することが前提となる。
【００３１】
図７に示すパターン３（ＤＮ情報リンク構造）は、親エントリと子エントリのそれぞれに関連する相手のエントリのＤＮを属性としてもつ構造である。１対多のディレクトリ構造としてはもっとも基本的な構造であり、パターン１とパターン２を選択する条件に合致しない１対多の関係では、すべてこの構造を選択する。
【００３２】
図８のパターン４から図１０のパターン６は、クラス間の関連が多対多の場合に選択されるディレクトリ構造を示している。
図８に示すパターン４（動的グループ構造）は、親クラスの個々のオブジェクトが、関連する子クラスのオブジェクトとの関連の条件を、子クラスの持つ属性の属性値を指定することにより定義できる場合に選択されるディレクトリ構造である。この動的グループ構造は、子エントリの追加・削除の際に親エントリがもつ関連条件に関する属性の値を変更する必要がないという利点がある。
【００３３】
図９に示すパターン５（多対多間接リンク構造）は、クラス間の関連が１対多の場合に選択するパターン２を多対多の関連に適用した構造である。子エントリは、複数の親エントリの識別子を属性として持つ。これにより、多対多の関係を表現する。このとき、性能上の観点から、ディレクトリサービスシステムが、子エントリの持つ親エントリの識別子に付すことができるインデックス機能を有しかつ有効に機能することが必要であるため、インデックス機能を有することが前提となる。
【００３４】
図１０に示すパターン６（静的グループ構造）は、クラス間の関連が１対多の場合に選択するパターン３を多対多に適用したスキーマ構造である。子エントリは、属性として親エントリのＤＮを複数持つ。これにより、多対多の関係を表現する。多対多の場合のディレクトリスキーマ構造としてはもっとも基本的な構造であり、パターン４とパターン５を選択する条件に合致しない多対多の関係では、すべてこの構造を選択する。
【００３５】
以上のように、パターン１からパターン６のディレクトリ構造はそれぞれの特長を有しているため、図４に示す処理に従い、適切なディレクトリ構造を決定する。
【００３６】
ステップＳＴ５でクラス名３１１とクラス名３２１が相違していると判定された場合には、ステップＳＴ６へ進み、ステップＳＴ１での入力内容に基づいて、インデックス機能が有効であるかどうかを判定する。
【００３７】
ステップＳＴ６でインデックス機能が有効と判定された場合には、パターン２のディレクトリ構造を採用する（ステップＳＴ８）。
【００３８】
また、ステップＳＴ６でインデックス機能が有効に機能しないと判定された場合には、パターン３のディレクトリ構造が選択される（ステップＳＴ９）。
【００３９】
一方、ステップＳＴ２で多重度３１５及び多重度３２５のどちらの値も「１」ではないと判定された場合には、多重度の平均値が小さい方のクラスを親クラスとする。例えば、多重度３１５の平均値が多重度３２５の平均値よりも小さい場合には、クラス情報３１を親クラスとする（ステップＳＴ１０）。
【００４０】
また、ステップＳＴ１０で親クラスとしなかった方のクラスを子クラスとする（ステップＳＴ１１）。例えば、クラス３１が親クラスと設定された場合には、クラス情報３２を子クラスとする。
【００４１】
次に、ステップＳＴ１での入力内容に基づいて、インデックス機能が有効であるかどうかを判定する（ステップＳＴ１２）。
【００４２】
ステップＳＴ１２でインデックス機能が有効ではないと判定された場合には、パターン６のディレクトリ構造を採用する（ステップＳＴ１４）。
【００４３】
ステップＳＴ１２でインデックス機能が有効であると判定された場合には、ステップＳＴ１３へ進み、子クラス側の条件有無情報の有無を判定する。例えば、クラス３２が子クラスの場合には、条件有無情報３２７を参照する。
【００４４】
ステップＳＴ１３で、子クラスの条件有無情報が「有」と判定された場合には、パターン４のディレクトリ構造を採用する（ステップＳＴ１５）。
【００４５】
また、ステップＳＴ１３で、子クラスの条件有無情報が「無」と判定された場合には、パターン５のディレクトリ構造を選択する（ステップＳＴ１６）。
【００４６】
以上の処理を、すべての関連する２つのクラスの組についての処理が終了するまで、繰り返し行う。
【００４７】
図１１から図１４に、図２で示す入力インタフェースを用いたディレクトリモデルの入力例を示す。図中、図２と同一の符号は、同一の要素を表している。
図１１の入力例は、図に示すように多重度が１対多で、両者のクラスが同一であるので、図４のステップＳＴ７において、パターン１の直接リンク構造が選択される。
【００４８】
図１２の入力例は、多重度が１対多で、両者のクラスが同一ではないので、図４のステップＳＴ８またはステップＳＴ９において、パターン２かパターン３のディレクトリ構造が採用される。インデックス機能が有効に機能するときはパターン２の間接リンク構造が採用され、有効に機能しないときはＤＮ情報リンク構造が採用される。
【００４９】
図１３及び図１４の入力例は、多重度が多対多であるので、インデックス機能が有効に機能しないときは、ステップＳＴ１４においてパターン６の静的グループ構造が選択される。また、インデックス機能が有効に機能するときは、図１３は子クラス側の条件有無情報が「無」であるため、ステップＳＴ１６においてパターン５の多対多間接リンク構造が選択される。一方、図１４については、インデックス機能が有効に機能するときは、子クラス側の条件有無情報が「有」であるため、ステップＳＴ１５においてパターン４の動的グループ構造が選択される。
【００５０】
ディレクトリ構成部３０で決定された、各々のクラス間のディレクトリ構造パターンは、出力部４０によって、ディスプレイ等に出力される。ディスプレイ上には、図５から図１０に示す各パターンの模式図が表示される。ただし、各親エントリ１１及び子エントリ１２には、図１３のディレクトリ設計データ上の対応するクラス名が表示される。また、属性１５及び属性１６の値には、対応する親エントリまたは子エントリのクラス名が表示される。
なお、図８に示す属性１８は、ユーザがディレクトリ構成情報の入力の際に設定した、元々定義されている属性であり、決定されたディレクトリ構造としては、ここでは出力されない。
【００５１】
以上のように、この実施の形態１によれば、設計支援部１０が、ユーザにＧＵＩを提供してディレクトリ設計情報の入力を促し、データ抽出部２０が入力データに基づいてディレクトリ設計データを生成し、ディレクトリ構成部３０がディレクトリ設計データに基づいて、６つのディレクトリ構造パターンの中から最適なディレクトリ構成を決定し、出力部４０が決定されたディレクトリ構成を出力するようにしたので、設計者個人の経験や能力に大きく依存せず、ディレクトリの利用目的に適合したディレクトリの構築が可能となる。
【００５２】
また、実施の形態１によれば、設計支援部１０は、ディレクトリシステムで管理される情報の構成が理解しやすい静的オブジェクトモデルの表記方法に基づいてディレクトリ設計情報を指定できるＧＵＩを提供するようにしたので、ディレクトリの設計者とディレクトリユーザの設計段階での意思疎通が容易になるという効果がある。
【００５３】
また、設計者が入力するディレクトリ設計情報として、クラス（エントリ）間の多重度の平均値を含め、それに基づいてエントリ間の親子関係を決定するようにしたので、適切なディレクトリ構造を決定できるという効果がある。
【００５４】
また、設計者が入力するディレクトリ設計情報として、クラス間の関連に条件が存在するか否かの情報（条件有無情報）を含めるようにしたので、ディレクトリ構造として典型的な動的グループ構造を選択する条件として利用することができる。
【００５５】
また、ディレクトリ構成部３０において、経験上ディレクトリ構造として適切であることが知られている６種類のディレクトリ構造の中から、最も適切なディレクトリ構造を選択するようにしたので、不適切なディレクトリ構造が選択されることを防止する効果がある。
【００５６】
また、クラス間の多対多構造をディレクトリ設計情報として記述可能とすることによって、アクセス制御情報管理の目的に適したディレクトリ構造を選択できるという効果がある。
【００５７】
また、ディレクトリサービスが検索性能向上のためにインデックス機能を実装しており、かつ効果的に機能するか否かを、ディレクトリ設計情報に含めるようにしたので、より、実践的なディレクトリ構造を決定できるという効果がある。
【００５８】
また、関連するクラスが同一クラス、すなわち再帰的な関係にある場合のディレクトリ構造を決定可能とすることによって、組織などの階層的な情報を管理するのに適したディレクトリ構造を選択できるという効果がある。
【産業上の利用可能性】
【００５９】
この発明は、設計者個人の経験や能力に大きく依存しないディレクトリ設計を可能とするディレクトリ設計支援装置として利用することができる。
【図面の簡単な説明】
【００６０】
【図１】この発明の実施の形態１による、ディレクトリ設計支援装置の構成を示すブロック図である。
【図２】この発明の実施の形態１による、ディレクトリ設計情報の入力インタフェースを説明する図である。
【図３】この発明の実施の形態１による、ディレクトリ設計情報を基に生成されるディレクトリ設計データの構成を示す図である。
【図４】この発明の実施の形態１による、ディレクトリ構造決定処理のフローチャートである。
【図５】この発明の実施の形態１による、ディレクトリ構造パターン１の構造を示す図である。
【図６】この発明の実施の形態１による、ディレクトリ構造パターン２の構造を示す図である。
【図７】この発明の実施の形態１による、ディレクトリ構造パターン３の構造を示す図である。
【図８】この発明の実施の形態１による、ディレクトリ構造パターン４の構造を示す図である。
【図９】この発明の実施の形態１による、ディレクトリ構造パターン５の構造を示す図である。
【図１０】この発明の実施の形態１による、ディレクトリ構造パターン６の構造を示す図である。
【図１１】１対多のディレクトリ設計情報の具体的な入力例を示す図である。
【図１２】１対多のディレクトリ設計情報の具体的な入力例を示す図である。
【図１３】多対多のディレクトリ設計情報の具体的な入力例を示す図である。
【図１４】多対多のディレクトリ設計情報の具体的な入力例を示す図である。
【符号の説明】
【００６１】
１０  設計支援部、２０  データ抽出部、３０  ディレクトリ構成部、４０  出力部、５０  ディレクトリモデル記憶部、１００  ディレクトリ設計支援装置。
【図１】
2005092612.tif 000003
【図２】
2005092612.tif 000004
【図３】
2005092612.tif 000005
【図４】
2005092612.tif 000006
【図５】
2005092612.tif 000007
【図６】
2005092612.tif 000008
【図７】
2005092612.tif 000009
【図８】
2005092612.tif 000010
【図９】
2005092612.tif 000011
【図１０】
2005092612.tif 000012
【図１１】
2005092612.tif 000013
【図１２】
2005092612.tif 000014
【図１３】
2005092612.tif 000015
【図１４】
2005092612.tif 000016