Aspect-Oriented Software Development (AOSD) Tutorial #10 Interference among Aspects.

Aspect-Oriented Software Development (AOSD)

Tutorial #10

Interference among Aspects

Aspect-Oriented Software Development (236608)

2

Today: Interference among Aspects

• Interference detection

• Proving interference freedom

• Error analysis

• Usage guidelines for aspect libraries

• Examples

• CAPE and AOSD-EUROPE


3

Interference Check – Example 1General description:• Two aspects to be used in systems with remote

authorized access. • Aspect C treats communication failures:

If a communication failure occurs during an authorization process, or when a user is logged in, the user is automatically logged out (to enable re-login when the communication is restored)

• Aspect T prevents identity-theft:If a wrong password is provided in several consequent attempts of logging in, the aspect guarantees that the user is blocked.


4

Example 1– contd.• Example system - ATM system of a bank• ATM usage: (in a cycle)

– insert card– enter code (repeat until the correct code or “cancel” is

entered)– if permission is granted (i.e, the code was correct), enter a

request for the bank operation. The request is then processed by the system

• Point of view of the aspects: the card serves as a user-login, and code - as a password.

• In case of communication failure, if a card is stuck in the ATM machine, aspect C returns it to the user.

• Aspect T ensures stolen cards are stuck forever in the ATM.


5

Aspects Specifications – Aspect C• Assumption: the only case when a card can get

stuck in a machine is when a communication failure occurred while the card was in the machine.

• Formally:

PC = G(card_in → F( ￢ card_in ⋁ comm_fail))• Guarantee: a card is never stuck in a machine

forever.• Formally: RC = G(card_in → F( ￢ card_in))


6

Aspects Specifications – Aspect T• Assumption – reminder:

PT = G(card_stolen → G(card_stolen))

• Guarantee: if a stolen card is inserted, it is then stuck in a machine forever.

• Formally:

RT = G(card_in ⋀ card_stolen → G(card_in))


7

Example 1– contd.

• Statements to check:– KPCT OKCT

– KRCT

– KPTC OKTC

– KRTC

• Full verification and/or feasibility check? • Feasibility check is enough!

RC and RT contradict!

For all S, (S ⊨ (PC ⋀ PT)) → ((S+C) ⊨ PT)

For all S, (S ⊨ (RC ⋀ PT)) → ((S+T) ⊨ RC)

Note: full verification will also detect the

problem…


8

Interference Check – Example 2General description:• Two aspects – part of a security-aspects library, to

be used in password-protected systems• Aspect E encrypts passwords

Whenever a password is sent from the login screen of the system, it is encrypted (there is also a decryption part, but we ignore it here)

• Aspect F for retrieving forgotten passwordsAdds a button to report that the password is forgotten. When the button is pressed, security questions are asked. If the answers are correct, the password is sent to the user.


9

Aspects Specifications – Aspect E• Assumption: passwords are sent only from the

login screen

• Formally:

PE = G (psw_send ↔ login_psw_send)

• Guarantee: a password is never sent unencrypted

• Formally:

RE = G (psw_send → encrypted_psw)


10

Aspects Specifications – Aspect F• Assumption: the aspect does not need to

assume anything about the base system• Formally:

PF = true• Guarantee: if the security check is passed, the

password is sent to the user• Formally:

RF = G((button_pressed ∧ quest_answered) → F(psw_send))


11

Example 2– contd.

• Check OKEF:

– KPEF – trivially true

– KREF :

For all S,

(S ⊨ G (psw_send → encrypted_psw)∧ true) →

(S+F ⊨ G (psw_send → encrypted_psw))

• Full verification and/or feasibility check?

• Feasibility check is not enough!

Specifications do not contradict.


12

Model for KREF check

Differs from the model for F’s verification:

• Additional base variables defined (required for E’s guarantee)

• Treatment of these variables in F’s transitions definitions (F does not modify variables it is unaware of)

• Assumption is (RE ⋀ PF), and guarantee - RE


13

Model for KREF checkVAR --BASE psw_send : boolean ;

button_pressed : boolean ; encr_psw : boolean ;

…TRANS (pcF = 1) -> next(pcF = 2) & next(button_pressed) & next(!mail_psw_send) & next(!

psw_send) & (next(encr_psw) = encr_psw);TRANS (pcF = 2) ->

next(pcF = 3) & (next(psw_send) = quest_answered) & (next(mail_psw_send) = quest_answered) & next(! button_pressed) & next(!quest_answered) & (next(encr_psw) = encr_psw);

TRANS (pcF = 3) -> next(pcF = 4) & next(!mail_psw_send) & next(!quest_answered) & next(!psw_send) & next(! button_pressed) & (next(encr_psw) = encr_psw);

…LTLSPEC --BASE

G (psw_send -> encr_psw) ; LTLSPEC --AUGMENTED

G (psw_send -> encr_psw) ;

Additional variable: from E’s assumption

New assumption: RE ⋀ PF

E’s variables remain unchanged

New guarantee: RE


14

Example 2– contd.

• KREF check fails!

• Model-checking result: counterexample – “bad” computation (= sequence of states violating the property)

[see verification output file…]


15

Example 2– counterexample

¬p_send b_p

¬encr ¬q_a

¬mp_snd

¬p_send b_p

¬encr ¬q_a

¬mp_snd

¬p_send b_p

¬encr q_a

¬mp_snd

p_send ¬b_p ¬encr ¬q_a

mp_snd

Base Aspect

…

…password sent unencrypted!


16

Error analysis

• Aspects in one library may interfere!• We might never want to add all the aspects

into one system! [for instance: several variants of the same aspect appear in the library…]

• Interference detection => – Interference elimination OR– Usage guidelines

sometimes also: cooperation

relationship …


17

Interference Elimintation Guidelines

Aspect A interferes with B =>

• Who is guilty?– A or B?

• What can be done?– Change the specification(s)– Change the advice implementation

Follows immediately from the stage of the failure: KPAB or KRAB

For incremental

method only! (for direct,

error localization is problematic


18

Usage Guidelines

For each pair (A,B) from the library:

• Can A be woven before B?

• B before A?

• If not – why?

• More refined guidelines might be possible in the future…


19

Analysis and Guidelines - Example• Feasibility check fails =>

– Specifications have to be changed– Advice might have to be changed

• In ATM example:– Change the specification(s)!– For example:

RC = G(card_in → F(special_event ∨ ￢ card_in))

RT = G[(card_in ⋀ card_stolen → G(card_in)) ⋀

(card_stolen → special_event)]

Special event => a card will remain in the ATM regardless of

communication failure

card stolen – a possible

“special event”


20

Analysis and Guidelines – Example2• Feasibility check succeeds =>

– Advice implementation has to be changed

– Specifications might have to be changed

• In Security example:– Change the advice!

– For example:

Change F to bring the user to a login screen and offer to enter the new password

– Result: Specifications stay the same, but OKFE now holds.

Note: OKEF still does not!


21

More about aspects…

• A framework for aspect verification tools:

The CAPE project

• More applications of aspects:

aosd-europe.net

Aspect-Oriented Software Development (AOSD) Tutorial #10 Interference among Aspects.

Documents

Transcript of Aspect-Oriented Software Development (AOSD) Tutorial #10 Interference among Aspects.