Monitoring-Oriented Programming: A Tool-Supported Methodology for Higher Quality Object-Oriented Software

This paper presents a tool-supported methodological paradigm for object-oriented software development, called monitoring-oriented programming and abbreviated MOP, in which runtime monitoring is a basic software design principle. The general idea underlying MOP is that software developers insert specifications in their code via annotations. Actual monitoring code is automatically synthesized from these annotations before compilation and integrated at appropriate places in the program, according to user-defined configuration attributes. This way, the specification is checked at runtime against the implementation. Moreover, violations and/or validations of specifications can trigger user-defined code at any points in the program, in particular recovery code, outputting or sending messages, or raising exceptions. The MOP paradigm does not promote or enforce any specific formalism to specify requirements: it allows the users to plug-in their favorite or domain-specific specification formalisms via logic plug-in modules. There are two major technical challenges that MOP supporting tools unavoidably face: monitor synthesis and monitor integration. The former is heavily dependent on the specification formalism and comes as part of the corresponding logic plug-in, while the latter is uniform for all specification formalisms and depends only on the target programming language. An experimental prototype tool, called Java-MOP, is also discussed, which currently supports most but not all of the desired MOP features. MOP aims at reducing the gap between formal specification and implementation, by integrating the two and allowing them together to form a system

Distributed Real-Time Emulation of Formally-Defined Patterns for Safe Medical Device Control

Safety of medical devices and of their interoperation is an unresolved issue causing severe and sometimes deadly accidents for patients with shocking frequency. Formal methods, particularly in support of highly reusable and provably safe patterns which can be instantiated to many device instances can help in this regard. However, this still leaves open the issue of how to pass from their formal specifications in logical time to executable emulations that can interoperate in physical time with other devices and with simulations of patient and/or doctor behaviors. This work presents a specification-based methodology in which virtual emulation environments can be easily developed from formal specifications in Real-Time Maude, and can support interactions with other real devices and with simulation models. This general methodology is explained in detail and is illustrated with two concrete scenarios which are both instances of a common safe formal pattern: one scenario involves the interaction of a provably safe pacemaker with a simulated heart; the other involves the interaction of a safe controller for patient-induced analgesia with a real syringe pump.Comment: In Proceedings RTRTS 2010, arXiv:1009.398

A viabilidade de Dart em desenvolvimento full stack: um estudo de caso

In 2012, Google released the Dart language which, more recently, due to Flutter, has received a boost in popularity and is being often referred to as a full-stack language / ecosystem suitable for developing front-end and back-end solutions. However, aside from Flutter for mobile, Dart usage is still quite low when it comes to developing enterprise level solutions. In this dissertation, we tried to investigate the adequacy of using Dart to develop a full-stack solution with special focus on its back-end support. With that in mind, a typical scenario involving both a mobile and a web-supported front end, where both communicate with a back-end server via a REST endpoint, was established. For performance comparison, we deployed an equivalent back-end server developed using Spring Boot, a popular Java-based solution, which was used as reference. The main result was that a full-stack system can be developed with just a Dart / Flutter ecosystem and, in our scenario, this system’s performance surpassed Spring Boot’s. From a developer’s perspective, off-the-shelf Dart embedded asynchronous solutions (e.g., streams, Futures, etc.) are clearly an improvement over similar mechanisms in Java / Spring Boot due to avoiding typical Java solutions, namely asynchronous configurations, and annotations. However, despite some interesting projects arising, when excluding Google’s own developed packages/resources, most third-party packages are either using out-of-date dependencies due to compatibility issues or have been abandoned entirely – this had an impact during the development stage as it led to unplanned constraints when choosing packages and / or frameworks used.Em 2012, Google lançou a linguagem Dart que, mais recentemente, devido ao Flutter, recebeu um impulso em popularidade e é muitas vezes referida como uma linguagem / ecossistema full stack adequado para o desenvolvimento de soluções front end e back end. No entanto, além do Flutter para dispositivos móveis, o uso de Dart ainda é muito baixo quando se trata de desenvolver soluções de nível corporativo. Nesta dissertação, tentamos investigar a adequação do uso de Dart para desenvolver uma solução full stack com foco especial no seu suporte de back end. Com isso em mente, foi estabelecido um cenário típico envolvendo um front end móvel e um compatível com web, em que ambos comunicam com um servidor back end por meio de um endpoint REST. Para comparação de desempenho, implementamos um servidor back end equivalente desenvolvido usando Spring Boot, uma solução popular baseada em Java, que foi usada como referência. O resultado principal foi que um sistema full stack pode ser desenvolvido com apenas um ecossistema Dart / Flutter e, no nosso cenário, o desempenho desse sistema ultrapassou o Spring Boot. Do ponto de vista do programador, soluções assíncronas incorporadas Dart prontas para uso (por exemplo, streams, Futures, etc.) são claramente uma melhoria em relação a mecanismos semelhantes em Java / Spring Boot devido a evitarem soluções Java típicas, nomeadamente configurações assíncronas e anotações. No entanto, apesar de alguns projetos interessantes surgirem, ao excluir os pacotes / recursos desenvolvidos pela própria Google, a maioria dos pacotes desenvolvidos por terceiros usam dependências desatualizadas devido a problemas de compatibilidade ou foram abandonados inteiramente - isso teve um impacto durante a fase de desenvolvimento, pois levou a restrições não planeadas na escolha de pacotes e / ou frameworks usados.Mestrado em Engenharia de Computadores e Telemátic

Fluent temporal logic for discrete-time event-based models

Fluent model checking is an automated technique for verifying that an event-based operational model satisfies some state-based declarative properties. The link between the event-based and state-based formalisms is defined through fluents which are state predicates whose value are determined by the occurrences of initiating and terminating events that make the fluents values become true or false, respectively. The existing fluent temporal logic is convenient for reasoning about untimed event-based models but difficult to use for timed models. The paper extends fluent temporal logic with temporal operators for modelling timed properties of discrete-time event-based models. It presents two approaches that differ on whether the properties model the system state after the occurrence of each event or at a fixed time rate. Model checking of timed properties is made possible by translating them into the existing untimed framework. Copyright 2005 ACM

Safety-Critical Java on a Java Processor

The safety-critical Java (SCJ) specification is developed within the Java Community Process under specification request number JSR 302. The specification is available as public draft, but details are still discussed by the expert group. In this stage of the specification we need prototype implementations of SCJ and first test applications that are written with SCJ, even when the specification is not finalized. The feedback from those prototype implementations is needed for final decisions. To help the SCJ expert group, a prototype implementation of SCJ on top of the Java optimized processor is developed and presented in this paper. This implementation raises issues in the SCJ specification and provides feedback to the expert group

Machine Protection and Operation for LHC

Since 2010 the Large Hadron Collider (LHC) is the accelerator with the highest stored energy per beam, with a record of 140 MJ at a beam energy of 4 TeV, almost a factor of 50 higher than other accelerators. With such a high stored energy, machine protection aspects set the boundary conditions for operation during all phases of the machine cycle. Only the low-intensity commissioning beams can be considered as relatively safe. This document discusses the interplay of machine operation and machine protection at the LHC, from commissioning to regular operation.Comment: 25 pages, contribution to the 2014 Joint International Accelerator School: Beam Loss and Accelerator Protection, Newport Beach, CA, USA , 5-14 Nov 201