現在ある制御対象をオブジェクト指向にする場合は，オブジェクト指向分析を行い，本来あるべき姿を吟味してから開発に着手する．また，現状の問題・課題を明確にしてから作業を進めることが大事である．既存のソフトウェアで実現したシステムを，そのままオブジェクト指向設計することをめざすべきではない．

　たとえば，既存の開発方式では，使っている言語の特性から，データ構造やステータス，フラグなどを手段として用いることで実装するが，それはたまたまそこにある“手段”であり，目的ではない．つまり，実現手段と分析は徹底的に切り離して考えるべきである．

　正しく分析すれば，実現手段に左右されない“本質”に迫ることができるわけだ．この“本質”が不偏なモデルになり，フレームワークに繋がっていくことになる．

　あるべき姿を十分に分析することで，フレームワーク（洗練されたオブジェクト指向らしい分析モデル，すなわち不偏の，真実のモデル）ができるはずである．既存の設計結果を分析し，同様の方法で実装することを目的にモデリングしてしまっては，本末転倒である．

　とはいうものの，たとえば大規模な組み込みソフトウェアの一部分の開発を担当しているグループが，部分的にオブジェクト指向を行おうとした場合，分析対象は既存のソフトウェアアーキテクチャの一部分であり，あるべき姿（いわゆる“What”を求める分析）を導き出すことなど不可能に近いということも現実である．

　そのような場合には無理をせず，現在の状況をモデリングし，モデルからソフトウェア制御の複雑さを分析し，そこに改善を加えることで再構築を試みればよい（図6）．図6はUMLによる図だが，ここで簡単に説明しておく．詳細は本特集の第7章｢オブジェクト指向を読みこなすための用語集｣を参照いただきたい．

〔図6〕現実的なアプローチ

　最終的な目的は，高度な再利用による生産性の改善なのだから，まずは可視化を第一段階として捉えるべきである．この進め方では，生産性改善の効果である時間的余裕（開発効率が増せば，時間的余裕が生まれるはず）を用いて，さらにオブジェクト指向での開発部分を増加させれば良いだろう．この方法で，ドメイン全体をオブジェクト指向に導く理想的なアプローチを図7に示す．

〔図7〕理想的なアプローチ

　つまり，フレームワークを基本とした再利用がなされるべきであり，ソフトウェア部品をあまり意識したくない．それは，制御対象がもともと十分にユニークなものであり，汎用化，柔軟性，拡張性などの冗長設計と相反するQCDS（Quality，Cost，Delivery，Security）をターゲットに開発を進めるからである．

　たとえば，Windows CEや（リアルタイム向けの機能拡張のなされていない）Linuxを製品に組み込むOSとして使えるような，比較的時間的な制約が少ないような開発なら，冗長な設計が許される．しかし，割り込み発生から処理開始までの時間的制約がμs単位になるような場合や，割り込み処理の再現性を重点的に管理する必要がある開発では，拡張性と再利用性に重きを置きすぎると，要求される性能を達成できなくなる．

　もしも，C（Cost）の点で有利な展開ができるなら，ある程度の冗長さは許されるだろうが，製造業である以上，不要な処理やコストは極力削り，最適な設計を進めたいのが心情である．

Copyright 2001 杉浦 英樹