だから私の質問は、誰かがすでにこの作業を行い、与えられたプログラミング問題のセットに対して適切なメタファーまたはヒューリスティックを推定するための構造化された方法を見つけましたか（または半分見つけましたか）？
私はあなたの質問に対する答えの始まりを持っているかもしれません。これは、複数レベルの抽象化で構成されています。複数のドメインの説明。そして、特定の方法での「モデリング」手法の適用-モデリングで通常行われるものとはかなり異なります。全体的なアプローチは、あなたが求めているものだと私は信じています。それは、操作されてから実際の結果に変換される比喩を提供します。これは、公開されている多くのアプローチに基づいており、これらのアプローチと方法のいくつかに大きく依存しています。
以下は、これらの警告の対象となります。
- これは非常に「進行中の作業」です。
- 私は「アーキテクチャの宇宙飛行士」であるという蔑称的なコメントを受け取っており、その結果、実際のシステム開発の本質に触れていないという意味合いを持っています。これが、これが進行中の理由の1つです。私の現在のプロジェクトは、この概念を検証し、実際の有用性があることを実証するように設計されています。これを行うには、私のアプローチを使用して、通常は個々の開発者の手の届かない、十分な規模と複雑さのシステムを開発する必要があります。私は、このような概念実証の開発の途中にすぎません。
- 私が説明する概念は、複雑な問題ドメイン（ソナー接触追跡システム、およびチップ設計システム）の考慮から導き出されていますが、私の例は、より単純なドメイン（基本的には、ルールシステムによって制約される情報システム）に関連しています。ルールベースには、ドメインに関するルールだけでなく、他のルールの適用可能性に関するルールも含まれます。
- あなたの質問から、私はあなたとは反対の方向からそれに来ているのではないかと思います。あなたは、与えられたプログラミング問題のセットに対して適切なメタファーまたはヒューリスティックを推定する方法を求めています。これは、プログラミングの問題から始めることを意味します。私の推進力は分析側からでした。実際のシステムとして実装できるように、提案されたシステムを説明する方法を見つけて定式化しようとしています。
- 「モデル」と「モデリング」という言葉を使うときは、以下に説明するモデリングを意味します。この説明は、これらの用語の一般的な使用法とは多少異なります。
このアプローチに必要な3つの主要な構成要素は次のとおりです。
複数のドメイン
私のドメインの定義は、通常採用されているものよりも広いです。
ドメインは、ドメインに特徴的なルールとポリシーに従って動作するオブジェクトと現象の別個のセットが存在する、別個の現実、仮想、または抽象的な世界です。問題分析では、ドメインは複雑なシステムを開発する際の考慮事項として役立ちます。
この定義では、システム内で検討する複数のドメインがあります。多くの場合、開発者がドメインを指す場合、それらは問題（またはアプリケーション）ドメイン（以下、Pと呼びます）を意味します。ただし、このアプローチの場合、システムのあらゆる側面、またはシステム開発がモデリングの潜在的な対象になります。これには、システムアーキテクチャ（A）が含まれます。システム生産アーティファクト（コード、スクリプトの作成、データベーススキーマなど）（C）; DBA機能; など。Pに近づくためにメタファーを介して、いくつかのそのようなドメインの開発が必要です-メタファーとメタファーから実世界のモデルへの変換、または開発されたシステムでの実世界のコード実現に関連します。複数のそのようなモデルが開発されるとき、それらはすべて同じ程度の範囲と精度で開発されます。
複数レベルの抽象化
問題とシステムを説明するために、1つのモデルはPだけでなく、適切なより高いレベルの抽象化もモデル化します。したがって、Pを記述するために選択されたメタファーがモデル化されます（M）。同様の方法で、A（F）の形式がモデル化され、必要に応じて、A（R ）を使用したPとCの間の変換プロセスがモデル化されます。したがって、問題のドメインを抽象化します。抽象化などを抽象化します。
複数のモデルの適用は色分解に似ています-それらは互いに重なり合っており、システムはすべてのレイヤーのすべての説明（「全体像」）を満たす必要があります。繰り返しますが、これは、元のモデルを作成してさまざまな制約を取り入れることにより、このような複数の要件を満たす傾向がある一般的なモデリング方法とは異なります。これは、すべてのアーキテクチャドメインがすべての問題のあるドメインのすべての要素に効果的に適用される場合に特に影響します。
モデリング
モデリングとは、次の点でモデリングに対する通常のアプローチとは異なります。
- モデルの主題は、ドメインごとに異なる可能性が高いです。これは、初期モデルが他のモデルの精緻化であるモデリングとは対照的です。実際、モデルの妥当性の1つのテストは、それがDRY原則の極端なバージョンを表すことです。何かが複数の場所で定義されている場合、それはモデルの欠陥を示します。これは検討中のすべてのドメインに及ぶため、システムの構築方法は1か所でのみ定義されます。
- ドメインは、一度モデル化されると、かなり静的になる可能性があります。抽象化のレベルが高いほど、変更される可能性は低くなります。
- モデルの範囲は、従来開発されたものよりもはるかに狭く、はるかに深い可能性があります。特定のドメイン内のオブジェクトは、従来のモデリングよりも少ない可能性があります。ただし、これらのモデルは完全である必要があり、モデルの完全性を示すテストがあります（明らかに、システムの説明が完全であることを証明することはできません）。
- Pは、 Mによって定義される用語で記述されます。モデルは、ダイアグラム、OO表現、数式、またはドメインMに適切なものとして表現できます。
次の例は、私の概念実証プロジェクトから派生したもので、上記の私の説明にいくつかの肉体を与える可能性があります。ドメインモデルの候補コンテンツとともに、いくつかのドメインをリストします。
- P [車両、ユニット、動き、消耗、速度...]
- P1 [ルール、適用性、状態、優先順位...]（補助的な問題ドメイン）
- M [オブジェクトタイプ、属性、関係、ドメイン...]
- A [イベント、テーブル、列、データベースドメイン、クラス...]
- F [永続メカニズム、処理、.....]
- C [データベーススキーマ、ソースコード、SQLスクリプト、ビルドスクリプト、...]
- R [形式、変換、マッピング...]
このアプローチには少なくとも1つの大きな欠点があります。モデルの開発に関連する作業は、実際の成果物が作成されておらず、非生産的であると管理者が見なす可能性があります。
この回答の出典は多種多様ですが、以下の作品に大きく依存しています。
- 構造化プログラミングに関するマイケルジャクソン。システム分析; および問題のドメインの説明。
- 精緻化ではなく変換によるシステム開発のShlaer-Mellor法。
- ケネディ-カーターメソッドコンサルタント。