applying product line use case modeling ! in an industrial automotive embedded system: lessons...
TRANSCRIPT
.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
(Use Case Diagram and Specifications, and Domain Model)
Customer Bfor 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 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
• 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
• 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
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
<<Variant>>Clear Error
Status via IEE QC Mode
0..1
<<include>>
Method of Clearing
Error Status 1..1
<<require>>
STO Controller
<<include>>
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
<<Variant>>Clear Error
Status via IEE QC Mode
0..1
<<include>>
Method of Clearing
Error Status 1..1
<<require>>
STO Controller
<<include>>
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
<<Variant>>Clear Error
Status via IEE QC Mode
0..1
<<include>>
Method of Clearing
Error Status 1..1
<<require>>
STO Controller
<<include>>
19
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
<<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)
Product Line Use Case Diagram for STO (Partial)
20
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
<<Variant>>Clear Error
Status via IEE QC Mode
0..1
<<include>>
Method of Clearing
Error Status 1..1
<<require>>
STO Controller
<<include>>
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
<<Variant>>Clear Error
Status via IEE QC Mode
0..1
<<include>>
Method of Clearing
Error Status 1..1
<<require>>
STO Controller
<<include>>
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
<<Variant>>Clear Error
Status via IEE QC Mode
0..1
<<include>>
Method of Clearing
Error Status 1..1
<<require>>
STO Controller
<<include>>
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
<<Variant>>Clear Error
Status via IEE QC Mode
0..1
<<include>>
Method of Clearing
Error Status 1..1
<<require>>
STO Controller
<<include>>
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
Product Line Use Case Diagram for STO (Partial)
22
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
<<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
StatusClearing
Error Status
<<Variant>>Clear Error
Status
0..1
0..1
<<require>>
• 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.
!RUCM Extensions (2)
• Keyword: OPTIONAL for optional steps
31
!RUCM Extensions (3)
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
!RUCM Extensions (4)
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.
!RUCM Extensions (5)
Elicit Product Line Use Cases
1
Product LineUse Case Diagram
Product LineUse Case Specifications
Check Conformance for
Diagram and Specifications
List of Inconsistencies
•• •• •• •• •• •• •• ••
2
34
Overview of PUM
37
Use Case Diagram/Specifications Consistency
Use case diagram
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
<<require>>
STO Controller
<<include>>
Annotated use cases
Elicit Product Line Use Cases
1
Product LineUse Case Diagram
Product LineUse Case Specifications
Check Conformance for
Diagram and Specifications
List of Inconsistencies
•• •• •• •• •• •• •• ••
Update the Diagram and
Specifications
32
38
Overview of PUM
Elicit Product Line Use Cases
1
Product LineUse Case Diagram
Product LineUse Case Specifications
Check Conformance for
Diagram and Specifications
List of Inconsistencies
•• •• •• •• •• •• •• ••
Update the Diagram and
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
Elicit Product Line Use Cases
1
Product LineUse Case Diagram
Product LineUse Case Specifications
Check Conformance for
Diagram and Specifications
List of Inconsistencies
•• •• •• •• •• •• •• ••
Update the Diagram and
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
• 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