R

Ta

b

a

ARRAA

KUOSS

1

apmstcwfsufaacN2(

2p

B

p

0d

The Journal of Systems and Software 84 (2011) 2234– 2252

Contents lists available at ScienceDirect

The Journal of Systems and Software

j ourna l ho me page: www.elsev ier .com/ locate / j ss

euseTool—An extensible tool support for object-oriented framework reuse

oacy C. Oliveiraa,b,∗, Paulo Alencarb, Don Cowanb

PESC/COPPE Federal University of Rio de Janeiro, BrazilDavid Cheriton School of Computer Science, University of Waterloo, Canada

r t i c l e i n f o

rticle history:eceived 3 November 2010eceived in revised form 6 June 2011ccepted 14 June 2011vailable online 21 June 2011

a b s t r a c t

Object-oriented frameworks have become a popular paradigm used to improve the software developmentlifecycle. They promote reuse by providing a semi-complete architecture that can be extended throughan instantiation process to integrate the needs of the new software application. Instantiation processesare typically enacted in an ad-hoc manner, which may lead to tedious and error-prone procedures. Thiswork leverages our previous work on the definition of RDL, a language to facilitate the description of

eywords:MLbject-oriented frameworkoftware processoftware reuse

instantiation process, and describe the ReuseTool, which is an extensible tool to execute RDL programsand assist framework reuse by manipulating UML Diagrams. The ReuseTool integrates a RDL Compilerand a Workflow Engine to control most of the activities required to extend a framework design and,therefore, incorporates application-specific needs. This work also describes how the tool can be extendedto incorporate new reuse activities and provides information of its use based on an exploratory Case Study.

. Introduction

With the popularity of object-oriented languages such as Javand C++, and the pressure for improving software developmentroductivity, the concept of object-oriented frameworks gainedomentum and became the de facto approach to develop complex

oftware systems. In essence, frameworks are reusable assets inhe form of quasi-complete and flexible software components, spe-ially assembled to reduce the effort to develop new applicationsithin a specific domain (Bosch et al., 1999). An object-oriented

ramework defines a set of permanent features known as frozen-pots to deliver unchangeable functionality (Pree, 1995). It alsoses typical object-oriented techniques to incorporate flexibleeatures, the hot-spots (Pree, 1995), which must be extendedppropriately to integrate application-specific needs (Markiewicznd Lucena, 2001) (Mattsson and Bosch, 2000). Examples of majorurrent object-oriented frameworks are: J2EE (J2EE, 2010), Dot-ET (DotNet, 2010), Hibernate (Hibernate, 2010), JUnit (Junit,010), Eclipse (Eclipse, 2010), Struts (Struts, 2010) and MooToolsMooTools, 2010).

In contrast to Software Product Lines (Atkinson et al.,001), where reuse occurs from putting together a set ofre-defined software components, developers reusing object-

∗ Corresponding author at: PESC/COPPE Federal University of Rio de Janeiro,razil. Tel.: +55 21 2562 8672.

E-mail addresses: toacy@cos.ufrj.br, toacy@csg.uwaterloo.ca (T.C. Oliveira),alencar@csg.uwaterloo.ca (P. Alencar), dcowan@csg.uwaterloo.ca (D. Cowan).

164-1212/$ – see front matter © 2011 Elsevier Inc. All rights reserved.oi:10.1016/j.jss.2011.06.030

© 2011 Elsevier Inc. All rights reserved.

oriented-frameworks need to engage in a more difficult reuseprocedure, which typically involves understanding the frameworkdesign rationale and programming. For example, a developer mustbe knowledgeable about the order in which hotspots are refinedsince they may need to be refined in a specific implicit sequence.Considering frameworks may contain several hotspots, such reuseorder should be clearly specified to avoid faulty reuse processes(Fayad et al., 1999) (Kirk et al., 2005) (Hou et al., 2005). Moreover,it is expected that the reuse processes of complex frameworks aresupported by tools to assist handling all the constraints that needto be satisfied when reusing a framework.

In this work we describe the ReuseTool as a way to assistobject-oriented frameworks reuse. The tool rationale is to orches-trate reuse actions within a reuse process that is specified by theframework developer and executed interactively by the frame-work reuser. The reuse process is specified using the RDL (ReuseDescription Language) (Oliveira et al., 2004, 2007, 2002), which isa special language that allows the specification of process flowssuch as sequencing, loops and branches, and also supports com-mands to manipulate UML-based framework designs. As a result,the ReuseTool is capable of tailoring the UML (2010) frameworkdesign with new model elements that will represent the needs ofthe application under development.

This work is organized as follows. In Section 2 we describe theapproach overview using a fictitious reuse project. In Section 3 we

describe the ReuseTool Architecture and the associated SoftwareReuse Process. Section 4 illustrates the approach with a detailedexample and also brings information about our experience usingthe ReuseTool. As RDL is a major component in our solution, Section

T.C. Oliveira et al. / The Journal of Systems

5St

2

iItaatepaads

tTwwhht

TiUabMmM

iMmfwnla

e

Fig. 1. ReuseTool operation.

describes how RDL was enhanced to cope with the tool needs.ection 6 describes how the ReuseTool can be extended by exposinghe tool hotspots and the associated RDL program.

. Approach overview

As pointed out by Krueger (Krueger, 1992), most reuse processesnvolve four dimensions: Abstraction, Selection, Specialization andntegration. The Abstraction and Selection dimensions deal withhe cognitive aspects of identifying a set of possible reusable assetsnd selecting the most suitable to implement the requirementsssociated with the new application. The cognitive nature of thesewo dimensions relies on the fact that requirements are typicallyxpressed with natural language, which demands human inter-retation. The Specialization dimension appears once the reusablertifact is chosen and needs to be tailored to incorporate thepplication specific increments. Last but not least, the Integrationimension deals with combining several reusable artifacts into aingle system.

In this scenario, the ReuseTool aims at facilitating the Specializa-ion dimension with possible effects to Selection and Integration.he Specialization dimension for object-oriented frameworks dealsith adding new design elements and code to the original frame-ork design, where each new element connects to a framework’sotspot. The connection between the new design element and theotspots extends the framework with information that is specifico the application under development.

In order to orchestrate the framework specialization, the Reuse-ool takes an RDL Program and the Framework UML Model asnput and produces the Application UML Model. The FrameworkML Model represents framework’s classes and relationships andlso provides useful information on how the framework code cane obtained. The RDL program details how the Framework UMLodel should be manipulated to accommodate new design ele-ents related to the new application and the Application UMLodel is the final application design.As illustrated in Fig. 1 the process of executing the ReuseTool

s quite straightforward. In Fig. 1-1 (Circle 1) the Framework UMLodel and the RDL Program are passed to the tool. The frameworkodel has classes Text and Style to indicate that the hypothetical

ramework is capable of applying styles to a given text such as in aord processor. The framework developers understand they can-ot provide all types of styles so, in this case, they have decided to

eave the style feature as a hotspot that must be configured by thepplication developer.

Fig. 1-2 (Circle 2) shows how the framework developers havexposed the Style hotspot and how to extend it. The rationale is

and Software 84 (2011) 2234– 2252 2235

based on the fact that the framework design has the class Styleand this class is responsible for the style feature. As a result, thespecialization of hotspot Style requires the specialization of the Styleclass, which is represented in the RDL Program by the statement“CLASS EXTENSION (Style,myPack,?);”.

The CLASS EXTENSION command indicates the class Style mustbe specialized with a new class that will represent the new style.The question mark (?) passed as parameter is a RDL feature calledReuser Interaction to indicate a placeholder for a name that shouldbe given at runtime (i.e. reuse-time) by the framework reuser. TheReuser interaction is shown in Fig. 1-3 (Circle 3), where the reuserindicates the new style will be called Header.

The result of the reuse process is an extended model calledthe Application UML Model (Fig. 1-4), which contains the designelements that represent application specific requirements. In ourexample, the new model has the class Header as a sub-class for classStyle, satisfying the reuser requirements from Fig. 1-4 (Circle 4).

Besides orchestrating reuse actions along the Specializationdimension, the ReuseTool can also impact the Selection and Inte-gration dimensions. Selection can take into consideration the effortneeded to reuse a framework measured in terms of the complexityto execute RDL programs. Frameworks with complex RDL programsmay be avoided as a higher complexity may indicate more reuseeffort is needed. The ReuseTool can also assist with Integration,making it more straightforward since some integration actions canbe incorporated into the RDL language as a new type of reuse action.Further impact on the Selection and Integration dimensions are stillunder investigation.

3. Reuse tool

The ReuseTool aims at helping developers to follow a strict pro-cess when working on the Specialization Dimension as discussedin Section 2. By a strict process we mean a process that guides theframework reuser to extend all the required hot-spots in a sequencethat is pre-defined by the framework engineer, thus following thesame rationale used in the framework implementation.

In order to create a process-based execution environment wehave established a set of requirements for the tool.

Adopt current trends. Besides the use of RDL, the tool should followcurrent trends in the Information Technology scenario to avoida steep learning curve and allow further integration with otherapproaches.Handle object-oriented frameworks. The object-oriented program-ming paradigm has been widely adopted, and has vast frameworkexamples we can leverage on. It also provides a potential marketfor our approach.Provide ways to pause and resume the process. Since a reuse processcan be lengthy, the ability put the process in a suspension modeand resume with no loss of context is an important feature.Provide infrastructure for a multi-“reuser” scenario. Nowadaysframeworks have to tackle multi-faceted scenarios, being typi-cally complex and requiring different types of expertise duringcustomization. As a result, the framework reuse process becamemulti-user by nature and our tool should provide means to supportit.Extensibility. RDL provides the building blocks to representthe reuse process and manipulate UML Models. However it’simportant to leave space for improvements, such as han-

dling forthcoming UML characteristics and new programmingparadigms such as Aspect-Oriented Programming. In this context,the tool must be open for extension, and become itself a frameworkthat can be extended to handle other reusable assets.

2236 T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252

aed

3

Esd1uogawbsw

worew

wdtm

nE

3

pPRPb

gehewc

tt

Fig. 3. RDL BNF in the ANTLRWorks tool.

Fig. 4. Code generation.

The next ReuseTool component to be described is the JPDL Pro-cess Language. JPDL is the jBPM Process Definition Language, anXML-based representation to declarative workflow definition. It

Fig. 2. ReuseTool architecture.

In order to cope with all the requirements we have designednd developed, a software architecture that integrates a workflowngine, a RDL compiler, and a Java object-oriented framework asescribed in Section 3.1.

.1. Architecture

Reusing a framework is a human-oriented process by definition.ach framework hotspot must be extended with application-pecific information that is essentially known by the applicationevelopers at reuse time. According to (Georgakopoulos et al.,995), a suitable way to represent a human-oriented process is bysing workflow processes. In summary, a workflow organizes a setf human-tasks, system-tasks and control flow structures to enact aiven process. For a reuse process, human-tasks are those for which

reuser introduces application-specific information. In the sameay, system-tasks are those devoted to manipulate UML models

ased on the information presented by the reuser, and control flowtructures allow the representation of loops, decisions, and otherorkflow patterns (van der Aalst et al., 2003).

It is important to mention that our process is representedith RDL, an imperative language specially created to specify

bject-oriented framework reuse. For that reason, our workflow isepresented neither as set of icons such as in YAWL (van der Aalstt al., 2005) and JPDL (JPDL, 2010) nor with XML as in xPDL, butith an algorithm-like script.

In order to create a tool that is capable of executing a RDL-basedorkflow that takes into consideration the list of requirementsescribed previously, we have designed a software architecturehat uses a workflow engine, a parser generator, a UML model

anipulation library and some helper classes.As illustrated in Fig. 2, the architecture has three main compo-

ents: the Transformer, the JPDL Process Language and the Processxecution Machine.

.1.1. The transformerThe Transformer aims at converting a RDL Program into a JPDL

rocess representation. It has three sub-components: the Lexer, thearser and the Code Generator. The Lexer and the Parser assure theDL Program is well-formed. We have used the ANTLR (Bovet andarr, 2008) parser generator program to create the Lexer and Parserased on the RDL Grammar as illustrated in Fig. 3.

The CodeGenarator is a set of Java classes that are capable ofenerating JPDL code according to the RDL command semantic. Forxample, Fig. 4a illustrates the CLASS EXTENSION command andow it is converted into a JPDL custom node (b). Note the param-ters Shape, packA and?, which are passed to the RDL command,ere represented as arguments passed to the constructor of the

ustom node.The Lexer, Parser and Code Generator work synchronously. After

he Lexer converts the RDL text into meaningful tokens, the Parserries to identity a sequence of tokens that matches a non-terminal

Fig. 5. Main classes of the transformer component.

symbol described in the RDL Grammar. Once the Parser matchesa valid sequence, it calls the Code Generator to producet the JPDLcode accordingly. We have managed to achieve this level of inte-gration by inserting Java commands into the RDL Grammar, whichis a feature supported by ANTLR. Fig. 5 illustrates the main classesof the Transformer component.1

3.1.2. The process language

1 The developed classes will be further explained in Section 6 when we presenthow the tool can be extended.

stems and Software 84 (2011) 2234– 2252 2237

ahp(jaaom

Tsitatso

ticiFiw

3

dMcatsti

t2ipeuwcutob

pla

3

gaab

T.C. Oliveira et al. / The Journal of Sy

llows the definition of workflow elements such as system tasks,uman tasks, workflow patterns, swimlanes, forks, joins and sub-rocesses. A JPDL file can be deployed and executed with the jBPMJBOSS Business Process Management) engine. Together, JPDL andBPM are integrated in the jBPM Platform, which is a JBOSS (Fleurynd Reverbel, 2003) community product for process representationnd execution. We have chosen the jBPM Platform as it fulfils somef the ReuseTool requirements such as process orchestration in aulti-user environment, process persistency and extensibility.JBPM is oblivious to the nature of the workflow tasks it executes.

asks can be either human-oriented such as signing a document orystem-oriented such as performing a complex computation, butnternally JBPM treats them as an executable item that fits withinhe workflow graph. In fact, JBPM is itself based on the frameworkpproach where tasks are hotspots that can be extended to allowhe introduction of new executable items. We have benefited fromuch extension mechanism to smoothly integrate all RDL reuse-riented tasks and leave space for further additions.

RDL tasks were mapped to JPDL Custom Nodes. We have decidedo use JPDL Custom Nodes as they allow binding a Java class tomplement the desired node behaviour. An instance of the java-lass is created by the underlying process execution machine andnitialized with the parameters passed under the constructor tag.or example, in Fig. 4b the Custom Node with name 7 (seven)s bound to the class org.reusetool.jbpm.pem.ClassExtensionHandler,

hich is responsible for implementing the CLASS EXTENSION task.

.1.3. The process execution machineThe last but most import component of the ReuseTool to be

escribed is the Process Execution Machine. The Process Executionachine, or simply PEM, is responsible for executing the reuse pro-

ess written in JPDL, which will extend the given framework designnd eventually turn it into the application design. To accomplishhis goal, the PEM component extends the jBPM platform with aet of Java classes capable of handling reuse-oriented tasks.2 Reuseasks are those executed by the framework reuser when specializ-ng the frameworks’ hotspots.

The PEM internal structure depends on the type of node used inhe JPDL workflow. According to the JPDL reference manual (JPDL,010), Custom Nodes are place holders for objects implement-

ng the org.jbpm.api.activity.ExternalActivityBehaviour Java interfacerovided by the JBPM library. As a result, when the JBPM workflowngine needs to execute a Custom Node, it actually instantiates theser-defined Java class that implements the associated behaviour,hich in our case is a type of reuse action. Fig. 6 illustrates how PEM

lasses are structured to implement the NEW CLASS reuse actionsed in Fig. 4. It is important to note the whole PEM implementa-ion contains more than 50 classes to support the implementationf all RDL reuse actions (More on the PEM’s internal rationale wille discussed in Section 6.2-Extending the Architecture).

The PEM operates on UML Models specified as “.uml” files. Fig. 7rovides an illustration for the UML File: on the right there is a tree-

ike rendering with classes and associations; on the left there is thectual file content for the class Activity.

.2. Software process for framework reuse

A software process organizes the actions needed to achieve a

iven goal, specifies the individuals that participate in an action,nd also describes the manipulated information. We believe using

software process to expose the ReuseTool functionalities woulde a valuable contribution and also facilitate understanding the

2 We have used the terms “reuse action” and “reuse task” indistinctively.

Fig. 6. PEM classes for the NEW CLASS reuse action.

approach. For this reason we have devised the Software Process forFramework Reuse. The process is specified with the Software Pro-cess Engineering MetaModel (SPEM), which is a standard notationfor representing software processes (SPEM, 2010).

SPEM allows the specification of process elements namelyroles, artifacts and tasks. Roles define a set of characteristics andattributes an individual must possess to execute tasks in a soft-ware process. Artifacts involve the information manipulated by atask in one or more documents. Finally, tasks represent a set ofactions that must be handled by an individual playing a role. A taskcan also contain a list of preceding and succeeding tasks to definethe sequence in which tasks should be handled.

The Software Process for Framework Reuse has two phases,the Framework Development and the Framework Reuse, whichare executed in a sequential order. The Framework Developmentphase is the first to be handled and attempts to create a work-ing object-oriented framework, its associated UML-based designdocumentation and the RDL reuse program. We do not detail thetasks executed in this phase as we believe most approaches to mod-ern software development are capable of developing a frameworkto support these tasks. Nevertheless, the Framework Developmentphase includes one role and two artifacts that will be used in theFramework Reuse Phase and are described in Table 1.

Once the framework is developed and its associated UML Mod-els and RDL Programs are developed the Framework Reuse phasecan occur. This phase aims at tailoring the framework design toinclude the application-specific extensions defined by the frame-work reuser. To achieve its goals the Reuse phase uses two artifactsdefined previously, the Framework UML Model and the RDL Pro-gram, but also involves its own process elements described inTable 2.

Fig. 8 illustrates the Software Process for Framework Reuseusing the SPEM notation. Two phases are represented in the top ofthe figure: the Development on the left and the Reuse on the right.Each phase is described by a workflow diagram that specifies theorder in which each task should occurs. At the bottom of the samefigure we represented the relationships between the model ele-ments. For example at the bottom-right, we show the task DevelopFramework Model and RDL Program performed («performs» sym-bol) by the role Framework Developer to create («output» symbol)the Framework UML Model and RDL Program artifacts.

Although the process specification is presented at once, its

actual execution takes place in two distinct environments, Develop-ment and Reuse. The two environments may differ in time, location,development team and they are typically part of two separate soft-

2238 T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252

Fig. 7. UML file example.

Table 1Process elements for the framework development phase.

Model element Name Description

Task Develop Framework Umbrella task to represent alltasks required to develop theobject-oriented framework.

Develop FrameworkModel and RDLProgram

Focus on developing theartifacts related to the reuseprocess.

Role Framework Developer Responsible for defining theUML Model and RDL Programthat will be used to assist theframework reuse. A personplaying this role must deeplyunderstand the frameworkunderlying concepts andhotspots, and also beknowledgeable in RDL andUML

Artifact Framework UML Model The UML Model must specifythe classes and relationshipsthat describe theobject-oriented frameworkimplementation.

RDL Program The RDL Program organizes the

wpitP

4

al(mwERi

4

eT

Table 2Process elements for the framework reuse phase.

Model Element Name Description

Task Load Framework Modeland RDL Program

Provide to the ReuseTool theFramework UML Model andassociated RDL Program.

Execute Reuse Process Execute the Reuse Process. Thistask is an umbrella task torepresent all possible reuseactions according to the RDLLanguage. Typical reuse actionsthat require reuser interactionand related RDL command are:- Extending aClass → CLASS EXTENSION- Creating apackage → NEW PACKAGE- Iterating on loop → LOOP- Confirming an humantask → EXTERNAL TASK

Role Framework Reuser Responsible for executing theframework reuse process. Mustbe knowledgeable about theapplication needs to extend theframework at the properhotspots. Must also understandthe framework documentation.

Artifact Application UML Model The Application UML Modelcontains the new classes and

reuse actions that will extendthe framework hotspots.

are projects. It is also important to point out that modern softwarerocesses are iterative by nature and tasks are orchestrated accord-

ng to project’s constraints such as time-to-market, budget, andeam allocation. As a result, the tasks described in the Softwarerocess for Framework Reuse may be interleaved with other tasks.

. An illustrative example—the shape framework

This section illustrates how the ReuseTool can be used to extendn existing framework by exploring the artifacts that are manipu-ated in the process. We have chosen the Shapes Diagram EditorGEF, 2010) as our example since it has a comprehensive docu-

entation and is part of the Eclipse Graphical Editing Framework,hat makes it easily available to general public. Further, the Shapes

ditor is a 3rd party implementation, which indicates that theeuseTool is not biased towards our frameworks but can be used

n a broader context.

.1. Shapes framework

The Shapes Diagram Editor is an Eclipse Plug-in developed as anxtension to the Graphical Editing Framework (GEF) (GEF, 2010).he Shapes Framework facilitates development of diagram editors

design elements that representthe application-specific needs.

made out of nodes and connections that can be customized bya developer to represent all sorts of icons and connecting lines,respectively. A typical Shapes instance is shown in Fig. 9 with adiagram customized to handle circles and squares that can be con-nected by solid or dashed lines.

A diagram within a Shapes instance has ordinary drawing fea-tures such as creating nodes and connections, selecting nodes,resizing nodes, deleting nodes, moving nodes and deleting con-nections. Connections can also use a special feature to restrict thelink between two undesired nodes. For example, it is possible torepresent squares and triangles cannot be connected by dashedlines.

In order to provide all its features, Shapes blends itself withGEF, which is Eclipse’s building block for creating graphic editors.Together, GEF and Shapes have several classes that represent anintricate design, allowing the reuser to represent diagrams basedon their model, view and edit parts (controllers), such as in a typi-

cal Model-view-controller pattern. Model represents the semanticsbehind each node; View specifies how nodes are rendered and;and Edit parts connect the Model with the Views. Our goal is to

T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252 2239

Fig. 8. Process e

.

Fig. 9. Shapes look and feel.

Fig. 10. Shapes

lements.

demonstrate how to reuse Shapes using the ReuseTool. Thereforewe will not explain the Shapes’ design rationale but explore its mainhotspots to develop a typical diagram.

Shapes main goal is to facilitate creating new nodes and we havechosen this feature to demonstrate the ReuseTool. In order to createa new node the reuser has to perform three reuse actions:

- Define the new shape model;- Define the new shape look and feel; and- Insert the new shape in Shapes palette.

Fortunately, the representation for the hotspot to developnew nodes using Shapes is straightforward. Fig. 10 presentsthe UML class diagram containing the framework classesorg.eclipse.draw2d.Figure, org.eclipse.gef.examples.shapes.model.Shape and org.eclipse.gef.examples.shapes.ShapesEditorPaletteFactoryThe Shape class is the main participant in the hotspot as it definesa set of abstract methods that must be extended by the applicationreusing the framework. In our scenario, the most important

methods are: getIcon(), getFigure() and canConnect(). The getIcon()method should return the icon that represents the node in thediagram palette to represent the node; the getFigure() methodshould return the graphical elements that represent the node in

hotspots.

2240 T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252

