variability_RE_SPL0311.pdf part of Daytek DT 1530A variability_RE_SPL0311.pdf, plz open it text manual preview

Text preview for : variability_RE_SPL0311.pdf part of Daytek DT 1530A plz open it

Back to : variability_RE_SPL0311.pd | Home

FUNDP - Equipe LIEL Institut d'Informatique Rue Grandgagnage, 21 B - 5000 NAMUR (Belgique)

Modelling variability requirements in Software Product Lines: a comparative survey
Jean-Christophe T RIGAUX and Patrick H EYMANS

Project : Financing:

Product Line ENgineering of food TraceabilitY software "Région wallonne" and "Fonds Social Européen"

First Europe Objectif 3

EPH3310300R0462 / 215315

15 November 2003

2

Contents
1 Introduction 5

2

An Overview of Variability 2.1 2.2 2.3 2.4 Definitions of Variability . . . . . . . . . . . . . . . . . . . . . . . . Categories of Variability . . . . . . . . . . . . . . . . . . . . . . . . Levels of Variability . . . . . . . . . . . . . . . . . . . . . . . . . . . Mechanisms of Variability . . . . . . . . . . . . . . . . . . . . . . .

5 5 6 8 9

3

Modelling Variability 3.1 3.2 Modelling variability: requirements . . . . . . . . . . . . . . . . . . Modelling Variability with Feature Diagrams . . . . . . . . . . . . . 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.3 FODA's notation . . . . . . . . . . . . . . . . . . . . . . . . FORM's notation . . . . . . . . . . . . . . . . . . . . . . . . FeatuRSEB's notation . . . . . . . . . . . . . . . . . . . . . J.Bosch's Notation . . . . . . . . . . . . . . . . . . . . . . . Riebish's Notation . . . . . . . . . . . . . . . . . . . . . . .

9 9 10 11 12 13 15 16 19 19 19 20 22

Modelling Variability with Use Cases . . . . . . . . . . . . . . . . . 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 Classical Use Cases . . . . . . . . . . . . . . . . . . . . . . . Variability and classical Use Cases . . . . . . . . . . . . . . . Extending Use Case templates . . . . . . . . . . . . . . . . . Extending Use Case diagrams . . . . . . . . . . . . . . . . .

Add Decision Model and Extend Use Case diagrams & templates 26 29 31

3.4 3.5

Modelling Variability with Use Cases & Feature Diagrams . . . . . . Modelling Variability with UML Class Diagrams . . . . . . . . . . .

4

Comparison between graphical notations designed to model variation points and variants 33

5

Case Study: Engine Monitoring

38

6

Conclusion 3

49

4

1

Introduction

The increase of variability leads to a situation where the complexity of managing it becomes a primary concern during software development. Variability affects the whole product line process, from requirements to code. Clearly, we need specific solutions to support variability during software product line development. However, in current practice, designers often give variability incidental treatments. They typically introduce it during late design or implementation. Even, they express it through myriad of inventive tricks. The point is that variability must be managed already during requirements engineering. Indeed, in initial project's phases, a key to success is efficient communication between the designers and the stakeholders about requirements and thus variability. Nevertheless, in the software product lines context, a major difficulty can occur because no standard notation has been adopted yet to model variability explicitly. This survey mainly refers to the article of Gunter Halmans and Klaus Pohl [HP03] in order to compare various notations designed to model variability in software product lines. We proceed as follows. Section 2 introduces basic notions on variability such as variability definitions, categories, levels and mechanisms. Section 3 describes variability in requirements engineering for product families development. More specifically, various techniques to model variability based on feature diagrams, use cases and UML class diagrams are presented. In section 4, we compare some selected techniques described in section 3 to analyze in details how they deal with variation points, variants and their relationships. Section 5 presents a small engine monitor case study.

2

An Overview of Variability

The purpose of this section is to describe variability in general. Firstly, in section 2.1, we define variability presenting several relevant definitions in software product lines. Secondly, we classify variability considering two main different aspects: the variability categories (or types) and the variability levels. So, in section 2.2, we present two variability's categorizations; one focus on variability in requirements [HP03] and one focus on variability in architecture [BB01]. Then, in section 2.3, we present the variability levels proposed by Bosch and Svanhnberg in [SB00]. Finally, in section 2.4, we present several mechanisms [JGJ97] which allow to manage variability in specific software development phases.

2.1

Definitions of Variability

Commonalities consist of a structured list of assumptions that are true for each member of the family. Variabilities consist of a structured list of assumptions about how family members differ. David M. Weiss and Chi Lai define variability in product family development as " ... An assumption about how members of a family may differ from each other ... "[WL99]. Variabilities specify the particularities of a system corresponding to the specific expectations of a client. A classic example of variability can be found in the telecommunication domain. Indeed, the identification of variabilities for mobile phone software is quite obvious as they can be listed as it follows : number of keys, screen dimensions, languages, games,...

5

A variation point locates a variability and its possible bindings by describing several variants. Each variant is one way to realize a particular variability and bind it in a concrete way. The variation point itself locates the insertion point for the variants and determines the characteristics (attributes) of the variability. Variation point cardinalities indicate the minimum number of variants which have to be selected for this variation point and the maximum number of variants which can be selected for this variation point [HP03]. Variability management plays a central role in software product lines and constitutes a new challenge compare to classical software engineering. Indeed, difficulties may occur when managing variability in software product lines. Firstly, additional work at start is inevitable. Secondly, the choice of a notation to model variability following the company domain is quite tricky . Thirdly, the variability must be explicitly managed during the all development process and not only during the implementation phase where the code is produced. Fourthly, there is a lack of global tools designed to help software product line engineers during this crucial task. Moreover, both single products and product family variants may change. Products evolve during the time with classical releases like in single product development. Furthermore, they can also evolve following their variants' choice. This two variation aspects are called in [BFG+ 01] "variation in time and in space". Variation in space means that at the same time two products may exist with different variants. Many implementation approaches used in industry for handling variability in a product line show their limits when new products are engaged in or when existing products are evolving (scalability) [AG00]. As variation points are not explicitly defined in the code, the product line evolution is leading gradually to a degraded design and implementation structure.

2.2

Categories of Variability

A classification based on the distinction between essential and technical variability in requirements has been proposed by Günter Halmans and Klaus Pohl [HP03]. Essential variability corresponds to the customer viewpoint who cares about usage aspects and who is concerned with functional and non-functional requirements. Technical variability corresponds to the product family engineer viewpoint who cares about variation points, variants and binding times, and who is concerned with the realization of variability. Clearly, essential variability defines what to implement and technical variability defines how to implement it. These two classes of variability have also been refined in various subcategories which are summarized in figures 1 and 2. For more details refer to [HP03].

6

Essential

Functionality

System environment
Users

Integration in Business Processes
Organization Structure Process Structure

Quality

Information/ Data
Presentation

Function

Availability

Behavior

Types of Usage Usage Environment

Security

Up-to-date

Constraints

Scalability

Figure 1: Essential product family variability [HP03]

Technical

IT-infrastructure

Binding Time

Implementation

Figure 2: Technical product family variability [HP03] A classification for architectural variabilities, shown in figure 3, has been proposed by Felix Bachmann and Len Bass [BB01] following several criteria: Variability in function which means that a particular function may exist in some products and not in others. Variability in data which means that a particular data structure may vary from one product to another. Variability in control flow which means that a particular pattern of interaction may vary from one product to another. Variability in technology which concerns the platform (OS, hardware, dependency on middleware, user interface, run-time system for programming language) and which may vary in a similar way to function but with the technical point of view. Variability in product quality goals like performance or modifiability. Variability in product environment like invocation mechanism.

7

Variability

Function

Data

Control Flow

Technology

Quality goals

Environment

Figure 3: Categorization of product family variability

2.3

Levels of Variability

Various levels of variability are defined by M. Svahnberg and J. Bosch in [SB00] · Product Line Level. Variability on this level is concerned with how products differ, i.e. which components are used by different products and which product specific code (PSC) is used. · Product Level. The variability is concerned with the architecture and the components choice for a particular product. On the product level, the components are fitted together in order to form a product architecture, and the PSC is customized for the particular product variation. The variability issues on this level can be summarized as followed: 1. how to fit components together, 2. how to cope with evolving interfaces, and 3. how to extract and/or replace parts of the PSC. · Component Level. This level is where the set of framework implementations are selected. Variability issues here are: 1. how to enable addition and usage of several component implementations 2. how to design the component interface in such a way that it survives the addition of more concrete implementations. · Sub-Component Level. A component consists of a number of feature sets. On the sub-component level the unnecessary features are removed to avoid dead code and others are added. · Code Level. The code-level is where products evolution and variability between products are implemented, ideally matching the provided and the required class interface defined in previous step. 8

2.4

Mechanisms of Variability

Jacobson defines in [JGJ97] various mechanisms to manage variability. In the following table, those mechanisms are described with the type of variability they address and with the time (requirements time, run time,...) when to apply them. Mechanism Inheritance Extension Uses Configuration Parameters Time of Specialization At class definition time At requirements time At requirements time Previous to runtime At component implementation time Type of Variability Specialization is done by modifying or adding to existing definitions. One use of a system can be defined by adding to the definition of another use. One use of a system can be defined by including the functionality of another use. A separate resource, such as file, is used to specialize the component. A functional definition is written in terms of unbound elements that are supplied when actual use is made of the definition. A type specification is written in terms of unbound elements that are supplied when actual use is made of the specification. A tool that produces definitions from user input.

Template instantiation Generation

At component implementation time

Before or during runtime

3

Modelling Variability

To express variability it is necessary to model variation points and its variable parts [JGJ97]. The purpose of this section is to make a tour of the main modelling variability notations for software product lines. Thus, we describe some feature diagrams, use cases and class diagrams notations which can be textual graphical or a mixture of both. Each specific notation is presented following the same pattern; first we describe the context of the notation, then we describe the syntax of the notation and finally we make a small evaluation of the notation mainly based on the notations comparison (section 4) and on the difficulties and facilities encountered during our small case study (section 5). Meanwhile, before presenting those notations we want to identify the basic requirements needed for a notation which claims to model variability in software product lines.

3.1

Modelling variability: requirements

At this point, we want to study what software product lines engineers generally expect from a notation designed to model variability. A first answer to this question has been already given in [vdML02], where Thomas von der Maßen proposes the following list of basic requirements expected for such notations : · Representation of common and variable parts. It must be possible to express common and variable parts of a software product line. · Distinction between types of variability. The notation must be able to explicitly express all different types of functional variability (options, alternatives, optional alternatives). 9

· Representation of dependencies between variable parts. The description of dependencies is mandatory. Indeed, variabilities are typically not independent of each other: variability A can restrict the range of possible values of variability B (so-called requires or excludes relationships), or variability C is only relevant and therefore should only be visible if some characteristics have been chosen for variability D. · Supporting model evolution. Because models will evolve over time, new requirements and characteristics have to be integrated and the model must be changed easily. · Providing good tangibility and expressiveness. To communicate the resulting models to the domain experts the models must be easy to read and to understand.

3.2

Modelling Variability with Feature Diagrams

The notion of features is used and defined in many different domains. We use for this survey the definition of Kang, who is one of the main references considering features and feature diagrams for software product lines. Kang defines a feature as "a prominent or distinctive user-visible aspect, quality or characteristic of a software system or systems"[KCH+ 90]. Features are also defined in [MG02] as "groups of requirements that give a product distinctive characteristics or qualities. The functional requirements of the system are usually mapped, grouped or modularized to features that the system has to support. A feature is a coherent and identifiable subset of system functionalities". A feature diagram is a featural description of the individual instances of a concept. A feature diagram constitutes a tree composed of nodes and directed edges. The tree's root represents the concept which is refined using mandatory, optional, alternative (X-OR-features) and OR-features. In feature diagrams, mandatory features are features always included in every products. Common features are defined as all mandatory features whose direct and indirect parents are all recursively mandatory. The common features relationship is the transitive closure of the mandatory features relationship. Variable features are defined as all features except common features. Variation points are features (or concepts) that have at least one direct variable subfeature (or feature). In the next subsections, we will describe five notations based on features and features diagrams: FODA's notation [KCH+ 90], FORM's notation [KLD02], FeatuRSEB's notation [GFd98], Bosch's notation [vGBS01] and Riebisch's notation [RBSP02].

10

3.2.1

FODA's notation

