1 / 22

Safety-Liveness Semantics for UML 2.0 Sequence Diagrams Radu Grosu SUNY at Stony Brook

Safety-Liveness Semantics for UML 2.0 Sequence Diagrams Radu Grosu SUNY at Stony Brook. Joint work with Scott A. Smolka. Scenario-Based Specifications. Convenient way of describing interaction among reactive systems, i.e.: Systems where termination is rather an error

dessa
Download Presentation

Safety-Liveness Semantics for UML 2.0 Sequence Diagrams Radu Grosu SUNY at Stony Brook

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. Safety-Liveness Semantics forUML 2.0 Sequence DiagramsRadu GrosuSUNY at Stony Brook Joint work with Scott A. Smolka

  2. Scenario-Based Specifications • Convenient way of describing interaction • among reactive systems, i.e.: • Systems where termination is rather an error • than an expected behavior. • Have become an integral partof all modern • software engineering design methods: • SDL and ROOM MSC (message sequence • charts), UML SD (sequence diagrams).

  3. Reactive Systems Commercial Aircraft Telecommunication Household devices Automobiles Nuclear Power Plants Medical devices

  4. UML 2.0 SD Simplified Syntax name of SD body of SD sd ack m n process name b process lifeline receive event send event message Positive SD: describes traces that are valid and should be possible

  5. neg sd nack m n c UML 2.0 SD Simplified Syntax negative qualification Negative SD: describes traces that are invalid and should not be possible

  6. sd init sd ack neg sd nack m n m n m n a b c High level SD (IOD) sd iod ack ref init ref ref nack UML 2.0 SD Simplified Syntax synchronous/asynchronous sequencing

  7. sd nsd neg sd ng sd nsd m n m n ng ref a neg a sd a sd b m m n n b a sd asd b a a ref b ref UML 2.0 SD Full Syntax sd asd m n alt

  8. m:n!a n:m?a Closed world semantics: rs Lang(rs) = {m:n!a n:m?a} UML 2.0 SD Semantics? sd rs m n a This is not a reactive system! What about asynchronous message passing?

  9. sd rs m n a Positive SD Semantics? tau transitions    rs m:n!a n:m?a Büchi automaton! L(rs) = {*m:n!a *n:m?a } What about refinement?

  10. sd rs sd rs m m n n b a Positive SD and Refinement?    rs m:n!a n:m?a ~m:n!a ~n:m?a  , liveness closure chaos closure Liveness Büchi automaton! L(rs) = {* ~m:n!a (,), * m:n!a * ~n:m?a (,), * n:m?a * m:n!a * n:m?a (,)}

  11.   nack neg sd nack n:m!c m:n?c m n c    nack n:m!c m:n?c ~n:m!c ~m:n?c , Negative SD Semantics? complement + safety closure Safety Büchi automaton! L(nack) = { , * n:m!c , * ~n:m!c (,), * n:m!c * ~m:n!c(,) }

  12.  ack sd iod ack ref init init ref nack   nack ref Positive SD: - remove all negative nodes and all their associated transitions.   ack init Negative SD: -turn negative nodes into accepting sink nodes. Others nonaccepting.   ack init nack  High Level SD Semantics

  13. piod  m:n!a n:m?a n:m!b n:m!b init ack      liod m:n!a n:m?a n:m!b m:n?c , ~m:n!a ~n:m?a ~n:m!b ~m:n!c , HSD Positive Semantics

  14. nack n:m!c n:m?c niod m:n!a n:m?a n:m!b n:m?b init ack  , ~m:n!a ~n:m?a ~n:m!c ~n:m?c siod n:m!c m:n!a n:m?a   n:m!b    n:m?b ~n:m?b HSD Negative Semantics

  15. HSD Semantics • Parallel composition of: • Liveness Büchi automaton • Safety Büchi automaton • Example: • Iod automaton: iod = liod  siod • Note: Lang(iod) = Lang(liod)  Lang(siod)

  16. SD Refinement • Definition: Let S1 and S2 be two SDs. Then: • -S1 S2 iff Lang(S1)  Lang(S2) • Theorem: Let S, T and U be three bounded • SD and assume that S* and T* are bounded, • too. Then: • if S  T then U S  U T • if S  T then (S)*  (T)* • if S  T then S + U  T + U and U + S  U + T • if S  T then S || U  T || U and U || S  U || T

  17. Sequential:  init ref init ref ack ref Alternative: ack ref  ack ref ref nack Examples of Refinement

  18. Star?  init ref init ref ack ref Star: init ref ref ack  ack ref ref init nack ref Examples of Refinement

  19. Related Work • PA and PO (Mauw, Alur, Muscholl, Peled, …): • Not compositional. Not interested in compositionality. • Live SC (Damm, Harel, Kugler): • Elegant, alternative AT solution. Departure from UML. • Triggered MSC (Cleaveland, Sengupta): • Prescriptive/constraint-based. Must preorder. • STAIRS (Haugen, Stoelen): • Open semantics. Not fully formalized. • Other semantics (Broy, Knapp, Krüger,…): • Also depart from closed world semantics.

  20. Conclusions • Presented an Automata-theoretic semantics that solves in asimple and elegant wayone of the main open questions about UML 2.0 SD: • How to assign a precise meaning to a set of SD without compromising refinement? • Provides a direct technique for checking SD refinement in a compositional way. • Supports the development ofa general purpose MC for property and refinement checking.

  21. Rough Complexity Analysis • Translation of HSD to Pos/Neg FA: • -linear time (in the size of the HSD). • Translation of Pos/Neg FA to Safe/Live BA: • -exponential due to flattening, • Complementation hard: • - double exponential due to BA. • In practice: • - avoid flattening for synchronous sequencing? • - special kind of BA with simple complementation.

More Related