More than three decades after its start, model-driven methodologies are continuing to gain acceptance and adopters among developers. Here’s what model-driven really is – and what it can do for you.
Originally associated with the 4GL movement of the 1990s, model-driven development (MDD, MDSD for “model-driven software development,” or MDE for “model-driven engineering”) is a methodology for creating applications based on high-level abstraction and automation, rather than low-level manual coding. In essence, the programmer serves as an architect, focused on conceptualizing and building models that contain elements representing multiple lines of code.
Code less. Do more
The most commonly cited benefit of MDD is increased programmer productivity. This is a very real phenomenon – and it’s a direct result of MDD allowing high-level workers to focus their energies on high-level work, rather than simply writing code all day.
At a very basic level, developers spend their time producing something. If they write a line of code in a 3GL, they’ve, well, written a line of code. By contrast, in MDD, developers create objects that represent the functionality of many lines of code; then the code is either generated, or the object itself is executed. Additionally, many basic functions – SQL database connectivity, for instance – are often capable of being fully automated by MDD platforms. They happen based on the design of the model, rather than having to be implemented piece-by-piece by the developer.
Here’s a real-world example. The famed Java Pet Store application contains 14,273 lines of code. Created in response to Pet Store, the highly optimized .NET Pet Shop is made up of 3,484 lines of code. By contrast, Uniface Pet Plaza – developed in the leading MDD technology – contains just 1,959 lines of code, contained in highly secure and consistent repositories rather than error-prone plain text files. One clear valuable example is that all CRUD functionality is implemented automatically in the MDD app further reducing developer workload and increasing productivity. They’re not just writing code ... they’re creating business functionality.
Fewer errors, caught consistently
In development, errors happen – and that’s never going to change.
Here’s the thing about errors: No matter the skill of the programmer involved, some will always happen. That means fewer lines of code (as described on Page 3) equals fewer errors. Simple, right?
Of course, that’s not the only quality-driven consequence of low- code app development. Less code to write means faster development times. And less time in development means more time for QA and QC. Additionally, since most technical factors are handled automatically, rather than by hand, functionality and UX become the most important factors to test rather than arcane back-end pieces of the application.
“With MDD, the focus is not on writing code but on designing a good model. Having said that, if the model is poorly designed you can quickly go back and improve it – it’s not like .NET where if your application is poorly written you have no choice but to rewrite code.”
Phillip Beal, Professional .NET Developer
Business + technology = succes
In traditional application development, a business case and basic project plan are created by non-technical team members, then turned over to IT and/or programming staff to execute. Obviously, in these cases, the chances for errors in translation and expectations (“What do you mean it can’t do that?”) are great.
With MDD, things are different. Because the actual developmentprocess is made up of high-level tasks, the initial conceptualization and prototyping phases are essentially part of development. And because iterations can occur so quickly, domain experts and business users can stay intimately involved with the project from Day 1 until post-launch; there’s never a “black box” period where the IT team is strictly focused on coding. Prototype and production are closer together resulting in improved productivity. Non-technical team members can see – and interpret – what’s happening, every day. If something looks wrong, a flag can be raised long before wasted cycles are spun. Plus, if business requirements change, the application can be modified quickly and easily.
Today. Tomorrow. Next year
With model-driven development, tomorrow’s inevitable changes in technology can be responded to quickly without major re-coding efforts. In fact, in most cases, your objects and models will remain the same regardless of the technology with which they’re working.
In MDD, code is generated or models are interpreted automatically; individual lines of code are rarely written by a developer. So when a model-driven application needs to work in a new technology infrastructure, all that needs to be changed is high-level CRUD in the model rather than specific pieces of code. That means the app will always support modern standards – today, tomorrow and even decades into the future. It also means that legacy hardware and systems can remain in use even as core solutions are updated to meet current standards.
“With Java there is a lot of experimenting in the development process. You don’t get that sort of disappointment with MDD, because things happen smoothly and you end up getting what you expect to get.”
Georges Herzet, Professional Java Developer
Model-driven development tools, like Uniface’s advanced technology, allow programmers and developers to do more, create cleaner applications, work toward more well-defined business goals and ensure long-term stability of their solutions.
While MDD tools will never fully replace traditional development
tools, their benefits make them useful for a wide variety of enterprise applications, whether deployed as client/server apps, on the web or on mobile.