システムエンジニアのためのモデリング心得 トップ10: その10 7 ± 2を忘れよ

システムエンジニアは、厳密さがより求められる状況に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月 15日

編集部より:

Rational developerWorksは、Bruce Douglassによる「システムエンジニアのためのモデリングの秘訣」を向こう10週にわたり毎週お届けします。Bruceは、この話題を提供することに関しては間違いなく最も適した人物であり、ユーモアを持ってお届けするでしょう…ですのでより一層楽しんでいただけるのではないでしょうか。これらの秘訣があなたのお仕事でお役に立てば幸いです。

はじめに

システムエンジニアリングは、この20年で非常に大きな変貌を遂げました。特に、システムエンジニアリングは、文章に基づいて分析結果を記述した文書から、より焦点を絞り厳密な分析を適用するためにシステムの本質的な特性を抽象化するモデルベースの方法へと移行してきました。これは、少なからず統一モデリング言語(UML)の普及、そしてそこから派生した同族の標準モデリング言語であるSystems Modeling Language (SysML)により後押しされたものということができます。私は、幸運にもこれら両方の標準に携わる特別な機会を得ることができました。長い経験を持つシステムおよび組込みのエンジニアとして、分析や表現に関わるシステムエンジニアの要望を(標準に対して)インプットしてきました。これにより、この言語を確実に「システムエンジニアリング実践のレベルを向上させ支えていく」という目的に適ったものにするために貢献したと考えています。

自分が従事してきた数十年において、私は小規模なインプラント可能な医療機器から遠距離通信システムやヘリコプター、宇宙船といったものまで様々なシステムに携わってきました。その中で作られていたモデルは、精度、完全さ、正確さ、価値といった面においてそれぞれ異なっていました。こういった経験やその多様性から、システムエンジニアリングにおいてモデリングがどういう場合にはうまく使え、またどういう場合には「それほど効果がない」(とでも言っておきましょうか)ということに関して強い考えを持つに至ったわけです。ここでは自分がトップ10だと信ずるソフトウェアエンジニアリングのための効果的なモデリングへの洞察を皆さんと共有したいと思います。


その10: 7±2を忘れよ

皆さん、これを聞いたことありますか?「全てのダイアグラム(図)は、7つ、もしくはそのプラス2、マイナス2の範囲の数の要素をもつべきである。」

その話はどこから来たのだろうと考えたことありますか?

1956年にGeorge Millerは、論文誌Psychology Reviewに「The magical number seven, plus or minus two: some limits on our capacity for processing information.」という論文を発表しました。これは刺激に基づく想起に関して2つの点を扱っています。一つは、「one-dimensional absolute judgment」と呼ばれるもので、1次元に変化するたくさんの刺激(例えば、大きさや色)を人間が識別し、前に学習した反応(例えば、ボタン押下)を結果として返す能力を計測したものです。もう一つの研究成果は、「memory span」すなわち、一度提示されその後隠されたものを想起する能力に関わるものです。偶然にも、そのどちらもが(50%の精度において)7つ、もしくはそのプラス2、マイナス2の範囲だったのです。

ここでの興味深い疑問は、「このことは、一つのダイアグラムに幾つ位のものを置くべきか、ということとどう関係するのか」ということです。

もちろん答えは、「全く関係ない」のですが。

覚えておいていただきたいのは、Miller博士が行った実験、すなわち、何かのリストを提示し、それを取り去り、そして少し間をおいて人々に記憶から空で答えさせるというものでしたが、それとは異なり、ダイアグラムの上のものはあなたが見ている限りはそこに留まって見えているわけです。

一方で、普通にあるようなサイズのモデルは数百から数千の要素を持っています。明らかにこれらを全部一つのダイアグラムに含めることはできるわけありません。ではどうすればよいのでしょうか。

Harmonyプロセスの著者である私は、次のように推奨しています: すべてのダイアグラムは、それぞれ単一の概念、あるいは単一の質問を表現したものであるべきで、その概念に関係した全ての要素を示すものである。これはダイアグラムの「ミッション(使命)」として知られているものです。

