JP2004362000A - ウェブアプリケーション開発支援装置、コンポーネント呼び出し監視装置、データ処理方法及びプログラム - Google Patents
ウェブアプリケーション開発支援装置、コンポーネント呼び出し監視装置、データ処理方法及びプログラム Download PDFInfo
- Publication number
- JP2004362000A JP2004362000A JP2003156042A JP2003156042A JP2004362000A JP 2004362000 A JP2004362000 A JP 2004362000A JP 2003156042 A JP2003156042 A JP 2003156042A JP 2003156042 A JP2003156042 A JP 2003156042A JP 2004362000 A JP2004362000 A JP 2004362000A
- Authority
- JP
- Japan
- Prior art keywords
- component call
- component
- information
- call
- monitor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
- G06F16/972—Access to data in other repository systems, e.g. legacy data or dynamic Web page generation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Databases & Information Systems (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
【課題】ＪＳＰページとその関連するコンポーネントとの間の整合・不整合を解析し、自動的に検証する方法およびツールを提供する。
【解決手段】動的にコンテンツが生成されるウェブページにおけるコンポーネント呼び出しの実行を監視して、このコンポーネント呼び出しに関する情報を抽出するモニタ２０と、このモニタ２０により抽出されたコンポーネント呼び出しに関する情報に基づいて、このコンポーネント呼び出しとその対象であるコンポーネントとの整合性を検証する整合性検証部３０とを備える。
【選択図】 図４
【解決手段】動的にコンテンツが生成されるウェブページにおけるコンポーネント呼び出しの実行を監視して、このコンポーネント呼び出しに関する情報を抽出するモニタ２０と、このモニタ２０により抽出されたコンポーネント呼び出しに関する情報に基づいて、このコンポーネント呼び出しとその対象であるコンポーネントとの整合性を検証する整合性検証部３０とを備える。
【選択図】 図４
Description
【０００１】
【発明の属する技術分野】
本発明は、ウェブアプリケーション等に用いられるＪＳＰのコンポーネント呼び出しとコンポーネントとの整合性を検証する方法及びシステムに関する。
【０００２】
【従来の技術】
インターネット等のネットワークを介してサービスを提供するウェブアプリケーションで用いられる技術に、ウェブサーバにおいてスクリプト言語（サーバサイドスクリプト言語）を用いて動的にウェブページを生成し、クライアントに送信する技術がある。ＪＳＰ（ＪａｖａＳｅｒｖｅｒ Ｐａｇｅｓ：米国サン・マイクロシステムズ社の商標）は、この種のサーバサイドスクリプト言語のひとつであり、Ｊａｖａ（米国サン・マイクロシステムズ社の商標）言語を利用してこの機能を実現する（例えば、特許文献１、非特許文献１参照）。具体的には、ＪＳＰでは、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルの中にスクリプト（Ｊａｖａプログラム）で処理を記述しておき、クライアントの要求に応じてスクリプトを実行し、処理結果のみをクライアントに送信する。
【０００３】
したがって、ＪＳＰによる動的なコンテンツを含むウェブページ（以下、ＪＳＰページ）のファイルには、当該動的コンテンツを表現する言語に関して、ＪＳＰによる記述部分やＨＴＭＬによる記述部分など、多くの言語が同時に存在している。ＨＴＭＬの記述は、ウェブページをブラウザに表示した際のレイアウトや制御を実現する。一方、ＪＳＰの記述は、所定の処理を記述したスクリプトであり、実行時にサーブレットとして動作する。そして、当該スクリプトの設計に沿ってアクセス可能な他のコンポーネントに対して必要な操作を行い、この操作の結果をレスポンスとしてブラウザに送信する。
【０００４】
ここで、コンポーネントとは、オブジェクトを意味しており、ＪＳＰに関連するコンポーネントとは、Ｊａｖａビーンやメッセージリソース、ＪＳＰページが依存する他のＪＳＰページやウェブページなどを指す。
図２５は、ＪＳＰページに関連する主要なコンポーネント群を示す図である。
【０００５】
【特許文献１】
特開２００２？３６６５１４号公報
【非特許文献１】
“ＪａｖａＳｅｒｖｅｒ ＰａｇｅｓＴＭ ＤＹＮＡＭＩＣＡＬＬＹ ＧＥＮＥＲＡＴＥＤ ＷＥＢ ＣＯＮＴＥＮＴ”、［ｏｎｌｉｎｅ］、［平成１５年５月２１日検索］、インターネット＜ＵＲＬ： ＨＹＰＥＲＬＩＮＫ ”ｈｔｔｐ：／／ｗｗｗ．ｃｓ．ｈｕｔ．ｆｉ／￣ｃｔｌ／３ｄｍ／” ｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｊ２ｅｅ／ｊａ／ｊｓｐ／＞
【０００６】
【発明が解決しようとする課題】
上記のように、ウェブアプリケーション等に用いられるＪＳＰは、実行時、所定のコンポーネントに対してアクセスして必要な操作を行う。しかし、実際のウェブアプリケーション開発における結合テストや稼動テストでは、ＪＳＰの記述内容に関する仕様が開発前に予め定められていないために、ＪＳＰページのコンポーネント呼び出し部分と他の開発者によって開発されたコンポーネントとの間で不整合が発生する場合が多い。
そこで従来、ウェブアプリケーション開発時には、開発者の手作業によってＪＳＰページの記述の整合性を確認したり、実際にアプリケーションサーバー上での結合テストを行って不整合を１つ１つ検出したりすることが行われている。
【０００７】
しかし、ウェブアプリケーション内に膨大な数のコンポーネント呼び出し記述が存在する場合、ＪＳＰページのコンポーネント呼び出しとコンポーネントとの間の不整合を完全に検出することは容易ではない。
かかる不整合を完全に除去できないと、ウェブアプリケーション稼動後にも、当該ウェブアプリケーション内に潜在していた不整合のために、システムに障害が発生することも起こりうる。そして、障害が発生すれば、開発全体では余分なコストが発生することになる。
【０００８】
また、Ｊａｖａスクリプトレットのプログラムロジックや、ＪＳＰタグライブラリのように利用者が自由に作成したタグ記述表現を許していることが、ＪＳＰページとコンポーネント間の整合性を解析し自動的に検証することを困難にしていた。
【０００９】
そこで本発明は、上記の問題に鑑み、ＪＳＰページとその関連するコンポーネントとの間の整合・不整合を解析し、自動的に検証する方法およびツールを提供することを目的とする。
また本発明は、上記の目的に加えて、ＪＳＰページとその関連するコンポーネントとの間の不整合を自動的に検証することにより、ＪＳＰページの開発作業を支援し、ＪＳＰページの品質向上および開発コストの削減に寄与することを目的とする。
【００１０】
【課題を解決するための手段】
上記の目的を達成する本発明は、次のように構成されたウェブアプリケーション開発支援装置として実現される。このウェブアプリケーション開発支援装置は、動的にコンテンツが生成されるウェブページにおけるコンポーネント呼び出しの実行を監視し、このコンポーネント呼び出しに関する情報を抽出するモニタと、このモニタにより抽出されたコンポーネント呼び出しに関する情報に基づいて、このコンポーネント呼び出しとその対象であるコンポーネントとの整合性を検証する整合性検証部とを備えることを特徴とする。
【００１１】
ここで、さらに好ましくは、このモニタは、所定のコンポーネント呼び出しが実際に実行されるかどうかが実行時まで決まらない場合に、コンポーネント呼び出しの実行の有無に関わらずに、コンポーネント呼び出しに関する情報を抽出する。また、整合性検証部は、ウェブページごとに予め設定されたコンポーネント呼び出しに関する情報をまとめた仕様情報とモニタにて抽出された情報とを照合することにより、コンポーネント呼び出しとコンポーネントとの整合性を検証する。
【００１２】
さらに、このウェブアプリケーション開発支援装置は、整合性検証部による検証結果に基づいて仕様情報を更新する仕様更新部や、コンポーネント呼び出しの記述に用いられるライブラリに関する情報を解析してコンポーネント呼び出しに対応するモニタを生成するモニタ生成部を、さらに備える構成とすることができる。
【００１３】
また本発明は、次のように構成されたコンポーネント呼び出し監視装置としても実現することができる。すなわち、このコンポーネント呼び出し監視装置は、動的にコンテンツが生成されるウェブページに対するＨＴＴＰリクエストを発行するリクエスト制御部と、このウェブページにおけるコンテンツを生成するためのコンポーネント呼び出しの実行を監視し、このコンポーネント呼び出しに関する情報を抽出するモニタとを備えることを特徴とする。そしてさらに、このコンポーネント呼び出し監視装置は、コンポーネント呼び出しの記述に用いられるライブラリに関する情報を解析してコンポーネント呼び出しに対応するモニタを生成するモニタ生成部をさらに備える構成とすることができる。
【００１４】
ここで、さらに好ましくは、モニタ生成部は、ライブラリに関する情報の解析結果に基づき、所定の記憶手段に格納されているライブラリの定義ファイルを、コンポーネント呼び出しの実行に際して当該コンポーネント呼び出しに関する情報を抽出する機能を含んだライブラリ定義ファイルに置き換えることにより、モニタを自装置に実装させる。
【００１５】
また、上記の目的を達成する他の本発明は、コンピュータを用いた次のようなデータ処理方法として実現される。このデータ処理方法は、動的にコンテンツが生成されるウェブページにおける当該コンテンツを生成するためのコンポーネント呼び出しに関して、このコンポーネント呼び出しの記述に用いられるライブラリに関する情報を解析する第１のステップと、第１のステップによる解析結果に基づき、所定の記憶手段に格納されているライブラリの定義ファイルを、コンポーネント呼び出しの実行に際して当該コンポーネント呼び出しに関する情報を抽出する機能を含んだライブラリ定義ファイルに置き換える第２のステップと、第２のステップにより置き換えられたライブラリ定義ファイルを用いてコンポーネント呼び出しを実行し、実行されたコンポーネント呼び出しに関する情報を抽出する第３のステップとを含むことを特徴とする。
【００１６】
また、このデータ処理方法は、ウェブページごとに予め設定されて所定の記憶手段に格納されたコンポーネント呼び出しに関する情報をまとめた仕様情報と、第３のステップで抽出された情報とを照合することにより、コンポーネント呼び出しとその対象であるコンポーネントとの整合性を検証する第４のステップを含むことができる。さらに、第４のステップによる検証結果に基づいて、所定の記憶手段に格納されている仕様情報を更新する第５のステップを含むことも可能である。
【００１７】
さらにまた、本発明は、コンピュータを制御して上述したウェブアプリケーション開発支援装置やコンポーネント呼び出し監視装置として機能させるプログラム、あるいはコンピュータに上記データ処理方法の各ステップに対応する処理を実行させるプログラムとしても実現される。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより、提供することができる。
【００１８】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
本発明は、開発されたＪＳＰページの検証方法として、検証対象とするＪＳＰページをテスト実行させることによって正しく開発されているかどうかを動的に検証する方法を用いる。ＪＳＰ記述表現に関しては、ＪＳＰタグライブラリ記述による表現を検証の対象とする。ＪＳＰタグライブラリは、ＪＳＰページの記述にはタグベースの記述を行う。
【００１９】
本実施の形態では、開発対象のＪＳＰページに関して、検証のための仕様にあたるコンポーネント呼び出し情報を定義する。
図１は、本実施の形態で定義されるコンポーネント呼び出し情報の構成を示す図である。
図１（Ａ）に示すように、コンポーネント呼び出し情報は、呼び出す対象であるコンポーネントに関する、コンポーネント名、コンポーネント種別、コンポーネントの属性、スコープの各情報からなる。コンポーネント名は、ＪＳＰタグ記述の属性を用いてコンポーネント呼び出しを行う際の名前である。コンポーネント種別は、呼び出すコンポーネントの種類であり、ＪＳＰビーン、メッセージリソース、他のＪＳＰページなどである。コンポーネントの属性は、コンポーネントが入れ子の時など、コンポーネント呼び出しに属性が必要な時に用いられる情報である。スコープは、セッションスコープや、リクエストスコープなどを指定するときに用いる情報である。
【００２０】
本実施の形態では、ＪＳＰページにおけるＪＳＰタグ記述に対して、図１（Ａ）に示したようなコンポーネント呼び出し情報テーブルを生成して当該コンポーネント呼び出し情報を管理する。例えば、
＜ｂｅａｎ：ｍｅｓｓａｇｅ ｋｅｙ＝”ｔｉｔｌｅ．ｗｅｌｃｏｍｅ”／＞
というＪＳＰタグ記述に対しては、図１（Ｂ）のようなコンポーネント呼び出し情報テーブルが生成される。また、
＜ｂｅａｎ：ｗｒｉｔｅ ｎａｍｅ＝”ｕｓｅｒ” ｐｒｏｐｅｒｔｙ＝”ｕｓｅｒｎａｍｅ” ｓｃｏｐｅ＝”ｓｅｓｓｉｏｎ” ｆｉｌｔｅｒ＝”ｔｒｕｅ”／＞
というＪＳＰタグ記述に対しては、図１（Ｃ）のようなコンポーネント呼び出し情報テーブルが生成される。
【００２１】
ところで、１つのＪＳＰページにはＪＳＰタグ記述が複数存在し得る。したがって、上記のコンポーネント呼び出し情報は、ＪＳＰページ単位でまとめて管理される。ＪＳＰページごとのコンポーネント呼び出し情報テーブルの集合をＪＳＰページ仕様記述と呼ぶ。
図２は、ＪＳＰ仕様記述の例を示す図である。
図示のように、ＪＳＰページの各コンポーネント呼び出し情報に対しては、当該ＪＳＰページでの記述が必須かどうかを示す「必然性」の情報（必須であればｔｒｕｅ、必須でなければｆａｌｓｅ）を持つ。
【００２２】
本実施の形態は、上記のように定義されたコンポーネント呼び出し情報を用いて、ＪＳＰページの記述と呼び出し先のコンポーネントとの整合性を検証する。上述したＪＳＰ仕様記述は、本実施の形態による検証の実行前に、予め作成しておく。なお、コンポーネント呼び出し情報およびＪＳＰ仕様記述は、ＪＳＰページとその関連するコンポーネントとの間の整合性を検証するのに有効な情報を一定の様式で含んでいれば良く、必ずしも図１、２に示した構成に限定するものではない。
【００２３】
図３は、本実施の形態によるウェブアプリケーション開発支援装置を実現するコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図３に示すコンピュータ装置は、演算手段であるＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２及びＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２及びＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスを介してＭ／Ｂチップセット１０２に接続されたハードディスク１０５、ネットワークインターフェイス１０６と、さらにこのＰＣＩバスからブリッジ回路１０７及びＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１０８及びキーボード／マウス１０９とを備える。
なお、図３は本実施の形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、外部記憶装置として、ＡＴＡ（ＡＴ Ａｔｔａｃｈｍｅｎｔ）やＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）などのインターフェイスを介してＣＤ−Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅｃｏｒｄａｂｌｅ）やＤＶＤ−ＲＡＭ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のドライブを設けても良い。
【００２４】
図４は、本実施の形態によるウェブアプリケーション開発支援装置の機能構成を示す図である。
図４を参照すると、本実施の形態のウェブアプリケーション開発支援装置は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストを行ってＪＳＰページをテスト実行させるためのリクエスト制御部１０と、実行されたＪＳＰページによるコンポーネントの呼び出しを監視するモニタ２０と、モニタ２０による監視結果に基づいてＪＳＰページの記述と呼び出し先のコンポーネントとの整合性を検証する整合性検証部３０と、検証対象であるＪＳＰページのＪＳＰ仕様記述を格納したＪＳＰ仕様記述格納部４０と、モニタ２０を生成するモニタ生成部５０とを備える。
【００２５】
図４に示すリクエスト制御部１０、モニタ２０、整合性検証部３０及びモニタ生成部５０は、例えば図３のプログラム制御されたＣＰＵ１０１にて実現されるソフトウェアブロックである。ＣＰＵ１０１を制御してこれらの機能を実現するプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供することができる。また、ＪＳＰ仕様記述格納部４０は、例えば図３のメインメモリ１０３やハードディスク１０５にて実現される。本実施の形態では、検証対象であるＪＳＰページをテスト実行するためのＪＳＰ単体テスト用ウェブアプリケーションを用意し、リクエスト制御部１０からのＨＴＴＰリクエストに応じてＪＳＰページを実行する。そして図４に示すように、上記構成要素のうち、モニタ２０及び整合性検証部３０は、検証対象であるＪＳＰページをテスト実行するためのＪＳＰ単体テスト用ウェブアプリケーションの機能として実現される。
【００２６】
本実施の形態では、ＪＳＰタグライブラリ記述による表現を検証対象としている。ＪＳＰタグライブラリは、ライブラリとして公開されているものも存在するが、利用者によって自由に開発することも可能である。そのため、全てのＪＳＰタグライブラリへの呼び出しを抽出するためには、未対応のＪＳＰタグライブラリに対してコンポーネント呼び出しを監視することができるモニタ２０を生成することが必要である。本実施の形態では、モニタ生成部５０を用意して、ＪＳＰの検証に先立って、必要なモニタ２０を自動生成する。
【００２７】
図５は、モニタ生成部５０の機能を説明する図、図６、７は、モニタ生成部５０の動作を説明するフローチャートである。
図５を参照すると、モニタ生成部５０は、所定の記憶手段（例えば図３のメインメモリ１０３やハードディスク１０５）からタグライブラリ定義ファイル及びタグハンドラクラスのソースコードというＪＳＰタグライブラリ関連リソースを入力し、呼び出し対象であるコンポーネント及び入力パラメータの解析を行う。そして、モニタ２０を実装したタグライブラリ定義ファイル及び関連するコンポーネントを操作する入力パラメータの抽出機能を持ったタグハンドラクラスのソースコードというモニタ２０に関連したリソースを出力する。すなわち、ＪＳＰページにおけるコンポーネント呼び出しの記述に用いられているＪＳＰタグライブラリ関連リソースを、コンポーネント呼び出しの実行に際して当該コンポーネント呼び出しに関する情報を抽出するモニタ２０の機能を含んだＪＳＰタグライブラリ関連リソースに置き換える。
【００２８】
図６を参照して、コンポーネント呼び出しの種別判断と関連する属性とを求めるための、モニタ生成部５０によるタグライブラリの解析処理を説明する。
図６に示すように、モニタ生成部５０は、まずモニタ２０による監視を行おうとするタグライブラリを含めたウェブアプリケーションパスを指定する（ステップ６０１）。そして、指定されたウェブアプリケーションパスからＷＥＢ−ＩＮＦ／ｗｅｂ．ｘｍｌファイルを入力し（ステップ６０２）、全てのタグライブラリ定義ファイルのパスを読み込んでリストを作成する（ステップ６０３）。図８（Ａ）に、作成されるパスのリストの例を示す。
【００２９】
次に、モニタ生成部５０は、所定のタグライブラリ定義ファイルを入力し（ステップ６０４）、入力したタグライブラリ定義ファイル中の所定のタグハンドラ定義を読み込む（ステップ６０５）。読み取ったタグハンドラ定義の例を図８（Ｂ）に示す。
次に、モニタ生成部５０は、当該タグハンドラクラスのソースファイルを、ステップ６０４で入力したタグライブラリ定義ファイルから読み込む（ステップ６０６）。そして、コンポーネント呼び出しの種別判断と関連する属性の解析処理を行う（ステップ６０７）。この処理については図７を参照して後述する。
【００３０】
ステップ６０７の解析処理の後、モニタ生成部５０は、当該処理の結果に基づいて、モニタ機能を実装したタグハンドラクラスのソースファイルを生成する（ステップ６０８）。以上のステップ６０５〜６０８の処理は、ステップ６０４で入力されたタグライブラリ定義ファイルに含まれる全てのタグハンドラ定義に対して実行される（ループ２）。
【００３１】
次にモニタ生成部５０は、全てのタグハンドラ定義に対して上記の処理がなされたタグライブラリ定義ファイルに基づき、モニタ機能タグライブラリを呼び出すタグライブラリ定義ファイルを生成する（ステップ６０９）。以上のステップ６０４〜６０９の処理は、ステップ６０３で作成されたリストに含まれる全てのタグライブラリ定義ファイルに対して実行される（ループ１）。
【００３２】
次に図７を参照して、ステップ６０７におけるＪＳＰのタグハンドラクラスのソースコード解析について説明する。この解析処理では、タグライブラリ定義ファイルから取得した属性に基づき、どの属性がコンポーネント呼び出しに関連しているかを解析する。
モニタ生成部５０は、まず、解析対象のタグハンドラにおける全ての属性を取得する（ステップ７０１）。図８（Ｂ）に示した例では、属性｛ｆｉｌｔｅｒ， ｉｇｎｏｒｅ， ｎａｍｅ， ｐｒｏｐｅｒｔｙ， ｓｃｏｐｅ｝が取得される。
【００３３】
次に、モニタ生成部５０は、ステップ７０１で取得した全ての属性に対するローカル変数名を取得する（ステップ７０２）。このローカル変数名は、通常は属性名と同じである。ローカル変数名と属性名とが一致していない場合は、ｇｅｔｔｅｒメソッドから推測することができる。
次にモニタ生成部５０は、取得したローカル変数名に基づいて、ｐｕｂｌｉｃ ｉｎｔ ｄｏＳｔａｒｔＴａｇ（）メソッドを検索し（ステップ７０３）、さらにｐｕｂｌｉｃ ｉｎｔ ｄｏＥｎｄＴａｇ（）メソッドを検索する（ステップ７０４）。
【００３４】
ＪＳＰでは通常、ＰａｇｅＣｏｎｔｅｘｔオブジェクトのメソッドとして、ｇｅｔＡｔｔｒｉｂｕｔｅ（ｎａｍｅ、ｐａｇｅＣｏｎｔｅｘｔ．ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＣＯＰＥ）メソッド、ｐａｇｅＣｏｎｔｅｘｔ．ｆｉｎｄＡｔｔｒｉｂｕｔｅ（ｎａｍｅ）メソッドを呼び出すことによって、各種スコープに存在するコンポーネント操作が行われる。そこで、次にモニタ生成部５０は、これらのメソッド呼び出しを探索する。そして、これらのメソッド呼び出しが存在しない場合、当該タグハンドラクラスは、モニタ機能を実装したタグハンドラクラスの生成対象とせず、解析処理を終了する（ステップ７０５、７０９）。
【００３５】
一方、ｇｅｔＡｔｔｒｉｂｕｔｅ（ｎａｍｅ、ｐａｇｅＣｏｎｔｅｘｔ．ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＣＯＰＥ）メソッド、ｐａｇｅＣｏｎｔｅｘｔ．ｆｉｎｄＡｔｔｒｉｂｕｔｅ（ｎａｍｅ）メソッドのメソッド呼び出しがタグハンドラに存在する場合は、次にモニタ生成部５０は、データフロー解析におけるＵＳＥ―ＤＥＦチェーンアルゴリズムを用い、属性を表す変数の定義参照関係により、メソッドの引数であるｎａｍｅ変数部分にはタグハンドラのどの属性に当たる変数が引数に用いられているかを解析する（ステップ７０５、７０６）。所定の属性が導き出せれば、例えばＪＳＰタグ記述の当該属性の値を用いて、コンポーネントにアクセスする可能性が発見できる。
【００３６】
次に、モニタ生成部５０は、コンポーネント種別を判断する（ステップ７０７）。コンポーネント種別の判断は、上記のメソッドの返り値であるオブジェクトが、どの型を持っているかで判断される。返り値のオブジェクトの型とコンポーネント種別との対応は、コンポーネント種別判断テーブルで表される。
図９は、コンポーネント種別判断テーブルの構成例を示す図である。
図９に示すコンポーネント種別判断テーブルでは、ｇｅｔＡｔｔｒｉｂｕｔｅ（）／ｆｉｎｄＡｔｔｒｉｂｕｔｅ（）の返り値の型と、コンポーネント種別、属性変数の場所、及びＴｌｄファイルで定義された属性名とが対応付けられている。図示の例では、例えば、メソッドの返り値の型がメッセージリソースの型であった場合、コンポーネントは、メッセージコンポーネントと判断される。具体的な例を挙げると、次の記述の場合、コンポーネント種別はＪＳＰビーンと判断される。
Ｏｂｊｅｃｔ ｏｂｊｅｃｔ ＝ ｐａｇｅＣｏｎｔｅｘｔ．ｆｉｎｄＡｔｔｒｉｂｕｔｅ（ｎａｍｅ）；
また、次の記述の場合、コンポーネント種別はメッセージリソースと判断される。
ＭｅｓｓａｇｅＲｅｓｏｕｒｃｅｓ ｒｅｓｏｕｒｃｅ ＝
（ＭｅｓｓａｇｅＲｅｓｏｕｒｃｅｓ）ｐａｇｅＣｏｎｔｅｘｔ．ｇｅｔＡｔｔｒｉｂｕｔｅ（ｂｕｎｄｌｅ， ｐａｇｅＣｏｎｔｅｘｔ．ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＣＯＰＥ）；
Ｓｔｒｉｎｇ ｍｅｓｓａｇｅＶａｌｕｅ ＝ ｒｅｓｏｕｒｃｅ．ｇｅｔＭｅｓｓａｇｅ（ｋｅｙ）；
なお、コンポーネント種別判断テーブルにて示される、オブジェクトの型とコンポーネント種別との対応は、対象とするＪＳＰタグライブラリによって決まる。そこで、この対応関係は、解析処理の実行に先立って与えられる必要がある。
【００３７】
また、タグハンドラ中に、コンポーネント呼び出しが実際に行われるかが解析不能な分岐ロジックが存在している場合がある。この場合は、当該タグハンドラを実行してみなければコンポーネントが実際に呼ばれるかどうかは判断できない。そこで、コンポーネント呼び出し部分の直後にコンポーネント呼び出し情報を抽出させるロジックを追加しておく。これにより、タグハンドラの実行時に、呼ばれたコンポーネント呼び出し情報を伝えることができる。
図１０は、タグハンドラにおける分岐ロジックのコードにコンポーネント呼び出し情報のロジックを追加した例を示す図である。
【００３８】
以上の解析の後、モニタ生成部５０は、この解析で得られた属性名と、コンポーネント種別に基づいて、モニタ機能を実装したタグハンドラを生成する（ステップ７０８）。そして、上述したように、この解析結果であるタグハンドラからクラスのソースファイルが生成され、モニタ機能タグライブラリを呼び出すタグライブラリ定義ファイルが生成される（図６、ステップ６０８、６０９参照）。図１１は、モニタ機能を実装したタグハンドラクラスのソースコードの例を示す図、図１２は、モニタ機能タグライブラリを呼び出すタグライブラリ定義ファイルの例を示す図である。
【００３９】
図１３は、通常のタグハンドラ呼び出しとモニタ２０の呼び出しとの違いをタグライブラリ定義ファイルの関係で説明する図である。
図１３の例において、ＪＳＰページ中の宣言しているタグライブラリを呼び出すＵＲＬの
＜ｂｅａｎ：ｗｒｉｔｅ ｎａｍｅ＝”ｕｓｅｒｎａｍｅ” …／＞
という記述から、ｗｅｂ．ｘｍｌ（ウェブアプリケーション）中で記述しているＵＲＬとタグライブラリ定義ファイルとのマッピングを行うと、通常の呼び出しの場合は、タグリブの記述から
／ＷＥＢ−ＩＮＦ／ｓｔｒｕｔｓ−ｂｅａｎ．ｔｌｄ
によって「ｓｔｒｕｔｓ−ｂｅａｎ．ｔｌｄ」が呼ばれ、タグライブラリ定義ファイル中で記述されているタグハンドラ定義から、「ＷｒｉｔｅＴａｇ」が呼び出される。
これに対し、モニタ機能が実装された後では、ｗｅｂ．ｘｍｌ中で記述しているＵＲＬとタグライブラリ定義ファイルとのマッピングを行うと、タグリブの記述から
／ＷＥＢ−ＩＮＦ／ｍｏｎｉｔｏｒ．ｔｌｄ
によって「ｍｏｎｉｔｏｒ．ｔｌｄ」が呼ばれ、タグライブラリ定義ファイル中で記述されているタグハンドラ定義から、「ＭｏｎｉｔｏｒＷｒｉｔｅＴａｇ」が呼び出されることとなる。
以上のように、ＪＳＰページの記述は一切変更することなく、ウェブアプリケーションの動作環境（タグライブラリ定義ファイル及びｗｅｂ．ｘｍｌ）を変更することによって、モニタ２０の機能が呼ばれることとなる。
【００４０】
ところで、モニタ生成部５０は、モニタ２０を生成するために、タグハンドラから受け取った属性とコンポーネント呼び出しとを関連付けるが、上述した通常の解析ではコンポーネント呼び出し自体が確実に実行されるかどうかを保証できない場合がある。そのようなケースを以下にまとめる。
【００４１】
１．コンポーネント呼び出し種別の出現が、分岐ロジックによって決定されるとき。
タグハンドラクラスは、Ｊａｖａのロジックとして多様な条件で分岐ロジックを記述可能である。例えば、日付や時間によってコンポーネントを呼び出したり、ビジネスロジックを伴うオブジェクトの振る舞いによってコンポーネントを呼び出したりすることができる。また、Ｓｔｒｕｔｓというフレームワークのタグライブラリには、セッションスコープにコンポーネントが存在していなければ、メッセージリソースとしてコンポーネントを取り出すというロジックがある。このロジックでは、セッションスコープのコンポーネントを取る場合と、メッセージリソースからコンポーネントを取る場合とでは、取得されるコンポーネント種別が変わる。
このようなロジックの判断には、分岐ロジックを実施できるリソースがテスト環境によって個々に用意されているテストアプリケーション上で、動作させる必要がある。
【００４２】
２．ＰａｇｅＣｏｎｔｅｘｔオブジェクトに対する操作が検出できなかったタグハンドラが使用されるとき。
タグハンドラにおいて、属性値がＰａｇｅＣｏｎｔｅｘｔオブジェクトの操作に使用されていない場合や、ＰａｇｅＣｏｎｔｅｘｔオブジェクトの記述が解析できない場合がある。そのようなタグハンドラは、コンポーネント呼び出しを行わない場合が多いが、ネストしているタグハンドラのコンポーネント呼び出しに影響を受ける場合がある。例えば、Ｓｔｒｕｔｓのタグライブラリでは、ｌｏｇｉｃタグハンドラがあり、ｌｏｇｉｃを用いるＪＳＰタグ記述の属性の値によって、ネストしているタグハンドラの呼び出しを行わないことがある。
【００４３】
上記２つのケースでは、ＪＳＰ仕様記述のコンポーネント呼び出し情報に対する「必然性」がｔｒｕｅの場合であっても、当該ＪＳＰページの実行の際に必ず呼び出されるかは静的な解析で保障できるものではない。したがって、当該ＪＳＰページを動的に実行させてコンポーネント呼び出しを行わせる必要がある。
【００４４】
以上説明したモニタ生成部５０の機能により、図４に示したように、ＪＳＰ単体テスト用ウェブアプリケーションに、必要なモニタ２０が実装される。上述したように、モニタ生成部５０によるモニタ２０の生成は、ＪＳＰページの検証に先立って行われる。ＪＳＰページの検証自体は、リクエスト制御部１０、生成されたモニタ２０及び整合性検証部３０にて実行される。また、ＪＳＰページを検証するには、予め検証対象であるＪＳＰページに関して図２に示したＪＳＰ仕様記述を作成し、ＪＳＰ仕様記述格納部４０に格納しておく。
【００４５】
リクエスト制御部１０は、ＪＳＰページを実行するためのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）リストを取得し、ｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅ＝ｔｒｕｅというパラメータを付加して、ＪＳＰ単体テスト用ウェブアプリケーションに送信する。ＵＲＬリストは、テストしようとするＪＳＰページ群のＵＲＬを集めたものであり、ＪＳＰページ（ウェブアプリケーション）の開発者によって予め用意される。また、ＪＳＰページの集合を編集可能なツールを用いて検証対象のＪＳＰページ群を選択させてＵＲＬリストを自動生成することもできる。
【００４６】
図１４は、リクエスト制御部１０の動作を説明するフローチャートである。
図１４を参照すると、リクエスト制御部１０は、上記のようにして用意されたＵＲＬリストを読み込んで（ステップ１４０１）、当該ＵＲＬリスト中の所定のＵＲＬに対してＨＴＴＰリクエストを送信する（ステップ１４０２）。このとき、このＨＴＴＰリクエストには、ｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅ＝ｔｒｕｅというパラメータが付加される。このＨＴＴＰリクエストに対する応答であるＨＴＴＰレスポンスを受信すると、リクエスト制御部１０は、当該ＨＴＴＰレスポンスにおいてＪＳＰコンパイルエラーか否かを調べる（ステップ１４０３、１４０４）。ＪＳＰコンパイルエラーが発生しなかった場合は、当該ＵＲＬに対する処理が終了する。
【００４７】
一方、このＵＲＬリストを用いたＨＴＴＰリクエストの結果、ＪＳＰコンパイルエラーが発生し、ＨＴＴＰレスポンスとしてエラー結果が返ってきた場合、リクエスト制御部１０は、ｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅ＝ｆａｌｓｅというパラメータを付加して再度ＨＴＴＰリクエストを送信する（ステップ１４０５）。ＪＳＰコンパイルエラーは、ＪＳＰタグ記述とコンポーネントとの関連に不整合が発生している可能性が高い。そこで、再度の送信によって、コンポーネント呼び出しは実行せず呼び出し部分にダミーの結果を与えるダミー実行を、ＪＳＰ単体テスト用アプリケーションに行わせ、ＨＴＴＰレスポンスを受信する（ステップ１４０６）。ダミー実行については後述する。
以上のステップ１４０２〜１４０６は、ステップ１４０１で読み込まれたＵＲＬリストの全てのＵＲＬに対して実行される（ループ）。
【００４８】
ＪＳＰ単体テスト用ウェブアプリケーションには、開発者が開発したＪＳＰページとテストで実行可能なコンポーネントが用意されており、タグライブラリ定義ファイルとプログラムロジックによって、リクエスト制御部１０から発行されたＨＴＴＰリクエストに対応したＪＳＰページをＨＴＴＰサーブレット経由で呼び出すことができる。また、モニタ生成部５０によって生成されたモニタ２０と、ＪＳＰページとコンポーネントとの整合性の検証を行う整合性検証部３０とが実装されている。また、図１３に示したように、ＪＳＰページのＪＳＰタグ記述において、ＪＳＰタグハンドラ呼び出しがモニタ２０への呼び出しに置き換えられている。
【００４９】
モニタ２０は、ＪＳＰページのテスト実行に伴って呼び出され、当該ＪＳＰによるコンポーネント呼び出しを監視する。
図１５は、モニタ２０の動作を説明するフローチャートである。
図１５を参照すると、モニタ２０は、まずＨＴＴＰリクエストの対象であるＪＳＰページ中のコンポーネント呼び出し情報を抽出する（ステップ１５０１）。そして、整合性検証部３０を呼び出し、ステップ１５０１で抽出されたコンポーネント呼び出し情報を、ＨＴＴＰリクエスト名から取得できるＪＳＰページ名と共に、整合性検証部３０に渡す（ステップ１５０２）。
【００５０】
次に、モニタ２０は、リクエスト制御部１０からのＨＴＴＰリクエストにおけるパラメータｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅを参照し（ステップ１５０３）、その値がｔｒｕｅの時は、本来のＪＳＰタグ記述におけるＪＳＰタグハンドラ（モニタ２０への呼び出しに置き換えられる前のＪＳＰタグハンドラ）に対して、実際にコンポーネント呼び出しを実行させる（ステップ１５０４）。そして、当該コンポーネント呼び出しにおけるコンポーネント呼び出し情報を整合性検証部３０へ送る。また、コンポーネント呼び出しの結果を、後述のように、ＪＳＰページへ返す。
【００５１】
一方、パラメータｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅの値がｆａｌｓｅの時は、モニタ２０は、コンポーネント呼び出しを行わずにダミー実行を行い、ダミーの結果をコンポーネント呼び出しの結果としてＪＳＰページへ返す（ステップ１５０５）。この場合、ＪＳＰタグ記述部分における実際の処理結果としては、“ｄｕｍｍｙ”という文字列が返される。また、実際にタグハンドラを実行しなければ判断できない分岐処理がコンポーネント呼び出しに関わっている場合は、モニタ生成部５０にてコンポーネント呼び出し部分の直後に追加されたロジックにより、全てのコンポーネントに関して呼び出し情報のみが抽出され、整合性検証部３０へ送られる。
【００５２】
図１６は、コンポーネント呼び出しに対するモニタ２０の動作を説明する図である。この図の例では、コンポーネントＡ、Ｂが呼び出されるものとする。
図１６において、ＪＳＰページの実行に伴ってモニタ２０が実装されたクラス（以下、モニタ実装クラス）が呼び出されると、ｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅの値がｔｒｕｅの場合は、モニタ実装クラスからタグハンドラクラスへ親クラスのｄｏＳｔａｒｔ（）メソッド呼び出しが返される。そして、タグハンドラクラスの実行時におけるメソッド呼び出しの動作により、対応するコンポーネントＡ、Ｂが呼び出される。一方、ｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅの値がｆａｌｓｅの場合は、コンポーネントＡ、Ｂの呼び出しは行われず、コンポーネント呼び出し情報のみが抽出され、モニタ実装クラスからタグハンドラクラスへはメソッド呼び出しの代わりに“ｄｕｍｍｙ”という文字列が返される。
【００５３】
整合性検証部３０は、上述したモニタ２０によって得られたコンポーネント呼び出し情報に基づいて、当該コンポーネント呼び出しとコンポーネントとの整合性を検証する。
図１７は、整合性検証部３０の構成を示す図である。
図１７を参照すると、整合性検証部３０は、コンポーネント呼び出し情報を検証する呼び出し情報検証部３１と、ＪＳＰページにおけるコンポーネント呼び出しの検証結果を所定の記述形式で作成する結果記述作成部３２と、結果記述作成部３２にて作成された検証結果のログを出力する検証結果ログ出力部３３と、必要に応じてＪＳＰページ仕様記述を更新する仕様更新部３４とを備える。
【００５４】
呼び出し情報検証部３１は、モニタ２０により抽出されたコンポーネント呼び出し情報を入力し、ＪＳＰ仕様記述格納部４０に格納されている当該ＪＳＰページの仕様記述を参照し比較して、整合性を検証する。
図１８、１９は、呼び出し情報検証部３１による処理の流れを説明するフローチャートである。
図１８に示すように、呼び出し情報検証部３１は、テスト実行されたＪＳＰページからモニタ２０により抽出されたＪＳＰページ名とコンポーネント呼び出し情報とを取得すると（ステップ１８０１）、まず、ＪＳＰ仕様記述格納部４０を調べ、取得したＪＳＰ名に対応するＪＳＰ仕様記述が存在するかどうかを調べる（ステップ１８０２）。対応するＪＳＰ仕様記述が存在しない場合は、当該ＪＳＰページにおけるコンポーネント呼び出しとその呼び出し対象であるコンポーネントとが不整合であるため、呼び出し情報検証部３１は、不整合という検証結果を結果記述作成部３２に通知する（ステップ１８０３）。
【００５５】
取得したＪＳＰ名に対応するＪＳＰ仕様記述がＪＳＰ仕様記述格納部４０に格納されていた場合、呼び出し情報検証部３１は、次に、ＪＳＰ仕様記述格納部４０から、当該ＪＳＰ仕様記述に登録されているコンポーネント呼び出し情報のリスト（コンポーネント名）を取得する（図１９、ステップ１８０４）。そして、モニタ２０により抽出されたコンポーネント呼び出し情報のコンポーネント名が当該リスト中に存在するかどうかを調べる（ステップ１８０５）。同一のコンポーネント名が存在しない場合、当該ＪＳＰページにおけるコンポーネント呼び出しとその呼び出し対象であるコンポーネントとが不整合であるため、呼び出し情報検証部３１は、不整合という検証結果を結果記述作成部３２に通知する（ステップ１８０３）。
【００５６】
ＪＳＰ仕様記述のコンポーネント呼び出し情報に、モニタ２０により抽出されたコンポーネント呼び出し情報と同一のコンポーネント名のものが存在した場合、次に呼び出し情報検証部３１は、ＪＳＰ仕様記述格納部４０から、当該ＪＳＰ仕様記述における当該コンポーネント呼び出し情報を取得する（ステップ１８０６）。そして、取得したコンポーネント呼び出し情報とモニタ２０により抽出されたコンポーネント呼び出し情報とに関して、コンポーネント種別が同一かどうか（ステップ１８０７）、コンポーネントの属性が記述されている場合はその属性値が同一かどうか（ステップ１８０８、１８０９）、スコープの情報が記述されている場合はそのスコープが同一かどうか（ステップ１８１０、１８１１）を、それぞれ調べる。コンポーネント種別、属性値、スコープのいずれかが異なっている場合、当該ＪＳＰページにおけるコンポーネント呼び出しとその呼び出し対象であるコンポーネントとが不整合であるため、呼び出し情報検証部３１は、不整合という検証結果を結果記述作成部３２に通知する（ステップ１８０３）。
【００５７】
一方、コンポーネント種別、属性またはスコープ情報が記述されている場合の属性値またはスコープがいずれも同一である場合、呼び出し情報検証部３１は、当該コンポーネント呼び出しを後述する記述漏れ抽出用のリストに登録する（ステップ１８１２）。そして、整合という検証結果を結果記述作成部３２に通知する（ステップ１８１３）。
【００５８】
また、呼び出し情報検証部３１は、モニタ２０においてＪＳＰページ単位でコンポーネント呼び出し抽出が終了した際に、記述漏れのエラー項目をチェックする。
図２０は、呼び出し情報検証部３１による記述漏れのエラー項目の検出処理の流れを説明するフローチャートである。
図２０を参照すると、呼び出し情報検証部３１は、まず、ＪＳＰ仕様記述格納部４０からＪＳＰ仕様記述を読み込み、図１９のステップ１８１２で作成された記述漏れ抽出用リストを読み込む（ステップ２００１、２００２）。そして、検証対象である（すなわちリストに対応する）ＪＳＰページのＪＳＰ仕様記述における各コンポーネント呼び出し情報に順次着目し（ステップ２００３）、当該コンポーネント呼び出し情報に対応する検証結果が記述漏れ抽出用リストに存在するかどうかを調べる（ステップ２００４）。
【００５９】
このステップ２００３、２００４の処理を、検証対象であるＪＳＰページのＪＳＰ仕様記述における全てのコンポーネント呼び出し情報に対して行う（ループ）。そして、１つでも記述漏れ抽出用リストに存在しないコンポーネント呼び出し情報があったならば、その時点で、当該検証対象であるＪＳＰページに記述漏れのエラーがあったことを結果記述作成部３２に通知して処理を終了する（ステップ２００５）。
【００６０】
結果記述作成部３２は、呼び出し情報検証部３１の検証結果に基づいて呼び出し結果記述を作成する。呼び出し結果記述は、ＪＳＰページ単位で検証の結果得られたコンポーネント呼び出し情報をまとめたものであり、整合・不整合の別と不整合の理由（ＪＳＰページが存在しない、属性が不明など）、記述漏れ等の情報が含まれる。図２１は、呼び出し結果記述の例を示す図である。図２１に示す例では、呼び出し結果記述には、モニタ２０にて抽出されたコンポーネント呼び出し情報と、呼び出し情報検証部３１による検証結果とが記述されている。また、この検証結果に対する識別番号が付される。
【００６１】
検証結果ログ出力部３３は、結果記述作成部３２により作成された呼び出し結果記述に基づいて検証結果のログ情報を出力し、例えば所定のディスプレイ装置に当該ログ情報を表示して、ＪＳＰページ（ウェブアプリケーション）の開発者に通知する。図２２は、検証結果のログ情報の表示出力例を示す図である。図２２において、右端のチェックボックスは、後述する仕様更新処理において、どのＪＳＰページ（ＪＳＰファイル）を更新するかを指定するために用いられる。
【００６２】
開発者は、出力された検証結果を確認し、不整合箇所に関して、当該検証結果に基づいてＪＳＰページのＪＳＰタグ記述を修正することができる。さらに本実施の形態では、検証結果により得られた不整合箇所を正しいＪＳＰタグ記述としてＪＳＰページ仕様記述に反映させることができる。この場合、開発者は、不整合であるＪＳＰページの検証結果の識別番号と必然性の情報（ｔｒｕｅまたはｆａｌｓｅ）を指定して、仕様更新部３４にＪＳＰ仕様記述の更新をリクエストする。
【００６３】
仕様更新部３４は、上記の更新リクエストを受け付け、当該リクエストの対象であるＪＳＰページのＪＳＰ仕様記述を更新する。
図２３は、仕様更新部３４の動作を説明するフローチャートである。
図２３を参照すると、仕様更新部３４は、更新リクエストを受け付けると（ステップ２３０１）、当該更新リクエストに含まれる識別番号に基づいて、更新すべきコンポーネント呼び出し情報を特定する（ステップ２３０２）。そして、ＪＳＰ仕様記述格納部４０から対応するＪＳＰページのＪＳＰ仕様記述を読み出す（ステップ２３０３）。
【００６４】
次に、仕様更新部３４は、更新リクエストの内容に応じて、ＪＳＰ仕様記述における所望の項目の記述を削除もしくは追加する（ステップ２３０４、２３０５、２３０６）。そして、記述内容が変更されたＪＳＰ仕様記述をＪＳＰ仕様記述格納部４０に格納する（ステップ２３０７）。
以上のようにして、モニタ２０により抽出されたコンポーネント呼び出し情報の内容が、対応するＪＳＰページのＪＳＰ仕様記述に反映されることとなる。
【００６５】
次に、以上のように構成された本実施の形態のウェブアプリケーション開発支援装置によるＪＳＰページの検証処理を説明する。
図２４は、本実施の形態のウェブアプリケーション開発支援装置によるＪＳＰページの検証処理の全体的な流れを説明するフローチャートである。
図２４に示すように、まず、予め用意されたＵＲＬを用いて、リクエスト制御部１０によりＨＴＴＰリクエストが発行される（ステップ２４０１）。このＨＴＴＰリクエストは、ＪＳＰ単体テスト用ウェブアプリケーションにおいて、タグライブラリ定義ファイル及びプログラムロジックによって処理され、ＨＴＴＰリクエストに対応したＪＳＰページが呼び出される（ステップ２４０２）。そして、このＪＳＰページにより動的に生成されたコンテンツが、ＨＴＴＰレスポンスとしてリクエスト制御部１０に返される。
【００６６】
一方、ＪＳＰページが呼び出された際、モニタ２０により、当該ＪＳＰページのタグ記述に基づいて、タグハンドラにより実行されるコンポーネント呼び出しに関するコンポーネント呼び出し情報が抽出される（ステップ２４０３）。そして、抽出されたコンポーネント呼び出し情報が、整合性検証部３０により、予め設定されてＪＳＰ仕様記述格納部４０に格納されているＪＳＰ仕様記述と照合されることにより、当該コンポーネント呼び出しとその対象であるコンポーネントとの整合性が検証される（ステップ２４０４）。
【００６７】
ＪＳＰページ（ウェブアプリケーション）の開発者は、この検証結果を参照し、対応措置として、検証対象であったＪＳＰページの不整合箇所を修正するか、ＪＳＰ仕様記述の方を更新するかを選択できる。ＪＳＰ仕様記述を更新する場合は、更新リクエストの入力を条件として、整合性検証部３０の仕様更新部３４により、ＪＳＰ仕様記述の記述内容がモニタ２０にて抽出されたコンポーネント呼び出し情報の内容に更新される（ステップ２４０５、２４０６）。
【００６８】
【発明の効果】
以上説明したように、本発明によれば、ＪＳＰページとその関連するコンポーネントとの間の整合・不整合を解析し、自動的に検証することが可能となる。
また本発明によれば、ＪＳＰページとその関連するコンポーネントとの間の整合・不整合の検証を行うことにより、ＪＳＰページの開発作業を支援し、ＪＳＰページの品質向上および開発コストの削減に寄与することができる。
【図面の簡単な説明】
【図１】本実施の形態で定義されるコンポーネント呼び出し情報の構成を示す図である。
【図２】本実施の形態で用いられるＪＳＰ仕様記述の例を示す図である。
【図３】本実施の形態によるウェブアプリケーション開発支援装置を実現するコンピュータ装置のハードウェア構成の例を模式的に示した図である。
【図４】本実施の形態によるウェブアプリケーション開発支援装置の機能構成を示す図である。
【図５】本実施の形態におけるモニタ生成部の機能を説明する図である。
【図６】本実施の形態におけるモニタ生成部の動作を説明するフローチャートである。
【図７】本実施の形態におけるモニタ生成部の動作を説明するフローチャートであり、コンポーネント呼び出しの種別判断と関連する属性とを求めるためのタグライブラリの解析処理を説明するフローチャートである。
【図８】図７の処理において用いられる情報を示す図であり、図８（Ａ）はタグライブラリ定義ファイルのパスのリストを示す図、図８（Ｂ）はタグハンドラの定義を示す図である。
【図９】本実施の形態で用いられるコンポーネント種別判断テーブルの構成例を示す図である。
【図１０】タグハンドラにおける分岐ロジックのコードにコンポーネント呼び出し情報のロジックを追加した例を示す図である。
【図１１】モニタ機能を実装したタグハンドラクラスのソースコードの例を示す図である。
【図１２】モニタ機能タグライブラリを呼び出すタグライブラリ定義ファイルの例を示す図である。
【図１３】通常のタグハンドラ呼び出しとモニタの呼び出しとの違いをタグライブラリ定義ファイルの関係で説明する図である。
【図１４】本実施の形態におけるリクエスト制御部の動作を説明するフローチャートである。
【図１５】本実施の形態におけるモニタの動作を説明するフローチャートである。
【図１６】コンポーネント呼び出しに対するモニタの動作を説明する図である。
【図１７】本実施の形態における整合性検証部の構成を示す図である。
【図１８】本実施の形態における呼び出し情報検証部による処理の流れを説明するフローチャートである。
【図１９】本実施の形態における呼び出し情報検証部による処理の流れを説明するフローチャートである。
【図２０】本実施の形態における呼び出し情報検証部による記述漏れのエラー項目の検出処理の流れを説明するフローチャートである。
【図２１】呼び出し情報検証部の結果記述作成部により生成される呼び出し結果記述の例を示す図である。
【図２２】呼び出し情報検証部の検証結果ログ出力部による検証結果のログ情報の表示出力例を示す図である。
【図２３】本実施の形態における仕様更新部の動作を説明するフローチャートである。
【図２４】本実施の形態のウェブアプリケーション開発支援装置によるＪＳＰページの検証処理の全体的な流れを説明するフローチャートである。
【図２５】ＪＳＰページに関連する主要なコンポーネント群を示す図である。
【符号の説明】
１０…リクエスト制御部、２０…モニタ、３０…整合性検証部、３１…呼び出し情報検証部、３２…結果記述作成部、３３…検証結果ログ出力部、３４…仕様更新部、４０…ＪＳＰ仕様記述格納部、５０…モニタ生成部、１０１…ＣＰＵ、１０３…メインメモリ、１０５…ハードディスク
【発明の属する技術分野】
本発明は、ウェブアプリケーション等に用いられるＪＳＰのコンポーネント呼び出しとコンポーネントとの整合性を検証する方法及びシステムに関する。
【０００２】
【従来の技術】
インターネット等のネットワークを介してサービスを提供するウェブアプリケーションで用いられる技術に、ウェブサーバにおいてスクリプト言語（サーバサイドスクリプト言語）を用いて動的にウェブページを生成し、クライアントに送信する技術がある。ＪＳＰ（ＪａｖａＳｅｒｖｅｒ Ｐａｇｅｓ：米国サン・マイクロシステムズ社の商標）は、この種のサーバサイドスクリプト言語のひとつであり、Ｊａｖａ（米国サン・マイクロシステムズ社の商標）言語を利用してこの機能を実現する（例えば、特許文献１、非特許文献１参照）。具体的には、ＪＳＰでは、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルの中にスクリプト（Ｊａｖａプログラム）で処理を記述しておき、クライアントの要求に応じてスクリプトを実行し、処理結果のみをクライアントに送信する。
【０００３】
したがって、ＪＳＰによる動的なコンテンツを含むウェブページ（以下、ＪＳＰページ）のファイルには、当該動的コンテンツを表現する言語に関して、ＪＳＰによる記述部分やＨＴＭＬによる記述部分など、多くの言語が同時に存在している。ＨＴＭＬの記述は、ウェブページをブラウザに表示した際のレイアウトや制御を実現する。一方、ＪＳＰの記述は、所定の処理を記述したスクリプトであり、実行時にサーブレットとして動作する。そして、当該スクリプトの設計に沿ってアクセス可能な他のコンポーネントに対して必要な操作を行い、この操作の結果をレスポンスとしてブラウザに送信する。
【０００４】
ここで、コンポーネントとは、オブジェクトを意味しており、ＪＳＰに関連するコンポーネントとは、Ｊａｖａビーンやメッセージリソース、ＪＳＰページが依存する他のＪＳＰページやウェブページなどを指す。
図２５は、ＪＳＰページに関連する主要なコンポーネント群を示す図である。
【０００５】
【特許文献１】
特開２００２？３６６５１４号公報
【非特許文献１】
“ＪａｖａＳｅｒｖｅｒ ＰａｇｅｓＴＭ ＤＹＮＡＭＩＣＡＬＬＹ ＧＥＮＥＲＡＴＥＤ ＷＥＢ ＣＯＮＴＥＮＴ”、［ｏｎｌｉｎｅ］、［平成１５年５月２１日検索］、インターネット＜ＵＲＬ： ＨＹＰＥＲＬＩＮＫ ”ｈｔｔｐ：／／ｗｗｗ．ｃｓ．ｈｕｔ．ｆｉ／￣ｃｔｌ／３ｄｍ／” ｈｔｔｐ：／／ｊａｖａ．ｓｕｎ．ｃｏｍ／ｊ２ｅｅ／ｊａ／ｊｓｐ／＞
【０００６】
【発明が解決しようとする課題】
上記のように、ウェブアプリケーション等に用いられるＪＳＰは、実行時、所定のコンポーネントに対してアクセスして必要な操作を行う。しかし、実際のウェブアプリケーション開発における結合テストや稼動テストでは、ＪＳＰの記述内容に関する仕様が開発前に予め定められていないために、ＪＳＰページのコンポーネント呼び出し部分と他の開発者によって開発されたコンポーネントとの間で不整合が発生する場合が多い。
そこで従来、ウェブアプリケーション開発時には、開発者の手作業によってＪＳＰページの記述の整合性を確認したり、実際にアプリケーションサーバー上での結合テストを行って不整合を１つ１つ検出したりすることが行われている。
【０００７】
しかし、ウェブアプリケーション内に膨大な数のコンポーネント呼び出し記述が存在する場合、ＪＳＰページのコンポーネント呼び出しとコンポーネントとの間の不整合を完全に検出することは容易ではない。
かかる不整合を完全に除去できないと、ウェブアプリケーション稼動後にも、当該ウェブアプリケーション内に潜在していた不整合のために、システムに障害が発生することも起こりうる。そして、障害が発生すれば、開発全体では余分なコストが発生することになる。
【０００８】
また、Ｊａｖａスクリプトレットのプログラムロジックや、ＪＳＰタグライブラリのように利用者が自由に作成したタグ記述表現を許していることが、ＪＳＰページとコンポーネント間の整合性を解析し自動的に検証することを困難にしていた。
【０００９】
そこで本発明は、上記の問題に鑑み、ＪＳＰページとその関連するコンポーネントとの間の整合・不整合を解析し、自動的に検証する方法およびツールを提供することを目的とする。
また本発明は、上記の目的に加えて、ＪＳＰページとその関連するコンポーネントとの間の不整合を自動的に検証することにより、ＪＳＰページの開発作業を支援し、ＪＳＰページの品質向上および開発コストの削減に寄与することを目的とする。
【００１０】
【課題を解決するための手段】
上記の目的を達成する本発明は、次のように構成されたウェブアプリケーション開発支援装置として実現される。このウェブアプリケーション開発支援装置は、動的にコンテンツが生成されるウェブページにおけるコンポーネント呼び出しの実行を監視し、このコンポーネント呼び出しに関する情報を抽出するモニタと、このモニタにより抽出されたコンポーネント呼び出しに関する情報に基づいて、このコンポーネント呼び出しとその対象であるコンポーネントとの整合性を検証する整合性検証部とを備えることを特徴とする。
【００１１】
ここで、さらに好ましくは、このモニタは、所定のコンポーネント呼び出しが実際に実行されるかどうかが実行時まで決まらない場合に、コンポーネント呼び出しの実行の有無に関わらずに、コンポーネント呼び出しに関する情報を抽出する。また、整合性検証部は、ウェブページごとに予め設定されたコンポーネント呼び出しに関する情報をまとめた仕様情報とモニタにて抽出された情報とを照合することにより、コンポーネント呼び出しとコンポーネントとの整合性を検証する。
【００１２】
さらに、このウェブアプリケーション開発支援装置は、整合性検証部による検証結果に基づいて仕様情報を更新する仕様更新部や、コンポーネント呼び出しの記述に用いられるライブラリに関する情報を解析してコンポーネント呼び出しに対応するモニタを生成するモニタ生成部を、さらに備える構成とすることができる。
【００１３】
また本発明は、次のように構成されたコンポーネント呼び出し監視装置としても実現することができる。すなわち、このコンポーネント呼び出し監視装置は、動的にコンテンツが生成されるウェブページに対するＨＴＴＰリクエストを発行するリクエスト制御部と、このウェブページにおけるコンテンツを生成するためのコンポーネント呼び出しの実行を監視し、このコンポーネント呼び出しに関する情報を抽出するモニタとを備えることを特徴とする。そしてさらに、このコンポーネント呼び出し監視装置は、コンポーネント呼び出しの記述に用いられるライブラリに関する情報を解析してコンポーネント呼び出しに対応するモニタを生成するモニタ生成部をさらに備える構成とすることができる。
【００１４】
ここで、さらに好ましくは、モニタ生成部は、ライブラリに関する情報の解析結果に基づき、所定の記憶手段に格納されているライブラリの定義ファイルを、コンポーネント呼び出しの実行に際して当該コンポーネント呼び出しに関する情報を抽出する機能を含んだライブラリ定義ファイルに置き換えることにより、モニタを自装置に実装させる。
【００１５】
また、上記の目的を達成する他の本発明は、コンピュータを用いた次のようなデータ処理方法として実現される。このデータ処理方法は、動的にコンテンツが生成されるウェブページにおける当該コンテンツを生成するためのコンポーネント呼び出しに関して、このコンポーネント呼び出しの記述に用いられるライブラリに関する情報を解析する第１のステップと、第１のステップによる解析結果に基づき、所定の記憶手段に格納されているライブラリの定義ファイルを、コンポーネント呼び出しの実行に際して当該コンポーネント呼び出しに関する情報を抽出する機能を含んだライブラリ定義ファイルに置き換える第２のステップと、第２のステップにより置き換えられたライブラリ定義ファイルを用いてコンポーネント呼び出しを実行し、実行されたコンポーネント呼び出しに関する情報を抽出する第３のステップとを含むことを特徴とする。
【００１６】
また、このデータ処理方法は、ウェブページごとに予め設定されて所定の記憶手段に格納されたコンポーネント呼び出しに関する情報をまとめた仕様情報と、第３のステップで抽出された情報とを照合することにより、コンポーネント呼び出しとその対象であるコンポーネントとの整合性を検証する第４のステップを含むことができる。さらに、第４のステップによる検証結果に基づいて、所定の記憶手段に格納されている仕様情報を更新する第５のステップを含むことも可能である。
【００１７】
さらにまた、本発明は、コンピュータを制御して上述したウェブアプリケーション開発支援装置やコンポーネント呼び出し監視装置として機能させるプログラム、あるいはコンピュータに上記データ処理方法の各ステップに対応する処理を実行させるプログラムとしても実現される。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより、提供することができる。
【００１８】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
本発明は、開発されたＪＳＰページの検証方法として、検証対象とするＪＳＰページをテスト実行させることによって正しく開発されているかどうかを動的に検証する方法を用いる。ＪＳＰ記述表現に関しては、ＪＳＰタグライブラリ記述による表現を検証の対象とする。ＪＳＰタグライブラリは、ＪＳＰページの記述にはタグベースの記述を行う。
【００１９】
本実施の形態では、開発対象のＪＳＰページに関して、検証のための仕様にあたるコンポーネント呼び出し情報を定義する。
図１は、本実施の形態で定義されるコンポーネント呼び出し情報の構成を示す図である。
図１（Ａ）に示すように、コンポーネント呼び出し情報は、呼び出す対象であるコンポーネントに関する、コンポーネント名、コンポーネント種別、コンポーネントの属性、スコープの各情報からなる。コンポーネント名は、ＪＳＰタグ記述の属性を用いてコンポーネント呼び出しを行う際の名前である。コンポーネント種別は、呼び出すコンポーネントの種類であり、ＪＳＰビーン、メッセージリソース、他のＪＳＰページなどである。コンポーネントの属性は、コンポーネントが入れ子の時など、コンポーネント呼び出しに属性が必要な時に用いられる情報である。スコープは、セッションスコープや、リクエストスコープなどを指定するときに用いる情報である。
【００２０】
本実施の形態では、ＪＳＰページにおけるＪＳＰタグ記述に対して、図１（Ａ）に示したようなコンポーネント呼び出し情報テーブルを生成して当該コンポーネント呼び出し情報を管理する。例えば、
＜ｂｅａｎ：ｍｅｓｓａｇｅ ｋｅｙ＝”ｔｉｔｌｅ．ｗｅｌｃｏｍｅ”／＞
というＪＳＰタグ記述に対しては、図１（Ｂ）のようなコンポーネント呼び出し情報テーブルが生成される。また、
＜ｂｅａｎ：ｗｒｉｔｅ ｎａｍｅ＝”ｕｓｅｒ” ｐｒｏｐｅｒｔｙ＝”ｕｓｅｒｎａｍｅ” ｓｃｏｐｅ＝”ｓｅｓｓｉｏｎ” ｆｉｌｔｅｒ＝”ｔｒｕｅ”／＞
というＪＳＰタグ記述に対しては、図１（Ｃ）のようなコンポーネント呼び出し情報テーブルが生成される。
【００２１】
ところで、１つのＪＳＰページにはＪＳＰタグ記述が複数存在し得る。したがって、上記のコンポーネント呼び出し情報は、ＪＳＰページ単位でまとめて管理される。ＪＳＰページごとのコンポーネント呼び出し情報テーブルの集合をＪＳＰページ仕様記述と呼ぶ。
図２は、ＪＳＰ仕様記述の例を示す図である。
図示のように、ＪＳＰページの各コンポーネント呼び出し情報に対しては、当該ＪＳＰページでの記述が必須かどうかを示す「必然性」の情報（必須であればｔｒｕｅ、必須でなければｆａｌｓｅ）を持つ。
【００２２】
本実施の形態は、上記のように定義されたコンポーネント呼び出し情報を用いて、ＪＳＰページの記述と呼び出し先のコンポーネントとの整合性を検証する。上述したＪＳＰ仕様記述は、本実施の形態による検証の実行前に、予め作成しておく。なお、コンポーネント呼び出し情報およびＪＳＰ仕様記述は、ＪＳＰページとその関連するコンポーネントとの間の整合性を検証するのに有効な情報を一定の様式で含んでいれば良く、必ずしも図１、２に示した構成に限定するものではない。
【００２３】
図３は、本実施の形態によるウェブアプリケーション開発支援装置を実現するコンピュータ装置のハードウェア構成の例を模式的に示した図である。
図３に示すコンピュータ装置は、演算手段であるＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：中央処理装置）１０１と、Ｍ／Ｂ（マザーボード）チップセット１０２及びＣＰＵバスを介してＣＰＵ１０１に接続されたメインメモリ１０３と、同じくＭ／Ｂチップセット１０２及びＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）を介してＣＰＵ１０１に接続されたビデオカード１０４と、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスを介してＭ／Ｂチップセット１０２に接続されたハードディスク１０５、ネットワークインターフェイス１０６と、さらにこのＰＣＩバスからブリッジ回路１０７及びＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バスなどの低速なバスを介してＭ／Ｂチップセット１０２に接続されたフロッピーディスクドライブ１０８及びキーボード／マウス１０９とを備える。
なお、図３は本実施の形態を実現するコンピュータ装置のハードウェア構成を例示するに過ぎず、本実施の形態を適用可能であれば、他の種々の構成を取ることができる。例えば、ビデオカード１０４を設ける代わりに、ビデオメモリのみを搭載し、ＣＰＵ１０１にてイメージデータを処理する構成としても良いし、外部記憶装置として、ＡＴＡ（ＡＴ Ａｔｔａｃｈｍｅｎｔ）やＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）などのインターフェイスを介してＣＤ−Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅｃｏｒｄａｂｌｅ）やＤＶＤ−ＲＡＭ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）のドライブを設けても良い。
【００２４】
図４は、本実施の形態によるウェブアプリケーション開発支援装置の機能構成を示す図である。
図４を参照すると、本実施の形態のウェブアプリケーション開発支援装置は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）リクエストを行ってＪＳＰページをテスト実行させるためのリクエスト制御部１０と、実行されたＪＳＰページによるコンポーネントの呼び出しを監視するモニタ２０と、モニタ２０による監視結果に基づいてＪＳＰページの記述と呼び出し先のコンポーネントとの整合性を検証する整合性検証部３０と、検証対象であるＪＳＰページのＪＳＰ仕様記述を格納したＪＳＰ仕様記述格納部４０と、モニタ２０を生成するモニタ生成部５０とを備える。
【００２５】
図４に示すリクエスト制御部１０、モニタ２０、整合性検証部３０及びモニタ生成部５０は、例えば図３のプログラム制御されたＣＰＵ１０１にて実現されるソフトウェアブロックである。ＣＰＵ１０１を制御してこれらの機能を実現するプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供することができる。また、ＪＳＰ仕様記述格納部４０は、例えば図３のメインメモリ１０３やハードディスク１０５にて実現される。本実施の形態では、検証対象であるＪＳＰページをテスト実行するためのＪＳＰ単体テスト用ウェブアプリケーションを用意し、リクエスト制御部１０からのＨＴＴＰリクエストに応じてＪＳＰページを実行する。そして図４に示すように、上記構成要素のうち、モニタ２０及び整合性検証部３０は、検証対象であるＪＳＰページをテスト実行するためのＪＳＰ単体テスト用ウェブアプリケーションの機能として実現される。
【００２６】
本実施の形態では、ＪＳＰタグライブラリ記述による表現を検証対象としている。ＪＳＰタグライブラリは、ライブラリとして公開されているものも存在するが、利用者によって自由に開発することも可能である。そのため、全てのＪＳＰタグライブラリへの呼び出しを抽出するためには、未対応のＪＳＰタグライブラリに対してコンポーネント呼び出しを監視することができるモニタ２０を生成することが必要である。本実施の形態では、モニタ生成部５０を用意して、ＪＳＰの検証に先立って、必要なモニタ２０を自動生成する。
【００２７】
図５は、モニタ生成部５０の機能を説明する図、図６、７は、モニタ生成部５０の動作を説明するフローチャートである。
図５を参照すると、モニタ生成部５０は、所定の記憶手段（例えば図３のメインメモリ１０３やハードディスク１０５）からタグライブラリ定義ファイル及びタグハンドラクラスのソースコードというＪＳＰタグライブラリ関連リソースを入力し、呼び出し対象であるコンポーネント及び入力パラメータの解析を行う。そして、モニタ２０を実装したタグライブラリ定義ファイル及び関連するコンポーネントを操作する入力パラメータの抽出機能を持ったタグハンドラクラスのソースコードというモニタ２０に関連したリソースを出力する。すなわち、ＪＳＰページにおけるコンポーネント呼び出しの記述に用いられているＪＳＰタグライブラリ関連リソースを、コンポーネント呼び出しの実行に際して当該コンポーネント呼び出しに関する情報を抽出するモニタ２０の機能を含んだＪＳＰタグライブラリ関連リソースに置き換える。
【００２８】
図６を参照して、コンポーネント呼び出しの種別判断と関連する属性とを求めるための、モニタ生成部５０によるタグライブラリの解析処理を説明する。
図６に示すように、モニタ生成部５０は、まずモニタ２０による監視を行おうとするタグライブラリを含めたウェブアプリケーションパスを指定する（ステップ６０１）。そして、指定されたウェブアプリケーションパスからＷＥＢ−ＩＮＦ／ｗｅｂ．ｘｍｌファイルを入力し（ステップ６０２）、全てのタグライブラリ定義ファイルのパスを読み込んでリストを作成する（ステップ６０３）。図８（Ａ）に、作成されるパスのリストの例を示す。
【００２９】
次に、モニタ生成部５０は、所定のタグライブラリ定義ファイルを入力し（ステップ６０４）、入力したタグライブラリ定義ファイル中の所定のタグハンドラ定義を読み込む（ステップ６０５）。読み取ったタグハンドラ定義の例を図８（Ｂ）に示す。
次に、モニタ生成部５０は、当該タグハンドラクラスのソースファイルを、ステップ６０４で入力したタグライブラリ定義ファイルから読み込む（ステップ６０６）。そして、コンポーネント呼び出しの種別判断と関連する属性の解析処理を行う（ステップ６０７）。この処理については図７を参照して後述する。
【００３０】
ステップ６０７の解析処理の後、モニタ生成部５０は、当該処理の結果に基づいて、モニタ機能を実装したタグハンドラクラスのソースファイルを生成する（ステップ６０８）。以上のステップ６０５〜６０８の処理は、ステップ６０４で入力されたタグライブラリ定義ファイルに含まれる全てのタグハンドラ定義に対して実行される（ループ２）。
【００３１】
次にモニタ生成部５０は、全てのタグハンドラ定義に対して上記の処理がなされたタグライブラリ定義ファイルに基づき、モニタ機能タグライブラリを呼び出すタグライブラリ定義ファイルを生成する（ステップ６０９）。以上のステップ６０４〜６０９の処理は、ステップ６０３で作成されたリストに含まれる全てのタグライブラリ定義ファイルに対して実行される（ループ１）。
【００３２】
次に図７を参照して、ステップ６０７におけるＪＳＰのタグハンドラクラスのソースコード解析について説明する。この解析処理では、タグライブラリ定義ファイルから取得した属性に基づき、どの属性がコンポーネント呼び出しに関連しているかを解析する。
モニタ生成部５０は、まず、解析対象のタグハンドラにおける全ての属性を取得する（ステップ７０１）。図８（Ｂ）に示した例では、属性｛ｆｉｌｔｅｒ， ｉｇｎｏｒｅ， ｎａｍｅ， ｐｒｏｐｅｒｔｙ， ｓｃｏｐｅ｝が取得される。
【００３３】
次に、モニタ生成部５０は、ステップ７０１で取得した全ての属性に対するローカル変数名を取得する（ステップ７０２）。このローカル変数名は、通常は属性名と同じである。ローカル変数名と属性名とが一致していない場合は、ｇｅｔｔｅｒメソッドから推測することができる。
次にモニタ生成部５０は、取得したローカル変数名に基づいて、ｐｕｂｌｉｃ ｉｎｔ ｄｏＳｔａｒｔＴａｇ（）メソッドを検索し（ステップ７０３）、さらにｐｕｂｌｉｃ ｉｎｔ ｄｏＥｎｄＴａｇ（）メソッドを検索する（ステップ７０４）。
【００３４】
ＪＳＰでは通常、ＰａｇｅＣｏｎｔｅｘｔオブジェクトのメソッドとして、ｇｅｔＡｔｔｒｉｂｕｔｅ（ｎａｍｅ、ｐａｇｅＣｏｎｔｅｘｔ．ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＣＯＰＥ）メソッド、ｐａｇｅＣｏｎｔｅｘｔ．ｆｉｎｄＡｔｔｒｉｂｕｔｅ（ｎａｍｅ）メソッドを呼び出すことによって、各種スコープに存在するコンポーネント操作が行われる。そこで、次にモニタ生成部５０は、これらのメソッド呼び出しを探索する。そして、これらのメソッド呼び出しが存在しない場合、当該タグハンドラクラスは、モニタ機能を実装したタグハンドラクラスの生成対象とせず、解析処理を終了する（ステップ７０５、７０９）。
【００３５】
一方、ｇｅｔＡｔｔｒｉｂｕｔｅ（ｎａｍｅ、ｐａｇｅＣｏｎｔｅｘｔ．ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＣＯＰＥ）メソッド、ｐａｇｅＣｏｎｔｅｘｔ．ｆｉｎｄＡｔｔｒｉｂｕｔｅ（ｎａｍｅ）メソッドのメソッド呼び出しがタグハンドラに存在する場合は、次にモニタ生成部５０は、データフロー解析におけるＵＳＥ―ＤＥＦチェーンアルゴリズムを用い、属性を表す変数の定義参照関係により、メソッドの引数であるｎａｍｅ変数部分にはタグハンドラのどの属性に当たる変数が引数に用いられているかを解析する（ステップ７０５、７０６）。所定の属性が導き出せれば、例えばＪＳＰタグ記述の当該属性の値を用いて、コンポーネントにアクセスする可能性が発見できる。
【００３６】
次に、モニタ生成部５０は、コンポーネント種別を判断する（ステップ７０７）。コンポーネント種別の判断は、上記のメソッドの返り値であるオブジェクトが、どの型を持っているかで判断される。返り値のオブジェクトの型とコンポーネント種別との対応は、コンポーネント種別判断テーブルで表される。
図９は、コンポーネント種別判断テーブルの構成例を示す図である。
図９に示すコンポーネント種別判断テーブルでは、ｇｅｔＡｔｔｒｉｂｕｔｅ（）／ｆｉｎｄＡｔｔｒｉｂｕｔｅ（）の返り値の型と、コンポーネント種別、属性変数の場所、及びＴｌｄファイルで定義された属性名とが対応付けられている。図示の例では、例えば、メソッドの返り値の型がメッセージリソースの型であった場合、コンポーネントは、メッセージコンポーネントと判断される。具体的な例を挙げると、次の記述の場合、コンポーネント種別はＪＳＰビーンと判断される。
Ｏｂｊｅｃｔ ｏｂｊｅｃｔ ＝ ｐａｇｅＣｏｎｔｅｘｔ．ｆｉｎｄＡｔｔｒｉｂｕｔｅ（ｎａｍｅ）；
また、次の記述の場合、コンポーネント種別はメッセージリソースと判断される。
ＭｅｓｓａｇｅＲｅｓｏｕｒｃｅｓ ｒｅｓｏｕｒｃｅ ＝
（ＭｅｓｓａｇｅＲｅｓｏｕｒｃｅｓ）ｐａｇｅＣｏｎｔｅｘｔ．ｇｅｔＡｔｔｒｉｂｕｔｅ（ｂｕｎｄｌｅ， ｐａｇｅＣｏｎｔｅｘｔ．ＡＰＰＬＩＣＡＴＩＯＮ＿ＳＣＯＰＥ）；
Ｓｔｒｉｎｇ ｍｅｓｓａｇｅＶａｌｕｅ ＝ ｒｅｓｏｕｒｃｅ．ｇｅｔＭｅｓｓａｇｅ（ｋｅｙ）；
なお、コンポーネント種別判断テーブルにて示される、オブジェクトの型とコンポーネント種別との対応は、対象とするＪＳＰタグライブラリによって決まる。そこで、この対応関係は、解析処理の実行に先立って与えられる必要がある。
【００３７】
また、タグハンドラ中に、コンポーネント呼び出しが実際に行われるかが解析不能な分岐ロジックが存在している場合がある。この場合は、当該タグハンドラを実行してみなければコンポーネントが実際に呼ばれるかどうかは判断できない。そこで、コンポーネント呼び出し部分の直後にコンポーネント呼び出し情報を抽出させるロジックを追加しておく。これにより、タグハンドラの実行時に、呼ばれたコンポーネント呼び出し情報を伝えることができる。
図１０は、タグハンドラにおける分岐ロジックのコードにコンポーネント呼び出し情報のロジックを追加した例を示す図である。
【００３８】
以上の解析の後、モニタ生成部５０は、この解析で得られた属性名と、コンポーネント種別に基づいて、モニタ機能を実装したタグハンドラを生成する（ステップ７０８）。そして、上述したように、この解析結果であるタグハンドラからクラスのソースファイルが生成され、モニタ機能タグライブラリを呼び出すタグライブラリ定義ファイルが生成される（図６、ステップ６０８、６０９参照）。図１１は、モニタ機能を実装したタグハンドラクラスのソースコードの例を示す図、図１２は、モニタ機能タグライブラリを呼び出すタグライブラリ定義ファイルの例を示す図である。
【００３９】
図１３は、通常のタグハンドラ呼び出しとモニタ２０の呼び出しとの違いをタグライブラリ定義ファイルの関係で説明する図である。
図１３の例において、ＪＳＰページ中の宣言しているタグライブラリを呼び出すＵＲＬの
＜ｂｅａｎ：ｗｒｉｔｅ ｎａｍｅ＝”ｕｓｅｒｎａｍｅ” …／＞
という記述から、ｗｅｂ．ｘｍｌ（ウェブアプリケーション）中で記述しているＵＲＬとタグライブラリ定義ファイルとのマッピングを行うと、通常の呼び出しの場合は、タグリブの記述から
／ＷＥＢ−ＩＮＦ／ｓｔｒｕｔｓ−ｂｅａｎ．ｔｌｄ
によって「ｓｔｒｕｔｓ−ｂｅａｎ．ｔｌｄ」が呼ばれ、タグライブラリ定義ファイル中で記述されているタグハンドラ定義から、「ＷｒｉｔｅＴａｇ」が呼び出される。
これに対し、モニタ機能が実装された後では、ｗｅｂ．ｘｍｌ中で記述しているＵＲＬとタグライブラリ定義ファイルとのマッピングを行うと、タグリブの記述から
／ＷＥＢ−ＩＮＦ／ｍｏｎｉｔｏｒ．ｔｌｄ
によって「ｍｏｎｉｔｏｒ．ｔｌｄ」が呼ばれ、タグライブラリ定義ファイル中で記述されているタグハンドラ定義から、「ＭｏｎｉｔｏｒＷｒｉｔｅＴａｇ」が呼び出されることとなる。
以上のように、ＪＳＰページの記述は一切変更することなく、ウェブアプリケーションの動作環境（タグライブラリ定義ファイル及びｗｅｂ．ｘｍｌ）を変更することによって、モニタ２０の機能が呼ばれることとなる。
【００４０】
ところで、モニタ生成部５０は、モニタ２０を生成するために、タグハンドラから受け取った属性とコンポーネント呼び出しとを関連付けるが、上述した通常の解析ではコンポーネント呼び出し自体が確実に実行されるかどうかを保証できない場合がある。そのようなケースを以下にまとめる。
【００４１】
１．コンポーネント呼び出し種別の出現が、分岐ロジックによって決定されるとき。
タグハンドラクラスは、Ｊａｖａのロジックとして多様な条件で分岐ロジックを記述可能である。例えば、日付や時間によってコンポーネントを呼び出したり、ビジネスロジックを伴うオブジェクトの振る舞いによってコンポーネントを呼び出したりすることができる。また、Ｓｔｒｕｔｓというフレームワークのタグライブラリには、セッションスコープにコンポーネントが存在していなければ、メッセージリソースとしてコンポーネントを取り出すというロジックがある。このロジックでは、セッションスコープのコンポーネントを取る場合と、メッセージリソースからコンポーネントを取る場合とでは、取得されるコンポーネント種別が変わる。
このようなロジックの判断には、分岐ロジックを実施できるリソースがテスト環境によって個々に用意されているテストアプリケーション上で、動作させる必要がある。
【００４２】
２．ＰａｇｅＣｏｎｔｅｘｔオブジェクトに対する操作が検出できなかったタグハンドラが使用されるとき。
タグハンドラにおいて、属性値がＰａｇｅＣｏｎｔｅｘｔオブジェクトの操作に使用されていない場合や、ＰａｇｅＣｏｎｔｅｘｔオブジェクトの記述が解析できない場合がある。そのようなタグハンドラは、コンポーネント呼び出しを行わない場合が多いが、ネストしているタグハンドラのコンポーネント呼び出しに影響を受ける場合がある。例えば、Ｓｔｒｕｔｓのタグライブラリでは、ｌｏｇｉｃタグハンドラがあり、ｌｏｇｉｃを用いるＪＳＰタグ記述の属性の値によって、ネストしているタグハンドラの呼び出しを行わないことがある。
【００４３】
上記２つのケースでは、ＪＳＰ仕様記述のコンポーネント呼び出し情報に対する「必然性」がｔｒｕｅの場合であっても、当該ＪＳＰページの実行の際に必ず呼び出されるかは静的な解析で保障できるものではない。したがって、当該ＪＳＰページを動的に実行させてコンポーネント呼び出しを行わせる必要がある。
【００４４】
以上説明したモニタ生成部５０の機能により、図４に示したように、ＪＳＰ単体テスト用ウェブアプリケーションに、必要なモニタ２０が実装される。上述したように、モニタ生成部５０によるモニタ２０の生成は、ＪＳＰページの検証に先立って行われる。ＪＳＰページの検証自体は、リクエスト制御部１０、生成されたモニタ２０及び整合性検証部３０にて実行される。また、ＪＳＰページを検証するには、予め検証対象であるＪＳＰページに関して図２に示したＪＳＰ仕様記述を作成し、ＪＳＰ仕様記述格納部４０に格納しておく。
【００４５】
リクエスト制御部１０は、ＪＳＰページを実行するためのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒｓ）リストを取得し、ｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅ＝ｔｒｕｅというパラメータを付加して、ＪＳＰ単体テスト用ウェブアプリケーションに送信する。ＵＲＬリストは、テストしようとするＪＳＰページ群のＵＲＬを集めたものであり、ＪＳＰページ（ウェブアプリケーション）の開発者によって予め用意される。また、ＪＳＰページの集合を編集可能なツールを用いて検証対象のＪＳＰページ群を選択させてＵＲＬリストを自動生成することもできる。
【００４６】
図１４は、リクエスト制御部１０の動作を説明するフローチャートである。
図１４を参照すると、リクエスト制御部１０は、上記のようにして用意されたＵＲＬリストを読み込んで（ステップ１４０１）、当該ＵＲＬリスト中の所定のＵＲＬに対してＨＴＴＰリクエストを送信する（ステップ１４０２）。このとき、このＨＴＴＰリクエストには、ｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅ＝ｔｒｕｅというパラメータが付加される。このＨＴＴＰリクエストに対する応答であるＨＴＴＰレスポンスを受信すると、リクエスト制御部１０は、当該ＨＴＴＰレスポンスにおいてＪＳＰコンパイルエラーか否かを調べる（ステップ１４０３、１４０４）。ＪＳＰコンパイルエラーが発生しなかった場合は、当該ＵＲＬに対する処理が終了する。
【００４７】
一方、このＵＲＬリストを用いたＨＴＴＰリクエストの結果、ＪＳＰコンパイルエラーが発生し、ＨＴＴＰレスポンスとしてエラー結果が返ってきた場合、リクエスト制御部１０は、ｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅ＝ｆａｌｓｅというパラメータを付加して再度ＨＴＴＰリクエストを送信する（ステップ１４０５）。ＪＳＰコンパイルエラーは、ＪＳＰタグ記述とコンポーネントとの関連に不整合が発生している可能性が高い。そこで、再度の送信によって、コンポーネント呼び出しは実行せず呼び出し部分にダミーの結果を与えるダミー実行を、ＪＳＰ単体テスト用アプリケーションに行わせ、ＨＴＴＰレスポンスを受信する（ステップ１４０６）。ダミー実行については後述する。
以上のステップ１４０２〜１４０６は、ステップ１４０１で読み込まれたＵＲＬリストの全てのＵＲＬに対して実行される（ループ）。
【００４８】
ＪＳＰ単体テスト用ウェブアプリケーションには、開発者が開発したＪＳＰページとテストで実行可能なコンポーネントが用意されており、タグライブラリ定義ファイルとプログラムロジックによって、リクエスト制御部１０から発行されたＨＴＴＰリクエストに対応したＪＳＰページをＨＴＴＰサーブレット経由で呼び出すことができる。また、モニタ生成部５０によって生成されたモニタ２０と、ＪＳＰページとコンポーネントとの整合性の検証を行う整合性検証部３０とが実装されている。また、図１３に示したように、ＪＳＰページのＪＳＰタグ記述において、ＪＳＰタグハンドラ呼び出しがモニタ２０への呼び出しに置き換えられている。
【００４９】
モニタ２０は、ＪＳＰページのテスト実行に伴って呼び出され、当該ＪＳＰによるコンポーネント呼び出しを監視する。
図１５は、モニタ２０の動作を説明するフローチャートである。
図１５を参照すると、モニタ２０は、まずＨＴＴＰリクエストの対象であるＪＳＰページ中のコンポーネント呼び出し情報を抽出する（ステップ１５０１）。そして、整合性検証部３０を呼び出し、ステップ１５０１で抽出されたコンポーネント呼び出し情報を、ＨＴＴＰリクエスト名から取得できるＪＳＰページ名と共に、整合性検証部３０に渡す（ステップ１５０２）。
【００５０】
次に、モニタ２０は、リクエスト制御部１０からのＨＴＴＰリクエストにおけるパラメータｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅを参照し（ステップ１５０３）、その値がｔｒｕｅの時は、本来のＪＳＰタグ記述におけるＪＳＰタグハンドラ（モニタ２０への呼び出しに置き換えられる前のＪＳＰタグハンドラ）に対して、実際にコンポーネント呼び出しを実行させる（ステップ１５０４）。そして、当該コンポーネント呼び出しにおけるコンポーネント呼び出し情報を整合性検証部３０へ送る。また、コンポーネント呼び出しの結果を、後述のように、ＪＳＰページへ返す。
【００５１】
一方、パラメータｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅの値がｆａｌｓｅの時は、モニタ２０は、コンポーネント呼び出しを行わずにダミー実行を行い、ダミーの結果をコンポーネント呼び出しの結果としてＪＳＰページへ返す（ステップ１５０５）。この場合、ＪＳＰタグ記述部分における実際の処理結果としては、“ｄｕｍｍｙ”という文字列が返される。また、実際にタグハンドラを実行しなければ判断できない分岐処理がコンポーネント呼び出しに関わっている場合は、モニタ生成部５０にてコンポーネント呼び出し部分の直後に追加されたロジックにより、全てのコンポーネントに関して呼び出し情報のみが抽出され、整合性検証部３０へ送られる。
【００５２】
図１６は、コンポーネント呼び出しに対するモニタ２０の動作を説明する図である。この図の例では、コンポーネントＡ、Ｂが呼び出されるものとする。
図１６において、ＪＳＰページの実行に伴ってモニタ２０が実装されたクラス（以下、モニタ実装クラス）が呼び出されると、ｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅの値がｔｒｕｅの場合は、モニタ実装クラスからタグハンドラクラスへ親クラスのｄｏＳｔａｒｔ（）メソッド呼び出しが返される。そして、タグハンドラクラスの実行時におけるメソッド呼び出しの動作により、対応するコンポーネントＡ、Ｂが呼び出される。一方、ｃｏｍｐｏｎｅｎｔＩｎｖｏｋｅの値がｆａｌｓｅの場合は、コンポーネントＡ、Ｂの呼び出しは行われず、コンポーネント呼び出し情報のみが抽出され、モニタ実装クラスからタグハンドラクラスへはメソッド呼び出しの代わりに“ｄｕｍｍｙ”という文字列が返される。
【００５３】
整合性検証部３０は、上述したモニタ２０によって得られたコンポーネント呼び出し情報に基づいて、当該コンポーネント呼び出しとコンポーネントとの整合性を検証する。
図１７は、整合性検証部３０の構成を示す図である。
図１７を参照すると、整合性検証部３０は、コンポーネント呼び出し情報を検証する呼び出し情報検証部３１と、ＪＳＰページにおけるコンポーネント呼び出しの検証結果を所定の記述形式で作成する結果記述作成部３２と、結果記述作成部３２にて作成された検証結果のログを出力する検証結果ログ出力部３３と、必要に応じてＪＳＰページ仕様記述を更新する仕様更新部３４とを備える。
【００５４】
呼び出し情報検証部３１は、モニタ２０により抽出されたコンポーネント呼び出し情報を入力し、ＪＳＰ仕様記述格納部４０に格納されている当該ＪＳＰページの仕様記述を参照し比較して、整合性を検証する。
図１８、１９は、呼び出し情報検証部３１による処理の流れを説明するフローチャートである。
図１８に示すように、呼び出し情報検証部３１は、テスト実行されたＪＳＰページからモニタ２０により抽出されたＪＳＰページ名とコンポーネント呼び出し情報とを取得すると（ステップ１８０１）、まず、ＪＳＰ仕様記述格納部４０を調べ、取得したＪＳＰ名に対応するＪＳＰ仕様記述が存在するかどうかを調べる（ステップ１８０２）。対応するＪＳＰ仕様記述が存在しない場合は、当該ＪＳＰページにおけるコンポーネント呼び出しとその呼び出し対象であるコンポーネントとが不整合であるため、呼び出し情報検証部３１は、不整合という検証結果を結果記述作成部３２に通知する（ステップ１８０３）。
【００５５】
取得したＪＳＰ名に対応するＪＳＰ仕様記述がＪＳＰ仕様記述格納部４０に格納されていた場合、呼び出し情報検証部３１は、次に、ＪＳＰ仕様記述格納部４０から、当該ＪＳＰ仕様記述に登録されているコンポーネント呼び出し情報のリスト（コンポーネント名）を取得する（図１９、ステップ１８０４）。そして、モニタ２０により抽出されたコンポーネント呼び出し情報のコンポーネント名が当該リスト中に存在するかどうかを調べる（ステップ１８０５）。同一のコンポーネント名が存在しない場合、当該ＪＳＰページにおけるコンポーネント呼び出しとその呼び出し対象であるコンポーネントとが不整合であるため、呼び出し情報検証部３１は、不整合という検証結果を結果記述作成部３２に通知する（ステップ１８０３）。
【００５６】
ＪＳＰ仕様記述のコンポーネント呼び出し情報に、モニタ２０により抽出されたコンポーネント呼び出し情報と同一のコンポーネント名のものが存在した場合、次に呼び出し情報検証部３１は、ＪＳＰ仕様記述格納部４０から、当該ＪＳＰ仕様記述における当該コンポーネント呼び出し情報を取得する（ステップ１８０６）。そして、取得したコンポーネント呼び出し情報とモニタ２０により抽出されたコンポーネント呼び出し情報とに関して、コンポーネント種別が同一かどうか（ステップ１８０７）、コンポーネントの属性が記述されている場合はその属性値が同一かどうか（ステップ１８０８、１８０９）、スコープの情報が記述されている場合はそのスコープが同一かどうか（ステップ１８１０、１８１１）を、それぞれ調べる。コンポーネント種別、属性値、スコープのいずれかが異なっている場合、当該ＪＳＰページにおけるコンポーネント呼び出しとその呼び出し対象であるコンポーネントとが不整合であるため、呼び出し情報検証部３１は、不整合という検証結果を結果記述作成部３２に通知する（ステップ１８０３）。
【００５７】
一方、コンポーネント種別、属性またはスコープ情報が記述されている場合の属性値またはスコープがいずれも同一である場合、呼び出し情報検証部３１は、当該コンポーネント呼び出しを後述する記述漏れ抽出用のリストに登録する（ステップ１８１２）。そして、整合という検証結果を結果記述作成部３２に通知する（ステップ１８１３）。
【００５８】
また、呼び出し情報検証部３１は、モニタ２０においてＪＳＰページ単位でコンポーネント呼び出し抽出が終了した際に、記述漏れのエラー項目をチェックする。
図２０は、呼び出し情報検証部３１による記述漏れのエラー項目の検出処理の流れを説明するフローチャートである。
図２０を参照すると、呼び出し情報検証部３１は、まず、ＪＳＰ仕様記述格納部４０からＪＳＰ仕様記述を読み込み、図１９のステップ１８１２で作成された記述漏れ抽出用リストを読み込む（ステップ２００１、２００２）。そして、検証対象である（すなわちリストに対応する）ＪＳＰページのＪＳＰ仕様記述における各コンポーネント呼び出し情報に順次着目し（ステップ２００３）、当該コンポーネント呼び出し情報に対応する検証結果が記述漏れ抽出用リストに存在するかどうかを調べる（ステップ２００４）。
【００５９】
このステップ２００３、２００４の処理を、検証対象であるＪＳＰページのＪＳＰ仕様記述における全てのコンポーネント呼び出し情報に対して行う（ループ）。そして、１つでも記述漏れ抽出用リストに存在しないコンポーネント呼び出し情報があったならば、その時点で、当該検証対象であるＪＳＰページに記述漏れのエラーがあったことを結果記述作成部３２に通知して処理を終了する（ステップ２００５）。
【００６０】
結果記述作成部３２は、呼び出し情報検証部３１の検証結果に基づいて呼び出し結果記述を作成する。呼び出し結果記述は、ＪＳＰページ単位で検証の結果得られたコンポーネント呼び出し情報をまとめたものであり、整合・不整合の別と不整合の理由（ＪＳＰページが存在しない、属性が不明など）、記述漏れ等の情報が含まれる。図２１は、呼び出し結果記述の例を示す図である。図２１に示す例では、呼び出し結果記述には、モニタ２０にて抽出されたコンポーネント呼び出し情報と、呼び出し情報検証部３１による検証結果とが記述されている。また、この検証結果に対する識別番号が付される。
【００６１】
検証結果ログ出力部３３は、結果記述作成部３２により作成された呼び出し結果記述に基づいて検証結果のログ情報を出力し、例えば所定のディスプレイ装置に当該ログ情報を表示して、ＪＳＰページ（ウェブアプリケーション）の開発者に通知する。図２２は、検証結果のログ情報の表示出力例を示す図である。図２２において、右端のチェックボックスは、後述する仕様更新処理において、どのＪＳＰページ（ＪＳＰファイル）を更新するかを指定するために用いられる。
【００６２】
開発者は、出力された検証結果を確認し、不整合箇所に関して、当該検証結果に基づいてＪＳＰページのＪＳＰタグ記述を修正することができる。さらに本実施の形態では、検証結果により得られた不整合箇所を正しいＪＳＰタグ記述としてＪＳＰページ仕様記述に反映させることができる。この場合、開発者は、不整合であるＪＳＰページの検証結果の識別番号と必然性の情報（ｔｒｕｅまたはｆａｌｓｅ）を指定して、仕様更新部３４にＪＳＰ仕様記述の更新をリクエストする。
【００６３】
仕様更新部３４は、上記の更新リクエストを受け付け、当該リクエストの対象であるＪＳＰページのＪＳＰ仕様記述を更新する。
図２３は、仕様更新部３４の動作を説明するフローチャートである。
図２３を参照すると、仕様更新部３４は、更新リクエストを受け付けると（ステップ２３０１）、当該更新リクエストに含まれる識別番号に基づいて、更新すべきコンポーネント呼び出し情報を特定する（ステップ２３０２）。そして、ＪＳＰ仕様記述格納部４０から対応するＪＳＰページのＪＳＰ仕様記述を読み出す（ステップ２３０３）。
【００６４】
次に、仕様更新部３４は、更新リクエストの内容に応じて、ＪＳＰ仕様記述における所望の項目の記述を削除もしくは追加する（ステップ２３０４、２３０５、２３０６）。そして、記述内容が変更されたＪＳＰ仕様記述をＪＳＰ仕様記述格納部４０に格納する（ステップ２３０７）。
以上のようにして、モニタ２０により抽出されたコンポーネント呼び出し情報の内容が、対応するＪＳＰページのＪＳＰ仕様記述に反映されることとなる。
【００６５】
次に、以上のように構成された本実施の形態のウェブアプリケーション開発支援装置によるＪＳＰページの検証処理を説明する。
図２４は、本実施の形態のウェブアプリケーション開発支援装置によるＪＳＰページの検証処理の全体的な流れを説明するフローチャートである。
図２４に示すように、まず、予め用意されたＵＲＬを用いて、リクエスト制御部１０によりＨＴＴＰリクエストが発行される（ステップ２４０１）。このＨＴＴＰリクエストは、ＪＳＰ単体テスト用ウェブアプリケーションにおいて、タグライブラリ定義ファイル及びプログラムロジックによって処理され、ＨＴＴＰリクエストに対応したＪＳＰページが呼び出される（ステップ２４０２）。そして、このＪＳＰページにより動的に生成されたコンテンツが、ＨＴＴＰレスポンスとしてリクエスト制御部１０に返される。
【００６６】
一方、ＪＳＰページが呼び出された際、モニタ２０により、当該ＪＳＰページのタグ記述に基づいて、タグハンドラにより実行されるコンポーネント呼び出しに関するコンポーネント呼び出し情報が抽出される（ステップ２４０３）。そして、抽出されたコンポーネント呼び出し情報が、整合性検証部３０により、予め設定されてＪＳＰ仕様記述格納部４０に格納されているＪＳＰ仕様記述と照合されることにより、当該コンポーネント呼び出しとその対象であるコンポーネントとの整合性が検証される（ステップ２４０４）。
【００６７】
ＪＳＰページ（ウェブアプリケーション）の開発者は、この検証結果を参照し、対応措置として、検証対象であったＪＳＰページの不整合箇所を修正するか、ＪＳＰ仕様記述の方を更新するかを選択できる。ＪＳＰ仕様記述を更新する場合は、更新リクエストの入力を条件として、整合性検証部３０の仕様更新部３４により、ＪＳＰ仕様記述の記述内容がモニタ２０にて抽出されたコンポーネント呼び出し情報の内容に更新される（ステップ２４０５、２４０６）。
【００６８】
【発明の効果】
以上説明したように、本発明によれば、ＪＳＰページとその関連するコンポーネントとの間の整合・不整合を解析し、自動的に検証することが可能となる。
また本発明によれば、ＪＳＰページとその関連するコンポーネントとの間の整合・不整合の検証を行うことにより、ＪＳＰページの開発作業を支援し、ＪＳＰページの品質向上および開発コストの削減に寄与することができる。
【図面の簡単な説明】
【図１】本実施の形態で定義されるコンポーネント呼び出し情報の構成を示す図である。
【図２】本実施の形態で用いられるＪＳＰ仕様記述の例を示す図である。
【図３】本実施の形態によるウェブアプリケーション開発支援装置を実現するコンピュータ装置のハードウェア構成の例を模式的に示した図である。
【図４】本実施の形態によるウェブアプリケーション開発支援装置の機能構成を示す図である。
【図５】本実施の形態におけるモニタ生成部の機能を説明する図である。
【図６】本実施の形態におけるモニタ生成部の動作を説明するフローチャートである。
【図７】本実施の形態におけるモニタ生成部の動作を説明するフローチャートであり、コンポーネント呼び出しの種別判断と関連する属性とを求めるためのタグライブラリの解析処理を説明するフローチャートである。
【図８】図７の処理において用いられる情報を示す図であり、図８（Ａ）はタグライブラリ定義ファイルのパスのリストを示す図、図８（Ｂ）はタグハンドラの定義を示す図である。
【図９】本実施の形態で用いられるコンポーネント種別判断テーブルの構成例を示す図である。
【図１０】タグハンドラにおける分岐ロジックのコードにコンポーネント呼び出し情報のロジックを追加した例を示す図である。
【図１１】モニタ機能を実装したタグハンドラクラスのソースコードの例を示す図である。
【図１２】モニタ機能タグライブラリを呼び出すタグライブラリ定義ファイルの例を示す図である。
【図１３】通常のタグハンドラ呼び出しとモニタの呼び出しとの違いをタグライブラリ定義ファイルの関係で説明する図である。
【図１４】本実施の形態におけるリクエスト制御部の動作を説明するフローチャートである。
【図１５】本実施の形態におけるモニタの動作を説明するフローチャートである。
【図１６】コンポーネント呼び出しに対するモニタの動作を説明する図である。
【図１７】本実施の形態における整合性検証部の構成を示す図である。
【図１８】本実施の形態における呼び出し情報検証部による処理の流れを説明するフローチャートである。
【図１９】本実施の形態における呼び出し情報検証部による処理の流れを説明するフローチャートである。
【図２０】本実施の形態における呼び出し情報検証部による記述漏れのエラー項目の検出処理の流れを説明するフローチャートである。
【図２１】呼び出し情報検証部の結果記述作成部により生成される呼び出し結果記述の例を示す図である。
【図２２】呼び出し情報検証部の検証結果ログ出力部による検証結果のログ情報の表示出力例を示す図である。
【図２３】本実施の形態における仕様更新部の動作を説明するフローチャートである。
【図２４】本実施の形態のウェブアプリケーション開発支援装置によるＪＳＰページの検証処理の全体的な流れを説明するフローチャートである。
【図２５】ＪＳＰページに関連する主要なコンポーネント群を示す図である。
【符号の説明】
１０…リクエスト制御部、２０…モニタ、３０…整合性検証部、３１…呼び出し情報検証部、３２…結果記述作成部、３３…検証結果ログ出力部、３４…仕様更新部、４０…ＪＳＰ仕様記述格納部、５０…モニタ生成部、１０１…ＣＰＵ、１０３…メインメモリ、１０５…ハードディスク
Claims (17)
- 動的にコンテンツが生成されるウェブページにおける当該コンテンツを生成するためのコンポーネント呼び出しの実行を監視し、当該コンポーネント呼び出しに関する情報を抽出するモニタと、
前記モニタにより抽出された前記コンポーネント呼び出しに関する情報に基づいて、当該コンポーネント呼び出しと当該コンポーネント呼び出しの対象であるコンポーネントとの整合性を検証する整合性検証部と
を備えることを特徴とするウェブアプリケーション開発支援装置。 - 前記モニタは、所定のコンポーネント呼び出しが実際に実行されるかどうかが実行時まで決まらない場合に、当該コンポーネント呼び出しの実行の有無に関わらずに、前記コンポーネント呼び出しに関する情報を抽出することを特徴とする請求項１に記載のウェブアプリケーション開発支援装置。
- 前記整合性検証部は、前記ウェブページごとに予め設定された前記コンポーネント呼び出しに関する情報をまとめた仕様情報と前記モニタにて抽出された情報とを照合することにより、当該コンポーネント呼び出しと前記コンポーネントとの整合性を検証することを特徴とする請求項１に記載のウェブアプリケーション開発支援装置。
- 前記整合性検証部による検証結果に基づいて、前記仕様情報を更新する仕様更新部をさらに備えることを特徴とする請求項１に記載のウェブアプリケーション開発支援装置。
- 前記コンポーネント呼び出しの記述に用いられるライブラリに関する情報を解析して、当該コンポーネント呼び出しに対応する前記モニタを生成するモニタ生成部をさらに備えることを特徴とする請求項１に記載のウェブアプリケーション開発支援装置。
- 動的にコンテンツが生成されるウェブページに対するＨＴＴＰリクエストを発行するリクエスト制御部と、
前記ウェブページにおける前記コンテンツを生成するためのコンポーネント呼び出しの実行を監視し、当該コンポーネント呼び出しに関する情報を抽出するモニタと
を備えることを特徴とするコンポーネント呼び出し監視装置。 - 前記コンポーネント呼び出しの記述に用いられるライブラリに関する情報を解析して、当該コンポーネント呼び出しに対応する前記モニタを生成するモニタ生成部をさらに備えることを特徴とする請求項６に記載のコンポーネント呼び出し監視装置。
- 前記モニタ生成部は、前記ライブラリに関する情報の解析結果に基づき、所定の記憶手段に格納されている当該ライブラリの定義ファイルを、前記コンポーネント呼び出しの実行に際して当該コンポーネント呼び出しに関する情報を抽出する機能を含んだライブラリ定義ファイルに置き換えることにより、前記モニタを自装置に実装させることを特徴とする請求項７に記載のコンポーネント呼び出し監視装置。
- コンピュータを用いて、所定のデータ処理を行うデータ処理方法であって、
動的にコンテンツが生成されるウェブページにおける当該コンテンツを生成するためのコンポーネント呼び出しに関して、当該コンポーネント呼び出しの記述に用いられるライブラリに関する情報を解析する第１のステップと、
解析結果に基づき、所定の記憶手段に格納されている当該ライブラリの定義ファイルを、前記コンポーネント呼び出しの実行に際して当該コンポーネント呼び出しに関する情報を抽出する機能を含んだライブラリ定義ファイルに置き換える第２のステップと、
置き換えられた前記ライブラリ定義ファイルを用いて前記コンポーネント呼び出しを実行し、実行された当該コンポーネント呼び出しに関する情報を抽出する第３のステップと
を含むことを特徴とするデータ処理方法。 - 前記ウェブページごとに予め設定されて所定の記憶手段に格納された前記コンポーネント呼び出しに関する情報をまとめた仕様情報と、前記第３のステップで抽出された情報とを照合することにより、当該コンポーネント呼び出しと当該コンポーネント呼び出しの対象であるコンポーネントとの整合性を検証する第４のステップをさらに含むことを特徴とする請求項９に記載のデータ処理方法。
- 前記第４のステップによる検証結果に基づいて、前記所定の記憶手段に格納されている前記仕様情報を更新する第５のステップをさらに含むことを特徴とする請求項１０に記載のデータ処理方法。
- コンピュータを制御して、動的にコンテンツが生成されるウェブページにおける当該コンテンツを生成するためのコンポーネント呼び出しを監視するプログラムであって、
前記コンポーネント呼び出しの記述に用いられるライブラリに関する情報を解析する第１の処理と、
解析結果に基づき、所定の記憶手段に格納されている当該ライブラリの定義ファイルを、前記コンポーネント呼び出しの実行に際して当該コンポーネント呼び出しに関する情報を抽出する機能を含んだライブラリ定義ファイルに置き換える第２の処理と、
置き換えられた前記ライブラリ定義ファイルを用いて前記コンポーネント呼び出しを実行し、実行された当該コンポーネント呼び出しに関する情報を抽出する第３の処理と
を前記コンピュータに実行させることを特徴とするプログラム。 - 前記第３の処理では、所定のコンポーネント呼び出しが実際に実行されるかどうかが実行時まで決まらない場合に、当該コンポーネント呼び出しの実行の有無に関わらずに、前記コンポーネント呼び出しに関する情報を抽出する処理を前記コンピュータに実行させることを特徴とする請求項１２に記載のプログラム。
- コンピュータを制御して、ウェブアプリケーションの開発を支援するプログラムであって、
動的にコンテンツが生成されるウェブページにおける当該コンテンツを生成するためのコンポーネント呼び出しを実行する手段と、
前記コンポーネント呼び出しの実行を監視し、当該コンポーネント呼び出しに関する情報を抽出する手段と、
抽出された前記コンポーネント呼び出しに関する情報に基づいて、当該コンポーネント呼び出しと当該コンポーネント呼び出しの対象であるコンポーネントとの整合性を検証する手段として、
前記コンピュータを機能させることを特徴とするプログラム。 - 前記コンポーネント呼び出しと前記コンポーネントとの整合性を検証する手段は、前記ウェブページごとに予め設定され所定の記憶手段に格納された前記コンポーネント呼び出しに関する情報をまとめた仕様情報と前記モニタにて抽出された情報とを照合することにより、当該コンポーネント呼び出しと前記コンポーネントとの整合性を検証することを特徴とする請求項１４に記載のプログラム。
- 前記コンポーネント呼び出しと前記コンポーネントとの整合性を検証する手段による検証結果に基づいて、前記仕様情報を更新する手段として、前記コンピュータをさらに機能させることを特徴とする請求項１５に記載のプログラム。
- 請求項１２から請求項１６のいずれかに記載のプログラムを、コンピュータが読み取り可能に記録した記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003156042A JP4023803B2 (ja) | 2003-05-30 | 2003-05-30 | ウェブアプリケーション開発支援装置、データ処理方法及びプログラム |
| US10/850,147 US20040268312A1 (en) | 2003-05-30 | 2004-05-20 | Application development support, component invocation monitoring, and data processing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003156042A JP4023803B2 (ja) | 2003-05-30 | 2003-05-30 | ウェブアプリケーション開発支援装置、データ処理方法及びプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004362000A true JP2004362000A (ja) | 2004-12-24 |
| JP4023803B2 JP4023803B2 (ja) | 2007-12-19 |
Family
ID=33534552
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003156042A Expired - Fee Related JP4023803B2 (ja) | 2003-05-30 | 2003-05-30 | ウェブアプリケーション開発支援装置、データ処理方法及びプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US20040268312A1 (ja) |
| JP (1) | JP4023803B2 (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006318203A (ja) * | 2005-05-12 | 2006-11-24 | Nippon Telegr & Teleph Corp <Ntt> | ＪａｖａサーブレットによるＷｅｂサーバシステム |
| JP2008015709A (ja) * | 2006-07-04 | 2008-01-24 | Fujitsu Ltd | テスト支援プログラム、テスト支援装置、およびテスト支援方法 |
| CN111240962A (zh) * | 2019-12-31 | 2020-06-05 | 中移（杭州）信息技术有限公司 | 测试方法、装置、计算机设备及计算机存储介质 |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2874440B1 (fr) * | 2004-08-17 | 2008-04-25 | Oberthur Card Syst Sa | Procede et dispositif de traitement de donnees |
| US7634721B1 (en) * | 2004-08-23 | 2009-12-15 | Sun Microsystems Inc. | Composite component architecture using javaserver pages (JSP) tags |
| US7849459B2 (en) * | 2004-11-04 | 2010-12-07 | International Business Machines Corporation | Deploying java applications in resource constrained environments |
| US20070089052A1 (en) * | 2005-10-13 | 2007-04-19 | Karle Christopher J | Systems, methods, and media for enforcing accessible content development |
| US8015547B2 (en) * | 2006-06-29 | 2011-09-06 | Augusta Systems, Inc. | Reconfigurable, hierarchical component-based architecture and framework and methods for rapidly developing sensor device-enabling software applications |
| US20080005721A1 (en) * | 2006-06-29 | 2008-01-03 | Augusta Systems, Inc. | Method and System for Rapidly Developing Sensor-Enabled Software Applications |
| US8095923B2 (en) * | 2006-06-29 | 2012-01-10 | Augusta Systems, Inc. | System and method for deploying and managing intelligent nodes in a distributed network |
| US7735060B2 (en) * | 2006-06-29 | 2010-06-08 | Augusta Systems, Inc. | Method and system for rapidly developing and deploying sensor-enabled software applications |
| JP4899971B2 (ja) * | 2007-03-27 | 2012-03-21 | 富士通株式会社 | テスト仕様書作成プログラム、テスト仕様書作成装置、およびテスト仕様書作成方法 |
| US7822853B2 (en) * | 2008-09-30 | 2010-10-26 | Microsoft Corporation | Stabilization of distributed systems |
| US9058429B2 (en) * | 2009-11-06 | 2015-06-16 | Toby Biddle | Usability testing tool |
| JP5669433B2 (ja) | 2010-05-06 | 2015-02-12 | キヤノン株式会社 | 部品結合装置及び部品結合方法 |
| US9361131B1 (en) * | 2011-06-24 | 2016-06-07 | Amazon Technologies, Inc. | Network resource access via a mobile shell |
| US9104795B2 (en) * | 2011-06-28 | 2015-08-11 | International Business Machines Corporation | Integrating compiler warnings into a debug session |
| US9384020B2 (en) * | 2013-01-18 | 2016-07-05 | Unisys Corporation | Domain scripting language framework for service and system integration |
| US9229694B2 (en) | 2013-03-15 | 2016-01-05 | Gamesys Ltd. | Systems and methods for facilitating application development utilizing plugins |
| US10936477B2 (en) * | 2018-01-31 | 2021-03-02 | Salesforce.Com, Inc. | End-to-end user interface component testing |
| US11055417B2 (en) * | 2018-04-17 | 2021-07-06 | Oracle International Corporation | High granularity application and data security in cloud environments |
| CN111124553B (zh) * | 2019-12-06 | 2024-04-26 | 北京小米移动软件有限公司 | 一种程序执行方法、装置、终端及存储介质 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6620204B1 (en) * | 1997-11-25 | 2003-09-16 | International Business Machines Corporation | Automated HTML test page and test data generation for javascript objects |
| CA2255023C (en) * | 1998-11-30 | 2004-04-13 | Siu Chung Yuen | A method and system for monitoring the execution of hybrid source code |
| US6604209B1 (en) * | 2000-09-29 | 2003-08-05 | Sun Microsystems, Inc. | Distributed component testing in an enterprise computer system |
| US7047522B1 (en) * | 2001-04-30 | 2006-05-16 | General Electric Capital Corporation | Method and system for verifying a computer program |
| US6826716B2 (en) * | 2001-09-26 | 2004-11-30 | International Business Machines Corporation | Test programs for enterprise web applications |
| US6792460B2 (en) * | 2002-10-02 | 2004-09-14 | Mercury Interactive Corporation | System and methods for monitoring application server performance |
| US7650592B2 (en) * | 2003-03-01 | 2010-01-19 | Bea Systems, Inc. | Systems and methods for multi-view debugging environment |
-
2003
- 2003-05-30 JP JP2003156042A patent/JP4023803B2/ja not_active Expired - Fee Related
-
2004
- 2004-05-20 US US10/850,147 patent/US20040268312A1/en not_active Abandoned
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006318203A (ja) * | 2005-05-12 | 2006-11-24 | Nippon Telegr & Teleph Corp <Ntt> | ＪａｖａサーブレットによるＷｅｂサーバシステム |
| JP4489634B2 (ja) * | 2005-05-12 | 2010-06-23 | 日本電信電話株式会社 | ＪａｖａサーブレットによるＷｅｂサーバシステム |
| JP2008015709A (ja) * | 2006-07-04 | 2008-01-24 | Fujitsu Ltd | テスト支援プログラム、テスト支援装置、およびテスト支援方法 |
| CN111240962A (zh) * | 2019-12-31 | 2020-06-05 | 中移（杭州）信息技术有限公司 | 测试方法、装置、计算机设备及计算机存储介质 |
| CN111240962B (zh) * | 2019-12-31 | 2023-09-05 | 中移（杭州）信息技术有限公司 | 测试方法、装置、计算机设备及计算机存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20040268312A1 (en) | 2004-12-30 |
| JP4023803B2 (ja) | 2007-12-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4023803B2 (ja) | ウェブアプリケーション開発支援装置、データ処理方法及びプログラム | |
| JP4140916B2 (ja) | Ｗｅｂページにおける状態遷移を解析する方法 | |
| US9465725B2 (en) | Software defect reporting | |
| US8959483B2 (en) | Test framework of visual components in a multitenant database environment | |
| US7877681B2 (en) | Automatic context management for web applications with client side code execution | |
| Martin-Lopez et al. | Specification and automated analysis of inter-parameter dependencies in web APIs | |
| US8615750B1 (en) | Optimizing application compiling | |
| US20080126931A1 (en) | System and method for recording and reproducing user operation | |
| US8645916B2 (en) | Crunching dynamically generated script files | |
| US8661416B2 (en) | Method and apparatus for defining and instrumenting reusable Java server page code snippets for website testing and production | |
| US8621613B1 (en) | Detecting malware in content items | |
| JP2003256202A (ja) | 整合性検査支援プログラム、整合性検査支援方法および整合性検査支援装置 | |
| US10705949B2 (en) | Evaluation of library test suites using mutation testing | |
| JP2004178263A (ja) | Ｗｅｂサーバ、Ｊａｖａサーブレットの機能を有するＷｅｂサーバ、およびコンピュータプログラム | |
| GB2511329A (en) | Web service black box testing | |
| JP6692289B2 (ja) | 画面情報生成装置、画面情報生成方法、及びプログラム | |
| US11237889B1 (en) | Application infrastructure configuration based on annotated API schemas | |
| US9348977B1 (en) | Detecting malware in content items | |
| JP2010237841A (ja) | 動作検証装置および動作検証プログラム | |
| JP4681673B1 (ja) | 動作検証装置、動作検証方法および動作検証プログラム | |
| JP6426535B2 (ja) | テスト支援装置、及びテスト支援方法 | |
| US11960560B1 (en) | Methods for analyzing recurring accessibility issues with dynamic web site behavior and devices thereof | |
| JP7488976B1 (ja) | セキュリティテストシステム | |
| US12001324B2 (en) | Operation pattern generation apparatus, operation pattern generation method and program | |
| Salama | “Down With Regression!”–Generating Test Suites for the Web |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061201 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070206 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070501 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070529 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070828 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070925 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20070926 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071001 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101012 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |