The end of programming as we know it? -

The end of programming as we know it?

“Model-driven development.” Just taste the words. These eight syllablesspell the change of an entire industry. The push is to reduce theimportance of code, and focus on what really matters: how the finalapplication is supposed to work, and making sure that you can build itreliably and according to requirements.

Model-driven development is part of a much grander concept calledMDA, which is short for Model-Driven Architecture and driven by theObject Management Group (OMG). MDA represents a conceptual frameworkfor an approach to model-driven development. However, while MDA in itsfull glory is not yet quite a reality, model-driven development isalready here.

Coincidentally, in the embedded software development there is anemerging need for a higher level modeling environment in which thedeveloper can determine if he has defined and characterized the systemcorrectly before writing the application code:designs are getting morecomplex, requiring more code; they operate increasingly in distributedcomputing environments; and they often require the use, and cooperationamong, multiple processors in a single system design and even within asingle system-on-chip.

No magic
If model-driven development is so good, why doesn't everyoneimmediately jump on this bandwagon? Well, first of all, this will notmagically solve all your problems; someone still has to work out thefunctionality of the system, and you won't find any tools that do thatfor you. What you will find are tools that make this work morestraightforward.

Second, you don't just change horses during a development project.There are ingrained development processes to contend with, and you haveto consider about the impact on existing applications. It should takeat least some consideration before switching over to a model-basedapproach, and normally you would only change your development approachfor new projects.

Third, you need to get buy-in from the people who are going to usethe tools. Developers tend to shy away from using model-drivendevelopment since “it is not programming.” The important message to getacross is that model-driven development allows them to focus on solvingthe significant design challenges and adding new, cool functionality,instead of spending most of their time fixing syntax errors, stoppingmemory leaks or sweating over low-level bugs.

Visual software engineering
The basis for model-driven development is models and the language usedto express the models. One of the main purposes of the model is toclose the gap between different stakeholders and establish a commonlanguage: requirements analysts, system engineers, software developers,and testers. Mind you, they will likely specialize in the differentparts of the language that suit them, but they will share somefundamental constructs and have a common understanding. A graphicalmodelling language such as UML* 2.0 simplifies communication and helpsbridge the complexity of the system.

What about programming? Is this no longer required? Well, givenenough information in a model, tools can generate most of or allrequired code. In many ways, this is similar to the paradigm shift thatoccurred when moving from assembly programming to C programming, whichwas met with a certain amount of skepticism.

What makes this new shift possible is that modeling languages arebecoming expressive enough to specify detailed system behavior. So, youdo still need to model or program, if you like the behavior of thesystem, but you can do it at a more abstract level.

Your star programmer, who has saved your company more times than youcan remember, may say: “It would be much quicker if I just programmedthis system for you.” And, he might be right.

But, and this is a big but, what is he supposed to program? Whocreated the specification? And would you want this information to existonly in his head? What happens if your competitor comes up with anoffer he can't refuse? And what about after delivery? Will the endcustomer be able to modify the implementation? Or even understand it?How easy will it be to maintain the system for future releases?

This brings us to another main purpose of model-driven development,which is to turn systems and software development into more of asystems and software engineering discipline. A system is not made upjust from the application, but also from the different parts that makeit possible to understand it. This includes requirements, roughsketches of the system, business models, and analysis models. All ofthese aspects need to evolve and be kept up-to-date during adevelopment project.

The role of UML 2.0
Not surprisingly, the Unified Modeling Language (UML) is the languageto be used for model-driven development. In June 2003, the OMG adopteda major new version of UML: UML 2.0. The new capabilities in UML 2.0for modeling the architecture of systems are among the most importantones in this context, and make it that much easier to build real-lifesystems of arbitrary complexity. This focus on scalability is prevalentin most other areas as well, including the diagrams used to modelbehavior, such as sequence diagrams and state machines.

Tool considerations
Tools implement model-driven development differently. Round-tripengineering is a poor man's substitute for not being able to capturebehaviour in a model, and suffers primarily from the fact that you tieyourself to a particular programming language, but also from the factthat it is an approach where the model tends to be forgotten in tightspots, such as when a project is running up against a deadline.

At the end of a project you then end up with a working application(hooray!) and a model that is practically useless (bummer*). So remindme again why you thought it important to do modeling?

Given the ability to specify system behavior directly in the model,this approach now seems hopelessly outdated. You can get automaticgeneration of code in any language on your chosen platform at the pressof a button, which means that portability is achieved at the modellevel.

