Introducing Product Line Engineering in a Bottom-up Approach

Nelufar Ulfat-Bunyadi, Rene Meis, Nazila Gol Mohammadi and Maritta Heisel

Paluno - The Ruhr Institute for Software Technology, University of Duisburg-Essen, Duisburg, Germany

Keywords:

Product Line Engineering, Variability, Control System, Embedded System, Six-Variable Model.

Abstract:

The optimal way for introducing a product line is to set up a completely new product line by developing a

reuse infrastructure for the whole range of products right from the start. However, in practice, product line

engineering is frequently introduced by a company after having developed a number of products separately (i.e.

in single system engineering). The challenge then consists of deﬁning the product line based on these existing

products, i.e. to a certain extent these products have to be re-engineered. More precisely, two problems need

to be solved: ﬁrst, commonality and variability among the existing products needs to be identiﬁed to deﬁne a

common set of core assets, and, second, the way in which future systems (i.e. products of the product line)

will be developed based on this common set of assets needs to be deﬁned. The method we suggest in this

paper solves these two problems. Our method focuses on control systems, i.e. systems which monitor/control

certain quantities in their environment.

1 INTRODUCTION

A (software) product line is deﬁned as follows

(Clements and Northrop, 2002): “A software product

line is a set of software-intensive systems sharing a

common, managed set of features that satisfy the spe-

ciﬁc needs of a particular market segment and that

are developed from a common set of core assets in a

prescribed way.” The process of developing a prod-

uct line is referred to as product line engineering (Pohl

et al., 2005). Companies introduce product line engi-

neering due to diverse reasons, for example, in order

to improve time-to-market, to improve product qual-

ity, to increase customer satisfaction, to enable mass-

customization, etc. (Clements and Northrop, 2002).

In a nutshell, substantial production economies can

be achieved by developing systems in a product line

instead of separately. Depending on the situation, dif-

ferent strategies may be used to introduce a product

line (Schmid and Verlage, 2002). Ideally, no prede-

cessor products exist and a new product line is set

up right from the start by developing a reuse infras-

tructure for all products of the product line. Yet, in

practice, companies often use a more incremental ap-

proach (Schmid and Verlage, 2002): frequently, pre-

decessor products exist that need to be integrated into

product line development. Therefore, they need to be

re-engineered. In this paper, we present a method

for introducing product line development in such a

situation. Our method supports developers in iden-

tifying commonalities and variability in the existing

products, deﬁning core assets for the product line (re-

stricted to requirements artefacts), and deﬁning how

future products can be derived in the product line. We

focus mainly on control systems.

The paper is structured as follows. In Sect. 2,

we present fundamentals which provide the basis of

our method. In Sect. 3, we describe our method and

the tool support we provide. In Sect. 4, we describe

the application of our method to a real example. In

Sect. 5, we discuss related work. Finally, in Sect. 6,

we provide a conclusion and an outlook on future

work.

2 FUNDAMENTALS

Context and Problem Diagrams. Context and prob-

lem diagrams have been introduced by Jackson (Jack-

son, 2001). He differentiates between the system, the

machine, and the environment. A system is a gen-

eral artefact that might have both, manual and au-

tomatic components. The machine is the computer-

based artefact of the system and is the target of soft-

ware development. The environment is a portion of

the real world that is becoming the environment of the

development project, because its current behaviour

is unsatisfactory. The machine will be connected to

this environment so that the behaviour of the environ-

146

Ulfat-Bunyadi, N., Meis, R., Mohammadi, N. and Heisel, M.

Introducing Product Line Engineering in a Bottom-up Approach.

DOI: 10.5220/0006006001460153

In Proceedings of the 11th International Joint Conference on Software Technologies (ICSOFT 2016) - Volume 2: ICSOFT-PT, pages 146-153

ISBN: 978-989-758-194-6

ment becomes satisfactory. According to Jackson’s

approach (Jackson, 2001), ﬁrst a context diagram is

created showing the machine in its environment. Then

the overall software development problem is decom-

posed into subproblems and each subproblem is doc-

umented in a problem diagram. A context diagram

usually consists of the following modelling elements:

the machine domain, problem domains, and interfaces

between them (see Fig. 8 for an example). The ma-

