Model-Driven Design promises to cut development time, reduce bugs, and increase maintainability. Pipe dreams? Maybe not according to Matthew Overington.

It has been an interesting few years for the software development industry as it’s moved through its big cost-cutting phase and is starting to grow up. There’s a need to build in more predictability, transparency and accountability into the software development process.

Modelling’s not new; it has been a crucial element in software design and development for some time, but companies are starting to come up with clever – and ambitious – plans to grow the use of models to help solve some age-old problems.

One of the issues with current coding methods that rely on modelling is that the model is only useful if it’s rigorously updated and maintained. An obsolete model is virtually useless, and in fact can be counter-productive in terms of being able to easily pinpoint the origin of bugs or develop in new features. What you think may be going on based on the model may not actually be the case in real code. What current trends promise to achieve is a framework that allows models to be transformed and used in many different ways, allowing developers to make more use of the resources available.

Malcolm Groves, Borland’s APAC director of product line sales, feels that Model Driven Development (MDD) is the next evolutionary step up from the RAD and OO schools that developed through the 90s. While RAD tools allowed developers to produce real, usable code extremely quickly, it also had a tendency to produce poor code and was often referred to as a spaghetti maker. Another camp said that RAD was plagued with inefficiencies and started to rely on UML models and hand-coding to produce well-structured maintainable code. This achieved top-notch results, but at the expense of speed. MDD promises to bridge the gap between these two to allow developers to produce quality code quickly that’s also easy to maintain.

In RAD, the architecture generally drives the development: the structure of the database will largely dictate the form of the application. Using MDD, the developer is free to move from database back to code, from code to database, or anywhere in-between. With ECO III due later this year, Borland will offer MDD for C#, and Delphi .NET.

The company is trying to make MDD the next step to RAD, and Groves argues that an increased reliance on modelling is a pragmatic approach. Developers can work quickly in high levels of abstraction without worrying about the underlying plumbing holding their apps together. Model Driven Architecture (MDA) raises this abstraction level again, which allows workers to focus on business logic.

Rational takes a similar view to MDD, after playing such a significant role in defining UML. Rational has been playing in this space since around 1990 with the introduction of Rational Rose and later Rational XDE. The Eclipse project has moved over to open source, and its easy to argue that Rational is leading this space.

According to Davyd Norris, Senior pre-sales architect with Rational, IBM Software, the development of more graphical tools for code generation was always a natural evolution. -MDD is about moving through abstraction levels; it allows different people with different experience and ideas to work together on a project at whatever layer of abstraction they’re most comfortable with.”

Norris argues that enterprise architecture needs an agile approach to UML, -there’s a large shift towards companies being more agile. Families of applications are developed from higher-level models.”

To Norris, every layer of abstraction, from the code at the lowest level to the model at the highest, is a part of the model. He scoffs at the notion that the code is the model, as there are too many things about enterprise architecture that you simply can’t express in code. It’s possible, using transformation tools, to move up and down those layers of extraction, but they’re all equally valuable pieces of the puzzle.

Microsoft takes a slightly different stance, and refers to the OMG’s official definition of MDA as being a way to develop applications in UML. Microsoft’s approach doesn’t try to use UML for model driven development, instead relying on domain specific languages (DSLs), which are designed to support specific tasks. Microsoft argues that UML is useful for sketching but is a poor choice for source language because of limitations in addressability, extensibility and consistency.

According to Jack Greenfield, Architect for Enterprise Frameworks and Tools at Microsoft, Redmond’s approach employs models as -software development source artefacts that can be manipulated computationally for such purposes as validation, analysis, traceability and code generation”. The models aren’t used for documentation.


While Rational and Borland are spearheading this movement, a lot of smaller development houses are equally enthusiastic and are jumping on board with strong toolsets.

Take Embarcadero Technologies for example. The software company offers model-driven data management solutions that can share information across the suite. Models can be created and then understood by everyone along the development chain. The company’s arsenal includes a model driven application for analysing database apps (ER/Studio), a visual modeller and data flow designer (DT/Studio), and a model-driven analysis, design and development environment called Describe. All three apps are designed to interact, and it’s possible to take data models from ER/Studio, bring them into Describe and build complete application models. From here, it’s possible to generate code directly from the models.

