phpmentors-jp/mpdosaka

第1章 序論：マルチパラダイムが必要とされる背景

iteman opened this issue · 16 comments

iteman commented

本書はソフトウェア開発におけるマルチパラダイムを説明するものだが、この章ではそのアイディアを考察するに至った動機について簡単に説明しよう。まずその背景に横たわる課題を説明する。そして、ドメインエンジニアリングとマルチパラダイムデザインとが、オブジェクト指向設計の最新技術、先行技術、新たに登場するかもしれないテーマと、どのように関係してくるのかを考えていこう。そして、その議論を通じて、本書を読み進める上で重要となる語彙を紹介する。ソフトウェアファミリ、共通性、可変性というのが本書の最も重要なキーワードである。
― 新装版 マルチパラダイムデザイン p.1

参考文献

iteman commented

ソフトウェア設計と抽象

1.1 ソフトウェア開発の課題 抽象、意図、設計の重要性 (p.1)

本書の最初のトピックは、ソフトウェア設計とは何か、について抽象の原理に基づいて考えていくことである。

古典的モデル、現代のカテゴリ理論

1.1 ソフトウェア開発の課題 抽象、意図、設計の重要性 (p.1)

認知言語学におけるカテゴリー化の議論はエレノア・ロッシュらの研究に端を発するものであり、認知言語学を生み出すきっかけの一つとなった。全成員に共通する属性によってカテゴリーを規定しようとする古典的なカテゴリー観に代わり、プロトタイプ理論や基本レベルカテゴリーの概念を提唱しており、それらに基づいて言語を記述している。

また語の意味は、その語の使用が想起する典型的な状況や百科事典的知識（世界知識）と切り離すことができないとされる。チャールズ・フィルモアらのフレーム意味論や、ジョージ・レイコフの理想認知モデルは、この考えに基づいた議論である。
― 認知言語学 - Wikipedia 2014-10-01T08:49Zの版

プロトタイプ理論（プロトタイプりろん、英: prototype theory）とは、言語学、認知心理学上の理論であり、1970年代にエレノア・ロッシュらによって提唱された。 人間が実際にもつカテゴリーは、必要十分条件によって規定される古典的カテゴリーではなく、典型事例とそれとの類似性によって特徴づけられるという考え方であり、認知言語学の主要テーゼのひとつである。こうしたカテゴリーをプロトタイプ的カテゴリーと呼ぶ。 たとえば「鳥」という語から想起されるのはカラスやスズメなどの空を飛ぶ小動物であり、ダチョウやペンギンなどは典型事例から外れている。典型性の差にもとづく現象は、一般にプロトタイプ効果と呼ばれる。これに関連して、「鳥は飛ぶ」のように、特別な文脈上の理由がないかぎりデフォルトとして仮定される状況は、理想化認知モデルなどと呼ばれる。
― プロトタイプ理論 - Wikipedia 2014-02-23T04:16Zの版

The other notion related to prototypes is that of a basic level in cognitive categorization. When asked What are you sitting on?, most subjects prefer to say chair rather than a subordinate such as kitchen chair or a superordinate such as furniture. Basic categories are relatively homogeneous in terms of sensory-motor affordances — a chair is associated with bending of one's knees, a fruit with picking it up and putting it in your mouth, etc. At the subordinate level (e.g. [dentist's chairs], [kitchen chairs] etc.) hardly any significant features can be added to that of the basic level; whereas at the superordinate level, these conceptual similarities are hard to pinpoint. A picture of a chair is easy to draw (or visualize), but drawing furniture would be difficult.
プロトタイプに関連するその他の考えは、認識のカテゴリ化の基本的なレベルのそれである。何に座っているんだ？と尋ねると、たいていの人はキッチンの椅子のような下位語または家具のような上位語よりも椅子と言うことを選ぶ。基本カテゴリは感覚**アフォーダンスの言葉で言えば比較的均質のものである。— ある椅子はある人の膝のたわみに結びつけられる、フルーツを手に取り口に入れる等。上位レベルにおいて、これらの概念の類似が特定しにくいとしても、下位レベル（例えば「歯科医の椅子」、「キッチンの椅子」等）においては、基本レベルのそれに追加することのできる重要な特徴はほとんどない。ある椅子の像は描写しやすい（または思い浮かべやすい）が、家具の描写は困難であろう。
― Prototype theory - Wikipedia, the free encyclopedia accessed January 13, 2015

全成員に共通する属性によってカテゴリーを規定しようとする古典的なカテゴリー観だけでなく、プロトタイプ理論や基本的カテゴリといった新しいカテゴリ理論に基づく抽象のモデルについて、マルチパラダイムデザインが考慮していることが示されている。

