JP6904364B2 - システム構築支援装置、方法およびプログラム - Google Patents

Description

本発明は、システムの構築を支援するシステム構築支援装置、システム構築支援方法およびシステム構築支援プログラムに関する。

ソフトウェア・システムの構築には、要求されたサービスを正常に動作する環境を整えることが要求される。そのような環境を整えるためには、ミドルウェアのインストールや、サービスの起動、設定ファイルの配備といったシステムの構築処理を行うパッチジョブ等のタスク（以下、構成変更タスクという）を適切に実行する必要がある。

本発明において、システムの構築といった場合には、システムの構成を変更、すなわち既存のシステムから改変を行って新たなシステムを構築する場合も含まれる。同様に、構成変更タスクには、現在のシステムの構成から構成要素の追加や削除を行うタスク、構成要素の状態を変更するタスクも含まれる。

近年、システム動作環境やソフトウェアの多様化によって、このような構成変更タスクを利用するためには広い専門知識が必要となっている。

上記の専門知識には、構成変更タスク間の依存関係が含まれる。構成変更タスク間の依存関係は、より具体的には、あるソフトウェアのパッケージＡをインストールするためにはパッケージＢのインストールを先に実行しなければならないといった順序関係を指す。なお、構成変更タスク間の順序関係は、さらに読み解くと、システムの状態をある状態に遷移させるためにはある構成要素の状態がＣでなければならないといった構成変更タスクと構成要素の状態間の依存関係といってもよい。したがって、システム構築者は、専門知識として、構成変更タスク間の依存関係の代わりに、構成変更タスクの前提条件とされる構成要素の状態、すなわち構成変更タスクと構成要素の状態間の依存関係を保持していてもよい。このような依存関係はパッケージのインストールの際に限らず、様々なシステムの変更の際にも生じる。依存関係を無視し、誤った順序や前提条件を無視して構成変更タスクを実行してしまうと障害が起きてしまう。

システムの構築を適切に行う技術に関連し、システムの構成要素間の依存関係を管理して適切な順序で構成変更タスクを実行する技術がある（例えば、特許文献１、特許文献２、非特許文献１および非特許文献２参照）。

特に、特許文献１に記載の方法は、システムを一から構築する場合だけでなく、既存のシステムを変更する場合にも対処できるように、システムを、構成部品の状態の集合として定義する。例えば、特許文献１に記載の方法は、構成部品内の状態遷移と構成変更タスクとを対応づけ、ある構成部品の状態遷移を実行する際に他の構成部品があるべき状態を指定することにより、構成変更タスクと構成部品の状態間の依存関係を管理している。

なお、非特許文献１に記載のＣｈｅｆおよび非特許文献２に記載のＰｕｐｐｅｔは、クラウドコンピューティングを自動化する構成管理ツールの一種である。いずれも、サーバの状態をコードで管理することにより、自動でサーバを構築できるようにしている。

また、特許文献３には、構成変更タスク間の依存関係を実行ログから算出する方法が記載されている。特許文献３には、さらに実行ログが膨大になった場合の解決策も記載されている。

特開２０１５−２１５８８５号公報 国際公開第２０１４／０４９８５４号 特開２０１１−１２８８２８号公報

Puppet enterprise, "Instructure as code - the foundation for DevOps | Puppet", ［２０１６年１０月４日検索］, インターネット＜ＵＲＬ：https://puppet.com/solutions/infrastructure-as-code＞ Chef Software, Inc., "Infrastructure Automation | Chef",［２０１６年１０月４日検索］, インターネット＜ＵＲＬ：https://www.chef.io/solutions/infrastructure-automation/＞

特許文献１、特許文献２、非特許文献１および非特許文献２に記載されている方法は、システム構築者が、必要とされる依存関係を記載したファイル等を入力しなければならない。このように、当該方法は、システム構築に利用する構成変更タスクに関わる全ての依存関係を人が記載しなければならず、手間がかかるという問題がある。また、例えば、当該方法は、システム構築者が誤った依存関係を入力した場合、システム構築が失敗してしまうという問題がある。さらに、当該方法は、依存関係の正しさを確認する方法がなく、実際に構成変更タスクを実行してその結果を取得しないと依存関係の正誤の判定ができないという問題がある。このように、当該方法は、手間がかかる上に、実環境でのエラーを予防できないため、システム構築者が対象とするシステム構築を行うために必要な構成要素間の依存関係に関する正しい知識を有していなければ利用できないという問題がある。

また、特許文献３に記載の方法は、必要とされる構成変更タスク間の依存関係を導出するために、実行ログに、それら構成変更タスクが実行されうる全てのシチュエーションでの実行結果が含まれている必要がある。例えば、当該方法は、必要とするタスク実行結果が一つでも実行ログに含まれていない場合、正しい依存関係が導出できないという問題がある。さらに、当該方法は、手順の実行可否を、実行ログに含まれるタスクの実行結果、すなわちタスクの実行の成否だけで決めており、タスク実行前にシステムがどのような状態であったかについては何ら考慮していない。このため、タスク実行前のシステム状態によってタスクの実行結果が異なる場合であっても、原因が特定できずに構成変更タスク間の依存関係を正しく導出できない可能性がある。

また、例えば再利用性を高めるために、ある構成部品において過去に意図しない箇所の変更が行われたとする。このような意図しない箇所の変更は、システム構築の際にはタスク実行不可と判断すべきであるが、既存の実行ログを分析する方法では、実行ログ中のタスクが意図しない箇所の変更に該当するか否を判断できない。

なお、システム構築手順を生成する際に必要となるシステム内の依存関係、より具体的には構成変更タスク間または構成変更タスクと構成要素の状態間の依存関係が人手によらずに正しく抽出できれば、例えば人が記載した依存関係が正しいか否かの検証を行うことも可能である。

そこで、本発明は、上記課題に鑑み、構成変更タスク間または構成変更タスクと構成要素の状態間の依存関係を正しく、かつ容易に抽出できるシステム構築支援装置、システム構築支援方法およびシステム構築支援プログラムを提供することを目的とする。

本発明によるシステム構築支援装置は、検証対象とする構成変更タスクを示す情報と、対象システムの各構成要素が取り得る状態を示す情報と、各構成要素が状態間を遷移するための状態遷移タスクを示す情報とを入力として、対象システムと同じ動作をする疑似システムの状態を変化させて構成変更タスクを実行することにより、対象システムが取り得る全てのシステム状態における構成変更タスクの実行結果を取得するタスク確認手段と、取得された実行結果に基づいて、構成変更タスクの各々が有する依存関係を算出し、算出された依存関係を示す情報を出力する依存関係算出手段とを備えたことを特徴とする。

本発明によるシステム構築支援方法は、検証対象とする構成変更タスクを示す情報と、対象システムの各構成要素が取り得る状態を示す情報と、各構成要素が状態間を遷移するための状態遷移タスクを示す情報とが入力されると、対象システムと同じ動作をする疑似システムの状態を変化させて構成変更タスクを実行することにより、対象システムが取り得る全てのシステム状態における構成変更タスクの実行結果を取得し、取得された実行結果に基づいて、構成変更タスクの各々が有する依存関係を算出し、算出された依存関係を示す情報を出力することを特徴とする。

本発明によるシステム構築支援プログラムは、コンピュータに、検証対象とする構成変更タスクの情報と、対象システムの各構成要素が取り得る状態の情報と、各構成要素が状態間を遷移するための状態遷移タスクの情報とを入力として、対象システムと同じ動作をする疑似システムの状態を変化させて構成変更タスクを実行することにより、対象システムが取り得る全てのシステム状態における構成変更タスクの実行結果を取得する処理、および取得された実行結果に基づいて、構成変更タスクの各々が有する依存関係を算出し、算出された依存関係を示す情報を出力する処理を実行させることを特徴とする。

本発明によれば、構成変更タスク間または構成変更タスクと構成要素の状態間の依存関係を正しく抽出できる。

第１の実施形態の依存関係抽出装置の構成例を示すブロック図である。 検証環境情報１０１の例を示す説明図である。 構成要素モデル情報１０２の例を示す説明図である。 構成要素モデル情報１０２の他の例を示す説明図である。 確認手段情報１０３の例を示す説明図である。 確認手段情報１０３の他の例を示す説明図である。 初期状態情報１１１の例を示す説明図である。 全状態遷移情報１２２の例を示す説明図である。 変更手段情報１２１の例を示す説明図である。 変更手段情報１２１の他の例を示す説明図である。 変更結果１３１の例を示す説明図である。 変更結果１３１の他の例を示す説明図である。 変更結果記憶部１４０に記憶される情報の例を示す説明図である。 変更結果記憶部１４０に記憶される情報の他の例を示す説明図である。 依存関係情報１５１の例を示す説明図である。 依存関係抽出装置１００の動作の概要を示すフローチャートである。 検証環境構築部１１０の動作の一例を示すフローチャートである。 状態探索部１２０の動作の一例を示すフローチャートである。 状態変更部１３０の動作の一例を示すフローチャートである。 依存関係算出部１５０の動作の一例を示すフローチャートである。 本発明の概要を示すブロック図である。 本発明のシステム構築支援装置の他の構成例を示すブロック図である。

以下、図面を参照して本発明の実施形態を説明する。

なお、各図面は本発明の実施形態の一例を示すものである。したがって、本発明の実施形態は各図面の記載に限られない。また、各図面において同様の構成には同じ番号を付し、繰り返しの説明を省略する場合がある。また、各図面において、本発明の説明に関係しない部分の構成の記載を省略する場合もある。

また、以下の説明において、第１の構成要素が第２の構成要素に必要な情報を渡す場合に送信（出力）するとの表現を用いるが、情報の受け渡しはこのような動作に限られない。例えば、第１の構成要素は、生成（算出）又は受信した情報を記憶部に保存し、第２の構成要素は、この記憶部から必要な情報を読み出してもよい。そのような場合、本発明の実施形態は、図示しない記憶部を含んでいてもよい。

実施形態１．
以下、本発明の第１の実施形態にかかる依存関係抽出装置１００について、図面を参照して説明する。第１の実施形態にかかる依存関係抽出装置１００は、本発明のシステム構築支援装置の一例であって、対象となるシステムの構築を行う際に必要とされる構成変更タスクと構成要素の状態間の依存関係を抽出するための処理を行う。

図１は、第１の実施形態の依存関係抽出装置１００の構成例を示すブロック図である。図１に示す依存関係抽出装置１００は、検証環境構築部１１０と、状態探索部１２０と、状態変更部１３０と、変更結果記憶部１４０と、依存関係算出部１５０とを備える。

本実施形態の依存関係抽出装置１００は、入力される構成要素モデル情報１０２に定義された全ての構成変更タスクの実行可否を検証環境上で検査することにより、対象とされる構成変更タスクと構成要素の状態間の依存関係を抽出する。より具体的に、依存関係抽出装置１００は、対象システムに追従した状態探索を行い、状態探索で発見された対象システムの全ての状態遷移と構成変更タスクとを対応づける。そして、依存関係抽出装置１００は、そのようにして対象システムの状態遷移と対応づけられた各構成変更タスクの逐次検査を検証環境で実施する。ここで、対象システムに追従した状態探索とは、構成要素モデル情報１０２が示す構成要素モデルの状態遷移に準じて、検証環境である疑似システムの構成要素の状態を遷移させ、その結果疑似システムが取り得る状態を全て探索することを指す。このとき、疑似システムの遷移後の状態は、対象システムで同様の状態遷移を行ったときの現在状態と整合するように保持、管理される。

また、依存関係抽出装置１００は、探索可能な全ての状態遷移について、対応する構成変更タスクの実行結果を示す変更結果１３１を作成し、作成された変更結果１３１を基に、構成変更タスクと構成要素の状態間の依存関係を示す依存関係情報１５１を作成、出力する。

図１に示す構成において、検証環境構築部１１０は、検証環境情報１０１と構成要素モデル情報１０２と確認手段情報１０３とを取得する。情報の取得方法は、特に制限されない。例えば、依存関係抽出装置１００のユーザが、図示しない入力装置を用いて、これらの情報を依存関係抽出装置１００に送信してもよい。また、例えば、ユーザが依存関係抽出装置１００を直接操作して、これらの情報を依存関係抽出装置１００に入力してもよい。

また、検証環境構築部１１０は、取得した検証環境情報１０１を基に、検証用に用意された仮想マシン上に、検証環境とされる疑似システムを構築する。例えば、検証環境構築部１１０は、検証環境情報１０１に従い、仮想マシンの立ち上げ、動作の検証に必要なミドルウェアのインストール、設定ファイルの配備等の構築処理を行う。また、検証環境構築部１１０は、検証環境情報１０１に従って疑似システムの構築処理を実施した後、確認手段情報１０３を基に、疑似システムの初期状態を確認する。検証環境構築部１１０は、初期状態の確認ができたら、疑似システムの初期状態を示す初期状態情報１１１を状態探索部１２０に送信する。

検証環境情報１０１は、対象システムと同じ動作を行う検証環境としての疑似システムに関する情報である。検証環境情報１０１には、疑似システムを構築するための情報、より具体的には疑似システムを立ち上げてサービスが可能な初期状態まで移行させるために必要な情報が含まれる。

具体例として、検証環境情報１０１は、動作検証で利用するクラウド基盤ソフトウェア、起動する仮想マシン、配備するパッケージ、設定ファイルといったシステムを構築する基盤となる基盤要素に関する情報と、これら基盤要素を稼動させ、疑似システムを構築するための手順情報とを含んでいてもよい。ここで、クラウド基盤ソフトウェアに関する情報は、例えば、利用するクラウド環境の種類と、クラウド基盤ソフトウェアを操作するためのアクセス方法とを示す情報であってもよい。また、仮想マシンに関する情報は、例えば、利用するイメージファイルと、ネットワーク上の所在（ＩＰアドレス等の割り当て等）とを示す情報であってもよい。また、パッケージや設定ファイルに関する情報は、パッケージの種類と、パッケージへのアクセス情報と、パッケージ固有の詳細情報と、設定ファイルの所在とを示す情報であってもよい。なお、これらの情報は、非特許文献１や非特許文献２に記載の構成管理ツールを利用して作成されたものであってもよい。

図２は、検証環境情報１０１の例を示す説明図である。図２に示すように、検証環境情報１０１は、システム構成情報と、システム構築手順情報とを含んでいてもよい。なお、図２（ａ）にシステム構成情報の一例を示し、図２（ｂ）にシステム構築手順情報の例を示している。

システム構成情報は、検証環境とされる疑似システムの構成を示す情報であり、具体的には、疑似システムを構築する際に必要となるクラウド基盤や仮想マシンといった疑似システムの基盤要素の情報が登録される。システム構成情報は、例えば、基盤要素ＩＤ（Identifier）、種類、アクセス情報およびプロパティ（属性や設定値）を含んでいてもよい。

