Enabling Performance Modeling for the Masses: Initial Experiences
- 1. Enabling Performance Modeling for the Masses: Initial Experiences Abel Gómez, Connie U. Smith, Amy Spellmann, and Jordi Cabot Internet Interdisciplinary Institute – Universitat Oberta de Catalunya, Spain L&S Computer Technology, USA 1
- 2. • Performance problems are obvious to users: sluggish response time, low throughtput… • Performace issues cause rejection of new products, or event loss of life. • Performance is a competitive edge… … but performance problems are typically tackled after they occur. • Unplanned expense and time for refactoring. 2
- 4. Software Performance Engineering •SPE is a labor-intensive approach. •Requires considerable expertise and effort. •Performance engineers work side by side with system designers. 4
- 5. Can system designers do the analysis themselves? • C1 — We need model specifications to express performance-determining design elements. • C2 — We need transformation tolos from system design models to performance models 5 MDE
- 6. Automated Software Performance Engineering 6
- 7. Defining Performance Scenarios and Requirements with UML and MARTE 7
- 8. Deployment Diagrams • Execution architecture of the system • Hardware elements providing processing services. 8
- 9. Class Diagrams • Logical entities of the system. • Software elements, communications and synchonization entities (mutex). 9
- 10. Composite Structure Diagrams • Describe how specific instances participating in a system relate to each other (from a static POV). • Specify resources, workloads and allocations. 10
- 11. Sequence Diagrams • Describe key performance scenarios. • Typically include fine-grained resource usage information (e.g. in ExecutionSpecifications or in Messages) 11
- 12. Automatic transformation to Performance Models 12 QVT S-PMIF+
- 13. 13
- 14. Performance Modeling for the Masses The tool 14
- 15. 15
- 16. 16
- 17. 17
- 18. About the project • 2 months, led by two experts • 200 correspondences • 40 MARTE stereotypes and their S-PMIF+ counterparts • 8 meetings • 150 e-mails • 118-pages report 18
- 19. Some thoughts • Barrier to entry: the modeling languages • UML and MARTE are extensive standards • There are ambiguities in the standards (e.g. MARTE VSL expressions). • There is a lack of online documentation with systematic modeling guidelines. The report (1/3!) had to provide specific recommendations and guidelines. 19
- 20. Some thoughts • About the QVTo language • Imperative transformation languages do not have specially good reputation, but… … it facilitated the processing of ordered elements • Good logging and assertions support • Explicit support for libraries • Helpers can contribute new properties and operations dynamically • Intermediate clases can be defined (very useful to reify VSL expressions) 20
- 21. Some thoughts • Repetitive transformation code: • 4 files • 2027 LOC • More the 60% of the code deals with auxiliary tasks • This has an important impact in the effort estimation 21 Stereotypes 12% Strings 13% VSL & NFP 22% Helpers 15% M2M 38% LOC Stereotypes Strings VSL & NFP Helpers M2M
- 22. Some thoughts • Limitations of the modeling tools • Papyrus is the most popular tool for UML modeling in the Eclipse ecosystem. • It still has important and known limitiations, specially w.r.t Sequence Diagrams. • Ordering is important… … but it is easily lost. • Papyrus models get corrupt very easily. • Garbage elements are commonly left around. 22
- 23. Some related work • Assessment of non-functional requirements, such as performance, is a well stablished discipline. • Different formalisms, techniques and levels of automation have been achieved. • PUMA, Palladio, Descartes Modeling Language, DICE framework, process mining techniques… 23
- 24. Some related work • Most of them are similar in concept, but: • Some require performance-specific annotations from MARTE/PAM (closely related to LQN), requiring performance expertise. E.g., PUMA. • Some use specific DSLs (although similar to UML). E.g., PCM; DML. • Some make use of their own profiles (although extending MARTE/DAM). E.g. DICE. • Most of the transform to one specific tool, rather tan a MIF. 24
- 25. Conclusions • Automated SPE processes are posible. • MDE techniques and MIFs are valuable assets. • We eliminate the need of manually creating performance models (laboriuos and error prone task). • We created a prototype demonstrating the viability of the approach. 25
- 26. Enabling Performance Modeling for the Masses: Initial Experiences Abel Gómez, Connie U. Smith, Amy Spellmann, and Jordi Cabot Internet Interdisciplinary Institute – Universitat Oberta de Catalunya, Spain L&S Computer Technology, USA 26