« RUPによるCMMIの実装について | トップページ | 経営の視点:ゴール指向の大切さ »

2005年6月 8日 (水)

組み込み・リアルタイムシステム向けの『オブジェクト指向開発方法論』Part1

 今日は仕事で組み込み・リアルタイムシステム向けの『オブジェクト指向開発方法論』を説明することをしていたので、昔自分が書いた文章を手直ししてみました。

==

『オブジェクト指向開発方法論』には世界中に色々あるけれど、組み込み・リアルタイムシステム向けは、組み込み・リアルタイムシステムの開発が、やはりビジネス系のシステムと異なる作業や手順があるため、非常に独特となる部分がある。

世界的に良く知られているのは、以下の通り、

・IBM-Rational社のRUPに取り込まれている旧ROOM手法。これをサポートしていたのはObjectTimeというツールで今はRoseRealTimeに引き継がれた。

・I-Logix社のRopesで、これをサポートするツールは、同社から発売されているラプソディ。

・S&M法。今はExecutableUMLと呼ぶことがい多いようだ。これをサポートするツールはプロジェクトテクノロジー社のBridgePoint

・ノキア社のオクトパス法

・etc(他にも色々ある。そのうちまた紹介します)

今日は、この中から2つの手法とツールの違いについて、簡単に整理したお話し。

 I-Logix社のOO組込みプロセスとRational社のOO組込みプロセス(ROOMが土台でRUPに取り込まれている:今は明示的にROOMとは呼ばない様だ)とっでは、オブジェクト指向といってもそれぞれオブジェクトの考え方、アーキテクチャ構成の考えにそれぞれ違いがある。

 I-Logix社のOO組込みプロセス(Ropes)は、組込みシステムのOO開発といっても非常にオーソドックスなOO開発プロセスでオブジェクトの抽出も幾つかは、組込みシステムに独特な視点が提案されてますが、特にビジネス系のオブジェクトの抽出と、比較しても非常に異なる様な程独なところは特ありません。
#非常に素直なアプローチで今までのOOの成果を利用出来る。

 また、ダグラス氏(Ropesの提唱者の一人)らの並行性の考えは、オブジェクトなどの静的なシステムの構成とは別に並行性などのタスクの抽出は別途ハッサン・Gomma氏の「DART法」などのタスク抽出などを参考にします。その後、各タスクで振る舞いオブジェクトをMappingしていきます。このMappingはリソースの競合、スケジューリング性などを考慮して行なわなければならず決して簡単では無い難しい作業です。特にリアルタイム性が厳しくなればなるほどこの傾向にあります。
 余談ですが、ノキア社のオクトパス法では、このタスクとオブジェクトのMappingに独特のアプローチを提案してます。

 一方、Rational社のOO組込みプロセス(ROOMが土台)は、組込み/リアルタイムシステムの特徴(制約)を最大限に意識したプロセスとなっています。ROOMでは、コンテキスト図やハードウエア構成図をオブジェクトの抽出や並行性の検討(マルチCPU、マルチタスクの検討)に使い、非常に重要視してます。ROOMのオブジェクトの抽出は、ビジネス系で見られるEntityオブジェクトより、Activeオブジェクト(自分のタスクを持つ候補:彼らはカプセルと読んでいる)を視点とします。

 この考えは組込み・リアルタイムシステムでは、並行性やハードウエア環境に非常に多くの制約を受けるので、コンテキスト図やハードウエア構成図を利用してActiveオブジェクトドリブンの開発をします。これの方が再利用性、競合の問題、スケジューリングの問題などの非常にデリケートかつ難しい問題を扱うには有利だという点です。

 なぜなら、マルチタスクの組込みシステムでCPUが変われば、システムのパフォーマンスが変わりますから、タスク構成を変更する必要がでてくる場合があります。加えて、機能に拡張を加える場合でも、デバイスなどの追加が多く、機能追加によりパフォーマンスや競合、デッドラインなどを検討しなおす組込みシステムではこのアプローチが向いているという意見です。彼らがこのようなアプローチでシステムアーキテクチャを構成する為、Activeオブジェクト(カプセル)にタスクを割り当てることも、複数のタスクを1つのタスクで割り当てることもRoseRTの持つシミュレーション機能で検討できるようになってます。さらにマルチCPU構成の場合でも、各CPUにタスクの割当を自由にできるようになっているようです。

 ROOM法以外のアプローチでは、タスク構成が変わるたびに、各タスクとオブジェクトをMappingを競合の問題やハードリアルタイム性を満たすスケジューリングをやり直すのは大変な労力ですし、再利用も難しいと言うわけです。ボードやCPUが変われば、また機能が変わればタスク構成が変わることが多いことが予想されるシステムならば、ROOMのアプローチが再利用性、競合の問題、スケジューリングの問題などの非常にデリケートかつ
難しい問題を扱うには有利だという点です。とは言ってもRoseRTのCaseToolを使えばですが...。

 補足ですが、ROOMのアプローチは並行性を基点としたオブジェクト構成ですが、(いわゆるEntityオブジェクトも出てきますがあくまで主役は各Activeオブジェクトで、 EntityクラスはActiveクラスに所有されている。つまり◆の関係になります。ですので競合問題を軽減している。)オブジェクト指向のアプローチのため、タスク候補のActive オブジェクトは、従来の粒度のSA/SD的な開発のタスクに比較して小さい粒度で能動的な振る舞いをもつオブジェクトを検討して分析・設計を進ます。つまり、機能分割による開発のタスク構成の粒度とは違います。最終的に実装環境のサポートする並行・並列性にMappingする際に、最終的なタスク、UNIXなどのプロセスの粒度に自由にMappingは出来るようになっています。

 以上により、組込みOO開発方法論といっても、それぞれ特徴をもっているため
さらに開発対象のシステムの特徴(ソフトリアルタイムとかハードリアルタイムとかetc)
「どの方法論は良く、どれが劣る」とはいえない状況ですので、肝心なのは、自分達のシステムに向いた方法を採用することですね。ここが、また難しいところでもあります。

|

« RUPによるCMMIの実装について | トップページ | 経営の視点:ゴール指向の大切さ »

「パソコン・インターネット」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/112989/4464777

この記事へのトラックバック一覧です: 組み込み・リアルタイムシステム向けの『オブジェクト指向開発方法論』Part1:

« RUPによるCMMIの実装について | トップページ | 経営の視点:ゴール指向の大切さ »