A Lightweight Language forSoftware Product Lines Architecture Description

Eduardo Silva, Ana Luisa Medeiros, Everton Cavalcante, Thais Batista

DIMAp – Department of Informatics and Applied MathematicsUFRN – Federal University of Rio Grande do Norte

Natal, Brazil{eduafsilva,analuisafdm,evertonranielly,thaisbatista}@gmail.com

Abstract. The architecture description of a software product line (SPL)is essential to make it clear how the architecture realizes the featuremodel and to represent both the domain and application engineering ar-chitectural artefacts. However, most architecture description languages(ADLs) for SPL have limited support regarding variability managementand they do not express the relationship between features and the archi-tecture, besides the lack of tools for graphical and textual modelling anda non-clear separation between the domain and application engineeringactivities. In order to overcome these deficiencies, this paper presentsLightPL-ACME, an ADL whose main goal is to be a simple, lightweightlanguage for the SPL architecture description, and enable the associa-tion between the architectural specification and the artefacts involved inthe SPL development process, including the relationship with the featuremodel and the representation of both domain and application engineeringelements.

Keywords: Software product lines architectures, Architecture descrip-tion languages, ACME, LightPL-ACME

1 Introduction

Software product lines (SPLs) [1] consist of an approach for deriving applicationsthat shares a specific set of common features (commonalities) and have variabil-ities that distinguish the specific applications, thus supporting the developmentof a product family. The SPL development process follows two main activities:(i) domain engineering, which aims to systematize the gathering, organization,and storage of reusable and consistent information in the form of artefacts, thusexploring similarities while preserving the ability to build different products,and; (ii) application engineering, which aims to specify and customize differentproducts from the artefacts generated by the domain engineering activity.

The architectural description is one of the activities involved in the devel-opment of an SPL that enables to anticipate important decisions regarding thesystem design and represent architectural characteristics of the SPL. In the soft-ware architecture context, architecture description languages (ADLs) [2] provide

2 Silva et al.

abstractions for representing architectures through components, connectors, andconfigurations. Components represent software functionalities, connectors arecommunication elements, and configurations describe the relationship betweencomponents and connectors.

Although there are some ADLs for describing SPL architectures [3–5], mostof them have limited support regarding the management of variabilities sincethey only focus on documenting SPL concepts (similarities and variabilities)and architectural elements rather than the relationship and traceability betweenthe variabilities represented in the feature model and the architecture of anSPL. Moreover, these ADLs do not express the relationship between featuresand the architecture and suffer from the following limitations: (i) high verbositythat makes the architectural description confusing and difficult to understand;(ii) complexity for instantiating products; (iii) lack of tools for graphical andtextual modeling; and (iv) lack of a clear separation between the domain andapplication engineering activities in the SPL development process.

In this context, this paper presents LightPL-ACME, an ADL that aims toprovide a lightweight strategy for describing architectures of SPLs in order toovercome the abovementioned limitations. We have chosen the ACME ADL [6]as basis of the proposed ADL since ACME provides generic structures to copewith a wide range of systems and includes a language based on first-order pred-icate logic called Armani [7], which is used to design architectural constraints.The main features of LightPL-ACME are: (i) semantic enrichment of ACMEelements originally used to specify the SPL architecture, the so-called base ar-chitecture; (ii) elements designed to enable the definition of the referenced ar-chitecture, which is a base architecture whose elements refer to the features ofthe SPL; and (iii) products instantiation, which is based on the architecturaldescription of the SPL and the referenced architecture. In this paper, we illus-trate the main elements of the LightPL-ACME ADL with the GingaForAll [8]SPL for Ginga [9], the middleware adopted by the Brazilian Digital TelevisionSystem (SBTVD).

This paper is structured as follows. Section 2 describes the basic conceptsregarding SPLs and provides an overview about the ACME/Armani ADL. Sec-tion 3 presents LightPL-ACME and its application for describing the GingaForAllSPL. Section 4 presents the LightPL-ACME Studio tool. Section 5 presents re-lated work. Finally, Section 6 contains final remarks and future works.

2 Background

2.1 Software product lines

Software product lines (SPLs) [1] enable the creation of a family (or productline) of similar products by using a common software infrastructure to mountand configure parts designed to be reused among products and following twomain activities, namely domain engineering and application engineering [11].The construction of a software product, also called instantiation or derivation,

