"Model-driven development." Just taste the words. These eight syllables
spell the change of an entire industry. The push is to reduce the
importance of code, and focus on what really matters: how the final
application is supposed to work, and making sure that you can build it
reliably and according to requirements.
Model-driven development is part of a much grander concept called
MDA, which is short for Model-Driven Architecture and driven by the
Object Management Group (OMG). MDA represents a conceptual framework
for an approach to model-driven development. However, while MDA in its
full glory is not yet quite a reality, model-driven development is
already here.
Coincidentally, in the embedded software development there is an
emerging need for a higher level modeling environment in which the
developer can determine if he has defined and characterized the system
correctly before writing the application code:designs are getting more
complex, requiring more code; they operate increasingly in distributed
computing environments; and they often require the use, and cooperation
among, multiple processors in a single system design and even within a
single system-on-chip.
No magic
If model-driven development is so good, why doesn't everyone
immediately jump on this bandwagon? Well, first of all, this will not
magically solve all your problems; someone still has to work out the
functionality of the system, and you won't find any tools that do that
for you. What you will find are tools that make this work more
straightforward.
Second, you don't just change horses during a development project.
There are ingrained development processes to contend with, and you have
to consider about the impact on existing applications. It should take
at least some consideration before switching over to a model-based
approach, and normally you would only change your development approach
for new projects.
Third, you need to get buy-in from the people who are going to use
the tools. Developers tend to shy away from using model-driven
development since "it is not programming." The important message to get
across is that model-driven development allows them to focus on solving
the significant design challenges and adding new, cool functionality,
instead of spending most of their time fixing syntax errors, stopping
memory leaks or sweating over low-level bugs.
Visual software engineering
The basis for model-driven development is models and the language used
to express the models. One of the main purposes of the model is to
close the gap between different stakeholders and establish a common
language: requirements analysts, system engineers, software developers,
and testers. Mind you, they will likely specialize in the different
parts of the language that suit them, but they will share some
fundamental constructs and have a common understanding. A graphical
modelling language such as UML* 2.0 simplifies communication and helps
bridge the complexity of the system.
What about programming? Is this no longer required? Well, given
enough information in a model, tools can generate most of or all
required code. In many ways, this is similar to the paradigm shift that
occurred when moving from assembly programming to C programming, which
was met with a certain amount of skepticism.
What makes this new shift possible is that modeling languages are
becoming expressive enough to specify detailed system behavior. So, you
do still need to model or program, if you like the behavior of the
system, but you can do it at a more abstract level.
Your star programmer, who has saved your company more times than you
can remember, may say: "It would be much quicker if I just programmed
this system for you." And, he might be right.
But, and this is a big but, what is he supposed to program? Who
created the specification? And would you want this information to exist
only in his head? What happens if your competitor comes up with an
offer he can't refuse? And what about after delivery? Will the end
customer 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 a
systems and software engineering discipline. A system is not made up
just from the application, but also from the different parts that make
it possible to understand it. This includes requirements, rough
sketches of the system, business models, and analysis models. All of
these aspects need to evolve and be kept up-to-date during a
development project.
The role of UML 2.0
Not surprisingly, the Unified Modeling Language (UML) is the language
to be used for model-driven development. In June 2003, the OMG adopted
a major new version of UML: UML 2.0. The new capabilities in UML 2.0
for modeling the architecture of systems are among the most important
ones in this context, and make it that much easier to build real-life
systems of arbitrary complexity. This focus on scalability is prevalent
in most other areas as well, including the diagrams used to model
behavior, such as sequence diagrams and state machines.
Tool considerations
Tools implement model-driven development differently. Round-trip
engineering is a poor man's substitute for not being able to capture
behaviour in a model, and suffers primarily from the fact that you tie
yourself to a particular programming language, but also from the fact
that it is an approach where the model tends to be forgotten in tight
spots, 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 remind
me 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 automatic
generation of code in any language on your chosen platform at the press
of a button, which means that portability is achieved at the model
level.
You never change code directly; changes to your system are done to
the 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 standardized
mappings and profiles for different languages and platforms.
The good news is that the future is already happening. Model-driven
development works, for real, and will change the way you develop
systems.
Morgan Björkander is a consultant at Telelogic, where he has been
working with modeling
tools and processes for more than ten years with a focus on
developing distributed real-time systems. He has worked for several
years within the OMG to further develop UML, and was actively involved
in 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
Japan
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?
--Jonathan
Dev Eng
SKEG
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
India