マルチパラダイムデザインが立脚する立場と意図

1.1 ソフトウェア開発の課題 抽象、意図、設計の重要性 (p.1)

本書が立脚するのは、ソフトウェア設計においては開発コストの低減、およびマーケット化に要する時間の短縮が重要だという立場である。また、わかりづらい構造を持ったシステムというのは、設計がでたらめである。そのような設計ではなく、より理解しやすいシステムを制作したい、よりニーズに適ったものを提供したいという意図（intentionality）がソフトウェア開発において重要だと著者は考えている。

前段は開発の生産性向上・高速化について言っているが、後段はソフトウェア開発における意図（intentionality）の重要性が示されている。本書の考えは基本的にジェネレーティブプログラミング（Generative Programming）とオーバーラップするものだが、いずれのパラダイムにおいても開発の生産性向上と意図性の向上は同時に達成できるものだと考えられている。

実用書として

1.1 ソフトウェア開発の課題 抽象、意図、設計の重要性 (p.1)

本書では、実用に即したソフトウェア設計を扱っていく。

Lean Architecture for Agile Software Developmentもそうだが、著者の本は実用書という位置付けが強調されている。

iteman commented

マルチパラダイムデザイン読書会 第1回

開催日時: 2015-01-17 15:30-18:00
参加者: @iteman, @kumamidori, @nyanp, @springkuma, @sugimoto-kei

iteman commented

問題と解決、アーキテクチャの関係

relationship-between-problem-and-solution

@sugimoto-kei によるこの図は、問題（problem）と解決（solution）、そしてアーキテクチャの関係を示したものだ。問題と解決の関係はフラクタルである。

ある問題に人間のユーザーが関わっている場合、開発者によって作られる問題ドメインはユーザーにとっての解決ドメインの一部となる。

iteman commented

最も重要なキーワード

導入文 (p.1)

ソフトウェアファミリ、共通性、可変性というのが本書の最も重要なキーワードである。

iteman commented

メタデザイン

1.1 ソフトウェア開発の課題 メタデザイン (pp.1-2)

本書では、そのような一般的なパラダイムの概念よりも高レベルで、ソフトウェア設計を考えていきたい。そのために、同時に複数の設計パラダイムを扱いながら設計を進めることができるような理論、モデル、メタデザイン（meta-design）というものを開発していこう。その開発の途上で、共通性（commonality）とバリエーション（variation）に基づく統合された形式性（formalism）というものも構築していくことになるだろう。そしてその形式性は、さまざまなソフトウェア開発パラダイムに共通する1つのモデル基盤を提供することになるだろう。

マルチパラダイムデザインは、様々なソフトウェア開発パラダイムに共通する1つのモデル基盤、いわばマルチパラダイムデザインモデルを提供する。これは共通性と可変性に基づく統合された形式性を使ったメタデザインの基盤ということであろう。

iteman commented

ドメインと抽象

1.1 ソフトウェア開発の課題 ドメインとパラダイムの関係 (p.2)

ここでは、ドメインは古典的な意味における抽象を特徴づけるために使用される。そして、そのような抽象は、共通性とバリエーションで記述される関心分野の構造に配置される。

本書の具体的な例を挙げると、FSM（ここでは抽象でありドメインでもある）を構成するトップ（第1階層のサブドメイン）（AbstractFSM、ImplementationFSM、UserFSM、State、Stimulus、TransitionAction）（p.47）が、共通性とバリエーションで記述される関心分野の構造（問題ドメインの構造、問題ドメインのアーキテクチャ）(pp.252-257)に配置される、というものがある。

iteman commented

オブジェクトパラダイムの拡大、見直しとマルチパラダイムデザイン

1.1 ソフトウェア開発の課題 ドメインとパラダイムの関係 (p.2)

オブジェクトパラダイムを拡大する、あるいは見直しをするといった研究分野は成熟に達していて、抽象力という意味でも表現力という意味でも限界に達した観がある（[Czar1999]、[Weiss+1999]、[CzarEise2000]）。オブジェクト指向設計が「オブジェクト」の普遍性に訴えようとしているのに対して、本書で掲げるマルチパラダイムデザインは「ドメイン」にそれを求めようとしている。

kumamidori commented

「ジェネレ−ティブプログラミング（チャルネッキ、アイセンアッカー）」

掲題の内容から拾った関連話題や基本用語について、改変を加えてピックアップしました。

[付録A 概念モデリング] より

