jagomart
digital resources
picture1_Programming Pdf 184381 | 07 01 Kuhlemann P 2146


 152x       Filetype PDF       File size 0.59 MB       Source: www.inf.ovgu.de


File: Programming Pdf 184381 | 07 01 Kuhlemann P 2146
design patterns revisited martin kuhlemann school of computer science university of magdeburg germany kuhlemann iti cs uni magdeburg de abstract label includes b buttoninterface buttoninterface design patterns are general solutions ...

icon picture PDF Filetype PDF | Posted on 01 Feb 2023 | 2 years ago
Partial capture of text on file.
                                                        Design Patterns Revisited
                                                                       Martin Kuhlemann
                                                   School of Computer Science, University of Magdeburg, Germany
                                                                kuhlemann@iti.cs.uni-magdeburg.de
               Abstract                                                                                 Label       includes   <>
                                                                                                   _b:ButtonInterface       ButtonInterface
               Design patterns are general solutions for recurring problems and                    setText()                click()
               used to develop flexible, reusable and modular software with                         getText()
               Object-Oriented Programming (OOP). Prior studies have shown
               a lack of modularity in object-oriented design patterns. Aspect-                      FramedLabel               Button
               OrientedProgramming(AOP)aimsatimprovingflexibility,reusabil-                           getText()                 click()
               ity, and modularity in object-oriented designs. In a case study Han-
               nemann and Kiczales have argued that AOP improves the imple-                Figure 1. UMLnotation of OOP classes and interfaces.
               mentation of GoF design patterns. Feature-Oriented Programming
               (FOP) is a new programming technique that also aims to improve         2.   Background
               the modularity in object-oriented designs. In this paper we com-
               pare OOP, AOP, and FOP in a quantiative case study of design           2.1  Object-Oriented Design Patterns
               pattern implementations. We evaluate the OOP, AOP, and FOP de-         In OOP methods and variables are merged into classes. For com-
               sign pattern implementations with respect to modularity and show       posingclassesOOPprovidesmechanismsofinheritanceandobject
               that FOP performs best compared to OOP and AOP.                        composition [28]. Variability of software is achieved through poly-
                                                                                      morphismofclasses [7].
                                                                                      Object-oriented design patterns propose advantageous class ar-
                                                                                      rangements for frequently recurring requirements [13]. The re-
                                                                                      quirements are described by roles of interacting objects, e.g., if one
                                                                                      kind of object has to observe changes of another object. If a class
               1.   Introduction                                                      should play a role in one of these design patterns it is assigned to
               Design patterns are accepted and well known approaches to imple-       implement interfaces or to inherit classes specific to its role.
               ment variable and reusable software using Object-Oriented Pro-            Figure 1 depicts the UML notion for OOP mechanisms [22].
               gramming (OOP) [13]. Although widely accepted, design patterns         The figure depicts the classes FramedLabel and Button, the ab-
               lack in separating software into modules and cause crosscutting        stract class Label, and the interface ButtonInterface. The class
               concerns [15].                                                         LabeldeclaresthemethodgetText,theclassButtondefinesthis
               Crosscutting concerns imply tangling, scattering and replication       method. Equivalently, the method click is declared in the inter-
               of source code which results in complex software [16]. Classes         face ButtonInterface and is defined in the class Button. Inher-
               that include code of a crosscutting concern are closely coupled to     itance and interface implementations are denoted by arrows while
               this concern (tangling) and to the other classes that also implement   inheritance implies solid arrows and interface implementations im-
               this crosscutting concern. To exchange the crosscutting concern        ply dashed arrows. Associations between classes are denoted by
               the classes that include this concern have to be replicated. Thus,     simple lines, e.g., the class Label includes one member of type
               software including crosscutting concerns is monolithic, hard to        ButtonInterface.
               maintain and reuse and thus development effort increases. Cross-       2.2  Aspect-Oriented Programming
               cutting concerns are studied in ongoing research [4, 23, 27], and      The purpose of AOP is to modularize crosscutting concerns into
               numerous approaches aim to tackle them on different levels of          aspects [16].
               software development, e.g., during requirement engineering and         WenowexplaintheAOPmechanismsofAspectJ1,apopularAOP
               others [1, 25, 8, 20]. Recently, advanced programming techniques,      language extension for Java, that are used in our case study [15].
               e.g., Aspect-Oriented Programming (AOP) and Feature-Oriented
               Programming (FOP), gain momentum to overcome crosscutting              Pointcut and Advice.   The mechanism of AOP is the extension
               concerns [16, 24].                                                     of code implementing events that occur at runtime (so-called join
               Several studies have shown the strengths of AOP and FOP [15, 14,       points) [18]. The static representation of a runtime event in the
               2]. These studies concentrated on single techniques or compared        source code is called join point shadow. Join point shadows are
               AOPandFOPqualitatively.                                                for example method calls, constructor calls, or member access. A
               In this paper we compare OOP, AOP, and FOP in a quantitative           pointcut defines a set of join points to be extended. The extension
               case study using the Gang-of-Four (GoF) design patterns [13]. We       to be invoked at the join points is called advice.
               did so to achieve a broader perspective of problems that occur fre-       Anexampleforpointcut and advice (PCA) is given in Figure 2.
               quently in software development. We show that FOP outperforms          TheaspectMyAspect(Lines12–26)extendstheclassesLabeland
               OOPandAOPwithrespect to modularity but also includes draw-             Button. The pointcut LabelChangeCall (Line 13) refers to all
               backs.
                                                                                      1http://www.eclipse.org/aspectj/
               1 public class Label {                                                                                  <>              <>
               2    public void setText(){/∗ ... ∗/}                                                                 ButtonInterface  declare    MyAspect
               3 }                                                                                                                    parents Label.Name
                                                                                                                         Button             pc:LabelChangeCall
                                                                                                                                            before:LabelChangeCall()
               4 public class Button {                                                                                 HashMap              before:LabelChangeExec()
               5   ButtonInterface _b;                                                                                  put()          uses Label.PrintName()
               6    public void click(){                                                                                get()               getPrinter()
               7     /∗ . . . ∗/                                                                                        set()               declare precedence
               8     myLabel.setText("Button clicked")                                                             Figure 3. Graphical notation of an aspect.
               9     /∗ . . . ∗/
              10   }
              11 }
                                                                                                      the same singleton instance of the aspect. In this case the aspect is
              12 public aspect MyAspect {                                                             instantiated once.
              13    protected pointcut LabelChangeCall():                                             Parent Declaration.       Aspects can make a class to implement an
                      call (*´ ´Label.*(..));                                                         interface. Furthermore, aspects can declare a class to inherit from
              14    protected pointcut LabelChangeExec():
                      execution(*´´Label.*(..));                                                      another class.
              15    before():LabelChangeCall(){/*...*/}                                               In Figure 2 (Line 24), the aspect MyAspect assigns the class
              16    before():LabelChangeExec(){/*...*/}                                               Buttontoimplementtheinterface ButtonInterface.
              17
              18    public String Label.Name;                                                         OtherAOP. ThecategoryOtherAOPincludescompilerwarnings
              19    public void Label.printName(){/*...*/}
              20                                                                                      and errors and includes the declaration of advice precedence.
              21    public HashMap printer;                                                           If a user defined constraint is violated by the classes, the aspect
              22    public void getPrinter(){/*...*/}                                                 weaver can be instructed to invoke compiler warnings or compiler
              23                                                                                      errors.
              24    declare parents:Button implements ButtonInterface;
              25    declare precedence:PriorAspect,MyAspect;                                          Precedence declarations define the ordering of advice if join point
              26 }                                                                                    shadowsareadvised by more than one aspect, e.g., Fig. 2, Line 25,
                                                                                                      states that the advice of the aspect PriorAspect has to be applied
                      Figure 2. Application of call and execution advice in AOP.                      before the advice of the aspect MyAspect is applied.
                                                                                                          We depict our extended UML notion for aspects in Figure 3.
                  statements that invoke methods of the class Label (call pointcut),                  The shaded element depicts the aspect MyAspect of Figure 2 and
                  e.g., call statements for the method setText. The corresponding                     includes the PCA, ITD, and AFM. Pointcuts are abbreviated using
                  piece of advice (Line 15) is woven into the method click of the                     pc while advice is abbreviated by the type of advice (e.g., before
                  class Button before (before advice) the call of the labels method                   advice). We depict subclass declarations assigned by an aspect by
                  setTextis invoked (Line 8). Advice also can be applied after (af-                   associating the aspect to the inheritance relationship of the classes
                  ter advice) or around (around advice) join points.                                  (association declare parents, Fig. 3).
                  The advice of the pointcut LabelChangeExec (Line 16) refers to                      2.3   Feature-Oriented Programming
                  the body of the method setText (execution advice), i.e., the ad-                    FOP aims at feature modularity in software product lines where
                  vice is woven into the method setText of class Label (Line 2).                      features are increments in program functionality, e.g., feature trac-
                  While pieces of call advice, e.g., advice assigned to the point-                    ing [24, 6]. Typically, features are not implemented through one
                  cut LabelChangeCall, intercept the method caller, i.e., call ad-                    single class [26, 5] but through different collaborating classes and
                  vice only augments specific join points that perform the method                      adding a feature subsequently means to introduce code, e.g., new
                  setText, execution advice, e.g., advice assigned to the pointcut                    methods, into different existing classes [24, 26]. This code of dif-
                  LabelChangeExec,intercepts the called object, i.e., execution ad-                   ferent classes associated to one feature is merged into one feature
                  vice augments all join points performing the method setText.                        module.Inthefollowingselectingfeaturesofthesoftwareisequiv-
                  Inter Type Declaration.        Inter type declarations (ITD) are meth-              alent to selecting feature modules. Assigning a feature to a config-
                  ods or variables that are inserted into classes and interfaces by an                uration causes the new feature module to superimpose (refine) the
                  aspect and thus become members of these classes and interfaces                      old feature modules [6], i.e., methods and classes are added or get
                  respectively. Contrary to Java conventions, AspectJ allows to intro-                refined.
                  duce methods including a method body into interfaces [15].                          WesystematizethemechanismsoftheAHEADToolSuite2,apop-
                  In our example of Figure 2 the aspect MyAspect defines two ITD                       ular FOPlanguageextensionforJava,intothecategoriesofMixins,
                  i.e., to insert the member variable Name (Line 18) and method                       Method Extensions, and Other FOP. Additionally, we describe the
                  printName(Line19)into the class Label.                                              OOP technique of Singleton classes as a category since we used
                  Aspect Fields and Methods.         Aspects can contain members simi-                singleton classes to transform AFM into FOP.
                  lar to members of an OOP class, i.e., aspects can contain methods,                  Method Extension.        FOPallows to extend methods of classes by
                  fields, or inner classes and interfaces. These aspect members can                    overriding.
                  be invoked like methods of a class from inside the aspect, e.g., by                 An example is depicted in Figure 4. The feature module BASE
                  advice, or from outside the aspect, i.e., from the classes (using the               (Lines 1–4) includes a class Label that is superimposed by the
                  aspect method aspectOf). The aspect MyAspect includes one as-                       refinement EXTENSION (Lines 5–12), i.e., the refinement EXTEN-
                  pect field and one aspect method (Fig. 2, Lines 21–22).                              SION superimposes the method setText of the class Label. The
                  If aspect fields and methods (AFM) are invoked through aspectOf                      method setText of the feature module EXTENSION extends the
                  and no extra pointcut mechanisms are declared (e.g., percflow),
                  then every reference to the aspect members of one aspect refers to                  2http://www.cs.utexas.edu/users/schwartz/ATS.html
                    1 // feature module BASE                                                                                               FOP where each refinement is figured by one class of an OOP
                    2 public class Label {                                                                                                 inheritance hierarchy.
                    3      public void setText(){/∗ ... ∗/}
                    4 }                                                                                                                    3.      GoalStatement
                    5 // feature module EXTENSION                                                                                          3.1      WhatDoWeAdress?
                    6 refines class Label {                                                                                                AOPandFOPprovidebenefitscomparedtoOOPbuthavedifficul-
                    7      public void setText(){                                                                                          ties and strengths [3]. In this paper we aim to compare OOP, AOP,
                    8       Super().setText();                                                                                             and FOPimplementations with respect to modularity.
                    9     }
                   10      public String Name;                                                                                             3.2      Experimentation Methodology
                   11      public void printName(){/∗ ... ∗/}
                   12 }                                                                                                                    3.2.1       Criteria
                                Figure 4. Refinement of a method by a FOP refinement.                                                        Wecomparethedesignpatternimplementationswithrespecttothe
                                                                                                                                           properties of modularity, i.e., cohesion and variability, and thus we
                                                                                                                                           follow existing studies of OOP and AOP [15, 14]. We define these
                                                                                                                                           properties as follows:
                                               Base                 Label           includes   Button                                      Cohesion.           An aggregate definition, e.g., a package, of different
                                                               setText()                       click()                                     programchanges,e.g.,theintroductionofdifferentclassesormeth-
                                                                   Label            name                                                   ods into the software, can be referred to by a name and is there-
                                               Extension Name: String                          String                                      fore cohesive [17]. The named module, e.g., a package, can be ex-
                                                                setText()                                                                  changed and reused and thus development effort decreases.
                                                                printName()                                                                Cohesive modules rarely reference to other modules and are thus
                                          Figure 5. Refinements and classes in FOP.                                                         loosely coupled to other modules.
                                                                                                                                           Ourdefinition of cohesion is similar to the definition of Locality of
                                                                                                                                           Hannemannetal.andCohesionofGarciaetal. [15, 14].
                        setText method of the feature module BASE by invoking this su-                                                     Variability.          If features of a modularized software shall be able to
                        perimposed method using Super (Line 8) and defining additional                                                      change flexibly, the modules of the software have to be composed
                        statements.                                                                                                        in many different ways. Modules that are loosely coupled are pre-
                        Mixins.         Feature modulesincludemixinclasses,thatsuperimpose                                                 required [17]. Consequently, modules can be exchanged easily.
                        andrefineotherclasses. Mixins are members of mixin classes, e.g.,                                                   Tangling of code of different concerns of the software causes close
                        methodsandmembervariables,thatareintroducedintoanexisting                                                          couplingofmodulesresultingininvariant,complexandmonolithic
                        class and extend the set of members of this refined class.                                                          software [16].
                        In Figure 4 the new method printName and the new member Name                                                            Our definition of variability corresponds to the criteria Compo-
                        is introduced by the feature module EXTENSION, i.e., by the mixin                                                  sition Transperency of Hannemann et al. [15]
                        class Label (Lines 10–11).                                                                                              In addition, Hannemann et al. used the criteria Reusability and
                        We define that a subtype declaration of a mixin class is a mixin                                                    (Un)pluggability to evaluate the aspect-oriented design pattern im-
                        too since this property is added to a class. Thus, mixin classes can                                               plementations [15]. We do not use these criteria because we argue
                        introduce additional base classes for a refined class.                                                              themtobeimprecise and not significant.
                        Singleton.          Asingleton class is an idiom to limit the number of                                            3.2.2       Schedule of Comparison
                        instances of a class. The singleton class is usually instantiated
                        once and all subsequent requests to this class are forwarded to this                                               Weadopt the methodology of Hannemann et al. and Garcia et al.
                        unique instance [13].                                                                                              to evaluate programming paradigms [15, 14]. Both studies com-
                        Other FOP.             This category include idioms of the arrangement of                                          pared OOP and AOP on the base of a case study of design pattern
                        classes, the ordering of feature modules and the qualification of                                                   implementations. To analyze many diverse applications we reim-
                        membervariables.                                                                                                   plemented the 23 GoF design patterns in FOP and adopt the OOP
                        All classes, that are not nested in other classes are encapsulated in                                              and AOP implementations. For different design patterns we im-
                        feature modules.Theorderingoffeaturemodulesdefinestheorder-                                                         plemented alternative FOP implementations (up to 7 per design
                        ing of extensions for one single method. Class members qualified                                                    pattern) resulting in 50 different FOP implementations. For com-
                        as limited visible, e.g., qualified as protected, cannot be accessed                                                parison we choose the implementation that is close to the AOP
                        from classes others than the class itself and its subclasses.                                                      counterpart.
                             Figure 5 depicts our graphical notion of FOP mechanisms that                                                       We compare the different implementations of the design pat-
                        are used in Figure 4. The feature modules BASE and EXTENSION                                                       terns by repeating the following schedule:
                        are shaded and encapsulate the classes Label and Button and a                                                       1. We review the aim of the pattern.
                        mixinclassrefiningtheclassLabel.(TheStringclassoftheJava-                                                            2. We give an explanation of the OOP, AOP, and FOP implemen-
                        API is not implemented inside the layer but is depicted to depict                                                        tations each followed by a discussion of the specific pros and
                        special properties of the Label class.)                                                                                  cons.
                             Werefer to classes and mixin classes inside feature modules by                                                 3. We compare the OOP, AOP, and FOP implementations based
                        ([X.]*)Y, where Y is a (nested) feature module and Y is the single                                                       onthe criteria given in Section 3.2.1.
                        mixin class.
                             We used mixin layers to implement the GoF design patterns                                                      4. We give a short summary of specific difficulties and strengths
                        in FOP [26]. Mixin layers is one implementation technique for                                                            of the OOP, AOP, and FOP implementations that were captured
              1 public interface ComponentFactory {                                                                     <>
              2   public JLabel createLabel();                                                                      ComponentFactory
              3  ...                                                                                                createLable()
              4 }                                                                                                   createButton()
                                                                                                                    getName()
                Figure6. TypelimitationthroughmethoddeclarationsintheOOP                                     RegularFactory    FramedFactory
                Abstract Factory implementation.                                                             createLable()     createLable()
                                                                                                             createButton()    createButton()
                    during the evaluation but are not relevant for the analyzed crite-                       getName()         getName()
                    ria.                                                                                Figure 7. Abstract Factory through OOP.
                   As a summary we give a table that aggregates and balace the
                results of the evaluation. A ”+” depicts that the technique performs
                well with respect to the criterium while ”-” depicts the lack of                                        <>
                the technique regarding that criterium compared to the other tech-                            ComponentFactoryImplementation
                                                                                                               ComponentFactory.createLable()
                niques. ”0” depicts the neutral evaluation regarding the criterium                             ComponentFactory.createButton()
                and compared to the other techniques.                                                                    <>
                                                                                                                     ComponentFactory
                                                                                                                     createLable()
                4.    CaseStudy                                                                                      createButton()
                InthissectionweevaluatethedesignpatternsimplementedinOOP,                                            getName()
                AOP,andFOPindetail.                                                                            RegularFactory FramedFactory
                   Hannemann et al. use Java3 to implement design patterns in                                                  createLable()
                OOP and use AspectJ to implement the aspect-oriented counter-                                                  createButton()
                parts. We use the AHEADToolSuiteforimplementingthepatterns                                     getName()       getName()
                in FOP.                                                                                 Figure 8. Abstract Factory through AOP.
                4.1   TheAbstractFactoryDesignPattern
                4.1.1   Intention                                                              factory. Consequently, all GUI elements that should be created
                    Provide an interface for creating families of related or de-               by the factory have to be of the type that is referred to by the
                    pendentobjectswithoutspecifyingtheirconcreteclasses[13].                   factory class for the according kind of GUI elements, e.g., the
                4.1.2   Implementation                                                         method createLabelofthefactory ComponentFactory lim-
                                                                                               its the type of possibly created label objects to be subtype of
                OOP solution.     Hannemann et al. applied the pattern to create               the class JLabel (Fig. 6, Line 2).
                different kinds of one graphical user interface (GUI) [15].                    Different factories may create the same GUI element classes
                   Each factory class creates GUI elements of different kinds,                 and thus introducing code replication.
                e.g., buttons or labels, and of different properties for each kind             If the implementationofthemethodscreateLabelorcreate-
                of GUI element, e.g., one factory object creates framed or regu-               Button should vary for all factory classes in the same way ei-
                lar elements of different kind (e.g., Button). All GUI elements                ther all classes or the common superclass has to change. This
                (e.g., of type Button or Label), that are created by one factory               introduces code replication if both variants of the implementa-
                class (e.g., FramedFactory or RegularFactory), have compat-                    tion should be available.
                ible properties, e.g., all elements are framed or all elements are
                regular. The properties of GUI elements created by different fac-           AOPsolution.     In the AOP implementation the factory class can
                tories differ and may be incompatible. Each GUI is created using            create GUI elements, e.g., of type Button, differently without con-
                onefactoryandthusallelementsofoneGUIhavecompatibleprop-                     ditional statements or subclasses of the factory class. The meth-
                erties, the elements of different GUI may have different properties         ods that create the GUI elements are detached into the aspect
                because they were created by different factories. Hence, the choice         ComponentFactoryImplementation(Fig.8)andareintroduced
                of the factory class implies the properties of the graphical elements       ondemand.
                that are created. Different factory classes, i.e., FramedFactory and
                RegularFactory, can be exchanged with respect to the common                 Advantages The advantages of the OOP implementation hold for
                interface ComponentFactory. If a referenced FramedFactory                      the AOP implementation. The interface ComponentFactory
                object is replaced by a RegularFactory object the GUI elements                 can be extended by methods without code replication of the
                created subsequently are framed instead of regular and vice versa              class or its subclasses. Thus, variant implementations of the
                without affecting a client that creates GUI.                                   methods createLabel or createButton can be varied for
                Advantages Exchanging factory objects of different type (e.g.,                 all classes, e.g., FramedFactory, homogenously without in-
                    RegularFactory and FramedFactory) does not affect the                      troducing code replication.
                    client that refers to the interface ComponentFactory. A com-            Disadvantages The AOP implementation does not work with-
                    patible configuration of properties for different GUI elements              out the aspect ComponentFactoryImpl because the methods
                    to be built, e.g., whether all should be framed, is encapsulated           createLabelandcreateButtonaredeclaredintheinterface
                    inside one graphical factory (e.g., FramedFactory).                        ComponentFactory but never implemented by its subclasses.
                Disadvantages The factory classes determine the type for each                  This arises the cognitive distance.
                    kind of GUI element, e.g., a button, that can be created by the            Thevariablecompositionofthefactoryclassmayhampercom-
                                                                                               patibility of GUI elements applied to that factory class.
                3http://java.sun.com/
The words contained in this file might help you see if this file matches what you are looking for:

...Design patterns revisited martin kuhlemann school of computer science university magdeburg germany iti cs uni de abstract label includes b buttoninterface are general solutions for recurring problems and settext click used to develop exible reusable modular software with gettext object oriented programming oop prior studies have shown a lack modularity in aspect framedlabel button orientedprogramming aop aimsatimprovingexibility reusabil ity designs case study han nemann kiczales argued that improves the imple figure umlnotation classes interfaces mentation gof feature fop is new technique also aims improve background this paper we com pare quantiative pattern implementations evaluate methods variables merged into sign respect show posingclassesoopprovidesmechanismsofinheritanceandobject performs best compared composition variability achieved through poly morphismofclasses propose advantageous class ar rangements frequently requirements re quirements described by roles interacting obje...

no reviews yet
Please Login to review.