Root CUIP Metalevel

Posts from November 2009.

Conceptual Map for MDD

When talking about Model Driven Development (MDD), code generation and related technologies, the key terms, its meanings and usage could not be clear enough to the involved audience due to our different backgrounds and the use of overloaded terms in several specific jargons.

A good way to avoid such confusion is to make explicit a short clear definition of the terms used.

Following this idea, today I want to share the Conceptual Map I traditionally use to explain the areas involved in code generation. This map helps me to explain how more complex interactions and natural dependences and properties arise in this domain. See embedded video.

We will start considering MDD using two orthogonal dimensions:

  • Types/Classes vs Instances &
  • Two levels of abstraction: Programs/code (technology dependent, concrete)  vs Models (technology independent, abstract).

Key concepts

  1. Model: A description of the problem to be solved.
  2. Metamodel: A type description for providing the modeling language.
  3. Template: A pattern representation of the code you want to create.
  4. Transformation: Application of an algorithm to transform one or more models in one o more outputs.
  5. Output: Your target asset: source code, doc or models again.

Additional concepts

  • Mappings = Template to Metamodel item bindings
  • Architecture Know How = Mappings + Templates (embedding best practices and patterns)
  • Business Know How  = Metamodel + Model
  • Model Checker = Validation of Model with respect to Metamodel
  • Generator = Transformation(Templates, Mappings, Model) –> Output

A pair of properties to mention.

Stability:

  1. Metamodel: Quite stable once developed.
  2. Model: Stable till the business change (requirements change).
  3. Template: Stable till not changing or evolving the technology (2-3 years cycle?).
  4. Transformation: Impacted by technology or metamodel changes.
  5. Output (Source code): Regenerated as needed. Discardable.

Dependences:

  1. Metamodel: Not dependent of third parties.
  2. Model: Altered if metamodel changes.
  3. Template: Not dependent of third parties (just the technology).
  4. Transformation: Impacted by template changes, mapping changes and  metamodel changes.
  5. Output (Source code): Impacted by everything. Regeneration is a good property as seen before. But now is a necessity.

Changes in the formers will cascade to the latter.

Strong Separation of Concerns & skills

Apart of the classical advantages provided by MDD approaches such as quality, productivity, time to market, & technology independence; one of the good properties no so times recalled is the strong separation of skills that this method of software engineering provides:

  • Business analyst can concentrate efforts in using modeling editors to describe the business and provide feedback to enhance metamodels (when needed)
  • On the other side, Software Architects and technology gurus can concentrate in tuning the technical architecture to achieve the most performing implementations they can provide.

One you achieve this stage, you can start thinking of reusing and evolving your business models and architectures at speeds that most of traditional SW developers never seen before.

There is one famous quote from Grady Booch saying:

“The entire history of software engineering is one of rising levels of abstraction (abstraction is the primary way we as humans deal with complexity).”  Grady Booch

As many others, I think that MDD is the next step to adopt in such direction. When it will happen globally is just a question of achieving the critical mass:

  • having good enough tools,
  • and having practitioners enough and success cases to prove the value in the “not so new” way of working.

I’m optimistic about it. We are in the way and getting speed…

SOA and MDD with Oslo

In the issue #21 of the Microsoft Architecture Journal, Cesar de la Torre talks about implementing SOA using an MDD aproach supported with Oslo: Model Driven SOA with Oslo.

In the economic crisis scenario, some voices argues about the death of SOA (more, more and more) just even before few organizations has already started to adopt it.

However, the SOA approach has valuable principles for Enterprise Software organization for the long term maintenance, integration and minimizing the TCO.

Johan den Haan has a nice post about it: SOA is dead; long live Model-Driven SOA.

As a supporter of MDD, I agree with Cesar and Johan, MD SOA could be a way to deliver the good principles behing SOA.

SOA is always a tough topic to explain for first time visitors. To help to introduce it I will link a superb presentation about it: Meet mike… (credits for Eduard Hildebrandt).

MDD with Oslo

MDD with Oslo

On the other hand, as Cesar pointed, Microsoft Oslo project has/had (after the rebranding) potential to be a good platform for domain modelling with textual DSL (MGrammar) and visual DSL (Quadrant).

As commented in the previous posts, it’s a pity that for the moment modeling efforts at Microsoft has been focused too much into one particular tree “the SQL Server scope” and loose the full forest vision.

The end of the MDD promise in OSLO

Sadly, Microsoft OSLO has died!

Via Jorge Ubeda I received the bad news. Accordingly to Douglas Purdy’s post, Microsoft OSLO is going to be rebranded to SQL Server Modeling CTP.

The people in the MDD community using .NET technologies has put a strong believe in Microsoft promise of delivering a big step forward in MDD with the OSLO project. At least, that what Microsoft sell us in the first CTP.

Now, in its new reincarnation: the M language, Quadrant and the Repository will still provide value for the database colleagues, for sure. But for the MDD community, this time, Microsoft has lost totally the point. That is quite different respect to the initial selling proposition we all bought at www.modelsremixed.com for example!

Model Driven Development is about increasing the level of abstraction, it is about technology and architecture independence. Tying the models with a database provides no help in achieving such objectives.

And what about MGrammar? It is a great tool for doing textual DSLs in the .NET environment. Any plans to support and improve it as a product or will end also tied to a database?

As Jorge points JJ. Dubray seems to be in the right path when anticipating the results.

It is a pity, a great opportunity to empower MDD with the right tools has been lost. Anyway, others tools will come and do the job instead.