Code transformation is widely used in programming. Most developers are familiar with using a preprocessor to perform syntactic transformations (symbol substitution and macro expansion). However, it is often necessary to perform more complex transformations using semantic information contained in the source code. In this thesis, we developed EXTRACT; a general-purpose code transformation language. Using EXTRACT, it is possible to specify, in a modular and extensible manner, a variety of transformations on Java code such as insertion, removal, and restructuring. In support of this, we also developed JPath, a path language for identifying portions of Java source code. Combined, these two technologies make it possible to identify source code that is to be transformed and then specify how that code is to be transformed. We evaluate our technology using three case studies: a type name qualifier which transforms Java class names into fully-qualified class names; a contract checker which enforces pre- and post-conditions across behavioral subtypes; and a code obfuscator which mangles the names of a class's methods and fields such that they cannot be understood by a human, without breaking the semantic content of the class.

Kotlin is a relatively new language that has received much attention since its first stable release in February 2016. Despite the fast growth of the language, there is a lack of libraries to provide an intuitive, typed abstract syntax tree (AST). Recognizing the utility of user-friendly ASTs with support for various analysis and transformation tasks, we make a first contribution towards bringing one for Kotlin with KtSpoon. Kotlin’s interoperability capabilities with Java enables exploitation of Java’s mature echo system and we propose the use of the Spoon library with its Java metamodel as a base for a model of Kotlin. We show the feasibility of this approach with KtSpoon, which is implemented through small additions to the Spoon metamodel. It consists of a tree builder that outputs a Spoon AST from Kotlin source code and a pretty-printer that prints it back to source code. Through an empirical study, we find out that KtSpoon accurately can represent the full Kotlin language. We conclude that while it is possible to model the Kotlin language with small modifications to the Spoon metamodel, it will likely require a partial reimplementation for it to be an intuitive model for developers. / Kotlin är ett relativt nytt språk som har fått mycket uppmärksamhet sedan dess första stabila version släpptes i Februari 2016. Trots att språket vuxit snabbt så saknar det fortfarande ett bibliotek som tillhandahåller ett intuitivt och typat abstrakt syntaxträd (AST). Nyttan av användarvänliga abstrakta syntaxträd motiverar oss att ta ett första steg mot att skapa ett sådant för Kotlin med KtSpoon. Kotlins interoperabilitet med Java möjliggör nyttjandet av Javas omfattande ekosystem och vi föreslår därför användandet av biblioteket Spoon och dess metamodell av Java som grund för en modell av Kotlin. Genom skapandet av KtSpoon visar vi att det är möjligt att modellera kod skriven i Kotlin med små tillägg i Spoons metamodell. KtSpoon består av en trädbyggare som skapar ett AST från källkod skriven i Kotlin samt en skrivare som skriver tillbaka det till källkod. Genom en empirisk studie finner vi att det är möjligt att modellera hela språket Kotlin med små förändringar av Spoons metamodell, men att det sannolikt krävs en ny implementation av modellen för att den ska vara intuitiv för utvecklare att använda sig av.

Framework-specific modeling languages (FSMLs) help developers build applications based on object-oriented frameworks. FSMLs formalize abstractions and rules of the framework's application programming interfaces (APIs) and can express models of how applications use an API. Such models, referred to as framework-specific models, aid developers in understanding, creating, and evolving application code. We present the concept of FSMLs, propose a way of specifying their abstract syntax and semantics, and show how such language specifications can be interpreted to provide reverse, forward, and round-trip engineering of framework-specific models and framework-based application code. We present a method for engineering FSMLs that was extracted post-mortem from the experience of building four such languages. The method is driven by the use cases that the FSMLs under development are to support. We present the use cases, the overall process, and its instantiation for each language. The presentation focuses on providing concrete examples for engineering steps, outcomes, and challenges. It also provides strategies for making engineering decisions. The presented method and experience are aimed at framework developers and tool builders who are interested in engineering new FSMLs. Furthermore, the method represents a necessary step in the maturation of the FSML concept. Finally, the presented work offers a concrete example of software language engineering. FSML engineering formalizes existing domain knowledge that is not present in language form and makes a strong case for the benefits of such formalization. We evaluated the method and the exemplar languages. The evaluation is both empirical and analytical. The empirical evaluation involved measuring the precision and recall of reverse engineering and verifying the correctness or forward and round-trip engineering. The analytical evaluation focused on the generality of the method.