幾つかのダイアグラムは、とても明確なミッションをもっています。例えば、UMLやSysMLの状態マシンは、システムの中の一つのクラス、あるいは一つのブロックの状態によりの振舞いを表すものです。また、他のダイアグラムはもっと柔軟な使われ方をします。

例えばシーケンス図は、その使われ方として… 目的
あるユースケースの流れにおいてシステムがその環境におけるアクター群とどのように相互作用するかを示す 。 あるユースケースのあるシナリオに関わる要求を把握する 。
あるケースでの内部設計要素どうしがどのように相互作用するかを示す 。 内部の注目している部分でどのような協調が起こるのかを表す 。
期待される入出力間の変化の流れを定義する 。 テストケースを表す 。
ある特定のテストケースにおいてシステムがどのように振舞うのかを表現する 。 テスト結果を表す 。

クラス図あるいはブロック図は更に柔軟な使われ方をします。クラス図、ブロック図に共通のミッション・ステートメントは次のようなものになります。

  • ユースケースのような、より大きなスケールでの振舞いを実現する協調動作の構成設計要素を示す。
  • 要求から、構造化された要素やユースケースへの割り当てを示す 。
  • 汎化階層分類を表す 。
  • (「パッケージ図」と呼ばれる)モデルの組織構成を示す 。
    注記: :
    URLおよびSysML標準では、ダイアグラムの種別とダイアグラムの使用方法をあまりうまく区別できていません。タスク図は並列性に関するアーキテクチャを示す目的のクラス図であり、同様に、構造図はクラスの内部構造を示す目的のクラス図です。どちらもクラス図ということになります。
  • アーキテクチャのある側面を示す。例えば、
    • サブシステムおよびコンポーネント・アーキテクチャ
    • デプロイメント(配置)アーキテクチャ(それぞれ異なるエンジニアリング領域への責務の割り当て)
    • 並列性およびリソース管理アーキテクチャ
    • 分散アーキテクチャ
    • ディペンダビリティ・アーキテクチャ(安全性、信頼性、セキュリティを含む)
  • デザインパターンによる抽象を表す。
  • あるインスタンスのスナップショットを示す(「オブジェクト図」とも呼ばれる)。
  • ソフトウェア要素間のインタフェースを示す。
  • (異なる)エンジニアリング領域の間のインタフェースを示す 。
  • 構造を持ったクラスの構造を示す(「構造図」とも呼ばれる)。

このミッションの考え方は、それぞれのダイアグラムは「一つの質問に答える」、あるいは「一つの特定の論理展開を支持する」ものであるべきということを意味しています。私の経験によると、できの悪いダイアグラムのほとんどはミッションが明確でないか、あるいはたくさんのミッションを果たそうとしすぎているために失敗しているのです。

私は、ダイアグラムのミッションを明確にして、図中のコメントとして明確に記述しておくことを好みます。図1-図3は、その典型的な例を示しています。

図 1. ミッション: あるユースケースに割り当てられた要求を示すこと
あるユースケースに割り当てられた要求を示すこと
図 2. ミッション: あるユースケースを実現するために協調動作する設計要素群を示すこと
あるユースケースを実現するために協調動作する設計要素群を示すこと
図 3. ミッション: あるユースケースの一つのシナリオを示すこと(事前および事後条件を含む)
あるユースケースの一つのシナリオを示すこと

もちろん、このような考え方によれば同じモデル要素が複数のダイアグラムに現れる可能性もあるわけですが、何の問題もありません。良いモデリングツールであれば、モデルに関する全ての真実を一箇所にまとめた拠点として意味情報を保持するリポジトリを管理しており、いろいろなダイアグラムは、いつでもその真実のある一部分を表現したものになっています。

ここでは、私のリストのうちの10番目の心得を取り上げました。次週は9番目の、全てのモデルは抽象だが役に立つものもある、です。乞うご期待。

訳者について

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