The Feature-Oriented Domain Analysis (FODA) method [KCH+ 90] has been introduced by Kang and al. in 1990. The method establishes three phases of a domain analysis: · Context analysis: to establish scope · Domain modelling: to define the problem space · Architecture modelling: to characterize the solution space In the following, we will focus on the domain modelling and more specifically on FODA feature diagrams. Mainly mandatory, optional, and alternative properties of concepts within a domain are described with this notation. 1. Syntax Such feature diagrams are trees (graphical AND/OR hierarchical features) capturing the relationships among features. · The root of the tree represents the concept being described and the remaining nodes denote features and their sub-features. · A feature is mandatory unless an empty circle is attached above its name, indicating an optional feature. · Alternative features in FODA are considered as specializations of a more general feature. Indeed, alternative features, which are children of the same parent feature and connected by an arc, define the alternative feature set from which almost one feature can be selected. · More dependencies between features like "«require»" or "«exclude»" can be expressed with composition rules to avoid graphical overload. 2. Evaluation FODA feature diagrams are one of the first notation used to describe software product lines and by consequence variability. This notation has the advantage to be clear and easy to understand. But it does not have enough expressiveness to model relationships between variants or to explicitly represent variation points. Moreover, generalization/specialization relationships can not be represented graphically at the functional level. The following example (see figure 4) is a feature model of a car system.

11

Figure 4: Feature Diagram FODA: car system [KCH+ 90] 3.2.2 FORM's notation

The FORM method was developed upon the FODA method by Kang and al. [KLD02]. During system development different stakeholders are involved leading to the need to describe various types of features corresponding to specific stakeholders. Users, system analysts, and developers are all usually involved in system development but with different interests. Users are more concerned with services or functions provided by the system (i.e., service features). System analysts and designers are concerned with domain technologies (e.g., navigation methods in the avionics domain, methods of fund transfer in the banking domain). Developers are concerned with implementation techniques (e.g., databases, sorting algorithms). It's difficult to build applications responding to such different views unless sound decisions are made among stakeholders, resulting in an implementable and consistent set of features accepted by all. 1. Syntax The syntax is principally based on FODA adding the various views on the system development. Thus, the FODA feature diagram is completed with four layers: the capability layer, the operating environment layer, the domain technology layer and the implementation technique layer. In the notation, the node symbols are the same as in FODA, but all feature names are depicted in boxes. Moreover, the capability layer is always represented by a feature diagram, but the three next layers transform it in a new graph which is called a feature model. · Mandatory and optional features are identical to FODA and only strong alternative is available, as in FODA. · The relationships between features are "composition", "generalization/ specialization" and "Implemented by". · The "Implemented by" relationship indicates that one feature is necessary to implement another one. 2. Evaluation

12

The main characteristic of FORM is its four layers decomposition which describes different points of views concerning the product development. Nevertheless, this decomposition is not adequate and generates complexity when we have to represent large number of variants. The simplicity and comprehensibility of FODA feature diagrams are reduced. Indeed, in figure 5 the feature model is relatively overloaded, even the features are not depicted in boxes anymore. Another FORM notation's specificity consists in the the relationships between features and more specifically the"implemented by" relationship which makes the link between the essential and technical requirements. The following example (see figure 5) is a feature model of a home integration system product line.

Figure 5: Feature Model FORM: Home integration system [KLD02]

3.2.3

FeatuRSEB's notation

FeatuRSEB [GFd98] is a combination between the FODA method [KCH+ 90] and the Reuse-Driven Software Engineering Business (RSEB) method. The RSEB is a usecase driven systematic reuse process, where variability is captured by structuring use cases and object models with explicit variation points and variants. RSEB provides no explicit feature models or steps that construct and transform such feature models. In FeaturRSEB, UML-like notational constructs are introduced to create feature diagrams. The basic idea is to build a tree or a network of features which are linked to13

gether by UML dependencies or refinements. Moreover, the aim is to represent explicit variation points like it has been defined in RSEB UseCase. 1. Syntax As we can see in figure 6, there are four important constructs in such feature diagrams: · The composed_of relationship indicates that a feature is composed of subfeatures and is represented by a simple line between the feature and each of its subfeatures. · The existence attribute determines whether a feature is optional or mandatory. An optional feature is distinguished by a simple circle above the feature name. · The alternative or XOR-relationship defines a feature as a variation point and defines other features as its variants from which only one can be bound. A variation point feature is represented by a white diamond under its name and the link with its possible variant features is represented by a line between the diamond and the variant feature's name. · The OR-relationship defines a feature as a variation point and defines other features as its variants from which one or more can be bind. A variation point feature is represented by a black diamond under its name and the link with its possible variant features is represented by a line between the diamond and the variant feature's name. 2. Evaluation FeatuRSEB formulates first the idea to establish a link between features and requirements combining FODA feature diagrams and RSEB use cases. Moreover, FeatuRSEB represents explicitly variation points with diamond. Meanwhile, lacks appear to represent variation points cardinalities. The following example (see figure 6) is a feature model of a phone service system

14

Figure 6: Feature Diagram FeatuRSEB: phone service system [GFd98] 3.2.4 J.Bosch's Notation

Jilles van Gurp and Jan Bosch use another feature diagram notation [vGBS01]. The notation is slightly different from FeatuRSEB adding binding times and external features. 1. Syntax · Features are represented by rectangles (like in FORM) · The alternative or XOR-relationship is represented by a non-filled triangle · The OR-relationship is represented by a black-filled triangle · External features which are technical possibilities offered by the system are represented by dotted rectangles. · Variant binding times are associated to the variant relationship

15

2. Evaluation For the alternative or XOR-relationship and for the OR-relationship the non- and black-filled diamond of FeatuRSEB are simply replaced by a non- and blackfilled triangle. The originality of J.Bosch's notation is the external features which are offered by the target platform of the system. While not directly part of the system, they are important because the system uses them and depends on them. This distinction permits to clearly identify the requirements on the system and the hypothesis on the system environment. The binding times representation is also interesting to clearly express variants characteristics. Nevertheless, once more, no variation points cardinalities can be expressed. The following example (see figure 7) is a feature model of a mail client system

Figure 7: Feature Diagram J. BOSCH: Mail Client System [vGBS01]

3.2.5

Riebish's Notation

In [RBSP02], Riebisch and al. insist on the importance of modelling cardinalities in feature diagrams and propose to extend feature diagrams with UML multiplicities. Some multiplicities can be implicitly represented in the previous feature diagrams notations (see figure 8) and shows up whenever features are combined in a set. Multiplicities are partially represented with those previous notations. Indeed, if we consider that n is the number of feature in the set then only four multiplicities can be modelled non explicitly.

