JP2006106893A - 仕様管理装置、仕様管理方法及び仕様管理プログラム - Google Patents

Abstract

【課題】 システム及びソフトウェアの仕様の定義決定、登録、更新等を行い、この仕様を基に正式なドキュメントを正確に作成する仕様管理装置、仕様管理方法及び仕様管理プログラムを提供する。
【解決手段】
仕様管理装置１００は、設計メタ情報記憶部２１及び設計情報記憶部２２を備えるデータベース格納部２０、制約エラー記憶部３１、変更点記憶部３２及びトレース記憶部３３等から構成されるテンポラリデータ格納部３０、管理者が設計メタ情報を定義する設計メタ情報定義部１１、ユーザが設計情報を定義する設計情報定義部１２、設計情報全体にバージョンを設定する設計情報構成管理部１３、設計情報検証管理部１４、設計情報トレース管理部１５及び設計書生成部１６等から構成される仕様定義トレース管理部１０を備える。
【選択図】 図１

Description

本発明は、システム及びソフトウェアの仕様の定義決定、登録、更新等を行い、この仕様を基に正式なドキュメントを作成する仕様管理装置、仕様管理方法及び仕様管理プログラムに関する。

システム及びソフトウェアの開発を行う際には、これらの作業のアウトプットとしてドキュメントを別途作成する必要がある。このドキュメントとしては、例えば、設計の図面やプログラムの仕様等があり、作成はＣＡＳＥツール等を用いて行われる。

尚、システム及びソフトウェアの開発では、分析、設計、開発、テストのライフサイクルを考慮する必要がある。これらのライフサイクルの入力情報は、顧客からの要件を基に決定される。この顧客要件は、ライフサイクルを通じて、要求仕様、機能仕様、設計仕様、テストシナリオ、コンポーネント、テスト結果、製品等に具体化される。同様に、ライフサイクルを通じて、要求仕様書、機能仕様書、ソフトウェア・システム設計書、テスト仕様書、テスト成績書、詳細設計書、テスト完了報告書、出荷報告書等のドキュメントに文書化される。

このようにシステム及びソフトウェアを開発する際に、設計及びそのドキュメント作成において、ソフトウェアを構成する設計要素をオブジェクトとして捉え、関連するオブジェクトを閲覧できるようにする手法（特許文献１参照。）が開示されている。
特開２００１−２７９４７号公報

しかしながら、既存のＣＡＳＥ(Computer Aided Software Engineering :コンピュータ支援ソフトウェア工学)ツールでは、ドキュメントの図面、仕様等は、正式な設計仕様書、要求仕様書のドキュメントを構成する要素の一部または断片に過ぎず、正式な設計仕様書、要求仕様書を作成するには、表紙、目次、章立、変更履歴及び裏表紙等を定義し、また各章節には、概要や条件を示す文章等を記述する必要があった。又、機能の要件に変更があった場合、ＣＡＳＥツールとドキュメント間との連携はないため、ＣＡＳＥツール等を利用して作成した部分の修正と、正式なドキュメント上への修正の反映は、分離して行わねばならなかった。

特許文献１においては、オブジェクト（モデル）とドキュメントに分離された状態で、各項目のリレーション情報を詳細に定義することはできなかった。又、設計の一部の要素とプログラム及びテスト結果の関係等の管理を行っていても、ライフサイクル全体を通じて、要求仕様、機能仕様、設計仕様、テストシナリオ、コンポーネント、テスト結果、製品に具体化されていく個々の要素の相互関係を管理することはできなかった。

更に、特許文献１を初めとする従来の技術においては、あるモデルに修正が生じた場合、修正の影響範囲や、関連したモデルをどのように修正すればよいかが不明瞭であった。従って、顧客要求に変更が生じた場合、要求の変更が、どの範囲まで波及するのかは、開発者に依存することとなり、特定の要件の変更が、どの機能、どのプログラム、どのコンポーネント等に及ぶのかを判断してモデル要素の修正を行う際には開発者の経験等に頼るしかなかった。

又、要求仕様書、設計仕様書、詳細設計書等のドキュメントは、修正したモデル要素に基づいて修正される為、ドキュメントの作成においても開発者の経験やスキルレベルにより変更管理処理に違いが生じ、システム・ソフトウェア全体の品質低下をもたらすこととなっていた。

本発明は、上記問題点を解決する為になされたものであり、システム及びソフトウェアの仕様の定義決定、登録、更新等を行い、この仕様を基にドキュメントを作成する仕様管理装置、仕様管理方法及び仕様管理プログラムを提供することを目的とする。

上記問題点を解決する為、本発明の第１の特徴は、ソフトウェア若しくはシステムの仕様の管理者が使用する管理者端末及び仕様を生成するユーザが使用するユーザ端末に接続される仕様管理装置であって、管理者端末によって定義されるモデルクラスのデータ、モデル間関連クラスのデータ、ドキュメントクラスのデータ及びモデルドキュメント間関連クラスのデータを含む設計メタ情報を格納する設計メタ情報記憶部（２１）と、設計メタ情報記憶部（２１）内の設計メタ情報を基にユーザ端末にて定義されるモデルインスタンスのデータ、モデル間関連インスタンスのデータ、ドキュメントインスタンスのデータ及びモデルドキュメント関連インスタンスのデータを含む設計情報を格納する設計情報記憶部（２２）と、モデルインスタンス、モデル間関連インスタンス、ドキュメントインスタンス及びモデルドキュメント関連インスタンスの各々が備える、クラス制約条件、インスタンス制約条件及び特定インスタンス制約条件を設計情報が満たしているかを検証する設計情報検証部（１４）とを備える仕様管理装置であることを要旨とする。

本発明の第２の特徴は、ソフトウェア若しくはシステムの仕様の管理者が使用する管理者端末及び仕様を生成するユーザが使用するユーザ端末に接続される仕様管理装置であって、管理者端末によって定義される設計メタ情報を格納する設計メタ情報記憶部（２１）と、設計メタ情報記憶部（２１）内の設計メタ情報を基にユーザ端末にて定義される設計情報を格納する設計情報記憶部（２２）と、設計情報記憶部（２２）内の設計情報の各々にバージョンを設定する設計情報構成管理部（１３）と、設計情報構成管理部（１３）にて設定された第１バージョンの設計情報及び第２バージョンの設計情報を取得し、第１バージョンの設計情報と第２バージョンの設計情報との間の変更点を検出し、変更点によって影響を受けるモデルを修正影響範囲として検出してユーザ端末に提示し、トレース処理を行った結果をユーザ端末に提示する設計情報トレース管理部（１５）と、設計情報の変更点の履歴を格納する変更点記憶部（３２）とを備える仕様管理装置であることを要旨とする。

本発明の第３の特徴は、ソフトウェア若しくはシステムの仕様の管理者が使用する管理者端末及び仕様を生成するユーザが使用するユーザ端末に接続される仕様管理装置であって、管理者端末によって定義される設計メタ情報を格納する設計メタ情報記憶部（２１）と、設計メタ情報記憶部（２１）内の設計メタ情報を基にユーザ端末にて定義される設計情報を格納する設計情報記憶部（２２）と、ユーザ端末より受信するドキュメント生成要求に基づいて、設計情報記憶部（２２）より設計情報を取得し、仕様書を作成する設計書生成部（１６）とを備える仕様管理装置であることを要旨とする。

本発明の第４の特徴は、ソフトウェア若しくはシステムの仕様の管理者が使用する管理者端末及び仕様を生成するユーザが使用するユーザ端末に接続される仕様管理装置であって、モデルクラスのデータ、モデル間関連クラスのデータ、ドキュメントクラスのデータ及びモデルドキュメント間関連クラスのデータを含む設計メタ情報を管理者端末からの要求により定義する設計メタ情報定義部（１１）と、設計メタ情報定義部（１１）にて定義された設計メタ情報を格納する設計メタ情報記憶部（２１）と、モデルインスタンスのデータ、モデル間関連インスタンスのデータ、ドキュメントインスタンスのデータ及びモデルドキュメント関連インスタンスのデータを含む設計情報をユーザ端末からの要求により定義する設計情報定義部（１２）と、設計情報定義部（１２）にて定義された設計情報を格納する設計情報記憶部（２２）とを備え、設計メタ情報及び設計情報の各々が示す情報は、情報の名称、属性及び情報を定義する操作より構成され、モデルクラスは仕様の最小単位の型であり、モデル間関連クラスは、モデルクラスとして定義した任意の２つのモデルクラス間の関連の型であり、ドキュメントクラスは、仕様の開発の際に作成するドキュメントの最小単位の型であり、モデルドキュメント間関連クラスは、モデルクラスとドキュメントクラスの間の関連の型であり、モデルインスタンスは、仕様の最小単位の実体であり、属性としてモデルクラスの識別子、インスタンスの識別子及び子となるモデルインスタンスの識別子、操作として制約条件を備え、モデル間関連インスタンスは、モデルクラスとして定義した任意の２つのモデルクラス間の関連の実体であり、属性としてモデル間関連クラスの識別子、関連元のモデルインスタンス識別子及び関連先のモデルインスタンス識別子、操作として制約条件を備え、ドキュメントインスタンスは、仕様の開発の際に作成するドキュメントの最小単位の実体であり、属性としてドキュメントクラスの識別子、ドキュメントインスタンスの識別子及び子となるドキュメントインスタンスの識別子、操作として制約条件を備え、モデルドキュメント間関連インスタンスは、モデルドキュメント間関連クラスとして定義した関連の実体であり、属性としてモデルドキュメント間関連クラスの識別子、関連元のモデルインスタンス識別子及び関連先のドキュメントインスタンス識別子、操作として制約条件を備える仕様管理装置であることを要旨とする。

本発明の第５の特徴は、ソフトウェア若しくはシステムの仕様の管理を行う仕様管理方法であって、仕様を定義する管理者端末からの要求により、設計メタ情報定義部（１１）が、仕様の最小単位の型であるモデルクラスのデータ、モデルクラスとして定義した任意の２つのモデルクラス間の関連の型であるモデル間関連クラスのデータ、仕様の開発の際に作成するドキュメントの最小単位の型であるドキュメントクラスのデータ、及びモデルクラスとドキュメントクラス間の関連の型であるモデルドキュメント間関連クラスを備えるモデルドキュメント間関連クラスのデータを含む設計メタ情報を定義し、設計メタ情報記憶部（２１）に格納するステップと、仕様を生成するユーザ端末からの要求により、設計情報定義部（１２）が設計メタ情報記憶部（２１）内の設計メタ情報を基に、仕様の最小単位の実体であり、モデルクラスの識別子、インスタンスの識別子、子となるモデルインスタンスの識別子及びインスタンス毎の制約条件を備えるモデルインスタンスのデータ、モデルクラスとして定義した任意の２つのモデルクラス間の関連の実体であり、モデル間関連クラスの識別子、関連元のモデルインスタンス識別子、関連先のモデルインスタンス識別子及びインスタンス毎の制約条件を備えるモデル間関連インスタンスのデータ、仕様の開発の際に作成するドキュメントの最小単位の実体であり、属性としてドキュメントクラスの識別子、ドキュメントインスタンスの識別子及び子となるドキュメントインスタンスの識別子、インスタンス毎の制約条件を備えるドキュメントインスタンスのデータ、及びモデルドキュメント間関連クラスとして定義した関連の実体であり、モデルドキュメント間関連クラスの識別子、関連元のモデルインスタンス識別子、関連先のドキュメントインスタンス識別子及びインスタンス毎の制約条件を備えるモデルドキュメント間関連インスタンスのデータを含む設計情報を定義し、設計情報記憶部（２２）に格納するステップとを備える仕様管理方法であることを要旨とする。

本発明の第６の特徴は、ソフトウェア若しくはシステムの仕様の管理を行うコンピュータにおいて、仕様を定義する管理者端末からの要求により、設計メタ情報定義部（１１）が、仕様の最小単位の型であるモデルクラスのデータ、モデルクラスとして定義した任意の２つのモデルクラス間の関連の型であるモデル間関連クラスのデータ、仕様の開発の際に作成するドキュメントの最小単位の型であるドキュメントクラスのデータ、モデルクラスとドキュメントクラス間の関連の型であるモデルドキュメント間関連クラスのデータを含む設計メタ情報を定義し、設計メタ情報記憶部（２１）に格納する命令と、仕様を生成するユーザ端末からの要求により、設計情報定義部（１２）が設計メタ情報記憶部（２１）内の設計メタ情報を基に、仕様の最小単位の実体であり、モデルクラスの識別子、インスタンスの識別子、子となるモデルインスタンスの識別子及びインスタンス毎の制約条件を備えるモデルインスタンスのデータ、モデルクラスとして定義した任意の２つのモデルクラス間の関連の実体であり、モデル間関連クラスの識別子、関連元のモデルインスタンス識別子、関連先のモデルインスタンス識別子及びインスタンス毎の制約条件を備えるモデル間関連インスタンスのデータ、仕様の開発の際に作成するドキュメントの最小単位の実体であり、属性としてドキュメントクラスの識別子、ドキュメントインスタンスの識別子及び子となるドキュメントインスタンスの識別子、インスタンス毎の制約条件を備えるドキュメントインスタンスのデータ、及びモデルドキュメント間関連クラスとして定義した関連の実体であり、モデルドキュメント間関連クラスの識別子、関連元のモデルインスタンス識別子、関連先のドキュメントインスタンス識別子及びインスタンス毎の制約条件を備えるモデルドキュメント間関連インスタンスのデータを含む設計情報を定義し、設計情報記憶部（２２）に格納する命令とを実行させる仕様管理プログラムであることを要旨とする。

本発明の仕様管理装置、仕様管理方法及び仕様管理プログラムによると、開発のライフサイクルで作成されるあらゆる成果物及び成果物間の関係を、モデル要素、モデル要素間の関係、ドキュメント及びその構成、モデル要素及びドキュメント要素との関係の４種類に分類して定義し、登録管理することにより、入力されるモデル要素の情報と予め定義されるドキュメントの情報に基づいて、ドキュメントを自動生成することが出来る。

モデル要素に変更及び修正を行う場合には、他に影響のあるモデル要素及びドキュメントの修正箇所等を特定し、定義が不完全なモデル要素、要件変更の修正が完了していないドキュメント等を抽出し、これらが満たすべき制約条件を定義する。これにより、モデル要素及びドキュメント間の整合をとり、品質を安定させることが出来る。

ライフサイクル全体のあらゆるドキュメントを蓄積することが出来る為、一部のドキュメントデータ等が必要になった際にでも、速やかに蓄積されたドキュメントから所望のデータを取得することが出来る。

モデル要素及びドキュメント間の整合がとれている為、仕様間の矛盾や対応の漏れを防止することが出来、ひいては全体の開発コストを下げることが出来る。

ある設計メタ情報若しくは設計情報の修正を行う際に、実際の修正作業前に影響範囲を提示することが出来る為、修正の漏れを防止することが出来る。更に変更毎に変更履歴を保存しておく為、修正する際に前回以降の修正データを直に取得することが出来、修正処理の時間を短縮することが出来る。

管理者及びユーザの目的に応じて、任意のドキュメントを自由に生成することが出来、仕様が変更されてもドキュメントそのものを変更する必要が無く、レイアウト等の変更に関してもプログラム上で対応することが出来る。

次に、図面を参照して、本発明の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。ただし、図面は模式的なものであることに留意すべきである。

＜モデルのデータ形式＞
図１に示す仕様管理装置１００の各モジュールの具体的な説明に入る前に、本発明の特徴であるモデルのデータ形式について図２４を用いて説明する。モデルのデータ形式とは、管理者が設計メタ情報を定義する際にベースとする、本発明の中核をなす設計モデル、ドキュメント、これらの間の関連情報の基礎情報となる。

（設計メタ情報）
設計メタ情報として、モデルのデータ形式である「モデルクラス」「モデル間関連クラス」「ドキュメントクラス」「モデルドキュメント間関連クラス」を基底クラスとして備える。尚、クラスとは、オブジェクト指向の技術分野にて定義されたデータの型を指す。

図２４は、オブジェクト指向技術記法であるＵＭＬ（Unified Modeling Language）に則って記載されたクラス図であり、長方形はクラスを表し、長方形間の直線はクラス間の関連を表す。クラス内は、３つに分けて表現され、上段はクラス名、中段は属性、下段には操作が記述される。全ての操作１ｃ，２ｃ，３ｃ，４ｃは、斜体文字で示されている。操作１ｃ〜４ｃは、抽象操作を示し、本クラスを継承するクラスを管理者が定義する際に、本クラスの特性に応じて、操作の実体を再定義する。

モデルクラス１は、開発のライフサイクルを通じて作成する仕様の最小単位の型である。モデルクラスのデータは、この型のデータである。又、モデルクラス１は、全てのモデルクラスの親クラスであり、管理者は、当該クラスの子クラスとして、具体的なモデル毎にモデルクラスを定義する。

モデルクラス１は、クラス名１ａとして「モデル」、属性１ｂとして「モデル名」「モデルＩＤ」「バーション」「修正可能性フラグ」「変更履歴」、この他「識別子」等の属性を備える。操作１ｃとしては「クラス制約条件検証（ ）」操作、「インスタンス制約条件検証（ ）」操作、「特定インスタンス制約条件検証（ ）」操作を備える。尚、これら操作の制約条件については後述する。

属性１ｂの「From」には関連元のクラス名、「To」には関連先のクラス名、「バーション」にはバーション情報を、「修正可能性フラグ」には修正が必要となる可能性のあるフラグ“ON”又は修正不要フラグ“OFF”を、「変更履歴」には変更済みの履歴情報を記載する。

モデルクラス１を継承してあらたにクラスを定義する場合、操作１ｃの「クラス制約条件検証（ ）」操作及び「インスタンス制約条件検証（ ）」操作は、管理者が定義する。「特定インスタンス制約条件検証（ ）」操作は、あらたに定義したクラスのインスタンスを定義する際、ユーザが定義する。

複数のモデルクラス２の間には、親と子の関係を備える場合がある。この場合の親子関係とは、親の要素として、子となるクラスが対応する、全体と部分の関係を持つことを指す。

モデル間関連クラス２は、モデルとして定義した任意の２つのモデル間の関連の型である。モデル間関連クラスのデータは、この型のデータである。開発のライフサイクルを通じて作成する仕様には様々な種類があり、入力関係、参照関係、設計と対応する検証仕様の関係等の関連にも様々な種類がある為、これらの関連をモデル間関連クラス２にて定義する。

モデル間関連クラス２は、全てのモデル間関連クラスの親クラスであり、管理者は当該クラスの子クラスとしてドキュメントに含まれる具体的なモデル間関連毎にモデル間関連クラスを定義する。

モデル間関連クラス２は、クラス名２ａとして「モデル間関連」、属性２ｂとしてモデルクラス１の属性１ｂと同様の「From」「To」「バーション」「修正可能性フラグ」「変更履歴」、この他「説明」「関連元モデルリスト」「関連先モデルリスト」等の属性を備える。操作２ｃとしてはモデルクラス１の操作３ｃと同様の操作と、必要に応じて「制約条件による関連の検証」の操作も備える。

ドキュメントクラス３は、開発のライフルサイクルを通じて作成するドキュメント（文書）の最小単位の型である。ドキュメントクラスのデータは、この型のデータである。又、ドキュメントクラス３は、全てのドキュメントクラスの親クラスであり、管理者は当該クラスの子クラスとして具体的なドキュメント毎にドキュメントクラスを定義する。ドキュメントクラス３は、クラス名３ａとして「ドキュメント」、属性３ｂとしてモデルクラス１の属性１ｂと同様の「ドキュメント名称」「ドキュメントＩＤ」「バーション」「修正可能性フラグ」「変更履歴」、この他「識別子」「説明」「サブドキュメントリスト」等の属性を備える。操作３ｃとしては、モデルクラス１と同様の操作を備える。

複数のドキュメントクラス３の間には、親と子の関係を備える場合がある。この場合の親子関係とは、親の要素として、子となるクラスが対応する、全体と部分の関係を持つことを指す。

モデルドキュメント間関連クラス４は、「モデル」「ドキュメント」として定義した、任意のモデルとドキュメントの間の関連の型である。モデルドキュメント間関連クラスのデータは、この型のデータである。開発のライフサイクルを通じて作成するドキュメントは、同じく開発のライフサイクルを通じて作成する仕様情報であり「モデル」の情報に基づいて文章として作成する。このとき「モデル」と「ドキュメント」の関係には、要求と要求仕様書、設計仕様と設計仕様書、テストシナリオとテスト仕様書等の様々な関連が存在する為、そのような関連の型をモデルドキュメント間関連クラス４にて定義する。

又、モデルドキュメント間関連クラス４は、全てのモデルドキュメント間関連クラスの親クラスであり、管理者は当該クラスの子クラスとしてドキュメントに含まれる具体的なモデルドキュメント間関連毎にモデルドキュメント間関連クラスを定義する。

モデルドキュメント間関連クラス４は、クラス名４ａとして「モデルドキュメント間関連」、属性４ｂとしてモデルクラス１の属性１ｂと同様の「From」「To」「バーション」「修正可能性フラグ」「変更履歴」、この他「説明関連元モデルリスト」「関連先ドキュメントリスト」等の属性を備える。操作４ｃとしてモデルクラス１の操作１ｃと同様であり、必要に応じて「制約条件による関連の検証」の操作を備える。

（設計情報）
設計情報は、上記した４つの各クラスによって作成されるデータの実態であり、「モデルインスタンス」「モデル間関連インスタンス」「ドキュメントインスタンス」「モデルドキュメント関連インスタンス」を備える。尚、図示しないが、これらのインスタンスも図２４のクラスと同様に、インスタンス内は、３つに分けて表現され、上段にはインスタンスの名称、中段には属性、下段には操作が記述される。操作は、抽象操作を示す。操作の実体は、上記した親クラスを継承するインスタンスをユーザが定義する際に、親クラスの特性に応じて、定義する。

モデルインスタンスは、開発のライフサイクルを通じて作成する仕様の最小単位の実体である。モデルインスタンスのデータは、この実体のデータである。モデルインスタンスの属性としては、親となるモデルクラスの識別子、インスタンスの識別子および名称（説明）、子となるモデルインスタンスの識別子を備える。モデルインスタンスの操作としては、必要に応じて、制約条件による仕様検証の操作を備える。

モデル間関連インスタンスは、モデルインスタンスとして定義した任意の２つのモデルインスタンス間の関連情報であり、モデル間関連クラスとして、定義した関連の型の実体である。モデル間関連インスタンスのデータは、この実体のデータである。モデル間関連インスタンスの属性としては、親となるモデル間関連識別子、関連元のモデルインスタンス識別子、関連先のモデルインスタンス識別子を備える。モデル間関連インスタンスの操作としては、必要に応じ、制約条件による関連の検証の操作を備える。

ドキュメントインスタンスは、開発のライフサイクルを通じて作成するドキュメント（文書）の最小単位の実体である。ドキュメントインスタンスのデータは、この実体のデータである。ドキュメントインスタンスの属性としては、親となるドキュメントクラスの識別子、ドキュメントインスタンスの識別子および名称（説明）、子となるドキュメントインスタンスの識別子を備える。ドキュメントインスタンスの操作としては、必要に応じ、制約条件によるドキュメント検証の操作を備える。

モデルドキュメント間関連インスタンスは、モデルインスタンスとドキュメントインスタンスとして定義した、任意のモデルインスタンスとドキュメントインスタンス間の関連情報であり、モデルドキュメント間関連クラスとして定義した関連の型の実体である。モデルドキュメント間関連インスタンスのデータは、この実体のデータである。モデルドキュメント間関連インスタンスの属性としては、親となるモデルドキュメント間関連識別子、関連元のモデルインスタンス識別子、関連先のドキュメントインスタンス識別子を備える。モデルドキュメント間関連インスタンスの操作としては、必要に応じ、制約条件による関連の検証の操作を備える。

（制約条件）
上記において、設計メタ情報において図２４の操作１ｃ，２ｃ，３ｃ，４ｃの「クラス制約条件検証（ ）」操作、「インスタンス制約条件検証（ ）」操作、「特定インスタンス制約条件検証（ ）」操作を備え、設計情報である４つのインスタンスも各操作を備えると上述したが、以下これらクラス及びインスタンスを定義する為の制約条件について説明する。

制約条件は、「モデル」、「モデル間関連」、「ドキュメント」、及び「モデルドキュメント間関連」のそれぞれに、必要に応じて、設定するルールである。具体的に制約条件としては、例えば「テスト」というモデルであれば、テストモデルの一つ一つには「入力と出力が定義されていなければならない」、テストモデルの集合には、「機能モデルから関連されていないテストモデルは存在してはならない」等のルールを設定する。

制約条件には、クラスに関する制約条件、クラスに属するインスタンスに広く適用される制約条件、ある特定のインスタンスにだけ適用される制約条件がある。クラスの制約条件とインスタンスの制約条件は、モデルクラス１、モデル間関連クラス２、ドキュメントクラス３及びモデルドキュメント間関連クラス４において、管理者が必要に応じて、「クラス制約条件検証（ ）」操作、「インスタンス制約条件検証（ ）」操作として定義する。また、特定のインスタンスの制約条件は、各クラスのインスタンスにおいて、ユーザが必要に応じて、「特定インスタンス制約条件検証( )」操作として定義する。

＜仕様管理装置＞
本発明の実施の形態における仕様管理装置１００は、図１のユーザインタフェース部４０、仕様定義トレース管理部１０、データベース格納部２０、テンポラリデータ格納部３０等より構成される。

ユーザインタフェース部４０は、仕様管理装置１００を使用するユーザのユーザ端末４１、このシステムを管理する管理者の管理者端末４２間を接続するモジュールである。管理者端末４２は、パーソナルコンピュータ等の端末であり、管理者の操作によって、設計メタ情報を定義し、開発プロセスを整備する。ユーザ端末４１は、パーソナルコンピュータ等の端末であり、ユーザの操作によって設計情報を定義し、ドキュメントを生成させる。

データベース格納部２０は、設計メタ情報記憶部２１及び設計情報記憶部２２等より構成される。

設計メタ情報記憶部２１は、ドキュメント構成、ドキュメントに含まれるモデルの構成、(特定インスタンスのそれを除く)制約条件等の仕様の型である設計メタ情報を格納する。設計メタ情報は、管理者により後述する設計メタ情報定義部１１にて、用意された抽象クラスを継承して定義される。

設計情報記憶部２２は、モデル、ドキュメント、それらの関連の具体的な内容、特定インスタンスの制約条件等から成る設計情報を格納する。設計情報は、ユーザにより後述する設計情報定義部１２にて、クラスのインスタンスとして定義される。

テンポラリデータ格納部３０は、制約エラー記憶部３１、変更点記憶部３２及びトレース記憶部３３等から構成される。制約エラー記憶部３１は、制約条件を満たさない制約エラーを記憶する。変更点記憶部３２は、バージョン間の変更点を記憶する。トレース記憶部３３は、トレースの為に必要な情報を記憶する。

尚、データベース格納部２０及びテンポラリデータ格納部３０はハードウェアに備えられる記憶装置である。

仕様定義トレース管理部１０は、設計メタ情報定義部１１、設計情報定義部１２、設計情報構成管理部１３、設計情報検証管理部１４、設計情報トレース管理部１５及び設計書生成部１６等から構成される。

設計メタ情報定義部１１は、管理者端末４２からの要求により、図２４に示される、モデルクラス、モデル間クラス、ドキュメントクラス、モデルドキュメント間関連クラス等の設計メタ情報を定義する。定義した設計メタ情報は設計メタ情報記憶部２１に格納される。

設計情報定義部１２は、ユーザ端末４１からの要求により、設計書に含まれる要素、ドキュメント等の設計情報を定義する。定義した設計情報は設計情報記憶部２２に格納される。

設計情報構成管理部１３は、ユーザ端末４１からの要求により、設計情報全体にバージョンを設定し、バージョンを指定して取り出す。尚、個々のモデル、モデル間関連、ドキュメント、モデルドキュメント間関連は、構成管理情報として、バージョン毎に設計情報記憶部２２に格納される。

設計情報検証管理部１４は、ユーザ端末４１からの要求により、定義した設計情報が制約条件を満たしているか否かを確認する。この時検出された制約エラーは制約エラー記憶部３１に格納される。

設計情報トレース管理部１５は、ユーザ端末４１からの要求により、設計情報の修正影響範囲を修正前に確認し、更に、設計情報の修正影響範囲と変更内容を修正後に確認する。この時検出された変更点は変更点記憶部３２に格納される。尚、設計情報の修正影響範囲はトレース記憶部３３に格納される。

設計書生成部１６は、ユーザ端末４１からの要求により、設計書を生成する。

（設計メタ情報定義部）
設計メタ情報定義部１１は、図２に示すように、モデルクラス定義部１１ａ、モデル間関連クラス定義部１１ｂ、ドキュメントクラス定義部１１ｃ及びモデルドキュメント間関連クラス定義部１１ｄ等を備え、データベース格納部２０の設計メタ情報記憶部２１に接続されている。

モデルクラス定義部１１ａは、モデル入力画面を管理者端末４２に提示し、受信した操作信号により、クラス名、親クラス名、クラス制約条件、インスタンス制約条件等を定義する。この他、新規クラスの追加、既存クラスの変更、既存クラスの削除等の処理を行う。

モデル間関連クラス定義部１１ｂは、モデル間関連クラス入力画面を管理者端末４２に提示し、受信した操作信号により、クラス名、親クラス名、クラス制約条件、インスタンス制約条件等を定義する。この他、新規クラスの追加、既存クラスの変更、既存クラスの削除等の処理を行う。

ドキュメントクラス定義部１１ｃは、ドキュメント入力画面を管理者端末４２に提示し、受信した操作信号により、クラス名、親クラス名、クラス制約条件、インスタンス制約条件等を定義する。この他、新規クラスの追加、既存クラスの変更、既存クラスの削除等の処理を行う。

モデルドキュメント間関連クラス定義部１１ｄは、モデルドキュメント間関連クラス入力画面を管理者端末４２に提示し、受信した操作信号により、クラス名、親クラス名、クラス制約条件、インスタンス制約条件等を定義する。この他、新規クラスの追加、既存クラスの変更、既存クラスの削除等の処理を行う。

（設計情報定義部）
設計情報定義部１２は、図３に示すように、モデルインスタンス定義部１２ａ、モデル間関連インスタンス定義部１２ｂ、ドキュメントインスタンス定義部１２ｃ及びモデルドキュメント間関連インスタンス定義部１２ｄ等を備え、データベース格納部２０の設計情報記憶部２２に接続されている。

モデルインスタンス定義部１２ａは、のモデルインスタンス入力画面をユーザ端末４１に提示し、受信した操作信号によりインスタンスを生成する型となるクラス名、インスタンスの識別子、インスタンスの内容、サブモデルのリスト、特定インスタンス制約条件等を定義する。尚、定義されたモデルインスタンスはユーザ端末４１上に表示され、設計情報記憶部２２に格納される。この他、新規インスタンスの追加、既存インスタンスの変更、既存インスタンスの削除等を行う。

モデル間関連インスタンス定義部１２ｂは、モデル間関連インスタンス入力画面をユーザ端末４１に提示し、受信した操作信号により、インスタンスを生成する型となるクラス名、インスタンスの識別子、インスタンスの内容、サブモデルのリスト、特定インスタンス制約条件等を定義する。モデル間関連インスタンス定義はユーザ端末４１上に表示される。この他、新規インスタンスの追加、既存インスタンスの変更、既存インスタンスの削除等を行う。

ドキュメントインスタンス定義部１２ｃは、ドキュメントインスタンス入力画面をユーザ端末４１に提示し、受信した操作信号により、インスタンスを生成する型となるクラス名、インスタンスの識別子、インスタンスの内容、サブモデルのリスト、特定インスタンス制約条件を定義する。この他、新規インスタンスの追加、既存インスタンスの変更、既存インスタンスの削除等を行う。

