ユースケース図 - ntuf/Tips GitHub Wiki

ユースケース図では何がわかるのか？
システムの範囲（できること・できないこと）を明確化できる
(細部の粒度については迷ってしまうと思うが、それがわかる粒度にすればいいということとしてみる)
何ができて、　振る舞いを書くが、何をしないのか　内部構造については記述しない

これらの表現を使うと何がわかるのか
　汎化
　　こういうアクターやユースケースも含まれていますよ的に使う。
　include　包含
　　has a関係を表現する　必ず含む 　関数が呼び出される感じ
　　共通の関数呼び出しとか
　extends　拡張
　　拡張点から全てのステップが呼び出される。
　　　『ユースケース駆動開発実践ガイド』
　　　　拡張と包含の違いは、仕事上はさほど意味はない。らしい。

<>というのがある。拡張という。あるユースケースの中のある手順におけるオプション（代替フロー）を示す。これがなくてもユースケースの本来の目的は達成できるところがポイント。たとえば、商品を買うというユースケースがあったとして、そのなかに代金を支払うという手順があるとする。通常は現金で支払うが、カードで支払うこともできることを表現するのにextendが使える。メインのユースケース側には拡張点といってどの手順でextendのユースケースを利用するのかを明記する

                                    <>基本パッケージツアー　←---- オプショナルツアー  拡張点

拡張点は矢印を受けている方に書く
ユースケースを書いていく進め方
①アクターを列挙
②アクターごとのユースケースを列挙
　　○○（アクター）が「××する（ユースケース）」
③ユースケースを整理する
　「○○（アクター）が　△△(ex.商品)を××する（ユースケース）」　に変更していく
　　商品を検索するとか
　・同じユースケースが他のアクターでも発生しないか考える。

もう一度聞くと、これらの種類の記述を使うことによって何が良いのか？また、包含や拡張を使うと書かないはずの内部構造を外だしにしてちょっと書いていることにならないのか？
まだユースケース図の意義が不明確。ないよりあったほうがいいレベルで、ぼんやりしている。
これを書くのは何がゴールかわからず、無駄に記述を続けそう。
例えば「検索する」というユースケースであったら、ソートできるのかとか部分一致検索ができるのかとか検索結果をCSV出力できるのかとかシステムでできることの境界を明確にするということならそれらも細かく必要ということでいいのか。結構大きなシステムでは図がだいぶ煩雑になる。
おそらく、それらを書くことを想定していない。〇〇が〇〇を〇〇するレベルの記述で良いのだろうし。でも、それだけだと、システムの境界を示したことになるのだろうか。
ユースケースだから、どのように使うかをしたいこと
使い方と用途を書いていけばいいのだろう。