アクターが一人なら関連の線を引かなくてもいいんじゃ？

Prompt

ユースケース図を描くときに、
アクターはただ一人で、示されているユースケースをそのアクターがすべて利用可能な時は、
アクターとユースケース間に関連をわざわざ引く必要性を感じないんだけど、これは省略できる？
そもそも関連はどのぐらいの粒度で表すべき？

なるほど！ユースケース図におけるアクターとユースケースの関連（線）について、君の疑問、すごくよくわかるよ！「一人しかアクターがいないのに、全部線で繋ぐのって面倒だし、図がゴチャゴチャするだけじゃない？」って思うのは、まさに多くの人が感じる疑問点なんだ。

情報工学を学ぶ君が、図の**「表現の効率性」と「情報伝達の明確さ」**のバランスを追求しているのは、すごく良い視点だよ！

結論から言うと、**「推奨されるUMLの作法としては、基本的に省略しない方が良い」けど、「現実的には、図の目的や対象読者、複雑度に応じて判断されることもある」**といった感じだよ。

UML（統一モデリング言語）のユースケース図の規約では、アクターとユースケースの間には**「関連（Association）」という線を引くことになっているんだ。これは、「アクターがそのユースケースと相互作用する（利用する）」**ことを明示的に示すためのものなんだ。

なぜ省略しない方が良いとされるのか:
- 明確性の担保: 誰が見ても、どのアクターがどのユースケースにアクセスできるのかが一目瞭然になる。
- 曖昧さの排除: 「このアクターはここに繋がってないけど、暗黙的に使えるの？」というような疑問が生じるのを防ぐ。
- 将来の拡張性: 今はアクターが一人でも、将来的に別の種類のアクター（管理者、ゲストなど）が追加されたときに、それぞれの関連を明確に区別できるようになる。

君が感じるように、アクターが一人でユースケースの数が非常に多い場合、すべての関連を引くと、確かに図はスパゲッティ状態になることがあるよね。そんな時は、以下のような対応が取られることもあるよ。

「ログイン」などの共通ユースケースは記述で補う:

以前話したように、「ログインする」のような、ほとんどのユースケースの前提となるものは、ユースケース図には描かず、個々のユースケースの「事前条件」としてドキュメント（ユースケース記述）に記載することが多い。
パッケージングでグルーピングする:

関連するユースケースを「パッケージ」で囲んでグループ化し、そのパッケージ全体とアクターを関連付ける、といった描き方をするケースもある。ただし、これもアクターと個々のユースケースの間の関連を完全に省略するわけではない。
図の目的を明確にする:

もし、そのユースケース図の目的が、システム全体の機能の一覧を大まかに示すことにあり、個々のアクターとユースケースの関係の厳密な記述が主ではない場合、敢えて全ての関連を描かないという選択をする場合も、なくはない。ただし、これは非常に限定的な状況で、図を見た人が混乱しないような工夫（凡例や説明）が必要になるよ。

アクターとユースケースの関連は、UML的には基本的に省略しない方が良い。
ただし、図が極度に複雑になる場合は、「ログイン」のように暗黙的な前提となるものはユースケース記述で補うなど、工夫を検討する余地はある。
**関連の粒度は、あくまで「システムの外部から見た機能とアクターの相互作用」**に焦点を当て、必要に応じて <<include>> や <<extend>> でユースケース間の関係を示すのがベストだよ。

君が感じた疑問は、まさに「UMLモデリングのベストプラクティス」と「現実のドキュメント作成におけるバランス」の狭間にある、とても良い問いだったね！

Garden