Formalising Well-Behaved Components

Formalising Well-Behaved Components

Sotiris Moschoyiannis1, Michael W. Shields1 and Juliana Kuster-Filipe2

1 Department of Computing, University of SurreyGuildford, Surrey, GU2 7XH, England

{s.moschoyiannis, m.shields}@eim.surrey.ac.uk2 School of Informatics, University of Edinburgh

Edinburgh EH9 3JZ, [email protected]

Abstract

Present-day software systems are challenged by increasing demands for modifiability andevolvability to cater for changing requirements. Component-based development emerges asa key methodology for creating large-scale, evolvable systems in a timely fashion as it advo-cates the assembly of the final system from prefabricated replaceable software components.However, it is often the case that undesirable or unpredictable behaviour emerges whencomponents are combined. This is partly due to lack of behavioural information about theindividual components. In this paper, we describe a formal model for component speci-fication which can be used to identify potential instances of undesirable behaviour. Theapproach considers component behaviour modelled by so-called behavioural presentations, apowerful model of true-concurrency. Moreover, the framework is compositional as has beenshown in a companion paper [12]. Finally, we outline directions for future work.

1 Introduction

A component-based approach to software engineering emerges as a key paradigm for creatingsoftware-intensive systems. The idea is that the final system can be assembled from prefabricatedsoftware components, thus increasing the scope for reuse and replacement. However, it is oftenthe case that systems assembled from pre-built components exhibit undesirable or unpredictablebehaviour. One of the problems has to do with the fact that when a component is designed,its interface often does not contain enough or precise behavioural information. This makesit difficult to infer how the component will behave when placed in a particular context andcombined with other components.

Formalising Well-Behaved Components 122

Current component technologies such as CORBA, EJB and COM/.NET facilitate the develop-ment of the final system from pre-built software components by addressing, mostly, the syntacticdependencies between components. However, these technologies seem to lack an adequate treat-ment of components at the specification level. As a result, they offer little support for reasoningabout the final system before its parts have been combined, executed and tested as a whole.What we are mostly interested in the work presented here, is the semantic dependencies: whatcan be safely assumed about the behaviour of a software component, not just the syntax of howto interact with it.

We argue in favour of an a priori reasoning [10] approach to component-based software en-gineering in which reasoning about composition is based on the properties of the individualcomponents. Our efforts are directed at providing support for predicting properties of assem-blies of components before the actual composition takes place.

Given a partial description of the behaviour of a component, most likely described by a softwareengineer at the design level using UML [14, 3], the proposed mathematical framework can beused, behind the scenes, for reasoning about generic issues related to components and theircomposition aiming to reveal potential instances of undesirable behaviour. Ideally, appropriatetool support would allow feedback to be provided to the designer indicating what the componentactually does (possibly when combined with others), how it is to be deployed, and so on. Thefeedback produced by such tools should be given using notation well known to the designerwhich in our case is assumed to be UML. Considerations about the tools is, however, beyondthe scope of the present paper.

In this paper we describe a mathematical framework for formalising components at a semanticmodelling level. In particular, we provide a mathematical concept of a software component;its static structure is described by a sort while its dynamic characteristics are captured bybehaviour vectors. Essentially, these vectors are tuples of sequences of events which are used tomodel calls to interface operations of the component in question. More importantly, we identifyconditions that ensure that a component is well-behaved. The notion of well-behavedness inthis context is twofold. From a theoretical perspective, these conditions allow us to associate acomponent with an event structure-like behavioural model, called behavioural presentation [15].Using a behavioural presentation to capture component behaviour is advantageous in the sensethat temporal relations among occurrences of events can be derived in such a way that non-determinism, concurrency and simultaneity are treated as distinct phenomena. From a morepractical perspective, these conditions allow us to model the component receiving events andreacting to them, and also, allow for a precise description of the time ordering between calls tocomponent interface operations. The key point is that whenever this time ordering is respected,the component is guaranteed to behave in predictable ways.

The foundations of the mathematical framework are essentially those of [12]. The main differ-ence though is that while [12] focuses on the treatment of composition and the all importantpreservation of properties under the operation of composition, in this paper we focus on asso-ciating the model to behavioural presentations. In this way, the component model is given adenotational semantics and can be related to a general theory of non-interleaving representation

Report No. 284, September 2003 UNU/IIST, P.O. Box 3058, Macau


of behaviour [16].

This paper is structured as follows. In Section 2 we present the foundations of the abstractmathematical model and introduce two basic conditions imposed on components: discretenessand local left closure. This inspires the notion of well-behaved components. In Section 3we associate components with behavioural presentations, which can be used to capture theirpotential behaviour. Section 4 provides a brief overview of composition of components withinour model and shows that the proposed framework is compositional. The paper finishes with adiscussion on future work and some concluding remarks in Section 5.

2 Component Model

A component, at a specification level, can be seen as a software entity that provides servicesto other components and possibly requires services from other components in order to deliverthose promised. The offered services are made available via a set of ’provides’ interfaces whilethe reciprocal obligations are to be satisfied via a set of ’requires’ interfaces. Basic componentconcepts for specification are understood as essentially given in [8, 11].

Pictorially [20], a component is a square box with a number of input and output ports. Eachport is associated with an interface. We shall assume a countable infinite set I of interface namesand a countable infinite set Op of calls to operations of those interfaces, both sets remainingfixed for the remainder of this paper.

Definition 2.1 We define a (component) sort to be a tuple Σ = (PΣ , RΣ , βΣ) where,

• PΣ ⊆ I is a set of provides interfaces

• RΣ ⊆ I is a set of requires interfaces

• βΣ : PΣ ∪RΣ → ℘(Op); hence, βΣ(i) is the set of calls to operations associated with in-terface i

and we require that PΣ ∩RΣ = ∅. Define IΣ = PΣ ∪RΣ.

These sets and this function comprise the static structure of a typical software component. Asfor its dynamic characteristics we introduce the notion of behaviour vectors in our model.

Definition 2.2 Suppose that Σ is a sort. We define VΣ to be the set of all functions v : IΣ → O∗p

such that for each i ∈ IΣ, v(i) ∈ βΣ(i)∗. We shall refer to behaviour vectors of VΣ as βΣ-vectors.



By βΣ(i)∗ we denote the finite sequences over βΣ(i). Thus, the function v returns the finitesequences of calls to operations on interface i, for each interface i of the component. The ideais that behaviour of the component as a whole can be described by assigning such a sequenceto each interface of the component. Putting together such sequences, one for each interface,we form (a set of) vectors of sequences. Each coordinate corresponds to an interface of thecomponent and contains a finite sequence of calls to operations on that interface. Thus, itrepresents the permitted behaviour of the component on that interface. Intuitively, the ideabeing that it indicates possible constraints on the order in which several operations from thatinterface can or should be called.

Based on the above definitions, we obtain a mathematical concept of a component.

Definition 2.3 A component c is a pair (Σ,B), where Σ is the sort of c, and B ⊆ VΣ andB 6= ∅ is the set of behaviours of c.

Thus, a component consists of the static structure described by a sort Σ together with a languageof βΣ-vectors.

Example 2.1 Consider a small and simplified extract of a TV platform, related to the MENUfunctionality of a TV set. The MANUAL STORE options are provided by the interaction of thecomponents of Figure 1 which depicts the component specification architecture using the notationof [3, 14]. The stereotype <<comp spec>> is used to denote a component specification and theusual UML lollipop notation is used for the interfaces. The component architecture of Figure 1comprises a set of application level components together with their structural relationships andbehavioural dependencies [8, 3].

CTuner

IDetectSignal

<<comp spec>>

IOutputIChangeChannel

<<comp spec>>CMenu

IFineTune

ISearchFre

Figure 1: Component specification architecture

The CMenu component establishes communication with users via its provided interfaces ISearch-Fre and IFineTune. The ISearchFre interface has operations highlightItem and startSearch.Calls to these operations shall be denoted by a1, a2 respectively, for abbreviation. The IFine-Tune interface has operations highlightItem, incrementFre and decrementFre, abbreviated by



b1, b2 and b3 respectively. A user requests to search the available frequency for a program via theISearchFre interface. The CMenu component cannot satisfy the requested operation itself andrequires a component providing the IDetectSignal interface to conduct the frequency search onits behalf. This is done by invocation of an operation detectingSignal (abbreviated by c1) on itsrequired interface IDetectSignal, which is implemented by the CTuner component.

In what follows, we apply the formalism presented earlier to model the CMenu component.The provided interfaces of CMenu is given by the set PΣ = {ISearchFre, IF ineTune}, andthe required interfaces is given by the set RΣ = {IDetectSignal}. Consequently, the completeset of interfaces is given by IΣ = {ISearchFre, IF ineTune, IDetectSignal} and of course,PΣ ∩RΣ = ∅.

Function βΣ as defined in Definition 2.1 provides the set of calls to operations associated witheach interface. In this case we have

βΣ(ISearchFre) = {a, a}βΣ(IF ineTune) = {b, b, b}βΣ(IDetectSignal) = {c}

Suppose that a component developer considers the expected behaviour of CMenu fulfilling thefollowing:

• The Fine Tune option should be highlighted before the user can change the default fine tunevalue.

• The Search option should be highlighted before the user can request a frequency search.

• Once the user requests a search (which corresponds to invoking operation a2 on ISearchFre)the CMenu component calls the CTuner component (calling operation c1 on IDetectSignal).

• An occurrence of an operation call a2 on ISearchFre should be followed immediately by anoperation call c1 on IDetectSignal, and nothing should be allowed to happen in between.

Given this informal description of behaviour for the CMenu component, and if we write (x, y, z)for the function v of Definition 2.2 with v(ISearchFre) = x, v(IF ineTune) = y and v(IDetectSignal) = zwe obtain a set of behaviours that indicates a partial description of what would be desirable be-haviour of the CMenu component. In fact such description of behaviour from a componentdeveloper would be interpreted into the following set of behaviours.

B = {(Λ,Λ, Λ), (a, Λ, Λ), (Λ, b, Λ), (aa, Λ, Λ), (Λ, bb, Λ), (Λ, bb, Λ), (a, b, Λ),(a, bb, Λ), (aa, Λ, c), (aa, b, c), (a, bbb, Λ)}

In further explanation of the notation, there is an ordering between calls to operations on thesame interface (within one coordinate) but not between different interfaces of the component



(between two coordinates). The ordering amongst calls to operations on different interfaces isobtained from the behavioural presentation for the component, as will be demonstrated in Section3.

Indeed, c = (Σ,B) is a component (recall Definition 2.3) where Σ = (PΣ , RΣ , βΣ) is a compo-nent sort and B is a subset of all behaviour vectors VΣ.

The mathematics of βΣ-vectors is given in [17] and is very similar to that of [16]. The maindifference is that while vectors in [16] describe behaviour of systems of sequential processescombined using something like the || operator of CSP [6], βΣ-vectors describe behaviour ofsystems using something like the ||| operator of CSP.

In this paper, we present the fairly basic properties of βΣ-vectors. More details can be foundin [17]. If x and y are sequences we write x.y for the concatenation of x and y. As is wellknown, this operation is associative with identity Λ, where Λ denotes the empty sequence. Wealso have a partial order on sequences given by x ≤ y if and only if there exists z such thatx.z = y, and this partial order has a bottom element Λ. It is also well known that concatenationis cancellative, thus z is unique.

