UMLのモデルが右脳と左脳のバランスで成り立つということ

　コミュニケーションを促進することにより，人間の活動が活性化され，作業の効率が改善されることについて，異を唱える人はいないと思う．UML（Unified Modeling Language）は共通言語だから，当然コミュニケーションツールというカテゴリに属するわけである．このモデルの特徴として，直感的に右脳で把握するための図（クラス図：後述）と，論理的にその図の示す内容を確認または検証するための記述（シーケンス図，コラボレーション図：後述）を，必ず対にして構成しているということを理解しておく必要がある．

　UMLをコミュニケーションツールとしてとらえた場合，注意すべきは，間違った描き方があり得るということである．相手に何かを伝えるという行為の結果として，作者の意図が読者に伝わらなければ，描き方が間違っているということがいえるわけである．

　設計の意図や戦略がモデルから読み取れないようでは，モデル化する意味があるのかないのかという議論に終始してしまい，過去の開発パラダイムとあまり変わらないことになりかねない．ところが，現実に商品開発の現場でモデルの確認を行うと，ほとんどのモデルからは設計意図や戦略，考え方，工夫というものを読みとれない．これは，従来のパラダイムの開発をモデル表現して，可視化しただけにすぎないということを意味している（図1）．

〔図1〕コミュニケーションを促進するためのUML/正しい使い方，間違った使い方（例）

　左脳で考える論理部分は，モデルの検証（たとえば，実装して本当に動くか否かの検証）ができればよいので，確認手段が確立しやすく，ほぼ問題ない．しかし，右脳で考えるモデリングの部分については，“センスや才能（もって生まれた能力）”という言葉によって片付けられ，オブジェクト指向技術の工業化に向けての課題について，未解決のままであるにもかかわらず，あたかも解決したかのごとく扱われ，その構築方法や思考プロセスの解説は皆無（?!）に等しく，解説するものがあったとしても実務には耐えられないことが多い．

　モデリングは本来，現実をそのまま描写すべきで，たとえ設計や実装を考える場面にあっても，自然にとらえた描写モデルを最初から崩すか，または意図的に崩すように作るべきではない．なぜなら，崩したことでその意図を推論する必要が起こり，また推論の結果として，同じモデルに対していくとおりもの解釈が可能になってしまうからである．これでは，作成者の意図を正確に伝えることにはならない．

　たとえば，あるデバイス（モータなど）とそれを制御する動作仕様（スペック）の関係は，デバイスを代表するクラスが定義されるなら，仕様はそのクラス自体に定義するもので，動作仕様という概念オブジェクトをわざわざ作って，デバイス≪has a≫動作仕様というようなとらえ方をすべきではない．これは，現実を描写することによる普遍性の表現による理解の促進を阻害する要因になる．

　ドメイン（domain：領域）の経験者であれば，すでにこの事実は理解できているはずだが，オブジェクト指向の最大の特徴である継承すなわち≪is a≫の関係について理解できないと，この≪has a≫が示すものが正しく見えてしまうことがあり，注意が必要である．すなわち，再利用によるソフト開発の生産性改善を行う際に，難しい継承によるホットスポットの特定よりも関連による置き換えを行うことが簡単にみえるからである．関連によるアプローチは，オブジェクト指向以前のパラダイムによる開発と大きく変わらないため，下流まで考えた開発効率を求めると，継承に劣ることはいうまでもない．

　また，親クラスと親クラスの間に関係を作る際，≪Interface≫クラスを安易に作成し，クラス間のオーバヘッドを増すことにどのような意味があるだろうか（図2）？　もちろん，インターフェース仕様に着目し，それを抽出する，あるいは十分に分析する必要があるのなら，クラスとしてインターフェースを代表させることに意味があるだろう．そのように考える必要のあるインターフェースがどのくらいあるのだろうか？　われわれはやみくもに本来なら簡単にできるシステムを複雑化しているだけではないだろうか？

〔図2〕Interfaceクラスによるパラドックス：簡単なはずのシステムが複雑化する

　オブジェクトにより，いままで見えなかったものが見えるようになり，ソフトウェアの制御構造や構成を知ることができる状況になってきたのは，モデリングによる開発手法の貢献にほかならない．しかし，見えるようになったことであたかもエントロピーの法則にしたがうように簡単な制御構造から複雑な制御構造へ変化してしまうことのきっかけになっているとしたら，それは問題である．つまり，よくわからないことが認識されれば，当然，ソフトの構造をシンプルに構成するような管理や努力が払われるが，モデル化されることでソフトの掌握がしやすくなると，より複雑な構造でソフトを作ることに対する拒絶感がなくなることを懸念する．

　われわれは，複雑なシステムを簡単にすることを当たり前のこととして評価しなければならない．モーツァルトが作曲するときに，次の音符の絶対性を求めたように，システムを単純化することが普遍を生み出すための近道になることを理解すべきである．とくに組み込み制御機器の開発に求められるのは無駄のない設計，無駄のない動作を基本としたコストパフォーマンスの追及である．この目的を見失うと，手段としてのソフトが目的化し，結果として真の目的を達成するための道筋として遠回りすることにならないだろうか．

　最近のヒット商品のめざしたものには“いやし”や“あそび”をテーマにしたものもある．しかし，普遍性を認識しないシステムでいやしを実現しようとしても，何をどうすればいやされるのかがわからないまま時間だけがすぎていくことになるだろう．デカルト思考やブレークスルー思考，システム分析・設計技法などを用いて，必要十分な分析と考察ができた者こそが，開発の結果をヒット商品に結びつけることができるのではないだろうか？

　普遍的なモデルを作るための方法について，今回は以降の章で，エレベータの制御モデルと電波時計システムという二つのモデルを例にあげて解説する．とくに，普遍的なモデルと実装モデルの関係を明確にすることにより，制御対象をモデル化するにあたり普遍的な部分と変化する部分との切り分け方法，あるいは概念オブジェクトと実体オブジェクトの切り分け方法を提案するので，UML-オブジェクト指向でクラス図を作成するときの参考にしていただきたい．

　本章〜第5章で使用するモデルは，ユースケースモデル，クラス図，シーケンス図の3種類である．それ以外にもステートチャート図（状態遷移図），コラボレーション図などをTPOにあわせて利用する．前者の三つのモデルは重要なので，念のため簡単に解説する．

Copyright 2003 杉浦英樹