BETA

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

投稿日:2020-07-12
最終更新:2020-10-04

TL; DR

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

実践UML記述法とは

UMLが使われない理由の1つに、書き方がわからないという問題が挙げられます。
バージョン2.0以降、わけのわからない機能がどんどん増えて、複雑化してしまったのは事実です。

でも、UMLというのは可読性の向上にすごく役立つものだと考えています。
どのアクターがどのユースケースと関係しているのか、ステークホルダーはどれくらい居るのかなどを、ぱっと見で理解できるのは、図ならではだと思います。

しかし使われない。

そこで、実践的なUMLの書き方講座みたいなことを勝手にしてみようと思います。
ここに書いているのはあくまで1例ですので、参考程度にしておくと吉かもしれません。

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

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

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

PlantUMLはこちら
@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専科

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

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

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

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

解決策

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

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

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

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

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

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

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

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

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

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

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

ユースケース図 疑似ソースコード
ユースケース メソッド
include 関係元ユースケースの内部で実行するユースケース
extend 関係先ユースケースの内部で、拡張点が真の場合に実行するユースケース
拡張点 extend の関係元ユースケースを実行する場合は真を表す真偽値

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

どのように includeextend を使い分けるのか

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

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

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

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

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

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

結論

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

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

技術ブログをはじめよう Qrunch(クランチ)は、プログラマの技術アプトプットに特化したブログサービスです
駆け出しエンジニアからエキスパートまで全ての方々のアウトプットを歓迎しております!
or 外部アカウントで 登録 / ログイン する
クランチについてもっと詳しく

この記事が掲載されているブログ

いろいろ落ちている

よく一緒に読まれる記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう