ユースケース図のextendとは？使い方と例も！（拡張関係：オプション処理：条件分岐：UML：includeとの違いなど）

ユースケース図のextendとは？使い方と例も！（拡張関係：オプション処理：条件分岐：UML：includeとの違いなど）

UMLのユースケース図を学ぶ中で、「extendって何？」「includeとどう違うの？」と疑問に思った方は多いのではないでしょうか。

ユースケース図におけるextend（拡張関係）は、オプション処理や条件分岐を表現するための重要な概念です。

システム設計の現場では、基本的なユースケースに対して「特定の条件が満たされたときだけ実行される処理」を分離して記述する場面が多々あります。

そのような場面でextendを正しく使えるかどうかが、読みやすく精度の高いユースケース図を作れるかどうかの分かれ目になるでしょう。

この記事では、extendの意味や使い方、具体的な例、そしてincludeとの違いまでをわかりやすく解説していきます。

ユースケース図のextendとは「条件付きで発動するオプション処理」のこと

それではまず、ユースケース図におけるextend（拡張関係）の基本的な意味から解説していきます。

extendとは、UMLのユースケース図において「ある条件が満たされたときにのみ、基本ユースケースの動作を拡張するオプション処理」を表す関係性です。

記法としては、矢印の向きが「拡張するユースケース → 基本ユースケース」という方向になり、矢印のラベルには「<<extend>>」と記述します。

つまり、基本となるユースケースが存在し、特定の条件下でのみ追加の処理が割り込んでくるイメージです。

例えば「商品を購入する」という基本ユースケースに対して、「クーポンを適用する」という拡張ユースケースをextendで結びつけた場合を考えてみましょう。

クーポンを持っていないユーザーが購入する場合は「クーポンを適用する」は実行されず、クーポン保有者のみにその処理が発動します。

このように、「常に実行されるわけではない」「条件次第で動作が変わる」処理を表現するのがextendの役割です。

拡張ポイント（Extension Point）とは

extendをより正確に使うために知っておきたいのが、「拡張ポイント（Extension Point）」という概念です。

拡張ポイントとは、基本ユースケースの中で「ここで拡張処理が割り込む可能性がある」という位置を明示したものになります。

UMLの仕様では、extendを使う際には基本ユースケースに拡張ポイントを定義することが推奨されています。

ただし実務レベルでは省略されるケースも多く、<<extend>>矢印と条件（condition）の記述だけで表現する場合も少なくないでしょう。

extendにおける条件（condition）の書き方

extendでは、拡張が発動する条件を「condition」として記述することができます。

例えば「クーポンコードを所持している場合」「エラーが発生した場合」など、具体的なトリガーを明示することで、ユースケース図の可読性が大きく向上します。

conditionはUML図中では波括弧「{ }」を使って表記するのが一般的なスタイルです。

条件を明記することで、読み手がオプション処理の発動タイミングを直感的に理解できるようになります。

extendが適しているシチュエーション

extendが特に有効なのは、「基本フローに影響を与えずにオプション処理を追加したい場合」です。

具体的には、エラー処理・警告表示・追加確認ダイアログ・ログ記録などの処理がextendの典型的な候補になります。

これらは「必ず実行するわけではないが、特定の条件下では必要になる」という性質を持っているため、extendとの相性が非常に高いでしょう。

extendの使い方と具体的な例

続いては、extendの実際の使い方と具体的な例を確認していきます。

ユースケース図を実際に描く際、extendをどのように配置・記述すればよいのかを具体例を交えながら見ていきましょう。

基本的な記述の手順

extendを用いたユースケース図を作成する基本的な流れは以下のようになります。

この手順を守ることで、誰が見ても直感的に理解できるユースケース図が完成します。

特に手順4と5は省略されがちですが、しっかり記述することで図の意図が格段に伝わりやすくなるでしょう。

ECサイトを例にした具体的なユースケース

ECサイトの購入フローを例に、extendの活用イメージをつかんでみましょう。

基本ユースケース	拡張ユースケース（extend）	発動条件
商品を購入する	クーポンを適用する	クーポンコードを入力した場合
商品を購入する	在庫不足メッセージを表示する	在庫が0件だった場合
ログインする	二段階認証を実施する	二段階認証が設定されている場合
検索する	検索履歴を保存する	ログイン済みユーザーの場合

この表からわかるように、extendは「基本処理に対するオプションや例外的な動作」を表現するのに最適な関係性です。

どの例も「必ず起きるわけではなく、条件次第で発動する」という共通の性質を持っています。

システム開発現場での活用シーン

実際のシステム開発現場では、要件定義の段階でextendを活用することで、基本フローと例外フローを明確に分離して管理できます。

