Chapter 10: Conclusions

Home - About » Computer Science - Research - Dissertation
Computer Science
Research, Industry Work,
Community Service
Hillside Group, CHOOSE,
Stanford GSA
The Serious Side
Business School,
Learning Chinese
Humorous Takes
Switzerland, United States,
Software, Fun Photos
Travel Stories
Europe, United States, Asia
Living Places
Berlin (+ Gallery), Zürich
Boston, S.F. + Bay Area

This chapter sums up the contributions made by the dissertation, points towards future work, and provides final conclusions on the results of this dissertation.

10.1 Contributions

The primary result of this dissertation is that role modeling for framework design, as described in Chapters 3 and 4, makes the design of object-oriented frameworks easier than is possible with traditional class-based approaches. This claim is detailed in Chapter 2. Naturally then for a dissertation, most parts of the exposition focus on validating precisely this claim. Chapters 6 to 8 provide case studies of using this method, and Chapter 9 validates the thesis based on the case studies.

Next to validating the thesis, this dissertation presents a novel modeling approach to framework design. It is both a precondition for the thesis as well as a major achievement in itself. Role modeling for framework design achieves the following results:

  • Novel role modeling concepts. This dissertation introduces role constraints as a new concept to more precisely define role models. Role constraints let developers specify how roles may or may not come together in an object. Earlier role modeling approaches offer no such description mechanism.
  • Integration of role modeling with class-based modeling. Earlier role modeling approaches, in particular [Ree96], view role modeling and class-based modeling as different paradigms. Andersen, following up on Reenskaug, brings classes back into the picture, but still views them as largely unrelated to roles [And97].

    This dissertation shows how role modeling can be integrated with traditional class-based modeling so that the respective strengths are added and the weaknesses are dropped.

    • The dissertation revises the existing concepts of role, role type, role model, class, and class model to better fit together, and is precise about the distinction between type level (role type, class, role model, class model) and instance level (role, object collaboration task, object collaboration).
    • The dissertation demonstrates the complementary focus of classes and role models. A role model describes how objects collaborate for one specific object collaboration task. A class defines how several roles from different collaboration tasks come together in one object, thereby defining how to bridge and integrate the tasks.
  • Introduction of an explicit framework concept. The modeling method gives a precise definition of what a framework is and what its properties are. The definition of the framework concept is based on the notions of free role model, built-on class set, and extension point classes.
    • Using free role models, developers specify how a framework is to be used by clients.
    • Using built-on class sets and free role models, developers specify how a framework builds on other frameworks and how it depends on its environment. While software engineering has long understood that next to provided functionality also required functionality needs to be specified [Wir82, PN86], facilities to do so in framework design have been missing.
    • Using extension-point class sets, developers can specify how a framework may be extended.

    These concepts are unique to frameworks and let developers speak about and deal with frameworks in a framework-specific way. A framework becomes an explicit design artifact rather than just another class model.

In addition, role modeling for framework design provides excellent means for describing design patterns and for showing how they are used in the context of object-oriented frameworks.

  • Description of design patterns. Role modeling as defined in this dissertation is a more general way of illustrating design patterns. A role model illustration of a pattern can be applied in more ways than a class-based illustration. A role model illustration adds to a class-based illustration, because a class-based illustration typically suggests too rigid a structure of pattern application.
  • Application of patterns in framework design. Because role models are prepared for composition right from the start, they show well how pattern applications compose and overlap in framework design. Class-based modeling offers no such facilities. Annotating classes as participants of a pattern instantiation goes into the right direction but stops halfway. Role modeling goes all the way.

These contributions are described in more detail and validated in the main body of the dissertation. Some of them have also been published at conferences and in journals [Rie96a, Rie97c, RG98, RBGM99].

10.2 Future work

This dissertation work opens several venues for future work, both with a narrow focus on role modeling, and a larger focus on frameworks and design patterns.

  • Choice of a type specification mechanism. The dissertation suggests no specific type specification mechanism. Any mechanism that provides types, subtyping, and type composition suffices. However, some type specification mechanisms may be more convenient and more effective to use than others. Therefore, a mechanism custom-tailored to the needs of role modeling may be developed.
  • Introducing dynamic behavior specifications. Because type specification issues are largely ignored in this dissertation, not much is said about dynamic behavior specifications. However, role models are best described not only by individual role types, but also by descriptions of the allowed collaborative behavior of objects acting according to the role types. Therefore, Reenskaug's or Andersen's mechanism to describe collaborative behavior of object roles may be adapted [Ree96, And97], or a new one may be developed.
  • Composition of role types independently of classes. Role modeling for framework design as presented in this dissertation composes role types to derive classes. I have never found a real need to compose role types to become composite role types. However, it may be a nice-to-have feature that could be useful once it is available.

Future work of this kind may directly build on current type specification mechanisms. However, existing mechanisms need to be adapted to fit role modeling in such a way that the separation of concerns achieved by role modeling is maintained. The benefit of reduction in complexity that role modeling achieves is directly based on the separation of concerns it provides.

  • Inheritance relationship between role models (addressing the problem of covariant redefinition). The dissertation does not introduce a concept of inheritance between role models. Any role model that could be viewed as a specialization of an existing role model is viewed as a different unrelated role model. It seems helpful in many situations, however, to view one role model as a specialization of another more general role model. For example a simple PersonModel/PersonView role model might be specialized to form a CustomerModel/CustomerView role model.

    Inheritance between role models might give a new twist to the problem of covariant redefinition of operation signatures. The covariant redefinition of parameters of an operation in a subclass (and the contravariant redefinition of return value or object types) serves to ensure that class hierarchies are specialized in parallel. The covariant redefinition of operations of a class is always carried out with a particular partner class in mind. Thus, covariant redefinition is about ensuring constraints on a set of allowed collaboration tasks (rather than individual classes). Expressing these collaboration tasks is all what role models are about.

  • Extension of programming languages with role modeling concepts. It would certainly be helpful to support the implementation of a role-model-based design with dedicated programming constructs. Such a role-oriented programming language might provide concepts for directly and conveniently expressing role types and role models.

    Current work already points into that direction. Van Hilst presents a role programming method using C++ templates [Van97], and Kendall uses aspect-oriented programming to more easily implement role-model-based designs [Ken99].

  • Support for design patterns and design templates. Role modeling lets developers more easily apply and recognize design patterns in object-oriented designs (than is possible with traditional class-based designs). A dedicated design notation for specifying design templates for design patterns may be based on role modeling rather than class-based modeling [Rie96a]. Then, the application of a design pattern leads to a specific role model that can be easily composed with other role models in the context of an object-oriented design.

    On the pattern/template level, something alike to composite role types is going to be helpful, as illustrated by the Bureaucracy pattern [Rie98]. The Bureaucracy pattern is a composite pattern in which different role types from different design patterns are composed to form the pattern/template level equivalent of a composite role type.

  • Empirical assessment of use of design patterns in framework design. The case studies of Chapters 6 to 8 provide some empirical data about the frequency of use of design patterns in framework design. Role models can be used as a kind of object-oriented function-point, that is, as an atomic unit of functionality in framework design. Thus, role models may serve as a coarse-grained measure for complexity in framework design.

    An analysis of frameworks described using role modeling can provide us with a figure about the frequency of design pattern application in relation to the overall functionality (= total number of role models in a framework's design). Arriving at a statement like "60% of a framework's functionality can be described using design patterns" is a valuable result to justify further research into design patterns.

Finally, marrying component-based design with object-oriented frameworks is a whole new research area. It does not follow directly from this dissertation, but it should take the new understanding of frameworks gained through this dissertation into account. Then, role modeling is likely to find its way into component design and implementation. Role modeling might even be reintroduced on a component framework level to better describe how components collaborate.

10.3 Final conclusions

Role modeling provides separation of concerns in a way that is highly beneficial to class-based design of frameworks. This dissertation shows how to marry role modeling with class-based design of frameworks. Role modeling for framework design has the following properties:

  • It reduces complexity of classes in framework design.
  • It reduces complexity of object collaboration in framework design.
  • It better supports specifying requirements put upon use-clients of a framework.
  • It lets developers apply and recognize design patterns in frameworks more easily.
  • It provides new and revised role modeling concepts for more precise framework design.
  • It makes frameworks first class citizens of software architecture.

Role modeling for framework design combines the strengths of role modeling with those of class-based modeling while leaving out their weaknesses. It is therefore an evolutionary extension of current methods that preserves existing investments. Finally, role modeling for framework design is the first comprehensive modeling method to make frameworks explicit design artifacts.

Copyright (©) 2007 Dirk Riehle. Some rights reserved. (Creative Commons License BY-NC-SA.) Original Web Location: