Jaa


パターン言語と開発プロセス

Software Factoriesはソフトウェアプロダクトラインとモデル駆動型開発を組み合わせた技術ととらえる点が強調されています。この組み合わせはソフトウェアプロダクトラインの分野では最近流行しているのですが、これと並んで、Software Factoriesは開発プロセスの設計と実装が重要なテーマです。

たとえば、簡単な例で飲み会で終電に遅れそうになっている例を考えてみましょう。この例では、目的は無事に自宅に帰宅できることです。この目的を遂行するために必要な活動をプロジェクトと見なします。必要となる手順としては、電車の路線図を見る、主要駅の終電の時刻表を見ることが必要です。これに加えて、運賃というコスト制約が発生します。できるだけ、タクシーは使いたくないので。

このプロジェクトは、別の見方をすれば、電車の路線図というDSLモデルと、終電の時刻表というDSLモデルを組み合わせ、相互に参照して、終電に間に合いそうな駅を複数のパスから発見する作業となります。まず、路線図を見て、時刻表を見て、また、路線図を見直すという手順となります。
この手順と必要とするモデル図の組み合わせを開発プロセスの定義とします。飲み会以外にも、終電にひっかかりそうな外出の例は多くありますから、再利用性の高いプロセスということになります。この開発プロセスの設計をアーキテクトが担当し、一般の開発者用に資産化しておきます。結局、携帯によるサービスはこうして出来上がっているのです。

ソフトウェア開発は多くの意思決定の連続です。そして、この意思決定のポイントは開発プロセスの特定条件のポイントで、制約条件に基づきます。そうであるのなら、想定する開発で必要となる意思決定ポイントと制約条件を抽出しておき、それに関連する資産、たとえば、参照しなければならない情報やモデルをを対応づけておきます。この作業は、上記の終電に間に合うためのプロセスの定義と同等と考えます。

パターンを体系化する方法には、パターンをまとめるクラスタ化、抽象レベルによる分類、開発の条件や制約に応じて開発プロセスでパターン間を舐める際に通るパス定義が存在します。これをパターンフレームといいます。パターン言語と呼ぶ方が一般的かもしれません。

このパターン言語の構造は、先の再利用可能な開発プロセス間の関係に類似しています。すなわち、ソフトウェア開発は細かな開発プロセスを組み合わせて開発されるとすると、それぞれの開発プロセス間の関係づけや利用パスが、開発上の制約条件によって決定されるからです。ですから、再利用可能な開発プロセスの定義は、パターン言語を応用して体系化されるといえます。

Software Factoriesには開発プロセス定義としてビューポイントが存在しますが、それをどのように抽出して定義し、体系化するかの方法が与えられていませんでした。僕は、ここに意思決定のポイントによる抽出と、パターン言語による体系化を考えています。