Based on the order theoretic properties of the set VΣ , two basic operations on the set of be-haviours of a component can be introduced.

Definition 2.4 Let u and v be behaviour vectors in B ⊆ VΣ. Then,

1. u u v is defined to be the vector w which satisfies w(i) = min(u(i), v(i))

2. if it exists u t v is defined to be the vector w which satisfies w(i) = max(u(i), v(i))

where, for an arbitrary i, w(i), u(i), v(i) denote the sequence of the i-th coordinate of vectorw, u, v respectively.

Additionally, and based on the fact that if x, y, z are sequences such that x, y ≤ z then eitherx ≤ y or y ≤ x, we may infer that if u, v ≤ w each i, then u(i), v(i) ≤ w(i) so u(i) ≤ v(i) orv(i) ≤ u(i), each i. We shall use this fact in the sequel without further comment.

In terms of partial orders the above operations essentially give the greatest lower bound andthe least upper bound of u, v ∈ B, in the usual sense of lattices and domain theory [4, 21]. Itis well known that if (X,≤) is a partially ordered set (poset) [4] then the least upper bound ofx1, x2 ∈ X, if it exists, is the least element x ∈ X such that x1, x2 ≤ x. We denote it by x1 tx2.The greatest lower bound, denoted by x1ux2, is the largest element x ∈ X such that x ≤ x1, x2.Notice that these are computed coordinate-wise for the behaviour vectors of our model.



A key property of the sets VΣ is that they possibly contain discrete subsets. Before definingdiscreteness, we also need to define consistent completeness. We shall say that B is consistentlycomplete if and only if i) ΛβΣ

∈ B and ii) whenever v1, v2, w ∈ B such that v1, v2 ≤ w, thenv1 t v2 ∈ B. In short, the notion of consistent completeness for a poset dictates that whenevertwo of its elements are less or equal than a third in the set, their least upper bound not onlyexists but is also in the poset.

Now, we can impose the first condition on a software component.

Definition 2.5 Let c = (Σ, B), where B ⊆ VΣ, be a component. We shall say that B is discrete,and consequently also that c is discrete, iff

1. B is consistently complete, and

2. If u1, u2 ∈ B, then u1 t u2 ∈ B ⇒ u1 u u2 ∈ B.

The justification for this constraint is as follows. A set of behaviours of a software componentmay be translated into an object called a behavioural presentation, introduced in [16], whichgeneralises the event structures of [13] in allowing time ordering of events to be a pre-orderrather than a partial order, thereby allowing the representation of simultaneity as well as con-currency. Behavioural presentations [16, 15] in relation to software components are discussed inthe following section.

As far as component-based design is concerned, we wish to constrain components in such away that they can be associated with a subclass of behavioural presentations, namely thosethat are discrete. This gurantees that i) there are no infinite ascending or descending chainsof occurrences of events, with respect to time ordering, which would give rise to Zeno typeparadoxes, ii) there are no ’gaps’ in the time continuum and iii) there is an initial point inwhich nothing has happened. We also wish to ensure that the behavioural presentation for eachcomponent contains one occurrrence for each call to operation on one of its interfaces. This canbe guaranteed by a property called local left closure, which we now define.

Definition 2.6 Suppose that c = (Σ, B) is a component. We shall say that c is locally leftclosed iff whenever u ∈ B and i ∈ IΣ and x ∈ βΣ(i) such that Λ < x < u(i), then there existsv ∈ B such that v ≤ u and v(i) = x.

If a component c is discrete and locally left closed, the we shall say it is well-behaved. Effec-tively, the local left closure property ensures that there will be a distinct prime in B for eachsimultaneity class of events, e.g. calls to operations. In order to provide a precise descriptionof a discrete behaviour we require that every occurrence of an event is ’recorded’ in the set ofbehaviours of the component. This implies the presence of a distinct prime vector in B for eachsimultaneity class of incidences, and for each appropriate interface. In this context, the notion of



prime refers to behaviour vectors which have a unique other vector immediately beneath them.The ordering among vectors in the set of behaviours B of the component is based on the relation/B which is defined in the following section (see Definition 3.2).

Example 2.2 We now examine discreteness and local left closure of the CMenu component ofExample 2.1, and illustrate why these properties are important. The idea is that, from an ini-tial set of component intended behaviours provided by the component designer(s), our proposedformal framework can determine whether this set is complete or on the contrary possible (andpotentially faulty) scenarios have been omitted. In our framework, we can determine this bychecking whether the set is well-behaved which corresponds to checking the properties of dis-creteness and local left closure. Again, the advantages in doing so are that we may identifymissing behaviours (either undesirable or simply unthought).

Based on the desirable behaviour for the CMenu component derived from the component de-signer’s description (see Example 2.1), we obtain the Hasse diagram of Figure 2 which depictsthe order structure of elements in the set B of Example 2.1.

( , b b , )Λ Λ1 3

( , b b , )Λ Λ1 2

(a a , , c )1 2 Λ 1

1 2 1 1(a a , b , c )

(Λ, Λ, Λ)

( , b , )Λ 1 Λ (a , , )1 Λ Λ

(a , b , )1 1 Λ (a a , , )1 2 Λ Λ

(a , b b , )1 1 2 Λ

(a , b b b , )1 1 2 3 Λ

Figure 2: Order structure of elements in B

It can be seen in Figure 2 that (Λ, bb, Λ), (a, bbb, Λ) and (aa, b, c) are the maximalbehaviour vectors of the component, in the sense that they do not describe earlier behaviour thanany other vector in B. Likewise, vector (Λ,Λ, Λ) is the minimal behaviour vector representingbehaviour of the component in which nothing has happened.

