JP2010079342A - Ｗｅｂアプリケーションの操作手順書生成システム - Google Patents

Abstract

【課題】完成したWebアプリケーションから操作手順書の雛形を自動生成することで、開発者の文書作成のコストを抑えることができるWebアプリケーションの操作手順書生成システムを提供する。
【解決手段】Webアプリケーションの操作手順書生成システム１−１５は、ユーザが、ルートURLを指定すると、ルートURLが示すWebアプリケーションサーバー１−１６のWebアプリケーションの画面にアクセスする手段と、アクセスした画面を引数として画面解析処理を呼び出す手段と、画面解析処理によって、解析対象の画面のHTMLを解析し、画面中に存在する全てのリンク、フォームの情報を取得し、画面情報記憶部に登録する手段と、解析対象の画面をキャプチャし、それを画像ファイルに変換し、画面画像記憶部に保存する手段と、取得したすべてのリンク、フォームについて、アクセス、又は、フォーム送信を行い、画面遷移を行う手段等を備えている。
【選択図】図１

Description

本発明はWebアプリケーションの使用方法をユーザに説明するための操作手順書を生成するためのWebアプリケーションの操作手順書生成システムに関するものである。

企業がビジネスを遂行していく上でWebアプリケーションシステムの重要性がますます高まってきている。近年ではライバル企業に差をつけるために、より短期間・低コストで品質の高いシステムの開発が求められるようになってきた。短期間・低コストでシステムを開発するには、その開発プロセスが非常に重要になってくる。

これまで、システムの開発現場では「ウォーターフォール型開発手法」がよく用いられていた。これは、最初に要件定義を行い、外部仕様書、詳細仕様書を定義し、すべての仕様書が完成した時点で実際のプログラムを開発、テストする、という開発手法である。プログラムを開発する時点で既にこれから開発するべきプログラムの詳細な仕様が決定しているため、仕様漏れやミスを防ぐことができ、効率よく開発ができる。

しかしウォーターフォール型開発手法は、仕様書がすべて完成しなければプログラムの実装を行うことができないという特徴がある。仕様書の作成には多大な時間と労力がかかり、これでは短期間・低コストでシステムを開発することは困難になってくる。そこで近年注目されているのが「アジャイルソフトウェア開発」である。これは、より高速にソフトウェアを開発するための開発手法の総称である。たとえばアジャイルソフトウェア開発の具体的な手法のひとつである「エクストリーム・プログラミング」では、2〜4週間という短い期間で設計、実装、テスト、リリースを行い、それを何度も繰り返すことによって開発を進める。これにより早い段階で実際に動作するソフトウェアを利用者に提供することができ、また利用者からの声を開発に即座にフィードバックすることで、より品質の高いソフトウェアを開発することが可能となる。またアジャイル開発では、仕様書をたくさん書くよりも、実際に動くソフトウェアを作り、フィードバックを受けて繰り返し改善して行く、という基本的な考え方がある。そのため、ウォーターフォール型開発に比べて作成する仕様書などの文書の数は大幅に減る。

しかし、作成する文書が少ないために、システムの保守が困難になってしまうと言う問題も指摘されている。たとえば設計文書が少ないために、システムに障害が発生した際に保守担当者が問題の原因を特定することが困難になってしまう場合がある。また、システムそのものの使い方を記述した利用手順書（マニュアル）が無いために、システムの利用者や管理者がシステムを使用できない、という状態にもなりえる。

このような問題を解決するには、いかに開発者の文書作成の負荷を減らすかという点が重要になってくる。その解決方法のひとつとして、既に完成したWebアプリケーションから操作手順書を自動生成して、文書作成にかかる手間を省く方法が提案されている。特許文献１では、あらかじめ手作業でWebアプリケーションの画面に対応するURLを登録しておくことで、自動的にWebアプリケーションの画面ショットを画像ファイルとして保存する機能を有するシステムについて述べたものである。これにより、操作手順書などを作成するときに必要となるWebアプリケーションの画面ショット画像を簡単に用意することが可能となる。

特開２００８−９６７４号公報

しかし特許文献１で言及している方法は画面ショット画像を作成することだけに特化しており、操作手順書自体は、依然として手作業で作成する必要がある。また、あらかじめ画面ショットを撮影したい画面のURLを指定しておく必要があるため、Webアプリケーションの画面数が膨大になった場合にはURLの指定作業に多大なコストがかかってしまう。

