JP2009199612A - 情報管理装置および方法、記録媒体 - Google Patents

Abstract

【課題】
構造を持った情報の当該構造を簡単な作業で自由に定義することができ、多人数による共同作業にも対応可能なシステムを提供する。
【解決手段】
情報の構造定義を入力する構造定義入力手段１と、入力された構造定義に従って情報の実体および実体間の関連を表すデータ定義を入力するデータ定義入力手段２と、入力された定義や制約事項を解析してＥＲモデルに変換するモデル化手段４とを設け、どのような形で定義を入力しても同じＥＲモデルを得ることができるようにする。これにより、情報の複雑な構造を完全に意識することなくユーザが書きやすいように自由に定義を行えるようにするとともに、関連付けも両方向から行わなくても済むようにすることにより、情報の構造を自由かつ簡単に定義できるようにする。
【選択図】 図１

Description

本発明は情報管理装置および方法、更にはこれらを実現するためのプログラムを格納した記録媒体に関し、特に、関連あるいは構造を持った情報の作成・管理・利用支援を行うためのシステムに用いて好適なものである。

一般に、システム開発を行ったり、開発されたシステムを使って作業を行ったりする際には、種々の情報が使用される。そしてこれらの情報は、実際には個々が単に独立したものとして存在するのではなく、他の情報との関連を持って存在することが多い。また、システム開発等の分野に限らず、それ以外の様々な分野においても（例えば、プレゼンテーション用資料やオンラインマニュアル等の各種ドキュメント、住所録や用語辞書等の各種データベースの作成を行う際にも）、使用される情報は互いに関連を持っていることが多い。

この場合、そのような関連、つまり構造を持った情報をコンピュータにて管理すること、しかもその管理を円滑に行えるようにすることが望まれる。例えば、ソフトウェア開発において、仕様書に登場する用語に対して、その用語の意味や付随する情報を適切に管理することは、ソフトウェア開発の生産性を向上させる上で有益である。すなわち、仕様書と用語との結びつきや、仕様書上の用語と実装上の情報（プログラム化の際の変数名や、あるいはその変数の型や制約事項などの情報）との結びつき、または用語同士の関連（同義語など）などがなす体系を適切に管理することにより、開発効率を向上させることが期待される。また、同義語などに限らず、例えば「コンピュータ」と「パソコン」のように概念的に関連している情報を関連付けておければ更に便利である。

従来、このような構造を持った情報を管理するためのツールがいくつか提案され、また、利用されている。しかしながら、それらのツールは何れも、それぞれのツールに決められた方式に従って情報間の関連付けを行わなければならず、また、双方向に関連を持つ情報間ではその双方向から関連付けを行わなければならなかった。そのため、構造を自由に定義することができず、しかもその作業は非常に面倒であった。

また、例えばシステム開発のような場面では、上述のような構造を持った情報の作成・管理を多人数による共同作業によって行う場合が多い。この場合には、作成した情報の構造に不整合が生じる可能性が高くなる。従来は、このような不整合は人手によって発見して修正しなければならなかった。

例えば不整合を発見するツールを利用したとしても、従来は単に不整合を発見してエラーであることをユーザに伝えるものであったため、情報を１項目入力するたびに整合性チェックをかけて、常に整合性をとりながら作業を進めていくというアプローチが用いられていた。

この場合、複数人による共同作業時には、他人の入力を待たないと自分の入力ができなかったり、他人のミスによって入力ができなくなってしまったりすることが有り得る。しかも、これを完璧に行わないと再びエラーを引き起こすことになる。このようなことから、共同作業では、不整合の解消作業に要する時間が多くを占めていた。

また、不整合が発見されたときは、共同作業者のうちの誰が作成したどの情報に不整合が有るかを調べ、それを解決して次の作業に移るという手順を踏む必要がある。この場合、不整合であった部分およびその不整合であった部分に関連する情報も全てシステムへ入力できなくなり、利用できなくなってしまうということがあった。

このようなことから、構造を持った情報を管理するための従来のツールは、情報の作成の段階で十分に注意を払いながら作業を進める必要があり、多人数による共同作業には不向きであった。

本発明は、このような問題を解決するために成されたものであり、構造を持った情報の当該構造を簡単な作業で自由に定義することができ、多人数による共同作業にも対応可能なシステムを提供することにより、構造を持つ情報の作成・管理の作業効率を向上できるようにすることを目的とする。

本発明の情報管理装置は、構造を持った情報の管理を行う情報管理装置であって、上記構造の定義を入力する第１の入力手段と、上記第１の入力手段により入力された構造定義に従って各情報の実体および実体間の関連を表すデータ定義を入力する第２の入力手段と、上記第１、第２の入力手段により入力された定義を解析してＥＲモデルに変換するモデル化手段とを備えたことを特徴とする。

本発明の他の態様では、上記モデル化手段は、上記第１、第２の入力手段により入力された各情報の実体を解析する第１の解析手段と、上記各情報間の関連を解析する第２の解析手段と、上記第１の解析手段による解析結果に従って上記ＥＲモデルのエンティティ定義に変換するエンティティ変換手段と、上記第２の解析手段による解析結果に従って上記ＥＲモデルのリレーションシップ定義に変換するリレーションシップ変換手段とを備える。

本発明のその他の態様では、上記第１、第２の入力手段により入力された定義を上記モデル化手段により上記ＥＲモデルに変換する際に、定義内容の不整合を検出する不整合検出手段を備える。ここで、上記情報の構造を定義する際に任意の制約事項を入力する第３の入力手段を備え、上記不整合検出手段は上記制約事項の検証を行うようにしても良い。また、上記不整合検出手段により検出された不整合をエラーとして出力するようにしても良い。また、上記不整合検出手段により検出された不整合の部分を、不整合であることを示すエンティティおよびリレーションシップの定義に変換する置き換え手段を備えるようにしても良い。

本発明のその他の態様では、上記ＥＲモデルをハイパーテキストに展開する手段を備える。

また、本発明の情報管理方法は、構造を持った情報の管理を行うための情報管理方法であって、上記構造の定義を入力するステップと、上記入力された構造定義に従って各情報の実体および実体間の関連を表すデータ定義を入力するステップと、上記入力された定義を解析してＥＲモデルに変換するステップとを備えたことを特徴とする。

本発明の他の態様では、上記ＥＲモデルへの変換を行う際に、定義内容の不整合を検出する。ここで、上記検出された不整合の部分を、不整合であることを示すエンティティおよびリレーションシップの定義に変換し、モデル変換処理の終了後に上記不整合の部分を抽出してまとめて提示するようにしても良い。

本発明のその他の態様では、上記変換されたＥＲモデルをハイパーテキストに展開するステップを更に備える。

また、本発明のコンピュータ読み取り可能な記録媒体は、構造を持った情報の管理を行う情報管理装置において、上記構造の定義を入力する第１の入力手段と、上記第１の入力手段により入力された構造定義に従って各情報の実体および実体間の関連を表すデータ定義を入力する第２の入力手段と、上記第１、第２の入力手段により入力された定義を解析してＥＲモデルに変換するモデル化手段としてコンピュータを機能させるためのプログラムを記録したことを特徴とする。

本発明の他の態様では、上記ＥＲモデルへの変換を行う際に定義内容の不整合を検出する手段としての機能を更にコンピュータを実現させるためのプログラムを記録する。

本発明のその他の態様では、上記ＥＲモデルをハイパーテキストに展開する手段としての機能を更にコンピュータを実現させるためのプログラムを記録する。

本発明は、入力された構造定義やデータ定義に従って対象となる情報をＥＲモデルへ変換する手段を設けたので、どのような形で定義を入力しても同じＥＲモデルを得ることができるようになり、これにより、情報の複雑な構造を完全に意識することなく、ユーザが書きやすいように自由に定義することができる。しかも、情報間の関連付けは一方向から行えば良いので、情報の構造を簡単に定義することができ、構造を持つ情報の作成・管理の作業効率を格段に向上させることができる。

また、本発明の他の特徴によれば、入力された定義をＥＲモデルに変換する際に定義内容の不整合を検出する手段を設けたので、ＥＲモデルへの変換の際に不整合を自動的に検出して提示するようにすることができ、構造を持った情報の作成の作業効率を更に向上させることができる。したがって、不整合の生じる可能性が高い多人数による共同作業において作業効率を図る場合にも十分に対応することが可能である。

また、本発明のその他の特徴によれば、変換されたＥＲモデルをハイパーテキストに展開する手段を更に設けたので、高速な情報ナビゲート環境を提供することができる。このとき、ＥＲモデルによりエンティティ間の相互のリレーションシップが明確に定義付けられているので、エンティティ間の移動表示を双方向から自由に行うことができ、情報の相互参照を簡便に行うことができる。

本発明の情報管理装置の要素的特徴を表す機能構成ブロック図である。 構造を持った情報の一例として人事構成モデルを示す図である。 図２の例に従った構造定義の一例を示す図である。 図２の例に従ったデータ定義の一例を示す図である。 図２の例に従ったデータ定義の他の例を示す図である。 不整合検出結果の出力例を示す図である。 モデル化手段によるＥＲモデルへの変換動作を示すフローチャートである。 ＨＴＭＬ形式によるハイパーテキストの出力例を示す図である。 ＨＴＭＬ形式によるハイパーテキストの出力例を示す図である。 構造を持った情報の一例としてワークフローモデルを示す図である。 構造を持った情報の一例として用語辞書モデルを示す図である。 構造を持った情報の一例として資源管理モデルを示す図である。 構造を持った情報の一例としてスケジュール管理モデルを示す図である。

以下、本発明の一実施形態を図面に基づいて説明する。図１は、本発明による情報管理装置の要素的特徴を表す機能構成ブロック図である。以下、具体例を挙げながら本発明の情報管理装置および方法について説明する。

図１において、１は構造定義入力手段であり、管理を行う対象となる様々な情報の構造を定義するためのものである。この構造定義入力手段１により、情報間相互の関連、各情報に付随する情報などに構造を定義することが可能である。以下では一例として、図２（ａ）に示すような人事構成の構造を定義することを考える。この図２（ａ）は、「部」の下に幾つかの「グループ」があり、そのグループに何人かの「人」が所属しており、人同士の関係においては上下関係が存在するという構造を表している。

このような構造の定義は、実際にはスクリプトベースで入力するようになっている。例えば、上記図２（ａ）の構造は、図３のように記述される。図３のスクリプトでは、説明の便宜上左側に行番号が記述されているが、実際にはこの行番号は不要である。図２（ａ）の「部」、「グループ」、「人」に対応する定義がそれぞれ図３の第４〜８行目、第９〜１２行目、第１３〜１８行目に記述されている。この構造で定義される「部」、「グループ」などの単位をクラスと呼び、後述する実際に入力される実体のデータをインスタンスと呼ぶ。

例えば、クラス「部」は、“string”、“list＿of＿ref ＿to”、“optionalstring ”という３つの要素で定義されている。第５行目の“string”は、このクラスがどんなものであるかという概要を記載するための文字列を定義する部分である。第６行目の“list＿of＿ref ＿to”は、他のクラスを参照し、それをリスト化するという定義である。具体的には、クラス「グループ」を参照して、そこに存在するインスタンスを抽出して「グループリスト」としてリスト化するという内容である。

また、第７行目では“optional string ”でコメント欄を設けているが、この“optional”が付いている要素は、制約チェック（不整合の確認）を行わなくても良い部分を示している。詳細は後述するが、ここで言う制約チェックとは、対応するインスタンスにおいてこの要素が存在する必要があるかどうかという確認を行うことである。

また、第１５行目の“optional ref＿to”では、クラス「グループ」を参照して、そこに存在するインスタンスを「所属」として使用するという定義が記述されている。この場合も先の“optional string ”と同様に、制約チェック（不整合の確認）を行わなくても良いものなので、対応するインスタンスの要素が存在する必要があるかどうかという確認をする必要はなく、その要素が空白であっても良い。

ただし、“optional ref＿to”の場合は、“ ref＿to”が示す通り他のクラスを参照する必要があるので、対応するインスタンスが空白でない場合には、その内容が示す参照先が定義されているかどうかという参照のチェックは行われる。例えば、先の第１５行目の例では、クラス「グループ」を参照して、そこに存在するインスタンスを「所属」として使用する必要があるので、参照先のクラス「グループ」が定義されているかどうかというチェックが行われる。

以上のようにクラスを定義することにより、情報の構造を定義することができる。なお、図３の第１〜３行目、第１９〜２１行目は、単なるコメント行で動作には関係ない部分である。本実施形態では、このような構造の定義に併せて、制約事項入力手段３によって様々な制約事項に関する情報も記述することが可能である。例えば、図２（ａ）では電話番号は表現されていないが、図３では第１４行目で、“string”として電話番号が定義されている。つまり、「人」は必ず「電話番号」を持っていなければならないといったものである。

図１に戻り、２はデータ定義入力手段であり、上記構造定義入力手段１により入力された構造定義に従って、管理を行う対象となる上記情報の実体および実体間の関連等を表すデータ定義を入力するためのものである。例えば、図４に示すように、図３のように入力された構造定義に従って、部は「開発部」、グループは「開発１課」と「開発２課」、人は「木下太郎」、「田中次郎」、「井上三郎」という各情報の実体とこれらの実体間の関連を表す情報、および電話番号等の制約事項に関する情報、更に図３の“optional”に相当する情報等をスクリプトベースで入力する。

なお、ここにおいて実体間の関連に関しては、部のデータ定義において「開発部」のグループリストとして「開発１課」と「開発２課」とがあり、人のデータ定義において「木下太郎」、「田中次郎」、「井上三郎」は皆「開発１課」に所属しており、「田中次郎」および「井上三郎」の上司が「木下太郎」であるということの内容が記述されている。

４はモデル化手段であり、上記各入力手段１〜３により入力された構造定義、データ定義、制約事項を解析してＥＲモデル（entity relationship model ）に変換する。ＥＲモデルとは、数あるデータモデルの中の１つであり、対象とする世界を主にエンティティ（実体）とリレーションシップ（関連）という２つの概念を用いて表現するモデルを言う。複数個のエンティティは、リレーションシップの意味に応じて結びつけられる。また、エンティティおよびリレーションシップは共に属性を持つことができる（例えば、「人」というエンティティにおいては上述の電話番号や氏名など）。

図２（ｂ）は、上記図４に示したデータ定義をＥＲモデルに変換した結果の例を示す概念図である。図２（ｂ）において、楕円形で示したものがエンティティであり、その楕円形を結ぶ実線がリレーションシップである。なお、ここでは、それぞれのエンティティおよびリレーションシップに紐付いている属性（電話番号など）については、図示を省略している。このようにして変換されたＥＲモデルの情報は、図１のＥＲ情報記憶部５に記憶され、保存される。

以上のように、本実施形態では、入力された定義に従って、管理を行う対象とする情報をＥＲモデルへ変換する手段を設けたので、上記情報の複雑な構造を完全に意識することなく、ユーザが書きやすいように自由に記述することができる。すなわち、例えば図２のような構造をどのように記述しようとも（例えば、「部」と「グループ」とのリレーションシップや「グループ」と「人」とのリレーションシップ等をどの立場から記述しても）、ＥＲ展開すれば皆同じ形のモデルとなるので、リレーションシップの定義の仕方は何ら拘束されるものではなく、自由に記述することができる。

すなわち、図３および図４の例では、「部」と「グループ」とのリレーションシップについては「部」のデータ定義の中で記述し（「開発部」内には「開発１課」と「開発２課」があるという記述形態）、「グループ」と「人」とのリレーションシップについては「人」のデータ定義の中で記述しているが（誰それは「開発１課」に所属するという記述形態）、他の記述形式によっても同じＥＲモデルに展開することができる。

例えば、「部」と「グループ」とのリレーションシップおよび「グループ」と「人」とのリレーションシップの全てを「グループ」のデータ定義の中で記述しても（「開発１課」と「開発２課」は「開発部」に属する。また、「開発１課」には誰それがいるという記述形態）、同じＥＲモデルに展開することができる。このように、本実施形態の情報管理装置によれば、ユーザが分かりやすい形で自由にかつ簡単に構造を定義することができる。

また、図１に示すように、本実施形態の情報管理装置では、モデル化手段４は不整合検出手段４ａと置き換え手段４ｂとを備えている。不整合検出手段４ａは、各入力手段１〜３により入力された定義や制約事項をモデル化手段４によりＥＲモデルに変換する際に、定義内容の不整合を検出する。例えば、入力された制約事項の検証を行うことにより、構造定義に従って入力すべき必須項目が未入力になっていたり、エンティティ間のリレーションシップが定義されているにもかかわらずそのエンティティ自身が定義されていないといったような不整合を検出する。

例えば、図５に示すように、「部」のデータ定義においてグループリストとして「開発３課」を記述しているにもかかわらず、「グループ」のデータ定義においてその「開発３課」のエンティティを定義していない場合には、エンティティ間を結ぶことのできないリレーションシップが存在するとして不整合が検出される。なお、例えば「開発部」の他にこれとは何ら関係性のない「営業部」（図示せず）の構造も定義する場合などには、リレーションシップが定義されていなくても不整合とはならない。このように不整合として検出するか否かは、制約事項として記述することができる。

ところで、不整合を検出した場合にそれを直ちにエラーとして出力することも可能であるが、ただ単にエラー出力した場合には、不整合の部分に付随する情報が全て使えなくなってしまい、構造を持った情報を作成する途中段階の支援が不十分になってしまう。すなわち、情報の構造化は試行錯誤を経て徐々に完成されていくものであり、作成途中では不整合は多数発生するのが通常であるが、単なるエラー出力を行う場合は、１つの不整合が発見される度にＥＲモデルへの変換が中断されてしまう。

多人数で共同作業を行っている場合には、このような不整合が発生することが多く、その度に作業が中断していたのでは、作業効率が悪くなる。そこで本実施形態では、このような不整合を検出した際に、直ちにエラーとしてはじくのではなく、仮のエンティティを作成するようにしている。つまり、本実施形態では不整合は一時的に許可されることになり、作業が中断することがない。また、不整合の部分に付随する情報がそのまま使えるので、作業効率は従来と比べて格段に向上する。

不整合を許可する処理は、具体的には、上記置き換え手段４ｂが、上記不整合検出手段４ａにより検出された不整合の部分を、不整合であることを示す特別なエンティティおよびリレーションシップの定義に変換する。すなわち、本実施形態では、不整合を検出した場合に、その不整合の部分を特別なエンティティおよびリレーションシップの定義に置き換えてＥＲモデルへの変換処理を続行し、変換処理の終了後に、置き換えた特別な部分を検索してまとめて出力するようにしている。図６は、その出力画面の例である。

ここで、これらの不整合検出手段４ａおよび置き換え手段４ｂを含むモデル化手段４によるＥＲモデルへの変換動作を、図７のフローチャートに示す。以下、この図７のフローチャートに従って説明する。図７において、まずステップＳ１で上記構造定義入力手段１により入力された構造定義を解析し、ステップＳ２で上記制約事項入力手段３により入力された制約事項を解析し、ステップＳ３で上記データ定義入力手段２により入力されたデータ定義を構造定義に従って解析する。

次に、ステップＳ４では、構造定義、データ定義、制約事項の定義を解析し、その解析結果に従ってＥＲモデルの全てのエンティティを作成する。そして、ステップＳ５で、各エンティティ間の関連性を解析し、その解析結果に従って上記作成した各エンティティ間のリレーションシップを作成する。その結果、例えば「リレーションが設定されているが対応するエンティティがない」という構造が定義されていると、ステップＳ６で不整合ありと判断される。この場合はステップＳ７に進み、その不整合を回避するために仮のエンティティを作成するとともに、リレーションシップを張る。

