describing, structuring and implementing objects

to be published in the Proceedings of the REX Workshop on Foundations of Object-Oriented Languages

DESCRIBING, STRUCTURING and IMPLEMENTINGOBJECTS

J.Fiadeiro1 and T.MaibaumDepartment of Computing

Imperial College of Science, Technology and Medecine180 Queen's Gate, London SW7 2BZ, UK

Abstract - The popularity of the notion of object for structuring (the specification of) systems has not been accompaniedby the necessary formalisation of the concepts and constructions involved. We have a well developed theory of abstractdata types that explains how to structure specifications based on the notion of value, but objects involve imperativenotions such as those of action and state which are not well captured in an applicative way. In this paper, we focus on thedevelopment of an alternative framework to support systems design based on the concept of object. We provide a notion ofobject signature around which we define the notion of locality (encapsulation). We adopt a deontic action logic for thedescription of objects. We define the notion of morphism between object descriptions, and show how these notions can beused to combine object descriptions and, in this way, define the behaviour of societies of interacting objects. And, finally,we show by means of an example how object descriptions may be reified by implementing descriptions of objects at onelevel (of abstraction) in terms of object descriptions at the level below.

1 Introduction

The concept of object, as an "entity" that has an identity independent of its state, that encapsulates acollection of attributes (its private memory) which it is able to manipulate according to a well definedset of actions, and that is able to interact with other objects, has emerged as one of the most powerfulabstractions for structuring systems design. As argued in [Sernadas et al 89b], by incorporating statesand behaviour, the concept of object is rich enough to capture the wide variety of phenomena that isusually involved in design, so that it becomes possible to consider each layer of the systemsdevelopment process to be structured uniformly as a collection of interacting objects. Likewise, duringreification, it allows us to regard each design step as the implementation of some abstract object interms of a collection of concrete ones that are "assembled" into a configuration that provides thefunctionality required by the abstract object. Naturally, the process ends when a layer of objects that donot need to be implemented is reached, either because they correspond to "real-world" entities, or theyare supported by the chosen programming and database environment, or by the existing operatingsystem.

Although the concept of object can be traced back to 1967 with Simula [Dahl et al 67], and theprinciples for programming/specifying "in the large" (modular decomposition and stepwise refinement)have been layed since [Hoare 72; Parnas 72], the ensuing work of formalisation has been developedmainly by the so-called ADT school (since [Zilles 74; Goguen et al 78]) around the notion of value asopposed to object. As put in [Schuman and Pitt 87], although both concepts play an important rôle,they also reflect a fundamental technical distinction. The notion of a data type as a collection of datadomains and operations on these domains is purely applicative. In contrast, the concept of object thatwe have in mind involves imperative notions (eg the notion of state, of action) that cannot beaccommodated easily within this applicative view. We do recognise that it is possible to model thenotion of state as a value (as another data domain) so that actions are just operations on that additionaldata domain, but this does not provide the right level of abstraction at which we want to deal with

1 on leave from Departamento de Matemática, Instituto Superior Técnico, Lisbon,as a grantee of the Commission of the European Communities.

DESCRIBING, STRUCTURING AND IMPLEMENTING OBJECTS 2

objects. On the one hand, we do want objects to have an identity independent of their state so that theycan be named and manipulated as a coherent unity and, on the other hand, the treatment of thebehavioural notions, in particular the notions of interaction, safety and liveness which are intrinsic toobjects as dynamic entities, does not seem to be given a satisfactory account in this applicative way.

Hence, although the ADT school of thought has successfully clarified the "in the large" techniques(structured specifications, modularisation, implementation, …) based on the notion of value, we claimthat the formalisms that have been used (in general, more or less exotic first-order equationalformalisms) are not the most adequate for formalising the use of the concept of object as a buildingblock for systems design. The purpose of this paper is to present an alternative formal framework thatwe have been developing towards the description of objects and their societies. This is part of anintegrated research effort on object-oriented systems design that started with [Sernadas et al 87, 89a],and which is also addressing the semantic fundamentals of the notion of object [Ehrich et al88a,88b,90; Ehrich and Sernadas 89], a specification language and its semantics [Fiadeiro et al 90;Sernadas and Saake 89], as well as methodological aspects of object-orientation [Sernadas et al 88;Sernadas et al 89b].

Taking into account the great success of formal accounts of change and behaviour based on temporal ordynamic logics, be it for axiomatising programming (since [Pratt 76]), for reasoning aboutconcurrency and other aspects of reactive systems (since [Pnueli 77]), or for the specification ofinformation systems and databases (since [Sernadas 80]), it seemed obvious that we should turn tomodal formalisms as an alternative to first-order logics. It still remained to choose a particular modallogic that would enable us to describe objects at the desired level of abstraction, and still be able tosupport the desired "in the large" techniques, both towards "horizontal" structuring (ie, the structuringof a specification in terms of modules within the same layer of development) and "vertical" structuring(ie, the implementation of objects in one layer of abstraction in terms of the objects of the layer below).

Fortunately, the work of Goguen and Burstall on institutions [Goguen and Burstall 84] and of otherauthors in what could be called abstract specification theory (eg [Maibaum 86; Fiadeiro and Sernadas88b; Gergely and Úry 88]) has shown us that many aspects of specification in the large, namely theability to put together small specifications to form the specification of a complex system, depend onlyon some properties of the underlying logic. For instance, if the underlying consequence relationsatisfies some structural properties, the category of specifications (as theory presentations) will befinitely cocomplete and, hence, we will be able to understand the process of specifying a system ofinterconnected components through colimits of diagrams in the category of specifications.

As we shall discuss later on, the chosen logic satisfies some of these requirements, and followsprevious work on action, deontic and temporal logics (eg, [Fiadeiro and Sernadas 86, 88a, 89;Fiadeiro and Maibaum 89a; Khosla et al 86; Khosla and Maibaum 89]). It will not be possible to give afull account of this logic in the paper, namely of the proof theory that is being developed for derivingproperties of specifications. The reader interested in more specific details should consult [Fiadeiro andMaibaum 89, 90a; Fiadeiro and Sernadas 89] for several of its fragments.

We must stress that we will not be proposing herein any new specification language (see [Fiadeiro et al90; Sernadas and Saake 89] for preliminary steps in that direction) but merely a formalism to supportthe desired object-oriented techniques. Drawing a parallel with the ADT school, we shall not beproposing an alternative to Clear based on objects, but an alternative to the equational institution inorder to support object-oriented design. This also means that we adhere to the use of the categorialdogma in systems specification [Goguen 89] and, hence, throughout the paper, we shall tread along


the well established path that directs us to the identification of the concepts of signature, language andconsequence relation of the logic, and of the structuring principles that are to support the horizontal andvertical structuring of specifications.

In section 2, we introduce the local aspects of object descriptions. First of all, we introduce the notionof object signature which is the core concept in this formalisation effort. It is around the notion ofsignature that the notion of locality (data abstraction, encapsulation of a set of attributes) - itself, in ouropinion, the core concept of object orientation - must be understood and formalised. Next, the notionof object description is introduced as a collection of formulae in a logic that includes positional (modal)operators to describe the effects of the events on the attributes, and two (deontic) predicates ofpermission and obligation with which the behavioural aspects are modelled. Finally, we briefly addressthe notions of safety and liveness.

Then, in section 3, we show how we can put descriptions together in order to form the description ofmore complex objects. First, we show how to define a category of object descriptions that is finitelycocomplete. Then, we show how interaction between objects can be expressed through diagrams.And, finally, we show how the colimit of a diagram describes the joint behaviour of the objects in thediagram taking into account their interaction. A simplified version of the well known example of theproducer-consumer-buffer is used throughout for the purposes of illustration.

Finally, in section 4, we shall discuss the process of implementation of an abstract description (that ofthe buffer) on top of more concrete ones (an array and two pointers). In particular, we shall discuss thecounterpart of the locality principle (data encapsulation) as the structuring principle at the horizontallevel, which is given in terms of an "action encapsulation" that makes the base of the implementation"private" to the abstract object.

2 Describing objects

From a formal point of view, we shall consider object descriptions to be theory presentations in acertain logic. That is to say, an object description will consist of a signature (defining the specificvocabulary symbols that are relevant for the description of the object), and a collection of formulae ofthe language generated from the signature (the non-logical or extra-logical axioms of the description).In this section, we shall put forward the notion of signature and the language that we shall adopt, aswell as a notion of interpretation structure.

As we have mentioned in the introduction, the formalism to be adopted for supporting object-orientedspecification should be adequate from the point of view of the three directions that we shall discuss inthe paper: description, structuring and implementation. Although, as shown in [Fiadeiro and Maibaum90b], the intended support for the (horizontal) structuring mechanisms can be achieved throughtemporal logics such as [Barringer 87], we chose a logic that combines positional (modal) operators todefine the effects of actions as in dynamic logic with deontic predicates of permission and obligation onactions to define the behavioural aspects. On the one hand, such a combination has proved to beadequate for systems specification (eg, [Goldsack and Howels 89; Khosla and Maibaum 89; Jeremeaset al 86; Maibaum 87]), having the advantage of distinguishing between description and prescription ofbehaviour. On the other hand, it has also been shown that the traditional notions of safety and livenesscan be captured in such a formalism by introducing the notion of (normative) trajectory, extending thelanguage with temporal operators and deriving a temporal consequence relation [Fiadeiro and Maibaum


89]. Hence, expressive power is not lost (rather, is gained). In this section, we show how thesenotions can be used to describe objects, namely how the notion of locality may be formalised, andbriefly hint at the notions of safety and liveness. More details on the proof theory and the connectionswith temporal logic may be found in [Fiadeiro and Maibaum 90a].

2.1 Object signatures

Signatures provide the different structures of vocabulary symbols that the language will deal with.Naturally, these structures have a meaning (semantics) that can be captured in the way they aremanipulated by the proof system, reflecting their use in specification. However, herein, we shall not beable to provide the intended proof system (see [Fiadeiro and Maibaum 90a] instead), and will limitourselves to present a notion of interpretation structure in order to clarify their intended semantics.Recognising the rôle of signatures as components of descriptions is very important because thesignature of a description defines the boundaries of the object in the sense that it will limit the "things"we may refer to during its specification: when reasoning about a component, we must use the languageof that component. In other words, it will enforce immediately a "syntactical locality", ie anencapsulation at the level of the language that is used for object description.

Taking into account the nature of our specifications, an object signature must be comprised of at leastthree different components: the universe component, the attribute component, and the actioncomponent. The universe component includes the information that is state-independent and that gives,so to say, the data context in which the object is placed. It can be seen as defining the frame ofreference with respect to which change is to be measured. The attribute component keeps theinformation that is state dependent. Examples of these structures can be found under different namesgiven according to the "nature" of the object: eg, program variables, database attributes, or frame slots.The action component accounts for the actions that the object may perform. These will correspond bothto what is usually called methods, ie operations on the state of the object, and to communicationactivities (for which we adopt synchronous communication by action sharing).

Definition 2.1.1 (object signature): An object signature is a triple (Σ,Α,Γ) where• Σ=(S⊕ E,Ω) is a signature (the universe signature) in the usual algebraic sense [Ehrig and

Mahr 85], ie S is a set (of sorts) and Ω is a S*×S-indexed family (of function symbols). Thesymbol E stands for the sort of events.

• Α is a S*×S-indexed family (of attribute symbols). In programming terms, a nullary attributesymbol corresponds to a program variable, whereas non-nullary attribute symbols can beassociated with more complex data structures such as arrays.

• Γ is an S*-indexed family (of action symbols). The parameters of an action symbol may stand,for instance, for the data that is necessary in order to define the effects of the actions on theattributes, or that is to be transmitted/received as part of a communication activity. However, atthis level of abstraction, we shall not distinguish between input and ouptut parameters. º

The families Ω, Α, Γ are assumed to be disjoint and finite (ie, there is only a finite number of functionsymbols, attribute and event symbols). The distinction between function (Ω) and attribute (Α) symbolswill have a semantic counterpart: function symbols will be given a rigid interpretation (sate-independent), whereas attribute symbols will be non-rigid.

For illustration, we shall use the well known producer-consumer-buffer example. In this example, it istrivial to recognise three different types of activity, corresponding to three types of objects. Naturally,


these activities are not independent. However, each makes a coherent unit in terms of local behaviour,which we formalise by defining three signatures - PRODUCER, CONSUMER and BUFFER:

PRODUCER

universe signature: attribute symbols:

sorts: current: ITEM

ITEM, BOOL waiting: BOOL

function symbols: action symbols:

boolean operations including produce(ITEM)

true, false: BOOL

store(ITEM)

Intuitively, current stores the current item produced by the producer, and waiting indicates whether theproducer is waiting to store the last item that was produced. These are attributes (non-rigid designators)as they will likely be the subject of change affected by actions.

The universe symbols give the standard operations on booleans, and include the sort symbol ITEM

standing for the items that are produced. Although we shall not explicitly address genericity andparameterisation, this sort can be thought of as being "generic", and the signature to be "parameterised"by this sort symbol, in the sense that this sort is "arbitrary".

The chosen action symbols account for the production and storage of items. Notice that there is noreference to the buffer in which the produced items will be stored. We shall see later on (section 3)how we can establish a relationship between a producer and a buffer by requiring them to synchroniseon the store actions. But, producers have a behaviour of their own, and that local behaviour is thetarget of the specification of producers as objects. On the other hand, the signature above may be seenas an "interface" of a more complex activity of production with the system that we are interested in(transmission of the produced items to consumers via a buffer). The other aspects of the productionactivity may be modelled as objects themselves which, together with the one we are considering, formdifferent parts of a (more) complex object. For instance, another object might be concerned with theselection of the items to be produced, eg imposing that an item may be produced only once. Thismodular decomposition of the problems, and the definition of the adequate interfaces to the parts of thesystem that are relevant to the problem at hand, are one of the advantages of object-orientation, and onethat should be reflected at the formal level. We shall further comment on these issues in section 3.

When we abstract from the consumer activity the behaviour that is of interest in connection to theproducer-consumer-buffer system, we find out that it is very "similar" to the production interface:

CONSUMER


sorts: current: ITEM

ITEM, BOOL waiting: BOOL


boolean operations including consume(ITEM)

true, false: BOOL

extract(ITEM)


Indeed, we could prove that the two signatures are isomorphic. We shall further explore this similaritywhen describing the behaviour of consumers and of producers. However, we should stress that theuse of the same symbols in both signatures (PRODUCER and CONSUMER) does not mean (or hint at)any relationship between the objects. The use (meaning) of symbols is local to the signature. As weshall explain in section 3, such relationships must be explicitly stated via morphisms.

Finally, let us consider the buffer:

BUFFER


sorts: pending: ITEM → INT

ITEM, INT, BOOL action symbols:

function symbols: put(ITEM)

usual operations on INT and BOOL get(ITEM)

This is a very "abstract" buffer: it is able to indicate for each item the number of "copies" that have beenproduced but not consumed (ie, it keeps a multiset of items), and has two actions accounting forstoring and extracting items. We shall see later on how we can reify such buffers into more concreteobjects such as queues and arrays.

2.2 The semantic structures

A semantic interpretation structure for an object signature is given by an algebra that interprets theuniverse parameters, a collection of events which model the behaviour of a (sequential) observer, amapping that gives the values taken by the attributes in the traces (finite sequences of events), and tworelations between events and traces (of permission and obligation):

Definition 2.2.1 (θ-interpretation structures): A θ−interpretation structure for a signatureθ=(Σ,Α,Γ) is a quadruple (U,I,P,O) where:

• U is a Σ-algebra such that EU is non-empty.

• I maps:– f∈Α <s1,…,sn>,s to I(f): s1U

×...×snU ×E

U*→ s

U ;– g∈Γ <s1,…,sn> to I(g): s1U

×...×snU ×E

U*→ ℘ (E

U ).

We shall often use I(f)(w) for w∈ EU* to denote the function λ(b1,…,bn).I(f)(b1,…,bn,w)

• P and O are relations in EU ×EU

*. º

We recall that E is the sort of events, so that EU is its interpretation (a set) in the algebra U . As usual,

EU* denotes the set of finite sequences of events (traces). Traces will play the rôle of "possible worlds"

in the interpretation of the modal language to be proposed below, so that an interpretation structureprovides the necessary Kripke semantics. Hence, attribute symbols are mapped to trace-dependentfunctions, ie the value of an attribute depends on the current state.

Action symbols are interpreted at each trace as defining subsets of the set of events. The intendedinterpretation is that an event is an abstraction of an atomic state transition according to some observer.The interpretation of the action symbols gives for each such event the set of actions that take placeduring the event. We shall say that the actions in each such set occur concurrently during that event.For instance, it is possible to define an interpretation structure such that every event witnesses the


occurrence of every action, corresponding to an observer that cannot discriminate between the actionsthat may occur. However, in most cases, such an observer will not provide a model of a specification.Indeed, the ability of actions to occur concurrently is restricted through the axioms of a specificationdefining their effects on the attributes as well as restrictions and requirements on their occurrence. Onthe other hand, it is possible that an event does not belong to any of the interpretations of the actionsymbols. These events denote observed behaviour in which the object is not engaged. They may beseen to be performed by the "environment", ie by any other component in the system that was notrequired to synchronise with the object at that step. Hence, using the terminology of [Barringer 87],we are dealing with open semantic structures in the sense that we are considering an object asembedded in a wider environment.

From a dual point of view, we can see action symbols as defining subsorts for the sort of events. Thatis, action symbols classify the events according to their "nature". Naturally, hierachies of suchsubsorts may be defined. This classification is state-dependent in order to support state-dependenthierachies between action sorts, namely for reflecting "choice" (as an action constructor).

An interpretation structure as defined above provides notions that are typical of any discrete model ofbehaviour such as transition systems. However, we should stress that this semantic notion differs frommore conventional ones, and in particular from [Ehrich et al 88a, 88b, 90], where sets of life cycles(runs or execution sequences) account for the behaviour of an object. As explained in [Khosla andMaibaum 89], the "deontic" model was preferred because, on the one hand, it is more general,allowing us in particular to formalise other kinds of information like error recovery through correctiveactions, or sanctions if desired (see, for instance, [McCarty 83; Minsky and Lockman 85; Khosla andMaibaum 89; Wieringa et al 89]), and, on the other hand, because it will support a more descriptiveaccount of the behaviour of an object in the sense that we will not be modelling directly the allowed lifecycles but describing instead the behavioural properties that they must satisfy. This has an impact at theformal level by separating the absence of normative behaviours (empty set of life cycles) or occurrenceof non-normative behaviour from inconsistency of a specification. This point has been illustrated in[Fiadeiro et al 90].

Before proceeding to the definition of the language supporting the description of objects, it is importantto analyse a restriction to the notion of θ−interpretation structure that will formalise the desired notionof locality. As motivated in the introduction, objects have an intrinsic notion of locality according towhich only the actions declared for an object can change the values of its attributes. This notion oflocality is incorporated into the notion of θ-interpretation structure through the requirement that whenan observer does not witness the occurrence of one of the actions of the object, ie when it witnesses anevent during which the object is not involved, then he cannot witness any change to the attributes:

Definition 2.2.2 (locality): Given an object signature θ=(Σ,Α,Γ) and a θ-interpretation structure(U,I,P,O) we define LU =e∈ EU e∈ gU (a1,…,an) for some g∈Γ and a1,…,an in the appropriatecarrier sets. Events belonging to LU are said to be local. The θ-interpretation structure is a θ-locus ifffor every e∉ LU,, for every trace w, for every f∈Α , I(f)(e::w)=I(f)(w). º

That is to say, the values of the attributes of the object can only be changed during witnessedtransitions, ie due to the occurrence of one of the actions of the object. In other words, non-witnessedtransitions are silent in the sense that they have no effect in the local state of an object. Again, using theterminology of [Barringer 87], non-witnessed transitions are identity steps. Hence, although we areworking with global instants of time (in the sense that the object is not necessarily engaged in everytransition), we are requiring that to these global instants correspond "local" (private) states (identifying,


as usual, states with the interpretations of the attribute symbols). Hence, the components (objects) thatwe specify are "context" independent in the sense that state information is localised rather than sharedbetween components, a strategy for achieving high levels of modularity that can be traced back to[Parnas 72].

We should point out that this notion of θ-locus does not formalise locality per se: it must be understoodin conjunction with the notion of object description and of morphism between descriptions to be givenin section 3. Rather, our ultimate purpose is to provide a formalisation of locality as a criterion to havecomposable object descriptions as specification modules, for which the notion of θ-locus given aboveprovides a correct model-theoretic basis. We shall see later on that the notion of morphism of objectdescriptions will indeed capture the desired notion of encapsulation so that an object cannot refer to theattributes of another object (for "read" or "write" purposes) without incorporating it as a component.This means that we are not allowing for attributes to be observed "outside" an object, only by objectsof which it is a component.

The notion of local event depends on the signature in the sense that, fixing a domain of events, somewill be local for some signatures but not for others. This is similar, in a way, to the classification ofevents/actions used in [Barringer and Kuiper 84] as belonging to the system (object) or theenvironment, and that the authors claim to be the key to obtaining composable specifications. Theformer correspond in our case to the local events. Naturally, the same event may be local to twodifferent signatures. In this case, this means that the two objects synchronise at that event, which canbe seen as the concurrent "execution" of the two actions involved (one from each signature).

The notion of θ-locus specifies private attributes but not private actions: we are adopting the "sharedactions" rather than the "shared variables" paradigm. Naturally, it could be argued that it would beuseful to be able to declare that some action is local (internal) to an object in the sense that it cannot beshared with any other object. In the formalism that we are proposing, this can be done by constrainingthe specifier in the way he is allowed to use morphisms. That is, it is a constraint that can be enforcedat the level of a specification language built on top of this formalism. We shall return to this point insection 3.3. However, we should stress that it is essential that such local actions be declared in thesignature of an object because, otherwise, we would not be able to reason about the behaviour of theobject in terms of proving properties of its attributes. Indeed, the signature of an object must declare allthe actions that are "authorised" to manipulate the attributes that were declared, even if some are local tothe object. Besides, notice that "hiding" of actions, a mechanism that is sometimes used for controllingthe scope of program variables, is not necessary here because the notion of scope is explicilty dealtwith through the signatures (and signature morphisms).

This is also different from making the internal structure of the actions available. Indeed, for horizontalstructuring, ie the structuring of specifications in a fixed layer of the development process byconnecting objects via their abstract properties (descriptions) alone, the internal structure of the actions,showing how they are "implemented" in terms of "lower level" objects (ie "closer" to the intendedimplementation layer), is hidden. Hence, connecting objects is done at each layer for the fixedgranularity that is given by the actions that were declared for the objects. Naturally, formal techniquesfor supporting vertical structuring, ie for supporting the "implementation" of abstract objects on top ofmore concrete ones are necessary, and we shall focus on them in section 4.

2.3 Object descriptions


The language that we use for describing objects distinguishes three syntactic categories defined alongwith two consequence operators. We shall assume a collection ξ of variables (distinct from the attributeand action symbols). Given an object signature, by a classification Ξ we mean a partial function ξ→S(S being the set of sorts of the universe signature). We shall also denote by Ξ the S-indexed set givenby Ξs=x∈ξ | Ξ(x)=s.

