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

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の節に関連付けされることを示している。

（設計情報）
次に、設計情報の事象について詳細に説明する。要求仕様５ｂのインスタンスとして、
「Ａ社顧客管理システム要求５ｃ」を定義する。要求１２ｆのインスタンスとして、「RQ
001」〜「RQ004」を定義する。このインスタンス「RQ001」〜「RQ004」は図３３に示すよ
うに、親クラスの識別子として各々が親クラスの要求内容を備えるように記述される。

若しくは図３４に示すように、モデルインスタンスの識別子を、要求（Requirements)、
機能(Function)、テストケース(Test Case)等のカテゴリ毎に分類して、システム開発の
ライフサイクル全体を通して作成する成果物のモデルクラスのインスタンスとして定義し
ても良い。なお、モデルインスタンスは、図２０のモデルインスタンス入力処理画面の識
別子、内容等に入力することにより定義される。

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

要求仕様−要求仕様書８ｂのインスタンスとして、「Ａ社顧客管理システム要求仕様−
要求仕様書８ｃ」及び「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 (3)

1. ソフトウェア若しくはシステムの開発プロセスにおいて、顧客の要件を実現するために具体化される仕様の管理者が使用する管理者端末及び前記仕様を生成するユーザが使用するユーザ端末に接続される仕様管理装置であって、
   前記管理者端末によって、開発プロセスで具体化する仕様の型を定義するモデルクラスのデータ、前記仕様に関する２つのモデル間の関連の型を定義するモデル間関連クラスのデータ、前記仕様に基づいて開発プロセスで作成されるドキュメントの型を定義するドキュメントクラスのデータ、及び任意のモデルと当該モデルの仕様に基づいて生成されるドキュメントとの間の関連の型を定義するモデルドキュメント間関連クラスのデータ、を含む設計メタ情報を格納する設計メタ情報記憶部と、
   前記設計メタ情報記憶部内の前記設計メタ情報を継承し、前記ユーザ端末からの要求により、モデルインスタンスのデータ、モデル間関連インスタンスのデータ、ドキュメントインスタンスのデータ及びモデルドキュメント間関連インスタンスのデータ、を含む設計情報を定義する設計情報定義部と、
   前記設計情報を格納する設計情報記憶部と、
   前記ユーザ端末より受信するドキュメント生成要求に基づいて、前記設計情報記憶部より前記設計情報を取得し、ドキュメントを作成する設計書生成部
   とを備え、
   前記モデルインスタンスのデータは、前記仕様の最小単位の実体のデータであり、
   前記ドキュメントインスタンスのデータは、前記開発プロセスに係る開発のライフサイクルを通じて作成するドキュメントの最小単位の実体のデータであり、
   前記モデルドキュメント間関連インスタンスのデータは、前記モデルインスタンスと前記ドキュメントインスタンスとして定義した、任意のモデルインスタンスとドキュメントインスタンス間の関連情報のデータであって、前記モデルドキュメント間関連クラスとして定義した関連の型の実体のデータであり、
   前記設計情報は、前記モデルインスタンス、前記ドキュメントインスタンス、および前記モデル間関連インスタンスを有することを特徴とする仕様管理装置。
2. ソフトウェア若しくはシステムの開発プロセスにおいて、顧客の要件を実現するために具体化される仕様の管理を行う仕様管理装置における仕様管理方法であって、
   前記仕様管理装置が、仕様を設定する管理者端末からの要求により、開発プロセスで具体化する仕様の型を定義するモデルクラスのデータ、前記仕様に関する２つのモデル間の関連の型を定義するモデル間関連クラスのデータ、前記仕様に基づいて開発プロセスで作成されるドキュメントの型を定義するドキュメントクラスのデータ、及び任意のモデルと当該モデルの仕様に基づいて生成されるドキュメントとの間の関連の型を定義するモデルドキュメント間関連クラスのデータ、を含む設計メタ情報を、設計メタ情報記憶部に格納するステップと、
   前記仕様管理装置が、前記仕様を生成するユーザ端末からの要求により、前記設計メタ情報記憶部内の前記設計メタ情報を継承するモデルインスタンスのデータ、モデル間関連インスタンスのデータ、ドキュメントインスタンスのデータ及びモデルドキュメント間関連インスタンスのデータ、を含む設計情報を定義し、設計情報記憶部に格納するステップと、
   前記仕様管理装置が、前記ユーザ端末より受信するドキュメント生成要求に基づいて、前記設計情報記憶部より前記設計情報を取得し、ドキュメントを作成するステップ
   とを備え、
   前記モデルインスタンスのデータは、前記仕様の最小単位の実体のデータであり、
   前記ドキュメントインスタンスのデータは、前記開発プロセスに係る開発のライフサイクルを通じて作成するドキュメントの最小単位の実体のデータであり、
   前記モデルドキュメント関連インスタンスのデータは、前記モデルインスタンスと前記ドキュメントインスタンスとして定義した、任意のモデルインスタンスとドキュメントインスタンス間の関連情報のデータであって、前記モデルドキュメント間関連クラスとして定義した関連の型の実体のデータであり、
   前記設計情報は、前記モデルインスタンス、前記ドキュメントインスタンス、および前記モデル間関連インスタンスを有することを特徴とする仕様管理方法。
3. ソフトウェア若しくはシステムの開発プロセスにおいて、顧客の要件を実現するために具体化される仕様の管理を行うコンピュータに、
   仕様を設定する管理者端末からの要求により、開発プロセスで具体化する仕様の型を定義するモデルクラスのデータ、前記仕様に関する２つのモデル間の関連の型を定義するモデル間関連クラスのデータ、前記仕様に基づいて開発プロセスで作成されるドキュメントの最小単位の型を定義するドキュメントクラスのデータ、及び任意のモデルと当該モデルの仕様に基づいて生成されるドキュメントとの間の関連の型を定義するモデルドキュメント間関連クラスのデータ、を含む設計メタ情報を、設計メタ情報記憶部に格納する手順と、
   前記仕様を生成するユーザ端末からの要求により、前記設計メタ情報記憶部内の前記設計メタ情報を継承するモデルインスタンスのデータ、モデル間関連インスタンスのデータ、ドキュメントインスタンスのデータ及びモデルドキュメント間関連インスタンスのデータ、を含む設計情報を定義し、設計情報記憶部に格納する手順と、
   前記ユーザ端末より受信するドキュメント生成要求に基づいて、前記設計情報記憶部より前記設計情報を取得し、ドキュメントを作成する手順
   とを実行させるための仕様管理プログラムであって、
   前記モデルインスタンスのデータは、前記仕様の最小単位の実体のデータであり、
   前記ドキュメントインスタンスのデータは、前記開発プロセスに係る開発のライフサイクルを通じて作成するドキュメントの最小単位の実体のデータであり、
   前記モデルドキュメント関連インスタンスのデータは、前記モデルインスタンスと前記ドキュメントインスタンスとして定義した、任意のモデルインスタンスとドキュメントインスタンス間の関連情報のデータであって、前記モデルドキュメント間関連クラスとして定義した関連の型の実体のデータであり、
   前記設計情報は、前記モデルインスタンス、前記ドキュメントインスタンス、および前記モデル間関連インスタンスを有することを特徴とする仕様管理プログラム。

Images