ObjectSquare [2002 年 6 月号]

[組込みトレーニング潜入レポート]


 組込みトレーニング 潜入レポート 


株式会社オージス総研 オブジェクトテクノロジー・ソリューション部

坂坂屋.comの兄イ
こと
赤坂 英彦


2002/05/23 12:48

はじめに

ご挨拶

こんにちは、先月号に引き続きまして、坂坂屋.comの赤坂です。

オージス総研では毎月恒例で組込みオブジェクト指向 分析・設計トレーニングを行っています。
トレーニングは、3日間で開発プロセス(おもに各ワークフローでのグッドプラクティス(実践原則)を集めたもの)とLEGO MindStorms(実際に動くおもちゃ)を使った実装演習と盛りだくさんです。

さて、(お客様を含む)私とチームメンバーはイテレーション終了のご褒美として、5/15(水)から5/17(金)の3日間、このトレーニングを受講してきました。組込み開発を行っている方でOOに興味のある方、実際にOOを適用しているが何か上手くいかないエンジニアの方にはぴったりの内容でした。
以下に、その"潜入レポート"をご紹介いたします。

トレーニングの内容

-------
名称:組込み・リアルタイム向 オブジェクト指向 分析・設計トレーニング
会期:平成14年5月15日(水)〜17日(金) (3日間)
時間:10:00〜17:00 (3日とも)
内容:
タイトルの通り、組込み向けのオブジェクト指向 分析・設計についてのトレーニングですが、6月に出版される組込み向け開発ガイドライン(eUML)を強く反映した開発プロセスを知ることの出来る、現在では唯一のトレーニングです。また3日目の午後には、LEGOのロボットを使ったC++実装の演習もあります。

内容として、トレーニングのアジェンダにあった項目を挙げておきます。

講師:渡辺 博之氏(オージス総研)、実習講師:阿左美 勝氏(オージス総研)
-------

その他、本レポートでは以下についてもご報告いたします(目次の替わりです)。

組込みシステムとオブジェクト指向


ここでは組込みシステム開発の現状、問題点を概観し、オブジェクト指向技術の導入の必要性、導入にあたってのリスク、正しく導入するためのポイントなどが説明されました。

「オブジェクト指向への懸念事項」として、リアルタイム性が実現できるのか、リソース制約への対処が難しいといった事がよく云われますが、講師はリアルタイム性の実現よりもむしろリソース制約に対処するリスクの方が大きいとのことでした。
組込みシステム開発にオブジェクト指向を適用するにあたり、重要なスタンスとして、

を挙げていました。もう一点、システム開発を"楽にしてくれるもの"とも。

また、オブジェクト指向を適用する上での問題点として、一般的にはどういうクラスが存在するかといった静的側面が重要とされているが、組込みシステムにおいては、さらに、クラスがどのように振舞うのか(動的側面)ということも大事だということも話していました。

 

開発プロセス


組込み向け開発プロセス(eUML)の概要

トレーニングではeUMLの開発プロセスについて解説されています。オーバービューは図1をご覧下さい。

eUML開発プロセスのオーバービュー

<<図1. eUML開発プロセスのオーバービュー(トレーニング資料より引用)>>

ドメイン開発に関しては、要求分析、分析、アーキテクチャ設計、設計、実装という流れです。ワークフロー自体はよくあるものですが、個々のアクティビティは特に組込み分野にフィットしたものになっています。

ドメイン開発に並行したアーキテクチャメカニズム設計として、実装メカニズム、オブジェクトの生成・管理のメカニズム、並行性メカニズム、その他ユーティリティやデバッグシミュレータといった、ドメインに直接関係のない実装手段を開発するのが特徴的です。

以下は、独断と偏見により、私の興味あるところだけをご紹介します。統括的ではありませんので予めご了承ください。

[分析]

