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

1. Tom Maibaum (with Naza Aguirre, Paulo Alencar) Architecting Aspects:orWhy you always knew aspect weaving was colimit construction

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 components • Undermines 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 … 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). 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). 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. LES/PUC-Aspects

6. DynaComm • Let us provide an example to clarify the above definition. set by the environment seen by environment private local variables 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 ? action write frame enabling guard progress guard specification of multiple assignment 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.) LES/PUC-Aspects

8. C A regulativesuperposition 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. extension spectative regulative Regulative Superpositions No narrowing of possible assignments LES/PUC-Aspects

9. C C’ C’ C’ The interval defined by L and U moves to the ‘right’: strengthening both enabling and progress guards maintains encapsulation extension spectative regulative Regulative Superpositions L1 U1 ( ) U2 L2 ) ( LES/PUC-Aspects

10. C C’ C’ C’ 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 spectative regulative Invasive Superpositions (extension) LES/PUC-Aspects

11. 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. extension spectative regulative Extension L2 U2 ( ) U1 L1 ) ( LES/PUC-Aspects

12. 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) refinement extension spectative regulative Refinement C’ LES/PUC-Aspects

13. 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!) refinement extension spectative regulative Refinement L1 U1 ( ) L2 U2 ( ) LES/PUC-Aspects

14. rec send prod put get buffer[t+K] receiver[t] sender[t] o val i val design buffer[t; K:nat] is in i:t out o:t prv q:queue(K,t); rd:bool do put:full(q)q:=enqueue(i,q) [] prv next:empty(q)rdo:=head(q)||q:=tail(q)||rd:=true []     get:rd rd:=false design sender[t] is out val:t prv rd:bool do prod[val,rd]:rd,falserd’ [] send[rd]:rd,false rd’ design receiver[t] is in val:t do rec:true,false LES/PUC-Aspects

15. Client/server example Sender [s] ←M1 Cable[s] M2→ Buffer [s,k] M1’ M2’ colimit colimit = component Cable [s:sort] is channels in i/o : s actions sync: true, false  skip endofcomponent automatically constructed Sender-Buffer [s, bound] 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. LES/PUC-Aspects

17. G 1in R1  Ri  Rn 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) glue e.g., buffer role e.g., receiver LES/PUC-Aspects

18. rec send prod put get Glue-sender-receiver[t] receiver[t] sender[t] o val i val rec send prod put get buffer[t+K] receiver[t] sender[t] o val i val Connector refinement Unicomm[s] • is a refinement Asynch[s,K] • component Glue-sender-receiver[s] is • channels in i:s ; out o:s • actions • put: true, false  skip • prod[o]: true, false  skip • get: true, false  skip • endofcomponent LES/PUC-Aspects

19. rec send prod put get buffer[t+K] receiver[t] sender[t] o val i val Performance aspect rec send prod put get • 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 Glue-sender-receiver[t] receiver[t] sender[t] o val i val architecture transformation 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. LES/PUC-Aspects

21. Add behavior to actions by synchronization a1 ac1 ac1 componentA componentA Action1 glue a-glue a2 ac1 a-glue: true, false  skip a1: true, false  skip a2: true, false  skip component Action2 LES/PUC-Aspects

22. Preempt an action a1 ac1 ac1 component component Action1 Strengthen never never: false  skip a1: true, false  skip 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 BC. 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. LES/PUC-Aspects

25. rec send prod put get Glue-sender-receiver[t] o receiver[t] sender[t] val i val put get put get o o Encrypt[t] i Encrypt[t] i rec send prod put get Glue-sender-receiver[t] o sender[t] receiver[t] i val val LES/PUC-Aspects

26. Static aspects: security and monitoring • Adding monitoring to a comms channel with encryption … listen Monitor[t] i put get put get o o Encrypt[t] i Encrypt[t] i rec send prod put get Glue-sender-receiver[t] o sender[t] receiver[t] i val val 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. 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 • …… 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 • … LES/PUC-Aspects