This chapter is from the book
This chapter is from the book
This chapter is from the book
Further Reading
In this chapter we discussed pattern composition approaches that we believe could belong to the behavioral composition or the structural composition categories. We selected some sample techniques, and presented a surface discussion about the concepts and models used by each technique.
Dong, Alencar, and Cowan of the University of Waterloo, Ontario, Canada, developed an approach for behavioral analysis to pattern-based composition [Dong et al. 2001]. They rely upon Prolog and model-checking techniques to analyze the composition and integration of design components. They discuss how to represent, instantiate, and integrate design components and how to find design composition errors. The approach is based on a structural and behavioral specification of the design components based on UML class diagrams and collaborations diagrams, respectively. The class diagrams are used to represent structural evolution of design components that are transformed into Prolog representation. Thus, the design components and their compositions are represented as a logic model. The behavioral specifications are transformed into process algebra representations in which case the behavioral properties of these components are represented as logic formulas. A model checker is then used to verify the properties of the design—that is, to verify that the logic formulas hold in the design model. This approach can be useful when the transformation activity can be automated, which is possible when formal descriptions of patterns are available.
Alencar and his group led a thorough research on the formal specification of pattern behavior, discussed in their latest work [Dong et al. 2001]. Formal specification of pattern behavior as well as pattern relationships are not considered composition mechanisms; however, they can provide assistance in analyzing a pattern composition approach.
A study by Motoshi Saeki of the Tokyo Institute of Technology, Japan, provides a technique to define the behavior of design patterns based on the formal description technique LOTOS (Language of Temporal Ordering Specification). The LOTOS simulation facility is used to check the behavioral consistency of combined patterns. The technique again is dependent on transforming patterns behavioral specifications into LOTOS, which is also related to formal models of patterns [Saeki 2000].
The above studies clearly show the importance of reasoning about the behavior of individual patterns and the behavior of pattern compositions using a formal technique. Although such techniques are useful in analyzing pattern participants and their interactions and to possibly detect inconsistencies, they do not provide a practical easy-to-use approach to compose patterns that can be used by an OO software designer.
The OOram approach is illustrated in the book by Reenskaug [Reenskaug 1996] with examples from real-world applications. The role models are incorporated in the collaboration diagrams of UML and in the metamodel as classifierRole [UML 2002]. For updates on the integration of role modeling approach into UML refer to Reenskaug's homepage, http://heim.ifi.uio.no/~trygver/
The notions of role and architectural fragment and their corresponding role and architecture language construct in LayOM that allow for reusable first-class specification of architectural fragments is discussed in Bosch's Specifying Frameworks and Design Patterns as Architecture Fragments (1998c). The LayOM language by itself is discussed in Bosch's Design Patterns as Language Constructs (1998b). The application of the architecture fragment technique and superimposition to the domain of measurement systems in production lines is discussed in Bosch's An Object-Oriented Framework for Measurement Systems (1998a). The superimposition mechanism is discussed in Bosch's Superimposition: A Component Adaptation Technique (1999).
For more discussion on modeling patterns using role diagrams and examples from the GoF patterns, refer to Riehle's Describing and Composing Patterns Using Role Diagrams (1996). Composite design patterns, their relationships to design frameworks, and details about the process of driving them from concrete applications are discussed in Riehle and Züllighoven's Understanding and Using Patterns in Software Development (1996) and Riehle's Composite Design Patterns (1997).
In summary, Reenskaug (1996) recognizes roles as analysis mechanisms helpful in developing application designs. Riehle (1997) recognizes roles as composition mechanisms to derive composite design patterns. Kristensen and Osterbye (1996) use roles as first-class conceptual modeling elements from which objects can be derived and therefore classes can be deduced. In their roots, most of the behavior composition approaches stem from the basic concepts of a role, role models, and role diagrams.
Helm and colleagues (1990) describe an approach that uses contracts to compose objects based on their behavior. Contracts provide a formal semantics to describe the mutual obligations between classes of objects. Design by Contract was introduced by Meyer (1992) as an approach to construct software applications. In this approach, the designer focuses on describing the responsibilities of each design class by formally defining the conditions that should be met prior to using any function or service provided by that class. In addition, a class will provide a formal description of the output of each function or service and how the service changes the application state.
A contract is used to link the function caller (or client) with the function implementation (the contractor). A common way to define a software contract is through the use of preconditions, postconditions, and invariants. Boolean assertions can then be made to determine if a precondition is met before invoking a service, a postcondition is satisfied after the service is invoked (and hence the service is successful), or a class invariant has not changed during the operation. In this case, a contract between the requester and the provider will define the mutual obligations. A client can use a particular service only if the preconditions for the service are met and the class invariants are respected. The provider promises to provide the service and the work defined in the postconditions; in addition, the class invariants will be respected.
Contracts are useful means to formally define the relationship between classes, since they capture all the possible interactions between instances of those classes as well as the runtime conditions required to perform an interaction. They can also be used as means to validate the runtime interactions between objects and discover any violations (interactions not defined in the contract, or pre-condition and post-condition violations).
Jezequel and colleagues (2000) describe how to use contracts to specify the set of design patterns defined in the GoF book. They use the notion of contracts to explicitly describe the intention behind a design pattern in terms of formally capturing the participating objects, their collaborations, and the distribution of responsibilities. They use the Eiffel language to specify a contract for each of the GoF patterns. Although this work mainly focuses on specifying a contract for each pattern that formally defines the responsibilities between pattern participants, the ideas are extensible and useful in pattern composition. For instance, if each pattern is captured by a contract between its participants, can we combine two or more contracts to define a composition of two patterns? Is there a way to present a contract that defines the composition? The answers to these questions can possibly be used to define a behavioral composition technique to compose design patterns. Whereas gluing objects (classes) together using patterns has received thorough investigation in the last decade, gluing patterns together using contracts is still a research topic that has not been exhaustively studied.
In this chapter we also discussed pattern composition approaches that we believe could belong to the structural composition category. We selected some sample techniques and presented a surface discussion about the concepts and models used by each technique.
For more information about the Catalysis approach, refer to D'Souza and Wills's Objects, Components, and Frameworks With UML: The Catalysis Approach (1998), which contains a complete guide to the process and the detailed models and steps. For aspect-oriented design and programming, the latest works by Clarke and colleagues (2000; 2001) provide pointers to its techniques and tools.
The two approaches that we consider closely relevant to POAD are the work by Keller and Schauer, Design Components: Towards Software Composition at the Design Level (1998), and by Larsen in Designing Component-Based Frameworks Using Patterns in the UML(1999). Keller introduces the concept of software design using design components, which are quite different from the well-known concepts of implementation and physical components. The patterns used in POAD are in fact design components, as discussed in Chapter 4. Larsen introduces the concept of interfaces for design patterns and using those interfaces to develop interfaces for a design framework. The concept of interfaces for design patterns is an important technique that POAD uses to glue design patterns together.
Xavier Castellani and Stephan Y. Liao (1998) propose an application development process that focuses on the reuse of OO application design. Their work presents a process that allows the system designer to create generic applications and reuse them in other application designs in the same problem domain. The approach starts with an existing application, then abstracts design macrocomponents through the abstraction of application-specific design components. The authors use a general definition of macrocomponents (frameworks or patterns) that allows any group of related classes to be considered a pattern.