of 24 /24
Formal Methods in Software Engineering 1 Lecture 17 Describing Syntax and Semantics
• Author

sharon-cummings
• Category

## Documents

• view

224

4

Embed Size (px)

### Transcript of Formal Methods in Software Engineering1 Lecture 17 Describing Syntax and Semantics. Formal Methods in Software Engineering 1

Lecture 17

Describing Syntax and Semantics Formal Methods in Software Engineering 2

Semantics

• How do we describe the “meaning” of a program?

• Dynamic semantics or semantics is concerned with accurately describing the execution behaviour of a language

• Why do we care?– English descriptions are often incomplete and ambiguous

– Compiler writers must implement the language description accurately

– Programmers want the same behaviour on different platforms

• There is no single widely acceptable notation or formalism for describing semantics

• Entire books have been dedicated to various semantic notations! Formal Methods in Software Engineering

Operational Semantics

• Describe the meaning of a program by executing its statements on a machine, either simulated or actual. The change in the state of the machine (memory, registers, etc.) defines the meaning of the statement

• At the highest level, we’re interested in the final result (natural operational semantics)

• At the lowest level, look at a translated version to determine precise meaning of a single statement (structural operational semantics)

3 Formal Methods in Software Engineering

Operational Semantics Example

• C Statementfor (expr1; expr2;

expr3){ . . .}

• Operational Statementsexpr1;

loop: if expr2 == 0 goto out. . .expr3;goto loop

out: . . .

Human reader is virtual computer, assumed to be able to correctly “execute” the instructions and recognize the effects. Note that language is intermediate level, not machine language.

4 Formal Methods in Software Engineering 5

Operational Semantics (continued)• A better alternative: A complete computer

simulation• The process:

– Build a translator (translates source code to the machine code of an idealized computer)

– Build a simulator for the idealized computer Formal Methods in Software Engineering

Evaluation of Operational Semantics• Good if used informally (language manuals, etc.)• Extremely complex if used formally (e.g., Vienna

Definition Language), it was used for describing semantics of PL/I.

• Can lead to circularities, because statements of high-level language are described in statements of lower-level language

• These problems can be avoided with formalisms based on logic or mathematics

6 Formal Methods in Software Engineering 7

Axiomatic Semantics

• Based on formal logic (predicate calculus)• Original purpose: formal program

verification• Correctness proofs specify constraints on

program variables• When proofs can be constructed, they

show that a program performs the computation described by its specification Formal Methods in Software Engineering 8

Axiomatic Semantics (continued)

• Logical expressions used in axiomatic semantics are called assertions.

• An assertion before a statement (a precondition) states the relationships and constraints among variables that are true at that point in execution

• An assertion following a statement is a postcondition

• A weakest precondition is the least restrictive precondition that will guarantee the postcondition Formal Methods in Software Engineering 9

Axiomatic Semantics Form

• Pre-, post form: {P} statement {Q}

• An example– a = b + 1 {a > 1}– One possible precondition: {b > 10}– Weakest precondition: {b > 0}

precondition postcondition Formal Methods in Software Engineering 10

Program Proof Process

• The postcondition for the entire program is the desired result– Work back through the program to the first

statement. If the precondition on the first statement is the same as the program specification, the program is correct.

• An axiom is a logical statement that is assumed to be true.

• An inference rule is a method of inferring the truth of one assertion on the basis of the value of other assertions. Formal Methods in Software Engineering

Program Proof Process (cont)

• To use axiomatic semantics with a given programming language (either for correctness proofs or for formal semantic specification), must have either an axiom or an inference rule for each kind of statement in the language

• The following rules assume that expressions do not have side effects

11 Formal Methods in Software Engineering 12

Axiomatic Semantics: Assignment

• An axiom for assignment statements (x = E): {Qx->E} x = E {Q}

• Example 1– a = b/2 – 1 {a < 10}– means b/2-1 must be < 10, or b < 22 is precondition

• Example 2– x = x + y – 3 { x > 10}– means x + y – 3 > 10, so y > 13 – x– OK for variable to be on both sides

Q is constraint on xreplace x by E in Q Formal Methods in Software Engineering

Axiomatic Semantics - Consequence

• {x > 3} x = x – 3 { x > 0} – Using assignment axiom, x = x – 3 {x > 0} produces

precondition of { x > 3 } which “proves” this statement

• What about {x > 5} x = x – 3 { x > 0 } ??

• The Rule of Consequence:

Q' S P'

Q' Q P, P' , S QP

0x 3 - x x 5x

0)(x 0) (x 3), (x 5) (x ,0 3 - x x 3

xx

13 Formal Methods in Software Engineering 14

Axiomatic Semantics: Sequences

• S1; S2; …{P1} S1 {P2}{P2} S2 {P3}

{P1 } S1 {P2 } , {P2 } S2 {P3 }{P1 } S1; S2 {P3 } Formal Methods in Software Engineering

Axiomatic Semantics: Selection

• if B then S1 else S2• Must be proven for both true and false

conditions

• Example: if (x > 0) y = y-1 else y = y + 1• Assume Q is {y > 0}• then P is {y > 1} else P is {y > -1} • Since {y > 1} => {y > -1} use {y > 1}

{Q} S2 else S1 then B if

S2 P} and B){(not {Q}, S1 P} and B {

P

Q

one P one Q

15 Formal Methods in Software Engineering 16

Axiomatic Semantics: Pretest Loops• {P} while B do S end {Q}• Number of iterations not always known.

Use a loop invariant I and induction.

I and B S {I }{I } while B do S {I and not B } Formal Methods in Software Engineering 17

Axiomatic Semantics: Loops

• Characteristics of the loop invariant: I must meet the following conditions:– P => I -- the loop invariant must be true initially

– {I} B {I} -- evaluation of the Boolean must not change the validity of I

– {I and B} S {I} -- I is not changed by executing the body of the loop

– (I and (not B)) => Q -- if I is true and B is false, is implied

– The loop terminates Formal Methods in Software Engineering

Axiomatic Semantics: Loop Example• while y <> x do y = y + 1 { y = x}• Run through the loop a few times to find

weakest precondition1st: wp (y = y + 1, {y = x} } = {y + 1 = x or y = x – 1}2nd: wp (y = y + 1, {y = x} } = {y + 1 = x or y = x – 2}3rd: wp (y = y + 1, {y = x} } = {y + 1 = x or y = x – 3}

So we see that {y < x} will suffice for 1 or more iterations. Combined with {y = x} for 0 iterations we have { y <= x } for loop invariant. I can also be used as the precondition. NOTE: text walks through four conditions for I

assignment equality test

18 Formal Methods in Software Engineering 19

Loop Invariant

• The loop invariant I is a weakened version of the loop postcondition, and it is also a precondition.

• I must be weak enough to be satisfied prior to the beginning of the loop, but when combined with the loop exit condition, it must be strong enough to force the truth of the postcondition

• Finding loop invariant can be difficult.• If loop termination can be shown, axiomatic

description is called total correctness.• If other conditions can be met but termination is

not guaranteed, called partial correctness. Formal Methods in Software Engineering 20

Evaluation of Axiomatic Semantics

• Developing axioms or inference rules for all of the statements in a language is difficult

• It is a good tool for correctness proofs, and an excellent framework for reasoning about programs, but it is not as useful for language users and compiler writers

• Its usefulness in describing the meaning of a programming language is limited for language users or compiler writers Formal Methods in Software Engineering 21

Denotational Semantics

• Based on recursive function theory• The most abstract semantics description

method• Originally developed by Scott and

Strachey (1970) Formal Methods in Software Engineering 22

Denotational Semantics (continued)• The process of building a denotational

specification for a language: Define a mathematical object for each language entity– Define a function that maps instances of the

language entities onto instances of the corresponding mathematical objects

• The meaning of language constructs are defined by only the values of the program's variables Formal Methods in Software Engineering 23

Denotation Semantics vs Operational Semantics

• In operational semantics, the state changes are defined by coded algorithms

• In denotational semantics, the state changes are defined by rigorous mathematical functions Formal Methods in Software Engineering 24

Evaluation of Denotational Semantics

• Can be used to prove the correctness of programs

• Provides a rigorous way to think about programs• Can be an aid to language design• Has been used in compiler generation systems

(but no useful compilers generated)• Because of its complexity, they are of little use to

language users
{"ft_lang_label":"__label__en","ft_lang_prob":0.8260345,"math_prob":0.86116546,"size":9184,"snap":"2023-14-2023-23","text_gpt3_token_len":2291,"char_repetition_ratio":0.18409586,"word_repetition_ratio":0.07459926,"special_character_ratio":0.2470601,"punctuation_ratio":0.06793651,"nsfw_num_words":1,"has_unicode_error":false,"math_prob_llama3":0.9737686,"pos_list":[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"im_url_duplicate_count":[null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null],"WARC_HEADER":"{\"WARC-Type\":\"response\",\"WARC-Date\":\"2023-06-05T07:37:29Z\",\"WARC-Record-ID\":\"<urn:uuid:113eaefc-94da-4656-8456-694e27ca2a33>\",\"Content-Length\":\"134420\",\"Content-Type\":\"application/http; msgtype=response\",\"WARC-Warcinfo-ID\":\"<urn:uuid:cfa2b7a6-dd0e-4101-8b82-3669a6e83a5d>\",\"WARC-Concurrent-To\":\"<urn:uuid:197d0293-7efb-4a7c-98a0-13c063a8248e>\",\"WARC-IP-Address\":\"104.21.75.202\",\"WARC-Target-URI\":\"https://fdocuments.in/document/formal-methods-in-software-engineering1-lecture-17-describing-syntax-and-semantics.html\",\"WARC-Payload-Digest\":\"sha1:UXU42SIJUMRKBC2BDMYARWUFWD7VQZCX\",\"WARC-Block-Digest\":\"sha1:VG3WNHUCKTC3PYFE74DURI6YCD3FEK2Z\",\"WARC-Identified-Payload-Type\":\"text/html\",\"warc_filename\":\"/cc_download/warc_2023/CC-MAIN-2023-23/CC-MAIN-2023-23_segments_1685224651325.38_warc_CC-MAIN-20230605053432-20230605083432-00113.warc.gz\"}"}