JP5605397B2

JP5605397B2 - 結合検査要否判定方法及び装置

Info

Publication number: JP5605397B2
Application number: JP2012155749A
Authority: JP
Inventors: 洋桑島
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2012-07-11
Filing date: 2012-07-11
Publication date: 2014-10-15
Anticipated expiration: 2032-07-11
Also published as: US8959487B2; US20140019938A1; JP2014016950A; DE102013213593A1

Description

本発明は、ソフトウェア部品の結合検査の要否を判定する要否判定方法及び装置に関する。

近年、特定の機能を実現するために機械や装置に組み込まれるコンピュータシステムである組み込みシステムでは、ユーザの多様な要求に応えるために、一つの製品系列に多くのバリエーションが用意されている。

このような組み込みシステムのソフトウェア開発では、多品種製品向けに技術要素を体系化した開発方法論の一つであるソフトウェアプロダクトライン（ＳＰＬ）が注目されている。

ＳＰＬでは、製品分析によって得られる情報であり、細分化された個々の仕様（フィーチャともいう）間の関係を定義したフィーチャモデルに従って要求仕様を特定し、その特定された要求仕様に従って、予め用意されたコア資産（再利用可能なソフトウェア部品）を適宜組合せることによって、個別のプロダクト（アプリケーションソフトウェア）が生産される（例えば、特許文献１，非特許文献１参照）。

特開２０１２−８６６０号公報

吉村，菊野著「組み込みシステムにおけるソフトウェアプロダクトラインの導入」情報処理Ｖol.50 No.4 Apr.2009 P295-P302

ところで、ＳＰＬでは、コア資産として提供されるソフトウェア部品は、単体ではもちろん、他のソフトウェア部品と組合せて使用した場合でも、仕様通りに動作することを保証する必要がある。そのためには、ソフトウェア部品同士の結合検査を事前に行っておくが必要となる。

ここで、ｎ種類のソフトウェア部品の任意の二つの組合せの全てについて結合検査を実施することを考えると、_nＣ₂通りの組合せが存在する。実際には、ソフトウェア部品を三つ以上組合せた場合についても検査する必要がある。

つまり、コア資産として用意するソフトウェア部品の数が増加するほど、結合検査に要する手間が著しく増大してしまうという問題があった。このため、現実的には、同時に選択されることがあり得ないソフトウェア部品の組合せについては、結合検査を省略する等の対策が必要となるが、膨大な数のソフトウェア部品の組合せについて、その都度、作業者がいちいち結合検査の要否を調べていたのでは、手間を削減するどころか、却って手間を増大させてしまうという問題があった。

本発明は、上記問題点を解決するために、ソフトウェアプロダクトラインにおいてコア資産として提供されるソフトウェア部品の結合検査に要する手間を削減することを目的とする。

本発明の結合検査要否判定方法において、第１のステップでは、ソフトウェアプロダクトラインによって製造されるプロダクト群の特徴を表現したフィーチャモデルを構成する各フィーチャとソフトウェア部品の種類及びバリエーションとの対応関係を表す対応情報を取得する。

第２のステップでは、ソフトウェア部品の種類をｉ（ｉ＝１，２，…Ｍ：Ｍはソフトウェア部品の種類の総数），バリエーションをｊ（ｊ＝１，２，…Ｎ_i：Ｎ_iは種類ｉで特定されるソフトウェア部品のバリエーションの総数）、ｉ，ｊによって特定される一つのソフトウェア部品をＳ_ijで表すものとして、フィーチャ毎に用意され、該フィーチャが選択された場合に真、選択されなかった場合に偽となる状態変数を使用し、第１のステップで取得した対応情報に従って、ソフトウェア部品Ｓ_ij毎に、該ソフトウェア部品Ｓ_ijに対応付けられた全てのフィーチャの状態変数の集合Ｃ_ijを生成する。

第３のステップでは、ｉによって特定されるソフトウェア部品のＮｉ個のバリエーションからなるソフトウェア部品群をＳ_ix、Ｓ_ixのうちｊによって特定されるバリエーション以外のＮ_i−１個のバリエーションをｔ（ｔ≠ｊ）で表し、Ｃ_ijの全要素を論理積で結合することで得られる論理式をＨ（Ｃ_ij）、Ｈ（Ｃ_ij）を論理否定することで得られる論理式をＮＨ（Ｃ_ij）で表すものとして、ソフトウェア部品Ｓ_ij毎に、Ｈ（Ｃ_ij）及びＮ_i−１個のＮＨ（Ｃ_it）を論理積で結合した論理式からなる個別判定式ＩＳ（Ｃ_ij）を生成する。