Based on Figure 2, we examine the discreteness property of the CMenu component. In orderto do so we concentrate on vectors v in B with at least two distinct incomparable immediatepredecessors. They, together with their predecessors should constitute (finite) lattices, accordingto Definition 2.5 of discreteness. In other words, whenever two behaviour vectors are less orequal than a third, also in B, their least upper bound must exist and belong to the set and their



greatest lower bound must also be in the set.

By careful examination it can be seen that the discreteness property is violated in Figure 2. Inparticular, vectors (a, b, Λ) and (aa, Λ, Λ) are less or equal than (aa, b, c). This impliesthat their greatest lower bound must be in the set, and it is (see vector (a, Λ, Λ)), but it alsoentails that their least upper bound should exist and belong to the set B. Their least upper boundis (a, b, Λ) t (aa, Λ, Λ) = (aa, b, Λ). Thus, according to our mathematical framework thisvector should be added in order to make the set B, and consequently the CMenu component,discrete. By adding in vector (aa, b, Λ) we get the following set of behaviours B. Its orderstructure is depicted in the diagram of Figure 3.

B = {(Λ,Λ, Λ), (a, Λ, Λ), (Λ, b, Λ), (aa, Λ, Λ), (Λ, bb, Λ), (Λ, bb, Λ), (a, b, Λ),(a, bb, Λ), (aa, b, Λ), (aa, Λ, c), (aa, b, c), (a, bbb, Λ)}

( , b b , )Λ Λ1 3

( , b b , )Λ Λ1 2

(Λ, Λ, Λ)

( , b , )Λ 1 Λ (a , , )1 Λ Λ

(a , b , )1 1 Λ (a a , , )1 2 Λ Λ

(a , b b , )1 1 2 Λ 1 2 Λ (a a , , c )1 2 Λ 1

(a , b b b , )1 1 2 3 Λ

1

1 2 1 1(a a , b , c )

(a a , b , )

Figure 3: Order structure of elements in B

This newly added vector describes behaviour of the component in which a call to operation a2

is followed by a call to operation b1. In terms of our example, the user requests a frequencysearch and before the CMenu component deals with this request (by making a call to operation c1

on IDetectSignal, according to the component designer) the user highlights the FineTune option(via a call to operation b1 on IFineTune). Such a sequence of events might leave the CMenucomponent in an inconsistent state or even cause a system failure. Hence, behaviour vector(aa, b, Λ) can be regarded as describing a potential instance of undesirable behaviour.

By comparing the two diagrams for the order structure of the set B in Figure 3 and Figure 2, itcan be seen that the model is, in a sense, warning the component designer. The diagram of Figure3 says that in the course of achieving the desirable behaviour, described by vector (aa, b, c), thecomponent might exhibit the potentially undesirable behaviour described by vector (aa, b, Λ).



In case this vector is indeed undesirable, some refinement of the component design is requiredin order to ensure that (aa, b, c) could be reached only through vector (aa, Λ, c) excludingany path that would involve vector (aa, b, Λ). If on the contrary vector (aa, b, Λ) representsreasonable behaviour and such a sequence of calls to operations should be allowed, then our modelis detecting it and serves as a designer’s aid to find the complete set of possible behaviours of acomponent.

Now based on Figure 3, we examine whether the discreteness property holds. That this is so, isbest illustrated diagrammatically. By inspection, we have the case depicted as a Hasse diagramin Figure 4, which exhibits the characteristic structure of a lattice.

(Λ, Λ, Λ)

( , b , )Λ 1 Λ (a , , )1 Λ Λ

( , b b , )Λ Λ1 2 (a , b , )1 1 Λ (a a , , )1 2 Λ Λ

(a , b b , )1 1 2 Λ 1 2 Λ (a a , , c )1 2 Λ 1

1 1

1(a a , b , )

1 2(a a , b , c )

Figure 4: Discreteness of CMenu component

It can be seen in the illustration of Figure 4 that we only include those vectors of B with atleast two distinct immediate predecessors. To see that (aa, b, c), (a, bb, Λ), (aa, b, Λ)and (a, b, Λ) are such vectors, focus on the rhombus-like shapes formed in Figure 3. The Hassediagram of Figure 4 then, demonstrates that together with their predecessors they constitutelattices. Indeed, the least upper bound and the greatest lower bound of the distinct immediatepredecessors exist and are in B, in all four cases. This implies that the CMenu component isdiscrete (in conformance with Definition 2.5).

For local left closure, we concentrate on those vectors in B with at least one component containinga coordinate with length greater than one and examine their predecessors. Figure 5 demonstratesthat for each vector in B with at least two events in one of its coordinates there is some othervector in B which has either the same sequence of events, at that specific coordinate, or the samereduced by one event. This implies that the CMenu component is locally left closed.

Having established both discreteness and local left closure for the CMenu component, we haveshown that it is well-behaved. Consequently, its set of behaviours can be associated with a be-havioural presentation (see the discussion in the following section for this association), modelling



(a a , , c )1 2 Λ 1

Λ11(a , b , )

1 1 2 3 Λ(a , b b b , )

(a , b b , )1 1 2 Λ

Λ 1 2 Λ( , b b , )

1 ΛΛ( , b , )

Λ 1 3 Λ( , b b , )

1 2 1 1(a a , b , c ) 1 2 1 1(a a , b , c )

(a a , , )ΛΛ1 2

(a , , )Λ Λ1

Λ11(a , b , )

21 1(a a , b , )

Λ 1 Λ( , b , )

Λ

.

Figure 5: Local left closure of CMenu component

the potential behaviour of the CMenu component.

