- Email: [email protected]
A Petri Net based compiler for the prototyping language RELOS
North-Holland Microprocessingand Microprogramming24 (1988) 471--482
A
PETRI
NET
BASED
COMPILER
471
FOR
Volker Matthias
THE
PROTOTYPING
LANGUAGE
RELOS
Gruhn Hallmann
U n i v e r s i t y of D o r t m u n d C o m p u t e r Science / S o f t w a r e - T e c h n o l o g y P.O. Box 500 500 D-4600 D o r t m u n d 50 Federal R e p u b l i c of Germany
In this paper we present a compiler for a prototyping language, c a l l e d RELOS. RELOS allows incomplete r e q u i r e m e n t description. From our point of view a p r o t o t y p e is an o p e r a t i o n a l model. The applicative language bases on the conceptual model of a set of subsystems c o m m u n i c a t i n g via m e s s a g e transfer. Special features like concurrency, nondeterminism, multicasting, and a time concept are included in RELOS. The semantic of RELOS is d e f i n e d by extended Petri Nets (called F u n c t i o n Nets or for short FN), w h i c h are a w e l l - f o u n d e d basis enabling analysis and traces. We d e s c r i b e the way how the RELOScompiler works. In detail the m a p p i n g of language constructs onto Function Nets is emphasized. An i n t e r a c t i v e n e t - s i m u l a t o r makes the model operational. Other tools like a c o n s i s t e n c y - c h e c k e r , and a neta n a l y z e r are part of an i n t e g r a t e d p r o t o t y p i n g environment.
1
INTRODUCTION
Requirement e n g i n e e r i n g is a process for the identification of faded requirements for a product. Existing r e q u i r e m e n t d e s c r i p t i o n models are not sufficient for incremental specification of a c o m p l e x target system (e.g. distributed systems, open systems, computer integrated manufacturing, office automation, e m b e d d e d systems, or m u l t i d a t a b a s e systems). Requirement definition is a not yet solved problem in computer science. Functional and n o n f u n c t i o n a l requirements must be d e s c r i b e d in an understandable, modifiable, precise, unambiguous, complete, i n t e r n a l l y consistent and m i n i m a l form. Up to now no solution is p r e s e n t e d to the most urgent problem: how can a user define its ~erhaps not clear but unstructured) r e q u i r e m e n t s in a s t e p w i s e manner? It isn't p o s s i b l e that x users describe the problem in the same breath, because they have x views about the problem. F u r t h e r m o r e the p r o b l e m has to be d e c o m p o s e d into smaller subproblems. R e q u i r e m e n t e n g i n e e r i n g is an incremental e v o l u t i o n a r y process with i t e r a t i n g r e q u i r e m e n t d e f i n i t i o n steps.
A new a p p r o a c h c a l l e d p r o t o t y p i n g has been copied from other engineering science o v e r c o m i n g the p r o b l e m s discussed above. The term p r o t o t y p e is derived from the Greek term prototypos, which stands for model (protos means first and typos means pattern). But the semantic of the term is ambiguous in c o m p u t e r science. The following classification gives an o v e r v i e w about the wide spectrum of p r o t o t y p i n g in the l i t e r a t u r e [3], [2]: - rapid c o n s t r u c t i o n of user interfaces, - c o n c e p t u a l and net-modeling, - formal and o p e r a t i o n a l specification, - high level p r o g r a m m i n g languages, - simulation, - r e u s a b l e software components, - quality a s s u r a n c e methods, as well as - tools and e n v i r o n m e n t s s u p p o r t i n g the software life cycle. For our p u r p o s e we define the term prototype in the following form: "a prototype is an operational model a b s t r a c t i n g details from a real system and h a v i n g the same functional behaviour. The p r o t o t y p e is used as a c o m m u n i c a t i o n object and offers a p o s s i b l y i n c o m p l e t e solution". No a c c e p t e d standard solution exists for the mapping of ideas onto the real system. In this p a p e r we d e s c r i b e the c o m p i l e r of the operational language RELOS. The
V. Gruhn, M. Hal/mann/A Petri-Net Based Compiler for RELOS
472
semantic of RELOS is d e s c r i b e d by extended Petri Nets that will be interpreted by a net-simulator. The compiler consists of a scanner, a parser, a c o n s i s t e n c y - c h e c k e r and a codeproducer. The tools are part of a p r o t o t y p i n g environment, called PROTOS.
2 RELATED RELOS
WORK AND BASIC
FEATURES
quick u n d e r s t a n d i n g of applicative languages. The i n t e r e s t i n g operational and applicative language PAISLey [ii] is o r i e n t e d towards e m b e d d e d systems. The main topic is the c o m m u n i c a t i o n mechan i s m b e t w e e n p r o c e s s e s ("exchange function"). The semantic of PAISLey is d e f i n e d by an interpreter. At this time [12] only a p r o t o t y p e interpreter but no c o n s i s t e n c y - c h e c k e r is available.
OF
2.2 A Short In the last ten years some formal s p e c i f i c a t i o n t e c h n i q u e s and languages have been p r e s e n t e d which pretend to overcome the problem of requirement description and s p e c i f i c a t i o n of complex systems. One of several aspects of a language is the formal semantic definition (interpreter, compiler, algebraic, axiomatic, or denotational semantic).
2.1 A p p r o a c h e s Executable
Making
a
Language
One of the first remarkable process model a p p r o a c h e s for d i s t r i b u t e d system e n g i n e e r i n g is called R S L / R S A p r o p o s e d in the project SREM [i]. Systems are described by a set of objects and corresponding relations b e t w e e n them. A formal foundation is p r e s e n t e d with requirement-networks but the semantic isn't d e s c r i b e d completely. The specification language GIST [6] bases on the d e f i n i t i o n of objects and relations, too. A GIST specification can be executed, because the dynamic properties are the initiation, deletion, insertion and put out of objects and relations in respect to a data base. The s e m a n t i c of the s p e c i f i c a t i o n language OBJ [5] is d e f i n e d axiomatically. An algebraic specification (abstract data type) is executable by a term r e w r i t i n g system. But concurrency, nond e t e r m i n i s m etc. cannot be d e s c r i b e d in OBJ. For the p u r p o s e of p r o t o t y p i n g other languages with applicative concepts are of interest. A p p l i c a t i v e languages are functional languages, but they allow the use of v a r i a b l e s and assignments local to one function. In applicative languages expressions are evaluated without side effects. Expressions are built by constants, formal parameters and function-calls. Because only the value of an e x p r e s s i o n is of interest, this value can be r e p l a c e d by another syntactic expression with the same semantic. The p r i m i t i v e syntax allows
Introduction to RELOS
In our opinion a p r o t o t y p e is a first e x e c u t a b l e model simulating the target system. At this place we give a short o v e r v i e w about the a p p l i c a t i v e language RELOS (REquirement D e s c r i p t i o n ~ a n g u a g e for Q/oen ~ystems) [8] e s p e c i a l l y designed for requirement description and p r o t o t y p i n g b a s e d on simulation. Several language p r o p e r t i e s exist d e d i c a t e d to distributed system specification. The p h i l o s o p h y of RELOS bases on subsystems (SS) which communicate via message passing. Each SS is e x e c u t e d on an abstract p r o c e s s o r offering a set of services (called global services) to other SS. A global service is i n i t i a t e d by r e c e i v i n g a message. A set of local services only known S S - i n t e r n a l l y are u s e d while e x e c u t i n g a global service. The local services manage a set of local resources of a SS. RELOS supports the d e s i g n e r in specifying the application p r o b l e m with: - scenario definition for incomplete requirement description, - message and local resource description (by aggregation, enumeration, list d e f i n i t i o n of basic types etc.), - global and local service definition, called by_ or respectively, and using - e x e c u t i o n e x p r e s s i o n s d e s c r i b i n g concurrency, n o n d e t e r m i n i s t i c and deterministic alternative, sequence, a s s i g n m e n t s etc. - unicasting, m u l t i c a s t i n g and broadcasting, - a set of p r e d e f i n e d built-in functions (arithmetic, boolean, list functions, and userinput), - d e f i n i t i o n of w a i t i n g queues, - a c k n o w l e d g e m e n t and protocol mechanism on the a p p l i c a t i o n p r o b l e m level, - requirements of time and time consumption, - export of services to certain subsystems, and - interactive simulation as well as r e u s a b i l i t y of services. A short example given in figure 2-1 shows the syntactic frame of a
V. Gruhn, M. Hallmann / A Petri-Net Based Compiler for R E L OS
subsystem describing some language features (built-in functions are underlined, c o m m e n t s e m b r a c e d by "/*" and "*/", k e y w o r d s w r i t t e n in bold). The global service account[] of the s u b s y s t e m Bank is called by a C u s t o m er sending the message NAME. The Bank m a n a g e s a d a t a - b a s e DB c o n s i s t i n g of a set of accounts ACC. The activated service account[] calls inside its execution plan the local service lookat[]. The result (here ACC.BALANCE) is given back to the calling global service and sent to acc-answer[] of the s u b s y s t e m Customer.
3
H O W THE R E L O S - C O M P I L E R
473
PRODUCES
NETS
A lot of a p p r o a c h e s for the design of distributed systems use net modeling because nets offer a graphical interface. If the refinement of the system design steps into more detail the r e s u l t i n g nets b e c o m e very complex and hard to u n d e r s t a n d for non-experts. In our approach the language is very simple and offers specific constructs for c o m m u n i c a t i o n . F u r t h e r m o r e the prod u c e d nets can be analyzed. The principle way the R E L O S - c o m p i l e r works is
messages NAME :STRING /* two p o s s i b l e message types */ ACCOUNT :INTEGER end s u b s y s t e m Bank global_services account : EVENT x NAME --> EVENT /* d e c l a r a t i o n */ account[NAME] == C u s t o m e r a c c - a n s w e r [ l o o k - a t [ D B , N A M E ] ] /* definition, first calling--local service "look-at" and then sendin the result to the global service "acc-answer" of SS "Customer" */ end local r e s o u r c e s ACC--= (NAME : STRING x /* structure of an account */ B A L A N C E : INTEGER) /* using a g g r e g a t i o n */ DB = list of ACC /* local data base "DB" as a list of accounts */ end local services lookTat : DB x NAME --> A C C . B A L A N C E /* d e c l a r a t i o n */ look-at [DB,NAME] /* d e f i n i t i o n */ if nQ~[emDtv[DB]] then if e a [ h e a d [ D B ] . N A M E , N A M E ] then /* s e l e c t i o n of the first head[DB].BALANCE and t h i r d component */ else look-at[tail[DB],NAME] /* recursion */ fi fi end end = =
Fig.2-1:
The o p e r a t i o n a l s e m a n t i c of RELOS is described by a compiler mapping a RELOS-requirement description onto e x t e n d e d Petri Nets, w h i c h can be simulated by a n e t - i n t e r p r e t e r . Language features like concurrency, n o n d e t e r m i n ism, non-suspending procedure calls, and time c o n c e p t s can be easily described. These features p r o d u c e many problems in other languages. In the following c h a p t e r we d e s c r i b e the w o r k i n g of the R E L O S - c o m p i l e r by some examples.
A RELOS
example
shown in the f o l l o w i n g figure. A f t e r the R E L O S - s c a n n e r has c h e c k e d the RELOS program a stream of tokens is p a s s e d to the RELOS-parser. If no synt a c t i c errors occur the p a r s e r p r o d u c e s a p a r s i n g tree. Before the c o d e - p r o d u cer generates Function Nets a consistency-checker checks the parsing tree against p o s s i b l y w r o n g functionalities and use of d e c l a r e d and defined services and some other kinds of mistakes and i n c o n s i s t e n c i e s .
V. Gruh n, M. Hal/mann/A Petri-Net Based Compiler for R E L OS
474
RELOS-,c ............... i ~
I
I
R~LOS -
(~
Fig.3-1:
3.1
. . . . . . . . . . ~'L__'.'_"_" _ J
,
code-producer
The structure compiler
Underlying
Model:
of
the
Function
RELOS-
Nets
P e t r i N e t s [I0] h a v e b e e n increasingly u s e d for t h e d e s c r i p t i o n of s t a t i c and d y n a m i c s t r u c t u r e s in t h e r e c e n t y e a r s . T h e i r a d v a n t a g e s are t h e well-defined, mathematical foundation, ans t h e graphical representation. Petri Nets can be analyzed automatically (deadlock occurrence, liveness, etc.) a n d that c o n c u r r e n c y can b e d e s c r i b e d n a t u r a l l y . Function N e t s are e x t e n d e d P e t r i Nets [4]. The e x t e n s i o n s c o n c e r n t h e f o l l o wing points: - m o d i f i c a t i o n of t h e f i r i n g rule, distinction between message and cont r o l flow, - distinction between different kinds of m e s s a g e flow, u s e of d i f f e r e n t m e s s a g e t y p e s associated with the tokens, use of a time concept, - concepts for m o d e l i n g u s e r interactions - s c h e d u l i n g c o n c e p t s for c h a n n e l s c o n t a i n i n g a set of t o k e n s , - application of a set of functions associated with the agencies. -
i) B e t r i N e t C ~ A = 0, T ~] S = Z T C_ C x A, S C A x C d o m (T U S) = C, i m a g (T U S) = A A : set of a g e n c i e s ( t r a n s i t i o n or i n s t a n c e ) , C : set o f c h a n n e l s (place), T : target relation and S : source relation 2 ) Aoency A = {al , a 2 , . . . , a n } w h e r e ai (Job x C o n s u m e ) , i = i, ...,n w h e r e J o b = {Jl, J2, .-., Jm} (identification of associated program) where Ji 6 (NAME x Fire) , i = 1 ..... m (name a n d k i n d of f i r i n g rule) w h e re Fire = {ALL, SOME_IN, SOME_OUT, SOME } C o n s u m e = N 0\{o~} (time-consume) 3) C h a n n e l C = {ci, c2, ..., c k } w h e r e ci 6 (Acc x Cap) , i = i, ...,k where A c c = {FIFO, L I F O } (kind of access) Cap = N O (capacity) 4) F l o w r e l a t i Q n T = {tl, t2. ..., t I } w h e r e ti 6 (C x A x Inkind) , i = 1 .... ,i where I n k i n d = {IN, CO, ST} (input r e l a t i o n ) S = {sl, s2, ..., Sp} w h e r e s i [ (C x A x O u t k i n d ) , i = l,...,p where O u t k i n d = {OU, FI} {output r e l a t i o n ) 5) M a r k i n q M : C --> T O K E N (initial m a r k i n g ) T O K E N = set of A S C I I - s t r i n g s x T Y P E TYPE = {REAL, S T R I N G , B O O L E A N }
-
Function N e t s c o n s i s t of t w o disjunct sets of nodes, called agencies and channels (corresponding with transitions a n d p l a c e s in t r a d i t i o n a l Petri Nets), w h i c h are c o n n e c t e d b y d i r e c t e d arcs. In t h e s e q u e l a d e d i c a t e d v e r s i o n o f t h e o r i g i n a l F u n c t i o n N e t c o n c e p t is introduced. A complete definition of the original concept can be found in [4]. A F u n c t i o n N e t is a 5 - t u p e l F N = (A,C,T,S,M) d e f i n e d as f o l l o w s :
In i) t h e P e t r i N e t s t r u c t u r e is defined. 2) d e f i n e s t h e s t r u c t u r e of a g e n cies. The definition shows that an agency represents a time-consuming activity. The kind of the activity a s s o c i a t e d w i t h t h e a g e n c y is d e s c r i b e d by the Job-component. T h e v a l u e of t h e Job-component is t h e n a m e of a small p r o g r a m (e.g. a r i t h m e t i c , b o o l e a n , list o p e r a t i o n s etc.), w h i c h w i l l be e x e c u ted when the agency fires. The job associated with an agency processes messages. I n p u t m e s s a g e s are t a k e n as p a r a m e t e r s a n d one or m o r e o u t p u t messages are p r o d u c e d . The third point describes the channel structure. Messages are s t o r e d in w a i t i n g q u e u e s . T h e s e q u e u e s c a n b e a c c e s s e d in a L I F O - or a FIFO-strategy. The maximal length of
V. Gruhn, 114.Hallmann / A Petri-Net Based Compiler for RELOS
w a i t i n g queues is d e t e r m i n e d by fixing the capacity of the channels. The fourth point d e s c r i b e s the token flow. The token flow characterizes the sy s t e m ' s d y n a m i c behaviour. The flow of tokens is d e t e r m i n e d by the firing of agencies under certain well-defined conditions and in d e p e n d e n c y on the token values in the input channels at firing time. In c o m p a r i s o n to t r a d i t i o nal Petri Net models the firing rule is extended. The Fire-component of an agency d e s c r i p t i o n can define the following kinds of firing: ALL
SOME
IN
SOME OUT
SOME
t r a d i t i o n a l firing rule, that means reading tokens from all input channels and writing into all output channels, reading tokens from some input channels, w r i t i n g into all output channels, reading tokens f r o m all input channels, w r i t i n g into some output channels, reading tokens from some input channels, w r i t i n g into some output channels
The flow r e l a t i o n can be - as i n d i c a t e d in 5) - s u b d i v i d e d into different classes of arcs. Their m e a n i n g s are: IN d e s t r u c t i v e reading, that means a message token is read and removed from the channel, CO copy reading, that means a m e s s a g e token is read, ST the token is c o n s i d e r e d as a control token, that means the value is of no importance; the message is removed, OU w r i t i n g a m e s s a g e token into output channels, FI a control token is w r i t t e n into the output channel. Apparently there is a d i f f e r e n c e between any kind of t y p e d m e s s a g e on the one and control tokens on the other hand. The d i f f e r e n c e is realized by connecting c h a n n e l s via special arcs. By r e a d i n g via an ST-arc or by writing via an FI-arc a message becomes a control token. In F u n c t i o n Nets the execution of an activity associated with an agency can consume time. The execution time is described in the TIME-component of the agency description. The e x t e n s i o n s c o n c e r n i n g the separation of m e s s a g e and control flow, the modified firing rules, and the time concept do not affect the properties of Petri Nets, b e c a u s e the o c c u r r e n c e s of these e x t e n s i o n s can be r e p l a c e d by so c a l l e d basis Petri Nets [4] or by subnets w h i c h do not i n c o r p o r a t e these extensions. The use of these e x t e n s i o n s
475
only p r o v i d e s a h i g h e r level of comfortability. The i n i t i a l i z a t i o n is d e f i n e d by the function M d e s c r i b e d in 5). The type and the v a l u e of the token must be given in order to define a correct channel initialization. A channel can be i n i t i a l i z e d by one or more tokens. In the f o l l o w i n g a g r a p h i c a l represent a t i o n of a very simple FN i n c l u d i n g an instance a s s o c i a t e d with the a r i t h m e t i c job "ADD" is presented. Two input channels of the A D D - a g e n c y are connected via "CO"-arcs, and the third input channel is read via an "IN"-channel. A f t e r firing the instance the result of the a d d i t i o n can be found in the output channels.
A c o m p l e t e set of a v a i l a b l e jobs can be found in a library [7]. The library can be e x t e n d e d if special jobs are needed. 3.2 RELOS Language Transformation
Concepts
and
their
This chapter starts with the description of very general language constructs w h i c h will be found in every language. S p e c i f i c c o m m u n i c a t i o n facilities are especially emphasized b e c a u s e they are R E L O S - s p e c i f i c . Their t r a n s l a t i o n shows d i f f i c u l t i e s arising when the complete t o p o l o g y of the produced net depends on results being d e l i v e r e d by the s i m u l a t i o n of parts of the p r o d u c e d net. F u r t h e r o n we d e s c r i b e the t r a n s l a t i o n of execution expressions used by global services.
a) General
Language
Constructs
Application Three d i f f e r e n t kinds of service applications will be d i s t i n g u i s h e d : the calling of a service or a b u i l t - i n function with (a) and without included parameters (b). Furthermore applications can occur in the p a r a m e t e r list of other applications. The following figure shows these three kinds of applications. In (c) the services a and b are a c t i v a t e d concurrently.
a[]
sT o
V. Gruhn, M. Hal/mann/A Petri-Net Based Compiler for RELOS
476
PAR1 a[PAR1. PAR2]
I
~
PAR2
SC:
SELECT-COMPONENT ~ y ' C O
b)
Intersubsystem
Communication
ST PO [ ~ [ / ~ 1 N Global
c[a[], b[]]
ST ~
if-then-else-fi The result of the d e t e r m i n i s t i c alternative depends on the e v a l u a t i o n of the first expression (execution of the function a). Either the result of the execution of the then-expression (execution of b) or the result of the evaluation of the else-expression (execution of c) is delivered. In order to g u a r a n t e e that exactly one of the results is p r o v i d e d to the following instances a c o l l e c t i n g channel is used, which is filled either by the last instance of the net c o r r e s p o n d i n g with the t h e n - e x p r e s s i o n or with the last expression of the net corresponding with the e l s e - e x p r e s s i o n . In the following figure the t r a n s l a t i o n of an ife x p r e s s i o n is shown. if a{]
then
ST
b[]
else
OH
Services
Global services are o f f e r e d by a subs y s t e m to other subsystems. They can be seen as an entry point used for communication. For every global service described in the r e q u i r e m e n t document a so-called service d e s c r i p t i o n element (sde) is c r e a t e d at the beginning of code p r o d u c t i o n . An sde comprises the complete name of the service (that means a name of the form < s e r v i c e identification>) and a r e f e r e n c e to the first instance of the FN c o r r e s p o n d i n g with the global service. The f o l l o w i n g figure shows a list of sde's for the global services SI_gAI, SI_gA2, and S2_gAI.
S1_ I 81
S2
c[] fi
IN
FI / ~
It is worth to point out that the firing b e h a v i o u r SOME OUT is n e e d e d for the t r a n s l a t i o n of an--ifexpr. In the FN given above the IF-agency p r o v i d e s the SOME O U T - b e h a v i o u r in order to guarantee ~hat e x a c t l y one of the subnets is activated.
Selection By u s i n g a " s e l e c t - e x p r e s s i o n " a component of an a g g r e g a t e d object can be selected. In the following figure a c o m p o n e n t w i t h the name "X" is s e l e c t e d from the object d e l i v e r e d by the activation of a. A s s u m e d that "X" is the name of the s e c o n d component of the result of a, the following figure r e p r e s e n t s the p r o d u c e d net. The position of "X" is read from the second input channel. This channel is connected by a "CO"-arc in order to provide the p o s i t i o n again at any a c t i v a t i o n of the agency.
~_~[-~ [_~
ou
Casting
IN
OU
Mechanisms
Some special c o m m u n i c a t i o n constructs dedicated to describe distributed systems exist in RELOS. This c o m m u n i c a tion facilities are described by c a s t i n g mechanisms. These casting constructs are used for the communication between global services of different subsystems. The principal difference between global and local services is that a global service doesn't receive a result after a c t i v a t i n g another global service ("non-suspending-procedurecall"). In opposite to this a local service returns a result. The calling global service only initiates another global service by sending a message, but it doesn't control its execution. We d i s t i n g u i s h three different kinds of c a s t i n g mechanism: - u n i c a s t i n g (I:I communication), - m u l t i c a s t i n g (l:n communication), and - b r o a d c a s t i n g (l:all communication)
V. Gruhn, M. Hal~mann/A Petri-Net Based Compiler for RELOS
The f i r s t p a r t of f i g u r e 3-2 s h o w s the u s e of t h e s e c a s t i n g constructs. Unicasting describes the activation of e x a c t l y one r e m o t e s e r v i c e . T h e a d d r e s s of this remote service can be given explicitly (3-2a) or its f i r s t p a r t c a n b e t h e v a l u e of a m e s s a g e (3-2b) . The m e s s a g e s o f an a c t i v a t i o n are p a s s e d to the sde of the addressed service. Multicasting is s y n t a c t i c a l l y similar to unicasting with implicit address. The d i f f e r e n c e is t h a t t h e f i r s t part of the called SS-name consists of a n a m e of a s t r i n g l i s t (3-2c) i n s t e a d of a n a m e of a s t r i n g . T h i s m e a n s t h a t all s t r i n g s i n c l u d e d in t h e s t r i n g l i s t are substituted for t h e list n a m e s t e p by step. T h i s m e a n s t h a t all t h o s e s e r v i ces are a c t i v a t e d , whose names consist of a s t r i n g w h i c h is p a r t of t h e given stringlist and the explicitly named s e c o n d p a r t of t h e s e r v i c e name. Broadcasting differs from the unicasting construct in t h e w a y that the s u b s y s t e m i d e n t i f i c a t i o n is r e p l a c e d b y "ALL". T h i s s h o w s t h a t all t h o s e g l o b a l services, whose second part corresponds with t h e s e c o n d p a r t of the broadcas t i n g c o n s t r u c t , are a c t i v a t e d (3-2d).
477
activating service. In f i g u r e 3 - 3 b t h e translation of a u n i c a s t i n g construct with implicitly given addressee is described. In o r d e r to a s s u r e to r e a c h t h e r i g h t a d d r e s s e e all p o s s i b l y c a l l e d services, r e s p e c t i v e l y t h e i r nets, are connected. The "address checknet" guarantees that only the really called s e r v i c e is a c t i v a t e d . That means that those services, whose names differ from the name which results from the p a r a m e t e r e v a l u a t i o n are s u p p r e s s e d at s i m u l a t i o n time.
Context: PARTNER = ('SITEA','SITEB','SITEC') /* e n u m e r a t i o n type M A I L S I T E S = ii$% Qf S T R I N G d e f a u l t [ M A I L S I T E S ] = ('SITEA', 'SITEB', ' S I T E C ' ) ; /* i n i t i a l i z a t i o n of MAILSITES SITEA, SITEB, SITEC, S I T E D are n a m e s of s u b s y s t e m s . (a) U n i c a s t i n g w i t h e x p l i c i t l y g i v e n S S - a d d r e s s s e n d m a i l : E V E N T x M A I L --> E V E N T s e n d m a i l [MAIL] == S I T E B _ g e t m a i l [MAIL] (b) U n i c a s t i n g w i t h i m p l i c i t l y g i v e n S S - a d d r e s s s e n d m a i l : E V E N T x P A R T N E R x M A I L --> E V E N T s e n d m a i l [MAIL x P A R T N E R ] == " P A R T N E R " _ g e t m a i l
[MAIL]
(c) M u l t i c a s t i n g sendmail sendmail
( s e n d i n g to f i x e d set of a d d r e s s e s ) : E V E N T x M A I L S I T E S x M A I L --> E V E N T [MAIL x M A I L S I T E S ] == f o r M A I L S I T E S _ g e t m a i l
(d) B r o a d c a s t i n g sendmail sendmail
: E V E N T x M A I L --> E V E N T [MAIL] == f o r A L L g e t m a i l
Fig.3-2:
The U s e
of t h e D i f f e r e n t
The m a i n p r o b l e m of t h e t r a n s l a t i o n of c a s t i n g m e c h a n i s m s i n t o F N is t h a t the structure of t h e F N isn't previously known. So we have to introduce so called "checknets" (see f i g u r e 3-3). In figure 3-3a the schema for the a c t i v a t i o n of one e x p l i c i t l y addressed r e m o t e s e r v i c e is shown. The sde of t h e called service is c o n n e c t e d with an instance of the schematically shown Function Net of the callinq or
[MAIL] Casting
Constructs
[MAIL]
*/
478
V. Gruhn, M. Hallmann / A Petri-Net BasedCompiler for RELOS
a) Unlcastlng with explicit address
SlteA-
SlteB-
SlteC- IslteO-
Sited -
Sub i
rma ead~
b) UnlcasUng with Implicit address
-
--~ ~'[
SlteB-
- SIteD." getma
address checknet
]"
address checknet
]"
address checknet
I J
I
Sub1_ sendma
SiteDreadmall
],
I
checking of the address during the simulation
c) Multlcastlng Same net structure as In b), but with a different kind of address ichecknet, whtchenables the activation of more than one service. d) Broadcasting
$1teA'
~ SiteS-
SiteC-
~ SiteD-
getmal
getma
getma
getma
~
~
~
Sub1
SiteD-
send~ ma
readma
~
~
Fig.3-3: The Translation of the Different Casting Mechanisms In order to illustrate the reason for using checknets we give a short
At first the parameter containing the implicite address is duplicated. The number of duplicates is as big as the number of subsystems providing the demanded service. One of these duplicates and a copy of the set of parameters is passed to the checknet. Afterwards the "address checknets" evaluate the parameter containing the address of the subsytem. The result of this evaluation is compared with the names of all those subsystems providing the demanded service. Each checknet is responsible for the comparison with exactly one subsystem name. The above given checknet compares the parameter value with the subsystem name "SITEA". If this comparison is successful the parameters are passed to the actually addressed subsystem. Otherwise nothing is done. This behaviour is realized by the job "TRUE?" If the input of the agency associated with this job has the value "TRUE" a control token is produced, otherwise nothing happens (that means that this agency fires according to the firing rule "SOME OUT"). The other subsystems (that mea~s those which are not addressed by the parameter value) are not activated. The translation of a multicasting construct doesn't differ from the schema shown in figure 3-3b. The semantic difference is realized by using a different kind of "address checknet". In opposite to figure 3-3b not only one remote service is activated, but all those, whose subsystem identification is part of the stringlist. The last part of the figure 3-3d shows the net schema of a broadcasting mechanism. The sde's of the services, whose second part corresponds to the global service identification of the broadcasting construct, are connected with the net the broadcasting construct occurs in. This can be done statically and so no "checknet" is needed, because the sde's are completely known before starting the code production. The special difficulty dealt with by means of checknets arises from the fact that the concrete calls of global activities can depend on the evaluation of
Parameters IN (,.A
~
-
: ge[mall
Address
address chscknet
V. Gruhn, IV~.Hallmann / A Petri-Net Based Compiler for RELOS
parameters. Thereby it can't be done before s t a r t i n g the e x e c u t i o n of the Function Net. T h e r e f o r e any possible c o m m u n i c a t i o n link b e t w e e n global activities has to be established even though it is known that only some of them are a c t u a l l y n e e d e d later on. This mechanism is n e c e s s a r y because of the fact that it is not p o s s i b l e to describe the change of the t o p o l o g y of a Petri Net in the Petri Net itself.
3.3 The Code
c)
a) ACC
Special
Execution
Production
(NAME:STRING x BALANCE:INTEGER) if ~e [ACC.BALANCE, '50'] t h e n 'TRUE' else 'FALSE' fi
are plan
=
b)
Concurrent
all I I
Ifunctdef
Activation
The c o n c u r r e n t e x e c u t i o n of e x p r e s s i o n s is r e a l i z e d by d u p l i c a t i n g the a r r i v i n g control token. In the following figure the i n s t a n c e s a s s o c i a t e d with the services a and b read the duplicates of the control token. A f t e r the instances a and b have fired the following i ns t a n c e can be activated.
~
ST
~1
I
~ /
b[]
FI
Schema
The automatic production of the FN s t a r t i n g w i t h a p a r s i n g tree is a very complex and c o m p l i c a t e d algorithm. In the sequel you will find a short example e x p l a i n i n g the code producing schema. Figure 3-4 shows an a g g r e g a t i o n example and the c o r r e s p o n d i n g parsing tree. Finally d i f f e r e n t steps in the code p r o d u c t i o n process are shown.
Expressions
The special e x e c u t i o n e x p r e s s i o n s u s e d for d e s c r i b i n g the e x e c u t i o n of a global service.
479
lfexpr (1)
boolexpr (21
expr
expr
prlmfunct
¢onst
const
\
I
FI boolcon,t
boolconst
I
I c ortst I
Nondeterministic
Alternative
By c r e a t i n g a conflict situation (that mean s h a v i n g a s i t u a t i o n in which the firing of one instance excludes the firing of another instance) exactly one a[l I b[l
S~
~
FI
ST ~ - ~
FI
of the c o m p e t i n g instances is a c t i v a t e d w h i l e the other one can't fire.
ge
ACC.BALANCE. '50'
] then
"[RUE'
else
'FALSE '
Looking at the p a r s i n g tree the code production starts with searching the expression with the lowest priority. This expression is identified by a parsing o p e r a t o r node, that means a marked node of the p a r s i n g tree. The m a r k i n g is an element of a set containing the most important construct identifications. The p a r s i n g o p e r a t o r node with the lowest p r i o r i t y (marked with (i) in the example) is searched. In detail it is the p a r s i n g operator node with the shortest p a t h to the root (here the node of type "ifexpr"). The code generation for this expression leads to the s i t u a t i o n shown in figure 3-4ci. K n o w i n g that the actual node is an "ifexpr" node the second son is e x a m i n e d (marked with (2)) in order to g e n e r a t e code for the "boolexpr". The
480
%/. Gruhn, M. Hallmann / A Petri-Net BasedCompiler for RELOS
cl)
c2)
code p r o d u c t i o n for this subtree includes the t r e a t m e n t of a "selectexpr" which r e p r e s e n t s the first operand of the built-in function "ae" (greater than). A f t e r h a v i n g g e n e r a t e d code for the "boolexpr" (3-4c2) the 4th (THENexpr) and the 6th (ELSE-expr) son of the "ifexpr" node are dealt with in a similar m a n n e r (3-4c3). In order to deliver exactly one result the two possible results (in this case "TRUE" or "FALSE") are c o l l e c t e d by a concluding instance of the type "MOVE" (34c4). By d e s c r i b i n g the code p r o d u c t i o n algorithm r e c u r s i v e l y the translation of different language constructs can be seen as i n d e p e n d e n t from each other. This enables to improve the t r a n s l a t i o n of c o n s t r u c t s without taking care for side effects.
ACC
TC
4
c3)
¢4)
ACC
ACC
--'~
SELECTC
°)o
IN~~s~LECTC
o;0
Iou
Iou
A
SNAPSHOT
OF
THE
PROVIDED
WORK
Several aspects are very hard to integrate into a language. RELOS is an integrated subject of a prototyping e n v i r o n m e n t for d i s t r i b u t e d a p p l i c a t i o n system development. The prototyping e n v i r o n m e n t PROTOS supports: - graphical description of requirements, - the s i m u l a t i o n of the model described by RELOS, - the e v a l u a t i o n of s i m u l a t i o n results, and - the transformation into the c o r r e s p o n d i n g p r o g r a m p r o g r a m m e d in a language which supports data abstraction. Some of the tools are already implemented. The RELOS compiler, w h i c h is desc r i b e d in the p r e c e d i n g chapter is the central part of the p r o t o t y p i n g environment PROTOS.
co j.,., co
I RELOS- compiler I
?,,
%
. , .... '.'"
I I 'o-''o'' .... ' - ' - " - I
©
Fig.3-4:
D i f f e r e n t Steps Code P r o d u c t i o n
in the
Fig.
4-1:
Cut-out of the P R O T O S - P r o t o typing Environment
V. Gruhn, M. Hallmann / A Petri-Net BasedCompiler for RELOS Other p r a c t i c a l work concern the neti n t e r p r e t e r and the net-analyzer. The net-interpreter enables interactive simulation of the Function Net and produces a trace of the net behaviour and different simulation statistics. The n e t - i n t e r p r e t e r bases on the SIMULA coroutine concept. The analyzer transforms the Function Net into a Petri Net and gives information about deadlock absence, liveness, boundedness, and other diagnostics. The p r o t o t y p i n g approach is c o m p l e t e d with theoretical work concerning a m e t h o d and the d e f i n i t i o n of semantics. The method REMOS is a well-founded procedure giving guidelines to the user for the construction of a prototype. In REMOS the u n d e r l y i n g conceptual model of c o m m u n i c a t i n g subsystems is described. REMOS installs modified transactions (well-known in data bases) in the requirement engineering process. After the designer has built a model of the system the execution of the (not n e c e s s a r i l y completely specified) system can be simulated and evaluated. The model is used as a c o m m u n i c a t i o n object between the designer and the user. The RELOS-compiler presented in this paper bases on a well-defined t h e o r e t i c a l work. The mapping of RELOS onto Function Nets is described formally with a two-level graph grammar [9]. The first level transforms the syntax from BNF into a special attributed abstract syntax tree. The second level maps this tree onto a FN.
5
CONCLUSION
This paper p r e s e n t s the main problems of t r a d i t i o n a l requirement description languages and the special problems of t r a n s l a t i n g a textual d e s c r i p t i o n into a g r a p h i c a l representation. We propose a new approach making a prototyping language operational. The operational semantic of RELOS is d e s c r i b e d by extended timed Petri Nets, called Function Nets. The RELOS language c o n s t r u c t s are m a p p e d onto FN. The FN can be s i m u l a t e d and analyzed by a corresponding net-interpreter. The RELOS-compiler makes the m a p p i n g of RELOS onto FN operational. In this paper the transformation of special RELOS language features are introduced concerning: - message and local resource description, - global and local service description, - unicasting, multicasting and broadcasting, and
- interactive
481
simulation.
The t r a n s l a t i o n of typical applicative concepts (e.g. function application, and deterministic alternative, sequence) and special language concepts (e.g. nondeterministic alternative, non-suspending procedure call, and concurrency) are d i s c u s s e d in detail. Other language features like acknowledgement mechanism, definition of w a i t i n g queues, requirements of time and time consumption, export of services to certain subsystems, and reusability of services cannot be described as a whole in such a short form. The described constructs were chosen in order to give an o v e r v i e w about the code producing schema. By introducing the R E L O S - c o m p i l e r one of the e s s e n t i a l parts of the p r o t o t y p i n g e n v i r o n m e n t PROTOS is explained. We are looking forward to realize the open system structure of PROTOS.
REFERENCES
[i]
[2]
[3]
[4]
[5]
[6]
[7]
M.W. A l f o r d Software Requirements Engineering Methodology (SREM) at the Age of Four P r o c e e d i n g s COMPSAC, 1980 R. Budde, K. Kuhlenkamp, L. Mathiassen, H. ZOllighoven [Eds.] Approaches to Prototyping Springer V e r l a g 1984 Berlin, Heidelberg, New York, Tokyo M. Branstad, S. Squires, M. Zelkowitz [Eds.] Special Issue on Rapid Prototyping A C M SEN, Vol 7, No. 5, Dec. 1982 H.P. G o d b e r s e n Function Nets: A Concept for Modeling to Support the Development process L a d e w i g - V e r l a g (in German) Berlin, 1983 J. Goguen, J. M e s e g u e r Rapid Prototyping in the OBJ executable Specification Language A C M SEN, Vol 7, No. 5, Dec. 1982 N.M. Goldman, D.S. Wile A Relational Data Base Foundation for Process Specifications in : Entity- R e l a t i o n s h i p A p p r o a c h to Systems A n a l y s i s and Design Chert led.] North H o l l a n d 1980 V. Gruhn A Compiler for Requirement Description Language D i p l o m a thesis (in German) U n i v e r s i t y of Dortmund, 1987
V. Gruhn, M. Hal~mann/A Petri-Net Based Compiler for RELOS
482
[8]
M. H a l l m a n n
An Operational Requirement Description Model for Open Systems [9]
10th Int. Conf. on Software Engineering, Singapore, April M. Nagl
Graph-Grammars: Theory, tation, Applications (in German) Vieweg, [i0] J.L. P e t e r s e n
88
Implemen-
1979
Petri Nets Theory and the Modeling of Systems Prentice 1981 [ii] P. Zave
Hall,
E n g l e w o o d Cliffs
,
An Operational Approach to Requirements Specification for Embedded Systems IEEE T r a n s a c t i o n s on Software Engineering Vol. SE-8, No. 3, May 1982 [12] P. Zave, W. Schell
Salient Features of an Executable Specification IEEE T r a n s a c t i o n s on Software Engineering Vol. SE-12, No. 2, Feb. 1986
A
PETRI
NET
BASED
COMPILER
471
FOR
Volker Matthias
THE
PROTOTYPING
LANGUAGE
RELOS
Gruhn Hallmann
U n i v e r s i t y of D o r t m u n d C o m p u t e r Science / S o f t w a r e - T e c h n o l o g y P.O. Box 500 500 D-4600 D o r t m u n d 50 Federal R e p u b l i c of Germany
In this paper we present a compiler for a prototyping language, c a l l e d RELOS. RELOS allows incomplete r e q u i r e m e n t description. From our point of view a p r o t o t y p e is an o p e r a t i o n a l model. The applicative language bases on the conceptual model of a set of subsystems c o m m u n i c a t i n g via m e s s a g e transfer. Special features like concurrency, nondeterminism, multicasting, and a time concept are included in RELOS. The semantic of RELOS is d e f i n e d by extended Petri Nets (called F u n c t i o n Nets or for short FN), w h i c h are a w e l l - f o u n d e d basis enabling analysis and traces. We d e s c r i b e the way how the RELOScompiler works. In detail the m a p p i n g of language constructs onto Function Nets is emphasized. An i n t e r a c t i v e n e t - s i m u l a t o r makes the model operational. Other tools like a c o n s i s t e n c y - c h e c k e r , and a neta n a l y z e r are part of an i n t e g r a t e d p r o t o t y p i n g environment.
1
INTRODUCTION
Requirement e n g i n e e r i n g is a process for the identification of faded requirements for a product. Existing r e q u i r e m e n t d e s c r i p t i o n models are not sufficient for incremental specification of a c o m p l e x target system (e.g. distributed systems, open systems, computer integrated manufacturing, office automation, e m b e d d e d systems, or m u l t i d a t a b a s e systems). Requirement definition is a not yet solved problem in computer science. Functional and n o n f u n c t i o n a l requirements must be d e s c r i b e d in an understandable, modifiable, precise, unambiguous, complete, i n t e r n a l l y consistent and m i n i m a l form. Up to now no solution is p r e s e n t e d to the most urgent problem: how can a user define its ~erhaps not clear but unstructured) r e q u i r e m e n t s in a s t e p w i s e manner? It isn't p o s s i b l e that x users describe the problem in the same breath, because they have x views about the problem. F u r t h e r m o r e the p r o b l e m has to be d e c o m p o s e d into smaller subproblems. R e q u i r e m e n t e n g i n e e r i n g is an incremental e v o l u t i o n a r y process with i t e r a t i n g r e q u i r e m e n t d e f i n i t i o n steps.
A new a p p r o a c h c a l l e d p r o t o t y p i n g has been copied from other engineering science o v e r c o m i n g the p r o b l e m s discussed above. The term p r o t o t y p e is derived from the Greek term prototypos, which stands for model (protos means first and typos means pattern). But the semantic of the term is ambiguous in c o m p u t e r science. The following classification gives an o v e r v i e w about the wide spectrum of p r o t o t y p i n g in the l i t e r a t u r e [3], [2]: - rapid c o n s t r u c t i o n of user interfaces, - c o n c e p t u a l and net-modeling, - formal and o p e r a t i o n a l specification, - high level p r o g r a m m i n g languages, - simulation, - r e u s a b l e software components, - quality a s s u r a n c e methods, as well as - tools and e n v i r o n m e n t s s u p p o r t i n g the software life cycle. For our p u r p o s e we define the term prototype in the following form: "a prototype is an operational model a b s t r a c t i n g details from a real system and h a v i n g the same functional behaviour. The p r o t o t y p e is used as a c o m m u n i c a t i o n object and offers a p o s s i b l y i n c o m p l e t e solution". No a c c e p t e d standard solution exists for the mapping of ideas onto the real system. In this p a p e r we d e s c r i b e the c o m p i l e r of the operational language RELOS. The
V. Gruhn, M. Hal/mann/A Petri-Net Based Compiler for RELOS
472
semantic of RELOS is d e s c r i b e d by extended Petri Nets that will be interpreted by a net-simulator. The compiler consists of a scanner, a parser, a c o n s i s t e n c y - c h e c k e r and a codeproducer. The tools are part of a p r o t o t y p i n g environment, called PROTOS.
2 RELATED RELOS
WORK AND BASIC
FEATURES
quick u n d e r s t a n d i n g of applicative languages. The i n t e r e s t i n g operational and applicative language PAISLey [ii] is o r i e n t e d towards e m b e d d e d systems. The main topic is the c o m m u n i c a t i o n mechan i s m b e t w e e n p r o c e s s e s ("exchange function"). The semantic of PAISLey is d e f i n e d by an interpreter. At this time [12] only a p r o t o t y p e interpreter but no c o n s i s t e n c y - c h e c k e r is available.
OF
2.2 A Short In the last ten years some formal s p e c i f i c a t i o n t e c h n i q u e s and languages have been p r e s e n t e d which pretend to overcome the problem of requirement description and s p e c i f i c a t i o n of complex systems. One of several aspects of a language is the formal semantic definition (interpreter, compiler, algebraic, axiomatic, or denotational semantic).
2.1 A p p r o a c h e s Executable
Making
a
Language
One of the first remarkable process model a p p r o a c h e s for d i s t r i b u t e d system e n g i n e e r i n g is called R S L / R S A p r o p o s e d in the project SREM [i]. Systems are described by a set of objects and corresponding relations b e t w e e n them. A formal foundation is p r e s e n t e d with requirement-networks but the semantic isn't d e s c r i b e d completely. The specification language GIST [6] bases on the d e f i n i t i o n of objects and relations, too. A GIST specification can be executed, because the dynamic properties are the initiation, deletion, insertion and put out of objects and relations in respect to a data base. The s e m a n t i c of the s p e c i f i c a t i o n language OBJ [5] is d e f i n e d axiomatically. An algebraic specification (abstract data type) is executable by a term r e w r i t i n g system. But concurrency, nond e t e r m i n i s m etc. cannot be d e s c r i b e d in OBJ. For the p u r p o s e of p r o t o t y p i n g other languages with applicative concepts are of interest. A p p l i c a t i v e languages are functional languages, but they allow the use of v a r i a b l e s and assignments local to one function. In applicative languages expressions are evaluated without side effects. Expressions are built by constants, formal parameters and function-calls. Because only the value of an e x p r e s s i o n is of interest, this value can be r e p l a c e d by another syntactic expression with the same semantic. The p r i m i t i v e syntax allows
Introduction to RELOS
In our opinion a p r o t o t y p e is a first e x e c u t a b l e model simulating the target system. At this place we give a short o v e r v i e w about the a p p l i c a t i v e language RELOS (REquirement D e s c r i p t i o n ~ a n g u a g e for Q/oen ~ystems) [8] e s p e c i a l l y designed for requirement description and p r o t o t y p i n g b a s e d on simulation. Several language p r o p e r t i e s exist d e d i c a t e d to distributed system specification. The p h i l o s o p h y of RELOS bases on subsystems (SS) which communicate via message passing. Each SS is e x e c u t e d on an abstract p r o c e s s o r offering a set of services (called global services) to other SS. A global service is i n i t i a t e d by r e c e i v i n g a message. A set of local services only known S S - i n t e r n a l l y are u s e d while e x e c u t i n g a global service. The local services manage a set of local resources of a SS. RELOS supports the d e s i g n e r in specifying the application p r o b l e m with: - scenario definition for incomplete requirement description, - message and local resource description (by aggregation, enumeration, list d e f i n i t i o n of basic types etc.), - global and local service definition, called by
V. Gruhn, M. Hallmann / A Petri-Net Based Compiler for R E L OS
subsystem describing some language features (built-in functions are underlined, c o m m e n t s e m b r a c e d by "/*" and "*/", k e y w o r d s w r i t t e n in bold). The global service account[] of the s u b s y s t e m Bank is called by a C u s t o m er sending the message NAME. The Bank m a n a g e s a d a t a - b a s e DB c o n s i s t i n g of a set of accounts ACC. The activated service account[] calls inside its execution plan the local service lookat[]. The result (here ACC.BALANCE) is given back to the calling global service and sent to acc-answer[] of the s u b s y s t e m Customer.
3
H O W THE R E L O S - C O M P I L E R
473
PRODUCES
NETS
A lot of a p p r o a c h e s for the design of distributed systems use net modeling because nets offer a graphical interface. If the refinement of the system design steps into more detail the r e s u l t i n g nets b e c o m e very complex and hard to u n d e r s t a n d for non-experts. In our approach the language is very simple and offers specific constructs for c o m m u n i c a t i o n . F u r t h e r m o r e the prod u c e d nets can be analyzed. The principle way the R E L O S - c o m p i l e r works is
messages NAME :STRING /* two p o s s i b l e message types */ ACCOUNT :INTEGER end s u b s y s t e m Bank global_services account : EVENT x NAME --> EVENT /* d e c l a r a t i o n */ account[NAME] == C u s t o m e r a c c - a n s w e r [ l o o k - a t [ D B , N A M E ] ] /* definition, first calling--local service "look-at" and then sendin the result to the global service "acc-answer" of SS "Customer" */ end local r e s o u r c e s ACC--= (NAME : STRING x /* structure of an account */ B A L A N C E : INTEGER) /* using a g g r e g a t i o n */ DB = list of ACC /* local data base "DB" as a list of accounts */ end local services lookTat : DB x NAME --> A C C . B A L A N C E /* d e c l a r a t i o n */ look-at [DB,NAME] /* d e f i n i t i o n */ if nQ~[emDtv[DB]] then if e a [ h e a d [ D B ] . N A M E , N A M E ] then /* s e l e c t i o n of the first head[DB].BALANCE and t h i r d component */ else look-at[tail[DB],NAME] /* recursion */ fi fi end end = =
Fig.2-1:
The o p e r a t i o n a l s e m a n t i c of RELOS is described by a compiler mapping a RELOS-requirement description onto e x t e n d e d Petri Nets, w h i c h can be simulated by a n e t - i n t e r p r e t e r . Language features like concurrency, n o n d e t e r m i n ism, non-suspending procedure calls, and time c o n c e p t s can be easily described. These features p r o d u c e many problems in other languages. In the following c h a p t e r we d e s c r i b e the w o r k i n g of the R E L O S - c o m p i l e r by some examples.
A RELOS
example
shown in the f o l l o w i n g figure. A f t e r the R E L O S - s c a n n e r has c h e c k e d the RELOS program a stream of tokens is p a s s e d to the RELOS-parser. If no synt a c t i c errors occur the p a r s e r p r o d u c e s a p a r s i n g tree. Before the c o d e - p r o d u cer generates Function Nets a consistency-checker checks the parsing tree against p o s s i b l y w r o n g functionalities and use of d e c l a r e d and defined services and some other kinds of mistakes and i n c o n s i s t e n c i e s .
V. Gruh n, M. Hal/mann/A Petri-Net Based Compiler for R E L OS
474
RELOS-,c ............... i ~
I
I
R~LOS -
(~
Fig.3-1:
3.1
. . . . . . . . . . ~'L__'.'_"_" _ J
,
code-producer
The structure compiler
Underlying
Model:
of
the
Function
RELOS-
Nets
P e t r i N e t s [I0] h a v e b e e n increasingly u s e d for t h e d e s c r i p t i o n of s t a t i c and d y n a m i c s t r u c t u r e s in t h e r e c e n t y e a r s . T h e i r a d v a n t a g e s are t h e well-defined, mathematical foundation, ans t h e graphical representation. Petri Nets can be analyzed automatically (deadlock occurrence, liveness, etc.) a n d that c o n c u r r e n c y can b e d e s c r i b e d n a t u r a l l y . Function N e t s are e x t e n d e d P e t r i Nets [4]. The e x t e n s i o n s c o n c e r n t h e f o l l o wing points: - m o d i f i c a t i o n of t h e f i r i n g rule, distinction between message and cont r o l flow, - distinction between different kinds of m e s s a g e flow, u s e of d i f f e r e n t m e s s a g e t y p e s associated with the tokens, use of a time concept, - concepts for m o d e l i n g u s e r interactions - s c h e d u l i n g c o n c e p t s for c h a n n e l s c o n t a i n i n g a set of t o k e n s , - application of a set of functions associated with the agencies. -
i) B e t r i N e t C ~ A = 0, T ~] S = Z T C_ C x A, S C A x C d o m (T U S) = C, i m a g (T U S) = A A : set of a g e n c i e s ( t r a n s i t i o n or i n s t a n c e ) , C : set o f c h a n n e l s (place), T : target relation and S : source relation 2 ) Aoency A = {al , a 2 , . . . , a n } w h e r e ai (Job x C o n s u m e ) , i = i, ...,n w h e r e J o b = {Jl, J2, .-., Jm} (identification of associated program) where Ji 6 (NAME x Fire) , i = 1 ..... m (name a n d k i n d of f i r i n g rule) w h e re Fire = {ALL, SOME_IN, SOME_OUT, SOME } C o n s u m e = N 0\{o~} (time-consume) 3) C h a n n e l C = {ci, c2, ..., c k } w h e r e ci 6 (Acc x Cap) , i = i, ...,k where A c c = {FIFO, L I F O } (kind of access) Cap = N O (capacity) 4) F l o w r e l a t i Q n T = {tl, t2. ..., t I } w h e r e ti 6 (C x A x Inkind) , i = 1 .... ,i where I n k i n d = {IN, CO, ST} (input r e l a t i o n ) S = {sl, s2, ..., Sp} w h e r e s i [ (C x A x O u t k i n d ) , i = l,...,p where O u t k i n d = {OU, FI} {output r e l a t i o n ) 5) M a r k i n q M : C --> T O K E N (initial m a r k i n g ) T O K E N = set of A S C I I - s t r i n g s x T Y P E TYPE = {REAL, S T R I N G , B O O L E A N }
-
Function N e t s c o n s i s t of t w o disjunct sets of nodes, called agencies and channels (corresponding with transitions a n d p l a c e s in t r a d i t i o n a l Petri Nets), w h i c h are c o n n e c t e d b y d i r e c t e d arcs. In t h e s e q u e l a d e d i c a t e d v e r s i o n o f t h e o r i g i n a l F u n c t i o n N e t c o n c e p t is introduced. A complete definition of the original concept can be found in [4]. A F u n c t i o n N e t is a 5 - t u p e l F N = (A,C,T,S,M) d e f i n e d as f o l l o w s :
In i) t h e P e t r i N e t s t r u c t u r e is defined. 2) d e f i n e s t h e s t r u c t u r e of a g e n cies. The definition shows that an agency represents a time-consuming activity. The kind of the activity a s s o c i a t e d w i t h t h e a g e n c y is d e s c r i b e d by the Job-component. T h e v a l u e of t h e Job-component is t h e n a m e of a small p r o g r a m (e.g. a r i t h m e t i c , b o o l e a n , list o p e r a t i o n s etc.), w h i c h w i l l be e x e c u ted when the agency fires. The job associated with an agency processes messages. I n p u t m e s s a g e s are t a k e n as p a r a m e t e r s a n d one or m o r e o u t p u t messages are p r o d u c e d . The third point describes the channel structure. Messages are s t o r e d in w a i t i n g q u e u e s . T h e s e q u e u e s c a n b e a c c e s s e d in a L I F O - or a FIFO-strategy. The maximal length of
V. Gruhn, 114.Hallmann / A Petri-Net Based Compiler for RELOS
w a i t i n g queues is d e t e r m i n e d by fixing the capacity of the channels. The fourth point d e s c r i b e s the token flow. The token flow characterizes the sy s t e m ' s d y n a m i c behaviour. The flow of tokens is d e t e r m i n e d by the firing of agencies under certain well-defined conditions and in d e p e n d e n c y on the token values in the input channels at firing time. In c o m p a r i s o n to t r a d i t i o nal Petri Net models the firing rule is extended. The Fire-component of an agency d e s c r i p t i o n can define the following kinds of firing: ALL
SOME
IN
SOME OUT
SOME
t r a d i t i o n a l firing rule, that means reading tokens from all input channels and writing into all output channels, reading tokens from some input channels, w r i t i n g into all output channels, reading tokens f r o m all input channels, w r i t i n g into some output channels, reading tokens from some input channels, w r i t i n g into some output channels
The flow r e l a t i o n can be - as i n d i c a t e d in 5) - s u b d i v i d e d into different classes of arcs. Their m e a n i n g s are: IN d e s t r u c t i v e reading, that means a message token is read and removed from the channel, CO copy reading, that means a m e s s a g e token is read, ST the token is c o n s i d e r e d as a control token, that means the value is of no importance; the message is removed, OU w r i t i n g a m e s s a g e token into output channels, FI a control token is w r i t t e n into the output channel. Apparently there is a d i f f e r e n c e between any kind of t y p e d m e s s a g e on the one and control tokens on the other hand. The d i f f e r e n c e is realized by connecting c h a n n e l s via special arcs. By r e a d i n g via an ST-arc or by writing via an FI-arc a message becomes a control token. In F u n c t i o n Nets the execution of an activity associated with an agency can consume time. The execution time is described in the TIME-component of the agency description. The e x t e n s i o n s c o n c e r n i n g the separation of m e s s a g e and control flow, the modified firing rules, and the time concept do not affect the properties of Petri Nets, b e c a u s e the o c c u r r e n c e s of these e x t e n s i o n s can be r e p l a c e d by so c a l l e d basis Petri Nets [4] or by subnets w h i c h do not i n c o r p o r a t e these extensions. The use of these e x t e n s i o n s
475
only p r o v i d e s a h i g h e r level of comfortability. The i n i t i a l i z a t i o n is d e f i n e d by the function M d e s c r i b e d in 5). The type and the v a l u e of the token must be given in order to define a correct channel initialization. A channel can be i n i t i a l i z e d by one or more tokens. In the f o l l o w i n g a g r a p h i c a l represent a t i o n of a very simple FN i n c l u d i n g an instance a s s o c i a t e d with the a r i t h m e t i c job "ADD" is presented. Two input channels of the A D D - a g e n c y are connected via "CO"-arcs, and the third input channel is read via an "IN"-channel. A f t e r firing the instance the result of the a d d i t i o n can be found in the output channels.
A c o m p l e t e set of a v a i l a b l e jobs can be found in a library [7]. The library can be e x t e n d e d if special jobs are needed. 3.2 RELOS Language Transformation
Concepts
and
their
This chapter starts with the description of very general language constructs w h i c h will be found in every language. S p e c i f i c c o m m u n i c a t i o n facilities are especially emphasized b e c a u s e they are R E L O S - s p e c i f i c . Their t r a n s l a t i o n shows d i f f i c u l t i e s arising when the complete t o p o l o g y of the produced net depends on results being d e l i v e r e d by the s i m u l a t i o n of parts of the p r o d u c e d net. F u r t h e r o n we d e s c r i b e the t r a n s l a t i o n of execution expressions used by global services.
a) General
Language
Constructs
Application Three d i f f e r e n t kinds of service applications will be d i s t i n g u i s h e d : the calling of a service or a b u i l t - i n function with (a) and without included parameters (b). Furthermore applications can occur in the p a r a m e t e r list of other applications. The following figure shows these three kinds of applications. In (c) the services a and b are a c t i v a t e d concurrently.
a[]
sT o
V. Gruhn, M. Hal/mann/A Petri-Net Based Compiler for RELOS
476
PAR1 a[PAR1. PAR2]
I
~
PAR2
SC:
SELECT-COMPONENT ~ y ' C O
b)
Intersubsystem
Communication
ST PO [ ~ [ / ~ 1 N Global
c[a[], b[]]
ST ~
if-then-else-fi The result of the d e t e r m i n i s t i c alternative depends on the e v a l u a t i o n of the first expression (execution of the function a). Either the result of the execution of the then-expression (execution of b) or the result of the evaluation of the else-expression (execution of c) is delivered. In order to g u a r a n t e e that exactly one of the results is p r o v i d e d to the following instances a c o l l e c t i n g channel is used, which is filled either by the last instance of the net c o r r e s p o n d i n g with the t h e n - e x p r e s s i o n or with the last expression of the net corresponding with the e l s e - e x p r e s s i o n . In the following figure the t r a n s l a t i o n of an ife x p r e s s i o n is shown. if a{]
then
ST
b[]
else
OH
Services
Global services are o f f e r e d by a subs y s t e m to other subsystems. They can be seen as an entry point used for communication. For every global service described in the r e q u i r e m e n t document a so-called service d e s c r i p t i o n element (sde) is c r e a t e d at the beginning of code p r o d u c t i o n . An sde comprises the complete name of the service (that means a name of the form
S1_ I 81
S2
c[] fi
IN
FI / ~
It is worth to point out that the firing b e h a v i o u r SOME OUT is n e e d e d for the t r a n s l a t i o n of an--ifexpr. In the FN given above the IF-agency p r o v i d e s the SOME O U T - b e h a v i o u r in order to guarantee ~hat e x a c t l y one of the subnets is activated.
Selection By u s i n g a " s e l e c t - e x p r e s s i o n " a component of an a g g r e g a t e d object can be selected. In the following figure a c o m p o n e n t w i t h the name "X" is s e l e c t e d from the object d e l i v e r e d by the activation of a. A s s u m e d that "X" is the name of the s e c o n d component of the result of a, the following figure r e p r e s e n t s the p r o d u c e d net. The position of "X" is read from the second input channel. This channel is connected by a "CO"-arc in order to provide the p o s i t i o n again at any a c t i v a t i o n of the agency.
~_~[-~ [_~
ou
Casting
IN
OU
Mechanisms
Some special c o m m u n i c a t i o n constructs dedicated to describe distributed systems exist in RELOS. This c o m m u n i c a tion facilities are described by c a s t i n g mechanisms. These casting constructs are used for the communication between global services of different subsystems. The principal difference between global and local services is that a global service doesn't receive a result after a c t i v a t i n g another global service ("non-suspending-procedurecall"). In opposite to this a local service returns a result. The calling global service only initiates another global service by sending a message, but it doesn't control its execution. We d i s t i n g u i s h three different kinds of c a s t i n g mechanism: - u n i c a s t i n g (I:I communication), - m u l t i c a s t i n g (l:n communication), and - b r o a d c a s t i n g (l:all communication)
V. Gruhn, M. Hal~mann/A Petri-Net Based Compiler for RELOS
The f i r s t p a r t of f i g u r e 3-2 s h o w s the u s e of t h e s e c a s t i n g constructs. Unicasting describes the activation of e x a c t l y one r e m o t e s e r v i c e . T h e a d d r e s s of this remote service can be given explicitly (3-2a) or its f i r s t p a r t c a n b e t h e v a l u e of a m e s s a g e (3-2b) . The m e s s a g e s o f an a c t i v a t i o n are p a s s e d to the sde of the addressed service. Multicasting is s y n t a c t i c a l l y similar to unicasting with implicit address. The d i f f e r e n c e is t h a t t h e f i r s t part of the called SS-name consists of a n a m e of a s t r i n g l i s t (3-2c) i n s t e a d of a n a m e of a s t r i n g . T h i s m e a n s t h a t all s t r i n g s i n c l u d e d in t h e s t r i n g l i s t are substituted for t h e list n a m e s t e p by step. T h i s m e a n s t h a t all t h o s e s e r v i ces are a c t i v a t e d , whose names consist of a s t r i n g w h i c h is p a r t of t h e given stringlist and the explicitly named s e c o n d p a r t of t h e s e r v i c e name. Broadcasting differs from the unicasting construct in t h e w a y that the s u b s y s t e m i d e n t i f i c a t i o n is r e p l a c e d b y "ALL". T h i s s h o w s t h a t all t h o s e g l o b a l services, whose second part corresponds with t h e s e c o n d p a r t of the broadcas t i n g c o n s t r u c t , are a c t i v a t e d (3-2d).
477
activating service. In f i g u r e 3 - 3 b t h e translation of a u n i c a s t i n g construct with implicitly given addressee is described. In o r d e r to a s s u r e to r e a c h t h e r i g h t a d d r e s s e e all p o s s i b l y c a l l e d services, r e s p e c t i v e l y t h e i r nets, are connected. The "address checknet" guarantees that only the really called s e r v i c e is a c t i v a t e d . That means that those services, whose names differ from the name which results from the p a r a m e t e r e v a l u a t i o n are s u p p r e s s e d at s i m u l a t i o n time.
Context: PARTNER = ('SITEA','SITEB','SITEC') /* e n u m e r a t i o n type M A I L S I T E S = ii$% Qf S T R I N G d e f a u l t [ M A I L S I T E S ] = ('SITEA', 'SITEB', ' S I T E C ' ) ; /* i n i t i a l i z a t i o n of MAILSITES SITEA, SITEB, SITEC, S I T E D are n a m e s of s u b s y s t e m s . (a) U n i c a s t i n g w i t h e x p l i c i t l y g i v e n S S - a d d r e s s s e n d m a i l : E V E N T x M A I L --> E V E N T s e n d m a i l [MAIL] == S I T E B _ g e t m a i l [MAIL] (b) U n i c a s t i n g w i t h i m p l i c i t l y g i v e n S S - a d d r e s s s e n d m a i l : E V E N T x P A R T N E R x M A I L --> E V E N T s e n d m a i l [MAIL x P A R T N E R ] == " P A R T N E R " _ g e t m a i l
[MAIL]
(c) M u l t i c a s t i n g sendmail sendmail
( s e n d i n g to f i x e d set of a d d r e s s e s ) : E V E N T x M A I L S I T E S x M A I L --> E V E N T [MAIL x M A I L S I T E S ] == f o r M A I L S I T E S _ g e t m a i l
(d) B r o a d c a s t i n g sendmail sendmail
: E V E N T x M A I L --> E V E N T [MAIL] == f o r A L L g e t m a i l
Fig.3-2:
The U s e
of t h e D i f f e r e n t
The m a i n p r o b l e m of t h e t r a n s l a t i o n of c a s t i n g m e c h a n i s m s i n t o F N is t h a t the structure of t h e F N isn't previously known. So we have to introduce so called "checknets" (see f i g u r e 3-3). In figure 3-3a the schema for the a c t i v a t i o n of one e x p l i c i t l y addressed r e m o t e s e r v i c e is shown. The sde of t h e called service is c o n n e c t e d with an instance of the schematically shown Function Net of the callinq or
[MAIL] Casting
Constructs
[MAIL]
*/
478
V. Gruhn, M. Hallmann / A Petri-Net BasedCompiler for RELOS
a) Unlcastlng with explicit address
SlteA-
SlteB-
SlteC- IslteO-
Sited -
Sub i
rma ead~
b) UnlcasUng with Implicit address
-
--~ ~'[
SlteB-
- SIteD." getma
address checknet
]"
address checknet
]"
address checknet
I J
I
Sub1_ sendma
SiteDreadmall
],
I
checking of the address during the simulation
c) Multlcastlng Same net structure as In b), but with a different kind of address ichecknet, whtchenables the activation of more than one service. d) Broadcasting
$1teA'
~ SiteS-
SiteC-
~ SiteD-
getmal
getma
getma
getma
~
~
~
Sub1
SiteD-
send~ ma
readma
~
~
Fig.3-3: The Translation of the Different Casting Mechanisms In order to illustrate the reason for using checknets we give a short
At first the parameter containing the implicite address is duplicated. The number of duplicates is as big as the number of subsystems providing the demanded service. One of these duplicates and a copy of the set of parameters is passed to the checknet. Afterwards the "address checknets" evaluate the parameter containing the address of the subsytem. The result of this evaluation is compared with the names of all those subsystems providing the demanded service. Each checknet is responsible for the comparison with exactly one subsystem name. The above given checknet compares the parameter value with the subsystem name "SITEA". If this comparison is successful the parameters are passed to the actually addressed subsystem. Otherwise nothing is done. This behaviour is realized by the job "TRUE?" If the input of the agency associated with this job has the value "TRUE" a control token is produced, otherwise nothing happens (that means that this agency fires according to the firing rule "SOME OUT"). The other subsystems (that mea~s those which are not addressed by the parameter value) are not activated. The translation of a multicasting construct doesn't differ from the schema shown in figure 3-3b. The semantic difference is realized by using a different kind of "address checknet". In opposite to figure 3-3b not only one remote service is activated, but all those, whose subsystem identification is part of the stringlist. The last part of the figure 3-3d shows the net schema of a broadcasting mechanism. The sde's of the services, whose second part corresponds to the global service identification of the broadcasting construct, are connected with the net the broadcasting construct occurs in. This can be done statically and so no "checknet" is needed, because the sde's are completely known before starting the code production. The special difficulty dealt with by means of checknets arises from the fact that the concrete calls of global activities can depend on the evaluation of
Parameters IN (,.A
~
-
: ge[mall
Address
address chscknet
V. Gruhn, IV~.Hallmann / A Petri-Net Based Compiler for RELOS
parameters. Thereby it can't be done before s t a r t i n g the e x e c u t i o n of the Function Net. T h e r e f o r e any possible c o m m u n i c a t i o n link b e t w e e n global activities has to be established even though it is known that only some of them are a c t u a l l y n e e d e d later on. This mechanism is n e c e s s a r y because of the fact that it is not p o s s i b l e to describe the change of the t o p o l o g y of a Petri Net in the Petri Net itself.
3.3 The Code
c)
a) ACC
Special
Execution
Production
(NAME:STRING x BALANCE:INTEGER) if ~e [ACC.BALANCE, '50'] t h e n 'TRUE' else 'FALSE' fi
are plan
=
b)
Concurrent
all I I
Ifunctdef
Activation
The c o n c u r r e n t e x e c u t i o n of e x p r e s s i o n s is r e a l i z e d by d u p l i c a t i n g the a r r i v i n g control token. In the following figure the i n s t a n c e s a s s o c i a t e d with the services a and b read the duplicates of the control token. A f t e r the instances a and b have fired the following i ns t a n c e can be activated.
~
ST
~1
I
~ /
b[]
FI
Schema
The automatic production of the FN s t a r t i n g w i t h a p a r s i n g tree is a very complex and c o m p l i c a t e d algorithm. In the sequel you will find a short example e x p l a i n i n g the code producing schema. Figure 3-4 shows an a g g r e g a t i o n example and the c o r r e s p o n d i n g parsing tree. Finally d i f f e r e n t steps in the code p r o d u c t i o n process are shown.
Expressions
The special e x e c u t i o n e x p r e s s i o n s u s e d for d e s c r i b i n g the e x e c u t i o n of a global service.
479
lfexpr (1)
boolexpr (21
expr
expr
prlmfunct
¢onst
const
\
I
FI boolcon,t
boolconst
I
I c ortst I
Nondeterministic
Alternative
By c r e a t i n g a conflict situation (that mean s h a v i n g a s i t u a t i o n in which the firing of one instance excludes the firing of another instance) exactly one a[l I b[l
S~
~
FI
ST ~ - ~
FI
of the c o m p e t i n g instances is a c t i v a t e d w h i l e the other one can't fire.
ge
ACC.BALANCE. '50'
] then
"[RUE'
else
'FALSE '
Looking at the p a r s i n g tree the code production starts with searching the expression with the lowest priority. This expression is identified by a parsing o p e r a t o r node, that means a marked node of the p a r s i n g tree. The m a r k i n g is an element of a set containing the most important construct identifications. The p a r s i n g o p e r a t o r node with the lowest p r i o r i t y (marked with (i) in the example) is searched. In detail it is the p a r s i n g operator node with the shortest p a t h to the root (here the node of type "ifexpr"). The code generation for this expression leads to the s i t u a t i o n shown in figure 3-4ci. K n o w i n g that the actual node is an "ifexpr" node the second son is e x a m i n e d (marked with (2)) in order to g e n e r a t e code for the "boolexpr". The
480
%/. Gruhn, M. Hallmann / A Petri-Net BasedCompiler for RELOS
cl)
c2)
code p r o d u c t i o n for this subtree includes the t r e a t m e n t of a "selectexpr" which r e p r e s e n t s the first operand of the built-in function "ae" (greater than). A f t e r h a v i n g g e n e r a t e d code for the "boolexpr" (3-4c2) the 4th (THENexpr) and the 6th (ELSE-expr) son of the "ifexpr" node are dealt with in a similar m a n n e r (3-4c3). In order to deliver exactly one result the two possible results (in this case "TRUE" or "FALSE") are c o l l e c t e d by a concluding instance of the type "MOVE" (34c4). By d e s c r i b i n g the code p r o d u c t i o n algorithm r e c u r s i v e l y the translation of different language constructs can be seen as i n d e p e n d e n t from each other. This enables to improve the t r a n s l a t i o n of c o n s t r u c t s without taking care for side effects.
ACC
TC
4
c3)
¢4)
ACC
ACC
--'~
SELECTC
°)o
IN~~s~LECTC
o;0
Iou
Iou
A
SNAPSHOT
OF
THE
PROVIDED
WORK
Several aspects are very hard to integrate into a language. RELOS is an integrated subject of a prototyping e n v i r o n m e n t for d i s t r i b u t e d a p p l i c a t i o n system development. The prototyping e n v i r o n m e n t PROTOS supports: - graphical description of requirements, - the s i m u l a t i o n of the model described by RELOS, - the e v a l u a t i o n of s i m u l a t i o n results, and - the transformation into the c o r r e s p o n d i n g p r o g r a m p r o g r a m m e d in a language which supports data abstraction. Some of the tools are already implemented. The RELOS compiler, w h i c h is desc r i b e d in the p r e c e d i n g chapter is the central part of the p r o t o t y p i n g environment PROTOS.
co j.,., co
I RELOS- compiler I
?,,
%
. , .... '.'"
I I 'o-''o'' .... ' - ' - " - I
©
Fig.3-4:
D i f f e r e n t Steps Code P r o d u c t i o n
in the
Fig.
4-1:
Cut-out of the P R O T O S - P r o t o typing Environment
V. Gruhn, M. Hallmann / A Petri-Net BasedCompiler for RELOS Other p r a c t i c a l work concern the neti n t e r p r e t e r and the net-analyzer. The net-interpreter enables interactive simulation of the Function Net and produces a trace of the net behaviour and different simulation statistics. The n e t - i n t e r p r e t e r bases on the SIMULA coroutine concept. The analyzer transforms the Function Net into a Petri Net and gives information about deadlock absence, liveness, boundedness, and other diagnostics. The p r o t o t y p i n g approach is c o m p l e t e d with theoretical work concerning a m e t h o d and the d e f i n i t i o n of semantics. The method REMOS is a well-founded procedure giving guidelines to the user for the construction of a prototype. In REMOS the u n d e r l y i n g conceptual model of c o m m u n i c a t i n g subsystems is described. REMOS installs modified transactions (well-known in data bases) in the requirement engineering process. After the designer has built a model of the system the execution of the (not n e c e s s a r i l y completely specified) system can be simulated and evaluated. The model is used as a c o m m u n i c a t i o n object between the designer and the user. The RELOS-compiler presented in this paper bases on a well-defined t h e o r e t i c a l work. The mapping of RELOS onto Function Nets is described formally with a two-level graph grammar [9]. The first level transforms the syntax from BNF into a special attributed abstract syntax tree. The second level maps this tree onto a FN.
5
CONCLUSION
This paper p r e s e n t s the main problems of t r a d i t i o n a l requirement description languages and the special problems of t r a n s l a t i n g a textual d e s c r i p t i o n into a g r a p h i c a l representation. We propose a new approach making a prototyping language operational. The operational semantic of RELOS is d e s c r i b e d by extended timed Petri Nets, called Function Nets. The RELOS language c o n s t r u c t s are m a p p e d onto FN. The FN can be s i m u l a t e d and analyzed by a corresponding net-interpreter. The RELOS-compiler makes the m a p p i n g of RELOS onto FN operational. In this paper the transformation of special RELOS language features are introduced concerning: - message and local resource description, - global and local service description, - unicasting, multicasting and broadcasting, and
- interactive
481
simulation.
The t r a n s l a t i o n of typical applicative concepts (e.g. function application, and deterministic alternative, sequence) and special language concepts (e.g. nondeterministic alternative, non-suspending procedure call, and concurrency) are d i s c u s s e d in detail. Other language features like acknowledgement mechanism, definition of w a i t i n g queues, requirements of time and time consumption, export of services to certain subsystems, and reusability of services cannot be described as a whole in such a short form. The described constructs were chosen in order to give an o v e r v i e w about the code producing schema. By introducing the R E L O S - c o m p i l e r one of the e s s e n t i a l parts of the p r o t o t y p i n g e n v i r o n m e n t PROTOS is explained. We are looking forward to realize the open system structure of PROTOS.
REFERENCES
[i]
[2]
[3]
[4]
[5]
[6]
[7]
M.W. A l f o r d Software Requirements Engineering Methodology (SREM) at the Age of Four P r o c e e d i n g s COMPSAC, 1980 R. Budde, K. Kuhlenkamp, L. Mathiassen, H. ZOllighoven [Eds.] Approaches to Prototyping Springer V e r l a g 1984 Berlin, Heidelberg, New York, Tokyo M. Branstad, S. Squires, M. Zelkowitz [Eds.] Special Issue on Rapid Prototyping A C M SEN, Vol 7, No. 5, Dec. 1982 H.P. G o d b e r s e n Function Nets: A Concept for Modeling to Support the Development process L a d e w i g - V e r l a g (in German) Berlin, 1983 J. Goguen, J. M e s e g u e r Rapid Prototyping in the OBJ executable Specification Language A C M SEN, Vol 7, No. 5, Dec. 1982 N.M. Goldman, D.S. Wile A Relational Data Base Foundation for Process Specifications in : Entity- R e l a t i o n s h i p A p p r o a c h to Systems A n a l y s i s and Design Chert led.] North H o l l a n d 1980 V. Gruhn A Compiler for Requirement Description Language D i p l o m a thesis (in German) U n i v e r s i t y of Dortmund, 1987
V. Gruhn, M. Hal~mann/A Petri-Net Based Compiler for RELOS
482
[8]
M. H a l l m a n n
An Operational Requirement Description Model for Open Systems [9]
10th Int. Conf. on Software Engineering, Singapore, April M. Nagl
Graph-Grammars: Theory, tation, Applications (in German) Vieweg, [i0] J.L. P e t e r s e n
88
Implemen-
1979
Petri Nets Theory and the Modeling of Systems Prentice 1981 [ii] P. Zave
Hall,
E n g l e w o o d Cliffs
,
An Operational Approach to Requirements Specification for Embedded Systems IEEE T r a n s a c t i o n s on Software Engineering Vol. SE-8, No. 3, May 1982 [12] P. Zave, W. Schell
Salient Features of an Executable Specification IEEE T r a n s a c t i o n s on Software Engineering Vol. SE-12, No. 2, Feb. 1986