applying product line use case modeling ! in an industrial automotive embedded system: lessons...

.lusoftware verification & validationVVSApplying Product Line Use Case Modeling !

in an Industrial Automotive Embedded System: Lessons Learned and a Refined Approach

Ines Hajri Arda Goknil Lionel C. Briand

SnT Center, University of Luxembourg IEE, Luxembourg

Thierry Stephany !

2

Software Verification and Validation Laboratory (SVV)

International Electronics !& Engineering (IEE)

IEE develops real-time embedded systems: •  Automotive safety sensing systems, e.g., Body

Sense System •  Automotive comfort & convenience systems,

e.g., Smart Trunk Opener

How Did This Work Come About?

Smart Trunk Opener (STO)

3

STO Provides automatic and hands-free access to a vehicle’s trunk (based on a keyless entry system)

Context: ISO 26262 • Automotive domain: compliance with standard!

ISO 26262

4

TC4

TC3

TC2

Requirements!!

Test cases

TC1

Context: Change TC4

TC3

TC2

TC1

STO Requirements ! for Customer A STO Test Cases !

for Customer A

TC4

TC3

TC2

TC1

STO Requirements ! for Customer B STO Test Cases !

for Customer B

TC4

TC3

TC2

TC1

STO Requirements ! for Customer C STO Test Cases !

for Customer C

evolve to

evolve to

evolve to

evolve to

Which requirements are impacted???

Which requirements are impacted???

Which test cases are impacted???

Which test cases are impacted???

Traces (links) still valid???

Traces (links) still valid???

Context: Use Case Centric Development

6

STO Requirements from Customer A

(Use Case Diagram and Specifications, and Domain Model)

Customer Afor STO

modify modify

modify modify

STO Test Cases for Customer A

evolves to

(clone-and-own)

STO Requirements from Customer B


Customer Bfor STO

evolves to

(clone-and-own)

STO Test Cases for Customer B

evolves to

(clone-and-own)

STO Requirements from Customer C


Customer Cfor STO

evolves to

(clone-and-own)

STO Test Cases for Customer C

Problem

• Ad-hoc change management in the context of product line is ad-hoc

• Manual traceability between system test cases and requirements

•  Inefficient verification of compliance between the system and its requirements

7

Working Assumptions

• Requirements are captured through use cases

• Use case diagram, specifications and domain models are used to communicate with costumers

• Feature models traced to use case diagrams is not an option: additional modeling and traceability effort

• The above assumptions are common in many environments, including IEE

8

Objective • Support change management in the context of product lines,

based exclusively on commonly used modeling artifacts

• Future goals:

• Change impact analysis

• Regression test selection

• This paper: Practical variability modeling in Use Case Models

9

Overview of the Solution

10

2. Model variability in use

case specifications

Introduce new extensions for use case

specifications

1. Model variability in use

case diagram

3. Model variability in the domain model

Integrate and adapt existing work

Integrate and adapt existing work

Product Line Use Case Modeling Method: PUM

• Relating feature models and use cases![Griss et al., 1998; Eriksson et al., 2009; Buhne et al., 2006]

• Extending use case templates![Gallina and Guelfi, 2007; Nebut et al., 2006; Fantechi et al., 2004]

• Extending use case diagrams![Azevedo et al., 2012; John and Muthig, 2004; Halmans and Pohl, 2003]

• Capturing variability in domain models![Ziadi and Jezequel, 2006; Gomaa, 2000]

12

Related Work in Product Line Use Case Driven Development

• Modeling variability with constraints and dependencies

• Reflecting variability in use case specifications

• Capturing precise conditions in flows of events

• Limit the modeling and traceability overhead over what is current practice

13

Challenges in Product Line Use Case Modeling

Overview of PUM Elicit

Product Line Use Cases

1

Product LineUse Case Diagram

Product LineUse Case Specifications

14

Use Case Diagram with Product Line Extensions

• PUM uses the product line extensions of use case diagrams proposed by Halmans and Pohl

!G. Halmans and K. Pohl, “Communicating the variability of a software- product family

to customers,” Software and System Modeling, vol. 2, pp. 15–36, 2003

16

Use Case Diagram with Product Line Extensions

17

Product Line Use Case Diagram for STO (Partial)


18

STO System

SensorsRecognize

Gesture

Identify System Operating Status Storing

Error Status

Provide System Operating Status

Tester

<<include>>

<<Variant>>Store Error

Status

<<include>>

Clearing Error

Status

<<Variant>>Clear Error

Status

0..1

0..1

<<Variant>>Clear Error Status

via Diagnostic Mode


Status via IEE QC Mode

0..1

<<include>>

Method of Clearing

Error Status 1..1

<<require>>

STO Controller

<<include>>

STO System

SensorsRecognize

Gesture


Error Status


Tester

<<include>>


Status

<<include>>

Clearing Error

Status


