Volume Number: 17 (2001)
Issue Number: 10
Column Tag: Software Engineering

Frameworks

by Paul E. Sevinc, Switzerland

Reuse is a key objective of software engineering. In our January 2001 article [15], we discussed how reuse is achieved by the use of patterns. To recap, we saw that patterns promote analysis, architecture, or design reuse, but never implementation reuse. A framework supplies the mechanisms that enforce a policy for interaction between software entities with open implementations [2]. As we shall see, frameworks always promote analysis, design, and implementation reuse, but not always architecture reuse.

In this article, we briefly review libraries and toolkits as a point of comparison for frameworks. Then we discuss in more detail object-oriented frameworks. Finally, we touch on the issue of black-box vs. white-box reuse.

Szyperski [17, p. 134] notes that "[e]arly programming languages attempted to provide all functions that would ever be used in multiple programs. An explosion of built-in functions was the result. [...] Since then, there has been a clear tendency to take specific functionality out of languages, in favor of abstractional and structural features." The specific functionality that was taken out, as well as additional functionality, was put in libraries. (As explained at the end of this section, toolkits are just special types of libraries.) The evolution of Pascal over Modula-2 to Oberon [11] is but one witness of this tendency.

The primary purpose of software libraries is to provide software engineers with reusable pieces of code (i.e., implementation). The most common kinds of libraries are procedure libraries (also called function libraries) and class libraries.

The Mac Toolbox/Carbon [1] is an example of a procedure/function library. It is designed and implemented in a procedural fashion to be used with a procedural programming language such as Pascal or C. Note that it not only defines procedures/functions, but also data structures (i.e., RECORDs and structs).

The C++ Standard Library [16] is an example of a class library. It is designed and implemented in an object-oriented fashion to be used with an object-oriented programming language, namely C++. Just like C++ is not a purely object-oriented programming language (as opposed to Java for instance), but a hybrid programming language, the C++ Standard Library is not a pure class library. Rather, it is a library of libraries, some of which are class libraries.

Toolkits are simply class libraries whose classes are related [5]. An example is the Java Abstract Window Toolkit (AWT), a library of classes for graphical user interfaces (GUIs) [6].

First of all, let us dispel a common misconception: frameworks are not exclusive to the realm of object orientation. Oberon microsystems, for instance, have an amazing component framework in their product line [10]. And numerous frameworks have been realized in a procedural programming language such as C. However, we have to add that in the latter case, procedure variables/function pointers are typically used to mimic polymorphism. That said, we nevertheless confine ourselves to object-oriented frameworks, nowadays the most typical kind of frameworks, in the next section.

Whatever the paradigm used, the key difference between libraries and frameworks lies in whether the client is in charge or not:

Figure 1: Library vs. Framework [9].

In procedural programming, the client of a procedure library develops the main procedure and calls library procedures at her own discretion (see Figure 1 left). In a similar manner, when using a class library, the user-defined classes are in control and determine the overall architecture of the system.

The opposite is the case when development is based on frameworks; the framework decides when the user's methods are invoked. Thus, there is an inversion of control; the framework incorporates the control logic [5, 12] (see Figure 1 right). (The way this is realized in object-oriented frameworks is explained in the next section.) This is called the Hollywood principle: "Don't call us, we'll call you!" [9] or the Greyhound principle: "Leave the driving to us." [2].

Examples: The Java Platform Math Class and Model-View-Controller in Swing

The Java Math class [6] defines mathematical functions (e.g., sin) as well constants (e.g., e) and as a whole is obviously a function library. Client code that invokes one of Math's methods relinquishes control only for a split second and does not have to worry about any side effects.

The Model-View-Controller (MVC) pattern [5, 9] depicted in Figure 2 underlies Java's Swing GUI elements [6]. In the case of a text field, for instance, the model manages the actual text in memory, the view displays the text on screen, and the controller determines the text's editability.

Figure 2: Components of the MVC [9].

We are not restricted to using the text field as is. Any of its three constituent parts can be replaced independent of the others by a subclass (e.g., the default controller in order to accept numerical characters only). That and the fact that the methods our subclass overrides are—or in a good design at least should be—invoked only by non-client code make the text field a framework.

An object-oriented framework is a customizable implementation of software. It consists of a set of cooperating classes and has hot spots [9] (also called plug points [4]), which make the customization possible (see Figure 3).

Figure 3: Framework [9].

Hot spots are abstract, or at least non-final, classes. Through factory, template and hook methods [5], the framework invokes the methods on the subclasses of the hot spots (see Figure 4). But it maintains overall control and makes sure that certain core tasks are fulfilled.

Figure 4: HotSpot [9].

Example: JUnit

JUnit is a framework for unit testing in Java [7]. Its original authors are Kent Beck and Erich Gamma, but it is maintained by an open community of software engineers. JUnit's four core types are partially depicted in Figure 5.

Clients of the framework subclass TestCase to add one or more methods that actually conduct tests. That is, TestCase is a hot spot. The three TestCase methods shown in italic are not really abstract: setUp and tearDown are empty hook methods invoked by the template method run before and after runTest, respectively. And runTest's default implementation invokes the client-added test method designated by the fName field using reflection.

Figure 5: JUnit Extract (adapted from [3]).

Let us discuss the use of the fName field a little bit more. As we already mentioned, a TestCase subclass can define more than one test method to test different aspects of a class or a set of classes. Typically, runTest invokes only one client-added test method (because setUp and tearDown should be invoked before and after every test method, but only by run in order to keep the design clean). Therefore, the TestCase subclass has to be further subclassed to override runTest for each test method. Alternatively, the TestCase subclass is not subclassed further. Instead, fName is defined to contain the name of different test methods for different instances. The latter approach is obviously simpler (albeit less type safe). (Using reflection in this way within an object-oriented framework allows for what could be considered "run-time parameterizable hot-spots".)

Beck and Gamma [3] treat the core design of the JUnit framework (using the language of design patterns) in more detail.

Application and Domain-Specific Frameworks

Frameworks can be domain-specific. FEMO, for instance, is a framework for multiobjective optimization with genetic algorithms [13]. Applications that make use of FEMO relinquish control during optimization runs, but FEMO does not impose any architecture on the application as a whole. Therefore, FEMO promotes analysis, design, and implementation reuse: analysis of the domain, and design and implementation of the classes.

An application framework is a standard program that takes care of window management, menu handling, opening & saving documents, etc., but that has to be extended by the programmer to give them content. Mössenböck [9] calls this programming by difference. Metrowerks' PowerPlant [8] is a typical application framework and as such defines the overall architecture of every PowerPlant-based application.

A black-box framework hides its implementation from its clients whereas the implementation of a white-box framework is visible to—and possibly modifiable by—its clients. A glass-box framework is a white-box framework whose implementation is not modifiable. [18] (Note that, rather confusingly, frameworks are sometimes designated as white-box as soon as they emphasize implementation inheritance over object composition [17], whether the implementation is actually visible to the client or not.)

Black-box reuse is preferable over white-box reuse. With the former, when (part of) the framework is replaced by a new release whose interface and specification have not changed, client code should not break. With the latter, the implementation may have to be studied anew, since at least informally it was part of the contract.

Listing 1

method( Type parameter )
   throws IllegalArgumentException
{
   if ( parameter == null || !inRange( parameter ) ) {
      throw new IllegalArgumentException();
   }
   ...
}

For example, after studying its source code, some clients of the white-box method method in Listing 1 might rely on NullPointerExceptions (which are unchecked exceptions in Java and thus need not be declared in the exception specification) never being thrown. In a future version, method no longer checks for null references (see Listing 2), which—let us assume—it never advertised to do anywhere in its formal documentation in the first place. At compile time, all of the existing clients will compile just fine. At run time, however, some might now behave erroneously.

Listing 2

