Robert Rubbens

dblp:299/8369 · also Bob Rubbens · DBLP profile ↗
← Back
6ranked-venue papers
3as first author
6since 2021 · last 2025
0000-0002-5638-5945ORCID · verified

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 5 · 2 first-author · 5 since 2021Theory of computation · 2 · 1 first-author · 2 since 2021
YearPublicationVenuePosition
2025 Verified Parameterized Choreographies
Robert Rubbens, Petra van den Bos, Marieke Huisman
COORDINATION1
2024 The VerCors Verifier: A Progress Report
abstract
Abstract This paper gives an overview of the most recent developments on the VerCors verifier. VerCors is a deductive verifier for concurrent software, written in multiple programming languages, where the specifications are written in terms of pre-/postcondition contracts using permission-based separation logic. In essence, VerCors is a program transformation tool: it translates an annotated program into input for the Viper framework, which is then used as verification back-end. The paper discusses the different programming languages and features for which VerCors provides verification support. It also discusses how the tool internally has been reorganised to become easily extendible, and to improve the connection and interaction with Viper. In addition, we also introduce two tools built on top of VerCors, which support correctness-preserving transformations of verified programs. Finally, we discuss how the VerCors verifier has been used on a range of realistic case studies.
Lukas Armborst, Pieter Bos, Lars B. van den Haak, Marieke Huisman, Robert Rubbens, Ömer Sakar, Philip Tasche
CAV (2)5
2024 VeyMont: Choreography-Based Generation of Correct Concurrent Programs with Shared Memory
Robert Rubbens, Petra van den Bos, Marieke Huisman
IFM1
2023 JavaBIP meets VerCors: Towards the Safety of Concurrent Software Systems in Java
abstract
Abstract We present “Verified JavaBIP”, a tool set for the verification of JavaBIP models. A JavaBIP model is a Java program where classes are considered as components, their behaviour described by finite state machine and synchronization annotations. While JavaBIP guarantees execution progresses according to the indicated state machines, it does not guarantee properties of the data exchanged between components. It also does not provide verification support to check whether the behaviour of the resulting concurrent program is as (safe as) expected. This paper addresses this by extending the JavaBIP engine with run-time verification support, and by extending the program verifier VerCors to verify JavaBIP models deductively. These two techniques complement each other: feedback from run-time verification allows quicker prototyping of contracts, and deductive verification can reduce the overhead of run-time verification. We demonstrate our approach on the “Solidity Casino” case study, known from the VerifyThis Collaborative Long Term Challenge.
Simon Bliudze, Petra van den Bos, Marieke Huisman, Robert Rubbens, Larisa Safina
FASE4
2022 On Deductive Verification of an Industrial Concurrent Software Component with VerCors
abstract
Abstract This paper presents a case study where a concurrent module of a tunnel control system written in Java is verified for memory safety and data race freedom using VerCors, a software verification tool. This case study was carried out in close collaboration with our industrial partner Technolution, which is in charge of developing the tunnel control software. First, we describe the process of preparing the code for verification, and how we make use of the different capabilities of VerCors to successfully verify the module. The concurrent module has gone through a rigorous process of design, code reviewing and unit and integration testing. Despite this careful approach, VerCors found two memory related bugs. We describe these bugs, and show how VerCors could have found them during the development process. Second, we wanted to communicate back our results and verification process to the engineers of Technolution. We discuss how we prepared our presentation, and the explanation we settled on. Third, we present interesting feedback points from this presentation. We use this feedback to determine future work directions with the goal to improve our tool support, and to bridge the gap between formal methods and industry.
Raúl E. Monti, Robert Rubbens, Marieke Huisman
ISoLA (1)2
2021 Modular Transformation of Java Exceptions Modulo Errors
Robert Rubbens, Sophie Lathouwers, Marieke Huisman
FMICS1