Status

0..1

0..1


via Diagnostic Mode



0..1

<<include>>

Method of Clearing

Error Status 1..1

<<require>>

STO Controller

<<include>>

STO System

SensorsRecognize

Gesture


Error Status


Tester

<<include>>


Status

<<include>>

Clearing Error

Status


Status

0..1

0..1


via Diagnostic Mode



0..1

<<include>>

Method of Clearing

Error Status 1..1

<<require>>

STO Controller

<<include>>

19

STO System

SensorsRecognize

Gesture


Error Status


Tester

<<include>>


Status

<<include>>

Clearing Error

Status


Status

0..1

0..1


via Diagnostic Mode



0..1

<<include>>

Method of Clearing

Error Status 1..1

<<require>>

STO Controller

<<include>>Identify System Operating Status

Storing Error

Status


Status

<<include>>

0..1



20

STO System

SensorsRecognize

Gesture


Error Status


Tester

<<include>>


Status

<<include>>

Clearing Error

Status


Status

0..1

0..1


via Diagnostic Mode



0..1

<<include>>

Method of Clearing

Error Status 1..1

<<require>>

STO Controller

<<include>>

STO System

SensorsRecognize

Gesture


Error Status


Tester

<<include>>


Status

<<include>>

Clearing Error

Status


Status

0..1

0..1


via Diagnostic Mode



0..1

<<include>>

Method of Clearing

Error Status 1..1

<<require>>

STO Controller

<<include>>

STO System

SensorsRecognize

Gesture


Error Status


Tester

<<include>>


Status

<<include>>

Clearing Error

Status


Status

0..1

0..1


via Diagnostic Mode



0..1

<<include>>

Method of Clearing

Error Status 1..1

<<require>>

STO Controller

<<include>>

STO System

SensorsRecognize

Gesture


Error Status


Tester

<<include>>


Status

<<include>>

Clearing Error

Status


Status

0..1

0..1


via Diagnostic Mode



0..1

<<include>>

Method of Clearing

Error Status 1..1

<<require>>

STO Controller

<<include>>


21

Tester


Status

0..1

Clearing Error

Status <<include>>


via Diagnostic Mode



0..1 1..1

Method of Clearing

Error Status


22

STO System

SensorsRecognize

Gesture


Error Status


Tester

<<include>>


Status

<<include>>

Clearing Error

Status


Status

0..1

0..1


via Diagnostic Mode



0..1

<<include>>

Method of Clearing

Error Status 1..1

<<require>>

STO Controller

<<include>>

Storing Error

Status


StatusClearing

Error Status


Status

0..1

0..1

<<require>>

Restricted Use Case Modeling (RUCM) and its Extensions

• RUCM is based on: -  Template -  Restriction rules -  Specific keywords

• RUCM reduces ambiguities and facilitates automated analysis of use cases

24

Restricted Use Case Modeling: !RUCM

25

RUCM Template (1) Use Case: Recognize Gesture

Brief Description

The system is recognising a gesturePrecondition

Primary Actor

Device SensorsSecondary Actors

STO ControllerDependency

INCLUDE USE CASE Identify System Operating StatusGeneralization

26

RUCM Template (2) Basic Flow

1. INCLUDE USE CASE Identify System Operating Status.2. The system VALIDATES THAT the operating status is OK.3. The system REQUESTS the move capacitance FROM the UpperSensor.4. The system REQUESTS the move capacitance FROM the LowerSensor.5. The system VALIDATES THAT the movement is a valid kick.6. The system VALIDATES THAT the overuse protection feature is enabled.7. The system VALIDATES THAT the Overuse protection status is inactive.8. The system SENDS the valid kick status TO the STOController.Post condition: The gesture has been recognised and the STO Controller hasbeen informed.

27

RUCM Template (3) Specific alternative flow

RFS 21. ABORT.Post condition: The gesture has been recognised and the STOController has been informed.Specific alternative flow

RFS 51. The system VALIDATES THAT the overuse protection featureis enabled.2. The system VALIDATES THAT the Overuse protection statusis inactive.3. The system increments the OveruseCounter by the overuseincrement step.4. The system VALIDATES THAT the OveruseCounter is smallerthan the OveruseCounter limit.5. ABORT.Post condition: The OveruseCounter has been incremented bythe overuse increment step.

New keywords for modeling variability in use case specifications

28

!Product Line Extensions of RUCM

• Keyword: INCLUDE VARIATION POINT: ... • Inclusion of variation points in basic or alternative flows of

use cases:

29

Use Case: Identify System Operating StatusBasic Flow1. The system VALIDATES THAT the watchdog reset is valid.2. The system VALIDATES THAT the RAM is valid.3. The system VALIDATES THAT the sensors are valid.4. The system VALIDATES THAT there is no error detected.Specific Alternative FlowRFS 41. INCLUDE VARIATION POINT: Storing Error Status.2. ABORT.