なお、Ｈ（Ｃ_ij）は、Ｓ_ix（ｉで特定される同一種類のソフトウェア部品）の中で、ｊで特定されるバリエーションのソフトウェア部品が選択される条件を表したものであり、また、ＮＨ（Ｃ_ix）は、Ｓ_ixの中で、ｔで特定されるバリエーションのソフトウェア部品（即ち、ｊで特定されるバリエーション以外のソフトウェア部品）が選択されない条件を表したものである。つまり、これらを論理積で結合したＩＳ（Ｃ_ij）は、同一種類のソフトウェア部品（Ｓ_ix）において、複数のバリエーションが同時に選択されることがない、即ち、一つのバリエーションしか選択されることがないという条件を、Ｈ（Ｃ_ij）が示す条件に加味したものとなる。

第４のステップでは、結合検査の要否を判定する対象となる二つ以上のソフトウェア部品を指定する。
第５のステップでは、第４のステップにて指定された全てのソフトウェア部品について個別判定式生成手段にて生成された個別判定式を論理積で結合することで要否判定式を生成し、その要否判定式が常に偽となる場合（恒偽式）は検査不要、その要否判定式が真偽不明または常に真となる場合（恒真式）は検査必要と判定する。

このような本発明の結合検査要否判定方法によれば、ソフトウェア部品Ｓ_ij毎に用意される個別判定式ＩＳ（Ｃ_ij）を用いることで、ソフトウェア部品の任意の組合せについての結合検査の要否を、フィーチャモデル等を参照することなく簡単に判定することができる。

また、本発明の結合検査要否判定装置では、対応情報取得手段が第１のステップに相当する処理を実行し、状態集合生成手段が第２のステップに相当する処理を実行し、個別判定式生成手段が第３のステップに相当する処理を実行し、対象選択手段が、第４のステップに相当する処理を実行し、検査要否判定手段が、第５のステップに相当する処理を実行し、判定結果出力手段が、検査要否判定手段での判定結果を出力する。

従って、本発明の結合検査要否判定装置によれば、上述した結合検査要否判定方法を実行することによって得られる効果と同様の効果を得ることができる。

結合検査要否判定装置の全体構成を示すブロック図である。（ａ）がフィーチャモデルの構造を示す説明図、（ｂ）が対応情報の内容を説明する説明図である。個別判定式生成処理の内容を示すフローチャートである。結合検査要否判定処理の内容を示すフローチャートである。判定結果データベースの構造を示す説明図である。検索用データベースの構造を示す説明図である。

以下に本発明の実施形態を図面と共に説明する。
＜全体構成＞
本実施形態に係る結合検査要否判定装置１は、図１に示すように、各種指令を入力するための操作部２と、操作手順や処理結果等を表示するための出力部３と、ソフトウェアプロダクトライン（ＳＰＬ）で使用する各種情報を記憶する記憶部４と、操作部２から入力される指令に従って、記憶部４に記憶された各種情報を用いた処理を実行し、処理結果を出力部３に出力したり記憶部４に格納したりする制御部５とを備えている。

記憶部４は、ＳＰＬを適用する製品群の分析（いわゆるドメインエンジニアリング）によって作成されたフィーチャモデルや再利用可能なソフトウェアであるソフトウェア部品の他、フィーチャモデルに示された個別のフィーチャとソフトウェア部品との対応関係を示す対応情報を記憶するコア資産データベース（以下、データベースをＤＢと表記する）４１、後述する処理によってソフトウェア部品毎に生成される個別判定式を記憶する個別判定式ＤＢ４２、結合検査の検査対象となるソフトウェア部品の組合せパタンと、その組合せパタンについての結合検査の要否を判定した要否判定結果とを対応付けて記憶する判定結果ＤＢ４３、判定結果ＤＢ４３の検索に使用する情報を記憶する検索用ＤＢ４４を備えている。

＜フィーチャモデル／ソフトウェア部品＞
ここでフィーチャモデルとは、図２（ａ）に示すように、製品分析によって抽出された個々の仕様（機能や品質等）をフィーチャとして、各フィーチャの関係（従属関係、選択肢等）を体系的に表したものである。

対応情報は、フィーチャによって特定される機能を実現するために使用される特定のソフトウェア部品、特定のバリエーションとの対応関係を示すものであり、図２（ｂ）に示すように、各フィーチャには、一つ以上のソフトウェア部品が対応付けられる。また、ソフトウェア部品は、複数種類のものが用意され、種類によっては、複数のバリエーションを持つものも存在する。

以下では、ソフトウェア部品の種類をｉ（ｉ＝１，２，…Ｍ：Ｍはソフトウェア部品の種類の総数），バリエーションをｊ（ｊ＝１，２，…Ｎ_i：Ｎ_iは種類ｉで特定されるソフトウェア部品のバリエーションの総数）、ｉ，ｊによって特定される一つのソフトウェア部品をＳ_ijで表し、また、種類ｉで特定されるソフトウェア部品のＮ_i個のバリエーションを総称する場合にＳ_ix（ｘ＝１，２，…Ｎ_i）で表すものとする。

また、同じソフトウェア部品群に属するソフトウェア部品同士、即ち、種類が同じでバリエーションが異なるソフトウェア部品同士は、互いに排反の関係にあり、ＳＰＬによって製造される一つのプロダクト（アプリケーションソフトウェア）において、同じ種類のソフトウェア部品からはいずれか一つのバリエーションのみが使用される。

具体的には、例えば、車両制御のアプリケーションソフトウェアを製造するＳＰＬにおいて、「ワイパーモータ制御」という種類のソフトウェア部品が存在し、そのバリエーションとして「右ハンドル用」「左ハンドル用」が存在する場合、「右ハンドル用ワイパーモータ制御」というソフトウェア部品と「左ハンドル用ワイパーモータ制御」というソフトウェア部品とが同時に使用されることはあり得ないことを意味する。

そして、ＳＰＬでは、フィーチャモデルに従って、フィーチャを適宜選択することによって要求仕様を特定し、その特定された要求仕様に従ったプロダクト（アプリケーションソフトウェア）を生成するものであり、そのプロダクトは、選択された個々のフィーチャに対応付けられたソフトウェア部品（対応情報を用いて特定される）によって構成される。

＜制御部＞
制御部は、ＣＰＵ，ＲＯＭ，ＲＡＭを少なくとも備えた周知のマイクロコンピュータからなり、個別判定式を生成して判定式ＤＢ４２を生成する個別判定式生成処理、及び個別判定式ＤＢ４２に記憶された個別判定式を使用して、指定されたソフトウェア部品間の結合検査の要否を判定する結合検査要否判定処理を少なくとも実行する。

これらの処理は、いずれも操作部から入力される指示に従って起動する。
<<個別判定式生成処理>>
ここで個別判定式生成処理の内容を、図３に示すフローチャートに沿って説明する。以下ではステップを単に「Ｓ」と示す。

本処理が起動すると、まず、Ｓ１１０では、コア資産ＤＢ４１から対応情報を取得する。
Ｓ１２０では、Ｓ１１０にて取得した対応情報に基づいて、ソフトウェア部品Ｓ_ij毎に、該ソフトウェア部品Ｓ_ijに対応付けられた全てのフィーチャの状態変数の集合Ｃ_ijを生成する。なお、フィーチャの状態変数は、着目するフィーチャについて、そのフィーチャが選択された場合に真（ＴＲＵＥ）、選択されなかった場合に偽（ＦＡＬＳＥ）となるブール変数からなる。

Ｓ１３０では、Ｓ１２０にて生成された集合Ｃ_ijを用いて、集合Ｃ_ijの全要素（状態変数）を、論理積で結合した論理式Ｈ（Ｃ_ij）を生成する。つまり、論理式Ｈ（Ｃ_ij）は、ソフトウェア部品Ｓ_ijに対応付けられた全てのフィーチャが選択された（全ての状態変数が真である）ときに、その値が真となる。

Ｓ１４０では、ソフトウェア部品の種類を指定するパラメータｉを１に初期化し、続くＳ１５０では、パラメータｉで種類が特定されるＮ_i個のソフトウェア部品Ｓ_ixのそれぞれについて、該ソフトウェア部品に関する論理式Ｈ（Ｃ_ix）を論理否定した否定論理式ＮＨ（Ｃ_ix）を生成する。

