アーキテクチャとは？ Grady Booch によると。。。

アーキテクチャとは何だろうか？この問いはいろいろな人に聞くといろいろな答えが返ってくるので、「リクルートの面接時に必ず問う」という人もいるはずだ。ソフトウェアと分野に限らなくてもよいし、さらに、システムという分野に限らなくても答えられる。

ぼくの知識の中で、もっともらしいと思われているのが幾つかある。

• IEEE1471のアーキテクチャに関するコンセプチャルなフレームワーク

これは、図のようなモデルで表現される。これは、かなりフォーマルに「アーキテクチャとは何か？」に答えているようだ。システムには１つのアーキテクチャがあり、１つ以上のアーキテクチャ記述によって記述されており、１つ以上のビューとモデルを含み、ステークホルダと関連している。ステークホルダは１つ以上の関心事をもっており、１つの視点は１つ以上の関心事をカバーしている。。。。。。」と読む（読めるか？）。

• RUP

RUPは、それ自身、「アーキテクチャ中心」という冠詞が付いており、アーキテクチャは主に非機能要件から決定されるとしている。また、早期に決定することがプロジェクトのリスクを下げる上で重要とされている。

• XP、アジャイル

アジャイルの旗手、XP(Extreme Programming)では、「ぼくは"A"からはじまる言葉をここではわざと使っていない。」として、アーキテクチャを避けている。もしくは、後に、「小さくはじめて育てる」とか、「アプリケーションの薄い縦スライスを作ってそれを太らせていく方法で、アーキテクチャは創発する」としている。これは、リファクタリング技術を最大限に活かした手法であるが、アーキテクチャが不連続に変わってしまう「アーキテクチャジャンプ」のリスクがある。

・Beyond Software Architecture

Luke Hohmann の本では、「アーキテクチャには技術できまる”ターキテクチャ”と、マーケティング要素から決まる”マーケテクチャ”の両面性がある」としている。

・POSA（Pattern Oriented Software Architecture)

よく知られたアーキテクチャをパターンとしてカタログ化するアプローチ。パターンムーブメントの中で、「デザインパターン」の自然な延長に出てきた。

そして、ぼくが最も興味があるのが、アーキテクチャの創発を「自然に起こる」のを待つアジャイルのアプローチと、最も変更しにくい部分と考えてなるべく早期に決定しようとするRUPアプローチのバランスである。もっとも、アジャイルでもリスクの高いストーリーを先に回すことで、アーキテクチャ創発を促すことができる。（ぼくはアジャイル信者である）

さらに、Jim Coplien が Uncle Bob との対談の中で、「TDDを過信して、アーキテクチャは創れない」という発言をしているのも気になるし、逆に「アーキテクトも実装に参加すべし(Architect Also Implements)」というパターンを組織プロセスパターンの中に含めているのもJim本人だ。

アーキテクチャは、創発するのか、あるいは、（経験から）選択するものなのか。直感的には、短期的な機能を実装することに焦点を当てると、健全なアーキテクチャは決まりにくいのではないか。。。アジャイルは機能するのだろうか？資産的な観点は？しかし、とは言っても行き過ぎたアーキテクチャ先行が逆に開発を阻む、いわゆるBDUF（Big Design Upfront)の弊害も多すぎる。先日マイクロソフトの萩原さんと話をしていたときにも、この話題になった。

こんなことを考えていたら、今日、Grady Booch のこんなスライドを発見してぶっとんだ。

• すべてのアーキテクチャはデザインである。しかし、すべてのデザインがアーキテクチャであるわけではない。システムのアーキテクチャは、有意なデザイン上の意思決定で定義される。（ここで、有意かどうかは変更コストによって計測される）
• ほとんどのアーキテクチャは、偶然的である。しかし、ときに意図的なものもある。
• すべてのソフトウェアが主要な役割をしめるシステムには、アーキテクチャが存在し、それは、日々起こる何万もの意思決定の積み重ねである。
• コードはいつでも正しい。しかし、それは正しいことの全体ではない。ほとんどのアーキテクチャ情報は、種族記憶(tribal memory: 個々人を含むチーム記憶の歴史的な全体)に存在する。

わお、だ。かっこいい。ほとんど言い尽くしている。。。。また Jim Coplien は、

• 開発は２つのレベルで進行する。
  (1) アーキテクチャ
  (2) 実装
• ２つは同時進行し、かつ、お互いに強い相互作用がある。新しい実装はアーキテクチャの変更を示唆する。アーキテクチャの変更は、ふつう大幅な実装の変更を強制する。

と示唆。これは、先の「Architect Also Implemets」のラショナルだ。

ところで、このブログを書くために、IEEE1471をJUDEで書いて、JUDE/Share にアップしてみました。www

http://ec2-75-101-210-248.compute-1.amazonaws.com:7080/judeshare/#diagram=103

(※10/27追記

上記サイトは JUDE/Share のデモサイトで、まだβ版です。最初ログイン画面が出ますが、「デモユーザ」でログインしてください、図が見えると思います。）