PDF版はこちら

成果報告書

第1.0版（2015年3月31日）
第1.1版（2015年4月1日）
第1.2版（2015年5月6日）

目次

  1. はじめに
  2. ソフトウェアプロダクトライン
  3. ソフトウェアプロダクトラインの進化
  4. 　ソフトウェア進化
  5. 　ソフトウェアプロダクトラインの導入
  6. 　ソフトウェアプロダクトライン進化に対する動機
  7. 　ソフトウェアプロダクトライン進化の特徴
  8. 　ソフトウェアプロダクトライン進化の種類
  9. 　プロダクトライン進化の計画
  10. 　ソフトウェアプロダクトライン進化のプロセスモデル
  11. 　進化の例
  12. 　ソフトウェアプロダクトラインの進化を支える技術
  13. 　　リファクタリング
  14. 　　変更影響分析
  15. 　　ソフトウェアリポジトリマイニング
  16. おわりに

はじめに

市場や技術が急速に変化するビジネス環境において，顧客や利用者の要求を満たすソフトウェアをいかに迅速に提供できるのかがIT事業を成功させる鍵である．特に，信頼性の高いソフトウェアを効率的に開発し，IT事業で利益を創出し続けるためには，既存の資産を最大限に活用することが重要である．しかしながら，実際，さまざまなシステムが，仕様変更への対応の繰り返しの結果として大規模化複雑化し，保守が困難となる状況に直面している．このような状況において，何の戦略を持たないまま既存資産を活用することは非常に困難である．

このような事態を解決する方法の一つとして，従来の新規開発や派生開発から，プロダクトライン開発[Pohl05]への移行が考えられる．ソフトウェアプロダクトライン(以下，SPL: Software Product Line)とは，共通の特性を持ち，特定の市場やミッションのために，共通の再利用資産(reusable asset)から規定された方法で作られる，ソフトウェア中心システムの集合を指す[Clements01, Pohl05]．

ここで，SPLもソフトウェアシステムである以上，その進化は避けられない．残念ながら，SPLにおけるプロダクト(製品)開発は通常のアプリケーション開発と異なり，SPLの進化をシステム単体の進化を同じように扱うことはできない[Botterweck14]．このような状況において，実際の開発現場や保守現場でSPL進化を実践するためには，理解しやすい進化モデルの構築が必須である．

このような観点から，本研究調査報告書では，SPLにおける進化プロセスのモデルを示すことで，SPL進化に対する理解の促進を目指す．さらに，そのSPL進化プロセスを支える技術を明確にすることで，SPL進化の開発現場および保守現場への普及を加速させる．

ソフトウェアプロダクトライン

通常，工業製品としてのソフトウェアを提供する際には，類似したソフトウェアを同時に，あるいは，時系列的に開発することが多い．たとえば，同じ製品であっても機能の一部を限定することでグレードを変えて提供したり，同じ製品を異なるプラットフォーム(ハードウェアやOSなど)で稼働するようにしたりす る[Kishi11]．

このような状況において，製品開発の生産性を向上させるためには，各製品で共通な部分を特定し，その共通部分を最大限に再利用することが望まれる．共通部分に対して，各製品に個別な特徴を付与することで，最終的な製品を導出する．ここでは，再利用可能な成果物(artifact)のことをSPL資産あるいはコア資産(core asset)と呼ぶ．SPL資産は，複数の製品系列に対して適用可能なように，あらかじめ共通部分と可変部分を織り込んで構築される．

このようにSPL開発では，再利用を強く推し進めることで，以下に示すことを目指している．

開発コストの削減
通常，プロダクトを個別に開発する場合，プロダクトを開発するたびに開発コストが増加する．これに対して，SPL資産を整備することにより，プロダクト群全体で開発コストを低く抑えることが期待できる[Pohl05]．ただし，SPL資産を最初に開発するためのコストが必要になる．この様子を図1に示す．

Figure 1

図1: SPL開発における開発コストの削減

品質の向上
プロダクトラインにおいて作成される成果物に対するレビューやテストは，単一のプロダクトではなく複数のプロダクトにおいて実施される．このため，不具合が発見されたり，それが修正される機会は増加する．結果的に，SPLで開発されたプロダクト全体の品質は向上する．
出荷までの時間の短縮
再利用なしでプロダクトを毎回開発するやり方では，開発するプロダクトの数が増えても各プロダクトに費やす開発時間はほぼ同じであり，それぞれのプロダクトの出荷までの時間はほぼ一定となる[Pohl05]．それに対して，SPLではSPL資産を整備する分だけ開発の初期に遅れがでるものの，それを乗り越えた後ではSPL資産に含まれる共通部品を開発する分の遅れがなくなるため，それ以降のプロダクトの出荷までの時間を短縮することが期待できる．この様子を図2に示す．

Figure 2

図2: SPL開発における出荷までの時間の短縮

次に，SPL開発の概要を示す．図3に示すように，SPLの活動は大きく，ドメインエンジニアリング(domain engineering)とアプリケーションエンジニアリング(application engineering)に分けられる[Pohl05])．ここで，文献[Clements01, Northrop02]では，これら2つの活動をそれぞれコア資産開発(core asset development)とプロダクト開発(product development)と呼ぶ．また，これら2つの活動を支援する技術的かつ組織的な管理(management)活動も追加している．ただし，本成果報告書では管理活動を対象としない．

Figure 3

図3: SPL開発の概要

ドメインエンジニアリング活動では，SPL資産の開発を指す．SPLアーキテクトは，SPLに対する要求を獲得し，プロダクトラインアーキテクチャ(SPLA: Software Product Line Architecture)を決定し，再利用可能なコンポーネントを実現する．SPL資産の開発において重要な作業にスコープの定義(スコーピング)がある．これは，SPLからどのプロダクトを導出するのか，どのプロダクトを導出しないのかの境界を明確にすることを指す．導出される可能性のあるプロダクト系列において可変な部分は可変モデルとして実装される．可変モデルにおいて，特定のプロダクト系列に固有な部分とすべてのプロダクト系列に共通な部分との分岐点を可変ポイントと呼ぶ．また，バリアント(variant)とは，可変ポイントに対する選択肢を指す．

