プロダクトライン・アーキテクチャ

プロダクトライン・アーキテクチャとは
主に量産化可能な製品を扱う組み込み系ソフトウェア開発に適用され、
生産性や成果物の管理で効果を上げている開発手法である。
アーキテクチャの構築という長期的視野を重視し、
長期的に継続される複数回のソフトウェア開発向けに適用される。
最近では、組み込み系ソフトウェアだけでなく、
一般にはアーキテクチャの構築が有効とされる大規模システム、
長期間の利用が前提となる企業システムへの適用が試みられている。

プロダクトライン・アーキテクチャはオブジェクト指向分析設計やその開発プロセスを超えて、
・アーキテクチャ構築のためのドメイン工学、
・アーキテクチャ構築を強制する開発プロセス、
・アーキテクチャを構成するソフトウェア資産
を管理し、
・コンポーネント・ベース開発
・モデル駆動型アーキテクチャ
と組み合わさって、
最新のソフトウェア工学の開発手法に成長しようとしている注目の技術である。

2

コンサルの使うバズワード

┌─【プロダクトライン開発】 ─┐
│┌[ プロダクトライン分析 ].┐│
││プロダクトライン定義　　││
││問題領域モデリング　　.││
││解決領域モデリング　　.││
│└──────────┘│
│　　　　　　　　▼　　　　　　　　│　　　　　　　　　　　　　　┌── 【プロダクト生産 】 ─┐
│┌[ プロダクトライン設計 ].┐│　　　　　　　　　　　　　　│┌─────────┐│
││プロダクトライン・　　 　 .││　　　　　　　　　　　　　　││プロダクト構成定義　.││
││　　　　　 アーキテクチャ││　　　　　　　　　　　　　　│└────▼────┘│
││インフラ・アーキテクチャ││　　┌─────┐　 .│┌─────────┐│
││アーキテクチャ・ 　 　 　 │┝＞ │ソフトウェア.┝＞ ││拡張性のあるツール..││
││　　フィーチャマッピング.││　　│スキーマ　　│　 .│└────▼────┘│
│└──────────┘│　　└─────┘　 .│┌─────────┐│
│　　　　　　　　▼　　　　　　　　│　　　　　　　　　　　　 　 ││カスタム化したツール││
│┌[ プロダクトライン実装 ].┐│　　┌─────┐　 .│└────▼────┘│
││資産の開発　　　　　　　.│┝＞ │変化要求の┝＞ │┌─────────┐│
││資産パッケージング　　 ││　　│ある資産　 .│　 .││プロダクト製造　　　　.││
│└──────────┘│　　└─────┘　 .│└─────────┘│
└────────────┘　　　　　　　　　　　　　　└───────────┘
　　　　　　　　　 ▼　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　▼
┌───────────────────────────────────┐
│　　　　　　　　　　　　　　　　　　　　　　　固定資産　　　　　　　　　　　　　　　　　　　　　　│
└───────────────────────────────────┘

プロダクトライン・アーキテクチャ

プロダクトライン・アーキテクチャは、アーキテクチャの構築という長期的視野を重視し、
長期的に継続される複数回のソフトウェア開発向けに適用される。
左側のプロダクトライン開発がアーキテクチャを構築し、
右側のプロダクト生産がそのアーキテクチャを再利用し、
提供されるフィーチャを選択して、1回ずつのプロジェクト開発を行う。

ソフトウェア工学(笑)

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

「共通の管理された特徴を持ち、特定のマーケットやミッションのために、
　共通の再利用資産に基づいて作られる、ソフトウェア集約的なシステムの集合」

　　　　　　(米国カーネギーメロン大学ソフトウェア工学研究所(CMU/SEI)の定義)

ここで再利用資産とは、要件、設計、実装などを指している。
プロダクトライン開発における開発は、以下の２つがある。

1) 再利用資産の開発（ドメインエンジニアリング）
プロダクトラインへの要求や対象ドメインの経験に基づき、再利用資産（コア資産）を開発する。

2) 再利用資産に基づくプロダクトの開発（アプリケーションエンジニアリング）
個々のプロダクトへの要求に基づき、個別プロダクトを開発する。

プロダクトライン開発が目的を達成するためには、
・プロダクトアーキテクチャに基づく再利用資産の体系化、
・要求とコンポーネントの間のアーキテクチャを中心とする
　トレーサビリティの定義と維持
が重要である。