Ｓ１６０では、ソフトウェア部品のバリエーションを指定するパラメータｊを１に初期化する。
Ｓ１７０では、Ｓ１５０で生成されたを否定論理式ＮＨ（Ｃ_ix）のうち、ｔ≠ｊとなるＮ_i−１個の否定論理式Ｈ（Ｃ_it）、及び論理式Ｈ（Ｃ_ij）からなるＮ_i個の論理式の全てを論理積で結合することによって、ソフトウェア部品Ｓ_ijに関する個別判定式ＩＳ（Ｃ_ij）を生成し、これを個別判定式ＤＢ４２に記憶する。

Ｓ１８０では、パラメータｊをインクリメント（ｊ←ｊ＋１）し、続くＳ１９０では、パラメータｊが、ソフトウェア部品Ｓ_ixのバリエーションの総数Ｎ_i以下であるか否かを判断する。

パラメータjが総数Ｎ_i以下であれば、Ｓ１７０に戻って個別判定式ＩＳ（Ｃ_ij）の作成を繰り返し、パラメータjが総数Ｎ_iより大きければ、パラメータｉで種類が特定される全てのバリエーションのソフトウェア部品Ｓ_ixについて、個別判定式の生成が終了したものとして、Ｓ２００に進む。

Ｓ２００では、パラメータｉをインクリメント（ｉ←ｉ＋１）し、続くＳ２１０では、パラメータｉが、ソフトウェア部品の種類の総数Ｍ以下であるか否かを判断する。
パラメータｉが総数Ｍ以下であれば、Ｓ１５０に戻って、否定倫理式の生成、個別判定式の生成，記憶を繰り返し、パラメータｉが総数Ｍ以上であれば、コア資産ＤＢ４１に用意された全てのソフトウェア部品について、個別判定式の生成が終了したものとして本処理を終了する。

ここで本処理によって生成される個別判定式の例を以下に示す。
例えば、個々の状態変数をｆ１,ｆ２,…で表すものとし、ｉ＝１で特定される種類のソフトウェア部品のバリエーションの総数がＮ₁＝３であり、これら各ソフトウェア部品のフィーチャ集合が、Ｃ₁₁＝｛ｆ１,ｆ２｝、Ｃ₁₂＝｛ｆ１,ｆ３｝、Ｃ₁₃＝｛ｆ２,ｆ４｝である場合を考える。また、論理積を「＊」、論理否定を「！」で表すものとすると、ソフトウェア部品Ｓ１１の個別判定式ＩＳ（Ｃ₁₁）は、（１）式で表される。

ＩＳ（Ｃ₁₁）＝Ｈ（Ｃ₁₁）＊ＮＨ（Ｃ₁₂）＊ＮＨ（Ｃ₁₃）
＝（ｆ１＊ｆ２）＊！（ｆ１＊ｆ３）＊！（ｆ２＊ｆ４）
＝ｆ１＊ｆ２＊！ｆ３＊！ｆ４（１）
<<結合検査要否判定処理>>
次に、結合検査要否判定処理の内容を、図４に示すフローチャートに沿って説明する。

本処理が起動すると、まず、Ｓ３１０では、判定対象となるソフトウェア部品の組合せ（以下「対象組合せパタン」という）を表す判定対象情報を取得する。
この判定対象情報として、操作部２を介して操作者が指定した内容を取得してもよいし、予め用意された（記憶部４または図示しない外部記憶装置等に記憶された）判定対象情報のリストから順次取得してもよい。

Ｓ３２０では、Ｓ３１０で取得した判定対象情報に従い、判定対象情報に示された対象組合せパタンが、既に判定結果ＤＢ４３に登録されているか否かを判断する。
そして、対象組合せパタンが判定結果ＤＢに登録済みであれば、Ｓ３３０に移行し、判定結果ＤＢ４３から、対象組合せパタンについての判定結果を取得し、その取得した要否判定結果を出力部３に出力して本処理を終了する。

一方、対象組合せパタンが判定結果ＤＢに未登録であれば、Ｓ３４０に移行して、対象組合せパタンに関する要否判定式を生成する。具体的には、個別判定式ＤＢ４２から、対象組合せパタンに示された全てのソフトウェア部品の個別判定式を取得し、その取得した全ての個別判定式を論理積で結合することによって要否判定式を生成する。

Ｓ３５０では、Ｓ３４０で生成された要否判定式の値が、状態変数の値に関わらず常に偽となる（恒偽式）か否かを判断し、肯定判断（常に偽）された場合は、Ｓ３６０に移行し、結合検査は不要である旨の判定結果を出力部３に出力してＳ３８０に進む。

一方、Ｓ３５０にて否定判断された場合、即ち、要否判定式が真偽不明または常に真（恒真式）となる場合は、Ｓ３７０に移行し、結合検査が必要である旨の判定結果を出力部３に出力してＳ３８０に進む。

Ｓ３８０では、Ｓ３６０またはＳ３７０で得られた判定結果を対象組合せパタンに対応付けて判定結果ＤＢ４３に登録すると共に、その新たに登録した対象組合せパタンの判定結果の検索が可能となるように、検索用ＤＢ４４を更新して、本処理を終了する。

ここで本処理によって生成される要否判定式の例を以下に示す。
例えば、フィーチャ集合が、Ｃ₁₁＝｛ｆ１,ｆ２｝、Ｃ₁₂＝｛ｆ１,ｆ３｝、Ｃ₁₃＝｛ｆ２,ｆ４｝、Ｃ₂₂＝｛ｆ２，ｆ４｝である場合を考える。

この場合、ソフトウェア部品Ｓ₁₁，Ｓ₂₁の組合せについての要否判定式ＩＴＴ（Ｃ₁₁，Ｃ₂₁）は（２）式、ソフトウェア部品Ｓ₁₂，Ｓ₂₁についての要否判定式ＩＴＴ（Ｃ₁₂，Ｃ₂₁）は（３）式で表される。

ＩＴＴ（Ｃ₁₁，Ｃ₂₁）＝ＩＳ（Ｃ₁₁）＊ＩＳ（Ｃ₂₁）
＝ｆ１＊ｆ２＊！ｆ３＊！ｆ４（２）
ＩＴＴ（Ｃ₁₂，Ｃ₂₁）＝ＩＳ（Ｃ₁₂）＊ＩＳ（Ｃ₂₁）
＝ｆ１＊ｆ３＊（！ｆ３＋！ｆ２＊！ｆ４）＊ｆ２＊！ｆ４（３）
（２）式は、状態変数の値によって真偽が決まるため、ソフトウェア部品Ｓ₁₁，Ｓ₂₁の組合せは結合検査が必要であると判断される。一方、（３）式は、式中に（ｆ２＊！ｆ２）が含まれており、状態変数の値によらず常に偽となる（恒偽式）ため、ソフトウェア部品Ｓ₁₂，Ｓ₂₁の組合せは結合検査が不要であると判断される。

＜判定結果ＤＢ／検索用ＤＢ＞
ここで、要否判定式による要否判定結果を記憶する判定結果ＤＢ４３及び判定結果ＤＢ４３の検索に使用する検索用ＤＢ４４について説明する。

判定結果ＤＢ４３は、図５に示すように、結合検査の検査対象となるソフトウェア部品の組合せパタンを識別するための識別番号（Ｎｏ．）に対応付けて、対象組合せパタンと、対象組合せパタンについての結合検査の要否判定を、要否判定式を用いて行った結果を示す要否判定結果と、別途実行される結合検査（説明を省略する）の結果であるテスト結果とを記憶させるように構成されている。但し、ここではテスト結果として、結果の格納先アドレスを記憶するようにされている。

また、検索用ＤＢ４４は、図６に示すように、結合検査の検査対象となる個々のソフトウェア部品に対応付けて、そのソフトウェア部品についての転置インデックスを記憶させるように構成されている。

なお、転置インデックスは、判定結果ＤＢ４３の登録内容に従って生成され、ソフトウェア部品毎に、そのソフトウェア部品が含まれている対象組合せパタンに付与された識別番号を、全て列挙した識別番号の集合からなる。

つまり、着目するソフトウェア部品（着目部品）の転置インデックスを見れば、その着目部品を含んだ対象組合せパタンについての情報が、判定結果ＤＢ４３のどこに格納されているのかを全て特定することができるように構成されている。

そして、実際に、検索用ＤＢ４４を用いて判定結果ＤＢ４３を検索するときには、以下の手順で行う。
まず、検索対象となる対象組合せパタンを構成する全てのソフトウェア部品について、検索用ＤＢ４４から転置インデックスを抽出する。

