JP6673358B2 - システム変更支援システム、情報処理装置、システム変更支援方法およびプログラム - Google Patents

Description

本発明は、システムの変更を支援するシステム変更支援システム、情報処理装置、システム変更支援方法およびシステム変更支援プログラムに関する。

一般的にシステムの変更は、システムの管理者がシステムを構成する部品の状態を要求通りの状態に変更する手順書を作成し、変更作業者が手順書に沿って変更作業を実行することにより実施される。全ての変更作業を正しく完了するためには、各変更作業は正しい順序で実行される必要がある。変更作業の順序性は、システムを構成する部品（以下、システム構成部品または単に部品という）の特性や組み合わせによって多様に変化する。そのため、手順書を正しく記述するためには当該システムおよび部品に関する深い理解が必要であり、高度な専門技術と膨大な時間を要する。

部品の状態を変更する変更手順に関する要件を、状態要素および状態要素間の依存関係によって形式的に表現するための手法がある。ここで、状態要素は、あるシステム構成部品といった所定の対象の状態および状態の変更方法に関する情報をひとまとめにした情報群である。状態要素の一例としては、状態要素を識別する識別子（以下、ｉｄという）と、対象に関し、取り得る状態、それら状態間の実施可能な状態遷移、現在状態および要求状態とからなる例が挙げられる。なお、状態要素のｉｄは、当該状態要素の対象を、そのような状態および状態の変更方法に関する情報を有する対象を識別するためのｉｄとして捉えることも可能である。

図２２は、ある状態要素“e”の概念図である。図中の“e”は当該状態要素のｉｄを表している。また、“s1”、“s2”は、当該状態要素において対象が取り得る状態を表している。“t1”、“t2”は、当該状態要素において対象が取り得る状態間の実施可能な状態遷移を表している。また、さらに“s1”は現在状態を表し、“s2”は要求状態を表している。

本明細書では図２２に示すように、状態要素全体を角丸長方形で表す。また、取り得る状態を楕円形で表す。また、実施可能な状態遷移を状態間の実線の矢印で表す。また、現在状態を二重線の楕円で表す。また、要求状態を黒塗りの楕円で表す。図２２に示される状態要素は、対象“e”を、状態“s1”から状態“s2”に変更する変更要求を表現しているとみなすことができる。なお、このような変更要求を表現した状態要素に基づいて変更手順を生成する変更手順生成系を用いれば、当該状態要素から状態遷移“t1”に必要な作業を含む変更手順を導出することができる。

協働関係にある複数の対象のいずれかの対象を変更するような場合には、各対象の状態要素間に依存関係を定義することにより、正しい変更手順を導出できる。

図２３は、複数の状態要素に基づくシステムの変更要件の表現例を示す図である。図２３では、ミドルウェア（ＭＷ）を起動させるために必要なシステムの変更要件を、２つの状態要素を用いて表現している。例えば、対象システムは、仮想マシン（ＶＭ）と、ＶＭにインストールされたミドルウェア（ＭＷ）とを含む。ＶＭを対象とした状態要素のｉｄを“ＶＭ”、ＭＷを対象とした状態要素のｉｄを“ＭＷ”とする。状態要素“VM”および状態要素“MW”において、状態“F”は停止状態を表し、状態“T”は稼動状態を表している。図２３に示されるように、ＶＭにおける状態“F”から状態“T”への遷移は、当該ＶＭの起動処理“boot”を経て行われる。また、ＶＭにおける状態“T”から状態“F”への遷移は、当該ＶＭの停止処理“stop”を経て行われる。また、ＭＷにおける状態“F”から状態“T”への遷移は、当該ＭＷのサービスの起動処理“start”を経て行われる。また、ＭＷにおける状態“T”から状態“F”への遷移は、当該ＭＷのサービスの停止処理“stop”を経て行われる。

ここで、ＭＷはＶＭ上にインストールされているため、ＭＷのサービスを起動したり停止したりするためにはＶＭが起動している必要がある。したがって、ＶＭが停止状態でありながらＭＷの状態遷移を実施する手順は誤りであることが分かる。このような変更における制約条件を定義するため、図２３では状態要素“MW”の状態遷移“start”および状態遷移“stop”に対して、状態要素“VM”の状態“T”への依存性を定義している。

上述したような変更手順生成系を用いれば、そのような依存性を満たしつつ所望の対象の状態を現在状態から要求状態に変更させるための変更順序を導出できる。図２３の例では、まずＶＭの状態を“F”から“T”に変更してから、ＭＷの状態を“F”から“T”に変更する手順が導出される。より具体的には、ＶＭの状態を“F”から“T”に変更するための状態遷移処理であるＶＭの起動（“boot”）の後に、ＭＷの状態を“F”から“T”に変更するための状態遷移処理であるＭＷの起動（“start”）が実施されるような変更手順が自動的に導出される。

以上のような状態要素に基づくシステムの変更手順の導出手法は、例えば、非特許文献１に開示されている。

S.Hagen and A.Kemper, "Model-based planning for state-relatedchanges to infrastructure and software as a service instances in largedata centers", in Cloud Computing(CLOUD), 2010 1EEE 3rd InternationalConference on, July 2010, p.11-18.

しかし、上述したような変更手順の導出手法は、状態の変化すなわち現在状態と要求状態の異なりに基づいて状態遷移を導出し、導出された状態遷移に基づいて変更手順を導出する。このため、設定値だけが異なるようなシステムの変更要求に対しては、期待した変更手順を導出できない問題がある。

例えば、上述した状態要素“e”の例において、変更前の状態が“s1”で、そのときのある設定項目の値が“p1”であったとする。状態は“s1”のままでこの設定項目の値を“p2”に変更するための変更要求を行っても、変更前後の状態がともに“s1”であるため状態遷移が導出されず、したがって所望する変更手順も導出されない。ここで、所望する変更手順は、例えば、「設定情報のリロード」といった処理を含む手順である。

以下、このようなシステムの部品における追加的な設定にかかる、状態要素に基づく変更手順の導出について具体的な例を用いて考える。例えば、Ｗｅｂサーバソフトウェアの１つである“Ａｐａｃｈｅ”は、リクエストを受け付けるポート番号を、８０番や８０８０番などの任意の番号に変更できる。そのため、状態要素に基づくシステムの変更手順の導出機能においても、システムの管理者が指定した特定のポート番号を用いてＡｐａｃｈｅを起動させるといった制御機能が求められる。

