Modeling Paradigms (p116) †
要約 †
- p116 第4段落
- MODEL-DRIVEN DESIGNは特定のモデリングパラダイムに調和する実装技術を必要とする。
- 現在はオブジェクト指向が優位。
Why the Object Paradigm Predominates (p116) †
- p116 第5段落
- チームがオブジェクトパラダイムを選ぶ理由の多くが技術的な理由ではなく、オブジェクトの簡単さと洗練のバランスがよいからです。
- p116 第6段落
- モデリングパラダイムがとても難しかったら、習得する開発者は少なく(そして誤って使用し)、技術者以外の人は基本を把握できないので、UBIQUITOUS LANGUAGEは失われるでしょう。
- p117 第2段落
- オブジェクトモデルの概念は簡単ですが、重要なドメイン知識を得るのに十分であると判明しました。また、モデリングツールが最初からサポートされました。
- p117 第3段落
- 今日、オブジェクトパラダイムは、成熟しているインフラストラクチャとツールサポートがあり、広く採用されている。
- p117 第4段落
- 同じく重要なのは、開発者コミュニティーとデザイン文化自体が成熟していることです。
- p117 第5段落
- オブジェクトは既にプロジェクト作業にかかわる何千人もの開発者、プロジェクト・マネージャ、および他のすべての専門家の共同体に理解されています。
- p118 第1段落
- 1990年代初期に最先端技術(オブジェクト指向データベースなどを含む)を使用した大規模プロジェクトがあり、はまりそうになった。
- p118 第2段落
- エキスパートを外部から雇い、3つの原因を突き止めた。
- データベースが、必要なだけスケールしなかった。
- 細かい粒度のオブジェクトの格納は、考えていたよりはるかに高コストだった。
- オブジェクト・モデルには相互依存性のもつれがあるものがあり、比較的少ない数の並列なトランザクションで問題が起きた。
- p118 第3段落
- エキスパートの助けで、インフラストラクチャを改善した。
- 私たちは、モデルのクモの巣のような関連を制限する重要性について認識を深めました。そして、密接に相互に関係づいた集合を疎結合にすると言う、より良いモデルを考えた。
- p118 第4段落
- 数ヶ月はこの復旧で失われたが、このプロジェクトは縮小され、かなり保守的になった。
- p119 第1段落
- 10年後、オブジェクト指向技術は比較的成熟しました。
- ツールは複数のベンダーやオープンソース・プロジェクトから提供され、これらの多くは十分広く使用されていし、それらを解説する本等がある。また、これらをすでに理解している人々がいる。
- p119 第2段落
- 他の興味深いモデルパラダイムには、この成熟がありません。
- p119 第3段落
- これは当分、MODEL-DRIVEN DESIGNを試みるほとんどのプロジェクトがそれらのシステムのコアとしてオブジェクト指向技術を使用するために賢明である理由です。
- p119 第4段落
- オブジェクト・モデルは多くの実用的なソフトウェアの問題を扱いますが、カプセル化された振舞いの離散的なパケットとしてモデル化するために適切ではないドメインがあります。
- 例えば、非常に数学的である、またはグローバルな論理的な推論で支配されるドメインはオブジェクト指向パラダイムによく収まりません。
Nonobjects in an Object World (p119) †
- p119 第5段落
- ドメインモデルはオブジェクト・モデルである必要はありません。
結果的に、モデリングスタイルをサポートするツールで効果的に実装できるパラダイムに従うモデルになる。
- p120 第2段落
- 優位なモデルパラダイムがプロジェクトにあっても、他のパラダイムではるかに言い表しやすいドメインの一部が必ずあるでしょう。相互依存が小さいとき、もう片方のパラダイムのサブシステムをカプセル化できます。
- p120 第3段落
- パラダイムを混合すると、開発者は最もよく合うスタイルで特定の概念をモデル化できます。
- しかし、パラダイム間を補うわかり易いモデルを作るのは困難で、サポートツールを共存させるのは複雑です。
- パラダイムの混合が必要でも、開発者がわかり易いモデルをソフトウェアで構築することができないならMODEL-DRIVEN DESIGNは完全に消えてしまいます。
Sticking with MODEL-DRIVEN DESIGN When Mixing Paradigms (p120) †
- p120 第4段落
- 技術の例がオブジェクト指向アプリケーション開発に時々混入するので、ルールエンジンが役立つだろう。
- ルールエンジン技術は、オブジェクトパラダイムにそのルールパラダイムを上手く混ぜることができるため。
- p121 第2段落
- しかし、いつもルールエンジンから期待するものを得るというわけではありません。
- ある製品は、2つの実装環境で稼働するモデル概念の関連性を示すことができるビューをシームレスに見ることができない。
- p121 第3段落
- ルールで動いている間にモデルの表現を考え続けているのは重要です。
- チームは両方の実装パラダイムで働くことができる単独のモデルを見つけなければなりません。
- p121 第4段落
- シームレスな環境がなければ、開発者が全体のデザインを結合するための明確で、基本的な概念を構成するやりかたを導き出すのは破綻する。
- p121 第5段落
- 結合するための最も効果的なツールは、全体の異種のモデルの基礎となる強健なUBIQUITOUS LANGUAGEです。
- 一貫して2つの環境における名前を適用して、それらの名前をUBIQUITOUS LANGUAGEに使用するのは、ギャップを埋める助けになる。
- p121 第6段落
- このセクションの目標はMODEL-DRIVEN DESIGNをあきらめる必要はなく、それを保つための努力に価値があるのを示すことです。
- p121 第7段落
- MODEL-DRIVEN DESIGNはオブジェクト指向である必要はありませんが、オブジェクト、ルール、またはワークフローというようなモデル構造物の表現の実装を持っているのに依存します。
- 利用可能なツールがその表現に乏しいのなら、ツールの選択を再考してください。
- p122 第1段落
- オブジェクト指向システム中に非オブジェクト要素を混入させるには、主に4つの規則があります。
- 実装パラダイムと戦わない。別の方法でドメインについて考える。パラダイムに合うモデル概念を見つけなさい。
- UBIQUITOUS LANGUAGEに頼りなさい。ツールの間にどんな緊密な関係がなくても、言語を一貫して使用することは、個々のデザインがばらばらになることを防ぐことができる。
- UMLにこだわるな。時々、UML図などのツールに対する執着は、容易に描けるようにするために、モデルを歪めることがある。
- 疑い深くなってください。ツールは本当に自分の役割を十分に果たしていますか?
- p122 第2段落
- パラダイムの混合に苦しむ前に、優位なパラダイムを使い尽くすべきです。オブジェクト技術の使用は9章で説明。
- p122 第3段落
- リレーショナルパラダイムはパラダイム混合の特別なケースです。→6章で説明。
担当者のつぶやき †
みんなの突っ込み †
