Content deleted Content added
m →Tool support for ___domain-specific language languages: Typo fixing, replaced: language language → language using AWB |
Undo self. I didn't understand the sentence well enough. |
||
Line 27:
A ___domain-specific language environment may be thought of as a metamodeling tool, i.e., a modeling tool used to define a modeling tool or CASE tool. The resulting tool may either work within the ___domain-specific language environment, or less commonly be produced as a separate stand-alone program. In the more common case, the ___domain-specific language environment supports an additional layer of [[Abstraction (computer science)|abstraction]] when compared to a traditional CASE tool.
Using a ___domain-specific language environment can significantly lower the cost of obtaining tool support for a ___domain-specific language language, since a well-designed ___domain-specific language environment will automate the creation of program parts that are costly to build from scratch, such as ___domain-specific editors, browsers and components. The ___domain expert only needs to specify the ___domain specific constructs and rules, and the ___domain-specific language environment provides a modeling tool tailored for the target ___domain.
Most existing ___domain-specific language takes place with ___domain-specific language environments, either commercial such as [[MetaEdit+]] or [[Actifsource]], open source such as [[Generic Eclipse Modeling System|GEMS]], or academic such as [[Generic Modeling Environment|GME]]. The increasing popularity of ___domain-specific language has led to ___domain-specific language frameworks being added to existing IDEs, e.g. [http://www.eclipse.org/modeling/ Eclipse Modeling Project] (EMP) with [[Eclipse Modeling Framework|EMF]] and [[Graphical Modeling Framework|GMF]], or in Microsoft's [http://msdn.microsoft.com/vstudio/DSLTools/ DSL Tools] for [[Software factory|Software Factories]].
| |||