Chapter 1: Introduction

Frameworks are of key importance for developing large-scale object-oriented software systems. They promise higher productivity and shorter time-to-market through design and code reuse. However, many projects report that this promise is hard to fulfill: the design of object-oriented frameworks is all but well understood. This introductory chapter sheds some light on why this is so, and presents several key problems. It thereby poses the research questions that have driven the work presented in this dissertation, and gives an overview of how and where these questions are answered in this work.

1.1 Why object-oriented frameworks?

Object-oriented frameworks promise higher productivity and shorter time-to-market of application development through design and code reuse (than possible with non-framework based approaches).

Object orientation comprises object-oriented analysis, object-oriented design, and object-oriented programming. Using a small set of concepts (objects, classes, and their relationships), developers can model an application domain (analysis), define a software architecture to represent that model on a computer (design), and implement the architecture to let a computer execute the model.

None of these activities (analysis, design, and implementation), nor the resulting models, are trivial. To carry them out effectively, developers have invented additional concepts that represent the conceptual entities they are dealing with. One such key concept is the object-oriented framework.

An object-oriented framework is a reusable design together with an implementation [JF88, CIM92, Lew95, FS97, FSJ99]. The design represents a model of an application domain or a pertinent aspect thereof, and the implementation defines how this model can be executed, at least partially. A good framework's design and implementation is the result of a deep understanding of the application domain, usually gained by developing several applications for that domain. The framework represents the cumulated experience of how the software architecture and its implementation for most applications in the domain should look like. It leaves enough room for customization to solve a particular problem in the application domain.

Developers who apply a framework reuse its design and implementation. They do so to solve an application problem that falls into the domain modeled by the framework. By reusing the design, application developers customize a (hopefully) well-understood software architecture to their own specific application problem. This helps them get the key aspects of the architecture right from the beginning. By reusing the implementation, application developers get up to speed more quickly.

Through design and code reuse, frameworks help developers achieve higher productivity and shorter time-to-market in application development.

Designing and implementing object-oriented frameworks is hard. Typically, it requires several iterations to get a framework "right" (which might mean nothing more than that it gets a pause before the evolution of domain requirements leads to yet another redesign and re-implementation of the framework).

In contrast to non-framework based application development, a framework requires additional up-front investments. If a framework is bought, it requires money to buy it and time to learn it. If a framework is developed in-house, it requires time and resources, both to develop it, and later to teach it or to learn it.

However, the promise of a significant increase in productivity and reduction in time-to-market makes the investment worthwhile in most cases. Today, every large object-oriented development project I know of uses frameworks in one way or the other. Yet, while there is no way around frameworks in large-scale object-oriented software development, they are all but well understood and sometimes do not live up to their promises.

1.2 Problems with frameworks

What is wrong with object-oriented software development based on frameworks? No single answer can be given. Most projects that fail do so for a multitude of reasons, with poor design and implementation quality of frameworks being only one of them. Yet, frameworks can significantly contribute to project success and ensure flexibility and evolvability of applications. It is therefore worthwhile to investigate current problems in framework development and search for solutions.

Case studies [FK97], current practice [BBE95], as well as my own experiences with frameworks in whose development I have participated, which I have used, or which I have reviewed suggest the following key problems (these are elaborated in Chapter 2):

• Class complexity. Classes define the behavior of objects, their instances. Objects collaborate in multiple contexts, for multiple purposes, exhibiting task-specific behavior. For complex objects, the definition of this behavior in a single flat class interface is inadequate, and better mechanisms that describe the different aspects of objects, are needed.
• Complementary focus on classes and collaborations. Objects collaborate with each other, for different purposes. Much of the complexity of frameworks goes into designing and implementing the object collaboration behavior. By assigning responsibilities to individual objects, the focus on overall collaborative behavior is lost. Thus, mechanisms to describe collaboration behavior are needed.
• Object collaboration complexity. The overall collaborative behavior of framework objects and their collaboration with client objects may become complex. To make the overall object collaboration easier to understand and to manage, it needs to be broken up into independent pieces. Means to describe task-specific collaborative behavior of objects are needed, as well as mechanisms to compose these pieces of collaborative behavior to define the full object collaboration.
• Difficulties with using a framework. It is easy to use a framework in ways unforeseen and not intended by their original designers. In particular, the requirements that a framework puts upon its clients are frequently unclear and unspecified. Framework misuse causes constant work-arounds for the client and may easily lead to unstable and buggy code. Thus, mechanisms are needed that help prevent the (mis-)use of frameworks in ways not intended by the framework developers.

These are the problems addressed in this dissertation. Of course, these problems are only a subset of technical problems with frameworks. Yet, they are a particularly pertinent kind of problems.

These problems suggest a separation of concerns approach: because complexity is high, it needs to reduced. Reduction of complexity is achieved by breaking up the framework up into (re-)composable pieces. Each of the pieces can then be analyzed, designed, and understood individually.

1.3 Role modeling for framework design

Role-based object-oriented modeling (or, for short, role modeling), is such a separation of concerns approach. This dissertation presents an approach for designing object-oriented frameworks using role modeling. The basic role modeling concepts are role, role type, object collaboration task, and role model. The next paragraphs, summarized from Chapter 3, shortly explain the concepts.

Objects do not occur in a vacuum. Rather, each object collaborates with other objects: it does so by playing roles. A role is an observable behavioral aspect of an object. While playing roles, an object collaborates with other objects, usually for several different purposes at once. Each such well-defined purpose of object collaboration is an object collaboration task. The composition of all object collaboration tasks becomes the overall object collaboration.

A role type describes each role an object may play. A role type is a regular type specification. Each object collaboration task is described by a role model. A role model uses role types to describe how an object in an object collaboration task must behave (play a role) if it wants to properly carry out its part of the work. The role types of a role model relate to each other using regular object relationship descriptions. The role model is effectively a specification of the set of possible valid object collaboration tasks.

A class defines the behavior of objects, their instances. A class is the composition of several role types, each of which is taken from a role model and assigned to one or more classes. The composition of role types forms the class type. Classes and role models are complementary: a role model focuses on one particular task of object collaboration, ignoring others, and a class focuses on how roles played in different tasks come together in one kind of object.

A class model describes the overall collaboration of objects. A class model is a set of classes that are related with each other through role models and class inheritance. The object relationship descriptions between the classes can be derived from the relationship descriptions between the role types from the role models. This way, role models serve as the interconnecting glue between classes, not only showing the overall structure, but the individual object collaboration tasks that make up the class model. Effectively, with the help of classes, the class model composes the different role models to define what a valid overall object collaboration is.

This dissertation extends the basic modeling approach to support the design of frameworks, leading to the role modeling for framework design approach. The next paragraphs, summarized from Chapter 4, shortly explain the involved concepts.

A framework is a class model that defines the collaboration of (framework) objects (and their client objects with respect to the framework). Next to the framework-internal role models, a framework defines so-called free role models that provide a bridge between the framework client and the framework. Free role types are those role types of a free role model that are to be picked up by client classes. They specify how client objects of the framework must behave to make proper use of framework objects. Only by playing roles defined by free role types may client objects make use of a framework.

Frameworks build on other frameworks by picking up these other frameworks' free role types and assigning them to one or more of their own classes. This mechanism of making use of frameworks by free role models is applied recursively to view systems as layers of frameworks and framework extension stacked on top of each other. Framework extensions are a set of subclasses of framework classes that add new free role models. Through the use of free role models new clients may make use of the extended framework functionality as well.

How does this approach help in overcoming the problems stated above?

• Class complexity. The complexity of a class is reduced by breaking its interface up into distinct role types. Experience shows that it is easier to understand the parts first and then to compose them rather than trying to understand the whole all at once.
• Complementary focus on classes and collaborations. The explicit focus on object collaborations and class models rather than just class hierarchies ensures that both perspectives are taken into account and represented in the design of a framework.
• Object collaboration complexity. The complexity of the overall collaborative behavior of framework objects is reduced by breaking it up into object collaboration tasks and describing it as the composition of role models. Again, understanding the parts first makes understanding the whole easier.
• Difficulties using a framework. The concept of free role model lets developers specify succinctly how a framework is to be used by use-relationship based clients. Free role models help to prevent misuse that would otherwise occur easily if the requirements put upon clients are not clarified.

Role modeling for framework design is evolutionary in nature rather the revolutionary. It is used as an addition to traditional class-based modeling. Role modeling does not try to replace class-based modeling but rather to refine it and improve over it where necessary. Developers who use this approach do not have to throw away existing investments, but may selectively apply the approach where necessary.

1.4 Dissertation overview

The dissertation comprises three main parts. The first part describes the role modeling approach and how it is applied to framework design. The second part presents three case studies, each one focussed on evaluating different aspects of the approach. The third and final part reiterates the claims posed by the dissertation, and validates them using qualitative arguments and experiences gained from the case studies.

The first part on role modeling for framework design comprises Chapters 2 to 5.

• Frameworks, related work, and dissertation thesis. Chapter 2 puts object-oriented frameworks into the context of software architecture. It reviews related work on object-oriented software architecture and frameworks and lists remaining problems. Based on these problems, it develops the dissertation thesis.
• Role modeling. Chapter 3 introduces the role modeling foundations, on which Chapter 4 on framework design builds. Chapter 3 shows how the traditional class-based modeling approach can be extended with the concepts of role type and role model, and how existing concepts need to be revised.
• Framework design. Chapter 4 builds on the role modeling foundation from Chapter 3. It develops a comprehensive definition of the concept of framework and discusses its context. It covers framework definition, framework use, and framework extension. It also discusses framework layering and documentation.
• Extension of industry standards with role modeling concepts. Chapter 5 shows how current industry standards can be extended with role modeling concepts. Such an extension lets developers use role modeling with current standards. The chapter provides extensions of UML, Java, C++, and Smalltalk.

The second part presents the case studies. It comprises Chapters 6 to 8.

• The Geo Object framework. Chapter 6 presents the Geo Object framework as a case study. This framework is the root framework of the Geo system, a distributed object system based on a metalevel architecture. The Object framework provides core abstractions like Object and Class common to many industrial systems.
• The KMU Desktop Tools framework. Chapter 7 presents the KMU Desktop Tools framework as a case study. The framework is used to build software tools for desktop applications. It is based on the Tools and Materials Metaphor approach to software development.
• The JHotDraw drawing editor framework. Chapter 8 presents the JHotDraw framework for drawing editors as a case study. JHotDraw is based on HotDraw, which is a widely known and mature framework used to build drawing editor applications.

The third part validates the claim and draws conclusions from the dissertation. It comprises Chapters 9 and 10.

• Validation of dissertation thesis. Chapter 9 reviews the experiences made in the case studies, supports them with qualitative arguments, and validates the dissertation thesis.
• Conclusions. Chapter 10 reviews the dissertation as a whole. It explains the consequences of the dissertation results, both from a narrow perspective (the thesis claim), and a wider perspective.

Finally, Appendices A to E provide additional material.

• References. Appendix A lists the references of work referred to by the dissertation.
• Glossary. Appendix B provides a glossary of key terms defined by the dissertation.
• Notation guide. Appendix C provides a notation guide to role modeling for framework design.
• Design patterns. Appendix D presents common design patterns cast in a role model form.
• Further material. Appendix E provides pointers to further material.

For comprehensive understanding, the theory chapters must be read first. Then individual case studies may be read, followed by the validation of the dissertation thesis. Those who want to get an impression only may restrict their reading to Chapter 3 and 4 and to one or more case studies. Alternatively, they may directly jump into a case study, using Appendix C, the notation guide, as a minimal introduction to role modeling for framework design.

1.5 Actors in this dissertation

For properly identifying actors in this dissertation, I use the following conventions:

• "we" identifies the reader and the author (you and me),
• "the project team" identifies the team described in Chapter 6,
• "the redesign team" identifies the team described in Chapter 7.

"The project team" and "the redesign team" are only used in their respective chapter. They are sometimes abbreviated as "the team".