Object-Oriented Frameworks and Product-LinesDon Batoryi, Rich Cardonei, & Yannis Smaragdakisii1 Introduction2 GenVoca and Collaboration-Based DesignsFigure 1 Creating Inheritance Hierarchies by Composing Layers3 Mixin-Layersclass Fig1 extends L4< L3< L2< L1 >>> (1)Fig1 = L4< L3< L2< L1 >>> // type equation of (1) (2)4 Limitations of OO FrameworksFigure 2: Refinement Hierarchies and Framework InstancesFigure 3: Partitioning Against Layer Boundaries5 An Example Product-Line6 Related Work7 Conclusions8 References1Object-Oriented Frameworks and Product-Lines1Keywords: 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.1 INTRODUCTIONA 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 SmaragdakisiiDepartment 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, [email protected] Don Batory, Rich Cardone, and Yannis SmaragdakisGomaa 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 template”—keymethods 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 generality—from 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 IBM’sSanFrancisco project,2 these limitations of frameworks have become appar-ent. While code replication is not yet burdensome because SanFrancisco isObject-Oriented Frameworks and Product-Lines 3still 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
View Full Document
Unlocking...