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

[Peter Eeles，＠IT]

　前篇ではソフトウェアアーキテクチャーの定義を詳細に解説した。分かっているようで実は意外とあいまいなままだったソフトウェアアーキテクチャーの本質に少しは迫れたと思う。後篇ではソフトウェアアーキテクチャーの構造をさらに掘り下げる。

アーキテクチャーは論理的根拠に基づく判断を具体化する

　 アーキテクチャーで重要な側面は、最終結果だけでも、アーキテクチャー自身でもなく、なぜそのようになるのかという論理的根拠だ。従って、そのアーキテクチャーに結びついた判断と、その判断の論理的根拠を必ず文書化するよう検討することが重要だ。

　この情報は多くの利害関係者、特にそれがシステムを保守する立場にあるような場合に関係してくる。この情報は、くだされた判断に結びついた論理的根拠を修正しなくてはならない場合、不要な追跡作業を繰り返す必要がなくなり、設計者にとって役立つ。例えば、アーキテクチャーを審査したところ、設計者が下した判断を正当化する必要がある場合などにこの情報が利用される。

アーキテクチャーはアーキテクチャースタイルに準拠できる

　アーキテクチャーの大半は同様の関心を共有するシステムから取得できる。この類似点は、アーキテクチャースタイルだということができる。これは複雑でさまざまな要素を含むパターンでも、特定の種類のパターンだと考えられる（多数のパターンが一緒に適用される）。パターン同様、アーキテクチャースタイルも経験のコード化を示しており、設計者はこのような経験を再利用する機会を探すようにしたい。アーキテクチャースタイルの例としては、分散スタイル、パイプ＆フィルタスタイル、データ中心スタイル、ルールベーススタイルなどがある。1つのシステムに複数のアーキテクチャースタイルを提示する場合もある。Shawと Garlanは次のように述べている。

　［アーキテクチャースタイルは］構造構成のパターンによってシステムのファミリーを定義している。さらに具体的にいうと、アーキテクチャースタイルは、コンポーネントやコネクタタイプの表現形式や、これらの組み合わせに関する一連の制約を定義する。注9

注9　Mary ShawおよびDavid Garlan共著、「Software Architecture――Perspectives on an Emerging Discipline」、Prentice Hall 1996年刊

　UMLに関しては次のようになる。

　［パターンは］所定の情況における共通の問題に対する共通のソリューションである。注10

注10　Grady Booch、James Rumbaugh、Ivar Jacobson共著。「The Unified Modeling Language User Guide」。Addison Wesley 1999年刊

　スタイルは、通常はそれを利用するための論理的根拠の点（そのため考える時間が減る）や、構造や動作（代わりにスタイルを参照できるため、アーキテクチャー関連の文書を用意する量が減る）の点から文書化されているため、経験の再利用に加えてアーキテクチャースタイル（もしくはパターン）を適用することは、設計者の作業を多少楽にする。

アーキテクチャーはその環境の影響を受ける

　システムは環境の中に設置され、この環境がアーキテクチャーに影響を与える。これは、「文脈アーキテクチャー」などと呼ばれている。本質的には、環境がシステムの運用範囲を決定し、これがアーキテクチャーに影響を与える。アーキテクチャーに影響を与える環境要因としては、アーキテクチャーがサポートする企業使命、システムの利害関係者、社内の技術的制約（組織基準への準拠の要件など）、社外の技術的制約（外部システムとのインタフェースの必要性や、外部監督機関の基準への準拠など）がある。

　逆に、Bass、ClementsおよびKazman（注11）が雄弁に語っているように、アーキテクチャーもその環境に影響を与える場合がある。アーキテクチャーを作成すると、技術的観点から環境を変える（それを所有する組織に対して再利用可能な資産を与えるようなこともある）だけでなく、組織内で利用可能なスキルの観点からも環境を変える場合がある。

注11　Bassなどから引用

　ソフトウェアの比重が高いシステムに関しては、本章ですでに説明したように、環境には常に検討の必要がある側面がある。ソフトウェアが有益なものになるためには、それが実行できるものでなくてはならない。実行するためには、ソフトウェアは何らかのハードウェア上で動作する必要がある。従って、その結果生まれるシステムは、ソフトウェアとハードウェアの組み合わせとなり、信頼性やパフォーマンスなどの特性の達成を可能にするのがこの組み合わせだ。ソフトウェアは、それが動作するハードウェアを抜きにしてこれらの特性を達成できない。

　IEEE Std 12207-1995、IEEE Standard for Information Technology――Software Life Cycle Processesは、先に言及したIEEE 1471のシステム定義（ソフトウェアの比重が高いシステムを重視している）とは違った形でシステムを定義しているが、システムエンジニアリング分野における以下の定義とは一致する。

　［システムは］1つ以上のプロセス、ハードウェア、ソフトウェア、設備、そして人員によって構成される統合された合成物で、規定されたニーズあるいは目的を満たす機能を提供するものである（IEEE 12207）。注12

注12　IEEE Computer Society, IEEE Standard for Information Technology――Software Life Cycle Processes. IEEE Std 12207-1995.

　Rational Unified Process for Systems Engineering（RUP SE）のコンフィギュレーションにも同様の定義が含まれている。

　［システムは］企業が業務目標もしくは企業使命達成のために利用するサービスを提供する資源の集合。一般的に、システムコンポーネントはハードウェア、ソフトウェア、データ、および従業員によって構成される。注13

注13　Murray Cantor著。「Rational Unified Process for Systems Engineering」。The Rational Edge、2003年8月号.

　システムエンジニアリング分野では、ソフトウェア、ハードウェア、および人員の利用に関してトレードオフが出てくる。例えば、もしパフォーマンスが重要であれば、システムの特定の要素を、ソフトウェアや人員ではなくハードウェアでインプリメントする判断を下すことになる。もう1つの例は、顧客にとって便利なシステムを提供するためには、ソフトウェアやハードウェアでインプリメントされたものではなく、人間を顧客とのインタフェースとして配置する判断が必要になる。もっと複雑なシナリオになると、ソフトウェア、ハードウェア、そして人員の組み合わせによって一定のシステム品質を達成する必要が出てくる（従って、この一連の記事では、適宜ソフトウェア以外の要素にも言及する）。

　システムエンジニアリングがソフトウェアとハードウェア（そして人員）を同等に扱い、ハードウェアはソフトウェアの次に来るものでありソフトウェアを実行するための手段にすぎないと考えたり、ソフトウェアはハードウェアの次に来るものでありハードウェアを希望どおりに動かすための手段にすぎないと考える落とし穴を回避することを明確な主題にしている点は興味深い。