プロダクトライン開発においてドメインにおける共通性や可変性を分析および定義するための代表的な手法に，フィーチャモデリング(feature modeling)[Kang90, Kang02]がある．フィーチャ(feature)とは，プロダクトが提供するサービス，操作性，性能など，そのプロダクトに関する代表的かつ観測可能な特徴のことを指す．

フィーチャモデル[Schobbens06]とは，フィーチャモデリングによって構築された可変モデルを指す．図4にフィーチャモデルの例を示す．この例において，すべてのプロダクト(Wiki)は必ずコンテンツタイプ(Content Type)を持ち，それは必ずテキスト(Text)を備える．画像(Image)については，備えていても備えていなくともよい．また，検索機能(Search)を持つかどうかは各プロダクトに依存し(検索機能を持たないプロダクトが存在することもあり)，それは全文探索(Full-text Search)あるいは見出し検索(Index Search)のどちらかあるいは両方を備えている．

Figure 4

図4: 可変モデルの例: フィーチャモデルとSPL資産の対応

ここでは，単純に１つのフィーチャが1つの再利用可能コンポーネントに対応している．しかしながら，実際のフィーチャモデルではさまざまなSPL資産(要求仕様，実装コード，テストケース，アーキテクチャ，ドキュメント)およびそれらを組み合わせたものがフィーチャに対応することがあることに注意する必要がある．

アプリケーションエンジニアリング活動では，プロダクト要求を満たすように設定されたプロダクト構成に基づき，SPL資産からプロダクトを導出し，各プロダクトで必要となる機能や特性を実現する．可変モデルとしてフィーチャモデルを採用し，フィーチャとSPL資産やバリアントとの対応がとれている場合には，適切なフィーチャを選択あるいは削除することで，プロダクトの実装を得ることができる．プロダクト要求に対してフィーチャの選択や削除だけで対処できない場合は，プロダクトに特化した実装を追加することになる．

Figure 5

図5: SPLにおける資産

ドメインエンジニアリング活動とアプリケーションエンジニアリング活動に現れる資産を図5に示す[Schobbens06, Botterweck14]．SPLおよびプロダクトにはそれぞれ異なる抽象度(要求モデル，可変モデル，実装モデル)の成果物が存在する．また，それぞれの成果物は，次の3種類に分類できる．

共通資産
すべてのプロダクトに共通する資産(common asset)を指す．これは，ドメインエンジニアリング活動において，あらかじめSPL資産として定義する．アプリケーションエンジニアリング活動では，要求モデル，可変モデル，実装モデルのすべてがSPL資産から直接導出される．
可変資産
個々のプロダクト構成に依存する資産(variable asset)を指す．共通資産と同様に，ドメインエンジニアリング活動において，あらかじめSPL資産として定義する．アプリケーションエンジニアリング活動では，個々のプロダクトに対する要求モデルに基づき，可変モデルにおいて適切なバリアントを選択する．個々のプロダクトに対するバリアントが選択されると，バリアントに対応する実装モデルがSPL資産から導出される．
プロダクト固有資産
SPL資産に存在しない機能や特性を実現するために，個々のプロダクトに応じて用意する資産(product-specific asset)を指す．アプリケーションエンジニアリング活動において，要求モデルに基づき実装モデルを作成する．また，要求モデルの定義や実装モデルの作成はプロダクトごとに実施されるため，プロダクトに対する可変性を考慮する必要はない．

Figure 6

図6: フィーチャの選択とプロダクトの開発

図6に，アプリケーションエンジニアリング活動において，プロダクトを開発する例を示す．まず，フィーチャを選択することでSPL資産から共通資産と可変資産を導出する．WikiおよびText Processorは共通資産として導出されたコンポーネント(要求モデル，可変モデル，実装モデル)，Full-text SearchおよびImage Processorは可変資産として導出されたコンポーネント(実装モデル)を指す．これらのコンポーネントは，プロダクトラインアーキテクチャ上において結合される．次に，Audio Processorコンポーネント(要求モデル，実装モデル)を追加することで，プロダクトEを作成する．Audio Processorコンポーネントはアプリケーションエンジニアリング活動におけるプロダクト固有資産となる．

ソフトウェアプロダクトラインの進化

本章では，まずソフトウェア進化について述べる．その後，SPLの導入戦略とSPL進化を概要する．最後に，SPL進化プロセスのモデルを示し，進化プロセスに関連 する技術を説明する．

ソフトウェア進化

ソフトウェア進化とは，一旦出荷されたソフトウェアに対する変更を受け入れる仕組みや活動を指す[Madhavji06, Mens08, Omori12]．通常，個体\(生物など)に対して，それ自体が変化することを進化とは呼ばない．進化とは，互いに似ている一群の個体を指す種(species)に対して，世代を越えて発生する現象である．

ここで，ソフトウェアにおける種を同一のSPL資産から導出されるプロダクト群で捉えることで，プロダクトの導出は世代を超えて発生していると見なせる[Jazayeri05]．一方，SPL資産や導出されたプロダクトの保守においては，それらの一部だけを書き直したり入れ替えたりすることで，新たなSPL資産やプロダクトを作成していることが多い．このように作成されたSPL資産やプロダクトが世代を超えていると見なせるかどうかは開発者や利用者の意識に依存する．

そこで，本成果報告書では，SPL資産やプロダクトの変更が世代を超えているかどうかに関わらず，進化と捉えることにした．

ソフトウェアプロダクトラインの導入

SPLの導入(adoption)には，以下の4つの戦略がある[Schmid02]．

