システムエンジニアのためのモデリング心得 トップ10: その8 ナプキン・モデルは会話を始めるには良い方法だが、締めくくるには最悪である

ナプキンの上に精密でない考えをスケッチするようなことをして、あえてシステムを失敗作にするようなことはやめましょう。システムエンジニアのためのモデリング心得シリーズその8では、軽量モデルから高忠実なモデルを目指すことを考えてみましょう。

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

今回の心得は、いつもすぐばれてしまうことですが、私がこの業界にて非常に広くみかけるモデリングの(誤)利用に関して持っている不満、すなわち、分析サポートにほとんど寄与せず、意味ある質問に全く答えられない、軽量で精密さに欠け、不適切で保守不可能なモデルの構築に関することです。たぶんおわかりでしょうが、私はこのようなモデリングを好みません。私は「高忠実な」モデルを好みます。これらは、(そのスコープと意図の範囲において)完全で、正確で、適切で、精密です。それらは検証可能な形でそのようになっています。(心得その1においてそのことについて少し言及する予定です。)

明確にしておきたいこととして、モデリングの価値は、我々がモデルの意図とスコープに関して「検証可能な形で完全で精密で正確」にできる能力の中にあると考えます。ナプキン・モデルは、その名のとおり、何かその辺りにあるものの上に手書きで書かれるということにちなんでいるのですが、UMLやSysMLが使われる場面としては、よく見かけるものです。しかし、モデルのこういった使用法は、概算の弾道計算でミサイルをプログラムするようなものです。どこかには着弾するでしょう。で、何か違いが出てくるでしょうか。あなたが着弾点側にいるとしたら、それは大きなものになると思います。

図 1. ナプキン・モデルは精密さに欠ける
ナプキン・モデルは精密さに欠ける

注: これはナプキン・モデルなので、ポケットに入っているかもしれないほかのナプキンに書いてある意味記述との整合性を確証するためのリポジトリがその下部にあるわけではありません。

このモデルへの質問として次のようなものがあるかもしれません。

  • このモデルは何を表現しようとしているのか?
  • これらは生徒やセミナーの全ての属性なのか?
  • この属性のデータ型は何で、その値の適切な部分範囲は何か?
  • この操作の引数と戻り値は何か?
  • セミナーへの参加資格をどのように決定すればよいか?それを決定するにはどんな情報が必要か?
  • これらの要素はどのように生成されるのか?それらはどのようにお互いリンクされるか?それらはどのように消滅するか?
  • セミナーが空か満席かをどのようにすれば言えるか?そのためにはどのような情報が必要が?属性MaxNumber: unsigned intが足りないのではないか?
  • これらの属性にはデフォルト値はあるのか?

私がナプキン・モデルを作っている人たちを葬り去ろうとしているように聞こえるかもしれませんが、そういうことではないのです。私は、これは会話を始める段階では優れた方法であると思っています。システムの構造や振舞いについて質問に答えたり推論をしたりしていく中で、このモデルを「ナプキン」から「高忠実」へと形態を変えていくのです。このモデルが、真のモデル・リポジトリを持つモデリング・ツールによって管理されていれば、このことは容易なことです。更に、このツールがモデル検証をサポートしていれば、一層容易になるでしょう。ハイエンドのツールであるRational Rhapsodyのようなものが、そのようなツールになります。

要するにまとめると、精密でない思考はシステムを失敗へと導くということです。私は、これは許容できないことだと考えます。

訳者について

三ツ井欽一は、東京ソフトウェア開発研究所に所属するラショナル・システムズ開発担当マネージャーです。この記事の著者の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=953948
ArticleTitle=システムエンジニアのためのモデリング心得 トップ10: その8 ナプキン・モデルは会話を始めるには良い方法だが、締めくくるには最悪である
publish-date=11292013