基盤要素ＩＤは、各基盤要素に割り当てられる識別子である。種類は、クラウド基盤、仮想マシン、ミドルウェアといった基盤要素の機能的な分類を示すものであればよい。アクセス情報は、各構成要素にアクセスするための情報である。アクセス情報は、例えば、構成要素を操作するために必要なＵＲＬ（Uniform Resource Locator）、ＩＰ（Internet Protocol）アドレス、ユーザ名、パスワードの情報を含んでいてもよい。

ところで、クラウド基盤や仮想マシンにアクセスした際、ＲＳＡ公開鍵認証によるアクセス制御が行われることがある。そのような場合に、アクセス情報は、利用する鍵名や秘密鍵のパスをさらに含んでいてもよい。なお、基盤要素がミドルウェアの場合、仮想マシンにアクセス出来れば、特段の情報なしに所望の操作が出来る場合がある。その場合、アクセス情報は省略されてもよいし、空欄としてもよい。また、依存関係抽出装置１００と検証環境とを直接接続するなど、検証環境をローカルに配備して動作検証を行うなど、リモートアクセスを要しない場合にも、アクセス情報を省略または空欄としてよい。なお、アクセス情報は、依存関係抽出装置１００において検証環境とされる疑似システムにアクセスする操作全てで利用される。

プロパティには、各基盤要素の属性や設定値など、基盤要素固有の詳細情報が記載される。例えば、基盤要素がクラウド基盤の場合、システム構成情報のプロパティに、クラウド基盤ソフトウェアの種類が含まれていてもよい。クラウド基盤ソフトウェアを操作するためのＡＰＩ（Application Programming Interface）はクラウド基盤の種類によって異なる。クラウド基盤ソフトウェアの種類がシステム構成情報のプロパティに含まれることにより、依存関係抽出装置１００（より具体的には検証環境構築部１１０）でＡＰＩの違いを判断できるようにしてもよい。

また、基盤要素が仮想マシンの場合、プロパティに、仮想マシンのイメージＩＤや、ＣＰＵ、メモリ等のハードウェア構成ＩＤ（仮想マシンフレーバーＩＤ）、仮想マシンに割り当てるＩＰアドレス（Ｆｌｏａｔｉｎｇ ＩＰ）が含まれていてもよい。

なお、プロパティに記載する情報（項目）及びその値は上記に限らず、プロパティは基盤要素を操作するために必要な項目及び値を含んでいればよい。

また、システム構築手順情報は、図２（ｂ）に示すように、検証用に用意された仮想マシン上に疑似システムを構築するために実行する作業の順番である手順番号と、該作業の内容である実行内容の情報とを含んでいてもよい。実行内容の情報は、実行するプログラムやスクリプトのパスまたは実行コマンドであってもよい。また、実行コマンドが基盤要素の情報を引数に用いる場合に、基盤要素ＩＤを用いて該情報の指定を行うことも可能である。

なお、ユーザは、特許文献１に記載の状態マシン群のテキストによる定義を利用してシステム構築手順情報を作成することも可能である。

図３は、構成要素モデル情報１０２の例を示す説明図である。構成要素モデル情報１０２は、対象システムの構成要素の各々について対象システム上で取り得る状態遷移をモデル化して示す情報である。構成要素モデル情報１０２は、例えば、図３に示すように、対象システムが備える各構成要素の識別子であるＭＩＤに対応づけて、モデル名と、状態と、状態遷移タスクとを含んでいてもよい。なお、図３に示す表の各行が、一つの構成要素に対応した構成要素モデル情報に相当する。対象システムの構成要素の単位は特に問わない。例えば、対象システム上で稼働するソフトウェアが有する任意の機能単位であってもよい。また、構成要素の状態の定義も特に限定されない。

ここで、モデル名は、対象システムの構成要素のモデルに対して付される名称である。なお、本例ではユーザが識別しやすいように構成要素のモデルに対して名称を付しているが、モデル名は省略されてもよい。また、状態は、構成要素が対象システム上で取り得る全ての状態を含む。例えば、構成要素がＡｐａｃｈｅのパッケージという機能単位であった場合、構成要素の取り得る状態として、パッケージが未インストールの状態を表すＦと、インストール済みの状態を表すＴとが定義される。図３に示す例には、モデル名が「Ａｐａｃｈｅ．ｐａｃｋａｇｅ」の状態として、ＦとＴの２つの状態が記載されている。

また、状態遷移タスクは、モデル名が示す構成要素の状態を遷移させるために実行するタスクである。なお、状態遷移タスクは、構成要素の状態遷移によってシステムの状態を変更する構成変更タスクとも言える。状態遷移タスクの情報には、構成要素が対象システム上で取り得る全ての状態遷移に対応するタスクが記載（定義）される。具体的には、「状態」欄で定義した状態を基に、それら状態間の遷移を行うために実行されるタスクが記載（定義）される。

例えば、状態Ｘから状態Ｙに遷移するためにＣｏｍｍａｎｄというコマンドが実行されればよい場合には、状態遷移タスクを、「Ｘ−＞Ｙ：Ｃｏｍｍａｎｄ」のように定義してもよい。図３に示す例には、モデル名「Ａｐａｃｈｅ．ｐａｃｋａｇｅ」の構成要素を、状態Ｆから状態Ｔに遷移するための構成変更タスクとして、当該状態遷移を表す「Ｆ−＞Ｔ」の後に実行コマンド「ａｐｔ ｉｎｓｔａｌｌ ａｐａｃｈｅ２」が定義されている。状態遷移タスクの実行コマンドを表す部分には、実行するプログラムやスクリプト名が記載されてもよい。

また、図４は、構成要素モデル情報１０２の他の例を示す説明図である。図４に示すように、構成要素モデル情報１０２は、状態遷移タスクの情報に、＜ｃｍｄＮａｍｅ＞などといった任意の変数を導入することも可能である。そのような場合、構成要素モデル情報１０２は、プロパティとして、さらに状態遷移タスクの変数の具体値を持つ属性を含んでいてもよい。

なお、ユーザは、特許文献１に記載の状態マシン群のテキストによる定義を利用して構成要素モデル情報１０２を作成することも可能である。

図５は、確認手段情報１０３の例を示す説明図である。確認手段情報１０３は、検証対象となる全ての構成要素の状態を確認する状態確認手段に関する情報である。確認手段情報１０３は、例えば、構成要素の状態を確認するための具体的なタスクの情報と、その実行結果から状態を判定するための判定基準とを含んでいてもよい。なお、図５に示す例では、表の各行が一つの状態確認手段に関する情報に相当する。図５に示すように、確認手段情報１０３は、状態確認手段の識別情報である確認Ｎｏに対応づけて、対象モデルと、状態確認タスクと、判定基準とを含んでいてもよい。

ここで、対象モデルは、状態確認手段が状態を確認する対象とする構成要素のモデルである。また、状態確認タスクは、対象モデルの状態を確認するために実行するタスクである。例えば、確認手段情報１０３に、状態確認タスクの情報として、検証環境にアクセスして実行する状態確認テストのコマンドが記載されてもよい。判定基準は、対象モデルの状態がどの状態であるかを判定するための基準である。判定基準には、状態確認タスクを実行した結果得られる情報から、対象モデルの状態を特定するための情報が記載される。

