ObjectSquare [ 2002 年 2 月号 ]

[技術講座]


オブジェクトパラダイムを超えて

             マルチパラダイムデザイン - 序論 -


事業模型倶楽部
金澤 典子
dori@srenai.gr.jp

■ はじめに

 James O. Coplien の"Multi-Paradigm Design for C++"の翻訳『 マルチパラダイムデザイン 』が,昨年12月にピアソン・エデュケーションから出版されました.原書は1998年10月に刊行され,その年のC/C++ユーザ協会ブックオブイヤー賞次点を取り,新しい設計手法に影響を与えてきました.ここでは,マルチパラダイムデザインが何かをご紹介して,『マルチパラダイムデザイン』を読み解くガイドライン を提供します.

 今回の記事に関連して,著者がオブジェクト指向シンポジューム2000(ソフトウェア工学研究会主催,2000年8月開催)などで使用してきたプレゼンテーション資料"Multi-Paradigm Design and Implementation in C++"の 翻訳 を許可してもらいました.この資料は,(著者自身が作成しているので当然といえば当然ですが(^^;;,) マルチパラダイムデザインの全容をコンパクトにうまく説明しています.この記事はそのプレゼンテーション資料と重複しないように考慮したので,ぜひ併せて読んでください.

■ マルチパラダイムデザインとは何か

 マルチパラダイムデザインを一言で説明するのは少々難解です.デザイン=design=設計ということばが付けられていますが,Cope(Jim Coplienのこと)はこのテクニックの基礎はドメイン分析(domain analysis)である,と言っています.ドメイン分析というのは,再利用を考慮に入れて,個々のアプリケーションだけではなく,そのアプリケーションの関与するビジネス領域を分析し,その領域,すなわち, ドメインの汎化された定義付けを行うというソフトウェア工学の一分野です.目前のアプリケーションだけを考慮しただけでは,今後の拡張の可能性に限界を強いるかもしれません.それを回避するために,これから開発するアプリケーションを含むドメインが汎用的にはどのようになるかを分析するのが,ドメイン分析です.

 ドメイン分析は,オブジェクト指向による開発では馴染みのものです.オブジェクト指向を用いた再利用技術の1つに「アプリケーションフレームワーク」がありますが,これを構築するためには,「このフレームワークを利用して開発されることになるアプリケーション」がどのようなものであるかを考えなくてはなりません.その際に実施されなくてはならないのが「ドメイン分析」です.また,OMGのOMA(Object Management Architecture)の垂直CORBAファシリティと水平CORBAファシリティはドメイン分析の結果をもとに作成されています.

 現在最も注目されている再利用の一形態として「ソフトウェアプロダクトライン」があります(これについては,あとから簡単に説明します).「ソフトウェアプロダクトライン」には,マルチパラダイムデザインの考え方が取り入れられています.

 では,マルチパラダイムデザインは再利用を促すテクニックなのでしょうか.そうです、けれども,それだけではありません.ドメイン分析を行い,それから,いままで「なんとなく」そのように決めていた事項を見直して,ソフトウェア設計にきっちりと理由付けをするのに役立つテクニックです.

■ マルチパラダイムデザインに何ができるか

a) 言語要素の適切な選択

 Copeがこれを考えた動機には,「本来オブジェクト指向プログラミング言語ではないC++のために適切な手法が必要だ」ということがありました.テンプレート, #ifdefというのは,本来オブジェクト指向言語要素ではありません.しかし,C++プログラマはこれを使いこなしている,もしくは使いこなすことが求められます.たとえば,どのような場合に通常のクラスを定義して,どのような場合にテンプレートを使えばいいのでしょうか.

b) アプリケーション開発のために適切な手法と実装ツールの選択

 理想的なソフトウェアシステムの開発では,プログラミング言語はシステムの特性に合わせて選択することが望ましいとされます.現実的には,顧客のほうから特定のプログラミング言語の使用が制約として課されることが多いのですが,もしプログラミング言語の選択も自由にできるとしたら,どのように考えてそれを選択するでしょうか.

 オブジェクト指向分析設計方法論が説かれた当初,1)メンテナンス性の高いソフトウェアの産出と,2)高い再利用性,とともに,3)要件から実装への「セマンティックギャップ」が小さくなることが期待されました.