その抽出した転置インデックスの論理積を求める。具体的には、抽出した転置インデックスの全てに同じ識別番号が含まれている場合に限り、その識別番号が論理積の結果として出力される。

論理積を求めた結果がヌル（一つの識別番号も出力されない）である場合は、検索した対象組合せパタンが判定結果ＤＢ４３に登録されていないことを表す。一方、論理積を求めた結果がヌルでなければ、検索した対象組合せパタンが判定結果ＤＢ４３に登録されていることを表す。この場合、結果に示された識別番号を検索することによって、要否判定結果やテスト結果の情報が得られる。

＜効果＞
以上説明したように、結合検査要否判定装置１によれば、ソフトウェア部品Ｓ_ij毎に生成された個別判定式ＩＳ（Ｃ_ij）を用い、検査対象となる全てのソフトウェア部品の個別判定式を論理結合することで生成される要否判定式によって、結合検査の要否判定を解析的に行っているため、検査対象となるソフトウェア部品の数やソフトウェア部品間の関係の複雑度によらず、簡易な論理計算によって結合検査の要否判定結果を得ることができる。

また、この要否判定結果に従って結合検査を実施することにより、仕様上、同時に組合せて使用されることのない組合せパタンについて、無駄に結合検査が行われてしまうことが防止されるため、コア資産の構築に要する手間を削減することができる。

また、結合検査要否判定装置１によれば、判定結果ＤＢ４３に、検査対象の組合せパタンと対応付けて要否判定結果や結合検査の結果を記憶し、検索用ＤＢ４４を用いて、過去の判定結果等を容易に検索できるようにされているため、判定済み，検査済みの組合せパタンについての判定や検査が重複して行われることを防止することができる。

＜他の実施形態＞
以上本発明の一実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、様々な態様にて実施することが可能である。

例えば、上記実施形態では、対応情報を、記憶部４を構成するコア資産ＤＢ４１から取得しているが、例えば、図示しない外部記憶装置から取得したり、インターネット等の通信ネットワークを介して通信ネットワーク上に設けられたサーバ等から取得したりするようにしてもよい。

上記実施形態では、判定結果ＤＢ４３や検索用ＤＢ４４を備えているが、これを省略してもよい。その場合、例えば、要否判定式による判定結果が得られると、その判定結果に従って、直ちに結合検査を実行するようにしてもよい。

１…結合検査要否判定装置２…操作部３…出力部４…記憶部５…制御部４１…コア資産データベース４２…個別判定式データベース４３…判定結果データベース４４…検索用データベース

Claims

