(57)【要約】【課題】  プログラムのバージョンアップ時にカスタマイズ内容の反映およびその影響範囲の特定を容易にする手段を提供する。【解決手段】  対象プログラムと標準プログラムとのソースコードファイルによる比較を行い、バージョンアッププログラムと標準プログラムとのソースコードファイルによる比較を行い、各比較結果を元に種別判定を行う。種別判定結果を元に対象プログラムにバージョンアップを適用するためのソースコードファイルごとの修正方法を判定し、修正による影響範囲の特定に必要な情報を算出する。【選択図】  図１
2015076025.tif 000002
【特許請求の範囲】
【請求項１】
ソース比較処理部が、対象ソースコードを、第1の標準ソースコードと比較する第1の比較工程と、
ソース比較処理部が、前記第1の標準ソースコードを、前記第1の標準ソースコードの同じソースコードのバージョン違いである第2の標準ソースコードと比較する第２の比較工程と、
種別判定処理部が、前記第1の比較工程の比較結果と、前記第２の比較工程の比較結果とに基いて、前記第２の標準ソースコードにかかるバージョンへの前記対象ソースコードのバージョンアップの方針を判定する判定工程と、
を含むことを特徴とするバージョンアップ支援方法。
【請求項２】
請求項１において、
前記対象ソースコード、前記第１の標準ソースコード及び第２の標準ソースコードは、それぞれ複数のファイルを有し、
前記第１及び第２の工程、判定工程では、前記ファイルごとに比較結果及び判定結果を作成することを特徴とするバージョンアップ支援方法。
【請求項３】
請求項２において、
前記第1の比較工程及び前記第２の比較工程では、前記複数のファイルのファイル名に基いて、比較対象とするファイルを決定することを特徴とするバージョンアップ支援方法。
【請求項４】
請求項３において、
前記第１及び前記第２の比較工程の比較結果は、差分有り、差分無し、新規及び削除を含むことを特徴とするバージョンアップ支援方法。
【請求項５】
請求項１乃至４のいずれかにおいて、
前記第１の比較の結果では差分無しであり、前記第２の比較の結果では差分有りの場合、前記判定結果として、前記対象ソースコードに前記第２の標準ソースコードへ適用可能であることを出力することを特徴とするバージョンアップ支援方法。
【請求項６】
請求項１乃至４のいずれかにおいて、
前記第１の比較の結果では差分有りであり、前記第２の比較の結果では差分無しの場合、前記判定結果としてバージョンアップ不要であることを出力することを特徴とするバージョンアップ支援方法。
【請求項７】
請求項２乃至４のいずれかにおいて、
影響範囲算出部が、前記複数のファイルの呼び出し関係情報と、前記判定結果に基いて、バージョンアップの影響範囲を算出することを特徴とするバージョンアップ支援方法。
【請求項８】
対象ソースコードを、第1の標準ソースコードと比較する第1の比較工程と、前記第1の標準ソースコードを、前記第1の標準ソースコードの同じソースコードのバージョン違いである第２の標準ソースコードと比較する第２」の比較工程と、を行うソース比較処理部と、
前記第1の比較工程の比較結果と、前記第２の比較工程の比較結果とに基いて、前記第２の標準ソースコードにかかるバージョンへの前記対象ソースコードのバージョンアップの方針を判定する判定工程を行う種別判定処理部と、
を備えたことを特徴とするバージョンアップ支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラムの更新技術に関する。
【背景技術】
【０００２】
例えば、業務システム構築時にパッケージソフトウェアを適用する場合、顧客・ユーザの要求に応じて改修（カスタマイズ）が行われる。
【０００３】
このカスタマイズ済みパッケージソフトウェアの元となるパッケージソフトウェアに対して機能追加などのバージョンアップが実施された場合、従来ではカスタマイズ済みのソースコードファイルとバージョンアップされたソースコードファイルを単純比較することで、変更点の洗い出しを行っている。
【０００４】
このような変更点の洗い出しでは、カスタマイズ箇所とバージョンアップ箇所との選別が機械的にできないため、人手によるチェック作業が必要となり、チェック漏れなどの問題が発生する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１２−１５９９３１号公報
【特許文献２】特開２００６−２７６９５３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１の技術では、パッケージソフトウェアの顧客・ユーザ別のカスタマイズの内容（カスタマイズ実績）をデータベースで一元管理して、当該パッケージソフトウェアの変更情報から顧客・ユーザ別のカスタマイズへの影響の有無の判別と、影響するオブジェクトの抽出を自動的に行うようにしている。
【０００７】
しかし、カスタマイズを実施した対象以外のバージョンアップの判別は行われないため、カスタマイズを行っていないオブジェクトへのバージョンアップ内容の判別は別途手作業で実施する必要がある。また、管理する内容はどのオブジェクトをどう変更したかの書類のみであり、ソースコードファイル実体による管理を行わないため、実体とのズレが生じる可能性がある。
【０００８】
特許文献２の技術では、カスタマイズされた画面定義ファイルに対するバージョンアップを反映する技術を提供している。カスタマイズの元のパッケージソフトウェアをバージョンアップしたことによって画面項目の追加や変更があった場合に、バージョンアップの内容をカスタマイズしたパッケージソフトウェアに反映すべきかどうかを確認するために、バージョンアップによる画面項目の追加や変更をカスタマイズしたパッケージソフトウェアへ反映して画面表示するというものである。特許文献２は画面定義ファイルに対するバージョンアップの反映に関する技術であり、画面定義ファイル以外のものを適用した場合は対応できない。また、特許文献１と同様にカスタマイズを実施していない画面定義ファイルのバージョンアップについては対象としていない。
【０００９】
本発明が解決しようとする問題点は、カスタマイズを行ったプログラムの元となるプログラムにバージョンアップが発生した場合、バージョンアップによる影響範囲を考慮しつつ、ソースコードファイル実体を元にして、ソースコードファイルごとのバージョンアップの有無およびカスタマイズの有無の判別を機械的に行う手段がない点。
【課題を解決するための手段】
【００１０】
本発明は、分析対象ソースコードを、分析対象ファイルと旧バージョンプログラムのソースコードファイル（旧バージョン標準ソースコード）との比較結果、および、旧バージョンプログラムと旧バージョンプログラムに機能追加などを行ってバージョンアップした新バージョンプログラムのソースコードファイル（新バージョン標準ソースコード）とのの比較結果を元に種別判定を行い、種別判定結果からバージョンアップによる影響範囲を考慮しつつ分析対象ソースコードのファイルごとのバージョンアップ方法を判定する。
【発明の効果】
【００１１】
本発明のシステムにより、プログラムのバージョンアップ時にカスタマイズプログラムへのバージョンアップ内容の反映および影響範囲の特定が容易となる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施例にかかるプログラムバージョンアップ支援システムの構成図である。
【図２】本発明の実施例にかかる名称変換処理部のフローチャートである。
【図３】本発明の実施例にかかるソース比較処理部のフローチャートである。
【図４】本発明の実施例にかかる分析対象ソースコードを比較元にした旧バージョン標準ソースコードの比較結果例である。
【図５】本発明の実施例にかかる旧バージョン標準ソースコードを比較元にした分析対象ソースコードとの比較結果例である。
【図６】本発明の実施例にかかる種別判定処理部のフローチャートである。
【図７】本発明の実施例にかかる比較結果からの種別判定結果とソースコード修正方法の一覧である。
【図８】本発明の実施例にかかる種別判定結果ファイルの例である。
【図９】本発明の実施例にかかる種別による影響範囲のイメージである。
【発明を実施するための形態】
【００１３】
以下、本発明の実施形態について図面を使用して詳細に説明する。
【実施例１】
【００１４】
図１はプログラムバージョンアップ支援システムを表す構成図である。
【００１５】
プログラムバージョンアップ支援システム１００は、例えば、一般的な計算機（コンピュータやサーバなど）で実現され、ＣＰＵ（Central Processing Unit）１１０、ＣＰＵが実行するプログラムや各種データを記憶するHDDや半導体メモリ等の記憶装置１１１、キーボード・マウス等の入力装置（図示せず）、ディスプレイ等の出力装置（図示せず）を有する。
【００１６】
分析対象ソースコード１３０は標準ソースコードを元に顧客要望などの利用者固有のカスタマイズを実施し、元にしたソースコードのバージョンやカスタマイズ後のバージョンアップにより旧バージョン標準ソースコード１３１と同じバージョン番号を有するソースコードである。また、旧バージョン標準ソースコード１３１に対して機能追加や不具合対策などを実施したものが新バージョン標準ソースコード１３２である。旧バージョン標準ソースコード１３１および新バージョン標準ソースコード１３２は分析対象ソースコード１３０の比較対象ソースコードである。分析対象ソースコード１３０、旧バージョン標準ソースコード１３１、新バージョン標準ソースコード１３２はそれぞれ１ファイル以上のソースコードファイルで構成される。本実施例では、複数のソースコードファイルで構成される場合を例にとって説明する。
【００１７】
本実施例では、分析対象ソースコード１３０に対して、新バージョン標準ソースコード１３２で実施された新機能の追加や不具合対策の反映を行うため、ソースコードファイル単位の修正方法を判定し、それを元に影響範囲の特定が可能となる情報の出力を行う。単純に、分析対象ソースコード１３０のソースコードファイルと新バージョン標準ソースコード１３２のソースコードファイルの比較を行ってしまうと、新バージョン標準ソースコード１３２での変更のみならずカスタマイズされている部分も差分となってしまうため、バージョンアップによる差分のみの抽出ができない。そこで、ソースコードファイルごとに、分析対象ソースコード１３０と旧バージョン標準ソースコード１３１との差分（カスタマイズ差分）、旧バージョン標準ソースコード１３２と新バージョン標準ソースコード１３３との差分（バージョンアップ差分）の抽出を行い、さらにソースコードファイルごとのカスタマイズ差分およびバージョンアップ差分の有無により種別を判定することで、ソースコードファイルの修正方法および影響範囲の特定を行える情報を提供することができる。また、これらの出力情報を利用して分析対象ソースコードのソースコードファイルの更新を自動化することも可能である。なお、比較単位をアプリケーション単位とすると、判定が粗くなり一部の自動バージョンアップできないファイルのためにアプリケーション全体を手動でバージョンアップするよう判定され、またファイル間の影響調査も実施できない。ソースコードファイルの行単位の比較結果を出力してもソースコードファイルの置換えを実施するのはファイル単位であるため、本発明ではファイル単位での比較結果の出力を行う。
【００１８】
図１において、プログラムバージョンアップ支援システム１００は、名称変換処理部１２０とソース比較処理部１２１と種別判定処理部１２２から構成される。
【００１９】
名称変換処理部１２０では、分析対象ソースコード１３０のソースコードファイル名の変換を行う。旧バージョン標準ソースコード１３１を元にカスタマイズを行う際に、カスタマイズを実施したとわかるようにあらかじめ決められたネーミングルールに従ってファイル名を変更することがある。その場合にカスタマイズ前のファイル名に戻すことを名称変換処理部１２０で行う。なお、カスタマイズ実施時にファイル名の変更が行われなかった場合はファイル名の変換は行われない。ソース比較処理部１２１以降で使うカスタマイズプログラム１３１は、名称変換済みのソースコードファイルとする。
【００２０】
ソース比較処理部１２１では、分析対象ソースコード１３０と旧バージョン標準ソースコード１３１の比較および旧バージョン標準ソースコード１３１と新バージョン標準ソースコード１３２の比較を行い、それぞれの比較結果１３３を記憶装置１１１へ格納する。  種別判定処理部１２２では、記憶装置１１１に格納された比較結果１３３を元に種別判定を行い、種別判定結果１３４を記憶装置１１１に格納する。ここで、種別について説明する。種別判定はソースコードファイルごとに行う。種別は種別１から種別４の４つに分類され、種別ごとにソースコードファイルの修正方法が異なる。後で図７を用いて詳述するが、種別１はカスタマイズでもバージョンアップでも変更されていないソースコードファイルで、修正は不要。種別２はバージョンアップでのみ変更されているソースコードファイルで、新バージョン標準ソースコードのソースコードファイルを適用する。種別３はカスタマイズでのみ変更されているソースコードファイルで、分析対象ソースコードのソースコードファイルを適用する。種別４はバージョンアップおよびカスタマイズの両方で変更されているソースコードファイルで、分析対象ソースコードおよび新バージョン標準ソースコードのマージが必要となる。
【００２１】
次に、図２から図１０を用いて、プログラムバージョンアップ支援システム１００の処理を説明する。
【００２２】
図２は図１の名称変換処理部１２０の処理フローを表す。本処理では、ソース比較を行う際に同じファイル名であることが前提であるため、カスタマイズ時にファイル名の変更が行われていた場合には、カスタマイズ前のファイル名に戻すことを行う。図２のステップ２００で本システムの利用者があらかじめ定義したカスタマイズ時名称変更ルール２１０を読み込む。分析対象ソースコード２１１のソースコードのファイルを１本読み込む。。ステップ２０１では読み込んだソースコードファイルのファイル名とカスタマイズ時名称変更ルール２１０の定義内容を比較し、カスタマイズ時にファイル名を変更したファイルかどうかを判定する。判定した結果、カスタマイズ時のファイル名の変更が行われていた場合は、ステップ２０３でカスタマイズ前のファイル名に戻す処理を行い、カスタマイズ前のファイル名になったソースコードファイルを図１の記憶装置１１１に格納する。例えば、Java(登録商標)言語で作成されたソースコードファイルをカスタマイズする場合を説明する。カスタマイズ時のコーディングルールとして「元のクラス名」＋「_cstm」＋「.java」にすることが定められているとする。旧バージョンのソースコードファイル名が「SampleClass1.java」であった場合、カスタマイズ実施時には「SampleClass1_cstm.java」というファイル名に変更して保存される。カスタマイズ時名称変更ルール２１０には「元のクラス名」＋「_cstm」＋「.java」の内容があらかじめ定義され、名称変換処理部１２０によって、「SampleClass1_cstm.java」というファイル名は「SampleClass1.java」というファイル名に変更される。この分析対象ソースコードのファイル読み込み、カスタマイズ判定、ファイル名の変換をファイル１本ずつ、分析対象ソースコードの全てのファイルについて行う。
【００２３】
図３は図１のソース比較処理部１２１の処理フローを表す。ステップ３１０では分析対象ソースコード３００と旧バージョン標準ソースコード３０１との比較を行い比較結果３２０および比較結果３２１を出力する。比較では、ソースコード同士を一文字一文字突合せ、相違が無く全く同じであるか、差分が有るか判定するステップカウントを行う。比較対象のファイル自体が存在しない場合もある。ここで、比較結果３２０は分析対象ソースコード３００に存在するソースコードのファイル名を比較元として、旧バージョン標準ソースコード３０１にある同じファイル名のソースコードファイルとの比較を行った結果である。比較結果３２１は前述とは逆に旧バージョン標準ソースコード３０１に存在するソースコードのファイル名を比較元として、分析対象ソースコード３００にある同じファイル名のソースコードファイルとの比較を行った結果である。このように２回比較することにより、一方にしか存在しないソースコードファイルも漏れなく比較結果３２０、３２１に加えることができる。
【００２４】
ステップ３１１では旧バージョン標準ソースコード３０１と新バージョン標準ソースコード３０２の比較を行い比較結果３２２および比較結果３２３を出力する。こちらもステップ３１０と同様の比較を行う。比較結果３２２は新バージョン標準ソースコード３０２に存在するソースコードのファイル名を比較元として、旧バージョン標準ソースコード３０１にある同じファイル名のソースコードファイルとの比較を行った結果である。比較結果３２３は前述とは逆に旧バージョン標準ソースコード３０１に存在するソースコードのファイル名を比較元として、新バージョン標準ソースコード３０２にある同じファイル名のソースコードファイルとの比較を行った結果である。
【００２５】
図４は、図３の比較結果３２０の例である。ソースコードファイル名ごとに判定結果を示す。比較結果の「新規」とは、旧バージョン標準コードには存在せず、分析対象ソースコードにのみ存在するソースコードファイルである。比較結果の「変更無」とは、旧バージョン標準ソースコードと比べ分析対象ソースコードで変更のないソースコードファイルである。比較結果の「変更有」とは、旧バージョン標準ソースコードと比べ分析対象ソースコードで変更のあったソースコードファイルである。
【００２６】
また、図５は図３の比較結果３２１の例である。比較結果「変更無し」「変更有り」は、同一ファイルについては比較結果３２０と同じになる。比較結果の「削除」とは、旧バージョン標準ソースコードには存在していたが分析対象ソースコードには存在しないソースコードファイルである。例えば、図５の項番3の「A01_010_I010.java」は図４に存在しないことから、「削除」であると判断される。
【００２７】
これらの比較結果３２０、３２１をマージすることにより、各ファイルについて「変更無し」「変更有り」「新規」「削除」を判定することができる。また、比較結果３２２、３２３についても、同様に扱うことができ、各ファイルについて４種類に判定することができる。
【００２８】
図６では図１の種別判定処理部１２２の処理フローを表す。比較結果６１０は、図３の比較結果３２０、３２１、３２２、３２３を表す。ステップ６００で比較結果６１０を読み込む。比較結果６１０からソースコードファイルのファイル名を取得し、ステップ６０１、ステップ６０２を行う。ステップ６０１では比較結果を元にソースコードファイルごとの種別の判定を行い、ステップ６０２で種別の判定結果を種別判定結果ファイル６１１に出力する。種別の判定方法については図７で説明する。比較結果に記載された全てのソースコードファイルに対して、このステップ６０１、ステップ６０２を繰り返す。
【００２９】
図７はソース比較処理部で作成した比較結果を元にした種別判定のパターンとパターンごとのソースコードファイルの修正方法を示したものである。VerUP差分７０１は図３の比較結果３２２および比較結果３２３の比較結果から「新規」「変更無」「変更有」「削除」を取得した結果であり、カスタマイズ差分７０２も同様に比較結果３２０および比較結果３２１から比較結果を判定した結果である。No.3の「−」は、バージョンアップ時に追加された新バージョン標準ソースコードには存在するソースコードファイルであるが、旧バージョン標準ソースコード及び分析対象ソースコードには存在しないソースコードファイルである。No.7は逆に分析対象ソースコードで追加されたが、旧バージョン標準ソースコード及び新バージョン標準ソースコードには存在しないソースコードファイルである。No.11の両方で「新規」となっているのは、新バージョン標準ソースコードと分析対象ソースコードにそれぞれ追加したソースコードファイルがたまたま同じファイル名になる場合を表しており、中身が同じであるとは限らない。種別７１０は比較結果７００の組み合わせから判定した種別判定結果である。例えば、図７のNo.1はVerUP差分７０１とカスタマイズ差分７０２が両方とも「変更無」であることからどちらでも更新されていないファイルであることが判断でき、種別は「種別１」と判定される。No.4はVerUP差分７０１が「変更有」でカスタマイズ差分７０２が「変更無」であることから、バージョンアップ時にのみ更新されたソースコードファイルであり、新バージョン標準ソースコードを適用するため、種別は「種別２」と判定される。また、No.3はVerUP差分７０１が「新規」でカスタマイズ差分７０２が「−」であることから、新バージョンでのみ追加されたソースコードファイルであり、新バージョン標準ソースコードを適用するため、種別は「種別２」と判定される。No.8はVerUP差分７０１が「変更無」でカスタマイズ差分７０２が「変更有」であることから、カスタマイズ時にのみ更新されたソースコードファイルであり、分析対象ソースコードを適用するため、種別は「種別３」と判定される。また、No.9,10はVerUP差分７０１が「削除」でカスタマイズ差分７０２が「変更無」または「変更有」であることから、分析対象ソースコード内では呼び出されている可能性があり、分析対象ソースコードを適用するため、種別は「種別３」と判定される。No.12はVerUP差分７０１とカスタマイズ差分７０２が両方とも「変更有」であることからどちらでも更新されているファイルであることが判断でき、種別は「種別４」と判定される。
【００３０】
図８に種別判定処理ファイル６１１の例を示す。８００が種別コード、８０１がソースコードファイルのファイル名、８０２がソースコードファイルの修正方法である。８００の種別コードは図７の種別コード７２０に対応している。例えば、1行目は種別コードが「1-a」であるため図７のNo.1のパターンに該当し種別は「種別１」であり、バージョンアップ時にもカスタマイズ時にも更新されていないソースコードファイルであるため、修正は不要であると判断できる。また、2行目は種別コードが「3-b」であるため図７のNo.8のパターンに該当し種別は「種別３」であり、カスタマイズ時に更新されたソースコードであるため、分析対象ソースコードを適用すると判断できる。
【００３１】
また、種別判定結果ファイル６１１を元に、影響範囲の特定を行うことができる。修正対象とテスト対象のソースコードファイルの特定方法を示す。プログラム（ソースコードファイル）の呼び出し関連を示す呼出関連情報を用意し、これに種別判定結果ファイル６１１の種別判定結果を適用する。呼び出し関連情報は、バージョンアップ後の分析対象ソースコードのものが望ましいが、旧バージョン標準ソースコード、新バージョン標準ソースコード、バージョンアップ前の分析対象ソースコードのものを用いてもよい。呼出し関連の中に種別４（９１３）のソースコードファイルが存在した場合、バージョンアップの内容とカスタマイズの内容が混ざったソースコードファイルであるため、テストが必要と判断できる。種別４（９１３）のソースコードファイルと呼出し関係のあるすべてのソースコードファイル（９１０、９１１、９１２）をテスト対象とする。また、種別２（９０３）と呼出し関係のある種別３（９０２）のソースコードファイルが存在した場合、バージョンアッププログラムとカスタマイズプログラムの呼び出し関連となるため、テストが必要と判断できる。種別２（９０３）と呼出し関係のある種別３（９０２）とその親プログラムにあたるソースコードファイルと子プログラムにあたるソースコードファイルをテスト対象とする。種別１は変更なしのため、テストは不要と判断できる。呼出し関係の中に種別２と種別３が混ざっていない場合、すでにバージョンアッププログラム作成時およびカスタマイズプログラム作成時にテスト済みである処理であるため、テストは不要と判断できる。以上を、呼出関連情報と種別判定結果ファイル６１１を用いて本システムで判定することにより、図９に示すように影響範囲やテストを必要とする対象を特定する影響範囲情報１３５を算出することができる。
【符号の説明】
【００３２】
１００  プログラムバージョンアップ支援システム
１１０  ＣＰＵ
１１１  記憶装置
１２０  名称変換処理部
１２１  ソース比較処理部
１２２  種別判定処理部
１３０  分析対象ソースコード
１３１  旧バージョン標準ソースコード
１３２  新バージョン標準ソースコード
１３３  比較結果
１３４  種別判定結果
１３５  影響範囲情報
【図１】
2015076025.tif 000003
【図２】
2015076025.tif 000004
【図３】
2015076025.tif 000005
【図４】
2015076025.tif 000006
【図５】
2015076025.tif 000007
【図６】
2015076025.tif 000008
【図７】
2015076025.tif 000009
【図８】
2015076025.tif 000010
【図９】
2015076025.tif 000011