先のオブジェクト指向を適用する上での問題点での話題に関連しますが、組込みシステムの開発においては、静的側面だけでなく、動的側面についても重要なので、分析において単なる「What」ではなく、Whatを実現するための「How」についても検討すべき(もちろん、設計における「How」とは粒度、対象が異なる)とのことです。

[アーキテクチャメカニズム設計]

eUMLでは、「アーキテクチャメカニズム設計は"モデルを実装するために必要なメカニズムの設計"としてドメイン(問題領域)の分析、(アーキテクチャ)設計とは異なるアクティビティ(作業項目)」としています。アーキテクチャ要求を満たすためのメカニズムやOS、言語に依存した部分の実現方法の提供といった内容になります。

成果物として、メカニズムの「フレームワーク・ライブラリ」は容易に想像できましたが、「設計ガイドライン」、「作業手順書」といったルールに関したものをここで挙げていたのは、私にとっては目から鱗でした。

まさしく、以前のプロジェクトでメカニズム設計を担当した際にこの様にまとめましたが、現在のプロジェクトではこれらルールの成果物を主に環境としての"サポートワークフロー"の成果物としてしまいました。こうしてしまったことで、常時担当を置くことが出来ず、適切なメンテナンスが行われなくなってしまっていたのです。
今後は、アーキテクチャメカニズム設計というアクティビティを重視するとともに、これらルールのメンテナンスの主担当を常に置くように改善しようと思います。

 

要求分析のガイドライン

[ユースケース記述]

イベントフローの記述についての注意点として、システムとアクターのトランザクション(相互作用としてのやりとり)が中心となってしまい、ユーザー機能が見えにくくなってしまうことを挙げていました。

ユースケース記述に重要な側面は以下の2つで、

気をつけないと、イベントフローでは後者ばかりに気を取られてしまい、肝心なシステム機能を見落としてしまうことになってしまいます。

※ 私のメモには業務手順とありますが、システム機能といった方が適切かもしれません。

現在のプロジェクトにおいても、ユースケース記述の「概要」の欄の記述(ユーザーにとってのシステム機能)が不足ぎみになっています。

質問

Q.各CASEツール製品の比較と選択のポイントについて教えて下さい。

A.CASEツールには以下の3レベルがありますとのこと。

  1. お絵かき(Visio、その他ドローツール)
  2. 静的構造中心(Rose、Konesaなど)
  3. 動的モデルのサポート(Rose-RT、Bridge Point、Rhapsody、Konesa-RTなど)

機能に応じて価格は 1 < 2 < 3 の順に高価になります。3 のソースコード生成は各製品ごとに「癖」があるので、検討にあたっては実際に試してから決めた方が良いとのことでした。

※ 米国では3のCASEツールとしては、Rhapsodyが一番売れているそうです。

分析のガイドライン

[ドメイン定義]

シュレイヤーメラー法ではお馴染みのドメイン定義です。RUPやその他の開発プロセスでは、対象となるシステムあたりをひとつのドメインと云ったりしています(概念モデル=ドメインモデル)ので、ちょっと注意が必要です。

eUMLでのドメイン定義とは、開発対象のシステムをいくつか関心のある問題領域(ドメイン)に分割しようというものです。主要な機能、UI(ユーザインタフェース)、(OS、H/Wの)メカニズムといったドメインに分割して、関心ごとを分離して並行作業を可能にします。

RUPに比べると、かなり早い段階でレイヤ粒度のサブシステムを定義することになりますので、チームにUIの専門家、メカニズムの専門家といった分業可能なメンバー構成がとれればかなり有効だと思います。実際には全体を見通してチェックできる人がいないと問題もありそうですが。

[エンティティ分析]

エンティティ分析とはアプリケーションドメインやサービスといった"実現手段に関係しない概念"を先行して分析することです。

「エンティティ分析でのクラス抽出はとても大事で、これによってシステム開発の成否が決まるといっても過言ではない」とのことです(果たして、そこまで云ってたかどうか自信ありませんが、私はそう思っています)。また、エンティティ分析については、Databaseのモデル化についての書籍(例として『データ構造モデリング』)などがとても参考になるとのことでした。

