ユースケース図の例：アクター、ユースケース、include と extend

ユースケース図は、1 ページで 1 つの問いに答えます。誰がこのシステムを使い、何のために使うのか、です。プロダクトマネージャーはスコープの合意に、エンジニアはシステムへの入口をすべて把握するために、テスターはすべての目的に経路があることを確かめるために使います。同時に、最もよく誤って描かれる UML 図の 1 つでもあります。フローチャートにしてしまう、ボタンを 1 つずつユースケースとして描く、include と extend を逆に使う、といった具合です。

この記事では、UML 2.5.1 仕様が定める記法を説明し、include と extend の違いを簡単なテストで整理します。さらに料理注文アプリの例を最後まで描き、各楕円の背後に置くべきテキストを示し、ユースケース図を役に立たなくする誤りを挙げます。

記法

矢印の向きは、OMG が 2017 年 12 月に公開した UML 2.5.1 仕様にそのまま従っています。include は基底ユースケースから包含されるユースケースへ向かい、extend は拡張するユースケースから拡張されるユースケースへ向かいます。仕様では拡張点も使えます。基底ユースケースの中で拡張が差し込まれる名前付きの場所で、楕円の中に列挙します。

include と extend：1 つのテスト

基底ユースケースが、もう一方なしで完結するかを問いかけてください。

• それなしでは完結しない：include。 注文には必ず支払いが伴います。「Place order」は「Pay for order」を包含します。矢印は包含されるものを指し、基底はそれなしでは実行できません。
• それなしでも完結する：extend。 プロモコードの適用は任意で、コードなしの注文も完全に有効です。「Apply promo code」は、顧客がコードを持っているとき、「支払いの前」のような拡張点で「Place order」を拡張します。矢印は基底を指し、基底は拡張の存在すら知りません。

さらに 2 つのルールで、誤用の大半を防げます。

• include は、認証や支払いのように複数のユースケースが必要とする振る舞いを共有するために使います。1 つのユースケースをステップに分割するために使ってはいけません。それはフローチャートです。
• extend は控えめに使います。基底ユースケースより extend のほうが多いなら、目的ではなく UI のオプションを記述しています。

アクターは役割

アクターは役割であり、人や職名ではありません。同じ人が朝は顧客、午後はレストランのマネージャーということもあります。アクターはシステムでも構いません。アプリがカードの承認のために呼び出す決済代行サービスは、支援アクターです。定期実行のジョブを「Time」アクターでモデル化するチームもあります。誰も手動で開始しないユースケースによく使われる慣習です。

慣習として、目的を達成するためにユースケースを開始する主アクターは左に、システムが頼る支援アクターは右に置きます。

ユースケースを適切なレベルで名付ける

ユースケースは、アクターの視点から動詞と目的語で名付けます。「注文」「注文画面」「送信ボタン」ではなく「注文する」です。それぞれが、アクターが一度に完了でき、達成できてうれしいと思える目的であるべきです。Alistair Cockburn はこれをユーザー目的の海面レベルと呼んでいます。それより上のレベル（「レストランを経営する」）は 1 つの楕円には広すぎ、下のレベル（「カード番号を入力する」）はユースケースの中のステップです。

例：料理の注文

下の図は、4 つのアクターを持つ料理注文アプリを示しています。

• Customer はメニューを閲覧し、注文し、配達を追跡します。
• Restaurant staff は注文を受け付けます。
• Courier は注文を配達します。
• Payment provider は外部システムで、支払いを支援します。

境界の内側には 7 つのユースケースがあります。

1. Browse menu
2. Place order（Pay for order を包含）
3. Pay for order（決済代行サービスが支援）
4. Apply promo code（支払いの前に Place order を拡張）
5. Track delivery
6. Accept order
7. Deliver order

図に描かれていないものにも注目してください。ステップの順序も、画面も、アクターごとの「Log in」の楕円もありません。認証は目的ではなく事前条件です。記述の中に書くか、実際の振る舞いを伴う場合に限り、包含されるユースケースを 1 つ用意します。

各楕円の背後にある記述

図は索引です。価値は、ユースケースごとの短い記述にあります。たとえば次のようなものです。

Use case: Place order
Primary actor: Customer
Precondition: The customer is signed in and the basket is not empty.

Main success scenario:
  1. Customer reviews the basket and delivery address.
  2. System shows the total, including fees and estimated delivery time.
  3. Customer confirms the order.
  4. System takes payment (includes: Pay for order).
  5. System sends the order to the restaurant and confirms it to the customer.

Extensions:
  2a. Customer has a promo code: Apply promo code, then continue at step 2.
  4a. Payment is declined: System asks for another payment method.
  5a. Restaurant does not accept within 5 minutes: System cancels and refunds.

