システムエンジニアのためのモデリング心得 トップ10

その10 7 ± 2を忘れよ

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: システムエンジニアのためのモデリング心得 トップ10

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:システムエンジニアのためのモデリング心得 トップ10

このシリーズの続きに乞うご期待。

編集部より:

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を含む、ラショナル・グローバル・チームのメンバーと共に、ラショナル・ソリューションの普及とお客様へ提供する価値の向上に日々取り組んでいます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

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