Definition 2.3.1 (terms) Given an object signature θ and a classification Ξ, we define inductivelythe S-indexed set of terms TRθ(Ξ) as follows:

• variables: if Ξ(x)=s, then x is a term in TRθ(Ξ)s;• if f∈Ω <s1,…,sn>,s and ti are terms in TRθ(Ξ)si then f(t1,…,tn)∈ TRθ(Ξ)s;• if f∈Α <s1,…,sn>,s and ti are terms in TRθ(Ξ)si then f(t1,…,tn)∈ TRθ(Ξ)s;• if e is an event term, ie e∈ TRθ(Ξ)E, and t∈ TRθ(Ξ)s then ([e]t)∈ TRθ(Ξ)s ([e]t reads "t after e");• if t∈ PTθ(Ξ)s then ([]t)∈ TRθ(Ξ)s ([]t reads "first t").

Given a θ−interpretation structure S=(U,I,P,O), a classification Ξ, and an assignment A for Ξ (afunction from Ξs to sU, for each s) each term t∈ TRθ(Ξ)s defines a mapping œt“S,A: EU * → s

U (its

interpretation) as follows:– if x∈Ξ s, œx“S,A(w)=A(x);– if f∈Ω <s1,…,sn>,s, œf(t1,…,tn)“S,A(w) = fU (œt1“

S,A(w),…,œtn“S,A(w));

– if f∈Α <s1,…,sn>,s, œf(t1,…,tn)“S,A(w) = I(f)(œt1“S,A(w),…,œtn“

S,A(w),w);– œ[e](t)“S,A(w) =œt“S,A(œe“S,A(w)::w);– œ[](t)“S,A(w) =œt“S,A(<>).

The set of action terms ATθ(Ξ) is also defined as follows:• if g∈Γ <s1,…,sn>, and ti are terms in PTθ(Ξ)si, then g(t1,…,tn)∈ ATθ(Ξ)

and action terms are interpreted as follows:– œg(t1,…,tn)“S,A(w) = I(g)(œt1“

S,A(w),…,œtn“S,A(w),w)

Notice how all the symbols belonging to the universe signature are rigid designators, ie theirinterpretation is state-independent (the interpretation of a symbol f in the algebra U is denoted by fU). Inparticular, variables are assigned a constant element of the domain: we recall that these are not meant as"program variables" (which are given herein through attributes) but as "logical variables". Finally, [e]tdenotes the value that t denotes after the event denoted by e occurs, and []t denotes the value that tdenotes in the empty trace (initial state). These are positional (modal) operators as defined in [Fiadeiroand Sernadas 89].

Also notice that operations on actions such as choice and synchronisation are easily defined. However,we shall not explore this expressive power herein. º

Terms provide us with the means to observe states. Basic judgements about these observations can bemade using state-propositions:

Definition 2.3.2 (state propositions): Given a classification Ξ, we define the set SP(Ξ) of statepropositions over Ξ as follows:

• g(e) for g an action term in ATθ(Ξ), and e an event term (action predicates);• (t1=st2) for t1 and t2 terms in TRθ(Ξ)s for some s∈ S (equality);• Per(e),Obl(e)∈ SPθ(Ξ) if e is an event term in PTθ(Ξ)E;• if e is an event term in PTθ(Ξ)E and p∈ SPθ(Ξ) then ([e]p)∈ SPθ(Ξ);• if p∈ SPθ(Ξ) then ([]p)∈ SPθ(Ξ).


• the usual first-order connectives, including– (p∨ q)∈ SPθ(Ξ) if p,q∈ SPθ(Ξ) (disjunction)– (p∧ q)∈ SPθ(Ξ) if p,q∈ SPθ(Ξ) (conjunction)– (∀ x:s)p∈ SPθ(Ξ) if p∈ SPθ(Ξ∪ x:s)– (∃ x:s)p∈ SPθ(Ξ) if p∈ SPθ(Ξ∪ x:s)

The satisfaction of a state proposition by a structure S and an assignment A at a trace w is defined asfollows:

– (t1=st2) is satisfied by S and A in w iff œt1“S,A(w)=œt2“S,A(w);– g(e) is satisfied by S and A in w iff œe“S,A(w)∈ œg“S,A(w);– Per(e) is satisfied by S and A in w iff (œe“S,A(w),w)∈ P ;– Obl(e) is satisfied by S and A in w iff (œe“S,A(w),w)∈ O ;– [e]p is satisfied by S and A in w iff p is satisfied in œe“S,A(w)::w;– []p is satisfied by S and A in w iff p is satisfied in <> (the empty trace).– the first-order connectives are interpreted as usual. º

State propositions provide us with the ability to assert properties of states (traces). In order to reasonabout these properties, we introduce a consequence operator on state-propositions with which weconstruct formulae as judgements over such state properties:

Definition 2.3.3 (formulae): Given a signature θ, and a pair (P1,P2) of (finite) sets of Ξ-statepropositions for some classification Ξ, (P1→Ξ P2) is a θ-formula . We shall assume the usualabbreviated notations such as (P →Ξ p) instead of (P→Ξp), (P1,P2→Ξ P'1,P'2) instead of(P1∪ P2→Ξ P'1∪ P'2), etc.

From the point of view of logical consequence, → will be given an underlying "at a trace" or "in aworld" notion of consequence, formulae being regarded as sequents (in the sense of proof theory) overstate propositions: a θ−formula (P1→Ξ P2) is true in a θ-structure S iff, for every assignment A andtrace w, if all the propositions in P1 are satisfied by S and A in w, then there is a proposition in P2 thatis also satisfied by S and A in w. º

Formulae assert properties that we wish to hold for every trace, ie they assert properties of a "model".Hence, it is at this syntactic level of consequence that we describe objects:

Definition 2.3.4 (descriptions): An object description is a pair (θ,F) where θ is an objectsignature and F is a (finite) set of θ-formulae (the axioms of the description). º

That is, an object description is a theory presentation of the logic. For instance, consider thedescription of producers. Besides the axioms on the booleans, we could have:

p1) produce(i)(x) →i:ITEM,x:E [x]current = i p5) produce(i)(x), Per(x) →i:ITEM,x:E waiting = false

p6) store(i)(x), Per(x) →i:ITEM,x:E current = i

p2) produce(i)(x) →i:ITEM,x:E [x]waiting = true p7) store(i)(x), Per(x) →i:ITEM,x:E waiting = true

p3) store(i)(x) →i:ITEM,x:E [x]waiting = false

p4) →Ø []waiting = false p8) waiting=true →Ø (∃ x:E)(store(current)(x)∧ Obl(x))

That is, p1 asserts that every event that behaves like a produce, ie during which a produce occurs, setscurrent to the produced item. Likewise, p2 asserts that a produce sets waiting to true. On the otherhand, p4 is an initialisation condition: it asserts that the initial value of waiting is false. With respect to


permissions and obligations, p5 asserts that a produce can only be witnessed when waiting is false,and p8 requires that a store of the current item be obligatory when waiting is true. We shall commentlater on on the semantics of such permissions and obligations.

It is interesting to note how the axioms of a description specify dependence relations (interference)between the actions, limiting their ability to occur during the same event. For instance, p1 implies thatproduce actions for different items interfere with each other. Indeed, it is trivial to derive the property

produce(i)(x), produce(j)(x) →i:ITEM,x:E (i = j)

stating that different produce actions cannot occur during the same event. Likewise, p2 and p3 implythat produce and store actions interfere and that, hence, produce and store actions cannot occur duringthe same event. Finally, p6 requires that only the current item is permitted to be stored, implying thatdifferent store actions interfere. Hence, we obtain the overall sequential behaviour that could beexpected: a producer produces an item and must wait till that item is stored before producing anotheritem.

The constant use of the event variables in these formulae may seem to be too cumbersome and, in fact,abbreviations could be defined allowing for the use of action terms standing for "variables" of thesubsort of the event sort defined by the action term. Alternatively, we could have defined terms astaking values in the power set of the carrier set, ie terms would denote sets of values instead of values,as done, for instance, in [Fiadeiro and Sernadas 89]. Although this extension would bring the languagecloser to [Fiadeiro et al 90], allowing us to write

p1) →i:ITEM [produce(i)]current = i p5) Per(produce(i)) →i:ITEM waiting = false

p6) Per(store(i)) →i:ITEM current = i

p2) →i:ITEM [produce(i)]waiting = true p7) Per(store(i)) →i:ITEM waiting = true

p3) →i:ITEM [store(i)]waiting = false

p4) →Ø []waiting = false p8) waiting=true →Ø Obl(store(current))

we chose to stay closer to the more "classic" approach of terms as denoting values, as the introductionof non-deterministic terms would require a more detailed account of their axiomatics and pragmatics.

Naturally, a calculus is needed for supporting the derivation of such properties of descriptions. Such acalculus may be defined as in [Fiadeiro and Maibaum 90a] by axiomatising a third level of consequenceallowing us to form judgements over formulae:

Definition 2.3.5 (assertions): If F is a (finite) set of formulae over a signature θ, and f is also aformula over θ, (F ⇒ θ f) is an assertion. Such an assertion is said to be valid iff every θ−object thatmakes all the formulae in F true also makes f true. º

However, due to space limitations, we shall not be able to present such calculus in the paper.

Assertions allow us to reason about properties that hold in any trace of an object. However, we usuallyattach an operational meaning to the notion of permission and obligation in terms of which we canspeak about the normative behaviours of an object: those where events occur only when permitted andwhere obligatory events are eventually performed. These normative behaviours characterise the safetyand the liveness properties of an object:


Definition 2.3.6: Given a θ-interpretation structure S=(U,I,P,O), a trajectory T for S and θ is aninfinite sequence over EU. A safe trajectory T is such that, for every i, (T(i+1),T i)∈ P. A livetrajectory T is such that, for every i, (e,Ti)∈ O implies that there is j>i such that e=T(j). A safe and livetrajectory is said to be normative. º

That is to say, a safe trajectory is one where each event in the sequence is permitted in the traceconsisting of the events that have already occurred, and a live trajectory is one where every event that isobligatory after a prefix of the trajectory will occur later on in the trajectory. These notions give, in away, a semantics for the concepts of permission and obligation.

As is well known, temporal logic has been found to be quite suitable for reasoning about safety("something bad will never happen") and liveness properties ("something good will eventuallyhappen") [eg Manna and Pnueli 81]. In [Fiadeiro and Maibaum 89a] we have already shown how it ispossible to reason about such temporal properties of systems from a specification of their behaviourgiven in terms of permissions and obligations as above. Basically, we can introduce an additionalconsequence relation and corresponding notion of assertion:

Definition 2.3.7: Given a signature θ, a finite set F of positional formulae and a temporal formula fover θ, (F ⇒ ;nθ f) is an assertion. Such an assertion is said to be valid iff f is true in every normativetrajectory of every θ-object where all the formulae of F are also true. º

Please refer once more to [Fiadeiro and Maibaum 89] for an axiomatisation of this consequencerelation, providing calculi of safety and liveness properties.

We end this section with the description of consumers and buffers. With respect to consumers, wemight have:

c1) extract(i)(x) →i:ITEM,x:E [x]current = i c5) extract(i)(x), Per(x) →i:ITEM,x:E waiting = false

c6) consume(i)(x), Per(x) →i:ITEM,x:E current = i

c2) extract(i)(x) →i:ITEM,x:E [x]waiting = true c7) consume(i)(x), Per(x) →i:ITEM,x:E waiting = true

c3) consume(i)(x) →i:ITEM,x:E [x]waiting = false

c4) →Ø []waiting = true c8) waiting=true → (∃ x:E)(consume(current)(x)∧ Obl(x))

