 | Level: Intermediate Larry Yusuf (yusuf@uk.ibm.com), Solution Designer, IBM
Mandy Chessell (mandy_chessell@uk.ibm.com), Senior Technical Staff Member, IBM
Dr. Tracy Gardner (tgardner@uk.ibm.com), Solution Architect, IBM
24 Jan 2006 Are you a lead architect or project manager trying to increase the business value of your IT system? If you are, this article can help. It explains the business drivers that influence modern IT development and introduces you to model-driven development (MDD). MDD is an improvement on mainstream software development practices and enables your IT system to be more responsive to business drivers. Learn about the MDD approach and how you can apply it to achieve the maximum business value and reduce the cost of solution development. With MDD you can improve the consistency and quality of solutions by automating implementation patterns with transforms and eliminate repetitive, low-level development work.
Know your current business environment
IT development does not take place in isolation. The purpose of IT is to facilitate the operations of a business, which means the needs of the business environment drive the way we develop IT. Table 1 shows some current business drivers.
Table 1. Current business drivers
| Driver | Description |
|---|
| The on demand business | As businesses are expected to be more adaptable and flexible, so too are the IT systems that enable them. | | Business relevance | There is a strong focus on IT departments to deliver business value. Software must be business relevant. Miscommunication between business and IT people can lead to projects that are successful from an IT-delivery viewpoint, but deemed business failures. | | Cost control | The days of investing in IT based on the strength of its promises are long gone. IT departments now operate under strong budget constraints and are expected to demonstrate value for money. | | Increasing complexity | Software systems continue to increase in scale and complexity to meet business needs. Techniques that work well for small-scale development do not necessarily scale to enterprise-wide initiatives. | | Skills availability | The sophistication of today's IT platforms means that specialists' knowledge is required to deliver software. Many organizations struggle to find sufficient skilled professionals to support their development. Projects often depend on key individuals and suffer significantly if the individuals leave. | | Changing middleware environment | Today's applications are deployed to a huge variety of middleware platforms, and the rate of change in platform technology is showing no sign of slowing up. Businesses want to take advantage of advances in middleware but don't want to repeatedly rewrite their applications. |
 |
Understand the model-driven approach to software development
Model-driven development (MDD) is a style of software development where the primary software artifacts are models from which code and other artifacts are generated according to best practices. A model is a description of a system from a particular perspective, omitting irrelevant detail so the characteristics of interest are seen more clearly. For example, a structural engineer creates a model of a building that is suitable for determining its load-bearing characteristics.
In MDD, we introduce the additional criteria that a model must be machine-readable. For example, we must be able to access the content of the model in an automated manner. Machine-readability of models is a prerequisite for being able to generate artifacts. A diagram on a white board may meet the other criteria for being a model. However, until we capture it in a machine-readable manner, we cannot use it within an MDD tool chain.
Software models are typically expressed in Unified Modeling Language (UML). UML is a language for specifying, visualizing, and documenting software systems. It provides a visual notation and underlying semantics for software models. UML also has a standard machine-readable serialization format that enables automation.
Software models hide technical implementation details so a system can be designed using concepts from the application domain. Application design is typically carried out using a UML modeling tool such as IBM Rational® Software Architect, using concepts relevant to the application domain. For example, when working in the enterprise integration domain, we would start by modeling the application design using concepts such as message, proxy, and adapter. Later, we can refine the software model and design the details of its components.
Models as sketches and blueprints
Using models to design software is a well-established practice (though certainly not ubiquitous). Currently, models are used mostly as sketches that informally convey some aspect of a system or they can be used as blueprints to describe a detailed design that you manually implement.
Using models as documentation and specification is valuable, but it requires strict discipline to ensure models are kept up to date as implementation progresses. More often than not, time constraints mean that the implementation is updated without first changing the models. Inaccurate models can be more harmful than no models at all.
In this article, we use the term MDD to describe approaches where automation generates artifacts from models.
Enable automation using precise models
In MDD, models are used not just as sketches or blueprints, but as primary artifacts from which efficient implementations are generated by the application of transformations. In MDD, application domain-oriented models are the primary focus when developing new software components. Code and other target domain artifacts are generated using transformations designed with input from both modeling experts and target domain experts.
MDD has the potential to greatly reduce the cost of solution development and improve the consistency and quality of solutions. It does this by automating implementation patterns with transforms, which eliminates repetitive low-level development work. Rather than repeatedly applying technical expertise manually when building solution artifacts, the expertise is encoded directly in transformations, offering the advantages of both consistency and maintainability. A modified transformation is reapplied rapidly to generate solution artifacts that reflect a change to the implementation architecture.
MDD shifts the emphasis of application development away from the platform, letting developers with application expertise design applications without concern for the platform-level concepts that are the province of developers with platform expertise. Platform expertise is captured directly in transformations rather than being documented as project guidelines or worse, being rediscovered many times during a project. Likewise, decisions about the implementation architecture are directly encoded in the transformations rather than documented as architectural decisions.
Depending on the situation, suitable off-the-shelf transformations are available for use directly or as a basis for extension. Alternatively, you can build custom transformations for a project.
Not just code
The generation of code and other platform artifacts is an important part of MDD, but MDD-style automation can go much further. A software development project needs to produce many non-code artifacts, several of which are completely or partially derivable from models. The following list gives some common examples of artifacts that are generated from models, but you can probably think of others.
- Documentation
- In organizations that follow a formal development approach, producing documentation takes a significant amount of development effort. Keeping documentation in line with the implementation is notoriously difficult. When using MDD, documents are generated from models ensuring consistency, and making information available within the models that developers are working with daily, rather than in documents that are difficult to navigate. Tools such as Rational SoDA and Rational Software Architect Report Generator generate documentation, or documentation is generated by a transformation.
- Test artifacts
- It is possible to generate basic test harnesses, such as using JUnit, from the information contained in software models. If additional test-specific modeling is carried out (for example, using the UML Profile for Testing), then complete test implementations are generated. Model-based testing is a discipline that is concerned with generating tests from models.
- Build and deployment scripts
- Using their expertise, infrastructure architects can create transformations to generate build and deployment scripts.
- Other models
- A system involves many interdependent models at different levels of abstraction (analysis, design, implementation), representing different parts of the system (UI, database, business logic, system administration), different concerns (security, performance, and resilience), or different tasks (testing, deployment modeling). In many cases it is possible to partially generate one model from another, for example moving from an analysis model to a design model, or from an application model to a test model.
- Pattern application
- Patterns capture best practice solutions to recurring problems. Patterns specify characteristics of model elements and relationships between those elements. You can automate patterns so that new elements are created, and existing elements are modified to conform to the pattern, then the pattern is applied to a model.
In this article, we include all of these techniques, in addition to the generation of code, with MDD.
Assessing the tasks for an MDD project
MDD has a profound affect on the way we build business application software. It captures the expertise and decisions of your top technical people, making them available to the rest of the team through tooling customized for the project's needs. The cost of development, and to test the business software, is significantly reduced since much of the low-level coding work is automated. The number of errors is reduced, and there's increased consistency in the way work is accomplished.
MDD does, however, create a different aspect for a project, requiring the management of one project inside another. The inner project covers the development of MDD tools that the development team building the business application in the outer project can use. Typically, one business application will be identified as the first project to be built with the MDD tooling to focus requirements and enable the approach to be fine-tuned. Once developed, the MDD tooling can be used to build many business applications.
With two projects, it is important to organize and plan carefully, especially at the start. On top of the usual issues associated with development projects, there is a requirement to manage an additional set of internal dependencies. The MDD tooling needs must be identified and developed before the application developers need it. The task flows for the two projects are interlocked to ensure that the deliveries from the MDD tooling project are timely.
Figure 1 shows the flow of tasks in an MDD project. The shaded tasks would be performed in a traditional project. Tasks in white are the additional tasks that build the MDD tooling for a specific project.
Figure 1. Steps to develop MDD tooling
You can develop all of the tooling in advance of the business application development, or take a more iterative "just-in-time" approach. Either way, it is important to allow additional time during the business application project to develop enhancements that might be identified as the tooling is used for the first time.
Tasks
The initial tasks for developing the MDD tooling occur in any traditional development approach. Your solution architect performs them, and defines the high-level structure of the business application.
- Create solution architecture
- Define the conceptual structure of the business application. This is expressed as a number of architectural styles that the developers will adopt when building the business application.
- Define runtime environments
- Define the runtime environments in which the business application should run. This covers all test environments, including unit test and final production environment.
Once these first two tasks are complete, the solution architect has a good understanding of what needs to be developed for the business application. At this point, the MDD-specific tasks can start:
- Identify common patterns and standards
- The solution architect identifies the repeating patterns within the business application. These patterns often occur either because of the consistent use of an architectural style, or because of the requirements of the runtime platforms. The common patterns can be described using the standard way for the organization's development process.
- Identify existing MDD assets for reuse
- The solution architect compares the common patterns they identified with existing MDD assets, making any necessary small adjustment to their architecture to exploit what is already available. Existing MDD assets could come from previous MDD projects, or from standard tools and packages.
- Define design model
- The solution architect defines the modeling conventions that developers must follow when developing a business application. Typically the UML will be chosen as the starting point, and the solution architect will define precisely how UML is to be used to capture designs. The solution architect needs to understand the different types of UML diagrams (such as class diagrams, collaboration diagrams, activity diagrams) and when it is appropriate to use each one.
- Identify a runtime-independent model for components
- This task creates the definition of a UML model that specifies the components for the business application in a runtime-independent manner. It can be carried out either by the solution architect or by an experienced application developer who understands all of the runtime environments.
- Produce sample artifacts
- An application programmer hand-codes the resulting business application artifacts for a typical scenario. These sample artifacts act as the blueprint for the MDD templates and transformations. This task should be performed by your best application programmer.
- Define tool chain
- This task identifies the MDD tools that need to be developed for the project. It is performed by someone skilled in the development of MDD tooling. Once complete, you can create a detailed plan of the effort required to build the MDD tooling.
The next five tasks build the MDD tooling:
- Extract templates from sample artifacts
- An MDD tooling developer reviews the sample artifacts and uses them as a basis for developing a template for each artifact to be generated. The template contains the code that is the same for every instance of the generated artifact. The MDD tooling developer needs skills in the language and format of the generated artifact. It also contains markers that the transformation uses to insert the specific parts of the artifact based on the content of a model.
- Design, code, test transformations and patterns
- This task requires Java programming skills. For each transformation or pattern, the MDD tooling developer needs to write the Java code that reads a UML2 model, then either update the model or fill in the appropriate gaps in a template to generate a new artifact.
- Package MDD tooling
- The MDD tooling must be packaged into a form that can be installed into the workbench of each or your application developers. There are several options:
- Put all the files into a zip file with written instructions on how to unpack it
- Use standard Eclipse plug-in management
- Use a reusable asset (RAS) repository
- Provide a full download Web site
The choice depends on the number of people who are likely to install the MDD tooling. A reasonable approach is to focus on supporting your initial set of application developers, then upgrade the packaging mechanism as needed when more people start to use it.
- Produce documentation and education for application developers
- A solution architect or technical writer produces a description of how an application developer builds a model and then selects the right transformation to generate the correct artifacts.
- Validate tool chain using key scenarios
- This final MDD tooling development task is a testing role. The MDD tooling models and generates all of the artifacts required for each runtime platform to support a few key scenarios.
Now the MDD tooling is ready for the application developers to start using it:
- Train application developers to use MDD tools
- Before using the MDD tools, educate the application developers on how the new development process works. They need to understand when and how to use the MDD tools, and also how they fit with their traditional tools such as configuration management.
- Develop business applications
- At this point, the application developers use the MDD tools to build business applications.
The MDD tool chain
The flow in Figure 2 shows how a developer can use the MDD tools to develop part of a business application. In this example, the developer reviews the business problem and selects a design pattern. This partially populates a design model and the developer fills in details of the specific business function they are building. After that, the development process is fully automated. The developer selects an option to generate the artifacts, which are packaged up and placed in the build area. Then the developer can select further options to generate the additional artifacts for a particular runtime platform.
Figure 2. The MDD tool chain
Benefits
MDD has the potential to greatly improve current mainstream software development practices. Table 2 shows the advantages of an MDD approach.
Table 2. MDD benefits
| Benefit | Explanation |
|---|
Increased
productivity | Reduced cost of software development by generating code and artifacts from models, increasing developer productivity. You must factor the cost of developing (or buying) transformations, but careful planning helps ensure there is an overall cost reduction. | | Maintainability | Many solution components are implemented using legacy platform technologies in which the organization no longer has expertise. MDD leads to a maintainable architecture where changes are made rapidly and consistently, enabling more efficient migration of components onto new technologies.
High-level models are kept free of irrelevant implementation detail, making it easier to handle changes in the underlying platform technology and its technical architecture. You change the technical architecture of the implementation by updating a transformation. The transformation is reapplied to the original models to produce implementation artifacts following the new approach.
You can try out different ideas before making a final decision. Bad decisions are easily changed. Software projects are often stuck with decisions that are a mistake, but too costly to fix. | Reuse of
legacy | Consistently model existing legacy platforms in UML. If there are many components implemented on the same legacy platform, you can develop reverse transformations from the components to UML. You can migrate the components to a new platform or generate wrappers to enable access to the legacy component by integration technologies such as Web services. | | Adaptability | Adding or modifying a business function is straightforward since the investment in automation was already made. When adding new business function, you only develop the behavior specific to that capability. The remaining information needed to generate implementation artifacts was captured in transformations. | | Consistency | Manually applying coding practices and architectural decisions is error prone. MDD ensures that artifacts are generated consistently. | | Repeatability | MDD is especially powerful when applied at a program or organization level; the return on investment from developing the transformations increases each time they are reused. Using tried and tested transformations also increases the predictability of developing new functions, and reduces risk because architectural and technical issues were already resolved. | Improved stakeholder
communication | Models omit implementation detail that isn't relevant to understanding the logical behavior of a system. They are much closer to the problem domain, reducing the semantic gap between the concepts that are understood by stakeholders and the language in which the solution is expressed. Facilitates the delivery of solutions that are better aligned to business objectives. | Improved design
communication | Models help you understand systems at the design level, leading to improved discussion and communication about a system. Because models are part of the system definition, rather than documentation, they are never out of date and are reliable. | | Expertise capture | Projects or organizations often depend on key experts who repeatedly make best practice decisions. Their expertise is captured in patterns and transformations, so they don't need to be present for other members of a project. And, provided sufficient documentation accompanies the transformations, the knowledge of an organization is maintained in the patterns and transformations even when experts leave. | Models as
long-term assets | Models are important assets that capture what the IT systems of an organization do. High-level models are resilient to changes at the state-of-the-art platform level. They change only when business requirements change. | Ability to delay
technology decisions | Early application development is focused on modeling activities. You can delay the choice of a specific technology platform or product version until further information is available. In domains with extremely long development cycles (such as air traffic control systems), this is crucial. The target platforms may not even exist when development begins. |
|
Summary
This article explained how you can use MDD to deliver improved business value from your IT. Like any tool or technique, MDD can be used well or it can be used badly. MDD has the potential to produce the benefits outlined in this article, but the approach must be applied effectively.
Information in this article is based on the authors' collective experience in industrial applications of MDD. A more detailed treatment of the subject, by the same authors, is in the IBM Redbook Patterns: Applying Model-Driven Development with Rational Software Architect. It includes a detailed case study, and describes how to use IBM Rational Software Architect to perform the tasks of an MDD project. Using the practices in the Redbook will significantly improve the chances of success for your MDD project.
Resources Learn
Get products and technologies
-
Get a fully functional trial download, available at no charge, of
Rational Software Architect, available for download directly from developerWorks.
-
Build your next development project with various
IBM
trial software products, also available for download from developerWorks.
Discuss
About the authors | 
| | Larry Yusuf is a Solution Designer with Software Group Strategy and Technology based at the Hursley Labs in the U.K. He has four years of experience in Business Integration and modeling, with an emphasis on business process management, event and solution management, and Integration patterns. He has written and presented extensively on these topics. Contact Larry at
yusuf@uk.ibm.com. |
| 
| | Mandy Chessell is a Senior Technical Staff Member in the U.K. She has 18 years of experience in the middleware field. She holds a Masters degree in software engineering from the University of Brighton, U.K. Her areas of expertise include distributed transaction processing, object-oriented design, usability, and UML modeling. Contact Mandy at mandy_chessell@uk.ibm.com. |
| 
| | Dr. Tracy Gardner is a Solution Architect in the IBM Software Group Services in the U.K. She has more than five years of industrial experience in model-driven development. She has written and presented extensively on model-driven development. She holds a Ph.D. in software engineering from the University of Bath. Contact Tracy at tgardner@uk.ibm.com. |
Rate this page
| |
