This section describes the design so that you get a feeling of where we are heading.

The core of the system is a Domain Model [12], see Figure 2, “Domain model”. A Library consists of PhysicalMedia. Books and Movies are different types of Media, which are stored on a PhysicalMedia, e.g. DVD, VHS, paper books, eBooks on CD. A Media has Characters, e.g. James Bond, which can be played by a Person, e.g Pierce Brosnan. A person can be involved (Engagement) in different Media, actually a Person can have several Engagements in the same Media. E.g. Quentin Tarantino is both actor and director in the movie 'Reservoir Dogs'.

Figure 2. Domain model of the Library example.

Repositories [13] are used to find/update domain model Aggregates [13]. The repository uses Access Objects [14], which implement the specialization needed for persistence. Access Objects have separated interface and implementation. Abstract Factory [15] is used to create instances of the Access Objects. Access Objects are implemented as Commands [15]. Hibernate has been used as O/R-mapping framework, and a generic set of Access Objects for common CRUD operations are part of the application framework.

In front of the domain model we have a Service Layer [12], which typically use Repositories to find/update domain model Aggregates. See Figure 3, “Overall design” .

Figure 3.  Overall design with Service, Repository and Access Object classes.

Illustration of the normal execution flow can be found in Appendix: Sequence Diagram .

The following tools have been used in the example in this article; Eclipse 3.1, Java 5.0, EMF, Merlin, Argo2Ecore, ArgoUML, Hibernate, and MySQL. You need to install them to be able to run the example. See Resources [1] - [8] for more information.

These tools have been chosen for this article mainly because they work well together and are fairly easy to use. There are many alternatives and you have to decide for yourself which tools to use when implementing the approach.

The DSL model for this example consists of three parts; domain model, repositories, and services. In this example the DSL model is tailored for a rather technical system design domain. It is rather independent from the business domain. To leverage the full potential of DSM it is even better to use concepts from the business domain in the language. The reason for this is described in Why DSM? [10]

The class diagram in Figure 4, “Domain model” is the domain model in the DSL model. It defines classes, with properties and relations that represent the domain model. This information is used for generation of domain model implementation classes, Hibernate mapping and database schema.

Figure 4.  Domain model representation in ArgoUML.

There are two Repositories, for the Library and Person Aggregates, see Figure 5, “Repositories” . The repositories are modeled as ordinary classes with operations. This information is used for generation of Repositories, Access Objects, and Abstract Factories.

Figure 5. Repositories in the DSL model.

There is one service class that exposes the published interface to client applications. In the DSL model we define the service operations and eventual delegation to repositories, see Figure 6, “Services” .

Figure 6.  The clients interacts with the application via the service layer.

ArgoUML is used to define the DSL model, which we convert to an Ecore model with the argo2ecore plug-in. It is done with a simple right click on the exported XMI file.

See Appendix: Ecore for some more information.

JET is used as code generation templates. JET is similar to JSP, so any knowledge of this should come in handy, see Appendix: JET Basics .

JET templates are defined in a separate Eclipse JET project, but we don't need to package them as a plug-in. We use a helper class to simplify the usage of the Ecore model from the templates. The helper can provide any functionality you need, such as String manipulation. The helper in this example is named EcoreGenerationHelper. You can use it as a foundation, but you should modify/extend it to fit your needs. Some templates may need specific functionality and then you should implement template specific helpers. An example of this is the DatabaseGenerationHelper, which is used for the Hibernate and DDL generation.

Tip: When developing a template it is convenient to use the preview pane, see figure in Appendix: JET Basics .

The Library example make use of 11 JET templates, one of them is Repository.javajet , and some interesting parts are described below.

The two repository classes in the DSL model are mapped to Repository.javajet and it generates LibraryRepository.java and PersonRepository.java Naming conventions are used to realize specific features. The input class must end with "Repository", and the part before that is used as part of the name in several of the classes. Package naming conventions are also defined in the templates.

The interesting part of Repository.javajet is the section that generates the methods. It generates code that delegates to the Abstract Factory and Access Object, but if the 'noaccessobject' annotation has been defined on the operation an empty method stub is generated, to be filled in by hand written code.

<%for (EOperation op : h.getOperations(eClass)) {
  // a few naming mapping conventions
  String mappedOpName = h.getMappedOperationName(op);
  boolean findById = (mappedOpName.equals("findById"));
%>
    /**
     * <!-- begin-user-doc -->
     * <!-- end-user-doc -->
     * @generated
     */
     <%=h.getVisibility(op) %><%=h.getTypeName(op)%> 
	 <%=h.getName(op)%>(<%=
       h.getParameterList(op)%>) <% if (findById) {
       %>throws <%=baseName%>NotFoundException<%}%> {
  <% if (h.getAnnotation(op, "noaccessobject") != null) {%>
        // TODO Auto-generated method stub
        throw new UnsupportedOperationException("<%=mappedOpName
          %> not implemented");
  <%} else {%>
        <%=h.capName(mappedOpName)%><%=productType%>
		<%=h.getGenericType(op)
          %> ao = <%=h.uncapName(baseName)%><%=productType%>
		  Factory.create<%=
          h.capName(mappedOpName)%><%=productType%>();
    <%for (EParameter parameter : h.getParameters(op)) {%>        
        ao.set<%=h.capName(h.getName(parameter))%>(
		<%=h.getName(parameter)%>);
    <%}%>
        ao.execute();
    <%if (!h.getTypeName(op).equals("void")) {%>
      <%if (findById) {
        EParameter idParam = h.getParameters(op).get(0);
      %>
        if (ao.getResult() == null) {
            throw new <%=baseName%>NotFoundException("No <%=
              baseName%> found with <%=h.getName(idParam)%>: " + <%=
              h.getName(idParam)%>);
        }
      <%}%>
        return ao.getResult();
    <%}%>
  <%}%>       
     }
     
<%}%>
                        

Note: Note the convention to use typed Lists (generics). In the model we use array types of the operations, e.g. Media[] that is generated as List<Media>. This mapping is implemented in the method getTypeName in the helper. This is a typical design decision that is implemented in the templates as a convention.

Detailed descriptions of the code generation of the other parts of the example system can be found in appendix:

The next step is to connect the model elements with appropriate templates. Merlin is used to define this mapping. It provides a drag-and-drop mapping user interface between model elements and JET templates. A model element is typically a class, operation or package, but it can be anything defined in the model. The model element will be the input argument to the template. It is also from the Merlin JET Mapping Model we start the code generation. See Appendix: Merlin Tools for more details.

Figure 7, “Generated code” illustrates how the code is generated by the JET templates with the mapped model elements as input arguments.

Figure 7.  The Ecore model to the left is mapped to JET in the middle, and the generated code is to the right. Only some of the mappings are illustrated. Click on different parts of the image to see more details.

Some parts of the system are generated and some parts are hand written. The Lightweight Domain Specific Modeling approach doesn't push full code generation as important, something that DSM emphasizes. Instead we try to keep it as simple as possible. If it is easier to write the code manually it should be done manually. Also, it is important to be able to use best of breed IDE tools together with code generation, e.g. when debugging you must feel comfortable with the generated code. See also Appendix: Mixing Generated and Hand Written Code.