リンク

UML for Real
Design of Embedded Real-Time Systems

Chapter 7
Fine Grained Patterns for Real-Time Systems

Abstract:

デザインパターンは一般に生じる問題への一般化されたアプローチまたは解決策です。

デザインパターンは様々な状況の中の特定の種類の問題を効果的に解決するのに証明された解決策によって形成される設計専門知識を取り込んで分類する方法です。

この章ではリアルタイムシステムにおける共通した特定の種類の問題を解決するFine-Grained(細粒化)パターンがどのようなものか議論します。

これらおよび他の関連するパターンは参考事項の中から見つけることができます。

この資料の多くは、著者の本であるリアル・タイムデザインパターン(リアルタイムのシステム用の強健なアーキテクチャー)から適合されています。

1. INTRODUCTION

コラボレーションは構造の要素、および使用ケース振る舞いを達成するのに必要なそれらの関係を定義します。

パターンはいくつかの重要な基準を最適化するコラボレーションをともに配線する共通の方法を提供するために存在します。

機能的な問題がコラボレーション自体によって上書きされるので、デザインパターンは実行、メモリ使用法、再利用、強健さ、安全性あるいは信頼性のようないくつかのサービスの質の基準を最適化します。

すべての潜在的に有用なパターンの完全なカタログではなく、リアルタイムや組み込みシステムの開発者が直面したいくつかの特定の問題に的を絞ったパターンに関係するだろう。

リアルタイムシステムに役立つパターンのカタログは、より詳細である他のところ[2,3,4]に扱われます。そして、興味を持っていたリーダは、より完全な型のリアルタイム設計パターンのためのそこに委託されます。

経験を積んだ開発者は彼らが新しい問題に取り組もうとするとき、以前に作成されたか見られた共通した問題を含んだ何かを通常もった状況を見つけます。

その問題は同一ではなく、同一の解決法はめったに新しい問題を解決しないでしょう。しかし、それにもかかわらず、その問題は類似しているので、同様の解決法は恐らくうまくいくでしょう。

一般化され形式的になった”類似解決法”はデザインパターンと呼ばれた。

デザインパターンの作成は問題およびそれらの解決策の多くの特定の実例の類似性を抽象する問題です。

その後、発見され一般化された解決法は身近な新しい問題に適用することができます。

パターンに関連した3つの基本の関係のうち、1番目はパターンの適用と関係します。

その問題の性質を識別し、適用するべき最良のもののためのパターン「ライブラリ」を検討する問題は、パターンハッチング[10]と呼ばれます。

また、その優れた本の著者であるJhon Vlissidesの指摘によれば、この名前は、新しいものを作成していないが「基本より先に存在することから発展する」ことを暗示します。

それらの先在する基本は、私たちが斬新な状況で働く解決法を構築するために使用することができる捕らえられたデザインパターンです。

もちろん別の問題は、識別およびライブラリへ加えるべき新しいパターンの捕獲です。

この過程はパターン採鉱と呼びます。

それは、総括的な解決策を作成し、次に、パターンが当てはまる状況の問題中の解決策の結果を理解するというその本質的な特性の問題の抽象を含んでいます。

最後に、パターンは実証されるに違いありません。それは、それらは近々アプリケーション問題に適用されるに違いないからです。

これは通常パラメタライズド・クラスのパラメーターの例示化、およびパターン要素の特性を組み込むアプリケーション・クラスの修正といった一般化されたパターンの役割をもった特殊化されたコンビネーションです。

パターンは単なるソフトウェアの再利用ではなく、むしろある種の概念の再利用です。

この本の中で示したように、多くのパターンは設計と関係があります。

設計は常に分析モデルの最適化です。また、デザインパターンは常に特別の結果を備えた特別の方法で分析モデルを最適化する方法用の一般的な概念です。

最適化には常にいくつかの他の損失したシステム状況の改善を伴います。

例えば、いくつかのパターンは最悪の場合の実行を犠牲にして再利用を最適化するでしょう。

他のパターンはシステムの再発するコストを犠牲にして安全性を最適化するでしょう。

１つの側面を最適化する場合は常に、他のものを非最適化する必要がある。

これは生活における事実で、それ以外に私たちはすべてガソリンを使わず、０コストにおける完全な安全性の音速で運転しているでしょう。

1.1 What is a Design Pattern?

デザインパターンは「共通して生じる問題の一般化された解決策」です。

パターンであるほど、しばしばその問題は十分に有用で一般化できるものを繰り返さなければなりません。

その解決策は十分に広い適用領域に適用された一般原理でなければなりません。

それが一つの適用領域へ単に当てはまる場合、それは恐らく分析パターンです。

分析パターンはデザインパターンに似ているが、金融または航空宇宙のような特定の適用領域へ当てはまります。

分析パターンは、一つの適用領域内の特定のオブジェクト分析モデルにおける問題を組織するための方法を定義します。

領域内の特有の分析パターンのいくつかの例に関しては、[5]を参照してください。

分析は、設計はシステムがどれくらいよくその必要条件を達成しなければならないかによって営まれている一方、システムが行わなければならないことによって営まれている。

設計パターンは、一つ又は小さなQoSに関わるそれ自体の最適条件を改善するための設計のいくつかの側面を組織する方法です。

設計パターンによって最適化されるかもしれないQoSのうちのいくらかは次のとおりです:

●パフォーマンス　○最悪の場合　○標準の場合
●予測可能であること
●計画的であること
●処理能力　○標準　○持続　○バースト(大量にデータをまとめて伝送すること)
●安全性
●再使用可能
●分配可能
●可搬性
●保守性
●拡大・縮小性
●複雑性
●資源使用法(例えばメモリ)
●エネルギー消費
●再発するコスト(つまりハードウェア・コスト)
●開発の試みおよびコスト

もちろん、おおくのこれらQoS(利用するサービスに対して品質を考慮するもの)の特性はいくらかの矛盾の程度があります。

設計パターンは常に集中した目的(それは1つあるいはこれらのQoS特性の小さなセットを使い、他のものを犠牲にしてそれらを最適化すること)を持っています。

パターンは異なるレベルの抽象設計に適用されるかもしれません。

構造上のパターンは組織立った範囲を持っており、ほとんどアーキテクチャーの５つの見解(サブシステム構成、分配、安全性および信頼度、一致および資源管理、あるいは配備)に当てはまります。

しかしより狭い情況の中、次の設計抽象概念におけるレベルダウンで、機械的な設計パターンは同じQoSの特性を最適化して、個々の共同作業に適用します。

これは本章で扱ったそれらのように”きめの細かい”パターンとみなした抽象のレベルです。

パターンは通常、詳細な設計(制限された単一のオブジェクトあるいはクラスの最適化における範囲)に適用されません。しかし、イディオムと慣習は適用されます。

パターン文学は第1に構造のパターンに関係があります。

すなわち、行動戦略が望まれたQoSの最適化を適用することができるように、それらはシステムあるいはシステムの一部をある方法で組織することを要求します。

しかしながら、パターンは構造上である必要がありません。

Doing Hard Timeという本では、たとえば国の機械がどのような状態が機械を動かすのに最適かという行動設計パターンの方法を提供しています。

特にともにうまくいくために調整された、相互関係があったパターンのセットはフレームワークと呼ばれます。

フレームワークに基づいた開発作品では、大多数のアプリケーションが実証されたフレームワークによって提供されます。

これはアプリケーションの「中心部」を含んでおり、典型的にGUI要素の構成サービスを提供したり、装置を管理したり、状態の機械を実行したりなど...。

開発者はその後、それらのアプリケーションサービスを支援するためにフレームワークに依存して、特にそのシステムに特有のシステムの要素を構築する必要があります。

フレームワークは4つの主要な使用方針(例示化、一般化、パラメター化および拡張)を提供します。また、多くのフレームワークが4つすべてを使用します。

例示化使用法戦略は、変更なしで直接フレームワークのいくつかの側面を使います。(糸を縫うか、機械を動かすように)

一般化戦略は抽象的なフレームワーク要素をとり、問題に特有の機能性を加えて、それを特定化します。

リアルタイムのフレームワークは、特にあなたの特定の装置のためのこのセンサー・クラスを下位分類し、相続した方法に上書きするだろうという見込みを含んだモデルビューコントローラースタイル・パターンにふさわしいセンサー・クラスを提供するかもしれません。

これはパターンを使用する非常に共通の方法です。

あなたがフレームワークの一部分を例示する時、実際のパラメーターを供給する意図のあるパラメタライズド・クラス(他のクラスのテンプレートになるクラス)(C++のSTLの中のコンテナーのような)に供給する場合、パラメター化が適用されます。

最後に、ほとんどのフレームワークはあなたが一部を差込み、フレームワークを拡張することができる特別の場所を持っています。

この例ではCANバス通信プロトコルあるいはHDLC(ハイ・レベルデータリンクコミュニケイションズ)プロトコルを差し込むでしょう。

