OGRAMMING IN PROTOCOLS

A Paradigm of Behavioral Programming

Ashley McNeile

Metamaxim Ltd., 48 Brunswick Gardens, London W8 4AN, U.K.

Ella Roubtsova

Open University of The Netherlands, Postbus 2960, 6401DL Heerlen, The Netherlands

Keywords:

Object-orientation Programming Modeling Composition CSP Protocols.

Abstract:

We present work in the creation of a programming paradigm based on the event protocols of objects. Our claim

is this results in a high level executable language that bridges the gap between behavioral models and code

for a large class of systems. The language is based on the idea of composing partial behavioral descriptions

using process algebraic techniques. We show that the concepts forming the basis of this language shed light on

questions relating to the description of behavior in object models, particularly in the areas of reuse, abstraction,

and behavioral conformance.

1 BACKGROUND

The earliest techniques for object modeling appeared

in the 1970s, before the mainstream appearance of ob-

ject oriented programming. Two leading approaches

were Jackson System Development (Jackson, 1983)

and Shlaer-Mellor (Shlaer and Mellor, 1992). Both

of these techniques had at their core the idea of ob-

ject life-cycle modeling, in other words describing, in

some form, the possible states of an object and how

events cause the object to move from one state to an-

other during its life.

When object orientated (OO) programming

started to become mainstream in the 1980s (with

Smalltalk), object modeling techniques and practice

tended to become aligned to the features and capa-

bilities of the emerging OO programming languages.

The emphasis in object modeling then moved to

classes, inheritance, attributes and relationships, fea-

tures closely aligned to the capabilities of OO lan-

guages, and away from life-cycle modeling, which is

not supported in any direct way by any OO language.

The Protocol Modeling paradigm described in

this paper has its origins in the JSD, but we have

both moved away from the particular notations used

in JSD towards a more abstract formulation, and

strengthened the semantic basis of the ideas, to the

point where direct execution can (and has) been sup-

ported. Along the way, the formalisms and ideas have

changed so much that any clue that JSD is its prove-

nance has all but disappeared, and the result is a high

level behavioral programming language.

2 PURPOSE AND

ORGANIZATION

This paper does not intend to provide a full descrip-

tion of the Protocol Modeling language, this has been

covered elsewhere (in particular in (McNeile and Si-

mons, 2006)). Rather, we want to discuss those as-

pects of the approach that are innovative, and repre-

sent a departure from conventional thinking or shed

light on existing ideas.

The paper is organized as follows:

Section 3 discusses the process algebraic basis of the

Protocol Modeling language.

Section 4 describes the semantics of the language.

Section 5 provides a small example based on a Bank.

Section 6 discusses some of the theoretical implica-

tions of the ideas.

Section 7 discusses the practical implications of the

ideas.

McNeile A. and Roubtsova E. (2008).

PROGRAMMING IN PROTOCOLS - A Paradigm of Behavioral Programming.

In Proceedings of the Third International Conference on Evaluation of Novel Approaches to Software Engineering, pages 23-30

DOI: 10.5220/0001759200230030

 SciTePress

3 PROCESS ALGEBRAIC

COMPOSITION

The Process Algebras (CCS, CSP, etc.) all deal with

abstract processes (or machines) that offer their envi-

ronment the ability to accept some events and refuse

or ignore others, based on their ”state”. This ability is

the basis for composing processes in various ways. In

the abstractions used in process algebras, the possible

states of a process are simply enumerated, as they are

entailed in the algebraic description of the process.

For instance, in the following example (using Hoare’s

CSP notation):

P = (w → P)|(x → R), R = y → ST OP, Q = z → P

there is an implicit deﬁnition of the state-space of Q

as {initial, P, R, stopped}. It also speciﬁes the pro-

tocol of the process: which of the events {w, x, y, z}

used in the deﬁnition of Q it is prepared to engage

in (accept) in each state. For instance, when in state

P it will accept w or x, but refuse to engage in y or

z. These formalisms are geared to formal algebraic

behavioral analysis, but not to modeling systems that

store signiﬁcantly complex data.

However, the ability to compose processes re-

quires only that they have a well speciﬁed protocol

behavior, meaning that they offer their environment

