連載
【改訂版】初歩のUML

第8回
顧客の要求をユースケースに反映させる

萩本順三　株式会社豆蔵
2003/7/5

　ユースケースとは何か？ なぜ必要か？ 今回は、だれも書いたことがない視点から、オブジェクト技術者が理解しておくべきユースケースモデルについてのノウハウを解説します。そもそも、ソフトウェア開発には、必ず開発を行う目的があります。どんなソフトウェアであってもこの目的がはっきりしないと、よいソフトウェアなど作れるはずがありません。筆者が初心者のころ、よく「構造化されたソフトウェアを考えてみよう」とか「継承を生かした何らかのソフトウェアを作ってみよう」といったことを計画し、自作ソフトウェアを作ろうと試みたことがありました。しかし、あえなくすべて失敗に終わってしまいました。「構造化」や「オブジェクトテクニック」が目的であっては何も作れないのです。では、ソフトウェア開発にとって最も重要なことは何でしょうか。そうです、「ソフトウェアがどのような人に、どう使われるか」ということなのです。今回は、UMLユースケースモデルを紹介します。ユースケースモデルは要求を表現するモデルです。「ソフトウェアがどのような人に、どう使われるか」を表すのが、ユースケースモデルなのです。

ユースケースモデルとは

　ユースケースモデルは、「ユースケース図」と「ユースケース記述」によって構成されます。

◇ユースケース図

　まずは、図1を見てください。これがユースケース図です。ユースケース図は、利用者から見たシステムの「使い方の例（ユースケース）」を示したものです。この図は、店頭で商品を販売するサービスと、Web上で商品を販売するサービスを持つ、商品販売システムを表しています。

図1 ユースケース図

　ユースケース図はとても簡単な図なので、あまり身構えずに読んでください。では、図の説明をしていきましょう。

　人形マークはアクターといいます。だ円をユースケースといいます。アクターは、システムを利用する何らかの役割を持つオブジェクトです。アクターは人であっても、サブシステムであっても構いません。システムにアクセスする何らかの役割を持ったものであればOKです。要するにアクターは、システムにアクセスする何らかの役割に名前を付けたものと考えれば分かりやすいでしょう。

　ユースケースとは、名前のとおり「システムの利用例」です。例えば、Webユーザーは、「商品を購入する」「購入商品を確認する」というユースケースを使うことができるのがこの図から分かります。商品販売システムと描かれた長方形は、システム境界と呼ばれ、システムの内外を区切ります。

　アクターは、システム境界の外部に書かれ、ユースケースはシステム境界の内部に書かれます。またアクターとユースケースをつなぐ線は関連といいます。

◇ユースケース記述

　ユースケース記述とは、ユースケース図の中の1つのユースケースについて、アクターとシステムのやりとりをストーリーとして書いたものです。例えば、「商品を購入する」というユースケースのユースケース記述を下記に書いてみましょう。

ユースケース名	商品を購入する
概要	本ユースケースは、Web上および店頭で商品を購入する際に呼び出される。店頭では、店員を通じて本ユースケースが利用される
アクター	Webユーザー、店員（オペレータ）
メインフロー	アクターは、購入したい商品のジャンルを選ぶ システムは、選択されたジャンルの商品一覧を返す アクターは、商品を選ぶ システムは、商品の詳細情報（説明、金額、写真）を返す アクターは、この商品でよければ商品購入手続きに入る
ユースケース記述

　いかがですか、簡単でしょう。上記のように、ストーリ部分はメインフローという所に書きます。ユースケース記述で書かれるフローのことを、イベントフローと呼びます。この例では、処理の中断や、前の処理に戻るなどの制御の流れについて省略しています。もう少し長々しく書いた本格方法を下記のコラムにまとめています。ここまで詳細に書いてしまうと、分析初期段階からドキュメント過多に陥りやすいので私としては、あまりお勧めしたくありません。

コラム：ユースケース記述補足

ユースケース記述には、必要に応じて、代替フロー（メインフローの条件分岐）、例外フロー（ユースケース中の例外的な挙動やシステムのユーザーから見えるエラー）を書きます。 　また、事前条件（ユースケースを呼び出すために満たすべき条件）や事後条件（ユースケースが終了される際にシステムが満たしておくべき条件）を書くこともできます。さらに、具体的な「もの」や「アクター」を説明するために、「シナリオ」を書くこともできます。イベントフローの一例をシナリオとして書いてみましょう。 ユーザーは、紳士服ジャンルを選ぶ システムは、紳士服の一覧を表示する ユーザーは、気に入った礼服を選ぶ システムは、選択された礼服の説明、サイズ、金額、写真を表示する ユーザーは、この礼服の購入手続きに入る

ユースケースモデル、誰のため、何のため？

　ユースケースモデルがどんなものか分かりましたか？

　ユースケースモデルを一言でいうと、「システムを利用者の視点で端的にとらえたモデル」です。では、ユースケースとは誰のために、何のために、必要なのかという点について考えてみましょう。まず、いままでのソフトウェア開発における要件定義フェイズはどうやっていたのでしょうか。開発者の立場で要求をまとめていたのでは？ そのような要件定義では、ユーザーは理解できるはずもなく、つい「これでいいですよ！」と開発者にいってしまいます。ここから悲劇の始まりです。システムに要求されているものと異なるシステムを作ってしまう原因となるわけです。

　開発者は、もう少しユーザーの視点で、つまりユーザーがどのようにシステムを利用するかといった視点で要求をまとめる必要があります。ユーザーの視点でまとめられた世界には、データベースやネットワークがどうのこうのという話はなく、あるのは「誰が、どうやれば、何ができるのか」ということに尽きます。このようにシステム利用者の視点で作るモデルがユースケースモデルです。そうすることで、ユーザーの業務ナレッジを最大限にシステムに生かすことができるのです。

　ユースケースモデルは、システムの利用者の視点で、システムの利用者と開発者の間でシステム要求の姿を明らかにするために作成されるモデルなのです。ユースケースモデルを開発でうまく活用するには、利用者主導でこのモデルを完成させることです（図2）。

図2 利用者主導で作成されたユースケースを開発者と共有するという考えが重要

開発者から見たユースケース

　次は、開発者の視点でユースケースをとらえてみましょう。つまり、開発するソフトウェアの構造とユースケースとの関係を調べてみることにします。図3は、「商品を購入する」ユースケースを開発者の視点で拡大したものです。ユースケースの中に開発者から見た、各種機能があります。ユースケースは、ユーザーから見た機能ですが、図3は、開発者から見たソフトウェア機能や画面も複数含まれ束ねられているものです。ユースケースは、あくまで、ユーザーから見た機能ということを忘れないでください。開発者から見える機能は、ユースケースとしては適切ではないことが多いのです。また、複数の機能や画面を束ねているという点も重要なポイントです。これは、ユースケース名は、ユーザーの利用事例に名前を付けたものと考えるとよいでしょう。「商品を購入する」というユースケース名も、システムの利用例をひとくくり（利用の単位）にして名前を付けたものです。

　なぜこのことが重要かというと、ある程度の規模になるビジネスアプリケーションにおいては、ユースケースの個数やユースケース図の枚数が膨大になる可能性があるからです。システムの利用単位でユースケースを書くことで、この問題を解決することができます。

　ユースケース図は何枚程度が適切ですかって？

　そうですね、どんなに多くなっても、ユースケース図20枚以内、図中のユースケース7個以内程度に抑えるようにした方がいいでしょうね。

図3 ユースケースを開発者の視点で拡大すると！

オブジェクト技術から見たユースケース

