1 Thomas Cottenier 1,2, Aswin van den Berg 1, Tzilla Elrad 2 1 Software and System Engineering Research Lab, Motorola Labs 2 Concurrent Programming Research

1

Thomas Cottenier 1,2, Aswin van den Berg 1, Tzilla Elrad 2

1 Software and System Engineering Research Lab, Motorola Labs

2 Concurrent Programming Research Group, Illinois Institute of Technology

AOSD 2007

Stateful Aspects:The Case for Aspect-Oriented Modeling

Stateful Aspects: The Case for Aspect-Oriented ModelingThomas Cottenier, AOSD 2007 – Other materials used by permission

Motorola General Business Information, MOTOROLA and the Stylized M Logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective owners. © Motorola, Inc. 2007

2

This talk is about…



3

This talk is about…

• Stateful Aspects• Modeling Languages

– Transformational Systems– Reactive Systems

• Stateful Aspects Appear in Reactive Systems• Model-Driven Implementation of Reactive Systems• Aspect-Oriented Modeling with Motorola WEAVR• Abstractions for Stateful Aspects • Conclusions



4

Conclusions

• The need for stateful aspects indicates that the base system exhibits reactive behavior

• Being reactive, the base system is better decomposed according to a state machine decomposition language

• Aspect-Oriented Modeling languages can capture stateful aspects in terms of module specifications as opposed to implementation-dependent sequences of events

• Aspect-Oriented Modeling techniques can achieve better decoupling between aspects and base modules



5

Stateful Aspects



6

Stateful Aspects

• “Jumping Aspects” Problem (Brichau et al.)History-sensitive pointcut descriptors that

capture protocols– Event-Based AOP (Douence et al.)– Trace-Based Aspects (Douence et al.)– Declarative Event Patterns (Walker et al.)– Java Aspect Components (Vandeperren et al.)

• Stateful aspect languages recover the state-machine based behavior of the system



7

Stateful Aspects in JAsCo



8

Stateful Aspects

• History-sensitive pointcut descriptors capture protocols• Systems that implement protocols can be categorized as

being reactive, discrete systems as opposed to transformational systems



9

Software Modeling

Different types of systems:• Transformational systems:

Data-Processing systems, Compilers, Search-Engines, Computation Intensive systems, etc..

• Reactive systemsATM, vending machines, phones, cars, missile and avionic systems, telecom infrastructure, human-machine interface of may ordinary software, etc…

• Workflow systemsEnterprise Resource Planning systems, business processes, Scientific workflow systems, etc…

• Concurrent systemsApplication Servers, Resource Access Servers, telecom systems, user-interfaces, …



10

Software Modeling

Different types of systems:• Transformational systems:

Data-Processing systems, Compilers, Search-Engines, Computation Intensive systems, etc..

Procedural, Functional, Object-Oriented, etc programming languages provide excellent support for Transformational systems!



11

Software Modeling

Different types of systems:• Reactive systems

ATM, vending machines, phones, cars, missile and avionic systems, telecom infrastructure, human-machine interface of may ordinary software

Procedural, Functional, Object-Oriented, etc programming languages DO NOT provide the right abstractions



12

Reactive Systems

Components:- That are repeatedly prompted by the outside world and

continuously respond to external inputs- Whose behavior is highly dependent on module history

Abstractions:- State- Transition- Decision Actions

Today, difficult systems are hybrid systems ! (concurrent, reactive, transformational, workflow)



13

1. void actionPerformed(ActionEvent evt) {

2. switch(this.STATE){

3. case Init:

4. serviceA.methodA();

5. if(evt.getSource() == Enter){

6. serviceB.methodB();

7. if(evt.getActionCommand() == “Previous”){

8. serviceC.methodC();

9. this.STATE = Previous;

10. return;

11. }else

12. if(evt.getActionCommand() == “Next”){

13. serviceD.methodB();

14. this.STATE = Next;

15. return;

16. }

17. }else

18. if (evt.getSource() == Cancel){

19. }

20. break;

21. case Previous:

22. serviceA.methodE();

23. break;

24. case Next:

25. if(evt.getActionCommand() == “Proceed”){

26. serviceA methodC();

27. }

28. break;

29. }

30. methodF();

31. this.STATE = Done;

32. return;

33. }

Example: Java Applet

Init

actionPerformed(evt)

ActionEvent evt;Button Enter;Button Cancel;

serviceA.methodA();

evt.getSource()

serviceB.methodB();

[==Enter]

evt.getActionCommand()

serviceC.methodC();

[=="Previous"]

Previous


serviceA.methodE();

Previous

serviceD.methodB();

Next

Next

if(evt.getActionCommand() == "Proceed"){ serviceA.methodC();}

serviceB.methodB();


Done

[=="Next"]

[==Cancel]

Service serviceA;Service serviceB;Service serviceC;Service serviceD;



