Chapter 9: Thesis Validation

This chapter validates the dissertation thesis. It first reviews the thesis and then devises a validation strategy. Based on the form of the thesis statement, the validation strategy is to split the thesis up into nine parts, each of which can be validated individually. Every sub-validation is carried out using general arguments about object-oriented framework design that are backed by the observations made and experiences gained in the case studies. The validation of the dissertation thesis follows from the sub-validations.

9.1 Thesis review and validation strategy

Chapter 2 presents the final version of the thesis of this dissertation:

Thesis statement of dissertation (final version, taken from Chapter 2)

Role modeling for framework design makes the following activities easier to carry out for the expert framework developer and user than is possible with traditional class-based approaches:

• designing and redesigning a framework;
• learning a framework from its documentation;
• using a framework that is already understood;

The following problems are addressed and their severity is reduced:

• complexity of classes;
• complexity of object collaboration;
• clarity of requirements put upon use-clients.

This form of the thesis helps to determine what to prove and which constraints to adhere to while doing so.

First, a validation of the thesis must be based on a comparison between the "traditional class-based approach" and the role modeling approach. Unless stated otherwise, role modeling always means "role modeling for framework design as defined in this dissertation". Traditional class-based approach means what you can natively express using classes as the only central modeling concept (for example, UML). Also, the discussion is restricted to expert developers and users only.

Then, the thesis is split up into different parts: designing and redesigning a framework, learning a framework from its documentation, and using an already understood framework. These are separate activities that can be discussed and validated independently.

Finally, the thesis defines in which respect role modeling eases the different activities by stating which problems it addresses: class complexity, object collaboration complexity, and clarity of requirements and constraints put upon use-clients.

This leads to a matrix of sub-theses (claims) to be validated, displayed in Table 9-1.

(activity, problem) matrix	designing and redesigning a framework	learning a framework from its documentation	using an already understood framework
complexity of classes	Validity to be shown.	Validity to be shown.	Validity to be shown.
complexity of object collaboration	Validity to be shown.	Validity to be shown.	Validity to be shown.
clarity of requirements put upon use-clients	Validity to be shown.	Validity to be shown.	Validity to be shown.

Table 9-1: The dissertation thesis broken up into nine sub-theses.

The matrix has the set of activities as its X-dimension, and the set of problems as its Y-dimension. A matrix cell is referenced using A for activity, P for problem, and a digit for the particular activity and problem. For example, A2P1 is the top middle matrix cell (activity: learning a framework; problem: complexity of classes).

For each cell in the matrix, it needs to be shown that the X dimension, the activity, becomes easier (or stays the same) with respect to the Y dimension, the problem, if one compares the traditional class-based approach with the role modeling approach.

Because the dissertation thesis is viewed as the conjunction of these nine sub-theses, the overall thesis validation becomes the conjunction of the nine sub-validations.

The matrix form suggests a validation strategy in which each sub-thesis is assessed and validated individually. For nine sub-theses, this is a tedious and repetitive undertaking, because many arguments and experiences apply to several of them.

A better validation strategy is to walk through a set of key properties of the role modeling approach and show how they lead to arguments that validate one or more of the nine sub-theses. In a second step, for each sub-thesis, the arguments can then be put together to form the overall validation of the sub-thesis. With all nine sub-theses done, the overall thesis validation is also done.

The next subsection carries out the thesis validation using this strategy.

9.2 Thesis validation

This subsection presents the actual validation of the dissertation thesis. It follows the validation strategy outlined above: it first walks through a set of key properties of the role modeling method, and then consolidates the resulting arguments for each sub-validation. The thesis validation follows as the conjunction of the sub-validations.

9.2.1 Describes class as composition of role types

