Misplaced Pages

Domain-specific modeling: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 21:48, 2 August 2006 editSteven Kelly (talk | contribs)176 edits Added more context to intro← Previous edit Revision as of 22:12, 2 August 2006 edit undoSteven Kelly (talk | contribs)176 edits Expanded "Formal languages and libraries" to "Defining DSM Languages" with more info and citationsNext edit →
Line 25: Line 25:
However, the UML includes a profile mechanism that allows it to be constrained and customized for specific domains and platforms. UML profiles use ], tagged values and constraints to restrict and extend the scope of UML to a particular domain. Perhaps the best known example of customizing UML for a specific domain is ], a DSM language for ]. However, the UML includes a profile mechanism that allows it to be constrained and customized for specific domains and platforms. UML profiles use ], tagged values and constraints to restrict and extend the scope of UML to a particular domain. Perhaps the best known example of customizing UML for a specific domain is ], a DSM language for ].


==Defining DSM Languages ==
==Formal languages and libraries ==
To define a language, one needs a language to write the definition in. The language of a model is often called a ], hence the language for defining a modeling language is a meta-metamodel. Meta-metamodels can be divided into two groups: those that are derived from or customizations of existing languages, and those that have been developed specifically as meta-metamodels.
] provide a rigorous basis for defining DSM languages. DSM languages can also be defined using ], ], ], MOF, etc. Although no large library of DSM languages is yet available, a large library of DSLs is available in the .

Derived meta-metamodels include ], ], ], ], ], and ]. The strengths of these languages tend to be in the familiarity and standardization of the original language.

The ethos of Domain-Specific Modeling favors the creation of a new language for a specific task, and so there are unsurprisingly new languages designed as meta-metamodels. The most widely-used family of such languages is that of OPRR<ref name="oprrWelke">R.J. Welke. The CASE Repository: More than another database application. In W.W. Cotterman and J.A. Senn, editors, Proceedings of 1988 INTEC Symposium Systems Analysis and Design: A Research Strategy, Atlanta, Georgia, 1988. Georgia State University.
</ref><ref name="oprrSmolander">Smolander, K., (1992) OPRR - A Model for Modeling Systems Development Methods. In: Next Generation CASE Tools (eds. K. Lyytinen, V.-P. Tahvanainen) IOS Press, Amsterdam, Netherlands, pp. 224-239.</ref>, GOPRR<ref name="GOPRR">Kelly, S., Lyytinen, K., and Rossi, M., "MetaEdit+: A Fully Configurable Multi-User and Multi-Tool CASE Environment," Proceedings of CAiSE'96, 8th Intl. Conference on Advanced Information Systems Engineering, Lecture Notes in Computer Science 1080, Springer-Verlag, pp. 1-21, 1996.</ref>, and GOPPRR, which focus on supporting things found in modeling languages with the minimum effort. Another meta-metamodel is , which focuses on simple definition with the common subset of existing meta-metamodels' capabilities. A large library of DSM languages in ATL is available in the .


==See also== ==See also==

Revision as of 22:12, 2 August 2006

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.
Find sources: "Domain-specific modeling" – news · newspapers · books · scholar · JSTOR (Learn how and when to remove this message)

Domain-Specific Modeling (DSM) is the systematic use of a graphical Domain Specific Language (DSL) to represent the various facets of a system. DSM languages tend to support higher-level abstractions than General-Purpose Modeling languages, meaning that they require less effort and fewer low-level details to specify a given system.

DSM often also includes the idea of code generation: automating the creation of executable source code directly from the DSM models. Being free from the manual creation and maintenance of source code means DSM can significantly improve developer productivity. The reliability of automatic generation compared to manual coding will also reduce the number of defects in the resulting programs, thus improving quality.

DSM differs from earlier code generation attempts in the CASE tools of the 1980s or UML tools of the 1990s. In both of these, the code generators and modeling languages were built by tool vendors. Whilst it is possible for a tool vendor to create a DSM language and generators, it is more normal for DSM to take place within one organization. One or a few expert developers will create the modeling language and generators, and the rest of the developers will use them.

Having the modeling language and generator built by the organization that will use them allows a tight fit with their exact domain and needs. It also reduces the time needed for developers to learn the modeling language, since it can use familiar terms and concepts. Finally, since only one organizations' requirements need be taken into account, it is easier for the modeling language to evolve in response to changes in the domain.

Tool support for DSM languages

Many General-Purpose Modeling languages already have tool support available in the form of CASE tools. DSM languages tend to have too small a market size to support the construction of a bespoke CASE tool from scratch. Instead, most tool support for DSM languages is built based on existing DSM frameworks or through DSM environments.

A DSM 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 DSM environment, or less commonly be produced as a separate stand-alone program. In the more common case, the DSM environment supports an additional layer of abstraction when compared to a traditional CASE tool.

Using a DSM environment can significantly lower the cost of obtaining tool support for a DSM language, since a well-designed DSM 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 DSM environment provides a modeling tool tailored for the target domain.

Most existing DSM takes place with DSM environments, either commercial such as MetaEdit+ or academic such as GME. The increasing popularity of DSM has led to DSM frameworks being added to existing IDEs, for instance in the Eclipse Modeling Project (EMP) and Microsoft's DSL Tools for Software Factories.

DSM examples

DSM languages can usually cover a range of abstraction levels for a particular domain. For example, a DSM language for mobile phones should allow users to specify high-level abstractions for the user interface, as well as lower-level abstractions for the implementation of logic gates. Likewise, a DSM language for financial services should permit users to specify high-level abstractions for clients, as well as lower-level abstractions for implementing stock and bond trading algorithms.

Comparison between DSM languages and UML

The Unified Modeling Language (UML) is a general-purpose modeling language for software-intensive systems that is designed to support mostly object oriented programming. Consequently, in contrast to DSM languages, UML is used for a wide variety of purposes across a broad range of domains.

However, the UML includes a profile mechanism that allows it to be constrained and customized for specific domains and platforms. UML profiles use stereotypes, tagged values and constraints to restrict and extend the scope of UML to a particular domain. Perhaps the best known example of customizing UML for a specific domain is SysML, a DSM language for systems engineering.

Defining DSM Languages

To define a language, one needs a language to write the definition in. The language of a model is often called a metamodel, hence the language for defining a modeling language is a meta-metamodel. Meta-metamodels can be divided into two groups: those that are derived from or customizations of existing languages, and those that have been developed specifically as meta-metamodels.

Derived meta-metamodels include Entity Relationship Diagrams, Formal languages, EBNF, Ontology languages, XML Schema, and MOF. The strengths of these languages tend to be in the familiarity and standardization of the original language.

The ethos of Domain-Specific Modeling favors the creation of a new language for a specific task, and so there are unsurprisingly new languages designed as meta-metamodels. The most widely-used family of such languages is that of OPRR, GOPRR, and GOPPRR, which focus on supporting things found in modeling languages with the minimum effort. Another meta-metamodel is ATL, which focuses on simple definition with the common subset of existing meta-metamodels' capabilities. A large library of DSM languages in ATL is available in the Eclipse metamodel open source library.

See also

External links

  1. R.J. Welke. The CASE Repository: More than another database application. In W.W. Cotterman and J.A. Senn, editors, Proceedings of 1988 INTEC Symposium Systems Analysis and Design: A Research Strategy, Atlanta, Georgia, 1988. Georgia State University.
  2. Smolander, K., (1992) OPRR - A Model for Modeling Systems Development Methods. In: Next Generation CASE Tools (eds. K. Lyytinen, V.-P. Tahvanainen) IOS Press, Amsterdam, Netherlands, pp. 224-239.
  3. Kelly, S., Lyytinen, K., and Rossi, M., "MetaEdit+: A Fully Configurable Multi-User and Multi-Tool CASE Environment," Proceedings of CAiSE'96, 8th Intl. Conference on Advanced Information Systems Engineering, Lecture Notes in Computer Science 1080, Springer-Verlag, pp. 1-21, 1996.
Categories: