ソフトウェアアーキテクチャ その10 - プロダクトラインでのパターン選択ケースタディ [arch]
本シリーズも前回から「実践編」というフェーズに入ったが，今回は実開発における pattern 検討の例として，第7回で reference としたケーススタディ群の別のケースを紹介したいと思う．
Reference:
Software Architecture: Perspectives on an Emerging Discipline,
by Mary Shaw and David Garlan, Prentice Hall 1996
--> Chapter 3.2
1996年発行と内容は少し古く，今日の開発に実践できる内容は少ないが，ソフトウェアアーキテクチャのいわゆる「クラシックエッセンス」に触れることができる．
エンジニアとして「自分の引き出しを増やす」という意味では，ぜひ手元に置いておきたい1冊だ．
本書第3.2章では，実際に Tektronix 社で行われた，3年越しのオシロスコープ開発プロジェクトの事例を紹介している．
このプロジェクトは，再利用性の高いオシロスコープのソフトウェアを構築し，Tektronix 社の製品ラインアップにおいてプロダクトラインを実現することを目的としてスタートした．
本書では，このソフトウェアアーキテクチャを検討するにあたり，Object-oriented pattern，Layered (N-tiers) pattern，Pipe-filter pattern を順に検討している．それぞれに，どんな問題があって採用に至らなかったのかが解説されており，実開発で pattern を選択する上で，またプロダクトラインを実践する上で，参考になるかもしれない．
そして本当に興味深いのは，彼等の出した結論が，「Pipe-filter pattern の亜種を作り上げること」だったことだ．つまり常識に縛られることなく，その組織に特化して，一般的な方法論を開発目的に沿うような形にアダプトしたことが素晴らしい．
このオシロスコープ開発の詳細や，各候補 pattern についての分析，最終的に提案された Pipe-filter の亜種と一般的な Pipe-filter の違いなどについては本書を参照頂くとして，ここでのメッセージは，どんなに優れた開発手法や本に書いてあることも「道具」にしかすぎないということである．
開発において「王道」というものは存在しない．
「道具」は使いこなして始めて意味を持つのである．
知識を得るだけで満足せずに，それを自分の環境でどう実践するかというところまで消化して，始めて役に立つと言えるのだと思う．
もちろんそれには，そもそもエンジニアとして多くの引き出しを持っていることが前提なわけだが…
もう1つ付け加えておきたいことは，開発を行う際，特に今回紹介したようなプロダクトラインを行う際には，技術面以外に重要な要素がたくさんあるということ．
具体的には，
1. プロトタイプの開発と戦略
2. 開発環境と組織形態
3. デザインレビューなどのプロセス的アプローチ
4. 適切なスペックを持った人員の確保
(特にインテグレータやドメインエキスパート)
5. 既存アーキテクチャに対する取捨選択の見極め
(場合によってはそれを壊す勇気)
6. 適切なツールの導入
7. マネージメントの開発組織に対する関わり方
などといったところだろうか．
特にプロダクトラインにおける，4の「適切なスペックを持った人員の確保」については，SEI の Software Product Line Adoption Roadmap というレポートの3.2.6章が非常に参考になるので，合わせて紹介しておく．
プロダクトラインに関しては，本シリーズでもいずれ取り上げる予定．
0 コメント:
コメントを投稿