16

Multiplicity 0..1 1 0..n 1..n
Multiplicity

Definition At most one feature has to be chosen from the set Exactly one feature has to be chosen from the set An arbitrary number of features (or none at all) have to be chosen from the set At least one feature has to be chosen from the set
FODA & FORM Bosch FeatuRSEB

0..1

Feature Name

Feature Name (XOR)

VP Name (XOR)

F1

F2

Fn

Feature Name 1

Feature Name (XOR)

VP Name (XOR)

F1

F2

Fn

Feature Name 0..n

VP Name (OR) Feature Name (OR) . . .
F1 F2 Fn

Feature Name 1..n

Feature Name (OR)

VP Name (OR)

. . .
F1 F2 Fn

Figure 8: Feature Diagram and multiplicities Shortcomings appear as simple multiplicities like n, 0..p, 1..p, p..n or m..p can not be represented where 1 < m <= p < n. So a new feature diagrams notation has been proposed in [RBSP02]. 1. Syntax · A feature is a node in a directed-acyclic graph. · Relations between features are expressed by edges between features. A circle at the end of its corresponding edge determines the direction of a relation. · If this circle is filled, then the relation between the features is said to be mandatory, i.e. when the feature at the relation's origin is chosen, the feature at the relation's destination has to be chosen, too. · If the circle is empty, then the relation is optional, i.e. the feature at the relation's destination does not need to be chosen. · Optional relations that originate from the same feature node can be combined into a set. Each relation can only be part of one set. A set has a multiplicity that denotes the minimum and maximum number of features to be chosen from the set. Possible multiplicities are: 0..1, 1, 0..n, 1..n, n, 0..p, 1..p, p..n, m..p, 0..*, 1..*. Visually a set is shown by an arc that connects all the edges that are part of the set. The multiplicity is drawn in the center of the arc. 17

· Relations between features can be expressed with for instance «requires» relationships. Meanwhile, if those features are located in various, non adjacent parts of the graph, the relationship between them may not be shown. Indeed, it can reduce the feature diagrams clarity. Instead, such relations can be described in a textual form in the feature model. 2. Evaluation The first intention when describing this notation was not to model variabilities but to simplify feature models. Indeed, when we want to group features, we simply have to mark all of them optional and to express multiplicities. This notation seems quite appropriate to model variabilities. Nevertheless, variation points are not explicitly represented even if cardinalities can be identified. Thus, a specific construct for variation points seems to be interesting in the context of variability in software product lines. Moreover the cardinalities 0..* and 1..* should be avoided and replaced respectively by 0..n and 1..n as usually the number of features in the set or the number of possible variants is known. The following example (see figure 9) is a feature diagram of a library system which is presented with multiplicity.

Figure 9: Feature Diagram with multiplicities: Library system [RBSP02]

18

3.3

Modelling Variability with Use Cases

The success of use cases to describe and communicate functional requirements in single product development has generated ideas to adapt this approach for software product lines development [HP01]. Many authors agree that classical use cases are not sufficient to represent product line requirements [HP03], [BFG+ 02], [GS02], [JM02c], [JM02b], [GFd98], [vdML02] and especially variabilities, variants, binding times... but their solutions to extend use cases are quite different. In the following sections, first we will shortly define use cases, then we will discuss variability in classical use cases and, finally, we will study various approaches designed to extend them. 3.3.1 Classical Use Cases

Pfleeger claims in [Pfl01] that "a use case describes particular functionalities that a system is supposed to perform or exhibit by modelling the dialog that a user, external system, or other entities will have with the system to be developed." As proposed by A. Cockburn in [Coc01], " use cases capture a contract between the stakeholders of a system about its behavior". The main goals of use cases are to elicit functional requirements and to facilitate the communication between those stakeholders who have to define clearly what the system will do, or more exactly, a fraction of their requirements on the system. Use cases do not deal in depth with non-functional requirements. Meanwhile, they are largely popular as all the stakeholders from non-technical to computer scientists can understand and contribute to the evolution of those scenarios describing possible interactions between the external actors and the system. If the number of connections between use cases is reasonable, it is possible to extract and study one use case without having to learn about the whole system and the other users. Classically, a use case description is composed of use case diagrams and use case textual descriptions. The diagrams correspond to graphical syntax conventions defined in UML with actors, use cases (graphical descriptions of the interactions between the actors and the system), system scope, use case relationships (extend, include, generalization). The textual description follows a template and is typically defined by a structured natural language for each use case, which is usually adapted following the application domain. It generally contains information like use case name, actors involved, pre- and post-conditions, flow of events, exceptions or possible variants in the flow.

3.3.2

Variability and classical Use Cases

As shown in [HP03], classical use cases can be used to model variabilities but lead to certain shortcomings. In general, the use case's definition allows to represent functions or users variability but brings also some restrictions. For instance, modelling data's variability with use cases diagrams is impossible, they have to be modelled in use case textual descriptions

19

Concerning use case diagrams, standard relationships like «generalization», «extend» and «include» are used to represent variabilities. Nevertheless, this representation is not relevant to express clearly variability. Indeed, shortcomings are revealed when we fail to distinguish extend relationships corresponding to variant from classical extend relationships. Instead, the variation concerning various categories of essential variabilities (see figure 1), like usage environment, behavior, constraints and type of usage, can not be represented [HP03]. Moreover, the variation points, the variation point cardinalities and the variants can not be explicitly represented. Concerning use case templates, pre- and post-conditions or alternative and exceptional scenarios may seem interesting to represent variability. Meanwhile, as the information is contained in the textual representation, a new challenge consists in differentiating classic alternative scenarios handling for instance exception scenarios and variability alternative scenarios. Moreover, it implies that use case templates become overloaded and too heavy for practical use. 3.3.3 Extending Use Case templates

