【TopSE修了制作発表資料】段階的詳細化をサポートするUML開発環境
2008年3月4日
日本電気株式会社 海津 智宏
■ SystemDirectorは、NECの商標です。■ UMLはObject Management Group Inc. の商標または登録商標です。■ Eclipse は米国およびその他の国におけるEclipse Foundation, Inc. の商標もしくは登録商標です。■ その他記載されている会社名、製品名は、各社の商標または登録商標です。
2
目次
• 背景と目的• 修了製作テーマ• 検証の例• 考察
3
目次
• 背景と目的• 修了製作テーマ• 検証の例• 考察
4
背景
ソフトウェアに求められる機能の複雑化・多様化
モジュール化による、追跡容易性・再利用性・変更容
易性・拡張性の向上
形式手法による、品質の向上・手戻り工数の削減
•J2EE、Strutsなど多くの実装技術が存在し、広く利用されている。•KobrAなどのコンポーネントベース開発方法論が提案されている。
•形式的な設計記述・仕様記述が困難、現場への適用は限定的
設計から実装を追跡できない
変更が困難
拡張が困難
再現性の低いバグが発生
作業工数不足
5
目的
• モジュール化を意識した設計から設計記述・仕様記述を自動生成する。
• 設計を網羅的に検証することで、開発方法論などで決められた枠組みからある程度外れていても、設計の問題点を発見できるようにする。
モジュール化を前提とした開発方法に形式手法を適用することで、品質の向上・手戻り工数の削減を目指す
6
目次
• 背景と目的• 修了製作テーマ• 検証の例• 考察
7
修了製作概要
段階的詳細化をサポートするUML開発環境
要求獲得ユースケース
モデル作成
実装
UMLモデル
ソースコード
UMLモデルリファインメント
詳細化の検証
詳細化の検証
UML
詳細化時の間違いを発見して
警告するコンポーネントの分割による段階的詳細化を前提とする
標準記法のUMLを使用
8
コンポーネントの分割による段階的詳細化
コンポーネント
コンポーネント
コンポーネント コンポーネント
コンポーネント
コンポーネント コンポーネント
コンポーネント コンポーネント
全ての機能を実現する単一のコンポーネントから始め、詳細化の各段階で機能ごとにコンポーネントを分割する。
※ Fraunhofer IESE で提案されている KobrA 開発方法論を参考にしています。
詳細化詳細化
全ての機能を単一のコンポーネントで実現
全ての機能の窓口となる
機能のまとまりごとにコンポーネントを作成
より細かい単位のコンポーネントや、実装上必要となるコンポーネントを追加
9
検証の内容
getList
list
getItem
item
A B
getList
list
getItem
item
A B C
getList2list
getItem2item
コンポーネント A, B 間に流れるメッセージは変わっていない
詳細化の各段階で記述するシーケンス図を入力とし、詳細化前に設計したメッセージ送受信が詳細化後の設計でも実現されていることを検証する。
詳細化前のシーケンス図 詳細化後のシーケンス図
10
Eclipse
SystemDirectorApplication Modeler
修了製作の実装方式
変換ツール
変換ツール
CSP
CSP
詳細化の検証
FDR2
UML記述
UML記述にSystemDirector Application Modelerを、詳細化の検証にFDR2を利用。UMLから検証用言語への変換ツールをEclipse環境上に独自実装。
SystemDirector Application Modeler:NECの提供するUML作成ツールEclipse:Eclipse Foundationの提供する統合開発環境CSP:並行プロセス間のメッセージ送受信を形式的に記述する言語FDR2:Formal Systemsの提供するCSP検証ツール
シーケンス図シーケンス図シーケンス図
シーケンス図シーケンス図シーケンス図
11
変換の例
getList
list
getItem
item
A B
A = getList → list→ getItem → item → A
B = getList → list → B□getItem → item → B
シーケンス図
CSP ※実際よりも簡略化しています
コンポーネントごとに、送受信するメッセージの順序をCSPで表現する。
コンポーネント A は getList → list → getItem → item の順に送受信
コンポーネント B は getList → list もしくは getItem → item の順に送受信
12
不確定なメッセージの変換
request
ok
A B
シーケンス図
request
ng
A B
A = request →(ok → A □ ng → A)
B = request →(ok → B П ng → B)
CSPの外部選択(□)。任意のメッセージを受信できる。
CSPの内部選択(П)。送信するメッセージはBの内部状態
により決定される。
CSP ※実際よりも簡略化しています
CSPの外部選択・内部選択により、複数の可能性があることを表現する。
13
詳細化の検証
詳細化前後で共通するコンポーネントの振る舞いのみを抽出し、振る舞いが変わっていないことを検証する。
詳細化前のCSPコンポーネント: A,B
A = …B = …
詳細化後のCSPコンポーネント: A,B,C
A = …B = …C = …
マージしたCSP検査式:
SYSTEM2 からコンポーネント C を隠蔽するとSYSTEM1 と SYSTEM2 は同一
SYSTEM1 SYSTEM2
FDR2で検証
差分がコンポーネントCであることを検出して検査式を自動生成
14
詳細化以外で検証可能なこと
• 仕様の漏れの検出
• コンポーネントの再利用の可否判断
exec
ok
A Breq1
exec
ng
A Breq1
exec
ok
A Breq2
proc
ng
A Breq2
入力したシーケンス図
execメッセージに対する返信はokとngの2つの場合があるはず
漏れの指摘
A
B C
A
B D
E FコンポーネントD・E・FはコンポーネントCと置き換え可能
15
目次
• 背景と目的• 修了製作テーマ• 検証の例• 考察
16
ユースケース
例として、ショッピングサイトのシステムを考える。• ユーザーは、商品一覧の取得・商品の購入・レシピの表示ができる。• 利用にはログイン・ログアウトが必要。
17
ユースケースをもとに作成したモデル (Step1)
単一の「System」コンポーネントで全機能を提供
ユースケースごとに、ユースケース記述相当のシーケンス図を用意
ユースケースの事前条件・事後条件を記述
18
CSPへの変換
(1) UML情報を格納したファイルを選択
(2) 「CSPに変換」メニューを実行
19
自動変換で得られた、Step1のCSP記述
User System
COMPO_(System.default_) =(call_.getItems.User.System ->call_.items.System.User ->COMPO_(System.default_)[]call_.getRecipe.User.System ->call_.recipe.System.User ->COMPO_(System.default_)[]call_.login.User.System ->
(call_.ng.System.User ->COMPO_(System.default_)|~|call_.ok.System.User ->COMPO_(System.default_))
[]call_.showCart.User.System ->call_.empty.System.User ->
……
COMPO_(User.default_) =call_.login.User.System ->
(call_.ng.System.User ->COMPO_(User.default_)[]call_.ok.System.User ->COMPO_(User.loggedin))
COMPO_(User.loggedin) =(call_.getItems.User.System ->call_.items.System.User ->COMPO_(User.loggedin)[]call_.getRecipe.User.System ->call_.recipe.System.User ->COMPO_(User.loggedin)[]call_.showCart.User.System ->
……
20
詳細化 (Step2)
「ユーザー管理」 「商品販売」「レシピ配信」 という機能に着目してコンポーネントを分割
Systemを窓口として、機能ごとに処理を振り分ける
21
自動変換で得られた、Step2のCSP記述
User
COMPO_(User.default_) =call_.login.User.System ->
(call_.ng.System.User ->COMPO_(User.default_)[]call_.ok.System.User ->COMPO_(User.loggedin))
COMPO_(User.loggedin) =(call_.getItems.User.System ->call_.items.System.User ->COMPO_(User.loggedin)[]call_.getRecipe.User.System ->call_.recipe.System.User ->COMPO_(User.loggedin)[]call_.showCart.User.System ->
(call_.cartInfo.System.User ->(call_.clearCart.User.System ->call_.ok.System.User ->COMPO_(User.loggedin)[]call_.back.User.System ->call_.ok.System.User ->COMPO_(User.loggedin)[]
……
MarketSite
COMPO_(MarketSite.default_) =(call_.getItems.System.MarketSite ->call_.items.MarketSite.System ->COMPO_(MarketSite.default_)[]call_.addToCart.System.MarketSite ->call_.ok.MarketSite.System ->COMPO_(MarketSite.haveCart)[]call_.showCart.System.MarketSite ->
……
System
COMPO_(System.default_) =(call_.ok.MarketSite.System ->call_.ok.System.User ->COMPO_(System.default_)[]call_.getItems.User.System ->call_.getItems.System.MarketSite ->call_.items.MarketSite.System ->call_.items.System.User ->COMPO_(System.default_)[]call_.getRecipe.User.System ->call_.getRecipe.System.RecipeSite ->call_.recipe.RecipeSite.System ->call_.recipe.System.User ->COMPO_(System.default_)[]call_.login.User.System ->call_.login.System.UserManager ->
(call_.ng.UserManager.System ->call_.ng.System.User ->COMPO_(System.default_)[]call_.ok.UserManager.System ->call_.ok.System.User ->COMPO_(System.default_))
……
RecipeSite
COMPO_(RecipeSite.default_) =call_.getRecipe.System.RecipeSite ->call_.recipe.RecipeSite.System ->COMPO_(RecipeSite.default_)
UserManager
COMPO_(UserManager.default_) =(call_.logout.System.UserManager ->call_.ok.UserManager.System ->COMPO_(UserManager.default_)[]call_.login.System.UserManager ->
……
22
CSPのマージ
(1) 詳細化前後のCSPファイルを選択
(2) 「CSPをマージ」メニューを実行
23
検証
検証失敗
詳細化後のシーケンスが詳細化前のシーケンスと
整合していない
24
問題の解析
ログアウト→再ログイン後に問題が発生
emptyが期待されているのにcartInfoを返そうとしている
25
シーケンス図の確認
Step1
カートが空の時にログアウト
カートが存在する時にログアウトすると、カートをクリアする。
Step2
カートの有無はMarketSiteが管理
ログアウト時はUserManagerのみを使用(カート情報を更新しない)
26
ログアウト処理の修正
ログアウト時にカートをクリア
検証成功
Step1からStep2へ正しく詳細化できた
※詳細化後の動作が正しい場合には、Step1に戻って仕様を修正する。
27
目次
• 背景と目的• 修了製作テーマ• 検証の例• 考察
28
検証の効果
• 詳細化時に検証を実行することで、詳細化前後での仕様の違いを早期に発見できるようになった。
– 詳細化が間違っている場合には詳細化後のUMLを修正する(品質向上・手戻り工数削減)。
– 仕様変更が必要な場合、詳細化前のUMLに戻って修正する(仕様と実装のずれをなくすことができる)。
29
今後の課題
• 詳細化のパターンに合わせた検査規則の策定– コンポーネントの追加(今回の発表)– メッセージのやりとりの詳細化– 機能の追加– 機能の削除– etc…
• 記述力の向上– シーケンス図の表現力の向上– ユースケース記述からCSPへの変換のサポート
• 効果測定– 実際の開発に適用することで、本当に効果が出るかを調
査したい。