プロダクトライン開発は、ビジネス目的に向けた戦略的、体系的な製品系列開発である。
プロダクトライン開発には、
　・プロダクト群、
　・変動性、
　・再利用資産（コア資産）
等の明示的な定義と管理が必要である。
再利用資産を高度に体系付ける技術が重要であり、そのような技術として、
　・ドメインエンジニアリング、
　・プロダクトラインアーキテクチャと再利用資産の設計、
　・変動性の管理、
　・トレーサビリティ
等がある。プロダクトライン開発を行うにあたっては、
個別最適ではなく全体最適の視点を持たなければならない。

こっちの板の方がいいんじゃね？
http://science6.2ch.net/informatics/

論外の外

ここで本家CMU/SEIの味気ない記述を読むか、
それともマイクロソフトの人の独自方法論を読むか、
が勝負の別れ所

猫も杓子もアーキテクチャとか付けて馬鹿丸出しだろ
そんな言葉はいいかげん飽きてｸﾁｬｗ

>>12
が議題について最も的確な答えを出した、と俺は信ずる。

こういうことはみんなが考える事じゃないから不要だと思うヤツは考える必要は無い

>>14
は議論妨害の常連なのでスルー

「サブジェクト指向パラダイム」

　ドメインクラスは、OOパラダイムによる機能要求の論理レベル表現である。
分析レベルでトップダウンにより決める「概念の名前」と、ボトムアップにより決める「概念の属性」を持ち、
ユースケースの振る舞いを、論理レベルでのオブジェクト間のシーケンス図の協調パターンを見ながら
ドメインクラスの「操作」として割り当てる。いわゆる責務の配置である。
協調パターンはデザインパターンの適用や特定アーキテクチャの利用を前提として決定する。

●ドメインクラスに見られるOOパラダイムの弱点

　だがこのドメインクラスは、同時にOOパラダイムの弱点を表している。
システムが外部に提供するサービスや機能であるユースケースは、
複数のドメインクラスを連携して提供される。
また、1つのドメインクラスは、複数のユースケースの実行で共有して使用される


　通常、大規模開発チームの構成は、外部サービスであるユースケースの実現を単位とするため、
ドメインクラスのコード共有管理の発生で、開発チーム間での調整が不可避となる。
これが、開発のプロジェクト管理を難しくし、プロジェクトの成功確率を下げてしまうのである。

　　　　　　　　　　　 ｜←責務→｜　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　 ┏━━━━┓　 ┏━━━━┓　 ┏━━━━┓
　 ┃ クラス１ .┃　 ┃ クラス２ .┃　 ┃ クラス３ .┃
　 ┠────┨　 ┠────┨　 ┠────┨
　 ┃　 　 　 　 ┃／┃￣￣￣￣┃￣┃￣￣￣￣┃＼
　 ┃　 　 　 　 ┣━┫　 　 　 　 ┣━┫　 　 　 　 ┃　|　ユースケースA
　 ┃　 　 　 　 ┃＼┃＿＿＿＿┃＿┃＿＿＿＿┃／
　 ┠────┨　 ┠────┨　 ┠────┨
／┃￣￣￣￣┃￣┃￣￣￣￣┃￣┃￣￣￣￣┃＼
|　┗━━━━┛　 ┗━━━━┛　 ┗━━━━┛　 |　ユースケースB
＼____＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
　　　　　　　　　　　　　　　　　 　 　 .↑　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　 散乱 (scattering)　　　 .│もつれ (tangled)
　　　　　　←──────→　　　↓

　OOパラダイムの弱点：散乱（scattered）ともつれ合い（tangled）
システムが外部に提供するサービスや機能であるユースケースは、複
数のドメインクラスを連携して提供される。図では2つのユースケースを例としている。
いずれも複数のクラスのオブジェクトが連携して実現されている。
これを散乱（scattered）という。
また、1つのクラスは、複数のユースケースの実行で共有して使用される。
図のクラス2に相当し、もつれ合い（tangled）という。
OOパラダイムでは、この散乱ともつれ合いがプロジェクト管理を困難とする。

●OOパラダイムの弱点「散乱」と「もつれ合い」の解決策

　この問題を解決するには、プロジェクト管理的側面で対応するか、
ドメインクラスのコード共有による依存性を回避する技術的側面で対応するかしかない。
後者の対応では、ドメインクラスの設計を前提としない開発手法を選択するほかない。

　例えば、ユースケースを提供する際のシステムの役割を定義し、
その役割をドメインクラスから分離する手法である。
これが「ロール・モデル」と呼ばれる分析手法で、例えるなら、
映画のシナリオ（サービス内容）では登場人物の演じる役割だけを先行して決定し、
俳優へのキャスティングをシナリオの完成まで遅らせることに似ている。

　シナリオとしてのサービス内容の仕様が完全に確認できた後、
その役割を演じる俳優（ドメインクラス）を選択する。
もし俳優に問題があれば置き換え可能とする。
確かに役割を演じることができる俳優には一定の資格が存在する。
しかし、その資格は従来のドメインクラスの持つ操作よりも緩い条件で、
シナリオ（サービス内容）に依存せず役割を持たない
最小限の基本的な属性と操作だけを持つドメインクラスとする。
これにより、従来のロジック・コードを実装するドメインクラスでのコード共有を最小化し、
コード共有をプロジェクトの後半にずらすことができる。

●サブジェクト指向パラダイムの特徴

　サブジェクトとドメインクラスを分離して、それぞれに適切な振る舞いを割り当てることで、
ドメインクラスへの操作の割り当てによるコード共有管理の問題を回避する。

　サブジェクトはほかのサブジェクトやドメインクラスと独立して開発可能なので、
サブジェクト単位に開発チームを編成して並行開発を行うことが可能である。
また、特定のサブジェクトを開発プロセスの遅い段階に定義し、追加することで、
要求の決定を遅延させることが可能である。

　コンポーネント・モデルのインターフェイス定義が、
インターフェイスを実装するクラスの提供する機能（提供インターフェイス）や
ほかのクラスを利用する機能（必要インターフェイス）の契約を定義するのと異なり、
サブジェクトはクラスがオブジェクトとして実行される際の
ほかのオブジェクトとの関係で決まる役割を示す。
すなわち、1つのクラスが複数の役割を実行し、その役割が動的に変化する場合に、
サブジェクトを適宜実行することで対応可能である。

　このようなシステム開発を可能とするパラダイムが「サブジェクト指向」である。

　このようなシステム開発を可能とするパラダイムが「サブジェクト指向」である。

　サブジェクト指向パラダイムは、OOパラダイムのドメインクラスと併存するので、
OOパラダイムと組み合わせて用いられるマルチパラダイム・デザインの一種である。
サブジェクト指向は、クラスと、クラスが持つメソッドを分離管理する発想であり、
DOA（データ中心アプローチ）のエンティティ・タイプとデータ項目の分離管理に類似した、
大規模システムに有効なドメインクラスに対する正規化技術である。

　すなわち、同一の意味を持つメソッドを論理的に統合する。
大規模システムでは、同一メソッド定義（＝必ずしも実装は同一ではないが、
シグネチャ定義が同一である）を持つ複数のドメインクラスが出現するので、
メソッド定義を論理的に1カ所で定義することで数を減らして管理可能とするのは有効な方法である。

　サブジェクト指向はクラスとサブジェクトのウィービングの1技術であるので、
現在はアスペクト指向の一部として発展しているが、厳密には両者が解決を目指す課題は異なる。
サブジェクト指向の開発手法を実現するにはプログラミング・パラダイムとして
サブジェクト指向言語が必要であるが、サブジェクト指向言語が利用可能でないときは、
より抽象レベルの高いDSL（ドメインに特化したモデル言語）がコード生成を行い、
サブジェクト相当のコードを提供する。

●ステークホルダーの多次元性の問題

　フィーチャ・モデルは、アーキテクチャ要求の可変性に着目したモデル表現でもある。
しかし、アーキテクチャはその規模と適用範囲の大きさから多くのステークホルダーがかかわり、
多くのステークホルダーの視点での表現が必要である。

　ステークホルダーごとに異なる関心の表現を、
特定のドメイン分割を前提としたフィーチャ・モデルで表現できるだろうか？
選択的なフィーチャにより可変性の表現ができるにしても、
ステークホルダーごとの異なる視点で「関心の分離」を表現するには
単純化しすぎていると思われる。
個々のステークホルダーの視点での関心の分離の表現は、
短期的視点のユースケースに対して長期的視点のフィーチャ・モデルを分離した
要求定義の解決法とは別問題である。

　この視点の問題は、ステークホルダーの多次元性という。
多次元性は現在のソフトウェア開発の要求の多様化に対応するために
取り組まなければならない課題である。
多次元性の問題は多次元的な視点を持っていないフィーチャ・モデルでは残念ながら解決できない。

●問題領域のドメイン分割の決定法の問題