chine domain is the software-to-be. A problem do-

main represents a material or immaterial object in the

environment (e.g. people, other systems, a physical

representation of data). An interface expresses that

phenomena (e.g. events, states, values) are shared be-

tween the domains it connects. At the interface, the

shared phenomena are annotated and, by means of

an exclamation mark, the domain controlling them is

indicated. For creating problem diagrams, the same

modelling elements are used. In addition, a problem

diagram contains a requirement which is to be satis-

ﬁed by the machine domain and the problem domains

shown in the problem diagram (see Fig. 9 for an ex-

ample). The requirement is connected to the problem

domains by means of at least one constraining ref-

erence, and optionally a requirement reference. The

latter means that the requirement refers somehow to

the domain phenomena. The former means that the

requirement even constrains the domain phenomena.

In context and problem diagrams, so called connec-

tion domains may be modelled as well. A connec-

tion domain is “a domain that is interposed between

the machine and a problem domain” (Jackson, 2001).

Examples of connection domains are sensors and ac-

tuators. They connect the machine to the environmen-

tal domains that are monitored/controlled. According

to Jackson, they can be omitted in context/problem

diagrams if they are reliable.

The Six-Variable Model. We introduced the Six-

Variable Model in previous work (Ulfat-Bunyadi

et al., 2016). It is based on the famous Four-Variable

Model for control systems deﬁned by Parnas and

Madey (Parnas and Madey, 1995). The four vari-

ables are monitored, controlled, input, and output

variables. Monitored variables m are environmen-

tal quantities the control software monitors through

input devices like sensors. Controlled variables c

are environmental quantities the software controls

through output devices like actuators. Input vari-

ables i are data items that the software needs as in-

put, and output variables o are quantities that the

software produces as output. We made the obser-

vation that in practice it is sometimes not sufﬁcient

to document only the four variables. As require-

ments are reﬁned and the decision is made which sen-

Control

machine

Environmental

domain W

REQ

Environmental

domain Z

SE!i

CM!o

Sensors

EW!m

EW!r

Actuators

EZ!d

AC!c

Legend:

r: environmental properties originally referenced by the requirement

d: environmental properties that shall be as desired by the requirement

m: variables actually monitored by sensors

c: variables actually controlled by actuators

i: input variables

o: output variables

Sensors/actuators/other

systrems connecting

software-to-be to reality

Requirement

in real world

Software-to-be

Remote problem

domains

in real world

Figure 1: Six-Variable Model (Ulfat-Bunyadi et al., 2016).

sors/actuators/other systems to use for monitoring and

controlling, the environmental quantities that have

been relevant in the requirements at ﬁrst (i.e. before

decision making) are replaced by the environmental

quantities that can actually be monitored/controlled

by the selected sensors/actuators/other systems. Ex-

isting approaches (like the Four-Variable Model) only

call for documenting the environmental quantities

that are ﬁnally relevant and that are actually moni-

tored/controlled. The quantities that have been rele-

vant originally, are not documented. This results in

problems when the software shall be reused in an-

other context/environment with slightly different sen-

sors/actuators. Then it is hard for developers to de-

cide, which environmental quantities still need to be

monitored/controlled and which ones not. Therefore,

we argue that six variables should be documented: the

four variables i, o, m, c and additionally r and d (see

Fig. 1). r represents the environmental quantities that

were originally referenced in the requirement and d

represent the environmental quantities that shall be as

desired by the requirement.

In Fig. 2, an example of documenting the six vari-

ables is given. We used the famous patient monitoring

system as an example here. The machine is intended

to notify a nurse if the patient’s heartbeat stops. The

machine is connected to a sensor and an actuator. The

sensor detects the sound in the patient’s chest. If the

patient’s heart has stopped beating, the sound from

the patient’s chest falls below a threshold for a cer-

tain time. Then, the machine raises the sound of the

buzzer to inform the nurse. The referenced variable is

the patient’s heartbeat, the monitored variable is the

sound in the patient’s chest, and the input variable is

the corresponding value measured by the sensor. The

output variable is ‘sound on/off’, the controlled vari-

able is the buzzing of the buzzer, and the desired vari-

able is that the nurse is informed.

Essence versus Incaration. The differentiation be-

tween essence and incarnation of a system was intro-

