　前工程において説明していますが、パフォーマンスなど予測性能におけるHW／SW分割は、実装を行い、評価をしなくては分からないという結論に達したため、いよいよそれまで封印しておいた設計、実装、評価を行った結果を参照することにしました。グループメンバーの著作物であり、本稿では、UMLの有効性を中心に記述しているため詳細結果は割愛させていただきますが、以下のパフォーマンス測定の結果について検討を行いました。

今回分割を行った際のパフォーマンス測定
すべてハードウェアで実装した際のパフォーマンス測定
すべてソフトウェアで実装した際のパフォーマンス測定

図4　機能確認および性能評価

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

　開発フローをもう1度参照してください。UMLを使用して分析したモデルから設計を行う工程で、アーキテクチャメカニズム設計はとても重要であると説明しました。今回は従来どおりの設計手法で行ったデータがあり、実際の設計工程は行っていないので、分析モデルから従来どおりのブロック図を作成し、設計が行えるであろうというプロセスで実行しました。しかしその後の議論の中で、やはり分割モデルと設計のひも付けを行うことは重要であるとの意見に達し、この部分について議論していくことが今後の課題であるのは間違いありません。

　議論の中で、分析まではUMLで行い、設計工程以降は従来どおりの開発手法を行えばよいとの意見もありましたが、分析から設計までをつなげる「何か」を見つけたいという結論に達しました。そのためには、現在以下の項目が考えられます。

ブロック図、プラットフォーム図などハード実装を行うためのメタモデルのようなものを作成する
USoCF（UML for SoC Forum）で使用した「UML for SoC profile」を使用し、さらに足りない表現があれば拡張させる
新たに足りないものについて検討し作成する

　UMLからハードウェアの設計に関しては、次回の「ハード設計グループ」の活動報告を参照してください。

活動を振り返って

　ここで最初に立てた目的に対して、どの程度達成したかを見てみましょう。



目的1	上流工程におけるHW／SW分割に関する指針を明確にし、決定要因とその要求資質の影響度に関する指針を明確にする
達成度	UMLによる分析を行ったことにより、HW／SW分割における無数のパターンが発見できた。分析方法についても明確になり、有効な手段の1つであると判断できる。上流工程において、パフォーマンス分析の予測性能を見いだせず、ここはNGであるかもしれない。しかし、1回目に仮分割を行い、性能評価を行った際には気付かなかったが、2回目に再度分割を行う際には分析モデルを基に議論できた。もし分析モデルがなかったら、ソースコードを基にして議論するしかなくなってしまうので、やはり分析モデルは有効であるといえる。また、再度検討を行う際に分析モデルはほとんど変更していない。ソースコードは、ハードウェア、ソフトウェアのどちらで実現するかによって形が変わってしまうが、分析モデルは普遍的に分析できる。逆にいえば最初にパフォーマンスにおける予測性能が明確でない部分についてこそ、分析モデルを作成し、分析することが有効であるともいえる



目的2	UMLを使用することの利点を明確にする
達成度	グループの活動は、1カ月に1度程度集まってレビュー＆ディスカッションを行うという形で進めてきた。UMLが標準化されており、皆の共通認識である点が一番の利点であると考えられる（レビュー効果）。また、分析モデルを参考にして、無数の分析パターンが明確になった（見える化）。そして、要求を満たすためのパフォーマンス分析を基にして、チューニングと実装を何度も繰り返す場合の再利用性の効果がある（再利用効果）。 UMLを使用したオブジェクト指向分析には効果があるといってよい



目的3	現在のプロセスに足りないものがあるとすれば、それが何かを明確にする
達成度	足りないもの、やはりそれは、アーキテクチャメカニズム設計において、分析モデルからハードウェア設計につなげるためのプロセスが足りないといわざるを得ない。アーキテクチャメカニズム設計での作業、プロセスを定義し開発フローをもう1度やり直す必要があると再認識させられた。やはり、ここに行き着いたという印象



最終目標	見積もりのための作業工程と精度に関する部分を明確にして効率化を図る
達成度	オブジェクト指向分析によりパフォーマンスなどの品質効果は明確であるといえるが、分析モデルを作成し分析することにかなりの時間（リソース）を費やした。そして、数多くの分析パターンから、最終的に1つのパターンを選択した。分析を行い要求に対する品質は良くなると思うが、それに費やした時間との費用対効果については、比較は難しく明確にはできなかった。これは実際のプロジェクトにおいて、同じスキルを持った人間が、従来の開発手法と、今回の開発手法を同時に実行して比較しない限り分からない。ただし、1ついえるのは、今回の開発手法が確立された後、ツールなどを用いた自動化や、トレーサビリティが行える個所が増えれば、将来的に開発効率が上がっていくのは間違いない

終わりに

　われわれはUMLからのSoC設計にこだわっています。その理由の1つに、ハードウェア開発でUMLを使用して開発が行われるようになり、このプロセスが完成すると、ソフトウェア開発者とハードウェア開発者はUMLという共通のドキュメントを基に開発できるというメリットがあるためです。ソフトウェアのプロセスにハードウェアをつなげて統合したいという思いがあるからです。それをぜひ実現したいのです。

　第2回の今回は「HW／SW分割グループ」の活動報告を紹介しました。第3回は「ハード設計グループ」、そして第4回は「システム要求分析グループ」の活動報告を紹介します。お楽しみに。（次回に続く）