extend は必要なのか？

アリスター・コーバーンの「ユースケース実践ガイド」では、extend とよく似た拡張ユースケースという概念を定義しています。そこで、「拡張ユースケースは理解や維持が困難なため、使用するのは必要な場合に限ってください」と主張しています。確かに、部分を表現する include と比較すると、代替フローを記述する extend は図的に見てもわかりにくいものがあります。また、拡張する側のユースケースの発動条件を基底ユースケース（拡張される側のユースケース）に書かないため、基底ユースケースのユースケース記述を読んでも流れを把握できないことも問題です。

私は、理解や維持が困難な extend は実装すべきではないと考えていました。ツールのコンセプトも、必要最小限の機能を実装することを考えていたため、extend は除外する方向で実装を進めていました。

ところが、前職の会社の先輩から示された例で心が動きました。その例とは、「電子マネーで商品を買う」という基底ユースケースがある場合、残高確認時に「オートチャージ」という拡張ユースケースがあり得るというものです。平易な例であり、よく遭遇しそうなケースです。ただ、オートチャージの例は include でも記述可能です。

前述の「ユースケース実践ガイド」を調べてみたところ、extend は基底ユースケースの変更回数を減らすテクニックであることがわかってきました。基底ユースケースになるような重要なユースケースは、基本的なものですから、あまり変更はしたくありません。extend を使うことで、基底ユースケースを変更しないでユースケースの拡張が可能になります。前述の電子マネーの例で言えば、電子マネーの残額が行っていより少なくなった時にオートチャージを行うという処理を、次のイテレーションに回すような場合に extend は適切ということになります。

結論としては、extend は理解と維持が難しいが、いくつかの条件の下で十分役に立つ機能であることがわかりました。

まとめ

結論としては、extend も使用ケースは十分にあると判断し、ツールとしてはこれを実装しました。以下、上記の議論を経て Kodougu に実装したユースケース図は以下のようになっています。ご参照ください。（IE/Firefox で動作します。Opera でも閲覧だけならできます。Firefox 推奨、動作速度が 10 倍くらい違います。）