Philip Ball, APAC Regional Director for Embarcadero Technologies, says that the current trend is solving an age-old development issue that he describes as, -the spaghetti ball effect, where everything’s connected to everything else. You pull on a piece of code and you have no idea what effects that may have elsewhere in your application.”

He says that strong use and adherence to models allows more transparency in the development process, which speeds up development time and reduces the possible impacts of bugs.

According to Ball, MDD is part of a much larger overall push to rely more heavily on metadata in development. -There’s a need to store metadata so that developers can get a more holistic view of not only their application, but where it fits into the bigger picture in an entire software lifecycle.”

With a massive growth in data in recent years, Ball feels that the problem is increasingly becoming how to lever that data; how to stay on top of it, retain a holistic view, and be able to use it effectively. In Ball’s estimation, knowledge workers can spend up to spend fifty percent of their time just understanding data before they can sit down and start to work with it: -if they have access to models and metadata, they can see where the data fits into the bigger picture and cut this down.”

Rational’s Davyd Norris also highlights benefits stretching right through a software lifecycle. Software development doesn’t end at testing. Deployment, maintenance and documentation are all equally important factors that are often left out of the costings for a project. Rational is heading towards relying on models to handle the entire software lifecycle. An ambitious project, yes, but Rational has been working towards this end for a while now.

The popularisation of MDD and even MDA is a multi-pronged attack that provides benefits for everyone along the chain of software development, from the DB engineers through to the architects and the developers on the ground floor. It allows project managers more transparency to monitor and develop their apps, it allows the developers themselves to roll out code changes more quickly, and it allows DB engineers to play a more active role in code generation. Developers are able to bridge the gap between pure tech and the business layer. -The line between modelling and development is blurring”, says Philip Ball.

Real World

Developers on the ground are starting to get behind the movement, too. Dick Walker, head of Granite Solutions, is a Delphi developer and ISV that’s used MDD to speed the development of a Ski Hire shop application over the last 15 months. The 3-tier WinForms business application handles bookings, packages, payments, and ski equipment. He uses .NET remoting to communicate between client applications and the application server and has built the application using Borland’s ECO tool. Walker can see MDD playing a major role in future development. He says that the skill in building apps is in, -identifying the objects involved in the system and their relationships.” According to Walker, writing class definitions and methods opens up areas where mistakes can creep into the code, so automating the process has sped his development time.

It’s not all roses, though. Initially Walker had some problems with C#Builder and ECO crashing in early versions and he found himself bumping up against ECO’s limitations. He describes a -paradigm shift when developing an MDD application, and moving away from RAD, and DB bound objects”. Now that he’s past the learning curve, though, he isn’t going back. -MDD is no toy; you can create real applications with it today.” He says that as soon as tools vendors catch up, the sky will be the limit.

Magic Wand?

With all this rhetoric flying around, it’s easy to get sucked in by the hype and come up believing that MDD is the answer to all of today’s programming issues. Unfortunately, it’s far from a one-size fits-all solution that will whiten teeth and reduce hair loss. At the end of the day, there’s no substitute for experienced developers to sit down and write good code. The growth and movement around solid modelling tools is complementary to writing quality code, not a substitute.

Extensive use of MDD can help developers deliver on their reporting requirements, integrate applications during mergers and acquisitions, and when the project’s said and done, produce documentation. Essentially the whole movement around Model Driven Development provides increased power to lever your assets and to do more with less.

It’s unrealistic to expect to define an application in UML, press a magic button and expect code to pop out the other end. Developers will still have to roll up their sleeves and get elbow-deep in source to produce elegant and efficient applications. Philip Ball sums it up perfectly when he says that MDD is, -not automating good design methodology”. Rather, it’s just bringing everyone involved in a development project together onto the same page, allowing everyone to work at whatever level they feel comfortable.