UML and Platform-based Design

Abstract

この章では、組み込みシステムおよびプラットフォームの設計用のUMLに基づいた明細技術を示しています。それは、組め込みソフトウェア開発におけるプラットフォームサービスやそれらの属性を表すためのステレオタイプや拡張記法を含んでいます。また、それは、プラットフォームに基づいた設計法則に基づく、組み込みシステムのための設計方法論も示しています。

Key words: platform-based design, embedded system design, UML

1.INTRODUCTION

現在産業の中で使用されている組み込みシステム設計の取り組みは、システムの必要条件および機能性が通常自然言語で表現される初期段階では特に形式的ではありません。形式的でない仕様書に本来備わっているあいまいな表現は、設計が分割され、タスクが異なるチームに割り当てられる時に、システムの意味深長な分析を防ぎ、顧客との誤解や不正確で非効率的な決定に帰着するかもしれません。
　
　従って、よく定義された方法論における重要な成分は、純粋に概念のレベルから始まる抽象概念の多数のレベルにおいて、設計者が構造および組み込みシステムの振る舞いについて記述することを可能にする、という形式的に定義された意味論を備えた明細言語です。組み込みシステムは、しっかりとした実装およびコスト制約を満たさなければなりません。したがって、組み込みソフトウェア設計は、従来のソフトウェア開発と比較して、機能的な正確さを確認するだけでなくこれらの制約の充足のチェックが必要です。
　
　実装とコスト分析は選択されたアーキテクチャーに依存し、したがって実装プラットフォーム資源、およびそれらが提供するサービスの質の形式上の定義のためのツールおよびモデルが必要です。更に、設計プロセスの初期の段階では、システム明細を視覚化し、多数のチームメンバーが適切な情報を共有することを可能にする図式によるインターフェースツールを使う事によって利益を得るでしょう。

本章は、これらの問題に取り組み、UMLに基づく、組み込みシステムおよびプラットフォームの設計用の明細技術を示します。

１．１ Platform-based Design

プラットフォームに基づいた設計は、組み込みシステム設計中の常に増加する複雑さおよび取引する時間圧力によって引き起こされた問題を解決するために、1つの約束する取り組みとして最近出現しました。[1]によれば、プラットフォームは、後のより低いレベル抽象層(プラットフォーム)への多くの可能な詳細化を促進する設計フローの中の抽象層です。言いかえれば、プラットフォームは、設計目標としてアプリケーション設計者によって使用される実装可能な1セットの抽象的な表現で、プラットフォーム提供者によって実装されます。

図5-1の中で示されるように、プラットフォームに基づいた設計方法論の根本的教義は次のとおりです。
　１．仕様書の連続した詳細化が潜在的な実行の抽象的概念に中間点で遭遇　　　する場合の設計の取り扱い
　２．詳細化および抽象プロセスが起こる、正確に定義された層の識別
　その後、たくさんの層によって、より低いレベルの詳細から分離されるためにそれらで構築された設計ができるようになるが、最終的な実装の特性のかなり正確な予測ができるような設計空間の探索ができるように、抽象のより低いレベルで理解可能な情報を送信します。

