Developer Product Briefs

Getting From Requirements to Code

IT faces challenges in solving complex business problems with technology. Find out how MDD offers a solution to improve communication, reduce technical complexity, and eliminate errors.

• By Mike Sawicki
• 01/15/2007

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.

This approach helps simplify much of the implementation of these technical aspects. The mechanics of the MVC can be applied using automated technology transformations, thereby simplifying the implementation. A similar approach can be employed for implementing back-end components with a persistency framework like EJB or other approaches like Hibernate.

Automation. The main challenge with models is that for many organizations they are considered not much more than an artistic venture and do not directly contribute to code. That is, it is difficult to see how a Unified Modeling Language (UML) class model or a use case directly relates to the code artifacts that we need to build. Oftentimes, developers have real difficulty synchronizing the code they have written with the models they've built.

In this case, the model becomes outdated or out of synch with the code because there is no link from the model to the code. Soft linkage of models to the code by using automated transformations makes modeling an active part of the development process. Automated transformations, then, in addition to providing the linkage, are the real strength behind automation. Automated transformations help us to eliminate errors of omission or lack of knowledge; enforce best practices for architecture and coding as it relates to the problem domain; accelerate, with high predictability, the steps from requirements to design architecture to code; and deliver business value consistently faster and continuously.

Abstractions, frameworks, and automation are the essence of MDD. We build models and use frameworks to visualize and communicate the desired structure and behavior of our system. We use automated transformations to ensure quality, improve delivery capacity, and manage risk.

Models, Frameworks, and Transformations
The domain model, application model, and code represent different layers of abstraction (see Figure 2). The domain model is a technology-agnostic representation of the system. It describes the classes, behaviors, and processes that comprise the application. The application model represents the technology-specific architecture with which we will implement our system, and the code—well, this is the end game. These are the objects that we build to implement our system.

Each of the different layers is expressed in a different fashion. Our domain models, for example, can be expressed in the form of UML diagrams. Class diagrams provide a serviceable picture of structure and the relationships among the entities. Use cases convey information regarding the behaviors or process tasks that represent specific requirements in our systems.

The application model represents the platform architecture that we employ. If we make a decision that the implementation platform will be Web-based Java, we will likely need to follow the rules for building and deploying this type of application. We are a bit closer to code, but not quite there. At the application layer we might use UML diagrams still to represent architecture decisions, but we are not yet to the code.

Getting from requirements to business model to application model to code requires a series of translations. Naturally, we can do these translations manually, but this approach is where errors or omissions can infect the application. For productivity and quality purposes an automated approach makes better sense—where automated transformations come into play.

The technology and the implementation transformations are the mappings that automate the domain model-to-application model and the application model-to-code translations. In other words, the technology and implementation transformations take you from a semantically rich, yet nontechnical, level of abstraction in the domain to a specific platform architecture and then to the syntactically precise code implementation.

A technology pattern describes how one model can be mapped to another model. Technology patterns can simplify a couple of tasks for you. First, it can define rules that map the structure and behavior of the application (DomainClasses to EJBEntityComponents and DomainOperations to BusinessMethods) depending on the granularity required. Second, these mappings can create or update the presentation, business logic, and database model elements required for a specific technology platform (like J2EE) based on the object definition(s) found in the domain model.

Implementation patterns map the application model to the code. Implementation transformations are not a new concept. They are an abstraction of many of the practices of developers. In completing a development task, a developer will oftentimes reuse or reapply what was learned from a previously successful project, relevant standards, or best practices. Implementation patterns collect this information, which can be reused. You capture this knowledge in a code template that can be used with a code generator. In a simple quick step you can apply this knowledge, practice, and code reuse that you have captured in your implementation pattern. Patterns are implemented in a variety of languages or a specialized pattern language.

MDD means that we model what we want to build. We use automated transformations to implement solution frameworks for translation from business model to application model and from application model to the code.

Modeling visually captures important facts about the business requirements and provides a vehicle by which information can be viewed and exchanged between the business stakeholders and the development teams. Models provide a clearer picture of what the business needs and what IT needs to build. The automated transformations of business model to application model and application model to code improves what has previously been a series of manual processes and helps align the end results with best practice design and coding standards in the form of frameworks in mind. MDD makes those Monday morning meetings a bit easier to take.