独立型(Independent)
プロダクトの開発を始める前に，既存のプロダクトとは独立に，SPL資産を準備する戦略を指す．最初に大きな投資が必要なため，今後開発するプロダクトに対する一定の見通しが明確な場合に有効である．Pure PL[DeBaud98]，Proactive[Krueger02]とも呼ばれる．
借入型(Leveraged)
すでに存在するSPL実装から活用可能な部分を取り出し，新たなSPL資産を作成する戦略を指す．活用可能なSPL実装が容易に見つかり，それに対する深い知識がある場合には有効である．
プロジェクト組込み型(Project-integrating)
プロジェクトの遂行時に，プロダクト開発とSPL資産の開発を同時に行う戦略を指す．Project-integrating PL[DeBaud98]，Reactive[Krueger02]とも呼ばれる．プロダクトの要求が，今後開発するプロダクトに対しても同様に発生すると判断された場合，SPL資産の更新を行う．SPL資産をインクリメンタル(incremental)に開発するため，その初期開発コスト(初期投資)を削減することが可能である．

リエンジニアリング型(Reengineering-driven)
既存のプロダクト群を分析し，それらの間の共通性や可変性を識別することで，SPL資産を抽出する戦略を指す．既存プロダクトと同様のプロダクトの作成が今後も見込まれる場合に有効である．Reengineering-enabled PL[DeBaud98]，Extractive[Krueger02]とも呼ばれる．

一般的に，独立型と借入型は革命的な(revolutionary)戦略，プロジェクト組込み型は進化的な(evolutionary)戦略である．また，既存のSPLが存在しない場合のリエンジニアリング型は革命的な戦略，既存のSPLに外部資産を組み入れていくリエンジニアリング型は進化的な戦略である．本成果報告書では，プロジェクト組込み型とリエンジニアリング型をSPLの進化として扱う．

ソフトウェアプロダクトライン進化に対する動機

図1と図2において，SPL開発がプロダクト群全体の開発コストを引き下げる可能性と出荷までの時間を短縮できる可能性を持つことを説明した．

開発コストの削減という観点では，SPL資産の準備にかかる初期開発コストをいかに削減するかということと，個々のプロダクトの作成にかかる開発コストをいかに削減するかということが重要である．SPL進化では，独立型戦略により膨大なSPL資産をあらかじめ準備するのではなく，プロジェクト組み入れ型戦略やリエンジニアリング型戦略により段階的にSPL資産を増やしていくことで，前者のコスト削減が期待できる[Schmid02]．また，SPL進化によりSPL資産を改善することで，後者のコスト削減も期待できる．たとえば，あるSPL資産から導出されたプロダクト群に同じフィーチャが何度も固有に実装されている場合を考える．このようなフィーチャを共有化できるようにSPL資産を進化させることにより，次のプロダクト開発において実装コストを抑えることができる．SPL資産の進化が開発コストを削減させる様子を図7に示す．

Figure 7

図7: SPLの進化による開発コストの削減

出荷までの時間の短縮という観点では，SPL資産の準備による遅れをいかに短縮するかということと，個々のプロダクトの作成にかかる開発時間をいかに削減するかということが重要である．SPL進化では，開発コストの削減と同様に，段階的にSPL資産を増やしていくことで前者の時間短縮，そのSPL資産を段階的に改善することで後者の時間短縮が期待できる．SPL資産の進化が出荷までの時間を短縮させる様子を図8に示す．

Figure 8

図8: SPLの進化による開発コストの削減

ソフトウェアプロダクトライン進化の特徴

SPL進化による開発の総コスト削減と出荷までの時間短縮は魅力的である．その反面，BotterweckとPleussは，SPLの進化は以下に示す3つの課題に直面していることを指摘している[Botterweck14]．

SPL開発は通常のプロダクト開発と異なるため，SPLの進化をプロダクト単体の進化を同じように実現することはできない．特に，SPL開発では，ドメインエンジニアリング活動とアプリケーションエンジニアリング活動が明確に区別され，あらかじめ用意しておいたSPL資産から要求に応じたプロダクトの作成が行われる．よって，SPL進化では，SPL資産の進化とプロダクトの進化を考える必要がある．

我々は，これら2つの進化は密接に結びついており，共進化(co-evolution)を引き起こすと考えている．たとえば，ビジネス戦略やビジネス形態の変化により，SPL資産が変更された場合，それを用いて作成されているプロダクトにも変更が発生する可能性は高い．反対に，変更要求に合わせてプロダクトが書き換えられると，プロダクト群に共通部分が生み出されたり，既存の共通部分が消えたりすることがある．このような状況において，プロダクトを効率的に開発するためには，共通部分のSPL資産への組み込みやSPL資産の改訂を行うことは当然である．

SPL進化における課題を克服し，現実の開発現場や保守現場においてSPL進化を適切に実践していくための第一歩として，SPL進化におけるプロセスモデルを理解しておくことは重要である．

ソフトウェアプロダクトライン進化の種類

SchmidとEichelbergerは，SPL進化における資産の変化や変化による影響を以下のようにまとめている[Schmid08]．ここで，SPL資産とは共通資産と可変資産を指す．

要求レベルの変化
ビジネスゴールの変更などに応じて，ドメインエンジニアリング活動において作成するSPL資産に対する要求や，アプリケーションエンジニアリング活動において作成する個々のプロダクトに対する要求が変化することを指す．この変化は，図4における共通資産，可変資産，プロダクト固有資産に影響を与える．
プロダクトレベルの変化
SPL資産からプロダクトを導出したり，不要なプロダクトを削除したりすることを指す．一般的に，この変化は，図4における共通資産，可変資産，プロダクト固有資産に影響を与えない．ただし，フィーチャインタラクション(feature interaction)[Lee04]による影響のため，SPL資産からプロダクトを導出する場合に，特定の組み合わせのフィーチャに対応する実装の変更が要求されることがある．
SPLレベルの変化
新規にSPLが構築されたり，不要なSPLが削除されたり，複数のSPLが合併したり，単一のSPLが分割されることを指す．この変化は，SPLの階層化などにより発生する．この変化は，図4における共通資産，可変資産，プロダクト固有資産に影響を与える．

ここで，本調査研究では，単一のSPLに関する進化に焦点を当てる．つまり，SPLレベルの変化は対象としない．また，図4における共通資産，可変資産，プロダクト固有資産に影響を与えるSPL進化を扱うため，プロダクトレベルの変化も対象としない．結果的に，本調査研究では要求レベルの変化を対象とする．

