Getting From Requirements to Code
Model-driven development provides the technology link between business requirements and production applications.
by Mike Sawicki
January 15, 2007
It's Monday morning, and you have just completed a grueling meeting with your supervisors, who had a difficult time understanding your explanations of how your development team will implement the latest business requirements. They really started to glaze over while reading the latest specification that was laced with too much of what they call jargon and references to industry standards that simply aren't of interest to them.
You need to do two things: 1) improve the communication and understanding of the project so that the complexity associated with the implementation of the technical aspects of the application are simplified; and 2) eliminate errors in construction that are because of a lack of understanding or possibly omission.
Let's face it. Given the variety of technology and design decisions that must be mastered, building enterprise-scale Java applications that deliver business value is difficult work. We are constantly challenged to solve complex business problems with very complex technology. Getting from requirements to code, and getting it correct is a challenge to many an overburdened development staff. The ideal solution to this problem is a development approach that improves communication and understanding, reduces technical complexity, and eliminates errors of omission or lack of expertise. These are exactly the problems model-driven development (MDD) solves.
Simply stated, MDD uses three simple steps to take you from requirement to code. The model, transform, and elaborate work cycle transforms visual models describing the structure, behaviors, and the necessary processes of your application into working systems (see Figure 1). It's not magic as you will see, but it's an innovative approach that contributes to better understanding simplification and consistency or quality of your application. There are three important aspects to MDD: abstraction, frameworks, and automation.
Business Value Delivery
Abstraction. As you might guess, models and modeling are central to the activities that lead to the development and deployment of good applications. These applications can deliver business value to your organization (by improving revenue, saving money, reducing cycle time, or improving customer satisfaction) and are reliable (by delivering correct information to the correct people when needed). Modeling aids development teams to improve their understanding of the problem to be solved and shields them from the complexity of repetitive coding tasks and component assembly. In addition to getting a really clear picture of the structure, behaviors, and processes of the application, abstractions improve understanding in these areas: reducing the complexity of the business aspects of the system, creating a separation of concerns, and managing both technical and functional architectures.
Frameworks. Having made your platform decision, there are some aspects of your system that can be addressed using frameworks. Frameworks reduce the complexity of the technology aspects of the system. For example, your decision is to build an application that makes use of a Web-based, front-end, and back-end Enterprise JavaBeans (EJB). This platform decision means that you must provide for the logic that organizes and exchanges data between the client interface and back-end components and the logic for data acquisition and maintenance.
For those client interface issues using a well-known open source framework like Apache Struts it might make sense for addressing the presentation layer mechanics. The model-view-controller (MVC) is a fairly popular (and tried) approach for managing the control flow of Web applications. Apache Struts has a number of features with which you can define the look and feel of particular fields, the flow of the Web application, the type of Web application generated, and so on.
Back to top