はじめに

連載第5回のテーマは「ユースケース図」です。ユースケース図を描く際に誤って使われることが多い表記や、{あまり嬉しくない|誤った}ユースケース図の描き方/使い方などをいくつか紹介していきたいと思います。ただし、ユースケース図を描く際にもっとも典型的な失敗である「ユースケース図上で細かく機能分割してしまう」や「《include》と《extend》の使用方法を間違ってしまう」といった例については既に他の記事やホームページなどで多く解説されているので、是非それらの記事をご覧ください。本記事では、その他の少し気付きにくい誤用/誤解の例を紹介します。

その1：アクター⇔ユースケース間の関連線の矢尻

最近はそれほど見かけなくなってきましたが、少し古い本やホームページで紹介されているユースケース図の例の中には 図1 のようにアクター⇔ユースケース間に引かれる関連線の片側に矢尻が付けられて描かれているものがあります。この矢尻(Navigability：誘導可能性)を表示すること自体はUMLの文法上誤りではないのですが、問題なのはアクター⇔ユースケース間の関連線に矢尻が付けられた場合の解釈の仕方がUML仕様書で明記されていないため、描いた人の意図が上手く伝わらなかったり変な誤解をされてしまったりすることが多い...という点です。

図1：アクター⇔ユースケース間の関連に付けられた矢尻の例 (誤解されやすい図)

たとえば、図1 に示した図書館システムのユースケース図の場合、「矢尻の付いていない方のアクターが各ユースケースを起動する主アクターになるという事を示している」という解釈をする人もいれば「矢尻が付いている方向にデータ/指示の流れがある」という解釈をする人もいるでしょう。

このような矢尻の表記が一部で使われているのは、特定の開発プロセスでローカル・ルールとして使われていたものが広がったものなのかもしれません。しかし、この表記の解釈はあくまでローカル・ルールなので、もしアクター⇔ユースケース間の関連線に矢尻を付けて表記したいのであれば、これを見る人が変な誤解をしてしまわないように「その矢尻の意味をどのように解釈するのか」という注記を目立つように付けておくといった工夫をしておいた方が安全でしょう。ユースケース図を描く際のちょっとした「思い付き」や「なんとなく」でつい矢尻を付けてしまったりすると、かえって{不要な誤解を招きやすく|混乱しやすく}なってしまいます。ローカルな表記ルールや解釈が曖昧になるケースを{把握|認識}して、必要であればメモなどで伝えたい事の意図を{補強|明確化}するといった事前の対処を行うのが良いでしょう。

その2：アクター⇔ユースケース間の関連線の多重度

アクター⇔ユースケース間に引かれる関連線の両端に多重度を明記する場合、その多重度がイイカゲンに付けられていて混乱してしまう...ということもあります。あまり考えられずに多重度が付けられてしまっている極端な例を 図2 に示します。

図2：多重度がイイカゲンに付けられているユースケース図の例

あるアクターから見た時のユースケース側の多重度が意味するのは「あるひとりのアクターが居た時、そのひとりのアクターに対して同時に存在する(≒同時に実行される)可能性のあるユースケース・インスタンスの個数の範囲」です。逆に、あるユースケースから見た時のアクター側の多重度が意味するのは「あるひとつのユースケース・インスタンス(ある特定のサービスの相互作用)があったとき、そのひとつのユースケース・インスタンスに同時に参加してくる可能性のあるアクターの個数の範囲」です。これらの多重度の解釈の仕方は、基本的にクラス図でクラス間に引かれる関連線の多重度の解釈と同じですね。

図2のユースケース図の多重度を素直に読み取ろうとすると、たとえば、『あるひとりの「図書館窓口係」が同時に「図書を貸し出す」というサービス(ユースケース・インスタンス)を3つと「図書を返却する」というサービスを2つ実行するというようなことがありうる』、『「蔵書の保管場所を探す」というサービスに4人の「図書館窓口係」と5人の「図書館利用者」が同時に参加してくるというようなことがありうる』といった感じになります。このユースケース図を描いた人がまさにそのような対応関係を意図していたのであれば良いのですが、図書館システムの例で考えると「かなり怪しい」感じがします。

図3：多重度を見直してみたユースケース図の例

図3 に多重度を見直してみたユースケース図の例を示します。この例では、『「図書館窓口係」や「図書館利用者」のアクターは、同じタイプのユースケースのインスタンスを複数同時に実行することはない(アクターから見たユースケース側の多重度がそれぞれ「0..1」になっているため)』、『「図書を貸し出す」と「図書を返却する」というユースケース・インスタンスが存在するなら、それに対応する「図書館窓口係」のインスタンスが必ず1人いる(アクター側の多重度が「1」になっているため)』、『「蔵書の保管場所を探す」というユースケース・インスタンスが存在するなら、それに対応する「図書館窓口係」か「図書館利用者」のいずれか1人が存在する(アクター側の多重度「0..1」とユースケースに付加された制約によって表現)』などといったように読み取ることができます。

