Dynamic instantiation-checking components
Proceedings of the 2006 ACM symposium on Applied computing
| Hi-index | 0.00 |
A design pattern describes a commonly recurring problem in the design of object-oriented software, a solution to that problem, and the context in which the solution can be applied. The benefits of design patterns are two-fold. First, patterns serve as guidance to the novice designer. Second, they provide an extended vocabulary for documenting software design. In the mid 1990s, the publication of several pattern catalogs—compendiums of design patterns—popularized patterns as a tool for designing object-oriented software. Today, many of these catalogs are standard references, and the patterns they contain are an important part of software practice. Unfortunately, the descriptive format popularized by these catalogs is inherently imprecise. As a consequence, it is unclear when a pattern has been applied correctly, or what can be concluded about a system implemented using a particular pattern. This ambiguity threatens to undermine the two principal benefits associated with the use of design patterns. First, novice designers are more prone to error without a precise description of how each pattern must be applied. Second, documentation describing the patterns applied in designing a system may be misleading, as different designers can interpret pattern descriptions in subtly different ways. To address the ambiguity issues associated with design pattern descriptions, we introduce the concept of a design pattern contract as a formalism for precisely specifying design patterns. Like all contracts, a design pattern contract consists of two primary components: a responsibilities component and a rewards component. The responsibilities component of a pattern contract precisely characterizes the requirements that must be satisfied by the designer when applying a particular pattern. The rewards component specifies the system properties that are guaranteed to be exhibited if the contract responsibilities are indeed satisfied. The contract formalism alone, however, is not enough to guarantee that design patterns will be applied correctly. After all, software design is a complex task. Even when guided by a precise set of requirements, designers can—and do—make mistakes. To detect such contract violations, we introduce the notion of a contract monitor—an executable unit of deployment used to detect runtime contract violations. During the testing phase of a system's life cycle, the designer can instrument the system with the appropriate monitors to determine if the contracts used in its construction were applied correctly. We present two approaches to implementing these monitors. The choice of which to use depends on the requirements of the system, and the skill-set of the designer.