　もう1つの問題は、フィーチャ・モデルを作るための問題領域のドメイン分割の決定法である。

　先のドメイン分割の例では、業務内容に従った分割を行った。ドメイン分割では、
・視点やスコープの明確化、
・粒度（意味のまとまりの単位）の決定、
・抽象レベルの一貫性、
・できるだけ分割単位間で依存関係やオーバーラップがない直交関係を持つドメイン間の
　整合性や変更追跡性
などを考慮する。

　ドメイン分割の決定は、フィーチャ・モデルに適合したアーキテクチャの品質に大きな影響を与える。

　　　　　　　　　 __　　　┌<.＾ヽ::／:::::／￣￣￣￣｀ヽ:::::::::::＼
.　　　　　　　 ／　　ヽ. ,.ヘ⊥／:::::／＿＿＿　　　　　 ﾏ::::::::::::ヽ
　　　　　 　 /　　　 　 ﾏ´ ／::::::::::::::::;ｨ::::/:::::::::::::￣ヽ.　 |:::::::::::|:::ﾍ
　　 　 　 　 |　　● 　　ﾄ/::::::::::＼:／ !::::l::::::::!::::::::::ヽ::＼|:::ヽ::/::::::| ＿_
　　 　 　 　 |　　　　　　|′:::::;ｲ::/ヽ　l::::ﾊ::::::|:::::::::::::|:::::::::::::::}'￣￣ 　 {
.　　　　　 ,r1　　　　 　 l::::::::::l |::|　 ﾍ.|:::| l::::::ﾄ:::::::::::ﾊ::::|:::|:::::| ヽ＜二ﾌ
　　　 　 /'_ｺ　　　　　　|、::::::| V　　　ヾ| ヽ:::|_,ゝ‐:T'|:::ル::::::|　 ﾍ｀ ｰ-､
　　　　　i´ ！　　 　 　 l ヽ::::| ﾆミ:.､　　 　 ベ　_,ゞ'=ﾚ､l:::::::::|　　_〉ト､
.　 　 　 ﾉ　　＼　　　　　　 l:::ヽ　　｀　　　　　 'f rﾍ, ﾊ.ヽ:::::::{Tﾏ:::::ヽ ｀　　　鼻クソびーっ
　　　 ｒ´　　　　ヽ、　　　　 |ヽ｀　　 ､ ' 　 　 　 ﾋこソｲ'´::::::/}:|. ';:::::::l
　 　 ！　ﾍ　　　　T　_,　j　ヽ. }､　　}'｀ ー､　　　｀´/:::::::::::/:::::|　ヾ::::! 　　　　
　　　ﾉ　　 ',　　　　Y_,-〈　　 V､:＼　､__ ノ　　　 ／::::::/::/::::::∧　ヾ!| 　　　　
　 　 {　 _　 ヽ　　 　 ,｀-'　 　 | lヾ:/ヽ ＿.　- ァ':::::::／／::::::/:/:７Ｔﾞ:| 　　　　
　 　 ヽ.　＼　＼__／　　　　　| |　'　|ヽ､ 　 ／::ィ ﾌ:／:::: ィヽｲ::/ｌ:j l:| 　　　
　　 　 |｀ - ､＞´ !'´　_.　--r ’.l.　　|＼.｀ ー‐/ イ1;r7´/　/¬ /'　'′ 　　
　　　　ヽ､_　 ｀ ｰゝ-'rｲ　　 ! :l l.　　|ヽ 二..ア　　´{!'　/　/ | ∧ 　　　　　　
　　　　　　　￣ ´　　.ゝ　　｜:| ﾏ　/　　 ／　　 ／ ／／ ／　 ヽ 　　　　　
　　　　　　　　　 ,ｒ'´　|　 　 ヽヽ ∨　／　 　 ／ ／∠ -'　　　　 〉
.　　　　　　　　_/　　　ｰ-､　　lヽｿ∠二二　´ -'_／_). 　 　 　 ,.〈
　　　　　 ,.- ´ ′ 　 　 　 ﾝ'￣{_ﾌヽ二ﾈ¨ ,rｧ─一´ ヽ----'´　｜
　　　　　 〉　　　　　　　　ヽ　ノ ハ｀t.-'　Y1　　　　　　　　　　／
.　　　　 〈　　　　　/　　　　｀ |　|　ヽ ヽ､ | ヽ　　　　　　　　／
.　　　　　＼　　／|　 　 　 　 |　|　　 ＼ ＼ 'シﾗ´￣￣￣