最終更新日：2007.10.13 - 渕田孝康
UML は Unified Modeling Language（統一モデリング言語）の略であり、1990年代に群雄割拠していたオブジェクト指向分析・設計方法論の統一をはかって、1994年頃に Ratinal Software 社の Grady Booch と Jim Rumbaugh が活動を開始したことに端を発する。その後、方法論そのものを統一することは困難であるという見解から、まずは方法論で使用されるモデルの表記法を統一しようという方向に変化した。
その結果、1997年に、オブジェクト指向業界最大の団体である OMG(Object Management Group) によって UML1.1 が標準仕様として採択された。2003年3月段階での最新版は UML1.5 であり、現在 2.0 の仕様策定が進んでいる。
モデリング言語として、OMGのお墨付きで登場したUMLは、ソフトウェア開発の救世主であるかのような受け入れ方をされ、多くのソフトウェア開発プロジェクトがUMLを採用した。OMGが進めているUML技術者の資格認定等も、その傾向に拍車をかけている。UMLを使わないプロジェクトは旧式開発とみなされ、逆にUMLを使えば開発効率は飛躍的に向上するという認識が多くなされている。
しかし、はじめに断っておくが、
UMLは描き方の基本を決めているだけ
である。
「どのようにして描くのか」や、「どのようにプログラムコードと関連付けるのか」については、何も決められていない。
したがって、UMLを使えば魔法のようにソフトウェアが作られるなどということは、決してない。
そして、この講義の目的も、UMLを修得することではない。
「工程管理されたソフトウェア開発方法」
を修得することこそ、本講義の目的である。そのためにオブジェクト指向分析と設計の技法について説明していくが、その一環としてUMLについても触れる。UML記法の背後にあるオブジェクト指向的な考え方を身につけることが重要である。
UMLは、大雑把に言うと以下の9種類の図である。
分析・設計の各段階において、これらの図をたくさん描くことで、問題を整理し、コード化へスムーズに移行することがUMLの目的である。
しかし、実際に9種類の図をすべて駆使して分析・設計を行わなくても、ソフトウェア開発は可能である。このページでは、上の9つの図の中で、特に重要な図であると考えられる以下の3つについて説明を行う。なお、ここでは各図の概要だけを述べ、具体的な例は実際問題に適用しつつ示すことにする。
ユースケース図(Use Case Diagram)は、システムがどのように機能するべきか（ユースケース）、およびその外部環境（アクター）を表す図である。システムを使用するエンドユーザーの視点からそのシステムを見ることができる。そのため、エンドユーザーや利用領域の専門家とコミュニケートして、要求に対する相互の理解を保障することが可能となる。
つまり、ユースケース図は、システムの外部と内部との境界をはっきりさせる図であるということができる。
UM-図1
上の図はユースケース図の例を示している。
ユースケース図には、「アクター」と呼ばれる部外者と、「ユースケース」と呼ばれるシステムの持つ機能が登場する。
アクター
- アクターはシステムの一部ではない。そのシステムを使用するユーザーが果たす役割を表す。
- システムと活発に情報交換したり、システムから受動的に情報を受け取ったりする。
- 人間だけでなく、ハードウェアや外部システムもアクターになりうる。
ユースケース
- アクターとシステムとの間の対話をモデル化する。
- ユースケースはアクターによって開始され、システムが持っている、ある機能を実行する。
- システムのユーザーがシステムを利用して遂行する単位業務のひとつを抽象化したもの。
- ユースケースをすべて集めると、システムがどう使われるかがすべて表される。
- ユースケースの視点で、分析モデル、設計モデル、実装モデル、テストモデルを関連付けて管理できる。
- ユースケースのドキュメントとして、「ユースケース記述（イベントフロー）」と「シナリオ」がある。
ユースケース記述（イベントフロー）
- 業務の流れを通常の言語（日本語など）を使って書いたもの。
- ユースケースがいつ、どのように開始・終了するかや、アクターとユースケースの相互作用について記述する。
- ユーザインターフェイスに関する記述はできるだけ避けた方が良い。ユーザインターフェイスは設計の段階にならないと具体的に決まらないし、変更が発生することも多いからである。
- 例外的な事項が発生する場合は、例外フローとしてメインフローとは別に記述する。
シナリオ
- ユースケースの実例を言葉で記述したもの。
- ユースケースを実行したときの具体的な流れを書く。
- 各ユースケースは、複数のシナリオの集合として表現される。
- 必要なクラスやオブジェクトを抽出するもとになる。
- 実例を通して、システムの動きを具体的に表現できる。
- シナリオには、次の2種類がある。
- 基本シナリオ・・・すべて問題なく動作する事例
- 2次シナリオ・・・基本シナリオに対する例外
シーケンス図 (Sequence Diagram) は、システムに登場するオブジェクト間の相互作用を時系列に沿って並べて表現した図である。シーケンス図を使用すると、ユースケースを実現するのに必要なオブジェクトの集合と、そのやりとりを明確に表現できる。オブジェクト間でやり取りされるメッセージを時間順にひとつずつ記述できるため、シナリオと対応させて具体的な内容を示すのに便利である。
UM-図2
上の図はシーケンス図の例を示している。
シーケンス図には、上部に「オブジェクト」を持つ「タイムライン」と呼ばれる縦線と、その上に縦長の長方形で表された「アクティベーション」、さらにアクティベーション間の「メッセージ」によって構成される。
オブジェクト
- シナリオの中に現れた、システムに登場するもの。アクターもオブジェクトになりうる。
- どれをオブジェクトとして採用するかは、分析者の手腕によるが、一般には文中に現れる名詞に着目すると良い。
- システムと無関係な名詞は、オブジェクトではない。
タイムライン
- 時間の経過を表す。
- オブジェクトはタイムライン上で常に存在しているわけではない。
アクティベーション
- オブジェクトが生存している期間を表す。
- オブジェクトは、生成され、活動し、必要がなくなれば破棄される。
メッセージ
- オブジェクト間のやりとりを表す。
- オブジェクト間の相互作用は、クライアントオブジェクト（メッセージを出すオブジェクト）から、サプライアオブジェクト（メッセージを受けるオブジェクト）への水平な矢印として表される。
- 順序は、縦軸上の位置として示される。
メッセージには同期型と非同期型とがある。通常の場合、送信されるメッセージは同期型である場合が多い。同期型メッセージは、呼び出されたオブジェクトでの処理が終わると必ず元のオブジェクトに復帰する。このとき特にメッセージを返さない場合は、復帰メッセージの矢印は省略できる。
同期メッセージは、プログラム言語における手続き呼び出しを表現するのに用いられる。
クラス図 (Class Diagram) は、対象領域やシステムの静的な構造を表す図であり、「クラス」と「クラス間の静的な関係 (Relationship)」を図に表現したものである。
クラス図は分析段階でも設計段階でも利用されるが、分析段階のクラス図は利用者の立場に立って問題領域を表すように書かれる。一方、開発段階におけるクラス図は開発者の視点から、より詳細化された形で書かれる。
UM-図3
上の図はクラス図の例を示している。
クラス図は、長方形の中に名前や属性、操作等を書き込んだ「クラス」と、クラス間をつなぐ「関係」によって構成される。関係にはさらに「関連」、「集約」、「汎化」など、いくつかの種類がある。また、設計段階になると、関係の両端に「ロール」や「多重度」を書き入れる場合もある。
クラス (Class)
- 類似のデータの構造（属性）と振る舞い（操作）を持つオブジェクトの集合。
- 「属性」とは、そのクラスに属するオブジェクトが共通に持つデータ構造のこと。
- 「操作」とは、そのクラスに属するオブジェクトが共通に行うことができる振る舞いのこと。
- 属性は、そのクラスに属する特定のオブジェクト毎に固有の「属性値」を持つ。
- 「操作」は、他のオブジェクトからの要求によって起動するこのができるサービスである。
- クラス図において、クラスは以下のように段階的に詳細化して記述できる。
UM-図4
- 詳細形においては、属性や操作の「可視性」、「型」、「返却値」などの情報も記入する。
- クラス名の上に、「ステレオタイプ」と呼ばれるクラスの種類を書く場合もある。
- クラスには、そのクラスのインスタンス（オブジェクト）を生成できる「具象クラス」と、生成できない「抽象クラス」とに分けることができる。一般に、単に「クラス」と言った場合は具象クラスを指す。
抽象クラス (Abstract Class)
- 抽象クラスは、クラス名を斜体にして表現する。
- 抽象クラスが持つ抽象操作も、操作名を斜体にして表現する。
- 抽象操作だけをまとめたものは「インターフェイス」と呼ばれる。
UM-図5
インターフェイス (Interface)
- 操作だけをまとめたもの。
- インターフェイス名の上に <<interface>> というステレオタイプを書く。
- 属性はないので、書かないか、または省略してよい。
- 簡略形の別形式として、○に線をつけて表現しても良い。
UM-図6
- クラス間のつながり具合や依存性を表す。
- 「関連」、「汎化」、「実現」、「依存」の4種類があり、さらに関連は「集約」と「合成」からなる。
UM-図7
- 上の図は、クラスの関係をクラス図を使って描いたものである。白抜きの矢印は「汎化」を表す。上の図は、「関連」、「汎化」、「実現」、「依存」というのは、4つとも「関係」の一種である、ということを表している。さらに、「集約」は「関連」の一種であり、「合成」は「集約」一種である。ということは当然、「合成」は「関係」の一種でもある。
関連 (Association)
- 一般的に、クラス間に意味的な関係があることを表す。
- 何もつけない実線で表す。
UM-図8
- さらに、線にさまざまな装飾を施すことで、いろいろな情報を付加させることもできる。
UM-図9
「多重度」は、あるクラスの1つのインスタンスが、もう一方のクラスのいくつのインスタンスと関連するかを表す数。上の図では、クラス2のインスタンスははクラス1の1つだけのインスタンスと関連があるが、クラス1のインスタンスは0個以上の複数のクラス2のインスタンスと関連がある。たとえば、「名簿」クラスと「学生」クラスとは関連があり、1つの名簿には複数の学生が載っているような場合は、このような関連になる。
「ナビゲービリティ」とは関連の方向性のことで、線の端に矢印をつけて表す。上の図の場合、クラス1からクラス2への関連はあるが、逆の関連はないことを意味する。これは、「名簿」はどの学生が載っているかを記憶しているが、「学生」は自分がどの名簿に載っているかは知らない、といった状況を表す。
「ロール」とは、その関連の上でクラスが果たしている役割、立場、能力などを表す。たとえば、「会社」クラスと「社員」クラスの関連の場合、会社のロールは「雇用者」であり、社員のロールは「被雇用者」となる。ロールは必須ではなく、モデルに意味を付加する場合にのみ使用すればよい。
「関連クラス」とは、その関連を実現するために別なクラスを使用している場合に書く。たとえば、「会社」クラスに「社員」クラスのインスタンスがたくさんいる場合、それらは「リスト」クラスを使って覚えられていることがあるかもしれない。そのような場合、関連クラスは「リスト」クラスとなる。この関連クラスは、設計段階で詳細なクラスを書く場合に、必要に応じて書き込まれる。
集約 (Aggregation)
「関連」の一種。
has-a の関係。
白抜きのひし形をつけた実線によって表す。
一方が他方によって構成されている、という関連を表す。
ただし、その関連は強いものではなく、ばらばらでも存在できるような程度である。
UM-図10
合成 (Composition)
「集約」の一種。
has-a の関係。
塗りつぶされたひし形をつけた実線によって表す。
一方が他方によって構成されている、という関連を表す。
ただし、その関連は非常に強く、切っても切れないような関連である。
UM-図11
汎化 (Generalization)
一方のクラスが、他方のクラスの表している概念をより一般化した概念であることを表す。
is-a の関係。
白抜きの三角形をつけた実線によって表す。
汎化の逆は「特化 (Specialization)」と言われる。
汎化は、集合によって表すことができる。
汎化が進むにつれて集合が大きくなっていく。特化が進むと集合は小さく限定されていく。
汎化が進むにつれて仕様は単純化していく。特化が進むと仕様は複雑化していく。
UM-図12
実現 (Realization)
インターフェイスを具体的に実現したことを表す関係。
白抜きの三角形をつけた破線によって表す。
抽象度の高いモデル（分析モデルなど）から具体的なモデル（設計モデルなど）を実現したという関係。
UM-図13
依存 (Dependency)
一方のクラスの変更が、もう一方のクラスに影響を及ぼす関係。
クラスとクラスの間に発生する動的（一時的）な関係。
点線の矢印によって表す。
UM-図14
UML の9つの図のうち、よく使われる3つに限っておおまかな説明を行った。
わずか3つの図についてでさえ、きわめて複雑な規則が定められていることが分かると思う。
UML は基本的に図を描くことでモデルを記述していくグラフィカル言語であるから、その文法に当たるものは図の描き方であり、形である。したがって、ある程度細かく記述方式が定められているのは仕方がない。
しかし、それにしても、ここに示された決まりを厳格に守って図を描いていくことは容易ではないと、誰もが思うだろう。しかも、UML は図の形は規定していても、具体的な描き方までは示していない。つまり、与えられた問題をUML の9つの図の形にしていく方法については、ほとんど何も決められていないのである。
したがって、UML を使ってソフトウェア開発を行おうとすると、まずはたくさんの例題を参考にして、試行錯誤で図を作っていき、それを繰り返すことでノウハウを蓄積するしかない。UML では標準的な記述の形が決まっているだけでも、参考にする多くの例題が利用できるので「まし」だと思う。
UML を利用したソフトウェア開発で最も重要な点は、オブジェクト指向による分析と設計を行うという点である。図を正確に描くことにこだわって、この点を忘れてしまっては本末転倒だが、逆に言うと、オブジェクト指向的分析と設計ができるなら、図の正確性は多少犠牲にしてもかまわないということでもある。
大規模プロジェクトに携わるのなら仕様書としての図にこだわる必要がある。記法の統一されたUMLに準拠して書く必要もあろう。が、この授業ではあまり正確性にはこだわらないで行く。背後のオブジェクト指向的な開発方法を身につけてほしい。
| 前へ （オブジェクト指向モデル） |
TOP （ソフトウェア工学） |