UNLIMITEb 'J/ p

IDTIC FILF COPY] Report No. 90019LR-

ROYAL SIGNALS AND RADAR ESTABLISHMENT

z~ t MALVERN010

wt TRANSLATING DATA FLOW DIAGRAMSo INTO Z (AND VICE VERSA)

Author: G P Randel

OTICEECTE

$MLR 2 6 1991

PROCUREMENT EXECUTIVE, MINISTRY OF DEFENCE

RSREMulvem, Worcestershire.

October 1990

UNLIMITED

COND.nONS QF RELEASE0089235 BRA1 15966

MR PAUL A ROBEYDflCAttn:DTIC-FDACCameron Staion-Bldg 5AlexandriaVA 22304 6145USA

DRIC U

COPYRIGHT (c)1988CONTROLLERHMSO LONDON

DRIC Y

Reports quoted are not necessarily available to members of the public or to commercialorganisations.

ROYAL SIGNALS AND RADAR ESTABLISHMENT

Report 90019

Title: Translating Data Flow Diagrams into Z

(and vice versa)

Author: G P Randell

Date: October 1990

ABSTRACT

This report describes the results of work into the integration of structured and formalmethods, in particular, data flow diagrams and Z. Data flow diagrams are given a formal,mathematical basis by defining rules to translate these diagrams into Z. Rules are alsogiven for generating a data flow diagram from a Z specification, and for checking thecompatibility of a data flow diagram and a Z specification.

Accesslon For

DTIC TABUhannounced QJust ification

Distribution/

A vailability CodesIAvail and/or

Copyright0

Controller HMSO London1990

• mmmn mmem m m om mmm nm mmnmnmamm mmu nm mmn lm Lr)')m mm

THIS PAGE IS LEFT BLANK INTNTIONALLY

1. Introduction

An earlier investigation into the integration of structured and formal methods for theproduction of requirements specifications [1] led to the conclusion that further work isneeded in all areas of the requirements definition activity. One recommendation inparticular suggested that the translation of data flow diagrams into the formal language Z[2] should be researched and rules derived. This report describes the results of thatresearch. Data flow diagrams were chosen for further study as they are in common use asa means of describing an existing or required system, but little work has been carried outin finding a mathematical basis for them. They feature in several systems analysis anddesign methods, including SSADM (Structured Systems Analysis and Design Method)[3], Yourdon [4] and CORE (Controlled Requirements Expression) [5], albeit in differentforms.

The advantage in providing a mathematical basis for data flow diagrams is that they willbecome unambiguous with a defined meaning, at the same time as retaining their ease ofunderstanding. Diagrams are often easier to understand than a mathematical specificationas the latter may appear daunting at first sight. This report, by providing a mathematicalbasis, imposes one view of data flow diagrams, and this will be explained as theformalism is developed.

The original recommendation to translate data flow diagrams into Z has been extendedand there are now three parts to the work. The first part is to produce rules for thetranslation of a data flow diagram into an outline Z specification, which gives a precisemeaning to the diagram, and could be used in a formal development, if required. Thesecond part is to give a formal relationship between data flow diagrams and Zspecifications, which says what it means for a diagram and a Z specification to representthe same system. The final part is to give rules for generating a data flow diagram from aZ specification which may be used to illustrate and validate the specification.

This report has used the SSADM conventions for data flow diagrams, although the workis more widely applicable with some minor modifications. For example, additionalconstraints could be put on a diagram to incorporate desired features or a house-style.

The report is structured as follows. Section 2 formally specifies data flow diagrams in Z.This is needed before any rules can be defined. The required parts of Z are specified inSection 3, again in Z itself. The rules for translating a data flow diagram into a Zspecification are given in Section 4. Section 5 describes how to check that a Zspecification and a data flow diagram represent the same system. Section 6 presents therules for generating a data flow diagram from a Z specification, and the final sectioncontains some concluding remarks.

This report has been produced using the RSRE Z tool Zadok [7]. Zadok is a Z editor andalso a syntax- and type-checker. Sections 2 to 6 of this report are separate Z documents.The conclusion of each document is marked by a "keeps" statement which lists theidentifiers exported by the document. A document is imported into another one byincluding the document name, which is distinguished by having a box drawn round it.

2. The Specification of Data Flow Diagrams

In SSADM, data flow diagrams have three types of diagram element. These are externalentities, processes, and datastores. External entities are those entities outside the systemboundary from which data is input to the system, or to where data from the system isoutput. Processes take a set of inputs which are transformed by the process into a set ofoutputs. The processes carry out the functions of the system. Processes are sometimesreferred to as transformers. Datastores, as their name implies, store the data held in thesystem.

External entities are represented graphically in SSADM by circles, processes by squares,

1

and datastores by two horizontal parallel lines joined on the left hand side by a verticalline. Data flows show data moving around the system. They are represented by arrows,labelled with the name of the data. The head of the arrow indicates the destination of thedata. Each data flow joins two diagram elements together, with the constraints that a dataflow cannot begin and end at the same entity, and every data flow must have a process aseither its source or its destination or both.

The interpretation put on a data flow diagram in this report is that it represents operationsbeing carried out on a state. The state is represented by the datastores, and the operationsby the processes. The external entities just provide or receive data. In formalizing thisinterpretation in Z, specifications are needed of the relevant details of data flow diagramsand of Z. A meaning function may then be defined from data flow diagrams to 7. Thisfunction represents the interpretation.

To specify data flow diagrams, it is necessary to abstract away from the detail of thediagrams. External entities, processes and datastores will be specified first, and then thedata flows between them may be specified as constraints on the set of diagram elementsmaking up a given diagram.

Figure 1 shows an example of a data flow diagram, using the conventions of SSADM.This diagram shows part of a banking system, where a manager takes the name of a newcustomer and adds it to a database containing the names of the current customers. Thisexample will be used throughout this section to illustrate the specification of data flowdiagrams.

identifier -- seq Char

external entity

r names F identifier

The relevant part of an external entity, from the point of view of this interpretation, is thedata which it gives rise to or uses. The data moving around the system is shown bywriting the name of the data, its identifier, on the data flow.

The example data flow diagram has one external entity, namely the customer.

I Customer : external-entityCustomer.names - ("Customername")

The data associated with the entity is just the customer's name.

Each process takes in inputs, and produces outputs, in accordance with some rules. Theserules are represented by the name of the process. There are two sorts of input: those fromoutside of the system, that is, from external entities, and those from within the system,that is, data passed between processes directly. These are distinguished, by inputs andint inputs respectively. Similarly, there are two sorts of output which are alsodistinguished.

[ processinputs, outputs : seq identifierint inputs, in-outputs : seq identifierprocessname : seq Char

The inputs and outputs are treated as sequences rather than sets as this makes thetranslation rules more straightforward. The ordering can be thought of as "across the pagefrom left to right". The sequence does not imply a particular order for processing anymore than the diagram does. Flows of data between processes and datastores are not

2

interpreted as inputs or outputs (of any form) as they actually represent a change of thestate data.

The example data flow diagram has one process, "Register-newCustomer", which hasone input from an external entity, "Customername", and no internal inputs or anyoutputs. The arrow on the diagram from the process to the datastore indicates that theoperation to register a new customer causes a change to the datastore, and is dierefore notan outpuL

p : process

p.inputs - ( "Customer name" )p. output -0

p.int inputs -0p.int outputs - 0p.processname - "RegisternewCustomer"

The processes in a SSADM data flow diagram have two extra pieces of informationassociated with them, a numeric identifier and a location. The numeric identifier isunnecessary, as it is assumed that no two processes have the same name. The locationdoes add something to the specification, if it is interpreted as describing a role. That is,states the authority needed to carry out the process. However, this information is notappropriate to incorporate into the Z specification produced by this translation.

datastore

s tore name : seq Char

Datastores are named. The contents of stores do not appear on a data flow diagram, so no

contents are specified.

The example data flow diagram has one datastore called "Customers".

d : datastore

d.store name - "Customers"

The identifier "DI" is not recorded as it is assumed that datastores with the same nameare the same, so the identifier adds nothing.

DFDelement ::- ext 4 externalentity)DI proc £ process )I store 9 datastore N

The three schemas external entity, process, and datastore represent the threepossible type of data flow diagram element. In addition to diagram elements, a data flowdiagram contains data flows:

data flowrorigiln, destination :DFD elementlabel : seq Char

origin 0 destinationorigin e rng proc v destination e rng proc

Each data flow has a source and destination, both of which are diagram elements. Each isalso labelled with the name of the data flowing along it. A data flow cannot return to itsown origin, and must have a process as either its origin or destination (or both).

3

The example data flow diagram has two data flows, from the external customer to the

process, and from the process to the datastore..

dfl : dataflow df2 : data_flow

dfl.origin - ext (Customer) df2.origin - proc(p)dfl.destination - proc(p) df2.destination - store(d)dfl.label - "Customer name" df2.label - ""

The first data flow, from the external customer to the process, is labelled with the nameof the data concerned, that is, the customer's name. The second flow, however, representsa change of the state data held in the datastore, and is not labelled.

A well-formed data flow diagram consists of diagram elements connected by suitabledata flows.

DFDelements F DFD elementflows : F dataflow

V e : elements * ( 3 f : flows , e - f.origin v e - f.destination )V f : flows * ( f.origin e elements A f.destination E elements )V e : elements; ex : external entity I e - ext ex eex.names - ( f flows I e - T.origin v e - f.destination - f.label )V e : elements; p process I e -proc prng (p.inputs) { f : flows

I f.destination - A A f.origin e rng extf.label )

rng (p.outputs) - f : flowsI f.origin - e A f.destination E rng extf.label )

rng (p.intinputs) - : £ flowsI f.destination - e A f.origin e rng procf.label I

rng (p.int outputs) - f : flows/ f. origin - e A f.destination e rng procf.label )

The first predicate says that, for each element in the diagram, there must be a flow eitherto or from it, or both. The second says that all flows must come from and go to a diagramelement. These are basic constraints to say that the diagram must be partly connected.Additional constraints could be added to say that the diagram must contain no sourcesand sinks of data, or that the diagram must be completely connected (that is, is notcapable of being split into two or more sets of elements, with no data flows between anytwo elements in different sets).

The third and fourth predicates describe two checks that must be made on each data flowdiagram, to ensure that the representation in terms of elements and data flows isconsistent. The first check is that, for each external entity, the names associated with itcorrespond to the labels on the data flows going to or coming from that entity. Thesecond check is concerned with processes. For each process, the inputs associated withthe process must correspond to the labels on the data flows from an external entity to theprocess, and the outputs associated with the process must correspond to the labels on thedata flows from the process to an external entity. Similarly, for each process, the internalinputs associated with the process must correspond to the labels on the data flows fromanother process to the process, and the internal outputs associated with the process mustcorrespond to the labels on the data flows from the process to another process.

The bank diagram is composed of one external entity, one process and one datastore,together with two data flows.

4

Bank : DFD

Bank.elements - (ext (Customer), proc(p), store(d))

Bank.flows - (dfl, df2)

This diagram is consistent, as the only input to the "Registernew.Customer" process is a"Customer-name", which is the same as the label on the data flow from the externalCustomer to the process. Also, the external Customer has only one type of dataassociated with it which is the same as the label on the only data flow from it. There areno data flows to the Customer.

Data_flow diagram keeps identifier, externalentity, process, datastore,ext, proc, store, DFD element, dataflow, DFD,Customer, p, d, dfl, df2, Bank

5

a

Customer

Customer name

* l IManager

RegisternewCustomer

Dl Customers

Figure 1 An Example Data Flow Diagram

6

3. The Specification of Z

Datajflow.diagram :Module

The purpose of this section is to specify those parts of Z that will be needed to representany data flow diagram. For the interpretation used, only two constructs are needed,namely given sets and schemas.

A given set introduces a Z type. This type is constructed from the name of the set.

set -- seq Char

The name of the set is just a sequence of characters.

Schemas are more complicated and have three parts: a name, a signature and a predicate.

schemaname -- seq Char

The name of the schema is just a sequence of characters.

The signature of a schema is a more complicated structure. There are two sorts ofelement in a signature, inclusions and declarations. Inclusions are names of otherschemas to be included, and declarations are identifier-type pairs. Identifiers have alreadybeen defined as sequences of characters. Types are more difficult.

The definitions of types and signatures are mutually recursive, so a set of types is

introduced first as a given set, and then later constrained.

[ type I

signatureelement ::- inc 9 schemaname N I dec 4 ( identifier X type ) ))

signature -- F signatureelement

A signature is a set of inclusions and declarations.

type ::- given A seq Char ))I tuple 4 seq type ))I powerset 9 type ))I schematype 9 signature D

There are four sorts of types in Z: those constructed from given sets, tuples (which arisefrom cross-products), powersets (for example, signature above has a powerset type),and schema types. For example, the following schema:

exampler aA/ b :seq k

has the following type:

schematype (dec ( a, given (AN) ),dec ( b, tuple ( given ( I ), given ( Al ) ) )

The predicate part of a schema is straightforward.

[ predicate I

I empty : predicate

7

Nothing is said about predicates, other than that they exist, as they cannot be deducedfrom a data flow diagram. For the translation from data flow diagrams to Z, the emptypredicate is supplied.

scheman : schema-namesig signaturepred predicate

A schema has a name, a signature and a predicate.

z_element ::- given-set 4 set S I box £ schema X

Each element of the part of Z used is either a given set or a schema box.

zjspecification -- F z element

A Z specification will consist of a set of these elements.

Zspecification keeps set, schemaname, signature, signatureelement,inc, dec, type, given, tuple, powerset,schematype, predicate, empty, schema, zelement,given set, box, zspecification

8

4. Rules for Translating a Data Flow Diagram into a Z Specification

Data.flowdiagram :Module

Zspecification :Module

This section defines a function, translate, which translates a data flow diagram into a Zspecification. Each element of the diagram is translated into one or more Z elements:external entities are translated into given sets, processes into schemas defining operationson states, and datastores into schemas defining part of the state. A given diagram elementand its translation are gathered together in the following schema along with the diagrambeing translated:

[ trans parsd e : DFD elementz e : F z elementdiagram :--DFD

d e Q diagram. elements

Taking external entities first, a given set is produced for each type of data associated withthat entity. These sets represent the types of the inputs and outputs to the system, andtheir names are given by appending "type" to the names of the data.

trans.exttrana~pars

d e e rng extz-e - given set I ( n : (ext 1I de).names * n "type" ) 3

Using the bank example, the external entity "Customer" produces one given set,"Customer-name-type". This set represents the only type of input to the system, and

there are no outputs.

A schema is generated for each process and Jescribes the effect the operation representedby the process has on the state of the system, that is, which datastores are affected.Additional given sets are generated for internal inputs and outputs.

9

trans proctranspars

do - proc ( 8process )z_* - ( box ( Oschema ) u

given set I ( i rng int inputs u rng int outputs • i - "type" ) 3where

schema; process

n - processnamesig- ( data flow; datastore

I Odatiflow E diagram.flowsstore( Odatastore ) e diagram.elementsdestination - de A origin - store ( Odatastore )-' 3 data flow' / Odata flow' E diagram.flows

origin' - d e A destination' - origin )* inc ( "3" store name ) )U

( data flow; datastoreI Odata flow E diagram.flowsstore ( Odatastore ) E diagram. elementsorigin - d e A destination - store ( Odatastore )

* inc ( "A" storename ) }U

{ i : dom inputs* dec ( inputs i "?", given ( inputs i "type" ) ) )

U

( i : dom outputs* dec ( outputs i - ",", given ( outputs i - "type" ) ) }U

( i : dom int inputs* dec ( int-i-puts i, given ( int_inputs i " "type" ) ) }

U{ i : dom int outputs* dec ( int-outputs i, given ( intoutputs i - "_type" ) ) }

pred - empty

The name of the generated schema is the same as the process name, and its signatureconsists of those datastores which are read by the process but not altered in any way,those datastores which the process does affect, and the inputs and outputs, both externaland internal. Those datastores read but not changed are prefixed by "s", while those thatare changed are prefixed by "A". The datastores that are read but not changed by aprocess are found by looking for datastores in the diagram which have a data flow fromthem to the process, but for which there is no flow from the process back to the datastore.Each datastore which is a destination of a dataflow is changed. Datastores becomeinclusions in the signature.

Each input is decorated with a "?", and each output with a "!". Internal inputs and outputsare not decorated. All the inputs and outputs, both internal and external, becomedeclarations in the signature. Their types are found by adding "-type" to the name andmaking the resulting name into a given set. If there were two data flows to or from theprocess with the same name, this name would appear only once in the signature of theprocess. This is a reasonable approach as it is unlikely that two outputs, say, would beidentical. One may be a copy of the other, in which case it should be named accordinglyas "copy.oL ... ". The given sets corresponding to external inputs and outputs aregenerated from external entities, while those corresponding to internal inputs and outputsare generated at the same time as the schema that uses them using this partial translationitself.

The schema is given the empty predicate. This is because information relating to thepredicate does not appear on a data flow diagram but must be obtained from othersources.

10

The process "Register-newCustomer" from the Bank example gives rise to a schema butno additional given sets (as there are no internal inputs or internal outputs). The schemais given the same name as the process. This process affects the single "Customers" datastore, and has one input, namely a customer's name.

Each datastore gives rise to a schema and a given set, which is needed to introduce thetype of the contents as the form of the information held in the store is not known from thedata flow diagram.

transstoretranspars

d e - store ( Odatastore )z_e - ( box ( Oschema ) I u ( given set ( storename " type" ) )

whereschemadatastore

n - storenamesig - ( dec ( store name " contents",

powerZset ( given ( storename - type" ) ) )pred - empty

The schema generated in this case has the same name as the datastore. The contents ofthe datastore do not appear on the diagram, so a contents list is inserted and acorresponding given set produced. This will need to be instantiated later. The contentsare given a powerset type, that is, the contents of a datastore are assumed to be a set ofthings. As in the case of a process, the schema generated has an empty predicate.

The datastore from the Bank example produces a schema and one given set. The schemarepresents the state data for the system. This data consists of a set of "Customers_type".

Bringing this all together gives the following function to translate the diagram elementsof a given diagram:

translate element -- X d e : DFDelement; diagram : DFD( g zi : F zelement-- transext v transproc v trans store * z e )

The function to translate a data flow diagram into a Z specification simply translates eachelement of the diagram in turn:

translate -- X d : DFD - U ( e : d.elements • translate element (e,d)I

The translation of the Bank example is as follows. The external entity gives rise to onegiven set:

translateelement (ext Customer, Bank)- ( given-set ("Customername"))

The process gives rise to one schema:

translateelement ( proc p, Bank I - ( box (a) )where

a : schema

s.n - "RegisternewCustomer"s.sig - ( inc ( "ACustomers" ),

dec ("Customername?", given ( "Customername-type")) Is.pred - empty

The datastore gives rise to one schema and one given set:

11

translate element ( store d, Bank ) -( bSox (p), givenset ( "Customers-type")

wherep : schema

p.n - "Customers"

p.sig - 1 dec ( Customers contents",powerset (given ( "Customerstype" ) ) ) )

p.pred - empty

There is a total of two schemas and two given sets. When displayed as a Z specification,the result will be as follows:

[ Customername type, Customers type ]

r CustomersCustomerscontents : P Customers type

RegisternewCustomer

ACustomersCustomername? : Customername type

The translation developed in this section produces a skeleton Z specification. This needsto be instantiated by defining in more detail the types of data actually used. The requiredinformation must be obtained from elsewhere as a data flow diagram cannot provide thenecessary information. The translation scheme provides a useful way of using a diagramto produce a well-structured Z specification.

Translationrules keeps transext, trans proc, trans store,translateelement, translate

12

5. Checking Compatibility

Data..flow-diagram :Module

Zspecification :ModuleI

Thslation-rules :Module

This section defines a relation, represents, which says what it means for a data flowdiagram and a Z specification to represent the same system. The complete Z specificationis not needed to check this compatibility. This is because a data flow diagram does notcontain any information about predicates. All that is needed of the Z specification is themapping from identifiers that appear in the specification to their types. This mapping willbe called a module spec. Such a mapping is produced by Zadok for each separatedocument (or module) of Z successfully type-checked, and forms the Z languagespecification of the module.

I modulespec : P (identifier - type)

The relation is defined in parts, in a similar manner to the translation function. That is, itconsiders each sort of diagram element in turn. A module specification is compatible withan external entity if all the names associated with that entity are in the specification; witha datastore if a schema with the same name is in the specification; and with a process if aschema with the same name and appropriate signature is in the specification.

I - partially represents _ : DFDelement 4 module spec

The parameters, that is, a diagram element and a module specification, are gathered intothe following schema:

part-parsde : DFDelementm s : module spec

External entities are dealt with first. Each name associated with the external entity mustbe in the module specification.

part extFpart parsd e e rng ext(ext -1 de).names r. dom ms

For a datastore and a module specification to be compatible there must be a schema withthe same name as the datastore.

part store

partpars

d e e rng store(store"4 d_e).storename e dom m_sms ( (stoxe"4 de).storename )e rng schema-type

For a process and a module specification to be compatible there must be a schema withthe same name as the process and with an appropriate signature. An additional function isneeded to flatten the signature of a schema, as operations are often defined in parts usingseveral schemas and all the identifiers from all the parts need to be considered. For

13

example, all references to unchanged datastores may be in one schema, which is thenincluded in the schema defining the operation. These datastores must be checked toensure that the operation is compatible with the diagram.

flatten signature -F F identifier

V sign signatureflatten sign - ( i identifier; t : type I dec (i,t) E sign - i ) UU ( name : schema name; s: schema / inc (name) e sign A s.n - name

( name ) v flatten ( s.sig ) }

This function retrieves all the identifiers present in a schema signature together with allthose implicitly present by virtue of a schema inclusion.

part procpart-pars

d e e rng procm s ( (proc"4 de).processname ) -powerset (schema-type (sign))

wheresign signature; ids F identifier

ids - flatten signV data flow; datastoreI destination - d e A origin - store ( Odatastore )A -, ( 3 dataflow' - origin' - d_e A destination' - origin)"3" - store name 6 ids

V data flow; datastoreI destination - store ( Odatastore ) A origin - d_e• "A" " storename e idsV data flow I destination - de A origin e rng ext* labeT - "?" e idsV data flow I destination e rng ext A origin - d e• label - "!" E idsV data flowI destination - de A origin e rng procv destination e ng proc A origin = d e* label E ids

For each data flow representing a look up of state data, that is, the flow goes from adatastore to the process and there is no flow from the process back to the same datastore,the flattened signature of the schema must include "Estore-name". For each data flowrepresenting a change of state data, that is, the flow goes from the process to a datastore,the flattened signature must include "Astore_name". For each input, internal input, outputand internal output, the flattened signature must contain an identifier the same as thelabel on the data flow, decorated with a "?" for inputs and a "!" for outputs.

Bringing this all together gives the following definition for partial representation:

V part.pars*de partially represents ms * part ext v part-store v partproc

And for the overall relation,

- represents : DFD 4- module spec

V d : DFD; m : module spec* d represents m *

U { d_e : d.elements; ms : module specI de partially represents ms • ms ) r m

This relation says simply that a diagram is related to a module specification if thatspecification contains all the sub-specifications that are related to each diagram element.

14

Relationship keeps module, Spec, part ext, part-store, flatten, partjproc,partia ly represents, represents

15

6. Rules for Generating a Data Flow Diagram from a Z Specification

Data-flow-diagram :Module

Z.specification :Module

Relationship :Module

This section defines a function, generate, which generates a data flow diagram from a Zspecification. A Z specification based on an example in [6] will be used to illustrate theprocess. This example specification is of a symbol table, with two operations defined onit: one to add an entry to the table, and one to look up the value of a symbol from thetable. Two sets are introduced, representing the symbols held in the table and theirvalues.

SS YM, VAL I

The symbol table itself is just a set of SYM-VAL pairs:

SSymbol -Table

at :P ( SYMX VAL

The first operation is to update the symbol table with a new SYM-VAL pair:

updatetiSymbol..Tablesym? : SYM

va1? : VAL

t", St 9 ( sym? 19 val? I

The second operation looks up the value of a symbol in the symbol table:

LookUpZSymbol_.Tablesym? : SYMval! : VAL

sym? E dom (st)val! - at (aym?)

The diagram generating function is again defined in parts, each talking a Z specificationand generating part of the data flow diagram. Datastores are generated from thoseschemas defining (part of) the state, processes from those schemas defining operations onthe state, and external entities from the inputs and outputs of the schemas definingoperations. Information from the signatures of the schemas defining operations is used togenerate the data flows.

One data store is generated for each schema representing part of the state.

16

gen_dtastores : z_specification -4 P datastore

V z z specification * gen.datastores z m( schema; datastoreI box (Oschema ) e zV *I : eig I el E rng inc e hd (incl el) 9 ( 'A', '3 11store name - nO edataitore )

State schemnas are identified by the absence of any schemas representing a change of statein its signature. Each datastore is given the same name as the relevant schema. Anypredicate in the schema is ignored.

In the example Z specification, one datastore is generated from the schemaSymbol-Table.

Sd : datastore

d.store name - "Symbol-Table"

This datastore is given the same name as the schema.

An external entity is generated for each input and output in a schema defining anoperation on the state. Each external entity generated will have one name associated withit. This could be relaxed if required so that no external entities are generated. Instead dataflows representing inputs and outputs to the system could be left with one end unattachedto any diagram element, and appropriate external entities added using informationobtained from other sources.

genexternalentities z specification -+ P external-entity

V z : z specification • gen external entities z -( schema; external entity; i : identifier; ty : typeI box ( eschema )Fe zlast i e ( '?', '!' I A dec ( i, ty ) E signames - ( front i )B external-entity I

Inputs and outputs are found by looking for identifiers ending with a "?" or "!" whichappear in the signature of a schema. The type of the identifier is irrelevant, as thisinformation does not appear on a data flow diagram.

In the example Z specification, there are two operations defined on the state, namelyUpdate and LookUp. Each of these generates the same two external entities. Thus, thegenerated diagram will contain the following two external entities:

el : external.entity e2 :external entity

el.names -("sym" I e2.najnes - I "val")

A process is generated for each schema that defines an operation on the state. Thepenerated process will have the same name as the schema, the inputs will be thoseidentifiers which end with "?" in the schema, and the outputs those which end with 1".The order of the inputs and outputs does not matter. It is impossible to tell in generalfrom the Z specification whether an identifier which does not end in "?" or "I" is aninternal input or an internal output, so no attempt is made to distinguish the two. Allidentifiers which are not inputs, outputs or inclusions are treated as internal inputs oroutputs. The predicate part of the schema is ignored.

17

gen processes : zspecification -+ P process

V z : z_specification ° genyprocesses z -( schema; processIbox (Oschema ) e z3 sn schemaname I hd sn E { "h', "Z" ) * inc ( sn ) e sigprocessname - nrng inputs - ( i: identifier; ty type

I last i - ? dec (i, ty) e sig* front i )

rng outputs - : .z identifier; ty : typeI last i - "A" A dec (i, ty) e sige front i }

rng int inputs u rng int outputs -F! : identifier; ty typeI last i 9 { "?', '!' A A dec (i, ty) E sig

0 process I

A check is made that the schema does represent an operation, by requiring that thereshould be at least one inclusion in the signature which represents a change of state. Theexample Z specification generates two processes, one for each operation. These are asfollows:

pl : process p2 : process

pl.process name - "Update" p2.process name - "LookUp"pl.inputs - ( "sym", "val" ) p2.inputs - ( "sym" )pl.outputs - 0 p2.outputs - ( "val" )pl.intinputs - 0 p2.intinputs - 0pl.intoutputs - 0 p2.int outputs - 0

Data flows are generated for each read of the state (that is, for every "-datastore" in asignature of a schema defining an operation), for each state change, and for each inputand output. There is insufficient information to join up internal flows, so these cannot befilled in on the generated diagram but must be filled in by hand afterwards. This isbecause internal flows are just undecorated identifiers, and, if the same identifier appearsin four schemas, say, there is no way of knowing which two pairs are joined by thedataflow, nor in which direction the data are flowing. The four known cases will bedefined in turn.

Each read of the state generates a flow from the datastore to the process concerned.

gen data flowsI --1 z : z_specification" schema; data flow; i : identifier

Inc i e sig -A hd i - "-"origin - store ( g ds : (gen_datastores z)

/ ds.store name - tl i o ds )destination - proc ( g p : (genprocesses z)

I p.processname - n * p )label - ""o edataflow I

Reads are identified by the presence of an inclusion of the form "Boschema.name". Theorigin of the flow is the store with the corresponding name, and the destination theprocess with the same name as the schema in which the inclusion was found. No label isput on the data flow.

Each state change generates a flow from the process concerned to the relevant data store.

18

gen data flows 2 - z: z specification o7sch-ema; i: identifier; data flowI inc i e sig A hd i - 'AIdestination - store ( gL ds : (gen_datastores z)

I ds.storename - tl i o ds )origin - proc ( IL p (genprocesses z)

I p.process name - n e p )label -

• Odataflow I

State changes are identified by the presence of an inclusion of the form"Aschemaname". The origin of the flow is the process with the same name as theschema in which the inclusion was found and the destination the store with thecorresponding name. No label is put on the data flow.

Data flows are generated for each input:

gen data flows 3 -- X z : z specification *

i sch-ema; i-: identifier; data flowI i E dom ( dec" I sig I ) A last i -origin - ext ( g e : (gen external entities z;

I e.names ( (front 1', . e )destination - proc ( g p :(gen processes z)

I p.processname - n * p )label - front i

• edata flow )

Inputs are identified by the existence of a declaration in a schema, with identifier endingwith a "?". The origin of the flow is the external entity with the identifier without the "?"as its associated name, which is also the label put on the data flow. The destination is theprocess with the same name as the schema in which the input was found.

Data flows are generated for each output:

gen_data flows 4 -- z : z_specification( schema; 1i : identifier; data flowI i E dom ( dec- I sig I ) A last i -destination - ext ( g e : (gen external entities z)

I e.names - (front -1 e )origin - proc ( g p : (genprocesses z)

I p.processname - n * p )label - front iO data flow )

Outputs are identified by the existence of a declaration in a schema, with identifierending with a "!". The destination of the flow is the external entity with the identifierwithout the "!" as its associated name, which is also the label put on the data flow. Theorigin is the process with the same name as the schema in which the output was found.

Bringing this all together into one rule gives:

gen dataflows : zspecification -4 P data-flow

V z : z specification• gen dataflows z - ( gen data flows I z )

u ( gen"dati'flows2 z )u ( gen data-flows.3 z )u ( gendata.flows4 z )

The example Z specification generates six data flows. The operation Update generatesone from the update process to the datastore. It also generates one from the externalentity with name "sym", and one from the external entity with name "val". The operation

19

LookUp generates one data flow from the datastore to the lookup process, one from theexternal entity with name "sym" and one to the external entity with name "val".

Bringing all the partial generating functions together gives the following function forgenerating a data flow diagram from a Z specification, provided that the specification iswritten in the style of state schemas and operations on (part of) the state:

generate : z specification - DFD

V z : z specificationgenerate z - d

whered : DFD

d.elements - store I gen datastores z Iu ext I gen external entities z IU proc I genproces~si z I

d.flows - gen dataflows z

The diagram resulting from the example developed in this section is shown in Figure 2.

Translation rules have been developed not only for developing a Z specification from adata flow diagram (in Section 4), but also for generating a data flow diagram from a Zspecification, described in this section. This latter is a useful way of illustrating a Zspecification so that the structure becomes clear. The diagram produced will aidunderstanding of the specification and will help with the process of validating thespecification.

Generatingrules keeps gendatastores, genexternalentities,genyprocesses, gendataflows, generate

20

Update LookUp

Symbol Table

Figure 2 The Generated Data Flow Diagram

21

7. Conclusions

This report has presented three approaches to using a formal language, Z, with astructured diagrammatic technique, data flow diagrams. These approaches are translatingdata flow diagrams into a Z specification, checking consistency of a diagram and a Zspecification using the relationship between them, and generating a diagram from a Zspecification written in a state-based style.

A particular interpretation has been put on both data flow diagrams and Z, and this needsto be validated. However, it is based on the standard style of using Z, that is, usingschemas to specify both the state and operations on that state. Translating a data flowdiagram into Z produces only an outline specification. This specification should be usedas a starting point, a way of structuring a specification. Conversely, generating a dataflow diagram from a Z specification may lead to a large diagram. This would occur in thecase where an operation is defined in parts, each part in a separate schema. If thecomplete operation only were used in the generation process then a sensible diagramwould result. If, however, diagram elements were generated for each part, then theresulting diagram would be cluttered. A useful approach would be to use the separateparts of an operation to generate a separate diagram describing just that operation.

The data flow diagram may be considered to be a high level overview of the system.Therefore, it is not surprising that a small amount of Z is produced. The usefulness of therelationship defined is that it provides a mechanical check that the high level overviewgiven by a data flow diagram is consistent with the more detailed description given by aZ specification. There are other information flows contained in a Z specification, forexample, the inclusions of schemas within other schemas. A similar diagram to a dataflow diagram could be automatically generated to produce a "usage tree" of thespecification. This would be of great help to reviewers of the specification as it wouldhelp them to navigate through the specification and keep track of the usage of schemas.

The specifications given in this report could be used to build a tool to carry out the threetechniques, preferably as part of an integrated support tool. However, data flow diagramsare only one of a number of techniques used in a structured method such as SSADM.Other diagrammatic techniques include entity life histories and logical data structuring(also called entity modelling). This work with data flow diagrams and Z hasdemonstrated the usefulness and practicality of combining structured and formalmethods, and a follow-on to this would be to carry out similar studies for the otherdiagrammatic techniques. The eventual aim is a toolset which will allow outline formalspecifications to be generated automatically from a set of diagrams, which may then beused in a formal development, if desired, of the required system. Alternatively, themathematical specifications may be used to prove properties of the system. Generatingdiagrams from a formal, mathematical specification will aid validation of thatspecification as diagrams are easier to understand than a mathematical specifiation, andare not so daunting at first sight.

This work, by providing a set of formal rules to translate a diagram into a formallanguage, has resulted in the diagrams themselves becoming formal objects, with all theassociated benefits of precision and lack of ambiguity. Adding this formal basis has notdetracted from the readability of the diagrams. This demonstrates that formal languagesare not necessarily harder to understand. It is the mathematical symbols of current formallanguages such as Z that make them seem more daunting than they really are.

22

References

[1] G P Randell, "The Integration of Structured and Formal Methods", RSREMemorandum No. 4293, June 1989

[2] J M Spivey, "The Z Notation: A Reference Manual", Prentice-Hall InternationalSeries in Computer Science, 1989

[3] G Longworth and D Nicholls, "SSADM Manual", Version 3.0, NCC, December 1986

[4] Yourdon International Ltd., 'The Yourdon Structured Method (YSM)", Yourdon,1988

[5] Systems Designers Scientific Ltd., "CORE - the Method", Issue 1.0, November 1985

[6] I Hayes (Editor), "Specification Case Studies", Prentice-Hall International Series inComputer Science, 1987

[7] G P Randell, "Zadok User Guide", RSRE Memorandum No. 4356, January 1990

23

THIS PAGE IS LEFT BLANK INTENTIONALLY

REPORT DOCUMENTATION PAGE DRIC Rfne Nurrd (iknown~)..............

Oveallsecrisecurity oalo ofshet ..........l... of...shee............U CLA SIFED .. .....U..CLASSI..................................... ....(As far as possible ties et shold contain only unclassilled Wfnfortion. It it Is necessary to enter classified Inforfmtlo the field concernedmaust be marked to Indicate the dasalficeton eg (R), (C) or (S).

RSRE, St Andrews RoadMalvern, Worcs WR14 3PS

Monitoring Agency Name and Location

Tfe

TRANSLATING DATA FLOW DIAGRAMS INTO Z(AND VICE VERSA)

Foreign Language Title (In the case of translations)

Conference Details

Abstract

This report describes the results of work into the integration of structured and formal methods, inparticular, data flow diagrams and Z. Data flow diagrams are given a formal, mathematical basis bydefining rules to translate these diagrams into Z. Rules are also given for generating a data flow diagramfrom a Z specification, and for checking the compatibility of a data flow diagram and a Z specification.

Abstac Classification (UARC or 8)U

DMstrvbution Imn (Enter any lintations on the distribution of the document)

UNLIMITEDsow

THIS PAGE IS 1.11 BLANK INTENTONALLY