UML (ユースケース図) アドベントカレンダー (7日目)

こんにちは。 安里悠矢@長田研(仮)B4です。
内容は、前回の続きということで、ユースケース図について書きたいと思います。

———————————————————-

もしあなたがシステムを何も無い状態から作っていく場合、何から始めますか?
誰がシステムを使うのか、どの機能が必要かなどを検討するなど、要求分析をする必要がありますよね。
ユースケース図では、今から作成するシステムで実現すべきことを明確にするために用いられます。

ユースケース図

ユースケースとは、今から作成するシステムで実現すべきことです。ユースケースの表記方法は複数ありますが、一番左の楕円の中にユースケース名を配置する方法が一般的でしょう。

上の図は、システムがアクターに対して「データを登録する」という機能/振る舞いを提供することを意味します。

アクター

アクターは、作るシステムの利用者のことです。棒人間みたいな図で記述されます。
利用者といっても、人だけじゃなくて、ハードウェアだったり外部システムといった人間以外の要素も含まれます。

ユースケースの包含 (include)
「包含(ほうがん)」は、複数のユースケースから共通利用されるユースケースとの間に存在する関係です。

例えば、データを登録や削除には、一度認証処理を行わないと行けないようなシステムがあるとします。
このシステムの場合、「本人認証を行う」ユースケースはどちらでも利用されるので、<<include>>を用いて記述します

ユースケースの拡張(extend)

条件付きで他のユースケースを利用する場合、<<extend>>を用いて表現します。

例えば、データを検索してる際に、ユーザがファイルへの出力を行う場合、<<extend>>を用いて、条件付きで記述します。

ユースケースの汎化

「ユースケースの汎化」は、一方が他方の機能を継承する関係を表現したものです。
例えば、「ユーザを検索する」というユースケースに、「IDで検索する」だったり、「キーワードで検索する」という方法があるとします。どちらも「ユーザを検索する」という共通の機能を持っています。
汎化は、個別機能を持つユースケース側から共通機能を持つユースケース側へ、白抜きの三角形がついた矢印を用いて表現します。

アクターの汎化
「アクターの汎化」もユースケースと同様に、一方が他方の機能を継承する関係を表したものです。
例えば、「社員」というアクターに、「使える社員」や「使えない社員」というアクターがあったとします。
どちらも「社員」なので、汎化関係にあると言えます。
基本的なことについてはこんなものかな….

ユースケース図を描くときのポイント

①分析中毒にならないようにする
最初から完全に分析できるものではないです。気楽にやりましょう。
②ユースケース名は動詞で表現する
内容の曖昧さを無くすために、「〜する」とか動詞を入れましょう。
③作成/読み込み/更新/削除のユースケースは、「管理する」でまとめる
ユースケースが増えすぎて、図が読みづらくなります。なので「管理する」でまとめちゃいましょう。
④詳細すぎないようにする
ユースケースは、あまり詳細に書く必要はないです、汎化のように抽象的に描いたほうがいいです。
今日はこんなところで終わります。
次回担当の際は、クラス図とかについて書こうかな。