A Lightweight Language for SPL Architecture Description 3

is made from a configuration of core assets, which consists of an arrangement ofthe software artefacts that implement the product.

In the SPL development, the members of a family have a basic set of com-mon functionalities and associated variants that individualize each one of thesemembers. Typically, similarities and variabilities among products of a family aremodelled in terms of features, which are concepts that may be a requirement,a function, or a non-functional feature [1]. Features are organized in featuremodels, which that represent similarities, variabilities, and constraints relatedto the variations between features and their relationships. In general, featuremodels have a tree structure in which features are represented by nodes of thetree and the variations between features are represented by edges and featuregroups, so that the hierarchical organization of the diagram describes the keyconcept from more general to more specific concepts as they descend the tree.Furthermore, features can be [10]: (i) mandatory, i.e. the feature must be in-cluded in a product; (ii) optional, i.e. the feature may or may not be included ifthe feature from which it derives is selected; (iii) inclusive-or, i.e. among the setof related features at least one of them must be selected, and; (iv) alternative,i.e. among the set of related features exactly one of them must be selected.

2.2 ACME/Armani

ACME [6] is a generic ADL that provides a basis for developing new domain-specific ADLs. A system is described in ACME by seven basic elements: Compo-nent, Connector, System, Attachment, Port, Role, and Representation. Compo-nents are computational entities that can have multiple interfaces called Ports.The ports of a component are bound to the ports of other components throughConnectors, which can have multiple interfaces called Roles. Systems are ab-stractions that represent configurations of components and connectors includinga set of Component elements, a set of Connector elements, and a set of Attach-ment elements that describe the topology of the system in terms of Port–Roleassociations. Representations are alternative architecture views of an element ormore detailed decompositions of a given element (component, connector, port orrole). Furthermore, architectural elements can be annotated in order to representbehavioral and non-functional properties by using Property elements. Propertieshave the form of <name, type, value> triples and can be used in any of theACME elements. ACME also enables to define architectural styles in order toincrease reuse and expressiveness, which is done through the Type and Familyelements. In ACME, an architectural style defines a family of systems, throughFamily element, in terms of a structural organization pattern that contains avocabulary of element types and a set of constraints that indicate how theseelements can be combined, and the Type element is used to define a vocabularyof abstract types of ACME elements. In turn, Armani [7] is an ACME extensionand consists of a predicate language based on first-order logic used to expressarchitectural constraints over ACME elements. Such constraints are defined interms of invariants, design constraints that must be fulfilled, and heuristics,design constraints that may or may not be fulfilled.

4 Silva et al.

3 LightPL-ACME

LightPL-ACME is an ADL proposed as an ACME extension that aims to pro-vide a lightweight, simple language for SPL architecture description, so that itis possible to associate such description with the artefacts related to the do-main engineering and application engineering activities in the SPL developmentprocess. It supports the separation of these SPL activities by creating specificabstractions for features (related to the domain engineering activity) and prod-ucts (related to the application engineering activity). Moreover, LightPL-ACMEwas designed envisioning the representation of the architecture and its relation-ship with the features. The following subsections present the main elements ofthe LightPL-ACME ADL.

3.1 ProductLine, Feature, and Product elements

The ProductLine element has similar characteristics to the ACME Family ele-ment, which is semantically and syntactically enriched in order to represent theSPL, thus enabling the user to describe its specific elements, such as featuresand products. Within the ProductLine element, the Feature element is definedto represent the features that compose the SPL and is specified by the defini-tion of an identifier and an associated type related to the types of features thatmay occur in an SPL: (i) Mandatory, which represents mandatory features; (ii)Optional, which represents optional features; (iii) Alternative, which representsalternative features, and; (iv) InclusiveOr, which represents inclusive-or features.Additionally, the extends mechanism provided by ACME enables to establish aninheritance relationship between two features.

Fig. 1 illustrates the definition of the Demultiplexer, Hardware, and Softwarefeatures for the GingaCC ProductLine element and its corresponding featuremodel. The Demultiplexer feature is mandatory (line 3), and the Hardware andSoftware features are alternative and derived from the Demultiplexer feature(lines 4 and 5).

Fig. 1. Features and product description in a ProductLine element and its correspond-ing depiction as a feature model.

In order to complement the description of the features in an SPL, LightPL-ACME provides Armani [7] functions for specifying constraints between Feature

A Lightweight Language for SPL Architecture Description 5

elements in a ProductLine element, namely the requires (for dependency) andexcludes (for mutual exclusion) functions, which receive as parameters the iden-tifiers of the Feature elements included in the relationship.

Finally, the Product element corresponds to the concept of products that canbe generated by an SPL. The specification of this element consists of an identifierregarding the product that is being specified and a set of identifiers regarding theFeature elements that compose this product. The inclusion of Feature elementsalso occurs by hierarchy, so that the inclusion of a Feature element in a Productelement includes all of its direct dependencies, which take place through theinheritance relationship.

3.2 Referenced architectures

In LightPL-ACME, referenced architectures are artefacts related to the systemarchitecture and consist of a description of the base architecture that is enrichedwith references to the Feature elements previously described in a ProductLineelement. This notion of referenced architectures in terms of mapping architec-tural elements to features is part of the well-known concept of configurationknowledge [11], which represents all available information used to support theproduct derivation process and includes this mapping between SPL artefacts andfeatures.

In LightPL-ACME, the mapping mechanism between architectural elementsand features in order to compose the referenced architecture is made by usingthe keyword MappedTo followed by a set of Feature elements and can be addedto the specification most of the conventional ACME elements after their names.In order to make Feature elements (that represent the features) accessible in thereferenced architecture, it is necessary that the System element that representsthe complete system has been adhered to the architectural style described bya ProductLine element. Fig. 2 illustrates the mapping between the base archi-tecture and the GingaForAll SPL architectural description in order to composethe referenced architecture, which is represented by the GingaFull System thatadheres to the GingaForAll ProductLine. It is important to highlight that allfeatures described in the ProductLine element associated with the referencedarchitecture must be mapped to at least one element of the architecture, oth-erwise the architecture does not fulfill the ProductLine. However, there may bearchitectural elements that are not being mapped to Feature elements and thenthey can be interpreted as implementation-specific elements.

4 LightPL-ACME Studio

LightPL-ACME Studio1 [12] is a tool developed as an Eclipse IDE plug-in thatwas designed to assist the SPL development and support the textual specifica-tion and graphical representation of architectures described in LightPL-ACME.

1 The LightPL-ACME Studio tool is available as free download from:http://www.dimap.ufrn.br/lightplacmestudio/downloads.php.

6 Silva et al.

Fig. 2. Mapping to the referenced architecture in LightPL-ACME.

The tool enables to specify architectural descriptions, create and edit LightPL-ACME elements (e.g. ProductLine), and represent referenced architectures, be-sides maintaining an automatic correspondence between textual and graphicdescriptions. Fig. 3 illustrates a partial textual description of the GingaForAllSPL in LightPL-ACME and its corresponding graphical representation in theLightPL-ACME Studio tool.

Fig. 3. Partial textual description of the GingaForAll ProductLine (left) and its cor-responding graphical representation.

Furthermore, LightPL-ACME Studio also enables to define the mapping be-tween elements in the base architecture and features of the SPL by accessing theproperties of the architectural element and choosing the features to which suchelement will be mapped, as exemplified in Fig. 4.

5 Related Work

In this section we present some proposals of the literature regarding ADLs to SPLarchitectural description. In ADLARS [3] the relationship between features andthe architectural description is explicitly done through conditional expressions,so that a Component Template specifies the collection of possible component

A Lightweight Language for SPL Architecture Description 7

Fig. 4. Mapping from the Ginga CommonCore component in the base architecture tothe Ginga feature in the LightPL-ACME Studio tool.

configurations and associates these components to the features. xADL 2.0 [4]specifies the architecture using XML (eXtensible Markup Language) schemas,but this ADL does not define specific elements for representing SPL architec-tures, thus hampering the identification of the variation points and their rela-tion with the system architecture. In turn, PL-AspectualACME [5] representsvariabilities by purely using the conventional ACME abstractions. It combinesRepresentation elements for identifying product variations and Port elementsfor representing the mechanism of variability selection, features are described asComponent Type elements, and the type of a feature (mandatory, optional oralternative) is defined through properties.

