Supporting Meta-Description Activities in Experimental Software Engineering Environments Wladmir A. Chapetta, Paulo Sérgio M. dos Santos and Guilherme H. Travassos COPPE / UFRJ Systems Engineering e Computer Science Department Caixa Postal 68.511, CEP 21945-970, Rio de Janeiro Brazil {wladmir, pasemes, ght}@cos.ufrj.br Abstract. This paper describes our experience on building tools that support meta-descriptions activities in experimental software engineering environments. It aims at discuss how these tools have been used to help on the building of experimental software engineering environments. The experimental software engineering group at COPPE/UFRJ has been working with the development of an integrated environment to support experimentation in software engineering. This environment, called esee, is composed of three main software tools set regarding meta-descriptions activities (describing all the definitions and models to be used to configure meta experimentation environments), configuration and instantiation environments activities (concerned with the building of configured environments that can be used to instantiated specific experimentation environments) and workflow based activities (where tools to support the enactment of instantiated experimentation process can be found). Keywords. CASE, Experimental Software Engineering, expermentation process tools. 1. Introduction One of the Software Engineering goals is to provide ways to improve the development of software systems. To achieve it, methods and tools have been developed by the software engineers to support the software development and maintenance activities. Nevertheless, it is not found the application of investigative methods to understand what makes software good or how to make software well (PFLEEGER, 1999). To evaluate the Software Engineering approaches, represented by software processes, new product technologies and improvements, making them available to the industry, the scientific method can be applied. Experimental Software Engineering aims at the use of scientific methodology (experimentation) to define a better understanding about software development, costs and benefits of techniques, a body of knowledge consolidation and, thus, the definition of feasible models for software development (AMARAL & TRAVASSOS, 2003). Furthermore, the experimentation applied as a collaborative activity increases the credibility of the performed research (AMARAL 2003) and would allow knowledge and information sharing among researchers on the Software Engineering Community.
However, experimental research in Software Engineering must take into account a lot of specific issues, variables and characteristics, being a complex activity as shown by BASILI et al. (1999). One way to make experimental research more manageable is trough the definition of frameworks to support the Experimentation Process in Software Engineering (WOHLIN et al., 2002, JURISTO & MORENO, 2001). Figure 1. Basic Concepts of esee s infrastructure Motivated by this scenario, a software engineering environment for experimentation (esee - experimental Software Engineering Environment) is being developed at COPPE/UFRJ. It aims at the supporting of experimentation activities throughout the Experimentation Process (MIAN et al. 2004,2005). The esee infrastructure is basically composed of three levels: meta-esee, configured-esee and instantiated-esee. In this paper, we will describe our experience on building the set of facilities to support the meta-esee level activities, mainly those concerned with experimentation processes and documents descriptions and e-services association. This set of facilities composes one of the three macro-components: the Meta-Configurator. Besides this introduction, this paper presents more three sections. In section 2, we discuss the esee s requirements and the architectural composition (NETO et al. 2004). In section 3, we present the set of tools that support the esee s metadescriptions activities, examining the project decisions and limitations. Finally, we conclude the paper pointing out the future perspectives and related works. 2. The experimental Software Engineering Environment An engineering environment to support experimentation in Software Engineering must provide the adequate set of facilities allowing the execution of tasks by individuals playing different roles in the Experimentation Process. CHAPETTA et al. (2004) performed a requirement elicitation to define the functionalities for SE experiments monitoring, executing and packaging activities based on WOHLIN et al. (2002), AMARAL (2003) and MIAN et al. (2004), what includes: (1) Having integrated experimentation support tools, performing similarly as a Software Development Environment (SDE); (2) Being a Web System, allowing its use on different localities and inter-institutional researches; (3) Using of e-services based paradigm, and; (4) Providing Knowledge Management mechanisms, since Experimental Software Engineering is a knowledge-intensive area. Based on these requirements, the esee architecture (DIAS NETO et al. 2004) considered three distributed macro-components, aiming at to describe a solution for experimental Software Engineering processes modeling, instantiation and executing. These distributed components are represented by: Meta-Configurator (MC), Instantiation Environment (IE) and Execution Environment (EE) (Figure 1).
The MC deals with the meta-descriptions activities. Its main functionality is regarding the definition and configuration of the basic elements used by the others components, as follow: (1) Process Models: allow the instantiation of the experimentation processes, by using the Process Meta-Model found in VILELA (2004); (2) Documents Models: allow the instantiation of the documents produced throughout the Experimentation Process, by using its own Document Meta-Model, and; (3) Configured Services: Information about the use of e-services (KIM et al., 2002) that could support some activity into Experimentation Process. Theses e-services, available or not internally at esee, are customized to be used in the Execution Environment. For each element (processes, documents and services), there is an associated meta-description component, represented by a Process Modeling Component, Documents Modeling Component and e-service Configuration Component. Only the definition of basic elements is described, but the relationships among them will be captured later. These definitions are stored in specific repositories. The goal of the second macro-component (IE) is to provide mechanisms to define and instantiate an EE. This component is responsible for the definition of the relationships among the experimentation process s activities, produced/consumed documents and configured services to accomplish a task. This set of relationships is called an Association Map and is defined by the Association Mapping Component. The Association Maps are stored in a specific repository, allowing instantiations of customized EEs. The Instantiation Component makes the instantiation of an EE. The EE is responsible for the monitoring, controlling and execution of the Experimentation Process s activities. The monitoring and controlling is performed by the chosen Experimentation Process, according to the restrictions of information access control among the process s activities. More details about the esee s IE and EE can be obtained in DIAS NETO et al. (2004), MIAN et al. (2004,2005). To evaluate the esee s infrastructure development feasibility, a prototype has been built (DIAS NETO et al. 2004). Due to the difficulty and effort of the basic elements description and configuration, simple documents and processes models were made without tools to support it, and the service configuration activities were not considered due to the lack of e-services to use in this context. Thus, the next step of this project was the building of tools to support the esee s meta-description activities. 3. esee s Meta-description activities Tools The meta-description activities comprise those defining and configuring the basic elements described in the previous section. So, in this phase, these activities allow to define the template of the documents, how and when they will be filled out and, also, which external tools will be used (e-services). Based on the esee s requirements, such as the use of platform independent technologies, some projects decisions had been made. For processes and documents description, the respective meta-models were mapped into a set of rules by using XML syntax (XML specification). Due to the distributed characteristics of esee s architecture components, for e-service construction and configuration, the web services approach has been adopted. Web services and related technologies (SOAP and WSDL) are platform independent. The WSDL (WSDL specification) and SOAP (SOAP
specification) are W3C recommendations and represent an attempt to establish, respectively, access and communication standards for use of web services. Each MC s component has its functionalities implemented to support its respective meta-activities. This set of functionalities was implemented and encapsulated into two tools. One of them is responsible for the e-services configurations, and another one is responsible for the process and documents modeling. Doing so, the esee s architectural components responsible for the process and documents modeling are encapsulated into a single tool. The forthcoming sub-sections describe each one in detail, presenting the additional project decisions and limitations. 3.1. Process and Documents Modeling Tool This tool is primarily used to describe an Experimentation Process Model, where a process, and its activities, artifacts and roles are defined. When the activities are described, the ordered and hierarchical (composition) relationships between the activities are established. The Figure 2 shows the tool s process modeling interface. Figure 2. Process Modeling At the end of this activity, a process model is stored and published in a process models repository, which could be chosen to compose an Association Map and used to instantiate an Execution Environment. After an Experimentation Process definition, this tool is used to elaborate the documents produced/consumed throughout the Experimentation Process. A document model represents the descriptions of these documents. It means that a documents model represents the documents template to be filled out for a specific individual playing a specific role in the Experimentation Process. This tool has been built in C++ programming language. And the model publication functionality is available trough one web service. This web service was implemented in Zope (http://www.zope.org), a Web application server with an objectoriented database, having all published models described in XML and available for the IE. 3.2. Service Configuration Tool The infrastructure allows the configuration of web services as external tools to the esee. The idea of these external tools is to let the development and/or reuse of tools like plug-ins, independently of programming language and external tools. The Services Configurator was built to support the web services configuration activity. A configured service is a web service with its WSDL descriptor (a web service properties list which describes important information like location, operations or methods, etc) available. Some restrictions were imposed in this activity. The first one is
that the e-service must be constructed using the web services standards. The second is that the web service must be available through its WSDL descriptor. The service configuration activity is best shown in two cases: (1) the first case occurs when the external tool is developed for the infrastructure and, thus, no modification to its WSDL descriptor is required. (2) The other, when the web service does not exactly fit all the requirements and some adaptation can possibly be made to its interface in order to be used by esee. This adaptation is supported by the Services Configurator tool, which allows the definition of a new web service interface to meet, if possible, the external tool use. To achieve this, the tool creates a new web service that works like an adapter between the infrastructure and the original web service and makes available the WSDL descriptor of this new interface. The definition is made through the Service Configurator GUI, which facilitates the selection of the parameters that will form the new interface, as shown in Figure 3. This tool generates the code of the new web service and deploys it on the Tomcat servlet container, which makes available its WSDL descriptor. The tool was built using the Python language and thus can be used in Windows and Linux based Operating Systems, respecting the esee s portability requirement (CHAPETTA et al 2004). Figure 3. Service Configuration Interface The essential limitation in the services configuration is the fact that only one operation can be configured at time. This introduces another limitation that not all the services can be reused in this way. Moreover, we believe that just altering the operation interface cannot significantly increase the services that can be reused. 4. Conclusion This paper described a set of tools that composes one of three esee s macrocomponents. The building of these tools allowed us to make a more robust evaluation about the esee s construction feasibility, so that these components were integrated at the first version of prototype. It also allowed us to identify that the use of web services as e-services implementation approach is feasible. Our future perspectives are concerned with the prototype s evolution to achieve web services use as data interchange mechanisms and the building of new tools to support other Experimentation Process activities. Into this context, it has been built a tool to support the Operation activity in the Experimentation Process. This tool is being developed to be a stand-alone Web application, but it will be available to esee infrastructure encapsulated as web service.
Acknowledgments Thanks to Rafael Barcelos and Tayana Conte for your suggestions, André Quadros for the building of the Process and Documents Modeling Tool, and CNPQ and CAPES for the financial support. This project is granted by CNPQ- Projeto Universal. References AMARAL, E. A. G. G. (2003) Empacotamento de Experimentos em Engenharia de Software, Master Dissertation, COPPE/UFRJ, Engenharia de Sistemas e Computação, Rio de Janeiro, RJ, Brazil. BASILI, V. R., SHULL, F., LANUBILE, F. (1999). Building Knowledge through Families of Experiments, IEEE Transactions on Software Engineering, Vol. 25, No 4, pp. 456-473. CHAPETTA, W. A.; CONTE, T. U.; TRAVASSOS, G. H. (2004) Requisitos para um Ambiente para Experimentação em Engenharia de Software, Technichal Report, ESE, Engenharia de Sistemas e Computação, COPPE/UFRJ, RJ, Brazil.. JURISTO, N. & MORENO, A.M. (2001) Basics of Software Engineering Experimentation, Hardcover, ISBN: 0-7923-7990-X. KIM, W., GRAUPNER, S., SAHAI, A., LENKOV, D., CHUDASAMA, C., WHEDBEE, S., YUHUA LUO, DESAI, B., MULLINGS, H., PUI WONG. (2002). Web E-speak: facilitating Web-based e-services, Multimedia, IEEE, Volume 9, Issue 1, Jan.-March Page(s): 43 55. MIAN, P. G.; TRAVASSOS, G. H.; ROCHA, A. R. C.; NATALI, A. C. C.(2004) Towards a Computerized Infrastructure for Experimental Software Engineering Knowledge. In: Anais da 4a Jornadas Iberoamericanas em Ingeniería del Software e Ingeniería del Conocimiento, Madrid, Espanha, November. MIAN, P. G; TRAVASSOS, G. H.; ROCHA, A.R.C. (2005) A Computerized Infrastructure for Supporting Experimentation in Software Engineering, 2nd Experimental Software Engineering Latin American Workshop ESELAW 05, Uberlândia, Brasil. DIAS NETO, A. C., BARCELOS, R., CHAPETTA W. A., SANTOS, P. S. M., MAFRA, S. N., TRAVASSOS, G. H. (2004). Infrastructure for SE Experiments Definition and Planning, 1st Experimental Software Engineering Latin American Workshop - ESELAW'04, Brasília, Brazil. PFLEEGER, S.L. (1999) Albert Einstein and Empirical Software Engineering, IEEE Computer, October. SOAP specification (2005). available in http://www.w3.org/tr/soap12/ and accessed on July, 2005. VILLELA, K. (2004) Ambientes de Desenvolvimento de Software Orientados à Organização. D.Sc. Thesis, PESC, COPPE/UFRJ, Rio de Janeiro, RJ, Brazil. XML specification (2005), avaliable in http://www.w3.org/tr/2004/rec-xml- 20040204/ and accessed on July, 2005. WOHLIN, C., RUNESON, P., HÖST, M., OHLSSON, M. C., REGNELL, B., WESSLÉN, A. (2000). Experimentation in Software Engineering: an Introduction, Kluwer Academic Publishers, Massachusetts. WSDL specification, available in http://www.w3.org/tr/wsdl and acessed on July, 2005.