JP6185148B2 - ソフトウェア仕様間依存関係検証装置、及びソフトウェア仕様間依存関係検証方法 - Google Patents

Description

本発明は、ソフトウェア仕様間依存関係検証装置及びソフトウェア仕様間依存関係検証方法に関する。

大規模ソフトウェア開発において、複数のソフトウェア仕様間に生じる不整合は、開発工程手戻りによる予算超過が発生する主な原因であり、そのような不整合を開発早期に検知し修正しておく必要がある。ソフトウェア仕様間の不整合を検知するために、ソフトウェア仕様間の依存関係に基づいて不整合を検証することが有効である。ここで、「依存関係」とは、あるソフトウェアの基本機能仕様と詳細機能仕様のように、対応する仕様中に含まれる対応する仕様項目間に成立する関係であって、例えば対応する仕様項目同士が「一致」すること等を意味している。なお、本明細書では、以下簡単のため、「ソフトウェア仕様」を単に「仕様」と略称する。

複数の仕様間での依存関係を検証するための従来技術として、対象とする仕様間の依存関係を示す情報を用いて、その情報を図または表形式でグラフィカルに表示する手法がある。この手法を活用すると、複数のソフトウェア仕様書を開いて横並びで見比べる手間をかけることなく一目で仕様間の依存関係を把握できるようにすることができる。これにより、仕様間依存関係の不備、矛盾などの不整合を検知できるようになる。

このような技術は、例えば特許文献１、２に開示されている。特許文献１は、「複数の工程からなるソフトウェアプロセスの各工程において作成される成果物を管理する成果物管理装置であり、入力装置により、所定のシステムを開発する前記ソフトウェアプロセスの所定の工程において作成された成果物を入力する成果物入力部と、処理装置により、前記成果物入力部が入力した成果物から所定のキーワードを検索して、検索された箇所を示す検索箇所情報を抽出する情報抽出部と、処理装置により、前記情報抽出部が抽出した検索箇所情報から、前記所定のシステムにおける前記各工程で作成された成果物間の関連を管理するためのトレーサビリティ情報を作成するトレーサビリティ情報作成部と、前記トレーサビリティ情報作成部が作成したトレーサビリティ情報を記憶装置に記憶するトレーサビリティ情報記憶部と」を備えている。また、特許文献２は、「ソフトウェア開発時に、要求仕様が正しく設計仕様に反映されたか否かを検証する方法であって、開発対象のソフトウェアに対する要求仕様を記述した要求ドキュメントに要求仕様識別子を付与して、ドキュメントデータベースに格納し（ＳＴＥＰ１１）、要求ドキュメントをもとにして作成した設計ドキュメントに設計仕様識別子を付与して、ドキュメントデータベースに格納し（ＳＴＥＰ１２）、前記ドキュメントデータベースから要求ドキュメントを入力して、要求仕様識別子をもとに要求仕様リストを生成し（ＳＴＥＰ１３）、前記ドキュメントデータベースから設計ドキュメントを入力して、設計仕様識別子をもとに設計仕様リストを生成し（ＳＴＥＰ１４）、前記要求ドキュメント、設計ドキュメントの項目ごとに付与された識別子の対応を照合し、要求仕様の過不足を検査し、（ＳＴＥＰ１５）、照合結果に過不足があった場合には、要求仕様の過不足警告メッセージを出力する（ＳＴＥＰ１６）」構成を開示している。

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

しかしながら、特許文献１，２の技術では、仕様間依存関係を検証するには、事前に仕様間の依存関係またはそれに準じる情報（特許文献１では所定のキーワード検索に基づく検索箇所情報から生成されるトレーサビリティ情報、特許文献２では要求仕様識別子）を仕様書の中または外に定義しておく必要がある。この場合、仕様の物量が多いと、すべてを定義するのには多くの工数がかかり、たとえ工数をかけて定義できたとしても、仕様の修正に追随して仕様間依存関係を抜け漏れなく更新するのは困難であるという問題がある。仮に、仕様間依存関係を抜け漏れなく更新できたとしても、検証結果の可視化処理の際に表示が大量かつ複雑に入り組むこととなり、実際に仕様間依存関係の把握が困難であるという問題がある。

また、上記した特許文献１，２の技術では、仕様間依存関係の不整合は項目の過不足として検出可能である。例えば特許文献１ではトレーサビリティ情報としてのトレーサビリティマトリクスに基づいて成果物間での不整合箇所の有無を判定している。また、特許文献２では要求ドキュメント、設計ドキュメントの項目ごとに付与された識別子の対応を照合し、要求仕様の過不足を検査している。このような項目の過不足で不整合を検出する手法では、依存関係間で矛盾があったとしても検出することができないという問題がある。仕様間依存関係の矛盾として、データロックの矛盾等がある。例えば、要求仕様で特定データに排他ロックをかけてアクセスする要求項目が定義されている場合、要求項目を詳細化して設計仕様で定義した対応する設計項目でも同様に同じデータに同じ排他ロックをかけてアクセスする定義とする必要がある。しかし、ファイルが分かれていて確認漏れが生じたりした場合、設計仕様項目では排他ロックではなく誤って共有ロックと定義されてしまうこともありうる。この場合、排他ロックと共有ロックというデータアクセスの依存関係が同時に発生し、要求仕様と設計仕様間で矛盾が生じていることになる。このような仕様間での矛盾は、仕様間依存関係の抜け漏れ確認だけでは検知できない。

以上の課題を踏まえ、本発明は、仕様間に依存関係が過不足なく存在することを確認でき、また依存関係間で発生する依存関係の矛盾をも検出することができるソフトウェア仕様間依存関係検証装置及びソフトウェア仕様間依存関係検証方法を提供することを目的としている。

上記の、および他の課題を解決するための本発明の一態様は、階層構造を有するソフトウェア仕様に含まれているデータ項目である仕様項目の整合性を検証するための検証装置であって、少なくとも一組の互いに対応するソフトウェア仕様を取得し、あらかじめ前記階層構造に従って前記ソフトウェア仕様中での相対位置が設定されている前記各仕様項目を抽出するように構成されている仕様構造解析部と、前記対応するソフトウェア仕様に含まれる前記仕様項目間で成立すべき対応関係である依存関係を記述してなるマッチングルールを格納しているマッチングルール格納部と、前記マッチングルールを用いて、前記各仕様項目間の依存関係の有無を判別するように構成されている仕様項目マッチング部と、前記仕様項目マッチング部で依存関係があると判定された前記仕様項目の組合せを指定する情報を依存関係情報として抽出するように構成されている依存関係情報生成部と、前記ソフトウェア仕様間で特定の前記仕様項目の組合せについて成立すべき整合条件をルール化して定義してなる検証ルールを格納している検証ルール格納部と、特定の前記仕様項目の組合せについて、前記抽出された依存関係情報に基づき、前記検証ルール格納部に格納されている前記検証ルールに規定されている前記整合条件を満たさない依存関係があるかを判定し、満たさない依存関係があると判定した場合、当該整合条件を満たさない依存関係を前記ソフトウェア仕様間の不整合を示す不整合情報として出力するように構成されている依存関係検証部と、前記依存関係検証部からの前記不整合情報を所定のユーザインタフェースによって出力するように構成されている検証結果出力部と、有し、前記マッチングルールには、当該マッチングルール毎に、当該マッチングルールが規定している依存関係の種類を示す情報である依存関係種類情報が含まれており、前記検証ルールには、複数の前記依存関係種類間で満たすべき論理条件が含まれており、前記依存関係情報生成部は、前記依存関係情報抽出時に、依存関係情報として仕様項目間の依存関係の有無とともに、当該依存関係の種類をも抽出し、前記依存関係検証部は、抽出した複数の前記依存関係種類間で満たすべき前記論理条件に基づいて、前記仕様項目間の依存関係種類の間の不整合を検出する、ソフトウェア仕様間整合性検証装置である。

本発明によれば、仕様間に依存関係が過不足なく存在することを確認でき、また依存関係間で発生する依存関係の矛盾をも検出することができるソフトウェア仕様間依存関係検証装置及びソフトウェア仕様間依存関係検証方法が提供される。

図１は、本発明の一実施形態によるソフトウェア仕様間依存関係検証装置のソフトウェア構成例を示す図である。 図２は、本発明の一実施形態によるソフトウェア仕様間依存関係検証装置のハードウェア構成例を示す図である。 図３は、検証対象となる機能に関する仕様データ例を示す図である。 図４は、図３の仕様データ構造を規定するスキーマ定義例を示す図である。 図５は、検証対象となる処理の流れに関する仕様データ例を示す図である。 図６は、図５の仕様データ構造を規定するスキーマ定義例を示す図である。 図７は、図４と図６のスキーマ定義間のマッチングルールを規定するマッチングルールデータベース１０４の構成例を示す図である。 図８は、依存関係情報データベース１０７の構成例を示す図である。 図９Ａは、依存関係間で成立する検証ルールを規定する検証ルールデータベース１０８の構成例を示す図である。 図９Ｂは、複数の仕様項目間で成立する依存関係について例示する模式図である。 図１０は、仕様構造解析処理フロー１０００の一例を示す図である。 図１１は、仕様項目マッチング処理フロー１１００の一例を示す図である。 図１２は、依存関係情報生成処理フロー１２００の一例を示す図である。 図１３は、依存関係検証処理フロー１３００の一例を示す図である。 図１４は、検証結果可視化処理フロー１４００の一例を示す図である。 図１５は、検証結果可視化画面の一例を示す図である。 図１６は、検証結果可視化画面の他の例を示す図である。

以下、本発明について、その一実施形態に即して添付図面を参照しながら説明する。まず、本発明の一実施形態によるソフトウェア仕様間依存関係検証装置１００の構成例について説明する。図１は、本実施形態のソフトウェア仕様間依存関係検証装置（以下「検証装置」と略称する。）１００のソフトウェア構成例を示す図である。この検証装置１００は、ソフトウェア仕様間の不整合を早期検出し開発の手戻りの低減を実現するための装置である。検証装置１００は、検証対象の仕様データ、検証処理に使用する各種データ等を格納するデータベース（以下「ＤＢ」）と、ＤＢに格納されている各種データを用いて本実施形態のソフトウェア仕様間依存関係検証処理を実行するための各処理部を含んでいる。

図１に示すように、ＤＢとしては、検証対象となるソフトウェア仕様を格納する仕様ＤＢ１０１、検証対象となるソフトウェア仕様について適用される記述規則を規定するスキーマ定義を格納するスキーマ定義ＤＢ１０２、仕様データに含まれる仕様項目間の依存関係成立条件を記述したルールであるマッチングルールを格納するマッチングルールＤＢ１０４、仕様項目間の依存関係の有無を仕様項目情報と対応付けて格納する依存関係情報ＤＢ１０７、及び用語の一致等の仕様間で成立すべき整合条件をルール化して定義した検証ルールを格納する検証ルールＤＢ１０８が備えられる。これらのＤＢは、後述する検証装置１００のメモリあるいは補助記憶装置に格納され、適時に読み出されて利用される。各ＤＢの具体的な構成については後述する。

次に、処理部としては、同じく図１に示すように、仕様構造解析部１０３、仕様項目マッチング部１０５、依存関係情報生成部１０６、依存関係検証部１０９、及び検証結果可視化部１１０（検証結果出力部）が含まれる。図１では、以下に説明する本実施形態の検証装置１００で実行されるデータ処理の流れに沿って各処理部等を矢印で関連付けている。仕様構造解析部１０３は、仕様ＤＢ１０１に格納されている解析対象の仕様を参照し、スキーマ定義ＤＢ１０２からその検証対象仕様に対応するスキーマ定義を取得して、仕様構造を解析して構造化された仕様データを抽出する処理を実行する。