One of the first approach [BNT02] to customize use cases with simple textual parameterization was proposed by Biddle. A Macro processor was used to write use case text with embedded parameters for specific details. Another approach [BNT02] was to develop a tool called Ukase to reuse use cases. The main idea was to provide a use case repository that helps finding patterns in use cases, facilitates use case copy-and-edit and support parameterized use cases. Those techniques have revealed some pitfalls [BNT02] concerning component sharing and traceability management which are keys for success in software reusability. In [BFG+ 02], the idea is to adapt use case templates to express variabilities. Two different solutions are proposed by Bertolino and al.: the first one called "tag representation" supposed that a use case must be separated following the family level and the product level. The second solution called "flat representation" includes in one specific use case the classical use case and its variabilities. In the tag representation, the variabilities are expressed by (optional, alternative or parametric) tags into the scenarios which identify and specify the variabilities. In the flat representation, the variabilities are included directly in the use case template. Those solutions have both their advantages and drawbacks; the use of tags gives a more dynamic perspective and allows easier requirements evolution while the "flat representation" gives a more direct vision on the variabilities which must stay quite stable. The tag representation is also used in [FGJ+ 03] to define the Product Line Use Cases (PLUCs) notation which is used to elicit and specify use cases for product lines based on existing user documentation. The following mobile phone example [BFG+ 02] has been used to illustrate the tag and flat representations.

20

The tag representation

Primary Actor: the {[V0] 33-serie} mobile phone Goal: play a game on a {[V0] 33-serie} mobile phone and record score Preconditions: the function GAME has been selected from the main MENU Main Success Scenario: - The system displays the list of the {[V1] available} games - The user select a game - The system displays the logo of the selected game - The user selects the difficulty level by following the {[V2] appropriate} procedure and press YES - The system starts the game and plays it until it goes over - The user records the score achieved and {[V3] possibly} send the score to Club Nokia via WAP - The system displays the list of the {[V1] available} games - The user presses NO V0: alternative V0: 1. Nokia 3310 model 2. Nokia 3330 model V1: optional if V0=1 then game1 or game2 else if V0=2 then game1 or game2 or game3 V2: parametric if V0=1 then procedure-A: - press Select - scroll to Options and press YES - scroll to Difficulty Level and press YES - select the desired difficulty level, press YES else if V0=2 then procedure-B: - press Select - scroll to Level and press YES - select the desired difficulty level, press YES V3: parametric if V0=1 then function not available else if V0=2 then function available

21

The flat representation

Primary Actor: The 3310/3330 mobile phone Goal: play a game on a 3310/3330 mobile phone and record score Preconditions: the funcextend_usecase.epstion GAME has been selected from the main MENU Main Success Scenario: - 3310 model: The system displays game1 or game2 3330 model: The system displays game1 or game2 or game3 - The user select a game - The system displays the logo of the selected game - The user selects the difficulty level by following this procedure: 3310 model: press Select scroll to Level and press YES select the desired difficulty level and press YES 3330 model: press Select scroll to Options and press YES scroll to Difficulty Level and press YES select the desired difficulty level and press YES - The system starts the game and plays it until it goes over - The user records the score achieved - 3330 model: send the score to Club Nokia via WAP - 3310 model: The system displays game1 or game2 3330 model: The system displays game1 or game2 or game3 - The user presses NO

3.3.4

Extending Use Case diagrams

· Gomaa's Notation Gomaa insists on the need to model software product lines with multiple views based on UML notation. The use case model, static model, collaboration model, statechart model and feature model constitute for him the basic views on software product lines. In the following, we will focus on the specific use case model that captures the functional requirements. In order to model variability in product lines, Gomaa has first described different types of features: Kernel features, optional features and variant features. He has also introduced the feature condition associated with optional feature. A feature condition is true for a given family's member if the corresponding feature is selected. Gomaa has translated those concepts in the use case context [GS02]. 1. Syntax Kernel use cases define use cases required by all members of the family. Optional use cases define use cases required by some but not all members of the family. This distinction is given by a specific condition associated with optional use cases. 22

Variant use cases define use cases with different versions which are required by different members of the family. To model variation points, the extension points and the extend relationship are used. UML stereotypes «kernel», «optional», and «variant» are used to distinguish kernel, optional, and variant use cases.[Gom01]. 2. Evaluation With this notation, the common and variable use cases are clearly identified. Nevertheless, decision points are difficult to identify as variation points are not explicitly represented. In addition, cardinalities are not described. By default, the variants are supposed to be mutually exclusive. The next exemple (see figure 10) presents variation in the "Move Part to WorkStation" use case in the factory automation product line.

Figure 10: Gomaa Extended UseCase diagrams: factory automation system [GS02]

23

· Halmans and Pohl's Notation In [HP03], Günter Halmans and Klaus Pohl present an extension to use case diagrams. The first step in their approach is to describe what classical use case diagrams can represent in the software product lines context and what they can not represent. The second step is to propose an extension to use case diagrams to alleviate some of these shortcomings. Their main idea is to extend the standard UML notation for use case diagrams and define new minimal graphical addiction notations. Concepts like variants, mandatory and optional variation points and mandatory and optional relationships are defined. 1. Syntax variation points are represented by an «include» relation followed by a triangle. A variation point is defined as mandatory if for at least one relationship to its variants the minimum cardinality is greater than 0. This variation point is represented by a black-filled triangle. A variation point is defined as optional if for all relationships originating from it the minimum cardinality is 0. This variation point is represented by an unfilled triangle. Variants are represented by stereotype «variant». Variants are always linked with one or more variation points. We define, for the rest of this survey, a constant n which indicates the number of variants associated to a specific variation point. Relationships between a variation point and its variants are represented by a "tree-like relationship" annotated with Cardinalities which indicates the minimum number of variants which have to be selected for this relationship and the maximum number of variants which can be selected for this relationship. A relationship is defined as mandatory if the minimum and maximum cardinalities are equal to the number of variants associated to the variation point. This relationship is graphically represented by a black-filled circle at the bottom of the triangle. A relationship is defined as optional in two cases: if the minimum cardinality is equal to 0 or if the minimum and maximum cardinalities are strictly contained in the interval ]0,n[. This relationship is graphically represented by an empty circle at the bottom of the triangle. Mandatory and optional relationships can be combined under the same variation point in order to be more expressive (see variation point "Payment method" in figure 11) . It means that the above defintions of mandatory and optional relationships must be refined; changing the constant n by a constant n' indicating the number of variants associated to the variation point via the relationship under consideration. 24

2. Evaluation The main advantage of this notation is its expressiveness. Indeed, the variation point and the variants are explicitly represented, defining variation points with specific names and constructs. We have also the possibility to model system actors variability. Moreover, optional relationships, unlike other notations, are clearly represented with an optional variation point construct. Finally, the key innovation in this notation is the explicit representation of variation points cardinalities assuring better expressiveness. Nevertheless, in some cases, the notion of variant is not absolutely clear as we have the possibility to define a "variant" which has a mandatory relationship with a mandatory variation point. We consider this specific variant as a simple commonality that we should represent by a classical use case with an «extend» or «include» relationship. Furthermore, the notion of "mandatory variant" seems, for us, quite ambiguous. Indeed, a variant is intuitively not mandatory. But this "mandatory variant" construct allows to regroup variants and commonalities use cases which have specific domain interconnection. For example, in figure 11 the use cases payment method by card, check and bill are clearly related even if the payment by card is a commonality. Moreover, this solution allows to relate one variant to different variation points with at least one optional relationship and 0-N mandatory relationship(s). Indeed, the authors consider that some variants can be optional under certain variation points and mandatory under others. In the future, this graphical notation will be coupled with a textual description that will allow to express more types of variabilities (for instance data variability), and to be more accurate without overloading the graphical representation. In figure 11, a fly booking example is presented.

25

Figure 11: Halmans Extended UseCase diagrams: fly booking system [HP03] 3.3.5 Add Decision Model and Extend Use Case diagrams & templates

Isabel John and Dirk Muthig, in [JM02b] and [JM02c], define Generic Use Case diagrams and Generic Textual Use Cases. 1. Syntax

· Two different parts compose a Generic Use Case diagram (figure 12); the first represents the common story that is valid for all the members of a system family with variation points, the second represents the variant use cases. A variant use case contains scenarios which are supported by some but not all products in the family. · Concerning Generic Textual Use Cases (figure 13) , they describe variant text fragment and variant in the scenario using XML-like tags and . · The variant use cases are instantiated during application engineering. The instantiation process is guided by a decision model (see figure 14 ) , which captures the motivation and interdependencies of variation points. The decision model can also describe whether a use case is an optional use case or whether it is an alternative to a use case. 2. Evaluation John and Muthig argue that use case diagrams, use case textual descriptions and the decision model must be coupled to represent and detail variability. The issue is to find which information has to be defined in an understandable graphical representation and which information has to be defined in a textual description to detail variability. Lacks of information appeared in generic use case diagrams as variation points 26

and their cardinalities are not explicitly represented. Furthermore, distinction between optional and alternative variants can not be graphically expressed. This information is contained in the decision model which also captures the traceability paths from variant use case scenarios down to variant implementation elements. Nevertheless, the decision model is unformal and its complexity will increase relatively quickly as systematic tools can not be easily developed over natural language. The following example presented in figure 12, 13 and 14 is a cruise control system with an optional distance regulator.

Figure 12: Generic Use Case diagrams: Cruise Control system [JM02a]

27

Use Case Name: keep velocity Short Description: keep the actual velocity value over gas regulator and control the distance to cars in front Actors: driver, gas regulator, actor distance regulator Trigger: actor driver, actor distance regulator Precondition: -Input: starting signal, velocity value vtarget Output: undefined Postcondition: vactual = vtarget Success guarantee: vactual = vtarget Minimal guarantee: The car keeps driving Main Success Scenario: 1.) is selected by actor driver 2.) Does a distance regulator exist? get vactual () get dactual dtarget () 3.) Does a distance regulator exist? - compare vactual and vtarget If vactual If vactual > vtarget : gas regulator decrease velocity - restart else restart - compare vactual and vtarget If vactual < vtarget and dactual > dtarget: gas regulator decrease velocity - restart else If vactual > vtargetand dactual < dtarget: gas regulator increase velocity - restart else restart

Figure 13: Generic Use Case templates: Cruise Control system [JM02a]

28

Variation Point 1

Decision The car has no distance regulator

Actions

· Remove Use Case "set distance" from use case diagram · Remove Actor "radar sensor" from use case diagram ... · Remove variant from use case "keep velocity" point 2 · Remove variant from use case "keep velocity" point 3... 1 The car has distance regulator · Remove the «variant» tag from all use cases in the use case diagram · Remove the tag and the tag from use case "keep velocity" point 2... Figure 14: Partial Decision Model : Cruise Control system [JM02a]

3.4

Modelling Variability with Use Cases & Feature Diagrams

In [GFd98], Griss introduces that the combination of use cases and feature model presents a good solution to model software product lines. But in their methodology called FeatuRSEB, use case models are used in their simplest expression to provide a complete description of what the system should do. Meanwhile, use cases are not used to model variabilities but principally to elicit user requirements and to link them with the features. As it has been shown in section 3.1.3, the variabilities are represented with feature diagrams (see figure 6). This results are coming from the commonalities and variabilities analysis and will be used during the domain engineering and the reuse process. In [vdML02], Thomas von der Maßen goes a step further and introduces a combination of feature diagrams and use cases in order to represent variabilities. On the one hand, feature diagrams are suitable to describe the characteristics of a domain and the relationship between them while, on the other hand, use cases are able to model sequence of activities, dynamic characteristics and dependencies between those activities. This combination allows, in a first step, to capture variability and essential activities of a domain with use cases and, in a second step, to detail common and variable characteristics with feature diagrams. However, use cases defined by Cockburn [Coc01] are not sufficient when it comes to product lines [vdML02]. Thus, the author [vdML02] proposes to extend the UML Use Case Meta-Model (figure 15) in order to (1) integrate the concept of variation point which is a specialization of the extension point and to (2) integrate the option and alternative relationships between use cases. 29

Figure 15: Extended UseCase MetaModel [vdML02] 1. Syntax · Variation points are extension points associated to a use case with one or more «alternative» relationships. · Alternative variant is a use case which is linked by an «alternative» relationship and which is not the basis of this «alternative» relationship. · optional variant is a use case which is linked by an «option» relationship and which is not the basis of this «option» relationship. 2. Evaluation The idea to combine feature diagrams and use cases to represent variability gives a better variability overview combining two complementary views. Nevertheless, concerning the extended use cases meta-model, the «option» and «alternative» relationships do not allowed to express cardinalities. Variation points are represented like extension points but are not explicitly identified. Furthermore, actors variability can not be expressed. The following example (see figure 16) illustrates a use diagram of a fly booking example corresponding to van der Maßen use case meta-model.

30

Searching a flight

<> <> Booking by airline company

Booking a flight <> Customer <> Booking by travel agency

Paying a booking flight

<>

Changing a reservation

<>

<>

<>

Paying by credit card

