4

Click here to load reader

[IEEE Canadian Conference on Electrical and Computer Engineering, 2005. - Saskatoon, SK, Canada (May 1-4, 2005)] Canadian Conference on Electrical and Computer Engineering, 2005. -

  • Upload
    tranque

  • View
    212

  • Download
    0

Embed Size (px)

Citation preview

Page 1: [IEEE Canadian Conference on Electrical and Computer Engineering, 2005. - Saskatoon, SK, Canada (May 1-4, 2005)] Canadian Conference on Electrical and Computer Engineering, 2005. -

AN OPERATIONAL SEMANTICS FOR RTPA

Cyprian F. Ngolah and Yingxu Wang

Theoretical and Empirical Software Engineering Research Center Department of Electrical and Computer Engineering

University of Calgary 2500 University Drive NW, Calgary, AB, Canada T2N 1N4

Email: {ncfoinjo, yingxu}@ucalgary.ca

Abstract A formal specification methodology that describes the

behaviors of a real-time system must have a means to verify the specification before software is implemented from it. Developing a verifier for a formal specification language demands an operational semantics for the language. If the syntactic constructs of the language involve variables, its operational semantics is more difficult to define since the environment must also show the association of variables and the values to which they are assigned.

This paper presents the operational semantics of Real-Time Process Algebra (RTPA). RTPA describes a software system’s behavior using a combination of meta-processes and process relations. Based on the meta-processes and process relations, the operational semantics of RTPA is presented, which shows how syntactic constructs can be reduced to values using inference rules. The operational semantics for RTPA will serve as a basis for the verifier and checker for RTPA specifications.

Keywords: Real-time process algebra, operational semantics, reduction machine, software engineering, real-time systems.

1. Introduction A methodology used for the design and specification of

complex software systems such as real-time systems requires a basis for the verification of the specification [1]. For such systems, safety and reliability are of prime importance and it is necessary to guarantee that the developed system will provide the required functionality. A language used in the specification and design of real-time systems requires an operational semantics that describes how any particular program in the language is interpreted as sequences of computational logics. Based on the operational semantics, a verifier or proof system can be developed, which can be used to verify specifications for semantic correctness. However, an operational semantics for a language in which its syntactic constructs involve variables is not easy to define since such a definition must include the concept of an environment that shows the association of variables and the values to which they are assigned [2].

One way to define an operational semantics for a language is to provide a state transition system for the language, which allows a formal analysis of the language, permitting the study of relations between programs [3]. An alternative way is to describe the operations of the language on a hypothetical machine whose operations are precisely defined [4]. Common hypothetical machines include SECD (Stack, Environment, Control, Dump), VDL (Vienna Definition Language), a Turing Machine, and a Reduction machine.

A reduction machine is an abstract machine that defines inference rules for repetitively simplifying language constructs until a result is obtained. It thus simulates the behaviors of an actual computer and is easily understood by the user. A reduction machine used to define the operational semantics of a specification language has three components: specification, control and store. An operational semantics describes how the control of the machine reduces a given specification to values of variables and how the memory is changed during the execution of the specification. For languages with expressions involving variables, two semantic functions that map identifiers to memory locations and memory locations to values are defined as shown in (1), where Env denotes an environment and S the store.

Env:Identifier location S:location value (1)

Given a particular expression in which variables are involved, the composite function S(Env(Identifier)) is used to obtain the corresponding value for that expression when it is executed by the machine.

In this paper, the operational semantics of RTPA is defined using a reduction machine, which defines inference rules for repetitively simplifying RTPA specifications until a result is obtained. RTPA is a formal specification language used for describing the behaviors of real-time software systems [5-6,9]. Section 2 briefly describes the syntax for RTPA. Section 3 describes the operational semantics of RTPA using a reduction machine while Section 4 gives the conclusions and future work.

0-7803-8886-0/05/$20.00 ©2005 IEEECCECE/CCGEI, Saskatoon, May 2005

1823

Page 2: [IEEE Canadian Conference on Electrical and Computer Engineering, 2005. - Saskatoon, SK, Canada (May 1-4, 2005)] Canadian Conference on Electrical and Computer Engineering, 2005. -

2. The Abstract Syntax of RTPA RTPA has 16 meta-processes and 16 process relations.

