Domain-specific modeling: Difference between revisions

Browse history interactively ← Previous editContent deleted Content addedVisual WikitextInline

Revision as of 12:56, 30 June 2005 edit212.149.217.232 (talk) minor fixes, added some internal links← Previous edit		Latest revision as of 02:40, 25 July 2024 edit undoGrabUp (talk \| contribs)Autopatrolled, Extended confirmed users, IP block exemptions, New page reviewers, Pending changes reviewers, Rollbackers19,760 editsm Reverted edits by 2806:267:4404:8F9F:184E:CE05:600C:C28A (talk) (AV)Tags: AntiVandal Rollback
(194 intermediate revisions by more than 100 users not shown)
Line 1:		Line 1:
			'''Domain-specific modeling''' ('''DSM''') is a ] ] for designing and developing systems, such as ]. It involves systematic use of a ] to represent the various facets of a system.
	==Introduction==
	'''Domain-specific modelling (DSM)''' is, beyond traditional ], a way to model ] and ] in "domain ]" independent from ] and thus also ] details. The final ] ] in a desired ] is ] ] from theese high ] ] by using specific ] generators. This is possible, because both the modelling ] and ] generators are defined by users of DSM ].

			Domain-specific modeling languages tend to support higher-level ] than ] languages, so they require less effort and fewer low-level details to specify a given system.
	==Differences between traditional CASE and DSM==
	Think of a DSM system as an "application to make a ] tool (])" or an "application for making aplications to make applications". So there is an extra layer of ] when compared to traditional ] tool, which would be just an "application to make applications". Traditional ] tools are just fine IF AND ONLY IF they happen to fit nicely to your specific domain, let it be a ], for example. Usually this does not happen accurately enough, though. Building your own domain specific ] tool from scratch with a ] and without a DSM system is VERY ] and thus the advantage of having a own domain specific ] tool is often considered not worth the effort of creating one. DSM changes all of this. It's specifically designed for the task and does it's job brilliantly.

			== Overview ==
	==DSM example with two abstraction levels of DSM models - a digital clock ==
			Domain-specific modeling often also includes the idea of ]: ] the creation of executable ] 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.<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}} </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 domains can be of any ] level. Usually higher ] DSM domain ] are modelled with lower ] DSM domain ]. For example, a set of lower ] DSM domain ] could be the internal functioning (]) of ]. The resulting set of higher ] DSM domain ] would be the DSM ] of the ]. A functioning highest level DSM ] (using the ] ] components as DSM domain concepts..) could be a ] ], compiled from the ] DSM domain concepts.

			Domain-specific language differs from earlier code generation attempts in the ] tools of the 1980s or ] 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.
	'''In brief''': ] can be made of ] that can be made of ]. Thus we build ] out of ] and the ] out of ]. So we have total three levels of ] in our ] model of a digital clock: 1) logic gates, 2) integrated circuits 3) the digital clock circuit.

			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.
	==Many uses==
	Basically, you can do anything with a DSM system that you can do with a ] ]. The ] of highest ] domains can be anything from ], trough ] to ] to ].

			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 ], 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.
	==DSM brings 500% to 1000% increase in productivity over Java/c++/BASIC==
	DSM has been to increase ] by 500% to 1000% when compared to plain ]/]/]. In comparison the shift from ] to ] showed an increase of 400% in ].

			== Topics ==
	==Focus on detail vs. focus on functionality==
	DSM still requires talented experts to do the language generators and the domain ], but the ] using the predefined DSM ] need not to know about ] details nor the target ] ] details. This enables the developers using a DSM ] to think and develop in ] (], button clicks, for example). So in brief: detail minded domain specific experts specify the DSM ] (]) and the more-practically-minded ] use the high-level ] to do a nice application by concentrating on functionality. An example of highest ] level DSM ] For example a ] ].

			=== Defining domain-specific languages ===
	==Differences between UML and DSM==
			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.
	] is, in a way, just a set of pre-defined "domain specific models". Theese "]" include ], ] and ] amongst others. Some of theese diagrams have functionality ("logic") or certain places where certain types of data is stored in (a ] / ], loosely speaking). ] is mainly intended for modelling ], ] or ] ]. As such, ] can be easily modelled with DSM software, altough the UML "DMS models" itself are somewhat abstract and therefore do not allow generation of complete working application solely from them. Alltough UML models could succesfully be included amongst other DSM models to define the logic & functionality of a full application.

			Derived meta-metamodels include ], ], ] (EBNF), ], ], and ] (MOF). The strengths of these languages tend to be in the familiarity and standardization of the original language.
	==It works. Nokia does DSM==
	As of 2005, DSM is a hot topic of discussion amongst software professionals. ] has been using DSM.

			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.
⚫	==See also==
			</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. (in 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 languages ===
			Many ] languages already have tool support available in the form of ] 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.

			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 ] when compared to a traditional CASE tool.
⚫	==External links==
	* Article on experiences of DSM from ], ] and ]
	*
	* - explains why the DSM increases productivity from 500% to 1000%.
	*
	* - MetaEdit+, the leading DSM software.
	* - free software modelling with partial support of DSM.
	*

			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 ] or ], open source such as ], or academic such as ]. The increasing popularity of domain-specific language has led to domain-specific language frameworks being added to existing IDEs, e.g. (EMP) with ] and ], or in Microsoft's for ].
⚫	]

⚫	]
			== Domain-specific language and UML ==
			The ] (UML) is a ] language for software-intensive systems that is designed to support mostly ]. 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 ] are familiar to all practitioners in that domain. For example, in the domain of ], there will be software models to represent the properties of an ], or a ], etc.

			UML includes a profile mechanism that allows it to be constrained and customized for specific domains and platforms. UML profiles use ], 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 domain specific language for ].

			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 ] 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 ==
			* ]
			* ]
			* ]
			* ]
			* ]
			* ]
		⚫	* ]
			* ]
			* ]
			* ]

			== References ==
			{{Reflist}}

		⚫	== External links ==
			* {{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
			* Web-article by ], 2007
			* Web-article by Juha-Pekka Tolvanen, 2005
			* Web-article by Juha-Pekka Tolvanen, 2006

		⚫	]
			]

Latest revision as of 02:40, 25 July 2024

Domain-specific modeling (DSM) is a 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.

Domain-specific modeling languages tend to support higher-level abstractions than general-purpose modeling languages, so they require less effort and fewer low-level details to specify a given system.

Overview

Domain-specific modeling often also includes the idea of code generation: automating the creation of executable source code 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. The reliability of automatic generation compared to manual coding will also reduce the number of defects in the resulting programs thus improving quality.

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

Topics

Defining domain-specific 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, extended Backus–Naur form (EBNF), 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, GOPRR, and GOPPRR, which focus on supporting things found in modeling languages with the minimum effort.

Tool support for domain-specific languages

Many General-Purpose Modeling languages already have tool support available in the form of 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.

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 abstraction when compared to a traditional CASE tool.

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 GEMS, or academic such as GME. The increasing popularity of domain-specific language has led to domain-specific language frameworks being added to existing IDEs, e.g. Eclipse Modeling Project (EMP) with EMF and GMF, or in Microsoft's DSL Tools for Software Factories.

Domain-specific language 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 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 semantics are familiar to all practitioners in that domain. For example, in the domain of automotive engineering, there will be software models to represent the properties of an anti-lock braking system, or a steering wheel, etc.

UML includes a profile mechanism that allows it to be constrained and customized for specific domains and platforms. UML profiles use 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.

References

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
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.
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.
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)
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.

External links

Domain-specific modeling for generative software development Archived 2010-01-31 at the Wayback Machine, Web-article by Martijn Iseger, 2010
Domain Specific Modeling in IoC frameworks Web-article by Ke Jin, 2007
Domain-Specific Modeling for Full Code Generation from Methods & Tools Web-article by Juha-Pekka Tolvanen, 2005
Creating a Domain-Specific Modeling Language for an Existing Framework Web-article by Juha-Pekka Tolvanen, 2006

Categories: