This page gives some information about the patterns tools we have worked on at the Computer Science Department of Utrecht University. I'm continuing some of this work at SERC, but in a different form and using a different approach. If you have suggestions or comments, let me know. Mail me also if you cannot print the documents or would like to have them in a different format. The software is still available here but it's not maintained in anyway. If you don't know what patterns are about, look here for some information.
Our current work focuses on RevJava.
I believe that patterns make it possible to talk about (and perhaps also think about) designs on a higher level of abstraction. Instead of thinking in terms of individual classes and their behaviour, we can start to think in terms of collaborating classes, their relations and responsibilities. In early design it is enough to know that you're using a pattern at some point. The details about how this pattern is actually implemented can be filled in later.
So with patterns we - at least conceptually - have larger scale building blocks from which to compose systems. Given a broad collection of patterns on different scales (e.g. architectural patterns vs. design patterns vs. language-idioms) it should be possible to combine and glue together patterns into a design that can be mapped to different programming languages.
Of course, this could be supported by a suitable, pattern-based development environment. The problem however is that patterns aren't formalized descriptions as, for instance, contracts. Patterns don't prescribe a specific, concrete objectmodel. They suggest a general solution and give you freedom as to how to put them in the design and how to implement them. The issue therefore is to see whether the inherent informality and freedom of the pattern format can be unified with the idea of a pattern-based development environment.
Since we want to work on different levels of abstraction a pattern-based development environment should provide 3, mutually consistent views:
We have created a first prototype of such an environment aimed at developing object-oriented programs with patterns. The tool assists developers using patterns in three ways:
Through the use of an existing refactoring package (the Smalltalk Refactoring browser, the tool supports the use of patterns both in forward engineering and in backwards engineering, i.e. documenting occurrences of patterns in existing programs and modifying the program to better reflect the pattern's structure. The tool is implemented in Smalltalk and has been applied to identify pattern occurrences in several non-trivial (Smalltalk) applications and to reorganize these subsequently.
An overview of the tool and the underlying architecture is described in a paper published at ECOOP'97. You can get it here as a gzipped Postscript file. An older and preliminary paper on this work is also available (as gzipped postscript).
The layers in the tool are depicted in the picture above. The fragment model/database store the program being developed as a graph of design elements such as classes, method definitions, inheritance relations, etc.. The suite of design elements can be extended easily through the introduction of new fragment types. Design patterns are also design elements and represented as fragments. The fragment model/database can be manipulated directly with the fragment browser and inspector. Higher level support is offered through the OMT-tool which provides an OMT view of the program (click for here a screen-shot) , and code tools such as the familiar Smalltalk class browser.
Marco Meijers developed the fragment model for the representation of programs as a constellation of design elements. The fragment model allows integration of pattern occurrences with the program representation. Pattern fragments are defined as a combination of structural elements (class-roles, method-roles that must be fulfilled, inheritance relationships, etc.) and constraints that restrict the reorganizations that can take place on the design level, and that code - in an abstract way - what the pattern really is about. The fragment model allows easy definition of new structural elements (e.g. an instantiation relation between a method and a class, indicating that this method creates instances of a particular class), new patterns using them together with the constraints, and designs based on them. The structure definition of a pattern (e.g. Observer) also forms a prototype for use of a pattern in a design. You insert the basic structure into your design and get the classes, methods, relations among classes, etc. defined in the structure. After that you adapt the design (e.g. combine different class-roles into one class, collapse hierarchies, etc.). The constraints associated with the patterns will keep checking whether the essential parts of a pattern are still valid, and report errors or automatically adjust and repair the design when needed. Marco's master thesis goes into the details. It is available as a gzipped Postscript file.
Pieter van Winsen started out with the fragment model and looked at how we can create a higher-level development environment based on fragments and using patterns. An important goal was to identify and document pattern occurrences in existing software (Smalltalk programs) and to reorganize these programs subsequently. Pieter has created a layer on top of the fragment database that supports this. The layer offers an OMT view of the program (click for here a screen shot) with the ability to reorganize the program (through refactoring operations offered by the Smalltalk Refactoring browser). With the tool you can also add patterns to the program and visualize which elements of your program fullfill roles in particular pattern instances. In addition, via the tool you can also view/modify the code of your application. Pieter's master thesis also describes some experiences in documenting and reorganizing non-trivial existing Smalltalk applications. His thesis is available on-line as a gzipped postscript file.
It turns out that representing patterns via constraints is tricky. People have different opinions about what a pattern is. Also, not all patterns lend themselves to easy representation. Dennis Gruijs therefore took a fresh look at the problem of tool support. The ideas he came up with are described in his thesis but are not yet implemented.
Last modified: 06/02/03