Meta-processes in RTPA are the building blocks for more complicated processes while process relations are combinatory rules used to combine meta-processes to form more complex processes. The syntax and deductive semantics [9] of RTPA have been defined using the EBNF grammar [8,9].

Fig. 1 shows an RTPA syntax for the meta-processes and process relations. The syntax shows how each of the constructs is represented in an RTPA specification. The informal description of some of the meta-processes and process relations is given in Section 3 alongside their operational semantics.

Meta-Process Process Relation Name Syntax Name Syntax

System §(SysIDS) Sequence P → Q Assignment yType := xType Branch (?expBL = T) → P

| (?~) → Q where ‘~’ means ‘expBL = F’

Addressing

PtrP ̂:= xType Switch ?expType =0 → P0

| 1 → P1 | … | n-1 → Pn-1

| else → ∅where expType = {N, B , S}

Input

Port(ptrP )̂Type | xType For-do R

n

i 1= (P(i))

Output xType | Port(ptrP )̂Type Repeat R

TexpBL

1

=

≥ (P)

Read Mem(ptrP )̂Type xType While-do F

exprBL TR

=(P)

Write xType Mem(ptrP )̂Type Function call P FTiming

a) @thh:mm:ss:ms := §thh:mm:ss:ms b) @tyy:MM:dd := §tyy:MM:dd c) @tyy:MM:dd:hh:mm:ss:ms := §tyy:MM:dd:hh:mm:ss:ms

Recursion P P

Duration @tnN := §tnN + ∆nN Parallel P || Q Memory allocation

AllocateObject (ObjectIDS ,NofElementsN ,ElementTypeRT)

Concurrence P Q

Memory release

ReleaseObject (ObjectIDS) Interleave P ||| Q

Increase ↑(nType) Pipeline P » Q Decrease ↓(nType) Time-driven

dispatch @tihh:mm:ss:ms Pi, i ∈{1..n}

Exception detecting

! (@eS) Event-driven dispatch

@eiS Pi , i ∈{1..n}

Skip ∅ Interrupt P || (@eS Q Stop Jump P Q

Fig. 1. The RTPA Notation System

RTPA is a specification language in which variables are involved. For example, the assignment process (y := x) when executed causes the variable y to be replaced by the value of x.Consequently, the definition of an operational semantics for RTPA must include the concept of an environment that shows the association of variables and the values to which they are assigned. This is necessary so as to avoid side-effects that usually occur due to changes in the environment.

3. Operational Semantics for RTPA

Formally, an operational semantics for a language is a mathematical definition of its computation relation, e v, where e is a program in the language and e v is a binary relation between expressions of the language e, and values of the language, v. In this definition e and v are meta-variables denoting an arbitrary expression and value respectively. Our intention is to show the necessary steps that an RTPA specification takes to transit from e to v. The operational semantics for RTPA are defined by describing the operational semantics of both meta-processes and process relations.

3.1. Notational Conventions

To define the operational semantics of RTPA, we adopt the following notational conventions.

a) <E|Env> <E’|Env’>: Expression E is evaluated in an environment Env to value E’ in a new environment Env’. In each case, Env’ will be derived based on the composition of Env. If the expression E contains variables, the value of E’ is derived using equation E’ = S(Env(E)) from mapping relation shown in rule (1).

b) premiseconclusion [ ]condition : This represents an inference rule

in which a conclusion is drawn whenever premise is true. Sometimes there is a condition attached to premise.

c) [x/y]: Indicates that value of variable x replaces the value of variable y in the store (memory).

d) Type(x): Returns the meta-type of variable x.e) RT(x): Returns the meta-type of variable x at run-time f) P ⎯→⎯t P’: P executes to P’ after t units of time

3.2. Operational Semantics of RTPA Meta- Processes

Using the reduction machine defined in Section 1 and the notational conventions, the operational semantics for meta-processes of RTPA are given. In this paper, we present the operational semantics of three meta-processes – assignment, timing and duration processes. The operational semantics of the rest of 13 meta-processes are similarly defined.

i) The Assignment Process: yRT := xRT

RTPA allows a variable in a different process to be assigned to a variable in another process. Consequently, the environments for the variables may be different. However, their types must be the same at run-time for the process to be executed. For the assignment process, the resulting environment when x is assigned to y is the union of the environments of x and y. The operational semantics for the assignment statement is shown in (2).

1824

