Formal Verification for UML/SysML models

Transcription

1 Formal Verification for UML/SysML models IBM Research Lab - Haifa

2 Content Formal verification v.s. testing Correctness properties Formal verification for Rhapsody models 2

3 Formal Verification Desired Properties Model Analysis Does the system obey its requirements? Demonstrate the cases where the system fails Exhaustive search for bugs In the absence of requirements Try to violate universal rules that all systems should obey 3

4 From models to models A model of a system: UML / SysML Analysis model: finite state machine (mathematical) Yes, these are huge! FV algorithms analyze them without building them 4

5 Computations Verification amounts to analyzing computations looking for possible bad states Imagine a system that reacts to its inputs and changes states Initial state 2 bits of input Assuming n Boolean variables: 5 2 n different states

6 Testing In testing we run the system on a single path through the computation tree Didn t hit an error? We run again. And again. And again 6

7 Formal Verification Formal verification uses mathematics rather than chance 7

8 Formal Verification Formal verification uses mathematics rather than chance 8

9 Formal Verification Formal verification uses mathematics rather than chance 9

10 crit_st proc2 updating IBM Formal verification for UML/SysML The user creates behavioral models The user defines correctness properties Mutual exclusion Object: proc1 State: Object: State: always (door_unlocked -> speed=0) never (P1.critical & P2.critical) 10 Fail + sequence diagram Pass

11 Correctness properties First rule: Second rule: know what you want to verify! Say it clearly Formal verification uses temporal specification languages Formally defined Powerful Not so easy to read / write Template properties hide the temporal language Easy to understand, easy to use Limited expressibility 11

12 Internal Non-Determinism Find scenarios in which there are two (or more) enabled transitions from the same state Model independent property Non determinism Can these two guards hold at the same time? check for ND transitions 12

13 Out of Bounds Check that attributes cannot be assigned with out-of-bounds values Model independent property Out-Of-Bounds check attribute bounds 13

14 Mutual Exclusion The user specifies two distinct states in two different objects The tool verifies that these states can never be active at the same time Model specific property 14

15 Invariants An invariant is an expression that should hold at all times Invariant Invariant expression: (state(a1) = done) -> (a1.x > 0) Invariant expressions can refer to states and attributes a1 is an object name state(a1) is the current state of a1 (can be hierarchical) a1.x is the attribute x of a1 Model specific property 15

16 Dead Code Find states that cannot be reached Find transitions that cannot fire Model independent property Dead States check for dead states 16

17 Deadlock Freedom A deadlock is a situation in which no progress can be made regardless of what the environment does. In other words, no transitions can ever be fired Model independent property Deadlock check for deadlocks 17

18 and more Template properties can be added and customized on-demand Should be tailored to in-house design methodology of specific customer Verification methodology: Template properties used by engineers Temporal logic used by verification expert Correctness properties should be part of the model 18

19 The Model Verifier Verifying UML/SysML (behavioral) specifications A subset defined for safety critical systems Rhapsody Mathematical representation of model and properties Problematic scenarios / Proofs Formal Engine 19

20 Contact information Ronen Levy Emerging Quality Technologies, Manager Karen Yorav FV for UML project leader 20