Gustavo Ansaldi Oliva

A systematic literature review of service choreography adaptation

A service choreography is a distributed service composition in which services interact without a centralized control. Adequate adaptation strategies are required to face complex and ever-changing business processes, given the collaborative nature of choreographies. Choreographies should also be able to adapt to changes in its non-functional requirements, such as response time, and especially for large-scale choreographies, adaptation strategies need to be automated and scale well. However, the body of knowledge regarding choreography adaptation approaches has not yet been consolidated and systematically evaluated. By means of a systematic literature review, in which we examined seven scientific paper sources, we identified and analyzed the state-of-the-art in choreography adaptation. We found 24 relevant primary studies and grouped them into six categories: model-based, measurement-based, multi-agent-based, formal method-based, semantic reasoning-based, and proxy layer-based. We analyzed (i) how each strategy deals with different types of requirements, (ii) what their required degree of human intervention is, (iii) how the different studies considered scalability, (iv) what implementations are currently available, and (v) which choreography languages are employed. From the selected studies, we extracted key examples of choreography adaptation usage and analyzed the terminology they adopted with respect to dynamic adaptation. We found out that more attention has been devoted to functional requirements and automated adaptation; only one work performs scalability evaluation; and most studies present some sort of implementation and use a specific choreography notation.

An integrated development and runtime environment for the future internet

The Future Internet environments raise challenging issues for the Service-Oriented Architectures. Due to the scalability and heterogeneity issues new approaches are thought in order to leverage the SOA to support a wider range of services and users. The CHOReOS project is part of the European Community Initiative to sketch technological solutions for the future ultra large systems. In particular, CHOReOS explores the choreography of services paradigm. Within this project, a conceptual architecture combining both the development and runtime environments is realized. This chapter introduces the CHOReOS Integrated Development and Runtime Environment, aka IDRE.

Towards a classification of logical dependencies origins: a case study

Logical dependencies are implicit relationships established between software artifacts that have evolved together. Software engineering researchers have investigated this kind of dependency to assess fault-proneness, detect design issues, infer code decay, and predict likely changes in code. Despite the acknowledged relation between logical dependencies and software quality, the nature of the logical dependencies is unknown in the literature. Most authors hypothesize about their origins, but no empirical study has been conducted to investigate the real nature of these dependencies. In this paper, we investigated the origins of logical dependencies by means of a case study involving a Java FLOSS project. We mined the project repository, filtered out irrelevant data based on statistical analyses, and performed a manual inspection of the logical dependencies to identify their origins using information from the revision comments, code diffs, and informal interviews held with the developers of the analyzed project. Preliminary results showed that logical dependencies involved files that changed together for a series of different reasons, which ranged from changing software license to refactoring classes that belonged to the same semantic class.

On the Interplay between Structural and Logical Dependencies in Open-Source Software

Structural dependencies have long been explored in the context of software quality. More recently, software evolution researchers have investigated logical dependencies between artifacts to assess failure-proneness, detect design issues, infer code decay, and predict likely changes. However, the interplay between these two kinds of dependencies is still obscure. By mining 150 thousand commits from the Apache Software Foundation repository and employing object-oriented metrics reference values, we concluded that 91% of all established logical dependencies involve non-structurally related artifacts. Furthermore, we found some evidence that structural dependencies do not lead to logical dependencies in most situations. These results suggest that dependency management methods and tools should rely on both kinds of dependencies, since they represent different dimensions of software evolvability.

Experience report: How do structural dependencies influence change propagation? An empirical study

Real world object-oriented systems are composed of hundreds or even thousands of classes that are structurally interconnected in many different ways. In this highly complex scenario, it is unclear how changes propagate. Given the high maintenance cost brought by change propagation, these questions become particularly relevant in practice. In this paper, we set out to investigate the influence of structural dependencies on change propagation. We historically analyzed thousands of code snapshots coming from 4 open-source Java projects of different sizes and domains. Our results indicated that, in general, it is more likely that two artifacts will not co-change just because one depends on the other. However, the rate with which an artifact co-changes with another is higher when the former structurally depends on the latter. This rate becomes higher if we track down dependencies to the low-level entities that are changed in commits. This implies, for instance, that developers should be aware of dependencies on methods that are added or changed, as these dependencies tend to propagate changes more often. Finally, we also found several cases where software changes could not be justified using structural dependencies, meaning that co-changes might be induced by other subtler kinds of relationships.

A Change Impact Analysis Approach for Workflow Repository Management

Large and complex workflow repositories include a series of interdependent workflows. In this scenario, it becomes hard to estimate the effort required to accomplish changes to workflows. Furthermore, ad-hoc changes may induce side and ripple effects, which ultimately hamper the reliability of the repository. In this paper, we introduce a static dependency-centric change impact analysis approach for workflow repository management. The approach relies on metrics and visualizations that makes it easy and quick to estimate change impact. We implemented the approach, incorporated it into HP Operations Orchestration (HP OO), and conducted an exploratory study in which we thoroughly analyzed the workflow repository of 8 HP OO customers. Besides being able to characterize and compare the repositories against each other, we found that while the out-of-the-box repository provided by HP OO has 10 flows with high change impact, 5 customer repositories had higher values that ranged from 11 (+10%) to 35 (+250%).

