Summary
Juha-Pekka Tolvanen provides advice and information useful for convincing colleagues and managers why MDD is worth using for development.

Sponsored Content

Bio

Juha-Pekka Tolvanen, PhD, is the CEO of MetaCase. He has been involved in model-driven approaches, meta-modeling and related tools since 1991. He has acted as a consultant worldwide on modeling language development, authored Domain-Specific Modelling, Wiley, 2008, and written over 60 articles in journals and conferences. Juha-Pekka is an adjunct professor at the University of Jyväskylä, Finland.

The Code Generation conference is the leading event on the practical applications of Model-Driven Software Development (MDSD). It offers a high quality learning experience by combining discussions and debates with a diverse range of practical tutorials and workshops. It will also give you the opportunity to share experiences and knowledge with fellow developers.The conference is now in its 6th year and is known for providing a high-value learning experience. This reputation has been built up by attracting industry-recognised experts to share their experiences at the conference.

There are many ways programmers like to use to produce code:Text oriented, Model oriented, IDE (NetBeans,Eclipse), ...All of those correspond to the different type of programmers, having a Model based enforced will displease more than 75% of programmers, they wont be productive with this tool because it does not fit their way of thinking.You claim programming language independence, and want to replace it with a one style fit all.I cannot believe in this, it is sure to fail.But for a percentage of programmers it will be successful, but be ready to accept having only one style and then limit your candidate pool.

Thanks for the comment Serge. Please note that the domain-specific languages and generators I’ve showed are all built by the programmers working in those domains ... so I think they should be happy on what they've built. The users of the domain-specific modeling languages may be then programmers or other kind of people.

You may, however, decide not to create or use domain-specific modeling languages and code generators but instead continue writing all the code manually. And that’s fine. As said in the talk, not all code will be generated so there is always place for the type of programming you described. The history, however, has shown that more and more of the code is been produced automatically and I don’t see any reason why that trend would stop. Models are one good source to feed the generators producing the code that does not make sense to write manually.

I am going to be a bit more abstract and state that a standard high level language is just a DSL for the software domain (which in turn is used by most organisations to realise their world). The domain specific models in the world of most programmers involve imperative programming representations. So all of the characteristic statics and dynamics true of any system exist specific to the developers' model (components/packages/class/interfaces etc. define the statics and their collaborations define the dynamics).

A programming language such as C# manifests that model using text whilst the same model can also be expressed in a DSL like UML. UML represents the model of a system in the domain of software development. A BPMN model is a DSL representing a model in the domain of business. An electronics schema is a DSL in the world of electronic systems etc. in my mind there is absolutely no difference at all in the conceptualisation of a DSL from a programming language. As Juha-Pekka implies, programming languages such as HTML are just more general DSLs.

However, I don't want to use a high level language to have to keep an 'intermediate' format of the model. The model's code generator should just output executable code straight off. If someone wants an intermediate representation, then they can have one through the back end of the same code generator but that same code generation process just throws out C# code, MSIL, PHP, machine code, Byte-code, p-code or whatever.

MDD, MDSD, MDA has been on the cards for a very long time and has unfortunately suffered from some false starts.

What sometimes makes me giggle is that we developers are constantly trying to get development 'closer to the customer'. So we remove specification phases and use Gherkin syntax and BDD to have conversations that are closer to the customer's frame of reference. Yet when it comes to talking about MDA and DSLs, which are often as close as you can practically get to a customer's activities, developers often go up in arms (maybe with legitimate concerns about the world of a programmer changing). We eradicated steps around documenting analysis and specification, so why shouldn't we expect to be the middle person/capability that is eradicated to streamline things from the point of view of business?

After all, currently, if a CEO wants to pivot the business it has to go through some business transformation with IT system changes to actually effect that pivot. Remove the IT system changes so that the business transformation process can pivot directly and is this not closer to the target business value? Can we not get there quicker?

@Ethar: I fully agree with your aspiration to avoid updating any intermediate formats. Therefore, the basic assumption is that we never (need to) change the generated code. If such need would rise, the obvious questions would then be: “what the code should look like?” If we can answer that question by writing the code then we update the generator (and perhaps DSL too) so we and others using that DSL can generate the code correctly.

When it comes to the fear of losing jobs, I think it is a primitive first reaction. Instead, I see that we have today more jobs for developers/programmers because we are using higher level languages. Our industry, and world in general, would look quite a different if we would be writing the code in machine code or assembler…

Indeed. If I was president of the any-world, what I would want to see is that I, as a domain expert, can transform my domain vision into a realised computational process just by working through a DSL. I don't want to have to take a DSL (say, an electronics schema), get some dev to understand what it means (they build their mental model), they transform that (even if using 'closer to the customer' methods like BDD) into tests and code in a high level language (such as C#/Java), for the compiler with its syntax-tree representation of a language (BNF coding an LL(1) or LALR grammar) to then convert to an intermediate format (like MSIL/byte-code) which then runs on top of a physical/virtual machine using the machine's native instruction set (say x86). There are too many transforming 'moving parts', each having the potential to introduce error or convolution into the delivery of each contextual representation.

As any-world president, I would like to transform the DSL to appropriate machine code. No mess in between, no fuss. It is just being aware of Occam's razor, especially if we consider code generation processes as a 'system'.

I think you are right in what you say about us having a lot of devs because of high level languages and despite me sometimes working as one, if MDD's took off, I see the role changing to one of being more domain expertise in the future. Maybe even absorbing programming in DSLs into different types of university course, for example (which stil happens). However, there is a lot of very heavyweight backing behind the idea of general high level languages, so how can this be broken? I can't see that happening any time soon worse luck.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.