ホーム >  連載企画：UMLの基礎と応用 >  連載第６回 １ ２

連載第６－２回
UMLの基礎と応用

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

　UMLのクラス間の関係には関連の他に次の５種類がある。

・集約（aggregation）

　全体を表すクラスとその部分を表すクラスとの関係を示す。たとえば、企業には事業部や従業員が部分として含まれていることを集約関係によって示すことができる。全体を表す矩形に接続する点に白い菱形をつけて集約関係を明示する。集約は関連の特別な場合であり、役割名、多重度、誘導可能性などを集約につけることができる。集約は全体と部分の関係を表すから、この関係に対する実線の両端に菱形をつけることはできないことに注意する。

・複合（Composition）

　全体を表すクラスと、その要素として含まれるクラスとの関係を複合という。複合では要素クラスは異なるクラスに含まれないことが必要である。したがって複合は集約よりも強い関係を表す。このため複合集約（Composite aggregation）ともいう。

　たとえばパソコンでは、フォルダによって複数のフォルダやファイルを階層的に管理することができる。上位のフォルダを消去するとそのフォルダに含まれるすべてのファイルやフォルダはすべて消去される。このように子のクラスに対する親クラスが必ず１個存在し、それがなくなると子のクラスもなくなるような関係を複合関係によって表現できる。

　全体を表す矩形に接続する点に黒い菱形をつけて複合関係を明示する。複合は関連の特別な場合であり、役割名、多重度、誘導可能性などを複合につけることができる。複合は集約と同様に全体と部分の関係を表すから、この関係に対する実線の両端に菱形をつけることはできないことに注意する。

・一般化（汎化，generalization）

　一般的なクラスと具体的なクラスとの関係を一般化（汎化）という。一般的なクラスをスーパクラス、具体的なクラスをサブクラスともいう。一般的なクラスに接続する点に白い三角を置くことにより一般化関係を明示する。たとえば、ファイルにはテキスト形式ファイルやHTML形式ファイルなどがあることを一般化関係で示すことができる。

・依存（dependency）

　あるクラスの変更が他のクラスに影響することを依存関係で示すことができる。依存関係は点線で示し、影響が与えられる側のクラスに接続する点に矢印をつける。ステレオタイプ名を依存関係のラベル名としてつけることにより依存関係の種類を表現できる。

・実現（realization）

　仕様を表すクラスとその仕様を実現するクラスとの関係を示す。たとえば、分析レベルで記述したクラスを実現する設計レベルのクラスを実現関係により明記することができる。実現関係を表現する場合、仕様クラスとその実現クラスを点線で接続し、仕様クラスに接する点に白い三角形を置く。

　以上述べたクラス図の関連を表１にまとめて示す。ただし表１では多項関係を省略した。


表1　クラス間の関係

　またクラス図における関連の代表的な例を図２に示す。


図2　クラス図の関連の例

・リンク（link）

　オブジェクト図ではインスタンス間の関係を記述するリンク関係を記述する。リンク関係は実線だけで示す。リンクには役割名をつけることができる。しかし、矢印や多重度などはつけないので注意する。

■クラス図の記述レベル

　クラス図では次の３種類の記述レベルを選択することができる。

概念レベル：クラス名だけでクラスを表しクラス間の概念的な関係を表現する。
仕様レベル：クラス名だけでなく属性や操作も記述してクラス間の構造を表現する。
実装レベル：仕様レベルのクラス図を詳細化してプログラミング言語を用いて実装に必要な情報を記述する。

　これらの３つの記述レベルを対比して図３に示す。


図3　クラス表現のレベル

　このようにUMLではクラスをソフトウェア開発工程にあわせて段階的に進化させていくことができるという特徴がある。また、同じクラス図の中に、仕様レベルのクラスとその実装である実装レベルのクラスを記述し、実現関係で両者を対応付けることができる。

■クラス図の作成手順の例

　UMLではシーケンス図を要件定義、要求分析と設計などの複数の工程で用いることができたように、クラス図も複数の工程で使うことができる。またすでに述べたように、クラス図では、異なる工程のクラス間の関係を実現関係で記述できる。これにより異なるモデル間の設計情報の追跡が容易になる。

　まず要件定義では、アクタとシステムに関するユースケースを記述することにより、アクタとシステムの相互作用を分析するものとしよう。この段階でクラス図を作成するとすると、アクタをクラスとし、ユースケースの機能に対するトランザクションとしてのクラスを記述することになるだろう。しかし、アクタをクラスとしてしまうと、アクタはシステムの外部エンティティなので、システムの内部で扱うことができないことになる。また、ユースケース図と同じ内容をクラス図で重複して記述してしまうことになり冗長である。したがってこの段階ではユース
ケース図だけにしておくほうがよさそうである。

　前回のシーケンス図の例では、要求分析段階で、ユースケースを詳細化し、システムを構成する複数のオブジェクトを抽出することによりシーケンス図を記述することにした。この場合、システムを境界オブジェクト、制御オブジェクト、エンティティ（実体）オブジェクトなどの複数のオブジェクトに分解して、シーケンス図でこれらのオブジェクトとアクタとの動的な相互関係を明らかにした。クラス図ではシーケンス図で抽出されたオブジェクトに関する静的な関係構造を明らかにする必要がある。すなわち、シーケンス図で抽出された境界オブジェクト、制御オブジェクト、実体オブジェクトをクラスとしてクラス図を記述する。次いでこのクラス図の各クラスの属性や操作を追加する。また、次のような情報をクラスとして記述するかどうか検討する。

・アクタ
・シーケンス図のメッセージ

　たとえば、酒類販売の在庫管理問題では、アクタとしての注文主や、出庫依頼メッセージなどをクラスとしてクラス図に追加するかどうか検討することになるだろう。注文主は、出庫指示書の属性でもいいかもしれないし、永続オブジェクトとして実体クラスで管理するほうがいいかもしれない。また出庫依頼についても操作の引数として複数の変数の並びで指定するだけなのか、それともクラスとして複数の属性を持つ出庫指示書を管理するのか判断しなくてはならないだろう。要求分析段階では、このようなクラス抽出上のいくつかの可能性を列挙して判断した結果をクラス図で記述するのだということに留意する必要がある。注文主をクラスとして追加した場合、ユースケース図のアクタが実体クラスになるので少し奇妙な気がするかもしれない。また、注文主に対する境界オブジェクトをクラスとして抽出するので、そういう意味でも理解しにくいかもしれない。しかし、よく考えると、利用者の情報はシステムの内部で管理される必要があるし、利用者が必要とする操作を指定するためにはユーザーインタフェースが必要になるのは当然のことである。この意味でも、ユースケース図のアクタが、分析段階のクラス図では、境界オブジェクトと実体オブジェクトに対するクラスとして記述されることになるのは自然であると思われる。

　次いでシステム設計ではシーケンス図を用いてサブシステム間のインタフェースを詳細化する。したがって設計レベルのクラス図では、シーケンス図で必要なクラスとクラス間の関係を記述する。またシーケンス図のメッセージに対応するようにクラスの操作を記述する。

　このようにクラス図の記述内容はシーケンス図の記述内容が要求定義から要求分析、設計へと段階的に詳細化されていくのと同じように詳細化しながら記述していくことができる。

■まとめ

　本稿ではクラス図とオブジェクト図について紹介した。また、ユースケース図やシーケンス図とクラス図との関係やクラス図の作成手順についても述べた。次回は、ROSEを用いてクラス図を記述してみよう。またクラス図に関する今回触れられなかった事項についても述べる。

参考文献
[１]ファウラー,スコット著羽生田監訳,UMLモデリングのエッセンス 第2版,翔泳社,2000.
[２] エリクソン,ペンカー著,杉本他訳,UMLガイドブック，トッパン(原著名UML Toolkit),1998.
[３] 日本語版UML(Unified Modeling Language)ドキュメントver 1.1,http://www.rational.co.jp/uml/
[４] Unified Modeling Language (UML), version1.4,
http://www.omg.org/technology/documents/formal/uml.htm
[５] Rumbaugh,J.,Blaha,M.,Premerlani,W.,Eddy,F.,and Lorensen,W.,Object-Oriented Modeling and Design, Prentice-Hall,1991.