Role modeling, as defined in this dissertation, lets developers describe classes as compositions of distinct role types. Or, viewed the other way round, class interfaces are broken up into role types. A role type is used in two different contexts. In the first context, the role type is part of a role model, where it is defined. In the second context, a role type is part of the role type set of a class, where the class defines how the role types are composed to determine the behavior of its instances. Traditional class-based modeling offers no appropriate means to split up a class interface into distinct parts.

When dealing with a class, developers switch between the two views. On the one hand, they focus on the role type in the context of its role model to define, use, or understand the specific aspect of the class being described by the role type. On the other hand, they focus on the composition of the role types to understand what makes up the class as a whole and how acting in the context of one role will cause actions in the context of another role of instances of that class.

Describing a class as the composition of role types and breaking up a class interface into role types separates design concerns along the lines of object collaboration tasks. This property of the approach helps with the following activity/problem pairs:

• Designing complex classes of a framework (A1P1). Role modeling makes it easier to design a class and its interface, because keeping the role model and the class view separate and being able to easily switch between them reduces the complexity of the design task.

  The experiences with designing the Geo frameworks and the Tools framework support this argument. For example, the Geo system has several complex service interfaces. Splitting them up into different role types significantly reduced the complexity of the remaining design task.

• Learning complex classes of a framework (A2P1). Role modeling makes it easier to understand a class, because keeping the role model and the class view separate and being able to easily switch between them reduces the complexity of the learning task.

  It was a common experience in the Geo project that it is easier to learn key classes from a framework designed and documented using role modeling than possible with documentation based on traditional class based modeling. The same argument holds true for the JHotDraw framework.

• Using a class from an well-understood framework (A3P1). Role modeling makes it easier to use a class, because it is better understood, and because developers can focus on the different uses of a class independently of each other.

  Describing classes as compositions of role types eased using key classes from the Geo frameworks. Also, when designing and implementing client classes, the focus is on single role types rather than full classes. This reduces the complexity of defining client classes further.

The property "describes class as composition of role types" of the role modeling approach therefore significantly eases designing, learning, and using complex classes of a framework. This addresses the activity problem pairs A1P1, A2P1, and A3P1.

9.2.2 Breaks up relationship descriptions into role models

Role modeling, as defined in this dissertation, breaks up the object association or aggregation descriptions of traditional class-based modeling into role models. A role model focuses on one particular object collaboration task, while a traditional object relationship description comprises all possible tasks carried out on an instance of the relationship description. The object relationship description between two classes becomes the sum of the role relationships descriptions between role types from role models that connect these two classes. Traditional class-based modeling offers only object relationship descriptions between classes, but no role models.

Role models can be viewed as zooming in on an object relationship description. They detail what is going on between the involved classes. Developers can therefore maintain two different views on how classes relate to each other. They can see the traditional object relationship descriptions that determine, which object may relate to which other object in what quantities, etc., and they can zoom in on any such relationship description to determine the different object collaboration tasks carried out using instances of these relationship descriptions.

Chapters 3 and 4 have shown that the role model view is an extension of the relationship description view, and that the object relationship descriptions between classes can be derived from role models. The object relationship descriptions determine the base skeleton, and the role models describe the behavior of objects working along this predefined structure. These complementary views help with the different activities and their problems.

Breaking up relationship descriptions into role models eases handling the complexity of object collaboration. This property of the approach helps with the following activity/problem pairs:

• Designing the object collaboration of a framework (A1P2). Role modeling eases designing the framework's object collaboration, because developers can zoom in on the object relationship structure, determine the tasks carried out along its line, and switch back to the big picture again. They can work on a detail level that is best for the current design issue, be it the overall structure or the individual collaboration tasks.

  The experiences with the Geo frameworks and the Tools framework directly support this argument. During design sessions team members continuously switched between the class structure and their relationship descriptions on the one hand, and the detailed discussion of how instances of these classes collaborate on specific tasks using role models on the other hand. Many of these role models were design pattern instantiations, which made them a well-defined design issue in itself.

• Learning the object collaboration of a framework (A2P2). Object relationship descriptions tell us about the structural relationships between objects of a framework, but they tell us nothing about the tasks they carry out. Role models do that. Role modeling significantly eases learning the object collaboration, because it makes information explicit that would otherwise be lost or described in other (then sub-optimal) ways.

  Again, the experiences from the case studies directly support this argument. When team members had to understand a new design or learn an existing framework, the two views of object relationship descriptions and role models helped them better and faster understand the intent of a design. Also, team members could more readily recognize design patterns based on the catalog of role model design patterns [Rie97a]. This helped reusing prior experience.

• Using classes from an well-understood framework (A2P3). Using role models, use-clients can be precise about what they want from a framework class (by picking up a specific free role type). Using object relationship descriptions, use-clients always get a bundle of role models, of which they may only be interested in one. Also, in traditional class-based modeling, use-clients without operations are not represented at all, even if they play a significant role. Role models provide free role types even for use-clients that have no operations. Hence important information is documented that gets lost in class-based modeling.

  The case study experiences support this argument. For example, the Geo service interfaces clearly separated the different issues of using the services as free role types. Team members could therefore distinguish between the different tasks like retrieving the service object, configuring it with information, and using its primary functionality. These tasks could be carried out by different objects and were not bound to one specific client class.

The property "breaks up relationship descriptions into role models" of the role modeling approach therefore significantly eases designing, learning, and using a framework that has complex object collaboration. This addresses the activity/problem pairs A1P2, A2P2, and A3P2.

9.2.3 Makes requirements on clients explicit

Role modeling, as defined in this dissertation, makes requirements and constraints put upon use-client classes explicit. The requirements and constraints are described using role types and role constraints. The role types are the free role types of a framework, and the role constraints are those constraints that relate to free role types. How exactly requirements and constraints on clients are specified depends primarily on the chosen type specification mechanism.

Traditional class-based modeling offers two possibilities to define requirements and constraints put upon clients:

• classes or interfaces that client classes have to inherit from;
• class specifications as part of a framework class interface.

This has the following problems:

• Making clients inherit from classes to enforce constraints is too heavyweight an approach, if clients have to inherit unwanted baggage (implementation state, operation implementations). Partially or fully implemented classes are not always an adequate means for specifying client constraints.
• Making clients implement specific interfaces is frequently better than making them inherit from classes. If an interface represents a role type, the role modeling approach and the traditional class-based approach are equivalent. However, in the traditional approach, such interfaces are used only if operations are associated with them. No-operation free role types are missed.
• Making requirements and constraints put upon clients part of a framework class specification forces developers of any client for any collaboration task to keep in mind the whole specification. Splitting it up into role types separates different behavioral aspects of the class and therefore reduces complexity. (See the arguments of why to break up a class interface into role types).

Moreover, the traditional approach to requirements and constraints specification puts the specification into the wrong place, namely the framework class. It is better to put it into the free role types, because the requirements are requirements on clients, and need to be adhered to by them, and not by the framework classes. However, as long as there was no concept of free role type, there was no possibility of making explicit that use-clients are responsible for adhering to the specifications. Thus, they were specified as part of a framework class interface.

Finally, the free role types are part of free role models. The additional view on object collaboration tasks provides the benefits of breaking up class interfaces into role types and breaking up object relationship descriptions into role models. This also applies to the specification of requirements and constraints put upon clients. (See the discussion of these role modeling properties above).

For these reasons, role modeling provides a better background for specifying the requirements and constraints put upon clients than traditional class-based modeling. Role modeling therefore helps with the following activity/problem pairs:

• Designing use-client requirements (A1P3). Free role types are a better means of enforcing requirements and constraints than classes. They are also a better means than interfaces, if these are only used to specify requirements that are attached to operations. Also, role types stem from role models, and therefore show how they tie in with the framework. Traditional class-based modeling falls short here as well.

  The experiences with the Geo frameworks and the Tools framework support this argument. For every role type provided by a framework class, the defining role model had to specify at least one client role type. Team members therefore always had to ask themselves what a specific role type was good for, and how the counterpart in the described collaboration task had to look like. This is in contrast to earlier experiences with traditional class-based modeling, where it was easy to forget about clients, and that they also had to fulfill requirements and adhere to constraints.

