Camila Nunes

On the impact of crosscutting concern projection on code measurement

Many concern metrics have been defined to quantify properties of crosscutting concerns, such as scattering, tangling, and dedication. To quantify these properties, concern metrics directly rely on the projection (assignment) of concerns into source code. Although concern identification tools have emerged over the last years, they are still rarely used in practice to support concern projection and, therefore, it is a task often performed manually. This means that the results of concern metrics are likely to be influenced by how accurately programmers assign concerns to code elements. Even though concern assignment is an important and long-standing problem in software engineering, its impact on accurate measures of crosscutting concerns has never been studied and quantified. This paper presents a series of 5 controlled experiments to quantify and analyse the impact of concern projection on crosscutting concern measures. A set of 80 participants from 4 different institutions projected 10 concern instances into the source code of two software systems. We analyse the accuracy of concern projections independently made by developers, and their impact on a set of 12 concern metrics. Our results suggest that: (i) programmers are conservative when projecting crosscutting concerns, (ii) all concern metrics suffer with such conservative behaviour, and (iii) fine-grained tangling measures are more sensitive to different concern projections than coarse-grained scattering metrics.

Developing and Evolving a Multi-agent System Product Line: An Exploratory Study

Software Product Line (SPL) approaches motivate the development and implementation of a flexible and adaptable architecture to enable software reuse in organizations. The SPL architecture addresses a set of common and variable features of a family of products. Based on this architecture, products can be derived in a systematic way. A multi-agent system product line (MAS-PL) defines a SPL architecture, whose design and implementation is accomplished using software agents to address its common and variable features. This paper presents the evolutionary development of a MAS-PL from an existing web-based system. The MAS-PL architecture developed is composed of: (i) the core architecture represented by the web-based system that addresses the main mandatory features; and (ii) a set of software agents that extends the core architecture to introduce in the web system new optional and alternative autonomous behavior features. We report several lessons learned from this exploratory study of definition of a MAS-PL.

On the development of multi-agent systems product lines: a domain engineering process

Multi-agent System Product Lines (MAS-PLs) are the integration of two promising technologies: Multi-agent Systems (MASs), which provides a powerful abstraction to model features with autonomous and pro-active behavior, and Software Product Lines (SPLs), whose aimis to reduce both time-to-market and costs in the development of system families by the exploitation of commonalities among family members. This paper presents a domain engineering process for developing MAS-PLs. It defines activities and work products, whose purposes include allowing agent variability and providing agent features traceability, both not addressed by current SPL and MAS approaches.

Extending web-based applications to incorporate autonomous behavior

Web applications are popular nowadays due to the ubiquity of the client and also because user experience is becoming each time more interactive. However, several tasks of these applications can be automated. Agent-oriented software engineering has emerged as a new software engineering paradigm to allow the development of applications that present autonomous behavior. In this work, we present two case studies of web-based systems, on which we added autonomous behavior by means of software agents. We also discuss some design and implementation issues found on the development of those systems and propose an architectural pattern as a consequence of our case studies.

Revealing Mistakes in Concern Mapping Tasks: An Experimental Evaluation

Concern mapping is the activity of assigning a stakeholder’s concern to its corresponding elements in the source code. This activity is primordial to guide software maintainers in several tasks, such as understanding and restructuring the implementation of existing concerns. Even though different techniques are emerging to facilitate the concern mapping process, they are still manual and error-prone according to recent studies. Existing work does not provide any guidance to developers to review and correct concern mappings. In this context, this paper presents the characterization and classification of eight concern mapping mistakes commonly made by developers. These mistakes were found to be associated with various properties of concerns and modules in the source code. The mistake categories were derived from actual mappings of 10 concerns in 12 versions of industry systems. In order to further evaluate to what extent these mistakes also occur in wider contexts, we ran two experiments where 26 subjects mapped 10 concerns in two systems. Our experimental results confirmed the mapping mistakes that often occur when developers need to interact with the source code.

Developing multi-agent system product lines: from requirements to code

Many modern software systems have autonomous, open, context-aware and highly-interactive properties. The agent abstraction with its autonomous and pro-active characteristics and the related discipline of agent-oriented software engineering (AOSE) are promising paradigms to address these types of systems. Even though agents are frequently being adopted, little effort has been directed in AOSE methodologies toward extensive software reuse techniques, which can provide both reduced time-to-market and lower development costs. Multi-agent system product lines (MAS-PLs) are the result of the integration of AOSE with software product lines (SPLs). SPLs bring many reuse benefits to the agent domain through the exploitation of common characteristics among family members. In this context, this paper presents a domain engineering process for developing MAS-PLs. It defines activities and work products, whose purposes include supporting agent variability and providing agent feature traceability, both not addressed by current SPL and AOSE approaches.

JAAF+T: a framework to implement self-adaptive agents that apply self-test

Appropriate implementation of self-adaptive software systems able not only to check the needs for the adaptations and perform them but also to ensure their compliance with new environment requirements is still an open issue. Therefore, this paper proposes an extension to the Java self-Adaptive Agent Framework (JAAF) in order to apply the self-test concept. This framework allows for the creation of self-adaptive agents based on a process composed of a set of four main activities (monitor, analyze, plan and execute). In this paper we extend the process and framework by including the test activity that will check the adapted behavior before its execution. The applicability of the proposed process is demonstrated by a case study where a system responsible for generating susceptibility maps, i.e., maps that show locations with landslides risks in a given area, searches to adapt its behavior and checks the adaptations before using them.

Comparing Stability of Implementation Techniques for Multi-agent System Product Lines

Multi-agent systems (MAS) are increasingly being exploited to support autonomous recommendation of products and information to contemporary application users. Multi-agent system product lines (MAS-PL) promote large-scale reuse of common and variable agency features across multiple MAS applications. The development of MAS-PLs can be achieved through alternative MAS-specific frameworks (JADE and Jadex), and general-purpose implementation techniques, such as aspect-oriented programming (AOP). However, there is not much evidence on how these techniques provide better modularity, allowing the conception of stable MAS-PL designs. This paper reports an empirical study that assesses the modularity of a MAS-PL through a systematic analysis of its releases. The study consists of a comparison among three distinct versions of this MAS-PL, each one implemented with a different technique: (i) Jadex platform and configuration files; (ii) JADE platform and configuration files; and (iii) JADE platform enriched with AOP mechanisms. Our analysis was driven by fundamental modularity attributes.

Heuristic expansion of feature mappings in evolving program families

Establishing explicit mappings between features and their implementation elements in code is one of the critical factors to maintain and evolve software systems successfully. This is especially important when developers have to evolve program families, which have evolved from one single core system to similar but different systems to accommodate various requirements from customers. Many techniques and tools have emerged to assist developers in the feature mapping activity. However, existing techniques and tools for feature mapping are limited as they operate on a single program version individually. Additionally, existing approaches are limited to recover features on demand, that is, developers have to run the tools for each family member version individually. In this paper, we propose a cohesive suite of five mapping heuristics addressing those two limitations. These heuristics explore the evolution history of the family members in order to expand feature mappings in evolving program families. The expansion refers to the action of automatically generating the feature mappings for each family member version by systematically considering its previous change history. The mapping expansion starts from seed mappings and continually tracks the features of the program family, thus eliminating the need of on demand algorithms. Additionally, we present the MapHist tool that provides support to the application of the proposed heuristics. We evaluate the accuracy of our heuristics through two evolving program families from our industrial partners. Copyright © 2013 John Wiley & Sons, Ltd.

History-sensitive heuristics for recovery of features in code of evolving program families

A program family might degenerate due to unplanned changes in its implementation, thus hindering the maintenance of family members. This degeneration is often induced by feature code that is changed individually in each member without considering other family members. Hence, as a program family evolves over time, it might no longer be possible to distinguish between common and variable features. One of the imminent activities to address this problem is the history-sensitive recovery of program familys features in the code. This recovery process encompasses the analysis of the evolution history of each family member in order to classify the implementation elements according to their variability nature. In this context, this paper proposes history-sensitive heuristics for the recovery of features in code of degenerate program families. Once the analysis of the family history is carried out, the feature elements are structured as Java project packages; they are intended to separate those elements in terms of their variability degree. The proposed heuristics are supported by a prototype tool called RecFeat. We evaluated the accuracy of the heuristics in the context of 33 versions of 2 industry program families. They presented encouraging results regarding recall measures that ranged from 85% to 100%; whereas the precision measures ranged from 71% to 99%.