c) アプリケーションドメイン(=問題ドメイン)とソリューションドメインの最適なマッピング

 オブジェクト指向開発手法への期待にもかかわらず,実際には多くの技術者が分析の結果を実装に結びつけることに困難を感じました.優れた技術者は,"方法論を超えて,"「ビジネスピープルのためのモデル」と「プログラミング言語やデータベースを使用しての実装」をうまくマッピングする(=設計する)ことができるのではないでしょうか.そうだとしたら,それはどのようにしてなされるのでしょうか.

d) 再利用性を向上させるために

 オブジェクト指向を利用して再利用性を高める技術として,アプリケーションフレームワークがあります.W. Pree は,そのフレームワークから生成されるアプリケーションごとに変化しないフローズンスポットと変化するホットスポットを切り分けることがフレームワーク作成の重要点であることを指摘し,さらにホットスポットの実装のためのメタパターンを提唱しました.しかし,オブジェクト指向が再利用のための究極のプログラミングテクニックではなく,将来はそれを凌駕するアイデアが出されるでしょうし,現実のシステムはオブジェクト指向プログラミング言語が最適であるとは限りません.メタパターンを超えて,汎用的なフレームワーク作成のガイドラインはないでしょうか.

e) 単純な「関心の分離」を超えて

 システムの「分割された要素」間に依存性が少なければ,メンテナンスは容易になりますし,その要素の再利用できる可能性も高くなると考えられます.結合度と凝集度がこのためのメジャーです.実際,「関心の分離」原理に従えば,うまく分離された「システム要素」を定義することができます.厄介なケースとしては,分離した要素間が相互依存する場合です.これを扱う形式的な方法はないのでしょうか.

 マルチパラダイムデザインは,たとえば以上のような問いに答えることができます.

■ 基本概念

 マルチパラダイムデザインの基本概念を表1にまとめました.

 中核となる概念は共通性可変性です.
何が共通性で何が可変性かを理解していただくために,その例を示しましょう.
テキストエディタ用のバッファはどのようなものであっても,ライン数とカレントラインを必ず持つでしょう.そして,ファイルもしくはストリームからデータを取り込む,データを書き込む,指定されたラインを取り出す,内部でメモリを管理するなどの振る舞いをします.これらが共通性です.しかし,扱えるキャラクタセットはASCIIかもしれませんし,EBCDIC かもしれません.
メモリ管理のためのワーキングセットアルゴリズムもさまざまなものが考えられるでしょう.この場合,「(何らかの)キャラクタセットを扱う」は共通性で,そのとりうる値は可変性になります.「ワーキングセットを(何らかの)アルゴリズムで扱い」は共通性で,そのアルゴリズムは可変性になります.(これは『マルチパラダイムデザイン』に掲載されている例です.J. O. Coplien, D. M. Hoffman, and D. M. Weiss. Commonality and Variability in Software Engineering. IEEE Software, 15(6):37-45, November/December 1998.,Weiss, David M., and Chi Tau Robert Lai. Software Product Line Engineering: A Family-Based Software Development Process. Reading, MA: Addison Wesley Longman.1999. にも,共通性と可変性の例が載せられています.参照してください.)

 マルチパラダイムデザインにおけるパラダイムとは,ソリューションドメインの個々の要素に対応します.共通性と可変性の対で構成されるのがパラダイムで,C++でいえば,テンプレート,オーバーローディングなどがパラダイムになります.パラダイムという語の由来などは,『マルチパラダイムデザイン』もしくは "Multi-Paradigm Design and Implementation in C++" を参照してください.


表1 マルチパラダイムデザインの概念

