Generative Programming — Methods, Tools, and Applications
2003.9.3 by 久野1• OOPSLA でも基本機能よりコンセプトがテーマに

Forward by James Coplien• OOPSLA は没落して GCSE がポピュラーに (そうなの?)□ Coplien さんというのは…パターンとかの有名な人□ この本はどういう本?

• この動きを軽視しない方がいいですゼ (そうなの?)(歴史上の位置付け)□ そういうわけで、本書はこの新しい動きに関わるものを□ この 10 年で色々なものが出たまとめている• Subject-Oriented とかコンポーネントとか色々□ さまざまな手法類を統合的に捉える (それぞれの差異を• どれも「非オブジェクト指向的」側面述べるのでなく)• ようやく共通の土台らしきものが見えてきた• components, objects, aspects, reflection,
intentional programming, generic□ 共通の土台とは…

programming, domain engineering• metaobject protocol, reflection,□ 一見ごった煮みたいだが「things beyond objects」でintentionality, insightful interpretationof compoinents, crosscutting

すゼ• 要するに→古典的なモジュールの分解□ 集めただけでなく統合しようともしている□ GCSE’99 --- 1st international symp.

on
Generative and Component-Based Software• ドメイン工学とメタプログラミングが中心となる• それを中心に集めるだけでなく、統合によるシナジー効果もEngineering → 多 く の ア イ デ ア の 結 び 付 き が 見えるように□ 新 し い モ ノ□ 現在が歴史の代わり目かも…(プログラミングと設計手(reflection, metaprogramming,aspects) は オ ブ ジェク ト に 取って 代 わ る プ ロ グ ラ
ミングの中心概念になるかも法の分野で)□ 産業界は O-O パラダイムの制約から逃れる方向を模索• たとえそうならなくても、これらが有用であること• パターンは一例だけど、Alexander のようになれるは確実とは思えない□ さあ、あなたもご一緒に (???)□ O-O が出た時に熱狂のあまり色々捨ててしまったかも→
今見直しの時期?

2□ 革命的変化は難しいけど漸進的なものなら…
□ O-O の「モノ」から concepts, features へ

From Handcrafting totometed Assembly Lines

Au-□ ソフトウェア工学への期待…

• intentional programming, domainengineering• 複雑なものを、高い生産性、高い品質で提供し、保• vulgar (non-Alexanderian) pattern

守や変更もしやすくmovement, AOP, generic programming,
multiparadign design• …全然ダメ。産業革命以前の「手工業」みたいなもの?

1□ Generative Programming では手工業から現在の産業5.1みたいに…必要なこと:

互換性のある部品□ 1785 に Thomas Jefferson がマスカット銃を「互換性• (1) 単一のシステムを作る→複数のファミリを作る← 正しいコンポーネントの把握のある部品を組み立てて作る」ことを思い付く□ 1798 に Eli Whitney が銃の大量生産 (4000 丁) を請け• (2) 実装の組み立てに generator を使って自動化

負う• (1) 水力駆動の工作機械、(2) 互換性のある部品の3

From Handcrafting...(2)□ 例:

大量生産、(3) 熟練していない普通の人が働く• 結局、1800 年までという契約に 9 年遅れ、互換性部品ではなかった自動車を自分で部品から組み立てることを考える• 部品のいくつかはぴったり会わなくて加工が必要かも□ しかしこの様子を知った同業者がその方向で努力• 産業革命の時にもそういう問題を克服するのに何十□ John Hall が 1826 年に互換性のある部品から成るライ年か掛かったフルを生産• たとえば STL からぴったしな部品が入手できたとし□ Simeon North が 1834 に Hall のライフルの互換部品ても、組み立てるのは手作業を製造□ 代わりに「ベンツ S クラス、オプション全部つきで」と□ 1845 に複数の兵器製造業者が 1841 モデルのライフル部
言うだけにしたい ← Generative Programming の目品を製造標。必要なことは:• (1) 実装コンポーネントが生産品のアーキテクチャにフィットするように設計されていること

5.2

自動車産業における製造ライン導入• (2) 構成知識をモデル化し、抽象的な要求を特定部 □ 自動車→ 1880 年代ころ現れる。1885 年にダイムラーの品群の組み合わせ方に変換できること
自動車• (3) 構成知識を generator として実装できること• 製造工程は時間が掛かり少ししか作れないものだった□ 自動車産業では実際そういうことができている• Ransom Olds が 1901 年に製造ラインの考えを導入(ライフルと同じ)

