【ICONIX】 ロバストネス分析で、ユースケースとドメインモデルを堅牢にしよう(｀・ω・´)

• Twitter
• Facebook
• B! はてブ
• Pocket
• Feedly

前回作成したユースケース記述を元に、ロバストネス分析を実施してみましたｗ

これにより、ドメインモデルとユースケースの曖昧さや不完全さが改善され、
『実際の設計を行う前の、振る舞い要求を検証』することが出来ます(｀・ω・´)ｂ

ロバストネス分析で何が(ﾟдﾟ)ｳﾏｰなのか？

• 要求分析(ユースケースなど)と、実際の設計(シーケンス図など)のギャップを埋めてくれる
• ドメインモデル作成時に見つけられなかったオブジェクトを『発見』出来る
• ユースケースから曖昧さを除去出来る

結果として、ユースケースが駆動する設計や実装が可能になりますヽ(・ω・)ﾉ

そもそもロバストネス図って何？

ユースケース記述を図にしたもので、上図のような図です ( ﾟДﾟ) ﾑﾎｰ

名称	記号	意味
バウンダリ		システムと外界との「インターフェイス」で、画面などが該当する。 ユースケース記述の名詞。
エンティティ		ドメインモデルのオブジェクト。ユースケース記述の名詞。
コントローラ		バウンダリとエンティティをくっつける「動作」。 ユースケース記述の動詞。

ロバストネス分析では上記の3種類の記号を使って、「名詞-名詞-動詞」の形式で書かれたユースケース記述を、
「名詞-動詞」、「動詞-動詞」の形式で図にしてゆきますｗｗ　(名詞と名詞は直接繋げられません。)

ユースケース記述	ロバストネス図	シーケンス図
名詞 (画面など)	バウンダリ	オブジェクトインスタンス
名詞 (データなど)	エンティティ	オブジェクトインスタンス
動詞	コントローラ	メッセージ

この図は、そのまま上記のような対応でシーケンス図に変換可能です (〃▽〃  )素敵・・・

では、実際にどう描けば良いのか？(´･ω･`)

astah communityを使いながら描いてみました。
Enterprise Architectだと誤りチェックしてくれるそうですが、そんな高級品持ってません(；´∀｀)

1. astah上でクラス図を作成します　(これにロバストネス図を描きますｗ)
2. ロバストネス図に、ユースケース記述を貼り付けます
3. まずは、基本コースのストーリーを順に記号にして結んでゆきます
4. 「名前がついていない」or「曖昧な名前」のバウンダリに名前をつけます
5. さらに、バウンダリに「表示する」or「初期化する」コントローラを結びつけます
6. 代替コースも色を替えて、同じように図にしてゆきます
7. 画面プロトタイプなども眺めながら、オブジェクトの属性を見つけます

上記作業中は、都度ユースケース記述とドメインモデルを更新してゆきましょうｗ
ここまで来ると、ドメインモデルが静的モデルに進化しているはずです！(・∀・)

作業風景はこんな感じになりますｗｗ

困ったよ？(´・ω・｀)

Q.うまく描き始められないよ？(´・ω・｀)
A.ユースケースの始まりが間違ってるかもしれません。
別のユースケースの一部が冒頭部分に含まれていないかチェックしましょう(｀・ω・´)

Q.「～ボタン」オブジェクトで、図がいっぱいになっちゃったよ？(´・ω・｀)
A.『画面/ページ/フレーム』よりも細かい「GUI部品」(～ボタン など)を、オブジェクトにしてはいけません。
GUI部品の割り当ては、詳細設計フェイズでやりましょう(｀・ω・´)

Q.画面にいちいち「表示する」とか「初期化する」コントローラつけるの面倒くさいよ？(´・ω・｀)
A.確かにロバストネス図がごちゃごちゃしてしまうかもしれません。
しかし詳細設計時に、画面などの初期化処理をきちんと忘れないためにも必要です。
『初期化時にどこどこからデータ取得する』というような処理を見逃さないためです。(｀・ω・´)

最後にチェックしてみましょう☆

• ユースケース記述の、全ての代替コースが図になりましたか？
• ユースケース記述の、全ての操作や機能を見つけられましたか？
• 全てのデータの流れを、エンティティ間に挿入出来ましたか？

チェックOKなら、ユースケースとドメインモデルがより洗練され、シーケンス図を描き始める準備が整ったことになります(｀・ω・´)ｂ

参考資料

より詳細な内容は、こちらの書籍をご覧下さい(｀・ω・´)

※2012-11-05：バウンダリ、エンティティ、コントローラの画像が間違っていたのを修正しました。
※2012-11-24：参考資料を追記しました。