A Reflective Approach to Dynamic Software Evolution

In this paper, we present a solution that allows systems to remain active while they are evolving. Our approach goes out from the principle of separated concerns and has two steps. In the first step, we have to make sure that the system's evolvable concerns are cleanly separated. We propose aspect mining and static refactorings for separating those concerns. In a second step, we allow every concern to evolve separately. We present a preliminary reflective framework that allows dynamic evolution of separate concerns. 1 Problem Statement An intrinsic property of a successful software application is its need to evolve. In order to keep an existing application up to date, we continuously need to adapt it. Usually, evolving such an application requires it to be shut down, however, because updating it at runtime is generally not possible. In some cases, this is beyond the pale. The unavailability of critical systems, such as web services, telecommunication switches, banking systems, etc. could have unacceptable financial consequences for the companies and their position in the market. Redundant systems (1) are currently the only solution available to solve this problem. Their main idea is to provide a critical system with a duplicate, that is able to take over all functions of the original system whenever this latter is not available. Although this solution has been proved to work, it still has some disadvantages. First of all, redundant systems require extra management concerning which software version is installed on which duplicate. Second, maintaining the redundant systems and switching between them can be hard and is often underestimated. What would happen for instance when the switching mechanism fails? Would we have to make a redundant switching mechanism and another switching mechanism for switching between the switching systems? Last, duplicate software and hardware devices should be present, which may involve severe financial issues. The principle of separation of concerns (2) could provide an improved and more flexible solution to the problem. Applications developed with this principle in mind implement every concern in a separate entity. These entities can then be adapted and substituted without affecting the rest of the application. Depending on the programming paradigm used, an entity can be a function, an abstract data type, a class or a component, for example, or even an aspect if we employ aspect-oriented programming techniques. Whenever an application is decomposed into cleanly separated entities, its evolution boils down to the addition, the removal or the modification of such an entity. If such activities can be performed while the application is running, we call such evolution dynamic software evolution. In practice, the principle of separation of concerns is not always that easy to achieve. As it turns out, no matter how well an application is decomposed into modular entities, some functionality always cross-cuts this modularisation. This phenomenon is known as the tyranny of the dominant decomposi- tion (3). As a consequence, such cross-cutting functionality (often called a concern) can not be evolved separately, as it affects all other entities in the application. Although techniques exist for addressing the problem of the dominant decomposition (4-7), they should be considered too static for supporting dynamic evolution. In effect, they provide a model in which cross-cutting concerns are fixed in the application at compile time. To solve this issue, more dynamic techniques should be investigated. Several prototypes of those techniques do exist: (8,9), but still lack some dynamic properties as well as practical experience.