Level: Introductory Dr. Tracy Gardner (tgardner@uk.ibm.com), Solution Architect, IBM
Larry Yusuf (yusuf@uk.ibm.com), Solution Designer, IBM
14 Feb 2006 Using patterns and model-driven development (MDD) can lead to architecture-driven development. This style of development allows architectural decisions to be captured explicitly and encoded in your system with automation. And by using patterns and MDD, you can reduce complexity in your work, enabling on demand design and development. Read this article to learn more about these issues, which builds on information discussed in its companion article, "Implement model-driven development to increase the business value of your IT system."
Introduction
In the companion article, "Implement model-driven development to increase the business value of your IT system," you learned how model-driven development (MDD) can deliver value. In this article, you discover how MDD supports an architecture-driven approach to development.
Recapping MDD
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.
Defining architecture and architectural style
The IEEE defines architecture as:
The architecture of a software system (at a given point in time) is its organization or structure of significant components interacting through interfaces, those components being composed of successively smaller components and interfaces.
A significant amount of effort and expertise goes into developing a software architecture. The architecture reflects decisions about how function will be distributed through the system, which technologies will be used, and which design patterns will be adopted.
The architecture embodies a set of architectural principles and decisions. Sometimes these architectural principles get documented, but often the reasoning is never captured. In some cases, the architectural principles are not even fully thought out, resulting in a poor or inconsistent architecture. Of course, documenting the architectural principles is a good idea, but what if you could go further and capture them in such a way that changing or introducing an architectural principle would actually change the architecture of the system? And, what if you could apply those same principles to multiple components, services, and solutions? These advantages are what MDD is about.
In his book, Convergent Architecture: Building Model-driven J2EE Systems with UML, Richard Hubert introduces the term architectural style to refer to a set of architectural principles that can be repeatedly applied. He defines an architectural style as a family of architectures:
- Related by common principles and attributes
- Conveys the principles and the means to most effectively achieve a design vision
MDD also involves automating an architectural style. In MDD, you don't just simply document the implemented architectural principles, patterns, and transformations that a solution is guaranteed to follow. An MDD approach also forces architectural decisions to be made explicitly. And it enables bad decisions to be rectified more easily as new understanding is gained. When a principle is manually applied throughout a system, it can be difficult to modify. But if captured in a transformation and applied automatically, it's easier to modify the transformation and regenerate. It is also less costly to try a number of alternatives before making a final decision. This approach is valuable when verifying that the solution meets nonfunctional requirements, where you repeatedly apply patterns and transformations to identify the best match.
The architectural style adopted by an MDD project can be influenced by a number of factors, including:
- Category of software under development (such as enterprise integration, real-time embedded, end-user interface)
- Category of software platform that is to be used (such as messaging middleware or rule-based system)
- Software development paradigms that are favored (such as service-oriented or aspect-oriented)
- Subject matter of the software (such as telecoms, finance, or retail)
- Architectural principles for the system or systems under development
- Scope of the architectural style (from industrywide to project specific)
- House style of the software development organization (for example, modeling conventions)
- Nonfunctional requirements for the solution (from qualities of service to presentation style and existing infrastructures)
Capturing expertise
Many IT projects suffer from a lack of skilled experts who are capable of making architectural decisions. This often leads to over-dependence on key individuals, without whom the project would have severe difficulties.
A key aspect of MDD is expertise capture. Instead of needing experts to be on hand every time a best-practice decision must be made, their expertise is captured in automated patterns and transformations so you can reapply it. This approach enables developers without specialist knowledge to build sophisticated systems.
There are two main types of expertise you need to capture in order to build an MDD framework: logical (functional) architecture expertise and technical architecture expertise. Both logical and technical architecture expertise is part of the overall architectural style.
Logical architecture expertise
The logical architecture of a solution is concerned with the function that it must exhibit rather than the way in which functions are implemented using particular technologies. When using an MDD approach, the goal is to model at the logical level and generate implementation artifacts.
In MDD, you define the logical architectural style and develop Unified Modeling Language (UML) profiles, patterns, and modeling conventions in support of this style. Much of the expertise involved in defining a logical architecture is captured in the MDD framework and applied each time a new application is developed. The designer of a new application is able to focus more on the problem domain and less on aspects of the software architecture that are common across applications.
Technical architecture expertise
Modern middleware platforms offer a rich array of features to support the wide variety of applications that will be built on top of them. Individual projects, however, often only use a subset of those functions, and they use that subset in a specialized way.
The way in which a particular project (or program) makes use of its chosen middleware platforms defines the technical architecture. The technical architecture can be captured in best practices documents or it can be passed from developer to developer. In practice, it is difficult to ensure that the technical architecture is applied consistently when this is a manual process.
MDD gives you the opportunity to implement the technical architecture directly. Rather than stating in a document that, for example, "entry and exit from all public methods will be recorded using log4j," you can implement a transformation that generates logging code according to this rule. One advantage of the MDD approach is that it forces you to consider the technical architecture earlier in a project and more thoroughly. If you understand this at the outset and sufficient time is allocated to define the technical architecture, this is a real benefit and can save you a lot of time later in the project.
Understanding patterns
In MDD, you model using domain-specific concepts. For example, in the enterprise integration domain you might use message, proxy, and adapter. Often the vocabulary of an application domain also includes patterns. In the enterprise integration domain, you might have guaranteed delivery and publish-subscribe patterns. These patterns are not individual elements, but introduce relationships between elements and constraints on their behavior.
The (building) architect Christopher Alexander introduced the concept of a pattern language in his classic, The Timeless Way of Building. His notion of patterns as best practice approaches to common design problems has been widely adopted by the software community. He introduces the concept of a pattern language, which he defines as a related set of patterns that together provide a vocabulary for designing within a certain context or problem domain.
In a follow-up volume, A Pattern Language, Alexander introduces a specific pattern language that has sub-languages for designing towns (targeted to planners) and buildings (targeted to architects) and a sub-language for construction (targeted to builders).
Examples of Alexander's patterns are:
- Town patterns
- Ring roads, night life, and row houses
- Building patterns
- Roof garden, indoor sunlight, and alcoves
- Construction patterns
- Good materials, column connection, and half-inch trim
Each pattern includes information about the circumstances in which it is applicable and its relationship with other patterns. Alexander explains that when using a pattern language, "we always use it as a sequence, going through the patterns, moving always from the larger patterns to the smaller, always from the ones that create structure, to the ones which then embellish those structures, and then to those that embellish the embellishments."
The idea of a pattern language is just as applicable to software development as it is to building architecture, and this article uses that term throughout. The nature of software development means that additional automation of the process of designing with a pattern language is possible.
Just as in Alexander's approach, you can design a software system by moving from larger patterns to smaller patterns, as shown in Figure 1. Human expertise is required to select appropriate software patterns within the context of the design.
Figure 1. Pattern progression
When applying patterns to software there's an additional advantage: The application of a pattern can be automated so that when a pattern is selected, the design is expanded with all the consequences associated with that pattern. A simple example of a software pattern is the Getter/Setter pattern in which attributes are always accessed through consistently named operations. This pattern can be automated so that applying the pattern to attribute name of class Customer adds operations named getName and setName (with appropriate parameters) to the Customer class.
In general, it is not possible to automate the physical construction of buildings. However, software systems are constructed from information artifacts that can be generated automatically according to implementation patterns. Where the builder must apply the construction patterns manually, software architects can describe software implementation patterns in sufficient detail that they can be generated when given application-specific context.
As you can see in Figure 2, a detailed system model can be transformed into a set of runtime artifacts (source code, deployment descriptors, and so on), then follow selected patterns and technical architectural principles. For example, if you have a model that uses the Getter/Setter pattern, you can generate implementation code for those methods for a specific platform, such as Java™, according to implementation patterns for that platform. In some cases, you may have an implementation pattern that implements an Application pattern directly. In other cases, you might apply multiple lower-level implementation patterns to implement an Application pattern.
Figure 2. Transformation
Combining patterns and MDD
The complementary nature of patterns and MDD is key to architecture-driven development. Patterns and MDD are related in two important ways:
- MDD can automate the application of patterns.
Traditionally, patterns are written down as documents, often with the aid of UML models to explain the pattern. Patterns are then applied manually.
- Patterns provide content for MDD.
MDD enables you to move from well-designed models to well-designed implementations. Patterns capture the best practices at both the modeling and implementation levels. MDD is not possible without knowledge of the patterns of the application domain and the patterns of the implementation domain.
Software patterns can apply within an abstraction layer (such as design patterns and implementation patterns) and across abstraction layers (patterns for relating design elements and code). You can compose patterns to produce pattern recipes for solving larger problems and pattern languages to cover best practices for a domain area.
When using the architecture-driven approach to development described in this article, the design of a system proceeds as shown in Figure 3.
Figure 3. Architecture-driven approach
The sequence of activities does not imply that one step must be complete before the next step is started. An iterative approach can be used, where a solution is built up over multiple passes through these steps, adding function each time.
Reusing assets with IBM Patterns for e-business
With the complementary nature of patterns and MDD, the success of a project using the architecture-driven development approach is very much dependent on the quality of the patterns and the MDD framework. You must ensure that you are automating a pattern language that covers the business, application, and runtime levels, while providing a definition of the expected qualities of service and behavior when each pattern is applied. The IBM Patterns for e-business provide a family of patterns at each level, allowing you to select particular patterns from them (depending on our solution requirements), to make up your pattern language.
IBM Patterns for e-business help facilitate the reuse of assets that capture the experience of IT architects in such a way that future engagements are simpler and faster. The reuse of these assets saves time, money, and effort, and helps ensure the delivery of a solid, properly architected solution. The purpose of IBM Patterns for e-business is to capture and publish e-business artifacts that were used, tested, and proven to be successful. The captured information is assumed to fit the majority, or 80/20, situation. IBM Patterns for e-business are further augmented with guidelines and related links for optimal use.
Layered asset model
The Patterns for e-business approach lets architects implement successful e-business solutions by reusing components and solution elements from proven successful experiences. The Patterns approach is based on a set of layered assets that any existing development methodology can exploit. The layered assets are structured so that each level of detail builds on the last. These assets include:
- Business patterns
- Identify the interaction between users, businesses, and data.
- Integration patterns
- Tie multiple Business patterns together when a solution cannot be provided based on a single Business pattern.
- Composite patterns
- Represent commonly occurring combinations of Business patterns and Integration patterns.
- Application patterns
- Provide a conceptual layout describing how the application components and data within a Business pattern or Integration pattern interact.
- Runtime patterns
- Define the logical middleware structure that supports an Application pattern.
Runtime patterns depict the major middleware nodes, their roles, and the interfaces between these nodes.
- Product mappings
- Identify proven and tested software implementations for each Runtime pattern.
- Best-practice guidelines
- For design, development, deployment, and management of e-business applications.
See Figure 4 for a visual representation.
Figure 4.
Patterns and MDD are key to closing the business and IT gap, and ensuring the delivery of business value. The adoption of Patterns and MDD:
- Reduces time to react
- Enables on demand design and development
- Reduces complexity
Patterns and MDD are coming of age and are delivering tangible results.
Thomas Murphy of META Group (now part of Gartner Group) is widely quoted as saying that "Organizations using model-driven, pattern-based development frameworks and tools can attain dramatic productivity and quality improvements across the development team."
MDD promotes improvements in business agility, which is key to success in a continually changing, on demand world. The successes of pattern-driven development, IBM Patterns for e-business, and MDD are a result of the complementary nature of these techniques.
IBM Patterns for e-business are layered, reusable, integrated, and proven patterns, providing quality input to the MDD method. MDD augments the reusability of the Patterns for e-business by automating them so they can be reapplied easily. Patterns for e-business provide key content when creating enterprise-wide MDD frameworks that are particularly important for capturing and enforcing a common architectural style across all the IT systems in an enterprise.
Part 11 of the Architecting on demand solutions series of articles illustrates this concept very well. It uses an example in which the IBM patterns for e-business provide the input to the MDD framework for generating the Enterprise Service Bus (ESB) components based on the messaging patterns.
Summary
In this article you learned how combining patterns and MDD can lead to architecture-driven development, where architectural decisions are captured explicitly and encoded in the system using automation. You also explored the benefits of implementing an architecture-driven approach.
Resources Learn
-
Read the IBM Redbook Patterns: Model-Driven Development using IBM Rational Software Architect for more information about MDD. It provides a detailed case study, and explains how to implement the approach using the Rational Software Architect tool.
-
Read The Timeless Way of Building, by Christopher Alexander (Oxford University Press, August 1979). ISBN 0-195-02402-8.
-
Read A Pattern Language Towns, Buildings, Construction, also by Christopher Alexander. (Oxford University Press, August 1977). ISBN 0-195-01919-9.
-
Read Richard Hubert's book, Convergent Architecture: Building Model-driven J2EE Systems with UML. (John Wiley & Sons, Inc.; November 2001). ISBN 0-471-10560-0.
-
Implement model-driven development to increase the business value of your IT system: Discover the advantages of using modeling tools from IBM Rational software (developerWorks, January 2006): Read the companion article to this one, which explains the value that can be delivered through an MDD approach.
-
The IBM Redbook, Patterns: Model-Driven Development using IBM Rational Software Architect gives you more information about MDD in practice. (IBM, December 2005) ISBN 0-738-49288-4.
-
Learn more about IBM Patterns for e-business, a group of reusable assets that can help speed the process of developing Web-based applications.
-
Stay current with
developerWorks
technical events and webcasts.
Discuss
About the authors  | 
| | 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. |
| 
| | 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. |
Rate this page
| 
