ソフトウェア・アーキテクチャの定義を、

ソフトウェア製品を設計するとき、機能・性能・意匠などから成る全体像と、その製品を構成する要素の、全体像に於ける役割と関係性

とする向きもありますが、あまりにも抽象的で、分りにくく、煙に巻かれたような気分になってしまいます。大切なことは、ソフトウェア・アーキテクチャが何を狙いとしているかを認識することです。

　“アーキテクチャ”の日本語訳は「建築学」や「構築スタイル」、「構築方式」などですが、そうならば、“ソフトウェア・アーキテクチャ”を、

・	ソフトウェア構築スタイル
・	ソフトウェア構築方式

と訳しても良いかも知れません。しかし、構築スタイルや構築方式は、ソフトウェア・アーキテクチャの意味をピッタリと言い表していません。スタイルという言葉に対して私達がイメージするのは様式や型です。ソフトウェア・アーキテクチャは、様式や型、あるいは方式を説明の一つの手段として取り扱うことはありますが、それらがソフトウェア・アーキテクチャのテーマではないので、本稿では「ソフトウェア・アーキテクチャ」のままで通したいと思います。

　それでは、ソフトウェア・アーキテクチャが難しい意味を含んでいるかと言えば、そうではなく、日本語に訳しにくいというだけのことです。ソフトウェア・アーキテクチャの狙いは極めて明快です。

　ソフトウェア・アーキテクチャの狙いは、ソフトウェアを開発する際、現在の開発環境（使用する機械、OS、ネットワーク、ツール、市場、など）と将来予測される環境変化に亘って、ソフトウェア開発をコスト・ミニマムにする要素をソフトウェアの設計に織り込むことです。

　ソフトウェア開発で見落とし勝ちなこととして、現在だけでなく、将来の変化を見据えた設計を行うことがあります。技術や市場は日々変化しています。今日の利用者が明日の利用者とは限りません。将来の変化を織り込んで設計しなければ、ソフトウェアを短命にします。また、変化する市場の要求に応えるために、多大な費用を使い、維持が困難になり、競争力がそがれることもあります。

　ソフトウェエア・アーキテクチャとして、ソフトウェアの設計に織り込むべきコスト･ミニマム化の要素は、

・	スケーラビリティ（Ｓｃａｌａｂｉｌｉｔｙ） 　システムの負荷の増大に応じて、柔軟に性能や機能を向上させられること。ファームウェアを活用して、同じ命令セットのマシンを小型機から大型機までシリーズ化したIBMシステム360が有名です。
・	拡張可能性（Ｅｘｔｅｎｓｉｂｉｌｉｔｙ） 　システムの利用環境の変化に応じて、性能・機能拡張が容易なこと。利用者の増加に対応するため、サーバを増設するだけで、サービスが拡大できることなど。
・	変更容易性：（Ｃｏｎｆｉｇｕｒａｂｉｌｉｔｙ） 　システムがニーズや特定の要求に合うように容易に修正・カスタマイズできること。
・	相互運用性（Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ） 　通常、異なるタイプの、異なるベンダで設計・生産されたシステムが他のシステムとのデータ交換において、効果的にコミュニケーション・動作する能力。

などです。これらは一例に過ぎません。他にも移行性（Ｐｏｒｔａｂｉｌｉｔｙ）、柔軟性（Ｆｌｅｘｉｂｉｌｉｔｙ）など多くの要素が考えられます。

　ソフトウェアの構造設計では、ソフトウェアの論理構造（モジュール構造・クラス構造）、実行環境、ファイル構成、インターフェースなどを定義しますが、上記の要素を定義に織り込むことをソフトウェア・アーキテクチャの設計と呼びます。これらの定義がソフトウェアの特性を決めることになります。

　あるソフトウェアの構造設計が、スケーラビリティや拡張可能性、変更容易性、相互運用性などの要素を織り込んでいれば、そのソフトウェアは、将来、使用条件が変わったとしても、想定の範囲内にある限り、コスト・ミニマムにできるということです。そういう観点から、ソフトウェア・アーキテクチャは非常に重要であると言えます。

　では、具体的にどのような方法で、ソフトウェア・アーキテクチャを設計することができるのでしょうか。結論から言いますと、それこそが設計者の仕事であり、一般的な方法はありません。しかし、ヒントを述べることはできます。

　本稿では、ソフトウェア・アーキテクチャの設計に際して、参考となる考え方を述べます。ソフトウェア・アーキテクチャの設計はアルゴリズムを考えるような具合には行きません。いろいろな観点から、将来に亘ってソフトウェアが使い続けられるような構造になる要素を織り込んでおく必要があります。ソフトウェア・アーキテクチャの設計はソフトウェアの種類によって異なります。例えば、OSとコンパイラ、販売管理システムでは、ソフトウェアの利用環境や構造が全く異なりますので、同じソフトウェア・アーキテクチャの設計が適用できるわけではありません。最近の携帯電話をはじめとする組込みソフトウェアもまた別のソフトウェア・アーキテクチャを設計する必要があります。このようにソフトウェアの種類を認識しておくことは大切です。以下の１．ではソフトウェアの種類を、２．以降では、主として業種ソフトウェアのアーキテクチャ設計について参考となる考え方を説明します。その他の種類のソフトウェアについては、各領域の専門家に委ねます。

