ユースケース図における依存、拡張、包含について

質問

UMLでユースケース図を作成していますが、依存、拡張、包含が今一つピンと来ません。
簡単な例で言うと、
ユースケースA：社員情報を登録する。
ユースケースB：社員情報を修正する。
という2つのユースケースがあった場合、AとBにはいずれかの関係が成り立つのでしょうか?
ユースケースBで提供されるサービスは、ユースケースAというサービスが提供されてはじめて意味のあるサービスになると思います。
社員情報を登録できなければ修正なんて発生し得ないわけですから。
依存、拡張、包含について上手く自分の中でイメージができません。
それぞれについてどう考えればいいのでしょうか?

回答No.1

anmochi

ユースケースAとBに関係は無いと思うよ。以下、説明の為に、「1枚のユースケース図で表される」ものを機能、「ユースケース図内で1つの○に入る」もの(本来は「ユースケース」)を処理と表記する。

　確かに処理フローとしては、処理Aがなされない場合、処理Bの実行は無意味であると言える。しかし、ユースケース図の主目的は、ターゲットシステムの全処理を羅列し、それらの処理群を使用するアクターとの関連を図示するというものだ。
　つまり、Bが、「前提のデータ」として社員情報が無ければいけないとしても、「社員情報修正」という処理そのものにはAは関係が無い。Bは、あくまで社員情報とやりとりする。

例えばアクターを「人事処理係」としよう。

　　　　　　（社員情報登録）
人事処理係＜
　　　　　　（社員情報修正）
↑うまく表示できんかったらごめん。人事がアクターで()が処理だ。

というユースケースは成り立つが、登録と修正の間に関係は存在すべきではない(処理の疎結合)。

依存というのは、例としてはあまり良くないが、例えば、ターゲットシステムが「人事システム」として、その中に出退勤管理機能があり、タイムカード打刻処理とタイムカード修正処理があるとする。打刻は全社員が行えるが、修正は庶務課の人のみが行えるとする。すると、必要な処理は、これ以外に「アクターの課を確かめる処理(権限認証処理)」があるよね。ここで、修正処理は権限認証処理が必要だから、修正処理－<<include>>→権限認証処理となるはずだ。もちろん、そもそも社員かどうか確かめるために、打刻処理－<<include>>→権限認証処理となっても良い。

拡張は、今の例で言うと打刻処理に対して、遅刻があった場合に、打刻と同時に言い訳入力処理を行えるようにする時に、打刻処理←<<extend>>－理由入力処理となる、というように、元々の処理にちょっと足し合わせる時に使うのかな。

包含は、同じ<<include>>を使うけど、ユースケースを分割する時に使う事が多いようだ。フローチャートで言う「定義済み処理」かな。

これが私なりのユースケースの解釈だ。何か参考になれば良いが・・・・。

お礼

ご回答ありがとうございます！
"ターゲットシステムの全処理を羅列し、それらの処理群を使用するアクターとの関連を図示するというものだ。"という説明がすごくわかりやすいです。
なにかもやもやしたものが消えた気がします。
とても助かりました！！