* In many application domains embedded systems and the corresponding embedded software face an increase in sometimes mutually exclusive stakeholder needs like requests from different customers or national legal obligations. In order to meet these needs variability is explicitly designed into the embedded software. Nowadays, in the engineering process of embedded software the variability information is explicitly documented in a dedicated variability model. Hence, the variability model comprises multiple variability-related concerns that are specific to different roles in the lifecycle of embedded software. Each role (e.g. product manager, requirements engineer, architect, maintenance engineer) requires only a specific subset of the variability information that is documented in the variability model to fulfill their certain responsibility. As a consequence, mechanisms for structuring the variability model with respect to the specific role-based variabilityconcerns are needed. In this paper we present an extension of a well-known modelbased engineering framework for embedded software (the SPES Modeling Framework) in order to structure the overall variability model of the embedded software with respect to role-based variability-concerns.
In many application domains (e.g. in the automotive domain) the management of variants of embedded software becomes increasingly important to address the different needs that are demanded from various stakeholders like customers, users or national authorities for legislation. In order to cope with the manifold and sometimes mutual * Copyright © 2014 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors. exclusive stakeholder needs, the variability of the embedded software is explicitly considered with respect to the engineering artifacts that are created during the engineering process (e.g. requirements, functional design, and technical architecture). This requires an explicit and continuous management of the different variants of the embedded software throughout the engineering process, or even better, throughout the whole lifecycle of the corresponding embedded software.
In recent years a consortium of 21 partners from academia and industry has developed the SPES Modeling Framework (or short: SPES MF, cf. [Br12]) that aims at supporting the seamless model-based engineering of embedded software. The SPES MF is built upon two powerful software engineering principles: “separation of concerns” and “divide and conquer” (cf. [GJM03]). The principle “separation of concerns” is manifested by distinguishing between the four different viewpoints: requirements, functional design, logical architecture and technical architecture. Each of these SPES viewpoints focuses on a set of role-specific concerns in the engineering process of embedded software. For instance, the requirements viewpoint addresses the concerns of the role “requirements engineer” in the engineering process, since he/she is responsible for the requirements specification of the embedded software. “Divide and conquer” is realized by multiple layers of systems’ granularity. Typically, the granularity layers are defined by systematically decomposing the embedded software into ever more finegrained building blocks like subsystems, components and system elements. Therefore, the coarse-grained engineering “problem” is stepwise decomposed into fine-grained engineering problems that are regarded in distinct engineering processes. Each of those engineering processes is in turn structured by the four SPES viewpoints (cf. [Br12]). Originally, variability and variants were not considered in the SPES MF. Therefore, in [HKW13] we proposed a general solution idea how to extend the SPES MF in order to enable an explicit variant management throughout the engineering process of embedded software. Since variability has a crosscutting nature with respect to the embedded software we introduced the concept variability perspective that is orthogonal to the viewpoints and granularity layers of the original SPES MF which is described in [Br12]. This variability perspective documents the variability information, which is related to the SPES MF engineering artefacts. The different roles in the lifecycle of embedded software require specific excerpts of the variability information to fulfill their responsibilities. To take this into account appropriately, we extend the concept of the variability perspective by suggesting an approach, which allows for a role-specific tailoring of the variability information.
The remainder of the paper is structured as follows: In Section 2, we present the conceptual basis for our approach. Section 3 explains requirements and concerns for structuring the variability perspective of the SPES MF. Then we introduce the concept for structuring the variability perspective and explain its applicability by using a variability model extract of an Advanced Driver Assistance System. We will then discuss the effects of the proposed concept in Section 4. The related work will be discussed in Section 5 and our conclusion will be presented in Section 6.
The SPES MF is based on an architecture framework that is proposed in [III11]. In order to describe the extension concept for addressing role-specific variability-concerns we give some insights in the IEEE Std. 42010 and the SPES MF as well as in the general idea of extending the SPES MF by a variability perspective that has already been published in [HKW13].
IEEE Std. 42010 [III11] provides a conceptual framework for defining viewpoints, allowing separation of concerns in an architectural description. Viewpoints cover multiple concerns of different stakeholders (e.g. the logical system architecture). A viewpoint is a specification supporting the structured derivation of one view on a system under development. Hence, multiple viewpoints are required to fully describe the architecture of such systems. The viewpoints also specify how they are interrelated w.r.t. concerns cutting across multiple viewpoints. IEEE Std. 42010 allows sharing architectural artifacts across multiple views and hence considers crosscutting concerns. This concept can be interpreted as one possible implementation of the concept perspective, which was introduced by ROZANSKI and WOODS [RW12]. A perspective is defined as “[...] a collection of architectural activities, tactics, and guidelines that are used to ensure that a system exhibits its particular set of related properties that require consideration across a number of the system’s architectural views” and allows the orthogonal consideration of crosscutting concerns w.r.t. the viewpoints.
The SPES Modeling Framework (cf. [Br12]) consists of four viewpoints: The Requirements Viewpoint addresses the structured documentation and analysis of requirements. The Functional Viewpoint addresses the structured documentation and analysis of system functions. The Logical Viewpoint addresses the structured documentation and analysis of the logical solution, whereas the Technical Viewpoint addresses the structured documentation and analysis of the technical solution. All four viewpoints cover multiple layers of granularity, which can be individually defined (see Figure 1) according to the needs of the engineering process. A new granularity layer is created, whenever a coarsegrained engineering artifact is decomposed into multiple finer grained engineering artifacts. For each of the engineering artifacts the four viewpoints are applied to ensure a structured engineering path on the lower granularity layers. In addition, the SPES MF explicitly considers crosscutting system properties (e.g. safety, real-time).
Variability is a first class concept and needs to be documented explicitly in a separate variability model (cf. [CN02], [PBL05]). This paradigm originates from the software product line community and is based on two ontological concepts: variability subject and variability object. The variability subject is defined as a variable item of the real world or a variable property of such an item, e.g. the paint of a car. The variability object is defined as a particular instance of a variability subject, e.g. red paint (cf. [PBL05]). A software-variant is constituted of a selected set of variability objects. These two concepts are supported by multiple relationships between variability subjects and variability objects. Dependencies are defined to express optional or mandatory variability objects and alternative groups. Constraints between variability subjects and variability objects are used to express requires- or excludes- relationships. Variability modeling is essential to continuous variant management in the engineering of variable software for embedded systems, because the variability cuts across the engineering process. Thus, all SPES viewpoints and several roles participating in the engineering of such systems are affected. In [HKW13] the SPES MF was extended by the variability perspective to consider the crosscutting nature of variability. The variability perspective documents the variability information orthogonally to the SPES viewpoints in one variability model. This variability perspective can be understood as an instantiation of the concept perspective proposed by ROZANSKI and WOODS [RW12] and defines the ontological concepts for variability modeling in the SPES MF in accordance to [PBL05]. In consequence, the variability perspective does not prescribe specific variability modeling languages, which leaves the concept open to project or company specific instantiations.
In this Section we will elaborate on requirements for structuring the variability perspective and present concerns related to specific roles in an engineering process. Based on these requirements and concerns we propose an IEEE Std. 42010-compliant approach to structure the variability perspective of the SPES MF. We demonstrate the application of the approach by a simplified example from the automotive domain.
ISO/IEC Std. 15504 (cf. [II06]) and domain specific derivations like automotive SPICE require the definition of specific responsibilities and authorities in an engineering process (cf. [Aut10]) to manage and develop engineering artifacts. Responsibilities are represented by roles in an engineering process (cf. [So11]) and hence essential to each engineering process. In the setting of variable software for embedded system, the responsibility for an engineering artifact also covers its variability. Hence, this responsibility causes e.g. the role EE-System Architect to retrieve a certain subset of the variability information, resulting in role-based variability-concerns. Consequently, we consider role-based variability-concerns as a key driver for structuring the variability information and hence the variability model. Based on the experiences made in several development projects of the automotive industry we derive the following requirements for structuring the variability perspective: (R1) Reduce the variability model complexity by neglecting irrelevant variability information for a determined SPES viewpoint, granularity layer or role. (R2) Define role-specific variability views to support the communication between different roles (e.g. requirements engineers and software designers).
These requirements address the required capabilities of an approach for structuring the variability information. In other words R1 and R2 are necessary to realize a variabilityrelated concern based structuring of the variability model. The structuring of the variability model is based on role-specific variability-concerns, which we identified, when working in projects that applied automotive SPICE.
(C1) Which variability information is required by a specific role? (C2) Which variability information is required by a specific role w.r.t. a specific granularity layer e.g. of a subsystem? (C3) Which variability information is the required by a specific role w.r.t. a specific
SPES viewpoint? The three concerns (C1 – C3) need detailing to support development, maintenance, change impact analysis and software defect detection activities of an engineering process. C1 is the most generic concern. Hence, we understand C2 and C3 as more detailed concerns. C2 potentially covers the variability information of multiple SPES viewpoints, whereas C3 potentially covers the variability information of multiple granularity layers. From the requirements and concerns it follows that a comprehensive view concept on variability models, is necessary (cf. [MSR13]).
Views on instances of variability models focus on specific variability-related concerns, which are documented in the model. Hence, views allow for analyzing a concern in isolation to get a deep understanding of this concern (cf. [GJM03]). This notion led us to introduce variability viewpoints based on the core concepts of IEEE Std. 42010: stakeholder-specific concern and viewpoint as a specification for a view. A variability view can be understood as a role-specific excerpt of information from the variability perspective. A variability viewpoint that addresses a role-specific variability-concern specifies which information of the variability perspective is needed by the corresponding role to be able to fulfill its responsibilities. Typically, different variability viewpoints share the same ontology for modeling variability information namely a variability model. In accordance to the requirements R1 and R2, and the concerns C1 – C3 we propose using role-based variability-concerns.
These concerns are the conceptual fundament for specifying variability viewpoints. Thus, we explicitly relate the concerns of roles to variability viewpoints and thereby allow a role-based structuring of the variability perspective. This structure can be independent from the structure, which is realized by the SPES viewpoints and their corresponding concerns. In doing so, we provide a structuring mechanism for the variability perspective. Essentially, the variability viewpoints provide role-based projections, inspired by relational database theory (cf. [EN11]), on the relation of the variability information VI (see Figure, 1 top layer circular elements). For each role-based variability-concern rc the corresponding variability view is defined as a projection on the variability information (VI) within the variability perspective: In the expression above VP is defined as the set of all variation points (a variation point is the manifestation of a variability subject), VA is defined as the set of all variants (a variant is the manifestation of a variability object) and is the set of all relationships between the elements of the sets A and B. The relation is defined based on the set of different semantics of relationships between elements of the sets A and B. Given n different semantics of the relationships between the elements of A and B then is defined as: 3 )
)
Variability Artifact rc4(VI) Sub-Subsystem
System
1 Subsystem Variability Viewpoints for role-specific structuring of the Variability Perspective
Granularity Layers
multiple Variability Viewpoints Variability Perspective
2 rc2(VI) rc1(VI)
rc3(VI)
SPES Viewpoints Here VI is defined as the set of all explicitly documented variability information within the variability perspective: For instance, let the requires-relation between a set VA of four optional variants va1, va2, va3, va4 be defined as: The relation above states that the variant va1 requires the variant va3 and variant va2 requires variant va4. Thus, va1 requires va3 means that when deciding upon the variant (i.e. the binding of this variant) va1 also a corresponding decision concerning the variant (i.e. the binding of this variant) va3 has to be made.
⋃ V Mid-Size
V
V Low-End V
NAFTA V EU V Adaptive V Cruise Control Cruise V Control Break Assist VP
EEArchitecture
The following example represents a small part of an Advanced Driver Assistant System (or short: ADAS) variability model. The complete variability model comprises several hundred features, which is a common size of variability models for automotive systems like engine control or electric drive. The ADAS supports a car driver in usual traffic scenarios to increase comfort and safety. Thus, it provides multiple functions (e.g., cruise control or brake assist, cf. Figure 2) with individual dependencies (e.g., adaptive cruise control requires signals of the high-end EE-architecture). The ADAS is offered in different vehicles classes (e.g., mid-size or luxury) and multiple markets (e.g. Europe or NAFTA-North American Free Trade Agreement). Figure 2 visualizes the ADAS variability information VI using the Orthogonal Variability Model variability modeling language (cf. [PBL05]).
s e d u l c x e
VP Vehicle Class
VP Market 1..1 1..1
Variability Concepts legend Core Concepts Relationships Variation Point requires
VP excludes V [name] variant [name]
Dependencies mandatory alternative group
m..n Role-based Variability Viewpoints
VEAEire-cswhyipsttoeecinmtt EngRienCDqeuouesmirtreoVemmiseteweicnrptosint rc.Sys.Arch(VI) rc.CD.Re.Eng(VI) Multiple roles are involved in the engineering process and marketing of the ADAS. Two of them are the EE-System Architect (or short: Sys.Arch) and the Customer Domestic Requirement Engineer (or short: CD.Re.Eng). The role Sys.Arch is responsible for designing and maintaining the architecture of an EE-system and takes responsibility for the internal characteristics and variability of an EE-system. The set of role-based variabilityconcerns that is associated with the role Sys.Arch is named rc.Sys.Arch. The variability viewpoint is denoted as ∏ ( ) in Figure 2. In contrast, the role CD.Re.Eng manages the requirements of specific markets and defines the market individual characteristic of an EE-System (e.g., in scope of after sales). The set of role-based variabilityconcerns that is associated with the role CD.Re.Eng is named rc.CD.Re.Eng. The variability viewpoint is denoted as ∏ ( ) in Figure 2. Constraints between e.g. different variants spanning across multiple viewpoints (e.g. Luxury requires HighEnd, cf. Figure 2) need to be maintained by the roles that are associated with the viewpoints.
According to IEEE Std. 42010, viewpoints are required to be documented explicitly. Thus, based on the concerns of the roles Sys.Arch and CD.Re.Eng two different variability viewpoints can be defined. Each has a unique name (e.g. vv.Sys.Arch and vv.CD.Re.Eng) and focuses on role-specific concerns such as the technical variability of the EE-System of the ADAS (vv.Sys.Arch) and the market specific variability in terms of different functionality and behavior of the ADAS (vv.CD.Re.Eng). Thus, both viewpoints use a role-specific subset of the variability information documented in the variability model (e.g. Feature Model, Orthogonal Variability Model) and use the same model for representing the variability information. These variability viewpoints can be used to derive the views visualized in Figure 2.
The proposed approach (cf. Section 3) impacts the engineering artifacts. Thus, we discuss possible impacts and challenges for a required evaluation.
Relation to Engineering Artifacts: The proposed view concept for variability models impacts the related engineering artifacts, because information documented by these artifacts is automatically tailored according to the tailored variability view. This is due to the relation of the variability model and the corresponding engineering artifacts. Today it is not clear whether the tailoring of variability information can be transferred to the engineering artifacts. Further research in this area is necessary.
Evaluation: As our work is in an early stage, it requires evaluation. The effects of overlapping viewpoints need to be studied in detail. One reason for overlapping variability viewpoints is the overlap of responsibilities in an engineering process, which can lead to discussions on the variability information of interest to multiple roles.
Regarding the realization of variability viewpoints annotative approaches augment variability model elements with additional information, which are used to create views on the variability model. In SCHROETER et al. [SLW12] feature models consist of attributed features. Viewpoints are defined based on these attributes. In contrast to annotative approaches, descriptive approaches specify sets of variability information and use them to define which variability information is part of a view. The work of FEY et al. [FFB02] proposes using feature sets to group features based on the needs on domain experts. But this so called feature set plane disregards the dependencies between features. In HUBAUX et al. [Hu13] a slicing operator based on sets of features for feature models is proposed to create multiple different views on a feature model. The approach focuses solely on feature-based configuration and proposed three different visualizations of not accessible features. THOMPSON and HEIMDAHL [TH03] use a set based approach to structure multi-dimensional product lines allowing for different views on the software product line under development, but the approach is not explicitly related to role-specific variability-concerns. CZARNECKI et al. [CHE05] propose a staged configuration approach in which the three dimensions time (cf. engineering stages), targets (cf. subsystems) and roles (cf. responsibilities) can be used to define successive configuration stages. Moreover, this approach focuses solely on feature-based configuration. In contrast to this approach, variability viewpoints do not necessarily cover specific configuration stages. MUTHIG and SCHROETER [MS13] describe an approach, which uses role-specific views to filter and manage access to feature information to support feature life cycle management, which is concerned with the documentation and evolution of features.
Variability information can be continuously documented in the variability perspective (cf. [HKW13]). Therefore, we argued in Section 1 that only an excerpt of the variability information is required by specific roles to fulfill their responsibilities within an engineering process. We explained the conceptual foundations in Section 2 and introduced an approach to structure the variability perspective based on role-based variability-concerns. The applicability of this concept was demonstrated by an industrial example (cf. Section 3). In Section 4, we discussed the impact of variability views on the related engineering artifacts and discussed that additional studies are required to evaluate the approach. In future work, we plan to examine existing view-building techniques and evaluate the proposed approach in scenarios close to industrial practice to get deeper insights into their benefits and shortcomings. Inconsistencies between overlapping variability viewpoints (cf. [MSA09]) need to be also targeted by future work.
This paper was partially funded by the BMBF project SPES 2020_XTCore under grant 01IS12005C and the DFG project KOPI grant PO 607/4-1. We would like to thank André Heuer and Vanessa Stricker for their fruitful comments regarding this paper.