![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
En vedette
En vedette (19)
Similaire à Resg ph d_seminar2010_germansibay
Similaire à Resg ph d_seminar2010_germansibay (20)
Dernier
Dernier (20)
Resg ph d_seminar2010_germansibay
- 1. TexPoint fonts used in 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
- 8. Summary analysis requirements Behaviour Models
- 9. Proposal: Synthesis from Scenarios synthesis Behaviour Models scenarios scenario notation analysis requirements
- 16. Models and Scenarios b 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 Scenarios b d c d c (dc) ∞ b c … 0 1 2 . . . There is a trace that satisfies the model satisfies the eLSC eLSC
- 21. Does the model satisfy the eTS? Does its tree satify the eTS? b d c
- 24. Universal Triggered Scenario (uTS) Does this tree satify the uTS ? b d c NO
- 26. Synthesis from TS synthesis TS Behaviour model
- 27. Synthesis from this eTS d c b
- 31. MTS refinement preserves scenarios Refinements TS LTSs: Satisfy the scenario Synthesis MTS Characterises LTSs that satisfy the TS satisfies
- 32. Combining scenarios Synthesised MTSs Refinements TS Refinements TS Merge
- 33. Combining properties and scenarios Synthesised MTSs Refinements Refinements FLTL property TS Merge
- 34. Methodology Synthesis Feedback Elaboration Model Checking, Simulation, Animation Validation eTS FLTL properties uTS
Notes de l'éditeur
- 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.
- 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.
- The perception is that there are more drawbacks than advantages, leading to a low adoption by practitioners.
- 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.
- 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.
- This is a hard path.
- 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.
- 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).
- -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.
- -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.
- 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.
- 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.
- 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.
- Existential is not very expressive. It’s just an example In this case an example of a user that logs in and retrieves money.
- 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?
- 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.
- -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
- -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.
- 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.
- -
- Hablar del cambio de poder expresivo
- Now, let’s move to the synthesis problem. We want to build a BM from an TS.
- Several LTS satisfies the scenario
- 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…
- Model checkin
- 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.
- 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
- Combining scenarios is achieved by MTS’s merge.
- If they dont overlap they are inconsistent