モデルドキュメント間関連インスタンス定義部１２ｄは、モデルドキュメント間関連インスタンス入力画面をユーザ端末４１に提示し、受信した操作信号により、インスタンスを生成する型となるクラス名、インスタンスの識別子、インスタンスの内容、サブモデルのリスト、特定インスタンス制約条件を定義する。尚、モデルドキュメント間関連インスタンス定義はユーザ端末４１上に表示される。この他、新規インスタンスの追加、既存インスタンスの変更、既存インスタンスの削除等を行う。

（設計情報検証管理部）
設計情報検証管理部１４は、図４に示すように、設計情報検証部１４ａ及び設計情報検証エラー表示部１４ｅ等を備え、データベース格納部２０の設計情報記憶部２２と、テンポラリデータ格納部３０の制約エラー記憶部３１に接続されている。

設計情報検証部１４ａは、クラス制約条件検証部１４ｂ、インスタンス制約条件検証部１４ｃ及び特定インスタンス制約条件検証部１４ｄを備える。クラス制約条件検証部１４ｂは、全ての「クラス制約条件検証（ ）」操作を起動させ、設計情報が制約条件を満たしているか検証する。インスタンス制約条件検証部１４ｃは、全ての「インスタンス制約条件検証（ ）」操作を起動させ、設計情報が制約条件を満たしているか検証する。特定インスタンス制約条件検証部１４ｄは、全ての「特定インスタンス制約条件検証（ ）」操作を起動させ、設計情報が制約条件を満たしているか検証する。検証結果は制約エラー記憶部３１に格納する。

設計情報検証エラー表示部１４ｅは、検証エラー結果として、制約エラー記憶部３１等の情報を、検証結果としてユーザ端末４１又は管理者端末４２に表示させる。尚、表示された検証結果を基にユーザ端末４１又は管理者端末４２は制約エラーを修正する。

（設計情報トレース管理部）
設計情報トレース管理部１５は、図５に示すように、設計情報変更点検出部１５ａ及び修正影響範囲表示部１５ｄ等を備え、データベース格納部２０の設計情報記憶部２２と、テンポラリデータ格納部３０の制約エラー記憶部３１、変更点記憶部３２及びトレース記憶部３３と接続されている。

設計情報変更点検出部１５ａは、モデルドキュメントインスタンス変更点検出部１５ｂ及び関連インスタンス変更点検出部１５ｃを備える。モデルドキュメントインスタンス変更点検出部１５ｂは、モデルインスタンス及びドキュメントインスタンスの変更点を検出する。関連インスタンス変更点検出部１５ｃは、モデル間関連インスタンス及びモデルドキュメント間関連インスタンスの変更点を検出する。変更点の検出処理では、バージョンを指定して設計情報記憶部２２から取り出した設計情報Ａと、設計情報定義部１２で定義中の設計情報Ｂとの間において「ＡになくＢにあるインスタンスの検出」「ＡにありＢにないインスタンスの検出」「Ｂ中の各インスタンス毎に、ＡからＢへの変更点の識別」を行う。

修正影響範囲表示部１５ｄは、設計情報記憶部２２と変更点記憶部３２情報を基に修正影響範囲の情報をトレースし、ユーザ端末４１上に表示する。尚、トレースの情報はトレース記憶部３３に格納される。修正影響範囲表示部１５ｄが表示したトレースを基に、ユーザ端末４１はトレース情報を修正する。

＜仕様管理方法＞
仕様管理装置１００の動作は大まかに、
１．管理者端末４２による、設計メタ情報定義部１１を用いた、メタ設計情報の定義
２．ユーザ端末４１による、設計情報定義部１２を用いた、設計情報の定義
３．ユーザ端末４１による、設計情報定義部１２及び設計情報検証管理部１４を用いた、設計情報の定義と検証
４．ユーザ端末４１による、設計情報定義部１２及び設計情報トレース管理部１５を用いた、設計情報のトレースと修正
５．ユーザ端末４１による、設計書生成部１６を用いた、仕様の定義
に分けられる。以下、これらの動作について図面を参照して説明する。

（メタ設計情報定義の動作）
管理者端末４２による、設計メタ情報定義部１１を用いた、メタ設計情報定義の動作について、図６のＵＭＬ記法のシーケンス図を用いて説明する。

（ａ）先ず、ステップＳ１０１においては、設計メタ情報定義部１１のモデルクラス定義部１１ａは、管理者端末４２上に図１６のモデル入力画面を表示させ、ユーザインタフェース４０を介して、管理者端末４２よりモデルクラスの定義を取得する。ステップＳ１０２においてモデルクラス定義部１１ａは、取得したモデルクラスの定義を設計メタ情報記憶部２１に格納する。

（ｂ）ステップＳ１０１〜Ｓ１０２と同様に、ステップＳ１０３〜Ｓ１０４ではモデル間関連クラス定義部１１ｂが図１７のモデル間関連クラス入力画面を提示してモデル間関連クラスの定義を取得し、設計メタ情報記憶部２１に格納する。ステップＳ１０５〜Ｓ１０６ではドキュメントクラス定義部１１ｃが図１８のドキュメント入力画面を提示してドキュメントクラスの定義を取得し、設計メタ情報記憶部２１に格納する。ステップＳ１０７〜Ｓ１０８ではモデルドキュメント間関連クラス定義部１１ｄが図１９のモデルドキュメント間関連クラス入力画面を提示してモデルドキュメント間関連クラスの定義を取得し、設計メタ情報記憶部２１に格納する。

（設計情報定義の動作）
次に、ユーザ端末４１による、設計情報定義部１２を用いた、設計情報定義の動作について図７のＵＭＬ記法のシーケンス図を用いて説明する。

（ａ）先ず、ステップＳ２０１においては、設計情報定義部１２のモデルインスタンス定義部１２ａは、図２０のモデルインスタンス入力画面をユーザ端末４１に提示し、入力されたモデルインスタンスの定義をユーザインタフェース４０を介して取得する。ステップＳ２０２においてモデルインスタンス定義部１２ａは、取得したモデルインスタンスの定義を設計情報記憶部２２に格納する。

（ｂ）ステップＳ２０１〜Ｓ２０２と同様に、ステップＳ２０３〜Ｓ２０４ではモデル間関連インスタンス定義部１２ｂが図２１のモデル間関連インスタンス入力画面をユーザ端末４１に提示し、モデル間関連インスタンスの定義を取得し、設計情報記憶部２２に格納する。ステップＳ２０５〜Ｓ２０６ではドキュメントインスタンス定義部１２ｃが図２２のモデル間関連インスタンス入力画面をユーザ端末４１に提示し、ドキュメントインスタンスの定義を取得し、設計情報記憶部２２に格納する。ステップＳ２０７〜Ｓ２０８ではモデルドキュメント間関連インスタンス定義部１２ｄが図２３のモデル間関連インスタンス入力画面をユーザ端末４１に提示し、モデルドキュメント間関連インスタンスの定義を取得して設計情報記憶部２２に格納する。

（ｃ）ステップＳ２０９において、必要に応じてユーザ端末４１が、仕様・設計情報の構成情報を検索する際は、ユーザインタフェース４０を通して、仕様・設計の構成情報の表示要求を設計情報構成管理部１３に送信する。ステップＳ２１０において、これを受信した設計情報構成管理部１３は、設計情報記憶部２２内より表示要求に適合する情報を検索し、ステップＳ２１１において、ユーザインタフェース４０を通して検索結果をユーザ端末４１に表示させる。

（設計情報定義検証の動作）
次に、ユーザ端末４１による、設計情報定義部１２及び設計情報検証管理部１４を用いた設計情報の定義と検証の動作について図８のＵＭＬ記法のシーケンス図を用いて説明する。

（ａ）先ず、ステップＳ２０１〜Ｓ２０８と同様に、ステップＳ３０１〜Ｓ３０８においてモデルインスタンス、モデル間関連インスタンス、ドキュメントインスタンス及びモデルドキュメント間関連インスタンスの各々のクラス制約条件、インスタンス制約条件及び特定インスタンス制約条件を、図１６〜２３の画面上にて定義し、設計情報記憶部２２に格納する。

（ｂ）ステップＳ３０９において、ユーザ端末４１が設計情報定義後に定義内容を検証する際は、ユーザインタフェース４０を通して、設計情報の検証要求が、設計情報検証管理部１４に送信される。ステップＳ３１０において、これを受信した設計情報検証管理部１４は、この検証要求を基に設計情報記憶部２２内を検索する。ステップＳ３１１において、設計情報検証管理部１４は、この検索結果を検証要求に基づいて検証する。ステップＳ３１２において、検証結果は制約エラー記憶部３１に登録される。

尚、ステップＳ３１０〜３１２の動作は、図４の設計情報検証管理部１４内のクラス制約条件検証部１４ｂ、インスタンス制約条件検証部１４ｃ及び特定インスタンス制約条件検証部１４ｄの各々によって行われる。

クラス制約条件検証部１４ｂの動作は、図９のフローチャートに示すように、ステップＳ３１にて全てのクラスより１つのクラスを取得し、ステップＳ３２にてそのクラスが持つ全てのクラス制約条件より１つのクラス制約条件を取得する。ステップＳ３３では、取得した１つのクラスが取得した１つのクラス制約条件を満たしているかを判定する。判定の結果クラス制約条件を満たしていないなら、ステップＳ３４へ進み、取得した１つのクラスが取得した１つのクラス制約条件を満たしていないことを制約エラー記憶部３１に格納する。判定の結果クラス制約条件を満たしているなら、この処理を終了し、次のクラス制約条件を取得する。

ステップＳ３３〜Ｓ３４の動作は、１つのクラスに対する全てのクラス制約条件が終了するまでループ処理され（ステップＳ３２）、更に、ステップＳ３２〜Ｓ３４の動作は全てのクラスが終了するまでループ処理される（ステップＳ３１）。つまり、全てのクラスの全てのクラス制約条件に対して制約エラーの検証が行われる。

インスタンス制約条件検証部１４ｃの動作は、ほぼクラス制約条件検証部１４ｂと同じであり、図１０のフローチャートに示すように行われる。先ずステップＳ４１にて全てのクラスより１つのクラスを取得し、ステップＳ４２にてそのクラスに属する全てのインスタンスより１つのインスタンスを取得し、ステップＳ４３にてそのクラスが持つ全てのインスタンス制約条件の１つを取得する。ステップＳ４４では、取得した１つのインスタンスが、取得した１つのインスタンス制約条件を満たしているかを判定する。判定の結果クラス制約条件を満たしていないなら、ステップＳ３４へ進み、取得した１つのクラスが取得した１つのインスタンス制約条件を満たしていないことを制約エラー記憶部３１に格納する。判定の結果インスタンス制約条件を満たしているなら、この処理を終了し、次のインスタンス制約条件を取得する。

ステップＳ４４〜Ｓ４５の動作は、１つのクラスが持つ全てのインスタンス制約条件が終了するまでループ処理され（ステップＳ４３）、更に、ステップＳ４３〜Ｓ４５の動作はクラスに属する全てのインスタンスが終了するまでループ処理され（ステップＳ４２）、更に、ステップＳ４２〜Ｓ４５の動作は全てのクラスが終了するまでループ処理される（ステップＳ４１）。つまり、全てのクラスに属する全てのインスタンス制約条件に対して制約エラーの検証が行われる。

特定インスタンス制約条件検証部１４ｄの動作は、ほぼクラス制約条件検証部１４ｂと同じであり、図１１のフローチャートに示すように行われる。ステップＳ５１にて全てのインスタンスより１つのインスタンスを取得し、ステップＳ５２にてそのインスタンスが持つ全ての特定インスタンス制約条件より１つの特定インスタンス制約条件を取得する。ステップＳ５３では、取得した１つのインスタンスが取得した１つの特定インスタンス制約条件を満たしているかを判定する。判定の結果クラス制約条件を満たしていないなら、ステップＳ５４へ進み、取得した１つのインスタンスが取得した１つの特定インスタンス制約条件を満たしていないことを制約エラー記憶部３１に格納する。判定の結果特定インスタンス制約条件を満たしているなら、この処理を終了し、次の特定インスタンス制約条件を取得する。

ステップＳ５３〜Ｓ５４の動作は、１つのインスタンスに対する全ての特定インスタンス制約条件が終了するまでループ処理され（ステップＳ５２）、更に、ステップＳ５２〜Ｓ５４の動作は全てのインスタンスが終了するまでループ処理される（ステップＳ５１）。つまり、全てのインスタンスの全ての特定インスタンス制約条件に対して制約エラーの検証が行われる。

（ｃ）ステップＳ３１３において、検証結果はユーザインタフェース４０を介して、ユーザ端末４１に表示される。

例えば制約条件として、RQ1〜RQ8が要求のモデルのインスタンスであり、要求のモデルの制約条件として全ての要求はいずれかの機能のインスタンスと関連づく必要があること、更に、F1からF9が機能のクラスのインスタンスであり、機能のクラスの制約条件として全ての機能はいずれかの要求のインスタンスと関連づく必要があること等が定義されたと仮定すると、図２５に示すような画面がユーザ端末４１に表示される。

図２５の右下欄には、この定義で仕様検証を実施した結果、機能が対応づいていない要求仕様、及び要求仕様が対応づいていない機能を検出したこと等の検証結果が表示される。これによりユーザは機能の定義や範囲指定にエラーがあることを知り、再定義を行う。

（設計情報トレース及び修正の動作）
次に、ユーザ端末４１による、設計情報定義部１２及び設計情報トレース管理部１５を用いた、設計情報のトレースと修正の動作について図１２のＵＭＬ記法のシーケンス図を参照して説明する。図１２では、すでに定義した設計情報に対して何らかの変更が発生した場合に、変更内容の影響範囲をトレースした上で、影響範囲内の設計情報を修正する際の動作について説明する。この際、設計情報は、図７又は図８で説明した設計情報定義の動作により設計情報記憶部２２に登録されているものとする。

（ａ）先ず、ステップＳ４０１において、ユーザ端末４１は、ユーザインタフェース部４０を通して、設計情報のトレース要求を送信する。ステップＳ４０２において、このトレース要求を受信した設計情報トレース管理部１５は、設計情報記憶部２２よりトレース要求を基に設計情報を検索する。ステップＳ４０３において設計情報トレース管理部１５は、この検索結果を基にトレースと変更点を検出する。ステップＳ４０４において、トレース結果及び変更点は、トレース記憶部３３及び変更点記憶部３２に登録される。更に、ステップＳ４０５において、トレース結果及び変更点は、ユーザインタフェースを通してユーザ端末４１に提示される。

（ｂ）ステップＳ４０６において、ユーザはユーザ端末４１上に提示されたトレース情報及び変更点を参照し、必要に応じて設計情報定義部１２にてモデルインスタンスを訂正する。訂正されたモデルインスタンスはステップＳ４０７において設計情報記憶部２２に格納される。同様に、ステップＳ４０８〜Ｓ４０９にてモデル間関連インスタンスを訂正し、設計情報記憶部２２に格納する。ステップＳ４１０〜Ｓ４１１にてドキュメントインスタンスを訂正し、設計情報記憶部２２に格納する。ステップＳ４１２〜Ｓ４１３にてモデルドキュメント間関連インスタンスを訂正し、設計情報記憶部２２に格納する。

（ｃ）ステップＳ４１４において、ユーザは、修正が確実に行われたかどうかを確認するために、必要に応じてトレースを要求する。トレース要求では、ユーザは変更対象になるモデルインスタンス又はドキュメントインスタンスを指定する。

（ｄ）ステップＳ４１５において、トレース要求を受信した設計情報トレース管理部１５は、指定されたインスタンスに関連するインスタンスを設計情報記憶部２２より検索する。ステップＳ４１６において、設計情報トレース管理部１５は、関連情報をトレースし、変更点を検出する。ステップＳ４１７において、この結果を変更点記憶部３２及びトレース記憶部３３に格納する。ステップＳ４１８においてはユーザ端末４１上にトレース結果を表示する。

尚、ステップＳ４１５〜Ｓ４１７は、モデルインスタンスとドキュメントインスタンス、モデル間関連インスタンスとモデルドキュメント間関連インスタンス毎に行われる。先ず、モデルインスタンスとドキュメントインスタンスのトレース変更点検出処理について図１３のフローチャートを用いて詳細に説明する。

（ａ）ステップＳ６１においては、全てのモデルインスタンス及びドキュメントインスタンス内より１つを取り出す。取り出されたインスタンスに対しては、以下のステップＳ６２〜Ｓ６７のループ処理を行う。つまり、ステップＳ６２〜Ｓ６７のループ処理を、全てのモデルインスタンス及びドキュメントインスタンスの各々に対して行う。

（ｂ）ステップＳ６２においては、設計情報記憶部２２より、現モデルインスタンス及び現ドキュメントインスタンスの１つ前のバージョンに含まれるインスタンスを取り出す。

ステップＳ６３においては、ステップＳ６２で取得した前バージョンの前インスタンスと現バージョンの現インスタンス間において、変更点があるか否かを判定する。変更点が無ければこの処理を終了し、変更点が有るとステップＳ６４へ進む。

ステップＳ６４においては、現インスタンスと前インスタンスの変更点を取り出し、現インスタンスのバージョンを変更する。

ステップＳ６５においては、現インスタンスを関連元とする全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンスの修正可能性フラグをONにし、当該全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンスの全ての関連先インスタンスの修正可能性フラグをONにする。

ステップＳ６６においては、現インスタンスを関連先とする全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンスの修正可能性フラグをONにし、当該全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンスの全ての関連元インスタンスの修正可能性フラグをONにする。

ステップＳ６７において、変更点を全て変更点記憶部３２に格納する。

（ｃ）ステップＳ６８においては、設計情報記憶部２２より、前バージョンに存在し、現バージョンに存在しない全てのモデルインスタンス及びドキュメントインスタンス（削除されたインスタンスを指す）と、前バージョンに存在せず、現バージョンに存在する全てのモデルインスタンス及びドキュメントインスタンス（追加されたインスタンスを指す）を取り出す。

ステップＳ６９においては、ステップＳ６８で取り出した削除されたインスタンス及び追加されたインスタンスのうち１つを取り出し、以下のステップＳ７０〜Ｓ７２までのループ処理を行う。尚、ステップＳ７０〜Ｓ７２までの処理はステップＳ６８にて取り出した全てのインスタンスの各々に対して行われる。

（ｄ）ステップＳ７０においては、現インスタンスを関連元とする全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンスの修正可能性フラグをONにし、当該全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンスの全ての関連先インスタンスの修正可能性フラグをONにする。

ステップＳ７１においては、現インスタンスを関連先とする全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンスの修正可能性フラグをONにし、当該全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンスの全ての関連元インスタンスの修正可能性フラグをONにする。

最後にステップＳ７２において、変更点を全て変更点記憶部３２に格納する。

次に、モデル間関連インスタンスとモデルドキュメント間関連インスタンスのトレース変更点検出処理について図１４のフローチャートを用いて詳細に説明する。

（ａ）ステップＳ８１においては、全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンス内より１つを取り出す。取り出されたインスタンスに対しては、以下のステップＳ８２〜Ｓ８７のループ処理を行う。つまり、ステップＳ８２〜Ｓ８７のループ処理を、全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンスの各々に対して行う。

ステップＳ８２においては、設計情報記憶部２２より、現モデル間関連インスタンス及び現モデルドキュメント間関連インスタンスの１つ前のバージョンに含まれるインスタンスを取り出す。

（ｂ）ステップＳ８３においては、ステップＳ８２で取得した前バージョンの前インスタンスと現バージョンの現インスタンス間において、変更点があるか否かを判定する。変更点が無ければこの処理を終了し、変更点が有るとステップＳ８４へ進む。

ステップＳ８４においては、現インスタンスと前インスタンスの変更点を取り出し、現インスタンスのバージョンを変更する。ステップＳ８５においては、現インスタンスの全ての関連元インスタンス及び関連先インスタンスの修正可能性フラグをONにする。ステップＳ８６においては、前インスタンスの全ての関連元インスタンス及び関連先インスタンスの修正可能性フラグをONにする。

ステップＳ８７においては、変更点を全て変更点記憶部３２に格納する。

（ｃ）ステップＳ８８においては、設計情報記憶部２２より、前バージョンに存在し、現バージョンに存在しない全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンス（削除されたインスタンスを指す）と、前バージョンに存在せず、現バージョンに存在する全てのモデル間関連インスタンス及びモデルドキュメント間関連インスタンス（追加されたインスタンスを指す）を取り出す。

ステップＳ８９においては、ステップＳ８８にて取り出した削除されたインスタンス及び追加されたインスタンス内より１つを取り出す。取り出されたインスタンスに対しては、以下のステップＳ９０〜Ｓ９１のループ処理を行う。つまり、ステップＳ９０〜Ｓ９１のループ処理を、ステップＳ８８にて取り出した全ての削除されたインスタンス及び追加されたインスタンスの各々に対して行う。

（ｄ）ステップＳ９０においては、削除されたインスタンス及び追加されたインスタンスの全ての関連元インスタンス及び関連先インスタンスの修正可能性フラグをONにする。

ステップＳ９１においては、変更点を全て変更点記憶部３２に格納する。

