Changeability

XVCL facilitates change. Modifying programs is known to be tedious and notoriously error-prone. Once a program has been changed, the change gets buried in the existing code - becomes invisible. After some time, it becomes unclear which parts of the code relate to which sources of change and why they are there. We find that the overall complexity of an evolving program increases, making any future changes even harder.

XVCL directly addresses these problems by explicating changes, automating routine and repeatedly performed changes, and avoiding repetitions in both program structures and programming processes. XVCL can represent traces of changes penetrating the affected software in the form of explicit, operational and replicable change plans. A change plan is a precise record of a complete chain of modifications related to a given source of change. We can streamline the whole chain of modifications triggered by different sources of change, propagating change to all the affected software artifacts. We may target at architecture-level changes (such as configuring components and their interfaces), detailed changes in components' code, or even change s in program documentation.

Change plans are contained in the specification meta-components that act on base meta-components containing the program code before change. Change plans can be kept in specification meta-components as long as it is useful for effective evolution, and integrated into the base code when change separation is not required anymore. Change traces created with XVCL are analogous to aspects in Aspect-Oriented-Programming [12] or hyperslices [15].

Change plans are human- and machine-readable. For developers, better visibility of past changes is invaluable in understanding and handling future changes. Changes are automatically merged into the base meta-components, according to a change plan, to produce a program after change, on demand. Change plans allow the XVCL processor to perform routine yet error-prone modification tasks automatically, faster and in a more reliable manner than this could be done manually. At the same time, developers can focus on creative aspects of software evolution.

The XVCL's focus on replicating changes allows us to produce custom component versions on demand rather than having to store multiple versions of similar components under a Software Configuration Management system. By doing that, we understand change better, keep our components small and avoid explosion of look-alike components which often becomes prohibitive to effective evolution or reuse.

Maintenance programmers are skeptical about abstractions that do not directly connect to code [5]. After all, programs must be changed at the code level and "only the source code is real". But, at the same time, effective maintenance requires us to understand and change programs also at the architecture level. XVCL finds a way out of this dilemma. Meta-components contain the actual code, as well as architectural elements or documentation. Higher level abstractions emerge from code and are tightly inter-related with code via formal dependency links. Therefore, in XVCL, unlike in many generation systems, we never get disconnected from the actual code. Even when we work at the architecture level, the impact of change is propagated down to code.

Previous      Next