Tool Support for Feature-Oriented Software Development

Transcription

1 Tool Support for Feture-Oriented Softwre Development FetureIDE: An Eclipse-Bsed Approch Thoms Leich Sven Apel Lur Mrnitz ABSTRACT Softwre progrm fmilies hve long trdition nd will gin momentum in the future. Tody s reserch tries to move softwre development to new qulity of industril production. Severl solutions concerning different phses of the softwre development process hve een proposed in order to cope with different prolems of progrm fmily development. A mjor prolem of progrm fmily engineering is still the missing tool support. The vision is n IDE tht rings ll phses of the development process together consistently nd in user-friendly mnner. This pper focuses on AHEAD, prominent design methodology nd rchitecturl model for feture-sed progrm fmilies. We present our first results on developing n Eclipse-sed IDE tht supports uilding progrm fmilies following the AHEAD rchitecture model. Strting from current weknesses nd pitflls in implementing progrm fmilies we outline severl chllenges of the feture-sed development process. Thereupon, we present our ides to fce these chllenges nd resulting integrted tool chin sed on Eclipse. 1. INTRODUCTION In recent yers the ide of progrm fmilies (.k.. product lines 1 ) hs een discussed to overcome the softwre crisis. The key ide is to uild not individul progrms, ut fmily of similr progrms. Progrm fmily memers re grouped y their commonlities. AHEAD is n rchitecturl model nd design methodology to implement progrm fmilies [4]. The ide of the AHEAD model is to decompose progrms into seprte modulr units (fetures) nd to compose stcks of fetures to derive concrete progrm. When dding new progrms to fmily existing fetures of other progrms cn e reused. This is lso known s step-wise refinement. The enefit is mintinle, compre- 1 Although there is sutle difference etween progrm fmilies nd product-lines (see [5]) we use these terms synonymously. Permission to mke digitl or hrd copies of ll or prt of this work for personl or clssroom use is grnted without fee provided tht copies re not mde or distriuted for profit or commercil dvntge nd tht copies er this notice nd the full cittion on the first pge. To copy otherwise, to repulish, to post on servers or to redistriute to lists, requires prior specific permission nd/or fee. Copyright 200X ACM X-XXXXX-XX-X/XX/XX...$5.00. hensile softwre tht cn esily e reused, configured nd extended. AHEAD proposes compositionl progrmming: It generlizes the concept for fetures nd feture refinement. The AHEAD Tool Suite 2 provides set of tools tht support progrmming in the AHEAD style. However, using the AHEAD Tool Suite is still hrd chllenge, since most of the functionlity is provided y commnd-line tools. To ring the AHEAD model to widely ccepted solution for uilding softwre in prxis n dequte IDE tool support is indispensle. This rticle focuses on providing IDE support for progrm fmily development. Firstly, we sketch out specil chllenges for uilding progrm fmilies using the AHEAD model. Therey, we do not only focus on design nd progrmming ctivities ut lso on the preliminry nlysis phse nd susequent configurtion support. We perceive fetures s the se concept tht is used in ll development phses. Consequently, we present tool-driven concept tht improves the overll Feture-Oriented Softwre Development (FOSD) Process to support reuse of informtion from different development phses. Moreover, we discuss our solutions on how to enforce consistent development process. We propose generting nd checking mechnisms tht help to gurntee consistent dt in etween the phses. Furthermore, we introduce feedck mechnism tht propgtes extrcted implementtion knowledge ck to the design nd nlysis phse. This llows us to use strct design informtion in the configurtion process in order to overcome the complexity of the configurtion process. Additionlly, we present our first results providing IDE-support for the comintion of Feture-Oriented Progrmming (FOP) nd Aspect-Oriented Progrmming (AOP). 2. BACKGROUND Feture-Oriented Softwre Development (FOSD) is the overll process of developing softwre systems in terms of its fetures. FOSD ims on nlyzing, designing, nd implementing fetures in progrm fmilies. Following this ide we utilize for the domin nlysis the Feture-Oriented Domin Anlysis (FODA) [7]. The design is sed on stepwise refinement nd the collortion design [12], nd the implementtion is sed on Feture-Oriented Progrmming (FOP) nd Mixin Lyers [12]. 2.1 Feture-Oriented Softwre Development 2

