JP2014215807A - 設計文書管理検証装置及び方法 - Google Patents

Abstract

【課題】設計文書の妥当性を段階的に確認する。【解決手段】設計文書管理検証装置は、設計文書の構造を階層的に定義するマスタ文書型定義及びマスタ文書型定義の一部分を指定するサブセット生成定義を格納するサブセット生成定義を用いて、サブセット文書型定義を生成するサブセット文書型定義生成部、サブセット文書型定義が表す厳密度の昇順に並べた、サブセット文書型定義を適用する順序を示す適用シナリオを生成する適用シナリオ生成部、適用シナリオに示される順序で、サブセット文書型定義を選択する文書型定義適用制御部、選択されたサブセット文書型定義を用いて、設計文書に含まれる未検証の部分設計文書の妥当性を検証する設計文書検証部、及び、適用シナリオに示される順序で、サブセット文書型定義ＤＢに格納されたサブセット文書型定義及びマスタ文書型定義に対応させて、部分設計文書及び設計文書の検証状況を表示する検証状況表示部を有する。【選択図】 図１

Description

ソフトウェア設計文書の妥当性を検証する設計文書管理検証装置及び方法に関する。

ソフトウェアの構造や処理仕様が記載される設計文書は、動作するソースコードを作成する指針となる重要なドキュメントである。設計文書に抜け漏れや矛盾などの不具合があると、それを元にして作成されたソースコードにバグが埋め込まれることになり、ソフトウェアの品質の低下や開発工程の遅延に繋がる恐れがある。そのため、設計文書の妥当性を可能な限り事前に検証し、不具合がないことを確認しておく必要がある。

特許文献１、２には、ソフトウェア設計文書の妥当性を検証するために、設計文書の構造を定義する文書型定義または設計文書の満たすべき制約条件などをチェックルールとして用いて、設計文書がそのチェックルールを満たしているかどうか判断することが記載されている。

特許文献３には、検証実績を記憶しておくことで、検証の進捗状況を確認することが記載されている。この技術により、検証の進捗状況から、設計文書がどこまで作られているかを把握できる。

特開平９−６８０４号公報 特開２００３−８４９８７号公報 特開２００７−７２５８０号公報

上記の技術では、設計文書が所定の文書型定義を満たしているか否かの粒度で進捗状況把握が可能である。これは、設計文書が完成するまでは、未完成であり、妥当性がないとみなされることを意味する。一般的に1つの設計文書を完成させるには、数日から数週間かかることがある。そのため、完了まで妥当性を確認できないと、修正のための手戻り工数が多くなる可能性がある。そこで、設計文書が完成前でも、部分的に妥当性を検証し、細かく進捗を確認可能な仕組みが必要である。

また、上記の技術を用いれば各設計文書の妥当性確認の進捗状況を表示することは可能であるが、各設計文書を個別に手作業で検証する必要がある。そのため、設計文書の種類や検証ステップが増えるほど手間がかかることになる。そこで、検証ステップを自動的に導出し、そのステップに応じて自動的に妥当性確認の進捗状況を表示可能な仕組みが必要となる。

開示する設計文書管理検証装置は、設計文書の構造を階層的に定義するマスタ文書型定義を格納するマスタ文書型定義ＤＢ、マスタ文書型定義の一部分を指定するサブセット生成定義を格納するサブセット生成定義ＤＢ、マスタ文書型定義及びサブセット生成定義を用いて、マスタ文書型定義のサブセットであるサブセット文書型定義を生成し、生成したサブセット文書型定義をサブセット文書型定義ＤＢに格納するサブセット文書型定義生成部、サブセット文書型定義ＤＢに格納されたサブセット文書型定義が表す厳密度の昇順に並べた、サブセット文書型定義を適用する順序を示す適用シナリオを生成し、生成した適用シナリオを適用シナリオＤＢに格納する適用シナリオ生成部、適用シナリオＤＢに格納された適用シナリオに示される順序で、サブセット文書型定義ＤＢに格納されたサブセット文書型定義を選択する文書型定義適用制御部、選択されたサブセット文書型定義を用いて、サブセット文書型定義に対応した、設計文書に含まれる未検証の部分設計文書の妥当性を検証し、部分設計文書の検証結果を検証履歴ＤＢに格納する設計文書検証部、及び、適用シナリオＤＢに格納された適用シナリオに示される順序で、サブセット文書型定義ＤＢに格納されたサブセット文書型定義及びマスタ文書型定義に対応させて、検証履歴ＤＢに格納された部分設計文書及び設計文書の検証状況を表示する検証状況表示部を有する。

