正常シナリオを用いた 例外シナリオの導出支援
DESCRIPTION
正常シナリオを用いた 例外シナリオの導出支援. 立命館大学大学院理工学研究科 ソフトウェア工学研究室 首藤寛樹. 背景. 要求分析活動においてシナリオは有効 ソフトウェアの振る舞いを定義 利用者自身による妥当性確認を支援 正常シナリオの他に,例外や代替等もシナリオとして記述する必要がある 例外や代替の導出には,主にブレインストーミングが用いられる. 問題点. 例外や代替は正常シナリオに比べると思いつきにくく,シナリオを用意しにくいという特徴がある 例外や代替の導出が不完全なまま開発工程が進むと,手戻りが発生し開発コストが増大する. 本研究の目的. - PowerPoint PPT PresentationTRANSCRIPT
2006/10/26 1
正常シナリオを用いた例外シナリオの導出支援
立命館大学大学院理工学研究科ソフトウェア工学研究室
首藤寛樹
2006/10/26 2
Software Engineering Laboratory.Software Engineering Laboratory.
背景
• 要求分析活動においてシナリオは有効– ソフトウェアの振る舞いを定義– 利用者自身による妥当性確認を支援
• 正常シナリオの他に,例外や代替等もシナリオとして記述する必要がある
• 例外や代替の導出には,主にブレインストーミングが用いられる
2006/10/26 3
Software Engineering Laboratory.Software Engineering Laboratory.
問題点
• 例外や代替は正常シナリオに比べると思いつきにくく,シナリオを用意しにくいという特徴がある
• 例外や代替の導出が不完全なまま開発工程が進むと,手戻りが発生し開発コストが増大する
2006/10/26 4
Software Engineering Laboratory.Software Engineering Laboratory.
本研究の目的正常シナリオを用いた例外シナリオの導出支援手法を提案・例外事象の導出プロセス 対処方法を用意すべき例外事象の選択
・対処方法の作成プロセス 例外事象への対処方法を正常シナリオとは別に イベント列として記述することによって明確化
・シナリオと対処方法の結合プロセス 正常シナリオと対処方法を結合することによって 対処方法の妥当性確認を支援
2006/10/26 5
Software Engineering Laboratory.Software Engineering Laboratory.
シナリオ
• ある状況に限定したシステムの具体的な動作例
• 利用者が目的を達成するためにシステムや他の利用者と協調して行う振る舞いを時系列に沿って記述
2006/10/26 6
Software Engineering Laboratory.Software Engineering Laboratory.
シナリオ記述言語 SLAF
• 機械処理可能なシナリオを記述可能• 構成
– タイトル– 視点(イベント文を捉える際の立場)– イベント文列
• イベント文• 時間的順序(順接,選択,繰り返し,並行同期)
– 事前条件・事後条件
2006/10/26 7
Software Engineering Laboratory.Software Engineering Laboratory.
シナリオ記述言語の処理系の機能
・ SLAFで記述されたシナリオのイベント文は,助詞を参考 に表層の表現に依存しない内部表現に変換可能・内部表現から視点の異なるシナリオの生成も可能
・・・・・・・・・
シナリオ内部表現
・・・・・・・・・
イベント文の解析の例
ユーザはシステムにウェブサイト名を入力する
動作概念= DFLOW
Source格=ユーザ( Human型 )
Goal格=システム (Function型)
object格=ウェブサイト名
ユーザ視点のシナリオ システム視点のシナリオ
2006/10/26 8
Software Engineering Laboratory.Software Engineering Laboratory.
シナリオの例
[ウェブ上で株式を購入する ][ユーザ,システム ]{ ユーザはシステムにウェブサイト名を入力する システムはウェブサイトに接続する システムはウェブサイトの制御を保持する ユーザはウェブサイトから株式情報を得る ユーザはウェブサイト上で株式を購入する システムはウェブサイトから応答を得る システムはユーザのポートフォリオ情報を更新する システムはポートフォリオを表示する}
タイトル視点
イベント文
列
2006/10/26 9
Software Engineering Laboratory.Software Engineering Laboratory.
用語の定義
• 正常シナリオ– 目標を達成できる最も一般的なシナリオ
• 例外事象– イベントの生起を失敗させるアクシデント
• 例外イベント列– 例外事象が発生した際の対処を記したイベント列
• 例外シナリオ– 例外事象が発生した際のシナリオ– 本研究では,例外時の振る舞いの妥当性確認を容易にするため,正常シナリオと例外イベント列を結合することによって例外シナリオを作成.
2006/10/26 10
Software Engineering Laboratory.Software Engineering Laboratory.
例外事象の分類と導出支援対象• 例外事象の分類
– 情報システムに依存した任意のドメインで起こりうる一般的な例外事象
– ドメインに依存した例外事象– システムに依存した例外事象
• 本研究の導出支援対象– 一般的な例外事象
• 様々なドメインのシナリオに手法を適用可能
2006/10/26 11
Software Engineering Laboratory.Software Engineering Laboratory.
手法の全体像
ユーザ
①例外事象の導出
例外事象データベース
例外イベント列データベース
②例外イベント列の作成
③シナリオと例外イベント列の結合
正常シナリオ
動作概念
例外事象の案
例外事象,正常シナリオ
例外事象,格の型情報
例外事象テンプレート
例外イベント列テンプレート
例外イベント列
正常シナリオ,例外イベント列
例外シナリオ
2006/10/26 12
Software Engineering Laboratory.Software Engineering Laboratory.
①例外事象の導出プロセス
• 正常シナリオ内のイベント文を解析し,例外事象の案をユーザに提示し選択してもらうことによって例外事象の導出を支援するプロセス(手順1~4)
2006/10/26 13
Software Engineering Laboratory.Software Engineering Laboratory.
①例外事象の導出プロセス -手順1 -
手順1:正常シナリオ内のイベント文から
動作概念を抽出する[ウェブ上で株式を購入する ][ユーザ,システム ]{ユーザはシステムにウェブサイト名を入力するシステムはウェブサイトに接続するシステムはウェブサイトの制御を保持するユーザはウェブサイトから株式情報を得るユーザはウェブサイト上で株式を購入するシステムはウェブサイトから応答を得るシステムはユーザのポートフォリオ情報を更新するユーザはシステムからポートフォリオを表示される}
入力された正常シナリオ
動作概念= DFLOW
Source格=ユーザ( Human型 )
Goal格=システム (Function型)
object格=ウェブサイト名
内部表現
2006/10/26 14
Software Engineering Laboratory.Software Engineering Laboratory.
①例外事象の導出プロセス -手順2 -
手順2:抽出した動作概念を用いてユーザへ提示用の
例外事象テンプレートを取得する
DFLOW
動作概念= DFLOW
・ (Source)からの (object)に抜け・誤りがあった場合・ 一定時間, (Source)からのアクションがなかった場合動作概念= SELECT
・ (Source)が誤った選択をした場合動作概念= CHECK
・ (CHECK)される (object)に誤りがあった場合
抽出した動作概念
2006/10/26 15
Software Engineering Laboratory.Software Engineering Laboratory.
①例外事象の導出プロセス -手順3 -
手順3:テンプレート内の抜けている格をイベント文の格情報を
用いて補完し,例外事象の案を作成
動作概念= DFLOW
Source格=ユーザ( Human型 )
Goal格=システム (Function型)
object格=ウェブサイト名
イベント文の格情報
・ (object)に抜け・誤りがあった場合・ 一定時間, (Source)からのアクションがなかった場合
手順2で得たテンプレート
・ ウェブサイト名に抜け・誤りがあった場合・ 一定時間,ユーザからのアクションがなかった場合
2006/10/26 16
Software Engineering Laboratory.Software Engineering Laboratory.
①例外事象の導出プロセス -手順4 -
手順4:ユーザに正常シナリオと共に例外事象の案を提示する。ユーザは案の中から対処方法をシナリオとして用意すべきだと思うものを選択する.
・ ウェブサイト名に抜け・誤りがあった場合・ 一定時間,ユーザからのアクションがなかった場合
[ウェブ上で株式を購入する ][ユーザ,システム ]{ ユーザはシステムにウェブサイト名を入力する システムはウェブサイトに接続する システムはウェブサイトの制御を保持する ユーザはウェブサイトから株式情報を得る ユーザはウェブサイトから株式を購入する システムはウェブサイトから応答を得る システムはユーザのポートフォリオ情報を更新する システムはポートフォリオを表示する}
例外事象の案
2006/10/26 17
Software Engineering Laboratory.Software Engineering Laboratory.
②例外イベント列の作成プロセス
• 例外事象への対処方法を作成するプロセス(手順5~7)テンプレートを用いて自動生成を行うが,ユーザは必要に応じて作成された例外イベント列をカスタマイズできる.
2006/10/26 18
Software Engineering Laboratory.Software Engineering Laboratory.
②例外イベント列の作成プロセス -手順5 -
手順5:選択された例外事象の案と格の型情報を元に,DBから 例外イベント列のテンプレートを取得.テンプレート内の抜けている格は元となったイベント文を用いて補完.
・ ウェブサイト名に抜け・誤りがあった場合・ 一定時間,ユーザからのアクションがなかった場合
起こりうる例外事象
動作概念=入力する (DFLOW)
Source格=ユーザ( Human型)
Goal格=システム (Function型)
object格=ウェブサイト名
イベント文の内部表現[(object)に抜け・誤りがあった場合の対処 ][(Source), (Goal)]event[]condition[(object)に抜け・誤りがあった ]{ (Source)は (Goal)から再入力の必要性を伝えられる (Source)は (object)を訂正する (Source)は (Goal)に (object)を (DFLOW)}
(object)に抜け・誤りがあった場合の対処( Source格 =Human型, Goal格 =Function型の場合)
[ウェブサイト名に抜け・誤りがあった場合の対処 ][ユーザ,システム ]event[ユーザはシステムにウェブサイト名を入力する ]condition[ウェブサイト名に抜け・誤りがあった ]{ ユーザはシステムから再入力の必要性を伝えられる ユーザはウェブサイト名を訂正する ユーザはシステムにウェブサイト名を入力する}
「ウェブサイト名」に抜け・誤りがあった場合の例外イベント列
2006/10/26 19
Software Engineering Laboratory.Software Engineering Laboratory.
②例外イベント列の作成プロセス -手順6,7 -
手順6:ユーザが必要に応じてカスタマイズを行う.選択された例外事象が複数あった場合は,選択された数だけ同じ手順を踏み例外イベント列を作成する.
[一定時間,ユーザからのアクションがなかった場合の対処 ][ユーザ,システム ]event[ユーザはシステムにウェブサイト名を入力する ]condition[一定時間,ユーザからのアクションがなかった ]{ システムは現在の状態を保存する システムは処理を終了する ユーザはシステムに処理を再開する旨を伝える システムは処理を再開する ユーザはシステムにウェブサイト名を入力する}
同一イベント文上の異なる例外事象に対し作成された例外イベント列
手順7:正常シナリオ内の該当する動作概念を含む全てのイベ ント文に対し,例外事例の導出及び例外イベント列の作成手順を繰り返す.
2006/10/26 20
Software Engineering Laboratory.Software Engineering Laboratory.
③シナリオと例外イベント列の結合プロセス
• 作成された例外イベント列と正常シナリオを結合し,例外時の振る舞いの妥当性確認を行うプロセス(手順8,9).
21
Software Engineering Laboratory.Software Engineering Laboratory.
③シナリオと例外イベント列の結合プロセス -手順8 -
手順8:正常シナリオと例外イベント列を結合する.結合時には 制御文を用いる
[ウェブ上で株式を購入する ][ユーザ,システム ]{ ユーザはシステムにウェブサイト名を入力する システムはウェブサイトに接続する システムはウェブサイトの制御を保持する ユーザはウェブサイトから株式情報を得る ユーザはウェブサイトから株式を購入する システムはウェブサイトから応答を得る システムはユーザのポートフォリオ情報を更新する システムはポートフォリオを表示する}
[ウェブサイト名に抜け・誤りがあった場合の対処 ][ユーザ,システム ]event[ユーザはシステムにウェブサイト名を入力する ]condition[ウェブサイト名に抜け・誤りがあった ]{ ユーザはシステムから再入力の必要性を伝えられる ユーザはウェブサイト名を訂正する ユーザはシステムにウェブサイト名を入力する}
[一定時間,ユーザからのアクションがなかった場合の対処 ][ユーザ,システム ]event[ユーザはシステムにウェブサイト名を入力する ]condition[一定時間,ユーザからのアクションがなかった ]{ システムは現在の状態を保存する システムは処理を終了する ユーザはシステムに処理を再開する旨を伝える システムは処理を再開する ユーザはシステムにウェブサイト名を入力する}
例外イベント列その1
例外イベント列その2
[ウェブ上で株式を購入する ][ユーザ,システム ]{ ユーザはシステムにウェブサイト名を入力する if(ユーザはシステムにウェブサイト名を入力する ) システムはウェブサイトに接続する システムはウェブサイトの制御を保持する ユーザはウェブサイトから株式情報を得る ユーザはウェブサイトから株式を購入する システムはウェブサイトから応答を得る システムはユーザのポートフォリオ情報を更新する システムはポートフォリオを表示する}
[ウェブ上で株式を購入する ][ユーザ,システム ]{ ユーザはシステムにウェブサイト名を入力する if(ウェブサイト名に抜け・誤りがあった ) if(一定時間,ユーザからのアクションがなかった) システムはウェブサイトに接続する システムはウェブサイトの制御を保持する ユーザはウェブサイトから株式情報を得る ユーザはウェブサイトから株式を購入する システムはウェブサイトから応答を得る システムはユーザのポートフォリオ情報を更新する システムはポートフォリオを表示する}
2006/10/26 22
Software Engineering Laboratory.Software Engineering Laboratory.
手順9:ビューワを用い,正常シナリオと結合された例外イベント列を同時に表示させ,例外時の振る舞いの妥当性確認を行う
③シナリオと例外イベント列の結合プロセス -手順9 -
2006/10/26 23
Software Engineering Laboratory.Software Engineering Laboratory.
評価と考察
• 5つのプロジェクトで使用されたシナリオに今回の手法を適用し,評価を行った
– UC02 :自動車事故の支払い請求– UC05 :システムを通して物を購入する– UC26 :コース科目を履修登録する– UC37 :オンラインショップで商品を選択する– UC39 :ウェブ上で株式を購入する
• 評価ポイント1. 開発事例で作成された一般的な例外事象のうち,何 %を本手
法によって導出できたか2. 開発事例で作成された例外シナリオのうち,何 %を本手法に
よって作成できたか
2006/10/26 24
Software Engineering Laboratory.Software Engineering Laboratory.
評価と考察
UC02 UC05 UC26 UC37 UC39 計開発事例での一般的な例外事象 3 2 1 1 3 10
手法で提示された例外事象(A) 6 17 2 2 6 33
(A)のうち,開発事例と一致していたもの
3 2 1 1 3 10
例外事象の導出プロセスの評価の内訳
評価ポイント1開発事例で作成された一般的な例外事象のう
ち,何 %を本手法によって導出できたか
→ 一般的な例外事象については もれなく導出支援することができた
2006/10/26 25
Software Engineering Laboratory.Software Engineering Laboratory.
評価と考察
• 一方で,23個(70%)の開発事例にはない例外事象を本手法では提示していた.
• 原因– 全てのアクタが同じように例外を起こすと考え,例外事象を提示していた
• 解決策– アクタの業務への理解度を考慮した手法への改善.– 例外事象を提示する際,イベント文中のアクタの業
務への理解度が高い場合は提示を行わない
2006/10/26 26
Software Engineering Laboratory.Software Engineering Laboratory.
評価と考察
• Human型のアクタが複数登場する, UC05(物を購入する)に改善策を適用
• 業務への理解度は以下のように設定– 小:依頼者,受取人– 大:承認者,購買担当者,決裁者,ベンダー
• 理解度大のアクタしか関らないイベント文では例外事象の提示を行わなかった
2006/10/26 27
Software Engineering Laboratory.Software Engineering Laboratory.
評価と考察
0
2
4
6
8
10
12
14
16
18
A B C
1系列
0
2
4
6
8
10
12
14
16
18
A B C
1系列
改善前 改善後
A 開発事例で作成された一般的な例外事象
B 本手法で提示された全例外事象
C Bのうち,開発事例と一致していたもの
2006/10/26 28
Software Engineering Laboratory.Software Engineering Laboratory.
評価と考察評価ポイント2開発事例で作成された一般的な例外事象に対するシナリオのう
ち,何%を本手法によって作成することができたか
自動作成後,カスタマイズ不要 50%
自動作成後,カスタマイズ要 20%作成に失敗(手法で提示した振る舞いの書き換えを要した)
30%
→ 本手法によって開発事例における 70%の例外シナ リオを作成することができた→ 失敗した 30%はドメインやシステムに依存した対処 方法をとっていたため,本手法の支援対象外といえる
2006/10/26 29
Software Engineering Laboratory.Software Engineering Laboratory.
まとめ
• 正常シナリオを用いた例外シナリオの導出支援手法を提案し,評価を行った
• 具体的には, DBに格納されたテンプレートと正常シナリオ内のイベント文が持つ格情報を用いて例外事象や例外イベント列を作成した.また,例外時の振る舞いの妥当性確認を支援するために,正常シナリオと例外イベント列を結合した.
• 実験によって,一般的な例外事象はもれなく導出支援が行えることがわかった.また,開発事例で作成された例外シナリオのうち, 70%を本手法によって作成できることがわかった.
2006/10/26 30
Software Engineering Laboratory.Software Engineering Laboratory.
今後の課題
• 例外事象の導出支援プロセスの改善• さらに多くの開発事例への適用・評価• 手法のツール化