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: https://dx.doi.org/10.1007/978-3-030-01042-3_7

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

3. Software Performance Engineering
3

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