• Refine Query
  • Source
  • Publication year
  • to
  • Language
  • 25
  • 4
  • 2
  • 1
  • 1
  • Tagged with
  • 36
  • 36
  • 23
  • 12
  • 9
  • 9
  • 7
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • 6
  • About
  • The Global ETD Search service is a free service for researchers to find electronic theses and dissertations. This service is provided by the Networked Digital Library of Theses and Dissertations.
    Our metadata is collected from universities around the world. If you manage a university/consortium/country archive and want to be added, details can be found on the NDLTD website.
31

IDE for SCADA Development at CERN / IDE for SCADA Development at CERN

Mareček, Matěj January 2016 (has links)
Cílem této magisterské práce je navrhnout a implementovat IDE (integrované vývojové prostředí), které zvýší efektivitu a bezpečnost vývoje pro SIMATIC WinCC Open Architecture. Tato práce je založena na výzkumu provedeném týmem z Technické univerzity v Eindhovenu a splňuje požadavky pocházející ze SCD sekce v CERN (Evropské organizace pro jaderný výzkum). Vyvinuté IDE je postaveno na platformě Eclipse, přičemž pro syntaktickou analýzu, linkování a sémantickou analýzu kódu používá Xtext framework. IDE nabízí také podporu pro nově vytvořený programovací jazyk, který umožňuje programátorům jednoduše nadefinovat šablonu pro konfigurační soubory používané WinCC OA. Interpret tohoto nového jazyka je schopen provést syntaktickou analýzu šablony a konfiguračního souboru a rozhodnout, zdali konfigurační soubor odpovídá šabloně. Praktickým výstupem této práce je integrované vývojové prostředí, které podporuje vývoj WinCC OA aplikací v CERN a periodicky provádí analýzu kódu těchto aplikací napsaného v jazyce Control script.
32

Subtree Hashing of Tests in Build Systems : Rust Tricorder / Subträd Hashing av tester i byggsystem : Rust Tricorder

Capitanu, Calin January 2023 (has links)
Software applications are built by teams of developers that constantly iterate over the codebase. Software projects rely on a build system, which handles the management of dependencies, compilation, testing, and deployment of the software. The execution of the tests during each build allow developers to validate that their changes do not introduce regressions. However, the execution of the test suite during each build can take a long time, potentially impacting the development process. To facilitate quicker feedback, build systems use incremental building in order to avoid the reprocessing of unmodified artifacts. This is achieved by maintaining a cache of source files, and only rebuilding artifacts that differ from their cached version. Yet, changing any part of a source file invalidates the cache, triggering the re-execution of unmodified tests. This focus over an entire file can be misleading to the build system, as it can not determine whether the actual function being tested has changed, thus invoking redundant re-testing. In this thesis, we propose a finer-grained approach to caching within build systems, by caching components within the Abstract Syntax Tree instead of entire source files. We compare their hashes on subsequent runs, in order to identify components that have changed. The potential advantage of this strategy is that re-running a specific test that has not been modified will leverage the use of caches even if the file that contains it has been modified. We implement our approach in a system called TRICORDER, and integrate it within a build system called WARP. TRICORDER works by analyzing RUST source code in order to identify the test cases that have not been changed, such as through the addition of comments, or modifications of unrelated functions. This can benefit developers by avoiding the re-execution of tests that are unmodified. We evaluate our approach against 4 notable, open-source RUST projects, targeting a set of 16 tests within them. We first analyze the accuracy with which TRICORDER detects the internal dependencies of a test function, which is needed for the code slicing done by TRICORDER, in order to cache code items related to the target test function. We then introduce artificial changes to our study subjects in order to determine whether or not TRICORDER indicates tests that need to be re-run. Finally, we analyze the ability of TRICORDER to identify real changes based on the commit history of our study subjects. Our results show that the more granular approach to caching can avoid the unnecessary recompilation and re-execution of test cases. An important direction for future work is to extend the current implementation to support the entire set of RUST features in order to evaluate TRICORDER on a larger set of study subjects. / Programvaruapplikationer byggs av utvecklingsteam som ständigt itererar över kodbasen. Programvaruprojekt förlitar sig på ett byggsystem som hanterar beroenden, kompilering, testning och implementering av programvaran. Utförande av testerna under varje byggprocess möjliggör för utvecklare att validera att deras ändringar inte introducerar regressionsfel. Dock kan utförningen av testsviten under varje byggprocess ta lång tid och potentiellt påverka utvecklingsprocessen. För att underlätta snabbare återkoppling använder byggsystemen inkrementell byggning för att undvika onödig återbearbetning av oförändrade artefakter. Detta uppnås genom att bibehålla en cache av källkodsfilerna och endast bygga om artefakter som skiljer sig från deras cachade version. Att ändra vilken del som helst av en källkodsfil invaliderar cachet och utlöser körningen av oförändrade tester. Fokuseringen på en hel fil kan vara vilseledande för byggsystemet, då det inte kan avgöra om den faktiska funktionen som testas har ändrats och därigenom påbörjar onödig omtestning. I detta projekt föreslår vi en mer detaljerad cache-strategi inom byggsystem, genom att cacha komponenter inom det abstrakta syntaxträdet istället för hela källkodsfiler. Vi jämför deras hash-värden vid senare körningar för att identifiera ändringar. Den potentiella fördelen med denna strategi är när man kör om ett specifikt test som inte har ändrats kan cachen användas även om filen som innehåller testet har modifierats. Vi implementerar vår metod i ett system som kallas TRICORDER och integrerar det i ett byggsystem som heter WARP. TRICORDER fungerar genom att analysera RUST-källkod för att identifiera testfall som inte har ändrats, till exempel genom tillägg av kommentarer eller ändringar av irrelevanta funktioner. Detta kan gynna utvecklare genom att undvika att köra om tester som inte har ändrats. Vi utvärderar vår metod mot 4 välkända öppen källkodsprojekt i RUST och riktar in oss på en uppsättning av 16 tester inom dem. Först analyserar vi noggrannheten med vilken TRICORDER identifierar de interna beroendena hos en testfunktion, vilket behövs för kodavskärningen som TRICORDER utför för att cachelagra kodenheter relaterade till måltestfunktionen. Sedan inför vi konstgjorda ändringar i våra studieobjekt för att avgöra om TRICORDER indikerar tester som behöver köras om. Slutligen analyserar vi TRICORDER förmåga att identifiera verkliga ändringar baserat på ändringshistoriken för våra studieobjekt. Våra resultat visar att den mer granulära cachelagringsmetoden kan undvika onödig omkompilering och omkörning av testfall. En viktig riktning för framtida arbete är att utöka den nuvarande implementationen för att stödja hela uppsättningen av RUST-funktioner för att utvärdera TRICORDER på en större uppsättning studieobjekt. / Aplicațiile software sunt dezvoltate de programatori care iterează constant asupra codului. Proiectele de software se bazează pe un sistem de generare care gestionează dependențele, compilarea, testarea și lansarea software-ului. Execuția testelor permite dezvoltatorilor să valideze că modificările lor nu introduc regresii. Cu toate acestea, execuția testelor în cadrul fiecărei generări poate dura mult timp, având potențialul de a incetinii dezvoltarea. Pentru a facilita o reprocesare mai rapidă, sistemele de generare utilizează construirea incrementală pentru a evita reprelucrarea a artefactelor nemodificate. Acest lucru se realizează prin menținerea unei cache și reconstruirea doar a artefactelor care diferă de cele din cache. Cu toate acestea, orice modificare a unui fișier sursă invalidează cache-ul, declanșând reprocesarea. Focalizarea asupra unui fișier întreg poate induce în eroare sistemul de generare, deoarece nu poate determina dacă funcția testată a suferit modificări, declanșând astfel teste redundante. În această teză, propunem o abordare mai detaliată a cache-ului în cadrul sistemelor de generare, prin cacharea componentelor Arborelui Sintactic Abstract, în locul întregilor fișiere sursă. Comparăm hash-urile acestora în rulările ulterioare pentru a identifica componentele modificate. Avantajul potențial al acestei strategii constă în faptul că reexecutarea unui test care nu a nemodificat va utiliza cache-urile chiar dacă fișierul a fost modificat. Implementăm abordarea noastră într-un sistem numit TRICORDER și îl integrăm într-un sistem de construire numit WARP. TRICORDER funcționează prin analizarea codului sursă RUST pentru a identifica cazurile de testare care nu au fost modificate, cum ar fi prin adăugarea de comentarii sau modificări ale funcțiilor nerelevante. Acest lucru poate fi benefic pentru dezvoltatori, evitând reexecutarea testelor care nu au fost modificate. Evaluăm abordarea noastră în raport cu 4 proiecte notabile open-source în RUST, având în vedere un set de 16 teste în cadrul acestora. Mai întâi, analizăm precizia cu care TRICORDER detectează dependențele interne ale unei funcții de testare, ceea ce este necesar pentru tăierea de cod realizată de TRICORDER, pentru a memora în cache elementele de cod legate de funcția de testare țintă. Apoi, introducem modificări artificiale în subiecții noștri de studiu pentru a determina dacă TRICORDER indică sau nu teste care trebuie reluate. În final, analizăm capacitatea TRICORDER de a identifica schimbări reale pe baza istoricului de angajări al subiecților noștri de studiu. Rezultatele noastre arată că abordarea mai granulară a memorării în cache poate evita recompilarea și reexecutarea inutilă a cazurilor de testare. O direcție importantă pentru viitor este extinderea implementării curente pentru a sprijini întregul set de caracteristici RUST, pentru a evalua TRICORDER pe un set mai mare de subiecți de studiu.
33

Interaktivní interpret jazyka C / C Language Interactive Interpreter

Blažek, Martin January 2008 (has links)
This master's thesis deals with implementation of ISO C99 language interpreter. The goal of this thesis is to provide support of education in C language programming and fast algorithm prototyping. It enables students to create own C programs and to experiment with language constructions without compiling. User interface includes editor and simple debugger. The interpreter is implemented in a novel grammar development environment written in Java language - ANTLRWorks which includes ANTLR language tool.
34

Elementos de Semántica Denotacional de Lenguajes de Programación con Datos Borrosos

Sánchez Álvarez, Daniel 01 October 1999 (has links)
A fin de diseñar e implementar lenguajes de programación que tengan en cuenta el paradigma borroso modificaremos el lambda cálculo clásico, adjuntando a cada término un grado, y redefiniendo la beta-reducción, obteniendo que para que el nuevo cálculo verifique la propiedad de Church-Rosser la transmisión de los grados debe hacerse por medio de una función que sea una t-norma o s-conorma. Utilizando esta nueva herramienta diseñamos un lenguaje no determinista que satisface los requerimientos de la programación con datos borrosos. / With the aim of designing and implementing programming languages that take into account the fuzzy paradigm we will modify the classical lambda calculus by adding a degree to each term and by redefining the b-reduction. Thus, for the new calculus to verify the Church-Rosser property, the degree computed with can be made through a function that is a t-norm or an s-conorm. With this new tool we design a nondeterminist language that satisfies fuzzy dataprogramming requirements, and an example of its behaviour is shown.
35

Web applications using the Google Web Toolkit / Webanwendungen unter Verwendung des Google Web Toolkits

von Wenckstern, Michael 04 June 2013 (has links) (PDF)
This diploma thesis describes how to create or convert traditional Java programs to desktop-like rich internet applications with the Google Web Toolkit. The Google Web Toolkit is an open source development environment, which translates Java code to browser and device independent HTML and JavaScript. Most of the GWT framework parts, including the Java to JavaScript compiler as well as important security issues of websites will be introduced. The famous Agricola board game will be implemented in the Model-View-Presenter pattern to show that complex user interfaces can be created with the Google Web Toolkit. The Google Web Toolkit framework will be compared with the JavaServer Faces one to find out which toolkit is the right one for the next web project. / Diese Diplomarbeit beschreibt die Erzeugung desktopähnlicher Anwendungen mit dem Google Web Toolkit und die Umwandlung klassischer Java-Programme in diese. Das Google Web Toolkit ist eine Open-Source-Entwicklungsumgebung, die Java-Code in browserunabhängiges als auch in geräteübergreifendes HTML und JavaScript übersetzt. Vorgestellt wird der Großteil des GWT Frameworks inklusive des Java zu JavaScript-Compilers sowie wichtige Sicherheitsaspekte von Internetseiten. Um zu zeigen, dass auch komplizierte graphische Oberflächen mit dem Google Web Toolkit erzeugt werden können, wird das bekannte Brettspiel Agricola mittels Model-View-Presenter Designmuster implementiert. Zur Ermittlung der richtigen Technologie für das nächste Webprojekt findet ein Vergleich zwischen dem Google Web Toolkit und JavaServer Faces statt.
36

Web applications using the Google Web Toolkit

von Wenckstern, Michael 05 June 2013 (has links)
This diploma thesis describes how to create or convert traditional Java programs to desktop-like rich internet applications with the Google Web Toolkit. The Google Web Toolkit is an open source development environment, which translates Java code to browser and device independent HTML and JavaScript. Most of the GWT framework parts, including the Java to JavaScript compiler as well as important security issues of websites will be introduced. The famous Agricola board game will be implemented in the Model-View-Presenter pattern to show that complex user interfaces can be created with the Google Web Toolkit. The Google Web Toolkit framework will be compared with the JavaServer Faces one to find out which toolkit is the right one for the next web project.:I Abstract II Contents III Acronyms and Glossary III.I Acronyms III.II Glossary IV Credits 1 Introduction 2 Basics 2.1 Development of the World Wide Web 2.2 Hypertext Markup Language 2.3 Cascading Style Sheets 2.4 JavaScript 2.5 Hypertext Markup Language Document Object Model 2.6 Asynchronous JavaScript and XML 3 GWT toolbox and compiler 3.1 GWT in action 3.2 A short overview of the toolkit 3.3 GWT compiler and JSNI 3.3.1 Overview of GWT compiler and JSNI 3.3.2 Deferred binding and bootstrapping process 3.3.3 GWT compiler steps and optimizations 3.4 Java Runtime Environment Emulation 3.5 Widgets and Panels 3.5.1 Overview of GWT Widgets 3.5.2 Event handlers in GWT Widgets 3.5.3 Manipulating browser’s DOM with GWT DOM class 3.5.4 GWT Designer and view optimization using UiBinder 3.6 Remote Procedure Calls 3.6.1 Comparison of Remote Procedure Calls with Remote Method Invocations 3.6.2 GWT’s RPC service and serializable whitelist 3.7 History Management 3.8 Client Bundle 3.8.1 Using ImageResources in the ClientBundle interface 3.8.2 Using CssResources in the ClientBundle interface 4 Model-View-Presenter Architecture 4.1 Comparison of MVP and MVC 4.2 GWT Model-View-Presenter pattern example: Agricola board game 4.3 Extending the Agricola web application with mobile views 4.4 Introducing activities in the Agricola Model-View-Presenter pattern enabling browser history 5 Comparison of the two web frameworks: GWT and JSF 5.1 Definitions of comparison fields 5.2 Comparison in category 1: Nearly completely static sites with a little bit of dynamic content, e.g. news update 5.3 Comparison in category 2: Doing a survey in both technologies 5.4 Comparison in category 3: Creating a forum to show data 5.5 Comparison in category 4: Writing a chat application 5.6 Comparison in category 5: Writing the speed game Snake 5.7 Summary 6 Security 6.1 Download Tomcat 6.2 Dynamic Web Application Project with GWT and Tomcat 6.3 Establish HTTPS connections in Tomcat 6.3.1 Create a pem certificate 6.3.2 Convert pem certificate into a key store object 6.3.3 Configure Tomcat’s XML files to enable HTPPS 6.4 Establish a database connection in Tomcat 6.4.1 Create TomcatGWT user and schema, and add the table countries 6.4.2 Configure Tomcat’s XML files to get access to the database connection 6.4.3 PreparedStatements avoid MySQL injections 6.5 Login mechanism in Tomcat 6.6 SafeHtml 7 Presenting a complex software application written in GWT 8 Conclusions 8.1 Summary 8.2 Future work A Appendix A 1 Configure the Google Web Toolkit framework in Eclipse A 1.1 Install the Java Developer Kit A 1.2 Download Eclipse A 1.3 Install the GWT plugin in Eclipse A 1.4 Create first GWT Java Project A 2 Figures A 3 Listings A 3.1 Source code of the Agricola board game A 3.2 Source code of GWT and JSF comparison A 4 Tables R Lists and References R 1 Lists R 1.1 List of Tables R 1.2 List of Figures R 1.3 List of Listings R 2 References R 2.1 Books R 2.2 Online resources / Diese Diplomarbeit beschreibt die Erzeugung desktopähnlicher Anwendungen mit dem Google Web Toolkit und die Umwandlung klassischer Java-Programme in diese. Das Google Web Toolkit ist eine Open-Source-Entwicklungsumgebung, die Java-Code in browserunabhängiges als auch in geräteübergreifendes HTML und JavaScript übersetzt. Vorgestellt wird der Großteil des GWT Frameworks inklusive des Java zu JavaScript-Compilers sowie wichtige Sicherheitsaspekte von Internetseiten. Um zu zeigen, dass auch komplizierte graphische Oberflächen mit dem Google Web Toolkit erzeugt werden können, wird das bekannte Brettspiel Agricola mittels Model-View-Presenter Designmuster implementiert. Zur Ermittlung der richtigen Technologie für das nächste Webprojekt findet ein Vergleich zwischen dem Google Web Toolkit und JavaServer Faces statt.:I Abstract II Contents III Acronyms and Glossary III.I Acronyms III.II Glossary IV Credits 1 Introduction 2 Basics 2.1 Development of the World Wide Web 2.2 Hypertext Markup Language 2.3 Cascading Style Sheets 2.4 JavaScript 2.5 Hypertext Markup Language Document Object Model 2.6 Asynchronous JavaScript and XML 3 GWT toolbox and compiler 3.1 GWT in action 3.2 A short overview of the toolkit 3.3 GWT compiler and JSNI 3.3.1 Overview of GWT compiler and JSNI 3.3.2 Deferred binding and bootstrapping process 3.3.3 GWT compiler steps and optimizations 3.4 Java Runtime Environment Emulation 3.5 Widgets and Panels 3.5.1 Overview of GWT Widgets 3.5.2 Event handlers in GWT Widgets 3.5.3 Manipulating browser’s DOM with GWT DOM class 3.5.4 GWT Designer and view optimization using UiBinder 3.6 Remote Procedure Calls 3.6.1 Comparison of Remote Procedure Calls with Remote Method Invocations 3.6.2 GWT’s RPC service and serializable whitelist 3.7 History Management 3.8 Client Bundle 3.8.1 Using ImageResources in the ClientBundle interface 3.8.2 Using CssResources in the ClientBundle interface 4 Model-View-Presenter Architecture 4.1 Comparison of MVP and MVC 4.2 GWT Model-View-Presenter pattern example: Agricola board game 4.3 Extending the Agricola web application with mobile views 4.4 Introducing activities in the Agricola Model-View-Presenter pattern enabling browser history 5 Comparison of the two web frameworks: GWT and JSF 5.1 Definitions of comparison fields 5.2 Comparison in category 1: Nearly completely static sites with a little bit of dynamic content, e.g. news update 5.3 Comparison in category 2: Doing a survey in both technologies 5.4 Comparison in category 3: Creating a forum to show data 5.5 Comparison in category 4: Writing a chat application 5.6 Comparison in category 5: Writing the speed game Snake 5.7 Summary 6 Security 6.1 Download Tomcat 6.2 Dynamic Web Application Project with GWT and Tomcat 6.3 Establish HTTPS connections in Tomcat 6.3.1 Create a pem certificate 6.3.2 Convert pem certificate into a key store object 6.3.3 Configure Tomcat’s XML files to enable HTPPS 6.4 Establish a database connection in Tomcat 6.4.1 Create TomcatGWT user and schema, and add the table countries 6.4.2 Configure Tomcat’s XML files to get access to the database connection 6.4.3 PreparedStatements avoid MySQL injections 6.5 Login mechanism in Tomcat 6.6 SafeHtml 7 Presenting a complex software application written in GWT 8 Conclusions 8.1 Summary 8.2 Future work A Appendix A 1 Configure the Google Web Toolkit framework in Eclipse A 1.1 Install the Java Developer Kit A 1.2 Download Eclipse A 1.3 Install the GWT plugin in Eclipse A 1.4 Create first GWT Java Project A 2 Figures A 3 Listings A 3.1 Source code of the Agricola board game A 3.2 Source code of GWT and JSF comparison A 4 Tables R Lists and References R 1 Lists R 1.1 List of Tables R 1.2 List of Figures R 1.3 List of Listings R 2 References R 2.1 Books R 2.2 Online resources

Page generated in 0.0656 seconds