2011-04-15
全てのソフトウェアアーキテクトに必要な、2つのダイアグラム
この記事は、Peter Cripps氏による、「Two diagrams all Software Architects need 」を、ご本人の許可を得て翻訳したものです。*1
昨日の記事でも出てきたシステム・コンテキストと、アーキテクチャ・オーバービュー（スケッチ）についての短い記事です。
私は"パワーポイントによるアーキテクチャ"の大ファンではないが、パワーポイント（またはその他の描画ツール）によって作成される、役立つダイアグラムが2つ存在する。これらの２つのダイアグラムは、現在のプロジェクトの構造やスコープを説明するときにはいつでも、アーキテクトのポケットから取り出すことができなければならない。その2つのダイアグラムとは、システム・コンテキストとアーキテクチャ・オーバービューである。これらのダイアグラムは両方とも、重要なダイアグラムとそれを説明する叙述的な文章を含む、完全な成果物の一部として作成される。しかしながら、これらの成果物のキーとなるのは、ダイアグラムそれ自身である。
システム・コンテキストは開発対象となるシステムを1つのエンティティとして表し、そのシステムと外部のエンティティ（ユーザーや他システム）との、全てのインターフェースを識別する。
アーキテクチャ・オーバービューは、アーキテクチャにおける重要な構造上の、そしてもしかすると動的な要素に関する概要を提供する。アーキテクチャ・オーバービューは、誰かによって解釈され、そして実装されるような完全な仕様を意味するのではなく、むしろそのシステムの本質的な要素の、ハイレベルなビューである。このダイアグラムの主な目的は、ステークホルダーとのコミュニケーションのためである。
システム・コンテキストは本質的に、開発対象となるシステムの”ブラック・ボックス”なビューであり、一方アーキテクチャ・オーバービューは”ホワイト・ボックス”なビューである（つまり、開発対象となるシステムの、主なサブシステムと、コンポーネントを表す）。システム・コンテキストについて認識しておくべき重要な点は、それがシステムの境界を定義するということである；境界の外に存在する全てのものは既に準備されている、または他のプロジェクトによって提供されると推測されるのである。境界の内部に存在する全てのものは、新しいシステムを提供する、この開発プロジェクトの一部であることが仮定される。以下のダイアグラムは新しいクレーム処理システムの、典型的なシステム・コンテキストである。このシステムに対するアーキテクチャ・オーバービューがどのようなものとなるかは、読者への宿題としておこう（もしくは、この本のp195で、他の例を見ることができる*2）。
（以下、翻訳者によるコメント）
システム・コンテキストとアーキテクチャ・オーバービュー（アーキテクチャ概要と呼んだりもしますが）は、両者共にプロジェクトの初期段階で、アーキテクトが作成すべき重要な成果物です。
正直初めてシステム・コンテキストを見たときは、こんな単純なダイアグラムに何の意味があるんだろう、と思いました。しかしながら、システムのスコープ（何がスコープ内で、何がスコープ外か）や、システムと相互作用する外部エンティティの認識をあわせるためには、非常に役に立ちます。
また、本記事ではアーキテクチャ・オーバービューの具体例がありませんでしたが、どのようなものか知りたい場合には、例えば以下のようなサイトが参考になるかと思います。特に記法も決まっていないので、ステークホルダーとのコミュニケーションという目的が達成できれば、どのような書き方でもよいと思います。
- IBM notice: The page you requested cannot be displayed
- SSRS 2008 Architecture Slide « Bret Stateham's Blog
- AM Throughout the XP Lifecycle
システムアーキテクチャ構築の実践手法 (IT Architects’ Archive)
- 作者: ピーター・イールズ,ピーター・クリップス,榊原彰,西原裕善,吉田幸彦,五十嵐正裕,山本久好,金元隆志
- 出版社/メーカー: 翔泳社
- 発売日: 2010/12/03
- メディア: 大型本
- 購入: 6人 クリック: 106回
- この商品を含むブログ (5件) を見る
