Download to read offline
More Related Content
Similar to Resg ph d_seminar2010_germansibay
![5G Explained! A High Level Overview [Introduction]](https://cdn.slidesharecdn.com/ss_thumbnails/5gexplainedahighleveloverview-260119165306-cc137a3e-thumbnail.jpg?width=640&height=640&fit=bounds)
Resg ph d_seminar2010_germansibay
- 1. TexPoint fonts usedin EMF. Read the TexPoint manual before you delete this box.: A A A A A A A From Triggered Scenarios to Modal Transition System German Sibay
- 2. Agenda Motivation PreviousWork Our Work Conclusion Future Work
- 3. Motivation Software iseverywhere Nuclear power stations Mobile phones Banking Design and development of software is hard Models are key in engineering (abstraction) Behaviour Models analysis requirements
- 4. Behaviour Models ProsAbstraction Build complexity: model < system Basis for (semi)automatic analysis techniques: Model checking Simulation Analysis of behaviour previous to construction Early detection Cons Requires expertise Intra-agent behaviour specification Hard to build
- 5. Behaviour Models Perception: cons > pros Possible cause of low adoption by practitioners
- 6. What do practitionersuse? Scenario notations, Use Cases Inter-agent specification Simple syntax Intuitive semantics MSC, UML Interaction Diagram User Retrieve money Pay Bills Actuator
- 7. Scenario notations pros: Easy syntax, intuitive semantic Popular among practitioners cons : Generally informal (no suitable for formal analysis) Example of execution (not comprehensive) Limited expressiveness
- 8. Summary analysis requirements Behaviour Models
- 9. Proposal: Synthesis fromScenarios synthesis Behaviour Models scenarios scenario notation analysis requirements
- 10. Our Contribution NovelScenario Language with Trigger Tree based semantics, allows existential and universal with trigger Synthesis algorithm for the new Language Characterising all models that satisfy the scenario synthesis Behaviour Models scenario notation
- 11. Scenario Language: BasicChart Example of execution (MSC, UML Seq. Diag.) Partial order semantics Defines a finite language of finite words { pwd verify verifying wait ok , pwd verify wait veryfing ok }
- 12. Scenario Language withPrechart (or Trigger) Live Sequence Chart (LSC): Existential Live Sequence Chart ( eLSC ) Example of a system run ≈ MSC Universal Live Sequence Chart ( uLSC ) Rule for all system runs ≈ Property
- 13. Existential Live SequenceChart (eLSC) Trace based semantics: interaction described by the scenario must be present somewhere in the trace A set of traces satisfy if at least one satisfies
- 14. Universal Live SequenceChart (uLSC) Prechart Mainchart … pwd verify nok pwd verify nok pwd verify nok x pwd verify ok … Trace based semantics Every time the Prechart holds, the Mainchart must follow next A set of traces satisfy if all satisfy
- 15. Labelled Transition System(LTS) as a set of traces A LTS defines a set of traces LTS satisfy the scenario if its set of traces do it: - uLSC : All traces satisfy the scenario - eLSC : At least one trace satisfy the scenario
- 16. Models and Scenariosb d c d c (dc) ∞ b c … x 0 1 2 . . . A trace does not satisfy the model does not satisfy the uLSC uLSC
- 17. Models and Scenariosb d c d c (dc) ∞ b c … 0 1 2 . . . There is a trace that satisfies the model satisfies the eLSC eLSC
- 18. New language: MotivationeLSC not very expressive. Just an example of a user that logs in and retrieves money
- 19. New language: MotivationuLSC may be too restrictive … pwd verify wait verifying wait ok getBalance() … x Every time the user logs in, must try to retrieve money (and succeed)
- 20. Existential Triggered Scenario(eTS) P M Execution tree based semantics: Every time the Trigger holds, there must exists an execution branch where the Mainchart holds next
- 21. Does the modelsatisfy the eTS? Does its tree satify the eTS? b d c
- 22. eTS: Summary Ruleover entire system-to-be behaviour Requires possibility of Mainchart when Prechart holds Complementary to uLSC uLSC – LTL formula eTS - CTL formula Semantics ≈ Use Cases with preconditions
- 23. Universal Triggered Scenario(uTS) P M Execution tree based semantics: Every time the Trigger holds, only the Mainchart can come next. Also every word in the Mainchart must be in at least one branch
- 24. Universal Triggered Scenario(uTS) Does this tree satify the uTS ? b d c NO
- 25. TS extension Conditionsin the Trigger: Fluent Propositional Logic formula u userLoggedIn
- 26. Synthesis from TSsynthesis TS Behaviour model
- 27. Synthesis from thiseTS d c b
- 28. Synthesising a LTS Several LTS satisfy the scenario Choosing one is taking an arbitrary decision Choosing one that characterises them all (through simulation or trace inclusion) does not work
- 29. Solution: synthesise aModal Transition System (MTS) Extend LTS with an extra set of transitions Required or Must transitions Possible or May transitions An LTS L is an implementation of an MTS M if all required behaviour in M is in L, and all behaviour in L is possible in M request reply request? reply? request reply request reply request reply
- 30. MTS have arefinement relation: “more defined than” MTS refinement preserves implementation Solution: synthesise a MTS request? reply? Implementations (LTS) request reply request? reply? Refined + - request reply request reply request reply
- 31. MTS refinement preservesscenarios Refinements TS LTSs: Satisfy the scenario Synthesis MTS Characterises LTSs that satisfy the TS satisfies
- 32. Combining scenarios SynthesisedMTSs Refinements TS Refinements TS Merge
- 33. Combining properties andscenarios Synthesised MTSs Refinements Refinements FLTL property TS Merge
- 34. Methodology Synthesis FeedbackElaboration Model Checking, Simulation, Animation Validation eTS FLTL properties uTS
- 35. Summarising New scenario-basedlanguage based on LSC with branching semantic TS have existential with trigger Existential Fits with Use Case w/Preconditions MTS Synthesis algorithm No arbitrary choice of LTS Characterisation of all LTSs satisfying TS Allows evolution through refinement Allows integrating multiple sources (merge) Applicable to other scenario notations
- 36. Future Work DistributedSynthesis Problems of composition of MTS (not complete) Distributed synthesis with trigger is tricky Synthesise using scenarios and Architecture Diagrams
Editor's Notes
- #4 First let’s get in context. As we all know, nowadays Software is everywhere and designing and developing reliable software has shown to be a difficult task. To deal with complexity we can do as other engineering do: build models, an abstraction of what is intended to build. So, this approach tries to build models from requirements and then analyse them.
- #5 So besides being an abstract, less complex representation of the system, a good thing about models is the automatic techniques for analysing them, such as model checking. Which allows early design flaw detection. However, the drawbacks are that their construction requires expertise. These kinds of intra-agent specification tend to be harder for practitioner. They are hard to build.
- #6 The perception is that there are more drawbacks than advantages, leading to a low adoption by practitioners.
- #7 But what do practitioners use? Scenario notations like this one. They are an iter-agent specification showing an example of system components interacting. Their simple syntax and intuitive semantics made this kind of notation very popular among practitioners. Examples are Message Sequence Charts and UML Interaction Diagram.
- #8 So Scenarios are easy to build and understand, but most of them are informal and then unsuitable for formal analysis. They’re just an example of system execution: not a comprehensive behaviour specification. And have a limited expressive power.
- #9 This is a hard path.
- #10 So one approach that has been around for a while is this one From the scenarios (popular among practitioners) automatically build (that is synthesise) the BM. Several scenario-based languages and behaviour model notations exists It’s necessary a sound scenario language so the synthesis is possible, and a powerful one to say something interesting.
- #13 As Scenario Language we focused on a simplified version of LSC a formal and powerful scenario language (and popular). LSC allow two modalities: Existential an Universal. Existential describe an interaction that must be present in the system (example of a portion of a run), like a MSC. I will talk about them later. Universals impose a rule over all system runs (more like a property).
- #14 -An eLSC is just a basic chart like MSC basic charts in a dashed box. -The Semantic is defined with respect to traces (infinite sequence of event representing a system run). So a trace satisfies if at some point the trace shows the interaction described by the scenario. -Events not restricted by the diagram can happen in between. The events restricted by the diagram are contains the events appearing in the chart. More events can be added to the restricted ones with a special notation. -Finally, the satisfaction relation is defined for set of traces: A set of traces satisfy if at least one satisfies. -Example: for example in this case, in white we have events not restricted by the diagram, so we don’t care about them. In this run the user logs in and successfully retrieves money, which is the sequence described by the diagram so it satisfy.
- #15 -An uLSC has 2 Basic Charts. A Prechart, above in the dashed area and a Mainchart in the box below the Prechart. -The restricts area is optional (also in the existential live sequence chart), means that those messages are also restricted by the diagram and so they cannot happen in between. -The Semantics is defined again, with respect to traces (considering only the events restricted by the diagram) :Every time the Prechart holds, the Mainchart must follow (inmediately) next. -Example: this example is saying that if the user enter the password 3 times and it’s not successfully verified by the bank (That is the Prechart), then the ATM retains the card (Mainchart). -A set of traces satisfy if all its traces satisfy. -Trace example: In this case, the prechart holds (the user tries unsuccesfully to log in), and after that the user inserts the password again. So, as the next restricted event after the prechart is not the one described by the Mainchart, this trace violates the LSC.
- #16 Let’s talk a little about models now. -A Labelled Transition System or LTS from now on, is behavioural model formalism. It’s a FSM with labelled transitions. -An LTS defines a set of traces so we can ask whether a LTS satisfies a LSC: Again: Satisfies a universal iff all its traces do it, Satisfy an existential iff at least one satisfies.
- #17 To make things clear, another example. Let’s see if this model satisfy this uLSC. Every time b happens, dc must come next. Animation: b [ Prechart holds ] d c d c [ lets consider the trace with a loop between state 1 and 2]. This trace satisfy as b is only seen once and after that dc happens. Another trace now: b [ Prechart holds] c [ this is not the Mainchart, and no matter what event comes next the Mainchart is not satisfy after the Precahrt and c is a restricted event] So, as there is one trace that do not satisfy, the model does not satisfy the chart.
- #18 However if we consider a similar scenario but with Existential semantic: This says that bdc must be present in some trace. The first trace satisfy as bdc is present. We have still don’t know if the second one satisfies. For example if we loop between state 0 and 1 we will never have a bdc and it will not satisfy, but anyway: as there is a trace that satisfy, the model satisfy the chart.
- #19 Existential is not very expressive. It’s just an example In this case an example of a user that logs in and retrieves money.
- #20 When the user logs in, he or she must always request (and get) money. He must attempt to retrieve money and succed. What if he doesnt not try or he cant?
- #21 New modality: Existential with Prechart LSC. -Very similar to universal. The Mainchart is in a dashed box. -It’s semantic is execution tree based. -Whenever the Prechart holds (or is satisfied), then, for every word gamma in the Mainchart, there should be a system run from that point on such that gamma occurs (always restricted to Sigma). NEW: Every branch in the execution tree is in particular a trace, so if we consider the uLSC semantics over an execution tree it means that every time the prechart holds, from that point on every branch the Mainchart must hold next.
- #22 -If we consider this Model, that’s it’s execution tree. -If we take this branch, b happens, that’s the prechart, And there is a branch where dc comes next. -Note that there is a branch where dc is not next, however this still satisfy. It wont satisfy if we consider a universal LS
- #23 -Semantics similar Use Cases: The Prechart works as the Preconditions in the Use Cases. When the Preconditions Holds (i.e. the Prechart holds) the USE CASE is initiated, that is the Mainchart. - uLSC can be seen as an LTL formula while the new language is a formula in CTL.
- #24 Similar to uLSC is uTS. The universal version of the Triggered Scenarios. - We use the same syntax as uLSC -It’s semantic is execution tree based. -Has the same semantics as uLSC when Mainchart has only one word.
- #25 -
- #26 Hablar del cambio de poder expresivo
- #27 Now, let’s move to the synthesis problem. We want to build a BM from an TS.
- #28 Several LTS satisfies the scenario
- #29 Comentario Sebas: no se puede como en terminos lineales eliminar transiciones .. Por que no funciona? Con lineales funciona? Pensar... We can think about synthesising the bigest in terms of trace inclusion that satisfies, and then, by removing transitions We get other models that satisfies, but that doesnt work as the resulting model may not satisfy the scenario because That transition being removed could be the only way that an obligation can be performed. Is there a way to know which transitions can be removed knowing that the resulting transition still satisfies… No. Because there is no distintion between required and possible transitions….which leads me to…
- #30 Model checkin
- #31 The MTS can distinguish the required behaviour. They have a refinement relation “more defined than”. A MTS defines a set of LTS, it’s refinements where all the transitions are required. The refinement relation Preserves implementations.
- #32 So we have a syntehsis algorithm that builds a MTS so that it’s implementations satisfy the scenario. And because o Completeness is a very important issue. Because I can guarantee that The model is as least refined as possible. No arbitrary decission was taken. The algorithm takes a scenario and builds the least refined MTS which implementations satisfy
- #33 Combining scenarios is achieved by MTS’s merge.
- #34 If they dont overlap they are inconsistent