duced as part of Essential Systems Analsis in 1984

Introducing Product Line Engineering in a Bottom-up Approach

147

Machine

Buzzer

Sensor

S! {measured value}

M! {sound ON,

sound OFF}

Nurse

P! {sound in chest}

B! {buzz}

Inform nurse

when

heartbeat stops

P! {heartbeat}

Patient

N! {informed}

Figure 2: Exemplary documentation of six variables.

(McMenamin and Palmer, 1984). The essence of

a system comprises the capabilities it must possess

to fulﬁl its purpose, regardless of how it is imple-

mented. The incarnation comprises all implementa-

tion details. For identifying the essence of a system,

the following heuristic is used: One assumes that the

technology within the system is perfect, this means

that processors, for example, are able to do anything

constantly and containers (data stores) are able to hold

an inﬁnite amount of data. The technology outside the

system is not assumed to be perfect.

3 BOTTOM-UP METHOD

3.1 Method Steps

Fig. 3 provides an overview of our method. We ex-

plain each step in the following in more detail. The

main idea is that we model, for each existing system,

the essence on the one hand (Steps 1 and 2) and, in-

dependent of that, the incarnation on the other hand

(Step 3). Creating an incarnation model means that

the corresponding system is modelled as it is. Cre-

ating an essential model is more difﬁcult, since the

information required to create the model is frequently

not documented and existed only at the beginning of

the system development project, in which the corre-

sponding system was developed. Mining this knowl-

edge is therefore more complicated. Confronting the

essential model with the incarnation model helps de-

velopers to reﬂect on the quantities that are moni-

tored/controlled and on the reasons why this is done,

i.e. which environmental phenomena originally have

been relevant in the real world.

Step 1: Create essential context diagrams. As a

ﬁrst step, an essential context diagram needs to be

created for each existing system. To focus on the

essence, we use a heuristic: we assume that the tech-

nology outside the machine is perfect. This means

that we assume that all connection domains are reli-

able and we do not model them therefore. A major

challenge in Step 1 consists in identifying the envi-

ronmental domains that are actually relevant in the

real world. Sometimes they are not made explicit in

existing documentations. The main question to be an-

swered is: What shall be monitored/controlled in the

environment? In this step, it is not important how this

is achieved, since we focus on the essence. Therefore,

in the context diagram (see Fig. 4, left hand side),

only the problem domains that are relevant in the real

world are shown and, at the interfaces to the machine,

the r and d variables are annotated that are relevant

from an essential view. We call them r

ess

and d

ess

Step 2: Create essential problem diagrams. Based

on the essential context diagrams from Step 1, essen-

tial problem diagrams are created during this step. For

each essential context diagram, usually several essen-

tial problem diagrams are created, since the consid-

ered machine usually has to satisfy several require-

ments and each requirement is modelled in a sepa-

rate problem diagram. The right hand side of Fig. 4

shows the information that needs to be shown in an

essential problem diagram. Note that we still abstract

from connection domains and focus on the r

ess

and

ess

variables. Since we assume perfect technology

(i.e. perfect sensors and actuators), the requirement

refers to/constrains the same phenomena as the ones

shared with the machine. Note that the requirement

(Req

ess

) represents an essential requirement, i.e. it de-

scribes what shall be achieved in the real world with-

out being biased by the technology to be used.

Step 3: Create incarnation problem diagrams. In-

dependently of the diagrams from Step 1 and 2, in-

carnation problem diagrams are created during this

step for each system. During this step, we take im-

plementation details into account and, therefore, we

model all connection domains. The diagram on the

left-hand side of Fig. 5 shows which information

needs to be shown in an incarnation problem dia-

gram. At the interfaces between the machine, connec-

tion domains (sensors/actuators), and environmental

domains (monitored/controlled domains), we anno-

tate now the six variables from an incarnation view

inc

). Creating these incarna-

tion diagrams independently of the essential diagrams

has the beneﬁt that we once focus on the r and d vari-

ables from an essential view and the other time we

focus on them from an incarnation view. In this way,

it is more likely that we ﬁnd differences between r

ess

and r

inc

as well as d

ess

and d

inc

variables. Note that

we welcome such differences. Essence and incarna-

tion are often different. It is only important that the

