Good change and bad change: An analysis perspective on software evolution

Software does change, and should change. Traditional industrial software systems often evolve over long periods of time with each new version forming a discreet milestone, while some new software systems involve constant adaptation to situations in the environment and therefore evolve continually. While necessary, software change can also be devastating, making the system difficult to change and maintain further. We believe that one promising way to manage and control change is to view an evolving system as a software product line where each version of the software is a product. Key to any successful software product line approach is a software architecture that supports variability management. Tools that can identify commonalities and differences among various releases are essential in collecting and managing the information on changed, added and deleted components. Equally important are tools that allow the architect to analyse the current status of the product line as well as its products from various perspectives, and to be able to detect and remove architectural violations that threaten the variability points and built-in flexibility. In this paper, we describe our current research on defining such a process and supporting tools for software evolution management based on product line concepts and apply it in a case study to a software testbed called TSAFE. We describe how we reverse engineer the actual architecture from the source code and how we develop new target architectures based on the reverse engineered one and the expected changes. We then described how we analyse the actual change across different implementations and visualize where the change actually occurred. We then describe how we determine if a particular implementation match the target architecture. The conclusion is that we have found that both these analysis techniques are particularly useful for analysing software evolution and complement each other.