図4

　詳細をお伝えすることは紙面などの都合でできかねますが，CIMはシステム環境を図4[拡大表示]のようにモデル化しています。この図を眺めながら，ご自分のシステム環境を振り返ってください。皆さんのシステム環境（実世界）が反映されているでしょうか？

　ここで多くの人は，「Core ModelとCommon Modelとはどのようなものであろう」と興味を示すことでしょう。CIM仕様書では次のように定義されています。ここでは概要のみを紹介しますから，詳細はすでに紹介してあるURLサイト情報を参照されてください。必要な情報はすべてダウンロード可能となっています。

・Core Modelは，すべてのシステム構成要素に適応される情報モデルである
・Core Modelは，システム要素を分析し，それを人に説明するために必要な，基本的な用語（basic vocabulary）となるクラス群，その関連，及びクラス・プロパティで構成される

　一方，Common Modelは次のような説明がなされています。

・Common Modelは，特定のシステム要素ではあっても，すでに一般的に使用されている要素の共通概念を表現する
・Common Modelは特定の社の製品や実装テクノロジからは独立している

　私は可能な限りわかりやすくなるように，一文一文を拡大解釈しながら文章を用意していますが，おそらく“普通の人々”はCIMの真意を理解することはできないと思われます。しかし，次回連載をお読みいただければ，かなりの数の人に「なるほど！」と言っていただけるものと思います。このため，現時点では次のような点を理解しておいて下さい。

・Core Modelクラスはすべてのシステム構成要素に適応される
・クラスというのは，日常生活でいえば，会話に必要な基本的な用語（単語）である
・クラスは相互に関連付けられる
・クラスはプロパティ（次回取り上げます）を持つ
・Common Modelクラスは，日常的に使用されている，個々のシステム構成要素に適応される。ただし，個々の製品やテクノロジからは独立している

　オブジェクト指向開発方法論に精通している開発者は，これらの各情報項目を一見すれば，CIMが目指そうとしていることをかなり理解できるのではないかと思います（メソッドがありませんが，この点は次回取り上げます）。しかし，開発業務に従事しない“普通の人々”は，依然として首をひねっていると思います。

　それではここで“普通の人々”の立場から，上にあげた第2文，“クラスというのは，日常生活でいえば，対話に必要な基本的な用語である”の意味を考えてみましょう。“普通の人々”はソフトウエアを開発しないにしても，何らかの組織に属していると思います。ここでは仮に化粧品会社に属しているとしましょう。すると，就職シーズンになると，時には，会社を代表して会社説明会などに出かける必要も出てきます。説明会の資料を用意しなければならないことは当然ですが，優秀な学生を1人でも採用したいために，自分の会社をわかりやすいように説明することに神経を使うのではないでしょうか。その際，使用する単語，つまり，用語の選択にも注意を払うはずです。そればかりではなく，説明後は質疑応答の時間も設けることになるでしょう。この一連の作業の流れは，オブジェクト指向開発方法論を身にまとう開発者にそのまま当てはまるのではないか，と思います。

　それでは，この譬え話に関連付けながら，クラスについて整理しておきましょう。なお，カッコ内には対応するオブジェクト指向開発方法論の専門用語を紹介しておきます。

・クラスは基本的な用語である（クラスの独立性）
・クラスは場面場面に応じて適切に選択し，使用する必要がある（クラス抽出）
・1つの会社に特有な用語は，より分かりやすく説明する必要がある（クラス命名やドキュメント）
・1つの会社に特有な商品（上の例では化粧品に相当）を表現する用語（クラス属性）である場合，次期商品名も意識して作成する必要がある（要求変更への対応や機能拡張）
・1つの会社に特有な商品は，他の商品と併用することもある（クラス間の関連）

　このまとめ文は，ソフトウエア開発に従事しない“普通の人々”も先端開発者もほとんど同じように理解できるのではないかと思います。

　会社説明会で一大演説をする役割を担った社員は，必要な資料を準備万端用意して，多少緊張した面持ちで会社を出ようとするでしょう。そのとき，同僚に次のような質問をすることは日常茶飯事でしょう。

“当社のあの商品の市場占有率は40%で間違いなかったよね？”
“社長の年齢は65歳で間違いなかったよね？”

図5

　これらは一種の後戻りであり（ラウンド・トリップ），社長の正確な年齢を同僚が知らない場合，秘書あるいは直接当の本人に確認する必要もあるでしょう（スパイラル＝旋回）。前回説明したように，米Rational Softawreの開発プロセスRUPは，スパイラル方法論を唱えています。ここから言えることは，オブジェクト指向開発方法論は意外と私たちの日常生活を反映しているということではないでしょうか。最後に図5[拡大表示]のような画面を紹介しておきます。

　図5は一般にはクラス図といわれています。この図の表記法は基本的に前回紹介したRationalのUnified Modeling Lanaguage（UML）で描かれています。ただし，多少分かりやすくなるように，色つきの線でクラス間の関連を表現しています。ダウンロードした資料の一部には，「色つき線はUMLでサポートされていない」と断り書きがありますが，Rationalへのリンクが張ってあるところを見ると，同社から何らかの形の支援を受けていると思われます。

　通常は開発に従事しない“普通の人々”は，この種の図をいきなり見せられるとかなり困惑しますが，開発者との間でコミュニケーションが取れていれば，困惑の度合いはそれほどでもないのではないか，と思います。

今回のまとめ

　今回はオブジェクト指向開発方法論の中心をなすクラスについて，“普通の人々”の視点から考えてみました。“普通の人々”は発注者として，開発者とさまざまな会議を持つこともありますから，開発者の事情も考えてみました。

　次回はクラスとは切っても切れない“プロパティ”と“メソッド”を取り上げます。クラスの理解がより一層進むのではないかと思います。それではごきげんよう。