difference is traceable and therefore we document it

now, i.e. in retrospect.

Step 4: Ensure that r

inc

variables map to

ess

variables. During this step, we try to map

the r

inc

variables to the r

ess

variables (see

Fig. 5), i.e. we try to answer the question, why

each r

inc

is monitored and why each d

inc

is effected

by identifying their relations to certain r

ess

vari-

ables. The reasoning explaining, why the variables

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

148

external

input

method

steps

input

output

Step 2:

Create essential

problem diagrams

Step 3: Create

incarnation problem

diagrams

Step 4:

Ensure that r

inc

variables map to

ess

variables

Step 5:

Introduce variation

points and variants

Any existing

documentation

Incarnation problem

diagrams for each system

Revised essential

and incarnation

diagrams

Essential problem

diagrams for each

system

Step 1:

Create essential

context diagrams

Domain

expertise

Essential context

diagrams for each

system

OVM with

dependencies

Step 6:

Identify constraint

dependencies

Domain

expertise

Figure 3: Overview of our method.

Control

machine

Monitored

domain

ess

Controlled

domain

ess

System X

Control

machine

Monitored

domain

Req

ess

Controlled

domain

System X

Information to be shown in an

essential context diagram

Information to be shown in an

essential problem diagram

ess

Figure 4: Information in essential diagrams.

Control

machine

Monitored

domain

Controlled

domain

System X

Control

machine

Monitored

domain

Req

inc

Controlled

domain

System X

Sensor

Actuator

inc

ess

Req

ess

Figure 5: Mapping essence and incarnation.

map, is documented textually. At the end of this step,

for each r

inc

variable, such a documentation must

exist. Thus, the term mapping does not mean that r

inc

and r

ess

as well as d

inc

and d

ess

variables need to be the

same. Rather, it means that r

inc

needs to reﬂect actu-

ally r

ess

and that d

inc

needs to result actually in d

ess

Even the environmental domains may be different to

a certain extent, e.g. a domain shown in the essential

diagram may be decomposed and shown as two do-

mains in the incarnation diagram. This is allowed but

should be traceable and documented in the reasoning.

If the discrepancy is not traceable, one should con-

sider revising one/both diagrams to identify the cause

and correct the diagrams from Steps 1-3.

Step 5: Introduce variation points and vari-

ants. Based on the (probably revised) diagrams from

Step 4, variants and variation points are introduced.

Usually there are different variants for one r

ess

variable, since different sensors/actuators may be

used. Therefore, we recommend to create incarna-

tion diagram fragments for the variants as shown in

Fig. 6. To depict variation points and variants (i.e.

the choices that can be made), we suggest creating an

OVM (Orthogonal Variability Model) (Pohl, 2010).

The variation points and variants are then related to

the essential and incarnation problem diagram frag-

ments by means of so called artefact dependencies.

Step 6: Identify constraint dependencies. Usually,

OVM

Name

VP X

Name

VP Y

Name

Control

machine

Monitored

domain

Req

ess

PD Fragment

Control

machine

Monitored

domains

PD Fragment

Sensor

Control

machine

Controlled

domain

PD Fragment

Actuator

Control

machine

Controlled

domain

PD Fragment

ess

Req

inc

Req

ess

Req

inc

ess

inc

Figure 6: Diagram fragments as variants.

the selection of variants at one variation point may af-

fect the available choices at another variation point: a

variation point may require/exclude another variation

point, a variant may require/exclude another variant,

and a variant may require/exclude a variation point

(cf. (Pohl, 2010)). Such relationships are called con-

straint dependencies. Since we create the OVM based

on the (essential and incarnation) problem diagrams,

it is likely that not all constraint dependencies that ac-

tually exist, will directly be identiﬁed. Therefore, we

introduce this step. During this step, the developers

must reﬂect on constraint dependencies that might ex-

ist and document them.

After Step 6, the product line is deﬁned and initi-

ated. To derive concrete products of the product line,

developers need to select variants and to compose the

related essence and incarnation diagram fragments to

whole context/problem diagrams for their product.

3.2 Tool Support

By means of our method, the OVM as well as core as-

sets for the product line are created (in Steps 5 and 6).

The tool support we present in this section helps de-

velopers in creating and maintaining these core assets

and the OVM together with its artefact and constraint

dependencies. We use the UML4PF proﬁle proposed

by Hatebur and Heisel (Hatebur and Heisel, 2010) as

a basis. This proﬁle allows describing context and

Introducing Product Line Engineering in a Bottom-up Approach

149

Figure 7: OVM Proﬁle extending UML4PF.

problem diagrams using UML class diagrams. It has

already been extended by Alebrahim et al. to sup-

port variability (cf. (Alebrahim et al., 2014)). Yet,

this variability proﬁle does not support the orthogo-

nal modelling of variability. To support orthogonal

variability modelling, we adapted the variability pro-

ﬁle and present the resulting OVM proﬁle (see Fig. 7)

in the following. Due to space limitation, we mainly

explain the adaptations we made.

The variability diagram captures the variation

points and variants (i.e. it represents the OVM). The

essence and incarnation diagram fragments are spe-

cialisations of problem diagrams. The conﬁguration

diagram captures the selected variants for a certain

product of the product line. Product context and prod-

uct problem diagrams are diagrams that are created

when deriving products of the product line. Therein,

essence/incarnation diagram fragments are composed

to build whole context/problem diagrams. An impor-

tant extension that we made, which allows for mod-

elling the variability orthogonally to the other dia-

grams, is that we deﬁned artefact dependency as a

specialisation of dependency. This allows for mod-

elling artefact dependencies between the OVM and

diagram fragments. Furthermore, we maintain vari-

ation points and variants exclusively in the variability

diagram. They are not scattered across various dia-

grams.

4 APPLICATION EXAMPLE

As examples, we use ACC (Adaptive Cruise Con-

trol) systems. Real ACC systems are described

in (Robert Bosch GmbH, 2003) and (Robert Bosch

GmbH, 2006). The description of the three systems

we use in the following is based on these documents.

We assume that they are existent and, based on them,

product line engineering is introduced:

System 1: Simple ACC. System 1 uses a long range

radar (LRR) sensor and ESP (Electronic Stability Pro-

gram) sensors. The LRR provides information about

speed, distance, and lateral offset of objects ahead.

ESP sensors measure the yaw rate, lateral accelera-

tion, steering wheel angle, and wheel speed of the

ACC vehicle. Based on this data, the ACC software

is able to calculate the yaw rate corrected for offset

which is needed to determine the projected course of

the ACC vehicle. Based on the projected course of the

ACC vehicle and the lateral offset of a detected ob-

ject, the lane of the object can be estimated. If the de-

tected object is on the same lane as the ACC vehicle,

it is identiﬁed as a target object (for tracking). If it is

not on the same lane, it is considered to be irrelevant.

However, the ACC software (using these sensors) is

not able to decide with sufﬁcient certainty, whether

or not an object is in the same lane as the ACC vehi-

cle. Therefore, stationary objects are ignored by the

ACC constant-gap function, i.e. only moving objects

can be selected as target objects for tracking. Due to

the large number of stationary objects at the roadside,

the likelihood for the ACC software reacting to one of

them by mistake is very high.

System 2: Advanced ACC. System 2 uses an LRR

sensor as well. Instead of the ESP sensors, a stereo

video sensor is used. As in System 1, the LRR pro-

vides information about speed and distance of objects

ahead. Yet, we do not need the lateral offset of de-

tected objects, because the video sensor identiﬁes the

lane of them precisely. In addition, the video sen-

sor recognizes object dimensions and is thus able to

differentiate between vehicles, people, beverage cans,

etc. Due to the precise information about the lane of a

detected object (at the roadside and on the road), the

ACC software is able to take stationary objects into

account in the constant-gap function. Due to the reli-

able information about stationary and moving objects

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

150

ACC

Software

Driver

ACC vehicle

System 1

Vehicles ahead

ACC

Software

Driver

ACC vehicle

System 2

Vehicles ahead

Pedestrians

D! {activate ACC,

deactivate ACC,

desired speed}

VA! {lane, speed, distance}

ACCV! {lane, speed}

ACC! {adapt speed}

D! {activate ACC,

deactivate ACC,

desired speed}

VA! {lane, speed, distance}

ACCV! {lane, speed}

ACC! {adapt speed}

