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

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

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:

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

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

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:

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

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

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

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

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

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

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…

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:

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:

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