さらに厳密に考えていくと、この例の記述ではまだ『ある「図書館窓口係」が「図書を貸し出す」と「図書を返却する」というふたつのサービスを同時に実行する』という場合があり得ます。もし、『ひとりの「図書館窓口係」は「図書を貸し出す」「図書を返却する」「蔵書の保管場所を探す」等のサービスを同時に複数実行することはできない』という仕様にしたいのであれば、このユースケース図に対してさらに制約を加えるか、あるいは、各ユースケース毎に作成されるユースケース記述中の事前条件に明記するといった表現方法が考えられます。

図4：多重度が1以上になる場合の例

図4 には、アクター⇔ユースケース間の関連線の多重度に1以上の値が付く場合の典型的な例として、あるチャット・システムのユースケース図の一部が示されています。この例では、「会話を交わす」というユースケース・インスタンスに対して同時に複数の「参加者」が対応付いています(会話に参加します)。また、あるひとりの「参加者」は、このチャット・システムを使って同時に複数のグループに対して会話を行うことができます。

その3：同じような結果をもたらすが相互作用の異なるユースケース

図5：ちょっと怪しいユースケース図

図5 のユースケース図を見てみてください。これは、飛行機や新幹線の指定席などの座席予約を受け付けて管理するシステムのユースケース図の一部を抜き出したモノとします。どこか怪しいところがあるでしょうか？

各ユースケースの中身(=ユースケース記述)を吟味してみないとなんとも言えません(正しいとも誤っているとも言えません)が、このユースケース図で特に注意しておきたい(確認しておきたい)のは「予約を取り消す」というユースケースの取り扱いだろうと思います。

このユースケース図によると、「予約を取り消す」というユースケースは「会員」から起動されることもあるし、「システム管理者」から起動されることもある様子です(「予約を取り消す」というユースケースの実行に「会員」と「システム管理者」が同時に参加するという可能性もあります)。「会員」が起動する「予約を取り消す」というサービスは、おそらくユースケース「座席を予約する」などを使って登録した自分の予約のいずれかを取り消すような操作なのだろうと推測できます。一方、ユースケース「予約を取り消す」が「システム管理者」から起動される場合、これはシステムに登録されている任意の会員の予約のいくつかを強制的に取り消すような操作になるのでしょうか。「会員」から起動される時と「システム管理者」から起動される時のどちらの場合も、「システムに登録されている特定の予約情報を削除する」という同じような結果をもたらすものであるため、この例では(このユースケース図を描いた人の気持ちとしては)「予約を取り消す」という単一のユースケースとして定義しているものと思います。

ここで、このユースケース「予約を取り消す」のイベント・フロー(アクターとシステム間の相互作用(インタラクション)の手順)をもう少し具体的に想像してみてください。もし、そうやって想像してみたイベント・フローが「会員」から起動された場合と「システム管理者」から起動された場合とで異なる箇所が多いようなら、実は別々のユースケースとして分けて取り扱った方が良いのかもしれません(図6)。

図6：ユースケース「予約を取り消す」を分解してみたユースケース図

ユースケースはアクタとシステムとの相互作用(インタラクション)のタイプを表わすものなので、(たとえ内部で利用する機能の多くが共通であっても)インタラクションの手順が大きく異なる場合はユースケースとしては別々のものとして分けて取り扱った方が有利になります。逆に、ユースケースの名前に囚われすぎて、大きく異なる二つのインタラクションを無理矢理ひとつのユースケースとしてまとめて取り扱おうとすると、(特にユースケース記述を作成する際に)本来負わなくて済むはずの苦労を背負ってしまうことになるかもしれません。

ただし、元の例のように「予約を取り消す」をひとつのユースケースとして取り扱うという方針が必ずしも「間違いである」とは言い切れないので注意してください。「そのユースケース図をどのように利用するか」という目的に応じて、「より取り扱いがしやすいユースケースの切り出し方」も変わってきます。

おわりに

ユースケース図の取り扱いや解釈については、UMLが公開された初期の頃に二転三転していろいろ混乱していた時期がありました。ユースケースの本体とも言えるユースケース記述の概念がUML仕様書中に明示されていない事も、誤解/誤用を広めてしまう要因のひとつとなったように思います。

現在は、いろいろな書籍、ホームページ、講座などでさまざまな例が紹介され、ユースケース記述の表記方法も含めてユースケース・モデルの「一般的な」取り扱い方法や注意点などに関する知見(ベスト・プラクティス)が広く知られるようになってきています。そのため、以前に比べて混乱してしまうことは少なくなりましたが、あまり知られていない注意点や誤解されにくい上手な記述方法など、まだまだいろいろ工夫の余地が残されている部分でもあります。ちょっとした工夫が大きな品質改善や効率向上に繋がることもあるので、今後も継続的に試行を重ねていきたいと思います。

※転載元の情報は上記執筆時点の情報です。
　上記執筆後に転載元の情報が修正されることがあります。