1.COOKB OOK ShapesProduct s2.RECIP E main{3.4. packA = NEW_PACK AGE(FrameworkModel,"org.reusetool.example.myshapeseditor") ;5. LOOP ("Create another shape? ") 6. {7. // PREPARE Images8. EXTERNAL_TAS K("Define 16x16 icon" );9. EXTERNAL_TAS K("Define 24x24 icon" ); 10.11. // Define Shape SubClass12. shapeClass = CLASS_EXTENSI ON(Shape, packA,"?");13.14. // Refine Abstract Meth ods15. m = METHOD_EXTEN SION(Shape,shapeClass,addConnectionAnchor);16. ADD_C ODE(shapeClass,m,"return new ChopboxAnchor(iFigure);");17. m = METHOD_EXTEN SION(Shape,shapeClass,getFigure) ;18. ADD_C ODE(shapeClass,m,"retur n new IFIGURE_SUBCLASS);"); 19. m = METHOD_EXTEN SION(Shape,shapeClass,getIcon); 20. ADD_C ODE(shapeClass,m,"return createImage( \"NEW_SHAPE.gi f\");");21.22. // Configure Palette23. ADD_C ODE(ShapesEditorPaletteFactory,createShapesDrawer ,24. "comp onent = new CombinedTemplateCreationEntry(25. \"NEW_SHAPE \",26. \"Create a NEW_SHAPE sha pe\", 27. NEW_SHAPE.cla ss,28. new SimpleFactory(NEW_SHAPE.class),

ile(

e 1. R

twi

aIirtrsT

Ftrmi

4

Pdmsotpattr

wTRn

the reuser so that the framework can be properly extended. Line 8uses the external task command to remind the reuser he needs to“Define a 16x16 icon.”

29. ImageDescriptor.createFromF

Code Exampl

he diagram canvas; and the canConnect() method should confirmhether the current shape can connect with the target shape that

s passed as parameter.The abstract class Figure is defined in the Eclipse Draw2d library

s a general representation for two dimensional visual elements.t declares several fields to customize the look and feel for graph-cal elements. It also declares the method paintFigure(), which isesponsible for rendering the image. In order to extend this class,he reuser must redefine the paintFigure() method and add theequired visual details. It is important to point out that Eclipse haseveral out-of-the-box visual elements such as Ellipse, Polygon andriangle that can be use as a subclass for Figure.

The last class we need to handle is the ShapesEditorPalette-actory. This class organizes the entries in the palette found inhe diagram editor interface. Reusing ShapesEditorPaletteFactoryequires a precise change to modify its existing java file at theethod createsShapeDrawer(), without damaging the whole system

ntegrity.

.2. Shapes RDL program

Assisting the reuse of the Shapes framework requires an RDLrogram as the one represented in Code 1. In RDL, programs areescribed as cookbooks that contain recipes. Recipes list RDL com-ands (shown in bold) in the same way a procedural language

uch as Java exposes its commands inside procedures and meth-ds. Code 1 also declares the cookbook ShapesProducts (Line 1) andhe main recipe (Line 2). The main recipe starts by creating theackage org.reusetool.example.myshapeseditor (Line 4) to group thepplication-related design elements in a single place. It is impor-ant to observe that variable packA was declared in Line 4 to storehe just created package model element. This was required alloweference to the package element later in the program.

Creating an RDL program requires acknowledging that frame-

ork development and framework reuse occur in different times.

herefore, by the time (framework development time) the ShapesDL program is implemented by the framework developer, theumber of shapes the framework reuser will create during frame-

ShapesPlugin.class, \"icons/crazy16.gif \"),

DL program.

work reuse time is unknown. To mitigate such issue, Line 5 declaresa loop that iterates several times according to the frameworkreuser’s need. The loop surrounds all reuse actions related to shapescreation, from Line 5 to Line 44.

Lines 8 and 9 declare two external tasks. RDL uses an externaltask to indicate the reuser has to perform an action that is impossi-ble to be represented as a model element manipulation. When theReuseTool reaches an EXTERNAL TASK it stops its execution andwaits for the reuser feedback acknowledging the task was com-pleted. For example, the Shapes framework requires an icon to beshown in the palette. An icon is a visual element that cannot berepresented by a design element such as a class, which means nei-ther RDL nor UML can represent it. However, the action of definingthe icon and placing it in the proper folder needs to be executed by

Fig. 11. CLASS EXTENSION with “?” = TriangleShape.

T.C. Oliveira et al. / The Journal of Systems

twfiCatftstdetS

imbtsts

elidtAcAaCsTammiA

experimentation indicates the sequence of reuse actions follows a

Fig. 12. METHOD EXTENSION with addConnectionAnchor.

One of the most important aspects of the ReuseTool ishe creation of the design elements that extend the frame-ork hotspots. Lines 12–42 present several RDL commands

or extending the framework design at specific places tonclude the application-specific requirements. Line 12 uses theLASS EXTENSION command to indicate the class Shape, shown as

hotspot in Fig. 11, needs to be sub-classed. This command referso the package variable packA defined at Line 4 as the containeror the new class. Note the presence of a question mark as thehird parameter in the CLASS EXTENSION command. RDL uses thispecial character to indicate the parameter is unknown at compileime and must be discovered at runtime (reuse-time). Line 12 alsoeclares a variable to represent the just created class for later refer-nce. Following the execution of the CLASS EXTENSION command,he resulting model should contain a new class that extends thehapes class as shown in Fig. 11.

Line 15 shows the METHOD EXTENSION command, which alsontroduces a new design element. The METHOD EXTENSION com-

and indicates a method from the super-class needs to be refinedy a method in the sub-class, which in terms of modelling meanshat a method with matching signature must be declared in theub-class. In Line 15, the method addConnectionAnchor defined inhe class Shape is refined in the sub-class referred by the variablehapeClass. Fig. 12 illustrated the model after executing Line 15.

The ReuseTool assists framework reuse by manipulating designlements according to the hotspots it needs to extend. Neverthe-ess, the gap between the application design and the applicationmplementation, the actual code, can still be considered a hur-le the reuser must overcome. In order to facilitate implementinghe hotspots with application specific code, RDL introduced theDD CODE command. Line 16 illustrates how the ADD CODEommand is used to “add the code snippet” “return new Chopbox-nchor(iFigure);” to the method referred by the variables shapeClassnd m, which point to the class just created and the refined add-onnectionAnchor method, respectively. The text “add the codenippet” was quoted in the previous sentence because the Reuse-ool does not attach plain code to the method but, instead, creates

comment that is linked to the method. The reason for creating theodel element comment is twofold: (i) RDL and UML are program-

ing language agnostic; (ii) the new code depends on application

nformation that is unknown when the RDL program is created.lthough the pre-programmed code fragment may not fit exactly

and Software 84 (2011) 2234– 2252 2241

in the application, we believe it gives valuable information on adirection to be pursued by the framework reuser during applicationimplementation.

Lines 17–34 repeat the METHOD EXTENSION and ADD CODEcommands to extend the methods related to the icon, figure andpalette hotspots. Line 35, however, exposes another RDL feature,the conditional command IF. The conditional command works inthe same way as in an imperative programming language suchas Java, but the expression being specified is an interaction withthe reuser. For example, the Shapes hotspot that restricts howshapes can be connected is optional, so the reuser has to beasked if he wants to extend it or not. Line 35 declares “IF (“AddFeature - Restrict Connections?”) THEN” to request if the reuserneeds to add the feature that restricts shapes connections tothe application. If the answer is positive the ReuseTool executeslines 36 and 37, otherwise it jumps to Line 38. Lines 39–42 alsouse the conditional command but this time to extend the figurehotspot.

4.3. Application scenario

Reusing any asset requires some planning to determine whathotspots will be extended and what information will be provided.In this section we provide the rationale of the application we havedeveloped reusing the Shapes framerwork. We have decided towork on a simple application as our intention was to demonstratethe ReuseTool without overcomplicating the text.

The application requirements can be specified as:

“an application to create a diagram editor that exposes threetypes of shapes: triangles, labelled rectangles and rectangleswith a red cross in the middle. The application also needs torestrict the connection between triangles and labelled rectan-gles.”

After browsing the Shapes hotspots documentation, the reuseridentified the need to create the classes TriangleShape, Labelled-Shape and RedCrossShape to represent shapes, and the classRedCrossFigure to render the rectangle containing a red cross in themiddle. Table 3 contains a trace with the reuse actions executedin the process, considering those classes were created in the orderTriangleShape ⇒ LabelledShape ⇒ RedCrossShape ⇒ RedCrossFigure.The first column contains the corresponding line from the Shape-sProduct cookbook and the second indicates the reusers responsefor each new shape class. For example, to add the shape Labelled-Shape the reuser should answer first answer “Yes” to indicate theneed of a new shape, and then confirm the two actions that definethe icons by pushing the enter button. After that, the reuser shouldenter “LabelledShape” as the name of the class, following to “No-s”to decline creating restriction rules and new figures. In this case,Line 41 is not executed (not applicable).

Fig. 13 shows a UML class diagram containing the final appli-cation model. The new shape classes are shown as sub-classes ofclass Shape and the RedCrossFigure class as a sub-class of Figure. Thecomment associated with each refined method does not appear inthe diagram, but can be found in the XML file that represents theUML diagram (the .uml file).

4.4. Considerations

Although the Shapes framework has a reuse process that dealswith few hotspots and design elements, we believe using the Reuse-Tool brought some improvements. Initial analysis about the tool

seamless path that is carefully designed by the framework devel-opers to facilitate navigating through the framework models. As aresult, the reuser does not waste time dealing with several classes

2242 T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252

Table 3Reuse actions trace.

RDL C omm and Reuse r Respo nse

TriangleShap e Labelled Shape RedCrossShape5. LOOP("Create another shape?"); yes Yes yes8. EXTERNAL_TASK("Define 16x16 icon"); enter Enter enter9. EXTERNAL_TASK("Define 24x24 icon"); enter Enter enter

12. shapeClass = CLA SS_EXTENSION(Shape ,

packA,"?");Trian gleShap e LabelledS hape RedC rossShape

35. IF ("Add Feature - Restric t

Connections?") THEN {No No yes

39. IF ("Add Feature - New Figure?") THEN { No No yes N/A

at

siitWi

flrmChtcttmcasp

41. figClass = CLASS_EXTENSION(Figure,

packA,"?");

t once to discover what needs to be done but, instead, focuses onhe model elements related to the hotspot to be extended.

Another benefit is also related to capturing reuse actionequences. Some reuse actions must occur before others as they canmpact the process flow. For example, what‘s the point of extend-ng the class Figure unless the reuser is creating a visual elementhat is not present in the library, such as in the RedCross case?

ithout the ReuseTool, an unattended reuser may create such classnadvertently.

Another point that is worth highlighting concerns the Shapesramework design. Although the original Shapes framework fol-ows an object-oriented approach and some of its hotspots areeused through class extensions, there were hotspots that requiredodifying the existing classes’ code. For example, the method

reateShapesDrawer from class ShapesEditorPaletteFactory needs toave its code modified to add a new palette entry. We believehis is an invasive way to reuse that may expose the frameworkode to possible misuse and, for this reason, we have modifiedhe Shapes’ design and code to avoid such practice. For instance,he class org.eclipse.gef.examples.shapes.parts.ShapeEditPart imple-

ented the methods createFigureForModel() and getConnectionAn-

hor() with code that was dependent on the new shape classess shown on the left cell of Table 4. We have implemented theame behaviour by delegating such code to the sub-class itself viaolymorphism.

Fig. 13. The applic

N/A RedC rossFigure

4.4.1. ExperienceIn order to verify the applicability of the proposed approach

we have conducted an Exploratory Case Study (Runeson and Host,2009). Our focus was to establish whether the ReuseTool approachwas capable of working for different frameworks from diversedomains and authors. As a result we have established the fol-lowing research question “Is the ReuseTool approach capable ofrepresenting and executing the instantiation process for diverseframeworks?”

In order to answer the research question we have gathered thefollowing data:

1. The framework’s domain—this information allowed us assuringwe are exploring different domains.

2. The number of classes in the framework—this informationallowed us reasoning about the framework size and complexity.

3. The number of hotspots—this information allowed us under-standing the framework’s reuse process size and complexity.

4. The number of lines of RDL code—this information allowed usrealizing whether RDL was capable of representing the reuseprocess.

The Case Study involved one researcher and 3 subjects with goodobject-oriented programming, JAVA and modelling skills with a mixof academic and industry backgrounds. The subjects’ profiles were:

ation model.

T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252 2243

Table 4Modified code for the method createFigureForModel.

Origi nal Code Modified Codeprivate IFigure createFigureForModel() {

// if (getModel() instanceo f EllipticalShape) {

// return new Ellipse();// } else if (getModel()

instanceof RectangularShape) {// return new RectangleFigure();// } else if (getModel()

instanceof CrazyShape) {// return new Label("Testing");// }{// // if Shapes gets extended the

conditions above must be updated// throw new

private IFigure createFigureForModel() {

// the Shape class knows how to return its associated figure

Shape sh = (Shape) getModel();return sh.getFigure() ;

}

•

•

•

•

•

•

•

•

tbiso

awdrSAbibc

fP

TC

IllegalArgumentException();// }

}

a master student with 5 years experience in “industry” JAVA pro-gramming.a master student with 1 year experience in “academic” JAVA pro-gramming.an undergrad student with 1 year experience in “academic” JAVAprogramming.

All subjects were exposed to the same procedure:

Choose a particular object-oriented framework from the litera-ture or self-made;Create the associated UML file, either by hand or reverse engi-neering from code;Create the RDL script files by analyzing the framework documen-tation and known instances;Execute the script using the ReuseTool to create the design for atleast two different framework instances;Report the experience as either successful or unsuccessful.

Table 5 summarizes the experiment information by exposinghe Frameworks’ Name and Domain, the Number of Classes, Num-er of Hotspots and the Number of Lines for the RDL Script. It is

mportant to point out that Table 5 shows five frameworks as someubjects decided to experiment with more than one, what in ourpinion do not pose a threat to the study.

As can be drawn from Table 5, all subjects managed to cre-te the RDL script for the selected frameworks. The frameworksere freely chosen by the subjects and were developed by indepen-ent teams, which do not participate in the study. The frameworksange from small and relatively simple to understand as with thehapes framework, to the midsized and more complex JHotDraw.nother interesting conclusion was the relation between the num-er of hotspots and the number of RDL lines. More hotspots implied

n more RDL lines, which is an expected impact since the num-er of hotspots is somehow related to the framework’s size and

omplexity.

It is also important to point out the results from the Product Linerameworks, Ecommerce Product Line (Gomaa, 2004) and Arcaderoduct Line (APL, 2010). They have respectively 10 and 5 hotspots

able 5ase study information.

Framework name Domain

Shapes (Shapes, 2010) Graphical

JHotDraw (Jhotdraw, 2010) Graphical

Ecommerce Product Line (Gomaa, 2004) Ecommerce

Arcade Product Line (APL, 2010) Games

REMF (REMF, 2010) Infrastructure

that led to RDL programs with 16 and 21 lines. When we comparedwith the Shapes framework, which has 6 hotspots the lead to 46lines of RDL code, we found the RDL script too small. In fact ourfindings are in line with the Product Line (Atkinson et al., 2001)community as reusing a Product Line typically leads to reusing pre-made assets through selection not extending as with regular object-oriented frameworks.

Limitations and threats to validity. In this section we report onthe limitations of our study with regards to using the ReuseToolapproach to represent and execute Reuse Processes. We discussaspects related to:

• Observer intervention—Although the subjects were free to selectany object-oriented framework to their liking, the Case Studyobservers had to make sure all three subjects chose different andmeaningful frameworks. Therefore we had to rule out the choiceof the JUnit Framework as it has too few hotspots.

• Subject selection—All subjects are students from our undergrad orgrad courses in Computer Science, which means they had simi-lar learning experiences. They also belong to the same researchgroup and participate regularly on several discussions regard-ing software reuse techniques. As a result the subjects may haveapproached the framework reuse problem from the same per-spective and may have used a similar rationale to describe theorder the reuse actions. We believe using subjects from differ-ent background would improve our results and we are planningfuture case studies with a broader set of subjects.

• Case study process—Our subjects played the Framework Devel-oper Role and the Application Developer Role in order to createthe UML Design, RDL script and test the approach. This scenarioimplies the Application Developers had previous and exten-sive knowledge on the Frameworks’ rationale, which definitivelymade the application development easier. However we believethis impact does not invalidate our study as we were not trying

to establish whether the approach leads to gains in productivity.

• Frameworks relevance—Most of the frameworks chosen for ourstudy are examples of object-oriented frameworks with exten-sive documentation found in the literature. However they are

#Classes #Hotspots # RDL Lines

13 6 4690 12 5516 10 1616 5 2153 7 27

2244 T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252

Table 6RDL enhancements.

T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252 2245

Table 6(Continued).

•

5

Dbhfforeo

itemtccOCgC

limited in size and scope, which means our approach may suf-fer scalability issues when applied to frameworks such as Eclipseand Hibernate that have several hotspots.Tool limitations—Although the ReuseTool is a step forward torepresent and execute Reuse Processes, we believe the tool stillneeds improvements. Firstly we believe the ReuseTool user inter-face needs to become graphical and based on forms, in contrastto current command-line approach, which will allow reducingerrors such as typos. Secondly the RDL typing mechanism maylead to erroneous scripts and we plan to enhance the RDL lan-guage to cope with strong typing. Thirdly the coverage of ReuseActions should be expanded to cope with situations such asAspect Oriented Frameworks (Santos et al., 2007) and MetadataBased Frameworks (Doucet et al., 2003). At last but not least, theReuseTool does not come with an extensive user-guide and forthat reason most issues during the Case Study were related toinstalling the tool.

. RDL enhancements and implementation

Our paper (Oliveira et al., 2007) thoroughly describes the Reuseescription Language and how its execution modifies a UML modelut only briefly discusses about implementation. On the otherand, this work focused on the development of a mature tool for

ramework reuse based on an established workflow engine and aully-fledged RDL compiler, a scenario that brought an excellentpportunity to upgrade RDL itself. As a result, we have managed toefactor the RDL BNF to make it more flexible and ready for futurextensions. We have also introduced new commands and upgradedld ones to facilitate the reuse experience.

Table 6 describes RDL enhancements. We have divided the tablen four groups as follows: BNF Refactoring, Syntactic Sugar, Refac-ored Commands and New Commands. The BNF refactoring groupxposes the adaptations made in the language BNF to make itore flexible to future adaptations and cope with how UML iden-

ifies design elements. The Syntactic Sugar group reflects someosmetic changes in the language and basically replaces lengthyommand delimiters by curly brackets with no semantic effect.

n the other hand, the groups Refactored Commands and Newommands unveil broader changes that impact how RDL pro-rams are developed and executed. The former group updated theLASS EXTENSION and LOOP commands, while the latter intro-

duced commands to deal with packages, interfaces, conditions andhuman-interaction. Most rows in Table 6 thoroughly describe eachmodification accompanied by its BNF syntax diagram.

6. Extending the ReuseTool

One of the features we aimed at when developing the Reuse-Tool was extensibility. Our past experiences with software projectsindicate that modelling and programming evolve over time, andtherefore having a tool that can cope with such evolution would be avaluable contribution. As a result, instead of creating an immutablepiece of software, we ended up using the concept of object-orientedframeworks throughout the ReuseTool’s architecture to define aset of hotspots and an associated RDL Program. In this section weexplain the rationale for the ReuseTool Framework and describe itsmajor hotspots, the associated RDL Program and a reuse scenariobased on handling UML Enumerations.

The extension scenario: Enumerations are UML model elementsto represent user-defined data types based on a set of literals (Bovetand Parr, 2008). Each literal represents a concept from the appli-cation domain and can hide complex computer based information.For example, computers typically represent a color as a numberthat indicates the amount of RGB (Red, Green and Blue) that shouldbe combined to reproduce its appearance. Thus, the color black canbe seen as (0,0,0), while red as (255,0,0). In order to make the colorinformation more palatable for developers not eager to work withnumbers it is possible to define an enumeration to represent theset of possible colors as Color = (BLACK, WHITE, RED), where eachliteral maps to a RGB number. Table 7 illustrates the look and feelof an UML Enumeration and its associated XML representation (the.uml file).

6.1. Extending the language

RDL represents the major front-end for the ReuseTool, given thatRDL is used to describe the reuse process that is later translated intoa process description. As a result, the first step towards making theReuseTool extensible is to make RDL extensible so that framework

developers can make use of new commands programmatically.Allowing new commands in RDL programs implies modifying theRDL grammar to represent the command’s syntax and how it willbe connected to the JPDL Code Generator. Fortunately, the RDL

2246 T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252

Table 7Enumerations in UML.

F

gdtpb

itwwR

m

-

-ically but by the use of JPDL (JBOSS Process Definition Language),

ig. 14. Non-terminal ip expression and its associated production rule.

rammar specifies a light-weight extension mechanism that allowsefining new commands that must be executed without affectinghe process flow. The restriction regarding the side effects on therocess flow means the new command cannot introduce a way toypass the course of execution already defined by the RDL program.

Fig. 14 exposes the production rule for the non-terminalp expression. Recalling Table 6 on RDL Enhancements (line Struc-ured Commands), an ip expression can take part in any statement,hat makes it a suitable place to add new reuse commands with noorkflow side-effects. As a result, the first hotspot specified by theeuseTool Framework is “Refining the non-terminal ip expression.”

In order to extend the hotspot related to ip expression the reuserust:

Add a new entry in the ip expression production rule to introducethe new non-terminal symbol;

Define the new non-terminal symbol production rule to representits syntax. Sometimes it’s required to add several terminal andnon-terminal symbols to properly represent the new command;

1. ip_expressio n : …. | ip_new_enumeratio n2. ;3.4. ip_new_enumeration 5. : NEW_ENUMERATION LEFT_PARENTHESIS qualif 6. {7. codeGen.addNewEnumeration($qualified 8. }9. ;

Code Example 2. RDL gramm

- Define the inline Java code to connect with the JPDL Code Gener-ator;

- Re-generate the RDL Parser and RDL Lexer.

Code 2 illustrates the grammar required to define a new com-mand to create UML Enumerations. Line 1 specifies the newentry with the ip expression production rule to introduce the newnon-terminal symbol ip new enumeration. Lines 4–9 specify theip new enumeration production rule that will allow declaring anRDL code such as “NEW ENUMERATION(id,“’label”)”, where id is theenclosing package and label is the name of the new enumeration. Itis also important to note how the non-terminal symbol is linkedto the code generator using a snippet of Java code from lines 6to 8. The addNewEnumeration method (Line 7) should be createdat class org.reusetool.jpdl.transformer.JbpmCodeGen, which is part ofthe ReuseTool CodeGenerator component (see Section 3.1).

The last action to extend RDL is developing its associated lexerand parser. Fortunately, we have adopted the compiler generatorANTLRWorks (Bovet and Parr, 2008), which is capable of generatingparsers and lexers automatically based on the language grammar.

6.2. Extending the architecture

The ReuseTool’s architecture is divided in two components: theTransformer and the Process Execution Machine. The former aimsat generating JPDL code based on the RDL parser output, while thelatter executes the JPDL code to manipulate the UML Model. In orderto make these two components flexible, we have developed a set ofclasses to define the hotspots “Extending the JPDL Code Generation”and “Extending Process Execution Machine.”

HotSpot—Extending JPDL Code Generation: The Code Generatoraims at transforming the RDL program into a JPDL process graphthat is executable by the JBPM workflow engine. The process graphconsists of a series of nodes that are connected to define thesequence in which the reuse actions occur. Table 8a presents a pro-cess graph diagram containing the nodes Start, Custom and End todefine a process graph that follows the sequence “Start - > Custom- > End”. However, the process graph cannot be manipulated graph-

which is an XML representation as illustrated in Table 8b.In order to make the JPDL code generation flexible, we

have developed the interaction strategy described by the UML

ied_id COMMA STRING RIGHT_PARENTHESIS

_id.text , $STRING.text);

ar for a new command.

T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252 2247

Table 8JPDL sample.

ScNNTcasdimt

Nigt

equence Diagram at Fig. 15. The diagram illustrates how toombine instances of the classes RDLParser, JBPMCodeGen andewEnumerationJPDL to generate JPDL code for the RDL commandEW ENUMERATION. Note the diagram has two loop fragments.he top loop fragment starts when the RDLParser matches a validommand in the RDL program input stream. It then triggers theddNewEnumeration() method found in the JBPMCodeGen class totore an instance of the NewEnumerationJPDL class in the interme-iate code array. Once all commands are parsed, the bottom loop

terates through the intermediate code array, retrieves all NewEnu-erationJPDL instances, and then generates JPDL code specific to

he reuse action type.The aforementioned flexibility relies on the fact that the class

ewEnumerationJPDL and the method addNewEnumeration() usedn the Sequence Diagram (Fig. 15) are actually placeholders to moreeneric representations, and they can be replaced by other pairshat correspond to any other RDL command. The class NewEnumer-

Fig. 15. Sequence diagram

ationJPDL is part of a hierarchy based on the class JPDLCode, whichmeans any instance of a JPDLCode sub-class can be stored withinthe intermediate code array instead. Furthermore, the methodaddNewEnumeration() can be replaced by the method specified inthe Java code snippet defined within RDL grammar that binds theRDL Parser and the Code Generator (see Code 2 Line 7). As a result,extending the Code Generation implies defining a new class follow-ing the JPDLCode hierarchy and implementing the related “add*()”method to add an instance of the new sub-class to the intermediatecode array.

The JPDLCode class defines a set of helper services to produce theXML representation for a JPDL Custom node that will be part of thereuse process graph. A JPDL Custom node defines an action in the

process graph that can be carried out by a Java class, which in ourcase implements the manipulation of a UML model element relatedto the reuse action. Code 3a contains the NewEnumerationJPDL classused to implement the NewEnumeration command, while Code 3b

to generate code.

2248 T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252

1.publi c clas s NewEnumerationJPDL extend sJPDLCode {

2.publi c NewEnumerationJPD L3. (String package_, String enumName) {

4. para ms.add(package_) ;5. para ms.add(enumName );6. setJavaClassNam e

("NewEn umeratio nHandle r");7. setJavaMethodName ("newEnum ");8. }9.}

1. <custo m clas s="NewEnumerationHandler " nam e="X ">2. <constructo r>3. <ar g>4. <strin g valu e='package_ ' />5. </ar g>6. <ar g>7. <strin g valu e='enumName ' />8. </ar g>9. </constructo r>10. <transitio n nam e="to Y " to="Y " />11.</custo m>

(a) (b)

Code Example 3. Code to configure the NewEnumeration command.

1. publi c clas s NewEnumeratio n extend s RDLCommand {2.3. protecte d String PACKAGE_PARA M ;4. protecte d String ENUM_NAME_PARA M ;5.6. publi c NewEnumeration(String pName, String name) {7. supe r("NEW_ENUMERATION ");8. PACKAGE_PARA M = pName ;9. ENUM_NAME_PARA M = name ;10. }11. protecte d Object internalExecute() {12. Package umlPackage = (Package) symbolTabl e.get (PACKAGE_PAR AM);13. String enumName = ENUM_NAME_PARA M;14. // Trim excess quotes and space s15. enumName = SupportLib.cleanString(enumName) ;16. if (enumName.startsWith ("? ")) {17. enumName = SupportLib.promptUser ("Type the Enumeration Name : ");18. }19. if (!SupportLib.isValidID(enumName)) {20. System .ou t.println ("Enumeration Name Invalid. ");21. retur n nul l;22. }23. retur n UMLModelRAM.newEnumeration(umlPackage,enumName) ;24. }25. }

Class NewEnumeration.

pasNhsaetN

ccMEheci

tdtm

Code Example 4.

resents the generated JPDL Custom node. Note the NewEnumer-tionJPDL class extends the JPDLCode class and uses the methodetJavaClassName at Code 3a Line 6, to indicate the qualified nameewEnumerationHandler (see Code 4) for the java class that willandle the UML model manipulation at runtime. The JPDLCodeub-class also defines two parameters to indicate the UML Pack-ge that will contain the enumeration (Code 3a Line 4) and thenumeration name (Code 3a Line 5). These parameters are used inhe custom node as arguments passed to the constructor for theewEnumerationHandler class (Code 3b lines 2–9).

Hotspot—Extending the Process Execution Machine: Once the JPDLode is generated, new features can be added to the Process Exe-ution Machine component so that it can manipulate the new UMLodel element properly. It is important to note that the Process

xecution Machine is developed around a workflow engine thatas been tailored with some Java classes to deal with UML modellements. Thus, using the same rationale of the Code Generationomponent, we have devised a set of classes that facilitate extend-ng the process machine through sub-classing.

The class diagram in Fig. 16 illustrates some model elements

hat compose the Process Execution Machine component. We haveeveloped the class RDLCommand to implement a set of serviceso facilitate executing the RDL command within a process environ-

ent. For instance, it allows accessing a shared symbol table that

Fig. 16. Process execution machine component.

T.C. Oliveira et al. / The Journal of Systems and Software 84 (2011) 2234– 2252 2249

1. publi c clas s NewEnumerationHandle r extend s NewEnumeration implement sExternalActivityBehaviour {2.3. publi c NewEnumerationHandler(String pName, String name) {4. supe r(pName, name) ;5. }6.7. publi c voi d signal (ActivityExecution execution, String signalName ,8. Map<String, ?> parameters) throw s Exception {9. execution.take(signalName) ;10. }11.12. publi c voi d execute(ActivityExecution execution) throw s Exception {13. thi s.execute() ;14. }15. }

eratio

cmaibib

diwitmtRceiTfi

Code Example 5. NewEnum

ontains runtime elements such as program variables, and UMLodel elements. In addition, the RDLCommand class declares an

bstract method named internalExecute() that should be redefinedn a sub-class to provide specific implementation to the commandehaviour. On the other hand, the interface ExternalActivityBehavior

s provided by the workflow engine library to promote integrationetween a Java object and the engine.

The classes NewEnumeration and NewEnumerationHandle (inark blue) are also shown in Fig. 16 to represent classes that

mplement the command behaviour and the integration with theorkflow engine, respectively. Furthermore, these two classes

llustrate how the Process Execution Machine hotspot is extendedhrough redefining proper methods in sub-classes. For example, the

ethod internalExecution() in the NewEnumeration class redefineshe behaviour of the equivalent method declared in super-classDLCommand. Code 4 illustrates the final implementation for thelass NewEnumeration containing its constructor and the internalEx-

cute methods. The constructor is described from lines 6 to 10 andt essentially stores the parameters in the current class instance.hese parameters are the same used in the JPDL custom node con-guration (see Code 3b lines 2–9).

1.COOKBOOK ReuseToo l2.3. RECIPE mai n4. {5. //// Extending Hotspo t - Refining the n 6. EXTERNAL_TASK("Modify the ip_expression 7. EXTERNAL_TASK("R e-generate the RDL Pars 8.9. //// Extending Hotspo t - JPDL Code Gene 10. // Add CodeGenerator Method to JBP 11. NEW_METHOD(JbpmCodeGen,"?"); 12.13. // Create JPDL Class to handle cod

org.reusetool.jpdl.transformer;14. jpdlClass = CLASS_EXTENSION(JPDLCo 15. // Define the constructo r16. NEW_METHOD(jpdlClass,"?" );17.18. //// Extending Hotspo t - Process E 19. // Create Class to execute the com

org.reusetool.pem.reuseactions.20. cmdClass = CLASS_EXTENSION(RDLComm 21. // Define the constructo r22. NEW_METHOD(cmdClass,"?"); 23. // Define method internalExecute()

Code Example 6. ReuseTool boot

nHandler implementation.

The method internalExecute() described from Line 11 throughLine 25 implements the UML element manipulation to realize thebehaviour of the RDL command. For instance, in Line 12, the methoduses a symbol table object to gain access to a reference to theUML package element which name matches the PACKAGE PARAMparameter. This method also uses a library that is responsible formanipulating the XML structure that represents the UML model inmemory (see Code 4 Line 23).

Fig. 16 also contains the class NewEnumerationHandler. Thisclass extends the NewEnumeration class and implements the Exter-nalActivityBehaviour interface to provide a smooth integrationbetween the code that implements the NEW ENUMERATION com-mand and the workflow engine. The integration happens in twolevels. First, the name “NewEnumerationHandler” was used whenextending the JPDL Code Generation hotspsot at Code 3a Line6 to indicate the name of the class that will realize the com-mand at runtime. Second, the implementation for methods signal()

and execute() handle the cases (Code 4 Line 9) when the JPDLcustom node is executed and the execution flow is re-routed tothe NewEnumeration.execute() method (Code 5 Line 13), respec-tively.

on-termin al ip_expression production rule in the RDL.g grammar.");er and RDL Lexe r.") ;

rationMCodeGenClass

e generation at package

de,org.reusetool.jpdl.transformer,"?") ;

xecution Machinemand at at package

and,org.reusetool.pem.reuseactions,"?");

srap instantiation program.

2 stems

6

Tbg

7

raw

ianaDtiicaastiVatttic

bAHosde2iwote

gt2nFtmCp(ilswst

250 T.C. Oliveira et al. / The Journal of Sy

.3. The RDL program

Sections 6.1 and 6.2 have illustrated the rationale for the Reuse-ool extension process. However, in order to demonstrate the tool’sootstrap approach, this section exposes the commented RDL Pro-ram that is capable of extending the ReuseTool itself (Code 6).

. Related work

In this section, we describe existing work on software reuseelated to framework instantiation, product lines and model-drivenrchitectures. We also explore how existing tools deal with soft-are reuse process representation and end-user guidance.

In Johnson (1992) the authors have proposed a structured spec-fication to support framework instantiation. They have introduced

document known as Cookbook to describe the reuse process withatural language. A Cookbook is composed of nested sections suchs The Purpose of the Framework, How to Use the Framework and Theetailed Design of the Framework and a pattern language to expose

he framework most common uses. Although a Cookbook is anmportant approach to document frameworks, its major drawbacks the extensive use of natural language. Natural Language specifi-ations depend on human interpretation and are hardly processedutomatically. As a result, Cookbooks are hard to be manipulatednd analyzed to check inconsistencies in the process. As an exten-ion to Cookbooks, Hooks (Froehlich et al., 1997) also provided aemplate for framework instantiation assistance that shares sim-lar problems. Hautamäki and Koskimies (2006), Viljamaa andiljamaa (2002) can be seen as a dynamic version of CookBooksnd Hooks where the authors define a pattern-based approacho specify goals that are related to framework instantiation. Pat-erns are expressed with natural language and organized withinhe JavaFrames tool. The JavaFrames approach does not deal with annstantiation process but with isolated instantiation patterns thatan be orchestrated according to the application developer needs.

In the area of framework instantiation guidance, Active Cook-ooks (Ortigosa and Campo, 1999) advocate the use of Softwaregents to execute instantiation plans. The main issue with theiFi (Ortigosa and Campo, 1999) approach, which is an extensionf Active Cookbooks, is that it introduces non-standard notationsuch as TOON (Ortigosa and Campo, 1999) into the applicationevelopment process. Such non-standard approaches can add anxtra burden to framework development. In OBS (Cechticky et al.,003), the authors used a generative approach for framework

nstantiation that shares some of the features of our previousork (Oliveira et al., 2002). However, the OBS approach is based

n ready-to-use blackbox frameworks, which restricts instantia-ion processes to component configuration, and does not focus onxtension.

Product Line Architectures also lead to approaches to supporteneration of applications from pre-defined software componentshat can be configured based on a decision model (Atkinson et al.,001). In Gomaa (Gomaa, 2004), the author has presented a tech-ique to develop Software Product Lines using UML diagrams andeature Models. However, the lack of tool support causes difficul-ies for systematic adoption. Another initiative based on Features

odel is the Generative Programming (GP) approach described inzarnecki (2004) (Antkiewicz et al., 2009), where the authors pro-ose the development of Domain Specific Modelling LanguagesDSML) as a means to generate programs from high-level spec-fications and transformations. Alfama (Santos et al., 2008) alsoeverages on DSMLs to foster framework instantiation. Although we

hare some underlying principles with the Generative approaches,e believe DSMLs should be anchored on a single robust notation

uch as UML to avoid using numerous languages to define a sys-em. We also advocate the need to a process specification that, to

and Software 84 (2011) 2234– 2252

the best of our knowledge, is not available in any of the relatedwork.

WebML (Ceri et al., 2009) and WebRatio (Acerbis et al., 2007)are approaches based on UML-based Domain Specific Languagethat guide developers through a set of pre-defined forms to col-lect application-specific information to create Web Applications.In the WebML/WebRatio approach the configuration knowledge ishard-coded into the tool, which complicates its extension to incor-porate new types of reusable assets and extension point types. Thework on Design Fragments (Fairbanks et al., 2006) encapsulates theframework extension points as part of goals the reuser must fulfil.Goals describe all the code elements that should be manipulatedduring instantiation with examples and also expose some relatedframework underlying concepts. Design Fragments is a code-basedapproach to framework instantiation while ours is model-based.

OMG’s Model Driven Architecture (MDA) (Bezivin and Gerbe,2001) is also an attempt to systematize reuse using UML (Uni-fied Modelling Language), OCL (Object Constraint Language)(Warmer and Kleppe, 2003) and software transformations. TheMDA approach can use modelling languages such as UML torepresent software in a platform-independent manner and havetransformation programs to generate code or platform dependentmodels. Our approach shares many of the MDA characteristic butinstead of using a strict deterministic (Czarnecki and Helsen, 2003)approach based on transformation languages such as ATL (AtlasTransformation Language) (Jouault et al., 2006), we use an interac-tive process in which the reuser can leverage on.

It is also important to mention current reuse guidance tools thatare being widely adopted by the software development communitysuch as Eclipse (Eclipse, 2010), Mac XCode (Xcode, 2011) and Delphi(Delphi, 2011). Eclipse is an Integrated Development Environment(IDE) that was conceived to be extended. Eclipse is based on thenotion of extension points, which represent the elements in theIDE that can be extended. In order to help reusers, Eclipse has Wiz-ards and Cheat Sheets. Wizards are represented as a set of formscodified in Java that guides a reuser through a predefined sequenceof data-collection tasks. Although Java is a powerful language, webelieve representing processes with Java can be cumbersome asprocesses have tasks that have to be synchronized under a multi-user environment, which is one of the reasons why there are severalWorkflow engines such as JBPM (JBPM, 2011), that extend the JavaLanguage. Cheat Sheets are part of the Eclipse’s User Assistance Sup-port and are aimed at helping the IDE users to accomplish certaintasks. A Cheat Sheet is represented with a bespoke XML structureand has limited mechanisms to represent process elements suchas conditionals and loops. It also lacks a proper editor to facilitatedealing with XML editing issues.

Mac XCode (Xcode, 2011) and Delphi (Delphi, 2011) reuse arerestricted to interface builders. Interface builders are importanttools to generate the associated code that represents a user inter-face, typically as a form. However they were not meant to facilitatereuse in a broader sense through a reuse process specification.

8. Conclusions and future directions

In this paper we present the ReuseTool, which is an infrastruc-ture to facilitate the instantiation of Object Oriented Frameworks.The tool is based on the interactive model-to-model transforma-tion (Czarnecki and Helsen, 2003) approach, where the frameworkmodel is tailored with application specific increments to create theapplication model. The interactive transformation process is spec-ified with RDL (Reuse Description Language) (Oliveira et al., 2007)

and executed by an extension to JBPM workflow engine (Fleuryand Reverbel, 2003). By an interactive transformation we mean theinstantiation process can request the reuser information on how toadapt an extension point at reuse-time.

stems

uA2owtdRttrwcT

tw(tP

A

nR

R

A

A

DA

B

B

B

C

C

C

C

C

DD

DD

D

T.C. Oliveira et al. / The Journal of Sy

The ReuseTool operates on UML models and was implementedsing the Eclipse UML2 plugin (UML2, 2010). We have also usedNTLR (Bovet and Parr, 2008) to implement the RDL-to-JPDL (JPDL,010) compiler. It is important to mention the ReuseTool is basedn an extensible architecture that is itself an object-oriented frame-ork and can be adapted to handle other types of reusable artifacts

han UML models. In fact, as part of our future work, we plan toevise an approach that integrates a Reusable Artifact Model, aeuse Process Specification and Reuse Constraints as an extensiono the Reusable Asset Specification (RAS) (RAS, 2010). Conceptually,he approach will allow the representation of reuse processes foreusable assets such as Aspects (Santos et al., 2007) and other Soft-are Process concepts. We also plan to extend our experiment to

ollect valuable feedback from end-users on the use of the Reuse-ool.

It is also important to mention our current efforts to cope withhe evolution of reusable assets (including object-oriented frame-orks), an important issue when dealing with real world scenarios

Dhungana et al., 2010). Corrêa et al. (2011) brings some of ourhoughts to deal with consistency issues in Model-Driven Softwareroduct Lines).

cknowledgements

This research was supported by the Natural Sciences and Engi-eering Research Council of Canada (NSERC) and the Brazilianesearch Council (CNPq).

eferences

cerbis, R., Bongio, A., Brambilla, M., Butti, S.,2007. WebRatio 5: an eclipse-basedCASE tool for engineering web applications. In: Proceedings of the 7th Inter-national Conference on Web Engineering (ICWE’07). Springer-Verlag, Berlin,Heidelberg, pp. 501–505.

ntkiewicz, M., Czarnecki, K., Stephan, M., 2009. Engineering framework-specificmodeling languages. IEEE Trans. Software Eng. 35 (6), 795–824.

ocumentation at http://www.sei.cmu.edu/productlines/ppl/, accessed July 2010.tkinson, et al., 2001 September. Component-Based Product Line Engineering with

the UML. Addison-Wesley.ezivin, J., Gerbe, O.,2001. 2, Towards a Precise Definition of the OMG/MDA Frame-

work. In: Proceedings of the 16th IEEE International Conference on AutomatedSoftware Engineering (ASE ’01). IEEE Computer Society, Washington, DC, USA,273.

osch, J., Molin, P., Mattsson, M., Bengtsson, P.O., Fayad, M., 1999. Object-OrientedFrameworks: Problems & Experiences. In: Fayad, M., Schmidt, D., Johnson, R.(Eds.), Building Application Frameworks. John Wiley, pp. 55–82, ISBN 0-471-24875-4.

ovet, J., Parr, T., 2008. ANTLRWorks: an ANTLR grammar development environ-ment. Softw. Pract. Exper. 38 (October (12)), 1305–1332.

echticky, V., Chevalley, E., Pasetti, A., Schaufelberger, W., 2003. A GenerativeApproach to Framework Instantiation, Erfurt, Germany, Proceedings of GPCE,pp. 267–286, LNCS 2830 OOPSLA.

eri, S., Brambilla, M., Fraternali, P.,2009. The history of WebML lessons learnedfrom 10 years of model-driven development of web applications. In: ConceptualModeling: Foundations and Applications, Lecture Notes In Computer Science,vol. 5600. Springer-Verlag, Berlin, Heidelberg, pp. 273–292.

orrêa, C.K.F., Oliveira, T.C., Wener, C.M.L., 2011. Towards automation of consistencypreservation for model-driven software product lines. In: Doctoral Symposiumof the 12th International Conference on Software Reuse, Pohang, Korea, June.

zarnecki, K., 2004. Overview of generative software development. In: Proceed-ings of Unconventional Programming Paradigms (UPP) 2004, 15–17 September,Mont Saint-Michel, France, Revised Papers, volume 3566 of Lecture Notes inComputer Science, Springer-Verlag, pp. 313–328.

zarnecki, K., Helsen, S., 2003. Classification of model transformation approaches,In: Proceedings of the 2nd OOPSLA Workshop on Generative Techniques in theContext of the Model Driven Architecture.

ocumentation at www.embarcadero.com/products/delphi, accessed in Feb, 2011.hungana, D., Grünbacher, P., Rabiser, R., Neumayer, T., 2010. Structuring the mod-

eling space and supporting evolution in software product line engineering. J.Syst. Software 83, 1108–1122.

ocumentation at http://www.microsoft.com/net/, accessed October 2010.oucet, F., Shukla, S., Gupta, R., 2003. Introspection in system-level language frame-

works: meta-level vs. Integrated. In: Source Design, Automation, and Test inEurope. pp. 382–387.

ocumentation at http://www.eclipse.org/, accessed October 2010.

and Software 84 (2011) 2234– 2252 2251

Fairbanks, G., Garlan, D., Scherlis, W., 2006. Design fragments make using frame-works easier. In: Proceedings of the 21st Annual ACM SIGPLAN Conference onObject-oriented Programming Systems, Languages, and Applications, p. 88.

Fayad, M., Schmidt, D., Johnson, R., 1999. Building Application Frameworks. JohnWiley.

Fleury, M., Reverbel, F., 2003. The JBoss extensible server. In: Endler, M. (Ed.),Proceedings of the ACM/IFIP/USENIX 2003 International Conference on Mid-dleware (Middleware ’03). Springer-Verlag New York, Inc, New York, NY, USA,pp. 344–373.

Froehlich, G., Hoover, H.J., Liu, L., Sorenson, P.G., 1997 May. Hooking intoobject-oriented application frameworks. In: Proc. 19th Int’l Conf. on SoftwareEngineering, Boston, pp. 491–501.

Documentation at http://www.eclipse.org/articles/Article-GEF-diagram-editor/shape.html, accessed October 2010.

Georgakopoulos, D., Hornick, M.F., Sheth:, A.P., 1995. An overview of workflowmanagement: from process modeling to workflow automation infrastructure.Distrib. Parallel Databases 3 (2), 119–153.

Gomaa, H., July 2004. Designing Software Product Lines with UML. Addison Wesley.Hautamäki, F., Koskimies, K., 2006. Finding and documenting the specialization

interface of an application framework. Software: Practice Experience 36 (13),1443–1465 (11, 2006).

Documentation at http://www.hibernate.org/, accessed October 2010.Hou, D., Wong, K., James Hoover, H., 2005. What can programmer questions tell us

about frameworks? In IWPC, pp. 87–96.Documentation at http://docs.jboss.com/jbpm/v4/userguide/html single/, accessed

in Feb, 2011.Documentation at www.jhotdraw.org/, accessed October 2010.Johnson, R., 1992. Documenting Frameworks Using Patterns. In: Proceedings of OOP-

SLA’92, ACM/SIGPLAN, New York.Jouault, F., Allilaire, F., Bezivin, J., Kurtev, I., Valduriez, P.,2006. ATL: a QVT-like trans-

formation language. In: Companion to the 21st ACM SIGPLAN Symposium onObject-oriented Programming Systems, Languages, and Applications (OOPSLA’06). ACM, New York, NY, USA, pp. 719–720.

Documentation at http://docs.jboss.org/jbpm/v3/userguide/jpdl.html, accessed July2010.

Documentation at http://www.junit.org/, accessed October 2010.Documentation at http://www.oracle.com/technetwork/java/javaee/overview/

index.html, accessed October 2010.Kirk, D., Roper, M., Wood, M., 2005. Identifying and addressing problems in frame-

work reuse. In: In IWPC, pp. 77–86.Krueger, C., 1992 June. Software reuse. In: ACM Computing Surveys (CSUR) Surveys

Homepage table of Contents Archive, vol. 24, Issue 2.Markiewicz, M.E., Lucena, C., 2001 June. Object Oriented Framework Development,

vol. 7. ACM Crossroads, Issue 4.Mattsson, M., Bosch, J., 2000. Stability assessment for evolving object-oriented

frameworks. J. Software Maintenance 12 (2), 79–102.Documentation at http://mootools.net/, accessed October 2010.Oliveira, T.C., Alencar, P., Cowan, D., 2002. Towards a declarative approach to

framework instantiation. In: Proceedings of the 1st Workshop on DeclarativeMeta-Programming (DMP-2002), Edinburgh, Scotland, September, pp. 5–9.

Oliveira, T.C., Alencar, P., Lucena, C., Cowan, D., 2004. Software process representa-tion and analysis for framework instantiation. IEEE Trans. Software Eng. 30 (3),145–159.

Oliveira, T.C., Alencar, P., Lucena, C., Cowan, D., 2007. RDL: a languagefor framework instantiation representation. J. Syst. Software 80 (11),1902–1929.

Ortigosa, A., Campo, M., 1999 June. Smartbooks: a step beyond active-cookbooks toaid in framework instantiation, Technology of Object-Oriented Languages andSystems 25. IEEE Press.

Pree, W., 1995. Design Patterns for Object-Oriented Software Development. AddisonWesley/ACM Press.

Documentation at http://www.omg.org/technology/documents/formal/ras.htm,accessed October 2010.

Documentation at www.cs.uwaterloo.ca/research/tr/2005/25/CS-2005-25.pdf,accessed October 2010.

Runeson, P., Host, M., 2009. Guidelines for conducting and reporting case studyresearch in software engineering. Empirical Softw. Eng. 14 (2), 131–164, April2009.

Santos, A., Lopes, A., Koskimies, K., 2007. Framework specialization aspects. In:Proceedings of the 6th international conference on Aspect-oriented softwaredevelopment, AOSD, pp. 14–24.

Santos, A., Koskimies, K., Lopes, A., 2008. Automated domain-specific modelinglanguages for generating framework-based applications. In: 12th InternationalSoftware Product Line Conference, pp. 149–158.

Documentation at http://www.omg.org/spec/SPEM/2.0/, accessed October 2010.Documentation at http://struts.apache.org/, accessed October 2010.Documentation at www.eclipse.org/uml2/, accessed October 2010.van der Aalst, W.M.P., Ter Hofstede, A.H.M., Kiepuszewski, B., Barros, A.P., 2003.

Workflow patterns. Distrib. Parallel Databases 14 (July (1)), 5–51.van der Aalst, W.M.P., ter, A.H.M., Hofstede, 2005. YAWL: yet another workflow

language. Inf. Syst. 30 (June (4)), 245–275.

Viljamaa, A., Viljamaa, J., 2002. Creating framework specialization instructions for

tool environments. In: Proceedings of the Nordic Workshop on Software Devel-opment Tools and Techniques.

Warmer, J., Kleppe, A., 2003. The Object Constraint Language: Getting Your ModelsReady for MDA, 2nd Edition. Addison-Wesley Professional.

2 stems

D

TJthEluudoHCtt

Dpthaa

ment in the Faculty of Mathematics (1967) at the University of Waterloo (now the

252 T.C. Oliveira et al. / The Journal of Sy

ocumentation at developer.apple.com/technologies/tools/xcode.html, accessed inFeb, 2011.

oacy Oliveira is currently an Assistant Professor at Federal University of Rio deaneiro (COPPE/UFRJ), Brazil. He is also Adjunct Professor with the David R. Cheri-on School of Computer Science at the University o Waterloo, Canada. He receivedis education at Pontifical Catholic University of Rio de Janeiro, Brazil (Electricalngineering - 1992, MSc-1997, PhD - 2001) and spent 3 years at University of Water-oo as a posdoc. His current research interests are under the software engineeringmbrella, including software processes and software reuse. Toacy focuses on these notations, models, processes and tools to improve the way software systems areeveloped. He has published over 40 refereed publications, and has been a memberf program committees of numerous highly-regarded conferences and workshops.e has been a leading investigator in national projects supported by CAPES andNPq. Toacy also has strong attachments to the local software industry that lead tohe creation of a software development company in 1998, the OWSE Informaticahat currently employes more than 50 software engineers.

r. Paulo Alencar is a Research Professor with the David R. Cheriton School of Com-

uter Science and Associate Director of the Computer Systems Group. He has morehan 20 years of experience in the software engineering and formal methods, andas made significant contributions to many areas, including software design andrchitectures, user interfaces, (mobile) web systems, software agents, and eventnd context-oriented applications. Dr. Alencar has received international research

and Software 84 (2011) 2234– 2252

awards from organizations such as Compaq (Compaq Award for best research paperin 1995 for his work on a software evolution theory) and IBM (IBM Innovation Award,2003). He has published over 140 refereed publications, and has been a member ofprogram committees of numerous highly-regarded conferences and workshops. Hehas been a leading investigator in national projects supported by NSERC, Sybase, IBM,CITO, CSER, and Bell, and has engaged in many collaborative international projectsinvolving Germany, Argentina, and Brazil.

Donald Cowan is Distinguished Professor Emeritus at the University of Waterloo.He received his education at the Universities of Toronto (BASc – 1960, EngineeringPhysics), Waterloo (MSc – 1961 and PhD – 1965, Applied Mathematics and Guelph(honorary DSc. - 2011). His current academic specializations include software engi-neering, software applications, and web-based information systems incorporatinggeomatics. His recent research has focused on the design and implementation of theWeb Informatics Development Environment (WIDE) toolkit, which has been usedto produce over 70 operational web-based information systems in the areas of envi-ronment, community information, economic development, cultural heritage andhealth. Donald Cowan is the founding Chairman of the Computer Science Depart-

David R. Cheriton School of Computer Science). He is the author or co-author of over250 refereed papers and 15 books in computer science, computer/communications,software engineering, education, environmental information systems and mathe-matics.