本発明によれば、設計文書の妥当性が、より詳細なレベルで段階的に確認できる。

設計文書管理検証装置のソフトウェア構成例を示す図である。 設計文書管理検証装置のハードウェア構成例を示す図である。 マスタ文書型定義例を示す図である。 マスタ文書型定義に基づく設計文書例を示す図である。 マスタ文書型定義に基づくが妥当でない設計文書例を示す図である。 サブセット生成定義例を示す図である。 サブセット文書型定義例を示す図である。 サブセット文書型定義に基づく設計文書例を示す図である。 適用シナリオ例を示す図である。 設計差分例を示す図である。 検証履歴例を示す図である。 検証状況の画面表示例（文書型定義別適用有無）を示す図である。 検証状況の画面表示例（文書型定義適用件数）を示す図である。 設計文書のひな形の例を示す図である。 設計文書管理検証装置の基本構成における処理フロー例を示す図である。 設計文書管理検証装置に差分検証を加えた処理フロー例を示す図である。 設計文書管理検証装置に次段階設計文書生成を加えた処理フロー例を示す図である。 適用シナリオ生成部の処理フロー例を示す図である。

図１は、設計文書管理検証装置のソフトウェア構成例を示す図である。設計文書管理検証装置は、設計文書の段階的な厳密化作業を支援するために、段階的な検証、検証工程の可視化および設計文書作成支援を実現する装置であり、以下の各ＤＢ（データベース）及び各処理部を含む。

設計文書管理検証装置は、設計文書の構造を規定するマスタ文書型定義を格納するマスタ文書型定義ＤＢ１０１、および、マスタ文書型定義に指定されたサブセットを生成するサブセット生成定義を格納するサブセット生成定義ＤＢ１０２を有する。マスタ文書型定義およびサブセット生成定義を用いて、サブセット文書型定義生成部１０３は、マスタ文書型定義から指定されたサブセットを生成し、生成したサブセット文書型定義をサブセット文書型定義ＤＢ１０４に格納する。

適用シナリオ生成部１０５は、生成された複数のサブセット文書型定義を、設計文書に対して適用する順序を定めた適用シナリオを生成し、生成した適用シナリオを適用シナリオＤＢ１０６に格納する。

文書型定義適用制御部１０７は、適用シナリオに従って、設計文書に対するサブセット文書型定義を選択し、選択したサブセット文書型定義を設計文書検証部１１３に通知する。設計文書検証部１１３は、通知されたサブセット文書型定義を用いて設計文書（厳密には、設計文書の一部を構成する部分設計文書であり、その構造はサブセット文書型定義に対応している。以下、未検証の又は検証済みの設計文書は、各々サブセット文書型定義に対応した部分設計文書である。）の妥当性を検証し、検証結果を検証設計文書ＤＢ１１２及び検証履歴ＤＢ１１１に格納する。検証状況表示部１１５は、検証設計文書ＤＢ１１２に格納されている検証結果をまとめて、検証の状況および設計の進捗状況などを表示する。以上が、設計文書管理検証装置の基本構成である。

設計文書差分抽出部１０８は、同じサブセット文書型定義を適用する、検証予定の設計文書と既に検証済みの設計文書との差分を抽出し、抽出した設計文書間の設計差分を設計差分ＤＢ１０９に格納する。たとえば、既に検証済みの設計文書は、たとえば設計者により指定される、検証予定の設計文書の元にした設計文書である。差分適用評価部１１０は、設計文書間の設計差分が、既にある検証結果（元にした設計文書の検証結果）に影響があるかどうかを評価し、影響がない場合には元にした設計文書の検証結果を再利用し（元にした設計文書の検証結果を、検証対象の設計文書の検証結果とする）、影響がある場合には設計文書検証部１１３に検証を指示する。影響がある場合の典型例は、設計差分に関する定義がサブセット文書型定義に含まれる場合である。このようにして、再利用の可能性がある検証結果が既にある場合に、差分検証により検証結果の再利用を可能にする。以上が設計文書管理検証装置の差分検証に係る構成である。

次段階設計文書生成部１１６は、適用シナリオＤＢ１０６に格納されている適用シナリオに従って、サブセット文書型定義ＤＢ１０４から次に適用するサブセット文書型定義（次定義）と直前に適用し、設計文書の検証に用いたサブセット文書型定義（現定義）を取得し、それらのサブセット文書型定義の間の差分を抽出し、抽出した差分を用いて、サブセット文書型定義（現定義）により検証済みの設計文書に、追加/変更/削除の処理を実行し、その設計文書を厳密化した、新たな設計文書のひな形を生成し、表示することにより、設計者の設計を支援する。具体的には、設計者は、ひな形の未完成部分を設定する。たとえば、変数がひな型に定義され、設計者はその変数の値を指定する。厳密化の対象の設計文書は、検証設計文書ＤＢ１１２に検証結果が格納されている、サブセット文書型定義（現定義）直前に適用して検証した設計文書である。以上が設計文書管理検証装置において、段階的に検証するために設計文書の厳密化に係る構成である。

図２は、設計文書管理検証装置のハードウェア構成例を示す図である。設計文書管理検証装置２００は、ＣＰＵ２０１、表示装置２０２、入力装置２０３、メモリ２０４、外部記憶装置２０５から構成される。ＣＰＵ２０１は、外部記憶装置２０５に保持されるプログラム（図１の各処理部）およびデータ（図１の各ＤＢ及び検証対象の設計文書）をメモリ２０４上に読込み、設計文書の管理および検証に関する処理を実行する。表示装置２０２は、ＣＰＵ２０１による処理結果（検証の状況および設計の進捗状況や次段階設計文書生成部１１６が生成したひな形など）を表示する。入力装置２０３は、処理部の実行要求や表示したひな型に対する設計内容を入力する。メモリ２０４は、主記憶装置であり、ＣＰＵ２０１が実行するためのプログラムおよびデータを読み込む。外部記憶装置２０５は、補助記憶装置であり、実行に必要なプログラムおよびデータ（図１の各ＤＢ）を保持する。

図３および図４は、それぞれマスタ文書型定義例とそのマスタ文書型定義に沿って記述された設計文書例を示す図である。

マスタ文書型定義ＤＢ１０１に格納されているマスタ文書型定義は、最終的に完成する設計文書の構造を規定する定義である。設計文書は、ソフトウェアの設計情報を構造的に定義した文書であり、マスタ文書型定義に沿った構造で記述される。

マスタ文書型定義は、文書構造を規定できればよく、設計文書も設計情報を構造的に表現できればよいため、そのフォーマットは問わない。一例として、設計文書をXML形式のフォーマットで記述し、マスタ文書型定義をXMLSchema形式のフォーマットで記述することができる。

図３は、XMLSchema形式のマスタ文書型定義の例であり、図４は、XML形式の設計文書の例を示している。マスタ文書型定義例３００では、木構造の文書のトップレベルにRoot要素３０１があり、その直下にElement1要素３０２があり、その直下にElement1-1要素３０３があるという階層構造を定義している。マスタ文書型定義は、このマスタ文書型定義に基づく設計文書の、Root、Element1などの要素名を持ったデータが、マスタ文書型定義と同じ階層構造で記述されるための制約ルールを記述するものである。実際に、図３のマスタ文書型定義例３００に従って、図４の設計文書例４００のように設計文書が記述される。設計文書例４００では、Element1-1の値としてvalue1-1が設計されている。同様にElement2-1、Element2-2の値も設計されている。

図５は、図３のマスタ文書型定義例３００に基づくが、妥当でない設計文書の例を示す図である。例えば、Element1要素の直下にElement1-2要素５０１が記述されているが、マスタ文書型定義３００では、Element1-2要素については規定されておらず（図３のElement1要素３０２のネストの中にElement1-2要素は含まれていない）、Element1-2要素５０１の記述が妥当ではない。よって、この設計文書例５００を、マスタ文書型定義３００を用いて検証した場合、妥当ではないと判定されることになる。

図６は、サブセット生成定義ＤＢ１０２に格納されているサブセット生成定義例を示す図である。サブセット生成定義例６００は、マスタ文書型定義例３００のサブセットを指定する定義である。サブセット生成定義は、マスタ文書型定義の階層構造を木構造として、その部分木の取捨選択を定義する。サブセット生成定義例６００は、マスタ文書型定義例３００のうち、Root要素直下のElement1要素６０１およびElement3要素６０３については、各々の子要素（たとえば、Element1要素６０１のネストに含まれる要素）を選択（利用）し、Element2要素６０２については、その子要素を選択しないことを定義している。マスタ文書型定義の要素のうち、このサブセット生成定義で選択された要素が残されたものをサブセット文書型定義として生成する。