このような制御機能を実現するために、例えば、状態要素にさらに設定値の情報を含ませ、このような設定値に対応した状態要素により示される状態遷移によって、必要な処理の内容を導出させるといった仕組みが考えられる。例えば、Ａｐａｃｈｅに対応した状態要素に、起動（“T”）と、停止（“F”）という２つの状態とともに、設定値としてポート番号を含ませる。そして、「指定されたポート番号でＡｐａｃｈｅを起動する処理」を状態“F”から状態“T”への状態遷移と関連付ける。このような仕組みにより、例えばシステムの管理者がＡｐａｃｈｅの要求状態に、一旦“F”を指定した上で、再度新たなポート番号の情報とともに要求状態に“T”を指定することで、新たなポート番号でＡｐａｃｈｅを起動する処理が自動的に導出できる。しかし、一旦停止状態を要求する方法は、本来であればリロード処理のみで済むところを、必要でない停止処理が実行されることになり、好ましくない。

なお、一旦“F”を指定しない場合、変更前の状態が“T”であって、変更後の状態も“T”であるため、上記の方法では状態遷移が導出されない。

この問題を回避するためには、例えば、指定した設定項目が取り得る値（設定値）の全てのバリエーションを、取り得る状態として表現する手法が考えられる。図２４は、実際にとり得る状態と設定値の組を、対象が取り得る状態（以下、要素状態という場合がある）として定義した状態要素の例を示す図である。

図２４における状態要素“e”が対象とする部品は、本来の取り得る状態として“s1”と“s2”とを持つ。また、設定値として“p1”と“p2”とを持つ。このような場合に、要素状態として、状態“s1,p1”、状態“s1,p2”、状態“s2,p1”、状態“s2,p2”という４つの状態が定義される。これにより、設定値の違いが状態の違いと同様に扱われることになり、例えば設定値のみが異なる変更要求であっても、状態“s1,p1”から状態“s1,p2”への状態遷移等として認識でき、その状態遷移に関連づけられた「設定値のリロード」処理等を導出することができる。

しかし、設定値は一般に連続値であり、取り得る値のバリエーションは膨大である。例えば、Ａｐａｃｈｅの例では、ポート番号は０から６５５３５までの任意の整数が選択可能である。そのため、状態要素において状態と設定値の組を新たな状態として定義する方法では、膨大の数の要素状態を定義しなければならず、実用が非常に困難である。

そこで、本発明は、変更可能性のある項目の値のみが異なる変更要求であっても、正しく処理することが可能なシステム変更支援システム、情報処理装置、システム変更支援方法およびシステム変更支援プログラムを提供することを目的とする。

本発明によるシステム変更支援システムは、取り得る値の個数が有限または所定値未満の離散値である第１項目の値と、取り得る値の個数が所定値以上の連続値または離散値である第２項目の値の組により構成される２つのベクトルであって、一方を比較対象とし、他方を被比較対象とする２つのベクトルの比較を行い、２つのベクトルの第１項目の値が一致し、第２項目の値が異なる場合に、比較対象のベクトルの第１項目の値を変更する値再定義手段を備えたことを特徴とする。

本発明による情報処理装置は、取り得る値の個数が有限または所定値未満の離散値である第１項目の値と、取り得る値の個数が所定値以上の連続値または離散値である第２項目の値の組により構成される２つのベクトルであって、一方を比較対象とし、他方を被比較対象とする２つのベクトルの比較を行い、２つのベクトルの第１項目の値が一致し、第２項目の値が異なる場合に、比較対象のベクトルの第１項目の値を変更する値再定義手段を備えたことを特徴とする。

本発明によるシステム変更支援方法は、情報処理装置が、取り得る値の個数が有限または所定値未満の離散値である第１項目の値と、取り得る値の個数が所定値以上の連続値または離散値である第２項目の値の組により構成される２つのベクトルであって、一方を比較対象とし、他方を被比較対象とする２つのベクトルの比較を行い、２つのベクトルの第１項目の値が一致し、第２項目の値が異なる場合に、比較対象のベクトルの第１項目の値を変更することを特徴とする。

本発明によるシステム変更支援プログラムは、コンピュータに、取り得る値の個数が有限または所定値未満の離散値である第１項目の値と、取り得る値の個数が所定値以上の連続値または離散値である第２項目の値の組により構成される２つのベクトルであって、一方を比較対象とし、他方を被比較対象とする２つのベクトルの比較を行い、２つのベクトルの第１項目の値が一致し、第２項目の値が異なる場合に、比較対象のベクトルの第１項目の値を変更する処理を実行させることを特徴とする。

本発明によれば、変更可能性のある項目の値のみが異なる変更要求であっても、正しく処理することができる。

第１の実施形態のシステム変更支援システムの構成例を示すブロック図。 指示状態要素の生成処理の概念を示す図。 状態要素定義の例を示す図。 テキスト形式による状態要素定義の例を示す図。 テキスト形式による現在状態要素の例を示す図。 テキスト形式による指示状態要素の例を示す図。 Ａｐａｃｈｅを対象部品とする、状態要素定義の例を示す図。 Ａｐａｃｈｅを対象部品とする、テキスト形式による状態要素定義の例を示す図。 Ａｐａｃｈｅを対象部品とする現在状態要素の例を示す図。 Ａｐａｃｈｅを対象部品とする、テキスト形式による現在状態要素の例を示す図。 Ａｐａｃｈｅを対象部品とする、変更要求後の現在状態要素の例を示す図。 Ａｐａｃｈｅを対象部品とする、テキスト形式による変更要求後の現在状態要素の例を示す図。 Ａｐａｃｈｅを対象部品とする指示状態要素の例を示す図。 テキスト形式によるＡｐａｃｈｅの指示状態要素の例を示す図。 状態管理システム１００における指示状態要素の導出フローの一例を示すフローチャート。 状態比較計算部１２０の比較処理のフローチャート。 再定義後の現在状態要素の例を示す図。 状態要素内の全ての再解釈先の状態が一致している状態要素の図。 図１８の状態要素をテキスト形式により表現した図。 本発明の概要を示すブロック図。 本発明のシステム変更支援システムの他の構成例を示す図。 状態要素の概念図。 複数の状態要素に基づくシステムの変更要件の表現例を示す図。 状態と設定値の組を要素状態として定義した状態要素の例を示す図。

以下、本発明の実施形態について図面を参照して説明する。図１は、第１の実施形態の構成例を示すブロック図である。図１に示されるように、本実施形態のシステム変更支援システム１０は、状態管理システム１００と、状態要素入出力部２００とを備える。

