TIETS14 Introduction to Formal Specification 5 ECTS Teacher: Timo Nummenmaa timo.nummenmaa@staff.uta.fi Executable Formal Specifications in Game Development: Design, Validation and Evolution
Teaching times: Lectures: 10 lectures Tuesdays weekly at 10-12, Pinni B0016 Thursdays weekly at 10-12, Pinni B0016 Weekly exercise session: 5 exercise sessions Thursdays weekly at 12-14, Pinni B0016 Exam Thu 26-Oct-2017 at 14-18, Pinni B1096
Marking The lectures are not compulsory, but for this course it is strictly recommended that you participate in them. The course has an exam, which gives 24 points as maximum. You need to score at least 10 from the exam to pass the course. Of the weekly exercises 30% is compulsory. The rest give you points: 40% give 1 point, 50% give 2 points,..., and 90% give you 6 points (maximum). The coursework gives 0..6 points. The marking scale has not been decided yet, but 30 points is guaranteed to give you a full mark (5).
Marking continued The amount of exercises you have done is checked twice. Once after 3 exercise sessions, once after 5. This means that if you have not completed 30% of the tasks given until that point for the first 3 sessions, it is not possible to complete the course. If you have not completed 30% of all of the exercises in the end, it is also not possible to complete the course.
Lectures The first part of the lectures mostly follows the book by Magee and Kramer. The book has a website, which contains the slides and a downloadable tool, which will also be used in the course. The university library used to have some books, so you may try to find out about that. The second part is about the DisCo system.
Weekly exercises The exercises shall be returned through WETO (the dev version!) The idea of the weekly exercises is that the students solve the exercises at home, submit the solutions through weto and come to the class with the solutions. A student or several students may be asked to present their solutions. Presenting at 3 weekly exercise sessions will give you one extra point. No penalty for wrong solutions The only way to receive feedback on exercise solutions is to come to the exercise sessions, thus it is highly recommended.
Coursework There will be a coursework Details will be available later Deadline will be around the time of the exam The coursework is designed to help you prepare for the exam
Exam There will be an exam Thu 26-Oct-2017 at 14-18, Pinni B1096 There will be one repeat exam The date will be given later
Websites Course information http://www.uta.fi/sis/tie/ifs/index.html Weto https://wetodev.sis.uta.fi/
Concurrency: State Models & Java Programs The book is originally for teaching concurrency This is done through formal specifications and Java implementations It introduces formal specifications in a good way for learning them Thus we will use this book to learn about formal specifications and models We will not focus on the Java parts It is possible to learn about concurrency while learning about formal specifications
Some terms and definitions
Formal Methods Either a branch of pure mathematics which may or may not have any application for real world purposes Or a branch of software engineering concerned with techniques and tools to create better software systems
Formal Methods Follow definition: a formal method is a set of tools and notations (with a formal semantics) used to specify unambiguously the requirements of a computer system that supports the proof of properties of that specification and proofs of correctness of an eventual implementation with respect to that specification (M.G. Hinchey and J.P. Bowen. Applications of formal methods.)
Formal Specifications A formal specification is a specification that is based on mathematics and can be used to model system behaviour. The formal specification should precisely state what the final piece of software is supposed to do
Dynamic vs Static Model dynamic aspects of software systems (this course) system behaviour (control flow) control distribution (concurrency) Model static aspects of software systems (languages such as Z) system states & data structures operations & preconditions
Executable Formal Specifications Formal specifications can be Written in a predetermined specification language That can be executed in a way which anticipates how the system specified will behave These specifications are called executable specifications These specifications can often be studied by simulations
Example: FSP If x is an action and P a process then (x-> P) describes a process that initially engages in the action x and then behaves exactly as described by P. ONESHOT = (once -> STOP). once 0 1 ONESHOT state machine (terminating process) Magee/Kramer 2 nd Edition
FSP - action prefix & recursion Repetitive behaviour uses recursion: on SWITCH = OFF, OFF = (on -> ON), ON = (off-> OFF). Substituting to get a more succinct definition: SWITCH = OFF, OFF = (on ->(off->off)). And again: SWITCH = (on->off->switch). Magee/Kramer 2 nd Edition 0 1 off
DisCo Distributed Co-operation, a formal specification method for reactive systems http://disco.cs.tut.fi/ Created at the Tampere University of Technology Open Source Object oriented Action based Modified to support game development better Extended support for probabilities
Disco specification Disco specification Layers Classes Integers, booleans, records, sets, sequences, states... Extended or new types Relations between classes Actions that alter the state of the system Creation Guard Objects and their states Relation states
DisCo Example layer swapping is class Container is end; val: integer; action swap(c1, c2: Container) is when true do end; c1.val := c2.val c2.val := c1.val; end;
DisCo Two parts Compiler Source compilation Animator Graphical UI Simulations