Automated Translation among EPSILON Languages for Performance-Driven UML Software Model Refactoring
•Descargar como PPTX, PDF•
0 recomendaciones•210 vistas
Presentation at 1st International Workshop on Refactoring
Recomendados
Recomendados
Más contenido relacionado
Similar a Automated Translation among EPSILON Languages for Performance-Driven UML Software Model Refactoring
Similar a Automated Translation among EPSILON Languages for Performance-Driven UML Software Model Refactoring (20)
Último
Último (20)
Automated Translation among EPSILON Languages for Performance-Driven UML Software Model Refactoring
- 1. Dipartimento di Ingegneria e Scienze Università degli Studi dell’Aquila dell’Informazione e Matematica Automated Translation among EPSILON Languages for Performance-Driven UML Software Model Refactoring Davide Arcelli davide.arcelli@univaq.it Vittorio Cortellessa vittorio.cortellessa@univaq.it Daniele Di Pompeo daniele.dipompeo@gradutate.uunivaq.it
- 2. • Introduction • Model Refactoring Framework • Automated Translation among EPSILON Language • Conclusion Agenda DISIM @ University of L'Aquila 2 / 21
- 3. Software Model Performance- oriented Model Integration Performance- oriented Software ModelApplication Designer <<build>> Performance Antipattern Detection & Model Refactoring Framework OR <<codify>> Performance Expert UML+MARTE Metamodel <<conform to>> <<conform to>> Porting Engine EVL EPL EWL Framework within SPE [1,2,3] DISIM @ University of L'Aquila 3 / 21
- 4. Performance Antipattern Formalism [4] DISIM @ University of L'Aquila 4 / 21
- 5. • Developed by York University • Is an open source eclipse based project • Provides a suite of languages to elaborate models • Is made up of 7 languages, each one is thought for a specific goal EPSILON Suite Language [5] DISIM @ University of L'Aquila 5 / 21
- 6. • EVL is a validation language. It provides a window as validation session output • EWL is a visual language, it provides a graphical wizard in order to apply defined rules • EPL is a batch language, it does not provide a graphical / window session output, but it provides a running configuration and it analyses the source model and applies refactoring actions in background EPSILON: Selected Languages DISIM @ University of L'Aquila 6 / 21
- 7. • Introduction • Model Refactoring Framework • Automated Translation among EPSILON Language • Conclusion Agenda DISIM @ University of L'Aquila 7 / 21
- 8. - el Performance Antipattern Detection & Model Refactoring Framework OR <<codify>> Performance Expert Porting Engine EVL EPL EWL Model Refactoring Framework [6] DISIM @ University of L'Aquila • The library is thought for supporting the extensibility of the Framework • It is made up of different EOL files one for each: • Supported Meta-Class (i.e., Component, Node, Lifeline etc.) • Defined Thresholds 8 / 21
- 9. - el Performance Antipattern Detection & Model Refactoring Framework OR <<codify>> Performance Expert Porting Engine EVL EPL EWL The Porting Engine DISIM @ University of L'Aquila • Is a JAVA program • Exploits the EPSILON AST • Uses our defined mappings • Does not support translation among every EPSILON languages 9 / 21
- 10. • Introduction • Model Refactoring Framework • Automated Translation among EPSILON Language • Conclusion Agenda DISIM @ University of L'Aquila 10 / 21
- 11. Mappings among Languages EVL EWLEPL DISIM @ University of L'Aquila 11 / 21
- 12. Automated Translation in practice DISIM @ University of L'Aquila 12 / 21
- 13. Automated Translation: example Here we create the target EPL AST DISIM @ University of L'Aquila 13 / 21
- 14. Automated Translation: example They are the file imports used into the source EPSILON language DISIM @ University of L'Aquila 14 / 21
- 15. Automated Translation: example For each Fix of each Critique of each Context we create a new Pattern in the target EPL AST DISIM @ University of L'Aquila 15 / 21
- 16. DEMO DISIM @ University of L'Aquila 16 / 21
- 17. • Introduction • Model Refactoring Framework • Automated Translation among EPSILON Language • Conclusion Agenda DISIM @ University of L'Aquila 17 / 21
- 18. Model-based automatic generation of EPSILON code Introducing heuristic for estimating • Antipattern occurrence probability • Refactoring action effectiveness Integration with other refactoring approaches • Software Reliability • Improving of functional design Future Work DISIM @ University of L'Aquila 18 / 21
- 19. • The framework supports different Assistant Designer • The framework works on UML (Component) models • The framework can also work over DSLs • Everyone can write his own rules (detections and refactoring actions) Conclusion DISIM @ University of L'Aquila 19 / 21
- 20. Questions ? Automated Translation among EPSILON Languages for Performance-Driven UML Software Model Refactoring DISIM @ University of L’Aquila Arcelli, D., Cortellessa, V. and Di Pompeo, D. {davide.arcelli,vittorio.cortellessa}@univaq.it – daniele.dipompeo@graduate.univaq.it https://github.com/SEALABQualityGroup DISIM @ University of L'Aquila 20 / 21
- 21. • [1] C. Smith, “Introduction to Software Performance Engineering: Origins and Outstanding Problems,” in Formal Methods for Performance Evaluation, vol. 4486, Springer, 2007, pp. 395–428. • [2] C. U. Smith and L. G. Williams, “New Software Performance AntiPatterns: More Ways to Shoot Yourself in the Foot,” presented at the CMG Conference, 2002, pp. 667–674. • [3] C. U. Smith and L. G. Williams, “More New Software Antipatterns: Even More Ways to Shoot Yourself in the Foot,” presented at the CMG Conference, 2003, pp. 717–725. • [4] V. Cortellessa, A. Di Marco, and C. Trubiani, “Performance Antipatterns as Logical Predicates,” presented at the ICECCS, 2010, pp. 146–156. • [5] D. Kolovos, L. Rose, R. Paige, and A. Garcıa-Domınguez, “The epsilon book,” Structure, vol. 178, pp. 1–10, 2010. • [6] D. Arcelli, V. Cortellessa, and D. Di Pompeo, “Towards a Unifying Approach for Performance-Driven Software Model Refactoring,” presented at the MPM co-located with MODELS, 2015, pp. 42–51. References DISIM @ University of L'Aquila 21 / 21
Notas del editor
- Good evening everyone, my name is Daniele Di Pompeo and I’m talking about “Automated Translation among EPSILON languages for performance driven UML software model refactoring”.
- This is the agenda of this presentation. This presentation is organized into 4 parts: IN The Introduction I present you SPE and EPSILON suite language In the second part will be presented the framework In the third part will be presented the core of this work, with a video demo for showing you how the framework works In the last part the conclusion with future work both a short and a long term.
- The software performance engineering has been presented by Connie Smith on the 2007 with the work “Introduction to Software Performance Engineering: Origins and Outstanding Problems”. The SPE is a process that allows to discover performance flaws during all development phases. In the SPE there are two paths: The first path from Software model to Performance Indices is called Forward Path. This path is widely discovered by literature and there are a lot of works on the transformation of a Software Model into a Performance Model. The second path from performance indices to Software model is called Backward Path. This is a new idea and there are a little bit of works, in how to show a understanding output. Our framework works within this ring, specially in the latter path. In parallel or in a different moment of the construction of the software model the Performance Experts codifies Detection rules and refactoring actions within our framework. Furthermore Smith classified these performance flaws as pattern calling Performance Antipattern Like a pattern a PA describes a performance problem that repeats itself more and more times, so each PA has a name, a description both for the occurrence and for the effect and one or more possible solutions. The framework uses the EPSILON suite language as a core language and thanks to the Automated Porting among EPSiLON languages the Performance Expert will write rules in only one language and as a porting result he obtains the same rules in the other languages.
- In order to have an automatic discovering of PA, far years ago my research group presented in ” Performance Antipatterns as Logical Predicates” a kind of formalism for representing the description of the PA in a natural language as logical predicates. These logical predicates allow an automatic or semi-automatic detection into models, for example with UML models. For obtaining a better representations of the PA we use a multiple views representation. In this case we have the Extensive processing description both in the “formal” specification and in the graphical representation. Both images show the multiple views, static dynamic and deployment view. Furthermore In the left side of the figure is depicted the presence of the PA, as a kind of graphical representation of the natural language description. In the right side, instead, is depicted the model after the application of the refactoring action. As a result of the refactoring action we have a new system version in which we hope to have removed the PA occurrence, introducing an overall benefit
- This is the agenda of this presentation. This presentation is organized into 4 parts: IN The Introduction I present you SPE and EPSILON suite language In the second part will be presented the framework In the third part will be presented the core of this work, with a video demo for showing you how the framework works In the last part the conclusion with future work both a short and a long term.
- We have presented the first release of this framework at MPM workshop co-located with Models 2015. We have developed it in an extensible manner, and for introducing an high cohesive and extensibility we have developed a library. The library guarantees the extensibility and besides a good modularity, thanks to which the debugging is easy to do. The library is made up of a set of eol files, one for each supported model type, and other useful ones that are used as support. For example we use a file for defining performance thresholds. Thanks EPSILON and our development standpoint the framework can work both UML models and any DSL In particular for working with a specific DSL it is only required to write the relative library both fot detection rules and for refactoring actions
- In order to reduce the coding effort for getting the most of our framework we have introduced an automated porting among the three selected languages. The porting engine is a java program that exploits the epsilon Abstract syntax tree. It can be activated only after the parsing of the source file. The porting engine is not thought for supporting every grammar items of the three selected languages, but it provides only a porting among supported items. In order to rewrite the target AST to file we have extended EPSILON, in a light manner. We have introduced an Interface with a method named rewrite. Each involved class of the core of epsilon should override the method returning itself in a right format.
- Here a graphical representation of defined mappings among three epsilon languages. We have identified a relationship among Context in EVL Pattern in EPL and Wizard in EWL. So in this example I consider EVL as a source language, but it is the same if we start from one of the other two languages. In EVL we have the keyword context that specifies what meta-class <type> is involved. In EPL and in EWL we do not have a keyword, thus in EPL we use the declaration block in which we can define variables, which are used into the pattern block. Therefore we define mainRole as the involved meta-class. In EWL we do not have a declaration block as in EPL and it does not provide the keyword context as it is in EVL, thus we use in the guard block the function isTypeOf provided by EPSILON that allows to filter the context on which the wizard should be activated The content of the check block in EVL is reported as it is in Match and in guard block in EPL and EWL respectively. As we can see the keyword message of EVL is ignored because in the two target languages is not available. The EVL title is mapped with the EWL title and in EPL is ignored, since in EPL we do not produce any kind of interactive output. The do block of EVL is mapped as it is in onmatch and do block in EPL and EWL respectively.
- The porting engine exploits the AST of epsilon to realize the translation. It means that only at the correct ending of parsing of EVL file we can use the porting. Exploiting the EPSILON parser we are sure that the source target does not have syntactic errors and the translation should produce a right output. The translation is made up of 3 step:
- The first step is the construction of the Target ABS, in this example an EPL AST.
- The second step is the translation of used “import” from the source to the target. We use imports to create the library more extensible as possible. We can consider the single file as a module of the library in which we codify the relative operation. Using this approach we obtain an high cohesive library and we should simplify the debugging.
- The third step is the translation of the core of the source AST following defined mappings. In this example we build in output an EPL file starting from and EVL module. From our mappings we make an EPL pattern for each FIX of each CRITIQUE of each CONTEXT. At the end of the third step the function returns the target AST and it is used by the method ast2file, which writes 2 target files.
- Caricare il video anche su youtube aprendo un canale di gruppo
- So we are coming to the end of this presentation.
- We present you three major future steps. The first is a short term step. We want to create a Model-based automatic generation of EPSILON code, to mostly reduce the effort of coding. With this development manner we think that not only a Performance Expert with EPSILON background could write his own rules and refactoring actions. In a medium term we want to introduce heuristics about PA occurrence probability and refactoring action effectiveness. This is absolutely a key point of a refactoring framework, in fact with these heuristics we can help the user for understanding if his models really have PAs. In a long term we want to combine this approach with other approaches like Software reliability. We think that our framework is enough extensible for supporting this integration. In fact if the Application Designer wants to use our framework for improving his functional design he should only write detections rules and eventually refactoring actions.
- i have presented you our framework and how we have created the automated translation among EPSILON languages. i have showed how our framework works within SPE and within EPSILON suite languages. And i have described a future work in a short medium and long term.
- if you have questions I am happy to answer.
- As we saw in some previous slides, from the 7 available languages of EPSILON we have selected EWL EVL and EPL because they are a good support for a multiple detection and solution sessions. So we have 3 kind of sessions Visual session in which the user, probably not a Performance Expert but a Software Designer, uses the framework over his model in a graphical tool, for example with papyrus Multiple session the user, maybe the Performance Expert, uses the framework on the source model but not with a graphical tool but he uses the windows session output provided by EPSILON. We think that this kind of detection session is used by a Performance Expert rather than Application Designer because the user does not have an overview of model but only the list of detected PAs, therefore he must be aware of what PA he will erase. The last, but not the least, session is the batch one. We propose this session because it could be used in automatic manner thanks to the running configuration that is provide by EPSILON. During the batch session the user will not receive any notification from the framework, and it will independently execute the defined refactoring actio.ns
- Figura del framework con vista generale
- Here an example in how the Performance Expert should write his rules within our framework In this example we present the Extensive Processing Performance Antipattern codified in EVL.
- The keyword Context specifies the meta-class on which this rule works. Critique is an other EVL grammar word, we use critique because in epsilon it represents a warning, so in our point of view the presence of PA is more similar to a warning than an error. Message and title are the output keywords and they show a message to the user Fix contains the refactoring rules, that are specified in the do block. Do is the imperative block of EVL
- The keyword check, instead, is the declarative block and it is used to represent the PA logic formula. To activate the PA refactoring actions the condition of check must be violated, so we negate the result of the Boolean condition. Each threshold function returns true if the threshold is not met, false otherwise.
- To make the framework ”il piu’ enstensibile possiible” each operation is more atomic as possible, so in this slide we present you a refactoring action of Extensive Processing PA.
- In order to reduce the effort for codifying same rules into three different languages we introduce an Automated Porting among EVL, EWL and EPL
- The SPE is made up of: A design model given as input of the process. The design model is a representation of the system in a whatever modelling convention or language. E.g we use a UML as modelling language The second step is to translate the Design Model in a Performance Model which may be a Queueing Network or a Discrete Time Markov Chain, let me say for the Performance Model we can use any modelling language for obtaining Performance indices Performance indices are the result of the evaluation of the used Performance Model and they provide performance information about the system. Typical performance indices are Response Time, Throughput, Utilization. Then we need to put them in the initial design model to understand what part of the system causes flaws. The end of the process is the evaluation of the performance indices over the model and the application of some refactoring action to remove these flaws.