Deriving Change Architectures from RCS History

C. Stringfellow, C.D. Amory, D. Potnuri, M. Georg, and A. Andrews (USA)

Keywords

software architecture, reverse architecting, software maintenance

Abstract

As software systems evolve over a series of releases, it becomes important to know which components show re peated need for maintenance. Deterioration of a sin gle component manifests itself in repeated and increas ing problems that are local to the component. A second type of deterioration is related to interactions between com ponents, that is, components are repeatedly change-prone in their relationships with each other. The latter requires changes to code in multiple components and is a sign of problems with the software architecture of the system. Software architecture problems are by far more costly to fix and thus it is very desirable to identify potential archi tectural problems early and to track them across multiple releases. This paper uses Revision Control System (RCS) change history to determine which system parts are the most change-prone, both locally and in their interactions with other parts of the systems. Relationships among sys tem components are identified based on whether they are involved in the same group of changes, and how many lines of code are changed. The resulting change architecture fig ures show what the system's most change-prone compo nents and relationships are. We illustrate our technique on a large commercial system consisting of over 800 KLOC of C, C++, and microcode.

Important Links:



Go Back


IASTED
Rotating Call For Paper Image