JP2009064056A - Ｗｅｂアプリケーションのセッション管理処理の設計・実装支援システム - Google Patents

Abstract

【課題】設計、実装が複雑になりがちな、Webアプリケーションのセッション管理処理を支援するシステムを提供する。
【解決手段】画面遷移パターン仕様書の生成、更新を行い、セッション管理処理の設計を支援するセッション情報編集装置と、画面遷移情報XMLファイルからWebアプリケーションのソースコードを生成するソースコード生成装置から構成し、Webアプリケーション画面遷移情報から画面遷移パターン仕様書を生成し、セッション管理処理の設計を支援し、さらに画面遷移パターン仕様書からWebアプリケーションのソースコードを生成する。
【選択図】図１７

Description

本発明は、Webアプリケーションの画面遷移パターン仕様書を操作者が視認しやすいように表示して入力を促し、入力された内容を画面遷移情報XMLファイルに反映することにより、Webアプリケーションのセッション管理処理の設計・実装を支援するシステム技術に関する。

図２６は、Webアプリケーションの動作環境を示す概念図である。インターネット２６０１上に設けられたWebサーバ２６０２上にWebアプリケーションがインストールされて、端末装置２６１１、２６１２、２６１３などからインターネット２６０１を介してWebサーバ２６０２にアクセスすることによりWebアプリケーションが動作する。完成したWebアプリケーションが動作する環境は、図２６に示したとおりであるが、そのWebアプリケーションを開発する途上にあっては、例えば端末装置２６１１を用いて開発者がプログラミングをしてWebアプリケーションを作成する。本発明は、そのようなWebアプリケーションの開発行為、特にセッション管理処理の設計・実装を支援するために、端末装置２６１１にインストールして用いるシステムに関するものである。

図２７は、端末装置２６１１のハードウェア構成を示すブロック図である。ＣＰＵ２７０１のバス２７００上には、ＲＡＭ（ランダムアクセスメモリ）２７０２、ＲＯＭ（リードオンリメモリ）２７０３、ＨＤＤ（ハードディスクドライブ）２７０４、表示回路２７０５、入力信号処理部２７０６、ネットワーク回路部２７０７が接続されている。さらに、表示回路部２７０５には、表示装置２７１５が接続される。表示装置２７１５は、具体的には液晶モニタ装置、ＣＲＴ装置、プラズマディスプレイ装置などのいずれかが用いられる。そして、入力信号処理部２７０６には、マウス２７１２、キーボード２７１１などの入力装置が接続される。端末装置２６１１の操作者は表示装置の画面上に表示される処理内容を視認しつつ、キーボード２７１１とマウス２７１２とを操作して入力し、さらに端末装置２６１１の処理内容が進められる。ネットワーク回路部２７０７は、さらに必要な機器を介してインターネット２６０１につながる。端末装置２６１１で完成されたWebアプリケーションをWebサーバ２６０２にアップロードするためにネットワーク接続が必要となる。また、端末装置２６１１が一つの端末コンピュータとしてWebサーバ２６０２にアクセスするときにも、ネットワーク接続を必要とする。

Webアプリケーションでは、ユーザが操作した内容や、やり取りした情報を、一定期間サーバに保存しておくことでWebアプリケーションの使い勝手を向上させるために、セッション管理の技術がよく使用されている。例えばログイン処理が必要となるWebアプリケーションでは「ログイン処理が完了した」という情報（セッション情報）を一定期間サーバに保持する。これにより、一度ログイン処理を行ってしまえば、それ以降は自由にWebアプリケーションを操作でき、Webアプリケーションの利便性を高めることができる。

セッション管理の実現技術としては（１）HTTPクッキーの使用（２）HTTPセッションの使用、という二つの技術がある。

まずは（１）について説明する。クッキー技術とは、Webアプリケーションを使用する上で永続的に使用される情報（クッキー情報）をクライアントPCに保存しておき、必要に応じてWebブラウザがクッキー情報を読み込むことで、Webアプリケーションの状態を保持するための技術である。

次に（２）について説明する。Webアプリケーションの状態を保持するために、（１）ではクライアント側に情報を保存していたが、（２）ではクライアント側ではなくサーバ側に情報を保持する。Webアプリケーションを動作させるサーバ（アプリケーションサーバ）には、通常「HTTPセッション情報格納領域」と呼ばれる領域が用意されている。（２）の技術では、この領域に、ユーザがやりとりした情報や操作情報（HTTPセッション情報）を格納しておくことで、セッション管理を実現している。

ただし（１）については、クライアント側にセッション情報を保存するという特徴があるため、情報漏えいの問題なども指摘されている。もし当人以外の第三者にクッキーを盗み見された場合、自分になりすましてWebアプリケーションが使用されてしまう可能性がある。そのため、（１）クッキー情報を使うのではなく、（２）のHTTPセッションを使用して、セッション管理を行うことが一般的になっている。

本発明に関連する公知技術文献として特許文献１があげられる。特許文献１には、複数列の条件部と処理部で構成された表形式のプログラム仕様書に記述された分岐制御用の日本語文を抽出して、分岐構造のソースプログラムを生成する技術が開示されている。
特開２００３−２０８３０７号公報

HTTPセッションを使用する場合は、正しいタイミングで、正しいセッション情報をHTTPセッション情報格納領域に格納するように、処理を実装する必要がある。また、セッション情報が不要になった場合は、正しいタイミングで領域から破棄する処理を実装する必要がある。このようなセッションの格納、破棄の処理は、細心の注意を払って実装する必要がある。例えばログイン処理の場合は、ログインが成功した瞬間にログイン済みセッション情報を格納し、ログアウト処理を行った瞬間にログイン済みセッション情報を破棄する必要がある。もしログアウト時にセッション情報を破棄する処理を実装し忘れたり、実装ミスがあったりすると、ユーザがログアウトを行っても実際にはログアウトされずに、ログインの状態を保つことになってしまう。この状態で他人が同じPCを使用した場合、すでにログイン状態にあるため、不正にWebアプリケーションが操作されてしまう危険性がある。また、ログイン情報が破棄されることなく常にHTTPセッション格納領域に保存されることになるので、ユーザ数が多くなればなるほど、保持する情報量が増加し、サーバに対する負荷が高まってしまう、という問題もある。

