Design patterns and frameworks have become important concepts in object development. As well important is UML as the standard modeling language. But there is not sufficient support to model design patterns and frameworks in design class diagrams (DCDs) without using the extension mechanisms, that is, stereotypes, constraints, and tagged values. Some approaches have been developed to improve the representation by extending UML. But they are either not comprehensive, or not well-defined, or don't consider the granularity or complexity of DCDs. In this paper we present a more comprehensive and well-defined approach by using an example, distinguish between DCDs, detailed DCDs, and design pattern CDs, define UML profiles for the extensions, and outline how an UML tool can support the approach.
Object-oriented techniques such as frameworks  and design patterns  make designs more flexible, extensible, and reusable. When documenting the design in a framework or when documenting the structure of a design pattern developers usually use UML [3, 2, 9] design class diagrams (DCDs). But standard UML DCDs often don't provide important information necessary to understand or extend the design.
To solve this problem several approaches have been suggested [1, 5, 6, 7, 10]. The most important approach is described in  and called UML-F. The authors suggest to use the UML extension mechanisms, that is, stereotypes, constraints, or tagged values, to represent the designs in frameworks. But their approach suffers from several shortcomings. First, they don't clearly distinguish between the three kinds of extension mechanisms and they don't define UML profiles for the extensions (until recently ). Second, their extensions are not comprehensive and there exist several more extensions that are useful in understanding the design. Third, they consider only partly the granularity of DCDs, such as distinguishing between DCDs and detailed DCDs. Finally, they don't consider the surface or complexity of DCDs, that is, which mixture of extensions and diagrams result in an easy to understand DCD.
The approach described in  uses the extension mechanisms to improve the representation of so called configuration design patterns. Hence, this approach is used to represent the static structure of some design patterns. But it resembles partly the approach in UML-F and has also the problem that it is not comprehensive.
The approach described in  emphasizes the distinction between whitebox and blackbox hotspots or variation points. The approach is based on changing the visual appearance of DCDs and hence is not compatible with standard UML. Furthermore it is certainly not comprehensive.
Another approach, based on designing a system as a composition of design patterns, is described in . Such an approach might be appropriate for some systems, but it is certainly difficult to apply for many kinds of systems. It requires detailed understanding of many design patterns and their interaction.
A similar but more general approach is described in . The authors propose the use of role diagrams to explicitly document the interaction between classes. Such role diagrams are not part of standard UML. Furthermore they don't explicitly model variation points and their instantiation.
In this paper we present an approach that extends the work done before. It is aimed to be more comprehensive and well-defined. To illustrate our approach we use an example from an easy to understand application domain: a grade recording framework. First we design the system with common DCDs, then we design the system again with DCDs that contain our proposed extensions. After having hopefully convinced the reader that our extensions help in understanding or extending a design, we provide definitions of all extensions as UML profiles. The approach distinguishes between DCDs, detailed DCDs, and design pattern CDs, and this distinction should be reflected in an UML tool. So, we also explain how we changed an existing UML tool so that it supports this distinction.
2 EXAMPLE: DEVELOPING A GRADE RECORDING SYSTEM
Assume that we want to develop a framework for recording grades. Such a system can be used at any school, university, or company to record the grades. Here we don't consider developing the full requirements for this application. We assume that developing the full requirements or domain model might reasonably result in our parts of a design, although other designs are certainly possible.
In such a domain there exist certainly classes to represent students, teachers, lectures, tests, etc. Teachers might offer reports, written and oral examinations, and many other kinds of tests. A natural representation for such a structure uses the Composite pattern . A partly unresolved issue is the procedure of how teachers compute the grades. Often teachers collect several grades and compute the final grade by using a certain weighting function for the subgrades. But there is a lot of variety in how the final grade is computed. So, we assume that the class 'Test' has some varying method 'compute' to compute the final grade out of the subgrades. The initial design of the framework is shown in the DCD in Figure 1.
In the following we consider how the variation point in this design should be implemented. Different teachers usually use different weighting functions and even one teacher usually uses different weighting functions for different lectures. So, it is reasonable to assign the responsibility to implement the weighting function to the class 'Lecture' and use the Strategy pattern  to implement the method 'compute' in class 'Test'. The resulting design is shown in Figure 2. We call this DCD a detailed one because it cannot be refined anymore and the implementation of the variation point has been resolved.
3 USING UML EXTENSIONS IN THE EXAMPLE
In this section we will show the same DCDs for our grade recording framework but add some information using the standard UML extension mechanisms, that is, stereotypes, constraints, and tagged values. We explain which additional information these extensions reveal and argue that those information is important in understanding or extending the design. Finally we argue that the detailed DCDs in Figure 2 and 4 are both complex, that is, its visual appearance and understanding are complex. So, we introduce another extension, namely tagged values that indicate the roles of participants in design patterns. In cases where the appearance of a DCD becomes too complex by using collaboration diagrams, these tagged values might be preferable.
Figure 3 shows the DCD of Figure 1 but contains two extensions. These extensions provide us the following information:
The detailed DCD of Figure 2 with the added extensions is shown in Figure 4. The extensions provide us the following information:
Another important aspect in representing designs as DCDs is the complexity of the layout and the visual appearance. In some cases, such as in Figure 2, using collaboration diagrams to illustrate design patterns, might result in a DCD that is difficult to understand. So, we suggest to use in such cases tagged values as an alternative. The resulting detailed DCD is shown in Figure 5. In case some kind of automatic or semi-automatic layout is supported in a tool, the visual appearance depends on the layout algorithm. But we think that there are always cases where tagged values are preferable to collaboration diagrams.
4 UML PROFILES FOR ALL EXTENSIONS
After having explained some of the extensions using an example in the previous sections, we provide a complete definition of all extensions in this section. That is, we provide explanations of all extensions in natural language and define UML profiles  for them.
First we provide an overview of all extensions and classify them according to their purpose or use. Figure 6 shows all extensions and classifies DCDs in three kinds: DCDs, detailed DCDs, and design pattern CDs. The extensions for each kind of DCD vary although some are in common. The distinction between a DCD and a detailed DCD have been described in the example given before. A detailed DCD results from a DCD by resolving the variation points. A design pattern CD is used to describe the static structure of a design pattern. We don't give an example of a design pattern CD here, but we developed one for the design pattern to implement enumerated types in Java as described in . This pattern can alternatively be used to represent the different kinds of tests in our example.
The different kinds of UML class diagrams don't necessarily correspond to different iterations in an iterative and adaptive development process . In our grade recording example the given DCD and detailed DCD can be produced in one iteration in case the variation point is considered an important part of the core architecture of the system. But they can as well be produced all in different iterations.
UML Profile for Design Patterns
Description of Stereotypes in the UML Profile for Design PatternsWe define four stereotypes in the UML profile for design patterns: <<InstanceClass>>, <<ForAllNewMethods>>, <<Template>>, and <<Hook>>, (see Table 1).
Description of Tags in the UML Profile for Design PatternsWe define three tags in the UML profile for design patterns (see Table 2):
UML Profile for Frameworks
Description of Stereotypes in the UML Profile for FrameworksWe define four stereotypes in the UML profile for frameworks (see Table 3). The only difference to design patterns is the use of <<ApplicationClass>> instead of <<InstanceClass>>
Description of Tags in the UML Profile for FrameworksWe define five tags plus a special set of tags in the UML profile for frameworks (see Table 4). The meaning of three tags is the same as or analogous to the meaning in the profile for design patterns. The meaning of the additional tags is as follows:
5 SUPPORT IN AN UML TOOL
We distinguish in our approach between three kinds of DCDs as shown in Figure 6. An UML tool should reflect this distinction and their relationships and provide an appropriate functionality. For example if an UML tool shows a DCD with a variation point it should be possible to easily switch to a detailed DCD where a variation point is instantiated, for example by selecting a menu item. Similar the opposite direction should be supported. The user might not be familiar with a certain design pattern and hence it should also be easy to switch forward and backward to a design pattern CD or full definition of a design pattern.
We implemented some part of the above functionality by extending an open source UML modeling tool, Argo/UML . We added support of the standard UML extension mechanisms and the possibility to switch between DCDs and associated detailed DCDs. The output of a detailed DCD is shown in Figure 7.
Representing design patterns and frameworks in UML with DCDs is not adequate when using no extensions. In this paper we present several extensions based on using the standard extension mechanisms of UML, that is, stereotypes, constraints, and tagged values. Our contributions are:
Future work should collect experience in using our approach.
 Marcus Fontoura and Wolfgang Pree and Bernhard Rumpe, UML-F: A Modeling Language for Object-Oriented Frameworks, In Proceedings of the European Conference on Object-Oriented Programming (ECOOP 2000), pages 63-82, Springer, LNCS, Vol. 1850, 2000
Cite this article as follows: Yasunobu Sanada, Rolf Adams: "Representing Design Patterns and Frameworks in UML - Towards a Comprehensive Approach", in Journal of Object Technology, vol. 1, no. 2, July-August 2002, pp. 143-154, http://www.jot.fm/issues/issue_2002_07/article3