• Learning how to use a framework (A2P3). Free role types specify requirements and constraints well and completely (as far as possible with the chosen type specification mechanism). Moreover, they provide separation of concerns as discussed above in the subsections on breaking up class interfaces and object collaborations. Both make it easier to learn how to use a framework.

  Again, this argument is supported by the experiences from the case studies. The primary reason is the separation of concerns achieved by defining free role types and by breaking up the relationship descriptions into role models. In class-based modeling, client requirements are either not specified or, at least, they are more difficult to understand. Thus, role modeling reduced the complexity of understanding all requirements and constraints.

• While using a framework, adhering to its requirements and constraints (A3P3). Every use-client has to specify explicitly how it ties in with the framework by stating which free role types it uses. None can be forgotten or omitted. This requirement allows checking for proper use of the framework.

  This argument is also supported by the case study experiences. First, learning a Geo framework more easily also made it easier to lay out how to use it. Second, when using it, the free role types and their description where a constant reminder and measure of how use-client classes had to look like and how their implementation had to behave.

The property "makes requirements on clients explicit" of the role modeling approach therefore eases designing, learning, and using a framework with respect to the requirements and constraints put upon clients. This addresses the activity/problem pairs A1P3, A2P3, and A3P3.

9.2.4 Supports reuse of experience

Role modeling, as defined in this dissertation, better supports developers in reusing previous design experience than possible with a traditional class-based approach. Reuse of design experience can take on two forms in this context. First, developers may adapt earlier designs to new requirements and derive the new design from this, and second, developers may apply design patterns [GHJV95, RZ96].

In comparison to class-based modeling, role modeling eases reusing experience, because the separation of concerns it achieves makes designs more readily decomposable into pieces and recomposable from these pieces. Role modeling supports this particular well, because it works along the lines of object collaboration, which are a main focus of design and also of reusing experience.

• Reuse of experience through design adaptation. In this form of reuse, a developer reconsiders an old design, takes out the pieces not needed in the new design, changes the pieces according to new requirements, and adds new pieces as required for the new design. The result is the new design. An example are the Geo service interfaces, which are very similar, but differ in the details of the actual services provided.

  If the old design has a clear role modeling description, reusing experience this way is made easier, because the old design already separates the different concerns that become the individual focus of attention when adapting the design for a new situation. The design is adapted along the lines of the object collaboration tasks that are described by the role models of the old and then new design.

• Reuse of experience through design patterns. In this form of reuse, an experienced developer recognizes a design problem and recalls a design pattern that he applies to solve the problem in the given context. Design patterns can take on many different forms. The most common object-oriented design patterns have been described in the seminal work of Gamma et al. [GHJV95]. Each of the design patterns from this catalog makes one specific design aspect flexible so that it can be changed easily.

  Most of these patterns are about the distribution of responsibilities among the objects of a design, and how the responsibilities are assigned to classes. Using role modeling terminology, each pattern instance focuses on one specific object collaboration task, and the assignment of responsibilities to classes corresponds to putting role types from a role model into the role type sets of classes. Of the patterns from the design patterns catalog, the larger part can be described well using role modeling [Rie97a, Rie97c]. (Also see Appendix D.)

  In a design, a design pattern application needs to be composed with other design pattern applications and role models. Recasting design patterns in role model form makes it easier to keep the different collaboration tasks separate, and thereby eases the reuse of experience. As I have demonstrated, using role models for describing design patterns makes them more flexible and more easily applicable, without making them use their particular patterns quality [Rie96a]. Traditional class-based modeling offers no such support.

Being able to reuse experiences addresses every kind of problem in object-oriented framework design. Therefore, role modeling better supports all of the activities and eases all of the problems than class-based modeling does (in this respect).

When designing the Geo system, the team made use of its own version of the design patterns catalog, which recast all the common design patterns in role model form. This catalog was a constant companion, and helped team members in all of the activities regarding all of the problems.

The use of design patterns is ubiquitous in the Geo frameworks, the Tools framework, and the JHotDraw framework. They have been applied to form or used to describe free role models as well as internal role models. They serve to more readily understand the framework's client collaboration as well as its inner workings. And they support using the framework.

Therefore, the property "supports reuse of experience" of the role modeling approach eases designing, learning, and using a framework with respect to all stated problems. This addresses the activity/problem pairs A1P1 through to A3P3.

9.2.5 Consolidation of validation

There are further properties of role modeling that help with framework design and use (for example, frameworks are made explicit design artifacts with well-defined boundaries) and that have not been discussed in the previous subsections. However, the purpose of this section is to validate the dissertation thesis. Therefore, properties that do not directly contribute to this validation have been omitted.

The previous subsections discussed the following properties and examined their effect on the activity/problem pairs derived from the dissertation thesis.

• Section 9.2.1: Describes class as composition of role types. Helps ease the problem of dealing with the complexity of classes for all three activities.
• Section 9.2.2: Breaks up relationship descriptions into role models. Helps ease the problem of dealing with complex object collaboration of a framework for all three activities.
• Section 9.2.3: Makes client requirements explicit. Helps ease the problem of specifying requirements and constraints put upon use-clients of a framework for all three activities.
• Section 9.2.4: Supports reuse of experience. Helps ease every problem for every activity, because developers have experience to reuse for all of them.

Table 9-2 shows where to find the arguments that prove a particular activity/problem pair.

(activity, problem) matrix	designing and redesigning a framework	learning a framework from its documentation	using an already understood framework
complexity of classes	9.2.1 9.2.4	9.2.1 9.2.4	9.2.1 9.2.4
complexity of object collaboration	9.2.2 9.2.4	9.2.2 9.2.4	9.2.2 9.2.4
clarity of requirements put upon use-clients	9.2.3 9.2.4	9.2.3 9.2.4	9.2.3 9.2.4

Table 9-2: Where to find the arguments for the sub-validations.

The validation of the dissertation thesis is the conjunction of the validation of the nine sub-theses. Table 9-2 shows in which subsection each sub-thesis has been addressed and validated. For each sub-thesis, there are at least two major validating arguments. Because the thesis dissertation is the conjunction of these sub-validations, Table 9-2 concludes the thesis validation.

9.3 Summary (meaning of validation)

The thesis validation shows that role modeling as defined in this dissertation is superior to traditional class-based modeling with respect to the problems stated initially in this work. As reviewed in Chapter 2, related work has also tried to address some of the problems that role modeling solves. However, none of this related work achieves this density of problem solving as role modeling.

It is the nature of a validation to focus exclusively on what needs to be validated and to ignore any other consequences. However, it may be exactly the side effects, why a specific statement, in this case the dissertation thesis, was set up in the first place. Thus, the validation does not tell the full truth about why role modeling represents an improvement over current practice.

In explaining the thesis as the sum of several distinct parts, it became possible to more precisely describe the thesis, and to devise a validation strategy based on breaking it up into parts. Doing so, however, the whole, which is more than the sum of its parts, got lost. Much of the power of role modeling for framework design as defined in this dissertation stems from the interaction of the different parts. Without role types, there would be no role models. Without role models, there would be no precise definition of client interaction. Without role models, there would only be limited increase of reuse of experience. Etc.

However, for the purposes of the thesis validation, this is irrelevant. It needed to be shown that role modeling is a significant improvement over current practice, and this has been done. How the validation result is used is not to be defined by the dissertation. It will become apparent in the practice of using role modeling for framework design.