Aspect-Oriented Software Development (AOSD) Tutorial #10 Interference among Aspects.
Post on 16-Dec-2015
238 Views
Preview:
Transcript
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 1General 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.
• Statements to check:– KPCT OKCT
– KRCT
– KPTC OKTC
– KRTC
• Full verification and/or feasibility check? • Feasibility check is enough!
RC and RT contradict!
For all S, (S ⊨ (PC ⋀ PT)) → ((S+C) ⊨ PT)
For all S, (S ⊨ (RC ⋀ PT)) → ((S+T) ⊨ RC)
Note: full verification will also detect the
problem…
Aspect-Oriented Software Development (236608)
8
Interference Check – Example 2General 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 passwordsAdds 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 checkVAR --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: RE ⋀ PF
E’s variables remain unchanged
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
¬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
Base Aspect
…
…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: KPAB or 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!
top related