設計フローにおいて既存の多くのプラットフォームの中で、2つの重要な抽象的概念が、システム定義と実装の間の接合ポイントで識別されます:(マイクロ)アーキテクチャー・プラットフォームおよびアプリケーションプログラムインターフェイス(API)プラットフォーム。 (マイクロ)アーキテクチャー・プラットフォームの概念は、シリコン機能性の独立して高度に発展したブロックのコレクションから組み立てられたのではなく、組み込みシステムのために使用された集積回路がいくつかの関連するマイクロアーキテクチャーに通常由来するという事実から起こります。従って、(マイクロ)アーキテクチャー・プラットフォームは、システム開発者によって、マイクロアーキテクチャーの特定の家族として定義され、おそらく、拡張したり縮小したり、という修正が可能な問題の特定のクラスの方へ適応されるでしょう。例えば、ANBA/ARMプラットフォーム、CoreConnectプラットフォーム、FPGAチップの族があります。プラットフォームの実例は、プラットフォームの集まりから1セットの構成要素を選び、配列をとることができる構成要素のパラメーターをセットすることにより、プラットフォームに由来することができます。プラットフォームの選択はコストおよび取引する時間の考察によって動かされ、アプリケーションおよびアーキテクチャー設計スペース両方の調査の後になされます。APIプラットフォームの概念は、組み込みソフトウェア開発者が、アーキテクチャーの詳細を隠し、プラットフォームが提供するサービスを定義するプラットフォームの抽象的概念を必要とするという事実に由来します。もっとはっきり言うと、APIプラットフォームは、アーキテクチャー・プラットフォーム内に含まれていた計算上の資源および利用可能な周辺装置の多様な抽象概念のためのプログラマのモデルです。そして、それはソフトウェア層によるアーキテクチャー・プラットフォームのユニークな抽象的表現です。この抽象は、通常、アーキテクチャー・プラットフォームの本質的な部品を包んでいるソフトウェア層からなり、特に、RTOSとデバイス・ドライバを含んでいます。例えば、VxWorksプラットフォーム、OSEKプラットフォームおよびOMAPプラットフォームのソフトウェアDSPタスク管理があります。APIプラットフォームの上には、特定のアプリケーションドメインで一般に用いられている機能性から成る、アプリケーション特有のプログラム可能なプラットフォームがあります。このプラットフォームは、通常組め込みソフトウェアの構成要素から成り、組め込みシステム設計者と直接相互に作用します。例えば、TCP/IPプラットフォームや、Nexperiaプラットフォームのトップレベルがあります。本章の範囲外である シリコン・インプリメンテーション・プラットフォーム(SIP)や、セクション４．４で議論されているネットワーク・プラットフォームのような他のプラットフォームもあります。

１．２　ＵＭＬ and Embedded System Design

ユニファイド・モデリング言語(UML)はソフトウェア開発をサポートするためにBooch、RumbaughおよびJacobson[2]によって導かれたオブジェクト指向のモデリング言語です。

　最近の研究[3、4、5、6]で、組み込みシステムデザイン用のUMLの可能性も示されました。多数の抽象レベルにシステム構造および振る舞いの捕獲およびビジュアル化を許可する、その豊富なグラフ式の記法およびそのモデリング能力により、UMLは、主として文書援助およびモデリング言語として組め込みシステム領域の中で使用されました。UMLは、広範囲のアプリケーションのために使われ、振る舞い、物質資源、時間のようなリアルタイムの組み込みシステムの最も適切な特徴をモデル化する能力をすでに組み立てているモデリング要素の豊富な１セットを含んでいます。しかしながら、下記要因も考慮されるべきです。

最初に、目標領域の基礎的な要素およびパターンを表わす、領域に特有な、より専門的記法を使用すれば、特定のアプリケーションのモデル化はより簡単でしょう。
　次に、形式的に定義された領域依存の使用意味論は、同じモデルの多数の解釈を回避し、かつ分析ツールを支援するために必要とされます。
　第3に、多数の図形は設計の関連する側面を捕らえるために使用することができます。異なる観点から同じオブジェクトを見て記述する可能性は、システム明細過程をより容易にするが、UMLの使用が正確な設計規律と結び付けられない場合、図形間の矛盾という結果をもたらすかもしれません。

これらの理由のために、組み込みシステム・プラットフォームの設計のような特定のアプリケーションドメインのためのUMLの使用は以下のことを要求します。
　・プロフィールと呼ばれ、基礎的なUMLの構造基盤に構築され、かつ、　　共通の設計要素およびパターンをモデル化するために、ステレオタイ　　プを使用して定義されたドメインに特有のビルディングブロックを含　　めた、ドメインの特定の言語。
　　・プロフィール記法が、いつどのように使用されるべきかを定義した方　　法論。

　　組み込みシステム・プラットフォームのためのUMLプロフィールは、性能やコスト面に対して主眼点をおき、構造およびプラットフォーム資源の振る舞いを表す特殊化した記法、およびそれらが提供するサービスを含むべきです。さらに、それは、迅速な比較を容易にする明細の多数の実装代案を視覚化する能力を持っているべきです。

本章の残りは以下のように体系づけられます。最初に、私たちは、関連する研究の概観を与えて、研究プロジェクトであるメトロポリスについて説明します(その内では私たちはコンセプト(セクション2)を開発しています)。次に、私たちは、ＵＭＬプラットフォーム（セクション３）と呼ばれる組み込みシステムプラットフォームのためのＵＭＬプロフィールおよびそれを使う為の方法論（セクション４）について説明します。最後に、私たちは無線のネットワーク・プラットフォームの設計にその実用的なアプリケーションを提示します。

２．BACKGROUND

２．１　Related work

オブジェクト・マネージメント・グループ(OMG)によって最近標準化され、11章の中で要約されているSchedulability、実装および時間（非公式にリアルタイムUMLプロフィールと呼ばれている）[8]のためのUMLプロフィールは、時間、スケジューリング、システムの実装様相を表現するための画一化されたフレームワークを定義します。それは、適切なクオリティー・オブ・サービス(QoS)パラメーターで注釈されたリアルタイムのシステムのモデルを構築するために使用することができる記法の１セットに基づきます。外部ツールは、これらのモデルに基づいた形式上の分析を実行し、システムが構築される前に、実行とschedulabilityについての情報を返すことができます。そのプロフィールは、資源、時間、一致およびschedulabilityパラメーターのモデル化のために記法を定義する一般化された資源モデリング(GRM)フレームワークから成ります。GRMに加え、サブ・プロフィールは分析の明白なタイプを特定する基礎的な記法の拡張を用いて定義されます。リアルタイムのUMLプロフィールは、モデリングと分析ツールの相互運用を支援するために拡張UML記法を標準化するが、この記法を使うための十分な方法論を定義しません。

UMLに基づいたいくつかの方法論が提案されました。それらはすべて、システムの動きおよび支援シミュレーション、および合成のデータ収集を許可する、正確な意味論を備えた形式上のモデルとUML記法を結び付けます。UML-RT[9]はシステム・コンポーネントを表わすために、カプセルと呼ばれる定形化された実行可能状態のオブジェクトを備えたUMLを拡張するプロフィールです。カプセルの内部動作はステートチャートを使用して定義されます。他のカプセルを備えたその相互作用は、ポートと呼ばれる定型化されたオブジェクトによって交換された信号のシーケンスを定義するプロトコルによります。カプセルは、実行から完成への意味論を持っており、それらの実行は入力ポートからのメッセージの受理で講じられる処置のシーケンスによって定義されます。UML-RTプロフィールは、正確な実行意味論を備えたモデルを定義するので、システムの動きおよび支援シミュレーション、あるいは合成ツール(例えば合理的なRose-RT)を収集することは適切です。UML-RTはアーキテクチャーと実行のモデリング能力を制限しており、したがって、OMGによって標準化されたリアルタイムのUMLプロフィールに補足的であると考えられるべきです。
　　HASoC[10]は６章で記述されたUML-RT記法に基づいた設計方法論です。設計フローは、初めにユースケース図の中で、システム機能性の記述から始まり、その後UML-RTバージョンの中で情報を図解する注釈を含めるために適切に拡張されます。著者は、カプセルの動作がステートチャートによって定義されるのでUML-RTが限定的すぎるモデルであると主張し、同時に起こるデータ・フローのような追加の計算モデル(MoC)にカプセルを関連させる代わりに、有限状態機械などの共同設計を提案します。UMLを使用する別の十分なシステムデザイン方法論はde Jongらによって示されます[4].それは、初期の明細過程から目標アーキテクチャーを指定する配備レベルまでのフローから成ります。ハイ・レベルのシステム明細は、ユースケース図を使用して、最初に構築されます。その後、システム・コンポーネントおよびそれらの相互作用はブロックダイヤグラムおよびメッセージ・シーケンス図をそれぞれ使用して記述されます。次のステップとして、各モジュールの動作は実行可能で実験することができる明細を提供するSDLを使用して指定されます。このアプローチは、SDLの形式上の意味論とUMLダイヤグラムの非公式の記法を組み合わせて、1ステップ移動し、さらにこれらの2つのモデル間の統合を促進します。

