1 Introduction
Eventbased systems are an important kind of software systems which are open to the environment to react to certain events. A crucial characteristics of such systems is that not any event can (or should) be expected at any time. Hence the control flow of the system is significant and should be modelled by appropriate means. On the other hand components administrate data which may change upon the occurrence of an event. Thus also the specification of admissible data changes caused by events plays a major role.
There is quite a lot of literature on modelling and specification of eventbased systems. Many approaches, often underpinned by graphical notations, provide formalisms aiming at being constructive enough to suggest particular designs or implementations, like e.g., EventB [abrial:2013, farrellmonahanpower:wadt:2016], symbolic transition systems [poizatroyer:jucs:2006], and UML behavioural and protocol state machines [uml2.5, knappetal:fase:2015]. On the other hand, there are logical formalisms to express desired properties of eventbased systems. Among them are temporal logics integrating state and eventbased styles [terbeeketal:fmics:2007], and various kinds of modal logics involving data, like firstorder dynamic logic [harelkozentiuryn:2000] or the modal calculus with data and time [grootemousavi:2014]. The gap between logics and constructive specification is usually filled by checking whether the model of a constructive specification satisfies certain logical formulae.
In this paper we are interested in investigating a logic which is capable to express properties of event/databased systems on various abstraction levels in a common formalism. For this purpose we follow ideas of [madeiraetal:tcs:2018], but there data states, effects of events on them and constructive operational specifications (see below) were not considered. The advantage of an expressive logic is that we can split the transition from system requirements to system implementation into a series of gradual refinement steps which are more easy to understand, to verify, and to adjust when certain aspects of the system are to be changed or when a product line of similar products has to be developed.
To that end we propose logic, a dynamic logic enriched with features of hybrid logic. The dynamic part uses diamond and box modalities over structured actions. Atomic actions are of the form with an event and a state transition predicate specifying the admissible effects of on the data. Using sequential composition, union, and iteration we obtain complex actions that, in connection with the modalities, can be used to specify required and forbidden behaviour. In particular, if is a finite set of events, though data is infinite we are able to capture all reachable states of the system and to express safety and liveness properties. But logic is also powerful enough to specify concrete, recursive process structures by integrating state variables and binders from hybrid logic [braeuner:2010] with the subtle difference that our state variables are used to denote control states only. We show that the dynamic part of the logic is bisimulation invariant while the hybrid part, due to the ability to bind names to states, is not.
An axiomatic specification in is given by an event/data signature , with a set of events and a set of attributes to model local data states, and a set of sentences , called axioms, expressing requirements. For the semantic interpretation we use event/data transition systems (edts). Their states are reachable configurations where is a control state, recording the current state of execution, and is a local data state, i.e., a valuation of the attributes. Transitions between configurations are labelled by events. The semantics of a specification is “loose” in the sense that it consists of all edts satisfying the axioms of the specification. Such structures are called models of . Loose semantics allows us to define a simple refinement notion: refines to if the model class of is included in the model class of . We may also say that is an implementation of .
Our refinement process starts typically with axiomatic specifications whose axioms involve only the dynamic part of the logic. Hybrid features will successively be added in refinements when specifying more concrete behaviours, like loops. Aiming at a concrete design, the use of an axiomatic specification style may, however, become cumbersome since we have to state explicitly also all negative cases, what the system should not do. For a convenient presentation of constructive specifications we propose operational event/data specifications, which are a kind of symbolic transition systems equipped again with a model class semantics in terms of edts. We will show that logic, by use of the hybrid binder, is powerful enough to characterise the semantics of an operational specification. Therefore we have not really left logic when refining axiomatic by operational specifications. Moreover, since several constructive notations in the literature, including (essential parts of) EventB, symbolic transition systems, and UML protocol state machines, can be expressed as operational specifications, logic provides a logical umbrella under which event/databased systems can be developed.
In order to consider more complex refinements we take up an idea of Sannella and Tarlecki [DBLP:journals/acta/SannellaT88, sannellatarlecki:2012] who have proposed the notion of constructor implementation. This is a generic notion applicable to specification formalisms based on signatures and semantic structures for signatures. As both are available in the context of logic, we complement our approach by introducing a couple of constructors, among them event refinement and parallel composition. For the latter we provide a useful refinement criterion relying on a relationship between syntactic and semantic parallel composition. The logic and the use of the implementation constructors will be illustrated by a running example.
Hereafter, in Sect. 2, we introduce syntax and semantics of logic. In Sect. 3, we consider axiomatic as well as operational specifications and demonstrate the expressiveness of logic. Refinement of both types of specifications using several implementation constructors is considered in Sect. 4. Section 5 provides some concluding remarks. Proofs of theorems and facts can be found in App. 0.A.
2 A Hybrid Dynamic Logic for Event/Data Systems
We propose the logic to specify and reason about event/databased systems. logic is an extension of the hybrid dynamic logic considered in [madeiraetal:tcs:2018] by taking into account changing data. Therefore, we first summarise our underlying notions used for the treatment of data. We then introduce the syntax and semantics of with its hybrid and dynamic logic features applied to events and data.
2.1 Data States
We assume given a universe of data values. A data signature is given by a set of attributes. An data state is a function . We denote by the set of all data states. For any data signature , we assume given a set of state predicates to be interpreted over single data states, and a set of transition predicates to be interpreted over pairs of pre and postdata states. The concrete syntax of state and transition predicates is of no particular importance for the following. For an attribute , a state predicate may be ; and a transition predicate e.g. , where refers to the value of attribute in the predata state and to its value in the postdata state. Still, both types of predicates are assumed to contain and to be closed under negation (written ) and disjunction (written ); as usual, we will then also use , , etc. Furthermore, we assume for each a transition predicate expressing that the values of attributes in are the same in pre and postdata states.
We write if is satisfied in data state ; and if is satisfied in the predata state and postdata state . In particular, if, and only if, for all .
2.2 Logic
Definition 1
An event/data signature (ed signature, for short) consists of a finite set of events and a data signature . We write for and for . We also write for , for , and for . The class of ed signatures is denoted by .
Any ed signature determines a class of semantic structures, the event/data transition systems which are reachable transition systems with sets of initial states and events as labels on transitions. The states are pairs , called configurations, where is a control state recording the current execution state and is an data state; we write for and for .
Definition 2
A event/data transition system (edts, for short) over an ed signature consists of a set of configurations for a set of control states ; a family of transition relations ; and a nonempty set of initial configurations for an initial control state and a set of initial data states such that is reachable via , i.e., for all there are , , , and for all with . We write for , for , for , for , for , and for . The class of edts is denoted by .
Atomic actions are given by expressions of the form with an event and a state transition predicate. The intuition is that the occurrence of the event causes a state transition in accordance with , i.e., the pre and postdata states satisfy , and specifies the possible effects of . Following the ideas of dynamic logic we also use complex, structured actions formed over atomic actions by union, sequential composition and iteration. All kinds of actions over an ed signature are called event/data actions (ed actions, for short). The set of ed actions is defined by the grammar
where and . We use the following shorthand notations for actions: For a subset , we use the notation to denote the complex action and to denote the action . For the action we will write . For , we use the notation to denote the action and to denote the action . Hence, if and , the action stands for .
The actions are interpreted over a edts as the family of relations defined by

