連載第2回-1
UMLの基礎と応用

(株)NTTデータ 技術開発本部 副本部長
山本修一郎

ユースケース

 統一モデリング言語UML(Unified Modeling Language)には、全部で9種類の図式がある。その中でも最も多くの担当者や工程で利用される図式がユースケース(Use Case)図式である。またユースケース図式は1992年のヤコブソンの本で初めて登場した新しい図式でもある。今回はユースケースについて、基本的な事項と適用上の留意点などを解説する。

ユースケースとは

 前回、ユースケース図はシステムの動的な構造を表すために記述する振る舞い図の一種であり、ユースケース図では外部環境とシステムの機能との関係を記述すると述べた。

 さて、ユースケースとはなんだろうか?

 UML仕様のドラフトやいくつかの教科書からユースケースについての説明を抜き出せば次のようになる。

(記述1)アクタとシステム間で交換される、システムが提供するアクションを伴う一連のメッセージの集合によって明確に定義される首尾一貫した機能の単位(a coherent unit of functionality)[1]
(記述2)アクタとシステム間の相互作用(Interaction)を説明した文章[2]
(記述3)ユーザーの一般的な目的に照らして結び付けられた一群のシナリオ[3]
(記述4)システムのある特定の使い方をするイベントのフローを記述した文章[2]
(記述5)アクタによって認識される観測可能な意味のある一つの結果を生成する一連のアクションの集合[4]

 これらの記述で用いられる用語の関係を考えてみよう。まずアクションやイベント、メッセージは相互作用の単位だと考えられる。また、ユーザーはアクタと同じだと考えてよいだろう。さらに特定のイベントのフローや、一連のアクションの集合はシナリオに対応付けることができる。これをまとめると、表1のようになる。

表1 ユースケースの構造
表1 ユースケースの構造

 したがって、ユースケースの定義は次のように整理できる。

 アクタとシステムやシステム内のクラスとの相互作用の単位としてアクションと対応するメッセージがある。複数のメッセージからなる一連の相互作用の系列がシステムの具体的な実行経路としてのシナリオである。互いに緊密に関連する複数のシナリオの集合に対応するクラスがユースケースである。

 換言すれば、ある目的に添って集められたアクタとシステムとが交換するメッセージの系列の集合が一つのユースケースを定義することになる。この意味で、ユースケースの完全な集合にはシステムを利用するすべての振る舞いが記述されていることになる。とはいえ、ユースケースを記述する上での課題も多い。それについては後述する。

ユースケース図式

 それではUML V1.4 draft February2001 3-97 359ページにあるユースケース図式(Use Case Diagram)の記述にしたがって見ていこう[1]。ユースケース図式ではシステムやサブシステム、クラスなどとアクタ間の関係を明らかにする。ユースケース図の構成要素は、システムの外部にあるアクタ、システムの内部にあるユースケースと、それらの間にある関係の3種に分けることができる。関係にはアクタとユースケースだけでなく、アクタ間の関係と、ユースケース間の関係もある。

◆アクタ
 アクタはシステムやクラスの利用者が、システムやクラスに対して果たす役割を定義する。人の形(stick man)のアイコンでアクタを表現する。クラスを表現する矩形でアクタを記述しても良い。この場合は<<actor>>というキーワードを矩形に付ける。ところでヤコブソンはもともと役割(Role)というスウェーデン語を使っていたのに英語に翻訳するときにアクタ(Actor)となったようだ。

◆ユースケース
 ユースケースは楕円で表現する。ステレオタイプキーワードはユースケース名の上に記述する。ユースケースが持つ属性リストはユースケース名の下に記述する。楕円は属性、操作拡張点を明記するためにいくつかの部屋に仕切ることができる。拡張点をユースケースに付加する場合、ユースケースを表す楕円内を線で仕切って作った部屋にextension pointを明記して、この部屋の中に拡張点の内容を記述する。

 ユースケースの振る舞いについては、テキスト、状態機械、操作などで記述することができる。どのような表現方法を用いるかについては決められていないので、状況に応じて適切な表現を選択する必要がある。たとえばユースケースとアクタ間の交信を記述するためにシーケンス図を用いることができる。

◆システム
 ユースケース図の中でユースケースの集合を矩形で囲むことにより指定されたユースケースを持つシステムやクラスを表現することができる。アクタはすべてこの矩形の外部にあり、ユースケースはすべてこの矩形の内部にある。システムの境界を矩形で示すのである。

◆関係
 関係にはアクタとユースケースの関係とアクタ間の一般化関係(generalizations)、ユースケース間の一般化関係(generalizations)、拡張関係(extends)、包含関係(includes)の5種がある。

◇関連(association)
 アクタとユースケースの間の関係を示す。アクタとユースケースの関係は関連関係だけである。関連関係は実線である。端点に多重度をつけることがある。

◇拡張(Extend)
 ユースケースには、拡張点を設けて他のユースケースの指定されたアクション系列をそこに挿入することができる。拡張点はユースケースの中で一意に識別可能な名前を持ち、振る舞いの中での挿入位置についても記述する。文章や状態機械の状態、事前条件や事後条件などで挿入位置を具体的に記述する。拡張点によりユースケースの一部を再利用できるようになっている。

 ユースケースAからユースケースBへの拡張関係は、Bの振る舞いがAの振る舞いによって拡張されることを示す。拡張関係によって参照されるBの拡張点を用いることにより、指定されたAの振る舞いがBに挿入される。拡張関係はラベル<<extend>>を持つ点線の有向矢で示す。

◇ユースケースの一般化
(Generalization)

 ユースケースCからDへの一般化関係はCがDの特別な場合であることを示す。一般化関係は白三角の実線の有向矢で示す。子ユースケースは親ユースケースの機能をすべて引き継ぐ。なおオブジェクト指向では「汎化」がGeneralizationの訳語で使われることが多いが、とくに難しい言葉を使う理由もないので本稿ではわかり易さのため「一般化」にした。

◇包含(Include)
 ユースケースEからFへの包含関係はEのインスタンスがFで指定される振る舞いをEの中で指定された位置に含んでいることを示す。包含関係はラベル<<include>>を持つ点線の有向矢で示す。

◇アクタの一般化
 アクタ間の関係には一般化がある。アクタAからアクタBへの一般化関係はAのインスタンスがBのインスタンスとして同じユースケースと交信できることを示す。

◆ユースケースの実現
 ユースケースの実現はコラボレーションの集合で規定される。コラボレーションはシステム内でインスタンスがどのように交信してユースケースのシーケンスを実行するかを定義する。

 ユースケースとその実現との関係はキーワード<<represented Classifier>>が付いたコラボレーションへの有向点線矢で示すことができる。少し前の教科書では<<realize>>がついている。このユースケースとその外部インタラクション・シーケンスとの実現関係をシーケンス図へのハイパーリンクによって示してもよい。

 上述したユースケース図の記述要素をまとめると表2のようになる。

表2 ユースケース図の構成要素
表2 ユースケース図の構成要素

NEXT >> 

・連載第1回

・連載第2回

・連載第3回

・連載第4回

・連載第5回

・連載第6回

・連載第7回

・連載第8回

・連載第9回

・連載第10回

・連載第11回

・連載第12回

・連載第13回

・連載第14回

・連載第15回

・連載第16回

・連載第17回