Level: Introductory Colin Yu (coliny@ca.ibm.com), Development Manager, IBM
21 Nov 2006 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. Its goal is to improve the productivity and quality of enterprise
application development. Patterns play an important role in model transformation and code generation in MDD. This series of articles discusses in detail the Model-Driven and Pattern-Based development paradigm using IBM® Rational® Software
Architect, an integrated development environment supporting MDD.
Introduction
Model-driven development (MDD) is a new software development paradigm supported and driven by the Model-driven Architecture (MDA) methodology, a software design approach released by the Object Management Group (OMG). MDA provides a set of guidelines for structuring specifications expressed as models, starting from a platform-independent model (PIM), continuing through an appropriate domain-specific language, and then tranforming into one or more platform-specific models (PSMs) for the actual implementation platform. This could be any number of platforms, such as Java™ 2 Platform, Enterprise Edition (J2EE™), CORBA, or .Net, implemented in a general programming language such as Java™, C#, and Python. MDA is normally performed using automated tools, like IBM® Rational® Software Architect. Driven by MDA, MDD focuses more on model transformation and code generation.
However, the code generation-based approach used by MDD has its own downside, due to things like constraints in generated code, insufficiently skilled developers, and tight coupling to the model. When companies commit themselves 100% to code generation, there is little room for tweaking, especially when developers always have to go through their model.
A pattern-based development approach helps solve this problem. A pattern is a solution to a recurring problem within a given context. Patterns encapsulate a designer's time, skill, and knowledge to solve a software problem. In addition,
when it is used repeatedly in a number of different projects, a pattern becomes established as a best practice. By designing around a particular design pattern, developers have greater flexibility to control the generated code, which is not constrained simply based on an abstract model.
Furthermore, MDD can automate implementation patterns with transforms, which eliminate repetitive low-level development work and encode technical expertise to improve consistency and maintainability. A modified transformation is rapidly reapplied in order to generate solution artifacts that reflect a change to the implementation architecture.
This article focuses on how to optimize MDD with asset-based development as an integrated development approach. Using this approach, developers first build the object model using the Unified Modeling Language (UML), and then generate the code from that UML model using a code generation tool that utilizes a pattern repository.
 | | UML is an open standard and the de-facto standard for software modeling. UML is a language for specifying, visualizing, and documenting software systems. UML provides a visual notation and underlying semantics for software models. UML also has a standard machine-readable serialization format, thereby enabling automation. |
|
Applying MDD with Rational Software Architect
Reading this information, you have probably realized that applying this development approach requires an Integrated Development Environment (IDE) that can support the following:
- Modeling using UML
- Patterns infrastructure
- Model transformation and code generation
- Platform-specific design and development tool and unit test environment
Rational Software Architect is the tool that provides all those capabilities. Rational Software Architect is an integrated design and development tool that leverages model-driven development with UML to create well-architected applications and services. With Rational Software Architect, you can:
- Leverage an open and extensible modelling platform
- Acclerate software modeling and design
- Automate development processes and maximize asset reuse
- Develop application and Web services more productively
The series of these articles is organized as follows:
Part 1: This article, which focuses on an overview of MDD and Pattern-based development approach
Part 2 (to come): The MDD and Pattern-based development approach with Rational Software Architect
Part 3 (to come): A case study
UML model
One of the main characteristics of MDD is using models as the key artifacts. A model is a description of a system from a particular perspective, omitting irrelevant detail so that the characteristics of interest are seen more clearly. In MDD, a model must be machine-readable, so that you can access the content of the model in an automated manner. Models must be machine-readable in order for you to be able to generate artifacts. A diagram on a whiteboard may meet the other criteria for being a model, but until you can capture it in a machine-readable manner, you cannot use it within an MDD tool chain.
Software models are typically expressed in UML. UML models hide technical implementation details, so that a system can be designed using concepts from the application domain. Application design is typically carried out using a UML modeling tool
such as Rational Software Architect, and concepts relevant to the application domain.
The use of UML models to design software was a well-established practice even before MDD. In most cases, models are used in two ways:
- As sketches that informally convey some aspect of a system
- As blueprints that describe a detailed design that you manually implement.
In MDD, models are used not just as sketches or blueprints, but as primary artifacts from which efficient implementations are generated by applying transformations. In MDD, precisely described domain-oriented application 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.
Transformation
UML modeling is a valuable technique by itself, but manually synchronizing models and code is error-prone and time consuming. Transformation is the main characteristic that distinguishes MDD from other approaches that use modeling.
MDD is concerned with automating the development process so that any artifact, which can be derived from information in a model, is generated. Besides code, the generated artifacts from transformation include but are not limited to the following:
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. This both ensures consistency and makes information available within the models that developers are working with on a daily basis, rather than in documents that are difficult to navigate. Documentation can either be generated by tools such as Rational Software Architect's Report Generator, or by a transformation.
Test artifacts: It is possible to generate basic test harnesses (for example, using JUnit) from the information contained in software models.
Build and deployment scripts: Using their expertise, build and deployment 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).
Patterns
Another main characteristic of MDD is capturing expertise. Patterns capture best practice solutions to recurring problems. In MDD, patterns can occur at all levels of abstraction in modeling. For example:
- Architecture patterns
- Design patterns
- Implementation patterns
Patterns can be composed to produce pattern recipes for solving larger problems and cover best practices for a domain area.
Patterns specify both characteristics of model elements and the relationships between those elements. You can automate patterns so that new elements are created, and existing elements are modified in transformation to conform to the pattern
when the pattern is applied to a model.
Patterns improve the consistency and quality of solutions. They do this by automating implementation patterns with transforms in MDD, which eliminates repetitive low-level development work. Rather than repeatedly and manually applying
technical expertise when building solution artifacts, the expertise is encoded directly in transformations. This has the double advantages of consistency and maintainability. A modified transformation is rapidly reapplied to generate solution artifacts that reflect a change to the implementation architecture.
From business problems to software solutions
Figure 1 shows how a business problem is translated into a software solution with MDD. The business problem is reviewed, and some common business patterns are applied. This partially populates a design model and fills in details of the specific business function under construction. Then, platform independent design patterns are applied to transform the design model into runtime-independent components. Following that, a runtime platform is selected, and runtime-specific implementation patterns are used to generate the artifacts.
Figure 1. Using MDD to translate a business problem into a software solution
Benefits of using MDD with Patterns
The software development industry has realized quite a lot of benefits by adopting MDD with Patterns. Some significant ones include:
Increased productivity: MDD reduces the cost of software development by generating code and artifacts from models, which increases developer productivity.
Increased reuse: MDD is especially powerful when applied at a program or organization level. This is because the return on investment from developing the transformations increases each time they are reused. The use of tried and tested transformations also increases the predictability of developing new functions, and reduces the project risk (since the architectural and technical issues have already been resolved).
Improved Maintainability: Technological evolution leads to solution components becoming legacies of previous platform technologies. MDD helps to solve this problem by leading to a maintainable architecture, one in which changes are made rapidly and consistently, enabling you to migrate components more efficiently onto new technologies.
More Flexibility: High-level models are kept free of irrelevant implementation detail. Keeping the models free of implementation detail makes it easier to handle changes in the underlying platform technology and its technical architecture.
Changing the technical architecture of the implementation is accomplished by updating a transformation. The transformation is reapplied to the original models to produce implementation artifacts following the new approach.
Consistency: Manually applying coding practices and architectural decisions is an error-prone activity. MDD ensures that artifacts are generated consistently
Improved communication: Models omit implementation detail that is not relevant to understanding the logical behavior of a system. Models are therefore 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. Models also facilitate understanding and reasoning about systems at the design level. This leads to improved communication about a system.
Retain expertise: Projects or organizations often depend on key experts who repeatedly make best practice decisions. With their expertise captured in patterns and transformations, they do not need to be present for other members
of a project to apply (and benefit from) it.
Lower risk: When using an MDD approach, early application development is focused on modeling activities. This means that it is possible to delay the choice of a specific technology platform or product version until a later point (when further information is available, thus reducing the risk).
Lessons learned
MDD is a sound development methodology. However, industry feedback indicates that not all the projects using MDD were successful. This was generally due to several factors:
- Poor project selection
- Insufficient planning
- Lack of necessary experience and skills
To help you gain the most benefits from MDD, the following are some lessons we have learned from our past projects.
Select the right candidate projects: MDD is especially powerful when applied at a program or organization level, because the return on investment (ROI) from developing or buying the transformations increases each time they are reused. A good candidate project should also have well-defined architecture and repeatable patterns of behavior, so that those patterns can be abstracted to capture the expertise and be used in the transforms.
Consider the additional cost: You may need to consider the cost of developing or buying transformations, but careful cost planning will ensure that there is an overall cost reduction in the long run.
Make small wins: In many organizations, a new approach is greeted with some skepticism until it is proven to work. If this is your first project that uses the MDD approach, it is advisable to split the development of the MDD tooling into a number of iterations. Subsequent iterations build on the experience you gain, allowing you to support a broader and broader set of scenarios for the business application.
Develop the right skills: MDD requires architects and developers to be familiar with UML and the IDE for MDD. Building these skills within the team may take some time at the beginning, which leads to project delay. However, with the same project team, subsequent projects will be much smoother. If this is your first project that uses MDD, bringing in experts to jump-start the team
is a good choice.
Always think about reuse: The MDD tooling built for your project will have been used many times by the application developers while they are generating artifacts for the business application. It is also possible that this tooling could be reused on subsequent projects. Always thinking about reuse in a bigger context will benefit your organization significantly in a long run.
Select the right development tool: Having the right weapon with you will ensure that you are getting the maximum value from MDD. The project team (including the project manager, business analysts, solution architect, developers, and testers) should evaluate and validate the development tool being used.
Summary
Part 1 of this series lays out the picture of the model-driven and pattern-based development paradigm. In summary, MDD unlocks the potential of patterns to create well designed solutions, and patterns provide the content for MDD.
Resources Learn
Get products and technologies
Discuss
About the author | 
| | Colin Yu is the development manager of the repository for reusable assets to support Asset-based Development with the Rational Software Development platforms. His prior jobs include On-demand software development, work as a solution architect of the WebSphere Business Integration platforms, and WebSphere Studio development. You can reach Colin at coliny@ca.ibm.com. |
Rate this page
| 