このように、HTTPセッションの管理は非常に複雑な処理を伴う。セッションで管理する情報が増えれば増えるほど、より管理が複雑になり、開発の難易度が高まってくる。これにより、セッションの格納、破棄の処理の実装にミスが発生してしまい、Webアプリケーションに不具合を作りこんでしまうという問題がある。

本発明の目的は、複雑なセッション管理を必要とするWebアプリケーション開発において、セッション管理処理の設計、実装を支援し、不具合のないWebアプリケーションを開発するためのWebアプリケーション開発支援システムを提供することにある。

上記課題を解決するために、本発明に係るWebアプリケーションのセッション管理処理の設計・実装支援システムは、Webアプリケーションの画面遷移情報をXMLで記述した画面遷移情報XMLファイルに、セッションの登録・破棄に関する情報を追加するセッション情報編集装置と、該セッション情報編集装置が処理した処理結果を表示して操作者が視認可能とする表示装置と、該表示装置の表示画面に表示された処理結果を操作者が見て操作者がコンピュータ入力をする入力装置と、該入力装置により入力された信号を受けて前記セッション情報編集装置の処理内容を編集し、それにより改変された前記画面遷移XMLファイルから、Webアプリケーションのソースコードを生成するソースコード生成装置とからなり、操作者がWebアプリケーションのセッション管理処理の設計・実装をすることを支援するWebアプリケーションのセッション管理処理の設計・実装支援システムであって、前記セッション情報編集装置には、前記画面遷移情報XMLファイルからWebアプリケーションの画面遷移パターンを視覚的に表現した画面遷移パターン仕様書を生成する画面遷移パターン解析手段と、セッション情報の登録・破棄処理に関する情報を、該画面遷移パターン仕様書に追記し更新する、セッション登録・破棄情報更新手段と、セッション保持期間に関する情報を、前記画面遷移パターン仕様書に追記し更新する、セッション保持期間設定手段と、前記画面遷移パターン仕様書に記述された内容を再び画面遷移情報XMLファイルに書き出すセッション情報反映手段を設け、ソースコード生成装置には、更新された画面遷移情報XMLファイルと、生成ソースコードテンプレートファイルとから、Webアプリケーションのソースコードを生成するソースコード生成手段を設けたものである。

本発明に係るWebアプリケーションのセッション管理処理の設計・実装支援システムによれば、次のような効果がある。
（１） 画面遷移パターン仕様書に◎、○、×、形式でセッションの登録・生存・破棄の情報を表示することで、複雑になりがちなセッションの状態を明確に表現できるようになるため、Webアプリケーションの設計時に、セッション管理の設計ミスを防ぐことができる。
（２） 画面遷移パターン仕様書と画面遷移情報XMLファイルから、セッションの登録・破棄処理が実装された状態のWebアプリケーションのソースコードを自動生成できるため、実装忘れなどのミスや不具合の発生を防ぐことができる。

以下に本発明の実施の形態を説明する。

図１は、本発明の一実施例を示すシステム構成図である。本システムは、セッション情報編集装置１０１とソースコード生成装置１０２、生成ソースコードテンプレートファイル１１１から構成される。図１に示す画面遷移情報XMLファイル１０３を、セッション情報編集装置の画面遷移パターン解析手段１０４の入力として与えると、画面遷移パターン仕様書１０５が生成される。本発明に係るWebアプリケーションのセッション管理処理の設計・実装支援システムを操作する開発者１１３は画面遷移情報XMLファイルに対して手作業でセッション情報を入力し（１０６）、再びセッション情報編集装置１０１に入力として与える。するとセッション登録・破棄情報更新手段１０７、セッション保持期間設定手段１０８が作動し、画面遷移パターン仕様書１０５が書き換えられて出力され、表示画面上にも表示される。画面遷移パターン仕様書１０５が完成したら、再びセッション情報編集装置１０１に入力として与える。すると今度はセッション情報反映手段１０９が作動し、画面遷移パターン仕様書１０５に記述された内容を元に、元々の画面遷移情報XMLファイル１０３が書き換えられ、出力される。最後に、ソースコード生成装置１０２のソースコード生成手段１１０に、画面遷移情報XMLファイル１０３と、生成ソースコードテンプレートファイル１１１を入力として与えることで、ソースコード１１２が生成される。図１において、「手段」と書いたものは、具体的には、図２７に示すＣＰＵ２７０１が、ＨＤＤ２７０４にあらかじめ記憶されているプログラムを読み込んで、それを実行することにより、実現するものである。実行するプログラムについては、それぞれその内容をフローチャートに示して後述する。

次に各構成要素の詳細を、手順を追って説明する。

まず、説明をわかりやすくするために、図２に示すような画面遷移をもつWebアプリケーションを実装することを想定する。図２は、Webアプリケーションの全体の機能のうち、何らかの情報の登録を行う機能（登録機能）についての画面遷移を抜粋したものである。まずこのWebアプリケーションのユーザ（このWebアプリケーションが完成した際に、ユーザとなるであろう端末からのアクセスする人）は、メニュー画面２０１を表示する。次に、メニュー画面から登録画面２０３に移動し、登録したい情報を入力する。これは、たとえば「ユーザ会員の情報」や「社員情報」などである。登録情報の入力が完了したら確認画面２０６に移動する。この画面では入力した登録情報が再表示され、内容が正しいいかどうかの確認を行う。もし内容に間違いがあれば、登録画面に戻ることもできる。内容に問題がなければ、完了画面２０８に移動することで、登録が完了する。最後にメニュー画面に戻ることで、一連の登録機能が完了する。

通常のWebアプリケーションでは、ある画面からある画面に遷移する際に何らかの処理が実行される。本明細書ではこれを「イベント」と呼ぶ。たとえば、メニュー画面２０１から登録画面２０３に遷移する場合は、「登録画面へ」イベント２０１が実行される。

図２では、四角形で画面を、角丸四角形でイベントを表している。四角形の上半分には「画面ID」と呼ばれる画面を一意に識別するIDが、下半分には「画面名」が記述されている。たとえば、メニュー画面２０１の場合は、画面IDが「menu」２０１ａ、画面名が「メニュー画面」２０１ｂである。

また、角丸四角形の上半分にはイベント名、そして下半分にはそのアクションの実体である「アクションクラス名」が記述されている。アクションクラスとは、あるイベントが発生したときに、実際に処理を行うクラスである。たとえば「登録画面へ」イベント２０２の場合は、イベント名が「登録画面へ」２１０、アクションクラス名が「InsertAction」２１１であり、「登録画面へ」イベント発生時には、「InsertAction」アクションクラスが動作することを示している。なお、「登録画面へ」イベント２０２と、「戻る」イベント２０５は、イベントは異なるが、アクションクラスは同じく「InsertAction」である。

各アクションクラスの内部では、画面遷移の制御のほかにもさまざまな処理が実行される。たとえばFinishActionクラス２０７であれば、登録情報をデータベースに登録する、などといった処理が実行される。そして、本発明のポイントであるセッション情報の登録、破棄処理も、このアクションクラス内で行われる。

図２で示すWebアプリケーションでは、登録画面（３）で入力された情報を、ConfirmActionクラス（４）が受け取り、その情報をセッション領域に登録する。そして遷移先の確認画面（６）では、セッション領域に登録された登録情報を、画面上に表示する。確認が完了するとFinishActionクラス（７）が呼び出され、完了画面（８）への遷移が行われる。FinishActionクラスでは、セッション領域から登録情報を取り出して、それをデータベースに登録する。登録が完了すると完了画面が表示される。この画面にもセッションに格納された登録情報が表示される。この時点で、データの登録が完了し、セッション領域に登録された登録は不要となる。そこで、メニュー画面に遷移する際に実行されるMenuActionクラス（９）の内部では、セッション領域から登録情報を破棄する処理が実行される。一方、確認画面（６）から登録画面（３）に戻る際にも、InsertActionクラス内（５）で、セッション領域から登録情報を破棄している。

以上のように、開発者はアクションクラス内でセッションの登録、破棄処理を実装することになる。このとき、登録・破棄をどのアクションクラスで実行するか、ということが非常に重要になってくる。たとえばConfirmActionクラス２０４内で、登録情報をセッションに登録する処理を実装し忘れてしまうと、途端に一連の登録処理は機能しなくなる。このようにセッション登録・破棄処理の設計、実装には細心の注意が必要となる。

図３は、図２に示した画面遷移とアクションの関係を、XML形式で表現したものであり、これを「画面遷移情報XMLファイル」と呼ぶ。画面遷移情報XMLファイルは、Webアプリケーションの設計に基づいて手作業で記述したり、Microsoft Visio（米国マイクロソフト社の商標）などのエディタを使用して画面遷移図を描画し、そのデータを画面遷移情報XMLファイルに変換することにより作成できる。

画面遷移情報XMLは、＜pageflow＞要素３０１をルートとしたXMLデータである。その子要素には、すべてのページ（画面）情報をあらわす＜pages＞要素３０２と、すべてのアクションをあらわす＜actions＞要素３０３が定義されている。

＜pages＞要素の子要素には、各画面をあらわす＜page＞要素が画面数分、定義されている。たとえば、３０４では、画面IDが「menu」、画面名が「メニュー画面」である画面情報が定義されている。なお、すべての＜page＞要素の内ひとつだけ、Webアプリケーションの開始画面を意味する属性である、startpage属性を定義できる。３０４ではメニュー画面ページの要素にstartpage="true"が記述されているため、メニュー画面を、このWebアプリケーションの開始画面であるとみなすことができる。また、各＜page＞要素の子要素には、その画面から他の画面へ遷移する際に発生するイベントを示す、＜event＞要素が定義される。＜event＞要素には、イベント名を示すdesc属性と、そのイベントに関連づくアクションクラス名を示すaction属性がある。たとえば３０５では、アクションクラスが「InsertAction」、イベント名が「登録画面へ」であるイベントを表している。

＜actions＞要素の子要素には、各画面間のアクションをしめす＜action＞要素を定義する。＜action＞要素にはアクションクラス名を示すname属性と、そのアクションが実行された後の遷移先画面の画面IDを示すforward属性を定義する。なお、このname属性と、＜event＞要素のaction属性は対応している。たとえば、３０６は、アクションクラス名が「InsertAction」で、遷移先画面IDが「insert」であるアクションをあらわしており、これは３０５に示すイベントに関連づいている。つまり、３０５のイベント発生時に、３０６のアクションが実行される、ということである。

以上のような画面遷移XMLファイルが準備できたら、それを図１のセッション情報編集装置１０１の画面遷移パターン解析手段１０４に入力情報として与える。すると、図４に示すような画面遷移パターン仕様書が生成される。

この仕様書は、対象となるWebアプリケーションのすべての画面遷移を解析し、開始画面を基点に、想定されるすべての画面遷移を表形式で示したものである。たとえば、仕様書４Ａは、「メニュー画面→登録画面→確認画面という画面遷移を行い、戻るイベントにより登録画面に戻る」という画面遷移パターンを示す表である。この表のヘッダ部分には、「メニュー画面」→「登録画面へ」イベント→「登録画面」→「確認画面へ」イベント→「確認画面」→「戻る」イベント→「登録画面」、といったように、一連の画面とイベントの流れが示されている。一方で、仕様書４Ｂでは、「確認画面」で「戻る」イベントではなく、「確定」イベントが発生し、→「完了画面」→「メニューへ」イベント→「メニュー画面」、という画面遷移のパターンを示している。

図５は、図４の画面遷移パターンを矢印で画面遷移図にマッピングしたものである。図５の５Ａ、５Ｂが、それぞれ図４の４Ａ、４Ｂのパターンに対応する。

図６から図１３は、この画面遷移パターン解析手段１０４により、画面遷移パターン仕様書を生成する処理の流れを説明する。

