ユースケースに対する2つの疑問とその答えを提示するICONIXプロセス

今日はこちらのオンラインセミナーに参加しました。

【8/21(金) 第3回 チェンジビジョンWEBセミナー】 ICONIXプロセスから学ぶオブジェクト指向モデリング

スピーカーは @hirodragon112 さんです。

Twitterハッシュタグ#astah

自分の中の疑問がクリアになるばかりか、新たな課題を発見できてとても良かったです。なにより学ぶための勇気も湧いてきました。ありがとうございます。

ユースケースに対する2つの疑問

さて、ユースケースを学び始めて間もないわけですが、ユースケースに対して2つの疑問があります。

  1. ユースケースから実装までの距離は大きい気がするけど、どうするんだろう?
  2. ユースケース自体を検証するにはどうすればいいんだろう?

1. ユースケースから実装までの距離は大きい気がするけど、どうするんだろう?

ユースケースは最終的にソースコードで表現されると思いますが、その間の距離が非常に遠いと思っています。 端的に言えば、「(完璧な?)ユースケースだけあってもプログラムの実装はできない」ということです。

これは実体験に基づいています。仲間内で「モデリング会」や「モデリング&実装会」をやっていたりします。大抵の場合「ユースケースを考えよう」という流れで棒人間を書くのですが、なかなか実装まではいかない。あるいは、実装したとしてもユースケースの存在が消えてしまう。

(※ここでいうユースケースは、ユースケースモデルの場合がほとんど。ユースケース記述ではない。)

2. ユースケース自体を検証するにはどうすればいいんだろう?

ユースケースが大事そうなことは(なんとなく)分かりました。

間違ったユースケースや正しいユースケースがあることも分かりました。

ユースケースを使って次の分析や設計を進めていくことも分かりました。

しかし、それだけ大事なユースケースそれ自体の検証がよくわからないのです(自分の研鑽が足りないだけかもしれない)。

なんらかの方法でユースケースを検証できければ、洗練も何もないと考えています。ソフトウェア「工学」なのであれば尚更です。

ロバストネス分析が2つの疑問の答え(になりそう)

今日のセミナーおよびセミナー終了後の雑談タイムでのやるとりに自分の解釈をのせると、「ICONIXプロセスにおけるロバストネス分析ユースケースの検証および洗練に貢献する」です。

これで「疑問2. ユースケース自体を検証するにはどうすればいいんだろう?」は解決の兆しがみえてきました。

また、ユースケースと実装の間に少なくとも1ステップ加わるわけですから「疑問1. ユースケースから実装までの距離は大きい気がするけど、どうするんだろう?」の解決も前進です!

嬉しいポイントとしては、ロバストネス分析のやり方はICONIXプロセスとして手順化されている点です(しかも、それが日本語の書籍になっている!)。

実はロバストネス分析はOOSE本にも書いてある

さて、なんとなーく、「ICONIXプロセス最高!」とか「これから勉強するぞー!」という興奮状態ですが、ちょっとストップ。

ICONIXプロセスの生みの親は、Doug Rosenberg(ICONIX Software Engineering社の設立者) ですが、ロバストネス分析の生みの親は Ivar Jacobsonです(同時に、ユースケースの生みの親でもあります)。

Ivar Jacobsonが著した『オブジェクト指向ソフトウェア工学OOSE―use‐caseによるアプローチ』(以下、OOSE本)にもロバストネス分析は登場します。

OOSE本で提唱されているプロセスはだいたいこんな感じです。

  1. 要求仕様書
  2. 分析プロセス
    1. 要求分析 → 要求モデル(ユースケース, インタフェース記述, 問題ドメインモデル)
    2. ロバストネス分析 → 分析モデル
  3. 構築プロセス
    1. 設計 → 設計モデル
    2. 実装 → 実装モデル(ソースコード)
  4. テストプロセス

OOSE本にちゃんと書いてありましたね(読む気力が湧いてきますね)。

ちょっと不思議なのは、ロバストネス分析という言葉が本文中にあまりでてこないことです。「ロバストネス(Robustness)」の日本語訳である「頑健」は出てくるのですが。

また、「ロバストネス分析」が索引にないんですよね。なぜだろう。

ロバストネス分析の元ネタはOOSE本(というか、Ivar Jacobson)

ユースケース駆動開発実践ガイド』の序文にこうあります。

我々が3つの方法論(注: Booch法、OMT、Objectory)の最良の部分を集大成したもの(その数年後のこれらが結合されてUMLとなるわけですが)は、現在ではICONIXプロセスと呼ばれています。 (中略) 顧客に対してこの手法を教えることで経験を積んだ結果、ヤコブソンの手法(ユースケース図、ロバストネス図、シーケンス図)が正しく利用可能ということが明確になりました

Rosenbergたちが、Jacobson(ヤコブソン)の手法を検証し、再現性のあるプロセスとして洗練させたみたいですね。

そう考えると、『ユースケース駆動開発実践ガイド』を読むことは、OOSE本の検証の理解を深めることにつながるわけですね。これは嬉しい発見。

セミナーに参加してよかった

セミナーは「ICONIXプロセス」が中心的話題でしたが、現在の自分の興味は「ユースケース(use-case)」です。

実は、セミナー参加の目的は「ICONIXプロセスを理解したい」ではありませんでした。本当の動機は「ユースケースを大事にしているICONIXプロセスなるものがあるらしい。では、それ理解すればユースケースのこと理解も深まるかもしれない」です。

今回のセミナーはこの目的を満たしてくれました。この記事を書いているのが何よりの証拠だと思います。

参考文献

  1. ICONIXプロセスから学ぶオブジェクト指向モデリング/ICONIX for Object-Oriented - Speaker Deck
  2. ユースケース駆動開発実践ガイド』
  3. オブジェクト指向ソフトウェア工学OOSE―use‐caseによるアプローチ』

他の方のまとめブログ