P! {position, distance}

Figure 8: Essential context diagrams (Step 1).

that is now available, the ACC software in System 2

supports also emergency braking.

System 3: Sophisticated ACC. System 3 is similar

to System 2, except for the short range radar (SRR)

sensors that are used in addition. The SRR sensors

detect vehicles ahead that are close to the ACC vehi-

cle (e.g. vehicles cutting in sharply). Due to this in-

formation, the ACC software supports in addition (to

the capabilities that are also supported by System 2)

stop-and-go in urban trafﬁc.

We now describe how we applied our method to

identify variability and commonality and to deﬁne

core assets for our product line of ACC systems.

Step 1: Create essential context diagrams. We

have created an essential context diagram for Sys-

tems 1, 2, and 3 by abstracting from connection do-

mains and identifying the r

ess

and d

ess

variables, i.e.

the environmental quantities that are actually relevant

in the real world regardless of the sensors/actuators

that will be used to monitor/control them. The con-

text diagrams for System 1 and 2 are given in Fig. 8.

The diagram for System 3 is the same as for System 2.

This is possible because, as regards the essence, the

same problem domains in the environment are rele-

vant for System 3. For all three systems the driver, ve-

hicles ahead, and the ACC vehicle are relevant prob-

lem domains in the environment. For System 2 and 3,

in addition, pedestrians are relevant.

Step 2: Create essential problem diagrams. Based

on the essential context diagrams from Step 1, we cre-

ated essential problem diagrams. Note that to each

essential context diagram, several essential problem

diagrams were created because each machine was

decomposed into submachines and each submachine

was modelled in another problem diagram with the

corresponding essential requirement it has to satisfy.

Fig. 9 shows two of these essential problem diagrams

for System 1 and System 2. The essential problem di-

agram for System 3 is again the same as for System 2

due to the same reason as in Step 1. The essential re-

quirement to be satisﬁed is “adapt speed”. In case of

System 1, the ACC software needs to know the lane,

speed, and distance of vehicles ahead as well as the

lane and the speed of the ACC vehicle. These are the

ACC

Software

ACC

vehicle

System 1

Vehicles

ahead

System 2

Pedestrians

Adapt

speed

ACC

Software

ACC

vehicle

Vehicles

ahead

Adapt

speed

VA! {lane, speed,

distance}

ACCV! {speed

adapted}

VA! {lane, speed,

distance}

ACCV! {speed adapted}

P! {position,

distance}

VA! {lane, speed,

distance}

ACC! {adapt speed}

VA! {lane, speed,

distance}

ACC! {adapt speed}

P! {position,

distance}

ACC

vehicle

ACCV! {lane, speed}

ACC

vehicle

ACCV! {lane,

speed}

ACCV! {lane,

speed}

Figure 9: Essential problem diagrams (Step 2).

ACC

Software

ACC vehicle

System 1

Vehicles

ahead

Adapt

speed

Engine Mgmt.

System

ESP Sensors

Long Range

Radar

ESP

VA! {relative

position, speed,

distance}

VA! {lateral offset, speed, distance}

LRR! {measured lateral

offset, speed, distance}

ACC vehicle

ACCV! {yaw rate, lateral acceleration,

wheel speed, steering wheel angle }

ESPS! {measured yaw rate, lat. acc.,

wheel speed, steering wheel angle}

ACCV! {course,

current speed}

ACCV! {speed

adapted}

ESP! {decelerate}

EMS! {accelerate}

ACC! {engine-

torque-to-be}

ACC! {braking-torque-to-be}

System 2

Pedestrians

ACC

Software

ACC vehicle

Vehicles

ahead

Adapt

speed

ESP

Video sensor

Engine Mgmt.

System

Long Range

Radar

VS! {lane and distance

of VA, position and

distance of P}

VA! {lane, speed,

distance}

ACCV! {speed

adapted}

ESP! {decelerate}

EMS! {accelerate}

ACC! {engine-

torque-to-be}

ACC! {braking-torque-to-be}

VA! {lane, distance}

P! {position, distance}

VA! {speed, distance}

P! {position, distance}

LRR! {measured speed, distance}

Figure 10: Incarnation problem diagrams (Step 3).

phenomena referred to by the requirement. The phe-

nomenon constrained by the requirement is the speed

of the ACC vehicle indicated by “speed adapted”. In

case of System 2, the same requirement has to be sat-

isﬁed but there is one more problem domain involved:

pedestrians. The reason is that, in contrast to Sys-

tem 1, the ACC software in Systems 2 and 3 is able to

differentiate between pedestrians and vehicles ahead.

Step 3: Create incarnation problem diagrams. In-

dependent of the diagrams created in Steps 1 and 2,

we modelled the incarnation of the three existent ACC

systems. The incarnation problem diagrams for Sys-

tem 1 and 2 are given in Fig. 10. We omitted the di-

agram for System 3 due to space limitation. The di-

agram for System 3 resembles the one for System 2,

but contains additionally the SRR sensors and the cor-

responding shared phenomena. As Fig. 10 shows, the

diagrams contain now the sensors and actuators they

use for monitoring and controlling problem domains

in the environment. Furthermore, at the interfaces,

the six variables r

inc

are anno-

tated. For example, the incarnation problem diagram

for System 1 shows the LRR and the ESP sensors that

are used for monitoring. The LRR measures lateral

offset, speed, and distance of vehicles ahead. The

ESP sensors measure the yaw rate, lateral accelera-

tion, wheel speed, and steering wheel angle of the

Introducing Product Line Engineering in a Bottom-up Approach

151

Figure 11: Exemplary variants and variation points for ACC product line (Step 5).

ACC vehicle. All these input variables are needed by

the ACC software in order to know the relative po-

sition, speed, and distance of vehicles ahead (refer-

enced variables). This is different in System 2. As the

incarnation problem diagram in Fig. 10 shows, differ-

ent sensors and a different set of input variables are

used.

Step 4: Ensure that r

inc

variables map to

ess

variables. During this step, we contrast the

incarnation of each system with the essence of the

system, for example, the incarnation of System 1

shown on in Fig. 10 with its essence shown in Fig. 9.

As stated above, for each r

inc

variable, a reason-

ing must be documented. We illustrate that exemplar-

ily for one r

ess

variable, the lane of vehicles ahead:

Based on the yaw rate, lateral acceleration,

wheel speed, and steering wheel angle of the

ACC vehicle (m

inc

variables), the yaw rate

corrected for offset can be calculated. Based

on this value, the course of the ACC vehicle

inc

variable) can be determined. Based on

the course of the ACC vehicle (r

inc

variable)

as well as the lateral offset of vehicles ahead

inc

variable), the relative position of vehi-

cles ahead can be determined (r

inc

variable).

The relative position is an estimation of the

lane of vehicles ahead (r

ess

variable).

Step 5: Introduce variation points and variants.

During this step, we introduce variants (incarnation

diagram fragments) and variation points (essence di-

agram fragments) and create an OVM. The OVM in

Fig. 11 shows the variation point ‘Identifying vehicles

ahead’ with the three variants V1 to V3. At least one

and at most one of the variants must be selected. The

variation point is related by means of an artefact de-

pendency to the corresponding essence diagram frag-

ment. Each variant is also related by means of an arte-

fact dependency to the corresponding incarnation di-

agram fragment. For creating the diagrams shown in

Fig. 11 and the artefact dependencies between them,

we used our tool that is described in Sect. 3.2.

5 RELATED WORK

There are existing approaches that provide support

in introducing a product line based on existing sys-

tems or legacy systems. Li and Chang (Li and Chang,

2009) describe also a bottom-up approach for initi-

ating product line engineering but they mainly fo-

cus on process-related aspects regarding the com-

pany/organisation (e.g. building teams and insti-

tutionalizing new processes that replace traditional

ones). Kang et al. (Kang et al., 2005) present a

method for feature-oriented re-engineering of legacy

systems into product line assets. Yet, their focus is on

architectural design while we focus on requirements

engineering. Ferber et al. (Ferber et al., 2002) de-

scribe a re-engineering approach for an entire prod-

uct line. They deﬁne a method to investigate fea-

ICSOFT-PT 2016 - 11th International Conference on Software Paradigm Trends

152

ture dependencies and interactions, which restrict the

variants that can be derived from the legacy product

line assets. Their approach is interesting, although

they consider a different project situation than we do

(they assume there is legacy product line). Yet, their

approach for investigating feature dependencies and

interactions may probably complement our method

as regards the identiﬁcation of constraint dependen-

cies (Step 6). We will consider that in future work.

Beyond these approaches, there is one paper of our-

selves (Ulfat-Bunyadi et al., 2016) that has similar-

ities with the work presented in this paper. Never-

theless, the main difference is that we present in this

paper a bottom-up approach for introducing a product

line. The method presented in (Ulfat-Bunyadi et al.,

2016) describes a top-down approach. Furthermore,

the latter solves a different problem: which informa-

tion to document about a control software to enable

later systematic reuse of the software.

6 CONCLUSION

In this paper, we presented a bottom-up approach

for introducing product line engineering by re-

engineering existent systems. To this end, we mod-

elled the essence of each system independent of its

incarnation and confronted the two models. We be-

lieve that reﬂecting on the essence of similar exist-

ing systems will help developers in identifying com-

monalities and variability among the systems. Our

method provides support in creating the core assets of

the product line and the variability model. We val-

idated our method using real examples and provide

tool support. In future work, we plan to extend our

tool support. We presented here the OVM proﬁle

which enables orthogonal variability modelling. We

would like to add OCL (Object Constraint Language)

constraints to check validation conditions. Further-

more, we plan to analyse how difﬁcult it is to create

an essential model for an existing system. To this end,

we plan experiments in student groups.

REFERENCES

Alebrahim, A., Fassbender, S., Filipczyk, M., Goedicke,

M., Heisel, M., and Konersmann, M. (2014). To-

wards a computer-aided problem-oriented variability

requirements engineering method. In Proc. CAiSE

2014 Workshops, number 178 in LNBIP, pages 136–

147. Springer.

Clements, P. and Northrop, L. (2002). Software Product

Lines - Practices and Patterns. SEI Series in Software

Engineering. Addison-Wesley.

Ferber, S., Haag, J., and Savolainen, J. (2002). Feature

interaction and dependencies: Modeling features for

reengineering a legacy product line. In Proc. SPLC

2002, number 2379 in LNCS, pages 235–256.

Hatebur, D. and Heisel, M. (2010). A uml proﬁle for re-

quirements analysis of dependable software. In Proc.

SAFECOMP 2010, number 6351 in LNCS, pages

317–331. Springer.

Jackson, M. (2001). Problem Frames - Analysing and Struc-

turing Software Development Problems. Addison-

Wesley.

Kang, K., Kim, M., Lee, J., and Kim, B. (2005). Feature-

oriented re-engineering of legacy systems into product

line assets – a case study. In Proc. SPLC 2005, number

3714 in LNCS, pages 45–56.

Li, D. and Chang, C. K. (2009). Initiating and institutional-

izing software product line engineering: from bottom-

up approach to top-down practice. In Proc. Annual

IEEE Intl. Computer Software and Applications Con-

ference, pages 53–60. IEEE Computer Society.

McMenamin, S. M. and Palmer, J. (1984). Essential Sys-

tems Analysis. Prentice Hall, London.

Parnas, D. and Madey, J. (1995). Functional documents

for computer systems. Science of Computer Program-

ming, 25(1):41–61.

Pohl, K. (2010). Requirements Engineering- Fundamentals,

Principles, and Techniques. Springer.

Pohl, K., Böckle, G., and van der Linden, F. (2005). Soft-

ware Product Line Engineering: Foundations, Princi-

ples and Techniques. Springer, 1 edition.

Robert Bosch GmbH (2003). ACC Adaptive Cruise Control

- The Bosch Yellow Jackets. Edition 2003 edition.

Robert Bosch GmbH (2006). Safety, Comfort and Con-

venience Systems. Function, Regulation and Compo-

nents. John Wiley and Sons.

Schmid, K. and Verlage, M. (2002). The economic impact

of product line adoption and evolution. IEEE Soft-

ware, 19(4):50–57.

Ulfat-Bunyadi, N., Meis, R., and Heisel, M. (2016). The

six-variable model – context modelling enabling sys-

tematic reuse. In To be published in Proc. of ICSOFT-

PT 2016.

Introducing Product Line Engineering in a Bottom-up Approach

153