UML 2 コミュニケーション図の概要
by Scott
W. Ambler, Copyright 2003
統一モデリング言語(Unified Modeling Language: UML)の基本となる考え方は、目的が違えば違うダイアグラムを使うということです。クラス図を使ってシステムの静的な姿をモデリングし、シーケンス図を使って逐次的なロジックをモデリングし、状態マシン図 (state machine diagrams) を使って複雑なクラスの振る舞いをモデリングします。しかし、協調して共通の目的を達成する複数のオブジェクトの振る舞いを表したいときにはどうすればよいでしょうか。そのためにはUMLコミュニケーション図を使うことができます。これはUML1.xでコラボレーション図と呼ばれていたもので、この図によって協調するオブジェクト群を概観することができます。
コミュニケーション図では、オブジェクト指向アプリケーションのオブジェクト間のメッセージフローを表し、同時にクラス間に基本となる関連(関係)が存在することを暗黙的に示します。図1は、ゼミ詳細の画面またはページを表示するための簡単なコミュニケーション図です。四角形は、アプリケーションを構成していてこの仕事にかかわるさまざまなオブジェクトを表します。クラス間の直線はクラス間の関係(関連、コンポジション、依存、または継承)を表します。UMLシーケンス図で使ったものと同じクラスおよびオブジェクトの表記法がコミュニケーション図でも使われていて、UMLの一貫性を示しています。多重度などの関連の詳細はクラス図に含まれているため、ここにはモデリングしません。UMLのダイアグラムはそれぞれに独自の目的を持っていて、どの図もそれ1つだけでは十分でないことを忘れないでください。メッセージはラベルの付いた矢印として記述し、矢じりでメッセージの向きを表します。この表記法はシーケンス図で使ったものと似ています。
図1 コミュニケーション図の例
★
Seminar Details:ゼミの詳細
Name:名前
Description:説明
Location:場所
SeatsLeft:定員の空き
StudentList:学生一覧
Seminar:ゼミ
Number:番号
Info:情報
Enrollment:登録
Student:学生
FullName:氏名
★
図2には、コミュニケーション図でメッセージをモデリングするときの基本的な表記法をまとめてあります。メッセージが送られるシーケンス番号(オプション)、返り値(オプション)、メソッド名と(あれば)渡されるパラメータを示すことができます。シーケンス番号はA.B.C.Dという形式で、メッセージが送られる順番を表します。図1では、Seminarオブジェクトにメッセージ1が送られ、Seminarオブジェクトはそれを受けてメッセージ1.1および1.2をCourseオブジェクトに送ります。Seminarオブジェクトにメッセージ5が送られると、Seminarオブジェクトはenrollmentオブジェクトにメッセージ5.1を送り、enrollmentオブジェクトはstudentオブジェクトにメッセージ5.1.1を送り、最後にstudentオブジェクトは自分自身にメッセージ5.1.1.1を送ります。このためにはstudentオブジェクトに再帰的接続(あるいは自己接続)が必要なことに注意してください。
図1ではメッセージにシーケンス番号を付けていますが、私の経験では、コミュニケーション図にシーケンス番号をつける必要があると感じたときには、コミュニケーション図ではなくシーケンス図を使った方がいい場合が多いようです。コミュニケーション図とシーケンス図の主な違いは、シーケンス図は逐次的なロジックを表すのが得意だけれども、全体像を見渡すのには向いていないことです。コミュニケーション図はまったくそれとは反対です。
図2 メッセージの表記法
|
[シーケンス番号:] メソッド名(パラメータ) [: 返り値] |
図1では、Seminar Detailsユーザインターフェースオブジェクトがゼミオブジェクトと協調して、画面に表示するのに必要な情報を取得します。まずゼミの名前を取得するためにgetメソッドを呼び出します。ゼミオブジェクトは、この責務を果たすために、名前を持っているコースオブジェクトと協調してコースの名前を取得します。この例ではいくつかのメッセージに返り値を付けて書き方の例を示していますが、付けていないものもあります。返り値には、型(たとえばstringなど)を示すこともあれば、結果(seminarNameなど)を示すこともあります。通常、私はこの図に返り値を書くことはありません。メッセージの名前から分かるからです。私が見つけ出した方法は、メッセージが何を返すかが明確でないときだけ返り値をモデリングするということです。返り値を書くよりも、メッセージの名前を見直した方がよいでしょう(メッセージはクラスで実装する操作に対応することを思い出してください)。
その他に私がよくごまかすのは、getメソッドの呼び出しなどの小さなメッセージをまとめることです。図1では、ゼミに登録されている学生の一覧を表示するのに必要な情報を取得するためのgetメソッドの一連の呼び出しを、getInfoという1つのメッセージにモデリングしています。この図ではノートをつけてそのことを明示していますが、通常はそのようなノートは付けません。これはなぜ重要なのでしょうか。アジャイルな開発では価値のあることだけをするべきであり、getメソッドの呼び出しを厳密に定義してもおそらく価値はないからです。
コミュニケーション図は、シーケンス図と同じように書くことができます。実際に異なっているのは要素のレイアウトだけです。主要な要求成果物としてユースケースを作成していない状況ではコミュニケーション図は有効ですが、正直なところ、私がこの図を作る必要を感じることはほとんどありません。シーケンス図とユースケースはたいてい一緒に作られるようですが、これはユースケースの逐次的なロジックをシーケンス図でモデリングするのが非常に簡単だからです。コミュニケーション図は「構造化好き」の人、つまりUMLクラス図やCRC(Class Responsibility Collaborator)カードを主に作成する人に人気があるようです。これらの成果物とコミュニケーション図が似ているからです。いつも言うことですが、AMの「適切な成果物を使おう」のプラクティスに従って、状況にもっとも合った技法を使ってください。
注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。
アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。 
Ronin
International, Inc. continues to help numerous
organizations to learn about and hopefully adopt agile
techniques and philosophies. We offer both
consulting and
training offerings. In addition we
host several sites - Agile
Modeling, Agile
Database Techniques, UML
Modeling Style Guidelines, Enterprise
Unified Process (EUP) - that you may find of value. You
might find several of my books to be of interest,
including
The Object Primer, Agile
Modeling, The
Elements of UML Style, and Agile
Database Techniques. For more information please
contact Michael Vizdos at 866-AT-RONIN (U.S. number) or via e-mail (michael.vizdos@ronin-intl.com).
visits since June 8, 2004.
|
