Modeling and Composing Scenario-Based Requirements with Aspects

Scenario Modeling With Aspects 1

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

• validation of the composition of aspectual and non-aspectual requirements should better be done at the requirements stage, and not later in the development


requirements

aspectual scenariosnon-aspectual scenarios

non-aspectual FSMs aspectual state machines

compose the FSMs

Simulate and validate system requirements

UML sequence diagrams

IPSs

SMPSs


Example – Parking System

1. Analyze the requirements build use case diagram

enter

exit

pay

driver


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”


Parking System(contd.)Exiting with paid ticket :

barrier driver exit machine data record

InsertTicket(t)

CheckTicket(t)

RecordTransaction(t)EjectTicket(t)

Open

TakeTicket(t)

SensorValidateExit

Close

Drive



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”


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


Parking System(contd.)Machine is broken :

driver | machine supervisor

| Action( | a)

| CannotRespond

AlertSupervisor( | a)

DisplayErrorMsg

message role

lifeline role



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


FSM Synthesis Example

A B C

s1

s1

s1a/

r/

p/qs/t b/

A B C

s1

s1

a

t

b

q

s

p

pq

r

ts

12


Parking System(contd.)Example : FSM for Exit Machine

t1

__t2__

entry/CheckTicket(t)

t3

t4

InsertTicket(t)

/ RecordTransaction(t); EjectTicket; Open

TakeTicket

SensorValidatedExit / Close



5. Construct state machines from IPSs for the aspectual scenarios :

Synthesize SMPSs from IPSs by the same algorithm as FSMs were synthesized from sequence diagrams


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)


Parking System(contd.)Example : SMPS for | Machine

| s1

| CannotRespond / AlertSupervisor( | a);

DisplayErrorMsg| s2

| s3| Action ( | a)



6. Compose FSMs with SMPSs :

6.1. Instantiate SMPSs to prepare them to merge with FSMs

6.2. Merge SMPSs with FSMs


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)


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|s1 |s2 |s3

{|s1, |s2, |s3} t = [ |s1, |s2, |s3]

| s2

| s3


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 t1 t2 t3

| s1 {t1, t2, t3}


Parking System(contd.)Example : Instantiation of SMPS for | Machine, for merge to Exit Machine

| s1

| CannotRespond / AlertSupervisor( | a);

DisplayErrorMsg

| s2

| s3| Action ( | a)

t1

__t2__


t3t4

InsertTicket(t)

TakeTicket



1. |s1 t1

2. |s2 t2

3. |Action (|a) InsertTicket

4. |a t

5. |CannotRespond timeout

Isn’t part of Exit Machine FSM !


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).


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


Merging state spaces (illustration)

|s1

|s2

|s3

|s4

t1

t2

t3

t4

|s5

φ

Ms Mf

t1

t2

|s1 |s4

t3

|s5 |s4t4

|s3

M


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


Merging transition spaces (illustration)

|s1

|s2

|s3

|s4

t1

t2

t3

t4

|s5

φ

Ms Mf

t1

t2

|s1 |s4

t3

|s5 |s4t4

|s3

M

m1

m1

m2

m3

m4

m5

m4

m6m1

m2

m5

m3

m4

m6

m1: (|s1,t4)

m3: (|s3,|s4)

m4: (|s4,|s5)

m5: (t1,|s4)

m6: (|s4,t4)


Parking System(contd.)Example : FSM for Exit Machine

t1

__t2__


t3

t4

InsertTicket(t)


TakeTicket


|s3timeout / AlertSupervisor(t); DisplayErrorMsg


Another Possible Algorithmrequirements

aspectual scenariosnon-aspectual scenarios

UML sequence diagrams

IPSs

instantiated aspectual scenarios

merge the scenarios

synthesize the FSMs

Simulate and validate system requirements


Merging scenarios illustrationa:A b:B

|p

q

a:A b:B c:C

|r

a:A b:B

m2

m5

c:C

m1

m3

m4m5

m4

m3

q

m1

m2

“IN” integration


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


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


References

1. J.Araujo, J.Whittle, D.-K.Kim “Modeling and Composing Scenario-based Requirements with Aspects”

2. J.Whittle, J.Araujo, “Scenario Modeling with Aspects”

Documents

Modeling and Composing Scenario-Based Requirements with Aspects