連載 次世代開発基盤技術“Software Factories”詳解 第2回 開発手法「ソフトウェア・プロダクトライン」とは？ マイクロソフト株式会社　萩原 正義 2005/04/16
Page1 Page2

◆「プロダクトライン開発」の開発プロセス

　プロダクトライン開発では、主に次の作業を行う。

1. プロダクトライン分析（＝ドメイン分析）
プロダクトライン定義	アーキテクチャがカバーするドメイン・スコープの決定
問題領域モデリング	そのスコープで提供するシステム利用者の要求機能（フィーチャ）の決定。その要求のうち「長期的に変化する要求」と「変化しない安定した要求」を区別
解決領域モデリング	要求のソフトウェアによる実現方法、非機能要求の提供方法の選択。要求の変化（可変性）に対する実現法の選択肢を列挙
2. プロダクトライン設計
プロダクトライン・アーキテクチャ	アーキテクチャを実現するパラダイム、共通性と可変性の実現メカニズムの決定、コンポーネント仕様定義、カスタマイズのためのDSLの設計
アーキテクチャ・フィーチャ・マッピング	問題領域モデリングでの要求、解決領域モデリングでの共通性と可変性の実現方法からアーキテクチャ実現方法へのマッピングを行う
3. プロダクトライン実装
資産の開発	アーキテクチャを実現するフレームワーク、コンポーネントの調達と開発、カスタマイズのためのDSLの調達と開発
資産パッケージング	フレームワーク、コンポーネント、テスト、DSL、IDE開発ツール、開発プロセス、開発ガイダンス（作業項目など）をセットにして提供

　これらを行う手順の概要が、先ほど示した図3の左側の開発プロセスの手順である。

　Software Factoriesでは、構築するアーキテクチャのスコープとそのアーキテクチャの要求機能（フィーチャ）は、プロダクトライン分析、つまりドメイン分析で決定する。ドメイン分析はドメイン工学の一部であり、オブジェクト指向分析／設計（OOAD）のスーパーセットである。

　ドメイン工学では主に開発対象となる世界の共通性と可変性（Commonality and Variability）に注目する*4。「共通性」は個々の要求に対してアーキテクチャが提供する共通機能で示され、「可変性」は要求によりカスタマイズやアーキテクチャの変更が必要な機能で示される。この共通性と可変性を分析し、可変性に対して適切なパラダイムや実現メカニズムを提供していく。

*4 一方、UMLでは主に開発対象の静的構造と動的振る舞いに注目する。

　ここでいうパラダイムとは、開発言語やデータ・モデルが提供する考え方や概念と、その表現方法や実現方法である。例えば、オブジェクト指向、手続き型、アスペクト指向、抽象データ型、ジェネリックスなどがある。これらのパラダイムにはその概念や表現を適用する最適なドメイン（問題領域と解決領域）、いわゆる得意分野が存在する。問題に合わせて最適なパラダイムを選択し、場合によって複数を組み合わせることもできる。特にドメイン工学では、可変性の実現方法として最適なパラダイムの選択を考えることが一般的だ。

　世の中の複雑な問題を単一パラダイムで解決できればいいのだが、実際的には複数パラダイムを組み合わせた設計を考えなければならないことが多い。これがマルチ・パラダイム・デザインである。

　例えば、可変性として小さなアルゴリズム変更が想定されるとき、これを条件コンパイルで実現する（つまり、条件でコンパイルされるアルゴリズムを切り替える）場合と、オーバーロードで実現する（オブジェクト指向のオーバーロード機能でアルゴリズムを切り替える）場合などがある。後者の場合はオブジェクト指向パラダイムの適用が前提となる。このようにドメイン工学はパラダイム選択の軸となる技術である（図4）。

図4　ドメイン工学はパラダイム選択の軸

対象システムの問題が複雑な場合は、ドメイン工学を用いて複数パラダイムを選択したドメインに分割する。この例ではパターン、オブジェクト指向、ファミリー（ジェネリックスなど）のパラダイムを組み合わせたマルチ・パラダイム・デザインを行っている。

●共通性から実現されるパターン、アーキテクチャ、フレームワーク

　共通性の発見は、主に過去から繰り返し出現する課題に対する、再利用可能な解のベスト・プラクティスを参考にして行うべきである。すなわち、業務分野でのビジネス要求、概念モデル、業務プロセスにおいて出現するアナリシス・パターンやデータ・パターン、システム構造で出現するアーキテクチャ・パターン、設計レベルのモデルで出現するデザイン・パターンなどを参考とする。

　例えば、ヘッダ明細のデータ・パターン、MVCパターン、データアクセス・パターンは、それぞれRDBテーブル構造や画面表示レイアウト、アーキテクチャ階層の論理構造、キャッシュや遅延ロード、を実現する汎用的なフレームワークやコンポーネントの機能として提供される。

　このように共通性は、パターンからアーキテクチャへ、アーキテクチャからフレームワークやコンポーネントへと実現される*5。そして、実現されたフレームワークやコンポーネントの上で新たなパターンが発見されて別のアーキテクチャとして確立され、プラットフォーム技術の高度化と抽象化が進んでいく（図5）。