Page 3: [IEEE Canadian Conference on Electrical and Computer Engineering, 2005. - Saskatoon, SK, Canada (May 1-4, 2005)] Canadian Conference on Electrical and Computer Engineering, 2005. -

y x y x

RT(y) = RT(x)

< <y|Env > := <x | Env >> < [x/y] | Env Env > (2)

ii) Timing

Informally, the timing process assigns system time to a given time variable. Therefore, we treat the timing process in a similar way to the assignment process except that system time is read from system clock and therefore does not have an environment. The three inference rules shown in 3a, 3b and 3c show the RTPA operational semantics when the time variable is a short time, date and long time variable respectively.

a) Variable t is a short time variable TM = hh:mm:ss:ms

t t

RT(@t)=TM

<<@t:STime|Env >:=§t:STime> <[§t/@t]|Env > (3a)

b) Variable t is a date variable Date = yy:MM:dd

t t

RT(@t)=Date

<<@t:Date|Env >:=§t:Date> <[§t/@t]|Env > (3b)

c) Variable t is a long time variable LTime = yyyy:hh:mm:ss:ms

t t

RT(@t) = LTime

<@t:LTime|Env > := §t:LTime> <[§t/@t]|Env > (3c)

iii) Duration: @tnN := §tnN + ∆nN

We treat duration in the context of time delay. Informally, the duration process, delays an executing process for an amount of time equal to ∆n. Thus if P is an executing process, then the expression, “P (@tnN := §tnN + ∆nN)” means “execute P followed by a time delay of ∆n time units”. Simply put, P executes to a state P’ and does nothing while time ∆n elapses. In this case, the environment of P is not affected by t. An operational semantics for the duration process is given in (4).

p p

n

p t p

<P | Env > <P ' | Env '>

<<P|Env <(@tN := §tN + n)|Env > <P ' P '|Env '>→ ⎯⎯→ (4)

3.2 Operational Semantics of RTPA process relations

We present the operational semantics of five RTPA process relations: sequence, while-do, Branch, parallel and event-driven dispatch.

i) Sequence: P → Q

Informally, P→ Q means “execute P followed by Q”. The environments of P and Q may be different. Consequently, the operational semantics must take this into consideration. This is represented as shown in (5).

p p

p q q p

<P | Env > <P ' | Env '>

< <P|Env > <Q|Env > <P ' <Q|Env Env '>→ → (5)

ii) While - do:T

exprBL=TR (P)

Using the while-do process relation, the Boolean expression expr is repeatedly tested. If it is false, the loop terminates. This is shown in rule 6a.

T

e x p r B L = T

< e x p r B L | E n v > < f a l s e | E n v >

< ( P ) | E n v > E n vR (6a)

If expr evaluates to true, then P evaluates to P’ followed by another iteration. This is shown in rule (6b).

p p

T T

p pexprBL =T exprBL=T

<exprBL|Env> <true|Env>

<P|Env > <P '|Env '>

< R (P)|Env > <P ' R (P)|Env '>→ (6b)

iii) Branch: ?(exprBL = T) → P | ?~ → Q

If the Boolean expression, expr, evaluates to true, then process P is executed, otherwise process Q is executed. It should be noted that when P is executed, the environment of Q does not change and has no effect on the environment of P. Rule 7a and 7b show respectively the situation when expr is true and false respectively.

p p

p q p

<exprBL|Env> <true|Env>

<P|Env > <P '|Env '>

<<?(exprBL=T) P|Env > | <(?~) Q|Env >> P '|Env '>→ → < (7a)

q q

p q q

<exprBL | Env> <false|Env>

<Q|Env > <Q '|Env '>

<<?(exprBL=T) P | Env > | <(?~) Q | Env >> <Q ' | Env '>→ → (7b)

iv) Parallel: P || Q (Multi-processor single clock)

For the parallel process, there can be two possible scenarios.

1825

Page 4: [IEEE Canadian Conference on Electrical and Computer Engineering, 2005. - Saskatoon, SK, Canada (May 1-4, 2005)] Canadian Conference on Electrical and Computer Engineering, 2005. -

a) P is executing and Q is not executing for a given period of time (and vice versa) i.e. no synchronization. Rule 8(a(i)) and 8(aii) show inference rules when P and Q are executing respectively.

p p

p q p q

<P|Env > <P '|Env '>

<<P|Env > || <Q|Env > <P ' || <Q|Env ' Env >> (8a)

