ソフトウェアアーキテクチャ その7 - パターンの実際 [arch]
我々が問題を解決する際，まったく新しいソリューションを発明することは稀であり，過去の類似した問題の解決方法 (またはそのエッセンス) を再利用することが多いだろう．これは "problem-solution pairs" と呼ばれ，建築や経済などの分野でも有名な概念である．
Pattern は「過去に実証された知識の再利用を可能にする」と述べたが，つまりこれは "problem-solution pairs" を抽象化・体系化し，共通の特徴を抽出したものが pattern であるからに他ならない．
では実践における pattern を見る為に，今回はいくつかのケーススタディを紹介したいと思う．
Reference:
Software Architecture: Perspectives on an Emerging Discipline,
by Mary Shaw and David Garlan, Prentice Hall 1996
--> Chapter 3
1996年発行と内容は少し古く，今日の開発に実践できる内容は少ないが，ソフトウェアアーキテクチャのいわゆる「クラシックエッセンス」に触れることができる．
エンジニアとして「自分の引き出しを増やす」という意味では，ぜひ手元に置いておきたい1冊だ．
Software Architecture in Practice, Second Edition,
by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003
--> Chapter 6
|
タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている．
こちらがその和訳本．
"Software Architecture: Perspectives on an Emerging Discipline" の第3章には，合計7つのケーススタディが紹介されている．1つ目は，同じ問題に対して異なるアプローチがそれぞれどう作用するかという例 (3.1章)，2つ目は，専門性の高い領域における pattern 活用の例 (3.2章)，3つ目は可動式ロボットにおける様々な pattern の比較 (3.3章)，4つ目はクルーズ制御システムにおける process-control の適用方法 (3.4章)，そして残りの3つはシステムに複数の pattern が混在する例 (3.5章) である．
ここでは可動式ロボットにおける様々な pattern (3.3章) を見てみることにしよう．
本書では，このロボットに対して Control Loop, Layers, Implicit Invocation, Blackboard という4つの pattern を用いた解決方法を比較している．"Layers" は一般的には module viewtype を指す言葉であり (本書が発行された1996年には "viewtype" という概念が無かった)，今日では C&C における階層構造は "N-tiers" と呼ばれる為，以下ではそのように記述する．
このロボットに要求されているのは，
Req 1. 環境の変化に応じた動作ができること
Req 2. 不完全もしくは信頼できない情報においても動作すること
Req 3. 電源の減衰や蒸気などの問題で破綻しないこと
Req 4. 開発中の実験や構成の変更に柔軟に対応できること
とされているが，本書の情報だけでは詳細検討に不十分であり (応答測定も示されておらず，そもそもどんなロボットなのかが分からない) 最適な解を導くことができない．視点を明確にする為に，ここでは「障害者用の自動操縦車椅子」のようなもの，つまりそれなりに複雑で，availability が最も重要であり，performance や modifiability が次の優先事項になるようなシステムと仮定した上で，それぞれの pattern を比較することにする．
- Control Loop
Availability の観点で active/passive redundancy, removable from service などの tactics が検討に値する．その他も考慮の余地があるが，control loop の最大の特徴である simplicity を害してしまう．
品質特性としては，availability と simplicity を促進し，adjustability, decomposability, performance などを抑制すると思われる．
このことから Req 1には不利であり，Req 2も trial-and-error で検証が必要なこと，また performance の tactics を適用しにくいことから不利である．Req 3は redundancy が適用でき冗長性を実現できることから有利であり，removable from service も考慮できる．Req 4に関しては，メジャーコンポーネントは代替可能であるが，それらにマイナーチェンジがしにくい点から，どちらとも言えないだろう．
結論として，複雑なロボットシステムには最適と言えず，また simplicity が最大の特徴であるがゆえに tactics を適用しにくいというジレンマがある．
- N-tiers
責務の明確なアサインが可能であり，コンポーネントの整理がしやすい．抽象化の概念も明確になる．
Availability の観点で voting，また modifiability の観点で hide information, use an intermediary などの tactics が適用可能と思われる．Availability と modifiability を促進するが，modifiability は他方で抑制もされるだろう．Performance, flexibility, customizability なども抑制されそうだ．
データと制御を完全に分離できない点から，Req 1には不利である．階層構造の抽象概念は Req 2には有利だが，Req 3の為に performance を促進しようとすると階層をショートカットする手段が必要となり，それが Req 4に不利に働いてしまう．
結論として，システムが複雑であればあるほど現実性が無くなってくる．Modifiability と performance のトレードオフが難しい．
- Implicit Invocation
Event-oriented のアプローチ．
Availability の観点で，exception, active redundancy, transactions, process monitor など，modifiability の観点で semantic coherence, runtime registration, component replacement など，performance の観点で，manage event rate, introduce concurrency, scheduling policy など，様々な tactics が検討に値する．
Availability, performance, re-configurability, flexibility, sustainability, reusability などを促進し，testability, portability, simplicity などを抑制する．
アクションの明確な分離が可能で，並行性も導入しやすいことから Req 1には非常に有利である．スケジューリングポリシーによるイベントレートの管理も可能だろう．Req 2に関しては，一時的な依存関係をタスク間で定義することや exception などでカバーできるかもしれない．Req 3は，exception, wiretapping, monitors が performance と availability を考慮し，また冗長性も容易に実現可能である．Req 4に関しても，インクリメンタルな開発を容易とし，component replacement や semantic coherence などが適用可能である．
結論として，ロボットシステム，特に複雑なものには非常にマッチし，とても強力に作用すると思われる．
- Blackboard
Data-oriented のアプローチ．情報集中型のシステム．
Availability の観点で exception, voting, transactions, process monitor など，modifiability の観点で，runtime registration, component replacement など，performance の観点で introduce concurrency, increase available resources など，testability の観点で record/playback などの tactics が適用可能と思われる．
Availability, modifiability, testability, flexibility, adaptability などが促進され，simplicity が抑制される．Performance もある程度ダメージを受ける可能性がある．
Req 1については共有データで情報交換可能だが，データの流れを強制してしまいかねない．Req 2と3については有利であるが，Req 3を考えるとデータが集中した時のリソース問題が心配になってくる．Req 4は並行性をサポートしており，component replacement も検討の余地があることから有利と言って良いだろう．
結論としては，どんなロボットシステムでもある程度応用可能であるが，複雑なシステムでは特に performance の観点で Implicit Invocation に及ばないと考える．
以上のことから，Implicit Invocation がこの中では最適だと思われるが，以前も述べた通りシステムがたった1つの pattern から構成されることはほとんど無い．
例えばこのロボットであれば Implicit Invocation をベースに，システムに秩序性をもたらす為に Explicit Invocation を平行導入し，そのデータ管理には Repository を採用する，などと考えて行くことになるだろう．
2つ目のケーススタディは，"Software Architecture in Practice" 第6章の航空交通制御システム．ここではその紹介だけに留めておく．
これはかつて実際にアメリカの FAA (Federal Aviation Administration) に対して計画されていたシステムである．
このシステムは「1990年代の計算機におけるチャレンジを全て集めた」とまで言われた．数百万行に及ぶソフトウェアは，何百ものコンピュータに配布され，複雑な分散システムとして実現される必要がある．人命に関わる航空交通システムという性格上，安全性の確保は絶対条件になる．リアルタイム性が高く求められ，タイミングも非常にシビアだ．莫大な資金が投入され，同時に規模も莫大になる．そして技術に非常に長けたエンドユーザー (航空交通システム管理者) を満足させなければいけない．
特にアーキテクチャ的には，availability と performance という，完全に矛盾する2つの品質特性が，両者とも高く求められる点が非常に興味深い．
本書にはこのプロジェクトの全貌とその設計が，様々な view を用いて詳しく語られており，かなり読み応えがある．いくつもの pattern を駆使しながら，いかにこの複雑な要件を解決しているかは，ぜひ本書を手にとって確かめて頂きたい．
0 コメント:
コメントを投稿