また、状態管理システム１００は、状態要素記憶部１１０と、状態比較計算部１２０とを含む。状態比較計算部１２０は、状態要素入出力部２００と、直接またはネットワークなどを介して間接的に接続されている。なお、状態比較計算部１２０と状態要素入出力部２００とは通信可能に接続されていればよい。

また、状態比較計算部１２０は、現在状態再定義部１２１と、変更要求生成部１２２とを有する。

本実施形態において、状態要素記憶部１１０は、例えば、記憶装置によって実現される。また、状態比較計算部１２０（より具体的には、現在状態再定義部１２１と、変更要求生成部１２２）は、例えば、プログラムに従って動作するＣＰＵ等によって実現される。

状態要素記憶部１１０は、対象システムにおいて変更の対象とされる部品と、その部品に関連する値であって変更可能性のある値を保持する任意の項目（以下、変化項目という）との組を対象として、当該対象の状態要素に含まれる情報要素のうちの少なくとも一部の情報要素を記憶する。ここで、変更可能性は、必ずしも外部から直接変更が可能という意味に限定されない。すなわち、システム内部で何らかの事象に連動して自動的に値が変動するような場合も含まれる。状態要素記憶部１１０が記憶する状態要素の情報要素は、例えば、状態要素の識別子（これは、当該状態要素によって示される対象の識別子でもある）と、対象に関して、取り得る状態、それら状態間の実施可能な状態遷移、現在状態とであってもよい。なお、状態要素記憶部１１０は、状態要素の情報要素のうち、固定的な情報要素のみを集めた情報を状態要素定義として保持してもよく、さらに、現在状態を、対応する状態要素の識別子に対応づけて保持してもよい。

一般に、状態要素は、異なる３つのフェーズにおいて定義される情報から構成されている。すなわち、対象が取り得る状態や、実施可能な状態遷移は、対象の特性によって決まる固定的な情報であり、対象の仕様が変更されない限り変更されることはない。このため、当該対象の状態要素を生成する際に定義すればよい。一方、現在状態と要求状態は、対象とされるシステム構成部品の状況や管理者の要求に合わせて変化する情報要素である。なお、要求状態はシステムの管理者などによって変更要求時に定義される。また、現在状態はシステム構成部品の状況によっても変化するし、変更作業の実施によっても変化するといったように、都度更新されながら継続的に管理される。したがって、定義されるフェーズが異なる情報を分けて保持した方が管理しやすいだけでなく、処理の効率化にもなる。

本実施形態では、状態要素を、固定的な情報からなる状態要素定義と、現在状態を示す情報と、要求状態を示す情報とに分ける。そして、変更手順生成系に渡す状態要素については、上記３つの情報を合成することで生成する。以下、状態要素としての現在状態を示す情報を「現在状態要素」という場合がある。また、状態要素としての要求状態を示す情報を「要求状態要素」という場合がある。また、変更手順生成系に渡す状態要素を「指示状態要素」という場合がある。

図２は、指示状態要素の生成処理の概念図である。図２の上段左は、状態要素の対象の変更前の状態を表した状態要素（現在状態要素）を表している。また、図２の上段右は、対象の変更後の状態を表した状態要素（要求状態要素）を表している。また、図２の下段は、変更手順生成系への変更要求を表す状態要素（指示状態要素）を表している。図２に示すように、変更前の状態が“s1”で変更後の状態が“s2”である場合、指示状態要素は、とり得る状態や状態遷移の情報の他、現在状態として“s1”を含み、要求状態として“s2”を含めばよい。なお、指示状態要素において取り得る状態は必須要素ではなく、例えば、現在状態と要求状態とそれらの間の状態遷移だけが定義されていれば足りる場合がある。

本実施形態において、現在状態要素は、対象のｉｄと、現在の要素状態を判別するための情報としての現在の状態と変化項目の組、とを含む情報であってもよい。また、要求状態要素は、対象のｉｄと、要求状態すなわち変更後の状態を判別するための情報としての変更後の状態と変化項目の組、とを含む情報であってもよい。また、指示状態要素は、対象のｉｄと、現在の要素状態と、変更後の要素状態とを含む情報であってもよい。本実施形態において、状態要素の「対象」といった場合には、当該状態要素に含まれる状態および状態の変更方法に関する情報を有する対象を指す。より具体的には、部品の正規の状態と、任意の変化項目との組によって識別される対象を指す。

状態比較計算部１２０は、状態要素記憶部１１０に記憶されている情報（状態要素定義および現在状態要素）と、状態要素入出力部２００から受け付けた要求状態要素とに基づいて、指示状態要素を生成する。なお、状態比較計算部１２０内における処理の詳細は後述する。

状態要素入出力部２００は、状態要素の入出力を行う。状態要素入出力部２００は、例えば、利用者または他の装置が定義した状態要素定義や、対象システムの状態を管理する状態システム（図示せず）が生成した現在状態要素や、利用者や状態システムが定義した要求状態要素を受け付けたり、状態管理システム１００が生成した指示状態要素を出力する。

本実施形態では、状態管理システム１００が、状態変更前後での状態要素、すなわち現在状態要素と要求状態要素とを比較し、指示状態要素を生成する。

本実施形態における状態要素定義は、ｉｄ、対象の取り得る要素状態、要素状態間の遷移、および対象とした変化項目に関する情報を含む。また、指示状態要素は、ｉｄ、対象の現在の要素状態、要求後の要素状態、および当該状態遷移にかかる処理に関する情報を含む。なお、要素状態といった場合には、正規の状態と、後述する再解釈により生じる状態とを特に区別なく指すものとする。

ここで、本実施形態の状態遷移には、変更要求により生じる遷移と、現在の状態の再解釈により生じる遷移とが存在する。なお、要素状態間の遷移といった場合には、上記の両方の遷移を特に区別なく指すものとする。

図３は、状態要素定義の例を示す図である。状態要素定義は、既に説明したように、状態要素のうち対象の特性により固定的に定める情報からなる情報群である。図３において、当該状態要素定義によって定義される状態要素を角丸長方形で表す。また、角丸長方形の左上に位置する長方形は、当該状態要素定義のｉｄすなわち対象のｉｄを表す。また、角丸長方形の右上に位置する長方形は対象が対応する変化項目（本例では該変化項目の名称）を表す。また、角丸長方形内の楕円形は、対象が取り得る要素状態を表す。また、実線の矢印は、変更要求により生じる要素状態間の遷移を表す。また、二重線の矢印は、現在の要素状態の再解釈により生じる要素状態間の遷移を表す。なお、本例では、正規の状態が“s1”である場合に、再解釈により生じる状態を“s'1”というように、“’”を付けて表現している。