図６は、画面遷移パターン解析手段１０４が行う処理の概要を示すフローチャートである。この処理の流れについて説明する。
（ステップ６０１）：まず、画面遷移パターンの解析時に一時的に使用する記憶領域として「解析スタック」を初期化する。これはスタック構造をもつデータ領域である。
（ステップ６０２）：さらに、画面遷移のパターンの解析結果を一時的に記憶する領域として「解析結果リスト」を初期化する。これはリスト構造のデータ領域である。
（ステップ６０３）：次に、画面遷移パターン解析手段に入力として与えられた画面遷移情報ＸＭＬファイルを読み込み、ＤＯＭオブジェクトとしてメモリ中に読み込む。ＤＯＭとは、XMLデータのためのＡＰＩであり、ＸＭＬファイルの内容をＤＯＭオブジェクトとしてメモリ中に読み込むことで、ＸＭＬのデータ構造のナビゲートや要素の取得、追加、削除を容易におこなうことができる。ＤＯＭオブジェクトをメモリ中に読み込む処理については、JAXP(Java API for XML Processing 「Java」は、米国サン・マイクロシステムズ社の登録商標。)など、すでに一般的な手法が知られているため説明は割愛する。
（ステップ６０４）：ＤＯＭオブジェクトが準備できたら、それを引数として「開始ページ要素取得処理」を呼び出す。これにより、画面遷移情報ＸＭＬから、属性startpageを持つ＜page＞要素のＤＯＭオブジェクト（以降、開始ページオブジェクトと表記する）を取得できる（詳細は後述）。
（ステップ６０５）：次に、取得した開始ページオブジェクトと、ＤＯＭオブジェクトを引数として、「画面遷移解析処理」を呼び出す。これにより、画面遷移情報ＸＭＬファイルが解析され、図６の（２）で初期化した解析結果リストに、その解析結果が格納される（詳細は後述）。
（ステップ６０６）：最後に、解析結果リストを引数として、画面遷移パターン仕様書生成呼び出しを行う。これにより、画面遷移パターン仕様書が生成される（詳細は後述）。

次に、図６のフローチャート内で呼び出している各処理の詳細を説明する。

図７は、図６のステップ６０４で呼び出している「開始ページ要素取得処理」の処理の流れを示すフローチャートである。
（ステップ７０１）：まず、ＤＯＭオブジェクトを読み込み、すべての＜page＞オブジェクトをひとつずつ取得する。すべての＜page＞オブジェクトの取得が完了したらループを抜ける。
（ステップ７０２）：次に、取得した＜page＞オブジェクトのstartpage属性を評価する。startpage属性がtrueであればステップ７０３を実行する。falseであればステップ７０１に戻りループする。
（ステップ７０３）：（ステップ７０１）で取得した＜page＞オブジェクトをリターンし、処理を終了する。
以上の処理により、開始ページのオブジェクトを取得できる。

図８は、図６のステップ６０５で呼び出している「画面遷移処理」の処理の流れを示すフローチャートである。
（ステップ８０１）：まず、引数として渡された＜page＞オブジェクトを、解析スタックにプッシュする。１回目の呼び出し（画面遷移パターン解析処理からの呼び出し）では、引数の＜page＞オブジェクトは、図６のステップ６０４で取得した、開始ページの＜page＞オブジェクトである。
（ステップ８０２）：次に、引数の＜page＞オブジェクトの子要素である＜event＞オブジェクトをひとつずつ取得する。＜event＞オブジェクトをすべて取得済みの場合はループを抜ける。
（ステップ８０３）：次に、ステップ８０２で取得した＜event＞オブジェクトを解析スタックにプッシュする。
（ステップ８０４）：次に、ステップ８０２で取得した＜event＞オブジェクトと、ＤＯＭオブジェクトを引数として「action要素取得処理」を呼び出す。これにより、すべての＜action＞オブジェクトのうちname属性が、引数として受け取った＜event＞オブジェクトのaction属性に等しいものが取得できる。
（ステップ８０５）：次に、ステップ８０４で取得した＜action＞オブジェクトと、ＤＯＭオブジェクトを引数として「遷移先page要素取得処理」を呼び出す。これにより、すべての＜page＞オブジェクトのうちname属性が、引数として受け取った＜action＞オブジェクトのforwad属性に等しいものが取得できる。
（ステップ８０６）：次に、ステップ８０５で取得した＜page＞オブジェクトが子要素として＜event＞オブジェクトを持っているかどうか、もしくは、解析スタックに同一の＜page＞オブジェクトが格納済みでないかをチェックする。子要素として＜event＞オブジェクトを持っていないということは、「遷移先のページは"突き当たりのページ"であり、それ以上画面遷移しない」ということを意味している。また、解析スタックに同一の＜page＞オブジェクトが格納済みということは、「遷移先のページは、これまでの画面遷移ですでに通過済みのページである」ということを意味している。これらの条件のいずれかに合致する場合は、その画面遷移パターンの終端に到達したことを意味するので、ステップ８０８を実行して、ここまでの解析結果を保存する。そうでない場合は、遷移先ページのさらに先に遷移可能なページがあるので、ステップ８０７を実行し、解析を継続する。
（ステップ８０７）：ステップ８０５で取得した遷移先の＜page＞オブジェクトを引数として、画面遷移解析処理を、再帰呼び出しする。これにより、遷移先ページのその先の画面遷移を分析できる。
（ステップ８０８）：リスト構造をもったデータ保存領域「画面遷移リスト」を作成し、これまでに解析スタックに格納された各要素を、その格納順序を守ったままコピーする。
（ステップ８０９）：ステップ８０８で作成した「画面遷移リスト」の末尾に、ステップ８０５で取得した遷移先＜page＞要素を追加する。これにより画面遷移リストには、開始ページからの画面遷移のひとつのパターンが格納されたことになる。ちなみに、画面遷移リストに格納された要素は、＜page＞要素、＜event＞要素、＜page＞要素、＜event＞要素・・・のように、＜page＞要素と＜event＞要素が交互に続き、最後に＜page＞要素で終了するリストになっている。
（ステップ８１０）：ステップ８０９で完成した画面遷移リストを、図６のステップ６０２で初期化した解析結果リストに格納する。つまり、解析結果リストは、リストを要素として持つリスト、ということになる。
（ステップ８１１）：解析スタックをポップし、ステップ８０３でプッシュした＜event＞要素を破棄する。
（ステップ８１２）：引数として与えられた＜page＞オブジェクトの子要素＜event＞オブジェクトについて、評価がすべて完了したら、最後に解析スタックをポップし、ステップ８０１でプッシュした＜page＞要素をスタックから破棄する。
以上の処理により、対象Webアプリケーションのすべての画面遷移のパターンの洗い出しが完了する。

図９は、図８のステップ８０４で呼び出している「action要素取得処理」の処理の流れを示すフローチャートである。
（ステップ９０１）：まず、ＤＯＭオブジェクトを読み込み、すべての＜action＞オブジェクトをひとつずつ取得する。すべて取得したらループを抜ける。
（ステップ９０２）：次に、取得した＜action＞オブジェクトのname属性をチェックする。name属性の値が、引数として与えられた＜event＞オブジェクトのaction属性の値と等しい場合は、ステップ９０３を実行する。そうでない場合は、ステップ９０１に戻り、ループを再開する。
（ステップ９０３）：（ステップ９０１）で取得した＜action＞オブジェクトをリターンし、処理を終了する。