ステップＳ４１８においてトレース結果はユーザ端末４１上に、例えば図２６及び図２７のように表示される。図２６の長方形の各々はモデルインスタンスを示しており、現在の段階では、バージョン２５の仕様クラス（TS1）のフラグは「OFF」、仕様クラスに関連するインスタンスであるRQ1、RQ2、TC1、TC2においてもフラグが「OFF」となっているため、このトレースが正常に処理されたことを示している。ここで上記仕様クラスの削除又は更新処理を行うと、図２７の画面がユーザ端末４１上に表示されたとする。図２７の画面では、全てのインスタンスのフラグが「ON」に、仕様クラスのバージョンが２６に変わっている為、ユーザは、先程行った削除又は更新処理が正しく行われておらず、設計情報に修正を加える必要があると判断する。尚、ユーザがステップＳ４０６〜Ｓ４１２において所定の修正を加えて再度トレース処理を実行すると、再び図２６に示すように全てのクラスが「OFF」となる。この際、仕様クラスのバージョンは再度１つ繰り上げられる。

（仕様定義の動作）
次に、ユーザ端末４１による、設計書生成部１６を用いた、仕様定義の動作について図１５のＵＭＬ記法のシーケンス図を用いて説明する。

（ａ）ステップＳ５０１において、ユーザ端末４１は、ユーザインタフェース部４０を介して、ドキュメント生成要求を送信する。ステップＳ５０２において設計書生成部１６がこれを受信すると、受信したドキュメント生成要求に基づいて、設計情報記憶部２２より該当する設計情報を検索する。ステップＳ５０３において、この検索結果を基に設計書生成部１６は仕様書を作成する。ステップＳ５０４において、作成した仕様書は、設計情報記憶部２２に登録される。ステップＳ５０５において、仕様書の作成結果はユーザインタフェース４０を介して、ユーザ端末４１上に提示される。

＜設計メタ情報及び設計情報の実施例＞
次に、仕様管理装置１００がソフトウェア又はシステムを開発して、同時に関連する仕様書を作成した実施例を、図２８のＵＭＬ記法のクラス図を参照して説明する。図２８の抽象クラス名を示すモデル１ａ、モデル間関連２ａ、ドキュメント３ａ、ドキュメント間関連４ａは、図２４の各クラスのクラス名であり、同じ内容を指している。図示しないが図２８に表示されている全ての各クラスは、図２４と同様に、クラス、属性、操作の３構造より構成されている。尚、図２８内の長方形は全てクラスを表す。図中、白抜きの三角は、クラス間の継承関係を示す。ひし形の図形は、クラス間の全体・部分の集約関係を表す。

図２８の設計メタ情報は、図２４のモデルクラス１、モデル間関連クラス２、ドキュメントクラス３及びモデルドキュメント間関連クラス４を継承するものであり、管理者が設計メタ情報定義部１１を介して定義する。設計メタ情報内の各クラス名は、設計メタ情報としての事例を示している。

図２８の設計情報は、設計メタ情報内の各々のクラスの各々のインスタンスから成り、ユーザが設計情報定義部１２を介して定義する。設計情報内の各クラス名は、設計情報としての事例を示している。

設計メタ情報の事例を詳細に説明すると、例えば、モデル１ａを継承して、「要求仕様５ｂ」「要求１２ｆ」「システムテスト仕様６ｂ」「システムテストケース１３ｂ」を定義する。

（設計メタ情報）
設計メタ情報の事象について詳細に説明する。

モデル１ａは子クラスとして要求仕様５ａ、システムテスト仕様６ｂ、要求１２ｆ、システムテストケース１３ｂを備えると定義する。要求仕様５ｂは、要求クラス１２ｆを子の要素として備えると定義する。システムテスト仕様６ｂは、システムテストケースクラス１３ｂを子の要素として備えると定義する。

モデル間関連２ａは子クラスとして、「要求仕様-システムテスト仕様７ｂ」を備えると定義する。モデル間関連２ａのインスタンスの定義は、一例として図２９に示すように、管理者端末４２上に２つのモデル間のインスタンスを行列のマトリクスを表示し、２つのインスタンスが交差するカラムに◎、○等の記号を管理者に入力させる。これにより、インスタンス間に特定の関連があることを示す。

ドキュメント３ａを継承する「要求仕様書１０ｂ」では、「はじめに」「本文」「おわりに」を定義し、「システムテスト仕様書１１ｆ」として、「はじめに」「本文」「おわりに」を定義する。これにより要求仕様書１０ｂは、「はじめに」「本文」「おわりに」を子の要素として備え、システムテスト仕様書１１ｆは、「はじめに」「本文」「おわりに」を子の要素として備えることになる。

要求仕様書１０ｂ及びシステムテスト仕様書１１ｆ等のドキュメントクラス３に関係する要求仕様書の構成について説明する。図３０にドキュメントの章節の階層構成の一例を示す。この階層構成は開発システムに固有の形態ではあるものの、システム開発では一般に必要なドキュメント、例えば要求仕様書、テスト仕様書などは共通であり、これらのドキュメントは「初めに」「本文」「おわりに」等の共通の構成を持つ。よって、システム開発に共通の部分は管理者がドキュメントクラスのインスタンスとして定義する。尚、後述するが、システム開発固有の部分、特にドキュメントの図３１の章節等の階層は、ユーザが設計情報内のドキュメントクラスのインスタンスとして定義する。

モデルドキュメント間関連４ａは、子クラスとして、「要求仕様-要求仕様書８ｂ」「ST仕様-ST仕様書９ｂ」を備えると定義する。尚、STとはシステムテストの略である。

モデルドキュメント関連インスタンスの一例について図３２を参照して説明する。管理者端末４２上に、左側にモデル１ａのインスタンス、右側にドキュメント３ａのインスタンスを表示し、管理者に、関連するインスタンス同士をユーザインタフェース部４０を介してリンク付けさせる。これにより関連するモデル及びドキュメントのインスタンスを定義する。尚、図３２は、右側の要求クラスインスタンスRQ1及びRQ2が、要求仕様書テンプレートPの3.1及び3.2の節に関連付けされることを示している。

（設計情報）
次に、設計情報の事象について詳細に説明する。要求仕様５ｂのインスタンスとして、「Ａ社顧客管理システム要求５ｃ」を定義する。要求１２ｆのインスタンスとして、「RQ001」〜「RQ004」を定義する。このインスタンス「RQ001」〜「RQ004」は図３３に示すように、親クラスの識別子として各々が親クラスの要求内容を備えるように記述される。若しくは図３４に示すように、モデルインスタンスの識別子を、要求（Requirements)、機能(Function)、テストケース(Test Case)等のカテゴリ毎に分類して、システム開発のライフサイクル全体を通して作成する成果物のモデルクラスのインスタンスとして定義しても良い。尚、モデルインスタンスは、図２０のモデルインスタンス入力処理画面の識別子、内容等に入力することにより定義される。

システムテスト仕様６ｂのインスタンスとして、「Ａ社顧客管理システムテスト仕様６ｃ」を定義する。システムテストケース１３ｂのインスタンスとして、「TC001」〜「TC004」を定義する。要求仕様-システムテスト仕様７ｂのインスタンスとして、「Ａ社顧客管理システム要求-システムテスト仕様７ｃ」を定義する。

要求仕様-要求仕様書８ｂのインスタンスとして、「Ａ社顧客管理システム要求仕様-要求仕様書８ｃ」及び「RQ001-RS2.1」〜「RQ002-RS2.2」を定義する。これは、Ａ社顧客管理システムのシステム要求は、Ａ社顧客管理システムのシステム要求仕様書にドキュメント化されること、要求のRQ001は、要求仕様書のRS2.1の節に記述されること、RQ002は要求仕様書のRS2.2に記述されること等を示す。

ST仕様-ST仕様書９ｂのインスタンスとして、「Ａ社顧客管理システムST仕様-ST仕様書９ｃ」を定義する。要求仕様書１０ｂのインスタンスとして、「Ａ社顧客管理システム要求仕様書１０ｃ」を定義する。要求仕様書１０ｂの「はじめに」のインスタンスとして、「RS1」を定義する。要求仕様書１０ｂの「本文」のインスタンスとして、「RS2.1」〜「RS2.3」を定義する。要求仕様書１０ｂの「おわりに」のインスタンスとして、「RS3」を定義する。

システムテスト仕様書１１ｆのインスタンスとして、「Ａ社顧客管理システムテスト仕様書１１ｇ」を定義する。システムテスト仕様書１１ｆの「はじめに」のインスタンスとして、「TS1」を定義する。システムテスト仕様書１１ｆの「本文」のインスタンスとして、「TS2.1」〜「TS2.3」を定義する。システムテスト仕様書１１ｆの「おわりに」のインスタンスとして、「TS3」を定義する。

＜制約条件の実施例＞
制約条件は、上述したように、管理者端末４２及びユーザ端末４１によって定義され、定義された制約条件は、クラス制約条件検証部１４ｂ、インスタンス制約条件検証部１４ｃ及び特定インスタンス制約条件検証部１４ｄにおいて検証されるが、以下、制約条件の具体例について説明する。

先ず、モデルクラスの各制約条件の例を挙げる。モデルクラスのクラス制約条件として、あるテストケースクラスを定義したい場合、クラス名が「テストケース」、親クラスが「モデルクラス」、クラス制約条件が「テストケースのインスタンスは１０００個以上でなければならず、且つ、このクラスに属するインスタンスの全ての識別子は、他の識別子と同一であってはならない」等と定義する。更にこのテストケースクラスのインスタンス制約条件を「このインスタンスの識別子は、文字列でなければならず、かつ、このインスタンスは、一つ以上の『機能-テストケース間関連』インスタンスの関連先でなければならない」等と定義する。尚、この場合「機能-テストケース間関連」クラスが設計メタ情報として定義されているものとする。

特定インスタンス制約条件は、クラス名が「テストケース」、親クラスが「モデルクラス」、インスタンス識別子が「TC01」、インスタンス名は「顧客登録画面（図２０参照）を通して予め登録されているデータベース登録結果（顧客情報）と、入力される結果が一致しなければならない」等と定義する。更に、特定インスタンス制約条件は、「このインスタンスは、顧客登録テストデータ(識別子TD01)を関連先とする」「『テストケース-テストデータ間関連』インスタンスの関連元でなければならない」等と定義する。尚、この場合『テストケース-テストデータ間関連』クラスが設計メタ情報として定義されている必要がある。

次に、ドキュメントクラスの各制約条件について例を挙げる。ドキュメントクラスのクラス制約条件として、ある要求仕様書クラスを定義したい場合、クラス名が「要求仕様書」、親クラスが「ドキュメントクラス」、クラス制約条件が「要求仕様書クラスのインスタンスの総数は1以上でなければならない」等と定義する。この要求仕様書クラスのインスタンス制約条件は「このインスタンスは、一つ以上の『要求仕様-要求仕様書間関連』インスタンスの関連先でなければならない」等と定義する。尚、この場合「要求仕様-要求仕様書間関連」クラスが設計メタ情報として定義されているものとする。

モデル間関連クラスの各制約条件について例を挙げる。モデル間関連クラスのクラス制約条件として、ある要求仕様-機能仕様クラスについて定義したい場合、クラス名が「要求仕様-機能仕様」、親クラスが「モデル間関連クラス」、クラス制約条件が「当クラスのインスタンスの総数は1以上でなければならない」等と定義する。この要求仕様-機能仕様クラスのインスタンス制約条件としては「このインスタンスの関連元は、全て要求仕様クラスのインスタンスでなければならず、且つ、本インスタンスの関連先は、全て機能仕様クラスのインスタンスでなければならない」等と定義する。

最後に、モデルドキュメント間関連クラスの各制約条件について例を挙げる。モデルドキュメント間関連クラスのクラス制約条件として、ある要求仕様-要求仕様書クラスについて定義したい場合、クラス名を「要求仕様-要求仕様書」、親クラスを「モデルドキュメント間関連クラス」、クラス制約条件を「当クラスのインスタンスの総数は1以上でなければならない」等と定義する。この要求仕様-要求仕様書クラスのインスタンス制約条件としては「このインスタンスの関連元のモデルの数は、１でなければならず、且つ、このインスタンスの関連先のモデルの数は、1以上でなければならない」等と定義する。

上述したこれらの定義は一例に過ぎず、管理者及びユーザは、個々の目的に応じて様々な制約条件を設定できることは勿論である。

このように、モデルクラス１、モデル間関連クラス２、ドキュメントクラス３及びモデルドキュメント間関連クラス４を定義し、これらのクラスより構成される設計情報を作成し、これらの関係を登録管理することにより、定義されたモデル要素の情報と定義したドキュメントの情報に基づいて、ドキュメントを自動生成することが出来る。

モデル要素に変更・修正が生じた場合であっても、他に影響のあるモデル要素及びドキュメントの修正箇所を抽出し、定義が不完全なモデル要素、要件変更の修正が完了していないドキュメントの抽出などを行うことにより、モデル要素及びドキュメント間の整合をとることが出来る。

仕様管理装置の全体構成を示す構成図である。 設計メタ情報定義部の構造を示す図である。 設計情報定義部の構造を示す図である。 設計情報検証管理部の構造を示す図である。 設計情報トレース管理部の構造を示す図である。 管理者によるメタ設計情報の定義の動作を示すフローチャートである。 ユーザによる設計情報の定義の動作を示すフローチャートである。 ユーザによる設計情報の定義と検証の動作を示すフローチャートである。 クラス制約条件の検証動作を示すフローチャートである。 インスタンス制約条件の検証動作を示すフローチャートである。 特定インスタンス制約条件の検証動作を示すフローチャートである。 ユーザによる設計情報のトレースと修正の動作を示すフローチャートである。 モデルインスタンス及びドキュメントインスタンスの変更点検出動作を示すフローチャートである。 モデル間関連インスタンス及びモデルドキュメント間関連インスタンスの変更点検出動作を示すフローチャートである。 ユーザによる仕様の定義の動作を示すフローチャートである。 モデルの入力画面を示す画面図である。 モデル間関連クラスの入力画面を示す画面図である。 ドキュメントクラスの入力画面を示す画面図である。 モデルドキュメント間関連クラスの入力画面を示す画面図である。 モデルインスタンスの入力画面を示す画面図である。 モデル間関連インスタンスの入力画面を示す画面図である。 ドキュメントインスタンスの入力画面を示す画面図である。 モデルドキュメント間関連インスタンスの入力画面を示す画面図である。 モデルのデータ形式を示す模式図である。 検証結果表示を示す画面図である。 トレース結果表示を示す画面図である。 トレース結果表示を示す画面図である。 モデル要素クラス及びドキュメントクラスの定義を示す模式図である。 モデル間関連インスタンスの定義例を示す図である。 ドキュメントの章節構造の例を示す図である。 ドキュメントの章節構造の例を示す図である。 モデルドキュメント及び関連インスタンスの実施例を示す図である。 モデルインスタンスの記述例を示す図である。 モデルインスタンスの記述例を示す図である。

符号の説明

１…モデルクラス
２…モデル間関連クラス
３…ドキュメントクラス
４…モデルドキュメント間関連クラス
５ｂ…要求仕様
５ｃ…Ａ社顧客管理システム要求
６ｂ…システムテスト仕様
６ｃ…Ａ社顧客管理システムテスト仕様
７ｂ…要求仕様−システムテスト仕様
７ｃ…Ａ社顧客管理システム要求−システムテスト仕様
８ｂ…要求仕様−要求仕様書
８ｃ…Ａ社顧客管理システム要求仕様−要求仕様書
９ｂ…ST仕様−ST仕様書
９ｃ…Ａ社顧客管理システムST仕様−ST仕様書
１０…仕様定義トレース管理部
１０ｂ…要求仕様書
１０ｃ…Ａ社顧客管理システム要求仕様書
１１…設計メタ情報定義部
１１ａ…モデルクラス定義部
１１ｂ…モデル間関連クラス定義部
１１ｃ…ドキュメントクラス定義部
１１ｄ…モデルドキュメント間関連クラス定義部
１１ｆ…システムテスト仕様書
１１ｇ…Ａ社顧客管理システムテスト仕様書
１２…設計情報定義部
１２ａ…モデルインスタンス定義部
１２ｂ…モデル間関連インスタンス定義部
１２ｃ…ドキュメントインスタンス定義部
１２ｄ…モデルドキュメント間関連インスタンス定義部
１２ｆ…要求
１３…設計情報構成管理部
１３ｂ…システムテストケース
１４…設計情報検証管理部
１４ａ…設計情報検証部
１４ｂ…クラス制約条件検証部
１４ｃ…インスタンス制約条件検証部
１４ｄ…特定インスタンス制約条件検証部
１４ｅ…設計情報検証エラー表示部
１５…設計情報トレース管理部
１５ａ…設計情報変更点検出部
１５ｂ…モデルドキュメントインスタンス変更点検出部
１５ｃ…関連インスタンス変更点検出部
１５ｄ…修正影響範囲表示部
１６…設計書生成部
２０…データベース格納部
２１…設計メタ情報記憶部
２２…設計情報記憶部
２２…設計情報記憶部部
３０…テンポラリデータ格納部
３１…制約エラー記憶部
３２…変更点記憶部
３３…トレース記憶部
４０…ユーザインタフェース
４１…ユーザ端末
４２…管理者端末
１００…仕様管理装置

Claims (12)

1. ソフトウェア若しくはシステムの仕様の管理者が使用する管理者端末及び前記仕様を生成するユーザが使用するユーザ端末に接続される仕様管理装置であって、
   前記管理者端末によって定義されるモデルクラスのデータ、モデル間関連クラスのデータ、ドキュメントクラスのデータ及びモデルドキュメント間関連クラスのデータを含む設計メタ情報を格納する設計メタ情報記憶部と、
   前記設計メタ情報記憶部内の前記設計メタ情報を基に前記ユーザ端末にて定義されるモデルインスタンスのデータ、モデル間関連インスタンスのデータ、ドキュメントインスタンスのデータ及びモデルドキュメント関連インスタンスのデータを含む設計情報を格納する設計情報記憶部と、
   前記モデルインスタンス、前記モデル間関連インスタンス、前記ドキュメントインスタンス及び前記モデルドキュメント関連インスタンスの各々が備える、クラス制約条件、インスタンス制約条件及び特定インスタンス制約条件を前記設計情報が満たしているかを検証する設計情報検証部
   とを備えることを特徴とする仕様管理装置。
2. ソフトウェア若しくはシステムの仕様の管理者が使用する管理者端末及び前記仕様を生成するユーザが使用するユーザ端末に接続される仕様管理装置であって、
   前記管理者端末によって定義される設計メタ情報を格納する設計メタ情報記憶部と、
   前記設計メタ情報記憶部内の前記設計メタ情報を基に前記ユーザ端末にて定義される設計情報を格納する設計情報記憶部と、
   前記設計情報記憶部内の前記設計情報の各々にバージョンを設定する設計情報構成管理部と、
   前記設計情報構成管理部にて設定された第１バージョンの設計情報及び第２バージョンの設計情報を取得し、前記第１バージョンの設計情報と前記第２バージョンの設計情報との間の変更点を検出し、前記変更点によって影響を受けるモデルを修正影響範囲として検出して前記ユーザ端末に提示し、トレース処理を行った結果を前記ユーザ端末に提示する設計情報トレース管理部と、
   前記設計情報の変更点の履歴を格納する変更点記憶部
   とを備えることを特徴とする仕様管理装置。
3. ソフトウェア若しくはシステムの仕様の管理者が使用する管理者端末及び前記仕様を生成するユーザが使用するユーザ端末に接続される仕様管理装置であって、
   前記管理者端末によって定義される設計メタ情報を格納する設計メタ情報記憶部と、
   前記設計メタ情報記憶部内の前記設計メタ情報を基に前記ユーザ端末にて定義される設計情報を格納する設計情報記憶部と、
   前記ユーザ端末より受信するドキュメント生成要求に基づいて、前記設計情報記憶部より設計情報を取得し、仕様書を作成する設計書生成部
   とを備えることを特徴とする仕様管理装置。
4. ソフトウェア若しくはシステムの仕様の管理者が使用する管理者端末及び前記仕様を生成するユーザが使用するユーザ端末に接続される仕様管理装置であって、
   モデルクラスのデータ、モデル間関連クラスのデータ、ドキュメントクラスのデータ及びモデルドキュメント間関連クラスのデータを含む設計メタ情報を前記管理者端末からの要求により定義する設計メタ情報定義部と、
   前記設計メタ情報定義部にて定義された設計メタ情報を格納する設計メタ情報記憶部と、
   モデルインスタンスのデータ、モデル間関連インスタンスのデータ、ドキュメントインスタンスのデータ及びモデルドキュメント関連インスタンスのデータを含む設計情報を前記ユーザ端末からの要求により定義する設計情報定義部と、
   前記設計情報定義部にて定義された設計情報を格納する設計情報記憶部とを備え、
   前記設計メタ情報及び前記設計情報の各々が示す情報は、情報の名称、属性及び情報を定義する操作より構成され、
   前記モデルクラスは前記仕様の最小単位の型であり、
   前記モデル間関連クラスは、前記モデルクラスとして定義した任意の２つのモデルクラス間の関連の型であり、
   前記ドキュメントクラスは、前記仕様の開発の際に作成するドキュメントの最小単位の型であり、
   前記モデルドキュメント間関連クラスは、前記モデルクラスと前記ドキュメントクラスの間の関連の型であり、
   前記モデルインスタンスは、前記仕様の最小単位の実体であり、前記属性として前記モデルクラスの識別子、インスタンスの識別子及び子となるモデルインスタンスの識別子、前記操作として制約条件を備え、
   前記モデル間関連インスタンスは、前記モデルクラスとして定義した任意の２つのモデルクラス間の関連の実体であり、前記属性として前記モデル間関連クラスの識別子、関連元のモデルインスタンス識別子及び関連先のモデルインスタンス識別子、前記操作として制約条件を備え、
   前記ドキュメントインスタンスは、前記仕様の開発の際に作成するドキュメントの最小単位の実体であり、前記属性として前記ドキュメントクラスの識別子、ドキュメントインスタンスの識別子及び子となるドキュメントインスタンスの識別子、前記操作として制約条件を備え、
   前記モデルドキュメント間関連インスタンスは、前記モデルドキュメント間関連クラスとして定義した関連の実体であり、前記属性として前記モデルドキュメント間関連クラスの識別子、関連元のモデルインスタンス識別子及び関連先のドキュメントインスタンス識別子、前記操作として制約条件を備える
   ことを特徴とする仕様管理装置。