2 FODA: With the domin nlysis feture modeling is n pproprite method [7]. The gol of FODA is to nlyze the considered trget ppliction scenrios nd to derive the required nd optionl fetures. Since the focus of FODA is on domin of pplictions the resulting fetures re chosen with regrd to whole fmily of systems. The results of feture modeling re feture models tht descrie the fetures, their reltions, constrints, nd dependencies [5]. The models express vrition points nd commonlities of the trget-progrms in n strct nd implementtion independent wy. Fetures re orgnized in hierrchicl wy (see Fig. 1). B A C E F G H I J K Figure 1: Exmple feture tree Step-wise Refinement nd Collortion Design: Step-wise refinement nd the collortion design re methods to design softwre incrementlly, using miniml uilding locks, nd strting from miniml se [12]. Exchnging, dding nd removing such uilding locks, lso clled lyers, yield reusility, extensiility, nd customizility. Fetures 3 re sic uilding locks tht stisfy intuitive user formulted requirements on the softwre system. Btory et l. hve mpped this concept to the oject-oriented world [3, 12]. They hve oserved tht new softwre feture often extends or modifies numerous existing clsses. Bsed on this oservtion, they perceive fetures s collortions of clss/oject frgments, lso referred to s roles. Figure 2 shows result of the step-wise refinement nd collortion design, stck of collortions (fetures). Clsses re rrnged verticlly (C 1 C 3). Collortions re rrnged horizontlly nd spn severl clsses (L 1 L 3). Severl fetures of softwre system result in stck of collortions. Collortions with the sme interfces re esily exchngele. They re n instnce of lrge-scle components [3]. L 1 L 2 L 3 C A C B C C Figure 2: Stck of collortions FOP: Mixin Lyers re one pproprite technique to implement collortions in step-wise mnner. As mentioned, the sic ide is tht fetures re often implemented y collortion of clss frgments (.k.. roles). A Mixin Lyer is sttic component encpsulting frgments of severl different clsses (Mixins) so tht ll frgments re composed consistently. Advntges re the high degree of modulrity nd the esy composition. The AHEAD Tool Suite, 3 We use the terms feture nd lyer s synonym for collortion. D including the Jk lnguge, implements AHEAD for Jv. FetureC++ 4 implements the AHEAD model for C++. Using the Jk-lnguge or FetureC++ Mixin Lyers re represented y directories of the file system. Mixins re represented y included source files. Therefore, Mixin Lyers hve no textul representtion t code level. An eqution file specifies which fetures re required for progrm configurtion. It defines ordered feture collections s lgeric expressions. Those Mixins found inside the directories re ssigned to e memers of the enclosing Mixin Lyers. Design Rule Checking: Type checking is provided y the underlying lnguge, ut it does not ctch deep semntic composition violtions. Not ll comintions of fetures re semnticlly correct. Selecting feture my enle or disle the selection of other fetures. Design rule checking (DRC) [4] helps to overcome this prolem. Defined s ttriutive grmmrs the progrmmer specifies these checks. Attriutes re vlue nnottions nd predictes over these nnottions tht determine which syntcticlly-legl comintions of tokens re semnticlly correct. 3. CHALLENGES OF FOSD The following considertions re sed on our experiences in developing FetureC++ [2] nd in uilding progrm fmilies in the re of emedded dtses [9] nd middlewre [1]. We see three mjor fields of interest: (1) the chllenges regrding the missing tool support of the FOSD process, (2) missing support for coding Mixin Lyers, nd (3) chllenges ccording to further improvements of FOP. 3.1 Supporting the FOSD-Process The ide of developing progrm fmilies is not to uild only one ppliction, ut rther the process of uilding fmily of pplictions. There is rod spectrum of different sources of informtion during the development process of progrm fmily. Without integrted softwre visuliztion tools for displying, connecting, nd mnging the different sources, s well s nvigtion support, the hndling of the progrm fmilies with more thn 1,000 fetures is not fesile. Moreover, to void filures nd to enforce consistent development process n utomtic genertion nd checking of models is necessry. We consider two mjor prolems of the FOSD process: Inconsistent sttes etween development phses: FOSD is phse-oriented development process. Without hving tool support lot of informtion regrding the different phses hs to e redundntly fed into the different development phses. This cuses filures nd inconsistent sttes. One exmple is tht informtion of FODA re not connected to the design nd implementtion phses, e.g. constrints, dependencies, nnottions represented in feture digrms re not present in other phses. In susequent phses the progrmmer hs to integrte nd evlute these reltionships mnully. This is errornous nd leds nd redundnt work. Furthermore, softwre engineering is seldom strightforwrd process. Often progrmmers discover deeper reltions etween fetures not until the implementtion phse. This encountered informtion hs to e ck propgted to the previous softwre engineering phse. 4 d/fcc/

