Model Checking
with UPPAAL
Ulrik Hørlyk Hjort
Ulrik.H.Hjort@BestPractice-Consulting.com
BestPractice Consulting
—
Thursday...
Background
Ulrik Hørlyk Hjort
Safety Critical and High Integrity system development since
1997
Defence industry from 1997
...
Overview
Use of Model Checking to add value to traditional testing.
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulti...
Traditional Testing
Testing involves running a program with a set of inputs and
comparing the actual outputs from the prog...
Testing Limitations
Testing cannot take place until some implementation is
available.
Correcting errors uncovered by testi...
Testing Limitations
Testing can only help to uncover errors it cannot guarantee
the absence of them.
Since, for any applic...
Testing Limitations
Testing is always carried out with respect to requirements as
laid down in the specification.
If the sp...
Ambiguous Specification
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC
Model Checking
Testing Problems
Clearly the specification plays a vital role in the reliability of
the software produced.
The design, and ...
Formal Methods
A formal method provides a formal language in which to
express the initial specification and all future desi...
Formal Methods advantages
The discipline required in producing a formal specification of
user requirements and the ability ...
Formal Methods advantages
Important properties (such as internal consistency) of the
initial specification can be checked m...
Formal Methods advantages
Proofs can help uncover design errors as soon as they are
made, rather than having to wait for t...
Formal Methods advantages
A proof of program correctness can be constructed that is a
much more robust method of achieving...
Formal Methods advantages
Formal specifications can help considerably in generating
suitable test cases.
Ulrik Hørlyk Hjort...
Model Checking
In a model-based approach an abstract mathematical model is
built of the data, using abstract mathematical ...
The UPPAAL System
Integrated tool environment for:
System Modelling
Simulation of the model
Verification of the model
Ulrik...
The System Editor
The system editor is used to create and edit the system model
to be analyzed
A system model describe a n...
UPPAAL Model Items
Initial Location
Location
Edge
Synchronization
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting...
UPPAAL Model Items
class _Factorial {
int result;
public void Factorial()
{
for (int i = result-1; i > 1; i--) {
result *=...
UPPAAL Model Items Subprogram Synchronization
class Hello {
private void Put_Line()
{
System.out.println("Hello World!n");...
UPPAAL Model Items Ada Tasks
task body TaskA is
begin
TaskB.WriteTaskName;
end TaskA;
task body TaskB is
begin
accept Writ...
UPPAAL Model Items Parametrised Synchronization
class Factorial {
int result;
public int Factorial(int N)
{
int result = 1...
The Model Checker (Verifier)
The main purpose of a model checker is to verify the model
with respect to a requirement speci...
Quantifiers
E : There exists a path
A : For all paths
G (♦ in UPPAAL) : All states in a path
F ( in UPPAAL) : Some states i...
Reachability Properties: E ϕ “ϕ Reachable”
E ϕ: It is possible from the initial state to reach a state in
which ϕ is satis...
Safety Properties: A ϕ “Invariantly ϕ”
A ϕ: ϕ holds invariantly
ϕ is true in all reachable states
Ulrik Hørlyk Hjort Ulrik...
Liveness Properties: A ♦ ϕ “Inevitable ϕ”
A ♦ ϕ: ϕ will inevitable become true
The automaton is guaranteed to eventually r...
E ϕ “Potentially always ϕ”
E ϕ: ϕ is potentially always true
There exists a path in which ϕ is true in all states
Ulrik Hø...
The Simulator
The simulator can be used in three ways:
Running the system manually and manually choose the
transitions to ...
ATM System
E X A M P L E
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC
Model Checking
Actors: Customer, Bank
System: ATM
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC
Model Checking
Customer
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC
Model Checking
ATM
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC
Model Checking
Bank
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC
Model Checking
ATM System
Requirements:
1 Transaction is only valid with a bank balance greater than 10
euro
2 Customer gets cash when tr...
Requirement 1
Transaction is only valid with a bank balance greater than 10
euro
A (Customer.READY and Bank.TRANSACTION OK...
Requirement 2
Customer gets cash when transaction is done
E ♦ Customer.GET CASH and Bank.TRANSACTION DONE
Ulrik Hørlyk Hjo...
Requirement 3
System may not be able to enter a deadlock state
A not deadlock
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractic...
System
Automatic test of requirements and MMI flow of insulin pump
Javascript with user actions commands and verification of...
System
UPPAAL model made from UML diagrams, MMI flows and
requirements
UPPAAL system locations was annotated with test scri...
System
Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC
Model Checking
Test script example
expect_mainScreen() {
expect(Label(Welcome);
expect(Label(BatteryIndicator);
}
expect_callScreen() {
e...
Upcoming SlideShare
Loading in …5
×

Uppaal

288
-1

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
288
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Uppaal

  1. 1. Model Checking with UPPAAL Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BestPractice Consulting — Thursday 31st May, 2012
  2. 2. Background Ulrik Hørlyk Hjort Safety Critical and High Integrity system development since 1997 Defence industry from 1997 Space industry from 2003 Medical industry from 2006 Formal software development since 2003 VDM, Z, B-Method and UPPAAL Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  3. 3. Overview Use of Model Checking to add value to traditional testing. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  4. 4. Traditional Testing Testing involves running a program with a set of inputs and comparing the actual outputs from the program against the expected outputs (as defined in the specification). There are several limitations to using testing as the sole approach to software error detection: Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  5. 5. Testing Limitations Testing cannot take place until some implementation is available. Correcting errors uncovered by testing could involve retracing many steps and undoing work previously done. If testing is the only approach to error detection then errors in the specification involve the greatest amount of work to rectify. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  6. 6. Testing Limitations Testing can only help to uncover errors it cannot guarantee the absence of them. Since, for any application, it is impossible to test every set of input values, residual errors will always have to be accepted. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  7. 7. Testing Limitations Testing is always carried out with respect to requirements as laid down in the specification. If the specification document is in any way ambiguous it is open to interpretation, and hence misinterpretation, making testing a rather inexact science. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  8. 8. Ambiguous Specification Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  9. 9. Testing Problems Clearly the specification plays a vital role in the reliability of the software produced. The design, and subsequent implementation, is based upon the information in the specification. The testing process relies upon the developers understanding of the specification to determine whether or not the software is behaving correctly. Misunderstandings in the specification can lead to the delivery of final applications that do not match user requirements. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  10. 10. Formal Methods A formal method provides a formal language in which to express the initial specification and all future design steps towards the final program in a unambiguous way. More than just a specification language —it also includes a proof system for demonstrating that each design step preserves the formal meaning captured in the previous step. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  11. 11. Formal Methods advantages The discipline required in producing a formal specification of user requirements and the ability to analyse a specification (which only arises if the specification language has a well-defined semantics) allows for feedback on system specifications at early development stages, increasing confidence that the specification accurately captures the real system requirements. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  12. 12. Formal Methods advantages Important properties (such as internal consistency) of the initial specification can be checked mathematically and incorporated as run-time checks in the final program. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  13. 13. Formal Methods advantages Proofs can help uncover design errors as soon as they are made, rather than having to wait for testing of the final implementation. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  14. 14. Formal Methods advantages A proof of program correctness can be constructed that is a much more robust method of achieving program correctness than is testing alone. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  15. 15. Formal Methods advantages Formal specifications can help considerably in generating suitable test cases. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  16. 16. Model Checking In a model-based approach an abstract mathematical model is built of the data, using abstract mathematical types such as sets and abstract state machines. The behaviour of the operations is then specified directly with respect to this model. Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  17. 17. The UPPAAL System Integrated tool environment for: System Modelling Simulation of the model Verification of the model Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  18. 18. The System Editor The system editor is used to create and edit the system model to be analyzed A system model describe a network of a finite number of non-deterministic finite state automata Edges between states may be labeled with: Guards Synchronizations Assignment statements Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  19. 19. UPPAAL Model Items Initial Location Location Edge Synchronization Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  20. 20. UPPAAL Model Items class _Factorial { int result; public void Factorial() { for (int i = result-1; i > 1; i--) { result *= i; } } public _Factorial() { result = 5; } public voidShowResult() { System.out.println("Result:" + result); } public static void main(String args[]) { _Factorial fac = new _Factorial(); fac.Factorial(); fac.ShowResult(); } } Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  21. 21. UPPAAL Model Items Subprogram Synchronization class Hello { private void Put_Line() { System.out.println("Hello World!n"); } public Hello() { Put_Line(); } public static void main(String args[]) { Hello hello = new Hello(); } } Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  22. 22. UPPAAL Model Items Ada Tasks task body TaskA is begin TaskB.WriteTaskName; end TaskA; task body TaskB is begin accept WriteTaskName do Put_Line("Task B"); end WriteTaskName; end TaskB; Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  23. 23. UPPAAL Model Items Parametrised Synchronization class Factorial { int result; public int Factorial(int N) { int result = 1; for (int i = N; i > 1; i--) { result *= i; } return result; } public static void main(String args[]) { Factorial fac = new Factorial(); int result = fac.Factorial(5); System.out.println(result); } } Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  24. 24. The Model Checker (Verifier) The main purpose of a model checker is to verify the model with respect to a requirement specification. Like the model, the requirement specification must be expressed in a formally well-defined and machine readable language. The model checker support three path formulae expressed by temporal logic quantifiers: Reachability : Is the state formular ϕ satisfied from any reachable state ? Safety : ϕ is invariantly true in all reachable states Liveness : ϕ is eventually sastified Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  25. 25. Quantifiers E : There exists a path A : For all paths G (♦ in UPPAAL) : All states in a path F ( in UPPAAL) : Some states in a path The following combinations are supported: A , A♦, E♦, and E Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  26. 26. Reachability Properties: E ϕ “ϕ Reachable” E ϕ: It is possible from the initial state to reach a state in which ϕ is satisfied ϕ is true in at least one reachable state Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  27. 27. Safety Properties: A ϕ “Invariantly ϕ” A ϕ: ϕ holds invariantly ϕ is true in all reachable states Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  28. 28. Liveness Properties: A ♦ ϕ “Inevitable ϕ” A ♦ ϕ: ϕ will inevitable become true The automaton is guaranteed to eventually reach a state in which ϕ is true ϕ is true in some states of all paths Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  29. 29. E ϕ “Potentially always ϕ” E ϕ: ϕ is potentially always true There exists a path in which ϕ is true in all states Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  30. 30. The Simulator The simulator can be used in three ways: Running the system manually and manually choose the transitions to take Going through a trace generated by the verifier Running the system at is own in random mode Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  31. 31. ATM System E X A M P L E Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  32. 32. Actors: Customer, Bank System: ATM Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  33. 33. Customer Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  34. 34. ATM Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  35. 35. Bank Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  36. 36. ATM System Requirements: 1 Transaction is only valid with a bank balance greater than 10 euro 2 Customer gets cash when transaction is done 3 System may not be able to enter a deadlock state Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  37. 37. Requirement 1 Transaction is only valid with a bank balance greater than 10 euro A (Customer.READY and Bank.TRANSACTION OK) imply Bank.balance >10 Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  38. 38. Requirement 2 Customer gets cash when transaction is done E ♦ Customer.GET CASH and Bank.TRANSACTION DONE Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  39. 39. Requirement 3 System may not be able to enter a deadlock state A not deadlock Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  40. 40. System Automatic test of requirements and MMI flow of insulin pump Javascript with user actions commands and verification of expected result of these First manually written from UML diagrams, MMI flows and requirements Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  41. 41. System UPPAAL model made from UML diagrams, MMI flows and requirements UPPAAL system locations was annotated with test script actions Full coverages paths of the model found by verifier A full coverage package of test Javascript generated from the model Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  42. 42. System Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  43. 43. Test script example expect_mainScreen() { expect(Label(Welcome); expect(Label(BatteryIndicator); } expect_callScreen() { expect(Label(Calling ...); } // Main Script: expect_mainScreen(); insert_card() expect_enter_pincode_screen(); key(5); expect(5); key(1); expect(1); expect_trasactionscreen(); . . . Ulrik Hørlyk Hjort Ulrik.H.Hjort@BestPractice-Consulting.com BPC Model Checking
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×