初出：技術評論社「組込みプレスVol.3」（2006年5月25日発売）
組込みシステムのソフトウェア開発ではコストの制約などから、まだまだアセンブリ言語やC言語が主流の分野があります。 使用するプロセッサに対応したC++のクロスコンパイラが存在しないこともあります。メモリも贅沢に使えません。数K バイトとか数100 バイト程度のメモリでヒープやスタックを贅沢に使えるはずもありません。必然的にいろんなところから参照、更新する1 ビット単位のフラグや変数を大域的に使用してしまいがちです。RTOS を使用する文化も予算もない場合、μITRON やμT-Kernel なども採用されません。 このような恵まれない貧弱な環境のことをここでは「省リソース」と呼びましょう。
さて、組込みシステムの開発でオブジェクト指向設計が本当に必要な分野は、実はこのような省リソース環境での開発だと言っても過言ではありません。
ハードウェアの変更を含むモデルチェンジに短期間かつ高品質に対応することがこの場合のオブジェクト指向設計の目的です。 旧来型の「組込み」はチームで開発することも少なく、再利用性を考えて設計する時間もありません。
ハードウェアのコストダウンでチップだけを変更して製品仕様が基本的に前のモデルとほとんど変わらず、ソフトウェアの変更工数を少ししか確保できない経験をお持ちの方も少なくないでしょう。 このような開発で実際にやることは前のモデルのソースプログラムをコピーして手直しする「作業」です。ポートのアサインがほとんど変わっていないから手直しは少し。ハード屋さんはこんなことを考えます。そのポートの先に仕様が変わったチップが繋がっていても「そこだけ」変更すれば済むと思い込んでいます。しかし、そのような柔軟な作り方をしていませんから変更は「そこだけ」では済みません。修正個所が広範囲に及ぶことが少なくありません。
では、どうやったら修正個所を少なくすることが出来るでしょうか。 それはオブジェクト指向設計で実装する部分を少しずつ増やしていくことです。 「そこだけ」の対象毎に開発するわけです。 チップやプロセッサに依存する処理を抽象化してアプリケーションと分離して実装すれば、ハードウェアの構成が変わっても局所的な対応が可能になります。ポートの割付や論理に依存しない抽象化を行えば修正個所も限定できます。
オブジェクト指向というとUMLで設計してC++やJavaなどで実装しなければならないという呪縛があるとすれば、その固定観念を捨て去ることが必要です。そのような固定観念では最初からオブジェクト指向設計など出来るはずもありません。 難解な概念を駆使して設計する必要はほとんど不要です。
この程度の着目点で十分です。 抽象化するためには、まずブロック図を書きましょう。
次にブロック図で分けたブロックはカプセルという呼び方に換えます。カプセルはデータと処理をひとまとめにして抽象化するという概念ですが、データと処理の記述を一つのソースファイルにまとめることにより実現します。大きな一つのソースファイルになっても気にしないことです。そのようなデメリットよりもカプセルとして独立しているということの方がここでは重要です。データを隠蔽するために外部参照は禁止し、最低限のインターフェースを持つ関数やサブルーチン（マクロだって良い）を用意し、それらを他のカプセルとのインターフェースとします。公開用のインターフェースに対する他のカプセル向けの「公開用ヘッダファイル」も用意します。
ｺﾒﾝﾄをする