システムエンジニアのためのモデリング心得 トップ10: その9 全てのモデルは抽象だが役に立つものもある

システムエンジニアは、厳密さがより求められる状況にUML標準やSysML標準を採用するという形で対応をしてきました。これらの標準は複雑であり、これらの言語を使ってどのようにすれば最良にモデリング技法を適用して効果的に要求やアーキテクチャを明確に記述できるのか、あるいは、どのようにすればモデリングを使ってトレード分析やシステムエンジニアリングに必要なさまざまな分析を遂行することができるのか、といったことにガイドを提供しているわけではありません。Douglass博士は、30年以上にわたり何百ものプロジェクトに対してコンサルテーションを提供してきました。彼は、その知見や深い経験を、このモデルベース・システムエンジニアリングの心得トップ10リストの中で皆さんと共有します。

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年 11月 22日

人間の認知は、モデリングに関する研究分野といってよいでしょう。もちろん、そういったモデルの全てがグラフィカルなものというわけではないですが、間違いなく、人はモデリングをせずに考えることはできません。

モデルは、「もの」あるいは「もの」の集まりを抽象したものです。そこでは、答えを見出そうとしている問題や立証したいと思っている論理展開とは関係のない詳細を省くようにします。このことにより、目の前にある分析や問題と関係ある詳細に集中することができます。

例えば、図1のオフィス用椅子を考えて見ましょう。椅子のモデルは何から成っているでしょうか?

図 1. 椅子のモデル
椅子のモデル

そうですね。それはどんな質問に答えようとしているのかによって変わってくるでしょう。もしあなたが椅子を組み立てようとしているのであれば、そのモデルは部品や作業指示に関するものでしょう。もしあなたが風水でオフィス空間を設計しようとしているのであれば、色やスタイルが問題になるでしょう。もしあなたが小売業者であれば、コストや入手方法に注目するかもしれません。それらは何れも、それぞれの思考目的に応じた、理屈に適ったモデルです。

役に立つモデルを作成するためには、その前に答えようとする質問は何なのか、立証したい論理展開は何なのかを明確にしなければなりません。

ここでの心得のポイントは、役に立つモデルを作成するためには、その前に答えようとする質問は何なのか、立証したい論理展開は何なのかを明確にしなければならないということです。モデルを構築する前に、以下の質問に明確に答えられるべきです。

  • 私はなぜこのモデルを構築しようとしているのか?
  • このモデルのスコープは何か?
  • この モデルを利用するのは誰か?
  • 利用者がこのモデルに関してどのような質問を問うことが想定されているか?
  • 利用者がこのモデルでどういった推論を展開するのか?

これらの質問のそれぞれが、1つ、または複数のダイアグラムになっていきます。例えば、今、私が、あるシステム・アーキテクチャ・モデルを構築しようとしているとします。そこでは私は上記の質問に対して次のように答えるかもしれません。

私は、このシステムの大きな視点における部分、それらの部分への要求の割り当て、それらの間のインタフェースの定義、そして機械、電子、ソフトウェアそれぞれのエンジニアリング領域への責務の割り当て、これらに関して論理的に考察するためにこのモデルを構築している。

スコープ

このモデルのスコープは、大きな視点で複数領域を含むような要素(サブシステム)とその間のインタフェースを含むシステム・エンジニアリング・アーキテクチャである。これは要求モデルに戻るトレース・リンクと個別のエンジニアリング(機械、電子、ソフトウェア)モデルに向かうトレース・リンクを含む。

このモデルの利用者:

  • システムエンジニア
  • ソフトウェア安全性担当エンジニア
  • ソフトウェア信頼性担当エンジニア
  • セキュリティ・アナリスト
  • 要求アナリスト
  • メカニカル・エンジニア
  • 電子エンジニア
  • ソフトウェア・エンジニア

質問の種類

  • サブシステムはどんなものか?
  • サブシステムにどのように要求が割り当てられるか?
  • サブシステム間のインタフェースは何か?
  • システムは起こりうる故障にたいして安全か?
  • 重要なシステムの機能の信頼性はどうなっているのか?
  • セキュリティ対応策により保護されなければならないアセットは何か?
  • 想定されるセキュリティ脅威やシステムの脆弱性は何か?
  • 機械部(もしくは電子部、ソフトウェア部)にどんな要求が割り当てられているか?
  • ソフトウェアと電子部のインタフェースは何か?

想定される論理的考察

  • フォルトツリー解析のカットセット(ある危険の出現に関与する故障の集合)の分析
  • この設計が全ての要求をカバーしていることの提示
  • ある要求を満たすための設計要素が全て存在していることの提示
  • システムが目的を達成していることを検証するために必要なテストケース

訳者について

三ツ井欽一は、東京ソフトウェア開発研究所に所属するラショナル・システムズ開発担当マネージャーです。この記事の著者の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=953002
ArticleTitle=システムエンジニアのためのモデリング心得 トップ10: その9 全てのモデルは抽象だが役に立つものもある
publish-date=11222013