図３によれば、対象“e”は、対象とした変化項目として“para1”を有していること、および取り得る（正規の）状態として、“s1”と“s2”を有することがわかる。その上で、正規の状態である“s1”および“s2”のそれぞれの再解釈先の状態として“s'1”および“s'2”が定義されている。したがって、対象“e”は、要素状態として、“s1”、“s2”、“s'1”、“s'2”の４つの状態を有していることがわかる。

また、要素状態間の遷移としては、“s1”から“s2”の遷移を表す“t1”、“s2”から“s1”の遷移を表す“t2”、“s'1”から“s1”の遷移を表す“t3”、“s'2”から“s2”の遷移を表す“t4”、“s'1”から“s2”の遷移を表す“t5”、“s'2”から“s1”の遷移を表す“t6”、“s1”から“s'1”の遷移を表す“r1”、“s2”から“s'2”の遷移を表す“r2”が定義されている。本例において、遷移“tX”（ただし、Ｘ＝１〜６）が、変更要求による遷移に相当し、遷移“rX”（ただし、Ｘ＝１〜２）が、再解釈により生じる遷移に相当する。なお、正規の状態から当該正規の状態に対応する再解釈後の状態への遷移（例えば、“s1”から“s'1”への遷移等）が、再解釈により生じる遷移であり、それ以外の遷移（例えば、正規の状態から正規の状態への遷移、ある正規の状態に対応する再解釈後の状態から他の正規の状態への遷移等）は、すべて変更要求による遷移である。

また、図４は、図３に示した状態要素定義をテキスト形式により表現した図である。ここでは、ＪＳＯＮ形式を用いた例を示している。図４において、“状態要素型”項目は、当該テキストが情報要素定義のテキストデータであることを表している。本例では、“状態要素型”項目は、さらに“型名”、“取り得る状態”、“再解釈”、“変化項目”、“状態遷移”の５つの項目を含む。

ここで、“型名”は、当該状態要素定義のｉｄとしての名称を表している。なお、本実施形態においても、状態要素定義のｉｄには、当該状態要素定義の対象のｉｄとしての意味が含まれている。また、“取り得る状態”は、当該状態要素定義の対象が取り得る状態を表している。ここで、当該状態要素定義の対象が取り得る状態は、上記の要素状態に相当する。すなわち、再解釈により生じる状態も含まれる。なお、“取り得る状態”項目には、図４に示すように、要素状態の識別子が定義されていてもよい。

また、“再解釈”は、正規の状態群に対して再解釈により生じる状態に関する情報を表している。本例の“再解釈”項目は、さらに“id”、“from”、“to”、“処理”という４つの項目を有する。“id”は、当該再解釈により発生する状態への状態遷移の識別子を表わしている。“from”は、再解釈される前の対象の現在状態（正規状態）を表している。“to”は、再解釈後に移行する対象の現在状態（再解釈状態）を表している。“処理”は、遷移条件、すなわち再解釈により対象の現在状態が“from”で示された状態から“to”で示された状態に遷移する際に行う遷移処理を表している。なお、“処理”項目には、遷移処理と対応づけられた状態遷移の識別子が定義されていてもよい。ここで、例えば、図４の６行目から１１行目は、再解釈前の対象の現在状態が“s1”のときに、再解釈により状態を遷移させることが決定された場合、状態遷移“r1”に対応づけられた処理“task1”を実施して、対象の現在状態を“s'1”に遷移させることを表している。同様に、１２行目から１７行目は、再解釈前の対象の現在状態が“s2”のときに、再解釈により状態を遷移させることが決定された場合、状態遷移“r2”に対応づけられた処理“task2”を実施して、対象の現在状態を“s'2”に遷移させることを表している。

また、“状態要素型”項目における“変化項目”は、状態要素定義が対応している変化項目を表している。すなわち、当該状態要素定義が対象とする、状態と変化項目の組のうちの変化項目を表している。本例の“変化項目”項目は、“項目名”を有しており、当該“項目名”には、当該変化項目の名称等が定義される。

また、“状態遷移”は、変更要求による状態間の遷移を表している。本例の“状態遷移”項目は、“id”、“from”、“to”、“処理”の項目を有しており、これらの項目は、上述した“再解釈”項目におけるそれらと基本的に同様である。すなわち、“id”は当該状態遷移の識別子を表し、“from”は遷移元の状態を表し、“to”は遷移先の状態を表し、“処理”は遷移条件すなわち変更要求により対象の現在状態が“from”で示された状態から“to”で示された状態に遷移する際に行う遷移処理を表している。ここで、遷移条件としての遷移処理には、処理実行に必要な情報が記載されるか、該情報への参照が記載される。処理実行に必要な情報の例としては、対象の正規の状態または対象の正規の状態と変化項目の組が挙げられる。

例えば、図４の２３行目から５８行目には、６つの状態遷移が定義されている。例えば、２３行目から２８行目は、変更要求前の対象の現在状態が“s1”のときに、変更要求により状態を“s2”に遷移させる場合、状態遷移“t1”に対応づけられた処理“task3”を実施して、対象の現在状態を“s2”に遷移させることを表している。同様に、例えば、２９行目から３４行目は、変更要求前の対象の現在状態が“s2”のときに、変更要求により状態を“s1”に遷移させる場合、状態遷移“t2”に対応づけられた処理“task4”を実施して、対象の現在状態を“s2”に遷移させることを表している。以下の行の要約としては、状態遷移“t3”は、設定項目“para1”に、要求状態における当該設定項目の値を代入するとともに、“task5”により状態を“s'1”から“s1”へ遷移させる。ここで、“{項目名}”は、変更要求で示される項目名の参照を表している。

なお、本例では、処理中に定義される設定項目が変化項目となっているが、変化項目以外の項目を定義することも可能である。

状態遷移“t4”は、設定項目“para1”に要求状態における当該設定項目の値を代入し、“task6”により状態を“s'2”から“s2”へ遷移させる。状態遷移“t5”は、設定項目“para1”に現在状態の当該設定項目の値を代入し、“task7”により状態を“s'1”から“s2”へ遷移させる。状態遷移“t6”は、設定項目“para1”に現在状態の当該設定項目の値を代入し、“task8”により状態を“s'2”から“s1”へ遷移させる。

また、図５は、現在状態要素の例を示す図である。なお、図５には、図４に示した状態要素定義に対応する現在状態要素の例がテキスト形式で示されている。ここでは、ＪＳＯＮ形式を用いた例を示している。図５において、“状態要素”項目は、当該テキストが現在状態要素のテキストデータであることを表している。本例では、“状態要素”項目は、さらに“型名”、“id”、“状態”、“変化項目”の４つの項目を含む。

ここで、“型名”は、対応する状態要素定義の名称を表している。また、“id”は、当該状態要素のｉｄとしての名称を表している。なお、当該状態要素の名称は、当該情報を基に、現在状態を含む状態要素が定義される場合、その状態要素の名称としても使用されることを想定している。“状態”は、対象の現在の正規の状態を表している。“変化項目”は、対象の現在の変化項目を表している。本例の“変化項目”には、項目名と当該項目名の値とが定義される。

図５によれば、例えば、ｉｄが“e1”で現在状態が管理される、対象“E”の状態要素が、現在状態が“s1”であり、変化項目“para1”の現在の値が“p1”であることがわかる。なお、上記項目以外に、例えば、状態遷移処理で必要なパラメータ等があれば、ここで定義することも可能である。

また、図６は、指示状態要素の例を示す図である。なお、図６には、図４に示した状態要素定義に対応する指示状態要素の例がテキスト形式で示されている。ここでは、ＪＳＯＮ形式を用いた例を示している。図６において、“変更要求”項目は、当該テキストが指示状態要素のテキストデータであることを表している。本例では、“変更要求”項目は、さらに“型名”、“id”、“現在状態”、“要求状態”、“変化項目”の５つの項目を含む。

ここで、“型名”は、対応する状態要素定義の名称を表している。また、“id”は、当該状態要素のｉｄとしての名称を表している。なお、当該状態要素の名称は、当該情報を基に、現在状態および変更状態を含む状態要素（指示状態要素）が定義される場合、その状態要素の名称としても使用されることを想定している。“現在状態”は、対象の現在の正規の状態を表している。“要求状態”は、対象に対して要求する正規の状態、すなわち状態変更後の対象の正規の状態を表している。“変化項目”は、対象の要求状態における変化項目を表している。本例の“変化項目”には、項目名と当該項目名の値とが定義される。

図６によれば、例えば、ｉｄが“e1”で現在状態と要求状態の組が管理される、対象“E”の状態要素が、正規の状態“s1”から正規の状態“s2”へと遷移するとともに、状態変更後の変化項目“para1”の値が“p1”となることを要求していることがわかる。なお、上記項目以外に、例えば、状態遷移処理で必要なパラメータ等があれば、ここで定義することも可能である。

以下、上述したＡｐａｃｈｅの例を用いて本実施形態の指示状態要素の導出過程を説明する。なお、導出が望まれる変更手順は、「変化項目の値を変更し、リロードを実施する」という変更要件からなる手順である。本実施形態では、このような変更手順の導出を、状態と変化項目の組での比較による現在状態の再解釈、より具体的にはそのような比較結果に基づく現在状態の再解釈状態への状態遷移によって実現する。

図７は、本実施形態におけるＡｐａｃｈｅを対象部品とする状態要素定義の例を示す図である。ここで、状態“F”は、Ａｐａｃｈｅが停止している状態を表している。また、状態“T”は、Ａｐａｃｈｅが稼動している状態を表している。また、状態“U”は、Ａｐａｃｈｅが要求状態において変化項目の値とは異なる値で稼動している状態を表している。本例において、状態“F”と状態“T”が正規の状態であり、状態“U”が状態“T”の再解釈状態である。

また、図７には、状態“F”から状態“T”への遷移“t1”が定義されている。また、状態“T”から状態“F”への遷移“t2”が定義されている。また、状態“U”から状態“F”への遷移“t3”が定義されている。また、状態“U”から状態“T”への遷移“t4”が定義されている。また、状態“T”から状態“U”への遷移“r1”が定義されている。本例において、遷移“tX”（ただし、Ｘ＝１〜４）は、変更要求による遷移である。また、遷移“r1”が再解釈により生じる遷移である。また、当該状態要素の角丸長方形の右上の四角は、当該状態要素の変化項目として“port”（ポート番号）を用いることを示している。

図８は、図７に示した状態要素定義をテキスト形式により表現した図である。ここでは、ＪＳＯＮ形式を用いた例を示している。なお、本例のデータ構造は、基本的に図４に示した例と同様である。

Ａｐａｃｈｅのリロード処理は、稼動中のＡｐａｃｈｅの設定値を変更してＡｐａｃｈｅに対してリロード実行コマンドを発行することにより実行される。よって、現在状態の再解釈が必要なのは、状態変更前後で現在状態が共に稼動中かつ設定値が異なるときである。図７および図８に示す状態要素定義では、そのような対象部品の動作に基づいて、状態“Ｔ”に対して再解釈状態“Ｕ”が定義されている。なお、状態“Ｆ”に対して再解釈状態が定義されていないのも、上記のような対象部品の動作に基づく。なお、現在状態“Ｔ”から再解釈状態“Ｕ”への遷移時には、Ａｐａｃｈｅに対して特に操作は必要でないため、再解釈で生じる状態遷移“r1”の処理には、処理を実行しない値として定義されている“noop”が設定されている。

本実施形態の状態比較計算部１２０は、状態要素定義に基づき、変更要求を受け付けたときに、現在状態に対して再解釈状態が定義されていた場合であって、状態変更前後で変化項目の値が異なっている場合に、現在状態を再解釈状態に仮想的に変更する。これは、状態変更前の状態を再解釈状態に定義しなおすことであってもよい。

本例では、状態遷移“t1”の状態遷移処理として、Ａｐａｃｈｅを停止状態から稼動状態へと遷移させるための起動処理（図中の２１行目の“service apache2 state=start”参照）が定義されている。ここで、“service apache2”は、処理実行の対象がＡｐａｃｈｅであることを示している。また、“state=start”は、処理実行の対象（Ａｐａｃｈｅ）を稼動状態に操作することを示している。

また、本例では、状態遷移“t2”の状態遷移処理として、Ａｐａｃｈｅを稼動状態から停止状態へと遷移させるための停止処理（図中の２７行目の“service apache2 state=stop”参照）が定義されている。ここで、“state=stop”は、処理実行の対象（Ａｐａｃｈｅ）を停止状態に操作することを示している。

また、本例では、状態遷移“t3”の状態遷移処理として、Ａｐａｃｈｅを要求された設定値とは異なる設定値で稼動している状態から停止状態へと遷移させるための停止処理（図中の３３行目参照）が定義されている。

