A methodology to infer and refactor an object‐oriented model from C applications

Abstract

AND ARÉVALO 551 design of the application. The most relevant design improvements were obtained with algorithm abstraction by applying the strategy pattern, attributes/methods relocalization, variables types generalization, and removing/renaming methods/attributes. Besides a methodology and the supporting tool, we provide 14 case studies based on real projects implemented in C, and we showed how the results validate our proposal. KEYWORDS design recovery, legacy software, object-oriented paradigm, procedural language, reengineering, refactoring, reverse engineeringIn the 1970s and 1980s, companies have invested in building software systems that improve and satisfy their commercial processes (shopping, sales, accounting, etc) and their market needs. Most systems were written especially in procedural-based languages, such as Cobol, C, Fortran, Pascal, and Clipper. Even when these languages were useful in those years for the implemented domains, the procedural paradigm used in legacy systems has been replaced mainly by object-oriented (OO) ones because this latter one offers useful mechanisms to get better design, such as abstraction, polymorphism, extensibility, and reuse.The applications implemented using procedural languages are still working, but they are already legacy code. Their main problems are that they were mostly implemented in an ad hoc way or, even without following an analysis-or design-based methodology, or with the functional decomposition principle, which leads to more unstable design than the OO one. Usually, provided documentation is not enough, and stakeholders and original developers have left the software development group, taking away implicit design knowledge that is not coded in the application itself. In addition, hardware and operating systems evolve, and some versions of compilers and executable code cannot continue working in the new environments. Due to all these problems, the uncontrolled evolution of the existing software and the new requirements (that are eventually implemented in an ad hoc way) have generated legacy code, whose structure and functionality are difficult to deal with. 1 Thus, these software systems end up as black boxes, and they can represent a technical debt for the owner and the developers themselves. Although the solution for all these problems could be the replacement or the migration of the complete systems, this action is not possible because they are working currently in the companies, and they represent their actual economic capital.Current developers use the OO paradigm to implement business applications and semiautomatic methodologies/tools to analyze and refactor them. Most of these methodologies mainly apply reverse engineering techniques to perform any maintenance task. However, these solutions are not available for procedural applications, and thus, we need to provide reconstruction methodologies that help the actual developers to understand how the systems are designed. These reconstruction methodologies should generate to the developers' different ab...