Postcondition: The order is paid and visible to the restaurant.

記述の中の拡張、つまり番号付きの「もし〜なら」の分岐こそが、要件とテストケースの源です。図の extend 関係よりはるかに詳細で、図には絵にする価値のある任意の目的だけを描くべきです。

よくある誤り

• フローチャートの変装。 ユースケース間に「次に」を意味する矢印を引くと、図はプロセスモデルになります。作業の順序には BPMN 図かアクティビティ図を使ってください。
• CRUD 操作ごとに 1 つのユースケース。 「メニュー項目を作成する」「メニュー項目を更新する」「メニュー項目を削除する」は、たいてい 1 つの目的「メニューを管理する」です。
• 画面やボタンをユースケースにする。 「購入ボタンを押す」はステップであり、目的ではありません。
• 分解のための include。 すべてのユースケースがほかの 3 つを包含しているなら、その図はユーザーの目的ではなくコードの構造を表しています。
• 内部コンポーネントをアクターにする。 データベースはアクターではなく、システムの内側にあります。呼び出す外部システムはアクターです。
• 境界がない。 サブジェクトの長方形がないと、読み手は何を作っていて何に依存しているのかを区別できません。

ユースケース図、ユーザーストーリー、シーケンス図

これらは組み合わせて使います。ユースケース図が領域の地図を描き、ストーリーがそれを届けられる単位に切り分け、シーケンス図が 1 つのシナリオが実際にどう動くかを示します。

ユースケース図

図の読み方は次のとおりです。

• 長方形はシステム境界です：内側にあるものはすべて料理注文アプリです。
• 左のアクターはユースケースを開始します：顧客には 3 つ、レストランスタッフと配達員には 1 つずつ目的があります。
• 右の決済代行サービスは、アプリが支払いの間に呼び出す支援システムです。
• Place order から Pay for order への «include» 矢印は、支払いが必ず行われることを意味します。Apply promo code から Place order への «extend» 矢印は、プロモコードが任意であることを意味します。
• Markdown ブロックは、UML に慣れていない読み手のための記法の凡例です。

本当に読まれるユースケース図を描くには

• 1 枚の図のユースケースはおよそ 15 個までにします。 それより多いシステムは、アクターかサブシステムごとに分けます。
• 主アクターを左、支援アクターを右に置き、読む方向と、誰が何を開始するかを一致させます。
• include と extend は山括弧付きで明示的にラベル付けし、矢印は破線のままにします。
• 詳細は記述に任せます。 図はスライド 1 枚に収め、テキストは必要なだけ長くて構いません。

ユースケース図はほかの UML のビューと相性がよく、ドメインモデルには UML クラス図の例、注文のライフサイクルには状態遷移図の例が役立ちます。

Archboard で作る

1. Google または GitHub でサインインし、図を作成します。
2. システム境界として、Food ordering app という名前の基本パックの フレーム を追加します。
3. フレームの中に、UML パックの ユースケース ノードを 7 つ追加し、上記のとおりに名前を付けます。
4. UML パックの アクター ノードを 4 つ追加します。左に Customer、Restaurant staff、Courier、右に Payment provider です。
5. アクターとユースケースを単純な線で結びます。Place order から Pay for order へ «include»、Apply promo code から Place order へ «extend» とラベルを付けた破線のエッジを追加します。
6. 短い記法の凡例を書いた基本パックの Markdown ブロックを追加します。

この例で使うダイアグラムノードは 13 個で、Free プランの範囲に収まります。

よくある質問

ユースケース図の include と extend の違いは何ですか？ include は、基底ユースケースが包含された振る舞いを常に実行することを意味し、矢印は包含されるユースケースを指します。extend は条件付きで加わる任意の振る舞いを意味し、矢印は拡張から基底ユースケースへ向かいます。

アクターはシステムでもよいですか？ はい。システムとやり取りする外部の役割は、決済代行サービスのような別のソフトウェアも含め、すべてアクターになり得ます。自分のシステムの内部コンポーネントはアクターではありません。

アクターとユースケースは矢印で結ぶべきですか？ UML では、アクターとユースケースの間に単純な関連の線を使います。誰が開始するかを示すために矢じりを付けるチームもありますが、標準の記法では必須ではありません。

1 枚の図にはいくつのユースケースを描くべきですか？ 目安として、およそ 15 個までです。それより大きなシステムは、アクターやサブシステムごとに複数の図に分けたほうが読みやすくなります。

ユースケース図はステップの順序を示しますか？ いいえ。示すのは目的であり、順序ではありません。ステップの順序は、ユースケース記述、アクティビティ図、シーケンス図で表します。

無料で始める — 1 シート、クレジットカード不要。