3 Deling with the complexity of the configurtion: Building concrete fmily memers using AHEAD or FetureC++ requires lot of implementtion knowledge. This is ecuse of fetures interct with ech other minly t implementtion level. Progrm fmilies consisting of mny fetures ( 100) re hrd to hndle. Moreover, reltionships nd dependencies etween them re not to ctchle y humns. During the development of emedded middlewre nd dtse systems we oserved tht due to the high vriility in this field with millions of possile configurtion vrints the configurtion process ecomes impossile without tool support. Deling with these prolems the configurtion process hs to e lifted to more strct level in order to hndle the complexity. 3.2 Supporting FOP Reding or writing code is still the most used wy of uilding nd understnding softwre. The min tsks of tool support in progrmming code is to point the progrmmer in n esy wy to the right loction of the source code nd help him to red, modify, nd/or write the code. Although the lnguges Jv nd C++ nd their feture-oriented extensions Jk nd FetureC++ only differs in hndful of key words, it is still hrd chllenge to use them. In ojectoriented IDEs the clss view is the dominting element of representtion. Insted, with FOP, the min suject of interest re fetures. Fetures contin severl softwre rtefcts tht contriute to the feture s functionlity. 5 Stndrd oject-oriented IDE-functionlity s Eclipse supports for Jv e.g. source code completion, syntx checks on demnd, clss nvigtion nd deugging support, re not ville for FOP. Furthermore, FOP yields some specil prolems: Hndling the complexity of feture interctions: Fetures interct with ech other in mny wys. These interctions result in dependencies etween different fetures in tht wy tht fetures exclude or require other fetures. The progrmmer must tke gret cre in identifying every interction efore he cn implement or modify feture. In AHEAD nd FetureC++ fetures hve no direct textul representtion. Therefore, dependencies re not explicitly represented. This complictes the development process. Supporting DRC specifiction: As mentioned in Section 2 the specifiction of semntic correctness is enforced y design rules using n ttriutive grmmr. Unfortuntely, the progrmmer hs to mp the knowledge of feture dependencies of the nlysis mnully to the design nd implementtion phse. This nontrivil tsk, not user friendly, nd in most cses redundnt work for the progrmmer. 3.3 Comining AOP nd FOP Aspect-Oriented Progrmming (AOP) is prominent technique to loclize, seprte, nd modulrizes crosscutting concerns [8]. Thus, it is lso dequte for uilding progrm 5 Although the FOP concept llows the refinement of other frgments like UML-digrms or documenttion we concentrte on implementtion units, i.e. clsses in this pper fmilies. The ide ehind AOP is to implement so clled orthogonl fetures s Aspects. This prevents the known phenomen of code tngling nd scttering. The core fetures re implemented s components, s with common design nd implementtion methods. Using join point specifictions (pointcuts), n spect wever rings spects nd components together. There re severl discussions on seprting crosscutting concerns using AOP nd FOP [11, 10, 2]. All current pproches focus on lnguge support. Developing FetureC++, we discovered tht visulizing dependencies of spects nd fetures in different context views would e extremely helpful for the progrmmer. These kinds of views cn help to control the powerful comintion of AOP nd FOP. However, there re first ttempts to chieve tht for pure AOP, e.g. the AcpectJ Visuliser 6. A second very importnt issue is the support of deugging functionlity. AHEAD nd FetureC++ re source-tosource code trnsformtion systems. The mpping of the runtime-deugging code in the originl source code is hrd chllenge, especilly when integrting AOP support. 4. IDE SUPPORT FOR FOSD Since Eclipse is eing widely used y growing user community nd it is open to trying out new ides, we implemented FetureIDE s n Eclipse 3.0 plug-in. Ech component of the workench is extensile nd customizle vi the plug-in interconnection model tht supports ny numer of nmed extension points nd ny numer of extensions to one or more extension points in other plug-ins. Moreover, the elementry components of n IDE, such s the workench, file nvigtor, wizrds, text editor, componentversion mngement, nd pulishing services re lredy ville. Besides the stndrd functionlity we hve used the GEF nd Visuliser plugin. Due to these fcts the implementtion process ws reltively esy nd strightforwrd. 4.1 FOSD-Process A mjor gol of the FetureIDE project is to hndle the complexity of the progrm fmily development process. Tking n mitious stnce, we clim tht the ultimte gol of our work is to ecome the preferred wy of developers of looking t softwre in ll phses. Therefore, we utilize visuliztion nd interction techniques, e.g. detil nd overview, detil on demnd, nd grphicl hints. Most of the functionlity is quite similr to the stndrd Jv IDE. We elieve only this will help to ring FOP to n widely ccepted progrmming prdigm Preventing Inconsistent Sttes Preventing inconsistent sttes is enforced y mpping functions tht connect ll phses of the development process. The centrl elements of these mpping functions re the fetures nd their reltionships nd constrints. Doing so, the results of FODA re propgted to the design phse nd ll fetures re mpped to collortions. An heuristic function genertes hlf-order of lyers (see Fig. 3). This propgtion helps the progrmmer during the design process to define concrete sequence of the lyer stck. Furthermore, the dditionl reltions re trnsferred into the corresponding lyers. If, e.g., two fetures exclude ech other, this reltion is lso known in susequent phses (e.g. 6

4 Anlysis Design preliminry design for lyer c heuristic sed trnsformtion preliminry design for lyers c,d,e d,e d e Figure 3: Mpping Functions implemented lyers). Doing so, it is not llowed to use or refine the functionlity of these lyers. As result of the design phse the reltionships etween fetures re further refined. Using this informtion the implementtion structure e.g. file directory folders, implementtion files, nd DRC-file re generted. However the development process is seldom strightforwrd. Commonly, new informtion re collected during the design n implementtion phses, which re inconsistent to existing informtion from previous phses. It is very common to find tht feture hs to e further differentited. According to our model, this hs to e ck propgted, ecuse it is not llowed to crete new implementtion files for non existing nlysis fetures. Only this restricted model enforces consistency etween ll development phses nd improves the qulity of the resulting progrm fmily rchitecture Supporting the Configurtion Process Feture digrms provide n strct nd intuitive representtion of the vrition points of progrm fmilies. Therefore, these digrms re perfect strting points to improve the configurtion process. Due to (1) chieving consistent nd synchronized sttes etween ll phses nd due to (2) the one-to-one mpping of fetures to their counterprts in susequent development phses we re le to utilize the strct feture tree to ssist the configurtion process. A drwck of this strct feture model is tht not ll reltionships re presented. Borrowed from [13] we improved our model with detiled informtion out dditionl reltionships from the design nd implementtion phse. Avoiding n overkill of informtion the dditionl informtion is highlighted only on demnd in the feture digrm. Figure 4 shows the configurtion process. According to the chosen feture PhysAcessMethod dditionl reltionships re displyed in the digrm. 4.2 Supporting FOP The most chllenging prolem rises due to the fct tht the refinement chins re highly vrile. Code completion fetures re relized using n on-the-fly nlysis of the collortion stck. Context sed views for nlyses of dependencies re essentil for progrmmers nd designers Hndling the complexity of feture interctions Figure 4: Feture Tree with DRC-Hints There is rod spectrum of different sources of informtion out feture interctions. To overcome this complexity we used different views on the implementtion units. The creted collortion stck is the min view ecuse it provides good overview of the glol structure. Additionlly, this view is used for nvigtion through the implementtion units. Severl filters llow the user to djust the complexity of the representtion (file type, file nme, reltionship to other fetures, refinement level). Figure 5 shows the collortion view. The representtions of the clss frgments re colored ccording to their type of the linked implementtion file, e.g. lue for clsses, white for documenttion, etc. Figure 5: Collortion Editor With the collortion view the progrmmer hs good opportunity to get n overview of the fetures nd their refinement hierrchy. Wht is still missing is possiility to get n overview of the refinements t implementtion level. Files tht implement the sme clss frgments cn refine or dd different code rtifcts. For the progrmmer it is very difficult to extrct these reltionships from textul code. We used nother representtion to give the progrmmer proper overview. Our visuliztion is sed on n pproch which is clled Seesoft [6]. Figure 6 shows n exmple: The oxes represent clss frgments tht compose the resulting clss. Thus, the progrmmer gets insight which feture contriutes to which clss. The length of the oxes is determined y the size of the corresponding implementtion file. The colored lines