このように不整合は、例えばネットワーク接続された複数のユーザ端末にて共同で作業する場合に多く発生すると考えられる。よって、本実施形態のように、一時的な不整合の存在を許してＥＲモデルへの変換処理を続行し、その後で不整合部分をまとめて提示する方が、全体の作業効率の向上を図る観点からより好ましい。不整合部分をまとめて提示することにより、不完全な部分の個数などにより作業進捗の管理をすることもできる。

再び図１において、６は共通出力部であり、上記ＥＲ情報記憶部５に保存されているＥＲ情報を図示しないディスプレイやプリンタに出力したり、ネットワーク上に転送したりするものである。本実施形態では、この共通出力部６を介してＨＴＭＬ出力部７、検索情報出力部８、ＬａＴｅＸ出力部９により様々な表現形式で出力することができる。

ＨＴＭＬ出力部７は、ＥＲ情報の内容をＨＴＭＬファイル群に展開して出力する。その際、リレーションシップが定義されているエンティティ間にハイパーリンクを張ることにより、高速な情報ナビゲート（リンクを辿ることによるノード間の移動）環境を提供する。図８および図９は、ＨＴＭＬ出力されたハイパーテキストの一例を示す図である。これらの図において、下線を引いた部分はハイパーリンクが張られた部分を示しており、ここをクリックすることにより該当するノードに直ちに移動することができる。図９は、図８の画面上で「開発部」の部分をクリックしたときに表示される画面の例である。

特に本実施形態では、ＥＲモデルによりエンティティ間の相互のリレーションシップが明確に定義付けられているので、エンティティ間の移動表示を双方向から自由に行うことができる。これにより、情報の相互参照を簡便にすることができる。また、図６に示したように、不整合の検出結果もハイパーテキスト形式にて出力するようにしているので、ハイパーリンクにより該当する不整合の部分に直ちに移動することができ、作業効率を更に向上させることができる。

さらに、各入力手段１〜３によって定義や制約事項を入力するときに責任範囲を規定する内容も入力しておき、それを併せて提示することにより、検出された不整合が本当の不整合なのか、自分の定義ミスによる不整合であるのか、あるいは共同作業している他人の情報を処理していないための不整合であるのかなど、不整合の原因を容易に特定することができる。これは、具体的には図３および図４のようにスクリプト中に定義して実現される。

例えば、図３のスクリプト中に更に、extern 支店 勤務地；という定義を第２２行目として追加する。これは、図３の構造定義のスクリプト以外の外部のスクリプトにて定義されている「支店」というクラスを参照してインスタンスを抽出し、「勤務地」として使用するという定義である。自分の責任範囲が図３のスクリプトの範囲で定義されているクラスだけであれば、クラス「支店」は責任範囲外ということが分かる。このように責任範囲の分離を行うことにより、複数作業者による作成の支援も効率的に行うことができる。

なお、上記説明でも分かるように、スクリプトは必ずしも構造定義とデータ定義、あるいは制約事項を別個に作成する必要はない。つまり、構造定義は構造定義の文法、データ定義はデータ定義の文法、制約事項は制約事項の文法で書けば１つのスクリプトに記載して構わない。

検索情報出力部８は、ＥＲ情報記憶部５に保存されているＥＲ情報の一覧表や情報の種類別の一覧表、あるいは名称などによる単純検索やキーワードによる曖昧検索を行うための検索用情報を作成し、例えばＨＴＭＬ形式のファイルに展開して出力する。また、ＬａＴｅＸ出力部９は、ＥＲ情報記憶部５に保存されているＥＲ情報に基づいて印刷用のデータを作成して出力する。

