Domain-specific modeling

<h2 id="overview">Overview</h2>
<p>Domain-specific modeling often also includes the idea of <a href="/facts/Automatic_programming/zrrwX3CW">code generation</a>: <a href="/facts/Automation/3YlF2K5q">automating</a> the creation of executable <a href="/facts/Source_code/o9J6Jv23">source code</a> directly from the domain-specific language models. Being free from the manual creation and maintenance of source code means domain-specific language can significantly improve developer productivity.<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a> The reliability of automatic generation compared to manual coding will also reduce the number of defects in the resulting programs thus improving quality.
</p><p>Domain-specific language differs from earlier code generation attempts in the <a href="/facts/Computer-aided_software_engineering/SfKJ6bp4">CASE</a> tools of the 1980s or <a href="/facts/Unified_Modeling_Language/3tlNS0tH">UML</a> 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 domain-specific language and generators, it is more normal for domain-specific language 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.
</p><p>Having the modeling language and generator built by the organization that will use them allows a tight fit with their exact domain and in response to changes in the domain.
</p><p>Domain-specific languages can usually cover a range of abstraction levels for a particular domain. For example, a domain-specific modeling language for mobile phones could allow users to specify high-level abstractions for the <a href="/facts/User_interface/e9sPEWVD">user interface</a>, as well as lower-level abstractions for storing data such as phone numbers or settings. Likewise, a domain-specific modeling language for financial services could permit users to specify high-level abstractions for clients, as well as lower-level abstractions for implementing stock and bond trading algorithms.
</p>
<h2 id="topics">Topics</h2>
<h3>Defining domain-specific languages</h3>
<p>To define a language, one needs a language to write the definition in. The language of a model is often called a <a href="/facts/Metamodeling/lA2nkA6J">metamodel</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.
</p><p>Derived meta-metamodels include <a href="/facts/Entity%25E2%2580%2593relationship_model/U8A0mwYe">entity–relationship diagrams</a>, <a href="/facts/Formal_languages/crDTyP8q">formal languages</a>, <a href="/facts/Extended_Backus%25E2%2580%2593Naur_form/89KI2QTe">extended Backus–Naur form</a> (EBNF), <a href="/facts/Ontology_language_(computer_science)/yXLTb2z3">ontology languages</a>, <a href="/facts/XML_schema/uWam66Rj">XML schema</a>, and <a href="/facts/Meta-Object_Facility/7MDs1aA8">Meta-Object Facility</a> (MOF). The strengths of these languages tend to be in the familiarity and standardization of the original language.
</p><p>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,<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a><a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> GOPRR,<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> and GOPPRR, which focus on supporting things found in modeling languages with the minimum effort.
</p>
<h3>Tool support for domain-specific languages</h3>
<p>Many <a href="/facts/General-Purpose_Modeling/yuqPSP7t">General-Purpose Modeling</a> languages already have tool support available in the form of <a href="/facts/Computer-aided_software_engineering/SfKJ6bp4">CASE</a> tools. Domain-specific language 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 domain-specific language languages is built based on existing domain-specific language frameworks or through domain-specific language environments.
</p><p>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 <a href="/facts/Abstraction_(computer_science)/hAnxmJle">abstraction</a> when compared to a traditional CASE tool. 
</p><p>Using a domain-specific language environment can significantly lower the cost of obtaining tool support for a domain-specific 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.
</p><p>Most existing domain-specific language takes place with domain-specific language environments, either commercial such as <a href="/facts/MetaEdit%252B/UKdboCmQ">MetaEdit+</a> or <a href="/facts/Actifsource/kFMkc5ad">Actifsource</a>, open source such as <a href="/facts/Generic_Eclipse_Modeling_System/34MR4BPS">GEMS</a>, or academic such as <a href="/facts/Generic_Modeling_Environment/DxGqpAHR">GME</a>. The increasing popularity of domain-specific language has led to domain-specific language frameworks being added to existing IDEs, e.g. <a href="http://www.eclipse.org/modeling/">Eclipse Modeling Project</a> (EMP) with <a href="/facts/Eclipse_Modeling_Framework/Hd939zYh">EMF</a> and <a href="/facts/Graphical_Modeling_Framework/oSJSG7hR">GMF</a>, or in Microsoft's <a href="https://web.archive.org/web/20060423095834/http://msdn.microsoft.com/vstudio/dsltools/">DSL Tools</a> for <a href="/facts/Software_factory/oHg2IdL9">Software Factories</a>.
</p>
<h2 id="domain-specific-language-and-uml">Domain-specific language and UML</h2>
<p>The <a href="/facts/Unified_Modeling_Language/3tlNS0tH">Unified Modeling Language</a> (UML) is a <a href="/facts/General-purpose_modeling/yuqPSP7t">general-purpose modeling</a> language for software-intensive systems that is designed to support mostly <a href="/facts/Object-oriented_programming/TxNMEcao">object oriented programming</a>. Consequently, in contrast to domain-specific language languages, UML is used for a wide variety of purposes across a broad range of domains. The primitives offered by UML are those of object oriented programming, while domain-specific languages offer primitives whose <a href="/facts/Semantics/1L4WwLAP">semantics</a> are familiar to all practitioners in that domain. For example, in the domain of <a href="/facts/Automotive_engineering/dspDKGwP">automotive engineering</a>, there will be software models to represent the properties of an <a href="/facts/Anti-lock_braking_system/SmXvJn6G">anti-lock braking system</a>, or a <a href="/facts/Steering_wheel/yf12zWIC">steering wheel</a>, etc.
</p><p>UML includes a profile mechanism that allows it to be constrained and customized for specific domains and platforms. UML profiles use <a href="/facts/Stereotype_(UML)/bfsYGbvo">stereotypes</a>, stereotype attributes (known as tagged values before UML 2.0), 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 href="/facts/SysML/66N9ASg1">SysML</a>, a domain specific language for <a href="/facts/Systems_engineering/gFwRmkDp">systems engineering</a>.
</p><p>UML is a popular choice for various model-driven development approaches whereby technical artifacts such as source code, documentation, tests, and more are generated algorithmically from a domain model. For instance, application profiles of the legal document standard <a href="/facts/Akoma_Ntoso/xWbf5BGP">Akoma Ntoso</a> can be developed by representing legal concepts and ontologies in UML class objects.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a>
</p>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Computer-aided_software_engineering/SfKJ6bp4">Computer-aided software engineering</a></li>
<li><a href="/facts/Domain-driven_design/vJpcBKxu">Domain-driven design</a></li>
<li><a href="/facts/Domain-specific_language/n18H1foD">Domain-specific language</a></li>
<li><a href="/facts/Framework-specific_modeling_language/sP4AN0sR">Framework-specific modeling language</a></li>
<li><a href="/facts/General-purpose_modeling/yuqPSP7t">General-purpose modeling</a></li>
<li><a href="/facts/Domain-specific_multimodeling/6HRLg9Lx">Domain-specific multimodeling</a></li>
<li><a href="/facts/Model-driven_engineering/vznUHbSm">Model-driven engineering</a></li>
<li><a href="/facts/Model-driven_architecture/IY0daKp1">Model-driven architecture</a></li>
<li><a href="/facts/Software_factories/oHg2IdL9">Software factories</a></li>
<li><a href="/facts/Service-oriented_modeling/dKBECNxo">Discipline-Specific Modeling</a></li></ul>

