Chapter 6: Case Study: The Geo Object Framework

This chapter presents a first case study: the Geo Object framework. This framework is the root framework of the Geo system, a distributed object system based on an explicit metalevel architecture. The Object framework comprises the most fundamental classes of a Geo system: Object, MetaObject, Class, MetaClass, and others. The chapter presents the framework and discusses the experiences of its development team with designing, learning, and using the framework. While doing so, the team made explicit use of role modeling and the role-model-based catalog of design patterns. This framework is of particular interest, because many systems today have such a root framework. The Geo system is only one example; other examples are Smalltalk and Java in general, and various C++ application frameworks.

6.1 Case study overview

The Geo system is a distributed object system that has an explicit metalevel architecture. It is organized as a service architecture and implemented using frameworks. All of the frameworks build on the Object framework, which is discussed in this chapter.

6.1.1 Project history

The Geo system was developed at Ubilab, UBS AG, during 1997. Its primary goal was to evaluate and demonstrate novel design concepts for a metalevel architecture that allowed programmers to customize object behavior on a per-instance basis. However, the metalevel architecture is only a small part of the system. The largest part are the service frameworks that made Geo a distributed system.

The Geo system was part of a project that was jointly run by Kai-Uwe Mätzel and me. The Geo frameworks were designed and implemented by a team that over time consisted of the following members: Roger Brudermann, Bruno Essmann, Frank Froese, Patrizia Marsura, Kai-Uwe Mätzel, and me. In the following, "the team" refers to this team, and "team members" refers to one or several of its members, depending on the context.

The team cooperated with the GBO project, another UBS IT project. GBO ("Global Business Objects") was a much larger project [BGR96a, BGR96b] that had been started in 1996. It aimed at providing a new distributed object infrastructure for UBS' worldwide IT operations. GBO was to integrate the many existing heterogeneous systems through means of a metalevel architecture. The goal of developing the Geo system was to feed back the results from the metalevel architecture into GBO. However, in course of the UBS/SBC merger development was stopped, and the project eventually was terminated.

As a consequence, different parts of the Geo system have different maturity. The framework presented in this chapter is very mature. It has formed the foundation for most other frameworks of the Geo system and proved its reliability.

6.1.2 The case study

The Geo Object framework is the root framework from which all other frameworks in the Geo system inherit. It defines key classes like AnyObject, from which every other class in the system either directly or indirectly inherits. The Object framework defines the overall structure of the metalevel architecture, but also allows for customization so that extensions can introduce their own custom-tailored versions.

In Geo, every object has a metaobject that can be customized with RequestHandler objects. Each such request handler manages one particular functional aspect of the execution of a method of the baseobject. The metaobject itself coordinates the overall method execution process. This setup is similar to the one of CodA [McA95a, McA95b], with the difference that the project team was not interested in the primitive aspects of an object (a minimal object model), but rather in what an object needs in a distributed system. So the functional aspects team members were thinking about were logging, security, error handling, etc.

The Object framework is based on experiences with similar frameworks and on-going refinement during the development of the Geo system. Every other framework in the Geo system directly or indirectly has to use it, so everyone who works with the Geo system has to learn it.

In the design and implementation process of Geo, the team members made frequent use of role modeling. While doing so, they also used the design patterns catalog that presents patterns using role models [Rie97a]. An abbreviated version of this catalog is available as Appendix D.

6.1.3 Chapter structure

The next section describes the Object framework using the framework documentation template from Chapter 4. The section also shows how the Object framework has been used by one higher-level framework, the Object Transport Service framework. The final section then describes the team's experiences with using role modeling in the development of the Geo Object framework and two of its extensions.

6.2 The Geo Object framework

The Geo Object framework provides basic object and class management functionality for a Geo process. It defines the classes AnyObject, AnyClass, and MetaClass for objects and classes, MetaObject and RequestHandler for handling and executing object requests, and ObjectRegistry and ClassManager for managing objects and classes. These are the most important classes that represent the interface architecture of the framework; the implementation of the framework provides many more classes.

6.2.1 Framework overview

