前のトピックへのコメントで、この記事は乾燥していて、学術的で、噛み心地が悪いと多くの人が言われました。 とにかく-なぜDSLが必要なのか、それはどのような問題を解決できるのか この点で、DSLが占める場所とその便利な使用方法を検討するために、主題分野全体に関する知識を提示する可能性の簡単な概要を準備しました。
現在まで、主題分野に関する知識を表すさまざまな方法があります。 それらの中には：
-テキスト表現。
-グラフィック表示。
-テーブルビュー。
-数式表現。
主題分野に関する知識を表す方法の分類を図1.1に示します。
テキスト表現は、主題領域に関する知識の表現の最も一般的なタイプです。 サブジェクト領域に関する知識のテキスト表現の方法は、図1.2で強調されています。
図1.1-サブジェクト領域に関する知識を表現する方法
図1.2-対象分野に関する知識のテキスト表現の方法
グラフィカルな表現は人にとって最も有益なものであり、サブジェクト領域の構造要素、サブジェクト領域で発生するプロセスとそれらの間の関係を見ることができます。 サブジェクト領域に関する知識のグラフィック表示の方法を図1.3に示します。
図1.3-サブジェクトエリアに関する知識を表すグラフィカルな方法
テーブルビューは、コンピューターでの後続の処理に便利です。 上記の中で最も形式化されたもの。 ほとんどの場合、行と列（グラフ）で構成される長方形のテーブルが使用されます。 グラフの見出しは通常、テーブルの一番上の行にあります。 表1.1は、数日間の天気情報を含む長方形の表の例です。
表1.1-タイプ "Object-property"のテーブルの例
日付
|
降水量
|
温度（度C）
|
圧力（mmHg）
|
湿度
（パーセント）
|
03/15/97
| 雪
| -3.5
| 746
| 67
|
97年3月16日
| 降水なし
| 0
| 750
| 62
|
03/17/97
| 霧
| 1,0
| 740
| 100
|
03/18/97
| 雨
| 3.4
| 745
| 96
|
03/19/97
| 降水なし
| 5.2
| 760
| 87
|
このテーブルは、「オブジェクトプロパティ」タイプのテーブルの例です。
そのようなテーブルの各行は、特定のオブジェクトを参照します。 上記の例では、これは日付を指定した特定の日です。 通常、最初の列はこのオブジェクトを識別し、後続のグラフはオブジェクトのプロパティ（特性）を反映します。
別のタイプのテーブルは、オブジェクト間と呼ばれます。
このようなテーブルは、さまざまなオブジェクト間の関係を反映しています。 例は、さまざまな科目の生徒のパフォーマンスチャートです-表1.2
表1.2-さまざまな科目の学生の成績
学生
| ロシア語
| 代数
| 化学
| 物理学
| 物語
| ミュージック
|
アリキン・ピーター
| 4
| 5
| 5
| 4
| 4
| 5
|
ボトフ・イヴァン
| 3
| 3
| 3
| 3
| 3
| 4
|
ヴォルコフイリヤ
| 5
| 5
| 5
| 5
| 5
| 5
|
ガルキナ・ニーナ
| 4
| 4
| 5
| 2
| 4
| 4
|
この表は、2種類のオブジェクト間の関係を反映しています：学生と研究対象。 評価は、このような関係の特徴です。 このようなテーブルでは、行と列を交換できます。行ではオブジェクト、列では学生です。
正式な表現は、主題領域の数学モデルを作成するために最もよく使用され、主題領域に関する知識を表現するための以前に提示された方法とは異なります。
知覚にとって最も自然で便利なものとして、テキストおよびグラフィック表現をより詳細に考えてみましょう。
テキスト表示は、構造化された説明と非構造化された説明に分けられます。 非構造化説明はプレーンテキストです。 構造化は、実行可能ファイル（何らかの方法でコンピューターで実行）と非実行可能ファイルに分けられます。 履行されない参照条件には、技術的なタスク（サブジェクトエリアに関する一般情報を含む構造化されたゲストドキュメント）とビジネス要件のセット（サブジェクトエリアに関する拡張情報を含む構造化されたドキュメント）が含まれます。
サブジェクト領域に関する知識を表現する実行可能なテキスト形式の方法は、プログラマーの観点からは、すでに方法よりも多くのテクノロジーです。 ただし、ドメイン専門家がこの分類で提示するドメインDSL、XML、およびドメインオントロジーを見ると、これらの方法は他の多くの方法よりもドメインで行われるプロセスを記述するための自然言語に非常に近いものです。 さらに、構造化により、サブジェクト領域に関する知識を表すこれらの方法は、プログラムコードでの実行に便利です。
グラフィック表示は、構造化と非構造化に分けることもできます。 非構造化表現には、対象領域を視覚的によく説明する図面、グラフ、および写真が含まれますが、それらをさらに処理するための形式化は十分ではありません。 構造化は、次に、ダイアグラムの形式とオブジェクトモデルの形式の表現に分割できます。
チャートは、UML、SADT、データフロー、および関連マップ（マインドマップ）で表されます。 主題領域を記述するこの方法は常に動的に開発されており、新しい仕様とその構築の機会が現れています。 これは非常に形式化されており、現在、ソフトウェアシステムを設計するための基礎となっています。
オブジェクトモデルには、サブジェクト領域を説明するグラフとグラフィック言語が含まれます。 後者は、サブジェクトエリアの自然な説明に最も近く、特定のサブジェクトエリアに固有の用語でサブジェクトエリアのアイデアを表現できます。
分類からわかるように、対象分野の専門家であるがまったくプログラマーではないユーザーが操作できる知識表現の構造化モデルには、次のものがあります。
1.参照規約
2.一連のビジネス機能
3. DSL
すべて。 他のモデルを作成するには、専門家のサブジェクトエリアに属さない追加の知識セットが必要です。 そして、参照用語と一連のビジネス機能が実行可能なモデルではないことを今の根拠としてとると、現時点では、プログラミングのトレーニングを受けていない専門家が主題領域に関する知識を記述する唯一の方法がDSLであることがわかります。 そして、これは、最終製品のプログラムコードへの後続の変換のための唯一の方法であり、プログラマーによるマイナーなdopilivaniyaが必要です。
別の見方をしている場合、あなたは考えに同意しないか、この問題についてあなたの意見を述べたいと思います-コメントを求めてください、私は建設的な批判とケースに関する有益な議論が好きです。