Domain-specific modeling: Difference between revisions

Revision as of 09:53, 18 September 2012

Revision as of 13:25, 12 October 2012

Line 2:

== Overview ==

Domain-specific modeling (DSM) often also includes the idea of [[Automatic programming|code generation]]: [[Automation|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.<ref name="dsmKelly">Kelly, S. and Tolvanen, J.-P., (2008) ''Domain-Specific Modeling: Enabling Full Code Generation,'' John Wiley & Sons, New Jersey. ISBN 978-0-470-03666-2 [http://dsmbook.com]</ref>. 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 [[Computer-aided software engineering|CASE]] tools of the 1980s or [[Unified Modeling Language|UML]] tools of the 1990s. In both of these, the code generators and modeling languages were built by tool vendors. While it is possible for a tool vendor to create a DSM language and generators, it is more normal for DSM to occur within one organization. One or a few expert developers creates the modeling language and generators, and the rest of the developers use them.

Line 11:

== Domain-specific modeling topics ==

=== 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 [[metamodeling|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.

Line 16 ⟶ 17:

Derived meta-metamodels include [[Entity-relationship model|Entity Relationship Diagrams]], [[Formal languages]], [[Extended Backus-Naur form|EBNF]], [[Ontology language (computer science)|Ontology languages]], [[XML Schema]], and [[Meta-Object Facility|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,<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. [http://www.dsmforum.org/papers/CASE_Repository.html]

</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.[http://books.google.com/books?id=tsbNn6auhm8C&pg=PA224]</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. (in [http://www.metacase.com/stevek.html Ph.D.] thesis as 3metools.pdf)</ref>, and GOPPRR, which focus on supporting things found in modeling languages with the minimum effort.

=== Tool support for DSM languages ===

Line 34 ⟶ 35:

==See also==

* [[Computer-aided software engineering]]

* [[Domain-driven design]]

* [[Domain-specific language]]

* [[Framework-specific modeling language]]

* [[General-purpose modeling]]

* [[Domain-specific multimodeling]]

* [[Model-driven engineering]]

* [[Model-driven architecture]]

* [[Software factories]]

* [[Service-oriented modeling#Discipline-specific modeling|Discipline-Specific Modeling]]