Domain-specific modeling: Difference between revisions

Revision as of 08:08, 11 September 2017

Latest revision as of 21:42, 24 June 2025

(18 intermediate revisions by 15 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 8 ⟶ 9:

Domain-specific language 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.{{fact|date=November 2012}} 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.

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 organization's requirements need be taken into account, it is easier for the modeling language to evolve in response to changes in the ___domain.

Domain-specific language 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.

== Topics ==

=== Defining ___domain-specific language 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.

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]

</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.[https://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 ___domain-specific language languages ===

Many [[General-Purpose Modeling]] languages already have tool support available in the form of [[Computer-aided software engineering|CASE]] 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.

Line 29 ⟶ 30:

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.

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 [https://web.archive.org/web/20060423095834/http://msdn.microsoft.com:80/vstudio/dsltools/ DSL Tools] for [[Software factory|Software Factories]].

== Domain-specific language and UML ==

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

* [http://www.methodsandtools.com/archive/archive.php?id=50 Creating a Domain-Specific Modeling Language for an Existing Framework] Web-article by Juha-Pekka Tolvanen, 2006