以上の現状に鑑み、本発明は、完成したWebアプリケーションから操作手順書の雛形を自動生成することで、開発者の文書作成のコストを抑えることができるWebアプリケーションの操作手順書生成システムを提供することを目的とする。

上記の課題を解決すべく、本発明は以下の構成を提供する。
請求項１に係る発明は、操作手順書の生成の対象となるWebアプリケーションが稼動しているWebアプリケーションサーバーにネットワークを介して通信自在に接続される電子計算機に搭載されるWebアプリケーションの操作手順書生成システムであって、
前記Webアプリケーションの操作手順書生成システムは、画面遷移、画面の構成などの画面情報を記憶する画面情報記憶部と、
画像ファイルを記憶する画面画像記憶部と、
操作手順書を作成するためのシナリオフローの情報を記憶するシナリオフロー記憶部と、
操作手順書テンプレートを記憶する操作手順書テンプレート記憶部と、
ユーザが、WebアプリケーションのルートURLを指定すると、ルートURLが示す前記WebアプリケーションサーバーのWebアプリケーションの画面にアクセスする手段と、
アクセスした画面を引数として画面解析処理を呼び出す手段と、
画面解析処理によって、解析対象の画面のHTMLを解析し、画面中に存在する全てのリンク、フォームの情報を取得し、前記画面情報記憶部に登録する手段と、
解析対象の画面をキャプチャし、それを画像ファイルに変換し、前記画面画像記憶部に保存する手段と、
取得したすべてのリンク、フォームについて、リンクであればリンク先にアクセスし、フォームであればフォーム送信を行い、画面遷移を行う手段と、
画面遷移を行った結果、HTTPリダイレクト応答を受け取ったかどうか判定する手段と、
HTTPリダイレクト応答を受け取った場合は、リダイレクト先のパスを前記画面情報記憶部に登録し、さらにリダイレクト先のパスに遷移する手段と、
遷移先の画面についての画面情報が、前記画面情報記憶部に登録されているかどうかをチェックする手段と、
遷移先の画面についての画面情報が、前記画面情報記憶部に登録されていなければ、遷移先の画面を解析対象の画面として、前記画面解析処理を再帰的に呼び出し、画面中に含まれるリンクを辿り、Webアプリケーションを構成する全ての画面情報及び画面画像を取得する手段と、
前記画面情報記憶部に登録されたリンクやフォームの情報について、それらの画面要素を強調するような画像を作成し、前記画面画像記憶部に保存する手段と、
画面解析処理によって画面情報記憶部、画面画像記憶部に蓄積された情報を使って画面遷移図を作成する手段と、
前記画面遷移図を参照してユーザ操作によって予め作成されたシナリオフロー情報を前記シナリオフロー記憶部から１レコードずつ取得する手段と、
前記操作手順書テンプレート記憶部から取得した操作手順書テンプレートに、シナリオフロー情報のシナリオ名を埋め込む手段と、
前記操作手順書テンプレートに、シナリオフロー情報のレコードの項番を埋め込む手段と、
前記操作手順書テンプレートに、操作手順メッセージを埋め込む手段と、
取得したレコードが、シナリオフロー情報の最後のレコードかどうか判定する手段と、
最後のレコードでない場合は、シナリオフローのレコードの「遷移実行画像」が示す画面ショット画像を、前記操作手順書テンプレートに埋め込む手段と、
最後のレコードである場合は、シナリオフローのレコードの「リンク元画像」が示す画面ショット画像を、前記操作手順書テンプレートに埋め込む手段と、
前記操作手順書テンプレートを操作手順書として出力する手段とを備えることを特徴とするWebアプリケーションの操作手順書生成システムを提供するものである。

本発明のWebアプリケーションの操作手順書生成システムによれば、次のような効果がある。
（１）
本システムによって自動生成される画面遷移図上で、操作手順書を作成したい範囲を選択するだけで、操作手順書の雛形が自動生成されるため、操作手順書の作成コストを大幅に減らすことができる。
（２）
生成される操作手順書に挿入される画面ショット画像には、操作手順を示すためのマークが追加描画されるので、開発者が画像を編集する手間を省くことができ、かつ利用者にとってより分かりやすい操作手順書を提供できる。

以下、実施例を示した図面を参照しつつ本発明の実施の形態を説明する。
尚、上記各手段は、電子計算機のＣＰＵが必要なコンピュータプログラムを読み込んで実行することにより実現される手段であり、そのフローチャートが図３，図４，図１４である。
図１は本発明で提案する操作手順書生成システムと、操作手順書生成システムを動作させるための関連システムとから成る全体構成を示したものである。操作手順書生成システム（１−１５）は、一般的な電子計算機（１−１４）上に搭載され、動作するプログラム群である。電子計算機（１−１４）にはディスプレイやキーボードなどの入出力装置（１−１０）が接続されており、さらにLAN・インターネット等のネットワーク（１−１３）に接続されている。電子計算機（１−１４）はネットワーク（１−１３）を通じてWebアプリケーションサーバー（１−１６）に接続されている。Webアプリケーションサーバー（１−１６）上では、操作手順書の生成の対象となるWebアプリケーション（１−２）が稼動している。アプリケーションログ（１−１）は、Webアプリケーション（１−２）の動作状況が記録されたファイルである。例えばWebアプリケーション（１−２）に対するリクエストがあると、リクエストがあった時刻、リクエストされたURL、送信されたリクエストパラメータ、等がアプリケーションログ（１−１）に記録される。本発明が前提としているアジャイルソフトウェア開発では、前に述べたように短い期間の間に頻繁にリリース作業を行う。リリースされたWebアプリケーション（１−２）は実際に顧客に使用される。そのためアプリケーションログ（１−１）には十分な量のログが出力されていることを前提とする。
電子計算機（１−１４）はネットワーク（１−１３）を通じてWebアプリケーションサーバー（１−１６）に接続されているため、Webアプリケーション（１−２）へのアクセスや、アプリケーションログ（１−１）の読み込みが可能となる。
また、電子計算機（１−１４）は記憶装置を備え、記憶装置はデータベースから成る後述する記憶部１−４〜１−７を格納する。

本システムを用いて操作手順書を生成するには、まず画面遷移図生成部（１−３）がWebアプリケーション（１−２）にアクセスし、その画面遷移、画面の構成などの情報を画面情報として取得し、それを画面情報記憶部（１−４）に記憶する。画面遷移図生成部（１−３）は、画面上のリンクを次から次へと辿り、Webアプリケーション（１−２）のすべての画面の情報を取得する。画面の情報を取得する際、同時にWebアプリケーション（１−２）の画面をキャプチャし、画像ファイルとして画面画像記憶部（１−５）に保持しておく。Webアプリケーション（１−２）の画面内に、ユーザからの入力を受け付ける画面要素（HTMLのinputタグなど）がある場合は、アプリケーションログ（１−１）を読み込み、そこから過去に入力された情報を得て、画面情報を取得する際に利用する。このようにして収集した画面情報、画面画像を組み合わせて、画面遷移図（１−９）を作成し、入出力装置（１−１０）上に表示する。

次にユーザ（１−１１）は、画面遷移図を見て、操作手順書を作成したいシナリオフローを入力する。入力したシナリオフローの情報は、シナリオフロー記憶部（１−６）に記憶される。すると、操作手順書生成部（１−８）はシナリオフロー記憶部（１−６）からシナリオフローの情報を、操作手順書テンプレート記憶部（１−７）から操作手順書テンプレートを取得し、操作手順書（１−１２）を生成する。生成した手順書は入出力装置（１−１０）に表示される。

ここからは具体的な例として、図2に示す画面遷移をもったWebアプリケーションの操作手順書を生成する手順を説明する。
図２は日記を書いたり、表示したりするWebアプリケーションの画面遷移を示したものである。「トップページ」画面（２−１）がこのWebアプリケーションを利用する際に最初に表示する画面である。このページには「日記を書く」「日記を見る」という２つのリンクが設けられている。「日記を書く」リンクをクリックすると「日記を書く」画面（２−２）が表示される。この画面中の「タイトル」テキストフィールドと「本文」テキストエリアに、日記のタイトルと本文を入力し「確認」ボタンを押す。すると「確認」画面（２−３）が表示され、「日記を書く」画面で入力した日記の内容が再度表示される。ユーザはこの内容が正しいことを確認し「登録」ボタンを押す。すると日記の内容が保存され、日記表示画面（２−５）が表示される。また「トップページ」画面の「日記を見る」リンクをクリックした場合は、「日記一覧」画面（２−４）が表示される。この画面にはいままでに登録した日記が一覧形式で表示される。一覧から任意の日記のタイトルをクリックすると、日記表示画面（２−５）が表示される。以降では、このWebアプリケーションを「日記アプリケーション」と呼ぶ。