q q

p q p q

<Q|Env > <Q '|Env '>

<<P|Env > || <Q|Env > <<P|<Env Env '> || Q '> (8b)

b) P and Q perform a common timed event.

If P and Q are executing on a common time action, then the operational semantics is as shown in rule 8b.

p p

q q

p q p q

<P|Env > <P '|Env '>

<Q|Env > <Q '|Env '>

<<P|Env > || <Q|Env >> <P '||Q '|Env ' Env '>(8c)

v) Event Driven Dispatch: @eiS Pi (i∈{1..n})

For event-driven dispatch, a given event causes a process to be dispatched. If no event occurs then no process is dispatched. Thus we can rewrite event-driven dispatch in RTPA as:

? eventS = eiS → Pi |?~ → ∅

where eventS is an event variable (a string). With the new definition, we can give the operational semantics as shown in rules 9a and 9b.

i e e

i e i p i e p

<event= e | Env > <true | Env >

<<@e | Env > P | Env > <P' | Env Env >→(9a)

i e e

i e i e e

< e v e n t= e | E n v > < fa ls e | E n v >

< @ e | E n v P | E n v > E n v→(9b)

Rule 9a is executed when a given event has occurred and 9b is executed when no event has occurred.

4. Conclusions

An operational semantics for a specification language defines how a valid specification in the language is interpreted as a sequence of computations. It thus lays groundwork for verification of formal specifications, particularly for real-time systems where specifications are expected to be precise and unambiguous. However, it is difficult to define an operational semantics for languages which contain variables since any execution of a program also results in changes in the

environment and memory locations to which assigned values are stored. This paper defines the operational semantics of Real-Time Process Algebra (RTPA). Two relationships that map identifiers to memory locations and memory locations to values are defined. Based on these relationships, an operational semantics for RTPA is presented for the 16 meta-processes and 16 process relations using a reduction machine, which defines inference rules for repeatedly simplifying language constructs until a result is obtained. The operational semantics for RTPA, lays groundwork for the development of a verifier for the RTPA specification language. Further work still remains to be done to provide operational semantics for some complicated RTPA process relations such as interrupt dispatch, time-driven dispatch, and concurrency and to develop a verifier for RTPA.

Acknowledgements

The authors would like to acknowledge the Natural Science and Engineering Council of Canada (NSERC) for its support to this work. We would like to thank the anonymous reviewers for their valuable comments and suggestions.

References

[1] Liu, L. Y. H. and Shyamasundar, R. K. (1989), "An operational semantics of real time design language RT-CDL" Proceedings of the 5th International Workshop on Software Specifications & Design Pittsburgh, Pennsylvania, United States, pp. 75-82.

[2] Jones C. B, (2003) Operational Semantics: Concepts and their Expression, Information Processing Letters, Volume 88, Issue 1-2, October, pp. 27 – 32.

[3] G. Plotkin (1981), “A Structural Approach to Operational Semantics”, Technical Report DAIMI FN-19, Aarhus University, Denmark.

[4] Slonneger K., Barry L. Kurtz (1995), “Formal Syntax and Semantics of Programming Languages:A Laboratory Based Approach”, Chapter 8, Reading (Mass.) etc. : Addison-Wesley Publishing Company.

[5] Wang, Y., (2002a), “A New Math for Software Engineering – The Real-time Process Algebra (RTPA)”, In Proceedings of the 2nd ASERC Workshop on Quantitative and Soft Computing Based Software Engineering (QBSSE’02), April, Banff, AB, Canada.

[6] Wang, Y., (2002c), “Description of Static and Dynamic behaviors of Software Components by Real-time Process Algebra (RTPA)”, In Component-Based Software Engineering, F. Barbier, Ed., Kluwer, Academic, U.K.

[7] Schneider S. (1995), “An Operational Semantics for Timed CSP”, In Information and Computation, Vol. 116, No. 2, pp. 193-213.

[8] Tan, X., Y. Wang, and C.F. Ngolah (2004), Specification of the RTPA Grammar and Its Recognition, Proceedings of the 3rd IEEE International Conference on Cognitive Informatics (ICCI'04), IEEE CS Press, Canada, August, pp. 54-63.

[9] Wang, Y. (2005), On the Informatics Laws and Deductive Semantics of Software, IEEE Transactions on Systems, Man, and Cybernetics, to appear.

1826