3 Behavioural Presentations and Components

In this section we relate the component model to behavioural presentations which comprise thecentral behavioural model of our approach as they provide a denotational semantics expressiveenough to model non-determinism, concurrency and simultaneity as distinct phenomena. Abehavioural presentation, introduced in [15], is defined as follows.

Definition 3.1 A behavioural presentation is a quadruple (O, Π,E, λ), where

1. O is a set of occurrences

2. Π ⊆ ℘(O) is a non-empty set of points

3. E is a set of events

4. λ : O → E is the occurrence function

which satisfies⋃

π∈Π π = O.

The term point in the above definition refers to the set of occurrences of events during the periodof activation in question. The intuition is that each π ∈ Π represents that point in time reachedafter all occurrences which constitute it have taken place.

The behavioural presentation model is closely related to the event structures model of [13]. Infact, behavioural presentations generalise the event structures of [13] in allowing time ordering of



events to be a pre-order (a reflexive and transitive relation) rather than a partial order, therebyallowing the representation of simultaneity as well as concurrency. The relationship between thetwo is further examined in [16] where it is shown that event structures correspond to behaviouralpresentations which are closed, in the sense of being prime algebraic and coherent [4]. We omitfurther details.

A software component can be associated with a behavioural presentation by exploiting a basicorder theoretic property of behavioural presentations related to primes. In this context, thenotion of prime refers to vectors which have a unique other vector immediately below them(see also [17]). The ordering among elements of the set of behaviours is based on the followingdefinition.

Definition 3.2 Let u and v be behaviour vectors in B ⊆ VΣ. Then we define, u /B v iff

1. u < v

2. if w ∈ B such that u ≤ w < v, then w = u

Intuitively, the relation /B provides an ordering among the elements of VΣ, in which one is’immediately beneath’ the other, allowing no vector in B to exist in between them. For v ∈ Bwe define

preB(v) = {u ∈ B : u /B v}

This set contains all vectors that are related to v by /B. We are mostly interested in thosebehaviour vectors in B which have a unique other vector, also in B, immediately below them.Put formally,

prms(B) = {v ∈ B : |preB(v)| = 1}

where |X| denotes the cardinality of the set X. If v ∈ prms(B) then we define baseB(v) to bethe unique element of preB(v) and we further define ifsB(v) = {i ∈ IΣ : baseB(v) < v(i)}

The elements of prms(B) are precisely the complete primes of the poset (B,≤) in the usualsense of domain theory. The complete proof of this key property of prms(B), among with aseries of intermediate results is developed in [17]. [16] provides an extensive description of thesubject matter and also includes a proof of (B,≤) being prime algebraic, as this is defined in[21, 4].

As far as our model is concerned, each prime v ∈ prms(B) represents behaviour in which calls tooperations on the corresponding interfaces have occurred, during the course of behaviour since



that described by baseB(v). We accordingly associate primes in B with simultaneity classes ofevent occurrences, as we define next.

Definition 3.3 Suppose that c = (Σ,B) is a component and let

Oc = {(v, i) ∈ B × IΣ : v ∈ prms(B) ∧ i ∈ ifsB(v)}

We define a function λc : Oc → M × IΣ by

λc(v, i) = (m, i) ⇐⇒ ∃y ∈ βΣ(i)∗ and m ∈ βΣ(i) such that v(i) = y.m

The set Oc comprises all possible occurrences of events in the behaviour of the component. Asfor the occurrence function, if λc(o) = (m, i) then o is the occurrence of an event consisting ofa call to operation m at interface i, during behaviour described by v and since that alreadydescribed by baseB(v). Notice that since v(i) 6= Λ when (v, i) ∈ Oc, there exists y ∈ βΣ(i) suchthat v(i) = y.m. In effect, we isolate the last call out of the sequence of calls to operations atinterface i. We also need to define a set of points.

Definition 3.4 For u ∈ B, we define

πu = {(v, i) ∈ Oc : v ≤ u}

The set πu is the set of all occurrences of events during the component behaviour represented byu. The set of all sets πu, for u ∈ B constitutes the set of points Πc, hence

Πc = {πu : u ∈ B}

The structure (Oc,Πc, Ec, λc) is an instance of a behavioural presentation of [16], where Oc isthe set of occurrences of events in the behaviour of the component c = (Σ, B),Πc ⊆ ℘(Oc) is aset of points, Ec is the set of events of the component and λc is the occurrence function. Finally,⋃

π∈Πcπ = Oc (see [17] for the technical details).

In order to obtain a precise description of the dynamic characteristics of the component in hand,during a period of operation, we introduce concepts of mutual exclusion and time ordering intothe model. In fact, the set Π in a behavioural presentation determines various temporal relations.

Definition 3.5 Let B be a behavioural presentation and suppose that o1, o2 ∈ O. Define,



• o]o ⇐⇒ ∀π ∈ Π : o ∈ π ⇒ o 6∈ π and we say o1, o2 are mutually exclusive

• o → o ⇐⇒ ∀π ∈ Π : o ∈ π ⇒ o ∈ π and we say o1 has happened no later than o2.

• o1 ≡ o2 ⇐⇒ (o1 → o2) ∧ (o2 → o1) and we say o1, o2 occurred simultaneously

• o1 co o2 ⇐⇒ ¬(o1]o2) ∧ (o1 6→ o2) ∧ (o2 6→ o1) and we say o1, o2 occurred concurrently

• o1 < o2 ⇐⇒ (o1 → o2) ∧ (o2 6→ o1) and we say o1 happened strictly before o2

