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

» 2006年03月17日 12時00分 公開

◆ アーキテクチャの定義

 こと「アーキテクチャ」に関しては十分定義され尽くしている。定義を集めたWebサイトまで存在する(注1)。本稿で使う定義は、IEEE 1471.2と呼ばれる「IEEE Std 1472000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems」から抜粋してきたものだ。この定義は次のようになっており、重要な部分は括弧で囲んである。


注1 「The Software Engineering Institute (SEI) Architecture Website -- architecture definitions」に好例がある。http://www.sei.cmu.edu/architecture/definitions.html参照。


 アーキテクチャとは、「コンポーネント」、コンポーネント間および「環境」との「関係」、またその設計と進化の指針となる原理に体現された「システム」の基本「構造」である(IEEE 1471)。注2


注2 IEEE Computer Society, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems: IEEE Std 1472000. 2000.


 同標準は、この定義に関連して以下の用語も定義している。

 「システム」は、特定の機能もしくは機能セット実現のために組織化されたコンポーネントの集合である。システムという用語には、個々のアプリケーション、従来の意味である体系、サブシステム、システムのシステム、製品ラインアップ、製品ファミリー、企業全体、そのほかあらゆる関心事が含まれている。システムは、それがある環境における1つ以上の「ミッション」を遂行するために存在する(IEEE 1471)。

 環境(あるいは前後関係)によって、そのシステムにおける開発上、運用上、政治上など、さまざまな影響の設定や状況が決まる(IEEE 1471)。

 「ミッション」とは、1人以上の「利害関係者」が一連の目的を達成するためにシステムに期待する用途もしくは運用方法である(IEEE 1471)。

 「利害関係者」は、1つのシステムに対して同じ関心もしくは懸念を持つ個人、チーム、もしくは組織(その意味では各階級も)である(IEEE 1471)。

 お気付きかとは思うが、これらの定義では「コンポーネント」という用語が各所で用いられている。しかし、アーキテクチャの大半の定義では「コンポーネント」という用語が定義されておらず、業界で多くの解釈ができるよう、これを故意にあいまいなままにしており、IEEE 1471もその例外ではない。コンポーネントは、論理的だったり物理的だったり、技術に依存しなかったり特化したり、粗かったり細かかったりとさまざまだ。本稿の目的を考え、筆者はUML 2.0仕様にあるコンポーネントの定義を利用する。だが筆者は、オブジェクト、技術コンポーネント(Enterprise JavaBeanなど)、サービス、プログラムモジュール、レガシーシステム、パッケージアプリケーションなど、目にする可能性のあるさまざまなアーキテクチャの要素を含めるため、この用語をかなり大まかな意味で利用する。UML 2.0は「コンポーネント」を次のように定義している。

 [コンポーネントとは]システムのモジュール部分で、その内容はカプセル化されていて、実現形が環境内で代替可能なものである。コンポーネントは、提供された必須インターフェイスの観点からその動作を定義する。そのようなことから、コンポーネントはこれらの提供された必須インターフェイス(静的意味論と動的意味論の両方を含む)によって整合性が定義される1つのタイプであることが多い。注3


注3 Object Management Group Inc.著、「UML 2.0 Infrastructure Specification: Document number 03-09-15」、2003年9月刊。


 ここにある定義は多数の異なるコンセプトをカバーしているが、詳細は以下で解説する。「アーキテクチャ」には、業界で一般的に意見が一致した定義はないが、これらの類似点が分かるよう、ほかにもいくつか定義を考えてみる価値はある。以下の定義も検討していただきたい。こちらも、重要な部分については括弧で囲んである。

 アーキテクチャとは、ソフトウェアシステムの構造に関する「一連の重要な判断」「構造要素」の選択、そしてシステムを構成するインターフェイスに加え、これらの要素間のコラボレーションで明記されたその「動作」、徐々に大型化するサブシステムへのこれら要素の「組み込み」、そしてこの構造の指針となる「アーキテクチャスタイル」である。つまり、これらの要素とインターフェイス、そのコラボレーション、そして構成であるKruchten)。注4


注4 Philippe Kruchten著、「The Rational Unified Process: An Introduction」第3版、Addison-Wesley Professional 2003年刊。


 ソフトウェアの要素、外部から見えるこれらの「要素」の特性、そしてこれらの「関係」を構成するシステムの構造が、プログラムあるいは計算処理システムのソフトウェアアーキテクチャである(Bassなど)。注5


注5 Len Bass、Paul Clements、Rick Kazman共著、「Software Architecture in Practice」第2版、Addison -Wesley 2003刊。


 [アーキテクチャは]組織の構成であり、システムの関連動作だ。アーキテクチャは、インターフェイス経由でやりとりするパーツ、パーツをつなぐ関係、そしてパーツを組み立てる制約に、再帰的に分解することができる。インターフェイス経由でやりとりするパーツには、クラス、コンポーネント、およびサブシステムなどがある(UML 1.5)。注6


注6 Object Management Group Inc.著、「OMG Unified Modeling Language Specification Version 1.5, Document number 03-03-01」、2003年3月。


 システムのソフトウェアアーキテクチャもしくはシステムの集合は、ソフトウェア構造に関する重要な設計判断すべてと、そのシステムを構成する構造間の対話によって構成されている。設計判断は、システムを成功へと導くために望ましい一連の資質をサポートする必要がある。設計判断は、システムの開発、サポート、および保守のためのコンセプト基盤を提供する(McGovern)。注7


注7 James McGovernなど著、「A Practical Guide to Enterprise Architecture.」、Prentice Hall 2004年刊。


 定義はやや異なるものの、かなりの共通点が見えてくる。例えば、アーキテクチャは構造と動作の両方を考慮し、重要な判断だけを考慮し、場合によって構造スタイルに準拠し、その利害関係者と環境の影響を受け、論理的根拠に基づく判断を具体化する、と大半の場合は定義されている。以下では、これらのテーマと、ほかのすべての問題について説明する。

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