the ability to accept, refuse or ignore any presented

event. In particular, two machines that both have such

protocol behavior can be put in CSP parallel compo-

sition to form a composite machine as follows:

• If both constituent machines ignore the event, the

composite machine ignores it;

• If either constituent machine refuses the event, the

composite machine refuses it;

• Otherwise the composite machine accepts the

event.

Based on this, we deﬁne a Protocol Machine as a ma-

chine that has a speciﬁed protocol whereby it will ac-

cept, refuse or ignore any event that is presented to

it; and observe that the above deﬁnition means that

the composition of two Protocol Machines is another

Protocol Machine. We neither prescribe nor proscribe

any particular notation for a Protocol Machine: either

for its state-space or for the internal mechanisms it

uses to decide its protocol behavior. In addition, we

allow a Protocol Machine to have arbitrary local stor-

age, in same manner as a class in conventional object

oriented programming. A Protocol Machine may up-

date its own local storage, but only when moving to a

new state as a result of accepting an event presented

to it; and it may read but not update the local storage

of other machines composed with it.

4 PROTOCOL MODELING

A Protocol Model is a model built from Protocol Ma-

chines. Such models are event driven and determin-

istic, and the language we use to build them belongs

to the class of languages termed synchronous reactive

(see (Benveniste and Berry, 2002)). In this section, we

outline the main concepts of this language

. The de-

scription given here is not exhaustive, but sufﬁcient as

a basis for the subsequent discussion of the wider im-

plications of the ideas. In particular, we do not deﬁne

a syntax for the language, such as might be presented

to a compiler.

4.1 Events and Machines

The language deals with event driven systems, where

an event (properly an ”event instance”) is the data rep-

resentation of an occurrence in the real world domain

that is of interest to the system. An event represents

such an occurrence as a set of data attributes. Every

event is an instance of an event-type, and the type of

an event determines its attribute schema, this being

the set of data attributes that completely deﬁne an in-

stance of the event-type. For instance, the attribute

schema for a

Transfer

event (to move funds from one

account to another) in a banking system might be:

Event-type: "Transfer",

Date-of-transfer: Date,

Source: acct-id,

Target: acct-id,

Amount: Currency

The system moves from one state to another as a

result of accepting events presented to it. This ap-

proach to modeling events is identical to that used

in other event based modeling approaches (Jackson,

1983; Cook and Daniels, 1994).

4.2 Objects and Repertoires

Our aim is to model systems that comprise a popula-

tion of objects, which are separately instantiated and

which each have their own, unique, identity - in other

words, an Object Model. We achieve this by deﬁning

a Protocol Model as a collection of composed Proto-

col Machines (using the CSP composition described

above), each with an OID (object identiﬁer) which

ties the machine to the object whose partial deﬁni-

tion it represents. The OID of a machine is an im-

mutable property of the machine, given to it when

We use the epithet ”Modeling Language” as the behav-

ioral semantics resemble those normally associated with a

modeling language.

ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering

Protocol Model

Object o1

(three machines)

Object o2

(two machines)

Machine-Type: M1

OID: o1

Machine-Type: M2

OID: o1

Machine-Type: M3

OID: o1

Machine-Type: M1

OID: o2

Machine-Type:M4

OID: o2

Figure 1: Machines and Objects.

it is instantiated. The relationship between objects

and machines is depicted in Figure 1 which shows

two objects, one (with OID o1) comprising three ma-

chines and the other (with OID o2) comprising two.

It is crucial to understand that all of the machines in

Figure 1 are composed using the parallel composition

construct of CSP, both within and across objects.

As in CSP, every Protocol Machine divides the

universe of possible events into those that it under-

stands (can accept or refuse) and those that it does not

(and ignores). In CSP, this is done on the basis of the

alphabet of a process: the set of event symbols for

which the behavior of the process is deﬁned. Thus the

alphabet, α(Q), of the process Q in the earlier exam-

ple would be the set {w, x, y, z}. Protocol Machines

have a similar but slightly more complex construct,

called the repertoire of a machine, which we now de-

scribe.

We deﬁne the repertoire of a machine

m, denoted

by λ(m), as a set of triples each of the form [E, o, R],

with the following meaning:

