UMLによるSoCシステム要求分析の可能性：SoC設計にモデリング手法を導入する（4）（1/4 ページ）
SoC開発におけるシステム要求分析で、UMLを適用するとどんなメリットが生じるのか。ノウハウや問題点などを紹介しよう
本連載の第1回「人海戦術よりスマートなSoC開発はないのか？」ではキャッツの塚田氏より、組み込みシステム開発に標準化された共通モデリング言語であるUML（Unified Modeling Language）を利用する利点、UML for SoCの話題（UML profile for SoC）の紹介などを行いました。この中で、UMTP（UMLモデリング推進協議会）のSoC分科会において3グループ体制で活動を行っていることが紹介されています。
これを受けて第2回「UMLでハード／ソフトの分割ポイントを見つける」では「ハードウェア／ソフトウェア分割グループ」の活動紹介、第3回「ハードウェア設計にUMLを取り入れるメリット」では「ハードウェア設計グループ」の活動紹介を行いました。第4回となる今回は、UMTP SoC分科会における3つ目のグループである「システム要求分析グループ」の取り組みを紹介します。
システム要求分析グループは、SoC開発の要求獲得・分析工程におけるUML適用技術に関する検討を進めており、この中でノウハウや問題点などを抽出することを主な目標としています。現在は、ほかのグループ同様、活動途上にあり議論が尽くされた段階ではありません。また、成果で公表できない部分も多々あり、本記事では多くを割愛させていただいています。特に図については、参考程度のイメージ図としてのみ掲載しています。
詳しい報告は、分科会活動が一区切りついて結論を得た、またの機会に譲りたいと思います。本記事を読んでご興味を持たれた方は、UMTPの活動に参加されてはいかがでしょうか。
SoC開発のシステム要求分析にUMLを用いる動機
UMLには、ご存じのようにさまざまな特色があります。例えば、ビジュアルな表現を基本としており、標準・共通表記であることなどから、可読性や開発者間のコミュニケーションに優れていること、高い再利用性があることなどです。ここでは、UMLの特徴や利点についての詳しい話は割愛しますが、まずはこうしたソフトウェアの分野で先行して普及しているUML特有の特色をSoC開発の現場でも生かしたいという動機が挙げられます。
すでに、SoC開発にUMLを利用する試みは存在し、多角的なアプローチで取り組んでいる事例が見られます。本連載の第1回で、UMLのSoC向け拡張プロファイルを紹介しましたが、このほかにも、例えばUMLのダイヤグラムを入力としたSystemCコードの自動生成ツールの開発などです。こうしたSoC開発におけるUML適用技術は、例年DAC（Design Automation Conference）のWorkshopでも取り上げられています。
ところが、SoCのシステム要求分析にUMLを利用した適用事例や研究報告が少ないといった現状があります。システム要求分析にUMLを利用すると、可読性の向上や再利用性などのさまざまなUMLの特色を生かすことができます。SoC開発にUMLを適用することで、ハードウェア開発者とファームウェア開発者の共通言語としてUMLの利点が生かされることも期待できます。さらに、後の開発工程へと自然に利用できる情報をUMLのダイヤグラムで表現すれば、要求獲得・分析の結果をアーキテクチャ設計に利用したり、後々検証に利用できる可能性があると考えました。
要求仕様に変更が生じたときに、要求仕様をUMLを用いて適切に、より網羅的に記述できていたとしたならば、該当するUMLダイヤグラムを修正するだけで、実装におけるプログラムコードの修正量を少なくしたり、検証データに反映しやすくできる可能性もあります。UMLによって、開発の初期工程での情報を検証に使えることは、開発期間短縮の観点からも非常に魅力的です。
そのために、まずシステム要求分析グループでは、以下の目標設定を行いました。
- システム要求分析にUMLでどのような表現を行えばよいのか（表現手法）を探る
- システム要求分析にUMLを適用するプロセスを探る
システム要求分析グループの目標設定
いずれも、すでに組み込みUMLとして知られているeUML（embedded UML、参考書籍：「組み込みUML―eUMLによるオブジェクト指向組み込みシステム開発」）をベースに検討を進めるのがよいと考えました。eUMLで使用されている表現やプロセスをSoC開発の工程で再現していく過程で、SoC固有の問題点が明らかになると考えたわけです。そして、この目標設定に沿い、このグループの短期的なゴールを、システム要求分析の結果を入力としたアーキテクチャ設計に生かす情報を整理することとしました。
ここで、注意しておかなければならないのは、SoCのシステム要求分析をUMLだけで完結しようなどと大それたことを考えないことです。たとえ通常のeUMLといえども、開発現場に浸透させるのは難しく大変です。UMLはモデリング言語（表記法）ですから、UMLの良いところだけを取り入れることを考えれば十分で、始めは仕様書や設計書のAppendixでも構わないのです。
UMLの苦手な分析とモデリング方法
SoC開発のシステム要求分析をするうえで、UMLだけでは完結できないと容易に想像できた分析として、まず挙げられたのがアーキテクチャ要求分析（非機能要求のまとめ）です。非機能要求を表現することはUML自体が苦手であるという認識ですが、今回の分科会での取り組みでは、非機能要求の表現手法の重要性を認識しつつも、この表現手法を開発するという方向では検討しませんでした。このことは、後のアーキテクチャ要求分析のところで補足します。
さて、実際のモデリングは、次に紹介する仮想のモデリングモチーフに対するシステム要求分析をUMLを用いて行いました。モデリングのベースとしたのはeUMLです。モデリングの過程で、分科会のグループメンバー間による意見交換を行いながら、ノウハウをまとめるという形で進めています。UMLのダイヤグラム記述は、手書きや市販のUML描画ツールだけを用いており、このほかの開発ツールは用いていません。
モデリングモチーフ
モデリングモチーフとは、UMLを用いてモデリング・トライアルをする題材として選択した、実際にありそうなSoCのことです。ここでは、デジタルカメラに使用される画像処理用のSoCを想定しました。
今回は、UMLダイヤグラムの詳細までは公表しない予定ですので、モデリングモチーフの詳細は省略しますが、実際のモデリングでは以下に挙げるような項目を詳細に仮定しました。
機能要求
- 信号処理・画像処理
- 現像処理
- メモリカード制御・記録処理
- 表示
- 撮影系制御
- USB通信制御
- etc.
信号処理・画像処理は、ノイズ除去やローパスフィルタなど。現像処理は、γ圧縮、ホワイトバランス、JPEG圧縮などです。撮影系制御には、AF（Auto Focus）、AWB（Auto White Balance）などを考えています。
非機能要求
- 高速性
- 低消費電力
- etc.
高速性は、起動時間や連写速度などを想定し、低消費電力ではバッテリー駆動時間などを考えています。
- 画像処理用SoCのブロック構成図
また、対象システムであるデジタルカメラに使用される画像処理用SoCのブロック図を仮定しました。このイメージ図を図1に示します。これは、あくまで一例で、SoCのブロック図を正確に記述したものではありません。例えば、USBの機能などは、この図では省いてあります。
ここではモデリングモチーフとしてどのようなものを取り扱ったのか、そのイメージがつかめればよい程度の簡単な説明にとどめています。
Copyright © ITmedia, Inc. All Rights Reserved.