Improving the build architecture of legacy C/C++ software systems

The build architecture of legacy C/C++ software systems, groups program files in directories to represent logical components. The interfaces of these components are loosely defined by a set of header files that are typically grouped in one common include directory. As legacy systems evolve, these interfaces decay, which contribute to an increase in the build time and the number of conflict in parallel developments. This paper presents an empirical study of the build architecture of large commercial software systems, introduces a restructuring approach, based on Reflexion models and automatic clustering, and reports on a case study using VIM open source editor

Improving the build architecture of legacy C/C++ software systems

Abstract. The build architecture of legacy C/C++ software systems, groups program files in directories to represent logical components. The interfaces of these components are loosely defined by a set of header files that are typically grouped in one common include directory. As legacy systems evolve, these interfaces decay, which contribute to an increase in the build time and the number of conflict in parallel developments. This paper presents an empirical study of the build architecture of large commercial software systems, introduces a restructuring approach, based on Reflexion models and automatic clustering, and reports on a case study using VIM open source editor.

On the Socio-Technical Dependencies in Free/Libre/Open Source Software Projects

During the course of the past two decades, Open Source Software (OSS) development model has lead to a number of projects which have produced software that rivals and in some cases even exceeds the scale and quality of the traditional software projects. Among others, Eclipse, Apache, Linux, and BSD operating system are representative examples of such success stories.However, OSS project like traditional in-house projects, often pose the potential for enormous problems, whose effects run the gamut from immense cumulative delay through complete breakdown and failure. This situation is evident, as OSS development is a socio-technical endeavor and is non-trivial. Such development occurs within an intensively collaborative process, in which technical prowess must go hand in hand with the efficient coordination and management of a large number of social, inter-personal interactions across the development organization. Furthermore, those social and technical dimensions are not orthogonal. It has been recognized that the structure of a software product and the layout of the development organization working on that product correlate.Therefore this thesis argue that a comprehensive understanding on the sustainable evolution of OSS projects can be gained through the examination of the mutual influence of social and technical dimensions in OSS development. Thus, the goal of this thesis is the verification and reasoning of the following proposition,“The evolution of the Open Source Software (OSS) project is constrained by the non-orthogonal evolution of Social and Technical dimensions (often termed as Socio-Technical dependency) of such projects”.In concrete terms, this thesis investigates and measures empirically the extent to which the two dimensions of OSS projects, social and technical, approximate and influence each other during the evolution of the projects. Perceived insight is then used to build proposals that would provide empirical basis to frame theory around the affirmed proposition.Moving towards this goal, this thesis proposes models, methods, frameworks and tool supports to measure, assess, and reason the socio-technical dependency within OSS project context. The starting point is to propose a data model to mimic the social and technical dimensions and their inter-relationships. This model is instantiated through the repository data of OSS projects that represent each of these dimensions. Then, methods and a mathematical model are proposed to derive dependency between the two dimensions, and to utilize them in measuring socio-technical dependency quantitatively. These proposals are then put into practice within distinct OSS project contexts to empirically measure and investigate socio-technical dependency. Along the process, frameworks, architectural design and corresponding tool implementations are provided to automate the analysis and visualization of such dependency.Reported results suggest that high degree of socio-technical congruence can be considered as the implicit underlying principle for building team collaboration and coordination within the developer community of long lived OSS projects. Even being highly distributed community of developers, and mostly using passive communication channels, OSS communities are tied together by maintaining task dependent communication. Such communication is often ad-hoc, adaptive and situated as it cope with rapid and continuous changes in the underlying software.Additionally, collaboration among projects are significantly influenced by the resembling properties among the projects. Resembling properties (e.g., project domain, size, and programming language) often form a favorable ground, thus creating a stimuli for developers to participate in those projects

Co-Evolution of Source Code and the Build System: Impact on the Introduction of AOSD in Legacy Systems

Software is omnipresent in our daily lives. As users demand ever more advanced features, software systems have to keep on evolving. In practice, this means that software developers need to adapt the description of a software application. Such a description not only consists of source code written down in a programming language, as a lot of knowledge is hidden in lesser known software development artifacts, like the build system. As its name suggests, the build system is responsible for building an executable program, ready for use, from the source code. There are various indications that the evolution of source code is strongly related to that of the build system. When the source code changes, the build system has to co-evolve to safeguard the ability to build an executable program. A rigid build system on the other hand limits software developers. This phenomenon especially surfaces when drastic changes in the source code are coupled with an inflexible build system, as is the case for the introduction of AOSD technology in legacy systems. AOSD is a young software development approach which enables developers to structure and compose source code in a better way. Legacy systems are old software systems which are still mission-critical, but of which the source code and the build system are no longer fully understood, and which typically make use of old(-fashioned) technology. This PhD dissertation focuses on finding an explanation for this co-evolution of source code and the build system, and on finding developer support to grasp and manage this phenomenon. We postulate four "roots of co-evolution" which represent four different ways in which source code and the build system interact with each other. Based on these roots, we have developed tool and aspect language support to understand and manage co-evolution. The roots and the tool support have been validated in case studies, both in the context of co-evolution in general and of the introduction of AOSD technology in legacy systems. The dissertation experimentally shows that co-evolution indeed is a real problem, but that specific software development and aspect language support enables developers to deal with it