Formal Validation with OCL

1. Formal Validation with OCL • Thouraya Bouabana-Tebibel • Algeria, 2006

2. Introduction • System validation • UML • Lacks of well-defined semantics • UML 2.0 • Remains informal • Lack of tools for automatic analysis and validation • Model Checking

3. Introduction • Customer requirements -> OCL invariants (class diagram) • UML dynamic models -> Petri nets • OCL invariants -> temporal logic properties -> PROD (Petri net analysis). • Object flow specification on the dynamic models. • Motivation • UML designer may reach a valid modeling without needs for knowledge of formal techniques.

4. Background --- Petri Nets • Formal definition: A Petri net is a bipartite directed graph (P, T, In, Out), where In⊆ P x T and Out ⊆ T x P. Example : Traffic Light

5. Background --- Statecharts • Describe the behavior of a class in terms of states and exchanged messages with other classes’ statecharts. • A state is composed of two atomic actions and one activity. • The states are linked by means of transitions annotated with the event that triggers the transition (event trigger) and atomic actions produced by the triggered transition.

6. Background --- Example Class Diagram Statechart

7. Background --- Petri Nets • A petri net is a 7-tuple <P, T, A, C, Pre, Post, M0> where, • P = {p1, p2, ..., pn} is a set of places • T = {t1, t2, ..., tn} is a set of transitions. • A ⊆ P x T ∪ T x P, is a set of arcs. • C = {C1, C2, ..., Cn} is a set of colors • Pre: P x T  (C) is a precondition function to the transition firing such that Pre(pi, ti) = {C1, C2, ..., Ck}. • Post: P x T  (C) is a postcondition function to the transition firing such that Post(pi, ti) = {C1, C2, ..., Ck}. • M0: P -> C is the initial marking function.

8. Background --- Derivation Process • Each statechart modeling an interactive class behavior is transformed to an object subnet called Dynamic Model.

9. Background --- Dynamic Model • Each state s  S is converted to a place p  P • Each transition tr  Tr is converted to a transition t  T.

10. Background --- Dynamic Model • Link place • Events generated by the DMs • Input place • Interface of the DM Link Input

11. Background --- Dynamic Model • Initial marking • Static: object<obj, attrib> • Class instances and attribute values • Object diagram • Dynamic: event<srce, targ, op/xobj, attrib> • Exchanged messages • Sequence diagram Object Scenario

12. Translation of the statechart constructs to Petri nets

13. Dynamic Model --- Resulting conversion

14. System Property Validation • Model validation • The model must conform to the customer initial requirements. • Specific properties of the system (written by the designer) are used. • System properties are expressed in the OCL language and then translated to LTL logic.

15. System Property Validation --- OCL • OCL is mainly based on collection handling to specify object invariants. • Collections corresponding to association ends must appear on the Petri net specification to be translated to LTL properties. • Introduction of the association end modeling onto the statecharts in order to get the equivalent Petri net constructs. • Create link and destroy link actions: Event {linkAction(associationEnd)}

16. System Property Validation --- Translation to PNs • The association end is translated in a place of role type. • The create link action is semantically equivalent to an arc from the transition with the association end update toward the place specifying the association end. • The destroy link action is semantically equivalent to an arc from the association end place to the transition corresponding to the link action.

17. System Property Validation --- Resulting Conversion

18. Mapping OCL invariants to PROD logics • OCL invariant -> Temporal logic property T: OCL invariant->LTL property • The transformation for each object T(Context object:class inv:ocl-expr) = henceforth(T(ocl- expr)). • PROD grammar

19. OCL Expression Metamodel • Translation of OCL expressions

20. Mapping OCL invariants to PROD logics • literalExp -> unchanged when translated • Integer 1 or String “this a a LiteralExp” • navigationExp • T(object.associationEnd) = placeassociationEnd : field[0] = object • attributeExp • T(object.atribute) = U (placeDM*class : field[0] == object:field[attributeNumber])

21. Mapping OCL Operations on Collections to Temporal Logic Formulas

22. Mapping OCL invariants to PROD logics - Example • Property 1 The number of connected stations is limited to maxStation. • Property 1 expression in OCL context s:Server inv: s.connectedStation->size <= Server.maxStation • Property 1 expression in PROD # verify henceforth(card(connectedStation:field[0] == s) <= (placeDM*server:field[2]))

23. Mapping OCL invariants to PROD logics - Example • Property 2 Only connected stations can transmit messages. • Property 2 expression in OCL Context t:Station inv: Sever.allinstances()->forAll(s.connectedStation->excludes(t) implies t.transmittedMessages->isEmpty() • Property 2 expression in PROD • For each station t and for each server s write the property: #verify henceforth(connectedStation: (field[0] == s && field[1] == t) == empty implies (transmittedMessages: field[0] == t) == empty)

24. Related Work • Translation of OCL invariants to • Object-z • First-order predicate logic • Object-based temporal logic • Automatic translation of the OCL invariants to the LTL logic expressed in PROD syntax. • Provides a dedicated specification that takes the target’s tool (PROD) characteristics into account. • Spares the designer the hard effort of learning new formalisms to validate the modeling.

25. Conclusions • Systematic validation of the UML modeling without need for the user to know formal checking techniques. • The verification concerns both the correctness of the model construction and the faithfulness of the modeling. • Translation from OCL language to LTL properties. • Introduction of an object flow specification into the statechart, using predefined actions on the association ends.

26. Questions?