An Abstract Contract Theory for Programs with Procedures
aa r X i v : . [ c s . L O ] J a n An Abstract Contract Theory forPrograms with Procedures
Full Version ∗Christian Lidström and Dilian Gurov
KTH Royal Institute of Technology, Stockholm, Sweden
January 19, 2021
Abstract
When developing complex software and systems, contracts providea means for controlling the complexity by dividing the responsibilitiesamong the components of the system in a hierarchical fashion. In spe-cific application areas, dedicated contract theories formalise the notionof contract and the operations on contracts in a manner that supportsbest the development of systems in that area. At the other end, con-tract meta-theories attempt to provide a systematic view on the vari-ous contract theories by axiomatising their desired properties. However,there exists a noticeable gap between the most well-known contract meta-theory of Benveniste et al [5], which focuses on the design of embeddedand cyber-physical systems, and the established way of using contractswhen developing general software, following Meyer’s design-by-contractmethodology [17]. At the core of this gap appears to be the notion of pro-cedure : while it is a central unit of composition in software development,the meta-theory does not suggest an obvious way of treating proceduresas components.In this paper, we provide a first step towards a contract theory thattakes procedures as the basic building block, and is at the same time aninstantiation of the meta-theory. To this end, we propose an abstract con-tract theory for sequential programming languages with procedures, basedon denotational semantics . We show that, on the one hand, the specifica-tion of contracts of procedures in
Hoare logic , and their procedure-modularverification, can be cast naturally in the framework of our abstract con-tract theory. On the other hand, we also show our contract theory to fulfilthe axioms of the meta-theory. In this way, we give further evidence for ∗ This is the full version of the paper
An Abstract Contract Theory for Programs withProcedures , to appear in the
Proceedings of the 24th International Conference on FundamentalApproaches to Software Engineering (FASE 2021), which includes the proofs of all theoremsand additional examples. The conference version should always be cited. he utility of the meta-theory, and prepare the ground for combining ourinstantiation with other, already existing instantiations. Contracts.
Loosely speaking, a contract for a software or system componentis a means of specifying that the component obliges itself to guarantee a certainbehaviour or result, provided that the user (or client) of the component obligesitself to fulfil certain constraints on how it interacts with the component.One of the earliest inspirations for the notion of software contracts camefrom the works of Floyd [10] and Hoare [15]. One outcome of this was
Hoarelogic , which is a way of assigning meaning to sequential programs axiomati-cally , through so-called Hoare triples. A Hoare triple { P } S { Q } consists of twoassertions P and Q over the program variables, called the pre-condition andpost-condition, respectively, and a program S . The triple states that if thepre-condition P holds prior to executing S , then, if execution of S terminates,the post-condition Q will hold upon termination. With the help of additional,so-called logical variables , one can specify, with a Hoare triple, the desired rela-tionship between the final values of certain variables (such as the return value ofa procedure) and the initial values of certain other variables (such as the formalparameters of the procedure).This style of specifying contracts has been advocated by Meyer [17], togetherwith the design methodology Design-by-Contract. A central characteristic ofthis methodology is that it is well-suited for independent implementation andverification , where software components are developed independently from eachother, based solely on the contracts, and without any knowledge of the imple-mentation details of the other components. Contract Theories.
Since then, many other contract theories have emerged,such as Rely/Guarantee reasoning [16, 21] and a number of Assume/Guaran-tee contract theories [4, 6]. A contract theory typically formalises the notionof contract, and develops a number of operations on contracts that supporttypical design steps. This in turn has lead to a few developments of contract meta-theories (e.g. [5, 2, 8]), which aim at unifying these, in many cases in-compatible, contract theories. The most comprehensive, and well-known, ofthese, is presented in Benveniste et al [5], and is concerned specifically with thedesign of cyber-physical systems. Here, all properties are derived from a mostabstract notion of a contract. The meta-theory focuses on the notion of contract refinement , and the operations of contract conjunction and composition . Theintention behind refinement and composition is to support a top-down designflow, where contracts are decomposed iteratively into sub-contracts; the taskis then to show that the composition of the sub-contracts refines the originalcontract. These operations are meant to enable independent development and reuse of components. In addition, the operation of conjunction is intended toallow the superimposition of contracts over the same component, when they2oncern different aspects of its behaviour. This also enables component reuse ,by allowing contracts to reveal only the behaviour relevant to the different usecases.
Motivation and Contribution.
The meta-theory of Benveniste et al focuseson the design of embedded and cyber-physical systems. However, there exists anoticeable gap between this meta-theory and the way contracts are used whendeveloping general software following Meyer’s design-by-contract methodology.At the core of this gap appears to be the notion of procedure . While theprocedure is a central unit of composition in software development, the meta-theory does not suggest an obvious way of treating procedures as components.This situation is not fully satisfactory, since the software components of mostembedded systems are implemented with the help of procedures (a typical C-module, for instance, would consist of a main function and a number of helper functions), and their development should ideally follow the same design flow asthat of the embedded system as a whole.In this paper we provide a first step towards a contract theory that takes pro-cedures as the basic building block, and at the same time respects the axioms ofthe meta-theory. Our contract theory is abstract, so that it can be instantiatedto any procedural language, and similarly to the meta-theory, is presented at thesemantics level only. Then, in the context of a simplistic imperative program-ming language with procedures and its denotational semantics, we show thatthe specification of contracts of procedures in Hoare logic , and their procedure-modular verification, can be cast in the framework of our abstract contracttheory. We also show that our contract theory is an instance of the meta-theoryof Benveniste et al. With this we expect to contribute to the bridging of thegap mentioned above, and to give a formal justification of the design methodol-ogy supported by the meta-theory, when applied to the software components ofembedded systems. Several existing contract theories have already been shownto instantiate the meta-theory. In providing a contract theory for proceduralprograms that also instantiates it, we increase the value of the meta-theory byproviding further evidence for its universality. In addition, we prepare the the-oretical ground for combining our instantiation with other instantiations, whichmay target components not to be implemented in software.Our theoretical development should be seen as a proof-of-concept. In futurework it will need to be extended to cover more programming language features,such as object orientation, multi-threading, and exceptions.
Related Work.
Software contracts and operations on contracts have longbeen an area of intensive research, as evidenced, e.g., by [1]. We briefly mentionsome works related to our theory, in addition to the already mentioned ones.Reasoning from multiple Hoare triples is studied in [20], in the context of un-available source code, where new properties cannot be derived by re-verification. We use the term “procedure”, rather than “function” or “method”, to refer to the well-known control abstraction mechanism of imperative programming languages.
3n particular, it is found that two Hoare-style rules, the standard rule of conse-quence and a generalised normalisation rule, are sufficient to infer, from a setof existing contracts for a procedure, any contract that is semantically entailed.Often-changing source code is a problem for contract-based reasoning andcontract reuse. In [13], abstract method calls are introduced to alleviate thisproblem. Fully abstract contracts are then introduced in [7], allowing reasoningabout software to be decoupled from contract applicability checks, in a way thatnot all verification effort is invalidated by changes in a specification.The relation between behavioural specifications and assume/guarantee-stylecontracts for modal transition systems is studied in [2], which shows how to builda contract framework from any specification theory supporting composition andrefinement. This work is built on in [9], where a formal contract framework basedon temporal logic is presented, allowing verification of correctness of contractrefinement relative to a specific decomposition.A survey of behavioural specification languages [14] found that existing lan-guages are well-suited for expressing properties of software components, but itis a challenge to express how components interact, making it difficult to reasonabout system and architectural level properties from detailed design specifica-tions. This provides additional evidence for the gap between contracts used insoftware verification and contracts as used in system design.
Structure.
The paper is organised as follows. Section 2 recalls the concept ofcontract based design and the contract meta-theory considered in the presentpaper. In Section 3 we present a denotational semantics for programs with pro-cedures, including a semantics for contracts for use in procedure-modular ver-ification. Next, Section 4 presents our abstract contract theory for sequentialprograms with procedures. Then, we show in Section 5 that our contract theoryfulfils the axioms of the meta-theory, while in Section 6 we show how the spec-ification of contracts of procedures in Hoare logic and their procedure-modularverification can be cast in the framework of our abstract contract theory. Weconclude with Section 7.
This section describes the concept of contract based design , and motivates its usein cyber-physical systems development. We then recall the contract meta-theoryby Benveniste et al [5].
Contract based design is an approach to systems design, where the system isdeveloped in a top-down manner through the use of contracts for components,which are incrementally assembled so that they preserve the desired system-wide properties. Contracts are typically described by a set of assumptions the4omponent makes on its environment, and a set of guarantees on the com-ponent’s behaviour, given that it operates in an environment adhering to theassumptions [5].Present-day cyber-physical systems, such as those found in the automotive,avionics and other industries, are extremely complex. Products assembled byOriginal Equipment Manufacturers (OEMs) often consist of components froma number of different suppliers, all using their own specialised design processes,system architectures, development platforms, and tools. This is also true insidethe OEMs, where there are different teams with different viewpoints of the sys-tem, and their own design processes and tools. In addition, the system itselfhas several different aspects that need to be managed, such as the architecture,safety and security requirements, functional behaviour, and so on. Thus, a rigor-ous design framework is called for that can solve these design-chain managementissues.Contract based design addresses these challenges through the principles, atthe specification level, of refinement and abstraction , which are processes formanaging the design flow between different layers of abstraction, and composi-tion and decomposition , which manage the flow at the same level of abstraction.Generally, when designing a system, at the top level of abstraction there willbe an overall system specification (or contract). This top-level contract is thenrefined, to provide a more concrete contract for the system, and decomposed,in order to obtain contracts for the sub-systems, and to separate the differentviewpoints of the system. A system design typically iterates the decomposition-and-refinement process, resulting in several layers of abstraction, until contractsare obtained that can be directly implemented, or for which implementationsalready exist. An important requirement on this methodology of hierarchicaldecomposition and refinement of contracts is that it must guarantee that whenthe low-level components implement their concrete contracts, and are combinedto form the overall system, then the top-level, abstract, contract shall hold.Furthermore, a contract framework in particular needs to support indepen-dent development and component reuse . That is, specifications for components,and their operations, must allow for components and specifications to be in-dependently designed and implemented, and to be used in different parts ofthe system, each with their own assumptions on how the other components,the environment, behave. This is achieved through the principle operations oncontracts: refinement , composition , and conjunction .Refinement allows one to extract a contract at the appropriate level of ab-straction. A desired property of refinement is that components which have beendesigned with reference to the more abstract (i.e., weaker) contract do not needto be re-designed after the refinement step. That is, in the early stages of devel-opment an OEM may have provided a weak contract for some subsystem to anexternal supplier, which implemented a component relying on this contract. Asdevelopment of the system progresses, and the contract is refined, the compo-nent supplied externally should still operate according to its guarantees withoutneeding to be changed, when instead assuming the new, refined, contract.Composition enables one to combine contracts of different components into5 contract for the larger subsystem obtained when combining the components.Again, a desirable property is that other components relying on one or moreof the individual contracts, can, after composition of the contracts, assume thenew contract and still perform its guarantees, without being re-designed, thusensuring that subsystems can be independently implemented.Finally, contract conjunction is another way of combining contracts, but nowfor the different viewpoints of a single component. This allows one to separate acontract into several different, finer contracts for the same component, revealingjust enough information for each particular system that depends on it, so thatit can be reused in different parts of the system, or in entirely different systems. We consider the meta-theory described in [5]. The stated purpose of the meta-theory has been to distil the notion of a contract to its essence, so that itcan be used in system design methodologies without ambiguities. In particu-lar, the meta-theory has been developed to give support for design-chain man-agement, and to allow component reuse and independent development . It hasbeen shown that a number of concrete contract theories instantiate it, includ-ing assume/guarantee-contracts, synchronous Moore interfaces, and interfacetheories. To our knowledge, this is the only meta-theory of its purpose andscope.We now present the formal definitions of the concepts defined in the meta-theory, and the properties that they entail. The meta-theory is defined only interms of semantics, and it is up to particular concrete instantiations to providea syntax.
Components.
The most basic concept in the meta-theory is that of a com-ponent , which represents any concrete part of the system. Thus, we have anabstract component universe M with components m ∈ M . Over pairs of compo-nents, we have a composition operation × . This operation is partially defined,and two components m and m are called composable when m × m is defined.In such cases, we call m an environment for m , and vice versa. In addition,component composition must be both commutative and associative, in order toensure that different components can be combined in any order.Typically, components are open , in the sense that they contain functionalityprovided by other components, i.e., their environment. The environment inwhich a component is to be placed is often unknown at development time, andalthough a component cannot restrict it, it is designed for a certain context. Contracts.
In the meta-theory, the notion of contract is defined in terms ofsets of components. The contract universe C def = 2 M × M consists of contracts C =( E, M ) , where E and M are the sets of environments and implementations of C ,respectively. Importantly, each pair ( m , m ) ∈ E × M must be composable.This definition is intentionally abstract. The intuition is that contracts separate6able 1: Properties that hold in theories that adhere to the meta-theory. Refinement.
When C (cid:22) C , every implementation of C is also animplementation of C .2 Shared refinement.
Any contract refining C ∧ C also refines C and C .Any implementation of C ∧ C is a shared implementation of C and C .Any environment for C and C is an environment for C ∧ C .3 Independent implementability.
Compatible contracts can beindependentlyimplemented.4
Independent refinement.
For all contracts C i and C ′ i , i ∈ I , if C i , i ∈ I are compatible and C ′ i (cid:22) C i , i ∈ I hold, then C ′ i , i ∈ I are compatibleand N i ∈ I C ′ i (cid:22) N i ∈ I C i Commutativity, sub-associativity.
For any finite sets of contracts C i ,i = 1 , . . . , n , C ⊗ C = C ⊗ C and N ≤ i ≤ n C i (cid:22) ( N ≤ i The following holds, if all contract compositionsin the formula are well defined: (( C ∧ C ) ⊗ ( C ∧ C )) (cid:22) (( C ⊗ C ) ∧ ( C ⊗ C )) the responsibilities of a component from the expectations on its environment.Moreover, contracts are best seen as weak specifications of components: theyshould expose just enough information to be adequate for their purpose.For a component m and a contract C = ( E, M ) , we shall sometimes write m | = E C for m ∈ E , and m | = M C for m ∈ M . A contract C is said to be consistent if it has at least one implementation, and compatible if it has at leastone environment. Contract refinement. For two contracts C = ( E , M ) and C = ( E , M ) , C is said to refine C , denoted C (cid:22) C , iff M ⊆ M and E ⊆ E . As an axiomof the meta-theory, it is required that the greatest lower bound with respectto refinement exists, for all subsets of C . Table 1 summarises the importantproperties of refinement and the other operations on contracts that a concretecontract theory needs to possess in order to be considered an instance of themeta-theory. Contract conjunction. The conjunction of two contracts C and C , denoted C ∧C , is defined as their greatest lower bound w.r.t. the refinement order. (Theintention is that ( E , M ) ∧ ( E , M ) should equal ( E ∪ E , M ∩ M ) ; however,this cannot be taken as the definition since not every such pair necessarily con-stitutes a contract.) Then, we have the three desirable properties of conjunctionlisted in Table 1, which together are referred to as shared refinement .7 ontract composition. The composition of two contracts C = ( E , M ) and C = ( E , M ) , denoted C ⊗C = ( E, M ) , is defined when every two components m ∈ M and m ∈ M are composable, and must then be the least contract,w.r.t. the refinement order, satisfying the following conditions:(i) m ∈ M ∧ m ∈ M ⇒ m × m ∈ M ;(ii) e ∈ E ∧ m ∈ M ⇒ m × e ∈ E ; and(iii) e ∈ E ∧ m ∈ M ⇒ e × m ∈ E .If all of the above is satisfied, then properties 3-6 of Table 1 hold. The intentionis that composing two components implementing C and C should yield animplementation of C ⊗ C , and composing an environment of C ⊗ C with animplementation of C should result in a valid environment for C , and vice versa.This is important in order to enable independent development. In this section we summarise the background needed to understand the formaldevelopments later in the paper. First, we recall the standard denotational se-mantics of programs with procedures on a typical toy programming language.Next, we summarise Hoare logic and contracts, and provide a semantic justifi-cation of procedure-modular verification, also based on denotational semantics. This section sketches the standard presentation of denotational semantics forprocedural languages, as presented in textbooks such as [22, 18]. This semanticsis the inspiration for the definition of components in our abstract contract theoryin Section 4.1. We start with a simplistic programming language not involvingprocedures, and add procedures later to the language.The following toy sequential programming language is typically used topresent the denotational semantics of imperative languages: S ::= skip | x := a | S ; S | if b then S else S | while b do S where S ranges over statements, a over arithmetic expressions, and b overBoolean expressions.To define the denotational semantics of the language, we define the set State of program states. A state s ∈ State is a mapping from the program variablesto, for simplicity, the set of integers.The denotation of a statement S , denoted [[ S ]] , is typically given as a partialfunction State ֒ → State such that [[ S ]] ( s ) = s ′ whenever executing statement S from the initial state s terminates in state s ′ . In case that executing S from s [[ S ]] ( s ) is undefined. The definition of [[ S ]] proceeds by induction on the structure of S . For example, the meaning ofsequential composition of statements is usually captured with relation compo-sition, as given by the equation [[ S ; S ]] def = [[ S ]] ◦ [[ S ]] . For the treatment of theremaining statements of the language, the reader is referred to [22, 18].The definition of denotation captures through its type (as a partial func-tion) that the execution of statements is deterministic. For non-deterministicprograms, the type of denotations is relaxed to [[ S ]] ⊆ State × State ; then, ( s, s ′ ) ∈ [[ S ]] captures that there is an execution of S starting in s that termi-nates in s ′ . For technical reasons that will become clear below, we shall use thislatter denotation type in our treatment.Note that we could alternatively have chosen State + as the denotational do-main, and most results would still hold in the context of finite-trace semantics.However, we chose to develop the theory with a focus on Hoare-logic and de-ductive verification. In fact, the domain State × State can be seen as a specialcase of finite traces. In future work, we will also investigate concrete contractlanguages based on this semantics, and extend the theory for that context. Procedures and Procedure Calls. To extend the language and its deno-tational semantics with procedures and procedure calls, we follow again theapproach of [22], but adapt it to an “open” setting, where some called proce-dures might not be declared. We consider programs in the context of a finiteset P of procedure names (of some larger, “closed” program), and a set of pro-cedure declarations of the form proc p is S p , where p ∈ P . Further, we extendthe toy programming language with the statement call p .Listing 1: An even-odd toy program. p roc even i s i f n = 0 then r := 1 e l s e ( n := n − − As an example, Listing 1 shows a (closed) program in the toy language,implementing two mutually recursive procedures. The procedures check whetherthe value of the global variable n is even or odd, respectively, and assign thecorresponding truth value to the variable r .Due to the (potential) recursion in the procedure declarations, the denota-tion of call p , and thus of the whole language, cannot be defined by structuralinduction as directly as before. We therefore define, for any set P ⊆ P of proce-dure names, the set Env P = P → State × State of procedure environments , eachenvironment ρ ∈ Env P thus providing a denotation for each procedure in P .Let Env def = S P ⊆P Env P be the set of all procedure environments. We definea partial order relation ⊑ on procedure environments, as follows. For any twoprocedure environments ρ ∈ Env P and ρ ′ ∈ Env P ′ , ρ ⊑ ρ ′ if and only if P ⊆ P ′ and ∀ p ∈ P. ρ ( p ) ⊆ ρ ′ ( p ) .Recall that a complete lattice is a partial order, every set of elements ofwhich has a greatest lower bound ( glb ) within the domain of the lattice (see,9.g., [22]). It is easy to show that for any P ⊆ P , ( Env P , ⊑ ) is a completelattice, since a greatest lower bound will exist within Env P . Then, the leastupper bound ( lub ) ρ ⊔ ρ of any two function environments ρ ∈ Env P and ρ ∈ Env P also exists, and is the environment ρ ∈ Env P ∪ P such that ∀ p ∈ P ∪ P . ρ ( p ) = ρ ( p ) ∪ ρ ( p ) .We will sometimes need a procedure environment that maps every procedurein P to State × State , and we shall denote this environment by ρ ⊤ P .Next, for sets of procedures, we shall need the notion of interface , which isa pair ( P − , P + ) of disjoint sets of procedure names, where P + ⊆ P is a set of provided (or declared) procedures, and P − ⊆ P a set of required (or called, butnot declared) ones.Then, we (re)define the notion of denotation of statements S in the contextof a given interface ( P − , P + ) and environments ρ − ∈ Env P − and ρ + ∈ Env P + ,and denote it by [[ S ]] ρ + ρ − . In particular, we define [[ call p ]] ρ + ρ − as ρ − ( p ) when p ∈ P − and as ρ + ( p ) when p ∈ P + .Intuitively, the denotation of a call to a procedure should be equal to thedenotation of the body of the latter. We therefore introduce, given anenvironment ρ − ∈ Env P − , the function ξ : Env P + → Env P + defined by ξ ( ρ + )( p ) def = [[ S p ]] ρ + ρ − for any ρ + ∈ Env P + and p ∈ P + , and consider its fixedpoints. By the Knaster-Tarski Fixed-Point Theorem (as stated, e.g., in [22]),since ( Env P + , ⊑ ) is a complete lattice and ξ is monotonic, ξ has a least fixed-point ρ +0 .Finally, we define the notion of standard denotation of statement S in thecontext of a given interface ( P − , P + ) and environment ρ − ∈ Env P − , denoted [[ S ]] ρ − , by [[ S ]] ρ − def = [[ S ]] ρ +0 ρ − , where ρ +0 is the least fixed-point defined above.For example, for the closed program in Listing 1, we have an interface with P + = { even , odd } and P − = ∅ . Then, ( s, s ′ ) ∈ [[ S even ]] ρ + ρ − if either s ( n ) = 0 and s ′ = s [ r , or else if s ( n ) > and ( s [ n s ( n ) − , s ′ ) ∈ ρ + ( odd ) . Thedenotation [[ S odd ]] ρ + ρ − is analogous. The resulting least fixed-point ρ +0 is suchthat ( s, s ′ ) ∈ [[ S even ]] ρ − , or equivalently ( s, s ′ ) ∈ [[ S even ]] ρ +0 ρ − , whenever s ( n ) ≥ ,and either s ( n ) is even and then s ′ ( n ) = 0 and s ′ ( r ) = 1 , or else s ( n ) is oddand then s ′ ( n ) = 0 and s ′ ( r ) = 0 . The standard denotation [[ S odd ]] ρ − of odd isanalogous. In this section we summarise the denotational semantics of Hoare logic and thesemantic justification of procedure-modular verification, as developed by thesecond author in [12]. These formalisations serve as the starting point for thedefinition of contracts in our contract theory developed in Section 4.2. Hoare Logic. The basic judgement of Hoare logic [15] is the Hoare triple,written { P } S { Q } , where P and Q are assertions over the program state, and S 10s a program statement. The Hoare triple signifies that if the statement S isexecuted from a state that satisfies P (called the pre-condition), and if thisexecution terminates, then the final state of the execution will satisfy Q (calledthe post-condition). Additionally, so-called logical variables can be used withina Hoare triple, to specify the desired relationship between the values of variablesafter execution and the values of variables before execution. The values of theprogram variables are defined by the notion of state; to give a meaning to thelogical variables we shall use interpretations I . We shall write s | = I P to signifythat the assertion P is true w.r.t. state s and interpretation I . The formalvalidity of a Hoare triple is denoted by | = par { P } S { Q } , where the subscriptsignifies that validity is in terms of partial correctness , where termination of theexecution of S is not required.An example of a Hoare triple, stating the desired behaviour of procedure odd from Listing 1, is shown below, where we use the logical variable n to captureto the value of n prior to execution of odd : { n ≥ ∧ n = n } S odd { ( n mod 2 = 0 ⇒ r = 0) ∧ ( n mod 2 = 1 ⇒ r = 1) } (1)Procedure even is specified analogously.Hoare logic comes with a proof calculus for reasoning in terms of Hoaretriples, consisting of proof rules for the different types of statements of theprogramming language. An example is the rule for sequential composition: { P } S { R } { R } S { Q }{ P } S ; S { Q } Composition which essentially states that if executing S from any state satisfying P ter-minates (if at all) in some state satisfying R , and executing S from any statesatisfying R terminates (if at all) in some state satisfying Q , then it is the casethat executing the composition S ; S from any state satisfying P terminates(if at all) in some state satisfying Q . The proof system is sound and relativelycomplete w.r.t. the denotational semantics of the programming language (see,e.g., [22, 18]). Hoare Logic Contracts. One can view a Hoare triple { P } S { Q } as a contract C = ( P, Q ) imposed on the program S . In many contexts it is meaningful toseparate the contract from the program; for instance, if the program is yet tobe implemented. In our earlier work [12], we gave such contracts a denotationalsemantics as follows: [[ C ]] def = { ( s, s ′ ) | ∀I . ( s | = I P ⇒ s ′ | = I Q ) } (2)The rationale behind this definition is the following desirable property: a pro-gram meets a contract whenever its denotation is subsumed by the denotationof the contract, i.e., S | = par C if and only if [[ S ]] ⊆ [[ C ]] .For example, for the contract C odd induced by (1) we have that ( s, s ′ ) ∈ [[ C odd ]] if and only if either s ( n ) < , or else s ′ ( r ) = 0 if s ( n ) is even and s ′ ( r ) = 1 if s ( n ) is odd. The denotation of C even is analogous.11 he Denotational Semantics of Programs with Procedure Contracts. Let S be a program with procedures, and let every declared procedure p ∈ P beequipped with a procedure contract C p . Procedure-modular verification refers totechniques that verify every procedure in isolation. The key to this is to handleprocedure calls by using the contract of the called procedure rather than itsbody (i.e., by contracting rather than by inlining [7]). In [12], a semantic justi-fication of this is given by means of a contract-relative denotational semanticsof statements. The intuition behind this semantics is that procedure calls aregiven a meaning through the denotation of the contract of the called procedure,rather than through the denotation of its body.The contract-relative denotational semantics of a statement S , denoted [[ S ]] cr ,is defined with the help of the contract environment ρ c that is induced by theprocedure contracts, i.e., ρ c ( p ) def = [[ C p ]] for all p ∈ P , as [[ S ]] cr def = [[ S ]] ρ c . Noticethat this definition does not involve solving any recursive equations (i.e., findingfixed points), and gives rise to a contract-relative notion of when a statementmeets a contract, namely S | = crpar C if and only if [[ S ]] cr ⊆ [[ C ]] . This is exactlythe correctness notion that is the target of procedure-modular verification. Asshown in [12], this notion is sound w.r.t. the original notion S | = par C , in thesense that S | = crpar C entails S | = par C . In other words, verifying a programprocedure-modularly establishes that the program is correct w.r.t. its contractin the standard sense.For example, the contract-relative semantics of S even is such that ( s, s ′ ) ∈ [[ S even ]] cr if either s ( n ) < , or s ( n ) = 0 and s ′ = s [ r , or else s ′ ( r ) = 1 if s ( n ) is even and s ′ ( r ) = 0 if s ( n ) is odd. The contract-relative semanticsof S odd is analogous. Then, it is easy to check that both S even | = crpar C even and S odd | = crpar C odd hold. This section presents an abstract contract theory for programs with procedures.The theory builds on the basic notion of denotation as a binary relation overstates. As we will show later, it is both an abstraction of the denotationalsemantic view on programs with procedures and procedure contracts presentedin Sections 3.1 and 3.2, and an instantiation of the meta-theory described inSection 2.2. In the context of a concrete programming language, we view a component as amodule, consisting of a collection of procedures that are provided by the module.The module may call required procedures that are external to the module. Theway the provided procedures transform the program state upon a call dependson how the required procedures transform the state. We take this observationas the basis of our abstract setting, in which state transformers are modelledas denotations (i.e., as binary relations over states). A component will thus be12imply a mapping from denotations of the required procedures to denotations ofthe provided ones, both captured through the notion of procedure environments.The contract theory is abstract, in that it is not defined for a particularprogramming language, and may be instantiated with any procedural language.As with the meta-theory, the abstract contract theory is also defined only onthe semantic level.Recall the notions and notation from Section 3.1. A component interface I = ( P − , P + ) is a pair of disjoint, finite sets of procedure names, of the requiredand the provided ones, respectively. Definition 1 (Component) . A component m with interface I m = ( P − m , P + m ) isa mapping m : Env P − m → Env P + m . Let M denote the universe of all components over P .We assume that any system is built up from a set of base components , thesimplest components from which more complex components are then obtainedby composition. The base components must be monotonic functions over thelattice defined in Section 3.1.When P − m = ∅ , we shall identify m with an element of Env P + m . In otherwords, when a component is closed , i.e., is not dependent on any external pro-cedures, the provided environment is constant. Definition 2 (Component composability) . Two components m and m are composable iff P + m ∩ P + m = ∅ . When defining the composition of two components, particular care is re-quired in the treatment of procedure names that are provided by one of thecomponents while required by the other. Let µx. f ( x ) denote the least fixed-point of a function f , when it exists. Definition 3 (Component composition) . Given two composable components m : Env P − m → Env P + m and m : Env P − m → Env P + m , their composition isdefined as a mapping m × m : Env P − m × m → Env P + m × m such that: P + m × m def = P + m ∪ P + m P − m × m def = ( P − m ∪ P − m ) \ ( P + m ∪ P + m ) m × m def = λρ − m × m ∈ Env P − m × m . µρ. χ + m × m ( ρ ) where χ + m × m : Env P + m × m → Env P + m × m is defined, in the context of a given ρ − m × m ∈ Env P − m × m , as follows. Let ρ + m × m ∈ Env P + m × m , and let ρ − m ∈ Env P − m be the environment defined by: ρ − m ( p ) def = (cid:26) ρ + m × m ( p ) if p ∈ P − m ∩ P + m ρ − m × m ( p ) if p ∈ P − m \ P + m nd let ρ − m ∈ Env P − m be defined symmetrically. We then define: χ + m × m ( ρ + m × m )( p ) def = (cid:26) m ( ρ − m )( p ) if p ∈ P + m m ( ρ − m )( p ) if p ∈ P + m In the above definition, χ + m × m represents the denotations of the procedure bodies of the procedures provided by the two composed components, given deno-tations of procedure calls to the same procedures. The choice of least fixed-pointwill be crucial for the proof of Theorem 2(i) in Section 4.2 below.The definition is well-defined, in the sense that the stated least fixed-pointsexist, and the resulting components are monotonic functions. Theorem 1. Component composition is well-defined.Proof. For any P ⊆ P , we have that ( Env P , ⊑ ) forms a complete lattice. Thus,in particular, ( Env P + m × m , ⊑ ) is a complete lattice. By the Knaster-TarskiFixed-Point Theorem, as stated e.g. in [22], if ( Env P + m × m , ⊑ ) is a completelattice, and χ + m × m : Env P + m × m → Env P + m × m is monotonic, then χ + m × m has a least fixed-point.To prove that components are monotonic functions, we shall use structuralinduction. Since base components are monotonic by definition, we only haveto show that composition preserves monotonicity. Assume that m and m aremonotonic. Since χ + m × m is an application of either m or m , it must also bemonotonic, and thus have a least fixed-point. The µ operator is itself monotonic,and the component m × m must therefore be monotonic as well. We now define the notion of denotational contracts c in the style of assume/guar-antee contracts [4, 6]. Contracts shall also be given interfaces. Definition 4 (Denotational contract) . A denotational contract c with interface I c = ( P − c , P + c ) is a pair ( ρ − c , ρ + c ) , where ρ − c ∈ Env P − c and ρ + c ∈ Env P + c . The intended interpretation of the environment pair is as follows: assuming that the denotation of every called procedure p ∈ P − c is subsumed by ρ − c ( p ) ,then it is guaranteed that the denotation of every provided procedure p ′ ∈ P + c is subsumed by ρ + c ( p ′ ) . Definition 5 (Contract implementation) . A component m with interface I m =( P − m , P + m ) is an implementation for, or implements , a contract c = ( ρ − c , ρ + c ) with interface I c = ( P − c , P + c ) , denoted m | = c , iff P − c ⊆ P − m , P + m ⊆ P + c , and m ( ρ − c ⊔ ρ ⊤ P − m \ P − c ) ⊑ ρ + c . The reason for not requiring the interfaces to be equal is that we aim at a subsetrelation between components implementing a contract and those implementinga refinement of said contract, in the meta-theory instantiation.For a mapping h : A → B and set A ′ ⊆ A , let h | A ′ denote as usual therestriction of h on A ′ . 14 efinition 6 (Contract environment) . A component m is an environment forcontract c iff, for any implementation m ′ of c , m and m ′ are composable, and ∀ ρ − m × m ′ ∈ Env P − m × m ′ . ( m × m ′ )( ρ − m × m ′ ) | P + c ⊑ ρ + c . Intuitively, an environment of a contract c is then a component such that whenit is composed with an implementation of c , the composition will operate satis-factorily with respect to the guarantee of the contract.We will now define the refinement relation, and the conjunction and compo-sition operations, on contracts. Definition 7 (Contract refinement) . A contract c refines contract c ′ , denoted c (cid:22) c ′ , iff ρ − c ′ ⊑ ρ − c and ρ + c ⊑ ρ + c ′ , where ⊑ is the partial order relation definedin Section 3.1. The refinement relation reflects the intention that if a contract c refines anothercontract c ′ , then any component implementing c should also implement c ′ . Definition 8 (Contract conjunction) . The conjunction of two contracts c =( ρ − c , ρ + c ) and c = ( ρ − c , ρ + c ) is the contract c ∧ c def = ( ρ − c ⊔ ρ − c , ρ + c ⊓ ρ + c ) ,where ⊔ and ⊓ are the lub and glb operations of the lattice, respectively. This definition is consistent with the intention that any contract that refines c ∧ c should also refine c and c individually. The interface of c ∧ c is then I c ∧ c = ( P − c ∪ P − c , P + c ∩ P + c ) . Note that while this is the interface in general,conjunction of contracts is typically used to merge different viewpoints of thesame component, and in that case I c = I c = I c ∧ c . Definition 9 (Contract composability) . Two contracts c = ( ρ − c , ρ + c ) and c = ( ρ − c , ρ + c ) with interfaces I c = ( P − c , P + c ) and I c = ( P − c , P + c ) are com-posable if: (i) P + c ∩ P + c = ∅ , (ii) ∀ p ∈ P − c ∩ P + c . ρ + c ( p ) ⊆ ρ − c ( p ) , and(iii) ∀ p ∈ P − c ∩ P + c . ρ + c ( p ) ⊆ ρ − c ( p ) . The conditions for composability ensure that the mutual guarantees of the twocontracts meet each other’s assumptions. Definition 10 (Contract composition) . The composition of two composablecontracts c = ( ρ − c , ρ + c ) and c = ( ρ − c , ρ + c ) , with interfaces I c = ( P − c , P + c ) and I c = ( P − c , P + c ) , respectively, is the contract c ⊗ c def = ( ρ − c ⊗ c , ρ + c ⊔ ρ + c ) , where: ρ − c ⊗ c def = ( ρ − c ⊓ ρ − c ) (cid:12)(cid:12) ( P − c ∪ P − c ) \ ( P + c ∪ P + c ) The interface of c ⊗ c is I c ⊗ c = (( P − c ∪ P − c ) \ ( P + c ∪ P + c ) , P + c ∪ P + c ) . Theorem 2. For any composable contracts c and c , and any implementations m | = c and m | = c , m and m are composable, and c ⊗ c is the leastcontract (w.r.t. refinement order) for which the following properties hold:(i) m × m | = c ⊗ c , ii) if m is an environment to c ⊗ c , then m × m is an environment to c ,(iii) if m is an environment to c ⊗ c , then m × m is an environment to c .Proof. Let the contracts c = ( ρ − c , ρ + c ) and c = ( ρ − c , ρ + c ) with interfaces I c =( P − c , P + c ) and I c = ( P − c , P + c ) be composable, and let m | = c and m | = c .Since contract composition restricts the interface in the same way as componentcomposition, m and m are also composable.Proof of (i). Since m | = c and m | = c , it must be the case that P − c ∪ P − c ⊆ P − m ∪ P − m and P + m ∪ P + m ⊆ P + c ∪ P + c , so P − c ⊗ c ⊆ P − m × m and P + m × m ⊆ P + c ⊗ c , which are the first two conditions from Definition 5.Now, let ρ − m × m def = ρ − c ⊗ c ⊔ ρ ⊤ P − m × m \ P − c ⊗ c and ρ + c ⊗ c def = ρ + c ⊔ ρ + c . Re-call the definition of χ + m × m in Definition 3, defined now in the context ofthe above ρ − m × m . We need to show ( m × m )( ρ − m × m ) ⊑ ρ + c ⊗ c , i.e., that µρ. χ + m × m ( ρ ) ⊑ ρ + c ⊗ c . By using that ρ + c ⊗ c | P + m × m ⊑ ρ + c ⊗ c , this reduces toshowing µρ. χ + m × m ( ρ ) ⊑ ρ + c ⊗ c | P + m × m . This we accomplish by proving that χ + m × m ( ρ + c ⊗ c | P + m × m ) ⊑ ρ + c ⊗ c | P + m × m , which establishes that ρ + c ⊗ c | P + m × m is a prefixed-point of χ + m × m , and is therefore greater than µρ. χ + m × m ( ρ ) .Thus, we need to show χ + m × m ( ρ + c ⊗ c | P + m × m ) ⊑ ρ + c ⊗ c | P + m × m , i.e., that ∀ p ∈ P + m × m . χ + m × m ( ρ + c ⊗ c | P + m × m )( p ) ⊆ ρ + c ⊗ c | P + m × m ( p ) . Let p ∈ P + m ; thecase p ∈ P + m is symmetric. Using the notation of Definition 3, we have: ρ − m ( p ′ ) = ρ + c ⊗ c | P + m × m ( p ′ ) if p ′ ∈ P − m ∩ P + m ( ρ − c ⊗ c ⊔ ρ ⊤ P − m × m \ P − c ⊗ c )( p ′ ) if p ′ ∈ P − m \ P + m Below we shall show ρ − m ⊑ ρ − c ⊔ ρ ⊤ P − m \ P − c . Since m | = c , by Definition 5 wehave m ( ρ − c ⊔ ρ ⊤ P − m \ P − c ) ⊑ ρ + c , and by monotonicity of m and transitivity of ⊑ ,we obtain m ( ρ − m ) ⊑ ρ + c . Then, for p ∈ P + m , we have χ + m × m ( ρ + c ⊗ c | P + m × m )( p ) = m ( ρ − m )( p ) ⊆ ( ρ + c )( p ) = ρ + c ⊗ c | P + m × m ( p ) , which is what we wanted to prove.And finally, we need to show ρ − m ⊑ ρ − c ⊔ ρ ⊤ P − m \ P − c . There are altogether fivecases that need to be considered. First, let p ′ ∈ P − c ∩ P + m (recall that P − c ⊆ P − m ,since m | = c ). Since c and c are composable, by Definition 9 we have ∀ p ∈ P − c ∩ P + c . ρ + c ( p ) ⊆ ρ − c ( p ) . Then we have ρ − m ( p ′ ) = ρ + c ⊗ c | P + m × m ( p ′ ) = ρ + c ( p ′ ) ⊆ ρ − c ( p ′ ) = ( ρ − c ⊔ ρ ⊤ P − m \ P − c )( p ′ ) . Next, let p ′ ∈ ( P − m \ P − c ) ∩ P + m .This case is similar to the first one, but now ρ + c ( p ′ ) ⊆ ρ ⊤ P − m \ P − c ( p ′ ) = ( ρ − c ⊔ ρ ⊤ P − m \ P − c )( p ′ ) . Third, let p ′ ∈ ( P − c \ P + m ) \ P − c . Then we have ρ − m ( p ′ ) =( ρ − c ⊗ c ⊔ ρ ⊤ P − m × m \ P − c ⊗ c )( p ′ ) = ρ − c ( p ′ ) = ( ρ − c ⊔ ρ ⊤ P − m \ P − c )( p ′ ) . Fourth, let p ′ ∈ ( P − m \ P + m ) \ P − c . This case is similar to the third one, but now ( ρ − c ⊗ c ⊔ ⊤ P − m × m \ P − c ⊗ c )( p ′ ) ⊆ ρ ⊤ P − m \ P − c ( p ′ ) = ( ρ − c ⊔ ρ ⊤ P − m \ P − c )( p ′ ) . And last, let p ′ ∈ P − c ∩ P − c . This case is also similar to the third one, but now, by Definition 10,we have ( ρ − c ⊗ c ⊔ ρ ⊤ P − m × m \ P − c ⊗ c )( p ′ ) = ( ρ − c ⊓ ρ − c )( p ′ ) ⊆ ρ − c ( p ′ ) = ( ρ − c ⊔ ρ ⊤ P − m \ P − c )( p ′ ) . This concludes the proof of (i).Proof of (ii). Let m be an environment to c ⊗ c . Then, P + m ∩ P + c ⊗ c = ∅ andconsequently P + m ∩ P + c = ∅ , so m and m are composable. Furthermore, since P + m ∩ P + c = ∅ and P + m ∩ P + c = ∅ we have P + m × m ∩ P + c = ∅ , thus the condition onthe interfaces hold. Since ρ + c × c is the lub of ρ − c and ρ − c , and P + c ∩ P + c = ∅ , thendenotations for all p ∈ P + c are the same in ρ + c and ρ + c ⊗ c . Thus, we have that ∀ ρ − m × m × m ∈ Env P − m × m × m . ∀ p ∈ P + c . ( m × m × m )( ρ − m × m × m )( p ) ⊆ ρ + c ( p ) must hold, which it does since ρ + c = ρ + c ⊗ c (cid:12)(cid:12) P + c and m is an environment to c ⊗ c . So m × m is an environment to c .The proof of (iii) is analogous.Finally, c ⊗ c is the least contract for which the above properties hold, sinceweakening ρ − c ⊗ c or strengthening ρ + c ⊗ c would immediately falsify (i). In this section we show that the abstract contract theory presented in Section 4instantiates the meta-theory described in Section 2.2.In our instantiation of the meta-theory, we consider as the abstract compo-nent universe M the same universe of components M as defined in Section 4.1.To distinguish the contracts of the meta-theory from those of the abstract the-ory, we shall always denote the former by C and the latter by c . Recall that acontract C is a pair ( E, M ) , where E, M ⊆ M . The formal connection betweenthe two notions is established with the following definition. Definition 11 (Induced contract) . Let c be a denotational contract. It induces the contract C c = ( E c , M c ) , where E c def = { m ∈ M | m is an environment for c } and M c def = { m ∈ M | m | = c } . Since contract implementation requires that the implementing component’s pro-vided functions are a subset of the contract’s provided functions, every compo-nent m such that P + m ∩ P + c = ∅ is composable with every component in M c .The definitions of implementation, refinement and conjunction of denota-tional contracts make this straightforward definition of induced contracts possi-ble, so that it directly results in refinement as set membership and conjunctionas lub w.r.t. the refinement order. Theorem 3. The contract theory of Section 4 instantiates the meta-theory ofBenveniste et al. [5], in the sense that composition of components is associativeand commutative, and for any two contracts c and c :(i) c (cid:22) c iff C c refines C c according to the definition of the meta-theory, ii) C c ∧ c is the conjunction of C c and C c as defined in the meta-theory, and(iii) C c ⊗ c is the composition of C c and C c as defined in the meta-theory.Proof. Statement (i) holds since c (cid:22) c means that for all components m , if m | = c then m | = c . Equivalently, if m | = M C c then m | = M C c , which meansthat M c ⊆ M c . Now, c (cid:22) c also means that all components m ′ composablewith components in M c are also composable with all components in M c , andthus E c ⊆ E c . So c (cid:22) c iff C c (cid:22) C c .Statement (ii) clearly holds: any component implementing c ∧ c also im-plements c and c . Thus, every component in M c ∧ c is also in M c and M c .Similarly, all components that are environments of c or c , are also environ-ments of c ∧ c . So M c ∧ c is the greatest lower bound of M c and M c withrespect to refinement.We will now show that Statement (iii) holds. Recall Theorem 2, and saythat we have components and contracts such that m | = c and m | = c , or, byDefinition 11, that m | = M C c and m | = M C c . From Theorem 2 we then havethat m × m | = c ⊗ c , or m × m | = M C c ⊗ c . This trivially holds in the otherdirection as well. Say that we also have m such that m is an environment to c ⊗ c , or, in other words, that m | = E C c ⊗ c . By Theorem 2 we then have that m × m is an environment to c , or m × m | = E C c . Again, this trivially holdsin the other direction, and by symmetry we also have that m × m | = E C c .Let us now return to our example from Section 3. When applying ContractBased Design, contracts at the more abstract level will be decomposed intocontracts at the more concrete level. So, for our example, we might have at thetop level a contract c = ( ρ − c , ρ + c ) with interface ( ∅ , { even, odd } ) , where ρ − c = ∅ ,and where ρ + c ∈ Env P + c maps even to the set of pairs ( s, s ′ ) such that whenever s ( n ) is non-negative and even, then s ′ ( r ) = 1 , and when s ( n ) is non-negativeand odd, then s ′ ( r ) = 0 , and maps odd in a dual manner. This contract couldthen be decomposed into two contracts c even and c odd , so that ρ + c even ( even ) def = ρ + c ( even ) and ρ − c even ( odd ) def = ρ + c ( odd ) , and c odd is analogous. Then, we wouldhave c even ⊗ c odd (cid:22) c , and for any two components m even and m odd such that m even | = c even and m odd | = c odd , it would hold that m even × m odd | = c . In this section we discuss how our abstract contract theory from Section 4 relatesto programs with procedures as presented in Section 3.1, and how it relates toHoare logic and procedure-modular verification as presented in Section 3.2.First, we define how to abstract the denotational notion of procedures intocomponents in the abstract theory, based on the function ξ from Section 3.1. Definition 12 (From procedure sets to components) . For any set of proce-dures P + , calling procedures P ′ , we define the component m : Env P − m → nv P + m , where P − m def = P ′ \ P + m and P + m def = P + , so that ∀ ρ − m ∈ Env P − m . ∀ p ∈ P + m . m ( ρ − m )( p ) def = [[ S p ]] ρ − m . As the next result shows, procedure set abstraction and component compo-sition commute. Together with commutativity and associativity of componentcomposition, this means that the initial grouping of procedures into componentsis irrelevant, and that one can start with abstracting each individual procedureinto a component. Theorem 4. For any two disjoint sets of procedures P +1 and P +2 , abstractedindividually into components m and m , respectively, and P +1 ∪ P +2 abstractedinto component m , it holds that m × m = m .Proof. Let the set of procedures P +1 , calling but not providing P − , and thedisjoint set P +2 , calling but not providing P − , be abstracted into components m and m , respectively, and let the set P + = P +1 ∪ P +2 be abstracted intocomponent m , all following Definition 12. The interfaces of components m and m × m are equal, since P + m = P + m ∪ P + m = P + m × m , and if P − and P − are the procedures called by (but not in) P +1 and P +2 , respectively, then theprocedures called by (but not in) P + are P − m = ( P − m ∪ P − m ) \ ( P + m ∪ P + m ) = P − m × m .To show that m × m = m , we have also to show that for all procedures p ∈ P +1 ∪ P +2 , ∀ ρ ∈ Env P − m . m ( ρ )( p ) = ( m × m )( ρ )( p ) . It is enough to showthat ∀ p ∈ P +1 . ∀ ρ ∈ Env P − m . m ( ρ )( p ) = ( m × m )( ρ )( p ) . By symmetry it thenalso holds for all p ∈ P +2 , and thus for all p ∈ P + m .For any p ∈ P +1 and ρ − ∈ Env P − m , m ( ρ − )( p ) = [[ S p ]] ρ − = [[ S p ]] ρ +0 ρ − = ρ +0 ( p ) =( µρ. ξ ( ρ ))( p ) , where ξ : Env P + → Env P + is relativised on ρ − , as we recallfrom Section 3.1. However, we could view this as taking the simultaneuos leastfixed-point of two functions ξ : Env P +1 × Env P +2 → Env P +1 and ξ : Env P +1 × Env P +2 → Env P +2 , both also relative to ρ − , and then taking the union of theresulting procedure environments as the result.The well-known Bekić’s Lemma [3] states that, for a complete lattice L ,and monotone f, g such that f : L p + q → L p , g : L p + q → L q , it holds that µx, y. ( f ( x, y ) , g ( x, y )) = ( x , y ) , where x = µx. f ( x, µy. g ( x, y )) and y = µy. g ( x , y ) , meaning that for two interdependent monotone functions, takingthe simultaneous least fixed-points gives the same results as iteratively findingthem one function at a time. Using the special case when p = q = 1 , wehave that the lemma also holds for f, g : L × L → L . Furthermore, in ourcase, for any complete lattice ( Env P , ⊑ ) and function h ′ : Env P → Env P ,we can define the equivalent function h : Env → Env by h ( ρ ) def = h ′ ( ρ ⊓ ρ ⊤ P ) ,essentially ignoring denotations for all procedures not in P . We then get thatBekić’s Lemma also holds for monotone f : Env P × Env P → Env P and g : Env P × Env P → Env P , for any two sets of procedures P and P .Again relativised on ρ − , for p ∈ P +1 and χ + m × m : Env P + → Env P + wehave that ( m × m )( ρ − )( p ) = ( µρ. χ + m × m ( ρ ))( p ) , according to Definition 3.19ere, χ + m × m is the simultaneous fixed-point of two functions, for which wealready have partial fixed-points, of the function ξ from Section 3.1. For theprocedures in P +1 in particular, and for each ρ − ∈ Env P − , we have the fixed-points of the function ξ ′ : Env P +1 → Env P +1 . Recall ξ from above. When ρ − ∪ ρ − = ρ − , we have ξ ( ρ − , x ) = ξ ′ ( x ) relative to ρ − and ρ − , respectively. Sincethese functions are all monotone, when taking the least fixed-point of χ + m × m ,using the already computed fixed-points, we will then by Bekić’s Lemma getthe same result as the least fixed-point of ξ above, and thus m = m × m . Component abstraction example. Let us illustrate the theorem on oureven-odd example (however, the example does not really illustrate Bekić’s Lemma,since the two procedures do not call themselves).By Definition 12, the procedure set { even } is abstracted into component m even : Env { odd } → Env { even } with interface ( { odd } , { even } ) , so that ∀ ρ − ∈ Env { odd } . m ( ρ − )( even ) = [[ S even ]] ρ − . By definition, [[ S even ]] ρ − is equal to [[ S even ]] ρ +0 ρ − , where ρ +0 is the least fixed point of ξ : Env { even } → Env { even } defined by ξ ( ρ + )( even ) def = [[ S even ]] ρ + ρ − for any ρ + ∈ Env { even } . Notice, however,that procedure even does not have any calls to itself, so [[ S even ]] ρ +0 ρ − does notreally depend on ρ + . Then, for any ρ − ∈ Env { odd } , ( s, s ′ ) ∈ m ( ρ − )( even ) ifeither s ( n ) = 0 and s ′ = s [ r , or else if s ( n ) > and ( s [ n s ( n ) − , s ′ ) ∈ ρ − ( odd ) .Similarly, the procedure set { odd } is abstracted into component m odd : Env { even } → Env { odd } with interface ( { even } , { odd } ) , so that ∀ ρ − ∈ Env { even } .m ( ρ − )( odd ) = [[ S odd ]] ρ − . Then, for any ρ − ∈ Env { even } , ( s, s ′ ) ∈ m ( ρ − )( odd ) ifeither s ( n ) = 0 and s ′ = s [ r , or else if s ( n ) > and ( s [ n s ( n ) − , s ′ ) ∈ ρ − ( even ) .Now, applying Definition 12 to the whole (closed) program yields a com-ponent m : Env ∅ → Env { even , odd } with interface ( ∅ , { even , odd } ) , so that ∀ ρ − ∈ Env ∅ . ∀ p ∈ { even , odd } . m ( ρ − )( p ) = [[ S p ]] ρ − . Recall the denotations [[ S even ]] ρ − and [[ S odd ]] ρ − from the end of Section 3.1.Components m even and m odd are composable, and by Definition 3, theircomposition has (the same) interface ( ∅ , { even , odd } ) , and is (also) a mapping m even × m odd : Env ∅ → Env { even , odd } .Finally, note that function χ + m even × m odd : Env { even , odd } → Env { even , odd } isexactly the function ξ in the context of the interface ( ∅ , { even , odd } ) . Thiscan be seen by first noting that since Env ∅ = ∅ , we have that χ + m even × m odd only depends on its arguments. Furthermore, for all ρ + ∈ Env { even , odd } , if ρ + odd def = ρ + (cid:12)(cid:12) { odd } and ρ + even def = ρ + (cid:12)(cid:12) { even } we have that, since odd ∈ P − even ∩ P + odd ,then χ + m even × m odd ( ρ + )( even ) = m even ( ρ + odd )( even ) = [[ S even ]] ρ + odd = [[ S even ]] ρ + = ξ ( ρ + )( even ) . Similarly χ + m even × m odd ( ρ + )( odd ) = ξ ( ρ + )( odd ) . We therefore have m even × m odd = m . 20e now define how to abstract Hoare logic contracts into denotational con-tracts, in terms of the contract environment ρ c defined in Section 3.2. Definition 13 (From Hoare logic contracts to denotational contracts) . Fora procedure p with Hoare logic contract C p , calling other procedures P − , wedefine the denotational contract c p = ( ρ − c p , ρ + c p ) with interface P + c p def = { p } and P − c p def = P − , so that ρ + c p ( p ) def = ρ c ( p ) , and ∀ p ′ ∈ P − . ρ − c p ( p ′ ) = ρ c ( p ′ ) . In this way, conceptually, denotational contracts become assume/guarantee-style specifications over Hoare logic procedure contracts: assuming that all (ex-ternal) procedures called by a procedure p transform the state according to theirHoare logic contracts, procedure p obliges itself to do so as well.We now show that if a procedure implements a Hoare logic contract, then theabstracted component will implement the abstracted contract, and vice versa.Together with Theorem 4, this result allows the procedure-modular verification of abstract components. Theorem 5. For any procedure p with procedure contract C p , abstracted intocomponent m p with contract c p , we have S p | = crpar C p iff m p | = c p .Proof. First, the interfaces will agree: P + m p = { p } = P + c p , and P − m p = P − c p sincethey are both the set of called procedures.Next, [[ S p ]] cr = [[ S p ]] ρ c by definition (see Section 3.2), i.e., the contract-relative denotation of S p is relativised on the contract environment ρ c , and sois ρ − c p according to Definition 13. If we have that S p | = crpar C p , then [[ S p ]] ρ c ⊆ [[ C p ]] , and since ρ + c p ( p ) = [[ C p ]] then [[ S p ]] ρ c ⊆ ρ + c p ( p ) . Because ρ c and ρ − c p agree onall denotations for procedures in P − c p , and because only the denotations of theprocedures in P − c p affect the denotation of p , then we also have [[ S p ]] ρ − cp ⊆ ρ + c p ( p ) .Since m ( ρ − c p )( p ) = [[ S p ]] ρ − cp and P + m p = { p } , then m ( ρ − c p ) ⊑ ρ + c p . Finally, since P − m p = P − c p , we have m ( ρ − c p ⊔ ρ ⊤ P − mp \ P − cp ) = m ( ρ − c p ) and therefore m | = c . Thesame argument holds in the other direction.Returning to the example from Sections 3 and 5, we can abstract the pro-cedure set { even } into component m even , with interface ( { odd } , { even } ) , whichwould be a function Env { odd } → Env { even } , and ∀ ρ − ∈ Env { odd } . m ( ρ − )( even ) =[[ S even ]] ρ − . The denotational contracts c even and c odd resulting from the decom-position shown in Section 5, would be exactly the abstraction of the Hoare Logiccontracts C even and C odd shown in Section 3.2. They would both be part of thecontract environment used in procedure-modular verification, for example whenverifying that S even | = crpar C even , which would entail m even | = c even . Thus, byapplying standard procedure-modular verification at the source code level, weprove the top-level contract c proposed in Section 5.21 Conclusion We presented an abstract contract theory for procedural languages, based on de-notational semantics. The theory is shown to be an instance of the meta-theoryof [5], and at the same time an abstraction of the standard denotational seman-tics of procedural languages. We believe that our contract theory can be used tosupport the development of cyber-physical and embedded systems by the designmethodology supported by the meta-theory, allowing the individual proceduresof the embedded software to be treated as any other system component. Thework also strengthens the claims of the meta-theory of distilling the notion ofcontracts to its essence, by showing that it is applicable also in the context ofprocedural programs and deductive verification. Finally, this work serves asa preparation for combining our contract theory for procedural programs withother instantiations of the meta-theory. In future work we plan to investigatethe utility of our contract theory on real embedded systems taken from the au-tomotive industry, where not all components are procedural programs, or evensoftware (cf. our previous work, e.g., [11]). We also plan to extend our toy im-perative language with additional features, such as procedure parameters andreturn values. Furthermore, we plan to extend the contract theory to captureprogram traces by developing a finite-trace semantics, to enable its use in thespecification and verification of temporal properties. Lastly, we plan to combineour contract theory with a contract theory for hybrid systems [19]. References [1] Abadi, M., Lamport, L.: Composing specifications. ACM Trans. Program.Lang. Syst. 15(1), 73–132 (Jan 1993)[2] Bauer, S., David, A., Hennicker, R., Larsen, K., Legay, A., Nyman, U.,Wasowski, A.: Moving from specifications to contracts in component-baseddesign. In: Fundamental Approaches to Software Engineering. pp. 43–58(2012)[3] Bekić, H.: Definable operation in general algebras, and the theory of au-tomata and flowcharts. In: Programming Languages and Their Definition -Hans Bekić (1936-1982). Lecture Notes in Computer Science, vol. 177, pp.30–55. Springer (1984)[4] Benveniste, A., Caillaud, B., Ferrari, A., Mangeruca, L., Passerone, R.,Sofronis, C.: Multiple viewpoint contract-based specification and design.In: Formal Methods for Components and Objects. vol. 5382, pp. 200–225(10 2007)[5] Benveniste, A., Caillaud, B., Nickovic, D., Passerone, R., Raclet, J.B.,Reinkemeier, P., Sangiovanni-Vincentelli, A., Damm, W., Henzinger, T.A.,Larsen, K.G.: Contracts for System Design, vol. 12. Now Publishers (2018), http://dx.doi.org/10.1561/1000000053 https://doi.org/10.1007/978-3-319-98047-8_8https://doi.org/10.1007/978-3-319-98047-8_8