Figure 9

図9: 資産に対する要求レベルの変化とその影響

図5における共通資産，可変資産，プロダクト固有資産において発生する要求レベルの変化とそれらの影響を図9に示す．資産間の関係において，実線は要求レベルの変化がすべてのプロダクトに影響を与えること，破線は要求レベルの変化がいくつかの(複数の)プロダクトに影響を与えること，点線は要求レベルの変化がそれに関係する個々のプロダクトだけに影響を与えることを指す．

Figure 10

図10: SPL進化におけるフィーチャモデルの変更

ここで，図9に示した資産間の関係を，例を用いて説明する．いま進化において，図4のフィーチャモデル(図10の矢印の左側)が図10の矢印の右側のフィーチャモデルに変更された場合を考える．

図10に示すように，WikiフィーチャとSearchフィーチャの関係が「選択」から「必須」に変化した場合，可変資産の一部に「共通化」が適用され，共通資産に変化したと見なせる．この場合，すべてのプロダクトが必ずSearchフィーチャを備えることになる．これは，すべてのプロダクトに対して要求レベルの変化が影響することを指す．

これに対して，Content TypeフィーチャとTextフィーチャとの関係が「必須」から「選択」に変更された場合を考える．これは，共通資産の一部に「可変化」が発生したと見なせる．この場合，すべてのプロダクトがTextフィーチャを備えているという前提が取り除かれ，いくつかのプロダクトではTextフィーチャを持たないことが許されるようになる．この変化による影響は，すべてのプロダクトではなく，一部のプロダクトに限定される．

「共通化」と「可変化」は，共通資産と可変資産の間の関係であるのに対して，「一般化」と「特殊化」は可変資産とプロダクト固有資産の関係である．いま，アプリケーションエンジニアリング活動においてAudio機能を持つプロダクトが作成された場合，Audio機能に関する要求と実装がプロダクト固有資産として蓄積される．図10では，プロダクト固有資産に対して「一般化」を適用することで，AudioフィーチャがContent Typeフィーチャの「選択」関係を持つ子要素として追加されていることを表している．これとは反対に，「特殊化」により，可変資産に含まれるフィーチャがプロダクト固有資産に変わる可能性もある．

また，SPL進化において，それぞれの資産内における要求の変更も発生する．さらには，外部資産の一部を採用したり，流用したりすることもある．

プロダクトライン進化の計画

プロダクトライン進化の計画とは，次のSPLのバージョンアップに対して何を変化させるのかを決めることであり，事業の成功に本質的な影響を及ぼす意思決定をすることに相当する[Botterweck14]．プロダクトライン進化の過程では，年次モデル，グレード，仕向け地ごとにさまざまな製品バリエーションを，長期間に渡り維持管理し，関係するステークホルダも変化することが予測される．プロダクトラインの進化を無計画に進めると，さまざまなリスクの発生が考えられる．想定されるリスクとしては，製品開発ロードマップに描かれた製品を開発するために必要な要求がコア資産から漏れる，コア資産や製品開発のリソースが不足することなどがある[Ruhe10]．

プロダクトラインの進化の計画立案では，市場，技術，組織の変化を考慮し，要求の範囲とタイミングを決定し，ステークホルダ間で合意形成する．この計画立案において，開発のスコープ，つまり何を開発すべきかを定める要求定義は重要であり，限られたリソースで開発する場合には，要求の優先度を定義することが必要である[Mead06]．

要求の優先度を決めるために，既にさまざまな手法が考案されている．要求の優先度を決めるためのシンプルな方法として，MosCow[IIBA09]，要求に1～5などの数値(ポイント)を付与する方法[JISA11]，100ドルテスト[Leffingwell03]がある．また，複数の視点を組み合わせて要求を評価する手法として，コスト－バリューアプローチ[Karlsson97]や，重要度と緊急度による4象限方式[Wiegers03]などがある．これらの手法は，各要求を複数の軸で定量化し，図面に可視化して評価結果を示し，複数のステークホルダ でも直観的に共通理解に到達しやすくする．しかし，プロダクトラインの進化に対する要求の優先度定義では，さまざまなシリーズ製品を多くのステークホルダにより長期間に渡り維持管理する状況にあり，ステークホルダの要求への優先度そのものが変化する可能性もあるため，既存の要求の優先度手法をそのまま活用するだけでは有効ではない．

Ruleは，release planningと呼ぶシリーズ製品開発における要求の優先度定義手法を提案している[Ruhe10]．この手法では，要求を評価する基準，ステークホルダ，各要求への制約，要求間の依存関係などの複数の観点から要求を評価し，要求の範囲を決定する. 要求を評価する基準の例として，顧客満足度(customer satisfaction)，顧客不満度(customer dissatisfaction)，開発リスク(risk of implementation)，顧客の受容リスク(risk of acceptance)，財務的価値(financial value)，コスト(cost)，緊急度(urgency)，準備度(readiness)，使用頻度(frequency of use)，使いやすさ(ease of use)などが提案されている．また，ツールEVOLVE[Ngo-The08]により，要求の優先度を可視化し，優先度の計算の自動化を支援している．

プロダクトライン進化の期間は，単一システムの開発と保守の期間よりも，長期に渡ると考えられる．プロダクトライン進化の過程で，開発の意思決定に関わったステークホルダも変化することで，過去のプロダクトライン開発における意思決定の根拠があいまいになり，その後の意思決定が適切に行われないリスクが高まると考えられる．このようなリスク回避のため，Tangらは，設計に関わる意思決定の根拠を蓄積し共有することを提案している[Tang05]．さらに，Schubanzらは，プロダクトライン進化の計画に関係する情報である，組織のゴール，要求の評価基準，意思決定の根拠そのものも進化すると考え，体系化さ れた手法に基づきプロダクトライン進化を扱うことの重要性を指摘している[Schubanz13]．

ソフトウェアプロダクトライン進化のプロセスモデル

ここでは，SPL進化におけるプロセスモデルを示す．我々は，図3に示したSPL開発の一般的なプロセスに基づき，図9に示す資産間の関係を考慮して，進化プロセスのモデルを構築した．モデルの構築においては，文献[Botterweck14]を参考にした．図11にSPL進化のプロセスモデルを示す．

Figure 11

図11: SPL進化のプロセスモデル

ここで，SPL進化はSPL開発を内包しており，大きくドメインエンジニアリング活動とアプリケーションエンジニアリング活動に分けられる．実際には，SPL進化には，プロセスそのものを改善するメソッドエンジニアリング活動も含まれるが，本調査研究では検討していないので省略する．四角形は成果物，楕円形は活動(アクティビティ)，六角形は評価による判断を必要とする活動を表す．

ドメインエンジニアリング活動では，SPL要求を受けてドメイン分析が行われ，可変モデルが作成される．その後，SPL要求と可変モデルに基づきドメイン実装が行 われ，SPL資産(SPL実装)が構築される．図4に示したように，可変モデルのフィーチャとSPL実装に含まれる要素との間には対応付けが行われている．

アプリケーションエンジニアリング活動では，プロダクト要求を受けて，プロダクトの構成定義が実施される．これによりプロダクト構成が構築され，それに基づきプロダクトの部分実装の導出が行われる．同時に，SPL資産(共有資産および可変資産)で未対応であったプロダクト固有部分に対する実装が行われる．この実装は，プロダクト固有資産として蓄積される．最後に，プロダクトの組み立てにおいて，プロダクトの部分実装とプロダクト固有実装が統合され，プロダクトの実装が完成する．

SPL開発は，一般的にこのようなプロセスにより実施される．我々は，このようなSPL開発において，5つの進化プロセス(図11のE1〜E5)をモデル化した．以下，進化プロセスE1〜E5をそれぞれ説明する．

進化プロセスE1

既存の外部資産(プロダクト群)やプロダクト固有資産がある場合，それらをSPL資産として採用するかどうかを判断し，採用すると判断した場合に実施するSPL資産の進化を指す．これは，「ソフトウェアプロダクトラインの導入」で述べたリエンジニアリング型戦略における進化に対応する．この進化では，既存の外部資産やプロダクト固有資産における共通性や可変性を識別し，それらをSPL資産として抽出することが主な活動になる．

この進化プロセスを実現する方法として，RE-PLACE[Bayer99], OAR[Bergey01], MAP[Stoermer01, OBrien02]，Evolutionary Introduction[Simon02]などがある．また，Sheらは抽出したフィーチャ 間の依存関係に基づき，フィーチャモデルの階層や条件を見つけ出す手法を提案している[She11]．さらに，フィーチャ特定(feature location)[Biggerstaff93, Wilde03, Dit13]が，この進化を支援する．フィーチャ特定とは，着目するフィーチャを(直接的に)実装しているコード(の一部)を特定することを指す．

進化プロセスE2

プロダクトの要求と可変モデルから導出されるプロダクト構成を照らし合わせ，その妥当性(特定のフィーチャをプロダクト固有資産で実装することが妥当であるかどうか)により実施するSPL資産の進化を指す．これは，「ソフトウェアプロダクトラインの導入」で述べたプロジェクト組込み型戦略における進化に対応する．いま，新たなプロダクトを開発しようとした場合を考える．その際，まずプロダクト要求がプロダクトに固有なものであるのか，あるいは今後開発されるプロダクトにおいても発生する可能性があるのかを検討する．今後も発生する可能性が高いと判断された場合は，プロダクトの開発を一旦中止し，プロダクト要求に合わせてSPLの進化を実施する．SPLの進化が完了した後，もとのプロダクトの開発に戻る．今後も発生する可能性が低いと判断された場合は，プロダクトの要求をプロダクト固有資産で吸収する．

この進化プロセスを実現する手法として，PuLSE-Eco[DeBaud99]やPuLSE-EM[Bayer99b], Rapid Feedback[Heider10], Issue-based Variability Management[Thurimella12]などがある．

進化プロセスE3

プロダクトの構成とプロダクトの部分実装を参照して，それらの間の整合性(一貫性)を検証し，不整合な部分が存在する場合にそれを取り除くための実施されるSPL資産の進化を指す．たとえば，プロダクト構成に現れるフィーチャ間に重複や干渉が発生した場合，それを取り除くようにSPL資産を再構成する．また，プロダクト構成に現れるフィーチャ群とそれらに基づき導出されたプロダクトの部分実装の振る舞いに矛盾が発生する場合，矛盾を取り除くようにSPL資産を修正する作業を指す．

この進化プロセスを実現する方法として，モデル検査に基づく手法[Guo12, Cordy12]やクローン検出に基づく手法[Mende08]がある．他にも，文献[Noda13]では，SPL進化において利用な形式手法(formal method)(フィーチャモデルの形式化と検証[Benavides10]など)が紹介されている．

進化プロセスE4

可変モデルやSPL実装を更新したことで実施するプロダクトの進化を指す．たとえば，稼働中のプロダクトの実装においてプロダクト固有資産で実現していたフィーチャがSPL資産で提供されるように変更された場合，プロダクトを再開発した方が将来の保守コストの削減が見込める可能性がある．また，稼働中のプロダクト実装では見送られていたフィーチャがSPL資産で提供されるようになることもある．このような場合，更新後のSPL資産を利用してプロダクトの再開発が実施される．この進化プロセスは，ISO14764[ISO14764]の完全化保守(perfective maintenance)に対応する．

進化プロセスE5

稼働中のプロダクトの実装に対する要求の変化や実行環境の変化に応じて実施するプロダクトの進化を指す．この進化プロセスは，ISO14764[ISO14764]の適応保守(adaptive maintenance)や完全化保守に対応する．