*5 フレームワークやコンポーネントの設計、実装には（DSLではなく）UMLを利用するのが一般的である。

　

図5　プラットフォーム技術の高度化と抽象化

左側はプラットフォームのAPIで直接開発する例。開発では分析／設計モデルを用いる。モデル駆動型開発ではモデルとその生成コードが同期する。生成コードのうち一部は、パターンの共通性が発見されてアーキテクチャとして確立され、そのアーキテクチャに対するフレームワークが提供されて右側の図になる。フレームワークは通常ドメインごとに最適なパラダイムを選択して提供される。右側の図のモデル駆動型開発では、プラットフォーム向け開発用の汎用モデル言語ではなくドメインに特化したモデル言語（DSL）が用いられ、フレームワークのAPIに対してコードが生成される。生成されたコードには、新たなパターンの共通性が発見され、再びアーキテクチャとして確立され、プラットフォーム技術の高度化と抽象化が繰り返される。

　従来、プラットフォームといえばOS、ネットワーク・プロトコル・スタック、アプリケーション・サーバであったが、技術が複雑化した結果、高度化と細分化が進み、ドメイン単位のアーキテクチャの抽象化へと発展した。この進化をSoftware Factoriesではビューポイント（フレームワークやコンポーネント、DSL、IDE開発ツール、開発プロセスなどのセット）として支援している。

●可変性を実現する複合化技術

　可変性の重要な実現技術として、複合化（Composition）技術の存在がある。

　複雑で大規模広域化したソフトウェア・システムは、上流の分析段階でドメインやサブシステム（例えば、階層構造やパイプライン構造など）で分割され、それぞれの分割単位に対して最適なパラダイム、開発手法、設計手法、実装メカニズムが適用されて、実装とテスト段階で再結合される。この結合メカニズムの総称が複合化である。

　複合化技術としては、オブジェクト指向パラダイムでは代表的な「継承」やオブジェクト参照を使った「委譲」*6、そのほかのパラダイムとしては、SOA（Service Oriented Architecture）の「サービス・バインディング」、アスペクト指向の「アスペクト・ウィービング」などが存在する（図6）。

*6 GoF（Gang of Four）の代表的な23個のデザイン・パターンは、オブジェクト指向パラダイムの基本的な複合化技術である「継承」と「委譲」により実現可能である。これをアスペクト・ウィービングなど、別パラダイムの複合化技術で置き換えることも可能である。

　

図6　複合化技術の選択肢

複雑で大規模広域化したソフトウェア・システムは、上流の分析段階でドメインやサブシステムに分割されて設計され、それぞれの分割単位に対して最適な実装メカニズムを適用したソース・コードは、実装とテスト段階で再結合される。結合は一般的にコードが織り合う（＝ウィービングする：weaving）ように結合される。この結合メカニズムを複合化技術という。オブジェクト指向パラダイムでは代表的な継承、オブジェクト参照を使った委譲が存在する。.NET Framework 2.0では、複数ファイルに分割した同一クラス名を持つ実装クラスを結合するパーシャル・クラスが導入されるが、これも複合化技術の一種である。

　複合化技術は、バインディング・タイム（＝開発プロセスのどの段階で再結合の実現技術の決定を行うか）の要求に合わせて選択される。

　例えば、顧客クラスを特殊化して定義される得意先クラスなら、その形式のバリエーションは継承で設計時に、アルゴリズムの動的変更はStrategyパターンを使った委譲とコンポーネントの動的ロードを組み合わせで実行時に、サービス内容に合わせた機能の提供にはSOAで実行時に、監査などの非機能要求の手順の変更にはアスペクト・ウィービングでコンパイル時に実現する。

　これらの複合化技術によって可変性が実現されることで、共通性を提供するアーキテクチャに対して、手順やデータ構造の変更などの柔軟性が与えられる。そして、複合化技術のメカニズム決定をできるだけ開発プロセスの後半に遅延させることで、実装技術の変化や要求の変更に対して備えるのである。

　可変性のメカニズムを隠ぺいし、一般開発チームの開発者によるカスタマイズを容易にするためにDSLを提供することも、プロダクトラインの開発プロセスでは重要である。

　DSLは、C#、Java、C++などの汎用開発言語やUMLのような汎用モデリング言語とは異なり、特定ドメインでの定義やカスタマイズに特化した開発言語である。DSLは、従来の汎用言語よりも表現力が豊かで、理解しやすく、カスタマイズを単純化する。DSLというと、何か特別な開発言語をまた覚えなければならないと考えがちであるが、実際はプロパティ設定画面、ウィザード、業務フロー図、ネットワーク配置図など、従来からドメインごとに使っていた開発方法を、モデル定義の基盤技術として提供しただけである。

　DSLの設計や実装には、コンパイラやメタモデリングなどの知識が必要であるが、DSLを利用する一般開発チームの開発者には、複雑な知識や経験は必要ない。上級開発チームのアーキテクトが、DSL表現の理解のしやすさ、DSL利用の簡単化を、DSL設計の段階で考慮するからである。

　プロダクトライン開発では、上級開発チームのアーキテクトが重要な役割を演じる。すなわち、ドメインやサブシステム分割、全体のアーキテクチャの決定、可変性の実現技術としてパラダイムと複合化技術の選択などを担当する。アーキテクチャの品質とプロダクト開発における再利用性の高さがSoftware Factoriesの有効性を決める。そのため、広範な技術、経験のあるアーキテクトの重要性はますます増大するであろう。

◆「プロダクト生産」の開発プロセス

　プロダクト生産もしくはプロダクト開発は、プロダクトライン開発で開発されたソフトウェア資産を使い、特定の要求での開発を行うプロセスである。

　従来のUPやアジャイル開発プロセスで行っていた開発はすべて1回で完結する開発であるが、そのプロセスの中からアーキテクチャ開発を除いた残りの短期的視点の部分が、ここでいうプロダクト生産の開発プロセスだと考えてもよい。

　既存のフレームワークやコンポーネントを再利用し、特定の要求ごとのカスタマイズを加えて製造する量産フェイズである*7。可変性の実現技術であるDSLを利用することで、一般開発チームの開発者にとって、そのカスタマイズが容易になるだけでなく、開発可能な範囲がDSLで許容される範囲だけに制約されるので品質を確保することもできる。

*7 要求は従来のユースケースで定義してもよい。

　従来のフレームワークやコンポーネント・ベース開発では、クラス・ライブラリやコンポーネントのAPIを使った開発であったが、Software Factoriesのプロダクト開発では、DSLによるモデル図作成とウィザードやプロパティの設定を使うことが中心となり、APIによる開発機会を減少させる。現在のフレームワークの選択肢を提供し、考慮する開発環境から、Factoryの選択肢を提供し、考慮する開発環境へと移行する。

　DSLは広義のモデル開発言語であるので、Software Factoriesはモデル駆動型開発と見なせるが、DSLだけですべてのカスタマイズを行うことは現実的に不可能である。一部のコード開発が必要となる場合、あるいは、アーキテクトが想定したDSLの範囲を超えた要求の場合は、提供アーキテクチャの範囲外でのコード開発が必要となる場合が存在する。

　さらに、プロダクト生産の開発プロセスではモデルすら利用しない開発も存在する。この点ではSoftware Factoriesは必ずしもモデル駆動型開発ではない。

◆まとめ

　ソフトウェア開発では、要求の複雑化、要求の多様性、要求変化への対応と、開発の迅速化、品質や生産性の向上、開発コストの削減などを満足させるため、技術が高度化、複雑化する中、開発方法論や開発基盤技術のさらなる進化が求められている。ソフトウェア開発の工業化は、好むと好まざるとにかかわらず取り組まなければならない目標である。Software Factoriesがその解の1選択肢を与えるならば、真剣に検討する必要があるだろう。

　日本にはDOA（Data Oriented Approach）、Relaxer（データ・バインディング・ツール、スキーマ言語、開発方法論）、Ruby（プログラミング言語）のような優れた考え方や技術が存在し、ソフトウェア開発に携わる各社にはやはり実績のある開発基盤技術が存在する。これらの考え方や技術がSoftware Factoriesの考え方になじむのか、ソフトウェア工業化に向けた方向性やロードマップが描けるのかを評価し、アイデアやコメントをいただきたいと思っている。

　ソフトウェア開発者は、ソフトウェア・プロダクトラインの考え方が浸透していくと、開発者の2極化（上級開発チームと一般開発チーム）や、海外に開発をアウトソーシングするオフショア開発における日本の開発者の役割を考えていかなければならない。理想的には、世界で活躍する志の高いアーキテクトが、日本から多く出てくることが望まれる。

　次回以降の連載では、ソフトウェア・プロダクトラインのプロダクトライン分析における要求分析とドメイン工学の適用、プロダクトライン設計におけるアーキテクチャ・パターンとパターン言語の適用、プロダクトラインのソフトウェア資産であるコンポーネント仕様、DSLの基礎と提供などについて順次解説していくつもりである。

萩原 正義 Software Architect

1993年マイクロソフト入社。北海道大学、早稲田大学非常勤講師。.NET開発、アーキテクチャの調査研究と技術啓蒙に従事。アスペクト指向、フレームワーク実装技術、開発方法論、データ中心アプローチとオブジェクト指向分析／設計との融合、モデル駆動型アーキテクチャ、サービス指向アーキテクチャなどが現在の興味対象。趣味は、IT業界の著名人との雑談とウィンター・スポーツ。ソフトウェア技術の発展に貢献することが夢。

　

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第2回 開発手法「ソフトウェア・プロダクトライン」とは？
	1．開発手法「ソフトウェア・プロダクトライン」
	2．「プロダクトライン開発」と「プロダクト生産」の開発プロセス

　

「次世代開発基盤技術“Software Factories”詳解」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）