　次は、オブジェクト技術からユースケースモデルを見てみましょう。ええっ、UMLの中に入っているからユースケースモデルはオブジェクトモデリング技術の一種なんでしょって？ 実は、そうではありません。ユースケースモデルは、オブジェクトモデリングとは異なる機能中心のモデリング技術なのです。しかし、オブジェクト指向開発には必須ともいえるものです。さて、ここからオブジェクト技術を追求しようと思っている読者の方々も必読です。オブジェクト技術を追求するビギナーの陥りやすい落とし穴について説明します。

　皆さん、オブジェクト技術の効果は何だと思いますか？ おそらく「再利用性」「拡張性」という話が必ず出てくるでしょう。たいていの自称オブジェクト技術者は、ソフトウェアの本質の尺度として再利用性と拡張性に重きを置いています。

　ここで、ユースケース図の中に現れるシステム境界とオブジェクトの再利用性と拡張性について簡単に説明している図4を示します。

図4 バランス感覚のないオブジェクト技術者は致命的？

　この図のように、オブジェクトの再利用性や拡張性を考慮するということは、システム境界からはみ出たオブジェクトを対象にするということになります。なぜなら、再利用可能なオブジェクトには、システムで必要とされる要求を満たす機能のほか、ほかのシステムでも必要とされるであろう機能を盛り込むからです。また、オブジェクトに拡張メカニズムを組み込むことは、いま必要な機能だけではなく、将来必要とされる機能を組み込むメカニズムを導入することなのです。

　このような思考をシステムに対する要求と同じ視点で考えてしまう人は、システム境界が図4の右側のように見えています。つまり、いま必要とされる要求に疎くなるのです。このような問題を解決するためにもユースケースモデルは非常に有効です。なぜなら、まずユースケースによってユーザーからシステムに要求されている機能は何なのかをしっかりととらえることができるからです。

　ただ、ユースケースモデルがあるから安心と考えるべきではありません。オブジェクト技術を実践する技術者の心得としては、ユースケースモデルに頼ることなく、「アプリケーションの視点」と「オブジェクトの視点」という2つの視点をバランスよく併せ持ち、それぞれの視点でシステム開発を見るべきです。「アプリケーションの視点」とは、システムとして必要とされているものが何で、それをいつまでに作るべきかというユースケースの視点です。「オブジェクトの視点」とは、いま何が必要かということだけではなく、将来必要となる機能は何か、また、そのソフトウェアの構造はどうなっているのか、さらに、その中で再利用できる個所はどこなのかといった視点です。

ユースケースモデルの描き方

　ユースケースモデルを開発者が書くとき陥りやすい落とし穴について説明します。

◇機能単位をユースケースにするな

　ユースケースの単位を、機能分割の感覚で作ってしまいます。そのようなユースケースは、ユーザーの視点から見ると時系列を伴うものが多く、時系列を表すすべがないユースケース図には不適切であり、また、ユースケースの個数が膨大になってしまいます。

◇データベースがどこにあるかなどは問題ではない

　よくある誤解が、例えば「商品を登録する」というユースケースの中にデータベースが存在すると勘違いしてしまうことです。この勘違いから、「商品を参照する」というユースケースに関連を持つアクターからも「商品を登録する」に関連を引いてしまいます（図5）。

図5 正しくないユースケース図

◇アクターの正しい理解

　最初に紹介した図1のユースケース図で、あなたが管理者だったとしましょう。あなたがもし商品購入ができるとしたら、それは、管理者という立場で、商品購入ユースケースと関連を持つのか、それとも、店員という立場で、商品購入ユースケースと関連を持つのか考えなければなりません。前者の場合は、管理者から商品購入ユースケースに関連を引く必要性が生じますが、後者の場合、その必要はありません。このように、アクターは、システムにアクセスする外部のアクターの責務を明確にすることで、システム運用における仕様を明らかにさせることが目的なのですが、この点があいまいな記述がよく見られます。

◇システムの根拠がないまま挙動を書いてしまう

