システムエンジニアのためのモデリング心得 トップ10: その4 デザインパターンは証明済みの解決策の再利用である

Bruce Douglassの心得トップ10シリーズのその4では、他の設計者たちの経験や知識を、抽象化もしくはデザインパターンの再利用という形で活用することについて考えてみましょう。

Bruce Douglass (Bruce.Douglass@us.ibm.com), Rationalチーフ・エバンジェリスト, システムズ・エンジニアリング, IBM

author photo組込みソフトウェア方法論者。トライアスリート。システムズエンジニア。UMLおよびSysML仕様開発コントリビューター。作家。黒帯。神経科学者。クラッシックギター奏者。高校中退。Bruce Powel DouglassはUSD(サウスダコタ大学)医学部より神経サイバネティックスの博士号を取得し、35年以上にわたる様々なハードリアルタイム環境のセーフティ・クリティカルなリアルタイム・アプリケーションの開発の経験を持っています。彼は5,700ページにおよぶ多くの技術書籍の著者で、Real-Time UML, Real-Time UML Workshop for Embedded Systems, Real-Time Design Patterns, Doing Hard Time, Real-Time Agility, Design Patterns for Embedded Systems in Cといった本を書いています。彼は、IBM Rationalのチーフ・エバンジェリストであり、システムズ領域のソート・リーダーでもあります。BruceはIBMの全世界の顧客に対してコンサルテーションや助言を提供しています。Bruceをツイッターでフォローするには@BruceDouglassです。



2013年 12月 27日

デザインパターンは、よく現れる問題に対する一般化された解決策の集まりです。すなわち、それらは、同じ問題に対するいろいろな異なるコンテキストでの解決策を集め、抽象化したものです。この抽象化では、コンテキストの個別の詳細は取り去られ、それにより新しいコンテキストでもその解決策を適用することができます。そして、新しい設計作業に取り掛かる中で、他の設計者の経験を生かし、証明済みである解決策を再利用できるのです。これはウィン-ウィンです。

例えば、医療用の薬物注入ポンプ(infusion pump)で閉ループ制御を行うために圧力と流量を扱うセーフティ・クリティカル・システムを考えてみてください。ここでは、システムを安全で正確なものにしたいものとします。さて、こういった目標を最適な形で達成する設計要素の構成方法はあるでしょうか。

パターン: 保護されたシングルチャネル

説明
コンポーネント群を直列の制御およびデータの変形ステップ列として構成し、エラーおよび安全性チェックをコンポーネント境界に配置する。
 
問題
コストに見合う形で障害に対する保護をする。
 
解決策
コンポーネント群を、エラーおよび安全性チェックを提供するための軽量の冗長性を持つ直列の制御およびデータの変形ステップ列として構成する。
 
結果
低い設計コスト、低い再発コスト、しかし障害発生時には動作継続はできないため、フェイルセーフ状態があることが必須。
 

基本的なパターンは、図1のようになります。コンポーネント群は直列の変換操作の要素(抽象的なデータ変換)として連結され、そのそれぞれは、妥当性や安全性の検査を追加することができるようにします。パターンを適用する際は、このモデル中の具体何々(Concrete…)となっている要素のところが実際の設計では置き換えられます。

図 1. 保護されたシングルチャネル・パターン
保護されたシングルチャネル・パターン

図2は、このパターンの適用例です。ここでは、圧力(pressure)および流量(flow)のセンサーコンポーネントが生データを送り込み、ポンプの位置が計算される前にそれぞれからのデータが移動平均(moving average)フィルタとバンドパスフィルタを通っていることが見て取れます。これらの変換には、それぞれについて以下のような検証すべき要素があります。

  • 圧力と流量は適切な制限の範囲内にあるのか
  • 計算された位置について前回の位置からの移動量が大きすぎないか

もしエラーが検出された場合は、警告管理部(Alarm Manger)に対して警告が通知され、担当している医師がこの問題を適切に扱えるようにします。そして、ポンプはフェイルセーフ状態(監視は継続するが、薬物注入は停止)に入ります。

図 2. 保護されたシングルチャネル・パターンの適用
保護されたシングルチャネル・パターンの適用

Harmonyプロセスでは、5つの主要なアーキテクチャのビューを特定しています(図3)。それらは以下のものです。

サブシステムおよびコンポーネント・ビュー
大きなスケール・レベルでのシステムの要素、その責務とインタフェース。
 
並列性(concurrency)およびリソース・ビュー
並列性ユニットの特定、それらのスケジューリング特性、ソフトウェア要素のこれらのスレッドへの割り当て、タスクの同期戦略と資源使用に関するポリシー。
 
配置(deployment)ビュー
機械、電子、ソフトウェアといった異なるエンジニアリング領域にまたがっての責務の割り当て。
 
分散(distribution)ビュー
処理ノード群にわたる分散情報収集、通信や協調のための技術やポリシーに関する意思決定。
 
ディペンダビリティ・ビュー
システムの実行中に如何に安全性、信頼性、セキュリティに関するシステムの一貫した状態が保たれるか。故障や攻撃の特定・分離・実行時の修正対応といったことを含む。
 

システムアーキテクチャというのは、とても重要な意味において、これらのクリティカルな領域のそれぞれにおける設計上の意思決定とパターンの総体になっています。

図 3. Harmonyでの5つの主要なアーキテクチャのビュー
the harmony architecture

これらのそれぞれ異なるアーキテクチャ視点でのデザインパターンは、私の書籍「Real-Time Design Patterns」 (Addison-Wesley, 2003年) や「Design Patterns for Embedded Systems in C」(Elsevier Press, 2011年)をご覧ください。

訳者について

三ツ井欽一は、東京ソフトウェア開発研究所に所属するラショナル・システムズ開発担当マネージャーです。この記事の著者のBruce Douglassを含む、ラショナル・グローバル・チームのメンバーと共に、ラショナル・ソリューションの普及とお客様へ提供する価値の向上に日々取り組んでいます。

参考文献

学ぶために

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=958138
ArticleTitle=システムエンジニアのためのモデリング心得 トップ10: その4 デザインパターンは証明済みの解決策の再利用である
publish-date=12272013