object-oriented frameworks and product- cse870/materials/frameworks/frameworks-batory.pdf ·...

Download Object-Oriented Frameworks and Product- cse870/Materials/Frameworks/frameworks-batory.pdf · Object-Oriented…

Post on 02-Nov-2018




0 download

Embed Size (px)


  • Object-Oriented Frameworks and Product-Lines1

    Keywords: object-oriented frameworks, refinements, components, product-line architec-tures, GenVoca.

    Abstract: Frameworks are a common object-oriented code-structuring technique that is usedin application product-lines. A framework is a set of abstract classes that embody an abstractdesign; a framework instance is a set of concrete classes that subclass abstract classes to pro-vide an executable subsystem. Frameworks are designed for reuse: abstract classes encapsu-late common code and concrete classes encapsulate instance-specific code. Unfortunately,this delineation of reusable v.s. instance-specific code is problematic. Concrete classes ofdifferent framework instances can have much in common and there can be variations inabstract classes, all of which lead to unnecessary code replication. In this paper, we showhow to overcome these limitations by decomposing frameworks and framework instancesinto primitive and reusable components. Doing so reduces code replication and creates acomponent-based product-line of frameworks and framework instances.


    A product-line architecture (PLA) is a design for a family of relatedapplications. The motivation for PLAs is to simplify the design and mainte-nance of program families and to address the needs of highly customizableapplications in an economical manner. Although the idea of product fami-lies is old (McIlroy, 1968; Parnas, 1976), it is an area of research that is onlynow gaining importance in software design (Bosch, 1998; DeBaud, 1999;

    1. This work was supported in part by Microsoft, Schlumberger, the University of TexasApplied Research Labs, and the U.S. Department of Defense Advanced Research ProjectsAgency in cooperation with the U.S. Wright Laboratory Avionics Directorate under contractF33615-91C-1788.

    Don Batoryi, Rich Cardonei, & Yannis Smaragdakisii

    Department of Computer Sciences, The University of Texas, Austin, Texas 78712 i &

    College of Computing, Georgia Institute of Technology, Atlanta, Georgia 30332 ii

    {batory, richcar}@cs.utexas.edu, yannis@cc.gatech.edu


  • 2 Don Batory, Rich Cardone, and Yannis Smaragdakis

    Gomaa et al., 1994; Cohen and Northrup, 1998; Batory 1998; Weiss andLai, 1999; Czarnecki and Eisenecker 1999).

    A framework is a collection of abstract classes that encapsulate commonalgorithms of a family of applications (Johnson and Foot 1998). Certainmethods of these classes are left unspecified (and hence are abstract)because they would expose details that would vary among particular, fully-executable implementations. Thus a framework is a code templatekeymethods and other details still need to be supplied, but all common code ispresent in abstract classes. A framework instance provides the missingdetails. It is a pairing of a concrete subclass with each abstract class of theframework to provide a complete implementation. These subclasses encap-sulate implementations of the abstract methods, as well as other details(e.g., data members specific to a particular framework instance).

    Frameworks often arise in PLA implementations. This is hardly unex-pected: frameworks are appropriate for reusing software parts and specializ-ing them in multiple ways for distinct applications. Members of a product-line can be created by refining framework classes with appropriate concreteimplementations. Frameworks are a fundamental technique because of theirsimplicity and generalityfrom an implementation standpoint, frameworksare just a coordinated use of inheritance. Since inheritance is a fundamentalmechanism in object-oriented languages, the applicability of the frameworkapproach is wide.

    The factoring of common algorithms into reusable, abstract classesgreatly reduces the cost of software development when building a newproduct-line application (i.e., when creating a framework instance). Unfor-tunately, this delineation of reusable vs. instance-specific code has prob-lems. Concrete classes of different framework instances can have much incommon. This situation is typically addressed by either copying code (withpredictable maintenance problems) or redeveloping concrete classes fromscratch (which is costly). A different problem arises with abstract classes:they can have variations. Much of the code in abstract classes would becommon across variations, but some parts would be radically different.Variability is typically handled by replicating the abstract classes of frame-works and hard-coding the changes into a new framework. Framework pro-liferation ensues, again incurring maintenance problems.

    These problems are real. In a recent discussion with a member of IBMsSanFrancisco project,2 these limitations of frameworks have become appar-ent. While code replication is not yet burdensome because SanFrancisco is

  • Object-Oriented Frameworks and Product-Lines 3

    still new, difficulties are anticipated in the future. We believe that theseproblems arise in other projects that use OO frameworks.

    A simple way to state the above problem is that product lines withoptional features will not be concisely expressed using frameworks. Suchframeworks suffer from either overfeaturing (Codenie, De Hondt,Steyaert, and Vercammen 1997) a lot of not-entirely-general functional-ity is part of the framework or replication of the same code across manyinstances. In this paper we present a general technique to solve this prob-lem. The solution is effected by relaxing the boundary between a frame-work (the common part of the product line) and its instantiations (theproduct-specific part). More specifically our technique is based on assem-bling both the abstract classes of frameworks and the concrete classes oftheir instances from primitive and reusable components. We show that thelevel of abstraction that delineates abstract classes from concrete classescan be drawn in different ways, and by decomposing frameworks and theirinstances in terms of our components, variations in abstract and concreteclasses can be handled without code replication. A particular framework orframework instance is created by a composition of components; variationsin frameworks and their instances are expressed as different componentcompositions. Our approach can be used to express any framework, butrequires more language support than plain frameworksinstead of regularinheritance, parameterized inheritance is needed. Nevertheless, this supportis readily available in production languages like C++. An example in anextended version of the Java language is given to illustrate our ideas.


    In this section we offer an overview of some design-level ideas thatunderlie our work. Many terms and concepts used in the rest of the paperare defined here.

    Collaboration-Based Designs. It is well-known in object-orienteddesign that objects are encapsulated entities that are rarely self-sufficient.The semantics of an object is largely defined by its relationship with otherobjects. Object interdependencies can be expressed as collaborations. A

    2. IBM SanFrancisco is a Java-based set of components that allows developers to assembleserver-side e-business applications from existing parts, rather than building applicationsfrom scratch.

  • 4 Don Batory, Rich Cardone, and Yannis Smaragdakis

    collaboration is a set of objects and a protocol (i.e., a set of allowed behav-iors) that determines how these objects interact. The part of an object thatenforces the protocol of a collaboration is called the objects role in that col-laboration (Reenskaug, et al, 1992; VanHilst and Notkin 1996; Smaragdakisand Batory 1998).

    A collaboration-based design expresses an application as a compositionof separately-definable collaborations. In this way, each object of an appli-cation represents a collection of roles describing actions on common data.Each collaboration, in turn, is a collection of roles that encapsulates rela-tionships across its corresponding objects.

    Example. I (Batory) am an author of this paper. This relationship isdefined by a collaboration of two objects, one in the role of authorand another in the role of manuscript. I am also a parenta collabo-ration of two or more objects, one in the role of parent and others inthe role of children. I am also a car ownera collaboration of two ormore objects, one in the role of owner and others in the role of pos-session. And so on. I am a single object where relationships that Ihave with other objects are expressed through collaborations where Iplay a specific role in each collaboration.

    The collaborations mentioned above are generic; they are not specificto me but are general relationships that can be defined in isolation ofeach other. Furthermore, such collaborations are applicable in differ-ent contexts to different entities. For example, a corporation can owna car, and so too can a government entity. The relationship betweenowner and possession is the same in all cases, but the ownership rolesare played by very different classes of objects (e.g., people, corpora-tions, government). Symmetrically, a possession could be a car, dog,or building; the possession role can also be played by very differentclasses of objects. The same holds for roles in other collaborations.

    GenVoca. GenVoca is a design methodology for building architectur-ally-extensible softwarei.e., software that is extensible via componentaddition and removal (Batory and OMalley 1992). GenVoca is a scalableoutgrowth of an old and practitioner-ignored methodology of program con-struction called step-wise refinement. GenVoca freshens this methodologyby scaling refinements to a component or layer (i.e., multi-class-modular-ization) granularity, so that applications of enormous complexity can beexpressed as a composition of a few refinemen


View more >