Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Towards Modularity in Live Visual Modeling: A case-study with OpenPonk and Kendrick

282 views

Published on

ESUG 2017 - IWST 2017

Published in: Software
  • Be the first to comment

  • Be the first to like this

Towards Modularity in Live Visual Modeling: A case-study with OpenPonk and Kendrick

  1. 1. Towards Modularity in Live Visual Modeling A Case Study with OpenPonk and KENDRICK
  2. 2. Towards Modularity in Live Visual Modeling •Jan Blizničenko (bliznjan@fit.cvut.cz) •Nick Papoulias (nikolaos.papoulias@upmc.fr) •Robert Pergl (robert.pergl@fit.cvut.cz) •Serge Stinckwich (serge.stinckwich@ird.fr) 2
  3. 3. Live Visual Programming & Modeling is great ! • Especially for people outside the core CS curriculum • Example: Students & Experts of all “computational” disciplines that use modeling and simulation as an experimentation tool • From Chemistry to Biology and Medicine, and from there to Epidemiology, Sociology and many others.. 3
  4. 4. Live Visual Programming & Modeling is great ! • This does not scale, beyond small examples • What happens when you are trying to model complex systems of MANY interacting parts ? • How is composition or modularity expressed lively and visually at runtime ? • Current solutions are MONOLITHIC (ie one visual part at a time externally composed) Unfortunately…. 4
  5. 5. Live Visual Programming & Modeling is great ! •But we need modular visual exploration •To understand complex composition semantics arising in domains such as epidemiology: = + 5
  6. 6. Live Visual Programming & Modeling is great ! •To understand complex composition semantics arising in domains such as epidemiology: = + => Visually Edit “PART” Lively Update “WHOLE” (Cartesian product semantics) Lively Update Execution Context and Simulation Results 6
  7. 7. Live Visual Programming & Modeling is great ! •To understand complex composition semantics arising in domains such as epidemiology: = + => Visually Edit “PART” Lively Update “WHOLE” (Cartesian product semantics) Lively Update Execution Context and Simulation Results • Q1 How can we extend a modeling platform (such as OpenPonk) to support modular exploration? • Q2 How can such a modular platform integrate with execution back-ends to provide live simulation feedback? 7
  8. 8. KENDRICK is a moldable platform for epidemiological modeling and analysis 8 Visualizations
  9. 9. What is Epidemiological Modelling ? •Building mathematical to study dynamics of disease propagation inside a population •Compartimental modelling 9
  10. 10. Separation of concerns (modularity) in Epidemiological Modelling • Decompose highly-coupled models into modular concerns • Compose concerns as freely as possible • Models in KENDRICK are expressed as stochastic automata that can be composed. 10
  11. 11. Multiple concerns Models in Epidemiology 11
  12. 12. Problems for Visual Kendrick •Modular in live textual modeling but.. •Complete recompilation for each and every edit •Visual modeling needs to be MORE INCREMENTAL •Incremental Editing -> Incremental Composition •Examples: Showing interactively diffs between composition results and simulation outputs ... 12 KendrickModel SIR attribute: #( status −> S I R ); parameters: #( beta lambda gamma mu ); transitions: #( S −− lambda −−> I #'.' I −− gamma −−> R #'.' status −− mu −−> Empty #'.' Empty −− mu −−> S #'.' ). KendrickModel SEIRS extends: 'SIR'; parameters: #( sigma nu ); delay: #( sigma , S −− lambda −−> I , E ); addTransition: #( R −− nu −−> S #'.' ); addTransition: #( E −− mu −−> Empty #'.' ).
  13. 13. OpenPonk •Visual diagram-based modeling tool •Implemented in Pharo •OpenSource •Designed to be extensible • by new models and notations • by new functions 13
  14. 14. Problems for Modular OpenPonk 14 •User interface that allows display impacts of change simultaneously •Both definitions and whole final models as diagrams •Working with elements of one model in definition of another •Communication with backend that creates models and results
  15. 15. Our Solution •User interface that allows display impacts of change simultaneously •Both definitions and whole final models as diagrams •Working with elements of one model in definition of another •Communication with backend that creates models and results 15
  16. 16. Our Solution •User interface that allows display impacts of change simultaneously ➥ User interface with two views - for definitions and results •Both definitions and whole final models as diagrams •Working with elements of one model in definition of another •Communication with backend that creates models and results 16
  17. 17. User interface with two views 17
  18. 18. Our Solution •User interface that allows display impacts of change simultaneously •Both definitions and whole final models as diagrams •Working with elements of one model in definition of another •Communication with backend that creates models and results 18
  19. 19. Our Solution •User interface that allows display impacts of change simultaneously •Both definitions and whole final models as diagrams ➥ Requirement for new diagram-friendly models •Working with elements of one model in definition of another •Communication with backend that creates models and results 19
  20. 20. Extension of OpenPonk 20
  21. 21. Our Solution •User interface that allows display impacts of change simultaneously •Both definitions and whole final models as diagrams •Working with elements of one model in definition of another •Communication with backend that creates models and results 21
  22. 22. Our Solution •User interface that allows display impacts of change simultaneously •Both definitions and whole final models as diagrams •Working with elements of one model in definition of another ➥ "Link" elements that reference other models •Communication with backend that creates models and results 22
  23. 23. Extension of OpenPonk 23
  24. 24. Our Solution •User interface that allows display impacts of change simultaneously •Both definitions and whole final models as diagrams •Working with elements of one model in definition of another •Communication with backend that creates models and results 24
  25. 25. Our Solution •User interface that allows display impacts of change simultaneously •Both definitions and whole final models as diagrams •Working with elements of one model in definition of another •Communication with backend that creates models and results ➥ "Bridge" component responsible for updating results 25
  26. 26. Extension of OpenPonk 26
  27. 27. Updating dependenices 27 Definition A Result A Definition B Result B Definition C Result C
  28. 28. Links 28
  29. 29. Links with broken references 29
  30. 30. Updating dependenices 30 Definition A Result A Definition B Result B Definition C Result C
  31. 31. Broken references 31 Definition AX Result AX Definition B
  32. 32. Example Session https://youtu.be/GFrIImGaGtA 32
  33. 33. Thank you https://github.com/bliznjan/openponk-modularity https://ummisco.github.io/kendrick/ https://openponk.github.io/ Kendrick/OpenPonk-based case study code: Kendrick: OpenPonk: 33

×