概念

  • 数学的概念
    • 数、幾何学図形、行列など。
    • 特徴：正確な定義が存在。
  • 自然概念
    • 犬、机、家具、顧客、銀行講座など。
    • 特徴：定義しようとすると難しい。

古典的ビューではできないこと

  • 古典的オブジェクトモデルは、オブジェクトの主観性や状況依存性をうまく扱えていない。
  • 自然概念の記述には向かない。

概念とプログラミング

  • プログラミングは概念モデリングに関係するもの。
  • モデル化しようとしている自然概念は複雑である。
  • ソフトウェア再利用は、多くの状況下で使い物になる一般的な解決策を提供することを目標としている。
  • 概念の可変性をモデル化する適切な方法が必要。

p.34. [2章ドメイン工学] - [2.7.3 ドメインの相互関係]

ドメインの相互関係には、３種類ある。

  • AはBに含まれる（AはBのサブドメイン）
  • AはBを使う（BはAのサポートドメイン）
  • AはBに類似する（AはBの類似ドメイン）
kumamidori commented

復習メモ

この本で出てくる「パラダイム」という言葉の意味

扉表紙「新装版にあたって」の枠内に下記の記述があった。

ソフトウェアの設計、プログラミングには複数のパラダイム（考え方の枠組み）が存在する。
本書は、C++ 言語を例に、複数のパラダイムを組み合わせて
ソフトウェアの可変性と共通性を織り込むデザイン手法を明らかにする。

「考え方の枠組み」という意味だった。

※日本語での「パラダイム」の使われ方だと、たとえば「進化論によるパラダイム・シフト」のような、大きなトピック、抜本的なことに対して使われることが多いようなイメージがあって混乱したのだけれど、この本では違う意味。

  • p.265 に定義が明記されていた。

共通性とバリエーションの配置をその定義とする

  • 英英辞書の載っていた語源（show side by side、並べて示す。表のイメージ。）
ORIGIN late 15th cent.: via late Latin from Greek paradeigma, 
from paradeiknunai ‘show side by side’, 
from para- ‘beside’ + deiknunai ‘to show’.

問題と解決

#1 (comment)
について。

例：Webサービスの場合

  • エンドユーザとWebサービスのサービス運営者の二者がいる。
  • サービス運営者には、ユーザとエンジニアの中間に位置する役割のディレクターと、実装を行う役割のエンジニアがいる。
  • たとえば、「こういう現象があって困っている、改善してほしい」という曖昧な要求がエンドユーザに見えているとする（エンドユーザにとっての問題。技術の外側の視点）。
    これに対して、ディレクターとエンジニアで問題分析を行う。ディレクターが、要求を仕様ドラフトにまとめる。それを見て、エンジニアが、この仕様ではとても運用できそうにない、などと検討して要求定義をディレクターと一緒に練り直す。（エンジニアにとっての問題が定義される。これはエンドユーザから見れば解決の形）。

（ですが、「ドメイン」と後ろにくっつけると、あれ？ドメインと言って良いのだっけ、ととたんに難しく感じてしまいます・・・）

iteman commented

@kumamidori ドメインについては、第4章 p.91 により詳しい説明があります。 #4

kumamidori commented

ありがとうございます。

ドメインという用語は２つの意味で使われる（ref. 第4章 p.91 より改変を加えてメモ）

1. 「活動・関心・機能の範囲、領域」

DDD本で出てくるドメインは主にこちらの意味。例：ファイナンシャルトレーディング。
一般的に馴染みのある使われ方。

2. 「数学的に形式化された意味」

「定義域」

Wikipedia 「関数 (数学)」より：

y が x の関数であることの別の表現として、変数 y は変数 x に従属するとも言い、y を従属変数 (dependent variable) と言い表す。
独立変数がとりうる値の全体（変域）を、この関数の定義域 (domain) といい、独立変数が定義域のあらゆる値をとるときに、従属変数がとりうる値（変域）を、この関数の値域 (range) という。

ref. http://ja.wikipedia.org/wiki/%E9%96%A2%E6%95%B0_%28%E6%95%B0%E5%AD%A6%29

domain axis は X軸のことだった。
https://www.khanacademy.org/math/algebra/algebra-functions/domain_and_range/v/domain-and-range-from-graphs

余談（ドメインという言葉の使われ方）

「販売管理システムで学ぶモデリング講座」（渡辺幸三さん）p.12
で、DBテーブルを実装する際の基本的なルールとして、ドメイン制約とユニーク制約が挙げられている。

まず、それぞれの項目の「取り得る値（定義域、ドメインとも言う）」をあらかじめ決めておけば入力間違いを減らせる。例えば「都道府県」として入力可能な値のリストを定めておけば、（以下略）

iteman commented

ドメイン分析の初出

1.1 ソフトウェア開発の課題 ドメインとパラダイムの関係 (p.2)

本書で解決していく問いかけは、ドメインモデルとドメイン分析[Neighbors1980]に基づくものだ。

ドメイン分析（Domain Analysis）はJames M. NeighborsのSoftware Construction using Componentsによって提唱された。

iteman commented

ドメインとファミリ

1.3.5 ファミリと共通性分析 (p.11)

つまり、複数の関心事にまたがって存在するような共通事項は何かを知り、その中の要素ごとにどの詳細箇所が変わるのかを知って、その上で問題を理解することが必要だ[Shaw1984]。その関心の対象になる要素を集めて、ファミリ（family）と呼ぶ。

ドメインにはファミリが含まれていることが多い（しかし必然というわけではない）。ファミリはオブジェクト、関数、クラスといった「モノ」の集合である。その「モノ」は共通の特性を有しているという理由で、グルーピングすることができる。共通性分析は、ファミリを設計するために用いることができるアクティビティである。

1.3.5 ファミリと共通性分析 (p.12)

ドメインの中には、ファミリを形成しないようなものもある。そのようなドメインは、同一の関心や焦点を持つ領域が存在しない。…このようにファミリを形成しないものであっても、1個のドメインとして扱いたいと思う。それ自身焦点をあてるに値する分野であるという意味で、そのように扱うことにしよう。

ファミリは1つ以上の特性を持ち、特性ごとにドメインを有すると考えることができる。特性が1つしかないファミリであればそのファミリはドメインである、といえる。またドメイン階層を考慮すると、あらゆるファミリはドメインであるともいえそうだ。一方、ドメインにはファミリを形成しないものがあるため、ドメインはファミリであるとは必ずしもいえないだろう。

iteman commented

優れた抽象

1.3 設計、分析、ドメイン、ファミリ：用語定義 1.3.7 正確な抽象 (p.13)

「抽象的」（abstract）と「汎化」（general）は、「曖昧な」とか「不明瞭な」という意味ではない。正確さをもって記述されたものこそが、優れた抽象であると言える。

iteman commented

Phase Shift（位相差）

It helps avoid the "phase shift" that happens after data-flow diagrams in structured techniques, while avoiding the false hope that the solution structure will match the problem structure.
それは、ソリューションの構造が問題の構造にマッチするだろうという誤った見込みを避けると同時に、構造化技法におけるデータフロー図に従って発生する、「位相のずれ」を避けるのに役立つ。（拙訳）
-- Multi-Paradigm Design (Ph.D. Thesis) p.32 1 The Need for Multiple Paradigms 1.3 Design, Analysis, Domains, and Families: Term 1.3.2 Design

ここでいう_phase shift_は、問題の構造とソリューションの構造のずれということだと思います。「相転移」は_phase transition_なので誤訳かもしれません。

iteman commented

機構と方針の分離と情報隠蔽、そして共通性・可変性

1.9 共通性分析 1.9.1 ポリシーとメカニズム (p.27)

エンドユーザーにメカニズムを調べさせるべきではない。エンドユーザはビジネスドメインのポリシーに対応する設計部分だけを操作できるのが望ましい。これがParnasの説いた情報隠蔽の精神である。そして優れたシステムでは、共通性でメカニズムが、可変性でポリシーが表現されている。

これは、優れたシステムでは、（アプリケーションドメインAが使用するドメインXによって）共通性でメカニズムが、（ドメインXによって、アプリケーションドメインAの中で）可変性でポリシーが表現されている、ということだと考えます。

通常のシステム

  • (A) アプリケーションドメイン
    • ワークフロー（ポリシー＋メカニズムが含まれる）
    • ...

優れたシステム

  • (A) アプリケーションドメイン
    • ワークフロー（Xによりポリシーのみが含まれる）
    • ...
  • (X) ワークフローエンジン（アプリケーションドメインAからみたメカニズム）
    • ワークフロー（プロセスを含むドメインモデル）

優れたシステムでは、サブドメインとしてアプリケーションドメインのドメインツリーに含まれるのは、ポリシーのみであり、機構部分はアプリケーションドメインを構成しません。

例えば、ワークフロー中心アプリケーションのコアドメインはワークフロードメインといえますが、メカニズム（ワークフロードメインモデル＝メタモデル＋プロセス）はこのツリーに含まれません。