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 which we have developed recently.

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 (see Andreas’ blog post for a more detailed introduction): 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 ( Juergens et al.: Feature Profiling for Evolving Systems, ICPC’11). 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.

For example, we use this approach to monitor how often our add-on »Teamscale Adapter« is executed. It runs periodically, exports custom code from the ABAP System and sends it to Teamscale for analysis. The add-on has a central class that is instantiated every time it is executed. We can analyse how often the add-on was used by retrieving the execution count of the central class’ constructor.

Feature Usage Analysis 2: ABAP Transactions

The first ABAP-specific mechanism we use for feature usage analysis are transactions. ABAP transactions are — unlike e.g. financial transactions or database transactions — a way for users to quickly access features of the ABAP system. Each transaction has a transaction code, i.e. a short combination of letters and numbers, which the user uses to access a feature. The following figure exemplarily shows a user entering transaction code ‘SE80’ and thereby opening the source code editor of the ABAP system.

Figure 1: Transaction »ABAP Development Workbench« with transaction code »SE80«

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). BAdIs are an extension mechanism for standard functionality implemented by SAP. SAP developers use BAdIs to define explicit points in their code where non-SAP developers can extend the standard functionality. A BAdI is similar to an interface as it also defines methods which can be implemented. 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. For example, the following figure shows the implementation ZBAB_CODE_INSPECTOR of BAdI CTS_REQUEST_CHECK. Code implementing its method CHECK_BEFORE_RELEASE is executed whenever a user marks his or her development task as completed.

Figure 2: Implementation ZBAB_CODE_INSPECTOR of BAdI CTS_REQUEST_CHECK

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. In the example, we obtain a counter value representing how often users completed a development task.

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 — as well as many frameworks for other programming languages, we will continue to develop such ways of feature usage analysis and incorporate them into our software intelligence suite Teamscale.

If you are interested in code or feature usage analysis and want to try it out on your system, please get in touch with me.

References and Further Reading

• Blog post by Andreas Goeb: How Much of Your Code Do You Actually Use?
• Juergens et al.: Feature Profiling for Evolving Systems, ICPC’11
• Eder et al.: How much does unused code matter for maintenance?, ICSE’12
• Teamscale Homepage