Listing 1 - 10 of 14 | << page >> |
Sort by
|
Choose an application
Dit doctoraatswerk bestudeert de problematiek van dynamische applicatie-adaptatie voor component-gebaseerde software systemen. De belangrijkste bijdragen van dit werk situeren zich op drie domeinen: (1) Het ontwerp en de ontwikkeling van een componentmethodologie en bijhorende middleware systeem genaamd Draco. Draco bestaat uit een kleine kern die in staat is componentencomposities uit te voeren. (2) Het ontwerp en de ontwikkeling van een uitbreidingsmodule die op volledig transparante wijze voor de gebruiker functionaliteit van dynamische adapatatie toevoegt aan het middleware systeem. Hierdoor wordt het mogelijk componenten tijdens de uitvoering van de applicatie te vervangen door een nieuwe versie. (3) Ondersteuning voor de generatie van overdrachtsroutines die de toestand die zich in de actieve component instanties bevindt overdragen naar de nieuwe versie. Het proces dat in dit werk geintroduceerd wordt bestaat uit twee delen. Tijdens de ontwikkelingsfase wordt de broncode van een component geanalyseerd en vergeleken met de vorige versie. Deze analyzefase tracht semi-automatisch overeenkomstige structuren tussen verschillende versies te localiseren door type en structuur analyze. Vervolgens wordt deze informatie toegevoegd aan de nieuwe componentenversie via codeinstrumentatie. Tijdens de uitvoering wordt deze informatie dan gebruikt door de extensiemodule van het middleware systeem. In this work, we address the problem of dynamic software evolution for component-based applications. The contributions of this work are threefold: (1) Design and implementation of a flexible and extensible component middleware system that allows the execution of component compositions at runtime. (2) Design and implementation of a extension module that transparantly adds live update functionality to the middleware platform (3) Support for semi-automatic generation of state transfer functionality. The process introduced in this work consists of two parts. At design time the source code of a component is analyzed and compared with the previous version. The results of this analysis are then embedded in the code of the new version using code instrumentation techniques. At runtime, the middleware and extension module use the information embedded in the component to safely replace the component without interrupting application execution.
Choose an application
Programming --- software engineering --- systeemontwikkeling (informatica) --- Computer architecture. Operating systems --- Software Engineering --- Software engineering --- 681.3*D2 --- Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Software engineering. --- 681.3*D2 Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Computer software engineering --- Engineering
Choose an application
Software Engineering --- Computerprogrammering --- Programmeermethoden --- 681.3*D2 --- Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Computerprogrammering. --- Programmeermethoden. --- 681.3*D2 Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Software engineering --- Computer software engineering --- Engineering
Choose an application
Software engineering --- Engineering & Applied Sciences --- Computer Science --- 681.3*D2 <063> --- Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51}--Congressen --- 681.3*D2 <063> Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51}--Congressen
Choose an application
In this doctorate, we focus on increasing the reusability of object-oriented software and object-oriented programming languages. A first part of the research consists of increasing the usability of reusable components that use checked exceptions. The common way of dealing with exceptional conditions in object-oriented software is the use of an exception handling mechanism. When an exceptional condition is detected by a component, it raises an exception and signals it to the caller. The caller can then handle the exception in a context dependent manner. This way, the reusability of a component is improved by removing the specific logic for handling the abnormal condition from that component. In addition, exception handling mechanisms force a separation of normal code and exception handling code, resulting in programs that are easier to understand. Exceptions can be divided into two categories: checked exceptions and unchecked exceptions. Checked exceptions must be propagated explicitly by listing them in the method header, while unchecked exceptions are propagated implicitly. Note that this is different from the categorisation caught-uncaught, which denotes whether an exception can exit a method body. Checked exceptions improve the robustness of software. Because every checked exception that can be signalled during the execution of a method must either be listed in the exception clause -- the throws clause in Java -- of that method or handled in its body, it is impossible to encounter an unanticipated checked exception at run-time. The programmer is forced to make a decision for every checked exception, so he can be reasonably sure that all checked exceptions are handled properly. As the software evolves, checked exceptions may need to be added to or removed from existing methods. The compiler will reject all methods that can encounter newly added checked exceptions, but do not deal with them. Outdated exception handlers for checked exceptions that cannot be signalled anymore will also be rejected, keeping the source code clean. Consequently, all affected methods must be modified manually by the programmer. Unfortunately, checked exceptions also cause problems. First of all, they decrease the adaptability of software. Modifying the exception clause of a method can trigger modifications along every call chain encountering that method. Another problem is the lack of context information available to the exception handling mechanism. Often, a programmer knows that a certain checked exception cannot be signalled by a particular method invocation, but the exception handling mechanism does not. This leads to the addition of dummy exception handlers that are inconvenient and dangerous for the evolution of the program. In this research, we track down the problems with checked exceptions to a lack of expressiveness of the exception clause. We then add the required expressiveness by introducing anchored exception declarations to provide a relative means to declare the exceptional behavior of a method besides traditional absolute declarations. Anchored exception declarations implemented as an extension to ClassicJava. The mechanism itself, however, is not specific to the Java programming language, nor to any particular exception handling mechanism. do not deal with them. Outdated exception handlers for checked exceptions that cannot be signalled anymore will also be rejected, keeping the source code clean. Consequently, all affected methods must be modified manually by the programmer. Unfortunately, checked exceptions also cause problems. First of all, they decrease the adaptability of software. Modifying the exception clause of a method can trigger modifications along every call chain encountering that method. Another problem is the lack of context information available to the exception handling mechanism. Often, a programmer knows that a certain checked exception cannot be signalled by a particular method invocation, but the exception handling mechanism does not. This leads to the addition of dummy exception handlers that are inconvenient and dangerous for the evolution of the program. In this research, we track down the problems with checked exceptions to a lack of expressiveness of the exception clause. We then add the required expressiveness by introducing anchored exception declarations to provide a relative means to declare the exceptional behavior of a method besides traditional absolute declarations. Anchored exception declarations implemented as an extension to ClassicJava. The mechanism itself, however, is not specific to the Java programming language, nor to any particular exception handling mechanism.
Academic collection --- 681.3*D15 <043> --- 681.3*D2 <043> --- 681.3*D33 <043> --- Software: object-oriented programming--Dissertaties --- Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51}--Dissertaties --- Languages constructs: abstract data types; concurrent programming structures;control structures; coroutines (Programming languages)--Dissertations --- Theses --- 681.3*D2 <043> Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51}--Dissertaties
Choose an application
Programming languages (Electronic computers) --- 681.3*D1 --- 681.3*D2 --- Computer languages --- Computer program languages --- Computer programming languages --- Machine language --- Electronic data processing --- Languages, Artificial --- 681.3*D1 Programming techniques--See also {681.3*E} --- Programming techniques--See also {681.3*E} --- 681.3*D2 Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51}
Choose an application
Software architecture --- Software patterns --- Computer software --- Architecture logicielle --- Design patterns. --- Logiciels --- Development --- Développement. --- -681.3* / / / / / / / / / / / / / / / / / / / / / / / / / / / / --- 681.3*D2 --- 681.3*D210 --- 681.3*D210 Design: methodologies; representation (Software engineering) --- Design: methodologies; representation (Software engineering) --- 681.3*D2 Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Software, Computer --- Computer systems --- Computerwetenschap --- -Development --- Développement.
Choose an application
Moderne softwaresystemen worden steeds frequenter opgebouwd als composities van herbruikbare componenten. Dergelijke componentgebaseerde software promoot vaak eenvoudige syntactische interfaces om het bouwen van nieuwe composities zo eenvoudig mogelijk te maken. Hoewel deze componenten op syntactisch niveau gemakkelijk samen te stellen zijn tot nieuwe composities, blijken losgekoppelde componenten echter regelmatig semantisch van elkaar af te hangen. Dit is onder andere het geval bij composities met een gemeenschappelijke opslagplaats (shared repository) via dewelke componenten indirect data met elkaar kunnen delen. Typisch worden deze verborgen afhankelijkheden niet gecontroleerd tijdens de compilatie, en op die manier leiden inbreuken op deze afhankelijkheden in huidige softwaresystemen tot fouten tijdens de uitvoering. De hoofdbijdrage van deze thesis is een aanpak om in toepassingen met een gemeenschappelijke opslagplaats het aantal fouten tijdens de uitvoering sterk te reduceren. We hebben uitgebreid ervaring opgedaan met dergelijke toepassingen in twee toepassingsdomeinen: componentgebaseerde protocolstapels en web toepassingen. Deze ervaringen illustreren duidelijk dat gebroken data afhankelijkheden in dergelijke applicaties een relevant probleem zijn en dat de fouten die eruit voorkomen een belangrijke impact kunnen hebben op de robuustheid en veiligheid van de toepassing. Onze aanpak baseert zich op de formele verificatie van de geen gebroken data afhankelijkheden compositie eigenschap. De formele verificatie van deze eigenschap wordt bereikt in twee stappen. In een eerste stap verifiëren we statisch dat een gegeven compositie met deterministische controle overgangen voldoet aan de gewenste compositie eigenschap. Hiertoe worden de componenten uitgebreid met contracten die de interacties met de gemeenschappelijke opslagplaats beschrijven in een probleemspecifieke contracttaal. Vervolgens volgen twee statische verificatiestappen. Eerst wordt nagegaan of het opgestelde component contract overeenkomt met de implementatie van de component. Ten slotte wordt de compositie eigenschap geverifieerd, steunend op de contracten van de verschillende componenten binnen de compositie. In een tweede stap breiden we de verificatie van de gewenste compositie eigenschap uit naar toepassingen met reactieve controle overgangen. Hierbij wordt de statische verificatie aanpak voor deterministische systemen gecombineerd met verificatie tijdens de uitvoering. Om de statische verificatie mogelijk te maken met de reactieve controle overgangen, definiëren we een bovengrens voor het reactieve gedrag. We noemen dit de vooropgestelde interacties tussen de web gebruiker en de toepassing, en drukken dit protocol uit in een gelabelde toestandsmachine. Daarna verifiëren we statisch of een gegeven compositie voldoet aan de compositie eigenschap, onder de veronderstelling dat elke interactie tussen de web gebruiker en de toepassing deel uitmaakt van de vooropgestelde interactie tussen de web gebruiker en de toepassing. We gebruiken hiervoor de oplossing voorgesteld voor deterministische controle overgangen. Ten slotte gebruiken we de protocolverificatie mogelijkheden van een Web Application Firewall om te garanderen dat enkel web aanvragen die deel uitmaken van de vooropgestelde interactie de web toepassing bereiken. Zo garanderen we dat de geen gebroken data afhankelijkheden compositie eigenschap geldt in een gegeven compositie. Ten slotte hebben we de formele verificatie van de geen gebroken data afhankelijkheden eigenschap gevalideerd in een toepassing met deterministische controle overgangen en een toepassing met reactieve controle overgangen. De statische verificatie uit de eerste stap werd succesvol toegepast op de webmail toepassing GatorMail. GatorMail is een middelgrote, open-source toepassing en bevat in totaal meer dan 1350 interacties met de gemeenschappelijke opslagplaats. Daarnaast werd de combinatie van statische en dynamische verificatie succesvol toegepast op de Duke's Bookstore e-commerce toepassing. In beide validatie experimenten werd een beperkte annotatie- en verificatiekost gemeten. Bovendien illustreerden beide experimenten dat de voorgestelde aanpak lineair schaalt naar grotere, realistische softwaretoepassingen, dankzij de modulaire specificatie en verificatie. Modern software systems evolve towards modularly composed applications, in which existing software components are reused in new software compositions. Current component-based software systems often promote simple syntactical interfaces to make the wiring of components simple. In practice however, these loosely-coupled components sometimes tend to have semantical dependencies, for example by passing data to each other on a shared data repository as is the case in data-centered applications. Typically, these hidden semantical dependencies are not checked at compile-time and lead to run-time errors in current software systems. The main contribution of this thesis is an approach to reduce the number of run-time errors due to broken data dependencies in data-centered, component-based applications. We have built up extensive hands-on experience with such applications in two application domains: networking software and web applications. This experience shows that errors caused by broken data dependencies are important in practice. Our approach is based on the formal verification of a composition property, the no broken data dependencies property. This formal verification is achieved in two steps. In a first step, we statically verify the desired composition property in deterministic software compositions. To do so, each component of the composition is extended with a component contract, stating in a problem-specific contract language what the shared data interactions of the component are. These contracts are then verified in two steps. First, the compliance of the component's implementation with its contract is checked. Next, the different component contracts are used to verify the composition property in a given composition. In a second step, we extend the verification of the desired composition property towards reactive software systems by combining the static verification approach with run-time checking. Reactive systems are characterised by their non-terminating behaviour and perpetual interactions with their environment, as is for example the case in graphical user interfaces. In addition to the approach for deterministic compositions, the expected, reactive protocol between the client and the server is expressed in a labelled state machine. Next, we apply the earlier proposed solution to verify statically whether or not the desired property is violated in a given composition, while assuming that the actual interaction protocol complies with the expressed state machine. Finally, we use the run-time checking capabilities of a Web Application Firewall to guarantee that the incoming requests of a user's session adheres to the verified labelled state machine and thus that the no broken data dependencies composition property also holds in the given composition. Finally, we validated the formal verification of the no broken data dependencies composition property in both a deterministic and a reactive software composition. The static verification approach is successfully applied to the medium-sized open-source webmail application GatorMail, in which more than 1350 shared data interactions are present. In addition, the combination of static verification and run-time checking by means of a Web Application Firewall is validated in the Duke's BookStore application, a reactive e-commerce application. In both case studies, a limited annotation and verification overhead was measured, and they both illustrated that the presented solution is scalable to larger, real-life software applications thanks to the modular specification and verification process. Moderne softwaresystemen worden steeds frequenter opgebouwd als composities van herbruikbare componenten. Om het samenstellen te vereenvoudigen worden de componenten bij voorkeur zo gesoleerd mogelijk ontwikkeld, en bestaan er zo weinig mogelijk afhankelijkheden tussen de individuele componenten. In praktijk echter blijken er echter vaak verborgen afhankelijkheden te bestaan tussen de verschillende componenten. Het breken van deze afhankelijkheden bij een nieuwe compositie leidt vaak tot fouten tijdens de uitvoering. Deze fouten ondermijnen de betrouwbaarheid en veiligheid van dergelijke systemen. In deze thesis worden verborgen afhankelijkheden bestudeerd tussen componenten die indirect data met elkaar delen. Met behulp van formele specificatie en statische en dynamische verificatie worden voor een gegeven compositie mogelijke fouten tijdens de uitvoering gedetecteerd. Op die manier kunnen de fouten al vroeg in het ontwikkelingsproces voorkomen worden, en wordt een belangrijk deel van de fouten tijdens uitvoering gelimineerd. De voorgestelde oplossingen werden gevalideerd in middelgrote, bestaande applicaties.
Academic collection --- 681.3*D1 <043> --- 681.3*D2 <043> --- 681.3*D46 <043> --- Programming techniques--See also {681.3*E}--Dissertaties --- Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51}--Dissertaties --- Security and protection: access controls; authentication; cryptographic controls; information flow controls; security kernels; verification (Operating systems)--Dissertaties --- Theses --- 681.3*D46 <043> Security and protection: access controls; authentication; cryptographic controls; information flow controls; security kernels; verification (Operating systems)--Dissertaties --- 681.3*D2 <043> Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51}--Dissertaties --- 681.3*D1 <043> Programming techniques--See also {681.3*E}--Dissertaties
Choose an application
Computer software --- -681.3* / / / / / / / / / / / / / / / / / / / / / / / / / / / / --- 681.3*D2 --- 681.3*D211 --- 681.3*D33 --- 681.3*D33 Languages constructs: abstract data types; concurrent programming structures;control structures; coroutines (Programming languages) --- Languages constructs: abstract data types; concurrent programming structures;control structures; coroutines (Programming languages) --- 681.3*D2 Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Software, Computer --- Computer systems --- Development --- Computerwetenschap --- Software architectures: data abstractio, domain-specific architectures, information hiding, languages (e.g. description, interconnection, definition), patterns (e.g. client/server, pipeline, blackboard) --- -Development
Choose an application
Computer security --- Computer networks - Security measures --- Computer software - Testing --- Computer software - Reliability --- Computer networks --- Computer software --- 005.8 --- 681.3*D2 --- Software, Computer --- Computer systems --- Computer privacy --- Computer system security --- Computers --- Cyber security --- Cybersecurity --- Electronic digital computers --- Protection of computer systems --- Security of computer systems --- Data protection --- Security systems --- Hacking --- Computer network security --- Network security, Computer --- Security of computer networks --- 681.3*D2 Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Software engineering: protection mechanisms; standards--See also {681.3*K63}; {681.3*K51} --- Security measures --- Reliability --- Testing --- Protection
Listing 1 - 10 of 14 | << page >> |
Sort by
|