ここで，進化プロセスE1，E2，E3に共通する支援技術にリファクタリング(refactoring)がある．リファクタリングとは，既存ソフトウェアの外部的挙動を保存したままで内部構造を改善することを指す．また，進化プロセスE2とE3を支援する技術に変更影響分析(change impact analysis)がある．変更影響分析とは，ソフトウェアの一部が変更されたとき，その変更の影響範囲を正確に把握することを指す．さらに，進化を適切に管理するためには，過去に実施された進化を分析する必要がある，このための方法のひとつにソフトウェアリポジトリマイニング(MSR: Mining Software Repository)がある．SPL進化におけるリファクタリング，変更影響分析，ソフトウェアリポジトリマイニングの活用については，それぞれ「リファクタリング」，「変更影響分析」， 「ソフトウェアリポジトリマイニング」で述べる．

我々のSPL進化プロセスモデルとは別に，ScmidとVerlageはSPLの進化を以下の3つに分類している[Schmid02]．

インフラストラクチャベース(infrastructure-based)
プロダクトに対する新規要求に応じて，すぐにSPL資産の汎化(generalization)を実施する進化を指す．これは，図11の進化プロセスE2に相当する．
分岐/統合(branch-and-unite)
プロダクトに対する新規要求に応じて，すぐにSPL資産の汎化を実施するのではなく，SPL資産に対して新たなブランチ(SPL資産の複製)を作成することで対処する進化を指す．プロダクトの実装が完了した後で，プロダクト固有資産をSPL資産に取り込む．これは，図11の進化プロセスE1に相当する．
一括(bulk)
プロダクトの実装が完了するごとにSPL資産への取り込みを実施するのではなく，ある程度の量のプロダクト固有資産が蓄積された後で，一括してプロダクト固有資産をSPL資産に取り込む進化を指す．これは，図11の進化プロセスE1に相当する．

進化の例

図11に示した進化プロセスE1〜E5をまとめたものを図12に示す．E1とE2はプロダクト進化により発生するSPL進化であることが分かる．また，E4はSPL進化により発生するプロダクト進化であることが分かる．E3とE5は，それぞれSPL進化とプロダクト進化に閉じている．これらの進化は単独で発生することもあれば，連続して発生することもある．

Figure 12

図12: SPL進化における進化プロセス

Figure 13a

Figure 13b

図13: SPL進化の例

この様子を，図13に示す例を用いて説明する．

  1. 新たなビジネス要求が発生したため，SPL実装ca3を利用してプロダクトの開発を開始する．プロダクト構成pa3-1を導出し，それとプロダクト要求に対して妥当性評価を行う．妥当性評価の結果により，進化プロセスE2が実行される(SPL実装ca4が作成される)．SPL進化が完了した後にプロダクト開発を再開し，プロダクトpa4-1を作成する．
  2. このプロダクトpa4-1に対して利用評価が行われ，その結果により進化プロセスE5が実行される(プロダクトpa4-2が作成される)．
  3. ビジネス戦略の変更により，SPL実装ca4への進化が実施され，SPL実装ca5が作成されている．このSPL進化に対して完全化評価が行われ，その結果により進化プロセスE4が実行される(プロダクトpa5-1が作成される)．
  4. 新たなビジネス要求が発生したため，SPL実装cb4を利用してプロダクトの開発を開始する．プロダクト部分実装pb4-1を導出し，それとプロダクト構成に対して整合性評価を行う．整合性評価の結果により，進化プロセスE3が実行される(SPL実装cb5が作成される)．SPL進化が完了した後にプロダクト開発を再開し，プロダクトpb5-1を作成する．
  5. 新たなビジネス要求により，プロダクトpb5-1に対して進化が実施され，プロダクトpb5-2が作成される．また，要求によっては，SPL実装cb5から別のプロダクトpb5-3が作成される．このようなプロダクトの開発により，プロダクト固有資産が蓄積される．その結果としてSPL実装cb5に対して進化プロセスE1が実行される(SPL実装cb6が作成される)．

SPL進化の事例は，文献[Svahnberg99, Maccari02, Deelstra05, Kang05, Kato13, Inoki14]などで報告されている．また，SPLの進化にはさまざまな成果物が関係するため，それを実現するためのツール支援は必須である．たとえば，EvoFM[Pleuss12]では，フィーチャモデルにおいて同時に追加あるいは削除される可能性のあるフィーチャ集合をフラグメントとしてまとめる．フラグメントに対する変更とフラグメント内の変更を明確に区別することでフィーチャの変更が扱いやすくなり，SPLの進化計画の容易化が期待できる．Botterweckらは，EvoFMに基づくツールを提案されている[Botterweck09, Botterweck10]．また，Heiderらは，過去のプロダクト構成定義を記録しておくことで，プロダクトを自動導出するツールを提案されている[Heider12]．このツールでは，SPL資産が更新された場合に，過去のプロダクト構成定義を可変モデルに適用し，新たな版のSPL資産から新たな版のプロダクトを導出する．

ソフトウェアプロダクトラインの進化を支える技術

　ここでは，SPL進化を支える技術として，リファクタリング，変更影響分析，ソフトウェアリポジトリマイニングについて概説する．

リファクタリング

リファクタリングとは，既存ソフトウェアの理解性や変更容易性を向上させることを目的とした上で，外部的挙動を保存したままで内部構造を改善することを指 す[Fowler99]．一般的には，リファクタリング前後で，同一の入力値集合(外部入力)に対して同一の出力値集合(外部出力)が得られることを，外部的挙動が保存されているという．また，リファクタリングでは，大きな設計変更を小さな変換の繰り返しで実現することで，挙動の保存を保証するのが特徴である．

SPLの進化では，既存プロダクトからSPL資産を構築するためのリファクタリング(SPL資産を抽出したりSPL資産に変形させたりするリファクタリング)と，すでに存在するSPL資産を再構築するリファクタリングを区別して考える必要がある[Botterweck14]．

