Assessment of software module upgrade complexity

Abstract

ASML develops and builds advanced photolithography systems, used by major semiconductor manufacturers. The software on these systems controls every aspect of the machine and various releases of this software are continuously updated. When multiple releases of the software need the same software change, the change needs to be synced with other releases. This step is the process of manually integrating a change into another release than it was initially written for. However, syncing changes requires a significant amount of developer effort. To reduce the time which is spent on syncing, ASML investigates to upgrade a system by upgrading modified software modules as a whole, rather than applying a patch to the system. This approach is more course-grained: upgrading a module may include more changes than a patch would provide. To make module-based upgrades work, modules should be independent to an extent such that they can be easily upgraded without the need to upgrade others. If it turns out that the software is structured in such a way that a change requires an upgrade of many other modules, the idea to upgrade on a modular basis does not provide an advantage over the current method of applying changes. In this study, the independence of modules is assessed by looking at which functionality they provide through an interface, and which functionality they require from other modules. While interfaces consist of two parts -syntax and behavior - this study is limited to the syntactical part only. This involves gathering information about which symbols are provided and required by the modules. Example symbol types are functions or constants that can be exported through an interface. Once the symbol information for each module has been obtained, a hypothetical upgrade can be performed by upgrading an older module in a system to the latest version. All additional modules which have to be upgraded to satisfy all dependencies are referred to as upgrade dependencies. When a module is included as an upgrade dependency, it is not strictly necessary to upgrade it to the latest version. The module can be upgraded to any newer version that provides at least the symbols which are required from other modules. Because each version of a module may have a different set of dependencies on other modules, there may be different upgrade paths. The goal is to find the upgrade path with the minimal set of upgrade dependencies, assuming that the number of upgraded modules is proportional to the risk involved (such as the risk of introducing regressions). This calculation is repeated for each module in the system, by upgrading each older version of that module to the latest version. This gives an overview on which modules are difficult to upgrade, and at which version the difficulties started. The results are presented in a two-level visualization. At the highest level, the results are presented as a heat map, where each cell represents an upgrade of a module from an older version to the latest version. The cell color reflects the number of upgrade dependencies for that upgrade path. At a lower level, a single upgrade path can be visualized using a directed graph, containing a vertex for each upgrade dependency. An edge (A,B) is added to the graph if and only if module B is an upgrade dependency of module A. This graph allows the user to study how the upgrade dependencies are related, and what can be possibly done to reduce the upgrade dependencies. For this study, a framework has been developed to assess the independence of a modular software system. This framework provides a means to gather symbol usage between modules, the calculation of the minimal dependency set and the visualization. In this implementation, only the first part of the framework makes assumptions on the architectural concepts and data formats at ASML. The framework can be deployed to investigate other software systems, provided that specific tooling is written which collects the usage information in that particular environment. By analysing the software at ASML with this framework, a number of recommendations were made to improve the independence of modules. Implementing these recommendations helps ASML to ease module upgrades to future versions.

Date of Award	31 Aug 2012
Original language	English
Supervisor	Alexander Serebrenik (Supervisor 1), Niels van den Broek (External coach) & Istvan Nagy (External coach)