Aspect-Oriented Software Development (AOSD) Tutorial #10

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

2. Today: Interference among Aspects • Interference detection • Proving interference freedom • Error analysis • Usage guidelines for aspect libraries • Examples • CAPE and AOSD-EUROPE Aspect-Oriented Software Development (236608)

3. Interference Check – Example 1 General 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. Aspect-Oriented Software Development (236608)

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. Aspect-Oriented Software Development (236608)

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)) Aspect-Oriented Software Development (236608)

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)) Aspect-Oriented Software Development (236608)

7. Example 1– contd. For all S, (S ⊨ (PC⋀ PT)) → ((S+C) ⊨PT) For all S, (S ⊨ (RC⋀ PT)) → ((S+T) ⊨RC) • Statements to check: • KPCT OKCT • KRCT • KPTC OKTC • KRTC • Full verification and/or feasibility check? • Feasibility check is enough! RC and RT contradict! Note: full verification will also detect the problem… Aspect-Oriented Software Development (236608)

8. Interference Check – Example 2 General 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 passwords Adds 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. Aspect-Oriented Software Development (236608)

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) Aspect-Oriented Software Development (236608)

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)) Aspect-Oriented Software Development (236608)

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. Aspect-Oriented Software Development (236608)

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 Aspect-Oriented Software Development (236608)

13. Model for KREF check Additional variable: from E’s assumption E’s variables remain unchanged VAR --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) ; New assumption: RE⋀ PF New guarantee: RE Aspect-Oriented Software Development (236608)

14. Example 2– contd. • KREF check fails! • Model-checking result: counterexample – “bad” computation (= sequence of states violating the property) [see verification output file…] Aspect-Oriented Software Development (236608)

15. Example 2– counterexample Base Aspect ¬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 password sent unencrypted! … Aspect-Oriented Software Development (236608)

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 … Aspect-Oriented Software Development (236608)

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: KPABor KRAB For incremental method only! (for direct, error localization is problematic Aspect-Oriented Software Development (236608)

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… Aspect-Oriented Software Development (236608)

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” Aspect-Oriented Software Development (236608)

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! Aspect-Oriented Software Development (236608)

21. More about aspects… • A framework for aspect verification tools: The CAPE project • More applications of aspects: aosd-europe.net Aspect-Oriented Software Development (236608)