まず，SPL資産を構築するためのリファクタリングを紹介する．Kolbらは，PuLSE-DSSA[Bayer99]において既存のソフトウェアコンポーネントからSPL実装を作成する際にリファクタリングを適用した事例を報告している[Kolb06]．基本リファクタリングとより高度なリファクタリングを適用することでソースコードを再構成し，SPL実装の改善に成功している．また，Liuらは，既存アプリケーションのコードを分割するリファクタリング(feature-oriented refactoring)を提案している[Liu06]．このリファクタリングでは，アプリケーションの提供するフィーチャをモジュールの合成として捉え，モジュール関係を再構成することで，もとのアプリケーションの振る舞いを保存したままでフィーチャを抽出する．さらに，RubinとChechikは，類似する複数のプロダクトのモデル(UMLのステートチャートなど)の性質に基づき，SPLにおける共通資産の抽出を支援する手法を提案している[Rubin12]．この手法では，プロダクトのモデルを合成して作成したモデルが，もとのプロダクトのモデルの性質を変えない(合成したステートチャートがもとのステートチャートにおける状態遷移をすべて満たしている)場合をリファクタリングと見なしている．

これらのリファクタリングは主に進化プロセスE1を支援する．ここで，既存のプロダクトからSPL資産を抽出するためには，既存プロダクトに対する十分な理解が必要である．よって，図11の進化プロセスE1の実施においては，従来のコードリファクタリング[Fowler99]も頻繁に利用される．

次に，すでに存在するSPL資産を再構築するリファクタリングを紹介する．Critchlowらは，プロダクトラインアーキテクチャに対するリファクタリングを提案している[Critchlow03]．各コンポーネントが提供するサービスと各コンポーネントが要求するサービスに対するメトリクス値を求めることで，プロダクトラインアーキテクチャに関する構造の欠陥を検出する．この欠陥を除去するためのリファクタリングが定義されている．これに対して，Avlesらは，フィーチャに着目したリファクタリングを提案されている[Alves06]．このリファクタリングは，変換前後のフィーチャモデルから導出されるプロダクト群の構成が同じであることを保証し，その上でプロダクトの構成可能性(configurability)の改善を目指している．また，Schulzeらは，フィーチャ組み合わせにおける可変性を保証するリファクタリングを提案している[Schulze12]．さらに，Nevesらは，変換前後のフィーチャモデルから導出されるプロダクト群の構成だけでなく，それらを実現するプロダクトの部分実装の同一性も保証する理論体系[Borba12]に基づくリファクタリングを提案している[Neves11]．

これらのリファクタリングは主に，進化プロセスE2とE3を支援する．ただし，進化プロセスE1においても，既存のSPL資産に新たなSPL資産を統合する際には利用できる．

変更影響分析

ソフトウェア進化においては，ソフトウェアの変更は避けられない．通常，ソフトウェアの構成要素に対する変更は直接書き換えた部分だけにとどまらず，他の多くの構成要素にも影響を及ぼす．このような影響に関して，その範囲を正確に把握することを目的とした技術に，変更影響分析(change impact analysis)[Arnold93, Bohner96, Lehnert11]がある．

変更影響分析は，大きく依存解析(dependency analysis)とトレーサビリティ解析(traceability analysis)に分けられる[Bohner96]．前者は，プログラムの構成要素間に現れる依存関係(データ依存関係，制御依存関係，関数の呼び出し関係など)を解析する作業を指す．後者は，ソフトウェア開発工程(要求，設計，実装，テスト，保守)において作成されたあらゆる成果物(要求文書，設計文書，実装コード，テストケース，バグレポート，変更要求チケット)を対象とする[Bohner02, Chen09]．これらの成果物の間に現れる論理的なリンク(logical link)をあらかじめ識別しておき，変更時にそのリンクをたどることで変更を追跡し，その影響範囲を特定する．

SPL進化では，ドメインエンジニアリング活動における可変モデルやSPL資産に対する変更と，アプリケーションエンジニアリング活動におけるプロダクトに対する変更を適切に管理することが要求され，その作業は複雑である．ここでは，SPLを対象としたトレーサビリティ解析を紹介する．JirapanthongとZismanは，SPL開発に現れる8種類の文書(フィーチャモデル，サブシステムモデル，プロセスモデル，モジュールモデル，ユースケース，クラス図，ステートチャート，シーケンス図)に対して，9個のトレーサビリティリンク(Satisfies, Depends-On, Overlaps, Evolves, Implements, Refines, Similar, Different)を定義している[Jirapanthong09]．これらのリンクは，あらかじめ用意しておいた規則に基づき自動的に検出する．これに対して，Anquetilらは，より洗練された4つの直交するトレーサビリティリンクを定義している[Anquetil10]．これらのリンクを以下で説明する．

  1. Refinementリンクは，ドメインエンジニアリング活動やアプリケーションエンジニアリング活動に現れる異なる抽象度(要求と設計，設計と実装など)の成果物を関連付ける．
  2. Similarリンクは，ドメインエンジニアリング活動やアプリケーションエンジニアリング活動に現れる同じ抽象度(要求内部や設計内部など)の成果物を関連付ける．
  3. Variabilityリンクは，RealizationとUseに分かれる．Variability /Realizationリンクは，ドメインエンジニアリング活動における可変モデルの構成要素(フィーチャなど)とその実装(実現)を関連付ける．一方，Variability/Useは，アプリケーションエンジニアリング活動に現れる要素とドメインエンジニアリング活動に現れる要素を関連付ける．
  4. Versioningリンクは，ドメインエンジニアリング活動やアプリケーションエンジニアリング活動において，連続する2つの版間に現れる要素を関連付ける．

SPLにおける成果物を静的に解析するのでなく，回帰テスト(regression testing)を用いて変更影響分析を行う手法がHeiderらによって提案されている[Heider12b]．この手法では，SPL資産が変更された際，その変更前にプロダクトを導出した際のプロダクト構成定義を利用して変更後のSPL資産からプロダクトを導出する．変更前のプロダクトに対するテストを変更後のプロダクトに適用し，その結果からプロダクト実装に対するSPL資産の変更影響範囲を特定する．

変更影響範囲の対象をフィーチャモデル(とその実装)に限定した手法もいくつか提案されている．Acherらは，フィーチャモデルのフィーチャとそれらの関係を形式的に表現することで，2つのフィーチャモデル間の構文的な差分と意味的な差分を定義している[Acher12]．このような差分を定義することで，フィーチャモデルの合成や分割が形式的に適用できる．

Thümらは，SPL進化において編集前後のフィーチャモデルから導出可能なプロダクトの集合の関係に基づき，フィーチャモデルの変更を4つに分類している[Thum09]．編集前後で導出されるプロダクト集合が変化しない場合をRefactoring, 編集後のプロダクト集合が編集前のプロダクト集合を包含する(プロダクトが追加されているのみの)場合をGeneralization, 編集前のプロダクト集合が編集後のプロダクト集合を包含する(プロダクトが削減されているのみ)場合をSpecializationと呼ぶ．プロダクト集合の包含関係がこれら3つで当てはまらない場合は，任意の編集となる．さらに，Seidlらは，フィーチャモデルとその実装(UMLモデル)との対応関係(問題領域と解領域を結ぶリンク)に着目し，フィーチャモデルとSPL資産の共進化を分類している[Seidl12]．フィーチャモデルやSPL資産の構成要素に対する変更が，それぞれフィーチャモデルやSPL資産に閉じている場合をIntra-spatialと呼ぶ．一方，構成要素の変更が対応関係にまで影響する場合と，対応関係だけでなく対応先の構成要素にまで影響する場合をInter-spatialと呼ぶ．

ここで紹介した手法を導入することにより，進化プロセスE2とE3における変更やその影響範囲が明確になる．これにより，誤ったSPL進化を避けることや適切なSPL進化を計画することが期待できる．

ソフトウェアリポジトリマイニング

ソフトウェアリポジトリマイニング(以下，MSRと呼ぶ)とは，ソフトウェアリポジトリを分析し，ソフトウェアに関するさまざまな知見を得ようとする研究分野で あり，近年非常に活発に取り組まれている．リポジトリとは，Subversionなどのソフトウェア構成管理ツール，Bugzillaなどのバグ管理システム，メーリングリストアーカイブの3つを主に指す[Monden13]．

MSRのアプローチをSPLに適用し，SPLの進化に関する分析を行っている研究は多くないが，いくつかの研究では取り組まれている．Yoshimuraらは，SPLの変更履歴に基づいて因子分析を行うことにより，SPLの可変部分の特定を行う方法を提案している[Yoshimura08]．この方法により可変部分を特定することにより，リファクタリングを適用してSPLの再構成を行うことができる．

Krishnanらは，統合開発環境であるEclipseをSPLとみなし，SPLが進化していっても欠陥が発生しにくいモジュールを，リビジョン数やリファクタリングの回数に基づき特定できることを示している[Krishnan11]．さらに，Krishnanらは，Eclipseの進化にともない，各コンポーネントの信頼性がどのように変化するかを分析している[Krishnan11b]．コンポーネントは，いくつかの観点，たとえば多くのプロダクトで利用されているかどうか，頻繁に変更されているかどうかで分類され，深刻なバグの割合が時系列でどう変化するかなどが分析されている．これらの分析手法はどちらもSPL再構成時の品質管理に適用可能である．

MSRのアプローチをSPLではなくソフトウェア進化に適用した研究は多く存在しており，これらの研究の手法をSPLに適用することにより，SPLの進化を補助的にではあるが支援することは可能である．Kagdiらは，ソフトウェア進化に関するMSRの既存研究を進化の分析手法ごとに紹介している[Kagdi07]．ここでのソフトウェア進化とは，時系列やバージョン間でのソフトウェアの変化を指す．以下，紹介されている分析方法とそれを用いている既存研究の一部を説明する．

メタデータ分析とは，構成管理ツールのコミットログやバグ管理システムなどから得られるデータ（誰が，いつ，なぜその変更を加えたかなど）を分析することを指す．たとえば，Gallらは，通信のスイッチングシステムのリリース履歴より，モジュール間のロジカルカップリング(logical coupling)を発見する方法を提案している[Gall98] ．ロジカルカップリングとは，一方のモジュールを変更した場合，他方のモジュールも変更する必要が生じるような関係が存在することを指す．この手法は進化プロセスE3を支援できる．また，静的コード分析とは，ここでは単一のバージョン内でソースコードの分析を行うことを指す．たとえば，Gö rgとWeißgerberは，不完全なリファクタリングを検出する方法を提案している[Gorg05]．不完全なリファクタリングとは，メソッド名などのリネームが，サブクラスなどで行われていないことを指す(正しくは，サブクラスでもメソッド名をリネームする必要がある)．この手法は進化プロセスE1，E2，E3においてリファクタリングが発生する場合に有効である．

ソフトウェアメトリクスはソフトウェアの規模や複雑度などを定量的に計測したものである．Biemanらは，クラスの継承の深さやクラスの属性の数などのソフトウェアメトリクスに基づき，頻繁に変更される可能性の高いクラスを特定する手法を提案している[Bieman03]．この手法によりプロダクトに含まれる特定のクラスが頻繁に変更されやすいと判断された場合，SPL資産の再構成，すなわち進化プロセスE3の実行を検討するとよい．

おわりに

　ソフトウェアプロダクトライン(SPL)の導入において，その進化は避けられない．このような状況において，SPL進化を実践するためには，理解しやすい進化モ デルの構築が必須である．このような観点から，本研究調査報告書では，SPL 進化を概説し，そのプロセスモデルを示した．さらに，SPL進化を支援するリファク タリング，変更影響分析，ソフトウェアリポジトリマイニングを取り上げ，これらの技術をSPL進化において活用している文献を紹介した．

　本成果報告書の内容が，実際のソフトウェア開発現場および保守現場におけるSPL進化の実践に貢献することを望む．

謝辞

　本成果報告書を執筆するにあたり，「プロダクトライン進化に関する調査研究」の機会を頂きました産学戦略研究フォーラム(SSR: Joint Forum for Strategic Software Research)およびSSR会員企業の皆様に深く感謝いたします．



参考文献
ページのトップへ戻る