OCRESとは
OCRESは「OMG認定 組込み技術者資格試験」(OMG-Certified Real-time and Embedded Specialist Program)の略称で,“オークレス”と呼びます。
組込みシステムの開発に従事する世界のアーキテクト・開発者・プログラマを対象とした,世界最大のソフトウェア標準化コンソーシアムであるOMG(Object Management Group)が認定する資格試験です。日本では,2007年3月15日より日本語版の試験がリリースされています。組込みシステムソフトウェアの規格となるリアルタイムOS,プログラムおよびデザインの基本原理をカバーしており,一歩進んだ組込みソフトウェアエンジニアには必須の知識が試験対象となっています。
これらの知識を習得し,実践で活用することで,組込みソフトウェア開発をよりエンジニアリングに近い形で実行できます。エンジニアにとっての残業との戦いからの脱出,そして企業にとっては,品質の高いソフトウェア開発に役立つことを願ってやみません。
OCRESの認定レベルは,UMLの表記法試験「OCUPファンダメンタル」の上位レベルに位置づけられ,中級レベルの「OCRESインターメディエイト」,上級レベルの「OCRESアドバンスト」の2段階のレベルで構成されます。日本ではIPAが主導で策定したETSSに準拠しています。
OCRES出題範囲
- ソフトウェア工学分野
- MDA(モデル ドリブン アーキテクチャ)
- UMLプロファイル-スケジュール/性能/時間
- UMLプロファイル-サービス品質(QoS)フォールトトレランス
- Real-Time CORBA
- 組込みCORBA(CORBA/e)
- 軽量CORBA
- データ配給サービス(Data Distribution Service)など
※詳細はOMGのサイト(http://www.omg.org/)を参照ください。
UML教育研究所からお知らせ
OCRES関連の出版を予定しています。
- 『OCRES対策教本(仮)』,7月下旬出版予定
- 『SOFTWARE ENGINEERING for REAL-TIME SYSTEMS翻訳版(仮)』,8月下旬出版予定(一部の内容がOCRES試験範囲に該当します)
設計していますか?
山田 大介
簡単な要求仕様を与えられて「さぁ,設計図を書いてみましょう」と言われたら,みなさんは何を書きますか? いきなり手が止まる人も多いと思います。そしてフローチャートのような設計図を書く人を多く見かけます。
しかし,それでは設計を表現できたとはいえません。たとえばソースコードが10万行の組込み機器があるとします。10万行のソースコードをA4サイズの用紙に印刷すると約1,500ページになります。もちろん,その情報だけでは設計の意図は見えてきません(図A)。
図A 設計図と記述の抽象度

またフローチャートは処理の流れを表現するものであり,ソースコードとほぼ同等の内容を図的に表現しているに過ぎないことから,同じく1,500ページを超える資料となってしまいます。フローチャートからも設計意図は見えてこないでしょう。
設計とは「複雑なものを,管理可能な単位に分割し,それを構造的に表現する」こと。すなわち分割統治です。組込みソフトウェアの設計とは,関数単位や責務単位などに分解して表現することです。関数単位に分割する方法が構造化手法で,責務単位に分割する方法がオブジェクト指向です。構造化手法では,モジュールの構造を表現するモジュール構造図を描くことになりますが,こちらはA4サイズで約50ページとなります。オブジェクト指向では責務をクラスで表現しますが,A4で約10ページとなります(いずれも単純計算)。
いかがでしょうか,1,500ページのソースコードが50ページあるいは10ページで表現できることになります。1,500ページでは担当者はその量に圧倒されてしまいますし,管理者は内部を見ようともしないでしょう。しかし,50ページ程度であれば,それを管理して,戦略的な開発に結びつけることも可能となります。今日のようにソースコードが100万行を越えるものも珍しくない状況下では,このような,設計を抽象化し図的表現する表記法が必須です。その図的表現の世界標準となるものがUMLです。これからのソフトウェアエンジニアは,UMLを駆使し,設計を行うことが重要になります。そして場合によっては,世界中のエンジニアとのコラボレーションを実現することが求められます。それらの経験を積むことでソフトウェアアーキテクトとして活躍する世界が開けるはずです。
エンジニアリングしていますか?
山田 大介
組込みソフトウェアエンジニアは,日夜,自分の作ったソフトウェアと格闘しているのではないでしょうか。仕様変更に振り回されたり,障害対応で忙殺されたりしている姿が目に浮かんでしまいます。しかし,それらの作業に追われてしまって,学習する時間を失っていませんか? また,それらの作業の理論的な裏づけを理解していますか? ということが気になります。
実践と理論を結びつけることも大切です。理論なき実践では,何度繰り返しても,実力アップは見込めないでしょう。そして,理論的な知識不足が,さらに多忙な作業を作り出してしまう,という悪循環に陥ってしまいます。
組込みソフトウェアエンジニアに今求められることは,「エンジニアリング」をすることです。たとえば,モジュール分割のよし悪しの尺度である「コヒージョン」(注A)を知っていることが大切です。セミナーなどで,コヒージョンを知っている人に挙手をしてもらうと,1割程度しか手が上がりません。
そして,リアルタイム&組込みの分野でのリアルタイム性の保障やスケジューリング,そして,パフォーマンスの最適化なども,今までの経験則を理論と結びつけることが大切です。コヒージョンというモジュール分割の尺度,レートモノトニックというスケジューリング理論などを理解することで,現状のソフトウェアに筋を通すことができます。そして,次の開発では,それらの理論を活かして,より速く,よりよいものを設計することが可能となるでしょう。
設計すること,エンジニアリングの理論に基づくこと,ほかの分野では当たり前のことが,今の組込みソフトウェア開発の分野では欠如しています。設計図がないエンジニアリングという特殊な世界は,ソフトウェアだけなのかもしれません。これを解決することで,より健全で楽しい産業になるはずです。日本の国際競争優位性は,組込み機器分野であると叫ばれている今こそエンジニアにとって必要な技術なのです。
そのような労働集約的な労働スタイルから脱却し,知的で高度なソフトウェアエンジニアやソフトウェアアーキテクトを目指す基礎となる知識が「OCRES」です。