1.2 Object-oriented frameworks-extensibility is the key

1.2 Object-oriented frameworks extensibility is the key

The UML-F profile focuses on object-oriented frameworks for which we define the relevant terminology in this section. What are frameworks? Instead of having to assemble systems using single Lego-like building blocks, object-oriented frameworks are prefabricated extensible sets of classes/components^[1] . For example, think of a universal kitchen device into which one can plug in a certain part and use it as shaker. Another part converts the device to a meat grinder. This multi-purpose device illustrates the characteristics of an object-oriented framework. It consists of several separate components such as an electric motor, a driving axle, a power plug, a switch, and a casing all of which are assembled as a unit that offers a well-defined extension interface. An adaptation of the framework simply requires a compatible plug-in. Any future extension part compliant with the interface can be plugged into the framework. Contrast this with the effort involved in building the device from Lego-like single components. This involves selecting the appropriate components and assembling them without explicitly defining an extension interface. In other words, frameworks significantly improve reuse, as not only code is reused but also architecture design.

^[1] The term 'component-ware' has become the vogue in the software engineering community but there are many different uses of the term 'component'. We define 'component' as a piece of software with a programming interface, deployable as unit (Pree and Templ, 2000). For a discussion of component standards we refer you to Szyperski (1998).

In general, a software framework is a piece of software that is extensible through the call-back style of programming (Pree and Templ, 2000). Frameworks built with conventional languages rely on function or procedure parameters. In order to modify the behavior of object-oriented frameworks, programmers apply inheritance to override dynamically bound methods in subclasses of framework classes. Note that from this point of view the Java interface construct is a similar concept that provides a conceptually analogous extension mechanism. Such method (re)definitions are analogous to providing specific procedures or functions in conventional programming in both cases the application architecture resides in the framework.

Figure 1.2(b) illustrates the call-back style of programming. Structured programming languages, such as Pascal, provide procedures and functions as building blocks. Figure 1.2(a) shows an application that invokes several small library routines. Contrast this with Figure 1.2(b) where the library contains a framework that is extended by passing specific procedures or functions as parameters to the framework. The framework calls them back.

Figure 1.2. Structured (a) and call-back (b) style of programming

Object-oriented frameworks usually consist of a collection of components with predefined collaborations between them and extension interfaces. We call the points of predefined extensions hot spots (Pree, 1995) or variation points. Figure 1.3 shows these framework characteristics in a schematic runtime snap shot (not UML) with the two variation points in gray. An adaptation of the framework plugs in specific objects instead of these placeholders. The arrows connecting method interfaces express the interaction between the concrete and abstract components. The box around the preassembled objects expresses that this ensemble can be viewed as one parameterizable component.

Figure 1.3. Schematic runtime snapshot of a framework with two variation points

A framework deserves the attribute well-designed if it offers the domain-specific variation points to achieve the desired flexibility via adaptation. Well-designed frameworks also predefine most of the overall architecture that is, the composition and interaction of its components. Applications built on top of a framework reuse not only source code but also architecture design, which we consider to be an important characteristic of a framework.

1.2.1 White-box components of frameworks

Frameworks differ from ordinary class libraries since they predefine an architecture that models the interaction between several components. Nevertheless, the classes of a framework form a class hierarchy that does not differ from a class hierarchy of single components. It just might have more high-level abstract classes and/or interfaces.

White-box components of frameworks are incomplete classes that is, classes that contain methods without meaningful default implementations. Class Promotion in the sample framework class hierarchy depicted in Figure 1.4 illustrates this characteristic. Let us assume that the framework supports the building of web-based shopping applications. A subclass of Promotion defines the rules for a customer receiving certain benefits such as discounts or gift certificates. A method box with a diagonal line represents an abstract method.^[2] Class Promotion has one abstract method that has to be overridden in a subclass.

^[2] This notation is introduced in Chapter 3.

Figure 1.4. Sample framework class hierarchy

Programmers adapt the framework by overriding methods called out from other methods in the framework. The need to override methods implies that programmers have to understand the framework's design and implementation, at least to a certain degree. That makes the documentation of variation points crucial to the success of a framework.

1.2.2 Black-box components of frameworks

Black-box components are ready-made components for framework adaptations. Modifications are accomplished by composition and parameter definitions, not by conventional programming.

The framework class hierarchy in Figure 1.4 currently offers two subclasses of the abstract class Payment, EMoney and CreditCard, that provide default implementations of Payment's abstract method. Supposing that the framework components interact as depicted in Figure 1.5(a), an adaptation plugs in instances of classes FreqShopping and EMoney see Figure 1.5(b). In the case of class Payment, the framework provides the appropriate ready-to-use subclasses; in the case of class Promotion appropriate subclasses must be created first. As the classes EMoney and CreditCard can be used as they are, they represent black-box components.

Figure 1.5. Framework (a) before, and (b) after specialization by composition

This example illustrates that frameworks typically neither provide just white-box nor just black-box components. If the framework is heavily reused, numerous adaptations will suggest which black-box defaults could be offered instead of just providing a white-box interface. So frameworks are likely to offer more and more black-box components as they mature.