An event instance e is in the repertoire of a ma-

chine m ⇔ [E, o, R] ∈ λ(m), where:

• E is the event-type of e,

• the schema for E has an attribute with name R

• The value of R in e is o, the OID of m.

Consider machines in a banking model that represent

Accounts and handle Transfer events. Suppose that

there is one of these machines (m

) with OID 12345

and one (m

) with OID 34567, and consider their roles

in an event to transfer £250.00 from account 12345 to

account 34567, as shown below:

Event-type = "Transfer",

Date-of-transfer = 20-Jul-2007,

We use ”machine” to mean a machine instance and use

a lower case symbol, m, to stand for a machine instance.

When we mean machine type we will say so explicitly and

use an upper case symbol, M. Similarly with events and

event types.

R here stands for Role, as the attribute name normally

signiﬁes the role the object is playing in handling an event.

Source = 12345,

Target = 34567,

Amount = 250.00

The machine m

will have the entry

[Transfer,

12345, Source]

in its repertoire and will understand,

and either accept or refuse but will not ignore, the

Source side of the Transfer transaction. The machine

will have

[Transfer, 34567, Target]

in its reper-

toire and will handle the Target side of the transac-

tion. Under the rules of CSP composition, only if both

machines accept the event will the model as a whole

accept it, and in this way the composition enforces

atomicity, as required by the rules of ACID transac-

tion handling

Account machines in model with OIDs other than

12345 or 34567 will ignore this Transfer. Incorporat-

ing the OID in the repertoire entry makes the object

structure of the model transparent to the composition

scheme.

4.3 Machines Types and Representation

Like events, machines have types and instances, so

that every machine instance has a type, and behaves

according to its type. As stated earlier there is no stan-

dard representation of the behavior of a machine type,

but the graphical notation described below has proved

both usable and useful in practice.

The notation uses states and transitions and there

are two variants of the notation, as shown in Figure 2.

In both variants, the diagram represents a successful

event acceptance scenario. In both cases the circles

represent states of the machine, and the arrow repre-

sents the effect of an event. The arrow (transition)

is marked with the repertoire entry to which the sce-

nario applies. As we are at the type level here, the

OID is omitted from the repertoire entry leading to the

form [E, R] shown (the OID is added to create the full

form [E, o, R] when a machine instance is created).

The solid (shaded) parts of the diagram represent the

way the machine updates its own local storage, and

Described,for instance, in (Gray, 1981).

PROGRAMMING IN PROTOCOLS - A Paradigm of Behavioral Programming

s1 s2

Update Spec.

f1 f2

[E,R] [E,R]

Update Spec.

Figure 2: Transitions.

the dotted parts represent the tests that must succeed

for the event to be accepted, as described below.

In the left hand form, the state of the machine is

represented by a distinguished variable (the state vari-

able) in the local storage of the machine. This vari-

able has an enumerated type of which s1 and s2 are

two possible values. This diagram has the following

semantics:

• The scenario is applicable if the value of the state

variable before the event is s1.

• The scenario results in a set of updates, speciﬁed

Update Spec

, being applied to the local storage

of the machine.

• In addition, the scenario results in the machine’s

state variable being set to s2 after the event, this

being the only mechanism whereby the state vari-

able can be changed.

In the right hand form, the circles (this time with a

double outline) represent values that are computed by

the machine, using a distinguished function called the

machine’s state function. This domain of this func-

tion is the local storage of the machine and all com-

posed machines and the function returns an enumer-

ated type, of which f 1 and f 2 are two possible values.

Again, the diagram represents a successful event ac-

ceptance scenario, but with the following semantics:

• The scenario applies if the value returned by the

state function before the event is f 1 and the value

returned by the state function after the event is f 2.

• The scenario results in a set of updates, speciﬁed

Update Spec

, being applied to the local storage

of the machine.

The behavior of a machine type is speciﬁed as a set of

success scenarios, with the following rules:

• The two variants are not mixed within a given ma-

chine type. A machine type is either stored state

in which case it has a single, distinguished, state

variable as part of its local state and only uses

left hand variant scenarios; or it is derived state

in which case it has a single, distinguished, state

function that returns its state value and only uses

right hand variant scenarios.

• The success scenarios of a given machine type are

mutually exclusive, so that it is not possible that

two (or more) scenarios can succeed for the same

event

Finally, the success scenario diagrams for a single ma-

chine type can be ”stitched together” to form a single

graphical state transition diagram that represents the

behavior of the machine.

5 EXAMPLE

Figure 3 is an example of a Protocol Model, show-

ing the behavior of the machine types of the model.

This model has two object types,

Customer

and

Account

whose behavior is deﬁned using one and four machine

types respectively.

Note the following about this model:

•

Account Machine 2

allows the repertoire entry

[Transfer, Source]

when in the state

Unfrozen

but not in the state

Frozen

. This means that it is

not possible to transfer funds out of a frozen Ac-

count. However

Account Machine 2

does not have

the entry

[Transfer, Target]

in its repertoire, so

whether an account is frozen or not has no af-

fect on its ability to act as the target of transferred

funds.

• Some transitions are labeled with two reper-

toire entries, for instance

[Withdraw, From]

and

[Transfer, Source]

Account Machine 1

. Using

a single transition arrow and speciﬁcation of up-

dates for both is possible because both are treated

identically by this machine. This is discussed fur-

ther in Section 6.4.

•

Account Machine 3

and

Account Machine 4

(both

of which use the right hand form in Figure 2) have

no ending and starting states respectively. This

means that there is no protocol test on the event(s)

in these machines after and before the event re-

spectively.

• Two of the event types in the model,

Open

and

Transfer

, require the engagement of two objects:

Customer

and an

Account

, and two

Accounts

re-

spectively. For these events, the CSP composi-

tion rules ensure that the model accepts the event

This is typically arranged by ensuring that, if two

success scenarios in the same machine type apply to the

same repertoire entry, they have mutually exclusive starting

states.

ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering

Customer Machine

[Register,Customer]

Registered

Left

[Leave,Customer]

[Open,Owner]

Store: Full Name;

Address;

[Open,Account]

Active

Closed

[Close,Account]

[Deposit,Into]

[Transfer,Target]

[Withdraw,From]

[Transfer,Source]

Balance := Balance

+ Event.amount;

Balance := Balance

- Event.amount;

Balance := 0;

Store: Owner;

Account Machine 1

[Open,Account]

Un-

frozen

[Withdraw,From]

[Transfer,Source]

Account Machine 2

Frozen

[Release,Account]

[Freeze,Account]

State Function:

if (Balance < -50) return “Over Limit”;

else return “Within Limit”;

Account Machine 4

Within

Limit

[Withdraw,From]

Credit

State Function:

if (Balance < 0) return “Overdrawn”;

else return “In Credit”;

Account Machine 3

[Release,Account]

[Close,Account]

Date of Register: Date

Customer

: OID (Customer)

Full Name: String

Address: String

Open:

Date of Open: Date

Owner

: OID (Customer)

Account

: OID (Account)

Leave:

Date of Leave: Date

Customer

: OID (Customer)

Reason: String

Transfer:

Date of Transfer: Date

Source

: OID (Account)

Target

: OID (Account)

Amount: Currency

Deposit:

Date of Deposit: Date

Into

: OID (Account)

Amount: Currency

Withdraw:

Date of Withdraw: Date

From

: OID (Account)

Amount: Currency

Close:

Date of Close: Date

Account

: OID (Account)

Freeze:

Date of Freeze: Date

Account

: OID (Account)

Reason: String

Release:

Date of Release: Date

Account

: OID (Account)

Events

Underlined attribute names are used as the Role

components of the repertoire entries above.

Local Storage:

Full Name: String

Address: String

Local Storage:

Owner: OID (Customer)

Balance: Currency

Account Machines 2, 3 and 4

have no Local Storage (apart

from their implicit OID and, in

the case of Account Machine 2,

its implicit stored state).

Figure 3: Bank Model.

iff both objects involved accept it, as required by

ACID event handing.

• Presentation of an event containing an OID that

does not exist in the model causes a new object to

be instantiated with the new OID. Such an event

will only be successful (accepted) if it is also the

creation event for the new object: as

the creation event for

Customer

, and

Open

is for

Account

6 THEORETICAL

OBSERVATIONS

In this section, we discuss some of the theoretical ob-

servations stemming from our work.

6.1 Derived States and Composition

Most modeling formalisms recognize the concept of

a derived attribute

. However, the use of a derived

quantity as the state of behavioral machine (as we do

in the right hand form of Figure 2) is, as far as we

In UML, a derived attribute is indicated by preﬁxing its

name with ”/”.

know, unique to our approach. Without this capabil-

ity, states determining protocol behavior that involve

derived quantities have to be expressed in other ways:

typically by the use of guards on transitions, or by

omitting such rules from the model and handling them

in code. It would not be possible, for instance, to de-

ﬁne

In Credit

and

Overdrawn

as states of an account

(as we have in

Account Machine 3

), or show the proto-

col rules that depend on these states in diagrammatic

form.

Describing complex behavior as a composition of

separate machines, some with stored and some with

derived states, helps to ensure that descriptions re-

main as simple as possible, and to avoid the prob-

lem of combinatorial state-space explosion that re-

sults from representing complex behavior in a single

diagram. In addition it is the basis for reuse, as de-

scribed in the next Section.

6.2 Inheritance, Reuse and Behavioral

Conformance

A cornerstone of Protocol Modeling is the idea that

the behavior of an object is the composition of par-

tial behavior descriptions. If we add to this the idea

that these partial behavior descriptions can be reused

PROGRAMMING IN PROTOCOLS - A Paradigm of Behavioral Programming

across different object types, we arrive very naturally

at a pure mixin approach to behavioral reuse (in the

sense described in (Bracha and Cook, 1990)). Thus,

in a banking context where it is desired to deﬁne a va-

riety of different types of account product, a catalogue

of machines such as those shown in Figure 3 can be

created and assembled in different combinations to

form different account product variants with different

behavioral rules. The machine

Account Machine 1

as it deﬁnes the core protocol of an account and the

maintenance of the account balance, is likely to be a

common mixin to all variants.

The use of CSP as the means of combining the

mixin components of an object guarantees that the

composite has Observational Conformance (a term

coined by Ebert and Engels in (Ebert and Engels,

1994b)) with the components contributing to it

. As

far as we know, Protocol Modeling is the only be-

havioral modeling approach that guarantees a degree

of behavioral conformance by virtue of its semantics,

in contrast to other published approaches which re-

quire that (sometimes complex) formation rules be

followed to achieve behavioral conformance

. More-

over, most published approaches which address this

matter focus on substitutability as the measure of con-

formance required. In our view substitutability is the

wrong measure of behavioral conformance in context

of model reuse, as it applies to subtyping rather than

the creation of behavioral variants

It seems that our compositional approach leads

very naturally to mixin based reuse. However, the

mainstream of object modeling, particularly as em-

bodied in UML, has followed OO programming tech-

nologies down the inheritance path. We think that

the natural way that mixins ”fall out” of the Protocol

Modeling approach casts doubt on whether hierarchi-

cal inheritance is the appropriate reuse paradigm for

modeling behavioral variants.

6.3 Local Reasoning

A concern in compositional approaches to software

development is that of Local Reasoning: the ability to

argue about the behavior of the whole based on ex-

amination of only a part. Without the ability to reason

locally, all parts of the design have to be viewed in

order to reach any conclusion about behavior, making

the retention of intellectual control hard in all but the

simplest of problems. This issue has been discussed

As discussed in (McNeile and Simons, 2003).

See, for instance, (Cook and Daniels, 1994), (Ebert and

Engels, 1994a), and (Schreﬂi and Stumptner, 2000).

The same point is made in (Cook et al., 1990).

particularly in the context of Aspect Orientation, for

instance by (Dantas and Walker, 2006).

We argue that the use of CSP composition enables

local reasoning at a behavior level, on the following

grounds (this argument is sketched only). Suppose

that:

• m is the composition of two machines m

of type

and m

of type

• traces(m) ¹

λ(m

)

is traces(m) restricted to the

repertoire of m

where traces(m) is the set of sequences of event in-

stances that m can accept. Then we have, as a prop-

erty of CSP composition, that:

traces(m) ¹

λ(m

)

⊆ traces(m

)

Using this we can determine from examination of

alone that an event sequence that purports to be a trace

of m is not actually so, because it fails to meet the

above condition. This ability to argue about m from

knowledge of

alone constitutes a form of behav-

ioral Local Reasoning.

6.4 Abstraction

Protocol Modeling enables abstraction in models, in

the sense that one machine can contain constructs that

represent a set of similar constructs in another ma-

chine, with the differences that distinguish the indi-

viduals of the set abstracted away. In a modeling ap-

proach, the ability to abstract is essential to achieving

economy and simplicity of expression.

The two forms of abstraction supported are by

event and state.

By Event: In the Banking Model shown in Fig-

ure 3, the repertoire entries

[Withdraw,

From]

and

[Transfer, Source]

appear in both

Account Machine 1

and

Account Machine 2

at-

tached to the same transition. This means that, in

both of these machines, the two repertoire entries

are treated identically: including the updates

performed to the local storage of the machines.

This is equivalent to saying that the difference

between these repertoire entries is immaterial for

these transitions, and we can use a single name

Debit

deﬁned as follows:

Debit = {[Withdraw,From], [Transfer,Source]}

instead. Note that the

Debit

abstraction could not

be used in

Account Machine 4

, as this machine

does not constrain Transfers.

By State: The ability to abstract by state stems from

use of derived states, as described earlier in Sec-

tion 4.3. For instance, the state

In Credit

ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering

Account Machine 3

can be viewed as an abstrac-

tion of all non-negative values of the local storage

attribute

Balance

Account Machine 1

The use of these abstraction mechanisms has no

affect on the semantics of machine composition, and

is therefore orthogonal to the ability to perform local

reasoning about behavior.

6.5 Behavioral Types

So far we have taken the protocol rules speciﬁed in

a Protocol Model to be non-discretionary statements

about when an event can take place. If an event is

refused, no update or change of state takes place. In

effect, the event is rejected as an error. Other classes

of behavioral rules are weaker than this, and should

not prevent an event but only provide guidance on

whether it should happen or not. An example is at-

tempting to access a website in Microsoft Internet Ex-

plorer v.7 (IE) when the security certiﬁcate held by

site is not recognized or is invalid. IE alerts the user,

with an alert and by coloring the header bar red, but

does not prevent access to the site.

In the model shown in Figure 3, it may be that the

Bank’s policy is not to prevent its Customers from go-

ing over their account overdraft limit but merely warn

them if a withdraw does so. A violation of the rule in

Account Machine 4

should not then cause a

Withdraw

event to be rejected, but instead should cause an alert

to the Customer that the event breaches the account

limit. To model this, we give a different Behavioral

Type to

Account Machine 4

to reﬂect this weaker pro-

tocol effect. A range of such weaker Behavioral Types

is possible, two being:

Allowed: Refused events are ﬂagged as not desired

or in violation of policy (but are not prevented).

Desired: Accepted events are ﬂagged as desired or

required (i.e., similar to a workﬂow rule).

Combining machines with different Behavioral Types

so as to prevent, encourage and discourage differ-

ent events under different circumstances is a way of

building behavioral intelligence into the model, so

that the system is active in policing the rules and poli-

cies required in the domain. Complete discussion of

this topic is beyond the scope of this paper, and more

information can be found in (McNeile and Simons,

2007).

Building behavioral intelligence into objects in

this way means that business processes become emer-

gent properties of the combined behavior of the par-

ticipating objects, rather than being deﬁned as process

ﬂow models using languages such as BPEL. This idea

(which has hinted at by others, for instance Fielding

with his idea of Hypermedia as the engine of applica-

tion state (Fielding, 2000)) involves less redundancy

of rule deﬁnition than the process ﬂow modeling ap-

proach, which normally requires that behavioral rules

about an object be repeated in each process that in-

volves the object. Making an object the owner of its

own behavioral rules ensures that any change is auto-

matically propagated to all business process contexts

in which that object participates. This makes pro-

cesses easier to modify and hence enhances business

agility.

7 PRACTICAL OBSERVATIONS

The aim of a language such as the one described

here must be to close the gap between the way soft-

ware is described in the analysis and design stages of

a project, and the way it is described in executable

form. The more this gap can be closed, the better the

software development process can be engineered to

avoid the familiar problems associated with human in-

terpretation and translation of one description into an-

other. Ideally, in our view, the software development

should involve executable artifacts from the begin-

ning, and the process should be based around incre-

mental review, testing and reﬁnement (and, perhaps,

automated transformation) of such artifacts. The early

focus of the process is on the behavioral requirements,

the later focus on the implementation environment

(target platform) and such issues as performance.

The language described here has proved valuable

in the early stages of development, where the focus is

on behavioral requirements. The richness of the be-

havioral semantics of the language makes it possible

to provide a generic user interface which interprets the

model to:

• Display, for a selected object, what events the ob-

ject understands.

• Color code events to indicate whether they are not

possible (”Greying out”), possible but discour-

aged, or possible and encouraged.

• Create ”pick-lists” of suitable target objects for an

event, being those objects that understand and can

accept it.

• Create suitable user-oriented error or warning

messages when a protocol rule has been violated.

An illustrative example of such a generic user inter-

face is shown in Figure 4. The important point is that

a generic user interface requires no more information

than is present in the model (for instance Figure 3)

and the associated instance data, so it is not neces-

sary to model or program it. This means that when

PROGRAMMING IN PROTOCOLS - A Paradigm of Behavioral Programming

Figure 4: Generic User Interface.

the model is changed the user interface changes ac-

cording, and this makes it is easy to support a rapid

cycle of develop, review and revise in the context of

an iterative approach to model construction and vali-

dation. Because the user interface does not show or

require any understanding of the internal structure of

the model (in terms of the way objects are modeled as

composed machines) stakeholders who are unfamiliar

and/or uncomfortable with formal behavior modeling

notations can successfully engage in, and contribute

to, the model validation process.

REFERENCES

Benveniste, A. and Berry, G. (2002). The synchronous ap-

proach to reactive and real-time systems. Kluwer Aca-

demic Publishers.

Bracha, G. and Cook, W. (1990). Mixin-based inheritance.

In ASM conference on Object-Oriented Programming,

Systems, Langiuages, Applications, pages 179–183.

Cook, S. and Daniels, J. (1994). Designing Object Systems:

Object-oriented Modelling with Syntropy. Prentice-

Hall.

Cook, W., Hill, W., and P.Canning (1990). Inheritance is not

subtyping. In 17th ACM SIGPLAN-SIGACT sympo-

sium on Principles of programming languages, pages

125–135. ACM.

Dantas, D. and Walker, D. (2006). Harmless advice. In 33rd

ACM SIGPLAN-SIGACT Symposium on Principles of

Programming Languages, pages 383–396. ACM.

Ebert, J. and Engels, G. (1994a). Dynamic models and be-

havioural views. LNCS 858.

Ebert, J. and Engels, G. (1994b). Observable or invoca-

ble behaviour - you have to choose. Technical report

94-38. Department of Computer Science, Leiden Uni-

versity.

Fielding, R. (2000). Architectural Styles and the Design

of Network-based Software Architectures. PhD thesis,

University of California, Irvine.

Gray, J. (1981). The transaction concept: Virtues and limi-

tations. In 7th International Conference on Very Large

Data Bases, pages 144–154.

Jackson, M. (1983). System Development. Prentice Hall.

McNeile, A. and Simons, N. (2003). State machines as mix-

ins. Journal of Object Technology, 2(6):85–101.

McNeile, A. and Simons, N. (2006). Protocol mod-

elling. a modelling approach that supports reusable

behavioural abstractions. Journal of Software and Sys-

tem Modeling, 5(1):91–107.

McNeile, A. and Simons, N. (2007). A typing scheme for

behavioural models. Journal of Object Technology,

6(10):81–94.

Schreﬂi, M. and Stumptner, M. (2000). On the design of

behavior consistent specialization of object life cycles

in obd and uml. In Advances in Object-Oriented Data

Modelling, pages 65–104. MIT Press.

Shlaer, S. and Mellor, S. (1992). Object Life Cycles -

Modeling the World in States. Yourdon Press/Prentice

Hall.

ENASE 2008 - International Conference on Evaluation of Novel Approaches to Software Engineering