Position Paper for OOSPLA '95 Workshop 32 Subjectivity in Object-Oriented Systems Dirk Riehle Union Bank of Switzerland, UBILAB P.O.Box 8021 Zrich, Switzerland Dirk BŠumer Projekt GeBOS, RWG GmBH Stuttgart, Deutschland Introduction ------------ The Tools and Materials Metaphor is a design methodology used to develop interactive software systems for skilled human work. One of its key concepts spanning the activities from analysis to design and implementation is the distinction of tool and material objects which are coupled using aspect classes. Subjectivity in system's design is acknowledged both on the software design level through the use of aspect classes and on the process level by a participatory and evolutionary approach. Several industrial and research systems have been built. The most important one is developed at RWG/Germany lead by Ute Buerkle, Dirk Baeumer and Ralph Knoll in cooperation with Guido Gryzan and Heinz Zuellighoven from the University of Hamburg. It has now roughly 1800 classes that span several related but distinct application domains [BGZ95]. Another project of this size is going to be developed at the Union Bank of Switzerland. Within these projects the problems discussed in [HO93] and the OOPSLA '94 workshop on Subjectivity in Object-Oriented Systems [HOSU95] became appearant. This position paper highlights some of our techniques of dealing with the problems on a software design level. It introduces a technique for automatic interface adaptations to new contexts. Finally, it points out which questions are currently most interesting for us so that they might be used as a starting point for focussed discussion at the workshop. The Tools and Materials Metaphor -------------------------------- The Tools and Materials Metaphor is used to build interactive software systems for people who are experts of their work and can take over the responsibility for it. Application domains are workshop like settings or office work. One of the central ideas of this approach is to make a distinction between tools, the means of work, and materials, the outcome of work. Users use tools to work on materials. Since tools cannot arbitrarily work on materials, the interfaces that materials offer to tools are made explicit as the so called aspect classes. An aspect class is the formalized description (a class interface) of a certain way of handling a material from a tool's point of view. Aspect classes are task specific, that is they group together all those operations that are needed to perform a certain task but nothing more. With aspect classes the problems discussed under "Subjectivity in Object-Oriented Systems" come into play. Different tasks require different tools that require different aspect classes from their materials to work properly. During development we discuss with users their way of handling materials. Each different tool with different requirements for a material's interface leads to the introduction of a new aspect class. By using aspect classes the different work contexts of different people from different application domains are acknowledged. The subjectivity of people and their different working tasks becomes explicit on the analysis level. We carefully work out suitable designs and implementation for it. Subjectivity in system's development on a process level has been discussed in the participatory design community and other schools on such depth and broad a scale that it cannot be discussed here. In the following, we'll therefore focus on our solutions on a software design level which currently pose the questions that are most interesting to us. Software Design --------------- It hasn't yet been discussed how aspect classes are attached to material classes. Aspect classes may carry policy, that is behavior, but no state. They are always abstract. Essentially, we make the following three distinctions. We first model a single inheritance class hierarchy of material classes from the relevant terms of the application domains. Doing so, we make the assumption that there still is some kind of core material that is more than just a shared object/material id, giving at least a suitable name. We then make a distinction between those aspect classes that we consider to be intrinsic to a material and those which we wish to appear only in certain contexts. In the first case, we use multiple inheritance. Aspect classes become mixin classes on an implementation level. Implementation of behavior promised through an aspect class as well as the necessary implementation state is located directly at the material itself. If an aspect class has to be attachable and detachable over time, we use wrappers. An aspect wrapper class is a subclass of an aspect class that adapts the aspect class's interface to a material. It is an object of its own with its own implementation state. It has to be made persistent distinct from the material it wraps. Since wrappers are objects themselves, we don't talk about an object id shared by several wrappers but about a material id. We thereby acknowledge that object-orientation is "just" an implementation paradigm used to implement higher level abstractions like materials in different contexts on which our focus rests. Sofar, it is deliberately visible whether an aspect class is attached via multiple inheritance or as a wrapper. We think that this distinction between intrinsic aspect classes and detachable aspect wrappers should not disappear. We're well aware that this distinction is a case by case decision that can be critized. However, our experience suggests that such an approach works even when a once single project splits up into several parallel projects with different but related application domains. Automatic Adaptation -------------------- The introduction of aspect wrappers, that is a number of wrapper objects grouped around a material core holding the material id, poses a number of difficult problems. It is not feasible for a certain set of tools, an application in traditional terms, to know all materials and to be able to create aspect wrappers for them by name. First, large and tedious case by case statements might arise and second, not all materials can be forseen but new material classes might be introduced during system evolution that can't be handled then. Given such a new situation, a tool faces the question how to find the right aspect wrapper (class) for a given material so that it can make use of it in terms of the required aspect classes. The aspect wrapper embedds the material into the tool context by offering the required aspect class interface. Essentially the tool that wishes to adapt a material to its context of use needs a mapping from material to a certain aspect class that stands for this context. It has to create or activate an aspect wrapper that both is an instance of a subclass of the aspect class and adapts this aspect class interface to the given material. More precisely, the tool is in need of a mapping f: AC x MC -> AWC, where AC is the set of aspect classes, MC the set of material classes and AWC the set of aspect wrapper classes. This mapping is constrained by the fact that for a given ac from the set of aspect classes the resulting awc from the set of aspect wrapper classes has to be a subclass of ac. In [Rie95] techniques are presented that solve these problems on a general level. The situation is best thought of as creating an object that both fulfills a certain class interface (the abstract aspect class) as well as an additional specification (it adapts the aspect class interface to a material). The first part ensures static typing so that a compiler can rely on this information, the second part ensures that the created aspect wrapper fulfills some more requirements that cannot be captured as a typing issue, that is its implementation succesfully adapts an interface to another interface. These techniques have been implemented very efficiently by introducing easy object-oriented specifications and using table lookups, so that they can be incorporated into basic framework design. In fact, they are almost as fast as factory methods but avoid the problem of hard coding future use contexts of materials into the material interface itself. Instead, these techniques go the other way round: From a given use context it is determined which the right adaptation is for an existing material class without bothering it. This ensures eased evolution without having to touch the original material in the first place. Conclusions and Open Questions ------------------------------ The key idea of the Tools and Materials Metaphor, the trinity of tool -- aspect class -- material has been pointed out and that it plays a crucial role both on a process and software design level to acknowledge subjectivity of different persons and for different use contexts. Issues of adapting old materials for new contexts due to evolutionary changes have been discussed. It has shortly been pointed out how this adaptation can be thought of and handled to ease system evolution. If details of these techniques both on a conceptual and implementation level are of interest to the workshop, the corresponding papers can be requested from the author. We're interested in the following topics of discussion: - Configuration issues: Assuming wrapper technology how can we ensure that the correct wrappers are included in their respective applications? What meta information do we need, how can we make it explicit and target of tool support? - Persistence and Consistency: Given wrappers with a state of their own that has to be persistent, how can we make them persistent separately and maintain consistency between different separate or derived states of other wrappers? Bibliography ------------ BGZ95 Ute Brkle, Guido Gryczan and Heinz Zllighoven. "Object-Oriented System Development in a Banking Project: Methodology, Experiences and Conclusions." Human Computer Interaction 10, 2&3 (1995): 293-336. HO93 William Harrison and Harold Ossher. "Subject-Oriented Programming (A Critique of Pure Objects)." OOPSLA '93, ACM SigPlan Notices 28, 10 (October 1993): 411-428. HOSU95 William Harrison, Harold Ossher, Randall B. Smith and David Ungar. "Subjectivity in Object-Oriented Systems." OOPSLA '94 Addendum, Workshop Summary, OOPS Messenger 5, 4 (October 1994): 131-136. OH92 Harold Ossher and William Harrison. "Combination of Inheritance Hierarchies." OOPSLA '92, ACM SigPlan Notices 27, 10 (October 1992): 25-40. Rie95 Dirk Riehle. "How and Why to Encapsulate Class Trees." OOPSLA '95, Conference Proceedings.