NOTE: 製造ラインに関する誤解• Henly Ford が 1908 年にフォード T 量産開始→自動□ 多くの人は製造ラインは「全く同じものを大量に作る」• 1913 年にはベルトコンベア式のラインを導入→生産量が 3 倍以上に4車の普及と思っている• それは実は嘘で。自動車は何千種類もの組み合わせから選ばれるので同じものは 2 台とないと言ってよい

5.3• 実際は「多数の個人の注文」→「それぞれの注文品自動化された製造ライン□ ロボット:の製造」→「各ディーラーで引渡し」

GM 社が 1961 年に導入 (Unimation)。柔軟性がなく非効率。1975 年くらいまでコストに見合わな• 膨大な生産/流通システムによってこれが可能となっ

かったている→ソフトの場合と良く似ているでしょう?

□ 1980 年代→マイクロチップの「頭脳」を持つ柔軟性の5あるロボット→産業ロボットブーム (別の要因:日本の産業革命台頭)□ 手工業からどのように変化してきたかを見てみる (図• 初期のロボット:大量ロットの加工、現在のロボット:
小量〜中量でも使えるように (ジョブショップ方式と1-1)の競合はまだある)• 互換性のある部品→生産ライン→自動化生産ライン
2

6□ 従来のソフトウェア工学→最終製品は作るけど「どうGenerative Programming(GP)やってそこに到達したか」という生産時の知識は捨てて□ Generative Programming とは…

いる• ソフトウェア工学のパラダイムであり、• プログラマや設計者は何か考えてやっているがそのことは残されない• ソフトウェアシステム「ファミリ」のモデル化を基盤とし、• そのため保守も改良も難しく高くつく• 基本的な/再利用可能な実装部品+構成知識によって、• 要求仕様から特化/最適化された中間/最終製品を自動生成するというもの。

□ GP ではこれらの知識をできるだけ捕獲しておきたい• 生産時の知識 = 構成知識 + 測定ツール + テスト
戦略/計画 + エラー診断 + デバッグ機能 + プログ□ 単一のシステムではなくシステムファミリに焦点

ラム視覚化 + その他もろもろ• 各システム (メンバ) は「1 から書く」代わりにファ• 具体的に何と何か→ドメイン固有。再利用可能なライブラリとしてパッケージする (active library)

ミリに共通の genrative domain model(5 章) から生成

□ active library がパッケージしているものとは…

□ システムファミリのモデルは 3 つの構成要素から成る• 汎用の/ドメイン固有の再利用可能な抽象化を、プロ• (1) メンバの仕様記述手段

グラマが実際にそれらを使うときのコードと一緒に• (2) 実装部品 ← これが実際のコードになる

パッケージする• (3) 構成知識 ← メンバの仕様と生成されるメンバ• つまりプログラミング環境をドメイン固有な形で拡張の間のマッピング• 具体例→ Intentional Programming(IP) システム
(11 章)□ 自動車の購入でも同様□ IP では「特定のプログラミング言語」の代わりに「言• (1) 自動車の注文システム

語を抽象化する active library」を使う• (2) 自動車を構成する個々の部品• Java とか C++とか言語を決めてしまうとその言語が• (3) 注文からどのように車を組み立てるかの知識決めた抽象化を使うしかない□ 仕 様 記 述=problem space、実 装 部 品+可 能 な 構 成• active libarry では問題 (ドメイン) に合った抽象=solution space(図 1.2)

化を使える

□ 構成知識 (configuration knowledge) が定めるもの• システム機能の許されない組み合わせ (例:• マルチパラダイムでドメイン特化したプログラミン
グサポート

カブリオレ×サンルーフ)• デフォルトの設定 (例:ら普通の屋根)□ フレームワーク、コンポーネント ← ソフトウェア再利
サンルーフを指定しないな• デフォルトの依存関係 (例:用において最も効果的と (現在) 考えられている技術• しかし→どの OOA/OOD もフレームワークやコンポーネント「の開発」は取り扱っていない

DC モータの電気自動車→ミッションなし)• GP では→開発を 2 つのサイクルに分割• 最適化• (1) generative domain model の設計と実装 ←• 組み合わせの知識 --- どの部品とどの部品を組み再利用のための開発

合わせるとどのような機能群を提供できるか• (2) generative model を用いた具体的なシステム□ 自動車→構成知識の多くは自動組み立てラインの形と生成 ← 再利用に基づく開発なっている• この (1) も (2) も「1 つのシステムを作るだけのプロセス」(例: 統一プロセス) とは全然違う□ GP では→構成知識をプログラムとして固定したい• 再利用のための開発のスコープ → システムファミリ3• また組み立ても generator が行う• 再利用に基づく開発 → (1) の投資を活用すべく注
意深くデザイン• ということは、generic programming は GP の 1/3の部分に相当□ 「システムファミリを対象とする開発」が重要な特徴□ (1) ファミリ (ないしドメイン) のスコープを決める

NOTE: コンポーネント• どの機能は入りどの機能は入らないか

7• 関与者は誰でそれぞれの目標は何か□ コンポーネントの考え方はよく知られている…

□ (2) ファミリ内で共通の機能/変化する機能を同定• どのコンポーネントは何に使うかも (例:煉瓦は家を作る時に…)• 分析の結果→ feature model(4 章) … UML なんかよりいい• コンテナなら STL、GUI なら Gtk+、分散なら CORBA…

• FM は変化点とそれらの間の依存関係を明示的に記述 □ これを一般化→コンポーネントの古典的定義
する→これに基づいてファミリに属する個別システ• たとえばオブジェクトの古典的定義→これこれの機ムを生成
能と属性を持つ (identity, state, behavior)• FM はメンバ内の変化とメンバ相互の変化を区別→• コンポーネントの古典的 (人工的) 定義は「有害」「太った」コンポーネントやフレームワークを避ける(通常の OO ではアプリ内の変化にもアプリ間の変化 □ コンポーネントは「自然概念」(natural concept)にも同じポリモルフィズム機構を使っている)• natural concept には古典的定義は合わない• FM は実装から独立した「変化点の表現手段」→どうやって変化させるかは後で決められる --- 分析時に• たとえば「机」をどう定義します?

は扱わないでよい (UML では「ここは集約」「ここは• 例:継承」とかいきなり書いてしまうのでダメダメ)• 4 とは限らない。あまつさえ脚がないものが日本にはある (え???)□ (3)generative domain model の設計「天板に 4 つの脚がついているもの」□ じゃあテーブルとは天板のこと?

• メンバの記述方法• 天板とは水平で平らな作業用平面?

• 共通アーキテクチャ(実装用コンポーネントなども含む)• 平面とは限らないし作業に使うとも限らない…→古典的定義はナイ• 構成知識 --- メンバの記述と組み立てられた実装との対応関係• でも多くのテーブルは役に立つ• 脚がないのに慣れてないならそれはあなた向けでな□ (4) モデルを実装する

いだけのこと• コンポーネント技術や (再び)GP 技法を使う□ コンポーネントも同じこと□ 実装コンポーネント←コードの重複がなく、できる限り柔軟に組み合わせ可能• 必要なコンポーネントのすべての性質や機能を列挙するなんて無理• STL などの generic programming が持つ特徴 (6 章、7 章)• ファミリのために必要なコンポーネントが用意でき• GP ではさらにコンポーネントの組み合わせ部分も生成する (generator)たりその場で作り出せたりすればいいわけじゃない?

(たぶん)• そういう風な文化的変化が今後必要とされている□ 例:下三角行列を高率よくしかも境界チェックつきで扱いたい• generator は複数の実装コンポーネントから適切なものを選ぶ

4

8Generative(Cont’d)• (3)IP
な ど の
extendible programming
environment を 使 う ← こ の 場 合 、言 語 だ け でProgramming

なくツールや環境まで変化させられる□ 今日のプログラミング手法→機能単位 (functional□ extendible programming environment では、新しいcomponent) をみつけてオブジェクトなりモジュールなりとして実現する

抽象化を作るごとにプログラミング言語がその分だけ拡張されたと考えることができる• しかしある種の側面 (エラー処理、同期、永続性、安• 従来の言語→手続きやクラスなどを定義することで拡張可能全性) →局所的に実装できない、今日の OO と合わない• 多くの言語では構文や最適化などは変えられない• AOP(8 章) →このような横断的側面をアスペクトとして分離• extendible programming environment ではツー
ルやエラーメッセージなどもドメインに特化して変• アスペクトは weaver によって OO の骨組みに組み込えられる

