|
モデリングの壁(1) |
UMLが使えてもモデリングはできず
 |
| 図9●共通部分を適切にまとめ，すっきりしているモデル（a）と，うまくまとめられず複雑なモデル（b）。 このように，パターン化してモデルをとらえられるのはUMLの利点 |
さらなる壁がモデリングだ。オブジェクト指向の考え方を習得し，確立された方法論に基づいて開発をしても，優れた分析，設計のモデルを作れるとは限らないのだ。しかし，この壁の存在に気づいていない人は案外多い。
オージス総研の竹政氏は「UMLのセミナに来て初めて，UMLを覚えることとモデリングができることは別だ，と気づく人が多い。図の表記法だけ覚えてもだめで，自分がいかにモデル作りできないかを知るのは，セミナを4日間くらい受けてからだ」と語る注7）。優れたモデリングをするには，本人の経験や努力，センスなどが必要になる。これは，マニュアル化できる種類のものではない。
ただUMLを使っていると，いいモデルと悪いモデルを見分けやすくなるようだ。ウルシステムズの山岸耕二執行役員兼CTOは「UMLをずっと使い続けると，図を見るだけでモデリングのパターンが見えるようになってくる。囲碁や将棋で盤の全体を見ただけで，その形勢がわかるのと同じ」と語る（図9[拡大表示]）。分析や設計の結果を図で表現するメリットの一つと言える。
|
モデリングの壁(2) |
適切な抽象度を見極めにくい
 |
| 図10●どの抽象度でUMLを書くかというのは大きな問題。 システムの対象とするのが社員だけである場合は，Eの段階から書き始めればよい。しかし，将来的に社員以外も対象にする可能性があるのなら，Dの段階から書き始める必要がある |
もう一つ，モデリングを難しくするのが，モデルを記述する際の抽象度の見極めである。UMLのメリットの一つは，前述のように「大まかにシステムをとらえられる」ことにある。つまりモデリングは，システムが大まかにどういうものか，抽象化する作業でもある。このとき，どのレベルから見るのかを見極めるのがかなり難しい。自分が作るシステムがどの範囲を対象としており，将来的にどこまで拡張するかをきちんと把握していなければ，どのレベルで図を書き始めてよいかわからない（図10[拡大表示]）。また，同じシステムを開発するメンバ同士で，対象とする抽象度を統一できていなければ開発作業はスムーズに進まない。
抽象度を下げすぎることの危険性を指摘する声もある。オブジェクト指向では，最初に設計した図を徐々に具体化し，実装まで持っていく方法がよく採られる。しかし図を細かくしすぎると，UMLとソース・コードの差がなくなってしまう。これでは，システムを大枠でとらえにくくなるため，「設計の詳細は，UMLで書く必要はない注8）。どこまでUMLで書き，どこからは書かないかというバランスが一番の悩みどころだ」（豆蔵 取締役副社長兼CTOの萩本順三氏）。
|
モデリングの壁(3) |
存在しない「正解」を無駄に探す
UMLの利用を難しくしている壁の一つに，存在しない「正解」を求めてしまうこともある。モデリングは，能力や経験がものをいう「匠の世界」とも言える。あるシステムを作る時に，それをどのようにモデル化するかは人それぞれ違う。つまり，正解はない。
モデリングする時は，このことを認識している必要がある。しかし，どうしてもそこに「正解」を求め，必要以上に苦労してしまうことがあるようだ注9）。「隣の人のモデルと自分のモデルが違うと，不安になってしまう人がいる」（日本ラショナルソフトウェアの平野氏）。
またモデリングの際に，UMLが規定する9種類の図をすべて使わなければならないと思いこむのも落とし穴だ。実際のシステム開発において，9種類すべてが必要となることはまずない。しかし，むりやりすべてを使おうとしてしまい，無駄な努力をするケースがあるという。9種類の中でもよく使われるものとそうでないものはある。システムの種類やプロジェクトの進め方によっても，必要となる図は変わる。必要に応じて組み合わせるのもノウハウの一つだ。
