ソフトウェアアーキテクチャ その6 - パターンとその解釈方法 [arch]
'Pattern' の定義については，'View' や 'Viewtype' といった概念も含めて，第3回 参照．
Reference:
Software Architecture: Perspectives on an Emerging Discipline,
by Mary Shaw and David Garlan, Prentice Hall 1996
--> Chapter 2
1996年発行と内容は少し古く，今日の開発に実践できる内容は少ないが，ソフトウェアアーキテクチャのいわゆる「クラシックエッセンス」に触れることができる．
エンジニアとして「自分の引き出しを増やす」という意味では，ぜひ手元に置いておきたい1冊だ．
第3回で述べた通り，pattern は，要素と要素間の関係，またそれらの組み合わせに関する制約を定義し， 過去に実証された知識の再利用を可能にするものだ．一般的に現実社会のシステムは，複数の pattern の組み合わせで構成されていると考えて良いだろう．
同じく第3回で，「アーキテクチャドキュメントというとレイヤ構造図や依存関係図ばかり見る気がするが，むしろソフトウェアアーキテクチャを本質的に表現するのは動的分析図である」と述べたが，つまりこれは C&C viewtype の pattern ということになる．代表的な pattern の一覧は，
http://softarchpract.atw.hu/ch05lev1sec9.html
の Figure 5.14 が見やすくまとまっている．
各 pattern の詳細については本書第2章か，第3回で紹介した Documenting Software Architectures (和訳版は こちら) の 第3・4章を参照頂くとして，以下ではそれよりもう1歩踏み込んでみたいと思う．
実は現状， pattern の標準的かつ完全な説明というものは，世に存在しない．つまり今日のソフトウェア工学は，システムの structure (構造・実体) を，その潜在的な理念や用途まで含めて体系化するに至っていないのである．
実体がドキュメント化された時に，その内容を体系化して粒度を合わせ，詳細を詰めながら何が重要かを見つけ出し，要求に沿っているかどうかを考察するのは，読み手に委ねられてしまっていることがほとんどだ．
こんな状況の中， なんらかのシステムやドキュメントで pattern に直面した時，あるいは自分が pattern を記述しようとしている時に，頭に置いておきたいのが以下の6点である．
これらは pattern を解釈し分析する際のフレームワークとして機能し，その用途を導いてくれる．
(1) 表現の view と視点
(perspective and view of the representation)
その pattern は「どの視点でものを話しているのか」ということ．
本書の pattern の説明でも視点は明確に伝わっておらず， 「はい，これが client-server ですよ」で終わりだ．
そもそも，GoF にしろ，Bushman にしろ，Shaw や Garlan にしろ，SEI にしろ，様々な研究者や団体が提唱している手法や方法論は，互いに矛盾していることも少なくない．なぜなら，語っている粒度がバラバラであり，そして視点が明確にされていないからである．
(2) 位相的配置
(topological arrangement)
何度も何度も目にするのは何なのか，ということ．
同じものが，何度も何度も登場してくるのは，すなわちそれが pattern であるからだ．
もちろんこの時でも，(1) の view が明確ではないと役には立たない．
(3) 要素とその関係
(elements and relations)
要素とその関係は，structureの基礎である．
視点 (1) が分からなければ，要素とその関係も分からないだろう．
(4) Pattern の意味付け (セマンティック)
(semantics of the pattern)
使用する際のルールが何なのか．
用途のルールを知らなければ，何の理解にもなり得ない．
(5) Pattern によって促進される品質特性
(qualities promoted by the pattern)
(6) Pattern によって抑制される品質特性
(qualities inhibited by the pattern)
この中でキーとなるのは (4) である．
(1) - (3) が分からなければ，その使い方 (4) は分からない．そして (4) が分かれば，(5) と (6) も分かるのだ．
これで始めて「知識の再利用」が可能になる．
促進するべき品質特性まで分かっていれば，「候補となる structure」が自ずと頭に浮かぶはずである．
現実の設計で pattern を見つけた時は，それが再利用できるように，どう (1) - (6) を記述するか，あるいは本の中で pattern を見たら，それをどう (1) - (6) の観点から落とし込んで現場で使えるようにするか，という点が非常に重要なポイントなのである．
ちなみにこれは，tactics には当てはまらない．なぜなら tactics は structural ではないからである (実体というよりも，むしろ実体に適用する戦略的なものである)．
以上の概念は，現在どの書籍にも書かれていない．先日，SEI の某アーキテクトが「あまりに重要な概念であるにも関わらず，あまりに疎かにされている」と嘆きながら話してくれたものである．そろそろウンザリしてきたので，彼が現在執筆中の書籍で明確にしようとしているとのことだ．
彼の言葉を借りれば
"feed me for a day" or "feed me for a lifetime,"
I'd choose "feed me for a lifetime."
とのこと (英語の表現で，"feed me for a day" とは魚を与えること，"feed me for a lifetime" とは釣り方を教えることを例えて指す)．
つまり，今回の reference である本書における「1つ1つの pattern の説明」や，その他書籍に書いてあることはもちろん重要だが，それは "feed me for a day" であり，アーキテクトが styleや pattern，もしくはどんな構造的要素 (structural elements) でもそれを見た時に (1) - (6) の観点で考えることこそ本質的な考え方であり，一生モノの "feed me for a lifetime" ということである．
0 コメント:
コメントを投稿