Position paper for Exploration of Framework Design Principles Dirk Riehle Ubilab, Union Bank of Switzerland Bahnhofstrasse 45, CH-8021 ZŸrich riehle@ubilab.ubs.ch Abstract Different levels of abstraction and modeling are now available to motivate, design and implement object-oriented frameworks. In this position paper, I discuss the relationships between patterns, role modeling, frameworks and framework implementations. I use a con- crete example as request by the call for position papers. 1 Introduction and Motivation An object usually collaborates with several other objects at once. These collaborations can be structured and focused on certain themes or tasks which they are intended to support. Thus a col- laboration is defined by the participating objects, the collabora- tionsÕ purpose, and by the roles the objects play within the col- laboration. A role defines the responsibilities of an object that wants to participate in the collaboration playing that role. Reen- skaug [1] calls such a collaboration role model and provides elaborate terminology and concepts for their modeling and imple- mentation. Kristensen and Osterbye [2] explore further metamodels for roles within conceptual programming. Role modeling lets us separate concerns on the level of object collaborations. This is helpful both on a conceptual modeling as well as on a software design level, because it makes systems eas- ier tractable. Since a role model is dedicated to a specific con- cern, but an object is usually concerned with many different is- sues at once, an object usually plays several roles, one or more in every role model instantiation. A role model instantiation rep- resents an operational context for an object, and changes to an object in one context cause it to act other contexts. The integra- tion problems of several roles in a single object, or context spe- cific components in a larger component, is addressed by subject- oriented programming [3], aspect-oriented programming [4], and the component composition community in general [5]. Recurring role models which fulfill their task well can be captured as patterns, called design patterns here (maybe role pattern is nicer). The design patterns in the design pattern catalog [6] can be explained well using role modeling, and I have done so already [7]. An example of a design pattern based on roles is the tree structure, define two roles Child and Parent, their relationships and the optional specializations Leaf and Root. As asked for by the workshop announcement, I will discuss a concrete example in which I explain a hierarchical self- stabilizing object structure in terms of the Composite, Mediator, Chain of Responsibility and Observer pattern. This object structure is itself a recurring pattern and has been described as the Bureaucracy pattern [8]. I will make the example explicit by discussing a framework design in which the Bureaucracy pattern was applied. This also lets me present our implementation techniques for implementing role models. They are straightforward and work well, however, they require interpretation to recognize the roles. Techniques like protocol mixin and decorators help, but are not optimal. For the workshop, IÕm interested in discussing further pragmatics of role modeling metamodels (is there a specialization relationship between roles?), in discussing how role modeling could be directly incorporated into object models as a modeling construct, and in discussing how to implement them efficiently given todayÕs restrictions. I close the paper by listing topics of my interests in further work and research. 2 The Bureaucracy Pattern Figure 1 shows the role diagram for the Bureaucracy pattern. I call it role diagram, because it allows inheritance between roles which is not possible in ReenskaugÕs role models. Figure 1: Bureaucracy pattern role diagram The Bureaucracy pattern lets developers build self contained hierarchical structures that can interact with clients on every level but need no external control and are capable of maintaining their inner consistency themselves. This pattern scales well to structure large parts of an application or framework. It is based on the idea of modern bureaucracy which seems to work well for software systems. Bureaucracy object structures form a hierarchy, in which a Manager object manages and coordinates its Subordinate objects. A Subordinate can be a Manager for further Subordinates. The structure of the pattern is governed by the Composite pattern, the distribution of responsibilities in the hierarchy is done according to the Mediator pattern, and the communication between Subordinates and Managers is structured according to the Chain of Responsibility and Observer pattern. I shortly list and explain the four patterns from which the Bureaucracy pattern is synthesized. Figure 2: Composite pattern role diagram The Composite pattern describes the roles in a hierarchical tree structure. It is crucial to remember that an object may play several roles, even within the same role model. Thus, an object playing the Parent role can also play the Child role for another object playing the Parent role. This is expressed by an inheritance relationship between Component (Child) and Composite (Parent) in the original class diagram for the pattern in [6]. Roles Leaf and Root represent the boundary conditions to the recursive structure. Whether a such a specialization relationship should be allowed in a role diagram is an interesting topic of discussion to me. It works so far. Figure 3: Mediator pattern role diagram The Mediator pattern defines a Mediator role which manages and coordinates some subordinate Colleague objects. No specific communication protocol is defined between a Colleague and its Mediator. Key is that Colleagues do not directly collaborate with each other but only via the Mediator. This decouples them from each other and makes the Mediator the center of changes, adaptation, mediation, and coordination. Figure 4: Chain of Responsibility pattern role diagram The Chain of Responsibility pattern defines a Handler role which can accept client requests, and a Successor to which the client request might be forwarded if the Handler cannot handle the request itself. At runtime, a chain of objects is built along which a client request is forwarded until it is handled. Figure 5: Observer pattern role diagram The Observer pattern defines a Subject and an Observer role. An object playing the Subject role can notify Observer objects about state changes so that they subsequently may update themselves. The notification is carried out using a general update interface. A well known pattern instance is the change/update mechanism of Smalltalk. These four patterns integrate with each other to form the Bureaucracy pattern. The Composite pattern lends its recursive tree structure to it, the Mediator pattern decouples the Subordinates and makes them subject to Management by their Manager, the Chain of Responsibility pattern defines the communication channel for forwarding requests up the hierarchy which a Subordinate cannot handle itself, and the Observer pattern defines how a Manager observes Subordinates to accommodate the hierarchy part it stands for to a SubordinateÕs state changes. 3 Framework Example The Bureaucracy pattern is used in many frameworks, including ET++, InterViews, HotDraw, PowerPlant as well as our own Tools and Materials Frameworks [9]. I review an application in our frameworks. The Tools and Materials Metaphor is an methodology used for developing software systems that support expert human work [10], [11]. Such work can well be interpreted as being carried out using tools and materials. Tools represent means of work and materials represent the outcome of work or its intermediate products. In a programming environment, compilers, browsers and editors are tools, and source code, class lists, symbol tables, and project structures are materials. In a banking environment, form editors and copiers, customer browsers and searchers are tools, and contract forms, yield curves, meeting protocols are materials. Users use tools to work on materials; they combine them in a flexible way based on intermediate coupling links representing the behavior a tool expects from a material. It is always a tool that users use to work on a material, and never vice versa. Tools exhibit a regular structure which makes them a nice target for framework support. They are recursively composed from subtools, thus forming a hierarchy of tool components. The central part of a tool component is its functional part which comprises all the functionality the tool component offers. This functionality is defined by both the way users handle this tool (component) and the required manipulative effect on materials which this tool is used to work on. The tool composition structures is best explained using the Bureaucracy pattern. I restrict the discussion to the functional part of a tool component. A functional part (fpart) may have one or more sub functional parts (Composite pattern), it integrates, manages and coordinates its subfparts (Mediator pattern), it receives client requests from subfparts which cannot be handled by them (Chain of Responsibility pattern), and it observes its subfparts in order to react to state changes of them which happened due to fulfilling a client request (Observer pattern). All this works together as discussed by the Bureaucracy pattern. Thus, the Bureaucracy pattern can be instantiated to provide the role diagram for the fpart hierarchy. This is shown in figure 6. Figure 6: Role diagram for FPart hierarchy The implementation of the FPart hierarchy role diagram based on traditional object-oriented concepts like classes leads to the structure depicted in figure 7. The actual framework part are the abstract classes denoted by italic class names and a 2pt thick border. The framework consists of three classes, which is very small, but provides a highly complicated control flow. The other classes in the figure stem from an example I use for explaining the Bureaucracy pattern. Figure 7: Class hierarchy for implementing the FPart hierarchy role diagram The class based framework design draws on standard class structures as demonstrated by Gamma et al. in [6], and on a set of conventions we use for implementing role diagrams: - At the heart, a single inheritance class hierarchy is devised which represents a classification hierarchy of the key concepts as derived from or interpreted upon an application domain. - Roles are expressed as role protocols which are mixed inÑin case of single inheritance systems, the protocol is copied. Consistency is maintained using tools like the Aspect Browser in [12]. - Finally, if a specific role should be attachable and detachable over time, we use wrappers or decorators to adapt an object to specific contexts, that is to the participation in a specific role model instantiation. The major open problem is the state integration if we resort to using wrappers for context adaptation. As pointed out in the introduction, though, many people are working on these topics now. 4 Workshop Perspective Topics of interest to me comprise the following thoughts and problems: - State integration, if a single conceptual object is split into several technical objects. If the implementation state is spread over the objects, it must be kept persistent in different places and a proper mapping must be maintained. If the state is centralized, a metalevel access is required which makes proper static typing and checking mechanisms hard. - Role modeling concepts. Should role models allow for subtyping relationships between roles as argued for by Kristensen and Osterbye [2]? How do proper metalevel models look like? - Mismatch between classification hierarchies and role modeling. In the example I mentioned that we still focus very much on providing proper abstraction and classification hierarchies. This is a traditional technique not addressed by role modeling. How can both be integrated well? We currently do a classification hierarchy first and then map role models as behavioral specifications to those hierarchies. Finally, I hope to have a good time and meet interesting people at the workshop. References [1] Trygve Reenskaug, with Per Wold and Odd Arild Lehne. (1996). Working with Objects. Greenwich, Manning. [2] Bent Bruun Kristensen and Kasper Osterbye. ÒRoles: Conceptual Abstraction Theory and Practical Language Issues.Ó Theory and Practice of Object Systems. To appear. [3] William Harrison and Harold Ossher. ÒSubject-Oriented Programming (A Critique of Pure Objects).Ó OOPSLA Ô93 ACM SIGPLAN Notices 28, 10 (October 1993): 411-428. [4] Gregor Kiczales, John Irwin, John Lamping, Jean-Marc Loingtier, Cristina Videria Lopez, Chris Maeda, and Anurag Mendhekar. ÒAspect-Oriented Programming.Ó http://www.parc.xerox.com/spl/projects/aop/. [5] ECOOP Ô96 Workshop on Composability Issues in Object- Orientation. http://wwwtrese.cs.utwente.nl/cioo96/. [6] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. (1995). Design Patterns: Elements of Reusable Design. Reading, Massachusetts: Addison-Wesley. [7] Dirk Riehle. ÒDescribing and Composing Patterns Using Role Diagrams.Ó WOON '96 (1st Int'l Conference on Object-Orientation in Russia), Conference Proceedings. St. Petersburg Electrotechnical University, 1996. [8] Dirk Riehle. ÒBuerocracyÑA Composite Pattern.Ó To be submitted to PLoPD-3. [9] Dirk Riehle and Heinz ZŸllighoven. ÒA Pattern Language for Tool Construction and Integration Based on the Tools and Materials Metaphor.Ó In Pattern Languages of Program Design. Edited by James O. Coplien and Douglas C. Schmidt. Reading, Massachusetts: Addison-Wesley, 1995. Chapter 2, page 9-42. [10] Ute BŸrkle, Guido Gryczan and Heinz ZŸllighoven. "Object- Oriented System Development in a Banking Project: Methodology, Experiences, and Conclusions." Human Computer Interaction 10, 2&3 (1995): 293-336. [11] Dirk BŠumer, Guido Gryczan, Ralph Knoll, and Heinz ZŸllighoven. ÒLarge Scale Object-Oriented Software-Development in a Banking EnvironmentÑAn Experience Report.Ó LNCS 1098, ECOOP Õ96, Conference Proceedings. 73-90. [12] Dirk Riehle, Bruno SchŠffer and Martin Schnyder. ÒDesign of a Smalltalk Framework for the Tools and Materials Metaphor.Ó Informatik/Informatique (February 1996): 20-22.