Modeling the Design Pattern Application Process Luis C.M. Nova luisnova@csg
Paulo S.C. Alencar Donald D. Cowan
[email protected] dcowan@csg Computer Science Department University of Waterloo Waterloo, Ontario, Canada Abstract
Design patterns are general solutions for recurring design problems that can be (re)used over and over in a variety of application domains. However, the pattern application procedure is still manual and lacks mechanisms to help the designer in applying a pattern. This paper introduces a model for the construction of object-oriented systems from design to implementation based on the application of design patterns. The semantics of each of the design pattern solutions is given by a product speci cation and a sequence of processes that operates on the product. The development model is implemented in a transformational environment that supports the speci cation of both product and process.
1 Introduction The act of designing with patterns: creative or automated? There is no easy answer to describing what is the appropriate approach for software development with patterns. Both sides have intrinsic limitations. For instance, while the creative act is slow, expensive, and prone to errors, the inherently informal nature of some pattern elements do not cope well with automation. As a result, the above question is not only dicult to answer, but it is currently dividing the design pattern community in two major streams. The rst stream emphasizes the creative aspects of patterns. It involves researchers that follow the Christopher Alexander's style of thinking, where patterns are design structures that \could easily transcend the exact nature of its expression" [JC95]. According to the ideas in such a stream, the precise representation of the pattern elements is not as relevant as what the pattern developer has in his own mind. While this approach seems appropriate to the general de nition of design patterns, it may restrict their applicability among the computer science community and industry.
1
The other research stream favors the use of speci cation languages which support more formal descriptions of pattern properties. As a result, tools may be developed to assist the user in tasks related to the de nition, retrieval, discovery, and application of patterns. While such an approach enables the e ective use of patterns in a broader extent, it faces some limitations because of the abstract nature of patterns. Thus, most of the automation e ort should be directed towards the elements which can be formalized. According to Gamma et. al[GHJV95], design patterns consist of four essential elements: a meaningful name, the problem it solves, the proposed solution, and the consequences of applying the pattern in a system. While the proposed solution is mostly characterized by structures that can be easily represented in formal terms, the other three essential pattern elements, which are name, problem, and consequences, are just the opposite. These are inherently informal elements, in which very little can be expressed formally. As a consequence, most of the current automation e ort in the pattern-related area is based on the description of the proposed solution. In contrast to other reusable structures, such as class libraries and frameworks, the solution proposed by a pattern is not one concrete set of classes and relationships. Rather, the pattern solution is abstract and may look di erent for every distinct instance. As the solution is not completely de ned, it needs to be completed with application speci c data for each new instance of the pattern. In fact, we consider the pattern solution as being composed of a product part, where the core of the solution is described in a given object-oriented language, and a process part, which speci es all the steps needed to instantiate the pattern solution.
2 The Pattern Application Process Model Design patterns have attracted attention from both industry and academia. Signi cant e ort is being spent towards the development of environments in which patterns may be e ectively applied to real world problems. Five distinct areas appear to bene t design pattern automation: 1. 2. 3. 4. 5.
Pattern representation languages and storage. Search and retrieval mechanisms. Reverse engineering for the identi cation of pattern occurrences. Generation of code templates based on the core of the pattern solution. Application guidance to the pattern instantiation process.
Our research interest is on the last category of automation, where support for the pattern instantiation starts after the pattern selection and ends with the completion of its integration 2
Figure 1: A software life cycle based on pattern applications. in the software model under development. The pattern instantiation is de ned by re nement processes that operate over an initial model to produce a re ned model, as illustrated in Figure 1. The models are speci ed in a product language. Each pattern application re nes the previous software model in a well-de ned sequence of processes. These processes are de ned by a set of transformations T that will operate over the input model to produce an output model based on a speci c pattern solution. The processes in the pattern instantiation can be automated and/or creative. Both types of processes may be used throughout the application of each pattern. Automated processes can be precisely described and interpreted by a computer. However, creative processes depend on human intervention (i.e. human modeling decisions) to be completed. Such human intervention may be required for distinct reasons. For example, the designer may be asked to make decisions on implementation trade-o s which favor either eciency or program size. Figure 1 shows a software development model for the application of design patterns. In this approach, an initial model is incrementally re ned through well-de ned processes and human interaction.
3
2.1 Contributions of the Automated Pattern Application
According to Boehm [Boe87], the three leading strategies to improve software productivity and reduce development cost are: making individual steps more ecient using automated aids, eliminating steps, and eliminating rework. We argue that the use of the transformational environment to support the application of design patterns addresses all three strategies. Software tools make individual steps more ecient by automating repetitive and labour intensive development tasks. In the transformational approach, a tool providing process support not only automates the generation of repetitive product structures, but it also automates the sequence of processes during development. In addition, the solution space may be reduced to a limited number of options (e.g., a trade-o selection), instead of an in nite set of solutions. Consequently, development time is shorter and errors are reduced. The elimination of steps in the development process is another way to improve productivity. In one form or another, reuse plays a major role in this elimination of steps. Compilers are one good example. Compared to programming in the 1950's, compilers simpli ed programming by allowing developers to write in a higher-level language and translating it to a lower-level one. This translation to machine language may be seen as a reuse of low-level structures. For design patterns, reuse shows itself in the form of higher level solutions. In such case, several tasks may be eliminated by both the product and process solutions. As Boehm addresses, reducing the need for post-development software modi cations is one of the strongest forms to leverage productivity. Automated support for patterns can signi cantly reduce rework. As both the automation and reuse of patterns help in the elimination of error-prone activities of development, the amount of needed rework will likely decrease. As patterns encapsulate partially reusable knowledge, its proposed solution is often tested and developed by experienced designers. Thus, the margin for error is reduced.
3 The Pattern Instantiation Environment (PIE) Processes are the fundamental elements of our pattern instantiation model. They evolve the system according to the guidelines speci ed for each di erent instance of a pattern. As mentioned in the previous section, processes in our approach are implemented as transformations to design pattern speci cations. Therefore, each pattern will consist of a set of transformations that should be executed in a sequence de ned by a combination of the pattern characteristics and the results of user interaction during instantiation. The Pattern Instantiation Environment (PIE) is a prototype tool developed to support the application of design patterns. PIE is supported by the Draco-PUC [LSF94] software machine, which is a meta program generator that supports the construction and usage of domain oriented software. Draco-PUC follows the Draco paradigm [Nei84] for software development which, as mentioned in [LSF94], states that it is possible to develop software based on the reuse of high level abstractions. In PIE, the \reuse of high level abstractions" is 4
Figure 2: Structure of the PIE. provided by instantiations of design patterns and the \representation domain" is the product language in which patterns are instantiated. Figure 2 shows some basic elements of the architecture of PIE and, consequently, the Draco-PUC environment, which is centered on a kernel. The Draco kernel is a transformation engine responsible for executing all the software construction activities. The gure illustrates a few les required for the activation of the kernel. Consistently with Figure 1, the input to the construction process is an initial software model (.in le) described in a chosen product language. The output is the re ned model (.out le). For our particular objectives, both the input and output models are described in the same product language. Therefore, only one domain/footnoteA Draco domain corresponds the product language grammar. is de ned, and it is represented in a .grm le. This le describes the syntax of our domain in terms of Yacc-like1 production rules. The transformational model is not limited to any product language in particular, even though the syntax of the transformations depends on the syntax of the product. Di erent instantiation environments may adopt the same model with a di erent product language. In PIE, we chose an OMT-based [R+91] product language in order to obtain representations 1
A standard Unix tool. For more information, check the man pages of a Unix environment
5
of pattern instances which are similar in form to most of the current pattern catalogs. The adopted language, however, is textual because of limitations on the transformational environment. The Draco-PUC environment also uses a Lisp-like script language to control the execution of the system. This control involves a sequence of operations such as loading parsers for the required domains, parsing the input model les to generate a syntactic tree, loading the appropriate transformation les (including the pattern-related transformations), triggering the transformation engine, printing results using a pretty-printer, and more. These commands are stored in a .dsf le. In Draco, all the software construction processes are implemented as transformations. These transformations are described in one or more .tfm les and vary in complexity. Some may call user interaction routines or even trigger less complex transformations. In PIE, a pattern is speci ed as a composite transformation that determines a sequence in which simpler transformations are applied. This composite transformation also determines which and when user interaction routines will be called. Depending on the pattern, the result of the interaction may or may not a ect the execution of the subsequent transformations.
4 Related Work As the increase of interest in design patterns is relatively recent, pattern tools and support, in general, are still immature. In an e ort to develop the design pattern concept to be e ective in software development techniques, a few areas are being investigated. Most of this e ort is currently concentrated in representation languages, discovery of new patterns, reverse engineering, and the application of patterns solutions. In the area of pattern application, there are a few tools that generate speci cation templates based on the core of the product solution described by a pattern. The Automatic Code Generator [BFVY96] creates C++ templates for all the patterns described in design pattern catalog [GHJV95]. This tool also allows the selection of implementation trade-o s. The Designer's Assistant [ACL+95] generates Java, C++, or Smalltalk code from a selection of patterns. Code Navigator 2 is another pattern tool in which C++ templates are associated to the system under development. One advantage of the model in Figure 1 over all the code template generation tools described in the previous paragraph is that the nal product of an instantiation is already integrated into the system being developed. This is a result of every process of the pattern application operating directly over the system structures. Conversely, the above mentioned tools require an additional e ort to attach the generated code into the system. The Patterns Wizard [EYG97] is another tool that supports the automatic application of design patterns. Among the tools here described, the Wizard is the one which is closer in objectives to PIE. It also considers a process language to the instantiation of patterns. 2
a C++ development environment from Quintessoft Engineering, Inc. (http://www.quintessoft.com)
6
However, their process speci cations are based on a meta-programming language, which is a language to construct software speci cations. While this approach also guides the application process until the integration of the pattern, using a program (i.e., routines) to specify the changes in the software model is more complex than directly describing the transformations. Another distinction, is that PIE can support generation of pattern instances at both design and implementation levels, while the Wizard focus is on the implementation level.
5 Conclusion Creative or automated? The precise amount of automated support for the design pattern application process is yet to be investigated. However, two answers may already be discarded from the ideal software engineering perspective: \fully creative" or \fully automated". In our mind, the answer to the question lies somewhere between these two extremes. While automation provides tools to speed up the identi cation, evaluation, and application of design pattern, creativity is based in the identi cation of new patterns, the choice of which pattern to apply, and the trade-o s that may be necessary. In fact, the proportion between creative and automated tasks will mostly depend on the individual characteristics of each of the patterns. While for some patterns user interactions will be required frequently, for others automated tasks will be prevalent. It all depends on the level of abstraction and exibility of the proposed pattern solution.
References [ACL+95] P.S.C. Alencar, D.D. Cowan, K.J. Lichtner, C.J.P. Lucena, and L.C.M. Nova. Tool Support for Formal Design Patterns. Technical Report CS-95-36, University of Waterloo, Waterloo, Ontario, Canada, August 1995. [BFVY96] F. Budinsky, M. Finnie, J. Vlissides, and P. Yu. Automatic code generation from design patterns. IBM Systems Journal, 35(2), 1996. [Boe87] Barry W. Boehm. Improving Software Productivity. Computer, 20(9):43{57, September 1987. [EYG97] Amnon Eden, Amiram Yehudai, and Joseph Gil. Precise speci cation and automatic application of design patterns. In Proceedings of the 12th International Conference on Automated Software Engineering, Incline Village, Nevada, 1997. IEEE. [GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns. Addison-Wesley, Reading, Massachusetts, 1995. 7
[JC95]
R. Johnson and W. Cunningham. Introduction, in: John Vlissides, James Coplien, and Norman Kerth. Pattern Languages of Program Design 2. AddisonWesley, 1995.
[LSF94] Julio Leite, Marcelo Sant'Anna, and Felipe Freitas. Draco-PUC: a technology assembly for domain oriented software development. In Proceedings of the Third International Conference on Software Reuse, pages 94{100, Los Alamitos, CA, 1994. IEEE Computer Society Press. [Nei84] J. Neighbors. The Draco approach to constructing software from reusable components. Transactions on Software Engineering, 10(5):564{574, 1984. [R+91] James Rumbaugh et al. Object-Oriented Modeling and Design. Prentice Hall, 1991.
8
