ソフトウェアアーキテクチャって何なの？（前編）：The Rational Edge（3/3 ページ）

The Rational Edgeより：ソフトウェアアーキテクチャという比較的新しい分野について概説する。今回はシリーズの第1弾という位置付け。この分野のキーワードを説明し、優れたデザインのアーキテクチャが、導入された環境にどのように寄与するのかを探っていく。

[PeterEeles（レベル：初級 IBMシニアITアーキテクト），＠IT] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

アーキテクチャが構造を定義する

　「アーキテクチャ」とは何か、と誰かに説明を求めると、10人中9人は何らかの形で構造に言及する。建築や、橋などの各種土木工事との関係が語られる。これらには、動作、目的への適合性、そして見栄えまで、ほかにも特性はあるが、最も聞き慣れていて、最も頻繁に言及されるのが構造上の特性だ。

　従って、誰かに開発中のソフトウェアシステムのアーキテクチャを説明するよう求めると、アーキテクチャレイヤ、コンポーネント、あるいはディストリビューションノードなど、システムの構造面を示す図を見せられることになる。実際、構造はアーキテクチャにとって絶対欠かせない特性だ。アーキテクチャにおける構造の部分は、それ自身を見れば一目瞭然であり、その結果、アーキテクチャの大半の定義は故意に漠然としている。構造要素には、サブシステム、プロセス、ライブラリ、データベース、計算ノード、レガシーシステム、既製製品など、さまざまなものがある。

　アーキテクチャの定義の多くは、構造要素だけでなく、構造要素の構成、それらの関係（およびこれらの関係のサポートに必要なコネクタ）、そのインターフェイス、そしてパーティションも受け入れている。繰り返すが、これらの各要素はさまざまな形で提供される。例えば、コネクタはソケットであったり、同期もしくは非同期であったり、特定のプロトコルと関連があったりなど、さまざまなケースが考えられる。

　図1に構造要素の例を示す。この図は、注文処理システムを示す複数の構造要素が含まれたUMLのクラス図となっている。ここにはOrderEntry、CustomerManagement、およびAccountManagementの3つのクラスがある。OrderEntryクラスは、CustomerManagementクラスとAccountManagementクラスに依存することが分かる。

図1 構造要素を示すUMLクラス図

動作を定義するアーキテクチャ

　アーキテクチャは、構造要素に加え、これらの構造要素間の対話も定義する。システムの望ましい動作を実現するのが、これらの対話だ。図2は、連携させることで注文処理システムでの注文作成を可能にする多数の対話を示したUMLシーケンス図だ。ここには5つの対話がある。まず、Sales ClerkアクターがOrderEntryクラスのインスタンスを使って注文を作成する。そして、OrderEntryインスタンスがCustomerManagementクラスのインスタンスを使って顧客の詳細を取得する。すると、OrderEntryインスタンスがAccountManagementクラスのインスタンスを使って注文を作成し、注文に項目を追加して、発注を掛ける。

図2 動作要素を示すUMLシーケンス図（クリックすると拡大）

　図1に示されている依存は図2で説明されている対話から導き出せるなど、図2が図1と一致していることに注意されたい。例えば、OrderEntryのインスタンスは、図2に示された対話のように、実行中にCustomerManagementのインスタンスに依存する。この依存は、図1にあるように、対応するOrderEntryとCustomerManagementの両クラスの依存関係に反映されている。

動作を定義するアーキテクチャ

　アーキテクチャは構造と動作を定義するが、構造や動作の定義すべてについては考慮しない。考慮するのは重要だと思われている要素だけだ。重要な要素とは、長くいつまでも影響のある、絶対欠かせない動作と関連する主要構造要素や、信頼性やスケーラビリティといった重要な資質に関する要素などだ。アーキテクチャは、これらの要素の細かい詳細部分は考慮しないのが一般的だ。何かの代わりに特定の要素を検討するとき最大の要因となるのは開発や変更のコストであるため、アーキテクチャの重要性は経済的な重要性ともいい換えることができる。

　アーキテクチャは重要な要素にしか注目しないため、設計者に最も関連が深い観点という、特定の観点から検討中のシステムを見ることになる（注8）。この意味では、アーキテクチャは設計者が複雑性を管理するのを支援するシステムの抽象化であるといえる。

注8　これについては本シリーズの続きで説明する。

　重要な一連の要素が、静的ではなく、時間の経過に伴って変化することも注目に値する。要件を絞り込み、リスクを特定し、実行イメージソフトウェアを構築し、いくつかの教訓を学んだ結果、重要な一連の要素は変化する可能性がある。しかし、変化に直面したアーキテクチャの相対的安定性は、ある程度優れたアーキテクチャのしるしであり、うまく考えられた構築プロセスのしるしであり、優れた設計者のしるしだ。もし、比較的小さい変更によってアーキテクチャに修正を続ける必要がある場合は、良いしるしではない。しかし、アーキテクチャが比較的安定していれば、その逆は真である。

アーキテクチャは利害関係者のニーズのバランスを取る

　アーキテクチャは、最終的に利害関係者の一連のニーズに対応する目的で作成される。しかし、提示されたすべてのニーズに対応することは不可能な場合が多い。例えば、ある利害関係者が指定されたスケジュール内で何らかの機能を望んでも、これら2つのニーズ（機能とスケジュール）は互いに矛盾する。スケジュールに合わせて範囲を絞り込むか、スケジュールを延ばしてすべての機能を盛り込むかのいずれかになる。同様に、異なる利害関係者が相反するニーズを示す場合も適切なバランスを取る必要がある。従って、妥協は構築プロセスにとって絶対欠かせない側面であり、交渉は設計者にとって欠かせない資質だ。

　手近にある作業で簡単に説明するために、一連の利害関係者がかかわる以下のようなニーズを考えてみたい。

エンドユーザーは直感的かつ正しい動作、パフォーマンス、信頼性、ユーザビリティ、可用性、およびセキュリティに関心がある
システム管理者は、監視に役立つ直感的な動作、運用、およびツールに関心がある
マーケティング担当者は、競争力の高い機能、製品化に要する時間、ほかの製品との位置付け、およびコストに関心がある
顧客はコスト、安定性、そしてスケジュールに関心がある
開発者は必須要件とシンプルかつ首尾一貫したデザインアプローチに関心がある
プロジェクトマネジャーは、プロジェクトをトラッキングするに当たっての予測可能性、スケジュール、リソースの生産的利用、および予算に関心がある
保守担当者は、包括的で、首尾一貫しており、ドキュメントのそろったデザインアプローチや、修正の容易さに関心がある

　この一覧から分かるように、設計者にとってのもう1つの課題は、システムが必要な機能を提供することだけが利害関係者の関心事ではないことだ。一覧にある関心事の多くは、システムの機能に寄与せず、本質的には機能に関するものではない（例：コストやスケジューリングに対する関心など）。それにもかかわらず、このような関心はシステム品質や制約を表す。設計者から考えた場合、最も重要な要件が機能でないことは多い。

「The Rational Edge」バックナンバー