[leftmargin=*, topsep=3pt, itemsep=1pt]

,

, i.e., union of relations,

, i.e., sequential composition of relations,

, i.e., reflexivetransitive closure of relations.
To define the event/data formulae of we assume given a countably infinite set of control state variables which are used in formulae to denote the control part of a configuration. They can be bound by the binder operator and accessed by the jump operator of hybrid logic. The dynamic part of our logic is due to the modalities which can be formed over any ed action over a given ed signature. thus retains from hybrid logic the use of binders, but omits free nominals. Thus sentences of the logic become restricted to express properties of configurations reachable from the initial ones.
Definition 3
The set of ed formulae over an ed signature is given by
where , , and . We write for and we use the usual boolean connectives as well as the constant to denote .^{1}^{1}1We use and for predicates and formulae; their meaning will always be clear from the context. For boolean values we will use instead the notations and . The set of ed sentences consists of all ed formulae without free variables, where the free variables are defined as usual with being the unique operator binding variables.
Given an ed signature and a edts , the satisfaction of a ed formula is inductively defined w.r.t. valuations , mapping variables to control states, and configurations :

[leftmargin=*, topsep=2pt]

iff ;

iff ;

iff ;

iff for all with ;

iff for some with ;

always holds;

iff ;

iff or .
If is a sentence then the valuation is irrelevant. satisfies a sentence , denoted by , if for all .
By borrowing the modalities from dynamic logic [harelkozentiuryn:2000, grootemousavi:2014], is able to express liveness and safety requirements as illustrated in our running ATM example below. There we use the fact that we can state properties over all reachable states by sentences of the form . In particular, deadlockfreedom can be expressed by . The logic , however, is also suited to directly express process structures and, thus, the implementation of abstract requirements. The binder operator is essential for this. For example, we can specify a process which switches a boolean value, denoted by the attribute , from to and back by the following sentence:
2.3 Bisimulation and Invariance
Bisimulation is a crucial notion in both behavioural systems specification and in modal logics. On the specification side, it provides a standard way to identify systems with the same behaviour by abstracting the internal specifics of the systems; this is also reflected at the logic side, where bisimulation frequently relates states that satisfy the same formulae. We explore some properties of w.r.t. bisimilarity. Let us first introduce the notion of bisimilarity in the context of :
Definition 4
Let be edts. A relation is a bisimulation relation between and if for all the following conditions hold:

[leftmargin=*, topsep=0pt, partopsep=0pt, label=(atom), ref=atom]

for all , iff ;

[leftmargin=*, topsep=0pt, partopsep=0pt, label=(zig), ref=zig]

for all and for all with , there is a such that and ;

[leftmargin=*, topsep=0pt, partopsep=0pt, label=(zag), ref=zag]

for all and for all with , there is a such that and .
and are bisimilar, in symbols , if there exists a bisimulation relation between and such that

[leftmargin=*, topsep=2pt, partopsep=0pt, label=(init), ref=init]

for any , there is a such that and for any , there is a such that .
Now we are able to establish a HennessyMilner like correspondence for a fragment of . Let us call hybridfree sentences of the formulae obtained by the grammar
Theorem 2.1
Let be bisimilar edts. Then iff for all hybridfree sentences .
The converse of Thm. 2.1 does not hold, in general, and the usual imagefiniteness assumption has to be imposed: A edts is imagefinite if, for all and all , the set is finite. Then:
Theorem 2.2
Let be imagefinite edts and , such that iff for all hybridfree sentences . Then there exists a bisimulation between and such that .
3 Specifications of Event/Data Systems
3.1 Axiomatic Specifications
Sentences of logic can be used to specify properties of event/data systems and thus to write system specifications in an axiomatic way.
Definition 5
An axiomatic ed specification in consists of an ed signature and a set of axioms .
The semantics of is given by the pair where . The edts in are called models of and is the model class of .
As a direct consequence of Thm. 2.1 we have:
Corollary 1
The model class of an axiomatic ed specification exclusively expressed by hybridfree sentences is closed under bisimulation.
This result does not hold for sentences with hybrid features. For instance, consider the specification : An edts with a single control state and a loop transition for is a model of . However, this is obviously not the case for its bisimilar edts with two control states and and the relation with , and .
Example 1
As a running example we consider an ATM. We start with an abstract specification of fundamental requirements for its interaction behaviour based on the set of events ^{2}^{2}2For shortening the presentation we omit further events like withdrawing money, etc. and on the singleton set of attributes where is boolean valued and records the correctness of an entered PIN. Hence our first ed signature is and where requires the following properties expressed by corresponding axioms Eqs. 0.1 to 0.3:

[leftmargin=*, topsep=2pt]

“Whenever a card has been inserted, a correct PIN can eventually be entered and also the transaction can eventually be cancelled.”
(0.1) 
“Whenever either a correct PIN has been entered or the transaction has been cancelled, the card can eventually be ejected.”
(0.2) 
“Whenever an incorrect PIN has been entered three times in a row, the current card is not returned.” This means that the card is kept by the ATM which is not modelled by an extra event. It may, however, still be possible that another card is inserted afterwards. So an can only be forbidden as long as no next card is inserted.
(0.3) where abbreviates the fold sequential composition .
The semantics of an axiomatic ed specification is loose allowing usually for many different realisations. A refinement step is therefore understood as a restriction of the model class of an abstract specification. Following the terminology of Sannella and Tarlecki [DBLP:journals/acta/SannellaT88, sannellatarlecki:2012], we call a specification refining another one an implementation. Formally, a specification is a simple implementation of a specification over the same signature, in symbols , whenever . Transitivity of the inclusion relation ensures gradual stepbystep development by a series of refinements.
Example 2
We provide a refinement where has the same signature as and are the sentences Eqs. 1.1 to 1.4 below; the last two use binders to specify a loop. As is easily seen, all models of must satisfy the axioms of .

[leftmargin=*, topsep=2pt]

“At the beginning a card can be inserted with the effect that is set to ; nothing else is possible at the beginning.”
(1.1) 
“Whenever a card has been inserted, a PIN can be entered (directly afterwards) and also the transaction can be cancelled; but nothing else.”
(1.2) 
“Whenever either a correct PIN has been entered or the transaction has been cancelled, the card can eventually be ejected and the ATM starts from the beginning.”
(1.3) 
“Whenever an incorrect PIN has been entered three times in a row the ATM starts from the beginning.” Hence the current card is kept.
(1.4)
3.2 Operational Specifications
Operational event/data specifications are introduced as a means to specify in a more constructive style the properties of event/data systems. They are not appropriate for writing abstract requirements for which axiomatic specifications are recommended. Though logic is able to specify concrete models, as discussed in Sect. 2, the use of operational specifications allows a graphic representation close to familiar formalisms in the literature, like UML protocol state machines, cf. [uml2.5, knappetal:fase:2015]. As will be shown in Sect. 3.3, finite operational specifications can be characterised by a sentence in logic. Therefore, logic is still the common basis of our development approach. Transitions in an operational specification are tuples with a source control state, a precondition, an event, a state transition predicate specifying the possible effects of the event , and a target control state. In the semantic models an event must be enabled whenever the respective source data state satisfies the precondition. Thus isolating preconditions has a semantic consequence that is not expressible by transition predicates only. The effect of the event must respect ; no other transitions are allowed.
Definition 6
An operational ed specification is given by an ed signature , a set of control states , a transition relation specification , an initial control state , and an initial state predicate , such that is syntactically reachable, i.e., for every there are with such that . We write for , etc.
A edts is a model of if up to a bijective renaming, , , and if the following conditions hold:

[leftmargin=*, topsep=2pt]

for all and with , there is a with ;