Framework-specific modeling languages (FSMLs) help developers build applications based on object-oriented frameworks. FSMLs formalize abstractions and rules of the framework's application programming interfaces (APIs) and can express models of how applications use an API. Such models, referred to as framework-specific models, aid developers in understanding, creating, and evolving application code. We present the concept of FSMLs, propose a way of specifying their abstract syntax and semantics, and show how such language specifications can be interpreted to provide reverse, forward, and round-trip engineering of framework-specific models and framework-based application code. We present a method for engineering FSMLs that was extracted post-mortem from the experience of building four such languages. The method is driven by the use cases that the FSMLs under development are to support. We present the use cases, the overall process, and its instantiation for each language. The presentation focuses on providing concrete examples for engineering steps, outcomes, and challenges. It also provides strategies for making engineering decisions. The presented method and experience are aimed at framework developers and tool builders who are interested in engineering new FSMLs. Furthermore, the method represents a necessary step in the maturation of the FSML concept. Finally, the presented work offers a concrete example of software language engineering. FSML engineering formalizes existing domain knowledge that is not present in language form and makes a strong case for the benefits of such formalization. We evaluated the method and the exemplar languages. The evaluation is both empirical and analytical. The empirical evaluation involved measuring the precision and recall of reverse engineering and verifying the correctness or forward and round-trip engineering. The analytical evaluation focused on the generality of the method.

Expert design knowledge is essential to develop a library of high-performance software. This includes how to implement and parallelize domain operations, how to optimize implementations, and estimates of which implementation choices are best. An expert repeatedly applies his knowledge, often in a rote and tedious way, to develop all of the related functionality expected from a domain-specific library. Expert knowledge is hard to gain and is easily lost over time when an expert forgets or when a new engineer starts developing code. The domain of dense linear algebra (DLA) is a prime example with software that is so well designed that much of experts' important work has become tediously rote in many ways. In this dissertation, we demonstrate how one can encode design knowledge for DLA so it can be automatically applied to generate code as an expert would or to generate better code. Further, the knowledge is encoded for perpetuity, so it can be reused to make implementing functionality on new hardware easier or it can be used to teach how software is designed to a non-expert. We call this approach to software engineering (encoding expert knowledge and automatically applying it) Design by Transformation (DxT). We present our vision, the methodology, a prototype code generation system, and possibilities when applying DxT to the domain of dense linear algebra. / text

Vérifier formellement des programmes concurrents est une tâche difficile. S’il existe différentes techniques pour la réaliser, très peu sont effectivement mises en oeuvre pour des programmes écrits dans des langages de programmation réalistes. En revanche, les techniques de vérification formelles de programmes séquentiels sont utilisées avec succès depuis plusieurs années déjà, et permettent d’atteindre de hauts degrés de confiance dans nos systèmes. Cette thèse propose une alternative aux méthodes d’analyses dédiées à la vérification de programmes concurrents consistant à transformer le programme concurrent en un programme séquentiel pour le rendre analysable par des outils dédiés aux programmes séquentiels. Nous nous plaçons dans le contexte de FRAMA-C, une plate-forme d’analyse de code C spécifié avec le langage ACSL. Les différentes analyses de FRAMA-C sont des greffons à la plate-forme, ceux-ci sont à ce jour majoritairement dédiés aux programmes séquentiels. La méthode de vérification que nous proposons est appliquée manuellement à la vérification d’un code concurrent issu d’un hyperviseur. Nous automatisons la méthode à travers un nouveau greffon à FRAMA-C qui permet de produire automatiquement, depuis un programme concurrent spécifié, un programme séquentiel spécifié équivalent. Nous présentons les bases de sa formalisation, ayant pour but d’en prouver la validité. Cette validité n’est valable que pour la classe des programmes séquentiellement consistant. Nous proposons donc finalement un prototype de solveur de contraintes pour les modèles mémoire faibles, capable de déterminer si un programme appartient bien à cette classe en fonction du modèle mémoire cible. / Formal verification of concurrent programs is a hard task. There exists different methods to perform such a task, but very few are applied to the verification of programs written using real life programming languages. On the other side, formal verification of sequential programs is successfully applied for many years, and allows to get high confidence in our systems. As an alternative to dedicated concurrent program analyses, we propose a method to transform concurrent programs into sequential ones to make them analyzable by tools dedicated to sequential programs. This work takes place within the analysis framework FRAMA-C, dedicated to the analysis of C code specified with ACSL. The different analyses provided by FRAMA-C are plugins to the framework, which are currently mostly dedicated to sequential programs. We apply this method to the verification of a concurrent code taken from an hypervisor. We describe the automation of the method implemented by a new plugin to FRAMAC that allow to produce, from a specified concurrent program, an equivalent specified sequential program. We present the basis of a formalization of the method with the objective to prove its validity. This validity is admissible only for the class of sequentially consistent programs. So, we finally propose a prototype of constraint solver for weak memory models, which is able to determine whether a program is in this class or not, depending on the targeted hardware.

<p>Општи информациони модел (CIM) користи се за опис електроенергетске мреже и за размену података између оператера преносних електроенергетских система. Како је модел постајао све заступљенији, појавила се потреба за његовим складиштењем. У раду је развијен методолошки приступ за развој базе података која би подржала релативно једноставно складиштење и рад са инстанцама CIM модела, које описују тренутно, активно стање у систему. Такође, омогућено је и праћење претходних, историјских стања CIM инстанци, као и њихова рестаурација у жељено стање. Очекује се да предложени приступ олакша увођење CIM модела у различита, наменска програмска решења.</p> / <p>Opšti informacioni model (CIM) koristi se za opis elektroenergetske mreže i za razmenu podataka između operatera prenosnih elektroenergetskih sistema. Kako je model postajao sve zastupljeniji, pojavila se potreba za njegovim skladištenjem. U radu je razvijen metodološki pristup za razvoj baze podataka koja bi podržala relativno jednostavno skladištenje i rad sa instancama CIM modela, koje opisuju trenutno, aktivno stanje u sistemu. Takođe, omogućeno je i praćenje prethodnih, istorijskih stanja CIM instanci, kao i njihova restauracija u željeno stanje. Očekuje se da predloženi pristup olakša uvođenje CIM modela u različita, namenska programska rešenja.</p> / <p>Common Information Model (CIM) is used for describing power grid networks<br />and data exchange among transmission system operators (TSO). As the<br />model became widely used, there was a need to store such model. In this<br />thesis we present a methodological approach to development of a database<br />that supports relatively easy storing and managing CIM instances, which<br />describe current, active state of the system. Also, tracking changes and<br />restoring CIM instances to its previous states are supported. We expect that<br />such methodological approach would ease the implementation of CIM model<br />in various, domain specific software solutions.</p>

<p>In this research paper, it evaluates the benefits achievable from static testing framework by analyzing and transforming the <em>JUnit3.8 </em>source code and static execution of transformed code. Static structure enables us to analyze the code statically during creation and execution of test cases. The concept of research is by now well established in static analysis and testing development. The research approach is also increasingly affecting the static testing process and such research oriented work has proved particularly valuable for those of us who want to understand the reflective behavior of <em>JUnit3.8 Framework</em>.</p><p><em> JUnit3.8 Framework</em> uses <em>Java Reflection API</em> to invoke core functionality (test cases creation and execution) dynamically. However, <em>Java Reflection API</em> allows developers to access and modify structure and behavior of a program.  Reflection provides flexible solution for creating test cases and controlling the execution of test cases. Java reflection helps to encapsulate test cases in a single object representing the test suite. It also helps to associate each test method with a test object. Where reflection is a powerful tool to perform potential operations, on the other hand, it limits static analysis. Static analysis tools often cannot work effectively with reflection.</p><p>In order to avoid the reflection, <em>Static Testing Framework</em> provides a static platform to analyze the <em>JUnit3.8</em> source code and transform it into non-reflective version that emulates the dynamic behavior of <em>JUnit3.8</em>. The transformed source code has possible leverage to replace reflection with static code and does same things in an execution environment of <em>Static Testing Framework</em> that reflection does in <em>JUnit3.8</em>. More besides, the transformed code also enables execution environment of <em>Static Testing Framework</em> to run test methods statically. In order to measure the degree of efficiency, the implemented tool is evaluated. The evaluation of <em>Static Testing Framework</em> draws results for different Java projects and these statistical data is compared with <em>JUnit3.8</em> results to measure the effectiveness of <em>Static Testing Framework</em>. As a result of evaluation, <em>STF</em> can be used for static creation and execution of test cases up to <em>JUnit3.8</em> where test cases are not creating within a test class and where real definition of constructors is not required. These problems can be dealt as future work by introducing a middle layer to execute test fixtures for each test method and by generating test classes as per real definition of constructors.</p>

In this research paper, it evaluates the benefits achievable from static testing framework by analyzing and transforming the JUnit3.8 source code and static execution of transformed code. Static structure enables us to analyze the code statically during creation and execution of test cases. The concept of research is by now well established in static analysis and testing development. The research approach is also increasingly affecting the static testing process and such research oriented work has proved particularly valuable for those of us who want to understand the reflective behavior of JUnit3.8 Framework. JUnit3.8 Framework uses Java Reflection API to invoke core functionality (test cases creation and execution) dynamically. However, Java Reflection API allows developers to access and modify structure and behavior of a program.  Reflection provides flexible solution for creating test cases and controlling the execution of test cases. Java reflection helps to encapsulate test cases in a single object representing the test suite. It also helps to associate each test method with a test object. Where reflection is a powerful tool to perform potential operations, on the other hand, it limits static analysis. Static analysis tools often cannot work effectively with reflection. In order to avoid the reflection, Static Testing Framework provides a static platform to analyze the JUnit3.8 source code and transform it into non-reflective version that emulates the dynamic behavior of JUnit3.8. The transformed source code has possible leverage to replace reflection with static code and does same things in an execution environment of Static Testing Framework that reflection does in JUnit3.8. More besides, the transformed code also enables execution environment of Static Testing Framework to run test methods statically. In order to measure the degree of efficiency, the implemented tool is evaluated. The evaluation of Static Testing Framework draws results for different Java projects and these statistical data is compared with JUnit3.8 results to measure the effectiveness of Static Testing Framework. As a result of evaluation, STF can be used for static creation and execution of test cases up to JUnit3.8 where test cases are not creating within a test class and where real definition of constructors is not required. These problems can be dealt as future work by introducing a middle layer to execute test fixtures for each test method and by generating test classes as per real definition of constructors.