［UMLとオブジェクト指向分析・設計が開発リスクを軽減する］
オブジェクト指向開発による利点
まず始めに，組み込みシステムをオブジェクト指向で開発する利点について考えてみましょう．
前述したように，現在の組み込みシステムの多くはRTOS上で動作する複数のタスクにより処理を行っています．このタスクという概念自体は大きなオブジェクトと捉えることもできます．現在のシステムでもタスク間の依存を少なくした設計を行うことで，システム全体の柔軟性やタスク単位での再利用性はある程度実現することができるでしょう．しかし，タスク自体の開発を考えた場合は，粒度があまりにも大きく内部の構造も機能的な視点で設計されているため拡張性や柔軟性という点では大きな問題を持っているといえます．
オブジェクト指向では，システムをタスクではなく，さらに細かなオブジェクトの集合として捉えます．粒度をオブジェクトの単位にすることで開発性や再利用性を向上させることができます．また，オブジェクトを作り出すものをクラスとして定義することで同じオブジェクトを簡単に作り出すことができます．これは，同一機器やプロトコルなどを複数制御することが多い組み込みシステムでは非常に便利です．
さらに，オブジェクト指向開発では抽象的なインターフェイスで設計・実装を行える点も大きな特徴です．オブジェクト指向のポリモフィズムという機能を使うことにより，実装に左右されない汎用的な設計を行うことが可能になります．GUI，ハードウェア，内部のアルゴリズムなど頻繁に変更されることが予想される部分は，この機能を使うことで変更に強い拡張性のある作りにすることができます．また，同じような機種に対してはフレームワークと呼ばれる「基本機能の実装と拡張用のインターフェイスから構成されるシステムの枠組み」を作成することにより効率的な差分開発が可能になります．
開発プロセス面から見た場合も，オブジェクト指向開発の大きな特徴である繰り返し型の開発はさまざまな開発リスクの低減に大きな威力を発揮します．
このように，オブジェクト指向は組み込みシステムの開発においても非常に大きな利点を持っていることがわかります．しかし，その一方では，先に述べたような制約が存在する事も事実です．たとえば，
・リアルタイム性を求められる時間的制約の厳しい部分
・ハードウェアを直接操作しなければいけない部分
などについては，拡張性や再利用性などよりも効率やサイズ等を重視した設計が必要になってくるでしょう．こういった部分は，無理矢理オブジェクト指向で開発するよりも，むしろ従来のリアルタイム制御に特化した設計技法やアセンブラ，Cなどによる実装が適しているかもしれません．
結論を言うと，組み込みシステムの開発では目的に合わせて一番有効な開発手法を用いることが開発のポイントになります．すべてに対してオブジェクト指向を適用するというよりは，従来手法と組み合わせ，より有効な部分に対して適用しそのメリットを引き出していく方が望ましいと思います．
組み込みのためのOO開発手法はUMLで！
ここで簡単に今回の記事のベースになっているリアルタイム向け開発方法論および，そこで使われるオブジェクトモデリング記法について触れておきます．
今回私たちが開発技法として紹介したものは，フィンランドのテレコム関連の会社であるNokiaのOOチームが提案しているOCTOPUS手法を参考に，オージス総研オブジェクト第1事業部での組み込み分野の開発経験を踏まえて独自に拡張したものです．そして，UMLを使った分析設計モデリングは組み込み系リアルタイム系の分野にもかなりフィットするという感触を得ています．特に基本的なシステム要件を定義するユースケース図とシーケンス図，問題領域やシステム内の構造を表現するクラス図やパッケージ図，オブジェクトの集団の振る舞いを表現するコラボレーション図，各コンポーネントの状態マシンとしての定義はステートチャート図で行い，各コンポーネントのハードウェアへの割り付けを表現する配置図といった組み合わせでほぼ必要十分なリアルタイム組み込み向けのモデリングを行えると経験上感じています．
実際，UML提案者の1人であるBooch氏は，現状のUMLはリアルタイムシステムの設計に十分だと述べていますし，彼自身多くのリアルタイム・リアクティブシステム（その多くは防衛関係）の設計にUMLを利用しています．特に，現在のUMLには，アクティブオブジェクト（図1で太線で示したボックス）の概念があるので，関連するオブジェクト集団間の一連の相互作用を表現するコラボレーション図をうまく使うと並行に動く複数オブジェクト（すなわちスレッドやタスクを割当てられたアクティブオブジェクト）間のイベントシーケンスを明確に表現できます．
たとえば，図1にあるように，3つのオブジェクトFactoryManager,
Robot, Ovenが各々タスクを割り当てられたアクティブオブジェクトでかつFactory
Managerは3個の内部オブジェクトを保持し，それらの間でのイベントのやり取りや待ち合わせ（2:
completed(job)はイベントA2, B2を待ち合わせている）が明確に表現されています．
ただし元来のコラボレーション図はオブジェクトを基本要素としていて，アーキテクチャ設計には要素が細かすぎます．OO技法の基本単位である小粒度のオブジェクトとリアルタイムシステムの基本単位である中粒度のタスクの間の折り合いをつけるノウハウが組み込み系にオブジェクトを適用する際のひとつのポイントだとすると，大局的な観点から比較的大きな粒度のコンポーネントどうしの相互作用をモデル化するための手段が必要です．そこで本技法では，システムアーキテクチャの設計時に高レベルのコラボレーション図（この目的のために開発されたユースケースマップという記法を利用するとさらに効果的です）を作成して各ユースケースに対応したスレッドの最適性やリスポンシビリティのコンポーネントへの割り当てのトレードオフを検討しています．
本技法は標準のUMLを最大限利用して組み込み系分野のモデリングに対処するという現実的なスタンスですが，リアルタイム系専用のモデリング要素を現在のUMLに追加するというアプローチも存在します．Bran Selic氏らのROOM（Real-Time Object-Oriented Modeling Language）手法では，並行なコンポーネント間のコラボレーションをより明確に表現するためにカプセル，プロトコル，ポート，コネクタと呼ばれるモデル要素を追加しています．オブジェクトが演じる役割をカプセルと呼び，その役割が必要とするプロトコルを実現したものがポート，カプセル間の通信をコネクタが実現します．これらの概念は，UMLのステレオタイプ機能を用いて次の版のUMLにリアルタイム拡張として取り入れられる可能性があります．ただし，どの概念も工夫次第で現状のUMLでも表現できますので，組み込みシステムの開発に現在のUMLを適用する上でこれらの概念の欠如はそれほど問題にはなりません．待つよりは早く適用して経験を積む方を選択することをお勧めします．
図1：コラボレーション図
| © 1999 OGIS-RI Co., Ltd. |
|