for all there is a with and .
The class of all models of is denoted by . The semantics of is given by the pair where .
Example 3
We construct an operational ed specification, called , for the ATM example. The signature of extends the one of (and ) by an additional integervalued attribute which counts the number of attempts to enter a correct PIN (with the same card). is graphically presented in Fig. 1. The initial control state is , and the initial state predicate is . Preconditions are written before the symbol . If no precondition is explicitly indicated it is assumed to be . Due to the extended signature, is not a simple implementation of , and we will only formally justify the implementation relationship in Ex. 5.
Operational specifications can be composed by a syntactic parallel composition operator which synchronises shared events. Two ed signatures and are composable if . Their parallel composition is given by .
Definition 7
Let and be composable ed signatures and let and be operational ed specifications with and . The parallel composition of and is given by the operational ed specification with , , and and are inductively defined by and

[leftmargin=*, topsep=2pt]

for , , and , if and , then and ;

for , , and , if and , then and ;

for , , and , if , , and , then and .^{3}^{3}3 Note that joint moves with cannot become inconsistent due to composability of ed signatures.
3.3 Expressiveness of Logic
We show that the semantics of an operational ed specification with finitely many control states can be characterised by a single sentence , i.e., an edts is a model of iff .
Using Alg. 1, such a characterising sentence is
where and . Algorithm 1 closely follows the procedure in [madeiraetal:tcs:2018] for characterising a finite structure by a sentence of logic. A call performs a recursive breadthfirst traversal through starting from , where holds the unprocessed quadruples of transitions outgoing from , the remaining states to visit, and the set of already bound states. The function first requires the existence of each outgoing transition of , provided its precondition holds, in the resulting formula, binding any newly reached state. Then it requires that no other transitions with source state exist using calls to . Having visited all states in , it finally requires all states in to be pairwise different.
It is where this algorithm mainly deviates from [madeiraetal:tcs:2018]: To ensure that no other transitions from exist than those specified in , produces the requirement that at state , for every event and for every subset of the transitions outgoing from , whenever an transition can be done with the combined effect of but not adhering to any of the effects of the currently not selected transitions, the transition must have one of the states as its target that are target states of . The rather complicated formulation is due to possibly overlapping preconditions where for a single event the preconditions of two different transitions may be satisfied simultaneously. For a state , where all outgoing transitions for the same event have disjoint preconditions, the formula returned by is equivalent to
Example 4
We show the first few steps of representing the operational ed specification of Fig. 1 as an sentence . This toplevel sentence is
The first call of explores the single outgoing transition from to , adds to the bound states, and hence expands to
Now all outgoing transitions from have been explored and the next call of removes from the set of states to be visited, resulting in
As there is only a single outgoing transition from , the special case of disjoint preconditions applies for the finalisation call, and results in
4 Constructor Implementations
The implementation notion defined in Sect. 3.1 is too simple for many practical applications. It requires the same signature for specification and implementation and does not support the process of constructing an implementation. Therefore, Sannella and Tarlecki [DBLP:journals/acta/SannellaT88, sannellatarlecki:2012] have proposed the notion of constructor implementation which is a generic notion applicable to specification formalisms which are based on signatures and semantic structures for signatures. We will reuse the ideas in the context of logic.
The notion of constructor is the basis: for signatures , a constructor from to is a (total) function . Given a constructor from to and a set of constructors from to , , the constructor from to is obtained by the usual composition of functions. The following definitions apply to both axiomatic and operational ed specifications since the semantics of both is given in terms of ed signatures and model classes of edts. In particular, the implementation notion allows to implement axiomatic specifications by operational specifications.
Definition 8
Given specifications and a constructor from to , the tuple is a constructor implementation via of , in symbols , if for all we have The implementation involves a decomposition if .
The notion of simple implementation in Sect. 3.1 is captured by choosing the identity. We now introduce a set of more advanced constructors in the context of ed signatures and edts. Let us first consider two central notions for constructors: signature morphisms and reducts. For data signatures a data signature morphism is a function from to . The reduct of an data state is given by the data state defined by for every . If , the injection of into is a particular data signature morphism and we denote the reduct of an data state to by . If is the disjoint union of and and are data states for then denotes the unique data state with for . The reduct of a configuration is given by , and is lifted to a set of configurations by
Comments
There are no comments yet.