=========================================================================== セッションB2　DAS/SWEST共同招待講演 「UMLを用いたシステムのモデリング方法」 浅利　康二氏（CATS） 会場：Ａ会場 人数：150名程度 =========================================================================== ======== 講演内容 ======== 　・システム設計の現状と問題点 　・UMLからシステムLSIへ 　・UMLの基本的な説明 　・提案する設計プロセス 　・UMLからSpecC、SystemCへ変換する際の例題 　・まとめ ========================== システム設計の現状と問題点 ========================== ○組込みシステムの大規模・複雑化してきている 　・設計品質が問題となってきている。 　・頻繁な仕様変更に耐え得る設計が求められる。（TATの短縮） ○H/W設計者とS/W設計者間のギャップ 　・S/W設計者はトップダウン志向で機能重視 　・H/W設計者はボトムアップ志向で性能重視 　・しかし！それだけではない(ツール間や考え方など) ○S/W設計者からみたシステム設計の変化 　・オブジェクト設計志向を取り入れる動き 　　（UMLを実際にSW実装設計に用いることでシステムの大規模化・複雑化に 　　　対応） 　・オブジェクトの再利用の推進 　・今後、組込みの分野にUMLが浸透していくには、UMLから実装設計への設計 　　プロセス(手順)と変換規則が重要（例:UML->C,Javaへ)となる。 　　　※MDAの分野となり、MDAは各社の設計ノウハウになる。 　・LSIは高速化に必要な部分に用いる単なる部品である ○システムLSI設計者の観点から 　・S/W-H/W混載のシステムの検証をしたい 　　　Cベースの設計言語(SpecC/SystemC)にシフトしつつある 　・システムLSIの大規模化・複雑化 　　　機能モジュールをIPとして再利用の促進 　・システムLSIにおけるS/Wの比率の増加 　　　RTOSなどのS/Wの知識を必要とされる ○システム設計の流れ 　・S/W設計 　　　UML -> C++ -> RTOSへの実装 -> ロードモジュール 　・LSI設計 　　　要求仕様文書 -> SystemC/SpecC -> Verilog/VHDL -> 　　　　（続き）ネットリスト -> レイアウト 　・両者間( S/W設計者、 LSI設計者)にはギャップがある 　・問題点 　　　LSI設計者は、C言語ベースでS/Wとのコデザインを行いたい 　　　S/W設計者は、SpecC,SystemCなどの言語を覚える事ができない 　　　LSI設計者は機能検証を簡単にしたい ==================== UMLからシステムLSIへ ==================== ○UMLからシステムLSIへ 　・UMLは、今後の標準の仕様表記方法になる。 　・UML->S/W実装設計へのツールは存在している。 　　　H/W設計もUMLから行うべきである。 　・UML->LSIの流れを確立する事で、S/W設計とH/W設計を融合させる事ができ 　　る。 　　　その為に、CASEツールとEDAツールのギャップを埋めたい。 ○UMLからのシステム設計 　・重要ポイント 　　　UMLからSpecC、SystemCへ落とす技術 　　　モデルドリブンアーキテクチャなどのノウハウ ○動くシステム仕様書 　・アーキテクチャ間のマッピング方法、システム設計で行う 　・詳細化する際には、SystemCで詳細化を行う 　　　常にUMLへ反映するように 　　　　シミュレーションはSystemCで記述 　　　　仕様書はUMLで記述 　・UMLによる要求仕様書とSystemCのコードは等価なモデルにする。 　　　→ UMLの要求仕様は、SystemCのコードで充たされる。 ○UMLは要求仕様書 　・UMLは常に要求仕様書として使う 　　　SystemC、SpecCを主体とすると、読めない仕様書になってしまう 　・シミュレーションなどを行うときには、シミュレータを使う 　　　SystemC/SpecC検証エンジンで検証を行う 　　　UMLとSystemC/SpecCの結果を見せる事で検証を行う ○SW設計者にやさしいシステム設計・検証 　・SW設計者に、HWを含めたシステム検証を可能にする 　　　LSIの機能をSystemCで記述することで、SW設計を容易にする。 ○UMLからのシステム設計のメリット 　・仕様変更に強い 　・設計工数削減 　・仕様の把握ミスによるバグの削減による品質の向上 　・LSIの機能をIP化してツール上で利用できるようにする事で、仕様設計者 　　にとって不可欠なものにできる。 　・上流設計からシステム設計を意識するので、SW設計者に使いやすいLSIを 　　開発できる。 　　→H/WのIPのAPIを仕様作成時に再利用できるため、システムLSIの設計効率 　　　が向上する。 ○システムLSI関連情報 　・富士通(株)がシステムLSIの設計期間を従来の1/2〜1/3にする手法を提案 　　　今後1年でこの設計手法に全面移行する 　　　仕様の漏れによる設計変更の工数を大幅に削減 ○日本のシステムLSI技術 　・強力なセットメーカとLSIメーカが存在 　・両者が協力してMDAのノウハウを確立するべき 　　　コスト削減、短TAT、高品質なLSIの提供 　・システム設計支援ツールも不可欠 　・日本の技術を生かしていれば・・・ ○今後のシステム設計に何が必要か？ 　・UMLからシステム実装までのプロセス提供 　・要求仕様から各言語への変換規則(MDA) 　　　今後システムLSIからOMGへの提案をしていくことも視野に ○機能検証の技術の必要性 　・機能検証も重要になってくる 　・SCAN、JTAG技術により製造不具合の検証が容易に 　　　JTAGはCPU上のSWデバッグにも使用されている 　・機能検証を容易にするには？ 　　　UML→システムLSIへの流れ＋ツールの確立 　　　各設計工程間の機能の等価性を証明する技術の確立(形式検証) 　　　　SWの分野では難しい(空間が広いので、ある切り口から)。 ○形式検証技術 　・以上のことが実現すると、自然言語やUMLからHWに落とす事ができる 　・ツールが自動化できて、機能検証・工数の削減が実現するといいが 　　なかなかここまでいかない 　・最初にUMLからせめてHWに落とす事ができれば・・・ 　・要求仕様を決める所と実装設計するところにギャップがある ================= UMLの基本的な説明 ================= ○UML(Unified Modeling Language)とは 　・S/Wの青写真を描くためのモデリング言語として発展 　　　OMG(Object Management Group:SW業界の標準化団体)によって標準化が 　　推進されている。 　・設計の方法論を指定するものではなく、アプリケーションの記述やモデル 　　化に使用できる一連の表記法を提供。コーディングは別途行う必要がある。 ○MDA(Model Driven Architecture)とは？ 　・プラットフォームに依存しないモデルと、それを実装するミドルウェアと 　　を分離するもの 　　（例：UMLモデルから実装するプラットフォーム(システムLSI→SystemC/SpecC) 　　　へのマッピング） ○UMLでの表記法 　・ユースケース図：システムのプロセスとと外部の関係を表す 　・静的構造図 　　　クラス図：アプリケーションに含まれるクラスとクラス間の関係を表す 　　　　　　　　スマートに表現する事で要求仕様での分析がし易くなる 　　　オブジェクト図 　・相互作用図 　　　シーケンス図：特定のオブジェクト間の関係を表す 　　　コラボレーション図：簡単なオブジェクト図とシーケンス図を合わせたよう 　　　　　　　　　　　　　なもの 　・状態図 　　　状態図：1つのオブジェクトの状態がどのように変化するのかを詳細に示す 　　　アクティビティ図：特殊なタイプの状態図 　・実装図 　　　パッケージ図：クラスがどのようにモジュール分割されるかを表す 　　　コンポーネント図：コードが実際にどのモジュールに分割されるかを表す 　　　配置図：物理的なアーキテクチャを表す ○eUML 　・オージス総研、キャッツ、ソニー、松下電器からボランティアベースで S/W 　　開発プロセスを標準化しようとしている動き ○eUMLの開発プロセス 　・要求分析→分析→アーキテクチャ設計→設計→実装 　・分析：eUMLでは重要。仕様をきれいな形で出す。 　・アーキテクチャ設計：SWのプロセス。C++を使って設計を行う。 　・テスト：分析の段階でテストデータを出す ○UML→システムLSIへの実現 　・現在はSW側への流れが実現している。 　　　UML→ UML&C++ 　・HW側の実現については、システム設計をもう少し詰めなければならない ○UMLからPLC実装例 　・上流はeUMLで記述 　・C++＋μITRONでSH4に実装 ==================== 提案する設計プロセス ==================== ○「UML→SystemC」設計プロセス 　・ユースケース分析 　・ドメイン分割 　・システム構成(ドメインのアーキテクチャへのマッピング) 　・クラス図の抽出、インスタンス図生成 　・動的分析の後、並行性の抽出 　・モジュールへ変換し、アクティブモジュール間にチャネルを挿入 　・シーケンス図、コラボレーション図からテストベンチを自動生成 　・詳細設計を行い、テストベンチを用いてシミュレーション 　・性能見積もりによるSW/HW分割 　・スケジューリングによる最適化 　・SystemC/SpecC/C++コード生成 ○分析から設計へ 　・分析（UML）とシステム設計(SystemC，SpecC)間のマッピング 　　　ユースケース図　　　−　外部入出力ポート 　　　配置図　　　　　　　−　システム構成 　　　クラス図　　　　　　−　モジュール 　　　オブジェクト図　　　−　モジュール 　　　状態図　　　　　　　−　モジュールの振る舞い 　　　アクティビティ図　　−　モジュールの振る舞い 　　　シーケンス図　　　　−　テストベンチ 　　　コラボレーション図　−　テストベンチ ○ドメインの分割 　・画像処理においては、画像処理用ドメインやUIのドメインに分割 　・ドメイン間の依存関係を少なくする ○システム構成(ドメインのマッピング) 　・IPライブラリなどの既存の資産を利用する事が多くなる。 　・どのような構成にするかは、早い時期に決まる（DSPやASICの使用など） ○クラスの抽出 　・エンティティ(システムの要となる部分)の抽出 　・コントロール部分の追加 　・アクティブクラスの決定 　・並行性の抽出 ○クラス図をインスタンス図へ 　・クラス図のみだと機能となってしまうので、実際のオブジェクトにしないと 　　ならない。例えば、 2つのタイマが存在する場合は、あらかじめタイマクラ 　　スを作り、そこからタイマ1、タイマ2のインスタンス生成を行う必要がある。 　・アクティブなスレッド同士間は、同期を取るためのチャネルが必要 　・関数呼び出しのみの場合は、チャネルは不必要 ○動的分析 　・クラスの同士の動作を分析 ○チャネルの挿入 　・2つのチャネル間にチャネルを実装する場合は、インタフェースとして実装 ○状態遷移設計 ○階層化 ○OSラッパー 　・OSを入れる場合には、ラッパーを入れる必要がある 　・OS固有の機能を使用する場合に挿入する ○UML→SystemCへの変換方法 　・メタモデル変換：MOF(Meta Object Facility：演算などの意味を定義) 　　　UML、SystemCそれぞれでメタモデルを定義して、それに基づき変換 　・プロファイル拡張 　　　ステレオタイプによる拡張 　　　　ステレオタイプを書く事で、SystemCへの変換が可能となる ============================ UML→SystemC/SpecC変換の例題 ============================ ○バスインターフェース 　・SystemCリファレンスコンパイラに付属するドキュメント中にSystemC記述 　　がある。 　・図(UML)で表すと非常に簡単だが、SystemCで書くと大変で一目で解らない。 　　　UMLは見やすいことは見やすい。仕様書として非常に使える。 ○USBシステムをSpecC言語で記述 　・システムの説明する時に、SpecCで記述しても図で説明する事になる。 　　　使用している図は標準のものではない。 　　　UMLで記述する事により、誰もが見ることができる。 　・物理的な配置 　　　 UMLの配置図を使用して CPUや USBデバイスの配置を行い、その中に機 　　　能を入れる。 　・設計詳細化によるチャネルの挿入 　　　設計フェーズで、 2つのクラス間にチャネルがある場合は、ポートとイ 　　　ンタフェースを通してチャネルへアクセスする。その場合に分析の段階 　　　では2つのチャネルを結ぶだけにとどめ、設計フェーズで詳細化する。 ====== まとめ ====== 　・UML で記述された要求仕様からシステムLSI 設計への新しい開発プロセス 　　を提案することで、 S/W-H/W設計の融合の可能性を示した。これらの実現 　　により、仕様変更への強化、設計工数削減、設計品質の向上につながる設 　　計の流れができるのではないか。 　・UMLからシステムLSI設計(SystemC，SpecCなど)への変換ルールが重要(OMG 　　でいうところの MDA)となり、今後のノウハウとなる 　　　※セットメーカやベンダーも巻き込んで日本のシステムLSI技術を世界に 　　　　発信できれば良いのではないか。 　・今後の課題 　　　システムLSI向けのUMLの書き方をある程度規定する必要がある 　　　システムLSI向けメタモデル(プロファイル)として、OMGへの提案・標準化 　　　　eUML SoC WGの発足 　　　設計事例実績作り ========== 質疑・応答 ========== Q:UMLでデザインする場合に、本当の仕様は仕様を書く人の頭の中にあるが、 　UMLに書き落とした時に、全ての仕様が入っているということをどう検証 　するか？ A:仕様の確認はSystemCで動かして検証を行う。UML単体での検証はできない。 Q:そこで変更を行わなければならなくなった際に、UMLと詳細設計の変更を行 　う事は、手戻りにつながり、本来の目的から外れるのではないか？ A:UMLを記述する段階で、要求仕様を最初に全て入れなければならない Q:UMLを使ってC++のSWに落とす場合に、シミュレーションはC++で行う事にな 　る。UMLの図のみで検証する事はできないのか？ A:検証はC/C++を用いるのは、UMLの図だけでは動的な部分が分かりにくいから。 Q:変換の対象としてSystemC、SpecCを選んだ理由は？ A:機能検証の面で選択している。VerilogやVHDLに落とすと、機能検証に時間 　がかかる。 Q:マルチベンダで設計を行う場合における仕様情報の更新はどのように行えば 　よいか？ A:複数の会社で回す場合は、要求仕様をリファインするのは第3者が行った方 　が良い。 Q:UMLを特定のSWツールベンダに依存しない電子フォーマットにするには？ A:XMLなどを用いれば特定のSWツールベンダに依存しないコードになる Q:変更履歴をどのように管理するのか？ A:CASEツールでバージョン管理の機能がある ==== 感想 ==== 講演の内容は、現在注目が向けられているシステム設計の現状・問題点から始まり、 UMLからシステムLSIへの手法について、特にUMLからSystemC,SpecCへの変換手法に 重点おいて解説されていた。質疑・応答では仕様と実装の関連について注目が向け られていた。比較的活発な意見交換が行われていたと思う。 以上