Architecting Aspects: or Why you always knew aspect weaving was colimit construction

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 …


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


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


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.


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

?


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


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


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

(

(

)

)


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.


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


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’


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

(

(

)

)


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


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


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.


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


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]


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


prod

val

send

sender[t]

rec

val receiver[t]

architecture transformation


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.


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


Preempt an action

ac1

component

ac1

component

a1

Action1

never Strengthen

never: false skipa1: true, false skip


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


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.


put

i

get


prod

val

send

sender[t]

rec

val receiver[t]

put

i

get


prod

val

send

sender[t]

rec

val

put

i

get

o

put

i

get

o Encrypt[t]

Encrypt[t]

receiver[t]


Static aspects: security and monitoring Adding monitoring to a comms channel with encryption …

put

i

get


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]


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


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


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

…

Documents

Architecting Aspects: or Why you always knew aspect weaving was colimit construction