図７および図８は、それぞれサブセット文書型定義例とそのサブセット文書型定義に沿って記述された設計文書例を示す図である。サブセット文書型定義例７００は、マスタ文書型定義例３００（図３）およびサブセット生成定義例６００（図６）を用いて生成したサブセット文書型定義の例である。マスタ文書型定義例３００では、Element2要素以下の要素（たとえば、Element2-1）まで規定されているが、サブセット文書型定義例７００では、サブセット生成定義例６００の選択に応じて、Element2要素以下の要素（たとえば、Element2-1）が削除されている（７０１）。図８の設計文書例８００は、サブセット文書型定義例７００に沿って記述された設計文書例である。設計文書例８００において、Element2要素以下の要素（たとえば、Element2-1）に関する記述が削除されている。

一つのマスタ文書型定義に関してサブセット生成定義を複数種類用意することにより、マスタ文書型定義よりも設計文書に対する制約ルールを緩くして（要素の削除を定義した）、厳密度を変えた多様なサブセット文書型定義を生成できる。

図９は、適用シナリオＤＢ１０６に格納されている適用シナリオ例を示す図である。適用シナリオ例９００は、一つのマスタ文書型定義に関して複数のサブセット文書型定義を生成した場合に、設計文書に対して適用し検証していくためのサブセット文書型定義の順番を定義する。適用シナリオ例９００では、subset2.xsdというファイル名のサブセット文書型定義の適用に引き続いてsubset1.xsdというファイル名のサブセット文書型定義を適用することを記述（９０１）している。その記述の中に適用条件がある場合には、その適用条件を記載する。適用シナリオ例９００の例では、1番目のsubset2.xsdというファイル名のサブセット文書型定義の適用結果が成功（true）した場合に、2番目 のsubset1.xsdというファイル名のサブセット文書型定義を適用するという条件を定義（９０２）している。このように、適用シナリオには、適用順番だけでなく、条件分岐も定義される。

適用シナリオでは、複数のサブセット文書型定義の適用順番を定義できるため、例えば、厳密度の低いサブセット文書型定義から厳密度の高いサブセット文書型定義までを段階的に適用し、設計文書の厳密度を徐々に高める作業を支援することも可能である。厳密度とは、木構造のマスタ文書型定義が最も厳密度が高く、ルートノードから直下の要素のネストの深さが深いほど厳密度が高くなる。図７を用いて説明したように、Element2要素以下の要素（たとえば、Element2-1）まで規定したサブセット生成定義は、Element2要素以下の要素（たとえば、Element2-1）を削除したサブセット生成定義よりも厳密度が高い。この例では、Element2要素以下の要素を削除したことにより厳密度が低くなっている。

図１０は、設計差分ＤＢ１０９に格納されている設計差分例を示す図である。設計差分は、２つの設計文書間の差分を設計文書の要素単位で抽出した結果である。設計差分例１０００は、設計文書例４００（図４）と設計文書例８００（図８）との差分を抽出した例である。この場合、設計文書例４００は、設計文書例８００に対して、Element2要素直下のElement2-1要素の追加し（１００１）、Element2-2要素を追加した（１００２）という結果の設計差分を記述している。設計差分は、追加だけでなく、要素の変更や要素の削除に関しても同様に記述する。たとえば、設計文書例８００は、設計文書例４００に対して、Element2要素直下のElement2-1要素の削除とElement2-2要素の削除という結果の設計差分を、図１０に示すDeleteElementに記述する。

図１１は、検証履歴ＤＢ１１１に格納される検証履歴例を示す図である。検証履歴は、設計文書に対してサブセット文書型定義を適用し設計文書の妥当性を検証した結果の記録である。検証履歴１１００は、２つの検証履歴１１０１、１１０２を記載している。検証履歴１１０１、１１０２の各々には、検証日時、検証対象の設計文書および検証に用いたサブセット文書型定義と検証結果を記載する。検証履歴１１００からは、同じ設計文書（sample1.xml）に対して厳密度の異なるサブセット文書型定義（subset2.xsd及びsubset1.xsd）を用いて検証した例を示している。

図１２、図１３は、検証状況表示部１１５により表示装置に表示される検証状況の画面表示例を示す図である。検証状況の画面表示は、検証履歴ＤＢ１１１に格納されている、設計文書の検証履歴を用いて、それぞれどの程度まで検証が進んでいるか、換言すると設計文書の厳密度はどこまで担保されているのかを表示し、設計者が確認できるようにする。

