UMLを学ぶETロボコンメンバーに送るUML講座２〜ユースケース図〜

#内容アウトライン
　本記事ではユースケース図について記述します。

　・ユースケース図って？
　・ユースケース図を構成する要素
　・汎化関係
　・include
　・extension
　・自省を込めた注意点
　・実際の描くときの流れは？
　・まとめ

#ユースケース図とは？
###なにを目的とした図なのか？
　ユースケース図は、システムを機能面から見つめるための図です。

　機能をあらかじめ抽出し、ユースケース図を作成しておくことで得られる大切な効果は以下のようになります。

・誰に対して、どのような機能を提供するのかが明確になる
・システムとシステム享受者との接点が明らかになる

　一つ目の、**「誰に対して、どのような機能を提供するのかが明確になる」**というが一番大切な効果です。

　また、ユースケース図をあらかじめ考え、まとめておくことで、のちのち大きな仕様変更が発生しないようにすることもユースケース図を描く効能として存在します。

###ユースケース図を構成する要素
大まかには以下の三つの要素で構成されています。

-アクター
-ユースケース
-システム境界線

　**アクターはシステムを利用する人、ユースケースはシステムの持つ機能システム境界線はシステムとアクターの境界を示します**。
　アクターとアクター、アクターとユースケース、ユースケースとユースケースは、**関係を表す線によってその関係性が示されます**。
　イメージとしてはこんな感じです。

<img width="440" alt="スクリーンショット 2018-12-04 21.35.19.png" src="https://qiita-image-store.s3.amazonaws.com/0/219573/87b11d8b-07e1-ce4b-b00f-8c2fe815d728.png">


　棒人間がアクターで、機能を表す文字列を楕円で囲ったものがユースケースです。
　システム境界線は、上図のように**システムの機能を表すユースケースを四角で囲うことで、アクターとシステムの境界を表現しています**。

　また、**アクターとユースケースを結ぶただの線は、両者の間に関連があることを表します。**

　要素の基本的な説明は以上になります。
　これ以下は、この項で説明した基本の線以外の関係を表す線について説明していきます。

###汎化・特化の関係
　汎化・特化の関係は、アクターとアクター、ユースケースとユースケースの関係に対して適用できます。
　**is-aの関係**とも言われます。

<img width="159" alt="スクリーンショット 2018-12-04 21.51.49.png" src="https://qiita-image-store.s3.amazonaws.com/0/219573/87488a00-8314-0e22-39ec-e9c351c222d2.png">


　上図はチームを例としたアクター間の関係の例です。リーダを汎化したものがチームメンバであり、チームメンバを特化したものがリーダです。
　チームメンバにリーダとしての役割はないですが、リーダはチームメンバでもあります（リーダ is-a チームメンバ）。

　アクター間の関係で言えば、特殊な役割を持った人を表現する場合に使うといいでしょう。

###includeの関係
　**includeの関連は、ユースケース間の関係を表すのに使用されます**。また、**包含関係とも呼ばれています**。
　以下のように表します。

<img width="640" alt="スクリーンショット 2018-12-11 10.36.53.png" src="https://qiita-image-store.s3.amazonaws.com/0/219573/485e7b7e-572a-b32e-1502-2f20ce7388eb.png">

　ここでは音楽プレイヤーを例にとっています。
　音楽プレイヤーの機能とは、音楽を提供することです。しかし、音楽を提供する上で、曲を選択する機能や、再生する機能、一時停止する機能が必要になってきます。
　上記のユースケース図では、音楽を提供する機能をincludeによって分解して表しています。

　**includeは、大雑把に表した機能を分解して表現する役割を持っています。**

###extendの関係
　**extendの関係は、アクターに提供するユースケースを場合によって使い分けることを表します。**ユースケース間の関係のみに使用できます。
　以下のように示します。

<img width="729" alt="スクリーンショット 2018-12-04 22.10.00.png" src="https://qiita-image-store.s3.amazonaws.com/0/219573/db692eea-51ea-f590-08aa-1ef415874045.png">


　シューティングゲームを例にとります。
　プレイヤーがハードモードを選択した場合、プレイヤーにはゲームのスタートから終了までハードモード仕様の敵、ハードモード仕様のアイテム量でゲームが提供されます。
　反対に、イージーモードを選択した場合、ハードモードを選択した時とは異なり、イージーモード仕様のゲームが提供されます。

　気づいた人は気づいたと思うのですが、**extendの関係を表現する場合は親となるユースケースに「extension point」を設定しなければなりません**。

**「extension point」は、何によってユースケースが使い分けられるのかを表現します**。書き方は例を参考にしてください。

　注意点としては、**extendされたユースケースは同時に提供されることがない**ということです。（ETロボコンのワークショップでも少し言われてたモデルはあった）。
　

#自省を込めた注意点
ユースケース間の汎化とincludeの関連は間違えやすいです（筆者が間違えただけですが）。

　例を考えてみればわかるのですが、ユースケース間の汎化・特化の関係とincludeの関連はどちらも包含関係という考え方でまとめてしまえるからです。
　ですが、この二つは似て非なるものです。

　**ユースケースの汎化・特化の関係では、特化したユースケースが汎化されているユースケースを実現するための手段になっています。**

　図書検索システムを例に挙げるならば、「本を検索する」という機能は、「題名で検索する」、「著者で検索する」、「キーワードで検索する」、といった検索手段を汎化したものです。どれも、本を検索することを表したユースケースです。

 includeがもつ役割は、機能を実現する手段の列挙ではなく、**一つのユースケースを、それぞれ異なる機能を提供するユースケースに分解、具体化することです。**

#実際の描くときの流れは？
　実際に書くときは、まず、どんな機能が必要なのか、関係している人は誰なのかをたくさん書き出してみましょう。[マインドマップ](https://ja.wikipedia.org/wiki/マインドマップ)などを利用して書くのもお勧めです。

　書き出しが終わったら、その中からアクターとユースケース候補を抽出し、システムで実現すべき範囲はどこまでかを踏まえた上で、アクターとユースケースを見直します。

　そうして洗練されたアクターとユースケースの候補をユースケース図としてまとめて、完成です。


#まとめ
　-ユースケース図の機能は、誰にどのような機能を提供するのかを明確にすること
　-ユースケース図は大まかにはアクター、ユースケース、システム境界線から成り立っている。
　-関係を表しかたには、単に関連を表す他に、include、extend、汎化・特化などがある。