Eerke Boiten

De Montfort University, Computer Science and Informatics, Faculty Member

University of Kent, Computing, Faculty Member

Followers

158

Following

Co-authors

Public Views

After his PhD in the Netherlands, Eerke Boiten worked at the University of Kent as a computer science researcher and academic from 1995 to 2017. Initially working in a foundational area of computing, he branched out into computer security 10 years ago. He set up and led the University's interdisciplinary Research Centre in Cyber Security, which achieved the EPSRC/GCHQ accreditation as an Academic Centre of Excellence in 2015. Looking beyond just his own discipline, Eerke developed an interest in the policy sides of big data from a perspective of technical realism. He engages in public debate in this area, including on privacy in general. In April 2017, he moved to the Cyber Technology Institute at De Montfort University to take on the role of Professor of Cyber Security.

less

Jonathan Zittrain

Harvard University

Beat Signer

Vrije Universiteit Brussel

Julita Vassileva

University of Saskatchewan

John F Dooley

Knox College

Antoine Meyer

Université Gustave Eiffel

Roshan Chitrakar

Nepal College of Information Technology

Lev Manovich

Graduate Center of the City University of New York

Dr. Shadab Alam

Jazan University

PALIMOTE JUSTICE

RIVERS STATE POLYTECHNIC

Ferhat Bozkurt

Ataturk University

Interests

Uploads

Papers by Eerke Boiten

Relating Data Refinement and Failures-Divergences Refinement

Chapter 9 discussed the general approach to relating process refinement and relational refinement... more Chapter 9 discussed the general approach to relating process refinement and relational refinement by developing a relational framework general enough that we could embed some of the refinement relations we discussed in Chap. 1. This included a brief discussion of the simulation rules that arise in the context of failures refinement (see Sect. 9.3.3). In this chapter we consider failures refinement in more depth, and in particular start to discuss the role that inputs and outputs have in a relational framework and how they correspond to aspects of divergence and refusals.

Promotion

Springer eBooks, 2014

Simple State-Based Refinement

One central distinction in formal methods is between those based on state, and those based on beh... more One central distinction in formal methods is between those based on state, and those based on behaviour. In most applications it is essential or at least practical to have both. State based systems need behavioural elements in order to consider aspects of interaction with an environment, for example to record which changes of state are due to the system’s ongoing execution and which are in response to an externally provided stimulus. Behaviour based systems can use state and data for abstraction, for example recording the number of free spaces as a number instead of a behaviour that encodes directly how many allocation operations will still succeed. The rich research field of “integrated formal methods” considers formalisms that have both, through extensions or integration of different formalisms. We will return in detail to these issues in Chap. 9 and on. The models we have looked at so far concentrate on behaviour, and states are fully characterised by the behaviour that will be possible from that point on. Observing only the (possible) behaviour tells us everything there is to know in a LTS. In this chapter we will look at a different class of elementary models that take the complementary view. What we will be observing is states rather than behaviours; and behaviour will be implicit, in the sense that we have to draw the conclusion that “something must have happened” if we can observe that the state has changed. We observe what “is”, not directly what “happens”.

Labeled Transition Systems and Their Refinement

On purpose we start with one of the simplest models of computation, that given by labeled transit... more On purpose we start with one of the simplest models of computation, that given by labeled transition systems. After introducing the reader to this simple set up we start to explore what refinement might mean, beginning with trace refinement, then adding in various notions such as refusals, so that each refinement relation we introduce is more discriminating than the last. The most discriminating of all, bisimulation, will then be introduced in Chap. 2. The material in this chapter serves as the foundation of refinement in process algebras such as CSP, CCS and LOTOS which we consider in Chap. 6.

Relational Concurrent Refinement - Partial and Total Frameworks

Data refinement as found in a state-based language such as Z or B, and refinement as defined in a... more Data refinement as found in a state-based language such as Z or B, and refinement as defined in a process algebra may appear as very different notions. Data refinement is defined using a relational model in terms of the behaviour of abstract programs, whereas in models of concurrency, refinement is often defined in terms of sets of observations. The methodologies used to verify them are also different: downward and upward simulations for data-refinement, whereas calculation of traces, refusals etc from the semantics is prevalent in a process algebra. In this chapter we discuss work undertaken to reconcile the two approaches. Specifically, we show how one can embed concurrent semantics into a relational framework. This not only articulates the relationship between the two, but allows event-wise verification methods for concurrent refinement relations to be derived. We discuss how this can be achieved, with particular emphasis on the type of relational model used - specifically whether one uses a model containing total relations, or one in which relations may be partial. Both are shown to have limits in expressiveness, and because of this we introduce a more general framework for simulations, called process data types

Process Algebra

Grey Box Data Refinement

Springer eBooks, Sep 1, 1998

We introduce the concepts of grey box and display box data types. These make explicit the idea th... more We introduce the concepts of grey box and display box data types. These make explicit the idea that state variables in abstract data types are not always hidden. Programming languages have visibility rules which make representations observable and modi able. Speci cations in model-based notations may have implicit assumptions about visible state components, or are used in contexts where the representation does matter. Grey box data types are like the \standard" black box data types, except that they contain explicit subspaces of the state which are modiable and observable. Display boxes indirectly observe the state by adding displays to a black box. Re nement rules for both these alternative data types are given, based on their interpretations as black boxes.

Eerke Boiten

Related Authors

Uploads

Papers by Eerke Boiten

Log In