It is easy to see that we obtain the overall sequential behaviour that could be expected: a consumerextracts an item and must wait till that item is consumed before extracting another item. Notice that, atthe level of an object, we are likely to have only partial information about the actions of that objectbecause they may be shared. For instance, we expect the extract action of a consumer to be shared witha buffer. However, in the description of a consumer, we only give the information about the extractaction that is local from the point of view of the consumer. Constraints on the permission to perform anextract that depend on the state of the buffer, eg the buffer not being empty, are not meaningful at thislevel.

With respect to the buffer, we could specify its behaviour as follows:

b1) put(i)(x) →i:ITEM,x:E [x]pending(i) = pending(i)+1 b4) get(i)(x), Per(x) →i:ITEM,x:E pending(i)>0

b2) get(i)(x) →i:ITEM,x:E [x]pending(i) = pending(i)-1

b3) →i:ITEM []pending(i) = 0


Notice that, for different items, these actions do not interfere and, hence, we leave open the possibilityof having concurrent access to the buffer. However, a put and a get of the same item interfere and,hence, cannot occur concurrently. That is, we can easily derive from these axioms

put(i)(x), get(i)(x) →i:ITEM,x:E

If we want to allow concurrency between put and get of the same item, we have to change ourdescription. For instance, we could have instead:

b1) put(i)(x) →i:ITEM,x:E ([x]pending(i) = pending(i)+1), get(i)(x)

b2) get(i)(x) →i:ITEM,x:E ([x]pending(i) = pending(i)-1), put(i)(x)

b5) put(i)(x), get(i)(x) →i:ITEM,x:E [x]pending(i) = pending(i)

That is, a put only increases the number of items pending if it does not occur simultaneously with a getof the same item, and mutatis mutandis for gets. Axiom b5 describes the concurrent behaviour of a putand a get: the number of pending items is kept unchanged. Notice, however, that b4 specifies that thisconcurrent execution of put and get is only permitted when there is at least one item pending. In otherwords, the execution of a put cannot enable a concurrent get.

Finally, it seems interesting to say that, using the calculi being developed (eg, [Fiadeiro and Maibaum90a]), it is easy to derive as a liveness property of the producer

p1-p8 ⇒ ;nPRODUCER (waiting=true) → F(waiting=false)

That is, thanks to the obligation to store the current item, a producer will always eventually cease to bewaiting. Naturally, this is a property of the normative behaviours of the producer. A safety property ofthe buffer will be, for instance,

b1-b5 ⇒ ;nBUFFER (pending≥0)

That is, in normative trajectories of the buffer, the number of occurrences of an item that are pendingwill never decrease below zero. This is a consequence of axiom b4, and we shall see in section 4 howit can be used when implementing the buffer.

3 Structuring objects

In the previous section, we discussed the description of atomic objects. However, one of therequirements of object orientation is the support for operations that allow us to build the description ofa more complex object from the description of its components. Formal tools for this purpose can beborrowed from category theory: as stated in [Goguen and Ginali 78], "given a category of widgets, theoperation of putting a system of widgets together to form a super-widget corresponds to taking acolimit of the diagram of widgets that shows how to interconnect them". From the specification pointof view, the idea is to use theory presentations as modularisation units, ie "putting theories together tomake specifications" [Burstall and Goguen 77]. Hence, we have to build the required category ofobject descriptions, ie we have to provide a notion of morphism between theory presentations, andprove that it allows for such colimits to be computed (is finitely cocomplete).


3.1 Morphisms of object descriptions

As structure-preserving mappings, morphisms establish the relationship that must exist between twoobject descriptions so that one of them may be considered as a component of the other. Intuitively, thiscorresponds to the notion of interpretation between theories used, for instance, in [Veloso and Pequeno81]. Using the notion of institution put forward in [Goguen and Burstall 84], this relationship consistsof a translation between the languages of the two descriptions (a signature morphism) such that thetheorems of one of them are translated to theorems of the second one. That is, we take the preservationof theorems (the meaning of a theory presentation) as the criterion for considering that a theorypresentation describes a component of a system which is described through another theorypresentation.

Definition 3.1.1: Given two object signatures θ1=(Σ1,Α1,Γ1) and θ2=(Σ2,Α2,Γ2), a morphism σfrom θ1 to θ2 consists of

• a morphism of algebraic signatures συ: Σ1→ Σ2;• for each f: s1,…,sn→s in Α1 an attribute symbol σα(f): συ(s1),…,συ(sn) → συ(s) in Α2;• for each g: s1,…,sn in Γ1 an action symbol σγ(g): συ(s1),…,συ(sn) in Γ2. º

That is to say, we are merely requiring that a signature morphism identifies the symbols in θ2 that areused to interpret (implement) the symbols of θ1. This is the "obvious" notion of signature morphism.It is easy to prove:

Proposition 3.1.2: Object signatures and signature morphisms constitute a category SIGN. Thiscategory is finitely cocomplete, and has (Ø,Ø,Ø) as the initial object signature (denoting also by Ø theinitial algebraic signature). º

The translation of formulae associated with a signature morphism is defined as follows:

Definition 3.1.3: Given a signature morphism σ: θ1→θ2• given x∈Ξ s, σ(x) is x• if f∈Ω <s1,…,sn>,s then σ(f(t1,…,tn)) is συ(f)(σ(t1),…,σ(tn))• if f∈Α <s1,…,sn>,s then σ(f(t1,…,tn)) is σα(f)(σ(t1),…,σ(tn))• σ([e]t) is [σ(e)]σ(t)• σ([]t) is []σ(t)

• σ(t1=t2) is (σ(t1)=σ(t2))• … º

Based on these notions of signature morphism and formula translation, we would like to define amorphism between two descriptions (θ1,F1) and (θ2,F2) as a signature morphism that induces aproperty preserving translation, ie such that for every formula f for which (F1 ⇒ θ1 f) is valid, (F2 ⇒ θ2σ(f)) is also valid. Because proving the existence of a morphism in this way requires the derivation ofan infinite set of assertions (one for each formula), we would also like to be able to conclude theexistence of a morphism between two descriptions by checking only that the axioms of the sourcedescription are translated to theorems of the target description, ie by proving that (F2 ⇒ θ2 σ(f)) is validfor every f∈ F1. However, for this to be possible, we know [Fiadeiro and Sernadas 88b] that theunderlying consequence relation must be structural, ie that given an arbitrary set of θ1-formulae F anda θ1-formula f, if (F ⇒ θ1 f) is valid then (σ(F) ⇒ θ2 σ(f)) must also be valid (which also means that


⇒ θ2 alone is able to "implement" ⇒ θ1). And it is easy to see that, in our case, ⇒ θ is not structural:consider the formula

→x:E ( ∨ ;g∈Γ 1

(∃ xg)g(xg)(x)) ∨ (∧ ;a∈Α 1

(∀ xa)([x]a(xa) = a(xa)))

where for each symbol u, xu is a tuple of variables (all distinct) of the appropriate sorts. This formulastates that, for every event, either it witnesses the occurrence of one of the actions of the object, or elseit leaves every attribute invariant. Notice that this is indeed a formula because Α and Γ are finite (cfdefinition 2.1.1). It is easy to see that this formula corresponds to the locality requirement (2.2.2) and,hence, is a theorem of (θ1,F1). However, it is also easy to see that its translation is not necessarily atheorem of (θ2,F2). That is to say, the fact that the axioms of a description are preserved does notimply that the locality of the attributes is preserved. This can also be understood from a more "model-theoretic" point of view. The notion of reduct of interpretation structures along a signature morphism iseasily defined as follows:

Definition 3.1.4: Given two object signatures θ1=(Σ1,Α1,Γ1) and θ2=(Σ2,Α2,Γ2), and a morphismσ from θ1 to θ2, we define for every θ2-interpretation structure S=(U,I,P,O) its reduct along σ as theθ1-interpretation structure S|σ= (U|σ,I|σ,P,O) where

– for every s∈ S, sU |σ= συ(s)U and EU |σ= EU ;– for every f: s1,…,sn→s in Ω1 fU |σ= συ(f)U ;– for every f: s1,…,sn→s in Α1, I |σ(f)(w) = I(σα(f))(w);– for every f: s1,…,sn in Γ1, I |σ(g)(w) = I(σγ(g))(w) º

It is straightforward to prove the satisfaction condition [Goguen and Burstall 84]:

Proposition 3.1.5: Given a θ2-interpretation structure S, a θ1-formula f is true in S|σ iff σ(f) is truein S. º

However, the same result does not hold if we take θ-loci instead of θ-interpretation structures asmodels because the reduct of a θ2-locus is not necessarily a θ1-locus: an event that is local to θ2 is notnecessarily local to θ1. Hence, when defining the notion of a morphism σ between two objectdescriptions (θ1,F1) and (θ2,F2) we cannot require only for every θ2-locus O validating F2 that O|σvalidates F1 (as usual), but we must also require that O|σ be a θ1-locus. Hence, the structure ofcomponents must be preserved in a strong sense.

Thus, given theory presentations (θ1,F1) and (θ2,F2), and a morphism σ between their signatures,besides requiring that the axioms of (θ1,F1) be translated to theorems of (θ2,F2), ie that (F2 ⇒ θ2 σ(f))be valid for every f∈ F1, we have to require that the translation of the locality axiom also be a theoremof (θ2,F2). That is, we require that the locality of the "smaller" component be preserved. This issimilar to what happens with interpretations of first-order theories [Enderton 72], where besideshaving to translate axioms to theorems we have to prove a certain number of closure and non-emptiness conditions. This extra requirement also has a counterpart in the formalism used in [Barringerand Kuiper 84]: the "matching rules". Indeed, it is easy to see that this extra condition "encodes" theparadigm (shared vs distributed variables vs synchronised actions vs...) that the logic is formalising, iethat is being supported by the formalism. A similar phenomenon occurs in [Barringer 87] where therule for parallel composition must be adapted to the paradigm that is being supported.

We shall abbreviate the translation of the locality axiom, ie the θ2-formula


σ(→x:E ( ∨ ;g∈Γ 1

(∃ xg)g(xg)(x)) ∨ (∧ ;a∈Α 1

(∀ xa)([x]a(xa) = a(xa))))

by θ1→;σθ2, ie by the signature morphism itself. Hence, in order to obtain a morphism of theorypresentations, we also have to prove that (F2 ⇒ θ2 θ1→;σθ2) is valid.

Besides representing a notational convenience, the choice of this abbreviation was also made so as torelate the rôle of this formula with the extension of languages with signature morphisms as proposed in[Goguen and Burstall 84]. This extension is needed to express constraints on the interpretationstructures when the language is not expressive enough to support them: a θ-interpretation structuremakes θ'→;σθ true iff its σ-reduct satisfies the desired constraint, in this case iff it is a θ'-locus.

Finally, we have:

Proposition 3.1.6: Object descriptions and their morphisms form a category DESC. Moreover, thiscategory is finitely cocomplete. The initial description is (Ø,Ø) and a pushout of two descriptionmorphisms µ1: (θ,F) → (θ1,F1) and µ2: (θ,F) → (θ2,F2) is given by the object description(θ1«θθ2,σ1(F1)∪σ 2(F2)∪ θ1→ ;

σ1 θ1«θθ2, θ2→ ;σ2 θ1«θθ2) where θ1«θθ2, σ1 and σ2 are a

pushout of µ1 and µ2 as signature morphisms. The signature θ1«θθ2 is obtained by taking theamalgamated sums of the components of θ1 and θ2, ie we take their disjoint union and identify thesymbols that they share with θ. An example will be provided in section 3.3.

º

Hence, besides containing the union of the sets of axioms of the components (after translation), apushout (and a colimit) will also contain the translation of the locality theorems of the components.This means that the structure of the complex object (given by the colimit) is explicitly recorded. Asexplained in [Sannella and Burstall 83], the structure of a theory can be useful in directing the search ofa proof. Hence, this added knowledge about the structure of the object is also very important forachieving modularity in the verification process because it allows us to break down proofs into lemmasthat may be proved locally as theorems of the relevant components, and later on composed intoproperties of the complex object. See [Fiadeiro and Maibaum 90a, 90b] for examples.

As we shall see in the next section, combinations of several objects into a "community" can beachieved through colimits of diagrams. A result from Category Theory says that, because the categoryof theory presentations admits an initial element (the empty presentation), every colimit (of finitediagrams) may be constructed by using pushouts as defined in 3.1.6. Pushouts are, indeed, the mostbasic operations for combining two objects: putting them in parallel but requiring them to synchronisevia a common sub-object. That is, a pushout achieves the operation (θ1,F1) ||(θ,F) (θ2,F2) whichgeneralises synchronisation at a set of actions. Non-synchronised parallel composition of componentsis just a particular case: it corresponds to taking the shared sub-object to be the empty one (Ø,Ø). Thatis, (θ1,F1) || (θ2,F2) is just the coproduct of the object descriptions.

3.2 Object communities

Morphisms are the formal tools that we use to express interconnections between objects: two objectsinteract by sharing some other object. Naturally, this sub-object may be as simple as an action. Indeed,it is easy to isolate an action as an "atomic" object


ACTION

universe signature: attribute symbols: action symbols: axioms:

Ø Ø a Ø

that can be used to connect two other objects via a certain action in which they will be required tosynchronise. We shall give examples below. However, we must stress that our definition of morphismrequires that, if two objects are to have an attribute in common, then they must also share all the actionsthat update that attribute. Indeed, mere sharing of attributes is forbidden by the formalism because it isimpossible to isolate an attribute as a sub-object. For instance, the object described through

ATTRIBUTE


Ø a Ø Ø

has the following locality requirement:

→x:E ([x]a = a)

requiring the attribute to remain invariant under any possible event. This is due to the fact that we havespecified an empty set of action symbols. Hence, only constant attributes may be isolated and shared.Otherwise, we need to surround the attribute with all the actions that update it. It is easy to see that, inthe case of the isolated action, the locality requirement is vacuous due to the fact that there is an emptyset of attribute symbols. Hence, any description admits ACTION as a sub-description as long as itcontains an action symbol.

It is in this sense that we claim to have captured encapsulation in our framework. Encapsulation meansthat attributes (state) cannot be separated from the actions that update them and, hence, imposes adiscipline in the way we are allowed to structure our specifications, ie in the way we can interconnectcomponents.

Let us see how the interaction between a producer and a buffer may be established. First, it isnecessary to define the "middle object" that will be shared between them. It is easy to see that thismiddle object can be reduced to the action in which the producer and the buffer will synchronise:

ATOM


BOOL, ITEM Ø a(ITEM) Ø

Notice that the universe signature is not empty: it contains the boolean sort and operations together withthe sort symbol ITEM in order to express (via the morphisms below) that these symbols are common tothe producer and the buffer.

It remains to define the morphisms that connect ATOM to the descriptions PRODUCER and BUFFER:


store: ATOM → PRODUCER put: ATOM → BUFFER

universe universe

identity morphism inclusion morphism

actions actionsa |→ store a |→ put

That is, via the two morphisms store and put, the two objects may be declared to share the action ofstoring an item.

The same object may be used to connect a consumer and a buffer, although through differentmorphisms:

extract: ATOM → CONSUMER get: ATOM → BUFFER

universe universe

identity morphism inclusion morphism

actions actionsa |→ extract a |→ get

The joint behaviour of a producer, a consumer and a buffer interacting in this way is given by thecolimit of the diagram

PRODUCER ATOM BUFFER ATOM CONSUMER

put getstore extract

This colimit returns a description, the description of the "minimal" object that contains the depictedones as sub-objects, respecting their interaction as given by the morphisms. The signature of thiscomplex objects consists of the colimit of the signatures of the component objects: essentially, we takethe union of the signatures of the objects after having renamed the symbols in each signature takinginto account the sharing of symbols imposed by the morphisms:

PROD-BUF-CONS


sorts: P.current, C.current: ITEM

ITEM, BOOL, INT P.waiting, C.waiting: BOOL

function symbols: pending: ITEM → INT

true, false: BOOL action symbols:

usual operations on INT

deposit(ITEM)

withdraw(ITEM)

produce(ITEM)

consume(ITEM)

Let P, C, and B denote the morphisms that link, respectively, PRODUCER, CONSUMER, and BUFFER tothe new description PROD-BUF-CONS, and that are given by the colimit construction. With respect tothe action symbols, these morphisms map, respectively, store to deposit, extract to withdraw, and(put,get) to (deposit, withdraw). That is to say, we obtain in the colimit only one symbol for the actionof depositing an item, and which was identified in the producer as store and in the buffer as put, aswell as only one symbol for the action of withdrawing an item. This means that the objects synchroniseat the shared actions: the producer and the buffer for depositing an item, and the consumer and thebuffer for withdrawing an item.


With respect to the attribute symbols, and because the interaction morphisms do not identify theattribute symbols current and waiting of PRODUCER and CONSUMER, we obtain different symbols inthe colimit: P.current and P.waiting imported from PRODUCER, and C.current and C.waiting importedfrom CONSUMER. These actual names are not important as the colimit is obtained up to isomorphism.What is important is that different names be assigned to the symbols imported from the twocomponents. As we mentioned in the previous section, symbols are local to a signature and the use ofthe same symbol in two different signatures is meaningless: any sharing has to be explicitly stated viamorphisms.

According to 3.1.6, the axioms of the new description are obtained by taking the union of thetranslations of the axioms of the component descriptions and adding the structural axioms. The fact thatthe translations identify symbols from different components is reflected in the axioms of the newdescription: because the action symbols store of PRODUCER and put of BUFFER are mapped to deposit,axioms p3, p6, p7, p8, and b1 now refer to the new action symbol:

p3) deposit(i)(x) →i:ITEM,x:E [x]P.waiting = false

p6) deposit(i)(x), Per(x) →i:ITEM,x:E P.current = i

p8) P.waiting = true →Ø (∃ x:E)(deposit(P.current)(x)∧ Obl(x))

b1) deposit(i)(x) →i:ITEM,x:E ([x]pending(i) = pending(i)+1), withdraw(i)(x)

And mutatis mutandis for extract, get and withdraw. Notice that, as a result, the constraints add-up forthe shared actions. For instance, there are now two restrictions on the permission for the actionwithdraw to be performed:

c5) withdraw(i)(x), Per(x) →i:ITEM,x:E C.waiting = false

b4) withdraw(i)(x), Per(x) →i:ITEM,x:E pending(i)>0

c5 (imported from the consumer's description) requires that C.waiting be false, ie that there be no itemwaiting to be consumed, and b4 (imported from the buffer's description) requires the item to be,indeed, pending. Hence, by renaming actions from different components to the same name, theconstraints specified locally add-up for the shared actions in a natural way.

Finally, it is important to stress that we do not obtain in the colimit non-interference axioms, such as

consume(i)(x) →i:ITEM,x:E [x]P.waiting = P.waiting

requiring that actions from one object (in this case, consumes performed by the consumer) not interferewith the attributes of another object (in this case, the attribute waiting of the producer). Intuitively, wecould think that these axioms would be necessary, or left to some kind of frame rule, in order toexpress that the locality of the components is preserved in the global system. However, these formulaeare not even theorems of the global system. Instead, we have as axioms of the colimit the signaturemorphisms (ie, the translations of the locality axioms)

PRODUCER →;P PROD-BUF-CONS

BUFFER →;B PROD-BUF-CONS

CONSUMER →;C PROD-BUF-CONS


expressing precisely the intended locality preservation requirement. We should point out that havingthe signature morphisms (ie the translations of the locality requirements of the components) instead ofthe non-interference formulae as axioms reflects the fact that it is not a strict interleaving model that weare adopting for parallelism. Indeed, the locality preservation requirement expressed through themorphisms guarantees that each action from one component either occurs concurrently with an actionof another component (ie, the interpretations of two action symbols, one from each signature, haveevents in common), or does not interfere with the attributes of the other component. That is to say, theadopted construction leaves open the possibility of having events that belong simultaneously to actionsymbols inherited from different specifications and, hence, allows for concurrency between thedifferent components. For instance, we are allowing for the producer and the consumer to performtheir produce and consume actions concurrently. The non-interference formulae would prevent this byproviding a way of discriminating between the actions inherited from different signatures. That is, byforcing their effects on the attributes, they would make them observationally different. For instance,the formula above would prevent having events that belong simultaneously to the interpretations ofconsume and produce because that would require the attribute P.waiting to be set to true (axiom p2)and kept false (non-interference formula above). That is, the non-interference formula would preventboth actions from being obeserved to occur concurrently. Indeed, it is easy to see that they would forcea strict interleaving discipline.

The adopted semantics of parallelism is also more akin to the notion of colimit as a minimalcombination of the components: enforcing interleaving seems to be a design decision imposed on theirjoint behaviour. The general principle is that action symbols inherited from different signatures areusually unrelated and, hence, they should be allowed the maximum degree of freedom in terms of"occurring simultaneously". Hence, basically, the signature morphisms identify sub-components of anobject that should not interfere apart from the specified interfaces.

3.3 Interfacing

Suppose now that we want to connect not one but two producers to the buffer. Apparently, this couldbe easily achieved by adding to the previous diagram another node labelled by PRODUCER and linkingit to the buffer through another instance of ATOM and the appropriate morphisms.

The problem with the system described in this way is that, because the actions of storing an item fromthe two producers are identified with the put action of the buffer, they are themselves identified in thecolimit implying that the two producers would have to synchronise in order to store an item. This isclearly not what is intended. What we want is that the two producers may act independently to storeitems in the buffer.

The problem with the solution above is that, intuitively, we have connected the two producers to thesame "port" of the buffer. Indeed, from an intuitive point of view, each action of an object provides aport to which another object may be linked for communication. (The parameters of the action symbolprovide for the data that is to be exchanged). This port is fixed in the sense that every other objectconnected to that port must synchronise in order to communicate. Hence, if we want two objects tocommunicate independently with a third one, each via the same operation, we must make sure that theyare assigned different ports. In our case, this means that we have to extend the buffer signature in orderto provide different ports for each of the producers. That is to say, we have to provide an interfacethrough which we are able to connect independently two producers to one buffer. Such an interface canbe built as follows:


X-BUFFER

universe signature: action symbols:

as before get(ITEM)

attribute symbols: put(ITEM)

pending: ITEM → NAT put1(ITEM)

axioms put2(ITEM)

x1)-x4): as b1) - b5)

x6) put1(i)(x) →x:E,i:ITEM put(i)(x) x8) put1(i)(x), put2(i)(x) →x:E,i:ITEM

x7) put2(i)(x) →x:E,i:ITEM put(i)(x)

That is to say, we extend the signature with action symbols that allow for two different ways of usingthe buffer in order to store an item. Notice how axioms x5 and x6 state that we are not introducing newforms of behaviour but merely specialising existing ones: we are saying that the new actions are justspecialisations of the put action. Hence, locality is preserved and the extension does establish an'object' or a locus preserving morphism between the two descriptions. Axiom x8 specifies that the twospecialisations interfere, ie that no event can witness both a put1 and a put2 for the same item.Naturally, if different items are concerned, there is no interference.

