ITmedia エンタープライズ

特集
2004/03/05 16:00 更新

全2回「UML入門」
特集：前編　モデリング言語「UML」を学ぼう (2/2)

UMLのダイアグラム−各ダイアグラム間の関係

　個々のダイアグラムの特徴が分かったところで、次は各ダイアグラム間の関係を前述の図に絞って見てみましょう（図6）。まずはクラス図とオブジェクト図の関係です。

　クラスを抽出し、クラス図を作成する作業には「抽象化」という技術が伴います。いきなり「クラス図を描け」、といわれて困った場合には、まず最初に現実世界に近いオブジェクトの図を描き、それを抽象化してクラス図にすると割と容易に取り組めることがあります。

　また、クラス間を結ぶ関連には、「多重度」というオブジェクト2者間で1つのインスタンスに対し、相手のインスタンスがいくつ結びつくかを表す記号を定義します。その多重度の検討や検証にもオブジェクト図が役立ちます（図6-1）。次にクラス図とシーケンス図の関係です。

　シーケンス図には、クラスのインスタンス（オブジェクト）を配置し、それらの間でメッセージをやりとり（＝会話）します。そのメッセージは、クラスで定義してある操作にひもづけられます（図6-2）。クラスに対し、会話に使うすべてのセリフ（＝操作）をあらかじめ用意しきれていればよいのですが、シーケンス図上で会話のやりとりを描いていると、あるべきセリフが足らないことに気づくことがあります。そこでセリフを作る、つまり操作を作っていくことにより、クラスの情報がどんどん補完されていくのです。そしてユースケース図とそのほかの図の関係です。

　前述の通り、ユースケースの詳細は自然言語で記述します。モデリングの手法として、その文章の中に出てくる名詞と動詞に着目し、クラス図やオブジェクト図、シーケンス図などの構成要素を洗い出す手法がよく使われます。文章の中の名詞はオブジェクト候補、クラス候補、クラスの属性候補となり、動詞はクラスの操作候補およびシーケンス図のメッセージ候補となります。

　ユースケースドキュメントの形式はUMLで定義されていませんが、たいていはシステムの振る舞いを時系列に記述していきます。このドキュメントを図式化したものは、シーケンス図となります。

Column 1■UMLに登場するダイアグラム 　本文の中で、UMLのダイアグラムは約10種類、と書きました。その数はUMLのバージョンや数え方、解釈によって異なります。UMLのバージョンにより図の数が異なるのは分かるのですが、同じバージョンを扱う解説書でも、見比べてみると数え方や扱いがそれぞれ異なっていることに気づくでしょう。 　たとえば「パッケージ図」は、その名のとおりパッケージ間の関係を表す図で、UML1.x 仕様書には定義されていませんが、実際には良く使われるため、図の一覧に記載することがあります。また、シーケンス図やコミュニケーション図などはまとめて「相互作用図」とすることがあります。こういったことが、図の数え方などの異なる原因となっているようです。 　また、UML1.x の仕様書には以下のような記述があります。「…クラス図には、インタフェース、パッケージ、関係、オブジェクト、リンクといったクラス以外の要素も含まれることがあるため、「静的構造図」などと呼ぶほうが名前としては適当かもしれない。しかしながら、「クラス図」のほうが簡潔であるし一般にも普及しているため、便宜的に「クラス図」と呼ぶことにした」。 　「…クラス図に、オブジェクトを配置したものをオブジェクト図と呼ぶ…」。UML仕様書を読む際、この辺りの記述は混乱しやすいので、注意が必要です。

UMLの導入効果−開発現場の現状

　ソフトウェア開発の現場において、分析設計工程のドキュメントはさまざまな記述方法で作成されます。各社オリジナルのフォーマット（ドキュメントの形式だけでなく、そこで使う図形の型なども含む）を作り、それに従って作成していくことが多いと思います。このフォーマットが、全社的に共通ならまだよいですが、場合によってはプロジェクトごと、さらにはそのときどきによって異なることもあるでしょう。

　また、成果物として何を作るか、というところから検討が必要な場合があります。UMLの表記は、世界的に標準であるため、案件ごとにバラバラな表記になることがありません。そして、UMLのダイアグラムは10数種類と多いものの、その中から必要なものだけ選べばよいので、何を成果物とするか、といった検討作業も楽になります。

UMLモデリングツールの導入メリット−UMLのメリット

　UMLを使わず、自然言語中心で書かれたドキュメントでも、文章を補う形で図が添えられることがあるかと思います。人に何かを伝える場合、図解することで理解が深まり、お互いの誤解を減らすことができます。ソフトウェアの開発作業の中では、ユーザの要求を的確に整理し、開発者同士が理解し合い、誤解を減らすことが重要です。UMLを使うことで、それが可能となるのです。

UMLモデリングツールの導入メリット−手描きとの比較

　UMLは紙とエンピツ、ホワイトボードなどがあればすぐに使い始めることができます。2、3人が集まってモデリングする場合はまず紙などに描き、必要であれば後でそれをコピーして配布したり、電子化したければデジカメで撮る、といった方法もあります。言うまでもないことですが、UMLは、それ専用のツール（ソフトウェア）がないと使い始めることができない、というわけではありません。ツールがなくてもUMLの導入効果は十分得られるのです。

　ただ、こうした手描きだと描き直しが面倒だったり、見づらいこともあるため、初めは必要なくても最終的には何らかのソフトウェアが使われることが多いようです。UMLに対応したモデリングツールの多くは、アクターやクラスといった各アイコンがあらかじめ用意されており、それらを図上に配置していけばよいので作業も効率的です。また、例えばユースケース図でいえば、関連の線がアクターやユースケースの位置に連動して動くツールもあり、この場合は配置換えも簡単に行えます。クラス図でいえば、クラス名や属性名などの文字列の長さと、クラスの枠の大きさが連動しているツールも多くあります。手描きや自作のアイコンではなかなかこういうわけにはいきません。さらに、UMLの文法チェックをしてくれるツールもあり、文法的に間違った図を描こうとするとツールが警告メッセージを出してくれるので、UML初心者のナビゲーター役としても活躍します。

　さて、以下に例としてオージス総研が販売しているモデリングツール「Konesa」を使用して描いた図を載せました（図9〜11）。見やすさや描き直しの手間をイメージしながら、手描きの図（図7、8）と見比べてみてください（Konesaの詳細）。

後編ではコードマッピングやツールを用いて解説

　以上、今回はUMLの概要、各ダイアグラムの紹介、モデリングツールの導入メリットなど解説しました。UMLがどのようなものか、概要が理解できたかと思います。さて、後編ではUMLとJavaコードのマッピング、そしてモデリングツールとIDE連携など、より具体的で、開発作業に身近な話題を取りあげる予定です。お楽しみに。

関連リンク
Konesa｜オージス総研
Java チャンネル

前のページ | 1 2 | 　　　　　

[蒔田修一，ITmedia]

Copyright © ITmedia, Inc. All Rights Reserved.