(57)【要約】【課題】本発明の課題は、設計者、利用者の負担を減らしつつ、正確に知識設計することの出来る知識処理システムを提供する。【解決手段】設計側では、構造化された知識構造を持つクラス群に、全体を統括するコードネームを持つスーパクラスを生成する。そして、スーパクラスを参照することによって、クラス群間の関係を多値論理で推論し、関連付ける。また、可能な場合には、多値論理による推論で新しいクラスを生成する。利用側では、設計側で生成された知識構造を示すクラス群とそれらの関係の他に、独自に多値論理による推論を行い、クラス群の間の関係を再構築し、クラスとクラス間の関係として記述された知識構造を利用する。【選択図】      図１
2004287881.tif 000002
【特許請求の範囲】
【請求項１】
設計対象に関する知識をクラス及びクラス間の関係によって構造的に構成する知識処理システムにおける知識処理方法であって、
該知識を記述するクラスを包括的に記述する名前を有したスーパクラスと、該クラスと、該クラス間の関係をデータベースに格納する格納ステップと、
該データベースに格納されているスーパクラスに関連するクラスを検出し、該クラス間の関係を多値論理に基づく推論によって生成し、該データベースに格納されている情報と、該推論によって得られた該クラス間の関係から該知識の構造を構築する推論ステップとからなることを特徴とする方法をコンピュータに実行させるプログラム。
【請求項２】
前記クラス間の関係には、前記多値論理に基づく推論によって得られたクラス間の関係及び階層構造を重み付ける重みが含まれることを特徴とする請求項１に記載のプログラム。
【請求項３】
前記推論ステップでは、前記推論によってクラス間に関連づけ可能な新しいクラスを生成可能な場合には、該新しいクラスを生成し、他のクラスと関連付けることで、知識の構造化を行うことを特徴とする請求項１に記載のプログラム。
【請求項４】
設計対象に関する知識をクラス及びクラス間の関係によって構造的に構成する知識処理システムにおける知識処理方法であって、
該知識を記述するクラスを包括的に記述する名前を有したスーパクラスと、該クラスと、該クラス間の関係をデータベースに格納する格納ステップと、
該データベースに格納されているスーパクラスに関連するクラスを検出し、該クラス間の関係を多値論理に基づく推論によって生成し、該データベースに格納されている情報と、該推論によって得られた該クラス間の関係から該知識の構造を構築する推論ステップとからなることを特徴とする方法
【請求項５】
設計対象に関する知識をクラス及びクラス間の関係によって構造的に構成する知識処理システムであって、
該知識を記述するクラスを包括的に記述する名前を有したスーパクラスと、該クラスと、該クラス間の関係をデータベースに格納する格納手段と、
該データベースに格納されているスーパクラスに関連するクラスを検出し、該クラス間の関係を多値論理に基づく推論によって生成し、該データベースに格納されている情報と、該推論によって得られた該クラス間の関係から該知識の構造を構築する推論手段とからなることを特徴とする知識処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、オブジェクト指向言語を使った知識処理システムに関する。特に、マルチメディアオブジェクト指向言語を使った知識処理システムに関する。
【０００２】
【従来の技術】
従来、設計者は業務開発やシステム開発等において筆記具を用いて手作業でブロック図を描画したり、または、パソコンやワークステーション等でＵＭＬ（Ｕｎｉｆｉｅｄ  Ｍｏｄｅｌｉｎｇ  Ｌａｎｇｕａｇｅ）等のオブジェクト指向のグラフィックエディタ機能を用いて描画していた。実世界の暗黙知（例えば、実世界の出来事を記述する人が持っている実世界に対する個人的な知識）や既成知（実世界の出来事を記述する人が実際に記載した知識）のモデリングのための知識及び知識間の相互関係や知識構造の階層関係やその知識及び知識間の関係及び知識構造の階層関係による知識を連ねたプロセス（流れ）やプログラム構造を前述の描画を利用して既成知として知識表現していた。この知識や知識構造を参照等する利用者は手作業で描画された図を目視的に自分の頭脳の中へ取り込んで頭脳の中で創造作業をなして知識処理していた。利用者はまた、パソコンやワークステーション等を利用してその知識や階層構造からなる業務のプロセス（流れ）やプログラム構造を参照または利用し、更には必要に応じて修正を加えたりして利用者の頭脳の中に埋没されていた知識や勘や経験等の暗黙知を既成知として知識データベースへ取り込んでいる。
【０００３】
従来の技術を知識構造の設計側と利用側で分けてまとめると以下の通りとなる。
・設計側
従来のプログラム開発、業務開発などにＵＭＬ等を用いて設計者がＵＭＬエディタを用いて設計していた。
【０００４】
その設計内容は以下の通りである。
（１）構造的描写（ユースケース、クラス、インターフェース、コンポーネント、コラボレーション）を行っている。
（２）振る舞い的描写（相互作用、状態マシーン）など
（３）グループ的描写（パッケージ）
（４）注記的描写（ノート）
（５）関係的描写（ユースケース、クラス、インターフェース、コンポーネント、コラボレーション）
（６）ダイヤグラム的描写（ユースケース図、クラス図、オブジェクト図、シーケンス図、コラボレーション図、状態図、アクティビティ図、コンポーネント図、配置図）など
・利用側
以上の設計生成物を利用側のアプリケーションプログラムの利用や人間が設計生成物を目視することによって自らの手作業により利用していた。
【０００５】
図１３は、従来技術を説明する図である。
設計側のＵＭＬ等による知識構造のモデリングは、各記述対象（ｅｖｅｎｔ）に対して、クラスを生成し、これらのクラス間の関係を記述することによって行う。
【０００６】
クラス間の関連の仕方としては、▲１▼依存、▲２▼汎化、▲３▼関連、▲４▼名前、▲５▼ロール、▲６▼多重度、▲７▼集約がある。
同図では、Ｅｖｅｎｔというクラスに対応して、ｗｉｎｄｏｗというクラスが依存関係を持っており、ＤｉａｌｏｇＢｏｘというクラスは、Ｃｏｎｔｒｏｌというクラスと関連がある。ＣｌｏｓｅＷｉｎｄｏｗｓというクラスとＤｉａｌｏｇＢｏｘというクラスは、大きく見ればｗｉｎｄｏｗの制御にあたるので、一般に言うとｗｉｎｄｏｗのクラスに含まれるべきものである。従って、ＤｉａｌｏｇＢｏｘとＣｌｏｓｅＷｉｎｄｏｗｓは、汎化という関連づけにおいて、ｗｉｎｄｏｗというクラスと関連付けられる。また、ｐｅｒｓｏｎというクラスは、Ｃｏｍｐａｎｙというクラスと関係があり、ｐｅｒｓｏｎがＣｏｍｐａｎｙのために働くという関連づけが行われる。また、ｐｅｒｓｏｎやＣｏｍｐａｎｙは、人の名前や会社の名前をインスタンスとして持つ。更に、ｐｅｒｓｏｎとＣｏｍｐａｎｙには、ロール名が付けられる。この場合、ｐｅｒｓｏｎの方には、ロール名としてｅｍｐｌｏｙｅｅ、Ｃｏｍｐａｎｙの方にはｅｍｐｌｏｙｅｒというロール名が付けられる。また、１つの会社に属する人の数に対応して、多重度が定められる。ｐｅｒｓｏｎに記述される人が１つの会社のみに属する場合には、ｐｅｒｓｏｎのＣｏｍｐａｎｙへの多重度は１であるが、ある会社の従業員が１００名であるとすると、Ｃｏｍｐａｎｙへ関連付けられるｐｅｒｓｏｎというクラスが１００個存在し、Ｃｏｍｐａｎｙのｐｅｒｓｏｎへの多重度は１００となる。更に、会社は複数の部門からなるのが通常であるが、この場合、部門を記述するＤｅｐａｒｔｍｅｎｔというクラスは全て、Ｃｏｍｐａｎｙというクラスの基に集められて関連付けられるので、これを集約という。
【０００７】
以上は、設計側が知識構造を設計する場合に使用するクラス間の関連づけの種類の例であるが、これらの関連づけを駆使することによって設計側では、様々な知識内容を設計することが出来る。一方、従来では、このようにして設計された知識内容を受け取った利用側では、この知識内容を読み取る場合、人間が自分の頭脳を使って読み解いていた。
【０００８】
特許文献１においては、ＵＭＬなどのオブジェクト指向プログラムにおいて、マルチメディア設計情報に反映すべき情報を抽出するか否かの判断を自動的に行い、判断の精度を向上させる技術が記載されている。
【０００９】
特許文献２においては、ＵＭＬなどを使ったオブジェクト指向設計の結果をテストする場合において、単純な作業、参照項目の多い作業を支援し、テスト項目が不要に増大しないようにテスト項目を生成する技術が開示されている。
【００１０】
【特許文献１】
特開２０００−１１２７４２号公報
【特許文献２】
特開２００１−２２２４２９号公報
【００１１】
【発明が解決しようとする課題】
従来のＵＭＬなどを使ったオブジェクト指向の知識設計における問題点を設計側と利用側に分けて示す。
・設計側
（１）ＵＭＬは知識を構造的に記述可能な言語であるが、実世界における記述対象の多くは暗黙知であり、言語で必ずしも表現できない。
（２）ＵＭＬは知識構造のビジュアル化のために使用可能な言語であるが、実世界においては、ビジュアル自身が確定的でなく抽象的である。
（３）ＵＭＬは知識内容の仕様化のための言語であるが、仕様書の内容は全てが簡潔明瞭であり、論理的には不確定であってはならないのに対し、仕様化される知識内容である実世界は不確定な要素が多くある。
（４）ＵＭＬは概念モデルを対象としているが、概念自身は当事者の主観によることが多いため、第三者によってゆがめられやすいものとなっている。
【００１２】
設計に関しては、既存のツールでは、どのように設計するかなど全てが利用側にまかされているので、設計者の負担が大きい。
・利用側
設計側で設計された知識内容の利用に関しては既存のツールでは全て利用側にまかされているので、利用者の負担が大きい。
【００１３】
本発明の課題は、設計者、利用者の負担を減らしつつ、正確に知識設計することの出来る知識処理システムを提供することである。特に、その知識処理システムは、マルチメディア知識処理システムである。
【００１４】
【課題を解決するための手段】
本発明の知識処理システムは、設計対象に関する知識をクラス及びクラス間の関係によって構造的に構成する知識処理システムであって、該知識を記述するクラスを包括的に記述する名前を有したスーパクラスと、該クラスと、該クラス間の関係をデータベースに格納する格納手段と、該データベースに格納されているスーパクラスに関連するクラスを検出し、該クラス間の関係を多値論理に基づく推論によって生成し、該データベースに格納されている情報と、該推論によって得られた該クラス間の関係から該知識の構造を構築する推論手段とからなることを特徴とする。
【００１５】
本発明によれば、スーパクラスという知識構造を代表するクラスを設け、スーパクラスに関連するか否かという形でクラスを関連付けることによって知識構造を記述するクラスを構造化する。更に、クラスの構造化において、設計者が設計したクラス間の関係の他に、多値論理を用いた、機械による推論の結果得られた新しいクラス間の関係も当該知識構造の一部とする。
【００１６】
更に他の側面によれば、多値論理を用いた推論によって、新たなクラスを生成し、知識構造をより精密化し、暗黙知の部分を減らし、できるだけ設計者の主観によらない既成知で知識を構造化することによって、当該知識構造によって記述される知識内容を利用者によりわかりやすく、正しく伝えることが出来る。この場合、利用側でも設計側で生成された知識構造に加え、利用側で推論した結果を知識構造に加えることも可能である。
【００１７】
【発明の実施の形態】
本発明では、知識データベースにある、またはＷｅｂ空間にあるコードネーム等のネーミングを持つ（例えば、ある開発プロジェクトにおいて、知識構造が設計される場合、その開発プロジェクトに一意に付与された開発コードネームのネーミングを持つ）、包括的な、知識の上位概念に対応するクラス（スーパクラス）を、従来の技術で示した知識構造化のための機能を持つ知識として扱い、設計者の設計段階及び利用者の利用段階時に重み付けがなされた知識間の相互関係、重み付けされた階層関係、等を時制推論で非単調的に自動生成させ、その結果得られた新たな知識を相互関係または階層関係に自動挿入させる。
【００１８】
本発明の実施形態に従った設計側と利用側の基本構成を以下に示す。
・設計側
（１）コードネームをスーパクラスにセットする。
（２）重み付きＵＭＬを編集する機能を持つ。
（３）重み関係（３要素）処理機能を持つ（依存、汎化、関連）。
（４）変数の多値論理を推論する機能を持つ（ファジーロジックやジェネティックアルゴリズム）。
（５）時制推論機能を持つ。
（６）ＲＤＦスキーマ（Ｒｅｓｏｕｒｃｅ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｆｒａｍｅｗｏｒｋ  ｓｃｈｅｍａ）あるいは、ＸＭＬスキーマなどに出力するＷｅｂコンパイラ機能を持つ。
・利用側
（１）コードネームをスーパクラスとする。
（２）ＵＭＬを編集する機能を持つ。
（３）重み関係（３要素）処理機能を持つ（依存、汎化、関連）。
（４）変数の多値論理を推論する機能を持つ（ファジーロジックあるいはジェネティックアルゴリズム）。
【００１９】
以上の構成を設けることにより、以下のような作用が得られる。
・設計側
（１）スーパクラスを頂点とする知識構造で全ての概念を表現することができる。
（２）設計された知識構造を表記したＵＭＬを編集することができる。
（３）知識構造の関係（３要素）を重み付けを用いて処理することができる。
（４）重み付けを多値論理（ファジーロジック等）で推論することができる。
（５）シーケンス図の処理過程でも上記多値論理を時制推論することができる。
（６）推論した結果により新たにクラスを生成することができる。
（７）以上の結果をＲＤＦスキーマあるいはＸＭＬスキーマに依拠してＷｅｂコンパイルすることができる。
・利用側
（１）スーパクラスを頂点とする知識構造で知識表現としてとらえることができる。
（２）幾つかのクラスを基に新たなクラスを推論することができる。
【００２０】
図１は、本発明の実施形態の要部を説明する図である。
図１において、ｗｉｎｄｏｗというスーパクラスが存在するとする。このスーパクラスを基に、多値論理を用いて推論することにより、他のクラスとの関係を推論し、関連付ける。図１においては、ＣｌｏｓｅＷｉｎｄｏｗｓというクラスは、多値推論により、スーパクラスであるｗｉｎｄｏｗに対して、汎化という関係で関連付けられる。また、ＤｉａｌｏｇＢｏｘというクラスもスーパクラスであるｗｉｎｄｏｗに汎化という関係で関連付けられる。更に、スーパクラスｗｉｎｄｏｗは、推論により、Ｅｖｅｎｔというクラスと関連付けられ、ＤｉａｌｏｇＢｏｘというクラスは、Ｃｏｎｔｒｏｌというクラスと関連付けられる。また、ＣｌｏｓｅＷｉｎｄｏｗｓとＤｉａｌｏｇＢｏｘの関係にも、多値論理による推論が行われるが、図１の場合、関連が発見されなかった場合となっている。
【００２１】
また、多値論理による関連づけがなされた場合には、関連の重みが計算され、データとしてクラスの関連データに付け加えられる。更に、多値論理による推論の結果、設計者は作成していないが、クラス間の関連の中で、新しいクラスが生成される場合がある。例えば、「手帳」というクラスと「テープレコーダ」というクラスが設計者によって、「ミーティング」というクラスの下に関連付けられて生成されていた場合、多値論理による推論により、「手帳」と「テープレコーダ」の共通の特徴である「記録」という概念に対応し、新しいクラスが「手帳」と「テープレコーダ」の汎化の結果として生成される。これは、「手帳」というクラスのインスタンスと「テープレコーダ」というクラスのインスタンスに共通に「記録」というインスタンスが有る場合、この「記録」という名前のクラスを生成することによって、「手帳」と「テープレコーダ」を「ミーティング」とは異なる視点の分類である「記録」という上位概念によって構造化する事が出来る。このような、複数の視点からの構造化を自動生成することにより、設計者の知識構造化作業の負担を減らすことができる。
【００２２】
図１の利用側では、設計側で作成された知識構造を基に、やはり、多値論理による推論を使って、可能な場合には新しいクラスを生成する。利用側では、設計側で作った知識構造をそのまま使うこともできるが、新たなクラスを生成することにより、構造化がより整理され、設計側の作った知識構造を理解するのに役立つ。また、時制推論を使用することにより、例えば、製品開発の段階を記述した知識構造の場合、アイデアの創出段階では、スケッチが入手可能であるが、モデルや製品は存在しない、アイデアの具体化段階では、スケッチとモデルが入手可能であるが、製品は存在しない、製造段階では、スケッチ、モデル、設計図が入手可能であるが、製品は存在しない、開発終了段階では、スケッチ、モデル、設計図、製品の全てが入手可能であるなど、時間の経過と共に、どのアイテムが入手可能ななどの推論を行う。時制推論は、「アイデア創出段階」、「アイデア具体化段階」、「製造段階」、「開発終了段階」などのクラスを発見し、クラスの有する情報から、これらの時制を推論することにより行う。
【００２３】
図２〜図８は、本発明の実施形態を具体的に適用した例を説明する図である。この適用例では、装置などの開発時に付与される開発コードネーム（ＤＣＮ：Ｄｅｖｅｌｏｐｍｅｎｔ  Ｃｏｄｅ  Ｎａｍｅ）をスーパクラスに設定する場合について述べる。
【００２４】
ＤＣＮは設計側、利用者側がクラス／オブジェクトの名前、属性（ｐｒｏｐｅｒｔｙ）、登録者職制をＷｅｂで知識データベースへ登録するものであり、同一名の重複回避または重複時のドメイン設定を行うシステムで構成されている。開発コードネームはスーパクラスに位置し、その配下に構成要素のクラスまたはサブクラスをクラスタとして連ねる。構成要素のつながりが機能的振る舞いとなる際の出力は実際のＷｅｂの利用者へと渡す。例えば、利用者は自ら主観（暗黙知）に照らし合わせた、知識の獲得が可能となる。
【００２５】
図２及び図３は、全体の流れを示すブロック図である。
設計側においては、設計業務において、開発コードネームの設定機能１０、クラス名やオブジェクト名を格納する名前テーブル１１、ＵＭＬエディタなどの画面読み取り機構１２などを備えた端末を使う。これらを用いて、シーケンス図や業務プロセスを示す図を生成し、これらのクラス名やオブジェクト名などを名前知識データベース１３に格納する。また、画面読み取り機構１２からは、時間／処理知識データベース２５に、各クラスの時制や処理内容を格納する。
【００２６】
名前知識データベース１３から、シーケンシャル名前呼び出し機構１４がクラス名やオブジェクト名をシーケンシャルに呼び出し、相互関係組み合わせテーブル作成１５を行う。相互関係組み合わせテーブルは、組み合わせテーブル１６に格納される。
【００２７】
結合推論機構１８では、時間／処理知識データベース２５、組み合わせテーブル１６、及び命題ルール知識データベース１７から、それぞれ各クラスの時制、処理内容データ、クラス間の相互関係データ、命題ルールを読み込み、ファジー推論やジェネティックアルゴリズムによる推論などの多値論理による推論を行う。この結果、設計されたクラスやオブジェクトが知識階層構造として構成される他、クラス間やオブジェクト間の関連の重みが計算される。知識階層構造となったクラスやオブジェクトは、クラス／オブジェクト知識データベース１９に格納され、重みは重み知識データベース２２に格納される。
【００２８】
時間／処理知識データベース２５、及び重み知識データベース２２のデータ，クラス／オブジェクト知識データベース１９のマルチメディアのオブジェクトを組み込み２０が行われたデータは、Ｗｅｂコンパイラ２４によって、Ｗｅｂ表示用にコンパイルされ、インターネットなどのネットワークを介して、利用側に出力成果物として提供される。もちろん、出力成果物はネットワーク上に適用されなくても良い。その場合には、ＤＶＤなどの記録媒体に出力成果物を記録して、利用側に出力成果物を渡す。
【００２９】
利用側では、設計側に対応する、時間／処理知識データベース２５’名前データ１３’、重みデータ２２’、及びクラス／オブジェクト知識データベース１９’が設けられ、設計側からのデータを入力成果物として格納する。時間／処理知識データベース２５’のデータと名前知識データベース１３’のデータとでシーケンス図や業務プロセスを示す図などが構成される。知識階層構造を有するクラス／オブジェクトは、クラス／オブジェクト知識データベース１９’に格納されており、開発コードネームや名前検索によって、クラス／オブジェクト検索３０を行えるようになっている。
【００３０】
時間／処理データ２５’、重み知識データベース２２’及びクラス／オブジェクト知識データベース１９’のデータは、結合推論機構２７において、検索されたスーパクラスの多値論理による推論が行われる。この場合、結合推論機構２７においては、ユーザ／アプリケーション処理ルール知識データベース２６とのやりとりで、クラス間関係の検索２８を行うこともできる。結合推論機構２７は、ファジーロジックやニューラルネットワーク、ジェネティックアルゴリズムなどを用いた多値論理の推論機構であり、クラス間、オブジェクト間などの関係を推論する。これにより、設計側から得たデータからクラス間あるいはオブジェクト間の関係の再構築２９を行い、重みを重み知識データベース２２’に、知識階層構造となったクラスまたはオブジェクトをクラス／オブジェクト知識データベース１９’に格納する。利用者は、開発コードネームや名前検索で検索したクラスやオブジェクト、スーパクラスに関連した再構築された知識構造をマルチメディアによってオブジェクト表示３１させる。これにより、設計側で設計された構造化された知識情報が利用者側に表示される。このマルチメディア表示には、画像による表示の他、音響やテキストなどによる知識の提示も含む。
【００３１】
なお、本発明の実施形態において使用する推論においては、多値論理を使っているので非単調推論ができる。つまり二つの命題は人間が読み書きした場合明らかに偽であると分かっても、命題論理にして処理すると二つの命題が共に真となることがある。しかし、多値論理を使用すると重み出力があるので、二つの命題が真であっても重みの大きい方を真ととらえる（非単調）ことができる。この結果、信頼度が高く精度の高い推論が可能となる。
【００３２】
図４は、本発明の実施形態に従った設計側の処理フローである。
まず、入力として、開発コードネームや名前リストを設計側の端末に入力する。ステップＳ１０では、この入力を受けて、クラス群をスキャンし、スーパクラスを見つける。ステップＳ１１においては、スーパクラスに関係した隣接クラスを見つける。そして、ステップＳ１２において、クラス間の結合関係を得、ステップＳ１３において、ファジーロジックやニューラルネットワーク、ジェネティックアルゴリズムなどを使った推論を行う。ステップＳ１４において、推論の結果をクラス間の関係の結果とする。この時、推論にファジーロジックを使った場合には、各関係に重みが付く。
【００３３】
そして、ステップＳ１５において、新しいクラスを生成すべきか否かが判断され、ステップＳ１５の判断がＹＥＳの場合には、ステップＳ１６において、新クラスを生成し、ステップＳ１７に進む。ステップＳ１５の判断がＮＯの場合には、そのままステップＳ１７に進む。ステップＳ１７においては、全てのクラスについて処理が終わったか否かを判断する。ステップＳ１７における判断がＮＯの場合には、ステップＳ１３に進む。ステップＳ１７における判断がＹＥＳの場合には、ステップＳ１８に進む。ステップＳ１８においては、全結合について処理し終わったか否かが判断される。ステップＳ１８の判断がＮＯの場合には、ステップＳ１１に戻る。ステップＳ１８における判断がＹＥＳの場合には、処理を終了する。
【００３４】
図５は、開発コードネーム知識データベースの例を示した図である。
このデータベースにおいては、開発コードネームＤＣＮがクラス／オブジェクト名として格納されると共に、開発コードネームに対応して、プロパティが格納される。プロパティにおいては、登録職制、部署名、装置名、型番、機能概略、構成、適用、ユーザ、環境が登録される。
【００３５】
図６は、本発明の実施形態に従った利用側の処理フローである。
利用側では、開発コードネームや名前リストを利用側の端末に入力する。ステップＳ２０においては、クラス群のスキャンを行い、スーパクラスを見つける。
ステップＳ２１においては、スーパクラスの隣接クラスを見つける。ステップＳ２２においては、クラス間の結合関係を取得する。ステップＳ２３においては、命題ルール端末に与え、ステップＳ２４においては、命題ルールに合致するクラスを得る。命題ルールは、「ａ」ならば「ｂ」、かつ、「ｂ」ならば「ｃ」、故に「ａ」ならば「ｃ」というような命題を記述するルールである。これによれば、図６左に記載されているクラス間の関係において、あるクラス「ａ」がクラス１と関係有り、クラス１がクラス２と間接的な関係にあり、クラス「ｂ」がクラス２と関係があり、クラス２と関連するクラス３がクラス４と間接的な関係にあり、クラス４とクラス「ｃ」が関係があるならば、クラス「ａ」とクラス「ｃ」は間接的な関係があるということになる。ステップＳ２５において、クラスとクラスの関係を推論する。この推論は、ファジーロジックやニューラルネットワークやジェネティックアルゴリズムで行う。ステップＳ２６においては、新しいクラスを生成可能か否かが判断され、ＹＥＳの場合には、ステップＳ２７で新クラスを生成してステップＳ２８に進み、ＮＯの場合には、そのまま、ステップＳ２８に進む。
【００３６】
ステップＳ２８においては、全てのクラスについて処理が終わったか否かが判断され、ＮＯの場合にはステップＳ２３に進み、ＹＥＳの場合にはステップＳ２９に進む。ステップＳ２９においては、全結合の処理が終わったか否かが判断される。ステップＳ２９の判断がＮＯの場合には、ステップＳ２１に戻り、ＹＥＳの場合には、処理を終了する。
【００３７】
図７は、時制推論を説明する図である。
同じ推論ルールであっても、業務プロセスなどがどの段階にあるかによって結果が異なる。ある時点ｔ１では、「ａ」ならば「ｂ」、且つ、「ｂ」ならば「ｃ」であれば、「ａ」は「ｃ」が成立する場合でも、ある時点ｔ２では、「ａ」ならば「ｂ」、且つ、「ｂ」ならば「ｃ」であっても「ａ」は「ｃ」とはならない。
【００３８】
このように、時制を考慮して推論ルールを構築しておけば、時制を含んだ推論を行うことが出来る。
図８は、設計側で得られた知識構造を利用者側にＷｅｂデータとして渡す場合を説明する図である。
【００３９】
設計側では、設計側で知識構造をクラスとクラス間の関係（依存、汎化、関連、名前、ロール、多重度、集約）を入力し、多値論理による推論によって知識階層構造を生成する。設計側では、これをＲＤＦスキーマあるいはＸＭＬスキーマを使って、Ｗｅｂコンパイルすると共に、ＵＭＬエディタを使って、クラス間関係から時制論理推論を行い、Ｗｅｂコンパイルしてネットワークにデータを公開する。利用側では、これをネットワーク経由で受け取って、時制推論や脱多値論理化処理を行い、業務プロセスなどの構造化知識を端末に表示させる。
【００４０】
図９〜図１２は、知識構造とクラスの関係を説明する図である。
図９に示されるように、「ＰＣＢ」というインスタンスを共通に持つクラスが複数有る場合には、推論メカニズムにより、新しいクラス「ＰＣＢ」が生成される。特に、本発明の実施形態では、ファジーロジックを使った場合、新たに生成されるクラス「ＰＣＢ」への、元のクラスからの各関連データには重みが付加される（図１０参照）。また、図１１においては、ＳｅｒｖｅｒというクラスとＬｏｃｋｅｒというクラスが関連付けられている場合、推論により、Ｓｅｒｖｅｒの部分クラスであるＬｏｃｋｅｒからＰｏｗＳｕｐというクラスへの関係がある重みで生成され、更に、推論により、ＰｏｗＳｕｐというクラスとＳｅｒｖｅｒというクラスが関連付けられる。この場合、ＰｏｗＳｕｐは、Ｓｅｒｖｅｒの部分クラスであるとされる。
【００４１】
また、図１２に示されるように、Ｓｅｒｖｅｒの部分クラスである女性用ロッカーの知識を記述するクラスＬｏｃｋｅｒには、色、高さ、奥行き、長さなどのプロパティが設けられ、これらは、Ｅｎｕｍｅｒａｔｉｏｎというクラスによって登録されるインスタンスの値が与えられる。Ｈｅｉｇｈｔには、更に、他のＥｎｕｍｅｒａｔｉｏｎクラスが関連付けられ、背の高さの情報が細かく規定される。
【００４２】
このように、多値推論処理を行うことにより、設計側の暗黙知であり、設計側で関連付けられていなかったクラスが、関連付けられたり、新たなクラスが生成されるので、設計側の暗黙知をシステムが既成知としてクラスに記述することができる。既成知となった暗黙知は、利用側で紛れなく認識されるので、設計側で生成された知識構造がゆがめられることなく、利用側に渡される。
【００４３】
（付記１）設計対象に関する知識をクラス及びクラス間の関係によって構造的に構成する知識処理システムにおける知識処理方法であって、
該知識を記述するクラスを包括的に記述する名前を有したスーパクラスと、該クラスと、該クラス間の関係をデータベースに格納する格納ステップと、
該データベースに格納されているスーパクラスに関連するクラスを検出し、該クラス間の関係を多値論理に基づく推論によって生成し、該データベースに格納されている情報と、該推論によって得られた該クラス間の関係から知識構造を構築する推論ステップとからなることを特徴とする方法をコンピュータに実行させるプログラム。
【００４４】
（付記２）前記クラス間の関係には、前記多値論理に基づく推論によって得られたクラス間の関係及び階層構造を重み付ける重みが含まれることを特徴とする付記１に記載のプログラム。
【００４５】
（付記３）前記推論ステップでは、前記推論によってクラス間に関連づけ可能な新しいクラスを生成可能な場合には、該新しいクラスを生成し、他のクラスと関連付けることで、知識の構造化を行うことを特徴とする付記１に記載のプログラム。
【００４６】
（付記４）前記推論ステップでは、クラス群で記述される知識構造について、時制推論を行い、記述されている知識の時間経過を追った変化を考慮したクラス間の関係を知識構造に組み込むことを特徴とする付記１に記載のプログラム。
【００４７】
（付記５）設計側で生成された前記知識構造を利用する利用側において、該知識構造を記述するスーパクラス及びクラス群の情報から、多値論理を用いた推論により該設計側で設計された知識構造を再構築することを特徴とする付記１に記載のプログラム。
【００４８】
（付記６）設計対象に関する知識をクラス及びクラス間の関係によって構造的に構成する知識処理システムにおける知識処理方法であって、
該知識を記述するクラスを包括的に記述する名前を有したスーパクラスと、該クラスと、該クラス間の関係をデータベースに格納する格納ステップと、
該データベースに格納されているスーパクラスに関連するクラスを検出し、該クラス間の関係を多値論理に基づく推論によって生成し、該データベースに格納されている情報と、該推論によって得られた該クラス間の関係から該知識の構造を構築する推論ステップとからなることを特徴とする方法
（付記７）前記クラス間の関係には、前記多値論理に基づく推論によって得られたクラス間の関係及び階層構造を重み付ける重みが含まれることを特徴とする付記６に記載の方法。
【００４９】
（付記８）前記推論ステップでは、前記推論によってクラス間に関連づけ可能な新しいクラスを生成可能な場合には、該新しいクラスを生成し、他のクラスと関連付けることで、知識の構造化を行うことを特徴とする付記６に記載の方法。
【００５０】
（付記９）前記推論ステップでは、クラス群で記述される知識構造について、時制推論を行い、記述されている知識の時間経過を追った変化を考慮したクラス間の関係を知識構造に組み込むことを特徴とする付記６に記載の方法。
【００５１】
（付記１０）設計側で生成された前記知識構造を利用する利用側において、該知識構造を記述するスーパクラス及びクラス群の情報から、多値論理を用いた推論により該設計側で設計された知識構造を再構築することを特徴とする付記６に記載の方法。
【００５２】
（付記１１）設計対象に関する知識をクラス及びクラス間の関係によって構造的に構成する知識処理システムであって、
該知識を記述するクラスを包括的に記述する名前を有したスーパクラスと、該クラスと、該クラス間の関係をデータベースに格納する格納手段と、
該データベースに格納されているスーパクラスに関連するクラスを検出し、該クラス間の関係を多値論理に基づく推論によって生成し、該データベースに格納されている情報と、該推論によって得られた該クラス間の関係から該知識の構造を構築する推論手段とからなることを特徴とする知識処理システム。
【００５３】
（付記１２）前記クラス間の関係には、前記多値論理に基づく推論によって得られたクラス間の関係及び階層構造を重み付ける重みが含まれることを特徴とする付記１１に記載の知識処理システム。
【００５４】
（付記１３）前記推論手段では、前記推論によってクラス間に関連づけ可能な新しいクラスを生成可能な場合には、該新しいクラスを生成し、他のクラスと関連付けることで、知識の構造化を行うことを特徴とする付記１１に記載の知識処理システム。
【００５５】
（付記１４）前記推論手段では、クラス群で記述される知識構造について、時制推論を行い、記述されている知識の時間経過を追った変化を考慮したクラス間の関係を知識構造に組み込むことを特徴とする付記１１に記載の知識処理システム。
【００５６】
（付記１５）設計側で生成された前記知識構造を利用する利用側において、該知識構造を記述するスーパクラス及びクラス群の情報から、多値論理を用いた推論により該設計側で設計された知識構造を再構築することを特徴とする付記１１に記載の知識処理システム。
【００５７】
【発明の効果】
（１）知識の獲得に利用するＵＭＬに暗黙知が取り込んで表現できる。
（２）重み付け及び多値論理をＵＭＬを用いてビジュアル化された言語で利用できるので、確定的な抽象的知識であっても取りこぼすことが無くなる。
（３）ＵＭＬで仕様化させるときの言語として利用できるので、仕様書の内容は簡潔明瞭であり、論理的には不確定であっても良いので、実世界の不確定な要素に対しても知識の獲得対象になる。
（４）ＵＭＬは概念モデルを対象としてきたので、概念自身は当事者の主観によるところが多くても、第三者によって知識がより精緻化することが可能となる。
（５）利用側の負担が軽減される。
（６）従来は手作業で関係付けを行っていたが設計側の習熟度により本質が落ちこぼれることなくエキスパートが作業したような幅の広い的確なクラス及びオブジェクトの入手が可能となる。例えば、製品の障害が発生して故障原因を探索する場合のドキュメントや画像や音声のガイドブックを入手する場合に的確なオブジェクトを入手可能となる。
【図面の簡単な説明】
【図１】本発明の実施形態の要部を説明する図である。
【図２】本発明の実施形態を具体的に適用した例を説明する図（その１）である。
【図３】本発明の実施形態を具体的に適用した例を説明する図（その２）である。
【図４】本発明の実施形態を具体的に適用した例を説明する図（その３）である。
【図５】本発明の実施形態を具体的に適用した例を説明する図（その４）である。
【図６】本発明の実施形態を具体的に適用した例を説明する図（その５）である。
【図７】本発明の実施形態を具体的に適用した例を説明する図（その６）である。
【図８】本発明の実施形態を具体的に適用した例を説明する図（その７）である。
【図９】知識構造とクラスの関係を説明する図（その１）である。
【図１０】知識構造とクラスの関係を説明する図（その２）である。
【図１１】知識構造とクラスの関係を説明する図（その３）である。
【図１２】知識構造とクラスの関係を説明する図（その４）である。
【図１３】従来技術を説明する図である。
【符号の説明】
１０      開発コードネーム設定機能
１１、      名前テーブル
１２      画面読み取り機構
１３、１３’      名前知識データベース
１４      シーケンシャル名前呼び出し機能
１５      相互関係組み合わせテーブル作成
１６      組み合わせテーブル
１７      命題ルール知識データベース
１８      結合推論機構
１９、１９’      クラス／オブジェクト知識データベース
２０      マルチメディアのオブジェクト組み込み
２２、２２’      重み知識データベース
２４      Ｗｅｂコンパイラ
２５、２５’      時間／処理知識データベース
２６      ユーザ／アプリケーション処理ルール知識データベース
２７      結合推論機構
２８      クラス間関係の探索
２９      関係の再構築
３０      クラス／オブジェクト検索
３１      マルチメディアのオブジェクト表示
【図１】
2004287881.tif 000003
【図２】
2004287881.tif 000004
【図３】
2004287881.tif 000005
【図４】
2004287881.tif 000006
【図５】
2004287881.tif 000007
【図６】
2004287881.tif 000008
【図７】
2004287881.tif 000009
【図８】
2004287881.tif 000010
【図９】
2004287881.tif 000011
【図１０】
2004287881.tif 000012
【図１１】
2004287881.tif 000013
【図１２】
2004287881.tif 000014
【図１３】
2004287881.tif 000015