仕様項目マッチング部１０５は、抽出された仕様データに含まれる仕様項目間の依存関係成立条件を記述したルールであるマッチングルールをマッチングルールＤＢ１０４より抽出し、仕様構造解析部１０３で抽出した仕様データから仕様項目間の依存関係の有無を抽出する処理を実行する。

依存関係情報生成部１０６は、仕様項目マッチング部１０５で抽出した仕様項目間の依存関係の有無をリストアップして、検証対象となる各仕様から抽出した仕様項目と対応させて依存関係情報ＤＢ１０７に格納する処理を実行する。

依存関係検証部１０９は、依存関係情報ＤＢ１０７から依存関係情報を抽出し、検証ルールＤＢ１０８から定義された検証ルールを取得して、依存関係情報間で検証ルールに違反する依存関係があるかを検証し、違反があると判定した場合にはそれを仕様間の不整合情報として出力する処理を実行する。

検証結果可視化部１１０は、依存関係検証部１０９が出力した仕様間の不整合情報を可視化して出力する処理を実行する。なお、不整合情報について、視覚情報以外の例えば音声情報等により出力することも適宜採用することができる。これらの処理部はコンピュータプログラムとして構成され、後述する検証装置１００のメモリ又は補助記憶装置に格納され、プロセッサによって適時に実行される。各処理部が実行するデータ処理フローについては、処理フロー例を参照して後述する。

なお、検証装置１００には、各プログラムが稼働する基盤となるオペレーティングシステム（ＯＳ）１２０と、各プログラムへのデータ入出力処理を担当するデータ入出力部（データＩ／Ｏ部）１３０とが設けられている。ＯＳ１２０、データＩ／Ｏ部１３０は、後述する検証装置１００のハードウェア構成、プログラムの種類等に応じて適宜に選定して採用することができる。

次に、本実施形態の検証装置１００のハードウェア構成について説明する。図２は、本実施形態の検証装置１００のハードウェア構成例を示す図である。図２に示すように、検証装置１００は、プロセッサ２０１、表示装置２０２、入力装置２０３、メモリ２０４、及び補助記憶装置２０５を備え、これらの構成要素間を内部ネットワーク２０６で通信可能に接続して構成される。プロセッサ２０１は、補助記憶装置２０５に保持されるプログラム（図１の各処理部）およびデータ（図１の各ＤＢ及び仕様ＤＢ１０１に格納されている検証対象のソフトウェア仕様書）をメモリ２０４上に読込み、仕様の管理および不整合検証に関する処理を実行するＣＰＵ（Central Processing Unit）等の演算装置である。表示装置２０２は、ＣＰＵ２０１による処理結果を表示するための出力デバイスであり、適宜の形式のモニタディスプレイ等が用いられる。表示装置２０２には音声出力装置を含めてもよい。入力装置２０３は、処理部の実行要求や表示したひな型に対する設計内容を入力するための入力デバイスであり、キーボード、マウス、タッチパネル等が適宜採用される。メモリ２０４は、ＲＡＭ（Random Access Memory）等の主記憶装置であり、ＣＰＵ２０１が実行するためのプログラムおよびデータを読み込んで保持する。補助記憶装置２０５は、検証装置１００のデータ処理実行に必要なプログラム（図１の各処理部）およびデータ（図１の各ＤＢ）を保持するＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等の記憶デバイスである。

次に、本実施形態の検証装置１００による仕様間依存関係検証処理の対象となるソフトウェア仕様書（以下「仕様書」）について説明する。図３は、検証装置１００による検証対象となる構造化された仕様書３００の一例を示す図である。図３では、XML（eXtensible Markup Language）で表現した仕様書を具体例として示している。検証対象となる仕様書３００のデータは、検証処理を行うユーザが検証装置１００に入力して、図１に示す検証装置１００の仕様ＤＢ１０１に格納されている。仕様書３００は、当該仕様書によって規定されるソフトウェアが奏する機能の一覧を表現した文書である。仕様書内には、XMLタグという形で仕様項目の意味が表現される。仕様書３００は、符号３０１，３０２で指示する破線で囲んで示すように、各機能（Function）に対して"id"，"name"，"type"の各属性を有する"Data"が割当てられることを、一覧形式で表現するプログラムである。仕様書では、符号３０１で示すように、まずルート項目（Root schema）で仕様書の構造を規定するスキーマ定義のファイル参照パスが、"Root/Functions"と指定される。このように仕様書３００上で適用されるスキーマ定義ファイル（図４）を指定することで、仕様書の種類と構造を判別できるようにしておく。なお、仕様書３００は、内部に保持される仕様項目を識別できるように構造化されていれば、その形式は特定のものに制約されない。例えば、表形式あるいは図形式の仕様書においても、仕様項目を表の行・列、あるいは図のシェイプなどに割り当てることで、本XML例と同様に本発明を適用することができる。

次に、仕様書３００の構造を規定するスキーマ定義について説明する。図４は、図３に示した仕様書３００の構造を規定するスキーマ定義４００の一例を示す図である。スキーマ定義４００は、ユーザにより検証装置１００に入力され、図１に示す検証装置１００のスキーマ定義ＤＢ１０２に格納されている。図４では、XML Schemaで表現したスキーマ定義４００を具体例として説明する。XML Schemaは仕様書３００の階層構造を規定するための言語であり、図４の例では、まず符号４０１で示すように、"schema name"が"Functions"であることで、図３の仕様書３００と対応付けられている。そして、符号４０２で示すように、"Root"項目が"Function"項目を子要素（element）として持ち、符号４０３で示すように"Function"項目が"Data"項目を含み、各"Data"項目は"id"属性、"name"属性、及び"type"属性を持つことを表現している。仕様書３００は、このスキーマ定義４００で規定する構造通りに記述する必要がある。

