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
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
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
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
- 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
- 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
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
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
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
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
- 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
- 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
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
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
- "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".