また、本例では、状態遷移“t4”の状態遷移処理として、Ａｐａｃｈｅを要求された設定値とは異なる設定値で稼動している状態から、要求された設定値で稼動している状態へと遷移させるためのリロード処理（図中の３９行目の“service apache2 state=reload port={port}”参照）が定義されている。ここで、“state=reload”は、設定値のリロード操作をすることを示している。また、“port={port}”は、変更要求で示される“{}”内の項目の値を参照して、左辺で示される項目に代入することを示している。

なお、上記の定義方法は一例であって、これに限定されない。

また、図９は、Ａｐａｃｈｅを対象部品とする現在状態要素の例を示す図である。なお、図９に示す例は、図７に示した状態要素定義によって示される対象に対して、現在の内容（現在の正規の状態および該状態における変化項目の値）を表したものとなっている。図９によれば、ｉｄが“apache1”で管理される状態要素であって、状態変更前の状態が“Ｔ”であり、状態変更前の変化項目“port”の値が“80”であることがわかる。

また、図１０は、図９に示した現在状態要素をテキスト形式により表現した図である。ここでは、ＪＳＯＮを用いた例を示している。なお、本例のデータ構造は、基本的に図５に示した例と同様である。

また、図１１は、Ａｐａｃｈｅを対象部品とする現在状態要素の他の例を示す図である。なお、図１１に示す例は、図７に示した状態要素定義によって示される対象に対して、要求後の内容（要求後の正規の状態および該状態における変化項目の値）を現在状態の内容として表したものとなっている。図１１によれば、ｉｄが“apache1”で管理される状態要素であって、状態変更後の状態が“Ｔ”であり、状態変更後の変化項目“port”の値が“81”であることがわかる。本例のように、要求後の状態を現在状態とする現在状態要素を、要求状態要素の代わりに用いることも可能である。なお、その場合、当該現在状態における現在の状態が要求状態とされる。

また、図１２は、図１１に示した現在状態要素をテキスト形式により表現した図である。ここでは、ＪＳＯＮを用いた例を示している。なお、本例のデータ構造は、基本的に図５に示した例と同様である。

また、図１３は、Ａｐａｃｈｅを対象部品とする指示状態要素の例を示す図である。図１３に示す例は、図７に示した状態要素定義と、図９に示した現在状態要素と、図１１に示した変更要求後の現在状態要素とに基づいて導出される指示状態要素の例である。図１３によれば、ｉｄが“apache1”で管理される状態要素であって、状態変更前の状態が“U”であり、要求状態が“T”であり、状態変更後の変化項目“port”の値が“81”であることがわかる。

また、図１４は、図１３に示した指示状態要素をテキスト形式により表現した図である。ここでは、ＪＳＯＮを用いた例を示している。なお、本例のデータ構造は、基本的に図６に示した例と同様である。

状態比較計算部１２０の現在状態再定義部１２１は、要求状態要素を受け付けると、指定された状態要素定義に基づき、対象の現在の内容（現在の正規の状態と変化項目値）と、対象の要求後の内容（要求後の正規の状態と変化項目値）とを比較して対象の現在の状態を再解釈する、すなわち、変化項目の値のみ異なる場合に、対象の現在の状態を、現在の正規の状態に対して定義されている再解釈状態に定義しなおす。ここで、現在状態再定義部１２１は、現在状態要素の現在の状態を、再解釈状態に変更したものを、今回の要求状態要素との対比における現在状態要素として、変更要求生成部１２２に出力してもよい。

状態比較計算部１２０の変更要求生成部１２２は、現在状態再定義部１２１による再定義処理の結果、得られた現在状態要素と、受け付けた要求状態要素とに基づいて、指示状態要素を生成する。変更要求生成部１２２は、生成した指示状態要素を、状態要素入出力部２００を介して出力してもよい。変更要求生成部１２２は、例えば、生成した指示状態要素とともに、対応する状態要素定義を出力してもよい。また、変更要求生成部１２２は、出力した先にいる処理手順生成装置等の仕様に準じた、指示状態要素を生成して出力するようにしてもよい。

状態要素入出力部２００は、受け付けた指示状態要素を出力する。状態要素入出力部２００は、例えば、ディスプレイ装置である場合に、当該ディスプレイ装置に表示させることで、ユーザに提示してもよい。また、状態要素入出力部２００は、ネットワーク等を介して接続されている所定の処理手順生成装置等に向けて出力してもよい。また、状態要素入出力部２００が、さらに処理実行部を備える場合には、処理実行部に転送し、該処理実行部に処理手順を生成させることも可能である。

［動作の説明］
次に、本実施形態の動作を説明する。図１５は、本実施形態における指示状態要素の導出処理の処理フローの一例を示すフローチャートである。なお、本例では、必要な対象についての状態要素定義および現在の正規の状態に対応した現在状態要素が、状態要素記憶部１１０に記憶されているものとする。

まず、状態比較計算部１２０（より具体的には、現在状態再定義部１２１）が、状態要素入出力部２００から任意の対象の要求状態要素（もしくは状態変更後の状態要素）を受け付けると、状態要素記憶部１１０が記憶する現在状態要素のうち、受け付けた要求状態要素と同一のｉｄを有する現在状態要素を取得する（ステップＳ１１０）。このとき、状態比較計算部１２０は、受け付けた要求状態要素に対応する状態要素定義も併せて取得してもよい。

次に、現在状態再定義部１２１は、受け付けた要求状態要素と、取得した現在状態要素とを比較して、現在状態を再定義する（ステップＳ１２０）。

現在状態再定義部１２１による現在状態の再定義処理が完了すると、変更要求生成部１２２が、受け付けた要求状態要素と、現在状態再定義部１２１から出力される現在状態要素とに基づいて、指示状態要素を生成する（ステップＳ１３０）。

また、図１６は、現在状態再定義部１２１による現在状態の再定義処理の処理フローの一例を示すフローチャートである。図１６に示す例では、まず、現在状態再定義部１２１は、要求状態と現在状態とが一致するか否かを判定する（ステップＳ１２１）。ここで、両状態が一致しなかった場合（ステップＳ１２１のＮｏ）、現在状態再定義部１２１は、現在状態の再定義は不要であるとして、取得された現在状態要素に対して特に何もせず、そのまま出力する。

一方、両状態が一致した場合（ステップＳ１２１のＹｅｓ）、現在状態再定義部１２１は、状態変更前後で変化項目の値が異なるか否かを判定する（ステップＳ１２２）。ここで、両変化項目の値が一致する場合（ステップＳ１２２のＮｏ）、現在状態再定義部１２１は、現在状態の再定義は不要であるとして、取得された現在状態要素に対して特に何もせず、そのまま出力する。

一方、両変化項目の値が異なる場合（ステップＳ１２２のＹｅｓ）、現在状態再定義部１２１は、現在状態の再定義が必要であるとして、現在状態を当該現在状態に対応する再解釈状態に定義しなおす（ステップＳ１２３）。ここでは、現在状態再定義部１２１は、取得された現在状態要素を複製し、その現在状態を当該現在状態に対応する再解釈状態に変更したものを出力する。なお、現在状態の再定義を、現在状態要素上では行わず、指示状態要素上で行うことも可能である。その場合、現在状態再定義部１２１は、再定義が必要であると判断した場合には、現在状態を示す情報として、現在の正規の状態に対応する再解釈状態を出力し、不要であると判断した場合には、現在の正規の状態を出力すればよい。

その場合、変更要求生成部１２２は、受け付けた要求状態要素の状態を要求状態とし、現在状態を、現在状態再定義部１２１から出力された現在状態として、指示情報要素を生成すればよい。なお、変更要求生成部１２２は、変化項目の値については、要求状態要素における値に設定すればよい。

以下、上述した例を用いて具体的に上記動作を説明する。状態比較計算部１２０（現在状態再定義部１２１）は、例えば、図１２に示す要求状態要素を状態要素入出力部２００から受け付けると、ｉｄが“apache1”で管理される対象“Apache”の状態要素定義（図８）と、現在状態要素（図１０）を取得する。そして、状態比較計算部１２０（現在状態再定義部１２１）は、取得した現在状態要素と、受け付けた要求状態要素とを比較し、再定義が必要であるか否かを判定する。本例では、再定義が必要であると判断されるため、状態比較計算部１２０（現在状態再定義部１２１）は、状態要素定義に基づいて図１７に示すような現在状態要素を生成して、出力する。変更要求生成部１２２は、出力された現在状態要素と、受け付けた要求状態要素とに基づいて、指示状態要素を生成する。本例の場合、ｉｄが“apache1”で管理される対象“Apache”の指示状態要素（図１４）が生成される。

より具体的には、図１０と図１２に示す現在状態要素の状態を比較すると、５行目の状態がともに“T”を示している。次に、変化項目の値を比較すると、７行目の“port”の値”が、図１０の状態変更前では“80”であり、図１２の状態変更後では“81”であり、異なる値を示している。ここで、図８に示す状態要素定義によれば、再解釈は、状態変更前後で“T”の状態で変化項目の値が異なるときに発生することがわかる。そして、再解釈により発生する再解釈状態が“U”であることがわかる。よって、状態比較計算部１２０の現在状態再定義部１２１は、現在状態を“U”に再定義する。

なお、状態比較計算部１２０（現在状態再定義部１２１）は、比較の結果、再定義が不要であると判断した場合には、取得した現在状態要素をそのまま出力すればよい。その場合も、変更要求生成部１２２は、出力された現在状態要素と、受け付けた要求状態要素とから、指示状態要素を生成すればよい。

さらに、変更要求生成部１２２は、ステップＳ１３０で導出された指示状態要素と、状態要素定義とに基づいて、変更手順を導出してもよい。上記の例では、Ａｐａｃｈｅのポート番号を８１番に変更した後、リロード処理である“service apache2 reload”を実行する旨を示す変更手順が生成される。

また、システム変更支援システム１０は、処理実行部を備え、処理実行部が、生成された変更手順を実行してもよい。

また、再解釈方法は、ある対象の正規の各状態に対して再解釈先を定義する以外に、対象の全ての正規の状態が同じ状態へと変更されるように定義する方法や、システムを構成する全ての対象で再解釈先が決められている方法なども可能である。

図１８は、ある対象の全ての正規の状態が同じ状態へと再解釈される状態要素定義の例を示す図である。状態“s1”、“s2”はともに再解釈により状態“s”へ遷移することが定義されている。ここで、状態“ｓ”は正規の状態であってもよい。その場合、状態“ｓ”から状態“ｓ”への再解釈による遷移がさらに定義されればよい。

図１９は、図１８に示す状態要素定義をテキスト形式により表現した図である。当該再解釈では、再解釈先の状態が全て同じであるため、“再解釈”項目における“from”項目に、全ての状態を示す“*”が指定されている。

以上のように、本実施形態によれば、状態要素における状態遷移に、設定値に基づく状態遷移を含ませるような場合であっても、状態変更前後で状態と設定値の組を比較して、状態変更前の状態を再解釈し現在状態を定義しなおすことで、設定値の個数分の状態を定義せずに設定値を変更するリロード処理を導出することができる。

なお、上記実施形態では、状態と変化項目の組を対象にして、システムの変更に基づく状態遷移および変更手順を導出する例を示したが、対象は、状態と変化項目の組に限られない。すなわち、取り得る値の個数が有限または所定値未満の離散値である第１項目と、取り得る値の個数が所定値以上の連続値または離散値である第２項目の組に対しても、同様に、それらの第１項目の値および第２項目の値のいずれかの変化に基づく変更手順を導出することができる。例えば、システム変更支援システムは、各々が第１項目の値と第２項目の値から構成される２つのベクトルであって、一方を比較対象とし、他方を被比較対象とする２つのベクトルの比較を行い、第１項目の値が一致し、第２項目の値が異なる場合に、比較対象のベクトルの第１項目の値を変更するものであってもよい。その場合、状態管理システム１００は、値管理システムとされてもよい。ここで、第１項目が上記の実施形態における状態に相当する。また、第２項目が上記の実施形態における変化項目に相当する。また、変化項目の値は、例えば、変更可能性のある値を保持する複数の項目の値の合成であってもよい。

次に、本発明の概要を説明する。図２０は、本発明の概要を示すブロック図である。図２０に示すように、本発明によるシステム変更支援システムは、値再定義手段５０１を備えている。

値再定義手段５０１（例えば、現在状態再定義部１２１）は、各々が、取り得る値の個数が有限または所定値未満の離散値である第１項目の値と、取り得る値の個数が所定値以上の連続値または離散値である第２項目の値の組により構成される２つのベクトルであって、一方を比較対象とし、他方を被比較対象とする２つのベクトルの比較を行い、２つのベクトルの第１項目の値が一致し、第２項目の値が異なる場合に、比較対象のベクトルの第１項目の値を変更する。