なお、確認画面（２−３）から日記表示画面（２−５）への画面遷移はHTTPリダイレクト応答による遷移を含んでいる。HTTPリダイレクト応答とは、HTTPにおけるサーバからの応答の一種であり、URLが変更されたことを通知するためのものである。一般的なWebブラウザでは、HTTPリダイレクト応答を受け取ると、HTTPリダイレクト応答に含まれる「リダイレクト先」のURLに自動的に画面遷移するように動作する。日記アプリケーションにおいては、確認画面中の「登録」ボタンを押すと、「/submit」というパスに対するHTTPリクエストを発行する。すると、リダイレクト先が「/view」であるHTTPリダイレクト応答が返って来る。Webブラウザはこれを認識し、今度は「「/view」に対してHTTPリクエストを発行する。すると今度は日記表示画面のHTMLデータがHTTPレスポンス情報として返って来る。これにより、日記表示画面がWebブラウザに表示される。

図３は画面遷移図生成部の処理内容を示したフローチャートである。
（３−１）まず本システムの利用者は画面遷移図生成部に対してWebアプリケーションのルートURLを指定する。ルートURLとは、Webアプリケーションの開始画面、もしくは基点となる画面のURLのことである。日記アプリケーションの「トップページ」画面のURLがこれに該当する。
（３−２）次に、ルートURLが示すWebアプリケーションの画面にアクセスする。画面遷移図生成部はHTTPクライアントとしての機能を備えている。HTTPクライアントとは、HTTP通信によってインターネットやLAN上のWebページにアクセスし、HTML文書や、文書が参照している画像ファイルなどをやり取りするプログラムのことである。通常我々が使用しているWebブラウザーもHTTPクライアントの一種である。
（３−３）上記処理でアクセスした画面を引数として、画面解析処理を呼び出す。画面解析処理については図４でその詳細を説明する。
（３−４）画面解析処理によって画面情報記憶部、画面画像記憶部に情報が蓄積されるので、それらの情報を使って画面遷移図を作成する。作成手順については図８でその詳細を説明する。

図４は、画面解析処理の処理内容を示したフローチャートである。この処理は引数として、解析対象の画面を取る。たとえば図３の処理では、ルートURLの画面を解析対象の画面としてこの処理を実行している。
（４−１）解析対象の画面のHTMLを解析し、画面中に存在する全てのリンク、フォームの情報を取得し、画面情報記憶部に登録する。画面のHTMLを解析する手法としては、XMLパーサーを用いてHTMLをXMLとして読み込み、DOM（Document Object Model）として扱う方法等がある。DOMツリーからリンク（Aタグ）要素やフォーム(FORMタグ)要素を取得することで、画面中に存在する全てのリンク、フォームの情報を取得することが可能となる。取得した情報を画面情報記憶部に登録する処理の詳細については図５で述べる。
（４−２）解析対象の画面をキャプチャし、それを画像ファイルに変換し、画面画像記憶部に保存する。例えばウィンドウズ（登録商標）を搭載したパーソナルコンピュータであれば、「PrintScreen」というキーを押すことで、現在ディスプレイに表示されている画像を、画像ファイルとして保存することが可能なので、これらの機能を用いて画面キャプチャを行えばよい。
（４−３）さらに上記手順でキャプチャした画像を加工する。（４−１）で画面中に存在するリンクやフォームの情報を全て取得したが、それらの画面要素を強調するような画像を作成する。たとえば画面中にリンクが存在する場合は、リンク部分を赤い枠（例えば操作マーク）で囲み、強調した画面の画像を作成する。作成した画像は、前手順と同じく画面画像記憶部に保存する。これらの処理の詳細は図７で述べる。

（４−４）（４−１）で取得したすべてのリンク、フォームについて、リンクであればリンク先にアクセスし、フォームであればフォーム送信を行い、画面遷移を行う。これを画面中の全てのリンク、フォームについて行う。なお、この処理については図６で詳細な説明を行う。
（４−５）画面遷移を行った結果、HTTPリダイレクト応答を受け取ったかどうか判定する。
（４−６）HTTPリダイレクト応答を受け取った場合は、リダイレクト先のパスを画面情報記憶部に登録し、さらにリダイレクト先のパスに遷移する。この処理の詳細は図５で説明する。
（４−７）遷移先の画面についての画面情報が、画面情報記憶部に登録されているかどうかをチェックする。
（４−８）遷移先の画面についての画面情報が、画面情報記憶部に登録されていなければ、遷移先の画面を解析対象の画面として、画面解析処理を再帰的に呼び出す。
以上のように、画面中に含まれるリンクを次々と辿り、画面解析処理を再帰的に呼び出すことによって、Webアプリケーションを構成する全ての画面情報、画面画像を取得できる。

