SPARQL Query Splitter: query translation between different contexts

XIV Jornadas de Ingenier´ ıa del Software y Bases de Datos San Sebasti´ an, 8-11 de septiembre de 2009 Editores: Antonio Vallecillo Dept. Lenguajes y Ciencias de la Computaci´on ETSI Inform´atica Universidad de M´alaga Bulevar Louis Pasteur, 35. 29071 M´alaga. Spain e-mail: a[email protected] Goiuria Sagardui Departamento de Electr´onica e Inform´atica Escuela Polit´ecnica Superior Mondragon Unibertsitatea Loramendi, 4; 20500 Arrasate-Mondrag´on.Spain e-mail: [email protected] Filmaci´on e impresi´on: Gr´aficas Michelena Dep´osito Legal: SS-988-2009 ISBN: 978-84-692-4211-7 Pr´ ologo Las XIV Jornadas de Ingenier´ıa del Software y Bases de Datos se celebraron en San Sebasti´an del 8 al 11 de septiembre de 2009, en el incomparable marco del Palacio Miramar, siendo organizadas por la Escuela Polit´ecnica Superior de la Universidad de Mondrag´on. Como viene ocurriendo desde la edici´on del 2001, se han celebrado, en paralelo y compartiendo algunos actos, de las IX Jornadas de Programaci´on y Lenguajes (PROLE). Ambos eventos son organizados bajo los auspicios de SISTEDES, la Sociedad de Ingenier´ıa del Software y Tecnolog´ıas de Desarrollo de Software. Este volumen recoge los trabajos seleccionados por el Comit´e de Programa de JISBD 2009. Este a˜no se han incluido tres tipos distintos de contribucionesen las actas. En primer lugar tenemos los art´ıculos de investigaci´on originales, que describen resultados de investigaci´ono experienciasindustriales relativas a los campos de la Ingenier´ıa del Software y de las Bases de Datos. Se recibieron un total de 81 resumenes preliminares, de los cuales 75 se plasmaron finalmente en art´ıculos. Entre ellos el Comit´ede Programa decidi´o seleccionar 22 como art´ıculos largos. Esto ha supuesto un ratio de aceptaci´on del 29%, lo que demuestra el arduo proceso de revisi´on y selecci´on al que fueron sometidos los art´ıculos, as´ı como la calidad de los finalmente seleccionados. Adem´as de estos art´ıculos, otros 5 fueron seleccionados para participar en la conferencia como art´ıculos cortos, con la idea de favorecer y estimular el debate cient´ıfico entre los asistentes y dar cabida a la presentaci´on de trabajos incipientes. Todos los art´ıculos fueron revisados siguiendo un sistema de revisi´on por pares, y discutidos entre los miembros del Comit´e. Adem´as de este tipo de art´ıculos, este a˜no tambi´en se ha incluido en las actas los res´umenes de las demostraciones de herramientas presentadas, y de los art´ıculos relevantes ya publicados. Las demostraciones de herramientas son el camino para demostrar la viabilidad pr´actica de las propuestas te´oricas y metodol´ogicas formuladas por los equipos de investigaci´on, y una muestra de lo que pueden aportar a la ciencia y a la industria. En esta ocasi´on se seleccionaron 23 herramientas para ser brevemente presentadas durante las sesiones, y expuestas durante las Jornadas. Por otro lado, la madurez de la comunidad JISBD se plasma en un n´umero creciente de trabajos publicados en revistas y congresos de primera l´ınea. Muchos de estos trabajos pasan desapercibidos para la comunidad al no tener un reflejo en las propias Jornadas, m´as orientadas hacia trabajos emergentes. Por ello, JISBD acoge desde las ´ultimas dos ediciones la presentaci´on de este tipo de publicaciones, con un doble objetivo: por una parte, publicitarlos dentro de las propias jornadas; por otra, ofrecerlos como gu´ıa y est´ımulo al resto de la comunidad.En esta ocasi´on se incluyen en las actas los res´umenes de los 10 trabajos seleccionados por la organizaci´onen esta categor´ıa. El ´exito de la conferencia JISBD tambi´en se refleja en el n´umero de eventos que suceden a su alrededor. En primer lugar, JISBD 2009 cont´o con tres conferenciantes invitadosde primernivel:DonBatory (DepartmentofComputerSciences, Universityof Texas at Austin, EE.UU.) que imparti´o la charla “Stepwise Development of Streaming Software Architectures”; Jean B´ezivin (University of Nantes, Francia) con “Advances in Model Driven Engineering”; y Houari Sahraoui (Universidad de Montreal, Canada), cuya charla fue “Put the Horse before the Cart: Task-Driven Development of Software Visualization Tools”. Nuestro agradecimiento m´as sincero por su disponibilidad para aceptar la invitaci´on y venir a San Sebati´an a impartir sus conferencias. El programade JISBD 2009 tambi´en incluy´odos tutoriales sobre temas de candente actualidad, como son las l´ıneas de producto y el desarrollo dirigido por modelos. Otro de los puntos fuertes de JISBD son los Talleres, que conforman punto de reuni´on obligado para los investigadores que trabajan en algunos temas de especial inter´es, y que ofrecen un foro de discusi´on excelente para estimular el debate y la colaboraci´onentre ellos. Este a˜no se ha contado con 6 Talleres, algunos de amplia tradici´on como ADIS (9aedici´on), DSDM (6aedici´on) o PRIS (4aedici´on) y otros m´as noveles como son PNIS, ZOCO o WASELF. Nos gustar´ıa expresar nuestro m´as sincero agradecimiento a todos los miembros del Comit´e de Programa por su tiempo y dedicaci´on a la hora de revisar y seleccionar los art´ıculos que fueron finalmente aceptados para su presentaci´on, y que han permitido confeccionar un a˜no m´as un programa de gran calidad y nivel. Por supuesto, queremos tambi´en agradecera los autores que enviaron art´ıculos a las Jornadas, fueran finalmente aceptados o no, por el esfuerzo realizado y por su contribuci´on al evento. Tambi´en queremos agradecer desde aqu´ı al equipo organizador todo su esfuerzo y trabajo. Esto incluye a los organizadores locales de la Universidad de Mondrag´on, que han permitido hacer realidad esta conferencia, as´ı como a los distintos Coordinadores que se han ocupado de organizar aspectos esenciales como los Talleres (Coral Calero), Demostraciones (Juan de Lara), Tutoriales (Ernest Teniente), Divulgaci´on de Trabajos Relevantes ya Publicados (Bel´en Vela), Publicidad (Gentzane Aldekoa y Jos´eRa´ul Romero), Actas (Leire Etxeberria) y Web (Ana Altuna). Nos gustar´ıa tambi´en mostrar nuestro agradecimiento al Comit´e Permanente de las JISBD: primero, por depositar en nosotros su confianza a la hora de presidir el Comit´e de Programa y organizar la conferencia; y segundo, por su constante apoyo y soporte. Menci´on especial merece Oscar D´ıaz, cuyos consejos y ayuda han sido siempre inestimables.Tambi´en mencionarel sistema de revisi´on de art´ıculos que hemos utilizado, EasyChair, que fue de gran utilidad y ayuda durante todo el proceso de revisi´on y para la confecci´on de estas actas. Nuestro agradecimientoexpl´ıcito a los patrocinadores del evento que hicieron posible que la conferencia fuera todo un ´exito: las empresas Intersystems y Ulma, la Asociaci´on de T´ecnicos en Inform´atica (ATI), la revista Nov´atica, las Universidades de Mondrag´on y del Pa´ıs Vasco, Cursos de Verano, el Gobierno Vasco, el Ministerio de Ciencia e Innovaci´on, la caja de ahorros Caja Laboral y la Corporaci´onMondrag´on. Muchas gracias a todos los asistentes a las JISBD 2009, y esperamos verles de nuevo en las pr´oximas JISBD 2010. San Sebasti´an, Septiembre 2009 Antonio Vallecillo Goiuria Sagardui Comit´ e Ejecutivo Presidente del Comit´ e de Programa Antonio Vallecillo (Univ. M´alaga) Presidenta del Comit´ e Organizador Goiuria Sagardui (Univ. Mondrag´on) Coordinadora de Talleres Coral Calero (Univ. Castilla-La Mancha) Coordinador de Demostraciones Juan de Lara (Univ. Aut´onoma Madrid) Coordinador de Tutoriales Ernest Teniente (Univ. Polit. Catalu˜na) Coordinadora de Divulgaci´ on de Trabajos Relevantes ya Publicados Bel´en Vela (Univ. Rey Juan Carlos) Coordinadores de Publicidad Gentzane Aldekoa (Univ. Mondrag´on) Jos´eRa´ul Romero (Univ. C´ordoba) Coordinadora de actas Leire Etxeberria (Univ. Mondrag´on) Coordinadora de la Web Ana Altuna (Univ. Mondrag´on) Comit´ e Organizador (Univ. Mondrag´ on) Goiuria Sagardui Joseba Andoni Aguirre Gentzane Aldekoa Ana Altuna Merixell Armentia Lorea Belategui Itxaso Buruaga Leire Etxeberria Osane Lizarralde Urtzi Markiegi Xabier Sagarna Comit´ e de Programa Abrah˜ao, Silvia (Univ. Polit. Valencia) Acu˜na, Cesar (Univ. Rey Juan Carlos) Aldana, Jos´e (Univ. M´alaga) ´ Alvarez, B´arbara (Univ. Polit. Cartagena) Aramburu, Mar´ıa Jos´e (Univ. Jaume I) Araujo, Joao (Univ. Nova Lisboa) ´ Avila, Orlando (Open Canarias) Ba˜nares, Jose A. (Univ. Zaragoza) Berlanga, Rafael (Univ. Jaume I) Bertrand, Enrique (Software AG) Boronat, Artur (Univ. Leicester) Brisaboa, Nieves (Univ. Coru˜na) Cabot, Jordi (Univ. Oberta Catalu˜na) Cachero, Cristina (Univ. Alicante) Canal, Carlos (Univ. M´alaga) Canos, Jos´e Hilario (Univ. Polit. Valencia) Carretero, Baltasar (T-Systems) Cavero, Jos´e Mar´ıa (Univ. Rey Juan Carlos) Corchuelo, Rafael (Univ. Sevilla) Costal, Dolors (Univ. Polit. Catalu˜na) Crespo, Yania (Univ. Valladolid) de la Riva, Claudio (Univ. Oviedo) Delgado Kloos, Carlos (Univ. Carlos III) Dolado, Javier (Univ. Pa´ıs Vasco) Duran, Francisco (Univ. M´alaga) Fdez-Bertoa, Manuel (Univ. M´alaga) Fdez-Medina, Eduardo (Univ. Castilla-La Mancha) Franch, Xavier (Univ. Polit. Catalu˜na) Fredlund, Lars-Ake (Univ. Polit. Madrid) Fuente, Pablo de la (Univ. Valladolid) Garbajosa, Juan (Univ. Polit. Madrid) Garc´ıa Molina, Jes´us (Univ. Murcia) Garc´ıa, F´elix (Univ. Castilla-La Mancha) Gaspar da Silva, Mario (Univ. Lisboa) Genero, Marcela (Univ. Castilla-La Mancha) Genova, Gonzalo (Univ. Carlos III) G´omez, Jaime (Univ. Alicante) Gonzalez, Daniel (Univ. La Laguna) Go˜ni, Alfredo (Univ. Pa´ıs Vasco) Guerra, Esther (Univ. Carlos III) Hern´andez, Juan (Univ. Extremadura) Hogdson, Peter (Procedimientos Uno) Irastorza, Arantza (Univ. Pa´ıs Vasco) Iribarne, Luis (Univ. Almeria) Iturrioz, Jon (Univ. Pa´ıs Vasco) Juristo, Natalia (Univ. Polit. Madrid) Laguna, Miguel A. (Univ. Valladolid) Llorens, Juan (Univ. Carlos III) Lopes, Antonia (Univ. Lisboa) Lopez Cobo, Jose M.(XimetriX) Lozano, Adolfo (Univ. Extremadura) Melia, Santiago (Univ. Alicante) Mena, Eduardo (Univ. Zaragoza) Moreira, Ana (Univ. Nova Lisboa) Moreno, Ana Mar´ıa (Univ. Polit. Madrid) Pelechano, Vicente (Univ. Polit. Valencia) Pimentel, Ernesto (Univ. M´alaga) Polo, Antonio (Univ. Extremadura) Quer, Carme (Univ. Polit. Catalu˜na) Riquelme, Jos´e (Univ. Sevilla) Rito, Antonio (Univ. Tec. Lisboa) Roda, Jos´e Luis (Univ. La Laguna) Ru´ız, Francisco (Univ. Castilla-La Mancha) Ru´ız-Cort´es, Antonio (Univ. Sevilla) Sagardui, Goiuria (Univ. Mondrag´on) Samos, Jos´e (Univ. Granada) S´anchez, Fernando (Univ. Extremadura) S´anchez, Juan (Univ. Polit. Valencia) S´anchez, Victor (Open Canarias) Toro, Miguel (Univ. Sevilla) Toval, Ambrosio (Univ. Murcia) Trujillo, Juan Carlos (Univ. Alicante) Trujillo, Salvador (Ikerlan) Tuya, Javier (Univ. Oviedo) Urp´ı, Toni (Univ. Polit. Catalu˜na) Vicente, Cristina (Univ. Polit. Cartagena) Revisores Miguel ´ Angel Mart´ınez Luz Marina Moreno de Antonio Isabel Brito Nuno Cardoso Dante Carrizo Ana Cerdeira-Pena Antonio Corral Diego Alonso Javier C´amara Jose Mar´ıa Garc´ıa Irene Garrig´os Anna Grim´an Jorge Garc´ıa Ignacio Garc´ıa Sergio Ilarri Ernesto Jimenez Beatriz Bern´ardez Joaqu´ın Lasheras Manuel Llavador Esperanza Manso Miguel Angel Martinez-Prieto Enric Mayol Jose-Norberto Mazon Fernando Molina Sonia Montagud Ma´ Angeles Moraga Isabel A. Nepomuceno-Chamorro Jes´us Pardillo Juan ´ Angel Pastor Jennifer Perez Javier P´erez Manuel Resinas Roberto Rodr´ıguez-Echeverr´ıa Roberto Ruiz Sergio Segura Manuel Serrano Pedro S´anchez Mari Carmen Otero Jose Zubcoff Patrocinadores Tabla de contenidos I Conferencias Invitadas Advances in Model Driven Engineering................................. 3 Jean B´ ezivin Stepwise Development of Streaming Software Architectures ................ 4 Don Batory Put the Horse before the Cart: Task-Driven Development of Software Visualization Tools ................................................. 5 Houari Sahraoui II Sesi´ on 1. Verificaci´ on y pruebas Generaci´on de Pruebas Basada en Restricciones para Consultas SQL.......... 9 Mar´ ıa Jos´ eSu´ arez-Cabal, Claudio de la Riva, Javier Tuya Selecci´on de Caracter´ısticas para Mejorar los Modelos de Verificaci´on de Informaci´on en EAI ................................................ 21 I˜ naki Fern´ andez de Viana, Jos´ e Luis Arjona, Jos´ e Luis ´ Alvarez, Pedro Abad An´alisis de los Efectos de las Pol´ıticas de Gesti´on de la Capacidad de los Servicios en el Cumplimiento de los SLAs utilizando Simulaci´on ............ 33 Elena Orta, Mercedes Ruiz, Miguel Toro A tabu search algorithm for structural software testing (Art´ ıculo ya publicado) .. 45 Eugenia D´ ıaz, Javier Tuya, Raquel Blanco, Jos´ e Javier Dolado WebAVLTester: Una Herramienta de Pruebas Funcionales Autom´aticas para Formularios Web (demo) ............................................ 46 Eugenia D´ ıaz, Marta Fern´ andez de Arriba, Roberto L´ opez GAmera: una herramienta para la generaci´on y selecci´on mediante algoritmos gen´eticos de mutantes WS-BPEL (demo)................................ 50 Antonia Estero, Inmaculada Medina, Juan Jos´ e Dom´ ınguez, Lorena Guti´ errez III Sesi´ on 2. Gesti´ on de Proyectos TUNE-UP: Seguimiento de proyectos software dirigido por la gesti´on de tiempos 57 Mar´ ıa Isabel Marante, Patricio Letelier, Francisco Su´ arez Parte I Conferencias Invitadas Advances in Model Driven Engineering Jean B´ezivin University of Nantes Abstract. When the MDATM was firstintroduced, the main idea was toproduce a platform specific model (e.g., a Java program) from a platform independent model (e.g., a UML model). As more general Model Driven Engineering (MDE) practices met success, models increasingly represent new situations or phenomena not initially imagined. In addition todevelopment-time models, maintenancetime and execution-time models are more and more frequently used. But we have now a richer classification of models. For example we may have models of the data or models of the dynamic behavior of a system and much more. This has much impact on the operations that may apply to these different kinds of models. The talk will summarize the past evolution and discuss the current research agenda in MDE based on the more precise model classification and broader spectrum of operation on them. The quest for unification of software artifacts with models is still going on but the applicability scope of MDE is at the same time rapidly broadening. The synergy between these two processes produces a very active research and development field that will be discussed in the presentation. Short Biography Jean Bezivin is professor of Computer Science at the University of Nantes, France He presently leads at Ecole des Mines de Nantes the AtlanMod INRIA research team. He got a Master degree from the University of Grenoble and a Ph.D. from the University of Rennes. Since 1980 he has been very active in Europe in the object-oriented community, starting the ECOOP series of conference, the TOOLS series of conferences, and more recently the MODELS/<<UML>> and the ICMT series of conferences. He founded in 1979, at the University of Nantes, one of the first Master programs in Software Engineering entirely devoted to Object Technology (Data Bases, Concurrency, Languages and Programming,Analysis and Design, etc.). His present research interests include model engineeringand more especially the techniques of model transformation applied to data engineering and to software forward and reverse engineering. He has published many papers and organized tutorials and workshops in the domains of concurrency, simulation, object-oriented programming, and model-driven engineering. On the subjects of model driven engineering and MDATM, he has been leading the OFTA industrial groupin France, co-animating a CNRS specific action and the Dagstuhl seminar #04101. He is a member of the ECOOP, MODELS, TOOLS and ICMT steering committees. He was co-chair of ECOOP’2006 and PC chair of TOOLS’2007 Actas JISBD 2009, pp.3, ISBN: 978-84-692-4211-7 c 2009 Los autores Stepwise Development of Streaming Software Architectures  Don Batory Department of Computer Sciences The University of Texas at Austin Austin, Texas, 78712 U.S.A. Abstract. We present simple and practicalModel DrivenEngineering techniques to develop, explain, test, and verify designs of streaming software architectures. We develop component-connector architectural models incrementally by transforming them into progressively more elaborate architectures, and optimize these architectures for efficiency and crash-fault tolerance. Two case studies are presented: join parallelizations in database machines and recoverable, crash faulttolerant server architectures. Short Biography Don Batory holds the David Bruton Centennial Professorship in the Department of Computer Sciences at The University of Texas at Austin. He was an Associate Editor of IEEE Transactions on Software Engineering (1999-2002), Associate Editor of ACM Transactions on Database Systems (1986-1992),a member of the ACM Software Systems Award Committee (1989-1993; Committee Chairman in 1992), Program Co- Chair for the 2002 Generative Programming and Component Engineering Conference. He is a leading researcher on feature-oriented software development. Over the last ten years, he and his students have written 11 Award Papers for their work in automated and component-based program development. Joint work with Taylor L. Riche Actas JISBD 2009, pp.4, ISBN: 978-84-692-4211-7 c 2009 Los autores Put the Horse before the Cart: Task-Driven Development of Software Visualization Tools Houari Sahraoui Universidad de Montreal, Canada Abstract. Software visualization isan efficientand flexible toolto perform maintenance tasks that are difficult to automate. It allows inspection and analysis of large sets of software data at various levels of detail. Many visualization environments have been proposed during the last two decades. For the most, they use interesting visualization metaphors and are powerful and scalable. On the other hand, one cannot but notice that they are almost unused outside the small community that developed them. One explanation of these phenomena is that the adequacy of the environments for the targeted tasks is questionable. Indeed, the choices made during the development of these environments are not (explicitly) motivated by the nature of the targeted tasks. This makes it difficult for common users to understand, learn, and use them in concrete situations. In this talk, we present principles and guidelines to develop software visualization tools by considering explicitly the nature of the data and actions involved in maintenance tasks. These principles are illustrated through the visualization environment VERSO. Short Biography Houari A. Sahraoui is Professor of Software Engineering in the Department of Computer Science and Operations Research of the University of Montreal. He obtained his Ph.D. degree in 1995 in computer science, with specialization in meta-modeling and model transformation, from the Pierre & Marie Curie University, Paris. His research interests include the application of artificial-intelligence techniques to software engineering, software visualization, object-oriented measurement and quality, and reengineering.He has been on the program, steering, or organizationcommittees of many international,IEEE andACM conferences,and is memberof theeditorial boardof three journals. He was the general chair of the IEEE Automated Software Engineering conference in 2003. Actas JISBD 2009, pp.5, ISBN: 978-84-692-4211-7 c 2009 Los autores Parte II Sesi´ on 1. Verificaci´ on y pruebas Actas JISBD 2009, pp.9-20, ISBN: 978-84-692-4211-7 ©2009 Los autores Generación de Pruebas Basada en Restricciones para Consultas SQL María José Suárez-Cabal, Claudio de la Riva, Javier Tuya Departamento de Informática – Universidad de Oviedo Campus Universitario de Gijón, s/n {cabal,claudio,tuya}@uniovi.es Abstract. En este artículo se describe un enfoque para generar automáticamente datos de prueba para consultas SQL, incorporando tanto información del esquema de la base de datos como de las propias consultas a probar. Las diferentes situaciones de prueba sobre las consultas se identifican a partir de un criterio de cobertura de condiciones y se representan mediante un conjunto de restricciones que la base de datos debe cumplir. Utilizando el constraint solver Alloy, se generan instancias de la base de datos que satisfacen las restricciones, y que constituyen una carga de prueba de la base datos. Se ilustra y evalúa la propuesta con un caso de estudio de una aplicación real. Keywords: Pruebas del Software, Criterio MCDC, Pruebas sobre Base de Datos, Generación de datos de prueba, Alloy constraint solver 1 Introducción Entre las actividades más comúnmente utilizadas en la prueba del software destacan la generación y ejecución de los casos de prueba. Mientras que la ejecución de los casos de prueba es, en muchos casos, fácilmente automatizable, la generación de los datos de prueba es, en la mayoría de los casos, una actividad con un fuerte componente manual, y por lo tanto, muy sujeta a errores. Esta generación manual es especialmente dificultosa en aquellos casos donde las entradas son estructuras de datos complejas, como ocurre en el caso de aplicaciones basadas en bases de datos. Varios trabajos y herramientas han contemplado el problema relativo a la generación de instancias de base de datos, como por ejemplo [5] [2] [10]. Sin embargo, en la mayoría de las situaciones, los procesos de generación de datos tienen en cuenta únicamente la estructura de la base de datos y sus restricciones, pero no las características de las consultas a probar, por lo que los datos generados pueden no ser útiles para la prueba de las consultas. Recientemente, la problemática asociada a las pruebas sobre bases de datos ha centrado la atención de varios investigadores, desde diferentes puntos de vista. Uno de ellos es la definición de criterios de suficiencia que permitan evaluar la calidad de los datos de prueba en relación con las consultas SQL y que a la vez sirvan como guía para el diseño de nuevos casos de prueba [8] [10] [11]. Otro es el relativo a la generación de los datos de prueba tomando como base la información de la consulta a 16 XIV Jornadas de Ingeniería del Software y Bases de Datos Para soportar estas características, es necesario proporcionar definiciones adicionales para los operadores relacionales, de forma que tengan en cuenta la presencia de valores nulos. Estos predicados se definen en Alloy como una función que devuelve cierto, falso o NULL dependiendo de la presencia o no del valor NULL en los operandos en el momento de su evaluación. A continuación se muestra la especificación para el operador relacional de igualdad. Para el resto de operadores relacionales, la definición sería similar. open util/boolean //Manejo de tipos True y False fun eq [x:Int+NULL,y:Int+NULL]:(Bool + NULL){ (isNotNULL[x] and isNotNULL[y]) => (x=y => True else False) else NULL } Así, la regla C2 quedaría codificada como sigue: some p:Profesor.pfilas,a:AsignaturaImpartida.afilas | (eq[pid[p],pref[a]]=True) and ((eq[creditos[a],2]=False) and (eq[responsable[a],1]=False)) 3.3 Generación de instancias de la base de datos Una vez modelado el esquema de la base de datos (sección 3.1) y cada una de las reglas de cobertura generadas a partir de la consulta a probar (sección 3.2), se ejecutará el analizador de Alloy con el objetivo de generar una instancia de la base datos de forma que ésta satisfaga todas las reglas de cobertura. Esta instancia representa una carga de prueba para la base datos que satisface a su vez el criterio SQLFpc. Para ello, todos los predicados que definen a cada una de las reglas de cobertura serán encapsulados en un único predicado en Alloy, de forma que en única ejecución del analizador se generen los datos en las tablas que cubran todas las reglas. La siguiente especificación ilustra lo anterior para un esquema formado por dos relaciones R y S y n reglas de cobertura derivadas de la consulta a probar. pred test [t1:R,t2:S] { <Predicado correspondiente a la regla de cobertura 1> … <Predicado correspondiente a la regla de cobertura n> } La ejecución del analizador con el comando run test generará filas en cada una de las tablas para cumplir todos los predicados. Aunque la exposición se ha limitado a una única consulta a probar, el enfoque anterior es válido y aplicable a más de una consulta SQL, cada una de ellas con varias reglas de cobertura: un único predicado encapsula todas las restricciones que representan a todas las reglas de cobertura de todas las consultas. De esta forma, se instruye al analizador para generar un único conjunto de datos cubriendo diferentes situaciones de prueba para varias consultas SQL. XIV Jornadas de Ingeniería del Software y Bases de Datos 17 4 Caso de Estudio Con el objetivo de mostrar el uso del enfoque desarrollado en este artículo, se va a generar una base de datos de prueba a partir de las consultas SQL extraídas de una aplicación real. La aplicación seleccionada, denominada HelpDesk, gestiona en la Universidad de Oviedo solicitudes de servicio y propuestas de cambios de software y hardware corporativo de usuarios finales, así como los distintos estados (anotaciones) por los que puede pasar una solicitud. Todos los experimentos se han realizado sobre un PC Intel® Core ™2 Duo a 2GHz. con 3GB. de memoria, utilizando la versión 4.0 de Alloy. Para el caso de estudio se ha extraído una muestra de las consultas SQL de la aplicación con diferente complejidad y se ha considerando únicamente la parte del esquema de la base de datos que se utiliza en las consultas seleccionadas. En la Tabla 1 se muestran las tablas con las columnas que las componen, el tipo de cada una, las restricciones de valores NULL, las claves primarias (PK) y las claves ajenas (FK), junto con la columna a la que hacen referencia. Tabla 1. Descripción de las tablas Tabla Columnas (nombre, tipo, restricciones de valores NULL , PK o FK) Usuario ID int, NOT NULL, PK IDArea int, NULL, FK referencia a Usuario.ID Solicitud ID int, NOT NULL, PK IDReceptor int, NOT NULL, FK referencia a Usuario.ID IDPropietario int, NOT NULL, FK referencia a Usuario.ID Anotacion ID int, NOT NULL, PK IDSolicitud int, NOT NULL, FK referencia a Solicitud.ID AntIDPropietario int, NULL, FK referencia a Usuario.ID Las consultas extraídas para el caso de estudio se muestran en la Tabla 2 (donde los parámetros se representan con la notación ?Num?) junto con el número de reglas de cobertura generadas (situaciones de prueba a cubrir de acuerdo al criterio SQLFpc) para cada una (20 en total). Tabla 2. Código SQL de las consultas seleccionadas y número de reglas generadas Id Código SQL NºReglas Q1 SELECT id FROM Solicitud WHERE (ID=?1?) AND ((IDReceptor=?2?) OR (IDPropietario=?2?)) 5 Q2 SELECT s.id FROM Solicitud s LEFT JOIN Anotacion a ON s.ID=a.IDSolicitud WHERE (s.ID=?1?) AND ((s.IDReceptor=?2?) OR (s.IDPropietario=?2?) OR (a.AntIDPropietario=?2?)) 8 Q3 SELECT s.id FROM Solicitud s LEFT JOIN Anotacion a ON s.ID=a.IDSolicitud LEFT JOIN Usuario u ON a.AntIDPropietario=u.ID WHERE (s.ID=?2?) AND (u.IDArea=?1?) 7 18 XIV Jornadas de Ingeniería del Software y Bases de Datos Siguiendo el procedimiento descrito en la sección 3, se ha generado la especificación Alloy para el esquema de datos de la Tabla 1 y las restricciones para las reglas de cobertura de las consultas de la Tabla 2 encapsuladas en un único predicado. La ejecución del analizador con la especificación anterior genera una instancia de la base de datos (Tabla 3) que permite satisfacer el conjunto de las reglas de cobertura para todas las consultas. La base de datos contiene 3 usuarios, 5 solicitudes y 5 anotaciones, y el tiempo de generación es de 7,6 segundos. Para validar los datos de prueba generados, se ha cargado la instancia de base de datos de prueba y, utilizando la herramienta SQLFpc (https://in2test.lsi.uniovi.es/sqltools/sqlrules/), se ha evaluado la cobertura de las consultas. El porcentaje de cobertura para todas las consultas es del 100%. Este resultado es el esperado, ya que en el propio proceso de generación se había indicado que todas las restricciones se debían cumplir. Tabla 3. Instancia de la base de datos generada automáticamente Usuario <ID,IDArea> Solicitud <ID,IDReceptor,IDPropietario> Anotacion <ID,IDSolicitud,AnIdPropietario> Filas <4, 5> <5, 4> <7, NULL> <1, 5, 5> <3, 4, 4> <4, 5, 4> <5, 5, 5> <7, 4, 7> <3, 7, 7> <4, 7, 4> <5, 5, 4> <6, 1, 7> <7, 3, NULL> La base de datos generada se ha comparado con una parte de la base de datos del HelpDesk (que contiene 501 solicitudes, 1.304 anotaciones y 261 usuarios, y a la que se hará referencia como base de datos de producción) desde dos puntos de vista: la cobertura alcanzada de acuerdo al criterio SQLFpc y la efectividad de los casos de prueba utilizando una técnica de generación de mutantes. Los resultados de la comparación se muestran en la Tabla 4. La columna %SQLFpc indica, para cada consulta, el número de reglas de cobertura generadas y los porcentajes de cobertura obtenidos con la base de datos de producción y la generada automáticamente. Como se observa, con la base de datos de producción se alcanza un 85,00% de cobertura frente al 100% de cobertura de la base de datos generada. La columna %SQLMut indica, para cada consulta, el número de mutantes no equivalentes generados y el porcentaje de mutantes muertos con la base de datos de producción y la generada, respectivamente. Para la generación de los mutantes se ha utilizado la herramienta SQLMutation (https://in2test.lsi.uniovi.es/sqlmutation/) [13]. El porcentaje de mutantes muertos es de 87,00% y 82,35% con la base de datos de producción y la generada, respectivamente. Como se puede observar, la disminución del porcentaje de mutantes muertos con la base de datos generada respecto a la de producción es muy pequeña teniendo en cuenta el reducido número de filas de la base de datos generada automáticamente. Así mismo, comparando la base de datos de producción con la base de datos generada cabe destacar que en el segundo caso el número de filas en cada tabla es XIV Jornadas de Ingeniería del Software y Bases de Datos 19 muy inferior (pasando de 501 a 5 solicitudes y de 1.304 a 5 anotaciones), alcanzando además el 100% de cobertura. Tabla 4. Porcentajes de cobertura SQLFpc y de mutantes muertos utilizando la base de datos de producción y la generada de forma automática. %SQLFpc %SQLMut Id N. Reglas Producción Generada N. Muts Producción Generada Q1 5 100% 100% 71 88,73% 84,51% Q2 8 87,50% 100% 139 89,93% 89,21% Q3 7 71,43% 100% 113 82,30% 72,57% Total 20 85,00% 100% 323 87,00% 82,35% 5 Conclusiones Se ha presentado un enfoque que permite la generación automática de bases de datos de prueba para consultas SQL. La aplicación a un caso de estudio real con varias consultas SQL muestra buenos resultados preliminares, ya que es posible generar una única carga de pruebas de tamaño reducido para todas las consultas que cumple un conjunto importante restricciones. Dado un conjunto de consultas SQL sobre un esquema de base datos, el esquema y las diferentes situaciones de prueba (reglas de cobertura) sobre las consultas se representan como un conjunto de restricciones, que se resuelven posteriormente con el constraint solver Alloy. Las limitaciones del enfoque propuesto vienen impuestas principalmente por el analizador Alloy. Debido a que Alloy enumera todas las posibles instancias de la base de datos, no es posible manejar grandes bases de datos y por ello se representa únicamente la parte del esquema de la base de datos que interviene en cada consulta. Además, los tipos de datos manejados se restringen a enteros, por lo que será necesario utilizar valores simbólicos para otro tipo de datos diferente. Los resultados de este trabajo pueden ser ampliados en varias direcciones. Por una parte, extendiendo el tipo de consultas SQL para dar soporte a otras características habituales en SQL, como por ejemplo agrupamientos y funciones de agregación. Otra es relativa al soporte automático, de forma que el proceso completo de generación de pruebas (obtención de reglas de cobertura, generación de datos de prueba y carga posterior de la base de datos) quede integrado en una única herramienta. 20 XIV Jornadas de Ingeniería del Software y Bases de Datos Agradecimientos. Este trabajo ha sido financiado por el Ministerio de Ciencia e Innovación y Fondos FEDER (Proyecto TIN2007-67843-C06-01), el Gobierno del Principado de Asturias (Proyecto CN-07-168) y el Gobierno de Castilla-La Mancha (Proyecto PCI-08-121-1374). Referencias 1. Binnig, C., Kossmann, D., Lo, E.M., Oztsu, T.: Qagen: generating query-aware test databases. In SIGMOD Conference, pp 341--352. (2007) 2. Bruno,N., Chaudhuri,S.: Flexible database generators. In: Proceedings of the 31st International Conference on Very Large Data Bases (VLDB), pp. 1097--107. (2005). 3. Chilenski, J.J.: An investigation of three forms of the modified condition decision coverage (MCDC) criterion. Technical Report DOT/FAA/AR-01/18, U.S. Department of Transportation, Federal Aviation Administration. (2001) 4. Emmi, M., Majumdar, R.,Sen, K.: Dynamic Test Input Generation of Database Applications. In: Proceedings of the International Symposium on Software Testing and Analysis (ISSTA), pp. 151--16. (2007). 5. IBM DB2 Generator. http://www-01.ibm.com/software/data/db2imstools/products/db2- luw-tools.html. 6. Jackson, D.: Alloy: A lightweight object modelling notation. ACM Transactions on Software Engineering and Methodology, 11 (2), 266—290. (2002) 7. Jackson, D., Schechter, I., Shlyakhter, I.: Alcoa: the alloy constraint analyzer (2000). In: Proceedings of the International Conference on Software Engineering (ICSE), pp. 730— 733. (200) 8. Kapfhammer, G.M., Soffa, M.L.: A Family of Test Adequacy Criteria for Database- Driven Applications. In: Proceedings of the European Software Engineering Conference/ACM SIGSOFT International Symposium on Foundations of Software Engineering, pp 98—107. (2003) 9. Khalek, S.A., Elkarablieh, B., Laleye, Y.O., Khurshid, S.: Query-aware Test Generation Using a Relational Constraint Solver. In: Proceedings of the IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 238—247. (2008) 10. Smaragdakis, Y., Csallner, C., Subramanian, R.: Scalable automatic test data generation from modeling diagrams. In: Proceedings of EEE/ACM international Conference on Automated Software Engineering (ASE), pp. 4—13. (2007) 11. Suárez-Cabal, M.J., Tuya J.: Structural Coverage Criteria for Testing SQL Queries. Journal of Universal Computer Science, 15 (3), 584—619. (2009) 12. Tuya, J., Suárez-Cabal, M.J., de la Riva, C.: A practical guide to SQL white-box testing. ACM SIGPLAN Notices; 41(1). (2006) 13. Tuya, J., Suárez-Cabal, M.J., de la Riva, C.: Mutating Database Queries. Information and Software Technology, 49 (4): 398-417. (2007) 14. Tuya, J., Suárez-Cabal, M.J., de la Riva, C.: Full Predicate Coverage for Testing SQL Database Queries. Software Testing, Verification and Reliability (under revision).(2009) 15. Willmor, D., Embury, S.M.: An intensional approach to the specification of test cases for database applications. In: Proceeding of the International Conference on Software Engineering (ICSE), pp.102—111. (2006) 16. Zhang, J., Xu, C., Cheung, S.C.: Automatic Generation of Database Instances for Whitebox Testing. In: Proceedings of the International Computer Software and Applications Conference (COMPSAC). (2001) Selección de Características para Mejorar los Modelos de Verificación de Información en EAI * I. Fernández de Viana1, J.L. Arjona1, J.L. Álvarez1, and P. Abad1 Dpto. Tecnologías de la Información E.P.S. La Rábida Universidad de Huelva 21071 La Rábida (Huelva) {i.fviana, jose.arjona, alvarez, abadhe}@dti.uhu.es Resumen Abaratar los costes de mantenimiento de soluciones de Integración de Aplicaciones Empresariales (EAI) se convierte en un reto cuando lo que intentamos integrar son aplicaciones web amigables. La solución a este problema consiste en el uso de sistemas automáticos que permitan navegar hasta la información de interés, extraerla, estructurarla y verificarla. La verificación permite caracterizar la información extraída en base a modelos complejos que son usados para comprobar si la información es válida. En este artículo demostramos empíricamente cómo la selección de características permite simplificar y mejorar los modelos que se obtienen para la verificación de información. 1. Introducción La Web es la principal fuente de información y ha sido concebida para ser consumida por seres humanos, lo que supone una desventaja si lo que pretendemos es su procesado automático. Y es que no es habitual que los sitios web proporcionan una interfaz programáticapara acceder a una vista estructurada de la información de interés que nos ofrecen. En el contexto de EAI, la integración de la información contenida en un sitio web con otras aplicaciones empresariales, pasa por disponer de un conjunto de APIs que proporcionen la posibilidad de interactuar con el sitio como si de un ser humano se tratara. Estas APIs deberían de aceptar una serie de consultas definidas en un lenguaje estructurado de alto nivel, comoSQL o SPARQL1, rellenar formularios a partir de ellas [1] [2], ejecutarlos y navegar a través de los resultados [3], devolver las páginas que contengan la información de interés, extraer dicha información [4] y dotarla de estructura de acuerdo con la ontología que estemos utilizando [5] y, por último, comprobar que la información obtenida es correcta [6] [7]. Al elemento que se encarga de realizar esta última actividad se le denomina verificador y es de vital importancia ya que, de no existir, podríamos alimentar a las distintas aplicaciones con datos no veraces. Esto tendría unos resultados imprevisibles sobre los procesos (como, por ejemplo, de tomas de decisión) que con posterioridad los usen. *Este trabajo ha sido parcialmente financiado por el proyecto INTEGRAWEB:TIN2007-64119 (MICINN), P07-TIC-2602 y P08-TIC-4100 (CICE, Junta Andalucia). 1http://www.w3.org/TR/rdf-sparql-query/ Actas JISBD 2009, pp.21-32, ISBN: 978-84-692-4211-7 c 2009 Los autores 22 XIV Jornadas de Ingeniería del Software y Bases de Datos Figura1. Marco general del proceso de verificación La figura 1 ilustra el marco general del proceso de verificación. A partir de los datos contenidos en nuestro conjunto de entrenamiento creamos un modelo matemático que sirve para estudiar el comportamiento global de las entidades que forman dicho conjunto. Para crearlo cuantificamos algunas de sus cualidades gracias a una serie de características. Para queeste proceso sea lo más verazposible, aplicamosfiltrosqueeliminen valores extraños, outliers, del conjunto y elegimos las características que mejor caractericen al conjunto. Una vez construido el modelo de verificación, el verificador se encargará de comprobar si el conjunto de datos a verificar tiene las mismas cualidades que el modelo de verificación. Si no las presenta entonces el verificador tendrá que lanzar una alarma que conllevará la intervención de un experto. Los principales modelos de verificación son los propuestos en [8] [6] [7] [9], todos se basan en el uso de diversas herramientas estadísticas y probabilísticas que les permiten crear los modelos y combinar los datos que estos tienen. En este artículo presentamos cómo mejorar la calidadde los resultados logradospor la propuesta de verificación de Kushmerick desde el punto de vista de la selección de características. Esto es, mejoraremos el modelo de verificación haciendo un estudio previo que permita vislumbrar qué conjunto de características caracterizan mejor al conjunto de entrenamiento. Este trabajo se ha organizado en las siguientes secciones. En la Sección 2 se presentarán los diversos modelos de verificación existentes haciendo especial énfasis en clasificar los distintos tipos de características propuestas. En la Sección 3 introduciremos en qué consisten la selección de características y resumiremos algunas técnicas. En la Sección 4 explicaremos la metodología de experimentación seguida. En la Sección 5 expondremos los resultados obtenidos. Finalmente, reservaremos la Sección 6 para conclusiones y trabajos futuros. 2. Verificación de información Para poder comprobarla veracidadde un conjunto de datos necesitamos dos elementos fundamentales: las características y los modelos de verificación. XIV Jornadas de Ingeniería del Software y Bases de Datos 23 2.1. Características Lascaracterísticassonatributos,cualidadesopropiedadescuantificablesdelosdistintos elementos que forman nuestros conjuntos de datos y se clasifican según su ámbito de aplicación y su dominio. Según su ámbito distinguimos entre características de slot o de conjunto de datos. Para nosotros un slot será un atributo o un registro presente en el conjunto de datos (ver figura 2). Por ejemplo, el número de registros que forman un conjunto de datos es una característica de dicho conjunto mientras que la longitud de las palabras extraídas sería de atributo. Segúnsu dominiotendremos características numéricasy características categóricas. Figura2. Slots, registros y atributos Características Numéricas. Las características numéricas transforman los valores de los slots o los conjuntos de datos en números. Estas características se suelen agrupar en cinco grupos denominados: Conteo: que van desde aquellas que cuentan el número de slots de una clase que hay en un conjunto de datos, hasta las que cuentan el número de slots que cumplen una seriede restricciones oque están caracterizadospor ciertospatrones a izquierda y derecha [8]. Léxicas: se centran en características de caracteres y suelen estar relacionadas con la codificación usada para representarlos. En [10] se recogen hasta 42 características del tipo longitud de palabras, conteo de palabras, media o longitud de palabras, etc. Similitud: comprueban el grado de igualdad entre atributos y el conjunto de atributos de una clase determinada [11]. Algunos autores intentan medir la similitud entre registros desde un punto de vista estructural. Como los registros se pueden ver como árboles ordenados y etiquetados, en [12] se usan medidas de edición de árboles para calcularla. Diseño: analizan las posiciones que ocupan los slots que forman el mismo registro o adyacentes en el texto HTML. En [9] hay diversas propuestas que se engloban dentro de este tipo de clase de características. 24 XIV Jornadas de Ingeniería del Software y Bases de Datos Tendencia: miden las fluctuaciones en los valores de las características numéricas de un registro [9]. Características Categóricas. Las características categóricas van desde patrones que describen la estructura de registro, hasta restricciones matemáticas sobre los valores de algunos atributos. Estas características se pueden clasificar en: Estructura del registro: analizan los registros desde un punto de vista estructural. Un registro está formado por un conjunto fijo en número y tipo de atributos, estas técnicas se encargan de comprobar que este tipo de restricciones se cumpla [9]. Clases lingüísticas: estudian las características lingüísticas de un atributo. En [10] esto se traduce en clasificar los atributos como sustantivos, verbos, nombre, apellidos, etc. Expresiones regulares:caracterizan todoel contenido de los atributos de una clase mediante patrones [10], o sólo se tienen en cuenta los patrones de comienzo y de fin [8]. Restricciones semánticas: buscan restricciones entre los atributos de diversas clases relacionadas. En [13] se presenta un motor de inferencia capaz de inferir este tipo de restricciones para un conjunto de datos. 2.2. Modelos Los valores quetomanlas características aplicadastantoa los slots comoa losconjuntos de datos son usados por el verificador como evidencia para determinar si un conjunto de datos es válido o no. Estos valores no se consideran individualmente sino en su conjunto. En los siguientes apartados veremos las principales propuestas existentes tanto para combinar dichos valores como para determinaren qué grado este valor nos servirá para establecer la validez o no de los datos, esto es, si el verificador tiene que lanzar una alarma. Modelo de Kushmerick. Este autor presenta dos modelos que son prácticamente idénticos [6,7]. El conjunto de entrenamiento que usa para crear el modelo de verificación sólo tiene conjuntos de datos válidos. En su propuesta inicial trabajaba con las siguientes características: número de registros por conjunto de datos, número de palabras,longitud,fracciónde dígitos,letras,letras mayúsculas,letras minúsculas,símbolos de puntuación y símbolos HTML. Posteriormente también incluyó características relacionadas con la estructura de los registros y el número de registros de cada una de las clases que hay en cada registro. Estas características son modeladas como si de variables aleatorias que siguen una distribución de probabilidad se trataran. Para las variables numéricas sugiere usar una distribución normal mientras que para las categóricas usa una empírica que crea basándose en los datos que estas variables toman en el conjunto de entrenamiento. A la hora de verificar un conjunto de datos, primero calcula los valores que toman las distintas características en dicho conjunto. Luego obtiene la probabilidad con la XIV Jornadas de Ingeniería del Software y Bases de Datos 25 que estos valores siguen las distribuciones antes calculadas. Para combinar estas probabilidades se sugieren tres alternativas denominadas de independencia, vinculación y equivalencia. El valor que se obtiene de aplicar cualquiera de estos métodos es considerado una muestra de una distribución de probabilidad V. Dicha distribución se calculó tomando como muestras las probabilidades con las que los datos del conjunto de entrenamiento siguen las distribuciones normales. Solo se lanza la alarma si la probabilidadcon la que este valor sigue la distribución Ves inferior a un límite. Modelo de Lerman. Este modelo [8] parte de un conjunto de entrenamiento formado únicamente por datos válidos. Junto a las características utilizadas por Kushmerick, Lerman usa un algoritmo propio, denominadoDATAPROG, para inferir los patrones de comienzo y fin y calcula el número de atributos de una clase que cumplen alguno de los patrones aprendidos para la clase. Tanto el conjunto de entrenamiento, como cada uno de los conjuntos que se deseen verificar, están representadospor un vector que contiene los valores medios de cada una de las características. Para verificar un conjunto de datos no verificado comprueba si su vector y el del conjunto de entrenamiento son estadísticamente iguales usando el estadístico de Pearson. Si el valor devuelto está por debajo de un límite entonces se dispara una alarma. Modelo de MacCann. Este modelo de verificación [9] considera las siguientes características a nivel de conjunto de datos: número de atributos de cada clase, longitud media, número medio de palabras, longitud media de las palabras, densidad de dígitos, densidad de palabras alfabéticas, numéricas y alfanuméricas, orden de tuplas atributo y una serie de características booleanas que indican el cumplimiento de restricciones semánticas definidas por el usuario. Además, para cada una de estas características, calcula su tendencia con el objetivo de detectar fluctuaciones en sus valores. El proceso de verificación propuesto se basa en cuatro puntos fundamentales: 1. Las estimaciones delas características se calculan mediantedensidadesnormalizas. Esto es, calcula la probabilidad de que una característica tenga un valor con más probabilidad que otro. 2. Usa tanto conjuntos de valores válidos como inválidos. Cada característica se perfila mediante dos distribuciones normalizadas, una para los datos válidos y otra para los inválidos. Aunque los autores proponen dos formas de combinar dichas distribuciones, los resultados empíricos que ellos presentan en su artículo demuestran que ninguna de ellas presenta unos resultados mucho mejores que el resto. 3. Calcula el valor combinado de las distintas características teniendo en cuenta el peso discriminatorio de cada una de ellas tanto para los conjuntos de datos válidos como los inválidos. 4. El usuario define un límite fijo que se usará para lanzar la alarma. 32 XIV Jornadas de Ingeniería del Software y Bases de Datos 17. Narendra, P.M., Fukunaga, K.: A branch and bound algorithm for feature subset selection. IEEE Trans. Comput. 26(9) (1977) 917–922 18. Liu, H., Motoda, H.: Feature Selection for Knowledge Discovery and Data Mining. Kluwer Academic Publishers, Norwell, MA, USA (1998) 19. J. Doak: An Evaluation of Feature Selection Methods and Their Application to Computer Security. Technical report, Univ. of California at Davis, Dept. Computer Science (1992) 20. Liu, H., Yu, L.: Toward integrating feature selection algorithms for classification and clustering. Knowledge and Data Engineering, IEEE Transactions on 17(4) (2005) 491–502 21. Dumais, S., Platt, J., Heckerman, D., Sahami, M.: Inductive learning algorithms and representations for text categorization. In: CIKM ’98: Proceedings of the seventh international conference on Information and knowledge management, New York, NY, USA, ACM (1998) 148–155 22. Kira, K., Rendell, L.A.: A practical approach to feature selection. In: ML92: Proceedings of the ninth international workshop on Machine learning, San Francisco, CA, USA, Morgan Kaufmann Publishers Inc. (1992) 249–256 23. Hall, M.A., Smith, L.A.: Feature selection for machine learning: Comparing a correlationbased filter approach to the wrapper (1999) 24. Almuallim, H., Dietterich, T.G.: Learning with many irrelevant features. In: In Proceedings of the Ninth National Conference on Artificial Intelligence, AAAI Press (1991) 547–552 Actas JISBD 2009, pp.33-44, ISBN: 978-84-692-4211-7 ©2009 Los autores Análisis de los Efectos de las Políticas de Gestión de la Capacidad de los Servicios en el Cumplimiento de los SLAs utilizando Simulación Elena Orta1, Mercedes Ruiz1 y Miguel Toro2 1 Departamento de Lenguajes y Sistemas Informáticos Escuela Superior de Ingeniería C/ Chile, 1 11003 – Cádiz, España 2Departamento de Lenguajes y Sistemas Informáticos Escuela Técnica Superior de Ingeniería Informática Avda. Reina Mercedes, s/n 41012 – Sevilla, España {elena.orta, mercedes.ruiz}@uca.es, [email protected] Resumen. Actualmente, cada vez son más las empresas proveedoras de servicios TI que recurren a ITIL (Information Technology Infraestructure Library) para gestionar sus servicios con la finalidad de mejorar la calidad y reducir el coste de los mismos. En este trabajo se propone un modelo dinámico de simulación aplicado en el ámbito del proceso Gestión de la Capacidad de ITIL que ayuda a decidir qué política de gestión de la capacidad de los servicios que los proveedores asignan a sus clientes es más adecuada respecto al cumplimiento de los SLAs (Service Level Agreements). El modelo permite estudiar los efectos que estas políticas tienen sobre el rendimiento de los servicios y sobre los costes que tendría que asumir el proveedor si los tiempos de respuesta no son los acordados en los SLAs. Con esta finalidad, se han realizado diferentes análisis de sensibilidad variando la capacidad del servicio, la forma de gestionarla y el porcentaje de la capacidad que se utiliza para responder las invocaciones al servicio en los tiempos de respuesta acordados. Palabras clave: Gestión de servicios TI, Gestión de la capacidad, Modelado y Simulación 1 Introducción El éxito de las empresas proveedoras de servicios TI depende cada vez más de que los servicios que ofrecen se correspondan con los objetivos de su negocio y satisfagan las expectativas de sus clientes. Por tanto, estas empresas no sólo deben centrarse en la tecnología y en su organización interna, sino que también deben tener en cuenta la calidad de los servicios y la relación que mantienen con sus clientes. En este contexto, una gestión eficaz de los servicios ayudará a alinearlos con las necesidades actuales y futuras de la propia organización y de sus clientes, a mejorar calidad y a reducir el coste de los servicios. 34 XIV Jornadas de Ingeniería del Software y Bases de Datos Actualmente, cada vez son más las empresas proveedoras de servicios TI que recurren a la Biblioteca de Infraestructura de Tecnología de la Información (ITIL, Information Technology Infraestructure Library) [12] para gestionar sus servicios. ITIL ofrece un marco de referencia de buenas prácticas en la gestión de servicios TI cuyo objetivo es proporcionar servicios de calidad. ITIL V3 propone utilizar las técnicas de modelado y simulación en algunos de sus procesos como, por ejemplo, en los procesos de los módulos Gestión Estratégica del Servicio y Diseño del Servicio. En este trabajo se propone un modelo dinámico de simulación aplicado en el ámbito del proceso Gestión de la Capacidad del módulo Diseño del Servicio de ITIL. En concreto, se aplica a la problemática de decidir qué política de gestión de la capacidad de los servicios que los proveedores asignan a sus clientes es más adecuada respecto al cumplimiento de los SLAs. El propósito del modelo es estudiar los efectos que diferentes políticas de gestión tienen sobre el rendimiento de los servicios y sobre los costes que tendrían que asumir los proveedores si los tiempos de respuesta no son los acordados. El trabajo se estructura de la siguiente manera: el apartado 2 ofrece una visión global del proceso Gestión de la Capacidad de ITIL. En el apartado 3 se presentan las principales técnicas de gestión de servicios TI y se referencian algunos trabajos actuales que estudian esta problemática. En el apartado 4 se describe el caso de estudio concreto en el que se aplica el modelo dinámico de simulación que se propone y se explican las características o aspectos principales del mismo. Asimismo, se describen los diferentes escenarios que se han simulado y se resumen los resultados obtenidos. Finalmente, el apartado 5 contiene las conclusiones y trabajos futuros. 2 Gestión de la capacidad de los servicios TI La finalidad principal del proceso Gestión de la Capacidad es proporcionar la capacidad necesaria para suministrar servicios de calidad a un coste razonable. Este proceso se compone de los siguientes subprocesos que analizan las necesidades de capacidad desde tres puntos de vista diferentes [10]: Gestión de la Capacidad del Negocio que prevee las necesidades futuras de los clientes, Gestión de la Capacidad del Servicio que analiza el rendimiento de los servicios TI con el objetivo de garantizar el cumplimiento de los acuerdos de nivel de servicios establecidos y Gestión de la Capacidad de los Recursos que analiza el uso de la infraestructura para asegurar que se dispone de los recursos necesarios y que se utilizan eficazmente. En este trabajo nos centramos en la aplicación de los modelos dinámicos de simulación en el subproceso Gestión de la Capacidad del Servicio. En el contexto de este proceso, las políticas de gestión de la capacidad de los servicios que los proveedores asignan a sus clientes influyen en el cumplimiento de los SLAs. En los siguientes apartados se presenta un modelo dinámico que simula el comportamiento de un servicio ante diferentes políticas de gestión de la capacidad y ayuda a determinar cuál de ellas es más adecuada respecto al cumplimiento de los SLAs. El modelo permite estudiar el rendimiento real del servicio con dos políticas de gestión de la capacidad diferentes y evaluar si el rendimiento es el acordado con el XIV Jornadas de Ingeniería del Software y Bases de Datos 35 cliente. Por otro lado, permite estudiar los costes que tendría que asumir el proveedor si no se cumplen los tiempos de respuesta. 3 Trabajos relacionados La Tabla 1 [8] muestra las principales técnicas que se utilizan para resolver los problemas de gestión de servicios TI clasificadas en función de los tipos de problemas que ayudan a resolver. Table 1. Principales técnicas de gestión de servicios TI Técnicas Tipo de problema Inteligencia artificial Toma de decisiones Programación lineal, no lineal, entera y dinámica Optimización y programación dinámica Modelos probabilísticos Estimación, predicción, inferencia y soporte a la decisión Simulación Predicción y soporte a la decisión Las técnicas de inteligencia artificial y las técnicas de programación lineal, no lineal, entera y dinámica se suelen utilizar en situaciones deterministas. Los modelos probabilísticos se utilizan en situaciones inciertas. Los modelos de simulación son modelos computacionales que permiten representar de forma simplificada sistemas complejos. Estos modelos ofrecen como principal ventaja la posibilidad de experimentar diferentes decisiones y analizar sus resultados en sistemas donde el coste o el riesgo de una experimentación real son prohibitivos. Por otro lado, la simulación permite el análisis de sistemas de una complejidad tan elevada que resultan imposibles de representar mediante modelos analíticos. El objetivo común de los modelos de simulación es proporcionar mecanismos para la experimentación, predicción del comportamiento, resolución de preguntas del tipo ¿Qué pasaría si…? y aprendizaje del sistema representado, entre otros. En este trabajo se utilizan modelos de simulación dinámicos continuos. Entre las principales ventajas de estos modelos frente a los modelos analíticos se encuentran las siguientes [14]: − Constituyen un mecanismo flexible y útil para capturar y modelar el alto grado de incertidumbre que presentan algunos sistemas. Estos modelos complementan a las técnicas analíticas que permiten modelar el riesgo y el comportamiento asociado a dicha incertidumbre. − Es una técnica flexible que permite representar un amplio rango de estructuras e interacciones dinámicas. Las técnicas analíticas pueden dar lugar a problemas intratables cuando la complejidad del sistema es elevada. − Permiten modelar la realimentación de los sistemas. Hay sistemas en los que el comportamiento y decisiones tomadas en un instante determinado repercuten en la evolución del sistema. Cuando las implicaciones son complejas, los modelos analíticos son inaplicables o inútiles. Entre los trabajos actuales que proponen aplicar estas técnicas en la gestión de servicios TI pueden encontrarse los siguientes: En [16] se utiliza el modelado de procesos y el análisis de la tecnología en la gestión de servicios TI. El ámbito de 36 XIV Jornadas de Ingeniería del Software y Bases de Datos aplicación de [15] es el proceso Gestión de Cambios. Se propone un modelo analítico de decisión basado en las técnicas de programación determinista y de programación probabilística que ayuda a planificar y a realizar los cambios en los servicios. El ámbito de aplicación de los trabajos [3] y [2] es el proceso Gestión de Incidentes. En [3] se propone un sistema de ayuda a la toma de decisiones dirigido por los objetivos del negocio. En [2] se presenta un enfoque de evaluación y mejora de la gestión de incidentes que se basa en una metodología de análisis de las causas del mal funcionamiento de los servicios que utiliza técnicas de minería de datos. Los trabajos [7] y [1] proponen utilizar las técnicas de simulación dinámica en la gestión de servicios TI. En [7] se propone un modelo que ayuda a gestionar los retrasos que se producen en un proceso sobre cuyas causas existe un cierto grado de incertidumbre. El modelo propuesto en [1] se aplica a la problemática de asignación de los recursos para garantizar el cumplimiento de los SLAs. En este trabajo se propone un modelo dinámico de simulación en el ámbito del proceso Gestión de la Capacidad de ITIL. 4 Caso de estudio En este apartado se describe el caso de estudio en el que se enmarca el modelo dinámico de simulación propuesto y se explican las características del mismo. Asimismo, se describen los escenarios que se han simulado y se recogen y analizan los resultados obtenidos. 4.1 Descripción del Problema Para el propósito de nuestro estudio hemos considerado una empresa proveedora de servicios de validación bancarios y una compañía de comercio electrónico que vende productos en Internet. En este contexto, la empresa proveedora de servicios y la compañía firmarán un SLA en el que se especifican acuerdos de nivel de servicio de diferentes categorías. El objetivo fundamental de este trabajo es evaluar cómo influye la gestión de la capacidad del servicio de validación de crédito que el proveedor asigna a la compañía, en el rendimiento del servicio y en el coste que tendría que asumir el proveedor si los tiempos de respuesta no son los acordados. Por ello, en este estudio se han considerado los parámetros del SLA que se suelen utilizar para definir estos aspectos [10]. Estos parámetros se han clasificado en las siguientes categorías: − Capacidad del servicio: − TasaValidaciónContratada: capacidad del servicio contratada por la compañía. − Tiempos de respuesta: − TiempoRespuestaEsperado (TRE): tiempo máximo que puede transcurrir entre una petición de validación y la respuesta del servicio sin que el proveedor del servicio sea penalizado. − TiempoRespuestaMáximo (TRM): tiempo máximo que puede transcurrir entre una petición de validación y la respuesta del servicio sin que la petición de validación sea abandonada. − Rendimiento del servicio: XIV Jornadas de Ingeniería del Software y Bases de Datos 37 − TasaPeticionesValidadasTRE: porcentaje mínimo de peticiones de validación que tienen que ser validadas en el tiempo de respuesta esperado. − TasaPeticionesAbandonadas: porcentaje máximo de peticiones de validación que se permite que se abandonen por sobrepasar el tiempo de respuesta máximo. − Penalizaciones por incumplimiento de los tiempos de respuesta: − PenalizaciónTiempoRespuestaEsperado: penalización que tendría que asumir el proveedor del servicio por cada petición que se valida sobrepasando el tiempo de respuesta esperado. − PenalizaciónAbandono: penalización que tendría que asumir el proveedor del servicio por cada petición que se abandona por sobrepasar el tiempo de respuesta máximo. En este trabajo se estudian los efectos de las siguientes políticas de gestión de la capacidad del servicio de validación de crédito en el cumplimiento del SLA: − Política A: El proveedor del servicio establece el porcentaje de la tasa de validación de crédito que se utiliza para validar las peticiones en el tiempo de respuesta esperado. El resto de la tasa de validación de crédito se utiliza para validarlas en el tiempo de respuesta máximo. La tasa de validación de crédito que se asigna en un momento dado para validar las peticiones en los tiempos de respuesta establecidos siempre es la misma con independencia de la tendencia que presenten las peticiones recibidas. − Política B: El proveedor del servicio establece el mayor porcentaje de la tasa de validación de crédito que se puede utilizar para validar las peticiones en el tiempo de respuesta máximo. La tasa de validación que no se utiliza para validar las peticiones en el tiempo de respuesta máximo, se utiliza para validarlas en el tiempo de respuesta esperado. A diferencia de la Política A, la tasa de validación de crédito que se asigna en un momento dado para validar las peticiones en los tiempos de respuesta establecidos varía en función de la tendencia que presenten las peticiones recibidas. 4.2 Construcción del modelo de simulación Siguiendo la propuesta de Kellner para describir modelos de simulación [6] y la metodología de Martínez y Richardson [9], a continuación se describe el modelo de simulación construido. La implementación del modelo y las simulaciones se han realizado utilizando el entorno de simulación Vensim®. 4.2.1. Propósito y ámbito del modelo El modelo propuesto se aplica a la problemática de analizar los efectos que las Políticas A y B de gestión de la tasa de validación de crédito tienen en el cumplimiento de los SLAs. El propósito del modelo es ayudar al proveedor del servicio a gestionar adecuadamente la tasa de validación de crédito para garantizar el cumplimiento de los parámetros de rendimiento del SLA. Asimismo, el modelo también permite estudiar los costes que tendría que asumir el proveedor del servicio por el incumplimiento de los tiempos de respuesta del SLA. El rendimiento real del servicio será el acordado siempre que: 38 XIV Jornadas de Ingeniería del Software y Bases de Datos − El porcentaje de peticiones que se validan en el tiempo de respuesta esperado sea mayor o igual al especificado en el parámetro TasaPeticionesValidadasTRE del SLA. − El porcentaje de peticiones de validación que se abandonan por sobrepasar el tiempo de respuesta máximo sea menor o igual al especificado en el parámetro TasaPeticionesAbandonadas del SLA. 4.2.2. Variables de salida Las principales variables que proporcionan información respecto del propósito del modelo son: − IncumplimientoTasaPeticionesValidadasTRE: desviación que existe entre el parámetro TasaPeticionesValidadasTRE del SLA y la tasa de peticiones recibidas que se validan en el tiempo de respuesta esperado en un momento dado. − IncumplimientoTasaPeticionesAbandonadas: desviación que existe entre la tasa de abandono de peticiones de validación recibidas que se produce en un momento dado por sobrepasar el tiempo de respuesta máximo y el parámetro TasaPeticionesAbandonadas del SLA. − CosteIncumplimientoTiemposRespuesta: coste que tendría que asumir el proveedor por las peticiones validadas en el tiempo de respuesta máximo y por las peticiones abandonadas. Otras variables de salida que son útiles para entender qué ocurre en el sistema son las siguientes: − PeticionesRecibidas: número de peticiones de validación que recibe el proveedor del servicio. − PeticionesValidadasTRE: número de peticiones validadas en el tiempo de respuesta esperado. − PeticionesValidadasTRM: número de peticiones validadas en el tiempo de respuesta máximo. − PeticionesAbandonadas: número de peticiones abandonadas. 4.2.3. Parámetros de entrada Los parámetros de entrada permiten configurar diferentes escenarios de simulación. Los utilizados en este estudio se han clasificado de la siguiente manera: − Parámetros del SLA que han firmado la empresa proveedora del servicio y la compañía (véase apartado 4.1) − Parámetros de gestión del servicio de validación: − TasaValidaciónCrédito: capacidad de validación de crédito que el proveedor asigna a la compañía en un momento dado. − PorcentajeTasaValidaciónCrédito: porcentaje de la tasa de validación de crédito que el proveedor utiliza para validar las peticiones en el tiempo de respuesta esperado. El resto de la tasa de validación de crédito se utiliza para validarlas en el tiempo de respuesta máximo. − Parámetros que modelan la tendencia de las peticiones de validación recibidas: − TasaPeticionesRecibidas: representa la tendencia de las peticiones de validación recibidas. XIV Jornadas de Ingeniería del Software y Bases de Datos 39 4.2.4. Proceso de abstracción Para representar los elementos del modelo y sus relaciones se han utilizado los diagramas causales. Para modelar la componente de comportamiento del sistema y representar formalmente sus relaciones causa-efecto se han utilizado los diagramas de flujo y niveles o diagramas de Forrester [4]. Las variables de nivel representan las variables más importantes de un sistema o aquellas cuyo comportamiento se desea observar. Las variables de flujo representan cómo cambian las variables de nivel con respecto al tiempo y permiten modelar las políticas de operación o reglas de decisión de un sistema. Matemáticamente, las variables de nivel se modelan mediante ecuaciones diferenciales que integran a lo largo del tiempo la diferencia entre las variables de flujo de entrada y las variables de flujo de salida de dicha variable de nivel. El conjunto de ecuaciones resultantes constituye el modelo matemático del sistema que se resuelve a través de la simulación. En el modelo propuesto, las variables de salida PeticionesValidadasTRE, PeticionesValidadasTRM y PeticionesAbandonadas se han modelado como variables de nivel cuyo comportamiento se controla mediante las variables de flujo TasaValidaciónTRE, TasaValidaciónTRM y TasaAbandono. Las variables de salida IncumplimientoTasaPeticionesValidadasTRE, IncumplimientoTasaPeticiones Abandonadas y CosteIncumplimientoTiemposRespuesta se han modelado como variables auxiliares. Fig. 1. Diagrama de flujos y niveles simplificado En la Figura 1 se muestra el diagrama de flujos y niveles del modelo simplificado y se detallan los parámetros de entrada y variables que influyen en el cálculo de las variables de flujo TasaValidaciónTRE y TasaValidaciónTRM con las Políticas A y B de gestión de la tasa de validación de crédito. 4.3 Simulaciones del modelo Las simulaciones del modelo permiten analizar los efectos de las Políticas A y B de gestión de la tasa de validación de crédito en el cumplimiento de los SLAs. A continuación se describe el caso de estudio considerado y se presentan y analizan los resultados obtenidos en los análisis de sensibilidad que se han realizado. Peticiones en espera TRE TasaPeticionesRecibidas Peticiones Validadas TRE Peticiones en espera TRM Tasa Validación TRE POLÍTICA B TasaContinuidad Peticiones Validadas TRM TasaValidacion TRM POLÍTICA A y B Peticiones Abandonadas TasaAbandono TasaValidacionCredito Porcentaje TasaValidacionCredito TasaValidación TRE POLÍTICA A Tiempo Respuesta Esperado SLA Tiempo Respuesta Máximo SLA Variable de flujo Variable de nivel Parámetros de entrada Políticas A y B 40 XIV Jornadas de Ingeniería del Software y Bases de Datos 4.3.1 Configuración de parámetros de entrada para el caso de estudio Las simulaciones del modelo se han realizado considerando que el proveedor del servicio y la compañía de comercio electrónico han firmado un determinado SLA y que las peticiones del servicio de validación presentan una tendencia concreta. Parámetros del SLA que han firmado la empresa proveedora del servicio y la compañía: Tomando como referencia ejemplos de SLAs de compañías de comercio electrónico, se han considerado los siguientes parámetros: TasaValidaciónContratada: 4000 peticiones/min. TiempoRespuestaEsperado: 15 segundos. TiempoRespuestaMáximo: 30 segundos. TasaPeticionesValidadasTRE: 90% de las peticiones recibidas. TasaPeticionesAbandonadas: 5% de las peticiones recibidas. PenalizaciónTiempoRespuestaMáximo: 0,2 euros/petición validada tiempo respuesta máximo. PenalizaciónAbandono: 1,8 euros/petición abandonada. Parámetros que modelan la tendencia de las peticiones de validación En la Figura 2 se muestra el parámetro de entrada TasaPeticionesRecibidas que representa la tendencia de las peticiones de validación que recibe el servidor. Se considera que la tasa de peticiones recibidas experimenta un incremento gradual hasta alcanzar un valor máximo que se mantiene constante durante un determinado periodo de tiempo. Pasado este periodo vuelve a descender gradualmente. El valor máximo de la tasa de peticiones recibidas considerado corresponde al record de ventas que registró Amazon en las navidades de 2008 [13]. Fig. 2. Patrón de comportamiento del parámetro de entrada TasaPeticionesRecibidas. 4.3.2 Análisis de sensibilidad Los objetivos de los análisis de sensibilidad realizados para determinar qué política de gestión de la tasa de validación de crédito es más adecuada respecto al cumplimiento de los SLAs son los siguientes: − Estudiar los valores de los parámetros de gestión de la tasa de validación de crédito que garantizan el cumplimiento de los parámetros de rendimiento del SLA. − Estudiar los costes que tendría que asumir el proveedor del servicio por el incumplimiento de los tiempos de respuesta del SLA. Los análisis de sensibilidad se han realizado variando los parámetros de gestión del servicio de validación de crédito TasaValidaciónCrédito y PorcentajeTasaValidaciónCrédito. Los parámetros del SLA y la TasaPeticionesRecibidas se mantienen constantes (véase apartado 4.3.1). 00 123 45 67 8910 Tiempo (minutos) 6,000 4,500 3,000 1,500 XIV Jornadas de Ingeniería del Software y Bases de Datos 41 4.3.2.1 Análisis de sensibilidad para estudiar el cumplimiento de los parámetros de rendimiento del SLA La finalidad principal de estos análisis de sensibilidad es estudiar qué valores de la tasa de validación de crédito y de los porcentajes de la tasa de validación de crédito garantizan el cumplimiento de los parámetros de rendimiento del SLA. La configuración de parámetros de los análisis de sensibilidad se muestra en la Tabla 2. Tabla 2. Configuración de parámetros de los análisis de sensibilidad para estudiar los parámetros de gestión Número de simulaciones: 200 Parámetros de entrada: − Parámetros del SLA y TendenciaPeticionesRecibidas: valores caso de estudio (véase apartado 4.3.1). Parámetros de control del análisis de sensibilidad: − TasaValidaciónCrédito: varía entre la TasaValidaciónContratada (4000 peticiones /minuto) y el valor mayor de la tendencia de peticiones de validación recibidas (4459 peticiones/minuto). Distribución: Uniforme aleatoria. − PorcentajeTasaValidaciónCrédito: varía entre 1% y 100%. Distribución: Uniforme aleatoria. Los datos obtenidos en los análisis de sensibilidad indican que los valores de la TasaValidaciónCrédito y del PorcentajeTasaValidaciónCrédito que garantizan el cumplimiento de los parámetros de rendimiento del SLA son los que se muestran en la Tabla 3. Tabla 3. TasaValidaciónCrédito y PorcentajeTasaValidaciónCrédito válidos (Politicas A y B) TasaValidaciónCrédito PorcentajeTasa ValidaciónCrédito (Política A) PorcentajeTasa ValidaciónCrédito (Política B) 4239<=TVC<=4270 %TVC>=95% %TVC>=95% 4271<=TVC<=4315 %TVC>=94% %TVC>=94% 4316<=TVC<=4362 %TVC>=93% %TVC>=93% 4363<=TVC<=4382 %TVC>=92% %TVC>=92% 4383<=TVC<=4390 %TVC>=92% %TVC>=91% 4390<=TVC<=4410 %TVC>=92% TVC>=4411 %TVC>=91% TVC>=4391 %TVC>=0% 4.3.2.2 Análisis de sensibilidad para estudiar los costes por el incumplimiento de los tiempos de respuesta del SLA La finalidad de estos análisis de sensibilidad es estudiar los costes que tendría que asumir el proveedor del servicio por el incumplimiento de los tiempos de respuesta establecidos en el SLA en los escenarios en los que el rendimiento del servicio es el acordado. Para ilustrar este estudio, en este apartado se analizan los costes que tendría que abonar el proveedor cuando le asigna a la compañía alguna de las tasas de validación de crédito que garantizan el cumplimiento de los parámetros de rendimiento del SLA (véase Tabla 3). La Tabla 4 muestra la configuración de parámetros de los análisis de sensibilidad. 48 XIV Jornadas de Ingeniería del Software y Bases de Datos Web de acuerdo a las restricciones del probador. Este paso se corresponde con los flujos de datos 7, 8 y 9 de la figura 1. 4. A continuación, nuestra herramienta permite inyectarlos directamente en el formulario bajo prueba y enviarlos al servidor Web dónde se aloje dicho formulario. Este paso incluye los flujos de datos 10 a 14 de la figura 1. 5. Además, WebAVLTester permite generar numerosos informes de prueba como parte de la documentación necesaria que debe ir asociada al proceso de prueba. Este paso se corresponde con los flujos de datos 15 y 16 mostrados en la figura 1. Fig. 1. Esquema general de WebAVLTester. 3 Detalle de la introducción de restricciones en WebAVLTester Una vez capturado el formulario bajo prueba, WebAVLTester muestra un interfaz como el ejemplo de la Figura 2. En la parte izquierda superior aparecen todos los XIV Jornadas de Ingeniería del Software y Bases de Datos 49 campos del formulario indicando de qué tipo son. Al seleccionar un campo, en la parte izquierda inferior se muestran las restricciones obtenidas de la especificación XHTML. En la parte derecha y en función del tipo de campo seleccionado el probador podrá introducir las restricciones. En el ejemplo, se puede indicar si el campo será o no obligatorio, el tipo de datos, la longitud así como valores permitidos. WebAVLTester comprueba las restricciones introducidas por el probador evitando que introduzca restricciones incoherentes entre sí o contradictorias con respecto a las propiedades descritas en el código del formulario. Fig. 2. Interfaz para la introducción de restricciones de prueba. Agradecimientos. Este trabajo ha sido financiado por el Ministerio de Educación y Ciencia de España dentro del Plan Nacional de I+D+I, Proyecto TIN2007-67843- C06-01. Referencias 1. Beizer, B., Software Testing Techniques, 2nd. Ed. Van Nostrand Reinhold. 1990. 2. W3C Validator Team: W3C Markup Validation Service. URL: http://validator.w3.org 3. W3C Validator Team: W3C Link Checker. URL: http://validator.w3.org/checklink 4. TAW: Test de Accesibilidad Web. URL: http://www.tawdis.net/taw3/cms/es 5. AutomatedQA: TestcompleteTM. URL: http://www.automatedqa.com/products/testcomplete/ 6. Mercury Interactive: WinRunner©. http://www.powertest.com/sub2.pages/winrunner.html 7. W3C, Pemberton, S. et al.: XHTML 1.0: The Extensible HyperText Markup Language (Second Edition). A Reformulation of HTML 4 in XML 1.0. 8. Ostrand, T.J., Balcer, M.J.: The category partition method for specifying and generating functional tests. In Communications of the ACM, Vol. 31(6) (1988) 676–686. GAmera: una herramienta para la generaci´ on y selecci´ on mediante algoritmos gen´ eticos de mutantes WS-BPEL A. Estero Botaro, I. Medina Bulo, J. J. Dom´ınguez Jim´enez y L. Guti´errez Madro˜nal Dpto. Lenguajes y Sistemas Inform´aticos, Universidad de C´adiz C/ Chile, N.o1, 11003, C´adiz {antonia.estero,inmaculada.medina,juanjose.dominguez, lorena.gutierrez}@uca.es Resumen En este art´ıculo se presenta una herramienta novedosa, GAmera, para la generaci´on y ejecuci´on autom´atica de mutantes para composiciones de servicios web en WS-BPEL. GAmera incorpora un mecanismo de optimizaci´on que permite seleccionar un subconjunto de los mutantes totales que pueden generarse. Esto se logra mediante la utilizaci´on de un algoritmo gen´etico que genera y selecciona s´olo los mutantes de mayor calidad, reduciendo el coste computacional que implicar´ıa la ejecuci´on de todos los mutantes. Los resultados que proporciona esta herramienta permiten mejorar la calidad de los casos de prueba. 1. Introducci´ on La evoluci´on del software hacia las arquitecturas orientadas a servicio ha conducido a la definici´on de un lenguaje que facilite la composici´on de servicios web, el est´andar OASIS WS-BPEL 2.0 [1], que se ha convertido en la referencia a nivel industrial. WSBPEL permite especificar la l´ogica de la composici´on de los servicios (env´ıo de mensajes, sincronizaci´on, iteraci´on, tratamiento de transacciones err´oneas, etc.) independientemente de su implementaci´on. La prueba de mutaciones ha sido validada como una poderosa herramienta para la evaluaci´on de la calidad de los casos de prueba. Para poder aplicarla a las composiciones WS-BPEL es necesario definir un conjunto de operadores de mutaci´on para este lenguaje y construir una herramienta que genere y ejecute los mutantes generados, con objeto de poder automatizar el proceso de pruebas. Rice [2] enumera y explica los diez retos m´as importantes en la automatizaci´on del proceso de pruebas. Entre ellos, se encuentra la falta de herramientas, bien por su elevado precio o bien porque las existentes no se ajusten al prop´osito o entorno para el que se necesitan. Existen varios trabajos en la bibliograf´ıa que abordan el desarrollo de sistemas para la generaci´on autom´atica de mutantes, tales como Mothra [3] para Fortran,MuJava [4] paraJava, Proteum [5] paraC, y SQLMutation[6] paraSQL. Todos estos sistemas se caracterizan por generar todos los mutantes posibles de acuerdo a los operadores de mutaci´on empleados. Uno de los principales inconvenientes que presenta la prueba de mutaciones es el alto coste computacional que supone la ejecuci´on de la gran cantidad de mutantes que se generan para el programa de prueba. Dado que ´esta es la primera herramienta que Actas JISBD 2009, pp.50-53, ISBN: 978-84-692-4211-7 c 2009 Los autores XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 51 se construye para la aplicaci´on de pruebas de mutaciones a composiciones WS-BPEL, hemos considerado que ser´ıa interesante introducir en ella un mecanismo de optimizaci´on que permitiera seleccionar s´olo un subconjuntode los mutantes totales que pueden generarse. Para ello GAmera incorpora un algoritmo gen´etico que selecciona s´olo los mutantes de mayor calidad, reduciendo el coste computacional que supondr´ıa la ejecuci´on de todos los mutantes. En [7] presentamos un conjunto de operadores de mutaci´on espec´ıficos para el lenguaje WS-BPEL 2.0 y en [8] un framework para la generaci´on autom´atica de mutantes para WS-BPEL 2.0 basado en algoritmos gen´eticos. La herramienta que se presenta en este art´ıculo es fruto de estos trabajos previos. Este art´ıculo tiene como objetivo mostrar la funcionalidady utilidad de la herramienta GAmera, que implementael algoritmo gen´etico integrado con los operadores de mutaci´on definidos para WS-BPEL en los trabajos previos. Esta herramienta se ha desarrollado como software libre, y puede descargarse gratuitamente de su web oficial [9]. 2. Estructura de GAmera La herramienta GAmera est´a constituida por tres componentes principales: el analizador, el generador de mutantes y el sistema de ejecuci´on, que ejecuta y eval´ua los mutantes. El analizador Es el primer componente de la herramienta que act´ua. Recibe como entrada la composici´on WS-BPEL a probar y determina los operadores de mutaci´on que se le pueden aplicar. La figura 1 muestra la pantalla de la aplicaci´on que interact´ua con el analizador. Los operadoresse muestran en pesta˜nas independientes,seg´un la categor´ıa del operador, permiti´endose al usuario incluso poder determinar el conjunto de operadores a utilizar de los que son aplicables a la composici´on WS-BPEL con la que se est´a trabajando. Generador de mutantes Los mutantes se generan a partir de la informaci´on que se recibe del analizador. La herramienta nos da la posibilidad de generar todos los mutantes posibles, o bien, un subconjunto de ´estos que va a ser seleccionado por el algoritmo gen´etico. En este ´ultimo caso, se llamar´a al componente denominado Generador gen´etico de mutantes, que est´a compuesto por dos elementos. El primero, denominado B´usqueda Gen´etica de Mutantes, es un algoritmo gen´etico en el que cada individuo representa a un mutante, capaz de generar y seleccionar de forma autom´atica un conjunto de mutantes. Esta selecci´on se realiza aplicando una funci´on de aptitud que mide su calidad en funci´on de si hay o no casos de prueba que lo matan [8]. El segundo elemento es el Conversor, que transforma un individuo del algoritmo gen´etico en un mutante WS-BPEL. Para realizar esta conversi´on, se utilizan hojas de estilos XSLT, una por cada operador de mutaci´on. Ejecuci´ on de mutantes A medida que se van generando los mutantes, el sistema los ejecuta frente a un conjunto de casos de prueba, distingui´endose tres posibles estados para cada mutante seg´un la salida que producen. 52 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos Figura1. Interacci´on con el analizador Muerto La salida del mutante es diferente a la del proceso original para al menos un caso de prueba. Vivo La salida del mutante es la misma que la del proceso original para todos los casos de pruebas suministrados. Err´ oneo Se ha producido un error en el despliegue del mutante y no se ha podido ejecutar. La existencia de este estado permite determinar si el dise˜no e implementaci´on de los operadores de mutaci´on es adecuado, o bien, si se est´an generando mutantes que no se pueden desplegar. Para la ejecuci´on del programa original y los mutantes, GAmera emplea el motor WS-BPEL 2.0 ActiveBPEL 4.1 [10] y BPELUnit [11], una biblioteca de pruebas unitarias para WS-BPEL que utiliza ficheros XML para describir los casos de prueba. 2.1. Resultados GAmera permite visualizar los resultados obtenidos en la ejecuci´on de los mutantes. Muestra el n´umero total de mutantes generados, el de mutantes muertos, vivos y err´oneos. Tambi´en muestra estos valores para cada operador de mutaci´on utilizado. A partir de estos valores se puede medir la calidad del conjunto de casos de prueba utilizado. XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 53 3. Conclusiones Hemos presentado una herramienta que genera autom´aticamente un conjunto de mutantes de calidad para composiciones de servicios WS-BPEL mediante un algoritmo gen´etico. La herramienta permite automatizar la prueba de composiciones WS-BPEL y proporciona informaci´on que permite mejorar la calidad de los conjuntos de casos de prueba. La herramienta es de utilidad tanto para desarrolladores de composiciones WSBPEL, ya que automatiza el proceso de prueba, como para investigadores en pruebas de composiciones WS-BPEL que tengan comofinalidad evaluar la calidad de conjuntos de casos de prueba. Actualmente estamos trabajando en el dise˜no de nuevos operadores de mutaci´on para WS-BPEL 2.0 que contemplen diversos criterios de cobertura. 4. Agradecimientos Este trabajo ha sido financiado por el Programa Nacional de I+D+I del Ministerio de Educaci´on y Ciencia y fondos FEDER mediante el proyecto SOAQSim (TIN2007- 67843-C06-04). Referencias 1. OASIS: Web services business process execution language 2.0. http://docs.oasisopen.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html (2007) 2. Rice, R.: Surviving the top 10 challenges of software test automation. CrossTalk: The Journal of Defense Software Engineering (2002) 26–29 3. King, K.N., Offutt, A.J.: A fortran language system for mutation-based software testing. Software - Practice and Experience 21(7) (1991) 685–718 4. Ma, Y.S., Offutt, J., Kwon, Y.R.: Mujava: an automated class mutation system. Software Testing, Verification & Reliability 15(2) (2005) 97–133 5. Delamaro, M., Maldonado, J.: Proteum–a tool for the assessment of test adequacy for c programs. En: Proceedings of the Conference on Performability in Computing System. (1996) 79–95 6. Tuya, J., Cabal, M.J.S., de la Riva, C.: Mutating database queries. Information and Software Technology 49(4) (2007) 398–417 7. Estero-Botaro, A., Palomo-Lozano, F., Medina-Bulo, I.: Mutation operators for WS-BPEL 2.0. En: ICSSEA 2008: Proceedings of the 21th International Conference on Software & Systems Engineering and their Applications. (2008) 8. Dom´ınguez-Jim´enez, J.J., Estero-Botaro, A., Medina-Bulo, I.: A framework for mutant genetic generation for WS-BPEL. En: SOFSEM 2009: Proceedings of the 35th Conference on Current Trends in Theory and Practice of Computer Science, Lecture Notes in Computer Science. Volume 5404., Springer-Verlag (2009) 229–240 9. Grupo SPI&FM: Web oficial de GAmera. http://neptuno.uca.es/˜gamera 10. ActiveVOS.: Activebpel WS-BPEL and BPEL4WS engine. http://sourceforge.net/projects/activebpel (2008) 11. Mayer, P., L¨ubke, D.: Towards a bpel unit testing framework. En: TAV-WEB ’06: Proceedings of the 2006 workshop on Testing, analysis, and verification of web services and applications, ACM (2006) 33–42 Parte III Sesi´ on 2. Gesti´ on de Proyectos Actas JISBD 2009, pp.57-68, ISBN: 978-84-692-4211-7 ©2009 Los autores TUNE-UP: Seguimiento de proyectos software dirigido por la gestión de tiempos María Isabel Marante1, Patricio Letelier1 y Francisco Suárez2 1 Departamento Sistemas Informáticos, Universidad Politécnica de Valencia 2 Aphelion Soluciones Informáticas S.L. { mmarante, letelier }@dsic.upv.es, [email protected] Resumen. El convencimiento de que el proceso de desarrollo de software es determinante para el éxito de un proyecto ha impulsado el interés por estándares para la evaluación y mejora de procesos, junto con la implantación de metodologías. Sin embargo, ni los estándares para proceso software ni las metodologías modernas más populares han conseguido satisfacer totalmente las expectativas de equipos de desarrollo, particularmente en lo relativo a conseguir un mayor control en sus proyectos. TUNE-UP es una metodología nacida de las necesidades de mejora de proceso en una PYME de desarrollo de software. TUNE-UP combina aspectos de metodologías ágiles y tradicionales, pero su característica más innovadora es el énfasis en la gestión de tiempos como factor clave para la planificación y seguimiento del proyecto. Este trabajo ilustra el enfoque ofrecido por TUNE-UP para gestión de tiempos en proyectos software. Palabras clave: Proceso software, metodologías para desarrollo de software, planificación de proyectos software. 1 Introducción Un proyecto de desarrollo y/o mantenimiento de software conlleva todas las dificultades de un proyecto de ingeniería, pero además incluye los particulares retos que tiene la construcción de un producto software; complejidad de la implementación, requisitos volátiles, desafíos tecnológicos, desarrollo colaborativo, dificultad para asegurar la calidad, etc. Además, el mercado cada vez exige plazos de entrega más reducidos y presupuestos más ajustados. En la última década hemos visto un creciente interés por metodologías y estándares asociados al proceso de desarrollo de software. El modelo de referencia CMMI [2] y los estándares SPICE [9] e ISO 90003 [10] han logrado reconocimiento y atraído el interés de empresas desarrolladoras de software. Metodologías Ágiles (p.e. XP [1] y Scrum [16]) y Tradicionales (p.e. RUP [11] y Métrica 3 [12]) han animado una interesante discusión respecto de las estrategias para desarrollar software y su efectividad en diferentes contextos, confirmándose que cada proyecto requiere un proceso ajustado a sus necesidades, es decir, deben considerarse: composición del equipo, envergadura del proyecto, características del dominio de aplicación, tecnología utilizada, etc. 64 XIV Jornadas de Ingeniería del Software y Bases de Datos registros de seguimiento, es decir, una línea generada cada vez que se pasa a una actividad en el workflow de la unidad de trabajo (incluyendo fechas-horas de inicio y finalización, agente, y otros datos). El Gestor de Unidades de Trabajo ofrece además otras pestañas entre las que destacan: Peticiones (mecanismo de comunicación entre los agentes en el contexto de una unidad de trabajo), Documentación (espacio de documentación para compartir especificaciones de la unidad de trabajo), Relaciones (relaciones de dependencia de la unidad de trabajo con respecto de otras), Planificación (asignación de agentes a actividades de la unidad de trabajo y asignación a una versión del producto) y Tiempos, que explicaremos a continuación. Con los botones Comenzar/Continuar/Pausar (es el mismo botón que cambia de nombre según el estado de la actividad) y Finalizar Actividad el agente puede controlar el registro de tiempo, activando, pausando o finalizando la actividad. Fig. 4. Fragmento de Pestaña Tiempos La pestaña Tiempos (Fig. 4) ofrece funcionalidad específica de tiempos para la unidad de trabajo. En la parte superior los agentes establecen las estimaciones para cada actividad. En la parte inferior se muestran los registros de tiempo producidos automáticamente por los pares de acciones Comenzar/Continuar – Pausar/Finalizar. Tanto en las estimaciones como en los registros de tiempo el agente puede realizar ajustes cuando por ejemplo, prevea que la estimación anterior no se va a cumplir, o cuando haya olvidado Activar, Pausar o Finalizar. Fig. 5. Fragmento de interfaz Gestión de Productos – Unidades de Trabajo de la Versión Para realizar la planificación y seguimiento el Product Manager utiliza el módulo Gestión de Productos (donde se gestionan las versiones de los productos) y desde allí, seleccionando un producto y versión se accede a Unidades de Trabajo en la Versión XIV Jornadas de Ingeniería del Software y Bases de Datos 65 (Fig.5) y a la Carga de Agentes en la Versión (Fig.6). Así, en la interfaz mostrada en la Fig.5, el Product Manager puede consultar los datos resumidos de cada unidad de trabajo en la versión (en particular, puede conocer la actividad actual y el agente asignado a cada unidad de trabajo) o acceder al Gestor de Unidades de Trabajo con una determinada. También puede establecer el orden de prioridad de las unidades de trabajo en una versión o cambiar su versión. Fig. 6. Fragmento de interfaz Gestión de Productos – Carga de Agentes en Versión En la Fig. 6 se muestra la Pestaña Carga de Agentes en Versión. En ella se puede conocer en cualquier momento la holgura simple de los agentes respecto de sus actividades en una versión del producto. En esta interfaz se ofrecen potentes mecanismos de filtros y agrupaciones por columnas. Cuando una versión tiene problemas de holgura, en esta misma interfaz el Product Manager puede cambiar el agente asignado a la actividad (para balancear la carga de un agente) o cambiar de versión alguna unidad de trabajo. Otras alternativas son modificar la fecha de término de la versión, asignar más recursos humanos a la versión o dividir unidades de trabajo para realizarlas incrementalmente en varias versiones. 5 Trabajos relacionados Modelos de referencia como CMMI y estándares como ISO 90003 y SPICE, así como otras guías para gestión de proyectos tales como el PMBOK (Project Management Book of Knowledge) [13] sólo recomiendan prácticas muy generales para la gestión del tiempo. Así, corresponde a las metodologías el definir mecanismos concretos para aplicar dichas prácticas. Las metodologías ágiles aciertan respecto de la granularidad en la definición de las unidades de trabajo, su asignación y estimación, y en el seguimiento continuo. Además, promueven en cierto grado el registro actualizado de tiempos invertidos. Sin embargo, su definición de roles tan genéricos y la no existencia de workflows explícitos, resulta ser incompatible con enfoques de desarrollo basados en mayor especialización de roles junto con mayores necesidades 66 XIV Jornadas de Ingeniería del Software y Bases de Datos de coordinación. Por otra parte, cuando se utiliza una metodología tradicional en los planes se suele asumir un modelo de proceso en cascada, lo cual resulta fácil de elaborar y entender (algo positivo para cerrar un acuerdo con el cliente), pero contraproducente para el control y seguimiento si dicho modelo de proceso no es el más apropiado para el proyecto. Aunque las metodologías tradicionales ponen más énfasis en el trabajo colaborativo basado en workflows, no ofrecen mecanismos para su aplicación. Tampoco promueven la asignación ni estimación detallada respecto de esfuerzos estimados o registrados por los agentes. Existe una gran cantidad de herramientas genéricas para gestión de proyectos, sin embargo, éstas presentan inconvenientes importantes para la gestión de tiempos en proyectos software. Por una parte, no soportan adecuadamente un proceso iterativo e incremental basado en unidades de trabajo que se implementan de forma colaborativa. Por otra parte, no promueven/soportan un registro actualizado de estimaciones y tiempos invertidos pues en la práctica se usan desconectadas del trabajo de los agentes, los cuales periódicamente deberían actualizar los datos del proyecto. En los últimos años han aparecido diversas herramientas para gestión ágil de proyectos software, las cuales sí que asumen que el proceso de desarrollo es iterativo e incremental y basado en unidades de trabajo. Herramientas tales como Rally (www.rallydev.com), TargetProcess (www.targetprocess.com), ScrumWorks (www.danube.com) y VersionOne (www.versionone.com) presentan un especial atractivo respecto de su interfaz y plataforma Web. Sin embargo, en cuanto a gestión de tiempos los mecanismos ofrecidos son muy rudimentarios y ninguna de ellas utiliza workflows para la gestión de unidades de trabajo. Los trabajos de J. Eder y E. Panagos en el área de sistemas de workflows [4, 5] ilustran el interés en mecanismos para la gestión del tiempo y especificación de restricciones de tiempo. Estos trabajos, si bien no están enmarcados en workflows para procesos de desarrollo de software, resultan complementarios a nuestra propuesta. De hecho, la recolección y cómputo de tiempo ofrecidos por TUNE-UP constituirían la base para poder aplicar dichos mecanismos. Los llamados Process-Centered Software Engineering Environments [6] impulsaron gran actividad de investigación a fines de los 90’s, sin embargo, hasta donde sabemos, dicha línea de investigación desapareció y sus resultados no llegaron a aplicarse en el ámbito industrial. Los trabajos de M. Richter, D. Rombach y F. Maurer respecto del entorno MILOS [14, 15] son representativos de dicha generación de herramientas. De estos trabajos pueden extraerse algunas ideas para una gestión más sofisticada de los tiempos y del soporte para el trabajo de los agentes, por ejemplo, gestión integrada de la planificación y de los workflows, almacenamiento y recuperación de experiencias para ser reutilizadas, ambas en [15], o la combinación de enfoques workflows y groupware para flexibilizar la aplicación de técnicas de workflows en contextos de procesos menos estructurados [3]. No descartamos, que un futuro, evaluemos la incorporación en TUNE-UP de algunas de esas ideas. XIV Jornadas de Ingeniería del Software y Bases de Datos 67 6 Conclusiones La adecuada gestión de los tiempos en un proyecto permite tomar acciones correctivas oportunas. Tanto el Product Manager como cada uno de los agentes pueden detectar desajustes en el cumplimiento de compromisos observando las holguras. Sin embargo, estos beneficios sólo se alcanzan cuando se dispone de la información actualizada y completa de los tiempos del proyecto. Sin embargo, en cuanto a precisión ningún mecanismo es perfecto, pues en las estimaciones de tiempos y de disponibilidades de agentes intervienen muchos factores no predecibles ni controlables totalmente, por ejemplo: cambios en los requisitos, modificación de prioridades, imprevistos que afectan la disponibilidad del agente, etc. Es reconocido que la implantación de una metodología es un proceso largo y que presenta dificultades, tales como la formación y entrenamiento del equipo o la resistencia al cambio por parte de algunos agentes. Una gestión del tiempo como la ofrecida por TUNE-UP conlleva además otros obstáculos: • Disciplina de estimación y registro de tiempo. Hay que ofrecer pautas para realizar la estimación y entrenar a los agentes en ello. Las acciones asociadas al registro de tiempo deben ser lo menos molestas para los agentes. • Desconfianza de los agentes al posible control basado en los tiempos. Es difícil convencer a los agentes de que las ventajas de esta gestión de tiempos van mucho más allá de su posible uso para su control. Sin embargo, a la larga el agente termina valorando la información de sus registros de tiempo y el análisis que puede hacerse de ella. La trasparencia contribuye a ganarse la confianza y aceptación de los agentes. Para ello es fundamental proporcionar a cada agente toda la información de tiempos que de él recolecta el sistema. • Evitar confundir la gestión de tiempos con el reloj para fichar la entrada y salida de la empresa. El sistema no pretende que el tiempo registrado mensualmente sea igual al tiempo contractual, aunque podría llegar a serlo sería demasiado molesto tener que registrar tiempos para cada tipo de tarea posible de desarrollar. Por esto es importante acotar las tareas para las cuales es relevante que el agente registre tiempos. • Introducir la disciplina de planificación y gestión de tiempos en la rutina de trabajo de los agentes. Esto exige que el agente tenga en todo momento en ejecución TUNE-UP Process Tool, lo cual en un principio no era valorado. Sin embargo, a medida que la herramienta fue incorporando funcionalidad respecto a planificación y seguimiento del trabajo, comunicación y coordinación entre agentes, espacio compartido de documentos, etc., ésta se ha transformado en un apoyo imprescindible para el trabajo de los agentes. Un elemento muy importante respecto de la comodidad para los agentes fue la instalación de dos monitores en cada puesto de trabajo. Esto les permite tener las ventanas de la herramienta en un monitor y utilizar el otro para el trabajo específico según sus roles. TUNE-UP ha evolucionado en el contexto de una PYME de desarrollo de software bajo el marco de varios proyectos universidad-empresa. Comenzamos con la definición e implantación de un proceso dirigido por las pruebas de aceptación y al mismo tiempo fuimos desarrollando y utilizando la herramienta de apoyo TUNE-UP Process Tool. Esta herramienta con sus principales funcionalidades para gestión de 68 XIV Jornadas de Ingeniería del Software y Bases de Datos tiempos lleva 2 años en funcionamiento y satisface las necesidades de desarrollo y mantenimiento de un producto de tamaño considerable (un ERP dirigido al sector socio-sanitario) y de cinco productos más pequeños, extensiones de dicho ERP. En el ERP trabaja un equipo con 3 analistas, 4 testers y 6 programadores, con versiones de alrededor de un mes que incluyen entre 50 y 100 solicitudes de cambios. TUNE-UP Process Tool en sí misma es un producto de la empresa, que sigue la metodología TUNE-UP y utiliza la herramienta. En el desarrollo de TUNE-UP Process Tool participan 2 programadores. Actualmente tenemos definidos 20 workflows, algunos específicos para un producto, otros compartidos entre diferentes productos, unos con pocas actividades, y otros con hasta 30 actividades. Cada producto utiliza alrededor de cinco workflows. Referencias 1. Beck K. Extreme Programming Explained: Embrace Change. Addison-Wesley. 2000. 2. CMMI v1.2. Capability Maturity Model Integrated. SEI–Software Engineering Institute, Carnegie Mellon. 2009. www.sei.cmu.edu/cmmi/models/ (visitado junio de 2009). 3. Dellen B., Maurer F., Pews G. Knowledge Based Techniques to Increase the Flexibility of Workflow Management. Data & Knowledge Engineering 29, 1997. Elsevier. 4. Eder J., Panagos E. Managing Time in Workflow Systems. Workflow handbook 28, 109- 132. 2001. 5. Eder J., Panagos E., Rabinovich M. Time Constraints in Workflow Systems. Lecture Notes in Computer Science 15, 165-280. Springer. 1999. 6. Gruhn V. Process-Centered Software Engineering En.vironments: A Brief History and Future Challenges. Annals of Software Engineering 14, 363-382. Kluwer Academic Publishers. 2002. 7. Hiranabe K. Kanban Applied to Software Development: from Agile to Lean. www.infoq.com/articles/hiranabe-lean-agile-kanban (visitado junio de 2009) 8. Hyun, J., Sun J., Ho, M. Extracting the workflow critical path from the extended wellformed workflow schema. Journal of Computer and System Sciences 70 (2005) 86–106. Academic Press, Inc. 9. ISO-International Organization for Standardization. ISO/IEC 15504, SPICE: Software Process Improvement and Capability dEtermination. 1998. 10. ISO-International Organization for Standardization. ISO/IEC 90003, Software engineering- Guidelines for the application of ISO 9001:2000 to computer software. 2004. 11. Kroll P., Kruchten P. Booch G. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Addison-Wesley Professional. 2003. 12. MAP-Ministerio de Administraciones Públicas de España. Métrica Versión 3, Metodología de planificación, desarrollo y mantenimiento de sistemas de información. 2005. www.csi.map.es/csi/metrica3/ (visitado en junio de 2009) 13. PMI-Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide) - Fourth Edition. 2008. 14. Richter M., Maurer F. MILOS and MASE: Past & Present. ase.cpsc.ucalgary.ca /uploads/Publications/Milos_22.08.2003.pdf (visitado en junio de 2009) 15. Rombach D. A process Platform for Experience-Based Software Development. Proc. of Int. Colloquium of the Sonderforschungsbereich 501 U.of Kaiserslautern, pp.47-57. 2003 16. Schwaber K., Beedle M. Agile Software Development with Scrum. Prentice Hall, Series in Agile Software Development. 2001. 17. Watts, H. Introducción al proceso de software personal. Addison-Wesley Iberoamericana. 2001. Actas JISBD 2009, pp.69-80, ISBN: 978-84-692-4211-7 ©2009 Los autores Selección de Herramientas para la Gestión de Proyectos de Software en Pequeñas y Medianas Empresas Lornel Rivas1, María Pérez1, Luis E. Mendoza1 y Anna Grimán1 1Departamento de Procesos y Sistemas, Universidad Simón Bolívar, Apartado Postal 89000, Caracas 1080-A, Venezuela {lrivas, movalles, lmendoza, agriman}@usb.ve Abstract. La gestión de proyectos (GP) de software se apoya en herramientas software que soportan la planificación, el seguimiento y el control del proyecto. Por su parte, la selección de herramientas debe responder a las necesidades y características de la empresa. Esto es especialmente importante en las Pequeñas y Medianas Empresas (PyMES), las cuales toman decisiones bajo diversas restricciones. Proponemos en este trabajo criterios para la selección de herramientas software de apoyo a la GP en PyMES. Apoyándonos en el enfoque Objetivo-Pregunta-Métrica, proponemos la operacionalización de los criterios a través de 94 métricas. Éstas fueron aplicadas en cinco herramientas de soporte a la GP: Gantt Project, Trac, Enterprise Architect, DotProject y OpenProj. Los resultados han sido coherentes con el alcance de cada herramienta y nos han revelado sus ventajas y debilidades; no existiendo una de ellas que satisfaga completamente todos los objetivos de evaluación. Enterprise Architect destaca durante el Inicio y la definición del alcance, mientras que OpenProj, DotProject y Trac hacen lo propio en la Planificación, y el Seguimiento y control del proyecto. La evaluación realizada nos ha permitido validar la generalidad, viabilidad, coherencia, utilidad y repetibilidad de nuestra propuesta. Keywords: Gestión de proyectos, Criterios de selección de herramientas, Calidad de software, Métricas, PyMES. 1 Introducción Actualmente académicos y profesionales reconocen la influencia de la Gestión de Proyectos (GP) en el éxito de los proyectos software [1,2]. Aunque las razones que propician tal éxito son diversas, la GP destaca por sus contribuciones para alcanzar la entrega de un producto de calidad dentro del tiempo y presupuesto establecidos. Para lograr esto, la GP incorpora herramientas automatizadas de Ingeniería de Software (IS) que son clave en el apoyo al equipo de desarrollo en actividades como la planificación, el seguimiento y el control de los proyectos. En este sentido, el uso de las herramientas automatizadas ha sido clave en el éxito de tales actividades [1]. Esta situación resulta particularmente importante para las Pequeñas y Medianas Empresas (PyMES). La principal razón para ello es que las PyMES han incrementado su presencia en la industria del software a escala global; asumiendo proyectos cada vez más complejos y compartiendo restricciones que exigen ser eficientes en el 70 XIV Jornadas de Ingeniería del Software y Bases de Datos manejo de los recursos. Esto ha requerido también que las PyMES sean efectivas en aquellos procesos de evaluación y selección de herramientas software, para obtener así los beneficios esperados de éstas. No obstante, tomar la decisión sobre cuál herramienta software adquirir no es una tarea trivial; por el contrario, requiere analizar la empresa y sus necesidades. Su selección puede realizarse mediante diferentes aproximaciones: el uso de listas de comprobación [3]; la aplicación de métodos y metodologías de evaluación [4]; o el uso de estándares, tales como ISO/IEC 14102 o IEEE 1209 [5,6]. Sin embargo, existen dificultades para la aplicación de aquellos procesos definidos en los estándares de IS en el ámbito de las PyMES [7]. En [3] se justifica esta dificultad por el número y la complejidad de las características a evaluar, su organización interna, y la diversidad de aspectos organizacionales que pueden estar involucrados. Por otra parte, aunque se han propuesto criterios de selección para ciertos dominios de la IS, no existen criterios específicos para aquellas áreas de especial interés para las PyMES; incluyendo la GP. Esto es analizado en [8], donde se abordan las dificultades en la aplicación de estándares de IS en áreas del ciclo de vida de desarrollo de software que incluyen explícitamente la GP. Por ello, persiste actualmente la necesidad de orientaciones más adecuadas que apoyen a las PyMES en aquellos procesos de evaluación y selección de herramientas software que apoyen la GP. En etapas previas de esta investigación hemos propuesto criterios de carácter general dirigidos a la selección de herramientas en PyMES [9]. En el presente trabajo analizamos las actividades claves de la GP en PyMES y, con base en este análisis, proponemos un conjunto de criterios que apoyen a los decisores en la selección de herramientas adecuadas a sus necesidades. En la propuesta de tales criterios hemos tomado en cuenta dos aspectos metodológicos fundamentales: (1) el contexto organizacional [3,4], y (2) su objetividad. Para satisfacer el primero de estos aspectos, hemos incorporado el análisis de aquellas características particulares de las PyMES. En relación al segundo aspecto, hemos utilizado el enfoque Objetivo-Pregunta-Métrica (GQM, por sus siglas en inglés) [10]. Una vez que hemos contado con un conjunto de criterios adecuados y objetivos, los hemos aplicado a cinco herramientas software (Gantt Project, Trac, Enterprise Architect, DotProject y OpenProj) para comprobar las bondades de nuestra propuesta. Los resultados generales revelaron las ventajas de cada una de estas herramientas en estadios particulares del proyecto software; al tiempo que también se hicieron evidentes las fortalezas y debilidades comunes a todas ellas respecto a los objetivos propuestos por las PyMES. Esto demuestra no sólo la viabilidad de aplicar los criterios propuestos sino también la utilidad de éstos dentro del proceso de evaluación y selección. En las próximas secciones establecemos un marco de referencia acerca de la GP en PyMES (sección 2). Sobre esta base, proponemos los criterios de selección expresados en un conjunto de 94 métricas (sección 3), las cuales aplicamos a las herramientas antes mencionadas (sección 4). Por último, presentamos las conclusiones obtenidas y los trabajos futuros (sección 5). XIV Jornadas de Ingeniería del Software y Bases de Datos 71 2 Marco para el Estudio de la Gestión de Proyectos en PyMES Existen en el mercado numerosas herramientas software que apoyan actividades de GP. Sin embargo, su selección efectiva requiere del establecimiento de criterios basados en el contexto de la organización [4]. Ello implica el reconocimiento de las características del proyecto, así como de la empresa que hace la selección. Respecto a los proyectos software, éstos comparten con cualquier otro tipo de proyecto, características y principios bien establecidos. Un proyecto software es definido entonces a partir de actividades precisas, tiempos delimitados y objetivos claros, que se orientan hacia el logro de un producto [11]. La GP surge ante la necesidad de coordinar tales actividades de forma sistemática y disciplinada. Para ello, el proyecto se organiza en las siguientes áreas [12]: (1) Inicio y definición del alcance, (2) Planificación, (3) Revisión y evaluación, (4) Cierre, y (5) Medición. Cuando hablamos de proyectos software, diversos factores pueden afectar la GP, entre los que destacan [13]: (1) el cambio tecnológico, (2) las necesidades de personal capacitado, (3) la intensiva relación con el usuario, y (4) el impacto de los cambios en el alcance. De allí la importancia de considerar las actividades de GP en la IS. Por otra parte, las PyMES se caracterizan por ciertas restricciones que afectan sus procesos de adopción tecnológica, incluyendo los de evaluación y selección de tecnologías. Restricciones de recursos para la adquisición de tecnologías, la contratación de personal especializado, y el desarrollo de infraestructura —entre otras— agregan complejidad a la toma de decisiones en PyMES dedicadas al desarrollo de software. Sin embargo, las PyMES se caracterizan asimismo por un alto grado de flexibilidad, por lo que suelen ajustar sus procesos según las necesidades del proyecto y así generar respuestas ante las exigencias de productividad y calidad a las que son sometidas. Por ello, es común la adopción de enfoques simplificados para la gestión de sus proyectos [2]; requiriendo herramientas software que les proporcionen soporte, especialmente en aquellas tareas que les son prioritarias. Aunque la GP es un tema ampliamente desarrollado en la literatura, la información sobre GP de software en el contexto de las PyMES es más escasa. No obstante, algunos autores como [14, 15, 16] reconocen la GP como una necesidad que comparten las PyMES que se dedican al desarrollo de software (ver Tabla 1). Por otra parte, autores como [2, 9, 8, 17] revelan coincidencias en la importancia que le otorgan a algunas tareas de GP específicas en PyMES (véase Tabla 2). Tabla 1: Algunas necesidades de apoyo en PyMES desarrolladoras de software [14, 15, 16] Necesidades de apoyo Argumentación Manejo de riesgos Vulnerabilidad de las finanzas; necesidad de eficiencia Estimación de tareas Carencias de históricos y de grandes bancos de proyectos Herramientas adecuadas Debilidades en la experiencia Necesidad de facilitar procesos de adopción tecnológica Organización y coordinación de roles Flexibilidad en la asignación de roles Informalidad en reglas y procedimientos Flexibilidad en la GP Procesos ajustados a necesidades del proyecto Determinación de requisitos Informalidad de la comunicación, las reglas y procedimientos Comunicación intensiva con los clientes Mecanismos para la comunicación Incremento en prácticas de trabajo distribuidas Informalidad de infraestructura 72 XIV Jornadas de Ingeniería del Software y Bases de Datos Tabla 2: Coincidencias observadas sobre actividades claves para GP en PyMES [2, 9, 8 17] Temas prioritarios Laporte et al. Murphy y Ledwith Rivas et al. O’Connor et al. Definición del alcance √ √ Estimación de tareas √ √ √ √ Gestión de riesgos √ √ √ Seguimiento de proyectos √ √ √ √ Control de Proyectos √ √ Estimación de costos √ √ Manejo de Agenda √ √ √ Las características de las PyMES generan inquietudes en torno al soporte que pueden obtener de las herramientas para la GP. De acuerdo con [12] todas las áreas de conocimiento definidas en PMBOK son directamente relevantes a la GP de software, sin embargo en SWEBOK se abordan aquellos tópicos específicos de la IS. De allí que ante la diversidad de enfoques existentes para estudiar la GP y el amplio reconocimiento de ambos cuerpos de conocimiento consideramos las áreas y actividades definidas en SWEBOK [12] como punto de partida para identificar aquellas de mayor interés para estas empresas. Sobre esta base, identificamos las siguientes áreas de soporte de las herramientas software: (1) las herramientas de planificación y seguimiento y las de gestión de riesgos soportan actividades de planificación y ejecución del proyecto al facilitar la medición de esfuerzo, la estimación de costos, la programación de agendas, así como la identificación, la estimación y el seguimiento de riesgos [12], (2) las herramientas de planeación, apoyan la planificación mediante la generación de diagramas PERT, estimaciones diversas y hojas de cálculo [18], (3) las herramientas de requisitos apoyan actividades de especificación y gestión de requisitos [12]. En la Tabla 3 relacionamos las áreas y actividades de GP que consideramos revisten especial relevancia para las PyMES, y las herramientas software mencionadas anteriormente. Tabla 3: Actividades de GP y herramientas de IS Áreas de la GP Actividades Herramientas software Inicio y definición del alcance del proyecto Determinar y negociar requisitos Análisis de factibilidad Revisión de requisitos Planificación del Proyecto Planificación Determinar Entregables Estimación de Esfuerzo, Agenda y Estimaciones de Costos Asignación de Recursos Gestión de Riesgos Ejecución del proyecto Seguimiento y Control Herramientas de requisitos de software Herramientas de planificación y seguimiento Herramientas de gestión de riesgos Herramientas de planeación En este punto, es importante mencionar que existen áreas de conocimiento definidas en el PMBOK tales como la Gestión de Comunicaciones, la Gestión de Recursos Humanos, la Gestión de Integración, la Gestión de Calidad y la Gestión de Procura, que no forman parte del alcance de este artículo. Ello obedece a que diversas actividades que las conforman no se justifican de manera determinante en el ámbito de las Pymes, bien sea por razones como el reducido número de personal (lo que XIV Jornadas de Ingeniería del Software y Bases de Datos 73 afecta la Gestión de Recursos Humanos y la Gestión de Integración, por ejemplo), así como otras características que las definen, como la flexibilidad en su comunicación interna y externa, o la sencillez de sus estructuras organizativas (ambas afectan a su vez la Gestión de Comunicaciones). Sin embargo, estas áreas serán también analizadas en futuras investigaciones. 3 Propuesta de Criterios para la Selección de Herramientas Software para la GP en PyMES El análisis previo nos permitió identificar ciertas actividades de GP que requieren un soporte automatizado. De acuerdo con los estándares ISO/IEC 14102 e IEEE 1209, los criterios de selección de herramientas software deben ser precisos y susceptibles de ser medidos [3, 4]. Por ello, hemos utilizado el enfoque GQM [5] para la definición de nuestros criterios, de la siguiente manera: (1) Un nivel conceptual: se establece un conjunto de objetivos orientadores del ejercicio de evaluación y selección; (2) Un nivel operativo: se propone un conjunto de preguntas que buscan el logro de tales objetivos; (3) Un nivel cuantitativo: se formulan las métricas que nos permiten capturar datos asociados a cada una de tales preguntas y así conocer la presencia o no de funcionalidades que debe tener una herramienta de GP. La Tabla 4 resume los objetivos y preguntas propuestas para los niveles conceptual y operacional, respectivamente; así como el número de métricas correspondiente a cada pregunta (nivel cuantitativo). Tabla 4: Objetivos, preguntas y número de métricas formuladas Objetivos Preguntas formuladas y número de métricas correspondientes Núm. de métricas P1: ¿Soporta actividades para la definición de requisitos? 12 P2: ¿Soporta actividades para el análisis de factibilidad? 5 O1.Conocer el soporte de la herramienta durante el Inicio y Definición del alcance P3: ¿Soporta actividades para la revisión de requisitos? 3 P1: ¿Soporta actividades para la planificación? 9 P2: ¿Soporta actividades para la definición de entregables? 6 P3: ¿Soporta actividades para la estimación de esfuerzos y costos? 27 P4: ¿Soporta actividades para la asignación de recursos? 8 O2. Conocer el soporte de la herramienta durante la Planificación P5: ¿Soporta actividades para la gestión de riesgos? 8 O3. Conocer el soporte de la herramienta en la Ejecución P6: ¿Soporta actividades para el seguimiento y control? 16 Como se observa en la Tabla 4, hemos propuesto un total de 94 métricas que nos permiten dar respuesta a seis preguntas y tres objetivos de evaluación. Por razones de espacio sólo presentamos algunos ejemplos de estas métricas (ver Tabla 5). Nótese que las métricas propuestas representan aquellas funcionalidades esperadas de la herramienta software, y son medidas según la escala propuesta para cada una de ellas, con valores normalizados de 1 a 5. 80 XIV Jornadas de Ingeniería del Software y Bases de Datos Tool: An Empirical Laboratory Study, The DATA BASE for Advances in Information Systems, vol. 36, no. 2, 28-42 (2005) 2. Murphy, A., Ledwith, A .:Project management tools and techniques in high technology SMES. Management research news, vol. 30, no. 2,153-166 (2007) 3. Lundell, B., Lings, B.: Comments on ISO 14102: the standard for CASE-tool evaluation. Computer Standards & Interfaces, vol. 24, 381–388 (2002) 4. Kitchenham, B.: Evaluating software engineering methods ant tools. Part 1: The evaluation context and evaluation methods. ACM SIGSOFT Software Engineering Notes, vol. 21, no. 1, 11–14 (1996) 5. ISO/IEC: Information Technology—Guideline for the evaluation and selection of CASE tools. ISO/IEC JTC1/SC7. ISO/IEC 14102:1995(E). USA (1995) 6. IEEE: IEEE Recommended Practice for the Evaluation and Selection of CASE Tools. IEEE Std 1209-1992. Published by the Institute of Electrical and Electronics Engineers, USA (1993) 7. O’Connor, R., Baddoo, N., Smolander, K., Messnarz, R.: Software Engineering Lifecycle Standard for Very Small Enterprises. Communications in Computer and Information Science. Software Process Improvement 15th European Conference, EuroSPI 2008, Dublin, Ireland, September 3-5 (2008). 8. O’Connor, sv-lncs. Version 1.2. S. Editors: ALEXANDRE – Centre d’Excellence en Technologies de l’Information et de la Communication (CETIC), (Belgium); C. Y. LAPORTE – Ecole de Technologie Supérieure (ETS), (Canada) . Estatus: draft (2007) 9. Rivas, L., Pérez, M., Mendoza, L. & Grimán, A. Selection criteria for software development tools for SMEs, Internacional Conference on Enterprise Information Systems, Barcelona, España (2008) 10. Basili,V., Gianluigi, C., H. Dieter: Goal Question Metric Paradigm. Encyclopedia of Software Engineering, vol. 1, edited by John J. Marciniak, John Wiley & Sons, 528-532, (1994) 11. PMI: A Guide to the Project Management Body of Knowledge (PMBOK Guide). Project Management Institute (2000) 12. IEEE: Guide to the software engineering body of knowledge SWEBOK. A project of the IEEE Computer Society (2004) 13. Fuller, M., Valacich, J., George, J.: Information systems project management: a process and team approach. Pearson education. USA (2008) 14. Richardson, I., Gresse, C.: Why are small software organization different?, IEEE software, published by the IEEE computer society, January/February, 18-22 (2007) 15. Fayad, M., Laitinen, M., Ward, R. Software engineering in the small, Communications of the ACM, vol. 23, no. 3, 115-118 (2000) 16. El Emam, K.: Multi-Method Evaluation of the Practices of Small Software Projects, Proc. First International Research Workshop for Process Improvement in Small Settings, Pittsburgh, PA, 12-17 (2005) 17. Laporte, C., April. A., Renault, A.: Applying ISO/IEC Software Engineering Standards in Small Settings: Historical Perspectives and Initial Achievements. Proceedings of SPICE 2006 Conference, May 4-5, Luxembourg (2006) 18. Sommerville, I. Ingeniería del Software. 7ma. ed. España: Pearson Educación (2005) 19. Sparx Systems. Enterprise Architect. Recuperado el 25/04/2009 de: http://www.sparxsystems.com.au/products/ea/index.html 20. Gantt Project. Recuperado el 25/04/2009 de: http://www.ganttproject.biz/ 21. DotProjet. Recuperado el 25/04/2009 de: http://www.dotproject.net/ 22. OpenProj. Recuperado el 25/04/2009 de: http://openproj.org/openproj 23. Trac Open Source Project. Recuperado el 25/04/2009 de: http://trac.edgewall.org/ TEMPO: Una herramienta para la reutilizaci´ on efectiva en la ingenier´ ıa de procesos software Orlando Avila-Garc´ıa, Adolfo S´anchez-BarbudoHerrera, V´ıctor Rold´an Betancort, Carlos Gonz´alez P´erez, Antonio Est´evez Garc´ıa Open Canarias, S.L. C/. El´ıas Ramos Gonz´alez, 4 - Oficina 304 38001 Santa Cruz de Tenerife, Spain {orlando,adolfosbh,vroldan,caglezp,aestevez}@opencanarias.com http://www.opencanarias.com 1. Introducci´ on La ingenier´ıa de procesos software se ha convertido en una de las m´as prometedoras ´areas de la ingenier´ıa del software, que ofrece t´ecnicas y m´etodos de control en la definici´on, personalizaci´on y ejecuci´on de los procesos software de una empresa de desarrollo. Uno de los elementos clave en la gesti´on de los procesos software es la reutilizaci´on: actualmente es com´unmente aceptado que no hay dos proyectos de software iguales, que los procesos en una empresa de software comparten similitudes pero presentan las suficientes diferencias como para que su gesti´on sea una tarea compleja. SPEM (Software & Systems Process Engineering Meta-Model Specification) [1] es la iniciativa que OMG propone para el modelado formal de los procesos software, como est´andar a implementar por las herramientas de dise˜no de procesos con el fin de facilitar la interoperabilidad entre las mismas. Aunque SPEM centra una parte importante de su contenido en proporcionar mecanismos para la reutilizaci´on de modelos de procesos, creemos que ´estos aportan una complejidad excesiva a la creaci´on de los procesos al seguir unas pautas y/o mecanismos de reutilizaci´on tradicionales y comunes a los lenguajes de programaci´on de software, que a lo largo de los a˜nos han demostrado sus limitaciones, sobretodo para usuarios no expertos en t´ecnicas de programaci´on. En trabajos previos ya se habla sobre limitaciones presentes en los mecanismos de reutilizaci´on de SPEM [2]. En [3] se proponeel concepto de ingenier´ıa de l´ıneas de proceso software, como un m´etodo de reutilizaci´on efectiva en el dise˜no de procesos software que utiliza conceptosyt´ecnicas de la llamada ingenier´ıa de l´ıneas de producto. La ingenier´ıa de l´ıneas de producto software permite la reutilizaci´on efectiva de artefactos de software bas´andose en la identificaci´on, organizaci´on y gesti´on proactivas de artefactos de software similares para un dominio dado, acorde con sus similitudes y variaciones. Recientemente han comenzado a aparecer investigaciones sobre la definici´on de estas l´ıneas de procesos software. Por ejemplo, [2] propone una extensi´on de SPEM 2.0 para modelar expl´ıcitamente la variabilidad en l´ıneas o familias de procesos. Sin embargo,el proceso de creaci´on de una l´ınea de producto va m´as all´a de la simple definici´on de las caracter´ısticas comunes y variables a los productos de la familia, Actas JISBD 2009, pp.81-84, ISBN: 978-84-692-4211-7 c 2009 Los autores 82 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos en la llamda ingenier´ıa de dominio. Otras actividades son igualmente importantes, como la ingenier´ıa de aplicaci´on, que trata la derivaci´on de un producto concreto a partir de una selecci´on (configuraci´on) particular de caracter´ısticas, y la llamada gesti´on de la l´ınea de productos, que se encarga del control estrat´egico y coordinaci´on de los esfuerzos aplicados a las dos anteriores disciplinas. TEMPO es una herramienta que pretende dar un soporte integral a la ingenier´ıa de l´ıneas de proceso software, permitiendo no solo la definici´on de familias de procesos (ingenier´ıa de dominio) sino la configuraci´on y derivaci´on de los procesos concretos de esas familias (ingenier´ıa de aplicaci´on), y la coordinaci´on y gesti´on de la interacci´on entre ambos esfuerzos. 2. Definici´ on de procesos gen´ ericos y concretos. En TEMPO identificamos dos roles bien diferenciados,el llamado “dise˜nador de procesos” y el “configurador de procesos”. La herramienta ofrece una perspectiva de trabajo para cada uno de estos roles, configurando el workbench para mostrar la informaci´on m´as relevante para cada rol. El dise˜nador es el encargado de crear la familia de procesos SPEM a trav´es del denominado proceso gen´erico, modelando las caracter´ısticas comunes y puntos de variabilidad de los procesos de la familia. Esta actividad es la que denominamos t´ıpicamente ingenier´ıa de dominio en la ingenier´ıa de l´ıneas de producto software. El configurador realiza actividades de configuraci´on sobre procesos gen´ericos para obtener las instancias concretas de procesos SPEM que pertenecen a la familia. Para ello, y siguiendo un asistente de configuraci´on proporcionado por la herramienta, el configuradorselecciona entre las caracter´ısticas variables (opcionalesy alternativas) de la familia; esta selecci´on se denomina configuraci´on y ser´a utilizada por la herramienta para resolver autom´aticamente la variabilidad del proceso gen´erico y producir el proceso concreto. Esta es la actividad que se corresponde con la llamada ingenier´ıa de aplicaci´on en la ingenier´ıa de l´ıneas de producto software. En TEMPO, el dise˜nador de procesos gen´ericos utiliza un lenguaje que permite definir, por un lado, los elementos SPEM del proceso que formar´an parte de los procesos concretos de la familia, y por el otro, elementos de variabilidad que completar´an la definici´on de la familia, estableciendo la presencia obligatoria, opcional o alternativa de dichos elementos SPEM en los procesos de la familia. Este lenguaje se llama MOTEL (Model Template Language) y hasido inspiradoen el modelode caracter´ısticas de Czarnecki [4], que permitemodelar varibilidad en l´ıneas de productosoftware. MOTEL ha sido dise˜nado de tal manera que sus instancias mantienen embebidos los elementos SPEM que formar´an parte de los procesos de la familia. De esta manera, MOTEL puede ser interpretado como un decorador del lenguaje SPEM, que a˜nade informaci´on de variabilidad sobre los elementos de dicho lenguaje. Para facilitar la interacci´on del usuario final con dicho lenguaje, TEMPO ofrece una sintaxis concreta gr´afica inspirada en la notaci´on UML. Un editor GMF (Graphical Modeling Framework) ayuda al dise˜nador a crear dichos procesos gen´ericos de forma que se utilizan cajas para representar las caracter´ısticas variables del proceso, que a su vez contendr´an los elementos SPEM que las realizan. En la siguiente figura podemos observar un ejemplo de dicha sintaxis: XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 83 Figura1. Perspectiva del dise˜nador de procesos gen´ericos, editando un modelo MOTEL con notaci´on UML. MOTEL es una combinaci´on de elementos SPEM y elementos de definici´on de variabilidad. Cuando el configurador genera un proceso concreto a partir de la configuraci´on del proceso gen´erico, obtiene un modelo SPEM en el que ya no tenemos elementos MOTEL relativos a la informaci´on de variabilidad. El usuariopodr´a introducir informaci´on adicional para especificar m´as si cabe su proceso concreto. Finalmente decir que la herramienta guarda la informaci´on de configuraci´on del proceso gen´erico y la mantiene junto al proceso concreto generado, para validar en el futuro que el proceso concreto sigue siendo consecuente con la configuraci´on de la que parti´o. Esto se hace para controlar la calidad del proceso software incluso despu´es de haberlo configurado, de forma que se puede utilizar para validar que cualquier modificaci´on posterior realizada directamente sobre el proceso concreto cumple con la configuraci´on realizada sobre el proceso gen´erico original. 3. Publicaci´ on y consumo de activos reutilizables El concepto de artefacto reutilizable es muy com´un en los entornos de desarrollo de software, cada uno con su propia manifestaci´on de la misma idea: procedimientos, objetos, componentes, aspectos, servicios, etc. La OMG ofrece un modelo formal para especificar activos reutilizables, independiente de la tecnolog´ıa usada, conocido como RAS (Reusable Asset Specification) [5], que presenta una abstracci´on convenientepara describir artefactos reutilizables: un paquete que describe tanto qu´e puede ser reutilizado como la forma de hacerlo, definiendo expl´ıcitamente tanto los punto de variabilidad 84 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos de los artefactos a reutilizar como el proceso por medio del cual configurarlos. Inspirado en este modelo, TEMPO define una abstracci´on sencilla que describe conceptos tales como activo reutilizable, servicios, contenedores de artefactos, repositorios, etc., a trav´es de interfaces Java. Usando este modelo, la herramienta es capaz de publicar e importar procesos gen´ericos creados por un dise˜nador. El proceso de publicaci´on empaqueta en el activo no solo la descripci´on del proceso, sino un conjunto de servicios que permitir´an mas tarde cargar este activo en otra instancia de TEMPO para ser configurado y reutilizado. Como hemos explicado, en TEMPO se crean procesos gen´ericos que deben ser distribuidos para su uso por parte de distintos configuradores. Todo este proceso de creaci´on y publicaci´on del activo se hace de manera transparente al usuario. La herramienta ofrece asimismo facilidades para que el configurador de procesos explore repositorios de activos reutilizables en busca del proceso gen´erico deseado, y para que lo desempaquete y configure una vez encontrado. Una vez m´as, la parte m´as pesada del proceso de consumo del activo es llevada a cabo por la herramienta. Este proceso de publicaci´on/consumo de activos se corresponder´ıa con la parte m´as pesada de la gesti´on de activos reutilizables de la ingenier´ıa de l´ıneas de producto software. De esta manera, TEMPO completa el soporte integral a los tres procesos para una reutilizaci´on efectiva. Referencias 1. OMG: Software & Systems Process Engineering Meta-model specification, v2.0. Technical Report formal/2008-04-01, OMG (April 2008) Available at http://www.omg.org/docs/formal/08-04-01.pdf. 2. Mart´ınez-Ruiz, T., Garc´ıa, F., Piattini, M.: Towards a spem v2.0 extension to define process lines variability mechanisms. Software Engineering Research, Magament and Applications 150 (2008) 115–130 3. Rombach, D.: Integrated software process and product lines. Unifying the Software Process Spectrum 3840 (2006) 25–31 4. Czarnecki, K., Helsen, S., Eisenecker, U.: Staged configuration through specialization and multi-level configuration of feature models. Software Process Improvement and Practice, special issue on Software Variability: Process and Management 10(2) (2005) 143–169 5. OMG: Reusable asset specification. Technical Report ptc/04-06-06, OMG (Jun 2004) Available at http://www.omg.org/docs/ptc/04-06-06.pdf. Una Aplicaci´ on Web de Gesti´ on Empresarial Orientada a Proyectos para PYMEs* Leticia Gonz´alez Folgueira, Miguel R. Luaces Laboratorio de Bases de Datos, Universidade da Coru˜na Campus de Elvi˜na, 15071, A Coru˜na, Espa˜na {lgonzalezf,luaces}@udc.es Resumen En la actualidad es casi imprescindible disponer de una herramienta inform´atica que permita almacenar y gestionar toda la informaci´on generada por la actividad de una empresa. En este trabajo presentamos una herramienta web que permite realizar las principales tareas de gesti´on empresarial. Se ha optado por una aplicaci´on web para facilitar su uso en entornos distribuidos proporcionando una mayor accesibilidad que una aplicaci´on cl´asica orientada a escritorio. El n´ucleo central de la aplicaci´on se centra en la gesti´on de proyectos que incluye la planificaci´on de tiempos, costes, recursos y esfuerzos, el control de los proyectos y sus actividades y observar la evoluci´on de los mismos en base al tiempo, coste y esfuerzo y las correspondientes comparativas entre lo estimado y lo real. En la administraci´on empresarial tambi´en se incluye la gesti´on del personal de la empresa, el mantenimiento de una agenda de clientes y contactos y la gesti´on de recursos y reservas de los mismos. 1. Motivaci´ on Hoy en d´ıa, realizar la gesti´on de proyectos es un trabajo dif´ıcil para empresas ya que se ven inmersas en un mont´on de papeles expandidos con notas sobre las tareas a realizar, la planificaci´on de costes, etc. Cualquier empresa necesita conocer diversos datos sobre sus proyectos para poder controlar presupuestos, gastos, ingresos y beneficios. De hecho, los beneficios son el sustento de toda empresa, por lo cual es imprescindible una correcta gesti´on para lograr los objetivos satisfactoriamente. Este proceso de gesti´on ser´ıa complejo e implicar´ıa muchas horas de trabajo sin la ayuda de una herramienta inform´atica, mientras que es un proceso sencillo con una aplicaci´on que facilite el seguimiento de los proyectos y la comparaci´on de todos los datos anteriormente se˜nalados. Adem´as, la informaci´on de esta herramienta puede servir para estimar costes de proyectos similares que se afrontar´an en un futuro pr´oximo. El control de los proyectos implica, adem´as de lo mencionado, conocer el tiempo que dedica cada empleado a cada tarea y el coste asociado a dicho trabajo que repercute directamente en los costes del proyecto. Adem´as, la disponibilidadde esta informaci´on permite tambi´en evaluar el rendimiento del empleado. Por lo tanto, es clara la necesidad de disponer de una herramienta sencilla y eficaz que facilite la gesti´on empresarial. Por estos motivos, el Laboratorio de Bases de Datos *Este trabajo ha sido financiado parcialmente por el Ministerio de Educaci´on y Ciencia (PGE y FEDER) ref. TIN2006-15071-C03-03 y por la Xunta de Galicia ref. 2006/4 y ref. 08SIN014E. Actas JISBD 2009, pp.85-88, ISBN: 978-84-692-4211-7 c 2009 Los autores 86 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos de la Universidadde A Coru˜na decidi´o desarrollar una aplicaci´on web que proporcione de forma intuitiva las funcionalidades imprescindibles para la gesti´on empresarial. 2. Funcionalidad Se ha optado por una herramienta web ya que as´ı facilita la gesti´on empresarial en entornos colaborativos, es decir, donde las personas pueden estar f´ısicamente en distintas localizaciones pero necesitan compartir y acceder a la informaci´on en tiempo real. De esta forma, se consigue dotar a la aplicaci´on de mayor accesibilidad que una aplicaci´on cl´asica. Principalmente, la herramienta proporciona las siguientes funcionalidades: Gesti´on de distintos perfiles de usuario de tal forma que el uso que una persona puede hacer de la aplicaci´on depende de los permisos de su rol de usuario. Gesti´on del personal de la empresa y los usuarios asociados que permiten el acceso a la aplicaci´on. Gesti´on de proyectos y sus actividades. Este proceso incluye la planificaci´on de tiempos y asignaci´on de recursos humanos a las tareas. Adem´as permite realizar el seguimiento de los proyectos y el control econ´omico que se centra en los presupuestos, gastos y facturas asociados a cada proyecto. Gesti´on de clientes y contactos asociados. Gesti´on de recursos que permite controlar el uso de los mismos mediante las reservas que una persona realiza de un recurso en unas fechas determinadas. Configuraci´onde ciertos aspectos de la aplicaci´on quedependen del ´area de trabajo de la empresa, como tipos de gastos, estados de factura, estados de proyecto, tipos de recursos y los departamentos de los que consta la organizaci´on. 2.1. Gesti´ on de personal Los usuarios con rol de administrador son los encargados de la gesti´on de usuarios y personal. Se almacena toda la informaci´on relativa al empleado tal como datos personales, datos laborables,datos fiscales y bancarios y dem´as informaci´onrelacionada con su labor en la empresa como permisos y vacaciones, cargos actuales, m´eritos, formaci´on recibida y curr´ıculum correspondiente. Cuando un empleado est´a dado de alta se le puede asignar uno o m´as usuarios con el rol adecuado a su labor en la empresa pudiendo ser: administrador, gerente, responsable de calidad y medio ambiente, responsable de departamento, jefe de proyecto o empleado. De esta forma se restringe la informaci´on a las personas no autorizadas y al mismo tiempofacilita el acceso a las funcionesprincipales del perfilseg´un sus permisos y responsabilidades. Tanto los usuarios con rol de administrador o con rol de gerente pueden acceder a toda la funcionalidad que ofrece la aplicaci´on. Los usuarios con rol de jefe de proyecto o con rol de responsable de departamento se encargan de la gesti´on de los proyectos que dirigen o que pertenecen a su departamento, respectivamente. Los usuarios con rol de empleado tienen como funci´on principal en la herramienta cubrir sus partes horarios con las horas de esfuerzo dedicado diariamente a las tareas que le fueron asignadas. Finalmente, el rol de responsable de calidad y medio ambiente se define en la norma ISO 9001 y es de especial importancia en empresas que cumplen este est´andar. XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 87 2.2. Gesti´ on de proyectos La herramienta desarrollada permite realizar las tareas b´asicas de la gesti´on de proyectos. Un proyecto a lo largo de su ciclo de vida pasa por distintos estados que es necesario conocer para el correcto control y seguimiento, por lo cual en la mayor´ıa de las ocasiones la informaci´on relativa a los proyectos se muestra agrupada por el estado actual en el que se encuentran. Este proceso comienza cuando un responsables de departamento da de alta un nuevo proyecto definiendo sus datos generales, como el nombre, la descripci´on, las fechas estimadas, presupuesto, el cliente del proyecto y el departamento de la empresa encargado del mismo, entre otros. A continuaci´on, se asigna uno o m´as jefes de proyecto responsables del mismo y a partir de ese momento ambos roles podr´an encargarse de la planificaci´on y seguimiento del proyecto. Entre las tareas principales destacamos la divisi´on del proyecto en actividades y subactividades,definiendo las fechas de comienzo y fin estimadas que luego ser´an completadas con las fechas reales en que se desarroll´o dicha actividad. Los recursos humanos se asignan a las actividades concretas indicando las fechas en que se debe realizar el trabajo y la estimaci´on en horas de esfuerzo que implica. Todo usuario dispone de su parte de trabajo en el cual consulta las actividades que tiene asignadas e introduce las horas dedicadas diariamente a cada una de ellas. De esta forma la informaci´on de los proyectos se actualiza instant´aneamente. Para un mayor detalle econ´omico se controlan los gastos y facturas de cada proyecto, detallando el tipo de gasto en cuesti´on y el importe del mismo, y en el caso de las facturas las fechas relevantes, el importe y el estado en que se encuentra. Con todo esto, se permite al responsable de departamento y al jefe de proyecto consultar en todo momento los datos actualizados en base a tres ejes: econ´omico, tiempo y esfuerzo. Los responsables de los proyectos pueden consultar y comparar todos los datos, obteniendo as´ı informaci´on tanto de los costes y beneficios inicialmente estimados como de los que se est´an obteniendo. Esta comparaci´on se puede hacer tambi´en para las fechas estimadas y fechas reales, y para el trabajo inicialmente previsto y las horas reales. Para facilitar esta tarea se dispone de varios listados. El listado principal muestra el resumen de la informaci´on econ´omica en base a costes y beneficios estimados en comparaci´on con los obtenidos,y tambi´enel esfuerzoplanificado frenteal trabajo real quefinalmente conlleva. Estos resultados se pueden obtener generando din´amicamente un informe en formato PDF. La aplicaci´on permite desglosar esta informaci´on seg´un el detalle deseado, para eso ofrece distintos listados seg´un lo que se desee consultar, como ejemplo destacamos los listados que presentan el trabajo realizado en cada proyecto a lo largo del tiempo, con tablassemanales,mensualesoanuales.Con tablastemporalestambi´ense puedeconocer la dedicaci´on de cada empleado a sus proyectos, o por el contrario que personas han trabajado en cada proyecto y actividades en determinadod´ıa o mes. 2.3. Gesti´ on de recursos y contactos Generalmente una empresa cuenta con un conjunto de recursos materiales que ser´an utilizados porlos empleados en el momentoque sea preciso.Para mejorarorganizaci´on, 88 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos se agrupan por tipo de recurso que depender´a de la actividad que desarrolle la empresa. El control de recursos se lleva a cabo mediante reservas. Un recurso se reserva por una persona entre unas fechas determinadas de forma que ya nadie podr´a solicitar ese recurso en dichas fechas y se puede conocer quien es el responsable del mismo en cada momento. Todo usuario puede consultar los recursos existentes y la lista de sus reservas, pudiendo realizar una nueva reserva siempre que el recurso solicitado se encuentre disponible en la fecha deseada. Con respecto a esta funcionalidad podemos destacar la existencia de un calendario de reservas que muestra para un recurso cuando est´a reservado y por qui´en, y el listado que muestra la misma informaci´on pero para el conjunto total de recursos pudiendo filtrar por tipo. Por otra parte, la aplicaci´on permite mantener una agenda de contactos que generalmente van asociados a un cliente concreto. Esta agenda se divide en contactos p´ublicos (que puede consultar cualquier usuario) o privados (a los que s´olo tiene acceso la persona que cre´o el contacto y los administradores). 3. Conclusiones Se ha desarrollado una aplicaci´on web que facilita la gesti´on de proyectos en entornos distribuidos mediante interfaces sencillas que proporcionan comodidad y facilidad de acceso a las funcionesm´as necesarias encada p´agina dela aplicaci´on.La aplicaci´on implementa las funcionalidades b´asicas de la gesti´on de proyectos con informaci´on siempre actualizada al ir imputando horas de esfuerzo mediante partes horarios. Adem´as, la aplicaci´on incluye control de gastos y facturaci´on, gesti´on de recursos, agenda de contactos y clientes, soporte multiling¨ue y facilidad de configuraci´on adaptando la herramienta a la actividad que se desarrolla en la empresa. Por lo tanto, consideramos que el uso de la herramienta facilita la administraci´on y gesti´on de una PYME. Parte IV Sesi´ on 3. Requisitos / Ingenier´ ıa del software emp´ ırica 96 XIV Jornadas de Ingeniería del Software y Bases de Datos experimentos [16]. A continuación se presentan un conjunto de pautas para poder aplicar los métodos de agregación presentados de forma conjunta. 3.3. Pautas para el uso de los métodos de agregación Para determinar cuándo usar un método de MA u otro, se deben analizar sus restricciones de uso (parámetros estadísticos, relación entre las variables respuesta, etc.) y la cantidad de estudios identificados como base para determinar qué método utilizar en caso que pueda aplicarse más de uno. En tal sentido, podemos decir que si se cuenta con un conjunto de 15 o mas experimentos que publican medias, varianza, y cantidad de sujetos experimentales se recomienda utilizar DMP, por ser éste el método mas eficiente [16], pero, en caso de tener menos de 15 experimentos con estas características, se deberían agregar mediante el método RRP [16]. Por otra parte cuando los estudios presentan problemas de informes, se recomienda utilizar el RRNP si los estudios publican solo las medias y la cantidad de sujetos experimentales, y VCE si en los estudios en lugar de detallar las medias se limitan a indicar que un tratamiento es mejor que el otro. En la tabla 1 se describen los criterios antes mencionados. El informes publica Cantidad de estudios Medias, varianzas y cantidad de sujetos experimentales Medias y cantidad de sujetos experimentales Diferencias entre Medias y cantidad de sujetos experimentales >= 15 Usar DMP < 15 Usar RRP Usar RRNP Usar VCE Tabla 1. Condiciones de aplicación de los métodos. Se debe tener en cuenta que las condiciones descriptas en la tabla 1, solo se aplican si las variables respuesta publicadas por los experimentos unicamente difieren en la escala de valores utilizada, para el caso de variables respuesta no iguales el único método de agregación aplicable es VCE. Para aumentar el nivel de evidencia de las conclusiones, se recomienda no utilizar los métodos de forma aislada, sino, por el contrario utilizarlos de forma conjunta, siempre y cuando el uso de alguno de ellos permita incrementar la cantidad de estudios factibles de ser agregados. Así, por ejemplo, si se cuenta con 5 experimentos agregables por RRP y tres por RRNP, la recomendación es agregar los primeros 5 con RRP y los 8 totales por RRNP, de esta forma se podrá generar distintos grupos de agregación que permitan ver como evoluciona el fenómeno con el aumento de la evidencia. Es de hacer notar que cuando se utiliza más de un método de agregación en forma simultánea, los resultados obtenidos pueden no ser compatibles. Cuando esto sucede, se recomienda hacer un análisis para tratar de identificar variables no controladas que afecten al resultado obtenido por cada método, de forma similar a como se hace con el análisis de heterogeneidad. XIV Jornadas de Ingeniería del Software y Bases de Datos 97 4. Caso de Estudio 4.1 Presentación del caso de estudio Para mostrar cómo aplicar los métodos de agregación bajo las pautas definidas, se tomó como base los estudios identificados en la RS desarrollado por [3], ya que los estudios están disponibles, y se contrastarán las conclusiones publicadas, en base a dicha RS, en el artículo [22]. Motiva esta elección el hecho de que en esta RS se ha identificado una gran variedad de técnicas de educción de requisitos, tanto tradicionales (como son las Entrevistas o Análisis de Protocolo) como alternativas (como son Card Sort y Ladderin grid entre otras), lo que permite realizar varios MA. 4.2 Comparación de Resultados Para que el contraste de resultados con los métodos de agregación sea más claro, los resultados obtenidos se muestran mediante los conocidos diagramas de árboles. Es de hacer notar que dichos diagramas en lugar de estar dibujados de forma vertical, como habitualmente lo dibujan los programas especializados en MA, han sido dibujados de forma horizontal mediante Ms EXCEL debido a que no se ha podido identificar ningún programa que aplique los métodos de agregación alternativos. Tener en cuenta que los extremos de las líneas vinculadas al eje Y representan los límites del intervalo de confianza, el punto identifica el tamaño de efecto y el peso del estudio se representa mediante el valor que acompaña el código de experimento debajo del eje X. 4.2.1 Caso 1: El Análisis de Protocolo no aporta más conocimientos que la Entrevista Esta conclusión fue obtenida en base a cuatro experimentos (E-1 [23], E-2 [24], E-3 [25] y E-4 [25]) que comparan Entrevista vs. Análisis de Protocolo (AP) analizando la variable ganancia (cantidad de cláusulas obtenidas). Dado que solo uno de estos estudios publica todos los parámetros estadísticos y los tres restantes publican medias y cantidad de sujetos experimentales, y no existen problemas con las variables respuesta, los mismos pueden agregarse mediante RRNP. Como se aprecia en la figura 1, el tamaño de efecto global es apróximadamente 1,5, lo que implicaría que la entrevista es casi un 50 % mejor que el AP, pero, como el intervalo de confianza contiene al valor 1, la evidencia no puede ser considerada significativa al 95%. Por lo tanto, se reafirma la no existencia de evidencia de que el AP es mejor que la entrevista. 98 XIV Jornadas de Ingeniería del Software y Bases de Datos Fig. 1. Entrevista vs. AP (Ganancia). 4.2.2 Caso 2: Las Entrevistas insumen más tiempos que el Análisis de Protocolo Esta conclusión fue obtenida en base a cuatro experimentos (E-1 [23], E-2 [24], E-3 [25] y E-4 [25]) que comparan Entrevista vs. Análisis de Protocolo (AP) analizando la variable esfuerzo (tiempo necesario para desarrollar la sesión y analizar los datos). Dado que solo uno de estos estudios publica todos los parámetros estadísticos y los tres restantes publican medias y cantidad de sujetos experimentales, y no existen problemas con las variables respuesta, los mismos pueden agregarse mediante RRNP. Como se aprecia en la figura 2, el tamaño de efecto global es apróximadamente 1, lo que implicaría que no se espera que existan diferencias en el desempeño de ambas técnicas. Por lo tanto, se contradice la afirmación original, no hay evidencias para afirmar que la entrevista consume más tiempo que el AP. Fig. 2. Entrevista vs. AP (Esfuerzo). 4.2.3 Caso 3: Laddering Grid aporta más conocimiento que Card Sort Esta conclusión fue obtenida en base a cuatro experimentos (E-1 [23], E-2 [24], E-3 [25] y E-4 [25]) que comparan las técnicas Laddering Grid (LD) vs. Card Sort (CS) analizando la variable ganancia (cantidad de cláusulas obtenidas). Dado que solo uno de estos estudios publica todos los parámetros estadísticos y los tres restantes publican medias y cantidad de sujetos experimentales, y no existen problemas con las variables respuesta, los mismos pueden agregarse mediante RRNP. Como se aprecia en la figura 3, el tamaño de efecto global es apróximadamente 2, lo que implicaría que LG duplica el rendimiento de CS, mostrando además evidencias XIV Jornadas de Ingeniería del Software y Bases de Datos 99 significativas al 95%. Por lo tanto, se reafirma el mejor desempeño de LG y se destaca que las diferencias son significativas Fig. 3. LD vs. CS (Ganancia). 4.2.4 Caso 4: Laddering Grid consume más tiempo que Card Sort Esta conclusión fue obtenida en base a cuatro experimentos (E-1 [23], E-2 [24], E-3 [25] y E-4 [25]) que comparan las técnicas Laddering Grid (LD) vs. Card Sort (CS) analizando la variable esfuerzo (tiempo necesario para desarrollar la sesión y analizar los datos). Dado que solo uno de estos estudios publica todos los parámetros estadísticos y los tres restantes publican medias y cantidad de sujetos experimentales, y no existen problemas con las variables respuesta, los mismos pueden agregarse mediante RRNP. Como se aprecia en la figura 4, el tamaño de efecto global es apróximadamente 1,3, lo que implicaría que LG mejora un 30 % el desempeño de CS, pero la evidencia no es significativa al 95%, dado que el intervalo de confianza contiene claramente al valor 1. Por lo tanto, se contradice la afirmación original, no hay evidencias para afirmar que la LG consume más tiempo que el CS. Fig. 4. LD vs. CS (esfuerzo). 4.2.5 Caso 5: La entrevista es más eficiente que CS Esta conclusión fue obtenida en base a cinco experimentos (E-1 [23], E-2 [24], E-3 [25], E-4 [25] y E-5 [26]) que comparan las Entrevistas vs. Card Sort (CS) analizando la variable ganancia estimada como: la cantidad de cláusulas, en los primeros 4 experimentos, y la cantidad de reglas en el último. Dado que solo uno de estos estudios publica todos los parámetros estadísticos y los cuatro restantes publican medias y cantidad de sujetos experimentales, se realizarán dos agregaciones, la 100 XIV Jornadas de Ingeniería del Software y Bases de Datos primera incluirá cuatro experimentos mediante RRNP y la segunda incluirá a los cinco experimentos mediante VCE. Como se aprecia en las figuras 5 y 6, las Entrevistas muestran un mejor comportamiento que CS. En la primer agregación el tamaño de efecto global es apróximadamente 1,35, lo que implicaría que la mejora alcanza el 35%, pero no es significativa al 95% da que el intervalo de confianza contiene al valor 1, en cambio en la segunda agregación, que incorpora un nuevo experimento, muestra resultados significativos y un tamaño de efecto medio similar al estimado anteriormente. Por lo tanto, se reafirma el mejor desempeño de la entrevista y se destaca que las diferencias son significativas. Fig. 5. Entrevista vs. CS (Ganancia) - RRNP Fig. 6. Entrevista vs. CS (Ganancia) - VCE. 5. Discusión Como se puede apreciar en los resultados obtenidos, en general, cuando todos los estudios apoyan a un mismo tratamiento, el resultado obtenido en el MA estadístico es compatible con el resultado original mediante CVNE, pero esto no puede tomarse como una regla universal, ya que en el caso de la combinación de los estudios vinculados a la Ganancia de LD vs. CS, a pesar de que todos los estudios apoyaban a la técnica LG, el resultado final no fue significativo. Esto refuerza la importancia de utilizar métodos estadísticos cuando se realiza un MA para evitar caer en errores de interpretación de los resultados. También es importante el uso de MA cuando no existe un claro ganador entre los tratamientos, ya que en muchos casos pueden existir diferencias significativas a pesar de que no se advierta un claro ganador mediante el CVNE. Por otra parte, el hecho de haber desarrollado dos agregaciones en la comparación de las Entrevistas vs Card Sort permitió, por un lado, afirmar que las diferencias son significativas, gracias al resultado del VCE, y por otro lado, ver como es la influencia de cada estudio en la conclusión final, gracias al RRNP. XIV Jornadas de Ingeniería del Software y Bases de Datos 101 6. Conclusiones Se considera que la incorporación de los métodos de agregación RRNP y VCE ha sido altamente positiva. Si bien la mayoría de las nuevas conclusiones son compatibles con las tomadas originalmente en el artículo [22], el hecho de poder estimar un tamaño de efecto junto con su intervalo de confianza con una fiabilidad del 95% permite a los investigadores expresar sus conclusiones con mayor seguridad. Además mostrar los resultados a través de gráficas como el diagrama de árboles permite hacer un chequeo de heterogeneidad, un aspecto más que relevante a la hora de generar un resultado mediante la agregación de experimentos. Dado que los métodos de agregación utilizadas han sido desarrolladas por investigadores de otras ramas de la ciencia, como son la medicina y la ecología, se considera de utilidad desarrollar nuevos trabajos tendientes a mostrar como es el comportamiento de estos métodos en un contexto experimental como el que hoy presenta la IS. 7. Financiamiento Este trabajo ha sido parcialmente financiado por el Ministerio de Ciencia y Tecnología del Gobierno de España, en el marco del proyecto TIN2008-00555. 8. Referencias 1. Basili, V. R., Green, S., Laitenberger, O., Lanubile, F., Shull, F., Sörumgård, S., Zelkowitz, M.; 1996; The empirical investigation of perspective-based reading, International Journal on Empirical Software Engineering, Vol. 1, No. 2; pp. 133–164 2. Kitchenham, B. A.; 2004; Procedures for performing systematic reviews. Keele University; TR/SE-0401. Keele University Technical Report. 3. Davis, A.; Dieste o.; Hickey, A.; Juristo, N.; Moreno, A.; 2006; Effectiveness of Requirements Elicitation Techniques: Empirical Results Derived from a Systematic Review; 14th IEEE Int. Requirements Engineering Conference (RE'06); pp. 179-188 4. Juristo N., Moreno A., Vegas S.; 2004; Towards building a solid empirical body of knowledge in testing techniques. ACM SIGSOFT Software Engineering Notes (SIGSOFT) 29(5); pp. 1-4 5. Jedlitschka, A. and Ciolkowski, M.; 2006; Reporting Experiments in Software Engineering; Franhofer Institute for Experimental Software Engineering. 6. Dyba, T., Kampenes, V., & Sjoberg, D.; 2006; A systematic review of statistical power in software engineering experiments. Information and Software Technology, 48(8); pp. 745- 755. 7. Dyba, T., Aricholm, E.; Sjoberg, D.; Hannay J.; Shull, F.; 2007; Are two heads better than one? On the effectiveness of pair programming. IEEE Software; pp. 12-15. 8. Miller, J.; 2000; Applying Meta-analytical Procedures to Software Engineering Experiments. Journal of Systems and Software. (54): 1; pp. 29-39. 9. Glass, G; 1976; Primary, secondary, and meta-analysis of research. Educational Researcher 5; pp. 3-8 102 XIV Jornadas de Ingeniería del Software y Bases de Datos 10. Goodman C.; 1996; Literature Searching and Evidence Interpretation for Assessing Health Care Practices; SBU; Stockholm. 11. Hedges, L.; Olkin, I.; 1985; Statistical methods for meta-analysis. Academic Press. 12. Mohagheghi, P., & Conradi , R.; 2004; Vote-Counting for Combining Quantitative Evidence from Empirical Studies - An Example. Proceedings of the International Symposium on Empirical Software Engineering (ISESE'04) . 13. Borenstein, M.; Hedges, L; Rothstein, H.; 2007; Meta-Analysis Fixed Effect vs. random effect; www.Meta-Analysis.com. 14. Sjoberg, D.; 2005; A survey of controlled Experiments in Software Engineering; IEEE Transactions on Software Engineering; Vol 31 Nro. 9 15. Gurevitch, J. and Hedges, L.; 2001; Meta-analysis: Combining results of independent experiments. Design and Analysis of Ecological Experiments (eds S.M. Scheiner and J. Gurevitch); pp. 347–369. Oxford University Press, Oxford. 16. Lajeunesse, M & Forbes, M.; 2003; Variable reporting and quantitative reviews: a comparison of three meta-analytical techniques. Ecology Letters, 6; pp. 448-454. 17. Jřrgensen, M.; 2004; A Review of Studies on Expert Estimation of Software Development Effort. Journal of Systems and Software. (70): 1-2; pp. 37-60. 18. Staples, M; Niazi,M; Ross Jeffery, D; Abrahams, A; Byatt, P; Murphy, R; 2007: An exploratory study of why organizations do not adopt CMMI. Journal of Systems and Software 80(6); pp. 883-895 19. Kitchenham, B.; 2007; Cross versus Within-Company Cost Estimation Studies: A Systematic Review; IEEE Transactions on Software Engineering; Vol 33 Nro. 5. 20. Mohagheghi, P., & Conradi , R.; 2004; Vote-Counting for Combining Quantitative Evidence from Empirical Studies - An Example. Proceedings of the International Symposium on Empirical Software Engineering (ISESE'04) . 21. Friedrich, J, Adhikari, N; Beyene, J; 2008; The ratio of means method as an alternative to mean differences for analyzing continuous outcome variables in meta-analysis: A simulation study; BMC Medical Research Methodology 22. Dieste, O.; Juristo, N.; Shull, F.; Understanding the Customer: What Do We Know about Requirements Elicitation? Software, IEEE; Volume 25, Issue 2, March-April 2008; pp. 11 – 13. 23. Burton, A., Shadbolt, N., Hedgecock, A. y Rugg, G.; 1988; A Formal Evaluation of Knowledge Elicitation Techniques for Expert Systems: Domain 1. Proceedings of Expert Systems '87 on Research and Development in Expert Systems IV. Pág. 136-145. 24. Corbridge, C., Rugg, G., Major, P., Shadbolt, N. y Burton, A. 1994. Laddering: Technical and Tool in Knowledge Acquisition. Department of Psychology, University of Nottingham. 25. Burton, A., Shadbolt, N., Rugg, G. y Hedgecock, A.; 1990. The Efficacy of Knowledge Elicitation Techniques: A Comparison Across Domains and Level of Expertise. Knowledge Acquisition 2(2): 167-178. 26. Schweickert, R., Burton, A., Taylor, N., Corlett, E., Shadbolt, N., Rugg, G. y Hedgecock, A.; 1987. Comparing Knowledge Elicitation Techniques: A Case Study. Artificial Intelligence Review (1): 245-253. Actas JISBD 2009, pp.103-114, ISBN: 978-84-692-4211-7 ©2009 Los autores Adapting Software by Identifying Volatile and Aspectual Requirements José M. Conejero1, Juan Hernández1, Ana Moreira2 and João Araújo2 1 Quercus Software Engineering Group, University of Extremadura, Spain {chemacm , juanher}@unex.es 2CITI/Dept. Informática, FCT, Universidade Nova de Lisboa, Portugal {ja , amm}@di.fct.unl.pt Abstract. The software market demands systems with highly volatile requirements. Thus, time and effort to adapt software to business’s changes must be reduced as much as possible. However, such volatile requirements are usually tangled with other concerns making systems evolution and adaptation difficult. In this paper, we propose a conceptual framework to identify both crosscutting and volatile requirements. This framework is based on a crosscutting pattern and uses traceability matrices and matrix operations. We also show an aspect-oriented refactoring process to externalize such requirements enhancing the future management of changes. Keywords: Software adaptation, Requirements, Aspect-orientation, Crosscutting, Volatility. 1 Introduction Enhancing business performance requires systems to be able to cope efficiently with changes in requirements, thus reducing time and development effort for adapting software. A key barrier to the success of these systems is the impact of requirements volatility on the system. As Firesmith [7] says: “The more volatile the requirements, the more important it becomes for the requirements process to support the quick and easy modification and addition of requirements”. However, such requirements are usually tangled with other concerns or requirements making evolution and adaptation of systems difficult and restricting maintainability of software. In order to improve software adaptability, in [10] the authors present an approach to cope with those volatile concerns by externalizing them. They propose the use of aspect-oriented techniques to isolate such concerns in the same way as crosscutting concerns. However, the identification of volatile (usually tangled with other concerns) and crosscutting concerns is not trivial and it is usually left to the developer’s expertise. In that sense, in [5] we proposed a conceptual framework where crosscutting is formally defined by means of a crosscutting pattern. This formal definition allows the distinction between the terms of crosscutting and tangling or scattering (often used without any difference). In this paper, we apply the conceptual framework presented in [5] for the identification of not only crosscutting concerns but tangled concerns (where volatile 104 XIV Jornadas de Ingeniería del Software y Bases de Datos concerns are usually involved) as well. Then, the main contributions of the paper, also with respect to our previous work are twofold: first, the paper shows the applicability of the framework to cope with situations where adaptability and evolution must be improved. Since volatile concerns are modularized using aspect-oriented techniques, the system may be evolved just composing different models (model instantiation and composition). Second, the utilization of our conceptual framework helps in automating the process of identifying concerns which must be isolated, allowing an aspectual refactoring process using the model notation introduced in [10]. According to [17], we perform a functional and technical software adaptation, depending on whether it is adapted for handling with volatile (new or changed user needs) or crosscutting concerns respectively. The rest of paper is organized as follows: Section 2 introduces some background on an aspect-oriented approach for coping with volatility [10] and the conceptual framework presented in [5]. In Section 3 we show the application of the conceptual framework used to identify both crosscutting and volatile concerns at requirements level (illustrated by a case study). We also show in this section how to isolate such concerns using Use Case Pattern Specification. Finally, Section 4 presents related works and Section 5 draw some conclusions. 2 Background In this section we introduce the approach presented in [10] and the crosscutting pattern and the matrix operations [5] used in this paper to improve the identification of tangled (which usually include volatile concerns) and crosscutting concerns. 2.1 AORE: Handling Volatility Volatile requirements are business rules with a high degree of evolution. Such requirements may be changed quickly at any time. In [10], the authors propose an approach to cope with volatile concerns by separating or externalizing them (using aspect-oriented techniques). Concern Identification(1) Concern Refactoring(3) Concern Representation(4) Concern Evolution(7) Model Instantiation(5) Model Composition(6) ConcernClassification &Description(2) Fig. 1. Aspect-oriented evolutionary model for volatile concerns (taken from [10]) XIV Jornadas de Ingeniería del Software y Bases de Datos 105 Once the concerns have been modularized they can be composed with the base system later on. The approach focuses on requirements evolution, where classification, composition and instantiation are the most important tasks to achieve a highly evolvable system. The approach consists of several steps (Fig. 1 shows the process outline): 1) The main concerns of the problem domain are identified. A concern refers to a matter of interest that the systems must address to satisfy the stakeholders needs. 2) The concerns identified are classified into several groups: either service or constraint, and either enduring or volatile. This classification leads to a description of each concern. 3) After classifying and describing concerns, the authors externalize the concerns using aspect-oriented techniques. 4) Concerns are then represented using UML use cases, activity models and pattern specifications [8]. Crosscutting and volatile concerns are represented and defined as roles elements in the representation models. 5) The volatile concerns are then instantiated by means of simple rules. This instantiation is needed to perform the next composition step. 6) Finally, the concerns isolated can be weaved into a base model. 7) The steps from 1 to 5 can be iteratively repeated to model new requirements allowing concern evolution. 2.2 The crosscutting pattern In [5] we presented a conceptual framework where crosscutting can be clearly distinguished from scattering and tangling, allowing to formally define these terms. These definitions are based on the study of trace dependencies through an extension to traceability matrices. In particular, our proposition is that crosscutting can be defined in terms of a mapping relationship property. From a mathematical point of view this means that we have two domains (called Source and Target) related to each other through a mapping or traceability relationship. We use the term of Crosscutting Pattern to denote this situation (see Fig. 2). Fig. 2. The crosscutting pattern The terms scattering, tangling and crosscutting are defined as specific cases of the mapping between “source” and “target”. We say that scattering occurs when, in a mapping between source and target, a source element is related to multiple target elements. Similarly, we can focus on the relation between target elements and source elements. This relation (here also called mapping) is the reverse of the previous one. So, we say that tangling occurs when, in a mapping between source and target, a 112 XIV Jornadas de Ingeniería del Software y Bases de Datos 3.5 Model Instantiation (5) After classifying and representing the concerns, use cases where several concerns are tangled or crosscut are separated into several use cases. We use the Use Case Pattern Specification presented in [10] to model these changes. Pattern Specifications (PSs) [8] are a way of formalizing the reuse of models. The notation for PSs is based on UML [11]. A PS describes a pattern of structure or behavior defined over the roles which participants of the pattern play. Role names are preceded by a vertical bar (“|”). A PS can be instantiated by assigning concrete modeling elements to play these roles. A role is a specialization of a UML metaclass restricted by additional properties that any element fulfilling the role must possess. Hence, a role specifies a subset of the instances of the UML metaclass. A model conforms to a PS if its model elements that play the roles of the PS satisfy the properties defined by the roles. Thus, a conforming diagram must instantiate each of the roles with UML model elements, multiplicity and other constraints. Note that any number of additional model elements may be present in a conforming diagram as long as the role constraints are maintained. As in [16], we extend the notion of pattern specification from that of [8] by allowing both role elements and concrete modeling elements in a PS. Fig. 5. Use Case Pattern Specification for subway system In order to use this Pattern Specification, both crosscutting and volatile concerns are marked as roles (see “|” mark in Fig. 5). In addition, a new relationship is included to complement the typical <<include>> and <<extend>> ones. The new relationship is called <<constrain>> and is used by requirements which restrict the behaviour of other requirements. In Fig. 5 we can see part of the resulting model for the subway system (the whole diagram is not shown for space reasons). Note that the requirements regarding to crosscutting or volatile concerns have been modeled in a separate use case and maintain <<constrain>> or <<include>> relationships with the base use cases. Managing such requirements by aspect-oriented techniques allows the developer to obtain a high degree of evolution and adaptability in the systems build. 3.6 Model Composition (6) The requirements engineer may quickly cope with business rules’ changes without altering the rest of the system. For example, if the business rules to calculate the trip fare is based on a fixed price the use case role |CalculateFare can be instantiated with the following rule (see [10] to obtain more details): XIV Jornadas de Ingeniería del Software y Bases de Datos 113 Replace |CalculateFare with CalculateFareBasedOnFixedPrice However, if the business rules changes for the trip fare to be based on zones, the use case role |CalculateFare can be instantiated with a rule of the type: Replace |CalculateFare with CalculateFareBasedOnZones Therefore, externalizing volatility promotes system evolution and adaptability, as changing the behavior of the system does not require to change what is already specified, but simply add new concerns and define new (or refine) existing instantiation rules. In [10], the authors also show how to perform a model composition to weave the isolated behavior with the base model (using composition rules and UML activity diagrams). The composition is not shown here since we focus on isolation of volatile and crosscutting behavior and not composition. 4. Related Work In the area of Early Aspects, there are several authors who have presented methodologies for the identification of crosscutting concerns at requirements level, for example, the approach presented in [1] and [15]. However, this approach is focused only on requirements phases while the crosscutting pattern used here could be applied in any phase of the software life cycle [3][5]. Several authors have used matrices (design structure matrices, DSM) to analyze modularity in software design [2]. Lopes and Bajracharya [9] describe a method with clustering and partitioning of the design structure matrix for improving modularity of object-oriented designs. Even in [13], a relationship matrix (concerns x requirements) is described very similar to our dependency matrix, and used to identify crosscutting concerns. However, there is no formalized definition of crosscutting. In [12] the authors propose the adaptation of software systems by means of the utilization of aspect-oriented techniques. They model the systems using UML and perform model checking to ensure that the system does not contain any inconsistence. While this work focuses on solving some interoperability problems after adapting software system using aspects, our work focuses on the identification of crosscutting and tangled behaviour in order to modularize it (by aspect-oriented techniques). 5. Conclusions and further work We proposed a framework to identify volatile and crosscutting concerns at requirements level. This framework is based on a crosscutting pattern where definition of crosscutting is formalized by means of trace relationships. We visualize such relationships by means of traceability matrices. The identification of volatile concerns is based on tangling in the system since such concerns are usually jumbled with other concerns. Crosscutting concerns are identified by means of simple matrix operations. Once the volatile and crosscutting concerns have been identified, the requirements can be refactored so that each concern is modularized in a single entity. The UCPS representation illustrates the refactorization. This is particular useful in 114 XIV Jornadas de Ingeniería del Software y Bases de Datos model-driven software engineering where model transformations could take into account volatile concerns and the system may be built based on these transformations (our future work). As we have showed, our conceptual framework has different application areas in addition to identification of crosscutting concerns. In other publications we have shown other interesting applications such as traceability of crosscutting concerns throughout a whole development process [5], identification of crosscutting concerns at design level [3] or the definition of a concern-oriented metrics to assess modularity of systems [6]. References 1. Araujo, J., Moreira, A., Brito, I. & Rashid, A. (2002). Aspect-Oriented Requirements with UML, In Workshop on AOM with UML at International Conference on UML, Germany 2. Baldwin, C.Y. & Clark, K.B. (2000). Design Rules vol I, The Power of Modularity. MIT Press 3. Berg, K. van den, Conejero, J. & Hernández, J. (2006). Identification of crosscutting in software design. In Aspect-Oriented Modeling Workshop at 5th AOSD, Bonn 4. Chung, L., Nixon, B., Yu, E. & Mylopoulos, J. (2000) Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, 2000 5. Conejero, J. M., Berg, K. van den & Hernández, J. (2007). Analysis of Crosscutting in Early Software Development Phases based on Traceability. In Transactions on AOSD III, Volume 4620/2007, ISBN: 978-3-540-75161-8. 6. Conejero, J., Figueiredo, E., Garcia, A., Hernández, J. & Jurado, E. (2009) Early Crosscutting Metrics as Predictors of Software Instability. To appear in 47th International Conference Objects, Models, Components, Patterns (TOOLS Europe). Zurich, Switzerland. 7. Firesmith, D. G. (2004). Creating a Project-Specific Requirements Engineering Process, in Journal of Object Technology, vol. 3, no. 5, 2004, pp. 31-44. 8. France, R., Kim, D., Ghosh, S. & Song, E. (2004) A UML-Based Pattern Specification Technique, IEEE Transactions on Software Engineering, Volume 30(3), 2004 9. Lopes, C.V. & Bajracharya, S.K. (2005). An analysis of modularity in aspect oriented design. In 4th International AOSD Conference. Chicago, Illinois 10. Moreira, A., Araujo, J. & Whittle, J. (2006) Modeling Volatile Concerns as Aspects. In 18th CAISE. LNCS 4001/2006: 544-558. ISBN: 978-3-540-34652-4, Luxembourg. 11. OMG (2005). UML Specification, version 2.0, August 2005, http://www.omg.org 12. Pérez-Toledano, M., Navasa, A., Murillo, J.M. & Canal, C. (2007). Safe Dynamic Adaptation using Aspect-Oriented Programming. In 4th Workshop on Coordination and Adaptation Techniques for Software Entities, in conjunction with ECOOP’07, Germany. 13. Rashid, A., Moreira, A. & Araujo, J. (2003). Modularisation and Composition of Aspectual Requirements. In Second AOSD Conference. Boston, USA 14. Sampaio, A., Chitchyan, R., Rashid, A. & Rayson, P. (2005). EA-Miner: A Tool for Automating Aspect-Oriented Requirements Identification, ASE’05, IEEE Computer Society 15. Sampaio, A., Loughran, L., Rashid, A. & Rayson, P. (2005). Mining Aspects in Requirements. In Early Aspects 2005 Workshop at AOSD Conference. Chicago, USA 16. Whittle, J. and Araujo, J. (2004). Scenario Modeling with Aspects, in IEE Proceedings Software, Vol. 151, no. 04, pp. 157-172. 17. Yahiaoui, N., Traverson, B. & Levy, N. (2004), Classification and comparison of Adaptable Platforms. In 1st International Workshop on Coordination and Adaptation Techniques for Software Entities, in conjunction with ECOOP’04, Oslo, Norway. A Tool-supported Natural Requirements Elicitation Technique for Pervasive Systems centred on End-users  Francisca Pérez and Pedro Valderas Centro de Investigación en Métodos de Producción de Software Universidad Politécnica de Valencia Camino de Vera, s/n, 46022 Valencia, Spain {mperez, pvalderas}@pros.upv.es Abstract. It is very important that end-users participate in the requirement elicitation process because they are the “owners” of the problem. In this paper, we present a natural requirements elicitation technique for pervasive systems centred on end-users that provide them a tool-supported natural visual language in order to describe the main characteristics of their pervasive system. Furthermore, we present a requirement elicitation process which guides end-users in the description. 1 Introduction In this work, we present a tool-supported requirements elicitation technique for pervasive systems centred on end-users. End-users are the ones who have more in-depth knowledgeabout both the services that must be providedby the system and the environment in which the system is going to be deployed. Thus, we think it is very important that end-users actively participate with analysts in the description of the requirements of a pervasive system. However, end-users have no knowledge about requirements engineering techniques or computation in general. Thus, end-users need to be provided with techniques and tools that allow them to specify their requirements in a natural way. Natural is a concept used in the field of end-user development and it is defined as [1] “faithfully representing nature or life,” which implies that it works in accordance with the way peopleexpect.Thus, our maingoal is to define a natural requirementselicitation technique that helps end-users to describe the system they need. To do this, we present a tool whose interface is inspired by well-accepted techniques and metaphors in the field of end-user development. This tool allows end-users to describe the environment in which the system must be deployed, the devices that are available, and the services that these devices must provide end-users with. Note that this tool constitutes a valuable mechanism to be used in requirements elicitation activities that helps analysts to identify the user needs that the system must satisfy. Finally, we have defined a requirements elicitation process that precisely determines the steps that end-users must follow to create a system description and how end-users and analysts interact to each other along this process. This work has been developed with the support of MEC under the project SESAMOTIN2007- 62894 and cofinanced by FEDER, in the grants program FPI. Actas JISBD 2009, pp.115-120, ISBN: 978-84-692-4211-7 c 2009 Los autores 116 XIV Jornadas de Ingeniería del Software y Bases de Datos 2 Supporting end-user with elicitation tools In order to allow end-users to describe their needs, we have developed a prototype of an elicitation tool. To do this, we have studied first end-users population. Our study concludes that end-user population is quite diverse because end-users are present in a lot of domains and with different needs [2] and we have observed two main common profiles: (1) End-users who are not familiarized with computers applications and (2) Advanced end-users who computers applications are familiar for them but they are not a professional (e.g. doctors, accountant...).Ourmain goal is to provide these two profiles with our tool. These profiles are supported by different types of interfaces: closed-option and open-option. End-users are supported by closed-option interfaces and advanced endusers are supported by both interfaces. Closed-optioninterfaces provide end-users with acatalogue of requirements. This catalogue allows end-users to select those requirements that satisfy their needs. In this case, the catalogue offers end-users pervasive requirements, which include the available services and a default configurationfor them. Open-option interfaces allow advanced end-users to define new requirements if the requirements catalogue does not satisfy their needs. To support this, our tools need to offer a mapping between the information which represents the catalogue and the user’s requirements with the computer’s interface and technologiesfor it. To do this mapping, we use avisual language.To definethis visual languageand interfaces,we haveinspired by Natural Programming [1], Visual Programming [3], Programming By Example [4] and Jigsaw metaphor [5]. In our tool, we have represented the catalogue using the Feature Modelling technique [6]. In order to tackle the representation of the catalogue in the proper interface, we use a Controller. The Controller also assists end-users in the description of their needs and it checks that the description of end-users are completed and without errors.The Controller is implemented using Eclipse Modelling Framework (EMF) and FAMA Framework [7]. Furthermore, a repository is used to save the enduser system description. Fig. 1 shows a smart example of the catalogue which supports the available services and devices for a smart home modelled as a feature model and the architecture which supports our tool. Fig.3 showsa snapshotofourprototypicaltool.Thename of thecurrentview is represented at the top, a title which indicates what are required by the tool and the buttons to navigate among views. The available devices for the environment are represented on the left together with a representative image. On the right of the figure is represented the environment, their locations and the devices previously selected. Finally, at the bottom of the figure, the information area, where our tool can advice to end-users or assist them, is shown. 3 Requirement Elicitation Process We have defined a requirements elicitation process in which end-users actively participate describing their needs by using the tool presented above. This process determines the steps that end-users must follow to create a system description and how end-users and analyst must interact with each other. Thus, we propose four phases (see Fig. 2): XIV Jornadas de Ingeniería del Software y Bases de Datos 117 Fig.1. Elicitation tool architecture Context scope, System specification, Advancedsystem and Validation. In the following subsections, we describe the steps that conform each phase in detail. Fig.2. Natural Requirements Elicitation process 3.1 Context scope The analyst determines the domain of the system to be developed and the end-user profile. Then, analysts prepare the end-user tool in order to allow end-users to interact with a natural interface adaptedto their profileand the system domain.On the one hand, if analysts consider that end-users are familiar with computer applications the tool is prepared to be used through open-option interfaces. Otherwise, the tool is prepared to be used through closed-option interfaces. On the other hand, if, for instance, the system domainis smart homes,the tool isadapted toshow onlyconceptsrelated tosmart homes (i.e. locations, services, devices). The analyst captures the information using traditional interviews. 118 XIV Jornadas de Ingeniería del Software y Bases de Datos 3.2 System specification End-users must describe the main characteristics of pervasive system by using the presented tool. Five steps are proposed to do this. Step 2.1: Specification of users and policies. End-users must describe the users who are able to use the system, their desired policies and the links between a user and a policy. For example, two users can be “Paul” and “Mary” while two policies can be “Parents” and “Kids”. In further steps, end-users must indicate the services that users of each policy can activate. For instance, users of the “Kids” policy must not be able to activate the security service. This step is performed in a different way depending on the end-user profile. On the one hand, non-advanced end-users must describe users and policies by working in collaboration with analysts. On the other hand, in order to support advanced end-users to define this information by themselves we have defined a proper interface which is composed of two areas: User and Policy. In each area end-users can manage the users or policies. Step 2.2:Characterizationof the physical environment.Characterizationimplies to define the differentlocations in which services can be available and which the system must be aware of. To support this in our tool, we allow end-user to define the different locations that must be known by the system in an image (a map or even a picture) that represents their physical environment. This representation is based on the knowledge and environment they are familiar with. An example of environment is shown in the snapshot of Fig. 3 where the different locations of a home (one corridor, one bathroom, one bedroom, one kitchen and one living room) have been identified over a map. Step 2.3: Specification of services. End-users have to specify the needed services in their physical environment and where they are located (e.g. Automated Illumination service in the living room). To allow this, we keep the characterization of the physical environment defined in the previous step and we offer the user a predefined catalogue of available services. The tool provides end-users with an interface like Fig. 3 shows: a left frame that offers the list of available services and a right frame that offers the representation of the physical environment. In order to define a service in a location, end-users just need to select it from the left frame and depict it into the proper location. Then, the representative image for the service is displayed. Step 2.4: Specification of devices. End-users specify the devices that are available in each location. To do this, the tool provides the user with an interface as Fig. 3 shows, which is divided into two frames: the left frame displays the list of devices that are available in the catalogue whereas the right frame represents of the physical environment. Step 2.5: Configuration of the specified services. End-users are able to define the configuration of each specified service. To support this in our tool, the tool’s interface offers a default configuration for each service in a series of left-to-right couplings of jigsaw pieces. Hence to customize a service, end-users have to remove a piece that represents their change and join another compatible piece. For instance, if end-users need to customize the service configuration to use a gradual lamp rather than a lamp they just need to remove the piece representing the Lamp and join the Gradual Lamp piece (see the Service Configuration of Fig.3). XIV Jornadas de Ingeniería del Software y Bases de Datos 119 Fig.3. Requirements for a smart home 3.3 Advanced system configuration In this phase the information related to the description of new services is captured. Advanced end-users can perform the proposed step by themselves (using an open-option interface) while non-advancedend-users need to interact with analysts. To describe a new service the needed information is: name of the service, where the service is located, what devices/services are needed to sense the context information (condition) and what devices/services are needed to activate this service (action). For example, end-users may need a Full Automated Illumination service that switches on a lamp and a gradual lamp when presence in the living room is detected. To support this in our tool, the open-option interface offers the same representation of the physical environment introduced above. This visual representation is again complemented with a different left frame that provides advanced end-users with mechanisms to define the information required. In order to introduce information such as location, end-users just need to select the corresponding option in the left frame and then select the location in the representation of the environment. 3.4 Validation The analyst validates together with end-users the system described by end-users using a traditional interview. In case some ambiguities or mistakes are detected, end-users can perform again the different phases of the process in an iterative way. Otherwise, the obtaineddescription constitutes a valuable productin order to allow analysts to a formal requirement specification that can be used as guide for the rest of the development process. An example of the end-user descriptions obtained by using the proposed tool is shownin Fig. 3. In particular,this figure partially shows the requirementsof the smart home system used as a case study. 120 XIV Jornadas de Ingeniería del Software y Bases de Datos 4 Conclusions and future work End-users need to be provided with techniques and tools that allow them to specify their needs in a natural way. In this paper, we have presented a natural requirements elicitation technique that helps end-users describe the system they need. In particular, we have focused on the description of pervasive systems by end-users. To do this, we have presented the prototype of a tool that supports end-users in the creation of pervasive system descriptions. We have also defined a requirements elicitation process that precisely determines the steps that end-users must follow to create a system description. Once the process is finished, analysts have a description which is the base to create a formal requirements specification. As future work, we are working on tools that help analysts to automatically obtain formal requirements specification from these descriptions. References 1. Brad A. Myers, John F. Pane, and Andy Ko. Natural programming languages and environments. Commun. ACM, 47(9):47–52, September 2004. 2. Christopher Scaffidi, Mary Shaw, and Brad Myers. The “55m end-user programmers” estimate revisited, 2005. 3. Andrew J. Ko and Brad A. Myers. Designing the whyline: a debugging interface for asking questions about program behavior. In CHI ’04, pages 151–158, 2004. 4. Henry Lieberman. Programming by example (introduction). Commun. ACM, 43(3):72–74, 2000. 5. Jan Humble et al. Playing with the bits - user-configuration of ubiquitous domestic environments. In Proceedings of Fifth Annual Conference on Ubiquitous Computing, UbiComp 2003, USA. 6. Francisca Pérez, Carlos Cetina, Pedro Valderas, and Joan Fons. Towards end-user development of smart homes by means of variability engineering. In VaMoS, volume 29, pages 103–110, 2009. 7. P. Trinidad, D. Benavides, A. Ruiz-Cortés, S. Segura, and A.Jimenez. Fama framework. In 12th Software Product Lines Conference (SPLC), 2008. Parte V Sesi´ on 4. MDE y Transformaciones 128 XIV Jornadas de Ingeniería del Software y Bases de Datos a source model, Ada and Java as target programming languages and a model-to-text transformationwith variability incorporatedto connect the sourcewith differenttargets. As a case in point, we considered the generation of switch statements that implement the code of a statechart model. Although switch statements are commonly found in most of current programming languages, they are not exactly defined in the same way. In our example, we define a base transformation with all the common elements of the switch, that will be refined for each output language.There will be a transformation refinement associated to each target language, each adding its specific elements. Base of a Transformation 1 <MOFScriptModel:MOFScriptSpecification ... xak:artifact="base.m2t.model. mofscript" xak:feature="baseTrans"> 2 <transformation line="6" name=" baseTransf" xak:module="transModule "> 3 <variables line="7" column="2" name=" outputFile" type="String" xak:module=" oFileModule"/> 4 <parameters line="6" column="39" name="sc" type="http: //www.w3.org/2005/07/ scxml"/> 5<!−− Content omitted−− > 6 <transformationrules line="64" name=" writeSwitchStart" xak:module=" switchStartModule "> 7 <context line="64" name=" self" type="module"/> 8 </transformationrules> 9<!−− Content omitted−− > 10 </transformation> 11 </MOFScriptModel:MOFScriptSpecification> Fig.3. Base Transformation (XMI representation) A base transformation definition has been defined with MOFScript (see Figure 2). This definition takes a statechart model as input, and has the rules to generate a switch statement as output. Since the switch statement differs among different languages, this base transformation only has the common elements. In our example, the base transformation defines some common rules to generate a switch statement based on the statechart model. Some rules for writing the output are defined (e.g. writeSwitchStart) but they are empty due to the fact that the output text varies depending on the syntax of the output programming language. In the base transformation a variable named outputFile is defined too, to specify the name of the output file, but this variable is not yet given a particular value. The assignment will be done with a refinement, which will assign a name related to its output language later on. MOFScript allows to represent a transformation definition as a model, conforming to the MOFScript metamodel. Figure 3 shows the model representation of the transformation using XML Metadata Interchange (XMI). (Note that this figure is equivalent to the textual representation of the transformation in Figure 2.) The transformation module is defined with the <transformation> element. Nested to this element, variables, parameters and rules are defined using the <variables>,<parameters> and <transformationrules> elements, respectively. XIV Jornadas de Ingeniería del Software y Bases de Datos 129 Actually, the base transformation can not be executed standalone since it is not complete, so it may not generate the expectedimplementation.The base transformation needs to be refined for each output language. Refinement of a Transformation 1 <xak:refines xak:artifact="base.m2t.model. mofscript" xak:feature="adaDelta" ...> 2 <xak:extends xak:module="oFileModule"> 3 <xak:super xak:module="oFileModule"/> 4 <value xsi:type="MOFScriptModel:Literal" value="example.adb"/> 5 </xak:extends> 6 <xak:extends xak:module="switchStartModule "> 7 <xak:super xak:module="switchStartModule "/> 8 <statements xsi:type="MOFScriptModel:PrintStatement"> 9 <printBody xsi:type="MOFScriptModel:Literal" value="case state is ; "/> 10 </statements> 11 <blocks statements="// @transformation .0/ @transformationrules .3/@statements.0" protected="true"/> 12 </xak:extends> 13 <!−− Content omitted−− > 14 </xak:refines> Fig.4. XAK-based Refinement of a Transformation A refinement can be deemed of as a function that takes an artifact as an input, and returns another similar artifact which has been leveraged to support a given feature [3]. XAK is a language for defining refinements in XML documents and provides a composer tool for them [1]. We used it for representing and composing our MOFScriptbased transformations. MOFScript offers the option to represent a transformation definition as a model. Such model can be represented using XMI. Therefore, XAK can be used for refining such transformations. Any traditional XML documentcan be a base document, but some additional annotationsare needed(see Figure3).Theattributes @xak:artifact and@xak:feature are added to the document root element. The first one specifies the name of the document that is being incrementally defined, while the second one specifies the name of the feature being supported (“base” for base documents). To specify which elements are modularizables, @xak:module is used. That is, it indicates those elements that play the role of modules, and henceforth can be refined. In general, a XAK module has a unique name. Refinement documents refine base documents and they have <xak:refines> element as root (see Figure 4). Its content describes a set of module refinements (i.e. elements annotated with the xak:module attribute) extending a given base document (i.e. the xak:artifact attribute). The xak:super node is a marker that indicates the place where the original module body is to be substituted. In general,a XAK refinement document can contain any number of xak:module refinements. Those elements of the transformation that can be refined must be defined before refining such transformation. In our example, the refinement units are the transforma- 130 XIV Jornadas de Ingeniería del Software y Bases de Datos tion definition itself, variables and rules. That is, we can add new rules or variables to the transformation definition, we can add or set values to variables already defined, or we can extend existing rules with new statements. We add xak:module attribute to <transformation>,<transformationrules> and <variables> elements to specify that they are modularizables (see Figure 3). Note that not all elements are modularizable, but only those we designate beforehand by xak:module. Figure 4 shows a refinement for the base transformation. This refinement refines the base transformation definition to generate the code in Ada programming language. Some of the rules in the base transformation are refined adding Ada specific elements. The variable outputFile is given a value. The rules that are refined are those which are used to produce specific code to the output file5. Since the syntax differs between languages, those rules must be refined for each language. Composition of Base and Refinements 1 <MOFScriptModel .. . > 2 <transformation ...> 3 <variables ...> 4 <value value="example.adb" .../ > 5 </variables> 6<!−− Content omitted−− > 7 <transformationrules ...> 8 <context .../> 9 <statements ...> 10 <printBody value="case state is " ... / > 11 </statements> 12 <blocks .../> 13 </transformationrules> 14 <!−− Content omitted−− > 15 </transformation> 16 </MOFScriptModel .. .> (a) 1/∗∗ 2∗Transformation Generated by MOFScript2Text transformation 3∗/ 4 texttransformation baseTransf (in sc :" http ://www.w3.org/2005/07/ scxml"){ 5 var outputFile: String = "example .adb"; 6 7/∗Content omitted ∗/ 8 9 module :: writeSwitchStart () { 10 "case state is\n " 11 } 12 13 /∗Content omitted ∗/ 14 } (b) Fig.5. Composed Transformation: (a) XMI representation; (b) MOFScript representation XAK composer tool is used to compose the refinement to the base transformation, executing the following command: > xak -xak2 -c baseTrans.mofscript adaDelta.xak -o composedAdaTrans.mofscript The result of the composition is a composed transformation model (Figure 5a), which can be executeddirectly givingas input the statechart model, or can be converted 5Due to the lack of space, in the figure only the refinement of the rule writeSwitchStart is shown. The complete example is available for download at http://www.ikerlan.es/softwareproductline/jisbd2009examples.zip XIV Jornadas de Ingeniería del Software y Bases de Datos 131 1case state is 2when sClosed => 3if isWarm then 4 state := sOpened; 5end if ; 6when sOpened => 7if isCool then 8 state := sClosed; 9end if ; 10 when others => 11 end case; (a) 1switch (state) { 2case sClosed: 3if (isWarm) { 4 state = sOpened; 5} 6break; 7case sOpened: 8if (isCool) { 9 state = sClosed; 10 } 11 break; 12 default: 13 } (b) Fig.6. Generated code: (a) Ada; (b) Java to a MOFScript transformation definition file (Figure 5b) using that option in MOF- Script tool and then executed. Note that some rules that were empty in the base transformation definition, have now some body specifying how the output has to be in Ada programming language. So, the customization of model transformations is achieved. The output of the transformationis the example.adb file which has the switch statement according to our model, written in Ada syntax (Figure 6a). Another possible refinement may be to refine the base transformation definition to generate Java code. In this case, the rules should be refined to generate Java code. Although the structure of the generated code is almost the same, the syntax differs from Ada to Java. Additionally,break; sentences are necessary in Java, so a new rule needs to be added to the base transformationto write such sentences. The new rule will be called from generateSwitchCases rule, that need to be refined to add the new statement. Figure 6b shows the code obtained when running the transformation refined for Java. The use of refinements in the context of model-to-text transformations enables the reuse and customization that Software Product Lines promote. Related Work Merging MDD and product lines is not new, we know of examples that explicitly use features in MDD [9,8,10–12,22]. One is BoldStroke: a product-line for supporting a family of mission computing avionics for military aircraft [12]. Czarnecki introduces super-imposed variants and model templates to map features to models [8]. Weber et al. introduce the Variation Point Model that models variation points at the design level [26]. There is a line of work on feature-based composition of models. Feature-oriented model-drivendevelopmentis an approach that ties feature composition to model driven development [25]. Recent work by Apel describes superimposition as a model composition technique to support variability of product lines [2]. FeatureMapper is a tool that 132 XIV Jornadas de Ingeniería del Software y Bases de Datos supports mapping features from feature models to solution artifacts [13]. These works do not yet consider the composition of model transformations or metamodels. Sanchez-Cuadrado presents an approach for the reuse of model transformations in RubyTL by using an idea reminiscent of libraries in programming[6]. This first step towards modeltransformationreuse does not yet incorporatethe notion of productfamily. The superimposed modules of ATL language can be composed into different transformation definitions. This is not related to features, neither to the notion of composition demanded in a product family scenario [15]. Oldevik proposes an aspect-based extension of the MOFScript model-to-text transformation language, which is called a Higher Order Transformations (HOT) [18]. Conclusions This paper presented an approach for the variability of MOFScript-based model-to- text transformations in a software product line scenario. The main contribution is the application of step-wise-refinement in the context of a model transformation. Doing so, the application of variability shifts from scenarios focused only on model variability towards broader scenarios handling the variability of MDD-related artifacts. We claim the need to shift our research attention from the variability of models to a broader perspective embracing the variability of models, metamodels and model transformations. This is indeed the direction of our current research efforts where we are addressing the variability of models, metamodels, and model transformations and their relationships concomitantly, since we believe they are often closely inter-related. Acknowledgments. This work was co-supported by the Spanish Ministry of Science & Innovationunder contractTIN2008-06507-C02-02.We thankto MaiderAzanza for her comments on earlier drafts. References 1. F. I. Anfurrutia, O. Díaz, and S. Trujillo. On Refining XML Artifacts. In ICWE, pages 473–478, 2007. 2. S. Apel, F. Janda, S. Trujillo, and C. Kaestner. Model Superimposition in Software Product Lines. In 2nd International Conference on Model Transformations (ICMT 2009), Zurich, Switzerland, June, 2009. 3. D. Batory, J.Neal Sarvela, and A. Rauschmayer. Scaling Step-Wise Refinement. IEEE Transactions on Software Engineering (TSE), 30(6):355–371, June 2004. 4. J. Bézivin, G. Dupe, F. Jouault, G. Pitette, and J. E. Rougui. First Experiments with the ATL Model Transformation Language: Transforming XSLT into XQuery. In 2nd OOPSLA Workshop on Generative Techniques in the context of MDA, Anaheim, California, USA, Oct 27, 2003. 5. P. Clements and L.M. Northrop. Software Product Lines - Practices and Patterns. Addison- Wesley, 2001. 6. J. Sanchez Cuadrado and J. Garcia Molina. Approaches for Model Transformation Reuse: Factorization and Composition. In International Conference of Model Transformations (ICMT), 2008. XIV Jornadas de Ingeniería del Software y Bases de Datos 133 7. J. Sánchez Cuadrado, J. García Molina, and M. Menárguez Tortosa. RubyTL: A Practical, Extensible Transformation Language. In 2nd European Conference on Model Driven Architecture - Foundations and Applications (ECMDA-FA 2006), Bilbao, Spain, Jul 10-13, pages 158–172, 2006. 8. K. Czarnecki and M. Antkiewicz. Mapping Features to Models: A Template Approach Based on Superimposed Variants. In 4th International Conference on Generative Programming and Component Engineering (GPCE 2005), Tallinn, Estonia, Sep 29 - Oct 1, 2005. 9. K. Czarnecki and M. Antkiewicz. Model-Driven Software Product-Lines. In 20th Annual ACMSIGPLANConference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2005), San Diego, CA, USA, Oct 16-20, 2005. 10. S. Deelstra, M. Sinnema, J. van Gurp, and J. Bosch. Model Driven Architecture as Approach to Manage Variability in Software Product Families. In Workshop on Model Driven Architecture: Foundations and Applications (MDAFA), Enschede, The Netherlands, June 26-27, 2003. 11. B. Gonzalez-Baixauli, M.A. Laguna, and Y. Crespo. Product Lines, Features, and MDD. In 1st Europeean Workshop on Model Transformation (SPLC-EWMT’05), Rennes, France, Sep 25, 2005. 12. J. Gray and et al. Model Driven Program Transformation of a Large Avionics Framework. In 3th International Conference on Generative Programming and Component Engineering (GPCE 2004), Vancouver, Canada, Oct 24-28, 2004. 13. F. Heidenreich, J. Kopcsek, and C. Wende. FeatureMapper: Mapping Features to Models. In 30th International Conference on Software Engineering (ICSE 2008), Companion, pages 943–944, New York, NY, USA, may 2008. ACM. 14. D. Herst and E. Roman. Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) - Approach: A Productivity Analysis. Technical report, TMC Research Report, 2003. 15. F. Jouault and I. Kurtev. Transforming Models with the ATL. In International Conference on Model Driven Engineering Languages and Systems (MODELS 2005), 2005. 16. K. C. Kang and et al. Feature Oriented Domain Analysis Feasability Study. Technical Report CMU/SEI-90-TR-21, Software Engineering Institute, November 1990. 17. I. Kurtev. Adaptability of Model Transformations. PhD thesis, University of Twente, 2005. 18. J. Oldevik and O. Haugen. Higher-order transformations for product lines. Software Product Line Conference, International, 0:243–254, 2007. 19. OMG. MDA Success Stories. http://www.omg.org/mda/products_success.htm. 20. OMG. MDA Guide version 1.0.1. OMG document 2003-06-01, 2003. 21. K. Pohl, G. Bockle, and F. van der Linden. Software Product Line Engineering - Foundations, Principles and Techniques. Springer, 2006. 22. D. Schmidt, A. Nechypurenko, and E. Wuchner. MDD for Software Product-Lines: Fact or Fiction. In Workshop at 8th International Conference on Model Driven Engineering Languages and Systems (MoDELS 2005), Montego Bay, Jamaica, Oct 2-7, 2005, 2005. 23. S. Sendall and W. Kozaczynski. Model Transformation: The Heart and Soul of Model-Driven Software Development. IEEE Software, 20(5):42–45, 2003. 24. A. Sánchez-Barbudo, E. V. Sánchez, V. Roldán, A. Estévez, and J.L. Roda. Providing an Open Virtual-Machine-based QVT Implementation. In Proceedings of the V Workshop on Model-Driven Software Development. MDA and Applications (DSDM’08 - XIII JISBD), 2008. 25. S. Trujillo, D. Batory, and O. Díaz. Feature Oriented Model Driven Development: A Case Study for Portlets. In 29th International Conference on Software Engineering (ICSE 2007), Minneapolis, MN, USA, May, 2007. 26. D.L. Webber and H. Gomaa. Modeling Variability in Software Product Lines with the Variation Point Model. Science of Computer Programming, 53, 2004. Towards Automatic Code Generation for EAI Solutions using DSL Tools  Hassan A. Sleiman1, Abdul W. Sult´an2, Rafael Z. Frantz3, Rafael Corchuelo1 1Universidad de Sevilla, ETSI Inform´atica Avda. Reina Mercedes, s/n. Sevilla 41012 [email protected], [email protected] 2Sytia Inform´atica S.L. Avda San Sebasti´an, no10, Local 1, Entreplanta. Huelva 21004 [email protected] 3Universidade Regional do Noroeste do Estado do Rio Grande do Sul (Uniju´ı) Departamento de Tecnologia, S˜ao Francisco, 501. Iju´ı 98700-000 RS Brasil [email protected] Abstract. Current companies count on heterogeneous information technology applications to perform their activities. More often than not, they need to be integrated so that the data they manage is kept in sync or to implement new functionality. According to a recent report by IBM, companies spend from $5 to $20 on integration per dollar spent on developing new functionality. This ratio argues for engineering solutions. The Model-Driven Architecture initiative promotes the development of software systems at different levels of abstraction, and Domain Specific Languages (DSLs)play a prominent role to reduce development costs. By means of an appropriate DSL, software engineers can design a software system that can later be deployed to a variety of specific platforms using automatic transformations. Our proposal to reduce integration costs is a DSL called Guaran´a and a software tool to design and automatically deploy integration solutions. Compared to the Enterprise Application Integration UML-profiles, DSLs are more suitable to address problems in a particular domain and are a better approach towards MDA. Key words: Enterprise Application Integration, Domain Specific Language. 1 Introduction We define an integration solution as a piece of software that co-ordinates a number of applications exogenously.An integrationsolution mayfocus on: Enterprise Application Integration (EAI); Business to Business Integration (B2BI); Enterprise Information Integration (EII); Extract, Transform and Load (ETL) and Mashup. Our research focuses on EAI. EAI always happens inside the same company, in its own software ecosystem, and the goal is to keep applications synchronized or to create new functionalities on the top Partially funded by the Spanish National R&D&I Plan under grant TIN2007-64119, and the Andalusian Local Government under grants P07-TIC-02602, and P08-TIC-4100. The work by R.Z. Frantz was also funded by the Evangelischer Entwicklungsdienst e.V. (EED). Actas JISBD 2009, pp.134-145, ISBN: 978-84-692-4211-7 c 2009 Los autores XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 135 of them. Furthermore, when considering Business to Business Integration, the solution necessarily involves applications that belong to different companies, so different software ecosystems must be considered. This type of solution has the same aim of EAI, but otheraspectswhenbuildingthe integrationsolutionmustbe considered,e.g.authentication, external network communication failures, service availability, confidentiality, non repudiationor accountabilitymust be taken into account.In addition, standardslike Open Buying on the Internet (OBI), Electronic Document Interchange (EDI) and Commerce XML (cXML) are usually adopted for the communication amongst companies. Also, it is very important to point here that those pieces of the integration solution deployed inside a software ecosystem (or in case we deploy it as a whole, so the whole solution) will have unlimited access to the application’s layers that are part of the same ecosystem; to communicate with external applications that take part of the integration solution, but belong to other companies’ software ecosystems, it must be done only by means of the exposed public interfaces of those external applications. According to a recent report, for each dollar spent on developing an application, companies usually spend from 5 to 20 dollars to integrate it [11]. This claims for solutions thatcan contributeto reducethis high costof integration.Guaran´ais a domain specific languageto design integrationsolutions that aimsto simplify the designingprocess of solutions andproduces platformindependentmodels which can programmaticallybe transformed into code of a specific technology [6]. In this paper, a realistic integration problem was taken as motivation and validation to generate an application integration solution using Guaran´a’s language and Windows Workflow Foundation(WF) [4] as target deployment technology. In order to meet this goal we have created a software tool prototype that implements domain specific concepts defined in Guaran´a and thus allow the visual design of integration solutions. The platform-independent model designed with this software can be transformed into several integration technologies; however, in this paper, we focus on Windows Workflow Foundation. Actually, [7] describes patterns for EAI but no integration solution language is defined, while Camel and Biztalk provide languages to describe integration solutions. In the case of Camel, this language is textual whereas Biztalk, although it is a graphical language, its not based on MDA. We understand that a DSL is a well focused language developed to address problems in a particular domain providing a set of dedicated abstractions, elementsand notations withformalisation to assist the designerin expressing its solution in the idiom and at the level of abstraction of its DSL. We are aware of the existence of an EAI UML-profile [9] proposed by OMG as an extension for their UML to support some concepts of EAI. While DSL is usually a small and well focused language, UML-profiles intend to wide the scope of UML to cover the modelling of those specific aspects not covered by the native UML elements [1]. This extension has some limitations, such as the impossibility to introduce new modeling concepts that cannot be expressed by extending existing UML elements. These characteristics contributes to make UML-profiles more complex and difficult to use in some domains. This profile also seems to be discontinued. Thetransformationof anintegrationsolution designedusing Guaran´ainto Windows Workflow Foundation(WF) is just one among manyoptions, since there are manyother possible targetintegrationtechnologies like those discussed by authorsin [5]. These au- 136 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos thors also have designed a framework that can be used to compare different integration technologies and they provide a comparison of five technologies in [3]. In [6] authors use 15 properties of this comparison framework to evaluate the Guaran´a’s language against some most common integration technologies’ language. This paper is organised as follows. Section 2, introduces the domain specific language tools concept and briefly highlights important concepts of Guaran´a; Section 3, presents an integration problem from the University of Ijui (UNIJU´ I) used to validate our software tool; Section 4, presents the software tool prototype; Section 5, introduces how the transformation process to Windows Workflow Foundation is carried out; and, finally, in Section 6, we draw our conclusions. 2 Guaran´ a, a DSL for EAI Domain Specific Languages (DSLs) are modelling languages designed to be used in special types of problems. They are restricted to a domain and are characterised by a high-level of abstraction that allows to express the concepts in the language of the problemdomain.Some examplesoftraditionally used DSLs include: SQL (fordatabase access), HTML (to describe the structure and content of a document) and BNF (to describe context-free grammars). The DSLs listed above are textual languages that are specified by describing the language syntax (eg. using BNF), which requires a parser for the language. There are also graphical DSLs based on a set of graphic symbols. Such DSLs have a direct correspondence with the conceptual model. Besides, the description of these languages can be done graphically. Considering the benefits of graphical DSLs, we have relied on this kind of DSL to perform this work. The most important aspects of a graphical DSL are: domain model, notation and code generation. The domain model is a model of concepts described by the language. The basic constructors in graphical DSLs are domain classes and domain relationships. Domain classes represent the concepts of the problem domain whereas domain relationships representrelationships betweenthese concepts.In addition,each domain class and domainrelationship contains a set of properties. An importantaspect of the domain model is the definition of constraints that the model must satisfy. These constraints are used to verifythat the created diagrams are valid. The notation is a set of graphicalsymbols used to represent the domain model. The basic elements are shapes and connectors that are the graphicalrepresentation of the domainclasses and the domain relationships. There is a direct correspondence between domain classes and domain relations and its graphical representation. This graphical notation is used to edit the model. 2.1 Guaran´ a Guaran´a provides a set of domain specific constructors to design integration solutions, which are describedin the language’s metamodel [6], where a part of them are inspired from the patterns at [7]. This language provides a very expressive and needful graphical notation for these constructors, which allow us to visually design an integration solution. Below we introduce the main constructors that can be seen in Fig. 1. XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 137 Building Block: This is one of the most importantconceptsin our language,since it represents a general constructor block where most of an integration solution processing takes place. Although some building blocks receive no entry messages, a typical building block receives an inbound message, executes one or more atomic tasks, and then makes the resulting message available for the next element(s)in the flow. Apart from being composed of tasks, building blocks have ports through which they receive and send messages. Basically, there are two kinds of building blocks: Wrappers and Processes. Wrappers are used to connect an application to an integration solution. Therefore, necessarily, one of its ports are connected with a specific application. Its internal tasks prepares messages to be sent to the application and/or to other processes of the integration solution. On the other hand, processes represent internal blocks where a well-defined set of tasks perform a clear integration service of the solution. A process is connected to other processes or wrappers by means of ports and integration links. Task: Is the element responsible for a building block’s internal processing and allows to turn a process or wrapper into a more complex processing unit. A task reads a message from a slot, processes it and writes the result to the next slot, making it available for the next element inside the block. This message processing usually consists of executing an integration pattern, e.g. enriching, translating, filtering or routing. Slot: They are used inside building blocks to allow exchanging messages between ports and tasks, and also between tasks,ie., they are essentially buffers. Port: These elements abstract away from the method used to communicate building blocks and/or applications. Guaran´a provides four types of ports, divided into two categories: one-way ports and two-way ports. The former are used for internal or external communication whereas the latter are used for external communication with an application. One-way ports are divided into entry port and exit port; two-way ports are divided into solicit-responde port (solicitor port) and request-response port (responder port). An entry port reads information from an application by accessing one or more of its layers. The possible layers we consider here are: data layer, business layer, controller layer and graphical user interface layer. An exit port does the opposite of an entry port, that is, it writes information to an application’s layer. A solicitor port enables the integration solution to solicit information from an application. A responder port provides a request-response interface that an application can use to send requesting messages and receiving responses from the integration solution. Integration Link: Used internally in an integration solution as a mean to transport messages from one building block to another. Because ports represent entry/exit points at a building block, integration links are those elements that actually connect them. 3 Validation example We have validated our proposal by designing and generating code for an integration problem found at UNIJU´ I. The goal was to automate the invoicing of the calls not related to te employee’s work activities. At UNIJU´ I, five applications involved in a handcrafted process to invoice their employees of the private phone calls they make using the University’s phones. Applications run on a different platform and were designed without integrationconcerns in mind. There is a Call Center System (CCS) that records 240 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos debido al gran n´umero de contextos diferentes que existen. Es por esto que se ha implementado un compresor semiest´atico. En una primera pasada sobre el texto se recopila toda la informaci´onsobre los contextos y sus probabilidades, utilizando toda esta informaci´on en una segunda pasada para codificar el texto. 3.1. Estructura del compresor El proceso de compresi´on se divide en dos fases principales: C´ alculo de probabilidades Se realiza una primera pasada sobre el texto, calculando las frecuencias de todas las palabras. Como se trata de un modelo orden-n, las probabilidades estar´an condicionadas por las 0, ..., n palabras precedentes. Compresi´ on En una segunda pasada sobre el texto, se utilizan los contextos y s´ımbolos extra´ıdos para comprimir el texto, utilizando siempre, al codificar un s´ımbolo, el contexto de mayor orden del que se disponga informaci´on. Adem´as, el texto comprimido final debe incluir los contextos, s´ımbolos y frecuencias que se han utilizado, para poder realizar posteriormente la descompresi´on. En una primera fase del desarrollo se decidi´o probar los resultados de compresi´on obtenidos almacenando todos los contextos encontrados, pero no se obtuvieron resultados competitivos. Por lo tanto, se decidi´o aplicar un filtro de contextos tras el c´alculo de los modelos completos, eliminando aquellas cadenas de texto con una baja frecuencia, ya que previsiblemente no se utilizar´an un gran n´umero de veces. As´ı, el coste de almacenarlos en el texto comprimido final puede no ser compensado con el beneficio en la compresi´on que proporcionan. Es necesario determinar una frecuencia l´ımite que marque qu´e elementos se eliminar´an, denominada umbral. Su valor se determinar´aexperimentalmente (ver Secci´on 5). Tras realizar el filtrado, el proceso para comprimir consiste en analizar el contexto de longitud nde la palabra a codificar. Si no se encuentra informaci´on sobre este contexto, se desciende al orden inmediatamente inferior (consultando las n−1palabras anteriores), y se repite el proceso. Si por el contrario se encuentra el contexto pero no se dispone informaci´on sobre el s´ımbolo actual, se emite un s´ımbolo de escape y se desciende del mismo modo al orden inferior para volver a realizar la comprobaci´on con un contexto de la longitud inmediatamente inferior. Por ´ultimo, si el s´ımbolo aparece en este contexto, se utiliza el codificador aritm´etico proporcion´andole la probabilidad de la palabra en su contexto. N´otese que a pesar de tratarse de un compresor semiest´atico, sigue siendo necesaria la emisi´on de s´ımbolos de escape, ya que al haber eliminado los s´ımbolos que aparecen un n´umero reducido de veces en el contexto, puede ser necesario descender de orden, e indicarle al descompresor este hecho. Por tanto, es necesario que el s´ımbolo de escape disponga de una frecuencia asignada en ese contexto. Una vez se ha comprimido el texto, es necesario representar los contextos y sus frecuencias de una forma compacta, ya que es necesario que formen parte del texto comprimido final para permitir la posterior descompresi´on. XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 241 3.2. Estructura del descompresor El procesoderecuperaci´ondel textooriginal apartir deltexto comprimidose realiza de formasim´etrica alproceso decompresi´on.El c´alculo deprobabilidadesse simplifica, puesto que s´olo se han de recuperarlos contextos que el compresor ha producido como salida en la compresi´on. Una vez se dispone de toda esta informaci´on, descomprimir el texto supone b´asicamente realizar un proceso an´alogo al de la compresi´on, descodificando siempre en el contexto de mayor orden posible, y si el s´ımbolo descodificado se trata de un s´ımbolo de escape, descendiendo de orden y repitiendo el mismo proceso. 4. Dise˜ no de estructuras para SWPPM 4.1. Almacenamiento de contextos Toda la informaci´on sobre los modelos de orden 0, ..., n debe ser almacenada en una estructura que permita un r´apido acceso durante la fase de c´alculo de contextos y de compresi´on.En el almacenamientode contextos,se precisa conocer si una secuencia de palabras (contexto y la palabra actual) ya existe en la estructura, para modificar su frecuencia o, en caso contrario, para insertarla con frecuencia 1. Al igual que PPM orientado a caracteres, SWPPM tambi´en utiliza codificaci´on aritm´etica. As´ı, para calcular el subintervalo que le corresponde al s´ımbolo actual y poder codificarlo, se necesita obtener la frecuencia absoluta del contexto,lafrecuencia del elemento en ese contexto ylafrecuencia acumulada inferior a ese s´ımbolo, esto es, de los otros s´ımbolos anteriores en el contexto actual. Para ello, es preciso determinar un ordenpara los s´ımbolos del mismo contexto, y tener acceso a ellos para poder sumar sus frecuencias y as´ı calcular su frecuencia acumulada inferior. Estos tres valores son los que requiere el codificador aritm´etico para procesar el s´ımbolo. Se ha optado por almacenar los contextos en una tabla hash, donde cada elemen- to contiene la informaci´on de una cadena de texto, que est´a formada por un contexto yuns´ımbolo que le sigue, con su frecuencia. Un contexto de kpalabras se almacena recursivamente como una referencia al contexto de k−1palabras y el s´ımbolo correspondiente. El s´ımbolo es una referencia a la palabra en el vocabulario almacenado de forma independiente. Para el c´alculo de la frecuencia inferior es necesario disponer de informaci´on que relacione entre s´ı los elementos que comparten el contexto. Para ello, cada elemento contiene otras dos referencias a otros elementos de la tabla: SiguienteContexto yPrimerDescendiente. De esta forma, se implementa un ´arbol de contextos sobre la tabla hash. La funci´on hash se calcula a partir de las palabras que forman el contexto y la palabra que sigue a dicho contexto. 4.2. Filtro de contextos Se descartan los contextos que no superen un determinado umbral de frecuencia, de forma que no ser´an utilizados para la compresi´on. Al eliminar un contexto, tambi´en se tienen que eliminarlos contextosque desciendande ´el en el ´arbolde contextos.N´otese que esto es consistente, pues si un contexto tiene una frecuencia menor al umbral, necesariamente los contextos que desciendan de ´el ser´an poco frecuentes. 242 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos Un aspecto cr´ıtico en la eliminaci´on de contextos consiste en mantener el ´arbol de contextos correctamente enlazado. El proceso de eliminaci´on de contextos se har´adela siguiente forma: Paso 1: Se asigna el valor0 a la frecuencia de aquellos elementos que no superenel umbral, siempre que no sean de orden 0 (que representa la frecuencia total de cada palabra independientemente de su contexto), ya que se precisa un orden en el que los elementos se puedan codificar con total seguridad (como se ver´a en el proceso de compresi´on). Paso 2: Se restauran los punteros PrimerDescendiente. Si apuntan a una fila cuya frecuencia sea 0, se recorre la lista de ese contexto mediante las referencias de SiguienteContexto hasta que se encuentre una fila cuya frecuencia sea distinta de 0, asignando la referencia de esa fila a PrimerDescendiente. Paso3:Se restauranlos punterosSiguienteContextodelmismo modoqueserealiz´ocon PrimerDescendiente. Para permitir posteriormente un almacenamiento compacto de estas estructuras, resulta conveniente que la lista de elementos que comparten contexto (representada por punteros PrimerDescendiente ySiguienteContexto) est´e ordenada alfab´eticamente seg´un las palabras que representan. Esta operaci´on modifica solamente los valores de los campos PrimerDescendiente,SiguienteContexto y la referencia a la palabra, puesto que tambi´en se reordena el vocabulario. El proceso consta de varias fases: Ordenaci´ on del vocabulario: en esta fase se reordena el vocabulario alfab´eticamente y se proporciona un vector de equivalencias para poder realizar posteriormente la actualizaci´on de las referencias a la palabra. Ordenaci´ on de las listas: una vez ordenadoel vocabulario,el proceso de ordenaci´on de las listas se vuelve sencillo. Para cada elemento, se sigue su lista accediendo a su campo PrimerDescendiente y posteriormente utilizando los enlaces con SiguienteContexto, almacenando los valores de palabra que se vayan procesando. Dado que el vocabulario est´a almacenado ahora alfab´eticamente, ordenar los valores de palabra consiste en ordenar num´ericamente ese vector. Una vez realizada esta ordenaci´on, se recorre de nuevo la lista asignando por orden los valores de palabra encontrados a las referencias SiguienteContexto. Al comenzar a realizar el procesamiento del texto, no se conoce el n´umero de elementos que va a contener la tabla de contextos. Una estrategia simple consiste en crear una tabla que ocupe la mitad de la memoria disponible. Una vez calculados los contextos, y descartados los que aparecen pocas veces, se puede reajustar a un tama˜no apropiado (por ejemplo a dos veces la cantidad de contextos). 4.3. Compresi´ on En este proceso, con toda la informaci´on disponible de la primera pasada sobre el texto, se realiza una segunda pasada en la que se codifica cada s´ımbolo mediante el contexto de mayor orden posible, emitiendo un s´ımbolo de escape si no se dispone informaci´on de los ´ordenes superiores. XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 243 En el procesode codificaci´on se utiliza el contextode mayorlongitud del quese dispongade informaci´on. En el caso de que no aparezca este contextoseguidodel s´ımbolo procesado, se enviar´auns´ımbolo de escape. Esta emisi´on puede ser muy elevada si se eliminan muchos elementos de la tabla de contextos (umbral alto). A la hora de la codificaci´on, el codificador aritm´etico manipula este s´ımbolo del mismo modo que las palabras. La frecuencia asignada al s´ımbolo de escape influye en la frecuencia total del contexto, con lo que asignar una frecuencia ´optima a dicho s´ımbolo repercutir´aenla eficacia del compresor. Paraello, hemosestudiadodosalternativas.La primeraconsiste en asignarals´ımbolo de escape una frecuencia dada como porcentaje de la suma de las frecuencias de los s´ımbolos existentes para ese contexto (porcentaje del intervalo). La segunda opci´on asigna al s´ımbolo de escape la suma de todas las frecuencias de s´ımbolos que hayan sido eliminadosen un determinadocontexto,ya que ´esta ser´a una medidabastante aproximada de las veces que el s´ımbolo de escape se emitir´a(frecuencias eliminadas). Experimentos preliminares muestran que con esta ´ultima aproximaci´on se obtienen unos mejores resultados de compresi´on, y ser´a la que utilicemos en la Secci´on 5. Para calcular la frecuencia acumulada inferior de cada s´ımbolo, es necesario recorrer la lista de s´ımbolos de un contexto, formada por la referencia PrimerDescendiente del contexto y SiguienteContexto de los elementos que lo siguen. Este proceso ralentiza la compresi´on, por lo que se realiz´o una mejora consistente en calcular previamente las frecuencias acumuladas inferiores de los s´ımbolos, as´ı como la de los s´ımbolos de escape. De este modo, recorriendo cada lista una sola vez se almacenan todos los valores necesarios,permitiendoen el procesode compresi´onrealizarla codificaci´onaccediendo directamente al elemento necesario y al elemento de su contexto. 4.4. Compresi´ on de las estructuras auxiliares El compresor y el descompresor precisan disponer del conjunto de elementos que ser´an utilizados para realizar la compresi´on y la descompresi´on. As´ı, partiendo de la tabla de contextos creada, es necesario transformar esa misma informaci´on de una forma que ocupe el menor espacio posible en disco. El proceso consiste en dividir dicha tabla en vectores siguiendo una aproximaci´on diferencial (es decir, se almacena la diferencia con respecto al valor inmediatamente anterior) que da lugar a valores bajos y repetitivos, y a continuaci´on aplica compresi´on Huffman, sobre las diferencias. Para ello, se precisa tener ordenadas alfab´eticamente las listas de elementos que comparten el contexto. Estructura intermedia En primer lugar, se precisa transformar la tabla a una estructura intermedia que facilite la conversi´on a los vectores finales. Dicha estructura contendr´a los elementos (contextosy las palabras que los siguen) ordenados seg´un el orden del contexto y posteriormente por orden alfab´etico. Esta estructura est´a formada por varios campos: ´ Indice: indica en qu´e fila de la estructura original se encuentra el elemento. Contexto: indica en qu´e fila de esta estructura intermedia est´a el contexto del elemento. Para los elementos de orden 0, este elemento apunta al vocabulario. Para los dem´as, este valor hace referencia a un elemento de orden inmediatamente inferior. 244 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos Palabra: indica en qu´e fila de esta estructura est´a la palabra del elemento. En el caso de los elementos de orden 0 este valor es nulo, y en el resto de los casos, hace referencia a un elemento de orden 0. Vectores finales Con el apoyo de esta estructura, se calculan los vectores que posteriormente ser´an comprimidos con Huffman. Tal y como se ha mencionado previamente, se utiliza una aproximaci´on incremental. Se debe calcular: LongitCont: longitud del vector Contextos. TotalSeg: la posici´on iindica el n´umero de elementos en el vector Segundos que hay de orden 0, ..., i −1. Contextos: para cada elemento de la estructura intermedia de orden superior a 0, indica la fila de dicha estructura en la que se encuentra el contexto de ese elemento. Las posiciones son relativas, es decir, si el contexto es de orden n,eln´umero indica el incremento de posici´on desde el primer elemento de orden nque hay en la fila intermedia. Esta estructura s´olo almacena los contextos diferentes. Numveces:n´umero de descendiente del contexto que ocupa esa misma posici´on en Contextos. Segundos: indica las palabras que suceden al contexto definido por Contextos y NumVeces. Para cada contexto, el primer elemento en este vector se corresponde con la posici´on de la palabra en la estructura intermedia en el orden 0. Las siguientes palabras con el mismo contexto se codifican con la aproximaci´on incremental. Esto produce n´umeros relativamente y bajos y con un mayor n´umero de repeticiones, debido a que las cadenas de texto est´an en orden alfab´etico, y la mayor´ıa de los elementos de este vector son la distancia entre elementos pr´oximos de orden 0. Frecuencias: frecuencia de todos los elementos de la estructura. La frecuencia se almacena para los elementos de todos los ´ordenes, incluido el orden 0, por lo que la longitud de este vector es TotalSeq[n+1]. En la Figura 1 se muestra el proceso de compactaci´on de las estructuras auxiliares que posteriormente ser´an comprimidas usando Huffman. ´ IND. CONT. PALAB. A8 0 Ø ORD. 0 B17 2 Ø C7 4 Ø D47 6 Ø AA 5 0 0 ORD. 1 AC 25 0 4 BA 27 2 0 BB 15 2 2 BC 56 2 4 AA B 2 4 2 ORD. 2 AA D 9 4 6 BB A 13 7 0 BB D 21 7 6 BC D 58 8 6 Figura1. Ejemplo de compactaci´on de las estructuras auxiliares En el conjuntode vectores finales de orden 0 s´olo se almacenan las frecuencias. Es- to es posible porque en el orden 0 se almacenan todas las palabras por orden alfab´etico, XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 245 y esta ordenaci´on ya se mantiene en el vocabulario, por lo que no es necesario volcar en disco ninguna informaci´on m´as sobre los elementos de este orden para poder reconstruirlos posteriormente. Tras obtener los vectores finales que han de ser volcados a disco, un ´ultimo paso previo al volcado consiste en comprimir los vectores de mayor longitud (Contextos, NumVeces, Segundos yFrecuencias) aplicando Huffman a cada uno de los vectores independientemente.As´ı, para cada vector se calcula la frecuencia de cada valor, y con ello se crea el ´arbol Huffman correspondiente. Con este ´arbol se codifica el vector y se vuelca a disco, ya comprimido, incluyendo tambi´en el ´arbol de Huffman, necesario para la posterior descompresi´on. 4.5. Descompresi´ on El proceso de descompresi´on se realiza de forma muy similar a la compresi´on. Una vez realizada la recuperaci´on de contextos, se dispone de la tabla de contextos y el c´odigo para descomprimir. El proceso es el siguiente: tras indicarle al contexto la frecuencia total del mismo, el decodificador aritm´etico devuelve un n´umero. El intervalo al que pertenezca dicho n´umero indica el s´ımbolo descodificado, y en caso de que se correspondacon un s´ımbolo de escape, se desciende de nivel, indic´andole la frecuencia del contexto de orden inferior y comprobando de nuevo a qu´e subintervalo pertenece el n´umero devuelto por el descodificador. 5. Resultados experimentales Los experimentos se ejecutaron en una m´aquina Intel R Pentium R -IV@ 3.00 GHz (16Kb L1 + 1024Kb L2 cache), con 4 GB dual-channel DDR-400Mhz RAM, sobre la que corr´ıa Debian GNU/Linux (kernel version 2.4.27). El compilador usado fue gcc version 3.3.5. Las pruebas, que miden el ratio de compresi´on, fueron realizadas sobre un conjunto de textos de la “Text Retrieval Conference”1(TREC); de TREC-2 se han utilizado “AP Newswire 1988”y “Ziff Data 1989-1990”, y de TREC-4 “Congressional Record 1993”,“Financial Times 1991, 1992, 1993y 1994”. A su vez FTALL agrega los corpus provenientesdel Financial Times. Adem´as, se utiliz´oeltextoEnglish50 2, resultado de los primeros 50 MegaBytes del texto English, consistente en una concatenaci´on de textos en ingl´es del proyecto Gutemberg3 En un primer lugar, se analiz´o la influencia del orden m´aximo utilizado en el compresor. La Gr´afica izquierda de la Figura 2 muestra los resultados obtenidos para el texto English50. Se muestra el orden m´aximo frente al ratio de compresi´on. Cada curva representa los ratios obtenidos para un determinado umbral. Se puede observar que en un texto en lenguaje natural el orden m´aximo ´optimo es 2. Los resultados producidos indican que en un texto en lenguaje natural no es muy beneficioso utilizar ´ordenes m´aximos elevados. Esto se debe a que utilizar un orden mayor supone almacenar un 1http://trec.nist.gov/ 2Obtenido de http://pizzachili.dcc.uchile.cl/texts.html 3http://www.gutenberg.org/ebooks/ 246 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 2468 35 40 45 50 55 60 65 Ratio de compresión (%) Orden Umbral 3 Umbral 4 Umbral 5 Umbral 10 Umbral 60 Umbral 200 Umbral 1200 Umbral 10000 0 2000 4000 6000 8000 10000 0 10 20 30 40 50 60 Ratio de compresión Umbral Contextos Código Vocabulario Total Figura2. Ratios de compresi´on para un texto en lenguaje natural con diferentes umbrales y ´ordenes mayor n´umero de contextos y, para que compense el incremento de almacenamiento producido, la informaci´on disponible debe producir una mejora en la compresi´on que implique un c´ odigo mucho m´as reducido. Si las frases de esta nueva longitud m´axima no se repiten mucho, incrementar este orden supone la mayor´ıa de las veces introducir un s´ımbolo de escape y posteriormente codificar en el orden inferior del mismo modo que se hac´ıa previamente, produciendo un c´ odigo peor debido al coste de emisi´on del s´ımbolo de escape. Una vez fijado el orden ´optimo, se procedi´o a analizar la cantidad de contextos que se deb´ıan almacenar (determinado por el umbral). La Gr´afica derecha de la Figura 2 muestra los ratios de compresi´on para los ´ordenes m´aximos probados emp´ıricamente para el texto English50.Lagr´afica indica en el eje xel umbral y, en el eje y, el ratio de compresi´on. En ella se muestran cuatro curvas: tres de ellas representan la contribuci´on al ratio de compresi´on de los contextos, del c´ odigo y del vocabulario, y una cuarta indica la suma de las tres anteriores, y por tanto, el ratio de compresi´on final. Se puede observarc´omo el espacio ocupado por los contextos decrece a medida que aumenta el umbral, debido a que ello implica que se almacenen un menor n´umero de contextos, mientras que el vocabulario permanece constante. El tama˜no del texto comprimido tambi´en desciende a medida que aumenta el umbral. En principio, se puede pensar que deber´ıa aumentar, ya que se dispone de menos informaci´on sobre los contextos y s´ımbolos, pero la forma de codificar los s´ımbolos de escape hace que en los umbrales bajos (en los que se eliminan un menorn´umero de contextos), los s´ımbolos de escape tengan una frecuencia m´as baja asignada, produciendo una peor codificaci´on de estos s´ımbolos que repercute en el texto comprimido final. La suma de las tres curvas se vuelve ´optima en los umbrales superiores, por lo que se puede concluir que los resultados ´optimos se obtienen para un umbral de 10000 o superior con un orden m´aximo de 2, resultando un ratio del 36,61%. Una vez calculados los valores ´optimos para nuestro compresor, comparamos su comportamiento con otros compresores conocidos. Los compresores utilizados en la comparativafueron el ya mencionadoPPMDI, ETDC [2,3], gzip 4y el compresorbzip2 4Puede encontrarse en el sitio Web http://www.gzip.org/ XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 247 5. PPMDI fue probado con orden m´aximo 0 y 9. Por otra parte, el compresor gzip se utiliz´o con las opciones de ejecuci´on m´as r´apida (opci´on 1) y m´as eficiente, pero m´as lenta (opci´on 9), mientras que el compresor bzip2 se prob´o con los tama˜nos de bloques extremos (100k en la opci´on 1 y 900k en la opci´on 9 m´as r´apido o mejor compresi´on respectivamente). La Tabla 1 muestra los resultados obtenidos. En la primera columna se indica el nombre del corpus, mientras que las restantes muestran los ratios de compresi´on obtenidos con los diferentes compresores. Los resultados obtenidos con SWPPM son competitivos, mejorando cualquier ejecuci´on de gzip y de ETDC y con resultados pr´oximos a la ejecuci´on ´optima de bzip2. TEXTO PPMDI BZIP2 GZIP ETDC SWPPM Op. 0 Op. 9 Op. -1 Op. -9 Op. -1 Op. -9 O2,U10000 FT92 29,40% 23,42 % 32,38 % 27,10% 42,59% 36,39 % 32,85 % 29,87 % ZIFF 26,48% 21,77 % 39,66 % 32,98% 39,66% 32,98 % 33,81 % 31,02 % FT93 27,66% 21,68 % 30,62 % 25,32% 40,23% 34,12 % 32,91 % 29,09 % FT94 27,61% 21,68 % 30,53 % 25,27% 40,24% 34,12 % 32,86 % 28,81 % AP 30,34% 23,33% 33,27% 27,25 % 43,66 % 37,23% 32,93% 30,05% FTALL 28,20% 22,24% 31,15% 25,98 % 40,99 % 34,85% 32,56% 28,37% Tabla 1. Comparativa de diferentes compresores para textos semiestructurados 6. Conclusiones En este trabajo hemos presentado un nuevo compresor PPM orientado a palabras (SWPPM), que se diferencia de las otras versiones de la familia PPM, en la utilizaci´on de palabras como s´ımbolos a comprimir en lugar de caracteres. Tras varios dise˜nos preliminares, se cre´o una variante que llamamos SWPPM que s´olo considera los contextos con una frecuencia superior a un umbral dado. El compresor propuesto fue probado experimentalmente obteniendo ratios de compresi´on del 28%-31%.La comparaci´onfrentea otrast´ecnicasexistentespermiti´overqueel SWPPM comprime m´as que t´ecnicas como el gzip (en todas sus variantes) y los compresores semi-est´aticos orientados a palabras m´as utilizados en la actualidad (dense codes). En general, el SWPPM comprime un poco menos que el bzip2, y se ve superado por el PPMDI. Losresultados prometedoresobtenidosdejan la puerta abiertaafuturasoptimizaciones sobre la base del trabajo realizado, como por ejemplo, la mejora de la compresi´on de estructuras auxiliares que permiten mantener un mayor n´umero de contextos durante la compresi´on. Tambi´en estamos trabajando buscando una reducci´on del tama˜no de los contextos en disco, realizando la compresi´on final con otras t´ecnicas (ppm, gzip) en lugar de Huffman. 5Disponible en http://www.bzip.org/ 248 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos Otra l´ınea de investigaci´on consiste en aprovechar la informaci´on que proporciona el hecho de emitir un s´ımbolo de escape para obtener una mejor estimaci´on de las probabilidades usadas al codificar en el orden inferior. Adem´as, el filtro de contextos elimina aquellos elementos con una menor frecuencia porque es probable que se usen menos veces, pero es posible que algunos de los restantes no se utilicen, ya que a los elementos de ´ordenes inferiores s´olo se accede cuando no existe el orden superior. Se propone por tanto realizar una pasada intermedia, previa al proceso de compresi´on, en la que se simula el proceso de codificaci´on marcando el n´umero de veces que se utiliza cada elemento y los s´ımbolos de escape emitidos en cada contexto. As´ı, se ahorrar´ıa el espacio de almacenamiento de los elementos y se ajustar´ıan mejor las frecuencias de los s´ımbolos. Referencias 1. T. C. Bell, I. H. Witten, and J. G. Cleary. Text compression. Prentice Hall, Englewood Cliffs, N.J., 1990. 2. N. R. Brisaboa, A. Fari˜na, G. Navarro, and J. R. Param´a. Lightweight natural language text compression. Information Retrieval, 10(1):1–33, 2007. 3. N. R. Brisaboa, E. L. Iglesias, G. Navarro, and J. R. Param´a. An efficient compression code for text databases. In Proc. 25th European Conf. on IR Ressearch (ECIR’03) - LNCS 2633, pages 468–481, 2003. 4. J. G. Cleary and I. H. Witten. Data compression using adaptive coding and partial string matching. IEEE Transactions on Communications, 32:396–402, 1984. 5. D. A. Huffman. A method for the construction of minimum-redundancy codes. Proceedings of the IRE, 40(9):1098–1101, 1952. 6. A. Moffat. Word-based text compression. Softw. Pract. Exper., 19(2):185–198, 1989. 7. A. Moffat, R. Neal, and I. H. Witten. Arithmetic coding revisited. In Proc. IEEEData Comp. Conf., pages 202–211. IEEE Computer Society Press, 1995. 8. A. Moffat and A.Turpin. Compression and coding algorithms. Kluwer Academic Publishers, Boston, London, 2002. 9. Turpin A. Moffat, A. Fast file search using text compression. In Proc. 20th Australian Computer Science Conference, pages 1–8, 1997. 10. E. Moura, G. Navarro, N. Z., and R. Baeza-Yates. Fast and flexible word searching on compressed text. ACM TOIS, 18(2):113–139, 2000. 11. J. Ziv and A. Lempel. A universal algorithm for sequential data compression. IEEE Transactions on Information Theory, 23(3):337–343, 1977. Reducci´ on del Tama˜ no del ´ Indice en B´ usquedas por Similitud sobre Espacios M´ etricos Luis G. Ares, Nieves R. Brisaboa, Mar´ıa F. Esteller, ´ Oscar Pedreira y ´ Angeles S. Places Laboratorio de Bases de Datos, Facultade de Inform´atica, Universidade da Coru˜na Campus de Elvi˜na s/n, 15071 A Coru˜na {lgares,brisaboa,mfesteller,opedreira,asplaces}@udc.es Resumen En problemas de recuperaci´on de informaci´on se plantea frecuentemente la realizaci´on de b´usquedas por similitud sobre espacios m´etricos. Se utilizan funciones de distancia costosas sobre grandes bases de datos, que requieren un equilibrio entre la cantidad de informaci´on almacenada en el´ındice y eln´umero de evaluaciones de la funci´on de distancia. Las soluciones adoptadas son m´etodos basados en pivotes y m´etodos basados en clustering. Los primeros obtienen menor n´umero de comparaciones, pero presentan necesidades de espacio mucho mayores, por lo que se han propuesto alternativas que pretenden reducir esa cantidad de espacio. En este trabajo analizamos la utilidad de los pivotes en funci´on de su proximidad al objeto, y como consecuencia, proponemos un nuevo m´etodo basado en pivotes que requiere una cantidad de espacio semejante a la que necesitan los m´etodos basados en clustering. Ofrecemos resultados experimentales que demuestran su idoneidad cuando se utiliza la misma cantidad de memoria. 1 Introducci´ on La b´usqueda por similitud es una operaci´on que est´a cada vez m´as presente en un gran n´umero de aplicaciones que realizan el tratamiento de tipos de datos complejos, como es el caso de datos semiestructurados, informaci´on biol´ogica y bases de datos multimedia. La recuperaci´on basada en contendido es un problema habitual en estos escenarios, siendola b´usquedaporsimilitud unade las estrategias m´as adecuadaspara solucionarlo. Un ejemplo de b´usqueda por similitud consiste en obtener la imagen m´as semejante a una dada, pero su aplicaci´on se extiende a una gran variedadde ´areas, como los editores de texto y los grandes buscadores, donde se requiere encontrar palabras que se asemejan a otras para obtener resultados ante criterios de b´usquedas o para efectuar comprobaciones sint´acticas, el reconocimiento de patrones donde se realiza una detecci´on y catalogaci´on de documentos, im´agenes o sonidos que presentan diversas similitudes, y la bioinform´atica donde se necesita reconocer y estudiar secuencias de ADN. El problema de la b´usqueda por similitud puede formalizarse mediante el concepto de espacio m´ etrico que es un par (X,d)formado por un universo de objetos v´alidos X Este trabajo ha sido parcialmente financiado por el Ministerio de Educaci´on y Ciencia (PGE y FEDER, ref. TIN2006-15071-C03-03) y por la Xunta de Galicia (ref. 2006/4) Actas JISBD 2009, pp.249-260, ISBN: 978-84-692-4211-7 c 2009 Los autores 256 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos Efectividad de los pivotes 0% 20% 40% 60% 80% 100% U08 U10 U12 U14 English Nasa Colors No descartados Solo por el más cercano Solo por el más lejano Por ambos Fig.1. Porcentajes de objetos descartados por el pivote m´as cercano, por el m´as lejano y por ambos. Un objeto ser´a descartado por su pivote m´as cercano, cuando la puntuaci´on est´andar de su distancia a ese pivote, es de aproximadamente −2,33. Sin embargo, cuando esa puntuaci´on est´a cercana o es inferior a −1,9y la puntuaci´on est´andar de la distancia al pivote m´as lejano es aproximadamente 5,1, el objeto va a ser descartado ´unicamente por el m´as pivote m´as lejano. En las dos ´ultimas columnas mostramos las puntuaciones est´andar de las distancias a los pivotes m´as cercano y m´as lejano, para los objetos que pueden ser descartados por ambos. Resultacurioso observarque, amedidaquela complejidaddelas coleccionessint´eticas crece, hay pocas posibilidades de descartar el objeto mediante su pivote m´as lejano. Estos resultados son acordes con los obtenidos en la figura 1. Estas puntuaciones nos dan un umbral para cada colecci´on, que nos permite decidir, para cada objeto, si ser´aelpivotem´as cercano o el m´as lejano, el que tenga m´as posibilidades de descartarlo. Como conclusi´on, el pivote m´as cercano es el que tiene mayor capacidad para descartar un objeto, y solo en aquellos casos en los que no est´a suficientemente cerca, vale la pena tratar de utilizar el pivote m´as lejano, si realmente est´a lo suficientemente lejos. Las puntuaciones est´andar de la distancia al pivote m´as cercano y al pivote m´as lejano, pueden darnos para cada colecci´on, una gu´ıa de cuando utilizar el pivote m´as lejano. En caso de duda, porque la distancia de ambos podr´ıa estar por encima o por debajo de estos umbrales, la opci´on m´as fiable es usar el pivote m´as cercano. XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 257 5´ Indice de Espacio M´ ınimo Basado en Pivotes Bas´andose en los resultados de nuestro an´alisis emp´ırico acerca de la eficacia de los pivotes, proponemos construir un ´ındice en el que, para cada objeto almacenamos el identificador del pivote que se va a utilizar y la distancia del objeto a ese pivote. Dicho pivote ser´aelm´as cercano, o el m´as lejano en aquellos casos en los que la distancia del objeto al m´as cercano no es lo suficientemente peque˜na, y a la vez existe un pivote suficientemente lejano. Podr´ıamos ver el ´ındice resultante como si se crease una partici´on de Voronoi sobre el espacio, almacenando para cada objeto, la partici´on a la que pertenece y la distancia al pivote central de la partici´on. Sin embargo, en nuestro caso, para los objetos que no est´an lo suficientemente cerca del centro de su partici´on (porque est´an distantes del resto de elementos de la colecci´ono porqueest´an muy cerca del l´ımite de dos regiones), almacenamos informaci´onsobre su pivote m´as lejano, en lugar de sobre el m´as cercano. 5.1 Almacenamiento de Distancias con Menor Precisi´ on Ya que nuestro objetivo es reducir el espacio del ´ındice, podemos almacenar los identificadores de los pivotes con log2(m)bits, siendo mel n´umero de pivotes, por lo que necesitar´an menos de un byte en la mayor´ıa de los casos. La distancia al pivote puede almacenarse con un n´umero variable de bits, si permitimos perder alguna precisi´on. Para evaluar nuestro m´etodo, nos referiremos a ´el como ´ Indice de Pivote ´ Unico (UPI). La tabla 3 muestra dos configuraciones diferentes del m´etodo. En la primera (“UPI(4bytes)”),los identificadoresdelos pivotesse almacenaronutilizandoeln´umero m´ınimo de bits, y para las distancias se usaron los 4bytes necesarios para precisi´on flotante. En el segundo (“UPI (2bytes)”), para los identificadores de los pivotes se utiliz´o tambi´en el n´umero m´ınimo de bits, pero las distancias se almacenaron utilizando 2bytes, es decir, con la mitad de precisi´on. Para cada opci´on se muestra el espacio utilizado por el ´ındice en MB (“Espac.”) y el n´umero de evaluaciones de la funci´on de distancia (“Eval. d”). Podemos ver en la tabla que cuando las distancias se almacenan con p´erdida de precisi´on, la desventaja en el n´umero de comparaciones es casi inexistente, mientras que el espacio se reduce aproximadamente a la mitad del necesario cuando se usa precisi´on flotante para las distancias. Colec. UPI (4 bytes) UPI (2 bytes) Espac. Eval. dEspac. Eval. d UV08 0,4311 3094,13 0,2594 3095,72 UV10 0,4348 5891,64 0,2631 5893,84 UV12 0,4456 9739,49 0,2740 9741,91 UV14 0,4673 18160,91 0,2957 18164,03 English 0,3083 12373,45 0,1897 12373,45 Nasa 0,1757 1958,34 0,1068 1958,72 Tabla 3. Espacio y evaluaciones de la distancia cuando se utiliza menor precisi´on. 258 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos El n´umero de bits necesarios para almacenar las distancias, depende del rango de valores obtenido por la funci´on de distancia. Por lo tanto, nuestro m´etodo puede ser parametrizado para guardar las distancias con un determinado n´umero de bits, en funci´on de la definici´on de la funci´on de la distancia y de la tolerancia a la p´erdida de precisi´on. Colec. SSS (α´optimo) KVP (k=2) UPI Lista de Clusters Espac. Eval. dEspac. Eval. dEspac. Eval. dEspac. Eval. d UV08 18,1963 141,43 1,3752 8724,62 0,2594 3095,72 0,3643 6139,21 UV10 60,4255 367,14 1,3789 13063,63 0,2631 5893,84 0,3710 11264,98 UV12 85,8317 645,08 1,3897 18955,94 0,2740 9741,91 0,3710 17273,55 UV14 168,5734 1381,64 1,4115 28502,26 0,2957 18164,03 0,3710 28253,04 English 45,0553 354,89 0,9604 18305,43 0,1897 8872,37 0,2651 7885,79 Nasa 7,4438 168,62 0,5547 2676,93 0,1068 1958,72 0,1427 2027,08 Tabla 4. Comparaci´on con otros m´etodos. 5.2 Evaluaci´ on Para comprobar la competitividad del m´etodo propuesto, lo comparamos con los siguientes m´etodos: –SSS con el espacio necesario para su configuraci´on ´optima (“SSS (α´optimo)”). –KVP almacenando para objeto solo la distancia a sus pivotes m´as cercano y m´as lejano (k=2) (“KVP (k=2)”). –Lista de Clusters [15], puesto que se trata de un m´etodo representativo de la efectividad de los m´etodos basados en clustering (“Lista de Clusters”). Aunque SSS realiza un n´umero mucho menor de evaluaciones, lo comparamos con nuestro m´etodo porque constituye una buena base de referencia para el n´umero de evaluaciones de la distancia y para la utilizaci´on de espacio. La tabla 4 muestra los resultados obtenidos. Nuestro m´etodo obtiene mejores resultados que KVP en todas las colecciones utilizando menos espacio para almacenar el ´ındice. Frente a Lista de Clusters, nuestro m´etodo obtiene mejores resultados en t´erminos de evaluaciones de la funci´on de distancia, en todas las colecciones de vectores sint´eticos y en Nasa, usando adem´as menos espacio para el ´ındice. En el caso de English, nuestro m´etodo necesita m´as evaluaciones de la funci´on de distancia, pero requieremenos espacio paraalmacenarel ´ındice. El n´umero deevaluacionesde la funci´on de la distancia es, por supuesto, superior a los obtenidos con SSS, pero la reducci´on del espacio necesario para el ´ındice es muy importante. Por ejemplo, en el caso de UV14, SSS crea un ´ındice de cerca de 168 MB, mientras que nuestro m´etodo solo necesita 0,37 MB para ello. Estos resultados demuestran que nuestro m´etodo es una estrategia competitiva con las propuestas anteriores, cuando se usa la misma cantidad de espacio. XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 259 6 Conclusiones En este trabajo, consideramos el problema de la reducci´on de los requerimientos de espacio en los m´etodos basados en pivotes, para la b´usqueda por similitud en espacios m´etricos. Presentamos un an´alisis emp´ırico de la eficacia de los pivotes para cada objeto de la base de datos, estudiando el efecto de la elecci´on del conjunto inicial de pivotes y la selecci´on de los m´as prometedores para cada objeto. Nuestros resultados muestran tambi´en que podemos almacenar para cada objeto, ´unicamente la distancia a su pivote m´as prometedor, siendo este el m´as cercano o el m´as lejano, y reducir la cantidad de espacio necesaria para el ´ındice, a la que requieren los m´etodos basados en clustering. Bas´andose en los resultados de este an´alisis, proponemos un nuevo m´etodo basado en pivotes que necesita una cantidad de espacio menor o muy cercana a la necesaria para los m´etodos basados en clustering. Nuestro m´etodo combina las estrategias de reducci´on de rango y de ´ambito: almacenamos solo la distancia m´as prometedora para cada objeto, y para ello utilizamos la mitad de la precisi´on. Nuestrosresultadosmuestranque elm´etodosuponeunaestrategiacompetitivafrente a propuestas anteriores, cuando usamos la misma cantidad de espacio. Como trabajo futuro, estamos estudiando la parametrizaci´on del n´umero de bits usados para almacenar la distancia. Referencias 1. Ch´avez, E., Navarro, G., Baeza-Yates, R., Marroqu´ın, J.L.: Searching in metric spaces. ACM Computing Surveys 33(3) (September 2001) 273–321 ACM Press. 2. Vidal, E.: An algorithm for finding nearest neighbors in (approximately) constant average time. Pattern Recognition Letters 4(1986) 145–157 Elsevier. 3. Mic´o, L., Oncina, J., Vidal, R.E.: A new version of the nearest-neighbor approximating and eliminating search (aesa) with linear pre-processing time and memory requirements. Pattern Recognition Letters 15 (1994) 9–17 Elsevier. 4. Baeza-Yates, R., Cunto, W., Manber, U., Wu, S.: Proximity matching using fixed-queries trees. In: Proc. of the 5th Annual Symposium on Combinatorial Pattern Matching (CPM’94), Asilomar, C.A., Springer-Verlag (1994) 198–212 5. Ch´avez, E., Marroqu´ın, J.L., Navarro, G.: Fixed queries array: A fast and economical data structure for proximity searching. Multimedia Tools and Applications 14(2) (2001) 113–135 6. Yianilos, P.: Data structures and algorithms for nearest-neighbor search in general metric spaces. In: Proc. of the fourth annual ACM-SIAM Symposium on Discrete Algorithms (SODA’93), ACM Press (1993) 311–321 7. Bustos, B., Navarro, G., Ch´avez, E.: Pivot selection techniques for proximity searching in metric spaces. Pattern Recognition Letters 24(14) (2003) 2357–2366 Elsevier. 8. Figueroa, K., Fredriksson, K.: Simple space-time trade-offs for aesa. In: Proc. 6th Workshop on Efficient and Experimental Algorithms (WEA2007). LNCS 4525, Springer-Verlag (2007) 229–241 9. Brisaboa, N.R., Fari˜na, A., Pedreira, O., Reyes, N.: Similarity search using sparse pivots for efficient multimedia information retrieval. In: Proc. of the 8th IEEE International Symposium on Multimedia (ISM’06), San Diego, California, USA, IEEE Press (2006) 881–888 260 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 10. Celik, C.: Priority vantage points structures for similarity queries in metric spaces. In: Proc. of EurAsia-ICT 2002: Information and Communication Technology. Volume 2510 of Lecture Notes in Computer Science., Springer (2002) 11. Celik, C.: Effective use of space for pivot-based metric indexing structures. In: Proc. of Int. Workshop on Similarity Search and Applications (SISAP 2008), Canc´un, M´exico, IEEE Press (2008) 402–409 12. Vleugels, J., Veltkamp, R.C.: Efficient image retrieval through vantage objects. Pattern Recognition 35(1) (2002) 69–80 Elsevier. 13. van Leuken, R.H., Veltkamp, R.C., Typke, R.: Selecting vantage objects for similarity indexing. In: Proc. of the 18th International Conference on Pattern Recognition (ICPR 2006), IEEE Press (2006) 453–456 14. SISAP: Metric spaces library (http://sisap.org/metric space library.html) 15. Ch´avez, E., Navarro, G.: A compact space decomposition for effective metric indexing. Pattern Recognition Letters 26(9) (2005) 1363–1376 Reorganizing Compressed Text  Nieves R. Brisaboa1, Antonio Fari˜na1, Susana Ladra1, and Gonzalo Navarro2 1Database Laboratory, University of A Coru˜na, Spain {brisaboa,fari,sladra}@udc.es 2Department of Computer Science, University of Chile, Chile [email protected] Key words: Word-based compression, searching compressed text, compressed indexing. Recent research has demonstrated beyond doubts the benefits of compressing natural languagetexts using word-basedstatistical semistatic compression.Not only it achieves extremely competitive compression rates, but also direct search on the compressed text can be carried out faster than on the original text; indexing based on inverted lists benefits from compression as well. Such compression methods assign a variable-lengthcodeword to each different text word. Some coding methods (Plain Huffman and Restricted Prefix Byte Codes) do not clearly mark codeword boundaries, and hence cannot be accessed at random positions nor searched with the fastest text search algorithms. Other coding methods (Tagged Huffman, End-Tagged Dense Code, or (s, c)-Dense Code) do mark codeword boundaries, achieving a self-synchronization property that enables fast search and random access, in exchange for some loss in compression effectiveness. In this paper, we show that by just performinga simple reorderingof the targetsymbols in the compressed text (more precisely, reorganizing the bytes into a wavelet-tree- like shape) and using little additional space, searching capabilities are greatly improved without a drastic impact in compression and decompression times. With this approach, all the codes achieve synchronism and can be searched fast and accessed at arbitrary points. Moreover, the reordered compressed text becomes an implicitly indexed representation of the text, which can be searched for words in time independent of the text length. Thatis, we achievenot only fast sequential search time, but indexedsearch time, for almost no extra space cost. We experiment with three well-known word-based compression techniques with different characteristics (Plain Huffman, End-Tagged Dense Code and Restricted Prefix Byte Codes), and show the searching capabilities achieved by reordering the compressed representation on several corpora. We show that the reordered versions are not only much more efficient than their classical counterparts, but also more efficient than explicit inverted indexes built on the collection, when using the same amount of space. In Proceedings of the 31st annual international ACM SIGIR conference, pages 139-146, Singapore, July 2008, doi: http://doi.acm.org/10.1145/1390334.1390360 Actas JISBD 2009, pp.261, ISBN: 978-84-692-4211-7 c 2009 Los autores Exploiting Pipeline Interruptions for Efficient Memory Allocation Josep Aguilar-Saborit2, Mohammad Jalali2, Dave Sharpe2, and Victor Munt´es-Mulero1 1DAMA-UPC, Computer Architecture Dept., Universitat Polit`ecnica de Catalunya, Campus Nord UPC, C/Jordi Girona 1-3 08034 Barcelona, (Catalonia, Spain), [email protected] 2IBM Toronto Lab, 8200 Warden Ave. Markham, ON L6G1C7, Canada {jaguilar, mjalali, dsharpe}@ca.ibm.com Key words: Performance, Memory Allocation, Query post-optimization The execution of a query in database management systems (DBMSs) is usually divided into different phases. Depending on the distribution of memory resources among the different internal operations, the execution time of a query can change drastically. This problem arises in very common scenarios for multi-join query processing, posing a serious problem for query optimization. If we just consider the join ordering problem, the search space of possible QEPs to solve a specific query grows exponentially to the number of joins in the query. The complexity of this problem is increased even further when we consider the use of different scan and join implementations,or the exploration of bushy trees instead of left-deep trees. Commercial DBMSs such as DB2 UDB or Oracle fall into static approaches where (i) the DBA sets the start-up parameters that the compilergathers to compute the queryexecutionplan, and(ii) the memoryassigned to all the memory-intensive operations in the QEP is usually distributed equally. The main drawback of this approach is twofold: first, it relies on the expertise of the DBA; second, it is sub-optimal because it does not take into account that different operators in a QEP can have completely different memory needs. As an alternative, research has been carried out in order to statically assign memory via rule-based approaches during compile time, or dynamically readjust the memory available for each operation during the execution of the query. Other approaches try to solve this problem from a cost-basis perspectiveduring the compilation time ofa query. However, they do not consider bushy trees, which are commonly used in commercial systems. In addition, they base their proposals on a theoretical cost function that differs significantlyfrom those inreal systems in terms ofcomplexity,and makes themdifficult to be applied in practice. In our work, we tackle the problem of memory allocation at compile time among the operations in a QEP. Although most of the DBMSs follow a pipelined philosophy in order to execute the queries, a large number of common QEP operations interrupt the data flow by requiring reading at least one of the input data sets completely before startingto returnresults.Themainideaofour workis to exploitthe available memoryof the system by reusing the memory released by these operations. Specifically, we focus on the hybridhash join (HHJ) operationthat, among all joinalgorithms, is characterized Actas JISBD 2009, pp.262-263, ISBN: 978-84-692-4211-7 c 2009 Los autores XIV Jornadas de Ingenier´ıa del Software y Bases de Datos 263 by being memory-intensive and very dependent on the available memory to achieve good performance. We study the coexistence of multiple operations competing for memory during the QEP processing. We propose a method to identify clusters of operations that compete for memory during the execution of a query and that allow for bushy trees. We also propose the Memory Chunk Distribution (MCD) algorithm. MCD is a method to distribute the available memory among the different operations in a cluster in order to achieve a better utilization of the available memory, independently of the complexity of the cost function. Finally, we implement our algorithm in DB2 UDB, and show that our memory allocation techniques improve the query execution performance compared with the current DB2 algorithm and other algorithms presented in the literature, both in terms of I/O and time. Abstract of the paper included in the Proceeding of the 17th ACM conference on Information and knowledge management (CIKM), pp. 639-648, 2008. Parte VIII Sesi´ on 7. L´ ıneas de Producto 272 XIV Jornadas de Ingeniería del Software y Bases de Datos We implemented our FOSD algebra in two Maude modules [7]: Kernel and ClassDiagram. The Kernel module implements the core of the FOSD algebra as explained in Section 2. This module defines 72 operators and 158 equationsin a total of 458 LOC. Its main operator dot leverages Maude’s native support of operator attributes to express the properties of our algebra. The majority of the operators provide support for manipulating objects and their attributes. A distinctive characteristic of this module is that all operators were definedexclusivelyin terms of Maudeling’smetatypes which makes the algebra applicable to any model represented in Maudeling. As mentioned in Section 2, the specific composition semantics of •operator depends on the type of artifact. Because of this reason, we implemented the composition details particular to class diagrams in a separate module ClassDiagram. This module defines 12 operators and 23 equations in a total of 98 LOC. Method composition is an example of specific composition semantics of class diagrams where two methods are composedif they have the same signature. In this case, the moduleeffectivelyoverrides the default composition when two method nodes are reached. Modules can then extend and refine the operators in the Kernel module. This modular implementation can facilitate the development of the basic algebra for other artifact types. On a first stage, we plan to extend our work to state machines and sequence diagrams. Later, we intend to extend the work to other metamodels and more sophisticated algebras such as [3]. 5 Case Study We used the Graph Product Line (GPL) [11] as case study to evaluate our implementation of FOSD basic algebra. The features of this product line are basic graph algorithms and data structures. A GPL program is a combination of different algorithms implemented on different data structures. Thereare implementations of GPL available in several programming languages but there are no UML class diagrams of its features. Our approach was to take an extended Java-based implementation and develop a translator from Java to Maudeling, using ANTLR to parse the source files and Velocity template engine to generate Maudeling code. This version of GPL has 27 features amounting to a total of 684 UML elements. Table 1 shows each GPL feature and its corresponding number of UML objects generated in Maudeling representation. We composed 3 representative examples of GPL programs to help us gauge the performance of our algebra implementation. These compositions were executed on a Windows laptop, running at 1.8 GHz with 4GB RAM. For each example we gather the number of objects in Maudeling representation, the number of rewrites performed, and the composition time in miliseconds averaged over 3 runs. The results are summarized in Table 2. We found that for these examples the composition time does not significantly exceeds a second even for the largest program GPL3. As expected, the number of rewrites increases as more features are composed. Certainly these results only provideus with glimpse of the performance of our approach. So as part of our future work we plan to evaluate larger and more complex examples of class diagrams and other models. XIV Jornadas de Ingeniería del Software y Bases de Datos 273 Feature Name Objs Feature Name Objs Feature Name Objs Base 25 MSTKruskal 10 UndirectedWithEdges 76 BFS 26 MSTPrim 11 UndirectedWithNeighbors 69 Connected 17 Number 13 UnWeighted 1 Cycle 28 OnlyVertices 1 Weighted 25 DFS 24 StronglyConnected 24 WeightedOnlyVertices 23 Directed 1 TestProg 4 WeightedWithEdges 17 DirectedOnlyVertices 56 Transpose 5 WeightedWithNeighbors 33 DirectedWithEdges 69 UnDirected 1 WithEdges 1 DirectedWithNeighbors 60 UndirectedOnlyVertices 63 WithNeighbors 1 Table 1. GPL Features and Number of Elements 6 Related Work GPL 1 GPL 2 GPL 3 Num Features 8 10 12 Num Objects 140 183 241 Composed Objects 124 155 173 Rewrites 74178 138090 206941 Time msec 402 691 1038 Table 2. GPL Examples Statistics There is a significant amount of related literature. Thus we focus on the research that most closely relates to our work and divide them in three categories. Algebras for FOSD. Our previous work has shown the applicability of an algebraic representation to describe model compositionin use case slices, an Aspect- Oriented modeling techniques based on UML diagrams, when used for SPL modeling [12]. Model Composition and Management. Herrmann et al. [13] propose an algebraic approach to describe the semantics of model composition. Their motivation comes from the realization that given the size of modern software projects it is impractical to describe them with single models. Instead, they propose breaking the system into a set of models that offer complementary views which can be subsequently composed. Our work has a similar motivation, breaking a model that describes all posible members of a product line into features that can be later composed. Model management tools such as MOMENT [8] provide support for generic management operations and also rely on Maude. Models and Software Product Lines. Work that couples FOSD and MDD into a framework called Feature-Oriented Model Driven Development (FOMDD) [4] has shown how to synthesize SPL products with MDD by first composing models that implement features which are subsequently transformed into executables. This work emphasizes the need for adequate support for algebraic model composition. 7 Conclusions and Future Work The driving motivation of this work was to perform a preliminary assessment of the feasibility of using equational logic to implement FOSD concepts. Maude attracted our 274 XIV Jornadas de Ingeniería del Software y Bases de Datos attention for its native support of operator properties and its growing use for model management. Maude’s equational logic appealed as a natural mechanism to realize the basic FOSD algebra and thus attempt to bridgethe conceptual gap between FOSD concepts and their implementation.We found that the implementationof the kernelmodule required a significant design effort that later paid off as it facilitated the developmentof the class diagram module. Performance was not an issue for the case study used to evaluate our implementation. However, this aspect needs further assessment with larger and more complex product lines. This assessment is part of our future work. Extensibility is another crucial issue to address. Work is underway to extend the algebra for state machines and sequence diagrams. We also plan to broaden our scope outside UML diagrams. We intend to study how our experienceimplementingthe basic algebra couldbe leveragedfor the development of other feature algebras. Our ultimate goal is to provide a platform in which FOSD concepts could be easily evaluated and experimented with. Acknowledgments. We thank Sven Apel for the Java version of GPL case study. References 1. Batory, D., Sarvela, J.N.,Rauschmayer, A.: Scaling Step-Wise Refinement. IEEE TSE30(6) (2004) 2. Pohl, K., Bockle, G., van der Linden, F.J.: Software Product Line Engineering: Foundations, Principles and Techniques. Springer (2005) 3. Apel, S., Lengauer, C., Möller, B., Kästner, C.: An algebra for features and feature composition. In: AMAST. (2008) 4. Trujillo, S., Batory, D., Diaz, O.: Feature Oriented Model Driven Development: A Case Study for Portlets. In: ICSE. (2007) 5. Batory, D.S.: Using modern mathematics as an fosd modeling language. In Smaragdakis, Y., Siek, J.G., eds.: GPCE, ACM (2008) 35–44 6. Rivera, J.E.,Vallecillo, A.,Durán, F.: Maudeling: Herramienta de gestión de modelos usando maude. In: JISBD. (2007) 7. Clavel, M., Durán, F., Eker, S., Lincoln, P., Martí-Oliet, N., Meseguer, J., Talcott, C.L.: All About Maude - A High-Performance Logical Framework, How to Specify, Program and Verify Systems in Rewriting Logic. Springer (2007) 8. Boronat, A., Carsí, J.A., Ramos, I., Letelier, P.: Formal model merging applied to class diagram integration. Electr. Notes Theor. Comput. Sci. 166 (2007) 9. Romero, J., Rivera, J., Duran, F., Vallecillo, A.: Formal and Tool Support for Model Driven Engineering with Maude. Journal of Object Technology 6(9) (2007) 10. Rivera, J.E., Vallecillo, A.: Representing and operating with model differences. In Paige, R.F., Meyer, B., eds.: TOOLS (46). Volume 11 of Lecture Notes in Business Information Processing., Springer (2008) 141–160 11. Lopez-Herrejon, R.E., Batory, D.S.: A standard problem for evaluating product-line methodologies. In Bosch, J., ed.: GCSE. Volume 2186 of Lecture Notes in Computer Science., Springer (2001) 10–24 12. Lopez-Herrejon, R., Batory, D.: Modeling Features in Aspect-Based Product Lines with Use Case Slices: An Exploratory Case Study. In: Workshops and Symposia at MoDELS. (2006) 13. Herrmann, C., Krahn, H., Rumpe, B., Schindler, M., Volkel, S.: An Algebraic View on the Semantics of Model Composition. In: ECMDA-FA. (2007) Actas JISBD 2009, pp.275-280, ISBN: 978-84-692-4211-7 ©2009 Los autores Revisión Sistemática de Métricas de Calidad para Líneas de Productos Software Sonia Montagud, Silvia Abrahão Grupo de Investigación ISSI, Departamento de Sistemas Informáticos y Computación, Universidad Politécnica de Valencia, Camino de Vera, s/n, 46022, Valencia, España {smontagud, sabrahao}@dsic.upv.es Abstract. En los últimos años se ha propuesto una cantidad considerable de métricas para evaluar características de calidad de líneas de productos software (LPS). Sin embargo, no existe ningún estudio que sintetice el conocimiento actual sobre ellas. Este artículo presenta una revisión sistemática sobre métricas de calidad para líneas de productos software propuestas por investigadores desde el año 1996. Las métricas han sido clasificadas teniendo en cuenta los procesos del ciclo de vida de las líneas de producto software y las características de calidad propuestas en la ISO/IEC SQuaRE. Se han obtenido un total de 104 métricas. Los resultados de la revisión indican que el 61% de las métricas miden atributos relacionados con la mantenibilidad. Además, el 68% de las métricas se utilizan durante la fase de diseño en la ingeniería del dominio y un 54% se aplican sobre la arquitectura de la línea de productos. Sin embargo, sólo un 1% de ellas han sido validadas empíricamente. Estos resultados son particularmente relevantes para la definición de un modelo de calidad para LPS. Keywords: calidad, métricas, líneas de productos software, revisión sistemática 1 Introducción La calidad es un factor crucial en la Ingeniería del Software. Si bien es importante para la construcción de productos individuales, cobra mayor relevancia en la ingeniería de Líneas de Productos Software (LPS), donde se pretende garantizar la calidad de todos los productos de una familia. Para la evaluación de la calidad, las métricas software son un buen medio para entender, monitorizar, controlar, predecir y probar el desarrollo de software y los proyectos de mantenimiento [6]. En los últimos años han aparecido numerosas métricas para evaluar la calidad en LPS. En [10] se comenta el uso de algunas métricas como un método para evaluar la calidad de las arquitecturas de líneas de productos, pero no las analizan en profundidad. Para averiguar si existe algún estudio que recoja y analice todas las métricas existentes para la evaluación de calidad en LPS, hemos realizado diferentes búsquedas en las bibliotecas digitales IEEEXplore, ACM Digital Library e INSPEC, no obteniendo ningún resultado. Con el propósito de conocer dicha información, este trabajo presenta una revisión sistemática de la literatura que recopila y analiza las métricas existentes para la evaluación de la calidad en LPS. Las revisiones 276 XIV Jornadas de Ingeniería del Software y Bases de Datos sistemáticas son útiles para identificar, evaluar, e interpretar una pregunta de investigación, un área de estudio, o un fenómeno de interés de forma objetiva [13]. Con respecto a otras revisiones sistemáticas relacionadas con este tema, en [14] hemos presentado una revisión sistemática donde se analizan todos los métodos y técnicas existentes para la evaluación de calidad en LPS, pero no se centra específicamente en la búsqueda y clasificación de métricas para LPS. En lo referente al método de investigación, en la literatura podemos encontrar otros trabajos en los que se realiza una revisión de la literatura para descubrir y analizar las métricas existentes en otras áreas de la ingeniería del software ([7], [9]). Así, parece razonable el uso de una revisión sistemática como método de investigación. La organización del artículo es la siguiente. En la Sección 2 se explica el protocolo de la revisión. La Sección 3 presenta los resultados obtenidos. La Sección 4 discute las posibles amenazas que puedan afectar a los resultados. Finalmente, en la Sección 5 se comentan las conclusiones y los trabajos futuros. 2 Método de Investigación Una revisión sistemática es un método de investigación con el que obtener, evaluar e interpretar de forma fiable, rigurosa y metodológica toda la información que está relacionada con una pregunta de investigación o un área de interés particular. En este estudio, hemos seguido el método propuesto por Kitchenham [13], que consta de tres actividades principales: planificación, revisión y presentación de resultados. 2.1 Planificación de la revisión 2.1.1. Formulación de la pregunta de investigación: El objetivo de esta revisión es obtener y analizar las métricas que han sido utilizadas por los investigadores para evaluar la calidad de líneas de productos software y cómo han sido utilizadas. 2.1.2. Selección de Fuentes: Se ha intentado recoger las bibliotecas digitales de las organizaciones y editoriales más relevantes en Ingeniería del Software. La selección es la siguiente: IEEEXplore, ACM Digital Library, Science Direct e INSPEC. Además, se ha considerado las siguientes actas de congresos relacionados a: (i) líneas de productos software (SPLC, PFE y IWSAPF); (ii) calidad del software (ESEM, ISESE y METRICS); y (iii) ingeniería del software (ICSE y ECSA). Además, hemos añadido literatura gris con el fin de ampliar las fuentes del estudio. El período de búsqueda comprende desde el año 1996 (año en el que se celebró el primer congreso dedicado específicamente a LPS) hasta principios del año 2009. Tras refinar la cadena de búsqueda para optimizar los resultados, ésta fue: (metric* OR measur*) AND (software) AND ("product line*" OR "product famil*"). La búsqueda se llevó a cabo utilizando el título y el resumen de los artículos. 2.1.3. Definición de criterios de Inclusión y Exclusión: Se ha incluido en la revisión artículos que presenten métricas para evaluar la calidad en LPS. Se han excluido los artículos que no estaban escritos en inglés, que no proponían métricas XIV Jornadas de Ingeniería del Software y Bases de Datos 277 directamente relacionadas con la calidad, que proponían métricas pero que no explicaban cómo medirlas o que definían atributos pero no sus métricas. 2.1.4. Estrategia de Extracción de Información: Una vez identificados y obtenidos los estudios primarios, la siguiente fase consistió en su revisión y en la extracción de la siguiente información: 1. Característica de calidad evaluada. Cada métrica se ha clasificado en función de la característica de calidad que pretende medir, según el modelo de calidad del estándar ISO/IEC SQuaRE [11]: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad. 2. Fase del ciclo de vida en el cual se aplica la métrica. De acuerdo a [17], las fases son: Ingeniería del Dominio: (1) Requisitos, (2) Diseño, (3) Realización, (4) Pruebas; Ingeniería de la Aplicación: (5) Requisitos, (6) Diseño, (7) Realización, (8) Pruebas. Finalmente, incluimos la fase: (9) Evolución, sugerida por Bosch [5]. 3. Artefacto sobre el cual se realiza la evaluación. Clasificamos las métricas, en función del artefacto evaluado, de la siguiente forma: (1) Arquitectura Base, (2) Activos, (3) Arquitectura del Producto, (4) Producto final. 4. Procedimiento de validación de la métrica. Existen dos tipos: Validación teórica o Validación empírica. Si carece de validación, se clasifica como No validada. 5. Soporte para la medición. Manual o Automática. 2.2 Conducción de la revisión La búsqueda en las bibliotecas digitales se realizó el 10/03/2009 e identificó 442 potenciales publicaciones. Los criterios de inclusión y exclusión seleccionaron 16 artículos: 4 procedentes de la búsqueda manual, 9 de la búsqueda automática y 3 considerados literatura gris. Las publicaciones que aparecieron en más de una fuente se consideraron una vez con el siguiente orden de prioridad: (1) Actas de Congresos, (2) IEEEXplore, (3) ACM, (4) Science Direct e (5) Inspec. La Figura 1 lista los artículos seleccionados. 1. Abdelmoez, W. et al.: Error Propagation In Software Architectures. METRICS, 2004. 2. Ajila, S. A., Dumitrescu, R. T.: Experimental use of code delta, code churn, and rate of change to understand software product line evolution. JSS, 2007. 3. Alves de Oliveira Junior, E. et al.: A Metric Suite to Support Software Product Line Architecture Evaluation. CLEI, 2008. 4. Aldekoa, G. et al.: Quantifying Maintainability in Feature Oriented Product Lines. CSMR, 2008. 5. Dincel, E. et al.: Measuring Product Line Architectures. PFE, 2001. 6. Ganesan, D. et al.: Comparing Costs and Benefits of Different Test Strategies for a Software Product Line: A Study from Testo AG. SPLC, 2007. 7. Inoki, M., Fukazawa, Y.: Software Product Line Evolution Method Based on Kaizen Approach. SAC, 2007. 8. Johansson, E., Höst, R.: Tracking Degradation in Software Product Lines through Measurement of Design Rule Violations. SEKE, 2002. 9. Mišić, V. B.: Measuring the Coherence of Software Product Line Architectures. TR 06/03. Univer. of Manitova, Canada, 2006. 10. Needham, D., Jones, S.: A Software Fault Tree Metric. ICSM, 2006. 11. Rahman, A.: Metrics for the Structural Assessment of Product Line Architecture. Master Tesis on Software Engineering, Thesis no. MSE-2004:24. School of Engineering, Blekinge Institute of Technology, Sweden, 2004. 12. Siegmund, N. et al.: Measuring Non-functional Properties in Software Product Lines for Product Derivation. APSEC, 2008. 13. Van der Hoek, A. et al.: Using Services Utilization Metrics to Assess the Structure of Prod. Line Arch. METRICS, 2003. 14. Sun Her, J. et al.: A framework for evaluationg reusability of core asset in product line engineering. IST, 2007. 15. Yoshimura, K. et al.: Assessing Merge Potencial of Existing Engine Control Systems into a Product Line. SEAS, 2006. 16. Zhang, T. et al.: Some Metrics for Accesing Quality of Product Line Architecture. CSSE, 2008. Figura 1. Artículos seleccionados. 278 XIV Jornadas de Ingeniería del Software y Bases de Datos 3 Resultados La revisión sistemática ha localizado 104 métricas que han sido clasificadas siguiendo los criterios descritos en la sección 3.1.4. Seguidamente, se presenta un análisis de los resultados para cada criterio: 1. Característica de calidad evaluada: Los resultados han mostrado que la mayoría de las métricas extraídas de los artículos pretenden medir atributos relacionados con la Mantenibilidad (ver Figura 2(a)). Por ejemplo, Aldekoa et al. [4] proponen una métrica para calcular el Índice de Mantenibilidad de una línea de productos; Alves de Oliveira et al. [3] proponen un conjunto de métricas para calcular la complejidad de la arquitectura de la línea de productos, obtenidas a partir de la herramienta SDMetrics; Ganesan et al. [8] proponen un conjunto de métricas para calcular el coste de la realización de pruebas en los componentes. Con relación a la eficiencia, la segunda característica con más métricas, se encuentran, entre otras, las métricas propuestas por Van der Hoek et al. [15] (la opcionalidad y la variabilidad) que calculan ratios de utilización de servicios provistos y requeridos y evalúan la arquitectura de una línea de productos, basándose en dos características específicas de las mismas. Sun Her et al. [16] evalúan la reusabilidad de los activos. En general, la mayoría de las métricas están relacionadas con la reusabilidad de componentes y la variabilidad. Figura 2. Resultados del criterio 1 (gráfica a) y criterio 3 (gráfica b). 2. Fase del Ciclo de Vida en el que se aplica la Métrica. Una gran cantidad de métricas (75) se aplican en la fase del diseño de la Ingeniería del Dominio. Esto es debido a que muchas de ellas están enfocadas a características concretas de las líneas de productos tales como la reusabilidad o la variabilidad, aspectos que se tienen muy presente en esta fase del ciclo de vida. La segunda fase más evaluada es la Evolución (14). Por ejemplo, Ajila et al. [2] identifican un conjunto de métricas (Tamaño de código en la línea de productos, Número de módulos, Código modificado, etc.) que pueden ser utilizadas para registrar los cambios en la línea de productos, con las cuales podrá observarse su evolución. 3. Artefacto sobre el cual se realiza la Evaluación. Como se puede observar en la Figura 2 (b), la mayoría de las métricas miden artefactos obtenidos en etapas tempranas del proceso de desarrollo de una línea de productos: el 54% de las métricas se aplican sobre la arquitectura de la línea de productos mientras que un 27% se aplican sobre los activos. En algunos casos, se utiliza más de un artefacto para realizar la medición. Por ejemplo, Johansson y Höst [12] hacen uso del código fuente, archivos y otros artefactos para comprobar las violaciones del diseño en el producto. XIV Jornadas de Ingeniería del Software y Bases de Datos 279 4. Procedimiento de Validación de la Métrica. Los resultados han mostrado que el 87% de las métricas carecen de cualquier tipo de validación. Sólo un 12% de ellas han sido validadas teóricamente. Éstas son las métricas propuestas por Sun Her et al. [16], las cuales han sido, por una parte, analizadas teóricamente mediante la aproximación propuesta por Kitchenham et al. [13], y por otra, aseguradas mediante seis criterios derivados del estándar IEEE Std 1061. Únicamente la métrica “Error propagation” propuesta por Abdelmoez et al. [1] ha sido validada empíricamente. La validación ha consistido en un estudio comparativo entre los resultados analíticos y los conseguidos experimentalmente. Sin embargo, ninguna métrica propuesta ha validado empíricamente la relación existente entre los valores obtenidos por la métrica y una característica de calidad externa. 5. Soporte para la Evaluación. El 80% de las métricas no disponen de una herramienta que de soporte a su medición. Como ejemplos de herramientas para la evaluación del restante 20% de las métricas, se encuentran la combinación de la herramienta Crystal Ball con la simulación Monte-Carlo para analizar los resultados de las métricas propuestas por [8] en un documento Excel; o Zhang et al. [18] que definen sus métricas sobre una especificación formal de la arquitectura de línea de productos con la especificación vADL, la cual permite hacer un análisis automático. 4 Amenazas a la Validez Las posibles limitaciones de este estudio están relacionadas con el sesgo en la selección de publicaciones, el posible uso de una cadena de búsqueda incompleta y la inexactitud en la extracción de datos o errores en la clasificación. Esperamos haber disminuido la primera amenaza a través de la exploración manual de actas de congresos y estudios considerados literatura gris. Al seleccionar las publicaciones, tratamos de elegir las fuentes en las que suelen publicarse artículos relacionados con métricas y LPS. Con respecto a la segunda, procuramos recoger las cadenas que son representativas de la pregunta de investigación, refinamos la búsqueda varias veces, consideramos sinónimos e incluimos los lexemas de las palabras. Finalmente, intentamos suavizar la tercera amenaza realizando la clasificación con dos revisores. 5 Conclusiones y Trabajo Futuro Se ha presentado una revisión sistemática de la literatura con el propósito de localizar y obtener información relevante sobre las métricas utilizadas por los investigadores en los últimos años para la evaluación de la calidad en líneas de productos software. Los resultados son interesantes para conocer el estado actual de las métricas que pueden ser utilizadas por los investigadores o profesionales de la industria para evaluar la calidad en LPS (la mayoría evalúan la mantenibilidad (61%) y la eficiencia (24%)), o en qué fases son comúnmente utilizadas (el 68% en la fase de diseño de la Ing. del Dominio). Además, el estudio permite detectar carencias para direccionar los esfuerzos de investigación. Así, sería de interés: definir métricas que evalúen otras 280 XIV Jornadas de Ingeniería del Software y Bases de Datos características de calidad; validar las métricas existentes con estudios empíricos, definir métricas que evalúen la composicionalidad (combinación de la arquitectura con otros activos) para permitir decidir que diseño es mejor; cubrir la evaluación en todo el ciclo de vida; o desarrollar herramientas que faciliten la medición. Como trabajo futuro, estamos trabajando en la definición de un modelo de calidad para LPS a partir de la descomposición del modelo de calidad propuesto en el estándar SQuaRE [11]. En él integraremos las métricas obtenidas en el presente trabajo y añadiremos las necesarias para completar el modelo. Referencias 1. Abdelmoez, W., Nassar, D.M., Shereschevsky, M., Gradetsky, N., Gunnalan, R., Ammar, H.H., Yu, B., Mili, A.: Error Propagation in Software Architectures. In 10th International Symposium on Software Metrics (METRICS), Chicago, Illinois, USA, 2004. 2. Ajila, S. A., Dumitrescu, R. T.: Experimental use of code delta, code churn, and rate of change to understand software product line evolution. JSS, 80, pp.74-91, 2007. 3. Alves de Oliveira Junior, E., Gimenes, I. M. S., Maldonado, J. C.: A Metric Suite to Support Software Product Line Architecture Evaluation. In XXXIV Conferencia Latinamericana de Informática (CLEI), Santa Fé, Argentina, pp.489-498, 2008. 4. Aldekoa, G., Trujillo, S., Sagardui, G., Díaz, O.: Quantifying Maintainability in Feature Oriented Product Lines. In Eur. Conf. on SW Maintenance and Reengineering, 2008. 5. Bosch, J.: Design and use of software architectures: adopting and evolving a product line approach”. ACM Press/Addison-Wesley Publishing Co., USA, 2000. 6. Briand, L.C., Differing, C.M., Rombach, D.: Practical Guidelines for Measurement-Based Process Improvement. Software Process-Improvement and Practice 2, pp.253-280, 1996. 7. Calero, C., Ruiz, J., Piattini, M.: Classifying web metrics using the Web Quality Model. Online Information Review, OIR - 29, 3 Emerald Literari. United Kingdom. 8. Ganesan, D., Knodel, J., Kolb, R., Haury, U., Meier, G.: Comparing Costs and Benefits of Different Test Strategies for a Software Product Line: A Study from Testo AG. In 11th International Software Product Line Conference, Kyoto, Japan, pp.74-83, September 2007. 9. Gómez, O., Oktaba, H., Piattini, M., García, F.: A Systematic Review Measurement in Software Engineering: State-of-the-Art in Measures. In First International Conference on Software and Data Technologies (ICSOFT), Setúbal, Portugal, pp.11-14. September, 2006. 10. Etxeberria, L., Sagarui, G., Belategi, L.: Quality aware software product line engineering. Journal of the Brazilian Computer Society, vol.14, no.1, Campinas Mar, 2008. 11. ISO/IEC 25000:2005. SW Eng. SW product Quality Requirements and Eval. (SQuaRE). 12. Johansson, E., Höst, R.: Tracking Degradation in Software Product Lines through Measurement of Design Rule Violations. Conf. SW Eng. and Knowledge Eng., Italy, 2002. 13. Kitchenham, B.: Guidelines for Performing Systematic Literature Reviews in Software Engineering. Version 2.3, EBSE Technical Report, Keele University, UK. 14. Montagud S., Abrahão, S.: Gathering Current Knowledge about Quality Evaluation in Software Product Lines. In International Software Product Lines Conferences, USA, 2009. 15. Van der Hoek, A., Dincel, E., Medidović, N.: Using Services Utilization Metrics to Assess the Structure of Product Line Architectures. In 9th Int. Software Metrics Symposium, 2003. 16. Sun Her, J., Hyeok Kim, J., Hun Oh, S., Yul Rhew, S., Dong Kim, S.: A framework for evaluationg reusability of core asset in product line engineering. IST 49, pp. 740-760, 2007. 17. Van der Linden, F., Schmid, K., Rommes, E.: Software Product Lines in Action. 2007. 18. Zhang, T., Deng, L., Wu, J., Zhou, Q., Ma, C.: Some Metrics for Accesing Quality of Product Line Architecture. Int. Conf. Computer Science and Software Engineering, 2008. Actas JISBD 2009, pp.281-284, ISBN: 978-84-692-4211-7 ©2009 Los autores FMT: Una Herramienta de Modelado y Configuración de Líneas de Productos Software para MS Visual Studio* Rubén Fernández, Miguel A. Laguna, Jesús Requejo, Nuria Serrano Departamento de Informática, Universidad de Valladolid. {luifern, mlaguna}@infor.uva.es, {jesus.requejo, nuriaserrano}@gmail.com Resumen. Los modelos de características son instrumentos básicos para modelar, analizar y configurar la variabilidad de una línea de productos software. Todas estas tareas son complejas por lo que es necesario disponer de herramientas que satisfagan una serie de requisitos mínimos: generación automática de modelos, configuración de productos finales, integración en el entorno de desarrollo, etc. Por esa razón, hemos desarrollado una herramienta para realizar estas tareas, definiendo un lenguaje específico de dominio e implementando el mismo mediante las herramientas proporcionadas por Microsoft para Visual Studio. De esta forma hemos logrado integrar la herramienta en la misma plataforma utilizada para desarrollar la línea de productos, con lo que todas las fases de desarrollo comparten el mismo entorno. 1 Introducción Uno de los problemas en el desarrollo de una línea de productos software (LPS) es la representación y gestión de la parte común y variable de la misma. La forma habitual de definir ambos aspectos es mediante modelos de características o features que permiten seleccionar la configuración de cada aplicación concreta dentro de la LPS. En la mayoría de LPS esas tareas son demasiado complejas para realizarlas manualmente. Por otro lado, en [3] hemos mostrado cómo se puede generar automáticamente la arquitectura básica de una línea de productos mediante transformaciones de los diagramas de características. La configuración de paquetes se basa en el mecanismo de package merge de UML 2 [4] y su implementación mediante clases parciales de C#. Hasta el momento para realizar todas estas tareas el grupo GIRO ha utilizado una combinación de herramientas: el Feature Model Plug-in para Eclipse de Czarnecki [1], y MS Visual Studio. La conexión entre ellas se realiza de manera manual utilizando ficheros XML y transformaciones con hojas de estilo XSLT. Los modelos de características se pueden convertir en la estructura de paquetes de una línea de productos, obtenida como un fichero XMI, que se puede importar con una herramienta CASE [3]. Actualmente existen diferentes herramientas libres que permiten la gestión de líneas de productos, como por ejemplo el mencionado plug-in fmp o Moskitt1. Todas ellas permiten la definición de modelos de * trabajo financiado por la Junta de Castilla y León (VA018A07) y el MICIINN (TIN2008-05675) 1 http://www.moskitt.org/eng/ 288 XIV Jornadas de Ingenier´ıa del Software y Bases de Datos FAMA FW is a SPL itself, as it allows the customer to decide which extensions to incorporatein a final distribution ofFAMA FW and even extendit in the future, needing no kind of adaptation. Among its extensions we find: –Reasoners: CSP (JaCoP and Choco), SAT (SAT4j) and BDD (JavaBDD). –Metamodels: FAMA Metamodel,Moskitt FM Metamodel.Stores and retrieves feature models in XML and X3D formats. –Questions: number of products, list of products, error detection, error explanation, valid configurations, filtering, etc. –Reasoner Selector: different criteria to select the reasoner with a best performance in answering a specific question. With the bearingpoint ofa furtherOSGi integration,FAMA FW was built following an OSGi-inspired architecture where every extension is an auto-contained Java Jar file and dependencies among them are contained in a configuration file. 3 MFM and FAMA FW Integration FeAture Model Analyser (FAMA) was presented in a previous edition of JISBD as a powerful tool for the AAFM but its Eclipse user interface was coupled to a metamodel that hindered a natural edition. Due to the experience Moskitt gave in developing Eclipse plugins, the UPV team offered to develop an intuitive feature model editor that could integrate with FAMA. USE team would invest their efforts in refactoring FAMA to produce a flexible AAFM platform in first term, and an OSGi-compliant platform in second term. FAMA FW is the result of such refactoring and was presented in last year edition of JISBD. This year we present the final result of both tools integration as a result of a new OSGi-compliant version of FAMA FW and the release of Moskitt Feature Modeler. References 1. D. Benavides, A. Ruiz-Cort´es, and P. Trinidad. Automated reasoning on feature models. LNCS, Advanced Information Systems Engineering: 17th International Conference, CAiSE 2005, 3520:491–503, 2005. 2. D. Benavides, A. Ruiz-Cort´es, P. Trinidad, and S. Segura. A survey on the automated analyses of feture models. In Jornadas de Ingeniera del Software y Bases de Datos (JISBD), 2006. 3. P. Trinidad, D. Benavides, A. Dur´an, A. Ruiz-Cort´es, and M. Toro. Automated error analysis for the agilization of feature modeling. Journal of Systems and Software, 81(6):883–896, 2008. 4. P. Trinidad, D. Benavides, A. Ruiz-Cort´es, S. Segura, and A.Jimenez. Fama framework. In 12th Software Product Lines Conference (SPLC), 2008. [Document text truncated for crawler view.]