5. ソフトウェア若しくはシステムの仕様の管理を行う仕様管理方法であって、
   仕様を設定する管理者端末からの要求により、モデルクラスのデータ、モデル間関連クラスのデータ、ドキュメントクラスのデータ及びモデルドキュメント間関連クラスのデータを含む設計メタ情報を設計メタ情報定義部が定義し、設計メタ情報記憶部に格納するステップと、
   前記仕様を生成するユーザ端末からの要求により、設計情報定義部が前記設計メタ情報記憶部内の前記設計メタ情報を基に、モデルインスタンスのデータ、モデル間関連インスタンスのデータ、ドキュメントインスタンスのデータ及びモデルドキュメント間関連インスタンスのデータを含む設計情報を定義し、設計情報記憶部に格納するステップと、
   前記モデルインスタンス、前記モデル間関連インスタンス、前記ドキュメントインスタンス及び前記モデルドキュメント関連インスタンスの各々が備える、クラス制約条件、インスタンス制約条件及び特定インスタンス制約条件を前記設計情報が満たしているかを設計情報検証部が検証するステップ
   とを備えることを特徴とする仕様管理方法。
6. ソフトウェア若しくはシステムの仕様の管理を行う仕様管理方法であって、
   仕様を設定する管理者端末からの要求により設計メタ情報定義部が設計メタ情報を定義し、設計メタ情報記憶部に格納するステップと、
   前記仕様を生成するユーザ端末からの要求により、設計情報定義部が前記設計メタ情報記憶部内の前記設計メタ情報を基に設計情報を定義し、設計情報記憶部に格納するステップと、
   前記設計情報記憶部内の前記設計情報の各々に、設計情報構成管理部がバージョンを設定するステップと、
   前記設計情報構成管理部より設定された第１バージョンの設計情報及び第２バージョンの設計情報を取得し、設計情報トレース管理部が前記第１バージョンの設計情報と前記第２バージョンの設計情報との間の変更点を検出し、前記変更点によって影響を受けるモデルを修正影響範囲として検出して前記ユーザ端末に提示し、トレース処理を行った結果を前記ユーザ端末に提示するステップ
   とを備えることを特徴とする仕様管理方法。
7. ソフトウェア若しくはシステムの仕様の管理を行う仕様管理方法であって、
   仕様を設定する管理者端末からの要求により設計メタ情報定義部が設計メタ情報を定義し、設計メタ情報記憶部に格納するステップと、
   前記仕様を生成するユーザ端末からの要求により、設計情報定義部が前記設計メタ情報記憶部内の前記設計メタ情報を基に設計情報を定義し、設計情報記憶部に格納するステップと、
   前記ユーザ端末より受信するドキュメント生成要求に基づいて、設計書生成部が前記設計情報記憶部より前記設計情報を取得し、仕様書を作成するステップ
   とを備えることを特徴とする仕様管理方法。
8. ソフトウェア若しくはシステムの仕様の管理を行う仕様管理方法であって、
   前記仕様を定義する管理者端末からの要求により、設計メタ情報定義部が、
   前記仕様の最小単位の型であるモデルクラスのデータ、
   前記モデルクラスとして定義した任意の２つのモデルクラス間の関連の型であるモデル間関連クラスのデータ、
   前記仕様の開発の際に作成するドキュメントの最小単位の型であるドキュメントクラスのデータ、及び
   前記モデルクラスと前記ドキュメントクラス間の関連の型であるモデルドキュメント間関連クラスを備える前記モデルドキュメント間関連クラスのデータ
   を含む設計メタ情報を定義し、設計メタ情報記憶部に格納するステップと、
   前記仕様を生成するユーザ端末からの要求により、設計情報定義部が前記設計メタ情報記憶部内の前記設計メタ情報を基に、
   前記仕様の最小単位の実体であり、前記モデルクラスの識別子、インスタンスの識別子、子となるモデルインスタンスの識別子及びインスタンス毎の制約条件を備えるモデルインスタンスのデータ、
   前記モデルクラスとして定義した任意の２つのモデルクラス間の関連の実体であり、前記モデル間関連クラスの識別子、関連元のモデルインスタンス識別子、関連先のモデルインスタンス識別子及びインスタンス毎の制約条件を備えるモデル間関連インスタンスのデータ、
   前記仕様の開発の際に作成するドキュメントの最小単位の実体であり、前記属性として前記ドキュメントクラスの識別子、ドキュメントインスタンスの識別子及び子となるドキュメントインスタンスの識別子、インスタンス毎の制約条件を備えるドキュメントインスタンスのデータ、及び
   前記モデルドキュメント間関連クラスとして定義した関連の実体であり、前記モデルドキュメント間関連クラスの識別子、関連元のモデルインスタンス識別子、関連先のドキュメントインスタンス識別子及びインスタンス毎の制約条件を備えるモデルドキュメント間関連インスタンスのデータ
   を含む設計情報を定義し、設計情報記憶部に格納するステップ
   とを備えることを特徴とする仕様管理方法。
9. ソフトウェア若しくはシステムの仕様の管理を行うコンピュータにおいて、
   仕様を設定する管理者端末からの要求により、モデルクラスのデータ、モデル間関連クラスのデータ、ドキュメントクラスのデータ及びモデルドキュメント間関連クラスのデータを含む設計メタ情報を設計メタ情報定義部が定義し、設計メタ情報記憶部に格納する命令と、
   前記仕様を生成するユーザ端末からの要求により、設計情報定義部が前記設計メタ情報記憶部内の設計メタ情報を基に、モデルインスタンスのデータ、モデル間関連インスタンスのデータ、ドキュメントインスタンスのデータ及びモデルドキュメント間関連インスタンスのデータを含む設計情報を定義し、設計情報記憶部に格納する命令と、
   前記モデルインスタンス、前記モデル間関連インスタンス、前記ドキュメントインスタンス及び前記モデルドキュメント関連インスタンスの各々が備える、クラス制約条件、インスタンス制約条件及び特定インスタンス制約条件を前記設計情報が満たしているかを設計情報検証部が検証する命令
   とを実行させることを特徴とする仕様管理プログラム。
10. ソフトウェア若しくはシステムの仕様の管理を行うコンピュータにおいて、
    仕様を設定する管理者端末からの要求により設計メタ情報定義部が設計メタ情報を定義し、設計メタ情報記憶部に格納する命令と、
    前記仕様を生成するユーザ端末からの要求により、設計情報定義部が前記設計メタ情報記憶部内の前記設計メタ情報を基に設計情報を定義し、設計情報記憶部に格納する命令と、
    前記設計情報記憶部内の前記設計情報の各々に、設計情報構成管理部がバージョンを設定する命令と、
    前記設計情報構成管理部より設定された第１バージョンの設計情報及び第２バージョンの設計情報を取得し、設計情報トレース管理部が前記第１バージョンの設計情報と前記第２バージョンの設計情報との間の変更点を検出し、前記変更点によって影響を受けるモデルを修正影響範囲として検出して前記ユーザ端末に提示し、トレース処理を行った結果を前記ユーザ端末に提示する命令
    とを実行させることを特徴とする仕様管理プログラム。
11. ソフトウェア若しくはシステムの仕様の管理を行うコンピュータにおいて、
    仕様を設定する管理者端末からの要求により設計メタ情報定義部が設計メタ情報を定義し、設計メタ情報記憶部に格納する命令と、
    前記仕様を生成するユーザ端末からの要求により、設計情報定義部が前記設計メタ情報記憶部内の前記設計メタ情報を基に設計情報を定義し、設計情報記憶部に格納する命令と、
    前記ユーザ端末より受信するドキュメント生成要求に基づいて、設計書生成部が前記設計情報記憶部より前記設計情報を取得し、仕様書を作成する命令
    とを実行させることを特徴とする仕様管理プログラム。
12. ソフトウェア若しくはシステムの仕様の管理を行うコンピュータにおいて、
    前記仕様を定義する管理者端末からの要求により、設計メタ情報定義部が、
    前記仕様の最小単位の型であるモデルクラスのデータ、
    前記モデルクラスとして定義した任意の２つのモデルクラス間の関連の型であるモデル間関連クラスのデータ、
    前記仕様の開発の際に作成するドキュメントの最小単位の型であるドキュメントクラスのデータ、
    前記モデルクラスと前記ドキュメントクラス間の関連の型である前記モデルドキュメント間関連クラスのデータ
    を含む設計メタ情報を定義し、設計メタ情報記憶部に格納する命令と、
    前記仕様を生成するユーザ端末からの要求により、設計情報定義部が前記設計メタ情報記憶部内の設計メタ情報を基に、
    前記仕様の最小単位の実体であり、前記モデルクラスの識別子、インスタンスの識別子、子となるモデルインスタンスの識別子及びインスタンス毎の制約条件を備えるモデルインスタンスのデータ、
    前記モデルクラスとして定義した任意の２つのモデルクラス間の関連の実体であり、前記モデル間関連クラスの識別子、関連元のモデルインスタンス識別子、関連先のモデルインスタンス識別子及びインスタンス毎の制約条件を備えるモデル間関連インスタンスのデータ、
    前記仕様の開発の際に作成するドキュメントの最小単位の実体であり、前記属性として前記ドキュメントクラスの識別子、ドキュメントインスタンスの識別子及び子となるドキュメントインスタンスの識別子、インスタンス毎の制約条件を備えるドキュメントインスタンスのデータ、及び
    前記モデルドキュメント間関連クラスとして定義した関連の実体であり、前記モデルドキュメント間関連クラスの識別子、関連元のモデルインスタンス識別子、関連先のドキュメントインスタンス識別子及びインスタンス毎の制約条件を備えるモデルドキュメント間関連インスタンスのデータ
    を含む設計情報を定義し、設計情報記憶部に格納する命令
    とを実行させることを特徴とする仕様管理プログラム。
    
    

Images