例えば、図５に示す例において、確認Ｎｏ＝１の状態確認タスクの情報として、対象モデルである「Ａｐａｃｈｅ．ｐａｃｋａｇｅ」の状態を確認するための状態確認テストの情報が記載されている。より具体的には、状態を確認するためのプログラムのパスが記載されている。これに対して、判定基準である「Ｐａｓｓｅｄ：Ｔ」は、状態確認タスクとして状態確認テスト「．／ｐａｃｋａｇｅＴｅｓｔ」を実行した結果、当該状態確認テストが全て通過した場合、状態確認タスクが正常終了したとして、対象モデルの状態がＴであると判定することを示している。なお、例えば、判定基準が「Ｆａｉｌｅｄ：Ｆ」であれば、指定された状態確認テストを実行した結果、１つでも失敗した場合に、状態確認タスクが正常終了しなかったとして、対象モデルの状態がＦであると判定することを示す。

また、図６は、確認手段情報１０３の他の例を示す説明図である。図６に示すように、状態確認手段は、各構成要素の状態の各々に対して割り当てられてもよい。図６に示す例では、確認Ｎｏを各構成要素の状態の各々に対して割り当てることで、当該各々を一つの状態確認手段としている。

また、検証環境構築部１１０は、疑似システムを構築後、全ての構成要素に対して状態確認タスクを実行してシステムの現在の状態を確認する。検証環境構築部１１０は、その結果得られた構成要素の状態の集合をシステムの初期状態とし、該初期状態を示す初期状態情報１１１を生成し状態探索部１２０に送信する。

図７は、初期状態情報１１１の例を示す説明図である。初期状態情報１１１は、図７に示すように、全ての構成要素について、当該構成要素の現在の状態を含んでいてもよい。

状態探索部１２０は、構成要素モデル情報１０２を基に、対象システムの全ての状態遷移を抽出し、抽出された状態遷移の各々と構成変更タスクとを対応づける。状態探索部１２０は、例えば、構成要素モデル情報１０２に基づいて、初期状態から遷移可能な構成要素モデルの状態の組み合わせによって表されるシステム状態の、全ての状態遷移を抽出し、その各々と状態遷移タスク（構成変更タスク）とを対応づける。また、状態探索部１２０は、確認手段情報１０３に基づいて、それら全ての状態遷移について、対応する構成変更タスクの実行方法および実行後のシステム状態の確認方法を含む全状態遷移情報１２２を生成する。

状態探索部１２０は、例えば、構成要素の取り得る状態の全ての組み合わせを、システムが取り得る全ての状態（システム状態）として定義し、そのシステム状態の各々を現在状態と仮定したときに、各現在状態から遷移可能なシステム状態を全て抽出することにより、システムの全ての状態遷移を抽出してもよい。

また、状態探索部１２０は、初期状態情報１１１と全状態遷移情報１２２とを基に、状態探索を行う。状態探索部１２０は、より具体的には、全状態遷移情報１２２に示される構成変更タスクの全てを対象に、検証環境で実際に起動して疑似システムが目的とする状態に遷移するか否かを確認する。状態探索部１２０は、初期状態とされるシステム状態から状態探索を開始する。状態探索は、初期状態から遷移可能な全ての状態遷移について行う。ここで、遷移可能な状態遷移には、複数の構成変更タスクの実行により遷移する場合も含まれる。

例えば、状態探索部１２０は、初期状態から始めて、現在のシステム状態を構成している構成要素の中から１つを選択し、選択した構成要素を他の状態に遷移させ、その結果を確認するという状態変更処理を、遷移可能な全ての状態遷移を対象に順次行ってもよい。

なお、本例において状態探索部１２０は、後述する状態変更部１３０に指示を出して状態変更処理を行わせる。状態探索部１２０は、例えば、確認対象とした状態遷移に関して、構成変更タスクの実行方法とシステム状態の確認方法とを含む変更手段情報１２１を状態変更部１３０に送信してもよい。そして、状態探索部１２０は、状態変更部１３０より、状態変更処理の結果として、構成変更タスクの実行の成否および確認されたシステム状態を示す変更結果１３１を受信する。

状態探索部１２０は、複数の状態遷移の情報を含む変更手段情報１２１を状態変更部１３０に送信してもよい。この場合、状態変更部１３０は、変更手段情報１２１に含まれる各状態遷移について、状態変更処理として状態変更タスクおよび状態確認タスクの実行を行い、それらの結果を示す変更結果１３１を送信すればよい。

状態探索部１２０は、変更結果１３１を受信すると、状態変更処理の結果である構成変更タスクの実行の成否および確認されたシステム状態を全状態遷移情報１２２に追記してもよい。状態探索部１２０は、全状態遷移情報１２２に含まれる全ての状態遷移を確認し終えたら、依存関係算出部１５０にその旨を通知する。

図８は、全状態遷移情報１２２の例を示す説明図である。なお、図８には、全状態遷移情報１２２の一部が示されている。図８に示す表の各行が、一つの状態遷移に対応する。図８に示すように、全状態遷移情報１２２は、各状態遷移について、遷移前状態と、対象ＭＩＤと、状態遷移と、遷移先状態と、確認Ｎｏと、確認結果とを含んでいてもよい。

遷移前状態は、状態遷移をする前のシステム状態である。なお、既に説明したように、本例においてシステムの状態は検証対象となる構成要素の状態の組み合わせによって定義される。対象ＭＩＤは、状態を変更する対象とする構成要素の識別子である。状態遷移は、ＭＩＤが示す構成要素に対する状態遷移である。遷移先状態は、状態遷移をした後のシステム状態である。また、確認Ｎｏは遷移後のシステム状態を確認するための状態確認手段の識別子である。なお、確認結果には、状態遷移の成否と、状態遷移後のシステム状態の整合性とが含まれる。図中の「状態遷移：−」は状態遷移タスクの未実行（未探索）を表している。また、「状態確認：−」は状態確認タスクの未実行を表している。

変更手段情報１２１には、状態変更処理に必要な情報が含まれていればよい。図９および図１０は、変更手段情報１２１の例を示す説明図である。図９に示すように、変更手段情報１２１は、全状態遷移情報１２２から確認対象とした状態遷移に関する情報をそのまま利用したものであってもよい。また、図１０に示すように、変更手段情報１２１は、全状態遷移情報１２２から確認対象とした状態遷移に関する情報の一部を抜粋したものであってもよい。なお、変更手段情報１２１はそれに限られず、例えば、さらに状態変更タスクの情報や現在状態の状態確認手段の情報等を含んでいてもよい。

なお、図９および図１０に示す例は、システムの現在状態として構成要素の状態が全てＦである場合に、ＭＩＤ＝１の構成要素を状態Ｆから状態Ｔに変更する状態遷移タスクを実行すること、および確認Ｎｏ＝２，３および５で示される状態確認タスクを各々実行してシステム状態の確認を行うことを指示している。図示のように、状態確認手段の情報として、状態確認手段の識別子を指定してもよい。このとき、複数の状態確認手段の識別子を指定することも可能である。また、図９に示す例では、遷移先状態と確認結果の欄が予め設けられているが、図１０に示すように、これらの欄は省略されてもよい。

状態変更部１３０は、変更手段情報１２１を取得し、その情報を基に検証環境にアクセスする。また、状態変更部１３０は、変更手段情報１２１を基に状態変更タスクおよび状態確認タスクの実行を行い、その結果を示す変更結果１３１を変更結果記憶部１４０に記憶する。このとき、状態変更部１３０は、変更結果１３１を変更結果記憶部１４０に記憶するとともに、状態探索部１２０に送信してもよい。

変更結果１３１は、変更手段情報１２１に示される状態変更処理の結果を示す情報である。図１１および図１２は、変更結果１３１の例を示す説明図である。変更結果１３１は、図示のように、変更手段情報１２１に確認結果を追記したものであってもよい。ここで、確認結果は、例えば、変更手段情報１２１が示す状態遷移に対応する状態遷移タスクの実行結果と、変更手段情報１２１が示す確認Ｎｏに対応する確認手段（状態確認タスク）の実行結果とを含んでいてもよい。図中の確認結果における「状態遷移：○」は全ての状態遷移タスクが成功したことを表している。また、「状態確認：○」は全ての状態確認タスクが成功したことを表している。なお、「○」の代わりに「×」が記載されていた場合、そのタスクが失敗したことを表す。例えば、「状態遷移：×」は、状態遷移タスクが失敗したことを表している。また、例えば、「状態確認：×」はいずれかの状態確認タスクが失敗したことを表している。なお、図１２に示す例では、状態遷移タスクの失敗により状態確認をする必要がないため、状態確認タスクの結果に未実行を表す「−」が記載されている。

状態探索部１２０は、変更結果１３１に示される確認結果を基に、疑似システムの現在状態を管理しながら、状態探索を行う。状態探索部１２０は、例えば、依頼した変更手段情報１２１に対して状態遷移タスクおよび状態確認タスクが成功した旨の変更結果１３１を受信した場合、疑似システムの現在状態を、依頼した変更手段情報１２１が示す遷移先の状態に更新すればよい。また、状態探索部１２０は、例えば、依頼した変更手段情報１２１に対して状態遷移タスク、状態確認タスクいずれかが失敗した旨の変更結果１３１を受信した場合、疑似システムの現在状態をそのままとしてもよい。なお、状態探索部１２０は、例えば、状態遷移タスクまたは状態確認タスクが失敗した旨の変更結果１３１を受信した場合、確認手段情報１０３を基にシステムの現在状態を確認する処理を別途行い、システムの現在状態を特定してもよい。

また、状態遷移タスクの実行の成否により遷移後の状態を特定できる場合には、確認手段情報１０３の取得および状態確認処理を省略してもよい。

変更結果記憶部１４０は、全状態遷移情報１２２に示される全ての状態遷移に対する変更結果１３１を記憶する。変更結果記憶部１４０は、例えば、図１３に示すように、全状態遷移情報１２２の各行に確認結果を追記した情報を記憶してもよい。図１３は、変更結果記憶部１４０に記憶される情報の例を示す説明図である。

また、図１４は、変更結果記憶部１４０に記憶される情報の他の例を示す説明図である。図１４に示すように、変更結果記憶部１４０は、全状態遷移情報１２２とは異なる形式で、全状態遷移情報１２２に示される全ての状態遷移に対する変更結果１３１を記憶してもよい。なお、図１４には、遷移元状態と、状態遷移と、遷移後状態と、探索済みまたは未探索を示すフラグと、確認結果とを含む情報が示されている。なお、本例でも、確認結果の欄に変更結果１３１の内容が反映される。

依存関係算出部１５０は、変更結果記憶部１４０から全ての状態遷移に対する変更結果１３１を取得して、構成変更タスクと構成要素の状態間の依存関係を算出する。また、依存関係算出部１５０は、算出した依存関係を示す依存関係情報１５１を出力する。

依存関係情報１５１は、検証対象となった全ての構成変更タスクについて、他の構成要素の状態との依存関係を示す情報である。依存関係情報１５１は、例えば、図１５に示すように、変更対象とする構成要素（対象構成要素）のＭＩＤと、ＭＩＤが示す構成要素の状態遷移と、該状態遷移が有する依存関係すなわち該状態遷移において必要とされる他の構成要素の状態とを含んでいてもよい。図１５は、依存関係情報１５１の例を示す説明図である。

依存関係算出部１５０は、例えば、全状態遷移情報１２２に含まれるシステム状態の状態遷移パターンの中から、対象構成要素の状態遷移を行っているものを抽出し、抽出された全てのパターンにおいて状態遷移および状態確認の確認結果が正常であれば、該状態遷移を行う構成変更タスクが有する他の構成変更タスクとの間の依存関係はなしと判定してもよい。一方、依存関係算出部１５０は、抽出されたパターンの中に状態遷移もしくは状態確認の確認結果が異常のパターンが含まれている場合であって、対象構成要素以外の構成要素の遷移元の状態が異なるパターンで状態遷移および状態確認の確認結果が正常なものが含まれている場合、当該正常パターンと異常パターンとの遷移元状態を比較して、当該状態遷移に必要条件とされる他の構成要素の状態を算出し、それを依存関係としてもよい。

例えば、図１５には、ＭＩＤ＝１の構成要素を状態Ｆから状態Ｔへ遷移させる状態遷移が、ＭＩＤ＝２の構成要素およびＭＩＤ＝３の構成要素の状態に依存しないことが示されている。すなわち、当該状態遷移はＭＩＤ＝２および３の構成要素がどの状態であっても実行可能なことを表している。なお、図中の「＊」は任意状態すなわち対象の構成要素がいずれの状態でも遷移可能であることを表している。

また、例えば、図１５には、ＭＩＤ＝１の構成要素を状態Ｔから状態Ｆへ遷移させる状態遷移は、ＭＩＤ＝３の構成要素がどの状態であっても実行可能であるが、ＭＩＤ＝２の構成要素が状態Ｆでないと実行できないことが示されている。

本実施形態において、検証環境構築部１１０、状態探索部１２０、状態変更部１３０および依存関係算出部１５０は、例えばプログラムに従って動作するＣＰＵ等の情報処理装置によって実現される。また、変更結果記憶部１４０は、記憶装置によって実現される。

次に、本実施形態の動作を説明する。図１６は、本実施形態の依存関係抽出装置１００の動作の概要を示すフローチャートである。図１６に示す例では、まず依存関係抽出装置１００は、検証環境情報１０１と構成要素モデル情報１０２と確認手段情報１０３とを取得する（ステップＡ１１０）。

次に、依存関係抽出装置１００は、検証環境情報１０１を基に、検証環境構築部１１０を用いて検証環境を構築する（ステップＡ１２０）。

次に、依存関係抽出装置１００は、状態探索部１２０および状態変更部１３０を用いて状態探索を行い、変更結果記憶部１４０に、全ての状態遷移に対する変更結果１３１を記憶する（ステップＡ１３０）。

次に、依存関係抽出装置１００は、変更結果記憶部１４０に記憶されている変更結果１３１を基に、依存関係算出部１５０を用いて、構成変更タスクと構成要素の状態間の依存関係を算出する（ステップＡ１４０）。また、依存関係抽出装置１００は、算出した依存関係を示す依存関係情報１５１を出力する（ステップＡ１５０）。

図１７は、検証環境構築部１１０の動作の一例を示すフローチャートである。図１７に示す例では、まず検証環境構築部１１０は、検証環境情報１０１と構成要素モデル情報１０２と確認手段情報１０３とを取得する（ステップＢ１１０）。

次に、検証環境構築部１１０は、検証環境情報１０１、特にシステム構築手順情報を基に、検証環境である疑似システムを構築する（ステップＢ１２０）。例えば、図２に示す検証環境情報１０１を参照した場合、検証環境構築部１１０は、まず手順番号＝１に対応づけられている実行内容を実施する。より詳細には、検証環境構築部１１０は、基盤要素ＩＤ＝１の基盤要素であるクラウド基盤にアクセスして、基盤要素ＩＤ＝２の基盤要素である仮想マシンを起動する。

次に、検証環境構築部１１０は、システム状態の初期状態を確認するために、状態確認タスクを実行する（ステップＢ１３０）。検証環境構築部１１０は、例えば、確認手段情報１０３に含まれる全ての状態確認タスクを実行してもよい。例えば、図５に示す確認手段情報１０３の例では、確認Ｎｏ＝１、２および３の状態確認タスクを実行することにより、３つの構成要素モデルの状態確認を行うことができる。また、例えば、図６に示す確認手段情報１０３の例では、確認Ｎｏ＝１、２、３、４、５および６の状態確認タスクを実行することにより、３つの構成要素モデルの状態確認を行うことができる。図６の例によれば、確認Ｎｏ＝１、３および５のテストが成功した場合、判定基準によりＭＩＤ＝１、２、３の構成要素の状態が全てＦであることが分かる。

最後に、検証環境構築部１１０は、状態確認タスクを実行した結果得られたシステムの現在状態を初期状態として示す初期状態情報１１１を出力する（ステップＢ１４０）。

また、図１８は、状態探索部１２０の動作の一例を示すフローチャートである。図１８に示す例では、まず状態探索部１２０は、全状態遷移情報１２２を作成して変更結果記憶部１４０に必要な情報を記憶する（ステップＣ１１０）。このとき、状態探索部１２０は、全状態遷移情報１２２の各状態遷移に識別番号を付した上で、変更結果記憶部１４０に記憶してもよい。

以下では、ＭＩＤ＝１〜３の３つの構成要素が検証対象とされた場合を例に説明する。上記の図８および図９は、３つの構成要素を検証対象とした場合の全状態遷移情報１２２の一部を例示している。なお、図示省略しているが、各構成要素が２つの状態（ＦとＴ）を有する場合、システム状態は全部で８通り、システムの状態遷移は全部で２４通りとなる。

例えば、図９は、ＭＩＤ＝１、２、３の構成要素が検証対象となる場合の全ての状態遷移のうち、２つの遷移前状態（（ＭＩＤ＝１，ＭＩＤ＝２，ＭＩＤ＝３）＝（Ｆ，Ｆ，Ｆ），（Ｔ，Ｆ，Ｆ））が取り得る状態遷移を示している。なお、図９には、１つの遷移前状態に対して遷移先状態が３通りあることから、６つの状態遷移の情報が示されている。

全状態遷移情報１２２には、各状態遷移が未探索か否を示す情報が含まれる。なお、図８に示す例では、状態遷移タスクに対する確認結果によって当該状態遷移が未探索か否かが示されている。

次に、状態探索部１２０は、状態探索を開始する。状態探索部１２０は、より具体的には、全状態遷移情報１２２のうち疑似システムの現在状態に適用可能な状態遷移であって未探索の状態遷移があるか否かを判定する（ステップＣ１２０）。例えば、疑似システムの現在状態が図７に示す初期状態すなわち（ＭＩＤ＝１，ＭＩＤ＝２，ＭＩＤ＝３）＝（Ｆ，Ｆ，Ｆ）であった場合、図８に示す全状態遷移情報１２２から遷移前状態が上記の初期状態と一致している状態遷移の中から未探索の状態遷移（図中の１〜３行目に記載の状態遷移）が抽出される。

状態探索部１２０は、疑似システムの現在状態に適用可能でかつ未探索の状態遷移がある場合（ステップＣ１２０のＹｅｓ）、その中から一つの状態遷移を選択し、選択した状態遷移に対応する変更手段情報１２１を状態変更部１３０に送信する（ステップＣ１３０）。

例えば、図８に示す全状態遷移情報１２２の１行目が選択された場合、状態探索部１２０は、図９または図１０に示す変更手段情報１２１を状態変更部１３０に送信してもよい。当該変更手段情報１２１によれば、システムの現在状態（（ＭＩＤ＝１，ＭＩＤ＝２，ＭＩＤ＝３）＝（Ｆ，Ｆ，Ｆ））において、ＭＩＤ＝１の構成要素の状態をＦからＴに遷移させること、および遷移後の状態を確認するために確認手段情報１０３の確認Ｎｏ＝２、３、５の状態確認タスクの実行が指示されていることがわかる。

次に、状態探索部１２０は、変更結果１３１を受信する（ステップＣ１４０）。変更結果１３１を受信すると、状態探索部１２０は、変更結果記憶部１４０の全状態遷移情報１２２に受信した変更結果１３１の内容を反映する（ステップＣ１５０）。例えば、ステップＣ１４０で図１１に示す変更結果１３１を受信した場合、状態探索部１２０は、図１７に示す情報の１行目の探索フラグを探索済みに変更するとともに、確認結果に変更結果１３１の内容を追記してもよい。

また、状態探索部１２０は、ステップＣ１５０でシステムの現在状態を更新する。例えば、図１１に示す変更結果１３１を受信した場合、状態探索部１２０は、現在状態を（ＭＩＤ＝１，ＭＩＤ＝２，ＭＩＤ＝３）＝（Ｔ，Ｆ，Ｆ）に更新する。

状態探索部１２０は、現在のシステム状態に適用可能な適用可能な未探索の状態遷移がなくなるまでステップＣ１３０からステップＣ１５０までの動作を繰り返す。

一方、状態探索部１２０は、現在のシステム状態に適用可能な未探索の状態遷移がなくなった場合（ステップＣ１２０のＮｏ）、全ての状態遷移の探索が完了したか否かの判定を行う（ステップＣ１６０）。ステップＣ１６０で全ての状態遷移の探索が完了したと判定された場合（ステップＣ１６０のＹｅｓ）、状態探索部１２０は処理を終了する。

一方、ステップＣ１６０で全ての状態遷移の探索が完了していないと判定された場合（ステップＣ１６０のＮｏ）、状態探索部１２０は、続いてシステム状態を前の状態に戻せるか否かの判定を行う（ステップＣ１７０）。ここで、前の状態は、未探索な状態遷移における遷移前状態であればどの状態であるかは特に問わず、数回の状態遷移を経て遷移可能な状態も含まれる。状態探索部１２０は、例えば、前の状態に戻せるか否かを、全状態遷移情報１２２の遷移後状態に当該前の状態が存在しているか否かによって判定してもよい。

前の状態に戻せると判定した場合（ステップＣ１７０のＹｅｓ）、状態探索部１２０は、前の状態に戻すための変更手段情報１２１を作成し、状態変更部１３０に送信する（ステップＣ１８０）。一方、ステップＣ１７０で遷移前の状態に戻せないと判定した場合（ステップＣ１７０のＮｏ）、状態探索部１２０は処理を終了する。

図１９は、状態変更部１３０の動作の一例を示すフローチャートである。図１９に示す例では、まず状態変更部１３０は、変更手段情報１２１を取得する（ステップＤ１１０）。

次に、状態変更部１３０は、取得した変更手段情報１２１が示す状態遷移に対応する状態遷移タスク（構成変更タスク）を実行する（ステップＤ１２０）。ステップＤ１２０で、状態変更部１３０は、変更手段情報１２１が示す状態遷移に対応する状態遷移タスクを構成要素モデル情報１０２から検索して実行してもよい。例えば、図９に示す変更手段情報１２１を受信した場合、状態変更部１３０は、ＭＩＤ=１の構成要素を状態ＦからＴに遷移させるための状態遷移タスクを構成要素モデル情報１０２から検索する。そして、状態変更部１３０は、得られた状態遷移タスク「ａｐｔ ｉｎｓｔａｌｌ ａｐａｃｈｅ２」を実行すればよい。

