When classifying programming and modeling languages it is becoming increasingly useful to distinguish between General Purpose Languages (GPLs) and Domain Specific Languages (DSLs).  Examples of General-Purpose Programming Languages (GPPLs) include Smalltalk, C++, and Java. The best known example of a General-Purpose Modeling Language (GPMLs) is UML.

Examples of Domain-Specific Programming Languages (DSPLs) include YACC for parsing and compiler writing, and GraphViz for defining visual representations of directed graphs. An example of a Domain-Specific Modeling Language (DSML) is SysML, which is a subset of UML that is customized for systems engineering applications. This page is dedicated to providing information about DSMLs, which is an active area of growth for visual modeling languages.

What are the advantages of using a DSML, such as SysML, rather than a GPML, such as UML? The answer, of course, depends upon the particular DSML that you design or choose, and how well it is customized to meet the needs of your particular application domain. However, if we assume that the DSML selected is properly designed and implemented, you should expect to make tradeoffs between the following advantages and disadvantages:

PROS

• Prefabrication of high-level abstractions. DSMLs provide domain experts with prefabricated abstractions that are defined at the same level as their problem domain. Consequently, domain experts can quickly learn, apply and extend DSMLs without a steep learning curve. For example, a DSML for mobile phone applications might include prefabricated constructs for Display, HardKeyButton, SoftKeyButton, and Ringtone, along with code generators to create calls using software components. Similarly, a DSML for Command & Control (C2) defense applications might include prefabricated constructs for Headquarters, MilitaryUnits, AirForces, LandForces, MaritimeForces, Operations, and Missions, along with code generators to create mission scenarios using software components.
• Information hiding of irrelevant constructs and details. DSMLs don't include constructs and details that are unrelated to your problem domain. As a result, your domain experts won't be distracted by entities that are unrelated to the problem they are solving. For example,  mobile phone experts or C2 defense experts won't be distracted by the relatively low-level generic constructs such as Classes, Attributes and Operations that support object-oriented GPPLs.

 CONS

• Design, implementation, and maintenance costs. Since first-generation commercial DSML tools have only recently become available, the main disadvantage for pursuing a DSML approach at this time is that you will likely need to design, implement, and maintain your DSML yourself. However, if you are already using a GPML like UML, you may be able customize it to produce a DSML for your project, but you will encounter some limitations with this stopgap solution (see below).
• Code generation capabilities lag those of GPMLs. If automated code generation is important to your modeling project, you will generally find that DSML code generation capabilities tend to lag behind those of GPML code generation capabilities, especially  regarding optimizations. This situation will likely improve over the next few years as GPML tools mature.

Can UML modeling tools be used to design and implement DSMLs? The glib answer is yes, since most UML tools support a stereotype mechanism for defining language customizations called profiles (e.g., the SysML DSML is defined as a UML 2.0 profile). In addition, many UML tools allow users to partially customize their user interfaces by adding graphic icons and modifying menus.  However, because UML 2.0 stereotypes impose substantial restrictions on customizing language semantics (compare metaclasses), and it is frequently difficult to filter out the UML constructs and features in a UML modeling tool, designing and implementing DSMLs in current UML tools should only be considered a transitional strategy. Hopefully, this situation will improve if UML tool vendors learn agility and DSML lessons from implementing SysML profiles.

You can find out more about DSMs by exploring the resources below:

• Webs
• Blogs
• Tools
• Books
• Papers
• Mailing Lists

Webs

• DSM Forum
  • Information and resources related to Domain-Specific Modeling.
• SysML Forum
  • SysML is a domain-specific modeling language for systems engineering applications.

Blogs

1. Juha-Pekka Tolvanen
2. Steven Kelly
3. Angelo Hulshout
4. Software Chimps
5. Jack Greenfield
6. Steve Cook
7. Stuart Kent

Commercial Tools

1. MetaEdit+ (MetaCASE)
   • Appears to the be leading customizable DSM tool. Relatively mature (v. 4.0 is available), and supports Windows, Linux, Mac OSX, HP, and Solaris. Evaluation download available.
2. XMF-Mosaic (Xactium)
   • Startup product that requires Eclipse. Current version 1.0. Fill out online form to obtain an evaluation copy.
3. Eclipse Graphical Modeling Framework (GMF)
   • Provides a generative component and runtime infrastructure for developing graphical editors based on Eclipse Modeling Framework (EMF) and Graphical Editing Framework (GEF). GMF has the potential to be used to develop DSMs, but it is currently still under development. Version 1.0 is expected to be released in Q3 2006.
4. Microsoft Visual Studio: Domain-Specific Language Tools
   • Perpetual pre-beta?

Books

• Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools by Jack Greenfield, Keith Short, et al.

Papers

• Domain-specific Modeling: Making Code Generation Complete: Juha-Pekka Tolvanen, DevX.com, April 27, 2006.
• Domain-Specific Modeling and Model Driven Architecture: Steve Cook, MDA Journal, January 2004.

Mailing Lists

• N/A