Publications‎ > ‎Mpd‎ > ‎

ThesisIntroduction_jpn


Multi-Paradigm Design

『マルチパラダイムデザイン』への序論



James O. Coplien


PhD thesis, Vrije Universiteit Brussel, May 2000, pp. 13 - 22


日本語 第1版 2002年2月2日

これは,Multi-Paradigm Design. PhD thesis, Vrije Universiteit Brussel, May 2000.の"Introduction"を日本語訳したものです.



  マルチパラダイムデザインは,1つのテクノロジやテクニックを越えて,ソフトウェアにおける抽象および設計についての基礎的な疑問を,より深く掘り起こそうというものである.パラダイムとは何なのか,分析・設計・実装にはどのような関係があるのかといった質問により,「抽象」というものの基礎が形作られる.ここで,「抽象」とは,設計とプログラミングの基本パラダイムの根底をなすものである.そして,このような質問に解を与えていくことが,アカデミックな研究業績である原理を押し広げて,洞察を広め,経験を深めることにつながっていく.このような質問には,テクノロジに関するものだけではなく,広い意味でのシステム構成の設計に関するものもある.

はじめに

  まず最初に,本論文の主題と方向付けを提示して,読者の興味を喚起したいと思う.また本論文がこれまで行われてきた研究とどう違うのかを理解していただくために,コンテキストと動機を説明し,今日のソフトウェア開発が直面している主要事項と本論文の関わりを提示することにしよう.

  現在まで行われてきた数多くの研究では,それが論文という形で提示される場合,新規の貴重な発見に焦点があてられるのが常であり,多大な労力を費やして,そのコンテキストを限定して,アイディアを評価し,運が良ければ正当性の見積りが行われてきた.そのようにして事を進めることは難解を極める.課題は高度で,解決策はすぐに解読できるものではない.そのうえ,このように書かれた論文というのは,著者の年齢やどのような経験をしてきたかに左右される.本論文はこれまでの研究や最先端のテクノロジについて述べているだけでなく,1970年に私がはじめてプログラムを書いた時点から疑問に思い続けてきた課題の解決に基づいている.システムプログラマとして働いてきたそれからの10年の間も,開発と次世代テクノロジに関する調査を行ってきた80年代も,研究者として努めてきた1990年代にも,私はその課題について考え続けてきた.

  さまざまな深刻な課題に直面にして,そのたびに繰り返し解決してきたという私の経験を統合するという形で論文を書く,というのが私の選択した方法である.現代の課題としてホットな話題を取り上げて,整理された形式でまとめるというのではなく,過去に立ち返り,時代とは関わりのない課題を調べるということを本論文では試みている.たしかに本論文は最新の研究成果やテクノロジ的発見に立脚している.ごく最近になってさまざまなコミュニティで試みようとされている課題を扱ってはいるが,同時にこれらの課題は表面下にどのような時代にもどんな場合にも潜伏していたものでもある.私を含めて何人かの研究者は,このような課題が人々に注目されるよりも10年あるいは20年も前から,この課題の解決に取り組んできた.

  本論文の基となった研究は,過去何十年にもわたって,その時代のコンピュータサイエンスで最も難しいとされてきた最先端の課題について考えられてきたことを,撚り合わせて整理し拡張したものである.すなわち,プログラミングの数学的本質と解析的本質を超えた複雑な課題への対処を提示している.本論文では,これまで提案されてきたほとんどすべての形式手法やパラダイムでは成し遂げることができなかった課題,「複雑性をどのようにモデル化するか」に取り組んでいる.これまでのパラダイムでは,多重の次元を持つ世界を単純な1次元のビューで捉えようとしてきた.しかし単純に考えても,いくつかのパラダイムを同時に併用することが必要になることがわかる.

  これまでよりも深く設計を捉えることができるような方法でパラダイムの組み合わせを扱う形式手法や原理はすでに存在する.そこで,本論文では抽象というものが支配する領域について深く取り扱うことにした.抽象を形式的に可能とする共通性(commonality)と可変性(variability)が,本論文で扱っている項目である.このようにしたことには,何十年もの私の経験という意味でも,認知科学における研究成果という意味でも,れっきとした理由がある(本論文ではそれについて完全にカバーすることはできないけれども,1.9.3節で触れている).この2つの原理を選択したのは,純粋にアカデミックな理由からではない.基本的にはソフトウェアの抽象を理解するための質問に関連したすべてに関わるような,理解しやすく一貫した意図(intentionality)をもち保守性の高いプログラムを作成するという経験に立脚する視点から,このような選択をしたのである.本論文で紹介するアイディアは,「抽象」についての質問よりも「パーティショニング」(分割)に関わる質問への解として考案したものである.経験的に,複雑なシステムにおいては抽象というものが危険なものになり得るということがわかっているので,このような方法をとることにした(抽象とは意図的に何かを無視することだ).まず最初に,関心の分離をするための抽象ツールを選択することが重要である.また,それを終着させるための最後の方法としてのみ,詳細の削除を行うようにする.本論文で「抽象」と呼んでいるものは,世界を認識するのに役立たなくてはいけない.圏論(category theory)を用いて世界について考えるのと同じような方法で役立つものでなくてはいけない.そのように扱うことで,抽象はパラダイムよりも深い意味を持つものになるだろう.

  このような深みにまで研究を進めなくてはならず,また,統合的なフォーカスを持つものでなくてはいけないので,本論文執筆の基となる研究はドメインエンジニアリングのテクニックとオブジェクト指向を単に融合したものではなく,あるプログラミング言語における設計テクニックとして拡張するものとなった.ここでいう設計テクニックについては,例えば[Vici+1998]で記述されている.本論文は,設計を考える新しい方法についての基礎を提供する.そして,本論文で述べる原理が,問題ドメインにもソリューションドメインにも適用可能であり,また適用可能なパラダイムに限定を加えず,さらには数多くの実装テクノロジにも適用可能であることを証明する.

  Chapter1 では,この見通しについてさらに深く遡及して,この研究に対する私の主張を述べる.そこで,この序論では,本論文で取り上げる概念について簡単に説明しておく.

抽象(Abstraction)

  設計に関する最も基本的な問いかけの1つに,「抽象」とは何かというものがある.抽象は,ソフトウェア設計のための主要ツールの1つである.そして,際限なく増大し続けるコンピュータシステムの複雑性を管理するために無くてはならないものである.「抽象とは何か」という問いに対する一般的な解は,通常,オブジェクトに関連した何かという形で提示される.つまり,過去10年か,もしかしたら20年にも及ぶオブジェクト指向テクノロジを実現しようと考えられ蓄積されてきた膨大な文献とツールを反映した解答がなされることになる.しかし,この受け答えは,設計の共通構造を無視したものである.ここで設計の共通構造とは,プログラマが日常的に用いる構造のことを言っている.この「共通構造」は,オブジェクト指向による構造とは異なるものだ.すなわち,テンプレート(template),オーバーロードされた関数群,モジュール,ジェネリック関数といったものが,設計で通常使用されるものだろう.C++を利用すればこれは一般的な設計構造だが,C++を利用する場合に固有な方法というわけでもない.あるテクニックの優位性について議論されることが多いものだが,実際には開発者の経験から見てもまた実際に利用されているアプリケーションから考えても,このようなニーズを満たすためにはどのようなアプローチでもたった1つではこと足るるということはあり得ない(そのようなアプローチの1つとしてオブジェクト指向がある.他のあらゆるテクニックよりも優れているテクニックというものは,おそらく存在しないだろう).

  基本的な設計原理に立ち戻って,「なぜ抽象なのか」という質問が発せられることもある.多くのコミュニティでは,抽象が「優れていること」の同義語として用いられてきた.しかし,最も多い抽象とは「階層」である.システムがレイヤ構造や階層構造に分割できるほど単純な場合には,これは適切である.オブジェクトパラダイムでは,このように考えて,クラス階層と実装階層の両方を構築しようとする徴候がある.しかし,現代のシステムに内在する複雑な構造は,本質的に階層構造に帰すことができるというものでもない.まず,スケールの問題がある.コード行が100のオーダーかもしれないし,1000,あるいは,1億,10億,100億のオーダーかもしれない.このようなスケールのものを単純な階層構造で適切に分析することはできない.何らかの関わりを持つとは限らない数多くの「トップ」階層を持つような大規模システムは,「トップダウン」つまり汎用的な用語でいえば階層構造を持つようなものではなく,さらにはシステムの構造に対する意味を欠いてしまっている.テレコム会社のシステムで考えると,このような「トップ」として,請求,オペレータ処理,電話接続処理,システム管理,システム保守などさまざまなものが考えられる.概念的な意味では,「トップ」同士は関連性を持たないのだが,それらの実装コードは互いに容易に分離できるというものではない.モジュール分割はいくら優れていたとしても「おおよそ」の域を脱することができない.どのような場合であっても,これは真である.モジュール分割が完璧なシステムというものは存在しない.複雑なシステムであれば多くの場合,モジュール分割のウェイトは望ましいとか,このようにしようという規則以上のものではない.

  次に問題になるのは,ドメインが複雑であるということだ.すなわち,対象が自然であってもビジネスであっても,階層構造で問題を定式化するのは易しいことではない.しかしそれにもかかわらず,設計戦略および実装戦略の多くは,世界を階層的に設計し実装しようとする.1つの階層をあらゆる問題に適用して機能させることはできるだろうが,ソフトウェア開発の中で不可避的に発生する変更を考慮に加えた場合には適切さを失う.ソフトウェアはソフトで上述の変更にも対処できるものだと考えられているが,経験的には,ビジネス革新の自然な方向に沿った形で実装の分割をするという挑戦的課題に対して1つのパラダイムで巧みに解決を図ることができるというものではない.

  そこで,今日のソフトウェアに課せられている主な課題の根底にあるのは,ビジネスドメインの構造を把握することと,それを満たす実装の最適構造を見つけ出すことである.マルチパラダイムデザインはこの課題に挑むものであり,コードの中に重ねて埋め込まれた抽象を設計する原理を提供する.マルチパラダイムデザインが支援するのは,階層的に考えられた抽象ではなく,網状に関連し合う抽象である.すなわち,類似した複雑性を有する構造を備えるような複雑なドメインを表現するのに,より適した表現を可能にするような抽象である.本論文で紹介するマルチパラダイムデザインでは,アプリケーション構造を説明するのに,運命であるかのように「オブジェクト」を必ず使わなくてはならない,というものではなく,そのアプリケーションに固有の用語を使って表現できると考える.そして,その固有の用語の各々に対してそれを基盤にするパラダイムを考える.そして,,問題空間と解空間の間の変換を,問題に関するアクティビティに含まれるものだとか,解に関するアクティビティに含まれるものだと考えるのではなく,1つの確立されたアクティビティだと捉える.これは単純な課題でもなければ,アルゴリズムとして記述可能とか,証明できるものとして定式化できるという類(たぐい)の課題でもない.しかし,抽象の基礎的原理である共通性と可変性を用いれば,取り組みが可能な課題である.

共通性と可変性

  どのような抽象のテクニックにも共通する原理というものが存在する.テクニックとは,そのような原理の有するプロパティに従って,エンティティのグループ化を行う方法のことで,個々のエンティティと他のエンティティとの異なり方についての規則性についても規定されている.そして,各テクニックごとに,このグループ化の方法が異なっている.あるテクニックにおいて,共通性は,繰り返し外部に発現するシステムのプロパティを表現するものである.そして,共通性によって表されるプロパティは,そのシステムのドメインに密接に関係している.

  別のテクニックにおいては,共通性は分析でカバーすることのできない暗黙構造を秩序立てるのに役立つ.つまり,あるドメインで くり 返し登場 す る解決策に た いして,分析によってはカバーすることができない何か に 秩序を 捧げる ことができる.

  マルチパラダイムデザインは,この両者の姿勢を共に踏襲している.例えば,オブジェクト指向設計と呼ばれるテクニックでは,オブジェクトをクラスにグループ化する.クラスは,そのオブジェクトが共通して有している構造と振る舞いを特徴付ける.そして,そのようなクラスを,構造と振る舞いに存在する共通性を反映する階層やグラフの形でグループ化するのであるが,同時に,ある振る舞いを実現するためのアルゴリズムや構造には,規則正しい可変性によるバリエーションが可能である.共通性と可変性によるさまざまな特徴を利用して,鋳型(テンプレート)を記述することができる.共通性と可変性は,抽象というものに広範で単純なモデルを提供する.これらは,オブジェクトやクラスよりも広範であり,その広範さは,大部分の設計とプログラミングテクニックを取り扱うのに十分なものである.

