システムエンジニアのためのモデリング心得 トップ10: その6 モデルベースのハンドオフは忠実さを保存する

モデルや文章を下流のエンジニアリングへとハンドオフ(引渡し)するのを支える良いシステムエンジニアリングモデルを作り上げることを学びましょう。

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月 13日

システムズ・エンジニアリングから(機械、電子、ソフトウェアのそれぞれの領域のエンジニアリングを含む)下流のエンジニアリングへの典型的なハンドオフ(引渡し)は、文章で表現された要求の作成を含むものと思われます。これは大変な労力がいるというだけでなく、システム要求のときと同様、いろいろな問題をはらんでいます。

  • 精密性に欠けること
  • 完全性、正確性
  • 適切さ

せっかく良いシステムエンジニアリングモデルを構築しようとするのであれば、それらがモデルや文章のハンドオフをうまく支えるような方法で構築すべきです。図1は、Harmonyプロセスにおける下流のエンジニアリングへのハンドオフのためのワークフローを示しています。

図 1. システムズ・エンジニアリングからのハンドオフのためのHarmonyワークフロー
システムズ・エンジニアリングからのハンドオフのためのHarmonyワークフロー

このワークフローの中の2つのスレッドは、要素間の物理的なインタフェースを明記するためのものです。これは共有モデルと呼ばれているものです。その後、全てのサブシステムごとに下流のエンジニアリングモデルが作られていきます。

共有モデルは、複数のサブシステムにより共有されるかまたは参照される要素を含んでいます。これは、対象システムとアクターの間のインタフェースを含みます。また、それは、サブシステム間のインタフェースも含みます。このシステムエンジニアリングモデルの大半は論理インタフェースを明記したものです。しかし、この時点においてサブシステムは、これらのインタフェースの実際に意図された実装も参照しなければなりません。これは物理インタフェースと呼ばれます。図2の左側のワークフローは、論理インタフェース情報を物理インタフェース仕様へと翻訳します。そして、その仕様は構成管理の対象物として管理されるようになります。

図の右側では、まずサブシステムモデルが、その仕様をシステムエンジニアリングモデルから取り込みます。次に、そのサブシステムが寄与するエンジニアリング領域(例えば、機械、電子、そしてソフトウェア)のそれぞれに対して要求の割り当てが行われます。幾つかの要求は、単純にある1つの領域に割り当てられるかもしれません。ある要求が、異なるエンジニアリング領域での要素の何らかの組合せにより実現されるということも、またよくあることです。もともとの要求は必ず導出された要求へと分解され、導出された要求は更にある単一のエンジニアリング領域へと割り当てられたりします。私がこの目的のために一番良く使うのはブロック図で、ソフトウェア、機械、電子というように本質的に排他的であるブロックを識別するためにステレオタイプや命名規則を使います。そのようにして、要求は簡単にこれらの要素へと割り当てることができます。

図 2. サブシステムから異種のエンジニアリング領域の要素への分解
サブシステムから異種のエンジニアリング領域の要素への分解

また、異なるエンジニアリング領域の要素の間、例えば、ソフトウェア-電子間のインタフェースを定義することも重要です。こうすることで、そのインタフェースの両側に位置するエンジニアが共通の期待値を持つことができます。この目的で、私はUMLやSysMLのタグ付き値という機能を使います。タグ付き値により、モデルにとって重要なメタデータを定義することができます。ソフトウェア-電子間のインタフェースの場合、これは以下のようなものを含みます。

  • インタフェースのタイプ(例、メモリマップ方式、ポートマップ方式、割り込みマップ方式)
  • インタフェースの構造
  • タイミング情報

ソフトウェア-電子間インタフェースの仕様記述が図3に示してあります。

図 3. ソフトウェア-電子間のインタフェースの仕様記述
ソフトウェア-電子間のインタフェースの仕様記述

モデルのハンドオフのワークフローが完了すれば、本当の下流のエンジニアリングを始めることができます。

訳者について

三ツ井欽一は、東京ソフトウェア開発研究所に所属するラショナル・システムズ開発担当マネージャーです。この記事の著者の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=956327
ArticleTitle=システムエンジニアのためのモデリング心得 トップ10: その6 モデルベースのハンドオフは忠実さを保存する
publish-date=12132013