次に、図５および図６は、図３および図４と同様に、XMLで表現した仕様書５００およびその仕様書構造を規定するスキーマ定義６００の例を示している。図５に例示する仕様書５００は、ルート項目が"Flow"と規定されているように（符号５０１）、データ処理の流れを複数の機能を含む処理フローとして表現するための仕様書であり、対応ソフトウェア機能を一覧形式で表現する図３の仕様書３００と依存関係を持つ仕様書として位置付けられている。仕様書３００と仕様書５００との間にどのような依存関係が存在するかについては後述する。図５の仕様書５００は、符号５０１，５０２で指示する破線で囲んで示すように、"Flow"項目に含まれる各プロセス（Process（図３のFunctionに対応））に対して"id"，"name"，"type"の各属性を有する"Data"が割当てられることを、フロー形式で表現するプログラムである。これを、"Flow"という"schema name"（符号６０１）で対応付けられるスキーマ定義６００と対応させて説明すると、仕様書５００では、まず"Root"項目が"Flow"項目を子要素（element）として持ち（符号６０２）、"Flow"項目がさらにProcess項目を子要素として備え（符号６０３）、"Process"項目が"Data"項目、"id"属性、"name"属性、及び"type"属性を持つことを表現している。仕様書５００では、ルート項目（Root schema）で仕様書の構造を規定するスキーマ定義のファイル参照パスが、"Root/Flow"と指定される。そして、"id"属性、"name"属性、及び"type"属性の各仕様項目を指定するデータパスが、"Root/Flow/Process"と規定される。

次に、本実施形態の検証装置１００に設けられている各ＤＢについて説明する。まず、マッチングルールＤＢ１０４について説明する。図７は、図３および図５に示した仕様書３００、５００間の依存関係の抽出方法を記述したマッチングルール７００を格納しているマッチングルールＤＢ１０４の構成例を示す図である。マッチングルールＤＢ１０４に格納されているマッチングルール７００は、２つのスキーマ定義４００，６００を対象とした依存関係抽出方法を記述している。図７に例示するマッチングルール７００では、図４に示したスキーマ定義４００に関する記述７０１、７０２と、図６に示したスキーマ定義６００に関する記述７０３、７０４をそれぞれ記述している。各スキーマ定義４００，６００に関する記述では、依存関係抽出の対象となる仕様項目を、各仕様内での相対位置で指定するための項目のパス７０１、７０３と、依存関係有無を判定するための情報としてのマッチング要素７０２、７０４を記述している。また、マッチング方法について、仕様項目の比較手段７０５および組合せ７０６を記述している。図７では、マッチング要素７０２，７０４として、仕様書３００，５００のスキーマ定義４００，６００から、"id"，"name"，"type"の３つが抽出されている。比較手段７０５には、例えば「完全一致」、「部分一致」、「特定変換による一致」等の各マッチング要素７０２，７０４が持つ値の間で成立する条件を記述する。組合せ７０６は、複数行に渡って記述したマッチングルール７００の同時または排他成立条件を、例えば「and」あるいは「or」の形で記述する。抽出する依存関係種類７０７については、マッチング方法７０５，７０６で比較して依存関係があると判定された場合に、抽出できる依存関係の種類名を記述する。図７の例では、２つの項目７０２と７０４が全く同一のものであるという関係として"一致関係"を定義している。他にも例えば、機能とデータとの間の関係であれば、排他ロック/共有ロック関係や、ＣＲＵＤ（Create, Read, Update, Delete）関係などさまざまな依存関係の種類が考えられる。なお、ここで用いる依存関係の種類は後述の依存関係検証処理で用いられる。具体的には、図７のマッチングルール７００の例では、図３に示した仕様書３００のRoot項目以下のFunction項目の属性値と、図５で示した仕様書５００のRoot項目以下のFlow項目以下にあるProcess項目の属性値とが、id属性、name属性、およびtype属性と、それぞれ完全一致する場合に、２項目間に「一致関係」という名の依存関係があると判定するルールを定義している。

次に、依存関係情報ＤＢ１０７について説明する。図８は、図７のマッチングルール７００を用いて抽出した図３の仕様書３００の各仕様項目８０１と、図５の仕様書５００の各仕様項目８０２との間の依存関係を対応付けて格納している依存関係情報ＤＢ１０７の構成例を示す図である。仕様書３００，４００に含まれている仕様項目１つ毎に探索し、マッチングルールＤＢ１０４に規定されるマッチングルール７００にマッチするとして抽出されたすべての仕様項目間の依存関係が、依存関係種類８０３と対応付けられて依存関係情報ＤＢ１０７に格納される。図８の例では、仕様"Flow"について記録されている仕様項目である"Start-End"が、仕様"Functions"については記録されていない。このように一方の仕様に存在する仕様項目に対応する仕様項目が他方の仕様に存在しないと判定された場合には、仕様項目の不整合が疑われることを示す情報としての依存関係候補情報として後述の依存関係検証部で１０９で抽出し、検証関係可視化部１１０を通じてユーザに提示することができる。

次に、検証ルールＤＢ１０８について説明する。図９Ａは、依存関係の種類の間で同時成立すべき条件を列挙した検証ルール９００を格納する検証ルールＤＢ１０８の構成例を示す図である。検証ルール９００は、仕様間の不整合を検出するために規定されているルールであり、図９ＡではＲ１，Ｒ２，…といった記号で識別されている。検証ルール９００を満たさない依存関係があると判定された場合、依存関係間で矛盾があると判定しそれを不整合として検出する。まず、検証に必要な入力項目の数９０１とその入力項目に対する事前条件９０２を記述する。事前条件９０２は、検証可能な仕様書の絞り込みに用いる。つまりその事前条件を満たす仕様書のみを検証可能な仕様書とみなして、検証ルール９０３のチェックを実施する。検証を実施した場合、事前条件９０２を満たし、かつ検証ルール９０３を満たすものは整合と判定し、事前条件９０２を満たし、かつ検証ルール９０３を満たさないものを不整合と判定する。