<h2 id="external-links">External links</h2>
<ul><li><a href="http://www.itarchitect.co.uk/articles/display.asp?id=161">Domain-specific modeling for generative software development</a> <a href="https://web.archive.org/web/20100131064439/http://www.itarchitect.co.uk/articles/display.asp?id=161">Archived</a> 2010-01-31 at the <a href="/facts/Wayback_Machine/nmQ3a6JC">Wayback Machine</a>, Web-article by Martijn Iseger, 2010</li>
<li><a href="https://web.archive.org/web/20151118021655/http://www.pocomatic.com/docs/whitepapers/dsm/">Domain Specific Modeling in IoC frameworks</a> Web-article by Ke Jin, 2007</li>
<li><a href="http://www.methodsandtools.com/archive/archive.php?id=26">Domain-Specific Modeling for Full Code Generation from Methods & Tools</a> Web-article by Juha-Pekka Tolvanen, 2005</li>
<li><a href="http://www.methodsandtools.com/archive/archive.php?id=50">Creating a Domain-Specific Modeling Language for an Existing Framework</a> Web-article by Juha-Pekka Tolvanen, 2006</li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>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 [1] <a href="/wiki/ISBN_(identifier)" target="_blank">/wiki/ISBN_(identifier)</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>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] <a href="http://www.dsmforum.org/papers/CASE_Repository.html" target="_blank">http://www.dsmforum.org/papers/CASE_Repository.html</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>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] <a href="https://books.google.com/books?id=tsbNn6auhm8C&pg=PA224" target="_blank">https://books.google.com/books?id=tsbNn6auhm8C&pg=PA224</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
<li id="fn:4"><p>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 Ph.D. thesis as 3metools.pdf) <a href="http://www.metacase.com/stevek.html" target="_blank">http://www.metacase.com/stevek.html</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li>
<li id="fn:5"><p>Flatt, Amelie; Langner, Arne; Leps, Olof (2022). Model-Driven Development of Akoma Ntoso Application Profiles - A Conceptual Framework for Model-Based Generation of XML Subschemas (1st ed.). Heidelberg: Sprinter Nature. ISBN 978-3-031-14131-7. <a href="978-3-031-14131-7" target="_blank">978-3-031-14131-7</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li>
</ol>

Domain-specific modeling open-in-new

Domain-specific modeling