The two producers can now be connected independently, one by sharing the put1 action and the otherone by sharing the put2 action. This kind of extension can be applied in order to accomodate anynumber of different producers. Another possibility would be to parameterise this extension to a sort ofproducer identifiers PROD-ID leading to a new action symbol put(PROD-ID,ITEM) and the axioms

put(i,d)(x) →x:E,i:ITEM,d:PROD-ID put(i)(x)

put(i,d)(x), put(i,d')(x) →x:E,i:ITEM,d,d':PROD-ID d=d'

Naturally, the same construction may be applied to the get action in order to accomodate multipleconsumers.

Finally, if we want to prevent further extensions, we can "complete" the specialisation axioms in orderto specify that the only specialisations are those that have been introduced. In the first case, we wouldhave

put(i)(x) →x:E,i:ITEM put1(i)(x), put2(i)(x)

stating that a put action is either a put1 or a put2 action, and in the parameterised case

put(i)(x) →x:E,i:ITEM (∃ d:PROC-ID)put(i,d)(x)

Having specified these completion axioms, we can "hide" the old put symbol from the signature, andderive a new description where this action symbol is not mentioned:


D-BUFFER


as before get(ITEM)

attribute symbols: put1(ITEM)

pending: ITEM → NAT put2(ITEM)

axioms

d1) put1(i)(x) →i:ITEM,x:E [x]pending(i) = pending(i)+1 d4) →i:ITEM []pending(i) = 0

d2) put2(i)(x) →i:ITEM,x:E [x]pending(i) = pending(i)+1 d5) get(i)(x), Per(x) →i:ITEM,x:E pending(i)>0

d3) get(i)(x) →i:ITEM,x:E [x]pending(i) = pending(i)-1 d6) put1(i)(x), put2(i)(x) →i:ITEM,x:E

It is easy to see that we do have a morphism (inclusion) between D-BUFFER and X-BUFFER enrichedwith the completion axioms. (This is the semantics of derivation of a theory along a signaturemorphism used in CLEAR [Burstall and Goguen 77]). The relationship between these constructionsusing BUFFER can be summarised by the diagram:

X-BUFFERD-BUFFER BUFFER

We should stress that the need for these extensions and derivations is not violating our claims forsupporting modular specification. Having specified objects separately, we have to provide adequateinterfaces in order to connect them because they were defined without knowledge of which othercomponents they were going to be connected to. Indeed, notice that our X-BUFFER description merelyspecialised existing behaviour, which implies that the extension is conservative in the sense that nonew properties are added [Maibaum 86]. Naturally, D-BUFFER and X-BUFFER are already biasedtowards the desired configuration of two producers and one buffer. But this is how it should be: if adifferent configuration was desired, a different interface would have to be built.

Although these operations on theory presentations may seem to be too cumbersome, they are trivialexamples of well known constructions that are available in CLEAR-like specification languages[Burstall and Goguen 77]: going from BUFFER to X-BUFFER is an extension (a particular case ofenrichment), and going from X-BUFFER to D-BUFFER is a derivation. Hence, any specificationlanguage would make these operations easy to apply.

Finally, it is important to stress that whereas the description D-BUFFER is the one that we want to usefor interaction with producers, the original description BUFFER is the one that we want to give animplementor to work on, ie it is the one that we shall use for interfacing with the next lower layer of thevertical structuring process. The above diagram does correspond to a "design structure" as defined in[Maibaum 89], where D-BUFFER is the "user's view" of the object, BUFFER is the "implementor'sview" of the object, and X-BUFFER is the "body" which tells how the two other views are related.

4 Implementing objects

Besides providing support for structuring systems as communities of interacting objects (ie, forhorizontal structuring), our framework is also intended to provide support for the implementation ofthe objects used at each layer of development in terms of the objects available in the layer below (socalled vertical structuring). The idea is that each implementation step consists of assembling a collectionof concrete objects, through appropriate interfaces, into an object that provides the required


functionality, and to express how the abstract behaviour can be achieved on top of it. This relationshipcan be definitional in the sense that we can define explicitly how each abstract action is to beimplemented in terms of the concrete ones (through transactions) but, in general, it need not be so: wemay leave some freedom to the programmer who, following the requirements expressed at theimplementation step, will carry out the task of actually writing the code using the chosen environment(transaction language).

The nature of the formal support for this activity is as defined in [Maibaum and Turski 84]. Basically,we extend the concrete theory into a new theory and map the abstract description to this extension.However, it is easy to accept that the formal tools used for horizontal structuring cannot be applieddirectly to vertical structuring. For instance, structuring at the horizontal level is focused aroundlocality, ie locality is the structuring principle of the category of object descriptions as defined in theprevious section. In terms of vertical structuring, we are concerned with another notion of "locality":that the representations of the abstract actions (concrete transactions) are the only ones to actually occurin the life of the concrete objects. In other words, the concrete objects "respond" only to abstractactions.

In this section, we shall illustrate such an implementation step with an example, but omit the wholeformal background that supports it. See [Ehrich and Sernadas 90; Sernadas et al 90] for an account ofsuch an implementation step at the model-theoretic level.

4.1 The base: pointers and arrays

The example that we chose in order to illustrate an implementation step in our framework is theimplementation of the buffer on top of an array and two pointers. This is similar to the usual data typeimplementation of queues on top of arrays and pointers. Let us first describe these "concrete" objects.

A variable is an object that consists only of one attribute and two actions of read and write. Naturally,only write actions can change the value of the variable, and there is only permission to read the actualvalue of the variable:

VARIABLE


sorts: ANY value: ANY


... write(ANY)

axioms read(ANY)

write(a)(x) →a:ANY,x:E [x]value = a

read(a)(x) →a:ANY,x:E [x]value = value read(a)(x), Per(x) →a:ANY,x:E value=a

We can consider this description to be parameterised on the universe signature. For our purposes, weshall use the enumerated data sort [1..M] and the operation + of addition modulo M. If these datatypes, as well as these actions, are available in the target programming environment, this is an exampleof an object that would not need to be further reified. Notice that we can easily extend this descriptionin order to allow for multiple readers and writers by using the notion of interfacing discussed in section3.3. However, as could be expected, it is easy to see that, whereas read actions do not interfere witheach other, write actions do.


It is also interesting to illustrate the use of the notion of interfacing in building pointers as specialisationof variables. For our purposes, we are only interested in incrementing the values of such variables.That is, we are only interested in some specialised behaviour of variables. This specialised variablecould be described by extending the previous description with an action symbol inc and the axiom

inc(x) →x:E write(value+1)(x)

stating that incrementing the variable consists of writing the successor of the current value of thevariable. If we would further specify that we can only increment the variable, ie that the only writeactions available are those that increment the variable, eg through

write(a)(x) →a:ANY,x:E inc(x)

we could then hide the write action as we did in section 3.3, and obtain through a derivation thedescription:

POINTER


sorts: [1..M] value: [1..M]


+: [1..M],[1..M] → [1..M] inc

axioms

axioms on [1..M]

p1) inc(x) →x:E [x]value = value+1

As we mentioned in section 3.3, the point of building this specialisation is that it may be moreconvenient for horizontal structuring. In terms of implementing the specialisation, we also mentionedthat it may use any implementation of the initial description. But it may happen that more efficientimplementations exist for the specialised objects, as is often the case, and we may choose to implementthe specialised objects differently.

Let us get on with the description of our concrete objects, and focus now on the array.

ARRAY


sorts: ANY, INDEX value: INDEX → ANY


... write(INDEX,ANY)

axioms read(INDEX,ANY)

a1) write(i,a)(x) →i:INDEX,a:ANY,x:E [x]value(i) =

a a2)read(i,a)(x) → i,j:INDEX,a:ANY,x:E[x]value(j) = value(j)

a3) read(i,a)(x), Per(x) →i:INDEX,a:ANY,x:E value(i)=a

We further need the axiom


a4) →i:INDEX,x:E [x]value(i) = value(i), (∃ a:ANY)write(i,a)(x)

requiring that only actions occurring concurrently with a write to the ith-component change the ith-component. This axiom allows for concurrent access to the components. This concurrent access suitsour implementation of the buffer because it will allow for concurrent puts and gets. If, otherwise, thisconcurrent behaviour was not desired, we would have to further specify

write(i,a)(x), write(j,b)(x) →i,j:INDEX,a,b:ANY,x:E (i=j)

Again, we can consider this description to be parameterised on the universe signature. For ourpurposes, we shall use [1..M] for INDEX and ITEM for ANY.

The base-object of our implementation will consist of two instances of POINTER (a pointer to thebeginning of the representation of the buffer and a pointer to its end), and an instance of ARRAY for thebody of the buffer. This object BASE is the colimit of the diagram

ARRAY

INDEX

POINTER POINTER

where the middle object contains only the data type of the indexes of the array. Otherwise, thedescriptions share no attribute or action symbols and, hence, the base signature will consist of thedisjoint union of the component signatures (apart from the universe component). In order todistinguish between the symbols imported from each signature, we shall prefix them by FIRST andLAST for the two POINTER descriptions, and with ARRAY for the description of the array. That is, weshall have

BASE


sorts: [1..M], ITEM ARRAY.value: [1..M] → ITEM

function symbols: FIRST.value: [1..M]

... LAST.value: [1..M]

action symbols:

axioms ARRAY.write([1..M],ITEM)

ARRAY.a1-a4 ARRAY.read([1..M],ITEM)

FIRST.p1 FIRST.inc

LAST.p1 LAST.inc

s1) ARRAY →;ARRAY BASE

s2) POINTER →;FIRST BASE

s3) POINTER →;LAST BASE

where s1, s2 and s3 are the structurality axioms given by the colimit construction (the translations ofthe locality axioms of the array and the two pointers), ie


s1) →x:E [x]ARRAY.value(i)=ARRAY.value(i),

(∃ a:ITEM)(∃ j:[1..M])ARRAY.write(j,a)(x)∨ ARRAY.read(j,a)(x)

s2) →x:E [x]FIRST.value=FIRST.value, FIRST.inc(x)

s3) →x:E [x]LAST.value=LAST.value, LAST.inc(x)

4.2 Representing the abstract object

In order to represent the abstract object in terms of the base, we must start by extending the universesignature with sorts and functions that will assist us in representing the abstract data structures. Thebasic idea of implementing the buffer on top of the array is to represent the multiset of current items(pending) in terms of a queue defined over the [1..M]-indexed array of the base. For that purpose, weneed to extend our universe signature with integers (a trivial extension) and an operation that counts thenumber of occurrences of an item in the queue. However, one of the advantages of using the deonticnotions is that we may decide to restrict ourselves to the implementation of the normative behaviour ofthe abstract object, and give the implementor the freedom to deal with non-normative ones (errorrecovery, etc). Hence, for instance, in our case, because we have seen that in normative behaviours theabstract attribute pending takes values only in the natural numbers, we can restrict ourselves to workwith natural numbers instead of integers. The counting function could therefore be defined as:

count: [1..M]×[1..M]×ITEM[1..M]×ITEM → NAT

where the first argument stands for the first index where the search will start and the second argumentfor the index where the search will end. This operation may be defined as follows:

ct0) f>l → count(f,l,q,i)=0

ct1) q(f)=i → count(f,f,q,i)=1

ct2) q(f)≠i → count(f,f,q,i)=0

ct3) f≤l, q(l)=i → count(f,l+1,q,i)=count(f,l,q,i)+1

ct4) f≤l, q(l)≠i → count(f,l+1,q,i)=count(f,l,q,i)

It should be easy to derive

ct5) (∀ f≤x≤l)((q(x)=i)∨ (q'(x)=i)⊃ (q(x)=q'(x))) → count(f,l,q,i)=count(f,l,q',i)

That is, if two queues agree in the components where a certain item is stored, then that item has thesame number of occurrences in each of them. Furthermore, we should be able to derive

ct6) f<l, q(f)=i → count(f+1,l,q,i)=count(f,l,q,i)-1

ct7) f<l, q(l)≠i → count(f+1,l,q,i)=count(f,l,q,i)

giving recursion in the first pointer. Now we may represent the abstract attribute symbol

pending: ITEM → NAT

by

λi.count(FIRST.value,LAST.value,ARRAY.value,i)


It remains to choose representations for the abstract actions and prove that the axioms of the abstractobject description are theorems of the extension of the base description.

With respect to the get action, the idea is to implement it through an increment of the pointer FIRST.Choosing get* as the action symbol that represents the action symbol get of the abstract description, wewould specify

e1) get*(i)(x) →i:ITEM,x:E FIRST.inc(x)

e2) get*(i)(x), Per(x) →i:ITEM,x:E i=ARRAY.value(FIRST.value)

e3) get*(i)(x), Per(x) →i:ITEM,x:E FIRST.value≤LAST.value

The first axiom states that a get is implemented by an increment. The second one states that only getsfor the first element of the queue are permitted. The third axiom states that gets are only permitted whenthe queue is not empty. It is easy to see that these two last axioms "implement" b4. Indeed, it is easy toderive from the definition of count:

FIRST.value≤LAST.value, i=ARRAY.value(FIRST.value) →i:ITEM count(FIRST.value,LAST.value,ARRAY.value,i)>0

And from the axioms on the permission of get*:

get*(i)(x), Per(x) →i:ITEM,x:E count(FIRST.value,LAST.value,ARRAY.value,i)>0

which is the translation of b4. In order to prove the other axioms of the buffer, we need someknowledge about the implementation of puts. The intuition is that the action that will implement a putwill have to increment the pointer LAST and make an assignment to the array. This can be stated asfollows:

e4) put*(i)(x) →i:ITEM,x:E LAST.inc(x)

e5) put*(i)(x) →i:ITEM,x:E ARRAY.write(LAST.value+1,i)(x)

e6) put*(i)(x), Per(x) →i:ITEM,x:E LAST.value+1<FIRST.value+M

The last axiom states that a put is only permitted when the queue is not full. Notice that there is stillroom for manoeuvre for the programmer to decide how to actually implement the put operation in hislanguage: he can require the concurrent execution of the increment and the assignment to the array

LAST.inc || ARRAY.write(LAST.value+1,i)

or, instead, the transaction

LAST.inc ; ARRAY.write(LAST.value,i)

or even the transaction

ARRAY.write(LAST.value+1,i) ; LAST.inc

Taking the transactions as atomic events, any of these implementations should satisfy the specificationof put* above. However, we shall not be able to discuss transactions in the paper. Work ontransactions for object reification can be found in [Sernadas et al 90].


Finally, we must prove the correctness of the implementation step, ie that the translations of the axiomsof the abstract description (using the revised axioms that allow for concurrent puts and gets of the sameitem)

b1) put(i)(x) →i:ITEM,x:E ([x]pending(i) = pending(i)+1), get(i)(x)

b2) get(i)(x) →i:ITEM,x:E ([x]pending(i) = pending(i)-1), put(i)(x)

b3) →i:ITEM,x:E []pending(i) = 0

b5) put(i)(x), get(i)(x) →i:ITEM,x:E [x]pending(i) = pending(i)

are theorems of this extension of the base description (we have already proved b4). For that purpose,we must make explicit the "closure" assumption at the vertical level: that behaviour at the concrete levelis restricted to the representation of the abstract actions. This corresponds in our case to:

e7) FIRST.inc(x) →x:E (∃ i:ITEM)get*(i)(x)

e8) LAST.inc(x) →x:E (∃ i:ITEM)put*(i)(x)

e9) ARRAY.write(p,i)(x) →p:[1..M],i:ITEM,x:E put*(i)(x)

That is to say, an instance of the operation of incrementing the pointer FIRST is necessarily (aninstance) of the implementation of a get, an instance of incrementing the pointer LAST is necessarily theimplementation of a put, and an instance of an assignment to the array is necessarily an implementationof a put.

This last axiom together with e5 implies

ARRAY.write(p,i)(x) →p:[1..M],i:ITEM,x:E ARRAY.write(LAST.value+1,i)(x)

which, together with axiom a1 of ARRAY, implies

ARRAY.write(p,i)(x) →p:[1..M],i:ITEM,x:E p=LAST.value+1

That is to say, any assignment to the array that is witnessed is an assignment to the component of indexLAST.value+1. Together with the axiom a4 of ARRAY we have

r1) →p:[1..M],x:E [x]ARRAY.value(p) = ARRAY.value(p), p=LAST.value+1

That is to say, only the component of index LAST.value+1 can change value during an event. From thestructural axioms of the pointers in the base

s2) →x:E [x]FIRST.value=FIRST.value, FIRST.inc(x)

s3) →x:E [x]LAST.value=LAST.value, LAST.inc(x)

we also get from the closure axioms above the following properties

r2) →x:E [x]FIRST.value=FIRST.value, (∃ i:ITEM)get*(i)(x)

r3) →x:E [x]LAST.value=LAST.value, (∃ i:ITEM)put*(i)(x)

That is, the pointer will stay invariant during an event unless the implementation of a put or a getoccurs during that event. In a similar way, we derive


r4) →p:[1..M],x:E [x]ARRAY.value(p) = ARRAY.value(p), (∃ i:ITEM)put*(i)(x)

Let us now prove the correctness of the implementation by checking that the translations of axioms ofthe abstract description are theorems of this extension. Let us check b2. Because, as we have alreadymentioned, we only guarantee the implementation of normative behaviour, its translation is

Per(x), get*(i)(x) →i:ITEM,x:E[x]count(FIRST.value,LAST.value,ARRAY.value,i)=count(FIRST.value,LAST.value,ARRAY.value,i)-1, put*(i)(x)

That is, we prove b2 assuming the event is permitted. The proof is as follows:

1. [x]count(FIRST.value,LAST.value,ARRAY.value,i)

=count([x]FIRST.value,[x]LAST.value,[x]ARRAY.value,i) as explained below

2. [x]FIRST.value=FIRST.value+1 FIRST.p1

3. i=ARRAY.value(FIRST.value) e2

4. FIRST.value≤LAST.value e3

The equality in step 1 results from the fact that the symbol count belongs to the universe signature and,hence, is rigid (cf 2.3.1). Hence, a positional qualification is transferred to its arguments (see [Fiadeiroand Sernadas 89] for details). In order to calculate the value of [x]LAST.value we can use r3

→x:E [x]LAST.value=LAST.value, (∃ i:ITEM)put*(i)(x)

derived above. Assume first that (∃ i:ITEM)put*(i)(x) does not hold

5. [x]LAST.value=LAST.value r3

6. → [x]ARRAY.value(p) = ARRAY.value(p) r4

Again, we have two cases: either FIRST.value<LAST.value or FIRST.value=LAST.value holds. In the first case,

7. count([x]FIRST.value,[x]LAST.value,[x]ARRAY.value,i)

=count(FIRST.value+1,LAST.value,[x]ARRAY.value,i) 2, 5

=count(FIRST.value+1,LAST.value,ARRAY.value,i) 6, ct5

=count(FIRST.value,LAST.value,ARRAY.value,i)-1 Hyp, 3, ct7

In the second case (FIRST.value=LAST.value holds),


=count(FIRST.value+1,LAST.value,[x]ARRAY.value,i) 2, 5

=0 Hyp, ct0

9. count(FIRST.value,LAST.value,ARRAY.value,i)=1 Hyp, 3, ct1


=count(FIRST.value,LAST.value,ARRAY.value,i)-1 8, 9

So, it remains to check the case where (∃ i:ITEM)put*(i)(x) does hold. Because the consequent of thetranslation of b2 is a disjunction where one of the disjuncts is precisely put*(i)(x), we can assumeput*(j)(x) and j≠i and derive the other disjunct:

11. [x]LAST.value=LAST.value+1 Hyp, e4, LAST.p1


12. [x]ARRAY.value(LAST.value+1)=j a1, e5, Hyp

13. p≠LAST.value+1 → [x]ARRAY.value(p) = ARRAY.value(p) Hyp, r1


=count(FIRST.value+1,LAST.value+1,[x]ARRAY.value,i) 2, 11

Again, we have two cases corresponding to FIRST.value<LAST.value or FIRST.value=LAST.value. In the firstcase, we have

15. =count(FIRST.value+1,LAST.value,[x]ARRAY.value,i) ct4, 12, Hyp (i≠j)

=count(FIRST.value+1,LAST.value,ARRAY.value,i) 13, ct6

=count(FIRST.value,LAST.value,ARRAY.value,i)-1 3, ct5

In the second case,

16. =0 ct2, 12, Hyp (i≠j)

17. count(FIRST.value,LAST.value,ARRAY.value,i)

=1 3, ct1

=count([x]FIRST.value,[x]LAST.value,[x]ARRAY.value,i)+1 16

This completes our proof. The derivation of the translation of b1 and b5 would follow the samepattern. Because we have already proved the translation of b4, it would remain to prove theinitialisation condition b3. This can be trivially done if we extend the base description with thefollowing initialisation conditions:

[]FIRST.value = 1

[]LAST.value = 0

ie by initialising the pointers so that an empty queue is obtained.

Summarising, we have built the following extension of the base:

X-BASE = BASE extended with


sorts: NAT put*(ITEM)

function symbols: get*(ITEM)

count:...

operations of NAT

axioms

c0-c4

e1-e9

and mapped the description BUFFER to X-BASE by sending put to put*, get to get*, and pending toλi.count(FIRST.value,LAST.value,ARRAY.value,i). It is easy that we have morphisms linking each of thesedescriptions, leading to the implementation diagram:


BUFFER X-BASE

BASE

5 Concluding remarks

In this paper, we have shown how a formalism for assisting object-oriented systems development canbe defined around the notions of object signature, object description, and corresponding notions ofmorphism. In the adopted formalism, objects are described through theory presentations in a modallogic where the modal (positional) operators are used to describe the effects of the events on theattributes of the object, and where two (deontic) predicates of permission and obligation on events areused to describe normative behaviour.

With respect to the structuring of object descriptions, the well known categorial way of using colimitsof diagrams to aggregate components (objects) along designated interconnections [Goguen and Ginali78] was used. Indeed, the corresponding category of object descriptions is finitely cocomplete, whichalso provides the starting point for the definition of corresponding specification languages [Burstall andGoguen 77]. Preliminary work in that direction is reported in [Fiadeiro et al 90].

Another major aspect of our formalism refers to the treatment of locality, according to which only theactions declared for an object can update its attributes. This allowed us to have local (private) states.This principle of locality was incorporated into the logic, in the sense that morphisms are locality-preserving mappings, and its impact in the way object descriptions can be composed to formdescriptions of communities of interacting objects was discussed and illustrated using the producer-consumer-buffer example. In this context, we also discussed how the explicit recording of the structureof a complex object (through the locality preservation requirements) provided a weak "frame" principlethat is compatible with concurrency. And, although we were not able to report on the calculi that arebeing developed for reasoning about the properties of the described objects (see [Fiadeiro andMaibaum 90a]), this treatment of locality allows us to have rules for reasoning at the "global" levelsthat take into account the structure of the object in terms of its components, leading to the desireddegree of modularity in the verification process: we do not need the global specification of the systemto reason about its parts, and we can use the structure of the system in order to reason about its globalproperties.

We also gave the general principles of object implementation (vertical structuring) along an example:the implementation of a buffer on top of an array and two pointers. These principles seem to agree withthe notion of implementation step developed in [Maibaum and Turski 84] (interpretation of the abstracttheory into an extension of the base theory), as well as with the model-theoretic notion adopted in[Ehrich and Sernadas 89]. Further work is going on in order to incorporate the notion of transactioninto the formalism so that abstract actions may be mapped to transactions of concrete ones. Work onthis subject from a model-theoretic point of view can be found in [Sernadas et al 90].

