Big software systems which have grown over many years likely contain feature implementations which are not used (anymore). While unused code can be identified by profiling the system in production, unused features are more difficult to identify. This blog post describes three ways of identifying unused features in ABAP systems. The overall goal is to identify unused features whose code implementation can possibly be frozen or deleted (of course after careful manual inspection).
Note: I did originally publish in the following post in my company’s blog on software quality. Since it might be interesting for ABAP developers, I re-publish it here (slightly adopted).
Introduction
This section introduces code usage analysis and feature usage analysis in general. Subsequent sections describe such analyses for ABAP systems.
When a software system has evolved over many years, different situations occur that render an existing feature implementation unused: the feature becomes obsolete, unrealistic requirements induced the implementation of a feature which nobody needs, users are not aware of the feature and therefore do not use it, or features are needed only once at a specific point in time such as for migration or roll-out. When the implementation of such an unused feature remains in the code base, it has to be stored, compiled, maintained, and migrated - i.e. it creates effort for developers, sometimes repeatedly, but does not add any value.
Code Usage Analysis
To identify unused source code, we employ code usage analysis: We install a profiler in the production environment and use it to record which parts of the code get executed. Then we visualize used and unused code regions and thereby enable developers to analyze which parts of their code base are not used. Two aspects are important to consider when setting up the profiling: First, to introduce only minimal performance overhead in the production environment, and second, to collect representative data. To minimize performance overhead, we record code execution on the level of methods. Furthermore, we use technology-specific ways to further minimize performance overhead. To ensure representativeness of execution data, we record code execution for several months and make sure to target important time intervals like the time of the year-end closing.
Feature Usage Analysis
While setting up the technical infrastructure for code usage analysis and collecting representative data requires time and effort, it is not complicated to do. Targeting unused features instead of unused code is more complicated because it requires abstraction from code. Information about unused features is required if the target group of the usage analysis are users, managers, or testers — people who are not familiar with code — and is helpful to group several unused code regions. The naive approach for feature usage analysis is to have developers analyze unused code regions and do the abstraction from code to features manually. Obviously, this is possible in all contexts but introduces effort for development teams which are usually under time pressure anyway. Hence, we developed an automated approach.
As we have the infrastructure to record code execution already, we want to reuse it. Furthermore, introducing dedicated monitoring code to the code base was not an option because it would induce effort for developers and performance overhead for profiling. Our general idea is to define a characteristic method for each feature, i.e. we assume when the characteristic method is executed once, the feature is used once. This approach allows to abstract from code to features and to reuse execution data from code usage analysis. Usually, it is difficult to find such characteristic methods for every feature in an arbitrary system. Hence, we use specific framework methods as characteristic methods. In the following, we describe how we implemented this idea for ABAP systems.
Code Profiling for ABAP Systems
Code execution on ABAP systems can be recorded easily because each ABAP system has the SAP Coverage Analyzer natively installed. It is deeply integrated into the kernel of the NetWeaver Application Server and therefore introduces minimal performance overhead. To collect code execution data, it has to be activated on the production system. Then, the execution of all methods, programs and function modules is recorded and the execution data is stored in the database. We use the Coverage Analyzer in Lite mode which records code execution on method level to minimize performance overhead.
Feature Usage Analysis 1: Central Methods, Classes or Reports
When a characteristic method for a particular feature is already known, only its execution count has to be retrieved to see how often the feature has been used. Candidates for characteristic methods are central methods like run() or process(), the constructor of a central class, or the »start of selection« event block of a central report.
Feature Usage Analysis 2: ABAP Transactions
The first ABAP-specific mechanism we use for feature usage analysis are ABAP transactions. By defining transactions, developers make features accessible to users. A definition of a transaction consists of three parts: the transaction name, the transaction code, and a program that is executed when the transaction is invoked by the user. Because a transaction defines a mapping from a user-visible feature to source code, we can use it for feature usage analysis: We consider the transactions to be features and for each transaction retrieve the execution count of its program. This tells us how often a transaction was executed and therefore how often users used the corresponding feature.
Please note that this approach makes a simplifying assumption: It assumes that the program of a transaction is triggered only by the transaction while in reality the program might be triggered by other means, too.
Feature Usage Analysis 3: Business Add-Ins (BAdIs)
The second ABAP-specific mechanism we use for feature usage analysis are Business Add-Ins (BAdIs). SAP developers use BAdIs to define explicit points in their code where non-SAP developers can extend the standard functionality. When a developer of custom code implements a BAdI method with own code, his or her code is executed whenever the BAdI method is executed. By specifying a BAdI method, SAP developers define an entry point to a specific part of custom code. Hence, we consider BAdI methods to be features and retrieve their execution count by analyzing implementations of BAdI methods and their execution counts (which we have from code usage analysis). This tells us how often each BAdI method was executed and therefore how often users used the corresponding feature.
Conclusion
This blog post described one generic and two ABAP-specific approaches for feature usage analysis by abstracting from code execution to feature execution. As there are several other mechanisms for extending ABAP standard code — e.g. Gateway Services or WebDynpro Screens — other but similar approaches have to be used for them.
The overall goal of feature usage analysis is to identify unused features whose code implementation can possibly be frozen or deleted (of course after careful manual inspection).
