ソフトウェアアーキテクチャ その2 - 「ソフトウェアアーキテクチャ」とは [arch]
今回は，「そもそもソフトウェアアーキテクチャって何?」という話．その定義を中心に見ていきたいと思う．
Reference:
Software Architecture in Practice, Second Edition,
by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003
--> Chapter 2
|
タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている．
こちらがその和訳本．
ではまず「ソフトウェアアーキテクチャ」について，SEI (ソフトウェアに関する最も権威のある研究機関の1つ) の定義から見てみよう．
How Do You Define Software Architecture?
Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.
これによるとソフトウェアアーキテクチャは，間違えばプロジェクトを失敗に陥れかねない，設計の「意思決定」の集合である，としている．
またこの他にも，SEI は世の中に無数にある「ソフトウェアアーキテクチャの定義」の一覧を掲載している．
Published Software Architecture Definitions
しかしここで採用したいのは，冒頭で紹介した書籍による定義である．
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
ソフトウェアアーキテクチャは，システムの "structure or structures" (構造) であり，それは "elements" (要素)，"the externally-visible properties of those elements" (可視化された要素の特性)，"the relationships among them" (要素間の関係) から成り立つとしている．
順番に見ていこう．
Structure(s) (構造) とはソフトウェアの実体であり，コード，プロセス，スレッドなど，様々な形態が存在するだろう．
Elements (要素) はシステムを構成する部品である．例えば静的観点で見ればクラスやファイル，動的観点で見ればデータフローやコントロール，物理的観点で見ればプロセッサやネットワークなどが挙げられる．
"The externally visible properties of those elements" ということは，まず要素が properties，つまり要求されているパフォーマンスや変更容易性などの特性を持つことを示している．要素に特性を割り当てるというのは，設計の真髄だ．さらにアーキテクチャはそれを可視化させるものであるということだ．
"The relationships among them" ということは，要素はインターフェースをもって互いに関係を持つことを示している．
加えてこの定義から読み取りたいことがいくつかある．
まず，この定義は相互作用に関係しない要素の情報を明確に除外している．つまりアーキテクチャは，システムの最も重要な抽象概念であり，使い方，使われ方，関係の仕方，あるいは相互作用に影響を与えない詳細部分を省略したものである．
さらにこの定義は，システムが複数の構造で構成されること，そしてソフトウェアを備えた全ての計算システムに，ソフトウェアアーキテクチャが存在することを意味している．システムがそれ自身で単一の要素になるような単純なケースでもやはりアーキテクチャであり，全てのドキュメントやソースコードが消え去り，実行バイナリコードだけが残ったとしてもそこにはアーキテクチャが存在する．つまりアーキテクチャは，その記述や定義とは独立して存在できるのである．
そして別の要素の視点から，振る舞いが観測可能，あるいは識別可能である限り，各要素の振る舞いはアーキテクチャの一部であることを意味している．このような振る舞いは，要素が他の要素と相互作用することを可能にするので，明らかにアーキテクチャの一部である．
またこの定義は，システムのアーキテクチャが良いか悪いかということには何も触れていないところにも注目したい．
なぜソフトウェアアーキテクチャがそこまで重要なのだろうか? それはソフトウェアアーキテクチャが開発において重要な役割りを持つからだ．本書は，以下の点で作用するとしている．
1. Communication among stakeholders
(利害関係者とのコミュニケーション)
ソフトウェアアーキテクチャは，利害関係者との相互理解，交渉，コンセンサス，コミュニケーション手段として利用できる．アーキテクチャの分析は，このコミュニケーションのレベルに依存し，また同時にそのレベルを高めることもできる．
2. Early design decisions
(初期の設計方針確立)
ソフトウェアアーキテクチャは，システムに関する最も初期の設計方針を明示したものである．
具体的には，アーキテクチャは，
- 実装上の制約を定義する
- 組織構造を決定する
- システムの品質特性を促進もしくは抑制する
- システムの品質を予見する
- 変更の考察及び管理を容易にする
- 段階的なプロトタイピングを促進する
- より正確なコスト・スケジュール見積りを可能にする
3. Transferable abstraction of a system
(システムの転用可能な抽象概念)
ソフトウェアアーキテクチャは，システムがどのような構造になっていて，その要素がどのように連携するのかを表現する，比較的小さな，知的に理解可能なモデルで構成される．
このモデルはシステム間で転用可能であり，特に同様の品質特性と機能要求を示す他のシステムに適用できるので，大規模な再利用を促進する．
具体的には，
- プロダクトラインは共通のアーキテクチャを共有する
- システムを，外部で開発された大規模な要素を使って構築可能とする
- 設計の選択肢を制限することができる
- テンプレートに基く開発を可能にする
- トレーニングの基礎として活用できる
1の，「アーキテクチャの分析は，このコミュニケーションのレベルに依存し，また同時にそのレベルを高めることもできる」との本書の記述に驚いた方もいるだろうが，実際に企業で開発を行っているとこれは事実だと感じるし，ソフトウェアアーキテクチャの専門書にも組織論やマネージメント，ステークホルダーとの関係の話が多く登場する．これこそが，ソフトウェアが「工学」になりきれていない証拠なのかもしれない．
ついでに「アーキテクトの役割」についても触れておこう．SEI はこのように定義している．
What are the Duties, Skills, etc. of a Chief Software Architect?
要約すると，アーキテクトの役割は
- システムの明確化，要求の実現，上流設計
- 担当者の技術支援
- 設計と文書化の引率，アーキテクチャ評価
- マネージメントに対する報告
- テクニカルリーダーシップ
などであり，それに伴いアーキテクトに求められる資質は，
- 最新技術，動向の理解
- 詳細を理解しつつも，全体像を見る眼力
- 経験
- 情報科学，OS，ハード等，多岐に渡る知識
- 設計と品質の，トレードオフまで含めた理解
- 技術面，ビジネス面におけるビジョン，先見性
- コミュニケーションスキル (writing + speaking)
- コーチングスキル
などということだ．
今回述べたかったことは以上だが，最後に今回の本書第2章の範囲の中で，もう2点ほどピックアップしておこう．
1つは「建築とソフトウェアシステムの比喩はすぐに破綻する」と記述されている点について．「アーキテクチャ」の本来の意味は「建築」であり，一般的にもソフトウェアアーキテクチャと建物のアーキテクチャは良く比較される．確かに実現しようとしている成果物のキーコンセプトを表すものであるという点，要求を具現化することを促進し利害関係者とのコミュニケーションツールとして利用できる点，小さい部品からより大きい部品を作り出しその集合でシステムを構築する点などは類似しているが，ソフトウェアはそもそも無形であること，建築には時として「芸術」という動機が伴うこと，建築設計に動的概念が無いこと，長い歴史に基き建築の方が工学として成熟しておりずっと標準化が進んでいること，そして完成品に対するリファクタリングの概念や部品交換及び複製の容易さ，さらに評価方法が致命的に違うことなどを忘れてはならない．
もう1つは "System Architecture versus Software Architecture" という Rick Kazman のコラムの補足．「エンタープライズアーキテクチャ」(ビジネス構造もしくはビジネス構造間の結合を描写し，企業の実体間における情報の流れやアクティビティを説明する) や，「システムアーキテクチャ」(完全なシステムの要素もしくは要素間の相互作用，及びそれらのシステムゴールにおける貢献を描写し，ハードウェアとソフトウェアの要素を定義する．但しそれらの基礎構造まで言及することはない) など，「アーキテクチャ」という言葉は開発における様々な分野に使われることがある．これら各アーキテクチャの分離や範囲，包含関係は，対象とするドメインやスコープ，視点などによって異なることを覚えておきたい．
0 コメント:
コメントを投稿