連載第２回－２
UMLの基礎と応用
（株）NTTデータ 技術開発本部 副本部長
山本修一郎
■ユースケース・モデルとは
ユースケース・モデルについては、次の２つの記述がある。
（記述A）ユースケース・モデルはユースケース、アクタ、ユースケース図から構成される。
（記述B）ユースケース・モデルはユースケース図として記述される。
定義Aではユースケースやアクタに関する記述はユースケース図の中には含まれないと考えるわけだ。定義Bではユースケースの内容は文書属性で記述すると述べているので、ユースケース図の中にユースケースの内容まで含めて考えているとみなすこともできる。あるいは定義Aと定義Bの違いはユースケース図の要素に関する記述をモデルに含めるかどうかの違いということもできる。いずれにしてもUMLの本を読むときはこういう微妙な部分についても、この著者は問題をこういう風に捉えているんだなということを間接的に読み取っていく必要があるわけで、こういうことがいくつかの部分で重なってくるとなんとなくわかった気がするが釈然としないという印象を読者に与えかねないことにもなるのかもしれない。逆にいえば複数の教科書を並べて比較しながら読むことで理解がいっそう深まるし、新たな発見があるということなのかもしれない。
■ユースケースビュウ
ユースケースビュウを利用するのは顧客、分析者、設計者、開発者、試験担当者である。このことからもユースケースがUMLで非常に重要で幅広く利用されるビュウであることが分かる。たとえば、ユースケースのアクタと実際の顧客との対応関係を吟味することにより、同じユースケースを利用する顧客ごとにグループ化して、システムの利用法を教育することができる。また、よく指摘されているように、ユースケースが一連のメッセージの集合から構成されているので、テスト項目を抽出するのに利用できる。しかし、その場合には、ユースケースをあらかじめ構造化して記述しておく必要がある。言い換えればどのように利用するかを考慮してユースケースの書き方も工夫しておく必要があるということだ。
ユースケースビュウのもう一つの意義としては、機能とオブジェクトを分離することで他のオブジェクト図式と異なる視点でオブジェクトモデルを記述できるようになったことが大きい。ユースケースビュウの目的は外部アクタの観点からシステムの機能を示すことである。言い換えると、システムやサブシステムあるいはクラスの内部構造の詳細を明記することなくエンティティの振る舞いの一部を定義することである。システム境界の内部に記述したユースケースによって、システムを実現するクラスに対して要求される機能の集合を表現しているのである。ここでシステム内のオブジェクトはユースケース図には、まったく記述しないことに注意しよう。実現関係でシーケンス図が対応するユースケースに関係付けられるだけである。このように、ユースケース図は、オブジェクトではなくシステムの機能を記述することを目的としている点に留意する必要があるだろう。UMLでは、ユースケース図によりシステム機能と外部環境の関係を記述することができるので、従来手法の経験者や初心者でもオブジェクト指向開発に取組みやすくなると思われる。実際、ここで説明したように構造化手法で導入されていたコンテクスト図式でも外部環境としてアクタに対応する概念もあったし、プロセスとそれに対応するプロセス仕様では、ユースケースで対象としているシナリオを記述していたのである。ただし、構造化手法ではデータの入出力を中心として分析している点が、アクタとシステムとの相互作用を分析するユースケースと異なるということだと思われる。またユースケースでは、一般化、拡張、包含といった機能に関する関係概念が整理されているが、構造化手法ではユースケースの機能に相当するプロセスに関する詳細化関係しかない点も異なる。これらの点についても詳細な議論が可能になると思われるが、本稿の範囲を越えるので割愛する。
■ユースケース作成上の課題
◆アクタの抽出
アクタはシステムと相互作用を持つすべての役割（Role）のクラスであることに注意して、アクタを抽出する必要がある。したがって対象とするシステムが実現するビジネスモデルのプレーヤは誰かを考えることが重要になる。ビジネスモデルのプレーヤには、システムのクライアントだけではなくプロバイダーも存在するし、バックヤードシステムも存在する。したがって、アクタを抽出する上では、まずビジネスモデルを考え、すべての関連するプレーヤと必要なリソースを明らかにすることが有効である。また、安全性の高いシステムを開発する場合、正当なアクタだけではなく、不正なアクタも抽出しておくとわかり易い。そうすれば不正行為を防ぐための機能を表すユースケースを明示的に抽出できるからである。
◆ユースケースの抽出
ユースケースはアクタに対して必要な相互作用のシナリオのクラスがユースケースであることに注意してユースケースを抽出する。たとえば、アクタに対して提供する必要のある機能や、通知イベント、情報提供などを列挙する。またシステムが実現しようとしているビジネスモデルのプレーヤ間での相互作用や情報の流れにも着目して、どの部分をシステムで実現し、どの部分が他のシステムや手作業で実現するのかを判断して必要なユースケースを抽出する。この過程で抽出されたユースケースに対応するアクタがもしなければ、ユースケースに対応するアクタをそれまでに抽出していたアクタの集合に追加して補完する。
◆記述法の統一
ユースケースは表記法が柔軟であるため、コクバーンはユースケースの定義がさまざまで統一されていないと指摘している［５］。したがってユースケースの適用にあたっては、記述法についてプロジェクトごとに適切なガイドラインを定めておくべきである。次のような観点がある。
・要求仕様なのか、それともユーザーの要求を明確化するための補助的な文書なのか。
・シーケンス図のような形式的な構造で記述するのか、それとも文章で記述するのか。
・内容の一貫性を保証するかどうか。たとえば要求仕様を記述するのであれば、内容に矛盾があってはならない。しかし、要求仕様を作成する前段階でユーザーとの対話で要求理解を深めるのにユースケースを使うのであれば内容の矛盾はあっても構わないという考え方もあり得る。
・シナリオとユースケースの関係を明確にしておく。一つの考え方としてユースケースは複数のシナリオをインスタンスとするシナリオのクラスだとすることもできる。この考えでは、シナリオはユースケースのインスタンスでシステムの特定の実行経路を表現するのである。
◆構成の統一
ユースケースのグループ化や関連付けの指針がない。たとえば、グループ化の場合、アクタごとにまとめたり、ユースケースを構成するアクションを提供するサブシステムやクラスごとにまとめることもできる。あるいはユースケース同士の類似性によってグループ化することもできるだろう。
また、拡張関係、包含関係、一般化関係をどう使い分ければいいのか？ たとえば関係の使い分けに対して次のような規則がある［３］。
・同一処理の共通化には包含関係を使う
・通常処理と特殊な処理の場合分けには一般化関係を使う
・通常処理の拡張点を具体的に指定する場合には、拡張関係を使う
しかし、詳しく考えると、異なる関係の組み合わせが同じ意味を表現できる場合がありそうである。この問題の攻め方は次のようになるだろう。たとえばユースケースをシナリオ集合だと考えよう。そうすると複数のシナリオ集合が存在したときにそれらを拡張関係、包含関係、一般化関係によってどのように再構成すればいいのかということになる。このとき、ユースケースの集合が満たすべき構造上の良形性の尺度を定めておく。たとえば、最小性などの尺度が考えられるだろう。この尺度に基づいて、このユースケースの集合は、どのような関係構造を持つべきかを決定することができると思われる。
というわけで大規模なプロジェクトの場合は多数の担当者が参加することになるから、これらの点をよくよく整理しておかないと、担当者間の意識のずれがユースケース・モデルのずれにつながる恐れがあると思われる。
またユースケースの詳細化をどのレベルでとどめるのかについての明確な指針がないことも問題になる。詳細化の一つの指針としては、開発を進める上でのリスクがあると思われるユースケースについて、リスク要因がなくなるまで詳細化をするというものだ。しかしリスクが予見できるかどうかは顧客や分析者に依存するという問題もあるし、詳細化のレベルがリスクの有無によってユースケースごとに異なるというバランスの問題もある。もう一つの考え方は、関係に基づくユースケース集合の再構成と同じように、ユースケースを構成するシナリオやメッセージシーケンスの集合に対して詳細化レベルを決定する方法である。いずれにしろ有限の時間を使ってユースケースを作成するわけだから、ユースケースをどこまで詳細化するのかについては総合的な判断が必要である。
◆ユースケースで記述できない要求
ユースケースはシステム入出力を記述しないので、インタフェースに関する要求仕様をユースケースでは記述できないことになる。ユースケースで抽出した機能に関する入出力情報を他の方法で獲得する必要がある。また、入出力項目に関する制約条件（たとえば、利益率や税率などの条件）についてもユースケースでは記述しない。さらに性能要求や画面構成などのユーザーインタフェースについてもユースケースでは扱わない。
今回は、ユースケースとは何かについて述べたがユースケースの実例を記述する余裕がなかったので、次回はユースケース図の例を紹介しよう。
[参考文献]
[１] OMG, UML Resource Page, http://www. omg.org/technology/uml/index.htm
3 .54 Use Case Diagram , UML V 1 .4 draft February 2001
[２]ジム・コナレン著，UMLによるWebアプリケーション開発，ピアソン・エデュケーション,2000．
[３]ファウラ－,スコット著羽生田監訳,UMLモデリングのエッセンス第2版,翔泳社,2000.
[４] エリクソン,ペンカー著，杉本他訳,UMLガイドブック，トッパン(原著名UML Toolkit) ,1998.
[５] Cockburn,A.,Structuring Use Cases with Goals,
http://members.aol.com/acockburn/papers/usecases.htm