Incremental Reconfiguration of Product Specific Use Case Models for Evolving Configuration Decisions
0 likes252 views
1. The document discusses an approach for incrementally reconfiguring product-specific use case models when configuration decisions evolve over time. 2. Product-specific models are regenerated by focusing only on the changed decisions and their side effects, preserving unaffected parts and existing trace links. 3. The approach involves matching decision model elements before and after changes, calculating differences, and using these to reconfigure use case diagrams and specifications while generating an impact report.
![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](https://image.slidesharecdn.com/ines-refsq17-170228133432/85/Incremental-Reconfiguration-of-Product-Specific-Use-Case-Models-for-Evolving-Configuration-Decisions-7-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (11)
Ad
Similar to Incremental Reconfiguration of Product Specific Use Case Models for Evolving Configuration Decisions (20)
Ad
More from Lionel Briand (20)
Recently uploaded (20)
Incremental Reconfiguration of Product Specific Use Case Models for Evolving Configuration Decisions
- 1. .lusoftware veriïŹcation & 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 SpeciïŹcations) Customer A for STO STO Test Cases for Customer A Derived from STO Requirements from Customer B (Use Case Diagram and SpeciïŹcations) 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 SpeciïŹcations) 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
- 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 ReconïŹguration of PS Models 3 Decision-level Changes PS Use Case Diagram and SpeciïŹcations ReconïŹgured PS Use Case Diagram and SpeciïŹcations 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 ReconïŹguration of PS Models 3 Decision-level Changes PS Use Case Diagram and SpeciïŹcations ReconïŹgured PS Use Case Diagram and SpeciïŹcations 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
- 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 veriïŹcation & 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