As explained in the introduction, this work is part of an integrated effort of building a coherentframework to compete with the ADT school in addressing the whole stepwise development cycle ofsoftware systems. The methodological advantages of centring design around objects as opposed to


values have been pointed out several times [eg, Sernadas et al 89b], and it seems that we are finallyequiping ourselves with the appropriate tools to approach it in a formal way.

Acknowledgments

The authors wish to thank their colleague Paulo Veloso for many fruitful discussions on the subject ofimplementation. We also thank H.-D.Ehrich, U.Lipeck, A.Sernadas and C.Sernadas for stimulatingdiscussions on object description, structuring and implementation.

References

[Barringer 87]H.Barringer, "The Use of Temporal Logic in the Compositional Specification of ConcurrentSystems", in A.Galton (ed) Temporal Logics and their Applications, Academic Press 1987

[Barringer and Kuiper 84]H.Barringer and R.Kuiper, "Hierarchical Development of Concurrent Systems in a TemporalFramework", in S.Brookes, A.Roscoe and G.Winskel (eds) Seminar on Concurrency, LNCS197, Springer-Verlag 1984, 35-61

[Burstall and Goguen 77]R.Burstall and J.Goguen, "Putting Theories together to make Specifications", in R.Reddy (ed)Proc Fifth International Joint Conference on Artificial Intelligence, 1977, 1045-1058

[Dahl et al 67]O.-J.Dahl, B.Myhrhaug and K.Nygaard, SIMULA 67: Common Base Language, NorwegianComputing Center, 1967

[Ehrich and Sernadas 89]H.-D.Ehrich and A.Sernadas, "Algebraic View of Implementing Objects over Objects", inW.deRoever (ed) Stepwise Refinement of Distributed Systems: Models, Formalisms,Correctness, Springer-Verlag (in print)

[Ehrich et al 88a]H.-D.Ehrich, A.Sernadas and C.Sernadas, "Objects, Object Types and Object Identity", inH.Ehrig et al (eds) Categorical Methods in Computer Science with Aspects from Topology,LNCS 334, Springer-Verlag (in print)

[Ehrich et al 88b]H.-D.Ehrich, A.Sernadas and C.Sernadas, "Abstract Object Types for Databases" (extendedposition paper), in K.R.Dittrich (ed) Advances in Object-Oriented Database Systems, LNCS393, Springer-Verlag 1988, 449-463

[Ehrich et al 90]H.-D.Ehrich, A.Sernadas and C.Sernadas, "From Data Types to Object Types", Journal ofInformation Processing and Cybernetics EIK 26(1/2), 1990, 33-48

[Ehrig and Mahr 85]H.Ehrig and B.Mahr, Fundamentals of Algebraic Specification 1: Equations and InitialSemantics, Springer-Verlag 1985

[Enderton 72]H.B.Enderton, A Mathematical Introduction to Logic, Academic Press 1972

[Fiadeiro 89]J.Fiadeiro, Cálculo de Objectos e Eventos, PhD Thesis, Technical University of Lisbon, 1989

[Fiadeiro and Maibaum 89]J.Fiadeiro and T.Maibaum, "Temporal Reasoning over Deontic Specifications", Journal of Logicand Computation, to appear


[Fiadeiro and Maibaum 90a]J.Fiadeiro and T.Maibaum, Towards Object Calculi, Technical Report, Imperial College,London 1990

[Fiadeiro and Maibaum 90b]J.Fiadeiro and T.Maibaum, Temporal Theories as Modularisation Units for Concurrent SystemSpecification, Technical Report, Imperial College, London 1990

[Fiadeiro and Sernadas 86]J.Fiadeiro and A.Sernadas, "The Infolog Linear Tense Propositional Logic of Events andTransactions", Information Systems 11, 1986, 61-85

[Fiadeiro and Sernadas 88a]J.Fiadeiro and A.Sernadas, "Specification and Verification of Database Dynamics", ActaInformatica 25, 1988, 625-661

[Fiadeiro and Sernadas 88b]J.Fiadeiro and A.Sernadas, "Structuring Theories on Consequence", in D.Sannella andA.Tarlecki (eds) Recent Trends in Data Type Specification, LNCS 332, Springer Verlag 1988,44-72

[Fiadeiro and Sernadas 89]J.Fiadeiro and A.Sernadas, "Logics of Modal Terms for Systems Specification", Journal ofLogic and Computation, to appear

[Fiadeiro et al 90]J.Fiadeiro, C.Sernadas, T.Maibaum and G.Saake, "Proof-theoretic Semantics of Object-orientedConstructs", in W.Kent, S.Khosla and R.Meersman (eds) Object-Oriented Databases: Analysis,Design and Construction, North-Holland (to be published)

[Goldsack and Howells 89]S.Goldsack and P.Howells, Specifying Shared Resources in Modal Action Logic, TechnicalReport, Imperial College, London 1989

[Goguen 89]J.Goguen, A Categorical Manifesto, Technical Report PRG-72, Programming Research Group,University of Oxford, March 1989

[Goguen et al 78]J.Goguen, J.Thatcher and E.Wagner, "An Initial Algebraic Approach to the Specification,Correctness, and Implementation of Abstract Data Types", in R.Yeh (ed) Current Trends inProgramming Methodology, Vol 4, Prentice-Hall 1978, 80-149

[Goguen and Burstall 84]J.Goguen and R.Burstall, "Introducing Institutions", in E,Clarke and D.Kozen (eds) ProcLogics of Programming Workshop, LNCS 164, Springer-Verlag 1984, 221-256

[Goguen and Ginali 78]J.Goguen and S.Ginali, "A Categorical Approach to General Systems Theory", in G.Klir (ed)Applied General Systems Research, Plenum 1978, 257-270

[Gergely and Úry 88]T.Gergely and L.Úry, Constructive Specification Theory, Technical Report, Applied LogicLaboratory, Budapest 1988

[Hoare 72]C.A.R.Hoare, "Proof of Correctness of Data Representation", Acta Informatica 1, 1972, 271-281

[Jeremeas et al 86]P.Jeremeas, S.Khosla and T.Maibaum, "A Modal (Action) Logic for RequirementsSpecification", in D.Barnes and P.Brown (eds) Proc Software Engineering 86, IEE ComputingSeries 6, Peter Peregrinus 1986


[Khosla et al 86]S.Khosla, T.Maibaum and M.Sadler, "Database Specification", in T.Steel and R.Meersman(eds) Database Semantics (DS-1), North-Holland 1986, 141-158

[Khosla and Maibaum 89]S.Khosla and T.Maibaum, "The Prescription and Description of State-Based Systems", inB.Banieqbal, H.Barringer and A.Pnueli (eds) Temporal Logic in Specification, LNCS 398,Springer-Verlag 1989, 243-294

[Maibaum 86]T.Maibaum, "Rôle of Abstraction in Program Development", in H.-J.Kugler (ed) InformationProcessing'86, North-Holland 1986, 135-142

[Maibaum 87]T.Maibaum, A Logic for the Formal Requirements Specification of Real-Time EmbeddedSystems, Forest Research Report 1987

[Maibaum 89]T.Maibaum, Design Structures, private communication, Imperial College, London 1989

[Maibaum and Turski 84]T.Maibaum and W.Turski, "On What Exactly Goes On When Software Is Developed Step byStep" Proc. 7th Int. Conference on Software Enginnering, IEEE 1984, 528-533

[Maibaum et al 85]T.Maibaum, P.Veloso and M.Sadler, "A Theory of Abstract Data Types for ProgramDevelopment: Bridging the Gap?" in Formal Methods and Software Development, LNCS 186,Springer-Verlag 1985

[Manna and Pnueli 81]Z.Manna and A.Pnueli, "Verification of Concurrent Programs: The Temporal Framework", inR.Boyer and J.Moore (eds) The Correctness Problem in Computer Science, Academic Press1981, 215-273

[McCarty 83]L.McCarty, "Permissions and Obligations", IJCAI 83, 1983, 287-294

[Minsky and Lockman 85]M.Minsky and A.Lockman, "Ensuring Integrity by Adding Obligations to Priveleges", in Proc8th IEEE Int. Conf on Software Engineering, 1985, 92-102

[Parnas 72]D.Parnas, "On the criteria to be used in decomposing systems into modules", CommunicationsACM 15, 1972, 1053-1058

[Pnueli 77]A.Pnueli, "The Temporal Logic of Programs", in Proc 18th Annual Symposium on Foundationsof Computer Science, IEEE 1977, 45-57

[Pratt 76]V.Pratt, "Semantical Considerations on Floyd-Hoare Logic", in Proc. 17th IEEE Symposium onFoundations of Computer Science, 1976, 326-337

[Sannella and Burstall 83]D.Sannella and R.Burstall, "Structured Theories in LCF", in G.Ausiello and M.Protasi (eds)Proc. 8th Colloquium on Trees in Algebra and Programming, LNCS 159, Springer-Verlag1983, 377-391

[Schuman and Pitt 87]S.Schuman and D.Pitt, "Object-Oriented Subsystem Specification", in L.Meertens (ed) ProgramSpecification and Transformation, North-Holland 1987, 313-341

[Sernadas 80]A.Sernadas, "Temporal Aspects of Logical Procedure Definition", Information Systems 5, 1980,167-187


[Sernadas and Saake 89]C.Sernadas and G.Saake, Formal Semantics of Object-oriented Languages for ConceptualModeling, Technical Report, INESC, Lisbon 1989

[Sernadas et al 87]A.Sernadas, C.Sernadas and H.-D.Ehrich, "Object-Oriented Specification of Databases: AnAlgebraic Approach", in P.Hammersley (ed) Proc 13th VLDB Conference, Morgan Kaufmann1987, 107-116

[Sernadas et al 88]C.Sernadas, J.Fiadeiro and A.Sernadas, "Object-Oriented Conceptual Modeling From Law, inC.-H.Kung and R.Meersman (eds) The Role of Artificial Intelligence in Databases andInformation Systems, North-Holland (in print)

[Sernadas et al 89a]A.Sernadas, J.Fiadeiro, C.Sernadas and H.-D.Ehrich, "Abstract Object Types: A TemporalPerspective", in B.Banieqbal, H.Barringer and A.Pnueli (eds) Temporal Logic in Specification,LNCS 398, Springer-Verlag 1989, 324-349

[Sernadas et al 89b]A.Sernadas, J.Fiadeiro, C.Sernadas and H.-D.Ehrich, "The Basic Building Blocks ofInformation Systems", in E.Falkenberg and P.Lindgreen (ed) Information Systems Concepts:An In-depth Analysis, North-Holland, 1989, 225-246

[Sernadas et al 90]A.Sernadas, J.-F.Costa and H.-D.Ehrich, Object Reification within a Cocomplete Category ofSequential Objects, INESC 1990

[Turski and Maibaum 87]W.Turski and T.Maibaum, The Specification of Computer Programs, Addison-Wesley 1987

[Veloso and Pequeno 78]P.Veloso and T.Pequeno, "Interpretations between Many-sorted Theories", in Proc. 2ndBrasilian Colloquium on Logic, 1978

[Wieringa et al 89]R.Wieringa,J .Meyer and H.Weigand, "Specifying Dynamic and Deontic Integrity Constraints",Data and Knowledge Engineering 4(2), 1989, 157-189

[Zilles 74]S.Zilles, Algebraic Specification of Data Types, Project MAC Progress Report 11, MIT 1974,28-52

describing, structuring and implementing objects

Documents