利用者とシステムの機能の関係を表すUMLの図。
ユースケース図とは、利用者とシステムの機能の関係を表すUMLの図のことです。「誰が、システムを使って何ができるか」を、外から見た視点でシンプルに表します。
身近な例で考えると、レストランのメニュー表に似ています。お客さん(利用者)が注文できる料理(機能)の一覧があり、誰がどれを頼めるかが分かる。中の調理手順までは書かず、「使える機能の一覧」を示すのがユースケース図です。
上のツールで▶ボタンを押すと、オンライン書店を題材に、アクターを置き、システム境界を描き、機能を楕円で並べ、線でつないでいく流れを確認できます。
アクターとは、システムを利用する人や、連携する外部システムのことです。棒人間の絵で描き、システム境界の外側に置きます。「システムを使う側」の存在だと考えてください。
アクターについて押さえるべき点は次のとおりです。
・役割を表す:個人名ではなく「購入者」「管理者」のように役割で書く
・人とは限らない:データを送ってくる他システムや機器もアクターになる
・境界の外に立つ:アクターはシステムの外側、機能はシステムの内側
同じ人でも、状況によって異なるアクターになります。例えば一人の社員が、ふだんは「購入者」として買い物をし、業務では「管理者」として在庫を操作する、という具合です。誰が・どんな役割でシステムを使うかを洗い出すことが、ユースケース図の出発点になります。
ユースケース図は、システムが提供する機能の全体像を、開発者と発注者が共有するために使います。とくに開発の初期、何を作るかを決める要件定義の場面で活躍します。
具体的な使い道は次のとおりです。
・機能の洗い出し:「誰がどんな操作を必要とするか」を漏れなく挙げる
・範囲の合意:システム境界で「ここまで作る」を発注者と確認する
・会話の土台:専門知識がなくても読める図なので、関係者の認識合わせに使える
ユースケース図は、あくまで「外から見た機能の一覧」を表す図です。各機能の中身の手順は、シーケンス図やアクティビティ図で別に描きます。まずユースケース図で「何を作るか」を決め、次に他の図で「どう動かすか」を設計する、という流れで使われます。
«include»(包含)とは、あるユースケースが必ず別のユースケースを呼び出すことを表す関係です。「本を購入する」にも「在庫を確認する」にも、必ず「ログインする」が伴うとき、共通処理を1つにまとめて矢印でつなぎます。
なぜ «include» を使うのか。「ログインする」を毎回それぞれの楕円の中に書いてしまうと、同じ機能が図に2回・3回と出てきて冗長になります。共通処理を1つの楕円に切り出して «include» でつなぐことで、重複をなくし「必ずこの処理が入る」という設計の意図を一目で伝えられます。
上のツールのSTEP6では、「購入する」が「ログインする」を «include» している様子を確認できます。矢印は呼び出す側(購入する)から呼び出される側(ログインする)へ向かって引きます。矢印の向きと点線が «include» の目印です。
ユースケース図のシステム境界(=大きな四角い枠)は、「このシステムが担当する範囲」と「外の世界(利用者・他システム)」を区別する線です。機能(ユースケース)は枠の内側、アクターは枠の外側に置きます。
なぜ境界を引くのか。システム開発では「どこまでを今回作るか」を発注者・開発者の間ではっきり決めることがとても重要です。境界線があることで、「この機能は作る・あの機能は別のシステムがやる」という範囲を一目で示せます。
境界の外にいるアクターは、システムを使う存在であってシステムの一部ではありません。たとえば利用者のパソコンや、連携する決済サービス(外部システム)は、境界の外側にアクターとして置きます。上のツールのSTEP3でオレンジの枠として確認できます。