[エンティティ分析でのクラスカテゴリ]

エンティティ分析でのクラス抽出の助けとして、eUMLではドメインを幾つかのクラスカテゴリに分類(それぞれstereotypeを規定)しています。これらカテゴリに着目してクラスを抽出することで、何も手がかりのないところからクラス抽出するより少しは楽になるのと、必要なタイプのクラスを抽出し忘れていないかレビューの際に使用することも出来ます。

# もちろん、全てのカテゴリからクラスが抽出されていなければならないという訳ではありません。ドメインによって多少偏りがあるのは仕方ありません。


エンティティ(ドメインで使用される情報)<<entity>>について

<<entity>>はエンティティ分析において" ドメインで使用される情報"に分類されるクラスのステレオタイプです。
エンティティは"相対的"なものなので、ドメイン定義で分割されたドメイン(RUPではサブシステム、またはレイヤといった粒度のもの)ごとに、エンティティの各クラスカテゴリが存在するとのことです。講師はこれをリカーシブな構造と云っていました(私はフラクタルな構造をイメージしていましたが、少し違うかも知れません(^^;;)。

また、これら<<entity>>クラスをシステム全体でひとつのパッケージにまとめてしまうと、保守しにくくなってしまうとの指摘もありました。理由として、問題領域(ドメイン)が異なるものは必要な業務知識も異なる、ならば同じドメインにまとめておく方が、開発も分担しやすいということです(正確には覚えてないので、私の誤解が含まれているかも)。

分析段階で、制御するデータ構造をきちんとモデル化し、レビューしておくことが重要ということも云われていました。良くある失敗は、制御するメカだけが抽出され、制御データについては全く分析されていないということです。

[演習3〜5]- 分析(エンティティ分析)、オブジェクト構造分析、コラボレーション分析

トレーニング受講者は、オージス社員を含め16名でした。4人×4チームに分かれて演習を行いました。私はオージス社員だけのチーム(メンバーは現役2名、OO未経験者2名)でした。

先程、クラスカテゴリについて講義を受けたばかりだというのに、全く<<spec>>クラスを抽出していなかったのは、我々オージスチームだけでした(T_T)。
# かなり恥ずかしい状況となってしまいました…。

ちなみに、<<spec>>クラスはエンティティ分析において"仕様やルール"を表すクラスのことです。

アーキテクチャ設計のガイドライン

アーキテクチャ設計については内容盛りだくさんなのですが、雑用その他で聴講することができませんでした。このため、レポートはあっさりになってしまいました。この辺に期待していた方、すみませんm(_._)m。

[アーキテクチャ設計]

パッケージ間の相互依存をなくすためにインタフェースクラスを出して、受け取り側で実現します(source-sink)。例えば、要求と結果で双方向になってしまう依存関係の"結果"側に適用します。

イベントをどこで定義するかによって依存関係が決定します。部品化したいクラスや保守性を上げたいクラスでは、なるべく自分のクラス内でイベントを定義すべきとのことです。

[タスクマッピングの手順]

タスクは並行に処理させたい単位(実行資源)のことです。

※なんでも、「非同期に動かしたい」ということと「タスク」の分割単位は別らしいです。

アーキテクチャメカニズム設計のガイドライン

実装メカニズムとして有限状態マシン(FSM)、オブジェクト間通信などの実装方法などについての説明がありました。

[FSMの実装]

FSMの実装方法としては以下の3種類があります。

  1. switch-caseによる実装
  2. 各アクションの関数ポインタテーブルによる実装
  3. Stateパターンを使った実装

それぞれ設計モデルと実装例が紹介され、各実装方法の比較としてサイズ、効率、保守性、再利用性といった尺度での評価が一覧に示されました。

[スーバー状態、サブ状態の実装]

スーパー状態、サブ状態についての実装方法についても幾つかの方法が紹介されました。状態モデルによる継承については、限られた条件のもとではとても強力とのことでしたが、不慣れな人が保守する可能性を考えると危険な感じがします。

といっても個人的には状態モデルの継承は使ってしまいそうですが(^^;;

[非同期メッセージの実現]

一つのEventQueueを所有するEventDispatcherクラス(<< active >>)が非同期に動かしたいクラス(複数)にイベントを振り分けることにより、同じ優先度の非同期オブジェクトをEventDispatcherによりひとつのタスクで実現することが可能。

※ これが「非同期に動かしたいもの」と「タスク」分割は別、の例でしょうか。

[オブジェクトの生成・管理メカニズム]

ここでは、ROM/RAMへの配置方法、オブジェクトの生成方法、システム初期化の仕組みの方法などが紹介されました。ここはかなり重要です。

 

設計・実装のガイドライン

分析とは異なり、実装を前提にモジュール内部の詳細な設計を行います。クラスの可視性や、属性、操作のシグニチャを決定することは勿論、効率や実装手段を考慮した分析モデルの再構成も必要になります。また、設計ではアーキテクチャメカニズムをモデルに組み込む作業も含まれます。

オブジェクトコラボレーション設計においてはシーケンス図などにより設計レベルでオブジェクト同士の相互作用を検討するが、全部のケースを書く必要はなく、重要な部分や分かりにくい部分に絞るのが肝心とのことでした。

LEGO ローバーロボットを使った実装演習


最後はLEGOを使ったローバーロボットの実装です。

LEGO ローバーロボット
<<図2. LEGO ローバーロボット(マテリアルより引用)>>

今回はKonesa-RTを使った実装演習でした。これによりシステム生成(Factory)などが自動生成されます。CASEツール上で実装コードを埋め込むためエディタすら使用しませんでした。

実装演習は、チームではなく個人で行いました。演習は3つのステップに分かれており、

というものです。
受講者各自がLEGO ローヴァーロボットを動かすべく頑張りました。お客様の中には、3日目の実装演習を前に前日から緊張されていた方もいらっしゃいました(笑)。なんでもこのトレーニングを開始して以来、最終段階まで実装を完了させた受講者の方は5人しかいらっしゃらない(そのうちオージス社員は1人だけ(なぜか新人さんらしい))とのことでした。一応、ステップ2までできれば達成感はあると思いますので完成しなくても全然OKだと思います。また、Konesa-RTを使っての実習ではまだ完成した人がいないということだったので、「それじゃ私が第1号に!!」なんて思ったのですが、途中で集中力が途絶えて、タバコが我慢できなくなってしまい、そのままLEGOは動くことなく(ただまっすぐには動きましたが(^^;;)演習時間が終了となってしまいました。

ちなみに一緒に参加した、チームメンバーの1人(一番若い後輩)がただ1人、最後の課題まで終了させ、LEGOをきちんと動かしていました。
# 先輩(しかも同じチームのリーダー!!)としての私の面子はどうなってしまうのでしょう(笑)。

■ 講師のコメントと受講者の感想など

ここで、組込み向けトレーニングの講師のコメント、受講者の方々の感想などをご紹介します。

□ 担当講師コメント

このトレーニングでは、私がいつもコンサルティングでお手伝いするときに話していることや、こんなガイドラインがあるとモデリング作業が楽に出来るなあ、などと思ったものを、出来るだけ多く盛り込みました。
内容も、常に最新の知識を反映するよう、心がけています(そのせいで、内容がなかなかFIXできないのですが...(笑))。(渡辺)

□ 実装演習サポート担当コメント

実装演習サポートを担当している阿左美です。私からは演習に関してのコメントを書かせていただきます。
本トレーニングは、分析→設計→実装におけるモデルの変遷を、演習にて実際に体験していただけるコースとなっています。演習題材は、LEGO MindStormsを使用した比較的小規模なシステムですが、トレーニング期間を考えると適度な規模だと思います。
受講した内容を演習で即実践して身に付けることができるので、今までオブジェクト指向を導入されたことがない方にもお薦めします。やはり、聴くだけではなく、自分で実施することが重要だと思います。
最後になりましたが、本トレーニングを受講された方々の今後のご活躍を心より願っております。(阿左美)

■ akobaさん(受講者)

私自身、試験的にOOを取り入れていますが、まだ実開発にOOを導入しているわけではなく、まだまだ勉強段階でこれからというところです。
今年の2月にオージス主催の「オブジェクト指向分析設計トレーニング(シルバー対応コース)」を受講し、なんとなく「こうやって分析設計すれば
いいんだなあ」と理解したつもりになり、小さな試験ツールで試験的に導入してみました。
しかし、そこでよくわからなくなったのが、「マルチタスクのときってどうやって分析設計していくのかな?」ということです。その話が前記トレーニングにはなかったからです。それから、「組込み向けシステムの場合のクラス抽出ってやっぱり難しいなあ」ということを感じていました。
そこで、今回組込み向けのトレーニングに参加したというわけです。あと、実はレゴのおもちゃ動かして遊ぶのがおもしろそうだったのもあります。。。
そんな私ですが、今回のトレーニングを受講して、まず、「これはそのまま使えるのでは!」と思わせられました。
開発プロセスに関しては順序立てて具体的に説明していただけて、私でも、「ああ、こうやっていけばいいんだなあ」って思った次第です。
「一つのプロセス(アクティビティ)でダイアグラムは一つしか使わない」っていうのは、結構いいですね。
この段階では何をするんだっていうのがすごく明確です。
それから、疑問になっていたマルチタスクの件も並行性設計の説明段階ですっきりしました。しかし、クラス抽出に関しては、説明はあったものの、
やはり経験が必要なのかなあと思ったりもしました。
最後に、、、レゴマインドストーム欲しいなあ。。
\23,000かあ。悩ましい。。
勢いで買っちゃおうかなあ。

■ SPR64331さん(受講者)

私の目的は、自分のスキル向上と、組込みにオブジェクト指向を取り入れた時のメリットデメリットを知りたいというものと、組込みでのクラス分けの方法でした。
テキストの出来がとても良かったので、これを見て復習しやすかったです。未だに良く分かってないのが、ビヘイビアで、私の頭の中ではビヘイビアはステートチャートを作成するもの!程度の理解しか有りません。
オブジェクト指向を取り入れる要因の一つに、組込みソフトウェアの肥大化が有り、オブジェクト指向を使用するのは理に適ってると思います。でも1つだけ、・・・実装で使用するコンパイラ、環境等の技術が枯れていないので、要らぬ苦労をする羽目にもなるのだなと思いました。(特にSTL周り)、この辺で上司の批判を食らうと立ち直れないです。
Konesa-RTは使いずらい印象が付きました。特に実装コードを埋め込む時、あんな小さなエディットボックスで何をやらせるんだ!俺には字が見えない。と、思いました。私の頭の中ではKonesa-RT = 悪 になってます。
クラス分けでは、まずドメイン分析で、ドメイン、UI、メカ、ドライバと分けて、エンティティ、Spec、H/W、H/WUnit等がクラス候補になる事が分かり、クラス分けの糸口が多少理解出来て良かったです。
その他、感想として、コラボレーション、ステートチャート図等は書いた事が無かったので良い勉強になりました。
こういったトレーニングを受けたのは始めてですが、参加して大変満足しました。

(赤坂注)Konesa-RTのエディットボックスは次バージョンで大きく見やすく改善されますとのことです(^^;;

 

まとめ

今回はイテレーション完了のご褒美に(?)、お客様を含むメンバー全員で組込みトレーニングを受講しました。

講師の渡辺さんのコメントにもあるように、マテリアルは毎回洗練しているそうです。
つまり常に鮮度の良い、グッドプラクティスの提供を心がけているってことですよね。

今回から例題もLEGOのキャンディーソーター(書籍と同じ例題)になり、いっそうeUML(組込みUML)色が強くなったようです。
1年前にリニューアルして開講した当時のマテリアル(のコピー)に比べて断然良いものになっていました。

マテリアルの例題:キャンディーソーター
<<図3. マテリアルの例題:キャンディーソーター(マテリアルより引用)>>

今回はその他のお客様もFA関係の方ばかりで、みなオブジェクト指向に乗り遅れまいと必死のようです(それぞれに温度差はあるようですが・・・)。

今回受講してみて、私個人の感想としてこんな方にお勧めいたします。
オブジェクト指向の基礎(例えばUML表記法)についてはある程度ご存知の方が前提となりますが…

このトレーニングを受講されると、組込みシステム開発においてオブジェクト指向を導入する際の手順がかなり具体的かつ詳細にまとめられており、わりとそのまま実施することができます。もちろん初めての場合には、ミニプロジェクト、パイロットプロジェクトで検証されることをお勧めいたしますが…。ここでの開発プロセスをそのまま実践することも可能です。実際、eUMLは「実践経験をベストプラクティス(実戦原則)としてまとめて、それを開発のガイドラインとして示していこう」というものです。組込み開発での、実践すべき作業あるいは作業手順、注意すべきポイント、重要なもの(不要なものを排除)などを示したものになっています。これは発売される書籍『eUML』はもちろん、トレーニングにも活かされています。

もちろん、これらグッドプラクティスは不変のものばかりではありません。実践経験を重ねていくうちに、市場の変化、技術要素の変化などに伴い変化していくものです。組込みシステム開発において、現時点でもっとも効率的にオブジェクトを指向を導入するためのプラクティス集といえますが、eUMLは今後も進化していくものと期待しています。何事も確定した時点で陳腐化が始まってしまいますから…。

もし、組込み・オブジェクト指向関係で良いトレーニングをお探しのお客様がいらっしゃいましたら、ぜひオージス総研の組込み分析・設計トレーニングをお勧めいたします。

「迷わず行けよ〜、行けばわかるさぁ〜」by 猪木せんせ

今回のレポートで、組込みトレーニングにご興味を持っていただけたら幸いです。
最後までお付き合いいただきましてありがとうございました m(_._)m。それではまた。

関連ページへのリンク

組込み向けオブジェクト指向分析・設計トレーニング

宣伝モードで申し訳ございませんが、私が潜入したトレーニングの概要、スケジュールはこちらからご覧いただけます。
もちろん、トレーニングのお申し込みも出来ます(^^;;。

Konesa、Konesa-RT

今回演習に使ったKonesa-RT(RealTime)についてはキャッツ株式会社様、Konesa については弊社にて情報がご覧いただけます。(※現在は取り扱っておりません。)
ちなみに次回(6月開催)ではCASEツールを使わない予定だそうです(こちらもいろいろと試行錯誤しているようです)。

eUML

eUML』は、日本発の組込み向けの開発プロセスのガイドラインです。以前、組込みネットで紹介されました。書籍の方は6月18日に翔泳社より発売されるそうです。

現在読めるのは、eUMLのエッセンスを濃縮した『組込みシステムのモデリングテクニック』です。これは、昨年JavaWorld誌に連載された記事ですが、書籍同様、レゴで作ったキャンディーソーターを使ってモデリングのエッセンスを紹介してくれます。

組込み関係の記事&レポート

組込み関係の記事と突撃レポートのリンクです。こちらもご覧下さい。

その他

やっぱりLEGO!、MindStormsですよねぇ(僕はまだ持ってませんが(^^;;)。

お手軽ゲームプログラミング(しかもネット対戦!!)としてRobocode、テラリウムなどがあります。究極の実践的自己学習用かな?

 

 




記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。
  
© 2002 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP