1 / 26

Formal Validation with OCL

Formal Validation with OCL. Thouraya Bouabana-Tebibel Algeria, 2006. Introduction. System validation UML Lacks of well-defined semantics UML 2.0 Remains informal Lack of tools for automatic analysis and validation Model Checking. Introduction.

karik
Download Presentation

Formal Validation with OCL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related