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

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

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

5. 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: P C = G(card_in → F( ￢ card_in ⋁ comm_fail)) Guarantee: a card is never stuck in a machine forever. Formally: R C = G(card_in → F( ￢ card_in))

6. Aspect-Oriented Software Development (236608) 6 Aspects Specifications – Aspect T Assumption – reminder: P T = G(card_stolen → G(card_stolen)) Guarantee: if a stolen card is inserted, it is then stuck in a machine forever. Formally: R T = G(card_in ⋀ card_stolen → G(card_in))

7. Aspect-Oriented Software Development (236608) 7 Example 1– contd. Statements to check: –KP CT OK CT –KR CT –KP TC OK TC –KR TC Full verification and/or feasibility check? Feasibility check is enough! R C and R T contradict! For all S, (S ⊨ (P C ⋀ P T )) → ((S+C) ⊨ P T ) For all S, (S ⊨ (R C ⋀ P T )) → ((S+T) ⊨ R C ) Note: full verification will also detect the problem…

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

9. Aspect-Oriented Software Development (236608) 9 Aspects Specifications – Aspect E Assumption: passwords are sent only from the login screen Formally: P E = G (psw_send ↔ login_psw_send) Guarantee: a password is never sent unencrypted Formally: R E = G (psw_send → encrypted_psw)

10. Aspect-Oriented Software Development (236608) 10 Aspects Specifications – Aspect F Assumption: the aspect does not need to assume anything about the base system Formally: P F = true Guarantee: if the security check is passed, the password is sent to the user Formally: R F = G((button_pressed ∧ quest_answered) → F(psw_send))

11. Aspect-Oriented Software Development (236608) 11 Example 2– contd. Check OK EF : –KP EF – trivially true –KR EF : 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. Aspect-Oriented Software Development (236608) 12 Model for KR EF 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 (R E ⋀ P F ), and guarantee - R E

13. Aspect-Oriented Software Development (236608) 13 Model for KR EF check 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) ; Additional variable: from E’s assumption New assumption: R E ⋀ P F E’s variables remain unchanged New guarantee: R E

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

15. Aspect-Oriented Software Development (236608) 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 BaseAspect … … password sent unencrypted!

16. 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 …

17. 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: KP AB or KR AB For incremental method only! (for direct, error localization is problematic

18. 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…

19. 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: R C = G(card_in → F(special_event ∨￢ card_in)) R T = 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. 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 OK FE now holds. Note: OK EF still does not!

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