The Object framework is the root framework of all Geo frameworks. It is both a white-box and a black-box framework. It is a white-box framework, because new classes necessarily inherit from AnyObject or AnyClass, and it is a black-box framework, because it provides readily usable implementations of MetaClass, ObjectRegistry, and ClassManager.

The framework provides different categories of functionality.

• Standard AnyObject functionality. AnyObject and AnyClass define what it means to be an object in a Geo system. This comprises a wide set of functionality, directly offered to clients.
• Request handling functionality. AnyObject, MetaObject, and RequestHandler define how a request is executed by any instance of (a subclass of) AnyObject.
• Object management functionality. AnyObject, AnyClass, and ObjectRegistry define the minimal lifecycle management applied to any object in the system.
• Class management functionality. AnyClass, MetaClass, and ClassManager define additional lifecycle management that is applied to any class object in the system (class objects are instances of AnyClass).

Subsection 6.2.2 presents the class model of the framework. It comprises a discussion of the classes and the structural relationships they define for their instances. Subsection 6.2.3 then presents the role models that define the collaboration of instances of these classes.

6.2.2 Class model

Figure 6-1 shows the seven key classes of the Geo Object framework, together with their structural relationships.

Figure 6-1: Class model of the Geo Object framework without role models.

These seven classes serve the following purposes:

• AnyObject defines functionality provided by every object in a Geo system. The functionality covered ranges from simple operations that provide an object identifier up to a metaobject protocol that lets clients request metadata about the object at hand. AnyObject relates to all other classes of the Object framework. It is the direct or indirect superclass of every class in the system.
• MetaObject is the (super-)class of all metaobject classes in a system. Every instance of AnyObject has a metaobject. An instance of the MetaObject class defines the configuration and execution of incoming requests of the baseobject the instance is responsible for. A metaobject handles accepting, queueing, processing, and dispatching of a request. It allows custom-tailoring the runtime behavior of its baseobject.
• RequestHandler is the (super-)class of all request handlers. Every metaobject may have several request handlers associated with it. A metaobject runs any incoming request by its request handlers. A request handler may change or veto a request. A request handler is devoted to a particular request execution concern, for example to logging the request, decrypting it, or authenticating the originator.
• AnyClass is the (super-)class of all class objects. A class object represents a specific class. Every instance of AnyObject has a class object. Each class object may have several instances. In contrast, to class objects, there is one dedicated metaobject for each baseobject (at least conceptually). AnyClass defines all the class-level functionality needed by an object. It provides metadata, identifier, stubs, etc.
• ObjectRegistry is the class of the singleton object registry. AnyClass is responsible for creating and deleting its instances. It manages these objects through the use of the object registry. ObjectRegistry focuses solely on providing convenient access to objects using either a unique identifier or a name that an object has been given.
• MetaClass is the (super-)class of the class object of all class objects. It is a subclass of AnyClass. The instance creation process of AnyClass is too simple for classes, so MetaClass provides more elaborate functionality and ensures that all pieces fit together. MetaClass implementations vary with each system type (front-end browser, application server, and distributed service provider).
• ClassManager is the class of the singleton class manager. The class manager provides a convenient access interface to all classes of a system. A class can be retrieved using its fully qualified name. If needed, the class manager lazily creates a requested class using the metaclass object.

The following role models detail the role types from the role type sets of these classes.

6.2.3 Role models

The overall set of role models defined in the Geo Object framework can be partitioned into several categories:

• AnyObject role models. These role models are binary: they relate a client role type with a role type provided by AnyObject that provides some basic functionality.
• AnyObject and AnyClass role models. These role models relate AnyObject and AnyClass instances with each other, with the focus on AnyClass as the primary service provider.
• Request Handling. These role models deal with executing an incoming request. Represented as an object, the request is processed by RequestHandler objects before it is dispatched to its target.
• Instance management. These role models deal with maintaining objects as instances of classes in an object registry. AnyClass and ObjectRegistry work together to maintain the objects.
• Class management. These role models deal with the management of class objects. Management includes creating and maintaining class objects in a registry. MetaClass and ClassManager do it.

6.2.3.1 Role models of basic object functionality

