Explicit exception handling variability in component-based product line architectures

Bertoncello, Ivo Augusto; Dias, Marcelo de Oliveira; Brito, Patrick H. S.; Rubira, Cecília Mary Fischer

doi:10.1145/1454268.1454275

Cited by 4 publications

(6 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Similar differences in the results can be seen in Fig. 6b, d, and e. The use of aspects supports the modularisation of Exception Handling feature, which was included in R2, as well as the use of components [46,52,53]. The combined use of aspects and components improved the modularisation even more than the use of either aspects or components alone.…”

Section: Addition Of Mandatory Featuressupporting

confidence: 81%

See 1 more Smart Citation

Components meet aspects: Assessing design stability of a software product line

Tizzei

Dias

Rubira

et al. 2011

Information and Software Technology

View full text Add to dashboard Cite

Section: Addition Of Mandatory Featuressupporting

confidence: 81%

“…Regarding risk (ii), even though MobileMedia is a small SPL, it is heavily-based on industry-strength technologies, and it is a complex SPL as it can derive 200 products. Furthermore, it has been extensively used and evaluated in previous research [7,52,[60][61][62][63].…”

Section: External Validitymentioning

confidence: 99%

Components meet aspects: Assessing design stability of a software product line

Tizzei

Dias

Rubira

et al. 2011

Information and Software Technology

View full text Add to dashboard Cite

“…We selected MobileMedia for two reasons: First, it is used in numerous studies, often with software measures, for several purposes (e.g., [2], [9], [14], [17], [29], [31]). This makes it a common system to compare results and to which we can relate the results of our experiment.…”

Section: Introductionmentioning

confidence: 99%

Exploring Software Measures to Assess Program Comprehension

Feigenspan

Apel

Liebig

et al. 2011

2011 International Symposium on Empirical Software Engineering and Measurement

View full text Add to dashboard Cite

Software measures are often used to assess program comprehension, although their applicability is discussed controversially. Often, their application is based on plausibility arguments, which, however, is not sufficient to decide whether software measures are good predictors for program comprehension. Our goal is to evaluate whether and how software measures and program comprehension correlate. To this end, we carefully designed an experiment. We used four different measures that are often used to judge the quality of source code: complexity, lines of code, concern attributes, and concern operations. We measured how subjects understood two comparable software systems that differ in their implementation, such that one implementation promised considerable benefits in terms of better software measures. We did not observe a difference in program comprehension of our subjects as the software measures suggested it. To explore how software measures and program comprehension could correlate, we used several variants of computing the software measures. This brought them closer to our observed result, however, not as close as to confirm a relationship between software measures and program comprehension. Having failed to establish a relationship, we present our findings as an open issue to the community and initiate a discussion on the role of software measures as comprehensibility predictors.

show abstract

“…Although the study has analyzed the EH code of MM product line, it neither performed a feature-oriented analysis of the EH exception flows, nor discussed the fault-proneness of specific flow types related to variable features, as we have investigated in our work. Bertoncello et al (2008) propose a method for refactoring OO product line architecture in order to separate their normal and exceptional behavior into different software components. The proposed method motivates the introduction of variations points in the SPL core architecture to address different choices of exception handlers during product derivation.…”

Section: Related Workmentioning

confidence: 99%

“…As EH mechanisms are embedded in most of mainstream programming languages, it is also used in SPL engineering as a way of structuring fault detection and recovery solutions (Bertoncello et al 2008). Exception signalers and handlers can then be found spread over code assets associated to common and variable features.…”

Section: Introductionmentioning

confidence: 99%

In-depth characterization of exception flows in software product lines: an empirical study

Melo

Coelho

Kulesza

et al. 2013

J Softw Eng Res Dev

View full text Add to dashboard Cite

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.

show abstract

Explicit exception handling variability in component-based product line architectures

Cited by 4 publications

References 10 publications

Components meet aspects: Assessing design stability of a software product line

Components meet aspects: Assessing design stability of a software product line

Exploring Software Measures to Assess Program Comprehension

In-depth characterization of exception flows in software product lines: an empirical study

Contact Info

Product

Resources

About