コメントを書く
2007-10-17 10:10 :
Kodougu でユースケース図の実装を開始した
最近、Kodougu でユースケース図の実装を開始しました。いざ作り始めてみると以下の点をどうするかで悩み始めています。
・ Include/Extend をどうするか（特に拡張点の扱いは悩ましい）
・ システム境界はどうするか（UML 2.0 的には分類子であり、名前空間）
・ なんかユースケースの初期サイズが大きい(^^;
現在、Kodougu では UML は「Tiny UML 2.0」という名称で実装しています。名前のとおり、Tiny な実装を目指していて、ごてごてとした機能を嫌います。私の好みとしては、システム境界は単なる四角にして、Include は実装、Extend はいらないって感じですかねぇ・・・。
続きを読む
Posted by あかさた（編集）
2007-10-17 23:49 : GLAD!!
include、extend、汎化は欲しいです。
拡張点はいりません。extend にノートでいいんじゃないかな?
2007-10-18 00:32 : あかさた
コメントありがとうございます！
汎化は必須ですね！ さっそく実装してみました。
extend ってどんな時に使います？ なんか extend は誤読（私が読み間違う）が多くて苦手なんですよ・・・。orz
# 実装は簡単なので、必要性が確認できれば即入れられます。
# ユースケース図の実装はここまでで 30 分もかかってませんし。
2007-10-18 17:25 : あかさた
とりあえず、ユースケース内部に拡張点を書きこむ機能以外は全機能を実装しました。システム境界は UML 1.x 並ですが・・・。
2007-10-19 01:15 : GLAD!!
> extend ってどんな時に使います？
ヤコブソンのアスペクト本によれば、サブフローをユースケースとして切り出すのが include で、代替フローをユースケースとして切り出すのが extend ですね。
なかなか良い例が思い浮かばなかったんだけど、電子マネーで、
商品を買う <- <<extend>> - オートチャージする
なんてどうでしょうか?
2007-10-19 02:04 : あかさた
こんな遅い時間にありがとうございます！
私も調べてみました。コーバーンのユースケース本によると、ワープロソフトで、「文書を編集する」の拡張ユースケースとして、「スペルチェックを行う」という例が挙げられていました。この本では、拡張ユースケースは主ユースケースを中断して実行されるユースケースであり、基底ユースケースを制御しないものとして定義していました。
拡張は繰り返し開発において、基底ユースケースの変更回数を減らすテクニックだそうです。
電子マネーの例なら、拡張点として「残額確認」などを定義しておいて、オートチャージなどは次以降のイテレーションで検討するような場合に拡張は有効だそうです。ただ、代替フローは「チャージ金額が一定額を下回る場合、オートチャージを行う」というような記述で、包含ユースケースとしても記述できます。この辺、レビューの手間とプロジェクトの規模などバランスを見ながら選択するようです。
この本では拡張ユースケースは理解と維持が難しいため使用を必要最小限に抑えた方が良いとのことでした。私も同感です。特にテキストベースでユースケースを記述しなおしたときに、include は直感的なのですが、extend が直感的に書けませんでした。
いずれにしても、便利な機能には違いないのでツールとしては実装しました。