フレームワークの損失は、それらが、あなたが物事を行う方法を制限するということです。そして、フレームワークは、適用より設計し構築することがはるかに困難です。

しかしながら、いったん開発されると、それらはアプリケーション開発を非常に容易にします。

フレームワークはパターンを使うのに効果的な第1の例です。

1.2 Basic Structure of Design Patterns

ガンマによれば、パターンは4つの重要な側面を持っています:

・名前　　名前は「肩書き」あるいはパターンに参照を付ける手段を提供します。

・目的　　目的は問題情況、およびパターンが最適化するように求めるQoSの側面を提供します。
　　　　　目的は、パターンがとりわけ適切かもしれないところでの問題情況の種類を識別します。

・解決策　その解決策はパターン要素、それらの役割およびそれらの関係を含めて、パターン自体です。

・結果　　結果はパターンの使用の賛成および反対のセットです。

パターン名は私たちに2つのものを持って来ます。

１つ目に、それが私たちにパターン参照を付けることを可能にすることは明確で、存在する詳細を備えた明白な方法であるが、明言はされていなかった。

二つ目に、それは設計について話すためのより抽象的な語彙を私たちに与えます。

その命令”そのシステムは、ブローカー・パターンを備えた対称な配備を横切って分配された一致をキューにするメッセージを備えた階層状の構造のアーキテクチャーを使用する”はシステムにおける全面的な構造に関する多くの情報を持っています。なぜなら私たちはこれらのパターンの点から設計について議論することができるからです。

パターンの目的は、適切なパターンから要求された本質的な問題の論争に焦点をあわせる状態にし、QoSパターンが最適化を試みることです。

このセクションはその状況の下ではそのパターンが適切で、その状況の下ではそれが回避されるべきと指定します。

行程の解決策は最も重要な側面です。

それは、パターンにおける要素やそれらの互いの関係における役割を識別します。

私たちが次のセクションで見るように、これらの要素は使用されるか、取り替えられるか、あるいはパターンを実証するためにあなたの適用目的に合わせて下位分類されます。

別の上の1つのパターンを選択する場合、私たちがトレードオフを常に構成するので、結果は重要です。

私たちは、それを有効に適用するためにパターンの賛成および反対を理解しなければなりません。

賛成および反対は、これらの結果が当てはまる問題情況の入念な可能性と同様に、たいていサービスのいくつかの特質の改良あるいは低下によって表現された。

パターンはパラメター化された共同作業です。

すなわち、それはいくらかの要素あるいは役割がパターンの中で指定されない共同作業です。しかし、後になって完成し、それからパターンが適用されます。

UMLは依存関係がパターン役割を示しているパターンのために代役として破線の楕円形を使用します。

図7-1の中で示されるように、パターンの適用は例示可能な共同作業に帰着する役割にクラスまたはオブジェクトを供給します。

図7-1aでは、パターンがそれ自身定義されます。

破線の楕円形は、パターンの名前を提供し、パターン役割の依存関係を示します。

パターン内のクラスはパターンの構造の要素です。

所有者と要素のようないくつかのこれらの役割は、パターンが適用されている問題から来ます。

他にも、パラメター化されたコンテナーおよびコンテナー、この場合はパターン自体によって提供されます。

図7-1bは、パターンがどのように使用されるか示します。

上部は適用モデルからの共同作業(この場合小さなもの)です。

より低い部分は、コンテナパターンで入念に作られた共同作業を示します。

2 USING DESIGN PATTERNS IN DEVELOPMENT

私たちは、サービスの様々な特質に対する私たちの設計を最適化するために戦略を提供することにより、そのパターンが私たちを援助することについて議論しました。

今からパターンを使用することができる方法を調査しましょう。

パターンは3つの方法のうちの1つが使用されます。それらは捜し出されるか(パターンハッチングと呼ばれるプロセス)、あるいは設計専門知識(パターン採鉱)から捕らえられるか、適用されるに違いない(パターン例示化)。

2.1 Pattern Hatching - Locating the right patterns

あなたは設計問題に直面しています。

あなたは特殊な設計問題を解決するために利用することが出来るパターンをどのように見つけますか？

図7-2に示すようなマルチステップアプローチをお勧めします。

1. まず最初に、設計を始める前にパターンの学問に親しませる。

たくさんのアプリケーションドメインのパターンに忠実な多くの本、論文、Webサイトがある。（アプリケーションドメイン＝適応領域？）

それらパターンの多くは簡潔に記述され、その他のものは関係の中に与えられます。

一度アプリケーションドメインに関連しているであろうパターンを含むために語彙を増加させたら、設計の挑戦に立ち向かうためにより知識的な情報を持っている。

2. 線形思考を適用する。
　　
直面する設計問題の性質を特徴づけてください。

その問題(建築上か機械論か、それとも詳細か)の範囲は何ですか。

サービスの質の問題と何か関係があるのですか。

最悪のケース・パフォーマンスですか?再利用ですか?安全性ですか?可搬性ですか?メモリ使用法ですか?

厳密にそれらを並べてください。

時々、一旦あなたがこれをしたならば、設計解決策は浮かぶでしょう。

3. パターンマッチングを適用してください。

これは楽しい部分です。

あなたの大脳皮質は素晴らしいパターンマッチング機械です。

それは、あなたの線形思考処理から自主的に作動します。

このため、あなたはシャワーを浴びてベッドの準備をしているとき、または夕食を食べるとき「わかった！」という経験を持っています。

一旦あなたが線形思考のステップを適用したならば、あなたの無意識のパターンマッチング機械は、仕事に行くために十分な情報を持っています。

4. 「奇跡が生じます。」

パターンマッチング機械は、パターンの適用が通常、そのパターンは一般的な解決として明示的に公式化されたかあるいは否か、潜在的な解決策を識別します。

これは提案された解決策がよいものであることを意味しません。単にそれは、さらなる評価のために十分に密接した望まれた特性に一致します。

5. 提案された解決策を評価してください。

これは提議されたパターンを論理的に分析し評価するという線形推論の別の適用です。

もし解決策がよければ、それ(ステップ6)を適用し、もしそうでなければ、明らかにステップ3に戻るか、あるいは恐らくステップ2にでさえ戻ります。

6. パターンを実証してください。

パターンと調和するためにあなたの構造の要素を組織してください。

これは壊れているオブジェクトを別々にし、お互いそれらを合併し、共同作業責任を再び割り当てるか、あるいはお互いすべて新しい要素の導入を含んでいるかもしれません。(一般に”リファクタリング”として知られている名高いプロセス)

7. 解決策をテストしてください。

共同作業の要素を備えたあなたの分析シナリオを入念に作って、それらが機能的で行動の必要条件を満たすことを実証してください。

一旦共同作業が正しいことを行っていることを確認すれば、望まれたサービスの質の程度は、もし必要があれば、パターンがあなたのサービスの質における目標を成し遂げることを確実にする。

これは、実行と資源の使用法の目的においてはとりわけ真実です。

この測定は、モデルかシステム実行、シミュレーションあるいはあなたのニーズに依存する数学的分析によって行われるかもしれません。

2.2 Pattern Mining - Rolling your own patterns

特にあなたが特別なエリア内の最適化問題を理解するための経験の深さを持っており、および一般化された解決策へそれらを抽象するのに十分な解決策の一般的な特性を理解する十分な広さを持っている場合、自らのパターンの作成は有用です。

私たちはこれをパターン採鉱と呼びます(図7-3を参照)。

パターン採鉱は発明の問題というよりむしろ発見や抽象概念です。-ある情況中の解決策が別の情況での解決策に似ていることを理解し、解決策の詳細を遠方に抽象しているのを見ること。

有用なパターンであるために、それが異なる情況に生じなければならず、そしてサービスの質の1つ以上の有用な最適化を実行しなければならないことを心に留めておいてください。

2.3 Pattern Instantiation - Applying Pattern in your design

パターン具体化はパターン採鉱の反対です。

パターンの利点を獲得するために、それは特定の共同作業にパターンを適用しています(図7-4を参照)。

パターンは、通常オブジェクト共同作業に適用されます。

共同作業はオブジェクト(他のものでは、それらがサブシステムと要素のような大きな粒のオブジェクトかもしれない一方、ある範囲では、これらは小さなロー・レベルのオブジェクトかもしれません)の１つのセットです。

その目的は、パターンを備えたこの既に存在している共同作業を組織し、なんとかして作り出すことです。

あなたの設計中のパターンの適用または具体化は、アプリケーションにおける共同作業役割を遂行するであろう要素を定義する問題です。

パターンのうちのいくつかについては、パターンを具体化するサブクラスからスーパークラスとしての役割を作成するかもしれない。

他のパターンでは、要求されたオペレーションおよび振る舞いを加えて、パターン要素を適用領域からの一つと単に置換してもよい。

あるいは、まさにそれらがあなたの適用目的にサービスを提供するためのパターン自体に存在するように、オブジェクトの作成を選んでもよい。

トップページへもどる