From Requirements to Architecture for Software Product Lines

Keivilany Coelho

Computing Department

Federal University of Rio Grande do Norte (UFRN)

Natal (RN), Brazil

keivyc@gmail.com

Thais Batista

Computing Department

Federal University of Rio Grande do Norte (UFRN)

Natal (RN), Brazil

thais@ufrnet.br

Abstract—To ensure a consistent correlation between the

requirements model and the architecture representation of Software Product Lines (SPL), this paper proposes an integration between goal models (described in PL-AOV-

Graph) and architectural specification (described in PL-AspectualACME). We define the mapping process between these models and transformation rules between their elements. We also present a case study (e-commerce system), to evaluate

the mapping process.

Keywords- Requirements Model, Architectural Model, Software Product Line, Variations.

I. INTRODUCTION

Variabilities in Software Product Lines are modeled using several approaches, such as feature models, which are, according to [1], feature diagrams with additional information about description of features and relationships rules. In feature models, the SPL requirements are represented by mandatory, optional, and alternative features.

On the other hand, in terms of software requirements, goals models [9] are often used to express functional and non-functional requirements. Batista et al (2010) [1] proposed the integration between feature models and goals models, to have a broader representation of SPL requirements. They also presented PL-AOV-Graph, an aspect-oriented goal model that extends AOV-Graph model [8] for the SPL domain. The integration of these two models takes advantage of the aspect-oriented abstractions offered by PL-AOVGraph to represent the variabilities as crosscutting concerns and to define crosscutting relationships between the elements.

In the SPL development, it is important to represent variabilities with modelling approaches such as those abovementioned, but it is also important to have proper support for the later stages of the software lifecycle activities, such as architecture. The architecture of a system can be described by an Architectural Description Language (ADL), which defines the software components and its interconnections. PL-AspectualACME ADL [3] is an extension of AspectualACME [2] for the specification of SPL architectures.

In this context, in this paper we propose a process that integrates requirements and architecture specification of SPL. The process defines a bidirectional mapping between goals models and SPL architectural description, in PL-

AspectualACME, to ensure that software architecture nicely meets software requirements. The purpose is to generate architectural description from goals models and vice versa, based on mapping rules and using the process defined in this work. The purpose is to maintain traceability between requirements model and architecture specification.

This paper is structured as follows. Section II presents the basic concepts of this work. Section III presents a background on architectural description languages. Section IV presents our running case study. Section V presents the process and rules that we propose to map SPL goal models into architecture models. Section VI contains the case study. Section VII presents a brief discussion about the resultant models of the transformation. Section VIII contains the final remarks.

II. BASIC CONCEPTS

In SPL engineering, the variability management is important to reduce the inherent risks of the initial SPL development [6]. Variabilities are expressed through several existent models, among which, feature models, which were proposed as part of Feature-Oriented Analysis Method (FODA) [5]. Figure 1 depicts an simple example of the feature model.

Feature models represent mandatory, optional, or alternative (inc-or or xor) features. Mandatory features (F2, F3, F4, F5, and F8, in Figure 1) represent an attribute or a functionality that is common to all SPL’s products. Optional features (F1, in the figure) are present only in a few SPL’s products. Alternative features xor (F6 and F7) offer options to choose which one and only one subfeature of the set should be selected. Inc-or features (F9, F10, and F11) require that at least a subfeature must be chosen, but it is allowed to select more than one feature.

Goals models are approaches that express functional and nonfunctional requirements of a system, with goals decomposition, which aims to show how to satisfy a goal, using, when necessary, subgoals [9].

The V-Graph goal model [9] represents textual and graphical elements (tasks, goals, softgoals) and the relations between these elements (contribution and correlation relationships), in a tree hierarchy. Contribution relationships may be of ‘and’ type (mandatory elements), ‘or’ type (optional elements), and ‘xor’ types (only one of the elements of the relationship can be satisfied).

2011 Ninth Working Conference on Software Architecture

978-0-7695-4351-2/11 $26.00 © 2011 IEEE