ソフトウェアプロダクトラインのコア資産として使用される再利用可能なソフトウェアであるソフトウェア部品間の結合検査の要否を判定する結合検査要否判定方法であって、
前記ソフトウェアプロダクトラインによって製造されるプロダクト群の特徴を表現したフィーチャモデルを構成する各フィーチャと前記ソフトウェア部品の種類及びバリエーションとの対応関係を表す対応情報を取得する第１のステップ（Ｓ１１０）と、
前記ソフトウェア部品の種類をｉ（ｉ＝１，２，…Ｍ：Ｍはソフトウェア部品の種類の総数），バリエーションをｊ（ｊ＝１，２，…Ｎi ：Ｎi は種類ｉで特定されるソフトウェア部品のバリエーションの総数）、ｉ，ｊによって特定される一つのソフトウェア部品をＳijで表すものとして、前記フィーチャ毎に用意され、該フィーチャが選択された場合に真、選択されなかった場合に偽となる状態変数を使用し、前記第１のステップで取得した対応情報に従って、前記ソフトウェア部品Ｓij毎に、該ソフトウェア部品Ｓijに対応付けられた全てのフィーチャの前記状態変数の集合Ｃijを生成する第２のステップ（Ｓ１２０）と、
ｉによって特定されるＮi 個のソフトウェア部品からなるソフトウェア部品群をＳix、Ｓixのうちｊによって特定されるバリエーション以外のＮi −１個のバリエーションをｔ（ｔ≠ｊ）で表し、Ｃijの全要素を論理積で結合することで得られる論理式をＨ（Ｃij）、Ｈ（Ｃij）を論理否定することで得られる論理式をＮＨ（Ｃij）で表すものとして、前記ソフトウェア部品Ｓij毎に、Ｈ（Ｃij）及びＮi −１個のＮＨ（Ｃit）を論理積で結合した論理式からなる個別判定式ＩＳ（Ｃij）を生成する第３のステップ（Ｓ１３０〜Ｓ２１０）と、
結合検査の要否判定の対象となる二つ以上のソフトウェア部品を指定する第４のステップ（Ｓ３１０）と、
前記第４のステップで指定されたソフトウェア部品について前記第３のステップにて生成された全ての個別判定式を論理積で結合することで要否判定式を生成し、該要否判定式が常に偽（恒偽式）となる場合は検査不要、該要否判定式が真偽不明または常に真（恒真式）となる場合は検査必要と判定する第５のステップ（Ｓ３４０〜Ｓ３７０）と、
をコンピュータに実行させることを特徴とする結合検査要否判定方法。
ソフトウェアプロダクトラインのコア資産として使用される再利用可能なソフトウェアであるソフトウェア部品間の結合検査の要否を判定する結合検査要否判定装置（１）であって、
前記ソフトウェアプロダクトラインによって製造されるプロダクト群の特徴を表現したフィーチャモデルを構成する各フィーチャと前記ソフトウェア部品の種類及びバリエーションとの対応関係を表す対応情報を取得する対応情報取得手段（５，Ｓ１１０）と、
前記ソフトウェア部品の種類をｉ（ｉ＝１，２，…Ｍ：Ｍはソフトウェア部品の種類の総数），バリエーションをｊ（ｊ＝１，２，…Ｎ_i：Ｎ_iは種類ｉで特定されるソフトウェア部品のバリエーションの総数）、ｉ，ｊによって特定される一つのソフトウェア部品をＳ_ijで表すものとして、前記フィーチャ毎に用意され、該フィーチャが選択された場合に真、選択されなかった場合に偽となる状態変数を使用し、前記対応情報取得手段によって取得された対応情報に従って、前記ソフトウェア部品Ｓ_ij毎に、該ソフトウェア部品Ｓ_ijに対応付けられた全てのフィーチャの前記状態変数の集合Ｃ_ijを生成する状態集合生成手段（５，Ｓ１２０）と、
ｉによって特定されるＮ_i個のソフトウェア部品からなるソフトウェア部品群をＳ_ix、Ｓ_ixのうちｊによって特定されるバリエーション以外のＮ_i−１個のバリエーションをｔ（ｔ≠ｊ）で表し、Ｃ_ijの全要素を論理積で結合することで得られる論理式をＨ（Ｃ_ij）、Ｈ（Ｃ_ij）を論理否定することで得られる論理式をＮＨ（Ｃ_ij）で表すものとして、前記ソフトウェア部品Ｓ_ij毎に、Ｈ（Ｃ_ij）及びＮ_i−１個のＮＨ（Ｃ_it）を論理積で結合した論理式からなる個別判定式ＩＳ（Ｃ_ij）を生成する個別判定式生成手段（５，Ｓ１３０〜Ｓ２１０）と、
結合検査の要否を判定する対象となる二つ以上のソフトウェア部品を指定する対象指定手段（５，Ｓ３１０）と、
該対象指定手段にて指定されたソフトウェア部品について前記個別判定式生成手段にて生成された全ての個別判定式を論理積で結合することで要否判定式を生成し、該要否判定式が常に偽（恒偽式）となる場合は検査不要、該要否判定式が真偽不明または常に真（恒真式）となる場合は検査必要と判定する検査要否判定手段（５，Ｓ３４０〜Ｓ３５０）と、
検査要否判定手段での判定結果を出力する判定結果出力手段（５，Ｓ３６０〜Ｓ３７０）と、
を備えることを特徴とする結合検査要否判定装置。
結合検査要否判定手段での判定結果を前記ソフトウェア部品の組合せと対応付けて記憶する判定結果記憶手段（４３）を備え、
前記判定結果出力手段（５，Ｓ３２０〜Ｓ３３０）は、前記対象指定手段にて選択されたソフトウェア部品の組合せについての判定結果が前記判定結果記憶手段に記憶されている場合には、前記検査要否判定手段による判定を実行することなく、前記判定結果記憶手段に記憶されている判定結果を出力することを特徴とする請求項２に記載の結合検査要否判定装置。
前記判定結果記憶手段の検索を、転置インデックスを用いて実行することを特徴とする請求項３に記載の結合検査要否判定装置。