む→実装ができあがる• OO では細かいメソッドの断片になってしまうものをAOP だとうまく扱える□ 自動プログラミング (Automatic Programming) … 古□ チェック、最適化、weaving、コンポーネントの組み立• AP では「一番上の抽象化」からコードに落すことだて→メタプログラミング (=プログラム自身を操作する

け考える →ドメイン知識などが膨大になってしまいプログラミング) が必要

難しい

くからあるアイデアだが、GP と似ている面もある• GP では自動化のレベルは様々に選べる → 実用的• generator(9 章) もメタプログラム ← プログラム
を組み立てるから□ GP は「正しい」コンポーネントを作る手段でもある• generator は階層的かも (下請けの generator を呼• 「コンポーネントを手で組み立てることができるんだりするかも)なら、そのプロセスを自動化することもできる」□ これまでのコンポーネント→「必要なものを探す」こと(automation principleに焦点• 自動化は魔法ではなく適切なアーキテクチャができれば着実に進められる• 名前程度しか手がかりがないのであまりうまく行か• どれくらい自動化できるかはどれくらいドメイン知ない

識獲得にコストを掛けるかによる□ これに対し、generator では「必要なものを作り出す」
ところが違う• ロボットは大量生産用から少量生産でも引き合うようになった (← CPU 制御のおかげ)• 利点 1:• 同様に、GP の自動化も技術の進歩に従って敷居が下オンデマンドで生成するから「山のようにがるはず用意」が不要、その元になるもの (小さい) があればいい• 利点 2:「必要なもの」を指定するので抽象度があ9げられる、具体的なアルゴリズムやデータ構造は (たとえば技術の進歩により) 変わっていってもいい ←Benefits and Applicability□ GP の 基 本 ア イ デ ア:

クラス名名指しでは不可能なこと

シ ス テ ム ファミ リ を 対 象 にgenerative model を構築し、モデルから具体的なシステムを自動生成□ generator はどうやって作るのか?

• 実装コンポーネントや構成知識→自動生成ごとに再利用• (1) 一から作ってもよい (が、大変)• (2) 言語のメタプログラミング機能を活用 (例:C++のテンプレート)• 新しい実装が必要となったときにす速くできるかも• economy of scope5• 1 つ作るだけでもコンポーネントが入手できたりす
れば有利• 実績のあるコンポーネントの再利用→品質、信頼性□ コンポーネント/ライブラリ/フレームワーク製造が仕事□ GP も他の新技術と同様、導入するなら iterative かつだったら?

controlled に• generator は作らなくてもファミリを想定したアプ• useful だが failure-critical でない適切な大きさのドメインに適用するパイロットプロジェクトか

ローチは有効□ コンポーネント開発→ファミリ内の共通点に加え変化点

らはじめるも同定• 一番上位レベルの自動化を目指さなくてよい← GP は「どれくらいの自動化」というレベルが選べる• domain scoping、feature modeling →これらの共通点/変化点発見に有効• generator を開発しなくても、feature modelingや構成知識のドキュメント化は有用□ GP は構成知識の獲得を伴う→より高い抽象度での再利• テンプレート、メタプログラミングは generator の用やサポートために使っても特定の最適化された実装のために使っ• generator や active library →ドメインに特化してもよいたサポート• DMS や IP が使えれば大きな効果もあるかも知れないが開発プロセスにも大きな変化が及ぶ□ テンプレートプログラミング→ generator などの実現に有効□ GP はプログラミングのさまざまなレベルにおいて適用可□ メタプログラミング環境→ GP により充実したサポート

能 --- scoping, feature analysis, generationを提供可能• 例:→ コンポーネントレベル、システム全体レベル以外に手続きやクラスの生成にも使える

DMS(9.7.1 節) や IP(11 章) など□ GP は言語やパラダイムとは直行している --- マルチパ

• 自動リファクタリング

ラダイムデザインの考え方を受け継いでいる• 通常の言語での記述より多くの設計知識を固定可能□ より重要な利点として、投資を保護してくれること• ある言語で投資したものは言語を移行するとパーになることが多い• DMS や IP では高レベルの知識をそのまま別の言語に持って行ける (ふーん)• 「半自動リターゲット」□ テンプレートプログラミング→ generator などの実現に有効□ とはいえ、ファミリを作るために用意するのは単一シス
テムよりはコスト高• だから実際にいくつかのメンバを作る予定がないと引き合わない• どれくらいから引き合うかは場合によりけりだが見積りはするべき• 急いで 1 つだけ作るなら GP ではない方がいいかも• そのドメインを継続的にメシの種にするなら GP にした方がいい6