DOI 10.1109/WICSA.2011.60

282

2011 Ninth Working IEEE/IFIP Conference on Software Architecture

978-0-7695-4351-2/11 $26.00 © 2011 IEEE

DOI 10.1109/WICSA.2011.60

282

Figure 1: Feature Model Example

Correlation relationships express interaction among elements (such as interfering with each other positively or negatively), and may be of ‘make’ type (an element exists only if the other also exists), ‘break’ type (an element precludes the existence of the other), ‘help’ type (an element reinforces the other), ‘unknown’ type (there is an influence, but we cannot determine whether it is positive or negative) and ‘hurt’ type (a requirement affects the other one).

AOV-Graph [8] is an extension of that goal model, which adds crosscutting relationships to modularize crosscutting concerns. PL-AOV-Graph [1] is an extension of AOV-Graph for the SPL domain which adds the ‘inc-or’ contribution relationship, in addition of new properties: ‘isFeature’ (determines whether a goal, softgoal, or task must be represented as a feature in the SPL feature model); ‘typeFeature’ (that indicates the type of feature that a goal, softgoal or task will to represent in the feature model); ‘groupFeature’ (defines which features are grouped); and ‘cardinality’ (represents the cardinality of features and groups of features). ‘Cardinality’ property may be ‘cardinalityMin’, ‘cardinalityMax’, ‘cardinalityGroupMin’, or ‘cardinalityGroupMax’ types.

Figure 2 depicts a generic goal model represented in PL-AOV-Graph, both textual and graphical description).

Similar to the feature model presented in the previous section, the goal model of Figure 2 has a root (named ‘Goal Model’). Furthermore, it has three tasks, which are: T1 (with ‘or’ contribution relationship), T5 (with ‘and’ contribution relationship) and T8 (also with ‘and’ contribution relationship), each with subtasks and ‘and’ contribution relationships (T2, T3, T4), ‘xor’ contribution relationships (T6 and T7) and ‘inc-or’ contribution relationships (T9, T10 and T11). The model also has a softgoal (Sg1), with an ‘and’ contribution relationship.

III. ARCHITECTURAL DESCRIPTION LANGUAGES

Architectural Description Languages (ADL) are used to describe software architecture in terms of components, connectors, and configurations. An ADL may be a formal or semi-formal language, can be descriptive, graphical, or both.

In industry or academy, there are several ADLs in various application domains. The ACME ADL [4] provides a mechanism for architectural information exchanging. Its

elements are components (basic elements), connectors (model interaction between components), ports (components’ interfaces), roles (connectors’ interfaces ), system (graphs whose nodes are components and edges are connectors), representation (internal description of a component), bindings (make the correspondence between the internal representation of an element and its external interface) and attachments (describe how components are connected through connectors).

In addition to the structural elements, ACME defines properties that include additional information about any element, except attachments, via a triple (name, type, value). There are also ‘Type’ and ‘Family’ constructs, which are used to define a vocabulary of abstract types for the elements and to define architectural styles in terms of abstract types of elements, respectively.

AspectualACME [2] extends ACME to support aspect orientation by including an aspectual connector and quantification mechanisms. The Aspectual connector has three elements that define the semantics of connections between components: (i) ‘Base role’, which connects to ports of regular connectors; (ii) ‘Crosscutting role’, which connects to ports of aspectual connectors; and (iii) ‘Glue clause’, which is the composition between a base role and a crosscuting role, and defines where a regular component will be affected by an aspectual connector, for instance.

The quantification mechanisms syntactically simplify

references to various joinpoints in the architectural

description. They are inserted in the attachments using

wildcards, which mean component names or pieces of

component names and their ports (depicted with ‘*’

symbol). Quantification is used in the connection between

base role and aspectual connector and one or more regular

components.

PL-AspectualACME [3] is an extension of

AspectualACME, which semantically enriches a few

elements of ADL, describing a new architectural style to

SPL, but it does not add new elements. To represent feature

interactions (constraints) in SPL, PL-AspectualACME also

uses elements of Armani [7] – a predicate language based

on first-order logic that also is part of ACME.

283283

Figure 2: Goal Model Example

Armani express architectural constraints on ACME elements, using invariants (constraints that must be satisfied) and heuristics (advices that may or may not be followed). Armani elements include: universal quantifier (forall), existential quantifier (exists), and a construct that allows definitions of new functions (Analysis). Further details of Armani can be found in [7].

PL-AspectualACME constructs comprise:

• Family – extension of the ACME ‘Family’ element. It defines the ‘ProductLine’ architectural style for SPL;

• Component Type – extension of the ACME ‘type’ element. It encapsulates optional (Component Type Optional), alternative (Component Type Alternative), and inclusive-or (Component Type Inclusive-Or) variation points;

• Representation – extension of the ACME ‘representation’ element. It encapsulates the variants;

• Select Port – extension of the ACME ‘port’ element. It abstracts the variants’ selection mechanism;

• Selected_variants – extension of ACME ‘property’ element. It indicates the chosen variants to a selected port;

• Analysis requires – extension of the Armani ‘Analysis’ predicate. It defines feature interactions of type ‘A requires B’; and

• Analysis excludes – extension of the Armani ‘Analysis’ predicate. It defines feature interactions of type ‘A excludes B’.

The architectural style (ProductLine) defined serves as a template for specifying SPL architectures and the PL-AspectualACME elements above described are used to model variabilities. Similarities are, then, shaped as components or regular ports. Figure 3 presents a small example of PL-AspectualACME, (both textual and graphical representation).

In the generic example shown in Figure 3, the Product Family called ‘Exemplo’ has a Component Type named ‘Comp’, that is mandatory (which is set on its property) and has two ports: (i) C1, which connects Comp to C1 component and it is mandatory; and (ii) C2, which is a Select Optional port and it abstracts the selection or non-selection of the C2 component (which is optional). Since C2 has internal components (C3, C4, and C5), we use the Representation element, which contains the system Sys, which encapsulates the C2 component and the three ports that connect C3, C4, and C5 components. Since these latter components are all mandatory, the C2 optional port should be connected to all of them. If the C2 port is selected, all C2 internal components will also be selected. Bindings are used to abstract the connection from the C2 port to the C3, C4, and C5 ports. The graphic representation in Figure 3 is merely illustrative, for a better understanding.

Figure 3: PL-AspectualACME Example

284284

IV. E-COMMERCE

Our case study, an E-Commerce system, represents business transactions via internet. Figure 4 depicts the feature model of this system. The E-commerce system contains four mandatory features: Payment, Shipping, Password Policy, and Security. Payment corresponds to the payment procedure. It has two subfeatures: FraudDetection (mandatory) and PaymentTypes (optional). PaymentTypes, on the other hand, has three inclusive-or subfeatures: DebitCard, CreditCard and PurchaseOrder, which determine possible payment types.

Shipping is about the delivery process. It has two inclusive-or subfeatures: CustomMethods, which includes ‘the Method’ feature, with cardinality 1..*, and Shipping Gateways.

PasswordPolicy contains the following subfeatures: Expiration and Chars. Expiration has two children: inDay and Never.. Chars has alternative features: Digits, SpecialChars, UpperCase, and LowerCase, with cardinality 2..4.

Figure 4: E-Commerce Feature Model

A. The E-Commerce Goal Model

Figure 5 shows the PL-AOVGraph model of the e-Commerce system. According to the e-commerce feature model, presented in the previous section, its goal model has the Payment tasks (with the ‘and’ contribution relationship), Shipping ( ‘and’ type), PasswordPolicy (‘and’), and the Security softgoal (with the ‘and‘ relationship). The Payment task has the subtasks FraudDetection (‘and’) and PaymentTypes (type ‘and’ and with inc-or subtasks: DebitCard, PurchaseOrder and CreditCard). The Shipping task has the subtask CustomMethods (type ‘inc-or’), which

includes the Method (String) task, with minimum cardinality 1 and maximum cardinality n. Moreover, the Shipping task also comprises the inc-or ShippingGateways task. The PasswordPolicy task contains the Expiration task (type ‘and’, with xor subtasks: inDay and Never) and Chars task (‘and’), which contains grouped features, with minimum cardinality 2 and maximum cardinality. They are: Digits, UpperCase, LowerCase, and SpecialChars. This paper will refer to these grouped features with inc-or type relationship, that is closest to that cardinality.

Figure 5: E-Commerce PL-AOVGraph Model

285285

B. The E-comerce Architectural Description

Figure 6 shows a part of the e-commerce system in PL-AspectualACME.

The architectural description is composed, as previously described, in terms of components, connectors, ports, roles, bindings, attachments, and representations. The root element is represented by the ACME Family element. First level features of feature model are Component Types, in the architectural description. Lower levels features are abstracted by ports. Properties define element types as mandatory, optional, alternative, inclusive-or and also defines their cardinality. The select port abstracts away the selection mechanism of the features that are not mandatory. The bindings configure this selection.

V. PROCESS OF MAPPING THE GOAL MODEL INTO AN

ARCHITECTURAL DESCRIPTION

This section defines the process that defines the mapping between goal models and architectural descriptions proposed in this work.

A. The Process

The mapping process starts with a PL-AOV-Graph model (generated from the feature model, following the rules defined in [1]). Figure 7 depicts the sequence of activities of this process.

Initially, there is an existing PL-AOV-Graph model, generated from the feature model). Using the rules defined in this work (see Subsection B), this model is mapped into a PL-AspectualACME specification.

Figure 6: Partial PL-AspectualACME Description of E-Commerce

The PL-AspectualACME generated model can be used as an input to perform a backward transformation, in order to verify the consistence between requirements and architecture. In summary, to ensure that the architecture description meets the specified requirements.

In the second flow, an existent PL-AspectualACME specification is used in a reverse engineering process to generate, using the mapping rules, the PL-AOVGraph model. Then, the generated PL-AOV-Graph can also be used to generate PL-AspectualACME..

B. Mapping

The mapping proposed in this paper is based on a set of rules described in this section.

1) Mapping Rules Table 1 summarizes the mapping rules between PL-

AOVGraph and PL-AspectualACME models, relating their elements with the elements of the feature model..

Figure 7: Bidirectional Mapping Process

Based on the rules, the transformation process between PL-AOVGraph and PL-AspectualACME follows the steps represented in Figure 8.The steps to generate a PL-AspectualACME specification from a PL-AOVGraph model are:

286286

TABLE I. MAPPING RULES

PL-AOVGraph

���� ���� Feature Model ���� ���� PL-

AspectualA

CME

Goal Model � � Root Feature � � Family

ProductLine

Task, Goal,

SoftGoal � � Feature � � Component

Hierarquia de

tasks, goals e

softgoals

� � Hierarquia de

features � �

Representati

on

Or Contribution � � Optional

Feature � �

Component

Type

Optional

And

Contribution � �

Mandatory

Feature � � Component

Xor

Contribution � �

Alternative

Feature � �

Component

Type

Alternative

Inc-or

Contribution � �

Inclusive-Or

Feature � �

Component

Type

Inclusive-Or

Correlation

Break � �

Constraint

“implies the

non-selection”

� �

Analisys

Excludes

(Armani)

Correlation

Make � �

Constraint

“implies” � �

Analisys

Requires

(Armani)

Correlation

help, hurt,

unknown

� � � � Property

Crosscutting

Relationship � � Cross Relation � �

Attachments

, Aspectual

Connector

Task_ref,

goal_ref,

SoftGoal_ref

� � References � � Selected_Va

riants

Property

[CardinalityMin

,

CardinalityMax,

cardinalityGrou

pMin,

CardinalityGrou

pMax]

� � Cardinalidade � � Property

Property

[isFeature,

typeFeature,

groupFeature]

� �

Feature,

Grouped

Feature

� � Property

1. The Goal Model, corresponding to the root of the feature model, is transformed into a PL-AspectualACME Family. 2. Tasks, goals, and softgoals hierarchy is transformed into components, ports, and representations, according to the position of each element in the hierarchy of the feature model. First level elements on the hierarchy are transformed into Component Types. At the right bottom level, they are transformed into ports. If there are variation points levels below, they are transformed into representations that encapsulate systems, components, ports, and bindings. Each element includes properties that are not required elements in PL-AspectualACME However, it facilitates the tracing between the models, allowing the inverse transformation.

3. AOVGraph pointcuts and intertype declarations are transformed into AspectualACME ports and bindings (pre-xisting rule) 4. The PL-AOVGraph Correlation ‘Break’ property is transformed into Armani´s analysis ‘excludes’ constraint. The PL-AOVGraph Correlation ‘Make’ is transformed into Armani analysis ‘requires’ constraint. The other correlation (help, unknown, and hurt) properties are transformed into properties in PL-AspectualACME, because they affect the elements in an indirect way. 5. Crosscutting relationships are transformed into connectors and attachments (pre-existing rule) 6. And, or, xor, and inc-or contribution relationships are respectively transformed into component, component type ‘optional’, component type ‘alternative’, and component type ‘inclusive-or’ elements. 7. Cardinality, groupFeature, and typeFeature properties are transformed into PL-AspectualACME properties.

The steps to generate a PL-AOVGraph model from a PL-AspectualACME specification are represented in Figure 9. The steps to generate a PL-AOVGraph model from a PL-Aspectual ACME specification are:

1. To transform the Family element into a Goal Model element, corresponding to the root of the goal model. 2. To transform components, ports, and representations hierarchy into tasks, goals, and softgoals, according to the ‘elementType’ property (which indicates the PL-AOVGraph element type). When additional information about the PL-AVGraph model are not available at the architecture description, only tasks and softgoals are generated. The tasks are derived from ports and softgoals are derived from components. However, it is necessary to examine whether these components and ports are not part of some ‘or’ intertype declaration. If they do, they are not transformed into softgoals and tasks, but exist only in the body of an intertype declaration. 3. Select Ports and the feature-type property indicate the types of contribution relationships (and, or, xor inc-or) 4. To transform cardinalityMin, cardinalityMax, cardinalityGroupMin, and cardinalityGroupMax properties into PL-AOVGraph properties. 5. PL-AspectualACME Analisys Excludes constraint is transformed into the correlation break property. Analisys Requires constraint is transformed into the make correlation. Help, hurt, and unknown properties are generated from the correlation property. 6. Each aspectual connector is mapped into a crosscutting relationship, as intertype declaration or advice (this is determined by a property). The glue clause type determines the intertype declaration or advice type. 7. For each attachment with the same connector linking ports and roles: (i) ports connected to a crosscuttingRole are mapped into an intertype declaration or an advice body; (ii) the component that contains this port is mapped into the

287287

crosscutting relationship source; (iii) ports linked to baseRoles are mapped into pointcuts. 8. At the end of the mapping, it is necessary to assemble all the crosscuting relationships with the same source, as well as all points affected by the same intertype declaration or advice.

VI. TRANSFORMATIONS IN THE E-COMMERCE CASE

STUDY

Based on rules described in Table 1 and on the process defined in this work, we performed: (i) a mapping from PL-AOVGraph to PL-AspectualACME (partially depicted in Figure 10) and (ii) a mapping from PL-AspectualACME to PL-AOVGraph (partially depicted in Figure 11).

In the mapping from PL-AOVGraph to PL-AspectualCME, we observed additional elements, as the ‘elementType’ property (in red, in the figure), which defines, in the ADL, the element type of the goal model (task, goal or softgoal) that generated its elements.

Figure 8: PL-AOVGraph to PL-AspectualACME transformation

Figure 9: PL-AspectualACME to PL-AOVGraph transformation

VII. DISCUSSION

