(57)【要約】      （修正有）【課題】ドメイン分析により抽出できる機能階層図からＵＭＬで表記のデータへの自動変換、及びその逆の自動変換のうちの少なくとも一方を行うことにより、ソフトウェア資源の再利用を支援する。【解決手段】特性ツリーテーブル２６には、ドメイン分析により抽出できる機能階層図（特性ツリー図）のデータが格納されている。ＵＭＬ変換部２１は、そのテーブル２６を参照して、ＵＭＬで表記のデータを格納したＵＭＬ記述テーブル２７を生成する。特性ツリー変換部２４は、ＵＭＬ記述テーブル２７を参照して、対応する特性ツリーテーブル２６を生成する。ＵＭＬ記述テーブル整合性チェック部２２は、ＵＭＬ記述テーブル２７に格納されたデータにおける整合性のチェックを行う。【選択図】図２
2006338303.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーション・プログラムの開発に関係する、異なる表記法により表現されたデータ間の自動変換を行う装置であって、
前記データとして、ドメイン分析により抽出可能な機能階層図を示す階層図データを取得するデータ取得手段と、
前記データ取得手段が取得した階層図データを自動変換してＵＭＬで表記のＵＭＬデータを生成する変換手段と、
を具備することを特徴とする表記変換装置。
【請求項２】
前記ＵＭＬデータにおける整合性をチェックするチェック手段、
を更に具備することを特徴とする請求項１記載の表記変換装置。
【請求項３】
前記ＵＭＬデータを自動変換して前記階層図データを生成する他の変換手段、
を更に具備することを特徴とする請求項１、または２記載の表記変換装置。
【請求項４】
前記チェック手段は、前記ＵＭＬデータの前記階層図データへの自動変換を考慮した整合性のチェックを行う、
ことを特徴とする請求項３記載の表記変換装置。
【請求項５】
アプリケーション・プログラムの開発に関係する、異なる表記法により表現されたデータ間の自動変換を行う装置であって、
前記データとして、ＵＭＬで表記されたＵＭＬデータを取得するデータ取得手段と、
前記データ取得手段が取得したＵＭＬデータを自動変換して、ドメイン分析により抽出可能な機能階層図を示す階層図データを生成する変換手段と、
を具備することを特徴とする表記変換装置。
【請求項６】
請求項１、または５記載の表記変換装置にデータの整合性のチェック用に搭載される装置であって、
前記データとして、ＵＭＬで表記されたＵＭＬデータを取得するデータ取得手段と、
前記データ取得手段が取得したＵＭＬデータを対象に、前記整合性をチェックするチェック手段と、
を具備することを特徴とする整合性チェック装置。
【請求項７】
アプリケーション・プログラムの開発に関係する、異なる表記法により表現されたデータ間の自動変換を行う表記変換装置に実行させるプログラムであって、
前記データとして、ドメイン分析により抽出可能な機能階層図を示す階層図データを取得する機能と、
前記取得する機能により取得した階層図データを自動変換してＵＭＬで表記のＵＭＬデータを生成する機能と、
を実現させるためのプログラム。
【請求項８】
アプリケーション・プログラムの開発に関係する、異なる表記法により表現されたデータ間の自動変換を行う表記変換装置に実行させるプログラムであって、
前記データとして、ＵＭＬで表記されたＵＭＬデータを取得する機能と、
前記取得する機能により取得したＵＭＬデータを自動変換して、ドメイン分析により抽出可能な機能階層図を示す階層図データを生成する機能と、
を実現させるためのプログラム。
【請求項９】
請求項１、または５記載の表記変換装置にデータの整合性のチェック用に搭載される整合性チェック装置に実行させるプログラムであって、
前記データとして、ＵＭＬで表記されたＵＭＬデータを取得する機能と、
前記取得する機能により取得したＵＭＬデータを対象に、前記整合性をチェックする機能と、
を実現させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーション・プログラムの開発にソフトウェア資源を再利用するための技術に関する。
【背景技術】
【０００２】
アプリケーション・プログラム（以降「アプリケーション」と略記）の開発には多大なコストがかかるのが普通である。このことから、開発に必要なコストを削減するために、既存のソフトウェア資源をアプリケーションの開発に再利用することが行われている。その再利用をより容易とする技術として、フレームワークを利用したものがある（特許文献１〜３、非特許文献１、２）。そのフレームワークは、最小のソフトウェア単位であるオブジェクトの集合体のことである。そのオブジェクトは「クラス」によって定義される。
【０００３】
フレームワークを利用した技術では、再利用可能なソフトウェア資源は、ドメイン、フレームワーク、フレームワークを構成する複数のクラス、アプリケーション特有の機能を実現させるクラス、及びフレームワークとクラス間のインターフェース、に分類される。ドメインは、或る特定業務に密着したソフトウェア資源を大まかに括ったものである。
【０００４】
ソフトウェア資源の再利用は、フレームワークの再利用と、クラス（以降、「部品」とも呼ぶ）に相当するものの再利用と、に大別することができる。フレームワークの再利用をする場合、そのフレームワークを構成する１つ以上のクラスを特定して、特定したクラスとそれに対応させるクラスのインターフェースを開発する。
【０００５】
部品の再利用は粒度が小さく、再利用の効果を得るには数多くの部品を選択、評価、拾得する必要がある。それにより、広範な部品の再利用は困難なのが実情である。一方、フレームワークの再利用はその粒度が大きく、大きな効果を得ることができる。このことから、適切なフレームワークの選定、或いは開発をより容易に行えるようにすることが望まれている。
【０００６】
そのようなフレームワークの開発をより容易に行えるようにするものとして、非特許文献１に記載のＦＯＤＡ（Feature-Oriented Domain Analysis）方式がある。そのＦＯＤＡ方式では、ドメインを構成するクラスを機能分析して分類し、分類した機能単位でクラスの再利用を支援している。ドメイン分析の結果は、機能間の階層関係を示す機能階層図（以降「機能ツリー」或いは「特性ツリー」とも呼ぶことにする）として表記されるのが普通である。
【０００７】
周知のように、アプリケーションの開発では、開発すべきアプリケーションの設計（モデリング）が行われる。オブジェクト指向設計では、多くの場合、設計図の統一表記法であるＵＭＬ（Unified Modeling Language）が用いられている。
【０００８】
そのＵＭＬは、ＭＤＡ（Model Driven Architecture）への適用が可能である。また、統一表記法であることから、他人への情報伝達も容易である。これらのことから、ドメイン分析によって得られる機能階層図をＵＭＬ表記に自動変換することは、アプリケーションをより容易に開発できるように支援するものと考えられる。機能階層図はドメイン分析が容易であることから、アプリケーションをより容易に開発できる環境を提供するうえでは、ＵＭＬ表記を機能階層図に変換することも行えることが望ましいと考えられる。
【０００９】
上述したようなことから、それらの間の自動変換は何れの方向で行っても、アプリケーションの開発をより容易なように支援することになると言える。それにより、アプリケーションの開発に関わる、異なる表記法により表現されたデータ間の自動変換を行うことには大きな意味があると考えられる。非特許文献２には、ＦＯＤＡ方式で作成した機能階層図を開発用に展開する技術が記載されているが、ＵＭＬへの展開については記載されていない。
【００１０】
なお、特許文献３に記載された従来技術では、以下のような手順で人によりＵＭＬ表記が行われる。
（１）オブジェクト指向設計をしたプログラム（オブジェクト群）を作成する
（２）プログラムを構成するオブジェクトをアプリケーション・レイヤとプラットフォーム・レイヤに分ける
（３）プラットフォーム・レイヤを構成するオブジェクトを更にハードウェアの寿命により分類し３つのサブレイヤに分ける
（４）オブジェクト間の関連をＵＭＬ表記（クラス図）で記述する
図１２は、特許文献３に記載された従来技術によるＵＭＬ表記を説明する図である。図１２（ａ）は、人の判断によってオブジェクトをレイヤで分割して得られるレイヤ構成図であり、１２０１はアプリケーション・レイヤ、１２０２はプラットフォーム・レイヤ、１２１１〜１２１３はプラットフォーム・レイヤ１２０２を構成する３つのサブレイヤ、をそれぞれ示している。図１１（ｂ）は、そのレイヤ構成図に示すように分割されたオブジェクトから抽出したオブジェクト間の関連を示すＵＭＬ表記によるクラス図である。
【特許文献１】特開平７−３６６８４号公報
【特許文献２】特開２００３−３３７６９７号公報
【特許文献３】特開２０００−９７１０２号公報
【非特許文献１】Ｋｙｏ  Ｃ．  Ｋａｎｇ  ｅｔ  ａｌ．、“Feature-Oriented Domain Analysis (FODA) Feasibility Study”、ＣＭＵ／ＳＥＩ−９０−ＴＲ−０２１
【非特許文献２】Ｋｙｏ  Ｃ．  Ｋａｎｇ  ｅｔ  ａｌ．、“FORM: A feature-Oriented reuse method with domain-specific reference architectures”、Annals of Software Engineering 5(1998) 143-168
【発明の開示】
【発明が解決しようとする課題】
【００１１】
本発明は、ドメイン分析により抽出できる機能階層図からＵＭＬで表記のデータへの自動変換、及びその逆の自動変換のうちの少なくとも一方を行うことにより、ソフトウェア資源の再利用を支援するための技術を提供することを目的とする。
【課題を解決するための手段】
【００１２】
本発明の第１〜第４の態様の表記変換装置は共に、アプリケーション・プログラムの開発に関係する、異なる表記法により表現されたデータ間の自動変換を行うことを前提とし、それぞれ以下の手段を具備する。
【００１３】
第１の態様の表記変換装置は、データとして、ドメイン分析により抽出可能な機能階層図を示す階層図データを取得するデータ取得手段と、データ取得手段が取得した階層図データを自動変換してＵＭＬで表記のＵＭＬデータを生成する変換手段と、を具備する。
【００１４】
第２の態様の表記変換装置は、上記第１の態様における構成に加えて、ＵＭＬデータにおける整合性をチェックするチェック手段、を更に具備する。
第３の態様の表記変換装置は、上記第１、或いは第２の態様における構成に加えて、ＵＭＬデータを自動変換して階層図データを生成する他の変換手段、を更に具備する。
【００１５】
なお、上記チェック手段は、ＵＭＬデータの階層図データへの自動変換を考慮した整合性のチェックを行う、ことが望ましい。
第４の態様の表記変換装置は、データとして、ＵＭＬで表記されたＵＭＬデータを取得するデータ取得手段と、データ取得手段が取得したＵＭＬデータを自動変換して、ドメイン分析により抽出可能な機能階層図を示す階層図データを生成する変換手段と、を具備する。
【００１６】
本発明の整合性チェック装置は、上記第１〜第４の何れかの表記変換装置に搭載されることを前提とし、データとして、ＵＭＬで表記されたＵＭＬデータを取得するデータ取得手段と、データ取得手段が取得したＵＭＬデータを対象に、整合性をチェックするチェック手段と、を具備する。
【００１７】
本発明の第１〜第３の態様のプログラムはそれぞれ、第１の態様の表記変換装置、第４の態様の表記変換装置、及び整合性チェック装置がそれぞれ具備する手段を実現させるための機能を搭載している。
【発明の効果】
【００１８】
本発明は、ドメイン分析により抽出可能な機能階層図を示す階層図データを取得し、その階層図データを自動変換してＵＭＬで表記のＵＭＬデータを生成する。このため、ソフトウェア資源の再利用性のドメイン分析からアプリケーションの設計、開発への連続性を持たせることができる。それにより、存在するデータをより容易、且つ有効に活用させる形でアプリケーションの開発を支援することとなる。
【００１９】
本発明は、ＵＭＬで表記されたＵＭＬデータを取得し、そのＵＭＬデータを自動変換して、ドメイン分析により抽出可能な機能階層図を示す階層図データを生成する。このため、設計したアプリケーションのドメイン分析が容易に行えるようになる。その結果、アプリケーションの開発を支援することとなる。
【００２０】
本発明は、ＵＭＬで表記されたＵＭＬデータを取得し、そのＵＭＬデータを対象に、整合性をチェックする。そのチェックにより、アプリケーションの開発者は、チェックの対象となったＵＭＬデータが適切なものか否か容易に判断できるようになる。そのため、アプリケーションの開発を支援することとなる。
【００２１】
上記の発明を組み合わせた場合には、アプリケーションの開発をより支援できるようになる。
【発明を実施するための最良の形態】
【００２２】
以下、図面を参照して、本発明の実施の形態について説明する。
図１は、本実施の形態における変換対象を説明する図である。図１（ａ）は、例えばＦＯＤＡ方式によるドメイン分析によって得られた特性ツリー図（機能階層図）、図１（ｂ）は、ＵＭＬ表記によるクラス図である。本実施の形態では、図１（ａ）に示すような特性ツリー図、及び図１（ｂ）に示すクラス図のようなＵＭＬ表記を共に変換対象とし、特性ツリー図はＵＭＬ表記、ＵＭＬ表記は特性ツリー図にそれぞれ自動変換できるようにしている。図１（ｂ）に示すクラス図は、図１（ａ）に示す特性ツリー図を変換して得られるものである。
【００２３】
図１（ａ）で波線により囲った範囲はそれぞれ、再利用可能な特性（機能）のグループを表している。グループ化した特性は、グループ単位で再利用されることを想定している。図１（ａ）において、グループ化された特性を上位とする階層関係を有しながら、そのグループ化から除外された特性（以降、便宜的に「除外特性」と呼ぶ）には、丸を付して示している。
【００２４】
各特性は図１（ｂ）に示すようにクラスに一意に置き換えられている。特性の属性は、当該クラスへのノートアンカーで結合したノートとして扱うことにより、ドメイン分析で使用された属性データを保存する。グループを構成する特性間は、ＵＭＬの汎化の記述として階層関係が表現がされている。除外特性は、上位のクラスとＵＭＬのコンポジションの関係で表現されている。図１（ａ）には示していないが、除外特性の下位がツリー状となっている、つまり複数の特性が存在する場合には、コンポジションの関係のクラスに対し、ＵＭＬの汎化の記述として階層関係を表現するようになっている。
【００２５】
特性ツリー図をＵＭＬ表記に自動的に変換することにより、面倒な作業を行うことなく、ＵＭＬツールやＭＤＡツールへのエクスポートやインポートなどを行えるようになる。ＵＭＬ表記を特性ツリー図に自動的に変換することにより、ドメイン分析の支援が行えるようになる。これらのことから、何れの変換を行っても、より容易に行えるようにアプリケーション開発を支援することとなる。その支援により、アプリケーション開発における品質向上、短納期対応、或いはコスト削減などをより容易に実現できることとなる。
【００２６】
図２は、本実施の形態による表記変換装置を搭載のサーバを用いて構築されたネットワークシステムの構成を説明する図である。
そのネットワークシステムは、図２に示すように、サーバ２０、及び複数のクライアント（端末装置）４０をネットワーク３０に接続させることで構築されている。それにより、クライアント４０のユーザに対し、特性ツリー図、或いはＵＭＬ表記を別の表記に自動変換してアプリケーションの開発を支援するサービスを提供できるようになっている。
【００２７】
そのサービスを提供するサーバ２０は、図２に示すように、ＵＭＬ変換部２１、ＵＭＬ記述テーブル整合性チェック部（以降「チェック部」と略記）２２、特性ツリー表示部２３、特性ツリー変換部２４、及びＵＭＬ表示部２５を備え、特性ツリーテーブル２６、及びＵＭＬ記述テーブル２７を格納できるものである。ハードウェアとしては、例えばＣＰＵ、半導体メモリ、ハードディスク装置等の補助記憶装置、及びネットワーク３０を介してデータの送受信を行うネットワーク制御部、を備えている。各テーブル２６、２７は、半導体メモリ、或いは補助記憶装置に格納され、各部２１〜２５は、例えばＣＰＵが補助記憶装置に格納されたプログラムを実行することで実現される。
【００２８】
上記各テーブル２６、２７には、以下のようなデータが格納される。
図３は、特性ツリーテーブルを説明する図である。図３（ａ）は特性ツリーテーブル２６のデータ構成を説明する図であり、図３（ｂ）は特性毎に格納される属性のデータ構成を説明する図である。始めに図３を参照して、特性ツリーテーブル２６について具体的に説明する。
【００２９】
特性ツリーテーブル２６は、クラスの特性（機能）分析を行って得られたデータの格納用である。図３（ａ）に示すように、ドメイン名と特性名がインデックスとなっている。ドメイン名はドメイン分析した結果によって入力される。特性名としては、特性分析を行う際の最上位特性の名称が入力される。
【００３０】
下位１レベル特性としては、最上位特性を特性分割して得られる特性名が入力される。下位１レベル属性には、当該特性の属性、例えば図３（ｂ）に示すような項目のデータ（属性データ）が入力される。下位２レベル特性、下位２レベル属性、下位ｎレベル特性、下位ｎレベル属性にも同様に、上位特性を特性分割して得られる特性名、図３（ｂ）に示す属性データが入力される。特性毎に格納される特性名、及び属性のデータについては便宜的に以降、「特性定義データ」と総称する。
【００３１】
属性を示す項目としては、図３（ｂ）に示すように、分類、下位マップ、再利用グループ名、非機能特性、要求度、安定性、ＵＭＬ記述上位／下位マップ、クラス属性・メソッド、などが用意されている。各項目には、以下のようなデータが格納される。
【００３２】
上記分類には、当該特性が属する特性を示すデータが格納される。ここでは便宜的に、その特性として、アプリケーションに依存することがない、或いはまれな特性である共通特性、アプリケーションに依存するのが普通の特性である可変特性、の２つのみを想定する。
【００３３】
下位マップには、当該特性の下位に位置する特性との関係を示すデータが格納される。再利用グループ名には、当該特性が属するグループ（再利用グループ）を一意に示すデータが格納される。非機能特性には、性能、メモリ容量、信頼性などの品質に関係する要求特性を示すデータが格納される。要求度には、非機能特性のデータが示す要求特性に対する要求度を示すデータが格納される。その要求度は例えば、必須、条件付きの必須、実現しなくとも可、提案レベル、のうちの何れかから選択されるものである。
【００３４】
安定性には、上記要求特性の変更が発生する可能性の度合いを示すデータが格納される。その度合いは、例えば大、中、小の何れかで表されるものである。
本実施の形態では、特性ツリー図を変換して得られたＵＭＬの変更を行えるようにしている。ＵＭＬ記述上位／下位マップは、そのために用意した項目である。その項目には、上位、或いは下位のマップをＵＭＬ上で変更した場合に、その変更内容を示すデータが格納される。それにより、そのデータは、変更を行ったＵＭＬを特性ツリー図に変換する場合に、必要に応じて格納される。
【００３５】
クラス属性・メソッドはＵＭＬを特性ツリー図に変換する場合を想定して用意した項目である。その項目には、ＵＭＬにおけるクラス属性およびメソッドに相当するデータが格納される。そのデータは、クラス属性とメソッドをそれぞれ識別できるように分けて格納される。
【００３６】
上述したようなデータ構成の特性ツリーテーブル２６では、最下位に位置していない特性には、それより下位のレベルに１つ以上の特性が関係付けられている。それにより、テーブル２６は、図１（ａ）に示すような特性ツリー図を記述している。
【００３７】
図４は、特性ツリーテーブルへのデータ格納例を説明する図である。図４（ａ）は特性ツリーテーブル２６に格納されたデータ例を説明する図であり、図４（ｂ）は特性名「ＯＳ２Ｋ保存」の属性として格納されたデータ例を説明する図である。図４（ａ）では、属性データとして分類のデータのみを示している。特性名「ＯＳ２Ｋ保存」、及び「ＯＳ９５保存」はそれぞれ、ＯＳであるＯＳ２Ｋ、ＯＳ９５によってファイルを保存させるためのクラスの特性名である。図４に示すようなデータが特性ツリーテーブル２６に格納されている場合、そのテーブル２６から図１０に示すような特性ツリーが表示される。
【００３８】
特性ツリー図のＵＭＬへの変換は、上記特性ツリーテーブル２６を参照して行われる。上記ＵＭＬ記述テーブル２７は、その変換を行うことで生成される。
図５は、ＵＭＬ記述テーブルを説明する図である。図５（ａ）はＵＭＬ記述テーブル２７のデータ構成を説明する図であり、図５（ｂ）はそのテーブル２７に格納される属性のデータ構成を説明する図である。次に図５を参照して、ＵＭＬ記述テーブル２７について具体的に説明する。
【００３９】
ＵＭＬ記述テーブル２７には、種別、クラス名／ノート名、クラス属性、メソッド、及び属性の各項目のデータが各レコードに格納される。各項目には、以下のようなデータが格納される。
【００４０】
ＵＭＬ記述テーブル２７では、クラス、ノート別にレコードを用意するようにしている。上記種別には、当該レコードに格納したデータがクラス、及びノートの何れのものであるか識別できるように、それらの何れかを示すデータが格納される。クラス名／ノート名には、そのデータが示す種別のクラス、或いはノートの名称が格納される。
【００４１】
クラス属性には、ＵＭＬにおいてクラス標準表記に含まれるそのデータが格納される。メソッドには、ＵＭＬにおいてクラス標準表記に含まれるそのデータが格納される。それらのデータは、特性ツリー図に変換する場合に、図３（ｂ）に項目として示すクラス属性・メソッドのデータとして格納される。
【００４２】
属性には、例えば図５（ｂ）に示すような項目のデータ（属性データ）、つまり分類、上位、下位マップ、特性ツリー下位マップ、再利用グループ名、非機能特性、要求度、及び安定性、などの項目のデータが格納される。上位、下位マップには、当該レベルの上位および下位に位置するクラスの名称、それとの関係（例えば汎化、コンポジション、或いはノートアンカー）を示すデータがそれぞれ格納される。特性ツリー下位マップには、図３（ｂ）に項目として示す下位マップのデータが格納される。そのデータを格納することにより、特性ツリーテーブル２６が表す特性ツリー図で特殊なマップ表現が行われている場合には、その表現をＵＭＬに反映させる。他の項目は特性ツリーテーブル２６と同様であるため、説明は省略する。
【００４３】
上記種別にクラス、及びノートの何れかを示すデータを格納することにより、ＵＭＬ記述テーブル２７には、特性ツリー図に示される特性毎、特性の属性毎にレコードが用意され、特性ツリー図のデータ、及ぶＵＭＬ特有のデータが保存される。それにより、特性ツリー図が図１（ａ）に示すようなものであれば、図１（ｂ）に示すようなクラス図を表記できるデータがテーブル２７に格納される。
【００４４】
図６は、ＵＭＬ記述テーブルへのデータ格納例を説明する図である。図６（ａ）はＵＭＬ記述テーブル２７に格納されたデータ例を説明する図、図６（ｂ）は特性名「ＯＳ２Ｋ保存」の特性により格納された属性の各項目（図中「ＯＳ２ｋクラス属性項目」と表記）のデータ例を説明する図、図６（ｃ）は特性名「ＯＳ２Ｋ保存」の特性の属性により格納された属性の各項目（図中「ＯＳ２ｋノート属性項目」と表記）のデータ例を説明する図である。
【００４５】
図６に示すデータの格納例は、図４に示すデータが特性ツリーテーブル２６に格納されていた場合のものである。図６に示すようなデータがＵＭＬ記述テーブル２７に格納されることにより、そのテーブル２７から図１１に示すようなクラス図が表示される。
【００４６】
特性ツリー図のＵＭＬへの自動変換は、例えば上記特性ツリーテーブル２６の格納場所、及び自動変換によって生成されるＵＭＬ記述テーブル２７の格納場所をクライアント４０のユーザがそれぞれ指定して行われる。その逆も同様である。
【００４７】
図２に示すＵＭＬ変換部２１は、上記特性ツリーテーブル２６を参照してＵＭＬ記述テーブル２７を生成することにより、特性ツリー図をＵＭＬに自動変換するものである。クライアント４０からの起動要求により起動する。起動した変換部２１は、図７に示すＵＭＬ変換処理を実行することにより、その自動変換を行う。ここで図７を参照して、その変換処理について詳細に説明する。
【００４８】
先ず、ステップＳ１では、特性ツリーテーブル２６が表す特性、及び属性毎に、ＵＭＬ記述テーブル２７にレコードを確保し、種別、クラス名／ノート名の各項目にデータを格納する。それにより、特性では種別としてクラスを示すデータ、クラス名／ノート名として特性名を示すデータが格納される。属性では種別としてノートを示すデータ、クラス名／ノート名として特性名を示すデータが格納される。それらのデータの格納が完了した後、ステップＳ２に移行する。
【００４９】
ステップＳ２では、再利用グループを構成する特性に着目して、対応するレコードのクラス属性、上位、下位マップの各データを格納する。クラス属性では、特性ツリーテーブル２６が表す再利用グループ毎に、そのグループで最上位の特性を検出し、その検出した特性の名称をデータとして格納する。上位、下位マップでは、再利用グループの最下位の特性からその特性の位置関係に応じたデータを格納する。より具体的には、上位に位置する特性が存在していれば、その特性名、及び汎化（図中「上位特性名：汎化」と表記）をデータとして格納する。下位に位置する特性が存在していれば、その特性名、及び汎化（図中「下位特性名：汎化」と表記）をデータとして格納する。特性ツリーテーブル２６の属性項目であるＵＭＬ記述上位／下位マップにデータが存在している場合には、それを上位、下位マップのデータとして格納する。
【００５０】
ステップＳ２に続くステップＳ３では、特性の属性に着目して、対応するレコードにデータを格納する。上位、下位マップのデータとして、その特性の名称、及びノートアンカー（図中「当該特性名：ノートアンカー」と表記）を格納する。また、特性ツリーテーブル２６から、分類、下位マップ、再利用グループ名、非機能特性、要求度、安定性、及びクラス属性・メソッドの各項目のデータを読み出し、それぞれ対応する項目のデータとして格納する。ステップＳ４には、その格納が終了した後に移行する。
【００５１】
ステップＳ４では、除外特性に着目して、対応するレコードのデータの格納を行う。上位、下位マップでは、特性ツリー図の最下位の特性からその特性の位置関係に応じたデータを格納する。より具体的には、上位に位置する特性が存在していれば、その特性名、及びコンポジション（図中「上位特性名：コンポジション」と表記）をデータとして格納する。下位に位置する特性が存在していれば、その特性名、及び汎化（図中「下位特性名：汎化」と表記）をデータとして格納する。特性ツリーテーブル２６の属性項目であるＵＭＬ記述上位／下位マップにデータが存在している場合には、それを上位、下位マップのデータとして格納する。
【００５２】
ステップＳ４に続くステップＳ５では、再利用グループで最上位の特性より更に上位の特性に着目して、対応するレコードのデータの格納を行う。クラス属性では、階層関係を考慮して、着目する特性における最上位の特性を検出し、その検出した特性の名称をデータとして格納する。上位、下位マップでは、着目する特性における最下位の特性からその特性の位置関係に応じたデータを格納する。より具体的には、上位に位置する特性のデータとして、検出した特性の名称、及び汎化（図中「上位特性名：汎化」と表記）を格納し、下位に位置する特性のデータとして、その特性名、及び汎化（図中「下位特性名：汎化」と表記）を格納する。その格納が完了した後、生成したＵＭＬ記述テーブル２７を指定の格納場所に格納してから一連の処理が終了する。
【００５３】
図２に示すＵＭＬ表示部２５は、上述したようにして生成されるＵＭＬ記述テーブル２７、或いはクライアント４０のユーザが指定したＵＭＬ記述テーブル２７から表示用の画像データを生成し、クライアント４０に送信するものである。その画像データを送信することにより、クライアント４０が有する、或いは接続された表示装置上に、図１（ｂ）、或いは図１１に示すようなＵＭＬ（ここではクラス図）が表示される。
【００５４】
ＵＭＬ記述テーブル２７は、クライアント４０により更新することが可能である。図２に示すチェック部２２は、更新後のテーブル２７の内容における整合性を自動的にチェックするものである。クライアント４０からの起動要求により起動する。起動したチェック部２２は、例えばクライアント４０から指定されたＵＭＬ記述テーブル２７を対象に、整合性のチェックを行う。そのチェックは、図８に示すＵＭＬ記述テーブル整合性チェック処理を実行することにより行う。ここで図８を参照して、そのチェック処理について詳細に説明する。
【００５５】
そのチェック処理では、ステップＳ１１を実行することにより、以下のチェック項目に着目した整合性のチェックを行い、その結果をクライアント４０に送信し、その処理を終了する。
（１）クラス名とノート名が対になっているか否か（特性とその属性にはそれぞれレコードが用意されることから、属性を持つ特性では、同一の特性名をクラス名／ノート名のデータとして格納し、種別のデータがクラス、ノートとなっている２つのレコードが存在する）
（２）種別のデータがノートとなっているレコードの上位、下位マップのデータにおいて、関係がノートアンカーとなっているか否か
（３）種別のデータがクラスとなっているレコードの上位、下位マップの上位のクラス（特性）を示すデータの関係が汎化となっており、それよりも上位のクラスにその関係がコンポジションとなっているものがなく、且つ対応するノートのレコードにおける分類が再利用可能な特性（ここでは共通特性が相当）となっているか否か
（４）種別のデータがクラスとなっているレコードのうち、上位、下位マップの上位のクラスを示すデータの関係がコンポジションとなっているレコードにおいて、対応するノートのレコードにおける分類が再利用可能でない特性（ここでは可変特性が相当）となっているか否か、及びその上位、下位マップの下位のクラスのレコードにおける分類がその特性となっているか否か
（５）種別のデータがノートとなっているレコードの分類が再利用可能な特性となっており、且つ上位、下位マップの上位、或いは下位のクラスを示すデータの関係が汎化となっているクラスにおいて、関係が汎化となっているクラス間で再利用グループ名が同じとなっているか否か
（６）種別のデータがノートとなっているレコード数が該当する特性ツリーテーブル２６における特性の属性の数と一致しているか否か
上記チェック項目の何れも、否の判定は不整合の存在を示している。その不整合は、特性ツリー図（特性ツリーテーブル２６）への変換が行えない、或いはその変換を不適切なものとする、といったことを生じさせる。このことから、本実施の形態では、各チェック項目でチェックを行い、そのチェック結果をクライアント４０側に送信する。それにより、チェックによって不整合が見つかれば、その旨を示すメッセージや不整合についての詳細な情報をクライアント４０に送信する。このため、クライアント４０のユーザは、ＵＭＬ記述テーブル２７に対する更新が適切に行われているか否かの確認を容易に行うことができる。上記チェック処理は、そのようなデータの送信をステップＳ１１で行った後、終了する。
【００５６】
図２に示す特性ツリー変換部２４は、上記ＵＭＬ記述テーブル２７を参照して特性ツリーテーブル２６を生成することにより、ＵＭＬを特性ツリー図に自動変換するものである。クライアント４０からの起動要求により起動する。起動した変換部２４は、図９に示す特性ツリー変換処理を実行することにより、その自動変換を行う。ここで図９を参照して、その変換処理について詳細に説明する。
【００５７】
先ず、ステップＳ２１では、ＵＭＬ記述テーブル２７の種別がクラスとなっているレコードを対象に、その上位、下位マップのデータを参照して、その下位のクラスとの関係が汎化となっているクラスのなかで最上位のクラスの検出を行い、そのデータから、ツリー構造を構成し、下位マップのデータを生成する。
【００５８】
ツリー構造の構成では、関係の違い、つまり汎化、コンポジションの何れであるかといったことは無視する。そのツリー構造の構成により、特性ツリーテーブル２６には必要なレコードが確保され、確保されたレコードに、特性名としてクラス名／ノート名の特性名、下位マップのデータが格納される。そのレコードのクラス属性・メソッドのデータとして、種別がクラスのレコードのクラス属性、メソッドの各データが格納される。それらの格納を行った後、ステップＳ２２に移行する。
【００５９】
ステップＳ２２では、確保したレコードの属性データとして、クラス名／ノート名に同じ特性名が格納され、種別がノートとなっているレコードの属性データ、つまり分類、特性ツリー下位マップ、再利用グループ名、非機能特性、要求度、及び安定性の各項目のデータを読み出して格納する。その格納を各レコードで行った後、一連の処理を終了する。
【００６０】
図２に示す特性ツリー表示部２３は、上述したようにして生成される特性ツリーテーブル２６、或いはクライアント４０のユーザが指定したそのテーブル２６から表示用の画像データを生成し、クライアント４０に送信するものである。その画像データを送信することにより、クライアント４０が有する、或いは接続された表示装置上に、図１（ａ）、或いは図１０に示すような特性ツリー図が表示される。
【００６１】
なお、本実施の形態では、サーバ２０に搭載の表記変換装置に、特性ツリー図からＵＭＬへの自動変換、及びＵＭＬから特性ツリー図への自動変換を共に行えるようにしているが、それらのうちの一方のみを行えるようにしても良い。また、そのサーバ２０には、ＵＭＬのデータの整合性をチェックする整合性チェック装置を併せて搭載しているが、別の装置に搭載しても良い。これは、表記変換装置においても同様である。
【００６２】
上述したような表記変換装置、或いは整合性チェック装置を実現させるようなプログラムは、ＣＤ−ＲＯＭ、ＤＶＤ、或いは着脱自在なフラッシュメモリ等の記録媒体に記録させて配布しても良い。ネットワーク３０を介して、そのプログラムの一部、若しくは全部を配信するようにしても良い。そのようにした場合には、ユーザーはプログラムを取得してデータ処理装置にロードすることにより、その装置に本発明を適用させることができる。このことから、記録媒体は、プログラムを配信する装置がアクセスできるものであっても良い。
【図面の簡単な説明】
【００６３】
【図１】本実施の形態における変換対象を説明する図である。
【図２】本実施の形態による表記変換装置を搭載のサーバを用いて構築されたネットワークシステムの構成を説明する図である。
【図３】特性ツリーテーブルを説明する図である。
【図４】特性ツリーテーブルへのデータ格納例を説明する図である。
【図５】ＵＭＬ記述テーブルを説明する図である。
【図６】ＵＭＬ記述テーブルへのデータ格納例を説明する図である。
【図７】ＵＭＬ変換処理のフローチャートである。
【図８】ＵＭＬ記述テーブル整合性チェック処理のフローチャートである。
【図９】特性ツリー変換処理のフローチャートである。
【図１０】特性ツリー表示例を説明する図である。
【図１１】ＵＭＬ表示例を説明する図である。
【図１２】特許文献３に記載された従来技術によるＵＭＬ表記を説明する図である。
【符号の説明】
【００６４】
２０    サーバ
２１    ＵＭＬ変換部
２２    ＵＭＬ記述テーブル整合性チェック部
２３    特性ツリー表示部
２４    特性ツリー変換部
２５    ＵＭＬ表示部
２６    特性ツリーテーブル
２７    ＵＭＬ記述テーブル
３０    ネットワーク
４０    クライアント
【図１】
2006338303.tif 000003
【図２】
2006338303.tif 000004
【図３】
2006338303.tif 000005
【図４】
2006338303.tif 000006
【図５】
2006338303.tif 000007
【図６】
2006338303.tif 000008
【図７】
2006338303.tif 000009
【図８】
2006338303.tif 000010
【図９】
2006338303.tif 000011
【図１０】
2006338303.tif 000012
【図１１】
2006338303.tif 000013
【図１２】
2006338303.tif 000014