5 6. CONCLUSIONS FOSD is importnt to uild future progrm fmilies. Current reserch on FOSD focuses minly on lnguge level support. Current tools re mostly commnd line sed. We rgue tht tool support for FOSD is indispensle to increse the cceptnce of feture-oriented techniques. In this contriution we fetured discussion on chllenges of developing softwre in feture-oriented style using common techniques nd tools. Strting from identified weknesses we present FetureIDE tht solve certin prolem of this field. Due to the integrtion into Eclipse we hope to increse the cceptnce of FOSD. 7. ADDITIONAL AUTHORS Gunter Ske ( Mgdeurg, Germny, emil: ske@iti.cs.uni-mgdeurg.de). Figure 6: Feture Frgment Visulizer in the oxes represent code frgments. Different code frgments re encoded y different colors. The width of the colored line encodes the size of the ccording code frgment. The colored lines re connected to the corresponding code nd cn e used to go quickly into the code to the right position. This functionlity helps the progrmmer to quickly mke decisions tht contriute to other clss frgments Design Rules AHEAD ssumes tht design rules re creted during the implementtion phse. We lredy strt creting design rules during the nlysis nd design phse. The design rules re utomticlly extrcted from the modelled reltionships nd constrints of these phses, e.g. encoded in feture digrms, collortion stcks, etc. Therey the progrmmer just hs to dd the design rules for those reltionships nd constrints which re extrcted during the implementtion process. Due to this proceeding, the concept of DRCs ecomes more prcticl nd cn e used for esily enforcing consistency. The design rules re concentrted view on the reltionships nd constrints in ll phses. Therefore inconsistency cn e esily detected. 5. FURTHER RESEARCH As in Section 3.3 discussed AOP is le to enhnce FOP in providing mechnisms to del with certin crosscutting concerns. A prolem of current AOP lnguges is tht the inding of spects is independent of the current development stges. Tht mens tht spect my ffect susequent integrted fetures. This my led to filures nd unpredicted progrm ehvior. Using spect-enhnced FOP the power of spects cn e controlled. In [2] we present lnguge support to solve this prolem. Using this mechnism we discovered tht in lrge-scle systems this lnguge cpilities further hs to e supported y visuliztion nd genertive techniques. 8. REFERENCES [1] S. Apel nd K. Böhm. Towrds the Development of Uiquitous Middlewre Product Lines. In ASE SEM 04, Springer, LNCS [2] S. Apel, T. Leich, M. Rosenmüller, nd G. Ske. FetureC++: On the Symiosis of Feture-Oriented nd Aspect-Oriented Progrmming. In GPCE 05, Springer, LNCS, [3] D. Btory nd S. O Mlley. The Design nd Implementtion of Hierrchicl Softwre Systems with Reusle Components. ACM TOSEM, [4] D. Btory, J. N. Srvel, nd A. Ruschmyer. Scling Step-Wise Refinement. IEEE TSE, 30(6), [5] K. Czrnecki nd U. Eisenecker. Genertive Progrmming: Methods, Tools, nd Applictions. Addison-Wesley, [6] S. Eick, J. Steffen, nd E. Summer. Seesoft tool for visulizing line oriented softwre sttistics. In IEEE TSE, [7] K. Kng et l. Feture-Oriented Domin Anlysis (FODA) Fesiility Study. Technicl report, Softwre Engineering Institute, Crnegie Mellon University, Pittsurgh, [8] G. Kiczles et l. Aspect-Oriented Progrmming. In ECOOP, [9] T. Leich, S. Apel, nd G. Ske. Using Step-Wise Refinement to Build Flexile Lightweight Storge Mnger. In ADBIS, [10] R. E. Lopez-Herrejon, D. Btory, nd W. Cook. Evluting support for fetures in dvnced modulriztion technologies. Technicl report, [11] M. Mezini nd K. Ostermnn. Vriility Mngement with Feture-Oriented Progrmming nd Aspects. In ACM SIGSOFT FSE, [12] Y. Smrgdkis nd D. Btory. Mixin Lyers: An Oject-Oriented Implementtion Technique for Refinements nd Collortion-Bsed Designs. ACM TOSEM, [13] P. Sochos, I. Philippow, nd M. Rieisch. Feture-Oriented Development of Softwre Product Lines: Mpping Feture Models to the Architecture. In Oject-Oriented nd Internet-Bsed Technologies. Springer, LNCS, 2004.