例えばATMシステムであれば、「現金を引き出す」という基本ユースケースに対して、「残高不足メッセージを表示する」「一日の引き出し上限超過を通知する」などをextendで記述することが考えられます。

このように例外処理やオプション機能を別ユースケースとして分離することで、基本ユースケースのシンプルさを維持しながら、複雑な仕様を整理することができます。

extendとincludeの違いを徹底比較

続いては、extendと混同されやすい「include（包含関係）」との違いを確認していきます。

この2つの関係はUMLのユースケース図において頻繁に登場しますが、使い方を誤るとシステムの設計意図が正確に伝わらなくなってしまうため、しっかり区別しておくことが重要です。

includeとは何か

include（包含関係）は、「基本ユースケースが常に呼び出す共通処理」を表します。

矢印の向きはextendとは逆で、「基本ユースケース → 共通ユースケース」という方向になり、ラベルには「<<include>>」と記述します。

例えば「商品を購入する」「注文履歴を確認する」「プロフィールを変更する」といった複数のユースケースがすべて「ログインする」という処理を必要とするケースが挙げられるでしょう。

この場合、「ログインする」を共通ユースケースとしてincludeで結びつけることで、重複した記述をなくすことができます。

extendとincludeの比較表

比較項目	extend（拡張関係）	include（包含関係）
矢印の向き	拡張ユースケース → 基本ユースケース	基本ユースケース → 共通ユースケース
実行タイミング	条件が満たされた場合のみ	常に実行される
主な用途	オプション処理・例外処理・条件分岐	共通処理の再利用・重複排除
基本UC側の認識	拡張の存在を知らなくてよい	共通処理の存在を知っている
典型例	クーポン適用、エラー表示	認証処理、ログ記録

よくある混同パターンと注意点

extendとincludeが混同されやすいのは、どちらも「あるユースケースが別のユースケースと関係する」という点が共通しているからです。

典型的な混同パターンとして、「条件によって実行されるのにincludeを使ってしまう」ケースが挙げられます。

判断の基準としては、「その処理は必ず実行されるか？」という問いを立てることが効果的です。

必ず実行されるならinclude、条件によって実行されるならextendを選ぶというシンプルなルールで、多くのケースに対応できます。

extendを使う際の注意点とよくある誤り

続いては、extendを使う際に気をつけたいポイントや、よくある誤りを確認していきます。

正しい概念を理解していても、実際に図を描くとミスが生じやすいポイントがあります。

矢印の向きを間違えない

extendで最も多いミスの一つが、矢印の向きの誤りです。

extendの矢印は「拡張ユースケース → 基本ユースケース」という方向が正しく、includeの矢印とは逆方向になります。

直感的には「基本UCが拡張UCを呼び出す」イメージを持ちやすいため、矢印を逆に描いてしまうことが多いでしょう。

「拡張する側から矢印が出る」と意識することで、向きのミスを防ぐことができます。

extendを多用しすぎない

extendは便利な表現ですが、使いすぎると図が複雑になり、かえって読みにくくなってしまいます。

特に「すべての例外処理をextendで表現しようとする」のは避けたいパターンです。

優先すべきはユースケース図全体の見やすさであり、細かいすべての条件分岐をUML図に落とし込む必要はないでしょう。

詳細な処理の分岐はアクティビティ図やシーケンス図で表現し、ユースケース図はシステムの概要を示すことに専念するのが望ましい姿勢です。

汎化（generalization）との混同に注意

ユースケース図にはextendとinclude以外にも「汎化（generalization）」という関係性が存在します。

汎化は「あるユースケースが別のユースケースの特殊バージョンである」ことを示すもので、継承の概念に近い関係です。

例えば「支払いをする」という基本UCに対して「クレジットカードで支払う」「電子マネーで支払う」が汎化として結びつくイメージになります。

オプション処理にはextend、共通処理にはinclude、特殊化にはgeneralizationというように、3つの関係性をそれぞれの用途に応じて使い分けることが大切です。

まとめ

この記事では、ユースケース図におけるextend（拡張関係）の意味・使い方・具体例、そしてincludeとの違いについて詳しく解説しました。

extendは「特定の条件が満たされたときだけ発動するオプション処理」を表す関係性であり、基本ユースケースをシンプルに保ちながら複雑な条件分岐を整理するのに非常に役立ちます。

includeが「常に実行される共通処理」を表すのに対し、extendは「条件付きで発動するオプション処理」を表すという違いを軸に理解しておくと、実際の図作成でもスムーズに使い分けができるでしょう。

矢印の向きや拡張ポイント・conditionの記述など、細かいルールも意識しながら、正確で読みやすいユースケース図の作成に役立ててみてください。

UMLの表現力を最大限に活かすために、extendを正しく理解して活用することが、質の高いシステム設計への近道です。