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