A methodology for developing distributed programs

A methodology for developing distributed programs

Citation for published version (APA):

Ramesh, S., & Mehndiratta, S. L. (1987). A methodology for developing distributed programs. IEEE Transactions on Software Engineering, 13(8), 967-976. https://doi.org/10.1109/TSE.1987.233514

DOI:

10.1109/TSE.1987.233514 Document status and date: Published: 01/01/1987

Document Version:

Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can be important differences between the submitted version and the official published version of record. People interested in the research are advised to contact the author for the final version of the publication, or visit the DOI to the publisher's website.

• The final author version and the galley proof are versions of the publication after peer review.

• The final published version features the final layout of the paper including the volume, issue and page numbers.

Link to publication

General rights

Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

• You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, please follow below link for the End User Agreement:

www.tue.nl/taverne

Take down policy

If you believe that this document breaches copyright please contact us at: openaccess@tue.nl

providing details and we will investigate your claim.

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 8, AUGUST 1987

A

Methodology

for

Developing

Distributed

Programs

S. RAMESH AND S. L. MEHNDIRATTA

Abstract-Amethodology, different from the existing ones, for

con-structingdistributed programs ispresented. It is basedon the well-known idea of developing distributed programs via synchronous and

centralizedprograms. Thedistinguishing featuresof themethodology

are:1)specification includeprocessstructureinformationand distrib-utedprograms aredeveloped takingthisinformationintoaccount, 2) a new class ofprograms, calledPPSA's, is used in the development

process,and3) a transformational approach is suggested to solve the problemsinherent in the method ofdeveloping distributedprograms

through synchronous and centralizedprograms. The methodology is

illustratedwithan example.

Index Terms-Communicating processes, decentralization,

distrib-uted programming, programming methodology, program

transfor-mation.

I. INTRODUCTION

THEdifficultyofprogrammingfordistributed systems,

ldue to theircharacteristic property of process auton-omy,demandsasystematic methodologyfor constructing

distributed programs. In recent times, many approaches

havebeen suggested for such a systematic development

[1], [5], [12], [13], [17].

A divide and conquer method

has been proposed in[5]-thatconsistsof developing a

col-lection of layers from a specification of the distributed program tobedeveloped and composingtheselayers, into the required distributed program, preserving their

com-municatioh closeness. In [1]

[12],

[13], distributed pro-grams are derived by transforming

sequential

programs!

centralized action systems; this derivation is accom-plished eitherby firstpartitioning the

variables

of the

se-quential programs and thentransforming them [12], [13] or by first decentralizing the centralized action systems, through introduction ofcontrol variables and control

ac-tions, andthentransformingthem [1]. Thebasic idea

be-hindthese approaches is to

develop

distributed programs forsynchronous and

centralized

programs. This idea has

beenfound to beextremelyuseful as it renders the process of developing distributed programs a two-step activity.

The first stepinvolves

deriving

synchronous and

central-ized programs forappropriate specifications and

the

sec-ond step-entails translating these

derived

programs into therequired distributed programs.

Certain comments are in order on some of the existing methodologies.

In [5],thespecifications of

distributed

programs are

in-formal and no methodhas been suggested for

systemati-ManuscriptreceivedJanuary31, 1985;revisedJuly31, 1985. Theauthors are withthe DepartmentofComputer Scienceand Engi-neering,IndianInstitute ofTechnology,Bombay400076, India.

IEEELog Number 8715546.

cally constructing layers. Derivation of layers directly

fromspecification does not seem to be easy as layersare distributed programsinvolving disjointprocesscodes and communications and hence their construction requites

de-sign of separate process codes that when put

together,

satisfy theirspecifications.

Like

[3],

we believe that the distributed solutions of

problems are required not for getting efficient solutions but for programming distributed systems whose process structures andtopologies are decided by physical consid-erations such as distribution of data,

resources,

etc. The methodologies discussed in

[12],

[13] are not suitablefor

developing distributed programs with prespecified topol-ogiesbecause 1)they decide the process structure and the topology of a distributedprogram,being

developed,

based on performance considerations and 2) constructing se-quential programs and partitioning their variables to de-rivedistributed programs with prespecifiedtopologiesare notstraightforward.

Hence,

it would be desirable to have a methodology

that willsystematically developdistributedprograms from

their specifications that includeprocess structure and to-pology informations. It is the purpose of this paper to demonstrate that based on the same idea [1], [5], [12], [13] ofdeveloping distributed programs via synchronous and centralized programs, such amethodology canbe de-vised.

Accordingly,

this paper presents amethodology for

de-veloping distributed programs from their specifications.

Thespecification ofany programconsists of1)itsprocess structure specification that specifies the number of pro-cesses, their variables and their interconnections (i.e.,the

topology of theunderlying network) and2)apairof pre-and postconditions (on the variables of its processes) in the form of first order logical formulae. Given such a

specification,

themethoddevelopsahighlevel distributed program calledPPSA-ProgramwithProcessesinvolving

Shared

Actions,

which can be implemented in terms of processes thatcommunicate viamessages.

A PPSA is a program consisting of a fixed number of processes. Each process has a set of variables disjoint

from those of otherprocesses. These processes interact with each other via sharedactions. Shared actions are a

multiprocess generalization of CSP (communicating se-quential processes

[8])

communication primitives as they

allowarbitrarynumber ofprocessestocommunicatewith each other. Furthermore, sharedactions aresimilartojoint

actions [1] in that they involve local variables from dif-ferent processes. Shared actionsare,

however,

more

gen-0098-5589/87/0800-0967$01.00

© 1987 IEEE

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 8, AUGUST 1987

eral than thejointactions: joint actionsarealways guarded by enabling conditions that may involve variables from all the processes inthe system whereas shared actions can be simple shared actions or Boolean shared actions and they involvevariables fromonly those processes that share the actions. Also, PPSA's are process-oriented as they specify explicitly the control structure of processes and

they model noncyclic programs. On the otherhand,joint

action systems aremodeled after theManna-Pnuelimodel [10] and hence they are action-oriented, do not specify

explicitly the control structure of processes and model

