UMLでハード／ソフトの分割ポイントを見つける：SoC設計にモデリング手法を導入する（2）（1/3 ページ）

組み込みシステム開発にモデリング手法を取り入れると、ハードウェアとソフトウェアの分割ポイントをより効果的に策定できる

[塚田 雄一 キャッツ，＠IT MONOist]

はじめに

　前回「人海戦術よりスマートなSoC開発はないのか？」では、膨大化／複雑化する組み込み（SoC）開発に対し、1つの解決策としてUMLの適用が有効ではないか、という仮説を立てました。そしてUMTP（UMLモデリング推進協議会）では、「UML for SoC」を標準化する取り組みを経て、現在SoC分科会として「システム要求分析グループ」「HW／SW分割グループ」「ハード設計グループ」という3つのグループに分かれて活動を行っている旨を紹介しました。今回は「HW／SW分割グループ」の活動を報告します。

HW／SW分割グループの活動目的と課題

　組み込みシステムには、HW（ハードウェア）開発とSW（ソフトウェア）開発があります。つまり、あらかじめパソコンなど決まったプラットフォーム上で動作するソフトウェア開発だけを行うのではなく、ハードウェアの開発も並行して行う必要性があります。またそれ以前に、要求（機能）をソフトウェアで実現するか、ハードウェアで実現するかという分割（パーティショニング）を行う必要があります。

　そこではコストとパフォーマンスのトレードオフを考慮する必要があるのですが、客観的なデータの裏付けによらず、過去の経験と勘に頼ることが現実には多いものです。また実装を行った後に、パフォーマンス要求に対して最適な実装であったか、評価が十分に行いきれずに製品になっているケースもあるのが現実ではないでしょうか。

　そこでHW／SW分割グループのメンバーは、このような課題に対する解決手段はないか、もし解決できないのであれば何が問題であるかについて議論を行い、UMLを使用してHW／SW分割の分析を行うことは有効だという仮説を立てました。

　以下にHW／SW分割グループの活動目的を記します。

1. 上流工程におけるHW／SW分割に関する指針を明確にし、決定要因とその要求資質の影響度に関する指針を明確にする
2. UMLを使用することの利点を明確にする
3. 現在のプロセスに足りないものがあるとすれば、それが何かを明確にする

　最終的には、見積もりのための作業工程と精度に関する部分を明確にして、SoC開発の効率化を図るところまで適用したいと考えています。

　誤解のないように、SoC分科会の考えているUMLの認識について確認します。UMLはシステムを表現する1つの手段でしかありません。HW／SWの分割を行うのは、あくまで開発者自身であり、その人のドメイン、要求、環境などの知識、またはスキルに依存する部分が多く、UMLを使用すれば何でもできるわけではありません。つまりUMLはあくまで、HW／SW分割を行ううえで何かを手助けしてくれるものであるという認識です。そのため、UMLはSoC開発者に何を手助けしてくれるのか、ということを明確にするのも活動目的の1つです。

　ここまで立派な目標を掲げてきましたが、実は何から手を付けてよいのか分からないというのが当初の現状でした。そこで以下のような対策を検討しました。

1. 何から手を付けてよいか分からなければ、まず開発プロセス、手法を定義する
2. ハードウェアの分析手法に実績がなければ、ソフトウェア開発で実績のある手法を参考にする
3. 実際に仕様から分析、設計、実装、評価を行うのがスケジュール的に困難であれば、過去にパフォーマンス評価を行った実績＆データを参考にする

　そして上記を満足する題材として「JPEGコーデック」を選びました。JPEGであれば、仕様を定義する必要はなく、HW／SW分割の実績は豊富で、分割を行い一部をハードウェアで実装できることも分かっているため、不安は少なくて済みます。メンバーにはHW／SW分割の分析にUMLを使用した実績はないので、ソフトウェア開発で分析の実績がある「Executable UML実践入門―クラス・モデルをいかに作成するか」「組み込みUML―eUMLによるオブジェクト指向組み込みシステム開発」などの書籍を参考にしました。

開発フローの策定

　次に開発フローについて議論を行いました。ここで驚いたことが1つ。それは開発フローに対する各メンバーの認識が違っていたのです。プログラミングという作業は設計でしょうか、実装でしょうか、皆さんも一緒に考えてみてください。

　「設計＝プログラミングを行う」という認識のメンバーもいれば、設計では設計における仕様を決定するとして、「実装でプログラミング＝コーディング」という認識のメンバーもいました。結果的には、仕様から実装を行うまでに必要とされる事項は同じで、言葉の解釈が違っていたのです。しかしそれは単に言葉の解釈の違いだけでなく、工程の中で何を一番重要と考えているか、どの工程に一番時間をかけて行うべきかという認識の表れであり、開発における根幹になります。それがメンバーそれぞれで微妙に違っていたという事実には驚かされました。そもそも、プロセスに関して、すべてのプロジェクトで万能なプロセスは存在せず、プロジェクトごとに決定する必要があります。今回は最後的に、全員の認識を基に以下のように定義しました。

• 「分析」とは、開発対象を理解すること。具体的には対象の持つ本質的な構造や動作の順序、平行性などについて検討し、分析モデルを用いて定式化する
• 「設計」とは、分析で得た知見に基づいてシステムの実現方法を決定すること。具体的には資源の配置方法をブロック図などで表現したり、使用するアルゴリズムの選択などを行う
• 「実装」とは、設計に従ってシステムを作成すること。設計における決定事項の質によっては機械的な実施も可能となる

　さらにHW／SW分割後に設計を行うためには、アーキテクチャメカニズム設計という作業が必要であるという認識に至りました。初期段階で議論した際には含まれていませんでしたが、現在はそれが必要であると考えています。アーキテクチャメカニズム設計とは、UMLを使用して分析を行ったモデルから設計を行うための工程で、とても重要な工程になります。最終的に決まった開発フローを図1に示します。

図1　開発フローの概略