Responsibilities and rewards: specifying design patterns

Abstract

Design patterns provide guidance to system designers on how to structure individual classes or groups of classes, as well as constraints on the interactions among these classes, to enable them to implement flexible and reliable systems. Patterns are usually described informally. While such informal descriptions are useful and even essential, if we want to be sure that designers precisely and unambiguously understand the requirements that must be met when applying a given pattern, and be able to reliably predict the behaviors the resulting system will exhibit, we also need formal characterizations of the patterns.In this paper, we develop an approach to formalizing design patterns. The requirements that a designer must meet with respect to the structures of the classes, as well as with respect to the behaviors exhibited by the relevant methods, are captured in the responsibilities component of the pattern's specification; the benefits that will result by applying the pattern, in terms of specific behaviors that the resulting system will be guaranteed to exhibit, are captured in the rewards component. One important aspect of many design patterns is their flexibility; our approach is designed to ensure that this flexibility is retained in the formalization of the pattern. We illustrate the approach by applying it to a standard design pattern.

Reusing Patterns through Design Refinement

“…The work reported in this manuscript represents a substantial revision and extension of our earlier work in pattern specification [6,7]. Although the earlier work was also based on the idea of pinning down flexibility dimensions when documenting pattern applications, the kinds of abstraction concepts used in the formalism were limited.…”

“…This is too restrictive since, for example, it doesn't allow an observer to change the format used to display information about the subject. In [6], we relaxed this to allow other methods of Observer to make changes as long as those changes left the observer in a state consistent with the same subject state that held at the start of the modifying Observer method. While this improves flexibility, it is still not flexible enough.…”

“…Each abstraction concept corresponds to a dimension of flexibility that must be preserved. Indeed, the process of identifying these abstraction concepts can help to identify latent dimensions of flexibility missing from standard pattern descriptions [6].…”

A catalog of architectural primitives for modeling architectural patterns

“…Architecture Description Languages (ADLs), which aim at representing software architectures in general [27]; 2. the Unified Modeling Language which is a generic modeling language but can also be used to describe software architectures [37,26,4]; 3. some formal or semi-formal approaches for the formalization of pattern specifications [8,29,43,25].…”

“…This is not restricted to architectural patterns but it is a general problem of specifying patterns because each pattern covers not only one (parametric) solution, but informally describes a whole solution space for a recurring design problem. It is obvious in UML and ADLs, and even more so in the third aforementioned approach that deals with the formal specification of design patterns [8,29,43,25]: such methods are capable of specifying one particular solution in the solution space of the pattern, but fail to specify the whole solution space covered by the informal pattern description.We propose to remedy the problem of modeling architectural patterns through identifying and representing a number of 'architectural primitives' that can act as the participants in the solution that patterns convey. We use the term 'primitive' because they are the fundamental modeling elements in representing a pattern, and they are the smallest units that makes sense at the architectural level of abstraction (e.g.…”