1 / 31

Modeling and Composing Scenario-Based Requirements with Aspects

Modeling and Composing Scenario-Based Requirements with Aspects. Lecture by Emilia Katz. Motivation. scenario-based specifications are common for reactive systems (like library system from the previous lecture…) crosscutting requirements then are also described by scenarios

dragon
Télécharger la présentation

Modeling and Composing Scenario-Based Requirements with Aspects

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. Modeling and Composing Scenario-Based Requirements with Aspects Lecture by Emilia Katz Scenario Modeling With Aspects

  2. Motivation • scenario-based specifications are common for reactive systems (like library system from the previous lecture…) • crosscutting requirements then are also described by scenarios • validation of the composition of aspectual and non-aspectual requirements should better be done at the requirements stage, and not later in the development Scenario Modeling With Aspects

  3. UML sequence diagrams requirements IPSs non-aspectual scenarios aspectual scenarios non-aspectual FSMs aspectual state machines SMPSs compose the FSMs Simulate and validate system requirements Scenario Modeling With Aspects

  4. Example – Parking System 1. Analyze the requirements  build use case diagram enter pay driver exit Scenario Modeling With Aspects

  5. Parking System(contd.) 2. Define non-aspectual scenarios • Many possible scenarios : • - enter scenarios : parking lot has space / has no space • - exit scenarios : driver inserts/doesn’t insert ticket, ticket paid/not paid; regular user types in PIN-code; etc. • - payment scenarios : driver inserts ticket and correct sum of money; driver adds money to PIN card; etc. • We will chose, for example, “exiting with paid ticket” Scenario Modeling With Aspects

  6. Parking System(contd.) Exiting with paid ticket : barrier driver exit machine data record InsertTicket(t) CheckTicket(t) RecordTransaction(t) EjectTicket(t) Open TakeTicket(t) Drive SensorValidateExit Close Scenario Modeling With Aspects

  7. Parking System(contd.) 3. Define aspectual scenarios • Many possible scenarios : • - Machine is broken • - Ticket cannot be read • - Incorrect PIN card; etc. • We will choose, for example, “machine is broken” Scenario Modeling With Aspects

  8. Interaction Pattern Specification (IPS) • Defines a pattern of interaction between its participants in terms of roles of two types : Lifeline and Message • Instantiation : assigning concrete model elements to roles Scenario Modeling With Aspects

  9. Parking System(contd.) lifeline role Machine is broken : driver | machine supervisor | Action( | a) | CannotRespond message role AlertSupervisor( | a) DisplayErrorMsg Scenario Modeling With Aspects

  10. Parking System(contd.) 4. Synthesize FSMs from sequence diagrams for the non-aspectual scenarios • For every object : • Construct an FSM from a diagram it is involved in • Update it with information from all the other diagrams Scenario Modeling With Aspects

  11. FSM Synthesis Example A A B C B C a s1 p s1 q s t r b s1 s s1 t p q 1 a/ 2 s1 s/t b/ p/q r/ Scenario Modeling With Aspects

  12. Parking System(contd.) Example : FSM for Exit Machine t1 InsertTicket(t) __t2__ entry/CheckTicket(t) / RecordTransaction(t); EjectTicket; Open t3 SensorValidatedExit / Close TakeTicket t4 Scenario Modeling With Aspects

  13. Parking System(contd.) 5. Construct state machines from IPSs for the aspectual scenarios : Synthesize SMPSs from IPSsby the same algorithm as FSMs were synthesized from sequence diagrams Scenario Modeling With Aspects

  14. State Machine Pattern Specification (SMPS) • Defines a pattern of state-based behavior between its participants in terms of roles of two types : State roles and Transition Roles • Instantiation : assigning concrete model elements to roles (will be done at the merging step) Scenario Modeling With Aspects

  15. Parking System(contd.) Example : SMPS for | Machine | s1 | Action ( | a) | s3 | CannotRespond / AlertSupervisor( | a); DisplayErrorMsg | s2 Scenario Modeling With Aspects

  16. Parking System(contd.) 6. Compose FSMs with SMPSs : 6.1. Instantiate SMPSs to prepare them to merge with FSMs 6.2. Merge SMPSs with FSMs Scenario Modeling With Aspects

  17. Instantiation of SMPS • The goal : join points (parallel to required-provided definitions) • Mapping state roles and transition roles • Transition roles : one-to-one mapping • State roles : many-to-many mapping (possible); merging directives are required in case of non one-to-one mapping (to support automatic merging) Scenario Modeling With Aspects

  18. Instantiation of SMPS(contd.) : merging directives • 1.Many(abstract states)-to-one(concrete state) mapping • the image state becomes composite state • the state roles are its substates • transitions directed to (/from) the image state are redirected towards (/away from) one of its new substates {|s1, |s2, |s3}  t = [ |s1, |s2, |s3] | s1 | s3 |s2 |s3 |s1 | s2 Scenario Modeling With Aspects

  19. Instantiation of SMPS(contd.) : merging directives • 2.One(abstract)-to-many(concrete) mapping • for every transition directed to (/from) the state role, choose the target (/source) state from the states in the image of the state role | s1 t2 t3 t1 | s1  {t1, t2, t3} Scenario Modeling With Aspects

  20. Parking System(contd.) Example : Instantiation of SMPS for | Machine, for merge to Exit Machine t1 | s1 InsertTicket(t) | s3 __t2__ entry/CheckTicket(t) | Action ( | a) | CannotRespond / AlertSupervisor( | a); DisplayErrorMsg | s2 / RecordTransaction(t); EjectTicket; Open SensorValidatedExit / Close 1. |s1 t1 2. |s2  t2 3. |Action (|a)  InsertTicket 4. |a  t 5. |CannotRespond  timeout t4 t3 TakeTicket Isn’t part of Exit Machine FSM ! Scenario Modeling With Aspects

  21. Merging SMPSs with FSMs • The goal : simulate aspect advice application • Merge state spaces • Merge transition spaces(note : the algorithm provided results in duplicated transitions, in some cases. Removing the duplicates is left to the implementer). Scenario Modeling With Aspects

  22. Merging SMPSs with FSMs : merge state spaces • Let Ms be SMPS, Mf be FSM, φ – instantiation mapping for Ms. M be the merged FSM. • s - state of Mf s - state of M, but : • s - state of Mf, and s = φ (a set of state roles) s becomes a composite state with those roles as substates • s - state of Ms, and : |φ(s)| = 0 s – state of M Scenario Modeling With Aspects

  23. Merging state spaces (illustration) φ t1 |s1 t1 t2 |s3 |s2 t2 |s1 |s4 |s3 t3 t3 |s4 t4 t4 |s5 |s4 |s5 Ms Mf M Scenario Modeling With Aspects

  24. Merging SMPSs with FSMs : merge transition spaces • Let Ms be SMPS, Mf be FSM, φ – instantiation mapping for Ms. M be the merged FSM. • m=(s,s’) - transition of Mf m - transition of M, but if s (/s’) is a composite state, then m is redirected from(/to) a substate of s (/s’) according to merging directives • m=(s,s’) - transition of Ms, and |φ(s)| = |φ(s’)| = 1m – transition of M • m=(s,s’) - transition of Ms, and |φ(s)| > 1 or |φ(s’)| > 1 m – transition of M, but m is redirected to be from(/to) a member of φ(s) (/ φ(s’)) according to merging directives Scenario Modeling With Aspects

  25. Merging transition spaces (illustration) φ t1 |s1 t1 m5 m1 m5 t2 |s3 m3 |s2 t2 |s1 |s4 m2 m4 m2 |s3 m1 t3 m4 m3 m6 m1: (|s1,t4) m3: (|s3,|s4) m4: (|s4,|s5) m5: (t1,|s4) m6: (|s4,t4) m1 t3 |s4 t4 t4 m4 |s5 |s4 m6 |s5 Ms Mf M Scenario Modeling With Aspects

  26. Parking System(contd.) Example : FSM for Exit Machine t1 InsertTicket(t) timeout / AlertSupervisor(t); DisplayErrorMsg |s3 __t2__ entry/CheckTicket(t) / RecordTransaction(t); EjectTicket; Open t3 SensorValidatedExit / Close TakeTicket t4 Scenario Modeling With Aspects

  27. Another Possible Algorithm requirements IPSs non-aspectual scenarios aspectual scenarios UML sequence diagrams instantiated aspectual scenarios merge the scenarios synthesize the FSMs Simulate and validate system requirements Scenario Modeling With Aspects

  28. Merging scenarios illustration a:A b:B a:A b:B c:C |p m1 q |r m2 q a:A b:B c:C “IN” integration m1 m3 m2 m4 m3 m5 m4 m5 Scenario Modeling With Aspects

  29. Compare the Approaches • Composition at the scenario level  • the requirements engineer does not need to see the state machines • complicated : the user must provide composition operators that describe interleaving of the messages of the different scenarios • Composition at the FSMs level  • additional flexibility in describing the nature of the composition : states that are not specified in the scenarios can appear Scenario Modeling With Aspects

  30. Summary • The innovation : checking requirements compatibility immediately at the requirements stage • Future work directions : • - scalability of the system (maybe,provide default bindings) • - use the result of the simulation step to augment and correct the scenario models • Existing automatization : a Rational Rose tool for creating and instantiating Pattern Specifications Scenario Modeling With Aspects

  31. References • J.Araujo, J.Whittle, D.-K.Kim “Modeling and Composing Scenario-based Requirements with Aspects” • J.Whittle, J.Araujo, “Scenario Modeling with Aspects” Scenario Modeling With Aspects

More Related