　ユースケース記述は、あまり細かく書いてしまうと問題が起こることがあります。なぜかというと、ユースケース記述は、要求定義というシステム開発のかなり早いフェイズで用いられるモデルだからです。よってシステムの詳細な動きについてシステマチックに書きすぎると、根拠なき挙動を書いてしまうということにつながります。システム屋さんが陥りやすい落とし穴です。ちょっとしたストーリ（構想）を書いているという軽い気持ちの方がうまくいくようです。

◇要求はユースケースかユースケース記述に書く

　ユースケース図は、システムの要求をビジュアルにとらえるものです。しかし、一般にユースケースの粒度はかなり大きくなります。そうすると、ユースケースだけを見ても要求がどのようなものであるか一目で分かりません。そこで、ユースケース記述でそれを補うわけです。従って、システムに対する主要な要求は、ユースケースかユースケース記述によって表現されていなければなりません。そのような定義からすると図1で紹介したユースケース図中の「商品を購入する」というユースケースを説明するユースケース記述（表）のメインフロー部は何か問題があると思いませんか？

1	アクターは、購入したい商品のジャンルを選ぶ
2	システムは、選択されたジャンルの商品一覧を返す
3	アクターは、商品を選ぶ
4	システムは、商品の詳細情報（説明、金額、写真）を返す
5	アクターは、この商品でよければ商品購入手続きに入る
表 ユースケース記述メインフロー

　このメインフローには、「商品購入手続き」というストーリがまだ明らかにされていません。これに対応するには2つの方法があります。まず、1つ目は、ユースケース記述に商品購入手続きの内容についてアクターとシステムのやりとりを書いていくことです。もう1つのやり方としては、「商品購入手続き」ユースケースを追加する方法です。ただし、「商品購入手続き」ユースケースは、アクターが単独で利用するものではないので、「商品を購入する」ユースケースから呼び出される部品的なユースケースとして表します。

　ユースケース図では、このようなユースケースは、包含（include）ステレオタイプを利用した依存関係を使って表すことができます。図6を見てください。

図6 商品購入手続きユースケース（includeを使って表現）

　「商品を購入する」は「商品購入手続き」を包含（include）しています。ただし、この方法は「開発者から見た機能を分割してユースケースにしてはならない」という点に十分注意してください。これでユースケース図としては完成です。このように、原則としてユースケース図かユースケース記述にシステムのすべての要求を書きます。なぜ、「原則として」と書いたかというと、開発対象のシステムが大きくなればなるほど、ユースケースは本質的な要求だけにとどめておいた方がよいからです。例えば、システムのマスタメンテナンスなどの細かな機能まで網羅しても仕方がありませんからね。

ユースケースモデルは機能要求をとらえる

　図4で、拡張性、再利用性といった視点とは異なる視点で、ユースケースモデルをとらえると説明しました。では、拡張性、再利用性については、どのように開発の中に組み込んでいくのでしょうか。また、パフォーマンスや信頼性といったユーザーから見た機能というものとは異なる要求はどうすればよいのでしょうか？

　実は、ユースケースモデルで整理できる要求は、「機能要求」のみです。機能要求とは、システムを利用する利用者から見てシステムの機能と考えられるもののことをいいます。また、それ以外の要求のことを「非機能要求」といいます。拡張性、再利用性、パフォーマンス、信頼性といったものは非機能要求に該当します。非機能要求は、ユースケースモデルでは表せないため、非機能要求一覧としてまとめられます。

　非機能要求についてもしっかりとアーキテクチャ設計に加味されます。この辺の話についてもこの連載の中で取り上げていきます。

　今回はこれでおしまいです。次回は、オブジェクト技術を使ってどのように開発を進めていくのか、どのようにモデリングを利用するのかという点について、オブジェクトベースの開発プロセスの考え方について説明します。では、お楽しみに！

IT Architect 連載記事一覧