図５は、画面遷移図生成部が日記アプリケーションを解析し、完了した時点で、画面情報記憶部に登録される情報を示したものである。画面情報記憶部には、ある画面から画面に遷移する情報と、その遷移を行うときの操作内容についての情報と、画面キャプチャ画像のポインタ（後述）を格納する。「リンク元」列（５−１）には各画面のパスを格納する。「リンク先」列（５−２）には各画面から別画面に遷移する際の遷移先のパスを格納する。「リダイレクト先」列（５−３）には画面遷移時にHTTPリダイレクト応答がある場合に、そのリダイレクト先のパスを格納する。「操作」列（５−１０）には、画面遷移時に操作する内容を格納する。
例として、図２のトップページ画面（２−１）を解析する際の処理を説明する。まずトップページ画面のパスは“/”であるため、（５−４）に“/”を登録する。また図４の（４−１）で説明したようにトップページ画面を解析すると「日記を書く」「日記を見る」という二つのリンク要素（Aタグ）が見つかる。そこでリンク先のパスであるAタグのhref属性の値である“/add”、“/list”を（５−５）（５−６）に登録する。なお、図４の（４−５）の判定処理の結果は偽であるため、「リダイレクト先」には何も登録しない。さらに画面遷移時には「日記を書く」「日記を見る」リンクをクリックすればいいので、（５−１１）（５−１２）にそれぞれ、“「日記を書く」リンクをクリック”、“「日記を見る」リンクをクリック”を登録する。
もう一つの例として、図２の確認画面（２−３）を解析する際の処理を説明する。図２の説明でも述べたように、確認画面から日記表示画面（２−５）への画面遷移はリダイレクトによるものである。まず、確認画面のパスである“/confirm”を（５−７）に登録する。また確認画面に含まれるフォームのリクエスト先のパスは“/submit”であるため、それを（５−８）に登録する。次に、図４の（４−５）の判定処理により、HTTPリダイレクト応答に含まれるリダイレクト先パスである“/view”を（５−９）に登録する。また、画面遷移を行うには「確認」ボタンをクリックする必要があるので、（５−１３）に“「確認」ボタンをクリック”を登録する。
このようにして、画面情報記憶部にすべての画面の情報が登録される。

図６は、図４の（４−４）の処理の詳細について説明したものである。（４−４）では画面中の全てのリンク先にアクセス、もしくはフォーム送信して画面遷移を行っている。リンクの場合は、単純にリンク先URLに対してHTTPのGETメソッドを用いてアクセスすればよい。しかしフォームの場合はテキストフィールドやテキストエリアの値を入力した上でHTTPのPOST送信を行う必要がある。テキストフィールドやテキストエリアには適当な値を入力すればよいわけではなく、たとえば日記アプリケーションの日記登録処理であれば、日記のタイトルや日記の本文といった、意味のあるデータをセットする必要がある。そこで、それらの情報をWebアプリケーションが出力するアプリケーションログから取得する。
例えば（６−１）は「日記を書く」画面であるが、この画面には「タイトル」テキストフィールド、「本文」テキストエリア、「確認」ボタンが表示されている。この画面を構成するHTMLの一部を示したものが（６−２）である。
画面遷移図生成部は、（６−２）のHTMLを解析し、「タイトル」テキストフィールドに対応する<input>タグ（６−４）と、「本文」テキストエリアに対応する<textarea>タグ（６−５）を特定する。そして、これらのタグのname属性値がそれぞれ「title」「body」であることを特定する。また、このフォームの送信先パスが「/confirm」であることを特定する（６−３）。

次に画面遷移図生成部は、Webアプリケーションが出力したアプリケーションログを読み込む。（６−６）がアプリケーションログの例である。このログについて、HTTPメソッド名がPOST、かつリクエスト先のパスが「/confirm」、POST送信時のパラメータに「title」「body」を含む、ログのレコードを検索する。
すると（６−７）に示すログのレコードが見つかる。このログのレコードによるとPOST送信時のパラメータのうち「title」パラメータの値は“日記1”、「body」パラメータの値は“これは日記１です・・・”という文字列であることが分かる。
以上により画面遷移図生成部は、「日記を書く」画面において、どのような文字列をテキストフィールド、テキストエリアに設定するべきかを決定することができる。

また、以上の処理によりフォーム送信時にはテキストエリアなどに入力を行う必要があることがわかるので、それを画面情報に追加登録する必要がある。例えば図６におけるHTMLの解析により、「タイトル」テキストフィールド、「本文」テキストエリアに入力を行う必要があることが分かる。次にこれらのタグを識別する識別子を取得する。今回の例では、（６−４）（６−５）より各タグのname属性が識別子として使用できるので、「title」「body」を各タグの識別子とする。これにより、（５−１４）（５−１５）に、“titleテキストフィールドに入力”、“bodyテキストエリアに入力”という情報がセットされる。

図７は、（４−３）の処理の詳細について説明したものである。一般的に、Webアプリケーションの操作手順書において、例えば「トップページ画面中の“日記を書く”リンクをクリックしてください」という説明を行うときに、当該する画面ショット画像を合わせて掲載し、さらにどこをクリックすればよいのかを分かりやすくするために、画面ショット画像内のクリックすべき箇所を赤色の枠で囲むなどして強調して表示することがある。この処理を行うのが（４−３）の処理である。例えば（７−１）に示す「トップページ」画面の場合、「日記を書く」リンクや「日記を見る」リンクをクリックすることを説明するには（７−２）（７−３）に示すような画像を作成して操作手順書中に掲載すればよい。
図４の（４−１）の処理によって、画面中のリンクやフォームを構成するHTMLの要素の位置はわかっているので、画面遷移図生成部は、そのHTML要素のstyle属性にスタイル情報を付加するなどしてクリックすべき箇所を赤色の枠で強調表示させる。（７−４）はその例である。このようにして強調表示を追加した画面に対して、図４の（４−２）と同様に画面キャプチャ処理を行い、画面ショット画像ファイルとして画面画像記憶部に保存する。

また、（７−５）は、画面情報記憶部に格納されている画面情報の一部を示したものである。ここで画面情報と画面ショット画像の関連付けを行う。画面情報の「リンク元画像」「遷移操作画像」に、（４−２）（４−３）の処理で作成した画像ファイルのポインタを登録することで関連付けを行う。
例えば、（７−１）の画像は、（７−６）（７−７）に関連付けられる。また（７−２）の画像は（７−８）に、（７−３）の画像は（７−９）に関連付けられる。
上記の関連付け処理を全ての画像ファイルについて行う。

図８は、画面遷移図生成部によって蓄積された画面情報と画面画像から、画面遷移図を生成する様子を示したものである。画面遷移図生成部は、まず画面情報記憶部（８−１）に蓄積された情報から、Webアプリケーションの全体の画面遷移を再構成する。
たとえば画面情報記憶部の（８−３）（８−４）（８−５）の関係から、「トップページ」画面（８−２）から、「日記を書く」画面（８−６）と「日記一覧」画面（８−７）にリンクが張られていることが分かる。そこで、（８−１８）（８−１９）のポインタが示す画像ファイルを画面画像記憶部（８−８）から取得し、それぞれ画面遷移図上に描画する。次に、「トップページ」画面から「日記を書く」画面、「日記一覧」画面に向けて、（８―９）（８−１０）に示すような矢印線を画面遷移図上に描画する。
また、（８−１３）（８−１４）（８−１５）の関係から、リダイレクト処理による画面遷移が発生していることがわかるため、（８−２１）（８−２０）のポインタが示す、「確認」画面（８−１１）と、日記表示画面（８−１２）画面の画像と、それらを結ぶ矢印線（８−１６）を、それぞれ画面遷移図上に描画する。
このような処理を画面情報記憶部に登録されている情報すべてに対して行った結果、（８−１７）に示すような図が完成する。
ここまでが、画面遷移図生成部の処理の詳細である。

図９は、画面遷移図が入出力装置に表示される様子を示したものである。ユーザはこの画面をみて、Webアプリケーションの画面遷移を確認することができる。ユーザは入出力装置を使って、画面上に表示されたポインタ（９−１）を操作し、画面遷移図上の各画面を選択し、操作手順書を生成したい画面遷移の順序、範囲を指定する。

図１０は、ユーザがポインタを使用して、操作手順書を生成したい画面遷移の順序、範囲を指定した様子を示したものである。この例では、ユーザは「日記を書くための手順書を生成したい」と考え、「トップページ」画面（１０−１）、「日記を書く」画面（１０−２）、「確認」画面（１０−３）、日記表示画面（１０−４）、の順番に選択した様子を示している。すると図に示すとおり、選択した画面とそれぞれの画面の間の矢印が強調表示される。