What can commit metadata tell us about design degradation

Design degradation has long been assessed by means of structural analyses applied on successive versions of a software system. More recently, repository mining techniques have been developed in order to uncover rich historical information of software projects. In this paper, we leverage such information and propose an approach to assess design degradation that is programming language agnostic and relies almost exclusively on commit metadata. Our approach currently focuses on the assessment of two particular design smells: rigidity and fragility. Rigidity refer to designs that are difficult to change due to ripple effects and fragility refer to designs that tend to break in different areas every time a change is performed. We conducted an evaluation of our approach in the project Apache Maven 1 and the results indicated that our approach is feasible and that the project suffered from increasing fragility.

Using contextual information to predict co-changes

Contextual information can improve the co-change prediction, especially the precision.The proposed models outperform the association rules used as baseline model.More than one dimension was frequently selected by our classifier. Background: Co-change prediction makes developers aware of which artifacts will change together with the artifact they are working on. In the past, researchers relied on structural analysis to build prediction models. More recently, hybrid approaches relying on historical information and textual analysis have been proposed. Despite the advances in the area, software developers still do not use these approaches widely, presumably because of the number of false recommendations. We conjecture that the contextual information of software changes collected from issues, developers communication, and commit metadata captures the change patterns of software artifacts and can improve the prediction models. Objective: Our goal is to develop more accurate co-change prediction models by using contextual information from software changes. Method: We selected pairs of files based on relevant association rules and built a prediction model for each pair relying on their associated contextual information. We evaluated our approach on two open source projects, namely Apache CXF and Derby. Besides calculating model accuracy metrics, we also performed a feature selection analysis to identify the best predictors when characterizing co-changes and to reduce overfitting. Results: Our models presented low rates of false negatives (8% average rate) and false positives (11% average rate). We obtained prediction models with AUC values ranging from 0.89 to 1.00 and our models outperformed association rules, our baseline model, when we compared their precision values. Commit-related metrics were the most frequently selected ones for both projects. On average, 6 out of 23 metrics were necessary to build the classifiers. Conclusions: Prediction models based on contextual information from software changes are accurate and, consequently, they can be used to support software maintenance and evolution, warning developers when they miss relevant artifacts while performing a software change.

An Empirical Study of the Relation Between Strong Change Coupling and Defects Using History and Social Metrics in the Apache Aries Project

Change coupling is an implicit relationship observed when artifacts change together during software evolution. The literature leverages change coupling analysis for several purposes. For example, researchers discovered that change coupling is associated with software defects and reveals relationships between software artifacts that cannot be found by scanning code or documentation. In this paper, we empirically investigate the strongest change couplings from the Apache Aries project to characterize and identify their impact in software development. We used historical and social metrics collected from commits and issue reports to build classification models to identify strong change couplings. Historical metrics were used because change coupling is a phenomenon associated with recurrent co-changes found in the software history. In turn, social metrics were used because developers often interact with each other in issue trackers to accomplish the tasks. Our classification models showed high accuracy, with 70−99 % F-measure and 88−99 % AUC. Using the same set of metrics, we also predicted the number of future defects for the artifacts involved in strong change couplings. More specifically, we were able to predict 45.7 % of defects where these strong change couplings reoccurred in the post-release. These findings suggest that developers and projects managers should detect and monitor strong change couplings, because they can be associated with defects and tend to happen again in the subsequent release.

Change Coupling Between Software Artifacts: Learning from Past Changes

While mining version control systems, researchers noticed that some artifacts frequently change together throughout software development. When a certain artifact co-changes repeatedly with another, we say that the former is change coupledto the latter. Researchers have found a series of applications for change coupling in software engineering. For instance, building on the idea that artifacts that changed together in the past are likely to change together in the future, researchers developed effective change prediction mechanisms. In this chapter, we describe the concept of change coupling in more detail and present different techniques to detect it. In particular, we provide ready-to-use code you can leverage as a starting step to detect change couplings in your own projects. In the last part of the chapter, we describe some of the main applications of change coupling analysis.Abstract While mining version control systems, researchers noticed that some artifacts frequently change together throughout software development. When a certain artifact co-changes repeatedly with another, we say that the former is change coupled to the latter. Researchers have found a series of applications for change coupling in software engineering. For instance, building on the idea that artifacts that changed together in the past are likely to change together in the future, researchers developed effective change prediction mechanisms. In this chapter, we describe the concept of change coupling in more detail and present different techniques to detect it. In particular, we provide ready-to-use code you can leverage as a starting step to detect change couplings in your own projects. In the last part of the chapter, we describe some of the main applications of change coupling analysis.