 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| 株式会社リコー | ||||||||||||
|
近年の組み込みプログラムの需要は飛躍的に増加している。プログラムサイズの増大による開発の大規模化／複雑化、製品ライフサイクルの短縮による短期開発要求などの背景から、人材不足ならびに品質問題が現状の課題となっている。HDDレコーダーや携帯電話の不具合は私自身よく耳にする。これらは、大規模／複雑化する組み込みプログラムに対し、開発現場の生産性が追いついていないことが原因として挙げられている。 こういった状況は数年前から続いており、リコーでは開発生産性を高めるために、90年代中頃からオブジェクト指向開発に取り組んでいる。当時は共通フレームワーク（固定部）を用意し、その上で稼動する小さなソフトを部品（変動部）として開発する手法を採用していた。 しかし、ハードウェアの部品変更やアーキテクチャの変更により、変動部だけでなく固定部も同時に変更せざるを得ないといった問題が発生した。組み込みプログラム開発では、コンポーネント化だけでは開発生産性が必ずしも向上しないことがわかった。 そこでリコーは、2001年下期からはEmbedded MDAという呼び名でプログラムコードの自動生成に取り組み始めている。MDAのメリットは、プラットフォームやOS、開発言語に依存せず、モデル記述のみで実装に近い段階まで開発を進められるところにある。その代わり、ツールが持つMDA機能（プログラム自動生成機能）のプログラムコード生成率や品質、精度に問題がないかを検証する必要があった。2001年当時ではツールによってかなり機能的に差があったと記憶している。 リコーでは、MDA機能を持つUMLモデリング・ツールを「推敲型」と「変換型」に分類し複数評価している。「推敲型」は、モデル内の記述コードが実装依存となるのに対し、「変換型」ではモデル用に言語と実装言語が分かれている。結果、推敲型の「Rose RealTime」と変換型の「BridgePoint」の2つを使い分けている。それぞれ一長一短であるとの評価だ（表2）。 |
||||||||||||
表2：推敲型と変換型の長所短所 |
||||||||||||
| Embedded MDAへの取り組みに際しては、開発担当者が分担する作業に変化があった。特にモデラーとプログラマの役割に変化があった。通常の開発では、モデラーとプログラマが一緒に作業することは無いが、MDAの場合、モデラーとプログラマの作業が渾然一体としている。モデラーが作成したモデルがプログラムとして生成されるからである。リコーではモデラーとプログラマを一緒に作業させている。 リコーの事例は、変化の激しい環境の中、コンポーネント開発からプログラム自動生成のMDAに開発アーキテクチャを移行させた事例である。彼らの経験からはMDA採用時の注意点が垣間見られる。 まずはツールの選択である。MDAではプログラムを自動生成するツールを選択することになるが、ツールの癖や制約の範囲内でプログラム自動生成を意識したモデリングを行う必要があるため、それらを承知した上でツールを選択したり、選択後にツール利用ガイドなどを作成したりする必要が出てくる。 また、開発担当者の役割分担に変化があることも見逃せない。単純に考えると前工程におけるモデラーの負担が増加する。MDAを採用する際は彼らの経験を参考にしてほしい。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