!RUCM Extensions (1)

• Keyword: VARIANT for use cases

30

Variant Use Case: Clear error status

Basic Flow

1. The Tester SENDS the clear error status request TO the Sys-tem.2. INCLUDE Variation Point: Method of clearing errors status.Postcondition: The stored errors have been cleared and the clearerror status answer for successful clearing has been provided to theTester.


• Keyword: OPTIONAL for optional steps

31


Variant Use Case: Provide System User Data via Standard modeBasic Flow1.OPTIONAL STEP: The system SENDS calibration data TO the Tester.2.OPTIONAL STEP: The system SENDS trace data TO the tester.3.OPTIONAL STEP: The system SENDS error data TO the tester.4.OPTIONAL STEP: The system SENDS sensor data TO the tester.

• Keyword: OPTIONAL for optional alternative flows

32


Use Case: Recognize Gesture1.1 Basic Flow1. INCLUDE USE CASE Identify System Operating Status.2. The system VALIDATES THAT the operating status is valid.3. The system REQUESTS the move capacitance FROM the sensors.4. The system VALIDATES THAT the movement is a valid kick.5. The system SENDS the valid kick status TO the STO Controller.1.2 OPTIONAL Bounded Alternative FlowRFS 1-41. IF voltage fluctuation is detected THEN2. RESUME STEP 1.3. ENDIF

• Keyword: V before the step number

33

Variant Use Case: Provide System User Data via Standard mode

Basic Flow

V1. OPTIONAL STEP: The system SENDS calibration data TO the Tester.V2. OPTIONAL STEP: The system SENDS trace data TO the tester.V3. OPTIONAL STEP: The system SENDS error data TO the tester.V4. OPTIONAL STEP: The system SENDS sensor data TO the tester.


Elicit Product Line Use Cases

1



Check Conformance for

Diagram and Specifications

List of Inconsistencies

•• •• •• •• •• •• •• ••

2

34

Overview of PUM

35

RUCM/Specifications Consistency

Natural !Language Processing

36

Use Case Diagram/Specifications Consistency

37

Use Case Diagram/Specifications Consistency

Use case diagram

SensorsRecognize

Gesture


Error Status


Tester

<<include>>


Status

<<include>>

Clearing Error

Status


Status

0..1

0..1

<<require>>

STO Controller

<<include>>

Annotated use cases


1






•• •• •• •• •• •• •• ••

Update the Diagram and

Specifications

32

38

Overview of PUM

Domain Model and OCL Constraints


1






•• •• •• •• •• •• •• ••


Specifications

32

Model the Domain

4

Domain Model

40

Overview of PUM

41

• PUM uses the stereotypes variation, variant and optional provided by Ziadi and Jezequel.

!T. Ziadi and J.-M. Jezequel, “Product line engineering with the uml : Deriving products,” Software

Product Lines. Springer, 2006.

!Domain Model with Product Line !

Extensions

42

Partial Domain Model for STO


1






•• •• •• •• •• •• •• ••


Specifications

32

Model the Domain

4

Domain Model

IdentifyConstraints

5

List of Constraints

•• •• •• •• •• •• •• ••

Specify Constraints

6

OCL Constraints43

Overview of PUM

44

Formalization of use case conditions as OCL constraints

è Correct execution of the product in terms of flows of events

!OCL Constraints for STO

45

OCL Constraints

Industrial Case Study and Lessons Learned

• Applying PUM to the functional requirements for STO

• Semi-structured interview and a questionnaire

• Interviewees had substantial experience and five important roles were covered

• Assessing PUM in terms of adoption effort, expressiveness, comparison with current practice, and tool support

47

Case Study

• The extensions are simple enough to enable communication between analysts and customers

• The extensions provide enough expressiveness to conveniently capture variability

• PUM provides better assistance for capturing and analyzing variability information compared to the current practice

• The tool provide useful assistance for minimizing inconsistencies in artifacts

48

Positive Aspects of PUM

• Modeling variability in non-functional requirements

• Training customers for PUM

• Evolution of variability information

49

Challenges for PUM Application

• Automatic configuration of product specific use case models

• Integrating non-functional requirements with use cases

50

Future Extensions for PUM

• Context strongly determines how variability should be captured and in which modeling artifacts

• PUM helps document variability in use case diagram, specifications and domain model, without feature models

• PUM integrates existing work and is supported by a tool employing NLP for checking artifact consistency

• Initial results from structured interviews suggest that PUM is accurate and practical to capture variability in industrial settings

51

Conclusion

.lusoftware verification & validationVVSApplying Product Line Use Case Modeling !

in an Industrial Automotive Embedded System: Lessons Learned and a Refined Approach

Ines Hajri Arda Goknil Lionel C. Briand

SnT Center, University of Luxembourg IEE, Luxembourg

Thierry Stephany !