連載
» 2004年06月11日 12時00分 公開

UML BASIC LECTURE(1):あなたはテキスト指向、それともダイヤグラム指向? (2/2)

[羽生田栄一, 岡村敦彦(豆蔵),@IT]
前のページへ 1|2       

ユースケースチェーン(ダイヤグラム指向派用)

 ユースケースチェーンとは、イベントフローの始まりから終わりまでにたどるフローのブロックをそれぞれの独立したユースケースとして抽出し、includeやextendを使って記述される多数のユースケースを管理する方法です。

 例えば、レンタルビデオ店システムによる以下のようなユースケースを考えてみましょう。

ユースケース「ビデオを貸し出す」

  • ステップ1:アクターである店員は会員情報を照会する
  • ステップ2:システムは会員情報を検索する
  • ステップ3:アクターはレンタルしたいビデオを指定する
  • ステップ4:システムは貸し出し可能であることを確認する
  • ステップ5:アクターはビデオの貸し出しを指示する
  • ステップ6:システムはビデオの貸し出しを記録する


 これは、ユースケースの原則である「アクターに価値のある結果を返すまでの一連の相互作用」という考え方に照らせば、1つのユースケースになります。しかし、ステップ2の「会員情報を検索する」という振る舞いは、ほかのユースケース、例えば「ビデオを購入する」というようなユースケースでも同様の挙動が必要となるため、共有できるフローとして抽出したくなります。この場合は、抽出した「会員情報を検索する」というフローは必ず通るパスであり、ほかのユースケースとの共通部分として整理するので包含関係とします。図で描くと以下のようになります。

ALT 図1 この場合は、必ず通るパスでありほかのユースケースとの共通部分として整理するので、包含関係とします

 こうした包含関係を使用するユースケース図を目にすることは、珍しいことではありません。ここまでは特に問題はないです。さて、それでは、会員情報を検索した結果、まだ登録していない顧客だった場合はどうなるでしょうか。ちょっと考えてみてください。おそらく「新規会員情報を獲得する」ためのフローが必要になるでしょう。皆さんはこれをどう扱いますか? 代替フローとして、ユースケース記述に含めますか? それとも、新しいユースケースを1つ作りますか?

 ここでは、後者の立場をとり、1つの新しいユースケースを作ります。この場合は常に新規の会員登録を行うわけではないため新しいユースケースとの関係は拡張関係としましょう。そしてさらにここで考えます。新規会員情報の獲得方法が1種類ではない場合はどうすればよいでしょう。通常はそのままリアルタイムで会員情報を獲得できる(例えば、Webのフォームによる入力など)ものと考えますが、必ずしもそうでない場合も考えられます。(何らかの事情で後から情報を入手する場合など)そこまで気にしなくてよければもちろん構いませんが、考慮しなければならない場合はそれを適切に表現する必要があります。さて、今度は皆さんどうしますか?

ポイントは、プロジェクトが適切に稼働していること

 ここでは、アクターである店員の目的は同じ「新規会員情報を獲得する」ことですが、実際の振る舞いとしては異なるフローが必要になるので、汎化関係を使使って2つの新しいユースケースを作成してみましょう。ここまでのストーリーを図にすると、以下のようになります。

ALT 図2 ここまでのストーリーを図にすると……

 さて、このように包含関係、拡張関係、汎化関係が混在するユースケース図はあまり好まれませんし、どれか1つで済むように記述しなさい、とよくいわれます(私もそういってきました)。なぜかといえば、物事はシンプルなのがベストです。関係の種類が混在し、しかも意味的にも区別が難しいとなると、それは無駄に複雑にしているだけです。

 この図を分かりにくくしているのは、イベントフローを考えたときに、結局どのパスが有効なのかを、判別しにくいことが原因です。自然言語で書かれているテキスト記述を見た方が、素直に理解できるのではないでしょうか。

 しかし、その複雑さの要因を取り除くことができれば、問題は変わってきます。むしろ、テキスト記述を追いかけるよりも分かりやすい管理方法があったらどうでしょう。つまり、各ユースケースの起動順序を明確にし、どのパスがいつ有効になるのかをきちんと把握できればいいわけです。それが、ユースケースチェーンです。ユースケースチェーンは、起動したユースケースがたどるパスを一連のつながり(鎖:チェーン)として表現します(ちなみにテキスト重視派は、この複雑さのために、順序を考える必要があるフローはユースケースとしては分割しません)。

 この例では、具体的な実体としてのユースケースがたどるパスは3種類考えられますので、チェーンは以下のようになります。

  • チェーン1:{ビデオを貸し出す}→{会員情報を検索する}
  • チェーン2:{ビデオを貸し出す}→{会員情報を検索する}→{新規顧客情報をリアルタイムで獲得する}
  • チェーン3:{ビデオを貸し出す}→{会員情報を検索する}→{新規顧客情報をマニュアルで獲得する}