図１０は、図８のステップ８０５で呼び出している「遷移先page要素取得処理」の処理の流れを示すフローチャートである。
（ステップ１００１）：まず、ＤＯＭオブジェクトを読み込み、すべての＜page＞オブジェクトをひとつずつ取得する。すべて取得したらループを抜ける。
（ステップ１００２）：次に、取得した＜page＞オブジェクトのname属性をチェックする。name属性の値が、引数として与えられた＜action＞オブジェクトのforard属性の値と等しい場合はステップ１００３を実行する。そうでない場合は、ステップ１００１に戻り、ループを再開する。
（ステップ１００３）：ステップ１００１で取得した＜page＞オブジェクトをリターンし、処理を終了する。

図１１は、図６のステップ６０５が終了した時点における、解析結果リストの格納データを示したものである。図１１に示すとおり、解析結果リストは、画面遷移のパターンごとに、＜page＞＜event＞オブジェクトが交互に格納された画面遷移リスト（１）（２）を、格納したリスト（３）、という形式になっている。

図１２は、図６の画面遷移パターン解析処理の最後のステップである、画面遷移パターン仕様書生成処理の処理の流れについて記述したフローチャートである。
図１３は、図１２中の「画面遷移パターン仕様書の新規作成処理」「ページ列挿入処理」「イベント列挿入処理」の処理内容を図示したものである。

以下に図１２のフローチャートに示す処理の流れを説明する。
（ステップ１２０１）：引数として渡された解析結果リストから、画面遷移リストをひとつずつ取得する。すべての要素の取得が完了したらループを抜け、処理を終了する。
（ステップ１２０２）：画面遷移パターン仕様書を新規に作成する。本発明では、解析された画面遷移パターンごとに画面遷移パターン仕様書がひとつずつ生成される。ここに示す例では、２つの画面遷移パターン仕様書が生成される。この時点で新規作成された画面遷移パターン仕様書は、図１３の１３０１のような状態になっている。
（ステップ１２０３）：次に、ステップ１２０１で取得した画面遷移リストに含まれる要素をひとつずつ取得する。このときのリストの要素は＜page＞オブジェクトか、＜event＞オブジェクトである。すべての要素の取得が完了したらループを抜ける。
（ステップ１２０４）：取得した要素を評価する。取得した要素が＜page＞オブジェクトであればステップ１２０５を実行する。取得した要素が＜event＞オブジェクトであれば、ステップ１２０６を実行する。
（ステップ１２０５）：ページ列挿入処理を実行する。これは、取得した＜page＞オブジェクトの内容を元に、ステップ１２０２で作成した画面遷移パターン仕様書に新たな列を追加する処理である。図１３の１３０２に示すように、画面遷移パターン仕様書に新たな列が追加され、取得した＜page＞オブジェクトのname,desc属性の値が、それぞれヘッダ列に埋め込まれる。
（ステップ１２０６）：イベント列挿入処理を実行する。これは、取得した＜event＞オブジェクトの内容を元に、ステップ１２０２で作成した画面遷移パターン仕様書に新たな列を追加する処理である。図１３の１３０３に示すように、画面遷移パターン仕様書に新たな列が追加され、取得した＜event＞オブジェクトのaction,desc属性の値が、それぞれヘッダ列に埋め込まれる。

以上で画面遷移パターン仕様書の生成が完了する。本システムの使用者（Webアプリケーションの開発者）は、生成した画面遷移パターン仕様書を手作業で修正して、セッションの登録・破棄情報を記述する。

図１４は、画面遷移パターン仕様書にセッションの登録、破棄の情報を記述したものである。まず本システムの使用者（Webアプリケーションの開発者）は「セッションキー」列に、セッションに登録・破棄したいデータの「セッションキー」を記述する。「セッションキー」とは、セッションにデータを登録する際のキーとなる文字列である。１４０１では、登録画面で入力した登録情報を「InputData」というセッションキーでセッションに登録するように記述している。
次にそのセッションにデータを登録・破棄するタイミングを、"◎"、"×"で記述する。"◎"はセッションの登録、"×"はセッションの破棄を意味する記号である。１４０２では、登録画面から確認画面に遷移するタイミングで、登録情報をセッションに登録させるため、「確認画面へ」イベントの列に"◎"を設定している。また１４０３では、確認画面から登録画面に戻るタイミングで登録情報をセッションから破棄するために、「戻る」イベントの列に"×"を設定している。
この時点で、いったん画面遷移パターン仕様書を保存し、図１のセッション登録・破棄情報更新手段１０７と、図１のセッション保持期間設定手段１０８を実行する。すると、画面遷移パターン仕様書の内容が、図１５のように更新される。

図１５は「セッション登録・破棄情報更新手段」「セッション保持期間設定手段」実行後の画面遷移パターン仕様書の様子を示す図である。
仕様書１５Ａでは、まず「登録画面へ」イベント列１５０１に"×"が追加されていることがわかる。これは、使用者が「戻る」イベント列１５０４に"×"を指定していたためである。「セッション登録・破棄情報更新手段」は、「登録画面へ」イベントと「戻る」イベントは同一のアクションクラスが関連付いているため、整合をとるために１５０１に"×"を自動的に追加した。
また、仕様書１５Ｂには、セッションキーとして「InputData」１５０５、「登録画面へ」イベント列１５０６に"×"、「確認画面へ」イベント列１５０７に"◎"が追加されている。これも仕様書１５Ａと共通のアクションが仕様書１５Ｂでも参照されているため、「セッション登録・破棄情報更新手段」が自動的に追加したものである。
加えて、仕様書１５Ａには「確認画面」ページの列１５０３に"○"が追加されている。"○"は「セッションの生存期間」を示す記号である。これは「確認画面」イベント列１５０２でセッションを登録し、「戻る」イベント列１５０４でセッションが破棄しているため、その間の「確認画面」ページ１５０３ではセッションは登録されたまま、すなわち生存状態にあるといえるため、「セッション保持期間設定手段」が自動的に"○"を設定している。

図１６では、さらに使用者が手作業で、更新された画面遷移パターン仕様書に対して、仕様書１６Ｂの１６０１に示すように、「メニューへ」イベントでセッションを破棄するように指定している。これは、登録が完了し、メニューに戻るタイミングでセッションを破棄するためである。そして、再度、図１のセッション登録・破棄情報更新手段１０７と、図１のセッション保持期間設定手段１０８を実行する。

すると、画面遷移パターン仕様書が図１７のように更新される。図１７では１７０１、１７０２，１７０３に示すように "○"が設定される。これは、「確認画面へ」イベント実行時にセッション情報を登録し、「メニューへ」イベント発生時に破棄していることから、その間はセッションが生存していると、「セッション保持期間設定手段」が判断しているためである。

このように、使用者はセッションを登録・破棄したい箇所に"◎""×"をつけることで、セッション情報編集装置は、他の画面遷移パターン内の同一アクションに対しても自動的に"◎""×"を設定し、さらに"◎"と"×"の間に"○"記号を自動的に付加する。これにより、画面遷移パターン仕様書を見るだけで、どこでセッションが登録され、どの程度の期間生存し、どこで破棄されるか、といったことが簡単にわかるようになるため、セッション管理の設計ミスを防ぐことが可能となる。

以上のように、「セッション登録・破棄情報更新手段」「セッション保持期間設定手段」によって、画面遷移パターン仕様書が更新される。次の図１８から図２０では、この二つの手段によって行われる処理の詳細について説明する。

図１８はセッション登録・破棄情報更新手段の処理の流れを示すフローチャートである。
（ステップ１８０１）：まずは、画面遷移パターン仕様書をひとつずつ読み込む。この仕様書には使用者によって"◎"や"×"の記号が追記されている。すべての仕様書の読み込みが完了したらループを抜ける。
（ステップ１８０２）：次に、読み込んだ仕様書を上から順に一行ずつ読み込む。すべての行の読み込みが完了したらループを抜ける。
（ステップ１８０３）：次に、読み込んだ行のカラムを左からひとつずつ読み込む。すべてのカラムの読み込みが完了したらループを抜ける。
（ステップ１８０４）：読み込んだカラムの値を評価する。読み込んだカラムの値が"◎"なら、ステップ１８０５を実行する。読み込んだカラムの値が"×"なら、ステップ１８０６を実行する。読み込んだカラムの値が"◎""×"以外であれば、なにもせずにステップ１８０３へ戻ってループする。
（ステップ１８０５）：ステップ１８０４で読み込んだカラムの列のヘッダから取得したアクションクラス名と、そのカラムの行の１列目から取得したセッションキー名と、コピーするカラムの値（＝"◎"）、の３つを引数として「セッション登録・破棄情報コピー処理（後述）」を呼び出す。たとえば、読み込んだカラムが図１４の１４０２のカラムであれば、"ConfirmAction"、"InsertData"、"◎"の三つの文字列を引数として「セッション登録・破棄情報コピー処理」を呼び出す。呼び出し先で、画面遷移パターン仕様書の更新が行われる。
（ステップ１８０６）：ステップ１８０４で読み込んだカラムの列のヘッダから取得したアクション名と、そのカラムの行の１列目から取得したセッションキー名と、カラムの値（＝"×"）、の３つを引数として「セッション登録・破棄情報コピー処理（後述）」を呼び出す。たとえば、読み込んだカラムが図１４の１４０３のカラムであれば、"InsertAction"、"InsertData"、"×"の三つの文字列を引数として、セッション登録・破棄情報コピー処理を呼び出す。呼び出し先で、画面遷移パターン仕様書の更新が行われる。

図１９は、図１８のステップ１８０５，ステップ１８０６から呼び出されるセッション登録・破棄情報コピー処理の処理の流れを示すフローチャートである。
（ステップ１９０１）：まず、画面遷移パターン仕様書をひとつずつ読み込む。すべての仕様書の読み込みが完了したらループを抜ける。
（ステップ１９０２）：ステップ１９０１で読み込んだ仕様書内のヘッダ部分の文字列に、引数として受け取ったアクションクラス名と同じものがないかチェックする。ない場合はステップ１９０１に戻ってループする。ある場合はステップ１９０３を実行する。
（ステップ１９０３）：ステップ１９０１で読み込んだ仕様書内のすべての行の１列目をチェックし、引数として受け取ったセッションキー名と同じものが記述されていないかチェックする。ある場合はステップ１９０５を、ない場合はステップ１９０４を実行する。
（ステップ１９０４）：読み込んだ画面遷移パターン仕様書に、１行追加し、その一列目に、引数として受け取ったセッションキー名を設定する。
（ステップ１９０５）：読み込んだ画面遷移パターン仕様書を一行ずつ読み込む。すべての行の読み込みが完了した場合はループを抜ける。
（ステップ１９０６）：読み込んだ行のカラムを左からひとつずつ読み込む。すべてのカラムの読み込みが完了した場合はループを抜ける。
（ステップ１９０７）：読み込んだカラムのヘッダに記述されているアクションクラス名と、引数として受け取ったアクションクラス名が等しく、かつ、読み込んだ行の１列目に記述されているセッションキー名と、引数として受け取ったセッションキー名が等しければ、ステップ１９０８を実行する。そうでなければ、ステップ１９０６に戻りループを再開する。
（ステップ１９０８）：読み込んだカラムの値に、引数として受け取ったコピーするカラムの値を設定する。
たとえば、読み込んだカラムが、図１４の１４０４であり、引数として（"InsertAction"、"InsertData"、"×"）を受け取っている場合は、カラムのヘッダは"InsertAction"であり、１列目には"InsertData"が記述されているため、評価結果は真となり、ステップ１９０８が実行されることになる。ステップ１９０８では、カラムに"×"が設定される。

図２０は、セッション保持期間設定処理の処理の流れについてのフローチャートである。ここでは、画面遷移パターン仕様書を読み込み、"◎"と"×"に囲まれた範囲を"○"で埋めるという処理を行っている。
（ステップ２００１）：まずは、画面遷移パターン仕様書をひとつずつ読み込む。すべての仕様書の読み込みが完了したらループを抜ける。
（ステップ２００２）：次に、読み込んだ仕様書を上から順に一行ずつ読み込む。すべての行の読み込みが完了したらループを抜ける。
（ステップ２００３）：次に、処理内部で一時的に使用する、真偽型のフラグをfalseで初期化しておく。
（ステップ２００４）：次に、読み込んだ行のカラムを左からひとつずつ読み込む。すべてのカラムの読み込みが完了したらループを抜ける。
（ステップ２００５）：読み込んだカラムの値を評価する。値が"◎"なら（ステップ６）、"×"なら（ステップ７）、それ以外なら（ステップ８）を実行する。
（ステップ２００６）：フラグをtrueにし、（ステップ４）に戻る。これにより、次以降に読み込むカラムには"○"が設定される。
（ステップ２００７）：フラグをfalseにし、（ステップ４）に戻る。これにより、次以降に読み込むカラムに対しては何もしない。
（ステップ２００８）：フラグの値を評価する。trueの場合は（ステップ９）を実行、falseの場合は（ステップ４）に戻る。
（ステップ２００９）：読み込んだカラムに"○"を設定する。

以上のように、「セッション登録・破棄情報更新手段」「セッション保持期間更新手段」を用いて画面遷移パターン仕様書の更新を繰り返す。そして、画面遷移パターン仕様書が完成したら、図１のセッション情報反映手段１０９を使用して画面遷移情報XMLファイル１０３を更新する。これにより、最終的なwebアプリケーションを生成するための元情報となる画面遷移情報XMLファイル１０３が完成する。

図２１はセッション情報反映手段１０９を実行後の画面遷移情報XMLファイル１０３の例を示す図である。２１０１、２１０２、２１０３に示すとおり、セッション情報反映手段によって、セッションの登録・破棄を行うアクションについては、＜action＞要素の子要素として＜session＞要素が追加される。＜session＞要素のtype属性には、セッションの登録の場合は"set"、破棄の場合は"remove"を指定する。また、name属性には登録・破棄を行う際のセッションキー名を指定する。

図２２は、セッション情報反映手段の処理の流れを示したフローチャートである。
（ステップ２２０１）：まずは、画面遷移パターン仕様書をひとつずつ読み込む。すべての仕様書の読み込みが完了したらループを抜ける。
（ステップ２２０２）：次に、読み込んだ仕様書を上から順に一行ずつ読み込む。すべての行の読み込みが完了したらループを抜ける。
（ステップ２２０３）：次に、読み込んだ行のカラムを左からひとつずつ読み込む。すべてのカラムの読み込みが完了したらループを抜ける。
（ステップ２２０４）：読み込んだカラムの値を評価する。カラムの値が"◎"もしくは"×"の場合はステップ２２０５を実行する。それ以外の場合はステップ２２０３のループに戻る。
（ステップ２２０５）：ステップ２２０２で読み込んだ行の一列目からセッションキー名を取得する。
（ステップ２２０６）：メモリ上に＜session＞要素（を文字列データとして表現したもの）を作成し、そのname属性にステップ２２０５で取得したセッションキー名を設定する。
（ステップ２２０７）：ステップ２２０３で読み込んだカラムの値を評価する。値が"◎"ならステップ２２０８、"×"ならステップ２２０９を実行する。
（ステップ２２０８）：ステップ２２０６で作成した＜session＞要素のtype属性値として、"set"を設定する。
（ステップ２２０９）：ステップ２２０６で作成した＜session＞要素のtype属性値として、"remove"を設定する。
（ステップ２２１０）：ステップ２２０３で読み込んだカラムの列のヘッダからアクションクラス名を取得する。
（ステップ２２１１）：画面遷移情報XMLファイルに記述されているすべての＜action＞要素のうちname属性が、ステップ２２１０で取得したアクションクラス名と等しいものを取得する。
（ステップ２２１２）：ステップ２２１１で取得した＜action＞要素の子要素に、ステップ２２０６で作成した＜session＞要素と等しいものがなければ、＜action＞要素の子要素としてステップ２２０６で作成した＜session＞要素を挿入し、画面遷移情報XMLファイルを書き換える。

以上で、Webアプリケーションのソースコードを生成するための情報はすべてそろったため、図１のソースコード生成装置１０２を使って、ソースコードを生成する。
ソースコードの生成を実際に行う図１のソースコード生成手段１１０では、図１の画面遷移情報XMLファイル１０３と、生成ソースコードテンプレートファイル１１１を、入力データとして使用する。
本実施例では、Java（「Java」は、米国サン・マイクロシステムズ社の登録商標である。）のWebアプリケーションフレームワークであるJakarta Struts Framework（以降、Strutsと表記）をベースとしたソースコードを生成対象とする。その場合、生成ソースコードテンプレートファイルは、図２３のようになる。

図２３は、Actionクラスと呼ばれるStrutsが提供するクラスを継承したクラスのソースコードを生成するためのテンプレートである。このテンプレートファイルは、本発明の画面遷移情報XMLファイルをDOMで読み込んだデータを対象としており、テンプレート中の"${・・・}"の部分がDOMオブジェクトの値に置換される。たとえば、画面遷移情報XMLの"＜action name="InsertAction＞"という要素のDOMオブジェクトを、図２３のテンプレートファイルに適用すると、図２３の２３０１に示す行は、"public InsertAction extends Action"のように置換されて、ソースコードとして出力される。また、このテンプレートでは、＜session＞オブジェクトのtype属性が"set"の場合は、セッションの登録処理を行うソースコードを、"remove"の場合はセッションの破棄処理を行うソースコードを、それぞれ生成する。
なお、テンプレートによるソースコードの生成の技術自体については、汎用テンプレートエンジンApache Velocityなどがよく知られており、公知の技術であるため、本実施例では詳細な説明は省略する。

図２４は、生成されるアクションクラスのソースコードの例である。２４０１に示すDOMオブジェクトを図２３のテンプレートに適用すると、２４０２に示すようなソースコードが生成される。２４０１のDOMオブジェクトには、type属性が"set"である要素が含まれているため、生成されるソースコード中の２４０４には、セッションの登録処理のソースコードが生成されているのがわかる。
なお、ソースコード生成直後は、２４０５に示すように、セッションに実際に登録するオブジェクトの値はnulｌである。本発明の使用者は、この部分を手作業で修正して、変数InputDataにセッションに実際に登録するオブジェクトを代入する必要がある。

