A Lightweight Language for Software Product Lines Architecture Description

Transcription

1 A Lightweight Language for Software Product Lines Architecture Description Eduardo Silva, Ana Luisa Medeiros, Everton Cavalcante, Thais Batista DIMAp Department of Informatics and Applied Mathematics UFRN Federal University of Rio Grande do Norte Natal, Brazil Abstract. The architecture description of a software product line (SPL) is essential to make it clear how the architecture realizes the feature model and to represent both the domain and application engineering architectural artefacts. However, most architecture description languages (ADLs) for SPL have limited support regarding variability management and they do not express the relationship between features and the architecture, besides the lack of tools for graphical and textual modelling and a non-clear separation between the domain and application engineering activities. In order to overcome these deficiencies, this paper presents LightPL-ACME, an ADL whose main goal is to be a simple, lightweight language for the SPL architecture description, and enable the association between the architectural specification and the artefacts involved in the SPL development process, including the relationship with the feature model and the representation of both domain and application engineering elements. Keywords: Software product lines architectures, Architecture description languages, ACME, LightPL-ACME 1 Introduction Software product lines (SPLs) [1] consist of an approach for deriving applications that shares a specific set of common features (commonalities) and have variabilities that distinguish the specific applications, thus supporting the development of 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, thus exploring similarities while preserving the ability to build different products, and; (ii) application engineering, which aims to specify and customize different products from the artefacts generated by the domain engineering activity. The architectural description is one of the activities involved in the development of an SPL that enables to anticipate important decisions regarding the system design and represent architectural characteristics of the SPL. In the software architecture context, architecture description languages (ADLs) [2] provide

2 2 Silva et al. abstractions for representing architectures through components, connectors, and configurations. Components represent software functionalities, connectors are communication elements, and configurations describe the relationship between components and connectors. Although there are some ADLs for describing SPL architectures [3 5], most of them have limited support regarding the management of variabilities since they only focus on documenting SPL concepts (similarities and variabilities) and architectural elements rather than the relationship and traceability between the variabilities represented in the feature model and the architecture of an SPL. Moreover, these ADLs do not express the relationship between features and the architecture and suffer from the following limitations: (i) high verbosity that makes the architectural description confusing and difficult to understand; (ii) complexity for instantiating products; (iii) lack of tools for graphical and textual modeling; and (iv) lack of a clear separation between the domain and application engineering activities in the SPL development process. In this context, this paper presents LightPL-ACME, an ADL that aims to provide a lightweight strategy for describing architectures of SPLs in order to overcome the abovementioned limitations. We have chosen the ACME ADL [6] as basis of the proposed ADL since ACME provides generic structures to cope with a wide range of systems and includes a language based on first-order predicate logic called Armani [7], which is used to design architectural constraints. The main features of LightPL-ACME are: (i) semantic enrichment of ACME elements originally used to specify the SPL architecture, the so-called base architecture; (ii) elements designed to enable the definition of the referenced architecture, which is a base architecture whose elements refer to the features of the SPL; and (iii) products instantiation, which is based on the architectural description of the SPL and the referenced architecture. In this paper, we illustrate the main elements of the LightPL-ACME ADL with the GingaForAll [8] SPL for Ginga [9], the middleware adopted by the Brazilian Digital Television System (SBTVD). This paper is structured as follows. Section 2 describes the basic concepts regarding SPLs and provides an overview about the ACME/Armani ADL. Section 3 presents LightPL-ACME and its application for describing the GingaForAll SPL. Section 4 presents the LightPL-ACME Studio tool. Section 5 presents related 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 product line) of similar products by using a common software infrastructure to mount and configure parts designed to be reused among products and following two main activities, namely domain engineering and application engineering [11]. The construction of a software product, also called instantiation or derivation,

