ソフトウェアアーキテクチャ 番外編 - 本質的な検討を行う為に [arch]

今回は息抜きに「番外編」として，Paul Clements の興味深いエッセイを紹介しよう．

Reference:
Essays on Software Architecture - What's the Difference Between Architecture and Design?

---

「『アーキテクチャ』と『設計』の違いは?」というタイトルであり，これに対する

Architecture is design, but not all design is architectural.

という言葉は，Clements の名言だと思う．


私は業務でソフトウェアの上流設計を行っているが，ついつい細かすぎることまで考えてしまい，全体のアーキテクチャ設計という観点から外れた部分に陥ってしまうことが時折ある．今週も SEI のアーキテクトと話す機会があったが，議論の中でやはり彼が "Is this architectural? (それはアーキテクチャ的に関係ある話なのか?)" と指摘をする場面があった．

特に UI 設計やユーザビリティの検討は，ユーザーの目に触れるだけあって理解しやすくまた重要である為に議論が深くなりがちだが，実はそこをどう実現するかはシステム全体の分割方針にほとんど影響を及ぼさないケースが多いのではないだろうか．


では何が "architectural" なのだろうか?

Clements 曰く

if a property of an architectural element is not visible, or discernible, to any other architectural element, that element is not architectural.
--中略--
The reason the architect didn't make it part of the architecture is that its existence or nonexistence was not material to the overall goals of the architecture.

とのことである．
つまり，その要素が他の要素から認識可能ではなく，その相互作用が存在しない場合は，「細かすぎること」と言って良いのかもしれない．例えばデータの構造やそのアクセス方法は，システムが要求する機能や品質を満たすように設計することがまず重要であり，それがリストだろうが配列だろうが構わないということだ．


…などということをグダグダ言いつつも，結局は「ケースバイケース」である，と述べられている点が非常に興味深い．

The fact is, no scale or scope or measure or line divides what is architectural and what is not. One person's architecture may be another person's implementation and vice versa.
--中略--
If structure is important to achieve your system's goals, that structure is architectural.
--中略--
But designers of elements, or subsystems, that you assign may have to introduce structure of their own to meet their goals, in which case such structures are architectural: to them but not to you.

では，アーキテクトはどこまでシステムを分割すれば十分なのだろうか?
David Parnas (現在のオブジェクト指向の基となったモジュール設計の基本コンセプトを提唱した，ソフトウェアエンジニアリングのパイオニア) はかつて

a module is "small enough" when, in the face of a change, it would be just as easy to recode it as it would be to alter it.
(変更に直面した場合に，変更することが，新たにコードを書くことよりも簡単であれば十分詳細である)

と述べたことがある．

1つの目安として，
- システムの全体的な特性が定量的に示され，記述されている
- 実装担当者に対して，設計内容を共通に理解し，忠実にコードに落とすことができるレベルの制約が定義されている
- 設計に対する意思決定が明確に説明可能である
の3点を持って，「上流アーキテクチャ設計」から「実装レベルの詳細設計」に移れると考えれば良いのではないだろうか．


本エッセイはとてもおもしろいので，興味がある方はぜひ全文を読まれると良いだろう．