具体的には、図９の検証ルールＤＢ１０８では、１つめのルールＲ１として、４つの仕様項目を入力した時に、項目１と項目２、項目３と項目４の間にそれぞれ"一致関係"があり、項目１と項目３の間に"排他（ロック）関係"がある場合、項目１、項目３とそれぞれ"一致関係"にある項目２と項目４の間にも"排他（ロック）関係"があるべきであると規定している。これは、一方で排他関係と定義しているのに、一致関係にある別の項目の方で排他関係でない（例えば共有関係である）と定義するような、依存関係が矛盾する定義を検出するためのルールである。入力項目数に制限はなく、検証ルール記述に必要な数の入力項目数９０１を定義することになる。入力項目数を指定するとその数分だけ事前条件９０２および検証ルール９０３の部分で"項目＋番号"という形で定義に活用できる。実際に検証する際には、指定数の仕様項目を準備して"項目＋番号"の部分に入力して検証実施することになる。なお、図９Ａの検証ルールＤＢ１０８で、事前条件９０２と検証ルール９０３で利用している"関係（項目１,項目２）"という記述は、図８に示した抽出済み依存関係情報８００を探索して該当行を検出し、そこで定義されている依存関係種類８０３の値を返す機能を備えている。各検証ルール９００は、対応する仕様に含まれる各仕様項目間に成立すべき関係としてあらかじめ設定しておく。図９Ｂには、図９Ａに例示する検証ルール９００の意味を模式的に示している。図９Ｂは、同一の基本機能仕様をリスト形式と図表形式で対応して表現するようにした場合、対応する項目１と項目３との間に排他関係が設定されていたとき、それぞれの構成をブレイクダウンして得られる詳細機能仕様においても、対応する項目２と項目４との間には排他関係が設定されていなければならないというルール（図９ＡのルールＲ１に相当）を例示している。

次に、本実施形態の検証装置１００における各処理部でのデータ処理について具体的に説明する。まず、仕様構造解析部１０３における仕様構造解析処理について説明する。図１０は、仕様構造解析部１０３における仕様構造解析処理フロー例を示すフローチャートである。仕様構造解析処理は、解析対象となる仕様ファイルを構造化されたデータとしてメモリ上に読み込む処理を実行する。検証装置１００の全体処理フローが、検証装置１００の電源投入等を契機として起動しているとの前提で、まず、仕様構造解析部１０３は、Ｓ１００１で処理を開始した後、仕様とその仕様の構造を規定するスキーマ定義とを、補助記憶装置２０５に格納されている仕様ＤＢ１０１、スキーマ定義ＤＢ１０２からそれぞれ取得する（Ｓ１００２）。本実施形態で取得される仕様およびスキーマ定義は、例えば仕様書３００，５００、およびスキーマ定義４００，６００が該当する。次に、仕様構造解析部１０３は、取得した仕様内にスキーマ定義に違反する記述がないことを、スキーマバリデーションによって確認する（Ｓ１００３）。スキーマバリデーションは例えば、仕様がXMLでスキーマ定義がXML Schemaである場合、一般的なXMLバリデーション技術により実施できるため、ここでは詳述を省略する。次いで、仕様構造解析部１０３は、Ｓ１００３での確認の結果、スキーマ定義に違反する項目があるか判定し（Ｓ１００４）、スキーマ定義に違反する項目があると判定した場合（Ｓ１００４，Ｙｅｓ）、正しく仕様の読み込みができないため、全体処理フローを終了して例外を発行する（Ｓ１００７）。スキーマ定義に違反する項目がないと判定した場合（Ｓ１００４，Ｎｏ）、仕様をスキーマ構造通りにメモリ上に読み込み（Ｓ１００５）、仕様構造解析フローの実行を終了する（Ｓ１００６）。この仕様構造解析処理により、仕様間依存関係検証の対象となる仕様が構造化データとして検証装置１００に読み込まれる。

次に、仕様項目マッチング処理について説明する。図１１は、仕様項目マッチング部１０５における仕様項目マッチング処理の処理フロー例を示すフローチャートである。仕様項目マッチング処理は、仕様構造解析処理で抽出済みの仕様に含まれる仕様項目間で依存関係があるかどうかを判定し、依存関係がある場合にそれを依存関係情報として抽出する処理を実行する。まず、仕様項目マッチング部１０５は、Ｓ１１０１で処理開始後、仕様構造解析部１０３より解析済み仕様データを取得し、仕様項目間の依存関係成立条件を記述したマッチングルール７００をマッチングルールＤＢ１０４より取得し読み込む（Ｓ１１０２）。次いで、仕様項目マッチング部１０５は、マッチングルールＤＢ１０４に格納されている全マッチングルール７００に対してそのルールを満たす依存関係抽出をループ処理する（Ｓ１１０３〜Ｓ１１１２）。各ループ処理において、仕様項目マッチング部１０５は、１つのマッチングルール７００内に記載される１つめの仕様（本実施形態では図３の仕様書３００）について、項目のパスで指定した仕様項目集合をすべて仕様データから抽出する（Ｓ１１０４）。また、仕様項目マッチング部１０５は、２つ目の仕様（本実施形態では図５の仕様書５００）についても同様に項目のパスで指定した仕様項目集合をすべて仕様データから抽出する（Ｓ１１０５）。次いで、仕様項目マッチング部１０５は、１つめの仕様で抽出したすべての仕様項目に対してループ処理を実施し（Ｓ１１０６〜Ｓ１１１１）、同様に２つめの仕様で抽出したすべての仕様項目に対してもループ処理を実施する（Ｓ１１０７〜Ｓ１１１０）。仕様項目マッチング部１０５は、各ループ処理において、２つの仕様項目の各マッチング要素７０２，７０４（例えば仕様項目内の属性）がマッチング方法７０５，７０６に記載する条件を満たすかどうか判定する（Ｓ１１０８）。マッチング条件を満たし、依存関係があると判定した場合（Ｓ１１０８，Ｙｅｓ）、仕様項目マッチング部１０５は、２項目間の依存関係情報として、２項目のパス情報と依存関係の種類を依存関係情報ＤＢ１０７に設定する（Ｓ１１０９）。マッチング条件を満たさないと判定した場合（Ｓ１１０８，Ｎｏ）、仕様項目マッチング部１０５は、依存関係なしのため次のループ処理を実施する（Ｓ１１０６，Ｓ１１０７）。そこで全マッチングルール７００に関して処理が終わってすべての依存関係情報を取得した時点で（Ｓ１１１２）、仕様項目マッチング処理フローを終了する（Ｓ１１１３）。

次に、依存関係情報生成処理について説明する。図１２は、依存関係情報生成部１０６における依存関係情報生成処理１２００の処理フロー例を示すフローチャートである。依存関係情報生成処理は、仕様項目マッチング処理１１００によって抽出した依存関係情報を整形し、依存関係情報ＤＢ１０７に格納する処理である。依存関係情報生成部１０６は、まずＳ１２０１で処理開始後、抽出済みの依存関係情報を取得し（Ｓ１２０２）、依存関係が１つもない仕様項目については依存関係なしと設定する（Ｓ１２０３）。そして、依存関係情報生成部１０６は、依存関係情報を図８に例示する依存関係情報ＤＢ１０７の記録形式に整形して依存関係情報ＤＢ１０７に格納し（Ｓ１２０４）、依存関係情報生成処理フローを終了する（Ｓ１２０５）。

次に、依存関係検証処理について説明する。図１３は、依存関係検証部１０９における依存関係検証処理の処理フロー例１３００を示すフローチャートである。依存関係検証処理では、依存関係情報と仕様間で成立すべき整合条件をルール化してあらかじめ定義されている検証ルール９００を用いて依存関係情報間で検証ルール９００に違反する依存関係がないか検証し、違反があると判定した場合には、それを仕様間の不整合として抽出し、出力する。依存関係検証部１０９は、まずＳ１３０１で処理開始後、依存関係情報ＤＢ１０７から依存関係情報を取得し、検証ルールＤＢ１０８から検証ルール９００を取得する（Ｓ１３０２）。次いで、依存関係検証部１０９は、取得した検証ルール９００毎にループ処理を実施する（Ｓ１３０３〜Ｓ１３０９）。この検証ルール９００毎のループ処理内では、１つの検証ルール９００に対して、必要入力項目数分の仕様項目の組合せをすべて作成し、全組合せ分ループ処理を実施する（Ｓ１３０４〜Ｓ１３０８）。仕様項目組合せのループ処理内で、依存関係検証部１０９は、入力項目が検証ルール９００の事前条件を満たすかどうか（図９ＡのルールＲ１の例では、所定の一致関係、排他関係が成立しているか否か）判定する（Ｓ１３０５）。入力項目が事前条件９０２を満たさないと判定した場合（Ｓ１３０５，Ｎｏ）、検証ルール９００を適用できないため次の検証ルール９００について同様の判定処理を実施する（Ｓ１３０４）。入力項目が検証ルール９００の事前条件９０２を満たすと判定した場合（Ｓ１３０５，Ｙｅｓ）、依存関係検証部１０９は、入力項目に対して検証ルール９０３が成立するかどうか検証する（Ｓ１３０６）。検証の結果、検証ルール９０３が成立すると判定した場合には不整合なし、検証の結果、検証ルール９０３が不成立と判定した場合には不整合ありとして、検証結果を依存関係情報と合わせて生成する（Ｓ１３０７）。仕様項目組合せのループ処理が終わったと判定した場合（Ｓ１３０８）、依存関係検証部１０９は、次の検証ルール９００に対して再び仕様項目組合せのループ処理を実施する（Ｓ１３０４）。依存関係検証部１０９は、検証ルールＤＢ１０８に格納されているすべての検証ルール９００に対するループ処理を終了した時点で（Ｓ１３０９）、依存関係検証処理フロー１３００の実行を終了する（Ｓ１３１０）。以上の依存関係検証処理により、対応する仕様間で所定の依存関係が成立しているかを検証することができる。なお、異なる検証ルール９００において同一の事前条件９０２が設定されている場合、当該事前条件９０２について繰り返し判定処理を実行する必要はない。その観点から、特定の事前条件９０２に対する判定結果をメモリ２０４等に保持しておき、同一の事前条件９０２について既存の判定結果があればそれを利用するように構成することができる。

次に、検証結果可視化処理について説明する。図１４は、検証結果可視化部１１０における検証結果可視化処理の処理フロー例１４００を示すフローチャートである。検証結果可視化処理では、抽出した依存関係を表示した上に、検証ルール９００を満たさない不整合部分を強調表示して、仕様間のどの部分に不整合が発生しているのかをユーザーにわかりやすく表示する。検証結果可視化部１１０は、まずＳ１４０１で処理開始後、依存関係情報ＤＢ１０７に格納されているすべての依存関係情報およびすべての依存関係検証結果を取得する（Ｓ１４０２）。検証結果可視化部１１０は、取得した依存関係情報８００を用いて、まず全ての仕様項目とその間の依存関係情報を表示し（Ｓ１４０３）、その表示の該当する依存関係部分の上に、検証結果を重ねて表示し（Ｓ１４０４）、検証結果可視化処理フローの実行を終了する（Ｓ１４０５）。この検証結果可視化処理により、仕様間に生じている不整合があれば、直ちに視覚的に把握することが可能である。

図１４に例示した検証結果可視化処理結果の一例を、図１５に示している。図１５は、本実施形態の検証装置１００において採用したユーザインタフェースによって検証結果可視化を行った例を示す画面１５００のサンプルである。検証結果可視化画面１５００では、依存関係情報ＤＢ１０７に格納された全ての依存関係を表示装置２０２上に表示した上で、検証結果を該当部分に重ねて表示するようにしている。図１５の例で言えば、仕様項目１（１５０１）や仕様項目３（１５０２）のように画面上の任意の位置に仕様項目を配置し、依存関係情報ＤＢ１０７を参照して依存関係のある仕様項目間を線で接続する（１５０３）。これにより、図１５に例示するネットワーク形式の依存関係図が生成される。さらにこの依存関係図上に、検証ルール９００を適用して得られた検証結果を参照して、不整合と判定されている部分を強調表示し（１５０４）、ユーザーに全体のうちどの部分に不整合があるか一目でわかるようにしている。

なお、全ての依存関係情報を画面上に一度に表示すると表示量が多くなりすぎて煩雑となる場合には、図１４に例示した処理フローに代えて、最初はユーザーが選択した最小限の依存関係のみを表示しておき、その依存関係に直接的または間接的に関係する依存関係、つまり同じ仕様項目を共有している依存関係のみに絞って芋づる式に抽出して表示することもできる。これにより依存関係検証の対象としたい部分と関係のない依存関係の表示を省略し、画面表示の煩雑さを避けることができる。

図１６は、上記した依存関係の一部を芋づる式に抽出して表示する、検証結果可視化の例を示す画面サンプルである。検証結果可視化画面１６００は、図１５による全依存関係の表示では、表示項目数や依存関係線の数が多く複雑に入り組んで確認するのが難しい場合に、必要最小限の依存関係情報のみを可視化するのに利用することができる。図１６に例示する検証結果可視化画面１６００は、項目選択ウィンドウ１６０１と芋づる依存関係表示ウィンドウ１６０２とを備えて構成される。項目選択ウィンドウ１６０１には、依存関係情報ＤＢ１０７に含まれている全ての仕様項目が一覧形式で表示され、検証装置１００のユーザーが画面上でオブジェクトをクリックする等によりいずれかの仕様項目を選択可能に構成されている（１６０３）。ユーザーがいずれかの仕様項目を選択すると、その選択した仕様項目を始点として（１６０４）、始点とされた仕様項目に依存関係によって関連付けられている仕様項目が芋づる式に抽出されるように構成されている。このように抽出された依存関係は、芋づる依存関係表示ウィンドウ１６０２内にツリー構造で表示される。これにより、ユーザーが検証結果を確認したいと考える範囲の依存関係のみを取り出して表示し、かつツリー構造で依存関係線が入り組むことがないため、ユーザーはより短時間で所望の仕様項目に関する依存関係をチェックすることができる。なお、芋づる式に抽出された依存関係の上でどこに不整合が存在するかを系統的に示すため、例えば始点である仕様項目から不整合の箇所の仕様項目に至る経路に存在する仕様項目を強調表示するといった構成により、ユーザーにとって検証結果をよりわかりやすく提示することもできる。

以上説明したように、本実施形態の仕様間依存関係検証装置１００によれば、対応する仕様書３００、５００に含まれる各仕様項目間の依存関係が過不足なく存在しているか容易に確認することができる。また、対応する仕様項目間に存在する依存関係の間で発生する不整合をも容易に発見することができる。

なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば，上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施形態の構成の一部を他の構成に置き換えることが可能であり、また、ある実施形態の構成に他の構成を加えることも可能である。

１００…仕様間依存関係検証装置 １０１…仕様ＤＢ
１０２…スキーマ定義ＤＢ １０３…仕様構造解析部
１０４…マッチングルールＤＢ １０５ …仕様項目マッチング部
１０６…依存関係情報生成部 １０７ …依存関係情報ＤＢ
１０８ …検証ルールＤＢ １０９…依存関係検証部
１１０ …検証結果可視化部 ２０１…プロセッサ ２０２…表示装置
２０３…入力装置 ２０４…メモリ ２０５…補助記憶装置

Claims (9)

1. 階層構造を有するソフトウェア仕様に含まれているデータ項目である仕様項目の整合性を検証するための検証装置であって、
   少なくとも一組の互いに対応するソフトウェア仕様を取得し、あらかじめ前記階層構造に従って前記ソフトウェア仕様中での相対位置が設定されている前記各仕様項目を抽出するように構成されている仕様構造解析部と、
   前記対応するソフトウェア仕様に含まれる前記仕様項目間で成立すべき対応関係である依存関係を記述してなるマッチングルールを格納しているマッチングルール格納部と、
   前記マッチングルールを用いて、前記各仕様項目間の依存関係の有無を判別するように構成されている仕様項目マッチング部と、
   前記仕様項目マッチング部で依存関係があると判定された前記仕様項目の組合せを指定する情報を依存関係情報として抽出するように構成されている依存関係情報生成部と、
   前記ソフトウェア仕様間で特定の前記仕様項目の組合せについて成立すべき整合条件をルール化して定義してなる検証ルールを格納している検証ルール格納部と、
   特定の前記仕様項目の組合せについて、前記抽出された依存関係情報に基づき、前記検証ルール格納部に格納されている前記検証ルールに規定されている前記整合条件を満たさない依存関係があるかを判定し、満たさない依存関係があると判定した場合、当該整合条件を満たさない依存関係を前記ソフトウェア仕様間の不整合を示す不整合情報として出力するように構成されている依存関係検証部と、
   前記依存関係検証部からの前記不整合情報を所定のユーザインタフェースによって出力するように構成されている検証結果出力部と、
   を有し、
   前記マッチングルールには、当該マッチングルール毎に、当該マッチングルールが規定している依存関係の種類を示す情報である依存関係種類情報が含まれており、前記検証ルールには、複数の前記依存関係種類間で満たすべき論理条件が含まれており、前記依存関係情報生成部は、前記依存関係情報抽出時に、依存関係情報として仕様項目間の依存関係の有無とともに、当該依存関係の種類をも抽出し、前記依存関係検証部は、抽出した複数の前記依存関係種類間で満たすべき前記論理条件に基づいて、前記仕様項目間の依存関係種類の間の不整合を検出する、ソフトウェア仕様間整合性検証装置。