In further explanation of the notation, o1 → o2 implies that if o2 has occcured then so musto1. If o1]o2, then occurrence of o2 excludes future occurrence of o1 and vice versa. It is thisrelation that introduces non-determinism into the model. The relation ’]’ denotes a choice whilerelation ’→’ implies a time ordering among events, in a fashion similar to the conflict and causaltemporal relations among events in [9]. Mutual exclusion is an independence relation; that is,an irreflexive, symmetric relation and whenever o1 → o′1 and o2 → o′2 then o1]o2 ⇒ o′1]o′2. Asfor ’→’, it is a pre-order; that is, a reflexive and transitive relation. ’<’ is a strict partial orderand ’≡’ is an equivalence relation. Finally, ’co’ is an irreflexive and symmetric relation.

Using the above temporal relations we may capture all occurrences in any behavioural presen-tation, as two occurrences are either a) mutually exclusive b) ordered in time c) simultaneousd) concurrent or e) strictly ordered in time, and only one of these relations holds for a pair ofoccurrences.

Example 3.1 We extend Examples 2.1 and 2.2 with a sequence of demonstrations that will allowus to use a behavioural presentation to model the potential behaviour of the CMenu component.

First, for each element in B of Example 2.1 we determine its corresponding set preB(v).

preB(Λ,Λ, Λ) = ∅

preB(a, Λ, Λ) = {(Λ, Λ,Λ)}

preB(Λ, b, Λ) = {(Λ,Λ, Λ)}

preB(aa, Λ, Λ) = {(a, Λ, Λ)}

preB(Λ, bb, Λ) = preB(Λ, bb, Λ) = {(Λ, b, Λ)}

preB(a, b, Λ) = {(a, Λ, Λ), (Λ, b, Λ)}

preB(a, bb, Λ) = {(a, b, Λ), (Λ, bb, Λ)}

preB(aa, b, Λ) = {(aa, Λ, Λ), (a, b, Λ)}

preB(aa, Λ, c) = {(aa, Λ, Λ)}



preB(aa, b, c) = {(aa, Λ, c), (aa, b, Λ)}

preB(a, bbb, Λ) = {(a, bb, Λ)}

All v that have a unique vector in B immediately below them comprise the set prms(B),

prms(B) = {(a, Λ, Λ), (Λ, b, Λ), (aa, Λ, Λ), (Λ, bb, Λ), (Λ, bb, Λ), (aa, Λ, c),(a, bbb, Λ)}

Next, we associate the behaviour vectors in prms(B) with the interfaces to which the last call toan operation occurred.

o = ((a, Λ, Λ), ISearchFre)

o = ((Λ, b, Λ), IF ineTune)

o = ((aa, Λ, Λ), ISearchFre)

o = ((Λ, bb, Λ), IF ineTune)

o = ((Λ, bb, Λ), IF ineTune)

o = ((aa, Λ, c), IDetectSignal)

o = ((a, bbb, Λ), IF ineTune)

The occurrence function λc can also be used to determine exactly to which call to operation, andon which interface, each occurrence refers to.

λc(o) = (a, ISearchFre)

λc(o) = (b, IF ineTune)

λc(o) = (a, ISearchFre)



λc(o) = (c, IDetectSignal)


The occurence function is to be read in conjuction with the corresponding occurrence given earlier.For instance, λc(o) = (b, IF ineTune) implies that o7 is the occurrence of call to operation



b3 on interface IFineTune. This is also the case for λc(o) (with λc(o) = (b, IF ineTune)).However, λc(o) is associated with o = ((Λ, bb, Λ), IF ineTune) which means that o5 refers tooccurrence of b3 when b1 has happened earlier whereas λc(o) = (b, IF ineTune) is associatedwith o = ((a, bbb, Λ), IF ineTune) and refers to occurrence of b3 on IFineTune but only afterthe component has experienced calls to operations a1, b1 and b2.

Based on Definition 3.4, we may now obtain the sets of all occurrences of calls to operationsduring the course of behaviour in question.

π(Λ,Λ,Λ) = ∅

π(a,Λ,Λ) = {o}

π(Λ,b,Λ) = {o}

π(aa,Λ,Λ) = {o, o}

π(Λ,bb,Λ) = {o, o}

π(Λ,bb,Λ) = {o, o}

π(a,b,Λ) = {o, o}

π(aa,Λ,c) = {o, o, o}

π(a,bb,Λ) = {o, o, o}

π(a,bbb,Λ) = {o, o, o, o}

π(aa,b,c) = {o, o, o, o}

For instance, π(aa,Λ,c) = {o, o, o} contains occurrence of event a1 at interface ISearchFre(i.e. o1), occurrence of event a2 at interface ISearchFre (i.e. o3) and occurrence of event c1 atinterface IDetectSignal (i.e. o6). Occurrence of all three events comprises the behaviour of thecomponent represented by (aa, Λ, c).

Referring back to Definition 3.1, we have constructed the sets Oc and Πc for the CMenu compo-nent. Finally, from the set of all occurrences of events given above and based on Definition 3.5we extract the temporal relations among occurrences of events for the CMenu component shownin Table 1.

As an illustration of how these temporal relations are obtained we examine the relation betweeno3 and o6. Occurrence o6 refers to a call to operation c1 at interface IDetectSignal, but onlywhen calls to operations a1 and then a2 at ISearchFre have preceded it. Occurrence of a call tooperation a1 followed by a2 at the same interface is precisely occurrence o3. Thus, o3 strictly



Table 1: Ordering on occurrences of events of CMenu component

for o1: for o2: for o3: for o4: for o5: for o6:o1 co o2 o2]o3 o3]o4 o4]o5 o5]o6 o6]o7

o1 < o3 o2 < o4 o3]o5 o4]o6 o5]o7

o1]o4 o2 < o5 o3 < o6 o4 < o7