3 A Lightweight Language for SPL Architecture Description 3 is made from a configuration of core assets, which consists of an arrangement of the software artefacts that implement the product. In the SPL development, the members of a family have a basic set of common functionalities and associated variants that individualize each one of these members. Typically, similarities and variabilities among products of a family are modelled in terms of features, which are concepts that may be a requirement, a function, or a non-functional feature [1]. Features are organized in feature models, which that represent similarities, variabilities, and constraints related to the variations between features and their relationships. In general, feature models have a tree structure in which features are represented by nodes of the tree and the variations between features are represented by edges and feature groups, so that the hierarchical organization of the diagram describes the key concept 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 included in a product; (ii) optional, i.e. the feature may or may not be included if the feature from which it derives is selected; (iii) inclusive-or, i.e. among the set of 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 domainspecific ADLs. A system is described in ACME by seven basic elements: Component, Connector, System, Attachment, Port, Role, and Representation. Components are computational entities that can have multiple interfaces called Ports. The ports of a component are bound to the ports of other components through Connectors, which can have multiple interfaces called Roles. Systems are abstractions that represent configurations of components and connectors including a set of Component elements, a set of Connector elements, and a set of Attachment elements that describe the topology of the system in terms of Port Role associations. Representations are alternative architecture views of an element or more detailed decompositions of a given element (component, connector, port or role). Furthermore, architectural elements can be annotated in order to represent behavioral and non-functional properties by using Property elements. Properties have the form of <name, type, value> triples and can be used in any of the ACME elements. ACME also enables to define architectural styles in order to increase reuse and expressiveness, which is done through the Type and Family elements. In ACME, an architectural style defines a family of systems, through Family element, in terms of a structural organization pattern that contains a vocabulary of element types and a set of constraints that indicate how these elements can be combined, and the Type element is used to define a vocabulary of abstract types of ACME elements. In turn, Armani [7] is an ACME extension and consists of a predicate language based on first-order logic used to express architectural constraints over ACME elements. Such constraints are defined in terms of invariants, design constraints that must be fulfilled, and heuristics, design constraints that may or may not be fulfilled.

4 4 Silva et al. 3 LightPL-ACME LightPL-ACME is an ADL proposed as an ACME extension that aims to provide a lightweight, simple language for SPL architecture description, so that it is possible to associate such description with the artefacts related to the domain engineering and application engineering activities in the SPL development process. It supports the separation of these SPL activities by creating specific abstractions for features (related to the domain engineering activity) and products (related to the application engineering activity). Moreover, LightPL-ACME was designed envisioning the representation of the architecture and its relationship with the features. The following subsections present the main elements of the LightPL-ACME ADL. 3.1 ProductLine, Feature, and Product elements The ProductLine element has similar characteristics to the ACME Family element, which is semantically and syntactically enriched in order to represent the SPL, thus enabling the user to describe its specific elements, such as features and products. Within the ProductLine element, the Feature element is defined to represent the features that compose the SPL and is specified by the definition of an identifier and an associated type related to the types of features that may occur in an SPL: (i) Mandatory, which represents mandatory features; (ii) Optional, which represents optional features; (iii) Alternative, which represents alternative features, and; (iv) InclusiveOr, which represents inclusive-or features. Additionally, the extends mechanism provided by ACME enables to establish an inheritance relationship between two features. Fig. 1 illustrates the definition of the Demultiplexer, Hardware, and Software features for the GingaCC ProductLine element and its corresponding feature model. The Demultiplexer feature is mandatory (line 3), and the Hardware and Software 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 corresponding 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

5 A Lightweight Language for SPL Architecture Description 5 elements in a ProductLine element, namely the requires (for dependency) and excludes (for mutual exclusion) functions, which receive as parameters the identifiers of the Feature elements included in the relationship. Finally, the Product element corresponds to the concept of products that can be generated by an SPL. The specification of this element consists of an identifier regarding the product that is being specified and a set of identifiers regarding the Feature elements that compose this product. The inclusion of Feature elements also occurs by hierarchy, so that the inclusion of a Feature element in a Product element includes all of its direct dependencies, which take place through the inheritance relationship. 3.2 Referenced architectures In LightPL-ACME, referenced architectures are artefacts related to the system architecture and consist of a description of the base architecture that is enriched with references to the Feature elements previously described in a ProductLine element. This notion of referenced architectures in terms of mapping architectural elements to features is part of the well-known concept of configuration knowledge [11], which represents all available information used to support the product derivation process and includes this mapping between SPL artefacts and features. In LightPL-ACME, the mapping mechanism between architectural elements and features in order to compose the referenced architecture is made by using the keyword MappedTo followed by a set of Feature elements and can be added to the specification most of the conventional ACME elements after their names. In order to make Feature elements (that represent the features) accessible in the referenced architecture, it is necessary that the System element that represents the complete system has been adhered to the architectural style described by a ProductLine element. Fig. 2 illustrates the mapping between the base architecture and the GingaForAll SPL architectural description in order to compose the referenced architecture, which is represented by the GingaFull System that adheres to the GingaForAll ProductLine. It is important to highlight that all features described in the ProductLine element associated with the referenced architecture must be mapped to at least one element of the architecture, otherwise the architecture does not fulfill the ProductLine. However, there may be architectural elements that are not being mapped to Feature elements and then they can be interpreted as implementation-specific elements. 4 LightPL-ACME Studio LightPL-ACME Studio 1 [12] is a tool developed as an Eclipse IDE plug-in that was designed to assist the SPL development and support the textual specification and graphical representation of architectures described in LightPL-ACME. 1 The LightPL-ACME Studio tool is available as free download from:

6 6 Silva et al. Fig. 2. Mapping to the referenced architecture in LightPL-ACME. The tool enables to specify architectural descriptions, create and edit LightPLACME elements (e.g. ProductLine), and represent referenced architectures, besides maintaining an automatic correspondence between textual and graphic descriptions. Fig. 3 illustrates a partial textual description of the GingaForAll SPL in LightPL-ACME and its corresponding graphical representation in the LightPL-ACME Studio tool. Fig. 3. Partial textual description of the GingaForAll ProductLine (left) and its corresponding graphical representation. Furthermore, LightPL-ACME Studio also enables to define the mapping between elements in the base architecture and features of the SPL by accessing the properties of the architectural element and choosing the features to which such element will be mapped, as exemplified in Fig Related Work In this section we present some proposals of the literature regarding ADLs to SPL architectural description. In ADLARS [3] the relationship between features and the architectural description is explicitly done through conditional expressions, so that a Component Template specifies the collection of possible component

7 A Lightweight Language for SPL Architecture Description 7 Fig. 4. Mapping from the Ginga CommonCore component in the base architecture to the 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 architectures, thus hampering the identification of the variation points and their relation with the system architecture. In turn, PL-AspectualACME [5] represents variabilities by purely using the conventional ACME abstractions. It combines Representation elements for identifying product variations and Port elements for representing the mechanism of variability selection, features are described as Component Type elements, and the type of a feature (mandatory, optional or alternative) is defined through properties. Unlike LightPL-ACME, none of the abovementioned languages addresses an explicit separation between the domain engineering and application engineering activities and has the concept and representation of the referenced architecture. Moreover, xadl 2.0 and PL-AspectualACME architectural descriptions tend to be verbose, whereas LightPL-ACME provides a simple, lightweight way for describing SPL architectures. Furthermore, LightPL-ACME enables the description 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 describing SPL architectures that introduces three essential elements (ProductLine, Feature, and Product) in order to reduce the verbosity and complexity in the description of SPL concepts and enrich elements present in the ACME ADL for SPL description and enable the description of the referenced architecture, a key concept that denotes a base architecture with references to the features described in the SPL. Finally, the LightPL-ACME strategy promotes a clear separation between the domain engineering and application engineering activities that are involved in the SPL development process. and maintains characteristics related to generality, simplicity, expressiveness, and extensibility inherited from ACME by using the existing abstractions of this ADL and avoiding the addition of many new abstractions. The proposed language has also an associated tool called LightPL-

8 8 Silva et al. ACME Studio, which provides textual and graphical support for representing SPL architectures specified in this ADL. LightPL-ACME was evaluated by a controlled experiment with a real-world case study, the GingaForAll SPL, as available at lightplacmestudio/experiments.php. In this experiment, it was possible to observe 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 to use the LightPL-ACME ADL within a model-driven development strategy in order to automatically generate customized source code from product models and also check the correlation between the source code and the architectural model. 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 for software architecture description languages. IEEE Trans. on Software Engineering 26(1), pp (2000) 3. Bashroush, R. et al.: ADLARS: An architecture description language for software product lines. In: 29th Annual IEEE/NASA Software Engineering Workshop, pp , IEEE Computer Society, USA (2005) 4. Dashofy, E. M. et al.: A highly-extensible, XML-based architecture description language. In: 2001 Working IEEE/IFIP Conf. on Software Architecture, pp , IEEE Computer Society, USA (2001) 5. Barbosa, E. A. et al.: PL-AspectualACME: An aspect-oriented architectural description language for software product lines. In: Crnkovic, I. et al. (eds.) 5th European Conf. on Software Architecture. LNCS, vol. 6903, pp , 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 , IBM Press (1997) 7. Monroe, R.: Capturing software architecture expertise with Armani. Technical report, School of Computer Science, Carnegie Mellon University, USA (1998) 8. Saraiva, D. et al.: Architecting a model-driven aspect-oriented product line for a digital TV middleware: A refactoring experience. In: Ali Babar, M., Gorton, I. (eds.) 4th European Conf. on Software Architecture. LNCS, vol. 6285, pp , Springer-Verlag, Germany (2010) 9. Ginga Middleware: 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 applications. ACM Press/Addison-Wesley, USA (2000) 12. LightPL-ACME Studio: Batista, T. et al.: Aspectual connectors: Supporting the seamless integration of aspects and ADLs. In: XX Brazilian Symposium on Software Engineering, pp , SBC, Brazil (2006)