14

Software Modeling

Architecture package U2Static {5/20}

Definition

Method

Implementation

/ isActive : eboolean

Attribute

/ isNavigable : eboolean

Class

isActive : eboolean

Internals

Connector

/ connectionKind : ConnectionKind

Port

isBehaviorPort : eboolean

inherited : ebooleanvisibility : VisibilityKind

ConnectorEnd

enabled :eboolean

connectorEnd'connector'

0 .. *

connectorEnd'connector'

0 .. *

carried0 .. *

carried0 .. *

realized

0 .. *

realized

0 .. * required

0 .. *

required

0 .. *

/ allMethod

0 .. *

/ allMethod

0 .. *

'part'

0 .. 1

'part'

0 .. 1

Collaboration

'port'0 .. 1

'port'0 .. 1 / 'port'

0 .. *

/ 'port'

0 .. *

/ 'connector'0 .. *

/ 'connector'0 .. *

/ 'connector'0 .. *

/ 'connector'0 .. *

/ 'port'

0 .. *

/ 'port'

0 .. *

/ 'connector'0 .. *

/ 'connector'0 .. *

pos::POMessage PO;pos::InvMessage Invoice;pos::shippingRequestMessage shippingRequest;pos::shippingInfoMessage shippingInfo;pos::scheduleMessage shippingSchedule; sendPurchaseOrder(PO)

assign<<mapping>>

shippingRequest.customerInfo = PO.customerInfo;

sendSchedule(shippingSchedule)

ship_to_invoice

sendInvoice(Invoice)

ship_to_scheduling

purchaseClient::purchaseInvoice(Invoice) via purchaseClient::purchaseCallbackPT

invoiceService::initiatePriceCalculation(PO) via invoiceService::computePricePT

invoiceService::sendShippingPrice(shippingInfo) via invoiceService::computePricePT

schedulingService::requestProductionScheduling(PO) via schedulingService::schedulingPT

shippingService::requestShipping(shippingRequest) via shippingService::shippingPT

requestShippingCallback(shippingInfo)

schedulingService::sendShippingSchedule(shippingSchedule) via schedulingService::schedulingPT

Init



serviceA.methodA();

evt.getSource()

serviceB.methodB();

[==Enter]


serviceC.methodC();

[=="Previous"]

Previous


serviceA.methodE();

Previous

serviceD.methodB();

Next

Next


serviceB.methodB();


Done

[=="Next"]

[==Cancel]


sd Trace (5) interaction DebugTrace2 {1/1}

env[1]<<actor>>

rh[1]

d[1]

Sequence diagram tracegenerated forServer

Idle

rh ((. 3874 .))

Idle

Init

request(RID_t (.id = 12.))

Idle

Ready

commit(RID_t (.id = 12.))

Idle

Init

kill()

Idle

resource_ack(CID_t (.id = 3874.), RID_t (.id = 12.))

global_commit(CID_t (.id = 3874.), RID_t (.id = 12.))

resource_commit(CID_t (.id = 3874.), RID_t (.id = 12.))

setupSession(CID_t (.id = 3874.))

resource_request(CID_t (.id = 3874.), RID_t (.id = 12.))

endSession(CID_t (.id = 3874.))

Architecture Diagram active class SimpleServer {2/2}

EnvPort

setupSession, endSession, resource_request

access_error

OutPort

resource_ack

-rh : RequestHandler[0..*]/ 0RHPort

srhPort

request, kill

d : DispatcherDPort

sdPort

request, kill

EnvToD

RHToEnv

- ss : Service[0 .. 3]

sPort

access

iPort

access

Procedural

Object-Oriented Workflow

State Machine

Run time Structure+ Execution: Action Language



15

Init



serviceA.methodA();

evt.getSource()

serviceB.methodB();

[==Enter]


serviceC.methodC();

[=="Previous"]

Previous


serviceA.methodE();

Previous

serviceD.methodB();

Next

Next


serviceB.methodB();


Done

[=="Next"]

[==Cancel]


Model-Driven Implementation

System Implementation System Specification

Init

Previous Next

Done

actionPerformed(evt)actionPerformed(evt)





16

Model-Driven Implementation



17

Aspect-Oriented Modeling with Motorola WEAVR



18


WEAVR

Model weaving

Engine

<<operation,Connector>>

initialize

<<operation,Pointcut>>

startup_transition<<bind>>

Active

Idle

startup()

proceed();

initializeTimers();

initializeChannels();

Idle

startup()

Active

ok()

Idle

startup()

Active

ok()

Idle

startup()

Active

ok()

<<operation,Connector>>

initfailure

return Boolean


init

return Boolean <<bind>>

<<operation,Expression>>

'initialize(.)*'

return Boolean

'initialize(.)*'();

status

status

status = proceed();

Boolean status;

status

[==true]

