Modern software systems are often characterized by uncertainty and changes in the environment in which they are embedded. Hence, they must be designed as adaptive systems. We propose a framework that supports adaptation to non-functional manifestations of uncertainty. Our framework allows engineers to derive, from an initial model of the system, a finite state automaton augmented with probabilities. The system is then executed by an interpreter that navigates the automaton and invokes the component implementations associated to the states it traverses. The interpreter adapts the execution by choosing among alternative possible paths of the automaton in order to maximize the system's ability to meet its non-functional requirements. To demonstrate the adaptation capabilities of the proposed approach we implemented an adaptive application inspired by an existing worldwide distributed mobile application and we discussed several adaptation scenarios.

Test suites, just like the applications they are testing, evolve throughout their lifetime. One of the main reasons for test-suite evolution is test obsolescence: test cases cease to work because of changes in the code and must be suitably repaired. There are several reasons why it is important to achieve a thorough understanding of how test cases evolve in practice. In particular, researchers who investigate automated test repair - an increasingly active research area - can use such understanding to develop more effective repair techniques that can be successfully applied in real-world scenarios. More generally, analyzing testsuite evolution can help testers better understand how test cases are modified during maintenance and improve the test evolution process, an extremely time consuming activity for any nontrivial test suite. Unfortunately, there are no existing tools that facilitate investigation of test evolution. To tackle this problem, we developed TestEvol, a tool that enables the systematic study of test-suite evolution for Java programs and JUnit test cases. This demonstration presents TestEvol and illustrates its usefulness and practical applicability by showing how TestEvol can be successfully used on real-world software and test suites. Demo video at http://www.cc.gatech.edu/~orso/software/testevol/.

We present the workflow language DSOL, its runtime system and the tools available to support the development of dynamic service orchestrations. DSOL aims at supporting dynamic, self-managed service compositions that can adapt to changes occurring at runtime.

Service Oriented Computing enables distributed applications that orchestrate existing services exported by remote providers. This paradigm requires to explicitly handle possible changes that may affect the orchestration. They include changes that impact its functional behavior (e.g., services being retired by their providers), but also changes in the non-functional behavior of the orchestrated services (e.g., an increased execution time). In the past we developed DSOL: it combines a declarative language to model the orchestration with planning mechanisms to decide at run-time the best flow of actions. In this paper we extend DSOL to support QoS attributes and requirements. In particular, we combine the DSOL planning techniques with a linear optimizer to calculate the optimal plan w.r.t. the QoS requirements. Moreover, we leverage the DSOL ability to adapt the orchestration flow at run-time, to further optimize the QoS perceived by the end users depending on the actual situations encountered.

In this demo we present SelfMotion: a declarative language and a run-time system conceived to support the development of adaptive, mobile applications, built as compositions of ad-hoc components, existing services and third party applications. The advantages of the approach and the adaptive capabilities of SelfMotion are demonstrated in the demo by designing and executing a mobile application inspired by an existing, worldwide distributed, mobile application.

Test suites, once created, rarely remain static. Just like the application they are testing, they evolve throughout their lifetime. Test obsolescence is probably the most known reason for test-suite evolution---test cases cease to work because of changes in the code and must be suitably repaired. Repairing existing test cases manually, however, can be extremely time consuming, especially for large test suites, which has motivated the recent development of automated test-repair techniques. We believe that, for developing effective repair techniques that are applicable in real-world scenarios, a fundamental prerequisite is a thorough understanding of how test cases evolve in practice. Without such knowledge, we risk to develop techniques that may work well for only a small number of tests or, worse, that may not work at all in most realistic cases. Unfortunately, to date there are no studies in the literature that investigate how test suites evolve. To tackle this problem, in this paper we present a technique for studying test-suite evolution, a tool that implements the technique, and an extensive empirical study in which we used our technique to study many versions of six real-world programs and their unit test suites. This is the first study of this kind, and our results reveal several interesting aspects of test-suite evolution. In particular, our findings show that test repair is just one possible reason for test-suite evolution, whereas most changes involve refactorings, deletions, and additions of test cases. Our results also show that test modifications tend to involve complex, and hard-to-automate, changes to test cases, and that existing test-repair techniques that focus exclusively on assertions may have limited practical applicability. More generally, our findings provide initial insight on how test cases are added, removed, and modified in practice, and can guide future research efforts in the area of test-suite evolution.

Service Oriented Architecture (SOA) is considered the best solution to develop distributed applications that compose existing services to provide new added-value services for their users. However, we claim that the fully potential of SOA is still to be reached and it is our belief that this is caused by the same tools used to build service orchestrations. To overcome this situation we are developing a new declarative language for service orchestration, enhanced with an innovative runtime system which simplifies the development of flexible and robust service compositions.

This paper presents an analysis of the performance impact of two generic group communication APIs, namely Hedera and jGCS. The analysis was carried out in a four-node cluster by comparing the performance of different configurations of two well-known group communication middleware systems (i.e., JGroups and Spread), under different message sizes, both in standalone mode and when used as plug-ins for the two generic APIs. The results show that there are significant variations in the performance overhead imposed by each generic API on both JGroups and Spread, and that those differences are strongly related to variations in message size and the way each generic API is implemented. The paper also discusses whether it would be worth migrating from a standalone group communication implementation to a generic API.