2. 前記依存関係情報生成部は、前記マッチングルールに従って前記ソフトウェア仕様間の依存関係情報を抽出する際、一方の前記ソフトウェア仕様に当該マッチングルールを満たす仕様項目があり、他方の前記ソフトウェア仕様に当該マッチングルールを満たす仕様項目がないと判定した場合に、当該マッチングルールを満たす仕様項目を依存関係候補情報として抽出し、前記依存関係検証部は、各前記仕様項目の組合せにおける一致関係及び排他関係を記述した前記検証ルールを用いて、不整合の候補を検出する、請求項１に記載のソフトウェア仕様間整合性検証装置。
3. 前記検証結果出力部は、抽出した前記依存関係情報を、依存関係を有する仕様項目間の関連が可視化される形態で表示し、表示した当該仕様項目間の関連に検出した不整合情報を重ねて表示する、請求項１に記載のソフトウェア仕様間整合性検証装置。
4. 前記検証結果出力部は、抽出した依存関係情報を表示する際、検証対象である前記仕様に含まれる前記仕様項目を選択可能に表示する画面を表示し、選択された当該仕様項目を始点として、抽出済みの複数の前記依存関係情報を解析し、始点となっている前記仕様項目に直接的にまたは間接的に依存関係を有する仕様項目をすべて抽出して表示する、請求項３に記載のソフトウェア仕様間整合性検証装置。
5. 前記検証結果出力部は、選択された前記仕様項目に関連して表示された依存関係上に検出された前記不整合情報を重ねて表示する際、前記始点となっている仕様項目から不整合と判定された依存関係の部分までを接続している仕様項目を識別できるように表示する、請求項４に記載のソフトウェア仕様間整合性検証装置。
6. 前記仕様項目マッチング部は、前記仕様項目に付与されている属性を示す属性値に対して、当該属性値の一致をもって依存関係成立条件とした前記マッチングルールを用いて前記依存関係情報を抽出する、請求項１に記載のソフトウェア仕様間整合性検証装置。
7. 前記検証ルールには、当該検証ルールに基づいて整合性を判定すべき仕様項目の数を示す入力項目数が設定されており、前記依存関係検証部は、前記依存関係情報を用いて前記仕様項目間の不整合を検出する際、前記検証ルールに設定されている前記入力項目数だけの仕様項目を仕様から抽出し、当該すべての仕様項目の組合せに対して前記検証ルールを用いて不整合を検証する、請求項１に記載のソフトウェア仕様間整合性検証装置。
8. 前記検証ルール毎に、前記入力項目数だけ抽出した前記仕様項目のうちで一部の仕様項目間で成り立つ依存関係の条件を規定している事前条件が設定されており、前記依存関係検証部は、前記検証ルールに設定されている前記入力項目数だけの仕様項目を仕様から抽出する際、前記事前条件に関する検証がすでに適用済みの他の検証ルールで実施されていると判定した場合、その実施の際に前記事前条件を満たすと判定された仕様項目組合せを再利用し、前記仕様項目が前記事前条件を満たすかどうかを判定することなく検証を実行する、請求項７に記載のソフトウェア仕様間整合性検証装置。
9. 階層構造を有するソフトウェア仕様に含まれているデータ項目である仕様項目の整合性を検証するための検証方法であって、データを格納するメモリと当該データを用いて演算処理を実行するプロセッサとを有するコンピュータにより、少なくとも一組の互いに対応するソフトウェア仕様を取得し、あらかじめ前記階層構造に従って前記ソフトウェア仕様中での相対位置が設定されている前記各仕様項目を抽出し、
   前記対応するソフトウェア仕様に含まれる前記仕様項目間で成立すべき対応関係である依存関係を記述してなり、それぞれに、それぞれが規定している依存関係の種類を示す情報である依存関係種類情報が含まれているマッチングルールを格納し、
   前記マッチングルールを用いて、前記各仕様項目間の依存関係の有無を判別し、
   前記各仕様項目間の依存関係の有無の判別により依存関係があると判定された前記仕様項目の組合せを指定する情報を依存関係情報として抽出し、
   前記ソフトウェア仕様間で特定の前記仕様項目の組合せについて成立すべき整合条件をルール化して定義してなり、複数の前記依存関係種類間で満たすべき論理条件が含まれている検証ルールを格納し、
   特定の前記仕様項目の組合せについて、前記抽出された依存関係情報に基づき、前記格納した前記検証ルールに規定されている前記整合条件を満たさない依存関係があるかを判定し、満たさない依存関係があると判定した場合、当該整合条件を満たさない依存関係を前記ソフトウェア仕様間の不整合を示す不整合情報として出力し、
   前記ソフトウェア仕様間の不整合を示す不整合情報を所定のユーザインタフェースによって出力し、
   前記コンピュータは、
   前記依存関係情報の抽出時に、依存関係情報として仕様項目間の依存関係の有無とともに、当該依存関係の種類をも抽出し、
   前記抽出した複数の前記依存関係種類間で満たすべき前記論理条件に基づいて、前記仕様項目間の依存関係種類の間の不整合を検出する、ソフトウェア仕様間整合性検証方法。

Images