(「新規会員情報を獲得する」は抽象ユースケースとなるため、インスタンスは存在しません)

 もちろんこの程度の数であれば、こんなことをしなくても理解は可能ですが、実際のシステムを考えてみてください。以下のような場合に有効なことに気付くはずです。

  • 機能のリストアップ
  • 開発単位の優先順位付け
  • モデルのウオークスルー
  • モデルの検証
  • テストシナリオの作成

 つまり、このチェーンを利用しながら、実際のシナリオを考えていくことができるわけです。

 ダイヤグラム指向であるこのユースケースチェーンを使用すると、細かいユースケースが多数できることになります。これは、最近好まれているシンプルなユースケースモデルとは相反するものといえるかもしれません。ユースケースの提唱者であるイヴァー・ヤコブソン自身も、数の多いユースケースモデルは好まなかったはずです。なぜならばマ−ティン・ファウラーの名著『UMLモデリングのエッセンス』にも、ファウラー自身であれば、100個のユースケースを定義するべきところをヤコブソンは20個にしてしまう、というような記述が見られるからです。

 では、このユースケースチェーンのアプローチは誤っているのでしょうか?

 いえ、決してそんなことはありません。テキスト指向にせよダイヤグラム指向にせよ、そのプロジェクトにとって最も適したものが採用されて、「うまく」運用されているのであれば、どちらが間違いということはありません。

 実際に現在のヤコブソンは、自身の20個のユースケースという判断基準は誤りであったと認めています。つまり、彼自身が想定し得ないユースケースの使い方をしているプロジェクトとして、20個以下のユースケースプロジェクトや、逆に20個以上のユースケース(700以上!)のプロジェクトでもうまくいっている事例を見て、彼も考え方を改めたようです。

 つまり、どちらが良い/悪いということではなくプロジェクトとして、

  • ユースケースの粒度がそろっていること
  • その基準がプロジェクト内で明確であること
  • その運用ポリシーが浸透していること

その結果、

  • プロジェクトが混乱に陥らず適切に稼働していること

が重要です。

 ユースケースの今後の動向にもなかなか面白いものがあります。ヤコブソン自身はユースケースの表記法の変更をもくろんでいたりするようですし、最近のアスペクト指向に対応した「アスペクト指向ユースケース」や、MDAの動きをにらんだ「ランタイムユースケース」などいろいろなことを考えているようです。例えば「アスペクト指向ユースケース」は、AOPの提供する概念である「現状のモデル(システム)に変更を加えずに新しい振る舞いを追加する」というアプローチが、ユースケースとユースケースの実現の関係、もしくは基本ユースケースと拡張ユースケースの関係に似ている、という観点からの発想です。もちろんまだアイデアの域を出ないと思いますが、ユースケースとアスペクト指向の融合が何か革新的なものを生み出す、という手応えは実感しているようです。これからのユースケースもなかなか目が離せません。

 さて、皆さんはテキスト指向派ですか? それともダイヤグラム指向派ですか?

[番外編]

UML 2.0とユースケース(多重度について)

  UML 2.0は、UMLとしての初めてのメジャーバージョンアップであり、大幅な変更が加えられていますが、下位互換性を保つために一般のユーザはなるべく意識しなくてもすむように配慮されています。

 ユースケースに関係する表記に関しても、2.0からの大きな変更点は特にありません。従って、1.xまでのときと同じようにモデルを作成できますので、大きな影響はないといってよいでしょう。ただし、いくつか表現が明確になった要素があります。その中の1つがアクターとユースケース間の関連に対する多重度です。

ALT 図3 アクターとユースケース間のコミュニケーション関連に対する多重度

 この多重度の意味は、クラス図におけるそれと基本的には同じであることが明確になりました。つまりそれぞれのインスタンスの立場になった場合に、相手先が存在し得る可能性の数の範囲を表します。では、アクターとユースケースの場合の多重度が意味するものは何でしょう? アクターのインスタンスである実在の誰か(通常は人であることが多い)と、その誰かが実際にサービスを受ける対象は、普通に考えれば 「1:1」です。サービスを提供する側としてもそのときに対峙(たいじ)しているアクターは1人きりです。

 しかし、アクターが外部システムの場合はどうでしょう? 例えば、この例の場合は、銀行がそれに当たります。つまり外部のシステムである銀行から見れば、同時にコミュニケートしているユースケースの実体としては、複数存在している場合があり得るわけです。従ってここの多重度は、「1:*」として表現することになります。そういうわけで、そのようなケースも表現できるようになったわけですが、でもまあ、あまり気にしなくてもいいかもしれません……。

著者プロフィール

羽生田栄一

豆蔵 取締役会長

岡村敦彦

豆蔵


[参考]
前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