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.

Enabling Performance Modeling for the Masses: Initial Experiences


Published on

Performance problems such as sluggish response time or low throughput are especially annoying, frustrating and noticeable to users. Fixing performance problems after they occur results in unplanned expenses and time. Our vision is an MDE-intensive software development paradigm for complex systems in which software designers can evaluate performance early in development, when the analysis can have the greatest impact. We seek to empower designers to do the analysis themselves by automating the creation of performance models out of standard design models. Such performance models can be automatically solved, providing results meaningful to them. In our vision, this automation can be enabled by using model-to-model transformations: First, designers create UML design models embellished with the Modeling and Analysis of Real Time and Embedded systems (MARTE) design specifications; and secondly, such models are transformed to automatically solvable performance models by using QVT. This work reports on our first experiences when implementing these two initial activities.

See full articla at:

Published in: Technology
  • Login to see the comments

  • Be the first to like this

Enabling Performance Modeling for the Masses: Initial Experiences

  1. 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. 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
  3. 3. Software Performance Engineering 3
  4. 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. 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. 6. Automated Software Performance Engineering 6
  7. 7. Defining Performance Scenarios and Requirements with UML and MARTE 7
  8. 8. Deployment Diagrams • Execution architecture of the system • Hardware elements providing processing services. 8
  9. 9. Class Diagrams • Logical entities of the system. • Software elements, communications and synchonization entities (mutex). 9
  10. 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. 11. Sequence Diagrams • Describe key performance scenarios. • Typically include fine-grained resource usage information (e.g. in ExecutionSpecifications or in Messages) 11
  12. 12. Automatic transformation to Performance Models 12 QVT S-PMIF+
  13. 13. 13
  14. 14. Performance Modeling for the Masses The tool 14
  15. 15. 15
  16. 16. 16
  17. 17. 17
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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