Chapter 2: Frameworks, Related Work, and Thesis Statement

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

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

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