以上詳しく説明したように、本実施形態によれば、管理を行う対象とする情報の複雑な構造を意識することなく、ユーザが書きやすいところ、あるいは書けるところから自由に定義することができる。しかも、情報間の関連付けは一方向から行えば良く、情報の構造を簡単に定義することができる。また、本実施形態によれば、ＥＲモデルへの変換の際に不整合が自動的に検出されて提示されるので、構造を持った情報の作成の作業効率を向上させることができる。このような構造を持った情報の作成を多人数による共同作業によって行う場合には不整合が生じる可能性が高くなるので、共同作業を行う場合に特にメリットがある。

なお、以上の実施形態では、人事構成に関する構造を持った情報を作成する場合を例に挙げて説明したが、本発明はこの例に限定されるものではなく、構造を持った情報であればどのようなものにも適用することが可能である。例えば、図１０に示すようなワークフローモデル、図１１に示すような用語辞書モデル、図１２に示すような資源管理モデル、図１３に示すようなスケジュール管理モデルが他の例として挙げられる。

図１０に示すワークフローモデルの構造について簡単に説明する。例えば、ソフトウェアの開発というワークを考えた場合、「開発プロセス」としてはソフトウェアを「設計」する作業と、その設計内容に従って実際にプログラミングする「コーディング」の作業とが必要である。「設計」する際には「仕様書」が必要であり、その結果「設計書」ができ上がる。これを担当するのは「設計者」であり、「設計書」をもとに「コーディング」することにより「ソースコード」を作成するのが「ＳＥ」である。

さらに、上記設計者やＳＥなどの「役割」と、仕様書や設計書やソースコードなどの「情報」との間に“レビュー役割”というリレーションシップが存在する。図１０の右側に示したＥＲモデルの概念図には「設計者」と「設計書」との間には実線が引かれていないが、上記“レビュー役割”に対応する実線をここに引くと、「設計書」をレビューする（例えば承認印を押す）のは「設計者」であるというリレーションシップを持たせることができる。

また、図１１に示す用語辞書モデルは、「パソコン」、「ワークステーション」、「コンピュータ」、「計算機」などの用語とその意味や同義語・多義語との関連、あるいは用語間の関連を構造として定義した例である。また、図１２に示す資源管理モデルは、「田中次郎」による管理の下で、「計算機１」を「○○電機」が製造して「△△商事」が販売するとともに、「机１」を「××事務機」が製造して「△△商事」が販売するとの関連を構造として定義した例である。

また、図１３に示すスケジュール管理モデルは、「田中次郎」は「開発部」の「プログラマ１」であり、「グループスケジュール」に沿って「プログラム」を行うが、それとは全く別に「個人スケジュール」も持っているという構造を定義した例である。

（本発明の他の実施形態）上記図１に示した各機能構成ブロック１〜９は、実際にはＣＰＵあるいはＭＰＵ、ＲＯＭおよびＲＡＭ等からなるマイクロコンピュータシステムにより構成され、その動作はＲＯＭに格納された作業プログラムに従って実現されるが、ハード的に構成してもよい。また、上記各機能構成ブロック１〜９の機能を実現するように当該機能を実現するためのソフトウェアのプログラムコードをＲＯＭに供給し、そのプログラムに従って上記各ブロック１〜９を動作させることによって実施したものも、本発明の範疇に含まれる。

この場合、上記ソフトウェアのプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコード自体、およびそのプログラムコードをコンピュータに供給するための手段、例えばかかるプログラムコードを格納した記録媒体は本発明を構成する。かかるプログラムコードを記憶する記録媒体としては、上記ＲＯＭの他に、例えばフロッピーディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｉ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ、ｚｉｐ、磁気テープ、不揮発性のメモリカード等を用いることができる。

また、コンピュータが供給されたプログラムコードを実行することにより、上述の実施形態の機能が実現されるだけでなく、そのプログラムコードがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等の共同して上述の実施形態の機能が実現される場合にもかかるプログラムコードは本発明の実施形態に含まれることは言うまでもない。

さらに、供給されたプログラムコードがコンピュータの機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに格納された後、そのプログラムコードの指示に基づいてその機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって上述した実施形態の機能が実現される場合にも本発明に含まれることは言うまでもない。

１ 構造定義入力手段
２ データ定義入力手段
３ 制約事項入力手段
４ モデル化手段
４ａ 不整合検出手段
４ｂ 置き換え手段
５ ＥＲ情報記憶部
６ 共通出力部
７ ＨＴＭＬ出力部
８ 検索情報出力部
９ ＬａＴｅＸ出力部

Claims (14)

1. 構造を持った情報の管理を行う情報管理装置であって、上記構造の定義を入力する第１の入力手段と、上記第１の入力手段により入力された構造定義に従って各情報の実体および実体間の関連を表すデータ定義を入力する第２の入力手段と、上記第１、第２の入力手段により入力された定義を解析してＥＲモデルに変換するモデル化手段とを備えたことを特徴とする情報管理装置。
2. 上記モデル化手段は、上記第１、第２の入力手段により入力された各情報の実体を解析する第１の解析手段と、上記各情報間の関連を解析する第２の解析手段と、上記第１の解析手段による解析結果に従って上記ＥＲモデルのエンティティ定義に変換するエンティティ変換手段と、上記第２の解析手段による解析結果に従って上記ＥＲモデルのリレーションシップ定義に変換するリレーションシップ変換手段とを備えることを特徴とする請求項１に記載の情報管理装置。
3. 上記第１、第２の入力手段により入力された定義を上記モデル化手段により上記ＥＲモデルに変換する際に、定義内容の不整合を検出する不整合検出手段を備えたことを特徴とする請求項１または２に記載の情報管理装置。
4. 上記情報の構造を定義する際に任意の制約事項を入力する第３の入力手段を備え、上記不整合検出手段は上記制約事項の検証を行うことを特徴とする請求項３に記載の情報管理装置。
5. 上記不整合検出手段により検出された不整合をエラーとして出力することを特徴とする請求項３または４に記載の情報管理装置。
6. 上記不整合検出手段により検出された不整合の部分を、不整合であることを示すエンティティおよびリレーションシップの定義に変換する置き換え手段を備えたことを特徴とする請求項３または４に記載の情報管理装置。
7. 上記ＥＲモデルをハイパーテキストに展開する手段を備えたことを特徴とする請求項１〜６の何れか１項に記載の情報管理装置。
8. 構造を持った情報の管理を行うための情報管理方法であって、上記構造の定義を入力するステップと、上記入力された構造定義に従って各情報の実体および実体間の関連を表すデータ定義を入力するステップと、上記入力された定義を解析してＥＲモデルに変換するステップとを備えたことを特徴とする情報管理方法。
9. 上記ＥＲモデルへの変換を行う際に、定義内容の不整合を検出することを特徴とする請求項８に記載の情報管理方法。
10. 上記検出された不整合の部分を、不整合であることを示すエンティティおよびリレーションシップの定義に変換し、モデル変換処理の終了後に上記不整合の部分を抽出してまとめて提示することを特徴とする請求項９に記載の情報管理方法。
11. 上記変換されたＥＲモデルをハイパーテキストに展開するステップを更に備えたことを特徴とする請求項８〜１０の何れか１項に記載の情報管理方法。
12. 構造を持った情報の管理を行う情報管理装置において、上記構造の定義を入力する第１の入力手段と、上記第１の入力手段により入力された構造定義に従って各情報の実体および実体間の関連を表すデータ定義を入力する第２の入力手段と、上記第１、第２の入力手段により入力された定義を解析してＥＲモデルに変換するモデル化手段としてコンピュータを機能させるためのプログラムを記録したことを特徴とするコンピュータ読み取り可能な記録媒体。
13. 上記ＥＲモデルへの変換を行う際に定義内容の不整合を検出する手段としての機能を更にコンピュータを実現させるためのプログラムを記録したことを特徴とする請求項１２に記載のコンピュータ読み取り可能な記録媒体。
14. 上記ＥＲモデルをハイパーテキストに展開する手段としての機能を更にコンピュータを実現させるためのプログラムを記録したことを特徴とする請求項１２または１３に記載のコンピュータ読み取り可能な記録媒体。

Images