Upload
monita
View
23
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Tom Maibaum (with Naza Aguirre, Paulo Alencar). Architecting Aspects: or Why you always knew aspect weaving was colimit construction. Introduction. Aspect oriented programming (AOP) focuses on an important issue: - PowerPoint PPT Presentation
Citation preview
Architecting Aspects:
orWhy you always knew aspect
weaving was colimit construction
Tom Maibaum
(with Naza Aguirre, Paulo Alencar)
28 Apr 2006 LES/PUC-Aspects 2
Introduction
Aspect oriented programming (AOP) focuses on an important issue:Not all concerns in program design map easily onto
the functional structure of programs.
AOP screws it up by forcing us to take a white box view of componentsUndermines all we know and love about SE
principles! Solution:
Follow the trend in SW construction and work at a level of abstraction where modularity is regained …
28 Apr 2006 LES/PUC-Aspects 3
Principles and assumptions
Programs will end up as spaghetti (often for good reasons!). Give up on working at code level and, following the historical trend, use
automatic code generation. SW Architecture (and UML!) teach us that there are essential
mechanisms not supported in any programming language: Connectors, associations, the concept of (re)configuration, …
Coupling between components is not minimised unless the definition of component interaction is completely externalised
(The greatest sin of OO programming languages!) Use co-ordination concepts.
José Fiadeiro and his coworkers have already recognised the need to take a software architecture based view of aspects, using the setting of CommUnity (which José and I co-invented 10 years ago) to give examples (and giving a formalisation of parameterised connectors that we will adopt).
28 Apr 2006 LES/PUC-Aspects 4
The approach
In this work we address the modelling of aspects at a more abstract level, where
the modularity and reconfigurability ideas from software architecture and
appropriate language mechanisms to create aspect-oriented (sub)configurations from other (sub)configurations (of components and connectors)
help us solve the ‘modularity problem’ for AOP. The semantics of the language CommUnity is based on
Transition Systems and Category Theory (CT).
28 Apr 2006 LES/PUC-Aspects 5
DynaComm
We call our variant Dynamic CommUnity (or DynaComm).
This variant supports hierarchically organized reconfigurable programs and program designs,
with components, connectors and configurations defined by means of several primitive relationships between components, namely (various kinds of) superpositions and refinement.
The semantics of programs and designs in standard CommUnity are extended to support these features.
28 Apr 2006 LES/PUC-Aspects 6
DynaComm
Let us provide an example to clarify the above definition.
component Counter is
channels in n: int out acum: int
actions
ac[acum]: true, false (acum’ = acum + n)
[] reset[acum]: true, false (acum’ = 0)
[] inc[acum]: true, false (acum ≥ 0 acum’ = acum + 1)
endofcomponent
local variables
set by the environment
seen by environment
private
action
enabling guard
progress guard
specification of multiple assignment
write frame
?
28 Apr 2006 LES/PUC-Aspects 7
DynaComm morphisms
We now define possible relationships between component definitions.
A morphism between two components C and C’ is just an extended signature morphism ch from C channels to those of C’, showing how the
channels of C are represented by those of C’, and a partial mapping ac from the actions of C’ to those of C,
mapping actions of C’ that realize an action in C to that action. (Several actions of C’ may use an action of C. Some actions of C’ don’t use any action of C.)
28 Apr 2006 LES/PUC-Aspects 8
Regulative Superpositions
C
C’ C’ C’
spectative
regulative
extension
A regulative superposition morphism σ: (Σ1, 1) → (Σ2, 2) from component C1 to component C2 is a signature morphism σ: Σ1 → Σ2 such that for every g ε Γ2 for which σac(g) is defined:
ADT╞ (R2(g)|ch(V1) σ(R1(σac(g))))
ADT╞ (L2(g) σ(L1(σac(g))))
ADT╞ (U2(g) σ(U1(σac(g))))
where ADT is the axiomatization of the datatype specification.
No narrowing of possible assignments
28 Apr 2006 LES/PUC-Aspects 9
Regulative Superpositions
C
C’ C’ C’
spectative
regulative
extension
The interval defined by L and U moves to the ‘right’:
strengthening both enabling and progress guards maintains encapsulation
L1
U2L2
U1
(
(
)
)
28 Apr 2006 LES/PUC-Aspects 10
Invasive Superpositions (extension)
C
C’ C’ C’
spectative
regulative
extension
A component extension (superposition) σ: (Σ1, 1) → (Σ2, 2) requires that for every g ε Γ2 for which σac(g) is defined:
ADT ╞ (R1(g)|ch(V1) σ(R2(σac(g))))
ADT ╞ (L1(g) σ(L1(σac(g))))
ADT ╞ σ(U1(g1)) σac(g2)=g1 U2(g2).
This morphism identifies a way in which a component design C1 is an extension (a kind of wrapping) of a component design C2, allowing encapsulation to be broken.
28 Apr 2006 LES/PUC-Aspects 11
Extension
C
C’ C’ C’
Breaks encapsulation! Allow channels to be set under weaker conditions or even by new actions in C2. Similarly, the progress guard may be weakened, requiring the action to be available under looser conditions. Like some (bad) forms of inheritance! But with some guarantees.
L2
U1L1
U2
(
(
)
)
spectative
regulative
extension
28 Apr 2006 LES/PUC-Aspects 12
Refinement
C
C’ C’ C’
A component refinement σ: (1, 1) → (Σ2, 2) from component C1 to component C2 requires that for every g ε Γ2 for which σac(g) is defined:
ADT╞ (R2(g) σ(R1(σac(g))))
ADT╞ (L2(g) σ(L1(σac(g)))),
and for every g1 ε Γ1
ADT╞ σ(U1(g1)) σac(g2)=g1 U2(g2)
spectative
regulative
extension
refinement
C’
28 Apr 2006 LES/PUC-Aspects 13
Refinement
C
C’ C’ C’
The effects of the actions of the more abstract design are required to be preserved or made more deterministic, unlike superpositions.
(Spectative superpositions keep everything the same!)
spectative
regulative
extension
refinement
L1
U2L2
U1
(
(
)
)
28 Apr 2006 LES/PUC-Aspects 14
put
i
get
obuffer[t+K]
prod
val
send
sender[t]
rec
val receiver[t]
design sender[t] is out val:tprv rd:booldo prod[val,rd]:rd,falserd’ send[rd]:rd,false rd’
design receiver[t] is in val:tdo rec:true,false
design buffer[t; K:nat] is in i:tout o:tprv q:queue(K,t); rd:booldo put:full(q)q:=enqueue(i,q)prv next:empty(q)rd o:=head(q)q:=tail(q)rd:=true get:rd rd:=false
28 Apr 2006 LES/PUC-Aspects 15
Client/server example
Sender [s] ←M1 Cable[s] M2→ Buffer [s,k]
Sender-Buffer [s, bound]
component Cable [s:sort] ischannels in i/o : s actions
sync: true, false skipendofcomponent
colimit colimit
=
M1’ M2’
automatically constructed
28 Apr 2006 LES/PUC-Aspects 16
Connectors
connectors consist of a glue component one or more role components, and connections between the roles and the glue.
Connectors can be parameterized by primitive sorts (e.g., integers), datatypes (e.g., lists) and also by other connectors, in which case the connector is called a higher-order connector [papers by José, idea by Garlan].
The glue component can be a component or a subsystem. Simple subsystems result from the composition of individual
components through the composition (i.e., using composes) morphism. However, subsystems can also be dynamic and appear in more complex forms.
28 Apr 2006 LES/PUC-Aspects 17
Connectors
Connectors are ‘parameterised’ components: there is glue G there are roles (the ‘parameters’) that will be
instantiated (using a refinement morphism) by components satisfying the requirements stated by the role
(the s are cables for connection)
R1 Ri Rn
1 i n
Ge.g., buffer
e.g., receiver
glue
role
28 Apr 2006 LES/PUC-Aspects 18
Connector refinement
is a refinement
put
i
get
obuffer[t+K]
prod
val
send
sender[t]
rec
val receiver[t]
put
i
get
oGlue-sender-receiver[t]
prod
val
send
sender[t]
rec
val receiver[t]
component Glue-sender-receiver[s] ischannels in i:s ; out o:s actions
put: true, false skipprod[o]: true, false skipget: true, false skip
endofcomponent
Unicomm[s]
Asynch[s,K]
28 Apr 2006 LES/PUC-Aspects 19
Performance aspect
First example of the application of an aspect to a system design
to enhance performance aspects replace an existing architectural pattern (or all instances
thereof) with another pattern, capturing the aspect
put
i
get
obuffer[t+K]
prod
val
send
sender[t]
rec
val receiver[t]
put
i
get
oGlue-sender-receiver[t]
prod
val
send
sender[t]
rec
val receiver[t]
architecture transformation
28 Apr 2006 LES/PUC-Aspects 20
Static Aspects
We define static (and dynamic) aspects, such as the ones related to monitoring and encryption, in terms of connectors and a notion of subsystem.
A first one can be used to add behavior to actions by synchronization.
In our component model, behavior is not added before or after, but in parallel because the model is abstract and sequencing is an implementation-dependent feature.
This connector, which is basic in the definition of aspects and corresponds to a parallel version of the before and after forms of advice, is defined as follows.
28 Apr 2006 LES/PUC-Aspects 21
Add behavior to actions by synchronization
ac1
componentA
ac1
componentA
a1
Action1
a2
Action2
ac1
component
a-glue
glue
a-glue: true, false skipa1: true, false skipa2: true, false skip
28 Apr 2006 LES/PUC-Aspects 22
Preempt an action
ac1
component
ac1
component
a1
Action1
never Strengthen
never: false skipa1: true, false skip
28 Apr 2006 LES/PUC-Aspects 23
Static aspects: action override
Generalization of the previous connector. The result of instantiating the role with an action with
guard B is the same action guarded by BC.
connector StrengthenGuard isglue Strengthen role Action1 connections strengthen-guard.Strengthen to
a1.Action1 endofconnector
component Strengthen isactions
strengthen-guard: C skipendofcomponent
28 Apr 2006 LES/PUC-Aspects 24
Static aspects: security
We model a (static) security aspect using our language. (This aspect is static since it uses no component
reconfiguration at runtime, i.e., the aspect configuration, the underlying architecture configuration and the application of the pattern defined by the aspect to the underlying architectural configuration remains unchanged.)
In this example, messages sent through a message medium are first encoded and they are decoded at the receiving end before being passed to the receiver.
28 Apr 2006 LES/PUC-Aspects 25
put
i
get
oGlue-sender-receiver[t]
prod
val
send
sender[t]
rec
val receiver[t]
put
i
get
oGlue-sender-receiver[t]
prod
val
send
sender[t]
rec
val
put
i
get
o
put
i
get
o Encrypt[t]
Encrypt[t]
receiver[t]
28 Apr 2006 LES/PUC-Aspects 26
Static aspects: security and monitoring Adding monitoring to a comms channel with encryption …
put
i
get
oGlue-sender-receiver[t]
prod
val
send
sender[t]
rec
val
put
i
get
o
put
i
get
o Encrypt[t]
Encrypt[t]
receiver[t]
i
listen Monitor[t]
28 Apr 2006 LES/PUC-Aspects 27
… and so on
We can handle all kinds of aspects: Making an unreliable communication medium reliable by
introducing an acknowledgement mechanism:• Extend each role in a comms connector to be able to send/receive
acks • Modify existing send action in sender to send again if ack not received
(weakens guard)• Use a normal comms connector in the reverse direction• Package it all up as a pattern to apply to any ‘simple’ comms
connector Dynamic aspects require reconfiguration.
Reasoning about temporal properties. Weaving by using OO patterns for translation to code (as a more
structured alternative to mathematical construction). Applications in autonomous, context aware, mobile, etc
applications. Systematising fault tolerance.
28 Apr 2006 LES/PUC-Aspects 28
… and so on
including dynamic ones: Fault tolerance by replacing a failed server with a live one (that
has been synchronised with the first at some point in time) Backup server, as above but replacing one server with another on
a regular basis Performance: replace or replicate a server with performance
deficiencies; replace a connector with a ‘better’ connector; replace a connector with better quality of service (as in networks or video streaming)
Mobile clients Access control Autonomic systems ……
28 Apr 2006 LES/PUC-Aspects 29
Future work
Aspects can be composed Order of composition is important (as in feature
interaction) Some forms of fault tolerance require deontic
operators on actions: distinguishing ‘good’ behaviour from ‘bad’ or ‘really bad’ or ‘evil’ …. (work with Jeff M)
Corresponding temporal logic specs and automated reasoning (Naza has already done some examples in STeP)
Lifting properties of components to system with features
…