Software Evolution of Legacy Systems A Case Study of Soft-migration Andreas Furnweger,¨ Martin Auer and Stefan Biffl Vienna University of Technology, Inst. of Software Technology and Interactive Systems, Vienna, Austria Keywords: Software Evolution, Migration, Legacy Systems. Abstract: Software ages. It does so in relation to surrounding software components: as those are updated and modern- ized, static software becomes evermore outdated relative to them. Such legacy systems are either tried to be kept alive, or they are updated themselves, e.g., by re-factoring or porting—they evolve. Both approaches carry risks as well as maintenance cost profiles. In this paper, we give an overview of software evolution types and drivers; we outline costs and benefits of various evolution approaches; and we present tools and frameworks to facilitate so-called “soft” migration approaches. Finally, we describe a case study of an actual platform migration, along with pitfalls and lessons learned. This paper thus aims to give software practitioners—both resource-allocating managers and choice-weighing engineers—a general framework with which to tackle soft- ware evolution and a specific evolution case study in a frequently-encountered Java-based setup. 1 INTRODUCTION tainability. We look into different aspects of software maintenance and show that the classic meaning of Software development is still a fast-changing environ- maintenance as some final development phase after ment, driven by new and evolving hardware, oper- software delivery is outdated—instead, it is best seen ating systems, frameworks, programming languages, as an ongoing effort. We also discuss program porta- and user interfaces. While this seemingly constant bility with a specific focus on porting source code. drive for modernization offers many benefits, it also We then outline costs and benefits of various requires dealing with legacy software that—while evolution approaches. These approaches are either working—slowly falls out of step with the surround- legacy-based, essentially trying to preserve as much ing components that are being updated—for example, as possible of the existing system, or migration-based, if a certain version of an operating system is no longer where the software is transferred, to various degrees, supported by its vendor. There are various ways to into a new setup. handle such “aging” software: one can try to keep After that, we focus on various methods for “soft” it up and running; to carefully refactor it to various migration approaches—those approaches aim to fa- degrees to make it blend in better; to port its code; cilitate traditional migration methods like porting or to rewrite it from scratch. The main stakeholders in rewriting code via support tools and frameworks. deciding on a course of action are managers, which We especially concentrate on the Java programming must allocate resources to and consider the risks and language and present a specific variant of a soft- maintenance cost profiles of the various options (e.g., migration approach, which is using a Java-based pro- will affordable developers with specific skills still be gram core with several platform-specific branches. available?), as well as software developers, which Finally, we describe a case study of an actual soft should be aware of the long-term implications of their migration of the UML editor UMLet, which is cur- choices (e.g., will a certain programming language be rently available as a Swing-based Java program and around in five years’ time?). an SWT-based Eclipse plugin, and which is ported to a web platform. We analyze some problems we en- To provide some software evolution guidelines, countered, and discuss the benefits and drawbacks of our paper first gives an overview on software evolu- the suggested approach. tion types, covering maintenance, reengineering, and whether to preserve or redesign legacy systems. We address software aging and its connection with main- 413 Fürnweger, A., Auer, M. and Biffl, S. Software Evolution of Legacy Systems - A Case Study of Soft-migration. In Proceedings of the 18th International Conference on Enterprise Information Systems (ICEIS 2016) - Volume 1, pages 413-424 ISBN: 978-989-758-187-8 Copyright c 2016 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved ICEIS 2016 - 18th International Conference on Enterprise Information Systems 2 RELATED WORK to (Feathers, 2004), this phase should be accompa- nied by extensive testing to make sure the application (Mens and Demeyer, 2008) give an overview of trends behavior stays the same. (Fowler and Beck, 1999) in software evolution research and address the evo- list useful refactoring patterns, while (Feathers, 2004) lution of other software artifacts like databases, soft- stresses how legacy code can be made testable. ware design, and architectures. A general overview of the related topics of maintenance and legacy software is given by (Bennett and Rajlich, 2000), who also 3 SOFTWARE EVOLUTION identify key problems and potential solution strate- gies. This section outlines relevant disciplines and nomen- Lehman classifies programs in terms of software clature related to software evolution. evolution and also formulates laws of software evo- lution (Lehman, 1980; Lehman et al., 1997), which 3.1 Overview are, however, not considered universally valid (Her- raiz et al., 2013). There are also many exploratory (Lehman et al., 2000) divide the view on software studies that try to analyze and understand software evolution into two disciplines. The scientific dis- evolution based on specific software projects (Jo- cipline investigates the nature of software evolution hari and Kaur, 2011; Businge et al., 2010; Zhang and its properties, while the engineering discipline et al., 2013; Ratzinger et al., 2007; Kim et al., 2011). focuses on the practical aspects like “theories, ab- (Chaikalis and Chatzigeorgiou, 2015) develop a pre- stractions, languages, activities, methods and tools diction model for software evolution and evaluate it required to effectively and reliably evolve a software against several open-source projects. (Benomar et al., system.” (Lehman, 1980) classifies programs based 2015) present a technology to identify software evo- on their relationship to the environment where they lution phases based on commits and releases. are executed. Lehman also formulates the eight laws The related topic of legacy systems is a bit am- of software evolution. Among those laws, two as- biguous, due to differing definitions. It can describe pects are emphasized: continuing change (i.e., with- a system that resists modification (Brodie and Stone- out adaption, software can become progressively less braker, 1995), a system without tests (Feathers, 2004), effective), and increasing complexity (i.e., as software or even all software as soon as it has been written evolves, its complexity tends to increase unless effort (Hunt and Thomas, 1999). A natural question regard- is spent to avoid that). According to (Herraiz et al., ing legacy systems is whether to preserve or redesign 2013), these laws have been proven in many cases, them. As this question is not easy to answer (Schnei- but they are not universally valid. dewind and Ebert, 1998), the pros and cons of reengi- neering or preserving a system are to be compared 3.2 Legacy Systems thoroughly before making a decision (Sneed, 1995). In addition, it is possible to replace a system in stages There are different definitions of what a legacy system to minimize the operational disruption of the system or legacy code is. (Brodie and Stonebraker, 1995) de- (Schneidewind and Ebert, 1998). scribe it as “a system which significantly resists mod- Even though the classic view of maintenance as ification and evolution.” (Feathers, 2004) defines it as the final life-cycle phase of software after delivery is code without tests, while (Hunt and Thomas, 1999) still prevalent, it is a much broader topic, especially state that “All software becomes legacy as soon as it’s for programs which must constantly adapt to a chang- written.” ing environment. There are reports that the total main- tenance costs are at least 40% of the initial develop- Preserve or Redesign Legacy Systems ment costs (Brooks Jr., 1995), 70% of the software budget (Harrison and Cook, 1990), and up to 90% of According to (Schneidewind and Ebert, 1998), the the total costs of the system (Rashid et al., 2009). As question whether to preserve or redesign a legacy sys- these numbers show, the topic of maintenance is cru- tem is not easy to answer. In general, most organiza- cial. (Lientz and Swanson, 1980) categorize mainte- tions do not rush to replace legacy systems, because nance activities into distinct classes. Several authors the successful operation of these systems is vital. But (Sjøberg et al., 2012; Riaz et al., 2009) propose main- they must eventually take some action to update or re- tainability metrics. place their systems, otherwise they will not be able to Finally, when migrating a system, a reengineer- take advantage of new hardware, operating systems, ing phase is almost always necessary. According or applications. 414 Software Evolution of Legacy Systems - A Case Study of Soft-migration An important aspect of this decision is that one spent on maintenance; 75% of software professionals does not have to choose an extreme solution like pre- are involved with maintenance. According to (Cole- serving a system unaltered, or redesigning it from man et al., 1994), HP has between 40 and 50 million