パッケージ間の関係

＜＜パッケージへの分割＞＞

◆クラス図における、パッケージの役割

モデルの構成の表現のひとつで、クラス図に包含される。
クラスは、論理的にグループ化される。

◆パッケージを表した図

これまでにいろいろなクラスが出てきたから、モデルを整理してまとめるという意味で、クラスをパッケージに分割しよう。

今回のモデルでは、どういう単位でパッケージを考えればいいのでしょうか？

最初は、クラスのステレオタイプによってパッケージの分割を考えるといいよ。

なるほど。エンティティクラスのパッケージ、コントロールクラスのパッケージ、バウンダリクラスのパッケージという具合ですか？

そうだよ。それぞれ、「ドメイン」、「コントローラ」、「インターフェース」というパッケージ名を付ければいいだろう。ただ、バウンダリクラスの「注文登録画面」クラスと「顧客情報管理システムIF」クラスは、インターフェースといっても、画面に関するものと外部システムへのアクセスに関するもので少し意味合いが違うよね。だから、「画面インターフェース」と「外部インターフェース」の２つのパッケージに分割してもいいだろう。

■「ドメイン」パッケージに含まれるクラス

顧客、注文、注文商品、商品、配送センター、配送、在庫

■「コントローラ」パッケージに含まれるクラス

注文登録コントローラ

■ 「外部インターフェース」パッケージに含まれるクラス

顧客情報管理システムIF

パッケージ間にはどんな関係があるのですか？

パッケージは、依存関係によってお互いに関係してるんだよ。あるパッケージのクラスが別のパッケージのクラスとやり取りをしている場合、パッケージレベルでの依存関係が追加されるんだよ。（図2.5.1）

　

図2.5.1　パッケージの関係 (1)

なるほど。では、シーケンス図とクラス図を検討して、パッケージ間の依存関係を決定すればいいのですね。Jun先輩、メッセージが両方向に送られていれば、パッケージ間の依存関係も双方向になるのですか？

そうだよ。でも、できればパッケージ間の依存関係は双方向にならないようにするのが望ましいんだ。

2_1_3

依存関係が双方向になっている場合はどうすればいいのですか？

図2.5.1の下図のようにパッケージ間で依存関係が巡回している場合はパッケージ間の結びつきが強いということだから、本質的にはひとつのパッケージでいいことになるよね。

そうですね。

逆に、パッケージを２つに分割することで解決できる場合も多いよ。図2.5.2を見てみよう。「C」クラスは「Ｂ」クラスと同じ「Q」パッケージに含めているけれど、パッケージ内で他のクラスとの関係は少ないから、別のパッケージに分割すればいいよね。

	Jun先輩、設計が進むにつれて、パッケージやその中のクラスを再構成する必要が出てくるのですね。
	そうだよ。また、パッケージを再構成していく際には、再利用についても考える必要があるんだよ。再利用性を考えると、再利用可能なパッケージは独立している方がいいんだ。他のパッケージを参照したり依存したりしていると、その部分が変更されたときに影響を受けてしまうからね。それに、論理パッケージ間の依存関係では、クライアントパッケージはサプライアパッケージに依存するから、クライアントパッケージだけで独立して再利用することはできないんだよ。
	はい。

【チュートリアル】 - 設計編