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

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

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…

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: P E = G (psw_send ↔ login_psw_send) Guarantee: a password is never sent unencrypted Formally: R E = 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: 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))

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.

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

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: KP AB or KR AB 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: 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”

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!

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