Paying by check

Paying by Bill

Figure 16: Van der Maßen Extended UseCase MetaModel: fly booking system

3.5

Modelling Variability with UML Class Diagrams

In [Cla01b], Clauss proposed to extend feature diagrams with UML Class Diagrams. 1. Syntax

· The features are organized in a tree with the modelled concept as the root constructed from composition or generalization relationships from the branches of the tree. · Mandatory, optional and alternative features are represented with stereotypes, «Mandatory», «optional» and «alternative». · Xor-relationships (Exclusive) are represented by a group of «is a » relationships which have the same feature as basis. · Or-relationships (Non-exclusive or alternatives) are represented by a group of «composed of» relationships which have the same feature as basis. · Mutual exclusion relationship between features is also represented with «mutex» dependencies. · The «requires» dependency between features A and B indicates that if the feature A is selected then the feature B will be also selected. 2. Evaluation This notation offers the possibility to represent graphically relationships between variants with «mutex» or «requires» relationships. Nevertheless, the variation point, the variation point cardinalities, are not explicitly represented. This feature diagrams notation looks more like FODA's notation with UML class diagrams constructs. 31

Figure 17: Extended UML Feature Diagram: Order process system [Cla01b] The following example, presented in figure 17, shows an order process system feature diagram. In [Cla01a], Clauss extends UML Class Diagrams to model variability. 1. Syntax · Every variation point is described by a class with «variation point» stereotype. Additional tagged values are added like the specification of a binding time chosen between development, installation, runtime or multiplicity (i.e. how many variants can be bound at binding time). · Every variant is described by a class with a «variant» stereotype and a condition tagged value. This condition specified when the variant has to be included. · The relationship between a variation point and its variants is simply modelled by the classical inheritance relationship. · Interactions between variants are modelled using dependencies "mutex" and "requires". Furthermore, the stereotype «optional» and usual tag values like binding times and condition are used to describe optional elements. 2. Evaluation The choice of an extended class diagrams to model variability seems quite interesting especially to model variability in data requirements. Moreover the variation point, their variants and the variation point cardinalities are explicitly represented.This notation could also be used to model architecture variability and to make the link with component diagrams. Classical OCL constraints can also be used to specify composition rules or specific constraints on the model.

32

Meanwhile some difficulties may appear concerning the distinction between requirements variability and architecture variability. Moreover, the optional elements are not directly related to a variation point and are defined as elements which exist under some circumstances and in others not. The example presented in figure 17 has been reused by Clauss in figure 18 to illustrate the extended UML class diagram notation representing variability in an "order process system".

Figure 18: Extended UML Class Diagram: Order process system [Cla01a]

4

Comparison between graphical notations designed to model variation points and variants

Various authors have proposed different notations to represent variabilities during requirements engineering. In this section, our objective is to select some notations and to compare them in order to be able to choose, to adapt, or to define a new notation responding to some specific needs. As we have seen before, mainly three different notation's types are used; feature diagrams, use cases models and UML class diagrams. When we want to model variability in functional requirements, the first decision to take is the choice between feature diagrams or use cases. We underline that both types of notations have their advantages and disadvantages. We consider that feature diagrams are mainly interesting when this model is designed to communicate with domain experts inside the company. Feature diagrams allow to describe graphically the requirements with a finer granularity than use cases. Indeed, feature diagrams can describe essential and technical requirements and, usu33

ally, use cases should describe essential requirements or tasks which have some added value for system users. We consider that use cases are interesting when this model is designed to communicate with clients of the final product to allow elicitation of requirements and of requirements variability. Use cases textual description, contrary to feature diagrams, can be used to represent variability in scenarios describing some variabilities in the behavior. However, we must refine this choice as our main purpose is to study how variability can be modelled explicitly and graphically. For us, the graphical aspect of the notation is important. Indeed, both graphical and textual representations are necessary, but graphical notations are often more expressive and understandable for common stakeholders. On the other side, textual descriptions are also important to define in more details variability. The idea is to concentrate first our efforts on graphical representations of variabilities which represent explicitly variation points and their variants. Thus, in the following, we select five notations in order to compare how they represent variability corresponding to our specific views: · Concerning feature diagrams notations, FeatuRSEB's notation [GFd98] and extended Riebisch's Notation [RBSP02] have been selected. We have made an exception and extended Riebisch's notation because this notation allows to define cardinalities in feature diagrams. The extension consists in a specific construct (round rectangle) to identify explicitly variation points. Bosch's [vGBS01] notation has not been chosen due to its important similarity with FeatuRSEB. FODA [KCH+ 90] and FORM's [KLD02] notation were not relevant in our selection as no explicit representations of variation point and variation point cardinalities are possible. · Concerning use case models, Gomaa's notation [GS02] and Halmans' notation [HP03] have been selected. Because they are not graphical, the different extended textual descriptions like the tag and flag representation from Bertolino and al.[BFG+ 02] or the generic textual use case from John and Muthig [JM02b] were put a side. The generic use case diagrams from John and Muthig [JM02b] and the notation from Thomas van der Maßen [vdML02] are not selected as variation points are not explicitly represented. · Concerning UML class diagrams the Clauss' notation [Cla01a] has been selected. In the next three figures, the comparison between those notations is presented. The idea is to compare various representations of variation points, variants and the relationships between them. In this figures, we consider n,k,p as constants, n representing the number of variants associated with the variation point, k and p representing a limited number of variants. In figure 20 and figure 21, we consider that n is greater than 1. Indeed, if we take the hypothesis that n is limited to 1, it implies that only one variant is associated with the variation point. It concerns the two classical relationships usually called mandatory (1-1) and optional (0-1) relationships (figure 19). Generally, those relationships are represented by "optional features" or "composed of" relationships. Optional relationships are not usually represented with a variation point, except in Halmans' notation where an optional variation point is used (see figure 19). Mandatory relationship (N-N) 34

where N is the maximum number of "mandatory features" is usually model like many single one, except in Halmans' notation where we have the possibility to use mandatory variation point and mandatory relationship notation to model it.
Feature Diagrams n=1 FeatureRSEB Riebisch extended Gomaa Use Cases Halmans Class Diagrams Clauss

Mandatory

Composed of

Composition & mandatory feature

<> <>
<> Use Case Name Extension points Name 1 [Condition] <>

<> <>

Class Diagram relationship 1-1
<< Optional >> Name {Binding time: [runtime, dvlpt,...], Condition}

Optional

Composed of & Optional feature

Composition & optional feature

VP Name
0-1

0-1

<> Name 1

<> UC

Figure 19: Comparison mandatory and optional relationships

35

Feature Diagrams n>1 FeatureRSEB VP Name (XOR) Riebisch extended VP Name M-N ... Variation Point VP Name (OR) ...
F1 Fn

Use Cases Gomaa
<> Use Case Name Extension points Name 1 Name n

Class Diagrams Clauss

Halmans

<>

...
F1 Fn

VP Name min..max
<> <>

<< Variation point >> VP Name {Binding time: [runtime, dvlpt,...], multiplicity: min..max}

... UC 1 UC n

<> Variant NameN {Condition: }

F2

F2

<> Name 1

Variant

...
<> Name n

<> UC 2

<> Variant Name1 {Condition: }

VP Name (XOR) ... 1-1
F1

VP Name 1-1 ...
F1

VP Name 1..1

{Multiplicity: 1}

...
F2 Fn F2

Fn

UC 1

...

UC n

VP Name 1-k where k<=n ...
F1 Fn F2

1-k

VP Name 1..k

{Multiplicity: 1..k}

UC 1

...

UC n

Figure 20: Comparison variability's representation

36

Feature Diagrams n>1 FeatureRSEB Riebisch extended VP Name 0-1 ...
F1 F2 Fn

Use Cases Gomaa Halmans

Class Diagrams Clauss

VP Name (XOR) ... 0-1
F1

...
F2 Fn

VP Name 0..1 UC 1 UC n

{Multiplicity: 0..1}

.. .. ..

0-k where 0
VP Name 0-k ...
F1 F2 Fn

VP Name 0..k UC 1 UC n

{Multiplicity: 0..k}

...

k-k where 0
VP Name k-k ...
F1 F2 Fn

VP Name k..k UC 1 UC n

{Multiplicity: k..k}

...

k-p where 0
VP Name k-p ...
F1 F2 Fn

VP Name k..p UC 1 . . . UC n

{Multiplicity: k..p}

Figure 21: Comparison variability's representation Some authors [Cla01a], [HP03] give the possibility to represent a variation point linked with various sets of variants within use cases like in figure 11 or within class diagrams like in figure 22.

37

Figure 22: Multiple variation point [Cla01a]

5 Case Study: Engine Monitoring
This case study has been adapted from the SPLC2 Workshop on Techniques for Exploiting Commonality Through Variability Management [SPC]. Our aim is to model graphically variability in an engine monitor system which provides information about fuel consumption and engine performances. The system manages different mandatory functions: · Monitor engine performance, · Monitor RPM, · Monitor (oil engine transmission) temperatures, · Monitor exhaust levels and temperatures, · Monitor fuel consumption. The system has one optional alternative function which consists in monitoring the coolant temperatures or not (Binding times: development). Different measures are offered to monitor the fuel consumption but only one must be chosen (Binding times: runtime): · Km/l · Miles/gal Different alternative methods are offered to monitor the fuel consumption but at least one must be chosen (Binding times: development): · Based on distance · Based on type of driving · Based on drive 38

In the following, our objective is to represent the engine monitor system variability with the various graphical notations which have been presented previously. For each notation, we will also describe the difficulties encountered. 1. FODA's Notation
Monitor Engine system

Monitor Engine Performance

Monitor Fuel Consumption

Monitor Monitor RPM Monitor exhaust Measures Temperatures levels and temperature

Methods

?
transmission coolant oil, engine l/Km galon/mile Based on distance Based on type of driving Based on drive

Figure 23: FODA's Notation Difficulties: · Variation points, variation points cardinalities and variants can not be explicitly identified. · Impossible to model that one or more fuel consumption methods can be used.

39

2. FORM's Notation
Monitor Engine system

Capability layer

?

Monitor Engine Performance

Monitor Fuel Consumption

Monitor Temperatures

Monitor RPM

Monitor exhaust levels and temperature

Measures

Methods

?
transmission coolant engine oil l/Km galon/mile Based on distance Based on type of driving Based on drive

Figure 24: FORM's Notation Difficulties: · Variation points, variation points cardinalities and variants can not be explicitly identified. · Impossible to model that one or more fuel consumption methods can be used. · Using the four layers generates complexity.

40

3. FeatuRSEB's Notation
Monitor Engine system

Monitor Engine Performance

Monitor Fuel Consumption

Monitor Monitor RPM Monitor exhaust Measures Temperatures levels and temperature

Methods

transmission coolant oil, engine

l/Km

galon/mile

Based on distance

Based on type of driving

Based on drive

Figure 25: FeatuRSEB's Notation Difficulties: · variation points cardinalities can not be explicitly identified

41

4. Bosch's Notation
Monitor Engine system

Monitor Engine Performance

Monitor Fuel Consumption

Monitor Temperatures
devlpt

Monitor RPM

Monitor exhaust levels and temperature
runtime

Measures

Methods

devlpt

transmission coolant engine oil

l/Km

galon/mile

Based on distance

Based on type of driving

Based on drive

External features ?

Figure 26: Bosch's Notation Difficulties: · Variation points cardinalities can not be explicitly identified. · External features could have been useful with a more complex case study.

42

5. Riebish's Notation
Monitor Engine system

Monitor Engine Performance

Monitor Fuel Consumption

Monitor Temperatures

Monitor RPM

Monitor exhaust levels and temperature

Measures 1..1

Methods 1..3

transmission coolant engine oil

l/Km

galon/mile

Based on distance

Based on type of driving

Based on drive

Figure 27: Riebisch's Notation Difficulties: · Variation points are not explicitly represented but cardinalities are.

43

6. Gomaa's Notation

<> Monitor Engine performance ---------------------------------Extension points Monitor coolant temperatures Monitor <> Monitor fuel consumption ----------------------------------Extension points Km/l Miles/gal Based on Type of driving Based on distance Based on drive

Include Include

<> Monitor RPM <> Monitor Temperatures (oil, engine, transmission) <> Monitor exhaust levels and temperature <> Monitor coolant Temperatures

Include [Condition] extend

extend <> Based on type of driving <> Based on distance <> Based on drive

Figure 28: Gomaa's Notation Difficulties: · Variation points, variation points cardinalities can not be explicitly identified. · Data variability concerning fuel consumption measures (k