２．２　The Metropolis design environment    メトロポリス設計環境

メトロポリス[1]は以下の新しいアプローチを使用して、組み込みシステムデザインを取り組むUCバークレーで現在行っている研究プロジェクトです。初めに、メトロポリスは、特定のコミュニケーション意味論や発火している規則を前もって約束しません。従って、しっかりとした意味論の基礎(計算モデル)を持つ限り、設計者は自由に選択の明細メカニズム(グラフを用いたり、原文通りの言語)を使用することができます。第2に、それは、組み込みシステム、およびその環境や実装プラットフォームのいくつかの抽象的な適切な特性の両方を表わすために単一の形式を使用します。最後に、それは次のもののように、独立したアスペクトを分離します:

１．計算とコミュニケーション。この分離は重要です。なぜなら、
　　a) 計算の精製は、一般に手、編集、あるいは他の複雑な技術のスケジュ　　　ーリングか使用によって行われます。
　ｂ) コミュニケーションの精製は、一般にパターン(FIFO用の循環的なバッ　　　ファー、ハードウェアからソフトウェアへのデータの移項のための　　　ポーリングあるいは割り込みなど)の使用によって行われます。
２．機能とアーキテクチャー
　　　それらは、異なる設計チーム(例えば、マルチメディアアプリケーショ　　ンでのビデオの符号づけおよび解読のプロとハードウェアおよびソフ　　トウェア設計者)によってしばしば独立して定義されます。機能(計算お　　よびコミュニケーションの両方)は実装を受け継ぐためにアーキテクチ　　ャーに「図解され」ています。
３．待ち時間、スループット、パワー、消費電力のような動作と実装パラ　　メーター。

　　これらの分離は、例えば、低い層の実装詳細や特定のコミュニケーション・パラダイム、あるいはスケジューリングアルゴリズムへの与えられた機能的明細、といった別のやり方で結ぶ独立した状況を切り離すので、すべてより良い設計の再利用に帰着します。柔軟性および迅速な設計空間の調査のために、全ての抽象層に求められるような同数のアスペクトだけを定義することは非常に重要です。さらに、それらは、設計サイクルを促進するために、統合、システム層のシミュレーション、形式上の検証技術の広範囲な使用を許可します。

メトロポリスでは、システムがnetlistとして表わされ、さらにsubnetlistsや構成要素へnetlistを分解することができます。Netlistやsubnetlistの構成要素にはプロセス、メディア、ポート、インターフェース、制約および量が含まれています。プロセスは計算のモデル化のために使用されたactiveオブジェクト(自身のスレッドを通っている)です。メディアはコミュニケーションのモデル化のために使用されたpassiveオブジェクトです。インターフェース・タイプとして指定されたポートは、プロセスに存在し、コミュニケーションが可能なたった一つの場所です。インターフェースはすべて、およびポートを通って呼ぶことができるメソッドだけを宣言します。制約を正確に指定することができるように、量は動作を注釈します。

３．　UML PLATFORM PROFILE

３．１　UMLを用いたモデリングプラットフォーム

UMLプラットフォーム・プロフィールは組み込みシステム・プラットフォームの明細のためのグラフを用いた言語です。それは、組み込みシステムの構造および動作をモデル化し、また異なる抽象層のプラットフォーム間の関係を表わすために、Schedulability、実行、時間明細[12]用に標準のUML[2]やUMLプロフィールの中で定義されている記法に加え、ステレオタイプで特定化された明確なドメインの分類や関係を含んでいる。そのプロフィールは、いくつかの無線プロトコルのモデルおよび設計から受け継がれ、したがってこのアプリケーションドメインに特に適しています。

UMLプラットフォームの構造モデルは、定型化されたモデリング要素を使用するシステムおよびそれらの関係のコンポーネントを取り込みます。プラットフォームのモデルは、異なる抽象層にある他のプラットフォームに関係する場合は特に、異なるタイプ(例えば論理的な機能、ソフトウェア実装用コンポーネント、およびそれらを実行する物理的な資源用の配備ノードを表わすクラス)の要素のモデル化を必要とし、したがって特定のUMLダイヤグラムと同一のものと確認できません。

組み込みシステムの動作は、ユースケース、相互作用、State MachineおよびActivity図を使用すれば、異なる抽象層で取り込むことができます。ユースケース図は、システムが環境に全体として提供するサービスの抽象的な表現を提供し、相互作用図は、システム・コンポーネント中の相互作用を単に定義し、State Machine やActivity図は個々のコンポーネントの詳細なアクション層の動作の明細を許可します。システムの動作の指定は、システム・コンポーネント中の実行および相互作用の意味論を形式的に定義する計算のモデルを選び、かつコンポーネントの動作について記述することを要求します。セクション２．２で議論されるように、明細メカニズムは特定のMoCに前もって委託してはなりませんが、アプリケーションのために設計者に最も適切なMoCを選ばせるように十分に柔軟であるべきです。UMLプラットフォーム・プロフィールは、標準のMoCs(Kahnプロセス・ネットワーク、同期データフローなど)を表し、基本的に、バッファー、プロトコルなどMoCを指定するために使用することができるブロックを建てるステレオタイプを定義します。個々のコンポーネントの動作はグラフを用いて（State Machineや Active adiagrams）原文のままの記法を使用して指定されます。

UMLプラットフォーム・プロフィールの構文は、要素をモデル化する標準で定型化されたUMLのセットと、それらの使用および構成のための規則によって定義されます。UMLプラットフォームは、標準の分類および関係のためのUMLの規則に従い、新しく導入された記法のための構成規則を明示的に定義します。UMLプラットフォームの意味論は、UMLプラットフォームのモデル化する要素とMetamodelの要素の直接の一致の確立により、Metropolis Metamodel[11]で定義されています。

３．２　Stereotypes

　UMLプラットフォーム・プロフィールは次のステレオタイプを含んでいます。
＜＜Netlist＞＞
全面的なシステム構造を1セットのつながっているコンポーネントであると確認する、トップレベルのクラスです。

＜＜Resource＞＞
クラス、コンポーネント、配置ノードを特定化し、プラットフォーム・コンポーネントを表わすために使用されます。Resource属性(例えば幅、masterやslaveの数、仲裁政策のようなバス属性)は、タグの注釈により、あるいは対応するクラスの属性として指定されます。＜＜バス＞＞、＜＜メモリ＞＞、＜＜プロセッサー＞＞、さらに配備ノード用の＜＜Resource＞＞ステレオタイプを特定化し、物理的な資源をモデル化するために使用される。
　　　　　　　　　　　　　
＜＜Process＞＞
計算を実行する論理的なオブジェクトをモデル化するactiveクラス[2]です。

＜＜Medium＞＞
コミュニケーション機能を提供する論理的で物理的なオブジェクトをモデル化するクラスです。

＜＜Scheduler＞＞
共有資源へのアクセスの調整および仲裁を実行するオブジェクトやアルゴリズムをモデル化するクラスです。

＜＜Port＞＞
その環境を備えたその相互作用を許可する資源の一部を表わします。それが属し、それがアクセスを提供するサービスに関係している資源との総計の関係を持っています。

　　次のステレオタイプがUMLの関係を特定化します。
＜＜Communicate＞＞
結合関係を特定化し、情報を伝え合い、メッセージを交換するオブジェクトにクラスを関連づけるために使用されます。＜＜Communicate＞＞の関係は、特別のコミュニケーション・メカニズム(例えば、同時、非同期、バッファに入れる、バッファから取り出す)やMoC(例えばSDF、Kahnプロセス・ネットワーク、同期FSM、CFSM)を示すステレオタイプでさらに特定化することができます。

＜＜Implement＞＞
それを実装するサービスと資源の関係を認識する一種です。図5-2では、チャンネル資源がコミュニケーション・サービスの実装です。＜＜Refine＞＞は詳細のより優れたレベルで、それを表現するオブジェクトとオブジェクトの関係を実現するタイプです。