deadlocking/nonterminating programs. Itmayperhaps be noted thatthe ideaofsharingcommonactions among pro-cesses isalso madeuse of in

[6].

The method of developing PPSA's is basedonthe same

divide-and-conquerprinciple asemployed in[5]. But it is more systematic as it makes use of 1) the WP-calculus [4], [7] approach and 2) atransformational approach for

developing efficient PPSA's. We shall see in Section II that PPSA's involve only sequential segments and hence

their construction and manipulation are easier and more systematic. Themethod ofimplementing PPSA's interms of communicating processes is similartothemethod given in

[12]

fortranslating sequential programs into CSP

pro-grams.

Since PPSA's are basedonamodel different from that ofjoint action systems, the proposed methodology ob-viously proceeds along different lines from those dis-cussed in [1]. Furthermore, ourmethodology also differs

significantly from the one discussed in [17].

The organization of this paper is as follows. SectionII elaborates further on PPSA's. Section III discusses the proposed methodology while Section IV illustrates the methodology. Section V contains some concluding

re-marks.

In whatfollows, we shall make use of GCL (Guarded Command Language [4]), WP-calculus [4], [7], and CSP [8].

II. PPSA' S-PROGRAMS WITH PROCESSES INVOLVING SHARED ACTIONS

A PPSA is ahigh level distributed program consisting

of afixed number of processes. Each process has its own set of variables (disjoint from those of other processes) and aprocess code. Each process code may involve four kinds ofactions: Simple sharedactions, Boolean shared actions, alternate actions, and iterative actions. Asimple

shared action involves a command in GCLwhile a Bool-eanshared actioninvolvesaBooleanexpression. Ashared

action(simpleorBoolean) mayoccurinthe process codes ofmore than one process and is said to be sharedby all

those processes inwhoseprocesscodes it occurs;trivially

thesetof processessharinganactioncould beasingleton.

Asharedactionmayinvolve thevariablesofaprocessthat shares it. Also wheneveravariable ofaprocess occursin a shared action, the action should be sharedby that pro-cess.

An alternate action (iterative action) is of the form if galI * * gakfi(dogal l * *

*1gak

od) where for

each i Ek = {1, * * ,k},

gal

isaguardedaction of the form g -p S; g is a

guard

and S is a sequence ofactions

involving simple shared/alternate/iterative actions. The

general form of g is b; b' where b is a Boolean shared

action shared by only one process and b' is a Boolean shared action shared by more than one process. The ac-tions b and b'are, respectively, called the local and non-local components of g. The guard g can haveonly alocal or nonlocal component and must have at least one such component.

Syntactically,aPPSA, say

PP,

consists ofadeclaration

followedbyalist of sharedactionsandalist ofprocesses.

The declaration defines a set of variables of PP. Each shared action in the shared action list has a name, a list of names of processes that shareit, andabody. The body

is a GCL command or a Boolean expression. Similarly

each process in the process list has a name, a list ofits variables, and process code. The setof variables listed in aprocessisdisjoint fromthe setofvariables listed in any other process in the list and union of all these sets is the set ofvariables declared at the head of PP. The process code ofa process is an action list consisting ofnames of

simple shared/alternate/iterative actions. The names of processes and shared actions should bedisjoint.

Thefollowing is an example of PP:

PP:: /*listofvariables ofPP*/ varx1 ,x ,x2

,x,x3,x,x4,x4:

integer /* list ofshared actions of

PPt*

initl:

shared by P1: end; init4: sharedbyP4: X4 = k end;

exchange1:

shared by P1,P2: XI .-=X2' if

xI

>

XIlj

=

Li

xl

x -x

skip

fi;X2 := end; Xj,X1 exchange3: shared byP3,P4: ifX3 >

X3'

- X3,X3: = X3,X3 LI

X3

x -X

skip

fi ;

x4

:=X3 end; unsorted: sharedby

P1,P2,P3,P4:

(X1

>

X2)

V

(X2

>

X3)

V

(X3

> X4) end; /* list of processes of PP */

[P1:

:varxl ,x'; /* variables of

PI

*/ 968

RAMESH AND MEHNDIRATTA: METHODOLOGY FOR DEVELOPING DISTRIBUTED PROGRAMS /* process code ofP1 */ do unsorted -+ exchange, od ||

P2:

:varx2,x2; /* variables of

P2

*1 init2; dounsorted 11 P3::varx3,x3; init3; do unsorted |I P4::varx4,x4; init4; do unsorted I /* process codeofP2*o -+

exchangel;

exchange2 od -+ exchange3;

exchange2od

-+

exchange3

od

It may be noted that init, in,it4, exchange1, exchange2, andexchange3 aresimplesharedactionswhile

"unsorted" is a Boolean shared actionof PP;

kl,

k4arefixed integers. The shared actionsinit2 and init3 are not shown above, as they can be obtained from init1 by

replacing the subscript 1 ofk, x and P, by 2 and 3,

re-spectively; similarly exchange2 can be obtained from exchange1.

Modelof Execution

The execution ofa PPSA involves the concurrent

exe-cution of its processes. Each process is executed by an

agent (processor). Theexecution ofa process consists of

executing the actions in its process code (in the order

specified). The execution ofan action succeeds orfails

(forthe ease ofpresentation, we ignore trivial modes of

failures like arithmetic overflow, division by zero, etc.).

The execution ofa shared action in aprocess fails ifone

ofthe processes sharing that action has terminated.

Oth-erwise, the execution of the action isdelayed until all

pro-cessessharingthataction reach thestageofexecutingthe

action in theirrespectiveprocesscodes. Theactionisthen

collectively executed by all these processes.

In the case of simple shared action, such a collective

executionmayresultinachangeof values ofthe variables

involved in the action. This change is the same as that

would beproduced whenthe bodyofthe shared action is executed in accordance with GCLsemantics. On the other hand, sucha collective execution ofaBoolean shared

ac-tion makes theprocessesknow thevalue of thebodywhich isnothingbut a,Boolean expression. It maybenotedthat

the effectofcollective execution ofasharedaction shared

by onlyoneprocess canbeproduced by simplyexecuting/

evaluating thebody of theshared action.

The collective execution ofasimple shared action

suc-ceeds iff the execution of its body, in accordance with GCL semantics, succeeds whereas that of a Boolean

sharedaction succeeds iff thebody evaluatesto true.

The execution ofan alternate action consists of

select-ing (the selection is nondeterministic) a guarded action,

witha successfully executable guard, and executing it; if

no guarded action has a successfully executable guard,

the execution ofthe alternate action fails. The execution

of a guarded action consists of executing its guard first and then the action list following the guard. A guard is executedby executing its constituent components from left to right. The guard succeeds iff the execution of its con-stituent component(s) succeed(s). The executionof an it-erative action similarly consists of repeatedly performing the following action until all of its guards fail: select

non-deterministicallyaguardedaction, with asuccessfully ex-ecutable guard, and execute it.

The execution of a process terminates successfully when all the actions executed during the execution have been successfully executed while that of a PPSA terminates successfully when all of its processes have been success-fully executed. The execution of a PPSA fails whenever the execution of at least one of its processes fails or a deadlock occurs. A deadlock occurs when there is a set of processes each of which is ready to execute a shared action but iswaitingforone ormoreprocesses(in the set) to reachthe stage of executing the shared action.

As an illustrationof this model of executing, consider the execution ofPP(thePPSA givenearlier). Concurrent execution ofP1, P2, P3, and P4 constitutes the execution

ofPP. Theexecution of each process

Pi,

i = 1, * * , 4,

involves first executing

initi

and thenrepeatedly executing the only guarded action in the iterative action, that

fol-lows

initi,

until "unsorted" fails. Each

initi

is shared by onlyoneprocess andhence does notrequireany

synchro-nization; it initializes

xi

to

ki.

The action "unsorted" is shared by all the processes and hence involves synchro-nizationofallthe four processes. Each exchange., i = 1, 2, 3, exchanges the value of

xi

and

xi

+ 1, if

xi

>

xi

+

1.

Consequently repeated execution of the guarded actions ofthe iterativeactions, eventuallymakes "unsorted" fail thereby sorting

xl,

, x4.

Remark 2.1: It is evident from the execution model of PPSA's that shared actions are (like CSP primitives [8]) the means of process interactions. However, they differ from CSP primitives in one important aspect: shared ac-tionsare amultiprocess generalizationoftwo-process CSP

primitives, as they can allow an arbitrary number of pro-cesses to synchronize and communicate witheach other.

Remark 2.2: The model of execution of PPSA's is ab-stractasitspecifies onlytheeffectof collective execution ofshared actions withoutexplaininghow thisexecution is carried out. The precise way in which a shared action is

collectively executed is a matter of implementation and forthe purpose of easy understanding, analysis, and

de-sign, suchanabstract model is sufficient and convenient.

Remark 2.3: The most important property of PPSA's is that they can specify arbitrary degree of

synchroniza-tion, i.e., they canallow any number of processes to syn-chronize and communicate with each other, through shared actions. This gives rise to tight synchronization

and poor

performance

whenever thenumber of processes

sharing an action is very large. Hence, whenever possi-ble, PPSA's involving shared actions shared by small

numberof processes should be developed. The

method-ology presentedinSection III has been proposedprecisely

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 8. AUGUST 1987 todevelop such programs. This methodology exploits the

above mentioned property of PPSA's to achieve the re-quired goal. As we shall see in Section III, highly syn-chronous and centralized programs can bedevelopedwith ease directly from their specifications while highly asyn-chronous and decentralized programs can be constructed from these programs by successfully transforming them, in asystematic fashion. Multiprocess synchronizationhas beenemployed precisely tohave such asystematic

meth-odology.

Based on the above model of execution, correctness measures similar to those given for CSP [8] can be de-fined.

Definition: APPSA PPis (totally) correct with respect to a pair ofpredicates <Q, R >, iff each execution that starts from an initial state satisfying Q successfully

ter-minates ina final state satisfying R.

Because of the presence of nondeterminism, PPSA's canexhibit time-dependent behaviors: the execution of a PPSA with one particular set ofrelative speeds of exe-cution of its processes terminates successfully, while ex-ecution with adifferent set of relative speedsmaynot ter-minate. Theabovedefinition of correctness, as itrequires

all executions of a correct PPSA to terminate success-fully, rules out time-dependent behaviors in correct PPSA's.

Forthe ease of presentation, we shall denote in the se-quel any PPSA by an ordered pair <[P2 I *

PnJ,

(i> where P1, ,

Pn

areits processes and (a is the set ofits shared actions. Furthermore, shared actions shared

by only oneprocess will appear explicitly as GCL

com-mands/Boolean expression in process codes. Shared ac-tions will be denoted by a, a' (with possible subscripts), GCL commands by c, c' (with possible subscripts), and

expressions by e, e' (with possible subscripts).

Implementation ofPPSA's

Letus recall that the execution model of PPSA's is ab-stract. In order to use PPSA's for describing distributed systems, itis necessary to furnish a concrete distributed

model of computation that can implement PPSA's. A brief discussion of suchanimplementation isgiveninthis sec-tion; fulldetails, however, can be found in [15].

Theimplementation of a PPSA, say PP, requiresa net-work of nodes, each of which' houses one or more pro-cessors. Each nodehasaunique index, which isanatural

number, identifying the

node-.

Furthermore, eacb node is connected via communication channels to a few other nodes called its neighbors. The processors of different nodes do not share any memory space butcan communi-cate by passing messages via the channels. The proces-sors at each node know the indexes of the node and its

neighboring nodes. The communication channels are bi-directional and theyneither corrupt, lose, nor changethe order in which messages are to becommunicated.

Furthermore, the implementation involves associating a process in PP with each node in the network. One of

'theprocessors inthe nodehasamemorylocation for every

variable of the associated process. This processor exe-cutes a piece of code corresponding to each constituent action inthe process code of the associated process. These codes involve only 'local computations and message pass-ing activities.

The piece of code corresponding to a simple shared

ac-tion, say a, whose body is x: = e, is as follows, where Pis the process (actually, processor) executing the code:

P:: if P

ownsxl

then receive values of nonlocal variables (if any) occurring in e, from the processes that own thesevariables;

evaluate e using thesevalues; assign the result ofevaluation to x

else send values of localvariables (ifany) occur-ring in e to the process that owns x

Whenthebodyofaisaniterative (alternate) command c, thepiece of code executedby Pis:

P:: repeat

if P is the process having the maximum index among all processes sharinga

thenbegin

receive from each other process that shares a, value(s)ofnonlocal variable(s)occurring

inthe guards of c;

evaluate the guards ofcusing thesevalues; ifthere'isatleastone successful guard

then begin

select one of the guarded commands with successful guards;

Informalltheother processes (sharing

a) the identity of the command se-lected;

execute the command following the

guard in the command selected.2 end

else/*noguardedcommand succeeds */ direct all the

processes

to terminate

(abort) the execution of c before itself

terminating

(aborting)

the executionofc. else /* P is notthe maximum index-process */

begin

sendto the maximum-index-process values of local variables (if any)

occurring

in the

guards of c;

receive message from the

maximum-index-process;

ifthe messagedirects to terminate (abort)

then terminate (abort) the execution ofc else select and execute the command

iden-tifiedin the message

until execution is terminated (execution is aborted oronce oneofthegurdedcommandshasbeen ex-ecuted)

'Moreprecisely, iftheprocessinPP, associatedwithP, owns x.

2Moreprecisely, executethe codecorrespondingtothecommand.

RAMESH AND MEHNDIRATTA: METHODOLOGY FOR DEVELOPING DISTRIBUTED PROGRAMS

The piece of code executed by P is empty when the

body ofa is skipwhile it is the code obtainedby

concat-enating the codes corresponding to

cl

and c2 when the body of a is

cl;

c2.

P executes the following code for an iterative (alter-nate) action, say, a

P:: repeat

evaluate the local components of a;

if local components of all the guards evaluate tofalse

then terminate (abort) the execution ofa elsebegin

attempt to selecta gurded actionwhose

lo-cal and nonlocal components evaluate to true;

if the attempt fails

then terminate (abort)the execution ofa else execute the action list following the

gurdedaction selected end

until execution is terminated

(execution

is aborted or once one ofthe guarded actions has been exe-cuted)

Certain noteworthy points about the above

implemen-tation are: 1) Thecodes, corresponding toasimpleshared actiona, executedby theprocesses

sharing

a, are similar

tothecodes of theprocesses of the CSP programobtained by translating the body of a, using the method proposed in [12]. 2) The messages sent (during the execution)

should haveproperidentities sothat theprocesses

receiv-ingthemcanidentify them. 3) The selection of aguarded action is a nontrivial step in the execution of the code

corresponding to an

iterative/alternate

action. This

re-quiresagreement among allthe other processes thatshare thenonlocal componentof the actionselectedinthesense that theseprocessesalsoshould select the actions with the same nonlocal component. This selection problem is

es-sentially the multiprocess generalization ofthe guard se-lectionproblemintheimplementationof CSP with output

guards [2]. Theguardselectionprotocol employedin[16]

for the implementation of CSP, can be generalized and usedfor the selectionofguarded actions. 4) Inthe imple-mentation, during the execution, any pair of processes

sharing

an actionmay require to communicate with each

other. Itis shown in [15] thatit is sufficient if the nodes

corresponding

toprocesses sharingany actionforma con-nected subnetwork in the whole network; a set of nodes in a network forms a connected subnetwork ifany node in this set isconnected to any other node in the set, either

directly

orindirectlythrough achain of nodesallofwhich are in the set.

Inconclusion, theentire implementationof PPSA's can be realized in a

distributed

environment that involves messagepassing as the only means of interaction among processors.

III. METHODOLOGY FOR DEVELOPING PPSA's

In this

section,

we shall see how to construct PPSA's from specifications. The specification of a PPSA is as-sumed to consist of two parts: 1) process structure spec-ification specifying the number of processes, their vari-ables, and the topology of theunderlying network and 2) pre- and postconditions in the form of first-order logical assertions that specify the initial and final states of the PPSA.

A transformational approach is adopted for the con-struction ofPPSA's. This involves the following steps:

1) Furnish a correct initial design of a PPSA from the given specification.

2) Successively improve thedesignby applyingcertain

transformation rules until a PPSA with desirable proper-ties is obtained.

AMethod for Deriving the Initial Design

This method is an extension ofthetop-down approach

fordeveloping sequential programs. Given a specification ofthe PPSA to be developed, it proceeds to develop the PPSAusing the three steps discussed below.

Let <Q, R > bethe pre- and postcondition of the PPSA PPtobe developed. Further, let PPbe specifiedtoconsist of n-processes,

PI,

* *,

P,

eachof which has a set of

variables and a set of neighbors, i.e., processes with which it cancommunicate(during its execution).

Step 1: Divide the givenpair <

Q,

R > into anumber

ofpre-postconditions, <

Q1l

Q2 >

*

, <

Qm

- I Qm>

such that Q

w Q,

and

Qm

=t

R forsomem > 1 and

Qi,

,Qm.

Remark3.1: Thepredicates

Q1,a

Qm

mayinvolve new variables, not specified in the specification, which

are appropriately associated with the processes without affecting the property ofdisjointness ofthe sets of

vari-ables of different processes.

Step2:

Foreachpair(Qj,

Q+1),je(m-1)

{1-= * m - 1 } find a collection of predicates

Qj,

k and

Qi,k

such that

Qj

= A

Qj,

k

kc-h

A Qj,k=

Qj+1

keh

for some h En; h isdependentupon j as it may be differ-ent for differentj's. Then construct a set of GCL com-mands

Cj,k,

k E h such that for k' e h and k' * k, the

following fiveconditions are satisfied:

1)

Qj,k

>

WP(Cj,k,

Qj,k)

2)

Qj

k A

Qj,=k',

WP(Cj,k,

Q1,k')-3)

Qj

kA

QJ,k'

X

WP(cj,k,

Qjk

).

4)

Ind

(cj,

k)

n Ind

(Cj,k')

= 0.

5) The process in {Pr r E Ind (cj

k)}

form a con-nected subnetwork in the underlying network

spec-ified.

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 8, AUGUST 1987

Ind

(Cj,

k) is the set ofindexes of processes whose vari-ables are referred in

cj,k

and WP is the weakest precon-dition function [4].

Remark 3.2: Each

Cj,

kmayalso involve new variables which are to bepartitioned and associated with those pro-cesseswhose variables arereferredin

Cj,

k* Itcan beeasily

seenthat condition 1)impliesthat executing

Cj,

k in a state

satisfying

Qj

kterminates in a state satisfying

Qj,

k, while conditions 2) and 3) imply that such an execution of

Cj,

k does not effect

Q;,k'

andQj k'(iftheyweretruebeforethe

execution) fork' * k.

Step3: Construct fromthese GCL commands, the fol-lowing PPSA,

pp =

([PI

11 ||

Pn],

(t)

where

(a =

{aj,k/k

Eh,j E (m -)}

aj,k:

shared by

Pi,

i E Id

(Cj,k):

Cj,k

end

Pi::

varxi,l, Xi,s;

pc(i)

xi,1 ..**,

xi,

sarevariables associated with

Pi

for some

s >

1,

sbeing dependent upon i, pc ( i ) is the process

code of

Pi,

defined recursively as follows: pc(i) =pc'(i, 1)

pc'(i,

j)

=

ifj

= m then nil (empty list)

else ifthere exists k Eh such that i E Ind

(Cj,k)

then3 aj,k;

PC'

(i,j + 1)

else pc'(i,j + 1)

Theorem: PPis correct with respect to <

Q,

R>.

Proof: SeeAppendix.

Remark 3.3:

Cj,k,

k E h,je (m

-1)

can be derived

using WP-calculus

[4],

[7] forappropriate pre-post con-dition pairs <

Q,

k,

Qj,k>.

The topology specification

influences both thedecomposition ofspecification and the choice of

Cj,k's.

This method of developing PPSA's is similar to constructing distributed

programs

using the

layer constructsuggested in [5].

Improving the Initial Design: Unless extra care is taken the initial design developed using the

above

method will behighly sequential, synchronous and centralized. As re-marked in Section

II,

these features are undesirable and we recommend an incremental approach to develop a

highly asynchronous and decentralized program from the initial design. According to this approach, the initial

de-sign is successively transformed, using well-defined transformation rules, to derive programs with increased

concurrency,

asynchrony, anddecentralization.

Thefollowing classes oftransformationrules, thatalter

PPSA's, have been found to be useful (in what follows PP X PP' denotes a rule that transforms the PPSA, PP into PP').

3Becauseofcondition4),there will beat mostoneksatisfyingiEInd

(CJik).

Decomposition: A decomposition rule has one of the

following forms:

1) ([P1

1

Pnl],

a u{a})

>([P'

11*

*|

Pn],

(i U{at, a2}

where4 a:

c1;

c2,

a,:

cl and a2: C2 for some GCL com-mandscl andc2 and

Pi'

is the process obtained from

Pi

by replacingthe occurrence of abyal: a2for each

Pi

sharing

a, while other P!'s are the same as the corresponding

Piss.

2)

([PI

1l

Pn],

C-(t

Ufa})

([Pl

| **|

Pn]

, (tU

Ial,***,

a2k}

where a: if el

-cll

ci

Liek

ckfior a: do el

cl

...* I ek - ck od for some Booleanexpessions el, * * * ,

ek

and GCL commands

cl,

*

k,

C,

a,:

el,

ak: ek, ak+ c1,C , a2k Ck and for each Pi sharing a,

Pi'

is obtained from

Pi

by

replacing

a

by

if

al

ak+ IF

*E Zak-+a2kfi(ordoal -*ak+ *- Liak-*a2k

od, respectively) while other

Pi"

s arethe same as the cor-responding

Pi's.

Rearrangement: Any rule in this class transforms a PPSAbyrearrangingtheoccurrences of a few of its shared actions in someofits processes.

Removal: A

typical

rule in this class is of the form

([P11||I

11 Pi

11

||

Pn]

C

I})

P

(P[P!

11

P || . ||

Pn]

]a)

whereP' is the process obtained from

Pi

by removing an occurrence of a shared action.

Replacement: A replacement rule has one of the

fol-lowing forms:

1)

[P

11

([*

**

IUaIu{a

where a and a'are-simpleshared action andPi' isobtained from

Pi

by replacingtheoccurrenceofa, if anyby a', for each i E n.

2)

(

[PI1

*

1

PnI]

(U{a,

a,,

,ak

([P' ||* *| Pn], (i

Ufa',

al,**' a'

I

where a is the nonlocal component occurring in those

guards, inprocesses P1, ,

Pn

whoselocalcomponents are

a1,

* * *,

ak

and

Pi',

i E n is the same as

Pi,

except forthe difference thata',

a8,

je k take theplaceofa,

aj,

respectively.

PPSA's need to satisfy some syntactic and semantic conditions in orderthat their correctness ispreserved un-der thesetransformations.

We shall now briefly illustrate how these transforma-tionrules can be usedto improve PPSA's.

Consider the PPSA, ,PPgivenby

4In thesequelsometimes,sharedactions will be denotedbya: c or a:e

whereaisthenameandc/e isthebodyofthe shared action.

RAMESH AND MEHNDIRATTA: METHODOLOGY FOR DEVELOPING DISTRIBUTED PROGRAMS

PP =

([P11

P2

11

P3

11

P41,

-{a,,

a2,

a3}

P1 :: a1,

P2::a1;a2,

P3::a2;a3, P4::a3

Thisprogram is highly sequential;

a,,

a2, and a3 are ex-ecuted in strict sequential order. If a2 and a3 are "com-mutative" then a PPSA, PP' that is more concurrent can beobtained where

pp' = ( [P ||P2|| P 11 P4], {al, a2,a3} > P a,, P : a,;a2,

P3

a3;a2,

P4

:: a3

by rearranging (reversing) the shared actions a2 and a3 in

P3

Similarly, a more asynchronous PPSA

PP = ( [P

II

P2I

II

P1l,

{a,,

a2, a3, a4,

a3,

a} >

P a; doa' -- a2 od

P2

done1, done2 = false,false; do a' -+ a2;

done,

= true

El a - a3; done2: = true od

P3::a4; do a' a3 od

at done1 a3: n done2 canbeobtained from

PP = <

[P1 11

P211P3],

{a,,

a2, a3,

a4}

>

P1

:: a,; a2 P2::a2;a3

P3

a4;a3

by

1)

making

the

following

replacements

a2 w done1

=false;

doa'-+a2;

donei

:= true od

a3 =

done2:

=false;

do

a'-+

a3;

done2

:= trueod

(done1,

done2are two newvariables associated withP2),

2)

decomposing

the twonew shared actions into

done1:=

false,

a', a2, done1 :=true and done2

= false, a, a3, done2 : = true, respectively, 3) removing the shared actions

done1:

=false,

done1

= true and done2:=false, done2:=true from

PI

and P3, respectively, and

4) rearranging the shared actions inP2.

Forthis transformation to be valid a2 and a3 should be

"'commutative.

"

It must be noted that in the sense of[5], PPpossesses insistent communication while PP' has indulgent com-munication.

Amostimportanttransformation isthedecentralization transformation that replaces a shared action by a new sharedaction which is shared by a fewernumber of pro-cessesthan the

former;

adesirable instance is the

replace-mentof a sharedactionshared by morethan one process,

byasharedaction shared by a singleprocess. This

trans-formation involvesapplyingthe rulesreplacementand re-moval in succession. The

possibility

of applying

decen-tralization depends upon the redundancy present in the system. Wheneverpossible this transformation should be

attempted in thedevelopmentof PPSA's asitreduces the communication complexity of the corresponding distrib-uted programs.

IV. ILLUSTRATION OF THE METHODOLOGY Weshall now illustrate our methodology bydeveloping adistributed programusing the methodology. The

speci-fication of the programtobe developedis as follows. Process Structure Specification: The topology of the underlying network is a rooted, complete binary tree T of n-processes, P1, * * ,

P,.

Each process

Pi

has avariable

xi

and can communicate with

Ps

I

(i), Ps2(i)

andPf

(i)

where

sl ( i ), s2 ( i ), andf(i ) are the indexes of the left, right

andfather processes of

Pi

(iE n); when i is the index of

a leaf process (root process) then sl (i) =s2 (i) = 0

(f(i)

=

0).

Precondition: n Q A

(xi

=

ki).

Postcondition: R

xi

= sum(l)

where sum (i ) isthesum ofthekeys recorded inthe nodes of the subtree rooted at i (sum(0) = 0).

First an initial design is constructed for this specifica-tion. Following the method given in Section III, a decom-position of

(

Q, R

)

is attempted. One possible

decom-position is

( Ql,

Q2 ,

(Qm-

1,

Qm),

where

Qj-

A A (FIN(i)A INV(i)) r=1 iElr A A A

(INIT(i)

A

INV(i)).

r=j+ l EIr m-depthof T.

Ir-set

of indexes of processes at level r

(levels

are

measuredfrom the leaves up the root.)

INV

(

i sum(i) (sum(s1(i)) + sum(s2(i )) +

ki.

INIT(i xi= sum(i).

m

A .. -true.

r=m+1

It is obvious that Q Q1, Qm = R. It may be noted that

Qj

corresponds to that state ofthe network in which all the processes at levels up to j have updated their

xi's

tothe requiredvalue while the other processes have not. Sequential Segmentsfor <

Qj,

Q1

+1>: As per step 2 ofthe methodology, for eachj = 1, * * , m - 1,

se-quential segments satisfying conditions 1)-5) ofSection IIIaredeveloped.

Consider the

following

twopredicates:

j-1

Qi,i-

A A

(FIN(t)

A

INV(t))

r =1 teir

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-13, NO. 8, AUGUST 1987 m

A A A (INIT

(t)

A INV(t))

r=j+2 tEir

A FIN(s1(i))A

FIN(s2(i))

A INIT(i) A INV(i)

Q,i-

A A

(FIN(t)

A

INV(t))

r=1 tEIr

m

A A A

(INIT(t)

A

INV(t))

r=j+2 tEir

A

FIN(i)

A

INV(i).

Foreach i e

Ij

+ 1 we have

Qj

=

A

Qj,i

ieJj+i

A

Qf,i

Qj Elj+I1 i

Also, for

ci

=

xi=

xsl(i)

+ Xs2(i) + Xi

QjAi

X

WP(ci,

Q

i)

Q

(Qj,i

A

Qj,i')

=

WP(Ci, Qj,i )

(Qj,

i

A

Qji" )

WP

(Ci,

Q3i"

)

Ind

(ci)

n Ind

(ci)

= 0

for every i, i' el +I and i * i', whereInd

(ci)

= {i,

sl(i),

s2(i)

}.

Furthermore, the processes whose indexes are in Ind

(ci)

form a connected subnetwork. Thus all the five

conditions ofSection III are satisfied forthe

ci's.

InitialDesign: Accordingly the initial design is given by

PP

=

([P111

IPn4,

a)

where

a

=

{ai

i

Ij+h=

1,

***,

m

-

1}

ai:

sharedby

PiPsl(i),

Ps2(i):

Ci

end

Pi

:: var

xi: integer

I * initial value is

ki

*/

ai

;

af(i)

foriEIj and <j <m,

Pi

:: var

xi:

integer / * initialvalue is

ki

*/

ai

;

af(i)

for i e

I,

and

Pi::

varxi:

integer

I * initial value is k1 *1

ai-for i e Im.

PPishighly synchronous astheexecutionof

ai

requires simultaneousparticipationof

Pi,

Ps1

(i)

and

Ps2(i).

Weshall

improvePPby applying certaintransformation rules.

Transformation 1: Foreach i e

1j+1,

1 c j < m,

re-place

ai

by

a;

given by

al:

set(i);

do

cond(i,sl(i))

-4

upd(i,sl(i))

[l

cond

(i,

s2(i

-)

upd

(i,

s2(i))

od where

set(i) =

donei

1,

donei,2:

= false, false

donesl(i),3,dones2(i),3,

: = false, false cond(i,k) -i

donei1,

A -,

donek,3

upd(i, k) = Xi + Xk;

donei1,

true

;donek,

3 true

fork = sr(i )and r = 1, 2;

donei,r

for r = 1, 2 are new variables of typeBoolean that are associated with

Pi,

i E

lj + 1 and 1 c

j

< m while

donei

3 is a Boolean variable associated with

Pi

for i e

Ij

and 1 c j < m.

Transformation 2: Decompose a; into set

(

i),

cond

( i,

sl(i

)),

cond(i, s2(i)),upd(i,sl (i))andupd(i, s2(i))

foriEIj+1,

1 sj < m.

Transformations 1 and 2, as

such,

do not

improve

the program. But they enable

subsequent

application

of the rulesthatimprovethe program.

Transformation 3: Remove

cond(i,

sl(i)),

upd(i,

sl(i) ), and cond( i,s2(i) ),

upd (

i,

s2

(

i

) ), respectively,

from processes Ps2(i)andPsl(i)for i e

Ij,

1 <j c m. The amount ofsynchronizationis reduced

by

this trans-formation, as it reduces the number of processes

sharing

some actions.

Final Transformation: Replace cond(i,

k)

in

Pi

by

donei

1; synch(i, k) and inPkby -'

donek,

3; synch(i, k)

where synch (i,k): trueis a Boolean shared actionshared by

Pi

and

Pk

for iEIj,k= sr(i), r = 1,2. The processes of the resulting PPSA are givenby

Pi

:: varxi:

integer;

set(i); do -

donei

1; synch (i,sl(i))

upd(i,sl(i))

-'

donei,2;

synch(i,s2(i))

upd(i,s2(i))-od;

set(f(i));

do

donej,3;

synch

(f(i),

1)

upd(f(i),i)od

for i elj and 1 <j<m.

Pi

:: var

xi:

integer;

set(f(i));do

donei,3;

synch(f(i), i)

upd(f(i),i)

od foriEI1,

Pi

:: varxi:

integer;

set

(i );

do

donei,

1;

synch

(i,

sl1(i ))

upd

(i,

s

1(i

)

-l

donei,2;

synch (i,s2(i))

upd

(i,

s2(i))

do;

for i e m.

No more transformation is required as no further im-provement is possible. As indicated in- Section III, this

can be

directly

implemented in terms of communicating

processes. For the sake ofthose familiar with CSP, we

give aCSPversion ofthis program.

RAMESH AND MEHNDIRATTA: METHODOLOGY FOR DEVELOPING DISTRIBUTED PROGRAMS

Pi

::

donei,

1,

donei,2

:

false,

false

do

donei,

l;Psl(i)?xi'

xi

xi+xi'

donei,

1 = true

donei,2;Ps2(i)?x' xi: =xi+xi;

donei,2:

=true

od ;

donei,3

: = false;

do donei,3 Pf(i) !xi donei,3 true od

for ie Ij and 1 < j < m.

Pi

foriEl and iIm are

similar.

Remark 4.1: Aprogram similarto the final PPSA has beendeveloped in [5] using their methodology. The sim-ilarities anddissimilarities of the development of this pro-gram and that ofthe final PPSA maybe noted.

Remark4.2: Thecorrectness ofthe final PPSA derived follows from that of the initial design and the validity of each of the transformations. The initial design is correct

by consruction because of Theorem 1. Intuitively, it is obvious that each of the transformations leads to correct

program. Thisfactcan, however, be formally verified but

this requires formal treatment of correctness, transfor-mations, and their validity. These arediscussed in [15].

Remark 4.3: The derivation of the finalprogram seems

to bemore complex and lengthier compared to the

com-plexity of the final program arrived at. One may say that

thefinalprogram canbearrivedatintuitively ina

straight-forward fashion. But the difference between such an

in-tuitively developed programand theonederived above is

that the former requires anaposteriori correctness proof

that establishes itscorrectness whereasthelatter doesnot;

asnotedabove thelatterisautomaticallycorrectby virtue ofbeing the end product of a sequence of well-defined

and correct steps. Accordingly, the complexity of the above derivation is to be compared to that of the a pos-terioriproofofcorrectness. Thecomplexity of thea

pos-teriori proof ofcorrectness is well-known and has forced

us toadopt the principle ofhand-in-handdevelopment of

programs and their proofs [7] in the case of sequential

programs. The proof of correctness of distributed

pro-grams is muchmore complex than thatofsequential

pro-gram. Hence suchaprinciple is muchmore validand

ad-vantageous inthe caseofdistributed programs.

V. CONCLUSION

A methodology, based on the well-known idea of

de-veloping distributed programs via synchronous and

cen-tralized programs, has been reported. Its distinguishing

features areasfollows. 1) Specifications includetopology

information and distributed programs are developed

tak-ing this information into account. 2) A newclass of

pro-grams (PPSA's) is used inthe development process. 3) A

transformational approach is suggested to solve the prob-lemsinherentinthemethodofdevelopingdistributed

pro-grams through synchronous and centralized programs.

Obvious advantages ofthis transformation approach are

1) highly concurrent, decentralized, and asynchronous

programs can bedeveloped with relative ease and 2) the

correctness of the programs so developed follows from

the correctness of the initial PPSA's designed and from the correctapplicationof the transformation rules. PPSA's have been found to be suitable for developing distributed programs with prespecified topologies. In contrast, se-quential programs are not useful as they do not exhibit process structures. PPSA's are also superior to layered programs as their construction and manipulation is easier andmore systematic. They aredifferent fromjoint action systems asthe formerarebased on .a model different from that of the latter. Thus the methodology proposed,

al-though itmakesuseof some of the known ideas from[1], [5], [12],

[13],

is different and more powerful than these

approaches.

The proposed methodology has been applied to many standard problems, like the one discussed in this paper, and found to be quite useful. Currently work is in prog-ress to demonstrate more effectively the practical utility

of the methodology proposed. As the first step towards this, a more formal treatment of PPSA's and the meth-odology has been attempted [14], [15]. With the transfor-mation rules discussed in this paper, the number of steps required for the development of "big" programs may be large. Considering the complexity of intuitive develop-ment followed by a posteriori proof of correctness, the large number ofsystematic and correct steps may not mat-ter.However, use ofhigher leveltransformationrules that arecombinations of the rules described in this paper, will considerably reduce the number of steps and the amount ofreasoning. Hence attempts are being made to discover such high level transformation rules.

APPENDIX PROOF OF THEOREM 1

Consider an execution of PP with the following addi-tional synchronization: execution of any shared action

aj,

k,

kEh isallowed if andonly ifall the othershared actions

aj,k',

k' E h are about to be executed forj E (m - 1). Thenwe

have,

1) executing PP, with an initial state satisfying Qand with the abovementioned additional synchronization, re-sults in a final state satisfying R.

2) any ordinaryexecution of PP with aninitial state is equivalent to the execution PP with the sameinitial state and withthe additional synchronization.

1) follows from

Q

=*Qi

Qj

>wp

W(cj,l

Il

*

lCj,h,

Qj+1)

for

j

E (m - 1), where

cj,1

| *

Cj,

h is a concurrent segment whose execution consists of

executing

the con-stituent GCL-commands inanyarbitrary orderandQm w-R.

These three conditions are implied by the conditions

1)-4) of SectionIII. Any additional synchronization

dis-ciplinecan, atmost, introducedeadlocking. Hence2) fol-lows from 1). 1) and 2) togetherprove the theorem.

IEEE TRANSACTIONS ONSOFTWARE ENGINEERING, VOL. SE-13, NO. 8, AUGUST 1987

ACKNOWLEDGMENT

We thankthe referees for theirconstructive comments

on earlier versions of this paper. We also wish to thank N. B. Joshiand N. S. Chaudhari for theirhelpinthe

prep-aration of this paper.

REFERENCES

[1] R.J. R. Back and R. Kurki-Suonio,"Decentralizationofprocess nets with centralizedcontrol," in Proc. 2ndConf. Principles of

Distrib-utedComputing, Montreal, P.Q., Canada,Aug. 1983.

12] G. N. Buckley and Silberschatz, "An effectiveimplementation for thegeneralized input-output construct ofCSP," ACM Trans.

Pro-gram. Lang. Syst., vol. 5, no. 2, 1983.

[3] K. M. Chandy, "Paradigms for distributedcomputing,"in Rec. 3rd

Conf. FoundationsofSoftware Technology and TheoreticalComputer

Science, Bangalore, India, Dec. 1983.

[4] E. W. Dijkstra, A Discipline ofProgramming. Englewood Cliffs,

NJ:Prentice-Hall, 1976.

[5] T. Elrad and N. Francez, "Decomposition ofdistributed programs into communication closedlayers," Sci. Comput. Program.,vol.2,

1982.

[6] N. Francez and B.Hailpem, "SCRIPTS-Acommunication

abstrac-tionmechanism," in Proc. 2nd Conf. Principles ofDistributed Com-puting,Montreal, P.Q., Canada, Aug..1983.

[7] D. Gries, The Science of Computer Programming. New York: Springer-Verlag, 1981.

[8] C.A.R. Hoare, "Communicating sequentialprocesses," Commun.

ACM, vol.21, no. 8, 1978.

[9] G. Levin and D. Gries, "Prooftechniques for communicating se-quential processes," Acta Inform., vol. 15, 1981.

[10] Z. Manna and A.Pneuli, "How to cook atemporal proof systemfor

yourpet language," in Proc. IOth Annu. Conf. Principles of Pro-gramming Languages, Austin, TX, Jan.,1983.

[11] R. Mccurley and F. B. Schneider, "Derivation of a distributed al-gorithmof finding paths in directed networks," Comell Univ., Ith-aca,NY, Tech. Rep. 83-86, Dec. 1983.

[12] A. Moitra, "Synthesis of communicatingprocesses," in Proc. 2nd

Conf.PrinciplesofDistributedComputing,Montreal, P.Q., Canada, Aug. 1983.

[13] V. R. Prasad, "Derivation of distributed programs from sequential programs," TIFR, Bombay, India, Tech. Rep. TR87, Aug. 1983.

[14] S. Ramesh and S. L. Mehndiratta, "A newclassofhighlevel pro-grams for distributed computing systems," in Proc.Fifth Conf. Foun-dations of Software Technologyand TheoreticalComputerScience (Lecture Notes inComputer Science, Vol. 206). New York:

Sprin-ger-Verlag, 1985.

[15] S. Ramesh, "Programming with shared actions:Amethodology for developing distributed programs," Ph.D. dissertation, Indian Inst.

Technol., Bombay, India, to be submitted.

[16] J. S. Schwartz, "Distributedsynchronization of communicating

se-quential processes," Artificial Intell., Univ. Edinburgh, Scotland,

Tech. Rep., July 1978.

[17] L.Shrira, N. Francez, and M. Rodeh, "Distributed K-selection: From asequentialtoadistributedalgorithm,"' inProc. 2ndConf

Princi-ples ofDistributedComputing, Montreal, P.Q.,Canada. Aug. 1983.

S. RameshwasborninKumbakonam, India,on November 29, 1958. He received the B.Sc. de-greein applied sciences from Thiagarajar College

of Engineering in 1978 and theBeE. degree in electronics and communication engineering from theIndianInstitute ofScience, Bangalore, 1981.

Shortly, he will besubmittinghis Ph.D. dis-sertationintheDepartmnentofComputerScience

and Engineering at Indian Institute of Technol-E ; 17!S ogy,Bombay.Heiscurrently workingon

distrib-utedprogramming.His other research interestsare specification, verification, and formal semantics ofconcurrentand

distrib-utedprograms and logic programming.

S. L.Mehndirattahas worked at Tata Institute of Fundamental Research, Bombay, India,

Dal-housie University, Canada, and theIndian Insti-tute ofTechnology, Madras. Currently he is a

Professor ofComputerScience withthe

Depart-ment ofComputer Science andEngineering,

In-dian Institute of Technology, Bombay. He has published papers in the areas of computerscience,

operationsresearch, and environmental

engineer-ing. His currentareas of interest aredistributed computing, methodologies for developing soft-ware, fault-tolerant protocols fordistributed systems, message systems,

and optimizationof industrial systems. 976