|
Object-oriented frameworks are cohesive design and implementation
artifacts. Frameworks typically serve to implement (larger-scale)
components, and are implemented using (smaller-scale) classes.
This chapter describes the framework concept and its purpose in
the context of object-oriented software architecture. Then the
chapter identifies a set of key problems with object-oriented
frameworks, and discusses to which extent related work addresses
these problems. Finally, the thesis of this dissertation is defined
and explained.
2.1 Overview of framework concepts
This section first puts frameworks into the context of object-oriented
software architecture, then reviews common and established terminology,
and finally provides a list of key problems that haunt today's
application development based on frameworks.
2.1.1 Object-oriented software architecture
Object-oriented software architecture is based on objects and
classes as the primitive building blocks. Current practice distinguishes
three levels of system granularity: the class level, the framework
level, and the component level. (Sometimes a fourth component
framework level is added, but it is ignored here, because it does
not add anything important to the discussion of object-oriented
frameworks.)
On the smallest level of granularity, a system can be designed
using classes, whose instances collaborate with each other. A
class defines a well-defined and bounded chunk of behavior and
state, based on a domain concept that it represents. Objects are
instances of classes, and thereby represent instances of a domain
concept.
For small systems, objects and classes are sufficient means
for describing the architecture of a system. However, when a system
gets bigger, more and more classes get involved in its architecture,
and higher-level abstractions are needed that let developers design
and implement systems.
Systems of medium size can be described as a set of collaborating
frameworks and framework extensions. A framework is a cohesive
design and implementation artifact [JF88, CIM92, Lew95, FS97,
FSJ99]. It represents a specific domain or an important aspect
thereof as a reusable design of abstract classes (or interfaces)
and concrete classes, together with a set of implementations.
Good implementations are reusable, and may or may not be readily
instantiable.
A good framework has well-defined boundaries, along which it
interacts with clients, and an implementation that is hidden from
the outside. Frameworks and framework extensions are a key part
of medium to large-scale software development [BCG95, BGK+97],
but even they have an upper limit of coping with complexity.
On a large-scale level of granularity, a system can be described
as a set of collaborating components, each of which may have been
built from one or more object frameworks [WSP+92, Szy98]. A component
is a well-defined technical artifact with interfaces to other
components. It may or may not have been implemented using object-oriented
frameworks-in case of an object-oriented system it typically is.
There are many more software architecture related issues like
process architecture, code bundling, and build systems. However,
they do not add to the discussion and are therefore omitted from
it.
2.1.2 Review of framework terminology
Frameworks model a specific domain or an important aspect thereof.
They represent the domain as an abstract design, consisting of
abstract classes (or interfaces). The abstract design is more
than a set of classes, because it defines how instances of the
classes are allowed to collaborate with each other at runtime.
Effectively, it acts as a skeleton, or a scaffolding, that determines
how framework objects relate to each other.
A framework comes with reusable implementations in the form
of abstract and concrete class implementations. Abstract implementations
are abstract classes that implement parts of a framework abstraction
(as expressed by an abstract class or interface), but leave crucial
implementation decisions to subclasses. They do so using the principle
of Design by Primitives. Design by Primitives bases a class implementation
on a small set of primitive operations that are left open for
implementation through subclasses. Concrete subclasses implement
these operations so that they can be instantiated and used without
further subclassing. A detailed discussion of the use of interfaces,
abstract classes, and concrete classes in object-oriented design
is presented in [RD99a, RD99b] (for German readers: [Rie97d, Rie97e]).
When designing an application, a developer may choose to use
an existing framework, because it models parts of the application
domain well. There are two primary ways of using a framework:
either by use-relationships or by inheritance. Consequently, there
are two kinds of clients: use-relationship based clients and inheritance-based
clients (use-clients and extension clients).
A use-client object instantiates one or more framework classes
and uses the objects for its purposes. A framework, whose classes
can be readily instantiated, and which can be used as-is, is called
a black-box framework [JF88]. An extension client class subclasses
framework classes according to its needs. It thereby customizes
the general domain model represented by the framework to its specific
application needs. The new subclasses are used by use-clients
of the specific application. A framework that can be extended
using subclassing is called a white-box framework [JF88]. Most
real-world frameworks combine black-box with white-box issues
and are therefore called gray-box frameworks.
Typically, applications use not only one framework, but several.
An application may tie together a framework for handling user-interfaces,
another framework for the banking domain, and yet another framework
for handling persistence and database access.
An application framework is a framework that ties together
a set of existing frameworks to cover most aspects of a certain
type of application. Strictly speaking, an application framework
is just another framework of a similar size as the frameworks
it uses. Most developers, however, when speaking of an application
framework, refer to all involved frameworks, the primary application
framework as well as all the other frameworks it is based on (an
application framework thereby may be viewed as something like
a composite framework).
In software development based on application frameworks, applications
(or systems) become extensions of the application framework. They
reuse the software architecture of this particular type of application
as defined by the application framework and its domain frameworks.
There are a number of key advantages to be gained from using
application frameworks. The primary technical advantage is that
they provide design and code reuse. The larger and better an application
framework, the more design and code reuse becomes possible. Also,
systems based on frameworks are easier to maintain, because most
key design and implementation decisions are localized in one place,
the framework.
The primary business advantages of design and code reuse are
higher developer productivity and shorter time-to-market of new
applications. In addition, applications tend to be less buggy
(they are reusing mature implementations), and tend to look more
homogenous (a suite of applications built from the same framework
has the same architecture and similar implementations).
2.1.3 Problems with frameworks
Software development in general, and object-oriented framework-based
application development in particular, is a non-trivial undertaking
that comes with many problems. These include technical issues,
social and communication issues, project management issues, and
developer organization issues.
This dissertation focuses on technical problems of design complexity.
Fortunately, the problems presented here can be addressed largely
independently of social, managerial, and organizational problems
as they emerge in real-world software development.
Based on four large case studies, Fichman and Kemerer note
that a key challenge of adopting object technology is the steep
learning curve it takes until developers can get to work productively
[FK97]. Bischofberger, Birrer, and Eggenschwiler note that beyond
basic object-oriented software development, object-oriented frameworks
require an even higher up-front learning investment [BBE95]. In
terms of resources, it takes time and good developers until a
project or an organization can start using a framework successfully.
Frameworks have a steep learning curve, because developers not
only have to understand single isolated classes, but abstract
designs of several classes whose instances collaborate for many
different purposes.
What makes up this increased complexity of using object-oriented
frameworks over the basic object paradigm? The case studies cited
above, current practice, and my own observations point to the
following problems:
- 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.
The first three list items are problems with understanding
and learning an existing framework. All four bullet list items
are also problems with using a framework, as understanding it
precedes using it.
These problems are a result of the complexity of designing
and implementing a framework in the first place. They arise in
the initial (and continued) development of a framework. Developers
do not have (yet) adequate means to tackle these problems in the
design and implementation process.
Any framework that is being used in real-world projects continuously
evolves, because its underlying domain keeps changing [Bäu98].
The design is in constant danger to deteriorate, and the implementation
is in constant danger to get convoluted. After a few evolutionary
steps, redesign and re-implementation of the framework become
a necessity. In our fast-paced time this must be carried out as
effectively as possible.
The thesis of this dissertation is that the listed problems
of designing and understanding frameworks can be eased significantly
through the use of a role modeling approach to framework design.
Role modeling for framework design is an addition of the traditional
class-based modeling approach. Before the thesis is laid out in
more detail, however, the next section reviews related work and
how it addresses the presented problems.
2.2 Related work
Related work can be characterized along three dimensions: work
on object-oriented design and frameworks, work on modeling languages
and methods for (possibly persistent) object-oriented systems,
and work on separation of concerns techniques for object-oriented
design and programming.
2.2.1 Object-oriented design
Objects interact in several different contexts at once. An
early understanding of this observation can be traced back to
Smalltalk that provides developers with method categories to group
methods into [GR89] and Objective-C that lets developers specify
different protocols of objects [Cox87]. In Smalltalk, each method
category can be devoted to one particular aspect of the class,
and it can be viewed independently of the other aspects. However,
Smalltalk provides a few standardized method categories, most
notably "Accessing", which suggest that method categories
are more a convenience function than a means of class design.
Programming languages like C++ and Java make it possible for
classes to have different interfaces through the use of multiple
inheritance [Str94, AG96]. The presence of interfaces and multiple
inheritance explicitly acknowledges the need to view objects from
different perspectives. Also, industry component models like COM
or CORBA [Box98, Sie96] and academic component models like those
of Wright, Darwin, and Rapide [All97, MDEK95, LKA+95] all allow
components to have multiple interfaces.
Also, it is now widely understood that object collaboration
is a major design issue and should be explicitly focused on. The
idea of object collaborations goes back to Beck and Cunningham
[BC89] and Wirfs-Brock et al. [WWW90]. However, the seminal paper
is [HGG90], which introduces the concept of contract as a formal
description of object collaboration behavior. A contract abstracts
from individual objects and focuses on the collaborative behavior
of objects. Contracts can be extended and refined, using a specialization
mechanism.
2.2.2 Programming methods
For a few years now, researchers have been working on new techniques
for making object systems more readily composable from pieces
than possible before. The understanding that objects and classes
need better code composition mechanisms than use and inheritance
relationships is driving most of this research.
In his work on the Demeter method, Lieberherr criticizes the
tendency of classes to hard-code their relationships [LH89, Lie95].
Class structures are hard to change if these structures are embedded
in the class implementations. He therefore suggests to abstract
from concrete class structures and to define constraints on class
structures only. These constraints do not describe a specific
class structure but rather a family of class structures that all
fulfill the constraints. Object-oriented programs are generated
from these constraints and from a set of propagation patterns.
A propagation pattern describes how to carry out a specific task
in terms of traversing object structures and calculating results.
The full program is generated by a tool that takes the class structure
constraints and propagation patterns, derives a class structure,
and assigns implementations to classes that reflect both the tasks
defined by the propagation patterns and the chosen class structure.
In their work on subject-oriented programming, Harrison and
Ossher also point out that an object may be viewed from many different
angles [HO93, OKH+95]. Starting with this observation, they derive
a method that lets developers compose new applications from existing
applications, where each application may have an arbitrarily complex
class model. They introduce composition operations for classes
and methods, and provide developers with tools to specify how
to compose different applications. This approach distinguishes
itself from the other approaches in that it uses the traditional
concepts of classes and methods as its basic building blocks,
and can be applied to existing applications.
In his work on the DASCO method, Rito-Silva describes techniques
for the development of concurrent distributed systems [Rit97].
He views applications as the result of a composition of different
frameworks, where each framework addresses one particular technical
aspect of a system (for example, a particular type of object synchronization
or concurrency control). Composing classes from these frameworks
using multiple inheritance defines the final application, in which
all different aspects come together.
In their work on aspect-oriented programming, Kiczales et al.
address the problem of "tangled code", a manifestation
of the feature interaction problem [KLM+97, Lop97]. Tangled code
is the phenomenon that in many class implementations different
technical issues come together. The implementation of a single
operation of a class might have to address issues of synchronization
and concurrency, logging and security, and others, before focusing
on the primary domain task of the operation. Kiczales et al. suggest
that it is desirable to describe each of these aspects in a programming
language of its own, rather than using a generic common language.
A dedicated tool, the Aspect Weaver, composes these different
programs for the different technical aspects, and generates a
single resulting program. Introducing dedicated programming languages
lets developers define programs dedicated to one particular technical
aspect. The approach thereby lets developers separate concerns
and "untangle" class implementations. The approach promises
higher flexibility and simpler maintainability and evolution.
In their work on role-oriented programming, VanHilst and Notkin
view object-oriented designs as compositions of object collaboration
descriptions [Van97, VN96]. They describe object collaborations
as a set of roles, which objects in the collaboration play. They
provide means to compose these object collaborations. Their composition
mechanism are parameterized types (templates in C++), for which
they provide elaborate handling guidelines.
In the context of database programming, Albano et al. describe
how to implement data models with roles [ABGO93]. Their database
programming language Fibonacci lets developers describe data models
in terms of roles objects play. Objects are fully hidden behind
roles and programmers never get to see an object except through
a mediating role. Roles are described by role types, which are
organized in type hierarchies. For these type hierarchies, the
usual subtyping mechanisms apply.
Database programming languages focus more on data structures
and object-lifecycles than behavior specification. Hence, Fibonacci
is strong in the area of dynamically acquiring and loosing roles,
as may happen during the lifetime of an object. This is helpful
for easing schema evolution, one of the hard problems of database
design and programming. However, this is not a topic of this dissertation.
2.2.3 Development methods
OOram is a full-fledged software development method that covers
all relevant activities of the development process [Ree96, RAB+92].
It was developed by Trygve Reenskaug et al. and has been in use
for many years. OOram is of particular importance to this dissertation,
because it served as one of its sources of inspiration.
OOram takes a different approach to modeling than traditional
class based modeling. It focuses on object collaborations, which
it describes using role models. Objects in a collaboration play
a role, which is described using a type. Classes are irrelevant
on this modeling level; they serve as implementation concepts
only.
A role model describes just one particular object collaboration
purpose, and is therefore composed with other role models to fully
determine object behavior and hence class implementations. The
composition is called role model synthesis, and is supported by
dedicated tools. A full object-oriented system emerges as the
composition of many role models. There is no intermediate concept
(like the framework concept), but only role models of growing
complexity.
Andersen's dissertation follows up on OOram [And97]. He rehabilitates
the concept of class, which he defines to model the information
content of objects by abstracting from individual objects. Andersen
also emphasizes that role models are instance-level models that
do not abstract from individual objects but are always bound to
specific objects. In contrast to this view, this dissertation
views role models as a specification of object collaboration tasks
that may fit a possibly infinite set of object collaborations
at runtime.
Finally, Andersen's work provides a formal foundation for the
role model synthesis process of OOram. This formal foundation
is of particular importance for this dissertation, because the
dissertation does not present a new type specification mechanism
but rather relies on existing ones. Anderson's mechanism is one
possible specification mechanism that can be used to formally
specify role models as used in this dissertation.
UML is currently becoming the dominating modeling language
in the object-oriented world [UML97a, UML 97b]. In UML, relationships
between classes can be defined that are tagged at each end with
a so-called role name, a simple string that indicates the role
an instance of the other class in the relationship may play. It
is possible to add additional specification using general UML
mechanisms, but no specific role modeling support is provided.
Next to basic role support on relationships between classes,
UML also provides the concept of Collaboration that lets developers
describe how objects are to collaborate for a specific task. The
authors of UML write that Collaborations serve to represent different
things, including use-cases and OOram role models. Collaborations
let developers specify structure, but not behavior. Its expressive
power is largely equivalent to basic OOram role models. However,
it is lacking more advanced features like role model synthesis
(composition of collaborations). This is where method extensions
come into play.
Catalysis is a recent software development method for component-based
software development with UML. It is being developed by D'Souza
and Wills [DW98]. It is based on UML and tries to leverage its
modeling capabilities as far as possible. Therefore, it does not
introduce new concepts like role and role model, but rather uses
the concepts of interface and class diagram.
However, D'Souza and Wills use class diagrams and interfaces
much like Reenskaug uses role models and roles, except that they
do not view their role-model-alike class diagrams as instance-level
models, but rather as type-level models. They use multiple inheritance
as the composition mechanism for interfaces. They support interface
specification and composition through lightweight formal modeling
based on pre-/postconditions and invariants.
However, much like OOram, Catalysis does not introduce an explicit
framework concept as used in this dissertation. Rather, they scale
up using UML concepts only, which does not provide a dedicated
framework concept. Catalysis uses the term framework, but it refers
to a single class diagram dedicated to one particular purpose,
much like a role model.
Object Role Modeling (ORM, [Hal96]) is a data modeling technique
that extends ER modeling with role modeling concepts. Similarly
to UML, it lets developers tag the end of associations with role
names, thereby letting them indicate what the purpose of an entity
type at an association end is. As explained by Halpin in [Hal98],
the differences between ORM and UML are on a fine-grained level,
for example in the details of how to attach meaning to roles.
However, unlike UML, ORM provides no means to specify behavior,
as possible with UML collaborations. Like most data structure
oriented modeling techniques, ORM falls short when it comes to
specifying collaborative behavior in object-oriented design.
2.2.4 Role modeling concepts
Some related work adds directly to the role concept as a key
modeling concept without trying to develop a full-fledged design
or programming method. Depending on the researchers' background,
such related work has a specific focus like conceptual modeling,
runtime configuration, or database design.
Kristensen and Osterbye introduce the role concept to the Scandinavian
tradition of conceptual modeling and programming [KO96a]. The
role meta-concept is viewed as a specialization of the more general
concept meta-concept. Operations that are applicable to the concept
meta-concept therefore become applicable to the role meta-concept,
for example, classification, aggregation, and specialization.
The definition of a role is the result of an abstraction process
from similar domain phenomena (which are not necessarily domain
objects). Roles can be aggregated to form aggregate roles, and
they can be specialized to form new derived roles. In Kristensen's
and Osterbye's terminology, role instances are attached to objects.
While objects provide intrinsic properties, roles attach extrinsic
properties to objects. Properties are both operations and attributes.
Kristensen and Osterbye call the resulting concept instance conglomerate
(object + attached roles) a subject.
Gottlob et al. [GSR96] discuss a role concept for better supporting
the life-cycle of objects in object-oriented databases. Long-lived
objects, in particular those stored in a database, may have a
complex life-cycle. Gottlob et al. describe the lifecycle of an
object as a succession of roles the object may take on. At any
one time, an object is an instance of exactly one class, but it
may take on several roles. Roles are modeled in role hierarchies,
which are type hierarchies. An object that is in the particular
state of playing a certain role acts according to the role's type
definition in the role hierarchy. Gottlob et al. provide a Smalltalk
implementation that lets an object dynamically acquire and drop
roles, even if they are of the same role type. The Smalltalk implementation
keeps the different roles synchronized.
Wieringa et al. also use roles for modeling object life-cycles
[WJS95]. Their conceptual modeling approach is similar to Gottlob
et al.'s and comprises role class hierarchies and dynamic role
playing. However, where Gottlob et al. provide a Smalltalk implementation
of roles, Wieringa et al. provide a formal specification of the
metamodel behind roles and classes using order-sorted logic.
Also closely related to Gottlob et al.'s approach is the concept
of role objects, as discussed by Bäumer et al. [BRSW00].
A role object is an object that extends a core object for use
in a specific context. The core object provides all functionality
that is independent of a specific context, and a role object provides
all functionality that is needed in one specific context. A core
object may provide many different role objects so that it can
operate in many different contexts in parallel. Of particular
importance to this dissertation is that role objects may be used
to integrate frameworks. One framework may define a core concept
like Person, and further frameworks may define role objects that
extend the core concept for their particular use [BGK+97, RG98].
Then, role objects serve as a dynamic bridge between frameworks.
They are used to adapt a framework to unforeseen requirements.
The focus of the related work presented in this subsection
is on the individual object and its roles. None of the work addresses
the collaborative behavior of objects through its roles, and none
of the work applies it to the level of framework design.
2.2.5 Object-oriented frameworks
The seminal paper on framework concepts is [JF88], where Johnson
and Foote pick up the framework concept and discuss many of its
properties. They introduce the concepts of white-box and black-box
frameworks. They distinguish between classes, types, and protocols.
The protocol of an object is the set of methods (operations) that
it understands. They use protocol as a synonym for type and argue
that it is to be treated differently from a class. A class implements
a particular protocol, which points to recent considerations of
classes as implementation concepts only (rather than modeling
concepts, as defined by their original SIMULA-67 inventors [DH72]).
Frameworks were soon recognized as a means for achieving large-scale
reuse. The Taligent frameworks are a notable effort for building
systems based on frameworks. This effort is also well published,
even though commercially it failed in the end. In a series of
books [CP95, Tal95], Taligent tried to introduce framework concepts
and a lightweight terminology into the marketplace. They introduce
the concept of ensemble to mean the set of application-specific
subclasses of frameworks that make up an application. An ensemble
draws on several frameworks at once. Furthermore, as already suggested
by Johnson and Foote through the introduction of white-box and
black-box frameworks, they make a clear distinction between the
different interfaces clients may use of a framework, which they
call composition-focused and inheritance focused, respectively.
Frameworks are usually used in the larger context of object-oriented
software architecture. Because frameworks are always focused on
a particular domain, they establish domain-specific software architectures
(DSSA's). Bäumer describes an example of such a DSSA for
interactive desktop applications [Bäu98, BGK+97]. He discusses
a U-form layering structure of application systems, with applications
on top of business section frameworks on top of business domain
frameworks, on top of desktop/technology frameworks, on top of
foundation frameworks. The layering structure takes on a U-form,
because layering is not strict, and any higher-layer framework
makes use of the desktop/technology and the foundation framework
layers. These two base layers form the containing borders of the
jar-like U-Form. Therefore, this DSSA employs non-strict layering,
a common property of object-oriented systems.
Of particular interest is Bäumer's adaptation of the connector
concept from software architecture [SG96] to object-oriented frameworks.
He shows that frameworks are frequently connected using (instantiations
of) design patterns as connecting elements. The results of this
dissertation support the importance of this observation, and provide
a more thorough basis for its discussion in the form of role models.
Role models may be design pattern instantiations (but need not!),
and one of their purposes is to connect frameworks with clients
or other frameworks.
Further reports on successfully using object-oriented frameworks
support the reuse claim [BCG95, SBF96]. [Lew95] is a first compendium
of concrete examples of frameworks from all kinds of domains.
Another forthcoming book by Fayad, Schmidt, and Johnson provides
even more study material [FSJ99].
2.2.6 Review of related work
The recent interest in separation of concerns approaches suggests
that today's design and implementation techniques need further
improvement. The work presented in this dissertation is based
on role modeling, which is one of the separation of concerns approaches.
None of the related work, be it on individual design concepts
or full design methods, on general programming or database programming,
or on frameworks or databases, utilizes role modeling for framework
design. However, this is the core them of this dissertation.
2.3 Thesis statement of dissertation
This subsection explains and refines the dissertation thesis.
The initial thesis statement is:
- Thesis statement (initial version)
- Role modeling for framework design makes the design and documentation
of object-oriented frameworks easier than is possible with traditional
class-based approaches.
Analysis of the initial thesis statement leads to three questions
that need further discussion:
- What is the scope of "design and documentation"?
- What does "easier" mean? Can it be made more specific?
- Who is the subject that benefits from an increased ease of
use?
The next subsections examine each question in turn.
2.3.1 What is the scope of "design and documentation"?
First, we need to distinguish between the different activities
and the tangible and intangible artifacts of framework-based application
development. Figure 2-1 shows a diagram of these activities and
artifacts. This diagram has been developed to explain the thesis
and serves illustration purposes only. It is not a complete description
of development activities, dependencies, and artifacts.
In Figure 2-1, tangible and intangible artifacts are shown
in large fonts, and activities relating artifacts are shown in
small font.
- Figure 2-1: Activities and artifacts during framework design
and application.
The diagram shows four artifacts: application domain, application
system, framework design, and framework documentation. It shows
the distinction between artifacts and activities well. For example,
framework design is an artifact, while designing is an activity.
Of the artifacts, only documentation is fully tangible. The application
domain, the application system, and the framework design artifacts
are partially or fully abstract.
It is important to distinguish between a framework's design
and its documentation. The framework design comprises all the
ideas and concepts involved in a framework. The framework documentation
makes them explicit as far as possible, but is never able to fully
reveal them. Rather, the documentation describes those aspects
of the design that are most important for developers to know who
try to understand the framework.
The artifacts are related by activities. Designing a system
in an application domain leads to a design. Documenting the design
leads to documentation. Reading documentation and working with
a framework leads to understanding the framework design. Applying
the framework leads to an application. Etc.
Role modeling for framework design is a method that supports
human activities. It is also reflected in the artifacts, for example
in the documentation, but its primary purpose is to support humans
in carrying out activities based on these artifacts. Therefore,
the degree to which role modeling helps with these activities
is the primary measure of its utility.
The diagram shows five activities: designing, redesigning,
applying/using, documenting, and understanding.
Let us assume that someone versed in role modeling for framework
design carries out these activities. Also, let us assume that
role modeling has already been used for the existing frameworks
and their documentation. Then, any redesign activity becomes a
design activity that takes both the application domain and an
existing design into account. Because the existing framework design
is already a result of designing for the application domain, no
qualitative difference exists, and redesign can safely be subsumed
under design.
Moreover, documenting a framework using role modeling is an
activity by which developers select certain aspects of a framework
and document them using whatever scheme seems appropriate, here
role modeling. The decision of which aspect is considered important
is independent of the deployed technique. Therefore, the documentation
activity is largely independent of the role modeling approach.
This discussion leaves us with designing, applying/using, and
understanding object-oriented frameworks. The refined thesis statement
now becomes:
- Thesis statement (first intermediate version)
- Role modeling for framework design makes the following activities
easier to carry out 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.
What about frameworks that have not been designed and documented
with role modeling in mind? Can role modeling help here as well?
As I have demonstrated, role modeling can be used as an analytical
means to reengineer existing designs [Rie97]. Naturally then,
the new design can be expressed well using role modeling.
However, such a reengineering activity is also an example of
the more general design activity for object-oriented frameworks.
Here, the application domain is the underlying domain of the existing
framework, and the reengineering activity becomes a design activity
for the application domain taking the purpose and structure of
the existing framework into account. Therefore, reengineering
is also subsumed under design.
2.3.2 What does "easier" mean?
"Easier" is used in the sense of "more effective"
in handling the problems of framework-based application development
as discussed earlier in Section 2.1.3.
The refined thesis statement of the dissertation now becomes:
- Thesis statement (second intermediate version)
- Role modeling for framework design makes the following activities
easier to carry out 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.
What remains to be done is to define an evaluation strategy
that lets us compare the effectiveness of the traditional class-based
approach with role modeling for framework design as presented
in this dissertation.
The phrase "[problem] severity is reduced" does not
lay claim to a quantitative measure. In principle, showing only
a tiny improvement over the existing situation would validate
the dissertation thesis. While a correct solution, this is certainly
not a satisfying solution. However, no quantitative measure or
metric is used to validate the claims; rather, the dissertation
uses a case study based approach.
If the dissertation were to measure the improvement in ease
of use, it would have to introduce a metric that measures the
reduction in complexity as experienced by a user. In principle,
this means setting up and conducting a psychological experiment
for framework design and use tasks of non-trivial complexity.
Such an experiment is beyond the scope of this dissertation and
can only be carried out by trained psychologists.
A less aggressive alternative would be to define quantitative
metrics of complexity in framework design. Such metrics could
then be calculated for a traditional framework design and for
a framework design based on role modeling. A "better"
resulting metric value can then be interpreted as a validation
of the dissertation thesis. The problem of this approach is that
it is difficult to show that a metric adequately reflects the
design complexity as perceived by a human. Again, psychological
experiments would be needed to show this.
As a consequence, I resort to using a qualitative approach
based on case studies to validate the dissertation thesis. Chapters
6 to 8 present several case studies and Chapter 9 evaluates the
thesis based on experiences made in the case studies.
2.3.3 Who is the subject?
Role modeling for framework design makes life easier for expert
framework developers and users. It is tempting to conclude that
role modeling helps novices and experts alike. However, I have
no hard evidence that role modeling works for novices to the same
extent that it does work for experts. Role modeling for framework
design is a more comprehensive method than traditional class based
modeling. It requires experience with framework design and use.
If this experience is not given, role modeling for framework design
may be too demanding a method for some developers.
Therefore, the thesis statement of the dissertation only claims
that the presented approach helps expert developers that already
understand class-based modeling and framework design well. This
is well in line with the understanding that the presented approach
is an extension of the existing class-based modeling approach,
rather than a replacement. One needs to understand the fundamental
modeling concepts first, before adding new ones.
2.3.4 Final version of the thesis
After the review of these three issues with the initial thesis
statement, the final statement now becomes:
- Thesis statement (final version)
- 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.
The three activity dimensions designing/redesigning, learning,
and using a framework all relate equally well to the three problem
dimensions complexity of classes, complexity of object collaboration,
and clarity of requirements put upon use-clients. The result is
a 3 x 3 matrix of activity/problem pairs, as shown in Table 2-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 2-1: The dissertation thesis broken up into nine sub-theses.
The thesis validation of Chapter 9 uses this matrix as the
basis of the validation strategy. For each pair, an argument is
made on why the specific problem is reduced in its severity when
carrying out the associated activity. The validation of the overall
thesis becomes the sum of the validations of the invidual sub-theses.
The remainder of this work explains and validates the dissertation
thesis.
|