Why MDD Works (Part 2)?

I know it’s been a little while since Part 1, but I didn’t foresee the “writers strike”...just kidding. It has been incredibly busy and exciting here at Intelliun, and time just flew by. Hopefully I will be able to block weekly time to add to this blog on a moving forward basis.

Picking up from where we left off, but before we get into the specifics of MDD, we need to take a closer look at programming, and analyze the types of code we usually write to develop a typical piece of software. If you strip out all of the standards, jargons and layers of complexity, you will find that code in any software falls into three categories: logic, interface and language/libraries.

Let me explain. Logic is “what” you wanted the software to do in the first place, regardless of technology or the “how”. This is usually where you have the value add (behind the software) and the innovation. However, it would make for useless software if it cannot interface with any external entities.

Interface code takes care of that problem. For example, if you want a human to interact with the logic, you have to build a user interface. If you need the logic to use another piece of software, you will have to build an interface, and so on.

Language and libraries are necessary to make your development easier. Instead of building the logic from scratch, you can use a set of libraries that save you time. Also, programming language specific syntax can save you a lot of work compared to programming in machine code. One statement can replace a page worth of machine code, and the higher level of programming language (the higher level of programming abstraction), the higher the productivity.

Here is a quick example to illustrate the above. To write a program in Java that would calculate the simple logic of adding two numbers, say 2 + 2, you would have to write:

public class TwoPlusTwo
  {
  public static void main( String args[] )
    {
    System.out.println( 2 + 2 );
    }
  }

Where the gray code is your language/library code, the blue code is the user interface code, and the red code is the original desired logic.
This should seem very obvious, but we don’t often think about it this way. It’s really important though so we can understand where we’re spending our programming time, and what we can change to make us more productive. Here are few opportunities for that:

• Raise the level of abstraction for the programming language focusing more on the what and not the how (declarative programming)
• Provide richer libraries and programming syntax
• Eliminate the need for interface code, maybe for 80% of the cases

Model-Driven Development capitalizes on these opportunities, keeping the focus on the logic itself. The different flavors of MDD, however, follow different approaches of getting there at varying degrees of success. Part 3 will examine Executable Models in more details and how it capitalizes on these opportunities.