REFSQ 2017 conference presentation

1. .lusoftware verification & validation
VVS
Incremental Reconfiguration of
Product Specific Use Case Models for
Evolving Configuration Decisions
Ines Hajri, Arda Goknil, Lionel Briand, and Thierry Stephany
SnT Center, University of Luxembourg
IEE, Luxembourg

2. Context: Automotive Domain
2
International Electronics & Engineering

3. Smart Trunk Opener (STO)
STO provides automatic and hands-free access to vehicle
trunks (based on a keyless entry system)
3

4. Context: Use Case Driven
Development in Product Lines
4
Use case
Diagram
Use Case
SpecificationsActor
Request
Order
Show
catalog
Pay For
Products are developed for multiple customers with varying
needs in a product line

5. Context: Evolution of
Requirements
5
STO Requirements
from Customer A
(Use Case Diagram
and Specifications)
Customer A
for STO
STO Test Cases for
Customer A
Derived
from
STO Requirements
from Customer B
(Use Case Diagram
and Specifications)
Customer B
for STO
STO Test Cases for
Customer B
Derived
from
evolves to
(clone-and-own)
modify modify
evolves to
(clone-and-own)
STO Requirements
from Customer C
(Use Case Diagram
and Specifications)
modify
Customer C
for STO
STO Test Cases
for Customer C
Derived
from

6. Long Term Objective
Support:
• automated and effective change management,
• and regression test selection
in the context of:
• product lines,
• and use case-driven development and testing
6

7. Research Steps
• Step1: Product line Use case modeling Method (PUM)
[MODELS’15]
• Step2: Product line Use case Model Configurator (PUMConf)
[SoSyM’16]
• Step3: Supporting incremental reconfiguration
of use case models for evolving configuration decisions
[This paper]
7

8. Incremental Reconfiguration
• Main goal: reduce manual effort during reconfiguration
- In particular, reducing the effort of manually assigning
traceability links between product specific use case
models and external documents
• Approach: product specific use case models can be
incrementally regenerated by exclusively focusing on the
changed decisions and their side effects
8

9. Background

10. Product Line Use Case Modeling
Method: PUM
10

11. Overview of PUM
11
2. Model
variability in
use case
specifications
1. Model
variability in
use case
diagram Introduce new
extensions for use
case specifications
Integrate and adapt
existing work
G. Halmans and K. Pohl, “Communicating the var
iability
of a software-product family to customers”, SoSy
M, 2003
I. Hajri, A. Goknil, L. C. Briand, and T. Steph
any
“Configuring use case models in product fa
milies”, SoSyM, 2016

12. Product Line Use Case Diagram
12

13. Product Line Use Case Diagram
13
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>>
G. Halmans and K. Pohl, “Communicating the variability of a software-product family to
customers”,
SoSyM, 2003

14. Product Line Use Case
Specifications
14

15. Restricted Use Case Modeling:
RUCM
15
• RUCM is based on:
- Predefined template
- Restriction rules
- Specific keywords
• RUCM reduces ambiguities and facilitates automated analysis
of use cases
T. Yue, L. C. Briand, and Y. Labiche, “Facilitating the transition from use
case models to analysis models: Approach and experiments”, TOSEM,
2013.

16. RUCM Extensions
New keywords for modeling variability in use case specifications:
• INCLUDE VARIATION POINT: for including variation points
• VARIANT: for variability in use cases
• OPTIONAL: for variability in steps and alternative flows
• V: for variability in steps order
16

17. Example Product Line Use Case
Specifications
17

18. Configuration Approach for Use
Case-Driven Development
18

19. Configuration Approach
• Guides analysts and customers in making configuration
decisions in product line use case
• Checks the consistency of configuration decisions
• Generates product specific use case models from the product
line models
19

20. Product specific
use case models
Customer A
for Product X
Product line
use case models
Customer B
for Product X
Product specific
use case models
ConfigureConfigure
Defines all
variabilities and
commonalities
Reuses commonalities
and exploits
variabilities to build a
product
20
Configurator

21. Incremental Reconfiguration of PS
Models for Evolving Configuration
Decisions

22. Product specific
use case models
Customer A
for Product X
Product line
use case models
Customer B
for Product X
Product specific
use case models
ConfigureConfigure
Defines all
variabilities and
commonalities
Reuses commonalities
and exploits
variabilities to build a
product Configurator
22

23. Product specific
use case models
Customer A
for Product X
Product line
use case models
Customer B
for Product X
Product specific
use case models
ConfigureConfigure
Configurator
Requirements
Analyst
Trace
Links
23
External
Documents

24. Trace Link Example
24

25. Product specific
use case models
Customer A
for Product X
Product line
use case models
Customer B
for Product X
Product specific
use case models
ConfigureConfigure
Configurator
Requirements
Analyst
Trace
Links
25
External
Documents
evolves
evolves

26. Product specific
use case models
Customer A
for Product X
Product line
use case models
Customer B
for Product X
Product specific
use case models
ConfigureConfigure
Configurator
Requirements
Analyst
Trace
Links
26
External
Documents
evolves
evolves
Reconfigure Reconfigure

27. Problem
• Loosing manually assigned traces when reconfiguring all
decisions
- Manually reassigning all the traces after each
reconfiguration is error-prone and time consuming
27

28. Goal
• Avoid manual effort during reconfiguration by incrementally
reconfiguring the generated product specific models
exclusively for the changed decisions
- Preserve non-impacted parts of product specific use case
models and their a-priori assigned traces
- Inform analysts about the impact of changes on
configuration decisions for product line models
28

29. Model Differencing and
Regeneration Pipeline
29
Decision Model
before Changes
(M1)
Decision Model
after Changes
(M2)
Matching Decision
Model Elements
1
Correspondences
•• •• •• •• •• •• •• ••
2 Change
Calculation
Reconfiguration
of PS Models
3
Decision-level
Changes
PS Use Case
Diagram and
Specifications
Reconfigured
PS Use Case
Diagram and
Specifications
Impact
Report

30. Matching Decision Model
Elements
30
Decision Model
before Changes
(M1)
Decision Model
after Changes
(M2)
Matching Decision
Model Elements
1
Correspondences
•• •• •• •• •• •• •• ••

31. Decision Model Example
31
:DecisionModel
- name = “Provide System User Data”
:EssentialUseCase
- name = “Method of Providing Data”
:MandatoryVariationPoint
- name = “Provide System User
Data via Standard Mode”
- isSelected = True
:VariantUseCase
- name = “Provide System User Data
via Diagnostic Mode”
- isSelected = True
:VariantUseCase
- name = “Provide System User
Data via IEE QC Mode”
- isSelected = True
:VariantUseCase
variants
- number = 1
:BasicFlow
- name = “V”
:VariantOrder
- orderNumber = 4
- variantOrderNumber = 1
- isSelected = True
:OptionalStep
- orderNumber = 1
- variantOrderNumber = 2
- isSelected = True
:OptionalStep
- orderNumber = 0
- variantOrderNumber = 3
- isSelected = False
:OptionalStep
usecases
variationpoint

32. Matching Decision Model
Elements
• The structural differencing of M1 and M2 is done by searching
for the correspondences in M1 and M2
• A correspondence between elements E1 and E2 denotes that
E1 and E2 represent decisions for the same variation in M1
and M2
32

33. Matching Decision Model
Elements Example
33
Excerptof Decision Model M1
(before the change)
Excerptof Decision Model M2
(after the change)
- name = “Provide System
User Data via Standard Mode”
- isSelected = True
B11:VariantUseCase
- number = 1
B12:BasicFlow
- orderNumber = 0
- variantOrderNumber = 2
- isSelected = False
B14:OptionalStep
Triplet
(use case,
flow, step )
- name = “Provide System User
Data via Standard Mode”
- isSelected = True
C11:VariantUseCase
- number = 1
C12:BasicFlow
- orderNumber = 1
- variantOrderNumber = 2
- isSelected = True
C14:OptionalStep
- name =
“Provide
System User
Data via
Diagnostic
Mode”
- isSelected =
True
C9:VariantUse
Case

34. Matching Decision Model
Elements Example
34
Excerptof Decision Model M1
(before the change)
Excerptof Decision Model M2
(after the change)
- name = “Provide System
User Data via Standard Mode”
- isSelected = True
B11:VariantUseCase
- number = 1
B12:BasicFlow
- orderNumber = 0
- variantOrderNumber = 2
- isSelected = False
B14:OptionalStep
- name =
“Provide
System User
Data via
Diagnostic
Mode”
- isSelected =
True
C9:VariantUse
Case
- name = “Provide System User
Data via Standard Mode”
- isSelected = True
C11:VariantUseCase
- number = 1
C12:BasicFlow
- orderNumber = 1
- variantOrderNumber = 2
- isSelected = True
C14:OptionalStep

35. Change Calculation
35
Decision Model
before Changes
(M1)
Decision Model
after Changes
(M2)
Matching Decision
Model Elements
1
Correspondences
•• •• •• •• •• •• •• ••
2 Change
Calculation Decision-level
Changes

36. Change Calculation
• Identifies decision-level changes from the corresponding
model elements
• Identifies deleted, added, and updated decisions for use case
diagram and specification
36

37. Change Calculation Example
37
Excerptof Decision Model M1
(before the change)
Excerptof Decision Model M2
(after the change)
- name = “Provide System
User Data via Standard Mode”
- isSelected = True
B11:VariantUseCase
- number = 1
B12:BasicFlow
- orderNumber = 0
- variantOrderNumber = 2
- isSelected = False
B14:OptionalStep
- name = “Provide System User
Data via Standard Mode”
- isSelected = True
C11:VariantUseCase
- number = 1
C12:BasicFlow
- orderNumber = 1
- variantOrderNumber = 2
- isSelected = True
C14:OptionalStep
- name =
“Provide
System User
Data via
Diagnostic
Mode”
- isSelected =
True
C9:VariantUse
Case

38. Reconfiguration of Product
Specific Models
38
Decision Model
before Changes
(M1)
Decision Model
after Changes
(M2)
Matching Decision
Model Elements
1
Correspondences
•• •• •• •• •• •• •• ••
2 Change
Calculation
Reconfiguration
of PS Models
3
Decision-level
Changes
PS Use Case
Diagram and
Specifications
Reconfigured
PS Use Case
Diagram and
Specifications
Impact
Report

39. Reconfiguration of Product
Specific Models
• Regenerates the product specific use case diagram and
specifications only for the added, deleted, and updated
decisions
• Generates a report for the impacted and regenerated parts of
the product specific models
39

40. Reconfiguration of PS Models
Example
40

41. Impact Report Example
41

42. Evaluation
42

43. Evaluation Goal
• Assess, in an industrial context, the feasibility of using our
approach
- We check whether the proposed approach improves reuse
and reduces manual effort after reconfiguration of product
specific models
43

44. Case Study (1)
44
# of use
cases
# of variation
Points
# of basic
flows
# of alternative
flows
# of
steps
# of
condition
steps
Essential Use
Cases
11 6 11 57 192 57
Variant Use
Cases
13 1 13 131 417 130
Total 24 7 24 188 609 187
• Case Study: Smart Trunk Opener (STO)
• Artifacts: product line use case diagram & product line
use case specifications

45. Case Study (2)
• We configured product specific models for 4 products
• We chose 1 product to be used for reconfiguration
• The selected product includes:
- 36 traces from product specific use case diagram
- 278 traces from product specific use case specifications to
other requirements documents
• We considered 8 change scenarios
45

46. Example Change Scenarios
46
ID Change Scenario Explanation
S1 Update a diagram decision Unselecting selected use cases
S2 Update and delete diagram
decisions
Unselecting selected use cases,
removing other decisions
S3 Update and add diagram decisions Selecting unselected use cases,
implying other decisions
…

47. Results and Analysis: Improving
Trace Reuse
47
0
20
40
60
80
100
120
S1 S2 S3 S4 S5 S6 S7 S8
Decision Change Scenarios
% of preserved traces for
PS use case diagram
% of preserved traces for
PS use case specification
In average, 96% of the use case diagram and specification traces
were preserved

48. Results and Analysis: Reducing
Manual Effort
48
In average, 4% of the use case specification traces need to be
manually assigned (when using our approach)
0
50
100
150
200
250
300
350
S1 S2 S3 S4 S5 S6 S7 S8
Decision Change Scenarios
# of manually assigned
traces in use case
specifications without
using our approach
# of manually added
traces in use case
specifications using our
approach

49. Evaluation Summary
• Our approach preserved all the traces for the unchanged parts
of PS models
• Only the traces for the deleted parts of the PS models were
removed
• Our automated approach for incremental reconfiguration
leads to significant reuse and savings when updating traces
49

50. Future Work
• Change impact analysis in the context of product lines
• Regression test selection in the context of product lines
50

51. Summing up

52. 52

53. .lusoftware verification & validation
VVS
Incremental Reconfiguration of
Product Specific Use Case Models for
Evolving Configuration Decisions
Ines Hajri, Arda Goknil, Lionel Briand, and Thierry Stephany
SnT Center, University of Luxembourg
IEE, Luxembourg