図１２の画面表示例１２００は、厳密度をサブセット文書型定義別の適用有無として、各設計文書が、現時点でどの文書型定義まで検証済みかを表示している。具体意的には図示するように、検証済み（検証成功）、未検証又は検証失敗、検証不要を識別できるように表示する。適用シナリオの検証順番に対応して（図１では、検証状況表示部１１５が適用シナリオＤＢ１０６を参照する矢印を、図面の煩雑化を避けるために省略）、すなわち厳密度の低いサブセット文書型定義から厳密度の高いサブセット文書型定義の順番に左から右に表示し、最も右に最も厳密度の高いマスタ文書型定義を表示している。例えば、Document1の進捗状況（１２０１）は、３つのサブセット文書型定義（Subset6.xsd、Subset5.xsd、Subset4.xsd）までの検証が成功しており、それ以降のサブセット文書型定義に関する検証は完了していない（未検証又は検証失敗）ことを表している。またDocument3の進捗状況（１２０２）は、後半の文書型定義(Subset2.xsd、Subset1.xsd、Master.xsd)は検証不要であることを表している。

図１３の画面表示例１３００は、厳密度を検証済みのサブセット文書型定義およびマスタ文書型定義の件数として、各設計文書が、現時点でどの程度の数のサブセット文書型定義およびマスタ文書型定義を用いて検証済みかを表示する。マスタ文書型定義を用いて検証済みである場合は、その文書の検証が完了していることを意味している。つまり、検証済みの件数が多ければ多いほど、その設計文書は厳密であると言える。例えば、Document1に関する進捗状況（１３０１）は、３件の検証が完了していることを表している。

図１４は、次段階設計文書生成部１１６によって生成される設計文書のひな形の例を示す図である。次段階設計文書生成部１１６では、適用シナリオＤＢ１０６に格納されている適用シナリオを参照して、次に適用し検証するサブセット文書型定義に対応する設計文書のひな形を生成する。次段階設計文書生成部１１６が、直前に検証したサブセット文書型定義と次に検証するサブセット文書型定義の差分を抽出し、差分の内容に応じて設計文書へ追加・削除・変更を行うことによって設計文書のひな形を生成する。設計文書のひな形例１４００は、サブセット文書型定義例７００を検証済みの設計文書に対して、次にマスタ文書型定義例３００を検証する際に、その文書型定義例３００に沿ったひな形を生成した例である。サブセット文書型定義例７００に対して、マスタ文書型定義例３００では、Element2-1要素とElement2-2要素の追加が必要になる。そのため、サブセット文書型定義例７００を検証済みの設計文書に対して、Element2-1要素とElement2-2要素の空データ１４０１、１４０２（要素の構造を定義しているが、要素の値が決定されていないデータ）を挿入することでひな形を生成する。空データ部分は、設計者が編集する。具体的には、Element2-1要素とElement2-2要素の値を設計者が設定する。

これにより次のサブセット文書型定義又はマスタ文書型定義に従った設計文書を作成する手間を一部省くことができる。

図１５は、前述の設計文書管理検証装置の基本構成における処理フローである。設計文書管理検証装置において、サブセット文書型定義生成部１０３が、サブセット文書型定義を生成する（ステップ１５０１）。マスタ文書型定義ＤＢ１０１に格納されているマスタ文書型定義およびサブセット生成定義ＤＢ１０２に格納されているサブセット生成定義を用いてサブセット文書型定義を生成し、サブセット文書型定義ＤＢ１０４に格納する。サブセット文書型定義の生成方法は、図３、図６及び図７を用いて説明したとおりである。

適用シナリオ生成部１０５は、サブセット文書型定義ＤＢ１０４に格納された複数のサブセット文書型定義の厳密度に応じてサブセット文書型定義を検証に適用する順序を決定し、その順序を適用シナリオとして適用シナリオＤＢ１０６に格納する（ステップ１５０２）。

文書型定義適用制御部１０７は、適用シナリオに定義された順番に従って、適用シナリオに記載のサブセット文書型定義を選択し、選択したサブセット文書型定義を用いて設計文書を検証するように設計文書検証部１１３に通知する（ステップ１５０３）。

設計文書検証部１１３は、文書型定義適用制御部１０７から通知されたサブセット文書型定義を用いて、対象の設計文書の妥当性を検証し、検証結果を検証設計文書ＤＢ１１２及び検証履歴ＤＢ１１１に格納する（ステップ１５０４）。設計文書の妥当性の検証方法は、図３〜図５を用いて説明したとおりである。また検証履歴ＤＢ１１１に格納される検証履歴は、設計文書と検証に用いたサブセット文書型定義との対であり、図１１を用いて説明したとおりである。

設計文書検証部１１３は、サブセット文書型定義を用いた設計文書の検証の終了毎に、検証状況表示部１１５に通知し、検証状況表示部１１５は、図１２および図１３を用いて説明した、表示装置に表示されている検証状況の画面表示内容を更新する（ステップ１５０５）。

文書型定義適用制御部１０７は、適用シナリオに定義されたすべてのサブセット文書型定義を用いた設計文書の検証が終了したかを判定し（最終的には、厳密度が最も高いマスタ文書型定義を用いた設計文書の検証が終了したかを判定し）（ステップ１５０６）、終了していなければ、ステップ１５０３に戻り、終了していれば、処理を終了する。

図１６は、図１５の処理フローに加えて差分検証を行うための処理を追加した処理フローである。設計文書管理検証装置において、図１５と同様に、サブセット文書型定義生成部１０３が、サブセット文書型定義を生成し（ステップ１６０１）、適用シナリオ生成部１０５が適用シナリオを生成し（ステップ１６０２）、文書型定義適用制御部１０７がサブセット文書型定義を選択する（ステップ１６０３）。一方、設計文書差分抽出部１０８は、検証対象の設計文書とその設計文書の一段階前の検証済み設計文書を比較し、設計差分を抽出し、抽出した設計差分を設計差分ＤＢ１０９に格納する（ステップ１６０４）。設計差分を抽出については、図１０を用いて説明したとおりである。差分適用評価部１１０は、文書型定義適用制御部１０７により選択されたサブセット文書型定義を参照し、抽出した設計差分が、比較した検証済み設計文書の検証結果に影響があるかどうかを評価する（ステップ１６０５）。差分適用評価部１１０による評価結果が、サブセット文書型定義が設計差分に関係していない（選択されたサブセット文書型定義に基づいた検証結果が設計差分による影響を受けない）場合、つまり設計差分に関する定義が、選択されたサブセット文書型定義に含まれていない場合には（ステップ１６０６）、比較した検証済み設計文書の検証結果を再利用し、次のサブセット文書型定義の選択のためにステップ１６０３へ移る。サブセット文書型定義が設計差分に関係している場合、つまり設計差分に関する定義が、選択されたサブセット文書型定義に含まれている場合には、比較した検証済み設計文書の検証結果を再利用できないので、設計文書検証部１１３は、選択されたサブセット文書型定義を用いて、対象の設計文書の妥当性を検証する（ステップ１６０７）。ステップ１６０８及びステップ１６０９は、図１５のステップ１５０５及びステップ１５０６と同様であるので、説明を省略する。

図１７は、図１５の処理フローに加えて次段階の設計文書生成を行うための処理を追加した処理フローである。設計文書管理検証装置において、図１５と同様に、サブセット文書型定義生成部１０３が、サブセット文書型定義を生成し（ステップ１７０１）、適用シナリオ生成部１０５が適用シナリオを生成し（ステップ１７０２）、文書型定義適用制御部１０７がサブセット文書型定義を選択する（ステップ１７０３）。ここで、図１５では、検証するための設計文書はあらかじめ作成済みとしていたが、設計文書を作成・修正するのは手間がかかるため、可能なものに対しては設計文書のひな形を生成する。次段階設計文書生成部１１６は、文書型定義適用制御部１０７により選択されたサブセット文書型定義について、適用シナリオ上１つ前のサブセット文書型定義で検証済みの設計文書がある場合、選択されたサブセット文書型定義と１つまえのサブセット文書型定義の差分を抽出し、その差分情報を用いて検証済みの設計文書に対して要素の削除・修正または空データをもつ新規要素の追加を行い、次段階設計文書のひな形を生成する（ステップ１７０４）。空データをもつ新規要素を追加した場合、ひな形を表示し、設計者による設計文書の完成を待つ。前述のようにステップ１７０５〜ステップ１７０７は、図１５のステップ１５０４〜ステップ１５０６と同様であるので、説明を省略する。

図１８は、適用シナリオ生成部１０５の処理フローチャートである。サブセット文書型定義ＤＢ１０４に格納されているサブセット文書型定義を解析し、マスタ文書型定義ＤＢ１０１に格納されているマスタ文書型定義をルートノードとして、各サブセット文書型定義が親子関係を持つ木構造のデータ構造を保持する（ステップ１８０１）。その木構造を参照し、階層の深さ、要素数の多さの数値を用いて、より階層が深く、より要素数が多いサブセット文書型定義が、より詳細であるとなるように文書型定義の厳密度を数値化（階層の深さ×要素数）する（ステップ１８０２）。マスタ文書型定義に対応した各サブセット文書型定義の厳密度が数値化済み化をチェックし（ステップ１８０３）、未だならばステップ１８０１に戻る。サブセット文書型定義を厳密度に応じて昇順に順位付けし（同じ厳密度のときは、階層の深さが深い方が高い厳密度であり、階層の深さも同じならば順位は任意）、各サブセット文書型定義とその順位情報を適用シナリオとして生成する（ステップ１８０４）。