ソフトウェアファミリ(Software Family)

  共通性と可変性は,ソフトウェアの設計モデルとしては新規のものではない.ソフトウェアファミリ(software family)というParnasの概念 [Parnas1976] は,少なくとも20年前には提案されている.ファミリとは,共通性により関連付けられるソフトウェアの集まりである.ファミリを構成する個々のメンバは,可変性により差異化される.ソフトウェアファミリの概念から生み出された設計のアイディアは,現代のプログラミング言語の中に見出すことができる.そのよい例としては,モジュール,クラス,オブジェクト,総称性の構成要素(generic construct)がある.アプリケーション固有言語のための環境におけるLaiとWeissの仕事は,ソフトウェアファミリというアイディアに限界があることを示している[Weiss+1999].いわゆる分析のアクティビティではソフトウェアファミリを発見することに焦点を合わせ,いわゆるコーディングのアクティビィティでは,分析で検出された抽象をどのように表現するかということに焦点をあてることになるが,これらのアクティビティはいつも密接に撚り合わされたものになる.マルチパラダイムデザインでは,言語,設計,ドメイン構造,共通性とvariationを表現する方法の密接な結びつきを意識的に区別する.

ドメイン分析(Domain Analysis)

  ドメイン分析というアクティビティにより,ソフトウェアファミリを見つけ出すことができる.ドメイン分析というのは,また1つの分野をなす研究で,すでに長い期間の研究の蓄積がある[Neighbors1980].ソフトウェアの再利用が,ドメイン分析のもともとのゴールであり,このゴールとソフトウェアファミリとは相性がよい.マルチパラダイムデザインは,再利用が重要であるということを明確に意識するものだ.設計者が広範な市場を見越してソフトウェアを考えるのに役立つように,マルチパラダイムデザインでは,共通性と可変性を明白に分離する.共通性は変化することが決してないとみなされるものであり,可変性は変化するとみなされるものである.単なる分析ではなく,ドメイン分析に精力をつぎ込む必要がある.そして,単なる抽象を設計するのではなく,抽象から構成されるファミリを設計する.うまくやれば,設計に対するこのアプローチによりメンテナンスが容易になり(このためには可変性によって生み出されるバリエーションの予見がうまくいくということが必要である),弾力のあるアーキテクチャが構築できる(変更を施そうとするたびに,そのソフトウェアに深く潜水する必要がないということを言っている).もちろん,マルチパラダイムデザインは再利用を援助するテクノロジ的な要素をサポートするツールの1つに過ぎない.効果的な再利用とは,組織,市場,ソフトウェアエコノミーといった広いコンテキストで行われるもののことを言うのである.

パラダイム(Paradigm)

  パラダイムの概念は,共通性と可変性という土台を使って形式化できる.パラダイムという用語は,現代のソフトウェア設計においてなじみのあるものだが,システムにおける抽象を共通性と可変性に関するプロパティで組織化する方法の1つである.オブジェクトパラダイムは,構造と振る舞いにおける共通性と,構造とアルゴリズムに基づく抽象を用いてシステムを有機的に結びつける.テンプレートパラダイムは,ファミリ構成員間の構造的な共通性に基づき,その可変性はテンプレートパラメータとして明示的に外在化されたファクタになっている.オーバーローディング関数はファミリを形成し,そのファミリのメンバは同一名と同一意味論を持つ.そして,個々のメンバ間の違いは仮パラメータの型により区分される.

  私はここで「マルチパラダイム」という用語を使っているが,少しばかり不安が無いわけではない.早い段階から本論文のレビューアを引き受けてくれていた Tim Budd は,彼の抱くマルチパラダイムという概念と本論文のその概念の間に紛らわしい差異があることを指摘し,それを使用することについて危惧すると伝えてくれた.私はといえば,「分析」など用語を使用することに危惧を感じていた.趣味というだけでなく日常的にプログラミングをやる人々が手元に置いて,必要になるたび手にしてくれるような書物に仕立て上げたいと切に願っていたからだ.Tim Budd も私の心情を気持ちよく理解してくれて,「マルチパラダイム」という言葉を広義に捉えたならば彼の意見も私の意見もうまく説明できるだろうと助言してくれた.彼の進言を,私は喜んで受け入れた.プログラマに対して書かれた本であること(これは方法論者に対してではなく,ということを意味している)をわたしは強く言いたいのだ.

マルチパラダイムデザインとC++

  C++はマルチパラダイムを支援するプログラミング言語である.すなわち,クラス,オーバーロード関数,テンプレート,モジュール,通常の手続き型プログラミングなどの言語要素を持つ.C++の創始者 Bjarne Stroustrup は,意図して,C++をそのような言語にしたのである.たいていのプログラマは,C++の言語機能を使用するのに,単にオブジェクトを意識して使用するだけではない(過剰な要素を間違って使用するプログラマもいるし,他の言語の特徴を利用したほうが自然な設計になるにも関わらず無理やりにもオブジェクト指向の枠にはめようとする開発者もいる).John Barton と Lee Nackman による強力なテンプレートコード[Barton1994]や,Czarnecki と Eisenecker による生成的プログラミングテクニック(generative programming technique)[CzarEise2000]は,おそらくマルチパラダイムデザインに適ったものだろう.

  Stroustrup はC++をマルチパラダイム言語に仕立て上げようとしたのだが,C++の豊富な言語要素に適した設計手法を編み出そうという真剣な取り組みは行われてこなかった.C++がポピュラーになってからも,そのようなことは行われていない.天才プログラマは直観で複数のパラダイムを混在させて利用することができる.しかし,個人を超えて産業というレベルで考えると,そのような試みはなされていないというのが事実であり,それどころかC++におけるパラダイムの混在を形式化するということを忘れてしまっているかのように思える.現在,設計に関する文献と,実務の現場におけるC++の言語要素の使い方には隙間がある.その証拠に,例えば,STL(Standard Template Library)[Musser+1998]は成功を収めたというのに,パラメータ付き抽象(parametric abstraction)を定式化し利用するための設計手法は存在しない.本論文は,この隙間の橋渡しをするものである.開発者がさまざまなパラダイムを直感的に結び付けられるように,単純な記法と用語を使用することにしよう.本論文で述べるテクニックは,熟練したC++プログラマであれば,わかりきったことかもしれない.そして,このテクニックの形式化はプログラマの直観に合致するものだろうが,そのような形式化を行うことについてはC++で設計しプログラミングをする人々がこれまで気づかないでいたのだ.さらに,この形式化は,共通性とvariationに根を持つパラダイムモデルをベースにし,設計に対して新しい視点を獲得するための跳躍版になることだろう.また,数多くの表現力豊かなプログラミング言語(expressive programming language)を生み出すものでもあり,汎用的な意味でのソフトウェア設計を生み出すものでもある.

メタ設計(Meta-Design)

  1995年の9月に私はDePaul大学で講義を受け持ったのだが,そのときに部門長 Helmut Epp からメタデザイン(meta-design)を使ってこの研究を進めてはどうかと提言を受けた.メタデザインが対象にしているのは,まずドメインに最適な設計テクニックを特定することであるので,私の仕事と関係するだろうというのである.メタデザインは,本論文で取ったアプローチ対して有効な示唆となった.そして,実際,多くのプログラマが採用するアプローチの方法を記述するものである.プログラマはまずどのパラダイムを使うかを決定しなくてはいけない.そして,システムの各パートに対して適しているパラダイムを決定し,そのルールとツールを設定する.このようなことはシステムアーキテクトや設計者だけではなく,すべてのプログラマが感知すべきことである.

  どのパラダイムを使用するかを決定するのは重要問題の1つである.また,そのパラダイムにおける抽象を表現するためのツールを入手することも重要問題の1つである.アプリケーションドメインを分析するのに,共通性と可変性の原理を用いてサブドメインに分割することができる.そして,そのサブドメインごとに,それに適したパラダイムのもとで設計を行うことができる.このパーティショニングを行うのは,通常は分析と呼ばれる開発フェーズである.しかし,設計の初期フェーズで考慮したほうが,より望ましいと言える.なぜなら,実装テクノロジーで表現可能な抽象を生成しようとするのが設計だからだ.実装ツール(プログラミング言語やアプリケーションジェネレータといったツール)がすべてのパラダイムに対処できるとは必ずしも言えない.この理由から,アプリケーションドメインだけでなくソリューションドメインのドメイン分析を実施することが重要になる.マルチパラダイムデザインは,このアクティビティを明確に実施する.ソリューションドメインの分析は,マルチパラダイム設計が持つ「メタデザイン」的性質の1つの彫面である.

方法論から独立した手法

  本論文で扱わなかった事柄も多くある.本論文は包括的な設計手法を述べているわけでもなければ,ソフトウェア開発のライフサイクルモデルを説明するわけでもなく,設計に対して少し異なった(turn-the-crank)アプローチをやろうと説くものではない.優れているとされる新しい設計テクニックというものは,概して従来存在していた設計テクニックの変化形である.つまり,まったく新しい問題とか,あるいは,いままでに遭遇した課題とは完全に異なるというようなものに直面することはまれである.本論文の表現方法やテクニックを新規システムのすべてのモジュールに適用するというのは不適切だし,時間の浪費でもある.しかし,我々が新しい課題に直面するときには,その課題の中に構造を検出して,その理解をもとに設計や実装のフェーズに持ち込んでいく必要がある.マルチパラダイムデザインの記法やテクニックはそれに役立つだけでなく,オブジェクト指向パラダイムを他のパラダイムで補強するという方法で,ドキュメントを設計する統一的な方法を提供する.

  マルチパラダイムデザインは厳密で完全な規律を備えた手技でもなければ手法でもない.本論文では,ソフトウェア開発者の思考過程を支援することができるような記法,ダイアグラム,設計モデルを扱う.このような形式化をやろうとすると,形式的方法それ自身に夢中になってしまう誘惑が必ずつきまとうというのは事実である.マルチパラダイムデザインは,アーキテクチャを生み出すアクティビティを集めたものであり,アーキテクチャとは断片間の関係を示すものである.しかし同時に,アーキテクチャはユーティリティでもあるし,美学でもある.つまり,アーキテクチャは,さまざまな多くの手法では扱いきれていない,優れたソフトウェアのプロパティなのである.美しいということが,本論文では主要な位置を占める.私には設計やコード化の自動化を促すようなテクニックを提供しようという意図はまったくない.美しさは,経験に帰することと,優れた洞察に由来するものを併せ持つものである.このようなことをPh.D.の誓いにすることは一般的なことではないだろう.しかし,もしかしたら,このようなことから,我々が携わっているソフトウェア業界の短所の多くを説明し得るのかもしれない.このように考えて,私は研究を行い,それを書物として著したのである.実務家の1人として研究をする人間の欠点なのかもしれない.このような良識については,第6章の終わりで,少し説明的に書き記している.そこではパラダイムのメリットについて,また,そのメリットの根底をなす設計の素晴らしさについての主観的評価基準の必然性について触れている.

  本論文のテクニックは,人間の判断力と経験を,良識で補足するものである.本論文のテクニックを適用することによってそれを見出したならば,望んだわけでもなければ理解していたわけでもなく,そのためにそれを設計とは呼んでこなかったような境地にまで,設計を引き上げることになる.本論文で扱うテクニックは,ツールであって,遵守を強制する命令ではない.しかし,どのような読者であっても,本論文とは無関係に,次のことは理解しておいたほうが良い.つまり,オブジェクト指向パラダイムや,あるいは何か別のパラダイムは,有用なパラダイムの1つに過ぎず,設計では1つのパラダイムで表し得る以上の構造を表現しなくてはいけないのである.

本論文の構成

  本論文の各章は,それまでの章に基づいて新しい概念を説明するという構成になっている.それにより,読者のドメインエンジニアリングとマルチパラダイムテクニックに対する理解が増すように考慮している.章順に読み進めて,参照として先の先の章に戻るという読み方が,大部分の読者に適していると思う.

  Chapter1 から Chapter7 では,ドメインエンジニアリングの知識を下敷きにした基礎事項を扱っている.

  • Chapter1 で,本論文のねらい,用語の紹介,マルチパラダイムデザインの必然性について述べる.この章は,ドメインエンジニアリングについての高レベルの知識に基づいている.

  • Chapter2 と Chapter3 では,共通性分析と可変性分析について記述する.システム開発においては,この2つの概念が対になって利用されるが,表現を簡素化するため,および,その表現言語の機微を強調するために,共通性は共通性としての権限を持ち,可変性は可変性としての権限を持つ.Chapter3 では,正の可変性,負の可変性という核となる概念を紹介する.明白な設計(clean design)が重要であること,ドメインエンジニアリングとよく使用されるデザインパターンとをどのように組み合わせるかを理解していただくことがここでの主題である.

  • Chapter4 では,ドメイン分析を使って,アプリケーションドメインの抽象を見つけ出す方法を説明する.ここでは,それまでの章で述べたテクニックを駆使することになる.

  • Chapter5 では,ドメインエンジニアリングの原理をオブジェクトパラダイムの抽象化テクニックのベースとして使用するやり方を示す.

  • Chapter6 は中核となる章である.「分析」のテクニックを適用して,ソリューションドメインを特徴付けるというのがこの章の内容の1つである.但し,ここでの「分析」は普通に考えられている「分析」とは異なっている.そして,共通性分析と可変性分析をベースにして形式化されたフレームワークに,C++のコンストラクタを組み込むという話題を扱う.この章では多重継承についても扱っている.さらに,ソリューションドメインで利用できるパターンを紹介し,ソリューションドメインで最もよく知られているパターンが共通性と可変性の組合せの一般系であることについても言及する.

  • Chapter7 では,これまでの章で説明した内容を組み合わせて,設計について考えるための論理フレームワークを作成する.構造的な複雑性の度合いに従って,設計の課題を分類することも試みる.また,高レベルのアクティビティ集合を紹介するが,これは優れた設計への道しるべとなり,ドメインエンジニアリングとマルチパラダイムデザインの2つのテクニックに基づいた手法のベースとなるだろう.この章では,各ドメインを開発するのに,1つのパラダイムにおけるその他のドメインとはほとんど独立に開発できることを示す簡単なケーススタディも扱うことにする.

  • Chapter8 では,前章をさらに進めて,構造上複雑な設計を調査する.ここで取り上げる課題は,単純な分割統治(divide-and-conquer)テクニックでは説明することができない.この章では,1つのドメインに内在する複数のパラダイムの使用方法を考えていくことにする.

  • Chapter9 は,「互いに絡みついた階層構造」を,複数のドメインにまたがる設計依存性と構造を用いて,詳細に調べることによって,理解の駒を進める.ここでは,再帰的で複雑な構造を持つ設計の例を挙げ,「再帰をやめる」経験則を示す.

  • Chapter10 は,本論文と関わりを持つ分野について言及し,その関係性について論じた総括である.この章では,将来の展望についても述べることにする.

Comments