Chapter 3: Role Modeling

Object-oriented modeling is based on the concepts of object, class, and their relationships. This chapter extends these concepts with new role modeling concepts. It starts out with the definition of concepts like object, class, and class model, to which it adds the definitions of the concepts of role, role type, role model, and role constraint. This leads to an extended object modeling terminology, based not only on objects and classes, but on roles and role types, as well as class models and role models. The concepts for framework design, defined in the following chapter, build on this foundation.

3.1 Chapter overview

This chapter presents two categories of modeling concepts:

• Traditional object modeling concepts. This part defines the concepts object and value, class, class type, and value type, association and association description, aggregation and aggregation description, inheritance, object collaboration, and class model. This section provides the object modeling basis.
• New role modeling concepts. This part defines the concepts role, role type, role constraint, object collaboration task, and role model. It also revises and extends the object modeling basis to better support role modeling. It presents a novel perspective on the role concept, as needed for framework design and documentation.

Appendix B, the glossary, lists all concept definitions in alphabetical order. Appendix C, the notation guide, summarizes the visual notation used in the dissertation. The visual notation is derived from UML, with additions only for those concepts not known to UML.

This and the next chapter use the design of a graphical figure framework as a running example. This chapter discusses the class model only; the next chapter discusses its definition as a framework and its use by clients like drawing editors.

Graphical figure objects are part of a drawing, as shown by and manipulated through a drawing editor. Figure 3-1 shows the graphical user interface of such an example drawing editor. At the center of the figure is a drawing area, which contains several graphical figures.

Figure 3-1: Screenshot of an example drawing editor (JHotDraw).

Graphical figures may be generic figures like polygon, rectangle, circle, and text figures. They may also be domain-specific figures like UML-style object, interface, association, and aggregation figures as used in a UML diagram editor, or like animal or circus figures as used in a drawing editor for children.

Some of the figures are composite graphical figures. A composite graphical figure is a figure that is composed from further embedded figures (it aggregates these sub-figures). Examples of composite graphical figures are predefined figures like the UML-style class or interface figures, which are build from polygon, rectangle, and text figures, and user-defined figures like those composed by a grouping mechanism as found in drawing editors. Thus, a composite graphical figure can be realized as a hierarchy of figure objects.

Figure 3-2 illustrates the runtime object hierarchy for the graphical figures of the drawing from Figure 3-1.

Section 3.2 defines the basic object modeling terminology. It uses the graphical figure class hierarchy indicated above as its illustrating example. The hierarchy is presented as a class model.

Figure 3-2: Object hierarchy of graphical figures.

Section 3.3 defines the role modeling extension of the object modeling basis. It enhances the graphical figure example with roles and role models to show the structure of object collaborations.

The concepts are presented in a programming language independent way. They do not reflect the full complexity of today's programming languages. Chapter 5 shows how the modeling concepts map on other notations and programming languages like UML, Java, C++ and Smalltalk.

3.2 Object modeling fundamentals

Objects and classes are the traditional modeling concepts of object-oriented software systems. This section defines and illustrates the concepts of object, class, class type, operation, value, value type, and interpretation function. It also defines the concepts of association and association description, aggregation and aggregation description, and inheritance. Finally, it defines the concepts of object collaboration and class model. Some definitions are preliminary and are extended in the subsequent sections when the role modeling concepts are introduced.

This section is not meant to provide a comprehensive object modeling terminology. It only defines the most fundamental concepts, on which the subsequent role modeling concepts build. It omits most of the complexity found in industrial-strength modeling approaches like UML [UML97a, UML97b] or OML [FHG98], which provide a much larger variety of modeling concepts than those presented here.

3.2.1 Object and class (definition)

The concepts of object and class can be defined from a technical or a conceptual perspective. We use the technical definitions, and view the conceptual definitions as a description of the purpose of objects and classes.

Definition 3-1: Object

An object is an opaque runtime entity of a system that provides state and operations to query and change that state. An object has a lifecycle: It is created, may change over time, and is possibly deleted. Objects can be identified unambiguously; identity is an intrinsic property of every object.

An object represents a concrete or abstract phenomenon from a domain. The domain may be a non-technical application domain like banking or insurance, or it may be a technical application domain like multithreading, synchronization, or distribution. This second modeling-oriented definition of objects as representations of phenomena complements the first definition of objects as encapsulated state with operations.

Examples of objects are all kinds of graphical figures, for example polygons, rectangles, triangles, and circles, but also higher-level graphical figures, like UML-style class, interface, association, and inheritance figures.

Figure 3-3 shows the visual representation of the object concept as used in this work. In such a diagram, an object typically has a name, like "aFigure", and provides its class name, like "Polygon", set in parenthesis below the object name.

Figure 3-3: Example of an object called p of class Polygon.

An object is an instance of a class. The class defines the properties of its instances.

Definition 3-2: Class

A class is the definition of a (possibly infinite) set of objects, called its instances. A class defines the behavior of its instances using a class type. A class type is a type, specified using an appropriate type specification mechanism.

With each class, exactly one class type is associated. The class type defines the operations applicable to an instance of the class in terms of the effects these operations have on its state and in terms of the values returned to an object calling an operation.

A class is the result of an abstraction process from several similar objects from a domain. It describes the common properties of all its instances and ignores any properties that are irrelevant for the modeling task at hand. Again, this second definition of class as the abstraction from similar recurring phenomena complements the first definition of class as the definition of the common properties of a set of objects.

Examples of classes are PolygonFigure, RectangleFigure, and TextFigure. Some visual instances are shown in Figure 3-1 as polygons, rectangles, texts on a drawing area, and some regular instances are shown in Figure 3-2 as objects in an object diagram. Similarly, more complex examples are the UmlClassFigure and UmlAssociationFigure classes, as they are needed for a UML-diagram drawing editor.

An object may be an immediate (or direct) instance of a class or not. An immediate instance is an object that conforms to a class without obeying further specified properties. An object that conforms to a class but that is not an immediate instance of this class typically is an instance of a subclass of this class (see Section 3.2.5).

A class may be abstract or concrete. An abstract class cannot have immediate instances. A concrete class may have immediate instances. The aforementioned PolygonFigure, RectangleFigure, and TextFigure classes are concrete classes. The class Figure, which represents all properties common to figure objects, is an abstract class, of which no direct instances may exist.

Figure 3-4 shows the visual representation of the class concept. If the class name is set in Italics, the class is an abstract class. If not, it is a concrete class. The body of the visual class representation shows parts of its class type, as defined below.

Figure 3-4: Example of a class, here the Figure class.

The concept of class is understood and used here as a modeling concept. On an implementation level, a design-level class may be represented using any appropriate mechanism. In Java, for example, design-level classes are frequently expressed using Java interfaces, and Java classes are used to provide implementations of the design-level classes.

The class type can be specified using an appropriate type specification mechanism, for example Liskov & Wing [LW93a, LW93b, LW94] or Abadi & Cardelli [AC96]. The only precondition is that the chosen specification mechanism must provide a proper composition operator on types. This is needed, as shown in the Section 3.3, to define a class type as the composition of several role types.

Figure 3-5 shows the visual representation of the type concept.

Figure 3-5: Example of a type, here the class type of Figure.

Class types, role types, and value types (see below) are expressed and shown using the same visual symbol.

3.2.2 Value and value type (definition)

Objects and values are complementary modeling concepts of equal importance [Mac82, BRS+98].

Definition 3-3: Value

A value is an atomic entity from the abstract and invisible universe of values. A value cannot be perceived directly, but only through occurrences of its representations. The representations are interpreted by means of interpretation functions. These interpretation functions return further (occurrences of representations of) values; they do not change the value.

In contrast to objects, values do not live in time: they are not created, do not change, and are not destroyed.

A value is always bound to an attribute of an object. An attribute is a name/value pair that puts a label, the attribute name, on some aspect of the object's state space, the attribute value, so that for a given object, the attribute's value can be named, assessed, and changed.

Examples of values are integers, strings, but also domain-specific values like account numbers, security tickets, and monetary amounts. Values of particular importance to object systems are object references, because they enable objects to communicate. The so-called primitive values like integers, strings, and object references are typically directly supported by a modeling notation or a programming language, while domain-specific values need to be defined by programmers.

Definition 3-4: Value type

A value type is a type that specifies a set of values together with the interpretation functions applicable to representations of members of this set.

Value types (or type constructors for a specific kind of value type) may be directly provided by a modeling language, like integer, string, and object reference. Or, value types may be domain-specific and introduced by programmers, like Color, 2DPoint and 3DPoint, etc.

For a given object attribute, an attribute type is defined, which determines the set of possible values that can be assigned to the attribute. An attribute type is always a value type.

There are no universal context-independent criteria to decide whether some domain phenomenon should be modeled as an object or a value. The purpose of the model and the suitability of its possible implementations always drive such a decision.

3.2.3 Figure class (example)

As explained, a class defines the state and behavior of its instances. It does so with the help of a class type. In the simplest case, a class type is a set of attributes, a set of constraints on the attribute values, a set of transitions between allowed states, and a set of operations that trigger state transitions. The constraints on the attributes determine the subspace of the overall state space defined by the cross product of the attributes' value types. Next to this simple scheme, more elaborate type specification mechanisms can be used.

For the purposes of this work every type specification mechanism is suitable, as long as it provides a well-defined composition operation on types. To better illustrate the examples, and to simplify their discussion, we use a simple type specification mechanism. A type is described as a set of operations, a set of attributes, and an informal annotation that describes its meaning (either as comments in the specification text or in the main body of the respective section). The possible state transitions are implied by the operation definitions.

For example, the class type of class Figure defines an attribute with the name "parent" that is of type "object reference to Figure object". Also, class Figure may have an attribute called extent of value type rectangle, with the constraint that the rectangle must have a positive non-zero extent. (Please note that the value type rectangle is a mathematical concept, hence a value type, while the class RectangleFigure is a graphical figure class, which may not only have an attribute extent of type rectangle, but many other attributes, like fill color, line stroke color, or line stroke width.)

Specification 3-1 describes the class Figure and its class type. Next to the Figure class, it uses a Graphics class that represents the drawing area. The specification uses Java syntax-alike constructs. The uncommon syntax "ref<Figure>" stands for the value type "object reference to Figure object". Thus, "ref" is a type constructor for object reference value types. This pseudo-code serves illustration purposes only. It is not based on a full-fledged specification or programming language.

class Figure {
    // Provide basic domain functionality of figures.
    // Figures have origin, extent. Can be drawn, moved, and resized.
    // Figures have a handle by which they are manipulated.
    point origin;
    rectangle extent;
    void draw(ref<Graphics> context);
    void drawOutline(ref<Graphics> context);
    void place(point location);
    void move(int dx, int dy);
    void resize(int handle, int dx, int dy);
    // Provide parent reference; may be null for root.
    // Parent object must be of type Figure.
    ref<Figure> parent;
    boolean hasParent();
    void setParent(ref<Figure> parent);
    // Manage objects registered as dependents.
    // Notify them about state changes of the figure.
    // Dependents must be of type FigureObserver.
    collection<ref<FigureObserver>> dependents;
    boolean hasObserver(ref<FigureObserver> observer);
    void addObserver(ref<FigureObserver> observer);
    void removeObserver(ref<FigureObserver> observer);
    // Generically manage properties of figure.
    // Examples properties are fill color, frame color, line stroke.
    // Properties may be any kind of Object.
    collection<ref<Object>> properties;
    void hasProperty(string name);
    void getProperty(string name);
    void setProperty(string name, ref<Object> property);
    void unsetProperty(string name);
    ... More definition.
}

Specification 3-1: Example specification of Figure class.

This example class defines its instances' state space together with operations to change it. The existence of an attribute in the class type definition implies an operation to get the attribute's value, but not necessarily an operation to set it. A set-operation needs to be specified explicitly.

3.2.4 Relationships and relationship descriptions (definition)

At runtime, objects are connected with each other. Such a connection may be implemented in different ways. On the modeling level, we only need to express that we allow for a certain type of connection between objects.

A connection between two objects is called an object relationship. For the object modeling basis, we consider two types of object relationships: object associations and object aggregations. These are runtime entities stating that two objects are connected with each other in a particular way.

An object relationship description defines what a valid object relationship is. We consider object association descriptions and object aggregation descriptions. These relationship descriptions can be annotated to add meaning and more precisely specify the set of allowed relationships according to that relationship description.

Object associations may be unidirectional or bi-directional. Object aggregations are always unidirectional. However, this information is effectively an annotation of the relationship description that is used to help implementing the model. The overall graph of object relationship descriptions is undirected, independently of the specification of individual relationship descriptions.

3.2.4.1 Association and association description (definition)

Objects relate to each other by means of object associations.

Definition 3-5: Object association

An object association is a pair of objects (x, y), stating that an object x holds a reference to another object y of which it may or may not make use.

Holding a reference means that a parameter of an invocation of an operation of object x or that an attribute of object x has the reference to y as its value. An example of an object association is (aText, aUmlClass), which indicates that the object aText is associated with the object aUmlClass (for example, by means of its parent attribute).

Figure 3-6 shows the visual representation of a unidirectional object association.

Figure 3-6: Example of an association between two objects.

Object associations may be bi-directional, which means that for a given association (x, y), the inverse (y, x) exists. This is visually shown through the omission of the arrowhead, see Figure 3-7.

Figure 3-7: Example of a bi-directional association between two objects.

Classes prescribe how their instances may relate to each other by means of object association descriptions.

Definition 3-6: Object association description

An object association description is a pair of types (X, Y) that determines possible runtime object associations. An association between two objects (x, y) conforms to the association description if x is of type X or a subtype of X, and if y is of type Y or a subtype of Y.

When speaking of an association description between two classes, the class types of the classes are meant.

Object association descriptions between classes are specifications of how instances of the classes may relate to each other at runtime. A specific object association is called a valid object association with respect to an object association description if it conforms to the description.

Figure 3-8 shows the visual representation of an object association description for unidirectional object associations, and Figure 3-9 shows the visual representation of an object association description for bi-directional object associations.

Figure 3-8: Example of a unidirectional object association description.

Figure 3-9: Example of a bi-directional object association description.

Being unidirectional or being bi-directional are annotations on the first or second element of the pair representing the object association description. They add meaning to the association description that can be used in the implementation of the design. However, the underlying graph is still undirected.

Object association descriptions (and object aggregation descriptions, see below) are annotated with further information. Each annotation is tied to one end of the description. Examples of annotations are the name of the description, the cardinality of the source or target, and possible existence dependency constraints.

For example, Figures 3-8 and 3-9 annotate the association descriptions with the cardinality of runtime object associations. If no cardinality is given, a default value of 0..1 is assumed.

3.2.4.2 Aggregation and aggregation description (definition)

Objects also relate to each other by means of aggregation.

Definition 3-7: Object aggregation

An object aggregation is a pair of objects (x, y), stating that an object x aggregates an object y as a part of it. To aggregate an object means to control it, not only to make use of it, but to determine its lifetime and accessibility as well.

One object may aggregate several other objects, but may itself be aggregated at maximum once. Object aggregations form acyclic object hierarchies. Odell gives an in-depth discussion of the concept of aggregation [Ode98]. An example of an aggregation is (aUmlClass, aText), which indicates that the object aUmlClass aggregates the object aText (for example to display the class name).

Figure 3-10 shows the visual representation of an aggregation. It is distinguished from an association through the diamond on the side of the aggregating object.

Figure 3-10: Example of an aggregation between two objects.

Classes prescribe how their instances may relate to each other by means of aggregation descriptions.

Definition 3-8: Object aggregation description

An object aggregation description is a pair of types (X, Y) that determines possible runtime object aggregations. An aggregation between two objects (x, y) conforms to the aggregation description if x is of type X or a subtype of X, and if y is of type Y or a subtype of Y.

When speaking of an association description between two classes, the class types of the classes are meant.

Object aggregation descriptions between classes are specifications of how instances of the classes may aggregate each other at runtime. A specific object aggregation is called a valid object aggregation with respect to an object aggregation description if it conforms to the description.

Figure 3-11 shows the visual representation of an aggregation description.

Figure 3-11: Example of an aggregation description between two classes.

Like object association descriptions, aggregation descriptions are not aggregations but rather descriptions of them. Aggregation descriptions provide information about the allowed runtime aggregations like cardinality of the aggregated objects, etc. In an aggregation description, the cardinality annotation of the aggregating class is always 0..1; thus the annotation can be omitted in a figure depicting the aggregation description.

3.2.5 Inheritance (definition)

Classes may inherit from each other. Inheritance is understood here as a modeling concept to define specialization/generalization hierarchies rather than as a construct to reuse code.

Definition 3-9: Inheritance

An inheritance is a pair of classes (X, Y) such that any instance of class Y can be substituted in a context where an instance of class X is expected.

X is called the superclass of Y and Y is called the subclass of X.

Conceptually speaking, the concept modeled by class Y is a specialization of the concept modeled by class X and the concept modeled by class X is a generalization of the concept modeled by class Y. The pair (Figure, RectangleFigure) is an example of inheritance. It indicates that RectangleFigure is a subclass of Figure.

Wegener and Zdonik discuss in more detail what "substituted in a context where an instance of class X is expected" means [WZ88]. Further definitions of substitutability have been given by Liskov [Lis88], Liskov and Wing [LW93a, LW93b, LW94], Abadi and Cardelli [AC96], and others.

We use single inheritance only. Thus, for a given inheritance (X, Y), there may not be another inheritance (Z, Y) with Z ( X. (This will seem less a restriction, once role types are introduced.)

Figure 3-12 illustrates the visual representation of the inheritance concept.

Figure 3-12: Example of an inheritance between two classes.

According to the abstract superclass rule, a class should not inherit from a concrete class [Hür94]. Thus, in a class inheritance hierarchy all leaf classes should be concrete classes, and all other classes are abstract classes.

In practice, this rule is often relaxed, and concrete classes inherit from concrete classes. If done right, this is not a problem, because the concrete superclass actually assumes two different roles: one as an abstract superclass for subclasses and one as a concrete class that is readily instantiable by use-clients.

3.2.6 Object collaboration and class model (definition)

For modeling object systems, we must define what a system is. Moreover, we are not interested in just about any system, but only those considered valid, because only they provide both expected and useful behavior.

At runtime, an object system is a set of objects that relate to each other by means of object associations and aggregations. Which of the possibly infinite number of object systems is a valid one and which is not? Object collaborations and class models provide the necessary means to better define what a valid system is.

Definition 3-10: Object collaboration

An object collaboration is a set of objects that relate to each other by object relationships.

An object system is an object collaboration. An object collaboration or an object system is said to be valid if it conforms to a class model.

Definition 3-11: Class model

A class model is a set of classes that relate to each other by inheritance and object relationship descriptions. The class relationship graph must be non-partitioned.

The class relationship graph is the graph of all object relationship descriptions, which may be either object association or object aggregation descriptions. The graph is undirected and non-partitioned.

A class model acts as a specification of a (possibly infinite) set of runtime object collaborations. Its purpose is to define what a valid object collaboration is and what not. If an object collaboration is an element of the set of object collaborations specified by the class model, it is said to conform to the class model, and hence is said to be a valid object collaboration.

3.2.7 Figure class model (example)

We can now present a first class model. We use the classes Figure, PolygonFigure, RectangleFigure, TextFigure, CompositeFigure, GroupFigure, UmlClassFigure, and UmlAssociationFigure. Figure and CompositeFigure are abstract classes, while all other classes are concrete classes.

Figure 3-2 presents an example object collaboration. A few non-composite as well as a few composite objects can be seen. To understand the structure of this object hierarchy, the classes Figure and CompositeFigure need to be defined. Class Figure is described in the previous class example subsection, and class CompositeFigure is described in Specification 3-2.

class CompositeFigure extends Figure {
    // Manage child figure objects.
    // Child figures must be of type Figure.
    collection<ref<Figure>> children;
    boolean hasChild(ref<Figure> child);
    void addChild(ref<Figure> child);
    void removeChild(ref<Figure> child);

    ... More definition.
}

Specification 3-2: Example specification of CompositeFigure class.

The class CompositeFigure defines what it means to be a composite figure object: it may have child objects, aggregated by the very composite object. Therefore, all classes whose instances are composite figure objects inherit from CompositeFigure.

The classes PolygonFigure, RectangleFigure, and TextFigure are direct subclasses of Figure. Thus, they represent non-composite figure objects. The classes GroupFigure, UmlClassFigure, and UmlAssociationFigure are subclasses of CompositeFigure. Thus, they represent composite figure objects.

Figure 3-13 shows the resulting class model.

Figure 3-13: Class model of Figure example.

Figure 3-13 expresses the concept of composite figure object by means of the object aggregation description between the CompositeFigure and Figure classes. The possibility to traverse an object hierarchy from the leaves up is expressed by the parent association description from Figure to CompositeFigure. The object associations between a graphical figure and its dependents are shown by an association description between Figure and FigureObserver. Finally, an object association description between Figure and Object shows how a figure provides its properties to clients.

The association descriptions between the composite figure classes UmlAssociationFigure and UmlClassFigure and the primitive figure object classes PolygonFigure, RectangleFigure and TextFigure are omitted.

3.3 Role modeling extensions

This section extends the concepts defined in the previous section with role modeling concepts. It introduces new concepts and revises old ones.

Object collaborations are described as interacting objects that play roles to provide predefined behavior. Because an object may play several roles in an object collaboration, the collaboration itself is broken up into pieces, called object collaboration tasks. Each object collaboration task is described by a role model, and a role type from the role model describes each role in the collaboration task. A role model describes the collaboration task as a set of role types and their relationships, independent of other collaboration tasks.

A role model describes the set of valid object collaboration tasks, much like a class model describes the set of valid object collaborations. Also, a class model is broken up into different role models, much like an object collaboration is broken up into collaboration tasks. The collaboration tasks compose to become the full object collaboration, and the role models compose to become the full class model. Role models thereby separate the different concerns involved in a class model and reduce the complexity of designing and understanding it.

This section defines the concepts role and role type, role constraint, object collaboration task and role model. The class and class model concepts are extended to integrate smoothly with the role modeling concepts. The Figure example is revised in light of the new modeling concepts.

3.3.1 Role and role type (definition)

Roles are observable behavioral aspects of objects. A role is described by a role type.

Definition 3-12: Role

A role is an observable behavioral aspect of an object.

An object, which provides a particular role, is said to play that role.

An object may play several roles at once (which every non-trivial object does). The roles, which an object plays, interact, and an operation called in the context of one role can easily lead to the object acting in the context of another role. The set of roles an object is playing is called the object's role set.

A role represents the behavior of an object with respect to a specific object collaboration task. Objects as phenomena from a domain typically behave in many different ways, acting in different use-contexts. Therefore, in each context, an object plays a different role. The role is determined by the view the client holds on the object playing the role.

Each graphical figure object provides a set of roles to clients. Among these are roles that let clients draw the object, traverse the object hierarchy, make the object persistent, and inform dependent objects about state changes.

A role type abstracts from the behavior of similar roles.

Definition 3-13: Role type

A role type is a type that defines the behavior of a role an object may play. It defines the operations and the state model of the role, as well as the associated semantics.

An object's behavior is defined by the composition of all role types of all roles it may play. Different objects may play a role that is defined by the same role type. Thus, a role type is (in principle) independent of a particular object or class.

A role type is the result of an abstraction process from similar behavioral aspects of objects from a domain, much like classes are the abstraction from structurally and behaviorally similar objects. In contrast to a class that fully defines an object, a role type only defines one possible behavioral aspect of an object.

A role type is visually represented as a type. For example, Figure 3-14 shows the Figure role type.

Figure 3-14: Example of a role type.

Examples of role types are the type definitions of the roles mentioned above. These role types might be named Figure, Child, and Subject. The Figure role type defines the domain-specific behavior of figure objects, like its capability to draw itself on some drawing area. It ignores other aspects like its child behavior in an object hierarchy.

If a textual specification of a role type is given, it is not necessary to repeat the type specification as part of the visual representation in a diagram. It is sufficient to provide the name. Figure 3-15 shows this convenience shortcut for the Figure, Child, and Subject role types.

Figure 3-15: Example role types.

Some role types may have no operations associated with them. For example, client role types frequently specify only behavior of objects, but no operations. (A client acts according to its role type specification, but it does not offer operations for other objects to call back.)

Definition 3-14: No-operation role type (no-op role type)

A no-operation role type is a role type that defines no operations.

Still, behavioral semantics may be associated with such no-operation role types. This is sometimes the case, but not always. But even if no semantics are associated with a no-operation role type, the role type still serves a useful purpose as a handle for a role played by an object.

Definition 3-15: No-semantics role type

A no-semantics role type is a no-operation role type that defines neither state nor behavior.

No-semantics role types are used to designate objects whose references are passed around but which are not made use of in the context of the current role model. No-semantics role types can be attached to a class after it has been defined.

For pragmatic purposes, diagrams identify no-operation role types by a mark in their upper right corner. Figure 3-16 shows an example.

Figure 3-16: Example no-op role type.

The importance of no-operation and no-semantics role types will become apparent in the context of role models (see Subsection 3.3.5) and class models (see Subsection 3.3.9).

3.3.2 Figure, Child, etc. (example)

Specification 3-3 describes the Figure, Child, and Subject role types:

// Provide basic domain functionality of figures.
// Figures have origin, extent. Can be drawn, moved, and resized.
// Figures have a handle by which they are manipulated.
roletype Figure {
    point origin;
    rectangle extent;
    void draw(ref<Graphics> context);
    void drawOutline(ref<Graphics> context);
    void place(point location);
    void move(int dx, int dy);
    void resize(int handle, int dx, int dy);
}

// Provide parent reference; may be null.
// Parent object must be of type Parent.
roletype Child {
    ref<Parent> parent;
    boolean hasParent();
    void setParent(ref<Parent> parent);
}

// Manage objects registered as dependents.
// Notify them about state changes of the figure.
// Dependents must be of type Observer.
roletype Subject {
    collection<ref<Observer>> dependents;
    boolean hasObserver(ref<Observer> observer);
    void addObserver(ref<Observer> observer);
    void removeObserver(ref<Observer> observer);
}

Specification 3-3: Example specification of Figure class.

Please note that a role type in its definition refers to other types, and that these other types need not be class types. As discussed below, these other types are likely to be other role types from a role model. Examples are the definition of the Child role type that refers to a Parent role type and the definition of the Subject role type that refers to an Observer role type.

3.3.3 Class (revised definition)

With the introduction of the role and role type concept, we can now enhance the definition of the class and inheritance concepts. The object concept has already been enhanced in the previous subsection, stating that with any object, a set of roles is associated.

Definition 3-16: Class (revised)

A class is the definition of a (possibly infinite) set of objects, called its instances. A class defines a non-empty set of role types, a composition function, and a class type. The composition function, applied to all role types, results in the class type.

The class type specifies the behavior of the instances of the class.

The set of role types of a class is called the class' role type set. The role type set of a class determines which kind of roles its instances may play at runtime. An object x of class X may only play a role r if the role's type R is an element of the role type set of X.

Specification 3-4 defines the Figure class in terms of role types.

roletype Figure { ... } // For definition, see above.
roletype Child { ... } // For definition, see above.
roletype Subject { ... } // For definition, see above.

// Generically manage properties of figure.
// Examples properties are fill color, frame color, line stroke.
// Properties may be any kind of Object.
roletype Provider {
    collection<ref<Object>> properties;
    void hasProperty(string name);
    void getProperty(string name);
    void setProperty(string name, ref<Object> property);
    void unsetProperty(string name);
}

class Figure extends Object {
    roletype Figure;
    roletype Child;
    roletype Subject;
    roletype Provider;
    ... More definition.
}

Specification 3-4: Example specification of Figure class, including role types.

The role type set of the Figure class comprises the Figure, Child, Subject, and Provider role types. The role types are deliberately defined independently of the class. The class only makes use of them by specifying that they are elements of its role type set. The enclosing definition of a role type is always a role model (see below).

A class inherits the role type set of its superclass. Thus, with increasing distance from the root class Object, the size of the role type set increases monotonously. Assume that class Object is defined as follows:

class Object {
    roletype Readable; // Object can be read from a passive form.
    roletype Writable; // Object can be written to a passive form.
    roletype Instance; // Object provides metainformation.
    roletype Clonable; // Object can be cloned.
    roletype Comparable; // Object can be compared for equality.
    roletype Key; // Object can act as a key for dictionaries.
}

Specification 3-5: Example specification of Figure class.

The cardinality of the object role type set is 6. With Figure being a direct subclass of Object, the cardinality of its role type set is 6 plus the number of new role types it defines itself (of which we have seen 4 so far: Figure, Child, Subject, and Provider).

For the purposes of this dissertation, there is no need to introduce a subtyping relationship between role types. Thus, class inheritance is not affected, and role types of a class remain unchanged by subclasses.

3.3.4 Choice of type specification mechanism

A class type is the composition of all the role types from the class' role type set. The class defines a composition function that carries out this composition. Effectively, this is the integration of the state model of the role types to form a larger state model for the class.

This dissertation does not introduce a new type specification, but assumes that any mechanism is acceptable that fulfills the following properties:

• The mechanism lets developers express a type in an object-oriented fashion.
• The mechanism provides a concept of substitutability based on concept specialization.
• The mechanism lets developers specify dynamic behavior of objects.
• The mechanism lets developers compose (role) types to form new derived (class) types.

These properties are the result of the new class definition. Most of the aforementioned approaches address these issues and could be chosen as a type specification mechanism for role modeling (for example, [LW93a, LW93b, LW94]).

Another solution is not to choose a particular type specification mechanism, but to rely on a mainstream modeling language or programming language. (These are typically so weak with respect to type specification that they are considered here as not having one.) Developers then define the composition function of the role types implicitly. They realize the composition function through a class implementation.

3.3.5 Object collaboration task and role model (definition)

Object collaborations typically fulfill several tasks in parallel. The same objects collaborate to achieve several different things. Given any individual object, the role types of the object's roles express the behavior needed for the different tasks.

Definition 3-17: Object collaboration task

An object collaboration task is an object collaboration and a set of roles objects play in the collaboration. The object relationship graph must be non-partitioned.

An object collaboration task represents a single-purpose activity of objects in an object collaboration, which they carry out by playing the roles defined by the task.

An object collaboration task is said to be valid, if it conforms to a role model.

Definition 3-18: Role model

A role model is a set of role types that relate to each other by object relationship descriptions and role constraints. The role type relationship graph must be non-partitioned.

The role type relationship graph is the graph of all object relationship descriptions.

A role model defines a (possibly infinite) set of valid object collaboration tasks. A collaboration task from this set is said to conform to the role model. As discussed below, role models compose to become class models, and object collaboration tasks compose to become object collaborations.

Role models are the place where role types are defined. For example, the role model that describes the figure object hierarchy is called FigureHierarchy. Part of its definition are the role types Child and Parent, as defined above. Classes have to import these role types from the role model to put them into their role type set. We use the common dot-notation to identify role types: Child becomes FigureHierarchy.Child and Parent becomes FigureHierarchy.Parent in the context of a class.

The role type relationship graph in a role model may not be partitioned, so that there is a path from every role type to every other role type. This ensures that the role model is a cohesive model rather than a set of unrelated role types.

Before we provide an example, we need to define the concept of role constraint that lets us define how roles come together in an object (or not).

3.3.6 Role constraint (definition)

An object may play several roles at once, as defined by the role type set of its class. A role, an object plays, may require another role from that same object within the given object collaboration task. Or, a role may require that the same object within the collaboration task never plays another role. Or, two roles might mutually require each other. Finally, two roles may not have any requirements with respect to each other.

Such constraints are expressed as role constraints. (It is role constraint rather than role type constraint, because this descriptive means refers to roles objects play in an object collaboration task rather than to role types from a role model).

Definition 3-19: Role constraint

A role constraint is a value from the set {role-implied, role-equivalent, role-prohibited, role-dontcare}. For every given pair of role types (R, S) from a role model one such value is defined.

Role constraints are scoped by an object collaboration task. They only constrain the role-playing of objects within such a task. As a consequence, role constraints are only specified within the context of one role model.

The meaning of the role constraints is as follows:

1. A role-implied value for a pair of role types (R, S) defines that an object playing a role r defined by role type R is always capable of playing a role s defined by role type S. That is, role r implies role s. This relationship is transitive.
2. A role-equivalent value for a pair of role types (R, S) defines that an object playing a role r defined by role type R is always capable of playing a role s defined by role type S, and vice versa. That is, role r and role s imply each other. This relationship is symmetric and transitive.
3. A role-prohibited value for a pair of role types (R, S) defines that an object playing role r defined by role type R may not play role s defined by role type S within a given collaboration task. That is, role r prohibits role s for the task. This relationship is symmetric and transitive.
4. A role-dontcare value for a pair of role types (R, S) defines that an object playing a role r of role type R has no constraints with respect to another role s of role type S within the given collaboration task. The role s may or may not be available together.

Figure 3-17 shows the visual representation of role constraints. Each possible role constraint is depicted through its own visual symbol.

Figure 3-17: Examples of role constraints between role types.

Case a) shows a role-implied constraint, case b) shows a role-equivalent constraint, case c) shows a role-prohibited constraint, and case d) shows a role-dontcare constraint.

3.3.7 Figure role models (examples)

As a first example of a role model, consider the collaboration task of a figure object with its client. It can be described by a simple role model that defines the role types Figure and Client. The Figure role type depends on further types from a yet unspecified Graphics role model, which it imports.

Specification 3-6 describes the Figure role model:

// Figure requires Graphics role model.
import Graphics.*;

rolemodel Figure {
    // Provide basic domain functionality of figures.
    // Have origin, extent. Can be drawn, moved, and resized.
    roletype Figure {
        point origin;
        rectangle extent;
        void draw(ref<Graphics> context);
        void drawOutline(ref<Graphics> context);
        void place(point location);
        void move(int dx, int dy);
        void resize(int handle, int dx, int dy);
        ... More definition.
    }

    // The Client role type provides no operations.
    // However, it must behave properly when using Figure objects.
    roletype Client {
        ... // Specification of behavior with respect to using figures.
    }

    constraints {
        (*, *) = role-dontcare;
    }

    ... More definition, e.g., associations, cardinalities.
}

Specification 3-6: Example specification of Figure role model.

The wildcard '*' in the role constraints part of the role model is a placeholder for any role type from the model. Thus, (*, *) expands to { (Figure, Client), (Client, Figure) }.

The Client role type is a no-operation role type. Within a role model, such no-operation role types define roles of objects that are not referenced and used by other objects (hence, no operations needed). However, a Client object still acts according to the no-operation Client role type.

The Client and Figure role types of the Figure role model are referenced from the outside using the common dot-notation for qualifying names: Figure.Client and Figure.Figure.

Figure 3-18 shows the Figure role model. Each role type in the role model prominently shows its name in large font and set below it, in parenthesis and a smaller font, the role model name. The role model name is added to distinguish role types from different role models in the context of class models (see below).

Figure 3-18: The Figure role model.

Another role model example is the collaboration between parent and child figure objects in the hierarchy. A parent figure manages its child figures, and a child figure provides access to its parent object.

Specification 3-7 shows the FigureHierarchy role model.

rolemodel FigureHierarchy {
    // Provide parent reference.
    roletype Child {
        ref<Parent> parent;
        boolean hasParent();
        void setParent(ref<Parent> parent);
    }

    // Manage child figures.
    roletype Parent {
        collection<ref<Child>> children;
        boolean hasChild(ref<Child> child);
        void addChild(ref<Child> child);
        void removeChild(ref<Child> child);
    }

    // Configures parent object with children.
    roletype Client {
        // Leave it to parent to set itself to child.
        // No further specification.
    }

    // A child may not be its own parent.
    // A child may not configure its parent.
    constraints {
        (Child, *) = role-prohibited;
        (*, Child) = role-prohibited;
        (Client, Parent) = role-dontcare;
        (Parent, Client) = role-dontcare;
    }

    ... More definition, e.g., associations, cardinalities.
}

Specification 3-7: Example specification of FigureHierarchy role model.

Figure 3-19 shows the FigureHierarchy role model.

Figure 3-19: The FigureHierarchy role model.

Yet another example is the collaboration task for notifying clients about state changes of a figure object. Clients may depend on the state of the figure object and need to be informed about changes to it.

A previous subsection defines the role types FigureObserver and Subject. This subsection redefines them in the context of a role model. In particular, their names are adapted to avoid confusion.

Specification 3-8 defines the FigureObserver role model.

rolemodel FigureObserver {
    // Manage all dependent objects.
    // Notify them about state changes of the figure.
    // Dependents must be of type Observer.
    roletype Subject {
        collection<ref<Observer>> dependents;
        boolean hasObserver(ref<Observer> observer);
        void addObserver(ref<Observer> observer);
        void removeObserver(ref<Observer> observer);
    }

    // Provide callback operations for subject.
    roletype Observer {
        void update(ref<Subject> source, ref<Event> event);
    }

    ... Event definition.

    constraints {
        (*, *) = role-prohibited;
    }

    ... More definition, e.g., associations, cardinalities.
}

Specification 3-8: Example specification of FigureObserver role model.

Figure 3-20 shows the FigureObserver role model.

Figure 3-20: The FigureObserver role model.

As a final example, consider a role model used to pass client requests along a chain of objects. The client requests are converted into Request objects first, which are then forwarded from one element in the chain to its succeeding element. A figure object uses this mechanism to notify its parent about a client request that it could not handle.

Specification 3-9 describes the FigureChain role model:

rolemodel FigureChain {
    // Predecessor in a chain of figure objects.
    // Provides operation to generically handle requests.
    roletype Predecessor {
        ref<Successor> successor;
        void setSuccessor(ref<Successor> successor);
        void forwardRequest(ref<Request> request);
    }

    // Accept, queue, and dispatch requests.
    roletype Successor {
        void handleRequest(ref<Request> request);
        void handleDeleteRequest(ref<DeleteRequest> request);
        void handleInvalidateRequest(ref<InvalidateRequest> request);
    }

    ... Request definition.

    constraints {
        (*, *) = role-prohibited;
    }

    ... More definition, e.g., associations, cardinalities.
}

Specification 3-9: Example specification of FigureChain role model.

Figure 3-21 shows the FigureChain role model.

Figure 3-21: The FigureChain role model.

Please note that these role models are concrete design artifacts, and not design patterns. (They are instances of design patterns.) It is a conscious modeling decision to make the FigureHierarchy role model have a Client role type, but to omit this role type from the FigureChain role models. These role models are defined for and used in the Figure class model defined below, where the FigureHierachy role model is used to configure the object hierarchy at runtime. From the object hierarchy, the object chain is determined, and no option for chain configuration is given.

The role models Figure, FigureHierarchy, FigureObserver, and FigureChain all generically relate to figure objects. They are therefore used by the abstract Figure and CompositeFigure classes. In addition, role models specific to a certain figure class can be defined.

For each concrete figure class like RectangleFigure or UmlClassFigure, there is a role model that describes the figure specific collaboration with its clients. Also, there is typically a role model that defines how to create a new instance. This leads to role models RectangleFigure and RectangleFigureCreation, UmlClassFigure and UmlClassFigureCreation, etc. They are omitted here, because they are fairly simple, and do not add to the discussion.

3.3.8 Composing role models

It might seem natural to introduce a composition function for role models. Composed role models would be the composition of smaller role models, which could either be atomic or other composed role models. OOram, for example, is based on a role modeling composition scheme called role model synthesis [Ree96]. However, OOram, as originally defined, has no concept of class on the modeling level.

Role modeling as defined in this dissertation directly takes the step from atomic role models to classes and class models. I have found no need for intermediate composed role models. None of the case studies presented in Chapters 6 to 8 require the introduction of composed role models. Therefore, no such role model composition function is introduced.

Composition is always carried out in the context of a class model, where role types are assigned to classes, and where the classes provide the composition function to compose role types.

3.3.9 Class model (revised definition)

This subsection revises the definition of class model given earlier. Class models are understood as compositions of role models, in which classes provide and compose role types defined by the role models.

Definition 3-20: Class model

A class model is a set of classes and a set of role models. The classes relate to each other by inheritance and object relationship descriptions between role types. The class relationship graph must be non-partitioned.

The purpose of a class model does not change: it serves to model a set of valid object collaborations. The revised definition simply adds the concept of role model to describe how the classes relate to each other. In addition to using classes, inheritance, and object relationship descriptions, a class model uses role models for the description of the set of valid object collaborations.

Effectively, a class model composes the role models. Developers assign role types to classes and define how the role types are composed to form the class type.

Between the classes, the relationships, and the role models, a set of constraints applies:

• At least one role type from one of the role models must be in the role type set of a class. Otherwise, the class or the role model would not be connected with the rest of the class model.
• The role type set of a class must fulfill the role constraints set up by the role models. This requirement avoids invalid object collaborations (see section on assigning role types to classes).
• The object relationship descriptions between role types must match those between classes. In particular, the cardinality of the descriptions between role types must sum up to those of the classes (see below).
• The relationship graph between the classes may not be partitioned, so that there is a path from every class to every other class in the model. Otherwise, a class would not be connected with the rest of the model.

Each role model describes one particular object collaboration task of the valid object collaborations defined by the class model. The role model composition leads to the class model, which in turn does not only define one or several object collaboration tasks, but the full set of possible object collaborations.

3.3.9.1 Context and scope of definitions

We can now review how the concepts introduced so far relate to each other.

Everything is defined in the context of a class model. It is the outermost concept. In the context of a class model we define role models and classes. Role types are defined in the context of role models. Classes only import the role types; they do not define them.

Role types are defined independently of classes, because their primary purpose is to show how an object behaves within a specific collaboration task. Thus, they are always a part of a role model that describes the (set of valid) object collaboration tasks.

Defining role types and role models independently of a specific class lets us introduce reusable role models that can be used by different class models. An example is the ObjectProperty role model that defines the role types Client, Provider, and Property, and that can be used by different class models (see revised class model example).

3.3.9.2 Cardinality of object relationship descriptions

The cardinality of object relationship descriptions (associations and aggregations) between role types must sum up to the overall cardinality of object relationship descriptions between the classes of the role types.

Given a pair of classes A and B, let RA be a role type of A and RB a role type of B. For any object relationship description (RA, RB) that is defined by a role model, a cardinality is defined for RA and RB. Then the following must hold:

• The sum of the cardinality associated with all RA's from the set of relationship descriptions (RA, RB) represents the cardinality of the object relationship description of class A with respect to class B.
• The sum of the cardinality associated with all RB's from the set of relationship descriptions (RA, RB) represents the cardinality of the object relationship description of class B with respect to class A.

Most class models in this dissertation omit the object relationship descriptions between classes, because they can be derived from the object relationship descriptions between role types. Should there be a case where this statement does not seem to hold, a role model is probably missing. (Such a role model may be the simple role model of a Manager object being its own Client and managing a set of Elements in a collection.)

3.3.9.3 Assigning role types to classes

A class provides a set of role types to determine the possible roles its instances may play. How do role constraints between role types affect how a class may put role types into its role type set?

The use of the abstract superclass rule (a concrete class may not have subclasses) significantly eases the definition of these assignment constraints:

• A role-dontcare constraint has no effect on how a class may provide certain role types or not.
• A role-prohibited constraint also has no effect on how a class may provide some role types, because role constraints are restricted to single object collaboration tasks only. For different tasks, an object may well play roles defined by role types between which a role-prohibit constraint exists.

  For example, the role-prohibited constraint between the Observer and Subject role type of the FigureObserver role model denotes that an object may not observe itself. However, an object may well observe another object and be observed by yet another object. Hence a class may provide both role types. This second case uses two different collaboration tasks, even though they are instances of the same role model.

• A role-implied constraint between two role types (R, S) puts a constraint on the class hierarchy of a class X that provides role type R. Another class Y now provides role type S. The role constraint is maintained if one of the following cases holds:
  • X = Y;
  • Y is a superclass of X;
  • Every concrete subclass of X provides S (either directly or indirectly).

  These three cases ensure that for a given object that plays a role defined by R, a role defined by S is available.

• A role-equivalent constraint between two role types (R, S) puts a constraint on the class hierarchy of a class X that provides role type R. Assume another class Y, which provides role type S. The role constraint is maintained if one of the following cases hold:
  • X = Y;
  • if Y is a superclass of X, and if every concrete subclass of Y provides R (directly or indirectly);
  • if X is a superclass of Y, and if every concrete subclass of X provides S (directly or indirectly).

  These three cases ensure that for a given object that plays a role defined by R, a role defined by S is available, and that for a given object that plays a role defined by S, a role defined by R is available.

As a general rule, no constraint can prevent that a class provides a certain role type. However, role-implied and role-equivalent enforce the joint provision of role types according to the above specification.

3.3.10 Figure class model (revised example)

We can now describe the Figure class hierarchy as a class model based on role models. So far, we have described the class model without role models (Figure 3-13). We also have defined the role models Figure, FigureHierarchy, FigureObserver, and FigureChain.

We further need the ObjectProperty role model, which determines the collaboration of a client with a figure and its property objects. It defines the role types Client, Property, and Provider (of property). Specification 3-10 illustrates the ObjectProperty role model.

rolemodel ObjectProperty {
    // Anything may work as a property.
    // Thus, this is a no-semantics role type serving as a handle.
    // It can be assigned to any class, even after the class has been defined.
    roletype Property {}

    // Generically manage properties of figure.
    // Examples properties are fill color, frame color, line stroke.
    // Properties may be any kind of Object.
    roletype Provider {
        collection<ref<Property>> properties;
        void hasProperty(string name);
        void getProperty(string name);
        void setProperty(string name, ref<Property> property);
        void unsetProperty(string name);
    }

    // Get and set Properties to Provider.
    roletype Client {
        // Do not set Provider as a Property to itself.
        // No further specification.
    }

    // A Provider may not be have itself as a Property.
    // A Client may not be a Property.
    constraints {
        (Property, *) = role-prohibited;
        (*, Property) = role-prohibited;
        (Client, Provider) = role-dontcare;
        (Provider, Client) = role-dontcare;
    }

    ... More definition, e.g., associations, cardinalities.
}

Specification 3-10: Example specification of Figure class model.

Also, we have not defined the class-specific role models RectangleFigure, PolygonFigure, etc. These are simple binary role models, which define a Client and a Figure role type. The Figure role type defines basic services for the Client role type. The specification given below omits the details.

Specification 3-11 describes the Figure class model.

// Figure requires ObjectProperty and Graphics role model.
import Object.ObjectProperty;
import Graphics.Graphics;

classmodel Figure {
    rolemodel Figure { ... }
    rolemodel FigureHierarchy { ... }
    rolemodel FigureObserver { ... }
    rolemodel FigureChain { ... }

    class Figure extends Object {
        roletype Figure.Figure;
        roletype FigureHierarchy.Child;
        roletype FigureObserver.Subject;
        roletype FigureChain.Predecessor;
        roletype ObjectProperty.Provider;
        roletype Graphics.Client;
        ... More definition.
    }

    class CompositeFigure extends Figure {
        roletype FigureHierarchy.Parent;
        roletype FigureChain.Successor;
        ... More definition.
    }

    rolemodel RectangleFigure { ... }
    rolemodel RectangleFigureCreation { ... }

    class RectangleFigure extends Figure {
        roletype RectangleFigure.Figure;
        roletype RectangleFigureCreation.Creator;
        roletype RectangleFigureCreation.Product;
        ... More definition.
    }

    rolemodel PolygonFigure { ... }
    rolemodel PolygonFigureCreation { ... }
    class PolygonFigure extends Figure { ... }

    rolemodel TextFigure { ... }
    rolemodel TextFigureCreation { ... }
    class TextFigure extends Figure { ... }

    rolemodel GroupFigure { ... }
    rolemodel GroupFigureCreation { ... }
    class GroupFigure extends CompositeFigure { ... }

    rolemodel UmlClassFigure { ... }
    rolemodel UmlClassFigureCreation { ... }
    class UmlClassFigure extends CompositeFigure { ... }

    rolemodel UmlAssociationFigure { ... }
    rolemodel UmlAssociationFigureCreation { ... }
    class UmlAssociationFigure extends CompositeFigure { ... }

    ... More definition, e.g., associations, cardinalities.
}

Specification 3-11: Example specification of Figure class model.

Figure 3-22 shows the class model using role models. The figure shows class-level role types for the first time. Class-level role types are role types of the class object (see discussion below). They look like regular (instance-level) role types, but are shown with a rectangle rather than an oval as the bounding box.

A role type, which is put on top of a class, is an element of that class' role type set. The object relationship descriptions between classes are omitted to avoid cluttering up the figure. They can be derived from the relationship descriptions between the role types.

Figure 3-22: Class model of the example Figure class model, including all role models.

Figure 3-22 demonstrates a few interesting issues.

• We can see how a class assembles a set of role types and composes them. For example, the Figure class provides the Figure, Subject, Child, Provider, and Predecessor role types.
• Also, no object relationship descriptions between classes are needed, because they can be derived easily from the relationship description between role types.
• All important role models deal with the key classes Figure and CompositeFigure. The less important subclasses only provide simple binary domain-specific role models like RectangleFigure.
• The average subclass introduces two role models. One that provides its primary domain functionality (like RectangleFigure), and one that lets clients create instances of the class (like RectangleFigureCreation).

The Figure class model raises some issues that need more discussion.

3.3.10.1 Roles of class objects

Class objects are objects and therefore play roles. The class of a class is called its metaclass. The role types of a metaclass need a dedicated textual and visual notation to not screw up specifications and diagrams.

Textually, we tag the metaclass' role type using the keyword static, and put them next the role types of the class. Visually, in a class model, we draw the bounding box of a static role type as a rectangle, rather than as an oval. This distinction lets us put static role types right next to regular role types.

Consider the GroupFigureCreation role model for creating a GroupFigure object. A Client object calls the new operation on a Creator, the class object. The Creator creates the new Product object that it returns to the Client. The Creator and Product role types are made up by the different constructor and initialization operations.

Specification 3-12 shows the textual specification of the GroupFigureCreation role model.

rolemodel GroupFigureCreation {
    roletype Client {
        // No constraints.
    }

    roletype Creator {
        GroupFigure new();
        GroupFigure new(collection<ref<Figure>> elements);
        ... Possibly more.
    }

    roletype Product {
        initialize(collection<ref<Figure>> elements);
    }

    ... More definition, e.g., associations, cardinalities.
}

class GroupFigure extends CompositeFigure {
    static roletype GroupFigureCreation.Creator;
    roletype GroupFigureCreation.Product;
    ... More role types.
}

Specification 3-12: GroupFigure class and GroupFigureCreation role model.

Figure 3-23 shows the GroupFigureCreation role model visually.

Figure 3-23: GroupFigure class with GroupFigureCreation role model.

Depending on the programming language used to implement this role model, different language features can be deployed to make it more convenient to use. For example, in Java, unless there are more specific requirements, Creator.new() should be mapped on new GroupFigure(), which may then internally call initialize() with an empty collection.

3.3.10.2 Boundaries of class model

The class model of Figure 3-22 presents only a part of what would be a realistic class model for a drawing editor. Basic graphical figure classes, like CircleFigure or TriangleFigure are missing. Also, domain-specific graphical figure classes are missing, like UmlInterfaceFigure, UmlInheritanceFigure, or UmlCollaborationFigure, as in the case of the UML drawing editor example.

If we added these classes, the class model would grow until it encompassed the whole system. The result would be a single large class model, which would be very inconvenient to use. Therefore, concepts to partition such a class model are needed. Categories, subsystems, and frameworks are examples of such concepts. As this work focuses on frameworks only, we omit the other concepts.

The next chapter shows how the class model can be partitioned into one framework and two framework extensions. The framework comprises the Figure, CompositeFigure, and GroupFigure classes. The first framework extension part encompasses the fundamental figure classes, and the second framework extension encompasses the application-specific figure classes.

3.3.11 Design patterns in role modeling

This dissertation is not about design patterns. However, design patterns permeate framework design. The Figure class model example shows several design pattern instances. The case studies in Chapter 6 to 8 show even more design pattern applications in the context of object-oriented frameworks. Therefore, it is helpful to show how design patterns relate to role models. Knowing patterns in their role model form lets us communicate design examples much faster than is possible without patterns.

3.3.11.1 Design patterns and design templates

A pattern is the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts [RZ96]. An object-oriented design pattern is a pattern in the domain of object-oriented design. A pattern is frequently described as a problem/context/solution triple [GHJV95, BMR+96]. According to [GHJV95, p. 407], "design patterns identify, name, and abstract common themes in object-oriented design. They preserve design information by capturing the intent behind a design. They identify classes, instances, their roles, collaborations, and the distribution of responsibilities."

Despite much recent work on design patterns, many misunderstandings about patterns remain [Vli98]. Perhaps the most common and most harmful misunderstanding is to take the structure diagram of a design pattern description, for example from [GHJV95], as a rigid definition of the pattern. The structure diagram and the description of its participants are an illustration of one common form of the pattern. By no means does the structure diagram represent the one and only form of the pattern.

It is helpful to distinguish between the concept of design pattern and design template. A design pattern is an abstract idea that defies formalization and therefore precise definition. However, for any given pattern, we can define an infinite number of design templates that can be represented in a formal way. The specification of such a design template can be carried out using any appropriate formalism, making code generation and conformance checking of implementations possible.

A pattern is an abstract idea that can be illustrated in many different ways and that can be instantiated in an infinite number of ways. We can illustrate a design pattern using role models as much as we can illustrate it using the class diagrams in [GHJV95]. We can also use both. The choice of a particular modeling technique depends on how well the presentation conveys the pattern idea to its readers.

In [Rie96a] I discuss the advantages of role modeling over traditional class-based modeling for illustrating design patterns. Almost all design patterns, in particular those from [GHJV95] can be illustrated using role models. The role model form of a pattern lets developers more easily understand the pattern structure and apply it in a new design than possible with traditional class-based modeling.

3.3.11.2 The Composite pattern as a role model (example)

The extended role modeling technique lets us illustrate design patterns in a more comprehensive way than traditional class-based modeling lets us do.

Consider the Composite design pattern [GHJV95]. The Figure class model uses an instance of this pattern in the form of the FigureHierarchy role model.

Figure 3-24 shows an illustration of the Composite pattern in role model form. It has two parts. The core part is the Client/Child/Parent role model that constitutes the Composite pattern. The second part is a separate NodeClient/Node role model that represents a domain functionality role model. This second role model is grayed out in the figure, because it does not directly belong to the pattern.

Figure 3-24: Illustration of the Composite pattern using role models.

The NodeClient/Node role model represents the domain functionality of the domain the pattern is applied in. The Client/Child/Parent role model represents the core idea of the pattern, namely that a Parent object can have several distinct Child objects and that the Parent object gets configured with its Child objects by a Client. The role-implied look-alike symbols transfer their role modeling meaning to the pattern level. It should be noted, however, that no precise semantics are underlying this pattern illustration. Here, the role-implied constraints state that any Child object and any Parent object always must be able to play the Node role.

Figure 3-25 shows the most common class model of the Composite pattern. It also shows how the role models are applied to this class model, thereby clarifying the different responsibilities of the classes.

Figure 3-25: Illustration of the most common class model of the Composite pattern.

To drive home the point that role models, in conjunction with class models, illustrate design patterns more comprehensively than traditional class-based modeling, Figure 3-26 shows another class model that illustrates the Composite pattern equally well.

Figure 3-26: Illustration of an alternative class model for the Composite pattern.

Both class models can be formalized as design templates. They represent the pattern idea in a specific form. The first case, shown in Figure 3-25, covers the majority of the pattern applications, but the second case, shown in Figure 3-26, can also be found.

3.3.11.3 Further design patterns

In addition to the Composite pattern, the Figure example uses the Observer, Chain of Responsibility, and Property List pattern. They occur as the FigureObserver, FigureChain, and ObjectProperty role models.

Appendix D presents these and many other patterns in role model form. The case studies of Chapter 6 to 8 draw heavily on these patterns to describe framework designs.

3.3.12 Visual role model shorthands

The textual and visual presentation of class models can become complex, in particular if many role models are involved. However, conciseness of presentation is important, because it helps communicate the design structure more effectively than possible by a lengthy presentation (which is also needed).

Sometimes the same types of role models are composed in a class in always the same way. It is very inconvenient to elaborately specify and draw these compositions in all their detail. Common recurring compositions should be captured using a shorthand notation.

Consider a Drawing class. In a drawing editor application, there might be exactly one instance of the Drawing class, which represents the whole drawing. Assume that there is one central place where to get this object, and that this is the class object of the Drawing class. Therefore, the Drawing class offers a simple access operation to it (DrawingSingleton role model). Moreover, the Drawing object is instantiated only when the first access occurs. Thus, the Drawing class object plays the Client and Creator roles in a DrawingCreation role model.

Figure 3-27 shows the resulting visual specification.

Figure 3-27: Drawing class with DrawingSingleton and DrawingCreation role models.

Because this kind of role model composition is such a common case that we abbreviate it using a shorthand. Figure 3-28 shows how the shorthand symbol looks like.

Figure 3-28: Drawing class with collapsed DrawingSingleton and DrawingCreation role model.

Unless a precise role type specification is required, it is sufficient for all practical purposes to use the terminology set up in Figure 3-28 to discuss this design. The case studies of this dissertation make use of this shorthand to save time and space and to avoid unnecessarily lengthy discussions.

Appendix C, the notation guide, presents further shorthands.

3.4 Summary

This chapter describes fundamental object and role modeling concepts needed for framework design. These concepts form the building blocks of all further concepts to come in this dissertation. They are needed to define higher-level concepts for framework design.

First, the chapter presents a concise summary of traditional class-based modeling concepts. It then enhances these concepts with new and adapted role modeling concepts. The new role modeling concepts add to the existing concepts and do not replace them.

The overall method becomes an evolutionary extension of existing object modeling approaches. They add to them where necessary rather than trying to replace them. Existing designs and documentations are not invalidated. However, using role modeling, they can be defined much more precisely and with greater detail.

The next chapter on framework design builds on this foundation to better describe object-oriented frameworks.