本実施形態の設計文書管理検証装置によれば、設計文書の妥当性が、より詳細なレベルで段階的に確認できる。

また、検証済みの設計文書と検証対象の設計文書の設計差分が、検証済み設計文書の検証結果に影響があるかどうかを評価した上で、検証済みの設計文書を再利用できる。

また、適用順序が連続するサブセット文書型定義間の差分を利用して、検証済みの設計文書に対して次に検証すべき設計文書（次段階設計文書）のひな形を生成できるので、設計者による設計を支援できる。

１０１…マスタ文書型定義ＤＢ、１０２…サブセット生成定義ＤＢ、１０３ …サブセット文書型定義生成部、１０４…サブセット文書型定義ＤＢ、１０５ …適用シナリオ生成部、１０６…適用シナリオＤＢ、１０７ …文書型定義適用制御部、１０８ …設計文書差分抽出部、１０９…設計差分ＤＢ、１１０ …差分適用評価部、１１１…検証履歴ＤＢ、１１２検証設計文書ＤＢ、１１３ …設計文書検証部、１１５ …検証状況表示部、１１６ …次段階設計文書生成部、２００ …設計文書管理検証装置。

Claims (12)

1. 設計文書の構造を階層的に定義するマスタ文書型定義を格納するマスタ文書型定義ＤＢ、
   前記マスタ文書型定義の一部分を指定するサブセット生成定義を格納するサブセット生成定義ＤＢ、
   前記マスタ文書型定義及び前記サブセット生成定義を用いて、前記マスタ文書型定義のサブセットであるサブセット文書型定義を生成し、生成した前記サブセット文書型定義をサブセット文書型定義ＤＢに格納するサブセット文書型定義生成部、
   前記サブセット文書型定義ＤＢに格納された前記サブセット文書型定義が表す厳密度の昇順に並べた、前記サブセット文書型定義を適用する順序を示す適用シナリオを生成し、生成した前記適用シナリオを適用シナリオＤＢに格納する適用シナリオ生成部、
   前記適用シナリオＤＢに格納された前記適用シナリオに示される順序で、前記サブセット文書型定義ＤＢに格納された前記サブセット文書型定義を選択する文書型定義適用制御部、
   選択された前記サブセット文書型定義を用いて、前記サブセット文書型定義に対応した、前記設計文書に含まれる未検証の部分設計文書の妥当性を検証し、前記部分設計文書の検証結果を検証履歴ＤＢに格納する設計文書検証部、及び、
   前記適用シナリオＤＢに格納された前記適用シナリオに示される順序で、前記サブセット文書型定義ＤＢに格納された前記サブセット文書型定義及び前記マスタ文書型定義に対応させて、前記検証履歴ＤＢに格納された前記部分設計文書及び前記設計文書の検証状況を表示する検証状況表示部を有することを特徴とする設計文書管理検証装置。
2. 前記設計文書検証部は、前記部分設計文書の前記検証結果として前記部分設計文書と検証に用いた前記サブセット文書型定義を対応させて前記検証履歴ＤＢに格納し、
   前記文書型定義適用制御部が選択した、前記適用シナリオＤＢに格納された新たな前記サブセット文書型定義に基づいて、新たな部分設計文書を検証するとき、前記検証履歴ＤＢに格納されている新たな前記サブセット文書型定義を適用した前記部分設計文書と前記新たな部分設計文書との設計差分を抽出する設計文書差分抽出部、及び、
   前記設計差分が、前記前記検証履歴ＤＢに格納されている前記部分設計文書の前記検証結果に影響がないとき、前記検証結果を前記新たな部分設計文書の検証結果として再利用する差分適用評価部をさらに備えること特徴とする請求項１に記載の設計文書管理検証装置。
3. 新たな前記サブセット文書型定義に、前記設計差分に関する定義が含まれるとき、前記差分適用評価部は、前記検証結果を前記新たな部分設計文書の検証結果として再利用しないことを特徴とする請求項２に記載の設計文書管理検証装置。
4. 前記検証状況表示部は、前記部分設計文書及び前記設計文書の検証状況を、前記サブセット文書型定義及び前記マスタ文書型定義に対応させて、検証済み、未検証、検証不要を識別できるように表示することを特徴とする請求項１に記載の設計文書管理検証装置。
5. 前記文書型定義適用制御部が選択した、前記適用シナリオＤＢに格納された新たな前記サブセット文書型定義と、前記部分設計文書の検証に直前に適用した前記サブセット文書型定義との差分を抽出し、抽出した前記差分を用いて、前記サブセット文書型定義により直前に検証した前記部分設計文書に、抽出した前記差分に対応した追加/変更/削除の処理を実行した新たな部分設計文書のひな形を生成する次段階設計文書生成部をさらに備えること特徴とする請求項１に記載の設計文書管理検証装置。
6. 抽出した前記差分に対応した追加の処理は、構造を定義し、値が未決定の要素を示す空データを、直前に検証した前記部分設計文書に追加すること特徴とする請求項５に記載の設計文書管理検証装置。
7. 設計文書の構造を階層的に定義するマスタ文書型定義を格納するマスタ文書型定義ＤＢ、及び前記マスタ文書型定義の一部分を指定するサブセット生成定義を格納するサブセット生成定義ＤＢを有する設計文書管理検証装置における設計文書管理検証方法であって、前記設計文書管理検証装置は、
   前記マスタ文書型定義及び前記サブセット生成定義を用いて、前記マスタ文書型定義のサブセットであるサブセット文書型定義を生成し、生成した前記サブセット文書型定義をサブセット文書型定義ＤＢに格納し、
   前記サブセット文書型定義ＤＢに格納された前記サブセット文書型定義が表す厳密度の昇順に並べた、前記サブセット文書型定義を適用する順序を示す適用シナリオを生成し、生成した前記適用シナリオを適用シナリオＤＢに格納し、
   前記適用シナリオＤＢに格納された前記適用シナリオに示される順序で、前記サブセット文書型定義ＤＢに格納された前記サブセット文書型定義を選択し、
   選択された前記サブセット文書型定義を用いて、前記サブセット文書型定義に対応した、前記設計文書に含まれる未検証の部分設計文書の妥当性を検証し、前記部分設計文書の検証結果を検証履歴ＤＢに格納し、
   前記適用シナリオＤＢに格納された前記適用シナリオに示される順序で、前記サブセット文書型定義ＤＢに格納された前記サブセット文書型定義及び前記マスタ文書型定義に対応させて、前記検証履歴ＤＢに格納された前記部分設計文書及び前記設計文書の検証状況を表示することを特徴とする設計文書管理検証方法。
8. 前記設計文書管理検証装置は、
   前記部分設計文書の前記検証結果として前記部分設計文書と検証に用いた前記サブセット文書型定義を対応させて前記検証履歴ＤＢに格納し、
   前記適用シナリオＤＢに格納された新たな前記サブセット文書型定義に基づいて、新たな部分設計文書を検証するとき、前記検証履歴ＤＢに格納されている新たな前記サブセット文書型定義を適用した前記部分設計文書と前記新たな部分設計文書との設計差分を抽出し、
   前記設計差分が、前記前記検証履歴ＤＢに格納されている前記部分設計文書の前記検証結果に影響がないとき、前記検証結果を前記新たな部分設計文書の検証結果として再利用すること特徴とする請求項７に記載の設計文書管理検証方法。
9. 新たな前記サブセット文書型定義に、前記設計差分に関する定義が含まれるとき、前記設計文書管理検証装置は、前記検証結果を前記新たな部分設計文書の検証結果として再利用しないことを特徴とする請求項８に記載の設計文書管理検証方法。
10. 前記設計文書管理検証装置は、前記部分設計文書及び前記設計文書の検証状況を、前記サブセット文書型定義及び前記マスタ文書型定義に対応させて、検証済み、未検証、検証不要を識別できるように表示することを特徴とする請求項７に記載の設計文書管理検証方法。
11. 前記設計文書管理検証装置は、
    前記適用シナリオＤＢに格納された新たな前記サブセット文書型定義と、前記部分設計文書の検証に直前に適用した前記サブセット文書型定義との差分を抽出し、抽出した前記差分を用いて、前記サブセット文書型定義により直前に検証した前記部分設計文書に、抽出した前記差分に対応した追加/変更/削除の処理を実行した新たな部分設計文書のひな形を生成すること特徴とする請求項７に記載の設計文書管理検証方法。
12. 抽出した前記差分に対応した追加の処理は、構造を定義し、値が未決定の要素を示す空データを、直前に検証した前記部分設計文書に追加すること特徴とする請求項１１に記載の設計文書管理検証方法。

Images