The first part describes the standard AnyObject functionality, and the second part describes the AnyObject/AnyClass collaboration. Figure 6-2 shows the role models that are relevant in this context.

Figure 6-2: AnyObject and AnyObject/AnyClass role models.

The following first part describes the AnyObject role models.

• The Reader role model serves to initialize an object from a data-oriented backend. A Client tells an object, the Readable, to read and subsequently initialize its state from another object, the Reader. It is an instance of the Serializer pattern. AnyObject provides the Readable role type, and Client and Reader are free role types.

  The Reader role type provides operations to start the reading process for a Readable, as well as operations for the Readable to request its state. The Readable role type in turn provides operations to receive the Reader from which to read its state, as well as post-processing operations after the reading took place. Graphs of objects are read by a recursive descent into the graph, realized by the Reader and Readable alternatingly calling each other.

• The Writer role model serves to write the state of an object to a data-oriented backend. A Client tells an object, the Writable, to write its state to another object, the Writer. It is an instance of the Serializer pattern. AnyObject provides the Writable role type, and Client and Writer are free role types.

  The Writer role type provides operations to start the writing process for a Writable, as well as operations for the Writable to write out its state. The Writable role type provides operations to receive the Writer it is to write its state to. Graphs of objects are written by a recursive descent into the graph, realized by the Writer and Writable objects, which alternatingly call each other.

• The Identifying role model makes an object provide a unique identifier (of it). A Client may request an identifier from an object, the Identifiable. If no identifier is present, the Identifiable requests it from its class, the IdProvider. AnyObject provides the Identifiable role type, AnyClass provides the IdProvider role type, and Client is a free role type.

  The Identifiable role type provides operations to get and set the identifier, as well as to compare two objects for identity with respect to their identifier. The IdProvider role type provides operations for the Identifiable to request an identifier. Typically, an object does not receive an identifier right from the start, but only when it is needed, for example, when it is referenced remotely for the first time.

• The Cloning role model serves to make shallow or deep copies of an object. A Client may ask an object, the Clonable, for a copy of it. AnyObject provides the Clonable role type, and Client is a free role type.
• The Comparing role model serves to compare two objects for equality. A Client may ask an object, the Comparable, to compare itself with another object. AnyObject provides the Comparable role type, and Client is a free role type.
• The DictionaryKey role model allows an object to act as a key. A Client can use the object as a Key. AnyObject provides the Key role type, and Client is a free role type.

The following second part describes combined AnyObject/AnyClass functionality.

• The ObjectCreation role model serves to create a new instance of a class. A Client object asks a Creator object to create the new Product object. AnyObject provides the Product role type, AnyClass provides the Creator role type, and Client is a free role type.

  The Creator role type defines operations for generically requesting a new instance. The Product role type defines generic initialization operations. For example, it receives a unique identifier and a reference to its class object. The ObjectCreation role model does not cover class-specific initialization, which must be done by a different dedicated role model.

  Upon successful creation, the Creator registers the new instance at the ObjectRegistry using the ObjectRegistry role model.

• The ObjectDeletion role model serves to delete an existing instance of a class. A Client object asks the Deletor object to delete the Target object. AnyObject provides the Target role type, AnyClass provides the Deletor role type, and Client is a free role type.

  The Deletor role type defines operations by which an existing object can be deleted. The Target role type defines a protocol for finalizing the object.

  Before deletion, the class object unregisters the object from the object registry.

• The ClassObject role model serves to provide metadata about an object. It is an instance of the Class Object pattern. A Client object can ask the Instance object about its Class object. AnyObject provides the Instance role type, AnyClass provides the Class role type, and Client is a free role type.

  The Instance object lets Clients request the Class object. The Client object may request metadata both from the Instance or the Class object. Only the Class object, however, provides the full set of metadata. For example, the Class object provides metalevel access to the attributes, behavior definition, and implementation of a given instance.

• The RemoteObject role model serves to make objects remotely referencable. A Client may ask a class, the StubProvider, to make an object, the Remotable, remotely accessible. AnyObject provides the Remotable role type, AnyClass provides the StubProvider role type, and Client is a free role type.

  The StubProvider role type provides operations to receive a stub for an object, decouple an object from the stub, etc. The Remotable role type provides operations to get and set the stub.

6.2.3.2 Role models of request handling

The following third part describes how incoming requests are handled and executed. The relevant role models are shown in Figure 6-3.

Figure 6-3: Classes and role models involved in the request handling process.

• The BaseObject role model defines how a Client may ask an object, the BaseObject, about its metaobject, the MetaObject. It is an instance of the Metaobject pattern. AnyObject provides the BaseObject role type, MetaObject provides the MetaObject role type, and AnyClass provides the Client role type. The Client role type is also a free role type.

  The BaseObject role type provides operations to get the metaobject. The MetaObject role type provides those operations that the baseobject wants to delegate to the metaobject, for example, error logging.

  Conceptually, there is one metaobject for each baseobject, but in practice, metaobjects can be shared among baseobjects. Therefore, all operations of the metaobject require a reference back to the baseobject they are to work on or provide services for.

• The MOConfiguration (MetaObjectConfiguration) role model defines how a Client object may configure a metaobject, the Manager, with a Handler for processing requests. MetaObject provides the Manager role type, RequestHandler provides the Handler role type, and Client is a free role type.

  The Manager role type provides operations for the Client to insert a Handler at a certain position in the chain of request handlers along which a request is passed.

• The MetaObject role model defines how a Client may ask a MetaObject to execute a request. MetaObject provides the MetaObject role type, and Client is a free role type.

  The MetaObject role type provides operations to receive an incoming request and to inquire about the current request processing state.

• The RequestHandler role model defines how a metaobject, the Client, passes a request along a set of Handler objects. MetaObject provides the Client role type, and RequestHandler provides the Handler role type.

  The Handler role type provides the operations to process a request. A handler might do nothing to a request, change it, or veto it.

• The RequestDispatch role model defines how a metaobject, the Client, hands over a Request object to its baseobject, the Target, for dispatch (also known as dynamic invocation interface). The Target dispatches the request to one of its operations. MetaObject provides the Client role type, and AnyObject provides the Target role type.

  The Target role type provides operations to receive the request object, which it then dispatches to the correct operation.

6.2.3.3 Role models of object and class management

The fourth part describes the role models for managing objects in an object registry. The fifth part describes role models for creating and maintaining class objects. Figure 6-4 shows the role models and the involved classes.

Figure 6-4: Classes and role models for managing objects and classes (grayed-out role models are not discussed here).

The following fourth part describes the role models associated with the ObjectRegistry.

• The ObjectRegistry role model serves as a central access point to all objects in the process. It is an instance of the Object Registry pattern. A Client object may ask the Registry object about any particular Element object. ObjectRegistry provides the Registry role type, AnyObject provides the Element role type, and AnyClass provides the Client role type. Client is a free role type.

  The Registry role type provides operations to register and unregister Elements using object identifiers and names.

  Within the framework, AnyClass provides the Client role type. AnyClass objects use it to register or unregister their instances at the ObjectRegistry.

• The ORSingleton role model (ObjectRegistrySingleton) serves to provide convenient access to the single ObjectRegistry object. It is an instance of the Singleton pattern. It is shown in Figure 6-4 using the singleton shorthand.

The following fifth part describes the role models for creating and managing classes.

• The ClassCreation role model serves to instantiate new class objects. A Client object may ask the Creator object to create a new Product object. AnyClass provides the Product, MetaClass provides the Creator, and ClassManager provides the Client role type. Client is a free role type.

  The Creator role type provides convenience operation to instantiate new class objects using the most common combinations of parameters. Class objects in the Geo metalevel architecture are configured with a large number of parameters. The Product role type provides initialization operations to receive these parameters.

  Creation of a class object is a special case of creation of a regular object, so the ObjectCreation role model is used to setup the Object related parts of the new class object. Also, the ObjectRegistry role model is used to register the new class object at the ObjectRegistry, using its identifier and class name.

• The MCSingleton role model (MetaClassSingleton) serves to provide convenient access to the single MetaClass object. It is an instance of the Singleton pattern and shown in the figure using the singleton shorthand.
• The ClassManager role model serves to provide a central access point to all classes of a process. A Client may ask the Manager for an Element. Class provides the Element role type, ClassManager provides the Manager role type, and Client is a free role type.

  The Manager role type provides operations to register and unregister class objects using their class name. If a class is not available, the class manager loads it on the fly.

  The ClassManager uses the ClassCreation role model and underlying system facilities for on-demand creating and loading a class that is not currently available in the system.

• The CMSingleton role model (ClassManagerSingleton) serves to provide convenient access to the single ClassManager object. It is an instance of the Singleton pattern and shown in the figure using the singleton shorthand.

Most of the role models are free role models. Virtually every framework makes use of the ClassManager.Client role type to retrieve classes by name. Other role types are taken up by more specialized frameworks. For example, the system configuration frameworks make use of the ClassCreation.Client role type, and others.

6.2.4 Built-on classes

The Object framework is a fundamental framework that does not build on any other framework. It uses several underlying Java APIs, though.

6.2.5 Example extension

If a class wants its instances to make use of system services and to be referenced remotely, it must directly or indirectly inherit from AnyObject. Therefore, the Object framework forms the foundation of nearly every other non-trivial class in a system.

Figure 6-5: The OTS framework making use of the Object framework.

Figure 6-5 shows two example frameworks that both extend and build on the Object framework. (This is a simplified example). Another account of this example has been given in [RBGM99].

The two example frameworks that build on the Object framework are the Streaming and the Object Transport Service framework. An intermediate Service framework that also extends and builds on the Object framework is ignored.

The Streaming and the Object Transport Service framework are both extensions and use-clients of the Object framework. They are extensions, because their classes either directly or indirectly inherit from AnyObject, which is the primary extension-point class of the Object framework. They are use-clients, because they tie in with the Object framework using several different free role models.

The Streaming framework introduces classes that define and implement the Reader and Writer objects implied by the Reader and Writer role models. These classes tie in to the Object framework through the Reader and Writer role models. The Object Transport Service uses such Reader and Writer objects to marshal and unmarshal an object's state.

The Object Transport Service (OTS) framework ties in with the Object and Streaming frameworks using the Reader and Writer role models. It also uses the ObjectCreation role model of the Object framework. The OTS does not need more role models, because it copies objects across process boundaries, but does not migrate them (which is the task of the Object Migration Service acting on top of the OTS).

The Streaming and the OTS framework are straightforward examples of how frameworks build on each other. The use of free role models lets us precisely specify what is expected of clients. As the example shows, this helps clarify framework relationships.

6.3 Experiences and evaluation

During the development of the Geo system, the team used role modeling and the role-model-based catalog of design patterns to discuss the design of frameworks. The following subsections present and discuss the team's experiences with the use of role modeling for framework design.

6.3.1 Statistics of case study

The Geo Object framework provides the data shown in Table 6-1.

Number of classes	7
Number of role models	21
Number of pattern instances	11
Number of role types assigned to classes	41
Ratio of role types per class	5.86
Standard deviation of role types per class	3.80
Ratio of role models per class	3.0
Ratio of pattern instances per role model	0.52

Table 6-1: Raw data and computed figures from the Object framework.

The Geo Streaming framework provides the data shown in Table 6-2.

Number of classes	5
Number of role models	3
Number of pattern instances	1
Number of role types assigned to classes	6
Ratio of role types per class	1.2
Standard deviation of role types per class	0.4
Ratio of role models per class	0.6
Ratio of pattern instances per role model	0.33

Table 6-2: Raw data and computed figures from the Streaming framework.

The Geo Object Transport Service framework provides the data shown in Table 6-3.

Number of classes	5
Number of role models	10
Number of pattern instances	8
Number of role types assigned to classes	28
Ratio of role types per class	5.6
Standard deviation of role types per class	5.43
Ratio of role models per class	2.0
Ratio of pattern instances per role model	0.8

Table 6-3: Raw data and computed figures from the Object Transporter framework.

The discussion of the Object framework, the Streaming framework, and the Object Transport Service framework shows the key interface architecture only and omits classes of lesser importance and helper classes.

6.3.2 Complexity of classes

The Geo system has many complex classes. On the one hand, these are classes like AnyObject and AnyClass, which are complex due to the non-trivial number of object collaboration tasks their instances get involved in. On the other hand, these are the classes that serve as facades to a subsystem. Examples of facades are service interfaces like the one of the Object Transport Sservice and those of its dependent services like the Object Migration Service or the Remote Request Execution Service.

In both cases, the team found that being able to describe these classes using role types eased its work considerably. During the development of the Geo system, the team made the following observations:

• During design, team members found that role types and role models made defining the new classes easier than they remembered from earlier non-role-modeling-based experiences.
• Team members who used complex classes like AnyObject that they had not develop themselves found these classes easier to understand given a role modeling explanation of their behavior.
• Moreover, most of the team members felt that the complex classes were not only easier to understand, but also easier to use.

It is the team's experience that designing object systems is much like playing with scenarios of collaborating objects. The use of role types and role models lets a developer focus on the position of one object in such collaboration, without having to care about other roles. Later, a developer can care about the other roles, and carry out the composition of the role types. Of course, in the design process there is never such a clear-cut step-wise proceeding, but as a mental tool, describing classes using role types eases framework design significantly.

AnyObject is a prime example of a class where role modeling made it easier for team members to learn and use it. Some of AnyObject's functionality is of general interest, while some is not. Describing each piece of functionality as a role type (in the context of a role model) helped separate the different concerns, and communicate only those concerns of interest to a specific team member.

6.3.3 Complexity of object collaboration

The Geo system has many frameworks with complex object collaborations. For example, the Object framework is based on many complex collaboration tasks between AnyObject, AnyClass, and others. Other frameworks have equally complex internal collaborations. Extending and using the Object framework both requires understanding these object collaboration tasks.

During the development of the Geo system, the team made the following observations:

• In design discussions, the use of role models and design patterns supports the focus on individual object collaboration tasks. A developer can delay dealing with other tasks without critically loosing touch with the overall design. In fact, a developer can even switch between the collaboration tasks and work on the larger whole while staying focused on one particular issue.
• Learning and using a framework is facilitated by the clear definition of free role models. Developers who want to use a service learn about its interface and behavior in terms of role models, with each of the role models addressing a different issue. Separating these different issues reduces the complexity of learning the framework and putting it to use.

A general observation of the team was that role modeling achieves a higher degree of separation of concerns in the design of object collaborations than a traditional approach does, and that this kind of separation of concerns significantly reduces intellectual load, thereby easing the work task at hand.

The team also found that breaking up an overall collaboration into different role models supports being precise about the individual object collaboration tasks. In design discussions, thinking in terms of role models and design patterns frequently helped team members derive conclusions about dependencies between classes, the framework, and clients that had initially been missed. Members attribute this to the separation of concerns achieved by role models and to the reduced intellectual load.

6.3.4 Clarity of requirements put upon use-clients

The Geo system comprises many frameworks. Black-box use of these frameworks is based on the use of free role types and free role models. The Geo system is implemented in Java, so free role types with operations are represented as Java interfaces. The other free role types are described in the documentation and as part of the annotations of the class interfaces.

During designing, learning, and using the frameworks, the team made the following observations:

• While designing a framework, explicitly thinking about what a client may see and what not helps focus on the relevant design issue at hand. This in turn helps reduce the complexity of designing the client interaction, because one can focus on one pertinent issue at a time. Role modeling increases the awareness of developers that they are defining the client interaction, so they work twice as thoroughly, because client interactions are more important than internal collaborations.
• While learning a framework, free role models communicate clearly how to use a framework from the outside. Not only can a developer use role modeling as a thinking tool in design, but also can he use it to review his design for clarity and preciseness. If a class has operations that do not belong to a role type, or if the client interaction is just one big role model, this usually is a good indication that the design needs further improvement.
• While using a framework, designing and programming in terms of free role types helps developers focus on what they are doing with the framework. Using a role type that is not a free role type indicates either a problem with the framework or with the developer's understanding of it. Using a free role type is helpful in its explicit description of what a developer can do and what he is supposed to do.

The use of free role types and free role models proved to be very helpful in defining the use-client interaction. This is something that would otherwise have stayed implicit. The team's experiences with using frameworks whose client interaction were defined in terms of free role models are favorably with respect to their effectiveness. For the first time team members had an explicit part of the design to turn to and to learn from how to use the framework.

6.3.5 Reuse of experience

The following two forms of reuse occurred in the development of the Geo system.

• Reuse of experience through design adaptation. In this form of reuse, a team member recalls some prior experience and adapts it to the current problem at hand.
• Reuse of experience through design patterns. In this form of reuse, a team member recognizes a common problem and instantiates a design pattern to solve it.

The following two subsections examine the team's experiences with these two forms of reuse in the development of the Geo system.

6.3.5.1 Reuse of experience through design adaptation

Reuse of experience through design adaptation occurs when designs are similar to designs from prior experience. Two examples are the design of the Object framework, and the design of the service interfaces.

• During the design of the AnyObject and AnyClass classes team members drew heavily on similar classes they had seen in Java, Smalltalk, and several C++ application frameworks. They all have root classes Object and Class, and they all serve similar purposes.
• During the design of some of the service interfaces, team members reused their experiences with earlier service interfaces that have a similar structure. The Object Transport service, the Object Migration service, and the Remote Request Execution service interface all provide similar kinds of role types (primary domain functionality, a callback role type, and a Singleton access role type).

Role modeling made this form of reuse easier than team members could imagine possible with a traditional approach. In all cases, the relevant functionality was represented and understood in the form of role models. The team's experience is that a role model represents a precise and convenient design fragment of possible reuse that is precisely at the right level of granularity.

Team members either decided to adapt a role model from a design fragment of prior experience, or they decided to drop it. Once a team member had decided to adapt and thereby reuse it, he worked within the boundaries set up by the role model. Here, role models proved to be excellent design elements of possible reuse. They are much better suited than classes, which one has to break up into pieces to arrive at something similar to role models before one can start reusing them.

The use of role models also made team members not forget the client side and therefore helped them even further to reuse prior experience.

6.3.5.2 Reuse of experience through design patterns

The Geo frameworks exhibit a high design pattern density [RBGM98]. The team made use of design patterns in many instances, both by using the original class-based design pattern catalog [GHJV95] and by using the role-model-based version of a design pattern catalog [Rie97a]. This use of design patterns made the team's design efforts more effective by allowing team members to communicate more effectively [BCC+96, Vli98]. This increased productivity and the overall quality of work.

The Object framework as illustrated here has 7 classes and 21 role models. Conservatively counted, of these 21 role models, 11 are pattern instances. If one counts role models like Cloning, Comparing, or DictionaryKey as instances of yet undocumented patterns, the pattern/role model ratio increases further. The Object Transport Service framework features similar numbers, and so do most other frameworks.

The clear structure of the frameworks and the preciseness of their role models are a result of the team's understanding and use of design patterns. Because such a large percentage of the functionality of a framework could be described using design patterns, a large part of the framework had a clear structure and well-defined meaning early on. The remaining functionality became much easier to define in terms of role models, because there were less holes left and the boundaries of these holes were much better defined.

Team members worked most of the time using the role-model-based version of the design pattern catalog. The role model form made composing design patterns much easier than possible with classes. When using the class-based form, a team member usually had to carry out an intermediate step in terms of mapping from classes to functionality and responsibilities and then to the concrete situation where the pattern was to be applied.

The use of role-model-based design patterns allowed team members to drop this intermediate step. The pattern's role model structure is directly applicable to any concrete design situation, because the role types from the pattern definition are directly instantiated in the context of the specific situation.

Also, recognizing an applied pattern became easier using the role-model-based version. Mapping back from the framework is less complicated, because the role model as an instance of a pattern is right there in the design, while a class-based structure still requires an intermediate interpretation step of which class is what participant.

6.3.5.3 Conclusion on reuse of experience

During the development of the Geo frameworks, it was the team's experience that role modeling makes it easier to reuse prior experience, be it in the form of adapting old designs or applying design patterns, than it could imagine possible with a traditional class-based approach.