Domain-specific modeling: Difference between revisions

Revision as of 22:50, 8 December 2017

Revision as of 09:04, 1 March 2018

Line 8:

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