Domain-specific modeling: Difference between revisions

Revision as of 08:40, 22 May 2021

Latest revision as of 21:42, 24 June 2025

(6 intermediate revisions by 6 users not shown)

Line 1:

{{Short description|Software engineering methodology}}

'''Domain-specific modeling''' ('''DSM''') is a [[software engineering]] [[Methodology (software engineering)|methodology]] for designing and developing systems, such as [[computer software]]. It involves systematic use of a [[___domain-specific language]] to represent the various facets of a system.

Line 10 ⟶ 11:

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.

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 [[user interface]], 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. Domain-specific modeling is also helpful to reason about low-level software artifacts.<ref>{{Citation|last1=Eichberg|first1=Michael|title=Model-Driven Engineering of Machine Executable Code|date=2010|url=https://hal.archives-ouvertes.fr/hal-01575664/file/Model-driven-Engineering-of-Machine-Executable-Code.pdf|work=Modelling Foundations and Applications|volume=6138|pages=104–115|doi=10.1007/978-3-642-13595-8_10|access-date=2019-03-06|last2=Monperrus|first2=Martin|last3=Kloppenburg|first3=Sven|last4=Mezini|first4=Mira|series=Lecture Notes in Computer Science|isbn=978-3-642-13594-1}}</ref>

== Topics ==

Line 17 ⟶ 18:

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.

Derived meta-metamodels include [[Entity-relationshipentity–relationship model|entity relationshipentity–relationship diagrams]], [[formal languages]], [[extended Backus-NaurBackus–Naur form]] (EBNF), [[Ontologyontology 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]

Line 36 ⟶ 37:

UML includes a profile mechanism that allows it to be constrained and customized for specific domains and platforms. UML profiles use [[Stereotype (UML)|stereotypes]], 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 [[SysML]], a ___domain specific language for [[systems engineering]].

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 [[Akoma Ntoso]] can be developed by representing legal concepts and ontologies in UML class objects.<ref>{{Cite book |last=Flatt |first=Amelie |title=Model-Driven Development of Akoma Ntoso Application Profiles - A Conceptual Framework for Model-Based Generation of XML Subschemas |last2=Langner |first2=Arne |last3=Leps |first3=Olof |publisher=Sprinter Nature |year=2022 |isbn=978-3-031-14131-7 |edition=1st |___location=Heidelberg |language=en}}</ref>

==See also==

== See also ==

* [[Computer-aided software engineering]]

* [[Domain-driven design]]

Line 48 ⟶ 51:

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

== References ==

{{Reflist}}

== External links ==

* [http://www.itarchitect.co.uk/articles/display.asp?id=161 Domain-specific modeling for generative software development] {{Webarchive|url=https://web.archive.org/web/20100131064439/http://www.itarchitect.co.uk/articles/display.asp?id=161 |date=2010-01-31 }}, Web-article by Martijn Iseger, 2010

* [https://web.archive.org/web/20151118021655/http://www.pocomatic.com/docs/whitepapers/dsm/ Domain Specific Modeling in IoC frameworks] Web-article by [[Ke Jin]], 2007

* [http://www.methodsandtools.com/archive/archive.php?id=26 Domain-Specific Modeling for Full Code Generation from Methods & Tools] Web-article by Juha-Pekka Tolvanen, 2005