なお、ここで指定した画面遷移に対応する画面情報は、シナリオフロー記憶部にコピーされる。たとえば、図１０のように画面遷移を指定すると、（5−１６）（５−１７）（５−１８）（５−１９）のレコードが、シナリオフロー記憶部に登録される。シナリオフロー記憶部に登録される情報の詳細については図１２で説明する。
ユーザは画面の選択が完了したら「生成」ボタン（８−５）を押す。すると「シナリオ名の指定」ダイアログボックスが表示される。

図１１は、「シナリオ名の指定」ダイアログボックス（１１−１）が表示される様子を示したものである。ユーザは指定した画面遷移に対してシナリオ名をつけて、それをダイアログボックスの入力欄（１１−２）に入力する。ここで指定したシナリオ名は、生成される操作手順書の見出し文字列として使用される。図では「日記の作成・登録」というシナリオ名を入力している。このシナリオ名は、シナリオフロー記憶部に保存される。
最後に「OK」ボタン（１１−３）を押すことで、操作手順書が生成される。
操作手順書は、操作手順書テンプレート記憶部に格納されているテンプレートに、シナリオフロー記憶部に保存された情報を埋め込むことで生成する。

図１２は、図１０、図１１における操作によって、シナリオフロー記憶部に登録された情報を示している。各レコードは画面情報記憶部に登録されたレコードを、項番を付加してコピーしたものである。この情報に沿って、操作手順書が生成されることになる。

図１３は操作手順書テンプレートの一例を示したものである。テンプレートの生成方法は本発明では特に限定していない。図１３で例示しているテンプレートは、｛
｝で囲まれた範囲がプログラムによって任意の文字列に置き換えられる、というものである。

図１４が操作手順書テンプレートの生成処理の手順である。
（１４−１）ユーザ操作によって作成されたシナリオフロー情報を１レコードずつ取得する。
（１４−２）テンプレートに、シナリオフローのシナリオ名を埋め込む。例えば（１２−１）が示す文字列を、（１３−１）の箇所に埋め込む。
（１４−３）テンプレートに、シナリオフローのレコードの項番を埋め込む。例えば（１２−２）列に登録された番号を、（１３−２）の箇所に埋め込む。
（１４−４）テンプレートに、操作手順メッセージを埋め込む。操作手順メッセージについては図１５で説明する。例えば（１３−３）の箇所に操作手順メッセージを埋め込む。
（１４−５）（１４−１）で取得したレコードが、シナリオフローのレコードが最後のレコードかどうか判定する。例えば（１４−１）で取得したレコードが、（１２−３）のレコードと等しいかどうか判定する。
（１４−６）（１４−５）の判定結果が偽の場合は、シナリオフローのレコードの「遷移実行画像」が示す画面ショット画像を、テンプレートに埋め込む。例えば（１２−４）列に登録されているポインタが示す画像を、（１３−４）の箇所に埋め込む。
（１４−７）（１４−５）の判定結果が真の場合は、シナリオフローのレコードの「リンク元画像」が示す画面ショット画像を、テンプレートに埋め込む。例えば（１２−５）列に登録されているポインタが示す画像を、（１３−４）の箇所に埋め込む。
（１４−８）最後にテンプレートを、操作手順書として出力する。図１６〜図１９がその出力例である。

図１５は、（１４−４）の操作手順メッセージ埋め込み処理について説明する図である。操作手順メッセージは、シナリオフロー情報の「操作」列に記述されている内容に対応するメッセージを、（１５−１）に示すテーブルから取得する。たとえば、（１２−６）には、（１５−２）のメッセージが対応する。「{アンカーテキスト}」の部分は「日記を書く」に置換される。その結果、（１６−１）のように表示される。また（１２−７）（１２−８）（１２−９）には（１５−３）（１５−４）（１５−５）のメッセージがそれぞれ対応する。「{ボタン名}」「{ id }」は、それぞれ「確認」「title」「body」に置換される。その結果（１７−１）（１７−２）（１７−３）のように表示される。これらのメッセージを箇条書きにまとめたものが、操作手順メッセージとしてテンプレートに埋め込まれる。

