## ユースケース図
ユースケース図とは要件定義等前の要求定義の要求分析で使われる。次のような図のことをいいます。
ユースケース図とはユーザ視点でシステムの機能を把握するのに役立つダイアグラムです。
何かシステムを作る上で便利になりそうなダイアグラムですね。
UML(統一モデリング言語）の一つです。
##アクター
アクターは、システムの利用者を指したりします。UML2.x系では、外部システムやハードウェアなどもアクターとして使用できるように表現できるようになったようです。
##ユースケース
ユースケースは、アクターから見たシステムの機能を示します。
例としてATMのシステムの場合、ユーザはお金を預ける、お金を引き出す等のユースケースが書けると思います。
ユースケースはそのままテストにも使えそうなので便利ですね。
ちなみにユースケースがまとめられている一覧をユースケース一覧といいます。
##システム境界
ユーザと、システムとの境界を表します。この場合、ユーザが使うのはATMを想定しているので、システム境界にATMと記述します。
##関連
関連は、アクターとユースケースとの関連を示します。
アクターとユースケースを関連で紐づけたとき、アクターからの反応や、ユーザからユースケースを実行することを示すことができます。
##汎化
汎化は、アクター同士や、ユースケース同志の共通部分を抽象化することです。
これによって管理者やメンバーによって実行できるユースケースを分けたりできます。
この場合、メンバーには社員情報を閲覧、管理者はメンバーを汎化しているので社員情報を閲覧できますし、編集、削除ができます。しかしメンバーは社員情報の編集と削除はできません。
##包含
包含はユースケースが別のユースケースを内部に含むことです。
手順として、〇〇をするならば、必ず□□する。といった場合。
◯◯は、□□に包含（インクルード）するといいます。
わかりやすく言えば、◯◯は、□□に含まれるということです。
たとえば、ATMで振り込みや引き出しを行う場合、必ず金額の指定をする必要があります。
つまり、ATMの振り込みや引き出しは、金額の指定に包含するということですね。
##拡張
拡張は、既に存在するユースケースに、別のユースケースによって拡張することを言います。
包含との違いが結構難しいですが。元々あるユースケースに、機能を追加する場合などに使います。
しかし、ユーザはその機能を必ず使う必要はありません、あくまでオプションとしてのユースケースです。
##終わりに
今回はユースケース図について書きました。
実際に仕事のフローなどをユースケース図に書くと膨大な量になりそうですね。粒度などが問題になりそうです。
意識することは、ユースケースはアクターから見たシステムの機能です。アクターから意識して行わない機能のユースケースは書くべきではありません。
ユースケースの機能について詳細に書かれたものをユースケース記述と言います。
次回はユースケース記述について書こうと思います。
では。