ソフトウェアアーキテクチャって何なの?(後編)The Rational Edge(1/2 ページ)

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

» 2006年03月24日 12時00分 公開
[PeterEeles(レベル:初級 IBMシニアITアーキテクト),@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




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

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

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.