要素間の関係を明らかにしよう！
4. クラス図による表現
オブジェクトの関係が整理できたので、次にクラス図を作成します。クラス図は、オブジェクト図を抽象化して、クラス間の恒常的な関係を表しています。
また、設計段階のモデルは、プログラミング言語で実装できるように、英語で表わすのが一般的です。そこで、本記事でも、モデルの情報を英語で記述することにします。
- 飲料水の商品スペック（DrinkSpec）
- 商品名（name）
- 内容量（contentWeight）
- 値段（price）
- 飲料水の在庫商品（StockedDrink）
- 賞味期限（best before）
図4は、UMLのクラス図です。図3の例は、DrinkSpecクラスとStockedDrinkクラスの静的な関係を表しています。
|
|
| 図4: 飲料水の商品スペックと在庫商品のクラス図 |
DrinkSpecとStockedDrinkの間に引かれている線を関連線と呼び、クラス間の恒常的な関係を表しています。図3では、StockedDrinkからDrinkSpecの方向へ矢が向いています。これは、StockedDrinkがDrinkSpecを恒常的に参照していることを表しています。プログラミング言語では、この関係を属性として表現できます。
関連線の両端には、数字で表現した"多重度"と、文字で表現した"関連端名"が記述されています。多重度と関連端名によって、関連におけるクラス間の数的関係や役割を表しています。
今回は、多重度、つまり数的関係について見てみましょう。多重度というのは、「自分のインスタンスが1つある場合、相手のインスタンスはいくつあり得るか」という視点で、その範囲を相手側の関連端に記述するものです。
DrinkSpec側に「1」、StockedDrink側に「0..*」と書かれています。これは「DrinkSpecのインスタンスが1つあるとき、対応するStockedDrinkが0以上（0..*）存在する」ことを表しています。つまり「在庫が無くてもよい」ということを表しています。
一方、StockedDrinkから見れば、「StockedDrinkのインスタンスが1つある場合は、対応するDrinkSpecが必ず1つある」ことを表しています。つまり「商品スペックが無い在庫商品は存在しない」ことを表しています。
こうして、オブジェクトの関係（図2）をもとに、クラスの関係（図3）として表すことができました（UMLのクラス図とオブジェクト図を用いて、商品スペックと在庫商品の要素間の関係を表すことができました）。
商品スペックと在庫商品の関係をほかの人に伝達する場合は、クラス図だけではなくオブジェクト図も一緒に用いるとよいでしょう。多角的な説明をすることができるため、コミュニケーションが円滑に進みます。
一般に、設計段階で作成するモデルは、そのままプログラミング言語で実装できるだけの詳細度で作成します。しかし、今回は図の理解を容易にするため、属性の型や操作は省いています。設計書としての厳密性には欠けますが、コミュニケーションを円滑にするという目的においては、これで十分です。
5. まとめ
今回は、要素間の静的な関係に限って解説しました。この方法以外に、シーケンス図やステートマシン図を用いることで、動的な関係を表すことも可能です。
いずれにせよ、クラスやオブジェクトといった要素間の関係を整理して明確に示すことが、誤解のないコミュニケーションを実現するためには重要です。このような情報は、文書や口頭だけで伝えることが困難だからです。
今回紹介したのは、Ralph Johnsonが考案したType Object Pattern*2と呼ぶデザイン・パターンの1つです。デザイン・パターンといえば「GoF」（Gang of Four）の23パターン*3が有名ですが、実はこれ以外にも多くのデザイン・パターンが存在します。デザイン・パターンを理解する際も、自分でUMLモデルを作成しながら学習すると、理解が深まります。
- [*2] Peter CoadのItem Descriptor Patterも同じパターンです。
- [*3] 書籍『Design Patterns: Elements of Reusable Object-Oriented Software』のこと。オブジェクト指向設計でよくある問題とその解決策を、Erich Gamma、Richard Helm、Ralph Johnson、John M. Vlissidesの4人が、パターン・カタログとしてまとめています。著者の4人はGang of Fourと呼ばれ、この書籍は一般的に「GoF本」などと呼ばれています。
