UML 2 パッケージ図の概要

パッケージとは、モデル要素をグループに整理し、図を単純に読みやすくするためのUMLの要素です。パッケージはファイルフォルダの形で表します。これはUMLのどの図においても使うことができますが、よく見かけられるのはユースケース図とクラス図です。この2つのモデルは大きくなる傾向があるからです。

パッケージ図はどの種類のUML分類子を整理するのにも使うことができますが、私がパッケージ図を作成するのは、たいてい、クラスかデータエンティティかユースケースを整理するためです。この3種類の要素に関するパッケージ図は、私にとって実質的なビジネスアーキテクチャ図となっています。

クラスパッケージ図

「クラスパッケージ図」に関しては、私はいくつかの経験則を適用します。第1に、同じ継承（汎化）階層のクラスは、通常同じパッケージに属します。第2に、コンポジションによって結び付いているクラスは、たいてい同じパッケージに属します。第3に、互いにコラボレーションを多く行うクラス(この情報はシーケンス図やコミュニケーション図に反映されています)は、たいてい同じパッケージに属します。図1に示すのは、大学システムの初期のクラスパッケージ図です。いくつかのパッケージとその間の依存関係が書かれています。「接点」パッケージのタブが左側ではなく右側に付いています。これについてはAMの「見栄えより中身」の原則を思い出してください。

図1 大学のクラスモデルを整理したパッケージ図

図1にはUMLのステレオタイプがいくつか付けられています。「ゼミ登録」パッケージには<<application>>のステレオタイプが付いていて、学生をゼミに登録するためのユーザインターフェース(UI)クラスやアプリケーション固有のビジネスクラスが含まれていることが分かります。同じように「Javaインフラ」パッケージには<<technical>>というステレオタイプが付いていて、技術的なクラスが含まれていることが分かります。おそらく「Apache Struts」のようなユーザインターフェースフレームワークや「Prevayler」のような永続化フレームワークなのでしょう。<<application>>と<<technical>>のいずれのステレオタイプも私が習慣として使っているものですが、他の人にも一般的に使われています。いくつかの依存関係に付けられた<<import>>というステレオタイプはUML標準のもので、「Javaインフラストラクチャ」パッケージがこの図の他のパッケージにインポートされていることを示しています。

図1に含まれる各パッケージには、それぞれパッケージの内部を示す詳細な図が存在します。非常に複雑なシステムの場合には別のパッケージ図かもしれませんし、たいていはUMLクラス図です。図2に示すのは、「スケジュール」パッケージの内容を表すためのUML枠 (frame) で、この場合は大雑把な概念クラス図になっています。枠を使うと、パッケージ、コンポーネント、クラス、操作など、任意の種類のUMLモデルの内容を詳細に示すことができます。タイトルは、右下隅を切り落とした長方形のネームタグの中に、「[<種類>]名前[<パラメータ>]」という書式で記述します。コンポーネント (Componenet) を表す枠なら、タイトルは「Component スケジュール」のようになりますし、操作 (Operation) の枠なら「Operation EnrollStudent(Student)」のようになるでしょう

図2 「スケジュール」パッケージの内容

データパッケージ図

UMLではデータをモデリングすることかできるので、「データモデルパッケージ図」があっても不思議ではありません。この場合、パッケージを使って、データエンティティを大規模なビジネスドメインに整理します。図1から「ゼミ登録」と「Javaインフラ」を消すと、そのような図になるでしょう。唯一の違いは、パッケージにつながっているのがUMLクラス図ではなくUMLデータモデルだということです。

ユースケースパッケージ図

図3は、ユースケースをパッケージに整理したUMLユースケース図です(図にはまだアクターが書かれていますが、これもパッケージ内に移動することが可能です)。これは今でもまだユースケース図なのでしょうか。それとも本当はUMLパッケージ図なのでしょうか。重要なのは図が作業に役立つということであって、図を何に分類するかは実際にはほとんど重要でありません。

私がユースケースパッケージ図を作成するときには、2つの経験則に従います。第1に、包含ユースケースや拡張ユースケースは、基底/親ユースケースと同じパッケージに含めます。この方法がうまくいくのは、たいていこれらのユースケースが、そもそも基底/親ユースケースからロジックを取り出して作られたものだからです。その後2番目に、主要アクターが関係しているユースケースについて分析します。たいてい各アクターは、少数の主要な目的を達成するためにシステムと相互作用しています。たとえば、学生が大学と相互作用するのは、登録するため、スケジュールを管理するため、授業料を支払うため、そして貸付と補助金を管理するため、です。この4種類の目的はそれぞれかなり凝集性が高いため、4つのパッケージが必要なことが分かります。

図3 ユースケースパッケージ図

パッケージ作成戦略

図3で興味深いのは、私がパッケージを使う理由が典型的に現れている点です。つまり、大きな図を複数の小さな図に整理するためです。経験から言えることですが、図に含めるモノ(ユースケースでもクラスでも)の数は7±2にするべきです。それ以上のモノを含めると、図は扱いにくくなり、結果として理解しにくくなってしまいます。

パッケージは凝集性が高くなければなりません。パッケージに入れるものはどれも、パッケージ内の他のものと考え合わせたときに意味を持っていなければなりません。パッケージの凝集性を判断するには、パッケージに意味の分かりやすい短い名前を付けられるかどうかを考えてみてください。付けられなければ、1つのパッケージに複数の関係のないものを入れている可能性があります。

アジャイルさを保つ

私はUMLパッケージ図を独立して作ることはほとんどありませんが、図にパッケージを追加することはあります(特にCASEツールを使っている場合)。私は、パッケージ図でコード全体の大雑把な構成を表しているJava開発チームのことを聞いたことがあります。Javaはもともとクラスのパッケージをサポートしていますが、Java開発環境でコードを調べやすくなる以上にどのような意味があるのか、私には分かりません。実際私は、UMLコンポーネント図のような物理ダイアグラムの方がずっと役に立つと思っています。

私がアドバイスをするとしたら、作成する価値のあるときにだけパッケージ図を作成すること、その場合にはできるだけシンプルにしておくこと、です。

注: この成果物の説明は『The Object Primer 3rd Edition: Agile Modeling Driven Development with UML 2』より抜粋しました。本ではより詳しく説明しています。

推奨文献

Package Diagram Style Guidelines

その他の文献

アジャイルモデリング(AM)について詳しく知るにはこの本をお薦めします。

Let Us Help　(以下、北米での話ですのでご注意ください）

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.