Abstract

Software Product Lines (SPLs) play an essential role in contemporary software development, improving program quality and reducing the time to market. However, despite its importance, several questions concerning SPL dependability did not get enough attention yet, such as: how the exception handling code has been implemented in SPLs? The characteristics of the exception handling code may lead to faulty SPL products? The Exception Handling (EH) is a widely used mechanism for building robust systems and is embedded in most of mainstream programming languages. In SPL context we can find exception signalers and handlers spread over code assets associated to common and variable SPL features. If exception signalers and handlers are added to a SPL in an unplanned way, products can be generated on which variable features may signal exceptions that remain uncaught or are mistakenly caught by common features or other variable features. This paper describes an empirical study that categorizes the possible ways exceptions flow through SPL features and investigates whether some of their characteristics can lead to faulty exception handling behavior. The study outcomes presented in this paper are helpful in several ways, such as: (i) enhancing the general understanding of how exceptions flow through mandatory and variable features; (ii) providing information about the potential problems related to specific kinds of flows detected in this study; and (iii) presenting how a static analysis tool can be used to support the identification of potentially faulty exception handling flows.

Highlights

  • Software product line engineering advocates the development of software system families from a specific market segment (Clements and Northrop 2001)

  • This paper extends the previous study in the following ways: (i) a new medium-sized product line was analyzed, called Prevayler (Godil and Jacobsen 2005), which implements an open-source memory database configurable system that allows persisting serializable Java objects; (ii) an in-depth analysis of each flow was performed, which besides considering the exception signaler and handler to categorize each flow, reports about the intermediate elements that compose the exception flows; (iii) a new version of the static code analysis tool was implemented in order to support the indepth analysis of each flow; (iv) this work presents an uncaught exception analysis for each software product line (SPL) and it discusses about the fault-prone scenarios that may occur in SPL products in the exception handling context

  • In order to obtain a more fine-grained view of how exceptions are signaled and handled inside SPLs, we performed an in-depth analysis of each flow on which: (i) we investigated the intermediate methods that composed the exception flows call chains – this analysis was based on manual inspection and guided by results provided by PLEA static analysis tool; and (ii) we analyzed how the flow types that are related could lead to faulty or inadequate exception handling behavior

Read more

Summary

Introduction

Software product line engineering advocates the development of software system families from a specific market segment (Clements and Northrop 2001). A system family is a set of programs that shares common functionalities and maintain specific functionalities that vary according to specific systems being considered (Parnas 1976). A software product line (SPL) is specified, designed and implemented in terms of common and variable features. A feature (Czarnecki and Eisenecker 2000) is a system property or functionality that is relevant to some stakeholder and is used to capture commonalities or discriminate among systems in SPLs. A SPL is developed through of a design of an extensible software architecture and subsequently implemented in terms of reusable code assets that address its common and variable features. The SPL development approach promotes benefits such as cost reduction, product quality, productivity and time to market (Clements and Northrop 2001). It may bring new challenges to the software dependability

Objectives
Methods
Findings
Conclusion

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.