o1]o5 o2]o6 o3]o7

o1 < o6 o2 < o7

o1 < o7

precedes o6 since a1 and a2 must have occurred at interface ISearchFre (this is o3) before c1 canoccur at interface IDetectSignal (this is o6).

A behavioural model of the CMenu component can be seen in Figure 6 which depicts the tem-poral relations among occurrences of events, as these are experienced by the component on itsinterfaces.

o2

o4

o1

o3

o6 o7

o5

co

# #

Figure 6: Behavioural presentation model for the CMenu component

4 Composition of Components

The main challenge in a component setting is that of understanding the consequences of intercon-necting components. Due to space limitations, and since it is not essential for the understandingof this paper, we do not discuss composition in detail. The interested reader is referred to [12],which descibes composition of components within our mathematical framework and also ex-amines its effect on the individual components, i.e. preservation of discreteness and local leftclosure under composition.

In what follows, we give the main concept of composition, as this is considered in our model.Components are combined by connecting their complementary interfaces; that is, interfaces



provided by one component and required by another. This has as an implication that the twocomponents must have disjoint sets of both provides and requires interfaces. In mathematicalterms, their sorts must be consistent [12].

In a fashion similar to the formalisation of a single software component, we are again interestedin the static structure and the dynamic characteristics, this time for the composite component.Before we compose components themselves, we compose their sorts (static structure) and theirsets of behaviours (dynamic characterstics).

The sort of the composite is formed from those of the individual components by eliminatingall interfaces participating in internal communication. This is formally put in the followingdefinition.

Definition 4.1 Suppose that Σ and Σ are consistent sorts. Define Σ ⊕Σ = Σ where,

• PΣ = (PΣ ∪ PΣ)\(RΣ ∪RΣ)

• RΣ = (RΣ ∪RΣ)\(PΣ ∪ PΣ)

• βΣ(i) = βΣj (i) wherever i ∈ IΣj , j = ,

As for the behaviour of the resulting composite, it is an aggregate of behaviours from each of thecomponents at the non-connected - or better, the non-complementary - interfaces which remainessentially unaffected, and of its connected interfaces on which the sequences of events mustagree.

Definition 4.2 Let c1, c2 be components where cj = (Σj , Bj), each j. Suppose IΣ , IΣ are setsof interfaces and βΣj : IΣj → ℘(Op), each j. We shall say that vectors uj ∈ VβΣj

are consistent,and we write u1 ↓ u2 if

ubIΣ∩IΣ= ubIΣ∩IΣ

where fbX denotes the restriction of function f to the set X. Define,

u ⊕ u = (u ∪ u)bIΣ4IΣ

where IΣ4IΣ is the symmetric difference of IΣ and IΣ, defined to be (IΣ\IΣ) ∪ (IΣ\IΣ).

Having composed their sorts (see Definition 4.1) and their sets of behaviours (see Definition 4.2),we can now give the formal definition of composition of components.



Definition 4.3 Suppose that c1, c2 are components, where cj = (Σj , Bj), each j. Then, wedefine their composition c ⊕ c = (Σ, B) where,

• Σ = Σ ⊕Σ

• B = B ⊕B where B1 ⊕B2 = {v ∈ VΣ|∃u1 ∈ B1, ∃u2 ∈ B2 : u1 ↓ u2 ∧ v = u1 ⊕ u2}

Informally, the above definition says that the static structure of the composite is formed fromthose of the components while the dynamics reflect the fact that behaviours of the compositecomprise behaviour vectors from each of the components on non-connected interfaces so long asthey are consistent on the shared interfaces.

[18] lays the groundwork for results establishing the algebraic properties of the operation ⊕of composition, it is commutative and associative, and also contains the complete proofs. [12]deals with the all important issue of preservation of well-behavedness (essentially, discretenessand local left closure properties) under the operation of composition. This paper however, ismostly concerned with specifying individual components prior to composition, and in particularmodelling component behaviour using behavioural presentations, a powerful model of true-concurrency.

5 Conclusions and Future Work

In this paper we presented a mathematical model for formalising software components, at asemantic modelling level. Our approach is based on the use of tuples of sequences of events tomodel component behaviour. The model was restricted by imposing certain conditions whichallow us to associate components with behavioural presentations. As a result, the componentmodel corresponds to an order theoretic based model of behaviours with desirable properties.The presentation of the mathematical framework was restricted to a single component and wedid not describe composition due to space limitations. An overview can be found in [12]. Further,[18] contains an intensive study of the operation of composition within our framework.

The overall objective of the work presented in this paper is the application of mathematicalmethods in enhancing the design of component-based systems. Our approach relates to bothbuilding a component (how to specify a component taking into account structural and be-havioural aspects) and reuse (how can the component be reused and combined with others, howcan it be operated, what are the expected sequences of operations). In creating a component,a designer would be expected to specify the desired set of behaviours. Using our model, and inchecking against discreteness and local left closure, we identify possible missing behaviour andrefine the set of behaviours for the component (i.e. additional vectors might be included in theset to make the component well-behaved; such vectors might indicate pathological behaviour,leading to refinement of the initial design). The refined set of behaviours then describes what



the component does as well as the ordering of calls to operations, which needs to be respectedwhenever the component is deployed in different configurations.

Probably the closest to our model is the algebraic specification model of M. Broy [2, 1]. The useof tuples of sequences to model component behaviour is reminiscent of the use of streams in [2] torepresent messages communicated along the channels of a component. Essentially, the set out ofour model is quite similar to that of [2, 1], where a software component is modelled as an input /output function transferring input streams to the set of possible output streams. Semantically, acomponent in [2] is represented by a predicate defining a set of behaviours where each behaviouris represented by a stream processing function. In this respect, we diverge from M. Broy’sapproach since our model is based on the order theoretic structure of the set of behavioursof a component and is then related to behavioural presentations which provide a denotationalsemantics expressive enough to capture non-determinism, concurrency and simultaneity.

