Applying Product Line Use Case Modeling ! in an Industrial Automotive Embedded System: Lessons Learned and a Refined Approach
•
3 gostaram•788 visualizações
ACM/IEEE MODELS 2015 presentation
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (6)
Semelhante a Applying Product Line Use Case Modeling ! in an Industrial Automotive Embedded System: Lessons Learned and a Refined Approach
Semelhante a Applying Product Line Use Case Modeling ! in an Industrial Automotive Embedded System: Lessons Learned and a Refined Approach (20)
Mais de Lionel Briand
Mais de Lionel Briand (20)
Último
Último (20)
Applying Product Line Use Case Modeling ! in an Industrial Automotive Embedded System: Lessons Learned and a Refined Approach
- 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
- 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
- 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 !