次に、状態変更部１３０は、状態遷移タスクが成功したか否かを判定する（ステップＤ１３０）。状態遷移タスクが成功した場合（ステップＤ１３０のＹｅｓ）、状態変更部１３０は、続いて状態確認タスクを実行する（ステップＤ１４０）。状態変更部１３０は、例えば、確認手段情報１０３から変更手段情報１２１が示す確認Ｎｏに対応する状態確認タスクを検索し、得られた状態確認タスクを実行すればよい。

最後に、状態変更部１３０は、状態遷移タスクおよび状態確認タスクの実行結果を示す変更結果１３１を状態探索部１２０に送信して処理を終了する（ステップＤ１５０）。

一方、状態変更部１３０は、状態遷移タスクが失敗した場合（ステップＤ１３０のＮｏ）、その旨を示す変更結果１３１を状態探索部１２０に送信して処理を終了する（ステップＤ１５０）。

図２０は、依存関係算出部１５０の動作の一例を示すフローチャートである。図２０に示す例では、まず依存関係算出部１５０は、変更結果記憶部１４０から全ての状態遷移に対する変更結果１３１を取得する（ステップＥ１１０）。

次に依存関係算出部１５０は、取得した変更結果１３１を参照し、各状態遷移に対応する構成変更タスクの依存関係を算出する（ステップＥ１２０）。

例えば、変更結果記憶部１４０に図１３に示す情報が記憶されていた場合、依存関係算出部１５０は、ＭＩＤ＝１の構成要素を状態ＴからＦへ遷移させる状態遷移は、ＭＩＤ=２の構成要素の状態がＦでないと正しく遷移できないとする前提条件を算出できる。したがって、依存関係算出部１５０は、当該状態遷移に対応する構成変更タスクの依存関係として、ＭＩＤ＝２：Ｔを示す依存関係情報１５１を生成する。この場合、ＭＩＤ＝３の構成要素はどの状態であってもよい。

また、例えば、変更結果記憶部１４０に図１３に示す情報が記憶されていた場合、依存関係算出部１５０は、ＭＩＤ＝２の構成要素を状態ＦからＴへ遷移させる状態遷移は、ＭＩＤ=１および３の構成要素の状態がともにＴでないと正しく遷移できないとする前提条件を算出できる。したがって、依存関係算出部１５０は、当該状態遷移に対応する構成変更タスクの依存関係として、ＭＩＤ＝１：ＴおよびＭＩＤ＝３：Ｔを示す依存関係情報１５１を生成する。

以上のように、本実施形態によれば、実環境でエラーを起こさずに、システム構築手順を生成する際に利用する構成変更タスクと構成要素の状態間の依存関係を抽出できる。

すなわち、本実施形態の依存関係抽出装置１００は、人手を介さずに、検証環境情報１０１と構成要素モデル情報１０２と確認手段情報１０３とを基に、検証対象とされる全ての構成変更タスクについて、当該タスクを実行可能な構成要素の状態を示す依存関係情報１５１を提供できる。

より詳細には、本実施形態の依存関係抽出装置１００は、検証環境構築部１１０が、検証環境情報１０１を基に検証環境を構築する。そして、状態探索部１２０が、構成要素モデル情報１０２と確認手段情報１０３とを基に、状態変更部１３０と協調して依存関係抽出装置１００で対象となるシステム構成変更タスクについて、取り得るシチュエーション全てで実行可能でかつ期待した通りの振る舞いをするかの検査を行い、その検証結果をデータベース（変更結果記憶部１４０）に記憶する。そして、依存関係算出部１５０が、このデータベースを参照して依存関係情報１５１を作成して出力する。

このように、依存関係抽出装置１００は、検証環境を用いて対象とされる構成変更タスクが取り得るシチュエーション全てで動作確認を行い、その結果に基づいて、各構成変更タスクが有する構成要素の状態に関する依存関係を算出する。このため、依存関係抽出装置１００は、構成変更タスク間または構成変更タスクと構成要素の状態間の依存関係を正しく、かつ容易に抽出できる。

なお、構成変更タスクと構成要素の状態間の依存関係が抽出されれば、それを基に、対象とされる構成変更タスク間の依存関係を抽出できる。例えば、第１の構成変更タスクについて、前提条件としてある構成要素の状態がＦであることを必要とする旨の依存関係が抽出された場合、第１の構成変更タスクが、その構成要素を他の状態から状態Ｆに遷移させる第２の構成変更タスクより後に実行される旨の依存関係を抽出できる。

また、例えば、システム構築手順が先に与えられる場合には、本実施形態の依存関係抽出装置１００が、抽出された依存関係に基づいて、その手順に含まれる構成変更タスクの順序関係において、前提条件が整っているか否かを判定することも可能である。そして、前提条件が整っていない構成変更タスクがあった場合に、順序の入れ替え、新たな構成変更タスクの追加等を行うことも可能である。

また、上記の例では、検証対象とする構成変更に対応する構成要素の状態および状態遷移が予め定義されていることを前提に、検証対象とする構成変更タスクを状態遷移タスクに限定したが、検証対象とするタスクは、状態遷移タスクに限定されない。例えば、状態遷移を伴わない構成変更タスクが検証対象に含まれていてもよい。その場合、状態探索部１２０は、構成要素の状態の組み合わせにより定義されるシステム状態が取り得る全てのパターンにおいて、検証対象とする全ての構成変更タスクを実行し、その結果を取得すればよい。その場合、状態探索部１２０は、全状態遷移情報１２２に代えて、システム状態が取り得る全てのパターンの各々と、検証対象とする構成変更タスクの各々とを対応づけた情報を生成してもよい。また、変更結果記憶部１４０は、該情報に対して確認結果を追記するなどして、システム状態が取り得る全てのパターンの各々における各構成変更タスクの実行結果を記憶すればよい。なお、依存関係抽出装置１００は、構成要素モデル情報１０２とは別に、検証対象とする構成変更タスクの情報を取得してもよい。

次に、本発明の概要を説明する。図２１は、本発明の概要を示すブロック図である。図２１に示すように、本発明によるシステム構築支援システムは、タスク確認手段５０１と、依存関係算出手段５０２とを備えている。

タスク確認手段５０１（例えば、状態探索部１２０および状態変更部１３０）は、検証対象とする構成変更タスクを示す情報と、対象システムの各構成要素が取り得る状態を示す情報と、各構成要素が状態間を遷移するための状態遷移タスクを示す情報とを入力として、対象システムと同じ動作をする疑似システムの状態を変化させて構成変更タスクを実行することにより、対象システムが取り得る全てのシステム状態における構成変更タスクの実行結果を取得する。

また、依存関係算出手段５０２（例えば、依存関係算出部１５０）は、タスク確認手段５０１による実行結果に基づいて、構成変更タスクの各々が有する依存関係を算出し、算出された依存関係を示す情報を出力する。

このような構成により、網羅的に構成変更タスクの実行結果を疑似システムによる動作検証により得ることができるので、構成変更タスク間または構成変更タスクと構成要素の状態間の依存関係を正しく抽出できる。

また、図２２は、本発明のシステム構築支援装置の他の構成例を示すブロック図である。図２２に示すように、本発明のシステム構築支援装置は、さらに検証環境構築手段５０３を備えていてもよい。