なお、システム変更支援システムにおいて、比較対象とされるベクトルは、対象システムの変更前の第１項目の値と第２項目の値の組により構成され、被比較対象とされるベクトルは、対象システムの変更後の第１項目の値と第２項目の値の組により構成されていてもよい。

また、第１項目は、対象システムを構成する部品の状態であり、第２項目は、対象システムの部品に関連する値であって変更可能性のある値を保持する任意の項目であってもよい。

そのような場合において、比較の結果、変更される状態は、予め指定された特定の状態であってもよい。また、比較の結果、変更される状態は、比較対象のベクトルを構成するシステムの部品の種類ごとに指定された状態であってもよい。さらに、比較の結果、変更される状態は、変更前のベクトルの状態の値によって異なっていてもよい。

また、比較対象のベクトルの変更後の第１項目の値は、対象システムにおいて第１項目が取りえない所定の値であってもよい。

また、図２１は、本発明によるシステム変更支援システムの他の構成例を示すブロック図である。図２１に示すように、システム変更支援システムは、さらに、記憶手段５０２や、入力手段５０３や、出力手段５０４を備えていてもよい。

記憶手段５０２（例えば、状態要素記憶部１１０）は、第１項目の値を異なる値に変更する際の変更要件を保持する記憶手段であってもよい。また、記憶手段５０２は、変更後の第１項目の値を、変更前の第１項目または比較対象のベクトルを構成する第１項目と第２項目の組に対して予め定義された識別子と対応づけて保持する記憶手段であってもよい。なお、記憶手段５０２は、これらすべてを記憶する記憶手段であってもよい。

入力手段５０３（例えば、状態要素入出力部２００）は、被比較対象のベクトルを含む情報を入力する。出力手段５０４（例えば、状態要素入出力部２００）は、変更後の比較対象のベクトルを含む情報を出力する。

また、記憶手段５０２は、変更前のシステムの部品の情報を記憶するシステム部品状態記憶手段であってもよい。また、入力手段５０３は、変更後のシステムの部品の情報を受け付ける状態要素入力手段であってもよい。そのような場合において、値再定義手段５０１は、記憶手段５０２に記憶された変更前のシステムの部品の情報と、入力手段５０３によって入力された変更後のシステムの部品の情報とを比較して、システムの部品の情報を再定義する手段であってもよい。また、出力手段５０４は、再定義されたシステムの部品の情報を出力する出力手段であってもよい。

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

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

本発明は、システム構成部品が、取り得る値の個数が有限または所定値未満の離散値である第１項目と、取り得る値の個数が所定値以上の連続値または離散値である第２項目とを有するようなシステムであれば、好適に適用可能である。

１０ システム変更支援システム
１００ 状態管理システム
１１０ 状態要素記憶部
１２０ 状態比較計算部
１２１ 現在状態再定義部
１２２ 変更要求生成部
２００ 状態要素入出力部
５０１ 値再定義手段
５０２ 記憶手段
５０３ 入力手段
５０４ 出力手段

Claims (10)

1. 取り得る値の個数が有限または所定値未満の離散値である第１項目の値と、取り得る値の個数が所定値以上の連続値または離散値である第２項目の値の組により構成される２つのベクトルであって、一方を比較対象とし、他方を被比較対象とする２つのベクトルの比較を行い、前記２つのベクトルの前記第１項目の値が一致し、前記第２項目の値が異なる場合に、比較対象のベクトルの前記第１項目の値を変更する値再定義手段を備えた
   ことを特徴とするシステム変更支援システム。
2. 比較対象とされるベクトルは、対象システムの変更前の第１項目の値と第２項目の値の組により構成され、
   被比較対象とされるベクトルは、対象システムの変更後の第１項目の値と第２項目の値の組により構成されている
   請求項１に記載のシステム変更支援システム。
3. 第１項目の値を異なる値に変更する際の変更要件を保持する記憶手段を備えた
   請求項１または請求項２に記載のシステム変更支援システム。
4. 第１項目は、対象システムを構成する部品の状態であり、
   第２項目は、対象システムの前記部品に関連する値であって変更可能性のある値を保持する任意の項目である
   請求項１から請求項３のうちのいずれか１項に記載のシステム変更支援システム。
5. 比較対象のベクトルの変更後の第１項目の値は、対象システムにおいて前記第１項目が取りえない所定の値である
   請求項１から請求項４のうちのいずれか１項に記載のシステム変更支援システム。
6. 変更後の第１項目の値を、変更前の第１項目または比較対象のベクトルを構成する第１項目と第２項目の組に対して予め定義された識別子と対応づけて保持する記憶手段を備えた
   請求項１から請求項５のうちのいずれか１項に記載のシステム変更支援システム。
7. 被比較対象のベクトルを含む情報を入力する入力手段と、
   変更後の比較対象のベクトルを含む情報を出力する出力手段とを備えた
   請求項１から請求項６のうちのいずれか１項に記載のシステム変更支援システム。
8. 取り得る値の個数が有限または所定値未満の離散値である第１項目の値と、取り得る値の個数が所定値以上の連続値または離散値である第２項目の値の組により構成される２つのベクトルであって、一方を比較対象とし、他方を被比較対象とする２つのベクトルの比較を行い、前記２つのベクトルの前記第１項目の値が一致し、前記第２項目の値が異なる場合に、比較対象のベクトルの前記第１項目の値を変更する値再定義手段を備えた
   ことを特徴とする情報処理装置。
9. 情報処理装置が、取り得る値の個数が有限または所定値未満の離散値である第１項目の値と、取り得る値の個数が所定値以上の連続値または離散値である第２項目の値の組により構成される２つのベクトルであって、一方を比較対象とし、他方を被比較対象とする２つのベクトルの比較を行い、前記２つのベクトルの前記第１項目の値が一致し、前記第２項目の値が異なる場合に、比較対象のベクトルの前記第１項目の値を変更する
   ことを特徴とするシステム変更支援方法。
10. コンピュータに、
    取り得る値の個数が有限または所定値未満の離散値である第１項目の値と、取り得る値の個数が所定値以上の連続値または離散値である第２項目の値の組により構成される２つのベクトルであって、一方を比較対象とし、他方を被比較対象とする２つのベクトルの比較を行い、前記２つのベクトルの前記第１項目の値が一致し、前記第２項目の値が異なる場合に、比較対象のベクトルの前記第１項目の値を変更する処理
    を実行させるためのシステム変更支援プログラム。

Images