October 14, 2014

Formal Methods in Software Formal Methods in Software EngineeringEngineering

Introduction to the Lecture, Winter Term 2014/15Prof. Dr. Joel Greenyer

2

Critical Software-Intensive Systems

Green MoveCenter

Greene-box

Greene-box

Greene-box

Greene-box

Greene-box

Ad seller

Municipal info Pollution info

Traffic info

ExternalUsers

3

Discussion

• Which system illustrated here interest me most? Why?

• If you imagine to be involved in the development of such a system...

– ...what development tasks would you find most interesting?

– ...what do you think you have to learn to fulfill these task?

4

Discussion

• What do you think is a formal method?

• And what is it good for?

5

What is a Formal Method?

• "Formal Methods refers to mathematically rigorous techniques and tools for the specification, design and verification of software and hardware systems...”(from http://shemesh.larc.nasa.gov/fm/fm-what.html )

• Specification and design of a system is based on formal models, models in a formal language

– formal: with a well-defined meaning

• Analysis is based on well-defined steps that follow logical reasoning

– and thus allow us, for example, to prove that the model of a system satisfies a specification

6

A typical Software/Systems Development Process...

public void run(){ ...;}

✓×

✓×

informalrequirements

informal or“semi-formal”specification

implementation

unit tests

integration/system

tests

use andmaintenance =

?

design

7

A typical Software/Systems Development Process...

public void run(){ ...;}

✓×

✓×

informalrequirements

informal or“semi-formal”specification

design

implementation

unit tests

integration/system

tests

use andmaintenance =

?informalspecification:unambiguous?consistent?

8

A typical Software/Systems Development Process...

public void run(){ ...;}

✓×

✓×

informalrequirements

informal or“semi-formal”specification

implementation

unit tests

integration/system

tests

use andmaintenance =

?informalspecification:unambiguous?consistent?

All requirementsconsidered?Design correct?

design

9

A typical Software/Systems Development Process...

public void run(){ ...;}

✓×

✓×

informalrequirements

informal or“semi-formal”specification

implementation

unit tests

integration/system

tests

use andmaintenance =

?informalspecification:unambiguous?consistent?

All requirementsconsidered?Design correct?

Testing?Based on informalspecification.

design

10

A typical Software/Systems Development Process...

public void run(){ ...;}

✓×

✓×

informalrequirements

informal or“semi-formal”specification

implementation

unit tests

integration/system

tests

use andmaintenance =

?informalspecification:unambiguous?consistent?

All requirementsconsidered?Design correct?

Testing?Based on informalspecification.

Not what stakeholder wanted. Violates critical requirements,→ dire consequences

design

11

Therac-25

Figure from Nancy Leveson: Medical Devices: The Therac-25

12

East Texas Cancer Center, March 1986

• A patient received electron therapy of cancer in upper back

• After entering the treatment data, the operator noticed that the beam type was set to “x” (x-ray) instead of “e” (electrons)

13

East Texas Cancer Center, March 1986

• The operator changed the setting (“x” to “e”) and confirmed all other previously entered values with a quick series of carriage returns

• Then she hit “B” to begin

• The machine shut down, indicating an under-dosage

• She hit “P” to proceed(a feature just previously added due to user requests)

• On that day, the video and audio monitoring was out of operation

14

East Texas Cancer Center, March 1986

• After the first treatment, the patient felt a burn on his back

• He then got up, because he suspected something was wrong

• When the operator hit “P”, the patient's hand was in the beam

• “he felt his arm was shocked with electricity and his hand was leaving his body”

• Physicists suspected an electric shock

• Instead, the patient received a massive overdose

• The patient was in pain and partly paralyzed, died five months later from the overdose

• AECL engineers could not reproduce the malfunction

15

What happened

• Hardware safety measures were replaced by software safety measures

– assumption: “software does not wear out”

– nobody suspected that software safety measures could be flawed

• Bad software design: effects of concurrency were not taken into account

– of processes interpreting input data and setting machine parameters

• Further reading: – http://sunnyday.mit.edu/papers/therac.pdf

16

Discussion

• What kind of software engineering problems can cannot be solved by formal methods? Which problems cannot?

• What do you think are biggest obstacles in applying formal methods where they could help?

17

Obstacles in applying formal methods

• Due to high system complexity, formal methods often cannot be used successfully

– We must abstract or decompose the problem

– Or make analysis techniques more efficient

• Writing formal specifications and designs is difficult

– requires expertise and discipline

– often fixing ambiguities and errors later also works (at a cost)

• Existing tools are difficult to integrate

– most formal analysis tools work on simple mathematical models

– often it is difficult to express complex problems with them

– they are not intuitive, often non-experts don't understand them

18

Learning objectives of this lecture

(1) You know fundamental formal modeling techniques, such as different forms of automata and temporal logics

(2) You have detailed knowledge of selected analysis techniques and the involved algorithms

(3) You have an elementary knowledge of applying formal analysis techniques to solve practical software and systems engineering problems.

19

Model Checking

Specification

Model

Model Checking

+ counter example(how the specificationcan be violated)

false

true

modify model (usually the error is here)

or modify specification (may also be wrong)

20

Model Checking in the development process

GQ6 informal specification

assert(...);

design

code

formalize

public void run(){ ...;}

create design

write/generate code

chan ts2c =...

[]!a || b;[]<> a;

Model for MC tool

specificationfor MCtool

Model Checker (MC)

transform

check

formal specification

transform

modify design orspecification

detail designor generate

code

21

Who am I and why am I here?

• Prof. Dr. Joel Greenyer

– 2011: Doctorate degree from University of Paderborn

– 2011 – 2013: Post-Doc researcher at Politecnico di Milano, Italy

– since April 2013: Juniorprofessor at the Leibniz Universität Hannover

• Contact

– Email: greenyer@uni-hannover.de

– Office G322

– You can make appointments via email

22

Who are you and why are you here?

?

23

Format of the lecture

• Will be broadcast live (via Hangout on Air) and recorded(on Youtube)

– HOAs and recordings will not be publicly available

– Send me your Google+ URL, then I can invite you to the HOA

https://plus.google.com/u/0/b/116488647624062331069/116488647624062331069/about

24

Interaction in the lecture

25

Interaction in the lecture

26

Tutorial and exercises

• Sometimes there will be small homework exercises

• Mainly, you will work on small-size projects in groups of three students

– Among other things, you will implement your own model checker!

27

Exam and Points

• There will be an oral exam

• Dates for the exam will be determined

• You can improve your final grade by participating in the exercises and mini projects

– 1/3 grade bonus if

• you participated in at least one mini-project, in a group of 3

• and presented in the tutorial/lecture– the solution of an exercise– the result or intermediate progress of a project

– 2/3 grade bonus if

• you did the above

• and participated in all mini-projects

28

Discuss and get organized in aGoogle Community

• I can invite you if you send me your Google+ URL

• Request to join onhttps://plus.google.com/communities/116163206527300925070

29

Organizational Issues

• Date and time of the lecture: Tuesdays 4.00-5.30 PM

• Date and time of the tutorial:

– Wednesdays 9-10, 10-11, or 11-12 AM

– or Thursdays 1-2, 2-3, 3-4, or 4-5 PM

– vote here (multiple selections possible): http://doodle.com/4bt7zzynfupa7hq2

• please give your votes until next Monday

• There will be no tutorial this week – it starts next week

30

Dates and topics

• Lecture dates:

– 14.10. (introduction)

– 21.10. (introduction to formal models, automata, labeled transition systems)

– 18.10. (software/system design process)

– 4.11. (CTL and CTL model-checking)

– 11.11. (CTL and CTL model-checking)

– 18.11. (no lecture or exercise)

– 25.11. (LTL and LTL model-checking)

– 2.12. (LTL and LTL model-checking)

– 9.12. (...)

– 16.12. (...)

– 6.1. (...)

– 13.1. (...)

– 20.1. (...)

– 27.1. (no lecture or we have to find alternative date)

Methods with formal variants of UML,real-time systems

31

Assignments (until next week)

• Create a Google+ account and request to join the Google communityhttps://plus.google.com/communities/116163206527300925070

• Form groups of three to four students, research the internet/literature for reports on software bugs

– find software bugs that you think could have been avoided by applying formal methods

– describe the software bug and sketch how you think they could be avoided

– prepare a short set of Powerpoint slides (or use another tool) that you could present in the next tutorial session

• Read http://cacm.acm.org/magazines/2014/2/171689-mars-code/fulltext

– How were formal methods applied in the development of the Curiosity Rover?