(57)【要約】【課題】Ｗｅｂアプリケーションシステムの開発において、画面イメージ作成にかかる工数の削減、および作成後のイメージを統一させ、自動で一括作成することができる巡回型画面チャプチャーシステム。【解決手段】ＷｅｂアプリケーションシステムにおけるＨＴＭＬの画面イメージをキャッシュとして一時保存可能なプロキシサーバと、  前記ＷｅｂアプリケーションシステムのＵＲＬを取得するＵＲＬ巡回機能と、前記ＵＲＬ巡回機能により取得された各ＵＲＬに関連して呼び出される画面イメージをキャプチャーするイメージキャプチャーと、前記イメージキャプチャーにより取得された各画面イメージを変換する画像変換ツールと、を備えたことを特徴とする巡回型画面キャプチャーシステム。【選択図】図２
2008009674.tif 000002
【特許請求の範囲】
【請求項１】
ＷｅｂアプリケーションシステムにおけるＨＴＭＬの画面イメージをキャッシュとして一時保存可能なプロキシサーバと、
前記ＷｅｂアプリケーションシステムのＵＲＬを取得するＵＲＬ巡回機能と、
前記ＵＲＬ巡回機能により取得された各ＵＲＬに関連して呼び出される画面イメージをキャプチャーするイメージキャプチャーと、
前記イメージキャプチャーにより取得された各画面イメージを変換する画像変換ツールと、を備えたことを特徴とする巡回型画面キャプチャーシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂアプリケーションシステムの開発、およびそのマニュアル作成等に伴う画面イメージを取り扱うシステムに関し、特に画面キャプチャーシステムに関するものである。
【背景技術】
【０００２】
Ｗｅｂアプリケーションシステムとは、インターネット（Ｗｅｂ）に接続されたコンピュータを使って文書、表、あるいはデータベース等を作るような、それぞれの目的を実現するためのソフトウェアのことであり、閲覧ソフトであるＷｅｂブラウザを介して利用可能なシステムである。このＷｅｂアプリケーションシステムは、規模の大小、または個人と法人の別を問わず各方面で開発され利用され、Ｗｅｂの急速かつ世界的な普及、および高機能化に伴って一般大衆にまで浸透した。
【０００３】
Ｗｅｂで閲覧可能なＷｅｂページを記述するための言語として、ＨｙｐｅｒＴｅｘｔ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＨＴＭＬ）がある。このＨＴＭＬ言語（以下、単に「ＨＴＭＬ」と略す）は周知のとおり、文書の論理的構造や見栄えを記述するために使い、画像や音声、動画等をページ内に埋め込むことも可能である。そして、ＨＴＭＬ自体は＜＞内に指定されたタグと呼ばれる予約語によって、他の文書へのリンクや画像ファイルのある場所等が記述されたテキストファイルである。このＨＴＭＬファイルを読み込んで、表示するには前記Ｗｅｂブラウザを用いる。
【０００４】
また、キャッシュとは、パーソナルコンピュータ（パソコン）で、一度取り出したものを、次にまた使う時に備えて一時的に置いておくところである。パソコン内部や周辺でのデータの流れには、スピードが速い部分と、相対的にスピードの遅い部分があり、スピードの速いところが無駄に待たされることがないようにキャッシュが使われる。
【０００５】
例えば、Ｗｅｂブラウザのキャッシュは以下のとおりに用いられる。パソコン内の処理は速いけれども、Ｗｅｂ側からのデータは電話回線経由で遅くなってしまうので、その間（ブラウザとＷｅｂの間、物理的にはハードディスク）に「キャッシュ」を置いて、２度目に同じページを見る場合は、Ｗｅｂに取りにいくのではなく、キャッシュ（実体はハードディスク上にあるファイル）にあるデータで表示するようにする。
【０００６】
また、キャプチャーとは、グラフィック（画面）イメージをファイル等にして取り込ことである。例えば、Ｗｉｎｄｏｗｓ（登録商標）では任意の場面で「Ｐｒｉｎｔ  Ｓｃｒｅｅｎ」キーを押すことにより、その瞬間の画面イメージをクリップボードに転送することができる。さらに、キャプチャーカードと呼ばれる拡張カードをパソコンに追加装備すれば、静止画以外にも、アナログである家庭用ビデオの画像をデジタルデータに変換し、ファイルに記録することも可能である。
【０００７】
また、法人向けのＷｅｂアプリケーションシステムには、画面数が１００を越える大規模システムもある。その場合は、開発に要する工数およびコストも規模に応じて当然に増加する。そこで、開発工数増加を抑制するため、大規模なＷｅｂアプリケーションシステム開発を支援する総合開発環境ツールが多種類にわたって普及している。しかしながら、前記大規模システムを設計開発する際は、画面数の多いことが原因となって無駄な反復作業が発生することは避けがたい。
【０００８】
具体的には、Ｗｅｂアプリケーションシステムを開発する際、純粋な技術的段階である設計フェーズにおける画面設計の時と、ほぼ設計完了の前後で、そのシステム用のマニュアルを作成する時に、Ｗｅｂアプリケーションシステムの画面イメージを作成する作業が多発することがある。その際、システム内の全画面を、画面キャプチャーするという手作業によりパソコン内に保存し、適宜、サイズおよび／またはファイル形式を変換して用いる。
【０００９】
図８は実際の画面イメージ図（以下、単に「画面イメージ」という）と、それを簡略化した画面サンプル図（以下、単に「画面サンプル」という）である。図８に示す画面イメージ８０１は、色彩およびグレースケールまで含んでおり、そのリアルな画面イメージ８０１を構成するデータ量が大きいため、システムにおける処理負担が重くなる。
【００１０】
このリアルな画面イメージ８０１を、そのままマニュアル作成等に使用すると、前記処理負担が重くなるので、その負担を軽減し、かつ工数の軽減、およびコストダウンを図る必要がある。そこで、ドローソフト等により白黒線画とテキストデータ程度にまで簡略化した擬似画面のサンプル、すなわち、画面サンプル８０２で代用するという適宜的手法が多用されている。画面イメージ８０１と、画面サンプル８０２に関しては、図８に沿った定義どおりの意味で、以後の説明に用いる。
【００１１】
一方、パソコン等の個人情報端末に（Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）ＷＷＷコンテンツの先読み機能を付加する技術が知られている。その先読み機能付加技術によれば、要求されたＷＷＷコンテンツを、ＷＷＷプロキシ部によりＷＷＷサーバ装置から取得する。
【００１２】
ちなみに、「Ｐｒｏｘｙ」とは「代理」の意味であり、ＷＷＷプロキシ部とは、Ｐｒｏｘｙ  ｓｅｒｖｅｒ（プロキシサーバ）を意味し、「ＷＷＷコンテンツ」とは規模の大小を問わず動画を含む番組等であってＷｅｂ配信に供されるものである。
【００１３】
前記先読み機能付加技術よる処理手順として、まず、個人用情報端末内のＷＷＷブラウザ部により要求されたコンテンツを、その情報端末内に設けた個人用ＷＷＷプロキシ部によりＷＷＷサーバ装置から取得し、ＷＷＷブラウザ部に送信する。
【００１４】
ついで、個人用ＷＷＷプロキシ部は複数のコンテンツへのアクセス要求を解析してユーザによるコンテンツへのアクセス特性を示すユーザ別アクセス特性データを計測する。
【００１５】
そして、ＷＷＷサーバ装置から取得したコンテンツに含まれたリンク情報が指定する何れかのリンク先のコンテンツを先読みすべきか否かを前記ユーザ別アクセス特性データに基づいて判別し、何れかのリンク先のコンテンツが先読みすべきと判別された時、そのリンク先のコンテンツを先読みし、個人用ＷＷＷプロキシ部に設けられたキャッシュ用記憶手段内に記憶するという手順を含むものである（特許文献１）。
【００１６】
なお、前記ＷＷＷプロキシ部は、社内ネットワークとＷｅｂとの接続地点で、社内クライアントからのリクエストを代行して、両者の通信を中継するアプリケーションのことである。通常はファイアウォール上で稼働させる。Ｗｅｂから社内ネットワーク方向への通信を遮断する一方、社内ネットワークからＷｅｂ方向に対しては、ユーザやアプリケーションを指定してアクセスの制御を行なう。
【００１７】
前記プロキシサーバのもう１つ大きな機能に「キャッシング」がある。ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）プロキシでは、ユーザがアクセスしたページを保管しておくことで、２回目以降のアクセスが高速化される。なお、ＨＴＴＰとは、インターネットのＷＷＷサービスにおいて、ＷＷＷサーバからＷＷＷクライアントに対してＨＴＭＬで記述されたドキュメントを送受信するための通信プロトコルである。
【００１８】
また、「巡回」とは、ＢＢＳやインターネットのＷＷＷアクセスにおいて、定期的にアクセスしている会議室やＷｅｂページを順次参照していくことである。ＢＢＳ用のアクセスソフトウェアやＷＷＷ用アクセスソフトウェアの中には、あらかじめ参照したい会議室やＷｅｂページを登録しておき、これらを自動的に巡回して、最新情報をローカルハードディスクなどに保存する機能を持つものもある。
【００１９】
なお、「巡回」に関連するＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）とは、インターネット上のリソースのロケーションを指し示す記述様式である。また、ルートとは階層構造の一番上の部分を表わす言葉であり、「ＷｅｂアプリケーションのルートＵＲＬ」とは、検索して最初に表示される画面を特定するＵＲＬである。
【００２０】
なお、巡回型画面キャプチャー発明に関連する公知技術文献としては下記特許文献１がある。
【特許文献１】特開２００３−３２３３７０号公報
【発明の開示】
【発明が解決しようとする課題】
【００２１】
しかしながら、前記ドローソフトによる画面サンプル８０２は、実際の画面イメージ８０１に比べて簡素に過ぎ、見栄えの印象がまったく異なるので、以下の問題点を引き起こすことがある。
【００２２】
（１）顧客の要求する仕様と、開発者の認識する設計との間で、少なからず、すれ違いを生じる可能性が高い。なぜならば、実際の画面イメージ８０１は、顧客に提供する画面そのものになるので、画面デザイン、レイアウト、および機能に関する正確な視覚的認識からの理解が容易であるのに対し、画面サンプル８０２は、それらの点を簡略化または省略しているので、不足分はユーザが勝手に想像して補足せざるを得ないからである。
【００２３】
（２）画面サンプル８０２は当然に見栄えが貧弱である。実際の画面イメージ８０１の方が高忠実度にレイアウトまで表現されており、見栄えの点では比較にならない。
（３）顧客に画面サンプル８０２で容認されるか否かの確認を取る必要がある。容認不可となれば、画面イメージ８０１を作成する作業が追加発生し、予定が狂ったりするからである。例えば、実際の画面イメージ８０１が掲載されたリアルなマニュアル等を顧客から要望された場合が該当する。
【００２４】
以上の現状に鑑み、本発明は、前記問題点を解決し、Ｗｅｂアプリケーションの開発において、システムの画面イメージ作成作業における重複操作の手間を省いて一括作成することを可能にした巡回型画面キャプチャーシステムを提供することを目的とする。
【課題を解決するための手段】
【００２５】
前記目的を達成するため、請求項１に係る発明は、ＷｅｂアプリケーションシステムにおけるＨＴＭＬの画面イメージをキャッシュとして一時保存可能なプロキシサーバと、  前記ＷｅｂアプリケーションシステムのＵＲＬを取得するＵＲＬ巡回機能と、前記ＵＲＬ巡回機能により取得された各ＵＲＬに関連して呼び出される画面イメージをキャプチャーするイメージキャプチャーと、前記イメージキャプチャーにより取得された各画面イメージを変換する画像変換ツールと、を備えたことを特徴とする巡回型画面キャプチャーシステムである。
【発明の効果】
【００２６】
請求項１に係る発明によれば、次のような効果がある。
（１）作業者に大きな工数による負担を強いていた従来の手作業による画面イメージ作成作業に関し、作業者が「ＷｅｂアプリケーションのルートＵＲＬ」と「作成イメージの条件」を設定するだけで、自動的に処理が実行される。そのため、作業者に必須の工数は設定作業のみに軽減され、大幅に工数とコストを削減することができる。
【００２７】
（２）手作業により画面イメージを作成していた従来の手作業による画面イメージ作成においては、複数の作業者が分担して作業を行うため、「表示するブラウザ、およびイメージサイズ、ファイル形式、ファイル名、フォントやフォントサイズ等の表示設定」等の統一が困難であり、その統一のための取り決めである生成規則等を設け、作業者相互間の意識合わせを図る必要があったという欠点を解消できる。
【００２８】
すなわち、本システム２０１では、複数の作業者や複数のツールを必要とせず、１ユーザ１ツールによる画面イメージ作成が一括でできるようになるため、「イメージファイルの命名規則」や「画像イメージの書式・サイズ」の統一が容易になる。
【００２９】
また、必要な画面イメージを作成する時間が、従来の作業に比べ削減でき、工数を減少させ、生産性を向上させる。つまり、従来必要だった画面遷移、画面キャプチャー作業および、画像変換作業のうち、画面遷移に係る操作と僅かな設定作業だけで、画面イメージ作成が可能となる。
【００３０】
要するに、本システム２０１によれば、大幅な工数削減、生産性向上効果を得ることができるのである。特に、大規模なシステムでは、さらなる効果を発揮できる。
【発明を実施するための最良の形態】
【００３１】
以下、図面を用いて本発明の実施形態を説明する。ただし、本発明に関連のある一般的事項を図１と図３を用いて予備説明し、図２、図４〜図７により本発明の本質を詳細に説明する。ただし、以後の説明は図の番号順に沿って行う。
【００３２】
図１は一般的な（従来の）画面イメージ作成作業のシーケンス図である。すなわち、一般的なＷｅｂアプリケーション開発において、図１に示す処理手順により画面イメージを作成する。なお、図１に示した（処理１０４）、（処理１０６）、（処理１０８）、（処理１１１）、（処理１１３）における処理番号は、必ずしも通し番号ではなく欠番も含んでいる。また、これらの（処理符号）で示す処理は、コンピュータで相当のプログラムを実行することにより実行されている。
【００３３】
（処理１０４）では、システム開発者（以下、「開発者」と略す）１０１が、ブラウザ１０２を介してＷｅｂアプリケーションシステム１０３にアクセスする。そうすると、Ｗｅｂアプリケーションシステム１０３は、開発者１０１からのリクエストに応じて、ＨＴＭＬファイル１０５を作成してレスポンスを返す。
【００３４】
（処理１０６）では、Ｗｅｂアプリケーションシステム１０３から返されたＨＴＭＬファイル１０５を、ブラウザ１０２でレンダリングし、ブラウザ１０２のウィンドウ上に表示する。なお、レンダリングとは最終的に必要な画像を指示に従って自動的に生成することである。このレンダリングによりリアルな画像を生成するには非常に多くのＣＰＵパワーと時間が必要である。
【００３５】
（処理１０８）では、ブラウザのウィンドウに表示された画面１０７を画面キャプチャーして、ブラウザのウィンドウの画面イメージ１０９を取得する。
【００３６】
（処理１１１）では、画面キャプチャーした画面イメージ１０９に対し、画像変換ツール１１０を使用し、リサイズおよび形式変換等の画像処理を行う。
【００３７】
（処理１１３）では、変換した画面イメージ１１２を、開発者１０１が指定する任意のイメージ保存ディレクトリ１１４に任意のファイル名で保存する。なお、図１ではｊｐｇファイルによる静止画像データを例示している。
【００３８】
図１に示した画面イメージ作成作業における各処理では、合理的かつ最新のツールを使用したとしても、画面イメージを作成する手順を、取り込む画面数に応じた回数だけ開発者１０１が繰り返す必要がある。したがって、画面数の多いＷｅｂアプリケーションでは、繰り返し作業を余儀なくされる。
【００３９】
すなわち、Ｗｅｂアプリケーションシステム１０３の画面イメージ８０１を作成する際、システム上の全ての画面に対し、手作業で画面イメージ作成を行っている。前記繰り返し作業の要点をまとめると、実際の作業は以下の３つの作業に大別される。
【００４０】
（１）ＵＲＬを指定しＨＴＭＬファイルを取得する作業。つまり、どの画面を取得するか指定する作業。
（２）取得したＨＴＭＬファイルの表示画面のイメージを取得する作業。
（３）取得した画面イメージを、適宜に編集する作業。
【００４１】
前記したイメージ作成に必要とされる３つの作業は、開発工数を増加させる要因であるため、本発明に係る巡回型画面キャプチャーシステムにより、これらの３つの作業を自動化できることを説明する。
【００４２】
図２は本発明の実施形態を示すシステム構成図である。すなわち、図２は巡回型画面キャプチャーシステム（以下、「本システム」という）２０１を含んだ全体の組み合わせを示したものであり、本システム２０１と、画面イメージ取得先であるＷｅｂアプリケーションシステム２０２と、イメージ保存先ディレクトリ２０３と、により構成されている。
【００４３】
本システム２０１は、ＵＲＬ巡回機能２０４、プロキシサーバ２０５、イメージキャプチャー２０６、および画像変換ツール２０７で構成されている。なお、本システム２０１の全体的な処理の概略は図５に沿って後記説明する。
【００４４】
図２に示すＷｅｂアプリケーションシステム２０２の詳細な構成に関しては、図３に沿って後記説明するように、ルートＵＲＬから各ページへとリンクしている。ルートＵＲＬとはシステムのトップページであり、そのトップページから子、孫ページへとリンクされているので、それら各ページも閲覧自在である。リンクとは、インターネット上でブラウザを使って、いろいろなＷｅｂサーバに接続できるようにすることであり、ＨＴＭＬによって記述されたハイパーテキストを使って接続先を指定するのでハイパーリンクともいう。
【００４５】
図２に示す（処理２０８）では、Ｗｅｂアプリケーションシステム２０２において、取得したい画面イメージ８０１（図８）を順次遷移していき、それぞれの画面イメージ８０１に対応するＨＴＭＬをプロキシサーバ２０５にキャッシュする。
【００４６】
次に、Ｗｅｂアプリケーションシステム２０２においてキャッシュされたＨＴＭＬを特定するＵＲＬを取得する処理について説明する。このＵＲＬ取得処理は、ＵＲＬ巡回機能２０４により実行される。
【００４７】
図３は、一般的なＷｅｂアプリケーションシステムの構成図である。図３に示すように、Ｗｅｂアプリケーションは、システムのトップページとなるルートＵＲＬ３０１から、各機能にリンクしている（処理３０２〜処理３０４）。
【００４８】
そして、ルートＵＲＬ３０１からの遷移先３０５〜遷移先３０７から、さらに機能の詳細および、機能を利用するためのページへと遷移していく。つまり、ルートＵＲＬ３０１を親ページとして、木構造的にシステムが構成されている。
【００４９】
このようにＷｅｂアプリケーションにおけるシステムの特性として、ルートＵＲＬ３０１から木構造的にリンクが広がっているのである。したがって、ユーザは、まずルートＵＲＬ３０１を選択し、ついでリンクをクリックし、必要画面に遷移する操作を行う。
【００５０】
ここで、各フォームに設定値等を入れる必要があれば、画面イメージ８０１として取得したい値を入力しながら、一連の画面遷移を行う。その時に、プロキシサーバ２０９（図２）に画面キャッシュが自動的に残されるように、プログラムが実行される。
【００５１】
必要な画面イメージ８０１の遷移が終了した後、ユーザがルートＵＲＬ３０１のみを指定をした後は、プロキシサーバ２０９にキャッシュとして一時保存され、かつルートＵＲＬ３０１に関連して呼び出される（以下、「紐付く」という）ＵＲＬの画面を自動的に列挙することが可能である。
【００５２】
ついで、列挙されたＵＲＬの各ページに紐付くＵＲＬの列挙を繰り返し、システム全体のＨＴＭＬを取得する。さらに、自動的に各ＨＴＭＬの画面イメージが取得され、編集され、保存される。これらの処理を１とまとまりに実行できるようにプログラムされている。そのプログラムをコンピュータに実行させるように、本発明に係る巡回型画面キャプチャーシステムが確立されている。
【００５３】
図４は実施形態で使用されるＵＲＬリストによるデータ構造図である。図４に示すように、ＵＲＬ管理を目的としてインデックス０，１，２〜１１…に、各ＵＲＬリストを対応付けたデータ構造になっている。
【００５４】
図５は実施形態の全体的な処理の概略を示すフローチャートである。すなわち、本システム２０１の処理手順の概要を示しており、キャッシュ取得処理（５０１）と、ＵＲＬ取得処理（５０２）、画面イメージキャプチャー処理（５０３）、および、画面イメージ変換処理（５０４）の４つの処理を含むプログラムがコンピュータにより実行される。
【００５５】
図５において、キャッシュ取得処理（５０１）は、Ｗｅｂアプリケーションシステム２０２（図２）におけるＨＴＭＬの画面イメージ８０１（図５）を、キャッシュとして一時保存可能なプロキシサーバ２０５に、Ｗｅｂアプリケーションシステム２０２のＨＴＭＬを、キャッシュとして一時保存する処理である。
【００５６】
ＵＲＬ取得処理（５０２）は、Ｗｅｂアプリケーションシステム２０２のルートＵＲＬを指定することにより、そのルートＵＲＬにリンクされた被リンクＵＲＬを巡回させるとともに、巡回したＵＲＬをリスト化する処理である。
【００５７】
画面イメージキャプチャー処理（５０３）は、前記ＵＲＬ取得処理（５０２）によりリスト化されたＵＲＬリストから複数ページ分のＨＴＭＬを取得するとともに、取得されたＨＴＭＬに対応する各画面イメージ８０１をキャプチャーする処理である。
【００５８】
画面イメージ変換処理（５０４）は、取得した画面イメージを適宜変換して保存する処理である。
【００５９】
これら一連の処理により、ＵＲＬリストに対応する各画面イメージ８０１を速やかに検索して用いることが可能となる。
【００６０】
図６は、実施形態におけるＵＲＬ取得処理の詳細を示すフローチャートである。適宜に他の図面も参照しながらＵＲＬ取得処理の手順を説明する。
【００６１】
図６に示すように、（処理６０１）により、あらかじめ取得したい画面８０１のイメージのサイズとファイル形式を指定する。ついで（処理６０２）により、取得したいＷｅｂアプリケーションシステム２０２のルートＵＲＬを指定する。
【００６２】
そして、（処理６０３）により、ＵＲＬリスト２１０の第０要素に、ルートＵＲＬを格納する。ついで（処理６０４）により、第０要素に格納されたルートＵＲＬのＨＴＭＬを取得し、ＨＴＭＬ上のリンク先のＵＲＬを取得する。
【００６３】
また、（処理６０５）では、取得したＵＲＬのＨＴＭＬがプロキシサーバ２０５にキャッシュされているか否かを判定する。その判定結果、キャッシュされているなら（処理６０６）に進み、取得したＵＲＬがＵＲＬリスト２１０に登録済みか否かを判別する。
【００６４】
（処理６０６）では、ＵＲＬが既に登録済みであると判定された場合、（処理６０７）に進み、取得したＵＲＬを、リストの最後に追加する。
【００６５】
（処理６０５）でプロキシサーバ２０５にＨＴＭＬがキャッシュされていない場合、または（処理６０６）でＵＲＬが未登録と判定された場合は、（処理６０８）へ進む。
【００６６】
（処理６０８）では、ユーザが現在指定している要素のＵＲＬのＨＴＭＬ内に、まだリンクが存在するか否かを判定し、存在する場合は（処理６０９）に進み、次のリンク先のＵＲＬを取得した後（処理６０５）へ戻る。そして、（処理６０５）から（処理６０８）を繰り返す。
【００６７】
前記（処理６０８）において、リンクが存在しない場合は、（処理６１０）に進み、現在指定しているＵＲＬリストの要素の次の要素が存在しているかどうかを判定する。ここで、存在していると判断された場合、（処理６１１）と（処理６０９）に進む。
【００６８】
（処理６１１）により、ユーザが現在指定している要素の次の要素のＵＲＬのＨＴＭＬを取得し、（処理６０８）を実行し、（処理６０９）により次のリンク先のＵＲＬを取得した後（処理６０５）へ戻る。そして、（処理６０５）から（処理６０８）を繰り返す。
【００６９】
前記（処理６１０）において、現在指定しているＵＲＬリストの要素の次の要素が存在しているかどうかを判定した結果、次の要素が存在しないと判断された場合、ＵＲＬ取得処理に係るプログラムの実行を終了する。
【００７０】
これまでのＵＲＬ取得処理により、（処理６０２）で指定したルートＵＲＬを親とするＵＲＬが取得される。つまり、ルートＵＲＬに紐付くプロキシサーバ２０５にキャッシュされたＷｅｂアプリケーションシステム２０２のＨＴＭＬのＵＲＬが全て取得されることになる。
【００７１】
次に、ＵＲＬ先の画面のイメージをキャプチャーする機能と取得した画面イメージ８０１を適宜に変換して、保存する機能が必要となる。以下、取得したＵＲＬリスト２１０のそれぞれに相当する画面をキャプチャーする処理と画面イメージ８０１の変換処理について説明する。
【００７２】
図７は、画面イメージキャプチャー処理と画面イメージ変換処理の詳細を示した図である。図７に示す、（処理７０１）において、巡回型画面キャプチャー処理は、イメージキャプチャー機能２０６と画像変換ツール２０７により実行される。これらもプログラムの実行により処理される。まず、ＵＲＬリスト２１０内の第０要素から最後の要素まで昇順にＵＲＬを取得していく。
【００７３】
（処理７０２）では、取得したＵＲＬからＨＴＭＬを取得し、画面イメージキャプチャー機能２０６で、画面イメージ８０１をキャプチャーする。
【００７４】
（処理７０３）では、キャプチャーされた画面イメージ８０１を、画像変換ツール２０７に渡す。
【００７５】
（処理７０４）では、渡された画面イメージ８０１を、画面イメージ変換ツール２０７により、処理６０１で設定した情報に従ってサイズやファイル形式を変換する（図２の処理２１３参照）。
【００７６】
（処理７０５）では、変換されたファイルを、ユーザが任意に定めたイメージ保存ディレクトリ２０３に、ＨＴＭＬのファイル名をイメージのファイル名として保存する（図2の処理２１4参照）。
【００７７】
（処理７０６）では、ＵＲＬリスト２１０（図4参照）から取り出すＵＲＬが最後の要素になるまで（処理７０１〜処理７０５）を繰り返す。
【００７８】
以上の説明からわかるように、本システム２０１によれば、次のような効果がある。
（１）作業者に大きな工数による負担を強いていた従来の手作業による画面イメージ作成作業に関し、作業者が「ＷｅｂアプリケーションのルートＵＲＬ」と「作成イメージの条件」を設定するだけで、自動的に処理が実行される。そのため、作業者に必須の工数は設定のみに軽減され、大幅に工数とコストを削減することができる。
【００７９】
（２）手作業により画面イメージを作成していた従来の手作業による画面イメージ作成においては、複数の作業者が分担して作業を行うため、「表示するブラウザ、およびイメージサイズ、ファイル形式、ファイル名、フォントやフォントサイズ等の表示設定」等の統一が困難であり、その統一のための取り決めである生成規則等を設け、作業者相互間の意識合わせを図る必要があったという欠点を解消できる。
【００８０】
すなわち、本システム２０１では、複数の作業者や複数のツールを必要とせず、１ユーザ１ツールによる画面イメージ作成が一括でできるようになるため、「イメージファイルの命名規則」や「画像イメージの書式・サイズ」の統一が容易になる。
【００８１】
また、必要な画面イメージを作成する時間が、従来の作業に比べ削減でき、工数を減少させ、生産性を向上させる。つまり、従来必要だった画面遷移、画面キャプチャー作業および、画像変換作業のうち、画面遷移に係る操作と僅かな設定作業だけで、画面イメージ作成が可能となる。
【００８２】
要するに、本システム２０１によれば、大幅な工数削減、生産性向上効果を得ることができるのである。特に、大規模なシステムでは、さらなる効果を発揮できる。
【図面の簡単な説明】
【００８３】
【図１】一般的な画面イメージ作成作業のシーケンス図である。
【図２】実施形態を示すシステム構成図である。
【図３】一般的なＷｅｂアプリケーションシステムの構成図である。
【図４】実施形態で使用されるＵＲＬリストによるデータ構造図。
【図５】実施形態の全体的な処理の概略を示すフローチャートである。
【図６】実施形態におけるＵＲＬ取得処理の詳細を示すフローチャートである。
【図７】実施形態における画面キャプチャー処理、および画面イメージ変換処理の詳細を示すフローチャートである。
【図８】実際の画面イメージ図と、それを簡略化した画面サンプル図である。
【符号の説明】
【００８４】
１０１  開発者
１０２  ブラウザ
１０３  Ｗｅｂアプリケーションシステム
１１０  画像変換ツール
１１４  イメージ保存ディレクトリ
２０１  巡回型画面チャプチャーシステム（本システム）
２０２  Ｗｅｂアプリケーションシステム
２０３  イメージ保存ディレクトリ
２０４  ＵＲＬ巡回機能
２０５  プロキシサーバ
２０６  イメージキャプチャー
２０７  画像変換ツール
３０１  ルートＵＲＬ
３０５，３０６，３０７  遷移先
８０１  （実際の）画面イメージ
８０２  （ドローソフトで描写した）画面サンプル
【図１】
2008009674.tif 000003
【図２】
2008009674.tif 000004
【図３】
2008009674.tif 000005
【図４】
2008009674.tif 000006
【図５】
2008009674.tif 000007
【図６】
2008009674.tif 000008
【図７】
2008009674.tif 000009
【図８】
2008009674.tif 000010