Design Patterns – A Modeling Challenge Vojislav D. Radonjic, Soheila Bashardoust, Jean-Pierre Corriveau, and Dave Arnold School of Computer Science, Carleton University Ottawa, Canada radonjic@acm.org Abstract – Design patterns and their catalogs are an important phenomenon in software development, and they present a challenge to modeling techniques and supporting tools. In this paper we identify and illustrate the problem in terms of the creational family and one of its members, the Factory Method. Keywords: design patterns; variability modeling; variant selection 1. Introduction: Design Patterns Designers are bridge builders from the problem world of requirements to the solution world of various candidate systems. Design patterns have emerged as important tools for documenting and sharing the ‘bridge building’ experience of spanning from the side of requirements (scenarios and features) to the side of implementations (C++, Java, various run-times). Like craftsmen in other disciplines, software designers place great importance on their tools, and judging by the large number of copies of the GoF catalog [3] sold, and by the ubiquity of these patterns in newly developed systems, these craftsmen have chosen design patterns as one of their essential tools. Design patterns, however, remain a challenge for the modeling community. The core pattern conceptualization – the often repeated ‘a design solution to a problem in context’ – is considerably more complex, as we will see in Section 2. In Section 3 we summarize the modeling challenges. 2. Design Patterns: a Challenge to Modeling Design Patterns are complex abstractions that span from requirements through design to implementation, with variability at each phase. In the remainder of this section we illustrate the challenge of modeling the creational family, and in particular, the Factory Method from the GoF [3]; our modeling goal is to explicit the concepts, their variations and connections as they appear in various sections of the template format used in the GoF catalog. 2.1 Example: Design Level Requirements For The Creational Family Of Patterns Let us start at the source, the GoF catalog[3]. “Creational design patterns abstract the instantiation process. They help make a system independent of how its objects are created, composed, and represented. ... Creational patterns become important as systems evolve to depend more on object composition than class inheritance. As that happens, emphasis shifts away from hard-coding a fixed set of behaviors toward defining a smaller set of fundamental behaviors that can be composed into any number of more complex ones. Thus creating objects with particular behaviors requires more than simply instantiating a class.” p81 [3] The above two paragraphs begin the presentation of creational patterns: they establish the fundamental goal of this family of patterns as System Creation in a specific context. The context is what leads to a particular kind of refinement of the goal of system creation that is based on object-orientation; where a system is composed of objects (components), whose structure and behavior are defined in terms of classes (types). It is this context that governs the space of design mechanisms used to achieve the goal. “There are two recurring themes in these patterns. First, they all encapsulate knowledge about which concrete classes the system uses. Second, they hide how instances of these classes are created and put together. All the system at large knows about the objects is their interfaces as defined by abstract classes. [component types] Consequently, the creational patterns give you a lot of flexibility in what gets created, who creates it, how it gets created, and when. They let you configure a system with "product" objects that vary widely in structure and functionality. Configuration can be static (that is, specified at compile-time) or dynamic (at run-time).” p81 [3] The goal of System Creation is that of creation and initialization of the system structure out of a set of component types. The previous paragraph mixes the what and the how, the goal and the mechanisms used to achieve it. Our aim is to separately model the goal of system creation from the mechanism used to achieve it. From a designer’s perspective, the goal of system creation is refined in terms of component types and their relationships (family constraints, initialization ordering constraints, incompatibilities between component types, etc.), system object structure, binding place and time. The forces leading to selection of one pattern over another, therefore, are in these terms: • Sets of component types: static, dynamic, family of component types • System Structure • Uniqueness (Singletoness)