Gen, UML and the DSL boat – Part 1

In recent gen Gatherings, a lot of discussion has been had about the tools and techniques that surround UML and Gen. However – is there another boat that Gen should be trying to board ? That of the DSL – or – Domain Specific Language.

A previous post in this blog waxed lyrical about DSLs,but it’s time I revisited that subject.

Domain-specific languages are designed to do one thing very well. C is not a DSL, as it is a general purpose language. Gen is usually used to manipulate data within databases, so can be considered a DSL. Yes, it has the ability to present that data in a variety of forms, but inherantly, its a DSL – long before the term DSL was coined!

Many examples of DSLs are to be found in Model-Driven-Engineering. Gen is a Model-Driven-Architecture  toolset, and as such, models and DSLs are of interest

Wikipedia defines a Model-Driven-Architecture as requiring some or all of the following:

Creation Tool:A tool used to elicit initial models and/or edit derived models.
Analysis Tool: A tool used to check models for completeness, inconsistencies, or error and warning conditions. Also used to calculate metrics for the model.
Transformation Tool: A tool used to transform models into other models or into code and documentation.
Composition Tool: A tool used to compose (i.e. to merge according to a given composition semantics) several source models, preferably conforming to the same metamodel.
Test Tool: A tool used to “test” models as described in Model-based testing.
Simulation Tool: A tool used to simulate the execution of a system represented by a given model. This is related to the subject of model execution.
Metadata Management Tool: A tool intended to handle the general relations between different models, including the metadata on each model (e.g. author, date of creation or modification, method of creation (which tool? which transformation? etc.)) and the mutual relations between these models (i.e. one metamodel is a version of another one, one model has been derived from another one by a transformation, etc.)
Reverse Engineering Tool: A tool intended to transform particular legacy or information artifact portfolios into full-fledged models.

Let’s test the theory that Gen is a Model-Driven-Architecture, shall we ???

Looking at Gen and its eco-system – do we have any of these at our disposal ?

Creation Tool: Pretty obvious – the toolset itself
Analysis Tool: many tools for this including the toolset itself and IET‘s verifIEr and Jumar‘s Model nalyser/ Model Reporter tools
Transformation Tool: The generators do this, as do some ecosystem tools (ModelCVS and Jumar:Links UML interface, for example) 
Composition Tool: Adoption within models broadly equates to this capability – importing model information from other models.
Test Tool: Jumar’s deployment of automatically generated test-harnesses for components as part of the Project Phoenix methodology.
Simulation Tool: Does this really equate to a “build and deploy” stage – i.e. the generators
Metadata Management Tool: I guess the nearest we get to this is model versioning such as we can get from GuardIEn
Reverse Engineering Tool: Many of the Legacy Renewal technologies – ModelCVS, Evolveware and others can import a set of Legacy source code in COBOL, Natural, PL/1 etc into Gen

So – yes we can consider Gen to be a true fuly-fledged MDA-complient toolset.

So where do DSLs fit into this then ?

I’ll worry about that in Part 2 !