Lucia Happe8Confi gurable Software Performance Completions through Higher-Order Model TransformationsLucia HappeThe Karlsruhe Series on Software Design and Quality 8Confi gurable Software Performance Completions through Higher-Order Model TransformationsLucia HappeConfigurable Software Performance Completions through Higher-Order Model TransformationsThe Karlsruhe Series on Software Design and Quality Volume 8Chair Software Design and QualityFaculty of Computer ScienceKarlsruhe Institute of TechnologyandSoftware Engineering DivisionResearch Center for Information Technology (FZI), KarlsruheEditor: Prof. Dr. Ralf ReussnerConfigurable Software Performance Completions through Higher-Order Model Transformationsby Lucia HappeDissertation, Karlsruher Institut für Technologie (KIT)Fakultät für InformatikTag der mündlichen Prüfung: 10. November 2011Referenten: Prof. Dr. Ralf H. Reussner, Assist.-Prof. Petr Hnetynka PhD.Print on Demand 2014ISSN 1867-0067ISBN 978-3-86644-990-9 This document – excluding the cover – is licensed under the Creative Commons Attribution-Share Alike 3.0 DE License (CC BY-SA 3.0 DE): http://creativecommons.org/licenses/by-sa/3.0/de/The cover page is licensed under the Creative Commons Attribution-No Derivatives 3.0 DE License (CC BY-ND 3.0 DE): http://creativecommons.org/licenses/by-nd/3.0/de/ImpressumKarlsruher Institut für Technologie (KIT) KIT Scientific Publishing Straße am Forum 2 D-76131 KarlsruheKIT Scientific Publishing is a registered trademark of Karlsruhe Institute of Technology. Reprint using the book cover is not allowed. www.ksp.kit.eduAbstractPerformance is one of the key quality attributes of a software system andis crucial for its success. Software performance engineering (SPE) sup-ports developers and architects in building responsive and resource effi-cient applications. During early development stages, performance predic-tions based on architecture models allow the evaluation of design alter-natives, capacity planning, and the identification of potential bottlenecks.To provide accurate performance predictions, such models have to includelow-level details, for example, about the underlying middleware or designpatterns used. Including such low-level details conflicts with the abstractarchitecture paradigm. It leads to significant modelling effort for softwarearchitects and requires detailed knowledge about the modelled system.Model-Driven Software Development (MDSD) can solve this conflictand include the necessary details using model transformations. However,such transformations have to cope with the complexity of today’s architec-ture models. Additionally, lower levels (infrastructure or implementation)are variable in many cases. The effect of such variability on performancemust be captured in the transformations. Current MDSD technologies cansupport variability of transformations only to a limited extend.In literature, completions allow the inclusion of low-level details intohigh level prediction models. However, they are not fully automated, arenot variable and configurable, and make limited use of MDSD technolo-gies. Related solutions introducing variability in MDSD typically dealwith model instances only. As a consequence, model transformations be-come very complex and hard to understand, develop, and maintain. Toiovercome this problem, we have to introduce variability to transformationsthemselves, which is not supported by current transformation languages.In this thesis, we propose an advanced concept for model transforma-tions closing the gap between abstract architecture models and low-leveldetails. For this purpose, we extend existing MDSD techniques by vari-ability of transformations. Our approach, called CHILIES, moves the man-agement of variability to a higher abstraction level. We enable variabilityof transformations using generators based on the presented Higher-OrderTransformation (HOT) patterns. HOT patterns target different goals, suchas template instantiation or transformation fragment composition. We ap-plied our approach to the domain of SPE to complete prediction models. Inthis thesis, we developed a completion library that allows to reuse expertknowledge and to improve the accuracy of performance predictions.The validation of our approach addresses the improvement of predictionaccuracy by completions and the complexity of their transformations. Weevaluated the prediction accuracy of the completions developed in the scopeof this thesis in several case studies by comparing performance predictionresults to measurements on real implementations. Our results imply thatthe prediction accuracy can be increased significantly when completionsare applied to a software performance model. Furthermore, we comparedthe complexity of manually implemented transformations to transforma-tions developed with our CHILIES framework. The results suggest thattransformations developed using CHILIES are less complex and more fo-cussed as they allow to manage variability more efficiently.iiAcknowledgmentsI enjoyed the work on my thesis so much especially because of the peoplewho accompanied me. This thesis would not be possible without constantsupport, guidance and encouragement provided to me by my colleagues,friends and immediate family members. They helped me to overcome dailyobstacles during this, sometimes hard, but always enjoyable period of mylife.I want to begin with the most important and very patient witness of mylife. Jens, this work would not have been possible without your love and en-couradgement you always have for me. I am happy (happe :)) to have sucha beautiful family with you and I am very grateful for our little daughterNatalie. I want to mention here as well the unconditional support, love andmotivation that my parents gave me. They are accompaning me from thebeginning and they are my biggest fans. With you standing behind me noth-ing can go wrong. Matko, my lovely brother, I want to thank you for yourlasting support, love and inspiration. You all make my life worth living. Ilove you and I am grateful to have you all!Fundamental for this work and my research was guidance and supportfrom Prof. Dr. Ralf Reussner, who gave me thorough guidance for mydissertation and taught me the principles of good research. Thank you fromwhole heart for your patience and for being the best advisor I ever met(far beyond PhD thesis). You gave me motivation to accomplish my goals,constructive critic and helpfull feedback. You provoked me to be betterand better in everything I do. Moreover, I thank you for the exeptional andstable research enviroment full of team-spirit that you created.iiiIn this environment I could meet my PhD-fellows and visiting researcherswho accommpanied my research. Many of you happen to be wonderfullfriends and an irreplaceable part of my life far beyond PhD research. De-spite the male-dominated profession, I have to mention at first number ofwomen: Bara, who has unfalling endurance in support and fine-tunningresearch ideas, Anne, who I love to have discussions with, Catia, whobrought energy and even more fun in our research. Girls, thank you for thegreat time we had! When mentioning support and endurance, I’m thinkingof Thomas Goldschmidt, who was a grey eminence behind my work andguided my first experiments in the MDSD world. Thomas, thank you foryour support!Moreover, I worked with many great people from various projects atthe Charles University in Prague and at the University of Karlsruhe (TH).From the Charles University, I would like to thank all members of D3SGroup, in particular, I would like to thank Petr Hnetynka for supervisingthis thesis and for his detailed and constructive comments. Furthermore,I want to thank Ján Kofroň, Lubomír Bulej, Tomáš Bureš, Petr Tu̇ma andFrantišek Plášil for their support and motivating discussions. At the Uni-versity of Karlsruhe (TH), the people from the SDQ group strongly con-tributed to this work. Especially, I would like to thank: Heiko Koziolek,Steffen Becker, Klaus Krogmann, Michael Kuperberg, Erik Burger, JörgHenss, Franz Brosch, Martin Küster, Michael Hauck, Matthias Huber, An-dreas Rentschler, Max Kramer und Philipp Merkle for their valuable feed-back, constructive discussions and unforgettable collaboration. During thecourse of this work, I supervised the bachelor or diploma theses of MishaStrittmatter and Christian Vogel whose contributions are also part of thiswork. Many thanks to both of you! Misha, I really enjoyed, and still enjoy,working with you. I would also like to thank all students I had the pleasureto work with: Georg Hinkel, Christian Heupel, Florian Klein, ChristianHarnisch, Christoph Kurrat and Thomas Schuischel.ivFurthermore, I have been lucky to work with number of researcherswho inspired and motivated me. Big thanks to Raffaela Mirandola, Do-rina Petriu, Colin Atkinson and Alberto Avritzer. Alberto, thank you forintroducing me into the world of smart-grids and energy distribution, it ispleasure to work with you!Last but not least, I would like to mention, a german-czekoslovakian col-laboration during the Check/Czech evenings with my colleagues BarboraBuhnova, Jan Kofron and Jens Happe who were the main ingredience forthe great time we had together.Karlsruhe, August 2012vContents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1. Research Questions . . . . . . . . . . . . . . . . . . . . . 41.2. Scientific Contributions . . . . . . . . . . . . . . . . . . . 61.3. Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 122. Foundations . . . . . . . . . . . . . . . . . . . . . . . . . . 152.1. Model-driven Software Development . . . . . . . . . . . . 162.1.1. Basic Artefacts of MDSD . . . . . . . . . . . . . . 172.1.2. Evolution of model transformation processes . . . . 272.2. Model-driven Software Performance Engineering . . . . . 352.2.1. CBSE Development Process . . . . . . . . . . . . 372.2.2. Palladio Component Model (PCM) . . . . . . . . . 392.2.3. Platform Completions . . . . . . . . . . . . . . . . 432.2.4. Software Performance Cockpit . . . . . . . . . . . 453. Model Completions . . . . . . . . . . . . . . . . . . . . . . 493.1. Model Completions and MDSD . . . . . . . . . . . . . . 503.1.1. Model Completion Concept . . . . . . . . . . . . . 543.1.2. Scientific Challenges in the MDSD context . . . . . 583.2. Model Completions and MDSPE . . . . . . . . . . . . . . 603.2.1. MDSPE Application Scenario . . . . . . . . . . . . 613.2.2. Performance Completions . . . . . . . . . . . . . . 633.2.3. Scientific Challenges in the MDSPE context . . . . 653.3. Completions in CBSE Development process . . . . . . . . 663.3.1. Running Example . . . . . . . . . . . . . . . . . . 69viiContents3.3.2. Completion-based Domain Engineering . . . . . . 703.3.3. Completion-based Software Engineering . . . . . . 883.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 904. Variability Management using Higher-OrderTransformations . . . . . . . . . . . . . . . . . . . . . . . . 934.1. Problem Domain . . . . . . . . . . . . . . . . . . . . . . 944.1.1. Increasing Expressive Power of Metamodels . . . . 944.1.2. Supporting Transformation Variability . . . . . . . 964.2. Introduction of the CHILIES Approach . . . . . . . . . . . 984.2.1. Scientific Contributions of this Chapter . . . . . . . 1004.2.2. Software Product Lines for Transformations . . . . 1024.2.3. Transformation Variability . . . . . . . . . . . . . 1044.2.4. Formalisation . . . . . . . . . . . . . . . . . . . . 1074.3. CHILIES: Higher-Order Transformation Patterns . . . . . 1154.3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 1164.3.2. Higher-Order Transformations . . . . . . . . . . . 1174.3.3. Notation . . . . . . . . . . . . . . . . . . . . . . . 1194.4. Routine HOT Pattern . . . . . . . . . . . . . . . . . . . . 1204.4.1. Definition . . . . . . . . . . . . . . . . . . . . . . 1204.4.2. Completions Support: Generation of a RoutineTransformation Frame . . . . . . . . . . . . . . . . 1274.4.3. Summary . . . . . . . . . . . . . . . . . . . . . . 1334.5. Composite HOT Pattern . . . . . . . . . . . . . . . . . . . 1354.5.1. Definition . . . . . . . . . . . . . . . . . . . . . . 1364.5.2. Completions Support: Generation of a CompletionTransformation . . . . . . . . . . . . . . . . . . . 1404.5.3. Summary . . . . . . . . . . . . . . . . . . . . . . 1564.6. Template HOT Pattern . . . . . . . . . . . . . . . . . . . . 1564.6.1. Definition . . . . . . . . . . . . . . . . . . . . . . 157viiiContents4.6.2. Completions Support: Generation ofTransformation Fragments using Templates . . . . 1594.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . 1744.7. CHILIES: Chains of HOT patterns . . . . . . . . . . . . . 1744.8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 1784.9. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 1815. Completions for Software Performance Engineering . . 1835.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 1835.2. Structured Completion Library for Conflict Reduction . . . 1865.2.1. Formalisation . . . . . . . . . . . . . . . . . . . . 1875.2.2. Method for Reduction of Completion ValidityConflicts . . . . . . . . . . . . . . . . . . . . . . . 1905.2.3. Method for Resolution of Completion QualityConflicts . . . . . . . . . . . . . . . . . . . . . . . 1955.3. Completion Library: Concurrency design patterns . . . . . 2035.3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . 2035.3.2. Categorisation of concurrency design patterns . . . 2055.3.3. Component Completions . . . . . . . . . . . . . . 2075.3.4. Connector Completions . . . . . . . . . . . . . . . 2215.3.5. Infrastructure Completions . . . . . . . . . . . . . 2335.4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 2385.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 2396. Model Transformation Analysis: EvaluatingMaintainability . . . . . . . . . . . . . . . . . . . . . . . . . 2416.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2426.2. Problem Domain . . . . . . . . . . . . . . . . . . . . . . 2446.3. Metrics Definition . . . . . . . . . . . . . . . . . . . . . . 2466.3.1. Automated Metrics . . . . . . . . . . . . . . . . . 2466.3.2. Manually Gathered Metrics . . . . . . . . . . . . . 2526.4. Computation of Metrics . . . . . . . . . . . . . . . . . . . 256ixContents6.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 2586.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 2587. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2617.1. Validation Goals . . . . . . . . . . . . . . . . . . . . . . . 2627.1.1. Validation Type I: Accuracy Validation . . . . . . . 2627.1.2. Validation Type II: Applicability Validation . . . . 2647.1.3. Validation Type III: Cost/Benefit Validation . . . . 2677.2. Improving Prediction Accuracy using PerformanceCompletions . . . . . . . . . . . . . . . . . . . . . . . . . 2687.2.1. Type I: Prediction Accuracy . . . . . . . . . . . . . 2687.2.2. Type I: Completion Composition and Ordering . . . 2927.2.3. Type II Validation: Applicability Evaluation . . . . 3067.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 3178. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 3198.1. Model Transformation Engineering . . . . . . . . . . . . . 3208.1.1. Development of Transformations for Reuse . . . . 3208.1.2. Development of Transformations with Reuse . . . . 3238.1.3. Quality Metrics for Model Transformations . . . . 3308.2. Platform Completions for Software Performance Engineering3328.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 3409. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 3459.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 3459.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 3529.3. Open Questions and Future Work . . . . . . . . . . . . . . 3539.3.1. Future work in the MDSPE context . . . . . . . . . 3539.3.2. Future work in the MDSD context . . . . . . . . . 355A. State Dependence in Software Performance Evaluation 361A.0.3. Challenges of Stateful Analysis . . . . . . . . . . . 363xContentsA.0.4. Stateful Component-Based Systems (SCBSs) . . . 366A.0.5. Specifics of CBSs with Respect to a State . . . . . 367A.1. State Categorisation for CBSs . . . . . . . . . . . . . . . . 369A.1.1. Component-Specific State . . . . . . . . . . . . . . 370A.1.2. System-Specific State . . . . . . . . . . . . . . . . 372A.1.3. User-Specific State . . . . . . . . . . . . . . . . . 374A.2. Performance Model for SCBSs . . . . . . . . . . . . . . . 375A.2.1. State of the Art Evaluation . . . . . . . . . . . . . 375A.2.2. Palladio Component Model (PCM) . . . . . . . . . 377A.3. Outline of the Approach . . . . . . . . . . . . . . . . . . . 378A.3.1. Quantification of Performance Impact . . . . . . . 379A.3.2. Quantification of Model Complexity . . . . . . . . 380A.3.3. Diversity Among State Categories . . . . . . . . . 381A.4. State Dependency Analysis . . . . . . . . . . . . . . . . . 382A.4.1. Protocol State . . . . . . . . . . . . . . . . . . . . 382A.4.2. Internal/Global State . . . . . . . . . . . . . . . . 385A.4.3. Allocation/Configuration State . . . . . . . . . . . 388A.4.4. Session/Persistent State . . . . . . . . . . . . . . . 390A.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 393A.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 394B. Further HOT patterns . . . . . . . . . . . . . . . . . . . . . 397B.1. Shared Configuration HOT Pattern . . . . . . . . . . . . . 397B.1.1. Motivation: . . . . . . . . . . . . . . . . . . . . . 397B.1.2. Implementation: . . . . . . . . . . . . . . . . . . . 398B.1.3. Benefits and Drawbacks: . . . . . . . . . . . . . . 399B.2. Retainment Policies HOT pattern . . . . . . . . . . . . . . 399B.2.1. Motivation: . . . . . . . . . . . . . . . . . . . . . 399B.2.2. Implementation: . . . . . . . . . . . . . . . . . . . 400B.2.3. Benefits and Drawbacks: . . . . . . . . . . . . . . 401xiContentsB.3. Model/View Synchronization HOT pattern . . . . . . . . . 401B.3.1. Motivation: . . . . . . . . . . . . . . . . . . . . . 402B.3.2. Implementation: . . . . . . . . . . . . . . . . . . . 402B.3.3. Benefits and Drawbacks: . . . . . . . . . . . . . . 402B.4. Analysis HOT pattern . . . . . . . . . . . . . . . . . . . . 403B.4.1. Motivation: . . . . . . . . . . . . . . . . . . . . . 404B.4.2. Implementation: . . . . . . . . . . . . . . . . . . . 404B.4.3. Benefits and Drawbacks: . . . . . . . . . . . . . . 404B.5. Future Scenarios . . . . . . . . . . . . . . . . . . . . . . . 405C. Examples of detailed QVT transformations . . . . . . . . 407C.1. Message Oriented Middleware Completion . . . . . . . . 407C.2. Pipe & Filter Connector Completion . . . . . . . . . . . . 414List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . 421List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429xii1. IntroductionFor successful and effective software development, the ability to predictthe impact of design decisions in early development stages is crucial. De-sign decision can influence quality properties, e.g., performance, of soft-ware systems. Using predictions, potential problems, such as bottlenecksand long delays, can be detected early avoiding costly redesigns or re-implementations in later stages. Williams and Smith [170] estimated thefinancial benefit of software performance prediction for medium sizedproject on several millions of US dollars.In model-driven software performance engineering [6], abstract designmodels are used to predict and evaluate response time, throughput, and re-source utilisation of the target system during early development stages.Inorder to provide accurate predictions, the performance models have to con-sider the influence of the underlying platform, of the operating system, andeven of used design patterns (e.g., concurrency design patterns). The low-level details influence performance metrics and as such are essential foraccurate predictions. The problem of missing details was already identifiedby Woodside et al. [172]:"Performance modelling is effective, but it is often costly; models areapproximate, they leave out detail that may be important, and aredifficult to validate."Including low-level details in prediction models conflicts with the ab-stract architecture paradigm and leads to a significant modelling effort forsoftware architects. Moreover, such models are very complex leading to11. Introductiona decreased understandability, reusability and model credibility. For ex-ample, the middleware’s complexity and the specific knowledge on theimplementation, which is required to create the necessary models, wouldincrease the modelling effort dramatically. Since the low-level details canappear in different configurations, it is hardly feasible to create such mod-els manually. This leads to the well known conflict between variability andautomation [172]:One of the obstacles to the adoption of performance tools is "a conflictbetween automation and adaptability in that systems which are highlyautomated but are difficult to change, and vice versa. As a result no tooldoes the job the user needs, so the user goes and invents one. Further,various tools all have different forms of output which makesinteroperability challenging at best."Woodside et al. in [172] point out the leading research question of thisthesis that addresses the problem of automated inclusion of variable low-level details into highly-abstract prediction models. The conflict betweenthe inclusion of low-level details into prediction models and maintaininghighly-abstract models can be addressed by Model-Driven Software Devel-opment (MDSD). Because of the reconfigurability of the included details,the used MDSD techniques must support variability as well.However, MDSD approaches lack an applicable and suitable solutionfor managing variability. Existing variability approaches result in a grow-ing complexity of transformations, limited usage of configurations, andthe maintainability of transformations quickly becomes a huge problem.Completion-based approaches described in the literature allow inclusion oflow-level details, however, they are not automated, do not support vari-ability of completions, or they are limited to the configuration of attributesonly. These approaches suggest only simple annotation models that ex-tend prediction models through parametrization of resource demands usingmeasurements on real systems (e.g., in the case of performance prediction,2for example, number of processor cycles needed for particular activity).They concentrate on the properties of the underlying platform and do notconsider structural changes in the architecture, such as inclusion of certaindesign pattern (e.g., Replication, Barrier, Connector patterns etc.).While most of the implementation details are not known in advance, arough knowledge about the design patterns that are to be used might beavailable already very early. This knowledge can be exploited for furtheranalysis, such as performance prediction. One reason why such details arenot considered is the high level of variability in the architecture that wouldbe required. It is not feasible to create such models manually. Therefore,automated tool support is crucial to build such detailed models.In this thesis, we propose a concept of configurable model transforma-tions to close the gap between an abstract model and low-level detailsrequired by the modelling purpose (e.g. to provide accurate predictionsof performance). The solution, presented in this thesis, is based on theparametrized model completions that include the details of lower levels intohigh-level architectures. Model completions are realised using and extend-ing existing model-driven technologies. They express low-level details asreconfigurable black-box constructs and, thus, hide the model complexityfrom software architects. Software architects only have to provide a con-figuration for the modelled detail. The integration of the configured detailis fully automated.MDSD allows to create software families specially tailored for a certaindomain and sharing common details. The existing techniques to supportvariability in the software families, however, mostly focus on the variabilityof models. Hence, the transformations, from a more general family memberinto a more detailed family member, define already how the model variantslook like. Thus, it is not necessary to actually create model variants, itis enough to focus on the variants of transformations generating requiredmodels. We take a step back and analyse broader variability scenarios in31. Introduction1. Introductionthe MDSD. We shift our attention from the variability of models to thevariability of other artefacts, especially transformations.The model transformations, sharing common parts, need to be cus-tomised to integrate different performance-relevant details. Moreover, thesedetails may introduce optional extensions to metamodels. In such situa-tion, we have to handle the variability of metamodels as well. We cre-ated an automated support of variable transformations development usingpre-processors and generators based on, so called, Higher-Order Transfor-mations (HOTs) [167]. The proposed approach, called CHILIES, presentsa set of HOT patterns for different variability scenarios. We use thesepatterns to build a Software Product Line (SPL) [37] for completion trans-formations. The CHILIES approach does not require heavy developmenteffort and allows the light weight integration of low-level details into per-formance prediction methods.1.1. Research QuestionsIn the scope of this thesis, we address research challenges from two ar-eas: (i) Model-Driven Software Performance Engineering (MDSPE), and(ii) Model-Driven Software Development (MDSD). More specifically, wework on answering the following research questions:Q1: How to include purpose-specific aspects to models in an automatedbut adaptable manner inheriting its standard mechanisms and facilities,including transformations and tools?The goal is to automate the integration of purpose-specific aspects intothe models. The model details increase the prediction accuracy as suchmore detailed models correspond better to the reality. Each aspect is encap-sulated in a completion and can be instantiated in different variants addedto the model. Potentially, we may use any of these completions and then,using completed models, generate the implementation, e.g. code, or to runanalyses. To support, for example, the code generation from any of these41.1. Research Questionsmodels, we have to maintain the same language as the generation chain re-quires as input. Moreover, the variability of completions results in multipleimplementations of transformations, which consist in majority of commonparts composed together with customisations based on the configuration.Thus, the second question emerges.Q2: How to support configuration-based variability in model transfor-mations?In other words, what methodology, technologies, model-driven struc-tures of pre-processors or generators are needed to support variability? Therequirement for variability results from different goals and different set-tings, which results in a different kinds of variability. Some of the requiredvariable artefacts have to be composed together, other are only instantiatedin form of templates or added as customisations of more general trans-formations. Our solution needs to support variability in transformationsresulting from these different requirements. The answer to this questionovercomes the limitations of current transformation approaches.Q3: How to structure the Completion Library to reduce possible conflictsin an application of multiple completions?The previous question deals with the management of variability in gen-eral. In our application domain, the Model-Driven Performance Engineer-ing (MDSPE), additional factors need to be considered. Especially, in thisdomain, conflicts in a sequence of completions has an additional dimen-sion, the dimension of quality attribute (i.e., performance). We discuss theapplication of the proposed method and the structure of the completion li-brary for MDSPE. In this context, we have to consider multiple applicationsof completions and the conflicts in their application. Furthermore, transfor-mations have certain quality properties themselves, which leads to the lastquestion.Q4: How to analyse maintainability of relational transformations?The final question deals with the evaluation of quality properties, such asmaintainability, ease-of-use or understandability, of resulting transforma-51. Introductiontions. We have to discuss the complexity and understandability of resultingtransformations. For this goal, we have to evaluate the metrics to quantifyquality properties of transformations.These research questions resulted in the scientific contributions listed inthe following section.1.2. Scientific ContributionsThe following gives details on the particular contributions. The main con-tributions of this thesis are:Generalised Model Completions The separation of concerns is es-sential to avoid construction of large and monolithic models, which arehard to maintain or reuse. Reusability of such models is limited espe-cially because such models are often designed for one purpose, as suchthey do not consider possible enhancements when the purpose of the modelchanges and new domain-specific details have to be introduced. For exam-ple, a component-based architecture model could be used to predict perfor-mance. However, the same model could be used to analyse reliability, aswell. Both of these purposes require additional domain-specific details, i.e.performance or reliability specific implementation details.Existing approaches do not consider model completions in general. Theidea of completions introduced by [174, 76], however, only in a form ofperformance-specific annotations. These approaches do not discuss the roleof model completions in MDSD, either provide a support for completions.Especially, they do not discuss the variability of structural changes resultingfrom completion integration.In the model-driven world, models are understood as instances conform-ing to predefined metamodels. Each model is created for certain purpose.Two models could have different levels of detail although they are basedon the same metamodel. Models may have even different level of detail in61.2. Scientific Contributionsthe same domain. Increasing the level of detail of a metamodel to the mag-nitude that each aspect of the real subject could be expressed by its modelwould increase complexity of metamodel in a such way that metamodelwould be unusable. Additionally, such metamodel does not support sepa-ration of concerns by modelling only one detail at the time. Having manymetamodels on a different level of detail is also infeasible. It is impossibleto foresee all different purposes for which a model could be created andrelated requirements on such models. This problem cannot be approachedon the metamodel level. It is necessary to come up with a solution on themodel level that would support the incremental completion of model in-stances that are in each step conform to the one and the same metamodel.We consider this approach as indirect extension of metamodel by introduc-ing (mini-)domain specific languages for a sub-domain of one completion.This way, we can define model pragmatics, similarly as it is possible forprogramming languages. Furthermore, the proposed solution should pro-vide support for reuse and reconfiguration of such incremental completions.We propose a concept of model completions to close the gap betweenan abstract model and low-level details required by the model’s purpose(e.g. to provide accurate predictions of performance). Completions donot change the metamodel, thus, all existing tools built for this modelling-language could be reused. The core idea of this thesis is to introduce modelpragmatics that could be used on a model level to increase the level ofdetail in model instances, without need to extend the metamodel directly.Moreover, the complexity of model enhancements encapsulated in comple-tions is hidden to the developers. They only configure the variant of thecompletion on an abstract level and the integration of the completion is ablack-box operation for them. These completions are highly variable, thusthe integration of them is non-trivial task, a lot of effort is needed to im-plement and to maintain any automated solution realizing them. We usean approach similar to model weaving. Each completion has a DSL for itsmodelled sub-domain and can be maintained individually. Together with71. Introductionthe original metamodel, completions are interconnected into a ’lattice ofmetamodels’ that could be considered as a more complete metamodel. Theidea is to allow the use of this more complete metamodel to create modelinstances and later transform instances to conforming to the original meta-model again, which allows reuse of existing tools. Because, the necessarytransformations inherit the high level of variability from completions andthe chosen variant is not known in advance, it is a higher-order problem.This challenge is the target of the second contribution in this thesis.CHILIES Variability Management Method The main contribution ofthis thesis is a novel approach called CHILIES which automates the man-agement of variability in transformations. The support of variability in thedefinition of transformations is crucial to support completions. Although,we apply CHILIES to support performance completions, our approach canbe used in other domains, as well.Typically, variability approaches focus on variability of models [154, 70,89] or propose solutions based on the model annotations [162, 12]. Themain problem of such approaches is the complexity of resulting transfor-mations which have to consider each possible combination of configurationoptions. The main advantage of our variability approach is provided byperforming the model transformation configuration automatically based onconfiguration instead of models. This separation of concerns can achievehigh variability and flexibility in the development of software applications.In this thesis, we created a Software Product Line (SPL) for model trans-formations using Higher-Order Transformations (HOTs). A HOT compilesa transformation model again into a transformation model. We used theseHOTs as pre-processors or generators, at load time of the transformation(e.g. in MDSPE), executed before the actual transformation. In our ap-proach, we use chains of HOTs where each HOT represents a differentpre-processing step. We identified different scenarios where the variabil-ity of transformations has to be handled and specified model-driven struc-81.2. Scientific Contributionstures using HOTs (called HOT patterns), which can be used to build SPLsfor transformations. Based on these patterns, software engineers can buildpre-processor chains to generate transformations on demand and integratethem into the existing model-driven process. By formalising these patterns,we build a framework allowing the reuse of HOT specifications. The SPLdesigned to support completions is a composition of three of such HOTpatterns: Routine, Composite and Template pattern.The first one is used for synthesis of a general transformation from ametamodel; the second one for transformation composition based on thestructure of the configuration model; the third one for the instantiation ofparametrized domain-specific templates as a partial transformation synthe-sis.Completion Library for Software Performance Engineering Thespecification of completions requires a lot of domain-specific expert knowl-edge (e.g. for performance prediction the knowledge about performance-relevant implementation details). Moreover, the same activities are oftenrepeated, e.g. usage of the same design pattern or integration of the samemiddleware platform. Therefore, we introduce a library offering reusablecompletions to developers. This library is structured, as mapping sets ofcompletions to the roles in the development process. Thus, one develop-ment role can configure only completions in its responsibility. Building onthe separation of concerns among the development roles is already reflectedin the design of the metamodel (e.g. in PCM), the responsibility domains ofthe roles can be mapped on disjunct sets of model elements. Based on thisprinciple, we can reduce conflicts in a sequence of multiple completions.Moreover, using predefined quality heuristics, we can evaluate if all per-mutations of a completion sequence are quality equivalent. We introduceda method to reduce and resolve conflicts in the sequence of completions.Considering that a model could require more than one completion to be in-tegrated, our approach can deal with chains of completion transformations.91. IntroductionWe formalise this problem and provide a solution based on a stepwise con-flict resolution. In the first step, the conflict domain is reduced based onthe structure of the underlying metamodel. In the next step, the qualityheuristics are applied to resolve the conflict.In addition, we introduce an initial set of completions, validated forthe Palladio Component Model [18], that allow to reuse expert knowledgeabout modelling of concurrency and serve as illustration of the applicationof completions. Each completion or combination of completions shouldincrease the prediction accuracy, i.e. reduce the deviation of prediction andobservation, to correspond better the reality. Therefore, the creation of acompletion is a challenge itself and requires detailed research of the mod-elled aspect and its validation by comparison to the measurements on a realsystem. The validation was performed in an end-to-end manner, by us-ing the PCM workbench extensions based on CHILIES introduced in thisthesis.To support completions, CHILIES are integrated in the Palladio Compo-nent Model (PCM) tools. The tool takes a complete PCM instance (i.e., asoftware architecture model including performance specifications) as inputand generates a new PCM instance by applying the completions defined andconfigured in the source model. Such refined models are prepared for fur-ther analyses of the performance, reliability, maintainability and cost prop-erties. Additionally, this thesis discusses the support for automated mea-surements and experiments to collect possible configuration options thatshould be included in the configuration model. These measurements andexperiments are done on real systems [77].Maintainability Metrics for Model Transformations Furthermore,we discuss the quality of the HOTs and completion transformations. Themaintainability of transformations is influenced by various characteristics- as with every programming language artifact. Code metrics are oftenused to estimate code maintainability. However, most of the established101.2. Scientific Contributionsmetrics do not apply to declarative transformation languages (such as QVTRelations) since they focus on imperative coding styles. Code metrics areone way to characterize the maintainability of programs. However, the vastmajority of these metrics focus on imperative coding styles and thus cannotbe reused as-is for transformations written in declarative languages.In this thesis, we propose a set of quality metrics to evaluate transforma-tions written in the declarative QVT Relations language. We evaluated thetransformations’ maintainability through this set of automated metrics formodel-to-model transformations. In the analysis, the classical parametrizedmodel transformations are compared to the generated transformations byHOTs.Statefull Model-Driven Software Performance Engineering In-tegrating rising variability of software systems in performance predictionmodels is crucial to allow the widespread industrial use of performanceprediction. One of such variabilities is the dependency of system perfor-mance on the context and history-dependent internal state of the system (orits components). The questions that rise for current prediction models are(i) how to include the state properties in a prediction model, and (ii) how tobalance the expressiveness and complexity of created models.Only a few performance prediction approaches deal with modellingstates in component-based systems. Currently, there is neither a consen-sus in the definition, nor in the method to include the state in predictionmodels. For these reasons, we have conducted a state-of-the-art survey ofexisting approaches addressing their expressiveness to model stateful com-ponents. Based on the results, we introduce a classification scheme andpresent the state-defining and state-dependent model parameters. We ex-tend the Palladio Component Model (PCM), a model-based performanceprediction approach, with state-modelling capabilities, and study the per-formance impact of modelled state.111. Introduction1.3. StructureAfter the introduction provided by this chapter, this thesis is structured ineight chapters:• Chapter 2 describes the foundations necessary for this thesis. Wediscuss the basic terms and gives a brief overview on the conceptsfrom the two main areas: Section 2.1 introduces the foundations ofMDSD and Section 2.2 the foundation of MDSPE domain.• Chapter 3 starts with a motivation and introduction of model com-pletions in general. We locate the model completion concepts in theMDSD and MDSPE domain. After, discussing the consequences ofmodel completions for the MDSD processes (e.g. MDA), we intro-duce an completion-based MDSPE process in Section 3.3. It pro-vides a running example and illustrates the completion-based MD-SPE process using this example. This chapter deals with the researchquestion Q1: How to include purpose-specific aspects to models inan automated but adaptable manner inheriting its standard mecha-nisms and facilities, including transformations and tools?• Chapter 4 introduces the CHILIES approach. We discuss the appli-cation of HOTs for different goals in Section 4.3. Furthermore, eachof the Sections 4.4, 4.5 and 4.6 gives, first, the specification of an oneHOT pattern in general and, second, the description of its implemen-tation in the context of performance completions. Furthermore, weintroduce the composition of these three patterns providing supportfor completions in the MDSPE process. The Chapter 4 presents thesolution to the research question Q2: How to support configuration-based variability in model transformations?• In Chapter 5 we apply model completions to the MDSPE approach’Palladio Component Model (PCM)’. At the beginning of this chap-ter (cf. Section 5.2.3), we discuss the reduction and resolution of121.3. Structureconflicts in the sequence of completion execution for the PCM meta-model. Later, we introduce an initial library of performance com-pletions for concurrency design patterns in Section 5.3. The chapterintroduces the results of the research question Q3: How to structurethe Completion Library to reduce possible conflicts in an applicationof multiple completions?• Chapter 6 continues to evaluate the proposed variability mechanismfor transformations. This chapter introduces a set of quality metricsthat can be used to evaluate the maintainability of transformations,especially their complexity, understandability, extendibility and ease-of-use. This chapter answers the research question Q4: How to anal-yse maintainability of relational transformations?• Chapter 7 shows on several case studies the validity of the contri-butions presented in this thesis. Two case studies in Section 7.2.1demonstrate that predictions made based on completed models re-flect the reality in an appropriate and accurate way. In addition,we present a case study based on the realistic Business ReportingScenario demonstrating the prediction accuracy in a composition ofcompletions. Moreover, we evaluate the method for the conflict res-olution in Section 7.2.2. Section 7.2.3 discusses the complexity andmaintainability of the HOTs and completion transformations usingquality metrics for transformations introduced in the previous chap-ter.• Chapter 8 discusses the current state-of-art in the related areas. Thediscussion includes work from the areas of model transformation en-gineering and platform completions for software performance engi-neering. In addition, we summarize and compare the related ap-proaches to the contributions introduced by this thesis and discussthe resulting deficiencies.131. Introduction• Chapter 9 concludes this thesis. We summarize the most importantcontributions presented in this thesis. Finally, we discuss the openquestions and future directions of our research.The additional contributions of this thesis are discussed in more detail inthe Appendix, where we also introduce further HOT patterns. Moreover,we give examples on the implementation of two completion transforma-tions, for the MOM and Procedure Call Connector completion. The mostimportant contribution presented in Appendix is the set of experiments andheuristics building a foundations for stateful SPE.Chapter 5: Completion LibraryChapter 1:IntroductionChapter 2:FoundationsChapter 8:Related WorkChapter 3:Model CompletionsChapter 4: Variability ManagementChapter 6: Transformation AnalysisChapter 7: ValidationChapter 9:ConclusionAppendix A:Further HOT PatternsAppendix B:Statefull SPE<><><>MDSD<>MDSDMDSDMDSDMDSPEMDSPEMDSPEFigure 1.1.: Chapter structure in this thesis.The dependencies among the chapters are illustrated in Figure 1.1. Theoptional chapters could be safely skipped, if the reader is familiar withthe basic MDSD and MDSPE concepts. The further chapters are dividedbetween the two context domains in this thesis, the MDSD and MDSPEdomain. The reader interested in the MDSD contributions could follow thereading plan marked by the MDSD tag, analogously for the MDSPE tag.142. FoundationsIn this chapter, we introduce the concepts and terms from the three differentresearch areas on which this thesis is built on (cf. Figure 2.1). Software Per-formance Engineering(SPE) supports developers to take the right decisionabout the developed software system to fulfil their performance require-ments. Performance prediction methods evaluate response time, through-put, and resource utilisation of the developed systems in early developmentphases. The application of SPE avoids cost, time and effort intensive re-designs of systems later. In this work, we focus on the SPE for component-based architectures (CB-SPE). In the component-based systems, the perfor-mance of a whole system is determined by the performance characteristicsof individual components and their composition. Components and com-positions are described by models specifying software system’s structureand properties. These models serve as basis for further generation of im-plementation skeletons (code), analysis models or simulation code. Thesedifferent generation scenarios are supported by Model-Driven Software De-velopment (MDSD). Because design decisions about the software systemscan easily change during the development, model transformations automatecreation of different model variants and avoid effort resulting from manualimplementation.We structured this chapter as depicted in Figure 2.1. First, Section 2.1introduces foundations of MDSD necessary to understand concepts pre-sented in this thesis. Second, Section 2.1.2.2 provides an overview of well-established Generative Programming, Model-Driven Architecture (MDA)and Software Product Line (SPL) concepts and related terms. Third, Sec-tion 2.2 discusses MDSPE methods for component-based architectures152. FoundationsCB-SPEFoundations:Performance Prediction for Component-based Systems (i.e. PCM)CBSE Development Process Contributions:Platform Completions Statefull CB-SPEMDSDContributions:Automated Model Completions for CBSEFoundations: Structured Completion LibraryModel-driven Software Initial set of Performance CompletionsPerformance Engineering for Concurrency Design Patterns(MDSPE) Related Work:Coupled Transformations and PlatformFoundations: Completions Related Work:Models and Metamodels Software Product Lines (SPL)Model Transformations Contributions: - Model-driven SPL- Feature-based Transformation Higher-Order Transformation - Aspect-oriented SPLApproaches Patterns and their composition Transformation VariabilitySPL for Transformations FrameworksQuality Metrics for TransformationsSPEFoundations:Software PerformanceCockpitFigure 2.1.: Research areas involved in this thesis.with special focus on approaches using model transformations to deriveperformance models. Finally, we provide an overview of the used SoftwarePerformance Cockpit in Section 2.2.4.2.1. Model-driven Software DevelopmentAbstraction plays a central role in Model-Driven Software Development(MDSD): it allows to separate the specification of a software system fromits implementation. The ultimate goal of the MDSD is to construct modelsof higher abstraction and to translate them stepwise into models of lowerabstraction until the implementation is generated. In doing so, the imple-mentation task (code writing) is replaced by modelling activities, such ascreating model instances, writing model transformations for different pur-162.1. Model-driven Software Developmentposes, or specifying other problem specific models. The following sec-tions introduce several concepts central to the MDSD. We discuss the mainMDSD artefacts in Section 2.1.1. The first subsection shows the defini-tions of basic terms like model and metamodel. The focus of the follow-ing section is on model transformation techniques including discussionson higher-order transformations. Special kinds of transformation method-ologies, such as generative programming and software product lines, playcentral role in later sections. Additionally, Section 2.1.2 discusses de-tails of MDSD generations and their relation to Model-Driven Architecture(MDA).2.1.1. Basic Artefacts of MDSDThe most effective way how to understand complex real-world problemsis to build a model. Models are abstractions of the real-world problemsor elements. Raising the level of abstraction helps effectively addressing aspecific purpose, such as answering a question about the system or influ-encing its behaviour. We can achieve this by ignoring certain details whilefocusing on the relevant ones. Models are the central artefact of Model-Driven Software Development (MDSD). MDSD is responsible for definingthe models. Moreover, MDSD is bridging the gap between these softwaremodels on a high-level of abstraction and program code, which containsimplementation details on a very low-level of abstraction. This gap is oftenvery large. MDSD technologies try to automate the process of lowering theabstraction levels. With MDSD, the ultimate aim of software engineers isto build models on a high-level of abstraction and translate them fully auto-matically into models of lower abstraction level (including program code).A key MDSD artefact to achieve this are model transformations. Modelsare transformed using model transformations in step-wise fashion, whereeach step lowers the level of abstraction.172. Foundations2.1.1.1. Model and MetamodelIn software engineering, models are used in many ways: to predict systemqualities, reason about system properties and their changes, and tradition-ally for communication between different software developers. Models canbe developed as a starting point to implement a system, or they can be de-rived from an existing implementation. Despite the importance of models,there is still no established definition. In the remainder of this thesis, wedefine model as follows (based on [150, 136]):Definition 1 Model"A formal representation of entities and relationships in the real world (ab-straction) with a certain correspondence (isomorphism) for a certain pur-pose (pragmatics)."Based on this definition, models have three main characteristics: abstrac-tion, isomorphism, and pragmatism. Models can be described as abstrac-tions of modelled objects, that allow engineers to reason about the objectignoring some details while focusing on relevant ones. The selection ofthe modelled details is guided by a purpose. The model represents the realworld object with certain level of correspondence, called isomorphism. Iso-morphism is a projection of considered attributes of real-world object ontothe attributes of its model, or in other words, there is certain equivalencebetween the model and the real world entity. Each model is created forsome purpose. This model pragmatism determines the level of abstractionand isomorphism. For example, we can create a software model for the pur-pose of behaviour protocol interoperability checks and another one for thepurpose of performance prediction. Both of the models will include entitiesdescribing used software components and their interfaces. But, because ofthe different aim of the model, the behaviour of the components will bemodelled with different level of detail. For the interoperability checks weneed to know exactly what is the functionality (behaviour protocols) pro-182.1. Model-driven Software Developmentvided by the component. Compared to the performance prediction model,is the first model very detailed model of a component behaviour. For thesecond purpose, it is enough to abstract the component behaviour to timeor resources needed to respond to an user request.A model is created conforming to one modelling language. A modellinglanguage is defined by its metamodel which specifies the ’grammar’ foreach model (or the ’word’). A metamodel defines constructs that can beused to build models and contains validity rules associated with this con-structs. Models conforming to a metamodel follow the structure defined bythe metamodel and do not violate its validity rules. Such models are calledinstances of metamodel. The modelling community around the websitemetamodel.com [117] defines metamodels as follows:Definition 2 Metamodel (metamodel.com: [117])"A metamodel is a precise definition of the constructs and rules needed forcreating semantic models."We understand a metamodel as a language that allows the formal rep-resentation (model) of entities and relationships in the real world on thecertain level of abstraction. In principle, each metamodel is again a modelcreated on a certain level of abstraction using constructs are described byanother meta-metamodel. Two metamodels, defining constructs that can beused to describe real world objects from the same domain, can have dif-ferent expressive power. The metamodel definition limits a level of detailallowed in conform model instances, that is influenced by the level of iso-morphism and abstraction of metamodel towards the native language. Forexample, two metamodels can provide constructs to describe a chair, thefirst allows to express that the chair has legs, second allows to describe howmany round or angled and polished or matt legs the chair has. We can saythat metamodel definition influences isomorphism and abstraction level of192. Foundationsmodel instances and therefore we extend the metamodel definition as fol-lows:Definition 3 Metamodel"A metamodel is a precise definition of the constructs and rules within acertain domain needed for creating semantic models on certain level of ab-straction."A metamodel is defined by:• Abstract syntax, which defines elements of models and the relationsbetween them. This definition is independent from actual representa-tion of these elements. For example, in programming languages, theabstract syntax is usually represented as an abstract syntax tree.• Static semantics, which describes properties of model elements andrelations by which the model can be validated. A common languageto express static semantics is OCL [127].• Dynamic semantics, which describes the intention of the model con-cepts, how to interpret valid model instances and meaning of theirelements. In most cases, it is written in prose.• Concrete syntax, which defines the representation of abstract con-cepts, e.g. an UML notation [124] or Java syntax. While metamodelsalways have exactly one abstract syntax, multiple concrete syntaxesare possible.Thus, metamodels define all information necessary to build a model. Forexample, the UML2 meta-model [124] defines the set of valid UML mod-els. It defines the elements available in an UML model and their connec-tions (syntax). Additionally, it contains the Object Constraint Language(OCL), which allows the definition of semantic constraints. Furthermore,each metamodel describes models from a certain problem domain. The202.1. Model-driven Software Developmentconstructs introduced by a metamodel belong to the same domain and allinstances of this metamodel describe objects from this domain using theallowed constructs. A metamodel is then understood as a specification lan-guage dedicated to a particular domain. We define domain as follows:Definition 4 Domain"A domain is a field of study that is defined by common requirements, usedmodelling constructs and rules."The Meta Object Facility (MOF) [126] is a meta-meta-model which isself describing and defines the constructs and rules necessary to specifymetamodels. Initially, was MOF used to model UML. Therefore, its coreconcepts are similar to those available in UML class diagrams, althoughthey are on different meta-levels and the described concepts are different.The MOF specification evolved to the "essential" MOF (EMOF). The re-sulting implementation based on this standard (used in this thesis) is theEclipse Modelling Framework (EMF) and its meta-meta-model ECORE(see Figure 2.2). Furthermore, the Object Constraint Language (OCL)[127] restricts valid MOF instances and expresses their static semantics.Figure 2.2.: The Ecore metamodel.212. Foundations2.1.1.2. TransformationsBecause many aspects of the modelled object might be of interest, modeldevelopers can use various modelling concepts and notations to highlightthe relevant details by the means of different views or representations. De-velopers use transformations to move between different representations, ab-straction levels or specialisations of models. Transformations can convertmodels from one abstraction level to another (usually a less abstract one)by adding more detail to the model. Transformations are the second majorconcept of MDSD.Insight into the topic of model transformations, explored techniques,most common languages, and current research papers is collected in a liter-ature study by Biehl [25]. According to his paper, typical usages of modeltransformations are synthesis, integration (tool integration or model merg-ing), analysis, simulation and optimization. He further proposes a clas-sification scheme for model transformation problems: change of abstrac-tion or not (vertical and horizontal transformation), change of metamodels(endogenous and exogenous transformation), translating between techno-logical spaces (such working contexts could be for example MOF, XML,DBML etc.), number of involved domains (in-place transformation if onlyone domain is involved), target types used (model or text), preservation ofcertain model properties (semantics, behaviour or syntax).The commonly used transformations are classified into two types: Model-To-Model (M2M) and Model-To-Text (M2T) transformations. Furthermore,transformations that take a number of instances of different metamodelsas input are called Y-transformations. If one of these inputs configures thetransformation itself, we call these Y-transformations mark transformations[11]. Another special type of transformations are in-place transformations,which use equal source and target metamodels. Additionally, these trans-formations operate on one model. Thus, the result of the transformation isdirectly stored in the model as used as input.222.1. Model-driven Software DevelopmentThe source and target of a M2M transformation are models. M2M trans-formations transform an instance of one metamodel into an instance of an-other metamodel. These metamodels are usually instances of the samemeta-metamodel and they can be equal. A transformation is defined bya set of transformation rules on a metamodel elements. Each rule definesits effect using the concepts from source (or input) and target (or output)metamodel. Thus, transformations are specific to the used metamodels.Transformation rules are specified in special languages and are interpretedby a transformation engine for execution. There is a wide range of differenttransformation engines available, supporting different approaches such asgraph-transformations, relational, operational or hybrid transformations.A special type of M2M transformations are such transformations wherethe target model of a transformation is an extension of the source model.Such transformations preserve large parts of the source model and addsadditional information. They are called refinement transformations [63]and are very similar to completion transformations.Graph-transformation approaches have the theoretical foundations ingraph grammars and as such are applied to models interpreted as graphsof objects. The principle of such transformations is based on mapping be-tween left-hand-side and right-hand-side patterns. When the sub-graph inthe input model matches the left-hand-side pattern the sub-graph is replacedin the output model by the right-hand-side pattern. This process is finishedwhen no further left-hand-side pattern can be matched. Similar principleis realised by relational approaches which specify transformation rules inform of formal relations between two domain patterns [45]. The relationaltransformation engine tests all available relations and updates the outputmodel to fulfil all the relations. The OMG Standard Query/View/Transfor-mation (QVT) [72] specifies a QVT Relational and QVT Core languages,both with relational semantics. In this thesis we use the QVT Relationaltransformation language to implement our transformations. Furthermore,the QVT standard introduces an operational language (QVT Operational),232. Foundationswhose main difference is the explicit definition of execution sequences bya main method from which all mapping operations are called. In con-trast, relational transformation languages only describe the relations be-tween input and output of a transformation in a relational (i.e., declarative)manner (non-determinism). Finally, hybrid approaches such as the AtlasTransformation Language (ATL) [90] combine relational and operationalapproaches.M2T transformations generate structured text (e.g., executable code)from their input models. These transformations can be visitor- or template-based. Using one of these approaches, M2T transformation engines createfor elements of the input model new code snippets.QVT Relational Transformation Language QVT Relational is partof the QVT standard [72] and describes model transformations in a declar-ative manner. This means the transformation itself is written as a set ofrelations that must be satisfied during the transformation process. As QVTRelational is multi-directional, there is no single source and target modelbut a list of so called candidate models. Each of these candidate models canbe chosen as a target of the transformation, identifying the execution direc-tion. When the transformation is invoked in a selected execution directiononly the target model is modified so that all relations hold.1 top relation ClassToTable {2 cn : Str ing ;3 pref ix : Str ing ;4 checkonly domain uml c : SimpleUML: : UmlClass {5 umlNamespace = p : SimpleUML: : UmlPackage {} ,6 umlKind = ’ Per s i s t en t ’ ,7 umlName = cn8 };9 enforce domain rdbms t : SimpleRDBMS: : RdbmsTable {10 rdbmsSchema = s : SimpleRDBMS: : RdbmsSchema { } ,11 rdbmsName = cn ,12 rdbmsColumn = cl : SimpleRDBMS: : RdbmsColumn {13 rdbmsName = cn + ’ _t id ’ ,14 rdbmsType = ’NUMBER’ } ,15 rdbmsKey = k : SimpleRDBMS: :RdbmsKey {242.1. Model-driven Software Development16 rdbmsColumn = cl : SimpleRDBMS: : RdbmsColumn{}}17 };18 when {19 PackageToSchema(p , s ) ;20 }21 where {22 ClassToPkey (c , k ) ;23 pref ix = cn ;24 AttributeToColumn (c , t , pref ix ) ;25 }26 }Listing 2.1: Example of QVT Relational.QVT Relational is part of the QVT standard [72] and describes modeltransformations in a declarative manner. This means the transformationitself is written as a set of relations that must be satisfied during the trans-formation process. As QVT Relational is multi-directional, there is no sin-gle source and target model but a list of so called candidate models. Eachof these candidate models can be chosen as a target of the transformation,identifying the execution direction. When the transformation is invoked ina selected execution direction only the target model is modified so that allrelations hold.An example QVT-R relation, which matches UML class (SimpleUML::UmlClass) to relational database table (SimpleRDBMS::RdbmsTable), isgiven in Listing 2.1. Before we map the class to table, we have to mapthe UML package to an RDBMS schema. Additionally, after the class ismapped to the table, we have to call the relation AttributeToColumn. Arelation has two or more domains, that are given as patterns on the candidatemodels. The pattern usually includes an object graph pattern, propertiesand associations between objects and defines a variable binding for eachpattern match. By using the same variables in different domain patterns,we can define the relation between candidate models. In consequence, thetarget model is modified for each found pattern binding not being fulfiledto the extent that the relation holds.252. FoundationsEach relation can be marked as top-level. This means that the relation hasto hold in any case for a successful transformation, while any non-top-levelrelation only has to be satisfied when directly or transitively referencedfrom a where clause. A top-level relation must hold for every possiblecombination of elements in the candidate models. The transformation en-gine starts with the execution of the top-level relations and continues withthe relations demanded by the pre- and post conditions of the top-level re-lations. Thus, non-top-level relations that are never demanded by otherrelations won’t be executed at all. A relation can have when and whereclauses that specify its pre- and post-conditions. A relation only has to besatisfied when all pre-condition relations contained in the when clause aresatisfied. In a similar manner, each relation contained in the where clausehas to be fulfiled when the relation containing the clause is fulfiled. Hence,the when and where clauses allow for the introduction of further constraintson the match patterns. Such constraint can be fulfilment of either a query,an OCL-Statement or another relation.Beyond that, a target domain can be marked as checkonly, i.e. the targetdomain model is only checked for consistency and not modified. Besidesthis, relations are marked as enforce by default, thus insisting on the appli-cation of model changes for relations that do not hold.To visualize QVT transformations the QVT specification defines a graph-ical representation for a relation. This should make it more intuitive to seeand understand a transformation. To make the diagrams more readable,when objects are typed, only the actual name of the type is written. Thecomplete package name would be very long in most cases. In Figure 2.3one can see the ClassToTable relation from the last example in graphicalnotation.Transformation diagrams are mainly based on standard UML class dia-grams. At some points they extend the class diagrams with new symbols.One new key symbol is the hexagon with the two arrows at the left and atthe right. On each limb you can find the name of the models involved in262.1. Model-driven Software Development<>c : UmlClassumlKind = ´Persistent´umlName = name<>t : RdbmsTablep : UmlPackageClassToTablecol : RdbmsColumnrdbmsSchema = srdbmsName = namek : RdbmsKeyC Euml : SimpleUML rdbms: SimpleRDBMSwhenPackageToSchema(p, s)ClassToPKey(c, k)whereFigure 2.3.: Graphical representation of a QVT relation.this relation and their corresponding metamodels. Below the arrow a "C"or "E" symbolizes if a model is only checked or if the relation is enforced.Domains or objects are pictured as rectangles, domain are labeled with thekeyword domain. This rest of the symbol is the same as in a class diagram.In the upper part of the rectangle there is the name of the object and itstype. In the lower part attributes or constraints that the object has to fulfilcan be specified. If an object contains other objects they are not writtenas attributes. They are pictured below in their own rectangle, and are con-nected to the containing element with a line. At the bottom of a relationoptional boxes for the when or the where clause can be attached.2.1.2. Evolution of model transformation processesThe crucial role of transformations for the MDSD is visible on the evolutionof transformation processes, which shows that only through extended usageof transformations it was possible for model-driven techniques to becomean integral part of software development. The evolution of model-driventechnologies and architectures can be summarized in three generations.272. Foundations2.1.2.1. First Generation of MDSD TechnologiesThis generation is the beginning of modelling, where programming abstrac-tions (e.g., packages, interfaces) are embedded in the code and provided ina form of, for example, programming libraries. A software architecturedesign exists only in the heads of developers. This situation is, however,inadequate for large, changing teams and for management of software evo-lution. Therefore, models were used as a mean to communicate ideas aboutan architecture. In the first generation, models are used in the role of pro-gram documentation or code visualization (e.g., UML class diagrams) butare difficult to maintain. However, they helped to increase software quality.These models are essentially diagrams, because of their low-level of ab-straction. These diagrams are tightly coupled with code and provide addi-tional means to view and edit at code level. In this generation, MDSD toolswere mostly graphical environments helping to draw diagrams. Some ofthe tools were capable of reverse-engineering code to diagrams, or of cre-ating code skeletons from class diagrams and other implementation-leveldiagrams (e.g. IBM Rational Software Architect).2.1.2.2. Second Generation of MDSD TechnologiesIn the second generation, the automation of forward engineering is the maingoal. This generation introduces standard and process guidelines under thename of Model-Driven Architecture (MDA) [125]. MDSD Tools made sig-nificant step to generate code comparable to hand-crafted implementation.Models include sufficient detail to enable the generation of an implementa-tion. Most of the model-to-code transformations are template-based, theyapply a series of templates on models and map them to code. Many toolsalso support round-trip engineering and allow synchronising models andimplementations during the software evolution. With the second genera-tion of MDSD technologies, the use of models in software developmentbecame much wider accepted. Models are an integral part of the software282.1. Model-driven Software Developmentengineering process. This led to the development of libraries of transfor-mations to accomplish several activities automatically, similar to the firstgeneration of documentation [167].Generative programming The idea of generative techniques has al-ready been applied in compiler construction where programs written in aprogramming language are transformed by compilers into executable code.The main difference is that compilers usually process a fixed set of pro-gramming languages and generate code for fixed amount of processors.Model-driven techniques allow to specify custom metamodels and trans-formations. Thus, on the model level, it is possible to have any number ofmetamodels and transformations.Czarnecki and Eisenecker [46] introduced generator options in their bookon Generative Programming which is a predecessor of today’s MDA para-digm. They used so called feature diagrams to capture different variants inthe possible output of code generators. Feature diagrams model all validcombinations of a set of features called (feature) configuration where a sin-gle feature stands for a certain option in the respective input domain. Theirwork is applied in area of product line engineering [109] especially for do-main modelling and domain variance analysis using feature diagrams.Legendorexclusive ormandatoryoptionalFeature DiagramMandatory FeatureOption 1 Option 2Optional FeatureFeature 1 Feature 2 Feature 3Figure 2.4.: Example of a feature diagram.Feature diagrams are used to formally capture variabilities of a targetdomain. Each feature represents an aspect of the target domain. The rela-tionships between features capture additional constraints limiting combina-292. Foundationstions of features. Some features may require other features as prerequisitesor be mutually exclusive with other features. An example of feature dia-gram is illustrated in Figure 2.4. An instance of feature diagram is called afeature configuration and represents choices of active features. Czarneckiand Eisenecker use feature diagrams to parametrise generators. In this the-sis, we use feature diagrams to parametrise model transformations. Simpleand intuitive structure of feature diagrams bears the advantage of havinga model for the possible transformation parameters which introduces theconfiguration options in terms easily understandable by software architectsand captures the variability in the transformation mapping in a focused way.Model-Driven Architecture Model-driven software development pro-cesses like the OMG’s Model-Driven Architecture (MDA) [125] leveragethe role of models in software development. In MDA, models serve as in-put for a series of transformations which at the end generate the system’simplementation. Each of these transformations maps models of higher ab-straction to models of lower abstraction. The system’s implementation rep-resents the lowest level of abstraction.According to the MDA process, the first model to create is an abstractmodel of the business domain, the computation independent model (CIM).Based on this model, developers create a model of the system under de-velopment without using any details of the technical platform. This modelis called platform independent model (PIM) (cf. Figure 2.5). Automaticmodel-2-model (M2M) transformations refine this model by adding imple-mentation details of particular platforms. The term platform is a broadconcept in this context. For example, it can define the type of the realisa-tion (database application, workflow management, etc.) or a specific imple-mentation of a technical concept like different industrial component models(.NET, CORBA, Java EE). Furthermore, a platform can refer to implemen-tation dependent details like different types of configuration files dependingon a particular middleware selection. A model which depends on such de-302.1. Model-driven Software Developmenttails is a platform specific model (PSM, cf. Figure 2.5) with respect to aparticular platform. The amount of additional platform-dependent infor-mation may vary depending on the purpose of transformation step. Thereare many such transformation steps possible, each adding certain aspects ofthe target platform.PIM PSM PSM’ CodeMark Model 1M2M M2M M2TMark Model 2 Mark Model 3Figure 2.5.: MDA models and transformations.In Figure 2.5, the refinement process is distributed among a number oftransformations forming a transformation chain. Each transformation takesthe output of the previous one and adds its own specific details. Whenrefining high-level concepts of transformations into concepts on lower ab-straction levels, different alternatives may be available. For example, ifdifferent applications communicate via messaging, different patterns forrealising the message channels can be used, e.g., with or without guaran-teed delivery. If developers want their transformations to be flexible, theycan parameterise them allowing transformation users to decide on mappingalternatives themselves. The OMG’s MDA standard allows transformationparametrisation by so called mark model instances.In MDA terminology, mark models are input models which tell trans-formations where, and how, platform-specific details should be added tocomputation-independent models. Mark models are models dedicated toreference entities of input models and to decorate these referenced enti-ties with a platform description model, usually specifying configurationoptions.Mark models allow users of transformations to decide on mapping vari-ations themselves by choosing from different options. Thus, mark modelsencapsulate different variants of target models. Depending on the mark312. Foundationsmodel, the transformation generates the result model. For example, a trans-formation from UML classes to database tables can depend on a configu-ration of a mark model to generate different types of tables. Using UMLstereotypes, we can create marks on the transformed elements. The stereo-types relational or object will result in different type of ta-bles being generated.In their book, Völter and Stahl [167] consider MDA application to beimpractical, especially because of missing tool support. However, the workof Becker [11] demonstrates that parametrisation of transformations canbe applied successfully. The biggest disadvantage of mark models andtransformations parametrised by mark models is the maintainability andvery hard extendibility of such approach. To provide necessary flexibil-ity the transformation developer has to foresee all possible options in markmodel and parametrise the transformation accordingly (implement a struc-ture similar switch statement from JAVA). Moreover, when new feature isintroduced transformation has to be adapted. We demonstrate in this thesistransformation parametrisation approach which does not require transfor-mation adaptations and we compare our approach to the concept of markmodels.Software Product Lines If there are commonalities between softwaresystems, developers implement the same functionality multiple times indifferent projects. Software Product Lines (SPLs) [37] standardise suchcommonalities using domain models to capture the core concepts. SPLspromote planned asset reuse, automation, and composition of large prod-ucts from smaller parts. The reusable parts are called features in SPL ter-minology. Each feature represents an increment in functionality. The im-plementation of a feature extends then the core software system in one ormore places.The development process of an SPL consists of two phases: domain andsoftware engineering. The goal of the domain engineering phase is to de-322.1. Model-driven Software Developmentscribe and develop the common and variable parts. During the softwareengineering phase, these parts are assembled to build the final product.SPLs can be implemented using a compositional and annotative approach[37]. In the compositional approach, developers implement each featureas independent module. These modules are then composed at compile- ordeployment-time. For the annotative approach, they implement featureswith some form of annotations of the core common part (or source code).Which is very similar to the #ifdef and #endif statements that surroundfeature code of C/C++ preprocessors. These two approaches are the basicconcepts of SPLs. More advanced approaches using generative, model-driven or aspect-oriented techniques to support SPLs fall in one of thesecategories. Our approach is compositional (from a transformation genera-tion point of view) and annotative (from a application model point of view).2.1.2.3. Third Generation of MDSD TechnologiesIn the third generation of MDSD technologies, transformations are subjectof manipulation as well. This is summarized by the statement of Bézivin atal. [23]: "In MDSD, everything is a model". Every artefact of the MDSDprocess can be interpreted (manually or automatically) as a model. Modelsand transformations are still a central part of the software development pro-cess. Furthermore, they start to become an integral part of the developedsystem as first-class elements of the runtime architecture. As part of the de-veloped system, transformations can be themselves generated and handledby model-driven development, like traditional programs. A wide set of ap-plications for such technologies appeared involving transformations in theroles of both manipulation program and manipulated object. Transforma-tions are taking on different tasks in the development process, besides codegeneration and documentation. Transformations can, for example, evalu-ate code quality or generate test cases. A fourth generation of MDSD mayinvolve transformations that take over program logic at runtime.332. FoundationsThe concepts introduced in this thesis contribute to the processes of thethird MDSD generation. In the following, we discuss the main tool to real-ize our goal, higher-order model transformations.Higher-Order Transformations Transformations are very complex asthey can form transformation chains, be highly configurable or require addi-tional inputs. A shift of knowledge is observable, as more and more logic isimplemented in transformations rather than platform-dependent code. Withlarger projects, developers not only have to face larger models, but alsotransformations of higher complexity. Transformations can be representedby a transformation models conforming to a transformation metamodel.However, not all frameworks provide transformation metamodels. In thiswork, we refer to the Medini QVT framework [88] which contains an im-plementation of QVT Relational transformation language. While in mostlanguages, Higher-Order Rules are not supported as first class entities (rulescannot be declared through expressions) in some languages, like ATL andQVT, transformations are able to operate on transformations, which are rep-resented as models. As such, transformations can be manipulated equallyas any other model. Transformations can be created, modified or analysedby transformations. The ability to treat transformations as subjects of othertransformations allows to fully exploit the power of transformation concept,abstraction levels and complex model-driven structures.Transformations that operate on transformations are called Higher-OrderTransformations (HOTs). Tisi et al. [158] understand a HOT as a modeltransformation such that its input and/or output models are again transfor-mations. In their work, Tisi et al. describe a typical schema of HOTs, whichconsists of three operations:1. Transformation injection: The textual representation of the transfor-mation rules is read and translated into a model representation con-forming to the transformation metamodel.342.2. Model-driven Software Performance Engineering2. Higher-order transformation: The transformation model is the in-put of a model transformation that produces another transformationmodel. The input, output and HOT transformation models are allinstances of the same metamodel.3. Transformation extraction: The serialization of the output transfor-mation model back to a textual transformation specification is per-formed.In our work, the transformation injection (reading of textual syntax orparsing) and extraction (model-to-text transformation or so called pretty-printer) are not considered as a part of a HOT. These steps are only ex-plicitly necessary when the framework does not provide support for them.Note, that in our case, the framework provides injection itself. However,since it does not provide extraction, we developed a pretty-printer as a laststep before executing a generated transformation. We consider the transfor-mation extraction as technical detail.2.2. Model-driven Software Performance EngineeringDuring the last years, many approaches dealing with performance pre-diction and measurement have been introduced [6, 98]. In the area ofComponent-Based Software Engineering (CBSE), systems are build out ofreusable black-box components (implementing sets of services) intercon-nected to a component architecture. The modelling of the system is done ata high level of abstraction. One idea behind CBSE is to increase componentre-use. Specialised component performance prediction and measurementapproaches introduce modelling languages with the aim to understand theperformance (i.e. response time, throughput, resource utilisation) of a fullarchitecture based on code-specific performance properties of individualcomponents.It is generally accepted that performance is a pervasive quality of soft-ware systems. Everything affects it, from the software itself to all under-352. Foundationslying layers, such as operating system, middleware, hardware, communi-cation networks, etc. [172]. The factors influencing the performance of asoftware component are difficult to analyse because they depend not onlyon the component implementation, but also on its usage, deployment andenvironmental context of the component (see figure 2.6), and occur at dif-ferent stages of component and system life cycle. A design-time perfor-mance prediction requires plenty of details about all influencing factors tobe sufficiently accurate [172, 76]. The approach introduced in this thesisis a contribution to ease development of accurate performance models ofcomponent-based architectures.Component ImplementationInternal StateRequiredServicesDeployment Platform ( Resource Contention )Usage ProfileFigure 2.6.: Performance-influencing factors.In the following sections, we describe the CBSE development processand involved development roles (see Section 2.2.1). We extend this devel-opment process in Section 3.3. Section 2.2.2 describes the Palladio Com-ponent Model (PCM), which is used in this thesis to express performancemodels and predict quality properties of component-based architectures(especially performance). The initial approaches for platform completionsare summarized in Section 2.2.3. These approaches were inspiration for thefirst idea of model completions as introduced in this thesis. Finally, Section2.2.4 presents basics of the Software Performance Cockpit (SoPeCo) usedto calibrate PCM models.362.2. Model-driven Software Performance Engineering2.2.1. CBSE Development ProcessIn the following, we give some details on CBSE development process andthe participating roles [102]. The presented development process is basedon the specification by Cheesman and Daniels [31]. They introduced a pro-cess consisting of following steps: (1) Requirements analysis, producinga business concept model and use cases; (2) Specification, describing theoverall architecture, business interfaces and components with their inter-faces; (3) Provisioning, creating component implementations or purchasingcomponents matching specification from third parties; (4) Assembly, creat-ing deployable application by wiring components according to the architec-ture description; (5) Test, testing application according to use case models;and (6) Deployment, installing application in its target environment.The division of work targeted by CBSE is enforced by structuring themodelling task to four independent languages reflecting the responsibilitiesof the four different developer roles (cf. Figure 2.7). We can we distin-guish following types of developer roles involved in producing artefacts ofa software system:• Component developers are responsible for the specification of com-ponents, interfaces, and data types. They implement and describecomponents and their behaviour in abstract, parametrised way. Com-ponents are generally specified via provided (implement services bycomponent) and required (used services by component) interfaces,which describe the contract between a client requiring a service anda server providing the service. Interfaces consist of a list of signa-tures specifying services, which is very similar to the Corba InterfaceDefinition Language (IDL) [129].• Software architects compose the component specifications into an ar-chitectural model. They create assembly connectors, which connectrequired interfaces of components to compatible provided interfaces372. Foundationsof other components. They usually do not deal with component in-ternals, but instead fully rely on the specifications supplied by thecomponent developers. Furthermore, software architects define thesystem boundaries and expose some of the provided interfaces to beaccessible by users.• System deployers model the resource environment (e.g., CPUs, net-work links) and allocate the components in the architectural model tothe resources. Resources have different attributes, such as processingrates or scheduling policies.• Finally, domain experts are familiar with the customers or users ofthe system. They specify the system-level usage model describingcritical usage scenarios as well as typical parameter values.Figure 2.7.: Roles in CBSE development process [19].The complete system model is then composed from these partial mod-els specified by each developer role. The field of study targeted by thisthesis is defined by domain-specific languages for component-based archi-382.2. Model-driven Software Performance Engineeringtectures (e.g. Palladio Component Model) that is composed of specific sub-domains mapping described development roles. The specific enhancingattributes of modelled architectures are described by orthogonal technicalsub-domains. We are interested in the technical sub-domains of particularquality attributes, especially performance. Therefore, in the following wewill describe specifics of PCM with focus on performance.2.2.2. Palladio Component Model (PCM)In the following, we introduce the technologies and architectural languagesfor specifying software architectures and their extra-functional properties.We apply our approach in the domain of performance engineering. For thispurpose, we use a performance prediction approach called Palladio Com-ponent Model (PCM) [135, 100, 18]. The PCM is a modelling languagespecifically designed for performance prediction of component-based sys-tems, with an automatic transformation into a discrete-event simulation ofgeneralised queuing networks. Its available tool support (PCM Bench) al-lows performance engineers to predict various performance metrics, includ-ing the response time, throughput and resource utilization. All three prop-erties are reported as random variables with probability distribution overpossible values together with their likelihood. The response time is ex-pressed in given time units (e.g., seconds), throughput in number of servicecalls or data amount per time unit (e.g., kilobytes per second), and resourceutilization in the number of jobs currently occupying the resource.Figure 2.8 illustrates a system model with performance annotations inPCM. It consists of four models created by four developer roles in a para-metric way, which allows the models to be updated independently of eachother. Component developers specify the behaviour and performance prop-erties of components, software architects combine components into com-ponent assembly with defined system interfaces, system deployers defineexecution environment and allocation of software components to system392. FoundationsFigure 2.8.: Illustration of a PCM model.resources, and domain experts specify the scenarios of system usage thatdrives system execution. Thanks to the responsibility separation, roles re-sponsible for the models of the architecture elements can be easily identi-fied in a PCM model.Software components are the core entities of the PCM. Each componentprovides and requires services defined by its interfaces. For each providedservice, an abstract behavioural specification called Resource Demanding-Service Effect Specification (RD-SEFF) is created. RD-SEFFs model theusage of required services by a component (i.e., external calls), and the con-sumption of resources during component-internal processing (i.e., internalactions). This description has the form of an annotated control flow graph.Basic components can be composed to composite components, which addhierarchy to the component models. Basic and composite components as-sembled to form a system by binding required interfaces of one componentto the provided interface of another component. These bindings are speci-fied by assembly connectors. Interfaces are first class entities in the PCM,consist of multiple service signatures, and follow the CORBA IDL syntax.Component specifications in the PCM are parametrised for their later en-vironment. Component developers can annotate external calls as well ascontrol flow constructs with parameter dependencies. These dependenciescover influences of required services, different soft- and hardware envi-402.2. Model-driven Software Performance Engineeringronments, as well as different input parameters of provided services. Thisallows the model to be adjusted for different system-level usage profiles.Parameter values can be of different type (e.g., string, int, real, composite)and can be characterised with random values to express the uncertainty.Similar to UML activities, RD-SEFFs consist of three types of actions:Internal actions, external service calls, and control flow nodes.Internal actions model resource demands and abstract from computa-tions performed inside a component. For performance prediction, compo-nent developers need to specify demands of internal actions to resources,like CPUs or hard disks. Demands can depend on parameters passed to aservice or return values of external service calls.External service calls represent invocations by a component of the ser-vices of other components. For each external service call, component de-velopers can specify performance-relevant information about the service’sparameters. For example, the size of a collection passed to a service can sig-nificantly influences its execution time, while the actual values have onlylittle effect. Modelling only the size of the collection keeps the specificationunderstandable and the model analysable. Apart from input parameters, thePCM also deals with return values of external service calls. Note that ex-ternal service calls are always synchronous in the PCM, i.e., the executionis blocked until a call returns. This is necessary to consider the effect ofreturn values on performance. A combination of external service calls andfork actions (that allow the parallel execution) can introduce asynchronouscommunication into the model. However, such models are too complex andrequire high development effort. In such scenarios model-driven technolo-gies can increase effectiveness of development.Control flow elements allow component developers to specify branches,loops, and forks of the control flow.Branches represent “exclusive or” splits of the control flow, where onlyone of the alternatives can be taken. In the PCM, the choice can either beprobabilistic or determined by a guard. In the first case, each alternative412. Foundationshas an associated probability giving the likelihood of its execution. In thelatter case, boolean expressions on the service’s input parameters guardeach alternative. With a stochastic specification of the input parameters,the guards are evaluated to probabilities.Loops model the repetitive execution of a part of the control flow. Aprobability mass function specifies the number of loop iterations. For ex-ample, a loop might execute 5 times with a probability of 0.7 and 10 timeswith a probability of 0.3. The number of loop iterations can depend on theservice’s input parameters.Forks split the control flow into multiple concurrently executing threads.The control flow of each thread is modelled by a so-called forked behaviour.The main control flow only waits for forked behaviours that are marked assynchronised. Its execution continues as soon as all synchronised forkedbehaviours finished their execution. The asynchronous fork action spawnsa new thread and immediately continues the execution of the main controlflow. This models an asynchronous service call in the PCM.In the PCM, parameter characterisations [100] abstractly specify inputand output parameters of component services with a focus on performance-relevant aspects. For example, the PCM allows to define the VALUE, BY-TESIZE, NUMBER_OF_ELEMENTS, or TYPE of a parameter. The character-isations can be stochastic, e.g., the byte size of a data container can bespecified by a probability mass function:data.BYTESIZE = IntPMF[(1000;0.8) (2000;0.2)]where IntPMF is a probability mass function over the domain of integers.The example specifies that data has a size of 1000 bytes with probability0.8 and a size of 2000 with probability 0.2.Stochastic expressions model data flow based on parameter characterisa-tions. For example, the stochastic expressionresult.BYTESIZE = data.BYTESIZE * 0.6422.2. Model-driven Software Performance Engineeringspecifies that a compression algorithm reduces the size of data to 60%.Stochastic expressions support arithmetic operations (∗,−,+,/,...) as wellas logical operations for boolean expressions (==,>,<,AND,OR,...) on ran-dom variables.Finally, resource containers model the hardware environment in thePCM. They represent nodes, e.g., servers or client computers, on whichcomponents can be allocated. They provide a set of processing resources,such as CPUs and hard disks, that can be used by the hosted components.Processing resources can employ scheduling disciplines such as processorsharing or first-come-first-served.Valid PCM models are input, for example, for a model-to-text transfor-mation that maps the architectural model into a discrete-event simulationor other analysis. The PCM could be used to predicts various performancemetrics and it supports further analysis of design decisions or trade-offanalysis, using automated optimisation approach PerOpteryx [96], whichcan be used to improve the architecture considering even multiple qualityattributes.2.2.3. Platform CompletionsWhen doing performance predictions in early development stages, the soft-ware model has to be kept on a high level of abstraction. Moreover, duringearly development stages, most implementation details are not yet known.By contrast, detailed information on the system is necessary to determinethe performance of the modelled architecture correctly. The complexityand the specific knowledge about the implementation required to create thenecessary models would dramatically increase the modelling effort. Thecomplexity of such models reduces the variability of the design modelsand, thus, increase the effort to evaluate and compare design alternatives.However, detailed information about the system is necessary to determinethe performance of the modelled architecture correctly.432. FoundationsSoftware ArchitectureAnnotationModelCompletion LibraryExtendedSoftware Architecture<><><>Figure 2.9.: Transformation integrating performance completions.Performance completions, as envisioned by Woodside [173, 174], areone possibility to close this gap. They are components added to the pre-diction model that add performance-relevant details to a performance pre-diction model, but which are not of interest when designing the system’sapplication logic. For example, details about the design patterns or plat-form are not included within the design model and therefore should beadded by completions. These performance completions extend the soft-ware model with annotations (or rules) whose extensions (such as addi-tional components, execution environments, or communication design pat-terns) are added to the original software architecture.Figure 2.9 shows how performance completions can be realized using theMDA concepts. Elements of a software architecture model, such as compo-nents or connectors, are annotated by elements of a mark model using, forexample, feature diagrams. Mark models annotate elements in the archi-tecture which are to be completed and provide the necessary configurationoptions. For example, if a connector is to be replaced by message-passingthe mark model can provide information about the type of the messagingchannel, e.g., using guaranteed delivery. Model-to-model transformationstake the necessary components from the completion library, adjust them tothe configuration, and insert them in the software architecture predictionmodel. The result of the transformation is an architecture model whoseannotated elements have been expanded to its detailed performance speci-fications. This step of model completion has to be automated.442.2. Model-driven Software Performance Engineering2.2.4. Software Performance CockpitThe Software Performance Cockpit is an extensible framework to ease, sys-temize and automate the tasks required to evaluate a software-system’s per-formance. A performance analyst simply specifies the desired measurementscenario and the Software Performance Cockpit then runs these measure-ments automatically using automated orchestration of analysed software.It enables experts of different aspects of performance evaluation (i.e. set-ting up the test-environment, measure data, analyse data, and export per-formance models) to model their requirements at one single point of con-figuration. When started, the framework executes a series of performance-tests, collects measurement data, analyses the collected data, and exportsanalysed functional dependencies as performance-models. Expert roles il-lustrating the Software Performance Cockpit approach, are:• Software Experts provide domain-specific knowledge for the soft-ware used in the evaluation-process (based on a GQM plan). Foreach software, they know its requirements, its functionality and itsconfigurable and measurable parameters. They additionally provideknowledge about how to use the software. They specify how it mustbe configured and how it can be controlled.• System Administrators set up the test-environment and deploy thesoftware required for the system under test’s performance-evaluation.• Performance Analysts are experts in the process of performance-evaluation. They determine strategies to efficiently configure a seriesof experiments in such a way as to gain meaningful measurement-data within as few experiments as possible. Once the measured datahas been analysed, Performance Analysts know how to interpret andpresent the analysis-results with respect to the tested system’s perfor-mance.452. Foundations• Analysis Experts provide knowledge in the area of data-analysis.They specify the algorithms to calculate possible dependencies be-tween the system’s parameter-configuration and its performance.In this thesis, we use this approach to calibrate performance models,hence, the performance evaluation requires a large effort to set up systemsand knowledge required to conduct performance evaluations is in manycases very system specific. We ease the process of completion develop-ment by utilisation of automated performance evaluation methods.The Goal/Question/Metric Approach: When measurements are tobe conducted in order to evaluate the performance of a system, they mustfollow a certain strategy to minimize the required number of performed ex-periments and to provide meaningful results. Goal/Question/Metric (GQM)was introduced by Basili et al. [7] as an approach to allow systematic mea-surements. They emphasise the importance of measurements to be goal-oriented in order to be efficient.Figure 2.10.: Hierarchy of a GQM-Model [7].462.2. Model-driven Software Performance Engineeringlike testing or programming), or resources (e.g. hardware-resourcesor personnel)• The second level is considered as the operational level. A set ofQuestions is defined to refine the goals and to qualify the objectsof measurement with respect to a certain issue of quality.• On the - qualitative - third level, Metrics are specified to allow aquantitative way of answering the questions. Metrics are consideredto either be objective or subjective. Objective metrics are indepen-dent from the Goals’ viewpoint (e.g. LOC of a .class file), wheresubjective metrics do depend on the goal’s viewpoint (e.g. the read-ability of a text).The structure of a GQM-plan is shown in Figure 2.10. In order to achievea Goal, it is associated to a set of Questions. Each Question itself is associ-ated to a set of Metrics. As the graphic shows, a Question does not have tobe associated to every specified Metric; however, one Metric can be associ-ated to multiple Questions. The relations between Goals and Questions areanalogue. With respect to the approach’s goal-orientation, building a GQM-model follows a top-down fashion. The interpretation of measurement-datais done in the opposite direction.47A GQM-instance is a hierarchically structured model consisting of threelevels:• On the - conceptional - first level, a set of Goals is defined. Goalsare specified in a certain context, which is determined by an issue,a purpose, an object to measure, and the viewpoint from which thegoal is defined. The objects of measurement can be products (e.g.documents or programs), processes (i.e. software-related processes3. Model CompletionsIn the previous chapter, we summarized the foundations of this work. Thesefoundations are the starting point we build on to support completions ofmodels in the Model-Driven Software Performance Engineering (MDSPE).The leading challenge this chapter is dealing with is: How to includepurpose-specific aspects to models in an automated but adaptable man-ner inheriting its standard mechanisms and facilities, including transfor-mations and tools?With this objective, we have to consider the well known conflict be-tween automation and adaptability of systems [172]. The systems whichare highly automated are difficult to change, and vice versa. We introducea solution based on an automated and configurable model completions. Weembed completions to the classical Model-Driven Software Development(MDSD) process and discuss their relationship to the well-known model re-finement principle. The following sections describe the particular conceptsneeded for model completions and apply automated completions to enhancethe MDSPE. We illustrate the creation process of completion and its usageon the running example. To automate completions we build on advancedmodel-driven techniques, such as Higher-Order Transformations (HOTs),which in our approach adapt transformations realising completions. Thenwe introduce the realisation of completions using HOTs in Chapter 4. Go-ing on with the running example, we incrementally build a first completion,which is also part of a completion library, introduced in Chapter 5.The remainder of this chapter will be organized as follows. Section 3.1introduces the main contribution of this chapter: the generalised ModelCompletion concept covering the integration of purpose-specific aspects493. Model Completionsas a part of the MDSD processes. As we introduce Model Completionconcept, we discuss and complete the view on the MDSD processes andtheir applications. Moreover, in the section 3.2 we discuss completion-based extension of the MDSPE process for component-based architectures.This section is followed by a description of completion-based developmentprocess for component-based models for MDSPE.3.1. Model Completions and MDSDIn model-driven software development (MDSD), we can distinguish twodirections of software development. First - vertical direction, the modelsof systems are built on different levels of abstraction. Abstraction involvesthe extraction of system properties according to some purpose. Thus, ab-straction filters and reduces the initial amount of information that is notneeded with respect to the model purpose. Refinement is the inverse op-eration to abstraction ([46], page 734). Refinement adds more details toabstract models, for example towards the implementation.Second - horizontal direction, which is specializing general models to-wards a more domain-specific model (e.g., software architecture modelfor performance prediction) by adding more domain-specific details to themodel. A typical example for specialization is adding concrete values toparametrized model elements. Every model is created with a specific pur-pose in mind. Typically, one writes a model to either document an existingsystem, specify a system to be implemented, analyse quality properties ofthe system, execute simulations or to provide predictions. The purpose ofthe model determines the domain to specialize for. With the purpose ofquality prediction, the domain we have to orient on is a domain of the par-ticular quality attribute (e.g., performance or reliability). Within the processof purpose model specialization, domain specific aspects of the model haveto be included.503.1. Model Completions and MDSDBecause models are often abstract and general at the same time, special-ization and refinement might be combined. Typically, specialization andrefinement activities are realized by domain experts manually. In this the-sis, we use model transformations to refine and specialise models. For eachmodel these transformations could be executed on the way to the purpose-specific model either in horizontal (specialization) or in vertical (refine-ment) manner (cf. Figure 3.1). A related concept was introduced in [137].These orthogonal software development activities, as described above,are basic building blocks of MDSD. Both types of activities are in thisthesis understood as series of transformations with a goal to automate asmuch of them as possible. The transformations executed in a direction ofmore concrete model, so called vertical transformations ([46], page 335),represent software implementation. The transformations executed on thesame abstraction level, so called horizontal transformations ([46], page335), represent purpose-specific completion of models. In this thesis, wefocus on the horizontal direction. An example of vertical transformation isthe model-to-text transformation in the ProtoCom Project, transforming aPCM model to a Java Prototype [15]. An example of horizontal transforma-tion is the model-to-model transformation adding performance annotationsto a general model.Using these basic building blocks, we can build more complex MDSDprocesses. The vertical direction of development (left hand side of Fig-ure 3.2) is best illustrated by well-known levels of Model-Driven Archi-tecture (MDA), which builds on the chain of refinements starting fromrequirements on a software product and targeting implementation of a fi-nal software product. First, MDA refines the requirements model towardsComputation-Independent Model (CIM), then from CIM to a Platform-Independent Model (PIM) and further to a Platform-Specific Model (PSM).These levels define software implementation process. Finally, the last re-finement step maps the PSM to an implementation (code), model-driventests and to a deployment of the final software product [134]. In MDA, the513. Model CompletionsAbsConcAbs‘RefinementSpecializationHorizontal transformationVertical transformationGeneralizationAbstractionFigure 3.1.: Transformations in the Model-Driven Software Development(MDSD)[46].chain of transformations is executed completely from the top-level (CIM)to the bottom (Code). Whenever the requirements change, only the top-level model is adjusted and all subsequent models and artefacts are newlygenerated. In the theory (cf. Figure 3.2), we design an abstract model Absthat captures requirements on the system and we refine it to a more concretemodels until implementation Conc. However, there are aspects of the realworld activities that conflict with the idea of step-wise model refinementtowards implementation.In the contrary to the theory, model development is an incremental pro-cess in practice (right hand side of Figure 3.2). Since requirements on thesystem are evolving over time or new requirements are introduced, newpurpose-specific aspects need to be included in different purpose-specificmodels. For different purpose different purpose-specific models on thesame abstraction level are created. Orthogonally to the refinement, thedevelopers introduce horizontal activities to perform refactorings, to exe-cute migrations, to apply domain-specific optimizations, and to weave newpurpose-specific aspects into the model. Today, developers must rely ontheir instinct and experience to decide how detailed models are needed.They perform manual adjustments of their models to fit required purpose.523.1. Model Completions and MDSDThis ad-hoc model development may result in models that are either tooabstract or too detailed for their purpose. Consequently, the models growmore complex because of the mix of low-level details and high-level ab-stractions. Often metamodels do not have enough expressive power to al-low modelling of required aspects directly and new metamodel elementshave to be introduced. When the metamodel changes, the chain of verticalrefinements is not reusable or, in contrary, when the metamodel is fixed,the domain-specific development decisions towards model purpose couldbe limited. In the first case, the vertical transformations realizing the refine-ment chain need to be adapted after each metamodel change. Furthermore,with growing complexity of metamodels more and more development ef-fort is needed to adapt existing transformations. Therefore, any change ofmetamodel is expensive and developers try to avoid it through introducingmodel "hacks" and manual designing of very complex models. The effortto avoid metamodel extension often leads to lost of traceability in designdecisions, poorly understandable and maintainable models.AbsConcAbs‘refinementAbsConcrefinementTheory Real Worldrequirements requirements[CIM][PIM][PSM][Code]new req.Figure 3.2.: Software development using MDSD.In any case, it is hard to follow the relationship of created abstract model(Abs) to the desired specialised model (Abs′, Figure 3.2). Having a de-tailed look on the (typically manual) activities developers realize towards533. Model Completionspurpose-specific model (Abs′) shows that models specialized for certainpurpose are obtained by specializing general abstractions that were de-signed to be used in more than one domain. For example, a general con-nector abstraction is specialized as remote procedure call connector, furtherspecialising steps could be adding middleware abstraction and identifyingplatform dependency (using .Net or J2EE middleware). Such specializedmodel is needed to solve particular problem, e.g. predicting performancecharacteristics of a system using modelled connector.We had a closer look at such processes (right hand side of Figure 3.2)in development of PCM models and we can distinguish independent andfocused development activities towards an abstract model (Abs′). The re-sulting model, Abs′, is specified to the necessary detail and specialized fora particular problem domain. Such model is typically created manually.The goal of this thesis is to provide structured and automated approach tosupport developers to create purpose-specific models. We implement theseactivities as the vertical transformations resulting in the purpose-specificmodel. These purpose-specific transformations are called completion trans-formations. Completions increase the specialisation of the model to therequired level. Additionally, the completions open a way to decrease devel-opment effort through automation and manageability of model complexity.Moreover, development effort is decreased by reusable nature of comple-tions. The complexity of models is encapsulated in and hidden by abstractdefinition of completions. In the following sections, we discuss purpose-specific completions and related scientific challenges.3.1.1. Model Completion ConceptWe understand purpose-specific model as a model on a such level of spe-cialisation that it includes enough detailed information to serve its purpose.For example, a performance prediction model should include performance-relevant details of a middleware platform to provide accurate predictions.543.1. Model Completions and MDSDThe goal is to arrive at the sweet-point, where the model is as abstract aspossible and as specialized as necessary. We define the suitability of themodel to fulfil its purpose by the level of model completeness. One modelcan target more than one purpose. For each model purpose different levelof model completeness can be necessary.Definition 5 CompletenessModel completeness is a quality criterion for models specified by the par-ticular level of detail and correspondence to the modelled entity. Moreover,the level of detail and correspondence are highly dependent on intendedpurpose of the model.Initially, it is not possible to quantify model completeness, because it isa purpose-specific quality. The completeness of the model can be evaluatedonly in the context of the model purpose and its application domain. Con-sidering models for performance prediction, the prediction accuracy canbe used as a metric to evaluate model completeness. The model providingmore accurate prediction is in MDSPE domain considered as more com-plete as a model resulting in less accurate predictions. Dependent on theapplication domain the completeness metric changes. For example, modelsused as documentation could be evaluated based on their understandability,or models used for code generation could be evaluated based on the addi-tional development effort after code generation needed towards executablecode. In this thesis, we discuss the completeness of performance predictionmodels, therefore, we adapt the definition of completeness for the domainof performance prediction.Definition 6 Completeness of Performance Prediction ModelsModel completeness is a quality criterion for performance prediction mod-els specified by the particular level of implementation detail and correspon-dence to the real software system. Moreover, the level of detail and corre-spondence determine the accuracy of the performance prediction.553. Model CompletionsAs mentioned before, the model-driven software development consistsof a number of activities, some of vertical (towards implementation), somehorizontal (improvement of completeness) nature. For simplicity, let us as-sume that vertical activities decrease/increase the level of abstraction, butthat horizontal maintain the level of abstraction, being concerned mostlywith activities such as weaving new purpose-specific aspects into the model.The motivation to maintain the level of abstraction is twofold: (i) sep-aration of concerns: to maintain the models in the responsibility of thesame development role on the same abstract level and develop complexdomain-specific completions in isolation by a special development role onthe level of lower abstraction; and (ii) maintainability: to avoid adapta-tions of transformations resulting from metamodel extensions to by able tomodel domain-specific aspects.We can extract a pattern in these development activities, with implemen-tation activities going vertically and purpose-specific completion going hor-izontally, as illustrated on Figure 3.3. This incremental pattern is a typicalscenario for application of model completions. In this structure the modelAbs′′ is considered as the most complete one. Considering this pattern,when the purpose of model creation was, for example, performance pre-diction the Abs′′ on Figure 3.3 would provide the most accurate predictionsand the Conc′′ would be closest to real implementation.AbsConcAbs‘ Abs‘‘Conc‘ Conc‘‘completionrefinementMetamodelconforms totransformationLegendFigure 3.3.: Model Completion concept.563.1. Model Completions and MDSDIn the following, we will focus on the horizontal activities, or so calledcompletions, of this concept. As illustrated on the Figure 3.3 these activi-ties have very interesting properties when the input model, Abs or Abs′, andoutput models, Abs′ or Abs′′, of transformations are conform to the samemetamodel. The metamodel is a language that allows a formal represen-tation (model) of entities and relationships in the real world on the certainlevel of abstraction. Initially, the level of correspondence and abstractionin the description of real-world entities is given by completeness or expres-sive power of the metamodel specification. The need for adjustment andcustomization is not only reserved for models. It also arises for metamod-els. Metamodels often do not fulfil requirements for special purpose and itis desirable to use a specifically tailored metamodel language. Developershave to extend metamodel by an embedding of required purpose-specificelements. As mentioned before this approach has its disadvantages. Thespecial properties of completions open a way to increase the expressivepower of the metamodels indirectly on the model instance level. With thehelp of completions it is possible to extend the model with purpose-specificaspects, that metamodel does not support directly. Completions add newaspects into the model instance using the language of the meta-(or abstract-)level recursively. Then, we define completions as follows:Definition 7 Model CompletionA model completion is a configurable purpose-specific transformation in-creasing model completeness while maintaining the language of the ab-stract level.This is an informal definition of completion necessary to discuss the MD-SPE process studied in this chapter. Completions are formally defined anddescribed in more detail later in Section 4.2.4. With this definition of com-pletions it is possible to reuse the existing transformation chain towardsimplementation even for the purpose-specific completed model as its in-573. Model Completionsput. Additionally, completions hide the complexity of the purpose-specificextension, allow configuration of aspect variants and encapsulate domain-specific expert knowledge. As a consequence completion-based evolutionof models following the design decisions about implementation on the levelof abstract models allows to create purpose-specific models in a traceableway even without the need of domain-specific expert knowledge. Further-more, the completions that are focusing on their own aspect can be indi-vidually maintained, and at the same time interconnected, building an en-riched metamodel. In other words, each metamodel could be enriched bya domain-specific language dealing with a particular aspect (or view) of asystem. The introduced completions have special properties that are veryinteresting for our application domain. In Section 3.2, we apply the modelcompletions in the MDSPE domain.3.1.2. Scientific Challenges in the MDSD contextIn this chapter, we summarize scientific challenges related to MDSD, whichare as follows:• Closing the semantic gap between an abstract model and low-level details: The conflict between the level of abstraction requiredfrom a high-level abstract model and a level of detail required to fitthe purpose of the model (e.g., performance prediction) makes it hardfor developers to create models they need. Additionally, the requireddetails are often very complex and variable. Inclusion of all requireddetails is in many cases not feasible. The necessary details increasethe model complexity in a such way that the model is not usable, un-derstandable, and trustworthy anymore. We deal with this challengein Section 3.1.1, where we propose the idea of completions on the ab-stract metamodel level. The realisation of this approach is describedin Section 4.7 and formalised in Section 4.2.4.583.1. Model Completions and MDSD• Hiding complexity and reusing expert knowledge: The comple-tions are used on the abstract level although they encapsulate andhide the complexity of low-level details requiring expert-knowledge.As such they can be used by developers without the required expertknowledge. Therefore, a suitable specification of completions on theabstract level that allows their reuse is very important. Additionally,we have to allow different completions to be used independently, sothat the developer or user of one completion does not have to know allother completions that may be used on the models. We discuss thischallenge further and create a reusable completion library in Chapter5.• Reusing existing transformation chains: Automation of modelcompletions allows reusing existing refinement chains in model-driven development process, e.g. generative transformation chainstowards implementation (Conc in Figure 3.3), at any point of theincremental completion. This requires that all the completions trans-form their input model towards the input model of the refinementchain without changing or extending modelling language defined bymetamodel. The completion concept (Section 3.1.1) addresses thischallenge, this pattern uses the same metamodel language for theextensions given by completions as for the input model. Thus, thetarget model is conform to the same metamodel. By this approach,the metamodel language is maintained unchanged and refinementchain can be reused. The realisation of completions is discussed inSection 4.7.• Support of variability: By their nature completions are very vari-able and as such a lot of effort is needed to implement and to maintainany automation solution realizing them. The support of variability inthe definition of completions and their transformations is crucial forthis approach. Because the variability of completions mirrors in the593. Model Completionsvariability of their transformations, this challenge is actually address-ing issue of transformation variability. This is the most challengingissue identified in this chapter that the implementation of comple-tions has to deal with. The support for variability in the transforma-tions definition is discussed in a separate Chapter 4.In the following section, we will introduce MDSPE application domainfor completions and summarize challenges related to this domain.3.2. Model Completions and MDSPEModel-Driven Software Performance Engineering (MDSPE) supports soft-ware developers to identify potential performance problems, such as bot-tlenecks, in their software systems within the design phase. The conceptsof MDSPE (surveyed in [6]) are based on the core idea of Software Perfor-mance Engineering (SPE) introduced by Connie Smith [147]. SPE enablesthe early performance evaluation of software systems. For this purpose,SPE integrates performance predictions directly in the software develop-ment process. It bridges the gap between architecture centric models usedby developers and formal performance models. In SPE, performance eval-uation of software systems is achieved on the basis of simple models [147]that are mapped to well-established performance modelling techniques andthus are made easily accessible for software architects and developers.In such early stages of the software life-cycle, only little information isavailable about the system’s implementation and execution environment.However, these details are crucial for accurate predictions. Often, detailedinformation on the execution environment (e.g., design patterns, middle-ware, database, operating system, processor architecture) is required toget meaningful predictions. The previously introduced completions closethe gap between available high-level models and required low-level de-tails. Model-driven technologies can be exploited to add such performance-relevant details to high-level architectural specifications. Using model-603.2. Model Completions and MDSPEdriven technologies, completions can include details of the implementationand execution environment into abstract performance prediction models.In the following section, we discuss the integration of completions into theclassical MDSPE process.3.2.1. MDSPE Application ScenarioAs mentioned before, the classical MDSPE uses model-driven techniquesto close the gap between architecture centric models used by software ar-chitects and formal performance models. For this purpose, existing ap-proaches provide transformations from architecture centric models, used bydevelopers, to formal performance models (overview in [20]), such as Lay-ered Queueing Networks (LQN), Stochastic Petri Nets (SPN), or StochasticProcess Algebras (SPA)(c.f. Figure 3.4).Prediction ResultsPerformance ModelSoftware Model- UML + SPT profile + Marte profile- ...- Queing Networks- Stoch. Process Algebra- Stoch. Petri Nets- ...- Response Time- Throughput- Resource Utilisation- ...Transform SolveFeedbackTool SupportFigure 3.4.: Model-driven Software Performance Engineering (MDSPE).In this thesis, we extend the classical SPE process by introducing com-pletions. Figure 3.5 illustrates the extended process of MDSPE with com-pletions. In this process, software architects describe their system in a lan-guage specific to their domain (such as UML [124], UML-SPT profile [124]or MARTE [128]). Alternatively, they can use architecture description lan-guages specialised for performance evaluation, like the Palladio Compo-nent Model (PCM) [18].We extend existing SPE process and provide tool support allowing soft-ware architects and developers to annotate their models with completions,613. Model Completionsmore exactly with chosen variant of completion. Thus, in the first step,they annotate software models with configurations of performance-relevantaspects using completions. These annotations encapsulate performance-relevant details, which are necessary for the model to provide more ac-curate performance predictions. They can decide, where to apply certaincompletion and with which particular configuration.Because of high-variability of completions and requirement for supportfor rapid evolution of prediction models, the integration of completionsand evolution of models is automated by transformations. The goal is todiminish manual effort, during the development phase, in the highest pos-sible extent; therefore, the transformations integrating completions have tobe automatically generated based on the actual configuration. This trans-formation generation phase is further discussed in Chapter 4. Using re-sulting transformation is then software model transformed into completedsoftware model. Completions hide the complexity of the full model fromsoftware architects when showing only the abstract annotations. They sup-port reusing performance-related expert knowledge. This firts step can berepeated until all required aspects are included.In the second step, other performance-relevant quantitative informationcan be included, such as model calibration based on the measurements.This step serves developers to include additional details about implementa-tion or details that should be considered only when other model representa-tion is generated, such us executable code, simulation code or performancemodels. To derive performance metrics from software models, the softwaremodel is transformed into a performance model as shown in Figure 3.5.The annotated software models are transformed to analytical performancemodels with resource demands based on model calibration and solved para-metric resource demands.Finally, the solution of the performance models by analytical or simulation-based methods yields various performance metrics for the system understudy, such as response times, throughput, and resource utilisation. The623.2. Model Completions and MDSPESoftware Model Prediction ResultsPerformance ModelCompleted Software Model- UML + SPT profile + Marte profile- ...- UML + SPT profile + Marte profile- ...- Queing Networks- Stoch. Process Algebra- Stoch. Petri Nets- ...- Response Time- Throughput- Resource Utilisation- ...Completion Platform ModelTransformTransform SolveFeedbackCalibrateCompletePlatform- OS- Processor- ...- Design Pattern -- Thread Pool- Middleware- ...Tool SupportFigure 3.5.: MDSPE with completions.biggest advantage of completions application in this context is that the spe-cialized models are conform to the same metamodel, or, in the terminologyof MDSPE, use the same architecture description language. As such, thetransformation to the performance model does not need to know about thechanges, or completions, realised on its input model and can be reusedcompletely.At last, the results are fed back into the initial software model. Thisenables software architects to reconfigure implementation details and inter-pret the effect of different design or allocation decisions on the system’sperformance and to plan capacities of the application’s hardware and soft-ware environment. In practice, tools encapsulate the transformation andsolution of the models and hide their complexity (cf. Figure 3.5).3.2.2. Performance CompletionsIn this section, we discuss necessary parts of performance completions.Figure 3.6 sketches the idea of performance completions. The core con-cept of completions is the separation of structural and quantitative informa-tion. The first part is an architecture-specific part that is newly generatedfor each completion configuration and the second part is an architecture-independent part that models the consumption of resources and is newlymeasured for each platform. The architecture-specific part consists of com-ponents and subsystems. The architecture-independent part are resourcedemands for specific platform for which the completion was created.633. Model CompletionsThe architecture-specific part is defined in Completion Structural Skele-ton that reflects, for example the Thread Pool’s general (performance-relevant) behaviour. The skeletons are structurally similar for differentplatforms, but their resource demands may vary. However, the skeleton de-fines the common structure of the performance completion, it depends onthe actual configuration and it has to be newly generated for each configu-ration. Important part of structural information is the configuration itself.It specifies possible options and their impact on the performance. Thecompletion developer has to identify effect of each configuration on thecompletions structure and express the model change in a form of structuralskeleton.Test DriverMeasurementResultsParametric Resource DemandsCompletion Structural SkeletonsConfigurationConfiguration EffectsMeasurementsData Analysis ModelingStructural AnalysisPlatform-specific CompletionIntegrationQuantitative information Structural informationFigure 3.6.: Concept overview of performance completions.The architecture-independent part is expressed in a form of ParametricResource Demands. Completions are parametric with respect to resourcedemands of the platform. Therefore, completions are adjusted for eachplatform. To capture the quantitative information for particular platform,software architects execute Test Drivers that take necessary measurements.Based on Measurement Results, software architects can determine realisticresource demands for complex platforms, such as Thread Pool implemen-tation in .Net or J2EE application servers on Windows or Linux platform.The software architects then analyse the measurement results and deriveplatform-specific Parametric Resource Demands. For example, software643.2. Model Completions and MDSPEarchitects can capture the effect of number of threads on resource demandsfor a specific Thread Pool implementation. They perform data analyses thatresult the approximated functional dependency of resource demands on thenumber of threads.The integration of the Completion Model Skeletons and Parametric Re-source Demands yields the Platform-specific Completion. The platformspecific resource demands are attached to their corresponding actions of themodel skeletons that structurally model the completion’s behaviour. Thecombination of parametric resource demands and model skeletons yieldsa complete performance model for the specific target platform. Because,extraction of quantitative and structural information for completion is non-trivial task and requires a lot of expert knowledge, the best way is to sys-tematize and to automate the completion design and development process.Ideally, the analyses during this process are performed fully automatically.In the following, we describe the design and development process for per-formance completions in greater detail.3.2.3. Scientific Challenges in the MDSPE contextThe application of completions, in the domain of MDSPE, bears particulardomain specific challenges:• Accuracy of performance prediction: Each completion or combi-nation of completions should increase prediction accuracy, i.e. re-duce the deviation of prediction and observation, corresponding bet-ter the reality. Therefore, the creation of a completion is challengeitself and requires detailed research of the modelled aspect. The ap-plication of completions can increase/decrease resulting performancemetrics and influence visible dependencies in resulting performancemetrics. The impact of a completion on the performance has to beformalized and clearly stated. We will formalize completions in653. Model CompletionsChapter 5 and discuss the performance impact of introduced com-pletions in Chapter 7.• Completion calibration: The automated measurements and analy-sis that are needed to calibrate the completions is a research field onits own. We do not contribute in this thesis to this research field.Completion approach, however, shows the integration of automatedmeasurements and analysis into the overall MDSPE process. Thecompletion developers use existing measurement frameworks (e.g.,the Software Performance Cockpit [169]) to calibrate their models.The resulting challenge is then reduced to the integration of perfor-mance results into the completions and architecture-centric models.We discuss integration of automated measurements and parametri-sation of performance models in the completion-based developmentprocess in Section 3.3.2.• Composition of performance abstractions: The composition ofcompletions is a challenging question, especially because of the ap-plication domain, where the performance quality attribute can be in-fluenced by completion composition. We have to analyse if applica-tion of completions in different order results in models equal consid-ering their performance. We discuss this topic in Chapter 5.3.3. Completions in CBSE Development processIn Chapter 2, we discussed the CBSE Development process. Based on thisprocess, we introduce two additional development roles. The role of com-pletion developer, who creates the completions and registers them with thelibrary, and the role of completion user, who actually uses completions andintegrates them into architecture models. Any of the classical CBSE rolescan take the position of completion user during the whole CBSE develop-ment process.663.3. Completions in CBSE Development processGenerally, the presented completion-based development process is verysimilar to those with the common goal of reusability and customizability.Our process is focused on reuse of process artefacts, especially those spec-ifying configuration models of completions. The goal of the process is toprovide necessary artefacts to automatically generate completion transfor-mations. The overview of this process is illustrated in Figure 3.7 with themost important automated step pointed out by the stripes.inputdependencyDomain AnalysisPlatform-specific Completion DataLegendactivityDocumentationCompletion DesignCompletion ValidationCompletion ImplementationInitial CompletionValidated CompletionReusable CompletionCompletion LibraryMissing Influences and AssumptionsMappingsDataSoftware Model Development /Requirements AnalysisModel Annotation /Completion ConfigurationCompletion Transformation GenerationRequirementsCompletion ExecutionSoftwareModelCompletedSoftware ModelTransformationCompletion InstanceCompletion Developer Completion UserDesign DecisionsFigure 3.7.: Completion-based development process overview.We can separate the completion-based process into two phases, first thedomain engineering, where the tasks of completion developer are located,and second software engineering, which is specified by tasks of completionuser. In the domain engineering phase the reusable and configurable com-pletions are specified. The initial part is domain analysis consisting of theextraction and analysis of possible features and their combinations in thecompletion. Completions encapsulate possible design decisions that resultfrom requirements on the software. Typically at the beginning of devel-673. Model Completionsopment, there is only an abstract idea about these requirements. Towardslater development phases, these incomplete, variable and contradictory re-quirements could change. The domain analysis task has the main goal torecognize and analyse possible requirements on the software and to defineallowed combinations among them. This analysis defines the first step at-tempting to design a new reconfigurable construct that could be used insoftware design. This helps to reduce the risk of a complete redesign ofsoftware models in the case of major changes in requirements. Once thepossible requirements are determined they should by analysed and clearlystated. For this purpose, the configuration model is used, where the possi-ble requirements are specified as configurations of features belonging to acompletion.The next step, the completion design defines how configuration options,so called features, and their combinations affect the final software model.Here it is necessary to determine the dependency among different config-uration properties, the model structure and the model elements’ attributevalues. The result of the completion design step is an extension of the pre-defined configuration model by feature interdependencies and documenta-tion how the features map to the software model changes.After identifying possible completion features, feature interdependen-cies and resulting changes of software model based on these features, wevalidate the initial configuration model by comparison with the real worldimplementation. This step is called completion validation and consists ofa set of experiments and measurements on the prediction model and corre-sponding implementation. When the results of measurements and predic-tion correspond with required accuracy the implementation of completioncan start. In other case, we have to look for and analyse missing assump-tions and influences.Step completion implementation represents the activity of developing ac-tual reusable completion. Therefore, it is necessary to formalise the modelchanges resulting from feature choice and create the final configuration683.3. Completions in CBSE Development processmodel. Followed by registration into the library and offering it to the actualusers.The phase of the software engineering includes actual software model de-velopment and requirements analysis. The task model annotation and com-pletion configuration benefits of reusable constructs defined by completiondeveloper. The completion users can annotate their models by completioninstances and attach particular configurations to them. The main goal ofthis step is to make sure that the software model will meet the requirementsdefined for the product, as well as ensuring that future requirements can beaddressed.The most important step included in the process is the completion trans-formation generation. Here, we apply the approach presented in Chapter4. The generated transformation is then applied (completion execution) tothe input software model resulting in the completed software model. In thefollowing, we discuss the completion-based development process in detailand illustrate each step on a running example.3.3.1. Running ExampleThis section introduces our running example, that is used throughout thisthesis. Moreover, we motivate the choice of the running example.Today, many applications (e.g., Web servers, Database servers) are de-signed to process a large number of short tasks that arrive from some remotesource (using for example messaging, HTTP, FTP). In the case of server ap-plications, processing of each task is short-lived and the amount of requestsis large. The Thread Pool design pattern offers a solution to the threadmanagement and is widely used by many multi-threaded applications. Thepoint of the Thread Pool is to avoid a creation of a lot of threads for shorttasks. The Thread Pool pattern reuses each thread for multiple tasks. Themain advantages are in allowing of the process to continue while waitingfor slow operations such as I/O-intensive tasks, and exploiting the avail-693. Model Completionsability of multiple processors. In the running example, we focus on theThread Pool model since most of server applications are built around pro-cessing large number of short requests, which require low-overhead mech-anism with resource management and timing predictability. Additionally,the Thread Pool design pattern promises performance increase and realisticoptimization of resource usage. Especially, the importance of this patternfor performance prediction motivated our choice to use it as a running ex-ample.In the following, we go through the steps of the completion-based de-velopment process and incrementally develop a completion for the ThreadPool design pattern. First, we analyse the structure of the Thread Pooldesign pattern and discuss performance-related characteristics of this pat-tern. Second, a brief discussion about the variety of Thread Pool imple-mentations and their characteristics takes place. Afterwards, we discuss theperformance measurements of Thread Pool from the literature showing im-portance of this pattern. Finally, we present the Thread Pool configurationmodel that will serve further as running example to illustrate the processof automated completion integration. The running example itself results inthe definition of a reusable completion for the Thread Pool design pattern.This completion will be included in the completion library and is one of thecontributions of this thesis.3.3.2. Completion-based Domain EngineeringAt the beginning of Chapter 3.3, we gave an overview of the completion-based development process. The detailed description of the tasks includedin this process is goal of this section (cf., Figure 3.8). We give overviewon the usage of model-driven techniques in combination with performanceanalysis and prediction methods.703.3. Completions in CBSE Development process3.3.2.1. Domain AnalysisThe goal of domain analysis (cf., Figure 3.8a) is to understand the perfor-mance of software systems. In the analysis, we focus on a particular im-plementation detail and its performance properties. The detail that is objectof the study in this step is an implementation of particular performance-relevant aspect, such as a design pattern (e.g., Thread Pool) or middlewareplatform. However, modelling performance-relevant aspects is not alwayspossible when dealing with used third-party- and legacy-software. Suchsoftware is used as a black-box component in implementations of complexsystems. The necessary amount of time to model this software may out-weigh the advantage of performance prediction at design time. Addition-ally, required information about the system’s structure and other propertiesmight not be easily to gather. A way to integrate such kind of software intoperformance-model is the path of documentation recherché, trying to findout about its properties by testing and analysing its performance in a con-trolled environment. We systematically evaluate the studied system’s per-formance in relation to its configuration and usage. Such process requiresa lot of experience and detailed expertise in the field of benchmarking, dataaggregation and analysis methods. In this initial step of completion de-velopment, we assume that we have a framework supporting systematicperformance evaluation available. In our approach, we use the SoftwarePerformance Cockpit [169], that is a framework to systemize and automatethe tasks required to evaluate performance of software systems.First, we identify the performance-relevant features of studied aspect,based on documentation and other functional or parameter descriptions.This domain-specific knowledge is used in evaluation process. For eachdetail, we have to identify its configurable and measurable parameters andtheir dependencies. Additionally, to start experiments and measurementsknowledge about the testing environment is needed. We have to specify theplatform for the completion. The resulting completions are then platform-713. Model Completionsdependent and we can provide number of versions of one completion fordifferent platforms.For chosen system setting, based on the documentation recherché and/orresulting assumptions we create GQM plan for the systematic experiments.At this point, the measurement frameworks, like the Software PerformanceCockpit, take over and drive performance evaluation based on the GQMplan. The Software Performance Cockpit provides a language to describeexperiment design based on the GQM plan. It is able to determine efficientseries of experiments to get the most meaningful measurement-data withinas few experiments as possible. The measured data are later used to refineand to focus the experiment design on the most promising configurations.The data analysis algorithms are used to calculate possible dependenciesbetween parameter configurations and performance of the system under thetest. The Software Performance Cockpit executes following steps: it runsthe actual experiment, collects) and (aggregates data). We described theintegration of the Software Performance Cockpit into the completion de-velopment process in [77]. During the data collection step, we measure theinfluence of performance-relevant parameters for the studied system in itstarget execution environment. The collected data is used to infer (parame-ters of) a prediction model.We use statistical inference techniques [79] and genetic optimization, toderive the influence of a studied aspect’s usage on its performance. Statis-tical inference of performance metrics does not require specific knowledgeof the internal structure of the system under study. However, statistical in-ference can require assumptions on the kind of functional dependency ofinput (independent) and output (dependent) variables. The inference ap-proaches mainly differ in their degree of model assumptions. For example,linear regression makes rather strong assumptions on the model underly-ing the observations (they are linear) while the nearest neighbour estimatormakes no assumptions at all. Most other statistical estimators lie betweenboth extremes. Methods with stronger assumptions, in general, need less723.3. Completions in CBSE Development processdata to provide reliable estimates, if the assumptions are correct. Methodswith less assumptions are more flexible, but require more data. These anal-ysis methods are supported by the Software Performance Cockpit. The taskof completion developer is to extract enough variables and needed assump-tions about their dependences (when available) to realise the analysis.The last step of domain analysis is the data analysis. In this step, weformalize the quantitative information needed for completion as describedin Figure 3.7. The aspect models inferred in the previous step are later bycompletion design integrated into software performance models to predicttheir effect on the overall performance of the system. We use the PalladioComponent Model (PCM) in combination with performance completions toevaluate the performance of the system under study. The PCM is well suitedfor our purposes since it captures the effect of different input parameters onsoftware performance. Stochastic expressions of the PCM can be used todirectly include the functions resulting from the statistical analysis into thecomponents of a performance completion. In the data analysis step, weselect data necessary for later completion design and express them in theunderstandable form. In our case, we use the form of stochastic expressionsfor resource demands in the PCM. The resource demands are platform-specific and have to be determined for each platform and for each executionenvironment. Determined resource demands are used to parametrise andcalibrate the completions in the later steps.733. Model CompletionsinputdependencyDomain AnalysisPlatform-specific Completion DataLegendactivityDocumentationDomain AnalysisCompletion DesignCompletion DesignCompletion ValidationCompletion ValidationCompletion ImplementationInitial CompletionValidated CompletionReusable CompletionCompletion Library(1)(2)(3)(4)Missing Influences and AssumptionsMappingsDataIdentificationPlatform-specific Influences and AssumptionsDocumentationFunctional DescriptionParameter Description(1)Platform Specification(hardware and deployment)Experiment DesignData CollectionData AggregationData AnalysisGQM PlanExperiment ConfigurationTest DriverExperiment RunMeasurementsParametric Resource Demands Platform-specific Completion Data(Resource Demands, Measurements)(2)(4)Configuration IdentificationConfiguration ModelPlatform-specific Completion Data Influences and Assumptions(2)Completion Skeleton DesignInitial CompletionMapping of skeleton structure to configuration options(3)(4)Completion-based Test Model DesignTest Model ImplementationInitial Completion(3)SimulationDomain AnalysisMeasurementsTest ModelResults ComparisonValidated CompletionMissing Influences and Assumptions(1)(1)(2)(4)Configuration Options EffectsDevelopmentConfiguration Effects and Parametric Resource DemandsValidated Completion with mapping of skeleton structure to configuration options(4)Completion ParametrisationCompletion CalibrationConfiguration Effects and Measurements ResultsReusable Completion(1)(1)(2)(3)Completion Library(1)(2)(a) Domain Analysis.(c) Completion Validation.(b) Completion Model Design.(d) Completion Implementation.Software Performance CockpitFocus of the thesisFigure3.8.:Tasksofthecompletiondeveloper.743.3. Completions in CBSE Development process3.3.2.2. Running Example: Thread Pool Domain AnalysisThread Pool: Structure The Thread Pool design pattern belongs to thegroup of resource management patterns and is used to increase performanceof the application. The implementation of Thread Pool pattern can be il-lustrated on an example of simple e-Commerce-Application, where cus-tomers shop in a product catalogue. The application is implemented withEJB-Technology as client-server application. Clients use Web-Browsersto communicate with Java-Servlet-Engine in parallel. The business logic ofthe application is implemented in the server component. The server compo-nent is connected via Java Database Connection (JDBS) with the database.The product catalogue mirrors current state of the database. The servercomponent connects with the database for each client request and executesnecessary SQL request. The results of the SQL request are then propagatedto the client’s Web-Browser. The Thread Pool is implemented to managemany instances of the same resource, in this case the managed resourcesare JDBS connections to the database. The pooling concept allows usage(acquire) of the resource instance and their reuse when the instance wasset free (release). The Thread Pool creates number of resource instances(threads) in advance and manages a waiting queue for incoming requeststhat have not assigned free thread yet. A typical usage scenario for ThreadPool is when there are many more tasks than threads and the Thread Poolmostly executes on a single computer. As soon as a thread completes itstask (or number of tasks, dependent on Thread Pool capacity) it will ac-cept the next task from the queue of waiting tasks until all tasks have beencompleted. The thread is then returned to the pool until there are new tasksavailable. The behaviour of a Thread Pool (with capacity of 3 threads) isillustrated by the Petri net in Figure 3.9.Thread Pool: Performance-relevant influences and assump-tions Within this step we study other research works with focus on753. Model CompletionsFigure 3.9.: A sample Thread Pool of capacity = 3 with waiting tasks and completedtasks.Thread Pool performance and analyse implementations of Thread Pool.This recherché provides excessive data, which are basis for the later exper-iment design. In the following, we provide short exemplary related workanalysis.In the literature, there are works analysing the influence of Thread Poolon performance. Shiping Chen and Ian Gorton [32] have identified ThreadPool size as one of the configurable system parameters that are importantfor achieving maximal throughput. The implementation of a Thread Poolhas a prominent impact on the performance due to its ability to limit thelevel of concurrency in the system [33]. The most important parameter thatcan be tuned to provide the best performance is the capacity of the ThreadPool. An excessive number of threads leads to waste of memory and neededcontext-switching among the threads also decreases performance. There-fore, in some Thread Pool variants the number of threads can be dynamic,based on the number of waiting tasks. Some software providers decidedabout static size of a Thread Pool in their products, for example in .Netframework by default the Thread Pool has 25 threads per processor. Sucha static Thread Pool with fixed pool size, is supported by latest version of763.3. Completions in CBSE Development processJava JDK 7 [131]. This Thread Pool variant always has a specified numberof threads available. Tasks, from an internal queue that holds waiting tasks,are appointed to the threads from the pool, whenever there are more activetasks than active threads.Thread Pool: GQM plan In order to conduct systematic evaluation ofthe studied aspect, goals, questions and metrics must be defined to allowa quantification of the system’s performance. Using performance metrics(e.g., response time, throughput, utilisation) and configuration parameters(e.g., arrival-rate, number of threads), we can formulate the experimentquestions, scenarios and hypotheses. In the following, we give an exampleof a question in the GQM plan with the observed metrics identification:QUESTION Q: Does a greater number of threads in a Thread Pool implyan increased performance? The focus of question Q lies in the evaluationof a possible correlation between the number of used threads and the ThreadPool’s performance.SCENARIO S: In Scenario S, we use simple Thread Pool variant withvariable number of threads in a pool. The total workload is set to reacha Thread Pool utilisation of 80%, which we choose to maximize the rep-resentativeness of collected results. The advantage of using Thread Poolcould be observed at high loads, when we can study the effects of threadconcurrency and scheduling. Therefore, we hold during the experiments aconstant utilisation of the Thread Pool at 80% at least.HYPOTHESIS H: The Thread Pool performance is expected to grow untilthe number of threads is higher as number of CPUs in the system. Hy-pothesis H1 is based on the assumption that, for a constant workload, anincreased number of threads implies increased performance until the in-creased number of resource-conflicts appears. For example, the resource-conflicts appear in a case of CPU-intensive requests, when the number ofthreads is higher as number of CPUs. However, this is more complex forI/O-intensive requests, which compete for other resource (HDD) that can773. Model Completionsbe a bottleneck even before a CPU. in this case additional experiment isneeded.METRICS M: Response time, ThroughputThread Pool: Results from measurements and experiments:To illustrate results of the measurement of such experiments, we use theresults of a study thesis by Achraf El Ghazi [62]. He analysed and mea-sured the performance of the Thread Pool pattern. His performance ex-periment evaluated CPU- and I/O intensive requests. His experiments forI/O and CPU intensive requests resulted in a dependency specification ofrequest execution time on different parameters. For example, in the caseof CPU-intensive requests, the execution time depends on: thread servicetime, request arrival rate, the number of requests in system, maximal sizeof the Thread Pool, and size of time slice in the OS scheduler configura-tion. To collect the necessary data for calibration of models he measuredEJB 3.0 application using GlassFish V2 B41 application server, thus hismeasurements are specific for this platform. Figure 3.10 represents themeasurement results of request execution time relative to the first point intime when the request execution started. The request arrival time in thisexperiment was 1100 ms and maximal Thread Pool size was 1000 threads.The graph shows a monotone increase of the execution time for the first36% of the requests. The following requests yield a stable execution timeof 30 to 40 seconds.Thread Pool: Platform-specific Completion Data The results ofexperiments are then input for specification of platform-specific completiondata as used in this thesis. The analysis of the data yields functional de-pendences between different Thread Pool parameters, workload, and othersystem settings. In our example, the request execution time depends on therequest arrival rate (Workflow:ArrivalRate.VALUE), the thread execu-tion time (ThreadExecutionTime.VALUE), the maximal Thread Pool size(PoolSize.VALUE), the number of requests in the system (defined for a783.3. Completions in CBSE Development processFigure 3.10.: Example of experiment results [62].closed workflow as Workflow:PopulationSize.VALUE) and the config-uration of OS scheduler (TimeSliceSize.VALUE). Based on this observa-tion, we can define resource demand on CPU as:1/[(ThreadExecutionTime.VALUETimeSliceSize.VALUE)]∗min(Workflow:PopulationSize.VALUE,PoolSize.VALUE+1)∗TimeSliceSize.VALUEMoreover, based on the previous studies we can identify default or evenclose to optimal Thread Pool configurations, for example:PoolSize.Size= ReplicaCount.VALUE+1,that defines an optimal number of threads parametrised by number of CPUreplicas for CPU-intensive requests.793. Model Completions3.3.2.3. Completion DesignIn this section, we introduce details of the completion design (cf., Figure3.8b). We describe the structural part of completion and its development.The concept of quantitative and structural information separation in thecompletion design was introduced in Section 3.2.2. Moreover, completiondesign step integrates the quantitative information needed for completionresulting from previous domain analysis step.As first to design a completion, we have to create the configuration modeland the structural skeleton. For this purpose, we use feature diagrams (seeSection 4.5.2.1). We extract performance-relevant attributes of the studiedaspect as features in a feature diagram.Configuration Model: Feature diagrams define all valid combinationsof application property values, or features. One feature defines a certainoption in the considered domain. Actual chosen combinations of featuresare called configurations (feature configurations). Feature diagrams are hi-erarchical decomposition of features including information if a feature ismandatory, alternative or optional. We use extended feature diagram, thatis discussed in detail in Section 4.5.2.1.Using feature diagrams as configuration models brings the advantage ofhaving a focused and less-complex configuration method understandable byall of the roles in development process. Such feature-based configurationmethod can be mapped to individual model changes and allows generationof completion transformations. The concept of generation of completiontransformations is discussed in Chapter 4. In the following section, we willillustrate the step of feature model specification on the running example.Completion Structural Skeleton: The separation of concerns in soft-ware modelling avoids the construction of large and monolithic models,which could be difficult to handle, maintain and reuse. However, havingdifferent models describing different aspects requires their integration into803.3. Completions in CBSE Development processa final model that represents the entire domain. In previous steps, we al-ready identified one part of modelled domain, the quantitative informationabout the completion. To complete the design of completion we have tospecify required information about the structure. The design phase yieldscompletion model skeletons that capture the structure of the completion.The completion model skeleton specifies a set of necessary components,and their behaviour, building the structure of completion. The skeletonsonly abstractly model the structure and behaviour without any resource de-mands. All possible variants of completion are captured by its structuralskeleton.We use model weaving to select a subset of the components needed fora particular completion variant based on the current configuration. Thereis no accepted definition of model weaving, we consider it as the fine-grained relationships between completion configuration and skeleton mod-els. Based on these relationships and correspondences between the consid-ered model parts, we avoid to have large skeleton models for capturing allthe variants of the aspect. The completion developer has to have a clearoverview about these mappings, that represent model changes required to-wards completed software model.3.3.2.4. Running Example: Thread Pool Completion DesignThread Pool: Configuration Model Based on the previous discus-sion, we extracted important performance-relevant features of Thread Poolpattern in a form of feature diagram. These features summarize differentconfiguration options of the thread management implementation based onthis pattern. The resulting feature diagram is illustrated in Figure 3.11Java-specific Thread Pool feature diagram: For the purpose of therunning example, we simplified the feature model for Thread Pool designpattern. The simplified version is based on the features supported by thelast Java JDK (1.6). The Java platform is designed to support concurrent813. Model CompletionsLegendorexclusive ormandatoryoptionalThreadPoolOptimizationPropertiesStatic DynamicPool Size Core Pool SizeMaximum Pool SizeKeepIdleTimeWaiting QueueDirect Handoffs Unbounded BoundedKeepAliveTimeFigure 3.11.: The configuration model of Thread Pool design pattern (used for therunning example).programming and includes high-level concurrency APIs. The concurrencysupport is implemented in the java.util.concurrent packages. Thefeature model in Figure 3.11, that will be used as a running example, col-lects Thread Pool implementation options supported by Java platform. Tovalidate this model, we will compare the prediction results with the mea-sured results later in the thesis.The valid Thread Pool configuration includes the mandatory feature Op-timization Properties. This feature may define either a static or a dynamicThread Pool variant. The exclusive selection is indicated by the excludesconstraints between both features. Each of these features have to have anumber of threads specified. This is either a static pool size or, for thedynamic feature, a core and a maximum number of threads. Additionally,software architect has a possibility to specify the time after which an idlethread in a static pool should be returned to the pool (or "sleep"), avoidingwaste of resources by busy waiting. Similarly, for a dynamic Thread Poolhe can specify, by KeepAliveTime, when an idle thread should be destruc-ted. This provides a means of reducing resource consumption when thepool is not being actively used. If the pool becomes more active later, newthreads will be constructed.Lastly, an important attribute is the queueing strategy in a waiting queue,because use of this queue interacts with pool sizing. There are three differ-823.3. Completions in CBSE Development processent strategies for queueing. Direct handoffs is a default choice for a workqueue that hands off tasks to threads without otherwise holding them. Here,an attempt to queue a task will fail if no threads are immediately avail-able to run it, so a new thread is required to be constructed. Unboundedqueue will cause new tasks to wait in the queue when all threads are busy.Bounded queue helps prevent resource exhaustion when used with finitemaximum pool sizes, but can be more difficult to tune and control. Queuesizes and maximum pool sizes may be traded off for each other: Usinglarge queues and small pools minimizes CPU usage, OS resources, andcontext-switching overhead, but can lead to artificially low throughput. Iftasks frequently block (for example if they are I/O-intensive), a system maybe able to schedule time for more threads than you otherwise allow. Useof small queues generally requires larger pool sizes, which keeps CPUsbusier, but may encounter unacceptable scheduling overhead, which alsodecreases throughput.Thread Pool: Structural Completion Skeleton We designed an ab-straction of the Thread Pool pattern (cf., Figure 3.12) for the purpose ofperformance prediction. The pattern abstraction is a version of a Leader-Follower pattern, where one particular thread takes the role of the leaderand waits for the next request. All other threads are either followers (i.e.,queued) or leaders (i.e. processing requests). To model this pattern we caneasily use one Thread Pool component with a size equal the capacity of thesystem. The overview about the required changes (e.g., adding/removingcomponents) of the model helps completion developer with later imple-mentation. Therefore, he is required to first model per hand a completionskeleton for each feature and validate them. Based on these analysis he canchoose appropriate abstraction and implement the change mappings. InFigure 5.21 the mappings, for one simplified variant, are illustrated by ar-rows. The semantic of these arrows is addition of the selected components,interfaces, methods or values to the model. To integrate a Thread Pool ab-833. Model CompletionsThreadPoolOptimizationPropertiesStatic DynamicPool Size Core Pool SizeMaximum Pool SizeKeepIdleTimeWaiting QueueDirect Handoffs Unbounded BoundedKeepAliveTimeServerClientThreadPoolWrapperPool:size=Nacquire releaseN=Pool Sizeacquire()release()Figure 3.12.: The structural completion skeleton of Thread Pool design pattern.straction into the model we have to add the Wrapper and the Thread Poolcomponents to the model. This basic structure of the skeleton is createdfrom the root feature. The child features then add the behaviour specifica-tions (e.g., SEFFs) and parameters to the components (e.g., PoolSize).3.3.2.5. Completion ValidationTo validate the initial completion (cf., Figure 3.8d), we create a test modeland correspondent implementation of modelled aspect in a real system. Us-ing the test model we realize a set of simulations (e.g., using PCM simula-tion framework) to predict system’s performance. Furthermore, by measur-ing the implementation we get a real performance data about the system.The measurements are again executed automatically taking an advantage843.3. Completions in CBSE Development processof support provided by the Software Performance Cockpit (see the domainanalysis step). In order to ensure that the completion model captures andcorrectly models all relevant parameters, developers compare predictionsand measurements. Based on the outcome of the comparison, it might benecessary to execute further experiments to evaluate observed deviationsof predictions and measurements. In such case, the developers extend thedomain analysis and the completion design to the required level. Whenthe desired degree of accuracy is reached, developer can start to implementgeneric and reusable completion.3.3.2.6. Running Example: Thread Pool Completion ValidationTo validate the Thread Pool completion, developers need to compare dif-ferent predictions and measurements of execution times for different con-figurations. Additionally, they can compare different Thread Pool variantseven when available other thread management strategies, such as ThreadPool versus the Thread-Per-Request model.In the Thread Pool example, we discussed measurement results for re-quest execution time depending on the start time a request is initially exe-cuted. In this experiment the request arrival time was 1100 ms and maximalThread Pool size was 1000 threads. Using our Thread Pool model, we canexecute simulations with the same system settings. The prediction resultscan be then compared to the measurements as illustrated in Figure 3.13. It isvisible from these graphs that the model allows to predict the behaviour ofThread Pool with very good accuracy (see Table 3.1). For the first 49,6% ofthe requests, before the Thread Pool stabilised, the prediction error is high-est. For later requests, the predicted execution time (30,00 s) is very close tothe mean value of the measurement results (27,77 s). The mean value of ex-ecution time was predicted with the prediction error smaller than 10%. Theprediction results promise more accurate predictions when the additionaleffects on Thread Pool performance are considered (see Section 5.3.5).853. Model Completions(a) Measurement results (b) Prediction resultsFigure 3.13.: Example of Thread Pool model validation [62].Mean [ms] Max [ms] Min [ms]Prediction 30004.72 36170.00 1140.00Measurement 27776.78 43449.92 1206.15Error [%] 7.42 16.75 5.48Table 3.1.: Example of the evaluation of prediction accuracy [62].3.3.2.7. Completion ImplementationThe goal of this step (cf., Figure 3.8e) is to implement generic and reusablecompletion, that can be registered into the completion library and used bythe performance analysts. Each of the introduced completion features couldhave additional information attached as, for example, fragments of code.In the completion design step, we define how features and their combi-nations affect the software model. We defined mappings specifying thedependences among different feature configurations, the model structureand the elements’ attribute values. The result of this step is an extensionof the pre-defined feature diagram by dependences and documentation howthe features map to the software model changes. We call these extensionfeature effects, they make clear which feature triggers which change.863.3. Completions in CBSE Development processDefinition 8 Feature EffectFeature effect is a formal representation of a isolated model change result-ing from feature selection.To formalise and implement feature effect, we have to develop actualtransformation fragments, which encode the change to the software model.The result of this activity is a feature model, that is extended by the annota-tions in a form of model-to-model transformation fragments. In this work,we use to implement transformation fragments the OMG QVT-Relationstransformation language.When the completion is validated and the feature effects are developed,the developers can parametrise the performance completion. Therefore,they derive the parametric resource (e.g., dependency of default number ofthreads on the number of CPUs, etc.) demands for the completion compo-nents and adjust the feature effects to integrate into the completed modelthese demands or static calibrations (e.g., measured platform-specific net-work overhead) , if necessary. The parametrisations and calibrations areintegrated into the model by the feature effects.3.3.2.8. Running Example: Thread Pool CompletionImplementationAs presented in previous section, the nodes of the feature diagram are an-notated with feature effects, implemented as transformation fragments. Weillustrate the feature effects implementation on the running example (cf.,Figure 3.14). The effect of Thread Pool feature is depict by the relationTP and creates necessary components (simplified in Figure 3.14). The resultof this feature effect is the creation of component TP. The effect of Staticfeature TP_Static has a when-dependency to the parent effect TP. Whenthe component TP exists, the TP_Static feature can be used to staticallyconfigure the size of the Thread Pool and set the default value. Hence, thetransformation fragment belonging to the the feature Pool size refers to873. Model CompletionsThreadPoolOptimizationPropertiesStatic DynamicPool Size Core Pool SizeMaximum Pool SizeKeepIdleTimeWaiting QueueDirect Handoffs Unbounded BoundedKeepAliveTimetop relation TP { checkonly domain in p : Component {}; enforce domain out s:TP { }; }top relation TP_Static { varSize : Integer; checkonly domain in p : Component {}; enforce domain out s:TP { poolsize = varSize; }; when { TP(p,s); } where { varSize = 100;--default }}TP_Static.varSize = poolsize;Legendorexclusive ormandatoryoptionalFigure 3.14.: Example of feature effects implemented as fragments oftransformations.the free variable declared in the TP_Static fragment of feature Static andoverrides the default value. Additionally, transformation fragments can in-tegrate quantitative information into the completion transformation, whichaddition is straightforward in the fragment implementation. We will discussthe transformation fragments in a more detail in Chapter 4.5.3.3.3. Completion-based Software EngineeringIn this section, we discuss the role of completion user and how he/she cantake advantage of the developed completion from completion library. Thephases of the software engineering include actual software model develop-ment and requirements analysis. Starting with the requirements on the soft-ware system, the model developers create a software model and meet cor-respondent design decisions. The task model annotation benefits from thereusable completion defined by domain engineering. When model develop-ers find a suitable model completion supporting their design decision, themodel can be annotated with the configuration of this completion. Modeldevelopers attach required configurations to the model elements where theyplan to apply chosen completion. The main goal of this step is to make sure883.3. Completions in CBSE Development processthe software application will meet the requirements defined for the prod-uct, as well as ensuring that future requirements and design decisions canbe addressed.RequirementsSoftware Model Development / Requirements AnalysisModel Annotation / Completion ConfigurationCompletion Transformation GenerationCompletion ExecutionSoftwareModelCompletedSoftware ModelTransformationCompletion LibraryCompletion InstanceDesign DecisionsFigure 3.15.: Tasks of the completion user.The most important step is the completion transformation generation.Realisation of this step is a topic of the whole following Chapter 4. Thegenerated transformation is then applied (completion execution) to the in-put software model and results in the completed software model. The com-pleted model is then directly passed to the existing simulation or analysisframeworks and provides more accurate and more complete predictions.Running Example: Using Thread Pool Completion The softwaredeployer role from the CBSE development process can use the Thread Poolcompletion as annotation to the resource container. Each user of the com-pletion has to create a correspondent feature configuration. The actual fea-ture configuration based on the Thread Pool feature diagram is illustrated bycheck(selected feature) and cross(eliminated feature) -marks. For such Fig-ure 3.16 additionally depicts one possible configuration of a Thread Pool.This feature configuration defines a simple static implementation of Thread893. Model CompletionsPool with the size of 32 threads treating all incoming tasks with the samepriority.Legendorexclusive ormandatoryoptionalThreadPoolOptimizationPropertiesStatic DynamicPool Size Core Pool SizeMaximum Pool SizeKeepIdleTimeWaiting QueueDirect Handoffs Unbounded BoundedKeepAliveTimesize:int =32Figure 3.16.: Thread Pool feature configuration.3.4. SummaryThe main contribution of this chapter is the generalisation of the ModelCompletion concept and its integration into the MDSPE process. In thischapter, we discussed relationship of model completions to MDSD andMDSPE processes. To put model completions into practice, we introduceda general process to design and apply performance completions in the MD-SPE. The design of completion-based development process for MDSPEwas presented in the invited talk on the EPEW 2010 and published in [93].The completion developers define completions based on abstract speci-fications and design patterns and, thus, parametrise over the platform andvendor-specific properties of different platforms. In our development pro-cess, we automate the measurement data collection using Software Per-formance Cockpit. The resulting parametrised completions allow softwarearchitects to instantiate the completion for their target platform and anno-tate their models. The performance completions represent powerful tool toanalyse performance of software using complex design patterns and plat-forms (e.g., application servers). We describe details of the particular steps903.4. SummaryinputdependencyDomain AnalysisPlatform-specific Completion DataLegendactivityDocumentationCompletion DesignCompletion ValidationCompletion ImplementationInitial CompletionValidated CompletionReusable CompletionCompletion LibraryMissing Influences and AssumptionsMappingsDataSoftware Model Development /Requirements AnalysisModel Annotation /Completion ConfigurationCompletion Transformation GenerationRequirementsCompletion ExecutionSoftwareModelCompletedSoftware ModelTransformationCompletion InstanceCompletion Developer Completion UserDesign DecisionsSection 6.3Section 6.3.3Section 8.2.1Section 5.5-6Section 6.3.3-5Section 4.3Section 8.3Section 5.8Section 8.3Section 6.2Figure 3.17.: Pointers to the detailed description of particular development steps.during the completion development process in separate sections later withinthis thesis.Figure 3.17 gives an overview about the structure of this thesis and point-ers to the chapters where details to the particular steps of the completion-based development process can be found. In the following chapter, we dealwith the automated integration of completions and management of theirvariability using Higher-Order Transformations (HOTs).914. Variability Management usingHigher-Order TransformationsIn the previous chapter, we introduced the concept of Model Completionsand its application in MDSPE. We discussed the main challenge related tocompletions in the MDSD context, which is the variability support. The re-quirement for variability results from the reconfigurability of completions.The model elements to be completed are determined by this configuration.The completions are implemented as model-to-model transformations. Be-cause, it is not feasible to implement a transformation for each combinationof configuration options, the variability of completions should be mirroredin the variability of their transformations.The leading challenge of this chapter is:How to support configuration-based variability in model transforma-tions?The remainder of this chapter will be organized as follows. Section 4.1introduces the problem domain. The main contribution of this chapter,CHILIES approach, is discussed in Section 4.2. Section 4.3 introduces theprinciple of Higher-Order Transformations (HOTs) and the idea of HOTpatterns definition. The patterns used to support completions are describedin Sections 4.4, 4.5 and 4.6. The composition of these patterns is discussedin Section 4.7. At last, we summarize the assumptions and limitations inSection 4.8, and conclude this chapter in Section 4.9.934. Variability Management using Higher-Order Transformations4.1. Problem DomainIn this chapter, we deal with the problem of variability management intransformations given a fixed input model. The variability of transforma-tion results from two sources: First, the requirement to increase expressivepower of metamodels through particular model elements originating fromdomain-specific languages. Second, the requirement to include variableparts into the transformations and adapt their functionality. In the bothcases, the changes of requirements on the software product (e.g. changedapplication domain, or required more detailed model) result in the changesof the transformations. In the following, we discuss both of the cases inmore detail.4.1.1. Increasing Expressive Power of MetamodelsThe language features, such as programming language pragmatics [145],have clearly a huge impact on the developers ability to write clear, conciseand maintainable code. A typical example of language pragmatics is theforeach statement in Java [131]. Analogous aspects apply to modellinglanguages, especially in the case of very large and complex systems. Toincrease usability of model-driven techniques we need modelling pragmat-ics that support efficient model design, too. Often developers claim that themetamodel is not suitable for the purpose of a particular model, that someother metamodel is more powerful. Although, in a sense of expressivenesstwo metamodel-based languages can be equivalent, both can be used forthe same goal, even if it is not straightforward and the models would be toocomplex, and can be suitable to express anything written in the other. Themost important factor contributing to the expressive power of the meta-model are features of abstraction. The modelling pragmatics support thedeveloper to overcome the complexity of the model by abstraction.As discussed in the previous chapter, in some scenarios, metamodels donot have enough expressive power to allow modelling of all required details.944.1. Problem DomainFor this purpose new metamodel elements have to be introduced which re-quires adapting all transformations based on the metamodel. The requireddevelopment effort for these adaptations depends on the complexity of themetamodel changes and the transformations. MDSD focuses on the reuseof existing models and supports different transformation chains and tool-ing working on the same model. Changes of the modelling language witheach new purpose of models and related adaptation of their transforma-tions is against this reuse principle. Our goal is to avoid or minimize theseadaptations and support extension of metamodels through introduction ofmodelling pragmatics in a form of completions.MetamodelSource Model Target Model«conforms-to» «conforms-to»Extended MetamodelMetamodel Domain-specificaspectFigure 4.1.: Introduction of new domain-specific aspects to the metamodel by acompletion transformation.Completions increase the expressive power of metamodels indirectly onthe model instance level, thus on the metamodel level the same languageis maintained (cf., Figure 4.1). They add new domain-specific aspects intothe model instance using the same language of the meta-(or abstract-)level,thus they allow an incremental and indirect extension of metamodel throughthe completion transformations. Such domain-specific aspects can be de-scribed by suitable domain-specific languages that introduce new elementsinto the host language and could be later transformed to subsystems con-form to the original host metamodel.954. Variability Management using Higher-Order TransformationsWe express these domain-specific languages in a form of a feature dia-gram. Based on the choice of features from the feature diagram the com-pletion transformation extends the model instance with new aspects fromthe domain described by the feature diagram. Each completion extends themodel by a new concept, that is constructed using existing elements of thehost metamodel. This way, we can bridge different domains. Variability,in this case, means that transformation generates different output models,based on the application domain. Because of the aspect’s configurability,the transformations realising these extensions should be derived automati-cally. We call these transformations completion transformations. The resultis that the applicability of the metamodel increases, using the new meta-model language features supporting abstractions it is easier to create mod-els and the creation of completion transformations is automated.4.1.2. Supporting Transformation VariabilityClassical MDSD approaches face the non-trivial task how to implementtransformations creating target models sharing common core, but differen-tiating by variable parts. Typically, given a fixed source model, there wouldbe one possible target model. In practice, however, different features canbe required. For instance, the design decision whether or not to integrate acertain design pattern (e.g., Thread Pool), could change. Variability, in thiscase, means that transformations generate different output models, basedon additional annotation and/or configuration models passed to the trans-formation. The configuration of the transformation or the transformationitself has to be adapted to integrate different design decisions.Thus, the main challenge to support model completions in MDSD is theirhigh degree of variability. Each implementation detail can have many con-figuration options which may change the structure and behaviour of relatedabstractions. For example, Message-Oriented Middleware (MOM) plat-forms are highly configurable to meet customer needs. The MOM config-964.1. Problem Domainuration includes, for instance, durable subscription or guaranteed delivery.These configuration options influence performance and, thus, have to bemirrored by the transformation that realizes the completion.One solution would be to implement one transformation for each com-bination of configuration options. Another solution would be to attach oneadditional input model to the transformation. The most commonly usedway to configure model transformations is by means of external annotationsto a source model. So called mark models [11] are used to provide config-uration details that are specific to the source model. This mark model isconsidered as an additional input for the transformation on the model level.However, this way of transformation configuration is not always prefer-able. Both solutions have to deal with the problem that a high effort isneeded to implement and to maintain their transformations. Regarding thefirst option, it is straightforward that it is not feasible to implement a trans-formation for each combination of configuration options. Already with 12binary configuration options, (with only boolean value possible) we wouldhave to implement 4096 (or 212) transformation variants. However, eventhe second solution has to deal with many problems. In the case of markmodel usage, the transformation is tightly-coupled to the configuration.Thus, when we want to change configuration options, remove them or tointroduce a new ones, we have to change the transformation itself. Thedeveloper of such a transformation has to consider dependencies betweenconfiguration options, which can become very complex.There are cases where this configuration mostly depends on externallydefined properties (i.e., source model independent) and is not specific tospecial model elements. In this case the configuration happens on a higherlevel of abstraction. Thus, the decision about used variability is made inlater stages (e.g. when transformation is applied) and requires late variabil-ity binding, during so called load time of transformation. Moreover, usedelements (ie. configuration models, transformations, etc.) should supportsoftware developers (i.e., completion users) managing variability. There-974. Variability Management using Higher-Order Transformationsfore, it is much more appropriate to decouple the configuration and theactual model. Starting with the same source model, we can get differenttarget models depending on the configuration. Additionally, there is a needto define the configuration model as reusable construct. The configura-tion model encapsulates domain-specific expert knowledge and as such itwould be beneficial to support its reuse in different contexts. For example,the configuration could be read by other development tools and used inde-pendently from the original software model. Thus, the configuration modelshould be specified on a more generic metamodel-independent level.Additionally, the code of the mark transformation is polluted with codereading and handling the configuration. The configuration managementcode grows with the complexity of configuration into complex decisiontrees. Consequently, using mark models the maintainability of the trans-formations decreases when the configuration model’s complexity grows.Transformations with such complex constructs are not only very hard tomaintain and to understand, but moreover writing a transformation that con-siders all possible combinations of selected configuration options or intro-ducing new configuration option, is very tedious and error-prone. Thus, themaintainability of transformations is one more reason to decouple config-uration model and transformation. In our application domain, the explicitsupport of variability in the definition of completions and their transforma-tions is crucial for their application in software performance engineering.4.2. Introduction of the CHILIES ApproachIn this thesis, we focus on variability management in transformations basedon configuration models. We use feature diagrams to express configura-tions. Transformations can then be based on the very same feature dia-gram to apply the appropriate changes to a model according to currentlyselected features. For this purpose, specific parts of a transformation areactivated depending on the selected features. However, transformations984.2. Introduction of the CHILIES Approachparametrized by configuration require substantial development effort. Inour approach, we allow transformation developers to focus on the actualtransformation logic. They specify transformation fragments for each fea-ture in the configuration model separately. Thus, the development effortis decreased through separation of concerns. Based on the selected com-bination of features, a Higher Order Transformation (HOT) generates thespecific completion transformation. The direct manipulation of transfor-mations depending on a given configuration makes the relation betweenconfiguration and transformation explicit.In the proposed approach, we lift the configuration model to a higher ab-straction level. Therefore, the transformation fragments do not get pollutedwith code that is only responsible for checking the actual feature configura-tion. Furthermore, as the binding of fragments and features is more explicit,this alleviates the complexity of transformation evolution as every featurehas a clear mapping to the parts of the transformation, which are relatedto it. We generate an executable completion transformation from a config-uration defined by a feature diagram in a number of steps. Each of thesepre-processing steps has a specific goal.CHILIES approach defines the pre-processing steps necessary to gener-ate transformations as general patterns that can be composed together tobuild an SPL for transformations. These patterns describe the necessaryelements, such as models and transformations, to achieve particular goals.Composing these patterns, in this work we focus on the Routine, the Com-posite and the Template pattern, we can create an SPL with more complexgoals. Completion transformations are generated based on these patterns.However, we used the CHILIES approach to systematically support vari-ability of completion transformations, completions are only one applica-tion domain and the presented approach could be applied in other contextsas well. The CHILIES approach will be further discussed in the followingsections. We start with summarizing the main contributions in more detail.994. Variability Management using Higher-Order Transformations4.2.1. Scientific Contributions of this ChapterThe main contribution of this chapter is located in the MDSD context andcan be summarised as follows:CHILIES Transformation Variability Management method: SPLsare used to build a family of products, which are subject to vari-ability. Variability should be managed, that is specified, modelledand implemented in a maintainable and effective way. For model-transformations, variability is defined by a varying set of featuresintegrated in the final transformation. Various approaches [71, 167]show that SPLs can be implemented using MDSD techniques. In thisthesis, we created a SPL for model transformations using Higher-Order Transformations (HOTs). Based on the different usage scenar-ios, where HOTs with different goals could be applied, we identifiedbuilding blocks, which can be used to build SPLs for transformations.The SPL for transformations works in combination with feature di-agram and transformation fragments. The transformation fragmentsare selected mirroring the corresponding configuration. The specificsub-contributions are:Higher-order transformation patterns: The used transformationgenerators are written as HOTs that are building blocks of theSPL for transformations. A HOT compiles the transformationmodel again into a transformation model. We used these HOTsas pre-processors, at load time of the transformation (e.g. inMDSPE), executed before the actual transformation. In our ap-proach, we use chains of HOTs where each HOT representsa different pre-processing step. We identified a set of higher-order transformation patterns formalizing different goals for theapplication of HOTs. Based on these patterns, software engi-neers can build pre-processor chains to generate transforma-tions on demand and integrate them into the existing model-1004.2. Introduction of the CHILIES Approachdriven process. By formalising these patterns, we build a frame-work allowing the reuse of HOT specifications. The main ob-jective of our solution is to manage variability efficiently. Com-posing the HOT patterns, we developed an advanced MDSD in-frastructure. Our approach can also be applied to other MDSDinfrastructures with a need to manage variability. We defined aset of usage guidelines and Higher-Order Transformation pat-terns, that are recipes and building blocks for using and buildinga similar infrastructure. Further, we present three patterns as anexample illustrating our approach. The whole set of HOT pat-terns is described in Appendix B. In this chapter, we introduceonly the HOT patterns used to support completions in more de-tail:1. Routine pattern: Our experience with development of com-plex transformations shows that a lot of routine work isneeded to specify usable transformations. To decrease de-velopment effort, we propose a generative method to takethe routine work from developers. We automate genera-tion of routine activities as copying, multiplying elementsor flattening of the models. Using Routine pattern we cangenerate a frame, which in the most cases, only copiesmodel elements. The frame can be then a basis for integrat-ing customisations and creating transformation variants.2. Composite pattern: Today’s transformation languages donot support the composition and reuse of transformationssufficiently. To create a transformation from fragments wehave to compose the relevant fragments and resolve theirdependencies. In this thesis, we introduce an approach fortransformation composition using additional informationprovided by feature diagrams. This approach defines and1014. Variability Management using Higher-Order Transformationsimplements a set of constraints to compose transformationfragments based on their position in a tree structure of fea-ture diagrams.3. Template pattern: Transformations often have a similarstructure differing only in parameter values and applica-tion context. To achieve this, our solution supports mod-ularity by using modular constructs (e.g. templates) asmuch as possible. Furthermore, modularity can improvereusability of transformations. In this thesis, we introducea method for the automated instantiation of transformationtemplates. Additionally, we provide an initial set of trans-formation templates for common transformation parts inthe domain of CBSE.4.2.2. Software Product Lines for TransformationsA Software Product Line (SPL) is a set of systems with well-defined com-monalities and variabilities [37]. The most important aspect of an SPL isthe management of variability. Using the concepts of SPLs, software de-velopers and architects can build a family of products which are subjectto variability. In this thesis, we apply SPLs for transformations to com-pletions in the domain of component-based software software engineering.Although the injection of completions into the model is straightforward, thedevelopment of the completion transformation is an non-trivial task. Thetransformations depend on the configurations and, therefore, are subject tothe variability themselves.To provide variability support in transformation definitions, we studiedthe design of SPLs. In our approach, we introduce a variability modellingconcept for model transformations. We create an SPL for transformationsthat generates variants of model transformations, for example, comple-tion transformations as illustrated in Figure 4.2. The SPL for transfor-1024.2. Introduction of the CHILIES Approachmations is used to generate completion transformations executed in thehorizontal direction of the Model Completion concept. The goal is tofully automate the transformation generation. The SPL reads configura-tions (Con f ig1, ...,Con f igN) and generates the required transformations.The configuration of the variable parts determines the transformation to begenerated and, thus, the product. The illustrated approach provides method-ologies to capture and reuse the common parts of transformations and alsoprovide techniques to manage the variable parts of a transformation.The process of building an SPL consists of two phases: domain engi-neering and software engineering [37]. These phases can be mapped to thetasks of the roles Completion Developer and Completion User introducedin Chapter 3.3. In the domain engineering phase, all the common parts ofa transformation are identified and implemented. Additionally, models thatdescribe the variable parts (in our approach feature models and feature ef-fects) and their relations are created. These models represent the variableparts of a (completion) transformation. The development of transforma-tions has to be done systematically, with the focus on their reusability. Inthe case of completion transformations encapsulate domain knowledge thatcan be (re)used in different contexts. This means that the developed trans-formations have to be generic and independent from an input model. In thesoftware engineering phase, the transformations (which have been createdduring the domain engineering phase) are selected, configured and appliedto a software system.The CHILIES approach realises an SPL for model transformations usingMDSD technologies. MDSD is one approach to cope with the challenges ofproduct line engineering [123]. We propose HOTs as generally applicablevariability modelling concept for transformations. The combined conceptsof SPL and MDSD enable the automated generation of customizable trans-formations. Our SPL built with MDSD technologies is a sequence of HOTseach of which addresses a different part of the transformation generationprocess (e.g., generating a copy transformation that is extended by other1034. Variability Management using Higher-Order TransformationsAbsConcAbs‘completiontransformation Abs‘‘completiontransformationConc‘ Conc‘‘annotate Config1 Config2 ConfigNrefine refine refine refinerefinerefineSPL for transformationsannotate readreadgenerategenerate[...]Model Completion readannotate Figure 4.2.: SPL for model transformations generating completion transformations.HOTs). The transformation sequence, and its elements (ie. models andmeta models) can be regarded as a software platform. A family of productscan be automatically generated using different customizations. In this sce-nario, the product of our SPL is again a transformation. The Higher-OrderTransformation Patterns (described in Section 4.3) give further insights intothe implementation of our SPL for transformation development.4.2.3. Transformation VariabilityVariability is one of the core aspects of Software Product Lines. In thecontext of SPLs for transformations, we can distinguish different types ofvariability. In this section, we discuss the relevant variability types and theirmanifestation in transformations.Specifying variability Transformations of one family of products usu-ally have many common parts, although they can carry significant differ-1044.2. Introduction of the CHILIES Approachences. Typically, these differences define the variation points. We under-stand variant and variation point as follows:Definition 9 Variant and Variation PointOne variation choice, defined by one configuration instance, is called vari-ant. A group of all possible product variants defines a variation point.In the running example described in Section 3.3.1, one variant is a staticThread pool with a pool size of 32 threads, defined by the feature config-uration shown in Figure 3.16. We use the concept and notation of featurediagrams to model variation points and corresponding feature configura-tions to specify variants. The resulting model can include more than onevariant that origin from the same (in different location in model) or differ-ent variation points. The syntax and semantics of the used feature diagramsis specified by a metamodel that is introduced in Section 4.5.2.1.Feature diagrams allow an independent definition of variability. In largedevelopment projects, the complexity of variability can easily overwhelmdevelopers. The benefit of using a separate definition of variability is clearlyvisible in such projects. A feature diagram-based definition of variabilityin a form of a tree allows to, when necessary, hide a variation point or divein a variation point and implement it in separation. Thus, developers canwork on the system using different views on the system with the requiredlevel of detail. The implementation of the selected feature configurationsis then realized automatically as a transformation or generator that expandsall the required details and their configurations in the target model.Moreover, by using feature diagrams we allow easy configuration of vari-ants, by choosing from several configuration alternatives. Constraints be-tween the alternatives limit the choices to valid combinations. Such vari-ability specification is simple and easy to use. Transformation developersdo not need to learn complex formalisms, they simply select a set of op-tions.1054. Variability Management using Higher-Order TransformationsCharacteristics of Variability The type of variability considered inthis thesis is source model independent and source metamodel dependent.Source model independent means that the feature effects are only definingmapping between the feature and the realisation of this feature by elementsconform to the source metamodel. Thus, there is no mapping needed be-tween the feature effect and the source model. The realisation of featureeffects is source model independent. However, feature effects are appliedto and transform elements of the source metamodel. As such, feature ef-fects depend on the source metamodel.Variability of Completions In the previous chapter, we discussed per-formance completions. The variability of completion manifests as follows(cf., Figure 4.3): (i) in completions many configuration options have pa-rameters (P1,P2) that can be varied. Precisely, the parameters are stored infeature effects of the feature diagram. One part variability implementationis resolving these parametrisations. A variant is constructed by providingvalues (V 1) to these parameters (e.g., Pool:size=32). This variability islimited only on the locations where the parameters are defined.In the next step (ii) the annotated (or other relevant) model element(called pivot element) from the source model is removed and on its placeis the required detailed model subsystem (e.g., completion instance) in-jected. The completion instance is composed from resolved feature effects(black triangles in Figure 4.3), corresponding the feature configuration. Thefeature effects are illustrated in Figure 4.3 by triangles with parameters(P1,P2) and as composed triangles with resolved parameters (V 1) in thetarget model.The feature effects correspond to the elements (e.g. component, con-nectors), that are defined by the used metamodel and could be instantiatedinto a model. The implementation of the model-to-model transformationrealizing this correspondence is implemented in declarative transformationlanguage QVT-Relations. A feature model defines the variation point. A1064.2. Introduction of the CHILIES ApproachFeatureeffectspivotelementTarget ModelV1annotatesConfigurationP2P1Source ModelCompletionInstanceFigure 4.3.: Variability implementation with configuration.feature configuration is a driver of the transformation and defines one vari-ant.4.2.4. FormalisationThis section captures the idea of variable transformations for model com-pletions formally. We formalize the essential terms of the completion con-cept beginning with definition of models, transformations and transforma-tion chains. Based on these initial definitions, we introduce a formalisationof model completions and completion transformations.4.2.4.1. Basic TermsModels and Metamodels: Let MM be a metamodel, expressed as an in-stance of some meta-metamodel MMM. For example, the PCM metamodelis an EMOF instance. An instance of the metamodel is a model definedas M. Then the set of all valid model instances that are conform to thismetamodel MM is defined as follows:con f (MM) = {M|M is conform to MM}Applied to the PCM, this definition allows to specify a valid model conformto the PCM metamodel as M ∈ con f (PCM), where PCM ∈ con f (EMOF).1074. Variability Management using Higher-Order TransformationsModel Transformations: Let t be a function, which maps an instanceof a source metamodel MMS to an instance of the target metamodel MMT :t : con f (MMS)→ con f (MMT ), where ∀MT ∈ con f (MMT )⇒∃MS ∈ con f (MMS)t(MS) = MTFor example, consider a transformation:tPCM2SOFA : con f (PCM)→ con f (SOFA)tPCM2SOFA maps instances of the PCM to instances of SOFA metamodel.Model Completion: Let c be a function, which is a left-total relation,thus every source model is associated with one or more target models.Thus, c maps instances of a source metamodel MS ∈ con f (MMS) to a setof target models (P), which are instances of the target metamodel MT ∈con f (MMT ):c : con f (MMS)→ P(con f (MMT ))In the following, we specify the applied completion by the description cabove the transition arrow (c→).The exact target domain of the completion is defined by its purpose. Inthe following, we understand source model MS as a set of model elements(i.e., links between elements and attributes are transformed implicitly). Thedefinition of completion does not force c to map every element of MS to anelement (or number of elements) of MT . Therefore, we can define a sourcemodel M′S as a subset of MS that is mapped to MT .Functions mapping only a subset of the source model are called partialfunctions, which allow to specify relations between two domains. More-over, starting with the same source model and using two different comple-tions (or only two different configurations of one completion) the trans-1084.2. Introduction of the CHILIES Approachformation can result in two different targets. However, such completiondefinition is not enough to support the implementation of our completion-based processes. To support such processes, we it has to be possible tomap every model MT to at most one model MS. Thus, we need additionalvariability specification. Therefore in the following, we define a suitablevariation specification allowing unambiguous definition of completions.Completion Specifics: In case of completions, the source model MS andthe target model MT are instances of the same metamodel (MMS = MMT ):MS ∈ con f (MM) ∧ MT ∈ con f (MM)Thus, the relation between source and target model is (i) reflexive (MSc→MS), when for c was any pivot element identified; (ii) asymmetric (MSc→MT MTc→MS), for each c; and (iii) transitive (MS ci→MT1 ∧MT1c j→MT2 ⇒MSci j→ MT2 ), for ci = c j ∧ ci j = ci ◦ c j (where ’◦’ defines a composition oftransformation in a sequence). Such a relation is called partial order andformalizes the intuitive concept of ordering, sequencing, and arrangementof the elements in a set of completions. We discuss sequences of comple-tions in Chapter 5.Further, we focus on the definition of the completions and the variabilityin the completion transformation ("c"). The goal is to define completiontransformations that associate one, and only one, target to any particularinput.4.2.4.2. Variability ManagementVariation Points and Variations: In this thesis, we deal with variabilitywhere, for a given fixed source model MS and a transformation t, a finiteset of possible variants v should be derivable. A set of all possible variantsP(V ) of one variation point V is defined as:V = {v|v ∈ con f (MMT )}1094. Variability Management using Higher-Order TransformationsIn the completion approach, one completion c defines at least one varia-tion point (a completion can define multiple variation points in one softwarearchitecture). All possible variation points are members of C = {ci|i ∈ I}.The set C denotes a finite set of available completions, called completionlibrary. Furthermore, the set Vi with i ∈ I:Vi ⊆ {v ji | j ∈ J}denotes a countable set of possible variants for one completion ci.To continue with our example, the variation point defined by completioncT hreadManagement isVT hreadManagement = {vT PstaticT hreadManagement ,vT PdynamicT hreadManagement ,vT hreadPerRequestT hreadManagement ,vSingleBackgroundT hreadT hreadManagement }Variant Composition: In the following, we use an operator to specifythe variant composition. The operator introduces variants into any sourcemodel and weaves model elements defined by the completion variant intothe source model. The semantics of the operator are represented by therelationship that exists between the variant model and the source model.More formally the semantics of operator is defined as follows: : con f (MMS)×P(V )⇒ MT ,whereMT ⊆ con f (MMT ).Variation Implementation: Each v ji can be implemented as a transfor-mation that realises the variant composition and constructs one variant ofMS ∈ con f (MMS) by weaving an instance (v ji ) of variation point ci:t : con f (MMS)ci→ con f (MMT ) : con f (MMS) v ji1104.2. Introduction of the CHILIES ApproachApplying one variation of a completion, e.g. cT hreadManagement , resultsin a composition of the source model and the configured variant, e.g.vT PstaticcT hreadManagement .Each variant of a completion could be applied to a number of elementsin the source model. The pivot element defines a type of model element thecompletion can be applied to. Applied to the PCM, this definition allows tospecify, for example, completions applicable to connectors, components orresource containers (also called infrastructure).Model Elements: As the application domain of our approach is CBSE,we identified possible pivot elements. Let E = Ecomp ∪Econn ∪Ein f ra bethe set of model elements (identified in the source model) of three types:components, connectors and infrastructures, respectively. Each of the setsis finite (possibly empty). Each ci can be applied to a model element e ∈ Es,where s = comp,conn, in f ra, and realise necessary model changes untilvariant v ji reached. If vji is again a set of valid model elements (which doesnot need to be the case), e is removed and replaced with v ji in E.Since t is a function, which has at most one corresponding result inthe target domain per element in the source domain, more parameters areneeded to be able unambiguous generation of the result. This yields anidea to extend the function t so that it would accept an additional input of,i.e., the configuration model. We use feature diagrams as configurationmodel. Thus, the additional input is f d ∈ FD, where FD is a set of fea-ture diagrams. Each completion is then defined as a tuple of the metamodelelement type e (so called pivot element), and a feature diagram f d:ci = (e, f di)A feature diagram defines a configuration metamodel, for example,f dT hreadManagement is a metamodel for the domain of cT hreadManagement , itsinstance is a specific configuration f c ∈ con f ( f dT hreadManagement) (e.g.,which defines one variant vT Pstatic ). The f dT hreadManagement itself is an in-1114. Variability Management using Higher-Order Transformationsstance of a metamodel for feature diagrams MMFD, f dT hreadManagement ∈con f (MMFD).Variability management with a Mark Transformation: One option tosupport variability, transformations can be parametrised by a configurationmodel. Such transformations are called mark transformations as explainedin Chapter 2. We formalise mark transformations as follows. Let tM be atransformation, which maps an instance of a source metamodel MMS and aninstance of a configuration metamodel MMC f g (e.g. metamodel of featurediagrams) to an instance of the target metamodel MMT :tM : con f (MMS)× con f (MMC f g)→ con f (MMT )Thus, for one source model MS ∈ con f (MMS) and one configuration in-stance MC f g ∈ con f (MMC f g) the transformation tM derives one target modelMT ∈ con f (MMT ).For example, consider a transformation:tMPCMT hreadMng : con f (PCM)× con f ( f dT hreadManagement)→ con f (PCM)mapping instances of the PCM and a Thread Pool configuration to new in-stances of the PCM. The transformation takes T hreadManagement-specificaspects as configuration.Because the mark transformations depend on the mark model and thesource model, the transformations have to implement a mapping for eachpossible configuration. To reduce the complexity of mark transformationswe use higher-order transformations introduced in the following.Higher-Order Transformation A higher-order transformation tHOT is atransformation whose target and/or source model are again transformations.Thus, in general tHOT maps an instance of a transformation metamodelMMTrans f to an instance of the transformation metamodel MMTrans f :tHOTGeneral : con f (MMTrans f )→ con f (MMTrans f )1124.2. Introduction of the CHILIES ApproachThis type of transformations is especially useful for transformation manip-ulations, such as modification, insertion or merges. In the case of com-pletions, we generate the completion transformation from the configurationmodel. Thus, tHOT maps an instance of a configuration metamodel MMC f gto an instance of the transformation metamodel MMTrans f :tHOT : con f (MMC f g)→ con f (MMTrans f )Variability management with a Completion Transformation: Let tCbe a completion transformation, which maps an instance of a source meta-model MMS and applies completion c to it. The target model is an instanceof the target metamodel MMT . The tC transformation is created by a higher-order transformation tHOT . The transformation tHOT maps an instance of aconfiguration metamodel MMC f g to an instance of the target metamodel, inthis case it is a transformation metamodel MMTrans f and generates requiredcompletion transformation tC:tHOT : con f (MMC f g)→ tC, where tC ∈ con f (MMTrans f )tC : con f (MMS)c→ con f (MMT )Thus, for one configuration model MMC f g the higher-order transformationtHOT derives one transformation variant tC.For example, consider a transformation:tHOT : f dT hreadManagement → tcPCMT hreadManagementtcPCMT hreadManagement : con f (PCM)cPCMT hreadManagement→ con f (PCM)mapping instances of the PCM to instances of PCM metamodel. The trans-formation tcPCMT hreadManagement is generated already considering thef dT hreadManagement and its configuration. The transformation implementsonly chosen the T hreadManagement-specific aspects and description how1134. Variability Management using Higher-Order Transformationsto instantiate these aspects in resulting PCM models. The configurationinstance of f dT hreadManagement is used to generate tCT hreadManagement .Now, we can define a completion transformation as follows. Each variantv ji ∈ Vi (defined by an instance of a configuration metamodel MMC f g) canbe implemented by a completion transformation:tciv ji: con f (MMS)v ji→ con f (MMS)constructing a one variant of MS (MS vji ) using variation point ci.4.2.4.3. Transformation ChainsIn this section, we discuss sequences of transformations, that represent anordered chain of model-to-model transformations. We focus on sequencesof higher-order transformations that build a software product line for trans-formations. Sequences of completion transformations are discussed inChapter 5.Chains of Transformations: Are ordered set of transformations ti. Theti transformations are executed sequentially with t1 being the first and tnbeing the last transformation. The source model of transformation ti isMS =Mi ∈ con f (MMi) and the target model is MT =Mi+1 ∈ con f (MMi+1):ti : con f (MMi)→ con f (MMi+1)The chain of transformations t∗ is then executed as follows:t∗ : con f (MMi)ti→ con f (MMi+1) ti+1→ ·· · tn→ con f (MMn+1)Chains of Higher-Order Transformations (HOTs) An example of aclassical chain of transformations is a chain of higher-order transforma-tions t∗HOT . Let THOT be an ordered set of HOTs. Similarly as chains ofclassical model transformations, the members of the HOT chain generate a1144.3. CHILIES: Higher-Order Transformation Patternsmodel, which is then input to the next HOT transformation. In the case ofcompletions, we express t∗HOT as follows:t∗HOT : con f (MMTrans fi)→ con f (MMTrans fi+1) · · · → con f (MMTrans fn+1),In the completion approach HOTs take as an input model a configurationmodel con f (MMC f g) or a transformation con f (MMTrans f ), or even a meta-model MM ∈ con f (MMM) could be an input for a HOT. These HOTs arethen executed sequentially to derive the required completion transforma-tion. We introduce the HOT chain in the following sections.4.3. CHILIES: Higher-Order Transformation PatternsWith the growing trust in MDSD, projects of greater complexity and sizeare developed based on the model-driven paradigm. Since the technologyfor executing transformations, especially written in high-level, declarativetransformation languages, is of very recent date, there is very little knowl-edge available on how to write such transformations (see Chapter 8).As mentioned above the goal of this chapter is to provide software devel-opers with an automated method to manage variability in transformations.We assume that developers have identified possible variation points relevantfor their goal (e.g. performance prediction). Starting with these variationpoints, we aim to generate the corresponding transformation variants real-ising the related design decisions. For this purpose, we build an SPL fortransformations from building blocks called HOT patterns. These patternsare reusable in different contexts and for different MDSD projects. TheHOT patterns define a body of knowledge on transformation engineeringand they introduce a number of useful guidelines for generation of com-plex transformations.1154. Variability Management using Higher-Order Transformations4.3.1. MotivationPrinciples for the development of model transformations are crucial for thesuccess of MDSD. The importance of model transformations is compara-ble to the importance of compilers for high-level programming languages.The development of transformations currently takes place on a low-level ofabstraction, lacking appropriate reuse mechanisms. The support of largetransformation scenarios is still missing [171, 153], since the methods, pat-terns, and building blocks for their development are not available.The young field of transformation engineering needs principles for reuseand modularity similar as for classical programming languages. StructuredProgramming was introduced as a means to facilitate reuse, maintainabil-ity, and to ease understanding. Similarly, most transformation languagesprovide language constructs to define modules, many of them even sup-port rule inheritance. Meta-programming is a programming paradigm withthe intend to write highly complex programs concisely by implementingsoftware on a higher level of abstraction. Model-driven engineering isstrongly related to meta-programming [9]. Meta-programming is aboutwriting programs operating on programs as first-class entities, and model-driven engineering is about modelling transformations which operate onmodels as first-class entities. The same fact accounts to Generative Pro-gramming, where configurable generators are build capable of creating pro-grams within one specific domain. Today’s MDSD paradigm embodiesmany ideas of Generative Programming. Domain Engineering, or ProductLine Engineering is a process to systematically reuse domain knowledge,with the objective of factoring out shared assets of a family of systems.In more complex scenarios transformations can be specialized more thanonce, for instance as more purpose-specific information becomes available.This specialization can happen at different stages through the lifetime of atransformation. Subsequently, the transformation should create a substan-tial part of the final software product. Often the parts of the software are1164.3. CHILIES: Higher-Order Transformation Patternsexpressed in a domain-specific language (DSL) that is better suited to theproblem at hand than a general purpose programming language. The us-age of DSL’s promises a shorter time-to-market, higher quality, reusability,maintainability, portability, and interoperability. The reason is especiallythe encapsulation of domain knowledge and improved communication withdomain experts through DSLs. A shift of knowledge is observable, as moreand more logic is implemented in transformations (Chapter 8). With largerprojects, developers not only have to face larger models, but also transfor-mations of higher complexity.One way to cope with the aforementioned challenges is to apply theideas of model-driven engineering to its own artefacts again. This imme-diately leads us to raising the abstraction level even further with Higher-Order-Transformations (HOTs), i.e. transformations which operate ontransformation(-model)s. The required transformations are generated andmanipulated by a HOT. This generation results in a more efficient trans-formation code and generation overhead is minimal. Generated code canbe involved in further transformation generation and can itself generatetransformations, providing full multi stage capabilities.4.3.2. Higher-Order TransformationsTransformations are an integral part of the developed system as first-classelements of the model-driven architecture. As such, they can be themselvesgenerated and handled by MDSD, exactly like traditional programs. Thisallows reusing MDSD tools and methods to generate new one (since trans-formations of transformations can be transformed themselves). A wide setof applications for such technologies appeared involving transformationsin the roles of both manipulating program and manipulated object. Suchtransformations are called Higher-Order Transformations (HOTs). We de-fine HOTs as follows:1174. Variability Management using Higher-Order TransformationsDefinition 10 Higher-Order TransformationsA Higher-Order Transformation is a model transformation manipulating orgenerating transformation models. The input and/or output models of suchtransformation are again transformations models.In the recent past, a number of approaches appeared where HOTs areincorporated as a means to solve various problems in the model-driven do-main [161, 158, 68]. Many application scenarios for HOTs explained inthese papers are based on similar patterns. Classifying all these scenariosin a precise manner can, first of all, help to find new patterns, for exampleby improving, synthesising, abstracting or refining existing ones. Further-more, it can also help to detect shortcomings of transformation languages.Last but not least, a set of scenarios can help designers incorporating HOTtechniques in future MDE architectures. Initial contributions [158] in thisarea classify HOTs according to different categories such as synthesis, anal-ysis, etc. However, these patterns build only very low-level primitives anda deeper insight into the area of application as well as practical experi-ences with complex generator structures are not gathered, yet. Examplesof such applications are synthesis of transformations from a source otheras transformation, as applied in [68]. Other applications are analyses oftransformations, as well as modification and composition of transformationfrom a number of input transformations.In this section, we present a set of Higher-Order Transformation Patterns(HOT patterns) for transformation generation that allow manipulating andgenerating transformations on lower levels of abstraction. These patternsrealise more complex goals and are solutions to reoccurring problems intransformation engineering. In our implementation, the transformation ma-nipulation primitives are provided through a library of patterns rather thanas a language extension, allowing a more robust and maintainable approachthan language extensions. The HOT patterns foster reuse and abstractionallowing for larger transformation scenarios and better overview over com-1184.3. CHILIES: Higher-Order Transformation Patternsplex model-driven systems. Moreover, we provide an implementation ofthese patterns to realise Model Completions, which serve as an applicationscenario for the HOT patterns. We realize the Model Completion approachcomposing together three of the HOT patterns. Additional HOT patternsidentified during our work can be found in Appendix B. These patternsencapsulate our experience with the application of HOTs.4.3.3. NotationIn [158], Tisi et al. give a valuable overview on application scenarios forHOTs. Their paper proposes a coarse classification of HOTs into what theycall base patterns. Base patterns make applications of HOTs distinguish-able by the types and characteristics of their input and output models. Thefour base patterns are synthesis, analysis, composition, and modification.At least one input model or one output model needs to be a transforma-tion model, otherwise we are dealing with ordinary transformations. Weconsider these patterns as basic primitives and we classify our scenariosrepresenting more complex patterns according to these primitives.(a) Synthesis (b) Analysis (c) Composition(d) ModificationFigure 4.4.: Patterns of higher-order transformations (according to [158]).1194. Variability Management using Higher-Order TransformationsFigure 4.4 illustrates all four patterns following Yourdon & Coad’s no-tation [38] of data flow diagrams (DFDs), displaying models as externalentities (rectangles) and transformations as processes (circles). We use thesame notation to illustrate HOT patterns. Thus, a transformation model,being a model (rectangle) and a transformation/process (circle) at the sametime, is depicted as a circle surrounded by a rectangle.To document the HOT patterns, we use a fixed notation inspired byGamma et al. [59], consisting of the following elements: the name ofthe pattern, motivation for the pattern including the class of problems thatthe pattern solves, specification of the solution using the QVT Relationslanguage including implementation details and discussion of benefits anddrawbacks regarding the pattern’s applicability.4.4. Routine HOT PatternTransformation developers often have to implement repeatedly functional-ity, such as copy routines, multiplying, referencing, mappings, markingsor flattening of models. However, many transformation languages (e.g.,QVT-R, ATL) lack support for such default rules. Thus, transformation de-velopers need to define these rules explicitly. It is a significant amount ofwork particularly for completion transformations which, for example, copylarge parts of a model. We propose a generator pattern to derive genericrules for given metamodels.4.4.1. DefinitionName: Routine HOT patternMotivation: Writing a model-to-model transformation can be a tedioustask. Our experience with development of complex transformations showsthat a lot of routine work is needed to specify usable transformations. Mosttransformations contain certain routine principles that frequently occur.1204.4. Routine HOT PatternOnly after implementing these routine parts, it is possible to realise theinitial goal of the transformation. More specifically, to implement modelcustomisation, we first have to copy the necessary model elements beforeintegrating customisations. Although in-place transformations are usefulto describe this type of model changes, there are several reasons to preferthe creation of a new models. First, in some scenarios, the source modelneeds to be preserved. For example, in MDSPE developers typically usethe source model for a wide range of purposes, this source model offers ahighly-abstract view on the system, which is crucial to allow experts fromdifferent domains to work with this model. Moreover, the customisationsof this model need to be propagated to the different purpose-specific mod-els. Thus, starting with the same source model we have to create differentpurpose-specific and customised target models. As consequence, the tracesbetween source model and target model become more explicit. Finally, weare not restricted to endogenous transformations (i.e., transformations withthe source and target model in the same language), as in-place transforma-tion are. In such scenarios, we can not avoid routine copies (or mappings)of model elements. To alleviate from this issue, the Routine pattern takesadvantage of the fact that the metamodel is also a model at the same time.Thus, from the metamodel as input the HOT generates a transformation thatcreates a required model, for example an exact copy of a given instance ofthat metamodel.To decrease development effort, we propose a generative method to takeaway the routine work from developers. We automate the generation of rou-tine activities such as copying, multiplying elements or flattening of mod-els. Using the Routine pattern we can generate a frame, which in mostcases only copies model elements. This frame can then be used as a basisto integrate customisations and create transformation variants.Specification of the Routine pattern was motivated by the need to im-plement a set of frequently occurring patterns in transformations. The ba-sic transformation patterns (Mapping, Refinement, Abstraction, Duality and1214. Variability Management using Higher-Order TransformationsFlattening) that frequently occur in model-to-model transformations wereintroduced by Iacob, Steen and Heerink in [87]. The patterns Mapping, Ab-straction, Flattening are typical applications for the HOT Routine pattern.Model transformations realising these patterns do not introduce new seman-tic or duality to the model instances and, therefore, they can be synthesisedfor any metamodel language without any additional expert knowledge. Pat-terns such as Refinement or Duality require additional information about thesemantic of the target model and as such they can not be generated simplyfrom the metamodel. The additional patterns (identified by us), which suitas very fortunate application scenarios, are Copying or Marking. For thecreation of the transformation frame, that is basis for the customisation oftransformations, the last two patterns are especially important, therefore wefocus on these patterns in a more detail (see Section 4.4.2).MAPPING: The goal of this pattern is to establish a one-to-one rela-tions between elements from the source model and elements from the targetmodel. Mapping is used when the source and target models are conform todifferent metamodels. This pattern is the only one assuming that the sourceand target metamodel are not equal. As such this pattern as only one re-quires additional mapping model that specifies the mapping between twometamodel languages. Because of the intuitive importance of this base pat-tern it is the most implemented pattern in existing MDSD tools. Most ofthe tools, for example [111, 90], require to specify the mapping model us-ing a graphical user interface. Based on the resulting mapping model atransformation is generated. This transformation then maps any instance ofthe source metamodel to a corresponding instance of the target metamodel.The generated mapping rules are specified as follows:1 top relation XYMapping {2 nm: String ;3 enforce domain source x: X {context = c1: XContext {}, name = nm};4 enforce domain target y: Y {context = c2: YContext {}, name = nm};5 when {ContextMapping(c1,c2);}6 }1224.4. Routine HOT PatternListing 4.1: Mapping transformation rule (based on [87]).This bidirectional mapping specifies that some element x of type X is re-lated to some element y of type Y, when their parent contexts are relatedas defined by another mapping relation ContextMapping and their namesare equal. For example, using this pattern we can map a BasicComponentdefined in the PCM metamodel to a Component defined in the SOFA meta-model using this base pattern. Thus, we can translate any model in onesyntax (e.g., PCM) into another syntax (e.g., SOFA) using mapping trans-formations.In the following, it is assumed that the source and target model are con-form to the same metamodel, i.e. we implement endogenous transforma-tions. Thus, the generated transformations would be a modifier of the modelinstances to fulfil a particular goal.ABSTRACTION: This pattern abstracts from model elements in the sourcemodel while keeping the incidence relations of its model elements [87] and,thus, from specific information in the models. The abstraction pattern can,for example, be used to remove subtypes that carry additional informationfrom a model. In a meta-model for component-based software architecture,we can, for example, remove the distinction between basic componentsand composite components which both are specialisations of components.The generalised abstraction rule, where X is a subtype of abstract typeModelElement, is specified as follows:1 top relation XAbstraction {2 checkonly domain source x: X {3 inIncidence = in : Incidence { name = nm_in: String , source = ss1:ModelElement{}},4 outIncidence = out : Incidence { name = nm_out: String , target = tt1 :ModelElement{}}};5 enforce domain target e: ModelElement {6 name = nm_in + nm_out, source = ss2:ModelElement{}, target = tt2 :ModelElement{}};7 when {Mapping(ss1 , ss2);Mapping( tt1 , tt2)}8 }Listing 4.2: Abstraction transformation rule (based on [87]).1234. Variability Management using Higher-Order TransformationsFLATTENING: This pattern removes the hierarchy from the source model.The reason to create hierarchical models is usually the understandability ofthe models, however, in order to generate code based on such models orformally analyse them it may be necessary to flatten the model. For ex-ample, in component-based models ComposedComponents contain a set ofBasicComponents. All the components are either BasicComponents orComposedComponents. The goal of the flattening pattern is to create mod-els only containing BasicComponents, removing the model’s hierarchy.The generalised flattening rule is specified as follows:1 top relation XFlattening{2 checkonly domain source c_x: Composite_X {context = c: Composite_Context {}};3 enforce domain target x: X {};4 when {XMapping(c ,x) or XFlattening(c ,x);}5 }67 top relation XMapping{8 nm:String ;9 checkonly domain source x1: X {name = nm, context = c1: Context {}};10 enforce domain target x2: X {name = nm, context = c2: Context {}};11 when {XMapping(c1,c2) or XFlattening(c1,c2);}12 }Listing 4.3: Flattening transformation rule (based on [87]).The transformation strategy is to map all the Composite_X elementsto the simple X elements in the target model. The relation is created byXMapping or XFlattening when the context was composite itself.COPYING AND MARKING: The Model Copier pattern introduces meansto overcome the lacking support for in-place transformation and a copy op-erator in QVT Relations (QVT-R). Such transformations keep most modelelements as they are while adding, removing or modifying only specific en-tities. QVT-R does not support a way to easily create such transformationsas there is no in-place transformation or copy operator available.QVT-R does not support default copies. In contrast to QVT-R, QVTOperational Mappings (QVT-O) provides a deep copy operation that canbe used within imperative mapping rules. The Atlas Transformation Lan-1244.4. Routine HOT Patternguage (ATL) even supports a special mode that allows the transformationprogrammer to specify that a transformation should be run as a refinementtransformation. This means that all elements are copied by default whilethose elements that are matched by transformation rules within the actualtransformation are not. Triple Graph Grammars (TGG) [144] naturally sup-port in-place transformations. To be able to implement refinement scenar-ios with QVT-R more efficiently we introduced the automated creation of adefault copy transformation using the Routine pattern. The generated copyand marker rules are specified as follows:1 top relation XCopy{2 checkonly domain source x: X {name = nm, context = c: Context {}};3 enforce domain target copied_x: X {name = nm, context = copied_c: Context {}};4 where {XMark(x,copied_x);5 ContextMark(c ,copied_c);}6 }78 relation XMark{9 checkonly domain source x: X {};10 checkonly domain target copied_x: X {};11 }Listing 4.4: Copy and Marker transformation rules (based on [68]).The first relation in the Listing 4.4 is a copy relation, which simplymatches an instance of required type in the source model and enforces (i.e.,creates) a corresponding instance of this type in the target model. It isa top relation and as such is applied to every instance of this type in thesource model. In the where clause of this relation, a so-called the markerrelation is called. A marker relation is a non-top relation that can only becalled from the where clause of a copy rule after the particular element wascopied. By this principle, marker relations indicates which elements havealready been copied.Implementation: The base patterns introduced above can be used tospecify a routine transformation for an arbitrary metamodel. The patterns1254. Variability Management using Higher-Order Transformationsare generic with respect to the metamodel and therefore they can be di-rectly generated from a given metamodel. In this section, we investigatethe structure of the model-driven generator and its used elements (models,metamodels and transformations). Figure 4.5 illustrates the implementationof the generator. Figure 4.5(a) shows the case where the source and the tar-get metamodel are not equal. In this case, we may need an additional map-ping model Map to implement the mapping pattern. Figure 4.5(b) showsthe setting when the source and target metamodel are equal. In this case,the only input for the HOT is the metamodel. Based on the metamodel, wecan generate a copy transformation that serves as a frame for later, morecomplex transformations..outputM1 M2THOT MM2«conforms-to»«conforms-to»MM1input inputinputMap(a) Routine with non-equalsource and target metamodeloutputM MTHOT«conforms-to»«conforms-to»MMinputMetamodel levelModel level(b) Routine with equal source and targetmetamodelFigure 4.5.: Routine HOT pattern.To implement the copy and mark pattern, the HOT generates a copytransformation from a metamodel as follows (cf. Figure 4.5): First, theHOT creates one rule for each metaclass which copies the respective in-stance model element and another helper rule marking it as copied. Copy1264.4. Routine HOT Patternrules use marker rules [88] to ensuring exactly one copy. Accordingly, theHOT creates similar rules for attributes and relations.Once the copy transformation exists, we need a mechanism to overriderules for elements which should be left out (i.e. deleted), added, or modifiedfor the implementation of a transformation. Transformation engineers candeclare such rules separately or weave them into the transformation defin-ing the copy rules using another HOT. Alternatively, it is possible to useQVT-R’s native rule overriding mechanism.Benefits and Drawbacks: The routine pattern takes the developmenteffort from developers and automates the generation of frequently usedtransformation frames. By implementing the abstraction or flattening pat-terns, we can provide model versions with different levels of abstraction.Developers can use these transformations to prepare their models for anal-ysis or code generation.The most significant benefit is the incrementability. As the metamodelevolves and new entities are introduced HOTs can incrementally add rou-tine rules and, thus, keep transformations up to date. If necessary, trans-formation engineers can adapt the generated transformation in an iterativeway. Traceability, originally provided by the underlying language frame-work, can be utilised in a beneficial way to support any subsequent cus-tomisation process: the trace model of the HOT is able to indicate thoseparts that did change since the last run.Although, throughout this thesis, we use routine pattern only to generatecopy rules, this pattern is applicable to derive other rule types too.4.4.2. Completions Support: Generation of a RoutineTransformation FrameThe completion transformations copy large parts of a source model, this isa tremendous task. Since QVT Relations does not support default copies,a completion definition needs to specify copies explicitly. In this section,1274. Variability Management using Higher-Order Transformationswe investigate copies in QVT Relations. First, we use the generic patternsfor copy rules. Second, we provide a way to generate the definition of acopy transformation for a given metamodel. The generation is specified asa higher-order transformation. Finally, we explore several ways to derive acompletion from a generated copy transformation.1 transformation Ecore2copyQVT (mm: ecore , oclstdlib : ecore , qvt : QVTRelation) {2 top relation Package2Transformation {3 n:String ;4 checkonly domain mm ePackage: ecore : :EPackage {5 name = n6 };78 enforce domain qvt t : QVTRelation: : RelationalTransformation {9 name = ’Copy’ + n,10 modelParameter = sourceMM: QVTBase: :TypedModel {11 name = ’source’ ,12 usedPackage = uPackage: ecore : :EPackage{}13 },14 modelParameter = targetMM: QVTBase: :TypedModel {15 name = ’target ’ ,16 usedPackage = uPackage: ecore : :EPackage{}17 }18 };19 when {20 ePackage.eContainer ( ) .oclIsUndefined() ;21 }22 where {23 uPackage = ePackage;24 MarkTypedModel(sourceMM, targetMM);25 MarkTransformation( t ) ;26 }27 }2829 relation MarkTypedModel { . . . }30 relation MarkTransformation { . . . }3132 top relation Class2CopyRelation { . . . }33 top relation SubClass2MarkerCallInWhen { . . . }3435 top relation Class2MarkerRelation { . . . }36 top relation Attribute2Relation { . . . }37 top relation Reference2Relation { . . . }38 top relation ExternalReference2Relation { . . . }1284.4. Routine HOT Pattern39 top relation MarkBooleanType { . . . }4041 relation Class2Domain { . . . }42 relation Attribute2Template { . . . }43 relation Reference2Template { . . . }44 relation Class2MarkerCall { . . . }45 relation Class2MarkerCallInPattern { . . . }Listing 4.5: Overall structure of the Routine HOT (based on [68]).In the completion approach we embed a special DSL for completionsinto host language. We exploit the fact that a large part of the completionscould be expressed relying on the facilities of the host language. In our sce-nario the host language is defined by the PCM metamodel. Macros wereoften used for this purpose. Embedding a DSL into an existing host lan-guage allows inheriting its standard mechanisms and facilities, includingtransformations and tools. Each DSL is specified as an individual featuremodel.To integrate model instances conform to the DSL defined for the partic-ular completion, we have to implement completion transformation. UsingHOT patterns and chains built by these patterns we generate completiontransformations. The first step of this generation is creation of a routinetransformation frame providing a copier functionality.The generator for a copier transformation was introduced in [68]. Wediscuss the implementation for the purpose of completion transformations.The Routine HOT is written in QVT Relational and captures the patternsdiscussed in the previous section. The source model of the Routine HOTcan be any Ecore metamodel and the output model is a QVT Relationaltransformation. For this purpose, the Routine HOT requires the Ecore meta-metamodel, the OCL standard library, and the QVT Relational metamodel.After executing the Routine HOT the model of the routine transformation iscreated. In our case, it is the copy transformation, implementing the Copy-ing and Marking pattern. The resulting transformation model is expressedin its abstract syntax (of the QVT-R metamodel) and can be used directly1294. Variability Management using Higher-Order TransformationsMetamodelePackageXeClassHigher-order TransformationCopy RelationInput MetamodelFigure 4.6.: Generating a copy relation (based on [68]).1304.4. Routine HOT Patternin this form for further manipulation. However, for the execution we use asimple pretty printer to generate its textual syntax.The overall Routine HOT works basically analogously to the patternsshown in the previous section. The overview through the basic generatorstructure is shown in Listing 4.5. As shown there, a copy transformationis generated (c.f. Package2Transformation) for each package in themetamodel. The remaining relations of the Routine HOT generate relationsof the copy transformation.In the following, we discuss the most important parts of the RoutineHOT implementation. The relation Class2CopyRelation generates acopy relation for each non-abstract metaclass. For each subclass the re-lation SubClass2MarkerCallInWhen adds a negated call to the corre-sponding marker relation to the when clause of the created copy relation.Then, the marker relation for each metaclass is generated by the rela-tion Class2MarkerRelation. Additionally, we have to create a copyrelation for each attribute and reference as well. This is done by therelations Attribute2Relation and Reference2Relation. The de-tails of this generation are discussed in [68]. In the following, we fo-cus on the implementation of the relations Class2CopyRelation andClass2MarkerRelation and their mapping to the base patterns from Sec-tion 4.4.1.Figure 4.6 illustrates the generation of copy relations from metaclasseswithin one metamodel package. For each relation, a where clause is createdand the corresponding marker relation is called. Furthermore, the necessarydomain patterns to match the source and target constructs are created by theClass2Domain relation.Figure 4.7 shows relation generating the marker pattern that is createdfor all metaclasses including abstract ones. That results in a call from thewhere clause to mark relation of the superclass. Similarly, we can generateroutine transformations based on the other patterns introduced in the pre-vious section. Figure 4.8 illustrates the generation of the abstraction rules1314. Variability Management using Higher-Order TransformationsMetamodelePackageXeClassHigher-order TransformationMarkRelationInput MetamodelFigure 4.7.: Generating a marker relation (based on [68]).1324.4. Routine HOT Patternfor all classes in the metamodel. All subclasses will be replaced by theircorresponding superclass after executing generated relation.4.4.3. SummaryUsing the HOT Routine pattern, we can generate transformation framesnecessary for the integration of the customisations. In our case, the re-sulting transformation frame for a completion is generated from the PCMmetamodel. Listing 4.6 shows a fragment from this transformation frame.1 transformation CopyPCM_Frame(source: pcm, target : pcm) {2 relation MarkBasicComponent {3 checkonly domain source sourceBasicComponent:pcm: : repository : :BasicComponent{};4 checkonly domain target targetBasicComponent:pcm: : repository : :BasicComponent{};5 where {6 MarkImplementationComponentType(sourceBasicComponent, targetBasicComponent) ;7 }8 }910 top relation CopyBasicComponent {11 checkonly domain source sourceBasicComponent:pcm: : repository : :BasicComponent{};12 enforce domain target targetBasicComponent:pcm: : repository : :BasicComponent{};13 where {14 MarkBasicComponent(sourceBasicComponent, targetBasicComponent) ;15 }16 }17 . . .18 . . .19 . . .20 }Listing 4.6: The transformation frame for copying of PCM modelsTo generate more complex transformations, the next HOT in a chain caninject customisation (i.e., transformation fragments) in a transformationframe. The injection is controlled by a configuration model that specifiesthe activated features as well as necessary input parameters. Additionally,we have to define exception rules for the model elements that must notbe copied. For example, as explained above, the completions annotate socalled pivot elements. These elements are replaced by the customisations1334. Variability Management using Higher-Order TransformationsMetamodelePackageXeClassXeSuperClassHigher-order TransformationAbstractionRelationInput MetamodelFigure 4.8.: Generating an abstraction relation.1344.5. Composite HOT Patternand on their place we integrate more detailed subsystems. Thus, the nextHOT could modify the generate frame itself. For this purpose, the most nat-ural possibility to introduce exception rules is to manually introduce rulesthat are called instead of the overwritten ones. Another, option is to cre-ate a set of exception rules and use a simple HOT to integrate these in thegenerated frame.In case of completions these exceptions are rather simple. The pivotelements that can be annotated by completion are only of three types. Ap-plied to the PCM, completions are applicable to connectors, componentsor resource containers (also called infrastructure). Thus, we have onlythree types of simple exception rules. For example, an exception rule fora basic component would be an top-level relation that overrides the gen-erated CopyBasicComponent rule and marks the component with a tagisAnnotated = true as already copied. After this step, would the ex-ception rule calls the original CopyBasicComponent rule to copy all othercomponents.The Routine pattern is used to generate completion transformation as afirst pre-processing step. Into the resulting transformation frame we inte-grate feature effects defined by the completion configuration. The nextpattern called Composite HOT is dealing with the issue of customisa-tion of transformations and follows the Routine HOT in the chain of pre-processors.4.5. Composite HOT PatternModel-driven application engineering builds on the concept of model trans-formations that have to be customised for different purposes. With existingMDSD tools, application developers need to define customisation transfor-mations manually, including all possible configuration combinations. Dueto the high number of possible initial requirements, such a developmentmethod is costly and means significant effort. Currently, there is a lack1354. Variability Management using Higher-Order Transformationsof automated support for integrating these configuration decisions into thedevelopment process of transformations.To address these issues, we introduce the Composite pattern that weavesadditional customisations into transformations. In many cases, these cus-tomisation are highly variable and configurable.In Chapter 3 we discussed the Model Completion concept. In the fol-lowing, we introduce a novel approach for automated feature-model-basedgeneration of completion transformations. For this purpose, we introducethe Composite HOT pattern that can be used to build generators composingtransformation fragments depending on configuration.4.5.1. DefinitionName: Composite HOT pattern In many domains, requirements re-garding the final software product are constantly evolving. Customisationsthat are based on these requirements are a foundation for the creation ofproduct variations and have to be integrated in transformations. Require-ment of customisation introduces demands for highly efficient and low-complexity reconfiguration methods.In our application scenario, we use feature diagrams to express config-urations. The completion transformation is based on this feature diagram.Using the completion configuration on the abstract level we can generatetransformations to complete the models with completions on the lower levelof abstraction. Thus, we customise our models for the performance predic-tion.Although our proposed approach has a wide range of application do-mains, we further investigate opportunities in the component-based ap-plications domain (see Section 4.5.2). To illustrate the application of thepresented pattern, we use the Thread Pool running example introduced inChapter 3.3.1.1364.5. Composite HOT PatternMotivation: Required completions could occur in different configura-tion variants (e.g., middleware configuration). The most frequent way toconfigure model transformations is by means of external annotations to asource model, i.e., mark models. Mark models are used to provide config-uration details that are specific to the source model. However, this way oftransformation configuration is not preferable in our scenario. The detailsof the Model Completion concept and its motivation are further discussedin Chapter 3.MMAbs‘TTAbsHOTConc‘Abs‘‘TTConc Conv‘‘TTT«conforms-to»refinementcompletionCAbs0CAbs2CAbs1 CAbs3CAbs4Completion LibraryFigure 4.9.: Overview of Model Completion concept.In our scenario, configuration happens on a higher level of abstraction.In this case, configuration itself is a definition (or model) of the transfor-mation on the lower level of abstraction. The Composite pattern decouplesthe source model and the configuration. The configuration is then sourcemetamodel-independent and can be reused in different contexts. Such con-figuration allows to define independent completion transformations that arebuilding blocks used to realise the same completion activities in differentcontexts as illustrated in Figure 4.9.Implementation: The implementation of the Composite pattern con-sists of two steps: (i) first, we have to implement a reusable and config-1374. Variability Management using Higher-Order Transformationsurable construct encapsulating a required variation point, which can be, forexample, a completion registered in a completion library; (ii) second, weneed a HOT able to compose necessary transformation fragments (definedfor the variation point) and integrate them into one transformation (cf. Fig-ure 4.9).Figure 4.10 shows the structure of this pattern in more detail. On themetamodel level, we define variation points V P in the form of configu-ration models (in our case, feature diagrams) conform to the configurationmetamodel MMV P (feature diagram metamodel). Each configuration modelencapsulates a set of transformation fragments T F mapping the configu-ration options (features). These transformation fragments are transforma-tions themselves, as such they are conform to the transformation metamodelMMT and require references to the source and target domain. The sourceand target domain are defined by the source MM1 and target metamodelMM2. Similarly as the Routine pattern, the Composite pattern has a variantwith an equal source and target metamodel. In this case, the source andtarget domain are defined by the same metamodel. On the model level ofthis pattern, we can instantiate variants Var conform to the variation pointmetamodel V P. Starting with a variant Var a HOT generates a comple-tion transformation T . This HOT merges transformation fragments to theresulting transformation.Benefits and Drawbacks: Performing the model transformation con-figuration automatically based on external configurations instead of modelsseparates the development of variable construct from the actual model. Thisseparation of concerns can achieve high variability and flexibility in the de-velopment of software applications. The required transformation fragmentsdo not get polluted with code that is only responsible for checking the ac-tual feature configuration. Furthermore, as the binding of fragments andfeatures is more explicit this alleviates the complexity of transformationevolution.1384.5. Composite HOT PatternoutputM1 M2THOTMM2MM1VarVPMMVPinputTF*MMTsource domaintarget domainMetamodel levelModel level«conforms-to»«conforms-to»conforms toLegendassociationinput/outputFigure 4.10.: Composite HOT pattern with non-equal source and target metamodel.The main advantage of using HOTs in this scenario is that developers canfocus on the impact of one selected feature on the model at a time and de-velop transformation rules for this feature only, they are not concerned withall the feature combinations and their dependencies. Using conventionaltransformation development, the developer has to consider all the possi-ble configuration combinations and check the state of features (selected oreliminated) by accessing the configuration model from the respective trans-formation rules. Even later in development, the dependencies (where- andwhen-clause) between the relations need to be resolved manually. Our ap-proach solves these dependencies by the transformation generation basedon defined relations and constraints in the feature model. Additionally, thegenerated transformations are more structured and therefore better under-standable.Despite the advantages in simplifying the configuration of transforma-tions with our feature model based approach there are also some drawbacks1394. Variability Management using Higher-Order Transformationsthat need to be discussed. One problem arises when the feature configura-tion is changed and the target model needs to be updated according to thenewly woven transformation. The transformation traces that were storedduring the last transformation execution will potentially become invalid asthe structure of the transformation may have changed significantly. Incre-mental updates (which are mostly based on the transformation’s trace links)then are impossible. However, this problem only occurs if the transforma-tion engine uses typed traces that are specific to the transformation thatcreated them. Generic trace links pose less problems to the approach.Another drawback of applying HOTs in this scenario is the debuggabil-ity of the transformation. The debugger of the transformation engine willexecute and observe only the generated and woven transformation. Hence,a transformation developer will need to understand the generated transfor-mation in order to be able to debug it. A specialised debugger would beneeded if debugging should be possible on the configuration level.4.5.2. Completions Support: Generation of a CompletionTransformationConfiguration CompositeHOTCompletion TransformationCompletionRulesExceptionRulesCopy&MarkRulesRoutineHOTMetamodelFigure 4.11.: Building elements of completion transformation using Routine andComposite pattern.The basis for a completion transformation is a copy transformation gen-erated by the Model Copier pattern. The parts of the model that are com-1404.5. Composite HOT Patternpleted by the configured transformation will then replace the standard copyrules for the corresponding metamodel element. The composition processof the transformation fragments based on a feature selection that followshere is realised using a HOT (cf. Figure 4.9). The integration of comple-tion transformation and the optional exception rules into the frame of copytransformation is illustrated in Figure 4.11.In the following, we discuss the used configuration model and its meta-model. Further, we introduce the fragment composition principle and itsimplementation as a higher-order transformation.4.5.2.1. Metamodel of the Extended Feature ModelFeature models are hierarchical decomposition of features including infor-mation whether a feature is mandatory, alternative or optional. The featurescould be user-visible characteristics of the application, for example evolu-tion of application variants in product lines or more specific optimisationsfor better performance.The metamodel of the used feature diagrams is illustrated in Figure 7.1.To be able to use feature diagrams to configure transformations, we ex-tended the feature diagrams introduced in [46].The extensions to the feature model metamodel make it possible to addtransformation rules as annotations to the features. These extensions tothe used metamodel are depicted in Figure 7.1. The most important, evenquite non-intrusive extension, was the addition of a reference from theFeature to the Relation class the QVT Relational metamodel. This al-lows to annotate transformation fragments to features. As we also want toallow the specification of variable values through feature configurations weadditionally added a reference to the OperationCallExp from the OCLmetamodel. This allows features to refer to the ’=’-operation from theOCL Standard Library and thus assigning values to variables that are e.g.,1414. Variability Management using Higher-Order Transformationspresent in parent features. The third extension was the addition of so called’DisambiguationRules’ which are explained in Section 4.5.2.2.Figure 4.12.: Extensions to the Feature Model Metamodel.Furthermore, the feature model could include feature composition con-straints, that indicate which feature combinations are valid and which arenot. These constraints can either be hard (depends or excludes con-straints) or weak (default values or allowed override). We will refer tothis constraints further in Section 4.5.2.2.4.5.2.2. Feature-based Composition of TransformationFragmentsTransformation Fragments in the Feature Model Tree: The divide-and-conquer paradigm is an essential strategy for the development of trans-formations with variability and in fact for the resolution of variability prob-1424.5. Composite HOT Patternlems in general. Dividing the variability domain in partial tasks focusingon an one aspect of the model at a time decreases the complexity. As pre-sented in Section 4.5.2.1, the nodes of the feature diagram are annotatedwith transformation fragments. The transformation fragments implementalways only one aspect of the variability. The ability of the compositionalapproach to produce complex transformations from smaller units allows tocompose these variability aspects and create different transformation vari-ants.Legendorexclusive ormandatoryoptionalThreadPoolOptimizationPropertiesStaticThreadPool Policy DispatcherDynamicInitial TP SizePriority Lanes ParityThread Borrowing PrioritySpecified NativeGuardSemaphore ConditionexcludesexcludesdependsMax TP Sizetop relation TP_Static {varSize : Integer;checkonly domain in p :Component {};enforce domain out s:TP {size = varSize;};when {TP(p,s);}where {varSize = 100;--default}}top relation TP {checkonly domain in p :Component {};enforce domain out s:TP {}; }TP_Static.varSize = size;TP Sizesize:int = 32Figure 4.13.: Simplified transformation fragments for the running example.There are two ways how to implement the transformation fragments. Thelanguage standards for model transformations offers two dialects: relationallanguage and operational language. Each one of these dialects can be usedin isolation. Combining of these approaches results in a hybrid transfor-mation approach. We can implement transformation fragments in a strictlydeclarative or in a hybrid manner. The hybrid transformation fragments cancall black-box operations implemented in an operational language between1434. Variability Management using Higher-Order Transformationsthe rules in relations. This can be used, for example, to manipulate usedvariables more directly, or to trace the execution flow in the relations. Thus,hybrid implementations are defined externally as relational and internallyuse operational constructs.For simplicity, we will consider only transformation fragments imple-mented in strictly declarative manner. The important advantage of usingthese declarative features over operational, is that they allow a high de-gree of decoupling between the different aspects of variability. In a strictlydeclarative rule-based approach to model-transformation, the transforma-tion is defined by a predicate, relating the models before and after thetransformation. For the composition paradigm, it is required to define thetransformation fragments T F as follows:Definition 11 Relational Transformation FragmentsA transformation fragment T F is a non-empty set of relational rules RRthat are defined as tuple:RR = (Var,Map,Pre,Post),where Var is a set of local variables, Map a set of mappings, Pre a set ofnecessary preconditions and Post postconditions. The preconditions andpostconditions are rule references and can refer to the rules that are definedin other fragments, this property distinguishes a fragment from a transfor-mation.Furthermore, as we create a transformation by composing transforma-tion fragments, for such transformation should hold that all the referencesin preconditions and postconditions of a relation are resolved. Let res de-note a function that resolves a reference in a precondition or postcondition,i.e. that return the referenced model element for a given precondition orpostcondition (res(x) = RR ∈ T : x points to RR). Then, we define suchtransformation as follows:1444.5. Composite HOT PatternDefinition 12 Fragment-based TransformationA fragment-based transformation T is a non-empty set of transformationfragments T F , for which holds:∀RRi ∈ T ∀pre ∈ RR.Pre ∃RR j ∈ T : res(pre) = RR j ∧∀RRi ∈ T ∀post ∈ RR.Post ∃RR j ∈ T : res(post) = RR jAlthough the transformation fragments are implemented using declara-tive transformation language, we support software engineers with a viewon the transformation, its variants, and its execution order at a highly ab-stract manner. The used feature diagrams allow to control execution or-der through the structure of the feature tree. The tree structure is used tocompose fragments and resolve their dependencies, thus it defines the ex-ecution order. At this abstract level software engineers can influence thetransformation execution, without fighting with maintainability overheadresulting from a verbose declarative transformation definition. The declar-ative structure of the targeted QVT Relations transformation engine makesthe composition possible without having to deal with issues regarding theoperational ordering of the rules. Moreover, studies in the area of programcomprehension [43] show that visualising the program structure in form ofa tree helps the understandability and developers can better focus on thedevelopment of isolated features.We distinguish two types of transformation composition. External com-position deals with chaining separate model transformations together bypassing models from one transformation to another; we discuss this type ofcomposition more in Chapter 5. Internal composition composes two modeltransformation definitions into one new model transformation, which typi-cally requires knowledge of the transformation language. The latter methodrequires the model transformations that will be composed to be expressed in1454. Variability Management using Higher-Order Transformationsthe same language. The Composite pattern focuses on internal compositionof transformation fragments into an one rule-based model transformation.The composition of transformation fragments based on the feature dia-gram is language-independent and can be used for any relational transfor-mation specification (such as QVT Relational or ATL). The feature treescapture the essence of a transformation’s modular structure. By its hier-archy, the feature model represents a general structure of the transforma-tion abstracting from language-specific details. For example, the hybridimplementation of a transformation fragment using operational constructsinternally would not have influence on the composition. This compositiontechnique can be used for other languages than QVT, as long as the transfor-mation language has the concepts of rules and modules that contain thoserules. QVT Relations is such a transformation language, therefore we usethis language to implement Composite pattern.Since it has to be possible to compose those fragments together to a sin-gle transformation, there are several constraints on the way the transfor-mation fragments are specified. Those constraints result mainly from thestructure of the feature model and the patterns, which can occur in sucha structure. As the composition of transformation fragments follows thestructure of the feature tree, the HOT weaves the transformation fragmentsinto the final transformation based on the set of composition constraintsconsidering position and type (e.g., optional or mandatory) of the relatedfeature in a tree. We discuss necessary constraints in the following section.Constraints for the Transformation Composition: According tothe different kinds of relations that can occur between features in a fea-ture model (cf., Figure 4.13, adapted and with feature Dispatcher addedfor the purposes of constraints explanation), different constraints apply forthe transformation fragments that are annotated to the features. These con-straints are guidelines for the composition. Constraints Ci (C1 to C5) de-scribe the rules that have to be obeyed when annotating transformation1464.5. Composite HOT Patternfragments to a specific feature. Furthermore, these constraints serve asbasis for the generation of the resulting transformation. We use the run-ning example to explain the different constraints. Figure 4.13 illustrates theannotated feature diagram for Thread Pool.Constraint C1: The basic shape of a feature model is that of a tree. Fea-tures can have sub-features forming a parent-child relationship. A child-feature can only be activated, if its parent feature is activated. For thescope of the transformation fragments that are attached to the child nodethis means that the children’s rules may reference those of the parent withinit’s when- and where-clauses.Definition 13 Ancestor FunctionAn ancestor function fA of transformation fragment T F is defined as fol-lows:f (n) =⎧⎨⎩T F, if T F belongs to the root feature,T F ∪ fA(T FP), otherwise, where T FP is parent of TF.A parent T FP is a transformation fragment belonging to the parent featureFP of the feature F holding T F (F ∈ FP.children).Definition 14 C1: Relation access for child featuresFor each relation RR ∈ T F holds:res(RR.Pre)⊆ fA(T F)∧ res(RR.Post)⊆ fA(T F)EXAMPLE: In the running example this pattern is depicted in Figure4.13 this pattern occurs between the ThreadPool and the Static feature.The transformation fragment of the Static feature TP_Static has a when-dependency to the transformation fragment TP of its transitive parent Thread-Pool. Listings 4.7 and 4.8 show how the child feature can call the relation1474. Variability Management using Higher-Order Transformationsdefined by a transformation fragment of the parent feature (see relationCreateThreadPoolComponent).1 transformation ThreadPoolRoot (source: pcm, target : pcm) {23 top relation CreateThreadPoolComponent {45 checkonly domain source sourceRepository:pcm: : repository : :Repository{6 };78 enforce domain target targetBasicComponent:pcm: : repository : :BasicComponent{9 entityName = ’ThreadPool’ ,10 . . .11 };12 when {13 CreateIThreadPoolInterface(sourceRepository , threadPoolInterface );14 }15 where {1617 }18 }1920 top relation CreateIThreadPoolInterface {21 . . .22 }Listing 4.7: Transformation fragment for the feature ThreadPool1 transformation ThreadPoolRoot (source: pcm, target : pcm) {23 top relation CreateThreadPoolComponent_Static {45 checkonly domain source sourceBasicComponent:pcm: : repository : :BasicComponent{6 entityName = ’ThreadPool’7 };89 enforce domain target targetBasicComponent:pcm: : repository : :BasicComponent{10 entityName = ’ThreadPool’ ,11 providedRoles_InterfaceProvidingEntity = providedRole : pcm: : repository :12 :ProvidedRole {13 . . . },14 serviceEffectSpecifications__BasicComponent = acquire : pcm: : seff :15 :ResourceDemandingSEFF {16 . . . },17 serviceEffectSpecifications__BasicComponent = release : pcm: : seff :18 :ResourceDemandingSEFF {1484.5. Composite HOT Pattern19 . . . },20 passiveResource_BasicComponent = threadPoolResource : pcm: : repository :21 :PassiveResource {22 entityName = ’ThreadPool’ ,23 capacity_PassiveResource = ThreadPoolSize : pcm: : core : :PCMRandomVariable {24 specification = ’100’25 }26 }27 };28 when {29 CreateThreadPoolComponent(sourceBasicComponent, targetBasicComponent) ;30 CreateIThreadPoolInterfaceAcquire(sourceRepository ,31 threadPoolInterfaceAcquire ) ;32 CreateIThreadPoolInterfaceRelease(sourceRepository ,33 threadPoolInterfaceRelease );34 }35 where {3637 }38 }3940 relation CreateIThreadPoolInterfaceAcquire {41 . . .42 }43 relation CreateIThreadPoolInterfaceRelease {44 . . .45 }Listing 4.8: Transformation fragment for the feature ThreadPool.StaticConstraint C2: Additionally to the access to when- and where-clauses itis possible for transformation fragments of child rules to control the assign-ment of free variables of their parents.Definition 15 C2: Variable assignment for child featuresFor each relation RR ∈ T F holds:RR.Var ⊆ fA(T F)EXAMPLE: See figure 4.13 and listing 4.9 for an application of C1 andC2. Feature TP Size can be used to statically configure the size of the1494. Variability Management using Higher-Order Transformationsthread pool. Hence, the transformation fragment refers to the free vari-able declared in the TP_Static fragment of feature Static (for the sakeof simplicity a simple path notation with the fragment’s name as prefixis used to denote the referred relation). This way the value specified inthe feature configuration (size = 32) ends up in the assignment within thewhere-clause of the resulting generated transformation. Listing 4.10 showsabnother value assignment for the variable ThreadPoolSize.1 −−Resulting composed transformation2 top relation TP_Static {3 varSize : Integer ;4 checkonly domain in p : Component {};5 enforce domain out s : TP {6 size = varSize; };7 when{ TP(p, s) }; −− Application of C18 where { s = 32; }−− Application of C29 }Listing 4.9: Example transformation fragments (C1,C2)1 transformation ThreadPoolRoot (source: pcm, target : pcm) {23 top relation CreateThreadPoolComponent_Static_PoolSize {45 checkonly domain source sourceBasicComponent:pcm: : repository : :BasicComponent{6 entityName = ’ThreadPool’7 };89 enforce domain target targetPassiveResource:pcm: : repository : :PassiveResource{10 capacity_PassiveResource = ThreadPoolSize : pcm: : core : :PCMRandomVariable {11 specification = ’32’12 }13 };1415 }Listing 4.10: Transformation fragment for the featureThreadPool.Static.PoolSizeConstraint C3: Feature models distinguish between mandatory and op-tional features. As mandatory features are always activated it is possibleto reference rules of mandatory features of (transitive) parents within child1504.5. Composite HOT Patternrules. This means that even siblings can use each other’s rules within theirwhen- and where-clauses if both of them are mandatory within their parentfeature.Definition 16 C3: Inheritance of mandatory featuresFor each relation RR ∈ T F ∪T FS, where T FS is a fragment belonging to thesibling feature, holds:RR.Var ⊆ fA(T F)∪ fA(T FS)res(RR.Pre)⊆ fA(T F)∪ fA(T FS)∧ res(RR.Post)⊆ fA(T F)∪ fA(T FS),if both of the features F and FS are mandatory.EXAMPLE: The fragments of the Dispatcher feature presented in ThreadPool feature model can reference fragments of the Optimization Propertiesfeature.Constraint C4: In addition to the parent-child relationship, a feature candepend on other features within the feature tree. Such dependencies aremodelled as depends-relationships. For the scope of the transformationrules of the dependent feature this results in an import of the rules of the re-quired feature and its scope (that is computed using C1 to C3). All importedrules may then again be used in when- and where-clauses of the currenttransformation rules.As counterpart to depends, excludes inhibits a concurrent activation oftwo features. As both features can then never be activated at the same timean interference of their transformation fragments is also impossible.1514. Variability Management using Higher-Order TransformationsDefinition 17 C4: Referencing through constraints - DEPENDSFor each relation RR ∈ T F and a fragment T FD related to the T F by de-pends-relationship, holds:RR.Var ⊆ fA(T F)∪ fA(T FD)res(RR.Pre)⊆ fA(T F)∪ fA(T FD)∧ res(RR.Post)⊆ fA(T F)∪ fA(T FD)Definition 18 C4: Referencing through constraints - EXCLUDESFor each relation RR ∈ T F and a fragment T FE related to T F by excludes-relationship, holds:if T F ∈ T then T FE /∈ TEXAMPLE: In the thread pool example (Figure 4.13) this pattern wouldapply for fragments of the Dispatcher feature referencing relations fromthe Thread Borrowing feature.Constraint C5: An exclusive-or between sub-features poses no problem,as they may never occur at the same time and thus their transformationrules can never interfere which each other. A more challenging construct isthe inclusive-or relationship. Features connected within such a relationshipmay occur in an arbitrary combination.To be able to specify this disambiguation, special disambiguation ruleswere introduced into the feature metamodel (cf. Figure 7.1). The disam-biguation is configured by defining one DisambiguationRule for eachcombination of features that should be treated exceptionally. Within theDisambiguationRule the combination is specified by assigning the fea-tures for which the rule applies to the selectedFeatures reference. Intheory it would be possible to make a transitive selection of inclusive-or-edchildren. However, in the current version of the approach this is not sup-ported. Therefore, a constraint (see listing 4.11) applies to the selection of1524.5. Composite HOT Patternfeatures, restricting the possible selection to direct children of the currentfeature.1 self . selectedFeatures−>forAll( f |2 i f self .disambiguatedFeature . childRelation .3 oclIsTypeOf(featuremodel : :FeatureGroup) then4 self . childRelation .oclAsType(featureModel : :FeatureGroup) .5 children−>includes( f )6 else −−then i ts a Simple relation7 self . childRelation .oclAsType(featureModel : :Simple) .8 optionalChildren−>includes( f )9 endif10 )Listing 4.11: Constraint on DisambiguationRuleDefinition 19 C5: Disambiguation of inclusive-orFor each set of transformation fragments ST F = T F1,T F2, . . . ,T FN , wherefragments are in inclusive-or relationship, holds:SD ⊆ ST F ∧SD ∈ T,where SD is a disambiguation set specified by a disambiguation rule RD ∈FP. Feature FP is shared parent of T F1 ∧T F2 ∧·· ·∧T FNEXAMPLE: In the thread pool example such different combination possi-bilities could occur with the Optimization Properties feature: Either Thread-Pool Policy, Static or Dynamic, a combination of them (excluding Static orDynamic selected at the same time, due to the excludes relationship be-tween them) or none of them could be selected. Each possibility results ina different transformation rule in the generated transformation.1534. Variability Management using Higher-Order Transformations4.5.2.3. Implementation of HOT for Composition ofTransformation FragmentsThe first input for this HOT is a feature diagram with mapped transforma-tion fragments, these fragments are used by for the actual transformationgeneration. The second input is the actual feature configuration, whichdefines the selected features and values of attributes. For composition ofcompletion transformation T , is responsible HOT that merges fragments sothat composition holds previously introduced constraints on transformationfragments.1 transformation Ecore2copyQVT (feat : featureconfig , qvt : QVTRelation, pcm: ecore) {23 top relation Config2Transformation {.. .}4 relation MarkTypedModel {. . .}5 relation MarkTransformation {.. .}67 /∗8 ∗ C1:9 ∗ Copy the relations from each selected feature10 ∗/11 top relation SelectedFeatureRelation2Relation {12 n : String ;13 checkonly domain feat selectedFeature : featureconfig : :ConfigNode {14 configState = featureconfig : : ConfigState : :SELECTED,15 origin = originFeature : featuremodel : : Feature {16 name = n,17 relations = featureRel : QVTRelation: :Relation {} }18 };19 enforce domain qvt targetRel : Relation {20 _transformation=transfo :QVTRelation: : RelationalTransformation {}21 };22 when { MarkTransformation( transfo ); }23 where { MarkFeatureRelation(originFeature , targetRel ) ;24 CopyRelation(featureRel , targetRel ) ; }25 }2627 /∗28 ∗ C2:29 ∗ Copy the assignments from each selected feature30 ∗/31 top relation SelectedFeatureVariableAssignment2VariableAssignment {32 n : String ;1544.5. Composite HOT Pattern33 checkonly domain feat selectedFeature : featureconfig : :ConfigNode {34 configState = featureconfig : : ConfigState : :SELECTED,35 origin = originFeature : featuremodel : : Feature {36 name = n,37 variableAssignments = assignment : OperationCallExp {},38 parentRelation = parentRel : featuremodel : : ChildRelation {39 parent = parentFeature : featuremodel : : Feature {} }40 }41 };42 enforce domain qvt targetRel : Relation {43 _transformation=transfo :QVTRelation: : RelationalTransformation {},44 _where = whereClause : QVTBase: : Pattern {45 predicate = pred : QVTBase: : Predicate {46 conditionExpression =47 copiedAssignment : ocl : : ecore : :OperationCallExp {}48 }49 }50 };51 when { MarkTransformation( transfo );52 MarkFeatureRelation(parentFeature , targetRel ) ; }53 where { CopyAssignment(assignment , copiedAssignment) ; }54 }55 relation CopyRelation {.. .}56 relation CopyAssignment {. . .}57 relation MarkFeatureRelation {.. .}Listing 4.12: HOT for transformation fragments composition (C1 and C2).The HOT for composition of transformation fragments that follow con-straints C1 and C2 is shown in listing 4.12. It weaves the transforma-tion fragments of the selected features into the final transformation. Thetransformation is based on a generated copy transformation for QVT Rela-tional itself (see Routine pattern in Section 4.4). The copy rules (such asCopyAssignment or CopyRelation) are used to copy the rules that arespecified by the transformation fragments on the selected features. Rela-tion SelectedFeatureRelation2Relation is responsible for matchingfeatures that are optional from the feature model and copying the annotatedtransformation relations to the final transformation. A corresponding re-lation MandatoryFeatureRelation2Relation is provided to match all1554. Variability Management using Higher-Order Transformationsmandatory features which do not need to be selected explicitly. SimilarHOTs are provided for the weaving process of constraints C3 to C5.4.5.3. SummaryUsing the introduced transformation generation technique based on theComposite HOT pattern, we can generate a transformation variants thatinclude selected customisations into the transformations. The Compositepattern allows to generate completion transformations and decrease the de-velopment effort resulting as a consequence of the variability. To fully au-tomate generation of completion transformations we have to combine bothof the introduced patterns HOT Routine and HOT Composite. Moreover,we can automate the development of the transformation fragments usingthe Template pattern introduced in the following section.Despite the advantages in simplifying the configuration of transforma-tions with our approach based on feature model, there are also some draw-backs that need to be discussed. One problem arises when the feature con-figuration is changed and the target model needs to be updated accordingto the newly woven transformation. The transformation traces that werestored during the last transformation execution will potentially become in-valid as the structure of the transformation may have changed significantly.Incremental updates (which are mostly based on the transformation’s tracelinks) are then impossible. However, this problem only occurs if the trans-formation engine uses typed traces that are specific to the transformationthat created them. Generic trace links pose no problem to the approach.4.6. Template HOT PatternModel transformations are a major instrument of model-driven software de-velopment used in various contexts. Especially in relational transformationapproaches, the structuring of transformations depends to a large extent onthe structure of the source models and the generated artefacts. In many1564.6. Template HOT Patterncases, similar code is written for transformations that deal with the samesource or target metamodel. Writing such transformations can be simpli-fied significantly if re-occurring parts within the transformation rules canbe specified in a reusable way.Current approaches to transformation development include means fortransformation reuse as well as inheritance. However, modularisation alongthe boundaries of different parts of domain metamodels is still lacking. Fur-thermore, the possibilities to reuse transformation fragments that re-occurin multiple transformations is limited. We introduce a Template HOT pat-tern to support usage of domain-specific templates for transformations withwell-defined instantiation points, so called hooks. Transformation tem-plates enable a modular specification of transformations and thus yield asimpler definition of transformations that can be grasped more easily anddeveloped more efficiently.In addition, we present a set of transformation templates in the contextof the MDSPE for component-based software architectures. The specifiedtemplates give insight into the application of the presented pattern for dif-ferent domains.4.6.1. DefinitionName: Template HOT patternMotivation: Transformations are mainly determined by the source- andtarget-domains on which they operate. The structure of a transformationdepends to a large extent on the structure of its source and target models.Furthermore, domain-specific patterns for the creation of a target modelmay occur multiple times in a transformation leading to large parts of du-plicated transformation code. In many cases, transformations require anno-tations [63, 120] which software engineers attach to individual elements ofa model. Annotations specify which elements are to be refined by subse-quent transformations. Such annotations and the underlying model are then1574. Variability Management using Higher-Order Transformationstransformed into a target model [63]. Writing such transformations can besimplified significantly if re-occurring parts within the transformation rulescan be reused.However, there is little experience available about how to design and im-plement transformations using modern relational transformation languages.One reason for this is the fact that model transformations are written in lan-guages of very recent date (e.g. QVT Version 1.0 was published in 2008)[72, 90]. Therefore, a basis of formalised knowledge and experience withmodel transformation development is not yet available at a broad basis.First initiatives for transformation design template specification focused ongeneric patterns [87] for model transformations. Although these patternsdefine a ground to build on, they do not exploit domain-specific knowledgeof the transformation’s source and target models. For example, they do notmake use of design patterns that are often part of software models.The Template pattern is based on our experience with the implementa-tion of transformations used for customizing software architectures. Weobserved that configurable model transformations follow certain patternsdefined by the domain of their metamodels. The approach introduced inthis thesis allows reusing and customizing transformation parts. Transfor-mation templates are based on known design patterns and enable a modularspecification of completion transformations. They yield simpler definitionsof transformations that can be grasped more easily and developed moreefficiently. Thus, the Template pattern can increase reuseability and modu-larization of transformations.The Template pattern is an analogy to templates in established program-ming languages, such as C++. For example, developers can can write meta-programs using C++ templates that are executed during compilation. Thistechnique can be used to perform code selection and code generation atcompile time. In the following, we describe the pattern in more detail.1584.6. Template HOT PatternImplementation: The Template pattern takes advantage of the possi-bility to reuse transformation parts to further automate transformation de-velopment. Transformation templates are parametrised and contain well-defined instantiation points. They are instantiated during load-time of atransformation.Figure 4.14 shows the structure of the pattern. Transformation templates(T mp) are stored in a template library. New customisation rules can bespecified instantiating (T Inst) and composing the existing templates. Fur-thermore, templates are configurable by a set of parameter values of theirinstantiation points. The template instantiation process presented is realisedusing a HOT (cf. Figure 4.14). It creates template instances, merges thetransformation using the instances and creates a transformation based onthe actual configuration given by the template configuration model. Fur-ther parts of the HOT are responsible for binding the instantiation points ofthe templates to the elements from the actual template configuration. Theimplementation of Template pattern is discussed in Section 4.6.2.4 in moredetail.Benefits and Drawbacks: This scenario allows to specify reusabletransformation templates that occur in transformation development for spe-cific metamodels. Based on these templates, model transformations canthen be generated using HOTs. This results in a creation of a SPL fortransformations. Therefore, we also exploit the advantages of SPLs, i.e.,improved reusability and easier creation of new members of a SPL. Simi-larly as in the previous pattern, one particular drawback of our approach isthe debuggability of the transformation.4.6.2. Completions Support: Generation of TransformationFragments using TemplatesIn this section, we describe the realisation of the Template pattern to supportcompletions, furthermore, this solution was published in the MDI Models1594. Variability Management using Higher-Order TransformationsoutputM1 M2THOTMM2MM1input*MMTsource domain target domainTmpTInstMetamodel levelModel levelconforms toLegendassociationinput/output«conforms-to»«conforms-to»Figure 4.14.: Template HOT pattern.Configuration CompositeHOTCompletion TransformationCompletionRulesExceptionRulesCopy&MarkRulesRoutineHOTMetamodelTemplateTemplateHOTFigure 4.15.: Building elements of completion transformation using Routine, Com-posite and Template HOT pattern.1604.6. Template HOT Pattern2010 proceedings [92]. To support transformation developers, we providea set of templates for reoccurring transformation patterns. The instantiationof the templates is realised using a HOT (cf. Figure 4.15). In the following,we discuss the implementation of this pattern for the purpose of comple-tions.4.6.2.1. Configuration-aware Transformation TemplatesThe automated generation of completion transformations presented by theComposite pattern significantly reduces the effort needed to specify suchtransformations. However, the customisation rules implemented as trans-formation fragments still tend to contain a large set of similar elements,especially for architectural models. Therefore, we propose transformationtemplates as an additional mean to ease the specification of completiontransformations.AdaptorMonitorMonitorActive AdaptorLockAdaptorCoupled AdaptorLockActive DelegatorDelegatorII1I2SynchroniserI1I2IFigure 4.16.: Introduction of simple templates for component-based architecturesbased on the running example.Figure 4.16 illustrates the set of templates we have identified so far forthe running example. A Coupled Adaptor allows sender and receiver toadapt their interfaces to the same standard and, for example, use the same1614. Variability Management using Higher-Order Transformationsmiddleware. This template can be used in the case of completion by cou-pled actions, such as encryption and decryption, or composition and de-composition. The Synchroniser is used when a component has to acquirea lock before accessing a certain service and release a lock when finished.Same synchronisation pattern could be observed in the case of dependentactions. In the example, this template is used for the wrapper componentto acquire locks through the thread pool interface. An Active Componenttemplate is used to model a component with a complex internal behaviour.This template refines the model with an element introducing independentbehaviour branch. An additional wrapper is provided for the functionalitydefined as an internal action of the component behaviour. To provide, forexample, a queue for competing consumers the Lock template is used. Thistemplate possesses a semaphore element and can be used when introducinga state holding element to the model. The Monitor template is applied tothe component to provide a wrapper for simple monitor functionality, suchas a timer. The last template introduces new functionality into the modeland could be independently required by already existing model elements.In following section, we describe the adaptor template, as a representa-tive, in more detail. To document the transformation templates, we use astandard description schema for templates defined in [59] and [87]. This in-cludes the following information: the name of the template, the goal of thetemplate, the motivation for the template, the specification of the templateusing the QVT-Relations language, applicability defines constraints for theusage of a template and an example in which the template is applied.4.6.2.2. The Adaptor templateIn this section, we illustrate the concepts introduced above with the exam-ple of the adaptor pattern [59]. For the application within a completiontransformation, further details concerning the specific metamodel are nec-essary.1624.6. Template HOT PatternNAME: AdaptorGOAL: Change the provided or required service interface.MOTIVATION: When new functionality is needed in an architecture (forexample message filtering), its implementation could result in a change ofa service’s signature (or input or return parameters). The adaptation ofthe interface is considered as a configurable change and allows developersto define changed attributes without the need to reimplement the wholetransformation for the integration.SPECIFICATION: The adaptor template is specified by a relation thatcreates an Adaptor component which requires the interface provided bythe adapted component and provides the interface required by the callingcomponent. Additionally, based on a designer defined method mapping,it requires or provides a modified interface to another component in thesystem. As illustrated in Listing 4.13, an adaptorComponent is createdwith the modified interface targetInterface in the target domain .1 transformation CBSE_Adaptor (source: CBSE, target : CBSE) {2 top relation Adaptor_template_CreateAdaptor {3 checkonly domain source sourceInterface:{ −−adapted interface4 5 };6 checkonly domain source targetInterface:{7 8 };9 enforce domain target adaptorComponent:{10 name = −−name11 requiredRoles = reqRole:RequiredRole{12 requiredInterface = sourceInterface }13 providedRoles = provRole:ProvidedRole{ −−modified interface14 providedInterface = targetInterface }15 serviceEffectSpecifications = −−behavior specification16 seff :ServiceEffectSpecification{ . . . }17 }18 };19 }Listing 4.13: Template Specification of the Adaptor template.1634. Variability Management using Higher-Order TransformationsAPPLICABILITY: The applicability of templates defines constraints forthe usage of a template. For the Adaptor template such a constraint is de-fined by the requirement that a instantiation point should be of type inter-face.EXAMPLE: An example of an Adaptor is shown in Figure 4.16. ThisAdaptor provides an interface to the receiver and adapts its required in-terface to communicate with used middleware (Active Component) and re-quire a lock for each request. This lock models the thread pool size usedfor the communication.Template Goal Instantiation Point (Hook) Delegator Provides a wrapper for a required or provided interface and delegates additional information without adjusting the signature. Interface Coupled Adaptor/Delegator Adapts two interfaces allowing their communication. Or in a case of delegation to allow them to use communication connection together without changing their signatures. Interface Synchroniser Provides an interface requiring a software resource (thread pool, queue or semaphore). Interface Lock Models a component providing a passive software resource (thread pool, queue, semaphore). Passive Resource Active Provides a component with its own, independent control flow thread. Component Monitor Adds a controller or monitor (e.g., mutex to all method calls allowing only a single thread to access the component at one time.) Internal action Table 4.1.: CBSE Transformation Templates.Additional examples illustrating the instantiation point approach formodel transformation templates are given in Table 4.1. The instantiationpoint types map known element types for specification of component-basedarchitectures (e.g. components, interfaces, signatures, resources, etc.). Adetailed description of these templates is provided in Section 4.6.2.5.4.6.2.3. Metamodel for the Templates DefinitionTo define a framework supporting the definition and configuration of trans-formation templates, we need to describe them and their instantiation in ageneral way. This description is provided by means of a metamodel intro-duced in this section and illustrated by Figure 4.17.1644.6. Template HOT PatternFigure 4.17.: The metamodel for the transformation templates.As a main element of the transformation templates metamodel, we in-troduce the Template element. This element represents the concept of atransformation template in our terminology and defines a reconfigurableand reusable transformation fragment for the model transformation gener-ation. The Description of a template contains a definition of the Goalof the template as well as a textual Motivation for the Template def-inition. Each Template defines the applicability, or usage scenarios, byspecifying an OCL Constraint. To be able to apply a template in a cer-tain context, this constraint needs to evaluate to true. The Templateelement refers to a set of Relations from the QVT Relational meta-model. These relations form the basis of the template as they will beparametrised by InstantiationPoints as defined below. Furthermore,the Template definition contains a set of InstantiationPoints. Theseinstantiation points define possibilities for variations within the basic rela-tions. A InstantiationPoint is defined by a reference to either a tem-plate expression (TemplateExp) or relation domain (RelationDomain).1654. Variability Management using Higher-Order TransformationsThese points are defined by subclasses of InstantiationPoint namedTemplateInstantiationPoint, DomainInstantiationPoint, and Literal-InstantiationPoint (for the specification of variable literals within atemplate).The association dependencies of the Template class expresses depen-dencies between transformation templates. Defined transformation tem-plates depend on each other and therefore these constructs need access toresults of required transformation templates.In complex cases, the dependencies on a design template definition or itsinstance could mix. However this type of variations defines very complextransformation templates relations. The fine granular model provided by theintroduced metamodel allows a low-effort definition of such dependencies.This is possible by the fine granular InstantiationPoint definitions andtheir sharing.The binding of a template to an actual transformation fragment is doneas soon as the template is referenced within an actual transformation frag-ment that is defined for a concrete feature model. The actual application ofthe transformation template is defined by the TemplateConfig. For eachdefined InstantiationPoint the template configuration includes Instan-tiationPointInstances which bind the InstantiationPoint to actual templatesor relation domains specifications. InstantiationPointInstances can be as-signed to multiple InstantiationPoints stemming from different transforma-tion templates. This yields the possibility to combine transformation tem-plates to build more complex model variations.4.6.2.4. Implementation of HOT for Model TemplateInstantiationThe instantiation process presented in Listing 4.15 is realized using a HOT.It merges the transformation using the templates and creates a transforma-166tion based on the actual configuration given by the template configurationmodel.4.6. Template HOT Pattern1 transformation templateInstantiation(source: templateDefinition ,2 config : templateDefinition , target : QVTRelation)3 extends CopyQVTRelation {4 top relation Library2Transformation {5 n:String ;6 checkonly domain source templateLib: templateLibrary {7 _domain = n };8 enforce domain target t : QVTRelation: : RelationalTransformation {9 name = n + ’_templateInstantiation ’ };10 where { MarkTargetTransformation( t ) ; }11 }1213 relation MarkTargetTransformation {14 checkonly domain target t :QVTRelation: : RelationalTransformation{};15 }1617 top relation AddTypedModels {18 checkonly domain source templateRep: templateRepository {19 modelParameter = mm: QVTBase: :TypedModel { } };20 enforce domain target t : QVTRelation: : RelationalTransformation {21 modelParameter = mmCopy: QVTBase: :TypedModel { } };22 when { Repository2Transformation(templateRep, t ) ;23 Mark_QVTBase_TypedModel(mm, mmCopy); }24 }2526 top relation IntegrateRelations {27 n:EString;28 checkonly domain source templateConfig:29 templateDefinition : : templateConfig {30 instanceOf = template : templateDefinition : : template {31 name = n,32 templateRelations = templateRel : QVTRelation: :Relation {}33 }34 };35 enforce domain target targetRelation : QVTRelation: :Relation {36 name = n + ’_template_’ + templateRel .name ,37 _transformation = t : QVTBase: :Transformation {}38 };39 when { MarkTargetTransformation( t ) ;40 Mark_QVTRelation_Relation(templateRel , targetRelation ); }41 }42 . . .43 }167Listing 4.14: Higher-order transformation for instantiating templates.4. Variability Management using Higher-Order TransformationsThe first step of the Template Instantiation is the creation of a copy of therelations that were specified within the template. Therefore, we use a gen-erated copy transformation for the QVT-Relations metamodel. The Mark-QVTRelationRelation relation that is used here is a part of this generatedtransformation. Using this, it is possible to retrieve the copied instance ofa given original relation. For each class in the corresponding metamodelsuch a relation exists. The template instantiation transformation extendsthis copy transformation. Repository2Transformation creates a newtransformation that will then contain the configured templates. Further-more, AddTypedModels adds the model parameter of the transformation tothe transformation as they were specified in the template repository. Eachused and configured template is then added to the newly generated transfor-mation by the IntegrateRelations relation. All other template relationsthat were copied from the template repository by the copy transformationwill be ignored.Further parts of the HOT are responsible for binding the instantiationpoints of the templates to the elements from the actual template configura-tion. Listing 4.15 shows the necessary relations for binding a Template-InstantiationPoint.1 top relation BindTemplateInstantiationPoint {2 n:EString;3 instantiationPointBindings :OrderedSet( InstantiationPoint ) ;4 checkonly domain source instantiationPoint :5 templateDefinition : : TemplateInstantiationPoint{6 name = n,7 relationTemplate = relationTemplate : QVTRelation: :Relation {},8 template = instantiationTemplate : QVTTemplate: :TemplateExp {}9 };10 checkonly domain config instantiationPointInstance :11 templateDefinition : : TemplateInstantiationPointInstance{12 bindsTo = instantiationPointBindings ,13 template = instanceTemplate : QVTTemplate: :TemplateExp {}14 };16815 enforce domain target targetTemplate : QVTTemplate: :TemplateExp { };16 when { Mark_QVTTemplate_TemplateExp(instanceTemplate , targetTemplate ) ;17 instantiationPointBindings−>includes( instantiationPoint ) ; }4.6. Template HOT Pattern18 where {19 Mark_QVTTemplate_TemplateExp(instantiationTemplate , targetTemplate ); }20 }21 . . .Listing 4.15: Binding of template variation points.An extension to the generated QVT-R copy transformation is made byoverriding the generated copy relations for those elements that may be in-stantiation points in the templates. In the example above this would be allcopy relations that inherit from TemplateExp. Listing 4.16 shows how thisis done for the ObjectTemplateExp. This extension will cause the copytransformation to omit all TemplateExp that are instantiation points dur-ing the copy process. For each binding that is configured in the templateconfiguration the BindTemplateVariationPoint relation in Listing 4.15will call the Mark_QVTTemplate_TemplateExp relation. Due to the func-tionality of the copy transformation this will cause the copy relations totreat the substituted template as the copy of the original and will assign itto all points in the template’s copy where the original template was used.The copy transformations are created applying the Routine pattern.1 −−Override the Generated Copy Rule:2 top relation Copy_QVTTemplate_ObjectTemplateExp3 overrides Copy_QVTTemplate_ObjectTemplateExp{4 checkonly domain source instantiationPoint :5 templateDefinition : : TemplateInstantiationPoint{6 template = instantiationTemplate : QVTTemplate: :TemplateExp {} };7 checkonly domain source sourceObjectTemplateExp:8 QVTTemplate: :ObjectTemplateExp{ };9 enforce domain target targetObjectTemplateExp:10 QVTTemplate: :ObjectTemplateExp{ };11 when { not (sourceObjectTemplateExp = instantiationTemplate ) ; }12 where {13 Mark_QVTTemplate_ObjectTemplateExp(14 sourceObjectTemplateExp, targetObjectTemplateExp); }15 }16 [ . . . ]169Listing 4.16: Overriding Copy Rules.4. Variability Management using Higher-Order Transformations4.6.2.5. Further Transformation TemplatesThe Delegator Template GOAL: Provide a wrapper for a required orprovided interface and delegate its functionality based on the unchangedsignature.MOTIVATION: A delegator can be used for example, when for eachrequest a semaphore lock should be asked to allow access the semaphoreprovider service before allowing the request to reach the interface.SPECIFICATION: This template is specified by a relation that creates adelegator component that requires or provides delegated interface to othercomponents in the system. Additionally a delegator could request servicesfrom other components. This template could be used to generated the initialstructures for this.1 transformation CBSE_Delegator (source: CBSE, target : CBSE) {23 top relation Delegator_template_CreateDelegator {4 checkonly domain source delegatedInterface:{5 };6 enforce domain target delegatorComponent:{7 name = 8 requiredRoles = reqRole:RequiredRole{9 requiredInterface = delegatedInterface }10 providedRoles = provRole:ProvidedRole{11 providedInterface = delegatedInterface }12 serviceEffectSpecifications =13 seff :ServiceEffectSpecification {.. .}14 }15 };16 }Listing 4.17: Template Specification of the Delegator template.APPLICABILITY: For the Delegator template it is required that a in-stantiation point is not of type interface.1704.6. Template HOT PatternEXAMPLE: The example of a Delegator is shown in Figure 4.16 asan additional template. This Delegator provides interfaces to the requestreceiver with the same interface.The Coupled Adaptor/Delegator template GOAL: To adapt twointerfaces and to allow their communication. Or, in a case of delegation,to allow them to use communication connection together without changingtheir provided functionality.MOTIVATION: When it is needed to build a connector between twocommunicating components or to build a chain of delegators to access cer-tain external functionality in a certain state of message delivery.SPECIFICATION: This template is specified by a relation that createstwo Delegator or Adaptor components that mirror their adapted or dele-gated interface.APPLICABILITY: For the Adaptor/Delegator template is required thatinstantiation point should/shouldn’t be of type interface.EXAMPLE: The example of a Coupled Adaptor is shown in Figure 4.16.This construct allows sender and receiver to use the same active component.The Synchroniser template GOAL: To provide an interface requir-ing a software resource (thread pool, queue or semaphore).MOTIVATION: When component has to acquire a lock before accessinga certain service and release a lock when finished.SPECIFICATION: This template is specified by a relation that extendsin a model already existing component with an interface requiring an ex-ternal service providing acquire() and release() on a lock resource holdedbe called component. This specification implies an existence of an Lockmanager in a system.1 transformation CBSE_Synchroniser(source: CBSE, target : CBSE) {23 top relation Synchroniser_template_CreateSynchroniser {4 checkonly domain source synchronizedInterface:{1714. Variability Management using Higher-Order Transformations5 };6 enforce domain target synchroniserComponent:{7 name = 8 requiredRoles = reqRole:RequiredRole{9 requiredInterface = synchronizedInterface ,10 requiredInterface = }11 providedRoles = provRole:ProvidedRole{12 providedInterface = synchronizedInterface }13 serviceEffectSpecifications =14 seff :ServiceEffectSpecification{ . . . }15 }16 };17 }Listing 4.18: Template Specification of Synchroniser template.APPLICABILITY: For the Synchroniser template is required that instan-tiation point should be of type LockManagerReference.EXAMPLE: The example of a Synchroniser is shown in Figure 4.16 andillustrated by extention to receiver adaptor component with an additionalsynchronisation interface.The Active component template GOAL: To provide a wrapper fora functionality defined as internal action of a component behaviour.MOTIVATION: When it is needed to model a component with a complexinternal behaviour.SPECIFICATION: This template is specified by a relation that createsan Active component that requires or provides a delegated interface to theanother components, depending on a developer specification. In case ofthis template is the template only a frame for implementation, it is the mostcomplex template with no restrictions on instantiation points.APPLICABILITY: There are no restrictions for this template. Conse-quently this template requires higher user interaction to implement.EXAMPLE: The example of a Active component is shown in Figure 4.16and illustrated by a shared component, providing a common functionality(e.g. middleware).1724.6. Template HOT PatternThe Lock manager template GOAL: To model a component provid-ing a passive software resource (thread pool, queue, semaphore).MOTIVATION: When a synchronization mechanism based on a lockstrategy is used in a system.SPECIFICATION: This template is specified by a relation that createsLock component that provides an interface with two signatures acquire()and release() on its internal passive resource.1 transformation CBSE_LockManager (source: CBSE, target : CBSE) {23 top relation LockManager_template_CreateLock {4 checkonly domain source appRepository:{5 };6 enforce domain target lockComponent:{7 name = 8 requiredRoles = reqRole:RequiredRole{}9 providedRoles = provRole:ProvidedRole{10 providedInterface = lockInterface }11 serviceEffectSpecifications = acquireLock12 seff :ServiceEffectSpecification{ . . . }13 serviceEffectSpecifications = releaseLock14 seff :ServiceEffectSpecification{ . . . }15 passiveResource = lock{16 }17 };18 }Listing 4.19: Template Specification of Lock manager template.APPLICABILITY: For the Lock manager template is required that theinstantiation point is of type passiveResource.EXAMPLE: The example of a Lock is shown in Figure 4.16. This lockmanager provides, for example, a queue for competing consumers.The Monitor template GOAL: To provide a wrapper for simple mon-itor functionality.MOTIVATION: When it is needed to model a component that only gainsand stores data, or provides some timing control. For example a clock com-ponent required by a connector or accessing middleware, providing a con-1734. Variability Management using Higher-Order Transformationstrol interface externally to set a clock and providing an interface internallyfor other components in assembly to ask a clock.SPECIFICATION: This template is specified by a relation that creates aMonitor component that requires or provides a delegated interface to theanother component. This component has only a simple internal action de-fined and is creating processing delay through computation.APPLICABILITY: For the Monitor template is required that variationpoint should be of type internal action.EXAMPLE: The example of a Monitor is shown in Figure 4.16 as anadditional template. This monitor provides, for example, a clock for a con-nector.4.6.3. SummaryThe introduced HOT Template Instantiation pattern allows to build a classi-cal SPL for transformations using template-based approach. The TemplateInstantiation pattern allows to automate development and supports reuse oftransformation fragments in completion-based approaches. In the follow-ing section, we will shortly discuss other HOT patterns and later using hereintroduced patterns we will build a chain of HOT patterns to fully supportmodel completions.4.7. CHILIES: Chains of HOT patternsIn some complex scenarios, it is useful to compose multiple HOT patternsin a chain. Figure 4.18 shows an example of such a composition where atransformation is generated using all three introduced patterns: (i) HOT1Routine generates a frame (copy rules), (ii) HOT2 Composite overridessome of the copy rules and adds custom rules dependent on configura-tion, (iii) HOT3 Template overrides some of the rules and adds templateinstances.1744.7. CHILIES: Chains of HOT patternsoutputHOT2 VarVPMMVPinputTF *MMToutputM MTHOT1«conforms-to»«conforms-to»MMinputoutputHOT3input*MMTTmpTInstMetamodel levelModel levelconforms toLegendassociationinput/outputsource/target domainsource/target domainFigure 4.18.: Chain of HOT patterns: HOT1 - Routine, HOT2- Composite, HOT3-TemplateSimilarly, a deeper view on the process of completion generation (c.f.Figure 4.19) shows the dependencies and connections between the conceptsintroduced above. The process depends on the specification of several in-puts for HOTs, which build the HOT Chain.The transformation fragment composition is realized using a ModelCompletion HOT, illustrated on a Figure 4.19. The first input is a FeatureModel with attached Transformation Fragments (Custom Rules). Thesefragments are used by a Composite HOT for the actual transformation gen-eration. It merges the transformation fragments that are annotated to thefeature model nodes together creating the final completion transformation.The second input is the actual Feature Configuration, which defines whichfeatures are selected as well as the values of feature attributes. In contrastto an in-place transformation, a completion transformation may also bespecified to create a new model where the completions are applied. In thiscase, the completion transformation extends a copy transformation (Frame)generated by the Routine HOT. As we rely on QVT Relations for the im-1754. Variability Management using Higher-Order Transformationsplementation of our transformations which does not provide native supportfor copy transformations, we use the Routine HOT to automatically createa copy transformation from the metamodel of the application model. TheComposite HOT includes the Transformation Fragments into the generatedcopy transformation. Custom rules will then replace the standard copy rulesfor the corresponding metamodel element.The goal of the templates is to ease the custom rules development. This isachieved through instantiation of Transformation Templates from TemplateLibrary on a place of transformation fragments in the feature model. Trans-formation templates are stored in a Template Library (cf. Figure 4.19). NewCustom Rules can be specified instantiating and composing the existingTemplates. Furthermore, templates are configurable by a set of parametervalues. Based on the template and its configuration, the Template HOTcreates Template Instances and adds the necessary rules to the completiontransformation.The result of the HOT Chain is a Completion Transformation that whenapplied to an Architectural Model generates the corresponding CompletedArchitectural Model. The line Meta-Level Boundary separates the genera-tion of the transformation (domain engineering phase) and its application(software engineering phase).1764.7. CHILIES: Chains of HOT patternsMeta-Level BoundaryCustom RulesConfigurationFeature ModelFeature ConfigurationHOT ChaininputTransformation FragmentsTF1T 1-Config1TFNextendsinputHigher-OrderTransformation ChainoutputTemplateLibraryT 1 T 2 T Ninstance ofinputTemplate Instantiation HOTT i-ConfigiFrameT iTemplateInstancesT i-InstanceiinputcopyconfCopy TransformationRoutine HOTModel Completion HOT inputinstance ofArchitectural ModelCompleted Architectural Modelmodel(of transform.)input/outputdependencyLegendactive transform.CompletionTransformationoutputTF1TF2TFNgeneratedFigure4.19.:HOTChaintosupportModelCompletionsinMDSPEApplicationScenario1774. Variability Management using Higher-Order Transformations4.8. DiscussionIn the following, we discuss the assumptions and limitations of the contri-butions presented in this chapter. The experience in the area of HOT ap-plications is still missing since transformations on higher abstraction levelsare not extensively used so far. Despite the advantages in simplifying thedevelopment of variable transformations with HOT patterns, there are alsosome limitations that need to be discussed.Complexity of HOTs Creating a HOT is not an easy task. Especiallyas the HOT engineer has to think on two different levels using probably thesame language constructs. Developers need to get accustomed to thinkingon a meta-level, and write/modify abstract syntax. HOTs naturally havea higher complexity coming along with power of abstraction. Therefore,development of HOTs can be error prone and should only be conducted byexperienced transformation engineers.Debuggability This issue is not a new one, as it occurs whenever soft-ware language artefacts are subject to automated modification. In thesecases, debugging can be a problem. Developers work and develop on acertain development version of an artefact (either also a transformation orsome other artefact, for example configuration, from which a transforma-tion will be derived). However, the debugger of the transformation enginewill execute and observe only the generated and woven transformation.Hence, a transformation developer will need to understand the generatedtransformation in order to be able to debug it. This can lead to confusionand additional effort for understanding these modifications when the devel-oper needs to debug the transformation. To alleviate this issue, a debuggerthat is capable of mapping the debug information to the higher level artefactis required. A specialised debugger would be needed if debugging shouldbe possible on the meta level.1784.8. DiscussionRoutine HOT pattern This pattern is currently only implemented forthe Ecore metamodels. The Routine HOT requires an Ecore metamodelon input and generates a QVT-R transformation on output. However, theextension of this HOT for other relational transformation languages is onlya question of implementation.Composite HOT pattern The assumption, we took by this HOT pat-tern is that all transformation fragments are composable. Although, thecomposability of relational transformations is straight-forward in compari-son to the operation languages, we require a valid design of feature modelon input. The valid design of feature model is described in the followingsection.Valid design of feature model The constraints for composition oftransformation fragments in the Composite HOT pattern require a valid fea-ture model to function correctly. A valid feature model does not include:• Nested inclusive-OR structures – such structures increase the com-plexity of disambiguation rules exponentially, because the relatedfragments have to consider all possible combinations of all nestedfeatures in the inclusive-OR sub-tree. Our assumption is that suchstructures result from invalid identification of relations between fea-tures by domain analyst during modelling of the domain.• Cyclic/Negated dependencies – the usage of the constraints in thefeature model is limited and does not allow to create cyclic or negateddependencies between two features, thus, two DEPENDS-constraintsin opposite direction or two constraints, one EXCLUDE and one DE-PENDS, between two features are not allowed.• Incomplete relations in feature effects – the relations in feature ef-fects are required to be complete, thus, include everything (e.g.,all opening and closing brackets) needed for their valid execution1794. Variability Management using Higher-Order Transformationsin a transformation engine, only missing parts could be pre/post-conditions or variables, which are parametrised and do not dangerthe relations validity.Usage of declarative transformations The declarative transforma-tion definition is easily extendible with additional features, therefore, welimit our approach to this family of languages. This is achieved by separa-tion of concerns and usage of declarative code as much as possible (min-imizing usage of imperative code). Declarative code is very suitable forgenerative approaches. In our approach, we follow the philosophy of mod-ular and declarative transformation rules with implicit execution order.Template HOT pattern The Template pattern builds on the existenceof templates for certain domain, in our case CBSE domain. The templateswe introduced help to create parts of the models, but some of them have tobe completed manually, for example the internal behaviour of the Adaptortemplate. We do not consider the templates applicable in general, they aredependent on a domain and a purpose of the model. The generality of thetemplates is out of scope for this thesis.Composability of HOTs The usage of QVT-R to implement HOTs andcompletion transformations is motivated by the special properties of rela-tional languages, especially composability. There are various approachesto support model transformation composability, either they are based oninternal or external composition of transformations. An transformation im-plemented in relational transformation language consists of a number ofmapping rules. These mappings may be combined by calling, or other fa-cilities, such as inheritance, merge and disjunction. These strategies areused for internal composition of transformations. The composition of trans-formations as black-box artefacts is called external composition. We limitour approach to the external composition of HOTs to form a transforma-1804.9. Summarytion chain. The internal or rule-based composition was not considered inthis work. In the case of transformation chain, the composition is straight-forward with assumption that the interfaces fit. We assume that the HOTsare implemented in a such way that they can be composed together (i.e.,output of previous HOT is of the same type as input of the next one). Inaddition, it would be suitable to have possibility to to pass parameters to thetransformations and the possibility to retrieve the output of a transformationand to pass as input to the consequent transformation.4.9. SummaryIn this chapter, we introduced a set of HOT patterns to solve different goalsas a part of complex model-driven processes. Despite their complexity,HOTs have the potential of solving problems in an efficient way. Espe-cially when a lot of variability needs to be managed within a transformationproject, lifting this variability to a higher level can ease the development ofotherwise complex transformations (see patterns 4.5 and 4.6). HOTs enablea better separation of concerns and therefore better maintainability of theemployed transformations. In scenarios where a large amount of manualeffort for a relatively simple task can be avoided, HOTs also unfold theirpotential (see Section 4.4). Here, otherwise tedious and error prone taskscan be easily automated using a HOT-based approach.Furthermore, we described the automated support of completion trans-formation development using the presented HOT patterns. Using this ap-proach the transformation generation phase in the Completion-based Soft-ware Engineering (see Chapter 3) is fully automated. In the next chapter,we focus on the realisation of the completion library. Additionally, we dis-cuss the execution of completions in sequences.1815. Completions for Software PerformanceEngineeringIn the previous two chapters, we discussed the Model Completion Conceptand its realisation through composing HOT patterns for different goals. Inthis chapter, we discuss integration of completions in the Completion Li-brary. The structure and usage of this library is the main topic of thischapter. The structure of the Completion Library supports reduction of ap-plication conflicts in the sequence of completions. Moreover, we introducea set of completions for MDSPE. This initial set of completions is focusedon the concurrency design patterns and targeted to support developers tocreate complex models of concurrent systems.The leading challenge of this chapter is:How to structure the Completion Library to reduce possible conflicts inan application of multiple completions?The remainder of this chapter will be organized as follows. Section 5.1introduces the application context and motivates the structuring of the Com-pletion Library. In Section 5.2.3 we describe the method for the reductionand resolution of conflicts in application of multiple completions. In ad-dition, Section 5.3 presents an initial set of completions for concurrencydesign patterns. We discuss limitation of presented approach in Section 5.4and, finally, we summarize the contributions in Section 5.5.5.1. MotivationCompletions transparently integrate low-level details that affect a system’squality (e.g. performance impact of compression or encryption configu-1835. Completions for Software Performance Engineeringration) into component-based architectural models, using model-to-modeltransformations. When multiple completions are to be applied, the neces-sary completion transformations are executed in a chain. In such scenarios,application conflicts (i.e., compression before encryption influences result-ing data volume, and the other way around) between different completionsare likely. The dependencies among completions define where and whencertain completions can be woven into the model. The execution order ofthe completions may affect the target model in a way that the followingcompletions are not applicable any more or that the analysis results are al-tered. Therefore, the application order of completions must be determinedunambiguously in order to reduce such conflicts. Problems of conflictingtransformations and their application order have already been addressed inthe area of model-driven development [82]. However, in the domain of soft-ware performance engineering, quality attributes captured by the architec-tural models have to be considered as an additional dimension of conflict.The execution order of a set of completions can affect the quality predic-tions for the resulting architectural models. Thus, the knowledge about thequality impact of a particular order of completions can be used to resolveconflicts and to identify the suitable order in which completions have to beapplied to achieve the best overall quality of the system.One approach to handle conflicts is that software architects decide on thesuitable transformation order manually. However, this approach is time-consuming, can be error-prone, and is likely to result in suboptimal de-signs. Especially, with growing number of completions the complexity ofthis decision grows. Therefore, a semi-automated and structured solutionsupporting software architects should reduce these conflicts in completionorder and help with their resolution.We define a systematic approach to identify, reduce or avoid conflictsbetween completions that are applied to the same model. The techniquereduces conflicts, based on the development role separation and locally op-timises the order of completions in a sequence. For this purpose, we clarify1845.1. Motivationthe roles in the development process responsible for specific completions,when additional information to reduce conflicts is necessary. The principleof development role separation is mirrored in the structure of the comple-tion library. Furthermore, in Section 7 we validate this approach by apply-ing it to an architecture model of a component-based business informationsystem and analyse the impact of different sequences of completions.The main scientific contribution of this chapter is located in the MDSPEcontext and can be summarised as follows:Structured Completion Library for Software PerformanceEngineering• Reusing expert knowledge: The decisions about the requiredsteps going from an abstract model Abs (cf., Figure 3.2), basedon a set of initial requirements, to an abstract model Abs′,suitable for required purpose (e.g. performance prediction),requires a lot of domain-specific expert knowledge (e.g. forperformance prediction it is knowledge about performance-relevant implementation details). Additionally, the same activi-ties are often repeated, e.g. usage of the same design pattern orintegration of the same middleware platform. Standardizationof possible design decisions in a form of reusable constructs(e.g., completions) allows reusing and tracing design decisions.This allows to build a ’Performance Knowledge Base’ as envi-sioned by Woodside et al. [172]. Design decision are explicitlymodelled as a part of a development already on the abstractlevel, and mapped to the requirements. Models with trace todesign decisions considering even implementation details notonly provide better predictions, but can help to document man-agerial decisions (e.g. which middleware will be used) on theabstract level. Therefore, we provide a support for completionlibrary where completion encapsulating expert-knowledge can1855. Completions for Software Performance Engineeringbe registered. In addition, we provide a initial set of comple-tions, which allow to reuse expert knowledge about modellingof the concurrency design patterns.• Completion conflict reduction: Because multiple applicationof completions on the same model could can lead to conflicts intheir application, we developed a completion reduction method.Completions are realised as model transformations. Comple-tion transformations executed in a sequence may not permit orrequire certain changes specified by a following transformation,in other words, the following transformation would not be ap-plicable. We call such conflict a validity conflict. In additionin the SPE domain, the order of completions in a sequence caninfluence the results of predictions, thus, two permutations ina sequence can provide different results. We call this kind ofconflict a quality conflict. Therefore, we designed a structuredlibrary of completions that supports reduction and resolution ofthese conflicts. Our method for conflict reduction builds on therelation between the transformations and the metamodel. Thequality conflicts are resolved with the help of quality heuristics.5.2. Structured Completion Library for Conflict ReductionModel Completions are implemented as model-to-model transformationsand as such they inherit all their properties. One specific property of modeltransformations is their connection to the metamodel they are developedfor, the, so called, metamodel coverage (see Section 6). By studying themetamodel coverage of transformations it is possible to identify whichmodel elements are modified by the transformations.Our observation is that metamodels are often structured. It is a goodpractice to structure metamodels into packages grouping together semantically-related elements. This package structure often follows the separation of1865.2. Structured Completion Library for Conflict Reductionconcerns principle, for example, the structure of packages in the PCMmetamodel follows the domains of the CBSE development roles introducedin Section 2.2.1, where each development role has a separate package set.When it is possible to identify such separation in a structure of metamodel,then it is possible to identify transformations covering only these separatedomains. For example, a completion applied by a system architect canmodify only instances of model elements belonging to the domain of sys-tem architect and therefore such completion is not in conflict with comple-tion applied by a component developer. This simple idea could be appliedto manage any transformations developed for a structured metamodel. Weapply this idea to reduce conflicts of completions for performance engi-neering and we use the PCM metamodel for this goal.The introduced approach for reducing and resolving conflicts betweenexecuted performance completions builds on a few systematic steps. First,we identify responsibility domains for the CBSE development roles inPCM. Second, we minimize the conflicting set and, third, we resolve re-maining conflicts using quality-based heuristics. These heuristics give anindication of most advantageous sequence, however, because we analysethe sequences only locally and not in a context of whole system, the finalresolution step requires an interaction from user, who has to deal only withsmall reduced set of conflicting completions. In the following, we describethe problem of conflicts between executed performance completions on themodel level formally.5.2.1. FormalisationIn the previous chapter, we discussed formalisation of model completions,related transformations and their variants. In this part of formalisation, wesummarize necessary definitions and focus on the chains of completions.Before completing a model element, the completion is instantiated ac-cording to a selected variant. Possible variants of a cT hreadManagement com-1875. Completions for Software Performance Engineeringpletion can be for instance vT PstaticcT hreadManagement . The instantiation results into acompletion transformationtcPCMT hreadManagement , which can finally be applied to a pivot element. Afterapplication of a completion transformation we create a valid model element(or subsystem). Thus, the next completion can be applied and multiple ap-plications of different completions in a completion chain is possible.Let now C = {ci|i ∈ I} be a finite set of available completions, that wecall a completion library. Then, Vi is a countable set of possible variants vjifor one completion ci (Section 4.2.4). For example, the Vlocking of a com-pletion clocking (enhancing a component A with a critical section lockingstrategy) is Vlocking = {vscopedlocking,vdouble−checkedlocking , ...,vstrategizedlocking }. Each variantis realised as a completion transformation tC that integrates chosen v ji intothe source model. The transformation is generated based on a configura-tion and completion definition including specification of pivot element andfeature diagram (ci = (e, f di), see Section 4.2.4).This section discusses a sequences of transformations, that represent anordered chain of completion transformations, as presented for model-to-model transformations in Section 4.2.4. As mentioned above, each modelelement e∈ E (for the definition of E see Section 4.2.4) can be enhanced bymultiple applications of (different) completions, i.e. a chain of completiontransformations.Consistent Set of Completions: For the purpose of completion chaindefinition, we define a set of possible completion variations (or completioninstances) in a chain asCI = {v ji | i ∈ I,v ji ∈Vi},and limit that a completion set CS⊆CI is consistent only if each completionin CS occurs in at most one variation, thus∀v ji ,vlk ∈CS : i = k ⇒ v ji = vlk1885.2. Structured Completion Library for Conflict ReductionChains of Completion Transformations: Thus, given a consistent com-pletion set CS ⊆CI, a completion chain cc over CS is defined ascc = ci1 ◦ ci2 ◦ ...◦ cin ,ci j ∈CS,where ’◦’ defines an external composition of transformations in form of achain of transformations. The chain of transformations t∗cc is then executedas follows:t∗cc : con f (MM)tCi1→ con f (MM)tCi2→ ·· · tCin→ con f (MM),where tCi j instantiates ci j ∈CSNote that not all sequences of execution of a completion set CS on a givenelement e need to be valid for the system model. Some of the completionchains cc over CS may result in an invalid set of model elements cc(e), notsatisfying a given set of validity constraints. Such constraints can be speci-fied in terms of rules or grammars, and can be verified on both the resultingelements cc(e) and the completion order cc = ci1 ◦ ci2 ◦ ... ◦ cin ,ci j ∈ CS,since some of the orders can be a priori forbidden. In our formalization, weuse CC(CS,e) to denote the set of all valid completion chains over CS forelement e.For example, the set CI for the completion clocking is defined as CI ={vscopedlocking, vdouble−checkedlocking , vstrategizedlocking }, and a consistent completion set can beCS = /0, CS = {vscopedlocking}, or others. When we assume CS includes an ad-ditional completion configuration of the completion cmessaging, e.g. CS ={vscopedlocking, vconn_1:Nmessaging}, we would identify two possible completion chainscc1 = vconn_1:Nmessaging ◦ vscopedlocking and cc2 = vscopedlocking ◦ vconn_1:Nmessaging.Completion Conflicts: Based on previous definitions, a completionchain cci is an ordered set of completion transformations < tC1 , tC2 , ..., tCN >, i ∈ I. The completion chain cci is in conflict with cc j; i, j ∈ I, when anorder of completion execution in cci = cc j and the validity of the model1895. Completions for Software Performance Engineeringstructure (validity conflict) or the result of analysis (quality conflict) is dif-ferent for each of the chain definitions.Finally, we say that a set of all completion chains over CC is conflictingon the element e ∈ E, if there are two completion chains cci,cc j ∈CC suchthatQ(cci(e)) = Q(cc j(e)),where Q is a quality function, e a pivot element, and cc(e) an element ecompleted by a completion chain cc applied to the model. Here, Q speci-fies the quality semantics of the set of model elements cci(e), resp. cc j(e),which result from e after applying all the completion configurations in cci(resp. cc j) to it, in the left-to-right order. Note that, we are interested toapply the definition only to the sets of valid completion chains CC(CS,e)over a consistent completion set CS and model element e ∈ E, but for thereason of generality, we define it for a wider domain (any set of completionchains).5.2.2. Method for Reduction of Completion Validity ConflictsThis section introduces the method to minimize the conflicting set in a se-quence of completions. To reduce possible conflict between completions,we have to investigate, for each new completion, its dependencies to othercompletions already registered in the library. We reflect the need for iden-tification and reduction of conflicts by introducing three levels of conflictreduction:1. Roles and Responsibilities Separation: The first resolution ques-tion is "Who is able to provide all necessary information to use andconfigure the completion?". The selected role in the developmentprocess has to have all necessary input data to specify the comple-tion’s configuration during software design. Furthermore, he/she hasto profit from completion usage. Ideally, the assignment of comple-tions to roles will lead to identification of disjointed sets of com-1905.2. Structured Completion Library for Conflict Reductionpletions. Each role is only responsible for the completions in onedisjointed set.Each time a new completion is introduced, we analyse its dependen-cies to other already known completions. Therefore, we focus on arelated group of completions where conflicts are more likely. Thisway, possible conflicts are limited to the completions in responsibil-ity of one role. Additionally, separation of concerns based on theroles in the development process creates a hierarchy (identifying do-mains of concern) in the metamodel of used architecture descriptionlanguage.To focus our reasoning, we categorise completions based on themetamodel elements they could be assigned to. This way we reducepossible conflicts on a metamodel level. The proposed categorisationmaps the roles in the CBSE development process [102] to groups ofcompletions. It is best practice in metamodel design to structure themetamodel considering the development process the metamodel willused in and the different subdomains or technology domains. Thisallows to identify independent parts of the metamodel in competenceof one development role. The metamodel part that belongs to onedevelopment role is called cluster. This is illustrated by a hierarchyof packages in the PCM metamodel in Figure 5.1.The goal of this step is to identify sets of completions where conflictsare possible. Based on the metamodel structure, we can identify com-pletion transformations their input and output model are created frominstances of metamodel elements belonging to two different clusters.Therefore, two such transformations could not result in a validityconflict. In Figure 5.1 the transformations T3 and T4 are in conflict,because they modify model elements from the same cluster. Thetransformation T2 is an example of a limitation of the introduced res-olution approach, we do not allow completions to change a model1915. Completions for Software Performance Engineeringin a responsibility of other role. This way, we define disjunct sets ofcompletions Ci. For each two completions ck ∈Ci and cl ∈Cj;Ci =Cjconflicts are not possible. Only in a case of completions located in thesame metamodel cluster, conflicts are possible. In this case, we haveto proceed to the next level and further specify affected elements.System DeployerComponent DeveloperSoftware ArchitectDomain Analyst<>system<>core<>protocol<>connectors<>repository<>seff<>parameter<>resource type<>resourceenvironment<>allocation<>usagemodelM MT3M MT4M MT1MMT2M MT5TransformationsMetamodelFigure 5.1.: A role hierarchy in the PCM metamodel.2. Conflicting Model Elements Identification: If conflicts can oc-cur, we further analyse the question "Which model elements are af-fected?". For this purpose we have to know how the completions aremodelled and at which places of the architecture they can be applied.We can identify affected elements as a difference between source andtarget model. Identified elements specify more exact locations whereconflicts may occur.The evaluation of completion chain cc for conflict-potential is a func-tionφ : T → S,1925.2. Structured Completion Library for Conflict Reductionwhere domain S is the set of possible conflicting instances of meta-model elements. For example, when evaluating order in a sequenceof completions for locking and stateful wrapper (both of them shouldbe applied to the same component) we identify on the model level thepossible conflict set that includes all elements needed in componentand its behavior definition. This results in further separation of con-flict domains and decreasing the number of completions that couldintroduce conflict on a model level. We define sets of potentiallyconflicting completions (conflict space):Con f lictSpace := {ti, ti}where i = j and ti potentially conflicts with t j on a model element e ∈S, where S is a set of conflicting elements orthogonal to the hierarchyfrom the previous level.Since we apply completions to component-based software systems,we identify the model elements of component-based architecturesthat can be refined, and discuss the completions applied to them.We assume three types of model elements (the main architecturalelements of CBSE) that can be completed: components, connec-tors, and the infrastructure. Thus, for our domain we can defineS = {component, connector, infrastructure}.While there may be many component and connector elements in themodel, there is always at most one infrastructure element to considerfrom a completions point of view. All these model elements are as-sumed to be independent for the completions, i.e. the order of com-pleting two different elements within the model does not influencethe result. In the following, we describe the model settings, to whichwe frame our problem.Components are black-box (or sometimes grey-box) entities charac-terized by the services they provide to others and the services they1935. Completions for Software Performance Engineeringrequire from third parties. In our approach, we can deal with com-ponents in two ways. In the first case, we assume that componentsare entirely black-box. Thus, completion-based model refinementsare not allowed to change the internals of the components (or its ser-vices). Instead, completions attach wrappers to the components thatdelegate the same interfaces (require and provide the same servicesas the original component) and include additional quality-relevantdetails to the service specification. In the second case, we assumethat components are grey-box and their behaviour is captured on anabstract level by a behaviour specification. Completions must notchange a component’s behaviour with respect to its functionality.However, they may extend the behaviour specification so that onlyits non-functional properties are affected. For example, a completioncan add a particular locking strategy to a critical section around acomponent’s behavioural specification.Connectors define communication links among components and mo-del interaction of components along these links. Additionally, thecommunication between remote components can be configured thro-ugh connector properties. A connector can have a complex inter-nal structure and implement non-trivial interaction logic. Therefore,the connector layer can be viewed as a net of independent connec-tor subsystems connecting the components. The connector comple-tions integrate independent connector subsystems into the architec-ture. These connector subsystems do not change the connector modelfrom the view of interacting components. As such connector subsys-tem could be considered as independent.The hardware environment forms the system’s infrastructure and istypically understood as a separate layer of a component-based archi-tecture, underlying the component assembly. Thanks to this, infras-tructure completions integrate usage of services provided by lower-1945.2. Structured Completion Library for Conflict Reductionlayers of software stack, and hence allow to adjust the environmentindependently.After this resolution step is the resulting set of completions is min-imized on completions applied by the same role to the same modelelement. Thus, we proceed to the last level of conflict resolution.3. Completion Dependencies Identification: At the end, we need toanswer the question "What are the dependencies to other comple-tions from the same conflict space?". From the previous levels, thatalready identified the roles and model element types the completionsenhance, we get a reduced set of completions. Further, we needto identify their intersections (affected model elements) on instancelevel. At this point a interaction with user is required, hence, the ap-plication of completion is system specific from this point on. Userscan generalise dependencies between completions by definition ofmutual exclusion or require relationships in a completion specifica-tion in the time of completion registration. Our assumption at thispoint is that remaining set of completions applied by the same role tothe same instance of model element is so small that it is possible toresolve the validity conflicts manually.The presented approach allows to reduce and avoid model completionsconflicts on a model-level (Conflicting Model Elements Identification) ormeta-model level (Roles and Responsibilities Separation). Thus, the com-plexity of conflicts is decreased (avoiding non-determinism of conflictssimilar as in graph grammars). The effort for manual conflict resolutionis minimised on a small set of model elements and the number of caseswhen the resolution of validity conflict cannot be automated.5.2.3. Method for Resolution of Completion Quality ConflictsTo allow the reasoning about completion order, we need to decide on theabstraction filter that allows us to identify the preferred completion order,1955. Completions for Software Performance Engineeringbased on the evaluation of the architectures resulting from the applicationof the completions. In our case, we employ a performance-driven view onthe system model.Performance is a pervasive quality of software systems, everything af-fects it [173], from the software itself to all underlying layers, such as oper-ating system, middleware, hardware, communication networks, etc. Withinthe domain of performance engineering, we focus on the response time,throughput and resource utilization as the main quality properties. Theseproperties can be related to the identified architectural elements as follows.Components are characterized by the response time and throughput of theservices they provide, and partially by the resource utilization during theirexecution. Connectors are characterized by the response time of the com-munication over the connectors, and the throughput and utilization of thelink they employ. The infrastructure is characterized by the utilization ofthe resources that form the infrastructure. The contribution of this sectionis then the examination of the order of completions in a completion chain,which could be optimised and used to improve the design of future systemor for fine-tuning quality attributes of the system during development.For the domain of component-based performance models, this sectiondefines the quality function Q employed by the heuristics for the resolu-tion of completion conflict, and justifies the locally-oriented definition ofa completion conflict. The justification is based on the understanding ofperformance interdependence of completed model elements. Finally, theobservations are compiled into a method of completion order definition andconflict resolution within this context.5.2.3.1. Quality HeuristicsIn the following, we study the performance semantics of completions basedon the quality heuristics for the completed elements. The performance se-mantics of a completion is defined as the completion’s impact on the com-1965.2. Structured Completion Library for Conflict Reductionpleted element’s performance (observation of a decrease in response timeor utilisation, and an increase in throughput has a positive impact on a per-formance). To this end, we define quality functions used to evaluate dif-ferent completions. We specify three quality functions for the three modelelements that can be annotated with completions in component-based ar-chitectures. These quality functions specify heuristics for identification ofa completion’s performance impact, based on local evaluation. The exactperformance evaluation with a global quality function would in large-scalesystems be hardly feasible. For our problem, the locally defined functions(dependent on a single element) provide already enough information to de-cide about the performance semantic of the completion even for large-scalesystems. The completions are locally applied (to specific model element)therefore this assumption holds. However, the optimisation of system-specific changes is the focus of multi-variant optimisation, such as [113].In this work, we do not consider such change scenarios.As defined in Section 5.2.3, the quality function Q : E →R quantifies thequality of system components, connectors and the infrastructure, based ontheir performance impact, which is under our performance abstraction theprimary metric for our architecture. Note that, the conflict definition relieson two simplifications, which are worth to be discussed. First, it relies onpurely quantitative characterization of system model, not taking the result-ing model structure into account. The reason for this lies in the employedabstraction of viewing the system model through its performance proper-ties. Our experience shows that if the structural changes introduced to themodel are significant, then they either result in an invalid set of model el-ements (and hence are detected during constraint checking), or influencethe performance properties of the model, and hence are detected with Qanyway. Second, it localizes the conflicts only among completion chainsexecuted on the same model element e ∈ E, disregarding from the depen-dencies on other elements in E. Thus, it provides only an indication (theaccuracy of the values is not guaranteed) of the most suitable chain based1975. Completions for Software Performance Engineeringon the direction of the heuristic. However, because of the locality princi-ple our method provides a user with a short localised tests, which do notrequire to run overall system analysis.Let E = Ecomp ∪Econn ∪Ein f ra be the set of model elements represent-ing components, connectors and infrastructures identified in system model.Then, the quality function Q : E → R is based on the type of its argument.The positive semantic of this function is in the direction of smaller valuesand is defined as follows.Component Quality Function:∀e ∈ Ecomp : Q(e) = ∑si∈Srt(si)thp(si),where S is the set of services provided by component e, rt(si) is the meanresponse time of service si, and thp(si) is the mean throughput of servicesi. We do not include service utilisation of underlying system resourcesin the component quality function, because it is highly dependent on theinfrastructure level. This way we hold the quality function independent ofthe remaining elements, while still characterizing component quality fromthe user point of view.Connector Quality Function:∀e ∈ Econn : Q(e) = rt(e)thp(link) ,where link is a communication resource (network) used by connectore, thp(link) is the mean throughput of the link, and rt(link) is the meanresponse time of the communication over the connector (round-trip), de-pendent on the communicating components. Note that, this definition isindependent of the usage of the connector by the connected components.The connector usage is defined by the communicating components. There-fore their quality function has to be defined before.Infrastructure Quality Function:1985.2. Structured Completion Library for Conflict Reduction∀e ∈ Ein f ra : Q(e) = ∑ri∈Rut(ri),where R is the set of available infrastructure resources, and ut(ri) themean utilisation of a given resource.5.2.3.2. Interdependence of Model ElementsThe three types of model elements are in component-based performancemodels understood as layers, with the infrastructure on the bottom, connec-tors in the middle, and components on the top. Based on this layering, theaccuracy of performance prediction is determined by the depth of informa-tion inclusion, starting from the component layer, possibly including theconnector layer, and sometimes even the infrastructure layer. This impliesthe interdependence among the layers, which is with respect to performancecompletion only bottom-up. In particular, the components are completedindependently of the connectors and the infrastructure, connectors comple-tions may be dependent on components, and the infrastructure completionscan be dependent on both the connectors and components.Thanks to the nature of completions applied to the different types ofmodel elements (components, connectors and infrastructure), which con-cern only the internals of the elements, we can claim the completion in-dependence between elements of different types. In other words, havingtwo elements of different types, e.g. a component ecomp and a connectoreconn, we can decide independently of the most suitable completion chainfor ecomp and for econn. The order of choosing the completion chains forthe two elements does not matter. Within each layer, we can see relativeindependence of the elements (of the same type). Having two componentsecomp1 and ecomp2, where ecomp1 requires a service provided by ecomp2, wemay first need to resolve completion conflicts in ecomp2 to have enough in-formation to decide on the optimal completion order for ecomp1. This isimplied by the quality quantification Q(ecomp1) = ∑si∈Srt(si)thp(si)defined over1995. Completions for Software Performance Engineeringthe performance qualities of component’s provided services si ∈ S, i.e. rt(si)and thp(si), which are in PCM defined in a parametric way based on theresource demands of the services.At the connector layer, the connector usage is defined by the communi-cating components. Therefore, completions of connectors could influencethe decision on the component layer. However, it only changes the ratio notthe performance semantic of the completion. The completion independenceof connectors (occupying the connector layer) is guaranteed simply fromthe non-existence of direct connections between connectors, and thanks tothe nature of connector completions, which touch only the internals of theconnectors. The same argument holds for the infrastructure layer that con-sists of a set of resource containers or nodes. Completions applied to oneresource container cannot affect completions applied to another resourcecontainer.This is however the issue only for component elements, which are inter-connected via their interfaces. Having the idea of component reusabilityin mind, we consider components as black-box elements. Throughout thecompletion process we can take advantage of these component-based prop-erties. Additionally, the components use the services (e.g., communicationlink) provided to them by connector. As such we first optimise the compo-nents and only later connectors completion chain. Connector elements areindependent due to their nature of not relying on the rest of the architecture,and there is always only one infrastructure element, hence having nothingto be in conflict with.Based on the above, we adopt the following order of completing the ele-ments in a system model:1. Component layer: Components are independent of all elements inthe remaining two layers of the system model (connectors and the infras-tructure), but are dependent on the components required by their providedservices. To evaluate the quality of the services, we first need to know2005.2. Structured Completion Library for Conflict Reductionthe quality of required services that hence need to be completed and eval-uated first. For this reason, we first connect the components into a calltree (starting in the user interface), and then complete the components in abottom-up fashion, starting from leafs and finishing in the root. If the callgraph contains cycles, then the completion orders for the individual com-ponents can be detected in an iterative way, starting with a seed of random(but valid) completion chain for each component, and iteratively optimisingthe dependent components, propagating the already computed performancevalues from the previous iteration.2. Connector layer: Connectors can be completed independently ofeach other. They may however be influenced by the component elementswhose communication they mediate. Therefore, the completions of con-nectors should follow after the completions of components.3. Infrastructure layer: Last, the infrastructure completes the targetmodel. The infrastructure provides physical services for connectors andcomponents (such as middleware). So it represents the lowest-level detailsthat should be added to the model last. Therefore, we apply infrastructurecompletions in the order from the highest to the lowest layer of softwarestack.5.2.3.3. Conflict Resolution for an Individual ElementIn the ideal case, the completion set CS intended to be applied on a modelelement e ∈ E is not conflicting. Then, we can choose any valid completionchain (permutation order) over CS, and apply the completions accordingto that order. If it is not the case, the idea behind the method of conflictresolution (chain selection) is the following.If a completion set CS is conflicting, then we select the completion chaincc over CS with the minimal value of Q(cc(e)) (with the best performance)and return it as the result to the software architect. This is a suggestion to2015. Completions for Software Performance Engineeringthe software architect. He/She can choose between proposed completionschains with defined performance semantics (increasing/decreasing perfor-mance), however, possibility to change the completion order depends onthe chains supported by the used platform. The completion-chain selectionproblem can be understood as a single-criteria optimization of completion-configuration order with constraints. The constraints define the architec-tural validity of the configuration order (completion chain) for the givenmodel element, and the objective function is given by our quality functionQ that is minimized. Existing algorithms can be employed to solve thisproblem, including popular heuristic-search techniques, which traverse thespace of all candidates (permutations of the given completion set) taking theconstraints into account (excluding invalid completion chains), and searchfor a (near-)optimal candidate to minimize the quality-function value.Pivot Element of a Transformation If v ji yields not only a single modelelement but a set of model elements, we identify the element that resemblesthe starting point of the next transformation, i.e., the pivot element of atransformation. We assume that, for each completion that is to be appliedin a chain, its pivot element has been defined explicitly. In the following,we describe the rule of thumb how the pivot element of a transformationcan be identified for component, connector, and infrastructure completions.• Component Completions build a hierarchy of wrapped components.Thus, the next completion is to be applied to the highest wrapper inthis hierarchy. The pivot element of a component completion is theouter wrapper introduced by the completion.• Connector Completions always consist of an operation and its inver-sion (e.g., marshaling and demarshaling). Both operations are (orcan be) represented by separate components linked by a newly intro-duced connector. This connector is the pivot element of the connectorcompletion.2025.3. Completion Library: Concurrency design patterns• Infrastructure Completions affect multiple connectors or componentsin one container. The container itself is never changed and thus re-mains a constant pivot element.5.3. Completion Library: Concurrency design patternsPredicting the performance of software systems is especially challenging ifsoftware components communicate based on a complex interaction pattern.Such interaction is defined by concurrency, message-based communication,and synchronisation patterns. In the following, we investigate some of thesepatterns. We discuss the integration of performance abstractions in a formof completions on the place of connectors or to enhance components orconnectors. First, we discuss the group of concurency design patterns ingeneral. Second, we give examples of completions in each sub-group ofpatterns. We motivate each of the introduced examples and further discussits feature diagram and sketch the skeleton design of the completion.5.3.1. MotivationParallel programs are generally complex, hard to understand and rise im-plementation and modelling effort. Lee [107] discussed the problems andcomplexity of parallel programs. Despite all the difficulties, the deploy-ment of concurrency concepts in software systems is the most importantpossibility to increase performance. To simplify implementation and mod-elling of parallel software is one of the most important questions of softwareengineering.Today, in the world of multicore processors, the development of paral-lel software is more and more important. The threads and processes couldbe divided between available cores and allow efficient usage of the under-lying hardware [155]. Software developers and software users get double(at least in theory) computation power by adding a second core. Similarly,the performance should rise by processors with four or eight cores. How-2035. Completions for Software Performance Engineeringever, this promised performance increase it is not for free. Programs run-ning on multicore processors have to be specifically structured to use thepromised advantages. The whole architecture should allow for the compu-tation or whole parts of architecture to run in parallel on the available cores.So the software architectures should be designed using parallel structures.Although, introduction of parallel execution promises increase in perfor-mance, the development effort for this increase is high. Additionally, insome cases the performance increase is not so big as expected. Therefore,it is important to test influence of concurrency on performance in advance.Design-time prediction of performance with concurrency allows softwarearchitects to make good decisions and identify where introduction of con-currency is necessary to increase performance and where the increase ofperformance would be too small in comparison to required developmenteffort.In the area of performance prediction the models of parallel software arevery complex as well. For accurate prediction detailed models are neces-sary. Such models include already expert knowledge and low-level imple-mentation details. Often creation of such models in early design time isimpossible or only realisable with a lot of effort. The main idea to solvethis problems is to simplify and refine performance predictions with helpof model-driven performance completions. Sutter and Larus [155] alreadyidentified the need for higher abstractions for concurrency and in this wayto simplify the development of parallel programs. This could be done with ahelp of model constructs, such as completions, that encapsulate the knowl-edge about behaviour and performance parameters of concurrency designpatterns. The design patterns for concurrency reduce the complexity, makethe systems more understandable and modelling simpler. Hence, designpatterns describe generic solutions for known software design problems.This way they help developers to design more effective and robust soft-ware.2045.3. Completion Library: Concurrency design patternsEven though it might be known that a certain pattern influences the qual-ity of a system [143, 51], the extend of the effect in a certain scenariois unknown. Furthermore, a design pattern may affect several quality at-tributes. For example, replication increases the availability of a service, butdoes not impact its performance directly. If multiple patterns are combinedto enhance quality, synchronise components, or ensure data consistency,their overall effect cannot be assessed manually. Schmidt et al. [143] de-scribed the most important design patterns for parallel software. They iden-tified service configuration, service call, event-management, concurrencyand synchronisation as most important tasks for design and implementa-tion of parallel and distributed systems.In this chapter we analyse concurrency design patterns based on theirapplicability in component-based architectures. Furthermore, for some ofthem completion construct are introduced and integrated in PCM. We usemodel-driven performance prediction techniques to evaluate the influenceof concurrency patterns on the quality of a software architecture. Addi-tionally, in the following section, we apply our approach for completionconflict reduction to concurrency design patterns.5.3.2. Categorisation of concurrency design patternsIn our approach, we simplify the design and the development of concur-rent software architectures by completions for concurrency design patterns.We provide predefined parametrized performance completions based on aknowledge about concurrency design patterns and their implementation de-tails. In general, design patterns provide enough information to allow accu-rate performance predictions. Patterns for concurrent and distributed sys-tems address multiple aspects, such as synchronisation, communication,and Quality of Service (QoS). For example, the patterns MonitorObject[143], Thread-Safe Interface [143], Guarded Call [51], and Rendezvous[51] provide different means for synchronisation and communication. Pat-2055. Completions for Software Performance Engineeringterns like Half-Sync/Half-Async, Leader Followers, Reactor, and Proactoras described Schmidt et. al. [143] are used in servers to efficiently dis-patch and process concurrent requests. Furthermore, Replication and LoadBalancing are employed to enhance different QoS attributes in distributedsystems.We apply the conflict reduction method to this group of design patterns.For this purpose, we categorise the design patterns in the conflict groupsusing the levels of conflict reduction introduced in Section 5.2.3. The cat-egorisation of design patterns based on a development roles and their re-sponsibilities separation builds the basis for reduction and avoidance ofconflicts. Additionally, based on this categorisation software developerscan select suitable patterns for certain problem domain without detailedknowledge about their structure. DWe categorised concurrency design pat-terns according to the development roles, that most likely will use them (seeTable 5.1).Event-based communication Synchronisation Concurrency Message-oriented communication Component Developer Scoped Locking Strategized Locking Thread-safe Interface Double-checked Locking Optimisation Rendezvous/Barrier Thread-specific Storage Monitor Object Replication Messaging Endpoints Software Architect Asynchronous Completion Token Pipeline Message Channel Message Routing Message Endpoints System Deployer Reactor Proactor Acceptor-Connector Active Object Half-Sync/Half-Async Leaders Followers Thread Pool Message Bus Table 5.1.: Roles and Responsibilities Separation: Mapping design patterns to de-velopment roles.2065.3. Completion Library: Concurrency design patternsComponent Completions: The category Component Developer includespatterns used for a definition of basic thread-safe components. These pat-terns solve the issues related to parallel usage of the component providedservice, for example, data inconsistency. Here, the patterns supporting dataconcurrency so that task could be executed in parallel on all elements of thesame data structure. This type of concurrency is called data concurrencyand especially patterns for synchronisation deal with this type of concur-rency.Connector Completions: The category Software Architect consists ofpatterns for specification of component interactions, such as coordinationand optimisation of communication between components. It is so calledpipeline concurrency, when data should be handled one after other by anumber of tasks, where parts of the data could be handled by different tasksat the same time. We can distinguish linear (Pipe and Filter), non-linear(Pipe and Filter Pattern with Distributors and Aggregators) or special (Pro-ducer/Consumer Pattern with synchronisation) types of pipeline.Infrastructure Completions: The category System Deployer subsumespatterns that are used to build middleware platforms for concurrent soft-ware systems. For example, the concurrent processing of requests by anapplication server can be realised by a Leader/Follower pattern. So calledtask concurrency patterns in this category are allowing that some task couldbe executed in parallel, that mean the task will be executed in a number ofthreads.There exist many different parallel patterns, in this work, representantsof these patterns were chosen and completions were specified for them.5.3.3. Component CompletionsThe first group of the completions is defined based on design patternsthat affect model elements describing component behaviour. These pat-terns complete behaviour by integrating new actions (e.g. external call,2075. Completions for Software Performance Engineeringacquire or release) into the component’s control flow, or they create wrap-pers around the completed component and delegate its interfaces so that thechange of the component is externally invisible (e.g. Replication pattern orState Manager). For example, all design patterns for synchronisation andthread-safety belong to this group, e.g., Locks, Monitors, State Managersor the Barrier pattern. In the following, we evaluate the Replication patternand introduce completion for this pattern.5.3.3.1. Replication CompletionWe analysed replication completion in [34], where we created a model ofthis completion and provided simulation experiments using different con-figuration options of replication. This section is based on results of theseexperiments.Motivation There are two purposes for replication, thus having multi-ple component instances of one component: improving a software system’sperformance and reliability. The goal of replication is, first, improving re-sponse times for incoming requests, as these can be assigned to differentreplicas, in effect handling several requests in parallel, and second, improv-ing reliability, by assigning the tasks of failed replica to one of its identicalcopies.Front-End ManagerclientServerServerFigure 5.2.: Replication Pattern.In Replication pattern (cf., Figure 5.2), the clients send their requests to,and also get their responses returned from, the Front-End Manager only.How their requests are handled by the Front-End Manager and the replicas2085.3. Completion Library: Concurrency design patternsis transparent to the clients. A Front-End Manager can provide shorterresponse times for its clients by distributing the incoming requests amongthe available replicas. When the Front-End Manager receives a requestfrom a client, it multicasts this request to all replicas. The replicas processthe request, and send a reply back to the Front-End Manager, which in turngathers the replies and selects a final response for the client.There are two basic modes of request handling: active replication andpassive replication. When all redundant replicas process each request, wecall it active replication, or the requests are directed only to a single replica,and the other servers act as backup, then we call it passive replication. Thesecond mode is sometimes called primary-backup replication [147]. In con-trast to active replication, there is only one primary replica. It is the onlyreplica that gets the request from the Front-End Manager, and also the onlyreplica that sends a reply. This reply is sent back to the Front-End Managerand additionally to the other replicas. The other replicas just update theirstate to keep the entire system consistent. Replicas may be stateful or state-less. If stateful, after a change in one replica has been detected, all otherreplicas must be updated to ensure consistency.Replication Completion: Feature Diagram Further, we studiedquality effects of replication with the goal to extract feature diagram, whichbuilds a basis to implement replication completion. Replication intuitivelyimproves reliability. Additionally, load-balancing can improve perfor-mance between number of replicas.However, because of a huge amount of routine work (e.g., copying) whenmodelling replication the cost of the model may increase and maintainabil-ity may be decreased due to higher complexity of the model. Therefore, isespecially important to automate replication mechanism. However, whilewe identified that replication configuration (except replica count) has veryminimal impact on performance, there is still a lot of effort needed to cre-ate models of replication, especially because of changes of topology and2095. Completions for Software Performance Engineeringneeded copies of a large number of elements. Therefore, we created a com-pletion that automates this effort. Impact on performance of this completionis evaluated in following.Based on the domain analysis, we identified features influencing perfor-mance and created feature diagram for replication completion. The featurediagram (cf., Figure 5.4) contains all configuration options, which we as-sume to have an influence on the quality properties of a system.In replication feature diagram the Replica Count property defines howmany identical copies of the component, which is to be replicated, shouldbe created. The results of the simulations reflect the benefit of balancingsystem load among replicas in real-world systems. The system is able togenerate answers faster, the more replicas are available, which is shown bythe averages and medians of the response times, as seen in Figure 5.3 (i.e.,voting 1 to 5 active replicas).The more stress the usage scenario puts the system under, the moreclearly you can see how the system scales. Considering the minimal usagescenario, the addition of a replica to the system makes not much difference.For the balanced usage scenario, the advantage of additional replicas be-gins to show. Compared to a system using a single replica, one with fivereplicas can generate a reply in less than half the time. Eventually, the sys-tem response time is noticeably reduced for the demanding usage scenario,demonstrated by the system becoming almost 4 times as fast the more repli-cas it has available.From the identified options, Load Balancing and Replica Count arestraightforward additions. Which replica is chosen to process a requestcan be decided for every single request, or for all requests per client. Wemodel the per-request choice only. Different strategies for the load balanc-ing decision are available, namely "Random", "Round Robin" and "FirstAvailable". A Front-End Manager using the "Random" strategy choosesone replica randomly for each received request, which will then process it.While not optimal, this strategy offers a significant increase in performance.2105.3. Completion Library: Concurrency design patternsFigure 5.3.: Random Load Balancing: Graphical comparison of the response timeaverages for three differently demanding usage scenarios.With the "Round Robin" strategy, the Front-End Manager defines an orderon its available replicas. Following this order, every request is forwardedto the currently selected replica, and the next replica is selected, one afteranother. With the "First Available" load balancing strategy, a Front-EndManager assigns each client to a randomly chosen replica. All requestsreceived from an assigned client are then always processed by the samereplica. In the case of the last two strategies, the Front-End Manager needsto keep track of the current state of its replicas.In the distributed variant of replication, a new resource container is cre-ated for every replica of the component. These resource containers get thesame processing resource specifications as the resource container that con-tains the original component. We replicate homogeneously (i.e., togetherwith all components on it, leading to identical server replicas) to make thesystem more manageable and the overview easier. On the other hand, iflocal replication is chosen, the already existing processing resources are2115. Completions for Software Performance EngineeringUniformFirst Availaible Round Robin RandomVoting StrategyMulticast TypeReplicationLoad BalancingLegendorexclusive ormandatoryoptionalBasic ReliableN of M PrioritisedReplica CountFigure 5.4.: Feature diagram for the replication design pattern.multiplicated inside the original resource container. This is done as manytimes as the replica count option specifies, so that every local replica has itsown exclusive set of resources.We also added the Voting Strategy to our feature diagram. We think thevoting strategy is a major factor for reliability. This becomes important forsafety-critical systems, which we also want to allow to be simulated. Acommon application of the "N of M" voting strategy is absolute majorityvoting. Taking a system with five replicas as example, an absolute majorityis achieved when three identical responses are returned, and the Front-EndManager may already send the response to the client without waiting for theremaining two replicas. However, we can support an arbitrary number ofrequired answers without additional effort. This may be of use for a systemarchitect who needs less certainty than a total majority, or who needs aneven higher certainty of the correctness of the gathered answers. The basicidea behind the rules for N of M voting is using a counting semaphore,stopping the main execution thread until enough replicas have finished andreplied. Additionally, we need to insert a mutex, so that each thread canuse the semaphore exclusively, undisturbed from other threads. Otherwise,it would be possible that race conditions occur. When evaluating the Nof M voting strategy, we determined that the number of required answersinfluenced performance. Factoring the influence of the replica count intothe voting strategy, both N and M are important options.2125.3. Completion Library: Concurrency design patternsThe choice of the multicast type concerns data consistency among repli-cas. When basic multicast is chosen, nothing needs to be changed in themodels. In this mode, requests are forwarded from the Front-End Managerto all replicas without taking any steps to ensure data consistency.Reliable multicast, however, is implemented using acknowledgements inactual systems. A replica sends an acknowledgement back to the Front-EndManager when it received a request. The Front-End Manager can therebyverify that all replicas received the request successfully. Therefore, ac-knowledgements improve the reliability of the communication between theFront-End Manager and its replicas, at the expense of increased networktraffic. We can model this by adding the usage of a network resource, whilechanges to other models are not necessary.Multicast TypeServerNClient Front-EndRequiredReplies=NServer2Server1......acquireProbabilistic Branch...acquire ServerN releaseacquire Server1 releaseacquire Server2 release *NUniformFirst Availaible Round Robin RandomVoting StrategyReplicationLoad BalancingBasic ReliableN of M PrioritisedReplica CountNN1...N=Required RepliesN=Required RepliesFigure 5.5.: Replication Completion Skeleton.2135. Completions for Software Performance EngineeringReplication Completion: Completion Design In PCM a compo-nent instance can be replicated in two ways: first, on the assembly layer,i.e. a component instance in two different contexts is composed to buildthe system; second, on the deployment layer, i.e. a component instance ismapped to several deployment contexts. The replication on the deploymentlayer is invisible in the systems structure. Therefore, software (e.g., paral-lelizable software) that could gain advantage from the replication can not betested for it properly. Another point about deployment layer replication isthat all the replicas are actually copies, concerning the functionality, qualityproperties and deployment environment. The replication on the assemblylayer does not implicitly mean this level of equality between replicas. Insome scenarios where, for example, the most performant replica has high-est priority, it is appreciated when this information propagates to the sys-tem architect as well. Therefore, we implemented only the replication onassembly level, anyhow, it is conceptually very similar to realise replicationon the deployment level.When a component should be replicated, first, a Front-End Managercomponent is inserted into the system (cf. Figure 5.5). Second, the repli-cated component is copied a number of times, as defined by the value of thereplica count. Front-End Manager shall manage the requests that formerlywere sent to the replicated component directly, therefore, it provides thesame interface as the replicated component. Furthermore, the Front-EndManager requires the same interface a number of times, determined by thevalue of the replica count, so that it can forward the requests to the replicas.In the system diagram, the replica count determines how many replicatedcomponents and connectors to them are created. Furthermore, the repli-cated components can require services from other components. We candeal with these required components twofold: first, all the required compo-nents as replicated too; second, only the selected component is replicated.In our solution, all components that provide a service used by the replicatedcomponents are replicated as well, such could become a bottleneck for the2145.3. Completion Library: Concurrency design patternssystem, if they resided on the original, local resource container. Withoutreplicating these components as well, each would be accessed by all repli-cas concurrently, provoking system overload. However, we assume thatthere is small number of these required components (not more as two) andwe replicate only components originally located in the same resource con-tainer. This approach, however, should be further evaluated, which is outof scope of this work.Another important point is that we can replicate these additional com-ponents without additional changes, because all components are originallystateless in the PCM. Would they be stateful, we would have to ensure syn-chronisation and data consistency via additional constructs. The statefulextension of this completion is required at this point, similarly as it wasdone of the MOM completion in Section 7.2.1, this is part of the plannedfuture work.Based on the option distributed or local for the replica location, a new re-source container is created for every replica of the component or the alreadyexisting processing resources are multiplicated inside the original resourcecontainer. This is done as many times as the replica count option specifies,so that every local replica has its own exclusive set of resources. The cre-ated resource containers get the same processing resource specifications asthe resource container that contains the original component.The voting strategy is simulated with the passive resource of capacityequal to the required number of replies from replicas. Each replica releasesthe passive resource when finished. The Front-End has to acquire the wholecapacity of this resource before sending reply to the client. Thus, the wait-ing for the replicas to finish is simulated.The load balancing strategy is simulated by a probabilistic branch wherenumber of branches is determined by the value of the replica count. In eachbranch one replica is called. The model of "Random" strategy is straightfor-ward, for example, when we have 2 replicas each of the branches gets theprobability of 50%. The model of "First available" and "Round robin" re-2155. Completions for Software Performance Engineeringquires stateful extention. However, because experiments [55] showed a lit-tle difference between these strategies we model these strategies with simi-lar model as for the "Random" strategy. For exact model of these strategieswe plan the stateful extention in the future.Replication Completion: Summary We identified the features ofreplication that are included in the feature model and modelled with themeans the PCM provides. These features were evaluated on a relevant im-pact on performance of a simulated architecture. Additionally, we imple-mented a completion in a form of feature model with related transformationfragments.The future work for the replication completion includes to evaluate theother alternatives to active replication, such as passive replication with aprimary replica or stateful replicas. Another area for future work is mod-elling and evaluating local replication. This should become possible oncethe implementation of multicore support in the PCM is completed, thatmeans utilising multiple processing resource definitions of the same type inone resource container.5.3.3.2. State ManagerWe analysed the stateful components and implemented stateful extension tothe MOM completion, which is further explained and validated in Section7.2.1. This completion was then implemented using the technique intro-duced in Section 7.2.1 and resulting transformation is evaluated in Section7.2.3. In this section, we introduce necessary changes and extensions tothe PCM allowing modelling of stateful components. In Appendix A, wefurther discuss stateful performance engineering and related concepts. Be-cause this completion is not an explicit construct available to the users, aState Manager is in current PCM used only as extension of existing comple-tion, we do not introduce a feature diagram. The reason for this decision (in2165.3. Completion Library: Concurrency design patternsPCM) is the possible complexity of stateful models that would be allowed,if the stateful concepts were available explicitly.Motivation In the following, we give an example for the influence ofstate on software performance which is taken from the area of messagebased systems. In particular, we are interested in the delivery time (timefrom sending a message until it is received) of messages send within a trans-action. Messaging systems, which implement the Java Message Servicestandard [74], explicitly support transactions for messages. The transac-tions guarantee that all messages are delivered to all receivers in the orderthey have been send. To achieve such a behaviour, Sun’s JMS implemen-tation MessageQueue 4.1 [1] waits for all incoming messages of a transac-tion and, then, delivers them sequentially. Figure 5.6 shows the measuredFigure 5.6.: Time series of a transaction with 1000 messages per transaction set.delivery times for a series of transactions with 1000 messages each (thesender initiates a new transaction (as part of a session), passes 1000 mes-sages to the MOM, and finally, commits the transaction). All messagesarrive within the first 0.4 seconds and are delivered sequentially within the2175. Completions for Software Performance Engineeringnext second. This behaviour leads to delivery times of 0.4 seconds at min-imum. The delivery times grow linearly until the transaction is completed.In this example, the position of a message in the transaction set determinesits delivery time. Thus, the measured delivery times are not independentand identically distributed but strongly depend on the number (and size) ofmessages that have already been sent. As a consequence, to predict perfor-mance accuratelly we need to keep track of the messages that are part of atransaction. Additionally, the periodical utilisation of resources (e.g., CPU)influences performance. To model such a behaviour, we need a notion ofstate as part of our performance model.State Manager: Completion Design In the MOM Completion in-troduced in [76] the transactional delivery is not supported, because of re-quirement on the PCM that prohibits to use stateful components becauseof complexity issues. We decided to extend MOM Completion so that theusage of stateful components will be hidden. The Statefull Manager will beinserted by the transformation into the target model as an wrapper aroundpreviously stateless component. This wrapper will then manage calls to themethods of the component based on the state value.We extended the component behaviour model of the PCM (the SEFF) toallow the modelling of component internal state. With this extension, alsosystem specific global state (cf. Appendix A) can be modelled by adding ablackboard component that makes its internal state available to other com-ponents in the system. Only two additions to the PCM metamodel are re-quired to model component internal state and global system state. First,we declare a set of state variables for a component. Only a declared statevariables can be used within a SEFF. Second, we add a SetStateActionto the SEFF, which allows to set the state variable to a given expression.Input data of the SEFF, other state variable values and the previous statevariable value can be used in the expression. Now, the state variable can be2185.3. Completion Library: Concurrency design patternsMessagingPoint-to-Point ChannelPublish-Subscribe ChannelMessage ChannelPool SizeCompeting ConsumersExclusive ORMandatory FeatureOptional FeatureSelective ConsumerDurable SubscriberTransactional ClientTransaction SizeGuaranteed DeliveryLegendReceiverSenderGuarded BranchisTransaction=trueisTransaction=falsesetState callServer commitTransaction[VALUE=state + 1]callServer[transactionSize==state]N=Transaction SizeState ManagerServerisTransaction=truetransactionSize=Nstate=0Figure 5.7.: MOM Completion Skeleton for transactional delivery.used in branch conditions or resource demands as a parameter. The use ofPCM Stateful extension is illustrated in section 7.2.1.Figure 5.8 illustrates the PCM extension. Assume a Component Aprocessing data. It performs clean-up task after each Megabyte of pro-cessed data. Thus, it keeps track of the amount of data processed. Inthe model, we store the limit of 1 MB in a component parameter nameddataLimitInMB.VALUE, defining component configuration state. We de-clare a state variable processData.VALUE and initialise it with the value0, defining component internal state. The SEFF of the component is shownin a state-chart-like notation in the figure. First, we modelled a Set-StateAction to add the currently processed amount of data (availableas inputData.BYTESIZE) to the processData.VALUE variable. Then,the data is processed in the InternalAction process. We omitted the re-source demands for brevity. After processing the data, we check whethera clean-up is required in the BranchAction. If processData.VALUE >=dataLimitInMB.VALUE, we do the clean-up of 1 MB and set back the state2195. Completions for Software Performance Engineering<>processedData.VALUE = processedData.VALUE + inputDate.BYTESIZE / 10^6<>processedData.VALUE >= dataLimitInMB.VALUEprocessedData.VALUE < dataLimitInMB.VALUE<>cleanUp<>processedData.VALUE = 0<< InternalAction >>process<>dataLimitInMB.VALUE = 1<>processedData.VALUE = processedData.VALUE - dataLimitInMB.VALUEFigure 5.8.: Example stateful SEFF.to processData.VALUE - dataLimitInMB.VALUE. The second branch isempty.State Manager: Summary An extended PCM model can be analysedwith the extended version of the SimuCom simulation presented in [18] toobtain the performance metrics. At simulation runtime, each componentis instantiated and holds its state variables. When a SetStateAction isevaluated, its expression is evaluated and stored in the state variable. IfBranchActions and InternalActions access state variables, the valueis retrieved. The extension increases the expression power of SEFFs andallows programming, although the language does not become Turing com-plete (all loops are bounded). As multiple requests to the system are anal-ysed concurrently, we can encounter race conditions and resulting unex-pected behaviour. In our example above, race conditions are excluded be-2205.3. Completion Library: Concurrency design patternscause the branch condition and SetStateAction are evaluated in the samesimulation event (no time passes in simulation). However, in general, if aresource demand is executed between reading the state in a BranchActionand setting the state in one of the branches, both actions are executed inseparate simulation events. Here, a second request to the component couldread or change the state in between, leading to race conditions.With the extended state modelling, steady-state behaviour is not guar-anteed any more. While this limits analysability, it also can help to detectproblems in a software design. For example, assume a system service thatbecomes the more expensive the more requests have been served. Then,the response time of the system will ever increase (’The Ramp’ antipat-tern [147]) and no steady state can be reached. With the extended statemodelling, this performance antipatterns can be detected in the simulationresults.5.3.4. Connector CompletionsAssembly connectors [165, 12] are the most complex type of model ele-ments that can be enhanced by completions. For connectors, several per-formance completions can be applied on one connector instance so thattheir order has to be determined.The first kind of completion provides details about the type of the con-nector, i.e, whether it is 1:1, 1:n, or n:1. Connectors of type 1:1 are typicalmessage passing or RPC style connectors which connect a single clientcomponent instance to a single server component instance. In case of 1:nconnectors, a single client component sends requests to a set of server com-ponents which is semantically the case for server replication scenarios orvoting based server queries. Finally, n:1 connectors are the usual case of nclients instances talking to a thread-safe server instance.Orthogonal to the type of the connector, connector performance com-pletions also include details about the processing of the communication2215. Completions for Software Performance EngineeringSenderMiddlewareReceiverMiddlewareMiddleware SystemSenderAdapterReceiverAdaperConnector CompletionMarshalling DeMarshallingWrapperIFoo IFoo’ IFoo’ IFoo’ IFoo’ IFooIMomIMarshalling IMarshallingISender IReceiverPlatform-specific Middleware ComponentsFigure 5.9.: Connector Middleware Completion [76].(synchronous or asynchronous) in the participating middleware layers as il-lustrated in Figure 5.9 [76]. Here we find services for message marshaling,message encryption, call authentication, message compression, etc. Forthese types of message processing steps, existing performance completionsinsert a completion component for each processing step. However, the or-der of these services is important because of the differences in the dataflow involved. For example, the size of the message to be sent over thenetwork is different if the message’s body is first encrypted and then com-pressed versus an initial compression followed by a subsequent encryptionstep. Hence, for the processing steps the order of application of a set ofperformance completions does matter and needs clarification. We analysethis issue further in Section 7.2.2.Connector completions rely on introduced components which reflectthe performance related behaviour of the used middleware. As a conse-quence, these middleware components implement both, the resource de-mand caused by the middleware’s processing but also the data transforma-tions they perform on the message to be sent over the network. Note, thatin some usecases the size of the message is not of major interest for theoverall performance of the network link. In such cases, the data transfor-mations become neglectable and consequently also the order of applyingthe corresponding performance completions does not matter any more.As a result of the discussion of connector completions, we can concludethat we need at least two types of annotations. The first annotation class2225.3. Completion Library: Concurrency design patternsdetermines the connector kind and defines the exact implementation se-mantics of 1:1, 1:n, and n:1 connectors, e.g., whether voting or replicationis used for a 1:n connector. The second class of annotations defines the pre-and post-processing details of the messages used by the connector for re-mote communication. Here, the annotation gives details about marshaling,encryption, compression, etc. A clear definition of the order in which suchcompletions are added to the performance model is necessary to get ac-curate performance predictions from the refined performance model. Thissection gives details on how to build more complex connectors, based onan abstraction inspired by Pipe&Filter pattern.5.3.4.1. Pipe&Filter ConnectorIn this section, we present the architecture of performance abstractions forconnectors, the feature diagrams we developed and finally the architecturewe implemented in transformations for the PCM. This section is based onour work presented in [119].Motivation Because, we aim to model only performance abstractions ofconnectors we can abstract from the functional details and concentrate onthe performance-relevant dependencies. In general, from a performancepoint of view connector is a chain of components producing a load depen-dent on the size of data to send. The exact functionality of connectors isnot of the interest for the performance prediction. Therefore, it is possibleto model connector as a chain of activities whose performance determinesthe performance of the whole connector. The performance of the connectorthen depends only on the properties of transferred data (such as data byte-size). In such highly abstract connector model we can simplify connectoron two types of activities: buffering of transferred data and computationor I/O activities with the data. Which is very similar to the Pipes & Filterspattern, which is an architecture pattern for data stream processing systems.The connectors’s task is then divided into several independent incremental2235. Completions for Software Performance Engineeringprocessing steps (filters) connected by pipes, altogether forming a pipeline.Pipe Filter PipeServer RoleClient Role Processing StepFigure 5.10.: Mapping the connectors on the abstractions in the performance model.In our case the scope will be connectors and their tasks. We will usepipes and filters to model connectors which in turn are assembled using ba-sic constructs provided by PCM. The main advantage would be high levelof abstraction and low-complexity of the composition of independent tasksin connector. We build all the connector variants from the basic constructs,e.g. pipes and (active/passive) filters. The connectors will be variableconsidering non-functional properties and other aspects of communication.The advantage of our approach is that we need to compose multiple in-stances of two simple building blocks (pipe and filters) and calibrate themwith performance data. In addition, our approach to build performance ab-stractions of connectors simplifies the generation technique because it isenough to have a few of reusable fragments of transformations (in our casethree: pipe, active and passive filter) that could be composed to generatethe connector (cf., Figure 5.10). The connectors we modelled within thePCM are based on [30].The settings in which a particular connector can be used are determinedby its topology. Four different topology types can be distinguished [30] asshown in Figure 5.11.2245.3. Completion Library: Concurrency design patternsdMessagingBlackboardbbc sccProcedure Calln:1Streamingfull duplex1:1w rrrhalfduplex1:nFigure 5.11.: Connector Layout.The Procedure Call Connector features unidirectional communicationfrom multiple client components (c) to one server component (s). It oper-ates in both a synchronous and an asynchronous call mode. However, itsinfluence on the performance is significant, the communication of multipleclient components with a single server component (n:1 relationship) can bemodelled.The Messaging Connector has a typical star layout. In the middle there isthe distributor unit (d). A component can be connected as sender, receiveror both. It operates only in an asynchronous mode.The Streaming Connector comes in two variants. The Full Duplex im-plementation features bidirectional point to point communication for twocoequal components. The Half Duplex variant limits communication to onedirection with one writer component (w) whilst enabling multiple receiver-s/readers (r). As is the nature of streaming transactions they are processedin an asynchronous mode.The Blackboard Connector has a star shaped layout similar to the mes-saging connector. In the middle there is the black board storage (bb). Everycomponent is attached to the connector by a provided and a required inter-face. Through the required interface it can send write and read requests2255. Completions for Software Performance Engineeringto the storage. Write requests are processed asynchronously while readrequests operate synchronously.Through the provided interface the compo-nents can be notified about changes to the blackboard.Pipe&Filter Connector: Procedure Call Feature Diagram In thefollowing, we introduce in more detail the structure of Procedure Call Con-nector. The architecture of this connector is shown in Figure 5.12. Theconnector is divided in two deployment units, one for the client and onefor the server side. They are allocated to the resource containers of theirrespective component. The simplest form is the point to point connectionfrom one client to one server, thus also featuring only one client and oneserver deployment unit. In general, multiple clients are possible.Figure 5.12.: Procedure Call connector architecture [30].2265.3. Completion Library: Concurrency design patternsWhen considering the individual elements from which the connector (cf.,Figure 5.12) is composed, many of them can be mapped directly to theabstractions based using simple pipes and filter components.The client adaptor maps to a single filter in our model. Its resourcedemands are configurable over a feature diagram. The Stub, the next ele-ment of the connector, is a composed element consisting of smaller tasks,from them the distributor and encryptor/decryptor are of interest to us. Inour model the encryptor/decryptor is also realized by a filter. The distrib-utor is resembled by a filter with multiple required interfaces. Its SEFFdoes not contain resource demands, but chooses which required interfaceor interfaces the outgoing call shall invoke. The first element in the serverdeployment unit is the skeleton, which is again a composed element andthe counterpart to the stub. From its subelements the encryptor/decryptordefine a coupled pair of filters in our model. The synchronizer is used toestablish the beginning of a critical section. Usually it is used to guardcode which is not thread safe. In these cases the capacity for the criticalsection will be set to one. It is also possible to choose another value ifthe resource, the critical section guards, has a higher capacity. The nextelement manages transactions. This functionality is already covered by theMiddleware completion. In our model there is a placeholder which is refer-enced by the transaction feature in the feature diagram. The server adapterand interceptor are analogous to their client counterparts. The Intercep-tor implements the Monitoring feature, which allows to interrupt passingcalls. In our model it resembles a special filter component with an addi-tional required interface through which it sends the call before passing italong down the connector. Intended for profiling (creation of statistics) theinterceptor can be used very flexibly, making it an all-purpose processingstep.Our feature model is shown in Figure 5.13. The node labelled targetconnections resembles a list of all assembly connectors which are to bemerged into this connector. As it can be annotated with multiple values, it2275. Completions for Software Performance EngineeringProcedure CallCompressionReplication(Replication)Encryption(Coupled)AdaptionClient Server(Filter) (Filter)InterceptionClient Server(Interception) (Interception)DistributionRemote LocalTransactionsSynch AsynchServer Worker ManagementCritical SectionLegendorexclusive ormandatoryoptionalTarget ConnectionsBuffer Size (x2)(Coupled)WP SizeEnabled Buffer Size (x2)CapacityFigure 5.13.: Procedure Call Feature Diagram.is illustrated as multi node. Only assembly connectors of the same interfaceare allowed. The other multi node labelled synch/asynch configures if callsshould be performed in the synchronous or asynchronous mode. It doesthat for each method signature within the used interface. It does only makesense to activate the asynchronous mode for a method with no return valueor if the return value is not used by the callee. As soon as there is at leastone method, operating in the synchronous mode, some subtrees have to beduplicated. This is because the synchronous calls travel through the con-nector twice. By duplicating the trees resource demands, worker pools, datasize changes and buffering capacity can be configured two times. When-ever a node and all of its child nodes have to be duplicated it is indicated bya (x2).The server worker management subtree configures the buffering capac-ity of the last pipe and if the server should be connected to the connectorsworker management. By enabling it, a BoundedSinkAdapter is usedinstead of the normal SinkAdapter. When it is disabled, the buffer ca-pacity has no effect on calls travelling to the sink, because it accepts allcalls instantly. However the second buffering capacity very well has effecton returning calls. This is not reflected in the feature diagram, because it2285.3. Completion Library: Concurrency design patternswould have made the diagram even more confusing. The critical sectionfeature adds the synchronizer component to the connector. When select-ing it, the number of calls which are allowed to enter the section has to bechosen. The transaction feature is set in grey because it refers to anothercompletion as mentioned before.Filter (x2)WP Sizeper MethodManual LibResource DemandBytesizeModificationBuffer SizeFigure 5.14.: Filter Subtree.The adaption feature can be enabled for either the client, server or both.Deploying both adapters may be necessary due to communication methodsor the use of middleware. Because the adapters are implemented by simplefilters, the filter subtree (cf. Figure 5.14) is referenced for both adapters.The fact that a node represents a subtree is illustrated through a thickerframe. Per filter the worker pool size and the buffer sizes of the pipe infront of the adapter have to be set. Also per filter the resource demand andbyte size change has to be configured for every method. It is possible tochoose these from a library with predefined formulas. However the libraryis not supported by our work, but can be retrieved from the work of Beckeret al. [10, 14].Compression is a feature a coupled feature in the feature diagram (cf.,Figure 5.13). The feature node references the subtree for coupled activitieswhich can be found in Figure 5.15. It merges two filter subtrees into one,because some values appear twice. For example if the connector operates in2295. Completions for Software Performance EngineeringCoupled (x2)ClientWP Sizeper MethodManual LibApplicationBytesizeModificationReversionResource DemandResource DemandBytesizeModificationServerWP SizeClientBuffer SizeServerBuffer SizeFigure 5.15.: Coupled Activity Subtree.synchronous mode, the values (resource demands and data size change) forthe compression would be configured once for the first filter and again forthe second filter (for returning calls). The feature is implemented by simplefilters and is intended to reduce the size of the calls data before sending itover the network. When it is enabled, it adds one filter to the client andone to the server deployment unit of the connector. The worker pool sizeof these filters and the capacity of their pipes can be configured separately,as shown in the coupled activities subtree. The compression method can beeither set manually or retrieved out of a predefined library. It can be config-ured individually for each method which the connector supports. Howeverwe cannot support such a library in the scope of this work, so the node isset in gray. Note that it is possible to add special parameters to the call(e.g. entropy). These can be used in the compression formulas to achieve amore accurate prediction than solely though data size consideration. Mid-dleware completions may contain compression completions. This has to beconsidered by the connector completion developer, so that no conflicts be-tween these completions arise. The encryption feature is also realized as acoupled activity. The configuration is analogous to that of the compressionfeature.2305.3. Completion Library: Concurrency design patternsReplicationReplication Countper ReplicaResource ContainerDistributor WP Size (x2)PolicyBuffer Size (x2)Figure 5.16.: Replication Subtree.The replication subtree references the replication completion, which wasalready introduced in Section 5.3.3. The replication and connector comple-tions should be linked in the Completion Library, so that they can be appliedtogether and do not conflict. Compression, encryption and replication onlymake sense, if the connector is not located within one resource container,because this means that calls have to travel over a network connection. Theconnection quality feature is not included in our feature model. This isbecause the architecture of the connector does not influence the connec-tion quality. In the PCM the connection quality is defined by the resourceenvironment.Pipe&Filter Connector: Procedure Call Completion Design Inthe following, we discuss the structural elements creating completion skele-ton. These structures map the features introduced by the feature diagram.The architecture of the full featured client deployment unit is shown in Fig-ure 5.18. For the sake of clarity we did not include the worker management.Each pipe is configured over the feature of the filter to its right. The clientunit fans out at the distributor. Exemplarily it is illustrated with three out-going interfaces. It is only contained, if replication is enabled; i.e. there ismore than one server.A more detailed view of how the distributor is connected to the workermanagement of all adjacent pipes can be found in Figure 5.17. We called2315. Completions for Software Performance EngineeringPipePipeDistributorFilterFilterFigure 5.17.: Distributor Worker Management.the filter which handles encryption and decryption cryptor. It is possible forthe client unit to be completely empty, if none of its features are selected.PipeInterceptorPipe PipeAdapterPipeCompressor DistributorPipeCryptorClient ComponentServer UnitFigure 5.18.: Procedure Call Connector Client Unit.Figure 5.19 shows a fully featured server deployment unit. Each con-nected client unit gets its own pipe. This has to be considered becausethe first processing step can vary, dependent on the selected features. Thesyncher marks the beginning of the critical section. It takes the place of apipe and its buffering capacity is determined by the feature configuration ofthe following processing step. When operating in the asynchronous mode,the SEFFs of the pipes which follow the syncher must not fork the call.However it may be possible to shift the syncher in the direction of the sink2325.3. Completion Library: Concurrency design patternsas long as the single processing steps are thread safe. The minimal serverunit consists only out of the sink and its pipe.PipeCryptorPipeSyncherCompressorPipeTransaction ManagerPipeAdaptor InterceptorPipeSinkPipePipeClient UnitsServer ComponentFigure 5.19.: Procedure Call Connector Server Unit.Pipe&Filter Connector: Summary In this section a connector com-pletion (Procedure Call Connector), its feature diagram and architecture de-sign, was discussed. The concept of Pipe&Filter abstractions for connectorssimplifies the design of models. It provides an overall concept for compo-sition of connectors from simple building blocks suitable for performanceprediction. The resulting connectors model very accurately blocking effects(limitation of concurrency) in connectors, simple asynchronous communi-cation and when they are calibrated the predictions using these models arevery accurate (cf., Section 7.2.2). In addition, the transformations inte-grating these connectors could easily reuse transformations fragments (cf.,Appendix C).5.3.5. Infrastructure CompletionsToday, many applications (e.g., Web servers, Database servers) are de-signed to process a large number of short tasks that arrive from some remotesource (using for example messaging, HTTP, FTP). In the case of server ap-2335. Completions for Software Performance Engineeringplications, processing of each task is short-lived and the amount of requestsis large. The infrastructure completions introduce possibilities how to man-age incoming tasks based on different threading models. We discuss theperformance of these models.Thread-Per-Request model A simple model to deal with incomingtasks would be to create a new thread each time a request arrives and pro-cess the request in this thread. The Thread-Per-Request model has a signif-icant disadvantage in producing overhead when creating a new thread foreach request. A server will spend more time and consume more systemresources creating and destroying threads than it would processing actualrequests. As a consequence the cost of creation could significantly hamperperformance. Additionally, each active thread consumes resources (CPU,Memory). Too many active threads (in one JVM or Application Server)could result in excessive memory consumption and the system could runout of memory. To prevent such problems, applications need some meansto limit number of requests processed at the same time. The Thread-Per-Request model is suitable when the frequency of task creation is low andthe mean task execution time is high. However, there are other ways howto support use of multiple threads within a server application, as describedin the following.Single-Background-Thread model Another common threading modelintroduces a single background thread and request queue for tasks of a cer-tain type, which is not suitable for long-running tasks or for high-prioritytasks where predictability is important. With the Single-Background-Threadmodel executing of asynchronous I/O-intensive operations is difficult. Ad-ditionally, this model is not optimal on multi-core systems because of itslimited parallelizability.2345.3. Completion Library: Concurrency design patternsLegendorexclusive ormandatoryoptionalThreadPoolOptimizationPropertiesStaticThreadPool PolicyDispatcherDynamicPool Size Core Pool SizePriority LanesParityThread BorrowingPrioritySpecified NativeGuardSemaphore ConditiondependsMaximum Pool SizeThread ManagmentThreadPerRequest Single-background ThreadKeepIdleTimeQueue SizeWaiting QueueDirect Handoffs Unbounded BoundedKeepAliveTimeMax ThreadsFigure 5.20.: The generic configuration model of thread management strategies.Thread Pool model The Thread Pool design pattern offers a solutionto the problem of thread creation, management and destruction overhead,and the problem of excessive resource usage. The point of the Thread Poolis to avoid creating lots of threads for short tasks. The Thread Pool pat-tern reuses each thread for multiple tasks. This way the overhead neededfor thread creation is spread over many tasks. Additionally, because threadalready exists when a request arrives, the delay introduced by thread cre-ation is eliminated and request is serviced immediately. Thread Pools arewidely used by many multi-threaded applications. The main advantages areallowing processing to continue while waiting for slow operations such asI/O-intensive tasks, and exploiting the availability of multiple processors.However, usage of Thread Pool deals with certain risks.Thread Management: Feature Diagram Based on the previous dis-cussion, we extracted important performance-relevant features of threadmanagement in a form of feature diagram. These features summarize differ-ent configuration options of the thread management implementation. Theresulting feature diagram is illustrated in Figure 5.20The software architect has a possibility to decide between Thread-Per-Request, Single-Background-Thread or Thread Pool model. The features in2355. Completions for Software Performance Engineeringthe Thread Pool subtree are described already in Section 3.3.2.4. For theSingle-Background-Thread model is an important configuration attributethe size of the request queue. These patterns have a prominent impact on theperformance due to its ability to limit the level of concurrency in the system.The Thread-Per-Request model separates the processing of incoming andoutgoing requests and for each direction we can define a maximal capacityof the system. This completion belongs to the infrastructure completions,for which we allow only one of these completions per resource container,consequently, no conflicts are possible.ThreadPoolOptimizationPropertiesStatic DynamicPool Size Core Pool SizeMaximum Pool SizeKeepIdleTimeWaiting QueueDirect Handoffs Unbounded BoundedKeepAliveTimeThread ManagmentThreadPerRequest Single-background ThreadQueue SizeMax ThreadsServerClientThreadPool_ININWrapperPool:size=NThreadPool_OUTOUTWrapperPool:size=Nacquire release acquire releaseN=Max ThreadsN=Max ThreadsN=1N=Pool Sizerelease()release()acquire()[release()]acquire()[release()]Figure 5.21.: The structural completion skeleton of Thread Management.Thread Management: Design Dispatching and the management ofthreads are addressed by a set of patterns dealing with thread managementand the infrastructure’s support for concurrency. Therefore, completionsfor dispatching annotate resource containers to which necessary compo-nents can be allocated. From the perspective of performance prediction,2365.3. Completion Library: Concurrency design patternsthese patterns can be abstracted as variations of the Thread Pool pattern.We designed performance component-based abstractions for thread man-agement patterns: (cf., Figure 5.21) i.) Single-Background-Thread: Theabstraction realises synchronous communication. This pattern could be ab-stracted as Thread Pool with a size of one thread for a client; ii.) Thread-Per-Request: The pattern separates the processing of incoming and outgo-ing requests. For each type there is a distinct pool of worker threads. There-fore, we can abstract the pattern as incoming and outgoing Thread Pool cou-ple with a size equal the capacity of the system; and iii.) Thread Pool: Thepattern abstraction is a version of a Leader-Follower pattern where one par-ticular thread takes the role of the leader and waits for the next request. Allother threads are either queued (i.e., followers) or processing requests (i.e.workers). To model this pattern we can easily use one Thread Pool compo-nent with a size equal the capacity of the system. The overview about therequired changes (e.g., adding/removing components) of the model helpscompletion developer with later implementation. Therefore, he is requiredto first model per hand a completion skeleton for each feature and validatethem. Based on these analysis he can choose appropriate abstraction andimplement the change mappings. In Figure 5.21 the mappings are illus-trated by arrows. The semantic of these arrows is addition of the selectedcomponents, interfaces, methods or values to the model.Thread Management: Summary In this thesis, we focused on theThread Pool completion, which is used as a running example. The val-idation of Thread Pool completion is provided in Section 7.2.1. In ad-dition, different implementation of the transformations integrating ThreadPool completion are discussed in Section 7.2.3.2375. Completions for Software Performance Engineering5.4. DiscussionIn the following, we discuss the assumptions and limitations of the contri-butions presented in this chapter.Structured Metamodel The strongest assumption of the introducedapproach is that we expect the metamodel to be designed with a certainstructure in mind. However, the current state-of-art in MDSD does not pro-vide a standard set of best practices for metamodel design. Metamodels aremostly designed on demand, without clear guidelines for design and in ad-hoc manner. We showed that structured design of metamodel can supportother engineering processes using this metamodel language. Thus, we seehere a great potential for future research.Size of the conflicting set We assume that the conflicting set after theconflict reduction is so small that it is possible to resolve remaining con-flicts manually. As the principle of separation of concerns already dividesdifferent completions in a responsibility of different roles, thus, comple-tions in one group are semantically very similar, we do not expect a hugenumber of choices from a number of completions for one role and one ele-ment. For example, it is not reasonable to deploy one component using twodifferent messaging middleware completions. Thus, it is very likely thatthe remaining group of completions would be rather small.Independence of model elements We assume that independent en-hancement of three element types (i.e., components, connectors, infrastruc-ture) in CBSE is possible. In particular, the components are refinable inde-pendently of the connectors and the infrastructure, connectors refinementmay be dependent on components, and the infrastructure refinement can bedependent on both the connectors and components. This assumption has tobe further investigated. Consequently, we have to investigate the sequences2385.5. Summaryof the connectors and components, and cyclic component interdependen-cies, which make the problem even more challenging.The applicability of quality heuristics The introduced heuristicsquantify the quality of system components, connectors and the infrastruc-ture, based on their performance impact, which is under our performanceabstraction the primary metric for our architecture. These heuristics giveindications of resulting performance increase or decrease in dependency onsome attributes (e.g., bytesize). The indications are results of local analy-sis of completion subsystems using standard tests. Thus, the exact valueswould change for a different system or a different usage profile. However,we assume that the performance semantic of the completion remains un-changed and the local heuristics can provide enough information to buildlearned knowledge about completions and support software developer’s de-cision about the order in completion sequence. To automate this decisionfurther we need to employ automated optimisation techniques, such as thePerOpteryx approach [113].5.5. SummaryIn this chapter, we introduced a method to handle conflicts in a sequence ofcompletions and help software architects to decide on a suitable transfor-mation order. The core of this method is the structure of the completion li-brary, where completion encapsulating expert-knowledge can be registered.The completion library allows archivation and reuse of expert-knowledge.In addition, the initial completions for concurrency design patterns buildguidelines that help software architects to create models of parallel archi-tectures. These design patterns are already important and very complexpart of parallel programming techniques and as such they are suitable asapplication domain for completion approach.2395. Completions for Software Performance EngineeringIn the next chapter, we discuss the quality properties of model transfor-mations integrating introduced model abstractions.2406. Model Transformation Analysis:Evaluating MaintainabilityIn the previous chapter, we introduced the CHILIES approach based onHOTs. We used a chain of HOTs to process and generate completion trans-formations. For the success of this approach is critical that the elements(i.e. models, metamodels and transformations) have certain quality char-acteristics. The main artefacts of MDSD are domain-specific languages(e.g. specified by metamodels) allowing modelling on a higher-level of ab-straction and transformations supporting automated generation of differenttarget models. The prominent role of model transformations in MDSD re-quires that they are treated as traditional software artefacts. The maintain-ability and ease-of-use of transformations is influenced by various char-acteristics – as with every programming language artefact. Code metricsare often used to estimate code maintainability, because, transformations,similarly as traditional software artefacts, should be used by different de-velopment roles and reused in different contexts, the understandability oftransformations is of our concern. In this chapter, we focus on the main-tainability and understandability of M2M transformations. We publishedthe work about code metrics for M2M transformations and their evaluationin the proceedings of QoSA 2010 Conference: Research into Practice - Re-ality and Gaps [91]. This chapter discusses these metrics in the context ofthis thesis.The leading challenge of this chapter is:How to analyse maintainability of relational transformations?Most of the established metrics do not apply to relational transformationlanguages (such as QVT Relational) since they focus on imperative (e.g.2416. Model Transformation Analysis: Evaluating Maintainabilityobject-oriented) coding styles. In this chapter, we define quality metricsfor relational transformations, which can be used to analyse the structure ofHOTs and completion transformations. Furthermore, we discuss the con-nection between the transformation and the metamodel. The connection be-tween the transformation and the metamodel is called metamodel coverageand is specific for transformations only, no similar property for traditionalsoftware artefacts exists.The remainder of this chapter is organized as follows. Section 6.1 moti-vates our work and introduces the context of metrics application. Section6.2 discusses the problem and general observations about the maintainabil-ity of transformations. Section 6.3 introduces the maintainability metricsfor M2M transformations and specifies the metrics using QVT relationalmetamodel. Our approach uses the Analysis HOT pattern (see AppendixB) to automatically compute the metrics for M2M transformations imple-mented in QVT Relational. The automated metrics collection is describedin Section 6.4. Finally, Sections 6.5 and 6.6 discuss limitations and sum-marize the contributions of this chapter.6.1. MotivationModel transformations are often used to transform software architecturesinto code or analysis models. Ideally, these transformations are written inspecial transformation languages like QVT [72]. With an observable in-crease in the application of Model-Driven Software Development (MDSD)in industry and research, more and more transformations are written bytransformation engineers. Thus, an increasing set of transformation scriptshave to be maintained in the near future, i.e., they demand to be understoodby other developers, bugs need to be tracked down and removed, and en-hancements need to be implemented because of evolving source or targetmetamodels.2426.1. MotivationToday there are two main streams of model-to-model transformation lan-guages: operational (i.e. imperative) and relational (i.e. declarative) lan-guages. For operational languages like QVT Operational, we can reuseexisting literature about software code metrics for imperative, e.g. object-oriented, languages. However, for relational model-transformation lan-guages like QVT Relational there is not even a comparable amount of liter-ature.In traditional object-oriented software development, software metricsare used as a mean to estimate the maintainability of code [17]. The es-timated maintainability then indicates when the code base becomes toohard to maintain. Software developers take corrective actions like refactor-ings [58] or code reviews to keep the code in a maintainable state. However,these metrics do not yet exist for relational model transformation languages.Nevertheless, some initial research targets metrics for functional program-ming languages in general like Lisp or Haskell. Being part of the samelanguage family, some metrics for functional programming languages canserve as a starting point for the definition of metrics for relational model-transformation languages. In this work we draw upon their ideas in definingour own set of metrics for model-transformation languages.As an initial step towards estimating the maintainability of relationalmodel transformation languages, we present a set of metrics usable to getinsight into the maintainability of QVT Relations transformations. For this,we analysed existing metrics for functional programming languages andcombined them with general code metrics (e.g. Lines of Code (LOC)) andcomplemented them with our own experiences from applying QVT Rela-tions. This set of developed metrics shall finally serve as a basis to judgeinternal transformation quality and to guide the development of transfor-mation refactorings or review checklists (i.e., a list of bad smells to lookfor). The metrics are described in detail and their ranges of ’bad’ values arecharacterized including a rationale explaining which type of maintainabilityproblem the metric detects.2436. Model Transformation Analysis: Evaluating MaintainabilityIn CHILIES approach, we used QVT Relational to implement HOTs andcompletion transformation (i.e., feature effects). Hence, we studied themetrics’ applicability and evaluated QVT Relational transformations im-plementing model completions. This study shows that understanding ofrelational transformations quickly turns out to be a difficult task. The diffi-culties increase faster than linearly when transformation sizes increase andsingle relations become more complex. As an reference example, we evalu-ated our metrics on the standard model transformation example given by theQVT standard specification [72]: the transformation from UML models toentity-relationship models to show that the metrics (a) are computable and(b) give insight into the transformation’s internal quality. The evaluation ofthe completions transformations and HOTs is described in more detail inSection 7.2.3.6.2. Problem DomainThe goal of our work is to quantify the maintainability of model transfor-mations. Therefore, we start by defining suitable metrics in this context.We identified a lack of quality metric definitions for relational transforma-tion languages in the literature. Hence, we focus on model transforma-tions created using QVT Relational (QVT-R), but we assume that our met-rics can be applied to model transformations created using other relationaltransformation languages as well. The main observed difference betweenrelational and operational languages is the fact, that operational transforma-tion languages describe a sequence of statements to create certain output.In contrast, relational transformation languages only describe the relationsbetween input and output of a transformation in a declarative manner, notthe way how it is computed (non-determinism). This results in special char-acteristics of relational transformation languages which have to be reflectedby the metrics to be defined.2446.2. Problem DomainGeneral Observations on Maintainability of QVT-R Transforma-tions: QVT-R can be for example applied in e.g. transformations be-tween languages, code generation and incremental or completion transfor-mations. One main advantage of QVT-R is its brevity and conciseness.In the QVT-R language, the structure of transformations is mainly charac-terised by the interdependencies of its relations. On the other hand, rela-tions can be defined in a way so that they match overlapping sets of ele-ments. Consequently, this increases complexity in cases when a new rela-tion is introduced and it is influenced by other relations. For example, lettransformation T be defined as a set of relations R, R = {a,b,c,d}. Sup-pose we want to extend T with a relation e, but e depends on a result ofa and a depends on a result of both b and c, while c depends on d. Thus,we first need to understand how relations a,b,c and d are related in orderto correctly include e into the transformation. In the case of more complextransformations, it is very hard to have all dependencies in mind. Becauseof this net of dependencies, it is hard to say if a new introduced relationconflicts with other relations or influences them in an undesired way. Onepossible design of relational transformation could be clustering of relationsthat match or create the same element (clustering of top-level relations).Furthermore, the identification of possible execution paths, how long theyusually are and what they depend on, is a very complex task.In following section, we discuss a collection of metrics for relationaltransformations. These metrics give a quick insight in transformation qual-ity. Additionally, because of the declarative nature of the family of rela-tional transformations we can define metrics to study structure and depen-dencies between the fragments of the transformations. This technique canbe easily built on the system of preconditions and postconditions definedfor each relation. The dependency data have various useful applicationsin the development and maintenance of transformations. By identifying ofdependencies between relations and avoiding cyclic dependencies, the un-2456. Model Transformation Analysis: Evaluating Maintainabilityderstandability of transformations may increase. Also, undesired calls torelations or relations that are never called can be easily recognised.6.3. Metrics DefinitionThis section introduces metrics for measuring the quality of model transfor-mations created using relational transformation language, such as QVT-R.For each metric, we give a description, including a brief motivation. Wealso include the rationale behind the metric giving insights in why we be-lieve the metric indicates the maintainability of a transformation. Addition-ally, we include a way for the computation (if possible using QVT-R andOCL) of the introduced metrics.6.3.1. Automated MetricsIn this section, we discuss the metrics derived for QVT-R that can be au-tomatically computed. We identified four categories: Transformation Sizemetrics, Relational metrics, Consistency metrics and Inheritance metrics.In the following sections, we give the names, descriptions and rationalesof the automated metrics. Table 6.1 then gives the computation directionsusing OCL for the presented automated metrics.6.3.1.1. Transformation Size MetricsThe size of the transformation has an impact on the understandability of atransformation. This metric for a whole transformation can be measured inseveral ways. The number of lines of code, for instance, is a simple metricmeasuring the pure code size of a transformation. This is comparable tomeasuring lines of code in programming languages. Comments and blanklines are also included in this metric. The number of code, comment andblank lines can also be viewed separately. Used in conjunction with other2466.3. Metrics Definitionmetrics we can derive valuable measures of a transformation, e.g. whencompared to the number of top level relations.The number of relations is a metric that can be used to derive the degreeof fragmentation and modularisation of a transformation. Higher numberof relations can be considered better, as it is an indicator for a high de-gree of modularisation. A high degree of modularisation can support themaintainability of a transformation and also the reuse of a transformationor parts of it. The number of top level relations gives a picture about theindependent parts of a transformation. A top level relation is a startingpoint for a transformation and can trigger the execution of other relations.An execution of a transformation requires all top level relations to hold.The ratio of top level relations to non-top level relations shows the rate be-tween independent and dependent parts of a transformation. An interestingmetric is number of starts defined by the number of top relations withoutwhen-clause. A higher number of starts increases the number of possibleexecution paths and therefore makes the transformation less maintainable.The metric number of domains expresses the complexity of a transforma-tion dependent on the number of match patterns. The number of domainspredicates additionally gives information about the complexity of these pat-terns. The number of when-predicates and the number of where-predicatesdefines how complex the dependency graph between relations is.The number of metamodels in a transformation has an impact on the com-plexity of the transformation itself and its match patterns. The size of themetamodel (defined by a number of classes) on which the relations matchelements might also have a great impact on the structure and therefore onthe understandability and modifiability of the transformation. The largerthe metamodel the larger the set of possible instances of this metamodel.Therefore, more combinations may have to be considered in the match pat-terns of the relations.2476. Model Transformation Analysis: Evaluating Maintainability6.3.1.2. Relational MetricsThe size of a transformation relation can be measured in different ways.The OMG specification of QVT states that a relation has one or more do-mains and that every domain has a domain pattern that consists of a tree oftemplate expressions. The size of a relation can be expressed in terms ofits number of domains or the depth of the domain patterns. Additionally,relations can define when- and where- predicates giving pre- and postcon-ditions. This leads to three different metrics for measuring the size of arelation: Number of domains , Number of when/where predicates, Sizeof domain pattern per domain. Another derived metric, the ratio betweenthe size of the relations and the number of relations might also give hintsabout the maintainability of the transformation itself and shows the lineardependency of effort needed to modify the transformation on the numberof relations. However, the direction of the metric (e.g., for better main-tainability) remains to be evaluated. For example, having many but smallrelations helps to understand the transformation punctually, for specific re-lations. However, grasping the interconnections of many small relations isalso a tedious and error-prone task, thus leading to the conclusion that hav-ing larger but fewer relations may be also good for maintainability. Still,defining a functional dependency between size and number of relations ina transformation might give hints on the maintainability of the transforma-tion.The metric average number of local variables per relation additionallygives indications on the dependencies within a relation that a developerneeds to grasp when trying to understand and modify the relation. A mea-surement for the complexity of the interconnections between relations is theaverage number of arguments in the form of its domains and the number ofvariables that are bound by calls to other relations in when- or where- pred-icates. These metrics are denoted val-in and val-out. Note that in QVT-Rval-in is always the same as number of domains. A high number of val-2486.3. Metrics Definitionout means that a relation is strongly dependent on the context, which mightdecrease the reusability of a relation.Relations generally depend on other relations to perform their task. Thedependency of a relation R on other relations can be measured by countingthe number of times relation R uses other relations or queries. These depen-dency metrics are denoted fan-in and fan-out, where fan-in is the number ofcalls to R and fan-out is the number of relations that are called by R. A highvalue of fan-in indicates that the relation is reused quite often and thereforeis highly reused or somehow more central to the overall transformation. Ahigh value of fan-out means that a relation uses a lot of other relations orfunctions (maybe delegates functionality to library queries), again makingthe relation more central. The metric number of enforce/checkonly domainsexpresses a rate of change between the domains of the relation (e.g., sourceand target domain). The metric expresses the number of possible matchpatterns by the number of checkonly domains and the level of change pro-vided by a relation (a number of diverse change patterns) by the numberof enforce domains. The complexity of a transformation may furthermorebe affected by the number of OCL helpers and number of lines/restrictedelements per OCL query, which encapsulate more complex behaviour.6.3.1.3. Consistency MetricsA high degree of inconsistency in the transformation is a reason for con-fusion during development and may lead to reusability and transformationcompleteness problems. To detect an inconsistency in a transformation weintroduce a number of consistency metrics. An example of inconsistencycould be a relation that was not completed during development. Such arelation could be identified as a relation without domains, with only onedomain or with domains without predicates. Therefore, we defined themetrics number of relations without domains, number of relations with sin-gular domains and number of domains without predicates. An additional2496. Model Transformation Analysis: Evaluating Maintainabilitymetric for the detection of incomplete relations is the number of unusedvariables. Unused variables pollute the code and complicate navigationwithin the transformation.The already introduced consistency metrics are easy to automate. An-other quite generic but still interesting metric is number of clones. How-ever, the automation of this metric is a research field by itself. This metricidentifies code duplicates, which are, as in other fields of code maintain-ability, candidates that impact maintainability of the code.6.3.1.4. Inheritance MetricsQVT-R transformations can extend each other and override relations fromparents. Inheritance metrics measure the level of inheritance of the trans-formation and its complexity.2506.3. Metrics DefinitionNameOCLexpressionTransformationtNumberofrelationst.rule→size()Numberoftoplevelrelationst.rule→select(oclAsType(QVTRelation::Relation).isTopLevel)→size()Numberofstartst.rule→select(oclAsType(QVTRelation::Relation).isTopLevelandoclAsType(qvtrelation::Relation).when→isEmpty())→size()Numberofwhent.rule→iterate(r:qvtbase::Rule;sum:Integer=0|sum+r.oclAsType(qvtrelation::Relation).when→size())Numberofwheret.rule→iterate(r:qvtbase::Rule;sum:Integer=0|sum+r.oclAsType(qvtrelation::Relation).where→size())Numberofmetamodelst.modelParameter→size()NumberofOCLqueriest.ownedOperation→size()RelationrNumberofdomainsr.domain→size()Numberofenforceddomainsr.domain→select(isEnforcable)→size()Numberofcheckonlydomainsr.domain→select(isCheckable)→size()Numberofwhen-predicatesr.when.predicate→size()Numberofwhere-predicatesr.where.predicate→size()Numberoflocalvariablesr.variable→reject(v|TemplateExp.allInstances().bindsTo.includes(v))→size()Val-InseenumberofdomainsVal-OutSet{r.when}→including(r.where).predicate→collect(p|collectVariableArgumentsOfRelationCallExps(p)).variable→asSet()→size()Fan-InRelationCallExp.allInstances().referredRelation=rFan-OutSet{r.when}→including(r.where).predicate→collect(p|collectRelationCallExps(p)).referredRelation→asSet()→size()Table6.1.:Automatedmetrics.2516. Model Transformation Analysis: Evaluating MaintainabilityThe balance metric shows size and distribution of transformation func-tionality between children. This metric is calculated as the ratio betweena number of relations, domains and equations per child transformation incomparison to the average.In a similar way as in object-oriented programming the dependency ofchildren on their parents can be measured by counting the number of tran-sitive parents per child and number of direct/transitive children per parent.Based on these metrics and the fan-in and fan-out metrics we can get a viewof the dependencies between relations in the different transformations (cre-ate a dependency graph). The metric number of overrides gives informationon how many relations from a parent transformation were overridden by achild relations. The larger this value gets, the more effort has to be investedinto understanding which parts of the transformation hierarchy are actuallyused (combination of non-overridden (inherited), overridden and additionalnon-inherited parts).6.3.2. Manually Gathered MetricsIn the following, we describe metrics that are not gathered fully auto-mated, but require manual or semi-automated analysis to determine theactual value of a metric.6.3.2.1. Similarity of Relations (frequent patterns)The Similarity of relations (frequent patterns) indicates how many similarpatterns can be found in a transformation. A large part of the complexityof a transformation and of an abstract model of the transformation comesthrough the need to understand patterns that occur within these models. Themore complex a transformation is, the harder it is to maintain it. Thus, tobe able to grasp the complexity of transformations, we propose to emulatehuman information processing through pattern mining on models. Humananalysis of software products is conducted either top-down or bottom-up2526.3. Metrics Definitionaccording to [116]. Using a top-down approach, the analyst tries to applyhis/her knowledge about design and domain to classify the software prod-uct under analysis. In order to do this he/she tries to gain an overview of thewhole application. Developers can then successively pick selected softwaresegments and determine their relevance for his current mental model of thesoftware. Using a bottom-up approach, the analyst will start reading com-ments of source code or other software artifacts. The control flow of certainsections will then be inspected sequentially and arbitrary selected variableswill be traced throughout the flow. Especially in declarative transformationlanguages, this is a difficult task as there is no explicit control flow. Theinformation gained will be integrated to a mental software model which isthe opposite to the top-down approach.Masak [116] notes that top-down analysis is being conducted more oftenby experts whereas bottom-up analysis is being used more often by noviceanalysts. These findings give strong indication that experts may have ab-stract mental patterns at hand which are being used for analysing the soft-ware product whereas novices must resort to documentation. If analysabil-ity is measured in terms of time to analyse parts of a software product, therequired time will be low if the analysed parts dominantly adhere to theexpert’s patterns. On the other hand the time will be very high, if the expertcan apply only a few of his/her patterns or the software heavily differs frompatterns known to him/her. These general observations were also stated forvisual patterns in [148] which is why we propose to incorporate them intoan analysability metric.This metric can be computed by using the frequent pattern mining algo-rithm presented in [105] to identify possible frequent patterns. From thesecandidates the relevant patterns can be selected and their similarity can beestimated. However, the result of these pattern mining is mostly a supersetof frequent patterns as they would be found by a human. Thus, manualselection needs to be performed to see whether each of the most frequentpatterns is really a pattern that occurs as repeating structure in the trans-2536. Model Transformation Analysis: Evaluating Maintainabilityformation or if it is just the result of constraints on e.g., the transformationmetamodel. For example, in QVT Relational a frequent pattern that is theresult of the language concept would be that each relation domain has aroot variable which refers to a meta-class that is contained in the packagereferred to by the domains typed model (see [72] for the QVT-R meta-model). However, this construct in inherent to QVT relations and is nota frequent pattern that would be relevant for the analysability of a trans-formation. Thus, this metric cannot be computed fully automatically butneeds an additional manual filter action. For example, a result of this met-ric could be that 30% of all relations of a transformation employ a patterninvolving the matching or creation of a certain tree structure consisting ofspecific types of model elements within the source or target model. As hu-mans are pretty good in pattern matching, a developer would then be ableto recognise this combination over and over again thus helping him/her tomore easily understand these 30% of relations.6.3.2.2. Number of Relations that Follow a Design PatternThe Number of relations that follow a design pattern may be another impor-tant indicator for transformation maintainability. The determination of thismetric is a tedious manual task as a design pattern is an abstract concept. Itmay occur in a form that can only vaguely be identified.The number of design patterns employed in the transformation may bea strong indicator on how good a transformation can be understood by ex-ternal readers. However, as the area of transformation development is stillquite immature, only few design patterns have been identified yet. To deter-mine this metric, we need to count the number of design patterns and theiroccurrences within the transformation. For example, if a transformationuses the Flattening Pattern from Section 4.4 throughout its whole imple-mentation and a developer knows what that pattern is used for he or she cangrasp the meaning of the transformation more easily.2546.3. Metrics Definition6.3.2.3. Type Cut Through Source/Target MetamodelAs mentioned at the beginning of this chapter, the metamodel coverageis specific for model transformations. The relation between the transfor-mation and the metamodel is analysed through studying metamodel cover-age. Each model transformation transforms source model which conformto a source metamodel to a target model which conform to a target meta-model. Some transformations transform all elements defined by the meta-model (e.g., translation). Other transformations transform only a subset ofthe metamodel elements (e.g., refinement or completion). We already usedthis analysis in Chapter 5 to minimize conflicts between transformation ina sequence of completions.To acquire insight about the parts of metamodel covered by a transfor-mation we propose to study a Type Cut Through Source/Target Metamodel.The metric Type Cut Through Source/Target Metamodel represents the rateof overlapping rules with respect to the transformation’s metamodels. Thetype cut concerning a metamodel is the set of patterns that match instancesof the same parts of a metamodel. In the UML to RDBMS example fromthe QVT standard (from which an excerpt is shown in Listing 2.1) the typecut concerning the meta-class UmlClass would be all those relations thatcontain a pattern that matches any UMLClass. The greater this overlap is,the more attention has to be paid when patterns of relations are modified inorder to not lose coverage of possible instances of the metamodel.To compute this metric we need to count the number of relations thatoverlap over the same part of a metamodel. For example, Relations a, b andc can all match instances of the same meta-class m. Thus the overlap rateconcerning class m would be 3. Finding type cuts that only refer to a certainelement of the metamodel, such as one meta-class m can be done straight-forward. However, it might be more interesting for more fine-grained pat-terns that are matched using several different relations. How such a detailedtype cut can be identified remains subject of future research.2556. Model Transformation Analysis: Evaluating Maintainability6.4. Computation of MetricsWe implemented a tool set to analyse the metrics presented in Section 6.3automatically. In the first step (cf. Figure 6.1), the transformation code(QV T ) is parsed which results in a transformation model (QV T Model).This model can be then analysed using our maintainability metrics. Thedescription of metrics is given by the metrics model (MetricsQV T ) on thehigher-level of abstraction. A HOT then generates transformations for ac-tual analysis based on this metrics description. Here, we implement theAnalysis HOT pattern introduced in Appendix B. The resulting metricsmodel gives information about the quality properties of the analysed trans-formations. Using a pretty-printer, we can extract an input to other analysistools from the metrics model. Note that for some metrics an additional inputcould be required, such as metamodels for Type Cut Through Source/Tar-get Metamodel or models of transformation design patterns for Number ofrelations that follow a design pattern.Figure 6.1.: Workflow for omputation of metrics.The automated metrics described in section 6.3.1 can mostly be ex-pressed as OCL expressions on the QVT-R meta-model. These OCL ex-pressions can be used to count the number of elements of a specific type,for instance the number of relations a transformation has. The expressionshave to be evaluated in the context of a transformation or a relation depend-ing on whether a transformation local or relation-local metric is calculated.Table 6.1 shows the OCL expressions used for calculating the metrics. To2566.4. Computation of Metricsbring these metrics together, relation local metrics can be aggregated bycalculating an average.1 query countSubExps(templ:QVTRelation: :TemplateExp) : Integer2 {3 if (templ.oclIsTypeOf (QVTTemplate: :ObjectTemplateExp))4 then templ.oclAsType(QVTTemplate: :ObjectTemplateExp) . part−>iterate (p:QVTRelation:5 :PropertyTemplateItem; acc: Integer = 1|6 acc + countSubExps(p.value .7 oclAsType(QVTRelation: :TemplateExp)))8 else9 if (templ.oclIsTypeOf (QVTTemplate: :CollectionTemplateExp))10 then countSubExps(templ.oclIsTypeOf (QVTTemplate: :CollectionTemplateExp) .11 member.oclAsType(QVTRelation: :TemplateExp)))12 else13 114 endif15 endif16 }Listing 6.1: Query function for calculating the domain predicate count.For more complex metrics like the domain pattern tree depth it was nec-essary to write more complex OCL query functions. Listing 6.1 shows anOCL query function for recursively counting the nodes of a domain patterntree. To easily apply all metric expressions and query functions, we devel-oped a QVT-R transformation that transforms a QVT transformation to aspecial metrics model. The metrics metamodel allows for compact storageof metrics for every relation in a transformation and for the transforma-tion itself. Moreover, it is possible to store the aggregated values that arealso calculated by our metrics transformation. Furthermore, for measur-ing the lines of code, we utilised common methods used for programminglanguages. We distinguished whitespace, pure comment and code lines.Figure 6.1 shows the workflow for retrieving the metrics.2576. Model Transformation Analysis: Evaluating Maintainability6.5. DiscussionThe definition of metrics with the goal to estimate quality attributes, such asmaintainability, always comes with the wish to indicate whether a lower ora higher value of a metric is better or worse. However, this decision cannotbe made without a sound validation of the ’meaning’ of a metric. For exam-ple, having a low number of relations, at first glance, seems to be good formaintainability whereas a high number seems to be bad. On the other hand,if these few relations are very long they may be harder to maintain that morebut smaller relations. Thus, in this chapter we only identified what could bepossible indicators that may resemble maintainability of transformations.We intentionally did not decide, for most of our metrics, which ’direction’of a metric is good or bad concerning maintainability. We leave it to futurework to determine and evaluate this meaning. Through empirical evalua-tions need to be performed in order identify how meaningful each metricis.Furthermore, the implementation of the metrics extracting limits our ap-proach to the transformations implemented in QVT-R. Despite, this limi-tation is motivated by the application of these metrics to evaluate comple-tion transformations which are implemented in QVT-R, it is obvious thatfor their application in other contexts we have to generalise these metricsfurther. We expect that presented metrics can be applied to other modeltransformation language, however it has to by further investigated.6.6. SummaryIn this chapter, we presented an initial set of quality metrics to evaluate themaintainability of QVT Relational transformations. However, such metricscould be applied to different relational transformations, they play impor-tant role when considering completion transformations. We apply proposedmetrics in Chapter 7 to compare different implementations of the comple-2586.6. Summarytion transformations. Moreover, we demonstrate the use of these metricson a reference transformation and HOTs implementations to show their ap-plication in real world settings.The presented metrics help software architects to judge the maintainabil-ity of their model transformations. Based on these judgements, softwarearchitects can take corrective actions (like refactorings or code-reviews)whenever they identify a decay in maintainability of their transformations.This results in higher agility when changing metamodels of software archi-tectures or their platforms, which together with metamodel build basis fortransformation definition.2597. ValidationThis chapter presents the validation of the contributions presented in thisthesis. We identified two main goals for the validation: (i) to asses thevalidity of the model completion as an artefact in the MDSPE process and(ii) to evaluate the quality properties of used MDSD artefacts. We structurethe validation based on these goals.Our hypotheses are evaluated based on different levels of validation forprediction models as introduced by [27]. For the first goal, we validate sev-eral aspects: we evaluate the accuracy of model-driven quality predictionusing performance completions introduced in Section 5.3. Furthermore,we evaluate the compositionality and the ordering in a sequence of comple-tions. For the second goal, we evaluate the understandability and maintain-ability of the completion transformations quantitatively. In particular, westudy the maintainability of the completions and necessary HOT transfor-mations. For this purpose, we use the approach and metrics for evaluatingmaintainability of model-to-model transformations presented in Chapter 6.Moreover, we sketch further validation studies for empirical evaluation.This chapter is structured as follows. In Section 7.1, we discuss the vali-dation goals. In Section 7.2.1, we study the validity of model completionspresented in Section 5.3. Furthermore, Section 7.2.2 discusses the compo-sition of completions. In Section 7.2.3, we evaluate the maintainability ofused transformations. Section 7.3 summarizes and discusses the validationgoals.2617. Validation7.1. Validation GoalsWithin the validation of our approach, we study the validity of model com-pletions and the quality properties of used MDSD artefacts. The validationgoals and derived validation questions for these two aspects are presentedbelow in Section 7.1.1 and Section 7.1.2 respectively. As introduced by[27], we can validate model-driven prediction approaches on several lev-els. We discuss these validation levels in the following and apply them tovalidate our goals.Levels of validating model-based prediction approaches In thework of Böhme and Reussner [27], several levels for validating model-based prediction approaches are introduced. These levels characterise vali-dations of model-based prediction approaches. The automated completion-based enhancements of MDSPE introduce variability and incremental com-pletion concepts to the models. Thus, we extend the description of valida-tion levels below to explicitly cover the model completion step as well.7.1.1. Validation Type I: Accuracy ValidationThe first level of validation (metric validation [27]) compares the predictionresults (e.g., response time) of the model-driven prediction approach to themeasured properties of the real-world subject (e.g., measured response timeof an implementation). The studied property of the prediction approach isthe accuracy of the prediction.In the case of completion support, additional aspects are important. Theprediction approach is required to: (i) deliver more accurate predictionsusing models with completions as without and it should deliver accuratepredictions for each variant of a completion that is derived based on a fea-ture model. Moreover, when multiple completions are used, (ii) their validcompositions should provide accurate predictions, as well.2627.1. Validation GoalsTYPE I: PREDICTION ACCURACY The accuracy of performance pre-diction approaches has been studied in several case studies, c.f. [98]. Inthis work, we focus on performance and assume that the quality predictionapproaches used are valid. Thus, the goal of the validation is to evaluateindividual completions, assuming a perfect underlying prediction model.The completion developer is responsible for the validation task during thecompletion development process. Each completion has to be validated be-fore it is registered in the completion library. We give an example how thiscompletion validation task can be realised and validate the completions in-troduced in this thesis. The first question we need to answer for this purposeis:Q1: Can completed model provide more accurate performance predic-tions?To validate the accuracy of the completion in this study, we comparethe results of performance prediction based on the completed model andthe performance measurements on the real implementation. Additionally,we study real-system properties (such as state dependency) which can bemodelled in PCM using completions. We validate three completions in thiswork: (i) Statefull ’Message Oriented Middleware’ (MOM), (ii) ’ThreadPool’, and (iii) ’Procedure Call Connector’.The detailed description and results of the validation can be found in Sec-tion 7.2. We validate platform-specific completions for particular softwareplatforms (using particular version of middleware). In our studies, we candemonstrate that it is possible to create meaningful completions that yieldaccurate predictions. However, we do not claim that our observations aretransferable to all other platforms and software systems, due to further de-velopments of platforms and related complex effects on performance. Cer-tainly, this validation can be repeated for new platforms and completionscan be recalibrated.2637. ValidationTYPE I: COMPLETION COMPOSITION AND ORDERING In this valida-tion step, we evaluate the compositionality and the ordering in a sequenceof completions and their accuracy in composition. We pose the secondevaluation question:Q2: Can models be automatically completed using a multiple comple-tions to provide more accurate performance predictions?For this goal, we validate the composition and ordering of three comple-tions in the Procedure Call Connector, i.e. its abstraction using Pipe&Filterpattern. The detailed description and results of the validation can be foundin Section 7.2.7.1.2. Validation Type II: Applicability ValidationThe second level of validation addresses the applicability of model-drivenprediction approaches. The validation of applicability assesses the informa-tion that has to be obtained to apply the approach, the creation of predictionmodels, the execution of the prediction or analysis, and the interpretationof the results.The completion-based approach inherits the applicability properties fromthe used prediction methods, or the MDSPE process integrating the com-pletion step. Therefore, the applicability regarding required information,model creation and results interpretation is mainly a property of the usedprediction model. However, we study the applicability of completion-related method enhancements. We can distinguish two different levels atwhich the applicability of completions has to be discussed.Completion users have to understand the feature models to be able toapply them to the CBA model. The questioned is, if is the specification ofconfiguration models using feature diagrams is appropriate. The instantia-tion of completions happens automatically and as such is not in concern ofcompletion user. The completions and their feature models are created onceby experts for a specific prediction metamodel (i.e., PCM in this thesis).2647.1. Validation GoalsFeature models are a well known and intuitive method to illustrate decisiontrees. Their applicability properties are inherited from the definition of fea-ture model metamodel and its syntax and semantics.Feature diagram havebeen used in the domain of generative programming and SPLs for morethan a decade. They have been introduced by Czarnecki et al. in [46] in2000. The completion-related extensions of the feature model are not vis-ible to the completion user and are necessary only for the implementationof automated transformation generation. As such, the feature models areconsidered as well-known and applicable for a completion-based approach.The completion developer, however, has more complex task to createa completion and register it with the completion library. Here, we buildon the very important prerequisite that the task of domain engineering issupported by automated benchmarking approaches, such as Software Per-formance Cockpit [169]. Having this prerequisite in mind, the collectionand analysis of measurement data is of no major concern for completiondeveloper. Using such automated measurement approaches, it is possibleto validate all configuration combinations, which would be a huge effort todo manually. Since the actual domain engineering step and the completionvalidation is automated, it requires no additional manual effort and inheritsits applicability properties from the measurement approach.Instead of validating the applicability of our method in isolation, it seemsmore promising and to result in more insight to conduct an empirical studyof model-based prediction method with completions and comparing it tomodel-based prediction method without completion mechanism as a whole.However, such empirical study is out of scope for this thesis and brings noadded value at this point, therefore we use established evaluation techniquesusing code metrics indicating the applicability of our approach. We focusin this evaluation on the complexity of the completion implementation. Es-pecially, the complexity of completion transformations gives indicators onapplicability of CHILIES for completion development.2657. ValidationThus, the remaining applicability aspect for the completion developer isthe ability to identify necessary model changes and implement transforma-tion fragments. The identification of model changes is dependent on thedeveloper’s domain specific knowledge and as such is hard to measure orquantify. In this validation, we focus on the understandability and com-plexity of transformations and transformation fragments. The developmenteffort necessary to implement required transformations and transformationfragments is discussed in the second goal of this validation. The complexityand maintainability of transformations is evaluated using the metrics intro-duced in Chapter 6. We present the validation plan and the results for thisgoal in Section 7.2.TYPE II: COMPLEXITY COMPARISON This part of the validation dis-cusses maintainability and applicability properties of completions, relatedmodels and transformations. Based on code metrics and their results col-lected for the evaluated transformations, we discuss and assess the develop-ment effort necessary to create and maintain completions. In the following,we pose the third evaluation question:Q3: What are the quality, especially maintainability, properties of usedtransformations?Furthermore, we have to discuss the fragmentation of transformationsand its complexity. Therefore, we pose a forth evaluation question:Q4: Is the complexity of transformations decreased by separation of con-cerns in feature-related transformation fragments?We use the maintainability metrics for transformations introduced in Sec-tion 6 to evaluate these goals.TYPE II: EMPIRICAL STUDY As mentioned before, an empirical studyof model-based prediction method with completions as a whole is out ofscope for this thesis. We inherit the applicability properties of the usedPCM approach. A initial validation of the understandability and applicabil-2667.1. Validation Goalsity of the PCM approach was conducted in two empirical studies [140, 112].The additional validation of the remaining aspects related to completionsapplicability can be derived from these studies. In both studies, partici-pants, with background software engineering knowledge, were trained inmaking quality prediction with PCM. The participants were asked to cre-ate models, execute the prediction method and analyse results of the pre-diction. Using PCM tools, they had to create performance abstractions,now encapsulated in completions, by hand without any automated support.Thus, these case studies indicate that abstractions encapsulated in comple-tions can be understood and parametrised, reusable models can be createdby a trained user. The most significant advantage of completions is sep-aration of concerns, reuse and automation. Completions decrease manualdevelopment effort previously need to create the performance abstractionsof performance-related aspects. However, to quantify the decrease of devel-opment effort using completions we have to conduct more focused studiescomparing groups of trained users building their models with and with-out completions. More details on the conducted studies can be found in[140, 112], including the posed questions, a detailed discussion of the re-sults, and the threats to validity. Further validation studies for applicabilityevaluation are part of the future work.7.1.3. Validation Type III: Cost/Benefit ValidationThe third level is called "benefit validation" and is concerned with thecost/benefit evaluation of a prediction method. In this type of validation,the costs, resulting from usage of the method, are compared to the expectedbenefit, which can be an improvement of the modelled subject, an evalu-ation of planned alternatives, and the recognition of not favourable designdecisions. The common benefit of all prediction approaches is the reduc-tion of effort in later development phases of the software life-cycle, such ascorrection of wrong design decisions or performance problems.2677. ValidationTo validate approaches on this level, a controlled experiment is neededduring which whole software projects have to be executed with and with-out using the presented approach. After the development projects finish,we can evaluate benefits resulting from completion usage. Such validationis the most expensive level of validation (with respect to time and effort)and, thus, is rarely executed in practice. Due to the high effort, we cannotconduct this type of validation in the scope of this thesis.7.2. Improving Prediction Accuracy using PerformanceCompletionsWe claim that our approach supports developers in improving the accuracyof quality predictions using the completed models. In this step, we assumethat developers have a software architecture model with quality annotations(e.g., PCM) and an automated measurement framework (e.g., Software Per-formance Cockpit) available. In this section, we present the validation set-tings and results for the validation goals specified in the previous section.7.2.1. Type I: Prediction AccuracyFirst, we address question Q1 regarding the prediction accuracy:Q1: Can completed model provide more accurate performance predic-tions?As the prediction accuracy using completions depends on the accuracyof underlying performance prediction method, we reviewed previous workdiscussing the accuracy of PCM prediction method. In the context of thePCM, numerous case studies demonstrate that accurate prediction modelscan be created [101, 103, 75, 100, 15, 18, 76, 80, 106, 86, 104]. In this work,we do not focus on the accuracy of PCM models, but on the predictionaccuracy of specific completions.Additionally, some of the mentioned studies [101, 75, 80, 86] use PCMmodels that have been created and calibrated using measurements of the2687.2. Improving Prediction Accuracy using Performance Completionsstudied system. Such models are validated by the comparison between thepredicted performance properties and measurements of the system. Thestudies mentioned above assessed the accuracy of PCM models at hand.They do not make a statement about the prediction accuracy of model vari-ations without recalibration . Some of the case studies [103, 15, 18, 104,76, 77] also discussed the issues of model variants, changed parametrisa-tion, and calibration. Two studies [103, 15] demonstrated that it is possibleto vary parts of a model in isolation. In the case studies, a component wasadded to the architecture of the initial system. The component was mea-sured, modelled and calibrated in isolation. The predictions for the result-ing system were successfully compared to measurements of an analogouslychanged implementation.Other two studies [18, 76] evaluated the accuracy of systems using ini-tial MOM completion across different platforms. The effects of the mes-saging configurations such as message size, messaging protocol, and useof encryption and authentication were studied. The encryption and authen-tication were measured in isolation. The performance abstractions wereweaved into the initial models, exchanged or refined model elements andchanged the systems topology. The predictions using resulting models weresuccessfully compared to the with measurements of real systems. Thesestudies demonstrate that completions can be parametrised, can be calibratedusing measurements, and are reusable in different execution contexts.In the following sections, we discuss two completions: (i) the statefulenhancements to the ’Message Oriented Middleware’ and (ii) the infras-tructure completion ’Thread Pool’. For each completion we discuss thegoal of the measurement, used metrics and assumptions, created modelsand corresponding implementation, and the results of the comparison be-tween measurements and prediction results.2697. Validation7.2.1.1. Validation: Connector Completion ’Statefull MessageOriented Connector’To provide accurate predictions, performance models have to include manylow-level details. Reusable performance completions ease development ofsuch models and are built using the MDSPE process introduced in Section3. In this section, we validate enhancements to the ’Message Oriented Mid-dleware’ (MOM) first introduced as manually (i.e., implemented in JAVA)created completion by Happe et al. in [76]. In their work, the MOM Com-pletion was validated in the context of real system, such validation here,therefore brings no added value, instead we focus on the specific aspects ofthis completion. We introduced enhancements to MOM Completion allow-ing its automation in [93, 92]. Additionally, we introduced a State Manager(see Section 5.3.3.2) to the internal ’message transfer’ component of thecompletion skeleton. Our extensions of MOM completion allow to modeltransactional communication between components. From the performanceprediction point of view, we discuss especially the stateful properties ofthis completion. The validation of these aspects is based on our work in[94]. The foundations of the stateful performance engineering concept isdiscussed as additional contribution of this thesis in Appendix A. Further-more, we implemented this completion in three ways (i) manually in JAVA,(ii) partially automated using mark model and (iii) fully automated usingtransformation fragments. We discuss the advantages and complexity ofsuch implementations in Section 7.2.3.SETTING: QUESTION, METRICS, ASSUMPTIONS The key challengeof performance completion design is to find the right performance abstrac-tion for the system under study. To identify the performance-relevant be-haviour and factors, we employ a combination of goal-driven measure-ments and existing knowledge about the functional system behaviour. Theprocess to build feature diagram, identify and implement feature effects is2707.2. Improving Prediction Accuracy using Performance Completionsdescribed in Section 3.3. In this validation case study, we start with thebasic structure of the completion for message-based systems which wasintroduced in [76]. In Figure 7.1, a feature model describes the possibleconfigurations of the MOM Completion.MessagingPoint-to-Point ChannelPublish-Subscribe ChannelMessage ChannelPool SizeCompeting ConsumersExclusive ORMandatory FeatureOptional FeatureSelective ConsumerDurable SubscriberTransactional ClientTransaction SizeGuaranteed DeliveryLegendReceiverSenderFigure 7.1.: Feature Model for the MOM Completion [76].The feature model captures possible configurations for a messaging sys-tem. The configuration includes the type of Messaging Channel as wellas characteristics of the Sender and Receiver. For example, a MessagingChannel can be configured as a Point-to-Point Channel if only a single Re-ceiver is needed. The Message Size is a property of the Sender and ex-presses the amount of data transferred. Furthermore, the number of Com-peting Consumers at the Receiver’s side can be specified. The choice ofeither of these features results in a change of the architectural model. Thecomplexity of these changes varies from setting a parameter, through struc-tural changes, to globally changing the deployment of a whole system.In our case study, we consider a feature configuration with the selectedfeatures: Point-to-Point Channel, Competing Consumers, Pool Size of 4,Transactional Client, TransactionSize of 1000 messages, and Message Sizeof 1 kilobyte.The configuration of a message-oriented middleware (e.g., a size of atransaction) can affect the delivery time of messages [94] as illustrated inFigure 7.2. Unfortunately, software architects cannot include these detailsinto their architectural models. The middleware’s complexity and the spe-2717. Validationcific knowledge on the implementation (that is required to create the neces-sary models) would increase the modelling effort dramatically. While mostof the implementation details are not known in advance, a rough knowledgeabout the design patterns that are to be used might be already available.This knowledge can be exploited for further analysis, such as performanceand reliability prediction, and for code generation.0,00,51,01,52,02,53,03,54,04,55,01 10 100 1000 10000 100000Delivery Time [ms]Message Sizenon-persistent persistent(a) Persistent vs. non-persistent mes-sage transfer.0,05,010,015,020,025,030,035,01 10 100 1000 10000 100000Delivery Time [ms]Message Sizelocal remote(b) Local vs. remote message transfer.Figure 7.2.: The influence of message size on the delivery time [93, 76].We extended the MOM Completion to include the state-dependent ef-fects to the PCM models and allow to study their properties too. In thefollowing, we give an example for the influence of state on software per-formance which is taken from the area of message based systems. In par-ticular, we are interested in the delivery time (time from sending a mes-sage until it is received) of messages send within a transaction. Messagingsystems, which implement the Java Message Service standard [74], explic-itly support transactions for messages. The transactions guarantee that allmessages are delivered to all receivers in the order they have been send.To achieve such a behaviour, Sun’s JMS implementation MessageQueue4.1 [1] waits for all incoming messages of a transaction and, then, deliversthem sequentially.Figure 7.3 shows the measured delivery times for a series of transac-tions with 1000 messages each (the sender initiates a new transaction (as2727.2. Improving Prediction Accuracy using Performance CompletionsFigure 7.3.: Time series of a transaction with 1000 messages per transaction set.part of a session), passes 1000 messages to the MOM, and finally, commitsthe transaction). All messages arrive within the first 0.4 seconds and aredelivered sequentially within the next second. This behaviour leads to de-livery times of 0.4 seconds at minimum. The delivery times grow linearlyuntil the transaction is completed. In this example, the position of a mes-sage in the transaction set determines its delivery time. Thus, the measureddelivery times are not independent and identically distributed but stronglydepend on the number (and size) of messages that have already been sent.As a consequence, we need to keep track of the messages that are part of atransaction. Additionally, the periodical utilisation of resources (e.g., CPU)influences performance. To model such a behaviour, we need to extend ourmodel and introduce a notion of state as part of our model.SenderMiddlewareReceiverMiddlewareMessaging SystemSenderAdapterReceiverAdaperMessaging CompletionMarshalling DeMarshallingMOMAdapterIFoo IFoo’ IFoo’ IFoo’ IFoo’ IFooIMomIMarshalling IMarshallingISender IReceiverPlatform-specific Middleware ComponentsFigure 7.4.: Components of the MOM Completion [based on [77]].2737. ValidationIMPLEMENTATION Transactional messages are common in today’s enter-prise applications, such as implemented by SPECjms2007 Benchmark [152].However, the transactions used in the supply chain management supermar-ket of the benchmark are limited to small, predefined transaction sizes. Toprovide a better evaluation, we implemented an application that allows toconfigure the number of messages send in one transaction following thephilosophy of SPECjms2007. We excluded external disturbances (such asdatabase accesses) and focussed on the evaluation of the messaging system.For performance prediction, we extended our performance completionfor message-oriented middleware called messaging completion in the fol-lowing [76]. The messaging completion subsumes several components thatreflect the influence of different middleware configurations such as guar-anteed delivery, competing consumers, or selective consumers. In [76], itwas already demonstrated that the messaging completion can predict theperformance of a SPECjms2007 scenario with an accuracy of 5% to 10%.In the subsequent paragraphs, we present an extension of our messagingcompletion that enables the prediction of influences of transactions on thedelivery time of a message.Completion for Message-oriented Middleware: Figure 7.4 shows thecomponents and connections that are generated by the messaging comple-tion (see [76] for details). The completion consists of adapter compo-nents and middleware components. The first forwards requests and callsthe middleware components that issue platform-specific resource demands.The Marshalling component computes the message size based on themethod’s signature. The message size is passed to subsequent adaptersas an additional parameter, so that the original interface (IFoo) needs to beextended (IFoo’). The Sender Adapter calls the Sender Middlewarewhich loads the resources of the sender’s node and forks the call to the MOMAdapter to reflect the asynchronous behaviour of the messaging system.The MOM Adapter realises the transactional behaviour of the messagingsystem. The Receiver Adapter calls the Receiver Middleware and,2747.2. Improving Prediction Accuracy using Performance CompletionsFigure 7.5.: Starting a new transaction.thus, loads the resources of the receiver’s node. It forwards the requests toDemarshalling which maps the extended interface (IFoo’) back to theoriginal interface (IFoo).Modelling transactional behaviour of the MOM Adapter: In order tostart a transaction, the sender has to explicitly call method startTrans-action. Its behaviour (see figure 7.5) consists of a single SetStateAction,which resets the number of messages to zero (numberOfMessages.VALUE= 0) and enables the transactional message transfer (isTransactional.VA-LUE = true). When startTransaction has been called, all messagessend in the following will be part of the transaction until commitTrans-action is executed. The behaviour of the MOM Adapter varies for transac-tional and non-transactional messages (see figure 7.6). The MOM Adapterbehaviour is extended as it is illustrated by Figure 5.7.If the message is not part of a transaction, the adapter simply callsthe Messaging System, which loads its local resources with the ser-vice demands necessary for transferring the message, and forwards themessages. Otherwise, if the message is part of a transaction, then theMOM Adapter increases the current number of messages of the transac-tion (numberOfMessages.VALUE = numberOfMessage.VALUE + 1) andqueues the message. The queueing is modelled by two actions. Thefirst external call action (IMOM.queueMessage) loads the resources ofthe Messaging System. The second action acquires the passive resource2757. ValidationtransactionQueue, which blocks the message transfer until the trans-actionQueue is released.<>isTransactional.VALUE == true isTransactional.VALUE == false<>IMOM.processMsgTransfer<>IMOM.queueMessage<>IFoo’.service<>waitForTransferStarted<>notifyTransferCompleted<>IFoo’.service << InputVariableUsage >>message.BYTESIZE = stream.BYTESIZE << InputVariableUsage >>p1.Characterisation = p1.Characterisation […]pn.Characterisation = pn.Characterisation stream.BYTESIZE = stream.BYTESIZE<>transactionQueuecapacity = 0<>synchronisationPointcapacity = 0<>numberOfMessages.VALUE = numberOfMessages.VALUE + 1<>IMOM.processMsgTransferFigure 7.6.: MOM Adapter: Message Transfer.When the transaction is committed and the messages blocked at thetransactionQueue are released, the MOM Adapter processes the mes-sage transfer (IMOM.processMessageTransfer). Furthermore, it notifiesthe behaviour of commitTransaction that the message has been trans-fered (transferCompleted is released). Finally, the MOM Adapter for-wards the message to the Receiver Adapter. This behaviour ensuresthat all messages are delivered in the same order as they have been send.Figure 7.7 shows the behaviour executed to commit a transaction. The RD-2767.2. Improving Prediction Accuracy using Performance CompletionsstartMsgTransferwaitForTransferCompletedFigure 7.7.: MOM Adapter: Commit Transaction.SEFF reflects the successful execution of a transaction and neglects pos-sible rollbacks and re-executions. To commit a transaction and deliver allmessages to the receivers, a loop action iterates over all messages blockedduring the transaction (numberOfMessages.VALUE). For each message, itunblocks its transfer (releases passive resource transactionQueue. Toensure the sequential delivery of messages, it waits for the successful trans-fer of the message (aquires passive resource synchronisationPoint)before it continues. Finally, the transaction is terminated (isTransac-tional.VALUE = false) and the number of queued messages is reset(numberOfMessages.VALUE = 0).RESULTS We used the PCM’s simulation environment SimuCom [18]to predict the performance for three different configuration variants ofmessage-oriented middleware. Basically, SimuCom interprets PCM in-stances as a queuing network model with multiple G/G/1 queues. To in-stantiate the parametric performance completions, we applied model-driventransformations mirroring chosen configuration for each of the alternatives.2777. Validation(a) Average of the delivery time. (b) 90% percentile of the deliverytime.(c) CPU utilisation.Figure 7.8.: Predictions and measurements of the three design alternatives [93, 77].Figure 7.8 summarises the predictions and measurements for the threedesign alternatives. These results were analysed by Happe et al. in [77].In the following we summarize them, as a proof that we started with accu-rate calibration of initial MOM completion. The results show the averageand 90% percentile of the delivery time as well as the CPU’s utilisation.Measured values are printed in dark grey, predicted values in light grey.The prediction error for the average delivery time and the 90% percentileis below 15% in all cases. The CPU utilisation with an error below 3%.Among the considered alternatives the third one, called ’small’ (with re-duced data size), shows the best performance. The considered scenario inthis thesis is the usage of not-persistent message transfer, where the mea-sured and predicted average times for one message are 1,50 ms and 1,652787.2. Improving Prediction Accuracy using Performance Completionsms. The stateless model predicted that 90% of all messages in transactionare delivered in less than 411 ms.Figure 7.9 shows the prediction results for transactional messages withstateful model. The corresponding real measurement is shown in figure 7.3.The predictions correctly reflect the dependency of a message’s deliverytime on its position in the transaction. This behaviour was not visible in theprediction results using the stateless variant of MOM completion. Further-more, the predicted delivery times range from 400 ms to 1400 ms whichcorresponds to the observed delivery times for the transaction size of 1000messages. Moreover, Figure 7.10 illustrates the prediction results for theCPU utilisation using stateful model. The prediction results illustrate delayFigure 7.9.: Predicted delivery times for messages.in transfer of messages in transaction, the first message in transaction is thefastest one and the last one is the slowest one. Thus, with the position ofthe message in the transaction increases the time spent in the message chan-nel too. In Figure 7.9 is the delay in message transfer, the start and com-mit of one transaction clearly visible. In stateless model, the distributionof the time for message transfer shows highest probability between 1,6msand 1,75ms (cf, Figure 7.11). However, the mean value for the transfer ofwhole transaction shows very small difference (for correct mean value itis enough to multiply transfer time of one message by the number of mes-sages in transaction), the error in median increases significantly with the2797. Validationsize of the transaction. Additionally, stateful model shows that the transfertime for one message is highly dependent on the position in the transaction.Figure 7.10.: Periodical CPU utilisation in stateful model.Table 7.1 lists the predicted and measured median values for differenttransaction sizes. Due to the high variance of the delivery times, the me-dian serves as a representative value for a specific transaction size. How-ever, the median can only be considered as an indicator for the predictionaccuracy, it is very good indicator for the variance. In table 7.1, predictionsand measurements deviate less than 4%. These results indicate, that theextension of our messaging completion can accurately predict the influenceof (successfully completed) transactions on the delivery time of a message.DISCUSSION We discuss stateful performance engineering in more de-tail in Appendix B. Based on the presented case study we can, however,already here make these conclusions. The increased expressiveness of state-ful models comes at a cost. Stateful models may have much higher com-plexity and size, which may complicate their analysis. Even if the mod-els are not analysed fully, and are examined with simulation methods (likein the case of PCM), model complexity may have an impact on the timeneeded for sufficiently accurate performance prediction (duration of a sim-ulation run). The time necessary to execute a simulation run is further influ-enced by the variability of simulation results. The state-dependent system2807.2. Improving Prediction Accuracy using Performance CompletionsTable 7.1.: Measurement/Prediction Comparison.variability mirrors in the variance of the results and consequently influencesthe number of measurements necessary to achieve results with a high confi-dence. The cost of a single simulation measurement depends on the lengthof the simulated trace. Explicitly modelled states have only little effecton the length of simulation traces, which mainly depend on the modelledsoftware architecture (e.g., loops dependent on a state value).(a) Transaction (size=400). (b) No transaction.Figure 7.11.: Message transfer time.On the other hand, one should to keep in mind that the confidence aboutthe correctness of predicted values will be higher if a low-coverage sim-2817. Validationulation is run on a more accurate (stateful) model, than if a high-coveragesimulation is run on an unrealistic (stateless) model. Moreover, as the state-ful dependency was in our case encapsulated in completion (invisible to thecompletion user) we can conclude that the complexity of the model fromthe user point of view has not increased.Modelling transactional messages probabilistically results in a compa-rable distribution of response times. However, the model does not reflectthe stochastic dependency of sequentially arriving messages. Furthermore,it provides less flexibility since delays caused by transactional behaviourhave to be known in advance. In most cases, such information is not avail-able or the delays are changing constantly. In these cases, an explicit statemodel eases the design of performance models and allows accurate predic-tions with the necessary flexibility. Additionally, approximating state bya probabilistic abstraction results in decreased possibility of reuse of thecomponent because the probabilities are specific for a one system, a oneallocation and one usage profile. More detailed discussion on this topic canbe found in Appendix B.7.2.1.2. Validation: Infrastructure Completion ’Thread Pool’SETTING: QUESTION, METRICS, ASSUMPTIONS Thread pools allowthe asynchronous processing of jobs. They support the creation and pool-ing of a number of threads to process these jobs. In Section 5.3.5, wepresented an analysis of thread management strategies and possible varia-tions of them. In the domain analysis, we identified that the most impor-tant parameter, that can be tuned to provide the best performance is thecapacity of the Thread Pool. Figure 3.11 shows the feature diagram forThread Pool design pattern based on the configuration options provided injava.util.concurrent packages by the Java JDK (1.6). The two mostimportant parameters influencing the choice of optimal pool size are the2827.2. Improving Prediction Accuracy using Performance Completionsnumber of processors available for the application and the nature of theincoming tjobs.In the following, we describe the most important metrics we used toevaluate performance-influences of different Thread Pool variants, as wellas the parameters we used to configure the experiments.Create JobDelayExecuteOpen Workload Generator ThreadPool ExecutorRespone TimeProcessing TimeFigure 7.12.: The experiment setup.Figure 7.12 illustrates the experiment setup. A workload generator cre-ates new jobs and inserts them in the queue of the ThreadPoolExecutor.The job itself consists of a single processing job that consumes the specifiedCPU processing time. We use the de.uka.ipd.sdq.resourcestrategiesfrom PCM to generate the corresponding CPU demand.Let tc be the time a job is created and put into the ThreadPoolExecutor’squeue, ts the time the a job is assigned to a thread (its processing starts),and t f the time the job is finised, then we can observe the following metricsfor each job:2837. Validation• Response Time tr: The time passed from the moment a new job isput in the ThreadPoolExecutor’s queue (tc until it processing isfinished (tr): tr = t f − tc.• Processing Time tp: The processing time is the time a request is beingprocessed by a thread, i.e. the time passed between the moment thejob is assigned to a thread (ts) until it is finished (t f ): tp = t f − ts.• Waiting Time tw: The waiting time is the time the request resides inthe ThreadPoolExecutor’s queue. It is the time passed for a job’screation (tc) until its processing starts (ts): tw = tc − ts.Based on the definition of the timing metrics we see that: tr = tw + tp.Configuration Parameters: In the experiment, we vary following pa-rameters:• Arrival-Rate: The arrival-rate λi for a waiting jobs queue qi is definedas average number of requests sent to the Thread Pool to be processedper second. For the total number of requests Ai and a measurement-time T . The arrival-rate can be calculated as:λi =AiT. The time between two requests is called inter-arrival time.• Number of Core Threads: The number of threads in the pool that arealways kept.• Maximal Number of Threads: The maximal number of threads in thepool.• Request Size: The size of a request is defined by the average (i.e.specified) processing time for this request.• Queueing Strategy: Strategy to be used to queue jobs if more jobs ar-rive then can be processed. Valid queueing strategies are unbounded2847.2. Improving Prediction Accuracy using Performance Completions(an unlimited queue), bounded ( a limited queue with a size definedby configuration parameter queue length), and direct-handoff (noqueue all jobs are processed immediately or rejected).• Queue Length: In case of a bounded queue this parameter deter-mines the number of jobs that can be kept in the queue.Observed Metrics: Furthermore, we observe the following metrics ofthe Thread Pool itself:• Rejection Rate: Percentage of jobs that is rejected by the Thread-PoolExecutor in case of bounded queues or direct hand-offs.• Number of Active Threads: Observed average number of threads thathave been active during an experiments.• Number of Threads in Core Pool: Observed average number ofthreads in the core pool during an experiment.• Observed Queue Length: Observed average number of jobs in thequeue during an experiment.• CPU-Utilisation: The Thread Pool average CPU-utilisation UCPU isthe quotient of the total time the CPU is busy (BCPU ) and the totalmeasurement-time T:UCPU =BCPUT.Using predefined metrics and configuration parameters, we can formu-late the experiment questions, scenarios and hypotheses (see Section 5.3.5).Moreover, based on the domain analysis results we could identify default(close to optimal) Thread Pool configurations:Optimal number of threads parametrised by number of CPU replicas (n)for CPU-intensive requests:PoolSize = n+12857. ValidationIn our experiment, we use CPU-intensive requests, thus, we await resultsshowing increase of Thread Pool performance (decrease of contention) un-til the moment when the size of Thread Pool is close to the n+ 1 value.After this value we await that no increase of performance would be ob-served.MEASUREMENTS The implementation of the prediction model is basedon the design of the Thread Pool completion presented in Section 5.3.5. Thecompleted model is illustrated in Figure 7.13. We calibrated the completionskeleton using measured data illustrated in Figure 7.14. These data areresults of measurement experiments with the Thread Pool design patternimplementation.For the performance measurements, we used a computer with followingsettings: Windows 7 Enterprise (64Bit), Intel Core2 Duo T7300@2GHz,RAM 4GB, and CPU set to the maximum performance. Each experimentused a workload generator for open workload with an exponentially dis-tributed inter-arrival time. The duration of measurement was 100 secondsfor each experiment (i.e. parameter combination) and we computed theaverage for the measured values.ServerClientThreadPoolWrapperPool:size=MaxSizeCorePool:size=Round(CoreSize*1)acquire releaseacquire()release()CPU: Core2 Duo T7300@2GHzschedulingPolicy="PROCESSOR_SHARING" numberOfReplicas="2"Usagemodel=OpenWorkloadinterArrivalTime_OpenWorkload.Specification="Exp(1.0 / inter-ArrivalTime.VALUE)"cpuDemand.VALUE=ProcessingTimeprocessFigure 7.13.: Completed Thread Pool Model in PCM.2867.2. Improving Prediction Accuracy using Performance CompletionsIn Figures 7.14(a)(b) we can observe that with the length of the queuethe processing time increases. This is explained by the decrease in thenumber of active threads in the second graph. In Figure 7.14(a), processingtime first increases then decreases slightly. This behaviour is also reflectedin the number of active threads (Figure 7.14(b)) Figure 7.14(c) gives anexplanation for this behaviour. It illustrate that the increased rejection ratebecause of queue contention. For short queues, a larger number of jobs(more than 20%) is rejected by the threadpool. In total, less jobs have to beprocessed by the pool resulting in less parallelization and shorter processingtimes. For longer queus, more jobs are accepted, so that the total workloadof the pool increases. This behaviour also affects the average response time(Figure 7.14(d)) for each job.In Figures 7.14(e)(f) the observed queue length and the waiting time ex-plodes for processing times larger than 250 ms. This is caused by an over-utilisation of the CPU – not all incoming jobs can be processed. As a result,the queue length and response times increase as jobs pile up at the pool. Weused the knowledge from the measurement experiments to build the ThreadPool completion.Experiment Processing Time Core Pool SizeCore Pool Size 4 0 to 10 in steps of 1Maximum Pool Size 4 10Pre-start all CoreThreadstrue falseKeep Alive Time 10.000 seconds 100 msQueueing Strategy UNBOUNDEDQUEUESUNBOUNDEDQUEUESSpecified ProcessingTime50 ms to 500 ms insteps of 50 ms50 msInter-arrival Time 180 ms (mean) 30 ms (mean)Table 7.2.: Thread Pool experiment configuration.2877. Validation(a) Queue Length vs. ProcessingTime.(b) Queue Length vs. Number Of Ac-tive Threads.(c) Queue Length vs. Rejection Rate. (d) Queue Length vs. Response Time.(e) Specified Processing Time vs. Ob-served Queue Length.(f) Specified Processing Time vs.Waiting Time.Figure 7.14.: Thread Pool completion: Calibration Data.RESULTS The configuration of the experiments is summarized in Tables7.2 and 7.3. For the Core Pool Size experiment the pool is ’cold’ at thebeginning meaning that it has not been used before to process any jobs.Otherwise, we cannot observe the influence of the core pool size as it hasalready been dynamically adjusted by the ThreadPoolExecutor.The comparison (cf. Figure 7.15) between the measurement and predic-tion shows the accuracy of the prediction. The model predicted the ob-served behaviour very accurately. We observed that by maximal pool sizeof 4 the observed number of threads in pool was in both of the experiments2887.2. Improving Prediction Accuracy using Performance Completionsequal 3, thus n+1 for the used dual-core processor. The completed modelmanifested the same behaviour. Furthermore, the predicted processing timebefore the queue overflow is very accurate by value of 3,444s which cor-responds to the observed processing time 3,763s in a first experiment. Thepredicted response time of 3,558s corresponds to the observed 3,975s, too.However, the completed model provided prediction with the error less than8% for our experiments, the results start to significantly deviate after thequeue overflow is observed. This deviation is visible on the right-hand sidegraph in Figure 7.15. Moreover, the queue overflow is observed ≈ 100mslater as measured in a real system. We discuss this observed effects furtherin the following section.(a) Core Pool Size vs. ProcessingTime.(b) Processing Time vs. Waiting Time.Figure 7.15.: Thread Pool completion: Comparison of prediction (BLUE) and mea-surements (RED).DISCUSSION The results of the previous experiments demonstrated that,after the queue overflow is observed, the prediction is not accurate anymore. The cause of the deviation is shown in Figure 7.16(b) where thequeue overflow in the simulation is depicted. Figure 7.16(a) further illus-trates this effect. The red curve shows the results of the same simulationonly left to run longer as the blue one. It is clear from this graphs that af-ter the queue overflow, results of the simulation are very sensitve to smallchanges. However, in this scenario, the absolute values are of minor inter-2897. Validationest. The fact that the queue is growing constantly if the processing time ofa job exceeds 250 ms is predicted correctly.The model presented here does currently not model bounded queues.However, a State Manager for keeping track of the queue length could solvea part of this problem (similar to the transactions in Section 7.2.1.1). De-pending on the jobs currently waiting in the queue and the maximal queuelength, the simulation can reflect the actual behaviour of the ThreadPoolEx-ecutor. If the limit is reached further jobs can be rejected. However, thisbehaviour requires a combination of realibility and state that is currentlynot available in the PCM.Experiment Queue LengthCore Pool Size 4Maximum Pool Size 10Pre-start all Core Threads falseKeep Alive Time 100 msQueueing Strategy BOUNDED_QUEUESQueue Length 1 to 50 in steps of 2Specified Processing Time 50 msInter-arrival Time 30 ms (mean)Table 7.3.: Thread Pool experiment configuration for the Queue Length.Figure 7.16(c) depicts additional difficulties for performance predictionusing thread pools. In this graph, the red dots represent prediction results,the blue is based on measurements of a cold pool, and the green on mea-surements of a hot pool. Before the pool size reaches 2 (n for dual-core)the number of threads is smaller than number of CPUs, which results inresource contention. Thus, we can observe a decrease in the response timeuntil n is reached. After this point the resource contention is not observedany more, there are enough threads created to process the requests. The pre-diction model manifests an utilisation of CPU ≈ 80%, which is in theory290correct as the utilisation could be computed as follows:7.2. Improving Prediction Accuracy using Performance CompletionscpuDemand.VALUE/numberO f Replicas/interArrivalTime.VALUE ∗100This formuly yield a utilisation of 83% (= 50ms/2/30ms∗100 for our thirdexperiment. However, we observed a CPU utilisation of ≈ 100% during theexperiments. In the measurement results (cf. Figure 7.16(c) blue and greencurve), a delay of at least 3s is visible. Most likely the arrival-rate and/orCPU demands are not close enough to the behviour of the real system.These additional delays could come from the operating system overhead(such as scheduling) or other services of the system. To provide more accu-rate predictions in such situations completions rely on the more detailed re-source models, which model particular resources in more detail. Currently,this is a subject of research by Michael Hauck [80] in his PhD thesis.(a) Processing Time vs.Waiting Time -with longer simulation.(b) Queue overflow.(c) Core Pool Size vs. Response Time.Figure 7.16.: Observation of the queue overflow.2917. Validation7.2.2. Type I: Completion Composition and OrderingIn this section, we address first the question Q2 regarding the predictionaccuracy when using multiple completions:Q2: Can models be automatically completed using a multiple comple-tions to provide more accurate performance predictions?In the following sections, we evaluate the composition of completionsand their order. We implement and validate all completions used in thiscase study in isolation. Resulting completions are then composed to buildmore complex systems.First, in this section, we introduce a scenario used to evaluate the basicconcept of cutting the task of the connector down to separate individualsteps. Furthermore, the effects of the composition of completions in con-nectors are explained. We demonstrate how completions based on concur-rency patterns can be used to efficiently model software systems and eval-uate performance. In a second step, we illustrate the applicability of ourapproach for partial completion ordering and conflict resolution. For thispurpose, we present a case study of a Supply Chain Management (SCM)for supermarkets. In particular, we are interested in the performance of aBusiness Reporting System (BRS) for a subset of supermarkets. The BRSsupports users by retrieving reports and statistical data about running busi-ness processes from databases of different supermarkets. This scenario isbased on a real system by Wu and Woodside in [174].Figure 7.17 shows the part of the system architecture relevant for busi-ness reporting. The main part of the business reporting is running on theHQ’s server system. The data is distributed among the company’s super-markets and managed by Data Managers. In order to generate a report fora particular set of supermarkets, the business reporting sends a request tothe supermarkets of interest. The data managers of each supermarket re-trieve the necessary data and send it back to the HQ, when data from all2927.2. Improving Prediction Accuracy using Performance CompletionsFigure 7.17.: Relevant part of the SCM architecture for BRS with annotations.supermarkets are collected. As soon as all data is available, the BusinessReporting generates the report and returns it to the client.The presented case study consists of three levels:1. In the first step of this case study, the HQ component is annotatedwith a Barrier pattern and the connector to supermarkets is anno-tated with MOM configuration. This case study demonstrates theapplication of completions and their effect on performance.2. To illustrate the compositionality of completions, we implementedand validated Compression and Decompression completions in iso-lation. These completions are then composed together to build a con-nector abstraction.3. To illustrate our approach for conflict resolution, we add further an-notations for Encryption and Compression to the connector (see Fig-ure 7.17). We apply our approach for conflict resolution to identifya locally optimal execution order for the completions applied to theconnector.2937. Validation7.2.2.1. Validation: Completion CompositionIn the following, we describe a component completion applied on the Busi-ness Reporting component. The application of the Barrier [51] com-pletion is illustrated in Figure 7.18 that shows the behaviour of the meth-ods generateReport and uploadData, which realise a large part of theBusiness Reporting’s functionality. The Figure 7.18) contains two ex-tensions that describe how these patterns are to be integrated into the soft-ware system in order to generate the business report from a number of su-permarkets in a correct way.HeadQuartersBusinessReportingSupermarketWrapperBarrier:size=NLocalTSS:sizeGlobalTSS:sizeacquire<>addData<>sendMessages<>processData <>ThreadsRequired = N<>ThreadSpecificStorage<><>generateReport() uploadData()<><><>ClientuploadDatareleasereleaseacquireacquiregenerateReportreleaseBarrierBarrierGlobalGlobalLocalLocaluploadData()’generateReport()’Figure 7.18.: Behaviour of the Business Reporting including annotations.Communication between HQ and the supermarkets is realised by mes-sages, to simultaneously collect data from all supermarkets. This requiresthe Business Reporting to block until the results of all supermarketsarrived. A barrier, modelled by an annotation of the outer scope of meth-ods generateReport() and uploadData() including the actions pro-cessData and addData, ensures that the generation of the business reportis deferred until all data is available. For report generation, this block-ing is achieved by registering at the barrier before processing the data2947.2. Improving Prediction Accuracy using Performance Completions(registerBefore). During the upload of data, the supermarkets registerat the barrier after they added the data (registerAfter). This behavioursignals the barrier that new data is available now. The data itself must beprotected by a critical section in order to avoid lost updates or race condi-tions. For this case study, we used a thread-specific storage to reach thisaim. We distinguish accesses to the local data of a single thread andglobal data of all threads. In general, the annotation critical sectionrealises a strategized lock, i.e., the locking strategy can be exchanged bywhatever seems appropriate. The complexity of the barrier is hidden in anexternal Wrapper component added to the system.75 120 180 220 280 320 380 420 480 520 580 620Time [ms]Density0.0000.0020.0040.0060.0080.010MessageTurnaroundTimeDataCollectionTimeFigure 7.19.: Distribution of the turn-around time and data collection time.We implemented the business reporting scenario using JBOSS 6.1 andmessage-driven beans for the message-based communication. For the mea-surements, we set up the system in a distributed environment with oneclient, one HQ, and five supermarkets each running on a separate machine.Figure 7.19 shows the probability distribution of the turn-around time of amessage (i.e., the time from when the message is send until an answer of a2957. Validationsupermarket arrives) and the data collection time (i.e., the total time fromsending a message to all supermarkets until all answers arrived). As to beexpected, the distribution of the data collection time represents a probabilis-tic lower bound of the turnaround time. Mathematically, it is the maximumturnaround time of five messages send in parallel. Sending a message tofive supermarkets (publish-subscribe) took 16 ms only. The delivery of themessage return took 158 ms on average. This strong difference is mainlycaused by the different message sizes. The messages send back to HQ aremuch larger than the messages send by HQ since they contain the data re-quested. Finally, the JNDI-look up of the topic for sending the messagetook 116 ms and the report generation (after all messages have been re-ceived) 260 ms. The total processing time to generate a report was 522 ms.In the following, we extend this system and apply additional processingsteps in the connector. Thus, we evaluate the composition of a multiplecompletions in one connector.SETTING: QUESTION, METRICS, ASSUMPTIONS We identified threedifferent dimensions in the configuration of the completions which impactperformance:1. The use of asynchronous calls is introduced, which speeds up thesimulation of procedure calls, that can be processed asynchronously.2. Due to the capacity restraints the capacity of concurrency can be con-figured. This includes pile up effects in the connector and can be usedto conduct bottleneck analysis.3. The resource demands (e.g. required number of CPU cycles) for eachof the processing steps can be specified.In the remainder of this section, we deal with the issue of finding properresource demands and separating the individual processing steps in the con-nector correctly. The process of finding proper (in some cases parametrised)2967.2. Improving Prediction Accuracy using Performance Completionsresource demands is part of the completion development and results in theplatform-specific completion definition. The separating of individual pro-cessing steps is the basis to support completion variability. We have toevaluate if these steps can be composed correctly.IMPLEMENTATION The case study scenario consists of multiple DataManagers which generate great amounts of data that are requested by theBusiness Reporting component. Each Data Manager serves one su-permarket. To preserve network bandwidth, the data is compressed beforenetwork transfer and decompressed afterwards, this does already reflect thesteps in which the overall task of the connector is going to be cut down.The scenario is implemented in Java using the GZIPStreams and Socketcommunication. In our scenario, we use two machines, each with one core,similar processing rate and memory. All Data Managers run on one ma-chine, while the server runs on the other.To adapt models corresponding to the real system, we implemented atransformation realizing connector completions and composing them frombasic elements. It is a model-to-model transformation using QVT Rela-tional [72]. The tool used to run the transformation is Medini QVT Engine.As shown in Figure 7.20 the transformation can be divided into a numberof basic steps.As a first step in the transformation, the source model has to be copiedcompletely into the target model, but without the annotated AssemblyCon-nectors (which are replaced by the transformation). The transformationcopying the model is generated using the Routine HOT. Then the Connec-tors have to be created. The creation of a Connector can be divided intothe following steps: (a) find elements in the target model, (b) create newelements, (c) connect elements, (d) allocate elements, and (e) place ele-ments. First, the location (pivot element) and the elements that are directlyconnected to this location, where the Connector has to be inserted into thecopied system, have to be identified. The new elements and their inter-2977. ValidationCopy the source modelFind elementsin the target modelCreate new elementsConnect elementsAllocate elementsPlace elementsCreate ConnectorFigure 7.20.: Approach for executing a transformation.connections are defined by the completion feature diagram and its featureeffects. For each completion, a completion transformation is generated.Second, this transformation is executed and all the new elements that arepart of the connector are generated. Then all the elements get allocated tohardware resources depending on the allocation in the source model. At theend all created elements have to be placed inside the system or allocationelement to be at the right place in the PCM model. Resulting transfor-mation completed prediction model in single steps integrating in each stepan abstraction of single connector part (e.g., Compression/Decompressionin a first step, MOM in a second step, etc.). If the completion createda ’coupled’ sets of elements (i.e. subsystems), such as Compression/De-compression, the elements get connected by ab AssemblyConnector. Thisconnector is then the pivot element for the next completion, in our case theMOM completion. When the completions do not create ’coupled’ subsys-tems, the next completion is applied on the first AssemblyConnector afterlocation of the by previous completion created subsystem. Thus, it is pos-sible to compose a number of processing steps in connectors.RESULTS To create the prediction model and to configure the compo-nents for processing steps, the response time of compression, socket trans-2987.2. Improving Prediction Accuracy using Performance CompletionsFigure 7.21.: Measurement Results: Overview.mission and decompression has been measured independently. We focusedon data sizes up to 0.5 MB and only a few concurrent threads to minimizetrashing, we expect the server to run at moderate utilisation. The data isstructured and thereby has a compression rate of 70%. We noticed, thatthe duration does not only depend on data size but also on the compres-sion rate achieved for that data, thus we used only data with that constantcompression rate.Figure 7.22.: Measurement Results: Compression.2997. ValidationThe results for the duration of all three processing steps executed byone thread are shown in Figure 7.21. The compression and decompressionclearly adhere to a linear behaviour, while the socket transmission show aperiodically partial-linear nature. Please note, that the values for decom-pression do not relate to the response time from the data size as indicatedby the x axis, but instead to the response time required to decompress tothe indicated data size. This is done for illustration purposes, so that onecan read on hand of one x value how long it takes to compress data, andfor the same x value the decompression graph shows how long it takes todecompress that same data, although the input data sizes differ due to thecompression.Also, if there is more than one thread, the behavior scales additively aslong as there is no trashing. Meaning that the duration of 4 threads doingone package of work is approximately the same, as one thread doing 4packages of work. This is shown in Figure 7.22 in the case of compression.Note, that this only holds, if there is no blocking involved like from file IOor excessive paging, which is not the case here. Within this case study, wefocused either on one or three Data Managers (i.e. threads). In case ofData Managers sensors the level of concurrency is configured through thethink time of the Data Managers.Another effect we experienced in the measurement of the overall sce-nario was that it did not relate to the sum of the individual measurements.This was caused by the fact that the decompression could already start,before the transmission of the whole data was finished. To simplify the sce-nario, we deployed a buffer in which the data is written and which is notdecompressed until all data has been received via the socket connection.The capacity of the worker pool of the decompressor has to be set toone, because the socket server accepts only one incoming connection at atime and accepts no new connection until the current is done processing.The model uses synchronous call mode to enable predictions of the overallresponse time. From the measurements of the processing steps we created3007.2. Improving Prediction Accuracy using Performance Completionsregression lines to use them for the resource demands of the component’sSEFFs.The prediction achieved good results (<3% error) when only one DataManager was used.With three active supermarket sensors (Figure 7.23) theprediction error was less than 3%, when the inter-arrival time was eithervery high or very low. The results deviated more with the inter-arrival timein middle values (approximately half of the execution time), although evenfor these cases the error went only up to 4%. What could be explained byrepeated garbage collection activity by higher utilisation.Figure 7.23.: Measurement vs. Prediction Results.DISCUSSION This part of the case study showed that even a composi-tion of multiple completions measured and calibrated in isolation providesaccurate predictions. There are, however, still open questions. In this casestudy, some factors were simplified. Those factors are predestined to be fo-cus of future studies. For example, streaming requires further investigation.One possible solution to model this is to split up the data into several smallpackages after the compression and process them asynchronously. Further-more, varying compression rates should be supported. Together with vary-ing degree of concurrency and data size, this turns into a multidimensional3017. Validationproblem. This can be mastered by utilising Software Performance Cockpit[77], which had not suitable tool support at this point.Additionally, the experiment can be also conducted on multi-core CPUs.The scenario can be enhanced by passive resources (e.g. semaphores, locksfor critical sections) to validate the passive resource model and new featurescan be added.7.2.2.2. Validation: Completion OrderingAlternative [C,E,M]MOM AdapterAlternative [E,C,M]Encryption496ms653msCompression EncryptionCompression MOM AdapterFigure 7.24.: Completion Alternatives.Figure 7.17 shows the part of the system’s architecture relevant for busi-ness reporting. In this architecture, one component, the HQ BusinessReporting, is annotated by a Barrier pattern configuration. This is acompletion annotating component, thus in a responsibility of componentdeveloper. Because it is a single completion having impact on this compo-nent, the conflict does not appear. More interesting is one connector (lineconnecting required interface of a HQ to provided interfaces of supermar-kets) annotated by three completions: firstly, as Messaging connector, sec-ondly, by Encryption, and thirdly, by Compression. All of these com-pletion annotations refine the performance prediction model with certainproperties. The sequence of completion execution affects the model struc-ture and its validity. In the illustrated example, the completion executionorder results in different semantic for the Barrier completion. Correctlyis a barrier implemented as a part of an intern functionality of a component,3027.2. Improving Prediction Accuracy using Performance Completionsthus the ’Barrier component’ is located before the beginning of the con-nector chain. However, when the ’Barrier component’ would be appliedat the end of this chain after the MOMAdapter the model would be semanti-cally invalid. In a first case, the ’Barrier component’ waits for a numberof replies from different Data Managers. By changed order the ’Barriercomponent’ waits for replies from one Data Manager. Additionally, theresults of performance prediction could be influenced as illustrated by ourexample (cf. Figure 7.24) for the connector chain. To identify a valid com-pletion execution order in such complex system is a non-trivial task.In the following, we demonstrate how conflicts of multiple completionscan be resolved. It is possible that not all of the permutations in the com-pletion sequence are valid, the reasons for it are different: some of the se-quences could be structurally or semantically invalid, other one are not pos-sible because of the middleware implementation that has a fixed sequenceof the services. We do not consider these cases, in this part of the casestudy we focus only on the third dimension in completion conflict, thus,the performance dimension. We analyse the impact of completion order onperformance and ability of our approach to help completion user identifysuitable variants from performance point of view.For the sequence of Messaging,Encryption, and Compression are allthe possible permutations structurally valid. However, semantically doesnot make sense, for example, to both compress and decompress before orafter sending the message. In reality such possibilities do not occur. For thepurpose of this case study, we modelled all these permutations and appliedour quality heuristics for conflict resolution.In the presented example, the sequence of completion execution shouldresult in the full architecture model illustrated in Figure 7.25 (e.g., with ap-plied [C,E,M] completion sequence). Using the method introduced in Sec-tion 5.2.3 we illustrate the reduction of conflicts in completion executionsorder. This way the sequence of completion execution can be implicitlydefined.3037. ValidationHeadQuartersSender AdapterReceiver AdapterMessage-oriented MiddlewareSupermarketReceiver Adapter SupermarketHeadQuarterClient Sender MiddlewareReceiver MiddlewareReceiver MiddlewareMOM AdapterBarrier Critical SectionEncryptionCompressionDecryptionDecompressionDecryptionDecompressionFigure 7.25.: Resulting Architecture.[C,E,M] [E,C,M] [E,M,C] [C,M,E] [M,C,E] [M,E,C]rt(link) 496 ms 653 ms 1137 ms 676 ms 1130 ms 1574 msthp(link) 115 msg/s 72.5 msg/s 39 msg/s 70 msg/s 39 msg/s 26 msg/sQ(e) 4.3 9.0 29.1 9.6 28.9 60.5Table 7.4.: Quality evaluation for all valid completion chains.RESULTS As expected, the completion set applied to the connector isconflicting, producing significantly different results for different comple-tion chains. To resolve the conflict, we analysed the application of all com-pletion chains over the completion set CS = {M,E,C}. The set of all validcompletion chains is {[C,E,M], [E,C,M], [E,M,C], [C,M,E], [M,C,E], [M,E,C]}.Based on the heuristics for order resolution we identified the most optimalcompletion order as [C,E,M]. The measured performance of E and M de-creases with growing size of input data. The C completion decreases thedata size and therefore should be the first in a sequence. The C is fol-lowed by E and by M as shown by quality function results. We modelledall alternative architectures in the Palladio Component Model (PCM). Tovalidate our approach, we developed a semi-automatic extension of thePCM Bench [18] that analyses the conflict location in isolation using ourheuristics. The PCM Bench allows the specification of component-basedsoftware architectures and the analysis of their performance properties suchas response time, throughput, and resource utilisation.3047.2. Improving Prediction Accuracy using Performance CompletionsThe order in which completions are applied heavily influences the re-sponse time and throughput of the connector. Table 7.4 lists the responsetime, throughput, and the computed results of local quality functions Q(e)for all different permutations. In addition, Figure 7.26 shows the cumula-tive distribution functions for the response time of all permutations.Figure 7.26.: Distribution of the response time for refined connector (based on allvalid completion chains).For the best permutation, we get a mean response time of 496 ms and amaximal throughput of 115 messages per second. This yields a value of 4.3for our quality heuristics. By contrast, the worst combination results in amean response time of 1574 ms and a maximal throughput of 26 messagesper second. Consequently, the value of our quality heuristic is much larger(60.5). The results demonstrate how the quality heuristics further empha-sises the differences between the permutations. While the response timeof the best and worst permutation differs "only" by a factory of three, theresults of the quality function differ by a factor of 14. Thus, the qualityheuristic clearly select the permutation [C,E,M] as the best alternative (cf.Figure 7.27).3057. ValidationFigure 7.27.: Comparison of the overall response time distribution for the[C,E,M](RED) and [E,C,M](BLUE) alternatives.DISCUSSION We shown that the proposed method for reduction and res-olution of conflicts can give the completion user an indication of the bestalternative. The exact results for the subsystems tested by this method inisolation do not correspond the exact values for the subsystem used as apart of a complex system with other usage profile, the pattern in results is,however, an indicator that remains. As such could be used to build a knowl-edge about the completions registered in library and give recommendationsfor best practices for the developers.7.2.3. Type II Validation: Applicability EvaluationIn this section, we demonstrate how the introduced metrics give insightinto the quality of transformations. We illustrate the applicability of ourapproach and discuss the results. For this purpose, we present a case studybased on an evaluation of different types of transformations.7.2.3.1. Maintainability ComparisonWe address first the question Q3 regarding the maintainability of comple-tion transformations:3067.2. Improving Prediction Accuracy using Performance CompletionsQ3: What are the quality, especially maintainability, properties of usedtransformations?SETTINGS In our case study, we evaluate following transformations:MOM (Message-oriented-Middleware) Completion Transforma-tion This transformation integrates performance-relevant details into soft-ware architectural models, it is a completion transformation. This type oftransformations is a special type of customisation. The details are woven asadditional subsystems into the model of architecture, thus the source modelhas to be copied first. The MOM completion transformation is dependenton the input from a configuration model that configures how the actualarchitecture model should be refined. Thus for each variant of this transfor-mation the copier part is the same. The difference is in actual descriptionof completed subsystem. We evaluate two different implementation of thistransformation:• MARK_MOM - MOM mark transformation: The configuration, de-fined by the mark model, provides the variability to the transforma-tion. For example, if a connector is to be completed by message-passing, the mark model can provide information about the type ofmessaging channel, e.g., using guaranteed delivery. The disadvan-tage of such implementation is that the completion developer hasto develop a overall transformation that produces a valid result foreach combination of configuration options. Thus, such transforma-tion has to read directly the configuration model and implement ahuge ’switch’-like constructs to react on the read configuration cor-rectly.• COMP_MOM - MOM completion transformation: This transforma-tion does not know about the configuration at all. It is generatedusing a composition (by the Composite HOT) of feature effects de-3077. Validationveloped in isolation for each feature. Moreover, this transformationincludes copy relations for all metamodel elements, these relationsare generated by the Routine HOT.We analyse both of these variants to get a feeling for the complexity ofthese transformation types. The source and target model of these transfor-mations are based on an underlying component-based metamodel of ’core’PCM with the size of 290 classes. As such, these transformations are rep-resentatives of the group of quite complex and variable transformations.R_HOT - Routine HOT Transformation This transformation is a Higher-Order Transformation (HOT), as it generates another transformation. Thisspecific HOT is used to generate a default copy transformation for a givenmetamodel by producing a copy relation for each class and each propertyof the given metamodel. This is required because there is no copy operatorin QVT Relational. The source model of this transformation is the Ecoremetamodel having 31 classes and target metamodel is the QVT Relationsmetamodel itself with the size of 110 classes. This transformation is usedas a representative of the group of medium-complex transformations.TRAN_T - Translation Transformation This transformation is pre-sented in the QVT specification as an example relational transformation[72]. In this case study, it serves as a reference example. The trans-lation transformation only translate model instances of one metamodellanguage to another metamodel language. This translation transformationmaps UML class models to RDBMS tables. The minimum UML sourcemetamodel contains 6 classes and the target RDBMS metamodel has a sizeof 18 classes. This transformation is used as a representative of the groupof simple transformations.We applied the maintainability metrics introduced in Chapter 6 to eval-uate maintainability of these transformations. The results were collected3087.2. Improving Prediction Accuracy using Performance Completionsautomatically using the Analysis HOT pattern. In the following section, wediscuss the results of this evaluation.RESULTS The results (cf. Table 7.5) of this case study have shown thatthe completion transformation (COMP_MOM) in contrast to the transforma-tion without the generated parts (MARK_MOM) has a higher number of smallerrelations. The relations in COMP_MOM are in average less complex. The de-crease in complexity originates in the less complex match patterns, becausethe complexity of pattern matching is distributed on a number of relations.Completion transformations show that usually the number of domainsused is two, one for target and one for the source. In manually programmedtransformations it can be observed, that more complex matching pattern areused and include several domains. Thus, the relations are bigger, but thenumber of relations is smaller comparing to generated transformation. Thisis visible on the graph ’Pattern Node Complexity’ in Figure 7.29, where wesee how the rate of domain pattern nodes per relation decreases significantlyif the simple copy rules are added. Moreover, no additional local variablesare necessary. In this graph is visible that the MARK_MOM transformationconsists of the most complex relations.The transformation COMP_MOM, intuitively categorised as a complex trans-formation, shows much higher values in average domain pattern tree depthas well as the average number of domains and when-predicates per rela-tion (cf., Figure 7.29). Interestingly, the number of where-predicates in-creases diametrically opposed. This may indicate that different approachesfor defining the overall transformation have been employed. Moreover,where-predicates indicate a somehow “forward” (thus also more impera-tive) executed transformation whereas more when- predicates indicates amore declarative way of the whole transformation design. The tendency touse more declarative constructs instead of imperative once is even visibleby per-hand developed MARK_MOM, which was implemented by developersused to the concepts of functional programming. Which of these designs is3097. Validationmore maintainable remains to be evaluated. However, using these metricsa connection between these findings could be underlined.Moreover, on the last two graphs in Figure 7.29 we can observe that ina simple transformations such as TRAN_T usually one predicate depends onone variable only. However, in more complex transformations the numberof variables in predicates grows. The most complex variable dependenciescould be observed for the MARK_MOM transformation. Similarly, in the caseof R_HOT the complexity of predicates is high, this transformation is angenerator that is not variable and is implemented only once. As such, thehigher complexity is reasonable.Furthermore, generated transformations show an equal ratio of when-to where-predicates (cf. Figure 7.29). This means that a fulfilment ofevery relation is a precondition of as many relations as it depends on. Thistendency is not visible in a manually programmed transformations. On theother hand, an increase in the usage of where- clauses is visible, becauseit is easier to think in the forward transformation direction. However, thetendency to use more when- predicates increases with the complexity ofthe transformation as shown for the MARK_MOM.The ratio between the number of top level relations and non-top levelrelations (cf. Figure 7.28) is the smallest in case of the generated transfor-mation (1:1). This means a higher utilisation of top level relations. Thegenerated transformation takes an advantage from a higher number of ex-ecution paths possible in the transformation and is not tuned to limit thenumber of starts in order to support maintainability. This also makes senseas the parts generated for the copy transformations are not intended to bemaintained manually anyway.In general, our observation is that in a manually developed transforma-tions roughly half of the relations are top-level relations. We can distinguisha pattern showing that a transformation was written manually by a humanbased on the number of starts as it seems natural for a human mind to con-sider only one execution path.3107.2. Improving Prediction Accuracy using Performance CompletionsCOMP_MOM MARK_MOM R_HOT TRAN_TLines of Code 7582 6875 473 239Clean code 5789 6074 416 181Comments 220 165 13 4Number of relations 488 313 17 8Number of top level relations 330 22 8 3Number of starts 99 1 1 1Number of OCL queries 20 21 1 1Number of when-predicates 233 113 9 5Number of where-predicates 221 90 12 13Number of metamodels in transformation 2 3 3 2Average number of domains per relation 2 4.65 2.76 2.5Average number of domain pattern nodes per relation 2 14.78 11.53 2Average number of when-predicates per relation 0.9 1.78 1 0.63Average number of where-predicates per relation 0.49 0.87 1.82 1.63Average number of local variables per relation 0.001 0.48 1.05 2.38Val-in per relation 2.63 14.78 11.53 2Val-out per relation 2.3 4.45 3.66 3.12Fan-in per relation 1.12 1.67 1.34 0.78Fan-out per relation 1.02 1.34 1.2 0.7Average number of checkonly domains per relation 1.04 2.09 0.71 1Average number of enforce domains per relation 1.08 2.57 2.47 1Table 7.5.: Automatically calculated metrics.Figure 7.28.: Results: Transformation Complexity.3117. ValidationFigure 7.29.: Results: Relations Dependencies.Additionally, the difference between the number of relations and num-ber of predicates is negative for simple transformations, it is an indicator ofaverage complexity of relations (cf. Figure 7.28). It indicates that in onerelation developers used higher number of predicates. Together with theknowledge about the overall number of relations it shows that developercan do this only because they still have a quite good overview about thewhole transformation in this cases. On the other hand, for complex trans-formations this indicator is positive, the higher the value of this indicatoris, the more complex the relations are. The high average number of domainpatterns and domain pattern nodes in the MARK_MOM shows that some therelations have to be even more complex (have more predicates) and somedo not have predicates at all. The relations without predicates are so called’helper’ relations that are used to ensure validity of the target model or readconfiguration models. The MARK_MOM transformations has the highest num-ber of these ’helper’ relations. Which is an indicator that it was difficult forthe developer to get an overview about the overall functionality of transfor-mation. This could originate in complex dependencies between relationsthat are visible on results for the fan-in/fan-out metrics.3127.2. Improving Prediction Accuracy using Performance CompletionsThe R_HOT manifest very interesting ration between the checkonly andenforce domains. The number of enforce domains is significantly higheras the number of checkonly domains. This ratio shows that it is a gener-ator type of transformation. Similarly, the 1:1 ratio in the case of TRAN_Tindicates the translational type of transformation.DISCUSSION The presented results illustrate how software architects canevaluate the maintainability of their model transformations. Our experienceshows that the developers implementing one feature at the time focus onone aspect and thus the relations are less complex and focused, too. Togenerate or compose transformations from parts it is the best approach toimplement a lot of small and focused relations. On the other hand, theimplementation of mark transformation manifested increase in the relationsize, especially in the domain pattern complexity. Moreover, the code waspolluted with the ’helper’ relations used to read the configuration model.7.2.3.2. Complexity ComparisonIn this section, we address the last validation question Q4 regarding thecomplexity of feature effects development:Q4: Is the complexity of transformations decreased by separation of con-cerns in feature-related transformation fragments?SETTINGS To give an indicator of the transformation complexity de-creased by our approach, we provide an experiment based on comparisonbetween a generated completion and a manually written mark transforma-tion. This illustrates that the separation of concerns decreases the transfor-mation complexity and that mark transformations include a lot of infras-tructure code (e.g., helpers). This infrastructure code is could be avoided orgenerated as well. Additionally, as we shown in previous section, generatedtransformations are more structured and therefore better understandable.3137. ValidationIn this experiment, we evaluate the Thread Pool completion which in-tegrates performance-relevant details about the Thread Pool design patterninto software architectural models. We compare following two implemen-tation of this transformations:• MARK_TP - Thread Pool mark transformation• COMP_TP - Thread Pool completion transformationWe analyse both of these variants, MARK_TP implemented manuallyand COMP_TP generated (i.e., composed from transformation fragments),considering the extendibility and ability to debug the resulting transforma-tion. Both of these transformations were developed for the PCM metamodelwith the size of 290 classes.RESULTS The main advantage of our approach is that developers can fo-cus on effect of one selected feature at time and develop relations for thisfeature only, they are not concerned with all feature combinations and theirdependencies. In the mark transformation, the developer has to considerall the possible configuration combinations and check the state of features(selected or eliminated) by accessing additional model (e.g., feature model)from relations in the mark transformation. Even later in development, thedependencies (where- and when- predicates) between the relations need tobe resolved manually. These dependencies are solved in our approach bythe Composite HOT using the constraints for the transformation composi-tion. Table 7.6 gives numbers of generated lines of transformation code incomparison to lines of manually written mark transformation code. Thetransformation frame consists of a generated copy transformation (usingRoutine HOT), which is used by both manual and automatic fragment in-tegration. We extracted this part of both transformations and focused com-parison only on the customisation relations implementing the functionalitypresented in the running example 3.3.1 and the configuration presented inSection 3.3.3. The input model to be completed is a simple client-server3147.2. Improving Prediction Accuracy using Performance Completionsapplication and the completion skeleton that is injected into the model isdescribed in Section 3.3.2.4.As shown in this comparison, the generated customisation part of thetransformation consist of 7 relations in 3 fragments, these fragments couldbe reused in a case of an another feature combination. In a case of themark implementation without reusable fragments, we have to implement anew transformation for each feature combination. For the chosen featureconfiguration, the transformation consists of 8 relations.Complexity of the model290 metamodel elements11 model elements21 to be added/completed elements in the model18 features in the feature model4 chosen features in the feature configuration1008 possible feature combinationsGenerated transformation frame450 copy relations in the transformation5850 lines of code implementing the copy relationsCOMP_TP - Thread Pool completion transformation3 transformation reusable fragments7 relations in the transformation fragments195 lines of code implementing the relationsMARK_TP - Thread Pool mark transformation8 relations for one combination250 lines of code implementing the relationsTable 7.6.: Comparison of completion versus mark transformation for one featurecombination.The results (cf., Table 7.6) show that, to realise feature effects for the 4chosen features, we have to implement:• ThreadPool feature effect: one fragment for the root feature Thread-Pool consisting of one top-level relation and two normal relations.3157. Validation• Static feature effect: one fragment for the Static feature consist-ing of three relations. The feature OptimisationProperties doesnot have feature effect, because of the mandatory choice of one ofthe child features.• PoolSize feature effect: one fragment for the leaf feature PoolSizeconsisting of one relation.For the mark transformation, we implemented 8 relations to achieve thesame functionality. Each relation has to implement two input domains (i.e.,source and configuration model) and one target domain. The additionalrelation is a ’helper’ relation. Moreover, this simple mark transformationhas already 55 lines of code more as the fragment-based implementation.This is an indication that the size and complexity of this transformationwill grow significantly if the other valid configuration options would beconsidered (i.e., 1008 valid options).Legendorexclusive ormandatoryoptionalFeature DiagramMandatory FeatureOption 1 Option 2Optional FeatureFeature 1 Feature 2 Feature 3Figure 7.30.: Dependencies to other features for the Feature 3.Furthermore, the separation of concerns based on feature diagrams (cf.,Figure 7.30) helps even by extending of the configuration by a new fea-ture or debugging the transformation. When adding a new feature in themark transformation, we have to check the dependencies to the each rela-tion having or calling a relation that has the configuration model as its inputdomain. In such cases, the structure of feature model gives an navigationto the feature effects that have to be updated. That are, for example, foreach leaf feature all the feature effects on the direct path to the root feature3167.3. Summaryand all mandatory features in the feature tree. Additionally, all the featurespossibly referenced by depends constraint have to by considered.DISCUSSION The presented experiment shown that focused develop-ment using feature model is an advantage. Especially, the additional in-formation about the dependencies between feature effects intuitively hid-den into the structure of the feature tree supports completion developers.However, further empirical evaluation of the usability properties would benecessary to get quantifiable results.7.3. SummaryThis chapter presented the validation of completion-based improvementmethod for the accuracy of performance prediction. We structured the val-idation according to two main goals: First, we studied the accuracy of thecompletions them self. Second, we evaluated the quality characteristicsof the main elements supporting the automated completion-based MDSPE:the model transformations.With respect to the first goal, we found that:• Completed models correspond better to the reality and can predictsystems behaviour with a very high accuracy. The accuracy of pre-diction depends strongly on the modelled completion. In complexcases some influences (e.g., Virtual Machine optimisations) could notbe modelled with 100% accuracy to the reality, what could result ina strong deviation. However, in other cases the calibrated model fora platform can provide predictions with an error of less than 3%.• Using completion-based models we can predict not only the responsetime or throughput with high accuracy, but even the complex effectsresulting from state-dependency.3177. Validation• Even multiple completions used on one model element provide accu-rate predictions in the composition. Moreover, the order of comple-tion execution in a sequence could be evaluated using performanceprediction with our quality heuristics and help to identify the mostadvantageous sequence.• The quality heuristics are suitable to provide indications about anorder in a sequence of completions .With respect to the second goal, we found that:• The evaluation results show that completion transformations are morefocused and consist of smaller relations mapping mostly only onemodel element at time. Thus, transformation developers could eas-ily identify relations impacting one model element type. This givesan indication that completion transformations are better readableand understandable, because of lower complexity of domain pat-terns, stronger modularisation and less complex interdependenciesbetween relations in transformations. We use established evaluationtechniques using code metrics indicating the applicability of our ap-proach.• The feature model structure supports developers when introducingnew features and extending completion transformation. It focusesthe development effort through separation of concerns.In addition, the possible topics for future work are mentioned throughoutthis chapter. The most important of them is the empirical validation ofthe used techniques, especially the evaluation of the ability of developersto take advantage of declarative constructs and implement transformationsmore in relational as operational way.3188. Related WorkIn this chapter, we summarise the state-of-art of model-driven software de-velopment and performance evaluation both with respect to variability ofmodels. There are other approaches dealing with similar challenges as thisthesis, even though in different contexts and for different application do-mains. In this chapter, we compare the solution introduced by this thesis tosome of these approaches. With this objective, we divide and list them indifferent groups discussed in separate subsections. Some of the approachesare, however, not dealing with the core problem that we want to solve,but they analyse and propose solutions for other related or partial goals ofour approach. Numerous approaches could be discussed here, however,to focus our discussion we analyse methods that are applicable at the ab-straction level of software architecture, and thus we exclude more low-levelapproaches that deal with variability and refinement of code.The approaches related to the results of in this thesis can be classifiedinto two main areas. The first area, discussed in Section 8.1, consists ofMDSD approaches dealing with management of variability in transforma-tions and quality metrics for transformations. The second area, discussed inSection 8.2, covers approaches that explicitly utilise model-driven softwaredevelopment techniques, similar to completions, for software performancepredictions. The last Section 8.3 summarizes and compares the most im-portant of the discussed approaches to the results of this thesis.3198. Related Work8.1. Model Transformation EngineeringThe first area of the related work compares approaches that are similar tothe main contributions of this thesis: (i) model completions and their real-isation as an SPL for transformations built by HOT patterns; and (ii) qual-ity metrics for transformations. To reduce development effort and to in-crease the maintainability of transformations, the transformation languagesand tools have to support mechanisms for creating as well as integratingreusable transformation artefacts. Thus, the related work for the first con-tribution can be divided into two subgroups. The first group (see Section8.1.1) includes methods for development of transformations for reuse andthe second group (see Section 8.1.2) contains methods for developmenttransformations with reuse.8.1.1. Development of Transformations for ReuseTo create reusable transformation artefacts, the level of abstraction is es-sential. Current approaches are focused on reusing single rules of transfor-mations or on reusing whole patterns or transformation fragments. Trans-formation reuse at rule-level has been addressed by several transformationlanguage specifications, such as ATL [90], QVT [72] or VIATRA [5]. Thiskind of reuse is very fine-grained and focused on the reuse of separate map-ping rules. QVT, which is used to implement our approach and as such weinherit its reuse mechanism, provides reuse mechanism at rule-level basedon rule inheritance [72]. The oAW’s Xtend language [166] is an impera-tive transformation language, which includes explicit code-level support fortransformation aspects. This mechanism is effective to avoid common partsin code and structure the implementation, however, for the coarse-grainedreuse using patterns and templates it is not suitable.Typically, model transformation languages, e.g., ATL [90] and QVT[72], allow to define transformation rules based on types of the correspond-ing metamodels. However, such model transformations are not reusable for3208.1. Model Transformation Engineeringdifferent metamodels and must be defined from scratch again and again.Such language definitions do not allow metamodel variation. For exam-ple, ATL requires to specify the metamodel package name as part of themapping classifier. One exception is the approach of Varró et al. [5] whodefine a notion of generic transformations within their VIATRA2 frame-work. This framework in fact resembles the concept of templates in C++or generics in Java. Therefore, VIATRA2 provides a way to implementreusable model transformations and could be principally used to imple-ment our templates or feature effects in a metamodel-independent way.Metamodel-independent definition of feature effects is mentioned as oneof the possible future work directions in Chapter 9. Nevertheless, they donot foster a general template instantiation technique as it is proposed in ourapproach based on HOTs in Section 4.6.The coarse-grained reuse based on transformation patterns and parame-trised templates, which is supported by our approach as described in Sec-tions 4.4 and 4.6, has not been extensively treated yet. We can distinguishto types of approaches for coarse-grained reuse: (i) template-based and (ii)pattern-based approaches.Template-based approaches: Czarnecki and Antkiewicz [44] pro-pose a template-based approach for mapping feature models to conciserepresentations of model variabilities. Allowed configuration combina-tions depend on the existence of suitable model templates that are basesfor model instantiation. Our approach is not template-based in the sensethat templates and feature models are an additional input for the transfor-mation. We rather lift the template instantiation up to the transformationcreation itself. We configure templates and instantiate them into the finalproduct, which is again a transformation defined by feature model and aset of instantiated templates. The templates define independent transforma-tion primitives. Because templates are used to implement feature effectsin our approach, the complexity of handling all possible feature combina-3218. Related Worktions within the transformations is decreased and is made explicit throughthe structure of the feature model. Furthermore, we define a general tem-plate instantiation mechanism and use templates to implement parametrisedartefacts instead of reusing them directly.Pattern-based approaches: The reuse of transformations in theform of transformation patterns is still in its infancy. A first list of patternsin the context of graph transformations has been proposed by Agrawal etal. [2]. Moreover, they introduce a graph transformation language namedGREAT and a set of patterns for graph transformations. The introducedpatterns are structurally similarly complex than the patterns used for defi-nition of CBSE templates in Section 4.6. The difference to our approachis that these patterns are defined for graph transformations and a generalinstantiation mechanism is missing. Another initial list of patterns origi-nating from QVT Relations specifications has been collected by Iacob etal. [87]. Iacob et al. introduced an initial set of design patterns for trans-formation specification. This set of patterns act as an input of the RoutineHOT pattern in Section 4.4 that generates transformations implementingthe chosen pattern.In our approach, we provide support for both fine-grained (inherited fromQVT and using Composition HOT pattern) and coarse-grained (using Rou-tine and Template Instantiation HOT pattern) reuse. The focus of our workis not on a definition of new patterns, but more on the general MDSDstructures used to instantiate, integrate, and resolve parametrisations and tocompose existing patterns or templates that are specific for handling of de-sign decisions integrating domain-specific aspects. We identified a generalMDSD patterns in Chapter 4, so called HOT patterns, used to instantiatetransformation templates and design patterns and we automatically gener-ate transformations realising these patterns.3228.1. Model Transformation Engineering8.1.2. Development of Transformations with ReuseIn the MDSD context the reuse of transformations is one of the principalsoftware quality factors and a key to achieve higher productivity. In thedomains of model transformation languages, however, transformation gen-eration, transformation composition, template definition for model trans-formations, and application of HOTs for the reusability goals are relativelynew. In the following, we discuss the most important approaches in thisarea with special focus on the applications of HOTs.8.1.2.1. Generative Approaches for TransformationsA very important answer to the demand of automated model refinement isModel-Driven Development (MDD), which employs model-to-model trans-formations to refine system models. Czarnecki and Eisenecker introducedgenerator options in their book on Generative Programming [46] which isa predecessor of today’s MDD paradigm. They used feature diagrams tocapture different variants in the possible output of code generators. Featurediagrams model all valid combinations of a set of features called (feature)configuration where a single feature stands for a certain option in the re-spective input domain. Similarly, MDD employs feature diagrams as anadditional input into the transformations to mark activation of transforma-tion parts for a particular input model. Such transformations are so calledmark transformations [11]. In our case, the choice of active features iswoven into the transformation by a HOT. Thus, the concept of mark trans-formations is the same as ours, but we raise the level of abstraction a bitfurther.Another generative approach, an automated framework DUALLY [111],aims to answer the issues concerning the interoperability of tools and lan-guages. This approach introduces the concept of transformation generationwith the purpose of translating model specifications from one language toanother. The transformation generation is based on a mapping between3238. Related Workthese languages. The resulting transformation is generated based on themapping model. The generated transformations serve as translation mech-anism for models from one metamodel language to other. In current stateit is not possible to generate customisation (or completion) transformationsthat introduce new domain-specific model elements.The most related approach is the ATLAS Model Weaver (AMW) [47, 48]that offers abstraction mechanisms for definition of simple weaving opera-tors (mappings) describing correspondence between two metamodels. Thisprocess can be done manually or semi-automatically. The result is called aweaving model. The weaving model is an input for the higher-order trans-formation (HOT) that generates model transformations. The AMW ap-proach is implemented using Atlas Transformation Language (ATL), whichis a mixture of declarative and imperative constructs. Because of the im-perative constructs, the traces between the weaving operators and resultingtransformation are hard to follow in AMW and for each new operator thewhole HOT has to be adapted. Thus, the HOT is not general for all the op-erators, as in our approach, and the separation of concerns between the im-plementation of HOT and weaving operators is unclear. Finally, a weavingoperator always connects source metamodel elements to target metamodelelements, so it is not possible to realize complex transformation logic orintroduction of new domain-specific elements as by completions.Lately, Herrmannsdoerfer et al. introduced a language for Coupled Evo-lution of Metamodels and Models COPE [84]. COPE is proposed as asolution to the problems that arise due to metamodel evolution and the re-sulting necessary model migration to a corresponding newer version of themetamodel. This approach is based on a reusable migration transactionlibrary that is used for migration transformation generation. Although, itprovides advanced means for reuse of migration transactions and migrationtransformations, it is not suitable to express the variabilities of applicationfamilies based on metamodel-independent feature configurations.3248.1. Model Transformation EngineeringTransformation Composition approaches: The composition oftransformations causes additional problems and is subject to many currentlyrunning research initiatives. We can distinguish two types of transformationcomposition: internal and external. Internal composition consists of rule-based analysis, location of rule conflicts and scheduling of transformationrules, with the goal to merge two transformations into one.One internal composition approaches is [168] which proposes a superim-position composition technique for ATL and QVT Relations. Superimposi-tion is a white-box mechanism that allows to merge several transformationsin a final transformation containing union of all transformation rules andhelpers. Other works [130] and [114] investigate possibilities of compos-ing complex transformations from atomic transformation definitions. Ourapproach is different to these composition methods, because it is based on apredefined structure (i.e. the feature model) that guides the transformationcomposition. Furthermore, our focus is on metamodel-specific transforma-tion generation and not generic composition techniques. Therefore, manyproblems that arise when trying to compose arbitrary atomic transformationparts are avoided.An intuitive example for external transformation composition is MDD,the transformations are applied in layers, in an a-priori defined order, hencenot addressing possible conflicts in execution order. This is natural due tothe nature of MDD refinements, which are very general constructs. Theinformation that could lead an automatic conflict identification and resolu-tion is hardly generalizable under their setting. This type of compositionis called external composition where a sequence of transformation is cre-ated, thus the output of one transformation is an input for the next one in asequence.Among the external transformation composition approaches, feature-oriented programming approaches like AHEAD [8] allow only sequencesof independent transformations and do not consider any feature dependen-cies. In our work, we compose externally a number of completions applied3258. Related Workto the same model. Our approach is using the package structure of themetamodel to identify independent transformations which are easily com-posed externally. However, as discussed in Chapter 5, not all completionsare independent and require further conflict resolution mechanism. A re-lated approach of model-driven development for non-functional propertiesbased on transformations [142] also does not consider transformation se-quences. Some prior work has been done in the area of transformationsequences by Cooper et al. [39] with focus on searching for sequences ofcompiler optimisation transformations using random sampling. A line ofrelated research can be identified in design-pattern integration [54] wherethe conflicts in integration order are also very likely. However, the stud-ied integration processes are not quality-driven, and hence have differentcriteria that drive the decision on the optimal execution order. Approachestrying to identify an valid order of transformation in a sequence deal mostlywith the structural conflict and do not consider the quality conflict as ourapproach does.Other Transformation Variability approaches: Vara et al. [162]propose a method for model configuration by annotations. The annota-tions are drivers that specify the configuration of variable model elements.This process is manual and the method targets the context of databases andschema transformations. The usage of annotations is, however, very similarto our approach.8.1.2.2. Software Product Lines for TransformationsIn the area of product lines, several works [154, 70, 89] propose a mappingbetween features and model structure elements. These works proposed sup-port for automated derivation of product line members based on a feature-driven development method. The expressiveness of these methods dependson composability of the mapped structural model fragments.3268.1. Model Transformation EngineeringIn the work of Garces et al. [60] an approach for variability manage-ment in model-driven SPL (MD-SPL) was introduced. The advantage ofthis approach is that it offers a possibility to introduce custom rules, imple-mented in ATL, to handle feature model-based variability. The rules thendefine a specific pattern in ATL language itself, however, the transforma-tion definition becomes more complex and more imperative. This approachdoes not separate between variability definition and transformation defini-tion. Our approach is different in this point, we reuse variability definitionand provide more declarative transformation definition with better qualityproperties.Voelter and Grober [71] combine the practices of model-driven andaspect-oriented software development (AOP-MD-SPL) to manage variabil-ity in a whole development cycle. The approach uses aspect weaving tointegrate feature-model based variability into the target models. This ap-proach allows to have a separate feature model, specifying cross-cuttingvariability, to configure the input model. The developers have the possi-bility to implement variability as aspects on multiple levels of the transfor-mation sequence (i.e. in models, model-to-model, or model-to-text trans-formations). Variants are described on the model-level. A disadvantageof this approach is a limited support of weaving, which allows only addi-tive weaving without updates or overrides of model elements. Moreover,this approach does not propose solution for transformation languages suchas ATL or QVT. The aspect-orientation can be not only used to generateproducts, but even transformers and generators. However, our approachdoes not use aspect orientation, it provides mapping mechanism betweenfeature diagram and its realisation using elements of the target metamodel.Our approach defines variability on a level of higher abstraction, as we donot define aspects on the code level but on the metamodel level, so thatour approach lowers the learning curve for developers. Additionally, thedistinctive feature of our approach is parametrisation of features with thegoal to systematically improve the purpose completeness of the models3278. Related Work(i.e. performance prediction). To allow reuse of existing tools, our ap-proach transforms into the same metamodel, which is not the goal of aspectorientation.Another very interesting approach by Morin et al. [121] develops productlines for Domain-Specific Modelling Languages (DSMLs) (DSML-SPL).This approach generates a modelling language with variability managementcapabilities. Similar to our approach, the variability aspects are woven intothe domain metamodel at the level of higher abstraction and extend meta-model language. The significant difference is, however, that the resultingmetamodel is not the same language as the input; moreover, it is a composi-tion of two metamodels. Therefore, the tools implemented for the originalmetamodel are not reusable anymore. Additionally, their introduced ap-proach does not provide any description of automated support, using HOTsor other generative approach.8.1.2.3. Applications of Higher-Order TransformationsThe continuous growth of complexity, which can be noticed for trans-formations, and which has only recently been addressed by researchers,is already being investigated for models for several years. In his report[153] on industrial experiences with structuring large scale domain models,Störrle strongly suggests to reconsider the notions and experiences fromthe era of structured analysis, as many model types and disciplines devel-oped in the past are a perfect match for the architectural abstraction levelof very large-scale modelling (VLSM) projects. Czarnecki’s well-knownpaper [45] surveys transformation languages and presents a classificationscheme for transformation language properties supported by feature dia-grams. He describes higher-order rules as rules taking other rules as pa-rameters. Higher-order rules are mentioned as one of three techniqueswhich allow transformations to be parametrisable, the others being controlparameters and generics.3288.1. Model Transformation EngineeringBézivin et al. [24] differentiate between two views on transformations:the textual concrete syntax of some transformation language (implementa-tion view), and a semantically equivalent representation as a model (spec-ification view). According to the authors, HOTs provide the followingbenefits: Abstraction from concrete implementations, languages, and theirconstraints (synthesis), refinement and refactoring (rewriting/modification),validation and formal reasoning, e. g. compatibility checks (analysis), andformal description of syntax and semantics of modelling languages throughtransformation models. Further use cases of HOTs are not discussed. In thiswork, we provide a set of solutions using HOTs for more complex goals andinvestigate the applicability of HOTs for product line variability.Varró and Pataricza [163] point out the importance of non-functionalproperties of transformation languages, like compactness, reusability, andmaintainability. By allowing transformation languages to compute on mod-els of their own language, generic transformations (parametrisable trans-formations in our terminology), as well as meta-transformations (predom-inantly called HOTs by now) are specifiable. In analogy to higher-order-logics, generic transformations have decidability and performance prob-lems. These problems may be overcome by using meta-transformations toreduce generic transformations to non-generic transformations.Tisi et al. [158] provide a survey of different approaches using HOTsand propose a coarse classification of HOTs, called base patterns. Thesepatterns are primitives consisting of analysis, synthesis, modification and(de)composition. Subsequently, they try to give an overview on existingHOTs. The overview is not intended to be complete, it merely lists publica-tions known to the authors where HOTs written in the widespread ATL havebeen used in various areas. These HOTs are studied to support the proposedfiner-grained classification. Further classification attempts or surveys arenot known as the field of transformations and HOTs in particular is still im-mature. However, approaches implemented in QVT are not surveyed, andthe need for improvement of current transformation languages for higher-3298. Related Workorder implementations is not pointed out. The difference between basepatterns and our HOT patterns is that we propose generic patterns to solveparticular problems, such as feature model-based transformation composi-tion or template instantiation. HOT patterns are composite patterns whichemploy base patterns for partial task to achieve their overall goal. We defineHOT patterns as building blocks that support generic model-driven trans-formation generation architecture, where each of the patterns encapsulatesspecific concern (e.g. weaving, model-to-model transformation, templateinstantiation or model-to-text transformation).Furthermore, an example of HOT is synthesis of transformation from asource other as transformation, as applied by Goldschmidt et al. in [68].He creates a HOT to generate transformation rules to copy model elements.Input for the HOT in solution of Goldchmidt et al. is the QVT metamodel.However, he does not generalise the HOT definition and only describesinitial implementation. His implementation was inspiration for the HOTRoutine pattern introduced in Section 4.4 and is an example of Copyingand Marking version of this pattern.8.1.3. Quality Metrics for Model TransformationsQuality metrics have been studied already to measure quality (softwarequality was defined by [26]) of object-oriented software [56, 83, 141] andsoftware architectures [13, 151]. Metrics to estimate the maintainability ofsoftware are mostly based on measuring the size and complexity of code.Depending on the employed programming languages (functional, impera-tive, etc.) different metrics need to be employed for this task. Numerousanalysis techniques exist to assess quality (e.g. maintainability) of tradi-tional software artefacts. However, this is not the case towards analysingmodel transformations. The work of Anastasakis et al. [3] recognised thatquality, especially maintainability, of model transformations is crucial forthe success of MDSD. In their approach a transformation is considered to3308.1. Model Transformation Engineeringbe a model and as such existing model analysis techniques for maintainabil-ity can be applied (i.e., transforming transformations into the Alloy modelsand simulating using existing tools).The most relevant group of metrics for our approach is derived from re-lated work in the area of functional languages, such as the metrics definedby Harrison et al. in [78]. The group of relational transformation languagesis related to functional programming languages, therefore we can reuse theexisting functional metrics, similar to [160], in combination with some met-rics used for object-oriented languages. However, Amstel et al. [160] fo-cuses on model transformations created using the ASF+SDF transformationlanguage. Most of these metrics are, however, quite generic and could beapplied to nearly arbitrary functional programming languages. Neverthe-less they do not take into account the special character of relational trans-formations, such as their strong alignment to the source and target meta-models. Still, some of these metrics can be used to measure certain aspectsof model transformations written in QVT Relations. We adapted some ofthe metrics to the special requirements of the QVT Relations transforma-tion language and extended them by the addition of more specific metrics(especially the group of manual metrics). Furthermore, we automated thegathering of the majority of the metrics presented in this paper.In [66] initial considerations for transformation metrics based on a clas-sification of transformation features [46] and a goal-question-metric planwere presented. However, these ideas were still in a very early stage andwere not elaborated down to the special needs of different groups of trans-formation, such as relational transformations.Reynoso et al. [139] analysed how the complexity of OCL expressionsimpacts the analysability and understandability of UML models. As OCL isalso part of QVT-R these findings are relevant for our approach. However,the remaining part of relational transformations, apart from OCL expres-sions, cannot be analysed using this approach.3318. Related WorkA special way of gathering a maintainability metric based on the occur-rence of frequent patterns within a model or transformation was presentedin [105]. The presented metric is based on a pattern mining approach thatdetects the most frequently occurring constructs. The assumption madein that paper is based on cognitive psychology, which says that the hu-man brain works like a giant pattern matching machine and therefore canprocess things that re-occur often more easily. Thus, we incorporated thismetric into our suite.Using OCL for the definition of metrics was introduced by Abreu in[52]. However, the approach presented there did not cope with metricsconcerning the maintainability of transformations at all.8.2. Platform Completions for Software PerformanceEngineeringThe second area of the related work compares related approaches to thecompletions for SPE, as described in Chapter 5. The problem of addingperformance abstractions of domain-specific aspects into the models (i.e.,performance models) has been handled by using annotations only, or byinjecting substructures depicting missing aspect. The majority of the ap-proaches use only annotations to complete the model, for example to addmeasured overheads, etc. As we show for completions in Chapter 3, theinjected aspects and their structure may be very variable. However, thecommon deficiency of existing approaches is no (or only partial) supportfor configurability of modelled aspects. Moreover, most of the approachescompletely lack tool-supported automation. In the following, we discussrelated approaches in more detail.Woodside et al.: Performance-related Completions for SoftwareSpecifications [173] The initial work on completions is based on asimplistic definition of a completion as a quality-related annotation of a3328.2. Platform Completions for Software Performance Engineeringsystem model (e.g., with results of performance measurements). Wood-side et al. [173] envisioned the concept of completions in order to supplyadditional information not needed for functional specification but requiredfor performance prediction. They proposed performance-related comple-tions to close the gap between abstract architectural models and requiredlow-level details. The previously calibrated sub-models (or completions)are then added into to system models. The use of completions adds per-formance influences of a system’s infrastructure to prediction models and,thus, increase prediction accuracy. In the original approach of Woodsideet al. [174], performance completions have to be added manually to theprediction model. In [174] they planned a library of components for exam-ple database, middleware, or file system. Using a set of rules, completionsbuild by these components should be added into the models. They pointout that this should be done automatically.The difficulty of automation is a result of the flexibility and variabilityrequired for performance completions. This difficulty was identified laterby Woodside in [172] as a practical obstacle which kept off wider accep-tance of completions. Since the completions, as viewed by initial simplisticdefinition, are not expected to introduce variable structural changes to themodel and the conflicts of different execution orders is not of high inter-est, there is a little research on how the initial completion idea should berealised and supported. In order to provide tool support and to apply perfor-mance completions, we have to address the problem of variability. Model-driven development can provide the needed automation by means of modeltransformations, as we introduced in this work.In the work of Woodside, completions are injected as a part of trans-formations transforming directly into the prediction model (e.g., LayeredQueueing Networks). Thus, target models are on a less abstract level. In acase when we would have to transform into more than one prediction model(e.g., Layered Queueing Networks, Coloured Petri Nets) we would have toadapt all these transformations to know each possible completion. In our3338. Related Workapproach, we use model-to-model transformations that maintain the level ofabstraction. As such, the transformation from the component-based model(e.g., PCM) into the prediction model (e.g., Layered Queueing Networks)does not know about the completion and, thus, it is a simple translation thatcan be fully reused. Completions are then applied before the translation andresult of completion transformation is an input for a transformation into theprediction model.Another important difference is the understanding of completions. Wood-side et al. understands completions as sub-models that are not part of theproduct, but represent parts of its environment, such as middleware, filesystems, databases or web services used by the product. We consider com-pletions as a mean to include environment details but also design decisionsthat are a part of the product, such as design patterns or parallelisation ofdifferent application parts. Moreover, we do not use completions to includehardware related aspects such as storage models or virtualisation infras-tructure, for this purpose we use special approaches, for example [81].Moreover, we propose in Chapter 3 a structured process how to developcompletions; in particular we introduce an application of automated mea-surements and experiments with the goal to calibrate resulting completions.Happe et al.: A Pattern-Based Performance Completion for Mes-sage-Oriented Middleware [76] The authors of [76] analyse com-pletion for Message-Oriented Middleware (MOM). The resulting MOMcompletion was implemented a number of times, first, using classical Javaimplementation, second, using mark transformation where configurationserved as additional input for transformation, and third, using model-driventechniques introduced in this thesis . The MOM completion was addition-ally extended in this thesis, see Section 7.2.1.1. In this section, we discussthe deficiencies of integration approach used for MOM completion in workof Happe et al. [76].3348.2. Platform Completions for Software Performance EngineeringFigure 8.1 illustrates the overview of completion concept used in [76].They present an approach focused on the parametrisation of completions.The performance measurements using suitable test-drivers determine re-alistic resource demands for different platforms, like Java EE applicationservers. Moreover, test-drivers evaluate quantitative effects of differentconfiguration combinations. In our approach, this evaluation is encapsu-lated in the domain analysis step (see Section 3.3.2) and automated usingSoftware Performance Cockpit. In their approach, Happe et al. do not con-sider variability of the Completion Model Skeleton. Actually, their trans-formation integrates always the same subsystem with different calibration.However, this is not suitable when the subsystem should be variable too,for example because certain middleware services are not supported by aparticular platform. Thus, the approach presented by Happe et al. doesnot consider variability of completions and do not provide an automatedsolution for their integration.PerformanceMeasurementsPlatform-Specific CompletionRegressionAnalysis Parametric Resource DemandsCompletion ModelSkeletonsTest-DriverBenchmarkingIntegrationFigure 8.1.: Overview of the concept of parametric performance completions usedin [76]In our work, we focus on the creation of variable completion skeleton.Happe et al. use the selected combination of messaging patterns as config-uration (mark model) for model-to-model transformations. We generate acompletion transformation from the configuration for one variant only.3358. Related WorkS. Becker: Coupled Model Transformations for QoS EnabledComponent-Based Software Design [12] The coupled transforma-tion concept is the inspiration for the HOT pattern described in Section B.1.In this section, we discuss coupled transformations [12] as a realisation ofcompletion resulting in two different target models. Often starting with thesame source model we generate not only prediction models, but even theimplementation (or code).Coupled transformations are actually mark transformations, which makethe relationship between generated code and completion explicit. Theimplementation code in this approach is generated automatically using amodel-to-text transformation. Injecting a completion into the model usingmark transformation afterwards requires an adaptation of the code gener-ation transformation, too. Coupled transformations, in this case, are twotransformations, namely a model-to-model transformation (e.g., PCM toLQN) and a model-to-text transformation (e.g., PCM to EJB). Mark mod-els then configure both transformations, the transformation to code as wellas transformation to performance model. The models then consider thesame information for prediction as used for generating code.However, because the completion concept introduced in this thesis main-tains the level of abstraction, we can simply execute in a sequence firstthe completion transformation and afterwards any other model-to-modelor model-to-text transformation requiring the source model conform to thelanguage on the same abstraction level as completion applied. This is pos-sible, because the target model of completion is conform to the same meta-model as the source model. As such, all transformations applied after allnecessary completions consider the same information, without necessity oftheir adaptation.Furthermore, existing solutions [174, 76, 12] focus on the integrationof only one completion with one configuration at a time. If more thanone completion is applied to model element, conflicts between different3368.2. Platform Completions for Software Performance Engineeringcompletions are likely and have to be resolved. These scenarios are notdiscussed in any of the approaches [174, 76, 12].Related Approaches employing Model-Driven Techniques Insoftware performance engineering, several approaches use model transfor-mations to derive prediction models (e.g., [115, 132, 49, 12]). Cortellessaet al. surveyed a number of performance meta-models in [40] leading toa general model-driven framework for analysis of extra-functional proper-ties [42, 41]. In [42] they propose usage of reusable (but static) buildingblocks for platform models.Other approaches (e.g., [69, 165]) extend this framework. Verdickt etal. [165] developed a framework to automatically inject a construct verysimilar to completion (but without configuration possibility) into the mod-els. Their focus is on the impact of CORBA middleware on the perfor-mance of distributed systems. The provided vertical transformations de-crease the level of abstraction, as they map high-level platform-independentUML models to other platform-specific UML models.Grassi et al. provided a model-based approach for prediction model re-finement using intermediate language KLAPER [69]. The transformationsimplemented in QVT Relations integrate the overhead caused by commu-nication links into the models. They follow the same idea of using classicalvertical refinements from model-driven technologies to integrate aspects ofperformance and reliability into the models. Although the approach usesmodel transformations, it does not support their configurability.These approaches still neglect crucial issues that are an obstacle to theirapplication in practice. First, support for structured increase of model com-pleteness for the analysis of extra-functional properties is not considered.Thus, purpose-specific aspects cannot be integrated by configurable trans-formations and the model cannot be extended to fit particular purpose. Sec-ond, maintainability of the used model-driven framework and reusable con-figuration models is not discussed.3378. Related WorkRelated Design Pattern-based Performance Abstractions Theidea of using pattern-based model enhancements for improving quality-prediction accuracy of component-based models has been discussed in thecontext of connectors between components [149] and component adaptors,used to bridge interoperability problems when composing components. Ini-tial work has been done by compiling a classification of adaptation patternsby Becker et al. [14]. Additionally, Becker et al. sketch initial process toincorporate the patterns in a prediction process for extra-functional proper-ties. Besides performance, we can analyse patterns for other quality prop-erties, for example, there is also work looking at reliability prediction in thecontext of adaptation patterns by Reussner et al. [138].Spitznagel et al. investigated the relationship of architectural connectorsand common dependability techniques [149]. A special focus of their workwas the composition of more than a single connector to combined connec-tors. However, their main interest has been to guarantee properties of sys-tems like deadlock-freedom and not in the prediction of the extra-functionalimpact. Similarly, the work of T. Bures [28] analysed extra-functional prop-erties of connectors, however, he does not provide calibrated models suit-able for performance prediction and he does not use model-driven tech-niques. His work provides an initial input for domain analysis of connectorcompletions in Section 5.3.4.Performance Abstractions of Concurrency Design Patterns Inthe literature numerous approaches exist analysing parallel systems and theproblems by design of parallel software. However, in case of concurrency,pattern modelling focuses mostly on functional properties or only makelimited use of configuration options. Additionally, existing prediction ap-proaches only provide basic modelling constructs for concurrency patternsmodelling, leaving the creation of complex structures to software archi-tects. Concurrent software systems are especially complex, hard to modeland implement. Therefore, goal-oriented abstractions are desirable for such3388.2. Platform Completions for Software Performance Engineeringsystems. Several approaches exist addressing these issues partially and wediscuss these in more detail.E. Lee proposed to use modelling constructs for concurrency patterns[107] to increase understandability of concurrency, communication, andsynchronisation within a software architecture. He identified the thread-based models as a source for the difficult understandability of parallel soft-ware. As a solution to these problems he proposes language pragmaticsthat extend existing programming languages. The language pragmatics aredefined in a form of a coordination language targeted to support develop-ers when designing constructs for communication and synchronisation ofcomponents. He provesa major improvement of understandability of paral-lel software by using coordination pragmatics.In the Ptolemy project [108], the same author proposed using reusablebuilding blocks for communication composites based on the concurrencydesign patterns. Thus, using these abstractions they can introduce multi-threading in communication that is not already multi-threaded. Althoughit is a very promising approach, it neglects qualitative aspects, such asperformance and reliability. Similarly, Spitznagel and Garlan [149] usedconnectors to extract communication aspects from components. However,both approaches focus on hard attributes, like deadlock-freedom , neglect-ing qualitative attributes, such as performance and reliability.The performance engineering methods model concurrency, communi-cation and synchronisation on very low abstraction level. A first step tomodel distributed systems on a higher level of abstraction is made Smithand Williams in [147]. They provide four communication and synchroni-sation patterns in a form of UML sequence diagrams. These patterns canbe used to model interaction of components. In the area of performanceprediction for component-based systems, Liu et al. [110] model architec-ture patterns for application servers. In the first step of their approach,developers have to create a general model of a component container for theapplication server. The second step is analysis and design of architecture3398. Related Workpatterns in a form of activity diagrams. In the third step, a parametrised per-formance model is created correspondingly to the previous general model.To provide accurate performance prediction, developers have to integratethe characteristics and demands of the platform. Therefore, in the last step,they use a test application to create a profile of the platform. All steps, in-tegration of the platform profile and architecture patterns are manual, thusthe development effort does not decrease.8.3. SummaryThe previous sections give an overview on the approaches closely related tothis thesis. We have addressed approaches from two research areas, MDSDin Section 8.1 and CB-SPE in Section 8.2. The surveyed methods vary inscope and focus. In the following, we summarize the main findings andresulting deficiencies, which provide motivation for a more comprehensiveapproach. We provide two comparison studies of the most important ap-proaches from both of the research areas: From MDSD approaches, wecompare related approaches generating variable transformations and, fromCB-SPE approaches, we discuss the scope of supported features of com-pletions by the closest methods.The first category of methods dealing with variability in the MDSD con-text provides specialised solutions to support model variability (cf. Table8.1). In the comparison, we focus on comparing the generated artefacts anddeficiencies. The approach DUALLY actually implements similar solutionas is introduced by Routine HOT pattern for mappings. The AMW andAOP/MD-SPL employ mark transformations to support variability. TheCOPE approach supports external merge of transformations. The DSML-SPL merges two model instances into the target model that is conform tothe merge of two source metamodels. The deficiencies of these approachesare summarized in Table 8.1.3408.3. SummaryGenerated Deficiencies DUALLY Mapping rules used for translation between different metamodels. Missing support for customisations and complex transformation logic. AMW Mapping rules between source model and target model. These rules are specified by an active weaving operator. Mixture of imperative and declarative constructs. The HOT definition is not general, depends on existing weaving operators. Missing support for complex transformation logic and customisations. COPE Migration transformation which is an external composition of transactions from a library. No support for variabilities, e.g. in application families or based on feature configurations. DSML-SPL: Morin et al. Transformation merging several metamodels. Target metamodel changes, thus when the product is used for further analysis the tools are not reusable. AOP-MD-SPL: Garces et al. Grober et al. Variants of models based on feature-model-based variability definition. No separation of concerns between variability definition and transformation definition. Variability definition is an input into the SPL. Only additive weaving no updates or overrides. Table 8.1.: Comparison of related approaches from MDSD context.In our approach, completions are realized by configurable model-to-model transformations. We present an approach to define domain-specificlanguages that capture the performance-relevant configurations of differentimplementation details. The configuration provides the necessary vari-ability. The transformations are applied to model elements specified bythe software architect. We realise the completions by means of model-to-model transformations. Depending on a given configuration, these transfor-mations inject the completion’s behaviour into performance models. Thusin our approach the transformation is specified by the configuration itself.In the case of SPLs, the configuration happens on the lower level of ab-straction, thus the variability is bound to model instance more tightly andcan not be reused on the metamodel level. Furthermore, the changes oftransformation in our solution can be both fine-grained and coarse-grained.Many SPLs support coarse-grained variability, where the whole methodsare added. These methods encapsulating consistent fragment of function-ality. Fine-grained extensions, where a parameter is updated, domain pat-tern of a mapping relation changed or a statement added in the middle of3418. Related Workmethod, either require intricate workarounds or obfuscate the base codewith annotations [95]. In our scenario, such fine-grained updates happenoften. The classical SPL-based approach is limited to support such scenar-ios and produces often results of worse quality. Our approach reduces codereplication and improves readability.Moreover, in our solution the coupling between the features and thetransformation fragments is more explicit than in classical SPLs. In manyother SPL-based approaches the configuration describes the product itselfnot a way to the product as it is in our case. We rather lift the configurationup to the transformation creation itself. The configuration describes thetransformation and thus we have described the product, too. This way thecomplexity of handling all possible feature combinations within the trans-formations is decreased and is made explicit through the structure of theconfiguration model.The second category of methods deals with support for model comple-tions in a context of MDSPE for component-based systems (cf. Table 8.2).In the comparison we focused on three closest approaches. First, we de-scribe the criteria to compare these approaches: (i) the level of abstraction(“Is the abstraction level maintained?”) , (ii) supported variability (“Arecompletions configurable?”), and (iii) automation (“Is the integration ofcompletions automated?”). The first criterion is crucial for reuse of ex-isting tools and transformations, because any change of target metamodellanguage limits the reusability of tools using the target model. The secondand third criterion discuss the scope of variability support.In case of platform completions and coupled transformation the anno-tation (or configuration) of models happens on higher level of abstractionas the resulting target model is located . In both cases the transformationdecreasing level of abstraction (e.g. transformation from PCM to LQN)has to be adapted to handle the annotations and create the target modelvariant. Moreover, both approaches are realised by mark transformationsHowever, usage of mark transformation has a clear disadvantage. It is a Y-3428.3. SummaryIs the abstraction level maintained? Are completions configurable? Is the integration of variable completions automated? Platform Completions: Woodside et al. Annotations are on a higher-level of abstraction than the target model. No support. No automation. MOM Completion: Happe et al. Abstraction level is maintained. Partially, only the resource demands, changes of the skeleton will result in highly-complex and un-maintainable transformations. Mark transformation. Only single completion. Coupled Transformations: S. Becker Annotations are on a higher-level of abstraction than the target model. Partially, the complexity of implementation allowed only partial variability support. Mark transformation. Only single completion. Figure 8.2.: Comparison of related approaches from MDSPE context.transformation, which takes two input models, in this case model instanceand annotation, and creates one output model. Thus, such transformationhas to be adapted for each new annotation. Other previously discussedapproaches by Grassi et al. and Verdickt et al. [69, 165] have furthera disadvantage, they do not support flexible control of completions. Thisapproaches provide an all-or-nothing method where for example all con-nectors in model are replaced by the same completion with the same con-figuration.In this thesis, we have addressed the shortcomings of existing approachesand have proposed a method supporting variability of transformations byemploying and composing HOT patterns (see Section 4) into the SPL formodel-to-model transformations. The proposed method was applied to sup-port model completions in MDSPE in Section 3. In addition, we have de-veloped a structure completion library to reduce conflicts in application ofmultiple completions. At last, we introduced an initial set of completionsthat allow software architects to integrate different performance influencesinto the models. The creation of each completion is a research task on itsown and includes discussion of related work for the particular modelledaspect. The discussion of related approaches for each completion is out3438. Related Workof scope for this section, but it is a part of research in domain analysis bycompletion developer.3449. ConclusionIn this chapter, we summarize the contributions presented in this thesis(Section 9.1). Furthermore, we discuss achievements and current limita-tions of our main contribution, the CHILIES approach, and our additionalcontributions, the completion-based MDSPE, the structured completion li-brary, and the maintainability metrics for transformations (Section 9.2).Section 9.3 presents open questions and visions for future research.9.1. SummaryThe presented approach is motivated by the requirement to improve the ac-curacy of performance prediction in MDSPE approaches, e.g. the PCM,through automated support of performance completions. However, we ob-served that model-driven approaches lack an applicable and suitable so-lution for managing variability, which is necessary to support completions.We had to deal with this challenge, thus, the main contribution of this thesisis located in the MDSD area. We introduced generalised concept of modelcompletions and created automated support for them, which is based onHOT patterns. HOT patterns (CHILIES) are building blocks that can becomposed together to form more complex model-driven architectures. Inthe next step, we applied our approach in the MDSPE domain to automateperformance completions. For the PCM, a metamodel specially designedto support CBSE development and design-time performance prediction, weintroduced a structured completion library with an initial set of performancecompletions for concurrency design patterns. Furthermore, to evaluate re-sulting model transformations, we created a set of maintainability metrics3459. Conclusionfor relational transformations. To automatically collect the results of thesemetrics, we applied one of the presented HOT patterns, the Analysis HOTpattern.In the following, we look back at the leading research questions and dis-cuss how they are answered by this thesis. The research questions addresslimitations of existing approaches and were kept as general as possible.Thus, they lead to results applicable in other contexts as well.Q1: How to include purpose-specific aspects to models in an automatedbut adaptable manner inheriting its standard mechanisms and facilities,including transformations and tools?This question introduces three requirements on the resulting solution:automation, adaptability, and reuse of existing software artefacts, such asM2M/M2T transformations, EMF editors etc. We answered this questionby introducing generalised model completions, which are (i) automated bygenerated completion (i.e. M2M) transformations, (ii) adaptable by themanagement of variability in completion transformations using feature di-agrams, and (iii) allow reuse of existing tools due the maintained level ofabstraction (i.e. metamodel language).In our approach, we define model completions as horizontal specialisa-tions of models for a certain domain to achieve a higher level of purpose-specific completeness. Completeness quantifies the level of model detailon which the ability of a model to serve its purpose depends. Each modelis created to serve a certain purpose, in our application scenario it is perfor-mance prediction. As such, we can quantify the completeness for models asthe ability to evaluate the performance of the modelled system with the de-sired accuracy. Because these necessary details (e.g. design patterns, mid-dleware) are very variable, we defined model completions as configurablepurpose-specific transformations. These transformations increase the levelof model completeness while maintaining the language of the abstract level.This property of completions allows fully reusing existing MDSD tools,such as model transformations, without the need of any adaptations. Using3469.1. Summarycompletions, we maintain not only the original model language, but eventhe models are remaining in the responsibility of the same development roleon the abstract level. In our application scenario, the performance knowl-edge is inherently fragmented. Not every role involved in the performancemodelling process has the full knowledge of all performance properties ofeach aspect. Furthermore, these aspects appear in different contexts, appli-cations or variants. The concept of model completions supports specifica-tion of reusable constructs that can be applied in different contexts. Thus,performance completions could be used to support a Performance Knowl-edge Base, as envisioned by Woodside et al. in [172]. In comparison tothe Woodside’s idea, the Completion Library is not only organised aroundresults of analyses but even parametrised model fragments, expressed ascompletions, that are calibrated using measurement data.Each completion is defined by two parts: quantitative and structuralspecification. The quantitative part require calibrations using results ofmeasurements on real systems. The structural part is defined by a config-uration model, i.e. a feature diagram, and structural skeletons that are ex-pressed as a composition of feature effects (i.e., transformation fragments).As such, completions help to consolidate approaches based only on mea-surements, with those that exploit model-driven prediction techniques. Us-ing completions a partial views on the black-box systems through measure-ment data such systems can be integrated into the models. The requirementto converge these two domains was identified already by Woodside et al.[172]. In this thesis, we contributed to the solution of challenges identifiedby Woodside et al. in his visionary big picture of SPE domain.Moreover, we introduced an enhanced MDSPE process, where we il-lustrated the usage of completions to increase the effectiveness of modeldevelopment. This process supports software architects in development ofmore accurate models that are so complex that it is not feasible to createthem manually. Completion-based models are less complex and more un-derstandable because of the encapsulation of the aspect’s complexity in a3479. Conclusionform of simple configuration model. The completions decrease develop-ment efforts through automation and manageability of model complexity.Furthermore, completion-based development• closes the semantic gap between an abstract model and low-level de-tails (Chapter 3) that are in some cases necessary to fit the purpose ofthe model (e.g., performance prediction).• hides the complexity of the purpose-specific aspect, allowing config-uration of aspect variants and encapsulating domain-specific expertknowledge (Section 5.3).• when applied to the MDSPE, increases the accuracy of performancepredictions (Section 7.2.1).Q2: How to support configuration-based variability in model transfor-mations?The answer to this question is the main contribution of this thesis. Wecreated an automated support of completion transformations developmentusing pre-processors and generators based on HOTs. Typically, variabilitysolutions for MDSD or SPL deal with the variability of model instances.In our work, we recognized that dealing with the variability of modelsonly, would not do the trick. The problem is that when going the classi-cal way and using known MDSD and SPL paradigms, the transformationsare growing in complexity, extensions of configurations are not feasible,and the maintainability of transformations quickly becomes a huge prob-lem. Therefore, we decided to take an advantage of the abstraction levelsin MDSD and move the management of variability to an higher abstrac-tion level. In our approach, metamodels and transformations are subjectto variability. Raising the level of abstraction enables to focus on individ-ual aspects separately. Thus, the productivity of development is increasedby modularisation and MDSD structures are more flexible. We introducedthe CHILIES approach that builds on the definition of goal-specific MDSD3489.1. Summarybuilding blocks which could be combined to chains of transformations withmore complex goals. In our work, we identified a set of such buildingblocks using HOTs and targeting different goals, such as template instan-tiation or fragment composition. We compose these HOT patterns into thechains of HOTs to build complex MDSD structures.In this thesis, we applied three HOT patterns to create an SPL for com-pletion transformations. Using this approach completion developers canfocus on one feature at time and do not need to implement an overall trans-formation that can handle all possible feature combinations. The resultingcompletion transformation is generated for one configuration instance only.We composed in an one SPL following HOT patterns:• Routine HOT pattern generates frequently occurring patterns (e.g.copier) in transformations. The routine relation (e.g. copy relation)is generated for each metamodel element and can be used as a basisfor more complex transformations (e.g. model customisations).• Composite HOT pattern allows configuration-dependent transfor-mation generation. The configuration happens on a higher level ofabstraction. Thus, the configuration itself defines the transforma-tion. The transformation is a composition of transformation frag-ments, which define the effects of configuration choices.• Template HOT pattern uses parametrised transformation templates(as reusable transformation parts) and instantiates them into the trans-formation. Transformation templates allow modular definition oftransformation which yields a simpler definition of transformation.Using our approach, the completion transformation phase in the comp-letion-based MDSPE is fully automated. The transformation definition iseasily extendible with additional features. Moreover, the transformationand the configuration are loosely-coupled and the development of the con-figuration is separated from the transformation. Such separation of con-cerns allows reuse of completion definition, even easier implementation of3499. Conclusioncompletion in different language (e.g. ATL). Furthermore, we identifiedadditional HOT patterns which are described in Appendix B.Q3: How to structure the Completion Library to reduce possible conflictsin an application of multiple completions?To answer this question, we created a library of completions structuredaccording the development process and the roles appearing in this process.Our hypothesis is that the metamodel used to expressed models in this pro-cess maps the separation of responsibilities to different roles. Thus, it ispossible to distinguish sets of elements in a responsibility of one develop-ment role. As such, completions working with these elements only impactelements in an independent cluster of the metamodel which contains all el-ements possibly adapted by the one development role. Thus, it is possibleto identify sub-domains (i.e., independent metamodel clusters) which aresolely affected by a change induced by a particular completion transforma-tion and applied by a particular role. Based on this principle, we identifiedtransformations which are independent and reduced potential conflicts ofcompletions. Each role has only a small set of completions and can resolveremaining conflicts manually.Additionally, the introduction of a new completion should be easily pos-sible and conflict-free. Therefore, each new completion is registered withthe Completion Library and categorised in three levels, which include itsassociated development role, the metamodel element type to which it canbe applied, and the identification of dependencies to other completions ofthe same category.Furthermore, we created a set of completions for concurrency designpatterns. These completions are categorised in three groups: Component,Connector and Infrastructure completion. We introduced completions ineach group:• Component Completion: State Manager, Replication• Connector Completion: Pipe&Filter Connector3509.1. Summary• Infrastructure Completion: Thread ManagementWe analysed these completions and evaluated the prediction results us-ing completed models. The resulting models reflect the real system be-haviour more precisely leading to more accurate predictions. Therefore,performance completions allow a more realistic evaluation of different de-sign decisions. Moreover, we observed a dependency of performance onthe state of a component or a system. We analysed the impact of state onthe performance and created a set of experiments that are summarized inAppendix A.Q4: How to analyse maintainability of relational transformations?In the development of HOTs and different versions of completion trans-formations, we identified a lack of metrics to evaluate the quality propertiesof relational transformations. We presented a set of code metrics to evaluatethe maintainability of QVT Relational transformations. Such metrics canbe applied to different relational transformations and they play importantrole when analysing completion transformations. We demonstrated the useof these metrics on a set of reference transformations.The presented metrics help software architects to judge the maintainabil-ity of their model transformations. Based on these judgements, softwarearchitects can take corrective actions (like refactorings or code-reviews)whenever they identify a decay in maintainability of their transformations.This results in higher agility when changing metamodels of software archi-tectures or their platforms, which together with metamodel build basis fortransformation definition.Validation We validate our contributions on two levels: A Type I vali-dation shows that when completions are applied to a software performancemodel, the prediction accuracy can be increased significantly. We vali-date the prediction results by comparing them to measurements on a realimplementation of the system. The prediction accuracy of a single comple-tion is validated for two completions: the stateful case of Message-oriented3519. ConclusionMiddleware (MOM) (an extension of MOM completion in [76]), and theThread Pool completion. Additionally, we evaluate prediction accuracy ina composition of a multiple completions in a Business Reporting Systemscenario (based on [174]). For this scenario, we discuss different permu-tations in sequences of completions and evaluated the best possible com-pletion order. In the investigated cases, a significant correspondence withreality is achieved.A Type II validation analyses the applicability of the model-driven ap-proach using CHILIES. The main focus of this evaluation lies on the main-tainability and complexity of used transformations. We evaluated the com-plexity of a number of completion transformations and HOT implemen-tations. Furthermore, we compare the complexity between two differentimplementations of one completion, once implementing a mark transfor-mation and once implementing a completion in a form of feature modelwith corresponding feature effects. This experiment discusses the advan-tages of separation of concerns using the feature effects.9.2. LimitationsLimitations are discussed in particular chapters at the end of each contri-bution of this thesis. This section gives reference to the respective sec-tions and summarizes the most important assumptions and limitations ofour approach. Section 4.8 discusses various limitations and assumptionsof CHILIES approach. Section 5.4 presents limitations and assumptionsof completion library. Besides the overall limitation of completion library,each of the presented completions has its own assumptions and limitationsthat should be evaluated by completion developer in the domain analysis.Section 6.5 summarizes the limitations and assumptions of the introducedquality metrics for M2M transformations.3529.3. Open Questions and Future Work9.3. Open Questions and Future WorkThis section gives an overview of open questions and possible areas of fu-ture research based on the results of this thesis. First, we discuss the openquestions in the MDSPE domain. Second, we further evolve the usage ofadvanced model-driven techniques and discuss the open questions in theMDSD domain.9.3.1. Future work in the MDSPE contextAutomated Calibration of Completions Many completions are de-pendent on the deployment environment where they are applied, they areplatform specific. The high complexity and diversity of middleware plat-forms make the design of completions cumbersome. The high effort fortheir development may void the benefit. Especially, the calibration of com-pletions should happen automatically and the completion models shouldbe able to be recalibrated for any platform. This calibration should be ablack-box operation for the user. The idea is that the user chooses a plat-form and previously measured profile for this platform is loaded. Otherpossibility would be that user could chose his own computer as a platformto calibrate for, thus this platform should be automatically measured bypreviously defined experiment. At the time of writing, support for such op-erations is being developed for the Software Performance Cockpit [169].The resulting tool will provide different adaptors for different platform andexperiments. This tool than should be fully integrated into the tool supportfor completions.Additional Concurrency Completions For the future, an extensionof the approach to support a boarder set of concurrency patterns wouldbe a natural endeavour. Here, one could focus especially on the accuratebehaviour of these patterns, not the accurate calibration of them. Thus,the calibration should happen automatically the effort to get the accurate3539. Conclusionmeasurements manually would not be well spent. One may focus on thepatterns in measurement and simulation results manifesting effects as state-dependency, usage of asynchronous calls, capacity restraints that restrainthe level of concurrency, etc. Moreover, the clear separation of concurrencypatterns as a processing steps is a question to research, as well.Performance Tuning through Concurrency Today’s trend of multi-core processors poses new challenges to software development. As the onlyreason to introduce concurrency is the performance, the natural idea for thefuture work is to use completions as automated tuning steps to find outif concurrency introduction would be of an advantage for a given system.These predefined completions should be automatically applied to a givensystem in different configurations, combinations and using different work-loads. Such analysis will help the developers to decide about the mosteffective concurrency solution. Based on provided results the unsuccessfuldevelopment branches, where a high effort was spend to paralelise a systemwithout awaited result, could be avoided.Optimisation of Completion Configuration Optimisation approa-ches, such as PerOpteryx [113], could be used to automatically optimise theconfiguration of completions and the order in a sequence of completions fora better performance. The result of such automated optimisation would bea proposition of the most performant system configuration. For this goal,one would have to introduce the completion configuration as an additionaldegree of freedom in the PerOpteryx approach.Completions for other Quality Attributes Furthermore, comple-tions for other quality properties such as reliability or security could beintroduced. Having such completions will not only extend the completionlibrary, but it would allow to reason about trade-off decisions between a3549.3. Open Questions and Future Worknumber of quality attributes on a level of complex solutions for different,e.g. security vs. performance, problems.9.3.2. Future work in the MDSD contextNecessity of Empirical Studies It is required to further evaluate em-pirically different aspects of MDSD. First, one would have to conduct anempirical study to explore the effects of modularisation on the system andtransformation comprehension. It is accepted that reuse and automation isalways for the better. However, to support this claim we have to use em-pirical methods. Especially, the usage of modularisation in a collaborativedesign and development is a challenging task. The ability of the developerto modularise and map partial changes to the features is a related aspect tothe applicability of model completions. The participants of such empiricalstudy would have to implement a transformation generating a completedmodel by two different approaches (i) once as a coherent transformationand (ii) once as a set of modules. The development effort, ability to modu-larise and transformation comprehension in both cases should be studied.Second, the advantages of using relational instead of operational trans-formations have to be evaluated. There are many arguments in favour ofboth. Thus, we argue that empirical studies that incorporate developers us-ing both of the language families are key to decide the fight. The qualitymetrics introduced in Chapter 6 could be used to evaluate the complexityof transformations developed by the participants. In addition, we think thatthe advantages (e.g. modularity and compositionality) of relational trans-formations have to be considered. The compositionality aspect could bestudied by quantifying the amount of helper or service code needed.Compositionality of Transformations The composition of transfor-mations is a research field for itself. There are different approaches dis-cussing this topic. To perform the composition of model transformations,which is needed after selecting required configuration in feature model,3559. Conclusioninternal composition is used. Internal composition composes two modeltransformation definitions into one new model transformation, with a typ-ically complex merge of the transformation rules. Internal composition,when performed by a model transformation, is a higher-order problem. Weuse internal composition to compose fragments of transformations. Exter-nal composition consists of chaining separate model transformations andpassing models from one transformation to another. We use external com-position to create sequences of completions. In our approach the externalcomposition of transformations could be abstracted as a composition offeature models. The composition of transformations on the level of featuremodels promises decrease of composition complexity, we plan to investi-gate this idea further in future.Composition of model-to-model transformation should be guided by thepurpose of the resulting transformation. In our approach, some parts oftransformations provide a frame where customisations are injected. Thus,we think the transformation pattern-based frames composition with cus-tomisations should be analysed further.Automated Extraction of Transformation Templates The auto-matic derivation of templates from example transformation models as itwas proposed in [164] is interesting topic for future research. An automatedextraction of templates could use pattern matching to identify common pat-terns in a set of transformation models. From the identified patterns onecould derive templates with ’hooks’ for parametrisation and register them inthe template library. This would greatly ease the development of templatesas the manual extraction from an instance model to the transformation canbe shortened significantly.General definition of HOTs and Transformation Templates Me-tamodel-independent definition of HOTs will ease their reuse to generatetransformations in other transformation languages, not only QVT Rela-3569.3. Open Questions and Future Worktional. Moreover, the feature effects could be specified in metamodel-independent way to allow reuse of completions in other contexts, e.g. PCM,SOFA, etc. As a suitable language for metamodel-independent transforma-tion specification we propose to use VIATRA [5].View-based Model Development The completions allow to hidemodel details. With suitable tool support allowing to encapsulate and rolloff chosen completions we can build a collaborative environment allowingdevelopers to work on the same model, but with different level of detail.Moreover, purpose-specific views could be supported. Thus, developerscould browse the model details and choose the level of completeness theyneed.Model-driven Architecture Patterns The HOT patterns introducecomplex structures in a model-driven architecture. We consider this groupof patterns as ’model-driven architecture patterns’, because they are reusableand goal-specific building blocks composed from different artefacts (suchas models, metamodels, transformations). The introduced and upcomingHOT patterns need to be further formalised. HOTs, especially HOTs ofmultiple order are rare, the useful scenarios are still to be explored. More-over, an experimental evaluation and efficiency study of some of the HOTapplication scenarios described in this work is planned for the future.With the growing set of reusable building blocks in the model-drivenworld, it is more and more important to discuss the terms ’component’ and’architecture’ in this context. We propose creation of component-basedarchitecture models for MDSD. An architectural model will provide an ap-propriate mechanism to enable the modular and compositional specificationof complex model transformation chains. Such models could support veri-fication of complex MDSD systems and, moreover, allow to define a rela-tion or their composition as an part of classical component-based softwarearchitectures.3579. ConclusionHots and Transformation Languages From our point of view thefollowing topics could be addressed by HOTs in order to improve the ap-plicability model transformations in general:• Providing parametrization mechanisms directly, for example by pro-viding new language constructs. This can be done using HOTs orlanguage extensions.• Supporting techniques to ensure the correctness of transformations.Design-by-Contract methods could be brought to the module-level,for example as OCL annotations. Heuristics to check such annota-tions formally or logic to generate test cases could be implementedas a HOT. Further, error-handling possibilities can be provided bytransformation languages. Syriani et. al. are considering exceptionhandling [156], these language constructs can only be provided bythe transformation engine, whereas the higher-order level is insuffi-cient.• Hybrid transformation implementations, i.e., composition techniques,which permit mixing declarative (QVT Relational) and imperative(QVT Operational) code as tackled by approach [133]. Such mix-ing of declarative with operational code is already possible in ATL.Composition of rules or modules of operational or functional stylecan be implemented as a HOT.• Supplying developers with better tooling is crucial for more compleximplementations. Additionally, conformance to standards is still notguaranteed, e. g. full support of QVT Relational.Best-Practices for Metamodel Evolution We showed that the struc-ture of the metamodel could be a source of certain advantages for the futureusage of metamodels in model-driven systems. In the PCM metamodel, wecan distinguish disjunct clusters of metamodel elements. This metamodel3589.3. Open Questions and Future Workclustering maps the separation of concerns between the roles in the devel-opment process. Intuitively, we propose to introduce an metamodel spec-ification process, which considers the structure and roles in developmentprocess it will be used in. We think that the introduction of best practicesfor metamodel design considering future development of transformationswill contribute significantly to the correctness of transformations and de-crease their complexity.Metamodel Coverage of Transformations The dependency betweentransformation and metamodel is very promising target for further analysis.Analysis of the metamodel coverage by a set of transformations helps to re-solve conflicts in transformation execution. Additionally, debugging toolsvisualising this dependency and illustrating when the borders of a clusterin metamodel were crossed by a transformation could support composi-tion and chaining of transformations. It will help to identify and reduceconflicts in transformation execution. This way developers could identifyparts of functionality that could be developed in separation or that have tobe merged. This will increase the productivity in development of complexMDSD architectures. Moreover, it will open possibilities to optimise ex-ecution in transformation chains through identification of transformationsthat are independent already on metamodel level so they can be executed inparallel.Quality Metrics for Transformations The necessity of empiricalstudies for MDSD and any metrics for transformations is a clear issue.Additionally, the techniques evaluating presented metrics should be em-bedded in model transformation tools. The conducted studies showed thatthe metrics proved as useful for increasing the understanding of modeltransformations. This is a promising perspective, however, experimentsshould be conducted to empirically validate the benefits of the proposed3599. Conclusiontechniques. Furthermore, the performance of transformations is an anotherquality attribute that should be further investigated.An obvious point for future work is generalisation of the presented tech-niques for quality metrics, transformation composition from fragments,template instantiation or routine pre processors even further. All techniquesintroduced in this thesis were implemented in QVT Relational, as they useconcept of relations and as such are suitable for any relational language,the extension of these techniques for other relational language (e.g. ATL)is simple implementation task. However, the extension of these techniquesfor other language families (imperative, QVT Operational) has to be furtherinvestigated.Final Remark The work presented in this thesis is a step towards fur-ther automation of software engineering processes. It helps software de-velopers (i) by reducing development efforts for manually implementingtransformations, especially when variability of transformations is required,(ii) by defining a structured process for purpose-specific model completion,and (iii) by providing an automated transformation generation framework,called CHILIES, applicable in different practical contexts. In this thesis, weapplied the CHILIES framework to the area of CB-SPE developing an ex-tensible support for performance engineers. Our Performance KnowledgeBase (i.e., Completion Library) enables reuse of expert knowledge to im-prove the accuracy of performance predictions. In addition, our approachcontributes to the state-of-art in model-driven software development. (i) Itis the first approach introducing enhanced scenarios and patterns for trans-formation generation. (ii) It clarifies the requirements for transformationvariability and provides a flexible solution for transformation variability.(iii) It is the first method demonstrating how purpose-specific completenesscan be increased in a systematic, incremental and traceable way.360A. State Dependence in SoftwarePerformance EvaluationIn this chapter, we discuss effective state abstraction in component-basedperformance models. Our previous work on this topic was published in[94]. In addition, this discussion is an extension and motivation of thedomain analysis for the State Manager completion introduced in Section5.3.3.2.During the last years, many approaches dealing with performance pre-diction and measurement have been introduced. In the area of Component-Based Software Engineering (CBSE), systems are build out of reusableblack-box components (implementing sets of services) interconnected toa component architecture. Specialised component performance predictionand measurement approaches introduce modelling languages with the aimto understand the performance (i.e., response time, throughput, resourceutilisation) of a full architecture based on code-specific performance prop-erties of individual components.It is generally accepted that performance is a pervasive quality of soft-ware systems. Everything affects it, from the software itself to all under-lying layers, such as operating system, middleware, hardware, communi-cation networks, etc. [172]. The factors influencing the performance of asoftware component are difficult to analyse because they depend not onlyon the component implementation, but also on its usage, deployment andenvironmental context of the component (see Figure A.1), and occur at dif-ferent stages of component and system life cycle.Moreover, the difficulty of understanding system performance comesfrom the propagation of the effects of these factors throughout system con-361A. State Dependence in Software Performance EvaluationComponent ImplementationInternal StateRequiredServicesDeployment Platform ( Resource Contention )Usage ProfileFigure A.1.: Performance-influencing factors.trol flow, including the influence of the usage profile and history-dependentinformation defining system state. Besides these influential forces on theirown, the difficulty of understanding system performance comes from thevariability introduced by the factors and propagated throughout the system.This includes the variability in system control flow due to the propaga-tion of system usage profile and influence of system internal states, andsubsequent variability in resource demands awakened by the control flow,which results in complex sequences of resource requests and potential re-source deadlocks. While the influence of usage profile on system controlflow and subsequent performance has been studied and is commonly un-derstood [97], not much attention has been paid to the influence of systemstateful information.When speaking about a state, we mean a context or history-dependentinformation remembered inside a component, system, or associate with auser, and employed to coordinate system behaviour. The state of a com-ponent or system can originate from its initialisation or previous execu-tions, and can be changed at different stages of system life cycle, includingsystem initialization, deployment or runtime. The state associated with auser uses to be quite stable along system execution and is typically usedto customize system behaviour for a particular user type (i.e., standard orpremium customer). Only a few performance prediction approaches dealwith the modelling of states in component-based systems. Currently, thereis no consensus in the definition and method to model stateful information362in component-based systems and its performance impact, which limits theaccuracy of existing performance models [99, 98].A.0.3. Challenges of Stateful AnalysisThe question that rises for current performance models is how to include thestateful software application properties in a performance model, and howto build more accurate and expressive models of stateful component-basedsystems. In this respect, we can identify four main issues.• State definition: The property of statefulness can be identified invarious artifacts of component-based systems, varying over severalsystem life-cycle stages. Existing literature lacks the localizationof state-holding information identifiable in component-based sys-tems [16, 98, 172], and their classification into a transparent set ofcategories. Available surveys consider the capability to model stateonly partially or not at all. In this work introduced evaluation fo-cuses especially on this property of performance prediction models(see section A.2.1).• Performance impact: The benefits of state modelling include in-creased expressive power of the models and higher accuracy of pre-dictions. It is however not well studied, as observed by a numberof authors [98, 18, 172], what is the increase of prediction accu-racy achieved by state modelling, especially in comparison to theincreased effort for modelling and analysis. More important thereis no consensus in understanding of the state definition and its im-pact on performance at all [98]. A discussion on how the existingperformance-driven models deal with the interpretation and analysisof stateful prediction models is elaborated in section A.2.1.• Prediction difficulty: The balance between expressiveness (statemodelling) and complexity (model size increase) is a challenging re-363A. State Dependence in Software Performance EvaluationA. State Dependence in Software Performance Evaluationsearch question. Only when it is understood what costs need to bepaid for the increase in prediction accuracy, we can competently de-cide on the suitable abstraction of state modelling (to what extent weaim to include stateful information present in the analysed system).• State support in component models: The lack of work addressingthe discussed issues can be explained by insufficient support of state-ful information in existing performance-prediction models. Indus-trial models (like EJB, CCM or Corba) have been designed to supportinternal state, since it is one of the crucial implementation details,but lack the support of broad analysis capabilities with respect tosystem properties. Academic research-oriented stateful componentmodels (like SOFA [29]) are often accompanied with a special analy-sis method for a set of functional system properties (model checking),but not for performance, which is of our interest. The performance-driven research-oriented component models (see detailed survey insection A.2.1) either lack support for state modelling or model stateonly partially (see Table A.2). Additionally when they support statemodelling the performance impact of the state is unclear, as shownin the Table A.2. Consequently, because of missing support for statemodelling in the existing prediction methods the analysis of state de-pendency and related costs is not provided.It is important to understand the state definition and its impact on theperformance predictions. As mentioned by many works from performanceprediction community, for example [98, 18, 172], there is a need for deeperanalysis of component/system state, its impact on performance and situa-tions when is needed to model the component state for accurate predictions.The purpose of this work is to address some of the challenges of state mod-elling in performance prediction models.Missing research on performance influence of stateful information incomponent-based systems makes performance prediction for the majority364of industrial component models (e.g., EJB) difficult and limited. In thecomponent models, such as EJB, CCM, and COM, components are simi-lar to object-oriented classes in the sense that they can be instantiated andthat their instances can be stateful. Existing component models orientedon functionality and model checking (e.g., FRACTAL, SOFA) have sup-port to model component internal state. However, the impact of componentinternal state on performance (or reliability) is not evaluated. Componentmodels oriented on performance prediction have no notion of internal state,or they support internal state modelling and analysis only partially [98]. Tobuild better models and their solvers, we need to think about componentstate introduction [172]. To reach this goal in the existing performance pre-diction models, we deal with two kinds of problems. Firstly, these modelsdepend in many cases on assumptions, e.g. with the assumption of expo-nential service demand we need a significant effort to find a probabilityof timeout [172] (as such the probabilistic approximation of internal stateis very difficult). Secondly, analytic performance models based directlyon states and transitions deal with state space explosion problem [172]. Toovercome this issues we propose performance-model-suitable state approx-imations and guidelines for their introduction in the architecture model.This thesis addresses the challenges via three main contributions: (i)identification of stateful information in component-based systems and theirclassification into a set of categories, (ii) critical evaluation of state mod-elling in current performance prediction models, and an extension of a cho-sen performance-prediction language to provide sufficient state-modellingcapability, and (iii) state-dependency analysis evaluating the performanceimpact of the identified state classes together with the discussion of theincrease in the prediction difficulty introduced by state modelling.The chapter is organized as follows. Section A.0.4 realizes the first con-tribution. It identifies and discusses state-specific properties of component-based systems, localizes stateful information, and classifies it along twodimensions into a categorization. Section A.2 realizes the second contribu-365A. State Dependence in Software Performance EvaluationA. State Dependence in Software Performance Evaluationtion. It surveys existing performance-driven component-based models withrespect to state support, and extends one of the models, Palladio Compo-nent Model (PCM), to sufficiently support the identified state categories, asalready discussed in Section 5.3.3.2. Sections A.3 and A.4 elaborate thethird contribution by introducing an approach supporting software engi-neers with the information about performance impact and model-size costsof the individual state categories. In particular, Section A.3 outlines the ap-proach and discusses its foundations, while Section A.4 presents the con-crete observations from a set of experiments performed on both stateful andstateless PCM models for individual state categories, and formulates theminto a set of heuristics navigating software engineers in the decisions on anappropriate state abstraction in their models.A.0.4. Stateful Component-Based Systems (SCBSs)In this work, we understand the state as an information remembered in-side the system. A state is typically context or history-dependent, and isused to navigate system behaviour depending on the current state value.Therefore, a state influences system control flow, which propagates intoresource-demand sequences, and finally to performance properties (such asresponse time, throughput, and resource utilisation). A typical example ofa state is an attribute of an object in object-oriented programming, which isused to store information (updated by methods of the object) and which isemployed for customizing object’s response to incoming calls.In literature, two main streams of understanding a state can be found. Inthe first one [98, 73, 85], the authors attach a state as an additional informa-tion to behavioural models. A state can be used in behavioural decisions.The behavioural models set and read state explicitly. In the second one [29],a state is encoded implicitly in the current position in system execution (be-haviour). The main difference between the two is that in the first case, anupdate of a state is possible, and can be used to adapt the behaviour of the366element. In the second case, the state cannot be changed explicitly. Whenwe assume that a system comprises of interacting components, the impactof the state rises in the case of parallel usage of components, when all usersshare the same stateful information coordinating their behaviour.A.0.5. Specifics of CBSs with Respect to a StateThe state-relevant information influencing system performance can be foundat different stages of system life cycle. As distinct to classic software sys-tems, the life cycle of a component-based system constitutes of two sepa-rate abstraction lines—life cycle of a component and life cycle of a compos-ite system [31, 157]. Moreover, components can be of two types: primitiveand composite. Primitive components directly encapsulate implementedfunctionality, and are typically viewed as black boxes. Composite com-ponents are constituted by a composition of existing components, and areoften viewed as grey boxes. In a similar fashion, we assume that the state ofa composite component is simply a composition (an ordered n-tuple) of thestates of its sub-components. In this sense, a complete composite systemhas two kinds of states: (i) the implicit state inherited from the (primitive)components in the system, and (ii) an explicit state containing additionalinformation specific to the full system.Life-cycle stages of a component:• Specified component: represents a component frame with knownprovided or required interfaces. The performance model of a spec-ified component may include performance requirements, e.g. maxi-mum response time is 15 ms.• Implemented component: defines how the provided services of theimplementation call the required services. Including the definition ofperformance model consisting of behaviour performance abstraction367A. State Dependence in Software Performance EvaluationA. State Dependence in Software Performance Evaluationand resource demands, e.g. amount of requested CPU, hard diskor memory. Here defined resource demand could depend on inputvalues from usage profile or deployment platform.• Instantiated component: is an identifiable component instance de-rived from the implemented component, and ready to be executed (inits initial configuration). In some component models, all componentsare instantiated before launching the system, in others, componentscan be instantiated at run-time.• Deployed component: is a component instance allocated on a hard-ware. The performance model can now include resource demands ofrequired services and properties of the component container, operat-ing system and hardware.• Running component: is an actually executed component that servesclient requests (not necessarily in its initial configuration). At runtime, components can have a state used in current models for check-ing the violations of valid protocol states. In the performance model,at this stage the workload (i.e. the number of clients calling the com-ponent), the input parameters and information about concurrentlyrunning processes are known.Life-cycle stages of a composite system• Specified system: is a frame of the system with known access pointsand services required from the environment.• Assembled system: is an executable system assembled from imple-mented (instantiated) components, and ready to be launched (in itsinitial configuration).• Deployed system: is an assembled system deployed on underlyingsoftware and hardware.368A.1. State Categorisation for CBSs• Running system: is a system at any moment of its execution.The responsibility to model stateful information and initialise suitablestate abstraction is based on CBSE development process. We divide the re-sponsibility to model the state between development roles considering themoment in the development when certain role has enough information to re-fine the model with required state definition. The overall development pro-cess, integrating the evolution on both component and system level can beunderstood in terms of involved developer roles, which are component de-velopers, software architects, system deployers, and domain experts [102].Component developers (CD) code the components, and annotate their in-terfaces with abstract behavioural specifications, to facilitate the usage bythird parties. Software architects (SA) assemble selected components intoarchitectures forming the system. System deployers (SD) design the re-source environment (e.g. CPUs, network links), and allocate the compo-nents in the architecture to the resources. Finally, domain analysts (DA)communicate and specify the system-level usage profiles (call frequenciesand expected input parameter values), which then can be employed in for-mal reasoning about system properties.A.1. State Categorisation for CBSsTo find a definition of a state in the context of CBSs and performance pre-dictions, we studied different categories of states in existing component-based systems and component models (see section A.2.1). We observedthat the notion of component/system state involves various properties andis dependent on different execution processes in the system. With respectto these, we have identified two dimensions, along which we categoriseobserved state types.(i) Place dimension answers the question: Is the state proprietary to acomponent/system/user?369A. State Dependence in Software Performance Evaluation(ii) Time dimension answers the question: Is the state initialised orchanged at run/deployment/instantiation time?Table A.1 outlines the identified state categories. Along the place di-mension, it distinguishes component-, system- and user-specific states, alldefined below. With respect to the time dimension, we studied all stagesof component/system life cycle, and observed that a state is by nature adynamic information that evolves independently for individual elements inthe system. If it is fixed along a life cycle, it is not set before the elementgains its identity (instantiation stage in case of a component, assembly stagein case of a system). We refer to this moment as instantiation time. Thefollowing moments are the deployment time, which corresponds to the de-ployment stage of the life cycle, and run time, which belongs to the run-timestage.The rest of this section presents the identified state categories, structuredto three sections along the place dimension, and for each category, it out-lines a demonstrating example, and comments on its modelling.Table A.1.: Identified state categories.A.1.1. Component-Specific StateComponent-specific state is an information remembered for each compo-nent, and used inside the component to adjust component’s behaviour toincoming requests. Component state can be modified only by the servicesof the component, not by other components.370A.1. State Categorisation for CBSs(a) Protocol State: This state holds an information about currently ac-ceptable service calls of a component. It is typically part of an interfacecontract between service provider and its client [157].• Example: Consider a component managing a file, which can beopened, modified and closed. The component is initially in the statewhen it accepts only the request for opening the file. After that, itmoves to the state, where the file can be either modified or closed.Closing takes the component again to the initial state. The indicationfor a protocol state performance impact is, for example, rate of re-jected requests (contenting the communication link). Analogically,the protocol state uses to be employed also for modelling compo-nent life cycle, including stages like inactive, initialised, replicated,or migrated component.• Modelling: The protocol state uses to be identified by componentdeveloper, and attached to a component via a proxy, filtering the callson component interfaces. Illegal calls are either dropped or returnedto the caller with an exception.(b) Internal State: This state holds an internal information set by theservices of the component (at run time), and used to coordinate the be-haviour of the component with respect to the current value of the state.Internal state is externally invisible, and externally unchangeable.• Example: Consider a component that can be in either full or com-pressed mode, based on the remaining capacity of its database. Ifit is in the compressed mode, all insert queries on the database areadditionally compressed.• Modelling: The internal state is defined by component developer, andstored internally as a local variable of each component instance. Toreflect the state in a component model, there must be a possibility to371A. State Dependence in Software Performance Evaluationdefine such a local variable, set its value at run time, and query itscurrent value.(c) Allocation State: This state holds component properties specified atdeployment time, based on the allocation environment of the component.• Example: An example of a performance-relevant deployment prop-erty is for instance the maximal length of a queue used by the com-ponent. Such a property is set at deployment time, and remains fixedalong the execution of a component.• Modelling: The component-specific allocation state can be modelledwith a static component parameter, and is identified and set by thesystem deployer role.(d) Configuration State: This state holds instance-specific componentproperties, fixed during instantiation of the component.• Example: The configuration state may specify a selected parallel-usage strategy (like rendezvous or barrier synchronization), whichmay differ for each component instance.• Modelling: Similarly to the component allocation state, the configu-ration state can be modelled with a static component parameter. Inthis case, it is typically set by a software architect, who decides onthe configuration of the primitive components forming the assembledarchitecture.A.1.2. System-Specific StateSystem-specific state is an information remembered in one copy for thewhole system, and used to customize or coordinate joint behaviour ofindividual components. This state abstraction gains on importance withanalysing the state of virtualised systems, cloud computing or systems shar-ing deployment environment.372A.1. State Categorisation for CBSs(e) Global State: This (run-time) state holds a global information sharedand accessed by all components.• Example: A typical example of this kind of state is a global counter,remembering for instance the number of service calls executed in thesystem since the last back-up of the system, and triggering the back-up process after a certain number is reached.• Modelling: Global state is specified by a software architect duringsystem assembly, in terms of a modifiable system attribute (globalvariable). It can be either managed directly by the execution environ-ment, or be encapsulated within a component that manages it as itsinternal state, update its value on request, and answers the questionson its current value.(f) Allocation State: This state holds deployment-specific informationshared by all components in the system.• Example: The examples include the availability of supportive ser-vices of the underlying infrastructure (e.g., middleware), parametersof employed thread pool, or selected communication or replicationstrategies.• Modelling: The system-specific allocation state can be modelledwith a static system parameter, and is identified and set by a sys-tem deployer.(g) Configuration State: This state defines system configuration prop-erties specified before launching the system.• Example: This may be for example an upper bound on the number ofcomponent instances that may resist in the system at the same time.This is an information of a configuration character, and utilized byall components whenever a new component instance is to be created.373A. State Dependence in Software Performance Evaluation• Modelling: The system-specific configuration state can be modelledanalogically to the configuration state, and is identified and set by asoftware architect.A.1.3. User-Specific StateUser-specific state is an information remembered for each user, and used tocustomize system behaviour to the user.(h) Session State: This state holds a user-specific information for a sin-gle session. The information defining the state is forgotten when the sessionterminates.• Example: A session can represent one sale performed in a super-market system. Each sale may start with scanning a customer card,which then customizes system processing of the sale. The systemmay for instance dynamically recompute during the shopping pro-cess the prices of some products or their combination, which maybe time consuming and can influence the system response time for auser.• Modelling: This kind of state is derived from the information givenby a domain analyst, and could be modelled by additional input pa-rameter in usage model or by more specific component state param-eters. The behaviour in system per user/session could depend on thehistory of actions in the session, this history information could betraced in component internal parameters, what builds together withthe persistent state an overlap with component state definition.(i) Persistent State: This state holds a user-specific information through-out the whole existence of user in the system, independently on an existenceof a session belonging to the user.• Example: Each user of an online Media Store has a different limiton data for download under full downloading speed. The system374A.2. Performance Model for SCBSsTable A.2.: Component Performance Models Comparison.needs to remember this information to control the attempts of usersto download data over the limit, and regulate downloading speed ac-cordingly.• Modelling: The persistent state can be modelled analogical to thesession state, with a persistent data store involved.A.2. Performance Model for SCBSsThis section surveys existing performance-prediction component modelswith respect to their state-related capabilities, and summarizes their cover-age of identified state categories in table A.2.A.2.1. State of the Art EvaluationExisting performance-driven component models can be based on their an-alytical methods classified into four main streams: design-time, formal-specification, measurement, and simulation models.In the group of design-time performance prediction methods these arefew that partially support state modelling. First of them is the CB-SPE375A. State Dependence in Software Performance Evaluationapproach by Bertolino and Mirandola [22] that uses UML extended withSPT annotations profile to model component state or configuration in astatic way. The component model based on a proprietary metamodel Pal-ladio Component Model (PCM) [18] builds on statical state abstractionstoo. Additionally this model allows to model session state through addi-tional input data in an usage profile of a system. Despite of these state ab-stractions a need of further extensions for state modelling was identified inPCM [99]. The PECT model [85] deals with state modelling in a more de-tail and addresses the performance predictability properties of componentswith runtime system assembly variability. Even though the notion of stateis partially included there is no full support for including of this state-basedvariability in performance predictions. This model builds on a ComponentComposition Language (CCL) that allows to model component behaviourbased on statecharts. The performance impact of state is not further inves-tigated, the focus of state modelling is directed on model checking of func-tional properties. Additionally, based on statecharts and certain behaviourclaims, reliability of the system can be verified. Similarly, state is modelledin the Component-Based Modeling Language (CBML) with the possibil-ity to statically configure component parameters. In the component modelProCom [146] designed for embedded systems, state is modelled only stat-ically by a set of component parameters. Further, the component architec-ture of COMQUAD [118] is using Petri nets as a system behaviour model,however, the dependency of the service call on input data is ommited. A lotof other models claim an ability to express state changes but in many casesthey refer to the behaviour protocol checking [85], state changes monitor-ing [122] or performance annotations based on measurements [21].The formal specification model for testing of performance and reliabil-ity HAMLET [73] suggest to model state as an additional input (additionalfloating point external variables loaded in the time of component execution)and provide tests showing functional aspects of a state. The measurementapproach called AQUA [50] inherently monitors state impact (component376A.2. Performance Model for SCBSsdescription is given by the specification of EJBs) and showed how impor-tant it is to understand how system state is interpreted. Another approachto measure EJB applications NICTA [110] provides benchmarking meth-ods to get platform-independent information, such as thread pool size etc.The simulation-based approach MIDAS [4] determines performance char-acteristics of the system through state estimation or computation duringsimulation, for example queueing characteristics.A.2.2. Palladio Component Model (PCM)Based on the evaluation in section A.2.1 we decided to extend the PalladioComponent Model (PCM) [18] with further capabilities to model statefulinformation. This extension is one of the contributions we introduce inSection 5.3.3.2. The advantage of this model is its component-based nature,already partial support for state modelling and possibility to model usageprofile in detail.In this section, we informally describe the features of the PCM meta-model and focus on its capabilities for state modelling. The division ofwork targeted by CBSE is enforced by the PCM, which structures themodelling task to four independent languages reflecting the responsibili-ties of the four different developer roles outlined already in section A.0.5.The PCM already provides certain abstractions or approximations to modelstate: (i) static component parameters (or properties) characterize the stateof a component in an abstract and static way and hence offer a more flexibleparameterization of the model. These parameters are propagated throughdevelopment process differently, they are defined and initialized by a com-ponent developer and can not be changed at runtime. (ii) Limited passiveresources, such as semaphores, threads from a pool, or memory buffersresult in waiting delays and contentions due to concurrently executed ser-vices. (iii) Input data from usage profile allows to express session state.Table A.2 illustrates the capabilities of PCM to model identified state cate-377A. State Dependence in Software Performance Evaluationgories. In addition, the State Manager Completion extends the capabilitiesof PCM to model state as described in Section 5.3.3.2.A.3. Outline of the ApproachAfter identifying state types in component-based systems, and extendingthe PCM performance-prediction model to support them, this section to-gether with Section A.4 elaborates the third contribution of the thesis—astudy of the performance impact of the identified state categories, and anal-ysis of the influences that should drive the decision on the abstraction levelof state modelling.In design-time performance prediction, this issue has already been ad-dressed for various different constructs, including service parameters, re-turn values, or usage-profile propagation. Our approach gives an insightinto the issue of state modelling, which has not been addressed so far, andtries to help the software engineers to find the balance between accuracyand complexity of models more competently.In particular, the approach aims to help software engineers to assess ifthe increase in the prediction accuracy introduced by the state modellingoutbalances the price that needs to be paid for the increased model com-plexity. To compare the two metrics, we first discuss the quantification ofthe performance impact (see Section A.3.1) and the model size cost (seeSection A.3.2). Second, we discuss the similarities among some of thestate categories (in Section A.3.3), and design four classes clustering thestate categories that are similar with respect to our goal. Each of the classesis later analysed in Section A.4. For each class, we discuss the observationsabout its performance impact and model size cost and design a number ofheuristics condensing the advises for the software engineers. Each heuristicis experimentally evaluated and the results of the evaluation summarized inthe text.378A.3. Outline of the ApproachA.3.1. Quantification of Performance ImpactThe adopted Palladio Component Model (PCM) allows software architectsto quantify three aspects of system performance: response time (of a com-ponent or system service), throughput (of a service or communication link),and resource utilisation (of a hardware resource). All the three metrics arereported as random variables with probability distribution over possible val-ues together with their likelihood. The response time is expressed in giventime units (e.g., seconds), throughput in number of service calls or dataamount per time unit (e.g., kilobytes per second), and resource utilizationin the number of jobs currently occupying the resource.The three performance metrics for all the individual model elements areat the end all propagated to the system response time, which quantifies theresponse time of a given usage profile. The system response time is de-pendent on the response times of the user-called system services, whichdepend on the response times of component services included in the trig-gered control flow, resource utilization of the system hardware resourcesemployed during service execution, and throughput of the utilized commu-nication links (due to contention and overloading effects).In this thesis, we are hence primarily interested in the impact of statemodelling on the system response time, which can be additionally ex-pressed with different abstractions, including best/worse time, mean time,and others. Since for each of the abstractions, the state-modelling advicescould have different validity, we discuss all of them in Section A.4 althoughwe focus primarily on the probability distribution, which is the default met-ric used in the PCM.The individual metrics of system response time discussed in this thesisare: mean value, median value, best/worst case, variance, probability distri-bution, and time series. The first two metrics, the mean and median values,approximate the expected system response time. Although both are verypopular in statistics, they use to be considered too coarse-grained for per-379A. State Dependence in Software Performance Evaluationformance engineering. To make the response-time characterization moredetailed, the best and worst case values use to be given. Together withthe variance, these metrics already characterize the possible response timevalues quite concisely. However, if all these information is needed, thefull probability distribution of the response-time values is often required,alternatively formulated as a cumulative probability function. The most de-tailed metric is the time series which reports possible response-time valuesof individual system services in connection to the time when the serviceexecution has been started. The time series provides view of the evolutionof the response-time over the time, which is a basis for transient analysis ofsystems, however time series is the most difficult to analyse.A.3.2. Quantification of Model ComplexityThe complexity of a model can be best understood when translated to a low-level formal language with clearly definable size. One of the formalismsmost commonly employed for this purpose are labelled transition systems.In the case of component-based systems, different kinds of interacting au-tomata [176, 175] use to be employed, which allow us to specify largelabelled transition systems via composition of automata-based models ofindividual components. In [175], the inclusion of a stateful information in amodel is studied in terms of Component-Interaction Automata. It is shownthat a component/system state can be encoded as an automaton interact-ing with the automata for component services—answering their queries ofits current value, and accepting their commands to change the value. Themodel of a system is then a composition of not only the models of individualservices (implemented by the components), but includes also the models ofall states (whose size corresponds to the number of possible state values).Since the size of a composite component-interaction automaton is de-fined over a Cartesian product of the vertices of composed automata, thesize of the composite model can be in the worst case a multiplication of380A.3. Outline of the Approachthe initial stateless model with the size of the internal-state model. How-ever, our experience shows that not only that this case is very unlikely tooccur, but the model that includes stateful information can be even smallerthan the initial stateless model, due to a higher certainty about the futurebehaviour of the system. A more detailed discussion of this phenomenoncan be found in the sub-sections of Section A.4.A.3.3. Diversity Among State CategoriesIn section A.1 we have identified nine state categories. Though they allembody the same construct (defined in section A.0.4), their practically ob-served performance impact differs, and is influenced by different criteria.At the same time, however, one can also observe strong similarities amongsome of the categories.• Allocation vs. Configuration state: Both the allocation and config-uration state (consider the component-specific case for now) are fixedbefore the actual system execution. Thus from the performance pointof view, both can be understood as fixed component parameters, of-ten usable in an interchangeable way.• System vs. Component-specific state: Even if the component-basedsystem behaviour is encapsulated in components, and structured toarchitectures, its core is in the interaction of system services. If weabstract from component boundaries, we can find a strong analogybetween component internal state and system global state, and be-tween component- and system-specific allocation and configurationstate.• Session vs. Persistent state: From the point of view of performanceanalysis, the persistent state is analogical to a session state for onelife-lasting session.381A. State Dependence in Software Performance EvaluationThe identified similarities cluster the defined state categories into fourclasses: (1) protocol state, (2) internal and global state, (3) allocation andconfiguration state, and (4) session and persistent state.A.4. State Dependency AnalysisFor each of the four state classes identified in Section A.3.3, we performeda number of experiments and drew observations on the performance impactand costs of the state modelling, which we present in this section. For boththe performance impact and the cost, we compared the stateful model of aPCM instance to the stateless model of the same example, where the state-dependent decisions are guarded by probabilities (estimated as precisely aspossible). The observations are discussed for all the response-time met-rics defined above, although the heuristics have been primarily defined forthe probability distribution of the response-time values, which is the mostcommonly employed response-time metric.A.4.1. Protocol StateThe protocol state, which is the only state category included in this class,is used for a very specific purpose. It holds an information about currentlyacceptable service calls of a component.STATEFUL VS. STATELESS MODEL: Recall the protocol-state exampleoutlined in Section A.1. The protocol state in the example can have two val-ues: closed, when the only acceptable call is open(), and opened, when thecomponent can accept calls modify() and close(). Both the stateful andprobabilistic model of the example in PCM consist of three SEFF modelsand one usage profile. Each SEFF starts with a branch condition decidingif the service is going to be executed or rejected (see Figure A.2). Whilein the stateful version, the branch is guarded by a current value of the pro-tocol state, updated after executing open() and close(), the probabilistic382A.4. State Dependency Analysis<>State.VALUE == closed state.VALUE ==opened<>open<>state = closed<>state.VALUE = openedFigure A.2.: A SEFF of open().model fixes the probabilities of the branches based on expected likelihoodof the alternatives.PERFORMANCE IMPACT:Observations: A number of performed experiments with different vari-ations of the probabilistic model showed two main observations about theaccuracy of the stateful model comparing to the stateless model.Observation 1: The performance impact of the protocol-state modellinghighly depends on the a-priori knowledge of the usage profile, which ingeneral cannot be guaranteed since component behaviour and usage profileare typically defined independently by different developer roles.Observation 2: Even if the usage profile is known, the actual probabilitiesof service execution depend on component’s environment through whichthe usage profile is propagated, and thus can be very hard to quantify.Heuristics: There are two heuristics that can be derived from the obser-vations.Heuristic 1: The importance of protocol-state modelling raises with thelower knowledge of the usage profile.Experimental evaluation: Our experiments show that already a very lit-383A. State Dependence in Software Performance Evaluationtle inaccuracy in the usage profile may lead to a very imprecise stateless(i.e. probabilistic-abstraction) model, since the inaccuracies can be easilymagnified by system control flow1. This is true for all the response-timemetrics. There are two important arguments that justify the inclusion of thestateful information into the model in this case. First, significantly moreeffort is required in the stateless model to update its transition probabilitiesto a more accurate usage profile. Second, adaptation of the probabilities inthe stateless model does not need to be sufficient to reflect the usage-profilechange. A structural change of the model may be needed.Heuristic 2: The importance of protocol-state modelling raises with highercomplexity of component’s environment.Experimental evaluation: In some situations common in complex sys-tems, it may be very hard or even impossible to estimate probabilities forthe stateless model precisely. A simple exemplary model illustrating thisphenomenon can be build on the fact that the probabilistic abstraction canhardly be foreseen in the models where the same service is called twiceand each time behaves differently based on the actual protocol-state valuethat may change in the meantime. In such a case, two models of the sameservice would need to be present in the stateless system model to makeit accurate. Otherwise, all the response-time characteristics of the prob-abilistic model (even the mean value, which uses to be very stable) maysignificantly deviate from the values of the more-precise stateful model.MODEL-SIZE COSTS: The stateful model of each service has a unifiedform, having two independent alternatives: the first (complex one) if theservice is executable, and the second (trivial one) if the call is rejected (seeFigure A.2). In a stateful model of such a service, two sources of model-size increase can be observed.1Note that the Palladio Component Model (PCM) supports value passing and value-guardedcontrol-flow constructs, which implies that already a minor modification of an input valuein the usage profile may influence system behaviour significantly.384A.4. State Dependency AnalysisObservation 1: An increase due to state update after service execution.The model-size increases with the higher number of state updates after ser-vice execution. The increase in this case is however negligible.Observation 2: An increase due to remembering the actual state value,and accordingly executing only the right alternative. If the size of themodel is understood in terms of a labelled transition system (a graph de-scribing the paths of possible system behaviour), then the size remains un-changed as far as there is always only one state value for which each servicecan be executed. If a service can be executed in more than one values of theprotocol state, the number of vertices in the model can be multiplied withthe number of such state values. On the other hand, the complexity of thepaths throughout the transition system remains unchanged.A.4.2. Internal/Global StateThe internal state, as well as the global state, holds local (resp. global)information used to coordinate the behaviour of the system or its compo-nents.STATEFUL VS. STATELESS MODEL: Consider an example outlined inFigure A.3, with internal state processed remembering the amount of pro-cessed data, and coordinating a component to either process additional dataor perform cleanup. A probabilistic model would be analogical, with thebranches guarded with the probabilities of state values.PERFORMANCE IMPACT:Observations: The example outlined above was selected to disclose anadditional influencing factor (besides the two identified for the protocolstate), specific to this state category. It is connected to a possible corre-lation of state values in subsequent branches guarded by an internal state(typically with an additional execution in between of the branches).385A. State Dependence in Software Performance Evaluation<>processed >= limit processed < limit<>cleanUp<>processed = 0<>limit = 10<>processed = 0<>processed >=limit processed < limit<>processData<>processed = processed + 1...A B C DFigure A.3.: A SEFF of processData().Observation 1: Recall the example in Figure A.3 with strongly positivelycorrelated branches (let us denote the alternatives in the first branch A andB, and in the second branch C and D). Note that while in the stateful model,there are only two possible service executions (either A followed by C, orB followed by D), in the probabilistic model, four alternatives are possible(both A and B can be followed by both C and D).Heuristics: The observation can be summarized with the followingheuristic.Heuristic 3: The importance of internal/global-state modelling raises withthe higher correlation of subsequent state-driven decisions.Experimental evaluation: In the experimental evaluation, we used a num-ber of models analogical to the example outlined above, with an internalaction in between of the branches. The experiments for more details) haveshown that even if the probabilities of the branches accurately reflect theusage profile, the results computed from the stateless model can be veryimprecise. We have observed, that already in very simple models (one ser-386A.4. State Dependency Analysisvice with two or three branches), the probability distribution (mainly thevariance and best/worst case) of the stateless-model results deviates signif-icantly from the stateful-model distribution. The mean and median valuestend to be quite stable for these simple examples, and start to deviate whenmore complexity is introduced into the models.MODEL-SIZE COSTS: The model of a service involving an internal/-global state can have much more variability than in the case of a proto-col state, since the state-guarded branches and state updates can be presentanywhere in the model. This in the worst case implies multiplication ofthe model size with the size of the state (number of its possible values).In practice however, this case is very unlikely to occur. The likelihood isdecreased by the factors summarized by the following observations.Observation 1: A high connection of component behaviour to a statevalue. The model does not grow to the worst case if some of the behavioursare possible only under a particular state value. Then the combinations ofthese behaviours with the infeasible state values do not appear in the modeland restrict the size increase (analogically to the argument for the protocolstate).Observation 2: A low number of independent state-guarded branches.Recall the example outlined above. While in the stateful model with depen-dent branches two behaviours were possible (A;C and B;D), if the branchconditions were independent, four behaviours would be possible (A;C, B;C,A;D and B;D). However, a high number of independent branches doesnot increase the number of vertices in the model. It only increases thenumber of transitions, and hence the number and complexity of behaviour-describing paths.Observation 3: A small number of state updates. A smaller number ofstate updates implies a higher likelihood that some of the branch conditionswill always (or at least often) be evaluated as false and the behaviours thatfollow them will be removed from the model.387A. State Dependence in Software Performance EvaluationA.4.3. Allocation/Configuration StateThis class comprises of four state categories, in particular the component-specific and system-specific allocation and configuration state, all coordi-nating system behaviour according to a fixed (deployment or configuration)parameter.STATEFUL VS. STATELESS MODEL: Recall the examples of these statesoutlined in Section A.1. The most important property shared by all the fourstate categories is that they are fixed before the execution and hence co-ordinate component or system behaviour in a unified way during systemexecution. Again, while in the stateful model, branches may be guardedwith state values, in the stateless model, the same branches are guardedwith probabilities (reflecting the likelihood of possible parameter values).If we are uncertain about the actual value also in the stateful model, wecan include this uncertainty into the usage profile, which before trigger-ing the system execution configures the parameters with the correspondingprobabilities of their values and then uses them in a fixed way along sys-tem execution. On the other hand, if we have an absolute certainty aboutthe value of the parameter, we can reduce the stateless model (and actuallyalso the stateful model) to keep only the branch behaviours conforming tothe actual value of the parameter.PERFORMANCE IMPACT:Observations: The above mentioned specifics imply two main obser-vations influencing the effect of allocation/configuration-state modelling.Observation 1: As distinct to so far discussed categories, the general influ-ence of the allocation/configuration state to system performance is indepen-dent of the usage and the environment. For each service, the state-guardedbranches are evaluated in a fixed way, irrespective of the service clients.388A.4. State Dependency AnalysisObservation 2: On the other hand, the prediction accuracy is highly de-pendent on the knowledge of deployment/configuration parameters, whichallows the architect to cut off the behavioural branches in the statelessmodel that go against the expected value of the parameter. When such aninformation is not available to the component developer (since it is deter-mined by a different role) and the uncertainty about the state value needsto be expressed with probabilities, the probabilistic model exhibits highinaccuracies.Heuristics: The following heuristic can be derived from the observa-tions.Heuristic 4: The importance of allocation/configuration-state modellingraises with the lower knowledge of deployment/configuration parameters.Experimental evaluation: The experimental evaluation reveals that when-ever there is any uncertainty about the value of the parameters, which henceneeds to be in the stateless model modelled with probabilities, the modelmay become very imprecise. The reason for this fact is that while in thestateful model, the parameter value for the whole system execution re-mains the same (the uncertainty about the parameter value is included ononly one place, in the usage profile before triggering system execution),the stateless model includes also the behaviours reflecting the unrealisticcases of parameter changes during system execution (similarly to the phe-nomenon observed in Section A.4.2). Interestingly, the deviation of thestateless model from the stateful results tends to exhibit a common phe-nomenon regarding the probability distribution of the reported values. Inparticular, while the mean and the median of the results use to be the same(or very similar), the variance of the stateless results tends to be signifi-cantly higher, with much smaller best value (fastest response) and muchhigher worst value (slowest response) compared to the accurate results ofthe stateful model.389A. State Dependence in Software Performance EvaluationMODEL-SIZE COSTS: The model-size costs are influenced by the fol-lowing observations about the expected sizes of the stateful and statelessmodel for the same system (or system element).Observation 1: Stateful model of a single system element uses to belarger than the stateless model of the same element. This is the case when-ever the architect of the stateless model cuts off those branch behavioursthat go against the expected value of the parameter.Observation 2: In the case of aimed model reuse, the stateful model ofa single system element uses to have the same size as the stateless modelof the same element. If we do not know the value of the deployment/confi-guration parameter in advance (typical in the case of aimed model reuse indifferent contexts), the stateless (probabilistic abstraction) model needs toinclude behaviours implied by all possible parameter values, and hence hasthe same complexity as the stateful model.Observation 3: System models resulting from the composition of indi-vidual stateful model elements are never larger than the stateless compositesystem models. As the value of the allocation/configuration state does notchange along system execution, there is no increase in model size, quitethe contrary. Since all infeasible branches are never executed, the reach-able space of the stateful model can even be smaller than in its probabilisticvariant.A.4.4. Session/Persistent StateThe session state, as well as the persistent state, holds an informationremembered for each individual user, and used to customize system be-haviour accordingly.STATEFUL VS. STATELESS MODEL: Consider the session-state exam-ple in Section A.1, with sessions connected to individual sales, parame-terized by an information about the customer. The PCM model can bevery simple, propagating the user-specific state in terms of an input value390A.4. State Dependency Analysisthroughout the whole session. The component realizing the state then onlychecks the value and behaves accordingly. In the stateless model, the value-guarded decisions would again be replaced with probabilistic decisions.Any uncertainty about the parameter value would be expressed analogicallyto Section A.4.3.PERFORMANCE IMPACT:Observations: The session/persistent state exhibits some similarities,but also differences to all the state classes discussed above. It is very sim-ilar to the allocation/configuration state, but is not fixed along the wholeexecution (differs for individual sessions). It changes very rarely, and isupdated only on a specific place (similarly to the protocol state). On theother hand, it may guard behavioural branches anywhere in the execution,as distinct to the protocol state but similarly to the internal/global state.This implies the following two observations.Observation 1: First, the impact is not very dependent on the usage profileand environment, but highly dependent on the knowledge of the distributionof the state values (similarly to the knowledge of deployment parameters incase of the allocation/configuration state).Observation 2: Second, since the subsequent queries on the state value arehighly correlated, probabilistic models can hardly model session/persistent-state dependent behaviour faithfully (similarly to the internal/global state).This state class hence plays a significant role in the model, due to the im-plied strong correlation of subsequent state-guarded branches, and change-ability of the state value along system execution.391A. State Dependence in Software Performance EvaluationHeuristics: There are two heuristics that can be derived from the obser-vations.Heuristic 5: The importance of session/persistent-state modelling raiseswith the lower knowledge of the corresponding user-given parameter val-ues.Experimental evaluation: The validity of this heuristic can be explainedwith the same reasoning that was used for Heuristic 4.Heuristic 6: The importance of session/persistent-state modelling raiseswith the higher correlation of subsequent state-driven decisions – which istypically very high.Experimental evaluation: The evaluation is built on a set of examplesanalogical to the set employed in the evaluation of Heuristic 3. Moreover,it demonstrates that the correlation can be very high, since the state value(for both the session and persistent state) is highly stable along systemexecution (i.e. also between the state-dependent decisions).MODEL-SIZE COSTS: The experience learned about the size of the modelcan be summarized by the following observations.Observation 1: Connection of component behaviour to the state value.The increase due to remembering the actual state value is similarly to theinternal/global state dependent on the connection of component behaviourto the state value. The weaker the connection is, the closer the model cangrow to the worst case.Observation 2: Correlation of subsequent branches. Thanks to the cor-relation of subsequent branches, there is basically no complexity increasein terms of the behavioural paths.Observation 3: State update. There is basically no size increase due tostate update, since the state is not updated inside the system, and occursvery rarely.392A.5. DiscussionA.5. DiscussionThe decision about an appropriate abstraction of state modelling in component-based software systems is a very complex task. As we show, there are manyaspects that influence the decision significantly. We have identified manysituations when the probabilistic abstraction introduces high prediction in-accuracies, even if the transition probabilities are estimated as precisely aspossible. At the same time, the expected increase in model size may any-way discourage software engineers from including the stateful informationinto their models.In the following, we discuss the impact of explicit state models on an-alytical and simulation-based solution methods. Furthermore, we look atpossibilities to approximate the influence state probabilistically. From atheoretical point of view, our explicit state model increases the state spaceof the underlying stochastic process. Consequently, the complexity growsfor all analytical methods.Although we have identified a number of aspects that indicate a lowmodel-size increase in some situations, it is still very likely that statefulmodels have much higher complexity and size, which may complicate theiranalysis. Even if the models are not analysed fully, and are examined withsimulation methods (like in the case of PCM), model complexity may havean impact on the time needed for sufficiently accurate performance predic-tion (duration of a simulation run). We have observed on many systems,that the results of stateful analysis tends to have much smaller variance,which also influences the time necessary to execute a simulation run. Thehigher variability of stateless models could be observed in the variance ofthe results. As a consequence it influences the number of measurementsnecessary to achieve results with a high confidence.However, explicit statemodels can, of course, influence the variance of resulting response timedistributions and, thus, increase simulation time. But they enable the de-sign of more realistic models that result in more accurate predictions. The393A. State Dependence in Software Performance Evaluationincreased prediction accuracy justifies the additional simulation effort. Atthe same time, even if the stateful model is significantly larger, the con-fidence about the correctness of predicted values will be higher if a low-coverage simulation is run on a more accurate (stateful) model, than if ahigh-coverage simulation is run on an unrealistic (stateless) model.When studying the performance impact of state modelling in Section A.4,we have compared stateful models to their approximations with probabilis-tic models. As shown in the text, even if the probabilities in the statelessmodels reflect system usage and environment, the results of the perfor-mance evaluation may deviate significantly from the stateful models. Thedeviation is best visible on the probability distribution of the response-timevalues and the time series, which are the most fine-grained metrics. Alsothe variance and best/worse case are very different, with a higher varianceof stateless models. On the other hand, the median and mean values use tobe quite stable, deviating often only slightly from the stateful model.There are many types of systems, where the probabilistic models canapproximate the stateful models very closely. For example, the influenceof transactions (described in Section 7.2.1.1) can be approximated prob-abilistically, if the waiting time of a message is known and modelled asan explicit delay that depends on the number of messages sent within thetransaction. To achieve this, performance analysts have not only to knowin advance the number (which is static and can not change at runtime) ofmessages in a transaction as well as the influence of a message on the trans-action’s delay (which needs to be adapted for each change in the transactionsize to get accurate predictions).A.6. SummaryThis work addresses the challenges of performance prediction for state-ful component-based software systems. To achieve this aim, we have ac-complished a number of tasks. We investigated the requirements and the394A.6. Summaryoffered expressiveness of prediction models for stateful systems. We sur-veyed the state of the art and extracted a classification scheme of variousstate-defining and state-dependent model parameters. After that, we crit-ically evaluated the possibility of modelling introduced categories usingstate abstractions in current performance prediction models. As a result,we extended the Palladio Component Model to provide sufficient state-modelling capability, and evaluated the benefits and costs it brings in astate-dependency analysis. In the state-dependency analysis, we furtheridentified the similarities and differences of the individual state categorieswith respect to their performance impact and model-size increase, and in-troduced and evaluated a number of heuristics summarizing the advices tosoftware engineers, and helping them to competently decide on the appro-priate state abstraction in their models.The future work includes further analysis of the individual heuristics andmethods for their automatic evaluation on a system model. The first stepsinclude decomposition of the heuristics to more concrete ones that defineexact conditions to be checked on the analysed model. The automatizationwould also include employment of expert techniques to determine an ap-propriate abstraction on the state values, to keep the model size and modelaccuracy balanced. Another aim of our ongoing research is to examinethe impact of the hardware-specific state categories, which may reflect theavailability and speed (based on the actual workload) of system hardwareresources. New challenges also rise from the introduction of dynamic ar-chitectures and support of virtualisation scenarios and dynamic allocation.395B. Further HOT patternsIn the following sections, we discuss additional HOT patterns for furtherscenarios. During our work, we developed an automated support for differ-ent goals and scenarios using advanced MDSD techniques, such as HOTs.We structured and extracted additional HOT patterns based on these scenar-ios. The extracted patterns provide support for Shared Configurations, Re-tainment Policies, Model/View Synchronisation, and Transformation Anal-ysis.B.1. Shared Configuration HOT PatternShared Configuration pattern is based on the observation that transforma-tions as a whole are also entities of reuse. Becker [11] first introducedvery similar concept, so called Coupled Transformations, in order to fac-tor out shared parts of transformations. This pattern try to give an answerto how transformation knowledge can be reused, and can be consideredas an immediate application of Czarnecki’s [46] Generative Programmingmethodology to the field of transformations.B.1.1. Motivation:In software development, refinement transformations are entities which en-capsulate design decisions to be applied to an architectural model. Apply-ing design decisions is leading to certain platform-dependencies, and finallyresults in an implementation model.However, besides an implementation as one purpose, engineers couldbe interested in further transformation objectives, for example the perfor-397B. Further HOT patternsFigure B.1.: Shared Configuration pattern.mance impact certain design decisions introduced into the model. In thissetting we have a number of existing transformations towards different ob-jectives. However, often the initial design decisions change during the de-velopment. After such a change, all existing transformations have to beadapted to correspond this new design decision. Instead of manually adapt-ing each transformation, it is recommended to keep code for one designdecision and different transformation objectives separated.B.1.2. Implementation:Figure B.1 depicts one HOT being able to automatically synchronise twotransformations for the same configuration options (a shared synchronisa-tion point), one targeting code, the other targeting for example performanceaspects. As a result, the possible set of configuration options can be de-scribed in a single model.Becker et al. originally implemented coupled transformations in Java,because no working implementation of a transformation engine was avail-398B.2. Retainment Policies HOT patternable back then. At that time, variability in configuration options had beenlimited on simple Boolean constants for the parameter values only.B.1.3. Benefits and Drawbacks:Shared Configuration pattern, implemented on the basis of HOTs, rendercode with higher reusability and provide better support for variability. Onthe negative side, it should be noted that transformation rules written onthe meta-level, is harder to read and maintain through the inherent indirec-tion introduced. However, if models are expected to be used for multiplepurposes the increased effort should pay off.B.2. Retainment Policies HOT patternThe retainment policy approach introduced in [67] aims at the preserva-tion of external changes in target models of transformations. To achievethis [67] introduced an annotation approach that allows transformation en-gineers to attach retainment policies to transformation rules. These policiesthen define how a re-executed transformation deals with external changesin target models, i.e., overwriting the change and resynchronising the targetmodel according to the source model, or, keeping the external modificationdiscarding updates from the source model. The paper also presented pat-terns on how the policies can be expressed in terms of QVT Relations. AHOT is then responsible for weaving these patterns into the annotated trans-formation, yielding a modified transformation that behaves like the originaltransformation but with the desired behaviour w.r.t. external changes to thetarget model.B.2.1. Motivation:For realising the retainment policy approach, two different possibilities ex-ist. First, a library-driven approach, meaning that a reusable set of rules399B. Further HOT patternsFigure B.2.: Retainment policies.exist that implement each retainment policy. A transformation could usethese generic rules to identify target changes and decide how to handlethem. Second, the HOT approach which uses external annotations to thedeveloped transformation and generates a new version of the transforma-tion which incorporates the annotated retainment policies into the devel-oped transformation.We chose the latter option because we targeted QVT Relations as trans-formation language. The retainment policy approach is based on the infor-mation provided by the trace of the transformation. In the MediniQVT [88]implementation of QVT Relations the trace model is strongly typed withthe actual domains employed in the transformation. Therefore, also therules realising the retainment policies would have to be typed in that way.As we can determine this only when the transformation under developmentis available this decision needs to be deferred to a later point in time. There-fore, we used a HOT to weave in the retainment policies at build time ofthe transformation under development.B.2.2. Implementation:We implemented the HOT approach so that it uses the model of the trans-formation under development as well as the annotated retainment policiesmodel as input as shown in Figure B.2. The output is then a modified400B.3. Model/View Synchronization HOT patternsource transformation incorporating additional parts and rules for handlingthe changes to the target model.B.2.3. Benefits and Drawbacks:Using the HOT approach in this scenario we did not only achieve the re-quired later binding time of the retainment policies but also achieved a bet-ter separation of concerns. The retainment policies are now completelyexternal to the transformation under development. Therefore, this transfor-mation only contains domain-related information and is not polluted withtechnical concerns, i.e., the rules implementing the retainment policies.However, applying HOT in this scenario has drawbacks as well. The ma-jor drawback is that debugging becomes more difficult. As the transforma-tion that actually runs (the generated one) is different to the transformationthe transformation engineer actually developed either he/she needs to haveknowledge on how the code of retainment policies works or the transfor-mation debugger needs to be modified in order to make the transformationmodification transparent.B.3. Model/View Synchronization HOT patternThe synchronisation between model and views on that model has been in-vestigated in several view-based modelling publications (e.g., [57, 61]). Aspecial kind of view-based modelling is the area which merges textual mod-elling with the view-based modelling paradigm. In [64] was presented anapproach that allows to create textual views on models based on a decora-tor approach comparable to the one used in graphical view-based modelling(see e.g., [53]). This textual decorator model is called TextBlocks-Model.As both the TextBlocks-Model as well as the underlying domain modelare subject to modifications, an incremental and bidirectional update ap-proach is required. To achieve this transformation was a synchronisationapproach [65] written in Java created. This approach works like an inter-401B. Further HOT patternspreter as it takes the view definition model into account when performingany synchronisation. However, this approach has several drawbacks w.r.t.debuggability and performance. Therefore, we investigated a HOT-basedapproach for realising the model/view synchronisation.B.3.1. Motivation:Having access to the view definition model which defines the mappingbetween textual view and the view’s underlying model in a declarative,template-based manner served as an optimal starting point for employinga HOT based approach. The idea was to automatically generate modeltransformations from these view definitions that bidirectionally synchro-nise views and models. As both, the underlying model, as well as the textualview, in form of the TextBlocks-Model are available on model level, theycan easily be accessed using model transformations. After having prob-lems w.r.t. debuggability, due to the interpreter-based approach we decidedto employ a HOT-based approach.B.3.2. Implementation:In this scenario, the HOT is employed as a means to bring the declara-tive, non-executable view definition to an executable level. If a declarativetransformation language is used, the transformation itself is declarative aswell. Therefore, as shown in Figure B.3, the input of the HOT is the viewspecification whereas the output is the synchronisation transformation.B.3.3. Benefits and Drawbacks:Using HOT-generated transformations in this scenario allows language de-velopers to more easily debug the synchronisation process. The interpreterin the previous synchronisation approach required the developer to thinkon two parallel layers at the same time, i.e., the code of the interpreter as402B.4. Analysis HOT patternFigure B.3.: Model/view synchronization.well as the mapping model that is currently interpreted. Instead, the de-veloper can now focus on debugging a transformation. As the translationbetween a mapping and a transformation is a one-to-one relationship, alsoa simple debugger interface lifting debugging to the mapping level couldbe provided.On the down side, using the HOT approach in this scenario adds com-plexity to the development. An additional artefact, i.e., the HOT has to bemaintained and tested.B.4. Analysis HOT patternAlong with the wide acceptance of the MDE paradigm in the industry, ahigh number of transformation scripts need to be maintained in the foresee-able future. In order to guarantee high code quality, we require metrics toevaluate the quality of transformation scripts.In [159], a collection of metrics has been elaborated and implementedas HOT in ATL. Additionally, the authors applied these metrics in a case403B. Further HOT patternsstudy to judge the quality of example transformations bridging betweentechnological spaces.B.4.1. Motivation:While metrics exist to judge about maintainability of imperative languages,there is a shortcoming of metrics which are focusing on declarative lan-guages like QVT-R. In Section 6, we propose a set of metrics w.r. t. trans-formation size, fulfillment of relational properties, degree of consistencyand level of inheritance.Figure B.4.: Transformation metrics.B.4.2. Implementation:As depicted in Figure B.4, we used OCL query functions, embedded intoa HOT in QVT-R that transforms a QVT-R transformation into a specialmetrics model.B.4.3. Benefits and Drawbacks:Automatically computable metrics help to make quality assurance of soft-ware engineering ease-to-use. Although many metrics are easy to imple-ment as a simple expression, some metrics exist, for which no efficientstraight-forward algorithm is available. Among them are: the similarity ofrelations, the number of relations following a design pattern, or the rate ofoverlapping rules w. r. t. a transformation’s source and target metamodels.404B.5. Future ScenariosFurther, a clear, formal definition of metrics and their computation makequality assurance a reproducible process. Because transformations are alsomodels, it is a straightforward approach to analyse transformations basedon their syntax tree. However, metrics based on the real sources are easierto write using the textual representation rather than the tree, for examplethe lines of code (LoC).B.5. Future ScenariosThe open questions include of identification of further scenarios for appli-cation of HOTs. For example, the co-evolution of metamodels and trans-formations (cf., Figure B.5) could be one suitable scenario. The metamod-els evolve over time, similarly as any other artefacts. We can distinguishdifferent operation in evolution of metamodels, such as refactorings, con-struction or destruction of metamodel elements. These operations couldbe predefined as allowed as change operators. Based on the activation andconfiguration of such change scenarios could be metamodel and its trans-formations together updated to the required state.Figure B.5.: Co-evolution of metamodels and transformations.405B. Further HOT patternsFurther scenarios could include, model merging or composition. In[168], Wagelaar augments ATL as well as QVT-R with new syntacticalelements for a modularization mechanism he calls module superimposi-tion. He incorporates HOTs as a means for defining semantics by reducingthe widened syntax to already existing elements. [161] uses UML profilesto introduce one standardized metamodel for modelling the core featuresof Graph Transformations. Such core profile is extendable with new con-structs. While new syntax may be specified in additional profiles, semanticsare defined using HOTs based on the core metamodel of transformationsnormalizing added constructs back to core features. Such an approachrelieves tool builders from integrating new language features as well asexternal language concepts. These scenarios could be basis to introducefurther standardised HOT patterns.The optimisation of transformations could be of interest as well. HOTcould optimize a transformation by removing redundant code, replacingcode with semantically identical code but better performance, for exampleby reordering instructions or lowering abstraction (behavior-preserving).Heuristics may be used to create mark models from transformations, whichannotate code parts of input transformations with various informations. AHOT may analyse the performance of each rule for a rule-based transfor-mation, and indicate possible problems and bugs where they might occur.406C. Examples of detailed QVTtransformationsIn the following, we provide two examples of completion transformationsin the QVT graphical syntax. First, we describe relations of the MOMcompletion. Second, we illustrate the implementation of the Procedure Callconnector.C.1. Message Oriented Middleware CompletionwhenwhereCopyAssemblyConnectorC Esource : pcm,annotation : MessagingAnnotation target:pcmnot FindAnnotatedAssemblyConnector(annotatedAssemblyConnector, sourceAssemblyConnector);MarkAssemblyConnector(sourceAssemblyConnector, targetAssemblyConnector);<>targetAssemblyConnector : AssemblyConnector<>sourceAssemblyConnector : AssemblyConnector<>annotatedAssemblyConnector : AnnotatedAssemblyConnector(a) Relation to remove assembly connector.whereFindAnnotatedAssemblyConnectorC CAnnotation:MessagingAnnotationSource:pcmId = AnnotatedAssemblyConnectorIDAnnotatedAssemblyConnectorId = AnnotatedAssemblyConnectorIDAnnotatedAssemblyConnectorMarkAnnotatedAssemblyConnector(AnnotatedAssemblyConnector);(b) Relation to identify the pivot element.407C. Examples of detailed QVT transformationswhenwhereFindCopiedSenderAndReceiverElementsannotatedAssemblyConnector : AssemblyConnector<>receiverProvidedRole : ProvidedRolereceiverAssemblyContext : AssemblyContextsenderRequiredRole : RequiredRole<>copiedReceiverProvidedRole<>copiedSenderRequiredRole<>copiedSenderAssemblyContext<>copiedReceiverAssemblyContextiFoo : InterfacecopiedIFoo : InterfaceC Esource : pcmtarget : pcmMarkAnnotatedAssemblyConnector(annotatedAssemblyConnector);CopyProvidedRole(receiverProvidedRole, copiedReceiverProvidedRole);CopyRequiredRole(SenderRequiredRole, copiedSenderRequiredRole);CopyAssemblyContext(receiverAssemblyContext, copiedReceiverAssemblyContext);CopyAssemblyContext(senderAssemblyContext, copiedSenderAssemblyContext);CopyInterface(iFoo, copiedIFoo);MarkOriginalIFoo(IFoo);MarkIFoo(copiedIFoo);MarkReceiverProvidedRole(copiedReceiverProvidedRole);MarkReceiverAssemblyContext(copiedReceiverAssemblyContext);MarkSenderRequiredRole(copiedSenderRequiredRole);MarkSenderAssemblyContext(copiedSenderAssemblyContext);senderAssemblyContext : AssemblyContext(c) Relation to find Sender and Receiver interfaces.whenwhereid = knownRepositoryID<>originalMiddlewareRepository : Repositoryid = knownRepositoryID<>copiedMiddlewareRepository : RepositoryC Csource : pcmtarget : pcmconsumerPool : BasicComponententityName = ‚MessagingSystem’messagingSystem : BasicComponentsenderMiddleware : BasicComponentreceiverMiddleware : BasicComponententityName = ‚Provided_IMom_MessagingSystem’ messagingSystemProvidedIMom : ProvidedRolecopiedConsumerPool : BasicComponentcopiedMessagingSystem : BasicComponentcopiedMessagingSystemProvidedIMom : ProvidedRolecopiedSsenderMiddleware : BasicComponentcopiedReceiverMiddleware : BasicComponentMarkRepository(originalMiddlewareRepository, copiedMiddlewareRepository);MarkBasicComponent(senderMiddleware, copiedSenderMiddleware);...MarkMiddlewareComponents(copiedSenderMiddleware, copiedMessagingSystem,copiedReceiverMiddleware);MarkMiddlewareProvidedRoles(copiedSenderMiddlewareProvidingIMarshalling,copiedSenderMiddlewareProvidingISender, ...);FindCopiedMiddlewareComponents(d) Relation to identify Middleware components.408C.1. Message Oriented Middleware Completionwhenwhereid = knownRepositoryID<>originalMiddlewareRepository : Repositoryid = knownRepositoryID<>copiedMiddlewareRepository : RepositoryC Csource : pcmtarget : pcmiConsumerPool : InterfaceiSender : InterfacecopiedIConsumerPool :InterfacecopiedIReceiver : InterfacecopiedIMarshalling : InterfacecopiedISender : InterfaceMarkRepository(originalMiddlewareRepository, copiedMiddlewareRepository);MarkBasicComponent(senderMiddleware, copiedSenderMiddleware);...MarkMiddlewareComponents(copiedSenderMiddleware, copiedMessagingSystem,copiedReceiverMiddleware);MarkMiddlewareProvidedRoles(copiedSenderMiddlewareProvidingIMarshalling,copiedSenderMiddlewareProvidingISender, ...);FindCopiedMiddlewareInterfacesiReceiver : InterfaceiMarshalling : Interface(e) Relation to bind the Middleware interfaces.whenwherechannel = channelType;deliveryType = delivery_Type;durableSubscriber = durableSubscriberType;annotationElemen : AnnotatedAssemblyConnector<>originalIMom : InterfaceserviceName = 'processMessageTransfer' + channelType + durableSubscriberType + delivery_TypeoriginalIMomSignature : SignaturemiddlewareRepository : Repository<>copiedIMom : Interface<>copiedIMomSignature : SignatureC Eannotation : MessagingAnnotationsource : pcm target : pcmFindAnnotatedAssemblyConnector(annotationElement, annotatedAssemblyConnector);MarkInterface(originalIMom, copiedIMom);MarkSignature(originalIMomSignature, copiedIMomSignature);MarkMiddlewareInterfaces(copiedIMarshalling, copiedISender, copiedIMom, copiedIReceiver);MarkUsedIMomSignature(annotatedAssemblyConnector, copiedIMomSignature);FindUsedMiddlewareInterfaceSignatures(f) Relation to identify the Middleware signatures.409C. Examples of detailed QVT transformationswhenwhereC Esource : pcmtarget : pcmsenderAllocationContext : AllocationContext<>annotatedAssemblyConnector :AssemblyConnector<>senderResourceContainer : ResourceContainersenderAssemblyContext : AssemblyContextcopiedSenderAllocationContext :AllocationContext<>copiedSenderResourceContainer : ResourceContainercopiedSenderAssemblyContext : AssemblyContextMarkAssemblyContext(senderAssemblyContext, senderAssemblyContext);MarkResourceContainer(senderResourceContainer, senderResourceContainer);MarkSenderAssemblyContext(annotatedAssemblyConnector, copiedSenderAssemblyContext);MarkSenderResourceContainer(annotatedAssemblyConnector, senderResourceContainer);FindSenderAndReceiverRessourceContainer (g) Relation to identify resource containers for Adaptors.whenwhereC Esource : pcmtarget : pcmmessagingSystemAllocationContext : AllocationContext<>messagingSystemResourceContainer : ResourceContainermessagingSystemAssemblyContext : AssemblyContextMarkMiddlewareComponents(..., messagingSystem, ...);MarkAssemblyContext(messagingSystemAssemblyContext,copiedMessagingSystemAssemblyContext);MarkAllocationContext(messagingSystemAllocationContext, copiedMessagingSystemAllocationContext);MarkResourceContainer(messagingSystemResourceContainer, copiedMessagingSystemRessourceContainer);MarkBasicComponent(messagingSystem, copiedMessagingSystem);FindMiddlewareDeploymentElementsmessagingSystem : BasicComponentcopiedMessagingSystemAllocationContext : AllocationContext<>copiedMessagingSystemResourceContainer : ResourceContainercopiedMessagingSystemAssemblyContext : AssemblyContextcopiedMessagingSystem : BasicComponentMarkMiddlewareAssemblyContexts(copiedMessagingSystemAssemblyContext);MarkMiddlewareAllocationContexts(copiedMessagingSystemAllocationContext);MarkMiddlewareResourceContainer(copiedMessagingSystemRessourceContainer);(h) Relation to identify the Middleware deployment.410C.1. Message Oriented Middleware CompletionwhenentityName = ‚completionRepository___’ + annotatedAssemblyConnectorNametargetRepository : Repository<>entityName = annotatedAssemblyConnectorNameannotatedAssemblyConnector : AssemblyConnector<>C Esource : pcmtarget : pcm marshalling : BasicComponentsenderAdapter : BasicComponentdeMarshalling : BasicComponentreceiverAdapter : BasicComponentmomAdapter : BasicComponentiMarshalledFoo : InterfaceiConsumerPool : InterfaceMarkAnnotatedAssemblyConnector(annotatedAssemblyConnector);CreateAdapterComponents(annotatedAssemblyConnector, marshalling, senderAdapter, momAdapter, receiverAdapter, deMarshalling, consumerPool);CreateConsumerPoolInterface(annotatedAssemblyConnector, iConsumerPool);MarkIMarshalledFoo(annotatedAssemblyConnector, iMarshalledFoo);consumerPool : BasicComponentCreateCompletionRepository(i) Relation to create the Repository for components.whenwhereC Esource : pcm target : pcmannotatedAssemblyConnector : AssemblyConnector<>entityName = ‚IConsumerPool’consumerPoolInterface : Interface<>serviceName = ‚getConsumer’getConsumer : SignatureserviceName = ‚returnConsumer’returnConsumer : SignatureMarkAnnotatedAssemblyConnector(annotatedAssemblyConnector);MarkConsumerPoolSignatures(annotatedAssemblyConnector, getConsumer, returnConsumer);CreateConsumerPoolInterface(j) Relation to create the ConsumerPool interface.411C. Examples of detailed QVT transformationswhenwhereC Esource : pcmtarget : pcmannotatedAssemblyConnector :AssemblyConnector<>entityName = IFooEntityNameoriginalIFoo : Interface<>originalIFooSignature : SignaturecopiedIFoo : Interface<>entityName = ‚Marshalled’ + IFooEntityNameiMarshalledFoo : Interface<>iMarshalledFooSignature : SignatureMarkAnnotatedAssemblyConnector(annotatedAssemblyConnector);MarkOriginalIFoo(annotatedAssemblyConnector, OriginalIFoo);MarkIFoo(annotatedAssemblyConnector, copiedIFoo);MarkIMarshalledFoo(annotatedAssemblyConnector, iMarshalledFoo);CopyIFooSignature(annotatedAssemblyConnector, OriginalIFooSignature, iMarshalledFooSignature);CreateIMarshalledFoo(k) Relation to create the original service interface.whereannotatedAssemblyConnector :AssemblyConnector<>serviceName = signatureNameoriginalIFooSignature : Signature<>originalIFooSignatureParameter : ParameterserviceName = signatureNameoriginalIFooSignature : Signature<>originalIFooSignatureParameter : ParameterCopyIFooSignatureParameter(annotatedAssemblyConnector, originalIFooSignatureParameter, IMarshalledFooSignatureParameter);CompleteIMarshalledFooSignature(annotatedAssemblyConnector, IMarshalledFooSignature);C Esource : pcmtarget : pcmCopyIFooSignature(l) Relation to complete the original service signature.412C.1. Message Oriented Middleware CompletionwhenwhereannotatedAssemblyConnector : AssemblyConnector<>entityName = ‚marshalling 'marshalling : BasicComponent<>senderAdapter : BasicComponent<>deMarshalling : BasicComponent<>receiverAdapter : BasicComponent<>momAdapter : BasicComponent<>consumerPool : BasicComponent<>entityName = ‚Provided_IFoo_Marshalling’marshallingProvidedIFoo : ProvidedRoleentityName = ‚Required_IMarshalledFoo_Marshalling’marshallingRequiredIMarshalledFoo : RequiredRoleentityName = ‚Required_IMarshalling_Marshalling’marshallingRequiredIMarshalling : RequireddRoleC Esource : pcm target : pcmiFoo : Interface iMarshalledFoo : Interface iMarshalling : InterfaceCreateAdapterComponentsMarkAnnotatedAssemblyConnector(annotatedAssemblyConnector);MarkIFoo(annotatedAssemblyConnector, iFoo);MarkIMarshalledFoo(annotatedAssemblyConnector, iMarshalledFoo);MarkMiddlewareInterfaces(iMarshalling, iSender, iMom, iReceiver);CreateConsumerPoolInterface(annotatedAssemblyConnector, iConsumerPool);MarkAdapterProvidedRoles(annotatedAssemblyConnector, marshallingProvidedIFoo, senderAdapterProvidedIMarshalledFoo, …);MarkAdapterRequiredRoles(annotatedAssemblyConnector, marshallingRequiredIMarshalling, marshallingRequiredIMarshalledFoo, …);(m) Relation to create the Adaptors.whenid = annotatedAssemblyConnectorIDannotatedAssemblyConnector : AssemblyConnector<>id = annotatedAssemblyConnectorID,competingConsumers = ccNumberassemblyConnector : AssemblyConnector<>consumerPool : BasicComponent<>pool : PassiveRessourcespecification = ccNumbercapacity : PCMRandomVatiableC Esource : pcmtarget : pcmannotation : MessagingAnnotationMarkAnnotatedAssemblyConnector(annotatedAssemblyConnector);MarkConsumerPool ( annotatedAssemblyConnector, consumerPool);CompleteConsumerPool(n) Relation to create passive resources for the ConsumerPool.413C. Examples of detailed QVT transformationswhenannotatedAssemblyConnector : AssemblyConnector<>sourceSystem : System<>C Esource : pcmtarget : pcmtargetSystem : System<>marshallingAssemblyContext : AssemblyContextmarshallingToSenderAdapter : AssemblyConnector... ...MarkSystem(sourceSystem, targetSystem);MarkAnnotatedAssemblyConnector(annotatedAssemblyConnector);CreateAdapterAssemblyContexts(annotatedAssemblyConnector,marshallingAssemblyContext,...);...CreateAssemblyConnectors(annotatedAssemblyConnector, sourceSystem, marshalligToSenderAdapter, …);CompleteSystem(o) Relation to create system elements.Figure C.1.: Message Oriented Middleware Completion [35].C.2. Pipe & Filter Connector CompletionFindCopiedConnectorRepositoryInterfaces<>annotatedAssemblyConnector: AssemblyConnectorCsource : pcm target : pcmEwhenMark_repository_Repository (getConnectorRepository('ConnectorRepository'),copiedConnectorRepository);Mark_repository_Interface(getConnectorInterface('unifiedCom'), copiedUnifiedCom);Mark_repository_Interface(getConnectorInterface('workerManagement'), copiedWorker...);<>copiedConnectorRepository: RepositorycopiedUnifiedCom: InterfacecopiedWorkerManagement: InterfaceentityName = ´ConnectorRepository`MarkConnectorInterfaces(copiedUnifiedCom, copiedWorkerManagement);where(a) Relation to mark all interfaces in the ConnectorRepository.414C.2. Pipe & Filter Connector CompletionunifiedComObject call(Object Data)void push(Object Data)workerManagementvoid rel()void acq()FilterSEFF SEFF SEFF SEFF PassiveResourceCompartmentWorkerPool ComponentParameterCompartmentPipeSEFF SEFF PassiveResourceCompartmentCapacity ComponentParameterCompartmentSinkAdapterSEFF SEFF SEFF SEFF PassiveResourceCompartmentComponentParameterCompartmentDistributorSEFF SEFF SEFF SEFF PassiveResourceCompartmentWorkerPool ComponentParameterCompartmentTerminatorSEFF SEFF PassiveResourceCompartmentComponentParameterCompartmentInterceptorSEFF SEFF SEFF SEFF PassiveResourceCompartmentWorkerPool ComponentParameterCompartmentSourceAdapterSEFF SEFF SEFF SEFF PassiveResourceCompartmentComponentParameterCompartmentSyncherSEFF SEFF PassiveResourceCompartmentCapacity CS ComponentParameterCompartmentForwarderSEFF SEFF PassiveResourceCompartmentComponentParameterCompartmentBlackBoardStorageSEFF SEFF SEFF SEFF PassiveResourceCompartmentWorkerPool ComponentParameterCompartment<><><><><><><><><><><><><><><><><><><><><><><><><><><><><>(b) The ConnectorRepository.415C. Examples of detailed QVT transformationsFindCopiedConnectorRepositoryComponents<>annotatedAssemblyConnector: AssemblyConnectorCsource : pcm target : pcmEwhenMark_repository_Repository (getConnectorRepository('ConnectorRepository'),copiedConnectorRepository);Mark_repository_BasicComponent(getConnectorComponent('filter'), copiedFilter);Mark_repository_BasicComponent(getConnectorComponent('pipe'), copiedPipe);Mark_repository_ProvidedRole (getConnectorProvidedRole('filterProvidingWorker'), copiedFilterProvidingWorker);Mark_repository_ProvidedRole (getConnectorProvidedRole('filterProvidingFilterIn'), copiedFilterProvidingFilterIn);Mark_repository_RequiredRole (getConnectorRequiredRole('filterRequiringFilterOut'),copiedFilterRequiringFilterOut);......<>copiedConnectorRepository: RepositorycopiedFilter: BasicComponentcopiedFilterProvidingFilterIn: ProvidedRolecopiedFilterRequiringFilterOut: RequiredRolecopiedFilterProvidingWorker: ProvidedRolecopiedPipe: BasicComponentcopiedPipeProvidingPipeIn: ProvidedRolecopiedPipeRequiringWorkerSucc: RequiredRolecopiedPipeRequiringPipeOut: RequiredRolecopiedPipeRequiringWorkerPred: RequiredRoleMarkMessageConnectorComponents(copiedFilter, copiedPipe, ...);MarkMessageConnectorProvidedRoles (copiedFilterProvidingWorker, copiedFilterProvidingFilterIn, copiedPipeProvidingPipeIn, ...);MarkMessageConnectorRequiredRoles(copiedFilterRequiringFilterOut, copiedPipeRequiringPipeOut, copiedPipeRequiringWorkerPred, copiedPipeRequiringWorkerSucc, ...);whereentityName = ´ConnectorRepository`(c) Excerpt of the relation to mark all components in theConnectorRepository.<>annotatedAssemblyConnector: AssemblyConnectorCsource : pcm target : pcmE...<>copiedSystem: SystemsourceAssemblyContext: AssemblyContextpipe01AssemblyContext: AssemblyContextsinkAssemblyContext: AssemblyContext<>system : SystemwhenMark_system_System(system, copiedSystem);MarkMessageConnectorAssemblyContexts(annotatedAssemblyConnector, sourceAssemblyContext, pipe01AssemblyContext, sinkAssemblyContext, ...);PutAssemblyContextsIntoSystem(d) Relation to place all assemblyContexts inside the system el-ement.416C.2. Pipe & Filter Connector CompletionCreateConnectorAssemblyConnectors<>annotatedAssemblyConnector: AssemblyConnectorCsource : pcm target : pcmE...whenMarkSenderRequiredRole(annotatedAssemblyConnector, senderRequiredRole);MarkReceiverProvidedRole(annotatedAssemblyConnector, receiverProvidedRole);MarkSenderAssemblyContext(annotatedAssemblyConnector, senderAssemblyContext);MarkReceiverAssemblyContext(annotatedAssemblyConnector, receiverAssemblyContext);MarkMessageConnectorAssemblyContexts(annotatedAssemblyConnector, sourceAssemblyContext, pipe01AssemblyContext, ...);MarkMessageConnectorProvidedRoles(pipeProvidingPipeIn, sourceAdapterProvidingWorkerIn, sourceAdapterProvidingSourceIn, ...);MarkMessageConnectorRequiredRoles(pipeRequiringPipeOut, pipeRequiringWorkerPred, pipeRequiringWorkerSucc, sourceAdapterRequiringSourceOut, ...);senderAssemblyContext: AssemblyContext<>senderToSource: AssemblyConnectorentityName = 'AC__ -> 'sourceAssemblyContext: AssemblyContextsenderRequiredRole: RequiredRolesourceAdapterProvidingSourceIn: ProvidedRolesourceAssemblyContext: AssemblyContext<>sourceToPipe01: AssemblyConnectorentityName = 'AC__ -> 'pipe01AssemblyContext: AssemblyContextsourceAdapterRequiringSourceOut: RequiredRolepipeProvidingPipeIn: ProvidedRoleMarkMessageConnectorAssemblyConnectors(annotatedAssemblyConnector, senderToSource, sourceToPipe01, ...);where(e) Relation to create all assemblyConnectors for theMessagingConnector.<>annotatedAssemblyConnector: AssemblyConnectorCsource : pcm target : pcmE...<>copiedAllocation: AllocationsourceAllocationContext: AllocationContextpipe01AllocationContext: AllocationContextsinkAllocationContext: AllocationContext<>allocation : AllocationwhenMark_allocation_Allocation(allocation, copiedAllocation);MarkMessageConnectorAllocationContexts(annotatedAssemblyConnector, sourceAllocationContext, pipe01AllocationContext, sinkAllocationContext, ...);PutAllocationContextsIntoAllocation(f) Relation to place all allocationContexts inside the alloca-tion element.417C. Examples of detailed QVT transformationsCreateConnectorAssemblyContexts<>annotatedAssemblyConnector: AssemblyConnectorCsource : pcm target : pcmEsourceAdapterComponent: BasicComponent<>sourceAssemblyContext: AssemblyContextentityName = 'AssemblyContext__'filterComponent: BasicComponent<>encryptorAssemblyContext: AssemblyContextentityName = 'AssemblyContext__'pipeComponent: BasicComponent<>pipe01AssemblyContext: AssemblyContextentityName = 'AssemblyContext__'...whenMarkAnnotatedAssemblyConnector(annotatedAssemblyConnector);MarkMessageConnectorComponents (sourceAdapterComponent, filterComponent, pipeCompoment, ...);MarkMessageConnectorAssemblyContexts(annotatedAssemblyConnector,sourceAssemblyContext, encryptorAssemblyContext, pipe01AssemblyContext, ...);where(g) Relation to create all assemblyContexts for theMessagingConnector.AdoptSourceSinkInterfaces<>annotatedAssemblyConnector: AssemblyConnectorCsource : pcm target : pcmEwhenMarkSenderInterface(annotatedAssemblyConnector, copiedSenderInterface); Mark_repository_ProvidedRole(getConnectorProvidedRole('sourceAdapterProvidingSourceIn') , copiedSourceAdapterProvidingSourceIn);Mark_repository_RequiredRole(getConnectorRequiredRole('sinkAdapterRequiringSinkOut') , copiedSinkAdapterRequiringSinkOut);<>copiedSourceAdapterProvidingSourceIn: ProvidedRolecopiedSenderInterface: Interface<>copiedSinkAdapterRequiringSinkOut: RequiredRolecopiedSenderInterface: Interface(h) Adoption of the interfaces of the Source- & SinkAdapter compo-nents.418C.2. Pipe & Filter Connector CompletionCreateConnectorAllocationContexts<>annotatedAssemblyConnector: AssemblyConnectorCsource : pcm target : pcmE...whenMarkSenderResourceContainer(annotatedAssemblyConnector, senderResourceContainer);MarkReceiverResourceContainer(annotatedAssemblyConnector, receiverResourceContainer);MarkMessageConnectorAssemblyContexts(annotatedAssemblyConnector,sourceAssemblyContext, pipe01AssemblyContext, sinkAssemblyContext...);MarkMessageConnectorAllocationContexts(annotatedAssemblyConnector, sourceAllocationContext, pipe01AllocationContext, sinkAllocationContext, ...);wheresourceAssemblyContext: AssemblyContext<>sourceAllocationContext: AllocationContextentityName = 'AllocationContext__'senderResourceContainer: ResourceContainerpipe01AssemblyContext: AssemblyContext<>pipe01AllocationContext: AllocationContextentityName = 'AllocationContext__'senderResourceContainer: ResourceContainersinkAssemblyContext: AssemblyContext<>sinkAllocationContext: AllocationContextentityName = 'AllocationContext__'receiverResourceContainer: ResourceContainer(i) Relation to create all allocationContexts for theMessagingConnector.Figure C.2.: Pipe & Filter Connector Completion [36].419List of Figures1.1. Chapter structure in this thesis. . . . . . . . . . . . . . . . 142.1. Research areas involved in this thesis. . . . . . . . . . . . 162.2. The Ecore metamodel. . . . . . . . . . . . . . . . . . . . 212.3. Graphical representation of a QVT relation. . . . . . . . . 272.4. Example of a feature diagram. . . . . . . . . . . . . . . . 292.5. MDA models and transformations. . . . . . . . . . . . . . 312.6. Performance-influencing factors. . . . . . . . . . . . . . . 362.7. Roles in CBSE development process [19]. . . . . . . . . . 382.8. Illustration of a PCM model. . . . . . . . . . . . . . . . . 402.9. Transformation integrating performance completions. . . . 442.10. Hierarchy of a GQM-Model [7]. . . . . . . . . . . . . . . 463.1. Transformations in the Model-Driven SoftwareDevelopment (MDSD)[46]. . . . . . . . . . . . . . . . . . 523.2. Software development using MDSD. . . . . . . . . . . . 533.3. Model Completion concept. . . . . . . . . . . . . . . . . 563.4. Model-driven Software Performance Engineering (MDSPE). 613.5. MDSPE with completions. . . . . . . . . . . . . . . . . . 633.6. Concept overview of performance completions. . . . . . . 643.7. Completion-based development process overview. . . . . 673.8. Tasks of the completion developer. . . . . . . . . . . . . . 743.9. A sample Thread Pool of capacity = 3 with waiting tasksand completed tasks. . . . . . . . . . . . . . . . . . . . . 763.10. Example of experiment results [62]. . . . . . . . . . . . . 79421List of Figures3.11. The configuration model of Thread Pool design pattern(used for the running example). . . . . . . . . . . . . . . 823.12. The structural completion skeleton of Thread Pool designpattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.13. Example of Thread Pool model validation [62]. . . . . . . 863.14. Example of feature effects implemented as fragments oftransformations. . . . . . . . . . . . . . . . . . . . . . . 883.15. Tasks of the completion user. . . . . . . . . . . . . . . . . 893.16. Thread Pool feature configuration. . . . . . . . . . . . . . 903.17. Pointers to the detailed description of particulardevelopment steps. . . . . . . . . . . . . . . . . . . . . . 914.1. Introduction of new domain-specific aspects to themetamodel by a completion transformation. . . . . . . . . 954.2. SPL for model transformations generating completiontransformations. . . . . . . . . . . . . . . . . . . . . . . 1044.3. Variability implementation with configuration. . . . . . . 1074.4. Patterns of higher-order transformations (according to[158]). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.5. Routine HOT pattern. . . . . . . . . . . . . . . . . . . . . 1264.6. Generating a copy relation (based on [68]). . . . . . . . . 1304.7. Generating a marker relation (based on [68]). . . . . . . . 1324.8. Generating an abstraction relation. . . . . . . . . . . . . . 1344.9. Overview of Model Completion concept. . . . . . . . . . 1374.10. Composite HOT pattern with non-equal source and targetmetamodel. . . . . . . . . . . . . . . . . . . . . . . . . . 1394.11. Building elements of completion transformation usingRoutine and Composite pattern. . . . . . . . . . . . . . . 1404.12. Extensions to the Feature Model Metamodel. . . . . . . . 1424.13. Simplified transformation fragments for the runningexample. . . . . . . . . . . . . . . . . . . . . . . . . . . 143422List of Figures4.14. Template HOT pattern. . . . . . . . . . . . . . . . . . . . 1604.15. Building elements of completion transformation usingRoutine, Composite and Template HOT pattern. . . . . . . 1604.16. Introduction of simple templates for component-basedarchitectures based on the running example. . . . . . . . . 1614.17. The metamodel for the transformation templates. . . . . . 1654.18. Chain of HOT patterns: HOT1 - Routine, HOT2-Composite, HOT3-Template . . . . . . . . . . . . . . . . 1754.19. HOT Chain to support Model Completions in MDSPEApplication Scenario . . . . . . . . . . . . . . . . . . . . 1775.1. A role hierarchy in the PCM metamodel. . . . . . . . . . 1925.2. Replication Pattern. . . . . . . . . . . . . . . . . . . . . . 2085.3. Random Load Balancing: Graphical comparison of theresponse time averages for three differently demandingusage scenarios. . . . . . . . . . . . . . . . . . . . . . . . 2115.4. Feature diagram for the replication design pattern. . . . . 2125.5. Replication Completion Skeleton. . . . . . . . . . . . . . 2135.6. Time series of a transaction with 1000 messages pertransaction set. . . . . . . . . . . . . . . . . . . . . . . . 2175.7. MOM Completion Skeleton for transactional delivery. . . 2195.8. Example stateful SEFF. . . . . . . . . . . . . . . . . . . . 2205.9. Connector Middleware Completion [76]. . . . . . . . . . 2225.10. Mapping the connectors on the abstractions in theperformance model. . . . . . . . . . . . . . . . . . . . . 2245.11. Connector Layout. . . . . . . . . . . . . . . . . . . . . . 2255.12. Procedure Call connector architecture [30]. . . . . . . . . 2265.13. Procedure Call Feature Diagram. . . . . . . . . . . . . . . 2285.14. Filter Subtree. . . . . . . . . . . . . . . . . . . . . . . . . 2295.15. Coupled Activity Subtree. . . . . . . . . . . . . . . . . . 2305.16. Replication Subtree. . . . . . . . . . . . . . . . . . . . . 231423List of Figures5.17. Distributor Worker Management. . . . . . . . . . . . . . 2325.18. Procedure Call Connector Client Unit. . . . . . . . . . . . 2325.19. Procedure Call Connector Server Unit. . . . . . . . . . . 2335.20. The generic configuration model of thread managementstrategies. . . . . . . . . . . . . . . . . . . . . . . . . . . 2355.21. The structural completion skeleton of Thread Management. 2366.1. Workflow for omputation of metrics. . . . . . . . . . . . . 2567.1. Feature Model for the MOM Completion [76]. . . . . . . 2717.2. The influence of message size on the delivery time [93, 76]. 2727.3. Time series of a transaction with 1000 messages pertransaction set. . . . . . . . . . . . . . . . . . . . . . . . 2737.4. Components of the MOM Completion [based on [77]]. . . 2737.5. Starting a new transaction. . . . . . . . . . . . . . . . . . 2757.6. MOM Adapter: Message Transfer. . . . . . . . . . . . . . 2767.7. MOM Adapter: Commit Transaction. . . . . . . . . . . . 2777.8. Predictions and measurements of the three designalternatives [93, 77]. . . . . . . . . . . . . . . . . . . . . 2787.9. Predicted delivery times for messages. . . . . . . . . . . . 2797.10. Periodical CPU utilisation in stateful model. . . . . . . . . 2807.11. Message transfer time. . . . . . . . . . . . . . . . . . . . 2817.12. The experiment setup. . . . . . . . . . . . . . . . . . . . 2837.13. Completed Thread Pool Model in PCM. . . . . . . . . . . 2867.14. Thread Pool completion: Calibration Data. . . . . . . . . 2887.15. Thread Pool completion: Comparison of prediction(BLUE) and measurements (RED). . . . . . . . . . . . . 2897.16. Observation of the queue overflow. . . . . . . . . . . . . . 2917.17. Relevant part of the SCM architecture for BRS withannotations. . . . . . . . . . . . . . . . . . . . . . . . . . 2937.18. Behaviour of the Business Reporting includingannotations. . . . . . . . . . . . . . . . . . . . . . . . . . 294424List of Figures7.19. Distribution of the turn-around time and data collection time.2957.20. Approach for executing a transformation. . . . . . . . . . 2987.21. Measurement Results: Overview. . . . . . . . . . . . . . 2997.22. Measurement Results: Compression. . . . . . . . . . . . 2997.23. Measurement vs. Prediction Results. . . . . . . . . . . . . 3017.24. Completion Alternatives. . . . . . . . . . . . . . . . . . . 3027.25. Resulting Architecture. . . . . . . . . . . . . . . . . . . . 3047.26. Distribution of the response time for refined connector(based on all valid completion chains). . . . . . . . . . . . 3057.27. Comparison of the overall response time distribution forthe [C,E,M](RED) and [E,C,M](BLUE) alternatives. . . . 3067.28. Results: Transformation Complexity. . . . . . . . . . . . 3117.29. Results: Relations Dependencies. . . . . . . . . . . . . . 3127.30. Dependencies to other features for the Feature 3. . . . . 3168.1. Overview of the concept of parametric performancecompletions used in [76] . . . . . . . . . . . . . . . . . . 3358.2. Comparison of related approaches from MDSPE context. . 343A.1. Performance-influencing factors. . . . . . . . . . . . . . . 362A.2. A SEFF of open(). . . . . . . . . . . . . . . . . . . . . . 383A.3. A SEFF of processData(). . . . . . . . . . . . . . . . . 386B.1. Shared Configuration pattern. . . . . . . . . . . . . . . . 398B.2. Retainment policies. . . . . . . . . . . . . . . . . . . . . 400B.3. Model/view synchronization. . . . . . . . . . . . . . . . . 403B.4. Transformation metrics. . . . . . . . . . . . . . . . . . . 404B.5. Co-evolution of metamodels and transformations. . . . . . 405C.1. Message Oriented Middleware Completion [35]. . . . . . 414C.2. Pipe & Filter Connector Completion [36]. . . . . . . . . . 419425List of Tables3.1. Example of the evaluation of prediction accuracy [62]. . . 864.1. CBSE Transformation Templates. . . . . . . . . . . . . . 1645.1. Roles and Responsibilities Separation: Mapping designpatterns to development roles. . . . . . . . . . . . . . . . . 2066.1. Automated metrics. . . . . . . . . . . . . . . . . . . . . . 2517.1. Measurement/Prediction Comparison. . . . . . . . . . . . 2817.2. Thread Pool experiment configuration. . . . . . . . . . . . 2877.3. Thread Pool experiment configuration for the Queue Length. 2907.4. Quality evaluation for all valid completion chains. . . . . . 3047.5. Automatically calculated metrics. . . . . . . . . . . . . . . 3117.6. Comparison of completion versus mark transformation forone feature combination. . . . . . . . . . . . . . . . . . . 3158.1. Comparison of related approaches from MDSD context. . . 341A.1. Identified state categories. . . . . . . . . . . . . . . . . . . 370A.2. Component Performance Models Comparison. . . . . . . . 375427Bibliography[1] “Java System Message Queue -Version 4.3,” http://java.net/downloads/mq/-Open MQ 4.3 Related/MQ4.3_RelNotes_preFCS.pdf, last retrieved: July2011.[2] A. Agrawal, A. Vizhanyo, Z. Kalmar, F. Shi, A. Narayanan, and G. Karsai,“Great: Reusable idioms and patterns in graph transformation languages,” inGraBaTs. Elsevier, 2004.[3] K. Anastasakis, B. Bordbar, and J. Küster, “Analysis of model transforma-tions via alloy,” in Proceedings of the 4th MoDeVVa workshop Model-DrivenEngineering, Verification and Validation. Citeseer, 2007, pp. 47–56.[4] R. Bagrodia and C. Shen, “Midas: Integrated design and simulation of dis-tributed systems,” IEEE Transactions on Software Engineering, vol. 17, pp.1042 – 1058, 1991.[5] A. Balogh and D. Varró, “Advanced model transformation languageconstructs in the viatra2 framework,” in ACM symposium on Appliedcomputing, ser. SAC ’06. New York, NY, USA: ACM, 2006, pp. 1280–1287. [Online]. Available: http://doi.acm.org/10.1145/1141277.1141575[6] S. Balsamo, A. Di Marco, P. Inverardi, and M. Simeoni, “Model-Based Per-formance Prediction in Software Development: A Survey,” IEEE Transac-tions on Software Engineering, vol. 30, no. 5, pp. 295–310, May 2004.[7] V. R. Basili, G. Caldiera, and H. D. Rombach, “The Goal Question MetricApproach,” in Encyclopedia of Software Engineering - 2 Volume Set, J. J.Marciniak, Ed. John Wiley & Sons, 1994, pp. 528–532.[8] D. Batory, “Feature-oriented programming and the ahead tool suite,” in ICSE’04: Proceedings of the 26th International Conference on Software Engi-neering. Washington, USA: IEEE Computer Society, 2004.429Bibliography[9] ——, “Multilevel models in model-driven engineering, product lines, andmetaprogramming,” IBM Systems Journal, vol. 45, pp. 527–539, 2006.[10] S. Becker, “Using Generated Design Patterns to Support QoS Predictionof Software Component Adaptation,” in Proceedings of the SecondInternational Workshop on Coordination and Adaptation Techniques forSoftware Entities (WCAT 05), C. Canal, J. M. Murillo, and P. Poizat,Eds., 2005. [Online]. Available: http://sdqweb.ipd.uka.de/publications/pdfs/becker2005a.pdf[11] ——, “Coupled model transformations,” in Proceedings of the 7th interna-tional workshop on Software and performance. ACM, 2008, pp. 103–114.[12] ——, “Coupled Model Transformations for QoS Enabled Component-BasedSoftware Design,” Ph.D. dissertation, University of Oldenburg, Germany,Mar. 2008.[13] ——, Dependability Metrics, ser. Lecture Notes in Computer Science.Springer-Verlag Berlin Heidelberg, 2008, vol. 4909, ch. Quality ofService Modeling Language, pp. 43–47. [Online]. Available: http://www.springerlink.com/content/754u689927655237/fulltext.pdf[14] S. Becker, A. Brogi, I. Gorton, S. Overhage, A. Romanovsky, and M. Tivoli,“Towards an Engineering Approach to Component Adaptation,” in Architect-ing Systems with Trustworthy Components, ser. Lecture Notes in ComputerScience. Springer, 2006.[15] S. Becker, T. Dencker, and J. Happe, “Model-Driven Generation ofPerformance Prototypes,” in Performance Evaluation: Metrics, Models andBenchmarks (SIPEW 2008), vol. 5119, 2008, pp. 79–98. [Online]. Available:http://www.springerlink.com/content/62t1277642tt8676/fulltext.pdf[16] S. Becker, J. Happe, and H. Koziolek, “Putting Components into Context:Supporting QoS-Predictions with an explicit Context Model,” in Proc. ofWorkshop on Component Oriented Programming (WCOP), 2006.[17] S. Becker, M. Hauck, M. Trifu, K. Krogmann, and J. Kofroň, “Reverse En-gineering Component Models for Quality Predictions,” in European Confer-ence on Software Maintenance and Reengineering, European Projects Track,2010.430Bibliography[18] S. Becker, H. Koziolek, and R. Reussner, “The palladio component modelfor model-driven performance prediction,” Journal of Systems and Software,vol. 82, no. 1, pp. 3 – 22, 2009, special Issue: Software Performance - Mod-eling and Analysis.[19] S. Becker, H. Koziolek, and R. H. Reussner, “Model-based PerformancePrediction with the Palladio Component Model,” in WOSP ’07: Proceedingsof the 6th International Workshop on Software and performance. NewYork, NY, USA: ACM, February 5–8 2007, pp. 54–65. [Online]. Available:http://sdqweb.ipd.uka.de/publications/pdfs/becker2007b.pdf[20] M. Bernardo and J. Hillston, Eds., Formal Methods for Performance Evalu-ation (7th International School on Formal Methods for the Design of Com-puter, Communication, and Software Systems, SFM2007), May 2007, vol.4486.[21] A. Bertolino and R. Mirandola, “Modeling and analysis of non-functionalproperties in component-based systems,” in Electronic Notes in TheoreticalComputer Science. Elsevier, 2003.[22] ——, “Cb-spe tool: Putting component-based performance engineering intopractice,” in Proc. 7th International Symposium on Component-Based Soft-ware Engineering (CBSE 2004. Springer, 2004, pp. 233–248.[23] J. Bézivin, “On the unification power of models,” Software and Systems Mod-eling, vol. 4, no. 2, pp. 171–188, 2005.[24] J. Bézivin, F. Büttner, M. Gogolla, F. Jouault, I. Kurtev, and A. Lindow,“Model transformations? transformation models!” Model Driven Engineer-ing Languages and Systems, vol. Springer, pp. 440–453, 2006.[25] M. Biehl, “Literature study on model transformations,” Web site: [Last ac-cessed Feb. 1, 2011] http://www.md.kth.se/~biehl/files/papers/mt.pdf, 2010.[26] B. W. Boehm, J. R. Brown, and M. Lipow, “Quantitative evaluation of soft-ware quality,” in ICSE ’76: Proceedings of the 2nd international conferenceon Software engineering. Los Alamitos, CA, USA: IEEE Computer SocietyPress, 1976, pp. 592–605.431Bibliography[27] R. Böhme and R. Reussner, Dependability Metrics, 2008, vol. 4909, ch.Validation of Predictions with Measurements, pp. 7–13. [Online]. Available:http://www.springerlink.com/content/662rn13014r46269/fulltext.pdf[28] T. Bures, “Generating connectors for homogeneous and heterogeneous de-ployment„” Ph.D. dissertation, Charles University in Prague, 2006.[29] T. Bures, P. Hnetynka, and F. Plasil, “Sofa 2.0: Balancing advanced featuresin a hierarchical component model,” in Proc. of Conference on Software En-gineering Research, Management and Applications (SERA). IEEE, 2006.[30] T. Bures, M. Malohlava, and P. Hnetynka, “Using DSL for Automatic Gener-ation of Software Connectors,” in In Proceedings of ICCBSS 2008, Madrid,Spain, Feb. 2008, pp. 138–147.[31] J. Cheesman and J. Daniels, UML Components: A Simple Process for Speci-fying Component-based Software, 2000.[32] S. Chen, I. Gorton, A. Liu, and Y. Liu, “Performance prediction of cotscomponent-based enterprise applications,” in Electronic proceedings of 5thICSE Workshop on Component-based Software Engineering Benchmarks,ser. CBSE5, 2002.[33] S. Chen, Y. Liu, I. Gorton, and A. Liu, “Performance Prediction ofComponent-based Applications,” Journal of Systems and Software, vol. 74,pp. 35–43, 2005.[34] L. K. Christian Harnisch, “Modelling parallel, component-based softwarearchitectures with design patterns - replication pattern,” Study Thesis, Uni-versity of Karlsruhe, 2010.[35] L. K. Christian Heupel, “Automatisierte integration nachrichtenbasierterkommunikation in das pcm,” Study Thesis, University of Karlsruhe, 2010.[36] L. K. ChristianVogel, “Automated integration of connector abstractions inpcm,” Study Thesis, University of Karlsruhe, 2010.[37] P. Clements and L. Northrop, Software product lines. Addison-Wesley,2001.[38] P. Coad and E. Yourdon, Object oriented design. Prentice-Hall, 1991.432Bibliography[39] K. D. Cooper, D. Subramanian, and L. Torczon, “Adaptive optimizing com-pilers for the 21st century,” J. Supercomput., vol. 23, no. 1, pp. 7–22, 2002.[40] V. Cortellessa, “How far are we from the definition of a common softwareperformance ontology?” in WOSP ’05: Proceedings of the 5th InternationalWorkshop on Software and Performance. New York, NY, USA: ACM Press,2005, pp. 195–204.[41] V. Cortellessa, A. Di Marco, and P. Inverardi, “Integrating Performance andReliability Analysis in a Non-Functional MDA Framework,” in FundamentalApproaches to Software Engineering, 10th International Conference, FASE2007, Held as Part of the Joint European Conferences, on Theory and Prac-tice of Software, ETAPS 2007, Braga, Portugal, March 24 - April 1, 2007,Proceedings, ser. Lecture Notes in Computer Science, M. B. Dwyer andA. Lopes, Eds., vol. 4422. Springer, 2007, pp. 57–71.[42] V. Cortellessa, P. Pierini, and D. Rossi, “Integrating Software Models andPlatform Models for Performance Analysis,” IEEE Transactions on SoftwareEngineering, vol. 33, no. 6, pp. 385–401, June 2007.[43] D. Cruz, R. Henriques, and J. Varanda, “Constructing program animationsusing a pattern based approach,” Computer Science and Information Systems,vol. 4, no. 2, pp. 97–114, 2007.[44] K. Czarnecki and M. Antkiewicz, “Mapping features to models: A templateapproach based on superimposed variants,” in GPCE’05: Proceedings of theFourth International Conference on Generative Programming and Compo-nent Engineering. Springer-Verlag, 2005.[45] K. Czarnecki and S. Helsen, “Classification of model transformation ap-proaches,” in Proceedings of the 2nd OOPSLA Workshop on GenerativeTechniques in the Context of the Model Driven Architecture, 2003, pp. 1–17.[46] K. Czarnecki and U. W. Eisenecker, Generative Programming – Methods,Tools, and Applications. Addison-Wesley Professional, 2000.[47] M. D. Del Fabro and P. Valduriez, “Towards the efficient development ofmodel transformations using model weaving and matching transformations,”Software and Systems Modeling, vol. 8, pp. 305–324, 2009.433Bibliography[48] M. Del Fabro and P. Valduriez, “Semi-automatic model integration usingmatching transformations and weaving models,” in Proceedings of the 2007ACM symposium on Applied computing. ACM, 2007, pp. 963–970.[49] A. Di Marco and P. Inveradi, “Compositional Generation of Software Archi-tecture Performance QN Models,” in Proceedings of WICSA 2004, 2004, pp.37–46.[50] A. Diaconescu and J. Murphy, “Automating the performance managementof component-based enterprise systems through the use of redundancy,” inProc. of Conference on Automated software engineering (ASE). IEEE, 2005.[51] B. P. Douglass, Real-Time Design Patterns, ser. Object Technology Series.Addison-Wesley Professional, 2002.[52] F. B. e Abreu, “Using ocl to formalize object oriented metrics definitions,”FCT/UNL and INSC, Tech. Rep., 2001.[53] Eclipse Foundation, “Graphical Modeling Project Homepage,” Web site:[Last accessed Feb. 11, 2011] http://www.eclipse.org/modeling/gmp/.[54] A. Eden, A. Yehudai, and J. Gil, “Precise specification and automatic appli-cation of design patterns,” Automated Software Engineering, InternationalConference on, vol. 0, p. 143, 1997.[55] I. El-Oudghiri, “Evaluierung der leistungsfähigkeit von lastverteilern für javaee cluster,” Study Thesis, University of Karlsruhe, 2008.[56] N. E. Fenton, Software Metrics: A Rigorous Approach. London, UK, UK:Chapman & Hall, Ltd., 1991.[57] J. Foster, M. Greenwald, J. Moore, B. Pierce, and A. Schmitt, “Combinatorsfor bi-directional tree transformations: a linguistic approach to the view up-date problem,” ACM Transactions on Programming Languages and Systems,vol. 40, no. 1, pp. 233–246, 2007.[58] M. Fowler, K. Beck, J. Brant, W. Opdyke, and D. Roberts, Refactoring: Im-proving the Design of Existing Code, 1999.[59] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Ele-ments of Reusable Object-Oriented Software. Addison-Wesley, 1995.434Bibliography[60] K. Garces, C. Parra, H. Arboleda, A. Yie, and R. Casallas, “Variabilitymanagement in a Model-Driven software product line,” Avances enSistemas e Informática, vol. 4, no. 2, pp. 3–12, 2007. [Online].Available: http://pisis.unalmed.edu.co/avances/archivos/ediciones/Edicion\%20Avances\%202007\%202/01.pdf[61] M. Garcia, “Bidirectional synchronization of multiple views of softwaremodels,” in Proceedings of the Workshop on Domain-Specific Modeling Lan-guages, ser. CEUR-WS, 2008.[62] A. A. E. Ghazi, “Modellierung der performance von thread-pools mit mod-ellierung der performance von thread-pools mit,” Study Thesis at KarlsruheInstute of Technology, 10 2007.[63] M. Girschick, T. Kühne, and F. Klar, “Generating systems from multiplelevels of abstraction,” in Conference on Trends in Enterprise ApplicationArchitecture, 2006.[64] T. Goldschmidt, S. Becker, and A. Uhl, “Textual views in model driven engi-neering,” in Proceedings of the 35th EUROMICRO Conference on SoftwareEngineering and Advanced Applications. IEEE, 2009.[65] ——, “Incremental Updates for Textual Modeling of Large Scale Models,”in Proceedings of the 15th IEEE International Conference on Engineering ofComplex Computer Systems - Poster Paper, 2010.[66] T. Goldschmidt and J. Kuebler, “Towards Evaluating Maintainability WithinModel-Driven Environments,” in Software Engineering 2008, WorkshopModellgetriebene Softwarearchitektur - Evolution, Integration und Migra-tion, 2008.[67] T. Goldschmidt and A. Uhl, “Retainment Rules for Model Transformations,”in Proceedings of the 1st International Workshop on Model Co-Evolutionand Consistency Management, 2008.[68] T. Goldschmidt and G. Wachsmuth, “Refinement transformation support forQVT Relational transformations,” in Proceedings of the 3rd Workshop onModel Driven Software Engineering, 2008.[69] V. Grassi, R. Mirandola, and A. Sabetta, “A Model Transformation Ap-proach for the Early Performance and Reliability Analysis of Component-435BibliographyBased Systems,” in Component-Based Software Engineering, 9th Interna-tional Symposium, CBSE 2006, Västerås, Sweden, June 29 - July 1, 2006,Proceedings, ser. Lecture Notes in Computer Science, vol. 4063. Springer,2006, pp. 270–284.[70] I. Groher and M. Voelter, “Expressing feature-based variability in structuralmodels,” in 11th Software Product Line Conference (SPLC) - Proceedings ofthe Workshop on Managing Variability for Software Product Lines, 2007.[71] ——, “Aspect-oriented model-driven software product line engineering,”Transactions on Aspect-Oriented Software Development VI, pp. 111–152,2009.[72] O. M. Group, MOF 2.0 Query/View/Transformation, version 1.0, O. docu-ment formal/08 04-03, Ed. OMG, 2008, no. OMG document formal/08-04-03. [Online]. Available: http://www.omg.org/spec/QVT/1.0/PDF/[73] D. Hamlet, “Subdomain testing of units and systems with state,” in Proc. ofsymposium on Software testing and analysis (ISSTA). ACM, 2006.[74] M. Hapner, R. Burridge, R. Sharma, J. Fialli, and K. Stout, “Java MessageService Specification -Version 1.1,” http://www.oracle.com/technetwork/ja-va/jms/index.html, last retrieved: July 2011.[75] J. Happe, “Towards a Model of Fair and Unfair Semaphores inMoDeST,” in Proceedings of the 6th Workshop on Process Algebra andStochastically Timed Activities, 2007, pp. 51–55. [Online]. Available:http://pastaworkshop.org/2007/proceedings/fair-semaphores.pdf[76] J. Happe, H. Friedrich, S. Becker, and R. H. Reussner, “A Pattern-Based Per-formance Completion for Message-Oriented Middleware,” in Proceedings ofthe 7th International Workshop on Software and Performance (WOSP ’08).New York, NY, USA: ACM, 2008, pp. 165–176.[77] J. Happe, D. Westermann, K. Sachs, and L. Kapova, “Statistical Inference ofSoftware Performance Models for Parametric Performance Completions,” inResearch into Practice - Reality and Gaps (Proceedings of QoSA 2010), ser.LNCS, G. Heineman, J. Kofron, and F. Plasil, Eds., vol. 6093. Springer-Verlag Berlin Heidelberg, 2010, pp. 20–35.436Bibliography[78] R. Harrison, L. G. Samaraweera, M. R. Dobie, and P. H. Lewis,“Estimating the quality of functional programs: an empirical investigation,”Information and Software Technology, vol. 37, no. 12, pp. 701 – 707,1995. [Online]. Available: http://www.sciencedirect.com/science/article/B6V0B-3YS2CBK-6/2/903ab3819bd8fe854dc98ea24c213c0f[79] T. Hastie, R. Tibshirani, J. Friedman, and J. Franklin, “The elements of sta-tistical learning: data mining, inference and prediction,” The MathematicalIntelligencer, vol. 27, no. 2, pp. 83–85, 2005.[80] M. Hauck, J. Happe, and R. H. Reussner, “Automatic Derivation of Per-formance Prediction Models for Load-balancing Properties Based on Goal-oriented Measurements,” in Proceedings of the 18th IEEE International Sym-posium on Modeling, Analysis and Simulation of Computer and Telecom-munication Systems (MASCOTS’10). IEEE Computer Society, 2010, pp.361–369.[81] M. Hauck, M. Kuperberg, N. Huber, and R. Reussner, “Ginpex: DerivingPerformance-relevant Infrastructure Properties Through Goal-oriented Ex-periments,” in 7th ACM SIGSOFT International Conference on the Qualityof Software Architectures (QoSA 2011), Boulder, Colorado, USA, June 20-242011.[82] F. Heidenreich, J. Kopcsek, and U. Aßmann, “Safe composition of trans-formations,” in Theory and Practice of Model Transformations, ser. LectureNotes in Computer Science, L. Tratt and M. Gogolla, Eds. Springer Berlin/ Heidelberg, 2010, vol. 6142, pp. 108–122.[83] B. Henderson-Sellers, Object-oriented metrics: measures of complexity.Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 1996.[84] M. Herrmannsdoerfer, S. Benz, and E. Juergens, “Cope: A language for thecoupled evolution of metamodels and models,” in Proceedings of the 1st In-ternational Workshop on Model Co-Evolution and Consistency Management,2008.[85] S. Hissam, G. Moreno, J. Stafford, and K. Wallnau, “Enabling predictableassembly,” Journal of Systems and Software, vol. 65, pp. 185–198, March2003. [Online]. Available: http://dl.acm.org/citation.cfm?id=860119.860122437Bibliography[86] N. Huber, S. Becker, C. Rathfelder, J. Schweflinghaus, and R. Reussner,“Performance Modeling in Industry: A Case Study on Storage Virtualiza-tion,” in ACM/IEEE 32nd International Conference on Software Engineer-ing, Software Engineering in Practice Track, Capetown, South Africa. NewYork, NY, USA: ACM, 2010, pp. 1–10, acceptance Rate: 23% (16/71). [On-line]. Available: http://sdqweb.ipd.uka.de/publications/pdfs/hubern2010.pdf[87] M. Iacob, M. Steen, and L. Heerink, “Reusable model transformation pat-terns,” in Enterprise Distributed Object Computing Conference Workshops,2008 12th. IEEE, 2008, pp. 1–10.[88] ikv++, “medini QVT,” Web site: [Last accessed Jan. 6, 2011] http://www.ikv.de/.[89] P. K. Jayaraman, J. Whittle, A. M. Elkhodary, and H. Gomaa, “Model com-position in product lines and feature interaction detection using critical pairanalysis,” in MoDELS, 2007.[90] F. Jouault, F. Allilaire, J. Bézivin, and I. Kurtev, “ATL: A model transforma-tion tool,” Science of Computer Programming, Special Issue on Second issueof experimental software and toolkits, vol. 72, pp. 31–39, 2008.[91] L. Kapova, T. Goldschmidt, S. Becker, and J. Henss, “Evaluating Main-tainability with Code Metrics for Model-to-Model Transformations,” in Re-search into Practice - Reality and Gaps (Proceeding of QoSA 2010), ser.LNCS, G. Heineman, J. Kofron, and F. Plasil, Eds., vol. 6093. Springer-Verlag Berlin Heidelberg, 2010, pp. 151–166, to appear.[92] L. Kapova, T. Goldschmidt, J. Happe, and R. H. Reussner, “Domain-specifictemplates for refinement transformations,” in MDI ’10: Proceedings of theFirst International Workshop on Model-Drive Interoperability. New York,NY, USA: ACM, 2010, pp. 69–78.[93] L. Kapova and R. Reussner, “Application of advanced model-driven tech-niques in performance engineering,” in Computer Performance Engineering,ser. Lecture Notes in Computer Science, A. Aldini, M. Bernardo, L. Bononi,and V. Cortellessa, Eds., vol. 6342. Springer Berlin / Heidelberg, 2010, pp.17–36.438Bibliography[94] L. Kapova, B. Zimmerova, A. Martens, J. Happe, and R. H. Reussner,“State dependence in performance evaluation of component-based softwaresystems,” in Proceedings of the 1st Joint WOSP/SIPEW InternationalConference on Performance Engineering (WOSP/SIPEW ’10). NewYork, NY, USA: ACM, 2010, pp. 37–48. [Online]. Available: http://sdqweb.ipd.uka.de/publications/pdfs/kapova2009b.pdf[95] C. Kästner, S. Apel, and M. Kuhlemann, “Granularity in software productlines,” in Proceedings of the 30th international conference on Software engi-neering. ACM, 2008, pp. 311–320.[96] A. Koziolek, H. Koziolek, and R. Reussner, “Peropteryx: automatedapplication of tactics in multi-objective software architecture optimization,”in Proceedings of the joint ACM SIGSOFT conference – QoSA and ACMSIGSOFT symposium – ISARCS on Quality of software architectures –QoSA and architecting critical systems – ISARCS, ser. QoSA-ISARCS ’11.New York, NY, USA: ACM, New York, NY, USA, 2011, pp. 33–42.[Online]. Available: http://qosa.ipd.kit.edu/qosa_2011/[97] H. Koziolek, “Parameter Dependencies for Reusable Performance Specifica-tions of Software Components,” Ph.D. dissertation, University of Oldenburg,2008.[98] ——, “Performance Evaluation of Component-based Software Systems: ASurvey,” Performance Evaluation, vol. 67, no. 8, pp. 634–658, August 2010.[99] H. Koziolek and S. Becker, “Transforming Operational Profiles of SoftwareComponents for Quality of Service Predictions,” in Proc. of Workshop onComponent Oriented Programming (WCOP), 2005.[100] H. Koziolek, S. Becker, J. Happe, and R. Reussner, Model-Driven SoftwareDevelopment: Integrating Quality Assurance. IDEA Group Inc., December2008, ch. Evaluating Performance of Software Architecture Models with thePalladio Component Model, pp. 95–118.[101] H. Koziolek and V. Firus, “Empirical Evaluation of Model-basedPerformance Predictions Methods in Software Development,” in Proceedingof the first International Conference on the Quality of Software Architectures(QoSA’05), R. H. Reussner, J. Mayer, J. A. Stafford, S. Overhage, S. Becker,439Bibliographyand P. J. Schroeder, Eds., vol. 3712, 2005, pp. 188–202. [Online]. Available:http://sdqweb.ipd.uka.de/publications/pdfs/koziolek2005b.pdf[102] H. Koziolek and J. Happe, “A QoS Driven Development Process Modelfor Component-Based Software Systems,” in Proc. of Symposium onComponent-Based Software Engineering (CBSE). Springer, 2006.[103] H. Koziolek, J. Happe, and S. Becker, “Parameter Dependent PerformanceSpecification of Software Components,” in Proc. 2nd Int. Conf. on theQuality of Software Architectures (QoSA’06), C. Hofmeister, I. Crnkovic,R. H. Reussner, and S. Becker, Eds., vol. 4214, July 2006, pp.163–179. [Online]. Available: http://sdqweb.ipd.uka.de/publications/pdfs/koziolek2006f.pdf[104] K. Krogmann, “Reconstruction of software component architecturesand behaviour models using static and dynamic analysis,” Ph.D.dissertation, Karlsruhe Institute of Technology (KIT), Karlsruhe, Germany,2010. [Online]. Available: http://digbib.ubka.uni-karlsruhe.de/volltexte/1000022278[105] J. Kübler and T. Goldschmidt, “A Pattern Mining Approach Using QVT,” inProceedings of the 5th European Conference on Model Driven Architecture- Foundations and Applications (ECMDA), ser. Lecture Notes in ComputerScience. Springer-Verlag Berlin Heidelberg, 2009. [Online]. Available:http://sdqweb.ipd.uka.de/publications/pdfs/kuebler2009a.pdf[106] M. Kuperberg and R. Reussner, “Analysing the Fidelity of MeasurementsPerformed With Hardware Performance Counters,” in Proceedings of theInternational Conference on Software Engineering 2011 (ICPE’11), March14–16, 2011, Karlsruhe, Germany, 2011.[107] E. A. Lee, “The Problem with Threads,” IEEE Computer, vol. 39, no. 5, pp.33–42, May 2006.[108] ——, “Threadedcomposite: A mechanism for building concurrent andparallel ptolemy ii models,” EECS Department, University of California,Berkeley, Tech. Rep. UCB/EECS-2008-151, Dec 2008. [Online]. Available:http://www.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-151.html440Bibliography[109] K. Lee, K. Kang, and J. Lee, “Concepts and guidelines of feature model-ing for product line software engineering,” Software Reuse: Methods, Tech-niques, and Tools, pp. 62–77, 2002.[110] Y. Liu, A. Fekete, and I. Gorton, “Design-level performance prediction ofcomponent-based applications,” IEEE Transactions on Software Engineer-ing, pp. 928–941, 2005.[111] I. Malavolta, H. Muccini, and P. Pelliccione, “Dually: A framework for archi-tectural languages and tools interoperability,” 23rd IEEE/ACM InternationalConference on Automated Software Engineering, 2008.[112] A. Martens, “Empirical Validation of the Model-driven Performance Pre-diction Approach Palladio,” Master’s thesis, Carl-von-Ossietzky UniversitätOldenburg, Nov. 2007.[113] A. Martens and H. Koziolek, “Automatic, model-based software per-formance improvement for component-based software designs,” in 6thInternational Workshop on Formal Engineering approaches to SoftwareComponents and Architectures (FESCA), 2009, pp. 77–93. [Online].Available: http://sdqweb.ipd.uka.de/publications/pdfs/martens2009a.pdf[114] R. Marvie, “A transformation composition framework for model driven en-gineering,” LIFL IRCICA University of Lille, Tech. Rep., 2004.[115] M. Marzolla, “Simulation-based performance modeling of UML softwarearchitectures,” PhD Thesis TD-2004-1, Dipartimento di Informatica, Uni-versità Ca’ Foscari di Venezia, Mestre, Italy, Feb. 2004.[116] D. Masak, Legacysoftware. Springer, 2005.[117] metamodel.com, “Community site for meta-modelling and semanticmodelling: What is metamodeling, and what is it good for?” 2009,last retrieved 2011-08-09. [Online]. Available: http://infogrid.org/wiki/Reference/WhatIsMetaModeling[118] M. Meyerhöfer and K. Meyer-Wegener, “Estimating non-functional prop-erties of component-based software based on resource consumption,” Elec-tronic Notes in Theoretical Computer Science, 2005.[119] L. K. Misha Strittmatter, “Performance abstractions of communication pat-terns for connectors,” Study Thesis, University of Karlsruhe, 2010.441Bibliography[120] M. Moriconi, X. Qian, and R. A. Riemenschneider, “Correct architecturerefinement,” IEEE Transactions on Software Engineering, vol. 21, no. 4, pp.356–372, 1995.[121] B. Morin, G. Perrouin, P. Lahire, O. Barais, G. Vanwormhoudt,and J.-M. Jézéquel, “Weaving variability into domain metamodels,” inProceedings of the 12th International Conference on Model DrivenEngineering Languages and Systems, ser. MODELS ’09. Berlin,Heidelberg: Springer-Verlag, 2009, pp. 690–705. [Online]. Available:http://dx.doi.org/10.1007/978-3-642-04425-0_56[122] A. Mos and J. Murphy, “Performance management in component-orientedsystems using a model driven architecture approach,” in Proc. of EnterpriseDistributed Object Computing Conference. IEEE, 2002.[123] D. Muthig, “A light-weight approach facilitating an evolutionary transitiontowards software product lines,” Ph.D. dissertation, 2002.[124] Object Management Group (OMG), “Unified Modeling Language Speci-fication: Version 2, Revised Final Adopted Specification (ptc/04-10-02),”2004. [Online]. Available: http://www.uml.org/\#UML2.0[125] ——, “Model Driven Architecture - Specifications,” Web site: [Last accessedFeb. 1, 2011] http://www.omg.org/mda/specs.htm, 2006.[126] ——, “MOF 2.0 Core Specification (formal/2006-01-01),” 2006. [Online].Available: http://www.omg.org/cgi-bin/doc?formal/2006-01-01[127] ——, “Object Constraint Language, v2.0 (formal/06-05-01),” 2006.[Online]. Available: http://www.omg.org/cgi-bin/doc?formal/2006-05-01[128] ——, “UML Profile for Modeling and Analysis of Real-Time and Embeddedsystems (MARTE) RFP (realtime/05-02-06),” 2006. [Online]. Available:http://www.omg.org/cgi-bin/doc?realtime/2005-2-6[129] ——, “CORBA 3.0 - OMG IDL Syntax and Semantics chapter,” 2007.[Online]. Available: http://www.omg.org/docs/formal/02-06-39.pdf[130] J. Oldevik, “Transformation composition modelling framework,” in Dis-tributed Applications and Interoperable Systems, 2005, pp. 108– 114.[131] Oracle Technology Network, “The JAVA homepage,”http://www.oracle.com/technetwork/java/javase/overview/index.html.442Bibliography[132] D. C. Petriu and X. Wang, “From UML description of high-level softwarearchitecture to LQN performance models,” in Proc. of AGTIVE’99 Kerkrade,M. Nagl, A. Schürr, and M. Münch, Eds., vol. 1779. Springer, 2000.[133] C. Pons, R. Giandini, G. Perez, and G. Baum, “A two-level calculus forcomposing hybrid QVT transformations,” in Proceedings of the 2009 Inter-national Conference of the Chilean Computer Science Society, ser. SCCC.IEEE Computer Society, 2009.[134] A. Rentschler, “Model-to-text transformation languages,” in Seminar: Mod-ellgetriebene Software-Entwicklung Architekturen, Muster und Eclipse-basierte MDA, 2006.[135] R. H. Reussner, S. Becker, H. Koziolek, J. Happe, M. Kuperberg, andK. Krogmann, “The Palladio Component Model,” Universität Karlsruhe(TH), Interner Bericht 2007-21, 2007, october 2007. [Online]. Available:http://sdqweb.ipd.uka.de/publications/pdfs/reussner2007a.pdf[136] R. H. Reussner and W. Hasselbring, Handbuch der Software-Architektur.dPunkt.verlag, Heidelberg, 2006.[137] ——, Handbuch der Software-Architektur, 2nd ed., December 2008.[138] R. H. Reussner, H. W. Schmidt, and I. Poernomo, “Reliability Prediction forComponent-Based Software Architectures,” Journal of Systems and Software– Special Issue of Software Architecture – Engineering Quality Attributes,vol. 66, no. 3, pp. 241–252, 2003.[139] L. Reynoso, M. Genero, M. Piattini, and E. Manso, “Assessing theimpact of coupling on the understandability and modifiability of oclexpressions within uml/ocl combined models,” in Proceedings of the11th IEEE International Software Metrics Symposium. Washington,DC, USA: IEEE Computer Society, 2005, pp. 14–. [Online]. Available:http://dl.acm.org/citation.cfm?id=1090955.1092154[140] T. Rohrberg, “Visualisierung von entscheidungshilfen für software-architektur-tradeoffs,” Master’s thesis, Karlsruhe Institute of Technology,2010.443Bibliography[141] R. J. Rubey and R. D. Hartwick, “Quantitative measurement of programquality,” in Proceedings of the 1968 23rd ACM national conference. NewYork, NY, USA: ACM, 1968, pp. 671–677.[142] S. Röttger and S. Zschaler, “Model-driven development for non-functionalproperties: Refinement through model transformation,” in In: Proc. UMLConference. Springer, 2004, pp. 275–289.[143] D. C. Schmidt, H. Rohnert, M. Stal, and D. Schultz, Pattern-Oriented Soft-ware Architecture: Patterns for Concurrent and Networked Objects. NewYork, NY, USA: John Wiley & Sons, Inc., 2000.[144] A. Schürr, “Specification of Graph Translators with Triple Graph Gram-mars,” in 21st International Conference on Graph-Theoretic Concepts inComputer Science, 1995.[145] M. Scott, Programming language pragmatics. Morgan Kaufmann Pub,2000.[146] S. Sentilles, A. Vulgarakis, T. Bureš, J. Carlson, and I. Crnković, “A compo-nent model for control-intensive distributed embedded systems,” in 11th In-ternational Symposium on Component-Based Software Engineering (CBSE).Springer, 2008.[147] C. U. Smith and L. G. Williams, Performance Solutions: A Practical Guideto Creating Responsive, Scalable Software. Addison-Wesley, 2002.[148] R. L. Solso, Cognitive Psychology. Allyn and Bacon, 2001.[149] B. Spitznagel and D. Garlan, “A Compositional Formalization of ConnectorWrappers,” in Proceedings of the 25th International Conference on SoftwareEngineering, May 3-10, 2003, Portland, Oregon, USA, IEEE, Ed. LosAlamitos, CA: IEEE Computer Society, May 2003, pp. 374–384.[150] H. Stachowiak, “{Allgemeine Modelltheorie},” 1973.[151] J. Stammel and R. Reussner, “Kamp: Karlsruhe architectural maintainabil-ity prediction,” in Proceedings of the 1. Workshop des GI-ArbeitskreisesLanglebige Softwaresysteme (L2S2): "Design for Future - Langlebige Soft-waresysteme", 2009, pp. 87–98.[152] Standard Performance Evaluation Corp., “SPECjms2007 Benchmark,”http://www.spec.org/jms2007/, last retrieved: July 2011, 2007.444Bibliography[153] H. Störrle, “Structuring very large domain models: Experiences from indus-trial MDSD projects,” in Proceedings of the Fourth European Conference onSoftware Architecture: Companion Volume, 2010.[154] D. Streitferdt, “A component model for applications based on feature mod-els,” in Proceedings of the 2nd Workshop on Software Variability Manage-ment - Software Product Families and PopulationsProceedings of the 2ndWorkshop on Software Variability Management - Software Product Familiesand Populations, December 2004.[155] H. Sutter and J. Larus, “Software and the Concurrency Revolution,” ACMQueue, vol. 3, no. 7, pp. 54–62, 2005.[156] E. Syriani, J. Kienzle, and H. Vangheluwe, “Exceptional transformations,”Theory and Practice of Model Transformations, vol. 6142, pp. 199–214,2010.[157] C. Szyperski, Component Software – Beyond Object-Oriented Programming.Addison-Wesley, 2002.[158] M. Tisi, F. Jouault, P. Fraternali, S. Ceri, and J. Bézivin, “On the use ofhigher-order model transformations,” in Model Driven Architecture - Foun-dations and Applications, ser. Lecture Notes in Computer Science. SpringerBerlin / Heidelberg, 2009.[159] J. B. Tolosa, O. Sanjuán-Martínez, V. García-Díaz, B. C. P. G-Bustelo, andJ. M. C. Lovelle, “Towards the systematic measurement of ATL transfor-mation models,” Software: Practice and Experience, vol. 41, pp. 789–815,2010.[160] M. F. van Amstel, C. F. J. Lange, and M. G. J. van den Brand, “Metricsfor analyzing the quality of model transformations,” in 12th ECOOP Work-shop on Quantitative Approaches in Object-Oriented Software Engineering(QAOOSE), 2008.[161] P. Van Gorp, A. Keller, and D. Janssens, “Transformation language integra-tion based on profiles and higher order transformations,” in Software Lan-guage Engineering, ser. Lecture Notes in Computer Science. SpringerBerlin / Heidelberg, 2009.445Bibliography[162] J. Vara, V. Bollati, B. Vela, and E. Marcos, “Leveraging model transfor-mations by means of annotation models,” Model Transformation with ATL,p. 88, 2009.[163] D. Varró and A. Pataricza, “Generic and meta-transformations for modeltransformation engineering,” The Unified Modelling Language, vol. 3273,p. 290, 2004.[164] D. Varró, “Model transformation by example,” in 9th International Con-ference on Model Driven Engineering Languages and Systems (MODELS),2006, pp. 410–424.[165] T. Verdickt, B. Dhoedt, F. Gielen, and P. Demeester, “Automatic Inclusion ofMiddleware Performance Attributes into Architectural UML Software Mod-els,” IEEE Transactions on Software Engineering, vol. 31, no. 8, pp. 695–711, 2005.[166] M. Voelter and I. Groher, “Handling variability in model transformationsand generators,” in Proceedings of the 7th Workshop on Domain-SpecificModeling (DSM’07) at OOPSLA ’07, 2007.[167] M. Völter and T. Stahl, Model-Driven Software Development. Wiley &Sons, New York, USA, 2006.[168] D. Wagelaar, “Composition techniques for rule-based model transformationlanguages,” in Theory and Practice of Model Transformations, ser. LectureNotes in Computer Science. Springer Berlin / Heidelberg, 2008.[169] D. Westermann, J. Happe, M. Hauck, and C. Heupel, “The performancecockpit approach: A framework for systematic performance evaluations,”in 2010 36th EUROMICRO Conference on Software Engineering and Ad-vanced Applications. IEEE, 2010, pp. 31–38.[170] L. G. Williams and C. U. Smith, “Making the Business Case for SoftwarePerformance Engineering,” in Proceedings of the 29th International Com-puter Measurement Group Conference, December 7-12, 2003, Dallas, Texas,USA. Computer Measurement Group, 2003, pp. 349–358.[171] E. D. Willink and P. J. Harris, “The side transformation pattern: Makingtransforms modular and re-usable,” ENTCS, vol. 127, pp. 17–29, 2005.446Bibliography[172] M. Woodside, G. Franks, and D. C. Petriu, “The Future of Software Perfor-mance Engineering,” in Proceedings of ICSE 2007, Future of SE. IEEEComputer Society, Washington, DC, USA, 2007, pp. 171–187.[173] M. Woodside, D. C. Petriu, and K. H. Siddiqui, “Performance-related Com-pletions for Software Specifications.” in Proceedings of the 22rd Interna-tional Conference on Software Engineering, ICSE 2002, 19-25 May 2002,Orlando, Florida, USA. ACM, 2002, pp. 22–32.[174] X. Wu and M. Woodside, “Performance modeling from software compo-nents,” SIGSOFT Software Engineering Notes, vol. 29, pp. 290–301, 2004.[175] B. Zimmerova, “Modelling and Formal Analysis of Component-Based Sys-tems in View of Component Interaction,” Ph.D. dissertation, Masaryk Uni-versity, Czech Republic, 2008.[176] B. Zimmerova et al., The Common Component Modeling Example: Compar-ing Software Component Models, ser. LNCS. Springer, 2008, ch. 7.447Lucia HappeThe Karlsruhe Series on Software Design and QualityEdited by Prof. Dr. Ralf ReussnerDuring early development stages, performance predictions based on architecture models allow the evaluation of design alternatives. To provide accurate perfor-mance predictions, such models have to include low-level implementation details. Including such details leads to signifi cant modeling effort for software architects and requires detailed knowledge about the modelled system.This work proposes an advanced concept for model completions closing the gap between abstract architecture models and low-level details. The library of completions allows to reuse expert knowledge and to improve the accuracy of performance predictions. For this purpose, we extend Model-Driven Engineer-ing techniques by variability method for transformations. Our approach, called CHILIES, moves the management of variability to a higher abstraction level by using generators based on the Higher-Order Transformations.ISSN 1867-0067 ISBN 978-3-86644-990-9 9 783866 449909ISBN 978-3-86644-990-9Confi gurable Software Performance Completions through Higher-Order Model Transformations

Higher-Order Transformations in

Abstract

Extracted data

Related items

Related items