導入
現在主流となっているオブジェクト指向プログラミング言語を用いたプログラミングは、既存のクラスを利用するか、自前でクラスを記述するかしてソフトウェアを構成します。クラスの数が数個の小さなソフトウェアのうちは問題になりませんが、片手を超える数のクラスを取り扱うようになると、それぞれの役割や存在さえも不明確になってしまいます。図は概念を確認するための良いツールです。今回学習するクラス図は、その意味で私たちを助けてくれる頼もしい味方です。
展開
クラス図とは
クラス図と、それに関連する語句の定義を示します。
クラス図 : 静的で宣言的な要素（クラスやインターフェイス、およびそれらの関係）の集合です。つまり、インスタンスにする前、sketchを実行する前のソースコード段階の各要素とその関係を示す図。
参考文献『オブジェクトモデリング表記法ガイド』より（一部文言を変更）
詳細度による描き分け
クラス図は、問題の取り扱い方のレベルによって描き方の詳細度を変えることができます。
- クラス名のみ：クラス名さえ分かれば良い場合
- 分析レベルの詳細：フィールド名やメソッド名をおおよそ示したい場合
- 実装レベルの詳細：フィールドやメソッドが公開かプライベートなのかまで示したい場合
クラス図の詳細度別の描き方
b.とc.の場合、上段にクラス名、中段にフィールド名、下段にメソッド名を記述します。分析レベルの詳細においては日本語のフィールド名やメソッド名を使うことを私は肯定します。分析レベルの段階で明確に名称が決定できるものではありません。よく考えて、最終的な実装段階でオブジェクトごとに最適な名称を決めれば良いのです。
実は、このような上段・中段・下段という区画の割り方はUMLのクラス図のすべてではありません。必要に応じて更に多くの区画に分けても良いのです。必要に応じて、自由に割って使いましょう。要は「コーディングの役に立つ」ように使うのです。
実装レベルの詳細度でクラス図を描く際、フィールドやメソッドを公開（+）、非公開（-）、プロテクテッド（#）のように可視性まで指示すると、クラス図がよりコードに近い形で表現できます。
また、私個人の考えとしては、実装レベルの詳細のクラス図を描くぐらいならコードを書くべきだと考えます。クラス図はこれから書くコードをどんなふうに構成したいかを具体的に記述できます。コードをどんな部分に切り分けようかという「細分化の方向性」と、コードをどんな部品から構成しようかという「組み立ての方向性」のどちらか、あるいは両面から検討する際に役立ちます。詳細な設計を行った上で、別の人にコードを記述してほしいならば実装レベルの詳細度のクラス図を描く必要があるでしょうが、個人的にソフトウェアを作成するとか、小さなソフトウェアを作成する際にあまりに詳細な図面を作成するのは無駄な作業でしょう。
ただし、小さなソフトウェアでも、長期にわたって開発を続けたい、あるいは続けることが分かっているならば、詳細なクラス図を作成して残しておくと助けられます。将来の自分が別人と考えた方が良いからです。
クラス間の関係の示し方
さらに、クラス間の関係を表現する方法があります。単純に2つのクラスに何らかの関係がある場合は、2つのクラスの矩形を線分で結び、その関係を表す言葉を線分に添えましょう。それで十分です。さらに詳細に関係を表現したい場合には、UMLに数多くの図示方法が用意されています。ここではよく使う数種類を紹介します。
- 依存性（dependency）
- 集約関係（contains）
- 汎化（継承）関係（generalization）
依存性
まずは依存性（a.）の描き方の例を示します。テストクラスは学校クラスによって作成されること、学生クラスがテストクラスを利用することを表現しています。これから作成しようとしているsketchで、このような依存関係をコードにするのだと明確化しています。
クラス間の依存性の描き方
依存性の図示はもっと実装側に踏み込んで「クラスAはクラスBの機能を初めて目的の機能を果たす」というような意味の図示をする場合もあるでしょう。
集約関係
次に集約関係（b.）の例を示します。ホームルームクラスが学生クラスを複数持つことを表現しています。菱形のお皿から延びた線分で、持つ側、持たれる側を表現しています。菱形のお皿が接している側が持つ側です。*はワイルドカードです。学生の数は特に規定されていないことを表します。0かもしれませんし、5人かもしれませんし、100人かもしれません。コードの実行時に決まる場合に*を書くと良いでしょう。学生の数が40人で固定の場合は、図中の*の代わりに40を書きます。5人から10人の間で変動がある場合は5..10と書きます。
集約関係の描き方
実際のコードでは、以下のように実装の仕方が複数考えられます。
- 双方独立したインスタンスとなり、ホームルームクラスのインスタンスが学生クラスのインスタンスへの参照を持つ。
- ホームルームクラスのコンストラクタで学生クラスのインスタンスを生成し保持する。
どのように実装すればシンプルで合理的か、これだけの情報ではまだ判断できません。全体を俯瞰して考える必要があります。そうすると、ソースコードだけを机の上に並べるよりも、クラス図等UMLの各種図面を机の上に並べた方が、より良い判断ができることでしょう。
汎化（継承）関係
最後に汎化（継承）関係（c.）の例を示します。まずは学生クラスを作成し、そこからサブクラスの理系学生クラスを作るといったコーディングの流れを想像しながら描いているかもしれませんし、学生クラスをスーパークラスとして、この他に文系学生というサブクラスも必要だなと検討しているかもしれません。いずれにせよ、こうして図にしておくと「そもそも学生というスーパークラスを作る必要があるんだろうか？」という疑問も湧きやすくなります。図により概念を形にすると、自分を疑うという高度な思考の働きがしやすくなります。単純なコーディングであっても、ちょっと紙とペンを使ってみるメリットがあるのです。
汎化（継承）関係の描き方
まとめ
クラス図はUMLの中核を成す重要な図法です。OMGには詳細な規定がたくさん記述されています。資格試験に合格しようと思えば規定を徹底的に学習する必要がありますが、ここで学習している皆さんには「まず使ってみること。間違っていてもいいから、自分が表現したいことをとことん図に盛り込むこと」をお勧めします。そのためにも紙と鉛筆を使ってどんどん描いてほしいのです。やがて、クラス図を描き、コードに活用することに慣れて来たときに、OMGの規定を見てください。すると「なるほど、この描き方は便利だ」「こう描けばこんなにシンプルになるのか」などという生きた知識・技術が身につき、コーディングがさらに楽になることでしょう。
演習
演習1（難易度：easy）
連載第17回で掲載したsketchTestAppInfoLoader7の各クラスを、クラス図で示しましょう。TestAppInfoLoader.pdeのコードも１つのクラスと考えてください。
演習2（難易度：easy）
次のクラス図で表されるクラスstudentをsketchにしてください。studentクラスをテストするコードをTestStudent.pdeとしてください。
studentクラスのクラス図
まとめ
学習の確認
それぞれの項目で、Aを選択できなければ、本文や演習にもう一度取り組みましょう。
- クラス図の描き方が理解できましたか？
- 理解できた。気持ちよく納得した。
- 理解できた。しかし、今ひとつスッキリしない。
- 理解できない。
- クラス図のメリットが理解できましたか？
- 理解できた。気持ちよく納得した。
- 理解できた。しかし、今ひとつスッキリしない。
- 理解できない。
参考文献
- 『これだけでわかる!初歩のUMLモデリング―基礎から各種テクニックまで第一人者が伝授!! (@ITハイブックス)』（萩本順三 著、技術評論社）
- UML入門の良書。絶版であるのが残念。古書をあたってください。
- 『オブジェクトモデリング表記法ガイド―例題で学ぶUML』（MISCOオブジェクト指向研究会 編著、今野 睦 監修、プレンティスホール出版）
- 私はUMLをこの書籍で学びました。大変分かりやすく記述されています。同じく絶版本。更に出版社は既に無いようです。これもよろしければ古書をあたってください。
演習解答
各クラスの関係を示したクラス図の例を示します。
sketch TestAppInfoLoader7 各クラスの関係
以下のファイルをフォルダTestStudentに納めてください。