図２５の場合は、生成されるアクションクラスのソースコードのうち、セッション破棄処理が含まれたものの例である。２５０１のDOMオブジェクトには、type属性が"remove"である＜session＞要素が含まれているため、生成されるソースコード中の２５０４には、セッションの破棄処理のソースコードが生成されているのがわかる。

以上のように、画面遷移パターン仕様書に記述したセッションの登録・破棄の設定どおりにWebアプリケーションのソースコードが生成されるため、セッション管理処理の実装し忘れなどを防ぐことができ、不具合のないWebアプリケーションの開発が可能となる。

このシステムを用いることにより、Webアプリケーションを開発する際に起こりえるセッション管理処理の実装し忘れを未然に防止することができるから、Webサーバ上でWebアプリを走らせて見て、バグを見つける探す時間を短縮してWebアプリケーションの開発が可能となる。

本発明の一実施例を示すシステム構成図である。 Webアプリケーションの全体の機能のうち、何らかの情報の登録を行う機能（登録機能）についての画面遷移を抜粋したものである。 画面遷移とアクションの関係を、XML形式で表現したものである。 画面遷移パターン仕様書の例である。 画面遷移パターンを矢印で画面遷移図にマッピングしたものである。 画面遷移パターン解析手段が行う処理の概要を示すフローチャートである。 開始ページ要素取得処理の流れを示すフローチャートである。 画面遷移処理の流れを示すフローチャートである。 action要素取得処理の流れを示すフローチャートである。 遷移先page要素取得処理の流れを示すフローチャートである。 解析結果リストの格納データを示したものである。 画面遷移パターン仕様書生成処理の処理の流れについて記述したフローチャートである。 「画面遷移パターン仕様書の新規作成処理」「ページ列挿入処理」「イベント列挿入処理」の処理内容を図示したものである。 画面遷移パターン仕様書にセッションの登録、破棄の情報を記述したものである。 「セッション登録・破棄情報更新手段」「セッション保持期間設定手段」実行後の画面遷移パターン仕様書の様子を示す図である。 さらに使用者が手作業で、更新された画面遷移パターン仕様書に対して「メニューへ」イベントでセッションを破棄するように指定していることを示す図である。 再度、セッション登録・破棄情報更新手段と、セッション保持期間設定手段を実行して画面遷移パターン仕様書が更新されることを示す図である。 セッション登録・破棄情報更新手段の処理の流れを示すフローチャートである。 セッション登録・破棄情報コピー処理の処理の流れを示すフローチャートである。 セッション保持期間設定処理の処理の流れについてのフローチャートである。 セッション情報反映手段１０９を実行後の画面遷移情報XMLファイル１０３の例を示す図である。 セッション情報反映手段の処理の流れを示したフローチャートである。 ソースコードテンプレートファイルの例である。 生成されるソースコード（セッション登録処理含む）の例である。 生成されるソースコード（セッション破棄処理含む）の例である。 Webアプリケーションの動作環境を示す概念図である。 端末装置２６１１のハードウェア構成を示すブロック図である。

符号の説明

１０１ セッション情報編集装置
１０２ ソースコード生成装置
１０３ 画面遷移情報XMLファイル
１０４ 画面遷移パターン解析手段
１０５ 画面遷移パターン仕様書
１０６ セッション登録・破棄情報を入力
１０７ セッション登録・破棄情報更新手段
１０８ セッション保持期間設定手段
１０９ セッション情報反映手段
１１０ ソースコード生成手段
１１１ 生成ソースコードテンプレートファイル
１１２ ソースコード
２６０１ インターネット（Web）
２６０２ Webサーバ
２６１１，２６１２，２６１３ 端末装置
２７００ バス
２７０１ ＣＰＵ
２７０２ ＲＡＭ
２７０３ ＲＯＭ
２７０４ ＨＤＤ
２７０５ 表示回路部
２７０６ 入力信号処理部
２７０７ ネットワーク回路部
２７１１ キーボード
２７１２ マウス
２７１５ 表示装置

Claims (3)

1. Webアプリケーションの画面遷移情報をXMLで記述した画面遷移情報XMLファイルに、セッションの登録・破棄に関する情報を追加するセッション情報編集装置と、
   該セッション情報編集装置が処理した処理結果を表示して操作者が視認可能とする表示装置と、
   該表示装置の表示画面に表示された処理結果を操作者が見て操作者がコンピュータ入力をする入力装置と、
   該入力装置により入力された信号を受けて前記セッション情報編集装置の処理内容を編集し、それにより改変された前記画面遷移XMLファイルから、Webアプリケーションのソースコードを生成するソースコード生成装置とからなり、操作者がWebアプリケーションのセッション管理処理の設計・実装をすることを支援するWebアプリケーションのセッション管理処理の設計・実装支援システムであって、
   前記セッション情報編集装置には、
   前記画面遷移情報XMLファイルからWebアプリケーションの画面遷移パターンを視覚的に表現した画面遷移パターン仕様書を生成する画面遷移パターン解析手段と、
   セッション情報の登録・破棄処理に関する情報を、該画面遷移パターン仕様書に追記し更新する、セッション登録・破棄情報更新手段と、
   セッション保持期間に関する情報を、前記画面遷移パターン仕様書に追記し更新する、セッション保持期間設定手段と、
   前記画面遷移パターン仕様書に記述された内容を再び画面遷移情報XMLファイルに書き出すセッション情報反映手段を設け、
   ソースコード生成装置には、
   更新された画面遷移情報XMLファイルと、生成ソースコードテンプレートファイルとから、Webアプリケーションのソースコードを生成するソースコード生成手段を設けた
   ことを特徴とするWebアプリケーションのセッション管理処理の設計・実装支援システム。
2. 請求項１に記載したWebアプリケーションのセッション管理処理の設計・実装支援システムであって、
   前記セッション登録・破棄情報更新手段と、前記セッション保持期間更新手段を用いて前記画面遷移パターン仕様書の更新を繰り返し、その結果を操作者に表示して、入力を促すことを特徴とするWebアプリケーションのセッション管理処理の設計・実装支援システム。
3. 請求項１に記載したWebアプリケーションのセッション管理処理の設計・実装支援システムであって、
   前記画面遷移パターン仕様書は、操作者が視認しやすいものであって、操作者に要求される入力が単純なものであることを特徴とするWebアプリケーションのセッション管理処理の設計・実装支援システム。

Images