2. 2つの基本概念

2.1 アーキテクチャ

もともとは建築の用語で、ギリシャ、ロマネスクなど建築の様式を現すのに使われています。ある建築物が作られる際に、その建築がとるべき典型的な構造、装飾を示すものです。ある程度の規模の建築物を作ろうとする際には、居間、寝室、トイレといった各部屋を、バラバラに建てていってもうまくいかないことは目に見えています。部屋の移動しやすい配置、日当たり、風通し、収納、防音、耐久性など全体の構成についての配慮を最初に行っていかないと、建てた後で「見かけはいいが実は耐久性がすごく悪い」ということになってしまいます。アーキテクチャが事前にきちんと整理されていればこのようなことを防ぐことができます。

ソフトウェアの世界でも同じようなことがいえます。アーキテクチャは、ソフトウェアの開発プロセスにわたって横断的に存在し、まさにソフトウェア全体を支える骨格として機能しているのです。まずクラスの作り込みといった細部に入る前に、どんなDBを使うのか（RDB、ODB）、どんな通信形態を取るのか(クライアントサーバ、ピアツーピア)、どんな処理形態をとるのか(バッチ、並列処理、並行処理)といった方針をあらかじめ決めておかねばまともなシステムにはなりません。(こうした、比較的上流工程で行われる大きなレベルでの決定はマクロアーキテクチャと呼ばれます)。また、開発が進み、クラスを洗練させようといった段階に入った後にも、クラスやパッケージ間の構成を秩序だって決めていくといった、もう少し小さいスケールでのアーキテクチャ(ミクロアーキテクチャ)を選択していくことが重要なのです。

更に、ソフトウェアの世界でのアーキテクチャは、単に典型的構造にのみ焦点を当てているわけではなく、振る舞いについても規定していることに注意する必要があります。
再び一種の問題解決の機械としてソフトウェアを考えてみましょう。機械は、機能を実現するために何らかの流れを制御するメカニズム持ちます。この部分がまずい機械は通常うまく動作しません。各部品の修理や、組み替えもしにくく、耐久性や、拡張性も非常に悪いのです。
例えば、CDプレーヤの場合には、まずトレーがCDプレーヤをデッキの内部に取り込み、回転軸にCDをセットします。次にモータが回転し始め、ピックアップがレンズをCDの特定トラックに移動させて再生を開始します。このように各部品での処理担当と流れが明確に機構として定まっているのが、望ましい機械のあり方です。再生ができないという事態に陥ったときには、モータの回転段階までは正常だが、トラックへの移動が上手くいっていないのでピックアップの不具合だろうとすぐにわかります。
ソフトウェアも、どのようなデータが流れ、どのようにプロセスが起動し、どのモジュールが処理を行っていくのかという、典型的な振る舞いの規定があることによって、堅牢なものになりえます。
バッチ的に定められた入力データを加工して出力として返していく形式なのか、よりインタラクティブに、ユーザのリクエストに逐一反応するビューを提供するものなのかなど、どのような流れで全体の処理が進んでいくべきなのかについての決定も、アーキテクチャの一候補なのです。

アーキテクチャについては、マクロなものとしてとらえるか、ミクロなものとしてとらえるか、構造重視か振る舞い重視かなど、オブジェクト指向の設計者の間でも微妙な解釈の違いがあり、きちんとした定義としてはまだ不明瞭な部分があります。UMLの3-Amigosの一人、Boochさんの解説をもとに端的にまとめると、「ソフトウェアの全体的な構造と振る舞いに関する戦略的な決定」となります。

Prev.

Index