In PL-AspectualACME, starting from the third level, elements with children are transformed into representations. This can cause a very large nesting in case of an extensive product line.

Cardinality in PL-AspectualACME is represented by properties. This can cause problems, since properties are not mandatory elements of the language. It would be proper to create a new abstraction for representing Cardinality, since SPL has cardinality on many elements.

In the reverse transformation, from a PL-AspectualACME specification (not generated from a goal model) to PL-AOVGraph, there is the problem of identifying the elements that are task, goal, or softgoal. Some functional requirements were therefore represented as softgoals in PL-AOVGraph.

‘elementType’ property is not a mandatory PL-AspectualACME element. Thus, the architect does not usually present such information when specifying the architecture.

Some problems can also arise due to the defined mappings such as: (i) semantic loss – some information represented in PL-AOVGraph has no direct correspondence in PL-AspectualACME and vice-versa. We deal with this problem by adding properties in the architectural description, so the architect can know if a component or port was derived from a goal, a softgoal, or a task and he can decide if that component or port has to be directly represented in architecture. However, an automatic generation of the architecture from the requirements can result in an incomplete model because some architectural

288288

decisions are not represented in PL-AOV-graph; (ii) limited creativity – the mapping rules are not so flexible and assume that the requirements were decomposed in the correct way. This does not make the architecture design process less creative because architectural information should be added. We have worked with the idea of that there is an information baseline, and it has to be repeated (and mapped to) in many of the models created during the software development process; therefore architects do not have to write this common information from scratch, he can add or change a pre-structure that was obtained from requirements.

VIII. FINAL REMARKS

Based on the need for maintaining the consistency between requirements and architecture in the software development, in this paper we presented a mapping process between models of these two development phases (requirements and architecture). We showed how

variabilities are represented in an aspect-oriented architecture description language (ADL).

We defined mapping rules from PL-AspectualACME and PL-AOVGraph. We also applied the process and the rules in a case study, performing bidirectional transformations: (i) PL-AOV-Graph (obtained from feature model ) to PL-AspectualACME, (ii) PL-AspectualACME to PL-AOV-Graph

We concluded that it is necessary to improve PL-AspectualACME in order to enable a better automatic tracing to PL-AOV-Graph, with no semantics loss. As a future work we aim to improve PL-AspectualACME by solving the problem of using nested representations to model variabilities. We also aim to evaluate our approach in several other case studies.

Figure 10: PL-AOVGraph to PL-AspectualACME Transformation

Figure 11: PL-AspectualACME to PL-AOVGraph Transformation

REFERENCES

[1] BATISTA, T. et al. On the Role of Features and Goals Models in the Development of a Software Product Line Early Aspects in AOSD, France, 2010.

[2] BATISTA, T. et al. Reflections on Architectural Connection: Seven Issues on Aspects and ADLs. Workshop on Early Aspects, ICSE'06, May 2006, Shanghai, China.

[3] BATISTA, T. et al. Um Estilo Arquitetural para Linhas de Produtos de Software. Brazilian Symposium on Components, Architecture and Reuse (SBCARS), 2009.

[4] GARLAN, D. et al. ACME: an architecture description interchange language. In: CASCON, 97., 1997. Toronto, Canadá, 1997.

[5] KANG, K. et al. Feature-Oriented Domain Analysis) Feasibility Study. Technical Report. Carnegie Mellon University, . 1990.

[6] LINDEN, Frank van der. et al. Software Product Line in Action: The Best Industrial Practice in Product Line Engineering. Springer, 2007.

[7] MONROE, R. Capturing Software Architecture Design Expertise With Armani. CMU School of Computer Science Technical Report CMU-CS-98-163. 1998.

[8] SILVA, L. F. da. Uma Estratégia Orientada a Aspectos em Modelagem de Requisitos. PhD Thesis – PUC-Rio, Rio de Janeiro, 2006.

[9] YU, Y. et al. From Goals to Aspects: discovering aspects from

requirements goal models. IEEE International Symposium on Requirements Engineering - RE’04, United Kingdom, 2004.

289289