オブジェクト指向でシステムをとらえると、システム化の対象となるものをオブジェクトとし、それには「データ」と「振る舞い」があると考えます。
たとえば、図書館の書籍というオブジェクトには、著作者や出版社といったデータと、貸出中と返却済と振る舞いがあるとします。書籍は一冊ずつに著作者が存在し出版社が決まっています。
システムとして考えるには、それらの情報を一つずつ個別に管理するのではなく、共通化した方が合理的といえますが、その共通化した情報をクラスとして定義します。
ＵＭＬのクラス図では、「データ」のことを「属性」と呼び、「振る舞い」のことは「操作」と呼んでいます。
ここで、「コンピュータ入門」という書籍があると考えてみた時、この書籍の著作者は「木村太郎」で「Ａ出版」から発行され、現在は貸出中と想定します。また、「プログラミング初級」という書籍があり、こちらは著作者が「田中一郎」で「Ｚ書房」から出版され、さきほど返却されたとしておきます。
これは、書籍というクラスがあり、その実体として「コンピュータ入門」という本が、「貸出」という操作により、図書館の書架から無くなっている状態となり、また、同じように実体としての「プログラミング初級」という本が、「返却」という操作により、図書館の書架に戻り存在している状態を表します。
オブジェクト指向では、クラスから生成される実体のことを「インスタンス」と名付けています。
システム的な考え方をすると、クラスごとに操作を実現させるためのプログラミングを用意しておき、クラスから生成されたインスタンス(オブジェクト)の状態を変化させるには、実現したい操作ごとに用意されたプログラムをインスタンス(オブジェクト)に対して実行する、ということになります。
これを上記の書籍を例に、クラス図で表現すると次のようになります。
クラスは、四角形で表現し、まず「クラス名」を記述します。
その下に横線を引いて「属性」を記述し、また横線を引いてから「操作」を記述します。
クラスのよっては、「属性」が無い場合や「操作」が無い場合がありますが、その時は省略します。
クラスの関係性
複数のクラスが関連しあってシステムは構成されます。
ここでは、「乗用車」「タクシー」「バス」「トラック」といったクラスで考えてみることとします。
汎化と継承
ここに並べたクラスは、車の種類(バリエーション)となっています。「乗用車」「タクシー」「バス」「トラック」をまとめたものとして、「車」というクラスを用意することができそうです。
このように、共通するような性質や規則性を抽出してまとめて一般化(普遍化)することを汎化といいます。そして、汎化により導き出されたクラスのことをスーパークラスとか親クラスなどと呼んでいます。
それに対し、スーパークラスを導き出したクラスの方をサブクラスとか子クラスまたは派生クラスと呼び、汎化に対しては特化といい、このような関係性を汎化特化関係と名付けています。
この「車」というスーパークラスは、「タクシー」とか「トラック」といった具体性のあるものではなく、共通的な概念として作成されたものになるので、抽象クラスともいわれ、クラス図で表現する際にはクラス名を斜文字にすることで区別をしています。
クラス図上での汎化特化関係は、サブクラスからスーパークラスに対し、白抜き三角形の矢印線を引くこととしています。矢印線は、サブクラスからスーパークラスにそれぞれ直接引いても、集約して引いても、どちらでもかまいません。
また、スーパークラスはサブクラスを一般化して作られたクラスとなるので、スーパークラスが持つ「属性」や「操作」はサブクラスにも引き継がれることになります。例えば、エンジンやハンドルにタイヤといった「属性」や、発進するとか停止するといった「操作」が該当します。
このことを「継承」といいます。しかし、乗車人数とか荷台といったサブクラス独自のものは、サブクラスの「属性」として定義します。
関連と集約
クラスとクラスの関係性は、汎化だけではなく、関連や集約など、いくつか存在します。
車は駐車場に置きますが、必ずしも固定の駐車場場所に保管されるわけではありません。
バスやトラックなどの社用車であれば、その会社が所有する何か所かの駐車エリアに、運用の事情に合わせて駐車させています。個人であっても、車通勤の方ですと、自宅の車庫と会社の駐車場の２ヶ所を利用していることもあります。
このような制約や制限の無い関係を、クラス図で表現する時は「関連」として表現します。
「集約」というのは、全体－部分の関係が成り立つ時に用いられます。
「レンタカー会社」で考えると、普通の「乗用車」、荷物用の「トラック」、大人数での移動用としての「バス」などを保有しています。しかし、「トラック」も「バス」もレンタカー会社にしか存在しないというものではなく、「レンタカー会社」も「乗用車」だけも保有していたり、会社設立当初や倒産してしまった時など１台も貸し出すものを所有していないということがあります。
このような全体部分関係をクラス図で表現する場合、「集約」とし、全体を表すクラス側に白抜き菱形を持つ矢印線を引くこととしています。
ところが、全体と部分が依存しあっている関係もあります。
「車」で考えると、「エンジン」「ハンドル」「タイヤ」など、各パーツが集まって全体を構成するような関係で、タイヤが無い車のようなものは、たぶん車とはいわず、別の名前も存在となります。ハンドルも、車の装備として利用価値があるもので、それ以外は部屋の装飾品になるくらいです。
こういった依存関係は「コンポジション」と呼び、全体を表すクラス側に黒塗りつぶし菱形を持つ矢印線を引くこととしています。
パッケージ
クラスを似たような機能でグルーピングすることがありますが、そのグループのことをパッケージと呼んでいます。車を例にすると、乗用と荷物用(トラックなど)、個人ユースと商業ユース(タクシー・バスなど)といった分類の仕方になります。
スーパークラスにするような汎用性のあるクラスを作成するのではなく、類似性のある集合を作成する際に用いられます。
※パッケージに関しては、ＵＭＬにパッケージ図が用意されています。
カプセル化
データを保有するだけでなく、データに対する操作も含めた形で一つにまとめてしまうことを、クラスによる情報のカプセル化といいます。
クラスは、オブジェクトという実体を表すものになるので、属性としていくつかの情報を管理していますし、それらの情報に対する各種操作を問題なく制御するロジック(アルゴリズム)も管理することになります。
書籍で考えると、いくつも存在する本の中から一意に決まるように属性を定義しておくとともに、貸出や返却、また購入や廃棄など、図書館で行なわれる書籍に対する全ての操作が実現できるように過不足なくロジックを組み立てておく必要があります。
クラスにおける属性と操作がもれなくカプセル化できていると、データ構造やアルゴリズムを変更する必要が生じた場合、変更すべき部分はカプセル化されたクラスの内部だけとなり、それ以外を考慮する必要はありません。変更による他への影響を考えなくてもいい、ということはクラスが適切にカプセル化されていることの大きなメリットといえます。
なにか変更の要求が発生してもクラス内部の問題として解決できるということになり、したがってクラス内のロジック(アルゴリズム)を公開する必要がないということになり、アルゴリズムを隠蔽化することができ、外部からロジックを破壊されてしまうことを防止できることとなります。
属性についても、何でも全て公開する必要はなく、外部からのリクエストに応じて公開すべき情報だけを提供するということも考えられ、そこでクラスのカプセル化に伴い、情報隠蔽という形で公開可否を判断することとしています。
クラス図を作成する際は、情報の公開可否を可視性として、次のように４段階のレベルで表わします。先頭の記号は、クラス図で表記する際のシンボルです。
＋ : public : 全て参照可能
－ : private : 自クラスのみ参照可能
＃ : protected : 自クラスと派生クラスで参照可能
～ : package : 同じパッケージ内で参照可能
クラス図の「属性」や「操作」の先頭に記号を付して、参照範囲を指定します。
記事のトップへ戻る
