The way in which a system's software archive is partitioned influences the evolvability of that system. The partition of a software archive is mostly assessed by looking at the static (include, call) relations between the parts. In the literature history information is also taken into account to assess the partition but only pairs of software entities are related. In this paper we describe a novel history-based approach to assess the extent in which a certain partition allows its parts to evolve independently. We use the assumption that a set of software entities which co-evolved often in the past are likely to be modified together in the near future as well. Hence, the elements of such a set should in principle belong to the same part. Our approach, therefore, identifies sets of co-evolving software entities, where each set has elements from more than one part of the archive. We illustrate our approach with a case study of a large software system that evolved during more than a decade, and has over 7 million lines of code.

No abstract

No abstract

Abstract-A single development task such as solving a bug or implementing a new feature often involves changing a number of entities, also known together as a change set. Change sets can be approximated from the version control system. They are then used by the architects and developers to take important decisions. So change sets need to be approximated carefully. It is common to assume that two entities checked-in less than a small time interval from each other, and having the same meta-data associated with them, belong to the same transaction. Transactions may be good approximations of change sets if developers commit change sets in one go and if the required meta-data is available. This is however not the case in the industrial environment (Philips Healthcare) we study. Our paper presents a case study in which we investigated how change sets can be approximated in an environment with a complex workflow and limited meta-data in the version repositories. We found that, dependent on the commit practices used, a suitable time intervals between check-in timestamps of files has to be determined and leveraged to reliably approximate change sets.

SUMMARYThe architect of a large, evolving system may wish to revise its decomposition from time to time; for instance, because the structure has deteriorated over time, certain components need to be outsourced to another site. One way to assess the current decomposition is to consider the past evolution, searching for components that often changed together. We iteratively devised and implemented a process for doing so at Philips Healthcare MRI. In this paper, we describe the lessons learned on how to effectively support architects to improve their system decomposition. Copyright © 2011 John Wiley & Sons, Ltd.