(57)【要約】【課題】  データフォーマットの変換規則の定義情報について、変換対象とされるデータフォーマットの変更に応じた修正作業を効率化させることのできる変換規則修正プログラムの提供を目的とする。【解決手段】  第一のデータフォーマットの定義情報の変更に基づいて前記第一のデータフォーマットと第二のデータフォーマットとの変換規則の定義情報の修正をコンピュータに実行させる変換規則修正プログラムであって、前記第一のデータフォーマットの変更前後の定義情報の形式的な差分を求め、該差分に基づいて前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報を導出する解析手順（Ｓ１２）と、前記解析手順において導出された前記論理的な変更情報に基づいて、前記変換規則の定義情報を修正する第一の修正手順（Ｓ１４）とを有することにより上記課題を解決する。【選択図】  図４
2006277662.tif 000002
【特許請求の範囲】
【請求項１】
第一のデータフォーマットの定義情報の変更に基づいて前記第一のデータフォーマットと第二のデータフォーマットとの変換規則の定義情報の修正をコンピュータに実行させる変換規則修正プログラムであって、
前記第一のデータフォーマットの変更前後の定義情報の形式的な差分を求め、該差分に基づいて前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報を導出する解析手順と、
前記解析手順において導出された前記論理的な変更情報に基づいて、前記変換規則の定義情報を修正する第一の修正手順とを有することを特徴とする変換規則修正プログラム。
【請求項２】
前記解析手順は、該差分に基づいて、前記論理的な変更情報として取り得る複数のパターンを導出し、
前記第一の修正手順は、前記複数のパターンのそれぞれに基づいて前記変換規則の定義情報を修正することを特徴とする請求項１記載の変換規則修正プログラム。
【請求項３】
前記論理的な変更情報を構成する変更要素ごとに、当該変更要素ごとの変更内容に応じた確定度を算出し、該確定度に基づいて前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報に対する確定度を算出する確定度算出手順を有することを特徴とする請求項１又は２記載の変更規則修正プログラム。
【請求項４】
前記解析手順において導出された前記論理的な変更情報に基づいて、変更前の前記第一のデータフォーマットに基づくデータを変更後の前記第一のデータフォーマットに基づくデータに修正する第二の修正手順を有することを特徴とする請求項１乃至３いずれか一項記載の変換規則修正プログラム。
【請求項５】
前記第二の修正手順において修正されたデータを用いて、前記第一の修正手順において修正された前記変換規則の定義情報の検証を行う検証手順を有することを特徴とする請求項４記載の変換規則修正プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、変換規則修正プログラムに関し、特にデータフォーマットの変換規則の定義情報の修正をコンピュータに実行させる変換規則修正プログラムに関する。
【背景技術】
【０００２】
企業においては多数のコンピュータシステムが稼動しており、それぞれのシステムは独自のデータベースを有しているのが一般的である。複数のシステム間のデータ連携を行う必要がある場合、システムの組み合わせごとに連携ツールを作成するのは非効率である。そこで、従来、仲介的又は共通的なデータベース（以下、「統合ＤＢ」という。）を定義し、かかる統合ＤＢを介して複数のシステム間のデータ連携を図る手法がある。
【０００３】
図１は、統合ＤＢを介したシステム間のデータ連携を説明するための概念図である。図１に示されるように、各システム（システムＡ、システムＢ及びシステムＣ）と統合ＤＢとの間では、それぞれのデータフォーマットの差違を吸収するために以下のようなフォーマット変換が行われる。
【０００４】
まず、各システムにおいて管理されているデータを統合ＤＢに入力する際には、各システムと統合ＤＢとのデータフォーマットとの差異を吸収するために入力用ＡＰＩ５０１が用いられ、システムごとのデータフォーマットが共通的な統合ＤＢにおけるデータフォーマットに変換される。一方、統合ＤＢにおいて管理されているデータを各システムに出力する際には、各システムと統合ＤＢとのデータフォーマットとの差異を吸収するために出力用ＡＰＩ５０２が用いられ、統合ＤＢにおけるデータフォーマットがシステムごとのデータフォーマットに変換される。
【０００５】
この手法によれば、それぞれのシステムは統合ＤＢとの入出力インタフェースのみを意識すればよいため、システムの組み合わせごとに連携ツールを作成する場合に比べれば効率的である。
【０００６】
しかし、統合ＤＢのデータフォーマットに仕様変更が生じた場合、統合ＤＢ自体のみならず、その仕様変更に係るデータ項目の連携を行っている入力用又は出力用ＡＰＩ（以下「入出力ＡＰＩ」という。）の全てについてもコーディング、コンパイル及びリンク等といった煩雑な作業が必要とされる。したがって、一度導入された統合ＤＢの拡張は非常にコストのかかるものであった。
【０００７】
そこで、近年では、データフォーマットの変換にＸＭＬ（eXtensible Markup Language）技術が用いられることが多くなっている。ＸＭＬデータは、ＸＳＬＴ（XSL Transformations）ファイルによって容易にデータフォーマットの変換を行うことができる。また、ＸＭＬは、データベースのデータフォーマットの表現に適している。したがって、各システムのデータベース及び統合ＤＢの内容をＸＭＬによって表現することにより、入出力ＡＰＩの代わりにＸＳＬＴファイルをデータフォーマットの変換機能として用いることができる。
【０００８】
ＸＳＬＴファイルは、単なるテキストファイルであり、コンパイル等は必要とされない。したがって、ＸＳＬＴファイルを用いることで統合ＤＢの仕様変更に際するメンテナンス工数を削減することができるというわけである。
【０００９】
なお、特許文献１には、ＸＭＬ文書等の構造化データの編集を効率化させるための技術について記載されている。
【特許文献１】特開２００３−３４５７８１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、ＸＳＬＴを用いた場合であっても、やはり統合ＤＢの仕様変更に関連するＸＳＬＴファイルの修正は必要とされる。そして、従来この作業は手作業で行われていた。修正量は、システムの数が多ければ多いほど膨大なものとなり、修正ミスの危険性も増加する。結局のところ統合ＤＢによって多くのシステムを連携させることを避けざるを得ないという問題があった。
【００１１】
本発明は、上記の点に鑑みてなされたものであって、データフォーマットの変換規則の定義情報について、変換対象とされるデータフォーマットの変更に応じた修正作業を効率化させることのできる変換規則修正プログラムの提供を目的とする。
【課題を解決するための手段】
【００１２】
そこで上記課題を解決するため、本発明は、第一のデータフォーマットの定義情報の変更に基づいて前記第一のデータフォーマットと第二のデータフォーマットとの変換規則の定義情報の修正をコンピュータに実行させる変換規則修正プログラムであって、前記第一のデータフォーマットの変更前後の定義情報の形式的な差分を求め、該差分に基づいて前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報を導出する解析手順と、前記解析手順において導出された前記論理的な変更情報に基づいて、前記変換規則の定義情報を修正する第一の修正手順とを有することを特徴とする。
【００１３】
このような変換規則修正プログラムでは、データフォーマットの定義情報の変更に基づいて、そのデータフォーマットを処理対象とする変換規則の定義情報を自動的に修正することができる。したがって、データフォーマットの定義情報の変更に応じた変換規則の修正作業を効率化させることができる。
【発明の効果】
【００１４】
本発明によれば、データフォーマットの変換規則の定義情報について、変換対象とされるデータフォーマットの変更に応じた修正作業を効率化させることのできる変換規則修正プログラムを提供することができる。
【発明を実施するための最良の形態】
【００１５】
以下、図面に基づいて本発明の実施の形態を説明する。図２は、本発明の実施の形態におけるフォーマット変換ファイル修正装置のハードウェア構成例を示す図である。ここで、フォーマット変換ファイルとは、統合ＤＢと、統合ＤＢに連携する各システム（以下「連携システム」という。）とのデータフォーマットの差違を吸収するために用いられる変換規則の定義情報が記述されたテキストファイルをいい、図１における入力用ＡＰＩ１５０１又は出力用ＡＰＩ１５０２の位置付けに相当する。
【００１６】
なお、統合ＤＢとは、複数のシステム間のデータ連携を行うための仲介的又は共通的なデータベースをいう。本実施の形態では、フォーマット変換ファイルとしてＸＳＬＴ（XSL Transformations）ファイルを具体例として説明するが、フォーマット変換ファイルは必ずしもＸＳＬＴファイルに限定されない。但し、各連携システム及び統合ＤＢのデータフォーマットをＸＭＬ形式によって表現する場合、ＸＭＬとの親和性が高いＸＳＬＴによってフォーマット変換ファイルを定義することが望ましい。なお、以下、入力用ＡＰＩ５０１として機能するフォーマット変換ファイルを入力用フォーマット変換ファイル、出力用ＡＰＩ５０２として機能するフォーマット変換ファイルを出力用フォーマット変換ファイルという。
【００１７】
図２のフォーマット変換ファイル修正装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、演算処理装置１０４と、表示装置１０５と、入力装置１０６とを有するように構成される。
【００１８】
フォーマット変換ファイル修正装置１０での処理を実現するプログラムは、CD―ROM等の記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１９】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。演算処理装置１０４は、メモリ装置１０３に格納されたプログラムに従ってフォーマット変換ファイル修正装置１０に係る機能を実行する。表示装置１０５はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０６はキーボード及びマウス等で構成され、様々な操作指示を受け付けるために用いられる。
【００２０】
図３は、本発明の実施の形態におけるフォーマット変換ファイル修正装置の機能構成例を示す図である。図３において、フォーマット変換ファイル修正装置１０は、フォーマット変換ファイルの修正機能として、フォーマット定義ファイル差分解析部１１、フォーマット変換ファイル修正部１２、テストケース修正部１３及びテスト実行部１４等を有する。これらの各部は、フォーマット変換ファイル修正装置１０にインストールされたプログラムによって実現されるものである。
【００２１】
図４は、フォーマット変換ファイル修正装置の処理概要を説明するためのフローチャートである。図４の処理手順に沿って図３における各部の機能について説明する。
【００２２】
統合ＤＢのデータフォーマットに仕様変更があり、統合ＤＢのフォーマット定義ファイルが修正されたものとする。ここで、フォーマット定義ファイルとは、データフォーマット（スキーマ情報）が定義されたファイルをいう。本実施の形態では、ＸＭＬによってデータフォーマットが定義されているものとする。
【００２３】
ユーザからの指示（メニューの選択、又はアイコンのクリック等）に応じ、フォーマット定義ファイル差分解析部１１は、新規統合ＤＢフォーマット指定画面２１を表示装置１０６に表示させ、修正後のフォーマット定義ファイルを作業領域にアップロードする（Ｓ１１）。
【００２４】
図５は、新規統合ＤＢフォーマット指定画面の表示例を示す図である。図５において、新規統合ＤＢフォーマット指定画面２１は、修正テーブル選択領域２１１、フォーマット定義ファイル指定領域２１２、参照ボタン２１３及び修正ボタン２１４等より構成されている。
【００２５】
修正テーブル選択領域２１１には、例えば、統合ＤＢを構成するテーブルの中から、データフォーマットの修正対象とされるテーブルを選択させるための領域であり、統合ＤＢを構成するテーブルごとにそのテーブル名が表示されている。例えば、商品マスタ関連としては、商品追加テーブル、商品更新テーブル及び商品検索テーブル等があることが分かる。
【００２６】
フォーマット定義ファイル指定領域２１２は、修正テーブル選択領域２１１において選択されたテーブルに関して修正後のフォーマット定義ファイルを指定させるためのテキスト入力領域である。ユーザは、フォーマット定義ファイル指定領域２１２に直接文字列を入力することにより修正後のフォーマット定義ファイルのファイル名を入力してもよいし、参照ボタン２１３をクリックすることによりファイルダイアログを表示させ、そのファイルダイアログから修正後のフォーマット定義ファイルを選択してもよい。
【００２７】
修正ボタン２１４は、修正テーブル選択領域２１１において選択されたテーブルに対する修正後のフォーマット定義ファイルの作業領域へのアップロードを指示するためのボタンである。したがって、修正ボタン２１４がクリックされると、フォーマット定義ファイルのアップロードが実行される。
【００２８】
フォーマット定義ファイルがアップロードされると、フォーマット定義ファイル差分解析部１１は、アップロードされたフォーマット定義ファイル（以下、「新フォーマット定義ファイル」という。）と、従来の統合ＤＢフォーマット定義ファイル３１（以下「旧フォーマット定義ファイル」という。）との形式的な差分を求め、その差分に基づいて両者の論理的な変更情報を導出する（Ｓ１２）。
【００２９】
ここで、フォーマット定義の論理的な変更情報は一意に定まらない場合がある。例えば、あるデータ項目が新規に追加されたものなのか、あるいは既存のデータ項目の名前が変更されたものなのかは確定できない場合があるからである。したがって、フォーマット定義ファイル差分解析部１１は、可能性のある変更パターンの全てについて洗い出し、それぞれの変更パターンの変更情報を変更パターン情報３４として出力する。但し、変更前後のデータ項目名の類似性等より各変更パターンについてある程度の確からしさの推測は可能である。したがって、フォーマット定義ファイル差分解析部１１は、各変更パターンについて確からしさ（以下「確定度」という。）を算出し、確定度情報３５として出力する。
【００３０】
続いて、フォーマット変換ファイル修正部１２は、変更パターン情報３４と確定度情報３５とを用いて、全ての変更パターンについて全てのフォーマット変換ファイル３２を自動修正し、その修正結果をフォーマット変換ファイル修正結果情報３６として出力する（Ｓ１４）。ここで、全てのフォーマット変換ファイル３２とは、連携システムごとに定義されている全てのフォーマット変換ファイル３２をいう。
【００３１】
続いて、テストケース修正部１３は、変更パターン情報３４と確定度情報３５とを用いてテストケース情報３３を自動修正する。テストケース情報３３とは、フォーマット変換ファイルが修正された場合等において、修正されたフォーマット変換ファイルによるデータフォーマットの変換が正しく行われるか等を検証するための情報をいう。
【００３２】
図６は、テストケース情報を説明するための図である。図６において、上段は入力側（各連携システムから統合ＤＢへの変換）のテストについて、下段は出力側（統合ＤＢから各連携システムへの変換）のテストについて示している。
【００３３】
入力側のテストでは、各連携システム個別のデータフォーマットによるテスト用入力データ３３１を入力用フォーマット変換ファイル３２ａに変換させ、その変換結果が予め用意されている統合ＤＢのデータフォーマットによる検証データ３３２と比較される。両者が一致すれば、入力用フォーマット変換ファイル３２ａの正当性が検証されたこととなる。
【００３４】
出力側のテストでは、統合ＤＢのデータフォーマットによるテスト用初期データ３３３を出力用フォーマット変換ファイル３２ｂに変換させ、その変換結果が予め用意されている各連携システム個別のデータフォーマットによる検証データ３３４と比較される。両者が一致すれば、出力用フォーマット変換ファイル３２ｂの正当性が検証されたこととなる。
【００３５】
ここで、テスト用入力データ３３１、検証データ３３２、テスト用初期データ３３３及び検証データ３３４がテストケース情報３３に相当する。但し、統合ＤＢのデータフォーマットの変更に伴って修正する必要があるテストケース情報３３は、検証データ３３２及びテスト用初期データ３３３に限定される。すなわち、入力側のテスト用入力データ３３１と出力側の検証データ３３４とは各連携システムのデータフォーマットに依存する情報であり、統合ＤＢのデータフォーマットの変更の影響は受けないからである。
【００３６】
なお、テストケース情報３３は、連携システムごとに必要とされる。したがって、ステップＳ１６では、全ての連携システムに対する検証データ３３２とテスト用初期データ３３３とが自動修正され、その修正結果がテストケース修正結果情報３７として出力される。
【００３７】
続いて、フォーマット変換ファイル修正部１２は、フォーマット変換ファイル３２とテストケース情報３３との修正結果、すなわち、フォーマット変換ファイル修正結果情報３６とテストケース修正結果情報３７とを修正内容確認画面２２に表示させる（Ｓ１７）。
【００３８】
図７は、修正内容確認画面の表示例を示す図である。図７において修正内容確認画面２２は、フォーマット変換ファイル選択領域２２１、テストケース選択領域２２２、修正結果表示領域２２３、別修正結果表示領域２２４、ボタン２２５、ボタン２２６、ボタン２２７及びボタン２２８等より構成されている。
【００３９】
フォーマット変換ファイル選択領域２２１は、修正後のフォーマット変換ファイルの一覧が表示されており、その一覧の中から閲覧対象とするフォーマット変換ファイルを選択させるための領域である。テストケース選択領域２２２は、修正後のテストケース情報の一覧が表示されており、その一覧の中から閲覧対象とするテストケース情報を選択させるための領域である。
【００４０】
修正結果表示領域２２３は、フォーマット変換ファイル選択領域２２１又はテストケース選択領域２２２において選択されたフォーマット変換ファイル又はテストケース情報が表示される領域である。別修正結果表示領域２２４は、修正結果表示領域２２３に表示されている修正結果における任意のタグがクリックされた際に、そのタグが構成するブロックに関して別の修正結果が表示される領域である。すなわち、別修正結果表示領域２２４は、変更パターンが一意に定まらない場合に、修正結果表示領域２２３において選択されたブロックについて他の変更パターンに基づく修正結果が表示される領域である。
【００４１】
なお、修正内容確認画面２２が表示された直後においては、確定度の最も高い変更パターンに基づく修正結果が表示される。
【００４２】
ボタン２２８は、フォーマット変換ファイル修正結果情報３６とテストケース修正結果情報３７とを用いたテストを実行させるためのボタンである。ボタン２２５、ボタン２２６及び２２７については後述する。
【００４３】
このように、ユーザは、修正内容確認画面２２において、修正後の全てのフォーマット変換ファイル及びテストケース情報を閲覧することができる。
【００４４】
ユーザが修正結果に満足し（Ｓ１８でｙｅｓ）、ボタン２２８がクリックされると（Ｓ１９）、テスト実行部１４は、フォーマット変換ファイル修正結果情報３６及びテストケース修正結果情報３７に基づいて、図６において説明したようなテストを自動実行する（Ｓ２０）。テスト実行部１４は、テスト結果をテスト結果表示画面２４に表示させる（Ｓ２１）。
【００４５】
ユーザがテスト結果に満足し（Ｓ２２でｙｅｓ）、テスト結果表示画面２４の保存ボタンをクリックすると（Ｓ２３）、テスト実行部１４は、フォーマット変換ファイル修正結果情報３６及びテストケース修正結果情報３７を正規のフォーマット変換ファイル３２又はテストケース情報３３として保存する（Ｓ２４）。
【００４６】
一方、ステップＳ１８においてユーザが修正結果に満足せず（Ｓ１８でｎｏ）、修正結果表示領域２２３に表示されている修正結果における任意のタグをクリックすると、フォーマット変換ファイル修正部１２又はテストケース修正部１３は、当該タグが構成するブロック（以下「選択ブロック」という。）に関する他の修正結果（他の変更パターンに基づく修正結果）を別修正結果表示領域２２４に表示させる（Ｓ２５）。また、別修正結果表示領域２２４における、前候補ボタン２２９ａ又は次候補ボタン２２９ｂがクリックされると、フォーマット変換ファイル修正部１２又はテストケース修正部１３は、選択ブロックに関して更に別の変更パターンに基づく修正結果を表示させる。
【００４７】
別修正結果表示領域２２４に表示された修正結果の中に適切な修正結果が存在し（Ｓ２６でｙｅｓ）、ユーザがボタン２２５をクリックすると（Ｓ２７）、フォーマット変換ファイル修正部１２又はテストケース修正部１３は、別修正結果表示領域２２４に表示されていた修正結果に係るフォーマット変換ファイル修正結果情報３６（修正後のフォーマット変換ファイル）を、修正結果表示領域２２３に表示させる（Ｓ２８）。
【００４８】
なお、この際、別修正結果表示領域２２４に表示されているブロックについて同一の修正結果のフォーマット変換ファイルが複数存在する場合は、フォーマット変換ファイル修正部１２又はテストケース修正部１３は、他の部分について修正結果表示領域２２３に表示されていたフォーマット変換ファイルと最も近いものを自動的に選択し、表示させる。
【００４９】
一方、全ての変更パターンに基づくフォーマット変換ファイル修正結果情報３６（すなわち、自動修正された修正結果）の中に適切なものは存在せず（Ｓ２６でｎｏ）、ユーザが、修正内容確認画面２２（図７）のボタン２２６（修正内容候補の編集）又はボタン２２７（新規修正内容候補作成）をクリックすると（Ｓ２９）、フォーマット変換ファイル修正部１２は、修正内容候補編集画面２３を表示させる（Ｓ３０）。
【００５０】
図８は、修正内容候補編集画面の表示例を示す図である。図８において、修正内容候補編集画面２３は、適用パターン入力領域２３１、修正結果入力領域２３２、優先順位入力領域２３３、確定ボタン２３４等より構成されている。
【００５１】
適用パターン入力領域２３１は、修正の適用対象とする箇所を特定するための情報（以下「適用パターン」という。）を入力させる領域である。適用パターンには、完全に一致する文字列の他、正規表現等を用いて適用対象を抽象的に特定することも可能である。
【００５２】
修正結果入力領域２３２は、適用パターンにマッチした箇所に対して適用する修正結果を入力させるための領域である。修正結果は、適用パターンの一部を変数として利用する等して抽象化して記述することができる。例えば、図中において、修正結果における記述２３１２である｛１｝は、適用パターンにおける記述２３１１である｛１：＊｝の部分に存在する文字列をそのまま差し込むことを意味する。
【００５３】
優先順位入力領域２３３は、適用パターンと修正結果との組み合わせからなる修正内容の優先順位を入力させる領域である。修正内容の優先順位とは、修正内容候補編集画面２３を用いて幾つもの修正内容を登録することができるところ、複数の適用パターンが当てはまる修正箇所が検出された際にいずれの修正内容を優先させるかを特定するためのパラメータである。
【００５４】
修正内容候補編集画面２３において確定ボタン２３４がクリックされると、フォーマット変換ファイル修正部１２は、修正内容候補編集画面２３に入力された修正内容を修正内容候補マスタ３８に登録する。
【００５５】
図９は、修正内容候補マスタの構成例を示す図である。図９において修正内容候補マスタ３８は、修正内容ごとに、修正内容候補ＩＤ，種別、適用パターン、修正結果、及び優先順位等の項目より構成されている。修正内容候補ＩＤは、各修正内容を識別するための情報が登録される項目である。修正内容候補ＩＤは、自動的に採番される。種別は、修正内容が適用される対象の種別（入力用フォーマット変換ファイル、出力用変換ファイル、テスト用初期データ又は検証データ等の別）が登録される項目である。適用パターン、修正結果、及び優先順位は、修正内容候補編集画面２３に入力された情報がそのまま登録される項目である。
【００５６】
更に、フォーマット変換ファイル修正部１２又はテストケース修正部１３は、修正内容候補マスタ３２に登録されている修正内容に基づいて、フォーマット変換ファイル修正結果情報３６又はテストケース修正結果情報３７を修正し（S３１）、その修正結果を修正内容確認画面２２に表示させる（Ｓ１７）。その後の操作は、上述した通りである。
【００５７】
次に、フォーマット定義ファイル差分解析部１１によるフォーマット定義ファイル差分解析処理（Ｓ１２）、フォーマット変換ファイル修正部１２によるフォーマット変換ファイル修正処理（Ｓ１４）、及びテストケース修正部１３によるテストケース修正処理（Ｓ１６）のそれぞれの詳細について説明する。
【００５８】
まず、フォーマット定義ファイル差分解析処理の詳細について説明する。ここでは、フォーマット定義ファイルが図１０に示されるように変更された場合を例とする。
【００５９】
図１０は、本発明の実施の形態における統合ＤＢの変更前後のフォーマット定義ファイルの例を示す図である。また、参考までに変更前後のフォーマット定義ファイルに基づく統合ＤＢの具体的なＸＭＬデータの例を図１１に示す。
【００６０】
図１０において、フォーマット定義ファイル３１１は変更前を、フォーマット定義ファイル３１２は変更後を示す。以下、それぞれ変更前フォーマット定義ファイル３１１、変更後フォーマット定義ファイル３１２という。
【００６１】
変更前フォーマット定義ファイル３１１について説明する。記述３１１−１、記述３１１−２、及び記述３１１−３では、ｅｍｐｌｏｙｅｅ＿ｉｄ要素、ｎａｍｅ要素、ｆｕｒｉｇａｎａ要素が定義されている。ここで、要素という用語はＸＭＬに倣ったものであり、統合ＤＢ上のデータ項目に対応付けられる。
【００６２】
記述３１１−４では、ｅｍｐｌｏｙｅｅ要素が定義されている。また、ｅｍｐｌｏｙｅｅ＿ｉｄ要素、ｎａｍｅ要素、ｆｕｒｉｇａｎａ要素、及びｅｎｇｌｉｓｈ＿ｉｎｆｏ要素は、ｅｍｐｌｏｙｅｅ要素の子要素であることも定義されている。
【００６３】
記述３１１−５では、ｅｎｇｌｉｓｈ＿ｉｎｆｏ要素が定義されている。また、ｎａｍｅ要素はｅｎｇｌｉｓｈ＿ｉｎｆｏ要素の子要素であることも定義されている。
【００６４】
すなわち、変更前フォーマット定義ファイル３１１におけるフォーマット定義はツリー３１１ｔに示されるツリー構造を構成する。
【００６５】
次に、変更後フォーマット定義ファイル３１２について説明する。記述３１２−１、記述３１２−２、記述３１２−３、及び記述３１２−４では、ｅｍｐｌｏｙｅｅ＿ｉｄ要素、ｎａｍｅ要素、ｆｕｒｉｇａｎａ要素、及びｅｎｇｌｉｓｈ＿ｎａｍｅ要素が定義されている。
【００６６】
記述３１２−５では、ｎａｍｅ＿ｉｎｆｏ要素が定義されている。また、ｎａｍｅ要素、ｆｕｒｉｇａｎａ要素、及びｅｎｇｌｉｓｈ＿ｎａｍｅ要素はｎａｍｅ＿ｉｎｆｏ要素の子要素であることも定義されている。
【００６７】
記述３１２−６では、ｅｍｐｌｏｙｅｅ要素が定義されている。また、ｅｍｐｌｏｙｅｅ＿ｉｄ要素、ｎａｍｅ＿ｉｎｆｏ要素はｅｍｐｌｏｙｅｅ要素の子要素であることも定義されている。
【００６８】
すなわち、変更後フォーマット定義ファイル３１２におけるフォーマット定義はツリー３１２ｔに示されるツリー構造を構成する。
【００６９】
ツリー３１１ｔ及びツリー３１２ｔを参照しながら説明すると、変更後フォーマット定義ファイル３１２は、変更前フォーマット定義ファイル３１１に対して、ｎａｍｅ＿ｉｎｆｏ要素を追加し（ａ１）、ｅｍｐｌｏｙｅｅ要素下のｎａｍｅ要素、及びｆｕｒｉｇａｎａ要素をｎａｍｅ＿ｉｎｆｏ要素下に移動し（ｍ１、ｍ２）、ｅｎｇｌｉｓｈ＿ｉｎｆｏ要素下のｎａｍｅ要素をｅｎｇｌｉｓｈ＿ｎａｍｅ要素に改名すると共にｎａｍｅ＿ｉｎｆｏ要素下に移動し（ｎ１）、更に、ｅｎｇｌｉｓｈ＿ｉｎｆｏ要素を削除（ｄ１）したものに相当する。
【００７０】
上記のような変更を例としてフォーマット定義ファイル差分解析処理を説明する。図１２は、フォーマット定義ファイル差分解析処理を説明するためのフローチャートである。
【００７１】
ツリー３１１ｔ及びツリー３１２ｔを参照しながら説明した論理的な変更内容をコンピュータプログラムが直ちに導き出すのは困難である。そこで、まず、変更前後のフォーマット定義ファイルの形式的な（単純な）差分が解析され、その解析結果が単純差分情報として出力される（Ｓ１２１）。
【００７２】
図１３は、単純差分情報の例を示す図である。図１３において、単純差分情報４１では、変更要素ごとに要素タイプ及び変更内容等が示されている。変更要素とは、変更前フォーマット定義ファイル３１１及び変更後フォーマット定義ファイル３１２のいずれかを問わず、変更のあった要素のパス名である。要素タイプとは、ＸＭＬにおいては、タグやそのタグについて属性等を定義することも可能であるため、タグと属性との別を識別するためのものである。変更内容は、変更の種別を示す情報である。このように、形式的な差分とは、フォーマット定義ファイルの変更前後の記述内容を単純に比較することによって導き出される両者の相違点をいい、本実施の形態においては、変更要素の新規追加又は削除のいずれかに判断される。すなわち、形式的な差分の解析において、変更要素の移動や要素名の変更（改名）等、論理的な判断が必要とされる変更は判断されない。
【００７３】
このように、差分として検出された全ての要素が単純差分情報４１として抽出される。
【００７４】
続いて、単純差分情報４１におけるレコード（変更要素）ごとのループ処理が実行される。すなわち、まず、未解決の変更要素の一つが処理対象として選択される（Ｓ１２２）。但し、ここでは、変更内容が「削除」のものが優先的に選択される。ここで選択された変更要素を以下「カレント要素」という。なお、未解決の変更要素とは、変更内容が確定されていない変更要素をいい、初期状態においては全ての変更要素が未解決の変更要素として扱われる。
【００７５】
続いて、カレント要素ついて可能性のある論理的な変更内容が洗い出される（Ｓ１２３）。ここで、論理的な変更内容とは、変更内容が「新規追加」又は「削除」のみならず、「移動」や「要素名変更」といった、その内容を判断するためにある程度の推測を含んだ論理的な解析が必要とされる変更内容をいう。
【００７６】
すなわち、単純差分情報４１から論理的な変更内容は必ずしも一意に導き出すことはできない。例えば、変更内容が「削除」である変更要素であっても、本当に削除された場合、移動された場合、又は要素名が変更された場合等複数の変更内容が考えられるからである。そこで、ここでは考えられる全ての変更内容が洗い出されるというわけである。なお、この処理の詳細については後述する。
【００７７】
続いて、カレント要素の変更内容が一意であるか否か判定される（Ｓ１２４）。カレント要素の変更内容が一意である場合（Ｓ１２４でｙｅｓ）、カレント要素については解決済みであるとしてその変更内容に関する情報を変更パターン情報３４として出力する（Ｓ１２５）。
【００７８】
一方、カレント要素の変更内容が一意でない場合、カレント要素は未解決の変更要素としてその処理は後回しにされる。すなわち、他の変更要素の変更内容が解決されることより、カレント要素の変更内容が絞り込まれる場合があるからである。
【００７９】
ステップＳ１２５又はステップＳ１２４でｎｏの場合に続いて、変更内容が一意に定まる変更要素は出尽くしたか否かが判定される（Ｓ１２６）。出尽くしていない場合は、Ｓ１２２からＳ１２５までの処理が繰り返される。出尽くした場合は、ステップＳ１３０に進む。
【００８０】
ステップＳ１３１において、未解決の変更要素が一つ選択される。ここで選択された変更要素を以下「カレント要素」という。続いてカレント要素について可能性のある論理的な変更内容が洗い出される（Ｓ１３２）。この処理は、ステップＳ１２３と同じ処理である。但し、他の変更要素の変更内容が解決されることによりステップＳ１３２で洗い出される変更内容は前回より少ない可能性がある。
【００８１】
続いて、カレント要素について可能性のある変更内容の中から一つの変更内容が選択される（Ｓ１３３）。ここで選択された変更内容をカレント変更内容という。続いて、カレント要素が最後の変更要素であるか否かが判定され（Ｓ１３４）、最後の変更要素でない場合（Ｓ１３４でｎｏ）、カレント要素の変更内容をカレント変更内容と仮定した場合について、ステップＳ１３０が再帰的に実行される（Ｓ１３５）。すなわち、例えば、カレント要素についての変更内容を「新規追加」であるとした場合、他の全ての未解決の変更要素が取り得る変更内容の中から一つずつ再帰的に選択して、各変更要素の変更内容を組み合わせたものとして矛盾のないもの（変更パターン）を生成するというわけである。
【００８２】
一方、カレント要素が最後の変更要素だった場合は（Ｓ１３４でｙｅｓ）、矛盾のない組み合わせ（変更パターン）が一つ出来上がったものとして、その変更パターンが変更パターン情報３４として出力される（Ｓ１３６）。この際、当該組み合わせに対してステップＳ１２５で解決されている一意に定まる変更内容も付加されて、一つの変更パターンとされる。
【００８３】
続いて、再帰処理のルートとなったカレント要素に関して可能性のある全ての変更内容について処理されたか否かが判定される（Ｓ１３７）。全ての変更内容について処理されていない場合、未処理の変更内容の一つがカレント変更内容とされ、ステップＳ１３４以降の処理が繰り返される。この処理が再帰処理のルートとなったカレント要素の全ての変更内容に対して繰り返されることにより、矛盾のない変更内容の全ての組み合わせが変更パターン情報３４に出力される
図１４は、変更パターン情報の構成例を示す図である。図１４において変更パターン情報３４は、変更要素ごとに、パターンＩＤ、変更要素、要素タイプ、変更内容、移動元及び移動先等の項目から構成される。
【００８４】
パターンＩＤは、各変更パターンを識別するためのＩＤである。すなわち、同一のパターンＩＤを有する一つ以上の変更要素に対する変更内容によって一つの変更パターンが構成される。図１４においては、少なくともパターンＩＤが「１」のものと「２」のものとが表示されている。
【００８５】
変更要素、要素タイプ及び変更内容については、単純差分情報４１（図１３）におけるものと同様である。但し、ここでの変更内容は、新規追加又は削除の別のみでなく、移動や要素名変更といった論理的な変更の別まで特定される。
【００８６】
移動元とは、変更内容が「移動」又は「削除」の変更要素について、変更前に属していた親要素のパス名である。移動先とは、変更内容が「新規追加」、「移動」の変更要素について、新たに属することとなった親要素のパス名、又は「要素名変更」の変更要素についての新たな要素名である。
【００８７】
全ての変更パターンについての処理が完了すると（Ｓ１３７）、各変更パターンに対して確定度が算出され、確定度情報３５として出力される（Ｓ１３８）。
【００８８】
続いて、ステップＳ１２３又はＳ１３２における、変更要素ごとに可能性のある論理的な変更内容を洗い出すための処理、すなわち、単純差分情報４１において「新規追加」と「削除」とのみで表されていた変更内容を「新規追加」、「移動」、「削除」、「種類変更」、及び「要素名変更」等に細分化するための処理の詳細について説明する。なお、種類変更とは、タグで囲まれた要素と、タグ内に定義される属性との間の種類の変更を意味する。
【００８９】
図１５は、一つの変更要素について可能性のある論理的な変更内容を洗い出すための処理を説明するためのフローチャートである。
【００９０】
まず、カレント要素の変更内容が「削除」であるのか「新規追加」であるのかが判定される（Ｓ１２３ａ）。ここで、カレント要素とは、図１２のステップＳ１２２又はＳ１３１において選択されている変更要素である。変更内容が「新規追加」であると判定された場合、カレント要素の変更内容の可能性として「新規追加」が確保される（Ｓ１２３ｂ）。すなわち、新規追加の可能性は常にあるからである。但し、既に他の変更要素の解析によってカレント要素が移動先等とされている場合は「新規追加」の可能性は無いものとして扱われる。なお、ここでは、移動、種類変更、要素名変更等の可能性については考慮しない。これらの変更に関しては単純差分情報４１において変更内容が「削除」の変更要素がペアとして必ず存在するため、後述するように、変更内容が「削除」の変更要素に関する変更内容として洗い出されるからである。
【００９１】
一方、ステップＳ１２３ａにおいてカレント要素の変更内容が「削除」であると判定された場合、単純差分情報４１において変更内容が「新規追加」の変更要素（以下「新規追加要素」という。）が一つ選択される（Ｓ１２３ｃ）。
【００９２】
続いて、カレント要素と新規追加要素との要素名が一致するか否かが判定される（Ｓ１２３ｄ）。一致する場合、要素の種類（タグであるのか属性であるのか）が一致するか否かが判定され（Ｓ１２３ｅ）、要素の種類が同じであればカレント要素の変更内容の可能性として、新規追加要素を移動先とする「移動」が確保される（Ｓ１２３ｆ）。
【００９３】
一方、要素の種類が一致しない場合、カレント要素の変更内容の可能性として「種類変更」が確保される（Ｓ１２３ｇ）。また、カレント要素と新規追加要素との親要素が異なる場合は、新規追加要素を移動先とする「移動」も確保される。すなわち、「種類変更」と「移動」とが同時に行われたものとして扱われる。
【００９４】
また、カレント要素と新規追加要素との要素名が一致しない場合（Ｓ１２３ｄでｎｏ）、カレント要素の変更内容として「要素名変更」の可能性が調査される（Ｓ１２３ｈ）。この処理の詳細については後述する。
【００９５】
ステップＳ１２３ｆ、Ｓ１２３ｇ、又はＳ１２３ｈに続いてステップＳ１２３ｉに進み、単純差分情報４１における全ての新規追加要素について処理が完了したかが判定され、未処理の新規追加要素が残っている場合は、ステップＳ１２３ｃ以降の処理が残りの新規追加要素についても行われる。
【００９６】
全ての新規追加要素について処理が完了している場合は、カレント要素の変更内容の可能性として「削除」が確保され（Ｓ１２３ｊ）、処理が終了する。なお、「削除」が確保されるのは、「削除」の可能性を完全に否定することはできないからである。
【００９７】
続いて、ステップＳ１２３ｈにおける、要素名変更の可能性を調査する処理について説明する。図１６は、要素名変更の可能性の調査処理を説明するためのフローチャートである。
【００９８】
まず、カレント要素の要素名と新規追加要素の要素名との類似度が算出される（Ｓ１２３ｈ-１）。ここで、類似度とは二つの文字列の類似性を示す尺度をいい、一例として以下のような式によって求められる。
【００９９】
類似度  =  一致文字数÷（一致文字数+相違文字数）
例えば、「ｅｍｐｌｏｙｅｅ＿ｎａｍｅ＿ｉｎｆｏｒｍａｔｉｏｎ」と「ｅｍｐ＿ｋａｎａ＿ｎａｍｅ＿ｉｎｆｏ」について考える。両文字列の一致文字数は”ｅｍｐ”の３文字と”＿ｎａｍｅ＿ｉｎｆｏ”の９文字との合計１２文字である。また相違文字数は”ｌｏｙｅｅ”と”＿ｋａｎａ”との文字数の多い方、すなわち”ｌｏｙｅｅ”の５文字と、”ｒｍａｔｉｏｎ”の７文字との合計１２文字である。
【０１００】
したがって類似度は、
１２／（１２+１２）=０．５
となる。
【０１０１】
続いて、類似度が所定の閾値以上であるか否かが判定される（Ｓ１２３ｈ-２）。類似度が所定の閾値より小さい場合は「要素名変更」の可能性は否定される。
【０１０２】
一方、類似度が所定の閾値以上である場合、カレント要素の変更内容の可能性として新規追加要素の要素名を変更後の要素名とする「要素名変更」が確保される（Ｓ１２３ｈ-３）。続いて、変更内容として「移動」が伴っているかが判定される（Ｓ１２３ｈ-４）。「移動」が伴っているか否かは、カレント要素と新規追加要素との親要素の異同を判定することにより行えばよい。「移動」が伴っていると判定された場合、カレント要素の変更内容の可能性として新規追加要素の親要素を移動先とする「移動」が確保される（Ｓ１２３ｈ-５）。
【０１０３】
続いて、図１２のステップＳ１３８における確定度の算出処理について説明する。改めて説明すると、「確定度」とは、変更パターンごとの確からしさのことをいい、複数ある変更パターンに対して順位をつけるための尺度の一例である。
【０１０４】
本実施の形態では、各変更要素について変更内容の候補ごとに重み付けをし、その重み付けについて変更パターンごとの総和をとる。更に、各変更パターンの重み付けの総和を全ての変更パターンの重み付けの総和で除した値が確定度とされる。したがって、各変更要素の変更内容の候補ごとにどのように重み付けを行うかが問題となる。以下、本実施の形態における例を説明する。
【０１０５】
まず、変更内容に応じて重み付けを決める。例えば、
移動  ＞  種類変更  ＞  要素名変更  ＞  新規追加  ＞  削除
となるように重み付けのパラメータ値を０〜１の間で定める。この大小関係は、各変更内容の発生の可能性等に応じて定めればよい。本実施の形態では、例えば、機能拡張に伴って既存のデータ項目が削除される可能性は低いであろうという観点から「削除」に対する重み付けは最小とされている。なお、それぞれの変更内容に対する重み付けパラメータを、a_move（移動）、a_type（種類変更）、a_name（要素名変更）、a_add（新規追加）、a_del（削除）として説明する。
【０１０６】
要素名変更については、上述した類似度を加味する。ここでは類似度をｂとする。
【０１０７】
移動については、移動量の多少を考慮する。すなわち、移動量が少なければ少ないほど確定度は高いものと推測されるからである。ここで、移動量とはデータ構造上（ツリー構造）における移動量をいい、フォーマット定義ファイル上で何行移動したかということではない。例えば、上下一階層の移動量を１として移動量を算出し、その逆数をｃとする。
【０１０８】
また、移動については、移動前後の親要素の名前の類似度が高いほど確定度が高いものと推測される。したがって、親要素の名前の類似度を考慮し、このパラメータをｄとする。
【０１０９】
更に、移動については、複数の要素が同名の要素に移動しているか否かについても考慮し、複数の要素が同名の要素に移動している場合に移動先の要素に新規追加の属性（ＸＭＬにおいてタグに付加される属性）が無いときは確定度を低くする。すなわち、変更前に要素として定義されていたものが、ある要素の属性に種類変更された場合であれば、移動先の要素に新規追加の属性があるはずである。しかし、新規追加の属性が無いということは、移動元の要素は削除されたこととなってしまうところ、上述したように、機能拡張に際して削除される可能性は低いからである。このパラメータをp_dupとする。なお、p_dupの値は０〜１において適当に定め、移動先の要素のタグに属性が追加されている場合はp_dupの値は１とする。
【０１１０】
要素名変更と移動、又は種類変更と移動が同時に起こっているか否かについても考慮し、少なくともいずれかが同時に起こっている場合は確定度を低くする。但し、変更前の要素名と移動先の親要素の要素名が似ている場合、又は移動前の親要素の要素名と変更後の要素名とが似ている場合、確定度を低くする度合いを小さくする。この場合、要素名変更と移動とのそれぞれの確定度の平均をとり、更に、ペナルティパラメータp_multi（０〜１）を乗ずる。変更前の要素名と移動先の親要素の要素名との類似度と、移動前の親要素の要素名と変更後の要素名との類似度とのうち大きい方をfとすると、ペナルティパラメータは以下の式で求めればよい。
【０１１１】
p_multi = δ+（１-δ）・f
ここで、δは、０〜１の範囲を持つ調整パラメータである。
【０１１２】
上記より、変更内容ごとの確定度（s_rec）は、例えば、以下のような式で算出される。
【０１１３】
移動：  s_rec = a_move×（c+γ・d）×p_dup
ここで、γは調整パラメータである。
【０１１４】
種類変更：  s_rec = a_type
要素名変更：  s_rec = a_name×ｂ
追加：  s_rec = a_add
削除：  s_rec = a_del
したがって、一つの変更要素についての確定度（s_el）は、
一つの変更要素について複数の変更が同時に発生していない場合、
s_el = s_rec
一つの変更要素について複数の変更が同時に発生している場合、
s_el =（Σs_rec / 変更の回数）×p_multi
として算出される。
【０１１５】
参考までに、例えば、a_move = 1、a_type=0.8、a_name=0.3、a_add=0.3、a_del=0、γ=0.5、δ=0.3  とした場合に、変更要素の幾つかについて確定度（s_el）を算出してみる。
【０１１６】
「ｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ」の追加については、
確定度：s_el=a_add=0.3
となる。
【０１１７】
「ｅｍｐｌｏｙｅｅ／ｎａｍｅ」の「ｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ」下への移動については、
移動量の逆数：c = 1/1 = 1
親要素の要素名の類似度：d = 0
より、
確定度：s_el = a_move×（c + γd)/(1 + γ) = 0.67
となる。
【０１１８】
「ｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ／ｎａｍｅ」の「ｅｎｇｌｉｓｈ＿ｎａｍｅ」への要素名変更と「ｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ／ｎａｍｅ」の「ｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ」への移動については、
ｎａｍｅとｅｎｇｌｉｓｈ＿ｎａｍｅとの類似度：b = 4 / (4 + 8) = 0.33、
要素名変更の確定度：s_rec = a_name × b = 0.1
「ｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ」から「ｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ」への移動量：2（逆数：c = 0.5）
移動の確定度：s_rec = a_move × (c + γd) / (1 + γ) = 0.47
ここで、移動と要素名変更が同時に起こっているので、p_multiを計算する。
【０１１９】
移動前の親要素の要素名「ｅｎｇｌｉｓｈ＿ｉｎｆｏ」と変更後の要素名「ｅｎｇｌｉｓｈ＿ｎａｍｅ」との類似度：
8 / ( 8 + 5 ) = 0.62
変更前の要素名「ｎａｍｅ」と新規要素の要素名「ｎａｍｅ＿ｉｎｆｏ」との類似度：
4 / ( 4 + 5 ) = 0.44
f = (0.62 と 0.44の大きい方) = 0.62
p_multi = δ + (1 − δ)f = 0.73
よって、
確定度：s_el = (0.1 + 0.47)/2 × 0.73 = 0.21
となる。
【０１２０】
「ｅｎｇｌｉｓｈ＿ｉｎｆｏ」の削除については、
確定度：s_el = a_del = 0
となる。
【０１２１】
このようにして変更パターン情報３４（図１４）の各変更要素について確定度（s_el）を算出し、さらに変更パターンごとについて確定度を算出すると、例えば、図１７に示されるようになる。図１７は、変更要素及び変更パターンについて算出された確定度を示す図である。
【０１２２】
パターンＩＤが１の変更パターン（以下「変更パターン１」といい、他の変更パターンについても同様の命名規則に従うものとする。）の各変更要素についての確定度は、上から順に、0.30、0.67、0.67、0.21、0と算出されている。変更パターン１の確定度（s_pat）は、当該変更パターン１に属する変更要素の確定度の総和であるから、
s_pat = 0.30 + 0.67 + 0.67 + 0.21 + 0 = 1.85
となる。
【０１２３】
また、同様に、変更パターン２の確定度は、1.67と算出される。
【０１２４】
したがって、変更パターン１の方が変更パターン２よりも確定度が高いことがわかる。なお、変更パターンごとの確定度は、確定度情報３５として出力される。
【０１２５】
ところで、各変更パターンの確定度は、当該変更パターンの確定度を全ての変更パターンの確定度の総和で除したもの（すなわち、割合）として先において説明したが、ここでは、パターン１とパターン２のみしか表示されていないため、便宜上絶対値として算出した。
【０１２６】
以上でフォーマット定義ファイル差分解析部１１によるフォーマット定義ファイル差分解析処理についての説明を終える。上述したように、この処理によって、フォーマット定義ファイルの変更について可能性のある変更パターンを示す情報である変更パターン情報３４と、各変更パターンに対する確定度である確定度情報３５とが出力される。
【０１２７】
次に、フォーマット変換ファイル修正部１２によるフォーマット変換ファイル修正処理（図４：Ｓ１４）の詳細について説明する。すなわち、変更パターン情報３４と確定度情報３５とを用いて、連携システムごとのフォーマット変換ファイル３２の全てを自動修正する処理である。説明を容易にするため、ここでは所定の連携システム（以下「連携システムＡ」という。）との間のフォーマット変換ファイルの修正を例として説明する。
【０１２８】
図１８は、連携システムＡについてのフォーマット変換ファイルの修正処理の概要を説明するための図である。
【０１２９】
図１８において、ツリー５１１、ツリー３１１ｔ、ツリー３１２ｔは、それぞれ連携システムＡのデータフォーマット、変更前の統合ＤＢのデータフォーマット、変更後の統合ＤＢのデータフォーマットを示す。
【０１３０】
図中上段におけるツリー５１１とツリー３１１ｔとの間の矢印は、連携システムＡと変更前の統合ＤＢとのフォーマット変換ファイルを示す。すなわち、矢印３２１ａは出力用フォーマット変換ファイルを、矢印３２１ｂは入力用フォーマット変換ファイルを示す。
【０１３１】
同様に図中下段におけるツリー５１１とツリー３１２ｔとの間の矢印は、連携システムＡと変更後の統合ＤＢとのフォーマット変換ファイルを示す。
【０１３２】
したがって、フォーマット変換ファイルの自動修正処理においては、矢印３２１ａによって示される出力用フォーマット変換ファイル（以下「修正前出力用フォーマット変換ファイル３２１ａ」という。）に基づいて矢印３２２ａによって示される出力用フォーマット変換ファイル（以下「修正後出力用フォーマット変換ファイル」という。）が生成され、かつ、矢印３２１ｂによって示される入力用フォーマット変換ファイル（以下「修正前入力用フォーマット変換ファイル３２１ｂ」という。）に基づいて矢印３２２ｂによって示される入力用フォーマット変換ファイル（以下「修正後入力用フォーマット変換ファイル３２２ｂ」という。）が生成される。
【０１３３】
なお、連携システムＡのデータフォーマットは、ツリー５１１から明らかなように、ＥＭＰ要素と、ＥＭＰ要素の子要素としてのＥＭＰ＿ＮＡＭＥ要素、ＥＭＰ＿ＫＡＮＡ要素、及びＥＭＰ＿ＲＯＭＡＮ要素とから構成されているものとする。また、ＥＭＰ要素は、ＥＭＰ＿ＮＯ属性を有するものとする。
【０１３４】
図１９は、修正前後の出力用フォーマット変換ファイルの定義例を示す図である。図１９において、修正前出力用フォーマット変換ファイル３２１ａには、ｅｍｐｌｏｙｅｅ要素はＥＭＰ要素に、ｅｍｐｌｏｙｅｅ／ｅｍｐｌｏｙｅｅ＿ｉｄ要素はＥＭＰ要素のＥＭＰ＿ＮＯ属性に、ｅｍｐｌｏｙｅｅ／ｎａｍｅ要素はＥＭＰ／ＥＭＰ＿ＮＡＭＥ要素に、ｅｍｐｌｏｙｅｅ／ｆｕｒｉｇａｎａ要素はＥＭＰ／ＥＭＰ＿ＫＡＮＡ要素に、ｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ／ｎａｍｅ要素はＥＭＰ／ＥＭＰ＿ＲＯＭＡＮ要素にそれぞれ変換される旨が定義されている。
【０１３５】
一方、修正後出力用フォーマット変換ファイル３２２ａには、ｅｍｐｌｏｙｅｅ要素はＥＭＰ要素に、ｅｍｐｌｏｙｅｅ／ｅｍｐｌｏｙｅｅ＿ｉｄ要素はＥＭＰ要素のＥＭＰ＿ＮＯ属性に、ｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ／ｎａｍｅ要素はＥＭＰ／ＥＭＰ＿ＮＡＭＥ要素に、ｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ／ｆｕｒｉｇａｎａ要素はＥＭＰ／ＥＭＰ＿ＫＡＮＡ要素に、ｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ／ｅｎｇｌｉｓｈ＿ｎａｍｅ要素はＥＭＰ／ＥＭＰ＿ＲＯＭＡＮ要素にそれぞれ変換される旨が定義されている。
【０１３６】
なお、図中破線で囲まれている部分は、修正前後において相互に異なる部分を示す。
【０１３７】
図２０は、修正前後の入力用フォーマット変換ファイルの定義例を示す図である。図２０において、修正前フォーマット変換ファイル３２１ｂには、ＥＭＰ要素はｅｍｐｌｏｙｅｅ要素に、ＥＭＰ＿ＮＯ属性はｅｍｐｌｏｙｅｅ／ｅｍｐｌｏｙｅｅ＿ｉｄ要素に、ＥＭＰ／ＥＭＰ＿ＮＡＭＥ要素はｅｍｐｌｏｙｅｅ／ｎａｍｅ要素に、ＥＭＰ／ＥＭＰ＿ＫＡＮＡ要素はｅｍｐｌｏｙｅｅ／ｆｕｒｉｇａｎａ要素に、ＥＭＰ／ＥＭＰ＿ＲＯＭＡＮ要素はｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ／ｎａｍｅ要素にそれぞれ変換される旨が定義されている。
【０１３８】
一方、修正後入力用フォーマット変換ファイル３２２ｂには、ＥＭＰ要素はｅｍｐｌｏｙｅｅ要素に、ＥＭＰ＿ＮＯ属性はｅｍｐｌｏｙｅｅ／ｅｍｐｌｏｙｅｅ＿ｉｄ要素に、ＥＭＰ／ＥＭＰ＿ＮＡＭＥ要素はｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ／ｎａｍｅ要素に、ＥＭＰ／ＥＭＰ＿ＫＡＮＡ要素はｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ／ｆｕｒｉｇａｎａ要素に、ＥＭＰ／ＥＭＰ＿ＲＯＭＡＮ要素はｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ／ｅｎｇｌｉｓｈ＿ｎａｍｅ要素にそれぞれ変換される旨が定義されている。
【０１３９】
なお、図中破線で囲まれている部分は、修正前後において相互に異なる部分を示す。また、図１９及び図２０において、各行に付されている符号は、後述の説明において使用するものである。
【０１４０】
図２１は、フォーマット変換ファイル修正処理を説明するためのフローチャートである。なお、図２１においては、入力用又は出力用を問わず「フォーマット変換ファイル」として総称する。
【０１４１】
まず、フォーマット変換ファイル修正部１２は、フォーマット変換ファイル３２の中から処理対象とするフォーマット変換ファイルを一つ選択する（Ｓ１４１）。ここで選択されたフォーマット変換ファイルを以下「カレントフォーマット変換ファイル」という。
【０１４２】
続いて、フォーマット変換ファイル修正部１２は、変更パターン情報３４（図１４）から一つの変更パターンを選択する（Ｓ１４２）。ここで選択された変更パターンを以下「カレント変更パターン」という。
【０１４３】
続いて、フォーマット変換ファイル修正部１２は、カレント変更パターンに基づいてカレントフォーマット変換ファイルを修正し、修正結果としてのフォーマット変換ファイルをフォーマット変換ファイル修正結果情報３６として出力する（Ｓ１４３）。
【０１４４】
続いて、フォーマット変換ファイル修正部１２は、全ての変更パターンに基づくカレントフォーマット変換ファイルの修正が完了したか否かを判定する（Ｓ１４４）。全ての変更パターンに基づく修正がなされていない場合は、ステップＳ１４２以降の処理が繰り返される。全ての変更パターン基づく修正が完了している場合、フォーマット変換ファイル修正部１２は、全てのフォーマット変換ファイル３２について修正を行ったか否かを判定する（Ｓ１４５）。未修正のフォーマット変換ファイル３２が存在する場合は、ステップＳ１４１以降の処理が繰り返される。全てのフォーマット変換ファイル３２について処理が完了した場合はフォーマット変換ファイル修正処理が終了する。
【０１４５】
以上の処理手順からも明らかなように、全てのフォーマット変換ファイルに対して全ての変更パターンに基づく修正が自動的に施される。
【０１４６】
続いて、ステップＳ１４３における、変更パターンに基づくフォーマット変換ファイルの修正処理の詳細について説明する。図２２は、変更パターンに基づくフォーマット変換ファイルの修正処理を説明するためのフローチャートである。
【０１４７】
まず、カレント変更パターンを構成する変更要素の中から変更内容に応じた順番（新規追加、要素名変更、種類変更、移動、削除の順番）で一つの変更要素が取り出される（Ｓ１４３ａ）。続いて、取り出された変更要素の変更内容に応じた修正がカレントフォーマット変換ファイルに施される（Ｓ１４３ｂ）。
【０１４８】
続いて、全ての変更要素について処理が完了したか否かが判定され（Ｓ１４３ｃ）、未処理の変更要素がある場合はステップＳ１４３ａ以降の処理が繰り返される。全ての変更要素について処理が完了した場合、修正内容候補マスタ３８（図９）に登録されている修正内容に基づく修正処理がカレントフォーマット変換ファイルに施される（Ｓ１４３ｄ）。すなわち、カレントフォーマット変換ファイル内に適用パターンにマッチする部分が存在するか検査され、マッチする部分がある場合は、当該部分に対して修正結果が適用される。なお、矛盾する複数の修正内容が適用され得る場合は、優先度の最も高い修正内容が適用される。
【０１４９】
修正されたカレントフォーマット変換ファイルは、フォーマット変換ファイル修正結果情報３６として出力される（Ｓ１４３ｅ）。
【０１５０】
続いて、ステップＳ１４３ｂにおける、変更内容に応じたフォーマット変換ファイルの修正について変更内容ごとに説明する。
【０１５１】
新規追加の場合について説明する。図２３は、変更内容が新規追加の場合にフォーマット変換ファイルに施される修正内容を説明するための図である。図２３では、変更パターン情報３４（図１４）の１行目に基づく場合、すなわち、ｅｍｐｌｏｙｅｅ要素下へのｎａｍｅ＿ｉｎｆｏ要素の新規追加に応じた修正例が示されている。なお、図２３の具体例において各行に付されている符号は、図１９又は図２０におけるものに対応しており、以降の図においても同様である。
【０１５２】
図中（Ａ）に示されるように、修正前出力用フォーマット変換ファイル３２１ａに対する修正としては、追加される要素（ｎａｍｅ＿ｉｎｆｏ）を対象とするｘｓｌ：ｔｅｍｐｌａｔｅ要素が追加される（記述３２２ａー２５、記述３２２ａ−３１）。
【０１５３】
また、図中（Ｂ）に示されるように、修正前入力用フォーマット変換ファイルに３２１ｂに対する修正としては、追加先となる親要素（ｅｍｐｌｏｙｅｅ）が検索され、その親要素内（記述３２１ｂ−５〜記述３２１ｂ−１２）に、追加される要素（ｎａｍｅｉｎｆｏ）の開始タグ及び終了タグが追加される（記述３２２ｂ−７及び１１）。
【０１５４】
要素名変更の場合について説明する。図２４は、変更内容が要素名変更の場合にフォーマット変換ファイルに施される修正内容を説明するための図である。図２４では、変更パターン情報３４（図１４）の４行目に基づく場合、すなわち、ｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ／ｎａｍｅ要素の要素名（ｎａｍｅ）のｅｎｇｌｉｓｈ＿ｎａｍｅへの変更に応じた修正例が示されている。
【０１５５】
図中（Ａ）に示されるように、修正前出力用フォーマット変換ファイル３２１ａに対する修正としては、まず、＜ｘｓｌ：ｖａｌｕｅ−ｏｆ  ｓｅｌｅｃｔ＝”式”＞タグや＜ｘｓｌ：ｔｅｍｐｌａｔｅ  ｍａｔｃｈ＝”パターン”＞タグ等における式やパターンのように、ＸＳＬＴ処理の対象とする要素を特定するための文字列の中から変更元の要素名（ｎａｍｅ）と一致するものが検索される。続いて、検索された文字列が変更先の要素名（ｅｎｇｌｉｓｈ＿ｎａｍｅ）に置換される（記述３２２ａ−２９）。但し、要素名が一致したとしてもパス（ｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ）が一致しない場合は置換の対象とはされない。
【０１５６】
また、図中（Ｂ）に示されるように、修正前入力用フォーマット変換ファイル３２１ｂに対する修正としては、変更前の要素名（ｎａｍｅ）と一致するタグ名が検索され、検索されたタグ名が変更先の要素名（ｅｎｇｌｉｓｈ＿ｉｎｆｏ）に置換される（記述３２２ｂ−３０、記述３２２ｂ−３２）。但し、要素名が一致したとしてもパス（ｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ）が一致しない場合は置換の対象とはされない。
【０１５７】
移動の場合について説明する。図２５は、変更内容が移動の場合に出力用フォーマット変換ファイルに施される修正内容を説明するための図である。図２５では、変更パターン情報３４（図１４）の２行目に基づく場合、すなわち、ｅｍｐｌｏｙｅｅ／ｎａｍｅ要素のｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ下への移動に応じた修正例が示されている。
【０１５８】
まず、ＸＳＬＴ処理の対象とされる要素を特定するための文字列の中から移動対象となる要素の要素名（ｎａｍｅ）と一致するものが検索される（記述３２１ａ−９）（但し、移動元のパス（ｅｍｐｌｏｙｅｅ）と一致するもののみが対象とされる）。続いて、検索された文字列が属する要素（記述３２１ａ−９）の兄弟要素（親要素（ＥＭＰ）を同じくする要素）として、移動先の親要素（ｎａｍｅ＿ｉｎｆｏ）を対象とするｘｓｌ：ａｐｐｌｙ−ｔｅｍｐｌａｔｅｓ要素が生成される（記述３２２ａ−９）。但し、当該要素が既に存在する場合は生成されない。続いて、最初に検索された文字列が属する要素（記述３２２ａ−９）が、移動先の親要素（ｎａｍｅ＿ｉｎｆｏ）を対象とするｘｓｌ：ｔｅｍｐｌａｔｅ要素（記述３２２ａ−２５）の子要素として移動される（記述３２２ａ−２６）。
【０１５９】
また、図２６は、変更内容が移動の場合に入力用フォーマット変換ファイルに施される修正内容を説明するための図である。図２６においても、変更パターン情報３４（図１４）の２行目に基づく場合、すなわち、ｅｍｐｌｏｙｅｅ／ｎａｍｅ要素のｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ下への移動に応じた修正例が示されている。
【０１６０】
まず、移動対象となる要素の要素名（ｎａｍｅ）をタグ名とするタグが検索される（記述３２１ｂ−２０）。続いて、検索されたタグが属するテンプレート（記述３２１ｂ−１９）を呼び出しているｘｓｌ：ａｐｐｌｙ−ｔｅｍｐｌａｔｅｓ要素が検索され（記述３２１ｂ−７）、検索された要素（記述３２１ｂ−７）が移動先としての要素（ｎａｍｅ＿ｉｎｆｏ：記述３２２ｂ−７〜記述３２２ｂ−１１）内に移動される（記述３２２ｂ−８）。
【０１６１】
なお、ｅｍｐｌｏｙｅｅ／ｆｕｒｉｇａｎａ等、他の要素の移動についても図２５及び図２６と同様に処理される。
【０１６２】
削除の場合について説明する。図２７は、変更内容が削除の場合にフォーマット変換ファイルに施される修正内容を説明するための図である。図２７では、変更パターン情報３４（図１４）の６行目に基づく場合、すなわち、ｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ要素の削除に応じた修正例が示されている。
【０１６３】
図中（Ａ）に示されるように、修正前出力用フォーマット変換ファイル３２１ａに対する修正としては、削除対象とされている要素（ｅｎｇｌｉｓｈ＿ｉｎｆｏ）に対するテンプレート要素（記述３２１ａ−２７、記述３２１ａ−３１）が削除され、更に、当該テンプレートを参照しているｘｓｌ：ａｐｐｌｙ−ｔｅｍｐｌａｔｅｓ要素（記述３２１ａ−１１）が削除される。
【０１６４】
また、図中（Ｂ）に示されるように、修正前入力用フォーマット変換ファイルに３２１ｂに対する修正としては、削除対象とされている要素の要素名（ｅｎｇｌｉｓｈ＿ｉｎｆｏ）をタグ名とするタグ（記述３２１ｂ−９、記述３２１ｂ−１１）が削除される。
【０１６５】
以上でフォーマット変換ファイル修正部１２によるフォーマット変換ファイル修正処理についての説明を終える。上述したように、この処理によって、既存の全てのフォーマット変換ファイル３２に対して全ての変更パターンに基づく修正が施され、フォーマット変換ファイル修正結果情報３６として出力される。
【０１６６】
次に、テストケース修正部１３によるテストケース修正処理（図４：Ｓ１６）の詳細について説明する。すなわち、変更パターン情報３４と確定度情報３５とを用いて、連携システムごとのテストケース情報３３の全てを自動修正する処理である。説明を容易にするため、連携システムＡに関するテストケース情報３３の修正を例として説明する。
【０１６７】
図２８は、入力用フォーマット変換ファイルのテストに用いられるテストケース情報を示す図である。図２８において、テスト用入力データ３３１は、連携システムＡのデータフォーマット（図１８：ツリー５１１）に基づくテスト用の入力データである。修正前検証データ３３２ａは、変更前の統合ＤＢのデータフォーマット（図１８：ツリー３１１ｔ）に基づく検証用データである。修正後検証データ３３２ｂは、変更後の統合ＤＢのデータフォーマットに基づく検証用データである。
【０１６８】
入力用フォーマット変換ファイル３２ａのテストは、入力用フォーマット変換ファイル３２ａに、テスト用入力データ３３１の変換を行わせ、その変換結果として統合ＤＢに登録された情報と、検証用データとを比較するというものである。ここで統合ＤＢのデータフォーマットに依存するデータは、検証用データであるため、入力用フォーマット変換ファイルのテストに用いられるテストケース情報３３のうち修正対象となるのは、検証用データに限定される。したがって、修正前検証用データ３３２ａを修正して修正後検証用データ３３２ｂを生成する処理がテストケース情報の修正処理の一つとなる。
【０１６９】
また、図２９は、出力用フォーマット変換ファイルのテストに用いられるテストケース情報を示す図である。図２９において、修正前テスト用初期データ３３３ａは、変更前の統合ＤＢのデータフォーマットに基づくテスト用の初期データである。修正後テスト用初期データ３３３ｂは、変更後の統合ＤＢのデータフォーマットに基づくテスト用の初期データである。検証データ３３４は、連携システムＡのデータフォーマットに基づくテスト用の検証データである。
【０１７０】
出力用フォーマット変換ファイル３２ｂのテストは、統合ＤＢに格納されているテスト用初期データの変換を出力用フォーマット変換ファイル３２ｂに行わせ、その変換結果として出力された情報と、検証用データ３３４とを比較するというものである。ここで統合ＤＢのデータフォーマットに依存するデータは、テスト用初期データであるため、出力用フォーマット変換ファイルのテストに用いられるテストケース情報３３のうち修正対象となるのは、テスト用初期データに限定される。したがって、修正前テスト用初期データ３３３ａを修正して修正後テスト用初期データ３３３ｂを生成する処理がテストケース情報の修正処理のもう一つとなる。
【０１７１】
図３０は、テストケース修正処理を説明するためのフローチャートである。なお、図３０においては、検証データ又はテスト用初期データを問わず「テストケース情報３３」として総称する。
【０１７２】
まず、テストケース修正部１３は、テストケース情報３３の中から処理対象とするテストケース情報を一つ選択する（Ｓ１６１）。ここで選択されたテストケース情報を以下「カレントテストケース情報」という。
【０１７３】
続いて、テストケース修正部１３は、変更パターン情報３４（図１４）から一つの変更パターンを選択する（Ｓ１６２）。ここで選択された変更パターンを以下「カレント変更パターン」という。
【０１７４】
続いて、テストケース修正部１３は、カレント変更パターンに基づいてカレントテストケース情報を修正し、修正結果としてのテストケース情報をテストケース修正結果情報３７として出力する（Ｓ１６３）。
【０１７５】
続いて、テストケース修正部１３は、全ての変更パターンに基づいてカレントテストケース情報を修正したか否かを判定する（Ｓ１６４）。全ての変更パターンに基づく修正がなされていない場合は、ステップＳ１６２以降の処理が繰り返される。全ての変更パターン基づく修正が完了している場合、テストケース修正部１３は、全てのテストケース情報３３について修正を行ったか否かを判定する（Ｓ１６５）。未修正のテストケース情報３３が存在する場合は、ステップＳ１６１以降の処理が繰り返される。全てのテストケース情報３３について処理が完了した場合はテストケース修正処理が終了する。
【０１７６】
以上の処理手順からも明らかなように、全てのテストケース情報３３に対して全ての変更パターンに基づく修正が自動的に施される。
【０１７７】
続いて、ステップＳ１６３における、変更パターンに基づくテストケース情報の修正処理の詳細について説明する。図３１は、変更パターンに基づくテストケース情報の修正処理を説明するためのフローチャートである。
【０１７８】
まず、カレント変更パターンを構成する変更要素の中から変更内容に応じた順番（新規追加、要素名変更、種類変更、移動、削除の順番）で一つの変更要素が取り出される（Ｓ１６３ａ）。続いて、取り出された変更要素の変更内容に応じた修正がカレントテストケース情報に施される（Ｓ１６３ｂ）。
【０１７９】
続いて、全ての変更要素について処理が完了したか否かが判定され（Ｓ１６３ｃ）、未処理の変更要素がある場合はステップＳ１６３ａ以降の処理が繰り返される。全ての変更要素について処理が完了した場合、修正内容候補マスタ３８（図９）に登録されている修正内容に基づく修正処理がカレントテストケース情報に施される（Ｓ１６３ｄ）。すなわち、カレントテストケース情報内に適用パターンにマッチする部分が存在するか検査され、マッチする部分がある場合は、当該部分に対して修正結果が適用される。なお、矛盾する複数の修正内容が適用され得る場合は、優先度の最も高い修正内容が適用される。
【０１８０】
修正されたカレントテストケース情報は、テストケース修正結果情報３７として出力される（Ｓ１６３ｅ）。
【０１８１】
続いて、ステップＳ１６３ｂにおける、変更内容に応じたテストケース情報の修正について説明する。図３２は、変更内容に応じてテストケース情報に施される修正内容を説明するための図である。ところで、図２８及び図２９から明らかなように、修正前検証データ３３２ａ（図２８）と修正前テスト用初期データ３３３ａ（図２９）は、全く同一のものでよい。また、その場合、修正後検証データ３３２ｂ（図２８）と修正後テスト用初期データ３３３ｂとも全く同一のものとなる。したがって、ここでは、変更パターン情報３４（図１４）の変更パターン１に基づいて、修正前検証データ３３２ａを修正する例についてのみ説明する。
【０１８２】
テストケース情報３３の修正において修正対象となる情報は、統合ＤＢのデータフォーマットに基づくものである。また、変更パターン情報３４は、統合ＤＢのデータフォーマットの変更に関しての変更パターンを示す情報である。したがって、テストケース情報３３の修正は、変更パターン情報３４に示されている通りに行えばよい。
【０１８３】
新規追加（Ｓ５１）については、対象となる要素（ｎａｍｅ＿ｉｎｆｏ）が追加されるべき要素（ｅｍｐｌｏｙｅｅ）内に追加される（記述３３２ｂ−１、記述３３２ｂ−７）。
【０１８４】
要素名変更（Ｓ５２）については、対象となる要素名（ｎａｍｅ）が変更されるべき要素名（ｅｎｇｌｉｓｈ＿ｎａｍｅ）に置換される（記述３３２ｂ−６）。
【０１８５】
移動（Ｓ５３）については、対象となる要素（ｅｍｐｌｏｙｅｅ／ｎａｍｅ、ｅｍｐｌｏｙｅｅ／ｆｕｒｉｇａｎａ、ｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ／ｎａｍｅ）が移動されるべき要素内（ｅｍｐｌｏｙｅｅ／ｎａｍｅ＿ｉｎｆｏ）に移動される（記述３３２ｂ−４、５、６）。
【０１８６】
削除（Ｓ５４）については、対象となる要素（ｅｍｐｌｏｙｅｅ／ｅｎｇｌｉｓｈ＿ｉｎｆｏ）が削除される（記述３３２ａ−５、７）。
【０１８７】
以上でテストケース修正部１３によるテストケース修正処理についての説明を終える。上述したように、この処理によって、既存の全てのテストケース情報３３に対して全ての変更パターンに基づく修正が施され、テストケース修正結果情報３７として出力される。
【０１８８】
上述したように、本発明の実施の形態におけるフォーマット変換ファイル修正装置１０によれば、統合ＤＢの変更前後のフォーマット定義ファイルに基づいて、自動的に変更内容を推測し、推測された変更内容に基づいて既存フォーマット変換ファイル３２及びテストケース情報３３を自動的に修正することができる。また、修正されたフォーマット変換ファイル及びテストケース情報を用いて自動的にテストを実行することができる。したがって、統合ＤＢの仕様変更に伴う作業工数を軽減させることができ、また、手作業によるバグの混入を防止することもできる。
【０１８９】
また、変更パターンが複数存在する場合は、それらをユーザに閲覧させることにより、ユーザに選択の余地が与えられるため、より適切な修正を施すことができる。その際、各変更パターンについては確定度が算出され、ユーザに提示されるため、ユーザは変更パターンの選択に当たって有効な判断基準を得ることができる。
【０１９０】
また、統合ＤＢの仕様変更に伴う作業工数が軽減されることにより、ユーザは、安心して統合ＤＢの機能拡張を行うことができる。
【０１９１】
また、統合ＤＢの保守作業が軽減されるため、統合ＤＢを一般的なパッケージとして導入することができる。既にサポートしているシステム間の連係であればそのまま導入が可能で、統合ＤＢのバージョンアップも顧客ごとではない、共通の最新版に置き換える事で可能になる。
【０１９２】
以上、本発明の実施例について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【０１９３】
以上の説明に関し、更に以下の項を開示する。
（付記１）  第一のデータフォーマットの定義情報の変更に基づいて前記第一のデータフォーマットと第二のデータフォーマットとの変換規則の定義情報の修正をコンピュータに実行させる変換規則修正プログラムであって、
前記第一のデータフォーマットの変更前後の定義情報の形式的な差分を求め、該差分に基づいて前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報を導出する解析手順と、
前記解析手順において導出された前記論理的な変更情報に基づいて、前記変換規則の定義情報を修正する第一の修正手順とを有することを特徴とする変換規則修正プログラム。
（付記２）  前記解析手順は、該差分に基づいて、前記論理的な変更情報として取り得る複数のパターンを導出し、
前記第一の修正手順は、前記複数のパターンのそれぞれに基づいて前記変換規則の定義情報を修正することを特徴とする付記１記載の変換規則修正プログラム。
（付記３）  前記論理的な変更情報を構成する変更要素ごとに、当該変更要素ごとの変更内容に応じた確定度を算出し、該確定度に基づいて前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報に対する確定度を算出する確定度算出手順を有することを特徴とする付記１又は２記載の変更規則修正プログラム。
（付記４）  前記解析手順において導出された前記論理的な変更情報に基づいて、変更前の前記第一のデータフォーマットに基づくデータを変更後の前記第一のデータフォーマットに基づくデータに修正する第二の修正手順を有することを特徴とする付記１乃至３いずれか一項記載の変換規則修正プログラム。
（付記５）  前記第二の修正手順において修正されたデータを用いて、前記第一の修正手順において修正された前記変換規則の定義情報の検証を行う検証手順を有することを特徴とする付記４記載の変換規則修正プログラム。
（付記６）  前記第一の修正手順における修正結果を提示し、提示された修正結果に対する修正を入力させるための画面を表示装置に表示させる修正結果表示手順を有することを特徴とする付記１乃至５いずれか一項記載の変換規則修正プログラム。
（付記７）  前記解析手順は、前記差分を構成する変更要素ごとに前記論理的な変更情報を解析し、前記変更要素ごとの前記論理的な変更情報を組み合わせることにより前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報を導出することを特徴とする付記１乃至６いずれか一項記載の変更規則修正プログラム。
（付記８）  前記第一の修正手順は、前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報を構成する変更要素ごとの変更内容に応じた修正を前記変換規則の定義情報に施すことを特徴とする付記１乃至７いずれか一項記載の変更規則修正プログラム。
（付記９）  前記第二の修正手順は、前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報を構成する変更要素ごとの変更内容に応じた修正を変更前の前記第一のデータフォーマットに基づくデータに施すことを特徴とする付記４又は５記載の変更規則修正プログラム。
（付記１０）  第一のデータフォーマットの定義情報の変更に基づいて前記第一のデータフォーマットと第二のデータフォーマットとの変換規則の定義情報を修正する変換規則修正装置であって、
前記第一のデータフォーマットの変更前後の定義情報の形式的な差分を求め、該差分に基づいて前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報を導出する解析手段と、
前記解析手段が導出した前記論理的な変更情報に基づいて、前記変換規則の定義情報を修正する第一の修正手段とを有することを特徴とする変換規則修正装置。
（付記１１）  第一のデータフォーマットの定義情報の変更に基づいて前記第一のデータフォーマットと第二のデータフォーマットとの変換規則の定義情報の修正をコンピュータを用いて行う変換規則修正方法であって、
前記第一のデータフォーマットの変更前後の定義情報の形式的な差分を求め、該差分に基づいて前記第一のデータフォーマットの定義情報の変更に関する論理的な変更情報を導出する解析手順と、
前記解析手順において導出された前記論理的な変更情報に基づいて、前記変換規則の定義情報を修正する第一の修正手順とを有することを特徴とする変換規則修正方法。
（付記１２）  付記１乃至９いずれか一項記載の変更規則修正プログラムを記録したコンピュータ読み取り可能な記録媒体。
【図面の簡単な説明】
【０１９４】
【図１】統合ＤＢを介したシステム間のデータ連携を説明するための概念図である。
【図２】本発明の実施の形態におけるフォーマット変換ファイル修正装置のハードウェア構成例を示す図である。
【図３】本発明の実施の形態におけるフォーマット変換ファイル修正装置の機能構成例を示す図である。
【図４】フォーマット変換ファイル修正装置の処理概要を説明するためのフローチャートである。
【図５】新規統合ＤＢフォーマット指定画面の表示例を示す図である。
【図６】テストケース情報を説明するための図である。
【図７】修正内容確認画面の表示例を示す図である。
【図８】修正内容候補編集画面の表示例を示す図である。
【図９】修正内容候補マスタの構成例を示す図である。
【図１０】本発明の実施の形態における統合ＤＢの変更前後のフォーマット定義ファイルの例を示す図である。
【図１１】変更前後のフォーマット定義ファイルに基づく統合ＤＢの具体的なＸＭＬデータの例である。
【図１２】フォーマット定義ファイル差分解析処理を説明するためのフローチャートである。
【図１３】単純差分情報の例を示す図である。
【図１４】変更パターン情報の構成例を示す図である。
【図１５】一つの変更要素について可能性のある論理的な変更内容を洗い出すための処理を説明するためのフローチャートである。
【図１６】要素名変更の可能性の調査処理を説明するためのフローチャートである。
【図１７】変更要素及び変更パターンについて算出された確定度を示す図である。
【図１８】連携システムＡについてのフォーマット変換ファイルの修正処理の概要を説明するための図である。
【図１９】修正前後の出力用フォーマット変換ファイルの定義例を示す図である。
【図２０】修正前後の入力用フォーマット変換ファイルの定義例を示す図である。
【図２１】フォーマット変換ファイル修正処理を説明するためのフローチャートである。
【図２２】変更パターンに基づくフォーマット変換ファイルの修正処理を説明するためのフローチャートである。
【図２３】変更内容が新規追加の場合にフォーマット変換ファイルに施される修正内容を説明するための図である。
【図２４】変更内容が要素名変更の場合にフォーマット変換ファイルに施される修正内容を説明するための図である。
【図２５】変更内容が移動の場合に出力用フォーマット変換ファイルに施される修正内容を説明するための図である。
【図２６】変更内容が移動の場合に入力用フォーマット変換ファイルに施される修正内容を説明するための図である。
【図２７】変更内容が削除の場合にフォーマット変換ファイルに施される修正内容を説明するための図である。
【図２８】入力用フォーマット変換ファイルのテストに用いられるテストケース情報を示す図である。
【図２９】出力用フォーマット変換ファイルのテストに用いられるテストケース情報を示す図である。
【図３０】テストケース修正処理を説明するためのフローチャートである。
【図３１】変更パターンに基づくテストケース情報の修正処理を説明するためのフローチャートである。
【図３２】変更内容に応じてテストケース情報に施される修正内容を説明するための図である。
【符号の説明】
【０１９５】
１０          フォーマット変換ファイル修正装置
１１          フォーマット定義ファイル差分解析部
１２          フォーマット変換ファイル修正部
１３          テストケース修正部
１４          テスト実行部
２１          新規統合ＤＢフォーマット指定画面
２２          修正内容確認画面
２３          修正内容候補編集画面
２４          テスト結果表示画面
３１          統合ＤＢフォーマット定義ファイル
３２          フォーマット変換ファイル
３３          テストケース情報
３４          変更パターン情報
３５          確定度情報
３６          フォーマット変換ファイル修正結果情報
３７          テストケース修正結果情報
３８          修正内容候補マスタ
３９          テスト結果情報
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        演算処理装置
１０５        表示装置
１０６        入力装置
Ｂ            バス
【図１】
2006277662.tif 000003
【図２】
2006277662.tif 000004
【図３】
2006277662.tif 000005
【図４】
2006277662.tif 000006
【図５】
2006277662.tif 000007
【図６】
2006277662.tif 000008
【図７】
2006277662.tif 000009
【図８】
2006277662.tif 000010
【図９】
2006277662.tif 000011
【図１０】
2006277662.tif 000012
【図１１】
2006277662.tif 000013
【図１２】
2006277662.tif 000014
【図１３】
2006277662.tif 000015
【図１４】
2006277662.tif 000016
【図１５】
2006277662.tif 000017
【図１６】
2006277662.tif 000018
【図１７】
2006277662.tif 000019
【図１８】
2006277662.tif 000020
【図１９】
2006277662.tif 000021
【図２０】
2006277662.tif 000022
【図２１】
2006277662.tif 000023
【図２２】
2006277662.tif 000024
【図２３】
2006277662.tif 000025
【図２４】
2006277662.tif 000026
【図２５】
2006277662.tif 000027
【図２６】
2006277662.tif 000028
【図２７】
2006277662.tif 000029
【図２８】
2006277662.tif 000030
【図２９】
2006277662.tif 000031
【図３０】
2006277662.tif 000032
【図３１】
2006277662.tif 000033
【図３２】
2006277662.tif 000034