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.

Re-launch of Intelliun's Products group

After almost four years of focusing on professional services and helping several companies reap the benefits of Model Driven Development using The Virtual Enterprise (VE), Intelliun's Model Driven Development platform, I am excited that we are turning our attention back to the products group (Check out the related press release and the brand new web site). We are actively working on a new product release and a new product line offering. Watch this space and our web site for more exiting product announcements in the next few months.

Why MDD Works (Part 1)?

When I started Intelliun in 1999, I wanted to develop a radically new programming paradigm that allows a large number of developers to concurrently and independently build small applications. These applications can be quickly assembled to solve large and complex problems including business/enterprise, scientific and even mobile applications. In a matter of fact, the name Intelliun stood for INTELLIgent UNiverse, which is the environment to run intellets (i.e. small units of intelligence).

I remember I was reading "Crossing the Chasm" by Geoffrey A. Moore, and one of the things it warns against is starting a business that introduces a paradigm shift. I did agree with the rational, and I had another idea I also wanted to develop anyway. That idea was MDD (didn't use the term at the time though). I figured it would be much easier to promote and gain traction with MDD, but to my surprise, that was not the case.

Around the middle of 2000, at JavaOne, we introduced VE 2.0 beta, our first public release of The Virtual Enterprise. The conference was a blast! We got a lot of interest and intrigue and generated many leads…after all we were still at the height of the dot com bubble. Following up on those leads, however, was a different story.

Managers and business people loved us. We are demonstrating a technology that will radically cut their development time and cost, and help reduce their pain of hiring more highly scarce developers. Even ones that came up through the technical ladder were very impressed. I remember flying to NY with our VP of Sales and meeting with a director at Lockheed Martin that we were introduced to by a visitor to our booth at JavaOne. He brought in his chief architect, who was an older gentleman with many years of experience and the gray hair to prove it. I still remember the look on his face when he walked into the room.

Here this little kid that is going to tell us how to develop software better. After all, he has seen it all, from punch cards to CASE tools to this new Java thing. Nevertheless, he patiently sat down and went through the presentation and the demo. At the end of the demo, he was so impressed that he stood up and shook my hand with both hands. He saw enough to accept that it can be done and that it was different.

Developers, on the other hand, hated us. We got significant skepticism and push back, some because of job security and fear of change, but the majority was out of the lack of understanding. It seemed to them like a major leap from how they're developing applications, and even if it worked, it will only be able to handle simple applications.

What I would like to do in the next couple of entries is to explain MDD from my point of view and demonstrate how it is really an incremental improvement and not a radical departure on current software development practices.

Scaling Model Driven Development : Introduction

Demos for software tools usually involve some sort of toy project so you can get up to speed with the environment and concepts without having to worry about the details of a complex application. Unfortunately, it's exactly those complex details that rise up to bite you when you adopt a new tool or process and try to use it on a real-world project.

I'm going to do a series of postings about the stuff you don't always notice in the demos, and how it can make the difference between a big mess and a clean scalable model.

You know those scotch-taped-together wall-sized database diagrams with hundreds of tables and an impenetrable maze of relationships between them? Don't do that. There's nothing that says all your classes have to be on the same canvas. You can divide up analysis-level classes into packages exactly the same way you'd divide your Java implementation classes into packages. The familiar principle of reducing coupling between packages applies to models.

A totally standalone model has very low coupling but is otherwise pretty useless. After you divide up your model, you need to hook the pieces back together somehow. But if you just add back in direct relationships then you've simplified the visual design but not the underlying complexity.

In the next post in this series I'll talk about the kinds of coupling that should be allowed between pieces of the model, and the specific modeling artifacts that allow you to incrementally add complexity without breaking previous work. Hopefully it will all lead up to some posts of how to write reusable models, but it depends on how ambitious I'm feeling.

What is MDD?

Model Driven Development is a software development approach that raises the level of abstraction or method of programming from textual code to visual models, with a great emphasize on focusing the developer concerns on the problem domain and less on the underlying technologies.

The evolution of programming languages from machine languages (1GL) to assembly (2GL) to the ever evolving human-understandable languages (3GL) like Basic, COBOL, Pascal, C, C++, Java and C#, all focus on making programming simpler, quicker and easier to understand and maintain. This is accomplished by raising the level of abstraction by

• providing more semantically rich vocabularies to accomplish common and repetitive tasks (i.e. patterns),
• shifting programming from imperative to more declarative constructs (i.e. focusing on the what and less than on the how)

4GL’s took a detour by focusing on data-oriented (or database) applications and introduced artificial and often proprietary artifacts like forms and tables to capture these common and repetitive tasks and provide more declarative constructs. 4GL’s did very well on the presentation (user interface) and persistence (database) layers, but fell short on the application logic layer. They simply didn’t have a continuous paradigm that spans the different aspects of programming artifacts.

5GL, describing visual programming languages, had limited success in the past, which contributed to the misconceptions surrounding visual programming. The failures of 5GL had nothing to do with the visual aspect of 5GL and all to do with:

• the lack of a standard and ubiquitous modeling notation
• high complexity of the visual models
• proprietary architectures
• high price points (or vendor business models in general)
• limited availability of high-end computing horsepower required to operate
• heavy focus on code generation

Today, with the wide adoption of UML as a standard notation for expressing application logic, the convergence of software architectures and the great advancements in computing power and memory, the perfect storm is forming to make MDD the first mainstream 5GL.

Welcome to MDD

Welcome to the Model Driven Developer blog by Intelliun. After years of pushing the envelope in Model Driven Development (MDD), both as a technology vendor and a user of the technology, we felt that we've accumulated a wealth of experience and lessons that we would like to share with the greater development community.

Yes, you will hear about our company and products, but mostly this blog is about sharing ideas about MDD, Object-Oriented development, and Software Engineering in general. We will talk about processes, architectures and patterns; solve real-life problems using MDD; and discuss some of the misconceptions and skepticism surrounding MDD.

Combining the increased complexity in software development, increased demand for web services and applications, and the limited supply of developers, we believe that MDD is the next inevitable evolution in software development. We applied it to many projects and reaped the productivity rewards, worked out a lot of the kinks, and with your collaboration are going to push MDD into mainstream software development.

The development team here at Intelliun and I are very excited about this blog and we hope that you find it educational, informative and engaging.