You never change code directly; changes to your system are done tothe implementation in the model. There is still some way to go,however. Most tool vendors currently have their own language mappings,and for the MDA vision to succeed it is required to have standardizedmappings and profiles for different languages and platforms.

The good news is that the future is already happening. Model-drivendevelopment works, for real, and will change the way you developsystems.

Morgan Björkander is a consultant at Telelogic, where he has beenworking with modelingtools and processes for more than ten years with a focus ondeveloping distributed real-time systems. He has worked for severalyears within the OMG to further develop UML, and was actively involvedin the creation of UML 2.0.

Reader Response

Model-driven development will never become prevalent in embedded systems! Well, not whilst the industry relies mainly on unqualified software engineers (or is that star programmers?), who can just about hack a bit of cryptic C code.

Previous attempts to achieve model-driven development failed because the tools were incapable of representing system behaviour accurately. Also, and more crucially, the average softie was not properly trained and experienced in analysis and design methods (e.g. RTSASD). So, even if accurate modelling tools are now available, there remains a major obstacle.

To quote/misquote Grady Booch, “If you give an engineer a power-drill, and he uses it to hammer a nail, all he will achieve are sore fingers”.

–Martin Allen
United Kingdom

I like modeling. I am not so sure about MDA. Some things are easy to express in a model, some are not. Automating the code generation for state machines is a natural. The diagram syntax and semantics are well understood and mechanical.

Modeling other types of behavior is not so straight forward. A for loop can be written in UML2, but it is much easier in C, C++, or Java. Models are great for expressing relationships among modules, but not so great for defining behavior (except for state machines IMO).

I've worked with teams doing MDA and the models slowed them down. Everyone got very vested in their models. They were reluctant to run them and to integrate their work. That could have been the silo and review culture though. I don’t think that MDA is going to work by itself. Models could be part of the answer. I think practitioners will have to marry that technique with some rapid feedback techniques like test driven development. MDA won’t save the world. I don’t think that MDA is the “end to programming as we know it.” It is not the “next big thing.” I think MDA tool vendors to make a bunch of money off an industry that is suffering from poor performance.

Models are good for getting concepts across. A picture is worth a thousand words, but not a thousand lines of code. Models can effectively demonstrate how the different parts of the system interact. But for the details code seems to be a more concise and expressive medium.

–James Grenning
Director of Consulting
Object Mentor
Bartlett, IL

The author is definitely trying to convince developers to move toward model driven systems, with tools and code generators doing most of the programming based on the UML models.

However, he seems to miss the point that most with such code generating tools we are at the mercy of these code generators even for optimizing. In most resource critical embedded systems, where we need to optimize not only for the code size but also for the CPU consumption, we often need to optimize the assembly code generated by the cross compilers/assembles. Not all microcontrollers, microproessors, SoCs, DSPs have really reliable toolchains available. So with model driven systems, we will first have to optimize the generated C code and then the assembly code generated, thus beating the entire purpose of the development model.

Model based programming design is a good option only for systems where we have ample resources, but is an complete failure where we need proper optimization. Still we have a long way to go before we can have tools that can substitute the human brain completely.

–Hemant Mohan

MDA sounds like a solution intended for upper-level management individuals who don't want to accept that people develop embedded systems and would love to buy into the latest auto-code-cranking, staff-eliminating trend-based business idea.Fine, so there are folks embedding PC architecture or running 64-bit micros in their designs, good for them. Use MDA, whatever. Most of us don't operate at that level. The reason MDA exists is the reason it won't work–only as good as the weakest human mind.

Maybe tomorrow?

Dev Eng
South Africa

Looking back at the assembly to C shift it was inevitable that it would occur because of the obvious advantages. But at the time it wasn't obvious that C was the answer until it proved itself both in productivity and that it still allows you to use assembly language. Over time the amount of assembly in most code is reduced to a few key functions or interrupt wrappers.

I see the same thing with modeling. People will continute to debate it as an abstract concept until the right language or tools come out to make it obviously useful to real work. These tools will have to be a hybrid to easily use the advantages of modeling while still allowing traditional programming in key areas.

–Johnathan Vail
Waverley, MA

Developing correct and error free software has been the dream of the programmers. Modeling user requirements and developing executable specifications can go a long way to acquire the actual requirements, the customer has in mind. Present day modeling tools do offer this capability. Having developed correct models and auto-codegeneration (synthesis) by the tools can also eliminate a large number of design errors. Though the synthesis tools have to still evolve and thus one may have to still focus on efficiency of certain code segments and manipulate them like we are using assembly code in C programs.

–RS Shekhawat
Technical Consultant

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.