Unlike LightPL-ACME, none of the abovementioned languages addresses anexplicit separation between the domain engineering and application engineeringactivities and has the concept and representation of the referenced architecture.Moreover, xADL 2.0 and PL-AspectualACME architectural descriptions tendto be verbose, whereas LightPL-ACME provides a simple, lightweight way fordescribing SPL architectures. Furthermore, LightPL-ACME enables the descrip-tion of any sort of system since the proposed ADL is a general-purpose language,unlike ADLARS, which is a specific language for embedded systems.

6 Final Remarks

This paper presented LightPL-ACME, a simple, lightweight ADL for describingSPL architectures that introduces three essential elements (ProductLine, Feature,and Product) in order to reduce the verbosity and complexity in the descriptionof SPL concepts and enrich elements present in the ACME ADL for SPL de-scription and enable the description of the referenced architecture, a key conceptthat denotes a base architecture with references to the features described in theSPL. Finally, the LightPL-ACME strategy promotes a clear separation betweenthe domain engineering and application engineering activities that are involvedin the SPL development process. and maintains characteristics related to gener-ality, simplicity, expressiveness, and extensibility inherited from ACME by usingthe existing abstractions of this ADL and avoiding the addition of many newabstractions. The proposed language has also an associated tool called LightPL-

8 Silva et al.

ACME Studio, which provides textual and graphical support for representingSPL architectures specified in this ADL.

LightPL-ACME was evaluated by a controlled experiment with a real-worldcase study, the GingaForAll SPL, as available at http://www.dimap.ufrn.br/lightplacmestudio/experiments.php. In this experiment, it was possible toobserve that LightPL-ACME is able to express important elements of an SPL(such as features and the products that can be generated from them) in a simple,lightweight, clear, and objective way. As directions to future work, we intend touse the LightPL-ACME ADL within a model-driven development strategy inorder to automatically generate customized source code from product modelsand also check the correlation between the source code and the architecturalmodel.

References

1. Clements, P., Northrop, L.: Software product lines: Practices and patterns.Addison-Wesley, USA (2001)

2. Medvidovic, N., Taylor, R. N.: A classification and comparison framework forsoftware architecture description languages. IEEE Trans. on Software Engineer-ing 26(1), pp. 70–93 (2000)

3. Bashroush, R. et al.: ADLARS: An architecture description language for softwareproduct lines. In: 29th Annual IEEE/NASA Software Engineering Workshop, pp.163–173, IEEE Computer Society, USA (2005)

4. Dashofy, E. M. et al.: A highly-extensible, XML-based architecture descriptionlanguage. In: 2001 Working IEEE/IFIP Conf. on Software Architecture, pp. 103–112, IEEE Computer Society, USA (2001)

5. Barbosa, E. A. et al.: PL-AspectualACME: An aspect-oriented architectural de-scription language for software product lines. In: Crnkovic, I. et al. (eds.) 5thEuropean Conf. on Software Architecture. LNCS, vol. 6903, pp. 139–146, Springer-Verlag, Germany (2011)

6. Garlan, D. et al.: ACME: An architecture description interchange language. In:1997 Conf. of the Centre for Advanced Studies on Collaborative Research, pp.169–183, IBM Press (1997)

7. Monroe, R.: Capturing software architecture expertise with Armani. Technical re-port, School of Computer Science, Carnegie Mellon University, USA (1998)

8. Saraiva, D. et al.: Architecting a model-driven aspect-oriented product line fora digital TV middleware: A refactoring experience. In: Ali Babar, M., Gorton, I.(eds.) 4th European Conf. on Software Architecture. LNCS, vol. 6285, pp. 166–181,Springer-Verlag, Germany (2010)

9. Ginga Middleware: http://www.ginga.org.br/en10. Kang, K. C. et al.: Feature-oriented domain analysis (FODA) feasibility study.

Technical report, Software Engineering Institute, Carnegie Mellon University, USA(1990)

11. Czarnecki, K., Eisenecker, U.: Generative Programming: Methods, tools, and ap-plications. ACM Press/Addison-Wesley, USA (2000)

12. LightPL-ACME Studio: http://www.dimap.ufrn.br/lightplacmestudio/13. Batista, T. et al.: Aspectual connectors: Supporting the seamless integration of

aspects and ADLs. In: XX Brazilian Symposium on Software Engineering, pp.17–32, SBC, Brazil (2006)