ECLIPSE IT The 6th Workshop of the Italian Eclipse Community. Proceedings of the Workshop

Transcription

1

2 ECLIPSE IT 2011 The 6th Workshop of the Italian Eclipse Community Proceedings of the Workshop Francesca Arcelli Leonardo Mariani and Domenico Squillace September 22th and September 23th, 2011 University of Milano Bicocca, Italy

3 Edited by Prof. Francesca Arcelli Università di Milano Bicocca, Italy Copyright 2011 by the Italian Eclipse Community. All Right Reserved. ISBN:

4 Committees Workshop Chair Francesca Arcelli University of Milano Bicocca, Italy Workshop Co-Chair Paolo Maresca Mauro Coccoli University of Napoli Federico II, Italy University of Genova, Italy Technical track Chair Francesca Arcelli University of Milano Bicocca, Italy Student track Chair Leonardo Mariani University of Milano Bicocca, Italy Industry track Chair Domenico Squillace IBM, Italy Organizing Committee Francesca Arcelli Leonardo Mariani Oliviero Riganelli University of Milano Bicocca, Italy University of Milano Bicocca, Italy University of Milano Bicocca, Italy

5 Program Committee Giovanni Adorni Marco Aimar Francesca Arcelli Luciano Baresi Francesco Bergdano Walter Binder Marco Brambilla Fabio Calefato Mauro Coccoli Andrea De Lucia Francesco di Cerbo Giovanni Denaro Claudio Ferretti Giacomo Franco Rosario Gangemi Angelo Gargantini Ferdinando Gorga Filippo Lanubile Paolo Maresca Leonardo Mariani Carla Milani Mattia Monga Antonio Natali Enrico Oliva Fabrizio Perin Claudia Raibulet Elvinia Riccobene Oliviero Riganelli Domenico Squillace Patrizia Scandurra Vittorio Scarano Carmine Seraponte Domenico Squillace Lidia Stanganelli Marco Torchiano Rodolfo Totaro Gianni Vercelli Marco Zanoni University of Genova, Italy Opera21, Italy University of Milano Bicocca, Italy Politecnico di Milano, Italy Univerity of Torino, Italy University of Lugano, Switzerland Politecnico di Milano, Italy University of Bari, Italy University of Genova, Italy University of Salerno, Italy University of Trento, Italy University of Milano Bicocca, Italy University of Milano Bicocca, Italy IBM, Italy IBM, Italy University of Bergamo, Italy IBM, Italy University of Bari, Italy University of Napoli Federico II, Italy University of Milano Bicocca, Italy IBM, Italy University of Milano, Italy University of Bologna, Italy S.E.I.C. s.r.l., Italy University of Bern, Switzerland University of Milano Bicocca, Italy University of Milano, Italy University of Milano Bicocca, Italy IBM, Italy University of Bergamo, Italy University of Salerno, Italy Opera21, Italy IBM, Italy University of Genova, Italy Politecnico di Torino, Italy Energeya Italia, Italy University of Genova, Italy University of Milano Bicocca, Italy iv

6 Sponsors of Eclipse-IT 2011 v

7 Contents Keynotes Eclipse an Open Source Innovation Network for the Industries.1 (Ralph Müller) Framework rich client application..2 (Paolo Giardiello) An outlook and trend in software industry market: Software Factory and best practices in successful enterprise software delivery..3 (Giorgio Galli) Technical Track Software Engineering, Reverse Engineering and Services Model-driven communications and collaborative software development.4 (Antonio Natali) Enabling End-User Plug-in Compositions with MASH..16 (Leonardo Mariani, Fabrizio Pastore) Reverse engineering Java Enterprise Applications in Eclipse.28 (Raphael Krebs, Fabrizio Perin) An Eclipse Plug-in for the Identification of Design Pattern Variants..40 (Andrea De Lucia, Vincenzo Deufemia, Carmine Gravino, Michele Risi, Genoveffa Tortora) An Eclipse-based SCA design framework to support coordinated execution of services.52 (Fabio Albani, Elvinia Riccobene, Patrizia Scandurra) An Eclipse Plug-in for Engineering Service Interchangeability..64 (Giovanni Denaro, Davide Tosi) Testing and Security The AutoBlackTest Tool: Automating System Testing of GUI-based Applications...78 (Leonardo Mariani, Oliviero Riganelli, Mauro Santoro) vi

8 TestCareAssistant: Automatic Repair of Test Case Compilation Errors 90 (Mehdi Mirzaaghaei, Fabrizio Pastore) An eclipse-based environment for conformance testing by FSMs (Angelo Gargantini, Marco Guarnieri, Eros Magri) An Eclipse plug-in for Test-to-Code Traceability Recovery (Abdallah Qusef, Gabriele Bavota, Rocco Oliveto, Andrea De Lucia, David Binkley) An Eclipse plug-in for specifying security policies in modern information systems (Simone Mutti, Mario Arrigoni Neri, Stefano Paraboschi) Security vulnerabilities detection and protection using Eclipse. 138 (Marco Guarnieri, Paul El Khoury, Gabriel Serme) Learning and Agents Persistence of the Memory: an introduction to the asset and intellectual capital management Application into the ETC project.150 (Ferdinando Gorga, Paolo Maresca) Knowledge sharing and cooperation among communities of practices: a possible scenario? (Giacomo Franco, Paolo Maresca, Giancarlo Nota, Marialuisa Saviano) Towards cloud learning with ETC and Juzzhub (Paolo Maresca, Carla Milani, Ferdinando Gorga, Giorgio Galli) Learning Processes and Cooperative Development in Software Engineering (Mauro Coccoli, Paolo Maresca, Lidia Stanganelli) Agent-Based Business Process Management with Eclipse 205 (Federico Bergenti, Giovanni Caire, Danilo Gotta, Elena Quarantotto, Giovanna Sacchi) Exploiting the Eclipse Ecosystem for Agent-Oriented Programming (Alessandro Ricci, Andrea Santi, Andrea Leardini, Antonio Natali) Applications and Tools An Eclipse Plug-in to Model System Requirements and Adaptation Capabilities (Luciano Baresi, Liliana Pasquale) An eclipse-based feature diagrams toolchain.242 (Luca Gherardi, Davide Brugali) vii

9 CViewer: an application for path routing analysis in a Telco software solution and the eclipse framework..254 (Loredana Luzzi, Alessandro Niglio, Marianna Peluso, Dario Pesole, Andrea Piccolo, Carmine Seraponte) An Eclipse plug-in for Public Administration software system modelling and simulation (Damiano Falcioni, Alberto Polzonetti, Andrea Polini, Barbara Re, Riccardo Cognini) PrEdE: a Projectional Editor for the Eclipse Modeling Framework..278 (Federico Tomasetti, Marco Torchiano) Students Track Combining SysML modelling with refinement checking in Eclipse.290 (Riccardo Sisto, Denis Makartetskiy) Managing On The Road Eclipse (OTRE) project, using the RTC Tools (Antonio Luparelli, Lidia Stanganelli) On The Road Eclipse: Single Sign In Project 299 (Fabrizio Ruocco, Gaetano Prisco, Antonio Luparelli) R -Blending Talk and Work in Eclipse. 303 (Alberto Bacchelli, Lorenzo Baracchi, Michele Lanza) Manhattan -3D City Visualizations in Eclipse (Alberto Bacchelli, Francesco Rigotti, Lile Hattori, Michele Lanza) AsmetaRE: an Eclipse-based Environment for Requirements Validation via Use Case Models and Abstract State Machines (Marco Dolci, Andrea Arnoldi) A DSL to define process templates in Jazz/RTC (Sam Golovchenko, Luca Pandolfo) A simple plugin for static security checks and program comprehension in Eclipse..319 (Andrea La Scola, Claudio Ferretti) Public Institutions and Industry Track Building a JEE application with Eclipse 322 (Marco De Luca, Giampiero Restaino) Extending the BPEL Designer with Xtext based editors (Lorenzo Bettini, Vincenzo Caselli, Francesco Guidieri) viii

10 Rational Quality Manager and Rational Team Concert adoption in Tivoli Rom Lab..334 (Ilaria Gorga, Alessandro De Micco) Parasoft Test: Complete Development Lifecycle Testing (Daniele Marsico, Clémence Soulat) ix

11 Eclipse - an Open Source Innovation Network for the Industries Ralph Müller Director Eco Systems Europe of the Eclipse Foundation Abstract. Open Source- for many the expression is a synonym for no cost or easy to obtain. Only known to the insider is the fact that Open Source methods and licenses have become the basis of many industry collaboration efforts. Here Open Source is applied to jointly develop, maintain and distribute software relevant for the industry. Due to its well-defined Intellectual Property Management and its Development Process is the Eclipse Project today well positioned to support industry initiatives in the collaborative value creation process. The commerce-friendly Eclipse Public License (EPL) makes it easy to capture value in commercial exploitation, providing the basis for a successful and sustainable eco system. While collaboration in the past was mostly organized by software vendors, we now experience that corporate software consumers are organizing their own consortia to work together on creation of relevant software. Based on Airbus TOPCASED and OPEES projects we will discuss the needs of these consortia and how organizations such as the Eclipse Foundation can provide an organizational framework to support these efforts. 1

12 Framework rich client application Paolo Giardiello SOGEI, Head of the Application Architectures Department Abstract. Every year Sogei distributes Java-based, standalone applications to the Italian citizens and to professional users. To achieve the goal of increased efficiency and improved quality of service, a project is underway to create a RCA framework promoting the creation of Eclipse RCP-based applications, while introducing in our company innovative solutions available in the open source community. The technological features that we are implementing in the framework are as follows: All applications plug into a Unified Desktop Application of the Workspace concept for user s data management using EFS (Eclipse File System) Custom software migration to OSGi technology and future use of these modules within JavaEE Application Server Application log based on the Pax Logging framework Help system based on the DocBook framework Software Upgrade via P2 and multi-site management Eclipse RCP Security Local Authentication Remote Authentication Profiling applications UI look and feel via CSS Data Binding and Validation via EMF User Interface Proprietary Language for UI definition; it will migrate to XText in future releases Swing integration into Eclipse view XMLSWT The framework is not limited to the client, standalone components, but is to be completed by a number of services, enabling remote access to our datacenter infrastructure offering data persistence, authentication/authorization and more, thus allowing fine-grained control from a central location. The technology chosen for this project is Eclipse, and we opted to reuse existing components to minimize changes on consolidated libraries. A series of infrastructure components has also been developed to: Establish a standard method for client applications to use the services Rationalize the services Reduce the impact on the infrastructure Open client applications to innovative technologies 2

13 An outlook and trend in software industry market: Software Factory and best practices in successful enterprise software delivery Giorgio Galli IBM Technical Leader Rational Software, South West Europe Abstract. Company and market that rely on software is growing faster. This is because software became more and more pervasive in our life. Software is flexible. Business process and people directly on indirectly run on it. Today software failure has tremendous impact and can cause several of millions of losses to organizations. In this context software delivery organization are under pressure to produce more software, faster, and with extreme cost pressure and increased quality. We will explore the concept of a Software Factory and which best practices have demonstrated how help organizations to decide what to invest in, develop what they decided, and deploy what they developed. 3

14 Model-driven communications and collaborative software development Antonio Natali Alma Mater Studiorum Università di Bologna Abstract Custom languages inherently associated via meta-modeling with the concrete organization of software systems, can promote not only better products, but can also allow people to efficiently describe and understand their collaboration, by identifying relevant relationships among tasks, developers and artifacts within a particular work context. This paper makes reference to Contact [1], a language usable as a meta-model for high-level communications within distributed systems, to show how it can promote structured forms of collaborations between workers with different skills and scope (e.g. customers, application designers and system designers), by providing at the same time other important benefits typical of the Model Driven Software Development (MDSD) approach [2]: i) the formal definition of a conceptual space useful in all the phases of software development; ii) the possibility to build a custom software factory that explicitly represents and spread the know-how of a company; iii) the automated construction of infrastructures tailored to application needs; iv) the usage of models as a new form of source code that can allow application designers to write platform-independent code. Keywords: Cooperative work, Meta-modeling, Communication, Software Factory, Eclipse, XText. 1 Introduction Software applications become increasingly heterogeneous and distributed and communication takes an increasingly central role in modern - service-oriented - software systems. Communication is commonly defined as the interchange of thoughts, opinions, or information by speech, writing, or signs. The problem is that current programming languages do not provide adequate expressive power and for many software developers, communication is only the emerging result of activities performed by using some software component providing communication mechanisms. As a consequence, the task of designing and building software components more related to a communication infrastructure rather than to the business logic is often repeated several times, each time in a different way. Worst, the analyst and the designer have no reference language to build a logic architecture of the system, with the intent to talk with customers at their abstraction level and to summarize information useful to evaluate the risks and to define well-founded plans for software development. 4

15 Thanks to Eclipse-based technologies, appropriate application-oriented conceptual spaces can be defined as meta-models introduced as custom domain specific languages (DSL). According to the MDSD[2] approach, model-to-model (M2M) and model-to-code (M2C) transformers can provide a custom Software Factory able to reduce the gap between models and code and to produce in automatic way the intrinsic systematic of an infrastructure as part of an user-defined design. MDSD promotes also the possibility to organize in a structured and unambiguous way the cooperation among the workers of a team. In fact, people working on the application logic (called from now on application designers) can define in a formal way new abstractions peculiar to the application domain. On the other hand, the team members more involved into the technical details of a infrastructure (called from now on system designers) can produce not only new operational platforms tailored to application needs, but also new concepts usable as they were primitive. New primitive concepts, defined by keeping into account specific application problems, are essential to face in an effective way the analysis and the design phase of modern software systems 1. Each software company could define, implement and use its own set of primitive concepts, by providing a custom IDE, based, in its turn, on custom meta-models usable as conventional (domain specific) languages. The activities of a team can be planned around this custom IDE that becomes the main artifact able to explicitly represent and transmit the knowledge and the know-how of the company both in the application domain and in the (relationship with the) supporting technologies. The aim of this work is to discuss these perspectives with reference to Contact [1], a language (a meta-model) that has been defined by exploiting Eclipse, Eclipse EMF[3] and the Xtext2.0[4] framework. The aim of Contact is to help application designers in: i) building models of high-level communication patterns that can be used as a new form of source code; ii) defining in a systematic way related to the definition of the operational semantics of the language the communication infrastructure; and iii) creating the IDE (Contact-ide in the following) that makes the language usable. The work is structured as follows. The Section 2 introduces the Contact meta model and gives an informal overview of its conceptual space, by introducing the primitives that the language provides. The Section 3 discusses the impact of Contact on the production process with reference to an example. The collaboration between application and system designers is discussed in Section 4, with reference to a set of technical and logical problems that can arise when the system must be transformed from a prototype to a true distributed system. This section gives also some detail on how the model-driven approach helps in structuring an application as a layered system in which each layer is associated to a proper meta-model. Finally Section 5 is devoted to the conclusions. 1 Imagine what could be a modern software production process without concepts like loop. collection, socket, object, class, process, agent etc 5

16 2 The Contact meta-model It is quite common to say that, in order to communicate, two software entities should exchange messages. Since sentences such as send a message or receive a message are not well defined, a more appropriate vocabulary for message-based interaction is needed. The main goal of the Contact language is to provide a conceptual space (and an associated vocabulary) to express a basic set of high-level forms of communication. The Contact conceptual space is based on a Message ontology defined in XText 2 (only a subset of the message types is shown): Message: OutOnlyMessage OutInMessage; OutOnlyMessage: Signal Dispatch ; OutInMessage: Request Invitation; OutOnlyMessage: informationthatasubjectsends(tosome other subject) without any expectation to receive a reply related to that message. OutInMessage: information that a subject sends (to some other subject) with the expectation to receive some reply (e.g. an ack, an answer, etc.) related to that message. Each Message type is associated with a pair of high level operations (one to send information and one to receive information) like those written in bold in Table 1, that reports an informal description of the Message semantics 3.The exact semantics of each term of the vocabulary is (operationally) defined by the system designer (see Subsection 4.1), which concurs also to the definition of the language with appropriate feedbacks. MsgType Informal meaning Signal a(outonlymessage) messagethatasubjectcanemit on the sharedspace; asignalcan be sensed by N>=0 time uncoupled subjects. Example: aclickofthemouse(asignalthat can be perceived by a window). Dispatch a(outonlymessage) messagethatasubjectcanforward to one specific receiver-subject, with the expectation that it will serve it. Example: amessagesentbyageneraltohis colonels on the battlefield. Invitation a(outinmessage) messagethatasubjectcanask to ND>=1 receivers, with the expectation to acquire NR>=0 acknowledgments (ack); a receiver will accept an invitation and will reply with an ack to the sender. Example: amessagesentbyagovernmentofacountrytoall its ambassadors in order to do something. Request a(outinmessage) messagethatasubjectcandemand to ND>=1 receivers, with the expectation to acquire NR>=0 responses; a receiver will grant arequestandwillanswer to the sender with a response. Example: amessagesenttoknowsomething. Table 1. Message informal semantics The main idea underlying the Contact conceptual space is that a distributed system is composed of a set of entities, called Subjects 4, each associated with a unique name; the subjects can exchange information via the sharedspace abstraction. The sharedspace defines basic operations to write (out), read (rd,rdw) or consume (in) information defined by an interface named ILindaLike. 2 Thus, each Contact specification is also a model, instance of a meta-model. 3 This vocabulary is open-ended, since it is proposed to capture communication patterns that frequently occur in the application domain. 4 This term has been used to avoid confusion with Object, Process, Agent, etc. 6

17 ILindaLike public interface ILindaLike { public IMessage in(string query) throws Exception; public IMessage rd(int LastMsgNum, String querymsg) throws Exception; public IMessage rdw(int LastMsgNum, String querymsg) throws Exception; public void out( String msg ) throws Exception; public Vector<IMessage> inmany(vector<string> tokens) throws Exception; public IMessage selectonefrommany(int msgnum,vector<imessage> queries) throws Exception; public void terminate() throws Exception; } ILindaLike operations are used as the reference machine to define the operational semantics of Contact (see Subsection 4.1). High-level communication patterns are associated to the Message types and can be expressed by means of a set of HighLevelOperation defined in XText as follows: Concrete syntax(contact) HighLevelOperation: OutOperation InOperation ; OutOperation: emitsignal forwarddispatch demandrequest askinvitation ; InOperation: InAcquireOperation InPerceiveOperation; InAcquireOperation: servedispatch grantrequest acceptinvitation; InPerceiveOperation: sensesignal ; Abstract syntax(medcl) IntermediateOperation: OpIn OpOut; OpIn: OpToPerceiveInfo OpToAcquireInfo OpToAcquireManyInfo ; OpOut: OpToEmitInfo OpToSendToOne OpToSendToMany ; An OutOperation is an instance of OpOut. An InOperation is an instance of OpIn. OpOut: usedtosendinformation. OpIn: usedtoacquireinformation. The definition of the language includes a concrete syntax (the Contact language itself) and an abstract syntax expressed by the intermediate language medcl. High-level operations can be viewed as a set of primitives whose concrete notation is provided by Contact and whose semantics is defined by a run time support built over on a lower-level support that implements the ILindaLike interface according to the meaning given to the medcl meta-model (see Subsection 4.1). The ILindaLike interface can be ignored by the application designer, since the behavior of each Subject is conceived, at application level, as a finite state machine (FSM) whose state transitions are associated to application-specific, generated communication methods, whose structure can be sketched as follows: Output operation scheme <AnswerType> hl_<sendername>_<operationname>_<messageid>_<receivername>(string M){ ILindaLike support = PlatformExpert.findOutSupport(<ReceiverName>,<messageId>,<SenderName>); <AnswerType> answer=<sendername>_<operationname>_<messageid>_<receivername>( M,support ); return answer; } Input operation scheme <ReturnType> hl_<receivername>_<operationname>_<messageid>(){ ILindaLike support = PlatformExpert.findInSupport( <ReceiverName>,<messageId>,<WithAnswer>); <ReturnType> answer=<receivername>_<operationname>_<messageid>( support ); return answer; } 7

18 An application-specific method starts by calling the PlatformExpert object, so to dynamically find (or build) the right communication run-time support (Section 4); then it calls a corresponding low-level operation that defines the operational semantics in terms of ILindaLike operations by giving to it the support to perform the required communication actions. The following table shows the types that can be assumed by the object returned by a Contact operation. AnswerType void: whennoreplyisexpectedbythecaller. IAcquireOneReply: when the caller expects to receive back just one reply. IAcquireManyReply: when the caller expects to receive one or more reply. ReturnType IMessage: when the receiver does not have to send any reply to the caller (see Subsection 4.1). IMessageAndContext: when the receiver must create and send a reply to the caller. The objects returned by a Contact operation can be used by the application designer to check for the availability of a message or of a reply and to get it. IMessageAndContext public interface IMessageAndContext { public void replytocaller(string msg); public IMessage getreceivedmessage(); } The getreceivedmessage returns the received message, while the replytocaller sends the reply (ack, answer etc.) to the Subject that has sent that message. IAcquireOneReply public interface IAcquireOneReply{ public boolean replyavailable(); public IMessage acquirereply() ; } IAcquireManyReply public interface IAcquireManyReply { public int numofreplyexpected(); public int numofreplyreceived(); public IMessage acquirereply(int n); } The acquirereply operation is a blocking operation that returns a reply message if it is available. The availability of a message can be tested using the replyavailable operation. The availability of a message can be tested using the numofreplyreceived operations, while the numofreplyexpected returns the number of reply that could be received. 3 The impact on the production process This section presents the usage of the Contact language with reference to a (simple) case-study: the definition of a dynamically reconfigurable distributed software system that finds all prime numbers up to a specified integer, using the algorithm known as Sieve of Eratosthenes. The initial system configuration is made of a pipeline of three elements: i) a generator of natural numbers (named intgen) starting from 3; ii) a filter (named filter2) that eliminates all the natural numbers divisible for 2 and iii) a collector of the prime numbers (named sieve). The logical behavior of the system can be informally described as follows. When filter2 receives from intgen anumbernotdivisibleby2 (i.e. 3),itsendssuchanumberto the sieve that stores it as a prime number. Moreover, filter2 reconfigures the pipeline by creating anewfilterthatwilleliminateallthenumbersdivisibleby3, workingasanewelementofthe pipeline inserted between filter2 and the sieve. Inthisway,thenextnumberthatreachesthe sieve will be 5 and a filter for it will be inserted between the filter for 3 and the sieve. 8

19 The behavior logic of a generic filter can be expressed in Java as follows: FilterN public class FilterN extends Thread{ protected int myprime; protected boolean go = true; protected void execfilterwork() { while (go) { IMessage m = getinput(); handleinput( m.msgcontent() ); }// while }} FilterN: handleinput protected String nextfilter = null; protected void handleinput(string msg){ if (checkend(msg)) go = false; else{ int n = Integer.parseInt(msg); if (n % myprime == 0) showmsg( "rejects " + n); else if (nextfilter == null){ sendtosieve( ""+n ); nextfilter=createanotherfilter(n); }else sendtonextfilter( ""+n ); }} This component is conceived as a finite state machine (FSM) that runs in its own Thread. The state transitions is performed by the local method handleinput according to the information received in input. For IMessage see Subsection 4.1. The filter2 component can be logically viewed as an instance of filtern. If msg does not include information to terminate, it represents a natural number (n); if n is not divisible for the filter prime number (myprime) then n is sent to the next element of the pipeline. If the nextfilter variable is not bound, the destination element is the sieve; in this case, a new instance of (FilterN) is created, and the nextfilter variable is bound to the name of such anewfilter. If the nextfilter variable is bound, the nextfilter becomes the destination of the next number not divisible for myprime. The filtern class defines the relevant part of the business logic of the system; to make things simpler, the designer can reasonably decide that all the instances of the filtern class belong to the same JVM; in this case the create operation can be defined as follows: FilterN: createanotherfilter public String createanotherfilter( int n ) throws Exception { FilterN filter = new FilterN(n); filter.start(); return filter.getname(); } The FilterN class is quite easy to implement, once that a proper support for communication is given. But before any implementation, the Contact conceptual space helps an analyst or a designer to express (and evaluate) different applicative scenarios 5. From the specification to a working prototype A Contact specification is introduced in three steps: i) first the system components are defined; ii) then the message types are introduced; iii) finally the communication patterns among the components are specified 6. 5 If the conceptual space is not adequate, it is time to extend the Contact meta-model. 6 In a Contact specification there is (at the moment) no sentence related to the component behavior that can be better expressed in a conventional GPL like Java. 9

20 Subject specification ContactSystem sievesystem; Subject class filtern ; Subject intgen ; Subject sieve ; Subject filter2 inherits filtern ; Message specification Signal nextint ; Dispatch isprime ; Invitation nextval ; Request getprime ; Communication specification intgen emit nextint ; filter2 sense nextint ; filtern accept nextval ; filtern ask nextval to filtern ; filtern forward isprime to sieve ; sieve serve isprime ; sieve grant getprime ; Definition of the components. This specification describes the components of the initial configuration of the system, including the fact that the subject filter2 can be viewed as a specialization of a more generic entity called filtern. Definition of the types of the messages. This specification introduces a wide set of message types, so to have an idea of the conceptual space actually supported by Contact. Definition of the communications roles. A set of constrains that describe with a relational flavor the logical architecture of the system. For the sake of simplicity, the datatypes associated to the messages are omitted. Since most of the communication infrastructure is generated by the Contact-ide, the application designer can produce in a very short time a first working prototype of the system (running on a single JVM), with the aim of further improving the mutual understanding with the customer. What the IDE does (see Figure 2). The Contact-ide generates a Java abstract class for each subject. A subject class has the name SubjSupport where Subj is the name of the subject that extends a predefined abstract Thread named Subject. The application designer must define the application logic into the abstract method dojob by designing a proper specific (communicationdriven) state transition sequence of the subject viewed as a FSM. The business logic finds quite rapidly its proper support, by exploiting the generated support classes. Let us start with the method getinput. getinput // FilterN method protected IMessage getinput() throws Exception{ IMessage m = hl_filtern_accept_nextval(); //defined in FilterNSupport return m; //Filter2 method protected IMessage getinput() throws Exception{ IMessage m = hl_filter2_sense_nextint(); //defined in Filter2Support return m; } The methods of filtern that send information to the other components are: FilterN protected void sendtosieve( String ns ) throws Exception{ hl_filtern_forward_isprime_sieve(ns); //defined in FilterNSupport } protected void sendtonextfilter( String ns ) throws Exception { IAcquireOneReply m=hl_filtern_ask_nextval_filtern(ns,nextfilter);//def. in FilterNSupport showmsg( "got " m.acquirereply().msgcontent() ); } To build a first working prototype, the application designer must define a specialized version of each generated subject support. Let us report here a possible version of the remaining applicative classes, by omitting for the moment the fact that the sieve must grant the request getprime (this case will be discussed in Section 4). 10

21 IntGen public class IntGen extends IntGenSupport{ public IntGen(){ super(); } public void dojob() { for( int n=3; n<9; n++) sendnextint(n); endjob(); } protected void sendnextint(int n){ showmsg( " n=" + n ); hl_intgen_emit_nextint(""+n); } protected void endjob() { hl_intgen_emit_nextint("end"); }} Sieve public class Sieve extends SieveSupport{ private boolean go = true; public Sieve() { super(); } public void dojob() { while( go ){ IMessage m = getinput(); handleinput( m.msgcontent() ); }} protected IMessage getinput(){ IMessage m=hl_sieve_serve_isprime();return m;} protected void handleinput(string msg){ if (msg.contains("end")) go = false; else{ int n = Integer.parseInt( msg ); } }} Running the system: TheContact-ide generates one abstract class for the system as a whole with the name ApplMain where Appl is the name of the system. The ApplMain class includes the logic required to initialize global system properties, to build common support components and the subjects, to configure the system and to start each subject. 4 From the prototype to a distributed system Once the first prototype is validated by the customer, the project team can plan the activities required to build a distributed version of the system, for example a version in which the sieve runs on its own JVM and processor. The analyst immediately recognizes that Filter2 must communicate in two different ways: initially by interacting with the sieve by using some network protocol; then, after the creation of a new filer, Filter2 must interact with the new instance of FilterN by using the implementation of the sharedspace on the common memory, as happens in the first prototype. The architecture of the system has been designed in such a way that no change is required in the subject application code. The transition from the prototype to a distributed system can be made by using a different support for the high-level operations to perform; the decision is delegated to the PlatformExpert component of the Contact runtime. A proper support is automatically created as a consequence of a new Contact specification sentence like the following one: sieve serve isprime support=tcp [ host= port=8070]; 4.1 Co-constructive design The transition from a system working into a single JVM to a distributed system cannot be completely transparent to the application logic. 7 The general strategy adopted in Contact is that the content of a message handled at application level could include also information set by the underlying platform, e.g. an exceptionmessage. However, since distributed systems can pose several problems, the point 7 In fact, several things may happen: i) the attempts to connect with a remote (TCP) port could fail; ii) a receiver on a port could decide to wait for a limited amount of time only; iii) an expected answer/reply does not arrive (within a prefixed time interval), and so on. 11

22 here is not how they are solved by Contact, but that the system designer and the application designer must agree on the best way to make these problems detectable and manageable at application level. As the result of the co-constructive work between application and system designers, the architecture of a Contact system is always composed of three main layers: i) the applicative layer that implements the business logic; ii) an application-support layer (built by a custom software factory) that provides the set of high-level operations required by the business logic; iii) the Contact infrastructure layer based on some implementation of ILindaLike (Section 2) 8. This architecture can be viewed as the result of a conventional design process based on the layer pattern. In our case however, the interfaces provided by each layer are the result of an explicit modeling action and the implementation code is obtained as a M2M transformation based on a stack of languages, each expressing a meta-model and each associated with its own software factory. At the top of the language stack there is Contact, while at the bottom there is a low-level language called corecl that captures the idea that, in order to communicate, two entities must share some medium (e.g. a shared memory space, a communication network, etc.). Between the two there is the intermediate language medcl introduced in Section 2, that defines a set of abstract types of communication operations. The formal definition of the meaning of Contact is performed in two steps, as shown in Figure 1. The M2MContactToMed transformer is a M2M mapper that translates a Contact into an instance of the medcl meta-language. The M2MMedToCore transformer is another M2M mapper that translates a medcl specification into an instance of corecl. The msgcl meta-model defines the structure of the message exchanged at intermediate level; at application level, this structure is expressed by the IMessage interface that follows. Figure 1. M2M transformation chain IMessage public interface IMessage extends IBasicMessage{ public String msgemitter(); public String msgid(); public String msgcontent(); public String msgnum(); } IBasicMessage public interface IBasicMessage { public String getmsgname(); public String getmsgcontent(); public int getmsgseqnum(); } The message interfaces reflect the two layers composing the Contact runtime system and subsume most of the knowledge shared between application and system designers. The application designers can handle the messages by using the IMessage interface only, by ignoring their concrete representation. However, making the structure of messages explicitly visible can improve the understanding of the system and the confidence of application designers in using 8 The implementation on common memory is provided by a class named LindaLike, while the implementation on a network connection is given by a set of objects organized according to suited design patterns. 12

23 the supports provided by the system designer 9. For this reason, all the messages exchanged within a Contact system are made observable at application level, by using a -o option in the system declaration sentence (e.g. ContactSystem sievesystem -o). When the -o option is selected, the Contact-ide generates a default observer 10 that shows that the internal structure of the messages is 11 : mmm( channelid(subjectid,msgid,content,msgnum), seqnum ) The message representation supports the different Contact communications forms. The structure of the channelid reveals how the sharedspace an abstraction that inherently provides many-tomany communications among time-uncoupled subjects can implement also P2P Contact messages (dispatches, invitations, requests). If two subjects named s1 and s2 declare to send a message with msgid=m to a same subject r, conceptually they make reference to a same logical channel with channelid=r m. The channels s1 r m and s2 r m are used to carry an answer/reply. A (TCP) network connection is viewed as an alternative communication medium. Since each message describes its own logical connection, a single (TCP) connection can be used to support all the P2P communications among the subjects running on the two connected nodes. Multi input. The Figure 2 shows a picture of the Contact-ide gui for the sievesystem and the application code of the sieve subject, that handles two kinds of messages: the dispatch isprime and the request getprime. The methods prepareinput and selectoneinput are provided by the system designer to reduce the complexity of the application code when asubjectmustmanageseveralpossible inputs. prepareinput builds the list of queries to be given as argument to selectoneinput, thatfindsamessage in the local sharedspace that unifies with one of the queries. The receiver works as a local proxy of the sender subject by substituting itself to the real caller; thus the code of a subject is made independent of any network protocol. This goal is achieved by forwarding the message with a modified emitter name into the local sharedspace, asshownbythestructure of messages. sieve isprime( proxyfilter2,isprime,3,0) Figure 2. The Contact-ide 9 Another aspect is the possibility to exploit the sharedspace as an internal knowledgebase that can be consulted at run time to reason about communications. 10 An observer can be also defined by the application designer since the LindaLike class is defined as an observable according to the Observer design pattern. 11 AmessageincludesthesubjectId of the sender; thus a receiver can communicate with a subject that it statically does not known. 13

24 5 Related works and conclusions Software development is a collaborative effort where groups of developers need to maintain (contextual) awareness 12 of how particular tasks or project artifacts are progressing. Since distributed software development offers several theoretical benefits over collocated settings 13, a number of tools and models have been developed (a survey can be found in [5]) to enhance contextual awareness in distributed software development. For example, IBM Jazz [6] aims at introducing a distributed collaboration environment by providing a real-time platform based on the Eclipse IDE for integrating work across the different phases of a software development lifecycle. The Rational Team Concert (RTC) [7] is a plug-in to Jazz that enables contextual awareness by mining relational properties of entities within shared software projects. The relational view of RTC offers the potential to enhance traceability and the monitoring of the state of different entities within aproject. The main vision behind our work is that an important set of relationships formed during the development of modern distributed software systems is often related to the collaboration between two main roles of developers: application designers and system designers; these relationships both structural and social are supposed here to be based on direct and indirect links among the artifacts that comprise a model-driven project. In this vision, since software teams often think by means of the models they design and build [5], the conceptual space related to the meta-models becomes a crucial aspect not only for the common understanding required in every cooperation, but also to achieve an appropriate expressive power during software production. In this perspective, Contact the custom language for communication among software componenets discussed in this work is viewed as a tool able to promote reasoning and cooperation, and the related Contact-ide as an environment able to play an active role in driving cognitive processes in all the phases of a software production: in the analysis phase, to express the interaction implied by the business logic of the problem (abstracting from specific communication supports); in the design phase to define (in a technology-independent way) the overall architecture of the system; in the implementation phase, to improve code readability, modularity and platform independence. The idea of model-driven cooperation around custom languages requires a deep integration between the concepts of domain-specific language (DSL) with the MDSD approach and finds an excellent support by the XText technology, founded on the Eclipse ecosystem. As advocated by the proposers of the Projectional Editing concept 14 [8], in Contact the abstract representation is considered the core definition of a system and the models (expressed as instances of the 12 A context refers to the set of circumstances or facts that surround a particular event or situation, including part of a process with different state transitions. 13 e.g. shortened time-to-market cycles, more rapid response to customer needs, a more effective resource pooling, etc 14 An alternative to SourceEditing is the idea that the core definition of a system should be held in a model and edited through projections 14

25 medcl and corecl metamodels) are conceptually decoupled from their representation (expressed by the Contact specification). templates. Moreover, the stack of Contact meta-models leads to a natural decomposition of a system into a set of layers, each related to a proper (abstract) language and built by a proper software factory. The Contact stack can be used/extended to capture more evolute forms of communication (e.g. those proposed by FIPA [9])). The required cooperative work will be inherently related to the organization of the software architecture and based on artifacts built using languages with a well-defined operational semantics. Without understating the concept of active externalism [10], language semantics is considered here an essential requirement to create contextual awareness information useful to initiate contacts among people, to avoid misunderstanding and to improve the organization of the software production and of the resulting products. The slogan coined by James Hendler for the Semantic Web can be adopted also here: a little semantics goes a long way. One of our possible future works is to investigate how this kind of organization can be supported by Jazz and wether it can be profitably included in the ETC project [11]. References 1. Natali, A., Molesini, A.: Towards model-driven communications. In Ardil, C., ed.: World Academy of Science, Engineering and Technology. Volume 64., Rome, Italy, Academic Science Research (2010) International Conference on Software Engineering and Technology (ICSET 2010). 2. Stahl, T., Voelter, M.: Model-Driven Software Development. Wiley (2006) 3. Steinberg, D., Budinsky, F., Paternostro, M., Merks, E.: EMF: Eclipse Modeling Framework, 2nd Edition. Addison-Wesley Professional (2009) 4. The Eclipse Foundation: XText site: Home page. (2011) 5. Omoronyia, I., Ferguson, J., Roper, M., Wood, M.: Using developer activity data to enhance awareness during collaborative software development. Computer Supported Cooperative Work - The Journal of Collaborative Computing 18 (2009) IBM: Home page. (2011) 7. Krishna, S., Fenstermaker, T.: IBM Rational Team Concert 2 Essentials. Packt Publishing (2011) 8. Merkle, B.: Textual modeling tools: overview and comparison of language workbenches. In: Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion, SPLASH 10, New York, NY, USA, ACM (2010) IEEE FIPA Design Process Documentation and Fragmentation: IEEE FIPA Design Process Documentation and Fragmentation Homepage. (2009) 10. Clark, A., Chalmers, D.: The Extended Mind. The MIT Press (1998) 11. Coccoli, M. Maresca, P., Stanganelli, L.: Enfrocing team cooperation using rational software tools into software engineering academic project. In Coccoli, M., ed.: Eclipse-IT Volume , Savona, Italy, Eclipse Italian Community (2010) The Fifth Workshop of the Italian Eclipse Community. 15

26 Enabling End-User Plug-in Compositions with MASH Leonardo Mariani and Fabrizio Pastore University of Milano - Bicocca Viale Sarca 336, Milano, Italy {mariani,pastore}@disco.unimib.it Abstract. The majority of IDEs are built upon plug-in architectures that support the integration and execution of different tools on a same environment. The current trend is thinking IDEs as craftsman tables that make available a number of ready-to-use tools. Similarly to craftsmen who combine tools according to tasks that need to be completed, software developers need to dynamically and flexibly compose software tools to effectively develop and analyze software. Unfortunately, IDEs provide little support to the design of tool compositions that have not been foreseen by plug-in developers. Any type of custom analysis must be manually coded from the plug-in API. It results that plug-in integration remains a complex activity reserved to expert plug-in developers with a deep understanding of the underlying environment. This paper describes MASH, an Eclipse plug-in that augments the Eclipse IDE with the concepts of Plug-in Tasks and Workflow of Plug-in Tasks. In our vision, IDE users must be able to integrate both plug-ins and their results by using simple visual formalisms, with limited, and possibly without, coding effort. The MASH workflows go into this direction supporting plug-in execution, plug-in integration, and hierarchical composition of workflows. Plug-in developers can design plug-ins that export functionality as executable tasks (Task-Based plug-ins) ready to be integrated within MASH workflows. The effort of translating regular plug-ins into Task-Based plug-ins is particularly small thank to the task extraction process described in this paper, which is based on the TPTP capture and replay technology. Early experience with MASH confirms our intuition that MASH workflows can be used to quickly implement custom analyses, without requiring significant knowledge about the IDE and the plug-ins API. Keywords: Software Engineering, Plug-ins Composition, Visual Languages 16

27 1 Introduction Modern integrated development environments (IDEs) like Eclipse 1, Netbeans 2 or Microsoft Visual Studio 3 are based on plug-in architectures that allow users installing new plug-ins to extend the original IDE functionalities. For example Java developers using Eclipse can install JUnit 4 to automate test case execution, and Eclemma 5 to measure code coverage. The availability of multiple tools in a same environment eases the invention of new analyses that require tool integration. For example software developers can easily obtain a debugging technique by integrating JUnit and Eclemma: JUnit can execute test cases; Eclemma can identify the lines of code covered by each test case; and the likely fault locations can be identified by computing the lines of code that are executed by the failing test cases but are not executed by the passing test cases (well-known automatic debugging techniques like Tarantula [3] are built upon this intuition). Even if integration is simplified by plug-in architectures, IDEs provide little support to the design and automation of tool compositions that have not been foreseen by plug-in developers. Any type of custom composition must be manually coded from the plug-in API. For example, comparing the lines of code executed by failed and passed test cases requires the implementation of a new plug-in, which implies understanding both the specific plug-in architecture that must be used (in our example the Eclipse architecture) and the APIs of the plug-ins that must be composed (in our example JUnit and Eclemma). It results that plug-in integration remains a complex activity reserved to expert plug-in developers with a deep understanding of the underlying environment. This paper presents MASH, a framework that augments IDEs with the concepts of Task-Based Plug-ins (TB-Plugins) and Workflow of TB-Plugins. In our vision, IDE users must be able to integrate both plug-ins and their results by using simple visual formalisms, with limited, and possibly without, coding effort. MASH goes into this direction by supporting the definition and execution of workflows that combine plug-in functionalities. A TB-plug-in is a plug-in that exposes its core functionalities as tasks that may be composed by end-users in workflows. Plug-ins commonly provide functionalities through widgets (e.g. buttons) that are available to IDE users through a GUI, and APIs that are used by the plug-in developers who want to reuse plug-in functionalities. MASH bridges the gap between the user and programmer views by: providing a visual editor for the definition of workflows that execute multiple tools (implemented as Eclipse plug-ins) and integrate tool results. Workflows

28 are persisted within projects, and can be automatically executed and reexecuted; introducing the concept of plug-in Task, a program interface with inputs and outputs that can be instantiated by users through a visual workflow editor; supporting the design of code scripts that can directly execute plug-in APIs; supporting the interactive design of workflows using recording functions that capture sequences of GUI events (e.g. entering text in a text box or clicking on the OK button) that can be synthesized as Tasks. MASH can benefit from the recent trend of using Eclipse to build rich client applications. In particular, MASH could be used to combine the functionality of generic software systems and not only IDEs, such as CCTVnet 6,whichisa video/monitoring recording software, and ProgmateDoc 7,whichisadocument management system. Our implementation of MASH consists of an Eclipse plug-in that augments Eclipse with the notions of TB-plug-in and workflow of TB-plug-ins. This paper extends the preliminary results described in [7] by: producing a more detailed description of the MASH architecture, extending the concept of Task Based plug-ins to include APIs and GUI functionalities, and evaluating MASH on two plug-in compositions. Early results show that workflows can be easily designed with little a-priori knowledge about the IDE and the plug-ins API, save the effort otherwise devoted to the implementation of additional plug-ins and glue-code, and produce analyses that can be quickly modified and reused. The paper is organized as follow. Section 2 presents the MASH vision. Section 3 presents how we implemented MASH in Eclipse. Section 4 describes a workflow that combines Eclemma and JUnit. Section 5 presents early results. Section 6 discusses related work. Finally, Section 7 summarizes the work and outlines future research directions. 2 Supporting End-Users plug-in composition We envision IDEs as environments where plug-ins can be integrated and composed through pre-defined and user-defined task flows. The conceptual architecture that enables this vision is shown in Figure 1. The top area in Figure 1 shows the structure of plug-ins installed on the IDE. In our vision the functionalities exposed by plug-ins play a central role. Plug-ins export their functionalities by implementing standard extension mechanisms, that is by providing APIs that can be programmatically reused, and by providing widgets that extend the IDE GUI. In addition plug-ins export their functionalities by declaring tasks and workflows. A task is an executable unit of work with a name, inputs, outputs and a configuration. Standard plug-ins can be reified as Task Based plug-ins (TB-plugins), by simply implementing proxy TB-plug-ins that declare tasks and reuse the

29 ! " Fig. 1. The MASH architecture functionalities in the original plug-ins. Plug-ins Plug-in2 and TB-plug-in2 in Figure 1 represent the case of a sample plug-in reified as a TB-plug-in. Plug-ins may furthermore export predefined workflows that can be used and executed by end-users similarly to tasks. The major difference between workflows and tasks exported by plug-ins is that tasks are directly executed by the plug-in, while workflows are executed by a workflow engine. Workflows declare only the names of the tasks they execute, while tasks implementation reside in different plug-ins. Workflows exported by plug-ins represent execution flows that are immediately available to IDE users. Plug-in developers can implement these workflows to represent the typical flows associated with a plug-in. Endusers can instantiate a pre-defined workflow without the need of understanding the internal details of the plug-in. In addition to execute workflows exported by plug-ins, IDE users can create new workflows, optionally starting from the ones distributed with the plug-ins. The bottom area in Figure 1 represents the MASH framework. MASH integrates a workflow engine for running workflows. In addition, MASH provides task and workflow adapters that allow users to execute the plug-in functionalities in a workflow. MASH provides three different task adapters that transparently allow users to compose workflows combining the different kind of functionality exposed by plug-ins: tasks defined in plug-ins (plug-in task adapter), APIs that can be used in programs implemented in the workspace (workspace task adapter), and widgets (GUI task adapter). Task adapters decorate tasks with the capability to persist results in the Task Space (which is a persistent area that the MASH framework reserves to the task), and the handling of the task lifecycle. At runtime adapters bind the task/workflow instances in a worflow with their corresponding implementation. The plug-in task adapter loads the implementation of a task from the plug-ins installed in the system. The workspace task adapter loads the implementation of a task from the workspace where the workflow is executed. In this case users indicate the name of the class to be loaded as task. The GUI task adapter loads a task defined as a sequence of GUI events 19

30 previously recorded by users. The workflow adapter similarly decorates workflows with the support to workflow loading and the handling of the workflow lifecycle.!"#!"# & $% &"# %'!"# ( Fig. 2. Users activities in the MASH workspace Figure 2 shows the activities that users may perform when working in the IDE workspace using MASH: instantiate workflows defined in plug-ins; define workflows as compositions of existing tasks and workflows; create hierarchical workflows; write scripts and use them as tasks to easily implement glue-code; define new tasks as classes in the workspace that might use the APIs exposed by the plug-ins installed in the IDE (note that a task differs from a script because it has an associated task-space and a configuration); capture sequences of GUI events and instantiate them as GUI-tasks in the workflow. 3 MASH for Eclipse We implemented MASH as an Eclipse plug-in. The MASH plug-in extends Eclipse to support the definition and execution of workflows of plug-in tasks. MASH reuses the Eclipse extension point mechanism to define task and workflow adapters as extension points that are extended by plug-ins. This mechanism allows plug-ins to automatically inherit the behavior in the adapters in a clean and elegant way. MASH reuses two Eclipse plug-ins: JOpera [9], which provides 20

31 a workflow engine and editor, and TPTP Automated GUI Recorder 8, a capture and replay toolset. JOpera provides a workflow engine which supports a number of advanced features typical of workflow engines and extremely useful when designing tool integration, such as parallelism, loops, conditions and data-flow. JOpera comes with an editor for the definition of the task instances that must be executed within workflows. MASH automatically populates the list of the available tasks with the tasks defined by the TB-plug-ins installed in the IDE. Plug-in tasks are defined by plug-in developers by extending the extension point Task, provided by MASH. Tasks are implemented as classes that implement the ITask interface by defining a run method that executes the task. The method run is automatically invoked by MASH during the execution of a workflow. In general, tasks can have multiple inputs and outputs. For this reason the run method works with two maps: ITaskInput and ITaskOutput. The ITaskInput map is passed by MASH to the run method, and contains the input values of the task. The ITaskOutput map is populated and returned by the task as a result of the execution. Workspace tasks are defined by users by implementing a Java class that extends the WorkspaceTask class provided by MASH and by creating a new task in the JOpera editor with the same name of the implemented class. GUI Tasks are defined thanks to the TPTP Automated GUI Recorder, an Eclipse plug-in that allows software developers to capture the sequence of GUI events generated by a user that interact with a GUI and to reproduce them as GUI test. MASH uses the Automated GUI Recorder APIs to save the captured events as xml scripts, that are loaded by MASH when a GUI task is executed within a workflow. MASH provides a menu that allows users to capture GUI events and automatically defines a GUI Task that can be instantiated and executed within a workflow. For each GUI Task MASH generates task-inputs that the users can modify to execute a recorded event with different values (e.g., changing the text entered in a text field). MASH workflows are defined within a particular type of Eclipse project named MASH project. MASH provides an Eclipse wizard that supports users in the definition of new MASH projects. MASH projects are also Java and JOpera projects, thus users can benefit from the feature of both the JOpera and the Java perspectives, like editing and executing workflows, or writing and testing Java classes. MASH allows users to reuse existing workflows in three different ways: by instantiating a workflow defined in a plug-in, by copying and pasting workflow files defined in other workspaces or projects, or by instantiating a workflow defined in a referenced project. A MASH project contains all the data generated by the tasks executed in the workflows: The Task Space associated to each executed task, the serialized outputs of the executed tasks, and the configuration of each task. MASH organizes Task Spaces in a directory tree created within the MASH project. MASH

32 serializes the outputs of each task in a file and loads the serialized data when users need to inspect them after workflow execution. Some user defined tasks may need complex configurations. For this reason MASH provides the TaskConfigurationEditor extension point that can be used by plug-in developers to define a configuration panel for each Task. In this way developers can programmatically define an ad-hoc GUI that is displayed by MASH when users need to configure a Task. During workflow execution, MASH passes the TaskConfiguration object to the task which can then behave accordingly the configuration. Outputs produced by plug-ins may require the implementation of ad-hoc editors. MASH natively supports the creation of these associations through the extension-point TaskOutputEditor. This extension point can be extended to associate editors with the Task outputs. IDE users can manually edit task outputs and then partially re-execute workflows to run what if analysis. MASH is freely available at along with some video tutorials. 4 Composing Eclemma and JUnit with MASH The top area of Figure 3 shows the MASH workflows that combine Eclemma and JUnit to support fault diagnosis. The bottom left area of Figure 3 shows the Eclipse workspace. The Debugging project is automatically created by MASH when the user edits the workflows, while the textitmyprogram project is the program analyzed by the workflow. The bottom right area of Figure 3 shows the plug-ins used by the sample workflow. Dotted arrows indicate the plug-in executed by each task represented in the workflow. The main workflow, namely project workflow shown at the top of Figure 3, executes two instances of the workflow Coverage (shown at the top right area of Figure 3). The two instances are named CoverPassingTests and CoverFailingTests. Theproject workflow receives as input two parameters, passingtest- Cases and failingtestcases, that are set by users the first time they run the workflow (this feature is provided by the JOpera editor). The project workflow passes the values of input parameters passingtestcases and failingtestcases to workflows CoverPassingTests and CoverFailingTests respectively. The results produced by CoverPassingTests and CoverFailingTests are passed to the task FindBugs. FindBugs is an instance of the plug-in task CalculateSpectraResults. CalculateSpectraResults is a task implemented by PSA, an Eclipse plug-in that compares the lines covered in passing and failing executions to find bugs. Instead of using PSA users could write a workspace task that implements the same behavior. The Coverage workflow is composed by three tasks: ExecuteTestCases, ExportCoverage, and FilterCoverage. TheCoverage workflow receives as input one parameter, testclass which is the name of the test class to execute, and is set by the workflow that instantiates the Coverage workflow. Task ExecuteTestCases is a GUI task that we recorded using MASH. This task executes a right click 22

33 & $%&% %&%! " "# "! & " $ *!! ' $!! $ &% &% (" ( ) " $ +&% Fig. 3. The MASH Debugging Workflow on the test case class in the Eclipse view package explorer, presses the menu button Coverage as.., and then presses the button JUnit Test to execute the test case. ExportCoverage is a plug-in task provided by the plug-in Eclemma-Mash that exports coverage data. Since Eclemma is not a TB-plug-in, we implemented Eclemma-Mash as a TB-plug-in that reifies Eclemma by providing some of its core functionalities as tasks. FilterCoverage is a workspace task implemented in a class defined in the workspace. This task class reads the coverage file generated by Eclemma-Mash and removes data about the lines of code covered in the classes that implement the text cases because test cases are not the target of the test. Figure 4 shows some screenshots of the MASH widgets used to define and run the Debugging workflow: (a) the Eclipse project resources, (b) the workflow editor with the executed tasks highlighted in blue, (c) the FindBugs task output editor, (d) the MASH project creation wizard, (e) the FindBugs task configuration editor provided by PSA, (f) the workflow run dialog. 23

34 Fig. 4. The MASH widgets used to define the Debugging workflow 5 Preliminary Evaluation To preliminary evaluate the effectiveness of MASH we compared the effort required to define two different plug-in compositions with and without MASH. Table 1 presents the results. Case study Coding MASH LOC CVS Commits Lines Modified Tasks Edges Log Analysis Bug Finder Table 1. Effort required to implement plug-in compositions with and without MASH. Column Case study lists the two case studies. Log Analysis is a workflow that processes the log files recorded in valid and failing executions to identify anomalous log messages that can be used for root cause analysis. The Log Analysis workflow is detailed in [7]. BugFinder is the workflow described in Section 4. Columns Coding and MASH show data about the effort required to implement the two workflows without and with MASH. We implemented the Coding cases as Eclipse plug-ins and we wrote the Java code necessary to compose the functionalities. We implemented the MASH case studies by designing the two workflows with MASH. Column LOC indicates the lines of code required to compose the functionalities of the integrated plug-ins. We also report the number of commits produced by developers (column CVS Commits) and the total number of lines modified by the commits (column Lines Modified) as a measure of the effort required to implement and maintain the workflow (more commits intuitively correspond to more effort). Columns Tasks and Edges measure the effort required to implement the two workflows in terms of the number of tasks that we instantiated in the MASH workflow editor and the number of connections between the tasks that we draw to setup the proper data flow. 24

35 The Log Analysis case study is more complex than Bug Finder. It integrates a greater number of components, which results in more instructions required to manage tasks inputs and outputs. Columns CSV Commits and Lines Modified follow this trend indicating that the most complex case study required also more development and maintenance effort. Even if the measures of effort are not directly comparable, the data in Table 1 suggest that the MASH implementation based on the design of workflows required less effort than the Java implementation of the integration. In fact the workflows include only a few tasks and edges while the coding effort has been substantial (e.g. more than 1000 LOC for the first case study). It is worth to mention that the Coding solution not only required more effort than the MASH solution but also does not provide all the features provided by MASH, such as the possibility to re-execute workflows from an intermediate task. 6 Related work This paper presents MASH a framework that extends the notion of plug-in with TB-plug-in and proposes the adoption of a visual language to model the dynamics of plug-in compositions as workflows. Plug-in architectures are extensively adopted for the development of different type of software systems. Well known examples are IDEs such as Eclipse, or NetBeans 9, content management systems like Joomla 10, or application servers like JBoss 11. Different frameworks that ease the development of software systems based on plug-in architectures have been developed. OSGi 12, Mono.addins 13, and PyUtilib 14 are frameworks that support the development of plug-in based systems in Java,.NET, and Python, respectively. Research on plug-in and component architectures focusses most on the development of frameworks that enable dynamic system reconfiguration and adaptation rather than on the end-user customization of component interactions. In fact plug-in architectures have been extended to cope with self-adaptation and configuration [5], dynamic updates [2], and dynamic discovery of components [12]. However, IDE users require more flexibility on a user perspective. For instance Ko et al. highlights that end-users are becoming more and more involved in the definition of programs [4]. End-User Software Engineering is a novel research field that aims to incorporate software engineering activities into users existing workflow, without requiring people to substantially change the nature of their work or their priorities [4]. End-User Software Engineering thus support end-users in designing, testing and debugging their programs. The recent

36 survey by Ko et al. on End-User Software Engineering [4] shows that End-User Software Engineering advances in program design regard mostly the definition of techniques that ease the definition of user interfaces, (e.g. spreadsheet [10] and web sites [11]), or that support programming by examples (McDaniel captures GUI events to be reproduced by the program at runtime [8]). MASH contributes to End-User Software Engineering by introducing the composition of Task-Based plug-ins as a mean to improve the IDE functionalities and flexibility. Web applications like Yahoo Pipes 15 highlight the usefulness of frameworks that enable end-users to mashup services provided by different parties. This is also shown by the recent success of commercial products like Automator 16 and Automate 17, that automate the execution of workflows of user actions. Automator is an Apple 18 tool that supports the definition of simple workflows that combine a set of actions provided by the system (e.g. create a new file, or take a screenshot). Automator supports the definition of scripts and the recording of GUI macros to replicate actions. Experienced programmers can create new Automator actions as Objective-C programs. MASH provides functionalities similar to Automator but it is dedicated to IDEs and plug-in architectures. Moreover, when MASH is used with plug-ins natively implemented as TB-plug-ins, its flexibility is definitely higher than simply replying sequences of actions. For example users can configure tasks, customize the recorded workflows, can handle any GUI event produced within Eclipse, and is not limited by the operative system or underlying platform. Visual languages are widely adopted to enable end-user programing [4]. Workflow languages for example are commonly adopted to compose the functionalities provided by third party components, in particular web-services [6] and web mash-ups [1]. MASH exploits the benefits of workflow languages to support the coordination of plug-ins [7]. 7 Conclusion This paper describes how the concept of plug-in can be extended to TB-plug-in to facilitate tool integration within IDEs. To support execution and integration of TB-plug-ins, we defined a core set of functionalities (represented as pluggable adapters) that decorate tasks and workflows and that are provided by the underlying framework, called MASH. We also presented an Eclipse based implementation of MASH and we reported early quantitative data that show the benefits of our framework for tool integration. Future work includes refining the Mash framework and automatically deriving workflows by recording user actions

37 Acknowledgments. This work is partially supported by the European Community under the call FP7-ICT project PINCETTE References 1. Biörnstad, B., Pautasso, C.: Let it flow: Building mashups with data processing pipelines. In: Nitto, E., Ripeanu, M. (eds.) Service-Oriented Computing - ICSOC 2007 Workshops, pp Springer-Verlag (2009) 2. Gregersen, A.R., Jørgensen, B.N.: Towards dynamic plug-in replacement in eclipse plug-in development. In: Proceedings of the 2007 OOPSLA workshop on Eclipse technology exchange. pp Eclipse 07, ACM (2007) 3. Jones, J.A., Harrold, M.J.: Empirical evaluation of the tarantula automatic faultlocalization technique. In: Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering. pp ASE 05, ACM (2005) 4. Ko, A.J., Abraham, R., Beckwith, L., Blackwell, A., Burnett, M., Erwig, M., Scaffidi, C., Lawrance, J., Lieberman, H., Myers, B., Rosson, M.B., Rothermel, G., Shaw, M., Wiedenbeck, S.: The state of the art in end-user software engineering. ACM Computing Surveys 43, 21:1 21:44 (2011) 5. Kramer, J., Magee, J.: Self-managed systems: an architectural challenge. In: 2007 Future of Software Engineering. pp FOSE 07, IEEE Computer Society, Washington, DC, USA (2007) 6. Lin, C., Lu, S., Fei, X., Chebotko, A., Pai, D., Lai, Z., Fotouhi, F., Hua, J.: A reference architecture for scientific workflow management systems and the VIEW SOA solution. IEEE Transactions on Services Computing 2, (2009) 7. Mariani, L., Pastore, F.: Supporting plug-in mashes to ease tool integration. In: First International Workshop on Developing Tools as Plug-ins (TOPI) - colocated with the International Conference on Software Engineering. ICSE 11, IEEE (2011) 8. McDaniel, R.G., Myers, B.A.: Getting more out of programming-by-demonstration. In: Proceedings of the SIGCHI conference on Human factors in computing systems: the CHI is the limit. pp CHI 99, ACM (1999) 9. Pautasso, C., Alonso, G.: The JOpera visual composition language. Journal of Visual Languages and Computing 16, (2005) 10. Powell, S.G., Baker, K.R.: The Art of Modeling with Spreadsheets: Management Science, Spreadsheet Engineering, and Modeling Craft. Wiley (2004) 11. Wolber, D., Su, Y., Chiang, Y.T.: Designing dynamic web pages and persistence in the wysiwyg interface. In: Proceedings of the 7th international conference on Intelligent user interfaces. pp IUI 02, ACM (2002) 12. Wolfinger, R., Loberbauer, M., Jahn, M., Mössenböck, H.: Adding genericity to a plug-in framework. In: Proceedings of the ninth international conference on Generative programming and component engineering. pp GPCE 10, ACM (2010) 27

38 Reverse engineering Java Enterprise Applications in Eclipse Raffael Krebs, Fabrizio Perin Software Composition Group, University of Bern, Switzerland Abstract. Java Enterprise Applications (JEAs) are complex systems composed of various technologies and programming languages other than Java, such as XML or SQL. In this heterogenous context, information is spread across various components and languages and the interactions between different application elements could be hidden. On the other hand, existing reverse engineering and quality assurance techniques are unable to analyze JEAs since they are focused on specific components or languages. In this paper we present our approach to enhance the Eclipse IDE to analyze these complex systems. We extended a meta-model for Object- Oriented systems to accommodate the heterogeneous nature of JEAs. By modeling JEAs we can support different kinds of analysis based on software visualizations and software metrics. We implemented an Eclipse plug-in to analyze JEAs called Vera to make this solution available in one of the most largely used IDE. The integration with the development environment makes the developers keep focused on a single tool instead of relying on several once. We demonstrate Vera by implementing a well known polymetric visualization, the System Complexity view, and an improved version of the Transaction Flow visualization. The latter shows what can be done by integrating information spread across different sources. We also present a browser that provides an analytical view of the code. Keywords: Reverse engineering, Enterprise Applications, Eclipse plug-in, Visualizations. 1 Introduction Since Java 2 Platform Enterprise Edition (J2EE) was introduced in 1999 it has become one of the standard technologies for enterprise application development. J2EE applications are complex systems composed of various technologies that in turn rely on languages other than Java, such as XML or SQL. Given the complexity of these applications, the need to reverse engineer them to support further development becomes critical. Over the years a lot of software analysis techniques and tools have been developed but all of them are focused on a single language. 28

39 In the heterogenous context of JEAs applying these techniques would result in losing the overview on the system or missing some important aspects about the interaction among its multiple components. Moreover some tools for software analysis are not part of the development environment but they are stand-alone applications. Therefore a developer have to perform a context switch every time he wants to use one of these tools. The context switch can result in a loss of focus on the problem to investigate and it is time consuming. In this paper we present our approach to support the analysis of Java enterprise applications (JEAs) within Eclipse, one of the most widely used Java development environments. To achieve this goal we develop an Eclipse plug-in called Vera. The plug-in provides a meta-model for JEAs[1] that can be extended with more entities to represent a wider range of JEAs components. This meta-model is based on FAMIX [2], a language independent meta-model that describes the static structure of object-oriented software systems. Vera implements two software visualizations, one of them is specific to analyze transaction scope in JEAs. The visualizations of Vera are implemented using Draw2D 1, a lightweight toolkit for displaying graphical components on a Standard Widget Toolkit 2 (SWT) canvas. By using this toolkit it is possible to craft more software visualizations and attach them to the proper extension points provided by Vera. With the purpose to provide a different way to browse and to inspect the code, Vera implements a browser called model browser that highlights information such as relationships among software components or software metrics computed on the software entity selected by the user. We demonstrate the efficiency of Vera by implementing a polymetric visualization known as System Complexity[3] and an improved version of the Transaction Flow visualization[4]. We also implement a model browser that provides an analytical view of the code to analyze. Vera is available on-line 3 and can be install like any other Eclipse plug-in. The rest of the paper is structured as follows: In section 2 we relate our approach to previous work and we present the problem. In section 3 we present Vera and we describe implementation details of the tool. One of the most important requirement of Vera is the extensibility thus is section 4 we describe how to extend Vera and enable the analysis of Java annotations. Finally in section 5 we summarize our results, we describe the future work and we conclude. 2 Problem This section lists some existing software analysis tools and we present the problem Vera is meant to solve. Moose[5] is an extensive platform for software and data analysis developed in Smalltalk. It includes various utilities and relies on several tools ranging from importing and parsing data, to modeling, to scripting software visualizations. One

40 core element of Moose is FAMIX [2], a language independent meta-model that describes the static structure of object-oriented software systems. By using tools such are VerveineJ 4 or infusion (a newer version of iplasma[6]), it is possible to instantiate a FAMIX model from Java source code and then analyze it with Moose. One major drawback from the viewpoint of a Java developer is that Moose is not integrated into any Java IDE. The context switch between Moose and the Java IDE during the development process is distracting and the user can lose the focus on the problem he meant to investigate. By integrating our analysis tool into the development environment we intend to overcome the problems induced by the context switch. Eclipse is a quite widely used Java development environment and therefore well suited to getting software analysis closer to the developer. Vera, as well as Moose, uses the FAMIX model and therefore is potentially interoperable with Moose and other similar tools. Softwarenaut[7] is a static analysis tool that supports architecture recovery through visualization and interactive exploration. Its focus is to provide a meaningful top-down code exploration. The user can increase or decrease the level of detail from a coarse-grained to a very fine-grained view of the system. This kind of code exploration is not Vera s main focus. Instead, Vera is shiped with a set of immutable interactive visualizations which allow the user to visualize software entities and to jump to their definition in the source code. Vera s structure ease the creation of new software visualizations to support the exploration and the analysis of the code. SHriMP Views[8] is a stand-alone Java application that provides flexible visualizations for any type of hierarchically organized information. The user can easily combine visualizations at different levels of detail. Visualizations are not meant to detect certain software flaws but to perform top-down exploration of the code like in Softwarenaut. SHriMP it is not integrated into a Java development environment, so it also suffers of the same context switching problems of Moose. There is an Eclipse plug-in called Creole that is an attempt of integrating ShriMP within the Eclipse IDE. However this plug-in is no longer maintained and constantly crashes with recent versions of Eclipse. Architexa 5 is a commercial Eclipse plug-in that allows the user to create UML diagrams of source code in an explorative manner and it is focused on a smooth user experience. Since Architexa is a commercial product the users cannot extend it to fit their own needs, their possibilities are limited to what that company thinks is useful. Vera has been developed with the purpose of being extensible. New visualizations, metrics or queries can be created to highlight different software aspects since Vera relies on an abstract representation of the code. incode[9] is an Eclipse plug-in that supports the user in software quality assessment. The most relevant feature of incode are: On-the-fly detection of design flaws, automated refactoring for correcting the flaws, architectural assessment, interactive code visualizations etc. incode uses JMondrian[10] to draw the

41 software visualizations that are interactive but cannot be customized and, unlike Vera, it focuses purely on Java code. The functionalities provided by incode were originally developed for infusion (formerly iplasma[6]), another stand-alone analysis program for Java, C# and C++. X-Ray 6 is another Eclise plug-in which provides some source code visualizations. X-Ray is open-source, so it is possible for other plug-ins to use its model, e. g., plug-ins like Citilyzer 6 or Proximity Alert 6 rely on X-Ray s model to create their own visualizations. X-Ray differs from Vera since it is only focus on Java code. Vera on the other hand relies on a meta-model that can represent all the parts composing a JEA and, by doing so, it enables crosscutting analysis that include not only the Java code e. g.,vera s first main visualization, the Transaction Flow view, requires information from both Java source files and an XML file. MoDisco 7 is an extensible framework to develop model-driven tools to support use-cases of existing software modernization. One main difference between Vera and MoDisco is the technology used to support the analysis of heterogenous applications. Vera is based on FAME while MoDisco relies on Ecore. FAME is a superset of a subset of EMOF that has feature comparable to Ecore since also Ecore is based on EMOF. Anyhow, FAME is simpler than Ecore and so more clear to understand and easier to extend. Since FAME is self describing it is possible to exchange model and meta-model definitions using the same mechanism. Therefore we choose FAME as meta-meta-model because it is possible to share information with the tools developed in the very active Moose ecosystem. Vera s final purpose is to be a simple tool to support code understanding and related activities through software visualizations and software metrics. MoDisco seems to have a larger scope since it tries to support the full process of software analyses and modernization. We list the main features of the tools presented in Table 1. For each tool we also gives a qualitative estimation about how good a feature is implemented. Regarding MoDisco we based our evaluation based just on the documentation we found on-line. 3 Vera In this section we describe our solution and we expose the implementation of Vera. We describe the overall architecture of our tool and then we detail the single components composing it. Vera provides a base to analyze JEAs within Eclipse, it support the use of software visualizations and it is extensible. The Transaction Flow visualization implemented in Vera is an example of the capabilities of Vera to deal with JEAs. Prior to EJB 3.0, the JEA transaction attributes had to be specified in an XML configuration file. So the information was spread between a Java class and a XML file. By relying on a unified meta-model we can integrate information

42 SW Visualizations IDE integration Extensible JEAs Moose Softwarenaut ++ Shrimp / Creole ++ infusion / incode + ++ Architexa X-Ray MoDisco? Vera Table 1. Features of the most relevant applications that support software understanding and analysis. (+: decent, ++: good) from different sources and enable new kind of analysis. The integration with the development environment overcame the problem related to the context switching to another tool and keep the developers focus on the problem they intend to solve. Vera can be extended by adding to its meta-model new entities and by extending information importers. By using Draw2D to implement software visualizations, Vera gives the possibility to the users to craft new custom visualizations on the software model. VERA Eclipse Plug-in Model Browser SW Visualizations MODEL repository (FM) FAME (FM3) FAMIX (FM2) Importers JEA Source Code Fig. 1. Architecture of Vera Figure 1 illustrates Vera s architecture which is composed of three main parts: the application model, the importers and the analysis tools. The application model contains the software model generated by the importers as well as the FAMIX meta-model and the Fame meta-meta-model. The importers extract information from the source code or other sources and instantiate the model of the application accordingly. The analysis tools consist for now in two software 32

43 visualizations, the System Complexity view and the Transaction Flow view, and in a model browser that shows analytical information about the software entities. 3.1 The Application Model The application model consists of three components: the FAMIX Model (FM), the FAMIX Meta-Model (FM2) and the Fame Meta-Meta-Model (FM3). The FM is an instance of the FM2 and it contains all the objects representing the source code. It only exists at runtime, i. e., after the importers are done parsing the source code. The FM is stored in a model repository which is fully accessible from the other layers. The FM objects are also called entities. FM2 is a language independent meta-model that describes the static structure of object-oriented software systems. Vera enriches this meta-model to represent not only object-oriented code but also other aspects peculiar to JEAs such as relational databases or EJBs. The classes implementing FM2 define getter and setter methods for all the properties of the model objects. In addition they define helper methods, some of which are specific for the Java source code. On top of the FM2 classes we introduced a layer of interfaces with the purpose of separating the part of FAMIX that models OO languages from the one that models Java language specific characteristics. These FM2 interfaces define also the methods related to FAMIX properties. In the model repository together with the model entities is stored a meta-description for all the FAMIX types. These meta-descriptions are built at runtime based on annotations on the FM2 interfaces. The meta-descriptions are instances of the FM3 classes which are, together with the annotation types, provided by a Fame implementation in Java[11]. 3.2 Importers There are two importers provided by Vera: The first is a Java importer that uses the Eclipse Java parser to generate an Abstract Syntax Tree (AST) of the Java code. The AST is then visited by the importer to create the entities composing the FAMIX Model. These entities are finally stored into the model repository. The second importer is a parser for EJB deployment descriptors which are XML files. The importer extracts information about the method s transaction attributes and it enriches the Java model with that information. Vera defines an importers extension-point where other importers can hook and by doing so they can be used during the import phase of the project to analyze. Extending plug-ins can alternatively hook their importers during the AST visiting phase. Importer extensions can also specify the order in which the importers must be executed and which kind of dependencies there are among different importers e. g., it is possible to specify that the importer for Java code must run before the importer for the deployment-descriptors. 33

44 3.3 Visualizers One way of bringing the model closer to the user is through software visualizations. Vera adds its own view to the Eclipse workbench for showing visualizations. Therefore, Vera extends the ViewPart class of Eclipse and relies on a number of so called visualizers for the rendering. Further visualizers can be added through the Vera s visualizers extension-point. So far, Vera provides two visualizations, System Complexity[3] and Transaction Flow[4]. To create the software visualizations we used Draw2D toolkit. In an earlier development stage we also evaluated JMondrian[10], the Java implementation of the Mondrian framework[12] to script visualization in Smalltalk. This last framework is less expressive and powerful than Draw2D and it is not constantly maintained. Anyhow, the model of JMondrian is simpler than the one of Draw2D so JMondrian is a good alternative to create very simple visualizations. Draw2D is also part of other frameworks like Zest 8 or GEF 8 that can help the users to create more complex visualizations by adding more layouts and by handling interactions generated by mouse and keyboard. We are not aware of other frameworks that can have the same potentiality of Draw2D, however, Vera is made in such a way that its is actually possible to use different visualization frameworks. 3.4 The Model Browser Another way to expose the information contained into the FM is through the Vera s model browser. Every time a user selects one entity either in a visualization provided by Vera or in the source code editor, the model browser shows the property of that entity e. g., by selecting a class into the Transaction Flow visualization the browser will display software metrics like the number of methods (NOM) or the number of attributes (NOA) of the selected class as well as more standard data like the class name. The model browser entirely relies on the Fame annotations within the meta-model interfaces described earlier. 3.5 User interface Vera adds two views to the Eclipse workbench: the visualization view and the model browser view. These views can be enabled and disabled and it is possible to add them to the standard Java perspective. The standard or the custom visualizations of Vera are displayed within the visualizations view. To facilitate the user in adding custom visualizations, Vera defines a visualizers extension point. For each visualization hooked to the extension point, Vera automatically creates a button in the view s toolbar to make the visualization available. Figure 2(b) shows the visualization panel of Vera displaying the System Complexity visualization[3] of the current project s model. The Vera model browser view, shown in Figure 2(a), exposes information of a single model object contained into the FM. On the left side of the model

45 (a) (b) Fig. 2. Screenshot of Vera s GUI browser all properties of the object are listed. By selecting one of these properties, its value is displayed on the right side of the browser. Multivalued properties are displayed as a list. If the selected property value is a Java entity itself, both the model browser view and the Java editor will jump to that entity. Likewise, whenever a Java entity is selected in the workspace Vera will show the entity s properties into the model browser. 4 Extension Example This section describes an example of how Vera can be extended. In particular, we present a scenario in which we want to enable Vera to analyze Java annotations. Java annotations are not part of the program itself even though they can be added to the Java source code 9. Java annotations carry extra information inside the Java code and they are contained into Java files. By extending Vera we will allow the user to collect information about the Java annotations defined and

46 used into an application and to analyze them. To extend Vera it is necessary to write a new Eclipse plug-in as described in the following sub-sections. 4.1 Extend the meta-model The first step is to extend the meta-model of Vera. For this scenario we decided to add two entities: AnnotationType and AnnotationInstance. As the names suggest the first entity represent the Java annotation types, the second model the Java annotation instances spread around the code. We choose the FAMIX entity type NamedEntity as the superclass of both classes. Together with the two new entities we need to implement two new interfaces IAnnotationType and IAnntotationInstance which should both extend INamedEntity. In the interfaces we need to define the getter methods for the information contained into the new entities e. g., the name of the annotation type, or the list of entities that have been annotated. These methods should be annotated and the interfaces themselves should be annotated as shown in Listing 1. The annotation types as prefix are part of the Fame implementation and their instances are used to attach FM3-related meta-information to Java classes. In other words, these annotations are used to populate the meta-repository. 2 interface IAnnotationInstance extends INamedEntity { 3 5 INamedEntity getannotatedentity(); 6 opposite="instances"} 8 IAnnotationType getannotationtype(); 9 } interface IAnnotationType extends INamedEntity { 13 multivalued=true, derived=true, opposite="annotationtype"} 15 Collection<IAnnotationInstance> getinstances(); 16 } class AnnotationInstance extends NamedEntity implements IAnnotationInstance { 19 // implement the interface methods, add some helper methods 20 } class AnnotationType extends NamedEntity implements IAnnotationType { 23 // implement the interface methods, add some helper methods 24 } Listing 1. Definition of the classes and the interfaces for the Java annotation scenario 36

47 Given that we have implemented the entities in Listing 1, we can declare a meta-model extension in which we feed the central meta-repository with the two new meta-model classes as shown in Listing 2. 1 <plugin> <extension point="ch.unibe.scg.vera.meta-model"> 4 <with class="com.example.annotationtype" /> 5 <with class="com.example.annotationinstance" /> 6 </extension> </plugin> Listing 2. Declaration of the meta-model extension Now that the meta-model has been modified we can instantiate a model containing also information regarding Java annotations. 4.2 Custom importers In this scenario we decided to create two importers; one to import the annotation types, another to import the annotations instances. Since we have to importers we need to declare two AST-importer extensions. Both importers will need to consider just Java files. By running the type importer first, the instance importer can verify that every annotation instance, e. g., of a method, corresponds to a known annotation type. It is possible to ensure the correct execution order of the importers by specifying that the annotation instance importer should run after the annotation type importer as shown in Listing 3. 1 <plugin> <extension point="ch.unibe.scg.vera.importers"> 4 <AST-importer 5 class="com.example.annotationtypeimporter" 6 id="java-annotation-type-importer"> 7 </AST-importer> 8 <AST-importer 9 class="com.example.annotationinstanceimporter" 10 id="java-annotation-importer"> 11 <dependency after="java-annotation-type-importer" /> 12 </AST-importer> 13 </extension> </plugin> Listing 3. Declaration of the Importers extensions 4.3 Expose the data By using the importers we can instantiate a model containing the new FAMIX Entities defined earlier. Since all the information within the model is accessible 37

48 it is possible to expose this information by creating a new Eclipse view and by choose any kind of model representation we like. Instead, we can use Vera s visualizer infrastructure to create a visualization of the model using Draw2D. By considering our scenario we can implement a software visualization like, for instance, the Annotation Constellation 10. To achieve this goal we have to implement a class that constructs the visualization using Draw2D starting from the information within the FAMIX model. This should extend the abstract class Draw2dVisualizer which handles the task of embedding the Draw2D figure into the Vera s visualization view. We then register our new visualizer by declaring a visualizer extension as shown in Listing 4. 1 <plugin> <extension point="ch.unibe.scg.vera.visualizers"> 4 <visualizer 5 title="annotations Constellation" 6 id="com.example.visualizers.annotations" 7 class="com.example.annotationconstellation" 8 icon="icons/foo.png" /> 9 </extension> </plugin> Listing 4. Declaration of the visualizations extensions 5 Conclusion Java Enterprise Applications (JEAs) are complex systems that integrate various technologies which in turn rely on different programming languages other than Java, such as XML or SQL. Modern software analysis tools and techniques are not able to capture important aspects of JEAs because of their heterogenous nature. Few attempts have been made to provide instruments to support the analysis of Enterprise Applications and only one of them is available within a development environment. In this paper we presented Vera, an Eclipse plug-in that aims to support the analysis of JEAs. Vera provides a meta-model for enterprise applications that can be extended with more entities to represent a wider range of JEAs components. By using Draw2D, a lightweight toolkit for displaying graphical components on an SWT Canvas, Vera provides two default software visualizations and gives the possibility to craft more of them. The model browser of Vera highlights information such as relationships with other components or software metrics computed on the software entity selected by the user. In the future we plan to make Vera even easier to extend: We intend to simplify as much as possible the process of adding new components to the metamodel. We plan to integrate a plug-in for scripting visualizations in JRuby. We 10 annotation-constellation 38

49 want to simplify the way in which additional information can be displayed in the model browser. Acknowledgments - We gratefully acknowledge the financial support of the Swiss National Science Foundation for the project Synchronizing Models and Code (SNF Project No , Oct Sept. 2012). We would also want to thank Oscar Nierstrasz and Jorge Ressia for their comments on this paper and their support on this project. References 1. Perin, F.: Enabling the evolution of J2EE applications through reverse engineering and quality assurance. In: Proceedings of the PhD Symposium at the Working Conference on Reverse Engineering (WCRE 2009), IEEE Computer Society Press (October 2009) Tichelaar, S., Ducasse, S., Demeyer, S., Nierstrasz, O.: A meta-model for languageindependent refactoring. In: Proceedings of International Symposium on Principles of Software Evolution (ISPSE 00), IEEE Computer Society Press (2000) Lanza, M., Marinescu, R.: Object-Oriented Metrics in Practice. Springer-Verlag (2006) 4. Perin, F., Gîrba, T., Nierstrasz, O.: Recovery and analysis of transaction scope from scattered information in Java enterprise applications. In: Proceedings of International Conference on Software Maintenance (September 2010) 5. Nierstrasz, O., Ducasse, S., Gîrba, T.: The story of Moose: an agile reengineering environment. In: Proceedings of the European Software Engineering Conference (ESEC/FSE 05), New York NY, ACM Press (2005) 1 10 Invited paper. 6. Marinescu, C., Marinescu, R., Mihancea, P., Ratiu, D., Wettel, R.: iplasma: An integrated platform for quality assessment of object-oriented design. In: Proceedings of the 21st IEEE International Conference on Software Maintenance (ICSM 2005). (2005) Tool demo. 7. Lungu, M., Lanza, M.: Softwarenaut: Exploring hierarchical system decompositions. In: Proceedings of CSMR 2006 (10th European Conference on Software Maintenance and Reengineering), Los Alamitos CA, IEEE Computer Society Press (2006) Storey, M.A., Best, C., Michaud, J.: SHriMP Views: An interactive and customizable environment for software exploration. In: Proceedings of International Workshop on Program Comprehension (IWPC 2001). (2001) 9. incode: incode eclipse plugin for code analysis (2009) JMondrian: JMondrian java implementation of the mondrian information visualization framework (2009) Kuhn, A., Verwaest, T.: FAME, a polyglot library for metamodeling at runtime. In: Workshop on Models at Runtime. (2008) Meyer, M., Gîrba, T., Lungu, M.: Mondrian: An agile visualization framework. In: ACM Symposium on Software Visualization (SoftVis 06), New York, NY, USA, ACM Press (2006)

50 An Eclipse Plug-in for the Identification of Design Pattern Variants Andrea De Lucia, Vincenzo Deufemia, Carmine Gravino, Michele Risi, Genoveffa Tortora Università di Salerno, Fisciano (SA), Italy Abstract. Design patterns are not only beneficial to the forward engineering process but they also help typical reverse engineering activities such as design recovery and program understanding. Indeed, conspicuous insight on the software structure and its internal characteristics are provided by design patterns recovered from source code. In this paper, we present an Eclipse plugin implementing a reverse engineering tool supporting the detection of design patterns and their implementation variants. The plug-in exploits a technique able to recover design pattern instances by combining static analysis, based on visual language parsing, with dynamic analysis, based on source code instrumentation. In particular, the dynamic analysis is performed through the automatic instrumentation of the method calls involved in the candidate pattern instances identified during static analysis. The results obtained from a program monitoring activity are matched against the definitions of the pattern behaviors expressed in terms of monitoring grammars. The plug-in allows software engineers to customize the layout used for the visualization of the recovered instances and the structural and behavioral properties of the design patterns to be recovered. Keywords: Reverse engineering, Design pattern recovery, Eclipse plug-in, Source code analysis, Implementation Variants of Patterns. 1. Introduction A design pattern can be seen as a set of classes, related through aggregation and delegation, which represents a partial solution to a common non-trivial design problem [9]. The definition of a design pattern comes with a canonical form which includes the elements composing the pattern instances and their relationships. The implemented instances of design patterns can diverge from such canonical form for different reasons, such as, due to the chosen software architecture or to additional design requirements. Design patterns are widely used to separate an interface from the different possible implementations, to wrap legacy systems, to encapsulate command requests, to use different platforms, and so on [9]. They represent a useful technique in forward 40

51 engineering since they allow reusing successful practices, to improve communication between designers and to share knowledge between software engineers. However, design patterns also represent useful architectural information that can support a rapid understanding of software design and source code [1] [2] [15] [20]. In reverse engineering of OO software systems they allow to capture relevant information which help the comprehension of the adopted solution. In particular, if a software engineer can understand that a particular design pattern has been used as part of an OO design, he/she can understand the capabilities and limitations of that part of the system. The extraction of design pattern instances from source code can provide reverse engineers with considerable insight on the software structure and its internal characteristics. Unfortunately, since pattern descriptions are abstract, informal, implemented very differently (depending on program language, personal style, design decisions), and not explicitly documented in software source code, their recovery has to be manually performed in most cases. This is an extremely time consuming task. Therefore, researchers have proposed techniques and tools to automatically recover design patterns in a program, which perform either a static analysis by considering the structural requirements of a pattern, or they combine a static and dynamic analysis, by considering both structural and behavioral requirements. Some of such tools consider a single implementation variant for each pattern, such as [14], others aim at detecting variants, such as [25]. In [6] we have presented an approach to recover structural design patterns from OO source code, which combines a diagram-level analysis, by using a parser for visual languages [3], with a source code-level analysis, whereas in [7] we have extended our approach by combining static and dynamic analysis. Such an approach has been implemented in an Eclipse plug-in, named epad (eclipse plug-in for design Pattern Analysis and Detection) [5]. In this paper we present an improved version of epad able to support the specification and the recovery of design pattern variants, and we provide the experimental results achieved on the recovery of design pattern variants. The paper is organized as follows. Section 2 focuses on the design pattern recovery process implemented by epad. Section 3 describes the proposed Eclipse plug-in, whilst Section 4 describes the process of recovery rule specification. Experimental results on design pattern variants are given in Section 5. Conclusions are given in Section The Design Pattern Recovery Process A design pattern is composed of a small number of classes that, through delegation and inheritance, provides a robust and modifiable solution [9]. Design patterns are classified as structural, which concentrate on object composition and their relations in the runtime object structures, creational, which address object instantiation issues, and behavioral, which focus on the internal dynamics and object interaction in the system. epad detects design pattern instances from OO source code through a static analysis, to extract the instances according to their structural properties [6], and a subsequent dynamic analysis, to verify the runtime behavior of the detected instances 41

52 [7]. epad has been implemented as an Eclipse plug-in and provides several visualization functionalities for the analysis of the results of the recovery process [5]. In particular, it provides multi-layouts to visually represent the recovered instances and to access their properties. The proposed tool is fully customizable since it allows engineers to configure the definition of the patterns structure and their behavior and the layout to be used for visualizing their instances. epad is downloadable from epad identifies instances of structural and behavioral design patterns from Java code by applying static and dynamic analyses. Fig. 1 shows the activity diagram describing the recognition process of epad, where rectangles represent data and rounded rectangles represent phases. During the Preliminary Analysis information proper to recover design pattern instances is extracted from input source code and stored in a repository by using the Source Code Extractor. In particular, class diagram information, e.g., the name and type of classes, inheritance and association relationships are exploited to construct the corresponding UML class diagram and stored to be used for the Model Analysis. Information on method declarations and invocations useful to perform the Source Code Analysis are also stored. Fig. 1. The design pattern recovery process During the Structural Analysis the instances of design patterns are identified by analyzing the class diagram structure. This recovery process is organized in two steps. 42

53 In the first step (Model Analysis), the candidate design patterns are identified at a coarse-grained level by analyzing the class diagram information obtained during the Preliminary Analysis and exploiting the Design Pattern Library. In particular, the problem of design pattern recovery is reduced to the problem of recognizing subsentences in the UML class diagram, where each subsentence corresponds to a design pattern instance [6]. In the second step (Source Code Analysis), a fine-grained source code analyzer checks if the identified candidate patterns are correct instances or false positives. This is accomplished by verifying at source code level the declarations and the invocations of the methods of the classes involved in the candidate instances. The definition of the recognition algorithms for these phases can be found in [6]. The set of candidate instances obtained from the Structural Analysis are then given as input to the Behavioral Analysis, together with the specification of the pattern behaviors (i.e., Design Pattern Library), the executable program with a test suite (i.e., Bytecode and Test Cases). The goal is to identify the candidates having a behavior that complies with the pattern definition they are instance of. This is performed in three steps. First, the bytecode of the classes involved in the candidate instances is instrumented (Instrumentation step). The files obtained from instrumentation are executed together with the program to monitor the method calls of the candidate instances on a suitable test suite (Monitoring step). Finally, the obtained method trace is validated by a parser able to recognize the sequence of method calls defining the design pattern behavior (Validation step). Details of the three steps can be found in [7]. 3. The Eclipse Plug-in We decided to implement epad as an Eclipse plug-in in order to enhance epad extensibility and take advantage of the latest development techniques [10]. The plug-in exploits the code analysis tool Source Navigator [21] in order to implement the Source Code Extractor module in Fig. 1. The information on the source code is structured as a set of tables storing information on classes, relationships between classes, method declarations, method invocations, and so on. The Source Code Extractor is invoked by epad when the user selects the folder containing the source code of the software system (Select folder button in Fig. 2). Then, epad automatically creates an Eclipse project containing a copy of the selected source code and the class diagram is built by clicking the Class Diagram button in Fig. 2. epad makes use of the GMF framework [23] to visualize the constructed class diagram in the diagram Eclipse view. The class diagram is saved as an Ecore diagram [22]. The Structural Analysis of the plug-in has been implemented as a parser that takes as input the set of tables obtained from the Source Code Extractor module and produces as output a set of textual descriptions representing the candidate design pattern instances [6]. This analysis is carried out by clicking the Model Analysis button in Fig. 2. The output descriptions of this process include the qualified name of the classes involved in the pattern instances together with the low-level checks to be performed on them. These checks are verified by clicking the Source Code Analysis button in Fig. 2. The pattern descriptions that passed these checks are the output of the Structural Analysis phase and the input of the Behavioral Analysis phase. Fig. 3 shows the results of the structural analysis for JHotDraw version 5.1 [12], a 43

54 tool developed to illustrate the good use of design patterns for designing and documenting systems [13]. The statistics on the recovered instances are textually visualized in the Pattern Instances tab, providing for each class the role it plays. By selecting an instance, the involved classes are highlighted in the diagram view as UML class diagram. As an example, Fig. 3 shows the layout of an instance in the list of retrieved Adapter pattern instances. The colors used to visualize the diagram can be configured by using the color palette associated to the epad view. In case the user selects more than one design pattern instance, the considered design patterns are displayed by using a grid layout and all the involved classes are highlighted in the diagram view. As an example, Fig. 4 shows the layout of four instances of retrieved Composite, Adapter, and two Façade design patterns. A class involved into multiple instances selected by the user, is visualized once and is shared between the different design pattern representations and all the roles played in the recovered instances are suitably highlighted. Fig. 2. Visualization of the selected software system as UML class diagram To instrument the bytecode of the classes involved in the candidate instances we use the Eclipse plug-in Probekit [17], developed within the TPTP (Test and Performance Tools Platform Project) [24]. Probekit allows users to write Java code fragments, named probes, that can be injected at specified points in the classes, such as method entry, method exit, class loading, in order to collect run-time data about objects, instance variables, arguments, exceptions, and so on. To trace the invocation of methods at run-time for each candidate epad generates a probe file, which is able to inject additional Java code at method entry and method exit of all classes of the candidate. The Monitoring is accomplished by executing the instrumented Java program on the set of specified test cases. The output is the sequence of all monitored 44

55 method calls and the order in which they are run, which is then validated against the pattern behavioral specification. Fig. 3. Visualization of a recovered Adapter instance Since the behavioral analysis requires the execution of the software under analysis, the user has first to select the folder containing the bytecode files (Select File button in Fig. 2). Then, when the Profiling button is clicked the Probekit plug-in is activated, which requires the selection of the test cases to be executed on the software system. To accomplish monitoring, epad automatically generates a probe file for each candidate and invokes Probekit to execute the instrumented Java program on the set of specified test cases. For each probe file, the monitoring process produces an XML file containing the sequence of monitored method calls and the order in which they are run. Fig. 4. Visualization of a multiple design pattern instances Such a file describes the behavior of a candidate pattern instance on a test case. Thus, to verify whether the behavior of an instance complies to the definition of Sequence Analysis button 45

56 in Fig. 2). In particular, such algorithm looks for a sequence of messages (in the XML file) exchanged between the objects involved in an instance that satisfies the pattern behavior. The resulting instances are textually visualized in the results view as done for the structural instances. Fig. 5 shows the profiling environment with the frame for selecting the candidates to be monitored. Fig. 5. Selection of candidate instances to be instrumented with Probekit As previously described Fig. 3 and Fig. 4 show the visualization of a single instance of Adapter pattern or a visualization of multiple instances, respectively. Notice that in Fig.3, the classes involved in the pattern are colored with the same color (e.g., AbstractHandle is colored in white and does not play a role in the design pattern) and grouped in boxes according to the role they play. Once a pattern instance is visualized in the view, the users can access the code of the classes involved in the instances to analyze and/or refactor it, by clicking the first button on toolbar of the epad view. When the user analyzes the instances obtained from the recovery process, s/he can classify an instance as false positive by marking the check box Not Valid in the Pattern Instances tab, as shown in Fig. 3. The false positive instances are then highlighted in red and not considered in the summary statistics of the results. 46

57 4. Design Pattern Variant Specification epad allows users to choose the design patterns to be retrieved from the source code through the epad Preferences page. In this page the user can also edit the design pattern recovery rules, having the possibility of considering variants of patterns in the recovery process. In particular, the user can define the structural and/or behavioral rules of a pattern, as well as, the layout used to show the recovered instances as UML class diagram. The structural properties are specified by coarse grained rules defining the relationships between classes or interfaces and fine grained rules exploiting the algorithms EXTEND, INHERITANCE, and DELEGATION described in [6]. As an example, the rule for the State pattern shown in Fig. 6 specifies that a CALLS relationship holds between Context represented by x and State represented by y and an EXTENDS relationship holds between State or ConcreteState represented by y and z, respectively. The behavioral rules are defined as a set of sequences, each describing the message exchanged by objects. As an example, sequence1 in Fig. 6 specifies that a client invokes a method denoted by label A of Context that subsequently invokes a method (i.e., B) of ConcreteState or State and then one of its methods (i.e., D, different from method with label B). Fig. 6 47

58 One of the main challenges in the recognition of instances of design patterns in source code is due to their abstract and informal definition. Indeed, the definition of a design pattern comes with a general form (the two most popular are called GoF form and canonical form), consisting of several sections describing the design structure, participants, collaborations and so on [10]. An intrinsic property of such design pattern definitions is that they can be implemented very differently depending on program language, personal style, design decisions, and so on. Fig. 7. Editor for the specifi In the recent years, many efforts have been devoted to development of tools that automate the recovery of design patterns from source code. Some of such tools consider a single implementation variant for each pattern, others aim at detecting variants. The presence of different implementation variants in software systems and the ability of detection tools of recovery different variants make the comparison of detection tools a challenging activity [16]. 48

59 epad allows to implement variants for a design pattern by modifying its structural properties such as: search algorithm, negative criteria, multi-level inheritance, type of the classes, references, and so on. In particular, a design pattern variant is defined by using the clause VARIANT having associated the name of the variant. The epad Preferences page allows to select a specific variant definition by clicking on a list-view widget. In case the user selects the canonical form specification, epad automatically selects the DEFAULT variant specification (see Fig. 6). Finally, layout information are specified in XML to define how the elements involved in pattern instances have to be arranged as UML class diagram. As an example, Fig. 7 shows the specification for the classical Adapter pattern representation. In particular, the XML allows to specify the displacement of the classes, the visualization of classes playing a particular role in the instance, the relationships line format and the grouping boxes highlighting specific aspects of the design pattern. 5. Experimental Results In this section we report the experimental results achieved by applying epad on JHotDraw. In particular, we considered different implementations for the patterns Adapter (see Fig. 8) and Composite (see Fig. 9). (a) Fig. 8. The structure of the object Adapter pattern (a) and class Adapter pattern (b) (b) (a) Fig. 9. The structure of the canonical Composite pattern (a) and an implementation variant (b) (b) 49

60 Table I shows the results achieved by epad at the end of Structural Analysis, by reporting on the number of instances recovered by Model Analysis and Source Code Analysis, and the achieved precision statistics. Design Pattern # instances from # instances from Model Analysis Source-Code Analysis Precision class Adapter % object Adapter % canonical Composite % variant Composite % Table 1. Results of the Structural Analysis Table I reveals that two object Adapters are recovered with respect to the class Adapter variant. Concerning the precision, we can note that the tool achieved a lower precision with respect to the class Adapter result. Considering the variant Composite, the tool recovered four instances achieving the same precision value but higher with respect to the canonical Composite. The main difference regards the structural properties of the used pattern definitions. 6. Conclusions In this paper we have presented an Eclipse plug-in supporting the detection and analysis of design pattern variants. To the best of our knowledge only RECLIPSE [4] and Ptidej [18] provide configuration functionalities similar to the ones supported by epad. In particular, RECLIPSE allows to graphically where reasonable, its behavior, and to inspect the obtained candidate instances. Ptidej provides a set of tools to evaluate and enhance the quality of object-oriented programs. Among its functionalities, it supports the specification of design patterns and the identification of their instances through a constraint solver [11]. As future work we intend to extend the tool to support the specification of variants based on behavioral rules together with multiple layout representation. This is particular important since diagram layout can significantly affect the comprehension of the pattern instances [19]. Finally, we plan to extend epad by integrating the model checking approach proposed in [8]. References 1. - Journal of Systems and Software, 59, 2001, pp K. Brown, Design reverse- Master Thesis, North Carolina State University, Raleigh NC,

61 3. ual Proceedings of the European Conference on Software Maintenance and Reengineering in Proceedings of the International Conference on Software Engineering, 2010 pp in for the Detection of Design Pattern Instances through Static and Dynamic Analysis in Proceedings of 26th IEEE International Conference on Software Maintenance 10), 2010, pp Journal of System & Software, 18(7), 2009, pp Proceedings of European Conference on Software Maintenance and Reengineering ), 2009, pp Proceedings of European Conference on Software Maintenance and Reengineering E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object- Oriented Software, Addison-Wesley, Menlo Park, CA, E. Gamma, K. Beck, Contributing to Eclipse: Principles, Patterns, and Plugins, Addison- Wesley, Y. Guéhéneuc, IEEE Transactions on Software Engineering, 34(5), 2008, pp JHotDraw: Proceedings of Conference on Object-Oriented Programming, Systems Languages and Applications (Vancouver, British Columbia, Canada, 1992), pp , in Proceedings of Working Conference on Reverse Engineering, Monterey, CA, USA, 1996, pp in Proceedings of International Conference on Software Engineering, Orlando Florida, USA, 2002, pp IEEE Transaction on Software Engineering, 36(4), 2010, pp Probekit. Creating Custom Profilers with Probekit, Ptidej: in Proceedings of the Conference on Software Engineering Education and Training (Pittsburgh, PA, 2010), pp object- Technical Report, University of Maryland, Computer Science Department, College Park MD, SourceNavigator, The Eclipse Modeling Framework The Graphical Modeling Framework TPTP (Test & Performance Tools Platform) ction using Transaction on Software Engineering, 32(11), 2006, pp

62 An Eclipse-based SCA design framework to support coordinated execution of services Fabio Albani 1 Elvinia Riccobene 2 Patrizia Scandurra 1 1 Università degli Studi di Bergamo, DIIMM, Dalmine (BG), Italy [email protected] 2 Università degli Studi di Milano, DTI, Crema (CR), Italy [email protected] Abstract. This paper presents a design framework for coordinated execution of service-oriented applications. The framework is based on the OSOA open standard model Service Component Architecture (SCA) for heterogeneous service assembly and on the formal method Abstract State Machine (ASM) for modeling notions of service behavior, interactions, orchestration, and compensation in an abstract but executable way. The framework was developed by integrating the Eclipse-based SCA Composite Designer, the SCA runtime platform Tuscany, and the simulator AsmetaS of the ASM toolset ASMETA. 1 Introduction Service-oriented applications are playing an important role in several application domains (e.g., information technology, health care, robotics, defense and aerospace, to name a few) since they offer complex and flexible functionalities in widely distributed environments by composing, possibly dynamically on demand, different types of services. Web Services is the most notable example of technology for implementing such components. On top of these service-oriented components, business processes and workflows can be (re-)implemented as composition of services service orchestration or service coordination. However, early designing, prototyping, and testing of the functionality of such assembled service-oriented applications is hardly feasible since services are discoverable, loosely-coupled, and heterogeneous (i.e. they differ in their implementation/middleware technology) components that can only interact with others on compatible interfaces. Concurrency and coordination aspects that are already difficult to address in component-based system design (though extensively studied), are even more exacerbated in service-oriented system design. In order to support the engineering of service-oriented applications, to withstand inevitable faults, and to improve the service quality (such as efficiency and reliability), established foundational theories and high-level formal notations and analysis techniques traditionally used for component-based systems should be revisited and integrated with service development technologies. This paper proposes a formal framework for coordinated execution of heterogeneous service-oriented applications. It relies on the SCA-ASM language [21] 52

63 that combines the OSOA open standard model Service Component Architecture (SCA) [18] for heterogeneous service assembly in a technology agnostic way, with the formal method Abstract State Machine (ASM) [8] able to model notions of service behavior, interactions, orchestration, and compensation [6, 5, 7] in an abstract but executable way. The framework is based on the Eclipse environment. It was developed by integrating the Eclipse-based SCA Composite Designer [22], the SCA runtime platform Tuscany [25], and the simulator AsmetaS of the ASM analysis toolset ASMETA [2]. A designer may use the proposed framework to provide abstract implementations in SCA-ASM of (i) mock components (possibly not yet implemented in code or available as off-the-shelf) or of (ii) core components containing the main service composition or process that coordinates the execution of other components (possibly implemented using different technologies) providing the real computation. He/she can then validate the behavior of the overall assembled application, by configuring these SCA-ASM models in place within an SCAcompliant runtime platform as implementation of (mock or core) components and then execute them together with the other (local or remote) components implementations according to the chosen SCA assembly. This paper is organized as follows. Section 2 provides background on SCA and ASMs. Section 3 describe the proposed framework. Section 4 surveys some related work. Finally, Section 5 concludes the paper. 2 Background on SCA and ASMs Service Component Architecture is an XML-based metadata model that describes the relationships and the deployment of services independently from SOA platforms and middleware programming APIs (as Java, C++, Spring, PHP, BPEL, Web services, etc.). SCA is supported by a graphical notation (a metamodel-based language developed with the Eclipse-EMF) and runtime environments (like Apache Tuscany and FRAscaTI) that enable to create service components, assemble them into a composite application, provide an implementation for them, and then run/debug the resulting composite application. Fig. 1 shows an SCA composite (or SCA assembly) as a collection of SCA components. Following the principles of SOA, loosely coupled service components are used as atomic units or building blocks to build an application. An SCA component is a piece of software that has been configured to provide its business functions (operations) for interaction with the outside world. This interaction is accomplished through: services that are externally visible functions provided by the component; references (functions required by the component) wired to services provided by other components; properties allowing for the configuration of a component implementation with externally set data values; and bindings that specify access mechanisms used by services and references according to some technology/protocol (e.g. WSDL binding to consume/expose web services, JMS binding to receive/send Java Message Service, etc.). Services and references are typed by interfaces. An interface describes a set of related oper- 53

64 Fig. 1. An SCA composite (adapted from the SCA Assembly Model V1.00 spec.) ations (or business functions) which as a whole make up the service offered or required by a component. The provider may respond to the requester client of an operation invocation with zero or more messages. These messages may be returned synchronously or asynchronously. Assemblies of components deployed together are called composite components and consist of: properties, services, services organized as sub-components, required services as references, and wires connecting sub-components. Abstract State Machines ASMs are an extension of Finite State Machines (FSMs) [8] where unstructured control states are replaced by states comprising arbitrary complex data. The states of an ASM are multi-sorted first-order structures, i.e. domains of objects with functions and predicates (boolean functions) defined on them. The transition relation is specified by rules describing how functions change from one state to the next. There is a limited but powerful set of ASM rule constructors, but the basic transition rule has the form of guarded update if Condition then Updates where Updates is a set of function updates of the form f(t 1,...,t n ):=t which are simultaneously executed 3 when Condition is true. Distributed computation can be modeled by means of multi-agent ASMs: multiple agents interact in parallel in a synchronous/asynchronous way. Each agent s behavior is specified by a basic ASM. Besides ASMs comes with a rigorous mathematical foundation [8], ASMs can be read as pseudocode on arbitrary data structures, and can be defined as the tuple (header, body, main rule, initialization): header contains the signature 4 (i.e. domain, function and predicate declarations); body consists of domain and function definitions, state invariants declarations, and transition rules; main rule represents the starting point of the machine program (i.e. it calls all the other ASM transition rules defined in the body); initialization defines initial values for domains and functions declared in the signature. 3 f is an arbitrary n-ary function and t 1,...,t n,t are first-order terms. To fire this rule to a state S i, i 0, evaluate all terms t 1,...,t n,tat S i and update the function f to t on parameters t 1,...,t n. This produces another state S i+1 which differs from S i only in the new interpretation of the function f. 4 Import and export clauses can be also specified for modularization. 54

65 Executing an ASM M means executing its main rule starting from a specified initial state. A computation M is a finite or infinite sequence S 0,S 1,...,S n,... of states of M, wheres 0 is an initial state and each S n+1 is obtained from S n by firing simultaneously all of the transition rules which are enabled in S n. A lightweight notion of module is also supported. An ASM module is an ASM (header, body) without a main rule, without a characterization of the set of initial states, and the body may have no rule declarations. An open framework, the ASMETA tool set [2], based on the Eclipse/EMF platform and developed around the ASM Metamodel, is also available for editing, exchanging, simulating, testing, and model checking models. AsmetaL is the textual notation to write ASM models within the ASMETA tool-set. The SCA-ASM modeling language By adopting a suitable subset of the SCA standard and exploiting the notion of distributed multi-agent ASMs, the SCA-ASM modeling language [21] complements the SCA assembly model with the ASM model of computation to provide ASM-based formal and executable description of the services internal behavior, services orchestration, interactions, and compensations. According to this implementation type, a service-oriented component is an ASM endowed with (at least) one agent (a business partner or role instance) able to interact with other agents by providing and requiring services to/from other service-oriented components agents. The service behaviors encapsulated in an SCA-ASM component are captured by ASM transition rules. Fig. 2. SCA-ASM component shape Fig. 2 shows the shape of an SCA-ASM component A using the graphical SCA notation, and the corresponding ASM modules for the provided interface 55

66 computation and coordination Skip rule skip do nothing Update rule f(t 1,...,t n):=t update the value of f at t 1,...,t n to t Call rule R[x 1,...,x n] call rule R with parameters x 1,...,x n Let rule let x = t in R assign the value of t to x and then execute R Cond rule it φ then R 1 else R 2 if φ is true, then execute R 1, otherwise R 2 Iterate rule while φ do R execute rule R until φ is true Seq rule seq R 1...R n endseq rules R 1...R n are executed in sequence without exposing intermediate updates Parallel rule par R 1...R n endpar rules R 1...R n are executed in parallel Forall rule forall x with φ do R(x) forall x satisfying φ execute R Choose rule choose x with φ do R(x) choose an x satisfying φ and then execute R Split rule forall n N do R(n) split N times the execution of R Spown rule spawn child with R create a child agent with program R communication Send rule wsend[lnk,r,snd] send data snd to lnk in reference to rule R (no blocking, no acknowledgment) Receive rule wreceive[lnk,r,rcv] receive data rcv from lnk in reference to rule R (blocks until data are received, no ack) SendReceive wsendreceive send data snd to lnk in reference to rule R rule [lnk,r,snd,rcv] waits for data rcv to be sent back (no ack) Reply rule wreplay[lnk,r,snd] returns data snd to lnk, as response of R request received from lnk (no ack) Table 1. SCA-ASM rule constructors for computation, coordination, communication AService (on the left) and the skeleton of the component itself (on the right) using the textual AsmetaL notation of the ASMETA toolset. Details on the meaning of these concepts can be found in [21]. The ASM rule constructors and predefined ASM rules (i.e. named ASM rules made available as model library) used as basic SCA-ASM behavioral primitives are recalled in Table 1. In particular, communication primitives provide both synchronous and asynchronous interaction styles (corresponding, respectively, to the request-response and one-way interaction patterns of the SCA standard). Communication relies on a dynamic domain Message that represents messages managed by an abstract message-passing mechanism: components communicate over wires according to the semantics of the communication primitives and a message encapsulates information about the partner link, the referenced service name, and data. We abstract, therefore, from the SCA notion of binding. Indeed, we adopt the default SCA binding (binding.sca) for message delivering, i.e. the SOAP/HTTP or the Java method invocations (via a Java proxy) depending if the invoked services are remote or local, respectively. 56

67 3 The SCA-ASM design framework The SCA-ASM framework 5 allows to design, assembly, and execute SCA-ASM models of components in an unique Eclipse-based environment. The framework consists of a graphical modeling front-end and of a run-time platform as back-end. The graphical front-end is the SCA Composite Designer that is an Eclipse-based graphical development environment for the construction of SCA composite assemblies. An SCA metamodel (based on the Eclipse Modeling Framework (EMF) [11] a platform for Model-driven Engineering) is at the core of such a graphical editor. We extended the SCA Composite Designer and the SCA metamodel to support ASM elements like component and interface implementation. Fig. 3 shows a screenshot of the tool. Appropriate ASM icons (see the right side of Fig. 3) may be used to specify ASM modules as (abstract) implementation of components and interfaces of the considered SCA assembly; alternatively, ASM modules files can be selected from the explorer view (on the left side of Fig. 3) and then dragged and dropped on the components and interfaces of the SCA assembly diagram. The back-end is the open Apache Tuscany SCA runtime [25] to run and test SCA assemblies of components developed with different implementation technologies and spread across a distributed environment (cloud and enterprise infrastructures) combined with the ASMETA toolset to support various forms of high-level functional analysis via ASMs. In particular, we extended (as better described in the next Section) the Tuscany runtime platform to allow the execution of ASM models of SCA components through the simulator ASMETA/AsmetaS (as shown by the console output in Fig. 3) within Tuscany. SCA-ASM makes it possible to specify abstract components, to compose them, and to simulate them and check various functional properties with the help of the ASMETA analysis toolset and of the Tuscany platform. Basically, the following two functional analysis scenarios are supported. Offline analysis: First, designers are able to exploit the ASMETA analysis toolset (also based on the Eclipse environment) to validate and verify SCA-ASM models of components in an off line manner, i.e. ASM models of such abstract (or mock) components may be analyzed in isolation. As analysis techniques, the ASMETA toolset includes simulation, scenario-based simulation, model-based testing and model checking. In-place simulation: Then, an in-place simulation scenario may be also carried out to execute early the behavior of the overall composite application. In this case, the AsmetaS simulator is directly invoked within the SCA runtime platform to execute the ASM specifications (intended as abstract implementations) of mock components together with the other real and heterogeneous (non ASMimplemented) components according to the chosen SCA assembly. Several case studies of varying sizes and covering different uses of the SCA- ASM constructs have been developed. These include application examples taken from the SCA Tuscany distribution, a Robotics task coordination case study [15] of the EU project BRICS [10], and a scenario of the Finance case study of the

68 EU project SENSORIA [23] related to a credit (web) portal application of a credit institute that allows customer companies to ask for a loan to a bank. Fig. 3 shows the SCA assembly of this last finance application. More details and functional requirements on this scenario can be found in [4]. Fig. 3. SCA-ASM tool screenshot 3.1 Framework implementation This subsection provides some details on how we extended the Eclipse-based SCA composite designer (the frontend) and the SCA Tuscany runtime (the backend) to support the SCA-ASM component implementation type. Extending the Eclipse-based SCA composite designer First, we extended the SCA metamodel [22], an extensible EMF Ecore-compliant metamodel that represents concepts of the Open SOA SCA specifications 1.0 [18] plus different extending concepts to support open SCA runtimes (Apache Tuscany and Frascati). Extending the SCA metamodel to add new concepts to SCA and extend the tools to include them is straightforward. Fig. 4 shows the two basic concepts, implementation and interface, that we added to the SCA metamodel to support the editing of SCA-ASM components within standard SCA assembly files. Then, we extended the SCA Composite Designer (see Figure 3), a graphical (GMF) development environment for the construction of SCA composite applications. This required us to develop Eclipse plug-ins to allow the use of the ASMInterface and the ASMImplementation creation tools from the palette or the contextual menu, to allow the setting of properties values in the Properties view for each created element, etc.. Extending the Tuscany SCA runtime SCA-ASM components use annotations to denote services, references, properties, etc. With this information, as 58

69 Fig. 4. A fragment of the SCA metamodel extension to support SCA-ASM better described below, an SCA runtime platform (Tuscany in our case) can create a composition (an application) by tracking service references (i.e. required services) at runtime and injecting required services into the component when they become available. Creating a new extension in Tuscany required to us two distinct steps. First, we developed the extension code (using the Java programming language) to handle the new technology implementation.asm. The UML package diagram in Fig. 5 shows the high-level structure and classes of this extension code. In the second step, the Tuscany runtime was configured to load, invoke, and manage the new extension through the Tuscany extension point mechanism. An extension point is the place where the Tuscany runtime collects the information required for handling an extension. Specifically, we had to do the following: (i) define how the extension can be used and configured in an SCA composite (assembly) file, by defining an XML schema implementation-asm.xsd that defines the XML syntax for the extension implementation.asm of the SCA implementation type 6 XML schema validation extension point; (ii) define how to create an Java model that represents the in-memory version of the configured ASM extension by providing the code for a processor (the Java class ASMImplementationProcessor in Fig. 5) that knows how to transform the XML representation in the composite file into an in-memory Java model and vice versa XML processor extension point; (iii) enable the Tuscany runtime to invoke and manage the ASM extension by adding the code, the ASM extension provider 7, that the Tuscany runtime will use to locate, invoke, and manage the extension at runtime Provider factory extension point. The ASM extension provider delegates the handling of the ASM component implementation to AsmetaS. To this purpose, the Tuscany runtime calls the ASMImplementationProviderFactory (see Fig. 5) to create an instance of the ASMImplementationProvider for each component implementation in- 6 For example, implementation.asm adds the location attribute for the pathname of the ASM file (an AsmetaL file) that implements the underlying component. 7 The Tuscany core delegates the start/stop of component implementation instances and related resources, and the service/reference invocations, to specific implementation providers that typically respond to these life-cycle events. 59

70 stance. The ASMImplementationProvider s start() method is invoked to set up the implementation instance when the component is started. Tuscany also calls the ASMImplementationProvider s createinvoker() method to create an ASMInvoker for each service operation and add it to the incoming invocation chain. When the request comes in, the ASMImplementationInvoker will be called to dispatch the request to the ASM instance and get the response back to the caller. When the component is stopped, the ASMImplementationProvider s stop() method is triggered to clean up the resources associated with the implementation instance. An SCA service can offer multiple operations. Below, we describe the mechanism (technology dependent) adopted by the invoker specific to ASM (the ASMInvoker) for dispatching (through the invoke method) requests to the appropriate operation. Fig. 5. The classes that define the implementation.asm extension In-place ASM execution mechanism. Fig. 6 illustrates how the ASM implementation provider sets up the environment (the ASM container) within Tuscany for instantiating and handle incoming/outgoing service requests to/from an ASM component implementation instance (like component A in the figure) by instrumenting the ASM simulator AsmetaS. Currently, the implementation scope of an SCA-ASM component is composite, i.e. a single component instance a single main ASM instance (see the main ASM for component A in Fig. 6) is created within AsmetaS for all service calls of the component. This main ASM is automatically created during the setting up of the connections and it is responsible for instantiating the component agent and related resources, and for listening for service requests incoming from the protocol layer and forward them to the component agent instance (see component A in Fig. 6). Executing an ASM component implementation means executing its main ASM. 60

71 Fig. 6. Instantiating and invoking ASM implementation instances within Tuscany For each reference, another entity (i.e. another ASM module) is automatically created (and instantiated as ASM agent within the main ASM of the component) as proxy for a remote component (see the ASM proxy for component B in Fig. 6) for making an outbound service call from the component. Using a terminology adopted in the Java Remote Method Invocation (RMI) API, this proxy ASM plays the role of stub to forward a service invocation (and their associated arguments) to an external component s agent, and to send back (through the ASM rule r replay) the result (if any) to the invoker component agent (the agent of the component A in Fig. 6). The main ASM, instead, plays the role of skeleton, i.e. a proxy for a remote entity that runs on the provider and forward (through the ASM rule r sendreceive) client s remote service requests (and their associated arguments) to the appropriate component s agent (usually the main agent of the component), and then the result (if any) of the invoked service is returned to the client component agent (via stubs). When an ASM implementation component is instantiated, the Tuscany runtime also creates a value for each (if any) externally settable property (i.e. ASM monitored functions, or shared functions when promoted as a composite property, annotated Such values or proxies are then injected into the component implementation instance. A data binding mechanism also guarantees a matching between ASM data types and Java data types, including structured data, since we assume the Java interface as IDL for SCA interfaces. 4 Related work Some visual notations for service modeling exist, such as the OMG SoaML UML profile [17] and the UML4SOA [20] defined within the EU project SENSORIA [23]. SoaML, like SCA, is focused on architectural aspects of services. UML4SOA is more focused on modeling service orchestrations as an extension of UML2 activity diagrams. In order to make UML4SOA models executable, code generators towards low-level orchestration languages (such as BPEL/WSDL, Jolie, and Java) were developed [19]; however these target languages do not provide the same preciseness of a formal method necessary for early design and analysis. 61

72 Some works devoted to provide software developers with formal methods and techniques tailored to the service domain also exist for the service composition problem), mostly developed within the EU projects SENSORIA [23] and S-Cube [16]. Several process calculi for the specification of SOA systems have been designed (see, e.g., [12, 13]). They provide linguistic primitives supported by mathematical semantics, and verification techniques for qualitative and quantitative properties [23]. Still within the SENSORIA project, a declarative modeling language for service-oriented systems, named SRML [24], has been developed. Compared to the formal notations mentioned above, the ASM method has the advantage to be executable. In [14], the analysis tool Wombat for SCA is presented; the tool is used for simulation and verification tasks by transforming SCA modules into composed Petri nets. There is not proven evidence, however, that this methodology scales effectively to large systems. An abstract service-oriented component model, named Kmelia, is formally defined in [1, 3] and is supported by a prototype tool (COSTO). Our proposal is similar to the Kmelia approach; however, we have the advantage of having integrated our SCA-ASM component model and the ASM-related tools with an SCA runtime platform for a practical use and an easy adoption by developers. Within the ASM community, the ASMs have been used for the purpose of formalizing business process notations and middleware technologies related to web services, such as [9, 6] to name a few. Some of these previous formalization efforts, as explained in [21], are at the basis of our work. 5 Conclusion and future directions We presented a framework for service design and prototyping that combines the SCA open standard model for service assembly and the ASM formal support to assemble service-oriented components as well as intra- and inter- service behavior. The framework is supported by a tool that exploits the SCA runtime Tuscany and the toolset ASMETA for model execution and functional analysis. We plan to support more useful SCA concepts, such as the SCA callback interface for bidirectional services. We want also to enrich the SCA-ASM notation with interaction and workflow patterns based on the BPMN specification and with specific actions to support an event-based style of interaction. We also plan to extend the language with pre/post-conditions defined on services (transition rules) for contract correctness checking in component assemblies. References 1. P. André, G. Ardourel, and C. Attiogbé. Composing components with shared services in the kmelia model. In C. Pautasso and É. Tanter, editors, Software Composition, volume4954oflncs, pages Springer, The ASMETA toolset website C. Attiogbé, P. André, and G. Ardourel. Checking component composability. In W. Löwe and M. Südholt, editors, Software Composition, volume4089oflecture Notes in Computer Science, pages Springer,

73 4. F. Banti, A. Lapadula, R. Pugliese, and F. Tiezzi. Specification and Analysis of SOC Systems Using COWS: A Finance Case Study. Electr. Notes Theor. Comput. Sci., 235:71 105, A. P. Barros and E. Börger. A compositional framework for service interaction patterns and interaction flows. In K.-K. Lau and R. Banach, editors, ICFEM, volume 3785 of LNCS, pages Springer, E. Börger. Modeling Workflow Patterns from First Principles. In Proc. of the 26th Int. Conf. on Conceptual Modeling - ER 2007, pages1 20, E. Börger, O. Sörensen, and B. Thalheim. On defining the behavior of or-joins in business process models. J. UCS, 15(1):3 32, E. Börger and R. Stärk. Abstract State Machines: A Method for High-Level System Design and Analysis. Springer Verlag, E. Brger, O. Srensen, and B. Thalheim. On defining the behavior of or-joins in business process models. Journal of Universal Computer Science, 15(1):3 32, EU project BRICS (Best Practice in Robotics), Eclipse Modeling Framework C. Guidi, R. Lucchi, R. Gorrieri, N. Busi, and G. Zavattaro. : A calculus for service oriented computing. In A. Dan and W. Lamersdorf, editors, ICSOC, volume4294 of LNCS, pages Springer, I. Lanese, F. Martins, V. T. Vasconcelos, and A. Ravara. Disciplining orchestration and conversation in service-oriented computing. In SEFM 07, pages IEEE, A. Martens and S. Moser. Diagnosing SCA Components Using Wombat. In Business Process Management, 4th International Conference, BPM 2006, Vienna, Austria, September 5-7, 2006, Proc., pages , EU project BRICS, Tech. Rep. A Coordination Use Case. March 24, www. best-of-robotics.org/wiki/images/e/e0/coordinationusecaseubergamo.pdf. 16. EU project S-Cube OMG. Service oriented architecture Modeling Language (SoaML), ptc/ , april Service Component Architecture (SCA) P. Mayer, A. Schroeder, and N. Koch. A model-driven approach to service orchestration. In IEEE SCC (2), pages IEEE, P. Mayer, A. Schroeder, N. Koch, and A. Knapp. The UML4SOA Profile. In Technical Report, LMU Muenchen, E. Riccobene and P. Scandurra. A modeling and executable language for designing and prototyping service-oriented applications. In EUROMICRO Conf. on Software Engineering and Advanced Applications (SEAA 2011). 22. SCA Tools EU project SENSORIA, SRML: A Service Modeling Language Apache Tuscany. 63

74 An Eclipse Plug-in for Engineering Service Interchangeability Giovanni Denaro and Davide Tosi Universitá degli Studi di Milano Bicocca, I-20126, Milano - Italy, [denaro tosi]@disco.unimib.it Abstract. Service-oriented applications often experience runtime failures when they attempt to interchangeably use different services that implement the same service API. In previous work, we have introduced a technique that combines test suites and adaptors into self-managed adaptation strategies, to automatically solve interchangeability failures at runtime without stopping the applications. This paper properly extends our previous work by presenting an Eclipse plug-in that facilitates and partially automates the tasks associated with the development and the deployment of the related adaptation strategies. 1 Introduction Several developer communities regard the spreading of web services and the service-oriented paradigm with extreme interest. On one hand, web services allow enterprises to export functionality outside their bounds, thus enabling stakeholders of different domains to seamlessly integrate third-party expertise into their applications. On the other hand, the service oriented paradigm favors both the reuse of services among applications and the development of interchangeable services, that is, services that implement the same (possibly standard) API and can mutually and seamlessly replace each other in the scope of the applications that use that API. Despite the increasing momentum, service-oriented applications do not experience the benefits of interchangeable services to full extent yet. As a matter of facts, applications often fail to interchangeably use all the services that (inconsistently) implement a service API. In principle, services that comply with the same contract should be equivalent, but in practice API contracts specify little more than the service syntax and parameters, leaving many semantic details unspecified and implementation-dependent. Thus, compliance to the same APIs supports the integrability between applications and services syntactically, but does not always guarantee full semantic interoperability between applications and interchangeable services. For instance, we have been using web services for obtaining the weather temperatures on the basis of a contract that specified the temperature to be returned as a floating point value, without indicating the measurement unit. This contract matched services that returned temperatures expressed in different 64

75 measurement units, e.g., Fahrenheit and Celsius. It can be easily spotted that using these services interchangeably likely leads to client-side failures. Common experience and previous research indicate that: 1) Many inconsistent behaviors of the services that comply to an API can be revealed by test suites that sample the service functions and compare them against a reference behavior defined for the API [e.g., see the forum at wiki.opensocial.org]; 2) once revealed, most inconsistencies can be fixed by means of adaptors that suitably fix the interactions between the services and the applications at runtime [15, 6, 13, 14, 10, 2, 12, 1, 3, 5, 4]. In previous work, we have proposed a technique that combines test suites and adaptors into self-managed adaptation strategies (that we refer to as testand-adapt plans), to automatically solve incompatibilities at runtime without stopping the applications [7, 8]. We showed that the test-and-adapt plans for the applications of a domain can be generalized into domain specific catalogs of adaptation strategies, meant to support developers to produce test-and-adapt plans for new applications. In this paper, we move our approach a step forward by introducing an Eclipse plug-in, called SHIWS, that supports and partially automates the tasks associated with the development and the deployment of the test-and-adapt plans. To sketch our approach, let us consider a system integrator that is engineering an application to achieve service interchangeability for a given API. The system integrator will first identify mismatches that may derive from different services that implement the API; they can use domain-specific catalogs, such as the ones from [8], to support this task. Then the integrator will set to using Eclipse, augmented with the SHIWS plug-in, to define a set of test-and-adapt plans able to avoid/overcome the identified mismatch. By means of SHIWS the integrator develops the test-and-adapt plans as independent modules, separated from the application code. Upon deployment, SHIWS weaves the test-and-adapt modules into the application code. At run time, the generated code automatically runs the test-and-adapt plans against the services connected by the application: It executes the test suites to identify the occurrence of the service mismatches, and suitably uses the adaptors to avoid the mismatches. The paper is organized as follows. Section 2 recaps the main concepts of the test-and-adapt approach. Section 3 presents the architecture and the functionality of SHIWS. Section 4 illustrates the use of SHIWS through a case study of implementing a service-oriented applications that works with interchangeable services. Section 5 summarizes the paper with final remarks. 2 The Test-and-Adapt Approach Interoperability problems due to dynamically bound implementations of standard APIs affect service-oriented applications that integrate competing implementations of standard service APIs. In [8] we tested a set of open-source applications based on two standard service APIs, del.icio.us and OpenSocial, 65

76 RECONFIGURABLE PROXY 4. invoke(op) adaptors chain A x A y dispatch to target service(op) APP TO WS CALLS 1. New WS? [if no goto 4] TEST-AND-ADAPT CONTROLLER test cases Test1: Test2: Test3: deploy(adaptors) 2. run(test cases) adaptors A 1 A 2 A 3... Service API implement WS1 WS2... APP call flow test-and-adapt flow test-and-adapt plan Fig. 1. Test-and-adapt: runtime aspects integrated with different third-party services that implement the APIs. Out of the combinations of 12 applications and 9 services, our tests exposed 59 failures. Further inspection of these failures revealed that all services, albeit inconsistently implemented, preserve the main functionality of the APIs. Indeed, these services could be used interchangeably, provided that developers slightly patch the code of the applications upon switching from one service (that implements an API) to another (that implements the same API). The baseline is that most interchangeability problems derive from inconsistent implementations of standard APIs; they do not preclude the interoperability of the applications with different service implementations of the same API, but require manual interventions of the developers whenever a new implementation is to be integrated. Our work is grounded on the observation that many inconsistencies can be predicted by analyzing the standard APIs on the basis of domain expertise and previous experience, identified by executing few simple test cases on the target implementations, and solved by means of simple adaptors. Following this observation, we have developed an approach called test-and-adapt that consists of a mechanism to augment applications with test cases and adaptors that can be executed at runtime to solve interoperability problems across inconsistent implementations of standard APIs. The test-and-adapt mechanism comprises design and runtime aspects. At design time, the mechanism is enabled by developers, which must engineer the applications with test-and-adapt plans. We define a test-and-adapt plan as a 66

77 relation between test cases that check for inconsistency, and adaptors that fix the inconsistency at runtime. Each test case is paired with an adaptor that is activated depending on the test outcome. At runtime, the mechanism is triggered by the applications whenever connecting to new services. The mechanism dynamically executes the test cases to verify the consistency of the current implementation with the reference API, triggers suitable adaptors if needed, and deploys the selected adaptors to mediate the next interactions through the API. Figure 1 illustrates the runtime mechanism for the case of standard API web services. The mechanism includes a Reconfigurable proxy that dynamically binds adaptors to service invocations, and a Test-and-adapt controller that manages test-and-adapt plans. The figure illustrates the two invocation flows for the cases of a newly-bound and in-use service implementation, respectively. If the runtime mechanism identifies that a new implementation has been bound to the service API (for instance, because of a new provider or because of the notification of a service update), it first activates the Test-and-adapt controller that executes the test cases associated with the API at design time, and then deploys suitable adaptors according to the test results (steps 1, 2, and 3 in Figure 1). When a service implementation is in-use, the application invokes the service through the Reconfigurable proxy that is responsible for executing the adaptors that may have been formerly selected for the current implementation (steps 1, 4 and 5 in Figure 1). Devising test-and-adapt plans is the design-time core of the approach. As when designing modern software systems, engineers shall identify unexpected executions and design exceptions handlers, when dealing with dynamically bound implementations of standard APIs, software engineers shall identify potential inconsistencies that may arise from different implementations of the same API, produce test cases to reveal inconsistent implementations, and design corresponding adaptors. Pairing adaptors with test cases makes the approach suitable to cope with incompatibilities that may arise when referring to implementations not known at design time. Engineers can identify potential inconsistencies either from their previous experience or through inconsistency catalogs that capture experience of software designers and domain experts (for further details, see the catalog in [8]). The inconsistency catalogs can be specialized on the application domains and the execution environments, and may evolve over time to optimize the process. 3 The SHIWS Plug-in SHIWS 1 is a plug-in of the Eclipse open platform [9] that supports the development of test-and-adapt plans for an API, and facilitates the deployment of these plans into the applications. Then, when the applications are deployed, SHIWS generates the runtime infrastructure that links the application to the services along the lines of Figure 1, by dynamically revealing the occurring inconsis- 1 The acronym stands for Self-Healing Integrator of Web Services. 67

78 (a) (a) web service interface (c) adaptation.config (b) (b) test_case.config Fig. 2. The test-and-adapt perspective of SHIWS tencies, and selecting and enacting the different adaptors. Currently, SHIWS is implemented for web applications written in Java. SHIWS augments Eclipse with two new commands and a new development perspective. Command Add new test-and-adapt web service initiates the integration of a new web service to be controlled according to the test-and-adapt mechanism: SHIWS retrieves the WSDL description, which describes the characteristics of the target web service, and parses it to identify the API (operations and parameters) of the web service. It then initializes an instance of the testand-adapt runtime infrastructure for web service API that is being integrated. The set of test-and-adapt plans is initially empty. The test-and-adapt plans can be browsed and edited within the test-andadapt perspective. Figure 2 shows a screenshot of this perspective. The web service interface pane (Figure 2-a) recalls the API of the web service, as parsed by SHIWS. The test case config pane (Figure 2-b) can be edited by the integrator to implement the test cases (specified as Java methods with test oracles after the JUnit assertion library), aimed to reveal the occurrence of potential mismatches in the web service. The adaptation config pane (Figure 2-c) contains the adaptor modules, eaimed to adapt mismatching implementations of the web service. Figure 3 shows a sample test-and-adapt test case for a web service that operates an online shopping cart. The test case populates and retrieves a shopping cart across two user sessions, to check whether the service implementation provides persistency of the cart items across user sessions. In SHIWS, the signature of test methods contains two new keywords, onsuccessselects and onfailureselects (lines 8 and 9 in the figure), that allow developers to specify the test-and-adapt relation, i.e., which adaptor modules have to be triggered when the test case either succeeds or fails. In the example, the success of the test case indicates a persistent shopping cart and triggers the PersistentCartDecorator 68

79 1 public class TestCartWS 2 extends junit.framework.testcase { 3 ShoppingCartWebService cart =...; 4 //automatically initialized as a 5 //reference to the actual web service 6 7 public void testcartpersistency() 8 onsuccessselects PersistentCartDecorator 9 onfailureselects NonPersistentCartDecorator { 10 cart.login("mylogin","mypassword"); 11 int cartid=cart.cartcreate(); 12 cart.cartadd(cartid, "CD2 Platinum Collection"); 13 cart.logout(); 14 cart.login("mylogin","mypassword"); 15 try{ 16 String[] cartitems = cart.cartget(cartid); 17 assertfalse(cartitems.length == 0); 18 } catch(cartnotpersistentexception e){ 19 fail(); 20 } 21 } 22 } Fig. 3. A sample test case to check whether or not the shopping cart web service provides persistent carts adaptor, while a failure indicates a non-persistent shopping cart and triggers the NonPersistentCartDecorator adaptor. The latter adaptor provides local storage of the cart items while the service is being used. The implementation of the adaptors, from the adaptation config pane, is straightforward and is not shown due to space reasons. When the implementations of the test-and-adapt plans is complete, command Generate test-and-adapt instantiates the runtime infrastructure with the test cases and the corresponding adaptors. The runtime infrastructure consists of a set of automatically generated Java classes that are compiled with the application to add self-managed behavior of the test-and-adapt mechanism. Figure 4 illustrates the architecture of the typical runtime infrastructure generated by SHIWS. The Wrapper mediates the interactions between the application and the web service, and dynamically monitors the current service, to check if the connection to a new implementation of the service occurs. This component is built automatically starting from the WSDL description of the target web service. The Wrapper detects the connection to a new service by comparing the provider details between subsequent invocations of the service, and in 69

80 WEB SERVICE DOMAIN WS_1 WS_n CONTROL LOOP CUSTOMIZATION DOMAIN APPLICATION DOMAIN AdaptationModule_1 WSInvocation AdaptationInterface AdaptationModule_n AdaptationInterface The actual adaptation module can be dinamically selected. TestDriver selects the proper adaptation module according to the result of the test. TestSuite executes WSInterface Wrapper notifies of service implementation changes TestDriver -<from junit.framework> INFRASTRUCTURE Fig. 4. The runtime infrastructure built by SHIWS the implementation of the services offered by the same provider by checking the version tags exported by the service 2. If the Wrapper detects the connection to a new service implementation, it notifies the (automatically generated) TestDriver and embeds the test suite designed as we described above. The TestDriver runs the test cases and uses the embedded onfailureselects and onsuccessselects logic to select the adaptor modules that best fit the characteristics of the current web service. Then, it reconfigures the infrastructure to include the selected adaptation modules, and returns control to the Wrapper that is responsible to execute the (possibly reconfigured) adaptation strategy. It is possible that, depending on the failure or success of different test cases, the TestDriver selects a set of adaptation modules rather than a single one. In this case, the runtime infrastructure composes all selected adaptation modules in a chain. 4 Implementing Applications with SHIWS This section illustrates our experience of using the test-and-adapt approach and the SHIWS plugin while implementing a service-oriented application, namely, the personal mobility manager (PMM). The PMM is an application to support 2 Current web services do not always provide version information, but it is reasonable to expect that the increasing use of web services will foster such a good practice. 70

81 Fig. 5. PMM in use people mobility. It works by dynamically integrating and composing a set of third-party web services for mobility. The motivation for test-and-adapt arises because these services can be available at runtime in different versions despite stable WSDL interfaces [11]. We used SHIWS to engineer the PMM with testand-adapt mechanisms. The sequel of this section provides a brief overview of the PMM, discusses some failures that may occur due to integration mismatches with different versions of web services, reports on developing the test-and-adapt support for one of the target web services, and describes the resulting PMM woven with the test-ad-adapt plans. 4.1 The Personal Mobility Manager PMM is an advanced navigation system that installs on mobile devices, such as smart phones, and allows users to search for optimal combinations of transportation means while taking into account emergent constraints, such as, traffic conditions, weather conditions, opening hours, etc. Figure 5) shows the simulation of a simple scenario in which PMM is used to plan the journey between two locations by relying on a set of web services to provide this functionality. PMM can fail due to new versions of web services that may come dynamically into play. For example, PMM can fail when updating the map web service currently integrated in PMM with a new version that delivers maps with a different encoding through the same WSDL interface specification (see screenshot in Figure 6). The exception is raised as a consequence of a mismatch with the image encoding supported by a new version of the MapProvider web service: PMM expects a JPG map, but the new service returns a different map encoding. 71

82 PMM Exception! The Map Provider web service does not responde properly. Please, try again later. Fig. 6. PMM failure example 4.2 Designing test-and-adapt plans We use SHIWS to develop an test-and-adapt plan for the map web service. The entrypoint for SHIWS is the command add new test-and-adapt web service that is invoked from the Eclipse menu, to integrate the map web service into a project. This command executes a widget where the user specifies the URL to the WSDL description of the service. Figure 7 shows an excerpt of the WSDL that describes the API of the service MapProvider: the API IMapImage (line 1) exposes the operation getmaps (line 2), whose input parameter has a field of type ArrayOfMapImageOptions (line 11), which in turn has a subfield mapimageformat of type string (line 18). The value of mapimageformat must be set to specify the desired map encoding format (e.g., JPG, GIF and so forth), but the supported encodings are not specified in the API. As an effect of the execution of command add new test-and-adapt web service, Eclipse switches to the test-and-adapt perspective of SHIWS, showed in Figure 8 for the case of PMM and the service MapProvider. The perspective shows the parsed API in Java-like format, and contains initially empty test cases and adaptors. For detecting and adapting the encoding format mismatch of the service MapProvider, we designed the test suite shown in Figure 9 and the adaptors shown in Figure 10. The test suite detects the supported encodings by sampling the web service for all possible encodings. If an encoding format is detected as either supported or non-supported a decorator component is selected correspondingly. Keywords onsuccessselects and onfailureselects set the association between the results of a test suite and the corresponding adaptors. For example, the success of test testgifsupported (Figure 9, lines 11-16) selects the adaptor 72

83 1 <wsdl:porttype name="imapimage"> 2 <wsdl:operation name="getmaps"> 3 <wsdl:input name="getmaps0in" message="getmapsrequest" /> <wsdl:message name="getmapsrequest"> 7 <xsd:complextype> 8 <xsd:sequence> 9 <xsd:element name="mapareas" type="n4:arrayofmaparea" /> 10 <xsd:element name="token" type="xsd:string" /> 11 <xsd:element name="mapimageoptions" type="n4:arrayofmapimageoptions" /> 12 </xsd:sequence> 13 </xsd:complextype> 14 </wsdl:message> <xsd:complextype name="mapimageoptions"> 17 <xsd:sequence> 18 <xsd:element name="mapimageformat" nillable="true" type="xsd:string" /> </xsd:sequence> 21 </xsd:complextype> Fig. 7. Excerpt of the WSDL description for the service MapProvider Fig. 8. The SHIWS test-and-adapt perspective generated for the PMM and the service MapProvider. GIFSupportedDecorator (line 12). All selected adaptors can be composed with the target web service. In the adaptation suite all adaptors share a common set of fields (Figure 10, lines 4-6) that indicate whether or not a given encoding is supported. The selected adaptors initialize these common fields. For example, the adap- 73

84 1 public class MapImageWS extends junit.framework.testcase { 2 MapImageWS mapimage =... ; 3 4 public void testjpgsupported() 5 onsuccessselects JPGSupportedDecorator 6 onfailureselects JPGNonSupportedDecorator { 7 try { mapimage.getmaps(..., "JPG",...);} 8 catch(jpgnonsupportedexception e) {fail();} 9 } public void testgifsupported() 12 onsuccessselects GIFSupportedDecorator 13 onfailureselects GIFNonSupportedDecorator { 14 try { mapimage.getmaps(..., "GIF",...);} 15 catch(gifnonsupportedexception e) {fail();} 16 } //add a test case for each possible encoding Fig. 9. Test suite for detecting encoding format mismatch of the service MapProvider 1 // Abstract decorator class 2 abstract class GetMapDecorator implements GetMapWS { 3 protected GetMapWS decoratedws; 4 static boolean JPGSupported=false; 5 static boolean GIFSupported=false; public GetMapsResponse getmaps() { 9 if (JPGSupported){ 10 return decoratedws.getmaps(..., "JPG",...); 11 } else if (GIFSupported) { 12 GetMapsResponse map = decoratedws.getmaps(..., "GIF",...); 13 return ConversionLibrary.GIFtoJPG(map); 14 } else if { 15...//Handle another possible encodings 16 } else {throw new Exception();} 17 } 18 } // A concrete decorator 21 class JPGSupportedDecorator extends GetMapDecorator { 22 public JPGSupportedDecorator(GetMapWS decoratedws) { 23 this.decoratedws = decoratedws; 24 JPGSupported=true; 25 } 26 } //add concrete decorators for all possible encodings Fig. 10. Adaptors for the encoding format mismatch of the service MapProvider tor named JPGSupportedDecorator (Figure 10, lines 20-26) initializes the field JPGSupported to true. When the adaptation logic is instantiated, calls to the target web service are filtered by the method getmaps (lines 8-18) which calls the web service selecting among supported encodings, and performing encoding conversions as needed. 74

85 As seen, the test-and-adapt strategies are developed almost independently of the business logic of the application, resulting in reusable adaptation modules and high separation of concerns. 4.3 Deploying test-and-adapt By command generate test-and-adapt, SHIWS deploys the designed test-andadapt mechanisms into the application. This automatically generates the testand-adapt runtime infrastructure as a set of Java files (see Screenshot in Figure 11) to be compiled with the application. The resulting PMM does not experience the interoperability problem discussed in the beginning of this section. Fig. 11. The Test-and-adapt generate command generates the classes of the runtime infrastructure that controls the dynamic adaptation. 5 Conclusions This paper has presented SHIWS, an Eclipse plug-in to design applications augmented with support for service interchangeability, after the test-and-adapt approach that we introduced in previous work. SHIWS successfully supports the key tasks of the test-and-adapt approach, that is, defining test cases and adaptors to detect and solve, respectively, interchangeability problems due to services that inconsistently implement the same API. We reported on a case study 75

86 where we successfully used SHIWS to engineer test-and-adapt mechanisms into a service-oriented application. Our experience with SHIWS pinpoints the following key remarks: Separation of concerns: SHIWS supports the design of the adaptation logic in separate modules, designed and developed independently of both the web services and the applications. We found it extremely beneficial to be able to deal with the application functionality and adaptation concerns of different web services as separate problems. Automatically generated infrastructure: most of the infrastructure for managing the test-and-adapt mechanisms is automatically generated by SHIWS. This eliminates many technical difficulties in the integration efforts, such as, handling the communication via SOAP primitives, checking changes of the service provider or implementation, executing test cases, and activating adaptation modules as needed. Reusable adaptation modules: the loose dependency between adaptation modules and client applications indicates that the same adaptation modules can be partially reused across applications that integrate similar web services. This suggests the possibility of designing libraries of standard adaptation modules. References 1. Brambilla, M., Ceri, S., Facca, F.M., Celino, I., Cerizza, D., Della Valle, E.: Modeldriven design and development of semantic web service applications. ACM Transactions on Internet Technology 8 (November 2007) 2. Brogi, A., Popescu, R.: Automated generation of bpel adapters. In: Proceedings of the 4th International Conference on Service Oriented Computing (ICSOC). pp LNCS 4294 (2006) 3. Brogi, A., Corfini, S., Popescu, R.: Semantics-based composition-oriented discovery of web services. ACM Transactions on Internet Technology 8, 19:1 19:39 (October 2008) 4. Brogi, A., Popescu, R., Tanca, M.: Design and implementation of sator: A web service aggregator. ACM Transactions on Software Engineering and Methodology 19, 10:1 10:21 (February 2010) 5. Camara, J., Martin, J.A., Salaun, G., Cubo, J., Ouederni, M., Canal, C., Pimentel, E.: Itaca: An integrated toolbox for the automatic composition and adaptation of web services. In: Proceedings of the 31st International Conference on Software Engineering. pp (may 2009) 6. Chen, P., Critchlow, M., Garg, A., Van der Westhuizen, C., van der Hoek, A.: Differencing and merging within an evolving product line architecture. In: Lecture Notes in Computer Science. vol. 3014, pp Springer Verlag (2004) 7. Denaro, G., Pezzè, M., Tosi, D.: Adaptive integration of third-party web services. In: In Proceedings of the 2005 Workshop on Design and Evolution of Autonomic Application Software (DEAS 05) (2005) 8. Denaro, G., Pezzè, M., Tosi, D.: Ensuring interoperable service-oriented systems through engineered self-healing. In: Proceedings of the the 7th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering (ESEC/FSE 09). pp ACM, New York, NY, USA (2009) 76

87 9. The eclipse open source project Haller, A., Cimpian, E., Mocan, A., Oren, E., Bussler, C.: WSMX - a semantic service-oriented architecture. In: Proceedings of the International Conference on Web Services (ICWS). pp (2005) 11. Lorenzoli, D., Mussino, S., Pezzè, M., Schilling, D., Sichel, A., Tosi, D.: A soabased self-adaptive personal mobility manager. In: In Proceedings of the IEEE Conference on Service Computing (SCC Contest). Chicago, Illinois, September 2006 (2006) 12. Motahari Nezhad, H.R., Benatallah, B., Martens, A., Curbera, F., Casati, F.: Semiautomated adaptation of service interactions. In: Proceedings of the International Conference on World Wide Web (WWW). pp (2007) 13. Ponnekanti, S., Fox, A.: Interoperability among independently evolving web services. In: Proceedings of the International Middleware Conference. pp (2004) 14. Roman, D., Keller, U., Lausen, H., de Bruijn, J., Lara, R., Stollberg, M., A.Polleres, Feier, C., Bussler, C., Fensel, D.: Web service modeling ontology. Applied Ontologies 1(1), (2005) 15. Zaremski, A.M., Wing, J.M.: Specification matching of software components. ACM Transactions on Software Engineering and Methodology 6(4), (1997) 77

88 The AutoBlackTest Tool: Automating System Testing of GUI-based Applications Leonardo Mariani, Oliviero Riganelli and Mauro Santoro Department of Informatics, Systems and Communications University of Milano Bicocca Milano, Italy Abstract. Automatic test case generation is a key ingredient of efficient and cost-effective software verification processes. The problem is attracting a lot of attention, and the research in the field has produced many interesting results opening new research directions. In this paper we present AutoBlackTest, a technique to automatically generate system test cases for GUI-based interactive applications. AutoBlackTest explores the behaviors of the application under test using reinforcement learning to learn how to interact with the application under test and stimulate its functionalities. The interaction with the elements that compose the GUI of the application under test is implemented as an extension of the Eclipse IDE, in particular of the IBM Rational Functional Tester tool. Early empirical results show that the tool has the potential of automatically discovering bugs and generating useful system and regression test suites. Keywords: System Testing, Test Automation, Reinforcement Learning, Rational Functional Tester 1 Introduction System testing is an important activity in software development as it validates the software system as a whole to ensure that the actual behaviour of the Application Under Test (AUT) is consistent with the requirements [10]. Despite this fact, most research and development effort have focused on automating unit and integration testing, leaving system testing fairly ad hoc and largely manual. This situation can be attributed to the fact that the exploration of the underlying code has to be performed from a user perspective. In the case of GUI-based interactive applications, the execution of system test cases requires the interaction with applications through their Graphical User Interface (GUI). Since the number of events that a user may perform on a GUI is extremely large, system test designers have to face the issue of testing an application according to the many ways it can be used in a small amount of time. For this reason, test cases executed by test designers usually explore a very limited portion of the execution space. 78

89 In this paper we present AutoBlackTest, a tool for the automatic generation of system test cases for GUI-based interactive applications. We use the term GUI-based interactive applications to refer to applications with GUIs that incorporate widgets like buttons, check-boxes, menus and text-fields. In a nutshell AutoBlackTest works as follows: it executes the AUT interacting with the GUI, it learns the most relevant ways of interacting with the application, it identifies failures when they occur and it generates regression test suites at the end of the testing process. AutoBlackTest dynamically updates its knowledge about the application at run-time. At the beginning of system testing, AutoBlackTest has no knowledge about the AUT. While AutoBlackTest generates and executes system test cases, additional behavioural information are collected and incorporated into a behavioural model, that is used to take decisions about future actions that must be executed. AutoBlackTest handles this learning process using Q-Learning [12], a well-known reinforcement learning technique. The major contributions of this paper are twofold. Firstly, we presents a solution for automatic system testing, which not only generates and runs test cases but also sample the key executions of interactive GUI-based applications. Secondly, we introduce a novel test case generation approach that is based on reinforcement learning to accomplish the specific goal of testing and to guide the exploration process. The remainder of the paper is organized as follows. Section 2 provides an overview of the AutoBlackTest technique. Sections 3, 4, 5 and 6 discuss in detail the main modules of AutoBlackTest. Section 7 describes the generation of a final test suite that can be used for regression testing. Section 8 provides implementation details of AutoBlackTest. Section 9 summarizes our empirical results. Section 10 discusses related work. Finally Section 11 presents some concluding remarks. 2 Automatic System Testing AutoBlackTest completely automates the testing process of GUI-based applications. AutoBlackTest is based on Q-Learning [12] to identify and execute the features to be tested, and is implemented as an extension of the IBM Functional Tester tool. The Q-learning algorithm is originally designed to drive the actions of an agent that interacts with an unknown environment. In our case, AutoBlackTest is the agent and the application is the environment. The agent is defined as a classic autonomic component [6] that includes an Observer, a Learner, a Planner and an Executor. After the execution of each action, the Observer analyzes the GUI and extracts an abstract representation of the state the application; the Learner builds and refines the behavioral model according to the state captured by the Observer; the Planner uses the behavioral model to decide what is the next action to execute; and the Executor concretely executes the selected action. The behavioral model is a labeled multidigraph that 79

90 represents what the agent has learnt about the application and consists of a set of states, that is the states of the application, and a set of transitions, that is the GUI-actions. Furthermore, the agent annotates each transition with a reward and a Q-value that indicate the immediate and the accumulated utility of the action according to the goal of deeply testing the application respectively. To execute GUI-actions the agent alternates exploration and exploitation activities. Exploration activities consist of executing random actions, while exploitation activities consist of executing the actions with the highest reward. The length of the learning process is disciplined by the number and the length of the episodes that must be executed. The number of episodes indicates the number of test cases that must be executed. The length of the episode is the number of actions executed by the agent. Every time a new episode is executed, the agent randomly selects a state in the model and starts the new episode from the selected state. In the next sections, we describe with greater detail the behaviour of the Observer, the Learner, the Planner and Executor components, and how Auto- BlackTest synthesized system test cases at the end of the testing process. A running example is used throughout the reminder of the paper to explain and illustrate the main concepts. As a running example we use Universal Password Manager (UPM) v1.6 [2]. UPM is a personal password manager for storing user names, passwords, URLs and generic notes in a local or remote database protected by a single master password. 3 The Observer Q-learning uses an abstract representation of the state of the application to reason about the actions that can be executed. Since the concrete state of the application is huge and hard to abstract without using a detailed specification of its implementation, the state of the AUT is heuristically approximated with the state of the information that is directly visible to the user, that is the state of the widgets that are active in the current GUI. For example, the initial state of the UPM application, partially shown in Table 1, consists of all the widgets available in that state and the values of their properties. Table 1 shows a subset of the properties for the Password field. In addition of extracting state information, the observer can also capture both domain independent failures, like crashes, hangs and uncaught exceptions, and failures that cause violations of assertions, if available in the code. When detecting a failure, the observer maps the failure on the state and reports the sequence of actions that leads to the failure. 4 The Learner The Learner continually builds and updates the behavioral model according to the current state of the application and the last executed action. The Learner is 80

91 type 2 PasswordFieldUI text null enable true P 2 editable true visible true class JPasswordField Table 1: An example of state abstraction also responsible of computing the utility values of the action in term of reward and Q-value. In our context of testing a GUI-based interactive application, the utility of actions depends on their effects on the concrete GUI states, and consequently the effects on their abstract representations. The more the state changes, the more likely an action produced a relevant computation. The less the state changes, the less likely an action produced a relevant computation. For instance, writing some text in a text-area, splitting a check-box or selecting an element from a list in most of cases neither cause any relevant change in the GUI nor cause any relevant computation. On the contrary, submitting a request by clicking a button may produce large changes on the GUI state, and a relevant computation as well. The utility of an action is computed according to both the immediate utility of an action, that is the reward, and the Q-values, that is the utility of an action according to the knowledge level that the agent has about the application. Reward Function. To heuristically classify actions, the Q-Learning uses a reward function that assigns high/low reward values to actions that induce many/few changes in the abstract GUI states. Our reward function computes the reward value as the number of widgets that are present in the new state and the were not present in the previous state. Thus, an action that leads to a new window produces a high reward. While actions that do not change the widgets displayed on the current window are assigned with low reward. For the purpose of computing the reward, if a widget is not changed but some of its properties are modified, we count the widget as partially new according to the number of changed properties. Q-value Function. The reward function can estimate well the utility of an action when executed in isolation but cannot measure the value of the same action when composed into an entire scenario. For instance, a simple action that produces a transition between similar states (for example, filling a text area) can enable the execution of actions that produce transitions between largely different states (for example, successfully submitting a form). A testing process that aims to execute valuable computations needs to identify these simple transitions that 81

92 potentially enable actions that induce large state changes later on. Q-values exactly represent the value of an action computed considering both the immediate utility as defined by the reward function, and the utility of the actions that can be executed in the future. The Q-value of an action is obtained by summing to the reward of the same action, a percentage of the maximum reward that can be collected from the future states. The interested reader can access [12] for the detailed formula of the Q-value. In the following we exemplify how the Learner works with the running example. The graph in Figure 1 shows a few steps executed by AutoBlackTest in the first episode. The nodes represent the states of the application. The edges indicate the actions executed by AutoBlackTest. The values in the table below the graph indicate the value of both the reward(s) and the Q-value(s) at episodes 0 and 60. action episode 0 episode 60 reward Q-value reward Q-value OK.click 0, 308 0, 308 0, 308 1, 104 AS 0 Password.setText 0, 004 0, 004 0, 004 3, 269 AS 1 OK.click 0, 404 0, 681 0, 404 0, 884 AS 2 OK.click 0, 362 0, 362 0, 362 3, 628 Fig. 1: An expert of the behavioral model built while AutoBlactest analyzing the UPM application 82

93 Here we describe how AutoBlackTest can generate the graph in Figure 1. At the beginning AutoBlackTest has no knowledge about the AUT, so it initializes the behavioral model with the initial state of the application, which is AS 0. For sake of simplicity in Figure 1 we indicate the state of the application with a screenshot rather than with the formal representation of the GUI state. Then AutoBlackTest executes a random action. Let us suppose it interacts with the Master Password... window by clicking the Ok button, which produces a state transition from AS 0 to state AS 1. In the newly discovered state the Master Password... window disappeared and a Message window is displayed. The reward associated with the executed action is R =0, 308. The initial Q-value for this action is the same than the reward because the future states are unknown. The only action that can be executed from state AS 1 is clicking on the OK button that brings UPM back to state AS 0. The resulting action produces a reward of R = 0, 404. Since the target state AS 0 is already included in the behavioral model, the Q-value is computed taking into account both the reward associated to the action from state AS 1 and the Q-values of actions available in state AS 0 resulting in Q =0, 681. It means that the long term utility of the action is higher than the short term utility. In fact, going back to the initial state there are a number of actions that can be executed and it is intuitively a good action to be executed at this point. An example of an action that produces a very low reward (R =0, 004) is writing a password in the Password field. This case is also shown in Figure 1. Intuitively this action produces a low reward because only a single property of a single widget is modified after writing a password in the Password field. While AutoBlackTest continues executing actions, the learner incrementally updates the behavioral model by adding the newly discovered states, the newly executed actions, and by refining the Q-values. For instance, if we consider the reward and the Q-value at episode 60 associated to transitions in Figure 1, we can notice how AutoBlakcTest distinguished the relevant paths from the irrelevant ones. For instance, the path through states AS 0, AS 2, AS 3 represents a relevant scenario leading to a correct login. In particular in state AS 0 a correct password is typed and a click on the Ok button of the Master Password... window is executed. Although the action from state AS 0 to state AS 2 has a low reward, the corresponding Q-value is the highest one because it is a step that enables a number of relevant computations for UPM. In summary, executing an action with a high Q-value does not necessary immediately return a high reward, but indicates that future actions will likely produce a high reward. This feature of the Q-learning is extremely useful in guiding AutoBlackTest towards re-executing and deeply exploring the most relevant scenarios. 5 The Planner The role of the planner is deciding the action that must be executed at each state. Since decisions are carried out incrementally while AutoBlackTest inter- 83

94 acts with the AUT, the new information that is dynamically collected influences the decisions of the planner. At each step the planner chooses between executing an action that provides high Q-value (exploitation) and executing a random action (exploration). The Planner uses the -greedy policy [3, 7] to decide how alternating between exploration and exploitation. The -greedy policy simply chooses the best action, that is the action with the highest Q-value, with probability 1 and chooses uniformly otherwise. If we consider the model in Figure 1, and we assume that the current state is state AS 0 while the episode is episode 60, the planner can choose between executing a random action or a best action. In case the best action is selected, the planner writes some text in the Password field because it is the action with the highest Q-value. Otherwise, a random action is executed between the ones available in that state. 6 The Executor The executor is responsible of executing the action decided by the Planner on the GUIs. The set of available actions is composed of simple and complex actions. Simple Actions. A simple action consists of a single interaction with one of the widgets included into the current GUI. For instance, typing a password and clicking a button are simple actions. We defined a set of simple actions that covers the most relevant interactions with 40 different types of widgets. When a simple action is parametric, for instance writing same text into a text-area widget, the assigned values are chosen between a predefined set identified according to the boundary testing principle. When specific values are necessary to execute some functionalities, such as user authentication or server connections, the correct values are included into the predefined set of values. Complex Actions. A complex action addresses a specific case according to a strategy that is inferred from the number and types of elements available in a given GUI state. For instance, if multiple widgets that accept data values are displayed, it is activated the fillform action that fills all or most of these widgets before clicking a button. The rationale is that to activate the underlying functions, most of the widgets must be properly filled, otherwise no computation will be activated for insufficient data. It is possible to obtain the same result as a combination of simple actions, but the time to learn how to fill the widgets before clicking on the button may be undesirably long. Figure 2 shows the composed action fillform that automatically interacts with the form-like window Add Account. This window is used in UPM in order to insert a new account by typing information in the Text fields. When executing the fillform action, the executor actually executes a workflow of simple actions that fill multiple widgets. In this example, the executor fills the Account name, the User ID and the URL. 84

95 Fig. 2: The composed action fillform 7 Test Cases Generation When the maximum number of episodes is reached, the executed episodes are indeed test cases that AutoBlackTest generated during the interaction with the AUT. The entire set of test cases contains a lot of redundant behaviors that must be rejected before producing the final test suite. AutoBlackTest uses the additional statement coverage prioritization [11] to filter test cases. AutoBlack- Test starts ordering the episodes according to their decreasing code coverage rate. Then AutoBlackTest selects the episode with the highest coverage, adds it to the test suite, and it reprocesses the net coverage for the remaining episodes. A test case is included into the final test suite if it covers program statements not yet executed by the already selected test cases. 8 AutoBlackTest We implemented a prototype version of AutoBlackTest as an extension of the Eclipse IDE. Figure 3 shows the architecture of the tool. AutoblackTest integrates two third-party tools: IBM Rational Functional Tester (RFT) [5] and TeachingBox [4]. RFT is a capture and replay tool for automatic regression testing. AutoBlackTest uses RFT to interact with the GUI of the AUT. Since RFT supports many GUI frameworks, including most widelyuse desktop applications, AutoBlackTest inherits the same range of applicability. TeachingBox is a Java library developed in the field of artificial intelligence that implements reinforcement learning techniques. We extended the core of the Q-Learning to our specific needs by implementing the state abstraction functions, the GUI-actions and the reward function. The Agent is the core of the implementation of AutoBlackTest. The agent includes the four components described in previous sections and stores a representation of the behavioural model. The Observer directly communicates with RFT to access the concrete state of the application. This communication is performed by using the APIs provided by RFT. The Observer returns an abstract representation of the concrete state 85

96 Fig. 3: The AutoBlackTest architecture to the Learner. The Learner is responsible for updating the model according to the state value returned by the Observer. The Planner uses the model to decide the action that must be executed and the executor to concretely execute the action. Both the Planner and the Observer takes advantage of the TeachingBox component to update the behavioral model according to Q-learning. The Executor directly interacts through APIs with RFT to execute actions on widgets. In particular, the Executor is responsible for translating the GUIactions, as represented in the model, into the corresponding RFT GUI actions. Since interactions with the GUI are mediated by RTF, the AutoBlackTest implementation results to be largely independent from the technology used to implement the GUI. Finally, AutoBlackTest can synthesize the executed test cases into a test suites that can be replayed with RFT. The Test Case Selector is the component responsible for this task. Since the entire knowledge about the application is represented in the behavioral model, the Test Case Selector translates the executions represented in the model into a non redundant set of test cases. 9 Early Empirical Validation We validated AutoBlackTest with two desktop applications. We chose the applications among desktop applications in SourceForge, browsing different domains 86

97 and sizes. We chose UPM v1.6 [2], the application presented in the running example (2.515 loc); and Buddi v [1], a personal finance and budgeting program ( loc). We evaluated the effectiveness of AutoBlackTest in terms of number of discovered unknown faults in the target application. The effectiveness of AutoBlackTest has been evaluated by executing it three times on each case study. We ran AutoBlackTest for 180 episodes of length 31 and we set the parameter to 0.8. We already observed that the -greedy policy of Q-Learning works better with values of closer to 1 than 0. In our empirical studies, we also observed that AutoBlackTest achieves an excellent balance between exploitation and exploration by using a 0.8-greedy policy. The test oracles used for this validation detect crashes, hangs and uncaught exceptions. AutoBlackTest automatically revealed faults in all the tested applications. In particular, AutoBlackTest revealed 8 faults in UPM and 6 faults in Buddi. 12 out of 14 discovered faults are new faults not reported in the bug repositories of the applications. Results confirm the ability of AutoBlackTest to discover faults, especially when faults can be revealed only through rare combinations of actions, as frequently happens for system level faults. For instance, one of the faults that AutoBlackTest revealed in UPM leads to a failure only when a user first creates two accounts with an empty account name and then deletes the second account. This sequence of actions results in the impossibility of modifying the first account. In this case, the Observer collected a null pointer exception and reported the sequence of actions that leads to this failure. In several cases, AutoBlackTest discovered different sequences of actions that generate different failures but reveal the same faults. These cases can be helpful in debugging applications because the testers can use multiple failing scenarios to analyze the same faults. An example is the fault detected in Buddi, where the functionality that discards changes and reverts to the last saved version, works incorrectly in several scenarios. In editing account types, for instance, AutoBlackTest detected a failure that is triggered when a user modifies the list of the account types and then tries to revert to the last saved version. This produces no response from the application and the list of the account types is not reverted. The same fault is also revealed in the edit transaction scenario. In this case Buddi fails any time a user adds or removes a transaction and then tries to restore the last saved configuration. The Observer classified the two failures by using the different stack traces thrown by a class cast exception, and reported the two different sequences of actions that replicate the same faults. Failing test cases are included into the final test suite. For each application, AutoBlackTest successfully pruned the set of 180 executed episodes by eliminating redundant test cases and producing compact test suites that can be re-executed with IBM Functional Tester. AutoBlackTest distilled for UPM and Buddi respectively 27 and 52 test cases covering all the executed statements and failing scenarios. 87

98 10 Related Work The current state of art of system test automation for GUI-based interactive applications is mostly limited to capture and replay tools, such as Abbot [13] and IBM Rational Functional Tester [5]. These tools records the user interactions on a GUI as a test case that can be executed to replay the recorded interactions. Capture and replay tools are probably the most popular tools for regression testing, but the automatic generation of test cases is not supported. They rely on the manual generation of an initial test suite. AutoBlackTest completes these tools by automatically generating and executing test cases for interactive applications. In order to automate some aspects of test case generation for GUI-based applications, White et al. [14] have used state-machine models that divide the state space into different user tasks, responsibilities, and relates these tasks to different Complete Interaction Sequences (CISs). A CIS is a sequence of GUI widgets and selections that may be used to complete a responsibility. Each CIS contains a reduced finite-state machine, which is used to generate test cases. This approach is resource-intensive because test designers have to identify the responsibilities and the subsequent CISs by consulting the GUI design document, the user manual or the code of the application. Moreover, a significant manual effort is still required to design finite-state machines for each CIS. Another well-known approach consists of identifying a target subset of event sequences that can be produced by a GUI [8, 15] and then automatically generate enough test cases to cover these sequences. For example, smoke testing produces test cases that exercise sequences of system events, which are defined as events that trigger functional computations [9]. Yuan and Memon refine this idea by introducing a technique to generate test cases that cover semantically interacting events, which are pairs of system events that produce different results (more precisely different GUI states) when executed in different order [16]. These techniques automatically generate test cases by exploring an event interaction model, but inevitably overlook at the scenarios where the interaction between events does not produce an effect that is immediately visible at the user interface level. Moreover, the event interaction model cannot predict infeasible sequences of events a priori, since it is based on a static view of the AUT that is obtained by applying a reverse-engineering technique. The above approaches for test case generation, unlike our own, do not deal with the dynamic response of the AUT when stimulated by tests. AutoBlack- Test differs from previous related works in that it provides a complement way to dynamically and automatically generate system test cases during their executions, aiming to generate test cases that activate the functionalities of the AUT, possibly producing interactions among these functionalities. 11 Conclusions Automatic test case generation is an important technique to achieve cost-effective validation of software systems. In this paper, we addressed the problem of generating system test cases for GUI-based interactive applications. 88

99 The proposed approach automatically generates test cases based on Q-Learning. The technique is implemented in a tool that extends the IBM Rational Functional Testing Tool. Early empirical results show that the technique can automatically reveal faults that have not been revealed by developers of the tested applications. Our future work include running additional experiments and investigating the possibility to improve the selection of concrete values for actions with parameters by using ontologies in order to produce semantically valid and invalid values, rather than using a fixed set of values. References 1. Buddi UPM Abul, O., Polat, F., Alhajj, R.: Multiagent reinforcement learning using function approximation. IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews 30(4), (2000) 4. Ertel, W., Schneider, M., Cubek, R., Tokic, M.: The teaching-box: A universal robot learning framework. In: Proceedings of the International Conference on Advanced Robotics. IEEE (2009) 5. IBM: IBM rational functional tester ibm.com/software/awdtools/tester/functional/ 6. Kephart, J.O., Chess, D.M.: The vision of autonomic computing. IEEE Computer 43(1), (2003) 7. Lin, L.J.: Reinforcement learning for robots using neural networks. Ph.D. thesis, Carnegie Mellon University, Pittsburgh, PA, USA (1992) 8. Memon, A.M., Soffa, M.L., Pollack, M.E.: Coverage criteria for GUI testing. In: proceedings of the 8th European Software Engineering Conference held jointly with 9th ACM SIGSOFT International Symposium on Foundations of Software Engineering (2001) 9. Memon, A.M., Xie, Q.: Studying the fault-detection effectiveness of GUI test cases for rapidly evolving software. IEEE Transactions on Software Engineering 31(10), (2005) 10. Pezzè, M., Young, M.: Software Testing and Analysis: Process, Principles and Techniques. Wiley (2007) 11. Rothermel, G., Untch, R.H., Chu, C., Harrold, M.J.: Prioritizing test cases for regression testing. IEEE Transactions on Software Engineering 27(10), (2001) 12. Sutton, R., Barto, A.: Reinforcement Learning: An Introduction. MIT Press (1998) 13. Wall, T.: Abbot Java GUI test framework White, L., Almezen, H.: Generating test cases for gui responsibilities using complete interaction sequences. In: Software Reliability Engineering, ISSRE Proceedings. 11th International Symposium on. pp (2000) 15. Yuan, X., Cohen, M., Memon, A.M.: GUI interaction testing: Incorporating event context. IEEE Transactions on Software Engineering (to appear) 16. Yuan, X., Memon, A.M.: Generating event sequence-based test cases using GUI run-time state feedback. IEEE Transactions on Software Engineering 36(1), (2010) 89

100 TestCareAssistant: Automatic Repair of Test Case Compilation Errors Mehdi Mirzaaghaei and Fabrizio Pastore University of Lugano, Switzerland - University of Milano Bicocca, Italy [email protected] - [email protected] Abstract. Software systems undergo several changes in their life-time, and software developers often need to spend a lot of time in repairing test cases broken by the changes. Modern IDEs automate repair activities that involve basic structural changes but do not properly repair test cases when non-trivial analysis is required to preserve test cases behavior. The absence or the improper repair of test cases may lead to test cases that do not compile, do not properly test the application, or that unexpectedly fail. As a consequence software developers have to manually inspect test cases and repair them. We found that an important and frequent set of causes of test case compilation errors are changes that alter method signatures. This paper presents TestCareAssistant an Eclipse plug-in that automatically repairs test cases broken by changes in method signatures and overcomes the limitations of existing approaches. TestCareAssistant combines static and dynamic analysis to identify the variables and values to use when repairing test cases. Keywords: Software Testing, Software Maintenance, Test Cases Evolution 1 Introduction Software systems are frequently modified by software developers for different reasons, for example to improve the system architecture and speed up maintenance, or to meet new user requirements or to support new frameworks. Unfortunately the pleasure for users is often the pain for developers. Software developers in fact must retest the modified and new functionalities of the software to ensure software quality and avoid regressions [10]. What makes developers life harder is the necessity to not only write new test cases but also to repair the test cases broken by the changes, e.g. compilation errors that emerge after API changes [2]. Software developers can count on the recent improvements of development environments to speed up their maintenance tasks. Java developers that use the Eclipse IDE 1 for example may rely on ReAssert and the JDT Refactoring 2,two Eclipse plug-ins that repair errors in test oracles, and prevent compilation errors due to software refactoring respectively. Unfortunately JDT Refactoring,

101 ReAssert, and the other techniques proposed in literature focus on specific problems, e.g. invalid test oracles, or support development activities only partially (Section 2 shows that the JDT refactoring tools deal with simple changes only). As a consequence developers still manually maintain most of their test code. We recently analyzed 262 versions of 22 open source projects of the Apache Software Foundation 3 and discovered that changes in method declarations, a type of change that lead to test cases compilation errors, occur very often [13]. We also noticed that the method changes not well supported by existing tools, i.e. changes in the declaration of method parameters and return values, are a non trivial portion of the overall software changes, the 8%. In [13] we introduced TestCareAssistant, a technique that overcomes existing techniques by automatically fixing test cases compilation errors when these are caused by changes in method declarations. TestCareAssistant repairs test cases and preserve their behavior by automatically adapting the parameters of the method calls that cause the compilation errors. TestCareAssistant relies on static analysis to identify the values in the original version of the test cases that can be used to initialize the variables of the repaired test case. This paper advances [13] by presenting the TestCareAssistant Eclipse plugin, a tool integrated with the Eclipse IDE that can either automatically repair broken test cases, or suggest repairs to developers. The TestCareAssistant plugin advances the previous TestCareAssistant approach by integrating dynamic and static analysis to overcome the limitations of static analysis. The remainder of the paper is organized as follow: Section 2 overviews the limitations of existing techniques through a case study that we repaired with TestCareAssistant, Section 3 overviews the TestCareAssistant Eclipse plug-in. Sections 4 to 6 detail the activities performed by TestCareAssistant. Finally Section 7 summarizes preliminary results and concludes the paper. 2 Motivating Example In this section, we illustrate the limitations of the existing techniques by considering an example taken from PMD 4 a well known open source program 5. Listing 1.1 and 1.2 show how PMD developers modified the signature of method Report.addRule during the development of version 1.1 of PMD: they changed the type of the second parameter from String to Context. One of the consequences of the change are the compilation errors in the 13 test cases that use the modified method. Listing 1.3 shows one of the broken test cases, testbasic. The change in the method signature caused a compilation error on line 4 because the test passes variable filename, which is of type String, as second parameter of method Report.addRule, but method Report.addRule requires a parameter of type Context in version 1.1 of PMD A Java source code analysis tool : 5 We slightly modified the example to make it easier to understand. 91

102 Listing 1.4 shows the repair for the test case of Listing 1.3: developers instantiated a new object of type Context and initialize it using the same value used to define variable filename in version 1.0 (line 3). This way PMD developers preserved the behavior of the test: a random String or the empty String would have changed the meaning of the test. 1 public void addrule(int line, String file){ 2 this.line = line; 3 this.name = file; 4 } Listing 1.1. Method Report.addRule in PMD public void testbasic() { 2 Report r= new Report(); 3 String filename="foo"; 4 r.addrule(5, filename); 5 asserttrue(!r.isempty()); 6 } Listing 1.3. Test case for method Report.addRule in PMD public void addrule(int line, Context ctx){ 2 this.line = line; 3 this.name = ctx.getfilename(); 4 } Listing 1.2. Method Report.addRule in PMD public void testbasic() { 2 Report r= new Report(); 3 Context ctx= new Context("foo"); 4 r.addrule(5, ctx); 5 asserttrue(!r.isempty()); 6 } Listing 1.4. Test case of Listing 1.3 repaired to work with PMD 1.1 Although test maintenance activities like the change of PMD test case test- Basic could be straightforward, the number of test cases to be repaired can be very large. Developers often do not have time to update all the test cases along with the modified classes, thus many test cases become obsolete. While software systems evolve, many obsolete test cases diverge from the system and become hard to repair, thus developers need to rewrite new test cases from scratch [2]. In order to save maintenance time PMD developers could have looked for tools and techniques that support developers during refactoring. Different techniques automate some refactoring activities like moving or renaming methods, modifying class hierarchies [15], improving concurrency [5] and reentrancy [16]. A strightforward solution to automate refactoring is the adoption of the refactoring functionalities provided by IDEs like Eclipse. The refactoring menu of Eclipse for example provides the Introduce Parameter Object action that allows developers to automatically replace a parameter with a new type that boxes the original parameter [7]. For example it permits to replace a parameter of type String with a parameter of type Context, given that Context is not a type already defined within the project. Eclipse modifies also the test cases to prevent compilation errors. Unfortunately the simple solution provided by tools like Eclipse does not work in many cases: it is not applicable when a parameter should be replaced with an existing type; it does not allow developers to introduce types that require the invocation of a setter method to incapsulate the value in the object (the only possible behavior is to pass the original value as argument of the constructor); 92

103 it is not applicable to multiple methods (once applied to a method it generates the new type and thus cannot be applied to other methods); it is not applicable when developers need to manually modify the method signature; it is not applicable when test cases are developed as side projects (this is a general limitation of many automated refactoring techniques [17]). Unfortunately for PMD developers, method Report.addRule is not a method that can be successfully refactored using the simple approach provided by Eclipse: class Context has not been introduced with the refactoring of version 1.1 but was already used in version 1.0; furthermore the refactoring must be applied on two methods, two overloaded versions of addrule. Given that automated refactoring could not be applied, PMD developers may decide to manually modify the method declaration and then apply research techniques that automatically repair the broken test cases. Most of the exising techniques focus on the repair of GUI test cases [12,8], or erros in test cases for web applications [1], or test oracles of JUnit test cases [3]. These techniques require either models [8], or global test oracles [12] and focus either on the repair of GUI events only [12,8] or session data [1], or test oracles [3] Existing techniques thus cannot help PMD developers, who need to repair method invocations in unit tests written in the same language of the program, i.e. JUnit test cases written in Java. The only technique that solve errors caused by method refactorings is ReBA [6]. Unfortunately ReBa works only in case of backward compatible refactorings; in particular it prevents compilation errors when methods are either removed or renamed, or when parameters are added to methods and default values can be used in place of these parameters. ReBA does not cope with changes of the type of parameters and return values, or when new parameters cannot be replaced with default values (e.g. an empty string). For this reason also ReBA does not completely match the requirements of PMD developers. 3 Automatic Test Repair TestCareAssistant repairs test cases broken by software changes. In particular, TestCareAssistant focuses on compilation errors that occur when developers alter method signatures by modifying the type of the value returned by the method, or the number or type of the input parameters of the method. TestCareAssistant does not target simple compilation errors caused by method renaming or changes in the parameter order only. Developers usually perform these modifications using refactoring tools that prevent compilation errors, e.g. the tools integrated in Eclipse. TestCareAssistant also ignores modifications that do not cause compilation errors, for example the introduction of a return value. TestCareAssistant thus focuses on four different type of method signature changes: change of the type of one or more parameters, removal of one or more parameters, addition of one or more parameters, change of the return type. To be effective in all these cases TestCareAssistant implements a set of algorithms 93

104 that automate the activities commonly performed by software developers when they repair test cases. %&$' *&$' +$( (,& ) ) ( )# $# #"!" Fig. 1. TestCareAssistant Approach We developed TestCareAssistant as a library with a GUI interface provided by the TestCareAssistant Eclipse plug-in. Figure 1 illustrates TestCareAssistant operating steps. After modifying a method, software developers usually re-compile the software (IDEs often perform this operation automatically). If a change breaks one or more test cases compilation errors are generated by the compiler and shown by the IDE. Then software developers can run TestCareAssistant to repair the test cases (it is not mandatory to execute TestCareAssistant right after the compilation error shows up, TestCareAssistant can be applied on test case compilation errors of any age). Developers can run TestCareAssistant on a single compilation error or on a set of test classes. To repair a single compilation error software developers use a contextual menu shown within the Eclipse IDE editor. To repair one or more test classes software developers select the classes to repair from the Eclipse project explorer and run TestCareAssistant using a given contextual menu. In both the cases TestCareAssistant behaves similarly: it receives from the user a list of one or more compilation errors to repair. When invoked on a single compilation error TestCareAssistant suggests a repair action using the Eclipse Editor contextual menu and applies the repair only if the developer accepts it. When run on one or more test classes TestCareAssistant automatically repairs all the compilation errors of the selected classes. The first scenario is useful in case of critical software when software developers need to validate all the changes. The second scenario is particularly useful in case of regression test cases generated automatically by test case generation techniques [14]. Test case generation techniques typically generate a lot of test cases, and the manual correction of the broken ones may be time consuming; for this reason, software developers usually discard broken test cases [14]. This common practice reduces the effectiveness of the regression test cases because they cannot identify regressions that affect methods with modified signatures. 94

105 TestCareAssistant thus could improve the effectiveness of test case generation techniques in presence of regression errors and method refactorings. TestCareAssistant requires four inputs: the original and the modified version of the program, the test cases broken by the changes, and the compilation errors. The TestCareAssistant Eclipse plug-in assumes that the modified version of the software corresponds with the Eclipse Project on which the developer is working. The original version of the software should be an Eclipse project too, and must be indicated by the developer using an appropriate menu. TestCareAssistant retrieves the list of compilation errors and broken test cases from the IDE APIs, then it repairs all the compilation errors by iterating three activities: analyze the change, determine the initialization values and repair the test case. Sections 4, 5, and 6 detail the three activities respectively. 4 Analyze the Change The first activity performed by TestCareAssistant regards the identification of both the changed elements (i.e. the modified parameters and return values), and the type of change. TestCareAssistant first identifies the methods that need to be repaired using the information about the compilation errors. If a compilation error does not involve method invocations, TestCareAssistant cannot fix the error and continues with the next error. Otherwise, TestCareAssistant identifies the type of the change by simply diffing the signatures of the modified methods. In the current prototype, we target Java programs, and we use JDiff 6. From the differences between the methods before and after the changes, TestCareAssistant then identifies the set of elementary actions that comprise the changes in terms of parameter additions, removals, type changes, and return type changes. For example, when applied to the PMD example in Figure 1.1 TestCareAssistant determines that the type of the first input parameter of method Report.addRule has been changed from String to Context. 5 Determine the Initialization Values After having identified the elementary change responsible for the compilation error, TestCareAssistant determines both the program variables that must be initialized, and the proper initialization values that preserve the behavior of the test case. TestCareAssistant determines the program variables to initialize by comparing static data flow information of the original and the modified software, and identifies the proper initialization values by dynamically analyzing the original software. The combination of static data flow and dynamic analysis produces a set of pairs variable, value that indicate the proper initialization values for the variables

106 TestCareAssistant adopts different analysis strategies according to the type of change identified in the first phase. If the change involves input parameters, TestCareAssistant derives the initialization values from the analysis of the original code. If the change involves the return value of a method, TestCareAssistant derives the initialization values starting from the modified code. 5.1 Initialize variables in case of parameter modification Determining the proper values to initialize the modified variables is hard. Parameters of type class in fact can be complex to initialize, because of the presence of many attributes whose initialization values may be difficult to determine. On the other hand, not all the elements of the class may need to be initialized to execute a given test case. For this reason, once identified the modified parameters, TestCareAssistant tries to identify the fields that need to be initialized in order to execute the test cases. To identify the variables to initialize, TestCareAssistant locates the first use of the modified parameter in the new version of the software system. If the modified parameter is an object, TestCareAssistant determines the scope of the initialization required to fix the test by checking if the first use involves the whole object or one of its fields. If the first use does not involve the whole object, then TestCareAssistant identifies the object attributes used during the execution of the method, and locates their first use. TestCareAssistant uses Datec [4] to identify all the uses of the attributes, and then traverses the interprocedural control flow graph [9] provided by Soot 7, starting from the modified method, to identify the first use of each attribute. If the modified parameter is of a primitive type or is an object whose fields are not accessed in the first use, TestCareAssistant identifies the parameter itself as the only program element to initialize. In the PMD example, the parameter ctx of method Report.addRule is used to invoke method getfilename. TestCareAssistant then locates all the uses of the fields of the class Context that are reachable from the invocation of method addrule. In this example only field filename is accessed within the execution of method Report.addRule, since it is read by the getter method Context.getFilename. TestCareAssistant thus needs to initialize only field filename. TestCareAssistant determines the proper initialization values values that preserve the test behavior by looking for the corresponding values used in the test cases of the original software. TestCareAssistant first builds a list of all the locations where the variables to initialize are used in the modified software. TestCareAssistant includes into this list also the variables that are an exact copy of the variables to initialize. TestCareAssistant finds these variables by inspecting the def-use chain of each variable. In the PMD example TestCareAssistant finds two locations: one is the use of field filename in the getter method Context.getFilename, the other

107 is the use of the value returned by method Context.getFilename in line 4 of method Report.addRule. TestCareAssistant then uses Soot to traverse the interprocedural control flow graph of the modified method to sort the locations according to the order it encounters them. This way TestCareAssistant derives an ordered set of the uses of each variable to initialize. For each variable to initialize TestCareAssistant starts from the first use in the set of its uses and looks for a corresponding line in the original software. TestCareAssistant identifies the corresponding line by diffing the original and the modified source code of the method with JDiff. AlineL0 of the original source code corresponds to a line L1 of the modified code if L0 is the counterpart of L1, as usually determined by the Unix diff algorithm, and L0 and L1 differ at most for: the name of the defined variable, a term, a literal or a variable that replaces the variable to initialize in the original software (we call this the corresponding term). If the Unix diff identifies multiple counterparts for line L1, TestCareAssistant selects the line most similar to L1 according to the Levenshtein distance [11]. If no corresponding line is found TestCareAssistant proceeds with the next use, otherwise TestCareAssistant finds a term that corresponds to the use of the variable to initialize by applying the Needleman Wunsch global alignment algorithm on the line in the modified software and its corresponding in the original one. If TestCareAssistant does not find any corresponding line for a variable to initialize, it indicates the initialization value of this element as unknown. In the PMD example, line 4 of Listing 1.1 is the line that corresponds to the use of ctx.getfilename() at line 4 in Listing 1.2, and file is the term that corresponds to field ctx.filename. We can determine the value of the corresponding term in the original software either statically or dynamically. In [13] we described the static approach. TestCareAssistant currently implements a dynamic approach that is used to overcome the limitations of the static one. TestCareAssistant implements the dynamic approach by instrumenting the binaries of the original software with Soot, and by running the original version of the test cases to record the dynamic value of each corresponding term. In the PMD example the execution of the instrumented version of the software allowed TestCareAssistant to determine that the value to be used to initialize field filename of class Context was the String foo. The same approach used for parameter type changes is adopted also for parameter additions, while a slightly different approach is adopted for the case of parameter removals. In the case of parameter removals the modified parameter is no longer available in the new version of the software. For this reason Test- CareAssistant starts by analyzing the original version of the software. It first identifies a set of variables to initialize by locating the use of either the removed parameter or one of its fields in the original software. Then for each variable to initialize, TestCareAssistant finds the corresponding term in the modified software, i.e. the element that replaces the original parameter or one of its fields in the modified version. TestCareAssistant inspects the interprocedural def-use chain of the corresponding term to identify the methods that set its value, and 97

108 then uses dynamic analysis to determine the value to use to initialize the new element. 5.2 Initialize variables in case of return type change %! % & ' ( ) * +!! "#!!$ %% % & ' ( ) * +, Fig. 2. Identification of initialization values in case of return type change When the change regards the type of the return value of a method, TestCareAssistant changes the initialization of the variable that uses the return value. Figure 2 shows a simple example for this case. TestCareAssistant identifies the sequence of inspectors and fields that the new test case should access to initialize the variable defined with the value returned by the modified method. The underlying assumption of TestCareAssistant is that the values returned by the original method can be found in the state of the modified application too. TestCareAssistant first identifies the program variable or constant returned by the original method (e.g. field balance at line 7 in Figure 2). TestCareAssistant then traverses the def-use chain of the variable to identify the definition of the variables that at runtime may have the same value ( e.g. the definition of variable balance at lines 2 and 4). Then TestCareAssistant processes the list of definitions. TestCareAssistant looks for the corresponding occurrence of the first definition. In the example of Figure 2 the corresponding definition of balance in line 2 of the original method is found on line 2 of the modified method. Test- CareAssistant then uses static analysis to find the sequence of getter methods or fields that permits to retrieve the value of the variable within the test. TestCareAssistant iterates these operations till it finds a variable that can be accessed within the test case, or until all the variable occurrences have been inspected. In the example of Figure 2 TestCareAssistant detects that class Money declares a getter method, getvalue, that permits to retrieve the value of variable balance within the test by invoking method getvalue on the object returned by method getbalance. 98

109 6 Repair the Test Case TestCareAssistant repairs the test case by first removing the compilation error by changing the variables used with variables of a proper type, and then initializes the test variables with proper values to preserve the test behavior. In the case of parameter type change of the PMD example TestCareAssistant behaves like the software developers by defining a new variable of type Context (step 1.1 in Figure 3), and passing it as argument of method addrule (step 1.2).!"#$ % & ''!"#$ % & '' '!"#$ % Fig. 3. Repair actions for the PMD case study shown is Section 2 TestCareAssistant then initializes the variables declared in the test cases according to the results of previous steps. To preserve the test behavior TestCareAssistant should initialize variables of different type, like primitive arguments of methods, or fields belonging to objects declared in the test case. TestCareAssistant initializes the primitive arguments by simply assigning the values as computed in phase determine the initialization values. TestCareAssistant initializes the fields of the objects introduced in the repair by invoking the constructor that initializes most of the fields. Step 2.1 of Figure 3 shows that in the PMD example TestCareAssistant initializes variable ctx by instantiating an object of type Context using the constructor that initializes field filename. When the variable to initialize does not belong to variables introduced by TestCareAssistant, or when the constructor of a variable introduced by TestCareAssistant does not initialize all the fields, TestCareAssistant invokes the setter methods that initialize these fields. Figure 4 shows the repair actions for the return type change presented in Section 5.2. TestCareAssistant first creates a new variable to hold the return value of the modified method (steps 1.1 and 1.2), and then initializes variable balance with the sequence of getters identified in phase determine the initialization values (step 2.1). 7 Conclusions This paper presents TestCareAssistant, a technique and a corresponding Eclipse plug-in to help software developers in automatically fixing test case compilation errors caused by changes in method declarations. 99

110 !! Fig. 4. Repair actions for the test of method getbalance In [13] we described a preliminary evaluation of TestCareAssistant conducted by applying TestCareAssistant on 22 test cases that suffer from 24 compilation errors of 6 open source systems 8. The results highlighted the effectiveness of the approach in repairing the 75% of the errors. The preliminary evaluation was conducted using a preliminary version of TestCareAssistant that did not integrate dynamic analysis with static analysis. The limitations of static analysis in presence of data flows that involve complex objects like hash tables was the primary cause of in-success. The TestCareAssistant Eclipse plug-in presented in this paper combines static and dynamic analysis to compare the data-flow of the original and modified methods and to effectively identify the values to be used to repair the test cases and preserve their behavior, thus overcoming the limitations of the adoption of static analysis only. Future work regards the execution of the current version of TestCareAssistant on a larger set of case studies in order to evaluate the effectiveness of the combination of dynamic and static analysis. We furthermore aim to setup an empirical study involving different software developers to determine if the TestCareAssistant Eclipse plug-in improves developers productivity. References 1. Alshahwan, N., Harman, M.: Automated session data repair for web application regression testing. In: ICST 08: Proceedings of the 2008 International Conference on Software Testing, Verification, and Validation. pp (2008) 2. Berner, S., Weber, R., Keller, R.K.: Observations and lessons learned from automated testing. In: ICSE 05: Proceedings of the 27th international conference on Software engineering. pp (2005) 3. Daniel, B., Dig, D., Gvero, T., Jagannath, V., Jiaa, J., Mitchell, D., Nogiec, J., Tan, S.H., Marinov, D.: Reassert: a tool for repairing broken unit tests. In: ICSE 2011: Proceeding of the 33rd international conference on Software engineering. pp ACM (2011) 4. Denaro, G., Gorla, A., Pezzè, M.: DaTeC: Contextual data flow testing of java classes. In: Companion of the Proceedings of 31st International Conference on Software Engineering. pp (2009) 8 The errors were due to the following changes: 9 parameter types changed, 8 parameters added, 3 parameters removed, 4 return types changed. 100

111 5. Dig, D., Marrero, J., Ernst, M.D.: Refactoring sequential java code for concurrency via concurrent libraries. In: ICSE 09: Proceedings of 31st annual IEEE International Conference on Software Engineering. pp (2009) 6. Dig, D., Negara, S., Mohindra, V., Johnson, R.: Reba: refactoring-aware binary adaptation of evolving libraries. In: ICSE 08: Proceedings of the 30th international conference on Software engineering. pp (2008) 7. Fowler, M., Beck, K., Brant, J., Opdyke, W., Roberts, D.: Refactoring: Improving the Design of Existing Code. Addison-Wesley Professional (1999) 8. Grechanik, M., Xie, Q., Fu, C.: Maintaining and evolving GUI-directed test scripts. In: ICSE 09: Proceedings of the 31st International Conference on Software Engineering. pp (2009) 9. Harrold, M.J., Rothermel, G., Sinha, S.: Computation of interprocedural control dependence. In: ISSTA 1998: Proceedings of the ACM SIGSOFT international symposium on Software testing and analysis. pp ACM (1998) 10. Harrold, M., Orso, A.: Retesting software during development and maintenance. FoSM 2008: Frontiers of Software Maintenance pp (2008) 11. Levenshtein, V.: Binary codes capable of correcting spurious insertions and deletions of ones. Problems of Information Transmission 1, 8 17 (1965) 12. Memon, A.M.: Automatically repairing event sequence-based GUI test suites for regression testing. ACM Transactions Software Engineering Methodology 18(2), 1 36 (2008) 13. Mirzaaghaei, M., Pastore, F., Pezzè, M.: Automatically repairing test cases for evolving method declarations. In: ICSM 10: Proceedings of 26th IEEE International Conference on Software Maintenance. pp. 1 5 (2010) 14. Orso, A., Xie, T.: Bert: Behavioral regression testing. In: WODA 08: Proceedings of the 2008 international workshop on dynamic analysis. pp ACM, New York, NY, USA (2008) 15. Streckenbach, M., Snelting, G.: Refactoring class hierarchies with KABA. In: OOP- SLA 2004: Proceedings of the 19th annual ACM SIGPLAN conference on Objectoriented programming, systems, languages, and applications. pp (2004) 16. Wloka, J., Sridharan, M., Tip, F.: Refactoring for reentrancy. In: Proceedings of the ACM SIGSOFT symposium on The foundations of software engineering. pp (2009) 17. Xing, Z., Stroulia, E.: Refactoring practice: How it is and how it should be supported an Eclipse case study. In: ICSM 2006: Proceedings of IEEE International Conference on Software Maintenance. pp (2006) 101

112 I S S I 102

113 M = I,O,S,s 0,δ,λ s 0 δ λ S M s S s S s = δ(s, i) o = λ(s, i) a b a.b a b i = i 1.i 2...i k o = o 1.o 2...o j δ : S I S s 1 i M s i+1 = δ(s i,i i ) i 103

114 a/0 s 1 b/1 b/0 a/1 s 2 b/1 s 3 a/0 M λ : S I O s 1 i M = I,O,S,T T <s,i,o,s > s I,O,S M M s M i M i M i M s M s M s s s s e M i t s s s e s e = s e t M s s s s e M i t s s s e o o = o i M s o i M s M i i o M s o M i o o o M i M s 104

115 M s M i M s M s i λ(s, i ) = λ(s,i ) λ δ M s s S M i M i M s x λ(s, x ) = λ(t, x ) s i s S i I x y x = y.a δ(s i,y )=s W i s j = x W i λ s i x = λ s j x W i s i 105

116 1 1 Fsm initialstate: State supportstateinput: Boolean supportresetinput: Boolean * * State name: String Transition input: String output: String tail: State head: State 106

117 FsmUnit. ConformanceTester FsmUnitApi FsmUnit.Diagram FsmUnit 107

118 108

119 109

120 S S S I I S S 110

121 111

122 112

123 113

124 An Eclipse plug-in for Test-to-Code Traceability Recovery Abdallah Qusef, Gabriele Bavota,RoccoOliveto, Andrea De Lucia, and David Binkley University of Salerno, Fisciano (SA), Italy, University of Molise, Pesche (IS), Italy Loyola University Maryland, Baltimore, USA Abstract. Developers write and maintain unit tests continually in order to reflect changes in the production code and maintain an effective regression test suite. In addition, during refactoring developers must ensure that all unit tests continue to pass, so unit tests often need to be refactored together with the source code. Traceability links between application code and respective unit tests are extremely useful to preserving consistency during refactoring. Unfortunately, support for identifying and maintaining traceability links between unit tests and tested classes in contemporary software engineering environments and tools is not satisfactory. This paper presents SCOTCH (Slicing and COupling based Test to Code trace Hunter), a tool implemented as an Eclipse plug-in that uses dynamic slicing and conceptual coupling to automatically establish the traceability links between unit tests and application code. The evaluation of SCOTCH on several software systems highlights its usefulness as a feature within a software development environment. Keywords: Slicing, Conceptual Coupling, Traceability. 1 Introduction Software Traceability is defined by IEEE 1 as the degree to which a relationship can be established between two or more products of the development process [1]. Thus, traceability information helps software engineers to understand the relationships and dependencies among various software artefacts. For this reason, it provides important insights during software development and evolution, and aids in program comprehension, maintenance, impact analysis, and reuse of existing software [17]. In agile development, unit tests are written by developers to help understand a problem and, when using test driven development, are written ahead of any new code. In addition, unit tests are continually updated to reflect changes in the production code and thus maintain an effective regression suite [2]. This activity 1 IEEE:Institute of Electrical and Electronics Engineers

125 Fig. 1. Test Case Wizard and Search-Referring-Tests menu in Eclipse can be easily supported when traceability links between unit tests and tested classes are explicitly maintained. For example, during refactoring, traceability information can play an important role in preserving the consistency between the changes applied to the production code and the behavior tested by the unit tests. Indeed, code refactoring is often followed by unit test refactoring [3, 4]. In such a scenario, the presence of the traceability links between unit tests and the classes under test facilitates the refactoring process [15]. Unfortunately, these traceability links are often not documented and thus no explicit link is available. To solve this problem we present SCOTCH (Slicing and COupling based Test to Code trace Hunter), an Eclipse plug-in that supports a developer in the identification of dependencies between unit test and tested classes. The traceability recovery process behind SCOTCH was presented in [11] and is composed of two steps. In the first step SCOTCH uses dynamic slicing [12] to identify all the classes that affect the result of the last assert statement in each unit-test. This set of classes will also include support classes (i.e., mock objects and helper classes), besides the actual tested classes. Then, in the second step, Conceptual Coupling [16] is exploited to discriminate between the actual tested classes and the support classes. The paper is organized as follows. Section 2 discusses related work, Section 3 presents the proposed traceability recovery approach, while Section 4 presents SCOTCH, highlighting its use in practical environments. Finally, Section 5 provides some evaluation results and concluding remarks. 115

126 2 Related Work Today s integrated development environments offer little support to a developer in need of linking unit tests with the related classes under test. For example, the Eclipse Java environment 2 suggests, when creating a unit test using the pre-defined wizard (see Figure 1), that the developer provides the corresponding class under test. Moreover, as shown in Figure 1, Eclipse offers a search-referringtests menu entry that retrieves all unit tests that call a selected class or method. However, no functionality is provided to support the software engineer in the recovery of traceability links between unit tests and the classes under test. To address these issues and to mitigate the Eclipse drawbacks, Bouillon et al. [7] present a JUnit Eclipse plug-in that uses Static Call Graphs [8] and Java s annotation string construct to identify, for each unit test, the classes under test. Most other approaches proposed in literature are not integrated into an IDE. Sneed [19] proposed a name matching and manual linking based approach that first maps code functions to requirements and then links test cases to code functions by associating test case time stamps with code function stamps. Rompaey and Demeyer compare four approaches: Naming Convention (NC), Last Call Before Assert (LCBA), Latent Semantic Indexing (LSI) [9], and Coevolution [18]. NC relies on the name of a unit test to identify the class under test by removing the prefix Test from the name of the unit test. LCBA exploits the static call graph to identify the set of tested classes as those called by the statement that precedes an assert statement. LSI computes the textual similarity between the unit test and the classes of the systems to retrieve tested class, while Co-evolution assumes that the tested class co-evolves with the unit test. Rompaey and Demeyer show that these approaches are not effective in identifying traceability links between unit tests and classes under test [18]. The results indicate that NC is the most accurate, while LCBA has a higher applicability (consistency). Nevertheless, these two approaches have important limitations. With regards to NC, it is based on the assumption that naming conventions are used to name the unit test and that a single class is tested by each unit test. However, such assumptions are not always valid in practice, especially in industrial contexts [10]. As for LCBA, it fails when, right before an assert statement, there is a call to a state-inspector method from a class that is not the class under test [10]. To overcome such limitations, we analyzed the last assert statements in unit tests and performed a simple reachability analysis that takes into account only data dependence to recover traceability links between unit tests and classes under test [10]. This approach ignores control dependences and other issues, such as aliasing, inter-procedural control and data flow, and inheritance. The results achieved indicate that on one hand the approach is able to identify tested classes with higher precision than NC and LCBA, while, on the other hand, it fails to retrieve a sensible number of tested classes (low recall)

127 Dynamic Slicing Step UnitTest Identifying the last assert statement for each method asserttrue(...) slicing critirion Dynamic slicing Class in STS Class Class Extracting the Classes slice slice slice Semantic Filtering Conceptual Coupling Class Class in CTS Conceptual Coupling Step Fig. 2. SCOTCH traceability recovery process. In [11] we introduced SCOTCH, a novel approach to traceability link recovery. SCOTCH exploits dynamic slicing [12, 13] to identify the set of classes that affect the last assert statement. It is able to identify a larger number of classes as compared to the approach proposed in [10], since it considers several aspects that are completely ignored in [10]. The use of slicing helps in improving recall but the set of identified classes is an overestimate of the set of tested classes because it also includes helper classes. This negatively impacts the approach s precision. To address this short coming, conceptual coupling is used to discriminate between the actual tested classes and helper classes and thus improve the accuracy of the approach. 3 The Traceability Recovery Method The traceability recovery process behind SCOTCH is based on the following assumptions: 1. unit tests are classes whose methods implement the tests of a test suite [5]. In each test, the actual outcome is compared to the expected outcome (oracle) using an assert statement. However, assert statements are also used to verify the testing environment before verifying the actual outcome [15]. Since each 117

128 method of the unit test implements a specific test case, we assume that the last assert statement in the unit-test method compares the actual outcome with the oracle [10]. This means that tested classes affect the result of the last assert statement in each unit-test method; 2. unit tests are related to different types of classes including mock objects, helper classes, and tested classes [15]. Support classes (mock objects and helper classes) are used to create the testing environment, while tested classes are the actual classes under test. We conjecture that the textual content of the unit tests is closer to the tested classes than to the helper classes or mock objects. Based on these assumptions, SCOTCH identifies the set of tested classes using the two steps shown in Figure 2. In the first step dynamic slicing is exploited to identify an initial set of candidate tested classes, called the Starting Tested Set (STS). Previous studies indicate that in general for a method implementing a unit-test, the results of the last assert statement in the method are affected by methods belonging to the tested classes [10]. Thus, we use the last assert statement in a unit test as the slicing criterion (starting point for the slice). In particular, we employ backward dynamic slicing [12] to identify the initial set of classes by finding all the method invocations that affect the last assert statement in each unit-test. However, the set of classes identified using dynamic slicing may include many helper classes as well as classes belonging to mock objects and those from standard libraries (e.g., String). The latter are removed from the STS through a stop-class list (i.e., a list of classes from standard libraries such as java.*, javax.*, org.junit.* ), while the helper classes are identified and pruned-out of the STS in the second step of the process. Indeed, we conjecture that a unit test is semantically related to the classes under test (in particular, their textual similarity is higher than the similarity between unit tests and helper classes, which are used more uniformly across all tests). In other words, the semantic information captured in the unit test by comments and identifiers is closer to that of the tested classes than to that of the helper classes. This closeness can be measured using the Conceptual Coupling Between Classes (CCBC) [16]. CCBC uses Latent Semantic Indexing (LSI), an advanced Information Retrieval (IR) technique [9] to represent each method of a class as a real-valued vector that spans a space defined by the vocabulary extracted from the code. We use CCBC to rank the classes in the slice according to their coupling with the unit test. The higher the rank, the higher the likelihood that the class is a tested class. Thus, once the classes in the STS are ranked according to their conceptual coupling with the unit test, a threshold is used to truncate the ranked list and identify the top coupled classes that represent the candidate tested classes. Defining a good threshold aprioriis challenging, because it depends on the quality of the classes in terms of identifiers and comments as well as on the number of tested classes. For this reason, we use a scaled threshold t [17] based on the coupling between the unit test and the top class in the ranked 118

129 Select stop-class list Fig. 3. SCOTCH: traceability recovery view. list: t = λ CCBC c1 where CCBC c1 is the conceptual coupling between the unit test and the top class in the ranked list and λ [0, 1]. The defined threshold is used to remove from the STS classes that have a conceptual coupling with the unit test lower than λ% of the conceptual coupling between the unit test and the top ranked class. The resulting set is called the Candidate Tested Classes (CTS). 4 Integrating SCOTCH in the Eclipse IDE SCOTCH contributes a new view to the Eclipse workbench that allows a developer to recover traceability links between unit tests and tested classes. The developer can select a unit test, a package, or an entire software project in the Eclipse Package Explorer, and press the button in the view to start the recovery process. If the developer selects a module (i.e., a package or a project) SCOTCH automatically identifies the unit test classes and then recovers links for each unit test. The results are then reported in the view shown in Figure 3. Indeed, for each candidate link, SCOTCH provides a checkbox that allows the developer to trace (or not) the link between the unit test and the candidate tested class. For each unit test, SCOTCH shows the classes belonging to its STS as well as to its CTS. The checkbox for the classes in the CTS are automatically checked to suggest to the developer which are (based on our approach) the tested classes. Once the developer has finished his or her classification, the traced links are stored in an XML file. In the following subsections we first demonstrate the traceability recovery functionality and then explain the fundamental underlying concepts of the tool and then how the traceability information can be used by SCOTCH to highlight inconsistency between the production code and related unit test. Finally, we describe the SCOTCH architecture. 119

130 Fig. 4. Fragment of NetworkCommunicationTest from AgilePlanner 4.1 Recovering Traceability Links To explain the traceability recovery functionality of SCOTCH we consider the unit test testsendfromservertoonlyoneclient from the class NetworkCommunicationTest shown in Figure 4. In order to identify the class(es) tested by such a unit test, the developer selects this unit test in the Eclipse Package Explorer and presses a button in the view to start the recovery process. Note that SCOTCH also supports the recovery on sets of tests. In particular, the developer can select a package or a project and SCOTCH will automatically recover links for each unit test found automatically by detecting all the classes that inherit from class TestCase. The recovery results are reported in the view shown in Figure 3. The view shows all the classes that are retrieved from the dynamic slice taken with respect to the last assert statement in a unit test. In the example, SCOTCH slices with respect to the assert statement assertnull(client2.messagereceived()), which yields the initial set of classes Message, MessageDataObject, XMLSocket- Server and XMLSocketClient. The view also reports, for each class retrieved by slicing, the CCBC value between the class and the unit test under analysis. From this list, SCOTCH automatically checks as tested those classes having high conceptual coupling with the unit test under analysis. In our example, the tool checks as tested the classes XMLSocketServer and XMLSocketClient, which correctly identifiers the tested classes. However, for each candidate link SCOTCH provides a checkbox option that allows the user to confirm (or not) the link between the unit test and the can- 120

131 Fig. 5. Modifying method in Converter class Fig. 6. SCOTCH results for ConversionTest didate tested class. Once the user has finished its classification, the traced links are stored in XML files. Finally, note that a stop-class list (i.e., a list of classes from standard libraries such as java.*, javax.*, org.junit.* ) is used by SCOTCH to filter the set of classes identified by slicing. The developer can setup this list according to his or her application domain and requirements, by selecting the stop-class list button in the SCOTCH view (see the upper left of Figure 3). 4.2 Highlighting Inconsistency between Unit Test and Tested Classes The traceability links, stored in XML files, can be exploited to support the development process by helping to maintain the consistency between modified production code and its related unit tests. To illustrate this functionality, we consider a modification to the class Converter, shown at the top of Figure 5. Suppose the modification of class Converter updates the method fromxml by replacing the call to unmarshal with a call to marshal. Theresultingcodeis 121

132 shown in the bottom of Figure 5. Further suppose that class Converter is tested by the unit test ConversionTest as indicated in Figure 6. The change to method fromxml may affect the correctness of the unit test ConversionTest. Thus, as illustrated in Figure 7, SCOTCH alerts the developer by giving a warning message advising the user to check if the related unit tests might need modification to reflect the changes made in one or more of the tested classes. Fig. 7. SCOTCH: consistency checking 4.3 Architecture The plug-in is decomposed into four modules, namely View, Link Retriever, XML Manager, and Consistency Manager (see Figure 8). The module View implements the presentation layer of the plug-in. In particular, as shown in Figure 3, it supports the visualization of the links that SCOTCH discovers. This view extends the ViewPart view defined in Eclipse. The traceability recovery process used by SCOTCH is implemented in the Link Retriever module. This module takes as input the set of unit tests selected by the user (that can be a single unit test, a package, or an entire software project) and uses the JavaSlicer 3 tool to identify the STS for each unit test. Then, using an nternal LSI-based IR-Engine [9], the Link Retriever module computes the conceptual coupling between each unit test and the classes contained in its STS in order to compute the CTS, which is then shown to the user. The links traced by the user are stored in XML files using the XML Manager module that is in charge of managing all the operations performed on the produced XML files. Finally, the Consistency Manager module maintains consistency between the changes applied to the classes in the production code and the behavior tested by the related unit tests. To this end, this module analyzes the operations performed by the user on the production code and check if the performed changes potentially affect the correctness of the related unit tests. The link between the production code and the unit tests are provided by the XML Manager module

133 View Eclipse ViewPart Link Retriever Consistency Manager JavaSlicer XML Manager Fig. 8. SCOTCH architecture 5 Conclusion Several traceability recovery tools have been proposed in the past. Although in general different approaches (e.g., those based on IR and Co-evolution) have been successful in identifying traceability links between different types of artefacts, the authors have shown that these approaches are not effective in identifying traceability links between unit tests and the classes under test [18, 10]. In this paper we presented SCOTCH, an Eclipse plug-in that supports a developer in the recovery of traceability links between unit tests and tested classes. In prior work [11], we compared the accuracy of SCOTCH with benchmark tools based on naming conventions (NC) [18], Last Call Before Assert (LCBA) [18], and data-flow analysis (DFA) [10] using three programs as a testbed (Agile- Planner, exvantage, and ArgoUML). We assessed the accuracy of each recovery methods using the F-measure (the harmonic mean of precision and recall) [20]. For SCOTCH the threshold parameter value 0.95 was used for λ because it provides the best average performance on these three programs. Figure 9 compares the F-measures attained by SCOTCH and the three benchmark tools. Overall, SCOTCH provides the best performances. In more detail, for AgilePlanner and exvantage (where naming conventions are badly applied) SCOTCH significantly outperforms NC, LCBA, and DFA, while on ArgoUML SCOTCH overcomes LCBA and DFA and is able to obtain the same performances as NC. It is worth noting that SCOTCH not only obtained the higher accuracy between the experimented tools, but also provided the most stable performances across systems having different characteristics. These results highlight SCOTCH s usefulness as a feature within a software development environ- 123

134 ment such as Eclipse. For a deeper description of the empirical evaluation of the SCOTCH traceability recovery engine see [11]. To the best of our knowledge SCOTCH is the first traceability recovery tool that relies on slicing and conceptual coupling to recover the traceability links between unit tests and application code. Indeed, SCOTCH helps developers detect traceability links during software development. Moreover, SCOTCH helps reduce consistency errors that are possible if tested classes are modified without corresponding modification to their unit tests. It does this with a pop-up message alerting the developer of the potential problem. Future work will be devoted to additional experiments and assessment of the traceability recovery tool. A second future direction regards the granularity of the traceability links recovered and their semantics. In particular, we plan to adapt SCOTCH in order to recover the traceability links between unit tests and the methods under test. NC DFA LCBA Slicing + CC (0.95) Agileplanner ArgoUML exvantage F-Measure Fig. 9. Accuracy of the experimented traceability recovery methods. References 1. IEEE Standard Glossary of Software Engineering Terminology. 2. Beck, K., Gamma, E.: Test infected: Programmers love writing tests. Java Report, vol. 3, no. 7, pp , (1998) 124

135 3. Van Deursen, A., Moonen, L.: The video store revisited thoughts on refactoring and testing. In Proceedings of International Conference extreme Programming and Flexible Processes in Software Engineering (XP), pp Sardinia, Italy (2002) 4. Hayes, J., Dekhtyar, A., Janzen, D.: Towards traceable test driven development. In Proceedings of the ICSE Workshop on Traceability in Emerging Forms of Software Engineering. pp IEEE Computer Society, Washington, USA (2009) 5. Hamill, P.: Unit Test Frameworks. OReilly (2004) 6. Bruntink, M., v. Deursen, A.: Predicting class testability using object-oriented metrics. In: 4th IEEE International Workshop Source Code Analysis and Manipulation, pp IEEE Computer Society, Montreal (2004) 7. Bouillon, P., Krinke, J., Meyer, N., Steimann, F.: Ezunit: A framework for associating failed unit tests with potential programming errors. In: 8th International Conference on Agile Processes in Software Engineering and extreme Programming, pp Como (2007) 8. Ryder, B.: Constructing the call graph of a program. IEEE Transactions on Software Engineering, vol. 5, no. 3, , (1979) 9. Deerwester, S., Dumais, S. T., Furnas, G. W., Landauer, T. K., Harshman, R.: Indexing by latent semantic analysis. Journal of the American Society for Information Science, vol. 41, no. 6, pp , (1990) 10. Qusef, A., Oliveto, R., DeLucia, A.: Recovering traceability links between unit tests and classes under test: An improved method. In 26th IEEE International Conference on Software Maintenance, pp IEEE Press, Timisoara (2010) 11. Qusef, A., Bavota, G., Oliveto, R., De Lucia, A., Binkley, D.: SCOTCH: Improving Test-to-Code Traceability using Slicing and Conceptual Coupling. In: 27th IEEE International Conference on Software Maintenance, IEEE Press. To appear, Williamsburg (2011) 12. Korel, B., Laski, J.: Dynamic program slicing. Inf. Process. Lett., vol. 29, pp , (1988) 13. Korel, B., Laski, J.: Dynamic slicing of computer programs. Journal of Systems and Software, vol. 13, no. 3, pp , (1990) 14. De Lucia, A.: Program slicing: Methods and applications. In: 1st IEEE workshop on Source Code Analysis and Manipulation, pp IEEE Computer Society, Florence (2001) 15. Van Deursen, A., Moonen, L., Bergh, A., Kok, G.: Refactoring test code. Technical Report, CWI, Amsterdam (2001) 16. Poshyvanyk, D., Marcus, A., Ferenc, R., Gyimothy, T.: Using information retrieval based coupling measures for impact analysis. Empirical Software Engineering, vol. 14, no. 1, pp. 5 32, (2009) 17. Antoniol, G., Canfora, G., Casazza, G., De Lucia, A., Merlo, E.: Recovering traceability links between code and documentation. IEEE Transactions on Software Engineering, vol. 28, no. 10, pp , (2002) 18. Rompaey, B. V., Demeyer, S.: Establishing traceability links between unit test cases and units under test. In: 13th European Conference on Software Maintenance and Reengineering, pp Kaiserslautern (2009) 19. Sneed, H.: Reverse engineering of test cases for selective regression testing. In: 8th Working Conference on Software Maintenance and Reengineering, pp. 69. IEEE Computer Society, Washington (2004) 20. Baeza-Yates, R., Ribeiro-Neto, B.: Modern Information Retrieval. Addison-Wesley (1999) 125

136 An Eclipse plug-in for specifying security policies in modern information systems Simone Mutti, Mario Arrigoni Neri, Stefano Paraboschi Dipartimento di Ingegneria dell Informazione e Metodi Matematici Universitá degli Studi di Bergamo, Dalmine BG, Italy {simone.mutti,mario.arrigonineri,parabosc}@unibg.it Abstract. In this paper we want to show how the Eclipse platform can offer very interesting support and be an adequate infrastructure in the realization of a software environment for the design and development of security policies. The efficient and effective design of security policies for modern information systems is a crucial open problem, important and at the same time quite difficult. The lifecycle of a company-wide security system is complex. Its correct management requires conceptual depth, with the ability to describe the security configuration at different abstraction levels, from a representation that is near to the way security requirements arise from business applications, to the concrete configuration of the security components that characterizes the implementation of the system. Also, information systems present a large variety of securityenabled tools and devices, each one tailored to a specific task and operating on a specific representation of a system subset, and a correct security management environment has to be able to cover as many of them as possible. Ideally, an integrated security management environment should provide interoperability among all the security tools and assist the user in such a complex job. In such a scenario, Eclipse is able, with itsopen source technology and its flexible architecture, to support the realization of such systems, facilitating the integration among the separate models required to describe the security configuration of a heterogeneous system. For instance, formal ontologies can be easily integrated and they can be used for the definition of the involved models, with clear benefits in terms of automatization of model definition and control. 1 Introduction As applications become more sophisticated, extensive and operate in an increasingly open and integrated environment, an urgent need grows of flexible and automated tools for the management of information security aspects. The proper management of security requirements is an important open problem in this environment. The work in this paper has been supported by the PoSecCo project (project no ), co-funded by the European Community under the Information and Communication Technologies (ICT) theme of the 7th Framework Programme for R&D (FP7). 126

137 Among the many topics investigated by access control research in recent years, two themes are particularly relevant to this scenario. The first is the investigation on new access control models able to meet the policy needs of real world application domains. This work has led to several successful and now well established models, such as the RBAC96 model [1], the NIST Standard RBAC model [2] and the RT model [3]. In a parallel line of investigation, researchers have developed a variety of policy languages for access control, in most cases with a direct integration with the languages and models of the modern Web scenario. These include industry standards such as XACML [4], but also academic efforts ranging from more practical implemented languages such as Ponder [5] to theoretical languages like the one proposed by Jajodia et al. in[6]andfinallyto Semantic Web based languages such as Rei [7] and KAoS [8]. Policy languages based on Semantic Web technologies allow policies to be described over heterogeneous domain data and promote a common understanding among participants, who might not use the same information model. This paper is motivated by the consideration that these two parallel efforts - access control models and Webconscious policy languages - need to develop a synergy in order to enable the development of security infrastructures with verifiable security properties for emerging open and dynamic environments. An abstract policy language without ties to a concrete model gives the designer considerable freedom, but it may also offer limited guidance and insufficient precision in the description. Conversely, an excessively concrete model may not have the flexibility needed to correctly express the policy of a given system or may force the omission of important aspects. For instance the NIST Standard RBAC model only supports the definition of the specific constraints of static and dynamic separation of duties. No attention is paid to the representation of other properties of the security policy. A policy language built on the basis of the NIST Standard RBAC model can be successfully applied to the management of security policies of real systems only if it supports the specification of a large variety of additional details that are not captured directly in the model. Our goal is to create an environment for the design and management of security policies that follows the approach proposed by the European project PoSecCo ( PoSecCo plans to represent the security policies at three distinct levels of abstracion: Business, IT and Landscape. The design of the security policy should start with the definition ofthesecurityrequirements at the Business level and then proceed to the IT level and finally the Landscape level, maintaining a traceable link between the elements at the different levels. These connections are crucial to support policy inspection and maintenance activities. We have a specific interest in the IT level description of security policies. Our first goal is to contribute to the definition of the IT level policy model, providing a description that is based on the representation of the common features of an Information Technology (IT) infrastructure. To achieve our goal we need models that are able to represent extended system features, to provide a precise description of the expected system behavior. Another goal is to increase knowledge on the security configuration in the model relying on 127

138 Semantic Web technology, and specifically on an enrichment of themodelwith the use of OWL (Ontology Web Language) [9]. The use of OWL within the definition of the model will bring significant benefits, especially in terms of partial automatization of the process of model verification and refinement. In fact, thanks to the use of OWL, model implementation can be done in part automatically. To introduce these automated processes, the model relies on ontological argumentation (reasoning), a powerful tool to derive new information and make an extensive verification of the model correctness. This paper presents the main design principles that have been used in the construction of an Eclipse plug-in that implements the aspects seen before. The motivation underlying the implementation of the plug-in is that Eclipse is the most used open source development framework, offering a high degree of flexibility and supporting the extention of its functionality through the implementation of plug-ins. Moreover, Eclipse can provide a common repository model as well a common plugin interface to facilitate the integration between this and other plugins, which will be used to manage business level and landscape level descriptions of the security policy. Finally, the Eclipse platform encourages the reuse of the functions of other plug-ins and modules of the Eclipse framework, speeding up and improving the quality of the development process. The paper is organized as follows. Section 2 presents the main features of the IT-level model used for the description of security policies. Section 3 briefly illustrates the role of Semantic Web technology and OWL. Section 4 discusses the design principles that have been followed in the design of the Eclipsepluginfor PoSecCo. Section 5 shows the interface the plugin offers to the security designer. Finally, Section 6 draws some concluding remarks. 2 Access control IT-level metamodel The metamodel that is being used in PoSecCo to describe security policies at IT-level consists of four related conceptual blocks, describing the main aspects that characterize access control and authentication services. The profiling metamodel is used to describe the organization by grouping users into groups and allowing them to activate roles. The authorization metamodel describes a taxonomy of authorizations and some basic properties of authorizations themselves. The privilege metamodel is used to describe the detailed structure of privileges and works as a fundamental link to the software and hardware infrastructure, involving the actual landscape entities as target. The network metamodel is used to describe the network layer. The profiling metamodel is composed of many classes. The Principal class represents generic user profiles or groups and is specialized intotwosubclasses: Identity and Role.Identitiesarestatichierarchicaluserclassifications.In general, aprincipalcancorrespondtoanyuserortoanyspecificorganization unit that 128

139 corresponds to a group of identities. GroupIdentity is a specialization of the Identity concept and denotes (directly or indirectly) a set of lower level identities. SingleIdentity corresponds to an Identity that represents a single user in the system. Role is the core concept of the submodel. The concept of role offers a variety of interpretations, adaptable to the specific features of the access control models implemented in the landscape. The authorization metamodel contains several classes. The PolicySet class represents the aggregation of policies. The Policy class consists of a set of authorizations. It is associated with a target that specifies restrictions valid over all the authorizations in the policy. The Target class permits to specify for each policy a set of restrictions that have to be applied to all the authorizations in the policy. The core concept of this part is the Authorization class. There are two different types of authorizations: Role Authorization and System Authorization. ARoleAuthorizationrepresentstheauthorizationtoactivate a role, that is, to enable all the privileges granted to such a role. System authorizations correspond to the classical authorizations/rules of most access control models. The main classes that appear in the Privilege metamodel are: Privilege, Action and Resource. The Privilege class represents the right of performing some action and its subclass ResourcePrivilege represents privileges that are associated with some specific resource. Another class is Action, which describes a generic business or technical action. The structure of the action is strictly related to the characteristics of the underlying access control system. In fact, the Action class is related with the System class that represents the system where the action can be performed. The Action is also related with the SystemAction class that represents the specific action of a system. Another classinthe privilege metamodel is Resource, whichrapresentstheentityonwhichaprivilege can be assigned. There is a large variety of resources to manageinthe PoSecCo environment. The main distinction we can introduce in resources is between Static and Dynamic resources. A Static resource is an information resource, like a file or a folder in a file system. The static resource entity has a specialization: ProtectedDataObject represents an abstraction of a protected resource. The ProtectedDataObject has two specializations: EncryptedDataObject and SignedDataObject. EncryptedDataObject represents an encrypted resource. SignedDataObject represents a resource whose content has been signed with a digital signature. A Dynamic resource corresponds to a target of an authorization that is responsible for the execution of a specific function. The dynamic resource entity has two specializations, Service and ServiceInterface. A service represents a complete set of service invocations, responsible for the execution of a specific application. A Service must expose at least one ServiceInterface. A ServiceInterface is an atomic service invocation provided by a service. The network metamodel is composed by: NetworkElement, an abstract class that describes elements in a computer network. NetworkElement has two specializations: Node and NetworkConnection. ANodeisanelementofthenetwork that contains a lot of resources. NetworkConnection is a data transport entity 129

140 that transports data from one Node to another Node at the same layer. Node has a specialization, Link. ALinkisaconnectionbetweennodes. 3 Semantic Web and OWL The term Semantic Web refers to both a vision and a set of technologies. The vision is articulated, in particular by the World Wide Web Consortium (W3C), as an extension to the existing web in which knowledge and data could be published in a form easy for computers to understand and reason with. Doing so would support more sophisticated software systems that share knowledge, information and data on the Web just as people do by publishing text and multimedia. Under the stewardship of the W3C, a set of languages, protocols and technologies have been developed to partially realize this vision, to enable exploration and experimentation and to support the evolution of the concepts andtechnology. The current set of W3C standards are based on RDF [10], a language that provides a basic capability of specifying graphs with a simple interpretation as a semantic network and serializing them in XML and several other popular Web systems (e.g., JSON). Since it is a graph-based representation, RDF data are often reduced to a set of triples where each represents an edge inthegraphor, alternatively, a binary predicate. The Web Ontology Language (OWL) [9] is a family of knowledge representation languages based on Description Logic (DL) [11] with a representation in RDF. OWL supports the specification and use of ontologies that consist of terms representing individuals, classes of individuals, properties, and axioms that assert constraints over them. The use of OWL to define policies has several very important advantages that become critical in distributed environments involving coordination across multiple organizations. First, most policy languages define constraints over classes of targets, objects, actions and other constraints (e.g., location). A substantial part of the development of a policy is often devoted to the precise specification of these classes. This is especially important if the policy is shared between multiple organizations that must adhere to or enforce the policy even though they have their own native schemas or data models for the domain in question. The second advantage is that OWL s grounding in logic facilitates the translation of policies expressed in OWL to other formalisms, either for analysis or for execution. 4 Eclipse and PoSecCo Eclipse ( canbeconsideredasatechnology,adevelopment platform, and a family of tools. From an infrastructural point of view, Eclipse is a collection of both plug-ins and access points for plug-ins.totake advantage of modern development techniques and to enhance PEPP (PoSecCo Eclipse Policy Plug-in) extensibility, we chose the Eclipse frameworkasourdevelopment platform and decided to implement the proposed metamodel as an Eclipse plug-in. 130

141 4.1 Integration between Eclipse and PoSecCo In Figure 1 we can see how the Eclipse architecture allows us to haveavertical integration of the various layers that make up the architecture of PoSecCo. Within each block we can find various layers that manage particular aspects of the security policies. These blocks can be easily integrated within Eclipse, in agreement with the philosophy that considers Eclipse as a collection of both plug-ins and access points of plug-ins. Fig. 1. Integration of the different components 4.2 PoSecCo Eclipse Policy Plug-in (PEPP) We introduce here the PEPP (PoSecCo Eclipse Policy Plug-in) component, described in Figure 2. This is the core of the system, responsible for managing the IT level representation of the security policy. 131

142 Fig. 2. Abstract architecture of the plug-in. In particular, this architecture allows us to have two representations of the access control model defined above, a model representation understandable by the user (via form-based interface) and a representation understandable by the machine through formal ontology and reasoning. This allows us to use the power of reasoning because, especially in model checking, these controls can be performed automatically by the machine. XML and XACML The plug-in provides support to the user during data entry. User is guided to describe consistent models due to ontology constraints. The obtained model is stored inside Eclipse project as an XML file that is valid w.r.t. a PEPP specific language. When the data entry is complete the user can export the created model in some task oriented formats, including OWL and XACML. Theplug-inallowsthischoiceaccordingtotheEclipsephilosophy. We want to maintain some flexibility as well as also an high level of integration with other modules that use the XML language or other tools that use XACML format. The use of the OWL format is instead used internally to theplug-infor reaoning related tasks. OWL and OWL API The ontology is implemented within the plug-in through the latest version of the OWL API. OWL API has been designed to meet the needs of people developing OWL based applications, OWL editors and OWL reasoners. It is a high level API that is closely aligned with the OWL 2 specification. It includes first class change support, general purpose reasonerinterfaces, validators for the various OWL profiles, and support for parsing and serializing ontologies in a variety of syntaxes. The API also has a very flexibledesign that allows third parties to provide alternative implementations for all the major components. Reasoning AkeypartofworkingwithOWLontologiesisreasoning.Reasoners are used to check the consistency of ontologies, check to see whether the signa- 132

143 ture of an ontology contains unsatisfiable classes, compute class and property hierarchies, and check to see if axioms are entailed by an ontology. The OWL API has various interfaces to support the interaction with OWL reasoners. AreasonerisakeycomponentforworkingwithOWLontologies.Infact, virtually all querying of an OWL ontology (and its imports closure) should be done using a reasoner. This is because knowledge in an ontology might not be explicit and a reasoner is required to deduce implicit knowledge so that the correct query results are obtained. The OWL API has various interfaces to support interacting with OWL reasoners. In PEPP we use HermiT ( asreasoner.hermitisthefirstpubliclyavailable OWL reasoner based on a hypertableau calculus, which provides more efficient reasoning than most other algorithms. Ontologies that previously required minutes or hours to classify can often by classified in seconds by HermiT. This performance gain allows HermiT to classify a number of ontologies that had previously considered too complex. For more specific controls, such as check of correctness of the policy that are beyond Description Logics expressivity, some specific inference rules must be introduced. SWRL (Semantic Web Rule Language) [12] is a proposal for a Semantic Web rules-language, combining sublanguages of the OWLWebOntology Language (OWL DL and Lite) with those of the Rule Markup Language. Rules are in the form of an implication between an antecedent (body) and consequent (head). The intended meaning is consistent with the classical semantics that characterizes most rule paradigms: whenever the conditions specified in the antecedent hold, then the conditions specified in the consequent must also hold. Thanks to the introduction of these rules, the verification process of the model can be automated. The use of SWRL offers interesting opportunities in the PoSecCo context and is well supported by the reasoners that can be easily integrated in Eclipse. 5 PEPP PEPP fully supports all the phases of the process depicted in Figure 2. The PEPP plugin is composed of several modules: amainwindowtodisplayandeditpolicydescriptionfiles.thepluginassigns adifferenttabpanelinthewindowtoeverytopconceptfromthemetamodel. This set of tabs provides the user with a high level guide through the model, always offering direct access to the main components of the model. The selection of a tab open a form that permits to enter values for each of the properties of the corresponding entity. Instances of each class can be described in a homogeneous way by the same form used for entering its properties. The plug-in has many forms (see Figure 4), in particular there is aformforeachclassofthemodeldescribedinsection2.theseformsallow to maintain a high usability of the plug-in. a navigation tool,that organizes resources in a finer taxonomy according to the specific top level concept selected by the user in the main window. 133

144 The classification proposed to the user is driven by the ontology itself. This makes the tool quite flexible and automatically adaptable to changes in the ontology. The tool can be applied to any fragment of the metamodel. asetoftaskbuttons,publishedintheeclipsemaintoolbar,that offer direct access to functions like the creation of the OWL ontology starting from an instance of the security policy or the activation of the reasoning-based checking. As a first task, the plug-in requires to create an empty project. Once the project has been created, the user must create the file that will contain the policies. This is possible in a way consistent with the practices of Eclipse plugins, by right-clicking the project within the Package Explorer view and choosing new file in the category PoSecCo within the menu new(see Figure 3). Fig. 3. The window used for the generation of a project. At this point the plug-in will provide a window for choosing the name of the new file and the workspace where the file will be stored. When the fileiscreated, the user can insert the data about the policy that he wants to create. Then, the user will typically insert the elements of the model using the formsassociated with the entities in the tabs. 134

145 Fig. 4. Appearance of the plug-in. To help the user during the creation and editing of data, a viewhasbeen introduced that allows the user to navigate between the entities entered above (see Figure 5). Fig. 5. The tree view of the instance of the model. When the policy creation phase is complete, the user can use the plug-in not only to export the data into an XML file, but it can also create the ontology, expressed in an OWL file, according to the pattern seen in Section 2. This feature of the plug-in allows the user to obtain a representation of the security policy that can be processed by a standard OWL reasoner. In Figure 6 we canseeboth aspects described above. 135

146 Fig. 6. The buttons supporting the generation of the OWL model and the invocation of the reasoner. The integration of reasoning was relatively direct, thanks to the flexible architecture that characterizes Eclipse. We created a view that shows the messages returned by HermiT, to provide feedback to the user and inform himofpossible conflicts within the model. Stricter integrations that offer agreaterlevelofinteraction and control on the execution of the reasoner are planned for the next versions of the plugin. We are confindent that the Eclipse architecture will allow us to manage this further integration, something that would be harder if using closed-source or stricter frameworks. 6 Conclusions and Future Work In this paper, we briefly described the structure of the PoSecCo plugin for Eclipse PEPP. We described the relationship between the PoSecCo security model and OWL and showed that the plugin can produce a representation of the PoSecCo model in OWL. We believe that a tool like the one presented in this paper can offer great support in the development of security policies and configurations. The use of the tool offers the designer the possibility to efficiently describe large systems and rely on well understood and verifiable security properties for open, dynamic environments, which require coordination across multiple organizations and integration of different data formats. The support provided by the Eclipse framework in the construction of such a system is essential, because Eclipse provides a powerful environment for tool integration and already makes available alargenumberoffunctionsthatarecommonlyrequiredintheconstruction of such systems. In particular, it can integrate and manage plug-ins developed by other project partners and provide a unique environment that can manage all phases at all layers. Future work will be devoted to extend the Eclipseplug-in with richer functionality and modules of the Eclipse framework, further improving and speeding up the development process. In particular, we will create a module for exporting policies in XACML format and expand the checks carried out by the SWRL rules. We already know that the Eclipse framework has been the foundation for the construction of design environments for a variety of programming languages and methodologies. The work described in this paper testifies that Eclipse can also have an important role in the construction of modern environments for the management of security policies in large and integrated information systems. 136

147 References 1. Sandhu, R.S., Coyne, E.J., Feinstein, H.L., Youman, C.E.: Role-Based Access Control Models. IEEE Computer 29 (1996) Ferraiolo, D.F., Sandhu, R., Gavrila, S., Kuhn, D.R., Chandramouli, R.: Proposed NIST standard for role-based access control. ACM Trans. Inf. Syst. Secur. 4 (2001) Li, N., Mitchell, J.C., Winsborough, W.H.: Design of a Role-Based Trust- Management Framework. In: Proceedings of the 2002 IEEE Symposium on Security and Privacy, Washington, DC, USA, IEEE Computer Society (2002) Anderson, A.: extensible Access Control Markup Language (XACML). Identity (2006) 5. Damianou, N., Dulay, N., Lupu, E., Sloman, M.: The Ponder Policy Specification Language. In: Proceedings of the International Workshop on Policies for Distributed Systems and Networks. POLICY 01, London, UK, Springer-Verlag (2001) Jajodia, S., Samarati, P., Subrahmanian, V.S.: A Logical Language for Expressing Authorizations. In: Proceedings of the 1997 IEEE Symposium on Securityand Privacy. SP 97, Washington, DC, USA, IEEE Computer Society (1997) Kagal, L., Finin, T., Joshi, A.: A Policy Language for a Pervasive Computing Environment. In: Proceedings of the 4th IEEE International Workshop on Policies for Distributed Systems and Networks. POLICY 03, Washington, DC, USA, IEEE Computer Society (2003) Tonti, G., Bradshaw, J.M., Jeffers, R., Montanari, R., Suri, N., Uszok, A.: Semantic Web languages for policy representation and reasoning: A comparison of KAoS. In Fensel, D., Sycara, K.P., Mylopoulos, J., eds.: International Semantic Web Conference, Springer (2003) Bechhofer, S., van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D.L., Patel- Schneider, P.F., Stein, L.A.: OWL Web Ontology Language Reference. Technical report, W3C, (2004) 10. Lassila, O., Swick, R.R.: Resource Description Framework (RDF). Model and Syntax Specification. (1999) 11. Baader, F., Calvanese, D., McGuinness, D.L., Nardi, D., Patel-Schneider, P.F., eds.: The Description Logic Handbook: Theory, Implementation, and Applications. In Baader, F., Calvanese, D., McGuinness, D.L., Nardi, D., Patel-Schneider, P.F., eds.: Description Logic Handbook, Cambridge University Press (2003) 12. Horrocks, I., Patel-Schneider, P.F., Boley, H., Tabet, S., Grosof, B., Dean, M.: SWRL: A Semantic Web Rule Language Combining OWL and RuleML. W3C member submission, World Wide Web Consortium, (2004) 137

148

149 139

150 140

151 141

152 142

153 143

154 144

155 145

156 146

157 147

158 148

159 149

160 Persistence of the Memory 1 : an introduction to the asset and intellectual capital management Application into the ETC project Ferdinando Gorga IBM Italia S.p.A. [email protected] Paolo Maresca Università di Napoli Federico II [email protected] Abstract. What is the relationship between Information Technology and the knowledge that it generates during the systems design? How is this knowledge encoded and passed? The skills acquired by mankind in the art of writing for the past seven millennia of history, are or are not used for encoding the software project documentation? If the answers are negative, what are the implications of this situation? In this article we examine these questions and present a viable solution using the tool IBM Rational Asset Manager for the hoarding of intellectual capital developed in the projects. This tool is also adopted in the ETC project to collect, manage and distribute all produced material in the experiments, in order to make it persistent and usable to all students and to teach them the right approach. Students seem to prefer the use and reuse of arrangements because they directly reuse pieces of knowledge;; this is also what will be discussed in this paper. Keywords: E-learning, IBM Jazz, Intellectual Capital, Asset Management. 1. Introduction The lack or absence of documentation of software has always been one of the biggest problems for companies and one of the activities difficult to teach to the students. Writing documentation is always perceived as a waste of time, unnecessary costs, pushed and pressured by deadlines and the low investment made available for the task. The real problem is that the documentation is not perceived as "knowledge hibernated" in the project and therefore it is considered unnecessary. If we look, for example, what is the dominant behavior when writing code is that the code is written first and then you add comments. This is a bad practice, because in this way, the 1 La persistencia de la memoria is a famous painting of Salvator Dalì, MoMA New York. 150

161 comments are useless because they do not provide any additional knowledge of the code which is actually very useful for those who must read and maintain the systems. It's clear that to move in this direction must perceive the importance of documentation of the code not just as an illustration of what has been done but in terms of reuse of its content. In short, the code must be perceived as an sset. An asset is a collection of artifacts that provides a reusable solution to a specific problem. In this context, then it turns out that there are assets for everything: to document the software for the design, to document best practices and to manage a plan for measuring etc. If we reason with reusability in mind, then change the focus of many of the activities in the process of software development are being developed by the actors. We want to illustrate in this article how shifting the focus on assets, the students adapt themselves to new ways of seeing things, and adapt their approach for reuse. And if we have tools to reuse the assets and then exchanging them, even better. The work is organized as follows: in the next section shows how the reasoning "by asset" is not born right now but finds its roots in cultural history. In next chapters we speak about the intellectual capital and its management, with a definition of asset. In section 6 we will speak of RAM, a tool for Asset Management and chapter 7 will take care of its use in a ETC project called OTRE to represent the intellectual capital of groups of people involved in the project. Finally, in section 8 will discuss the final results and conclusions. 2. A brief look at the far past In this section we will try to illustrate the characteristics and the criticality of information handed down verbally. Let me try to imagine how it must be the culture and its management when there were no books, before seven thousand years ago. The elders or sages instructed young people with stories or anecdotes, verbally passing on their culture enough for everyday life, probably in the context of social and family rituals or by specific request. If we analyze the characteristics of this way of passing on information, practices and culture we find some critical points: a) Synchrony: it communicates in a synchronous mode: the people involved in the verbal exchange of information and culture must be both available simultaneously in the same place. b) Ambiguity: The information transmitted verbally is not encoded and is prone to personal interpretation. c) Inconsistency: the communication of such information is unlikely to be repeated in the same way, so every 'session' of communication is unique. Any replies will contain differences. 151

162 d) Evanescence: This information have a low level of persistence over time: things are forgotten, are remembered in a different way every day, belong only to a person that can disappear, die, forget. e) Fan-out: there is a limit to the number of people to whom you can communicate verbally knowledge. f) Accumulation: because verbally the amount of things you can communicate is a function of the time and the average life of a person has a standard length, once used all the available time is not possible to pass on further knowledge. This means that the generation n +1 is not able to receive information verbally more than the generation n. The maximum amount of transmitted culture remains constant over time. These aspects depict a scenario of little or no codified and rationalized information, where memory and mood of the teacher greatly influences the communication. We suppose that tens thousands of years ago, each new generation of people have been able to take advantage of existing knowledge and precepts in limited quantities and mostly had to start almost from scratch in many cases to learn what is necessary or desired. It was not possible to pass on a wealth of information and culture gradually increased from generation to generation and transmission of knowledge was for 'direct contact' between people. With the invention of writing, and then of the books in their various forms, things have changed radically. Knowledge has become 'visible', has been codified, it suddenly became persistent, repeatable and independent from the people. We could say that has become eternal (or at least its life is linked to that of inanimate objects such as books, usually more longevous than people). Pass on the culture and information through writing has resolved the negative characteristics that we listed above: The synchrony is no more: I write a book and anyone can read it at any time. Ambiguity: It is what the author has decided to keep in the book but it can be demolished or altered by other authors and reviewers in very different times, adding chapters, commentaries and analysis. Inconsistency: solved by reusing and re-read the same book several times. Persistence: the information remains unchanged over time if the book is not burned or eaten by a rat. The life and destiny of the written information is independent in most cases the life and destiny of its author. Fan-out: a book can be read by an arbitrary number of people, as long as it was printed in sufficient copies. 152

163 Incremental Accumulation: it is one of the most beautiful aspects: each generation bequeaths to the future people new books and new knowledge, often built on the study of existing books. Each generation can grow by taking advantage of knowledge accumulated over millennia in the millions of books produced. The generations so now can study pieces of culture coming from the past, from the present and from various parts of the world... this is the context in which we were educated and we continue to live. This we love it! But what is the connection between how the writing has changed the way of passing on knowledge and the world of the applications and computers? 3. Information Technology and knowledge management What is the knowledge or information we are speaking about, referring to the computer science? A company or an institution of public administration has IT systems quite large. A plausible example is the following: Function Point in operations: > 200,000 More than 600 maintenance requests for year More than 20 Terabyte in on-line databases Average age of systems: >40 years or the same age of the company Employee headcount: >10,000 Millions lines of code. These numbers are included and implemented through thousands of applications, often built ad hoc. Are we sure that in addition to applications in operation, the companies always have the documentation that describes them? What would happen if the 'books' disappear, the books in which are written the motivations, the projects and the source code of part of these 200,000 function points when the company needs to make a change? It would be a disaster, you should hope that the employee or the consultant who had done 10 years before the application to change, remember the details to be able to make the change or explain the missed details to someone. And if it turns out that for a good portion of these 200,000 function points the documentation has not disappeared, but has never been produced? When employees retire or change jobs, the company loses the knowledge of the 153

164 If there is no written information then we are using the verbal mode of transmission of knowledge, hoping in people's memory (in addition to their good health)! To manage the transfer of skills, to the employee who resigned or older is asked to assist the new employee. In this way the transfer of knowledge will be done in the verbal manner characterized by aspects seen at the beginning of this work. The knowledge, in this way, is not the company's heritage, but of the individual. If the person changes the company, resigned or simply forgets, knowledge is no longer available for the company. We are seeing a paradox: computer science that is the science which deals with information and knowledge in some cases has allowed to return to the way verbal/mnemonic/linked to the person, to describe the knowledge of the systems. The effort to write the software has overshadowed the daily use of writing as a means of sharing information and persistence and was returned at the time when the writing did not exist, before the time of the Sumerians, with the inevitable implications. Fortunately, this scenario is not the rule, however the average incidence of this sad habit is still too common, and this involution is still unacceptable. This state of affairs also makes sure that the corporate culture in terms of knowledge of the managed systems does not increase over time, being located in people's minds. This is a very limiting factor but the large amount of experience of a company, if they hoarded and readily available, could be a competitive advantage One can easily imagine what the consequences in an business organization that depends on external changes and manages the knowledge in a non-formalized way: higher spending, more failures, lower reactivity, inability to innovate, no economies of scale, missed ownership of intellectual capital. The last term is the key to understanding this article. 4. The intellectual capital Any product of human intellect is the result of a mental effort that has a purpose. As such it can be commissioned, paid for and used. It is a form of wealth, a real capital and as such should be treated. We put our savings in the bank, even if they are small, but not always put in the bank the investment of millions of dollars spent on our system. In the case of the systems, the coins that make up this heritage are records of various types, a list (partial) of which may be this: Analysis documents Use cases Acceptance tests documents 154

165 Source code Compilation and build logs Report of deploy List of solved defects The contracts with external consultants and suppliers Architectural and design diagrams Architectural choices Traceability with the business vision Traceability with fiscal year budget Test case list Requirements list Project meetings reports Time and economics plannings Strength and weakness of the system List of used services, list of produced services List of components Usage requirements Mandatory hardware resources Costraints (standard, privacy etc.) List of used As we know, an IT system is an entity of great complexity and its description covers much larger areas than just source code. The ideal condition is that there are formalizations through which to represent all the information that makes up a system and its operation. The list seen, could be so organically harvested document to document, described accurately and carefully hoarded. What we need then is a kind of 'bank' in which to deposit this entire heritage and preserve the knowledge in the same way we do with the books. These documents will define as Intellectual Assets. IBM for several years has addressed these needs by implementing a good system of asset management: the Rational Asset Manager. 5. What an Asset is An Asset, in terms in which we describe in this paper, is a resource (document type, text, graphics) of any value to a project, a system or company. Any file (or collection of files) containing information can be a significant and valuable asset for a company. 155

166 Currently there is a standard formalism, issued by the Object Management Group (OMG), which describes how the assets will be made, so that they can be managed and reused. This formalism is called RAS: Reusable Asset Specification and you can find the specifications on the OMG site. A file or group of files to be used as an asset must be described accurately and it must be associated with metadata that allow the classification and future retrieval. To make an asset reusable, at least these conditions must be met: 1) We have to own the asset 2) We have to know where it is 3) We have to know who is responsible for it 4) We have to know the usage details and what is its purpose. The company that carefully preserves all the documentation of systems, although it is protected from the risks outlined earlier, does not yet has all the advantages that could provide faster availability of information. We want a tool that enables both the hoarding that awareness of corporate assets. Rational Asset Manager is the right tool in order to manage assets. 6. IBM Rational Asset Manager Rational Asset Manager (RAM below, for short) is an application that runs on one or more servers, using a repository based on a database and that is used through a web browser. The main features of this product are the following: Allows to describe the types of assets;; Allows storage of assets;; Allows the submission of assets through a simple workflow (so assets can be in various states, as proposed or accepted);; Allows connection of assets and set dependencies;; Check that the asset is formally well-made, for example, which is connected with other assets as required;; Facilitates tracking of assets through informal queries, and metadata tags;; Allows to subscribe to the assets on which you want to be notified about updates;; Allows the ranking of the assets that we downloaded and reused;; Allows versioning of assets for continuous improvement. 156

167 CVS ClearCase RTC Subversion Analyst WebSphe re Business Modeler Developer Rational Asset Analyzer Business Manager Portfolio Management Insight Reporting All Roles Doors, Caliber Requisite Pro Software Development Platform Architect RSA RSD RSM Harvest assets Measure performance Link Requirements with assets Developer Tester RAD WebSphere Integration Developer Eclipse RFT RPT RAM Eclipse Client & Plug-in Create, publish, search & use Cloud RAM assets Services RAM Asset Management Server Metadata DB2 Oracle Project Manager Rational Method Composer ewas Storage Filesystem Business Manager All Roles RAM Web Client Create. modify, use & review cloud assets RAM administration Fig. 1- The Rational Asset Manager landscape Publish, search,, & impact analysis Report Policies Submit and query change requests LDAP Build SQL execution Server Asset Management Platform Includes RUP for Asset Based Development A N T Developer WebSph. Serv Reg & Rep. Deployment Manager Tivoli CCMDB Policy Manager Weblayers All Roles ClearQuest RTC Build Mgr BuildForge After some time of use, the RAM user will be helped to consolidate the company's intellectual capital, having downloaded, tried, submitted, validated, choosed assets and actively participated in improving this body of knowledge. This becomes the only viable way to ensure that the experience gained through years of work is not just the preserve of people who have transited in companies but of the companies themselves. We have the same effects that we mentioned talking about the invention of writing: to make knowledge persistent and unrelated to the memory of the people and ensure that this knowledge is incremental. A more extensive use of RAM could be the repository for enabling Definitive Media Library (DML, cfr. ITILv3). Implement a DML with RAM by using even further automation tools to guarantee a perfect alignment is a strategic choice for companies that have many applications in operation. This solution allows you to keep constantly aligned worlds of development and operation, reducing the time for problem determination when problems occur in applications in operation. Further advantages conveyed by the use of these solutions are that the information of the projects becomes objects of a knowledge engineering process. With the availability of these data, it is able to better understand the potential and limits of the resources and is able to improve forecasts of expenditure in many cases (consider, for example, having to maintain a certain service: If you have 157

168 historical data of the effort for similar interventions can be used to easily predict what is the time and effort to plan). Universities are the contexts in which it creates and conveys more culture. It is thus an ideal environment in which put asset management solutions. With them, students can benefit from incremental enrichment due to conservation and stratification of the projects generated by other students and other universities and their availability improves students' performance. For this reason we think that Rational Asset Manager is a strategic tool that is already bearing fruit in the implementation of a teaching model different than the traditional, shifting the student effort from finding information to their revision and learning. 7. The OTRE asset management In a few words, the OTRE project and the related activity can be described as the experiment of realizing a collaborative learning project, built on the Eclipse IDE and tools. During the development of sub-tasks, users are recommended to use collaboration tools, improving the production of artifacts. The whole project is composed by a variety of sub-tasks;; some of them are not related, while others are strictly dependent. Even, one task may be propaedeutic to another one. Since the project has a seamless integration with the educational activity carried on by (academic) members of the Italian Eclipse community, the results will be collected, published, shared and discussed in the annual conference and this has to be considered a part of the educational task. In fact, during the workshop, the teams that have collaborated remotely will have, finally, the opportunity of meeting themselves as well as of comparing their work and results with the ones achieved by the other teams involved in the same project. -to-peer conference in the students will have completed a group of tasks whose outcome was the realization of a working plug-in for the Eclipse IDE, which will also have to be interoperable with the ones developed by the other teams and, possibly, made available world wide, in the Eclipse Marketplace [12,13]. We also point out that the OTRE project is much more then an educational activity, since it originates in the framework of an innovative academic project sponsored by the Italian branch of IBM, IBM-Italia. Such program is called [10]. At the moment of writing, the number of students signed-up within the platform is 528. They all (and maybe more) will keep on working along the entire second semester of the on-going academic year. Their main activity was to produce artifacts, assets. The process of asset management is simple and effective. Assets are created by the community. A community is made up of a group of users that share a goal. In a community assets can be of different types: categories, reports and review processes. OTRE in this case [9,10,11] is a community of communities being made up of subprojects and other communities (such as eclipse, etc.). So asset management of a 158

169 community is left to the administrators of the community that coincide with the role of team leader of the sub-projects. Fig. 2 shows a group of communities. In RAM a community is the highest level of organization for users and asset. Fig. 2 RAM communities Community administrators assign roles and permissions to users and user groups. So each team leader is responsible for assigning roles and authorization for his team and each member can belong to different communities. For example, see fig. 1, a student may belong to (i) the OTRE community, (ii) to the programming lab, (iii) to the computer engineering course. Each community has a way to organize itself. The organization takes the form of a configuration section in which the group of users decides to classify assets into categories and build assets that have a life cycle (for instance examination program on an annual basis). A community also has available a statistical and control section with which you can check the number of times a particular asset has been downloaded, modified and voted. It can also produce, in the configuration section, reports that highlight how the asset was used and where it was downloaded from other communities. An asset may also be accessed via phone, IPAD or other tools. All OTRE assets are also accessible via mobile phone. Of course, every community has a forum through which discusses asset. The forum can be public or private. The forums are very important because the Asset contain information about their operation, use and connection with other assets, then the discussion between other communities may be useful in order to allow the easy reuse of an asset in order to solve different problems with each other (as example an requirements specification asset that can be used to build an asset for the definition of a test case or that should serve to build the flow of events of a use case). Once submitted and approved the asset can be searched and reused as shown in Fig

170 Fig. 3 Asset search The process of building assets is simple: (i) community users build assets, (ii) team leaders (administrators of the community) validate them (iii) project manager consolidates them. At the end of this process assets are available in the repository and can flow into the knowledge network. The assets can be built either using the web interface or through RAM Eclipse plug-in. The OTRE organizations accumulate artifacts while developing their projects, including: software artifacts such as requirements, code, and documentation, skill, ability, and so on. The idea is to collect, store and share assets developed within the OTRE Project. An asset is a collection of artifacts that provides a reusable solution to a specific problem. We observed that using assets foster reusing, thus reducing time, effort and risk of software development. Students tend to share a certified asset in order to solve problems. Moreover, an asset is associated with a specific set of asset's packaging. As an example of asset we can consider: i) test case, ii) business requirement, iii) functional requirement, and iv) risk management plan. For the management activity to be carried-on with a professional flavor, the Eclipse platform hosting the OTRE project has been enhanced with the Rational Asset Manager (RAM), provided by IBM. More in details, the Rational Asset Manager can be described as a collaborative, development-time asset management repository, enabling teams to identify and manage the design, development, and utilization of software and other reusable, business-related assets. The RAM has tools that allow users to search, organize, and download assets. Other features enable communication among users, provide governance, and obtain statistics. In Rational Asset Manager, asset metadata conforms to the Reusable Asset Specification (RAS), a standard for organizing software artifacts into reusable assets. Rational Asset Manager has two client types, an Eclipse client and a Web client. The Eclipse client enables software practitioners to search, browse, download, and update 160

171 assets within the same integrated development environment as their other software development tools. The Eclipse client functionalities are the following: Submit and classify assets Search, download, and rate assets Use assets Integrate with either CVS or ClearCase SCM adapter plug-ins Fig. 3 - The OTRE asset manager Eclipse client Fig. 3 shows the Eclipse asset manager client platform adopted in the OTRE project. The upper side shows risk management software development plan followed by developing teams (e.g., Universities of Naples and Genoa here) and produced by a student team at Milano Bicocca. Other assets are available for use (see asset windows in the lower side of Fig. 3) and students can rate each one. rcing team intelligence, maximizing value from non-software assets. In fact, knowledge sharing capture best practices, proven business processes and associated artifacts. 8. Conclusions and future development In this paper, asset managing into university domain has been presented. The adopted solution is the Rational Asset Manager, part of the Jazz software ecosystem. We observed for one year a student community working around a project OTRE that 161

172 has been composed of 12 subprojects. Skills and abilities are contained in specific assets, duly described, and accessible over the network to other developers, participating to the Eclipse open community at large. A general framework for the development of team-working skills has been presented, based on the Eclipse and Jazz framework and tools. Such a test-bed can be considered as a learning tool itself and it can be re-used in many different applications, even different from the software engineering we have been referring to along the whole paper. As a significant example, consider the Public Institutions and large Organizations. In such organizations, cooperating to reach a common objective can be a critical point to achieve results and meet the milestones. The availability of a framework enabling users to cooperate through advanced software systems can greatly empower such scenarios and interesting perspectives can be considered in many other fields. ACKNOWLEDGMENTS Authors wish to thank IBM for allowing using software from the Academic Initiative. Our thanks to the Eclipse foundation for their support to Eclipse Italian Community. 9. References 1. IBM Jazz web site: 2. A practical guide to SOA governance with RAM n_us&source=sw-app&s_pkg=soagovernancewithramwp 3. IBM RAM webpage: 4. Maximize reuse of your software assets with Rational Asset Manager Demo- from The Rational Edge, Part 1 & 2: etswram.html etswram2.html 5. Manage assets with lifecycle in Rational Asset Manager: 6. Establishing and populating a Definitive Software Library Williamson, Mendel, Larsen, Rader The Rational Edge: /rader/index.html 7. Asset engineering with the RAM rich client Pendergrass, Lane: RAMrichclient/index.html?ca=drs- 8. OMG specification of Reusable Asset Specification: 9. Coccoli, M., Maresca, P., Stanganelli, L.: Enforcing Team Cooperation Using Rational Software Tools into Software Engineering Academic Projects. In: Eclipse- IT 2010, Ed. M. Coccoli, pp , De Ferrari, Genova University Press, Genova (2011) 10. Coccoli, M., Maresca, P., Stanganelli, L.: Enforcing Team Cooperation: an example of Computer Supported Collaborative Learning in Software Engineering. In: Proc. of the 16th International Conference on Distributed Multimedia Systems, International 162

173 Workshop on Distance Education Technologies, DMS-DET 2010 (Chicago, IL, U.S.A., Oct , 2010), pp (2010) 11. Coccoli, M., Maresca, P., Stanganelli, L.: Computer Supported Collaborative Learning in Software Engineering. In: Proc. of the 16th IEEE Global Engineering Education Conference - Learning Environments and Ecosystems in Engineering Education, IEEE EDUCON 2011 (Amman, Jordan, Apr. 4-6, 2011), pp (2011) 12. IBM, Eclipse, Eclipse Foundation, Cheng, L., Hupfer, S., Ross, S., Patterson, J.: Jazzing up Eclipse with Collaborative Tools. In: Proc. of the 2003 OOPSLA Workshop on Eclipse Technology Exchange, pp , Anaheim, CA (2003) 15. Frost, R.: Jazz and the eclipse way of collaboration. IEEE Software, vol. 24(6), pp (2007) 163

174 Knowledge sharing and cooperation among communities of practices: a possible scenario? Giacomo Franco!, Paolo Maresca 2, Giancarlo Nota", Marialuisa Saviano 4! IBM Italia, Napoli, Italy, [email protected] # Dipartimento di Informatica e Sistemistica University of Naples Federico II, Italy, [email protected] " Dipartimento di Informatica, University of Salerno, Italy, [email protected] 4 Dipartimento di Studi e Ricerche Aziendali, University of Salerno, Italy, [email protected] Abstract. Communities of practices (CoPs) bring high value to product and process innovation in the actual context of economic depression and enable the development of small and medium enterprises. We aim to contribute to the improvement of their value promoting an integrated model based on vsa and DKMF models finalized to promote the knowledge transfer among community members of cooperating CoPs. The model enables to generate new knowledge and to amplify innovative cooperation when the governance effort in planning community development finds an equilibrium with structural characteristic of meta-cop emerging from cooperating CoPs. The model is expected to help with needs of next organization scenario: big projects collecting activities shared between many actors and emerging complex social systems based on networking. Keywords: Community of Practices, Viable System Approach, Distributed Knowledge Management. 1 Introduction The contribution that communities of practices bring to product and process innovation has increased in the last years. On the one hand, they enable the development of small and medium enterprises even in the context of economic depression. On the other hand, they promote the knowledge transfer among community members; this process is able to generate new knowledge and is amplified when innovative cooperation tools are adopted. In this work we will focus our attention on the potential that might arise in terms of innovation capability when a CoP interacts with another CoP. This scenario is expected to be more and more observed in the future especially when we face with problems like large scale projects or better understanding of network of organizations and complex social systems. The distinctive characteristics of a CoP is its mission. Usually the mission is well delimited by the field of knowledge (subject of study, fundamental results, the language shared by community members, research topics, reference models, 164

175 characteristics of a product to develop or to maintain, etc.) and the exchanges of knowledge that involve the members of a CoP are generally confined within the community itself. As the knowledge exchanges with other CoP that have different missions are rare, a CoP tends to behave as a closed system. Nevertheless, there exist circumstances that drive two or more CoP to exchange knowledge. Recently, during the PMKT 2011 workshop held at Torre Canne - Italy, some members of the following CoP: Project Management Institute Southern Italy Chapter (PMI-SIC), Association for Research on Viable Systems (asvsa), Project and Knowledge Management School (PKMS), PKMT community, Eclipse Italia, and Consorzio Daisy Net, took into consideration some questions:! Can a CoP be reinterpreted as an open system that interacts with another community in order to achieve some kind of benefits from the knowledge exchange?! Does a network of open CoP make sense, and how could it be represented and managed?! Can product, process and research innovation be pursued in a network of CoP?! How is it possible to overcome obstacles that restrain the cooperation among communities? Assuming that there is a common interest between two or more communities (research topic, product development and in general a common goal) and that people are willing to cooperate, the quantity of innovative content that might be transferred from one community to another is potentially high but very difficult to exploit. Using a metaphor, for a member, a group or the entire community, the path towards the acquisition of knowledge from another community is climbing a mountain. Only after the clearing of several hurdles it will be possible to see another valley. Seemingly, the paths towards the knowledge maintained by other communities will be not clearly determined neither easily practicable but it is worth to try. We claim that the path toward new knowledge for a community can be better identified and covered by an integrated approach that takes as reference the Viable Systems Approach (vsa) and a model for the management of distributed knowledge: the Distributed Knowledge Management Framework (DKMF). The integrated approach proposed in this paper combines the vsa and DKMF to get a new model able to better identity paths (or to trace new paths) towards knowledge managed by a CoP. The purpose is twofold; first, we wish to explore at what extent the community of Eclipse can contribute through its proper research results, methods and tools to a network of CoPs that share a common goal. Second, an approach that integrates vsa and DKMF is proposed as a reference framework where possible explorations of paths to new knowledge is made easier. vsa provides the rationale to understand if there exist consonance and resonance among participants to a network of CoPs. Consonance will provide us information about the structural compatibility of two or more CoPs. Resonance will provide us information about the effective cooperation result. The DKMF is able to provide the method to create a network of cooperating CoPs as well as its structural representation. Many aspects concerning the technological support necessary to make really useful this approach can be faced using the Eclipse technology. 165

176 The paper is organized as follows: in section 2 some preliminary concepts on the Viable Systems Approach and on the Distributed Knowledge Management Framework are resumed. The reference model that integrates vsa and DKMF is presented in section 3. A case study that reports an experience of cooperation between two CoPs (Eclipse vs Project and Knowledge Management Trends) is shown in section 4. A discussion about the tools from the Eclipse community that can enhance the cooperation capability closes the paper. 2 Preliminary concepts: VSA and DKMF 2.1 The Viable Systems Approach As a methodological approach, VSA is a lens that enables the shift of perspective from a static analysis of structures to a dynamic observation of processes of interaction among different entities. The systems view is particularly useful to the understanding of interaction emerging from a multi-node (network) organization, where the diversity of the nodes generally complicates interaction requiring the development of adequate mechanisms of governance. Saraceno defines a firm structure as the network of inter-relations between the parts of which the system is made up [17], implicitly integrating the descriptive and functional representation of the organizations (structural dimension) and the interaction of forces or tendencies that rule the development of processes, subject to constant evolution in relation to changing context (systemic dimension). The static observation analyzes the structure of the phenomenon focusing on components and relations. The dynamic perspective interprets the systems focusing on the interaction processes between the internal and external components (Fig. 1). T R U C T U R E S 5#0#12, 3"&+3"2#14",!"#$%&' (%)"*+, -./0(12, 3"&+3"2#14", Y S T E M S Fig. 1. A conceptual framework based on the structure-system paradigm Source: [18], pp

177 It is worthwhile to note that the system emerges from the structure either in a governed or in uncontrolled way [6,7]. This means that even in the presence of regulation the way of interacting done by the decision maker of the planned system, interactions and relative properties will emerge [12, 28] (Fig. 2). The structure is characterized by the following conceptual elements:! a physical boundary;! components with a specific function;! a set of stable links among the components. Such specifications, evidently, are not useful in identifying properties emerging from the behavioral dynamics of the structure, in respect to the goals pursued by each interconnected entity and relations from which interaction is activated are relevant.! Source: Fig. 2. The system emerging from the structure. The system perspective emphasizes the following elements [6,7]:! vanishing of boundaries;! absorbing of any entity connected to the system. In the proposed case of a network of CoP organizations, we can distinguish several systems interaction levels:! the interpersonal intra-node community level;! the inter-node communities network level;! the whole network inter-systems level. These levels define a recursive configuration evidently complicating the governance approach. Organizing, at both structural and system levels, such recursive networks underlines the necessity for adequate methodological tools useful for achieving synergies in pursuing a common goal. 167

178 The question is: how well established communities characterized by a defined variety of aims, values, cognitive schemes and behavioral patterns can effectively interact as nodes into a network organization aimed at achieving shared goals? In this respect, VSA proposes a methodological approach to face these governance issues. 2.2 DKMF The Distributed Knowledge Management Framework (DKMF) is an extension of the top-level conceptual framework for KM due to M. Stankosky [22] - fig. 3a. It includes the dimension of social influences as identity, negotiation and trust in order to face the problem of KM in a network of organizations (Distributed Knowledge Network), particularly when the organizations are communities of practice (fig. 3-b). Any CoP that decides to adhere to the network of organization, will initially have a low trustability inside the network. So the main purpose of DKMF is to establish a set of processes to increase the trustability of CoPs and individuals inside the network in order to improve Knowledge Transfer and push to grow the total knowledge managed by the network. In fact, trust will make possible to collaborate and to share data, information and knowledge. Due to the Stankosky framework, in a DKMF a life-cycle of KM has been conceptualized to manage the four pillars for KM (leadership, organization, technology, and learning) together with the dimensions of social influence introduced in [27] fig. 3b in order to reinforce the trust between CoPs belonging to the network. The whole DKMF is an organizational structure made of three fundamental parts: the Local Knowledge Managers (LKM), the Virtual Community Supervisor (VCS) and the Virtual Knowledge Repository. A LKM manages local knowledge i.e., the one owned by an enterprise, that is available to be shared between community participants within a given application domain. The node VCS assumes the leadership for the government of a virtual community starting a new Distributed Knowledge Network and providing the design of a new knowledge network infrastructure, the identity of the knowledge network, and the definition of the four KM pillars at the meta level of DMKF. The virtual knowledge repository is the virtual place where shared knowledge can be stored and allows social aspects to work meaningfully. Learning Technology Leadership Use Organization Leadership Use Transfer Leadership Leadership Leadership Use Transfer Leadership Codification Leadership Transfer Leadership Use Transfer Leadership Codification Leadership Generation Leadership Transfer Codification Use Leadership Leadership Generation Leadership Assurance Codification Leadership Generation Leadership Assurance Generation Leadership Assurance Assurance Assurance Generation Codification KM Life Cycle a) top-level conceptual framework for KM b) the Local Knowledge Manager Framework Use Transfer The four pillar of KM Leadership Learning Technology Organization Identity Trust Negotiation Communication Social influences Fig. 3. The Stankosky top-level conceptual framework for KM and the DKMF Cube 168

179 3 A VSA-DKMF integrated approach 3.1 The methodological contribution of VSA From a VSA perspective, the organization emerging from the interconnection of various CoPs will act effectively as a new system, able to achieve shared goals cocreating value according to a service logic [11], if conditions of consonance and resonance among the nodes (CoPs) result. Consonance expresses the level of sensitivity characterizing variety in perceiving new information. Resonance, in turn, as emerging from the interaction, represents both the process and the result of interaction among consonant entities. As the new organization does not aim at founding a new well established community, but just an informal and temporary connection, it will configure an open network where, on the basis of a project management logic [19], several systems will be organized according to specific goals the communities recognize as worthy to be achieved on a value co-creation basis, exploiting, in particular, network knowledge synergies [29]. This leads us to conceive the idea of an Open Community of Practice (OCoP) where various nodes converge to dynamically create modular project-systems. It is important to note that the above described vanishing of boundaries at the systems interaction level, in the proposed OcoP, is turned from threat into opportunity. The idea of an OCoP is based on the opinion that structural boundaries drawn by formalizing relationship among actors may prevent the generation of new knowledge, by opposing a resistance to change. To understand what makes it possible to dynamically and easily organize such project-systems the focus must shift on interactions. In this respect, it is interesting to consider that a community, like an individual, in interacting with other entities, is characterized by the action of two forces (Golinelli, 2011): the one (consonance) addressing to achieve condition of harmony; the other one (competition) opposing a resistance, insofar interaction implies, according to the requisite variety law [2], a reciprocal variety change in order to align different systems varieties. In this respect, VSA offers interpretation schemes useful to both analyze and govern respectively the structure of relationship and the interaction process in such organizations, duly taking into account the specific relational conditions. In particular, it suggests to verify, to the alignment of individual information varieties, the condition of consonance at the level of the categorical values. According to the information variety model [2,6,7], the knowledge that identifies a viable system is made up not only of items or organized structures of information (like databases), but mainly of deeply rooted values, beliefs, and opinions, as well as cognitive and interpretation schemes. Common or harmonic values will act as facilitators of interaction among different actors accelerating the achievement of consonance that is fundamental to the emerging of an effective project-system, characterized by informal and temporary relations. Consonant categorical values generate a gravitational centre among the nodes attracting to the shared goal. What is particularly interesting is that 169

180 in these cases there is less need of a governing role, because the alignment between actors emerges spontaneously bottom-up. Therefore, an OCoP can effectively work, without requiring huge governing resources, if, first of all, consonance is achieved at the categorical values level. At a second level, according to the information variety model, consonance is determined by the action of interpretation schemes. As interaction between individuals (as well as organizations) can always be interpreted as a cognitive interaction, a fortiori interaction among CoPs should be investigated in terms of knowledge transfer process, as the ultimate aim of a CoP is creating new knowledge. The role of the interpretation schemes is twofold. On the one hand, they guide and determine interpretation in processing incoming information units; therefore, they determine the reciprocal understanding of interacting entities; in this case, they need to be similar, as they act on the level of consonance. On the other hand, what is more relevant to our aims, they offer new perspectives of observation of reality that are expression of the paradigms of reference of the different communities; in this case, they increase the level of variety of the whole connected organization, creating the basis for co-generating new knowledge. In this sense, by participating to an OCoP, single nodes shift from a traditional logic of (closed) Communities of Practice to a logic of Open Community of Practice, benefitting from the opportunity to use a synergistic modular structure where individual nodes dynamically become parts of variable multi-node structure, with multi-functional capacities. At this point, we need to clarify how interaction in OCoP can facilitate the process of creating new knowledge.! The openness feature of the proposed OCoP allows for a creative combining of knowledge that may result in devising new interpretation schemes. In this perspective, the project-system emerging from the OCoP, just on the basis of the knowledge variety owned by the whole project-system and oriented by the project goal [19] can be able to face decisional conditions, that, while resulting complex at the level of the single nodes, become just complicated or even simple at the level of the whole organization. This is clearly a systemic effect of the interaction. In this sense, OCoP may represent an organizational strategy of fast and creative [16,23] acquisition of knowledge to face complex decision making conditions, shifting from the complexity side to the certainty side of the knowledge curve represented in Fig

181 Fig. 4. The process of knowledge from chaos to complexity to complication to certainty. Source: [5]. The proposed OCoP model also allows for the dynamic configuration of capacities, in order to develop T-shaped professionals [20,21], able to combine!""#$ %&'#"(")%"$ *)$ &)"$ +&,$ '&,"-$.,"./0$./$ 1"22$./$ 3,&.!$ 4)!",/(.)!*)5$ &6$ '.)7$ 6*"2!/. The model aims at highlighting the opportunity for creating a mutual learning environment (cognitive context) where network is not simply a mechanism for organizing and managing the relationship between different subjects but becomes a service platform through which participants interact by informally contributing to the learning process. Bearing in mind that one of the main characteristics of knowledge is the high temporal contextualization, in a fast changing environment it becomes easily old vanishing the efforts of structuring knowledge into the network. The key idea of our model is the generation of new knowledge on the basis of a re-interpretation approach, i.e. the subjective interpretation of existing knowledge (shared into the network by interaction) through different interpretation schemes characterizing the paradigms of reference of the CoPs participating to the network. The basic process is the re-use of knowledge through the interaction process, i.e. the socialization [14], aimed at the creative co-generation of new knowledge. 3.2 Guidelines for a VSA-DKMF integrated model Although we are aware of the difficulties deriving from the integration of two already consolidated models, there are common characteristics of VSA and DKMF that encouraged us to propose an integrated model. Indeed, they are both meta-models and can be described/understood as conceptual frameworks based on the structure-system paradigm. This last aspect allow us to propose a DKMF cube with the new dimension made of elements of information variety peculiar to VSA (fig. 5). We have one more dimension on the DKMF cube representing the Information Units, Interpretation Schemas and Categorical Values that can be used to determine consonance and resonance based on information variety when they are shared between parts. 171

182 Fig. 5. A DKMF cube with the VSA dimension. The fact that and VSA and DKMF are meta-models makes the integrated model very general. However, an instantiation step is necessary to make it useful in practical contexts. During the instantiation step, the role of VCS acts to build the whole organization of a network of OCoPs while the LKM appropriately works at the different levels of emerging structures as defined in cap.2. The two roles now can use the four phases (Planning, Tailoring, Relationships, Use) described in [27] basing their effectiveness on the usage of Information Items, Interpretation Scheme and Categorical Values to create consonance and resonance. The instantiation process proceeds qualifying: a) the four KM pillars at the meta-level of virtual community, b) stating identities of participants, the negotiations and trust relationships; the definition of the rules that allow the LKM to consume/produce knowledge from/to the virtual repository. The Consonance and Resonance of OCoPs need to be planned, tailored, to have relationships defined and used to correctly create the OCoP using the other dimensions of DKMF. Obviously the used knowledge processes can be repeated how many times we need to move between the activities related to different levels of organization of DKMF. 4 A case study: cooperation and knowledge sharing between Eclipse and PKMT An example of case study is that which arises directly from a project of Eclipse Italian community. The OTRE (On the Road Eclipse) project [24,25] had the task of 172

183 developing a complete platform for managing an online conference. It has involved at least fifty students, many teachers and some post docs and undergraduate students. From the technical point of view, it was aimed at implementing a fragmented system in its sub-systems. But the real key point was to handle the 13 subprojects in a correct and efficient way saving time and respecting the schedule. The lesson learned from the experience of OTRE represents a good opportunity for the eclipse community but also for universities it could be a chance to make knowledge flow in the network of participants. The project has involved different courses (programming, computer science, software engineering, web development) and students belonging to the engineering faculty of the University Federico II of Naples, Genoa and Savona). In practice, an OCoP has been created in which an open innovation network operates as an instance of a VSA +DKMF. The following table shows the projects in which students were involved. It was necessary to provide them with a short course of project management before they could participate in various tasks assigned to each. Table 1 OTRE project organization Sub-Project Students Priority State SSIN (Single Sign-IN) 2 high testing RC (Reporting Center) 3 medium testing AVC (Audio and Video Conference) 2 high testing CST (Conference Sharing Tools) 3 medium testing IT (Interaction Tools) 4 medium testing MSC (Managing Scientific Contribution) 2 medium testing Asset Management (AM) 7 medium ongoing (RE&R) Requirement Elicitation, Engineering & Representation 4 high ongoing Advanced Asset Management (AAM) 8 low ongoing (QM) Quality Management 3 high ongoing Testing (T) 4 high started SSIN Portal and Services (SSIN P&S) 2 low started OTRE Portal (OTRE P) 3 high started Total 47 In this last activity is substantiated the importance of the OCoP Project and Knowledge Management Trend whose skills in project management, best practices and suggestions were very important in order to develop a syllabus for the 173

184 construction of a module to be inserted in the course of software engineering. Another community, Jazz community (jazz.net), was involved in order to define the "get-handon experience" and share their best results into software projects. To summarize the main content of the project management course, students will be introduced to project management basics. They will understand the role of user stories, sizings, defects, etc.. Students will understand the role of dashboards and get hands-on experience with sample dashboards which projects cannot be found at Jazz.net. Also the students will spend time with the live online dashboards jazz.net (or a larger sample project) and put together a write-up of current status with suggestions on how to improve. To support all these projects without one or more tools enabling the project manager to monitor their progress is an impossible undertaking. The IBM community has been involved, with the IBM Academic Initiative (again a OCoP). Its contribution has been to provide the development platform for the RTC management and project management. In order to strengthen project management activities, the Eclipse community has also collaborated with IBM Rational in the ETC project [24, 25] (Enforcing Team Cooperation using Rational tools) were developed and added many tools and plug-ins in Rational Team Concert (RTC). Fig. 6, shows a session in which the project management team leader conducts its components. Fig. 6. Requisite backlog in ETC project using Rational Team Concert platform In the sprint backlog, project manager can add some action points, set priority and assign to a student. Clicking in the project backlog the project manager can monitor the assigned works. When the items are solved, they disappear and in Developer s Task board the project manager can see the correct status of the task. 174

185 Fig. 7. Task recap in a ETC project management task using Rational Team Concert platform It is possible to view a recap of all tasks assigned and unassigned (see fig. 7). It is interesting to think about how the cube meta-model described in Figure 5, matches an instance of the OTRE project. If you imagine, for example, to move its faces, and objects on them, so as to align them, as a Rubik's cube, we can find instances of the meta-model. The instances of the model can be described by quadruples of objects selected on the faces that can create consonance or resonance between the communities. In other words in the OTRE project, we brought students from various universities working on a common project, of which they built a part. The role of the leader has created consonance. In the case of a leader we can extract the following function-instance!f. F(leadership, identity, categorical values, transfer). (1) This instance, represented by a function of characteristics, could in turn be measured by giving each object its own metric, so as to highlight the best resonance in the subproject and then the best leadership. Other similar instances could be extracted from the cube meta-model. Some might express consonance rather than resonance especially for team members. 5 Conclusions The work made by scientific communities towards knowledge sharing and cooperation can be traced back to exciting successes and discouraging failures. An important impulse in such direction came from the ideas of Ludvig von Bertalanffy and other scientists in the period when the General System Theory was conceived [26]. The premises were that there are fundamental structures that act in many scientific fields; when we learn these structures a consistent amount of knowledge can be transferred from one discipline to another with relatively little effort. Using the words of Bertalanffy: 175

186 there exist models, principles, and laws that apply to generalized systems or their subclasses, irrespective of their particular kind, the nature of their elements, and the relationships or forces between them. It seems legitimate to ask for a theory, not a system of a more or less special kind, but universal principles applying to systems in general. Apart the need to capitalize efforts done in a given discipline through the identification of concepts, models and methods that by analogy could be used by other disciplines, there is also the need to exploit knowledge developed within a given scientific community (such as a CoP) in the context of another scientific community whenever possible and convenient. To manage knowledge sharing and cooperation, the model proposed in this paper proposes the integration of the Viable System Approach and the Distributed Knowledge Management Framework. The VSA provide us the suitable concepts (consonance, competition and resonance) that can be used to better understand the potential of OCoPs when they act as open systems in order to enhance product, process and research innovation. The DKMF provide us the method to create a network of cooperating OCoPs as well as its structural representation. As far as we know, the case study presented in the paper is the first attempt to put together two OCoP, (Eclipse and Project and Knowledge Management in the case study) that have completely different missions. The experience gained shows that from the cooperation mutual benefit arose for both communities. On the one hand, the people of the Community Eclipse that worked on the project OTRE gained deep understanding of the nine knowledge areas covered by the PMBOK during the interaction with members of the PKMT community. On the other hand, people, accustomed to work with theory and methodology of Project Management, learnt tools and technology usually employed in the Eclipse or Jazz communities and are now considering the eventuality of using them as a support for their daily work or as concrete realizations against which to verify theoretical models and methods developed during the research activities on Project Management. References 1.AA.VV., Contributions to theoretical and practical advances in management. A Viable Systems Approach (VSA), International Printing Srl Editore, Avellino, Ashby, W. R., An introduction to cybernetics. Chapman and Hall, London, Barile S., Management sistemico vitale, Giappichelli, Torino, Barile S., Polese, F., Smart service systems and viable service systems.in: Service Science, Vol.2 No.1/2, Barile S., The dynamic of Information Varieties in the Processes of Decision Making. In: Proceeding of the 13th WMSCI - World Multi-Conference on Systemics, Cybernetics and Informatics, Orlando, Barile, S., Saviano M., Foundations of systems thinking: the structure-systems paradigm, in AA.VV., Contributions to theoretical and practical advances in management. A Viable Systems Approach (VSA), International Printing Srl Editore, Avellino,

187 7.Barile, S., Saviano M., Qualifying the concept of systems complexity, in AA.VV., Contributions to theoretical and practical advances in management. A Viable Systems Approach (VSA), International Printing Srl Editore, Avellino, Demirkan, Spohrer, Krishna (eds.), The Science of Service Systems, Springer Book Series, forthcoming. 9.Golinelli M. G., Viable Systems Approach (VSA). Governing business dynamics. Cedam, Vol. II, Padova, Golinelli, G.M., L Approccio Sistemico Vitale (ASV) al governo dell impresa. Cedam, Padova, Lusch R.F., Vargo S.L., Toward a Service-Dominant Logic of Marketing: Dialog, Debate, and Directions, Sharpe, New York, Minati, G., Pessa, E., Abhram, M., Systemics of emergence: research and development. Springer, USA, Ng Irene, Maull R., Smith L., Embedding the Discipline of Service Science, in: Demirkan, Spohrer, Krishna (eds.), The Science of Service Systems, Springer Book Series, forthcoming. 14.Nonaka I., Takeuchi H., The Knowledge Creating Company. University Press, Oxford, Piciocchi P., Saviano M., Bassano C., Network Creativity to Reduce Strategic Ambiguity in Turbulent Environments A Viable Systems Approach (VSA), in AA.VV., Contributions to theoretical and practical advances in management. A Viable Systems Approach (VSA), International Printing Srl Editore, Avellino. 16.Poincarè, J.H., The foundation of science. Science House, Inc, New York, Saraceno, P., Il governo delle aziende. Venezia, Libreria Editrice Universitaria, Saviano M., Analisi sistemico vitale della distribuzione commerciale, Giappichelli, Torino, Saviano M., Di Nauta P., Project Management as a compass in complex decision making contexts. A Viable Systems Approach., in Proceedings della 1st International Workshop on Project and Knowledge Management Trends - PKMT2011, PROFES 2011, Torre Canne (Br), 21 giugno Spohrer J., Anderson L., Pass N., Ager T., Gruhl D., Service Science, IBM Research, in Journal of Grid Computing, Special Issue on Grid Economics and Business Models, August 2, Spohrer J., Golinelli G.M., Piciocchi P., Bassano C., An Integrated SS-VSA Analysis of Changing Job Roles, in Service Science, Vol. 2, n. 1, Stankosky M. Creating the Discipline of Knowledge Management The Latest in University Research, Elsevier, Vicari, S., La creatività dell impresa. Tra caso e necessità. Etas Libri, Milano, M. Coccoli, P. Maresca, L. Stanganelli, " Computer Supported Collaborative Learning in Software Engineering", IEEE EDUCON Education Engineering 2011, Annual Global Engineering Education Conference, Amman, Giordania, April 4-6, 2011, pp , Digital Object Identifier: /EDUCON M. Coccoli, P. Maresca, and L. Stanganelli, Enforcing Team Cooperation: an example of Computer Supported Collaborative Learning in Software Engineering, Proc. of the 16th Int. Conf. on Distributed Multimedia Systems, pp , Chicago, IL, U.S.A., Oct , L. von Bertalanffy, General System Theory: Foundations, Development, Applications, Amazon, G. Franco, P. Maresca, G. Nota " Modeling Social Influences in a Knowledge Management Network", Journal of Distance Education Technologies, vol. 8(1), Jan-Mar 2010, Idea Group inc., pp ISSN Pessa, E., What is emergence?, in Minati, G., Pessa, E. (eds.). Emergence in Complex Cognitive, Social and Biological Systems. Kluwer. 177

188 29. Rullani E., La fabbrica dell immateriale, Carocci, Roma. 178

189 Towards cloud learning with ETC and Jazzhub Giorgio Galli 1, Ferdinando Gorga 1, Paolo Maresca 2, Carla Milani 1, 1 IBM, Italy, {Giorgio_Galli, Ferdinando_Gorga, Carla_Milani }@it.ibm.com 2 DIS, Dipartimento di Informatica e Sistemistica, Università di Napoli Federico II, Via Claudio 21, Napoli, Italy {Paolo.Maresca}@unina.it Abstract. Collaboration is considered as a teaching strategy but, in many cases such as in the programming and software engineering classes, collaboration has to be a learning outcome itself, since students must acquire a specific ability in team working. Thus a suited working environment is needed, that has to be much more than just a flexible Learning Management System. Consequently, a specific project has been launched within the Eclipse italian community in the framework of the Enforcing Team Cooperation (ETC) activity. The aim of the project is that of enforcing and enlarging cooperation activities among a large number of students, all attending programming and software engineering courses at different Universities in Italy. The main idea behind the project is the implementation of a really effective Computer Supported Collaborative Learning (CSCL) paradigm, to be used for higher education on team cooperation, in software engineering classes for the analysis, design, and development of software programs along their lifecycle. The project, in cooperation with IBM Italy as part of IBM's Academic Initiative and the Italian Eclipse community, has obtained interesting results so far as to build a migration of it into JazzHub IBM cloud platform. In addition, the cloud technology looks promising in order to improve cooperation and formation of student groups on specific objectives besides providing valuable support to the construction of virtual laboratories. This paper will discuss both innovations that cloud technology can provide the teaching of programming and software engineering, and first impressions of students and researchers who have used it. Keywords: Cloud computing, Eclipse-Jazz, Team Cooperation, E-learning. 1 Introduction Cloud computing seems to be a promising technology that offers the ease in building cooperation and development environments quickly without doing any installation on local computers. At present, researchers agree that this technology is here to stay because of the unprecedented opportunities provided to achieve economies of scale never conceived before [1]. Many vendors are available on the market cloud, among these we remember: Microsoft, HP, IBM, Amazon, Salesforce, Google, VMware and 179

190 Netup. Among the first workload that are migrating to the cloud we have: and collaboration, development, testing and vertical industry solutions. It 'also true that cloud amplifies many problems that are themes of research both in universities and industries. Cloud adopters continue seeking to solve problems of security, integration and data quality of their cloud computing [2], but also a new list of challenges are growing, mainly around the problem of cloud-to-cloud integration, user productivity and porting information to mobile devices. Cloud represents a drastic shift in terms of new possibilities it enables [3] the promise is not just to make something more cheaply, but to achieve it in a fast, simple, effective and more flexible way than we have never seen before. The cloud should have a profound effect in the way people think about the use of computing especially when you can consume a platform as a service (PaaS) from any data center in any location and with any device. Mobility / cloud ecosystem has the aims to provide infrastructure, platforms and software as a service, allowing more people to benefit from access to information from anywhere[4]. The university system tends to be increasingly made up of students who benefit from mobile services. It's clear that the challenges involved are making sure the services, protect infrastructure from attack and to protect private data and privacy of anyone. IBM, with its Academic Initiative program, is interconnecting the universities and also with the help of open source communities such as Eclipse ecosystem [5,6] is focusing on research and training of high quality. Spohrer in [7] measures the vitality of this program through a paradigm of 5 R. When the interconnection between the universities is strong it is observed that the growth of the vitality is susceptible. This happened in the project ETC [8]. ETC stand for Cooperation (ETC) using rational software tools into software engineer [8,9]. At the actual prototypal stage, 6 Universities in Italy are involved in the pilot project. In more details, the participants are the following: Federico II, Napoli, Milano Bicocca;; Bologna Alma Mater, Bergamo;; Genoa and his Savona campus;; Bari and his Taranto campus. The students signed-up into the platform are 535 and they all will keep working along the entire second semester of the on-going academic year, after having started in the first semester. Each University has gone forming developments teams by merging together students from different courses: from the Universities of Naples Federico II, Bologna and from the Universities of Genoa and Bari;; from the University of Bergamo. Heterogeneous and distributed teams must be composed with students from different cities and with one teacher tutor for each. In addition, for each University, a Champion Student (tipically a computer engineering or computer science, Ph.D. student) is chosen to support the corresponding teacher. Besides, the Champion Student is the responsible of the local group. One only computer engineering Ph.D. student (administrator) has the technical direction for the overall ETC platform, for what concerns both software and hardware configurations and resources. In the new JazzHub [10], powered by IBM Rational Team Concert, a team based development solution for both traditional and agile planning, gives software and systems engineering students tools that make software development and deployment a truly social experience. JazzHub allows university teams to develop directly on IBM's Jazz.net website with no fee. Jazz is an open platform designed to support any participant who wants to improve the software development process [11]. On 180

191 JazzHub, registered university teams can begin development in under a minute. At the moment the following academic institutions, with their specific goals, are participating in the JazzHub Beta Program: - North Carolina State University will use the JazzHub in future curriculum projects [12]. The institute previously used Jazz for research, analyzing information about artifacts, and in an online course in Agile software development. - Tecnológico de Monterrey (Mexico) and the University of Macedonia (Greece) will participate in joint development work with the JazzHub to promote collaboration between students across international borders. - University of Naples Federico ll (Italy) is undergoing a project with seven other local universities, entitled Enforcing Team Cooperation (ETC), which is using the disciplines of software engineering in a collaborative environment to create new applications. JazzHub, in its beta version, will enable students from different universities to cooperate in the cloud developing projects at no cost. There are currently 41 active projects. The remaining part of the work is organized as follows: Section 2 explores cloud computing, and describes the strategies adopted by IBM. Section 3 discusses the first impressions given by teachers and students in the use of cloud in the project OTRE (a project within the ETC initiative). Section 4 offers conclusions and future developments. 2 Cloud computing and IBM strategies In the last decade Software became one of the main components that contribute to transform business across the industry spectrum. From the manufacture and sale of goods to energy conservation and financial services, we assisted to this transformation with an incredible speed, increased data elaboration capacity and intelligent. While such progress creates new business opportunities and also paths toward and flexible enough to support the associated and often dramatic business changes [13]. Tradition enterprise tends to pull together resources and deploy them in support of a business function workload on project at a time, or in silos. The resources are dedicated to the workload and are unable to support other workloads where they could be leveraged as added support. So what is really different about cloud computing? A Cloud computing on the other hand leverages a pooled resources environment that uses virtualization in order for the physical assets to support multiple workloads, see fig.1. In order to drive efficiency of the delivery to enable the self-service, self-management of cloud computing requires standardization of the assets (hw, sw, delivery) as well as automation. This is what delivers a responsive end user experience. So from the end users point of view it is elastic in scalability, accessible from any device, anywhere, any time, and if charged pay only for what they use during the time they are using it. 181

192 resources that are location independent and have automated service management to handle provisioning, de-provisioning, change management, security and overall environment controls. Fig. 1 Schema of tradition workload and infrastructure compared with Cloud computing Cloud computing represent the emerging answer to the need for such flexibility, providing a highly automated, dynamic delivery of IT services. Companies are leveraging the massive scalability and collaboration capabilities of cloud computing the most out of their existing hardware resources ands peed time to market for new services and capabilities. Cloud computing is enabling organization to do more with less. With the promises that the cloud delivers, many companies are considering building their own clouds some private for corporate use only and some public for their customers and users outside of their firewall. Through [14]: 11 cloud development labs around the world. over 200 IBM researchers working on breakthroughs in cloud security and privacy. Invested more than $3 billion in key cloud acquisitions, including: WebDialogs, ThinkDynamics, Outblaze, Cast Iron Systems, Coremetrics, Unica, Sterling Commerce, ISS, Arsenal, Diligent Technologies. IBM is helping leading companies to design, create and use cloud models, infrastructure and services. Not just to improve their efficiency and cost effectiveness, but also to drive transform their businesses. In particular IBM is focusing attention in solution and services for: Consolidation and Virtualization of Infrastructure and Applications Providing the infrastructure, platform and managed services that enable consolidation and virtualization of cloud environments and applications 182

193 Standardizing the configuration and deployments of topologies, patterns, and workloads for faster time to market and service delivery Optimized Workloads Providing the expertise and capabilities to migrate, build, deploy and manage workloads and the new business models they enable across heterogeneous infrastructures. Providing integrated, heterogeneous infrastructure to execute the workloads on the best fit platform Seamless integration across cloud environments Integrating traditional and cloud delivery models to provide a seamless user experience Monitoring hybrid environments to optimize workload Management Consistent integrity and security Monitoring the underlying architecture and infrastructure to reduce threats. In a multi-tenant environment, ensuring that the tenants cannot accidently or maliciously impact one another. databases hosted in a cloud environment to protect them from leaks and exposures. But, What about the cloud for the Application LifeCycle Management and related SoftwareDevelopment and delivery organizations? How the cloud can be used to streamline and enhance the work of software developers and delivery today? Today, Geographically dispersed development and delivery teams are being asked to respond to changes in the marketplace more quickly with fewer resources and while delivering more value applications with increased quality. In this scenario many IT managers need to: Reduce the capital and operational expense of IT systems and resources for software development through an increased efficiency and utilization Quickly deploy an infrastructure for Software Development to support rapidly changing and new project needs. Governing software best practices for corporate governance and dealing with concerns regarding regulatory and security compliance. Produce application that can be easily deployed on the new infrastructure model. To overcome these obstacles, developers and delivery team need new ways to work more efficiently. IT managers must leverage dynamic, agile infrastructures to respond to rapid marketplace changes and evolving business requirements. Cloud represent also for Software Development a valid and proven answer to this needs. IBM Rational approach to Software Development and delivery and cloud, can be categorize into 3 different categories [14] see fig. 2, mainly. 183

194 ON the cloud This is tools running on a cloud infrastructure, such as running a full Application LifeCycle Management platform on a cloud environment, as your hardware resource infrastructure. FOR the cloud is preparing applications to run on a cloud infrastructure. Thus, meaning that the tools and capabilities you are using are taking the cloud infrastructure into account in preparation for deployment. LEVERAGING the cloud This is exploiting the elastic nature of a cloud infrastructure. Thus, in this category the cloud infrastructure is a more integrated part test lab provisioning. These elastic nature of the cloud offers new and unique capabilities not available in traditional data centers. Fig. 2 IBM approach to Software Development and delivery for and on the Cloud IBM Rational Platform provides comprehensive to for a collaborative application lifecycle management (ALM), from Requirement to Test and Deploy. Which you can provision as a service on the cloud (private or plublic 1 ). These services provide you with tooling specifically designed to handle different workloads 2 to transform software delivery by making it more collaborative, productive and transparent. 1 For a IBM public Cloud for software development refer to 2 Jazz is an IBM program that is composed of 3 main initiative. A Jazz community ( that increase and facilitate collaboration between end-users communicate and IBM labs. A framework (Jazz) based on OSLC (Open Services for LifeCycle Collaboration ) that provide services for ALM. An third a set of product built on top of Jazz to support the different discipline of ALM. 184

195 Fig. 3 IBM Rational Platform based on Jazz infrastructure to support a Collaborative Software Development and delivery for and on the Cloud Jazz platform, in fig. 3, exactly exploit the capability described above. ON the cloud Pre-defined, pre-configured images of the Jazz-based integrated platform named Collaborative Lifecycle Management 3 (that include Rational Team Concert, Rational Quality Manager, Rational Requirement Composer, Rational Asset Manager and Rational Build Forge). These allow users to get up and running quickly with these products in a cloud environment. A pattern we are beginning to see more is a desktop cloud solution for developers and/or testers. By providing scalability and on demand provisioning Cloud Computing improves server and resource utilization, thereby reducing administrative costs and labor. FOR the cloud When preparing applications to be deployed to a cloud environment, considerations about topology planning, automation and governance of the deployments come to mind. Cloud adoption is bringing the need to consider what a topology needs to and should look like when it is to be deployed to the forefront, especially due to the desire to automate as many of the steps as possible. Rational provide tool for design and deliver in compliant to Cloud infrastructure. 3 Mode tails can be found at Jazz.net 185

196 LEVERAGING the cloud In a traditional development environment, test loads are typically constrained by hardware availability to run larger performance tests, more hardware is required to under test. Conversely, test hardware is likely to be underutilized performance testing typically takes place at specific points of a typical development iteration or project, and the hardware is idle for the remaining time. Studies have shown that test hardware may only be utilized between 10-20% of the time on any given project. Because of this, running large load tests can be prohibitively expensive in terms of license costs (virtual tester packs) and infrastructure With IBM Rational Load Testing on Cloud, for large load tests engineers can automatically provision virtual test agents and generate virtual users on the Cloud from Rational tools. To exploit this capability to a broader community, a new IBM initiative called JazzHub has been started. This is an invite-only beta program for students, professors, and academic researchers. It offers free access to Rational platform on the cloud (in Software as aservice form) so that there is no need for professors to download, install, or configure a server before using in the classroom. Students and professors can enjoy the following: All of the features of Rational Team Concert No download, install, or configuring the server Project dashboards allow professors to evaluate student progress Compatible with both web and client-based GUIs At this stage, each project on JazzHub must be sponsored by a faculty member who is a member of the IBM Academic Initiative [15] 3 Towards cloud learning The ETC project (Enforcing Cooperation Team) had a strong impact on students of the University of Naples Federico II in the year as experimental test then it can spread to other universities of the ETC project [9]. For 2 semester students were constantly engaged. In particular, in the first semester they were active in building a virtual laboratory of programming during which they produced 23 homework by learning to manage the versioning their code. In this activity, students work individually and operated in conjunction, each has developed and versioned total of about lines of code in semester. The lab covered a virtual programming effort equal to 3 credits (CFU). The activities in this phase of interaction was cooperative with teacher and team leaders. In the second half they started software engineering projects that involved 47 students who had been trained in the virtual laboratory in the previous semester. These students were engaged in the development of a 13 sub-projects within the project OTRE (On the road eclipse) [8,9] and here they have acquired knowledge and 186

197 have developed parts of their project building documents and artifacts by using the tools provided by ETC. Table 1: OTRE sub-projects Sub-Project N. Students Priority SSIN (Single Sign-IN) 2 high testing RC (Reporting Center) 3 medium testing AVC (Audio and Video Conference) 2 high testing CST (Conference Sharing Tools) 3 medium testing IT (Interaction Tools) 4 medium testing MSC (Managing Scientific Contribution) 2 medium testing State Asset Management (AM) 7 medium ongoing (RE&R) Requirement Elicitation, Engineering & Representation 4 high ongoing Advanced Asset Management (AAM) 8 low ongoing (QM) Quality Management 3 high ongoing Testing (T) 4 high started SSIN Portal and Services (SSIN P&S) 2 low started OTRE Portal (OTRE P) 3 high started Total 47 During the second semester has been an unexpected event that is the same group of students was admitted in the trial JazzHub. This project involved a dozen students at once, Fig. 4 shows the snapshot of the project. This opportunity has given rise to the need to reflect on the implications that this opportunity provides innovative in terms of dissemination of the concepts of learning. Meanwhile it is clear that the type of relationship between the teacher and students involved in the projects was of a different nature. The students see their teacher as a coach and very quickly acquire both operating modes offered by the platform as a best practice. 187

198 Figura 4. Jazz Hub snapshot for OTRE project From the organizational point of view teacher assigns tasks and keeps them through a dashboard that is a useful instrument panel which monitors the progress of students and therefore the proficiency / deficiency of both students and whole team. Through JazzHub you can also share code, version it, and also develop it through the use of eclipse. More generally, however, the use of Jazz Hub, such as ETC, lets you organize projects that are not geographically limited. In other words, as ETC have allowed the project management team which belonged to different Italian universities. Now with JazzHub you can invite people to a project belonging to any university in the world and share content with them. For example, you can share the curricula and programs of a single course. 5 Conclusions and future development It is worth investigating a Cloud computing possible use at the university level thanks to the opportunity offered by Academic Initiative of IBM. Through this initiative could be offered not only software but also hardware which would not be handled locally. This would greatly facilitate the construction and maintenance of laboratories that are to be offered to students during class. In addition, the trial would involve other international universities for the dissemination of the idea behind ETC and then to develop projects and activities during the courses cooperatively. There is a big point, however, overlooks the fact that this platform is aimed at experienced researchers and innovations seem to be faster than we can disseminate them. I mean there and feel a strong lack of teaching materials at different levels. For example there is the need to have a module called Programming in a Collaborative Environment (using Rational Team Concert) in which it is necessary to explain to students how they can organize a programming virtual laboratory and how versioning 188

199 is done onto common repositories. Another module would be essential of project management (with Rational Team Concert) which is able to explain students how to manage their projects. It is also important to have another module named Agile Development (with Rational Team Concert) in which students learn how to conduct projects of software engineering and particularly agile process (Scrum, Sprint, etc,) but would also be useful as one can handle an Assett in the module Assett organization and dissemination using RTC and RAM that would allow students to handle the artifacts and the skills acquired in their work. Of course, the academy may be useful at this stage for the preparation of real practical lab in these courses after they are tested in a university domain. Through the Academic Initiative provides many courses, but these are especially dedicated to the sector professionals but would need to have courses for different levels of users including universities in order to broaden the audience of people who can benefit from the tools. There are huge advantages to have a cloud structure in a university course. The first is the speed of operation. The laboratory should not be installed and this saves students a couple of weeks between software acquisition and installation of all applications making them operational immediately. In addition, you can stop quickly on the peculiarities of the instruments without having to deal with issues of tedious and often poorly documented tools configuration. In this way, students could concentrate on the course and not on the details of installation tools. Another advantage is the speed of harmony of the team. When the project is started it is easier for a new person to join. Also, the fact that the laboratory will develop virtually don't requires that all students who participate are simultaneously present in the courtroom to begin the activities. Finally, since the laboratory is not real does not require maintenance efforts or the alignment of applications with a considerable saving of time and money by the institutions offering the course. It is worth stopping at the end of this section on the need to rethink the way in which in this scenario should be produced instructional materials. Anything that produces a team can be a valuable educational material, an asset, provided that it is recognized as useful by a team of experts. It may be a web service, and made immediately available to the entire network of students, for the entire community of practice. It is worth noting that among the future developments of the research is to test our learning model. It is a model of cooperative learning and are believed to be innovative as it is applied to heterogeneous groups of students. The groups consist of students who do not belong necessary to the same institution and that could belong to universities located in geographically different places. Of course, the learning model of this project will be compared with other models of learning in order to decide which one work better than other. For this reason we are preparing a plan of measures, which will be a next job. We have confirmation that ETC project is really attractive by the number of students who participated. This will help us to understand how students may perceive attractive this training offer proposed by collaborative JazzHub. We can say that the number of students who participated and used the tools IBM over two semesters were about 300 of which about 150 are used to manage a remote laboratory for the development and management and versioning of code C + + and Java and about

200 students worked on projects in software engineering (project OTRE) [8,9,32]. The remaining number of students (about 80) has been involved in supporting projects such as RAM, testing, requirements engineering, test case management, etc. Up to now the number of students participating is growing and is 536 and some of them are already porting OTRE project into JazzHub. References 1. S. Srinivasan, V. Getov: Navigating the cloud computing landscape- technologies, services and adopters, Computer, vol. 44, n. 3, pp , IEEE press (2011). 2. B. Narasimhan, R. Nichols: State of cloud applications and platforms: The cloud adopters' view, Computer, vol. 44, n. 3, pp , IEEE press (2011). 3. Y. A. Khalidi: Building a cloud computing platform for new possibilities, Computer, vol. 44, n. 3, pp , IEEE press (2011). 4. P.Banerjee, et al: Everything as a service: powering the new information economy, Computer, vol. 44, n. 3, pp , IEEE press (2011). 5. Eclipse foundation, 6. Eclipse italian community, 7. J. C. Spohrer: IBM's university program, Computer, vol. 37, n. 8, pp , IEEE press (2010). 8. M. Coccoli, P. Maresca, L. Stanganelli, " Computer Supported Collaborative Learning in Software Engineering", IEEE EDUCON Education Engineering 2011, Annual Global Engineering Education Conference, Amman, Giordania, April 4-6, 2011, pp , Digital Object Identifier: /EDUCON eam Cooperation: an example of Conf. on Distributed Multimedia Systems, pp , Chicago, IL, U.S.A., Oct , IBM Offers New Tools to Help University Students, Professionals Prepare for Information Technology Top Jobs, Jazz ecosystem, XXII, no. 3, CIO White Paper April - Staying aloft in tough times. Why smart,innovative businesses are turning to cloud computing. Copyright IBM Corporation 2009 IBM Global Services. 14. IBM Cloud. Rethink IT. Reinvent Business. Copyright IBM Corporation 2009 IBM Corporation Software 15. Alan W. Brown Presentation - IBM Rational CTO Europe - Cloud Computing and the Future of Enterprise Software Delivery 16. Academic initiative, P. Dillenbourg, Collaborative Learning: Cognitive and Computational Approaches. Advances in Learning and Instruction Series, Elsevier Science, NY, Computers Education, vol. 25, no. 3, pp , R.E. Slavin, Cooperative Learning: Theory, Research, and Practice. Englewood Cliffs, NJ: Prentice Hall, M. Hamm and D. Adams, The Collaborative Dimensions of Learning. Norwood, NJ: Ablex,

201 21. Proc. Int. on Computers in Education, pp , Dec A. Bandura, Social Learning Theory. Englewood Cliffs, NJ: Prentice Hall, Proc. Int. Conf. on the Learning Science, Advances in Computers, vol. 59, Academic Press, Aug C. Ghezzi, M. Jazayeri, and D. Mandrioli, Fundamentals of Sotware Engineering. Englewood Cliffs, NJ: Prentice Hall, IEEE Software, vol. 16, no. 3, pp , May/June OMG Software Engineering Notes, vol. 11, no. 14, pp , ACM, New York, Proc. of the 2003 OOPSLA Workshop on Eclipse Technology Exchange, pp , Anaheim, CA, IEEE Software, vol. 24, no. 6, pp , Nov./Dec Coccoli, M., Maresca, P., Stanganelli, L.: Enforcing Team Cooperation Using Rational Software Tools into Software Engineering Academic Projects. In: Eclipse-IT 2010, Ed. M. Coccoli, pp , De Ferrari, Genova University Press, Genova (2011) 191

202 Learning Processes and Cooperative Development in Software Engineering Mauro Coccoli 1, Paolo Maresca 2, Lidia Stanganelli 1 1 DIST Department of Communication, Computer and Systems Science University of Genova, Via Opera Pia, Genova {mauro.coccoli, lidia.stanganelli}@unige.it 2 DIS Department of Computer and Systems Engineering University of Naples Federico II, Via Claudio, Napoli {paolo.maresca}@unina.it Abstract. This reports on the state of advancement of the OTRE project, whose first results were presented during the previous workshop of the Italian Eclipse Community. A wide variety of services and products based on ecosystem Eclipse is being developed, through the interactions between teams composed by groups of students, in different Italian universities. They have joined the project with the aim of learning to develop software systems and services, according to the software engineering principles. Keywords: Eclipse, Software Engineering, Cooperative Learning, Teamwork. 1 Introduction The use of collaborative work methodologies in software development is a winning strategy and it can enhance performances and results. Significant empowerments of the whole development process can be achieved through the adoption of collaborative tools, as a support to traditional software engineering techniques [1]. Nevertheless, collaboration and collaborative processes need a strict coordination among people and their relevant activities, which may lead to an overhead in the activity of management. This is further amplified when teams participating to the collaborative work are arranged in geographically distributed groups. From an educational point of view, this reflects in the need of exploiting the so-called Computer Supported Collaborative Learning (CSCL), generally recognized as a powerful mean for teaching [2]. Then, from a merely technical point of view, suited software tools must be chosen, so to enable learners to cope with the problem of collaborative software development. In the present work, the Eclipse Integrated Development Environment (IDE) [3] is the adopted solution. In more details, within the OTRE Project the CSCL techniques are applied in the academic reference scenario of software engineering courses. In addition, the Jazz platform [4] has been adopted, owing to its features. In fact, Jazz is designed to perform the role of an Orchestra Director, so to improve and to drive them to work together effectively [5]. Moreover, the Italian Eclipse 192

203 Community has been investigating in depth the capabilities of the Jazz platform along the last years, so that a significant know-how has been already acquired and shared among the members and, finally, student can take benefit from the work already done by previous classes. In this reference scenario, the aspects of collaborative software development are being stressed, for an educational use with students of both software engineering and programming courses. This has driven the set-up of well-defined Jazz-based experimental test bed, for the development of collaborative projects. On the one hand, the objectives are: i) to rule the software development process, ii) to make it an observable process and iii) to identify suited software metrics for evaluation purposes. On the other hand, the educational objective is teaching young students a modus operandi by forcing them to perform different roles (e.g., analyst, developer, tester) so to better understand the criticisms of their work and to enable them to be active part of a work-group. This is a challenging idea because the collaborative model is in contrast with traditional university activities, which are usually driven by competition. The mandatory conditions, to be observed by all of the participants, for collaboration to take place are the following: i) they feel part of a team and recognize a task leader, ii) all together, they perceive a common objective, and iii) they experience a good communication. In this respect the teacher role is shifted to act as a facilitator, while learning may happen among peers. In more details, the OTRE activity is based on 8 sub-projects, 8 team leaders, 1 project leader and 1 general project manager and its reference scenario is that of a full-featured on-line conference management system. Besides, a fundamental part of the project is relevant to the production of a good documentation, so that single assets can be re-used and the work experience is duly valued and becomes replicable, as well as best practices. In this vein, the OTRE Project can be an effective playground for practical software engineering. The remainder of the paper is the following. In Section 2, the OTRE project will be described from both the architecture and management points of view, outlining its main features. In Section 3 we will outline the state-of-the-art of the project, by describing the asset management of the organization with special reference to the adopted software solution supporting the development. Section 4 is devoted to the description of the resource management. Finally, in Section 5 the achieved results will be presented as well as some considerations on possible future development. 2 The OTRE Project In a few words, the OTRE project and the related activity can be described as the experiment of realizing a collaborative learning project, built on the Eclipse IDE and tools. During the development of sub-tasks, users are recommended to use collaboration tools, improving the production of artifacts. The whole project is composed by a variety of sub-tasks;; some of them are not related, while others are strictly dependent. Even, one task may be propaedeutic to another one. Since the project has a seamless integration with the educational activity carried on by (academic) members of the Italian Eclipse community, the results will be collected, published, shared and discussed in the annual conference and this has to be 193

204 considered a part of the educational task. In fact, during the workshop, the teams that have collaborated remotely will have, finally, the opportunity of meeting themselves as well as of comparing their work and results with the ones achieved by the other teams involved in the same project. It sounds like a peer-to-peer conference in the conference, which wants to be much more than a student contest. Each team of students will have completed a group of tasks whose outcome was the realization of a working plug-in for the Eclipse IDE, which will also have to be interoperable with the ones developed by the other teams and, possibly, made available world wide, in the Eclipse Marketplace. We also point out that the OTRE project is much more then an educational activity, since it originates in the framework of an innovative academic project sponsored by the Italian branch of IBM, IBM-Italia. Such program is called [7]. At the actual prototypal stage, 6 Universities in Italy are involved in the pilot project. Specifically, the participants are the following: Federico II, Naples;; Milan, Bicocca;; Alma Mater, Bologna;; Bergamo;; Genoa and his Savona Campus;; Bari and his Taranto Campus. At the moment of writing, the number of students signed-up within the platform is 528. They all (and maybe more) will keep on working along the entire second semester of the on-going academic year. Each University has gone forming nd Milan must be composed with students from different cities and with one teacher tutor for each. In addition, for each University, a Champion Student is chosen to support the corresponding teacher, typically a skilled computer engineering or computer science, PhD student. Besides, the Champion Student is the responsible of the local group. For what concerns both software and hardware configurations and resources, one only PhD student has the technical direction for the overall ETC platform, covering the role of administrator. The topics addressed in the project are directed to a re-engineering of the actual Italian Eclipse Community Web site. In a wider vision the objective is that of developing general-purpose services and applications for a variety of specific fields of interest. Such new services have to be analyzed, designed and developed, with the objective of making the relevant Web site the perfect place to repeat the experimentation after the first group of pioneers students and teachers have achieved their first results. Future classes will have the opportunity of participating, by adding further functionality to the system, integrated with the ones already available and exploiting the previous experience. In fact, after the first running phase, the OTRE will represent a repeatable model so that new experiences can be done without the start-up period and with a quick set-up time as well a smooth learning curve. According to the specifications outlined by the teachers, the newly realized Eclipse-IT portal will have to integrate audio and video contents, paying attention to accessibility and making multi-format information available to the visitors. In this present edition of the OTRE project, the activity will be centered on a set of modular components that will be designed and realized to manage events. Proposed services are: a liveconference system (live streaming of the talks given at the conference);; news 194

205 management;; live blogging;; interactive boards supporting chat sessions and live discussions;; collaborative systems such as wiki for the documentation management (user, developer, and reference manual, documentation, etc.) as well for the organization of the conference agenda and the topics in a barcamp style;; discussion boards for exchanging opinions;; sharing systems;; publication tools addressed to different targets such as scientific community, developer community, generic and specialist press;; user data and profiles management;; mash-up tools for the data fusion contributions for a workshop;; a repository and indexing system to archive the work done and to keep track of interactions;; content management;; advanced search capabilities;; semantic description, indexing and search systems with specific handlers for software libraries and for the Eclipse plug-ins in particular. 2.1 Software Architecture The project started in In its first stage [6] was designed the architectural design of the system OTRE. Given the good results achieved in the first phase of development [6], it was decided to start another activity devoted to detect, represent, promote and exchange experience, skills and knowledge acquired by students. This task involved University of Naples Federico II, the University of Genoa (and his Savona Campus) and the university of Milan Bicocca. A specific task will be the one that picks up, organize and share assets emerging during project. In this case, an asset is any kind of collection of artifacts that provides a reusable solution to a given business problem. The application that is observed is a system that will allow web services to manage a workshop or a conference. Fig. 1. The OTRE software architecture The system handling the eclipse workshop event is composed of the following functions (Fig.1) with the 195

206 aim of managing media contents (e.g., voice, video, streams) including conferencing with the aim of making available such a useful tools from an organizational point of view. For the sake of brevity, the blocks shown in Fig. 1 will be no further detailed;; just some additional information about some strategic components will be given. The interested readers can find a more detailed description in reference [8]. that live-conferencing tools for streaming audio and streaming video of the talk of the conference may be a good choice for a practice community that plans to grow further and continuously;; these information will be accessible from both the companies and the students. Connected to these, other cooperative tools are provided, such as live blogging, blackboard and wiki, finalized to support live-report during the conference and post-conference discussion. It is worthwhile to outline that wiki tools could be useful also for collaborative construction of topics for the first call for papers and agenda of the day after, by the Technical Program Committee. For not-attending people, sharing tools, browser for remote viewing of presentations by the various channels through video streaming are available for use. The inclusion of tools to package and sharing web technical articles and essays is also planned, to re-arrange data in order to publish them onto journals or magazines. A more specific resource is represented by a mash-up activity designed to manage conference data (both video and audio) in order to extract and abstract behavior of virtual communities and groups during both the development of the project and the community activities (e.g., conferences, sharing knowledge). Finally, tools for archiving and cataloguing the plug-ins developed by both students and professionals, submitted to the community in the annual workshop will be available. These will own capabilities of semantic content search and classification with plug-in for document management and software libraries management. The project will involve groups of students with different roles predefined and geographically distributed throughout Italy between those universities participating to the experimentation. 2.2 The OTRE Project: Issues Management As already mentioned, the considered track of the OTRE project is composed of 8 sub-projects. In addition, 4 supporting projects have been launched, each with its own specific development process and assets. Each sub-project assigned to a team is supported by documentation and is developed by using Internet collaborative tools. Fig. 2 shows both the projects already completed and the ones released for the testing phase. For each sub-project a process of development is assigned. Details are given in Table 1, in which one can find the explanation of the acronyms of each sub-project, the number of participating students, the assigned priority and the state of the art. As reported, the total amount of students involved is 44 and they are coordinated by 3 graduating students, 1 PhD student, and by 2 teachers assuming in tandem the general 196

207 It is worthwhile to describe, albeit briefly, the purpose of the OTRE supporting projects. The project is complex;; therefore it is necessary that some groups will serve to support some of the oth As an example, each group identifies and proposes the functional and nonfunctional requirements for their sub-project, which are discussed and approved during several conference calls. Fig. 2. The OTRE System Table 1. Detailed situation of sub-project, people involved and state of advancement Sub-Project Students Priority state SSIN (Single Sign-IN) 2 high testing RC (Reporting Center) 3 medium testing AVC (Audio and Video Conference) 2 high testing CST (Conference Sharing Tools) 3 medium testing IT (Interaction Tools) 4 medium testing MSC (Managing Scientific Contribution) 2 medium testing Asset Management (AM) 7 medium ongoing (RE&R) Requirement Elicitation, 4 high ongoing Engineering & Representation Advanced Asset Management (AAM) 8 low ongoing (QM) Quality Management 3 high ongoing Testing (T) 4 high started SSIN Portal and Services (SSIN P&S) 2 low started OTRE Portal (OTRE P) 3 high started Total 47 After the approval, the RE&R group draws up the specification documents and circulates them among the other interested groups. That is, a group of students that 197

208 harmonizes the processes of collecting requirements. The QM group has the task of defining test cases, while the T group will actually run them into sub-projects. The group SSIN P&S has the task of developing a Web application that serves to log into the OTRE system and therefore makes available all services provided within single sign-in models. The groups involved in AM and AAM, respectively, describe the projects assets (e.g., requirements and design) and the people assets. The AAM in particular, is dedicated to the construction of metadata for representing the knowledge and the skills acquired by each student. Thus, the network of knowledge allows flowing these capabilities and makes them available for the reuse to other communities, where necessary. Fig. 3. OTRE Main Use Case diagram The diagram shown in Fig. 3 represents the main use-case diagram of the project. It is the result of a collaborative process, obtained at the end of the discussion and the acceptance of requirements by all (groups, general manager and team manager). In a subproject each feature designed to be incorporated from time to time (incremental development with iterative enhancement), also being a prerequisite for some other feature was necessary to assign a priority to the various subprojects. The Table 1 shows the sub-projects and their priorities. State of art is: there are 6 sub-projects completed in the testing phase, others are ongoing and others just started. 198

209 3 OTRE State of the Art Fig. 4. Screenshot of the OTRE-P: OTRE portal access (italian version) As already mentioned in Section 2, the OTRE project is at a stage of advanced development. Below we will discuss those applications that have been developed and are now in the testing phase. Since OTRE represents an abstract system that contains many heterogeneous applications, a portal was built, hosting the sub-projects and the service projects. To begin, Fig. 4 shows the OTRE-P portal. OTRE-P contains not only OTRE applications, but permits to manage the connection with some ETC tools that are used in the OTRE project, such as RAM and RQM, which are discussed below because these two tools of ETC are important for OTRE. Also OTRE-P maintains a wiki and a forum for group of developing of project, which consists of 47 students, 3 undergraduates and 1 PhD. Fig. 5. Screenshot showing the Single Sign-IN Portal & Service (SSIN S&P) 199

210 SSIN P&S is the first tool and sub-project of OTRE. It is the service for the single sign in, for applications inside OTRE. The same SSIN P&S will be used to interact with IBM-Rational applications inside ETC project. Fig. 5 shows the application that uses CAS for SSIN. Through this application, each OTRE project user engaged a single portal access to make any other access to use other OTRE applications. One important subprojects of OTRE, is the management of work submission or the MSC project (Managing Scientific Contribution), which is made using a customized version of Alfresco, see Fig. 6, the submission and works refereeing can be customized, at the moment only changing Alfresco. Fig. 6. Screenshot of the OTRE-MSC for managing scientific contribution In the near future we plan to define some primitives to enable semi-automatic modification of the OTRE-MSC application. Another project integrated into OTRE is AVC (Audio and Video Conference). This project has two perspectives: supply and use. In the former case, the director enters the application, he/she chooses a specific room, then connects and transmits the work (see Fig. 7). In the latter case, the user logs in and selects the conference room where user accesses virtually, and in this way assists the work. Separate discussion is needed for the two tools Rational Asset Manager and Rational Quality Manager content, in OTRE-P website. In the next paragraph will discuss project asset and how these have been important, also for the cultural maturation of the student team. With regard to RQM, the projects were followed by a students group who have engineered the requirements. The project name is (RE&R) Requirement Elicitation, Engineering & Representation. The same group has defined the test case of functional and non-functional specific, for which it was necessary to use Rational Quality Manager for the definition and tracking of test cases. Another group of students will have the task of testing whole OTRE project at the end of its development. 200

211 Fig. 7. OTRE-AVC: perspective of spectator 4 Resource Management The OTRE organizations accumulate artifacts while developing their projects, including: software artifacts such as requirements, code, and documentation, skill, ability, and so on. The idea is to collect, store and share assets developed within the OTRE Project. An asset is a collection of artifacts that provides a reusable solution to a specific problem. We observed that using assets foster reusing, thus reducing time, effort and risk of software development. Students tend to share a certified asset in order to solve problems. Moreover, an asset is associated with a specific set of asset's packaging. As an example of asset we can consider: i) test case, ii) business requirement, iii) functional requirement, iv) risk management plan. For the management activity to be carried-on with a professional flavor, the Eclipse platform hosting the OTRE project has been enhanced with the Rational Asset Manager (RAM), provided by IBM. More in details, the Rational Asset Manager can be described as a collaborative, development-time asset management repository, 201

212 enabling teams to identify and manage the design, development, and utilization of software and other reusable, business-related assets. The RAM has tools that allow users to search, organize, and download assets. Other features enable communication among users, provide governance, and obtain statistics. In Rational Asset Manager, asset metadata conforms to the Reusable Asset Specification (RAS), a standard for organizing software artifacts into reusable assets. Rational Asset Manager has two client types, an Eclipse client and a Web client. The Eclipse client enables software practitioners to search, browse, download, and update assets within the same integrated development environment as their other software development tools. The Eclipse client functionalities are the following: Submit and classify assets Search, download, and rate assets Use assets Integrate with either CVS or ClearCase SCM adapter plug-ins Fig. 8 shows the Eclipse asset manager client platform adopted in the OTRE project. The upper side shows risk management software development plan followed by developing teams (e.g., Universities of Naples and Genoa here) and produced by a student team at Milan Bicocca. Other assets are available for use (see asset windows in the lower side of Fig. 8) and students can rate each one. enforcing team intelligence, maximizing value from non-software assets. In fact, knowledge sharing capture best practices, proven business processes and associated artifacts. Fig. 8. Screenshot of the Eclipse Client Asset Manager 202

213 5 Conclusions and Future Work In this paper, the outline of a running project has been presented, focusing on the disparate activity required to manage collaborative software development projects. The adopted solution is the Rational Asset Manager, part of the Jazz software ecosystem. Further results from the activity of the students (and their supervising teachers) will be soon available and will allow evaluating the effectiveness of the presented approach. At the present moment, 6 out of the 8 sub-projects have already reached the testing phase. Remaining tasks are at an advanced level of development, yet not released. Besides the aforementioned 8 sub-projects, 4 other jobs have been launched, so-called service components, based on the requirements emerged during the development of the main tasks. Such components are devoted to store, manage, and share the knowledge acquired in the whole project. Skills and abilities, are contained in specific assets, duly described, and accessible over the network to other developers, participating to the Eclipse open community at large. A general framework for the development of team-working skills has been presented, based on the Eclipse and Jazz framework and tools. Such a test-bed can be considered as a learning tool itself and it can be re-used in many different applications, even different from the software engineering we have been referring to along the whole paper. As a significant example, consider the Public Institutions and large Organizations. In such organizations, cooperating to reach a common objective can be a critical point to achieve results and meet the milestones. The availability of a framework enabling users to cooperate through advanced software systems can greatly empower such scenarios and interesting perspectives can be considered in many other fields. 6 Acknowledgement Authors wish to thank IBM for allowing the use of software from their Academic Initiative Program and for their helpful support. Also, authors wish to thank the Eclipse Foundation for their support to the Italian Eclipse Community. Bibliography 1. Booch, G., Brown, A.: Collaborative Development Environments. Advances in Computers, 59, Academic Press (2003) 2. Williams, S., Roberts, T.S.: Computer Supported Collaborative Learning: Strengths and Weaknesses. In: Proc. of the 2002 Int. Conf. on Computers in Education, pp (2002) 3. IBM, Eclipse, 203

214 4. Cheng, L., Hupfer, S., Ross, S., Patterson, J.: Jazzing up Eclipse with Collaborative Tools. In: Proc. of the 2003 OOPSLA Workshop on Eclipse Technology Exchange, pp , Anaheim, CA (2003) 5. Frost, R.: Jazz and the eclipse way of collaboration. IEEE Software, vol. 24(6), pp (2007) 6. Coccoli, M., Maresca, P., Stanganelli, L.: Enforcing Team Cooperation Using Rational Software Tools into Software Engineering Academic Projects. In: Eclipse-IT 2010, Ed. M. Coccoli, pp , De Ferrari, Genova University Press, Genova (2011) 7. Coccoli, M., Maresca, P., Stanganelli, L.: Enforcing Team Cooperation: an example of Computer Supported Collaborative Learning in Software Engineering. In: Proc. of the 16th International Conference on Distributed Multimedia Systems, International Workshop on Distance Education Technologies, DMS-DET 2010 (Chicago, IL, U.S.A., Oct , 2010), pp (2010) 8. Coccoli, M., Maresca, P., Stanganelli, L.: Computer Supported Collaborative Learning in Software Engineering. In: Proc. of the 16th IEEE Global Engineering Education Conference - Learning Environments and Ecosystems in Engineering Education, IEEE EDUCON 2011 (Amman, Jordan, Apr. 4-6, 2011), pp (2011) 204

215 Agent-Based Business Process Management with Eclipse Federico Bergenti Dipartimento di Matematica, Università degli Studi di Parma Parco Area delle Scienze, 53/A Parma, Italy Giovanni Caire, Danilo Gotta, Elena Quarantotto, Giovanna Sacchi Telecom Italia S.p.A. Via G. Reiss Romoli, Torino, Italy {giovanni.caire, danilo.gotta, elena.quarantotto, Abstract. This paper describes WOLF (WOrkflow LiFe cycle management environment), an open-source development environment that leverages the full power of Eclipse to provide users with an industrial-strength business process modelling tool that has already proven its functionality in real-world projects. WOLF provides users with a graphical view of the advanced abstractions related to agent-based BPM (Business Process Management) like agents, workflows, events and messages. The core advantage of such abstractions is their high-level expressiveness that turns agent-based BPM into a solid technology that can be easily understood and mastered by both technical personnel and domain experts. The main feature of WOLF is the support for the graphical definition of workflows by means of a dedicated Eclipse editor; besides that, WOLF also helps developers in setting up Eclipse projects for realizing and managing agent-based business processes. Keywords. Agent-based business process management, multi-agent systems, distributed systems. 1 Introduction Besides their central role in Artificial Intelligence, as witnessed by, e.g., [9], agents have been recently adopted as an enabling technology for the development of mission critical software systems. Since the establishment of FIPA (Foundation for Intelligent Physical Agents, now IEEE FIPA Standardization Committee) [6] in 1996 a large research community has identified the possibilities that agents provide in the design and realization of dynamic and decentralized distributed software systems. Today, after more than a decade, software agents are a mature reality in software develop- 205

216 ment with notable successes, open-source reference tools, and a large literature that targets researchers and practitioners. Taking the peculiar point of view on agents that FIPA promoted, we can say that agents are loosely coupled software entities spread across a network of computation sites that communicate by means of asynchronous message passing. Normally, the ensemble of agents that form a so called MAS (Multi-Agent System) is highly dynamic and decentralized and the coordination of the tasks of agents is not embedded into a specific part of the system, rather it is dynamically distributed across the MAS and single agents have full control over their behaviour. This paper presents an overview of some of the most prominent open-source tools available today for the development of MASs and it focuses on the notable role of Eclipse in the provision of a workbench for the management of mission critical MASs. The paper first introduces JADE (see next section), a popular middleware for the realization of agent-based systems that provides a solid and scalable technology that has been under active open-source development for over a decade. Then, the paper focuses on WADE (see next section), the open-source, agent-based BPM (Business Process Management) system which is the final responsible for orchestrating agents to enact business processes. Finally, the paper targets WOLF (see Sections 3), an Eclipse plug-in for the realization and runtime management of BPM systems. The paper is concluded with an overview of the major projects that has been using WOLF in Telecom Italia and it outlines some future directions of research and development. 2 An Overview of JADE and WADE This section provides an overview of two of the most widely adopted open-source tools for the effective development of MASs both in research and in the industry. 2.1 JADE JADE (Java Agent DEvelopment framework) [1] is an open-source tool that has been developed in the scope of FIPA mostly by Telecom Italia in order to provide developers with a solid tool to concretize the ideas of agents and MASs. With a large community of developers and users, and with a history of over 15 years of research and development (release 4.1 is dated June 2011), now JADE is a solid tool and a first class choice for agent-based development. From the functional point of view, JADE provides the basic services necessary to deliver distributed and decentralized applications in fixed and mobile environments. JADE allows each agent to dynamically discover other agents and to communicate with them according to a peer-to-peer paradigm, i.e., all agents are equal and no agent have control over the behaviour of other agents. From the application point of view, each JADE agent is identified by a unique name and provides a set of services; it can register and modify its services and/or search for agents providing given services, it can control its lifecycle, and it can communicate with all other agents. 206

217 JADE agents communicate by exchanging asynchronous messages. The structure of a message between two JADE agents complies with the ACL (Agent Communication Language) defined by FIPA [7] and it includes fields aimed at supporting complex interactions and multiple parallel conversations, e.g., the context a message refers to and the amount of time that can be waited before a valid answer is received. To further support the realization of complex conversations, JADE provides a set of skeletons of typical interaction protocols used to perform specific tasks, e.g., auctions and task delegation. By using such skeletons, programmers can get rid of the burden of dealing with synchronization issues, timeouts, error conditions and, in general, all aspects that are not strictly related to the application logic. JADE also includes a naming service (ensuring each agent has a unique name) and a yellow pages service that can be distributed across multiple hosts. Federation graphs can be created in order to define structured domains of agent services. Technically, each running instance of the JADE runtime environment is called container and a set of related containers is called platform. In a JADE platform a single special main container is always active and other containers register with it at startup. One or more agent can be started into a single container and the actual job of an agent is described in terms of its behaviours, i.e., the set of tasks to be performed by the agent. As FIPA was primarily concerned with the definition of the enabling technologies needed to support the interoperability of agent-based applications, FIPA and JADE do not mandate an internal architecture for agents. Developers are free to choose the best internal architecture for their agents and we often have different agents designed using different architectures within a single MAS. Even if this is perfectly in line with the overall goals of FIPA and JADE, the use of such technologies in real-world applications brought the need of a reference model for the internals of agents. The rest of this section introduces a software layer on top of JADE that targets the field of agentbased BPM and that ultimately provides a specific agent architecture. 2.2 WADE WADE (Workflow and Agent Development Environment) is a domain agnostic platform built on top of JADE that targets the use of agents and MASs in BPM. WADE has been intensively developed since early 2000 (release 3.0 is dated July 2011) and [5] provides a detailed description of WADE together with the presentation of two mission critical applications developed by Telecom Italia with it. Until version 2.6, the main target of Wade was the implementation of the system internal logics, using the workflow metaphor. Following the workflow metaphor, a process can be defined in terms of the activities to be executed, the relationship between them, used to specify the execution flow, the conditions of start-up and termination and the required inputs and expected outputs. The main advantage of using the workflow metaphor is that a single workflow can be represented in a graphical form, easily understandable by domain experts as well as by programmers. Domain experts can then validate the system logics and, in some 207

218 cases, they could even contribute to the actual development of the system with no need of programming skills. Another important characteristic of the workflow metaphor is that the steps that compose a process are explicitly identified. This facilitates the implementation and the use of automatic mechanisms to trace the execution of a workflow for the purposes of system monitoring and problem investigation. Additionally, automatic or semi-automatic rollback procedures can be activated in case of unexpected fault, when processes need to be executed within the scope of a transaction. Finally, because of their expressiveness, workflows are considered selfdocumented artefacts and the development team is no longer required to keep documentation in line with actual systems. WADE adds to JADE the support for the execution of workflows and a few other mechanisms needed to manage the complexity of distribution, in terms of both administration and fault tolerance. In order to do that, the following specific components have been added: 1. Boot daemon processes: there is a boot daemon process for each host in the platform which is in charge of the activation of local containers. 2. Configuration Agent (CFA): the CFA always runs in the main container and it is responsible for interacting with boot daemons and for controlling the application life cycle. 3. Controller Agents (CA): there is a CA for each container in the platform and CAs are responsible for supervising activities in local container and for all fault tolerance mechanisms provided by WADE. 4. Workflow Engine Agents (WEA): each WEA embeds an instance of WADE workflow engine and WEAs are primarily intended to execute workflows. (a) Fig. 1. (a) Coarse-grained view of a WADE-based application, (b) the WOLF workflow editor Figure 1a shows a coarse-grained view of a WADE-based application. WADE specific components are highlighted in blue. As discussed later in Section 3, WOLF supports the graphical definition of workflows (see Figure 1b), the setup of the Eclipse project to develop the application and the management of the application running (b) 208

219 remotely or locally. WOLF tries to keep the advantages of workflows representation, without giving up the power and the flexibility of everyday programming languages and represents a key element in the WADE approach. Since 2010 new requirements have been coming out from Telecom Italia Wadebased systems as well as the open source community. Especially, more and more frequently it was indicated as a mandatory feature the need to properly manage situations where a workflow could block waiting for external events that may happen in hours, days or even months. To meet such ever growing requirements with version 3.0, WADE had a strong evolution that, though preserving its distinctive characteristics, makes it now a tool that can effectively play the role of orchestrator in a BPM context. Among the new features introduced in version 3.0, it is important to mention the possibility of defining and executing long-running workflows, workflows that survive to a system restart, the possibility of handling asynchronous events and the enrichment of the functionalities for the Web Service exposure, already available since version WOLF: An Eclipse-based Environment to Develop WADE Applications A key element of the approach that WADE advocates is WOLF (WOrkflow LiFe cycle management environment), the Eclipse-based development environment for WADE-based applications. Using WOLF, developers are free to adopt the workflow metaphor when they think it is suitable and they can easily switch between the workflow view and the Java code view according to what they consider more appropriate. As its name suggests, WOLF is not only a tool to graphically create workflows for the WADE platform, rather it is a complete environment to manage the whole life cycle of workflows: from early prototyping, to testing, up to final deployment. Technically, WOLF is an Eclipse plug-in and it allows WADE developers to effectively use the full power of Eclipse plus additional WADE-specific features. It allows the management of the whole life cycle of workflows using a single development environment and it provides support for: (i) graphically editing of workflows; (ii) controlling a local or remote WADE-based application; and (iii) deploying and executing workflows in a controlled application. In order to grasp the functionality and the insight of WOLF, we first need to briefly give details on how WADE represents workflows. Several attempts to support graphical development of system internal logics have been attempted and several descriptive formalism, e.g., XPDL [Error! Reference source not found.], and BPEL [10], have been defined in the literature. However, if on the one hand they provide a clear and intuitive representation of the process execution flow, on the other hand they are not suitable to specify all details involved in the implementation of a piece of the business logic of a complex software system. A wellknown programming language like Java is definitely more effective in dealing with data management and transformations, computations and other low level auxiliary operations that can be needed when specifying the business logic of a system. Taking this into account, the approach followed by WADE is to provide a workflow view on 209

220 top of an everyday Java class. As a consequence, a workflow is concretely implemented as a Java class and no specific workflow definition language is needed. However, WOLF adopts a workflow meta-model, based on the XPDL standard, defined in the XPDL [Error! Reference source not found.] and extended when it is necessary. In the WOLF meta-model a process is represented as a workflow, consisting of one or more activities that can be thought as tasks to be executed. In a workflow, the execution entry point is defined specifying the first activity to be performed; this activity is called start activity. On the other hand, a workflow must have one or even more termination points, named final activities. The execution flow is defined by means of transitions. A transition is an oriented connection between two activities and may have an associated condition. Regular and exception transitions can be defined. Exception transitions allow specifying branches that are taken only when an exceptional case is met in the source activity. Excluding the final ones, each activity may have one or more outgoing transitions. When the execution of an activity is terminated, the conditions associated to its outgoing transitions are evaluated. As soon as a condition is verified the corresponding transition is activated and the execution flow proceeds towards the destination activity. Normally a process execution uses internal data, e.g., to pass intermediate results between activities and/or for the evaluation of conditional expressions. In WOLF the internal data are modelled by data fields. A process can have one or more inputs to be provided and one or more outputs expected at the end of its nominal execution. Inputs and outputs of a process can be formalized in WOLF by means of the workflow formal parameters. Many types of activities are available in WOLF and, among them, the most important are: 1. Code activity: a code activity is an activity used to model common tasks in an agent-based BPM system. Code activities allow describing the operations to be performed directly by a piece of Java code embedded in the workflow process definition. 2. Subflow activity: a sublflow activity is an activity whose execution corresponds to the invocation of another workflow. 3. Web Service activity: a subflow activity is an activity providing support to invoke Web Services within a workflow. 4. WaitEvent activity: a wait event activity is a synchronization activity that, when reached, make the execution block until a given event happens. 5. WaitWebService activity: a wait web service activity is a synchronization activity that, when reached, makes the workflow block until the event corresponding to the invocation of a Web Service operation happens. 3.1 Managing WADE-based projects The first step to use WOLF in an Eclipse Java project is to mark it with the WADE nature. The project nature is an Eclipse concept used to characterize a project and to give it a set of additional functionalities. Once the WADE nature is added, all the 210

221 features of the WOLF plug-in become available to the project. Such features are described hereafter. Workflow editing, deployment and execution. WOLF provides support for: (i) workflow editing; (ii) workflow deploying on a running platform; and (iii) workflow execution on a given WEA. Obviously a WADE platform must be active and running in order to deploy and execute a workflow. Once the execution is started the user can monitor it by means of a dedicated editor, which shows status information, output parameters, possible failure reasons and workflow tracing information. Controlling/activating a WADE based application. In order to test newly created workflows WOLF allows starting an internal WADE platform, in this case the execution of the boot daemon and of the main container is controlled by Eclipse and both of them can be launched in normal or debug mode. Agent tree view. WOLF provides support for connecting to an internal or to an external platform and to manage the applications running on it. This can be done by means of the so called agent tree view. Such a view enriches the functionalities of the JADE RMA (Remote Management Agent) [1] with WADE specific aspects. In particular, two buttons are provided in the agent tree view toolbar to connect/disconnect to/from a running WADE platform. In case that the main container process is launched internally, the agent tree view automatically connects to it. Once connected, the buttons to control the application life cycle are enabled. By double-clicking on an agent in the agent tree view the user can inspect and, when relevant, modify its exported attributes by means of the agent details editor. 3.2 The Workflow Graphical Editor As mentioned before WOLF provides a workflow view on top of an everyday Java class. In the following, a few details about the workflow representation in WADE, the workflow editor and its architecture are provided. Workflow representation in WADE. A workflow is implemented by a Java class that extends (directly or indirectly) the WADE class WorkflowBehaviour. The WorkflowBehaviour class provides a set of APIs which can be used by developers to implement their own workflows. The mapping between the meta-model objects and the workflow implementation is shown in the example depicted in Figure 2. The methods registeractivity() and registertransition() must be used respectively to add an activity and a transition. When we call the method registeractivity() its first parameter is an instance of the activity to be added. The following types of activities, corresponding to the activities described in the meta-model, can be created: CodeExecutionBehaviour, SubflowDelegationBehaviour, WebServiceInvocationBehaviour, WaitEvent- Behaviour and WaitWebServiceBehaviour. 211

222 public class SendMail extends WorkflowBehaviour {... protected void defineactivities() { //ACTIVITY Prepare Mail... registeractivity(prepar , INITIAL); //ACTIVITY Verify Mail... registeractivity(verifymail);... } Send Mail protected void definetransitions() { registertransition(new Transition(), PREPARE_MAIL, VERIFY_MAIL); registertransition( new Transition("IsCorrect", this), VERIFY_MAIL, SEND_MAIL);... } SEND MAIL PROCESS Prepare Mail Verify Mail Modify Mail protected void executeprepar (final ApplicationList applications) throws Exception {... } } protected boolean checkiscorrect() {... } Fig. 2. Mapping between meta-model objects and workflow implementation Activities that are in charge to perform a well defined task (like CodeActivity and SubflowActivity for instance) are associated to a void method of the workflow class specifying the task to be performed; this method must have the same name of the activity, preceded by the prefix execute. The workflow engine is in charge of invoking that method when the activity is visited. Instead, synchronization activities (like for instance WaitEventActivity) are associated to a pair of void methods, having the same name of the activity preceded by the prefixes before and after that are respectively responsible for better characterizing the waited event and pulling out the data included in the event itself. In a similar way, the registertransition() method takes a transition instance as parameter. For transitions with conditions, the boolean expression to be 212

223 evaluated by the workflow engine is specified in a boolean method that has same name of the condition, preceded by the prefix check. As previously mentioned, many types of activity are available in the meta-model and the class WorkflowBehaviour provides a set of APIs to manage such activities. For example, in a WebService activity to define the URL of the WSDL, describing the service to be invoked, the setwsdl() method must be used in the workflow definition. For more details about workflow coding, see the WADE tutorial [11]. An important feature of the object-oriented programming languages is the possibility to reuse code by means of inheritance. In order to bring the programming language power also to the workflow representation, it has been chosen to extend inheritance to workflows. Therefore WADE allows defining a new workflow by extending an existing one, and then adding/removing activities and transitions. The overriding of methods associated to the activities and to the conditions of transitions is also permitted. The workflow editor. WOLF is implemented as a plug-in of the Eclipse platform and it requires the availability of JDT (Java Development Tooling) and GEF (Graphical Editing Framework) plug-ins. The workflow graphical editor (henceforth, simply workflow editor) offers a graphical view of the Java class that represents a workflow. WOLF lets developers switch between the graphical view provided by the workflow editor and the code view provided by Eclipse Java editor. So, the workflow editor is strictly bound to the Java editor in order to guarantee consistency between the two views. Synchronization between the graphical and code views is maintained asymmetrically because (i) modifications made through the workflow editor are immediately visible in the code view; while (ii) modifications made through the Java editor become visible in the graphical view when clicking on the Refresh button. When opened, the workflow editor provides developers with proper tools to modify the graphical view and switch from the graphical view to the code view. The developer uses a tool palette to insert activities and/or transitions in the workflow. The types of activity that can be created are those supported by WADE and they include: code, subflow, Web Service wait event and wait Web Service. Regular or exception transitions can be created and in both cases the user can assign a condition to them. Finally WOLF provides a problems view strictly related to the workflow editor where semantic problems encountered in the workflow definition are shown. For instance, a non-initial activity with no incoming transitions will never be visited during the execution of the workflow and is therefore indicated in the problems view as a warning. Architecture of the workflow editor. The workflow editor is based on the GEF plug-in. GEF is a very powerful framework for visually creating and editing models. A model is the starting point for any GEF application; it represents the data to be displayed and edited by the graphical editor. 213

224 The heart of GEF is the Model-View-Controller pattern and in our case the model reflects the workflow meta-model previously described. The main classes that build the model comprise WorkflowProcess (the container of activities and transitions), Activity (the elementary work unit in a workflow) and Transition (the connection between activities). Instances of such classes form an in-memory representation of the workflow to be edited and are created by parsing the workflow Java file. A description of the parsing procedure is provided below. The Workflow model is displayed using figures from the Draw2D plug-in, thus the View part of the editor is entirely delegated to Draw2D. The controller bridges the view and model. Each controller, or EditPart using the GEF terminology, is responsible for mapping the model to its view. Any Edit- Part contain also the EditPolicies, which generate the commands for making changes to the model. Finally any EditPart also observes the model and updates the view to reflect changes of the model state. The workflow editor includes the following EditPart implementations: WorkflowProcessEditPart, ActivityEditPart and TransitionEditPart. All parsing operations on the workflow Java file are performed using the APIs provided by the JDT plug-in. JDT is a full featured Java integrated development environment and it offers the AST (Abstract Syntax Tree) API for manipulating Java source codes. The abstract syntax tree maps plain Java source code to a tree form and such a tree is much more convenient and reliable to analyse and modify programmatically than a text-based source. After the model generation, the workflow editor uses the model itself to create the EditPart implementations associated to all activities and transitions included in the workflow process. During the workflow editor initialization (see Figure 4a), the workflow editor also instantiates an object from class ModelListener that is an observer of the graphical model. The ModelListener is notified of changes made by the user in the graphical editor and it is responsible for updating the Java code. When the user interacts with the editor, the EditPolicies generates a command that manipulates the model. Model changes are notified to EditPart instances and to the ModelListener. The EditPart instances and the Model- Listener respectively refresh the view and modify the Java code. Figure 4b shows an example in which the user adds an activity A* and the related the ActivityCreateCommand is invoked. This command modifies the workflow process model object adding a new activity. A notification is sent to the Workflow- ProcessEditPart and to the ModelListener. The former reacts by showing the activity. The latter reacts by modifying the AST tree in order to add new nodes that represent the registeractivity() method invocation. When a workflow is displayed by the workflow editor also the Java editor is kept opened on the same workflow. To allow synchronization between the two editors, the working copy mechanism is used. A working copy is an in-memory representation of the Java file and it permits to share the file with multiple clients. In our case, it is used by the Java editor and, at the same time, it is modified programmatically by the ModelListener so that changes appear immediately in the Java editor. 214

225 (a) Fig. 3. (a) Workflow editor initialization, (b) example of workflow editing When the user modifies directly the workflow Java class, the workflow editor is not automatically updated. Synchronization must be explicitly triggered by the user. (b) 4 Conclusions This paper describes a stack of open-source technologies, namely JADE, WADE and WOLF, that provides users with a graphical view of the advanced abstractions related to agent-based BPM like agents, workflows, events and messages. The core advantage of such abstractions is their high-level expressiveness that turns agentbased BPM into a solid technology that can be easily understood and mastered by both technical personnel and domain experts. The paper mostly concentrates on WOLF, an open-source development environment that leverages the full power of Eclipse to provide users with an industrial-strength business process modelling tool that has already proven its functionality in real-world projects. From a methodological point of view, the combined use of JADE, WADE and WOLF has been appreciated in the development of mission critical agent-based BPM systems for the agile approach that it brings in. The tools presented in this paper provide a solid platform for the development of complex BPM systems that tightly integrate the power of a visual approach with scalability, robustness and interoperability with mainstream technologies. This has reduced the effort needed to develop effective demonstrators and prototypes that were fruitfully scaled up to the core parts of real systems, thus reducing time-to-market and improving the overall qualities of the systems and of the development processes. In particular, the tools that this paper discusses proved to be largely useful to develop applications having strong requirements regarding performances, scalability and high flexibility in defining the systems logics. In fact, such tools are used in Telecom Italia for a number of mission critical systems (see, e.g., [4]) that are now in everyday use with real users and in the scope of projects with real customers: 215

226 1. NNEM implements a mediation layer between network elements and OSS systems for millions of Telecom Italia customers; 2. Wizard provides step-by-step guidance to thousands Telecom Italia technicians performing installation and maintenance operations in the fields with more than 1 million documented assisted installation since 2007; and 3. WeMash, a mash-up platform, enables non-developer users self-creating simple applications and sharing them within their team. The results were so compelling that Telecom Italia chose JADE, WADE and WOLF as the enabling middleware for a SAAS (Software As A Service) offer for customers in the fields of electricity, gas and water. This offer includes various systems (Wizard 2.0, WeMash, and a bus orchestrator) based on the new functionalities of WADE with a fully functional service oriented architecture based completely on open source components. References 1. Bellifemine, F., Caire, G., and Greenwood, D. (2007) Developing multi-agent systems with JADE. John Wiley And Sons 2. Bergenti, F., Caire, G., Gotta, D., Long, D., and Sacchi, G. (2011) Enacting BPM-oriented Workflows with WADE. In Procs. 12 th Dagli Oggetti agli Agenti (WOA 2011) 3. Business Process Modeling Notation (BPMN) Caire G. (2008) WADE: An Open Source Platform for Workflows and Agents Caire, G., Gotta, D., and Banzi, M. (2008) WADE: A software platform to develop mission critical applications exploiting agents and workflows, In Procs. 7 th Int l Conf. on Autonomous Agents and Multiagent Systems (AAMAS 2008), Foundation for Intelligent Physical Agents (FIPA) FIPA ACL Message Structure Specification Java Agent DEvelopment framework (JADE) Newell, A. (1982) The Knowledge Level. Artificial Intelligence, 18(1): Shapiro, R. (2002) A comparison of XPDL, BPML and BPEL4WS, Cape Vision 11. Sacchi, G., Marando, A., Quarantotto, E., and Caire G. (2011) WADE Tutorial Defining Agent tasks as workflows Trione, L., Long, D., Gotta, D., and Sacchi, G. (2009) Wizard, WeMash, WADE: Unleash the Power of power of collective intelligence. In Procs. 8 th Int l Conf. Autonomous Agents and Multiagent Systems (AAMAS 2009). 13. XML Process Definition Language (XPDL)

227 Exploiting the Eclipse Ecosystem for Agent-Oriented Programming Andrea Santi, Andrea Leardini, Antonio Natali, and Alessandro Ricci DEIS, Alma Mater Studiorum Università di Bologna via Venezia 52, Cesena, Italy Abstract. In this paper we discuss first explorations about exploiting the Eclipse framework in the context of agent-oriented programming, using an agent-oriented programming platform called JaCa. At first, we discuss how the Eclipse framework can be naturally exploited for designing and developing a modular feature-rich agent-oriented IDE, to represent, manipulate, inspect JaCa programs directly in terms of such agentoriented abstractions defined by the JaCa computation/programming model. Then, we extend the scope of the discussion by devising: (a) the opportunity of exploiting Eclipse for exploring a model-driven approach to agent-oriented programming and to the development of the agentoriented programming languages and the platforms themselves; and (b) the opportunity of injecting agents into the Eclipse ecosystem, so as to enrich it with first-class human-inspired abstractions to deal with the flexible organization of concurrent and distributed tasks, and their coordination. 1 Introduction The fundamental turn of software into concurrency, interactivity, distribution is not only a matter of performance, but also design and abstraction. The free lunch is over as put by Sutter and Larus in a recent paper [27] calls for devising new programming paradigms being the evolution of existing ones or not that would allow to naturally think, design, develop, execute, debug and profile programs exhibiting different degree of concurrency, reactiveness, autonomy, decentralization of control, distribution. In that perspective, agent-oriented programming introduces a high-level abstraction layer drawning inspiration from human systems and organisations to conceive programs as organizations of autonomous entities called agents interacting in various ways in a common distributed environment. Since the seminal paper by Shoham dated 1993 [25], many agent-oriented languages and frameworks have been developed the interested reader can find good surveys here [5 7] and most of the contributions in the proceedings of workshops like ATAL (Agent Technologies, Architectures and Languages) and ProMAS (Programming Multi-Agent Systems). So far, the background context 217

228 of this research has been Artificial Intelligence (AI) and Distributed AI, so exploring such languages and technologies just as a tool for developing multi-agent systems as a technique to solve complex problems or implement intelligent complex systems [12]. Besides this perspective, a further research line aims at exploring agentoriented programming more generally as a post-oo general-purpose programming paradigm, providing a level of abstraction which is effective to tackle main complexities that are more and more part of everyday software, related to concurrency, distribution, interactivity [24]. In that perspective, we aim at exploring aspects related to agent-oriented programming which have been almost not considered so far being not relevant from an AI perspective. These aspects concern features of the programming languages and the underlying computing models that are interesting in a software engineering perspective as well as features of the development environments and tools. To this end, we aim at exploiting the features provided by Eclipse framework to design and develop a full-fledged IDE (as a front-end) for agent-oriented programming; furthermore, to setup up a software factory [17] to work on the agent-oriented programming languages themselves, to be adapted according to the need, and finally support the systematic development of the back-ends from parsers up to the intepreters and virtual machines to run the agent programs. In this paper we show our first results in these directions, adopting an agentoriented programming platform called JaCa, described in Section 2. In Section 3 we describe the design and development of an IDE for JaCa based on the Eclipse framework, which provides a way to represent, manipulate, inspect the JaCa programs directly in terms of the high-level human-inspired concepts and abstractions on which the JaCa computation/programming model is based. Then, besides this practical result, in Section 4 we extend the scope of the discussion (and integration) along two related directions. On the one side, the use of Eclipse framework paves the way to investigating a model-driven approach to agent-oriented programming and to the development of the agent-oriented programming languages and platforms themselves. On the other side, agent-oriented programming exemplified by the JaCa platform in this case introduces a conceptual space whose elements and abstractions we argue may be meaningful for enriching the Eclipse ecosystem itself, which is basically based on objects and components. For both these directions the starting point is the definition of proper (meta-)models capturing main elements of the agent conceptual space, to be injected in the Eclipse ecosystem and to be then manipulable by the Eclipse modeling framework and related tools. 2 Agent-Oriented Programming with JaCa Quoting Lieberman [15], The history of Object-Oriented Programming can be interpreted as a continuing quest to capture the notion of abstraction to create computational artifacts that represent the essential nature of a situation, and to ignore irrelevant details. In that perspective, in this section we identify and dis- 218

229 CLOCK WHITEBOARD BAKERY workspace workers can join dynamically the workspace ARCHIVE RESOURCE COM. CHANNEL TASK SCHEDULER Fig. 1. Abstract representation of the A&A metaphor in the context of a bakery. cuss a core set of concepts and abstractions that characterize JaCa as a platform for exploiting an agent-oriented programming approach in software development. 2.1 The Agents and Artifacts Conceptual Model Metaphors play a key role in computer science, as means for constructing new concepts and terminology [28]. In the case of objects in OOP, the metaphor is about real-world objects. Like physical objects, objects in OOP can have properties and states, and like social objects, they can communicate as well as respond to communications. In the case of actors [1], similarly, the inspiration is clearly more anthropomorphic, and a variety of anthropomorphic metaphors influenced its development [14, 26]. The inspiration for the agent-oriented abstraction layer that we discuss in this paper is human-inspired too and refers to the A&A (Agents and Artifacts) conceptual model [19], which takes human organizations as main reference. Fig. 1 shows an example of such metaphor, represented by a human working environment, a bakery in particular. It is a system where articulated concurrent and coordinated activities take place, distributed in time and space, by people working inside a common environment. Activities are explicitly targeted to some objectives. The complexity of work calls for some division of labor, so each person is responsible for the fulfillment of one or multiple tasks. Interaction is a main dimension, due to the dependencies among the activities. Cooperation occurs by means of both direct verbal communication and through tools available in the environment (e.g., a blackboard, a clock, the task scheduler). So the environment as the set of tools and resources used by people to work plays a key role in performing tasks efficiently. Besides tools, the environment hosts resources that represent the co-constructed results of people work (e.g., the cake). 219

230 Following this metaphor, we see a program or software system as a collection of autonomous agents working and cooperating in a shared environment: on the one side, agents (like humans) are used to represent and modularize those parts of the system that need some level of autonomy and pro-activity i.e., those parts in charge to autonomously accomplish the tasks in which the overall labor is split; on the other side, the environment is used to represent and modularize the non-autonomous functionalities that can be dynamically composed, adapted and used (by the agents) to perform the tasks. 2.2 The JaCa Conceptual Space JaCa is an agent-oriented platform that allows for designing and developing an application following the A&A conceptual model 1. In particular, an application in JaCa is designed and programmed as a set of agents which work and cooperate inside a common environment. Programming the application means then programming the agents on the one side, encapsulating the logic of control of the tasks that must be executed, and the environment on the other side, as first-class abstraction providing the actions and functionalities exploited by the agents to do their tasks. More specifically, in JaCa Jason [4] is adopted as programming language to implement and execute the agents and CArtAgO [23] as the framework to program and execute the computational environments where agents are situated. Programming the Agents Being a concrete implementation of an extended version of AgentSpeak(L) [20], Jason adopts a BDI-based computational model and architecture to define the structure and behaviour of individual agents. In that, agents are implemented as state-full reactive planning systems: they run continuously, reacting to events (e.g., perceived changes in the environment) by executing plans given by the programmer. Plans are courses of actions that agents commit to execute so as to achieve their goals (tasks). The pro-active behaviour of agents is possible through the notion of goals, which are part of the language in which plans are written. The state of an agent is represented by the agent belief base, keeping track of the knowledge that the agent has about the environment, its activities, other agents, etc. Such a knowledge is organised in beliefs which are represented by Prolog-like predicates. Besides interacting with the environment, Jason agents can communicate directly by means of speech acts. From a programming point of view, the main features of the model include: (a) an explicit high-level model to organize a concurrent program, decentralizing and encapsulating control into agents; (b) an explicit model to structure active/autonomous behaviours, separating the interface (goal/task) from the implementation (plans); (c) the capability to seamlessly integrate of task-oriented 1 JaCa is part of a wider platform called JaCaMo, available at sourceforge.net 220

231 and event-oriented behaviours, thanks to the BDI-based agent execution cycle [20]; (d) a way to exploit in synergy both Prolog-like declarative programming to represent knowledge on the agent side, for defining the beliefs and goals and the procedural model, adopted to define plans. Programming the Environment On the environment side, CArtAgO following the A&A meta-model adopts the notion of artifact as first-class abstraction to define the structure and behaviour of the computational environments where the agents are situated, and the notion of workspace as a logical container of agents and artifacts [22]. Artifacts explicitly represent the resources and tools that agents may dynamically instantiate, share and use, encapsulating functionalities designed by the environment programmer. CArtAgO provides a Java-based API to program the types of artifacts that can be instantiated and used by agents at runtime As a key aspect of the artifact model, to be used by agents artifacts provide a usage interface composed by a set of operations and observable properties. Operations correspond to the actions that the artifact makes it available to agents to interact with such a piece of the environment; so, the action repertoire of an agent is dynamic and depends on the set of artifacts available in the environment set that can be changed by agents themselves by creating, disposing artifacts. Observable properties define the observable state of the artifact, which is represented by a set of information items whose value (and value change) can be perceived by agents as percepts. More precisely, on the agent side, by observing an artifact its observable properties are directly mapped into beliefs in the agent belief-base, updated automatically each time the observable property changes its value. So a Jason agent can specify plans reacting to changes to beliefs that concern observable properties or can select plan according to the value of beliefs which refer to observable properties. Besides observable properties, the execution of operations can generate signals perceivable by agents as percepts, too. Finally, the notion of workspace is used to define the topology of complex environments, that can be organised as multiple sub-environments, possibly distributed over the network. By default, each workspace contains a predefined set of artifact created at boot time, providing basic actions to manage the set of artifacts in the workspace for instance, to create, lookup, link together artifacts to join multiple workspaces, to print message on the console, and so on. Summary of the Meta-Models Involved A full description of Jason language/platform and CArtAgO framework and their integration is out of the scope of this paper: the interested reader can find details in literature [21, 23] and on Jason 2 and CArtAgO 3 open-source web sites. For the sake of this work, the

232 conceptual space of JaCa can be summarized as the union of the following parts or meta-models: JaCaOrg, to express the architectural description, i.e. the structure of the organization of the agent system; JaCaAgent, to express the agent behavior; JaCaEnv, to express the environment behavior; JaCaDM, to express the data model; and JaCaRT, to express the features of the run time support. 3 Developing an Eclipse-based Agent Development Environment: The JaCa-IDE Currently JaCa, as well as the most part of agent-oriented programming platforms, lacks of adequate tools to support the development and deployment processes, starting from good IDE. A main reason is that as mentioned in the introduction so far, the main perspective on agents and multi-agent systems has been related to theoretical and AI-related aspects, not to theory and, above all, practice of computer programming and software development. Actually, in the context of AOSE (Agent-Oriented Software Engineering), different kinds of modelling tools have been developed, however typically focussed only on the analysis and design stage of the development process. Indeed, the lack of good tools is one of the main issues that curbs the adoption of agent-based technologies outside the mere academics contexts. Accordingly, with the aim of trying to cover this lack of adequate support tools, in this section of the paper we present the results of our efforts in using the Eclipse ecosystem for the realisation of an Eclipse-based IDE for JaCa. In Section 3.1 we first outline the requirements of our IDE inspired by the concepts and needs of the conceptual space introduced by the JaCa platform (Section 2.2) while in Section 3.2 we describe its architecture and main features with respect to such requirements. 3.1 JaCa IDE Requirements The requirements of our JaCa-IDE can be split in two main groups: (i) afirst group of requirements related to features which are common in mostly modern development environments, and (ii) a second group of requirements that are specific to the agent-oriented programming context. In the first group we identify all the features that make a modern IDE worth of that name: (i) the possibility of managing multiple projects related to different applications and the opportunity to explore the content of such projects, (ii) proper file editors providing features such as context-assist, code completion, template proposals, cross-referencing, etc, (iii) a set of useful views that help programmers during their development experience (output views for inspecting the outputs produced by the application, views for representing the outline of structured files, etc.). We need at least all this feature in our JaCa-IDE. In addition a group of agent-oriented specific requirements are also needed. The first one concerns the definition of a proper structure for a JaCa project inside the IDE. Indeed, the abstraction introduced in the JaCa conceptual space 222

233 agents, environment, artifacts, etc. push for a proper agent-oriented project organisation that could not simply mimic the classical OO-based ones. Another specific requirement arise from the possibility to natively define in JaCa: (i) the application topology by properly specifying the set of its workspaces, and (ii) the functionalities offered by each workspace on the base of the artifacts it contains. Hence the IDE should provides a set of specific views and perspectives allowing developers to have a clear representation of such informations. Moreover, since MAS-based applications are intrinsically concurrent and distributed the JaCa-IDE should also provide a group of more advanced and specific features allowing to proper: inspect, profile, deploy, run and debug an agentbased application. All of these are well known, very complex tasks that have been studied from many years in literature in the context of concurrent and distributed systems [2, 13, 16] but, at the best of our knowledge, state of the art tools and development environments offer really low level mechanisms for their management. Instead, we argue, thanks to the high-level of abstraction introduced by JaCa and by MAS more generally, a full-fledged development environment can and also should provides a set of features allowing at least to easily deploy and debug a JaCa application. More specifically the JaCa-IDE debugger should provides mechanisms for easily stopping/suspending/resuming the execution of both agents course of actions and artifacts operations exploiting the high-level concepts and abstractions introduced by the JaCa conceptual space, hence providing more advanced ways for debugging an application than merely placing breakpoints. Making some concrete examples thanks to JaCa abstractions a powerful debugger could allows to: (i) inspect the different parts of a JaCa application, even the one running in remote network nodes w.r.t. the machine from which the application has been launched, (ii) inspect an agent s belief base or agent s intentions (plans in execution), eventually choosing one of them for step by step execution while other ones are carried out in background smoothly and without side-effects, (iii) suspend one or more tasks assigned to an agent simply suspending the related plans, etc. Finally, as a last requirement we mentioned the need of a proper component of the IDE able provide an easy way to run/deploy/un-deploy a distributed application without necessarily requiring, for doing such operations, to operate on each of the distributed machines upon which the application is supposed to be executed. 3.2 The JaCa-IDE Starting from the requirement described in the previous section we realised a first prototype of our Eclipse-based IDE for JaCa. The IDE has been realised con- 223

234 necting an already existing JaCa back-end 4 with a proper front-end 5 developed synergically using two tools part of the Eclipse ecosystem: (i) the Eclipse Plugin Development Environment (PDE) part of the Eclipse SDK [8], and (ii) Xtext, a powerful language development framework [9]. Fig. 2 shows the JaCa-IDE architecture focussing on the dependencies among the various plugin introduced. The jacaide plugin represents the core of our IDE. It has been realised using PDE for defining a set of Eclipse extensions relying on proper Eclipse extension points able to cover most of the features outlined in the previous section. In detail this plugin define: (i) a proper structure for each JaCa application (Fig. 3 (a)), (ii) a custom navigator for showing, besides file system contents, the topology of a JaCa application in terms of workspaces and artifacts contained in such workspaces (Fig. 3 (b)), (iii) a set of wizards for easing the creation of new JaCa projects, new agents and new artifacts, and (iv) a proper connection with the existing back-end for allowing the execution of JaCa applications (Fig. 3 (c)). As depicted in Fig. 2, the jacaide logically depends from the jacaide.xtext.jaca.ui and jacaide.xtext.jason.ui plugins. These represent the file editors automatically generated by Xtext for the languages that we have defined inside the jacaide.xtext.jaca and jacaide.xtext.jason plugins. By referring to the parts of the conceptual space introduced at the end of Section 2, such languages correspond to: JaCaOrg, the language used for defining the organization (structure) of the JaCa applications, in terms of the set of workspaces (along with the network nodes in which they are situated) and the (initial) set of agents and artifacts (Fig. 3 (d)). All this information are contained into a unique file named main.jaca placed in the root of each JaCa application. JaCaAgent, the language used to define the agent behavior, i.e. the Jason programming language (the editor is not shown in the picture). The editors exploit the full power of the Xtext language development framework in order to provide developers full-blown file editors, able to ease their coding experience. Among the features currently supported: syntax highlighting, code completion, cross-referencing and context assist. It is worth remarking that the editor for the JaCaEnv and JaCaDM is directly the JDT, being Java the language adopted in CArtAgO to program artifacts and defining the JaCa data model. To conclude, due to their intrinsic complexities, most of the advanced features related to the second groups of requirements for an agent-oriented IDE has not been fully realized yet. But, before starting a work in this perspective (e.g., by introducing other plugins that can then be linked to the core one using the classic plugin dependency mechanisms) a question arises: is the object oriented metaphor the right one to face the design and development of a full-fledged version of an 4 With the term back-end we refer to the JaCa virtual machine, related runtime data structures and all the others components required for running a JaCa application. 5 With this term we refer instead to GUI tools, editors and all the other support used by a developer for coding a JaCa application. 224

235 Fig. 2. Architecture of the JaCa-IDE. In evidence the plugin dependencies: (i) between the plugins used for defining the Xtext grammars (jacaide.xtext.jaca and jacaide.xtext.jason) and their related file editors (jacaide.xtext.jaca.ui and jacaide.xtext.jason.ui plugins) and,(ii) between the jacaide plugin and the two file editors mentioned before. Fig. 3. The JaCa-IDE in action showing a simple producer-consumer MAS sample project. 225

236 agent-oriented IDE or it is a better idea to ground such an IDE on the agent metaphor itself? This question is the starting point for investigating a deeper integration between the Eclipse ecosystem and the agent-oriented programming world, discussed in next section. 4 Injecting Agents into the Eclipse Ecosystem As depicted in Section 2, the agent-oriented programming paradigm introduces some elements and concepts that are quite radically new with respect to those as found in traditional programming paradigms being them procedural, functional, logic-based or even object-oriented and component-oriented ones and so quite new with respect to the basic abstractions on which the entire Eclipse ecosystem is based. Such elements are along the dimension that concerns the organization of a concurrent/distributed system and in particular the specification of control and behaviour, by introducing high-level coarse-grain concepts inspired to human organizations. Thus, an interesting question that naturally arises is: can the agent conceptual space be useful also within the Eclipse ecosystem itself? We believe that an affirmative answer should be articulated along with different directions and levels, that we start sketching in this section, by showing as some immediate goal can be achieved by properly extending our current, traditional approach by better exploiting a model-driven approach to software construction. 4.1 Towards a Model-driven Approach to Agent-Oriented Programming A first quite obvious direction concerns investigating such agent abstractions to explicitly model, design and finally implement those part of the Eclipse framework that concerns the management of multiple concurrent tasks, possibly exhibiting dependencies that call for a proper coordination and that include also interaction with the user(s) and other applications, eventually exhibiting a responsive behaviour. For this purpose, the use of an agent-based organization alongside a traditional workflow-based approach, could provide more flexibility and a natural approach for investigating the development of adaptive framework, providing self-* capabilities. Then, concepts like activity, task, plan, goal, etc. that are typical of a cooperative environment like RTC/Jazz 6. So, it is possible to envisage a future Eclipse agent-based framework in which a project can be performed as a cooperative work (between human and machines), managed with the help of artificial agents. 6 Jazz is a standard repository usable via network. RTC provides a conceptual space for cooperative working but it provides only features to monitor and visualize the state of the system. For example, the specification of a plan is used to create a time-line picture that shows the current state of the plan. The plan specification is not used to execute the plan as an agent could/should do. 226

237 If it is interesting to investigate how an agent conceptual space could be useful for the Eclipse ecosystem itself, a further point is how. Indeed, the availability of some a-priori defined platform such as JaCaRT can be useful from a practical point of view to integrate the existing technologies; however it does not help in integrating the tools at the conceptual level, allowing for exploiting in a finer and more systematic way such integration. To this end, the JaCaOrg, JaCaAgent and JaCaEnv meta-models can be be used as artifacts able to drive (both in real world and in the IDE world) the design and construction of an agent-oriented software factory. In literature, the definition of meta-models for agent-oriented systems is a core problem in the context of Agent-Oriented Software Engineering, in particular for the definition of agent-oriented methodologies [10, 11, 29]. Various proposals have been already formulated. A recent one is described in [3], which aims at being a common reference meta-model to be exploited by the different methodologies. Another one has been proposed in the context of the OMG, in order to integrate agent-oriented concepts in the context of Service-Oriented Architectures [18]. In our case, the definition of a (custom) meta-model would be the starting point for exploiting in a deeper and more systematic way both the agent-oriented programming approach and an an Eclipse-based agent-oriented framework. From the first point of view, an explicit reference to a custom meta-model could be useful to (i) design and implement further features of the front-end side, extending those described in Section 3, (ii) rethink the design and the implementation of the back-end side, so the runtime/infrastructure that allow for executing JaCa programs and related tools concerning debugging, monitoring, profiling the agent-based applications, by relating in a systematic way the userlevel language with the IDE and the run-time support. From the second point of view, besides rethinking the development of an agent-orient languages with respect to how such languages have been developed so far the model-driven approach can make it easier to build in a structured and systematic way an agent software factory like that described in [17]. More precisely, the injection of a model-driven approach in the agent world, leads us to distinguish different logical layers in our current work: i) a language for the end-user (e.g. some union between JaCaOrg, JaCaAgent and JaCaEnv); ii) an intermediate, abstract language (called here JaCaMed), and iii) a low-level language (called JaCaCore in the following). The intermediate language JaCaMed should define an abstract syntax to capture high-level concepts for agent-systems specification, while the low-level language JaCaCore should capture the conceptual space of an agent-oriented virtual machine, to be implemented on one or more operational platforms. Although the design of the JaCaCore meta-model seems quite difficult, its presence is important, to reduce the abstraction gap between the JaCaMed language and the final operational platform. Moreover, the definition of a formal mapping via a model-to-model (M2M) transformation between the (useroriented) JaCaMed metamodel and the (run-time oriented) JaCaCore metamodel 227

238 is almost mandatory in a field in which the concept of agent is continuously evolving and often in different ways for different application domains. On the one side, the effort to build an explicit representation of (low-level) concepts for agent-based computations could help in finding a common denominator among different approaches and to provide useful supports to build agentbased IDEs or a new generation of cooperative work environments, able to mix human workers and artificial assistants. On the other side, the availability of the meta-model and related Eclipse modeling tools allows for possibly adapting/building the agent languages so as to introduce new features that are not handled by the current technology, but that can be essential for tackling some specific domain problems. Two main examples are planning enhancing agents with the native capability to build the plan to achieve some goal at runtime and learning so as to adapt/refine the plan/action to do the feedbacks received in the past. 5 Conclusion The JaCa-IDE described in the paper will be used as reference tool for the development of JaCa applications both in research and academic projects. This will be important for both easing the development of agent-oriented programs and getting feedbacks for the future extensions and improvements of the IDE. In this paper we provided also a first discussion and conceptual space framing the integration of the Eclipse ecosystem with the abstraction layer provided by agent-oriented programming, exemplified in this case by the JaCa platform. Such a conceptual space is the starting point for investigating in our future work a full-fledge integration of agents into a software factory perspective [17], adopting a model-driven approach to systematize the flexible production of agent-based tools, technologies, applications possibly enriching the Eclipse ecosystem itself. References 1. G. Agha. Actors: a model of concurrent computation in distributed systems. MIT Press, Cambridge, MA, USA, P. Bates. Distributed debugging tools for heterogeneous distributed systems. In Distributed Computing Systems, 1988., 8th International Conference on, pages IEEE, G. Beydoun, G. Low, B. Henderson-Sellers, H. Mouratidis, J. Gomez-Sanz, J. Pavn, and C. Gonzalez-Perez. Faml: a generic metamodel for mas development. Software Engineering IEEE Transactions on, 35(6): , R. Bordini, J. Hübner, and M. Wooldridge. Programming Multi-Agent Systems in AgentSpeak Using Jason. JohnWiley&Sons,Ltd, R. H. Bordini, M. Dastani, J. Dix, and A. El Fallah Seghrouchni. Special Issue: Multi-Agent Programming, volume 23 (2). Springer Verlag, R. H. Bordini, M. Dastani, and A. El Fallah Seghrouchni, editors. Multi-Agent Programming Languages, Platforms and Applications (I), volume 15. Springer,

239 7. R. H. Bordini, M. Dastani, A. El Fallah Seghrouchni, and J. Dix, editors. Multi- Agent Programming Languages, Platforms and Applications (II). Springer, Eclipse. Plugin development environment (pde) official website, Eclipse. Xtext official website, B. Henderson-Sellers and P. Giorgini. Agent-oriented methodologies. Idea Group, C. A. Iglesias, M. Garijo, and J. Centeno-González. A survey of agent-oriented methodologies. In Intelligent Agents V, ATAL 98,pages ,London,UK, Springer-Verlag. 12. N. R. Jennings. An agent-based approach for building complex software systems. Commun. ACM, 44(4):35 41, J. Joyce, G. Lomow, K. Slind, and B. Unger. Monitoring distributed systems. ACM Transactions on Computer Systems (TOCS), 5(2): , W. A. Kornfeld and C. Hewitt. The scientific community metaphor, MIT Artificial Intelligence Laboratory. 15. H. Lieberman. The continuing quest for abstraction. In ECOOP 2006, volume 4067/2006, pages Springer, C. McDowell and D. Helmbold. Debugging concurrent programs. ACM Computing Surveys (CSUR), 21(4): , A. Natali. Model-driven communications and collaborative software development, DEIS internal report, University of Bologna. 18. OMG. Agent platform special interest group official website, A. Omicini, A. Ricci, and M. Viroli. Artifacts in the A&A meta-model for multiagent systems. Autonomous Agents and Multi-Agent Systems, 17 (3), Dec A. S. Rao. AgentSpeak(l): BDI agents speak out in a logical computable language. In MAAMAW 96, volume1038oflecture Notes in Computer Science, pages Springer, A. Ricci, M. Piunti, L. D. Acay, R. Bordini, J. Hübner, and M. Dastani. Integrating Artifact-Based Environments with Heterogeneous Agent-Programming Platforms. In AAMAS 08, pages , A. Ricci, M. Piunti, and M. Viroli. Environment programming in multi-agent systems: an artifact-based perspective. Autonomous Agents and Multi-Agent Systems, 23: , A. Ricci, M. Piunti, M. Viroli, and A. Omicini. Environment programming with CArtAgO. In R. Bordini, M. Dastani, J. Dix, and A. El Fallah Seghrouchni, editors, Multi-Agent Programming: Languages, Tools and Applications. Springer, A. Ricci and A. Santi. Agent-oriented computing: Agents as a paradigm for computer programming and software development. In Proceedings of Future Computing IARIA, Y. Shoham. Agent-oriented programming. Artificial Intelligence, 60(1):51 92, B. C. Smith and C. Hewitt. A plasma primer, MIT Artificial Intelligence Laboratory. 27. H. Sutter and J. Larus. Software and the concurrency revolution. ACM Queue: Tomorrow s Computing Today,3(7):54 62,Sept M. D. Travers. Programming with Agents: New metaphors for thinking about computation. MassachusettsInstituteofTechnology, M. Wooldridge and P. Ciancarini. Agent-oriented software engineering: The state of the art. pages Springer-Verlag,

240 An Eclipse Plug-in to Model System Requirements and Adaptation Capabilities Luciano Baresi and Liliana Pasquale Politecnico di Milano - Dipartimento di Elettronica e Informazione p.zza L. da Vinci, 32, Milano (Italy) {baresi pasquale}@elet.polimi.it Abstract. Requirements elicitation is an important phase of the software life-cycle, since it helps to reduce the software development time and costs. Unfortunately, existing tools for software design are mainly focused on building a solution (i.e., the software system), and neglect the elicitation and analysis of the stakeholders requirements. Besides, systems are constantly required to adapt to cope with the variability of the environment in which they operate. For this reason, self-adaptation must be also taken into account during requirements elicitation.this paper proposes a graphical designer to express the conventional (functional and non functional) requirements together with the adaptation capabilities of the system. It has been developed as an Eclipse plug-in and leverages other Eclipse projects, such as EMF [1], GMP [2] and Xtext [3], which helped us to make the designer usable and extensible. 1 Introduction Requirements elicitation is a delicate phase in the software development process. If requirements are not captured completely and unambiguously, IT projects would experiment delivery delays and overrun costs. For this reason, it is fundamental to provide requirements engineering (RE) tools to enable the software designer to express and manage the requirements after their definition. Unfortunately, existing tools are mainly focused on aiding the designers to build a solution (i.e., the software system), and neglect a rigorous analysis of the requirements of the stakeholders. Besides, the RE process would not be effective enough if the designer just takes into account the conventional functional and non functional requirements. As a matter of facts, many software systems need to self-adapt to cope with the variability of the environment in which they operate. Variability may be due to requirements violations, context changes, or modifications of the business objectives of the stakeholders. For this reason, self-adaptation becomes a requirement per-se and must be related to the other conventional requirements of the system. This paper proposes a graphical tool, the FLAGS Designer, to aid software designers to elicit and represent the requirements of self-adaptive systems. Our tool is based on the FLAGS (Fuzzy Live Adaptation Goals for Self-Adaptive 230

241 Systems) [4] modeling notation. FLAGS generalizes the existing KAOS [5] model, adds adaptation goals to embed adaptation countermeasures, and fosters selfadaptation by considering requirements as live, runtime entities. The adoption of a goal model allows us to represent the requirements in a hierarchical way, by refining high-level goals into system requirements and operations. Adaptation goals embed the adaptation actions (i.e., changes in the model) to be performed if one or more goals are not fulfilled satisfactorily. The execution of an adaptation goal at runtime depends on the satisfaction level of related goals and the actual conditions of the system and of the environment. Finally, to pursue the alignment between requirements and the running systems, and delegate decisions about adaptation to the goal model, FLAGS proposes to turn goals into live entities, as suggested by Kramer and Magee [6]. Requirements modeling has been always tedious, since the size of the model can grow easily, making it unmanageable. For this reason, FLAGS divides the requirements model in different views (domain, goals, operations, and adaptation). Each view may contain a portion of the model to make it more understandable and reduce its complexity. FLAGS also proposes a suitable language that specifies goals as fuzzy constraints that quantify the degree x (x [0, 1]) to which a goal is satisfied/violated. As for goals satisfaction, a crisp notion (yes or no) would not provide the flexibility necessary in systems where some goals cannot be clearly measured (soft goals), and small/transient violations must be tolerated. The FLAGS Designer supports the creation of new instances of the FLAGS model and provides some preliminary mechanisms to convert the elements of the model into runtime entities. It provides a nice and intuitive graphical interface that makes possible for non-practitioners to create and manage FLAGS models with a minimal effort. Finally the FLAGS Designer offers suitable mechanisms to represent requirements at runtime and assess their satisfaction. A first prototype of the FLAGS Designer has been developed as an Eclipse plug-in 1 and distributed under GNU GPL 3 license. It leverages other Eclipse projects, such as EMF (Eclipse Modeling Framework) [1], GMP (Graphical Modeling Project) [2] and Xtext [3], which helped us to make the designer usable and extensible. The first release of the FLAGS designer has been successfully employed to model the requirements of real cases study in the health care domain. In particular it has been used to model a set of safety-critical surgical actions (i.e., puncturing, suturing, cutting) for the ISUR European Joint project [7]. The rest of the paper is structured as follows. Section 2 motivates our design choices. Section 3 illustrates how the FLAGS Designer supports the creation of new instances of the FLAGS model through a running example. Section 4 discusses some related work. Section 5 concludes the paper. 2 The Overall Solution The FLAGS Designer has ben created to satisfy a certain set of requirements. It must support the creation and management of new or existing instances of the 1 The graphical designer is publicly available at 231

242 FLAGS model, including their views. These model instances must comply with a set of consistency rules (e.g., a goal cannot refine itself), while the definition of goals must conform to the FLAGS language. Since golas are conceived as runtime entities it is also necessary to trace them into live objects and assess their satisfaction at runtime. Besides, we require that both domain experts and non-practitioners be able to define new instances of the FLAGS model with the minimal effort. Finally, requirements models and notations are in continuous evolution, and, for this reason, the FLAGS Designer must be extensible. The FLAGS Designer has been released as an Eclipse plug-in. A plug-in is a module that may be used by other plug-ins, or be combined with other plugins on the same Eclipse platform, or be extended by other plug-ins. This choice supports the reusability and extensibility of the FLAGS Designer and allows us to exploit other plug-ins (EMF, GMP, and Xtext) to reduce the release time of our solution. We also decided to develop the FLAGS Designer according to the MDA (Model Driven Architecture) principles to easily turn goals into runtime entities. In particular, we defined the FLAGS model through EMF, which enables the automatic translation of the model into correct and easily customizable Java code. EMF also allows us to annotate the model with suitable OCL (Object Constraint Language) [8] constraints to forbid the creation of instances of the FLAGS model that violate its consistency rules. GMP greatly helped us to develop a user-friendly graphical interface. GMP provides a set of generative components and runtime infrastructures for developing graphical editors based on EMF. One can generate a graphical editor, by simply creating a tooling, graphical and mapping model definition. The interface of the FLAGS Designer is intuitive: the elements of the model can be created by drag and dropping them from a palette, while links can be added by connecting two elements in the model. Finally we used Xtext to define the syntax of the FLAGS language. Xtext allows us to automatically derive a parser that recognizes a FLAGS formula and generates its corresponding AST (Abstract Syntax Tree). We modified the visit algorithm of the AST to derive the monitors that check the satisfaction of the corresponding goal at runtime. 3 The FLAGS model This section describes how the FLAGS Designer supports the creation of new instances of the FLAGS model, including their different views (i.e., domain, goals, operations and adaptations). The domain view represents the environment in which the system operates. The goals view expresses the requirements of the system and links them to the operations necessary for their achievement. The operation view represents the operations of the system. The adaptation view describes the adaptations that must be performed if some conditions are satisfied (e.g., goals are violated, certain events takes place). As presented in Figure 1, the graphical interface of the FLAGS Designer is composed of three areas. The Diagram (1) shows one of the view the designer is currently creating, the Palette (2) contains the elements (Nodes, Links, and 232

243 Compartments) that can be drag and dropped in the diagram, and the Properties View (3) allows the designer to visualize and edit the properties of an element, which has been selected in the diagram. Note that the elements of the model can be divided in three categories: Node, Compartments and Links. Node are the main elements of the FLAGS model, such as goals, adaptation goals, operations, and so forth. Links represent all possible connections between the elements of the model (e.g., an operationalization is a link between a goal and an operation). The Compartments correspond to other additional properties of an element of the model (e.g., the definition of a goal) Fig. 1. The Goal model for the puncturing case study. In the following we describe how the FLAGS Designer supports the creation of all different views of a model. As an example, we refer to the FLAGS model we used to represent the puncturing in the percutaneous cryoablation. This surgical action is used to destroy small cancers located on the surface of the kidney and comprehends three phases. First, one or more needles must be inserted in the tumoral mass, then an iceball must be created by injecting hydrogen in the cancer through the needles, and, finally, all needles must be extracted after the iceball is defrosted. 3.1 The Domain View The elements of the domain may belong to one the following types: entity, event, or agent. Both entities and events can be characterized by simple attributes (e.g., 233

244 int, string) or may refer to other entities/events already defined in the model. Attributes and references also have a cardinality (e.g., at most one, exactly one, some, any). Entities are objects providing an informative content and may evolve through a set of states, when one or more operations are performed. The state of an entity is determined by the value assumed by its attributes. Events are instantaneous objects, corresponding to something that may happen during the execution of the system. Agents can be software components, external devices and humans in the environment, responsible for the satisfaction of some goals. Agents can monitor and control entities and events in the environment and may be responsible for the realization of a goal, depending on the objects they can monitor/control. Fig. 2. A subset of the entities of the domain of the puncturing case study. Figure 2 provides a subset of the domain model for the puncturing case study. From Figure 2 we can see event Move Performed and entities Tumor, Point and Voxel. In our example, we did not model agents since our main focus is on automating a surgical action, instead of reasoning on the responsibility of different agents. Entities are characterized by three groups of compartments: the first one identifies the states through which an entity can transit, the second one detects the attributes, and the last one contains the references to other entities/events in the model. Since events do not have a state, they are just characterized by the last two groups of compartments. Event Move Performed is generated every time a needle moves, either because it is being inserted or it is being extracted. It is described by a set of attributes: the needle that has been moved (needle), the time at which the movement took place, the direction of the movement (-1 if the needle is inserted or 1 if the needle is extracted), the distance covered by the needle, and the stiff- 234

245 ness perceived during the movement. Event Move Performed has also reference point which indicates the arrival point of the movement. Entity Point is just characterized by its coordinates (x, y, and z) and does not have a state. A Tumor is characterized at most by a center (reference to a Point) and a surface (i.e., a set of Voxel 2 ). Entity Tumor may pass through state empty, whenits surface and center has not been detected yet, and defined, when its surface and center is detected through an ultrasound scan. 3.2 The Goal view The Goal view defines the main objectives the system should meet. Goals can be refined into several conjoined subgoals (AND-refinement) or into alternative combinations of subgoals (OR-refinement). The satisfaction of the parent goal depends on the achievement of all (for AND-refinement) or at least one (for OR-refinement) of its underlying subgoals. The refinement of a goal terminates when it can be operationalized, or, in other words, it can be associated with a set of operations. All goals that cannot be refined anymore are called leaf goals and represent the requirements of the system. Goals are formally expressed in terms of crisp or fuzzy properties and are associated with a priority depending on their criticality. Fig. 3. Decomposition of goal G1.2 for the puncturing case study. 2 A voxel is a volume element, representing a value on a regular grid in three dimensional space 235

246 Fig. 4. The definition of goal G Figure 3 partially shows the goal view of the puncturing, where each goals is characterized, on top, by its name and description. In particular, it shows goal G1.2 (Execute puncturing) that can be decomposed (AND-refinement) into 3 sub-goals. First, all necessary needles must reach a specific position in the tumoral mass (G1.2.1). When all needles have been inserted, the ablation cycle must be performed (G1.2.2). After an iceball has been created, the doctor must verify whether the tumor has been completely destroyed (G1.2.3). In its turn, goal G1.2.1 can be further AND-decomposed into goals G , G and G G specifies that all the needles must be inserted in the tumoral mass. G asserts that every time a movement is performed the needle must not touch forbidden regions, such as ribs or nerves. G states that only one needle can be active at each time instant. Fig. 5. OCL constraints defined on the FLAGS model. 236

247 The Properties view allows the users to configure other additional attributes of a selected goal, such as its description, priority, whether it is a leaf goal or not, or its operations (in case of a leaf goal). For example, Figure 3 shows the properties view of G , which is a leaf goal (attribute leaf is true) and has the maximum priority (i.e., 5) since it is one of the most important goals to achieve. The operations associated with G are Insert, Signal Needle Extracted, and Select Needle, which we will explain in detail in the following subsection. Each leaf goal has one compartment composed of some sub-compartments. The first sub-compartment contains the definition the goal, which is specified in the FLAGS language and may use some variables that refer to other elements of the FLAGS model. For example, Figure 4 shows the definition of goal G , which asserts that every time a movement is performed (variable mp), no forbidden region must be touched (variable fr) by that needle. The other sub-compartments represent the mapping between the variables used in the definition and the elements of the FLAGS model. For example, variables mp and fr refer respectively to event Move Performed (as shown in Figure 4), and event FR TouchedEv. Figure 5 presents some OCL constraints specified for the FLAGS model. For example, in the first group we assert that a leaf goal cannot be refined by other goals (isleaf ), while the second constraint asserts that a goal cannot refine itself (i.e., it cannot be in both attributes myfather and target of a refinement link). 3.3 The Operation view The Operation view describes the operations of the system. An operation is an input-output relationship over a set of objects. Operations are specified depending on their effects on the domain: domain pre- and post-conditions (DomPre and DomPost). A domain pre-condition characterizes the state before applying the operation, a domain post-condition defines a relationship between the state before and after applying the operation. Operations are also specified through required pre-conditions (ReqPre), triggering pre-conditions (TrigPre) and required post-conditions (ReqPost). Required pre-conditions define those states in which the operation is allowed to be applied. Triggering conditions define those states in which the operation must be immediately applied, provided the domain precondition is true. Required post-conditions define additional conditions the application of an operation must satisfy. Figure 6 represents some operations of the FLAGS model of the puncturing: Select Needle Insert, Insert, and Signal Tumor Reached 3. Operation Signal Tumor Reached is triggered every time a needle is moved (see TrigPre compartment), under the condition that the point in which the needle is positioned equals the target point on the cancer (see DomPre compartment). This operation generates event Tumor Reached that refers to the same needle that has been previously moved (see ReqPost). This operation causes a change of state for entity 3 For reasons of space we just enlarged the compartments of operation Signal Tumor Reached 237

248 Needle that transits from state inserting to state positioned (see DomPre and DomPost compartments). This Properties View allows to configure other additional attributes of an operation, such as its input and output entities/events,, a descriptions and a minimum and maximum time it can be executed. Fig. 6. A subset of the operations of the puncturing case study. Note that all pre- and post-conditions are represented through a suitable compartment. Each of these compartments is composed of one sub-compartment that contains the definition of the pre- or post-condition (expressed in the FLAGS language) and other sub-compartments that map each variable used in the definition of the pre- or post-condition with an entity/event in the domain model. 3.4 The adaptation view Adaptation goals define the adaptation capabilities embedded in the system at requirements level. They are characterized by a condition and a trigger. A condition specifies a set of properties of the system (e.g., satisfaction levels of conventional goals, adaptation goals already performed) or of the environment (e.g., constraint on the domain) that must be true to activate an adaptation 238

249 goal. A trigger is associated with one or more events that activate the execution of the adaptation goal if the corresponding conditions are satisfied too. Fig. 7. Adaptation goal FR Touched. Adaptation goals are associated with a set of actions to be carried out when adaptation is required. These actions can simply change the way goals are achieved, by performing some goals/operations, without modifying the existing FLAGS model, or, alternatively, they can modify the model, by, for example, adding/removing goals and operations. Adaptation goals also have a priority to select one among different adaptations that may be triggered at the same time. Figure 7 shows adaptation goal FR Touched, which is performed to achieve goal G1.2.1 even if a needle touches a forbidden region. In this case, the needle is extracted and inserted again in a different position. The properties view allows the users to configure a set of attributes of an adaptation goal, such as the goal it helps (G1.2.1 in the example), its priority (i.e., 3) and the adaptation actions to be performed. The trigger and conditions are represented through two compartments. The structure of each compartment is similar to that used to express the pre- and post-conditions of the operations. Adaptation goal FR Touched is triggered by events Move Performed and event FR TouchedEv. They indicate that adaptation is performed after a needle is moved and a forbidden region has been touched. The condition verifies that the event FR TouchedEv refers to the 239

250 same needle that performed the movement (fr.needle == fr.needle), and the needle is being inserted (mp.direction = 1). As shown in Figure 8, this adaptation goal is operationalized through two adaptation actions: perform operation Extract And Reset and perform goal G Operation Extract And Reset has been added only for adaptation purposes. It extracts the needle that touched a forbidden region and changes its configuration parameters. Action perform goal G1.2.1 re-performs the operations associated with goal G1.2.1 (e.g., a needle can be selected again to be inserted) to enforce its satisfaction. Fig. 8. Adaptation action perform operation Extract AND Reset. 4 Related Work In our previous work [9] we already compared the FLAGS model with other approaches used to represent the requirements of self-adaptive systems. FLAGS is one of the most expressive models that is able to represent almost all features of a feedback loop. Differently from the other modeling approaches, FLAGS also supports the evolution of the system by offering the possibility to change the requirements model at runtime. Other tools [10,11] have been already provided to model and manage the requirements of the system. Objectiver [10] is a graphical designer to create and manage the requirements expressed according to the KAOS methodology. Objectiver does not provide support to model the adaptation capabilities of the system or transform goals into runtime objects. Instead, it focuses on the requirements elicitation and can transform the KAOS model into textual requirements documents conforming to existing standards, such as the IEEE Software Requirements Specification (IEEE ). TAOM4E [11] relies on the TROPOS [12] methodology to translate early requirements into the code of BDI (Belief-Desire-Intention) agents. The tool has been released as an Eclipse plug-in by the Software Engineering group at FBK IRST in Trento. Similarly to the FLAGS Designer, TAOM4E is a research 240

251 prototype that has been designed according to the MDA principles. Despite these commonalities, the FLAGS Designer has a different objective, since it is aimed to collect requirements to engineer the feedback loop. 5 Conclusions This paper describes an eclipse plug-in to design and manage the requirements of the system together with its adaptation capabilities. This is still a preliminary solution towords the final objective of providing a complete transformation of requirements into the code of the feedback loop and support the evolution of requirements at runtime. The adoption of other existing Eclipse projects, such as EMF, GMP, and Xtext, aided the development process and fostered the usability and extensibility of the FLAGS Designer. The FLAGS Designer is still in its first release and needs further improvements. The users must be guided during the design of the requirements and must receive suggestions regarding the parts of the model that still need to be defined. In this first release the correctness check of the goals definition has not been integrated with the rest of the designer and must be performed separately. In this phase we have just provided support for the automatic generation of monitors [13] that assess the satisfaction of fuzzy requirements at runtime. However to achieve the final objectives of engineering the feedback loops, we also need to provide automatic mechanisms to convert adaptation goals into adaptation actions that are activated at runtime, when necessary. References 1. Eclipse Modeling Framework Project (EMF). modeling/emf/ 2. Graphical Modeling Project (GMP) Xtext Language Development Framework Baresi, L., Pasquale, L., Spoletini, P.: Fuzzy Goals for Requirements-Driven Adaptation. In: Proc. of the 18th Int. Requirements Engineering Conf., (2010) van Lamsweerde, A.: Requirements Engineering: From System Goals to UML Models to Software Specifications. John Wiley (2009) 6. Kramer, J., Magee, J.: Self-Managed Systems: an Architectural Challenge. In: Proc. of Future of Software Engineering. (2007) ISUR Project Website Object Constraint Language Version Pasquale, L.: A Goal Oriented Methodology for Self-Supervised Service Compositions. PhD thesis, Politecnico di Milano (2011) 10. Objectiver Fondazione Bruno Kessler: Tool for Agent Oriented Modeling TAOM4E. http: //selab.fbk.eu/taom/ 12. Fuxman, A., Liu, L., Mylopoulos, J., Pistore, M., Roveri, M., Traverso, P.: Specifying and Analyzing Early Requirements in TROPOS. RE 9(2) (2004) Pasquale, L., Spoletini, P.: Monitoring Fuzzy Temporal Requirements for Self- Adaptive Systems: Motivations, Challenges and Experimental Results. In: Proceedings of SOCCER 11. (2011) (to appear) 241

252 An eclipse-based Feature Models toolchain Luca Gherardi, Davide Brugali Dept. of Information Technology and Mathematics Methods, University of Bergamo Abstract. Feature models are used in software engineering for modeling all the possible configurations of the software of a specific domain. They capture the commonalities and the variabilities among these software and offer a formalism to clearly represent these properties in a separate way. Features represent end-user characteristic of the software and can be optional or mandatory. A selection of a number of these features defines one specific configuration of the software and could be used for example for configuration purpose. Along the years, at least two extensions of the feature models have been proposed in order to improve the original proposal, but only few attempts of providing a set of graphical tools can be found in literature. Moreover some of those are not open source. In this paper we propose a tool chain completely based on the Eclipse Modeling Framework and the Graphical Modeling Framework. It consists of: (i) a meta-model that describes the rules for defining feature models, (ii) a graphical tool for creating feature models and defining constraints between the features, (iii) a graphical tool for selecting one possible configuration and checking if it satisfies all the constraints. 1 Introduction Feature models were introduced for the first time two decades ago and are today widely spread in the context of the Software Product Lines [13]. They are really generic and for this reason they can be used in various different fields. In this paper we describe the meta-model and the tools that we have designed in the context of the European project BRICS [1] in our attempt of introducing feature models in the robotics field. Despite our work is more focused on robotics, in the paper we will keep our attention on the feature models and we will use a generic example because it allows us to describe the feature models without having to introduce a number of terms that are specific of the robotics field. In the description of the tools we will show a more complex example related to the robotics field without going into details of the meaning of the terms. Feature models are a useful formalism, which allows the developers to model and define all the possible configurations of a family of software in such a way that is independent from the implementation mechanism. These configurations share a set of properties and functionality (aka features) that are always present 242

253 in the software of the specific domain and that are called commonalities. On the other side some features are present only in some specific configurations and so they define a subset of the domain. They are called variabilities. Feature models capture these commonalities and variabilities among a family of software and offer a method to clearly represent them in a separate way. Feature models are typically used in two phases of the software development process: During the specification of the requirements they allow the designers to define which configurations of the software will be supported by the product line. In this stage they give to the designers a view on the entire family of systems. During the composition of the software instead, they allow the developers to select a particular configuration of the system and so they provide a view on a specific application. In this stage it is particularly interesting the use of the defined configuration as input for an automatic toolchain, which is in charge of deploying the final product. The two stages of the development process also suggest two different users of these models: the system designer and the application developer. The first one is in charge of designing the models and defining the allowed configurations. The second one instead has the role of selecting one available configuration and developing the corresponding application. The work described in this paper is part of a work package of the BRICS project that aims to provide a set of tools that allow the management of the software variability in robotics. In particular our final goal is to make as easier as possible the process of designing and transforming feature models in order to realize an input for the application deployer. That means to provide to the system designers and the application developers with the possibilities of specifying all the possible configurations, selecting one of them, transforming it in a configuration file and finally easily deploying the desired application. For achieving this goal we have to model the variability from three different points of view: Variability specification. That means describing which are the variabilities of a system (variation points) and how they can be solved (variants). Variability implementation. That means specifying how the different variants will be implemented in the final applications in terms of architectural elements. Variability resolution. That means defining a function that maps each variant to one or more architectural elements. In this paper we focus on the first point and we propose two completely eclipse-based tools that allow the specification of the variability through the use of the feature models. We started the implementation of a new plugin because no one of the open source eclipse-based tools that we analyzed provides all these features: 243

254 Conformity to the standard specification of the feature models that was defined in literature (see section 2) for what regards the features, the containments and the constraints. The presence of a graphical tool that allows the system designers to define feature models in form of feature diagrams in a simple and user-friendly way. The presence, in the same graphical editor, of a functionality that allows the application developers to select one available configuration directly from the same feature diagram defined by the system designer. In particular for what regards the last point we found out that most of the available plugins allow the selection of a configuration only by using a tree-view of the model or by recreating a new feature diagram in which the user has to insert some of the features defined in the feature model. Let s think about a use case in which the model defines more than hundred features. In that case those ways of selecting configurations can be very uncomfortable since the user doesn t have a complete view of the available features and of the structure of the model. In our opinion it would be more user-friendly and quick reusing the diagram defined by the system designer and having a toolbar button that allows the selection of the features that have to be included in the configuration. During the development of our plugin we tried to take in account all these points and at the same time to keep the graphical interface and the feature model design flow as simple as possible. The paper is structured as follows. Section 2 describes the fundamental concepts of the feature models and their extensions that have been proposed along the years. Section 3 briefly presents some attempts of providing eclipse based feature model tools. Section 4 describes the tools that we have developed and in particular the meta-model on which they are based. Finally section 5 draws the relevant conclusions. 2 Feature Models Feature models were proposed for the first time in 1990 in the context of the Feature Oriented Domain Analysis (FODA) approach [15]. FODA aims to identify the properties and the functionality of a software, which are commonly present in applications of a specific domain, and separate them in two groups: those that are always present and those that are present only in some applications. For representing these properties and functionality FODA proposes a formal method: the feature model. In this section we will describe its original proposal and the two major extensions that were proposed along the years. 2.1 Basic Feature Models A feature model is an hierarchical composition of features. A feature defines a software property and represents an increment in program functionality [10]. Compose features, or in other words select a subset of all the features contained 244

255 in a feature model, corresponds to define a possible configuration of a software that belongs to the application domain described by the model. This selection is usually called instance. On the base of the feature models, the FODA experts have defined a graphical representation called feature diagram. In this section we will refer to the feature diagram depicted in figure 1 in order to exemplify the characteristics of feature models. The diagram describes the functionality of a family of geographical maps websites. Geographical Maps Web Site User access View Directions Zoom in/out Read only Read and edit Map Hybrid Satellite Fig. 1. An example of Feature Diagram of a geographical maps website Feature models are organized as a tree and the root feature, also called concept, defines the application domain. Features are represented by means of white boxes, which contain the feature names, and are connected to the children features by means of edges, which represent containment relationships [9]. Features can be discerned in two main categories: Mandatory. Mandatory features have to be present in every possible configuration of a software that belongs to the domain described by the model. They usually define the core of the software and represent functionality or properties that are fundamental in the specific domain: the commonalities. In the feature diagrams they are depicted by means of a black circle on the top. In the example the Zoom in/out functionality is a mandatory feature. Every maps website in fact allows the user to execute zooming operations in order to explore the maps. Optional. Optional features can be present but they are not mandatory. They represent functionality or properties that characterize a specific configuration of the software: the variabilities. In the feature diagrams they are depicted by means of a white circle on the top. In the example the Directions functionality is an optional feature, which means that not all the maps websites provide it. 245

256 Features can be connected to their children features by means of three types of containment relationships: One-to-one containment. It is the simplest relationship and it means that the parent feature can (or has to) contain the child feature. In the example it is represented by the containment between the root and the Directions feature and by the containment between the root and the Zoom in/out feature. Or containment. It is a relationship between the parent feature and a set of children features. It means that from the children features at least one has to be present in a possible configuration of the software. In the example it is represented by the containment between the View feature and its children. This relationship is depicted by means of the black semi-circle that connects the edges. Alternative containment (X-Or). It is a relationship between the parent feature and a set of children features. It means that from the children features only one can be present in a possible configuration of the software. In the example it is represented by the containment between the User access feature and its children. This relationship is depicted by means of the white semicircle that connects the edges. The basic feature models also define two kinds of constraints between the features: requires and excludes. These constraints allow the definition of a subset of valid configurations. They are typically expressed in the form A kind of constraint B, wherea and B can be a simple feature or a composition of features by means of logical operators (AND, OR, XOR, NOT). Requires constraint. It means that if a feature A is selected to be part of a configuration, then also a feature B has to be selected. If A and/or B represent logical rules the constraint imposes that if A is true, then also B has to be true. To be noticed that for solving the logical rules the value of a feature has to be considered true if the feature is selected. Excludes constraint. It means that if a feature A is selected to be part of a configuration, then a feature B cannot be selected. If A and/or B represent logical rules the constraint imposes that if A is true, then B has to be false. 2.2 Cardinality-Based Feature Models The cardinality-based feature models propose to replace the properties optional and mandatory and the containments or and alternative with a cardinality-based annotation. In particular these ideas are proposed in two different works: [14] proposes a feature-cardinality approach. The idea consists of marking each feature with a lower bound and an upper bound. The upper bound defines the maximum number of times that the feature can be present in an instance. 246

257 [16] proposes a containment-cardinality approach. The idea consists of marking each containment with a lower bound and an upper bound. The lower bound defines the minimum number of sub-features that have to be present in an instance whereas the upper bound the maximum number. According to this approach the containment relationships or and alternative are respectively replaced by [1... ] and [1...1]. 2.3 Extended Feature Models The extended models propose to attach some information to the features by means of attributes [14]. The purpose of the attributes is to allow a more concise representation of feature models. In fact the idea is to use the attributes for representing information that are important but not so relevant to be represented as features. Attributes are defined by means of a name, a type and a value. 3 Related Works Despite along the years feature models have gained popularity, only few attempts of providing a set of tools, which support the design of these models, can be found in literature. Moreover some of those are not open source. In this section we will focus on the eclipse-based tools, because with respect to the standalone tolls they can be more easily integrated with other tools. From this point we will use the term graphical editor for defining an editor which allows the representation of the feature models in form of feature diagrams (see figure 1). The Eclipse Modeling Framework Technology project (EMFT)[4], which aims to provide a set of new tools that extend or complement the Eclipse Modeling Framework (EMF)[2], proposes a feature model plugin called EMF Feature Model [3]. This plugin is still in the incubation stage and it is based on two meta-models. The first one describes the rules for modeling the variability and designing feature models, whereas the second the rules for creating instances of the feature models. The major drawback of this plugin is the dependency to pure::variants [11] for providing a graphical representation and the constraints evaluation. Pure::variants is another well done plugin but we avoided using it due to the commercial license. Indeed, it is free available only in a limited version. Another interesting plugin, which is still in development, was designed at the university of Waterloo [6]. In contrast to the proposal of [3], this plugin uses a single meta-model for representing both the feature model and its configurations. They provide an XPath support for the definition of the constraints and also a constraints evaluation engine. This plugin is completely open source but it doesn t provide a graphical editor. The P&P Software GmbH and the ETH-Zurich developed an open source feature model plugin called XFeature [12]. This plugin provides a graphical editor, an XPath constraints definition support and a constraints evaluation engine. The editor is in general very complete but in our opinion the editing of the feature model is not really user friendly. For example a tools palette is not provided 247

258 and the user has to edit the model by continuously using the context menu. Furthermore the plugin allows the users to define an instance only by creating a new feature diagram in which only the features defined in the feature-model can be inserted. Finally one of the most complete and open source plugin that we found in literature is FeatureIDE [5]. It provides a lot of functionality, for example a graphical editor which is compatible with the standard notation (as far as we know it is the only one), a statistics view that collects information about the number of features, the number of variants and the number of possible configurations and last but not least the possibility of comparing the current version with the last saved version in order to reason about how the changes in the model will affect the product line. Despite this editor is very complete, in our opinion it has some drawbacks: (i) like the previous plugin it doesn t provide a tools palette for editing the model, (ii) it provides a tree representation for the definition of the feature model instances but it doesn t allow the users to do this operation by using the standard feature diagram representation, which is more intuitive, (iii) it doesn t explicit allow the definition of the exclude constraint (the workaround is defining A excludes B in the form not (A and B) ). 4 The meta-model and the tools The tools that we are going to propose in this section are based on the Eclipse Modeling Framework (EMF) and on the Graphical Modeling Framework (GMF) [7]. EMF and GMF are two eclipse projects that allow the development of domain specific languages (DSLs) and graphical editors for their visual representation. Every DSL is based on a set of rules that are defined by means of a formal meta-model. During the development of the eclipse plugins these meta-models are typically expressed through the Ecore format [17], which is a small and simplified subset of UML. 4.1 The Feature Meta-model Figure 2 depicts the Ecore meta-model that represents the core of our tools. Due to the fact that it was designed by following the feature models specification, which is a standard, it is quite similar to the meta-models of other tools presented in the previous section. The root entity of this model is the class FeatureModel. Itrepresentsthe feature model and contains a set of Features, Constraints and Instances. Feature. The features are defined by a name and by the boolean attribute required. When its value is true the feature is mandatory, otherwise the feature is optional. Features also have another boolean attribute (root, true only for the root feature) and two integer attributes (lowerbound and upperbound) which allow the definition of the feature cardinality (see sub-section 2.2). Finally features contain Attributes, CompositeFeatures and the sub-features that are their direct children (one-to-one containment). 248

259 Fig. 2. The Meta-Model Attribute. The attributes are defined by a name, a type and a value. They allow the representation of the extended models (see sub-section 2.3). CompositeFeature. The composite features are used for representing the group containments. They are defined by two integers (lowerbound and upperbound) that allow the representation of the standard containments (alternative and or) and of the cardinality containments. The composite features contain the features that are part of the containments. Constraint. The constraints are defined by a name and a rule. The rule is a string and it is composed of two members separated by the Constraint- Type, which can assume two values: requires or excludes. The members can be defined as any possible logical combination of the features. Instance. The instances represent a possible configuration of the model and are defined by a name and a description. An instance contains references to the features that are selected for being part of the configuration. More instances can have references to the same feature. The presented model defines the rules for creating feature models that are conforming to the specification described in the section 2. After having defined this model in EMF, it is already possible to create feature models by means of a simple tree-view editor. In the following sub-section we will introduce the editor that we have developed in order to provide a graphical representation. 249

260 4.2 The feature model editor The feature model editor allows the creation of feature models that are conforming to the meta-model presented in the previous sub-section. It is a graphical editor realized by means of the eclipse GMF tools. Figure 3 depicts the editor and shows how the feature models are represented. The figure reports a feature model that describes the possible configurations of a motion planning software. It is a software that involves different functionality in order to plan a path for moving a robot along a collision free trajectory. Fig. 3. The feature model Editor The graphical representation is conforming to the standard convention of the feature diagrams, except for the group containments. In particular we represent the different entities defined in the model in the following way. Features are represented by means of a white box that contains the name of the feature. The blue box represents the concept (root feature). Mandatory features are represented by means of a black circle on the top whereas optional features by means of a white circle. Group containments are represented by means of a grey box that shows the lower and the upper bound of the cardinality. Attributes are represented by means of a cyan box that contains the name of the attribute. The editor also provides the possibility of defining constraints by means of the dialog window depicted in figure 4. It forces the user to create rules that are syntactically correct, for instance it doesn t allow him to insert two logical operators without a feature between them. The constraint presented in the example means that if the feature Rapid is selected then also the Oriented Bounding Box and Triangle Mesh features have to be selected. 250

261 Fig. 4. The Constraints Editor 4.3 The instance editor The instance editor allows the user to create instances of an existent feature model. That means select a sub-set of features from all the features that are defined in the model. This selection has to contain all the mandatory features, satisfy the cardinality of the containments and respect all the constraints defined on the model. Figure 5 depicts the instance editor. It is composed of two parts: the visual representation of the model and the instances view. The instances view shows the information about the existent instances and offers a set of commands that allow the user to create, remove and select instances. By looking at the third column of the view it is possible to find out which instance is currently showed in the visual representation. In the presented example it is the Config 1. In the visual representation the selected features are drawn in green. The user can select a feature for being part of the instance by simply clicking on it and pressing a button in the toolbar. Once the user has completed the selection of the features, the instance can be validated. The process of validation checks if the instance satisfies the following requirements. All the mandatory features have to be selected to be part of the instance. All the cardinalities of the containments have to be satisfied, which means that the number of the selected sub-features of a containment has to be 251

262 Fig. 5. The Instance Editor greater than or equal to the lower bound and less than or equal to the upper bound. All the constraints have to be respected. The constraint checking is done by using an external open source library called MVEL [8], which resolves the two members of the constraint rule. After that, if the constraint type is require, the constraint checker controls that both the members are true. In case of an exclude constraint instead when the first member is true the constraint checker controls that the second is false. Finally the instances can be saved on an XML file, which will be the input for the next tools that we are going to develop (see section 1). 5 Conclusions and future works In this paper we have introduced the feature models, their syntactic and semantic and their typical use in the software development process. We have also described the tools that we have developed and the meta-model that describes the rules for the definition of the feature models. Our plugin provides a simple and intuitive tool for designing feature models that are conforming to the syntactic that was presented for the first time in 1990 and then extended in different works described in literature. The plugin also provides a tool for creating and validating instances of the designed models. 252

263 These instances describe concrete applications and can be saved as an XML file in order to be reused by other tools. We have tested the plugin by using it for representing the possible configurations of robotics software and validating them according to the constraints imposed on the models. In the next months we plan to design a new meta-model that allows the representation of the variability resolution (sec 1). In particular we plan to associate to each variant described with a feature model one or more of the architectural elements that compose a component based system and that define how these variants are implemented (variability implementation). By using this mapping we finally plan to develop a tool that helps the developers in the process of deploying the applications defined with the Instance editor. 6 ACKNOWLEDGMENTS The work described in this paper has been funded by the European Community s Seventh Framework Programme (FP7/ ) under grant agreement no. FP7-ICT BRICS (Best Practice in Robotics). The authors would like to thank all the partners of the project for their valuable comments. References 1. BRICS, Best Of Robotics EMF: Eclipse Modeling Framework EMF Feature Model EMFT: Eclipse Modeling Framework Technology Project FeatureIDE, an Eclipse plug-in for Feature-Oriented Software Development. db/research/featureide/. 6. Fmp: Feature Model Plug-in GMF, the Eclipse Graphical Modeling Framework MVEL, MVflex Expression Language OMG, Common Variability Language Wiki Pamela Zave, FAQ Sheet on feature interaction. pamela/faq.html. 11. Pure::variants XFeature - Feature Modelling Tool P. Clements and L. Northrop. Software product lines. Addison-Wesley, K. Czarnecki, T. Bednasch, P. Unger, and U. Eisenecker. Generative programming for embedded software: An industrial experience report. In Generative Programming and Component Engineering, pages Springer, K. Kang. Feature-oriented domain analysis (FODA) feasibility study. Technical report, DTIC Document, M. Riebisch, K. Böllert, D. Streitferdt, and I. Philippow. Extending feature diagrams with UML multiplicities. In 6th Conference on Integrated Design & Process Technology (IDPT 2002), Pasadena, California, USA. Citeseer, D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks. EMF: Eclipse Modeling Framework. Addison-Wesley Professional,

264 CViewer: an application for path routing analysis in a Telco software solution and the Eclipse framework Loredana Luzzi, Alessandro Niglio, Marianna Peluso, Dario Pesole, Andrea Piccolo and Carmine Seraponte Opera21 S.p.A. Via G. Porzio 4, Isola G7 CDN, Napoli, Italy {lluzzi, aniglio, mpeluso, dpesole, apiccolo, cseraponte}@opera21.it Abstract. This paper introduces the application CViewer (Circuit Viewer), that enables the graphical representation and analysis of the path routings involving transport circuits belonging to the Transport Network technological level. Specifically this application performs a comparison between transport circuit paths in terms of physical resources that are used for delivering a communication service. CViewer is based on Semantic Web technologies as an ontological knowledge-base and RDF/OWL-DL languages to represent the communication network model. Besides it is based on Web Services technology and Service Oriented Architecture. This application was born inside a larger project aimed to realize an industrial prototype platform for the modelling and analysis of communication networks in the context of modern Telco service providers. CViewer has been developed, with all the other project modules, via the Eclipse platform using both the development and debugging environment (IDE). In the paper we present the scientific and technological background of the application, its main characteristics and its development in the context of the Eclipse framework. Keywords. Semantic Web, Ontology, Network Inventory, Path, Web Services, SOA. 1 Introduction In the last years the telecommunication industry has seen the continuous need to provide efficient and ready services with low costs. In this context a crucial role has been played by the Operation Support Systems (OSSs) [1], which are generally defined as software systems aimed at the realization of many functions related to telecommunications networks and services to allow service providers to attract and keep customers. These functions include order management, service provisioning, service activation, inventory control etc. Fundamentally, OSSs control a set of processes designed to the usage, the development and the spreading of applications that connect customers with the Telco network. First available OSSs were developed to solve specific organization problems and thus they were strongly customized depending on a given service provider or well 254

265 defined business processes. Later, New Generation OSSs (NG OSSs) [2] appeared that really improve the previous ones in order to supply service providers with more robust products suites. These include the development of solutions based on integrated platforms able to face to a wider needs range. A key role in network handling with OSSs is played by Inventory Control (IC). Independently from the networks dimension and complexity, IC allows the automation of many business processes, such as planning, implementation, configuration, and automatic provisioning of telecommunications services. Indeed, precise and detailed maintenance of network resources data is crucial to enhance telecommunications networks handling. In this context, among a number of software modules that realize, at different layers, an innovative complex system for Network Inventory, based on semantics and agent paradigm, this paper presents a specific application - CViewer - whose prototypal development with the Eclipse framework started within the INCA research project conducted by Opera21 (formerly I.T. Staff) in cooperation with the University of Salerno 1 and partially financed by the Italian Ministry of Economic Development. Nowadays, CViewer, as application for the graphical analysis of network interdomain data, is a part of an important industrial solution for Network Inventory control of Telecom Italia and has been improving continuously. The remainder of this paper is organized as follows. In Section 2, related work on applied researches about the topic of interest will be shortly described. In Section 3 an overview of the main INCA s characteristics is given with reference to the semantic knowledge base of the network which is the foundation of the system. In Section 4 the architecture and functionalities of CViewer are described. Section 5 will present some usage examples. Finally, some brief conclusions will be presented in Section 6. 2 Related Work The scientific and technological area of interest in our scenario is Semantic Web, software agents and new approaches in telecommunication network modelling. Different research projects, based on semantic web technology stack [4], have been conducted with the aim to experiment and find a profitable use of semantic web and agent technologies in industrial applications. So, in this context, we have to point out the already mentioned INCA project [2] because it represents for our company the first systematic attempt to join some research and industrial issues. Main challenge has been the use of ontology-based modelling instead of classical and consolidated database relational schema and software agents as paradigm to realize service delivery. In these fields research and standard works reported in [4-9] have been precious references for designing new network models and the agent-based middleware infrastructure. Contemporarily other research projects have been taking place on similar themes. The EU funded SUPER (Semantics Utilised for Process management within and between EnteRprises) project [19], for example, had the objective to create a 1 Department of Mathematics and Informatics (Prof. Vincenzo Loia). 255

266 technological framework for Business Process Management, enriched with machine readable semantics by employing Semantic Web (with specific domain ontologies) and Semantic Web Services. Also important is the project by Opera21 and FBK-irst (Trento), financed by Autonomous Province of Trento, called RoWS (Rovereto Web Services), whose main purpose has been to realize a framework for bridging the gap between the business process analysis and realization. A crucial role in the RoWS framework is played from a semantic repository where all business processes, also coming from external tools, e.g., as ARIS, are stored to feed after an execution phase realized in terms of complex coordination of services, achieved by means of advanced service composition techniques [20-22]. In the same project also an Eclipse plug-in for business process specification was developed [23]. Many other research efforts have been taking place on semantic web technology and agent paradigm, also involving automotive and e-commerce domains [24, 25], in which we currently have very interesting projects in progress. 3 INCA Overview INCA (Inventory & Catalog) [2] is an integrated software solution designed for telecommunications service providers. It has been conceived as a suite made up by several applications integrated in order to allow the automation of the main Telco business processes. The architectural design is modular and highly scalable in order to meet specific needs of several network service providers operating nowadays in the market, in terms of dimensions (local, national and international) and technologies (mobile networks, etc.). INCA is complying to the international telecommunication standards and is designed to support different Access and Transport network technologies, such as SDH, PDH, ISDN, IP, ATM, xdsl, DWDM, 2G/3G mobile networks etc. The solution is composed by the following main components: Work Manager - for coordination and control of the correct execution of service orders; Route Manager - for finding and building network paths; Loader - for uploading data coming from legacy systems; Network Inventory for intelligent handling the inventory of network resources; Activation Manager for interfacing Network Management services to actuate work-orders; Reconciliation Manager - for reconciliation needs of inventory data; Client Manager for allowing INCA users to access the system; Connector/API, Service and Network Adapter Layer - for integration with external systems. These functional modules provide all is necessary to fully exploit the resources made available by the inventory. The final result is a system completely integrated with other OSSs and BSSs (Business Support Systems) to perform some of the main processes identified by the Enhanced Telecoms Operations Map (etom) from the TeleManagement Forum [3] as: Service Creation, that includes network designing and planning; Service Provisioning, that depends on the telecommunications network capacity and configuration; Service Activation, that allows to execute all modifications to the network configuration; Service Assurance, for problems solution 256

267 and a better planning of network maintenance; Network Provisioning, for network adjustments to allow the activation of new services. The Network Inventory subsystem represents the core component of NG OSSs. In fact, it has been developed in the form of a flexible and intelligent data model adopting semantic web technologies [4, 5], with particular reference to the ontology and ontological languages level. This approach allowed to formalize network related knowledge preparing the basis to enable autonomous agents support activities. Specifically the ontological modelling of network resources is the foundation of the system, which is based, from a structural point of view, on the following main components [2]: an Inventory Knowledge Base (IKB), maintaining all inventory data in the form of a semantic storage; a Network Inventory (NI) layer, which is made up by different sets of agents and is in charge of handling inventory related activities; a Client Manager, allowing users to access the Network Inventory through a webcentric application. For the purposes of this paper we illustrate in particular the IKB subsystem which defines a new efficient and flexible resource inventory model able to be immediately applied to different technological contexts (such as UMTS, etc.). It has been designed [6] as a layered set of ontologies interconnected by means of extension and inclusion relationships. Each ontology represents the modelling of components from a specific technological context and can be added easily to the IKB without any service interruption. The ontologies inside IKB are of different types [2]: Domain Concept Ontologies, defining INCA s general and shared ontological representation of infrastructure components; Applicative Ontologies, maintaining the conceptualization that a specific vendor has defined for given physical components; Semantic Bridging Ontologies, to specify the conversion of applicative ontologies concepts into/from domain concept ones; Service Ontologies, for defining the roles and behaviours of agents in charge of executing tasks related to inventory resources. In particular, the Domain Concept Ontologies are a set of ontologies semantically characterizing inventory resources. Each ontology can be defined extending one or more of pre-existent ones in order to model a new technological context. For each concept in these ontologies a physical component provided by a specific vendor should exist and is conceptually modelled by means of an Applicative Ontology. The binding and conversion from/to homologous instances into the two model is performed by a mapping module (called Semantic Bridge) driven by an instance of the Semantic Bridging Ontology. This instance defines what attributes from the two instances should be mapped each other and the conversion rules to be applied. The semantic bridging aspect of the solution allows directly to support the problem of the integration of knowledge handled by pre-existing inventory systems (with the vantage to reduce overhead and migration costs in real industrial contexts). The Service Ontologies tier, at the top of the ontologies stack, allows to model business processes depending on inventory resources, such as provisioning automation, data reconciliation, etc. In the environment defined by the Inventory Knowledge Base autonomous agents belonging to the NI subsystem are embedded and work. Indeed, the NI subsystem is designed [7] in the form of a Multi-Agent System (MAS) where each agent has a well defined set of assigned roles. Agents interact each other in order to realize shared 257

268 business goals and tasks. A goal is globally defined as a workflow where each activity generally depends on the occurrence of well defined events influencing the environment. The NI subsystem has been designed and implemented [8, 9] as a fully FIPA compliant (Foundation for Intelligent Physical Agents) Multi-Agent System with the JADE (Java Agent DEvelopment) framework [10]. The Multi-Agent System has been designed according to the GAIA agent-oriented software engineering methodology [11]. Network Inventory knowledge management services are offered on a SOA based approach [12]. This is realized by means of a Web Service Interface (WSI) exposed by a specific set of agents in charge of translating service requests into inventory operation events triggering MAS agents activities. The ontological model representation of the different network components is the natural underlying level on which specifically relies CViewer, the visualization and analysis application which is presented in the next Section. 4 The CViewer Application In the context of the New Generation OSSs the semantic approach is revealed challenging and very helpful with respect to needs of modern telecommunication service providers. The state of the network and all related components as nodes, devices, etc. must be continuously monitored and updated to realize an efficient service provisioning, including also service recovery and plant maintenance. For these reasons, as already mentioned, it is very attractive to have an application for the graphical analysis of network inter-domain data to enable a network service provisioning operator to control and verify the consistency of network configuration. This solution is CViewer which has been developed in the context of OSSs, based on semantic web technologies, to provide some specific functionalities as the following: visualization of transport path routings in terms of resources (equipments, fibers, cables, etc.) used; diversification analysis of path routings of transport circuits; printing of the graphical routings. The aim is clearly to obtain a ready control of the network state to be sure it is possible to provide new services and studying the common physical resources between two diversified paths for fault management (e.g., for eventually managing reserve or protection alternative circuit paths). 4.1 Functionalities The CViewer application is constituted by the following main macro-components or functional views: Circuit View, Equipment View and Ring View, which are now shortly described. The Circuit View represents the core functionality of the graphic system CViewer. The network entity object of the consultation is the network service (Data or Transport service) that is graphically represented in all its components both 258

269 logical and physical; the objects involved in the graphic representation of the service are given with all more meaningful information details. This view, providing a graphic vision of the routing of a network service in terms of elements a/o resources that compose its network path, fulfills the user need to have an immediate vision of the physical and logical network used by a service; besides it constitutes a valid tool for the analysis of diversification of the circuits, because it gives evidence of the physical elements shared by two network path routings. More specifically two functionalities are available for the Circuit View: a basic functionality, said Physical View, that allows only the graphic visualization of the network s paths, i.e., linear sequences of physical resources used by the service (as cables and equipments), and that works solely for Transport network services; an advanced functionality, or Inter-Domain View, that represents a proper extension for these reasons: - it includes one Logic View of the circuit, that is, it allows the visualization both of the network physical layer and of the logical one; - it allows to consult network s inter-domain paths or rather those paths that, beginning from the Data network, cross the Transport network layer a/o the Access layer, also, eventually, underlining the Commutated network plants that could be used by the service. The Equipment View allows to visualize, given an equipment of the Transport network, the internal hierarchical structure of the same equipment in terms of cards and ports that compose it, showing the paths that are attested on it, their physical paths in the network and the transmission services that use such paths. The Ring View functionality provides the schematic graphic view of a ring of the Transport network, intended as the set of the Multiplex Sections that form a SDH (Synchronous Digital Hierarchy) ring subnetwork and of the SDH equipments crossed inside the nodes of the ring. More precisely, the Ring View allows the representation both of the physical (equipments, cables) and logical (path) components involved in the schema of the input ring according to the required hierarchical level. All these functionalities in the real industrial field are inserted in a complex multidatabase legacy operational context, so the application uses in real-time the network data stored in the different inventory schema involved for Data, Transport, Access and Commutation network layers. 4.2 Architecture CViewer is based on the following technical architecture. The main subsystems of the application are: the GUI constituted by JSP pages; a web application made by java servlets; a web service that exposes atomic services for the web application. The GUI manages the interaction with the user, who introduces the input data about which he wants to retrieve the information and receives in output the graphical visualization of the data. The web application is formed by servlets that invoke the web services to retrieve the data in RDF/OWL-DL format. The servlets, after obtaining the requested information, elaborate the data and opportunely format them 259

270 before sending them to the GUI s JSP pages that realize the visualization of the received elements with Javascript and AJAX. The web services realize the task of interfacing an Oracle database and catching the data necessary for implementing the computations. Particularly the web services offer some operations that allow to extract the data in an ontological format. The CViewer s architecture is based on a SOA oriented paradigm [12, 13]. The next Figure 1 shows the architecture with reference, for example, to the Equipment View. An important layer in the background of this architecture manages the mapping between data retrieved from legacy database and the instances of the ontological model on which CViewer is founded. This mapping is realized by means of an XML layer with specific XSLT transformations [14]. Fig. 1. CViewer s technical architecture (Equipment View). The ontology for this application has been developed initially in the above mentioned research project and then continuously updated always making reference to the Methontology methodology [15] that really covers all the application lifecycle. In the following Fig. 2 the ontology with its main concepts and relations is shown. The main concepts of this ontological schema are: Path: it is a basic concept which models a service a/o a circuit but also the hierarchical level of the network infrastructure for the transport of the services; Path_Relations: this entity models circuits in relations to paths, the relationships between paths and multiplexing sections, multiplexing sections connected with regeneration sections etc. Site: it is the entity that locates the installation of an equipment; Equipment: it indicates a whole set of mechanical, electric, electronics, optical and software equipments, installed in a network s site; Cable: entity to model the concept of Transmission Media and Infrastructure; 260

271 Rack: it is a part of the infrastructure (a vertical mechanical structure) to permit the installation of an equipment. The ontology has been developed with Protégé, a free, open source ontology editor and knowledge-base framework according to the W3C standard RDF/OWL-DL languages; besides, data manipulation rules from RDF/OWL-DL format storage have been developed with TopBraid Composer, a free Eclipse plug-in [16-18]. 4.3 Eclipse Environment Support Fig. 2. CViewer s Ontological Model. From a technical point of view, a basic support has been given from the IDE and debugging capabilities of the Eclipse platform, which have profitably supported CViewer application s development since the beginning for all its lifecycle: from a research prototype to an industrial application running in a challenging context as that of a very important telecommunication service provider as Telecom Italia. The stability of the Eclipse framework and the simple integration of plug-ins, as TopBraid Composer or Subclipse, has guaranteed also the success in the continuous upgrade of the product functionalities. Simply in the next Figure 3 it is shown an interesting example of the Eclipse framework use, which is referenced to the configuration management case that has been fundamental for the collaborative development and is based on the use in the Eclipse IDE of Subclipse plug-in to provide direct integration of Subversion (SVN). Moreover, from another point of view, a generalized, but important, support has derived to development from the continuous relationship with Eclipse Italian Community on topics related to Semantic Web, OWL-DL model transformations of business processes schema etc. This way, in fact, we have been able to practice with 261

272 different student s stages or theses a virtuous loop among the company and the university according to the well known Renaissance Craftsman Studio metaphor, producing some interesting surveys and prototypal plug-ins. Just in this perhaps we can find the contribution to innovation in the Eclipse ecosystem of applications as CViewer: essentially the transfer of new technologies from research circles into industrial fields, supported by an active community. Fig. 3. CViewer: Configuration management example. 5 CViewer s Usage Examples We describe here some examples to show some CViewer outputs. In general, to query the system the user by a GUI specifies in input the circuit of the Transport network for which it is required to show graphically the physical path or one or two circuits on which he wants to effect the analysis of diversification. 5.1 Physical Path Visualization In this example the path is visualized in graphic form inside a scrollable panel, through a sequence of icons contained in outlined boxes; the main network entities involved are sites, equipments, racks, shelves, ports, cables and links, each one with a proper icon inside the graphic representation. Besides, for equipments the icons are differentiated according to the macro-typology of the represented equipment. The icons are labelled using the alphanumeric key and the typology of the objects that represent following the Company standard. It is possible to expand or collapse the boxes to obtain more details and the icons, as it is shown in the next page (Fig. 4), are 262

273 vertically prepared inside the boxes on more levels, according to the level in which the corresponding entity is met inside the hierarchy of Transport of the input path. Fig. 4. Output example: Physical Path Visualization. Fig. 5. Output example: Path Diversification Analysis. 263

274 5.2 Path Diversification Analysis This functionality allows the comparison between two network paths, providing immediate graphic evidence of the common physical elements. Besides, for each common element found, CViewer provides information about the path of upper level (or father path), inside the hierarchy of Transport for every path in input, that should be redirected for guaranteeing the restoration of the diversification property. The output (see Fig. 5 in the previous page) visualizes the involved path/circuits showing the possible physical elements as equipments, rack, cables or links in common. 6 Conclusions In this paper we presented the CViewer application initially developed in the context of the INCA research project and now become an ontology-based graphical solution running in an important Telco industrial multi-domain context. After presenting the research context and the original project in which the first prototype was developed, we have shown the application s characteristics with the main functionalities and the technical architecture. As discussed, this architecture is basically founded on a SOA paradigm with the use of web services and three independent software layers. Moreover we have illustrated the core ontology which is at the basis of the mapping between the legacy system data and the data layer proper of CViewer, mapping opportunely realized with XML technology by appropriate XSLT transformations. Evidence has been given to the important contribution received from using Eclipse platform during all the entire lifecycle of the application thanks to the powerful IDE and configuration management that supported much the collaboration during development s phases. Besides, an aspect as much important has been underlined, that is, the cooperation on interesting research themes between the company and the university in the context of the Eclipse Italian Community. After, some practical examples of functionalities have been shown to give a concrete idea about the real and immediate support that CViewer can provide in the analysis of network state. It is possible, in conclusion, to say that semantic web technologies (and the agent paradigm too) result very appealing for industrial applications. In our experience their introduction can be made easier just thanks to practical applications, as CViewer, that simply and flexibly are able to meet real and important industrial requirements. Acknowledgments. The authors would like to thank all the Opera21 development team s components, the partners involved into the INCA project and Telecom Italia. References 1. L. Andersson, OSS Solutions for Network Operators, White Paper, Open Distribution, Teleca (2002) 264

275 2. A. Adamo, L. Cafaro, V. Loia, C. Romano, M. Veniero, A Multi-layered Agent Ontology System for Resource Inventory, ISIE (2008) 3. TeleManagement Forum (TMF), Enhanced Telecom Operations Map (etom) The Business Process Framework (2003), 4. T. Berners-Lee, J. Hendler, and O. Lassila, The semantic web, Scientific American, 284(5):34-43, (May 2001) 5. T. Berners-Lee, Weaving the Web, HarperBusiness, New York (2000) 6. M. Fernandez-Lopez, Overview of methodologies for building ontologies, In Proc. Workshop on Ontologies and Problem-Solving Methods (1999) 7. V. Loia and S. Sessa (Eds.), Soft Computing Agents: New Trends for Designing Autonomous Systems, Physica-Verlag, Springer, vol. 75 (2001) 8. Foundation for Intelligent, Physical Agents, FIPA Agent Management Specification, Geneva, Switzerland (October 2000), 9. Foundation for Intelligent, Physical Agents, and P.D. O Brien and R. Nicol, FIPA: Towards a standard for intelligent agents, BT Technical Journal, 16(3) (1998) 10. JADE (Java Agent DEvelopment Framework) Project (TILAB, formerly CSELT), P. Moraitis, N. Spanoudakis, Combining Gaia and JADE for Multi-Agent Systems Design, in: Proc. of the 17th European Meeting on Cybernetics and Systems Research (EMCSR 2004), Vienna, Austria (April 2004) 12. OASIS, Reference Model for Service Oriented Architecture 1.0, on-line (August 2006) 13. W3C, Web Services Architecture, on-line (February 2004) 14. W3C Recommendation, XSL Transformations (XSLT) Version 1.0, on-line (November 1999) 15. M. Fernandez-Lopez, A. Gomez-Perez, and N. Juristo, Methontology: from ontological art towards ontological engineering, in Proc. Symp. on Ontological Engin. of AAAI (1997) 16. Protégé, Ontology editor & knowledge-base framework, - TopBraid Composer, D. Becket, Rdf/xml syntax specification. W3C recommendation, RDF Core Working Group, World Wide Web Consortium (2004) 18. W3C Recommendation, OWL Web Ontology Language Guide (February 2004), SUPER Project Site, P. Traverso, M. Pistore, Automated Composition of Semantic Web Services into Executable Processes, in: Proc. ISWC 04 (2004) 21. M. Pistore, P. Traverso, P. Bertoli, Automated Composition of Web Services by Planning in Asynchronous Domains, in: Proc. ICAPS 05 (2005) 22. J. Hoffmann, P. Bertoli, M. Pistore, Web Service Composition as Planning, Revisited: In Between Background Theories and Initial State Uncertainty, in: Proc. of AAAI 07 (2007) 23. M. Aimar, I. R. Clerici, P. Pilolli, M. Pistore, C. Seraponte, M. Trainotti, G. Zacco, Business specification framework: an eclipse plugin for business process specification, in: Proc. of First International Conference on Eclipse Technologies (Eclipse-IT) (2007) 24. V. Galdi, V. Loia, A. Piccolo, M. Veniero, Computational Intelligence and Agent Paradigm for Intelligent Tunnels Design, World Academic Press, UK, Vol.2, No.2, pp (2008) 25. V. Loia, S. Senatore, M.I. Sessa, and M. Veniero, A Multi-Granular Model for E-Commerce Services in Uncertainty and Intelligent Information Systems, B. Bouchon-Meunier, C. Marsala, M. Rifqi, R. R Yager, Eds. World Scientific Publishing Co. Pte. Ltd. (2008) 265

276 An Eclipse plug-in for Public Administration software system modelling and simulation Riccardo Cognini, Damiano Falcioni, Andrea Polini, Alberto Polzonetti, and Barbara Re University of Camerino, School of Science and Technology Computer Science Section, Camerino, Italy WWW home page: Abstract. According to national and international studies most of information systems development projects perform poorly and often lead to seam failures. These issues seem to be even more prevalent within public sector where among the others political, organizational and technology issues have to find the best combination. Software development in public sector is a quite complex task. Building up a community where all the Public Administration stakeholders share languages and techniques is crucial to support the information systems development and their impact on the society. In this paper we present a modeling and simulation framework supporting the communication between the domain experts and the IT staff usually challenge due to different backgrounds, perspectives and terminology. We face the modeling challenge considering standard languages such as UML 2.0 and BPMN 2.0. The approach is supported by a plugin for Eclipse platform permitting to have an integrated environment in which to design and to simulate the information system. 1 Introduction In order to strengthen the penetration of Information and Communication Technologies (ICT) potentialities, Public Administrations (PA) are working toward a structured design of their software systems and services. Models for organizational design require a high degree of knowledge that can be expected only from domain experts. At the same time models for application system design require a high degree of technical precision. Therefore to implement successful software system it is necessary to close the gap between domain and IT experts. A systematic design and analysis approach is needed to support innovation in PA and to enable e-government development via a plan-do-check-act paradigm. To do that we introduce a multi-perspective representation based on consolidate Enterprise Architecture approaches [1]. We also enable comparability between This work has been partially supported by the European Project FP7 IP : CHOReOS. 266

277 different models and we identify points of interaction among the different model views. This is in line with general principles of modeling in the e-government domain [2]. Starting from a Domain Specific Language (DSL) we define in the past, named egaml [3]; we propose a practical approach that starting from the Business Process definition supports domain and IT experts to model and than simulate specific views in the PA information systems. egaml is based on UML 2.0 and BPMN 2.0 standards and it is encapsulated in an eclipse plug-in that we developed. Several challenges were faced during the definition and development of egaml. The paper illustrates technical solutions we adopted and egaml general usage. We provide an overview of tools available to generate both a graphical editor from the DSL meta-models (such as GMF, Graphiti, EuGENia and GEMS), and specific editor for BPMN 2.0 (such as Activiti and jbpm). As a result Eclipse becomes a powerful development environment for PA related software systems. The paper is structured as follows. Section 2 introduces a brief state of the art review and Section 3 provides an introduction to background technologies. Section 4 describes the work performed in implementing the egaml meta-model and the simulation algorithm. Finally, Section 5 draws some conclusions. 2 State of the art Several Domain Specific Languages have been developed; most of them are based over the Zachman framework [4]. In the area of e-government we cite the PICTURE-method. It consists of a modeling language and related approach, which guides the application of the language giving a complete overview on organizations practices focusing on Business Process (BP) [5]. For what concern the BP simulation and related tools several attempts have been introduced [6] [7]. Just to cite a few we refer to Protos [8] and ARIS [9] as important and relevant experiences. In the area of commercial software we cite Goldsim Pro [10], eclarus Business Process Modeler [11] or ProModel Process [12]. All of them are mature Business Process Management (BPM) systems with a more or less structured simulation engine. In the most of modelling and simulation approaches (i) relationships between BP and the other views in the organizations and (ii) domain dependent requirements are missed. We try to introduce them and we provide a plan-do-check-act approach in the design of e-government informative systems. 3 Background 3.1 EMF supporting tools In order to design and develop the graphical editor based on the EMF metamodel we compare Graphical Modeling Framework (GMF) [13], Graphiti [14], EuGENIa [15] and Generic Eclipse Modeling System (GEMS) [16]. Table 1 sum up the results of our first investigation. 267

278 GMF introduces a model-driven approach to generate Eclipse graphical editors from EMF Ecore files. It is a bridge between EMF and Graphical Editing Framework (GEF). We withdraw it after several tests. According to our technical evaluation we realize that developing a good BPMN 2.0 visual editor using this kind of technology is too complex Graphiti is an Eclipse-based graphics framework to enable easy development of state-of-the-art diagram editors for domain models. The main difference between GMF and Graphiti is that GMF creates a visual editor from EMF file, instead with Graphiti it is possible to create directly the meta model and than the visual editor starting from it. Unfortunately, Graphiti does not support EMF import that in our case is a strict requirement. EuGENia is a tool that automatically generates the models needed to implement a GMF editor from a single annotated Ecore meta-model. Even if it introduces an interesting approach it does not reduce developing time respect to the GMF-based coding, so according to our analysis we realize to skip it. GEMS tries to bridge the gap between the communities experienced with visual meta-modeling tools, such as the Generic Modeling Environment, and those built around the Eclipse modeling technologies, such as the EMF and the GMF. The framework provides a knowledge base suitable to assert EMF modeling elements into. Once modeling elements are asserted into the knowledge base, constraints to relationships between model elements can be add via a easily edit interface. GEMS is stable and well tested environment. Table 1. EMF supporting tools: overview According to our first investigation GEMS results the best option to create visual editors bases on customized meta-model. Unfortunately, none of the investigated tools support our choice to rely on standard BPMN 2.0 EMF metamodel. We believe that the main reason for that can be the BPMN 2.0 EMF meta-model incompleteness. In order to solve this issue we decided to relay over a third part BPMN 2.0 Editor based on EMF as following discussed. 268

279 3.2 BPMN 2.0 and related modeling tools Business Process Model and Notation (BPMN) is a graphical representation for specifying BP in a BP model. The current version is BPMN 2.0 [17]. It introduces various constructs and two completely new diagram types such as choreography diagram - modeling of the data exchange between different partners, and conversation diagram - giving an overview of several partners and their communication links. Although these novelties are very prominent the majority of the alterations from the past version is the graphic model representation in the form of a meta-model. We tested several BPMN 2.0 modelers based on Eclipse (Table 2) but in this work we focus only on those based on the BPMN 2.0 EMF meta-model [18]. We refer to Activiti [19] and jboss [20] communities. Activiti Eclispe Plug-in provides functionalities to design BPMN 2.0 processes and run these processes on the Activiti Engine. For the implementation of visual editor it uses Graphiti, and the BPMN 2.0 specification is based on the Eclipse BPMN 2.0 meta-model. Unfortunately, Activity is not yet complete and it does not provide all BPMN 2.0 elements. Activiti also provides a web-based BPMN2 editor provided by SIGNAVIO that cover all BPMN2 elements, but it is not Eclipse based and we faced several integration problems. Also JBoss Community created a BPMN 2.0 Eclipse plug-in named jbpm. As well as Activiti it does not provide all of BPMN 2.0 elements. After some investigations, we have find imeikas jboss to be our best choice for modeling BPMN 2.0 processes. According to our investigation it is the most complete and effective BPMN 2.0 modeling tool. Table 2. BPMN 2.0 and related modeling tools: overview 4 Modeling and Simulation 4.1 Architecture Overview The framework we have defined for BP modelling and simulation is made available through the development of an Eclipse plug-ins. It permits to have a fully integrated and user-friendly environment, which support domain experts both in the BP specification phase (Fig. 1). In particular, the supported meta-models are created using EMF, while the graphical modeler is supported by GEMS. Using the resulting plug-in, BP developers can define their models according to the rules of the egaml meta-model [3] as following reported. 269

280 For each Role in the Organization Model, there is a BPMN 2.0 Model and a Communication Model that describe its process and communications respectively. Each BPMN 2.0 Model is associated to a Communication Model. For each Send (Receive) Task in BPMN 2.0 Model there is a Send (Receive) Task in the Communication Model associated. Fig. 1. Architecture overview Rules are stored in a parameterized XML file. The approach can be generalized to add a new meta-model and link it with the others defined by egaml. Simulation is also supported by the plug-in according to the algorithm we have defined. Before launching the simulation BP developers can set different parameters such as the number of stakeholders for each role, the average time needed to complete a task, how much time each stakeholders works, etc. Many statistical functions have been implemented to assess the result of the simulation. It is also possible to know how many times a stakeholder completes his process, or how many times a stakeholder complete a specific task. Results of simulation are shown using histograms created with jfreechart. 4.2 BPMN2, Organization and Communication Meta-model For what concern meta-model definition we base our work on BPMN 2.0 metamodel as already discussed and we introduce Organization and Communication meta-models. Organization meta-model permits to describe the structure of an organization. This can refer to a PA, group of citizen, schools, etc. The meta-model is composed by four different elements: Organization represents the organization (i.e. University of Camerino, Home Affairs Minister or Citizen); 270

281 Unit represents the different units of the organization (i.e. personnel department or Warehouse); Role represents the role of Organizations (i.e. secretary and director); Stakeholder represents actors of the system as a person or an entity that can do something (i.e. Mario the director of the unit X). These elements are related to each others through the following relationships: Each Organization is composed by Units; For each Organization, there is at least one Role, and each Role can be linked to at least a single Organization; For each Organization, there is at least a Stakeholder, but each Stakeholder can work in many Organizations; Each Stakeholder play at least a Role and each Role has to be played by at least one Stakeholder. Fig. 2. Example of Organization Model Figure 2 shows an example of Organization Model. In this case, there is only one Organization called Unicam. It has only one Unit, the Secretariat, and it includes two Roles, the Student and the Professor. Actors of the system are also two. There is Riccardo that is a Student, and Polzonetti that is a Professor. Communication meta-models describes how actors interact with each other. For each Role/Lane it exists a Communication Diagram. Therefore, each actor has its Communication Model. This meta-model is composed by five different elements: Receive Task means that the actor receives a message from other actors; Send Task means that the actor send a message to other actors; 271

282 Pool is referring to an organization in the Organization meta-model; External Receive Task is a Receive Task of an external actor; it means that this task is not executed by this actor; External Send Task is a Send Task of an external actor; it means that this actor does not execute this task. These elements are related to each others through the following relationships: Each Pool can be link to zero or more External Send or External Receive tasks; Each External Send or External Receive task can be in only one Pool; Each Send Task can be linked to a single External Receive Task and each External Receive Task can be linked to a single Send Task; Each External Send Task can be linked to a single Receive Task and each Receive Task can be linked to a single External Send Task. 4.3 Business rules as meta-models links Once all the different meta-models have been defined, we introduce a set of rules to kink them. The main rules are as following. For each Role and for each Receive Task in a Process Model there is only one Receive Task in a Communication Model with the same Name. For each Role and for each Receive Task in a Communication Model there is only one Receive Task in a Process Model with the same Name. For each Role and for each Send Task in a Process Model there is only one Send Task in a Communication Model with the same Name. For each Role and for each Send Task in a Communication Model there is only one Send Task in a Process Model with the same Name. For each Organization in the Organization Model there is at most one Pool in each Communication Model with the same Name. For each Pool in each Communication Model there is an Organization in the Organization Model with the same Name. The main element of XML rules file is Rules element. Inside Rules element there is at least a Rule element. A Rule element is composed by two simple elements. Element element: represents the related object and it has two attributes: Name: contains name of the related object; File: refers to the meta-model where the object can be found (it can be communication, organization or bpmn2). Link element: represents the object that is linked from Element. It has three attributes: Name: contains the name of the linked object; File: refers to the meta-model where the object can be found (it can be communication, organization or bpmn2). 272

283 Cardinality: is the cardinality of the relation (i.e. if cardinality is 3, for each selected object in Element element exactly three linked elements must exist, or if cardinality is 1..* at least a linked element must exist). According to the rules, we can deduce the hierarchy of the models. The first model we need to create is the Organization Model. To do that we implement functionality that creates automatically the structure of the file system, from an Organization Model. It creates a folder for each Organization in an Organization Model and it creates a sub-folder for each role in an Organization with a BPMN2 Model and a Communication Model. There are many advantages in providing such folder structure. First, we can easily manage authorizations both in edit and view mode. For example, image that a Manager wants to modify a process of his stakeholders; in this case, we can easy implement the logic of permits that avoid the manager to modify something out of his Organization. 4.4 Simulation To define our simulator we have followed the approach proposed in [6] and tried to cover all the main aspects described in [21] and in [7]. As matter of fact we use sub-runs and statistics functions and we did not introduce animation in order to maintain the framework light. The approach is based on waterfall steps where the first is the definition of the problem. Input parameters are following proposed. Organization, Process and Communication models are defined according to the meta-models in egaml; The number of actors there is in the simulation context as well as the Role they play; Information related Actors, like how long an actor work or how much time an actor spends for doing a specific Task, etc; Path priorities as the order of priorities for the routes in case of Gateway elements. The outputs parameters we obtain are: Number of times that each actor completes his process; Time of execution for each actor; Number of times that each actor complete a Task; Statistical indexes (i.e. average waiting time, trend, variance, standard deviation, etc) for each Receive Task. Figure 3 shows the conceptual model of our simulator. The core of the simulator is the class Simulator; it contains two sets of actors (class Actor). The first set contains actors with the given inputs parameters (given by user), and the second set contains actors defined during the simulation process. Every actor has at least a communication model and a process model (classes Communication and Process). There are three classes for doing various controls. They are 273

284 Fig. 3. Simulator model class diagram Errors, Messages and Functions. Errors contains a set of error messages that are stamped when an error occurs. Messages contains a set of messages that are printed when something happen. Functions contains a set of generic functions (i.e. XML reader). Class description is following reported. Simulator: Messages Information, tracks who send a message, who receive it and the time of send; Actor: Time Information, that is the start time, the end time and the execution time of the actor; Task Information, represents the information of Tasks (i.e. the time of execution of a task); Getaway Priority, represents the priorities of Getaway elements; Process: Process Information, is a simple XML file that describes the process; Communication: Communication Information, is a simple XML file that describes the communication. Based on this conceptual model we have realized the executable tool. There are a lot of tools created for executing simulation models, but we preferred to develop it from scratch, creating an algorithm from conceptual model, since available tools are too dispersed, they are designed for simulating general processes, and for example in our specific domain they lost some inputs parameters. Besides, they usually transform the system in a Petri-Net, and after that they do the simulation based on it. In our case we define a simulation algorithm based on the concept of actor time and in a loop cycle that executes a single task for each actor in any time. For example image that we have the Process model in Figure 4. There are two different roles, Person and Municipality Worker. Suppose there is a single actor for each role that works from time 0 to time 100 (where time is a user defined time 274

285 Fig. 4. Simulation Example unit), and each Task/Send Task has an execution time equal to 5 (all Receive Task has a variable time). The algorithm starts executing the firth task of the first actor. In this case it stats from Persons Send Info. The execution s time of Person is now 5, he is waiting in Send Info and in the set of messages there is a message from Send Info to Receive Info. It is because when a Send Task is executed the algorithm add a message in the set of messages, contrariwise when a Receive Task is executed a respective message is erased, if it exists. At this point algorithm executes a Task of the other actor, Municipality Worker. The time of Municipality Worker is now set to 5 because the message that he attends is arrived at 5. Now it s up to Person. After that Municipality Worker does Work Task. And it set his time to 10. Now it is Persons time.butheis still waiting for a message. So the situation does not change. The only action that we can do is Send Response of Municipality Worker. When algorithm does Send Response, it adds a new message to the set of the messages and update the time of Municipality Worker to 15. Finally Receive Response is unlocked at time 15 and Person can finish his process. The Simulation results have to be interpreted by an analyst expert through graphs like histograms or through row textual data. They help us understand where the system can be improved. If the medium waiting time of a Receive Task is higher than the minimum waiting time, probably there is a block in the process with the respective Send Task. If the distribute indexes are high (i.e. Variance or Standard deviation), or if the different between the maximum and the minimum waiting time is high, probably there is a block in the process with the respective Send Task. If a stakeholder ends his simulation before (i.e. final stakeholders time is 10 and max stakeholders time is 100), probably there is a slowdown in a linked processes. 275

286 If the medium waiting time of Receive Task is similar to minimum and maximum waiting time, it means that probably there is not a slowdown in alinkedprocesses. If each actor ends his process for the same times, probably there is not a slowdown in the system. 5 Conclusion The paper presents a modeling and simulation framework. We face the modeling challenge considering standard languages such as UML 2.0 and BPMN 2.0. The approach is supported by a plug-in for Eclipse platform permitting to have an integrated environment in which to design and to simulate the information system. The plug-in makes easier and more effective the development of software system in order to provide better services to citizens. References 1. Schekkerman, J.: How to survive in the jungle of enterprise architecture framework: Creating or choosing an enterprise architecture framework. Trafford (2006) 2. Becker, J., Algermissen, L., Niehaves, B.: Organizational engineering in public administrations: a method for process-oriented egovernment projects. In: Proceedings of the 2004 ACM symposium on Applied computing. SAC 04, New York, NY, USA, ACM (2004) F.Corradini, Falcioni, D., Polini, A., Polzonetti, A., Re, B.: egaml: A domain specific language for design and verification of e-government digital services. In: Proceedings of the IFIP EGOV 2011 conference, Delft (The Netherlands) (2011) 4. Zachman, J.: A framework for information systems architecture. IBM systems journal 26(3) (2010) Becker, J., Pfeiffer, D., Räckers, M.: Electronic Government, 6th International Conference, EGOV 2007, Regensburg, Germany, September 3-7, 2007, Proceedings. In Wimmer, M., Scholl, H.J., Grönlund, Å., eds.: EGOV. Volume 4656 of Lecture Notes in Computer Science., Springer (2007) 6. van der Aalst, W., Nakatumba, J., Rozinat, A., Russell, N.: Business process simulation. Handbook on business process management 1 (2010) 7. Bosilj-Vuksic, V., Ceric, V., Hlupic, V.: Criteria for the evaluation of business process simulation tools. Interdisciplinary Journal of Information, Knowledge, and Management 2 (2007) Verbeek, E., van Hattem, M., Reijers, H., de Munk, W.: Protos 7.0: Simulation made accessible. Applications and Theory of Petri Nets 2005 (2005) Scheer, A.: ARIS business process frameworks. Springer Verlag (1999) 10. Goldsim: (Goldsim modeler) eclarus: (eclarus modeler) Promodel: (Promodel process simulator) Eclipse: (Gmf - graphical modeling framework) Eclipse: (Graphiti project) Eclipse: (Eugenia) White, J., Schmidt, D., Mulligan, S.: The generic eclipse modeling system. In: Model-Driven Development Tool Implementers Forum, TOOLS. Volume 7. (2007) 276

287 17. OMG: Business process model and notation (bpmn) 2.0. Technical report, Object Management Group (2009) 18. Eclipse: (Bpmn 2.0 meta-model) Activiti: Activiti bpm platform (2010) jboss: (jbpm) van der Aalst, W., Nakatumba, J., Rozinat, A., Russell, N.: Business process simulation: How to get it right. BPM Center Report BPM-08-07, BPMcenter. org (2008) 277

288 PrEdE: a Projectional Editor for the Eclipse Modeling Framework Federico Tomassetti, Marco Torchiano Politecnico di Torino, c.so Duca degli Abruzzi, 24, 10129, Torino, Italy Abstract. Modern software applications are extremely complex systems, in particular due to the many different facets that characterize such systems. Specific languages and notations are the key factors to improve efficiency and effectiveness in understanding, analysing, and synthesizing each and every feature. Nevertheless they express different views of the same underlying system, and maintaining coherence and unity represents an important issue. A projectional editor is able to represent different parts and aspects of a single model by means of different notations thus enhancing effectiveness while ensuring consistency. We propose a tool designed to achieve the possibility to easy mix languages and notations. This tool is based on the Eclipse Modeling Framework, which provides the technological infrastructure and offers a wide set of interoperable tools. We believe that such an editor can represent a valuable addition to the Eclipse ecosystem. 1 Introduction The Eclipse Modeling project provides a rich platform for model-driven development consisting of various interoperating tools. In this rich environment we think a flexible projectional-editor could be a significative addition and it could complete the platform with the possibility to develop extensible and combinable languages (both GPLs and DSLs), realizing for each of them one or more mixable notations. The tool works on top of the Eclipse Modeling Framework (EMF) technology. In this paper we present the design and implementation of this projectional editor, named PrEdE. The most important characteristics of this tool are: projectional editing: what is edited is different from what is stored, use of multiple notations to represent the same data, interoperability between different domains, reusability of projections, possibility to evolve languages and notations. Using this projectional editor as a base and integrating it with other tools from the Eclipse Modeling platform we aim to realize a complete Language Workbench, as defined by Martin Fowler [4]. In the resulting Language Workbench new languages would be created: their meta-models would be defined using Ecore 1, new notations would be implemented as projections

289 2 Motivation This work was motivated by the relevance of using proper languages and notations to develop every kind of artefacts involving reasoning and the importance of supporting tools. We believe that these advantages should be brought to the rich ecosystem of the Eclipse Modeling framework, both to complete that environment and to take advantage of existing technology in implementing this language workbench. The need for a projectional editor in Eclipse was also stated by Merkle: The combination of modular languages, different DSLs combined is much easier with Projectional editor and classical parser based approaches will reach their limits. Currently there is not yet a real projectional editor for eclipse but we are sure that this is already on the roadmap.[8]. We discuss the importance of languages and notations (2.1) and supporting tools (2.2). 2.1 Languages and notations Sapir and Whorf hypothesized that the natural language used affect the way of thinking. This principle was named after them as the Sapir-Whorf hypothesis and it is also known as the linguistic relativity principle [13][12]. According to the Sapir-Whorf hypothesis at the very least languages influence our way of think and, potentially, they can limit what we are able to think about; languages determine which thoughts we are able to formulate, hindering or preventing thoughts that can not be expressed by the means of known languages. Later this concept was supported with empirical evidence [11]. The importance of the language and the supporting notation was considered also in the context of formal languages. In mathematics it was pointed out by Whitehead: By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race. Before the introduction of the Arabic notation, multiplication was difficult, and the division even of integers called into play the highest mathematical faculties.[17, p. 59]. I.e. the way the Korean language represents numbers is considered one of the reason for high-performances of Korean students in international mathematics competition [10]. In 1972 Dijkstra discussed about the importance of languages and notations in the programming world: Tools we are trying to use and the language or notation we are using to express or record our thoughts are the major factors determining what we can think or express at all![3]. A correct notation also improves our ability to reason on a particular model. Gross [5] in particular discuss the role of graphical notation. 2.2 Supporting tools Andy Clark et al. introduced the concept of active externalism. Considering the active role of the environment in driving cognitive processes they suggest that the human brain and the external tools are part of a complexive system, i.e. tools 279

290 used to support reasoning can be seen as extension of the mind [1]. Dennett reports a sentence from Bo Dahlbom and Lars-Erik Janlert: Just as you cannot do very much carpentry with your bare hands, there is not much thinking you can do with your bare brain [2]. This sentence expresses the commonality between physical and mental activities. It is commonly known that tools augmented the physical possibilities of human beings. On the same way there is a category of tools leveraging the human mental potential. Clark suggests that the biological brain has evolved and matured in ways which factor in the reliable presence of a manipulable external environment. Nersessian concludes that engineering scientists think by means of the artifact models they design and build and without them they are almost unable to think [9]. So tools can support designing and thinking, and so also programming which is a specific mental activity. In some way languages can be seen as particular tools supporting reasoning. Given the importance of tools we think that is important to pair extensible languages with appropriate extensible supporting tools to efficiently use them and we think that projectional editors are a particularly interesting option. Projectional editors operate directly on the model. It brings some advantage in respect to textual editors which have to build inside the editor the model to associate portions of the code to semantic concepts. Textual editors instead are not always able to reconstruct correctly the model. For example Ko reports experiences of IDE reconstructing incorrectly the model from the textual form [7]; this kind of problem can not happen in a projectional editor because the model is directly available, it does not need to be reconstructed from another source. We think that decoupling the models from their representation is an advantage. In this way these two aspects can evolve independently. Notations can be improved without modifying existing models. Using textual editing this is simply not possible because source code depends on the notation, not on the abstract language. A very important advantage over textual editing in our opinion is the possibility to combine modular languages [8]. Compose two textual languages means to combine their grammars, which could easily lead to ambiguity and the need to refactor the grammars, in general the possibility to combine two textual languages is not easily obtainable. An issue with projectional editors is the difficulty to modify models in respect to common textual source code. I.e. transforming a while statement in an if statement is as simple as substituting the corresponding keyword in the latter case, while it requires an explicit command to be provided by the projectional editor vendor. This argument suggests that extensibility is strongly desirable for projectional editors so that users have the possibility to enrich the tools with commands not provided by the vendor. 280

291 3 Architecture of PrEdE In this section we present the design of PrEdE. The tool projects a EMF model as an editor-cell eventually composed by sub-cells. The architecture is based on the Model View Controller (MVC) pattern: the EMF model plays the model role also in the MVC pattern, the view is realized using lightweight widgets and the editor cells are the controllers. A bird s-eye view of the architecture is shown in figure 1. Each model is divided in elements. An element is a piece of information which can be represented independently. Elements are arranged in hierarchies: an element can be composed by sub-elements. Elements are fine-grained in PrEdE to achieve flexibility. PrEdE uses EMF models, so PrEdE elements derives from EMF components. In particular they correspond roughly to EResources, EObjects, EAttributes and EReferences. Distinct elements were introduced for EAttributes and EReferences with a single value associated or a list. Each element is controlled by an editor-cell. Often a cell contains sub-cells and each contained cell is used to control a portion of the element controlled by the containing cell, i.e. a containing cell can control a whole EObject and it can contain a cell for each EAttribute. A cell uses different widgets to represent information of the element and observes it for changes. According to commands issued from the users the corresponding changes are applied to the model and then reflected by the view (the concrete widgets). The cell is then responsible to wire the information represented in the element to its representation. Projection Model Editor cells CELL CELL CELL CELL CELL CELL CELL CELL CONTROL CELL SHOW WIDGETS Fig. 1. Architecture of PrEdE. 281

292 Projections are responsible for creating and wiring together cells. Each projection represents a notation usable for a certain kind of elements. When the user ask the editor to show a certain element the preferred projection for that kind of element is retrieved and it is asked to create a cell for the element. The projection could decide to create sub-cells to represent portions of the element. In this case the projections could instantiates directly the sub-cells or ask the workbench to select the best suitable projection to represent that sub-element. For example the mathematical projection when asked to represent a division creates an editor cell which draws a line between two cells. When a division is created the dividend and the divisor are undefined, so the mathematical projection is responsible for creating place-holders which let the user instantiate them. Operands of a division have to be Expression, which is an EClass defined in the Mathematical meta-model. Acting on a place-holder for undefined elements the user is presented with a list all concrete EClass which derive from Expression.The line between the operands is automatically resized to be as long as the widest operand representation. In figure 2 two divisions are shown; on the left there is a division between an integer and a not yet created element. On the right the same division is shown after the user decided to instantiate a sum as divisor. Note that the same pattern is used for the representation of the Sum: a place-holder is used to let the user choose which kind of element instantiate as operand of the addition. This means that the same cell kind (the place-holder) is re-used in both situations and in general, each time an object has to be instantiated. If the operands of the division are already created the mathematical projection try to represent them. If it does not know how to represent them the corresponding extension for the mathematical projection the workbench is asked for the preferred projection for that elements. It could happen when new kinds of elements are created and the corresponding extension to the mathematical projection is not implemented. In any case PrEdE ensures that every kind of EMF element can be represented, at least using the Default projection which can be used as a fall-back. Currently projections are implemented in Java. Users can create, load and save models through the navigation panel. Models are shown using a tree view which permits to explore every element contained. Clicking on an element it is shown in the editor area using the preferred projection for that kind of element. More editor views can be opened at the same time and the user can switch between them. In the editor area the user can select cells and perform actions on them. One of this action is the projection switch Fig. 2. A division as represented by the Mathematical projection in PrEdE. 282

293 which permits to represent the selected piece of information using a different projection. Using EMF is possible to register Resource Factory which are components able to produce EMF models from a certain source. For example JaMopp [6] provides a Resource Factory to produce EMF models from Java source files. This mechanism permits to use EMF as pivot technology working on different kind of sources. As consequence PrEdE is able to open every kind of file for which a Resource Factory is provided. This include also XMI files, which is the default format used to persist EMF models. The workbench maintains a registry of available projections. Each projection is associated with a priority value. When an element need to be represented the suitable projection with the highest priority is used. A projection named default projection is provided. The default projection is suitable to represent every kind of elements, so it is guaranteed that every element can be shown. The workbench is based on the Eclipse platform and because of that it uses the Standard Widget Toolkit (SWT) 2. In the editor area instead a set of lightweight widgets is used. The reason is that the editor could potentially create a very large number of widgets, considering also a large number of containers create by intermediate elements. SWT uses widgets from the system library which requires on many platforms to use an handle from the system. Because the number of handles is quite limited and not stated explicitly we preferred to avoid using SWT. Moreover the widget sets are tipically designed for notdynamic applications. In this kind of applications forms are created and almost never changed. In this projectional editor instead widgets need to be added or removed often. Finally in common widget sets is the container to determine the size of children, while in this case a container does not necessarily know the kind of widgets it is going to contain. This is due to the open nature of this tool: new projections and new extensions can be added, so each container should be able to adapt to work with unknown cells. PrEdE re-uses the EMF technology to build models and also meta-models. In particular meta-models can be realized using the Ecore language: Ecore models are EMF meta-models and, at the same time they are EMF models. Every kind of EMF model can be created and edited in PrEdE using the default projection. Figure 3 shows the a meta-model open in PrEdE using the default projection. A global registry is used by EMF to track all the existing meta-models. Eclipse plug-ins can register the meta-models they contain when they are loaded. 4 Case study: a mathematical DSL To show how PrEdE can be used we realized a simple case-study. In this section we first describe the implementation of a language and its supporting notation (4.1), then we show how this language can be extended both with new concepts (4.2) and new notations (4.3). Finally we discuss this experience (4.4)

294 4.1 The basic math language The language we chose to implement is a simple mathematical language describing immediate integers and the fundamental operations (addition, subtraction, multiplication, division). Those concepts are a subset of many programming languages. There are some differences in the syntax between the different languages but the concepts are the same, re-implemented in different ways. Aiming to engineer the process of create and manage languages we thought that implementing this portion common to many languages could be an interesting example. Using PrEdE this implementation could be re-used in implementing more complex languages. The meta-model created is shown in figure 4. Fig. 3. A metamodel open PrEdE. Elements represented by [EFactory] and [EClass] are folded. The user can expand them individually. 284

295 We realized also a projection of the basic math language reproducing the common mathematical notation. In figure 5 we show an expression as it appears in a common Java editor and the same expression as it appears in PrEdE. We implemented the projection in Java code (639 lines of code) and inserted it in an Eclipse plug-in. We declared in the Activator of the Eclipse plug-in to register the projection in the PrEdE projections registry as soon as the plug-in is loaded, as consequence inserting it in the Eclipse installation where PrEdE it is available the new projection can be immediately used with no configuration required. 4.2 Extend with new concepts To demonstrate the extensibility of PrEdE with new concepts we realized in a separate Eclipse plug-in a new meta-model declaring just the Exponentiation Fig. 4. The basic mathematical meta-model. Fig. 5. A mathematical expression in Java (above) and shown in PrEdE (below). 285

296 EClass. Exponentiation is an extension of the Expression EClass declared in the basic mathematical language. It has two EReference: a generic Expression can be used as the base, and an ImmediateInteger can be used as the exponent. Realize this extension is as simple as realize a new meta-model. Without any further effort the concept Exponentiation can be used in PrEdE using the default projection to represent instance of the Exponentiation. We implemented also a specific projection for the newly created concept. It required to write about 30 lines of Java code. Also in this case, just installing the plug-in the newly created concept and the corresponding projection are immediately available in PrEdE. 4.3 Extend with more notations For the sake of demonstrate the extendibility of PrEdE we realized a different notation for the mathematical language. We chose to implement a graphical notation representing expressions as a tree where leaves are the values and intermediate nodes are the operators. The same expression shown in figure 5 is represented using the tree notation in PrEdE in figure 6. Installing the plug-in with the new projection every expression realized before or after the plug-in insertion can be projected using the new tree notation. Realize this extension was quite easy, being PrEdE planned for extension. New projections need just to produce views of elements using lightweight widgets. In this example we just used a Canvas widget and draw a circle containing the symbol of the operation, then we connected the symbol to the representation of the operands. The representations of the operands were then observed and when they changed their size the link between them and the operation symbol were redrawn. Note that the representation of the operation does not assume anything about the representation of the operand, which could be provided later Fig. 6. The mathematical tree projection in PrEdE. 286

297 and being not known to the provider of the operation representation. The projection of the operation verify if it possible to use the tree-view for the operands (we provided a tree-view projections for immediate integers and the basic operations). If it is not available the projection preferred for the operand it is used. 4.4 Discussion The projections implemented in this case-study could be reused in implementing editors for common programming languages. Some general purpose languages (GPLs) offer a specific operator for exponentiation (ˆ,**) while others relay on a library function (java.lang.math.pow in Java). The same concept is represented in different ways, this can be regarded as syntactic noise. PrEdE permits to reduce syntactic noise using the most appropriate notation. We think that using the right notation is important. Consider the expression shown in figure 5: how long it takes to understand what would happen to the result modifying a certain value, i.e. the 1 appearing as last number in the expression? We are confident this kind of tasks would be easier and less error prone using the correct notation in PrEdE instead of the common textual notations adopted in widely used programming languages. The goal of PrEdE is to make the implementation of this notations affordable and permits not expensive extendibility both on the semantic and the notational level. 5 Related work There are two proper language workbenchs based on projectional editors which are well-known. Both are based on proprietary formats: i) the Intentional Domain Workbench, from IntentSoft, ii) the meta-programming system (MPS), from JetBrains. The Intentional Domain Workbench is not available for evaluation and so information on it it is limited. It represents the first application of Intentional Programming [14]. The tool was first described in a paper presented at OOPSLA 06 [15] and it introduced a shift from Intentional Programming to Intentional Software stressing the importance to include non-programmers in the software development process. While the tool developed at Intentional Software is not publicly available they presentated some demos 3 at programming conferences and let examine their tool by external experts, i.e. experts from ThoughtWorks including Martin Fowler. MPS is the most mature projectional editor tool publicly available but the last version released at the time of writing (version 1.5) still lacks some features we consider important, like the ability to support more than one notation for each element. Moreover it is not easily extendible with custom representations, only textual representation are reasonably easy to realize while no documentation is provided about graphical ones. Finally it is a closed environment, and

298 interoperability with other tools is quite limited; the only possibility for interoperability that we are aware of it is a tool to export models from the proprietary format of the tool to the EMF format (but not the viceversa). It was recently realized by Vöelter 4. Vöelter recently reported an experience report on use of projectional language workbenches [16]. He reported on designing a Software Product Line for embedded development using the JetBrains MPS tool. Vöelter is one of the main contributors to the suite Eclipse Modeling. 6 Conclusions and future work In this paper we presented a prototype of a projectional editor for Eclipse which reuses the infrastructure provided by the Eclipse Modeling project, a flexible platform widely used to realize model-driven solutions. Because PrEdE produces EMF models, it can be used to edit existing models and its adoption does not lead to lock-in problems, being the produced models available to be edited with other tools. In this paper we described the approach we chose to design and implement the projectional editor and discuss the characteristics of this kind of tools. We want to continue developing PrEdE and eventually release it as opensource in the next future as soon as the tool reaches a sufficient stability. As future work we would like to implement an extensible editor for a General Purpose Language as Java, for example reusing components already available in the EMF Ecosystem like JaMopp [6]. References 1. Andy Clark and David J. Chalmers. The Extended Mind. Analysis, 58(1):7 19, Daniel C Dennett. Making Tools for Thinking. Oxford University Press. 3. Edsger W. Dijkstra. The humble programmer. Commun. ACM, 15: , October Martin Fowler. Language workbenches: The killer-app for domain specific languages? M. D. Gross. Visual languages and visual thinking: sketch based interaction and modeling. In Proceedings of the 6th Eurographics Symposium on Sketch-Based Interfaces and Modeling, SBIM 09, pages 7 11, New York, NY, USA, ACM. 6. Florian Heidenreich, Jendrik Johannes, Mirko Seifert, and Christian Wende. Closing the gap between modelling and java. In SLE, pages , Andrew J. Ko, Htet Aung, and Brad A. Myers. Eliciting design requirements for maintenance-oriented ides: a detailed study of corrective and perfective maintenance tasks. In Proceedings of the 27th international conference on Software engineering, ICSE 05, pages , New York, NY, USA, ACM

299 8. Bernhard Merkle. Textual modeling tools: overview and comparison of language workbenches. In Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion, SPLASH 10, pages , New York, NY, USA, ACM. 9. Nancy J. Nersessian. How do engineering scientists think? model-based simulation in biomedical engineering research laboratories. Topics in Cognitive Science, 1:730757, K-M Park. Factors contributing to korean students high achievement in mathematics. ICME 10, Martin Pütz and Marjolijn H. Verspoor. Explorations in linguistic relativity. John Benjamins Publishing Co., Technology Review. Science and linguistics. Whorf, Benjamin, 42(6), Edward Sapir. The status of linguistics as a science. Language, 5(209), Charles Simonyi. The death of computer languages, the birth of intentional programming. Technical Report MSR-TR-95-52, Microsoft Research, SEP Charles Simonyi, Magnus Christerson, and Shane Clifford. Intentional software. In OOPSLA, pages , Markus Voelter. Implementing feature variability for models and code with projectional language workbenches. In Proceedings of the 2nd International Workshop on Feature-Oriented Software Development, FOSD 10, pages 41 48, New York, NY, USA, ACM. 17. Alfred North Whitehead. An introduction to Mathematics. Williams & Northgate,

300 Combining SysML modelling with refinement checking in Eclipse Denis Makartetskiy and Riccardo Sisto Politecnico di Torino C.so Duca degli Abruzzi 24, Torino, Italy Abstract. The gap between modeling and verification activities causes a hurdle for system engineers. Usual practice shows that these activities are wrongly separated during development phase and some time passes after modeling is finished and verification started. It slows system development and can impact the quality of end product. This work aims at overcoming this problem for particular cases of modeling and system level verification, namely for SysML requirements modeling and refinement checking in trace semantics. 1 Introduction During the development of safety critical embedded systems it is mandatory to couple modeling activities with appropriate verification activities. In system engineering, modeling can be done by SysML [4], a UML-based semi-formal notation that enables both the representation of system block diagrams as well as the specification of requirements for them. In the Eclipse ecosystem, SysML modelling is supported by MDT Papyrus [2]. Like many other modeling tools, MDT Papyrus has no built-in verification functions, but the open-source and extensible nature of Eclipse makes it possible to add them as a plugin. Depending on the context, different V&V activities are applied to a model. Since it is impossible to cover all of them in a single work, we make a first step demonstrating a proof-of-concept for refinement checking of requirements. Requirements are organized hierarchically through several kinds of refinement relations. We say that one requirement is derived from another one if there exists a derive relationship from latter to former. Our objective is to extend Papyrus with a verification tool that can automatically verify whether certain derived requirements refine their parent requirements or not. In fact, this is not an easy task to be done manually. In their simplest form requirements are textual descriptions of desired properties. Textual description usually means ambiguity and impossibility of automatic processing. A more precise description of requirements is enabled by SysML, which lets state machines to be assigned to requirements, thus giving a formal representation of the corresponding expected system behavior. Our 290

301 Fig. 1. Workflow for refinement checking of SysML Requirements diagram simple idea is to exploit this possibility and to perform automatic verification of refinement between requirements having associated state machines. In this way, we put together modeling and V&V of system behavior within Eclipse environment so they could be easily performed in an iterative manner being as higher as possible on the abstraction level. 2 Basic techniques and tools Due to difficulty in verifying state machines in their UML representation, they can be translated into alternative descriptions suitable for formal verification. Communicating Sequential Processes (CSP) [3] is a mathematical model oriented basically on the description of concurrent systems and interaction between them. CSP seems a good choice because refinement checkers for CSP and tools that map UML Statemeachines onto CSP already exist. This section briefly presents these tools which are the base for the plugin. Refinement checking [1] is a formal verification technique that compares two models written in the same concurrent specification language and says whether one model refines another. Output of refinement checking represents an answer YES/NO and counterexample (if there is no actual refinement between system descriptions). There are several definitions of refinement relation. In this work we take into consideration trace refinement and refinement denotes trace refinement in the sequel of this paper. A trace of a model P refers to one of its possible executions. A trace is an ordered list of labels representing the time-ordered events and/or states occurring in that execution of P. Formally, given models P and Q one says that Q trace refines P if all the traces of Q correspond to possible traces of P. In this terms the counterexample is a trace which is presented in one description but absent in another one while it should be presented in both for refinement to be valid. 291

302 PAT [5] is a recently developed stand-alone formal verification framework that can be used for refinement checking on CSP models. The translation from UML Statemachine to CSP is included in PAT, which makes this tool very interesting for our purposes. 3 Plugin structure The plugin is composed of a single view with an intuitive graphical interface: a table showing refinement relationships of the current SysML model, a console and a couple of buttons. It is entirely written in Java with SWT as GUI toolkit. Besides Eclipse Platform itself the refinement checking plugin has the following dependencies: Eclipse MDT Papyrus for SysML modelling, Saxon XSLT Transformation Engine for extraction of finite state machines from SysML models, PAT for UML->CSP translation and for performing the refinement checking on statemachines. The plugin implements the tool chain depicted on Fig. 1 in a way invisible to the user. Thanks to interface simplicity (see Fig. 2), the user needs no special skills to perform refinement checking. Neither the user has to write CSP models for requirements, nor has to analyze manually the causes when refinement relation does not hold, because the plugin gives a counterexample as a point of divergence between models when a refinement assertion is not valid. Basically, the sequence of actions that the user needs to perform is: modeling SysML requirements diagram, assigning to the model state machines describing desired behavior corresponding to requirements, triggering automatic refinement checking process and analyzing verification results or errors. The plugin presents to the user all the derive relationships found in the model in a table view along with client and supplier requirements. This is done by parsing the XMI file that MDT Papyrus uses for storing the diagram. Once verification is triggered, an XSLT transformation is launched on the XMI representation of the SysML diagram. This extracts pieces of XML code that correspond to state machines and saves them into separate files in the file system. On the next step, the plugin invokes PAT for translating state machines extracted on the previous step into CSP notation. After having obtained CSP notations of state machines modelled inside MDT Papyrus for refinement checking to start, we put together pairs of state machines with established assertion of the following kind: StatemachineA refines StatemachineB. There is one pitfall here: transitions (events in terms of CSP) that are presented in StatemachineA but absent in StatemachineB need to be hidden using the CSP hiding operator. Otherwise, refinement will never be valid, since there would be traces in concrete StatemachineA that are not possible in abstract StatemachineB. When such transitions presented only in the concrete state machine are hidden, the verification engine simply ingnores them, though they are still shown within counterexamples. Finally, the composed verification model with CSP descriptions of statemachines and assertion is fed to PAT. As a result, whether an error or verification statistics is obtained, results are shown within the console window of the plugin view. 292

303 Fig. 2. GUI of the Refinement Checking Eclipse Plugin 4 Conclusions and Future Work The developed plugin is the meeting point between two techniques that are usually separated. The plugin provides a fully functional environment for verification of behavioral requirements. Not only UML Statemachines can be assigned to SysML requirements to verify them, but also other formal and semi-formal languages for description of behavioral patterns (e.g. Timed Automata, Buchi automata, etc). This extension of the presented approach is a subject for future work. References 1. Back, R.J.R., von Wright, J.: Trace refinement of action systems. In: Structured Programming. pp Springer-Verlag (1994) 2. The Eclipse Foundation: Papyrus Modelling Software (2011), url: eclipse.org/mdt/papyrus 3. Hoare, C.A.R.: Communicating sequential processes. Prentice-Hall, Inc. (1985) 4. Object Management Group: OMG SysML Specification (2006) 5. Sun, J., Liu, Y., Dong, J.S.: Model checking csp revisited: Introducing a process analysis toolkit. In: Proceedings of the Third International Symposium on Leveraging Applications of Formal Methods, Verification and Validation pp Springer (2008) 293

304 294

305 295

306 296

307 297

308 298

309 299

310 300

311 301

312 302

313 R Blending Talk and Work in Eclipse Alberto Bacchelli and Lorenzo Baracchi and Michele Lanza Faculty of Informatics - University of Lugano, Switzerland Abstract. Integrated Development Environments (IDEs) are isolated from those communication means that programmers use daily to interact with each other as if talk and work were unrelated in software development. We present R , an Eclipse plugin, that aims at filling this gap. R integrates communication in the IDE, allowing developers to quickly and easily retrieve s related to the class at hand, perform customized searches, or watch trends in discussions about code. R also allows developers to produce information, e.g., by rating the value of any message or by sending contextual s. 1 Introduction In software development, teamwork has become the norm rather than an exception [7]. A team of developers working on the same project must deal with coordination and collaboration issues, such as effectively sharing the design rationale behind an implementation (i.e., the most common information need for a developer [4]). To coordinate and collaborate, collocated developers favor face-to-face meetings [4] a communication means that causes frequent disruption of developers s attention (workers are interrupted every 7 minutes [6]), retains knowledge by few developers, cannot be archived effectively, and is unsuitable to globally distributed development projects. Developers, thus, replace face-to-face meetings with electronic communication. Viable options are instant messaging, wikis, forums, etc., but the decisive role is played by s. Indeed, Mailing lists are the bread and butter of project communications [3]. s evade time zones, do not disrupt the flow of developers, and can be used to talk about issues ranging from mere bug fixing to high-level design. Mailing lists archive messages, thus offering a historical perspective, and broadcast discussions, announcement, and decisions to all the participants, thus maintaining team coordination. Despite the importance of communication in software development, modern IDEs are isolated from this point of view. Even though developers spend most of their working time in IDEs (to write, read, debug, and understand code, and design new features) [5], they must interrupt their flow, switch the context, and use external programs (sometimes even a web browser) to manage their communication, particularly s. We present R , a plugin for Eclipse, which fills this gap. R was born as a lightweight recommendation system for s to help developers finding discussions related to any class within Eclipse. It proved to be useful to improve developers program comprehension and effectiveness [2]. Now R has grown and integrates communication in the IDE: It includes features such as writing, data visualization, social rating, continuous updating, and fast text searching. 303

314 Fig. 1. The R Eclipse Plugin 2 R User Perspective Figure 1 shows R from the users perspective. They can click on any entity in the augmented package explorer (1) or open/change a class in the editor (2), see related s in the s panel (3), organized in threads and sorted by date. With the search box (4), they can further refine their search using keyword and/or regular expressions. Users can perceive the relevance of classes from the point of view of mailing list discussions by means of two complementary perspective: In the package explorer, each entity is decorated with a number that shows the cumulative count of related s (5), while in the s visualization panel (6), one can see how the related s are distributed in time. This latter view shows the s related to the chosen class as a bar chart: The x-axis is a discrete timeline, split in bins of equal duration, and the height is the number of s exchanged during each period of time. This graph allows developers to see trends in discussions related to the chosen class. When users find a significant period and click on a bar, the s panel (3) shows only those s. Once an is clicked in the s panel, the content panel (7) shows its content with colors to denote quotation levels and emphasize the related class. R also enriches the code editor: When classes are mentioned in the source code, side markers give information about related s. With R , users can not only consume information, but also produce it. By selecting any number of entities in the package explorer and/or a snippet in the code editor and clicking a button a new is automatically prepared, whose body includes the chosen information. The Writer panel (8) shows the intermediate result. Users can then complete the message by hand. The code snippets and fully qualified names of entities are automatically included in the body. Certain s contain valuable discussions. Users can rate the importance of s in the panel (9), this rating will be shared and averaged with the other users, thus creating a social rating. 304

315 Mbox Mbox MBox files files files Server Mailing Lists MarkMail Service MBox Importer POP/IMAP Daemon MarkMail Importer Importing Layer R Server s Traceability Views Rating Infos CouchDB JSON JSON HTTP JSON JSON JSON Writing Composer Metrics Extractor Rating Engine Traceability Engine JS Visualizations R Plugin System Model SMTP Server Eclipse Fig. 2. The R s Architecture 3 R Design Perspective Figure 2 shows the architecture of R . Initially we devised a stand-alone solution, in which R was composed of the Eclipse plugin and simply used s stored in the users client [2]. This approach had disadvantages: For example, s had to be files in MBox format and could not be modified to avoid concurrency issues with the client; developers working on the same project could not share information such as rating; any computation (e.g., finding the links between classes and s) is done client-side and must be replicated by each client. Now R is made of a server (left-hand side of Figure 2) and an Eclipse plugin (right-hand side). The R server, to be installed by any organization willing to use R , relies on the document-oriented database CouchDB 1, which provides a RESTful JSON API accessible through HTTP requests. Being s stored in a document-oriented database, we are able to change the meta-model without having to migrate data to a new schema, and we can use MapReduce 2 functions to parallelize tasks among cores or clusters of computers. To populate CouchDB, we devised an Importing Layer that handles different sources (e.g., MBox archives, MarkMail 3 ), extracts the selected s, and instantiates them as documents in CouchDB. Moreover, we created a POP/IMAP daemon to handle newly received messages, thus keeping data updated. Any component of the R plugin that needs data directly queries the CouchDB server through HTTP requests by sending and receiving JSON objects. As an example we see how the Traceability Engine (TE) works in practice. When users open a class from the package explorer or change tab in the main editor, R automatically triggers the TE. Since the TE retrieves the links between classes and s by using lightweight text-matching techniques [1], it does not require additional information other than the fully qualified class name. The very first time users request s for a class, R plugin generates a new specialized CouchDB view that implements the linking procedure, and permanently add it to the database. From that

316 moment on, every time s for the same class are requested, the R plugin will query the view to obtain the s. The first time the view is run, CouchDB applies it to all the s to find the appropriate documents. The results will be stored and subsequent requests will be served almost in real-time. Moreover, since the view results are stored in a B-tree, when new s are stored, the view will be updated accordingly in logarithmic time. The rating engine is based on CouchDB update and view functions. The visualization panel (Point 6 in Figure 1) is based on HTML and Javascript. By using the SWT Browser, one can include HTML pages and interactive javascript within Eclipse and use java-to-javascript and javascript-to-java callbacks to make the view interacting with the environment. In this way, the same visualization can be accessed through a web browser outside of Eclipse (we can imagine a manager using this feature), all the effective javascript visualization libraries that are available can be used, and the IDE is more responsive than when using Eclipse visualizations. 4 Conclusion We presented the key features of R (online at p/r- /), an Eclipse plugin to integrate communication in the IDE. Users can not only retrieve the s discussing a certain class, but also write new messages, rate their importance, visualize trends, or search for keywords. We plan extend R by (1) offering -to-classes traceability (i.e., go from s to classes), and (2) adding a not-intrusive notifier to track new s on selected classes. Acknowledgements. Bacchelli is supported by the Swiss National Science foundation through the project SOSYA (SNF Project No ). References 1. Bacchelli, A., D Ambros, M., Lanza, M., Robbes, R.: Benchmarking lightweight techniques to link s and source code. In: Proceedings of WCRE 2009 (16th IEEE Working Conference on Reverse Engineering). pp IEEE CS Press (2009) 2. Bacchelli, A., Lanza, M., Humpa, V.: RTFM (Read The Factual Mails) augmenting program comprehension with r . In: Proceedings of CSMR 2011 (15th IEEE European Conference on Software Maintenance and Reengineering). pp (2011) 3. Fogel, K.: Producing Open Source Software. O Reilly Media, first edn. (2005) 4. Ko, A.J., DeLine, R., Venolia, G.: Information needs in collocated software development teams. In: Proceedings of ICSE 2007 (29th ACM/IEEE International Conference on Software Engineering). pp IEEE Computer Society (2007) 5. LaToza, T.D., Venolia, G., DeLine, R.: Maintaining mental models: a study of developer work habits. In: Proceedings of ICSE 2006 (28th ACM International Conference on Software Engineering). pp ACM (2006) 6. Mark, G., Gonzalez, V.M., Harris, J.: No task left behind?: examining the nature of fragmented work. In: Proceedings of CHI 2005 (SIGCHI Conference on Human Factors in Computing Systems). pp ACM (2005) 7. Sarma, A., Bortis, G., van der Hoek, A.: Towards supporting awareness of indirect conflicts across software configuration management workspaces. In: Proceedings of ASE 2007 (22nd IEEE/ACM International Conference on Automated Software Engineering). pp IEEE CS Press (2007) 306

317 Manhattan 3D City Visualizations in Eclipse Alberto Bacchelli, Francesco Rigotti, Lile Hattori, and Michele Lanza Faculty of Informatics - University of Lugano, Switzerland Abstract. Software visualization eases program comprehension through visual metaphors, which leverage the power of the human eye to identify colors, shapes, patterns, and differences. Even though many powerful software visualization tools exist, the majority of them consists of stand-alone systems that are not integrated with the development tools already in use. We present Manhattan, an Eclipse plugin that visualizes projects in the workspace as 3D cities. While working on a software system project, developers can see its representation, updated in real time according to the code changes performed. Moreover, Manhattan does not work in isolation: When other developers modify the same project in their Eclipse instance, Manhattan visualizes them to increase developers awareness to facilitate team collaboration and coordination. 1 Introduction The first requirement to properly evolve a software system is program comprehension: Before making changes, one needs to know what to change and how. However, understanding a software system is not trivial, because software systems are complex, intangible, and constantly evolving. Software visualization techniques can ease this process, as they allow one to perceive software through vision, the sense from which humans acquire most information [2]. Many powerful software visualization tools have been created to support program comprehension, design assessment, evolution analysis, and reverse engineering tasks. Most of these tools are not integrated on the IDE, thus forcing programmers to move away from the development environment. To best support developers, however, a software visualization tool should be tightly integrated in the development process and used throughout the entire life of the system. With these considerations in mind, we devised Manhattan, a software visualization tool in the form of an Eclipse plugin. Manhattan s goal is twofold: 1. Help developers to reason on a system, thus making it easier to understand its architecture, and, as a consequence, help them to properly drive the system s evolution. 2. Support collaboration between members of a development team by increasing each member s awareness of the activity of the team. Manhattan visualizes projects in the Eclipse workspace by using the 3D city metaphor devised by Wettel et al. in CodeCity [3][4], which exploits the similarities between software constructs and the urban landscape of a city. The city metaphor gives a shape to the otherwise intangible software, exploiting the human capacity to build a visual mental model of the system to ease its comprehension. 307

318 In addition, Manhattan improves awareness by showing to developers a living city where changes from the members of the team and potential conflicting code are animated with different colors and shapes. To do that, Manhattan relies on APIs provided by the Syde plugin for Eclipse [1]. Merge conflicts can be examined in an instance of Eclipse s Compare Editor opened from within the visualization. Fig. 1. The Manhattan Eclipse Plugin In Action 2 Manhattan In Action Figure 1 shows Manhattan working using our recommended setup: A dual-monitor layout in which one of the two displays shows the interactive city visualization. The city metaphor maps architectural elements to software entities: Projects are represented as cities, packages as districts, and classes as buildings. For space reason, further information about the 3D city metaphor can be found in the CodeCity website 1. In our approach, the dimensions of each building is mapped to the number of fields (NOF) and the number of methods (NOM) of any class. To clearly distinguish them, interfaces are represented by circular buildings in a special color. The user can navigate the city through the orbital mode, where the camera is fixed on a dome centered on top of the city and users move along the dome, or the first-person navigation mode, which gives full control over the movement and allows any kind of translation or rotation. By mouse hovering on any building, a tooltip that describes

319 the metrics (i.e., NOF, NOM, and LOC) of the corresponding class appears; by rightclicking, Manhattan opens the class in the Java editor. Manhattan also includes a focused view, in which only the chosen entities are displayed: The users select any number of entities and press the v key to activate this view. Moreover, by clicking on a class and pressing h, Manhattan presents a view with only the hierarchically related classes. To visualize systems and information, Manhattan needs a language-specific parser that extracts the model from the system s code. Manhattan exploits the abstract syntax trees provided by the language-integration plugins (e.g., JDT for JAVA). Currently, Manhattan handles JAVA projects by building on top of X-Ray 2, a software visualization plugin that uses the JDT APIs to extract projects information Fig. 2. Collaboration Support Visualization 3 Manhattan - Visualization of Collaborative Development Figure 2 how Manhattan visualizes information to improve collaboration and team awareness. Manhattan shows (i) the emerging conflicts in which the developer is involved, (ii) the classes that have been changed or deleted by the other developers, and (iii) the developer who modified a class more frequently. Manhattan can visualize the system while it is being changed by several developers in parallel, because Syde 3 monitors source code changes directly at each developer s

320 workspace. Thus, it captures changes and broadcasts its information at every build action, rather than at every commit. Let us consider a team of three developers working together and analyze their interaction from the perspective of developer 1. When any class is changed by someone other than 1, she sees the corresponding building turning yellow (Point 1). As soon as one of her colleagues removes any class, the building does not disappear in her view, but becomes orange (2). Supplementary change information is included in the tooltip description for classes (3), which lists the names of the developers who recently modified the given class. Developers are grouped by the kind of change they performed and those that deleted the class are put first. To visualize a conflict alert on a class, we put a sphere on top of its building (4). The color depends on the kind of conflict the sphere represents: Emerging conflicts are showed with a yellow sphere, while committed conflicts (those in which one of the involved developers has committed his changes) are shown with a red sphere. We also use the concept of conflict beacon: a spotlight positioned above of a conflict sphere and pointing towards the ground. These beacons illuminate an area of the city around their associated conflict spheres, so that conflicts are always clearly visible. After the user notices an alert and puts the mouse on the conflict sphere, the beacon is deactivated. 4 Conclusion We presented Manhattan (online at manhattan.inf.usi.ch), a plugin to visualize software systems as 3D cities within Eclipse. One of its key points is the tight integration with the IDE: Manhattan offers developers a high-level view of the system, updated in real-time, while it is being developed. Users can navigate on the representation of the system and interact with it, for instance, to obtain source code metrics (e.g., number of methods), or to directly open and read the corresponding code in the Eclipse editor. Manhattan offers focused views to concentrate on specific entities or on the hierarchy of a systems class. In the context of the city metaphor, Manhattan includes visualizations built on top of the Syde plugin s API to improve collaboration and team awareness. As future work, we plan to improve how we visualize change notifications and conflict alerts, by using simple textures and small animations. We also plan to provide an additional view of the city, focused on displaying code ownership information, based on the change information provided by Syde. Acknowledgements. Hattori is supported by the Swiss Science foundation through the project GSync (SNF Project No ). References 1. Hattori, L., Lanza, M.: Syde: A tool for collaborative software development. In: Proc. of ICSE 2010 (32nd Int l Conf. on Software Engineering). pp (2010) 2. Ware, C.: Information Visualization: Perception for Design. Morgan Kaufmann (2004) 3. Wettel, R.: Software Systems as Cities. Ph.D. thesis, University of Lugano, CH (Sep 2010) 4. Wettel, R., Lanza, M., Robbes, R.: Software systems as cities: A controlled experiment. In: Proc. of ICSE 2011 (33rd Int l Conf. on Software Engineeering). pp (2011) 310

321 AsmetaRE: an Eclipse-based Environment for Requirements Validation via Use Case Models and Abstract State Machines Andrea Arnoldi 1 [email protected], Marco Dolci 1 [email protected], 1 DIIM, University of Bergamo, Italy. Abstract. Use cases are commonly used to structure and document functional requirements while formal methods, such as Abstract State Machines (ASMs) [1], are helpful to specify the behavior of a system and serve as a basis to validate system requirements. Therefore, automated support for the transition from use cases to formal models would provide significant, practical help for validating system requirements. This paper proposes a tool to automatically transform Use Cases Models into ASMs and then validate systems functional requirements through simulation and scenario-based simulation of the generated ASM formal models. The proposed approach is supported by an environment, called AsmetaRE, that is based on the Eclipse Modeling Framework an implementation platform for the Model driven Engineering principles of metamodeling and model transformation and the ACCELEO transformation engine to perform model transformations, and on the ASM analysis toolset ASMETA [2] to perform requirements validation. Requirements are only functional as a method driven by use cases is not suitable to treat non-functional requirements. Keywords: Requirements validation, use case models, abstract state machines, model transformation. 1. Introduction Developing complex and safety-critical systems requires precise, unambiguous specification of functional requirements. A formal specification language is thus well suited to this task. Formal specification languages require, but also exacerbate, the need for tools. In particular, tools should support the elaboration (how to build the formal specification) and the validation (how to check the adequacy of the specification towards the informal needs of the various stakeholders). In this work, we focus on describing the tool and the architecture of the AsmetaRE environment, with emphasis on the transformation from an instance of UCMeta to an Abstract State Machine. The work presented in this paper is related to the atoucan approach and tool [3], since the environment presented here takes as input Use Case models provided as 311

322 output by the atoucan enviroment. atoucan is merely aimed at transforming a Use Case Model produced with RUCM [4] into an UML analysis model made of class and sequence diagrams, activity diagrams and state machine diagrams, while establishing traceability links during transformations. A systematic literature review on transformations of textual requirements specifications into UML analysis models and related tools is in [7]. Our approach, however, is the first one (to the best of our knowledge) that involves a lightweight formal method (i.e. formal but without mathematical overkill) such as ASMs as target analysis framework. Fig. 1 An example of RUCM use case description related to the use case Withdraw Fund of an ATM system (taken from [3]) 2. The AsmetaRE Environment Fig. 2 shows the overall architecture of the proposed environment AsmetaRE. First, the framework receives in input a Use Case Model UCMod (an instance of the UCMeta metamodel) generated by the atoucan tool [3].Then, the main concern is to transform the input UCMod into an ASM (an instance of the AsmM metamodel) under the form of a textual specification written directly in the AsmetaL notation (as concrete syntax, human comprehensible). The result of such model-to-text transformation is an executable formal specification that serves as basis to perform requirements validation through the ASM analysis toolset ASMETA. Basically, two validation scenarios can be performed: basic simulation through the ASM simulator AsmetaS, and scenario based simulation through the ASM validator AsmetaV. In the second case, another model-to-text transformation is involved to generate also the simulation scenarios according to the textual notation Avalla of the AsmetaV tool. The overall transformation chain is implemented trough the ACCELEO model transformation engine [5]. 312

323 Fig. 2 AsmetaRe architecture The complete transformation code in ACCELEO, and the ASM modules and Avalla scenarios generated for the ATM system case study are provided at [6]. Fig. 3 A screenshot of the Eclipse-based AsmetaRE environment 313

324 2.1 Transforming Use Case Models into ASMs The transformation process, as shown in the AsmetaRE screenshot in Fig. 3, consists of two transformation paths. The first path automatizes a method for constructing an ASM formal model of the system behavior from the Use Case description expressing the stakeholders' functional requirements. The second transformation path produces in output either the ASM model of the system behavior and the use scenarios in the Avalla language of the AsmetaV validation tool, that the stakeholders can use interactively and cooperatively in order to explore different possible behaviors (or instance-level scenarios) of the system. These behaviors are automatically checked against the ASM formal requirements specification. 3 Conclusions and Future Work This paper presented a practical environment for the automatic formal functional requirements specification and validation. It combines the RUCM/UCmeta approach for use case modeling and the ASM formal support to specify and validate the system behavior. The environment is supported by a tool that exploits the EMF metamodeling environment, the ACCELEO model transformation engine, and the toolset ASMETA for ASM model execution and functional analysis. The effectiveness of our environment was experimented through various case studies of different complexity and heterogeneity, such as the ATM system, the Invoice Order system, the Sluice Gate Control system, and the Elevator system, to name a few, whose documentation can be found here [6]. These case studies have already given us some directions and priorities on how to extend the environment especially regarding additional RUCM sentences to be dealt, and the definition of a formal refinement schema to transform the generated ASM ground model that currently is merely useful for validation purposes only, i.e. as a throw-away prototype of the system into a more detailed and rich ASM model that can evolve till the final synthesis into code, at least for the most critical parts of the system behavior that require to be formally specified and analyzed. References 1. E. Börger and R. Stärk. Abstract State Machines: A Method for High-Level System Design and Analysis. Springer Verlag, The ASMETA toolset website T. Yue, L. C. Briand, and Y. Labiche. Automatically Deriving a UML Analysis Model from a Use Case Model. s.l. : Carleton University, Technical Report , October T. Yue, L. C. Briand, and Y. Labiche. Facilitating the Transition from Use Case Models to Analysis Models: Approach and Experiments. s.l.: Carleton University, Technical Report , September Acceleo website. [Online] Obeo T. Yue, L. C. Briand, and Y. Labiche. A systematic review of transformation approaches between user requirements and analysis models. Requir. Eng., 16(2):75-99,

325 A DSL to define process templates in Jazz/RTC Sam Golovchenko and Luca Pandolfo DEIS, Alma Mater Studiorum Università di Bologna viale Risorgimento 2, Bologna, Italy Abstract. In software design context, Rational Team Concert [2][3] is an application that integrates many actvities bounded to development process in collaborative way such as planning, source code management, work item management and build management. The wealth of RTC Jazz conceptual space, combined with the wide range of its features, provides great interest in both industrial and academic environments. Nevertheless there are several users[1][4] who have reported excessive complexity to understand this system in its initial using phases. This work aims to define an alternative approach to facilitate learning and use of RTC Jazz. For this purpose we have realized Domain Specific Language (DSL) to create process models in terms of RCT Jazz, highlighting its most important concepts. Keywords: MDD, RTC Jazz, DSL, Xtext2.0 1 Introduction: RTC Process Template A process model generally specifies the set of roles, practices, rules and phases in which a project should be formed and the order in which these phases should be executed. In Rational Team Concert (RTC) Jazz[3], projects are also related to their process and there are some predefined process models (e.g. Scrum, OpenUp). It is possible to make changes to a chosen model or even to create new ones (latter option can be complex[4]). In RTC a process model is represented through a template that is used for development process initialization. After initialization, process configuration can be modified according to some constraints like, e.g., work item type, plan type and other configuration data, that are imposed by the template. In RTC environment templates are specified in XML and, within the application, can be modified by a high-level graphical user interface or a simple textual editor. The syntactic structure of XML file is described by many XML Schemas (XSD) not all free accessible. Intervening directly on the XML file[4], the process model configuration is rather tricky: the syntax is not well documented, the wealth of details makes the template process semantics difficult to understand, XSD files that describe the XML file structure are not always easy to find, XML merges configuration datails with high-level process concepts, too many references to specific packages that are not present in any documentation. These 315

326 considerations persuade us to think that XML template is machine-oriented, difficult to understand by user but useful for process configuration in RTC enviroment (in List. 1.1 process template fragment represents a Role and two initial entities: Stream and a Component 1 ). <?xml version= 1. 0 encoding= UTF 8?> <process specification xmlns= process > <role definitions> <role d e f i n i t i o n c a r d i n a l i t y= many name= RTCUser r o l e id= RTCUser /> </role definitions> <project configuration> < initialization> <server initialization> <followup actions> <followup action xmlns= process/setupproject id= com.ibm.team. process. server. setupproject name= Example > <stream name= User Stream > <component name= UserComponent />... Listing 1.1. XML process template On the other hand, using only the RTC Jazz graphic interface for template editing, some possible configurations are neglected and others maintain a high detail. These issues in template configuration make process model understanding difficult. 2 PCL: Process Configuration Language Given the relevance of the template to characterize the model of a process, the first aim of this paper was collecting all the entities and settings of the RTC process template. processspecification Example { roledefinitions { RoleDefinition RTCUser;{ c a r d i n a l i t y many ; } } projectconfiguration { initialization { serverinitialization { followupactions { followupactionprocess Example ;{ stream { component User Component ; name User Stream ;... Listing 1.2. PCL process template Process Configuration Language (PCL) defines whole syntactic structure of process template and it is characterized by the same detail level of XML file (List. 1.2). This language includes the informations contained in various XML Schema 1 A Component is a collection of artifacts. A Stream is a repository object that includes one or more components. Typically, the components in a stream are related functionally so that they are grouped together. 316

327 (XSD) files extracted from several part of the RTC system. PCL makes template configuration more complete and facilitates the examination of all necessary entities of the template, their properties and relations. By using XSD files as a process template meta-model, we are able to define the PCL grammar in the Xtext language[5] and generator in Xtend2[5]. This generator allows to trasform template coded in PCL into process template coded in XML for RTC Jazz platform (M2C: model-to-code trasformation) (Fig. 1). This approach allows us to adapt the PCL grammar to possible changes of the XSD meta-model. Fig. 1. PCL platform By PCL language, through the auto-completion and a more precise syntax checking, creating a process template, or changing some features, is more immediate than intervening directly into XML file. Despite of these advantages, PCL provides an excessive level of detailing to interpret RTC Jazz process template (List. 1.2: PCL code fragment is referred to process template in List. 1.1). 3 PML: Process Modeling Language In the previous section, PCL properties affect the transparency of a process model. For this reason we have retained essential to create a higher-level language to highlight the most important elements of the RTC Jazz conceptual space. Reasoning by abstraction levels, PCL is a platform for the high-level languages development that includes all right process template configurations. PCL contibution has been essential to understand the importance of each RTC template entity in process modeling: what information it contains, what are the minimal properties required to mantain the semantic value. Process Modeling Language (PML) is an ongoing project since is not easy to define. It tries to represent a specific hierarchy of the most significant RTC Jazz entities. In fact PML maps some of elements expressed in PCL into more expressive concepts (List. 1.3: PML code is referred to PCL code in List. 1.2). PML doesn t propose to reproduce a generic process model but it limites to define a process model restricted to RTC process template. The PML grammar is realized in Xtext. Through Xtend2 generator process models in PML code are transformed into corresponding models in PCL code (M2C: model-to-code 317

328 transformation). This approach makes easier to map the PML conceptual space (whetever it will be) into XML and it makes flexible, regular and more documented a refactoring that could be indispensable (Fig. 2). Fig. 2. From PML to XML PML attempts to determine a simple syntax and common semantics. A high level abstraction would help to better understand the significant aspects of a model process (List. 1.3). ProcessTamplate Example { Role RTCUser; Stream User Stream { component User Component ; } } Listing 1.3. PML process template So process template configuration would become more accessible to user with limited informatic abilities. PML would also improve the communicative capacity facilitating informations exchange between members of a project. By approach described in paper, the abstraction level increase of DSL languages is easier. The knowledge exchange between workers of different specialties (client, analyst, designer, developer, etc... ) will always improve and it will adopt a universal language through which single platform indipendent process models could be defined. References 1. A. Gargantini, G. Salvaneschi, and P. Scandurra. On the downscaling of the jazz platform experimenting the jazz rtc platform in a teaching course, IBM. Home page S. Krishna and T. Fenstermaker. IBM Rational Team Concert 2 Essentials. Packt Publishing, C. Ping, C. Sunita, B. D. Ya, and D. Robert. Jazz as a research platform: experience from the software development governance group at ibm research, Xtext. Home page

329 A simple plugin for static security checks and program comprehension in Eclipse Andrea La Scola and Claudio Ferretti Università di Milano-Bicocca viale Sarca 336/14, Milano, Italy Abstract. Secure programming recommends static checking of the code you write. The properties to be checked, like the presence of calls to unsafe functions or having assignments of unfiltered user input to internal variables, can be automatically verified by parsing tools like compilers. Program comprehension can take advantage of similar tools, if paired to exploration and highlighting of source code. The paper presents an Eclipse plugin which allows the developer to input custom queries on methods and variables of a project, and results can be directly browsed through the usual platform interface. 1 Introduction This work shortly documents a first step in the development of a toolkit which exploits and extends the Eclipse framework, to give assistance to the developer in two types of activity: static security checking and program comprehension. These two activities share much of their underlying technologies, since both require tools which understand source files, according to syntax and semantics of the programming language being used. In static security checking the tools have to parse source code to discover unsafe constructs, like dangerous assignments or sequences of instructions which create race conditions prone to attack. Program comprehension, on the other hand, requires parsing to produce abstract representations of what the software does, so to help the developer working on legacy projects, for instance. In both cases the experienced developer will find useful to interact with the tools also by running icustom queries against the codebase, to check for properties that he will define each time according to what he will be analysing, for assessing security or understanding structures of the software. This is why we propose a tool allowing the developer to search inside an Eclipse project not only for strings or identifiers, but also for syntactical objects having properties that will be specified along with the query. At the same time Eclipse will offer a rich platform where to present, and browse, the code fragments selected by the search. The plugin currently only operates on Java projects. The technology will be based on the abstract syntax tree (AST) produced by the parsing engine already operating inside Eclipse. This representation has 319

330 been proved rich enough even in other projects (e.g. [3]). Other approaches, like having the compilers to produce the representation on which to perform searches (e.g. [1]) would be less cleanly integrated into Eclipse. 2 The ASTSearch Plugin The plugin we introduced is called ASTSearch, and operates in Eclipse as a popup menu. It offers to the user a textbox where to type her query, and after scanning the AST of the current project as made available by Eclipse, it lists in its window the items, methods and variables, matching the query. Fig. 1. Query and results in the plugin popup, and the highlighted code. Currently the query can be built according to a very simple language. For instance: the query Method returns the list of methods Variable returns the list of variables Method:str will list the methods with identifiers including strings str Variable:Declaration lists the places declaring variables Variable:Declaration:typ will list declarations of variables of type typ Variable:Assignment returns the list of assignments Moreover, more than one of the simple queries seen above can be concatenated in a single query separated by //: the union of the results of all the subqueries will be listed. 320

331 After performing the required search, the ASTSearch showing the list of selected items will allow to browse the relevant source code fragments. A double click on a selected item will open an editing window, if not already open, and will place the cursor on the first line cointaing the required method or variable use. A click on each listed item will show some information about it, like type of a variable and file containing it, or the return type of a method. The user will have to translate the required check into the simple query language, and running it she will quickly focus the manual analysis on the relevent source lines. 3 Future Work The plugin can already produce useful results, but it is conceived as a part of a framework centered on the Eclipse platform and aiming a assisting the experienced developer in improving her understanding of source code, and/or in checking for the presence of security flaws in it. Improvements can be expected along two directions. The interface will be made a view in Eclipse, while now it uses just a popup frame, so that for instance it will offer automatic updating of results when the code changes. Also, the results could presented together with the possible relationships among them, possibly by showing diagrams. For instance, items in the list of methods could be linked to the listed variables when the latter occour inside the former. The approach could similar to that of Sextant tool [2]. Another line of improvement concerns the expressivity of queries. While now they only check a series of single disjoint properties, it would be useful to be allowed to run queries of combination of properties, for instance looking for variables which receive values from other variables, which in turn satisfy a different property. For instance, this would be important if we need to perform checks similar to taint analysis. References 1. D. R. Engler, B. Chelf, A. Chou, S. Hallem. Checking System Rules Using System- Specific, Programmer-Written Compiler Extensions. OSDI: Symposium on Operating System Design and Implementation, pp. 1 16, T. Schafer, M. Eichberg, M. Haupt, M. Mezini. The SEXTANT Software Exploration Tool. IEEE Trans. on Software Engineering, vol. 32, no. 9, pp , A.I. Sotirov. Automatic Vulnerability Detection using Static Source Code Analysis, MS Thesis, University of Alabama,

332 Building a JEE application with Eclipse Marco De Luca and Giampiero Restaino Reply S.p.A, C.so Francia 110, Turin, Italy {mar.deluca,g.restaino}@reply.it Abstract. Java provides enterprises with several frameworks to build compact, reusable, scalable and secure software. In order to reduce the effort each component requires to be implemented, the Eclipse community produces uninterruptedly a number of plug-ins that provide developers with wizards, integration tools and checkers. We present which way Eclipse helps our company day by day in facing and satisfying our customers needs. We will present a real-world case study and discuss the solutions we offer to our customers. The presentation is equipped with screen shots and code extracts. Keywords: JEE, Eclipse, Case study, Java frameworks, Team work 1 Introduction Everyday the Java community produces new frameworks aimed to provide richer features and highly reusable code. Without the support provided by a strong IDE like Eclipse, the developer would be soon overcame. In industrial realities, reducing development effort is vital; the main aspects to consider in such an environment are: everything that can be done in an automatic way, must be done in such a way; projects need a strong control system in order to limit the number of defects introduced during development phases; resources and code are shared between team members; instruments to coordinate resource accesses are needed. Our discussion starts describing a simple case study based on a real customer need and presents the solution offered by the richest Java libraries to fulfill the request in an innovative, compact and efficient way. In facing the request of a customer, the analyst has to elaborate a clear formulation closer to the developer reality and the software architect needs to detect the instruments able to simplify the developer s job leading to a reduction of the required effort. Later on, we demonstrate the effectiveness of several tools provided by the Eclipse IDE in implementing the solution. 322

333 Resources control, sharing and coordination is crucial to limit the number of defects during development phases; Eclipse offers means such as SVN/CVS integration tools for source control and unit testing oriented plug-ins. The implementation of the projects used as example is based on JPA 2.0, EJB 3.0, Spring and JSF in a JEE 5 environment. 1.1 Our company In the companies network known as Reply, we are members of the group called Blue Reply. Blue Reply is the group company dealing with the planning and implementation of solutions based on the SOA/BPM model and developed using JEE/IBM Websphere technologies. Our offer focuses on defining the reference SOA/BPM architecture, implementing portals and web applications based on the web 2.0 paradigm and on defining and developing infrastructure solutions aiming at application security. Over the time, Blue developed specific references and competences in the consumer credit sector, by working with some of the main Italian Financial Institutions of the industry. Blue Reply boasts a privileged technological partnership with IBM, thanks to its highest certification level as Premier Business Partner. 2 Case study Our example customer works in fashion; he supplies several brands and his stores are spread all around Europe. In order to menage communications to suppliers and salesmen, it is necessary to know which brand each recipient is related to. The customer specifies that such a service will come in handy for several different applications in the future. 2.1 System architecture In order to start developing we need, at first, to design the system architecture and to identify subsystems and units of reuse. In our scenario, we start working from an existing database and we need to work in such a way to allow high reuse of our code even for future applications. To fulfill the requests, we need to build a service oriented architecture, a system where the business logic lies separated from other layers and can be shared between different application. In a JEE 5 environment, such a goal can be obtained exploiting EJB 3.0 capabilities. Figure 1 shows a canonical four-tier server architecture; this is the architecture we will follow to implement the requested feature. As depicted by Figure 2, EJB allows to work with such an architecture thanks to its robust support for implementing the business logic and persistence layers. 323

334 Fig. 1. Four-tiers architecture (picture from [1]). Fig. 2. EJB-added features to business logic layer (picture from [1]). 2.2 Building the system from the foundations Before creating the workspace, we need to detect the actors of the case study. Then, using JPA Tools included in Eclipse, will be possible to model the entities via Java classes and to automatically generate the corresponding tables on a database or, vice versa, to create the relational tables on the database and to generate Java entity classes from them. The entity level will be implemented following the Java Persistence API 2.0 specifications[2]. Since in our scenario we already have a populated database to read data from, we need to identify the tables necessary to implement our service and to generate Java entity classes from them (see Figure 3). All entity classes and persistence configuration elements will be grouped in a JPA project. 324

335 Fig. 3. Case study related entities: object-relational diagram. In order to create an highly reusable service, we chose to implement its logic by mean of one (or more) method(s) in a stateless session bean written following EJB 3.0 specifications[1]; this approach leads to the creation of two projects, one for interfaces and one for implementing classes: referencing the former and using Spring for the JNDI lookups, a dynamic web project will be able to use the services exposed by the session bean. Nowadays web applications are highly dynamic and client interactions with the server are mostly asynchronous; to implement such interactions on stateless structures as, for example, servlets, a lot of JavaScript code and an error prone management of request parameters and session attributes are required while JSF offers a framework that tightly couples web pages and back-end beans. Moreover, JSF developers community is very fertile, providing developers with libraries composed by several graphical components that can be used as black boxes to present, for example, tables with a nice look and feel automatically populated from a Java Collection stored in a bean. The effort reduction due to this kind of front-end framework is remarkable. 2.3 Setting up the workspace Like presented in Figure 4, the whole project is composed by four sub-projects: InformanizioNegozioJPA: contains classes and configuration xml files needed to handle persistence; InformanizioNegozio: contains the session beans responsible for business logic implementation; InformanizioNegozioClient: contains the interfaces of the session beans: the separation of classes and interfaces in different projects leads to an high decoupling that, together with JNDI capabilities and EJB features, allows 325

336 Fig. 4. Case study project structure. to invoke a service implemented in InformanizioNegozio even from a different EAR that does not include any source code but interfaces; WebApplicationJSF : contains the front-end implementation. Each sub-project is created using a wizard natively included into Eclipse. As hosting system for our software solution we often rely on IBM Websphere Application Server. The test environment for this application server can be embedded into an Eclipse-based IDE named IBM Rational Application Developer (RAD). For the implementation of our case study we used this IDE but every feature presented (but Websphere Application Server integration) can be found even in standard Eclipse IDE. 2.4 Motivations For large, complex, long-life webapps, using a Java framework may be more appropriate because the quality and maintainability of the code will be considerably higher. In fact, the strict structure of the language allows the programmer to write well-organized code in a easier and more natural way. In case of web applications, such an organization can be seen even as separation of the application layers: following the well-known MVC pattern, the team can increment his parallelism and the structure of each well-defined layer leads to an higher testability of code. Since in last ten years Java became the leader technology in enterprise environments, a lot of libraries were developed in order to support developers; many of these liraries are open source or proded under GPL[3]/LGPL[4] license. These instruments allow to produce high tech software in very strict time and this is a key element for enterprises. We could mention an infinity of utilities but in 326

337 Fig. 5. Using JPA Tools. the following sections we will focus on the key ones we use everyday in our work (Hibernate, Spring, JSF). Many server-side scripting languages supporters state that the complexity introduced by Java hosting systems leads to a remarkable waste of time in setting-up, developing and releasing web-based projects. Although Java application servers are complex systems and their configuration requires time and attention, the advantages they introduce justify the effort: a JEE application server can be configured to handle database connections, transactions, security, environment variables, objects registry, thread pools and much more. Last but not least, Java IDEs provide the developers with instruments such as typecheckers, verifiers, wizards and code generators that lead the resulting code to be cleaner and the software to hide less bugs. 3 Java EE tools 3.1 Entity layer - JPA tools We start our implementation by the domain objects. As mentioned above, following EJB 3.0 specifications, entity classes reside in a separated project that, for our case study, we call InformazioniNegozioJPA. This kind of project can be created by a wizard and popolated thanks to JPA tools (see Figure 5). The tool relies on a data source created into the IDE to query our database for metadata informations necessary to build entity classes. In fact, RAD can be easily configured to point to our development databases as shown in Figure 6. After the creation of our entities, we proceed populating classes with custom queries such as standard select-by-id and select-* queries. According to JPA 327

338 Fig. 6. Creating a RAD datasource. specifications, we use Java Persistence Query Language[5] in order to be DBMS independent in our implementations. 3.2 Business logic layer - EJBs wizard A stateless session bean can be accessed and by local and by remote location: the creation wizard used to create an EJB project and its session beans, creates the annotated class for the service implementation and both the interfaces. The wizard arranges a client project too in order to keep separated classes and interfaces when stateless session beans are created (see Figure 7). 3.3 Presentation layer - Dynamic Web Project For the presentation layer, the recommended approach is to use a Model-View- Controller pattern. Java offers several framework implementing such a pattern (SpringMVC[6], Struts2[7], JSF2 and others). Usually, this kind of framework require configuration by xml file(s) or annotations; this tedious and error prone operation is lighten by visual plugins for Eclipse-based IDEs: the developer specifies the desired rules by a graphical form and the IDE generates the required configuration code. To create a presentation layer project, the usual Dynamic Web Project wizard is used. 3.4 Team work - CVS repository integration Working on large projects requires the code to be shared among many developers. Eclipse-based IDEs provide integration with version control systems such as PVCS, CSV and SVN. Our teams rely on a CVS repository placed in the Reply private network. 328

339 Fig. 7. Creating EJB and EJBClient projects. Each developer downloads a copy of the source code from the central repository and starts working on it. When he wrote and tested his work, he can delivery it to colleagues synchronizing his local copy with the repository: the CVS view highlights the differences between the local copy of the project and the central one. In the example in Figure 8 we have two classes with differences in respect to the repository; we can see differences file by file (Figure 9) and decide what operation to perform: we could commit our code making available a new version for our colleagues or we could decide to undo our modifications overriding our local copy of the class with the central one. Moreover, other developers may have committed new code that we can pick from the repository by an update operation. 329

340 Fig. 8. Synchronizing resources with CVS. Fig. 9. Local/central class file differences. 330

341 References 1. D. Panda, R. Rahman, D. Lane: EJB 3 in Action. Manning Pubblications Co., Greenwich (2007) 2. The Java Persistence API - A Simpler Programming Model for Entity Persistence, 3. General Public License - Wikipedia, General_Public_License 4. Lesser General Public License - Wikipedia, Lesser_General_Public_License 5. Java Persistence Query Language official reference, docs/cd/e16764_01/apirefs.1111/e13046/ejb3_langref.html 6. SpringMVC reference page, current/spring-framework-reference/html/mvc.html 7. Struts2 official site homepage, 331

342 Extending the BPEL Designer with Xtext based editors (Extended Abstract) Lorenzo Bettini 1, Vincenzo Caselli 2, and Francesco Guidieri 2 1 Dipartimento di Informatica, Università di Torino, Italy 2 RCP Vision, Italy The Eclipse BPEL Project ( provides support for the definition, authoring, editing, deploying, testing and debugging of WS-BPEL 2.0 processes. In particular, it includes a GEF-based editor that provides a graphical means to author BPEL processes based on an EMF model that represents the WS-BPEL 2.0 specification. An interesting feature of the BPEL Project graphical editor is that it allows the programmer to provide a custom editor for specific expression languages to be used when editing the properties of a BPEL process. XTEXT ( is a framework for the development of programming languages as well as other domain-specific languages (DSLs). It provides high-level mechanisms that generate all the typical and recurrent artifacts necessary for a fully-fledged IDE on top of Eclipse. What we present here is a framework for using XTEXT editors as expression editors in the BPEL process editor. Our main requirement is that the programmer does not have to change any part of the code of his XTEXT editor: our framework provides all the infrastructure to embed any XTEXT editor in the BPEL editor. This way, all the functionalities related to the language implemented in XTEXT can be reused immediately, and the programmer can test the language functionalities in isolation from the BPEL editor. The BPEL project, in order to use a custom expression editor, requires to extend a specific abstract class, AbstractExpressionEditor, which will act as a wrapper for the actual editor; our framework provides an implementation of this abstract class, XtextBasedExpressionEditor, and, once provided with the Google Guice Injector ( of an XTEXT editor, it will be able to perform all the operations for the actual embedding of the editor as a BPEL expression editor. Besides that, the programmer will only have to use the specific extension points provided by the BPEL project in order to make the editor available in the BPEL graphical editor. The main problem we encountered when developing the integration of an XTEXT editor into the BPEL editor is due to a limitation of XTEXT itself: an XTEXT editor can only be opened with an input which corresponds to a physical file that has to be part of an Eclipse project. This poses problems since the text of expressions that have to be edited by an editor embedded in BPEL is saved in the BPEL process file itself. Thus, a natural solution would be to open an editor with an EditorInput bound to a stream of bytes from a string (see, e.g., How - do I open an editor on something that is not a file). However, due to the The first author has also been partially supported by MIUR (Project PRIN 2008 DISCO). 332

343 Fig. 1. Two Xtext editors embedded in the BPEL editor. above limitation of XTEXT editors, we cannot adopt this solution. Another possibility would be to write a brand new text editor and configure it with all the editor artifacts generated by XTEXT, like syntax highlighter, code completion, etc. (see, e.g., However, this has the drawback of duplicating efforts (you will have to write a lot of code to mimic the base XTEXT editor class), and future versions of XTEXT might require to adapt all this manual written code. Our solution was to provide the XTEXT editors embedded in the BPEL editor with an actual file in the current project as an hidden file, which is automatically filled with the contents of the expression to be edited (stored in the BPEL process file). This way, we are able to embed any XTEXT editor into the BPEL editor, as an expression editor. Without any further configuration, all the features of the XTEXT editor will work as expected, such as, e.g., syntax highlighting, error markers, code completion, etc. These hidden files will be automatically removed from the project when the corresponding XTEXT editor is closed. In Figure 1 we show a screenshot of the BPEL editor (left upper corner) with the properties view opened which uses two XTEXT editors for two different languages (two of the example languages which come with XTEXT). Note that the two XTEXT editors are integrated in the properties view of the BPEL editor and yet they provide all their functionalities (e.g., the error markers in the right editor). Indeed these two XTEXT editors have not been changed at all, since all the integration is performed by our framework. In the right upper corner of the IDE you can see the XML source code of the BPEL process where the actual contents of the XTEXT editors are saved. The framework presented here is available at 333

344 Rational Quality Manager and Rational Team Concert adoption in Tivoli Rome Lab Ilaria Gorga Software Engineer, IBM Alessandro De Micco Staff Software Engineer, IBM Abstract - Improve product quality it s a matter of both team process and tools adopted. In this article, we address this consideration by providing a story example showing the migration from TTT Notes DB text Documents to the development lifecycle approach, using Collaborative Application Lifecycle Management artefact integration. IBM Rational Team Concert Version and IBM Rational Quality Manager Version were used to achieve a new day-by-day process. Moreover, adopting those tools made architects, project managers, developers and testers able to feed and maintain in a centralized way the product artefacts linked together: product requirements, developed story and test cases are easily traced and tracked within a single point of entry. The entire above issues ensure the quality and completeness of the product delivered to customer. Introduction Starting from 2008, the Rome Lab has adopted the Rational Quality Manager (RQM) to support the test process. IBM Rational Quality Manager is a collaborative, Web-based tool that offers comprehensive test planning, test construction, and test asset management functions throughout the software development life cycle. Rational Quality Manager is based on the Jazz platform. The RQM introduction integrated with the RTC adoption, improved the implementation of the Agile development process in the Tivoli Lab. Main strengths identified using RQM are the following: 1. Project lifecycle management with a test plan centric approach Integrated test management with a WEB interface across all the test aspects (business objectives, test strategy, test cases, resources, environments, entry/exit criteria, risk assessment, plan and test cases review and approval, test tracking...). All project related data (iteration plans, test, and defects) are linked together. 2. Collaborative and adaptive test plan management Structured and customizable test plan with multiple user defined sections, possibility to assign different ownership for specified sections, team collaboration improvements 3. Collaborative and adaptive test cases design Test cases easy to create, maintain and evolve, test cases re-use, possibility to assign different ownership for specified sections 4. Easy link between RTC epics-stories and requirements and test cases on RQM For example, it is possible to link test scenarios defined in RQM with related user stories entered in RTC. Increased requirement traceability and direct linking with test cases identified for a specific requirement 5. Execution paths optimization Easy determination of the most efficient configuration coverage patterns and execution paths and related execution record generation 6. Extensible and open architecture Leverage test automation feature provided by RQM integrating automated test suites developed internally 334

345 7. Test Assets and Test environments management Test asset discovery, inventory and software provisioning by RQM. Structured test environment definition. Automated test environment installation and direct linking with test cases. Requirements definition A clear and detailed description of product requirements is one of the most effective elements to have a product release starting with high-level quality. Moreover, traceability of requirements through the software development lifecycle is a key factor to easily identify whether all requirements are developed and have a proper level of test coverage. Product Management was populating a Lotus Notes DB repository, giving access to a restricted list of people to discuss and refine product requirements list. This process lead to some side effects: limited list of empowered people; a time consuming process to define, refine and maintain requirements list artefact; information kept isolated and unlinked to other product artifacts. So, we moved requirements definition and management in Rational Quality Manager. Because RQM comes with a built-in tab that allows the business analyst to populate a database by simply complete a web form. You can see an example of defining a requirement in Figure 1. Figura 1 Requirement definition using RQM 335

346 The inserted requirements are then collected and collected in a view like the one shown in Figure 2. Figure 2 Requirements view in RQM This adoption makes the entire team empowered to contribute to discussion on requirements design and development; the fast access to the web interface makes the tool availability uninterrupted; it makes the requirements record ready to be associated with other artefacts. 336

347 Design your Test Plan The product test plan is the central artefact in our process workflow. It describes the scope of the test and the strategy adopted to ensure product quality. It contains assumptions; risk assessment; list platform coverage and software dependencies; test phase entry and exit criteria; quality objectives and more. This was usually accomplished by writing a text document from a single author, then stored on a Lotus Notes DB for review process from a close list of reviewer and then saved untouched once approved. But, as the Agile methodology is adopted in our organization several of the Test Plan items change rapidly. The effect of that is that we need to adopt a new tool to respond to the changes. Again, we found in RQM the right tool to solve this issue. When you create a test plan in Rational Quality Manager, you can design the plan on a template containing section that you can create, based on your needs. You can also create several templates suitable for different teams working on different aspects of the product, like the component verification tests, the scalability and performance tests, the globalization verification tests, and the integration test. All of those teams have their own customized Test Plan but all of them centrally managed and linked to the other product artefacts. So, the following figures show details of our Quality Assurance phase. Meaningful section for our process are now easily designed and kept update by web interfaces access. Figure 3 Summary of TWS QA test plan 337

348 Each section is different but all of them have an editor (Figure 4) while some sections, provide a rich-text editor having usual capabilities: font selection, inserting pictures, creating tables. Figure 4 Objectives defined in the TWS QA test plan Other sections have a specific layout and behaviour, like the Test Schedules shown in Figure 5. Figure 5 Test schedules for TWS QA test plan 338

349 The picture below shows the project test schedules and a S-curve approach in completing the test effort. In our process, especially coming from PMR analysis, we decide to specify the environment condition in which to test. Figure 6 Execution Trend report view In the Test Plan definition, it s possible to associate a list of Test Environments as shown in Figure 7. Figure 7 Test Environments associate with the Test Plan Again, RQM allows us to manage such kind of information in a centralized way. Information is stored in the database and from now on it will be easy to be retrieved and compared in next product release or to be a reusable asset. 339

350 Test Case Definition Test cases are fundamental to maintain the desired level of quality in the developed product. Test cases are the declaration of the objective for the test team to state that the product works as expected. In the past, each test team member was asked to design test cases in several artefacts like text document, or sheet document that would be aggregated in a document called Test Design. Again, after a review and approval phase such a document would be added on a Notes DB as a record for the testing quality process. Problems were: different granularity in designing test case because different author style or skills; redundancy of test cases; lack of clarity on expected results since developed artefact could differ from the starting picture. Rational Quality Manager provides a built in test-case template with some predefined sections that you can modify in order to obtain your own template. You can reference and link your requirements with the test case. And you can link a test script to the environment you execute it. You can see an example of Test Cases list in Figure 8. Figure 8 Test cases list 340

351 Test Execution Records The physical execution of a test script, associated to the environment dedicate to run it, it is called Execution Records. By tracking the list of execution of those records and by knowing the weight (the effort) of each one of those, the product management and the product team itself get the execution progress of the overall product. In the past, a manual insert and modification of entries in a Notes DB, plus the association of style-sheet document obtained those tracking purposes. This produced an isolated level of project control, with the entire team out of the chance to verify in real time the product status. The sense of feeling part of the global lifecycle was totally missed. With RQM and RTC, we come to the opposite: daily scrum meeting attended by the team, in which each team member reports its daily duties or problem to be addressed make the entire team responsible to insert and update any kind of information that goes to the product tracking. In RQM, by running the Execution Record trough a console an automated process is computing the executed effort. An example of execution record is shown in Figure 9. Figure 9 Test execution record You can even design your test script by hand, so to uniform different author style in a template manner. (Figure10) 341

352 Figure 10 Test Script overview You can manually or automatically execute a test script (Figure 11) Figure 11 Test script execution And finally you can adjust the status of the test script. An example of test execution result is shown in Figure

353 Figure 12 Test execution result 343

354 Defect Management When a designed test script execution encounters a problem on the developed software you need to open a defect to manage this event. In the past, we manually opened and managed defects on an additional tool called CMVC. This tool was a shared point for tester, developer and product management to count and track all the defects encountered and resolved on the project. Then, the tester manually inserted on the Notes DB called TTT defect id extracted from CMVC and associate it to the test script. And also defect management was a problem since any change on CMVC has to be manually reflected on TTT. In RQM simply go the View Execution Results. Select the records and simply you can add the defect with a web form. Figure 13 Defect definition We decided to set up unified database access between Rational Quality Manager and Rational Team Concert so you can create and track defects in Rational Team Concert. You can also create and track defects in the Rational Quality Manager since the information is shared and no duplicated. We usually open the defects from the RTC console for the CVT phase, while in RQM in the SVT phase. This because, CVT is mostly tracked on RTC since stories are linked to basic component test, while SVT is a complex and large test cases list where RQM is the central tool, as seen in previous chapters. 344

355 Reporting Capabilities We already talked about our tracking process. We move from Style-sheet document to the reporting capabilities of RQM and RTC. This mean a process evolution from static business analysis to a dynamic project indicators evaluation, based on data warehouse query. RQM gives a predefined list of built-in reports: Figure 13 List of reports To run each of them you have just to select values from field in a mask and the output will be shown (Figure 14-15): Figure 14 Report generation 345

356 Figure 15 Sample of report in RQM The example above is based on the Execution Trend of our product Quality Assurance Phase. But another built in report is very useful: we talked on the beginning of the article about the key value added from clear evidence in linking Requirements to Test Cases. Here is a report coming from our product: 346

357 Figure 16 Sample of report in RQM Depending on analyst interest, you can look at information by requirements, tester, owner, test plan, or environment. While in RTC, trough a BIRT programming customization, a project dashboard is showing product indicator to provide daily status: 347

358 Figure 17 TWS Dashboard Test assets and Test environments management In a Development Software Lab the test asset management gains a key role, indeed to ensure successful software deployment, it is crucial to have a stable environment dedicated to testing. The Verification Team in Rome has a machine fleet composed by hundreds of physical and virtual machines. Each team has tens of assigned machines. The mainly difficulties in managing a lab that size are described below: Inventory: each machine (physical or virtual) has to be inventoried. For each machine is required to collect technical information (hardware and software data) and business information (i.e. machine owner). Keep track of machines updates: all the collected information needs to be up to date. Each change must be notified. For example, an operative system change or owner change. Sharing the machines data with stakeholders: all the machines data need to be shared with the stakeholders. There are different stakeholders, with varying levels of interest: for example the lab manager needs to know the high level machine information, a tester want to know all the configuration information about the machine assigned to a project, etc. The kind of information to share is different based on the stakeholders. Reservation: the resources should be reserved for any longer than is strictly necessary. We identified two reservation levels: project level reservation and team level reservation. The first is related to the reservation for a 348

359 project, when a project starts, a group of machines is reserved for it. The second one is related to the machines reservation in the same team, a single tester reserves a machine for own test. Definition, configuration and installation of test environment: during the test plan preparation, the test leader defines the test environments. A test environment is a logical description of the environment required for a specific test or group of test. When a tester needs to execute a test, he has to configure and install a physical environment. It s very important to have an environment ready for the test in the shortest possible time. Sharing the test environment data with stakeholders: when an environment is ready for the test, it s important to share all the information about this environment with the other team component. For all the issues identified above, RQM provides us a solution. In the following section we compare the solution used before RQM adoption and the RQM solution. Inventory: In the past, several tools were used to collect the information about the IT assets: a tool collected the technical data for physical machine, a tool collected the business data, a tool collected the data for virtual machines, a tool managed the virtual machines request, etc. Mainly, the data were manually updated. RQM, in the Lab Management section (Figure 18), provides an interface to extend and customize the inventory capabilities. TPM provides an extension of RQM Inventory capabilities (TPM Adapter). TPM Adapter uses the TPM discovery to find the machines (for example all the machines contained into an IP range).the collected data are automatically imported into RQM. In this way the information is always up to date. The physical and virtual machines are described in RQM using the Lab Resource artifact. Figure 18 Lab Management tool 349

360 Keep track of machines updates: In the past, each tool manages the data update in different way. Usually, the data were manually updated. Using the Lab Management extension, for example the TPM Adapter, the information could be automatically updated. The update request could be triggered manually or automatically. Sharing the machines data with stakeholders: As said previously, the stakeholders could be different. Different stakeholders are interested to different information. So, another problem, using several tool is that each user needed several account and on each tool was defined several roles. Using RQM as central information access point, we assign different roles to different users. This is important because the role associated with each account determines the options that are available and the functions that can be accessed in the lab manager editors. Reservation: In the past the project level reservation was managed by a specific tool. The team level reservation was managed with sheet document or mails. The problems with this reservation management were: static management, each team keeps the machines the entire duration of the project, also if the hardware machine is not required for the test, each person was owner of some machines and he kept them also if he no longer used them. Again, RQM allows us to manage such kind of information in a centralized way. To reserve the machine is need to specify the time interval. The reservation management is transparent, all user view the machine reservation status. It s possible to integrate RQM with tools to know the effective use of a machine during a time interval. Figure 19 shows a sample of reservation for a Lab Resource. Figure 19 Reservation of a lab resource 350

361 Definition, configuration and installation of test environment: The steps to have a ready to use test environment are: definition of test environment (components and prerequisites), environment configuration, machines retrieval, machines reservation, middleware software installation and product build installation. In the past, each team leader was asked to design test environment associated to each test cases, in several artefacts like text document, or sheet document. Again, after a review and approval phase such a document would be added on a Notes DB. Problems were: a time consuming process to define, refine and maintain requirements list artefact; information kept isolated and unlinked to other product artefacts, for example, there wasn t a link between a logical environment (the logical description of an environment) and a instance of the test environment (a list of real machines and configurations that compose an environment). The retrieval of the machines in order to instantiate a test environment was done using sheet document, this document was manually updated. Problems were: keep the information up to date about the various test configurations and keeping track of who is running what tests on which machines. The environment was installed almost always manually. The test automation environments are installed using automation, but they are predefined and preconfigured. All test environment life cycle can be managed using basic RQM features and RQM extension. The test environment can be defined using the Test Environment artifact. The tester defines all the environment components. For each component, he can define the prerequisite for the component (for example a specific operative system, a required middleware ) Figure 20 shows a sample of Test Environment definition. Figure 20 Sample of Test environment definition 351

362 When a Tester needs to instantiate a test environment, he defines a Test Cell associated with the specific Test Environment. In the Test Cell, RQM associates a lab resource for each component defined in the associated test environment, if it s available. Figure 21 shows a sample of Test Cell. Figure 21 Sample of a Test Cell The machines reservation could also be done starting from a Test Cell definition (Figure 22). Figure 22 Reservation of Test cell components 352

363 You can reference and link your Test environment and Test Cell with a Test Case or a specific Test Execution Record (Figure 23). Figure 23 Relation between Test case and Test environment/test Cell You can link a specific Test Cell with a test script, so you can run the script on the specific environment. The environment configuration (for example middleware installation) could be done using the integration between RQM and the Tivoli Provisioning Manager, called TPM Adapter. The product under test could be installed using the integration between RQM and the Test Installation Suite Automation, called Build Provisioning Adapter. The Build Provisioning adapter (BP Adapter) uses RQM API to perform several operations programmatically with the data in RQM repository (create, read, update, and delete the data in RQM repository). Figure 24 shows a sample of operations provides from BP Adapter. 353

364 Figure 24 List of BP Adapter operations Sharing the test environment data with stakeholders: The information sharing about the installed test environment was done using sheet document, manually updated. Problems were: keep the information up to date about the various test configurations and keeping track of who is running what tests on which machines. As said previously, RQM API enables several operations with the data in RQM repository. The BP Adapter uses the API to update automatically the test environment information after an install operation. For example, if we use the BP adapter to install a specific TWS Component on a lab resource, the adapter updates automatically the Lab Resource information (Figure 25). Figure 25 Sample of software information automatically updated for a Lab Resource 354

365 Conclusion In this paper, we have shown as the Rome Lab takes advantage of RQM Adoption. The RQM and RTC capabilities made possible to design a fully integrated architecture for Test and Development. In the specific, RQM provided to the Verification team a unique tool to cover all test phases, based on integrative and collaborative approach. This change is not immediate, but the Rome Lab is changing little by little. Several points discuss in this paper are underdevelopment or in pilot projects. Next steps are related to the integration between RQM and other IBM products (official products but also internal products as Test Automation Suite). Resources: The official site of RQM: The official site of RTC: RQM jazz communities: RTC jazz communities: Developerworks site: IBM developerworks is the industry-leading and award-winning technical resource and professional network for the developer community. 355

366 Parasoft Test: Complete Development Lifecycle Testing Daniele Marsico, Clémence Soulat Parasoft Italia, Rome, Italy Abstract. Parasoft Test is a platform for integrating testing throughout all stages of the software development lifecycle. In addition to delivering the industry's most comprehensive set of capabilities for Java, C, C++,.NET, SOA, Web, Cloud, and message/protocol testing, Parasoft Test also provides task management and peer code review capabilities that support any programming language. It was developed in response to the rising number of teams leveraging multiple automated testing techniques together in order to release applications more rapidly, with greater confidence.[1] Keywords: ALM, task management, SLDC, static analysis, unit testing, collaborative development 1 Parasoft Test. Parasoft, leading provider of Automated Error Prevention software, joined the Eclipse consortium in 2002 to help support, create and define policies, practices and technology for the open source tool development platform[2]. As result of this work Parasoft released a framework and a suite of products based on Eclipse named Parasoft Test. Parasoft Test provides developers a practical way to prevent, expose, and correct errors in order to ensure that their code works as expected. To promote rapid remediation, each problem detected is prioritized based on configurable severity assignments, automatically assigned to the developer who wrote the related code, and distributed to his or her IDE with direct links to the problematic code and a description of how to fix it. Tools integrated into Eclipse are the following: 1. Parasoft C++test and Jtest. Parasoft C++test and Jtest are integrated solution for automating a broad range of best practices proven to improve software development team productivity and software quality for C, C++, Java. They facilitate: 356

367 Static analysis static code analysis, data flow static analysis, and metrics analysis Peer code review process automation preparation, notification, and tracking Unit testing unit test creation, execution, optimization, and maintenance Runtime error detection memory access errors, leaks, corruptions, and more This provides teams a practical way to prevent, expose, and correct errors in order to ensure that their code works as expected. 2. Parasoft SOAtest Parasoft SOAtest automates web application testing, message/protocol testing, cloud testing and security testing. Parasoft SOAtest ensures secure, reliable, compliant business processes and seamlessly integrates with Parasoft language products (e.g., Parasoft Jtest) to help teams prevent and detect application-layer defects from the start of the SDLC. Parasoft SOAtest provides is an integrated solution for: End-to-end testing: To continuously validate all critical aspects of complex transactions, which may extend beyond the message layer through a web interface, ESBs, databases, and everything in between. Environment management: To reduce the complexity of testing in today's heterogeneous environments with limited visibility/control of distributed components or vendor-specific technologies. Quality governance: To continuously measure how each service conforms to the often dynamic expectations defined by both your own organization and your partners. Process visibility and control: To establish a sustainable workflow that helps the entire team efficiently develop, share, and manage the evolution of quality assets throughout the lifecycle. 2 Conclusions Today's complex, distributed applications and transactions needs much more effort by developer and testers. Parasoft Test meets their needs providing a platform for integrating testing throughout all stages of the software development lifecycle. References 1. Parsoft: Parasoft Test: Complete Development Lifecycle Testing Parasoft: Parasoft Joins Eclipse

368 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ISBN >