Discussion Topic: Lightweight Domain Specific Modeling

"Improving Developer Productivity with Lightweight Domain Specific Modeling" is the title of a current article from Patrik Nordwall, an experienced Java architect at the Swedish consulting company Avega AB. The article was published at TheServerSide.com, the largest Java community on the Web. Nordwall compares different software development techniques that partially compete with each other. Code generation is one of them. In fact, Nordwall combines these techniques into a true methodology named "Lightweight Domain Specific Modeling", whereby the use of domain-specific models is an important point, especially for code generation. We consider Nordwall’s article to be very worth reading. Read on for our constructive criticism on the article.

In his article Nordwall at first states that programmers frequently perform simple repetitive tasks, for example by excessive “copy-paste-adapt”, i.e. by continually copying and adapting code fragments by hand. If one tries to automate this process, however, things rapidly become time-consuming and difficult. Nordwall proposes as a solution using domain-specific languages (DSLs) and related code generators.

While Nordwall's approach is quite reasonable, its motivation is a little diffuse here: even trivial coding activities may be realized by (primitive) generator techniques in a simple way, e.g. by macros or filters. The underlying problem occurs for non-trivial activities, which could be automated only expensively. A generator for such a task realizes a higher, domain-oriented level of abstraction. Its domain-specific orientation, however, limits its usage area and makes the generator's creation a complex task.

Concerning such domain-specific generators Nordwall favors their project-specific development instead of buying available generators. In doing so, one totally keeps control of one’s own generators. This is important with regard to changing requirements. This statement from Nordwall corresponds with the experiences of Delta Software Technology with the commercial usage of generators: in many cases they have to be developed in a project-specific way, thereby having to be profoundly adaptable for changing customer requirements. Last, but not least, the customer has to be able to maintain such project-specific generators on his own. Nordwall presents this issue in a certain global way, almost leading to the idea to relate it not only to code generators. However, analyzing the make-or-buy decision concerning generation tools by using objective criteria certainly is an interesting field for further study.

Getting back to the article – Nordwall refers to a variant of "Domain Specific Modeling" (DSM), which is convenient (especially for small projects) and therefore is named with the addition "Lightweight". In order that the approach becomes economic, the effort required to create a generator has to be worthwhile within the particular project. Nordwall does not present a system family approach here. This, however, could be decisive for making the return on investment decision of "Is a generator economic or not?" (See the report "Processes as Input: Generating Web Portals").

In detail, Nordwall proposes the appliance of a range of freely-available Eclipse-based tools and techniques: the respective DSL could be defined with ArgoUML and subsequently be converted to an Ecore model. Based on this, JET templates would be used for defining the generator, whereby the Eclipse plug-in Merlin would realize the connections to the Ecore model.

In the approach presented, Nordwall particularly renounces the definition of a metamodel for the domain-specific model. This is, according to Nordwall, an important difference to the concepts of the OMG MDA (Model-Driven Architecture). In our opinion, domain-crossing tool support, the usage of a software family concept and model transformations at least become complicated, if not actually impossible.

Indeed Nordwall clears up one misunderstanding: that models are not one-to-one representations of implementations, but abstractions that simplify certain things. The point is not to define UML models that are as code-related as possible, but to focus on things that are important for code generation within the models. Following Nordwall this is not a problem, as using a project-specific generator one has technical details as well as elements not covered by the domain-specific model, e.g. its templates, which are under full control within a generator developed specifically for the project.

With HyperSenses Delta provides a base technology for the development of model-based generators, focusing especially on project-specific generators. Comparing Nordwall's approach to HyperSenses, a main difference is the definition of the models: A HyperSenses model is always related to a metamodel that exactly defines the variation points for a generator. This is domain-specific in any case. According to Nordwall a domain-specific model corresponds with a HyperSenses model, whereas the metamodel in fact does not exist explicitly. In HyperSenses, however, a meta-metamodel ensures domain-crossing, uniform systematics (tool features, concepts, …) for all HyperSenses models, tools and components.

To conclude our remakes: it has to be stated that the return on investment is decisive for the worthwhile usage of code generators. It is remarkable that in the article discussed here (as well as elsewhere) broad terms and general presumptions are used again and again to make the case. Preferably, one day clear and objective criteria for this task, such as metrics, should be presented by the research world.

Form your own opinion and read Nordwall's article at:
http://www.theserverside.com/tt/articles/article.tss?l=LightweightModeling