method( Type parameter )
   throws IllegalArgumentException
{
   if ( !inRange( parameter ) ) {
      throw new IllegalArgumentException();
   }
   ...
}

Mössenböck's Objektorientierte Programmierung in Oberon-2 [9] is an excellent book on object orientation in general. The latest edition features a chapter on frameworks. Unfortunately, this edition has never been translated to English.

Gamma et al.'s Design Patterns [5] is first and foremost a book on, well, design patterns. Nevertheless, it also quickly introduces frameworks and discusses the important relationship between patterns and frameworks.

Szyperski's Component Software [17] is a seminal work on component orientation. It features a chapter discussing reuse in general, including a concise treatment of frameworks.

This article is partly based on a chapter in my M.S. thesis [14] that was proofread and commented on by Prof. Dr. Rachid Guerraoui, Dr. Jean-Philippe Martin-Flatin, Luc Girardin, and Dani Seelhofer.

I would like to thank the contributing reviewers for this article, Nate Little and Peter "Primetime" Taylor from Trilogy Software, Inc.

• [1] Apple Computer, Inc. Carbon Developer Documentation. Home Page. Located at
  http://developer.apple.com/techpubs/macosx/Carbon/carbon.html.
• [2] B. Appleton. "Patterns and Software: Essential Concepts and Terminology". Available at
  http://www.enteract.com/~bradapp/docs/.
• [3] K. Beck and E. Gamma. "JUnit: A Cook's Tour". Java Report, Vol. 4, No. 5, May 1999.
• [4] D.F. D'Souza and A.C. Wills. Objects, Components, and Frameworks with UML: The Catalysis Approach. Addison-Wesley, Reading (Massachusetts), 1999.
• [5] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading (Massachusetts), 1995.
• [6] C.S. Horstmann and G. Cornell. Core Java: Fundamentals. Sun Microsystems Press, Palo Alto, 5th edition 2001.
• [7] JUnit.org. JUnit, Testing Resources for Extreme Programming. Home Page. Located at
  http://www.junit.org/.
• [8] A. Montgomery. "First Steps". MacTech Magazine, Vol. 17, No. 4, April 2001.
• [9] H. Mössenböck. Objektorientierte Programmierung in Oberon-2. Springer, Heidelberg, 3rd edition 1998.
• [10] Oberon microsystems, Inc. BlackBox Component Builder. Home Page. Located at
  http://www.oberon.ch/prod/BlackBox/index.html.
• [11] M. Reiser and N. Wirth. Programming in Oberon: Steps beyond Pascal and Modula. Addison-Wesley, Reading (Massachusetts), 1992.
• [12] S.R. Schoch. Classical and Object-Oriented Software Engineering: With UML and Java. McGraw-Hill, Boston, 4th edition 1999.
• [13] P.E. Sevinç. Ein C++-Framework für die Mehrzieloptimierung mit genetischen Algorithmen. Semester Thesis, Swiss Federal Institute of Technology Zurich, January 1999.
• [14] P.E. Sevinç. Design Patterns for the Management of IP Networks. M.S. Thesis, Swiss Federal Institute of Technology Zurich, February 2000.
• [15] P.E. Sevinç. "Patterns". MacTech Magazine, Vol. 17, No. 1, January 2001.
• [16] B. Stroustrup. The C++ Programming Language. Addison-Wesley, Reading (Massachusetts), 3rd edition 1997.
• [17] C. Szyperski. Component Software: Beyond Object-Oriented Programming. Addison-Wesley, Reading (Massachusetts), 1998.
• [18] C. Szyperski. "Components and Objects Together". Software Development, Vol. 7, No. 5, May 1999. Available at
  http://www.sdmagazine.com/breakrm/features/s995f2.shtml.

Paul E. Sevinç is back in Europe after spending three fantastic months in Austin, Texas going through Trilogy University, the corporate boot camp of Trilogy Software, Inc. You can reach him at paul.sevinc@ubilab.org.