SPIN を用いたウェブアプリケーションにおける階層別モデル検査支援方法

SPINを用いたウェブアプリケーションにおける階層別モデル検査支援方法SPINを用いたウェブアプリケーションにおける階層別モデル検査支援方法大阪大学　大学院情報科学研究科コンピュータサイエンス専攻浜口優　吉村顕　岡野浩三　楠本真二

研究の背景と目的 • 研究の背景 • Webアプリケーションの大規模複雑化 • 設計誤りを早期に漏れなく検出するのはますます困難 • 従来のソフトウェア開発における確認作業の問題点 • 人間の手作業による抜け落ちを完全に排除することは難しい • レビュー：担当者による仕様の確認作業 • 受け入れテスト：テストチームによるテストケースの設定 • ソフトウェア設計の確認作業で求められること • 設計誤りを迅速に検出すること • 上位仕様を対象とした検査手法の確立 • 設計誤りを漏れなく検出すること • 論理的な確認手法の確立 • 研究の目的 • Webアプリケーション仕様を対象としたモデル検査手法の提案と評価モデル検査上位仕様実装

モデル検査 • 検査対象の動作が仕様通りであることを検証 • デッドロック，到達不能状態の検出機能 • ユーザが定義した制約（LTL等）の真偽判定 • 利用手順 • 検査対象を有限状態機械としてモデル化 • 検査ツールで全状態空間を迅速に探索 • 問題点 • 検証用モデル記述言語の習得が必要 • 状態爆発回避を考慮した抽象化には経験が必要

提案手法 • 問題点 • システム全体をモデル化状態爆発 • 提案手法 • Webアプリケーションを階層別にモデル化 • 階層 • 画面遷移の検証 • 内部処理の検証 • 利点 • 状態爆発の軽減 • モデル別に独立した検証藤原貴之他, ”SPINによるStrutsアプリケーションの動作検証を目的としたモデル生成手法の提案”

MVCアーキテクチャ Model 具体的な処理 View ユーザの視点，画面 Controller ModelとViewの制御各部の主な働き User アプリケーションの利用者 Business Logic 具体的な処理の最小単位 Action まとまりのある処理単位を構成 Business Logicの制御対象Webアプリケーションの概要ページ遷移検証用モデル内部処理検証用モデル＊ Temporary Data View Controller Model １＊１１＊ User Action BusinessLogic Database １１

検証用モデル生成の流れ • 検証用モデル生成支援ツールの作成 • 検証用モデルのスケルトンを出力 • モデル抽出の手間を削減 • 抽出モデルの記述にかかる手間を緩和 • 支援ツールの入力 • 仕様の情報を含むXMLファイル • Struts設定ファイル • 画面定義ファイル　（画面設計書等の情報から作成可能） • 内部処理定義ファイル　（論理設計書から作成可能）ページ遷移検証用モデル内部処理検証用モデル検証用モデル（Promela）仕様書等（XML）支援ツール検証器（SPIN）制約（LTL）検証者検証結果

検証用モデル生成の基本方針 • 各機能ごとに状態遷移プロセスを作成 • プロセスどうしが同期することでシステムを表現 • ページ遷移検証用モデル • 内部処理検証用モデルページ遷移検証用モデル内部処理検証用モデル Server Client Business Logic Context Action Form User Action JSP Client Request Processor Action Servlet Database 図：Strutsアプリケーションの概要

ページ遷移検証用モデル入力ファイル • 画面定義ファイル • 画面内にどのアクションがあるのかを記述 • 呼び出すアクション名 • パラメータ • 画面ID • 画面に含まれるJSP • Struts設定ファイル • アクション実行後どの画面に遷移するのかを記述 • アクションの総数 • 各アクションの名称 • 処理後の遷移先 <screens> <screen id=“初期画面"> <jsps> <jspfile="index.jsp" /> </jsps> <actions> <actionname="/menu" parameter="action=init" /> <actionname="/menu" parameter="action=top" /> </actions> </screen> <screen> ･・・・・・・・・・・・・ </screen> </screens> ページの枚数と名前そのページから呼び出されるアクション <struts-config> <form-beans> <form-bean name=“form” type=“Form” /> </form-beans> <action-mappings> <actionpath=“/index" type=“Index" name=“form” scope=“request”> <forwardname=“init" path=“index.jsp" /> </action> </aciton-mappings> </struts-config> アクションの名前アクション実行後の遷移先

クライアントプロセス Viewの情報より生成画面定義ファイル（画面設計書）表示画面の総数アクションプロセス Controllerの情報より生成 Struts設定ファイルアクションの総数各アクションの名称処理後の遷移先ページ遷移検証用モデル出力となるモデルユーザからの入力サーバへリクエスト送信 ? input ! view !HttpReq ユーザへ表示中画面の送信 ?HttpRes サーバからの受信呼び出しを受信 ! forward ? callAction • 全体で６個のプロセスが同期して実現遷移先を送信

ページ遷移検証用モデル工夫点：特殊な状況とそのモデル表現（外乱プロセス）ページ遷移検証用モデル工夫点：特殊な状況とそのモデル表現（外乱プロセス）購入確認画面 Submitボタン押下ミス購入完了処理（支払い等）の二重化二重送信リクエスト送信ユーザサーバタイムアウトリクエスト情報の消失参照例外発生購入確認画面放置 → Submit 二重送信発生時タイムアウト発生時 !HttpReq !HttpReq 通常時通常時 e !HttpReq ?HttpReq ?HttpReq リクエスト横取りリクエスト横取り !HttpReq

目次 • 研究の背景と目的 • モデル検査 • 提案手法 • 対象Webアプリケーションの概要 • 検証用モデル生成の流れ • 検証用モデル生成の基本方針 • ページ遷移検証用モデル • 内部処理検証用モデル • 評価実験 • 適用実験 • 実験結果と考察 • まとめ

内部処理検証用モデル概要 • 内部処理 • Model層における意味を持つまとまりある単位の処理 • Actionが複数のBusiness logicの呼び出し順序を制御して処理を実現ビジネスロジック１呼び出しビジネスロジック１処理終了受信ビジネスロジック２呼び出し ?return Action１ !call Business１ !call Business2 ?return Action2 アクションアクションから呼び出し受信処理終了送信 !return Action１ ?call Business１ビジネスロジック１ … ?return Action2 ?call Business２ビジネスロジック２ …

内部処理検証用モデル工夫点：マルチタスク環境に対応したモデル表現内部処理検証用モデル工夫点：マルチタスク環境に対応したモデル表現 • 内部処理は共有資源を扱うことが多い • マルチタスク環境での動作検証が必要 • 並列に実行させる • 検証したい内部処理 • 資源の競合を起こす可能性のある内部処理 • 資源の競合が起きるかどうかを検証できるモデルを作成可能（デッドロックを早期に発見可）検証したい内部処理共有ロック読み込みビジネスロジックロック開始と解除タイミングのミス資源の競合の可能性のある内部処理排他ロック書き込みデッドロックビジネスロジック

入力：内部処理定義ファイル 内部処理内のAction Actionの呼び出すBusiness logic Business logic のアクセスする共有資源出力：検証モデル内部処理検証用モデル生成支援ツールの入出力追加記述共有資源を設定呼び出すビジネスロジックを定義 <actions resource=“1"> <action name=“ActionA"> <business-objects> <business name="businessA"order="0"> <dao name="daoA"resource=“1"order="0"type=“read" /> </business> </business-objects> <action name=“ActionB”> • <business-objects> • <business name="businessB"order="0"> • <dao name="daoB"resource=“1"order="0" type=“write" /> • </business> • </business-objects> </action> </actions> 共有ロックアクションを定義読み込みビジネスロジックの行う処理を定義追加記述共有資源排他ロック書き込み並列に実行する内部処理を定義

評価実験 • 実際のWebアプリケーションに適用 • 企業の新人研修で開発されたWebアプリケーション • ショッピングサイト • Webアプリケーションのページ遷移 • 二重送信 • タイムアウト • Webアプリケーション内の一部の内部処理 • 購入確認処理 • 検索処理 • 調べたいこと • 動作誤りの検証が可能かどうか？ • まとまった処理の検証が可能かどうか？ • 評価項目 • 検証コスト（検証時間，メモリ使用量）

適用実験：ページ遷移 • 新人研修で開発されたWebアプリケーション • ショッピングサイト • 画面遷移書，画面設計書がある • 黄色ノードへはメニューフレームより全画面から遷移可能トップ商品リスト商品詳細カート詳細購入購入確認購入完了検証例としてここに着目

実験結果と考察：ページ遷移 • 実験環境 • CPU : 3GHz，メモリ: 2GByte，検証器 : SPIN • OS : Windows XP Professional Edition • 動作誤りが存在する場合の検証時間は数秒 • 問題となる事象を個別に検証することで状態爆発を回避

適用実験：購入確認処理 • 処理内容 • 共有資源内の注文番号を取得し、新規注文番号の書き込みを行う • ２～６個の購入確処理を並列に実行 • 検査項目 • 全ての購入確認処理が正常に終了し、共有資源に値を書き込んでいる共有ロック掛けて読み込み購入確認処理Aと同じ処理購入確認処理A 共有資源購入確認処理B ランダムに共有ロック、排他ロックを掛けるビジネスロジック呼び出し排他ロック掛けて書き込み外乱プロセス（外部から管理者の共有資源へのアクセスを想定）図：作成した検証モデル

実験結果と考察：内部処理 • 実験環境 • CPU : 3GHz，メモリ: 2GByte，検証器 : SPIN • OS : Windows XP Professional Edition 購入確認処理検索処理 • 動作誤りが存在する場合の検証時間は数秒 • 同時に実行できるアクション数は２つのみ

実験結果と考察：内部処理（外乱プロセスなし）実験結果と考察：内部処理（外乱プロセスなし） • 実験環境 • CPU : 1.69GHz，メモリ: 512MByte，検証器 : SPIN • OS : Windows XP Home Edition 検索処理購入確認処理

モデル生成と検証の手間 • ページ遷移検証：約３日 • モデル作成 • 画面定義ファイル記述 • 追加記述 • 検証式（LTL式） • 内部処理検証：約１日 • モデル作成 • 内部処理定義ファイル記述 • 購入確認処理 • 検索処理 • 追加記述 • モデル内の詳細記述 • 検証式（LTL式）

まとめ • Webアプリケーション検証用モデル生成支援手法 • 外乱の導入によって異常発生時の動作設計支援 • 並列実行によるマルチタスク環境での内部処理動作設計支援 • 検証用コードの自動生成ツール試作 • モデル検査利用者の利便性向上 • 提案したモデルはある程度状態爆発を回避　今後の課題 • より多数のプロセスを用いたモデルの状態爆発の克服

SPIN を用いたウェブアプリケーションにおける階層別モデル検査支援方法