Idle

startup_failure()

[==false]

status = initializeTimers();

status = initializeChannels();

Boolean status;

status

[==true]

status

Idle

startup()

ok()

[==true]

Active

startup_failure()

[==false]

[==false]

Idle



Boolean status;

status

[==true]

status

Idle

startup()

ok()

[==true]

Active

startup_failure()

[==false]

[==false]

Idle



Boolean status;

status

[==true]

status

Idle

startup()

ok()

[==true]

Active

startup_failure()

[==false]

[==false]

Idle

Resource Initialization Aspect

Initialization Exception Handling Aspect



19


WEAVR is an addin to Telelogic TAU that performs weaving of UML models:– Aspects are fully defined at the modeling level– Aspects are woven with the base model before simulation or

code generation

We are not interested in generating code-level aspects:– The modeling language provides for a richer joinpoint model

than programming languages– Code generation optimizers destroy the structure and the

syntactic correspondence between models and generated code

Model weaving is a particular form of model transformation



20


WEAVR performs model weaving using the Telelogic TAU metamodel and model transformation API– WEAVR can take advantage of the metamodel, API, type

analysis, static analysis and model checking functions provided by TAU

Downside: WEAVR is highly dependent on TAU, yet:– The semantics of the standard UML action language are not fully

defined– Meaningful inter-exchange of executable models is hard– Weaving at the XMI level is not practical, especially for

executable models



21

Abstractions for Stateful Aspects







22

Aspects in Motorola WEAVRClassDiagram1 <<Aspect>>class ProtocolSecurityChecker {2/2}


securityViolation<<operation,Connector>>

throwSecurityException

<<binds>>

<<interface>>

ThrowsSecurityException

<<Pointcut>> void securityViolation() {1/1}

unauthorized

*

access()

<<Connector>> void throwSecurityException() {1/1}

'thisStateMachine<FAILURE>'

throw new SecurityException("This protocol on" +"component"+ thisJoinPoint::getThisClassName() +" is not allowed!");



23

Aspects in Motorola WEAVR

Init

authorized unauthorized

access()access()

<<realizes>>mapping {State: Init -> InitState: Previous -> unauthorizedState: Next, Done -> authorizedSignal: actionPerformed(ActionEvent) -> access()

}

Init

Previous Next

Done






24


Init

authorized unauthorized

access()access()


}

Init

Previous Next

Done




Init


serviceA.methodA();

evt.getSource()

serviceB.methodB();

[==Enter]


serviceC.methodC();

[=="Previous"] / {}

Previous


serviceA.methodE();

Previous

serviceD.methodB();

Next

Next


serviceB.methodB();


Done

[=="Next"]

[==Cancel]


unauthorized

*

access()



25


Selection mechanism localizes important decision points


}

Init


serviceA.methodA();

evt.getSource()

serviceB.methodB();

[==Enter]


serviceC.methodC();

[=="Previous"] / {}

Previous


serviceA.methodE();

Previous

serviceD.methodB();

Next

Next


serviceB.methodB();


Done

[=="Next"]

[==Cancel]


unauthorized

*

access()

See paper, Cottenier et al.“Joinpoint Inference from Behavioral Specification to Implementation”, ECOOP’07



26

Change of Secutity Policy

From:

ATrans: call(methodA) > BTrans;

BTrans: call(methodB) > CTrans;

CTrans: call(methodC) > ATrans;

To:

ATrans: call(methodA) > BTrans;

BTrans: call(methodB) > CTrans;

CTrans: call(methodC)

|| call(methodB) > ATrans;

Very Implementation Dependent! Defined in terms of system specification!

From:

State: Previous-> unauthorized

State: Next, Done -> authorized

To:

State: Previous, Next-> unauthorized

State: Done -> authorized



27

Change of Secutity Policy To: State: Previous, Next-> unauthorized State: Done -> authorized

From: State: Previous-> unauthorized State: Next, Done -> authorized

Init


serviceA.methodA();

evt.getSource()

serviceB.methodB();

[==Enter]


serviceC.methodC();

[=="Previous"] / {}

Previous


serviceA.methodE();

Previous

serviceD.methodB();

Next

Next


serviceB.methodB();


Done

[=="Next"]

[==Cancel]

Init


serviceA.methodA();

evt.getSource()

serviceB.methodB();

[==Enter]


serviceC.methodC();

[=="Previous"]

Previous


serviceA.methodE();

Previous

serviceD.methodB();

Next

Next


serviceB.methodB();


Done

[=="Next"]

[==Cancel]



28

Conclusions



29

Conclusions







30

Thank You

http://www.iit.edu/~concur/weavr/

Documents

1 Thomas Cottenier 1,2, Aswin van den Berg 1, Tzilla Elrad 2 1 Software and System Engineering Research Lab, Motorola Labs 2 Concurrent Programming Research