Another approach to formalising software components is that of [7, 8] which describes a dis-tributed logical framework for components and their composition. The initial set out is quitedifferent to our model since [7, 8] introduce a module distributed temporal logic Mdtl for spec-ifying components. To give a semantics to Mdtl [7] uses event structures which are similar tobehavioural presentations as mentioned before. In this way, [7, 8] can address non-determinismand concurrency but not simultaneity as is the case with behavioural presentations.

At the design level a software engineer could envisage using UML [14] to specify component-based systems. Even though UML was not developed for component-based design some of itsnotation can be useful (as shown for example in [3]). In particular, UML includes a constraintlanguage OCL which can be used for describing component constraints, mostly in terms of pre-and postconditions on interface operations. OCL is still essentially a static language and lacksthe appropriate expressiveness to capture provides/requires dependencies, which are essential fordescribing component contracts [19] precisely. This is tackled in [8] and [9] by using a Catalysis-like notation [5] for describing component interactions and component frameworks, respectively.Work in increasing the expressive power of OCL is in progress and possible correspondence tothe temporal relations derived from behavioural presentations needs to be further investigated.In any case, OCL 2.0 will have added expressive power and consequently provide more usefulnotation for describing some component contracts.

Finally, one natural extension of our work is to associate component behaviour with automata.This transition is straightforward because behavioural presentations give rise to a certain class ofautomata, building on consequences of discreteness and local left closure. An obvious advantageof automata is that it would make our formal approach to components amenable to automatedverification and consequently tool support. Such considerations are however subject for furtherwork.



References

[1] M. Broy. Advanced Component Interface Specification. In Proceedings of Theory andPractice of Parallel Programming (TPPP ’94), volume 307, pages 369–392. Lecture Notesin Computer Science, 1995.

[2] M. Broy. Algebraic Specification of Reactive Systems. Theoretical Computer Science,239(2000):3–40, 2000.

[3] J. Cheesman and J. Daniels. UML Components. Component Software Series, AddisonWesley, 2001.

[4] B. A. Davey and H. A. Priestley. Introduction to Lattices and Order. Cambridge Mathe-matical Textbooks, Cambridge University Press, 1990.

[5] D. F. D’Souza and A. C. Wills. Objects, Components and Frameworks with UML: TheCatalysis Approach. Object Technology Series. Addison Wesley, 1999.

[6] C. A. R. Hoare. Communicating Sequential Processes. Prentice Hall, 1985.

[7] J. Kuster Filipe. Fundamentals of a Module Logic for Distributed Object Systems. Journalof Functioning and Logic Programming, 2000(3), March 2000.

[8] J. Kuster Filipe. A Logic-Based Formalisation for Component Specification. Journal ofObject Technology, special issue: TOOLS USA 2002 Proceedings, 1(3):231–248, 2002.

[9] J. Kuster Filipe, K. K. Lau, M. Ornaghi, K. Taguchi, H. Yatsu, and A. C. Wills. FormalSpecification of Catalysis Frameworks. In Proceedings of the 7th Asia-Pacific SoftwareEngineering Conference, pages 180–187. IEEE Computer Society Press, 2000.

[10] K. K. Lau. Component Certification and System Prediction: Is there a Role for Formal-ity? In Proceedings of ICSE’01, 4th International Workshop on Component-Based SoftwareEngineering, Toronto, Canada, 2001.

[11] F. Luders and K. K. Lau. Specification of Software Components. In I. Crnkovic andM. Larsson, editors, Building Reliable Component-Based Software Systems, pages 23–38.Artech House, 2002.

[12] S. Moschoyiannis and M. W. Shields. Component-Based Design: Towards Guided Compo-sition. In Proceedings of Application of Concurrency to System Design (ACSD’03), pages122–131. IEEE Computer Society, 2003.

[13] M. Nielsen, G. Plotkin, and G. Winskel. Petri Nets, Event Structures and Domains, part1. Theoretical Computer Science, 13:85–108, 1981.

[14] OMG. Unified Modelling Language Specification, version 1.5. OMG document formal/01-03-01, available from http://www.omg.org, March 2003.

[15] M. W. Shields. Behavioural Presentations. In de Bakker, de Roever, and Rozenberg,editors, Linear Time, Branching Time and Partial Orders in Logics and Models for Con-currency, volume 354, pages 671–689. Springer Verlag, 1988.



[16] M. W. Shields. Semantics of Parallelism. Springer-Verlag London, 1997.

[17] M. W. Shields and D. Pitt. Component-Based Systems I: Theory of a Single Component.Technical Report SCOMP-TC-01-01, Department of Computing, University of Surrey, 2001.

[18] M. W. Shields and D. Pitt. Component-Based Systems II: Composition of Components.Technical Report SCOMP-TC-03-01, Department of Computing, University of Surrey, 2001.

[19] C. Szyperski. Component Software: Beyond Object-Oriented Programming. Addison Wes-ley, 1997.

[20] R. van Ommering, F. van der Linden, J. Kramer, and J. Magee. The Koala ComponentModel for Consumer Electronics. IEEE Transactions on Computers, 33(3):78–85, 2000.

[21] G. Winskel and M. Nielsen. Models for Concurrency. In S. Abramsky, D. Gabbay, andT. Maibaum, editors, Handbook of Logic in Computer Science, vol. 4, Semantic Modelling,pages 1–148. Oxford Science Publications, 1995.


Formalising Well-Behaved Components

Documents

Transcript of Formalising Well-Behaved Components