１．ソフトウェアの種類

　ソフトウェアの構造は、対象とするソフトウェアの種類によって大きく異なります。ソフトウェアを大雑把に分類すると、次表に示す通りです。

　上表に示したソフトウェアはそれぞれの目的に合った構造を採用しています。例えば、OSはコンピュータの能力を最大限に使いこなすために必要な構造を追求しています。一方、コンパイラはプログラミング言語から、コンピュータの構造に合わせて最適なオブジェクト・プログラムを生成する構造を追及しています。どちらの構造もちょっとしたアイディアで確立されたわけではありません。先達が長年に亘り、研究を重ねて洗練してきた構造なのです。各種類のソフトウェア一つひとつの構造を研究することが大切です。

２．標準の採用

　言うまでもないことですが、国際標準／業界標準のいずれかに関わらず、実質的に広く使われている標準を採用することは重要です。標準の採用によって、ソフトウェアのスケーラビリティや相互運用性、移行性が高まり、ソフトウェアの市場価値を高めることになります。例えば、スケーラビリティや移行性を問題にする場合、Jａｖａの使用は有用です。携帯型の小型の機器から大型のサーバに到るまでＪａｖａで開発できるばかりでなく、機種間の移行がスムースにできるからです。大型機で開発した機能の一部が携帯端末でも必要になったとき、Ｊａｖａで書かれたプログラムであれば容易に移行できます。また、相互運用性を問題にする場合、システム間のデータ交換の手段としてXMLの使用は有用です。最近のパッケージ･ソフトウェアの多くはＸＭＬで外部システムとデータ交換できるようにしていますので、ネットワーク経由で接続された異なる機種の異なるＯＳ上の異なるソフトウェア・システムと容易にデータ交換することができます。

３．コンポーネント化

　ソフトウェアを一塊の構造に設計すると、スケーラビリティや拡張可能性、変更容易性がなく技術や市場の変化に追従することが困難になります。ソフトウェア・システムを複数のサブシステムで構成し、また各サブシステムを複数のモジュールで構成することにより、スケーラビリティや拡張可能性、変更容易性を上げる可能性があります。ここに、サブシステムやモジュールをコンポーネントと呼びます。ソフトウェア・システムをコンポーネントから構成するようにするだけでは不十分です。コンポーネントの独立性（高い強度／低い結合度）を追求することにより、コンポーネントの流通性が良くなります。コンポーネント間の関係が疎結合で、さらに同時並行動作が可能であればなお望ましいと言えます。コンポーネント化はスケーラビリティ、拡張可能性、変更容易性を高めます。しかし、コンポーネントのサイズを小さくしすぎると、分割によってコンポーネントの呼び出しコストが急激に高まり、タイムロスが増大します。

　コンポーネント化には、開発体制に自由度を与える効果もあります。あまりクリティカルではないコンポーネントの開発の外部発注を容易にし、開発速度を上げる手段になります。

　オブジェクト指向の考え方はコンポーネント化を助ける手段となります。数十年も前から、モジュール化、モジュールの独立性が研究され、オブジェクト指向へと発展してきました。オブジェクト指向でのプログラミングを実現したＪａｖａ＋ＸＭＬはコンポーネント化を容易にする手段として大変有効です。

４．ソフトウェア・ツールの活用

　前稿「プログラミング言語に依存するソフトウェア設計」で述べましたが、ソフトウェア・ツールが発展し、その影響を受けてソフトウェアの設計方法も様変わりしました。前述の通り、ソフトウェア・ツールの活用には注意すべき点があります。それは、以下の点を十分に評価しなければならないことです。

１）	ツールの制約条件の評価
２）	ツールの寿命と保守
３）	ツールの障害対応の困難さ

　これらについては、前稿を参照して下さい。

　ソフトウェア開発を行う際、設計を始める前に、利用可能なソフトウェア・ツールが存在するか、存在するならそれが目的のソフトウェア設計で利用可能か否かを評価し、それらを組み込んでソフトウェアを設計します。一昔前のソフトウェア開発に比べ、今日のソフトウェア開発では、事前の調査・評価が大変重要な位置を占めるようになっています。使用するソフトウェア・ツールがスケーラビリティや拡張可能性、変更容易性、相互運用性などを満足するものかどうかも事前の評価では大切です。

　本稿の執筆に当たって、以下の資料を参考にしました。

ａ）　ソフトウェア・アーキテクチャ　岸友二、野田夏子、深澤良彰　著　共立出版
ｂ）　Software Architecture Then and Now,  Dennis Layton,  CUTTER IT JOURNAL 2004 Vol.17, No.1

■