Domain Specific Languages and the Unified Modelling Language

Domain Specific Languages and UML

A domain is any area of speciality, and a domain specific language (DSL) is a language that has elements designed specifically for a domain, contrasted to generic or general purpose languages, which attempt to be able to cover anything. Domains can be business-related, with elements such as customer and warehouse, or architectural domains, which might use elements such as entity, service or page. In fact you can select whichever domain area best characterises the sort of thing you are likely to be generating.

The Unified Modelling Language (UML) is an example of a graphical, general-purpose language, and it's an ideal example of why code generation requires some level of domain specificity. UML 2.0 has thirteen diagram types with overlapping functionality, any of which can be used to convey incomplete and ambiguous information to the viewer. Unless specific limitations are placed on the diagrams and how they are used, it isn't possible for a generation system to do more than guess what you are trying to show. And that's often the same problem that development teams have and that we are trying to overcome with code generation tools.

It is possible to use UML by restricting its use to a tightly defined subset, for example by using executable UML (xUML). To create a tighter specification using UML, the language provides the ability to profile its elements, using stereotyping and tag values. By stereotyping a class to be an entity or a component to be an application, you can ensure that the code generator will look for the meta-model and template directories associated with that name. You can add named property values to a model element by tagging, and the tag values are associated with the element. In some UML modelling tools, the valid tag values are restricted by the stereotype(s) applied, but in others, any name value pair can be added to any element.

JeeWiz only transforms things it can understand, but these can be somewhat generic, such as the children of something it knows about. However, it makes guesses about what these might be, for example assuming all properties not in the meta-model are text values. This can be useful on occasion and for tools which don't allow free tagging, such as Rational Software Modeller, we provide a tag called extraAttributes, which expects a list of name-values pairs to be passed on to the generator.

Of course, that brings up the question of how does the list of available stereotypes and their tag names get into something like RSM in the first place. Initially we take a list of all the meta-model elements in a transform for a defined stack (see the link to CodeGen for a description of the stack), and we create an eclipse plugin using the meta-model elements for stereotypes and the public data properties for the tag names. Actually we also run it through a filter transform so as to make tag-value entry a little more user friendly, but that's the gist of it.

JeeWiz doesn't just filter when creating the Eclipse plugins, it allows for a filtered massaging of the information in the model. For example, for the JSF/Spring/Hibernate transform, we make the assumption that an association between two stereotyped entities carries the stereotype "relation", whether or not this has been specified, and generating from within Eclipse can update the model with the stereotypes automatically. In fact if a class diagram is created and just one of the classes is stereotyped as an entity, it is possible to automatically stereotype all the classes as entities, all the associations as relations and their ends as ends, and all the class attributes as attributes. In RSM this allows access to the correct tags values for further model markup.

In some platforms, meta-models only allow specification of the data elements, whereas DSLs also model behaviour. JeeWiz meta-models incorporate the full object-oriented power of java and can specify everything that DSLs do.

Domain Specific Modelling (DSM) goes further than this, but JeeWiz does not apply domain specific modelling restrictions at the time the model is created. Model constraints are only applied when the model is used or a specific validation pass requested, so it is possible to draw domain illegal constructs. JeeWiz is primarily a code generation tool and currently does not supply its own modelling tool. Instead it supports many others through XML, which is JeeWiz's primary modelling language.

NT/e see Eclipse as a strategic modelling platform, and as well as providing stereotypes/tag value plugins, Jeewiz exports a data-type library, an Eclipse help plugin and set up the ability to generate using JeeWiz from within Eclipse. JeeWiz also forms the code generator of the Eclipse SOA tools project, Swordfish (available separately). The Eclipse modelling framework (EMF) has an internal representation of model elements built into the core of the framework (Ecore). It is expected that the JeeWiz-Ecore transform will be included in the next release of JeeWizCE, allowing cross-compatibility.