正常シナリオを用いた
例外イベント列の作成支援
立命館大学大学院
理工学研究科情報システム学専攻
ソフトウェア工学研究室所属
首藤寛樹
2007/2/23
1
Software Engineering Laboratory.
背景
• シナリオを用いたソフトウェア開発では，一般的な振
る舞いのシナリオだけでなく，異常発生時の対処シ
ナリオを用意する必要がある
• 異常発生時の対処シナリオは一般的な振る舞いの
シナリオに比べ用意が難しい
• 一般的な振る舞いのシナリオから，異常発生時の
対処シナリオを生成する手法が過去に提案された
2007/2/23
2
Software Engineering Laboratory.
従来の手法の問題と本研究の目的
• 従来の手法の問題点
– アクタの特性によって対処方法が変化しない
– テンプレートに汎用性がない
– 妥当性確認に手間がかかる
• 本研究の目的
– 対処方法の生成時，アクタの特性によって生成する対処
を変化させる
– 対処時の振る舞いのみ生成し，テンプレートに汎用性を
持たせる
– 妥当性確認を行う際は随時一般的なシナリオと結合
2007/2/23
3
Software Engineering Laboratory.
用語の定義
• 正常シナリオ
– 目標を達成できる最も一般的なシナリオ
• 例外事象
– イベントの生起を失敗させるアクシデント
• 例外イベント列
– 例外事象が発生した際の対処を記したイベント列
• 例外シナリオ
– 例外事象が発生した際のシナリオ
– 本研究では，例外時の振る舞いの妥当性確認を容易に
するため，正常シナリオと例外イベント列を結合すること
2007/2/23 によって例外シナリオを作成する
4
Software Engineering Laboratory.
シナリオの具体例
タイトル
視点
2007/2/23
[ 物品を購入する ]
[ 依頼者，承認者，購買担当者，決裁者，受取人，ベンダー ]{
依頼者は 承認者に 依頼を 出す
承認者は 予算額を 確認する
承認者は 商品価格を 確認する
承認者は 依頼を 承認する
承認者は 購買担当者に 依頼を 提出する
購買担当者は 在庫を 確認する
購買担当者は 商品のベンダーを 選択する
イベント文列
決裁者は 承認印を 確認する
購買担当者は 注文書を 作成する
購買担当者は 注文書を ベンダーに 送付する
受取人は 受け取りを 登録する
依頼者は 受取人から 商品を 受け取る
依頼者は 依頼品が届いた事を 記録する
}
物品の購買システムのシナリオ
5
Software Engineering Laboratory.
例外イベント列の具体例
タイトル
視点
[ 一定時間，受取人からのアクションがなかった場合の対処 ]
[ 依頼者，受取人 ]
event[ 受取人は依頼者から商品を受け取る ]
イベント文
condition[ 一定時間，受取人からのアクションがなかった場合 ]{
条件
依頼者は 受取人に アクションを起こして欲しい旨を 伝える
受取人は アクションを 再開させる
依頼者は 受取人から 商品を 受け取る
}
イベント文列
一定時間，依頼者からのアクションがなかった場合の例外イベント列
2007/2/23
6
Software Engineering Laboratory.
手法の全体像
①
例外事象
の導出
正常シナリオ，
業務への理解度
例外事象の案
例外事象
ユーザ
例外イベント列の案
例外イベント列
動作概念
例外事象テンプレート
例外事象
データベース
正常シナリオ
②
例外イベント列
の作成
例外事象，格の型情報
例外イベント列
テンプレート
例外イベント列
データベース
正常シナリオ
例外シナリオ
2007/2/23
③
シナリオと
例外イベント列
の結合
シナリオの結合手法
7
Software Engineering Laboratory.
①例外事象の導出プロセス -手順１手順１：
正常シナリオを受け取ると，Human型アクタの
業務への理解度をユーザに問い合わせる
[ 物品を購入する ]
[ 依頼者，承認者，購買担当者，決裁者，受取人，ベンダー ]{
依頼者は 承認者に 依頼を 出す
承認者は 予算額を 確認する
承認者は 商品価格を 確認する
承認者は 依頼を 承認する
承認者は 購買担当者に 依頼を 提出する
購買担当者は 在庫を 確認する
購買担当者は 商品のベンダーを 選択する
決裁者は 承認印を 確認する
購買担当者は 注文書を 作成する
購買担当者は 注文書を ベンダーに 送付する
受取人は 受け取りを 登録する
依頼者は 受取人から 商品を 受け取る
依頼者は 依頼品が届いた事を 記録する
}
2007/2/23
入力された正常シナリオ
６人分の入力を要求
業務への理解度の設定例
業務への理解度
アクタ
大
承認者，購買担当者，決裁者
中
依頼者，ベンダー
小
受取人
8
Software Engineering Laboratory.
①例外事象の導出プロセス -手順２手順２：
導出支援すべき動作概念とアクタの条件の組み合わせを元に，
導出支援を行うイベント文を選択する．
[ 物品を購入する ]
[ 依頼者，承認者，購買担当者，決裁者，受取人，ベンダー ]{
依頼者は 承認者に 依頼を 出す
承認者は 予算額を 確認する
承認者は 商品価格を 確認する
承認者は 依頼を 承認する
承認者は 購買担当者に 依頼を 提出する
購買担当者は 在庫を 確認する
購買担当者は 商品のベンダーを 選択する
決裁者は 承認印を 確認する
購買担当者は 注文書を 作成する
購買担当者は 注文書を ベンダーに 送付する
受取人は 受け取りを 登録する
依頼者は 受取人から 商品を 受け取る
依頼者は 依頼品が届いた事を 記録する
}
2007/2/23
動作概念とアクタの条件の組み合わせ
動作概念
アクタの条件
DFLOW
Source の業務への理解度が小
SELECT
Agent の業務への理解度が小
CHECK
Agent の業務への理解度が大
・・・
・・・
9
Software Engineering Laboratory.
①例外事象の導出プロセス -手順３手順３：
選択したイベント文の動作概念を用いて，
データベースから例外事象のテンプレートを取得する
選択したイベント文の
動作概念： DFLOW
動作概念＝DFLOW
・ (object)に抜け・誤りがあった場合
・ 一定時間，(Source）からのアクションがなかった場合
動作概念＝SELECT
・ (Source)が誤った選択をした場合
動作概念＝CHECK
・ (CHECK)される(object)に誤りがあった場合
2007/2/23
10
Software Engineering Laboratory.
①例外事象の導出プロセス -手順４手順４：
イベント文の格情報を用いてテンプレート内において
抜けている格を補完し，例外事象を作成する
イベント文の格情報
手順３で得たテンプレート
・ (object)に抜け・誤りがあった場合
・ 一定時間，(Source）からのアクションがなかった場合
動作概念＝DFLOW
Source格＝受取人（Human型)
Goal格
＝依頼者(Human型）
object格 ＝商品
・ 商品に抜け・誤りがあった場合
・ 一定時間，受取人からのアクションがなかった場合
2007/2/23
11
Software Engineering Laboratory.
②例外イベント列の作成プロセス-手順6，7手順６：
例外事象と格の型情報を元に，データベースから
例外イベント列のテンプレートを取得する．
手順７：
テンプレート内の抜けている格はイベント文を用いて補完．
ユーザによって選択された例外事象
・ 一定時間，受取人からのアクションがなかった場合
・一定時間，(Source)からのアクションがなかった場合
イベント文の内部表現
・Source＝Human型，Goal＝Human型
「一定時間，受取人からのアクションがなかった場合」
の例外イベント列
という条件で取得されたテンプレート
動作概念＝受け取る(DFLOW)
Source格＝受取人（Human型）
Goal格
＝依頼者(Human型）
object格 ＝商品
2007/2/23
[ 一定時間，受取人からのアクションがなかった場合の対処
[ 一定時間，(Source)からのアクションがなかった場合の対処
] ]
[ 依頼者，受取人
[ (Goal)，(Source)
] ]
event[
]
event[
依頼者は受取人から商品を受け取る
]
condition[
condition[
一定時間，受取人からのアクションがなかった場合
一定時間，(Source)からのアクションがなかった場合
]{ ]{
依頼者は
(Goal)は受取人に
(Source)に
アクションを起こして欲しい旨を
アクションを起こして欲しい旨を
伝える
伝える
受取人は
(Source)は
アクションを
アクションを
再開させる
再開させる
依頼者は
(Goal)は受取人から
(Source)から
商品を
(Object)を
受け取る
受け取る
} }
12
Software Engineering Laboratory.
②例外イベント列の作成プロセス-手順8手順８：
必要に応じてユーザから表層表現のカスタマイズを
受け付ける．
[ 一定時間，受取人からのアクションがなかった場合の対処 ]
[ 依頼者，受取人 ]
event[ 依頼者は受取人から商品を受け取る ]
condition[ 一定時間，受取人からのアクションがなかった場合 ]{
依頼者は 受取人に 商品の配送要求を
アクションを起こして欲しい旨を
送る
伝える
受取人は アクションを 再開させる
依頼者は 受取人から 商品を 受け取る
}
表層表現変更後の例外イベント列
2007/2/23
13
Software Engineering Laboratory.
正常シナリオと例外イベント列の結合手法
例外イベント列の妥当性確認時は，
正常シナリオと例外イベント列の結合手法を用いて
例外シナリオを作成する
[ 一定時間，受取人からのアクションがなかった場合の対処 ]
[ 依頼者，受取人 ]
event[ 依頼者は受取人から商品を受け取る ]
condition[ 一定時間，受取人からのアクションがなかった場合 ]{
依頼者は 受取人に 商品の配送要求を 送る
受取人は アクションを 再開させる
依頼者は 受取人から 商品を 受け取る
}
例外イベント列
[ 物品を購入する ]
[ 依頼者，承認者，購買担当者，決裁者，受取人，ベンダー ]{
依頼者は 承認者に 依頼を 出す
承認者は 予算額を 確認する
承認者は 商品価格を 確認する
承認者は 依頼を 承認する
承認者は 購買担当者に 依頼を 提出する
購買担当者は 在庫を 確認する
購買担当者は 商品のベンダーを 選択する
決裁者は 承認印を 確認する
購買担当者は 注文書を 作成する
購買担当者は 注文書を ベンダーに 送付する
受取人は 受け取りを 登録する
依頼者は 受取人から 商品を 受け取る
依頼者は
if(一定時間，受取人からのアクションがなかった場合
依頼品が届いた事を 記録する
)
} then
依頼者は 受取人に 商品の配送要求を 送る
受取人は アクションを 再開させる
依頼者は 受取人から 商品を 受け取る
fi
依頼者は 依頼品が届いた事を 記録する
}
正常シナリオ
2007/2/23
例外シナリオ
14
Software Engineering Laboratory.
評価と考察 -評価のポイント• ５つの開発事例で作成されたシナリオ（＊）に本手法
を適用し，評価を行った
• 評価のポイント
（１）開発事例で作成された例外事象のうち，何％を提示す
ることができたか
（２）本手法で生成した例外イベント列のうち，何％が開発事
例に適用可能なものであったか
（＊）ユースケース実践ガイド／A・コーバーン／翔泳社
2007/2/23
15
Software Engineering Laboratory.
評価と考察 –提示した例外事象の評価提示した例外事象の評価結果内訳
開発事例に存在し，手法で提示
１２個
開発事例に存在し，手法で提示できず
７個
開発事例に存在せず，手法で提示
１２個
• 開発事例に存在する例外事象のうち，６３％（１９個中１２個）を
提示することに成功
2007/2/23
16
Software Engineering Laboratory.
評価と考察 –提示した例外事象の評価• 提示できなかった７個の例外事象を分析
– イベント文情報のみからは生成不可能なものであった
– 例）イベント文：「受取人は依頼者に商品を送付する」
例外事象：「商品が来るまでに依頼者が退職した」等
– イベント文情報から生成できない典型的な例外事象についてはチェッ
クリスト形式でユーザに提示することで対処可能
• 提示したものの，開発事例に存在しなかった例外事象１２個
を分析
– １２個中１０個は，他の例外事象と対処時の振る舞いが重複せず，有
用なものであった
– 残り２個は対処時の振る舞いが他の対処時の振る舞いと重複する，
無用なものであった
– 対処が重複し無用だと考えられる例外事象は提示しない手法への改
2007/2/23 善が必要
17
Software Engineering Laboratory.
評価と考察 –作成した例外イベント列の評価生成した例外イベント列の評価結果内訳
自動生成後，カスタマイズが不要だった
６個
自動生成後，カスタマイズが必要だった
２個
生成に失敗した
２個
評価不能（文献に対処が掲載されていなかった為）
２個
• 本手法で生成した例外イベント列のうち，８０％（１０
個中８個）は開発事例に適用可能なものであった
2007/2/23
18
Software Engineering Laboratory.
評価と考察 –作成した例外イベント列の評価• 生成に失敗した２個の例外イベント列を分析
– イベント文中に登場していないアクタと協調する振る舞い
が記述される必要があったパターン
• 例）イベント文：「承認者は依頼を承認する」
例外事象：「承認者は依頼を却下する」
対処：「承認者は依頼者に依頼を返送し，修正を要求する」
• 自動的に補完できなかった情報はその都度，ユーザに問い合わ
せることで対処可能
– 例外イベント列から再び正常シナリオに合流しなかったパ
ターン
2007/2/23
• 例）「保険金の請求が来たが，請求者が有効な保険に入っていな
かったため，請求を却下した」（保険金請求シナリオに戻らず）
• 「請求を却下する」という新たな正常シナリオであり，本手法によ
19
る支援対象外であると判断できる
Software Engineering Laboratory.
まとめと今後の課題
• まとめ
– 正常シナリオを用いた例外イベント列の作成支援手法を提
案
– 本手法で作成した例外事象の６３％（考察後７０％）が，ま
た作成した例外イベント列の８０％（考察後，９０％）が有用
なものであった
• 今後の課題
– 対処が重複した例外事象を提示している問題の解決
2007/2/23
20
Software Engineering Laboratory.
2007/2/23
21
Software Engineering Laboratory.
従来の手法
①
例外事象
の導出
正常シナリオ，
業務への理解度
例外事象の案
例外事象
ユーザ
例外シナリオ
動作概念
例外事象テンプレート
例外事象
データベース
正常シナリオ
②
例外シナリオ
の作成
例外事象
例外シナリオ
テンプレート
例外シナリオ
データベース
例外事象の種類のみで対処方法を決定．
アクタの特性によって対処方法を変化させることが不可能．
2007/2/23
22
Software Engineering Laboratory.
従来の手法
①
例外事象
の導出
正常シナリオ，
業務への理解度
例外事象の案
例外事象
ユーザ
例外シナリオ
動作概念
例外事象テンプレート
例外事象
データベース
正常シナリオ
②
例外シナリオ
の作成
例外事象
例外シナリオ
テンプレート
例外シナリオ
データベース
対処方法と対処後の流れをテンプレートから作成しているため，
対処後の流れが正常シナリオと異なるケースが発生．
2007/2/23
異常が起きる前の振る舞いを例外シナリオに記述することが不可能
23
© Copyright 2024 ExpyDoc
