こと「アーキテクチャー」に関しては十分定義され尽くしている。定義を集めた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.
同標準は、この定義に関連して以下の用語も定義している。
お気づきかとは思うが、これらの定義では「コンポーネント」という用語が各所で用いられている。しかし、アーキテクチャーの大半の定義では「コンポーネント」という用語が定義されておらず、業界で多くの解釈ができるよう、これを故意にあいまいなままにしており、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.