(57)【要約】【課題】ビルド作業後のモジュールの品質をチェックすることを可能とする。【解決手段】ＥＡＲモジュール格納ディレクトリ２２には、モジュール情報を含むチェック対象モジュールが格納される。データ抽出処理部３１は、ユーザによって指定されたＥＡＲモジュール格納ディレクトリ２２に格納されているチェック対象モジュールを取得する。データ処理部３２は、データ抽出処理部３１によって取得されたチェック対象モジュールに含まれるモジュール情報を抽出し、当該チェック対象モジュールの品質をチェックするための当該抽出されたモジュール情報からなるモデルを作成する。チェック処理部３３は、データ処理部３２によって作成されたモデルを用いて、データ抽出処理部３１によって取得されたチェック対象モジュールの品質をチェックする。結果出力部３４は、チェック処理部３３によるチェック結果を出力する。【選択図】図２
2011059882.tif 000002
【特許請求の範囲】
【請求項１】
チェック対象モジュールの品質をチェックするために用いられるモジュールチェックシステムにおいて、
前記チェック対象モジュールに関するモジュール情報を含む当該チェック対象モジュールを格納するモジュール格納手段と、
ユーザによって指定された前記モジュール格納手段に格納されているチェック対象モジュールを取得する取得手段と、
前記取得されたチェック対象モジュールに含まれるモジュール情報を抽出し、当該チェック対象モジュールの品質をチェックするための当該抽出されたモジュール情報からなるモデルを作成する作成手段と、
前記作成されたモデルを用いて、前記取得されたチェック対象モジュールの品質をチェックするチェック手段と、
前記チェック手段によるチェック結果を出力する出力手段と
を具備することを特徴とするモジュールチェックシステム。
【請求項２】
前記チェック対象モジュールに関するモジュール情報は、当該チェック対象モジュールの対象環境を識別するための環境識別情報を含み、
前記チェック手段は、前記取得されたチェック対象モジュールに含まれるモジュール情報に含まれる環境識別情報に応じたファイルが前記取得されたチェック対象モジュールに存在するかをチェックする
ことを特徴とする請求項１記載のモジュールチェックシステム。
【請求項３】
前記チェック対象モジュールは、ユーティリティモジュールまたはライブラリモジュールを含み、
前記チェック対象モジュールに関するモジュール情報は、当該チェック対象モジュールに含まれるユーティリティモジュールまたはライブラリモジュールのクラスパス設定情報を含み、
前記チェック手段は、前記取得されたチェック対象モジュールに含まれるモジュール情報に含まれるクラスパス設定情報を用いて、前記取得されたチェック対象モジュールに含まれるユーティリティモジュールまたはライブラリモジュールの参照関係をチェックする
ことを特徴とする請求項１記載のモジュールチェックシステム。
【請求項４】
予め指定された値を保持するチェック値リストを更に具備し、
前記チェック対象モジュールは、環境依存モジュールを含み、
前記チェック対象モジュールに関するモジュール情報は、当該チェック対象モジュールに含まれる環境依存モジュール上の設定情報を含み、
前記チェック手段は、前記チェック値リストに保持されている値に基づいて、前記取得されたチェック対象モジュールに含まれるモジュール情報に含まれる設定情報の内容をチェックする
ことを特徴とする請求項１記載のモジュールチェックシステム。
【請求項５】
チェック対象モジュールの品質をチェックするために用いられるモジュールチェックシステムであって、前記チェック対象モジュールに関するモジュール情報を含む当該チェック対象モジュールを格納するモジュール格納手段を有する外部記憶装置と、当該外部記憶装置を利用するコンピュータとから構成されるモジュールチェックシステムにおいて、前記コンピュータによって実行されるプログラムであって、
前記コンピュータに、
ユーザによって指定された前記モジュール格納手段に格納されているチェック対象モジュールを取得するステップと、
前記取得されたチェック対象モジュールに含まれるモジュール情報を抽出し、当該チェック対象モジュールの品質をチェックするための当該抽出されたモジュール情報からなるモデルを作成するステップと、
前記作成されたモデルを用いて、前記取得されたチェック対象モジュールの品質をチェックするステップと、
前記チェック結果を出力するステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モジュールの品質をチェックするモジュールチェックシステム及びプログラムに関する。
【背景技術】
【０００２】
近年のソフトウェア開発（Ｗｅｂアプリケーション）プロジェクトにおいては、プログラムソース単体チェックによる様々な品質向上の試みがされている。
【０００３】
例えば開発やテスト、運用等の工程毎にプログラムに要求される様々な異なるレベルの品質をチェックする技術（以下、先行技術と表記）が開示されている（例えば、特許文献１を参照）。この先行技術によれば、開発プロセスのフェーズ毎にプログラムに要求される様々な異なるレベルの品質をチェックすることができ、高品質が要求されるフェーズではリポジトリに高い品質のプログラムのみを登録可能とすることで、不具合が発生しないことを第三者に対して保証することができる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−２６９５２７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、大規模かつ複雑化する異なる環境向けにビルド作業を実施する場合、細分化の進むライブラリモジュールの参照関係のような、プログラムソース単体のチェックではチェックすることができない実行形式モジュールの構成管理が必要となる。
【０００６】
このような管理は人間による作業が一般的であるため、モジュールの動作確認時まで問題が発覚しない場合が多い。したがって、事前にモジュールそのものをチェックする仕組みが必要とされる。
【０００７】
そこで、本発明の目的は、ビルド作業後のモジュールの品質をチェックすることが可能なモジュールチェックシステム及びプログラムを提供することにある。
【課題を解決するための手段】
【０００８】
本発明の１つの態様によれば、チェック対象モジュールの品質をチェックするために用いられるモジュールチェックシステムが提供される。このモジュールチェックシステムは、前記チェック対象モジュールに関するモジュール情報を含む当該チェック対象モジュールを格納するモジュール格納手段と、ユーザによって指定された前記モジュール格納手段に格納されているチェック対象モジュールを取得する取得手段と、前記取得されたチェック対象モジュールに含まれるモジュール情報を抽出し、当該チェック対象モジュールの品質をチェックするための当該抽出されたモジュール情報からなるモデルを作成する作成手段と、前記作成されたモデルを用いて、前記取得されたチェック対象モジュールの品質をチェックするチェック手段と、前記チェック手段によるチェック結果を出力する出力手段とを具備する。
【発明の効果】
【０００９】
本発明は、ビルド作業後のモジュールの品質をチェックすることを可能とする。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態に係るモジュールチェックシステムのハードウェア構成を示すブロック図。
【図２】図１に示すモジュールチェックシステム３０の主として機能構成を示すブロック図。
【図３】図２に示すＥＡＲモジュール格納ディレクトリ２２に格納されているチェック対象モジュールの構成の一例を示す図。
【図４】図２に示す種別判定リスト格納部２３に格納されている実行環境種別判定リストのデータ構造の一例を示す図。
【図５】本実施形態に係るモジュールチェックシステムの処理手順を示すフローチャート。
【図６】モジュールチェック処理の処理手順を示すフローチャート。
【図７】ＥＡＲモデル一次格納部２４に格納された作成されたＥａｒモデルの一例を示す図。
【図８】ＥＡＲファイルに含まれるファイルＮｏ．９の「MANIFEST.MF」の内容の一例を示す図。
【図９】チェック値リスト格納部２５に格納されているチェック値リスト「jsessionid_YY.properties」の内容の一例を示す図。
【図１０】一連のチェック処理が実行された場合のチェック結果出力画面の一例を示す図。
【発明を実施するための形態】
【００１１】
以下、図面を参照して、本発明の実施形態について説明する。
【００１２】
図１は、本実施形態に係るモジュールチェックシステムのハードウェア構成を示すブロック図である。
【００１３】
図１に示すように、コンピュータ１０は、例えばハードディスクドライブ（ＨＤＤ：Hard Disk Drive）のような外部記憶装置２０と接続されている。この外部記憶装置２０は、コンピュータ１０によって実行されるプログラム２１を格納する。コンピュータ１０及び外部記憶装置２０は、モジュールチェックシステム３０を構成する。
【００１４】
モジュールチェックシステム３０は、ビルド作業後の例えばＥＡＲ（Enterprise Archive）モジュール（Ｊ２ＥＥアプリケーション）の品質をチェックする機能を有する。
【００１５】
図２は、図１に示すモジュールチェックシステム３０の主として機能構成を示すブロック図である。図２に示すように、モジュールチェックシステム３０は、データ抽出処理部３１、データ処理部３２、チェック処理部３３及び結果出力部３４を含む。本実施形態において、これらの各部３１〜３４は、図１に示すコンピュータ１０が外部記憶装置２０に格納されているプログラム（モジュールチェックプログラム）２１を実行することにより実現されるものとする。このプログラム２１は、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラム２１が例えばネットワークを介してコンピュータ１０にダウンロードされても構わない。
【００１６】
また、モジュールチェックシステム３０は、ＥＡＲモジュール格納ディレクトリ２２、種別判定リスト格納部２３、ＥＡＲモデル一時格納部２４及びチェック値リスト格納部２５を含む。本実施形態において、これらのＥＡＲモジュール格納ディレクトリ２２、種別判定リスト格納部２３、ＥＡＲモデル一次格納部２４及びチェック値リスト格納部２５は、例えば外部記憶装置２０に格納される。
【００１７】
ＥＡＲモジュール格納ディレクトリ２２には、モジュールチェックシステム３０によるチェックの対象となるＥＡＲモジュール（以下、チェック対象モジュールと表記）が格納される。チェック対象モジュールには、当該チェック対象モジュールに関する情報（以下、モジュール情報と表記）が含まれる。このモジュール情報には、例えばチェック対象モジュールの名称及び当該チェック対象モジュールの対象環境を識別するための環境識別子（環境識別情報）等が含まれる。
【００１８】
データ抽出処理部３１は、ユーザによって指定されたコマンドを入力する。このコマンドには、例えばチェック対象モジュール（ＥＡＲファイル）の格納先（もしくはディレクトリ）及び当該チェック対象モジュールのチェック結果の出力レベルが含まれる。
【００１９】
データ抽出処理部３１は、入力されたコマンドに含まれるチェック対象モジュールの格納先に基づいて、チェック対象モジュール（もしくはディレクトリ情報）をＥＡＲモジュール格納ディレクトリ２２から取得する。
【００２０】
データ処理部３２は、データ抽出処理部３１によって取得されたチェック対象モジュールに含まれるモジュール情報に基づいて、当該チェック対象モジュールの名称を判定する。また、データ処理部３２は、モジュール情報に含まれる環境識別子に基づいて当該チェック対象モジュールの環境種別を判定する。チェック対象モジュールの環境種別の判定には、種別判定リスト格納部２３に格納されているリスト（以下、実行環境種別判定リストと表記）が用いられる。この実行環境種別判定リストには、環境識別子に対応付けて環境種別が保持される。なお、環境種別には、例えば「準本番環境」及び「開発、テスト環境」等が含まれる。
【００２１】
データ処理部３２は、データ抽出処理部３１によって取得されたチェック対象モジュールのチェック処理に必要なモジュール情報（当該チェック対象モジュールの内容）を、当該チェック対象モジュールから抽出する。データ処理部３２は、抽出されたモジュール情報からなるＥＡＲモデルを作成する。このＥＡＲモデルは、チェック対象モジュールの品質をチェックするために利用される。データ処理部３２によって作成されたＥＡＲモデルは、ＥＡＲモデル一次格納部２４に格納される。
【００２２】
チェック処理部３３は、ＥＡＲモデル一次格納部２４に格納されたＥＡＲモデルを用いてチェック対象モジュールの品質のチェック処理を実行する。この場合、チェック処理部３３は、例えば共通チェック処理、Ｗｅｂ・Ｂａｔｃｈアプリケーションの共通処理及びＷｅｂアプリチェック処理等を実行する。このチェック処理部３３によるチェック処理によって、チェック対象モジュールの例えば構成、参照関係及び環境依存設定等がチェックされる。
【００２３】
チェック値リスト格納部２５には、チェック処理部３３において用いられるチェック値リストが格納される。このチェック値リストには、チェック処理において用いられる予め指定された値が保持される。
【００２４】
結果出力部３４は、チェック処理部３３によるチェック処理の実行結果（チェック結果）を出力する。
【００２５】
図３は、図２に示すＥＡＲモジュール格納ディレクトリ２２に格納されているチェック対象モジュール（Ｊ２ＥＥアプリケーション）の構成の一例を示す。
【００２６】
図３に示すチェック対象モジュールは、例えばファイルＮｏ．１〜２２によって構成されている。
【００２７】
図３に示す例では、ファイルＮｏ．１の「Xxxx_YY-ZzzContainer.ear」は、Ｊ２ＥＥアプリケーションファイル（ＥＡＲファイル）を示す。
【００２８】
ファイルＮｏ．２の「lib」は、ライブラリ格納ディレクトリを示す。ファイルＮｏ．３の「Xxx.jar」は、ライブラリモジュールを示す。
【００２９】
フィアルＮｏ．４の「META-INF」は、ＭＥＴＡ−ＩＮＦディレクトリを示す。ファイルＮｏ．５の「application.xml」は、Ｊ２ＥＥアプリケーション設定フィアルを示す。ファイルＮｏ．６の「MANIFEST.MF」は、マニフェストファイル（クラスパス設定情報）を示す。
【００３０】
ファイルＮｏ．７の「XxxxZzz.war」は、ＷＥＢアプリケーションファイルを示す。ファイルＮｏ．９の「MANIFEST.MF」は、マニフェストファイル（クラスパス設定情報）を示す。
【００３１】
ファイルＮｏ．１０の「yyy」は、Ｗｅｂアプリケーションに必要な各種ファイル（例えばcss/html/bmp/ggif/js/jspなど）を示す。また、ファイルＮｏ．１３の「web.xml」は、Ｗｅｂアプリケーション設定ファイルを示す。
【００３２】
ファイルＮｏ．１４の「Xxxxabcdef.jar」は、ユーティリティＪａｒファイルを示す。ファイルＮｏ．１６の「www.class」はクラスファイルなどを示す。また、ファイルＮｏ．１８の「MANIFEST.MF」は、マニフェストファイル（クラスパス設定情報）を示す。
【００３３】
ファイルＮｏ．１９の「Xxxx_YY-Yyyy.jar」は、ユーティリティＪａｒファイル（環境依存モジュール）を示す。ファイルＮｏ．２０の「vvv.properties」は、環境設定ファイル（環境依存モジュール上の設定情報）を示す。ファイルＮｏ．２２の「MANIFEST.MF」は、マニフェストファイル（クラスパス設定情報）を示す。
【００３４】
なお、上記した図３に示すチェック対象モジュールの構成において、下線部分は、Ｊ２ＥＥの仕様であり、例えばＷＡＲファイル及びＪＡＲファイルを含むＥＡＲファイルを形成する上で必要となるファイル（及び命名規則）である。
【００３５】
一方、下線部以外については基本的には任意に命名して利用することが可能であるが、複数環境が絡む大規模プロジェクトでは、Ｗｅｂアプリケーション（ｗａｒ）、共通ロジック（ｊａｒ）、環境依存設定（ｊａｒ）等を分けて利用する形が一般的である。
【００３６】
また、本実施形態においてチェック対象モジュールのチェック処理を実施するにあたり、Ｅａｒのタイプ判定及び当該チェック対象モジュールの対象環境を特定するために、ＥＡＲファイル名そのものについて命名ルールが設けられている。
【００３７】
この命名ルールを図３に示すファイルＮｏ．１の「Xxxx_YY-ZzzContainer.ear」を用いて説明する。この命名ルールによれば、ファイルＮｏ．１の「Xxxx_YY-ZzzContainer.ear」の「Xxxx」はアプリケーション種別を表す。また、この命名ルールによれば、ファイルＮｏ．１の「Xxxx_YY-ZzzContainer.ear」の「YY」は、環境識別子（環境識別情報）を表す。なお、環境識別子がない場合は運用向けであることを表す。また、この命名ルールによれば、ファイルＮｏ．１の「Xxxx_YY-ZzzContainer.ear」の「Zzz」は、Ｗｅｂアプリ、バッチ等の種別を表す。
【００３８】
このような命名ルールに基づいて作成されたＥＡＲファイルは、種別判定リスト格納部２３に格納されている実行環境種別判定リストを用いて判定、分類され、モデル化される。チェック処理部３３においては、このモデル化された情報を基に、種別毎（例えば、アプリケーション種別等）にチェック内容を切り替えてチェック処理が実行される。
【００３９】
図４は、図２に示す種別判定リスト格納部２３に格納されている実行環境種別判定リストのデータ構造の一例を示す。
【００４０】
図４に示す実行環境種別判定リストには、環境識別子に対応付けて環境種別（を示す情報）が保持される。
【００４１】
図４に示す例では、「ＡＡ」、「ＢＢ」、「ＣＣ」、「ＤＤ」、「ＥＥ」、「ＦＦ」、「ＳＳ」、「ＸＸ」及び「ＹＹ」は、環境識別子である。一方、「Ｓ」及び「Ｔ」は、環境種別を示す。なお、「Ｓ」は例えば「準本番環境」を示し、「Ｔ」は「開発、テスト環境」を示すものとする。
【００４２】
このような実行環境種別判定リストを用いることにより、チェック対象モジュールに含まれるモジュール情報に含まれる環境識別子から環境種別が判定される。
【００４３】
次に、図５のフローチャートを参照して、本実施形態に係るモジュールチェックシステム３０の処理手順について説明する。
【００４４】
なお、以下の説明においては、ＥＡＲモジュール格納ディレクトリ２２には、上記した図３に示すチェック対象モジュールが格納されているものとする。また、種別判定リスト格納部２３には、上記した図４に示す実行環境種別判定リストが格納されているものとする。
【００４５】
まず、データ抽出処理部３１は、ユーザによって指定されたコマンドを入力する。これにより、データ抽出処理部３１は、コマンドに含まれるＥＡＲモジュール（チェック対象モジュール）の格納先及び出力レベルを入力する（ステップＳ１）。このコマンド（ＥＡＲモジュールの格納先及び出力レベル）は、例えばチェックアプリケーション画面を起動することにより入力することができる。
【００４６】
ここで、データ抽出処理部３１によって入力されるコマンドについて具体的に説明する。データ抽出処理部３１は、例えばコマンド「java ‐jar earchecker.jar ‐verbose C:\EarChecker\modules\Xxxx_YY-ZzzContainer.ear」を入力する。このコマンドにおいては、「-verbose」がチェック結果の出力レベルを示し、「C:\EarChecker\modules\Xxxx_YY-ZzzContainer.ear」がチェック対象モジュール（Ｅａｒファイル）の格納先を示す。
【００４７】
データ抽出処理部３１は、入力されたチェック対象モジュールの格納先に基づいて、チェック対象モジュールをＥＡＲモジュール格納ディレクトリ２２から取得する（ステップＳ２）。
【００４８】
次に、データ抽出処理部３１は、チェック対象モジュールが存在するか（つまり、チェック対象モジュールが取得されたか）否かを判定する（ステップＳ３）。
【００４９】
チェック対象モジュールが存在すると判定された場合（ステップＳ３のＹＥＳ）、当該チェック対象モジュールの品質をチェックするモジュールチェック処理が実行される（ステップＳ２１）。モジュールチェック処理においては、種別判定リスト格納部２３に格納されている実行環境種別判定リスト及びチェック値リスト格納部２５に格納されているチェック値リスト等が用いられる。このモジュールチェック処理の詳細については後述する。
【００５０】
モジュールチェック処理が実行されると、当該チェック処理結果に問題があるか否かが判定される（ステップＳ５）。
【００５１】
チェック処理結果に問題があると判定された場合（ステップＳ５のＹＥＳ）、エラー情報が出力される（ステップＳ６）。一方、チェック処理結果に問題がないと判定された場合（ステップＳ５のＮＯ）、ステップＳ６の処理は実行されない。
【００５２】
次に、全てのチェック対象モジュール（対象ＥＡＲファイル）についてモジュールチェック処理が終了したか否かが判定される（ステップＳ７）。全てのチェック対象モジュールについてモジュールチェック処理が終了していないと判定された場合（ステップＳ７のＮＯ）、ステップＳ４に戻って処理が繰り返される。つまり、チェック対象モジュール（対象ＥＡＲファイル）が複数ある場合には、当該ファイルの個数分、モジュールチェック処理が繰り返される。
【００５３】
一方、全てのチェック対象モジュールについてモジュールチェック処理が終了したと判定された場合（ステップＳ７のＹＥＳ）、結果出力部３４は、チェック結果を出力する（ステップＳ８）。結果出力部３４によって出力されるチェック結果には、上記したステップＳ６において出力されたエラー情報が含まれる。
【００５４】
なお、上記したステップＳ３においてチェック対象モジュールが存在しないと判定された場合、ステップＳ８の処理が実行される。この場合、チェック結果としてチェック対象モジュールが存在しない（つまり、チェックの対象が存在しない）旨の情報が出力される。
【００５５】
次に、図６のフローチャートを参照して、上記したモジュールチェック処理（図５に示すステップＳ４の処理）の処理手順の詳細について説明する。
【００５６】
モジュールチェック処理においては、後述するように例えば共通チェック処理、Ｗｅｂ・Ｂａｔｃｈアプリケーションの共通処理及びＷｅｂアプリチェック処理等のチェック処理が実行される。
【００５７】
なお、モジュールチェック処理においては、上記した共通チェック処理、Ｗｅｂ・Ｂａｔｃｈアプリケーションの共通処理及びＷｅｂアプリチェック処理等のチェック処理の前に、以下に説明するステップＳ１１〜ステップＳ１３において準備処理が実行される。
【００５８】
まず、データ処理部３２は、データ抽出処理部３１によって取得されたチェック対象モジュールに含まれるモジュール情報に基づいて、当該チェック対象モジュールの名称（モジュール名称）を判定する（ステップＳ１１）。前述した図３に示す例では、当該モジュール名称（ＥＡＲファイル名）は「Xxxx_YY-ZzzContainer.ear」である。
【００５９】
次に、データ処理部３２は、データ抽出処理部３１によって取得されたチェック対象モジュールに含まれるモジュール情報に基づいて、環境種別の判定を行う（ステップＳ１２）。データ処理部３２は、種別判定リスト格納部２３に格納されている実行環境種別判定リスト及び上記したＥＡＲファイル名の命名ルール（ＥＡＲ命名ルール）を活用して判定処理を実行する。
【００６０】
図３に示す例では、上記したＥＡＲファイル名の命名ルールによりチェック対象モジュールのファイルＮｏ．１「Xxxx_YY-ZzzContainer.ear」の「YY」が環境識別子である。したがって、前述した図４に示す実行環境種別判定リストによれば、環境種別が「Ｔ」、つまり、「開発、テスト環境」であることが判定される。
【００６１】
次に、データ処理部３２は、データ抽出処理部３１によって取得されたチェック対象モジュール（に含まれるモジュール情報）からチェック処理に必要な情報を個別に抽出し、モデル化することによりＥａｒモデルを作成する（ステップＳ１３）。このＥａｒモデルは、Ｅａｒモデル情報として以降のチェック処理に利用される。Ｅａｒモデルは、データ処理部３２によって抽出された情報（モジュール情報）等からなる。
【００６２】
具体的には、データ処理部３２は、図３に示すファイルＮｏ．１「Xxxx_YY-ZzzContainer.ear」より以下の情報、つまり、Ｅａｒファイルに含まれる全ファイル（ファイルＮｏ．２〜２２）をプログラム内で展開し、必要な情報を抽出することにより、Ｅａｒモデルを作成する。なお、データ処理部３２によって作成されたＥａｒモデルは、ＥＡＲモデル一次格納部２４に格納される。
【００６３】
ここで、図７は、ＥＡＲモデル一次格納部２４に格納されたＥａｒモデルの一例を示す。なお、図７は、図３に示すチェック対象モジュールに含まれるモジュール情報から必要な情報が抽出されることによって作成されたＥａｒモデルの一例を示す。
【００６４】
図７に示すＥａｒモデルにおける「Ｅａｒ種別＝[Zzz]」、「環境識別子＝[YY]」及び「アプリ短縮名＝[Xxxx]」は、Ｅａｒファイル名称によるセットである。
【００６５】
また、図７に示すＥａｒモデルにおいて、例えば「運用向け＝[false]」は、データ処理部３２によってＥＡＲファイル名より取得された環境識別子について実行環境種別判定リストをもとに環境種別が判定された結果を示し、Ｅａｒモデルへと格納されている。
【００６６】
なお、Ｅａｒモデルには、仕様バージョン、ユーティリティモジュールまたはライブラリモジュールのクラスパス設定情報及び環境依存モジュール（ユーティリティＪａｒ、Ｗａｒファイル）上の設定情報等が含まれる。
【００６７】
図７に示すようなＥａｒモデルを利用することによって、チェック対象モジュールに対するチェック処理が実行される。
【００６８】
再び図６に戻ると、チェック処理部３３は、以下のステップＳ１４〜ステップＳ１６の処理により、チェック対象モジュールに対する各種チェック処理を実行する。このチェック処理においては、ＥＡＲモデル一次格納部２４に格納されたＥＡＲモデルが用いられる。
【００６９】
まず、チェック処理部３３は、共通チェック処理を実行する（ステップＳ１４）。この共通チェック処理には、例えば第１〜第６のチェック処理が含まれる。
【００７０】
第１のチェック処理は、例えば環境識別子に応じたＪａｒファイルが存在するかをチェックする処理である。第２のチェック処理は、例えばユーティリティＪａｒのクラスパスをチェックする処理である。第３のチェック処理は、例えば開発環境、運用環境で異なるＪａｒの存在をチェックする処理である。第４のチェック処理は、例えば「Yyyy.jar」の存在をチェックする処理である。第５のチェック処理は、例えばＬｏｇｇｅｒ定義をチェックする処理である。第６のチェック処理は、例えばＥａｒ種別毎のチェックを実施する処理である。
【００７１】
以下、共通チェック処理における第１及び第４のチェック処理について具体的に説明する。
【００７２】
第１のチェック処理は、上記したように環境識別子に応じたＪａｒファイルが存在するかをチェックする処理である。この第１のチェック処理においては、例えば図３に示すチェック対象モジュール（ＥＡＲファイル）に含まれるファイルＮｏ．１９に正しい名称が付与されているか否かが判定される。
【００７３】
具体的には、第１のチェック処理においては、Ｅａｒモデルの「アプリ短縮名＝[Xxxx]」及び「環境識別子＝[YY]」から想定されるユーティリティＪａｒ「Xxxx_YY-Yyyy.jar」がチェック値とされる。また、第１のチェック処理では、Ｅａｒモデルの「ConfigJar＝[Xxxx_YY-Yyyy.jar]」がチェック対象とされる。
【００７４】
第４のチェック処理は、ConfigJarの存在をチェックする処理である。この第４のチェック処理においては、例えば図３に示すチェック対象モジュール（ＥＡＲファイル）に含まれるファイルＮｏ．１９がファイルＮｏ．７（Ｗｅｂアプリケーション）から正しく参照されているかがチェックされる。
【００７５】
具体的には、第４のチェック処理においては、Ｅａｒモデルの「ConfigJar＝[Xxxx_YY-Yyyy.jar]」がチェック値とされる。また、第４のチェック処理においては、図３に示すチェック対象モジュール（ＥＡＲファイル）に含まれるファイルＮｏ．７の「XxxxZzz.war」に含まれるファイルＮｏ．９の「MANIFEST.MF（クラスパス設定情報）」（の内容）がチェック対象とされる。
【００７６】
ここで、図８は、ＥＡＲファイルに含まれるファイルＮｏ．９の「MANIFEST.MF」の内容の一例を示す。
【００７７】
図８に示す例では、ファイルＮｏ．９の「MANIFEST.MF」には、チェック値である「[Xxxx_YY-Yyyy.jar]」が存在しているため、第４のチェック処理では問題はない（つまり、チェッククリア）と判定される。
【００７８】
次に、チェック処理３３は、Ｗｅｂ・Ｂａｔｃｈアプリケーションの共通処理を実行する（ステップＳ１５）。このＷｅｂ・Ｂａｔｃｈアプリケーションの共通処理には、第７及び第８のチェック処理が含まれる。
【００７９】
第７のチェック処理は、例えばリソース参照のＩＢＭ拡張定義との整合性をチェックする処理である。この第７のチェック処理は、Ｅａｒモデルの「web.xml」のリソース参照分ループされる。
【００８０】
第８のチェック処理は、第７のチェック処理と同様に、リソース参照のＩＢＭ拡張定義との整合性をチェックする処理である。この第８のチェック処理は、Ｅａｒモデルの「ibm-web-bnd.xmi」のリソース参照分ループされる。
【００８１】
次に、チェック処理部３３は、Ｗｅｂアプリチェック処理を実行する（ステップＳ１６）。このＷｅｂアプリチェック処理には、第９のチェック処理が含まれる。
【００８２】
第９のチェック処理は、例えばＪＳＥＳＳＩＯＮＩＤキー定義をチェックする処理である。以下、Ｗｅｂアプリチェック処理における第９のチェック処理について具体的に説明する。
【００８３】
第９のチェック処理においては、チェック値リスト格納部２５に格納されているチェック値リストの値と、実際の環境依存設定ファイルの内容がチェックされる。
【００８４】
チェック値リスト格納部２５には、チェック値リストとして例えば「jsessionid_YY.properties」等が格納されている。なお、図９は、チェック値リスト格納部２５に格納されているチェック値リスト「jsessionid_YY.properties」の内容の一例を示す。
【００８５】
具体的には、第９のチェック処理においては、チェック値リスト格納部２５に格納されている「jsessionid_YY.properties」により指定された値がチェック値とされる。なお、ファイル名の「YY」は、上記したＥａｒモデルの「環境識別子＝[YY]」より取得される。また、第９のチェック処理においては、チェック対象モジュール（ＥＡＲファイル）に含まれるファイルＮｏ．２０の「vvv.properties」に記載されるＪＳＥＳＳＩＯＮＩＤの値がチェック対象とされる。
【００８６】
上記したように、チェック処理部３３は、上記一連のチェック処理を実行する。これにより、チェック結果として、ＯＫ／ＮＧの判定結果及びＮＧの場合にはエラー項目（エラー情報）が結果出力部３４によって出力（表示）される。
【００８７】
ここで、図１０は、上記したような一連のチェック処理が実行された場合のチェック結果が表示された画面（チェック結果出力画面）の一例を示す。
【００８８】
図１０に示すチェック結果出力画面の「結果＝[NG]」が上記チェック処理における判定結果（チェック結果）を示す。また、図１０に示すように、チェック結果出力画面には、ＮＧと判定されたエラー項目が表示されている。
【００８９】
上記したように本実施形態においては、チェック対象モジュール（ＥＡＲモジュール）に含まれるモジュール情報（モジュール名称および環境識別子等）に基づいてＥＡＲモデルが作成される。本実施形態においては、ＥＡＲモデルを用いて共通チェック処理、Ｗｅｂ・Ｂａｔｃｈアプリケーションの共通処理及びＷｅｂアプリチェック処理が実行される。
【００９０】
これにより、本実施形態においては、チェック対象モジュールの構成、参照関係及び環境依存設定等のチェックをすることができる。したがって、本実施形態においては、ビルド作業後のチェック対象モジュールの一括品質チェックが可能となり、効率的な品質監査を行うことができる。
【００９１】
また、本実施形態においては、チェック処理結果がプログラム開発者及びビルド担当者に即座にフィードバックされることにより、当該プログラム開発者及びビルド担当者は修正作業等の対応策を検討及び実施できる。これにより、チェック対象モジュールの品質の向上及び均一化を図ることが可能となる。
【００９２】
なお、例えば構成管理ツール（ＣＶＳ・ＳＶＮ）との連携、アプリケーションサーバへのモジュールアップロード及びアプリケーションサーバへのデプロイ処理等を組み合わせることにより、ビルド処理の自動化を図ることも可能である。
【００９３】
また、本願発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。  
【符号の説明】
【００９４】
１０…コンピュータ、２０…外部記憶装置、２２…ＥＡＲモジュール格納ディレクトリ、２３…種別判定リスト格納部、２４…ＥＡＲモデル一次格納部、２５…チェック値リスト格納部、３０…モジュールチェックシステム、３１…データ抽出処理部（取得手段）、３２…データ処理部（作成手段）、３３…チェック処理部、３４…結果出力部。
【図１】
2011059882.tif 000003
【図２】
2011059882.tif 000004
【図３】
2011059882.tif 000005
【図４】
2011059882.tif 000006
【図５】
2011059882.tif 000007
【図６】
2011059882.tif 000008
【図７】
2011059882.tif 000009
【図８】
2011059882.tif 000010
【図９】
2011059882.tif 000011
【図１０】
2011059882.tif 000012