Recommending Mechanisms for Modularizing Mobile Software Variabilities

Recommending Mechanisms for Modularizing Mobile Software Variabilities

Márcio Ribeiro (Federal University of Pernambuco, Brazil), Pedro Matos (Federal University of Pernambuco, Brazil) and Paulo Borba (Federal University of Pernambuco, Brazil)
DOI: 10.4018/978-1-61520-655-1.ch018
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Software Product Lines (SPLs) encompass a family of software systems developed from reusable assets. One issue during SPL maintenance is the decision about which mechanism should be used to restructure variabilities aiming at improving the modularity of the SPL artifacts. Due to the great variety of mechanisms (inheritance, configuration files, aspect-oriented programming), selecting the incorrect ones may produce negative effects on the cost to evolve the SPL. To reduce this problem, the authors propose a Decision Model to help developers to choose mechanisms to restructure variabilities in SPLs. Their model was developed based on two domains: mobile test scripts and J2ME games. When using the model, developers may improve the variabilities’ modularity, the SPLs design, and remove bad smells such as cloned code.
Chapter Preview
Top

Introduction

Software Product Lines encompass a family of software-intensive systems developed from reusable assets (known as core assets). By reusing such assets it is possible to construct a large scale of products through specific variabilities defined according to customers' requirements (Pohl, Böckle, & van der Linden, 2005). On the other hand, implementation activities become more complex because they also have to realize variabilities (Patzke & Muthig, 2002).

In this context, reasoning about how to combine both core assets and product variabilities is a challenging task (Anastasopoulos & Gacek, 2001). In other words, the challenge consists of understanding the available mechanisms - such as Inheritance, Configuration Files, Aspect-Oriented Programming (Kiczales, et al., 1997), and so forth - for realizing variability and knowing which of them fits best for a given variability (Patzke & Muthig, 2002). Previous work (Kolb, Muthig, Patzke, & Yamauchi, 2005) (Alves, Matos Jr, Cole, Borba, & Ramalho, 2005) has structured product line variabilities by using only one mechanism. Because each mechanism has strengths and weaknesses, not all variabilities were well structured when considering modularity criteria, for example.

Due to the great variety of available mechanisms, selecting an incorrect mechanism may produce negative effects on the cost to maintain the SPL (Ribeiro, Matos Jr, Borba, & Cardim, 2007). For example, cloned code and concerns not modularized may appear, affecting independent evolution of SPL artifacts, increasing developer's effort, and consequently decreasing productivity when evolving the SPL.

The problem of combining core assets and SPL variabilities exists not only at source code, but also in other artifacts such as requirements and tests. In order to reduce the aforementioned problems, we have defined a Decision Model encompassing two different domains. Such model is supposed to help developers on the task of choosing mechanisms to restructure variabilities in SPLs. To construct our decision model, we analyzed real variabilities found in two different domains: Motorola mobile phone test scripts and J2ME games from Meantime Mobile Creations1. The test variabilities analyzed were handled by using if-else statements whereas the J2ME games variabilities are implemented using conditional compilation. The motivation to restructure them is that both approaches do not provide modularity at all; variabilities are not separated from core assets. Our model aims at suggesting mechanisms so that these variabilities can be modularized, being important to improve the product lines' design.

The main contributions of our work are:

  • a.

    A Decision Model for improving guidance of developers in SPL maintenance. Existing models (Anastasopoulos & Gacek, 2001) (Patzke & Muthig, 2002) consider a high level approach that rely basically on feature types. In contrast, we provide a decision model which is code-centric and more fine-grained. Because we consider not only the feature type, but also the exactly variability location at the source code and some criteria, our recommendations may be more precise. In addition, we discuss some particularities and similarities between the domains when defining the model. Given the different natures of them, we believe our model may be applied in other domains as well;

  • b.

    In order to analyze the advantages and disadvantages of each mechanism, we have calculated some metrics (Sant’Anna, Garcia, Lucena, & von Staa, 2003). Because those metrics are supposed to deal with single products, we have defined new metrics to encompass SPLs, representing another contribution of our work.

Key Terms in this Chapter

Bytecode Size: Final size of a system after the compilation. The smaller the bytecode is, the better is for a mobile application due to its limited resources.

Binding Time: The time in which a feature is bound to the product. A feature might be bound at compile-time (at the moment where the product is being compiled) or at runtime (the feature starts working when the software is running).

Software Modularity: Software design technique used to decompose the software into modules. Each module is responsible for implementing a relevant part of the system, separating that module from the others parts of the software, improving the understandability and maintainability of that module.

Aspect-Oriented Programming (AOP): Programming style that allows developers to modularize crosscutting concerns. Such concerns are in general scattered and tangled throughout many modules of the system, being hard to maintain them. This way, when using AOP, a unit called aspect is responsible for implementing these concerns in one place instead of many, reducing the scattering and the tangling of the concern.

Software Product Line: A set of systems (products) of a common family. The systems have commonalities - since they are constructed using the same infrastructure - and variabilities, which makes possible the mass customization, so that many products of a family may be generated automatically.

Feature: A functionality used to differ products in a product line.

Design Pattern: General solution for a common problem that occurs when designing software. A design pattern is reusable, so that it might be applied in many systems that suffer of a common problem.

Complete Chapter List

Search this Book:
Reset