Model driven development is a top-down, traditional approach that has been around for a long time. Test Driven Development (TDD) is a bottom-up, new approach in the sense that it has picked up its value in the recent years. The focus of MDD as the name implies is on the models rather than on code that guides the development of software whereas focus of TDD is on the tests. There have been several changes to MDD since the beginning to deal with the changing environment and complexities raised by projects. TDD started as a part of extreme programming (XP) methodology and has gained popularity among many developers as a separate practice itself. Traditional, hard cored MDD developers are accustomed to developing software that seems more natural to them considering it to be an Engineering approach. TDD developers approach the problem in a totally different perspective concentrating on customer views of the system. There are advantages and disadvantages to both approaches. For a high quality software product that meets the goals of the organization, it is important to understand and apply the most suitable methodology while making certain trade-offs if necessary. The best approach to follow depends on several factors including the type of organization, type of project, and experience the developers have. This paper is aimed at explaining Model driven and Test Driven development along with case study and observations.

1. Model Driven Development or MDD.

Model can be precisely defined as “a description of a system from a particular perspective, omitting irrelevant detail so that the characteristics of interest are seen more clearly”. (Source: Patterns: Model-Driven Development Using IBM Rational Software Architect)

Consider an example in which there is a pressing business need such as automation of certain processes and understanding the data collected in the business. In this situation a Business exists and there are people who are performing certain business activities in certain way. These are the people who are thinking of having a tool or a software product to help them increase their productivity and their functionality. These people who are called Domain Experts or Subject Matter experts or Business Experts know what they want. However, they currently do not have any software product that will help them to meet their needs. In this situation Domain Experts are the driving force. They do things in a certain way and expect the software product developed for them meet their needs should also do things in that manner. However, they do not know how a new software product will look like and how it will help them to meet their needs. People who develop this software product understand the needs, but they may miss the intricacies of the desired end product. Building a MODEL will help alleviate this situation. A MODEL can be a diagram, an animation or a presentation. If the Software that has to be developed is very small or involves 1 or 2 people, then the process need not be so much structured, even though it helps. However, while developing a large product which will involve tens or hundreds of people having different expertise, model will help them to accomplish this easily.

A new product development building a Model is absolutely necessary. This is analogous to a civil Engineer creating a model of Building before it is actually built.

Model Driven Development (MDD) is a methodology that focuses on designing models at an abstract level without considering the implementation details that guide the development process, focusing on one part of the system to manage complexity. Models help to analyze the problem and visualize the process. Most commonly used language for this purpose is Unified Modeling Language (UML). It establishes certain vocabulary and structure so as to understand and communicate between various developers. Artifacts are produced from the models, so the models are machine-readable, which is an important aspect of MDD.

MDD is also called as “Model Driven Engineering”. An implementation of MDD is given by Object Management Group (OMG)’s Model Driven Architecture (MDA). Focus of MDA is on forward engineering, i.e. creating code from modeling diagrams. Apart from MDA, there are also other views of MDD such as Domain Oriented Programming, Agile Model Driven Development, etc.

MDA uses platform-independent model (PIM) to describe the system functionality as the first step. Platform Independent Model (PIM) is a generic way of representing the end view of the product without considering any technology or platforms going to be used. This model just transforms the Business requirements into a Model. This format does not contain any particular software code but shows the end state of the product in one of the Model development modes such as Diagrams, Flow Charts, and Animations etc. Based on the PIM and considering some economic conditions or availability, a proper platform is selected to develop the software. A model is then converted from PIM to platform specific model or PSM. . This contains software code at a higher level.

Platform is a loose word in this context. This can be referred to type of hardware, software, operating system, programming language or combination of any of these put together. That is why choosing a platform is related to economic viability also.

PSM can be thought of Developer’s model where as PIM can be thought of Domain Experts’ or End users’ model.

UML representation using IBM’s Rational Rose can be considered as PIM. Whereas, tools like IBM WebSphere Studio and Borland Together/J are used for developing PSM. In these, we have CODE VIEW and MODEL VIEW. These two views are synchronized together. When code is changed in Code View, it is reflected in the Model View and vice versa.

The models may contain fixed and variable data, business requirements, presentation elements (forms, reports). If one of these elements changes, they can be incorporated into the model to see the changes that occur due to interdependencies. Based on the affects, all the other depending code can be changed accordingly to accommodate these changes.

Models also describe what is called the Gap Analysis. Models are first built with an Ideal situation, but in reality the business processes and other aspects may be different. Therefore, the models will show the difference between the Real Life situation and the End State Ideal situations. This will help the Business units to define the changes in Business Practices or the Developers to meet the Business needs and bridge the gap. A well defined Structured System Analysis and Design (SSAD) is required to develop software based on Models. In this process, the design (Model) is taken as the basis to start with the development and as the development process is advanced, it is analyzed with the design and tested against the Model and re-visited to meet the requirements.

Hence, software development using MDD approach requires Domain (Business) experts, software developers, Team leaders and Integration experts. Someone should also be able to play a Liaison role to understand both sides of the table – Business side and Software side. This person will help each of the expert groups to understand the needs of other groups and will bridge the gap. Number of iterations in the project development process will be reduced drastically if this Liaison person has good knowledge and is an expert on both sides.

MDD is used with many development processes such as waterfall model, iterative model, spiral model, etc. In MDD approach, a model plays an important role and forms the basis or driving mechanism to develop a software product.

Test Driven Development:

Test Driven Development (TDD) started its roots in Extreme Programming (XP) approach. Later on, it became a popular method by itself. TDD was originally called “Test First Programming”. TDD can best be described in three words as “Red-Green-Refactor” (source: Kent Beck). Simple essence of TDD is to write tests before the code is written. First, unit tests are written from the requirements. These tests will definitely fail because the code for it has not been written. In order to write the tests, it is necessary for the developer to understand the requirements well. Then, code that implements the test cases is written. The code that is written should be just enough so that the tests pass, no more, no less. This means that no prediction about the future story must be made. Test driven approach is “then & there” approach. This means that code is written at that time from the user story requirements without making any assumptions or predictions about future. After writing the code, the tests are run and seen if they succeed. If they do, then programmer can be assured that the requirements were met. After this, a process called refactoring is done. This refers to improving the quality of code and removing any duplication in the code. If the design is changed for the better, the developer can be sure he is not breaking any functionality by running the tests again. This process is repeated for the test cases that follow. This process is shown as a flowchart below:

Source: http://en.wikipedia.org/wiki/Test-driven_development

There are different issues to consider in this process. Test cases are written taking small steps at a time, such as implementation of one method. It is important to know the size of the test case and when the test case exceeds its limit of functionality to test. A test case contains the following: condition that specifies the system’s state, an event that is to be tested, and finally system’s state after the event has occurred. Almost every language has associated tools for writing these tests. In general, they are XUnit tests available for each language. For example, java has JUnit, C++ has cppUnit, .Net has NUnit, etc.

The amount of designing that has to be done in TDD depends on developer. In Extreme Programming, no designing is done, directly jumping to test cases. However, some developers prefer to spend some time on design. Too much time should not be spent on the designs and deciding on that right amount of time to spend on it comes with experience.

As suggested by Dave Chaplin, it takes almost a year for a good developer to learn most of the techniques in TDD. He divides the learning process in three stages. First stage would take three months to master writing the tests correctly. TDD is a totally different approach to take in developing software and most developers believe that hardest part about it is getting used to it and thinking in that direction. It takes another six months to learn about Mock objects. Last would be to be able to draw UML diagrams in a TDD perspective. This takes about three months. Those that become familiar with TDD find many advantages in it. These advantages are explained later in the paper.

Pair programming is considered one of the best ways to develop a program using TDD. This is because another person can make sure you are going in right path. It is hard to make developers believe that this approach works. Also, management believes that it is a waste of money to make two people work on one feature while they can work on different features.

Through test driven development, the focus is on customer’s requirements. TDD is now part of many other methodologies, such as Scrum, Agile Unified Process (AUP), and Rational Unified Process (AUP). TDD gives confidence to the developer and produces enthusiasm as they can see parts of the program coming together when they run the tests and see them pass.

Case Study:

Results of TDD and MDD are seen more effective by example. Therefore, I consider a case in which a Software Engineering class was given a choice of either doing MDD or TDD project. The projects were done for the same problem using different approaches. It was a calendar program that consisted of certain functionalities to fulfill. For TDD people, six user stories were given one after another without knowing what the next user story is. MDD people were given a problem definition and they were to submit GUI, design, code, tests at regular intervals. The functionalities that had to be implemented included finding the following: next date, previous date, zodiac sign, day of the week, next Friday the 13th, number of shopping days left until Christmas. These were each given as a user stories to TDD people. From the results of these, the following statistics were made: