T1-403 Software Factories補足テキスト
萩原氏のセッションはたいてい話す内容がPPTの数倍は有るのでメモ取りが大変。
今回は何とかがんばってとったメモ内容をここに書きます。
あとでポストカンファレンスDVDをみると間違いや抜けがぼろぼろと・・・。
関心の分離
ステークスホルダそれぞれがシステムに対して持つ関心は異なり、その関心の間には開きがある。
アーキテクチャ/プロダクトラインの開発
5年/10年のスパンでアーキテクチャを考える。
→（なぜか）→
一つのプロジェクトでアーキテクチャの構築を考えることは予算/政治的な要因から難しい。従ってアーキテクチャの構築は実際のプロジェクト分離したプロセスで開発する必要がある。（時間軸の違いによる開発プロセスの分離）
プロダクトライン開発ではアーキテクチャ（プロダクトライン）とアプリケーション（プロダクト生産）の会亜hつぷろせすを分離している。
ソフトウェアファクトリ
コンポーネント再利用を求める時代ではない。（過去に失敗している。）
ソフトウェアファクトリは部品（コンポーネント）の再利用ではなく、工場/生産設備（プロセス/アーキテクチャ/プロダクトライン）を再利用する。再利用するためにフィーチャ（機能）をドメインで共通性を持つフィーチャをアーキテクチャ/プロダクトラインとして用意しておく。
フィーチャはドメイン分析の中で共通性を持つフィーチャと、案件ごと独自のフィーチャとに分離しておく。
ドメイン/視点/DSL/成果物
ドメインとは知識や関心の領域
解決領域（技術）＜How＞
問題領域（機能）＜What＞
ビューポイント・・・ビジネスプロセス視点での関心の分離
DSL・・・問題領域での関心の分離
フレームワーク・・・解決領域での関心の分離
先進的なソフトウェア構造
ソフトウェアは複数のドメインで構成される。
各ドメインでのシステマティックな再利用
- 知識
- ベストプラクティス
- パターン
- 成果物
- プラットフォーム、ミドルウェア
- ライブラリ
- コンポーネント
- アスペクト
ソフトウェア成果物への要求←成果物の管理
- 自己完結的（メタデータ）
- 識別するための手段
- 他の成果物とは最小の冗長性
- 高凝集度・低い結合度の維持し、変化に対応する。
- 理想的には単一の関心を表現
- 適度な適応可能性
- 繰り返し作業を自動化、利用が容易。
振る舞いを伴う静的モデル
Ref:カタリシス http://www.catalysis.org/index.html
ソフトウェア成果物としてこのレベル（カタリシスのダイアグラム）で再利用する。（仕様レベルでの再利用）たとえば、コンポーネントではFrameworkが変更されたりしたら使えない。仕様レベルの再利用であればFxの変更や実装方法の変更があっても再利用することができる。ここから再利用できればいい→DSL
DSLとは
開発言語は技術や要求の変化に対応できない。開発言語の上にドメインに対応した抽象的なコンセプトをDSLとして乗せる。こうすることで、開発言語と、再利用対象である「ドメイン仕様」との間にある時間軸の差を解決する。具体的にはDSLのコードジェネレーション機能をその時々の実装に技術にあわせることで、DSL自体の独立性を維持する。
DSLの有効性
DSLはメタデータ（仕様/管理する単位）を使って一部コードを生成するツール。
DSLは汎用的であってはいけない。スコープを限定する。汎用的に作るのであればそれはC#のような汎用言語であってDSLではない。
DSLですべてを作る必要はない。部分的にコードを作成するような形でも良い。
コメント