用語 意味
ドメイン 関心の対象領域.
ソフトウェアファミリ,ファミリ 何らかの共通点でグルーピングされたもの.
ファミリの個々の要素を,ファミリ構成員という.
共通性 すべてのファミリ構成員に共通する性質.
可変性 ファミリ構成員ごとに異なる性質.
可変性を何らかの形でパラメータ化できると,再利用性を増すことができる.
正の可変性 共通性を維持したまま,構成員ごとに変化する可変性.
負の可変性 共通性を侵害する可変性.
通信システムのメッセージでは,ACK,NAKがあるがこれはメッセージボディを含まないメッセージ.もしメッセージの共通性として「メッセージボディを持つ」を定義したならば,その値のレンジは負の可変性を持つことになる.
(『マルチパラダイムデザイン』に挙げられている例)
共通性分析 ドメインの共通性は何かを分析すること.可変性分析と並行して実施する.
可変性分析 共通性分析で見つけられた個々の共通性について,その可変性を分析する.
共通性カテゴリ 共通性の分割基準. 例) 構造,振る舞い,名前
可変パラメータ 可変性のパラメータ.これが1個のドメインを形成することもある.
アプリケーションドメイン分析 アプリケーションドメインとは,ソフトウェアシステムを導入の対象となるドメイン.通常「問題ドメイン」と呼ばれる.マルチパラダイムデザインでは,これをあえてアプリケーションドメインと表現する.必ずしもすべてのプロジェクトの対象が問題とは言えないというのが,その理由.
アプリケーションドメイン分析では,まずサブドメインに分割して,各サブドメインのスコープ(scope)を決め共通性(commonality)と可変性(variability)を分析する.(SCV分析というドメイン分析手法)
ソリューションドメイン分析 ソリューションドメインとは,ソフトウェアシステムのためのテクノロジーのこと.C++,Java,データベース管理システムはそれぞれソリューションドメインを形成する.
ソリューションドメイン分析では,ソリューションドメインのスコープを決め,共通性と可変性を分析する.
変換分析 アプリケーションドメインに適切なソリューションドメインを選び出し,アプリケーションドメインの共通性と可変性をソリューションドメインの共通性と可変性にマッピングする方法を分析すること.

 

■ マルチパラダイムデザインを適用してソフトウェアを開発する:基本形

 マルチパラダイムデザインの肝は,アプリケーションドメインだけでなくソリューションドメインも分析対象にすることです.マルチパラダイムデザインを適用したシステム開発(正確には,ドメインエンジニアリング)の概要を示すと,図1のようになるでしょう.


図1 マルチパラダイムデザインによるソフトウェア開発

 

 ここで注意してほしいことは,ソリューションドメインの分析は,アプリケーションドメインの分析に対応してやるのではなく,独立して実施できることです.したがって,アプリケーション開発のたびにソリューションドメイン分析を実施する必要はありません.たとえば実装のためにC++を利用するのであれば,『マルチパラダイムデザイン』に載せられた分析結果をそのまま利用できます.

 表2に挙げたのは,C++というソリューションドメインの分析結果の一部です.


表2 C++の共通性と可変性 ( "Multi-Paradigm Design and Implementation in C++" スライド16の訳,著者の許可を得て翻訳)

共通性
可変性 バインディング時期 インスタンス化 C++メカニズム
関数名とセマンティクス アルゴリズム構造以外 ソースコード時 N/a テンプレート
細粒度のアルゴリズム コンパイル時 N/a #ifdef
細粒度/粗粒度のアルゴリズム コンパイル時 N/a オーバーローディング
データ構造 状態の値 実行時 Yes struct,単純な型
値の小さな集合 実行時 Yes enum
型,値,状態 ソースコード時 Yes テンプレート
操作と構造 状態の値 ソースコード時 No モジュール
状態の値 ソースコード時 No struct,class
データ構造と状態 コンパイル時 オプション 継承
アルゴリズム,データ構造,状態 コンパイル時 オプション 継承
実行時 オプション
仮想関数

 

 アプリケーションドメイン分析結果のその共通性と可変性が表2に挙げたC++の共通性と可変性で表現できるのであれば,実装テクノロジとしてC++を選択できます.アプリケーションドメインの共通性と可変性の組ごとに,上記のような表の共通性・可変性の組を調べ,適切なC++言語要素を選択します.これを 変換分析と呼びます.表3は,エディタ用のテキストバッファのアプリケーションドメイン分析結果に,変換分析の結果を併せて載せたものです.「デフォルトテクニック」の列にイタリック体で表記したものが,表2から適切であると判断されたC++言語要素です.


表3 変換分析テーブル ( "Multi-Paradigm Design and Implementation in C++" スライド19の訳,著者の許可を得て翻訳)

