(57)【要約】【課題】オブジェクト指向のソフトウェアを開発する際に、設計モデルを含む設計情報に基づいてソフトウェアの仕様書を作成する。【解決手段】設計モデルの記述形式に沿って記述されたオブジェクト指向のソフトウェアの設計情報、に基づいてソフトウェアの仕様書を作成する仕様書作成装置１００であって、対象設計情報を解析して仕様書の作成に必要な情報を抽出する設計情報解析手段１０と、設計情報解析手段１０において抽出された情報に基づいて、対象設計情報から生成されるソフトウェアの仕様書を出力する仕様書作成手段１４と、を含む仕様書作成装置により上記課題を解決できる。【選択図】図１
2005258561.tif 000002
【特許請求の範囲】
【請求項１】
設計モデルの記述形式に沿って記述されたオブジェクト指向のソフトウェアの設計情報、に基づいてソフトウェアの仕様書を作成する仕様書作成装置であって、
設計対象となる対象設計情報を取得する設計情報取得手段と、
前記設計情報取得手段において取得された対象設計情報を解析して仕様書の作成に必要な情報を抽出する設計情報解析手段と、
前記設計情報解析手段において抽出された情報に基づいて、前記対象設計情報から生成されるソフトウェアの仕様書を出力する仕様書作成手段と、
を含むことを特徴とする仕様書作成装置。
【請求項２】
請求項１に記載の仕様書作成装置において、
前記仕様書作成手段は、ユーザから仕様書作成の対象となるクラスの指定を受け、その指定されたクラスに関する仕様書を作成することを特徴とする仕様書作成装置。
【請求項３】
請求項２に記載の仕様書作成装置において、
前記設計情報解析手段は、前記対象設計情報から２つ以上のクラス間の依存関係を抽出し、
前記仕様書作成手段は、前記指定されたクラスと依存関係にあるクラスについて仕様書を作成することを特徴とする仕様書作成装置。
【請求項４】
請求項２又は３に記載の仕様書作成装置において、
前記設計情報解析手段は、前記対象設計情報からクラスに含まれるメンバ属性又はメンバ関数を示す情報を抽出し、
前記仕様書作成手段は、前記指定されたクラス又はそれと依存関係にあるクラス、に含まれるメンバ属性又はメンバ関数について仕様書を作成することを特徴とする仕様書作成装置。
【請求項５】
請求項１〜４のいずれか１つに記載の仕様書作成装置において、
前記仕様書作成手段は、ハイパーテキスト形式で仕様書を作成することを特徴とする仕様書作成装置。
【請求項６】
請求項５に記載の仕様書作成装置において、
前記仕様書作成手段は、依存関係にあるクラスをリンクを伴って仕様書に記述することを特徴とする仕様書作成装置。
【請求項７】
請求項５に記載の仕様書作成装置において、
前記仕様書作成手段は、クラスに含まれるメンバ属性又はメンバ関数をリンクを伴って仕様書に記述することを特徴とする仕様書作成装置。
【請求項８】
請求項１〜７のいずれか１つに記載の仕様書作成装置において、
前記仕様書作成手段は、指定された言語に対応するソフトウェアの仕様書を作成することを特徴とする仕様書作成装置。
【請求項９】
請求項１〜８のいずれか１つに記載の仕様書作成装置において、
複数の設計情報の差分から前記対象設計情報を抽出する設計情報差分抽出手段を含むことを特徴とする仕様書作成装置。
【請求項１０】
設計モデルの記述形式に沿って記述されたオブジェクト指向のソフトウェアの設計情報、に基づいてソフトウェアの仕様書を作成する仕様書作成方法であって、
設計対象となる対象設計情報を取得する設計情報取得工程と、
前記設計情報取得工程において取得された対象設計情報を解析して仕様書の作成に必要な情報を抽出する設計情報解析工程と、
前記設計情報解析工程において抽出された情報に基づいて、前記対象設計情報から生成されるソフトウェアの仕様書を出力する仕様書作成工程と、
を含むことを特徴とする仕様書作成方法。
【請求項１１】
請求項１０に記載の仕様書作成方法において、
前記仕様書作成工程では、ユーザから仕様書作成の対象となるクラスの指定を受け、その指定されたクラスに関する仕様書が作成されることを特徴とする仕様書作成方法。
【請求項１２】
請求項１１に記載の仕様書作成方法において、
前記設計情報解析工程では、前記対象設計情報から２つ以上のクラス間の依存関係が抽出され、
前記仕様書作成工程では、前記指定されたクラスと依存関係にあるクラスについて仕様書が作成されることを特徴とする仕様書作成方法。
【請求項１３】
請求項１１又は１２に記載の仕様書作成方法において、
前記設計情報解析工程では、前記対象設計情報からクラスに含まれるメンバ属性又はメンバ関数を示す情報が抽出され、
前記仕様書作成工程では、前記指定されたクラス又はそれと依存関係にあるクラス、に含まれるメンバ属性又はメンバ関数について仕様書が作成されることを特徴とする仕様書作成方法。
【請求項１４】
請求項１０〜１３のいずれか１つに記載の仕様書作成方法において、
前記仕様書作成工程では、ハイパーテキスト形式で仕様書が作成されることを特徴とする仕様書作成方法。
【請求項１５】
請求項１４に記載の仕様書作成方法において、
前記仕様書作成工程では、依存関係にあるクラスがリンクを伴って仕様書に記述されることを特徴とする仕様書作成方法。
【請求項１６】
請求項１４に記載の仕様書作成方法において、
前記仕様書作成工程では、クラスに含まれるメンバ属性又はメンバ関数がリンクを伴って仕様書に記述されることを特徴とする仕様書作成方法。
【請求項１７】
設計モデルの記述形式に沿って記述されたオブジェクト指向のソフトウェアの設計情報、に基づいてソフトウェアの仕様書を作成する仕様書作成プログラムであって、
コンピュータを、
設計対象となる対象設計情報を取得する設計情報取得手段と、
前記設計情報取得手段において取得された対象設計情報を解析して仕様書の作成に必要な情報を抽出する設計情報解析手段と、
前記設計情報解析手段において抽出された情報に基づいて、前記対象設計情報から生成されるソフトウェアの仕様書を出力する仕様書作成手段と、
を含む仕様書作成装置として機能させることを特徴とする仕様書作成プログラム。
【請求項１８】
請求項１７に記載の仕様書作成プログラムにおいて、
前記仕様書作成手段を、ユーザから仕様書作成の対象となるクラスの指定を受け、その指定されたクラスに関する仕様書を作成する手段として機能させることを特徴とする仕様書作成プログラム。
【請求項１９】
請求項１８に記載の仕様書作成プログラムにおいて、
前記設計情報解析手段を、前記対象設計情報から２つ以上のクラス間の依存関係を抽出する手段、
前記仕様書作成手段を、前記指定されたクラスと依存関係にあるクラスについて仕様書を作成する手段、
として機能させることを特徴とする仕様書作成プログラム。
【請求項２０】
請求項１８又は１９に記載の仕様書作成プログラムにおいて、
前記設計情報解析手段を、前記対象設計情報からクラスに含まれるメンバ属性又はメンバ関数を示す情報を抽出する手段、
前記仕様書作成手段を、前記指定されたクラス又はそれと依存関係にあるクラス、に含まれるメンバ属性又はメンバ関数について仕様書を作成する手段、
として機能させることを特徴とする仕様書作成プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オブジェクト指向のソフトウェアに対する設計情報に基づいてソフトウェアの仕様書を作成するために用いられる仕様書作成装置、仕様書作成方法及び仕様書作成プログラムに関する。
【背景技術】
【０００２】
ソフトウェアの仕様書を作成する方法として、ソフトウェアに対するソースコードの構文に加えてソースコードにコメントとして記載された説明を利用する方法が考えられている（特許文献１及び２等）。サン・マイクロシステムズ(Sun  Microsystems)社のJavodoc  Toolは、ソースコードに含まれるクラス、メンバ関数、メンバ変数等の各種の定義の直前にコメントの種類を区別するために予め決められた形式のタグを用いてコメントを記載しておくことによって、そのタグに基づいてコメントを解釈することによりインターフェースの仕様書を作成する。
【０００３】
また、特許文献１には、ソースコードの各種定義の直前だけでなく、各種定義内に記述されているコメントを抽出してインターフェースの仕様書に反映する方法が開示されている。
【０００４】
一方、ソフトウェアの開発プロセスでは、オブジェクト指向に基づいた開発手法を適用する動きが広がっている。これに伴って、オブジェクト指向に基づく開発ツールも整備されつつあり、例えば、ラショナル(Rational)社のRational  Rose等のように設計モデルを作成することによって、設計モデルからソースコードの雛型を自動的に生成するようなツールも開発されている。
【０００５】
【特許文献１】特開２００２−１６９６９２号公報
【特許文献２】特開平７−２３４７８３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記従来技術のようにソースコードから仕様書を作成する方法では、ソースコードにコメントやコメントの種別を示す専用のタグを埋め込む必要があり、より詳細なコメントを記述するほどソースコード自体が読み難くなってしまう。また、所定の形式でコメントやタグを記述する必要があるため、ソースコードを記述する際にコメントやタグの記述の形式を理解しておかなければならず、ソフトウェアの作成者の負担が大きくなってしまう。
【０００７】
さらに、ソースコードが作成されるまでインターフェースの仕様書を生成することができないため、ソースコードが作成される前の開発段階で仕様書が必要となる場合には別途用意する必要があった。その結果、ソフトウェアの開発プロセスにおいて無駄な手間を要していた。
【０００８】
また、ソフトウェアの設計モデルからソースコードの雛型を自動生成するツールを用いて設計モデルからソースコードを自動生成し、さらにソースコードから仕様書を自動生成するツールを用いて自動生成されたソースコードから仕様書を生成することもできる。しかしながら、このような方法を用いる場合には二つのツールが対応できるプログラム言語が共通でなくてはならなかった。さらに、一般的なコメントに加えて、ソースコードの再生成に用いられる自動的に生成されたソースコードと開発者が追加したソースコードとを区別するためのコメントも挿入されるため、結果的にソースコードは一層読み難いものになってしまう。
【０００９】
本発明は、上記従来技術の問題を鑑み、上記課題の少なくとも一つを解決すべく、オブジェクト指向のソフトウェアに対する設計情報に基づいてソフトウェアの仕様書を作成するために用いられる仕様書作成装置、仕様書作成方法及び仕様書作成プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明は、設計モデルの記述形式に沿って記述されたオブジェクト指向のソフトウェアの設計情報、に基づいてソフトウェアの仕様書を作成する仕様書作成装置であって、設計対象となる対象設計情報を取得する設計情報取得手段と、前記設計情報取得手段において取得された対象設計情報を解析して仕様書の作成に必要な情報を抽出する設計情報解析手段と、前記設計情報解析手段において抽出された情報に基づいて、前記対象設計情報から生成されるソフトウェアの仕様書を出力する仕様書作成手段と、を含むことを特徴とする。
【００１１】
ここで、前記仕様書作成手段は、ユーザから仕様書作成の対象とするクラスの指定を受け、その指定されたクラスに関する仕様書を作成するものとすることができる。オブジェクト指向のソフトウェアでは、設計モデルに様々な依存関係が含まれるので、前記設計情報解析手段は、前記対象設計情報から２つ以上のクラス間の依存関係を抽出し、前記仕様書作成手段は、前記指定されたクラスと依存関係にあるクラスについて仕様書を作成することが好適である。また、前記設計情報解析手段は、前記対象設計情報からクラスに含まれるメンバ属性又はメンバ関数を示す情報を抽出し、前記仕様書作成手段は、前記指定されたクラス又はそれと依存関係にあるクラス、に含まれるメンバ属性又はメンバ関数について仕様書を作成することも好適である。
【００１２】
また、前記仕様書作成手段は、指定された言語に対応するソフトウェアの仕様書を作成することが好適である。同一の設計情報に基づいて複数の異なる言語で記述されたソフトウェアについての仕様書が作成できるのでユーザの利便性が高まる。
【００１３】
特に、前記仕様書作成手段は、ハイパーテキスト形式で仕様書を作成することが好適である。例えば、依存関係にあるクラスをリンクを伴って仕様書に記述したり、クラスに含まれるメンバ属性又はメンバ関数をリンクを伴って仕様書に記述したりすることによって利便性や視認性を向上することができる。
【００１４】
さらに、複数の設計情報の差分から前記対象設計情報を抽出する設計情報差分抽出手段を含むことも好適である。これにより、ソフトウェアのバージョンアップ等に対応した仕様書を作成することができる。
【００１５】
本発明の別の態様は、設計モデルの記述形式に沿って記述されたオブジェクト指向のソフトウェアの設計情報、に基づいてソフトウェアの仕様書を作成する仕様書作成方法であって、設計対象となる対象設計情報を取得する設計情報取得工程と、前記設計情報取得工程において取得された対象設計情報を解析して仕様書の作成に必要な情報を抽出する設計情報解析工程と、前記設計情報解析工程において抽出された情報に基づいて、前記対象設計情報から生成されるソフトウェアの仕様書を出力する仕様書作成工程と、を含むことを特徴とする。
【００１６】
上記と同様に、前記仕様書作成工程では、ユーザから仕様書作成の対象とするクラスの指定を受け、その指定されたクラスに関する仕様書が作成されるものとすることができる。ここで、前記設計情報解析工程では、前記対象設計情報から２つ以上のクラス間の依存関係が抽出され、前記仕様書作成工程では、前記指定されたクラスと依存関係にあるクラスについて仕様書が作成されることが好適である。また、前記設計情報解析工程では、前記対象設計情報からクラスに含まれるメンバ属性又はメンバ関数を示す情報が抽出され、前記仕様書作成工程では、前記指定されたクラス又はそれと依存関係にあるクラス、に含まれるメンバ属性又はメンバ関数について仕様書が作成されることも好適である。
【００１７】
また、前記仕様書作成工程では、ハイパーテキスト形式で仕様書が作成されることが好適である。例えば、依存関係にあるクラスがリンクを伴って仕様書に記述されたり、クラスに含まれるメンバ属性又はメンバ関数がリンクを伴って仕様書に記述されたりすることによってユーザの利便性や視認性を高めることができる。
【００１８】
また、本発明の別の態様は、設計モデルの記述形式に沿って記述されたオブジェクト指向のソフトウェアの設計情報、に基づいてソフトウェアの仕様書を作成する仕様書作成プログラムであって、コンピュータを、設計対象となる対象設計情報を取得する設計情報取得手段と、前記設計情報取得手段において取得された対象設計情報を解析して仕様書の作成に必要な情報を抽出する設計情報解析手段と、前記設計情報解析手段において抽出された情報に基づいて、前記対象設計情報から生成されるソフトウェアの仕様書を出力する仕様書作成手段と、を含む仕様書作成装置として機能させることを特徴とする。
【００１９】
上記と同様に、前記仕様書作成手段を、ユーザから仕様書作成の対象とするクラスの指定を受け、その指定されたクラスに関する仕様書を作成する手段として機能させることができる。ここで、前記設計情報解析手段を、前記対象設計情報から２つ以上のクラス間の依存関係を抽出する手段、前記仕様書作成手段を、前記指定されたクラスと依存関係にあるクラスについて仕様書を作成する手段、として機能させることが好適である。また、前記設計情報解析手段を、前記対象設計情報からクラスに含まれるメンバ属性又はメンバ関数を示す情報を抽出する手段、前記仕様書作成手段を、前記指定されたクラス又はそれと依存関係にあるクラス、に含まれるメンバ属性又はメンバ関数について仕様書を作成する手段、として機能させることも好適である。
【発明の効果】
【００２０】
本発明によれば、オブジェクト指向のソフトウェアを開発する際に、設計モデルを含む設計情報に基づいてソフトウェアの仕様書を作成することが可能となる。すなわち、ソースコードの言語に依存せず、開発者やユーザが理解し易い仕様書を生成することができる。
【発明を実施するための最良の形態】
【００２１】
本発明の実施の形態における仕様書作成装置１００は、図１に示すように、設計情報解析手段１０、設計情報保持手段１２及び仕様書作成手段１４を含んで構成される。仕様書作成装置１００は、図２に示すように、ＣＰＵを含む主処理部２０、キーボードやポインティングデバイス等からなる入力部２２、ディスプレイ等からなる出力部２４、仕様書作成プログラム、設計情報及び各種データを格納及び保持する半導体メモリやハードディスク等からなる記憶部２６、データ転送を担うネットワークカード等からなるインターフェース２８を含むコンピュータにより実現することができる。
【００２２】
設計情報に基づきソフトウェアの仕様書を作成する処理は、仕様書作成装置１００の記憶部２６に格納された仕様書作成プログラムを実行することによって行われる。仕様書作成方法は、図３に示すフローチャートの各工程に沿って処理される。
【００２３】
ステップＳ１０では、設計情報解析手段１０において、ソフトウェアの設計情報が解析される。ソフトウェアの設計情報は、図４に示すように、ＵＭＬ(Unified  Model  Language)のクラス図等によって表現されたオブジェクト指向に基づく設計モデルを含む情報３０とすることができる。但し、これに限定されるものではなく、設計モデルを含む設計情報として表現できる形式であれば良く、仕様書作成装置１００に固有の形式であっても構わない。
【００２４】
本実施の形態では、設計情報３０は、図５及び６に例示するように、ＸＭＩ(XML  Metadata  Interchange)によって記述されている情報として説明を行う。ＸＭＩは、ＵＭＬによって記述された情報をＸＭＬ(eXtensible  Markup  Language)形式で表現するためのフォーマットである。
【００２５】
主処理部２０は、入力部２２又はインターフェース２８を用いて、外部から設計情報３０を取得する。取得された設計情報３０は、記憶部２６に記憶される。そして、主処理部２０は、記憶部２６に保持されているパーサを実行することにより、ＸＭＩで記述された設計情報３０の構文を解析する。ＸＭＬパーサには、ＤＯＭパーサとＳＡＸパーサとがあり、ＤＯＭパーサはＸＭＬの構文を維持したままデータアクセスができる利便性を有するが、仕様書作成における工程ではデータアクセスが頻繁となり、処理速度の低下が顕著となるためにＳＡＸパーサでＸＭＬの構文を解析することが好ましい。ＸＭＩ及びＵＭＬのタグを解析するように設計されたＳＡＸパーサは、図５及び６に例示されたようなＸＭＩ形式の設計情報３０を解析する。
【００２６】
ステップＳ１２では、抽出された仕様書作成に必要な情報が仕様書作成手段１４で扱い易いデータ構造に変換されて記憶部２６を含んで構成される設計情報保持手段１２に保持される。
【００２７】
データ構造は、記憶部２６に以下の各種テーブルとして格納及び保持される。クラス用ハッシュテーブル４０には、図７に示すように、クラスのｘｍｉ．ｉｄ値とクラスの名前とが関連付けて保持される。ここで、ハッシュテーブルとは、キーと値とを関連付けて複数格納できるデータ構造のことを示す。ハッシュテーブルにキーを与えると、そのキーに関連付けて保持されている値を取り出すことができる。クラス用ハッシュテーブル４０では、クラスのｘｍｉ．ｉｄ値がキーとなる。
【００２８】
コメント用ハッシュテーブル４２には、図８に示すように、コメントのｘｍｉ．ｉｄ値とコメントの文字列とが関連付けて保持される。ここで、コメントのｘｍｉ．ｉｄ値がキーとなる。依存関係用ハッシュテーブル４４には、図９に示すように、依存元のクラスのｘｍｉ．ｉｄ値と依存先のクラスのｘｍｉ．ｉｄ値とが関連付けて保持される。ここで、依存元のクラスのｘｍｉ．ｉｄ値がキーとなる。依存先のクラスは複数存在する場合もあるため、ハッシュテーブルの値としては、ｘｍｉ．ｉｄ値文字列として使用されない文字を使って複数のｘｍｉ．ｉｄ値を連結した文字列や、またはｘｍｉ．ｉｄ値文字列を格納したリストへのポインタを格納する。リストとは、複数のデータ構造またはそのポインタを格納することができるデータ構造である。前者の場合には、依存先のクラスのｘｍｉ．ｉｄ値を使用するたびに連結文字列の分離作業が必要であるため、後者のほうが利便性が高い。コメントｉｄハッシュテーブル４６には、図１０に示すように、クラスのｘｍｉ．ｉｄ値とそのクラスに対するコメントのｘｍｉ．ｉｄ値とが関連付けて保持される。ここで、クラスのｘｍｉ．ｉｄ値がキーとなる。データ型用ハッシュテーブル４８には、図１１に示すように、データ型のｘｍｉ．ｉｄ値とデータ型とが関連付けて保持される。ここで、データ型のｘｍｉ．ｉｄ値がキーとなる。
【００２９】
クラスのデータ構造５０には、図１２に示すように、文字列又は値として保持可能なｘｍｉ．ｉｄ値や視認性(visibility)等の他に、メンバ属性のデータ構造又はそのポインタを格納したリスト５２やメンバ関数のデータ構造又はそのポインタを格納したリスト５４が保持される。さらに、ネストクラスのデータ構造又はそのポインタを格納するリストや親クラスのデータ構造又はそのポインタを格納するリスト等を保持させても良い。
【００３０】
メンバ属性のデータ構造５６には、図１２に示すように、文字列又は値として保持可能なメンバ属性のｘｍｉ．ｉｄ値、視認性(visibility)、属性名、データ型が保持される。メンバ関数のデータ構造５８には、図１２に示すように、メンバ関数のｘｍｉ．ｉｄ値、視認性(visibility)、関数名、戻り値の型が保持される。さらに、メンバ関数が引数を有する場合には、引数のデータ構造又はそのポインタを格納したリスト６０を保持する。リスト６０は、引数の順序も考慮したものとすることが好ましい。なぜなら、メンバ関数の引数の順序には意味があり、その順序が変わってしまうと異なるメンバ関数を意味することになるからである。
【００３１】
上記に挙げたクラス、メンバ属性、メンバ関数のデータ構造と同様に引数や戻り値等もデータ構造で表現できる。また、クラス、メンバ属性、メンバ関数の各々に対するコメントもデータ構造内に含めることもできるが、図５及び６に示したように、ＸＭＩではクラスについてのタグとコメントについてのタグは完全に異なる階層に位置する場合がほとんどであり、クラス、メンバ属性、メンバ関数のデータ構造内にコメントを含めるためにはＳＡＸパーサが複雑なものとなるので、図８及び１０に示したようにコメント用ハッシュテーブル４２やコメントｉｄハッシュテーブル４６のように登録することが好ましい。なお、各データ構造は、上記以外のデータや言語に固有なデータを保持するものとしても良い。
【００３２】
また、図１３に示すように、各クラスのクラス名をキーとして、データ構造を特定するポインタ等を保持するクラスハッシュテーブル６２を保持しておくことも好ましい。後の処理において指定されたクラスのみに対して仕様書を作成するような場合、仕様書を作成する対象となるクラスの指定はクラス名で行うのがユーザにとって利便性が高い。そこで、クラスハッシュテーブル６２のように、クラス名をキーとして仕様書の作成に必要なクラスのデータ構造を直接的に取得できるようにしておくことが好適である。
【００３３】
例えば、図１３のクラスハッシュテーブル６２では、クラス名“Ｃｌａｓｓ１”をキーとして、Ｃｌａｓｓ１のデータ構造５０へのポインタ１が関連付けて保持されている。また、パッケージｆｏｏ：：ｖａｒに属するＣｌａｓｓ１１の場合、スコープ文字列“：：”を“／”に変換して連結した文字列“ｆｏｏ／ｖａｒ／Ｃｌａｓｓ１１”をキーとして、ｆｏｏ：：ｖａｒ：：Ｃｌａｓｓ１１のデータ構造６４へのポインタ１１が関連付けて保持されている。また、パッケージｆｏｏに属するＣｌａｓｓ２２のネストクラスＣｌａｓｓ３３の場合、パッケージとクラスとの間のスコープ文字列“：：”を“／”に、クラス間のスコープ文字列“：：”を“＃”に変換して連結した文字列“ｆｏｏ／Ｃｌａｓｓ２２＃Ｃｌａｓｓ３３”をキーとして、ｆｏｏ：：Ｃｌａｓｓ２２：：Ｃｌａｓｓ３３のデータ構造６６へのポインタ３３が関連付けて保持されている。
【００３４】
このように、クラスハッシュテーブル６２を登録することによって、異なるパッケージに属する同名のクラスを区別して登録することができ、クラス名を指定することにより必要なデータ構造を取得することができる。
【００３５】
このように得られたデータ構造が仕様書作成手段１４に引き渡され、仕様書が作成される。以下のステップＳ１４及びＳ１６で処理が仕様書作成手段１４の機能を実現する。
【００３６】
ステップＳ１４では、仕様書を作成する対象となるクラスが指定される。ユーザは、入力部２２を用いて、仕様書を作成しようとするクラスのクラス名を入力する。主処理部２０は、入力されたクラス名を受けて、以下の仕様書の作成に利用する。
【００３７】
ステップＳ１６では、指定された言語によるインターフェースの仕様書が作成される。まず、主処理部２０は、クラスハッシュテーブル６２を参照して入力されたクラス名に対応するデータ構造を取得する。例えば、仕様書の作成対象としてクラス名“Ｃｌａｓｓ１”が入力された場合、図１３のクラスハッシュテーブル６２の例では、クラス名“Ｃｌａｓｓ１”に関連付けられているポインタ１を辿ることによりＣｌａｓｓ１のデータ構造５０を取得することができる。
【００３８】
クラスのデータ構造が取得されると、そこに登録されているクラスのｘｍｉ．ｉｄ値を用いてコメントｉｄハッシュテーブル４６からそのクラスに対するコメントのｘｍｉ．ｉｄ値を取得する。例えば、図１２のＣｌａｓｓ１のデータ構造５０の例では、クラスのｘｍｉ．ｉｄ値は“Ｓ．１”であるので、図１０のコメントｉｄハッシュテーブル４６を参照するとＣｌａｓｓ１に対するコメントのｘｍｉ．ｉｄ値として“ＸＸ．３”を得ることができる。
【００３９】
コメントのｘｍｉ．ｉｄ値が取得されると、コメント用ハッシュテーブル４２が参照され、対象となったクラスに対するコメントが取得される。例えば、図１０のコメントｉｄハッシュテーブル４６からコメントのｘｍｉ．ｉｄ値として“ＸＸ．３”が得られたとすると、図８のコメント用ハッシュテーブルから“対象クラス”という文字列がコメントとして得られる。この文字列“対象クラス”がＣｌａｓｓ１に対するコメントである。
【００４０】
このように、各データ構造及び各テーブルを遡って得られたコメントは、適宜整形されて出力部２４に仕様書として出力される。
【００４１】
また、クラスのデータ構造に登録されているポインタに基づいてメンバ属性についても仕様書を作成することができる。まず、メンバ属性を示すポインタで特定されるメンバ属性のデータ構造を取得する。例えば、図１２のＣｌａｓｓ１のデータ構造５０の例では、登録されたポインタに基づいてメンバ属性のデータ構造５６が取得される。
【００４２】
次に、メンバ属性のデータ構造５６の視認性(visibility)を確認し、その視認性に応じてそのメンバ属性に対する仕様書の表示形式を変更する。例えば、図１２のデータ構造５６において視認性は“private”であるので、メンバ属性の視認性が“private”である場合にそのメンバ属性の仕様書を作成するように指定されているなら仕様書を作成する。このように、メンバ属性毎にそのデータ構造内に視認性を登録しておくことによって、その視認性に基づいて仕様書の作成が許可されたメンバ属性であるか、どのような仕様書を作成したらよいか等の仕様書の作成条件を決定することができる。
【００４３】
仕様書を作成する必要がある場合、メンバ属性のデータ構造に基づいてメンバ属性に対するコメントを取得して仕様書に記述する。図１２のデータ構造５６では、属性“ａｔｔｒ１”のｘｍｉ．ｉｄ値は“Ｓ．２”であるので、コメントｉｄハッシュテーブル４６を参照して、属性“ａｔｔｒ１”に対するコメントのｘｍｉ．ｉｄ値の取得を試みる。ここでは、コメントｉｄハッシュテーブル４６には“Ｓ．２”に関連付けられたコメントのｘｍｉ．ｉｄ値は登録されておらず、仕様書にコメントは記述しない。一方、コメントｉｄハッシュテーブル４６にメンバ属性に対するコメントのｘｍｉ．ｉｄ値が登録されていた場合には、コメント用ハッシュテーブル４２を参照してコメントを取得し、そのコメントをメンバ属性に対するコメントとして仕様書内に記述する。
【００４４】
次に、メンバ属性のデータ構造からデータ型のｘｍｉ．ｉｄ値が取得され、メンバ属性のデータ型が仕様書に記述される。例えば、図１２のデータ構造５６ではデータ型のｘｍｉ．ｉｄ値が“Ｇ．２”と登録されているので、データ型用ハッシュテーブル４８が参照され、データ型のｘｍｉ．ｉｄ値が“Ｇ．２”に関連付けられて登録されているデータ型“ｉｎｔ”が取得され、メンバ属性“ａｔｔｒ１”のデータ型として“ｉｎｔ”が仕様書に追加される。
【００４５】
また、クラスのデータ構造に登録されているポインタに基づいてメンバ関数についても仕様書を作成することができる。まず、メンバ関数を示すポインタで特定されるメンバ関数のデータ構造を取得する。例えば、図１２のＣｌａｓｓ１のデータ構造５０の例では、登録されたポインタに基づいてメンバ関数のデータ構造５８が取得される。
【００４６】
次に、メンバ属性の場合と同様に、メンバ関数のデータ構造５８の視認性(visibility)を確認し、その視認性に応じてそのメンバ関数に対する仕様書の表示形式を変更する。例えば、図１２のデータ構造５８において視認性は“public”であるので、メンバ関数の視認性が“public”である場合にそのメンバ関数の仕様書を作成するように指定されているなら仕様書を作成する。このように、メンバ関数毎にそのデータ構造内に視認性を登録しておくことによって、その視認性に基づいて仕様書の作成が許可されたメンバ関数であるか、どのような仕様書を作成したらよいか等の仕様書の作成条件を決定することができる。
【００４７】
仕様書を作成する必要がある場合、メンバ関数のデータ構造に基づいてメンバ関数に対するコメントを取得して仕様書に記述する。図１２のデータ構造５８では、メンバ関数“ｅｘｅｃｕｔｅ”のｘｍｉ．ｉｄ値は“Ｓ．３”であるので、コメントｉｄハッシュテーブル４６を参照して、メンバ関数“ｅｘｅｃｕｔｅ”に対するコメントのｘｍｉ．ｉｄ値の取得を試みる。コメントｉｄハッシュテーブル４６から“Ｓ．３”に関連付けられたコメントのｘｍｉ．ｉｄ値“ＸＸ．４”が取得される。主処理部２０は、コメント用ハッシュテーブル４２を参照し、取得されたコメントのｘｍｉ．ｉｄ値“ＸＸ．４”に関連付けられた文字列“処理を実行する”をメンバ関数“ｅｘｅｃｕｔｅ”に対するコメントとして取得し、仕様書のコメント記述箇所に記述する。
【００４８】
次に、メンバ関数の戻り値のデータ型のｘｍｉ．ｉｄ値が取得され、メンバ関数の戻り値のデータ型が仕様書に記述される。例えば、図１２のデータ構造５８ではデータ型のｘｍｉ．ｉｄ値が“Ｇ．３”と登録されているので、データ型用ハッシュテーブル４８が参照され、データ型のｘｍｉ．ｉｄ値が“Ｇ．３”に関連付けられて登録されているデータ型“ｖｏｉｄ”が取得され、メンバ関数“ｅｘｅｃｕｔｅ”の戻り値のデータ型として“ｖｏｉｄ”が仕様書に追加される。
【００４９】
さらに、引数のリストに基づいて、メンバ関数に引き渡される引数に関する情報が仕様書に記述される。引数のリストにはデータ構造又はそのポインタが格納されており、上記のメンバ属性と同様に引数に対するコメントやデータ型などを仕様書に記述することができる。このとき、リストに登録された引数の順序に沿って各引数の情報を仕様書に記述することが好ましい。
【００５０】
同様に、ステップＳ１４で指定された他のクラスについても仕様書を記述することができ、全体としてソースコードのインターフェース仕様書を作成することができる。仕様書は予め指定された言語に合わせて作成される。例えば、指定された言語がＣ＋＋であればＣ＋＋のインターフェースの仕様に合わせた記述で仕様書が作成され、指定された言語がＪａｖａ（登録商標）であればＪａｖａ（登録商標）のインターフェースの仕様に合わせた記述で仕様書が作成される。指定された言語で使われない設計情報は無視しても良い。
【００５１】
このように、同一の設計情報に基づいて複数の異なる言語で記述されたソフトウェアについての仕様書が作成できるのでユーザの利便性が高まる。
【００５２】
仕様書は通常のテキストデータとして記述しても良いし、ハイパーテキスト形式として記述しても良い。特に、図１７及び１８に示すようなフレーム表示されるハイパーテキスト形式として出力されればユーザにとっての利便性や視認性を高くすることができる。例えば、図１７に示すフレーム７０の場合、２分割された一方のフレーム７２には各クラスの仕様書に対するページへのリンクを示すクラス名を表示し、ユーザが入力部２２によっていずれかのクラスを指定すると、他方のフレーム７４に指定されたクラスの仕様書が記述されたページを表示する。また、図１８に示すフレーム７６の場合、３分割された１つのフレーム７８にはリンクを伴うパッケージ名の一覧を示し、ユーザから入力部２２によっていずれかのパッケージ名を指定すると、フレーム８０に指定されたパッケージに属するクラス名の一覧を示す。さらに、ユーザが入力部２２を用いてフレーム８０に表示されたクラス名の一覧のいずれかのクラスを指定すると、フレーム８２に指定されたクラスに対する仕様書が記述されたページを表示する。
【００５３】
また、各クラスに属するメンバ属性やメンバ関数についても、クラス名からのリンクを用いて表示することも好適である。例えば、図１８のフレーム８２に表示されたクラスに対する仕様書のなかにメンバ属性やメンバ関数の名前が含まれる場合に、その名前にそれぞれのメンバ属性やメンバ関数の内容を示す仕様書の情報へのリンクを伴わせておくことによって、ユーザがメンバ属性やメンバ関数を指定した場合に指定されたメンバ属性やメンバ関数の仕様書を表示させることができる。
【００５４】
なお、仕様書を作成する言語がＣ＋＋である場合には、フレーム７８にリンクを伴うヘッダファイル名の一覧を表示し、いずれかのリンクを指定すると、フレーム８０に該当するヘッダファイルに属するリンクを伴うクラス名の一覧を表示するようにしてもよい。
【００５５】
以上のように、本実施の形態によれば、プログラミング言語に依存しないソフトウェアの設計モデルに基づいてソースコードの仕様書を作成できる。このとき、プログラミング言語に依存しない１種類の設計モデルに対するコメントやタグの記述の形式を理解しておけば良く、ソフトウェアの作成者の負担を低減することができる。また、ソースコードに仕様書作成のための不要なコメントを埋め込む必要がなくなり、ソフトウェア開発者に対するソースコードの理解性を高めることができる。
【００５６】
さらに、設計モデルを開発した時点で仕様書を作成することができるので、ソースコードが作成されるまで仕様書を確認できない不都合を回避することができる。その結果、ソフトウェアの開発プロセスにおける無駄な手間を排除することができる。
【００５７】
また、ソフトウェアの設計情報が更新された場合には、更新後の設計情報と更新前の設計情報との差分情報に基づいて仕様書を作成することによって、更新に伴って新たに付加された箇所のみについて仕様書を作成することもできる。これによって、ソフトウェアのバージョンアップ等を行った際に、追加すべき仕様書のみを効率的に作成することができる。
【００５８】
＜変形例１＞
上記実施の形態では、依存関係のないクラスについて仕様書を作成する手順について説明を行った。この変形例１では、クラス間に依存関係がある場合についての仕様書の作成について説明する。
【００５９】
オブジェクト指向の設計モデルにおけるクラス間の依存関係としては、一般的に依存、関連、継承又はネストが挙げられる。以下では、これらの総称して依存関係と云う。依存関係には、継承の継承などの複数回にわたる依存関係も含まれる。例えば、図１４に示す例では、Ｃｌａｓｓ１００はＣｌａｓｓ１０１を継承（Ｉ１）しており、Ｃｌａｓｓ１００はＣｌａｓｓ１０３に依存（Ｄ２）している。さらに、Ｃｌａｓｓ１０２はＣｌａｓｓ１０１及びＣｌａｓｓ２００の両方のクラスに関連（Ｒ３，Ｒ４）されている。ただし、以下の処理はこれらの依存関係に限定されるものではなく、オブジェクト指向のソフトウェアの設計モデルで許可される記述であって、２以上のクラス間に何らかの繋がりを示す記述について適用することができる。
【００６０】
クラス間の依存関係を含めた仕様書を作成する場合、図３に示したフローチャートにおけるステップＳ１４において、指定されたクラスの依存関係を調査する。クラス間の依存関係は、図１５及び１６に示すフローチャートにより調べることができる。
【００６１】
ステップＳ２０では、仕様書を作成する対象となるクラスを示す情報を格納するための空のリストＡを用意する。例えば、ソフトウェアの設計情報がＸＭＩで表現されている場合には、各クラスに固有のｘｍｉ．ｉｄ値を格納するためのリストＡを用意する。また、ここでは、リストＡを用いて処理を行うが、同一のオブジェクトの重複した格納を許可しないセットや配列を用いても良い。
【００６２】
ステップＳ２２では、仕様書の作成が指定されたクラスの番号を１に設定すると共にカウンタＩを１に初期設定する。ここでは、図１４におけるＣｌａｓｓ１００及びＣｌａｓｓ２００が指定されたものとして、Ｃｌａｓｓ１００の番号を１及びＣｌａｓｓ２００の番号を２に設定する。
【００６３】
ステップＳ２４では、カウンタＩで特定されるクラスがリストＡに登録されているか否かが判断される。カウンタＩで特定されるクラスがリストＡに登録されている場合には処理をステップＳ２６に移行させ、登録されていない場合には処理をステップＳ３０に移行させる。
【００６４】
ここでは、リストＡは空であるのでカウンタＩ＝１で特定されるＣｌａｓｓ１００は未だ登録されておらず、処理はステップＳ３０に移行される。
【００６５】
ステップＳ３０では、カウンタＩで特定されるクラスをリストＡに登録する。このとき、カウンタＩで特定されるクラスのｘｍｉ．ｉｄ値を登録することが好ましい。ここでは、カウンタＩ＝１で特定されるＣｌａｓｓ１００のｘｍｉ．ｉｄ値がリストＡに登録される。
【００６６】
続くステップＳ３２はサブルーチン化されており、カウンタＩで特定されるクラスと依存関係にあるクラスの調査が行われる。カウンタＩで特定されるクラスが対象クラスに指定され、図１６のサブルーチンのステップＳ４０に処理が移行される。
【００６７】
ステップＳ４０では、対象クラスとされたカウンタＩで特定されるクラスを関係元とする依存関係を有するクラスが存在するか否かが判断される。対象クラスを関係元とした依存関係を有するクラスが存在する場合にはステップＳ４２に処理を移行させ、存在しない場合にはサブルーチンからメインルーチンのステップＳ２６に処理を戻す。
【００６８】
例えば、カウンタＩ＝１でありＣｌａｓｓ１００が対象クラスに指定された場合、Ｃｌａｓｓ１００が継承（Ｉ１）するＣｌａｓｓ１０１及びＣｌａｓｓ１００が依存（Ｄ２）するＣｌａｓｓ１０３とが存在するので処理はステップＳ４２に移行される。
【００６９】
ステップＳ４２では、カウンタＪを１に初期設定すると共に、対象クラスを関係元とした依存関係を有する各クラスに１から順に番号を割り当てる。ここでは、対象クラスであるＣｌａｓｓ１００が継承（Ｉ１）するＣｌａｓｓ１０１に１が割り当てられ、Ｃｌａｓｓ１００が依存（Ｄ２）するＣｌａｓｓ１０３に２が割り当てられたものとする。
【００７０】
ステップＳ４４では、カウンタＪの番号が割り当てられたクラスがリストＡに登録されているか否かが判断される。カウンタＪの番号が割り当てられたクラスがリストＡに既に登録されていなければステップＳ４６に処理を移行させ、リストＡに登録されていればステップＳ５０に処理を移行させる。ここでは、カウンタＪ＝１が割り当てられたＣｌａｓｓ１０１がリストＡに登録されているか否かが判断される。Ｃｌａｓｓ１０１は未だ登録されていないので、処理はステップＳ４６に移行される。
【００７１】
ステップＳ４６では、カウンタＪで特定されるクラスをリストＡに登録する。このとき、カウンタＪで特定されるクラスのｘｍｉ．ｉｄ値を登録することが好ましい。ここでは、カウンタＪ＝１で特定されるＣｌａｓｓ１０１のｘｍｉ．ｉｄ値がリストＡに登録される。
【００７２】
ステップＳ４８では、カウンタＪで特定されるクラスと依存関係にあるクラスの調査が行われる。カウンタＪで特定されるクラスが対象クラスに指定され、サブルーチンのステップＳ４０から再帰処理が行われる。この再帰処理により、依存関係元のクラスから依存関係にあるクラスが遡って調査されリストＡに登録される。再帰処理が総て終了するとステップＳ５０に処理が移行される。
【００７３】
ここでは、カウンタＪ＝１で特定されるＣｌａｓｓ１０１が対象クラスに指定されるので、再帰処理におけるステップＳ４０〜ステップＳ４６においてＣｌａｓｓ１０１が関連（Ｒ３）するＣｌａｓｓ１０２のｘｍｉ．ｉｄ値が新たにリストＡに登録される。
【００７４】
ステップＳ５０では、カウンタＪの値が１だけ増加される。そして、ステップＳ５２において、対象クラスとされたクラスを関係元としてカウンタＪの値に相当する依存関係を有するクラスが存在するか否かが判断される。対象クラスを関係元とした依存関係を有するクラスが存在する場合にはステップＳ４４に処理を戻し、存在しない場合にはサブルーチンからメインルーチンのステップＳ２６に処理を戻す。
【００７５】
例えば、Ｃｌａｓｓ１００が対象クラスであり、カウンタＪ＝２となった場合には、Ｃｌａｓｓ１００が依存（Ｄ２）するＣｌａｓｓ１０３に２が割り当てられているので依存関係を有するクラスが存在するものとして処理がステップＳ４４に戻される。そして、ステップＳ４４〜ステップＳ５０の処理が再度行われ、Ｃｌａｓｓ１０３が新たにリストＡに登録されると共に、ステップＳ４８における再帰処理によってＣｌａｓｓ１０３を関係元とした依存関係を有するクラスのｘｍｉ．ｉｄ値もリストＡに登録される。
【００７６】
以上のようにして、Ｃｌａｓｓ１００を関係元とした依存関係を有するクラスについてリストＡへの登録が行われる。
【００７７】
メインルーチンのステップＳ２６では、カウンタＩが１だけ増加される。そして、ステップＳ２８において、カウンタＩで特定される指定クラスが存在するか否かが判断される。カウンタＩで特定される指定クラスが存在する場合にはステップＳ２４に処理を戻し、存在しない場合にはクラス間に依存関係の調査を終了する。
【００７８】
ここでは、カウンタＩ＝２で特定されるＣｌａｓｓ２００が存在するので、ステップＳ２４に処理を戻し、Ｃｌａｓｓ２００を指定クラスとしてクラス間の依存関係の調査及びリストＡへの登録が行われる。
【００７９】
ステップＳ２４では、カウンタＩ＝２で特定されるＣｌａｓｓ２００は未だ登録されておらず、処理はステップＳ３０に移行される。ステップＳ３０では、カウンタＩ＝２で特定されるＣｌａｓｓ２００のｘｍｉ．ｉｄ値がリストＡに登録される。続いて、ステップＳ３２のサブルーチンによりＣｌａｓｓ２００を関係元とするクラスについて調査が行われる。ステップＳ４０では、Ｃｌａｓｓ２００から関連（Ｒ４）するＣｌａｓｓ１０２が存在するので処理はステップＳ４２に移行される。ステップＳ４２では、対象クラスであるＣｌａｓｓ２００が関連（Ｒ４）するＣｌａｓｓ１０２に１が割り当てられると共に、カウンタＪが１に初期化される。ステップＳ４４では、カウンタＪの番号が割り当てられたクラスがリストＡに登録されているか否かが判断される。ここでは、カウンタＪ＝１が割り当てられたＣｌａｓｓ１０２は既にリストＡに登録されているので処理はステップＳ５０に移行される。ステップＳ５０では、カウンタＪの値が１だけ増加される。そして、ステップＳ５２において、対象クラスとされたＣｌａｓｓ２００を関係元としてカウンタＪの値に相当する依存関係を有するクラスが存在するか否かが判断される。Ｃｌａｓｓ２００には２つ以上の依存関係を有するクラスが存在しないのでメインルーチンのステップＳ２６に処理が戻される。
【００８０】
メインルーチンのステップＳ２６では、カウンタＩが１だけ増加される。そして、ステップＳ２８において、カウンタＩで特定される指定クラスが存在するか否かが判断される。ここでは、カウンタＩ＝３で特定されるクラスは存在しないのでクラス間の依存関係の調査及び登録の処理が終了する。
【００８１】
このようにリストＡに依存関係にあるクラスを登録することによって、以下は上記実施の形態と同様にリストＡに登録されたクラスについて指定した言語に合わせて仕様書を作成することができる。
【００８２】
また、このようにクラス間の依存関係を調査して仕様書を作成する場合、特に、図１７及び１８に示すようなフレーム表示されるハイパーテキスト形式として出力されればユーザにとっての利便性や視認性を高くすることができる。
【００８３】
仕様書をハイパーテキスト形式とした場合にあるクラスの仕様書中に他のクラスへのリンクを伴うものとするとユーザにとって利便性が高くなる。
【００８４】
例えば、図１９のようにクラスＡとクラスＢとの関係が示されるとする。ここで、（ａ）の関係はＣｌａｓｓＡがＣｌａｓｓＢをネストする関係、（ｂ）の関係はＣｌａｓｓＢがＣｌａｓｓＡをネストする関係、（ｃ）はＣｌａｓｓＡがＣｌａｓｓＢを継承（Ｉ）する関係、（ｄ）はＣｌａｓｓＡがＣｌａｓｓＢに関連（Ｒ）する関係、（ｅ）はＣｌａｓｓＡがＣｌａｓｓＢに依存（Ｄ）する関係を示している。
【００８５】
このとき、２つのクラスがネスト及び継承（Ｉ）の関係にある場合には、たとえＣｌａｓｓＢと同名のクラスが存在していたとしても、ＣｌａｓｓＡの仕様書ではＣｌａｓｓＢにリンクを伴うように処理する。なぜなら、ネスト及び継承（Ｉ）の関係にある場合には、ＣｌａｓｓＢをＣｌａｓｓＡの関係先のクラスとしてもほぼ間違いがないからである。
【００８６】
一方、２つのクラスが関連（Ｒ）及び依存（Ｄ）の関係にある場合には、パッケージ階層等の他の基準をも考慮してリンクを伴わせるか否かを判断することが好ましい。なぜなら、関連（Ｒ）及び依存（Ｄ）の関係にある場合には、ＣｌａｓｓＡがＣｌａｓｓＢと同名のＣｌａｓｓＢとは別のクラスとの関係をさらに有する可能性があり、確実とは言えないからである。
【図面の簡単な説明】
【００８７】
【図１】本発明の実施の形態における仕様書作成装置の機能ブロックを示す図である。
【図２】本発明の実施の形態における仕様書作成装置を実現する構成を示すブロック図である。
【図３】本発明の実施の形態における仕様書作成方法のフローチャート示す図である。
【図４】ＵＭＬによるソフトウェアの設計情報の例を示す図である。
【図５】ＸＭＩ形式で記述されたソフトウェアの設計情報の例を示す図である。
【図６】ＸＭＩ形式で記述されたソフトウェアの設計情報の例を示す図である。
【図７】本発明の実施の形態におけるクラス用ハッシュテーブルの例を示す図である。
【図８】本発明の実施の形態におけるコメント用ハッシュテーブルの例を示す図である。
【図９】本発明の実施の形態における依存関係用ハッシュテーブルの例を示す図である。
【図１０】本発明の実施の形態におけるコメントｉｄハッシュテーブルの例を示す図である。
【図１１】本発明の実施の形態におけるデータ型用ハッシュテーブルの例を示す図である。
【図１２】本発明の実施の形態におけるクラスのデータ構造の例を示す図である。
【図１３】本発明の実施の形態におけるクラスハッシュテーブルの例を示す図である。
【図１４】クラスの依存関係の例を示す図である。
【図１５】本発明の実施の形態の変形例１におけるクラス間の依存関係の調査方法のフローチャートを示す図である。
【図１６】本発明の実施の形態の変形例１におけるクラス間の依存関係の調査方法のフローチャートを示す図である。
【図１７】本発明の実施の形態におけるソフトウェアの仕様書を表示する際のフレーム構成を示す図である。
【図１８】本発明の実施の形態におけるソフトウェアの仕様書を表示する際のフレーム構成を示す図である。
【図１９】クラスの依存関係の例を示す図である。
【符号の説明】
【００８８】
１０  設計情報解析手段、１２  設計情報保持手段、１４  仕様書作成手段、２０  主処理部、２２  入力部、２４  出力部、２６  記憶部、２８  インターフェース、３０  設計情報、４０  クラス用ハッシュテーブル、４２  コメント用ハッシュテーブル、４４                                  依存関係用ハッシュテーブル、４６  コメントｉｄハッシュテーブル、４８  データ型用ハッシュテーブル、５０，５６，５８，６４，６６  データ構造、５２，５４，６０  リスト、６２  クラスハッシュテーブル、７０，７２，７４，７６，７８，８０，８２  フレーム、１００  仕様書作成装置。
.
【図１】
2005258561.tif 000003
【図２】
2005258561.tif 000004
【図３】
2005258561.tif 000005
【図４】
2005258561.tif 000006
【図５】
2005258561.tif 000007
【図６】
2005258561.tif 000008
【図７】
2005258561.tif 000009
【図８】
2005258561.tif 000010
【図９】
2005258561.tif 000011
【図１０】
2005258561.tif 000012
【図１１】
2005258561.tif 000013
【図１２】
2005258561.tif 000014
【図１３】
2005258561.tif 000015
【図１４】
2005258561.tif 000016
【図１５】
2005258561.tif 000017
【図１６】
2005258561.tif 000018
【図１７】
2005258561.tif 000019
【図１８】
2005258561.tif 000020
【図１９】
2005258561.tif 000021