Splitting a large software repository for easing future software evolution—an industrial experience report

Abstract

SUMMARYPhilips Medical Systems produces medical diagnostic imaging products, such as MR, X-ray and CT systems. The software of these devices is complex, has been evolving for several decades and is currently a multi-MLOC monolithic software repository. In this paper we report on splitting a single software repository into multiple smaller repositories so that these can be developed independently, easing the software's evolution. For splitting the single software repository, we set up two experiments that involve well-known analysis techniques, namely formal concept analysis and clustering. Because of the sheer size of the monolithic software repository, we also propose to use a 'leveled approach', which implies that the analysis technique is applied in several iterations, whereby in some iterations only part of the application is subjected to the analysis technique. Unfortunately, both analysis techniques failed to produce an acceptable partitioning of the monolithic software repository, even if they are combined with our newly proposed leveled approach. We provide a number of valuable lessons learned, which might prevent others from falling into the same pitfalls.

Supervised software modularisation

“…However, in any case the use of SUMO (even for a small number of iterations) is likely to lead to significant improvements in the final modularisation. This clearly addresses weaknesses in existing unsupervised techniques, as described by Glorie et al [9], where there is a desire to refine modularisations by feeding-in domain knowledge.…”

“…The rationale for this work is captured by an observation by Glorie et al [9]. In their work on applying the most popular software clustering approach (Bunch [3]) alongside an FCA-based approach in an industrial context (Philips Medical Systems), they observed that these unsupervised clustering approaches tended to produce results that were "'non-acceptable' for the domain experts".…”

Establishing the Source Code Disruption Caused by Automated Remodularisation Tools

“…Despite over two decades of research into automated software remodularisation tools [1], [2], their transfer into industrial use has been very limited [3]. Previous papers have focussed on addressing the key perceived hindrance-that the proposed changes often fail to make sense with respect to the underlying domain model of the system [3].…”

A practice-driven systematic review of dependency analysis solutions

“…Second, many solutions are for supporting activities that facilitate change impact analysis, e.g., change prediction (Hassan and Holt 2004;Kagdi and Maletic 2007;Law and Rothermel 2003b), identification of dependence clusters and dependence pollution (Binkley and Harman 2005), dynamic impact analysis in object-oriented programs (Huang and Song 2007), identification of class change profiles (Xing and Stroulia 2006), impact of database schema change (Maule et al 2008), and efficient source code navigation (Robillard 2008). Third, a number of other solutions are presented to support change impact on development aspects such as the relation between evolvability and modularity (Breivold et al 2008), independent development (Glorie et al 2009), and requirement change impact on architectural elements (Khan et al 2008).…”

“…A variety of static analysis techniques are used by dependency solutions to discover and organize dependency information in graphs and matrices. These techniques are approximation algorithms (Zhang and Ryder 2007), context-sensitivity dataflow (Maule et al 2008), formal concept analysis and clustering (Glorie et al 2009), island grammars (Cossette and Walker 2007), searchbased slicing (Jiang et al 2008), source code navigators for heterogeneous code (Moise and Wong 2005), topology analysis (Robillard 2008), and annotations and navigation models (Holmes and Walker 2007). The goal of these techniques is to reflect the system structure and highlight patterns and problematic relationships that practitioners deal with through various application areas (see Table 4).…”