可変パラメータ 意 味 ドメイン バインディング時期 デフォルトテクニック
出力型の構造
アルゴリズム
テキストラインの整形化は,出力メディアに強く依存する データベース,RCS,TTY,UNIXファイル 実行時 UNIXファイル
仮想関数
キャラクタセット
構造は無関係
バッファ型ごとに,異なるキャラクタセットをサポートする ASCII,EBCDIC,FIELDATA コンパイル時 ASCII
テンプレート
ワーキングセット管理
アルゴリズム
アプリケーションごとに,キャッシュするメモリ量が異なる ファイル全体,ページ全体,LRU fixed コンパイル時 ファイル全体
継承
デバッキングコード
コード断片
開発部署内のデバック,ソースコードをテストする デバックの成果 コンパイル時 None
#ifdef


 1個のソフトウェアシステムは通常複数のサブドメインからなり,サブドメインごとに実装テクノロジが選択可能です.個々のドメインは複数の共通性・可変性対を持ちます.そのすべての対を適切に表現できる共通性・可変性をもつソリューションドメインが望ましい実装テクノロジになります.

 マルチパラダイムデザインでは,個々のアプリケーションの開発ではなく,アプリケーションのファミリの開発を目指していることに注意してください.たとえば,テキストエディタにマルチパラダイムデザインを適用したならば,実際のテキストエディタの作成は,個々の可変性に対して,可変パラメータの値を決めていくだけでよいのです.

 アプリケーションドメイン分析のサンプルは,FASTのテキスト(Weiss, David M., and Chi Tau Robert Lai. Software Product Line Engineering: A Family-Based Software Development Process. Reading, MA: Addison Wesley Longman.1999.)に載せられたものが参考になると思います.

 熟達した技術者であれば,表2,3に挙げたようなことは,暗黙的に行っていると私は思います.それを形式知とすることで,属人性を排除できますし,これまで鑑みることもなかった新たな領域に可能性を見つけ出せる可能性が増します.

■ アプリケーションフレームワークを作成する

 デザインパターンとマルチパラダイムデザイン

 アプリケーションフレームワーク構築のために,Pree が提唱したホットスポット・フローズンスポットは,それぞれ共通性と可変性に対応することがわかります.アプリケーションフレームワークは,オブジェクト指向プログラミング言語の特性を生かすことで可能になったものです.

 Pree はメタパターンという形でソリューションドメインの可変性を表現しようとしました.マルチパラダイムデザインでは,実装する個々の言語の特性以上に抽象化することはしません.しかし,たとえば GoF の "Design Patterns" (邦訳『デザインパターン』ソフトバンク) が ET++ というアプリケーションフレームワーク構築の経験から導き出されたパターンを元にしていることからもわかるように,ソリューションの一部としてパターンが取り込まれていることが必要です.では,マルチパラダイムデザインでは,デザインパターンをどのように考えているのでしょうか.

 Copeは,

 「(デザイン)パターンの多くは共通性とパラメータ化された可変性を表現するもの」

 そして,マルチパラダイムデザインとデザインパターンの関係を

 1. ソリューションドメイン分析に登場する共通性/可変性対のエイリアス.
 2. C++の言語構成要素よりも抽象度が高い抽象.C++の構成要素は,そのような抽象のもとに構成される.
 3. 負の可変性を扱う強力なメカニズム.

と説明しています.表3は,パターンをマルチパラダイムデザインで表現したものです.(負の可変性は,マルチパラダイムデザインの中でも重要なアイデアです.紙面の関係で詳細を説明できませんので,この議論に興味のある方は『マルチパラダイムデザイン』の6.12節を参照してください.)


表4 デザインパターンの共通性/可変性分析(『マルチパラダイムデザイン』p.161)

共通性 可変性 バインディング インスタンス化 パターン
関数名
関数セマンティクス
細粒度のアルゴリズム 実行時 N/A TEMPLATE METHOD
アルゴリズム
コンパイル時デフォルトを含む実行時 N/A Unification +
TEMPLATE METHOD
アルゴリズム:可変パラメータが状態 実行時 Yes STATE
操作と構造
(正の可変性)
粗アルゴリズム 実行時 N/A STRATEGY
状態の値 ソースコード時
一度
SINGLTON
粗アルゴリズム
ソースコード時
(もしくはコンパイル時)
N/A (テンプレートを使用する)STRATEGYもしくはUnification
操作,構造は含まない 互換性のないデータ構造 いずれも Yes BRIDGE
ENVELOPE/LETTER


 フレームワークとソフトウェアプロダクトライン

 図2に挙げたのは,ソフトウェアプロダクトラインの概念です.まず「ドメインエンジニアリング」を実施して再利用部品を作成し,個々のアプリケーションは「アプリケーションエンジニアリング」を実施して,再利用部品から開発します.この「ドメインエンジニアリング」で,マルチパラダイムデザインのアプリケーションドメイン/ソリューションドメイン,共通性/可変性というアイディアが取り込まれています.プロダクトラインのソリューション実現方式の1つにアプリケーションフレームワークがあると考えることができます.


図2 ソフトウェアプロダクトライン模式図

 

注)ソフトウェアプロダクトラインの1手法に位置付けられるFASTとマルチパラダイムデザインの考え方には違いもあります.マルチパラダイムデザインでは,ソリューションドメインは既存のテクノロジもしくは今後登場してくるテクノロジです.それに大してFASTでは,アプリケーションドメインごとに,アプリケーションドメインに特化言語を作成します.これは, J. L. Bentley が "More Programming Pearls: Confessions of a Coder",Addison-Wesley. 1988.で,little language と呼ぶものです.

■ ASOC(Advanced Separation of concerns)

 マルチパラダイムデザインはASOCという新しい設計潮流の1つに数えられます.ASOCには,

アスペクト指向プログラミングを含むリフレクション,
ジェネリックプログラミング,
インテンショナルプログラミング(intentional programming),
生成的プログラミング,
パターン

などが含まれています.(生成的プログラミングには,アスペクト指向プログラミング,ジェネリックプログラミング,インテンショナルプログラミングが取り込まれています.K. Czarnecki and U. Eisenecker. Generative Programming: Methods, Tools and Applications. Addison-Wesley, 2000.) 

 Separation of concerns(関心の分離)は,構造化プログラミングで著名な Dijkstraの説いた良いソフトウェアを可能にする技法です.結合度を下げ凝集度を高めるテクニックの1つで,このテクニックの適用はメンテナンス性,再利用性に貢献することになります.このテクニックはオブジェクト指向でも採用されています.関連する責務のまとまりを1つのクラスの振る舞いとして定義しますが,これは「関心の分離」 です.Buschmannたちの POSA (邦訳『ソフトウェアアーキテクチャ』近代科学社)に掲載されているようなModel-View-Controllerパターンの単純な形では,ユーザ表示部分,ユーザ入力部分,そしてそのアプリケーションのコアというデータという形での関心の分離を行っています.

 しかし,たとえば同じくPOSAのReflectionパターン(リフレクション)を見ると,これが単純な関心の分離でないことがわかります.このパターンには,ソフトウェアをメタレベルとベースレベルに分割し,メタレベルを操作することによって,サービスを利用者に提供するベースレベルに変更を加えます.このように,ASOCでは「単純にはセパレート」できないソフトウェア上の関心について,さらに進んだ方法を考えていこうとしています.

 マルチパラダイムデザインでは,論理的な単位であるドメインのオーバーラップという問題から,関心の分離に関する高度な,しかしより現実的な解に挑戦しています.(これは著者が力を入れているところです, "Multi-Paradigm Design and Implementation in C++" や『マルチパラダイムデザイン』の第8章,第9章を参照してください.)

注:『ソフトウェアアーキテクチャ』に掲載されているReflectionパターンは,リフレクションの初期のアイディアです.たとえば東京工業大学の千葉滋先生のホームページ(https://www.csg.is.titech.ac.jp/~chiba/)で,リフレクションについてさらに学ぶことができます.

 Copeは,とくに生成的プログラミングに注目していて,マルチパラダイムデザインとこれを組み合わせることで,複雑なソフトウェア設計に実用的な解決策が生み出せるのではないかと研究を続けています.これについては,"Contemporary Trends in Advanced Design"( 翻訳 )を参照してください.

■ 最後に、『マルチパラダイムデザイン』の読み方

 『マルチパラダイムデザイン』は,1998年に刊行された第1版の翻訳そのものではなく,その後の研究成果を盛り込んだものになっています.

 著者は,前から順番に読んで、と書いていますが、とありますが、第1章は読み飛ばしてもかまわないと思います.この章は,著者の意向を押し切って,日本語版に入れました.なぜなら、私たちはここに書かれているような背景をあまり知りませんし,これから日本にも普及してくるかもしれない概念の存在と関係があるということを知っておくことは,ただの興味というだけでも楽しいことではないか,と思ったから.

 この本には,マルチパラダイムデザインのアイディアだけでなく,そこに行き着くまでにプロジェクト経験から学んだこと・考えたことがちりばめられています.特に第6章,7章には強い思い入れが込められているように思います.うまくそれが訳せたとは言えませんが,著者とみなさんの橋渡しができれば,うれしく思います.


© 2002 OGIS-RI Co., Ltd.
HOME HOME TOP TOP