ACM/IEEE MODELS 2015 presentation

1. .lusoftware verification & validation
VVS
Applying 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. 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?

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

4. Context: ISO 26262
• Automotive domain: compliance with standard!
ISO 26262
4
TC4
TC3
TC2
Requirements!
!
Test cases
TC1

5. 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???

6. Context: Use Case Centric Development
6
STO Requirements
from Customer A
(Use Case Diagram
and Specifications,
and Domain Model)
Customer A
for STO
modify modify
modify modify
STO Test Cases for
Customer A
evolves to
(clone-and-own)
STO Requirements
from Customer B
(Use Case Diagram
and Specifications,
and Domain Model)
Customer B
for STO
evolves to
(clone-and-own)
STO Test Cases for
Customer B
evolves to
(clone-and-own)
STO Requirements
from Customer C
(Use Case Diagram
and Specifications,
and Domain Model)
Customer C
for STO
evolves to
(clone-and-own)
STO Test Cases for
Customer C

7. 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

8. 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

9. 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

10. 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

11. Product Line Use Case
Modeling Method: PUM

12. • 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

13. • 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

14. Overview of PUM
Elicit
Product Line
Use Cases
1
Product Line
Use Case Diagram
Product Line
Use Case Specifications
14

15. Use Case Diagram with
Product Line Extensions

16. • 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. 17
Product Line Use Case Diagram for
STO (Partial)

18. Product Line Use Case Diagram for
STO (Partial)
18
STO System
Sensors
Recognize
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
<<Variant>>
Clear Error
Status via IEE
QC Mode
0..1
<<include>>
Method of
Clearing
Error Status
1..1
<<require>>
STO Controller
<<include>>
STO System
Sensors
Recognize
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
<<Variant>>
Clear Error
Status via IEE
QC Mode
0..1
<<include>>
Method of
Clearing
Error Status
1..1
<<require>>
STO Controller
<<include>>
STO System
Sensors
Recognize
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
<<Variant>>
Clear Error
Status via IEE
QC Mode
0..1
<<include>>
Method of
Clearing
Error Status
1..1
<<require>>
STO Controller
<<include>>

19. 19
STO System
Sensors
Recognize
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
<<Variant>>
Clear Error
Status via IEE
QC Mode
0..1
<<include>>
Method of
Clearing
Error Status
1..1
<<require>>
STO Controller
<<include>>
Identify System
Operating Status
Storing
Error
Status
<<Variant>>
Store Error
Status
<<include>>
0..1
Product Line Use Case Diagram for
STO (Partial)

20. Product Line Use Case Diagram for
STO (Partial)
20
STO System
Sensors
Recognize
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
<<Variant>>
Clear Error
Status via IEE
QC Mode
0..1
<<include>>
Method of
Clearing
Error Status
1..1
<<require>>
STO Controller
<<include>>
STO System
Sensors
Recognize
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
<<Variant>>
Clear Error
Status via IEE
QC Mode
0..1
<<include>>
Method of
Clearing
Error Status
1..1
<<require>>
STO Controller
<<include>>
STO System
Sensors
Recognize
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
<<Variant>>
Clear Error
Status via IEE
QC Mode
0..1
<<include>>
Method of
Clearing
Error Status
1..1
<<require>>
STO Controller
<<include>>
STO System
Sensors
Recognize
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
<<Variant>>
Clear Error
Status via IEE
QC Mode
0..1
<<include>>
Method of
Clearing
Error Status
1..1
<<require>>
STO Controller
<<include>>

21. Product Line Use Case Diagram for
STO (Partial)
21
Tester
<<Variant>>
Clear Error
Status
0..1
Clearing
Error
Status
<<include>>
<<Variant>>
Clear Error Status
via Diagnostic
Mode
<<Variant>>
Clear Error
Status via IEE
QC Mode
0..1 1..1
Method of
Clearing
Error Status

22. Product Line Use Case Diagram for
STO (Partial)
22
STO System
Sensors
Recognize
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
<<Variant>>
Clear Error
Status via IEE
QC Mode
0..1
<<include>>
Method of
Clearing
Error Status
1..1
<<require>>
STO Controller
<<include>>
Storing
Error
Status
<<Variant>>
Store Error
Status
Clearing
Error
Status
<<Variant>>
Clear Error
Status
0..1
0..1
<<require>>

23. Restricted Use Case Modeling
(RUCM) and its Extensions

24. • 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. 25
RUCM Template (1)
Use Case: Recognize Gesture
Brief Description
The system is recognising a gesture
Precondition
Primary Actor
Device Sensors
Secondary Actors
STO Controller
Dependency
INCLUDE USE CASE Identify System Operating Status
Generalization

26. 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 has
been informed.

27. 27
RUCM Template (3)
Specific alternative flow
RFS 2
1. ABORT.
Post condition: The gesture has been recognised and the STO
Controller has been informed.
Specific alternative flow
RFS 5
1. The system VALIDATES THAT the overuse protection feature
is enabled.
2. The system VALIDATES THAT the Overuse protection status
is inactive.
3. The system increments the OveruseCounter by the overuse
increment step.
4. The system VALIDATES THAT the OveruseCounter is smaller
than the OveruseCounter limit.
5. ABORT.
Post condition: The OveruseCounter has been incremented by
the overuse increment step.

28. New keywords for modeling variability in use case
specifications
28
!
Product Line Extensions of RUCM

29. • Keyword: INCLUDE VARIATION POINT: ...
• Inclusion of variation points in basic or alternative flows of
use cases:
29
Use Case: Identify System Operating Status
Basic Flow
1. 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 Flow
RFS 4
1. INCLUDE VARIATION POINT: Storing Error Status.
2. ABORT.
!
RUCM Extensions (1)

30. • 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 clear
error status answer for successful clearing has been provided to the
Tester.
!
RUCM Extensions (2)

31. • Keyword: OPTIONAL for optional steps
31
!
RUCM Extensions (3)
Variant Use Case: Provide System User Data via Standard mode
Basic Flow
1.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.

32. • Keyword: OPTIONAL for optional alternative flows
32
!
RUCM Extensions (4)
Use Case: Recognize Gesture
1.1 Basic Flow
1. 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 Flow
RFS 1-4
1. IF voltage fluctuation is detected THEN
2. RESUME STEP 1.
3. ENDIF

33. • 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.
!
RUCM Extensions (5)

34. Elicit
Product Line
Use Cases
1
Product Line
Use Case Diagram
Product Line
Use Case Specifications
Check
Conformance for
Diagram and
Specifications
List of
Inconsistencies
•• •• •• •• •• •• •• ••
2
34
Overview of PUM

35. 35
RUCM/Specifications Consistency
Natural !
Language
Processing

36. 36
Use Case Diagram/Specifications Consistency

37. 37
Use Case Diagram/Specifications Consistency
Use case diagram
Sensors
Recognize
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
<<require>>
STO Controller
<<include>>
Annotated use cases

38. Elicit
Product Line
Use Cases
1
Product Line
Use Case Diagram
Product Line
Use Case Specifications
Check
Conformance for
Diagram and
Specifications
List of
Inconsistencies
•• •• •• •• •• •• •• ••
Update the
Diagram and
Specifications
3
2
38
Overview of PUM

39. Domain Model and OCL
Constraints

40. Elicit
Product Line
Use Cases
1
Product Line
Use Case Diagram
Product Line
Use Case Specifications
Check
Conformance for
Diagram and
Specifications
List of
Inconsistencies
•• •• •• •• •• •• •• ••
Update the
Diagram and
Specifications
3
2
Model the
Domain
4
Domain Model
40
Overview of PUM

41. 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. 42
Partial Domain Model for STO

43. Elicit
Product Line
Use Cases
1
Product Line
Use Case Diagram
Product Line
Use Case Specifications
Check
Conformance for
Diagram and
Specifications
List of
Inconsistencies
•• •• •• •• •• •• •• ••
Update the
Diagram and
Specifications
3
2
Model the
Domain
4
Domain Model
Identify
Constraints
5
List of
Constraints
•• •• •• •• •• •• •• ••
Specify
Constraints
6
OCL Constraints
43
Overview of PUM

44. 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. 45
OCL Constraints

46. Industrial Case Study and
Lessons Learned

47. • 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

48. • 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

49. • Modeling variability in non-functional requirements
• Training customers for PUM
• Evolution of variability information
49
Challenges for PUM Application

50. • Automatic configuration of product specific use case
models
• Integrating non-functional requirements with use
cases
50
Future Extensions for PUM

51. • 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

52. .lusoftware verification & validation
VVS
Applying 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 !