本記事は、 Qrunch からの移転記事です。

移転元: 実践UML記述法：ユースケース図におけるユースケース間の関係の書き方を疑似コードから逆変換して考える - 雑木林

TL; DR

ユースケース図の include および extends は、それぞれメソッドおよび if 文が真の場合のメソッドに変換できます。
また、拡張点は if 文の真偽値判定に変換できます。

本題：ユースケース図におけるユースケース間の関係の書き方を疑似コードから逆変換して考える

UMLのダイアグラムの1つに、ユースケース図というものがあります。
ユースケース図とは、ステークホルダーとシステムの関係を、簡易的に図として表現するものです。

以下のような図を、人生で1度は見たことがあるはずです。

@startuml
title 冷蔵庫利用者のユースケース図

left to right direction

actor "利用者" as user

rectangle 冷蔵庫 {
  usecase set_item as "食品を入れる
  ---
  extension points
  食品にラッピングが付いている"
  (食品を取る) as get_item
  (ドアを開ける) as open_door
  (ラッピングを外す) as remove_wrapping
  set_item ..> open_door : <<include>>
  get_item ..> open_door : <<include>>
  set_item <.. remove_wrapping : <<extend>>
}

user --> set_item
user --> get_item
@enduml

問題点

ここで、よく混乱するのが include および extend の意味、および、矢印の向きです。

include は、あるユースケースは別のユースケースを包含している、という意味を表します。

ユースケースBの中には、ユースケースAが含まれていることを示します。
「has a」関係、つまり、「ユースケースB has a ユースケースA」の関係が成り立ちます。

extend は、あるユースケースが別のユールケースを拡張する、という意味を表します。

ユースケースAに対して、機能を追加するようなユースケースBの関係を示します。

ユースケース図(Use Case Diagram) - UML入門 - IT専科

この包含と拡張、という単語の違いは、個人的には非常に理解が難しかったです。
それにより、以下の疑問が顕在化します。

• どのように include と extend を使い分けるのか
• なぜ extend の矢印の向きは include と逆なのか

しかし、下記ページにより、長年の疑問が解けたので、解説しようと思います。

ユースケース図のincludeとextend:アーキテクト360

解決策

エンジニアは、図で理解するより、ソースコードで理解する方が簡単ですよね。
ということで、上記ユースケース図の例を、疑似コードに置換えてみます。

冷蔵庫利用者のユースケース疑似コード

# TODO: 例として挙げたユースケース図からは、ユースケースの実行順序までは読取れない

def ドアを開ける:
    # ドアを開ける際の処理記述

def ラッピングを外す:
    # ラッピングを外す際の処理記述

def 食品を入れる:
    if 食品にラッピングが付いている:
        ラッピングを外す()
    ドアを開ける()
    # 食品を入れる際の処理記述

def 食品を取る:
    ドアを開ける()
    # 食品を取る際の処理記述

各ユースケースは、各メソッドと対応します。

include の関係先ユースケース（例における「ドアを開ける」ユースケース）は、関係元ユースケース（例における「食品を入れる」ユースケースおよび「食品を取る」ユースケース）の共通部品として、関数内で呼出すメソッドとして対応します。

extend の関係元ユースケース（例における「ラッピングを外す」ユースケース）は、関係先ユースケース（例における「食品を入れる」ユースケース）を一部拡張するため、拡張点「食品にラッピングが付いている」場合にのみ呼出すメソッドとして対応します。

ここで注意ですが、例として挙げたユースケース図からは、ユースケースの実行順序までは読取れないことに気をつけてください。
例えば、「食品を入れる」ユースケースで実行する、「ドアを開ける」ユースケース／「ラッピングを外す」ユースケース／「食品を入れる」ユースケースの3つ（3番目は、ユースケース自身のユースケースを指す）は、本来は前後関係がありますが、ユースケース図からは読取れません。
「ドアを開ける」前に「食品を入れる」ことはできませんし、「ラッピングを外す」前に「食品を入れる」ことは、本来はできないので、疑似コードでは順序を指定してます（ドアを開けた後にラッピングを外すことはできますが、電気代が掛かるので、先にラッピングを外しています）。

表でまとめると、下記の通りです。

こう見ると、最初の疑問点がはっきりすると思います。

どのように include と extend を使い分けるのか

include の関係先ユースケースは、複数のユースケースから呼出されることを想定し、共通部品化すると良いです。

extend の関係元ユースケースは、まず関係先ユースケースを共通部品化し、ある分岐点（拡張点）でのみ実行するユースケースとして外出しすると良いです。

なぜ extend の矢印の向きは include と逆なのか

ここは、私の個人的な見解を述べます。

extend が include と逆向きなのは、 extend の関係元ユースケースが拡張点を求めていることが理由と考えます。
すなわち、 extend の関係元ユースケースは、関係先ユースケースにおける拡張点に「依存」していると言えるのではないか、と考えます。

疑似コードを見ればわかりますが、 extend の関係先ユースケースに拡張点が存在しないユースケース図は、どのような場合に関係元ユースケースが実行されるのか、判断できかねます。
つまり、 extend の関係元ユースケースと、関係先ユースケースの拡張点は、セットであると考えるのが自然です。
さらに言えば、 extend の関係元ユースケースは、関係先ユースケースの拡張点なしには関係を結ぶことは難しく、拡張点に依存して存在を維持している関係である、と言うこともできます。

結論

ユースケース図の関係は、疑似コードから逆変換して考えてみると、理解しやすい気がします。
UMLは高度に抽象的であるため、具象的な疑似コードに置換えることで、把握しやすいのかもしれません。

これを元に、ユースケース図がもっと流行ることを期待します。