an architectural approach to support
play

An Architectural Approach to Support Online Updates of SPL - PowerPoint PPT Presentation

An Architectural Approach to Support Online Updates of SPL Products Danny Weyns, Linnaeus University Vxj Campus, Sweden 23rd CREST Open Workshop


  1. An ¡Architectural ¡Approach ¡to ¡Support ¡ Online ¡Updates ¡of ¡SPL ¡Products ¡ Danny ¡Weyns, ¡Linnaeus ¡University ¡Växjö ¡Campus, ¡Sweden ¡ ¡ ¡ 23rd ¡CREST ¡Open ¡Workshop ¡ ¡ Change ¡Impact ¡Analysis ¡and ¡TesCng ¡of ¡SoDware ¡Product ¡Lines ¡ ¡ November ¡19-­‑20, ¡2012 ¡UCL ¡London ¡

  2. 2 ¡ Problem ¡context: ¡Egemin ¡integrated ¡ logisJc ¡systems ¡ E’car ¡ E’con ¡ E’gv ¡ E’wms ¡

  3. 3 ¡ Egemin ¡SPL ¡architecture ¡

  4. 4 ¡ Typical ¡configuraJon ¡of ¡a ¡product ¡ ¡

  5. 5 ¡ Simple ¡update ¡scenario ¡ Update ¡E’tricc ¡to ¡new ¡version ¡ v14 ¡ v14 ¡

  6. 6 ¡ Problem ¡ NV Logistics Updated ¡ product ¡ SPL ¡development ¡ Integrator ¡ organizaJon ¡ System ¡admin ¡

  7. 7 ¡ Problem ¡ ¡ • Coarse ¡grained ¡updates ¡of ¡deployed ¡SPL ¡products ¡ ▫ Product ¡= ¡set ¡of ¡assets ¡each ¡consisJng ¡of ¡set ¡of ¡resources ¡ ¡ ▫ SupporJng ¡infrastructure ¡for ¡dynamic ¡updates ¡of ¡components ¡is ¡ available ¡ ▫ 200 ¡products ¡deployed; ¡aWer ¡iniJal ¡phase ¡+-­‑ ¡1 ¡update/year ¡ • Egemin’s ¡current ¡pracJce: ¡updates ¡oWen ¡contain ¡errors ¡ and/or ¡are ¡not ¡performed ¡efficiently ¡ ¡ • Problem: ¡how ¡to ¡support ¡integrators ¡to ¡ ▫ Perform ¡correct ¡updates ¡with ¡minimal ¡interrupJon ¡of ¡service ¡ ▫ Given ¡a ¡lack ¡of ¡precise ¡architectural ¡informaJon ¡ ¡

  8. 8 ¡ Overview ¡ • Architectural ¡approach ¡ • Update ¡viewpoint ¡ • Framework ¡ • EvaluaJon ¡ • Conclusions ¡and ¡future ¡work ¡ ¡

  9. 9 ¡ Architectural ¡approach ¡ Create ¡ ¡ Define ¡ Usage ¡ SPL-­‑Specific ¡ ¡ Reusable ¡ArJfacts ¡ ¡ ArJfact ¡Instances ¡ ¡ Update ¡ Update ¡view ¡ viewpoint ¡ InstanJated ¡ Framework ¡ Update ¡Products ¡ ¡ Framework ¡

  10. 10 ¡ Overview ¡ • Architectural ¡approach ¡ • Update ¡viewpoint ¡ • Framework ¡ • EvaluaJon ¡ • Conclusions ¡& ¡future ¡work ¡ ¡

  11. 11 ¡ Update ¡viewpoint: ¡overview ¡ • Update ¡concerns ¡ • Model ¡kinds ¡ • Meta-­‑models ¡ • Analysis ¡ ¡ D. ¡Weyns, ¡B. ¡Michalik, ¡A. ¡Helleboogh, ¡N. ¡Bouke, ¡An ¡Architectural ¡Approach ¡to ¡Support ¡Online ¡ Updates ¡of ¡SoWware ¡Product ¡Lines, ¡IEEE/IFIP ¡Conference ¡on ¡SoWware ¡Architecture, ¡WICSA ¡2011 ¡

  12. 12 ¡ Update ¡concerns ¡ • Understandability ¡ • Availability ¡ • Correctness ¡

  13. 13 ¡ Update ¡concerns ¡ • Understandability ¡ ▫ What ¡are ¡assets ¡and ¡resources ¡for ¡the ¡SPL ¡ ▫ What ¡are ¡the ¡dependencies ¡between ¡assets/resources? ¡ ¡ ▫ Which ¡assets ¡are ¡currently/should ¡be ¡installed? ¡ ▫ Where ¡are ¡resources ¡deployed? ¡ ▫ Where ¡should ¡resources ¡be ¡deployed ¡aWer ¡update? ¡ ¡ • Availability ¡ • Correctness ¡ ¡

  14. 14 ¡ Update ¡concerns ¡ • Understandability ¡ • Availability ¡ ▫ How ¡to ¡perform ¡the ¡update ¡with ¡minimal ¡interrupJon ¡ of ¡service? ¡ ▫ Which ¡resources ¡have ¡to ¡be ¡replaced? ¡ ▫ Which ¡processes ¡have ¡to ¡be ¡stopped ¡and ¡(re-­‑)started ¡ and ¡when? ¡ ¡ • Correctness ¡

  15. 15 ¡ Update ¡concerns ¡ • Understandability ¡ • Availability ¡ • Correctness ¡ ▫ What ¡is ¡the ¡procedure ¡to ¡perform ¡a ¡correct ¡update? ¡ ¡ ▫ What ¡kind ¡of ¡inconsistencies ¡exist? ¡ ¡ ▫ When ¡is ¡the ¡update ¡performed ¡correctly? ¡ ¡

  16. 16 ¡ Update ¡viewpoint: ¡overview ¡ • Update ¡concerns ¡ • Model ¡kinds ¡ • Meta-­‑models ¡ • Analysis ¡

  17. 17 ¡ Update ¡viewpoint ¡model ¡kinds ¡ • M1 ¡-­‑ ¡As-­‑is ¡product ¡deployment ¡ ▫ Browse-­‑able ¡model ¡of ¡the ¡current ¡product ¡ ¡ • M2 ¡-­‑ ¡To-­‑be ¡product ¡deployment ¡ ¡ ▫ Browse-­‑able ¡ ¡model ¡of ¡the ¡ future ¡version ¡of ¡the ¡ product ¡ ¡ • M3 ¡-­‑ ¡Update ¡procedure ¡(update ¡script) ¡ ▫ Model ¡showing ¡the ¡steps ¡to ¡perform ¡the ¡update ¡ • M4 ¡-­‑ ¡Inconsistencies ¡ ¡ ▫ Model ¡showing ¡the ¡inconsistencies ¡ in ¡updated ¡product. ¡

  18. 18 ¡ Update ¡viewpoint ¡model ¡kinds ¡ M1: ¡As-­‑Is ¡ M2: ¡To-­‑Be ¡ M3: ¡Update ¡ M4: ¡ Product ¡ Product ¡ Procedure ¡ Inconsistencies ¡ Understandability ¡ X ¡ X ¡ Availability ¡ X ¡ Correctness ¡ X ¡ X ¡

  19. 19 ¡ Update ¡viewpoint ¡model ¡kinds ¡ Models ¡harvested ¡from ¡system ¡sources ¡ M1: ¡As-­‑Is ¡ M2: ¡To-­‑Be ¡ M3: ¡Update ¡ M4: ¡ Product ¡ Product ¡ Procedure ¡ Inconsistencies ¡ Understandability ¡ X ¡ X ¡ Availability ¡ X ¡ Correctness ¡ X ¡ X ¡ Models ¡derived ¡from ¡analysis ¡of ¡M1 ¡and ¡M2 ¡

  20. 20 ¡ Update ¡viewpoint: ¡overview ¡ • Update ¡concerns ¡ • Model ¡kinds ¡ • Meta-­‑model ¡(M1, ¡M2) ¡ ¡ ▫ Integrated ¡meta-­‑model ¡ ▫ Mapping ¡to ¡Egemin’s ¡context ¡ • Analysis ¡(M3, ¡M4) ¡

  21. 21 ¡ Integrated ¡meta-­‑model ¡

  22. 22 ¡ Egemin’s ¡Integrated ¡Meta-­‑Model ¡

  23. 23 ¡ Update ¡viewpoint: ¡overview ¡ • Update ¡concerns ¡ • Model ¡kinds ¡ • Meta-­‑model ¡(M1, ¡M2) ¡ • Analysis ¡(M3, ¡M4) ¡ ¡ ▫ A1: ¡Update ¡procedure ¡ ▫ A2: ¡Product ¡inconsistencies ¡ D. ¡Weyns ¡and ¡B. ¡Michalik, ¡Codifying ¡Architecture ¡Knowledge ¡to ¡Support ¡Online ¡EvoluJon ¡of ¡ SoWware ¡Product ¡Lines, ¡SHAring ¡and ¡Reusing ¡architectural ¡Knowledge, ¡SHARK ¡2011 ¡

  24. 24 ¡ A1: ¡Update ¡procedure ¡ • Analysis ¡of ¡delta ¡between ¡as-­‑is ¡and ¡to-­‑be ¡ ¡ ▫ Resources ¡to ¡be ¡added ¡(in ¡to-­‑be, ¡not ¡in ¡as-­‑is) ¡ ▫ Resources ¡to ¡be ¡removed ¡(in ¡as-­‑is, ¡not ¡in ¡to-­‑be) ¡ ▫ Resources ¡to ¡be ¡replaced ¡(versions) ¡ ¡ ▫ Affected ¡processes ¡(to ¡stop ¡and ¡start) ¡ ▫ Domain-­‑specific ¡rules ¡about ¡order ¡of ¡process ¡ manipulaJons ¡ • Result ¡is ¡an ¡update ¡script ¡

  25. 25 ¡ A2: ¡Product ¡inconsistencies ¡ • Check ¡inconsistencies ¡of ¡product ¡under ¡update ¡ ▫ ViolaJons ¡of ¡asset ¡constraints ¡ ▫ Incomplete/inconsistent ¡set ¡of ¡resources ¡for ¡a ¡ parJcular ¡asset ¡ ▫ Resource ¡dependencies ¡that ¡cannot ¡be ¡resolved ¡ ▫ ViolaJons ¡of ¡versions ¡of ¡assets/resources ¡ ¡ • Result ¡is ¡an ¡inconsistency ¡model ¡

  26. 26 ¡ Overview ¡ • Architectural ¡approach ¡ • Update ¡viewpoint ¡ • Framework ¡ • EvaluaJon ¡ • Conclusions ¡and ¡future ¡work ¡ ¡

  27. 27 ¡ Framework ¡ • Reusable ¡and ¡extensible ¡infrastructure ¡for ¡ updaJng ¡deployed ¡SPL ¡products ¡ • Key ¡funcJons ¡ ▫ HarvesJng ¡architectural ¡relevant ¡informaJon ¡ ▫ Analyzing ¡architectural ¡informaJon ¡ ¡ ▫ Visualizing ¡architectural ¡models ¡for ¡the ¡stakeholders ¡ • Built ¡in ¡Java ¡reusing ¡several ¡of ¡the ¡Eclipse ¡projects ¡ ¡

  28. 28 ¡ Framework ¡ Stakeholders ¡

  29. As-­‑Is ¡tab ¡ Assets ¡on ¡selected ¡ locaJon ¡ Available ¡locaJons ¡ Deployed ¡assemblies ¡of ¡ selected ¡locaJon/asset ¡ Dependencies ¡of ¡selected ¡ Assemblies ¡that ¡use ¡selected ¡ assembly ¡ assembly ¡

  30. Consistency ¡of ¡as-­‑is ¡ product ¡ ¡ System ¡assemblies ¡that ¡can ¡be ¡ignored ¡ Lacking ¡assemblies ¡for ¡ ¡ selected ¡locaJon ¡ Required ¡assemblies ¡for ¡ selected ¡assembly ¡

  31. Concrete ¡tasks ¡to ¡be ¡performed ¡ Update ¡script ¡ on ¡the ¡selected ¡locaJon ¡

  32. 32 ¡ Overview ¡ • Architectural ¡approach ¡ • Update ¡viewpoint ¡ • Framework ¡ • EvaluaJon ¡ • Conclusions ¡& ¡future ¡work ¡ ¡

Recommend


More recommend