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: Guarantee: a card is never stuck in a machine forever. Formally:

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

7. Aspect-Oriented Software Development (236608) 7 Example 1– contd. Statements to check: Full verification and/or feasibility check?

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: Guarantee: a password is never sent unencrypted Formally:

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: Guarantee: if the security check is passed, the password is sent to the user Formally:

11. Aspect-Oriented Software Development (236608) 11 Example 2– contd. Check OK EF : Full verification and/or feasibility check?

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

16. Aspect-Oriented Software Development (236608) 16 Interference Elimintation Guidelines Aspect A interfers with B => Who is guilty? –A or B? What can be done? –Change the specification(s) –Change the advice implementation

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

18. Aspect-Oriented Software Development (236608) 18 Guidelines - Example Feasibility check fails => –Specifications have to be changed –Advice might have to be changed In ATM example:

19. Aspect-Oriented Software Development (236608) 19 Guidelines – Example2 Feasibility check succeeds => –Advice implementation has to be changed –Specifications might have to be changed In Security example:

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