[1999 年 9 月号]

［トレーニングの現場から] 第４回 - 初めてのモデル その１ -

■ はじめに

オブジェクト指向を学んでいこうとするとき、まず生徒さんが最初に躓く場所は、オブジェクトやクラスの発見です。
「クラスとかオブジェクトって本当にこれでいいのかなぁ…」
「正解を見せてもらったら、自分のモデルは正解とは違うところがたくさんあってショックだ…自分には向いていないのかも…」
そんなうめき声(!)が漏れ聞こえてくることもあります。

(私の場合)トレーニングでは生徒さんのモデルが解答からどれだけ乖離しているか？ということは見ません。生徒さんのモデルがどれだけつじつまのあったものか？ということを確認するようにしています。
といいますのも、モデリングに100点満点の正解はないからです。
オブジェクトを発見すると言ってはいますが、正確には用語を定義していく創造活動です。業務知識がオブジェクトの顔をして埋もれているわけではないのです。

「自分の発見したオブジェクトやクラスが正解かそうでないか？」ということにこだわったり、オブジェクト指向には自分は向いていないのだと、１度や２度の演習で決め付けてしまわないようにしましょう。
いろいろな解答例をみながら、「…あぁ、こんなものなんだな…」と少しずつ身に付けていきます。「科学的ではない！」とか、「機械的にできるようにしてほしい」とか、「AさんがしてもBさんがしても同じ結果になるような方法論でないと駄目だ」とかいわれる方もいらっしゃいますが、今のところモデリング修行が必要なのが実際です。
今の開発技法を学んだのと同じ程度の修行は必要だと思って頂いたほうがいいのです。
もちろん、標準化（誰が作っても似たようなものになる）というのはOOの重大なテーマです。
デザインパターン、アナリシスパターン、アーキテクチャパターンなどと呼ばれているバターンの利用がそのテーマの中心となっています。多くのパターンが発表されていますが、あなたのシステム分析を全てパターンでまかなうことは不可能です。やはり、分析・設計者の創造活動は必要です。

OOは初めて、という人のモデルを知ることは有効です。
トレーニングを受講する時というのは、人のモデルを観察する絶好のチャンスですね。

トレーニングの演習時間には、自分で考えてモデルを作成しててもらいます。そして、自分で考えてみて疑問点があきらかになってきたら、なるべく周囲の人とモデルを見せ合っていろいろなモデルのケースを見るようにしてくださいと薦めています。

オンサイト教育や新入社員教育の場合、とてもオープンな雰囲気でモデルをわきあいあいと誉めあいけなしあいながら、あっというまに勘所(かんどころ)のようなものを習得する傾向がありますが、トレーニング会場でのトレーニングは、見知らぬ会社の人が混在しますので、モデルを自由に検討しあうという雰囲気にまで至らない場合が多いです。（とても残念です）
できれば、人のモデルを見て、我がモデルを振り返る、我がモデルを見せて、人のモデルを知る。ということをしていくと、色々と勉強になります。
今回は、クラス図作成時に私が見かけた初心者のモデルのパターンをご紹介したいと思います。

靴会社の商品受注システムというのを例にとって考えてみましょう。(*1)

*1
演習仕様をここであげることはできませんので、モデルのパターンを紹介するために架空の仕様でご紹介します。

メイン関数の中に全ての処理を書き込んでしまうのと同じような感じですね。
(最近はみかけませんが、かつては…時折みかけました。)
OOでは、オブジェクトの協調動作をデザインすることが大切な活動です。特定の処理に責任を持つ小さな単位に分割し、どのように協調動作させるかを考えることが最初に習得しなければならないポイントです。

クラスは機能単位ではなく、意味単位です。そのため業務知識についての初期の分析段階で導出されるクラス名は名詞であるのが一般的です。（「靴の登録」とか「靴の注文」という名詞*形*に直しましょうといっているのではありません）

文字列や数字で表せるものは、属性としてクラスに含めるのが一般的なやり方です。サイズや色は、数字(25.5とか、23.0など）や文字(redとか、yellowなど）で表せる場合（つまり名前ぐらいにしか関心がない場合）、靴の属性として考えます。

「製造会社」はクラスか属性か？は一概に言えません。製造会社の情報は会社名だけという場合、文字列だけで表せます（マドラスとか、ワシントンなど）ので、靴クラスの属性として扱います。製造会社の住所や電話番号や責任窓口といった情報もシステム上必要があれば、クラスとして切り出すのがいいでしょう。

発注システムで、「靴の色には赤、青、黄の３つのバリエーションがあります」という記述に対してこのようなモデルが作成される場合があります。クラス「靴」の属性に「色」があり、ある靴オブジェクトの色の属性値として、赤、青、黄があると考えます。赤クラスのオブジェクトにはどんなものがありますか？と問うた時に曖昧だと見直しが必要です。（もし、色を三原色の構造として管理するのであれば、「色」クラスとして切り出す場合もあるでしょう）

分析活動と設計活動は分けて考えます。データベースは設計の段階で考えます。（データベースのエンティティとオブジェクトはしばしば一致します。DB構造を考えることはオブジェクトを導出する１つのヒントになります）

「靴」クラスの「種類」属性で切り分けてもいい場合があります。大量の商品を扱うシステムの場合全てを分けて扱う必要があるかどうか考えてみましょう。興味関心の度合いに応じて考えます。

仕様にかかれた単語をそのまま書き抜いてしまうと、もしかしたら同じ物が混じっているかもしれません。

何がなんだかわからなくなったと思います。モデルの１つの形をあげておきます。（業務知識のもつ意味合いによって、これが必ずしもベストというわけではないことにご注意下さい）

いかがですか？
今回は、本当に学び始めの人が最初に作成するモデルについてご紹介してみました。
トレーニングでは是非周りを見回して(嫌われないように！）みてくださいね。そして、「その（クラスの）オブジェクトは何ですか？」とか「それをクラスとして切り出した根拠は何ですか？」とおしゃべりしてみるのもいいと思います。色々な意味の発見ができるかもしれませんよ。

次回は皆さんのモデル紹介その２です。

お楽しみに。

© 1999 OGIS-RI Co., Ltd.

Prev. Index Next