Constraints: The Heart of Domain and Application Engineering in the Product Lines Engineering Strategy

Constraints: The Heart of Domain and Application Engineering in the Product Lines Engineering Strategy

Raúl Mazo (University of Antioquia & CRI Panthéon Sorbonne University, France), Camille Salinesi (CRI Panthéon Sorbonne University, France), Daniel Diaz (CRI Panthéon Sorbonne University, France), Olfa Djebbi (CRI Panthéon Sorbonne University, France) and Alberto Lora-Michiels (Baxter International Inc, Belgium)
Copyright: © 2012 |Pages: 36
DOI: 10.4018/jismd.2012040102
OnDemand PDF Download:
List Price: $37.50


Drawing from an analogy between features based Product Line (PL) models and Constraint Programming (CP), this paper explores the use of CP in the Domain Engineering and Application Engineering activities that are put in motion in a Product Line Engineering strategy. Specifying a PL as a constraint program instead of a feature model carries out two important qualities of CP: expressiveness and direct automation. On the one hand, variables in CP can take values over boolean, integer, real or even complex domains and not only boolean values as in most PL languages such as the Feature-Oriented Domain Analysis (FODA). Specifying boolean, arithmetic, symbolic and reified constraint, provides a power of expression that spans beyond that provided by the boolean dependencies in FODA models. On the other hand, PL models expressed as constraint programs can directly be executed and analyzed by off-the-shelf solvers. This paper explores the issues of (a) how to specify a PL model using CP, including in the presence of multi-model representation, (b) how to verify PL specifications, (c) how to specify configuration requirements, and (d) how to support the product configuration activity. Tests performed on a benchmark of 50 PL models show that the approach is efficient and scales up easily to very large and complex PL specifications.
Article Preview


Many experiences in the industry have shown that Product Lines engineering is an effective way to deal efficiently with reuse during analysis, design, development, test or even delivery of series of products that contain similar and varying features. Starting from 3 products, the Product Line engineering strategy has positive effects on time to market, product quality and customer satisfaction (Clements & Northrop, 2001). Product Line success stories gathered in the SPLC “Hall of Fame”1 show companies such as Boeing, Cummins, HP, Nokia, Philips Medical Systems, or Toshiba benefited from the Product Line strategy in many ways, spanning from a drastic reduction of time to market, number of defects per product, engineering effort to deploy and maintain products, combined with a substantial increase in the number of products that can be deployed. The business benefits are multiple: reduced time to revenue, higher profit margins, improved ability to aim at market windows, higher profit margins, reduced risk in product deployment, and even improved reputation of the company due to better product quality2.

The Product Line engineering strategy entails two activities: domain engineering and application engineering.

Application engineering consists in analysing, designing, building, customizing, or testing one product by reuse. Different kinds of artefacts can be reused: requirements, design fragments, architecture, code, test cases, etc. The reuse strategy is based on the exploitation of Product Line models built during domain engineering.

Domain engineering consists in specifying artefacts for reuse. This means specifying the artefacts to make them readily reusable, as well as specifying their reuse conditions. Many different specification languages have been proposed to support this. The most well known is probably FODA and its dialects (Kang et al., 1990). However OVM (Pohl et al., 2005), UML extensions (Ziadi, 2004; van der Maßen, Lichter, 2002), Dopler (Dhungana et al., 2010), the text-based variability language (TVL) (cf. Boucher et al., 2010; Classen et al., 2011), and the DSL proposed in Mannion (2002) are noteworthy alternatives as they allow specifying Product Lines with complementary viewpoints such as marketing, architecture, logistics, maintenance, etc.

In our view, the approaches that exploit these formalisms have in common that they emphasize the role of constraints at both the level of domain engineering and application engineering. Indeed, domain engineering can be seen in these approaches as the specification of variables (“features”, “attributes”, “variation points”, etc.) and constraints (“dependencies”). Application engineering then consists in defining values for these variables, while ensuring that the constraints are satisfied. Therefore, variables specify what can vary from a product to the other, in other terms the characteristics of artefacts that can be reused. On the other hand, constraints specify the reuse conditions, i.e., when artefacts can (or should) be reused or not.

Our approach is grounded on former research works that proposed to transform traditional Product Line Models (PLMs) into propositional logic (Mannion, 2002; Zhang et al., 2004; Batory 2005; White et al., 2008) or boolean constraints programs in order to reason about them (Benavides et al., 2005; Trinidad et al., 2008; Mendonça et al., 2009). As these works showed it, using traditional Product Line specification formalisms raises a series of problems:

Complete Article List

Search this Journal:
Open Access Articles: Forthcoming
Volume 8: 4 Issues (2017): Forthcoming, Available for Pre-Order
Volume 7: 4 Issues (2016)
Volume 6: 4 Issues (2015)
Volume 5: 4 Issues (2014)
Volume 4: 4 Issues (2013)
Volume 3: 4 Issues (2012)
Volume 2: 4 Issues (2011)
Volume 1: 4 Issues (2010)
View Complete Journal Contents Listing