UML BASIC LECTURE（1）
あなたはテキスト指向、それともダイヤグラム指向？



豆蔵 取締役会長 羽生田栄一
豆蔵 岡村敦彦
2004/6/11

---

■ ユースケースのわな：機能 vs. 価値の提供（サービス）

　書籍や文献、セミナーなどが増えてきた関係で、ユースケースという技法が数年前と比較するとだいぶポピュラーになってきました。いろいろなところで話をするときも、以前は「ユースケースって何」といった入門的なところからの話題が多かったのですが、いまは「本当はどこまで書けばよいのか」「どうすれば効果的に使えるのか」といった実践的な部分に関心が移ってきているようです。実はそれはUML全体にもいえることなのですが、特にとっつきやすいユースケースにおいて、最も顕著であるといってよいでしょう。

　とはいえ、ユースケースの考え方自体はそれほど新しい概念ではなく、もともとの発想は1967年といいますから、業界的には古い考え方といってもよいかもしれません。その後それが実際のプロジェクトの中で使われていくうちに徐々に洗練され、現在の形に近づいてきた結果、公式な形でユースケースとして表に出たのが1986年、書籍として広く知れ渡ったのが1992年になります。ですので、そうした意味では新しいとも古いともいえない微妙な時期でもあります。

　それがオブジェクト指向の世界で、広く受け入れられるようになり、UMLの記述としても採用されるようになったのは周知のとおりです。

　さて、そのユースケースで最も議論となるのがユースケースの粒度（大きさ）に関してでしょう。どのレベルでどこまで書けばよいのか、迷ったことがない人はいないはずです。

　その際、一番役に立つ指針は、“Actor's Satisfaction”の原則、日本語でいえば『アクター満足度充足の原則』です。つまり、個々のユースケースは決してシステムの内部処理機能を提供するのが目的ではなく、あくまでも「対応するアクターに対して、業務上意味のある何らかのバリュー（価値）を提供するひとまとまりのシステムの振る舞い」をユースケースとしなさい、というものです。いい換えれば、システムにとっての機能ではなく、利用者としてのアクターに対するサービスの視点でユースケースを識別・管理しましょうね、という指針です。

　この原則に立つことで、GUIに絡んだ細かな処理やDBアクセスといった内部処理は排除され、アクターが本来システムを利用する目的に沿った形で、ユースケースを定義する、という指針が得られます。ここから、（i）UIに依存しないでユースケース定義のイベントフローを書こう、（ii）イベントフローの各ステップはこまごまとした処理手順ではなくアクターやシステムのアクションの「意図」を書こう、といった指針も導かれます。

　しかし、これらの指針を踏まえたうえで、なおかつ、プロジェクト管理や要求管理のしやすさ、という観点もユースケースをとらえる際に重要になってきます。つまり、要求の再利用性や、ユースケースに対応する設計実装といった作業の管理の視点です。以下、ユースケース定義（イベントフロー）の管理の一部をダイヤグラムで行う場合の考え方、そのヒントをご提供しましょう。

■ テキスト指向とダイヤグラム指向

　ユースケースの使い方に関する混乱は、UMLの仕様ではユースケースのダイヤグラムとしてその記述方法が定義されているのみで、ユースケースの内容であるユースケース記述に関しては、何ら規定されるものではなかったのも大きな原因です。従って、ユースケースを利用するそれぞれの人が、自分の流儀でユースケースを活用する方法を考えなければなりませんでした。その考え方は、大きく分けて以下の2つの傾向に分類できます。

粒度の大きいユースケース	全体的な見通しの利くレベルで大きいユースケースを定義し、詳細な内容はユースケース記述としてテキスト形式で表現する
粒度の小さいユースケース	UMLで規定されているユースケース間の関係を活用し、ダイヤグラムでの表現を重要視する

　ここでは便宜的に前者をテキスト指向、後者をダイヤグラム指向と名付けることにしますが、これは非常に悩ましい問題といえます。例えば大きいユースケースを採用し、詳細についてはテキストで記述していくようにすると、どうしても同じような文章を何度も書くことになってしまいます。結局、ユースケースの構造を意識するincludeやextendを使わざるを得ずどっちつかずのユースケースモデルとなり、しかも分かりにくくなってしまった、という経験をお持ちの方もいらっしゃるのではないでしょうか。また逆に、小さいユースケースを採用した結果、クラス図よりも複雑なダイヤグラムとなってしまったため、一所懸命書いたのはいいがその後に参照されることはなかった、というようなことはなかったでしょうか。

　つまり、以下のようなトレードオフがあります。

	ユースケースの管理	ユースケース記述
大きいユースケース	管理しやすい	記述が複雑
小さいユースケース	管理が複雑	記述がシンプル

　ここで、ユースケース間の関係について、簡単に復習しておきましょう。

　UMLでは、ユースケースは、以下の3つの関係が標準で決められています。

・包含関係：依存関係のステレオタイプ <<include>> で表現する
・拡張関係：依存関係のステレオタイプ <<extend>> で表現する
・汎化関係：クラス図と同様の generalization で表現する

　最近では、クリスタルメソッドというアジャイル手法を提唱するアリスター・コーバーンの書籍『ユースケース実践ガイド』の影響もあり、ユースケースの本質はテキスト記述であり、ダイヤグラム自体にはそれほど意味はない、とする考え方も浸透してきているようですが、それでも実際に書いてみる局面になると、どうしてもその悩みにぶつかります。

　そこで、今回は後者の流派（ダイヤグラム指向派）にとってのヒントとなるようなTIPSを紹介してみたいと思います。

1/2

INDEX
UML BASIC LECTURE（1） あなたはテキスト指向、それともダイヤグラム指向？
	Page1 ユースケースのわな：機能 vs. 価値の提供（サービス）
	Page2 ユースケースチェーン（ダイヤグラム指向派用）

IT Architect 連載記事一覧

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）