(57)【要約】【課題】ソースプログラムがフレームワーク仕様に則って作成されているか否かをチェックする。【解決手段】チェックエンジン１２０が、チェックルール記憶部１２５が記憶するチェックルールに基づいてソースプログラムがフレームワーク仕様に則って作成されているか否かをチェックする。また、ツールアダプタ１１０が外部ツールを起動して外部ツールによるチェックを行い、レポート出力部１３０が外部ツールによるチェック結果とチェックエンジン１２０によるチェック結果をまとめてレポート出力する。【選択図】        図２
2009099111.tif 000002
【特許請求の範囲】
【請求項１】
業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査手順と、
前記フレームワーク検査手順により検査された結果を出力する検査結果出力手順と、
をコンピュータに実行させ、
前記フレームワーク検査手順は、フレームワーク仕様に則って作成されているか否かの検査として、共通部品同士の使用方法の整合性、業務ロジックと共通部品の使用方法との整合性を含む検査を行うことを特徴とする規則検査プログラム。
【請求項２】
前記フレームワーク検査手順は、検査対象のソースプログラムの特性に基づいてチェックルールを選択してソースプログラムを検査することを特徴とする請求項１に記載の規則検査プログラム。
【請求項３】
前記チェックルールは、ルール選択に使用される自動選択機能部と検査を実行するチェク処理実装部から構成され、
前記フレームワーク検査手順は、
前記自動選択機能部を使用してチェックルールを選択するルール選択手順と、
前記ルール選択手順により選択されたチェックルールのチェク処理実装部に基づいて検査を実行する検査実行手順と
をコンピュータに実行させることを特徴とする請求項２に記載の規則検査プログラム。
【請求項４】
前記フレームワーク検査手順は、チェックルールの適用結果に関するデータを収集し、適用したチェックルールごとに記憶装置に書き込み、
前記フレームワーク検査手順によりチェックルールごとに書き込まれたデータを記憶装置から読み出して各チェックルールを評価するルール評価手順
をさらにコンピュータに実行させることを特徴とする請求項１に記載の規則検査プログラム。
【請求項５】
前記フレームワーク検査手順は、各チェックルールの適用回数を記憶装置に書き込み
前記ルール評価手順は、各チェックルールの適用回数が所定の閾値範囲から外れているか否かに基づいて各チェックルールを評価することを特徴とする請求項４に記載の規則検査プログラム。
【請求項６】
業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査ステップと、
前記フレームワーク検査ステップにより検査された結果を出力する検査結果出力ステップと、
を含み、
前記フレームワーク検査ステップは、フレームワーク仕様に則って作成されているか否かの検査として、共通部品同士の使用方法の整合性、業務ロジックと共通部品の使用方法との整合性を含む検査を行うことを特徴とする規則検査方法。
【請求項７】
業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査手段と、
前記フレームワーク検査手段により検査された結果を出力する検査結果出力手段と、
を備え、
前記フレームワーク検査手段は、フレームワーク仕様に則って作成されているか否かの検査として、共通部品同士の使用方法の整合性、業務ロジックと共通部品の使用方法との整合性を含む検査を行うことを特徴とする規則検査装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、フレームワークを利用して作成されるフレームワーク利用文書の品質を診断する規則検査プログラム、規則検査方法および規則検査装置に関する。
【背景技術】
【０００２】
ソフトウェアの開発では、Ｊａｖａ(登録商標、以下同様)やＣ＋＋などのプログラム言語を用いて作成したソースプログラムをコンパイラによってチェックした後、ロードモジュールを作成し、作成したロードモジュールを実行することによってテストが行われる。
【０００３】
これまで、かかるソフトウェア開発を支援する様々な技術やツールが開発されている。例えば、特許文献１には、プログラムを構成する各命令のデータ型に関する制約が正しく守られているか否かの検査を効率良く行うプログラム検査システムが記載されている。
【０００４】
【特許文献１】特許第３３６０６３５号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００５】
近年、ソフトウェアの開発においては、プログラム言語を用いてソースプログラムを一から開発する代わりに、フレームワークを利用した開発が行われるようになってきた。ここで、フレームワークとは、ソフトウェアを開発する場合の枠組みであり、コーディング規則、部品の利用規約、テンプレートなどを含むものである。例えば、ＪａｖａやＶＢ．ＮＥＴそれぞれにデータベースアクセス用のフレームワーク、画面動作記述用のフレームワーク、帳票処理用のフレームワークなどがある。
【０００６】
フレームワーク仕様に則ってソースプログラムを開発するか否かは、ソフトウェアの開発効率に影響するだけでなく、ソースプログラムの標準化にも大きく影響する。また、フレームワーク仕様に則ってソースプログラムを開発しないと、実行性能が大きく低下する場合もあり、フレームワーク仕様に則ってソースプログラムを開発することが非常に重要となっている。
【０００７】
プログラム言語を用いて作成されたソースプログラムが言語仕様に則って作成されているか否かの検査はコンパイラによって行うことができる。しかしながら、フレームワークを利用して作成されたソースプログラムがフレームワーク仕様に則って作成されているか否かの検査は、コンパイラによっては行うことができない。
【０００８】
したがって、ソースプログラムがフレームワーク仕様に則って作成されているか否かの検査は、人手で行う必要があるが、様々なフレームワーク仕様を人手で正確に検査することは困難であるという問題がある。
【０００９】
この発明は、上述した従来技術による問題点を解消するためになされたものであり、フレームワークを利用して作成されたソースプログラムなどのフレームワーク利用文書を検査して品質を診断し、フレームワーク利用文書の品質を向上させることができる規則検査プログラム、規則検査方法および規則検査装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上述した課題を解決し、目的を達成するため、本発明は、業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査手順と、前記フレームワーク検査手順により検査された結果を出力する検査結果出力手順と、をコンピュータに実行させ、前記フレームワーク検査手順は、フレームワーク仕様に則って作成されているか否かの検査として、共通部品同士の使用方法の整合性、業務ロジックと共通部品の使用方法との整合性を含む検査を行うことを特徴とする。
【００１１】
また、本発明は、業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査ステップと、前記フレームワーク検査ステップにより検査された結果を出力する検査結果出力ステップと、を含み、前記フレームワーク検査ステップは、フレームワーク仕様に則って作成されているか否かの検査として、共通部品同士の使用方法の整合性、業務ロジックと共通部品の使用方法との整合性を含む検査を行うことを特徴とする。
【００１２】
また、本発明は、業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査手段と、前記フレームワーク検査手段により検査された結果を出力する検査結果出力手段と、を備え、前記フレームワーク検査手段は、フレームワーク仕様に則って作成されているか否かの検査として、共通部品同士の使用方法の整合性、業務ロジックと共通部品の使用方法との整合性を含む検査を行うことを特徴とする。
【００１３】
かかる発明によれば、ソースプログラムがフレームワーク仕様に則って作成されているか否かを検査し、検査検果を出力するよう構成したので、ソースプログラムの品質を診断することができる。
【発明の効果】
【００１４】
本発明によれば、ソースプログラムの品質を診断するので、ソフトウェア開発者のスキルを評価することができるとともに、品質を向上することができるという効果を奏する。
【発明を実施するための最良の形態】
【００１５】
以下に添付図面を参照して、この発明に係る規則検査プログラム、規則検査方法および規則検査装置の好適な実施例を詳細に説明する。
【実施例１】
【００１６】
まず、本実施例１に係る品質診断の概念について説明する。図１は、本実施例１に係る品質診断の概念を説明するための説明図である。同図（ａ）に示すように、本実施例１に係る品質診断では、業務アプリケーションなどフレームワークを利用して作成されたソースプログラムが、言語仕様に則って作成されているか否かを検査するだけでなく、フレームワーク仕様に則って作成されているか否かを検査し、ソースプログラムの品質を診断する。すなわち、フレームワークを使用する際に守るべき規則にしたがってソースプログラムが作成されているか否かを検査する。
【００１７】
このように、ソースプログラムがフレームワーク仕様に則って作成されているか否かを検査して、ソースプログラムの品質を診断することによって、アプリケーション開発の標準化を推進するとともに、開発者の技術スキルを評価することができる。また、アプリケーションの開発を委託する場合には、本実施例１に係る品質診断を、納品されたソースプログラムの受入検査に利用することができ、委託先のスキル評価にも利用することができる。
【００１８】
また、本実施例１に係る品質診断では、図１（ｂ）に示すように、フレームワーク仕様に基づく品質診断を行う基本品質診断装置に、Ｊａｖａ、ＰＬ／ＳＱＬなど言語に依存する部分をプラグインして品質診断装置を構成する。したがって、本実施例１に係る品質診断装置は、どのような言語で作成されたソースプログラムに対しても柔軟に対応することができる。
【００１９】
また、本実施例１に係る品質診断では、ソースプログラムの品質診断をチェックルールを用いて行う。したがって、固有のチェックルールを追加することによって、品質診断装置を簡単にカスタマイズすることができる。
【００２０】
次に、本実施例１に係る品質診断装置の構成について説明する。図２は、本実施例１に係る品質診断装置の構成を示す機能ブロック図である。同図に示すように、この品質診断装置１００は、ツールアダプタ１１０と、チェックエンジン１２０と、チェックルール記憶部１２５と、レポート出力部１３０と、共通メッセージ管理部１４０と、メインコントローラ１５０とを有する。
【００２１】
ツールアダプタ１１０は、ＦｘＣｏｐ、．ＴＥＳＴなどの他のチェックツールの起動、チェック結果のデータ変換などを行う処理部であり、品質診断装置１００から様々なチェックツールの利用を可能とする。このツールアダプタ１１０が、他のチェックツールのアダプタとして動作することによって、様々なチェックツールを品質診断装置１００から利用することができる。
【００２２】
チェックエンジン１２０は、ソースプログラムがフレームワーク仕様に則って作成されているか否かをチェックルールに基づいてチェックする処理部である。チェックルール記憶部１２５は、チェックルールを記憶する記憶部である。チェックエンジン１２０は、チェックルール記憶部１２５からチェックルールを読み出し、読み出した順番にチェックルールを用いてソースプログラムのチェックを行う。なお、チェックルールを用いたチェックエンジン１２０の処理の詳細については後述する。
【００２３】
レポート出力部１３０は、ツールアダプタ１１０から起動されたツールおよびチェックエンジン１２０によるチェック結果を一つのレポートとして統一した形式で出力する処理部である。共通メッセージ管理部１４０は、品質診断装置１００が扱うメッセージを共通に管理する管理部である。
【００２４】
メインコントローラ１５０は、品質診断装置１００全体の処理を制御する制御部であり、品質診断装置１００の初期化やツールアダプタ１１０、チェックエンジン１２０、レポート出力部１３０の起動などを行う。
【００２５】
次に、チェックルールを用いたチェックエンジン１２０の処理の詳細について説明する。図３は、チェックルールを用いたチェックエンジン１２０の処理を説明するための説明図である。同図に示すように、チェックエンジン１２０は、各チェックルールに対応するチェックモジュールを順番に起動することによってソースプログラムの静的チェックを行う。チェックルールはＸＭＬで記述され、各チェックルールには、起動するチェックモジュール名、チェックモジュールに渡すパラメータなどが記述される。図３では、ルールＡ〜ルールＤに対応するチェックモジュールがチェックエンジン１２０によって順番に起動されることによって、品質診断が行われる。
【００２６】
図４は、チェックルールおよびチェックモジュールの作成方法を示す図である。同図に示すように、新たなチェックルールを作成する場合には、各チェックルールを識別するルールＩＤを採番し、チェックルールが行うチェック処理を定義する。そして、チェック処理の具体的な手順を文書で記述し、この記述に基づいてチェック処理を行うチェックモジュールを作成する。
【００２７】
例えば、ルールＩＤが「２０１０２」であるチェックルールは、「View層(*.aspx.vb)ファイルに、"*ManagerParam"以外のパラメータクラスの記述があるか確認する」ルールであり、具体的には、「*.aspx.vbファイルを処理対象にして、変数宣言している場所の変数の型を取得し、変数の型がManagerParam以外ならＮＧとする」というチェック処理を行う。なお、図４では、対応するチェックモジュールは、Ruby言語で記述されている。
【００２８】
図５は、チェックルールの例を示す図である。同図に示すように、各チェックルールには、ルールＩＤ、チェックモジュール名などが含まれる。図５では、ルールＩＤが「２０１０２」、「２０１０３」、「２０１０４」であるチェックルールが示されている。
【００２９】
図６は、図５に示したチェックルールのうちルールＩＤが「２０１０２」であるチェックルールに対応するチェックモジュールを示す図である。このチェックモジュールによって、「View層(*.aspx.vb)ファイルに、"*ManagerParam"以外のパラメータクラスの記述があるか確認する」処理が行われる。
【００３０】
図７は、ルールＩＤが「２０１０２」であるチェックルールの具体的な処理と、対応するチェックモジュールのソースコードとの対応を示す図である。同図に示すように、「*.aspx.vbファイルを処理対象とする」は、「if  getFileName.execute・・・」に対応し、「変数宣言している場所の変数の型を取得する」は、「variables=getVariableType.execute・・・」に対応し、「変数の型がManagerParam以外ならＮＧ」は「re=Regexp.new(/ManagerParam/)・・・findWordResult.result」に対応する。
【００３１】
なお、図８−１〜図８−３に他のチェックルールの概要（一部）を示す。図８−１は、コーディングスタイル、コメント、データベースなどに関するチェックルールの概要を示し、図８−２は、ＳＱＬ、例外処理に関するチェックルールの概要を示し、図８−３は、命名規則、宣言などに関するチェックルールの概要を示す。
【００３２】
例えば、ＳＱＬに関するチェックルールとしては、図８−２に示すように、「ＳＱＬ文の記述ルールをチェックする為、ＳＱＬの予約語の記述で大文字、小文字が統一されているかを検出する」、「テーブル名の後に短縮名が指定されているかを検出する」、「ＳＥＬＥＣＴ句内に＊が存在するかを検出する」、「ＷＨＥＲＥ句内で、算術演算したものを比較対象にしているかを検出する」、「ＪＯＩＮの記述があるかを検出する」といったルールがある。
【００３３】
次に、本実施例１に係る品質診断装置１００の処理手順について説明する。図９は、本実施例１に係る品質診断装置１００の処理手順を示すフローチャートである。同図に示すように、この品質診断装置１００は、メインコントローラ１５０が初期化処理を行い（ステップＳ１）、ツールアダプタ１１０、チェックエンジン１２０、レポート出力部１３０を順に起動して品質診断処理を行う。
【００３４】
すなわち、ツールアダプタ１１０が、他のチェックツールを起動してチェックを行い（ステップＳ２）、チェックエンジン１２０が、チェックルールに基づいて静的チェックを行い（ステップＳ３）、レポート出力部１３０が他のチェックツールによるチェック結果およびチェックエンジン１２０によるチェック結果をまとめてレポート出力を行う（ステップＳ４）。
【００３５】
このように、メインコントローラ１５０がツールアダプタ１１０、チェックエンジン１２０、レポート出力部１３０を順に起動して品質診断処理を行うことによって、各ツールを個別に実行する場合と比較して、ユーザは簡単な操作で効率良く様々なチェックを行うことができる。
【００３６】
次に、チェックエンジン１２０による静的チェック処理の処理手順について説明する。図１０は、チェックエンジン１２０による静的チェック処理の処理手順を示すフローチャートである。同図に示すように、チェックエンジン１２０は、チェック対象のソースプログラムであるターゲットソースの一覧を取得する（ステップＳ３１）。また、チェックルールの一覧およびチェックモジュールの一覧を取得する（ステップＳ３２〜ステップＳ３３）。
【００３７】
そして、チェックルールが存在する間（ステップＳ３４、Ｙｅｓ）は、各チェックルールに対応するチェックモジュールを実行し（ステップＳ３５）、各チェックモジュールの実行結果を一時的に保存する（ステップＳ３６）。
【００３８】
そして、全てのチェックルールのチェックが終了する（ステップＳ３４、Ｎｏ）と、一時的に保存したチェック結果をまとめてファイルに保存し（ステップＳ３７）、処理を終了する。
【００３９】
このように、チェックエンジン１２０が各チェックルールに対応するチェックモジュールを順番に実行することによって、ソースプログラムがフレームワーク仕様に則って作成されているか否かのチェックを行うことができる。
【００４０】
次に、レポート出力部１３０によるレポート出力処理の処理手順について説明する。図１１は、レポート出力部１３０によるレポート出力処理の処理手順を示すフローチャートである。同図に示すように、レポート出力部１３０は、ターゲットソースの一覧を取得する（ステップＳ４１）。
【００４１】
そして、ターゲットソースに対する結果ファイルが存在する間（ステップＳ４２、Ｙｅｓ）は、結果ファイルを読み出して結果の一覧を取得し（ステップＳ４３）、レポートの出力を行う（ステップＳ４４）。レポートは、ＣＳＶ形式、ＨＴＭＬ形式、ＸＭＬ形式の中からユーザに指定された形式（複数可）で出力する。
【００４２】
そして、全ての結果ファイルの処理が終了する（ステップＳ４２、Ｎｏ）と、ＨＴＭＬ形式の出力があるか否かを判定し（ステップＳ４５）、ＨＴＭＬ形式の出力がある場合には、Index.htmを出力する（ステップＳ４６）。
【００４３】
上述してきたように、本実施例１では、チェックエンジン１２０が、ソースプログラムがフレームワーク仕様に則って作成されているか否かをチェックして、ソースプログラムの品質を診断することとしたので、開発者のスキルレベルを評価するとともに、ソースプログラムの品質を向上することができる。また、ソースプログラムの開発を委託する場合には、委託先のスキルを評価することができるとともに、受入検査を効率良く行うことができる。
【００４４】
また、本実施例１では、チェックエンジン１２０が、チェックルール記憶部１２５が記憶するチェックルールに基づいてソースプログラムをチェックすることとしたので、チェックルールを作成するだけで様々なチェックを柔軟に行うことができる。
【００４５】
また、本実施例１では、ツールアダプタ１１０が他のチェックツールを起動して他のチェックツールによるチェックを行い、レポート出力部１３０が他のチェックツールによるチェック結果とチェックエンジン１２０によるチェック結果をまとめてレポート出力することとしたので、ユーザは各ツールを個別に実行する必要がなく、効率良くソースプログラムのチェックを行うことができる。
【００４６】
なお、本実施例１では、品質診断装置について説明したが、品質診断装置が有する構成をソフトウェアによって実現することで、同様の機能を有する品質診断プログラムを得ることができる。そこで、この品質診断プログラムを実行するコンピュータについて説明する。
【００４７】
図１２は、本実施例１に係る品質診断プログラムを実行するコンピュータの構成を示す機能ブロック図である。同図に示すように、このコンピュータ２００は、ＲＡＭ２１０と、ＣＰＵ２２０と、ＨＤＤ２３０と、ＬＡＮインタフェース２４０と、入出力インタフェース２５０と、ＤＶＤドライブ２６０とを有する。
【００４８】
ＲＡＭ２１０は、プログラムやプログラムの実行途中結果などを記憶するメモリであり、ＣＰＵ２２０は、ＲＡＭ２１０からプログラムを読み出して実行する中央処理装置である。ＨＤＤ２３０は、プログラムやデータを格納するディスク装置であり、ＬＡＮインタフェース２４０は、コンピュータ２００をＬＡＮ経由で他のコンピュータに接続するためのインタフェースである。入出力インタフェース２５０は、マウスやキーボードなどの入力装置および表示装置を接続するためのインタフェースであり、ＤＶＤドライブ２６０は、ＤＶＤの読み書きを行う装置である。
【００４９】
そして、このコンピュータ２００において実行される品質診断プログラム２１１は、ＤＶＤに記憶され、ＤＶＤドライブ２６０によってＤＶＤから読み出されてコンピュータ２００にインストールされる。あるいは、この品質診断プログラム２１１は、ＬＡＮインタフェース２４０を介して接続された他のコンピュータシステムのデータベースなどに記憶され、これらのデータベースから読み出されてコンピュータ２００にインストールされる。そして、インストールされた品質診断プログラム２１１は、ＨＤＤ２３０に記憶され、ＲＡＭ２１０に読み出されてＣＰＵ２２０によって実行される。
【００５０】
また、本実施例１では、フレームワークを利用して作成されるソースプログラムの品質をチェックする場合について説明したが、本発明はこれに限定されるものではなく、フレームワークを利用して作成される任意のフレームワーク利用文書の品質をチェックする場合にも同様に適用することができる。
【００５１】
なお、以下に本実施例１に係るフレームワークの詳細について説明する。図１３は、本実施例１に係るフレームワークを説明するための説明図である。同図（ａ）は一般的なフレームワークを示し、同図（ｂ）は本実施例１に係るフレームワークを示す。
【００５２】
同図（ａ）に示すように、一般的に、プログラムは個々のプログラムで異なる処理を行う部分とどのプログラムでも共通的な処理を行う部分とから構成される。個々のプログラムで異なる処理を行う部分はプログラムごとに開発する必要があるが、どのプログラムでも共通的な処理を行う部分は共通部品として開発されたものを利用することができる。このような共通部品を一般的にはフレームワークと呼んでいる。
【００５３】
これに対して、同図（ｂ）に示すように、本実施例１に係るフレームワークは、共通部品以外に、開発標準や開発ツールを含む。ここで、開発標準とは、ソフトウェア開発の標準を示す文書であり、特に、共通部品の理想的な使用方法や行ってはいけない処理方法などを記述した方式設計書が重要となる。また、開発ツールは、自動的に共通部品を利用するソースコードを生成する。例えば、開発ツールは、入力チェック部品を使用する上で、入力チェックを行う画面項目と、入力チェックの型を設定すると、共通部品の理想的な使用方法で記述されたプログラムを自動生成する。
【００５４】
このように、本実施例１に係るフレームワークは、共通部品以外に開発標準や開発ツールを含むことから、品質診断装置１００は、一般的なフレームワークのチェックとして行われる共通部品の使用方法のチェック以外のチェックも行う。
【００５５】
図１４は、品質診断装置１００が共通部品の使用方法のチェック以外に行うチェックを説明するための説明図である。同図（ａ）は、二つの入力チェックを行う共通部品に対して品質診断装置１００が行う整合性チェックを示しており、品質診断装置１００は、共通部品同士の整合性、利用方法のチェックを行う。入力チェックＡおよび入力チェックＢそれぞれの利用方法が正しい場合でも、両者を組み合わせることによって不整合や意図しない動作が発生する場合があり、品質診断装置１００は、このような共通部品同士の整合性のチェックを行う。
【００５６】
同図（ｂ）は、業務ロジックとの関係で共通部品の使用方法をチェックする例を示している。この例では、品質診断装置１００は、業務ロジックでＡ画面項目は「文字型」と記述されているのに対して、入力チェックで「数字型」のチェックが行われているといったチェックを行う。
【００５７】
同図（ｃ）は、業務ロジックとの関係で共通部品の使用方法をチェックする他の例を示している。この例では、品質診断装置１００は、本来、共通部品を利用すべき入力チェック等を業務ロジックで独自に実装していないかといったチェックを行う。
【００５８】
同図（ｄ）は、方式設計書に基づいて行うチェックを示している。品質診断装置１００は、方式設計書で定義されている内容が正しくソースコードに反映されているかといったチェックを行う。
【００５９】
図１５は、図１４に示したチェックを行うチェックルールの例を示す図である。各チェックルールは、チェックルール番号、チェックルールの分類情報、チェック内容から構成される。図１５（ａ）は、入力チェック同士の不整合をチェックするチェックルールを示す。このチェックルールは、例えば、数値チェックと文字チェックの両方を行っていないかといったチェックを行う。
【００６０】
図１５（ｂ）は、業務ロジックとの関係で共通部品の使用方法をチェックするチェックルールを示す。このチェックルールは、例えば、業務ロジック部分で、画面の文字位置の揃えを右寄せに設定した場合、想定される入力文字は「数値（金額等）」が想定されるのに、入力チェック部品で「文字チェック」を行っていないかといったチェックを行う。
【００６１】
図１５（ｃ）は、業務ロジックとの関係で共通部品の使用方法をチェックする他のチェックルールを示す。このチェックルールは、画面のデータを変数に代入するときに、画面項目転記部品を使用しているかをチェックする。画面項目の変数への代入は、代入文を使っても行えるが、大量の画面項目を転記する場合には、画面項目転記部品を使用した方が効率が良い。
【００６２】
図１５（ｄ）は、方式設計書に基づいてチェックを行うチェックルールを示している。このチェックルールは、コントローラＣとマネージャＭとの間でデータを受け渡すときに、５つ以上の引数を渡していないかをチェックする。５つ以上のデータを渡す場合には、オブジェクトの中に変数を組み込み、代入を行うことが、方式設計書に記載されている。
【００６３】
図１６は、品質診断装置１００による品質チェックの効果を示す図である。同図に示すように、品質診断装置１００による品質チェックを行わない場合には個人によって記述方法が異なっていたプログラムが、品質診断装置１００による品質チェックを行うことによって、統一的な記述方法に基づいて記述されたプログラムとなる。したがって、プログラムの可読性、保守性を向上させることができる。
【実施例２】
【００６４】
ところで、上記実施例１では、全てのチェックルールをチェックする場合について説明した。しかしながら、全てのチェックルールを全てのプログラムに対して適用しようとすると、図１７に示すような問題がある。同図（ａ）は、全てのチェックルールを全てのプログラムに対して適用する場合を示し、この場合には、品質診断の処理時間が長いという問題がある。
【００６５】
そこで、同図（ｂ）に示すように、プログラムの種類を大まかに判定し、プログラム種類に応じて適用するチェックルールを変えることが考えられる。同図（ｂ）は、画面系プログラムに対して画面系のチェックルールを適用する場合を示している。しかしながら、大まかに判定されたプログラム種類に応じて適用するチェックルールを変えることとすると、チェックルールの適用漏れが発生する可能性がある。
【００６６】
また、同図（ｃ）に示すように、使用するチェックルールをルールごとに使用者が選択することも考えられるが、チェックルールの数が多くなると選択する作業が煩雑になる。
【００６７】
そこで、本実施例２では、使用するチェックルールを自動的に選択して品質診断を行う品質診断装置について説明する。図１８は、本実施例２に係る品質診断装置によるチェックルールの自動選択を説明するための説明図である。同図に示すように、本実施例２に係る品質診断装置は、診断の対象となる全プログラムの特性をチェックし、全チェックルールの中から必要なチェックルールだけを自動的に選択し、選択したチェックルールのみを適用して品質診断を行う。このように、品質診断装置が必要なチェックルールだけを自動的に選択して品質診断を行うことによって、正確な品質診断を効率よく行うことができる。
【００６８】
図１９は、本実施例２に係るチェックルールの構造を示す図である。同図に示すように、各チェックルールは、自動選択機能部とチェック処理実装部とから構成される。自動選択機能部は、チェックルールの選択に使用され、チェック処理実装部はプログラムのチェックに使用される。
【００６９】
例えば、通常の業務アプリケーションプログラムは、「画面」、「コントローラ」、「ロジック」の三階層に分類され、画面系のプログラムのファイルは必ずファイル名が「.aspx.vb」で終わっている。そこで、画面系のプログラムのチェックに使用されるチェックルールの自動選択機能部には、ファイル名が「.aspx.vb」で終わっているファイルに対してチェック処理を実施することが記述されている。
【００７０】
したがって、本実施例２に係る品質診断装置は、自動選択機能部にファイル名が「.aspx.vb」で終わっているファイルに対してチェック処理を実施することが記述されているかを判定することによって、画面系のプログラムのチェックに使用するチェックルールを自動的に選択することができる。
【００７１】
図２０は、本実施例２に係る品質診断装置の処理手順を説明するための説明図である。同図に示すように、本実施例２に係る品質診断装置は、まずチェックルールを選択するルール自動選択機能を実行し、診断の対象プログラムのチェックに必要なチェックルールを選択する。ここでは、対象プログラムが画面系のプログラムであるため、ファイル名が「.aspx.vb」で終わっているファイルをチェック対象とするチェックルールが選択する。
【００７２】
そして、本実施例２に係る品質診断装置は、選択したチェックルールだけを実行する。ここでは、画面系のプログラムをチェックするチェックルールだけを実行する。このように、本実施例２に係る品質診断装置は、診断の対象プログラムのチェックに必要なチェックルールを選択し、選択したチェックルールだけを実行することによって、効率良く品質診断を行うことができる。
【００７３】
図２１は、本実施例２に係る品質診断装置の構成を示す機能ブロック図である。なお、ここでは説明の便宜上、図２に示した各部と同様の役割を果たす機能部については同一符号を付すこととしてその詳細な説明を省略する。
【００７４】
図２１に示すように、本実施例２に係る品質診断装置３００は、図２に示した品質診断装置１００と比較して、チェックエンジン１２０およびチェックルール記憶部１２５の代わりにチェックエンジン３２０およびチェックルール記憶部３２５をそれぞれ有する。
【００７５】
チェックルール記憶部３２５は、図１９に示した構成のチェックルールを記憶する記憶部である。チェックエンジン３２０は、チェックルール記憶部３２５に記憶されたチェックルールの中から、診断対象プログラムのチェックに必要なチェックルールだけを選択して実行する。
【００７６】
このように、本実施例２では、チェックルール記憶部３２５が自動選択機能部とチェック処理実装部とから構成されるチェックルールを記憶し、チェックエンジン３２０がチェックルール記憶部３２５に記憶されたチェックルールの中から診断対象プログラムのチェックに必要なチェックルールだけを選択して実行することとしたので、効率良く正確に品質診断を行うことができる。
【実施例３】
【００７７】
チェックルールを用いた品質診断では、ユーザに特化したチェックルールをユーザごとに追加することによって、各ユーザに適したフレームワークのチェックを行うことが可能となる。
【００７８】
しかしながら、図２２に示すように、ユーザごとに作成されるチェックルールは、共通に使用されるチェックルールと比較して、厳密な検証・検査がされない可能性が高く、チェックルール自体の精度・品質が高くない場合もある。このため、ユーザが定義したチェックルールを用いて行われた品質診断は、必ずしも結果が正しいとは限らない。したがって、精度の高い品質診断を行うためには、チェックルール自体の品質をチェックすることが必要となる。
【００７９】
そこで、本実施例３では、チェックルールの品質を評価する機能を備えた品質診断装置について説明する。図２３は、本実施例３に係る品質診断装置によるチェックルールの自動評価を説明するための説明図である。
【００８０】
同図に示すように、本実施例３に係る品質診断装置は、チェックルールごとにプログラムのチェック結果を集計する。例えば、図２３では、「ルールＡ」について、適用回数、チェック結果がＯＫ（＋）であった回数、チェック結果がＮＧ（−）であった回数が集計されている。
【００８１】
そして、本実施例３に係る品質診断装置は、ＯＫとＮＧの合計値すなわち適用回数と所定の閾値範囲とを比較し、適用回数が所定の閾値範囲外にある場合には、チェックルールが不適切に多く適用された場合または不適切に少なく適用された場合であるので、チェックルールに問題があると判定する。
【００８２】
一方、適用回数が所定の閾値範囲内にある場合には、ＯＫが多いときは、チェック対象となったプログラムの品質が高いと判定し、ＮＧが多いときは、チェック対象となったプログラムの品質が低いと判定する。
【００８３】
また、本実施例３に係る品質診断装置は、ＯＫおよびＮＧをそれぞれの所定の閾値と比較し、両方がそれぞれの所定の閾値以上である場合には、チェックルールの適用によってプログラムが良いと判定している場合も悪いと判定している場合も多い場合であるので、チェックルールに問題があると判定する。
【００８４】
また、本実施例３に係る品質診断装置は、チェックルールをカテゴリ別に分類し、カテゴリごとに適用回数を集計する。そして、あるカテゴリに属するチェックルールの適用回数とそのカテゴリに属する全チェックルールの適用回数の平均値との差を所定の閾値と比較し、所定の閾値以上であれがそのチェックルールに問題があると判定する。
【００８５】
そして、本実施例３に係る品質診断装置は、チェックルールの判定結果、プログラム品質の判定結果をレポート出力する。このように、本実施例３に係る品質診断装置は、各チェックルールの適用結果を集計し、集計結果に基づいてチェックルールを評価することによって、チェックルール自体の品質を向上することができる。
【００８６】
図２４は、本実施例３に係る品質診断装置の構成を示す機能ブロック図である。なお、ここでは説明の便宜上、図２１に示した各部と同様の役割を果たす機能部については同一符号を付すこととしてその詳細な説明を省略する。
【００８７】
図２４に示すように、本実施例３に係る品質診断装置４００は、図２１に示した品質診断装置３００と比較して、チェックエンジン３２０の代わりにチェックエンジン４２０を有し、新たに適用結果記憶部４６０とルール評価部４７０とを有する。
【００８８】
チェックエンジン４２０は、プログラムのチェックを行うとともに、適用したチェックルールについて、適用結果（ＯＫとＮＧ）ごとに回数を集計し適用結果記憶部４６０に格納する。
【００８９】
適用結果記憶部４６０は、各チェックルールについて適用結果ごとに回数を記憶する記憶部である。また、この適用結果記憶部４６０は、チェックルールのカテゴリ分類結果を記憶する。
【００９０】
ルール評価部４７０は、適用結果記憶部４６０に記憶されたデータに基づいて各チェックルールを評価する処理部である。すなわち、このルール評価部４７０は、各チェックルールの適用回数と所定の閾値範囲とを比較し、各チェックルールの評価を行う。また、このルール評価部４７０は、ＯＫおよびＮＧを所定の閾値と比較することによって、プログラムの品質やチェックルールの評価を行う。
【００９１】
また、このルール評価部４７０は、カテゴリごとに適用回数の平均値を算出し、そのカテゴリに属する各チェックルールの適用回数との差を所定の閾値と比較し、各チェックルールの評価を行う。そして、このルール評価部４７０は、チェックルールの評価結果、プログラム品質の判定結果をレポート出力する。
【００９２】
このように、チェックエンジン４２０が適用したチェックルールについて適用結果（ＯＫとＮＧ）ごとに回数を集計し、ルール評価部４７０が、各チェックルールの適用結果の集計結果に基づいて各チェックルールを評価することによって、チェックルールの品質を向上することができる。
【００９３】
（付記１）フレームワークを利用して作成されるフレームワーク利用文書がフレームワーク仕様に則って作成されているか否かを検査するフレームワーク検査手順と、
前記フレームワーク検査手順により検査された結果を出力する検査結果出力手順と、
をコンピュータに実行させることを特徴とする品質診断プログラム。
【００９４】
（付記２）前記フレームワーク検査手順は、フレームワーク利用文書がフレームワーク仕様に則って作成されているか否かを検査するチェックルールに基づいてフレームワーク利用文書を検査することを特徴とする付記１に記載の品質診断プログラム。
【００９５】
（付記３）前記チェックルールは、チェックを実行するチェックモジュールの識別する識別子を含み、
前記フレームワーク検査手順は、チェックルールに含まれる識別子で識別されるチェックモジュールを実行することによりフレームワーク利用文書を検査することを特徴とする付記２に記載の品質診断プログラム。
【００９６】
（付記４）前記フレームワーク検査手順が検査するフレームワーク利用文書は、ソースプログラムであることを特徴とする付記１、２または３に記載の品質診断プログラム。
【００９７】
（付記５）前記フレームワーク検査手順による検査は、データベースへのアクセスがフレームワーク仕様に則って行われているか否かの検査を含むことを特徴とする付記４に記載の品質診断プログラム。
【００９８】
（付記６）他のチェックツールを起動して他のチェックツールによる検査を行う他ツール実行手順をさらにコンピュータに実行させ、
前記検査結果出力手順は、前記フレームワーク検査手順により検査された結果および前記他ツール実行手順によるチェック結果をまとめてレポートとして出力することを特徴とする付記４または５に記載の品質診断プログラム。
【００９９】
（付記７）フレームワークを利用して作成されるフレームワーク利用文書がフレームワーク仕様に則って作成されているか否かを検査するフレームワーク検査ステップと、
前記フレームワーク検査ステップにより検査された結果を出力する検査結果出力ステップと、
を含んだことを特徴とする品質診断方法。
【０１００】
（付記８）前記フレームワーク検査ステップは、フレームワーク利用文書がフレームワーク仕様に則って作成されているか否かを検査するチェックルールに基づいてフレームワーク利用文書を検査することを特徴とする付記７に記載の品質診断方法。
【０１０１】
（付記９）前記チェックルールは、チェックを実行するチェックモジュールの識別する識別子を含み、
前記フレームワーク検査ステップは、チェックルールに含まれる識別子で識別されるチェックモジュールを実行することによりフレームワーク利用文書を検査することを特徴とする付記８に記載の品質診断方法。
【０１０２】
（付記１０）前記フレームワーク検査ステップが検査するフレームワーク利用文書は、ソースプログラムであることを特徴とする付記７、８または９に記載の品質診断方法。
【０１０３】
（付記１１）前記フレームワーク検査ステップによる検査は、データベースへのアクセスがフレームワーク仕様に則って行われているか否かの検査を含むことを特徴とする付記１０に記載の品質診断方法。
【０１０４】
（付記１２）他のチェックツールを起動して他のチェックツールによる検査を行う他ツール実行ステップをさらに含み、
前記検査結果出力ステップは、前記フレームワーク検査ステップにより検査された結果および前記他ツール実行ステップによるチェック結果をまとめてレポートとして出力することを特徴とする付記１０または１１に記載の品質診断方法。
【０１０５】
（付記１３）フレームワークを利用して作成されるフレームワーク利用文書がフレームワーク仕様に則って作成されているか否かを検査するフレームワーク検査手段と、
前記フレームワーク検査手段により検査された結果を出力する検査結果出力手段と、
を備えたことを特徴とする品質診断装置。
【０１０６】
（付記１４）前記フレームワーク検査手段は、フレームワーク利用文書がフレームワーク仕様に則って作成されているか否かを検査するチェックルールに基づいてフレームワーク利用文書を検査することを特徴とする付記１３に記載の品質診断装置。
【０１０７】
（付記１５）前記チェックルールは、チェックを実行するチェックモジュールの識別する識別子を含み、
前記フレームワーク検査手段は、チェックルールに含まれる識別子で識別されるチェックモジュールを実行することによりフレームワーク利用文書を検査することを特徴とする付記１４に記載の品質診断装置。
【０１０８】
（付記１６）前記フレームワーク検査手段が検査するフレームワーク利用文書は、ソースプログラムであることを特徴とする付記１３、１４または１５に記載の品質診断装置。
【０１０９】
（付記１７）前記フレームワーク検査手段による検査は、データベースへのアクセスがフレームワーク仕様に則って行われているか否かの検査を含むことを特徴とする付記１６に記載の品質診断装置。
【０１１０】
（付記１８）他のチェックツールを起動して他のチェックツールによる検査を行う他ツール実行手段をさらに備え、
前記検査結果出力手段は、前記フレームワーク検査手段により検査された結果および前記他ツール実行手段によるチェック結果をまとめてレポートとして出力することを特徴とする付記１６または１７に記載の品質診断装置。
【産業上の利用可能性】
【０１１１】
以上のように、本発明に係る規則検査プログラム、規則検査方法および規則検査装置は、フレームワークを用いたソフトウェアの開発などに有用である。
【図面の簡単な説明】
【０１１２】
【図１】本実施例１に係る品質診断の概念を説明するための説明図である。
【図２】本実施例１に係る品質診断装置の構成を示す機能ブロック図である。
【図３】チェックルールを用いたチェックエンジンの処理を説明するための説明図である。
【図４】チェックルールおよびチェックモジュールの作成方法を示す図である。
【図５】チェックルールの例を示す図である。
【図６】図５に示したチェックルールのうちルールＩＤが「２０１０２」であるチェックルールに対応するチェックモジュールを示す図である。
【図７】ルールＩＤが「２０１０２」であるチェックルールの具体的な処理と、対応するチェックモジュールのソースコードとの対応を示す図である。
【図８−１】他のチェックルールの概要（一部）を示す図（１）である。
【図８−２】他のチェックルールの概要（一部）を示す図（２）である。
【図８−３】他のチェックルールの概要（一部）を示す図（３）である。
【図９】本実施例１に係る品質診断装置の処理手順を示すフローチャートである。
【図１０】チェックエンジンによる静的チェック処理の処理手順を示すフローチャートである。
【図１１】レポート出力部によるレポート出力処理の処理手順を示すフローチャートである。
【図１２】本実施例１に係る品質診断プログラムを実行するコンピュータの構成を示す機能ブロック図である。
【図１３】本実施例１に係るフレームワークを説明するための説明図である。
【図１４】品質診断装置が共通部品の使用方法のチェック以外に行うチェックを説明するための説明図である。
【図１５】図１４に示したチェックを行うチェックルールの例を示す図である。
【図１６】品質診断装置によるチェックの効果を示す図である。
【図１７】チェックルールを用いた品質診断の課題を説明するための説明図である。
【図１８】チェックルールの自動選択を説明するための説明図である。
【図１９】本実施例２に係るチェックルールの構造を示す図である。
【図２０】本実施例２に係る品質診断装置の処理手順を説明するための説明図である。
【図２１】本実施例２に係る品質診断装置の構成を示す機能ブロック図である。
【図２２】チェックルールを用いた品質診断の他の課題を説明するための説明図である。
【図２３】チェックルールの自動評価を説明するための説明図である。
【図２４】本実施例３に係る品質診断装置の構成を示す機能ブロック図である。
【符号の説明】
【０１１３】
１００，３００，４００    品質診断装置
１１０    ツールアダプタ
１２０，３２０，４２０    チェックエンジン
１２５，３２５    チェックルール記憶部
１３０    レポート出力部
１４０    共通メッセージ管理部
１５０    メインコントローラ
２００    コンピュータ
２１０    ＲＡＭ
２１１    品質診断プログラム
２２０    ＣＰＵ
２３０    ＨＤＤ
２４０    ＬＡＮインタフェース
２５０    入出力インタフェース
２６０    ＤＶＤドライブ
４６０    適用結果記憶部
４７０    ルール評価部
【図１】
2009099111.tif 000003
【図２】
2009099111.tif 000004
【図３】
2009099111.tif 000005
【図４】
2009099111.tif 000006
【図５】
2009099111.tif 000007
【図６】
2009099111.tif 000008
【図７】
2009099111.tif 000009
【図８−１】
2009099111.tif 000010
【図８−２】
2009099111.tif 000011
【図８−３】
2009099111.tif 000012
【図９】
2009099111.tif 000013
【図１０】
2009099111.tif 000014
【図１１】
2009099111.tif 000015
【図１２】
2009099111.tif 000016
【図１３】
2009099111.tif 000017
【図１４】
2009099111.tif 000018
【図１５】
2009099111.tif 000019
【図１６】
2009099111.tif 000020
【図１７】
2009099111.tif 000021
【図１８】
2009099111.tif 000022
【図１９】
2009099111.tif 000023
【図２０】
2009099111.tif 000024
【図２１】
2009099111.tif 000025
【図２２】
2009099111.tif 000026
【図２３】
2009099111.tif 000027
【図２４】
2009099111.tif 000028
【手続補正書】
【提出日】平成20年9月26日(2008.9.26)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査手順と、
前記フレームワーク検査手順により検査された結果を出力する検査結果出力手順と、
をコンピュータに実行させ、
前記フレームワーク検査手順は、フレームワーク仕様に則って作成されているか否かの検査として、ソースプログラムに含まれる業務ロジックおよび共通部品利用について業務ロジックにおける画面項目の型と入力チェックを行う共通部品における該画面項目の型とが一致しているか否かを含む検査を行うことを特徴とする規則検査プログラム。
【請求項２】
前記フレームワーク検査手順は、フレームワーク仕様に則って作成されているか否かの検査として、さらに、共通部品で行われるべき処理が業務ロジックに含まれているか否かを含む検査を行うことを特徴とする請求項１に記載の規則検査プログラム。
【請求項３】
前記フレームワーク検査手順は、ソースプログラムのファイル名の末尾が所定の文字列と一致するか否かを判定することによってソースプログラムが画面系のプログラムであるか否かを判定し、ソースプログラムが画面系のプログラムである場合には、画面系のチェックルールによりソースプログラムを検査することを特徴とする請求項１に記載の規則検査プログラム。
【請求項４】
前記フレームワーク検査手順は、チェックルールの適用回数を収集し、適用したチェックルールごとに記憶装置に書き込み、
前記フレームワーク検査手順によりチェックルールごとに書き込まれた適用回数を記憶装置から読み出して該適用回数と所定の閾値範囲とを比較し、該適用回数が所定の閾値範囲外にあるか否かに基づいて、チェックルールに問題があるか否かを評価するルール評価手順
をさらにコンピュータに実行させることを特徴とする請求項１に記載の規則検査プログラム。
【請求項５】
前記フレームワーク検査手順は、各チェックルールのチェック結果が問題なしの回数と問題ありの回数をチェックルールごとに収集して記憶装置に書き込み、
前記ルール評価手順は、チェックルールごとにチェック結果が問題なしの回数および問題ありの回数をそれぞれ所定の閾値と比較し、問題なしの回数および問題ありの回数の両方が所定の閾値以上である場合に、チェックルールに問題があると評価することを特徴とする請求項４に記載の規則検査プログラム。
【請求項６】
業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査ステップと、
前記フレームワーク検査ステップにより検査された結果を出力する検査結果出力ステップと、
を含み、
前記フレームワーク検査ステップは、フレームワーク仕様に則って作成されているか否かの検査として、ソースプログラムに含まれる業務ロジックおよび共通部品利用について業務ロジックにおける画面項目の型と入力チェックを行う共通部品における該画面項目の型とが一致しているか否かを含むことを特徴とする、規則検査装置による規則検査方法。
【請求項７】
業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査手段と、
前記フレームワーク検査手段により検査された結果を出力する検査結果出力手段と、
を備え、
前記フレームワーク検査手段は、フレームワーク仕様に則って作成されているか否かの検査として、ソースプログラムに含まれる業務ロジックおよび共通部品利用について業務ロジックにおける画面項目の型と入力チェックを行う共通部品における該画面項目の型とが一致しているか否かを含む検査を行うことを特徴とする規則検査装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
上述した課題を解決し、目的を達成するため、本発明は、業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査手順と、前記フレームワーク検査手順により検査された結果を出力する検査結果出力手順と、をコンピュータに実行させ、前記フレームワーク検査手順は、フレームワーク仕様に則って作成されているか否かの検査として、ソースプログラムに含まれる業務ロジックおよび共通部品利用について業務ロジックにおける画面項目の型と入力チェックを行う共通部品における該画面項目の型とが一致しているか否かを含む検査を行うことを特徴とする。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】変更
【補正の内容】
【００１１】
また、本発明は、業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査ステップと、前記フレームワーク検査ステップにより検査された結果を出力する検査結果出力ステップと、を含み、前記フレームワーク検査ステップは、フレームワーク仕様に則って作成されているか否かの検査として、ソースプログラムに含まれる業務ロジックおよび共通部品利用について業務ロジックにおける画面項目の型と入力チェックを行う共通部品における該画面項目の型とが一致しているか否かを含む検査を行うことを特徴とする。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】変更
【補正の内容】
【００１２】
また、本発明は、業務アプリケーションに関してフレームワークを利用して作成されるソースプログラムがフレームワーク仕様に則って作成されているか否かを、記憶装置に格納されたチェックルールを読み出し、該読み出したチェックルールで指定されるチェックモジュールを起動することにより検査するフレームワーク検査手段と、前記フレームワーク検査手段により検査された結果を出力する検査結果出力手段と、を備え、前記フレームワーク検査手段は、フレームワーク仕様に則って作成されているか否かの検査として、ソースプログラムに含まれる業務ロジックおよび共通部品利用について業務ロジックにおける画面項目の型と入力チェックを行う共通部品における該画面項目の型とが一致しているか否かを含む検査を行うことを特徴とする。