検証環境構築手段５０３（例えば、検証環境構築部１１０）は、所定の環境に疑似システムを構築する手順を示す検証環境情報を入力として、所定の環境に疑似システムを構築する。そのような場合、タスク確認手段５０１は、検証環境構築手段５０３が構築した疑似システムにアクセスして構成変更タスクを実行してもよい。

また、タスク確認手段５０１は、対象システムの各構成要素が取り得る状態を示す情報を基に、対象システムのシステム状態を定義し、状態遷移タスクを用いて疑似システムの状態を対象システムのシステム状態に追従するように遷移させ、遷移先の各々で適用可能な構成変更タスクを実行することにより、対象システムが取り得る全てのシステム状態における構成変更タスクの実行結果を取得してもよい。

また、検証対象とする構成変更タスクが全て状態遷移タスクである場合には、タスク確認手段５０１は、疑似システムの状態を遷移させる際の状態遷移タスクを構成変更タスクとして実行してもよい。

また、タスク確認手段５０１は、構成要素の状態を確認する状態確認タスクおよび状態確認タスクの実行結果を用いた構成要素の状態の判定基準を示す情報をさらに入力とし、構成変更タスクの実行後に状態確認タスクを実行して、その結果を取得してもよい。そのような場合、依存関係算出手段５０２は、構成変更タスクおよび状態確認タスクの実行結果に基づいて、構成変更タスクの各々が有する依存関係を算出してもよい。

また、図２２に示すように、タスク確認手段５０１は、対象システムの各構成要素が取り得る状態を示す情報を基に、対象システムのシステム状態を定義し、対象システムのシステム状態に追従するように疑似システムの状態を管理する状態管理手段５１１（例えば、状態探索部１２０）と、状態管理手段５１１からの指示に従い、疑似システム上で状態遷移タスクの実行および／または構成変更タスクの実行を行い、結果を取得するタスク実行手段５１２（例えば、状態変更部１３０）とを含んでいてもよい。

以上、本実施形態および実施例を参照して本願発明を説明したが、本願発明は上記実施形態および実施例に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

この出願は、２０１６年１１月１日に出願された日本特許出願２０１６−２１４４０３を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明は、システム構築手順を作成する際に限らず、構成要素の状態遷移を伴う構成変更タスクを利用する全ての用途に好適に利用できる。

１００ 依存関係抽出装置
１０１ 検証環境情報
１０２ 構成要素モデル情報
１０３ 確認手段情報
１１０ 検証環境構築部
１１１ 初期状態情報
１２０ 状態探索部
１２１ 変更手段情報
１２２ 全状態遷移情報
１３０ 状態変更部
１３１ 変更結果
１４０ 変更結果記憶部
１５０ 依存関係算出部
１５１ 依存関係情報
５０１ タスク確認手段
５０２ 依存関係算出手段
５０３ 検証環境構築手段
５１１ 状態管理手段
５１２ タスク実行手段

Claims (10)

1. 検証対象とする構成変更タスクを示す情報と、対象システムの各構成要素が取り得る状態を示す情報と、各構成要素が前記状態間を遷移するための状態遷移タスクを示す情報とを入力として、前記対象システムと同じ動作をする疑似システムの状態を変化させて前記構成変更タスクを実行することにより、前記対象システムが取り得る全てのシステム状態における前記構成変更タスクの実行結果を取得するタスク確認手段と、
   前記実行結果に基づいて、前記構成変更タスクの各々が有する依存関係を算出し、算出された依存関係を示す情報を出力する依存関係算出手段とを備えた
   ことを特徴とするシステム構築支援装置。
2. 所定の環境に前記疑似システムを構築する手順を示す検証環境情報を入力として、前記所定の環境に前記疑似システムを構築する検証環境構築手段を備えた
   請求項１に記載のシステム構築支援装置。
3. 前記タスク確認手段は、前記対象システムの各構成要素が取り得る状態を示す情報を基に、前記対象システムのシステム状態を定義し、状態遷移タスクを用いて前記疑似システムの状態を前記対象システムのシステム状態に追従するように遷移させ、遷移先の各々で適用可能な構成変更タスクを実行することにより、前記対象システムが取り得る全てのシステム状態における前記構成変更タスクの実行結果を取得する
   請求項１または請求項２に記載のシステム構築支援装置。
4. 検証対象とする構成変更タスクが全て状態遷移タスクであり、
   前記タスク確認手段は、前記疑似システムの状態を遷移させる際の状態遷移タスクを構成変更タスクとして実行する
   請求項３に記載のシステム構築支援装置。
5. 前記タスク確認手段は、構成要素の状態を確認する状態確認タスクおよび前記状態確認タスクの実行結果を用いた構成要素の状態の判定基準を示す情報をさらに入力とし、構成変更タスクの実行後に前記状態確認タスクを実行して、その結果を取得し、
   前記依存関係算出手段は、構成変更タスクおよび状態確認タスクの実行結果に基づいて、前記構成変更タスクの各々が有する依存関係を算出する
   請求項１から請求項４のうちのいずれか１項に記載のシステム構築支援装置。
6. 前記タスク確認手段は、
   前記対象システムの各構成要素が取り得る状態を示す情報を基に、前記対象システムのシステム状態を定義し、前記対象システムのシステム状態に追従するように前記疑似システムの状態を管理する状態管理手段と、
   前記状態管理手段からの指示に従い、前記疑似システム上で状態遷移タスクの実行および／または構成変更タスクの実行を行い、結果を取得するタスク実行手段とを含む
   請求項１から請求項５のうちのいずれか１項に記載のシステム構築支援装置。
7. 検証対象とする構成変更タスクを示す情報と、対象システムの各構成要素が取り得る状態を示す情報と、各構成要素が前記状態間を遷移するための状態遷移タスクを示す情報とが入力されると、前記対象システムと同じ動作をする疑似システムの状態を変化させて前記構成変更タスクを実行することにより、前記対象システムが取り得る全てのシステム状態における前記構成変更タスクの実行結果を取得し、
   前記実行結果に基づいて、前記構成変更タスクの各々が有する依存関係を算出し、算出された依存関係を示す情報を出力する
   ことを特徴とするシステム構築支援方法。
8. 所定の環境に前記疑似システムを構築する手順を示す検証環境情報が入力されると、前記検証環境情報に基づいて、前記所定の環境に前記疑似システムを構築し、
   前記疑似システムにアクセスして構成変更タスクを実行する
   請求項７に記載のシステム構築支援方法。
9. コンピュータに、
   検証対象とする構成変更タスクの情報と、対象システムの各構成要素が取り得る状態の情報と、各構成要素が前記状態間を遷移するための状態遷移タスクの情報とを入力として、前記対象システムと同じ動作をする疑似システムの状態を変化させて前記構成変更タスクを実行することにより、前記対象システムが取り得る全てのシステム状態における前記構成変更タスクの実行結果を取得する処理、および
   前記実行結果に基づいて、前記構成変更タスクの各々が有する依存関係を算出し、算出された依存関係を示す情報を出力する処理
   を実行させるためのシステム構築支援プログラム。
10. コンピュータに、
    所定の環境に前記疑似システムを構築する手順を示す検証環境情報を入力とし、前記所定の環境に前記疑似システムを構築する処理を実行させ、
    構成変更タスクの実行結果を取得する処理で、前記疑似システムにアクセスして構成変更タスクを実行させる
    請求項９に記載のシステム構築支援プログラム。

Images