What about pragmatic approach to model driven development?

Replies to This Discussion

Permalink Reply by Rui Curado on January 24, 2009 at 17:26

I also advocate a pragmatic approach to MD(S)D.

I've been performing research work, on my own, for several years, on the search for a simple, understandable way to do MDSD. Two years ago, I've finally come up with a methodology that I think is pragmatic and accessible to the average developer. I've been perfecting it in the last months. I named it ABSE (Atom-Based Software Engineering). ABSE essentially:

- Has a very, very simple meta meta model, therefore:
- Is abstraction-level independent, therefore:
- Can support and mix AOP, DSM, TDD, CBD and others, therefore:
- Is evolutive: Evolves as the software architect evolves, therefore:
- Can work on the solution domain as well as on the problem domain;

Also,

- Graphical models are not required
- Promotes reuse
- Can support ALM (The whole application lifecycle)

Curiously, I developed ABSE outside the MDD/DSM "school". When I started working on it, nine years ago, I didn't knew anything about AOP, MDD or DSM. I was basing my research on my own needs and understanding of the development process, with a constant focus on productivity. It was just a few months ago that I started tracing parallelisms between ABSE and all other model-driven techniques.

So I guess ABSE breaks some established MDD rules.

Also, the main reason I think ABSE is very pragmatic, is that it is not theoretical. The ABSE proof of concept is a full-featured IDE that implements ABSE. And since this IDE is an ABSE model, it can generate itself!

Of course, I am not intending to keep ABSE a secret. I submitted a session proposal for CG2009, where I intend to present the ABSE methodology, and AtomWeaver, the IDE that implements it. Now it's up to the CG2009 committee to decide if that's going to happen there...

• ▶ Reply

Permalink Reply by Ed Merks on January 25, 2009 at 12:35

I think the success of the Modeling Project at Eclipse is largely a result of its pragmatic focus. People end up using EMF not because they believe in model driven development---most in fact are very skeptical of it---but because EMF solves the problems they already have better than any other way. For example, most people who develop an XML Schema don't realize they have a model. The fact they can hand it over to EMF and out comes a complete API for reading, writing, and manipulating instances along with an integrated Eclipse editor for doing the same has obvious and immediate appeal. They don't have to believe in modeling, they only have to be busy with more important things than writing all this rote code by hand.

When it comes to standards I love then and I love to hate them. Unfortunately politics and technical compromise often dominate. Ecore was definitely a departure from MOF, but subsequent politics resulted in EMOF and CMOF where Ecore is isomorphic to EMOF and hence can easily be serialized to, and deserialized from, a standard EMOF serialization (which no one else produces, so kind of pointless). Keep in mind that there is no defined mapping from EMOF to Java, so one cannot argue that the Ecore API doesn't conform to something that's not been defined nor that EMF doesn't produce conforming APIs for any given Ecore/EMOF model instance.

Of course Eclipse also supports a multitude of standards based on EMF models. XSD is a conforming XML Schema implementation. UML is a conforming UML implementation. There are implementations of OCL, QVT, BPMN, and so on. It's a very long list. In the end, Eclipse is helping the OMG realize it's goal: a growing set of reusable implementations of their various modeling standards. I think this is an excellent demonstration that a focus on being pragmatic is what enables absolutely everything else.

• ▶ Reply

Permalink Reply by Johan den Haan on January 28, 2009 at 14:07

I do agree with Ed that a focus on being pragmatic enables everything else. If you start the other way around you will end up with complex standards, integrations, metalayers, etc. without any business value.

I think your approach (for MDD toolbuilding) should be something like:
- Make it work: build a prototype generating or interpreting just the application you want from custom models.
- Make it fast: build an enterprise-level system generating or interpreting a class of systems. Focus on all system aspects (including: performance, security, deployment, etc.).
- Make it beautiful: try to standardize your DSLs and work on interoperability with other tools, languages, and standards.

Besides that, don't forget to think about a methodology, templates, etc. See 10 misperceptions and challenges of Model-Driven Development for more information.

• ▶ Reply

Permalink Reply by Jorge Ubeda on February 1, 2009 at 13:12

I remember Mr Jack Greenfield naming his Software Factory concept as a pragmatic approach to MDD. ¿Are there any member to advocate on it?

• ▶ Reply

Permalink Reply by Marcus Munzert on February 20, 2009 at 13:16

I consider a pragmatic approach to model-driven development an approach where one uses as much as possible of what one already knows and is familiar with (languages, tools, technologies, methodologies). At the same time, the approach needs to be easily verifiable in terms of ease of use. In other words: someone who did not do model-driven software development before, ideally should be enabled to try it out herself/himself within one or two hours. Such kind of experience has the potential to pave the way for model-driven software development. Characteristics like simplicity and flexibility prevent people from thinking "oh, another thing I'll have to struggle with".

• ▶ Reply