本発明によるWebアプリケーションの操作手順書生成システムと、操作手順書生成システムを動作させるための関連システムとから成る全体構成図である。 本発明の一例として用いる日記アプリケーションの画面遷移図である。 本発明の画面遷移図生成部の処理の流れ図である。 本発明の画面解析処理の流れを示す図である。 本発明の画面情報の例を示す図である。 本発明のアプリケーションログからフォーム送信データのサンプルを取得する手順を示す図である。 本発明の画面キャプチャ画像の作成と、画面情報との関連付けの説明図である。 本発明の画面遷移図の構築の説明図である。 本発明の出力装置上に表示された画面遷移図である。 本発明のユーザによりシナリオフローが指定された状態を表示する画面図である。 本発明のユーザによりシナリオフロー名が指定された状態を表示する画面図である。 本発明のシナリオフロー情報の例を示す図である。 本発明の操作手順書のテンプレートの例を示す図である。 本発明の操作手順書生成部の処理の流れを示す図である。 本発明の操作手順メッセージの処理の説明図である。 本発明の生成される操作手順書の例（１）を示す図である。 本発明の生成される操作手順書の例（２）を示す図である。 本発明の生成される操作手順書の例（３）を示す図である。 本発明の生成される操作手順書の例（４）を示す図である。

符号の説明

１−２ Webアプリケーション
１−４ 画面情報記憶部
１−５ 画面画像記憶部
１−６ シナリオフロー記憶部
１−７ 操作手順テンプレート記憶部
１−９ 画面遷移図
１−１１ ユーザ
１−１２ 操作手順書
１−１３ ネットワーク
１−１４ 電子計算機
１−１５ 操作手順書生成システム
１−１６ Webアプリケーションサーバー

Claims (1)

1. 操作手順書の生成の対象となるWebアプリケーションが稼動しているWebアプリケーションサーバーにネットワークを介して通信自在に接続される電子計算機に搭載されるWebアプリケーションの操作手順書生成システムであって、
   前記Webアプリケーションの操作手順書生成システムは、画面遷移、画面の構成などの画面情報を記憶する画面情報記憶部と、
   画像ファイルを記憶する画面画像記憶部と、
   操作手順書を作成するためのシナリオフローの情報を記憶するシナリオフロー記憶部と、
   操作手順書テンプレートを記憶する操作手順書テンプレート記憶部と、
   ユーザが、WebアプリケーションのルートURLを指定すると、ルートURLが示す前記WebアプリケーションサーバーのWebアプリケーションの画面にアクセスする手段と、
   アクセスした画面を引数として画面解析処理を呼び出す手段と、
   画面解析処理によって、解析対象の画面のHTMLを解析し、画面中に存在する全てのリンク、フォームの情報を取得し、前記画面情報記憶部に登録する手段と、
   解析対象の画面をキャプチャし、それを画像ファイルに変換し、前記画面画像記憶部に保存する手段と、
   取得したすべてのリンク、フォームについて、リンクであればリンク先にアクセスし、フォームであればフォーム送信を行い、画面遷移を行う手段と、
   画面遷移を行った結果、HTTPリダイレクト応答を受け取ったかどうか判定する手段と、
   HTTPリダイレクト応答を受け取った場合は、リダイレクト先のパスを前記画面情報記憶部に登録し、さらにリダイレクト先のパスに遷移する手段と、
   遷移先の画面についての画面情報が、前記画面情報記憶部に登録されているかどうかをチェックする手段と、
   遷移先の画面についての画面情報が、前記画面情報記憶部に登録されていなければ、遷移先の画面を解析対象の画面として、前記画面解析処理を再帰的に呼び出し、画面中に含まれるリンクを辿り、Webアプリケーションを構成する全ての画面情報及び画面画像を取得する手段と、
   前記画面情報記憶部に登録されたリンクやフォームの情報について、それらの画面要素を強調するような画像を作成し、前記画面画像記憶部に保存する手段と、
   画面解析処理によって画面情報記憶部、画面画像記憶部に蓄積された情報を使って画面遷移図を作成する手段と、
   前記画面遷移図を参照してユーザ操作によって予め作成されたシナリオフロー情報を前記シナリオフロー記憶部から１レコードずつ取得する手段と、
   前記操作手順書テンプレート記憶部から取得した操作手順書テンプレートに、シナリオフロー情報のシナリオ名を埋め込む手段と、
   前記操作手順書テンプレートに、シナリオフロー情報のレコードの項番を埋め込む手段と、
   前記操作手順書テンプレートに、操作手順メッセージを埋め込む手段と、
   取得したレコードが、シナリオフロー情報の最後のレコードかどうか判定する手段と、
   最後のレコードでない場合は、シナリオフローのレコードの「遷移実行画像」が示す画面ショット画像を、前記操作手順書テンプレートに埋め込む手段と、
   最後のレコードである場合は、シナリオフローのレコードの「リンク元画像」が示す画面ショット画像を、前記操作手順書テンプレートに埋め込む手段と、
   前記操作手順書テンプレートを操作手順書として出力する手段とを備えることを特徴とするWebアプリケーションの操作手順書生成システム。

Images