Myths that give Model Driven Development a Bad Name

We are proud to introduce the first blog post from our new guest Blogger, Rafael Chaves, founder of Abstratt Technologies...

It seems that people that resist the idea of model-driven development (MDD) do so because they believe no tool can have the level of insight a programmer can. They are totally right about that last part. But that is far from being the point of MDD anyways. However, I think that unfortunate misconception is one of the main reasons MDD hasn’t caught on yet. Because of that, I thought it would be productive to explore this and other myths that give MDD a bad name.

Model-driven development myths

Model-driven development makes programmers redundant. MDD helps with the boring, repetitive work, leaving more time for programmers to focus on the intellectually challenging aspects. Programmers are still needed to model a solution, albeit using a more appropriate level of abstraction. And programmers are still needed to encode implementation strategies in the form of reusable code generation templates or model-driven runtime engines.

Model-driven development enables business analysts to develop software (a variation of the previous myth). The realm of business analysts is the problem space. They usually don’t have the skills required to devise a solution in software. Tools cannot bridge that gap. Unless the mapping between the problem space and solution space is really trivial (but then you wouldn’t want to do that kind of trivial job anyways, right?).

Model-driven development generates an initial version of the code that can be manually maintained from there on. That is not model-driven, it is model-started at most. Most of the benefits of MDD are missed unless models truly drive development.

Model-driven development involves round-trip engineering. In MDD, models are king, 3GL source code is object code, models are the source. The nice abstractions from the model-level map to several different implementation artifacts that capture some specific aspect of the original abstraction, combined with implementation-related aspects. That mapping is not without loss of information, so it is usually not reversible in a practical way, even less so if the codebase is manually maintained (and thus inherently inconsistent/ill-formed). More on this in this older post, pay attention to the comments as well.

Model-driven development is an all or nothing proposition. You use MDD where it is beneficial, combining with manually developed artifacts and components where appropriate. But avoid mixing manual written code with automatically generated code in the same artifact.

What is your opinion? Do you agree these are myths? Any other myths about MDD that give it a bad name that you have seen being thrown around?

Rafael has been writing code since he was in high school (20 yrs ago), and with time he discovered he was way more interested in how software was built than what the software actually did. For the last 8 years, he has been focusing on model-driven development, and as a result, he has built two products out of that: TextUML Toolkit, a UML modeling tool for Eclipse that uses a textual notation, and AlphaSimple, an online modeling environment that supports prototyping and code generation (currently in beta). Rafael is a keen blogger and also has a blog as he aims to stop people writing so much code... We collaborated because Objektum Solutions  are also on this quest.

Adding Flesh to the Bones – Primary Scenarios

Alex, one of our Systems Engineering trainers, continues to share his wisdom in another post in his series on Use Cases. 

Having defined the structure of the use case it is now time to describe the behaviours and interactions that occur during the execution of the use case; the flow of events if you like.

For this we will write use case scenarios to document the dialogue between the system and actors as the use case achieves its goal.

A scenario is an instance of a use case, i.e. it is one flow through the use case.  Each use case will have many possible paths through.  We first write an easy to understand description of a typical scenario in which the use case delivers the primary actors goal, i.e. the actor gets what he/she wants.  This main scenario is frequently known as the primary scenario.  All other paths through success and failure are described as extensions to the primary scenario, sometimes called alternate scenarios.

Let's bring in the ATM example.

Use case scenarios are normally captured using simple text.  Each scenario captures a specific path through the use case in a single flow of events that contains no branching. There is one primary scenario and several alternate scenarios documenting all of the relevant success and failure cases.

 It can be difficult to describe iterations, branching and/or concurrency using text, and therefore scenarios can be also described using sequence, state machine or activity diagrams. For now let us concentrate of the text. 

Textual scenarios are written as a sequence of goal-achieving actions by the various actors. Each action step will describe one of the following:

• An actor interaction         -              “Customer enters PIN” 
• A validation step              -              “System validate PIN code”
• An internal change           -              “System deducts amount from balance”

There are a number of useful guidelines for use case scenario action steps:

• Use simple grammar and vocabulary
• Write everything in the same tense
• Show clearly who is involved in each step
• Write from a consistent perspective
• Show the process moving forward
• Show the actor’s intent not how he does it
• Limit each scenario to between 3 and 11 action steps
• Number each action step

As with all modelling your first draft is unlikely to represent the final incarnation of the primary scenario and may need to be modified once the alternate scenarios have been written. That, however, is a discussion for another day.

National Technology Day

It's National Technology Day in India today! Fiona takes a look at why this day is so important... 

On May 11^th 1998 India set a precedent for the world of technology by declaring the date as the National Technology Day. The naming followed India’s rise on the international scene by becoming the sixth member of an elite group of countries in the ‘nuclear club’. The day is now celebrated annually across the country. In acknowledgment, an event is arranged by the Ministry of Science and Technology and includes a lecture session, a demonstration of new products released and a prestigious award ceremony which honours all those who have generated technological innovation. But how relevant is Technology Day is to the development of a country? And is technology important enough for other countries to adopt a similar celebration?

India’s rapid emergence onto the global economic market can be viewed in terms of their acceptance of technology as one of the fastest growing sectors, and a sector which we are all increasingly reliant upon. The growth in the IT industry over the past decade can be attributed to a highly skilled and motivated workforce. In particular, India has benefitted from Business Process Outsourcing. The Technology Day is celebrated as a symbol of the innate pursuit for scientific advancement and technological innovation and how this also leads to improvements in society and industry. It is without question that India recognised and seized the importance of technology resulting in the country becoming a major player in the global market. 

So do we all need to take heed of this lesson and declare our own appreciation of technology? The importance of technology for all countries is evident by observing the most important challenge for the future, the green energy technology race. China is currently second in the world as a producer of green energy. The Chinese government recognised that investing in green technologies is very much the future in financial terms. They have become a mass producer of solar cells and wind turbines not only for their own internal use, but also to export to the international markets which are under increasing pressure to invest heavily in green technologies. The US and UK are now realising that they need to increase and renew efforts to capture some of the green energy technology race to resist being left behind by the market. The competition is about to accelerate and an acknowledgement of the importance of technology such as a celebration National Technology Day can only help with awareness of the importance of scientific creativity and productiveness. 

At Objektum we have always embraced technological changes and we are continuingly looking for new ways to improve software development and plan to use our appreciation of technology to its full advantage. And why not celebrate it?!

The Truth of Motivation

Here's a video that we've been watching at Objektum Solutions HQ about motivation. We all found it fascinating (and fun to watch) and so we thought we'd share it with you. So, spare a little time to find out the truth about motivation...

 

Ada Connection 2011

This June, Objektum Solutions will be jumping on a plane and heading to the Scottish capital Edinburgh for Ada Connection which now combines the 16th International Conference on Reliable Software Technologies and Ada-Europe 2011. 

The conference programme spans across 5 days, 20 – 24 June 2011, and we will be there exhibiting on the Tuesday and Wednesday.   We will be giving demonstrations of our automatic software migration tool, the Legacy Bridge Suite, and there to answer any of your questions on migration, training and software development. We will also be giving a presentation called Making Life Test Better: Ada testing with UML on Wednesday 22^nd June at 15.30 – 16.00. 

So, come to Ada Connection and come and see us to discuss Ada programming and how we can help you manage obsolescence. (Keep an eye out for Derek Russell and Ajay Patel who will be our representatives on the ground at the conference)