1

James Neighbors さんは、ソフトウェアの再利用のアプローチとして DSL について言及しましたが、その理由については説明しませんでした。彼は、DSL は再利用可能なコンポーネントのライブラリよりも優れたアプローチになり得るとだけ述べています。ソフトウェアの再利用で DSL を使用すると、どのような利点が得られるのでしょうか?

また、Mernik による DSL の開発時期と方法に関する論文で、彼は DSL はアプリケーション ジェネレーターへの入力言語として機能し、アプリケーション ジェネレーターは Krueger によって議論されたソフトウェアを再利用する 1 つのアプローチであると述べました。

誰か関係を教えてもらえますか、または DSL がソフトウェアの再利用に対する効果的なアプローチになる方法を教えてください。助けてくれてどうもありがとう

4

1 に答える 1

2

James は、DSL がソフトウェアの再利用に適したアプローチである理由を非常に明確にしました (彼と私は UC Irvine に一緒にいました)。

  • 問題領域で関心のある概念を捉える
  • 彼らは、そのドメインで機能するコミュニティになじみのある表記法を使用します
  • それらは、仕様/ソリューションコンポーネントの構成規則を定義して回答を生成し、DSLフラグメントが提供されたときにサニティをチェックできるようにします

彼の Draco システムはこれらすべての概念を実装し、DSL 記述を受け入れ、続いて DSL インスタンスを実装しました。Draco は実装知識の断片(「改良規則」) を適用して低レベル コードにコンパイルし、高レベル DSL から低レベル DSL にマッピングしました。低レベルの DSL で最適化を行い、最終的に従来のコンパイラ (LISP、C、Ada、COBOL など) に与えるのに十分な低レベルの抽象化で DSL に到達するまで繰り返します。

これは彼の改良と最適化のパラダイムであり、一連の DSL を階層の層を通して低レベルのコードに改良することを可能にします。したがって、階層化されたドメインの構成可能性が得られ、非常に高いレベルの抽象化で作業できます。

したがって、問題の仕様と実装に関する知識を取得し、それを適用してコードを取得します。抽象化の再利用、仕様の再利用、実装の再利用、うわー…「コード」の再利用だけでなく、80 年代初頭のように、多くの人々がまだ行き詰まっているように見えます。コードの再利用は非常に困難です。

これは、「コンポーネントとしてのサブルーチン」と比較して、非常に優れたパラダイムです (現在、これを意味する派手な用語は「内部 DSL」であり、ドメイン表記、仕様チェック、実装、および構成要素が欠落しています)。

彼の博士論文 (彼の他の多くの論文とともにここからアクセス可能) を注意深く読むべきだと思います。予想以上に親しみやすいです。難解な数学でいっぱいではありません。彼の種類の DSL を設計する方法の概念とデモンストレーションでいっぱいです。

于 2012-08-04T20:03:29.080 に答える