1. AspectWrapper CHALFOUN Pierre et BUIST Éric

2. Overview Introduction – what and why In a nutshell – main components Our approach – how we did it Demo – a taste of things to come Conclusion – “wrap” things up Introduction – what and why In a nutshell – main components Our approach – how we did it Demo – a taste of things to come Conclusion – “wrap” things up

3. Introduction Problematic – in two words  Testing  A pain in the … “you know where”  Nevertheless … important !  Nevertheless … tedious and time consuming  Please, do automate ! Problematic – in two words  Testing  A pain in the … “you know where”  Nevertheless … important !  Nevertheless … tedious and time consuming  Please, do automate ! Introduction In a nutshell Our approach Demo Conclusion  Aspect-oriented programming  Crosscutting … How can you test that ?  Composition impact on code  Specifications are required when modeling ( UML )  Aspect-oriented programming  Crosscutting … How can you test that ?  Composition impact on code  Specifications are required when modeling ( UML )

4. Introduction Problematic – in one word  Specification-based automatic testing of aspect-oriented programs Problematic – in one word  Specification-based automatic testing of aspect-oriented programs Introduction In a nutshell Our approach Demo Conclusion

5. Introduction Motivation : an illustrated version Modeling aspects Test data report Generating oracles Running oracles Introduction In a nutshell Our approach Demo Conclusion

6. - In a nutshell - Testing Framework Test runners  Automate execution  Report results Test oracles  How to perform the test Test data – domain specific Two approaches  Specification-based (black box)  Program-based (white box) Test runners  Automate execution  Report results Test oracles  How to perform the test Test data – domain specific Two approaches  Specification-based (black box)  Program-based (white box) Introduction In a nutshell Our approach Demo Conclusion

7. - In a nutshell – Aspect Modeling 1/2 Aspect-UML – Mostefaoui et Vachon 2005  Language independent  Validate aspect composition  Aspect defined by stereotype « Aspect »  Pointcut defined by stereotype « PointCut »  Constraints are written in OCL  Cannot model inter-type declarations Aspect-UML – Mostefaoui et Vachon 2005  Language independent  Validate aspect composition  Aspect defined by stereotype « Aspect »  Pointcut defined by stereotype « PointCut »  Constraints are written in OCL  Cannot model inter-type declarations Introduction In a nutshell Our approach Demo Conclusion

8. - In a nutshell – Aspect Modeling 2/2 Aspect-UML – Mostefaoui et Vachon 2005 Introduction In a nutshell Our approach Demo Conclusion OCL constraint for the opDrop advice context Billing : :opDrop inv : connection=c inv : c.getTime() !=Null post : c.getCaller.getCharge() >= c.getCaller.getCharge()@pre

9. - In a nutshell – Dresden : OCL to Java Dresden – Dresden University Group 2005  Parses OCL constraints in UML diagrams  Applicable only to Java and OOP  Long series of try and catch Dresden – Dresden University Group 2005  Parses OCL constraints in UML diagrams  Applicable only to Java and OOP  Long series of try and catch /** A wrapper for injection. Generated automatically, DO NOT CHANGE! @author ocl_injector @see #Person(tudresden.ocl.injection.lib.WrapperDummy) */ public Person(){ this((tudresden.ocl.injection.lib.WrapperDummy)null); try{ tudresden.ocl.injection.ocl.lib.Invariant.checking_flag=true; tudresden.ocl.injection.ocl.lib.Invariant.checkVacantInvariants(); }finally{ tudresden.ocl.injection.ocl.lib.Invariant.checking_flag=false; } }/** Introduction In a nutshell Our approach Demo Conclusion

10. - In a nutshell – aUnit 1/2 aUnit – Russ Miles 2005 “ Similar to how JUnit provides unit testing for Java, aUnit will provide mechanisms by which developers can test their aspects in isolation in support of Test Driven Development.” – Russ Miles 2004 Idea : calling an advice explicitly  Code manually the JoinPoint  One advice = 1 step  Get all the steps together and sort them  Execute each step in turn Idea : calling an advice explicitly  Code manually the JoinPoint  One advice = 1 step  Get all the steps together and sort them  Execute each step in turn Introduction In a nutshell Our approach Demo Conclusion

11. - In a nutshell – aUnit 2/2 Introduction In a nutshell Our approach Demo Conclusion

12. - Our approach - Aspect-UML to AspectJ Extending the mapping between UML and Java  1 « Aspect » = 1 java file Annotation AdviceName for the advice Attaching OCL constraints with annotations Extending the mapping between UML and Java  1 « Aspect » = 1 java file Annotation AdviceName for the advice Attaching OCL constraints with annotations Introduction In a nutshell Our approach Demo Conclusion /* When timing stops, calculate and add the charge from the * connection time */ @AdviceName("opDrop") @OclPostcondition(value="getPayer(conn).totalCharge >= "+ " getPayer(conn).totalCharge@pre") after(Connection conn): Timing.endTiming(conn) { long time = Timing.aspectOf().getTimer(conn).getTime(); long rate = conn.callRate(); long cost = rate * time; getPayer(conn).addCharge(cost); }

13. - Our approach - OCL annotation to Java Extending Dresden to take advice into account OCL is converted to JAVA in a class_Test.java file Each constraint has an associated non-static method Extending Dresden to take advice into account OCL is converted to JAVA in a class_Test.java file Each constraint has an associated non-static method Introduction In a nutshell Our approach Demo Conclusion public void prep$adv$opDrop (telecom.Connection conn) { […] final tudresden…OclInteger tudOclNode13= tudresden…toOclInteger(tudOclNode12.getFeature("totalCharge")); final tudresden…OclAnyImpl tudOclNode14= tudresden…toOclAnyImpl(tudOclNode11.getFeature("getPayer", tudOclParam1)); tudOclNode15=tudresden…toOclInteger(tudOclNode14. getFeature("totalCharge")); final tudresden…OclBoolean tudOclNode16= tudOclNode13.isGreaterEqual(tudOclNode15); } public tudresden…OclBoolean check$adv$pre$opDrop (telecom.Connection conn) { return tudresden…OclBoolean.TRUE; }

14. - Our approach - aUnit Revisited 1/2 Extending aUnit to support method calls : re- implement TestStep and subclass Extending aUnit to support method calls : re- implement TestStep and subclass Introduction In a nutshell Our approach Demo Conclusion public class MethodTestStep implements TestStep { protected Object testedObject; protected Method testedMethod; protected Object[] arguments; protected Object returnValue; protected List results = new ArrayList(); […] } public class CheckMethodTestStep Extends MethodTestStep { […] public void runStep() throws TestFailException { super.runStep(); OclBoolean oclBoolean = (OclBoolean)getResults().get (0); if (oclBoolean.isFalse()) { throw new TestFailException(); } }

15. - Our approach - aUnit Revisited 2/2 Usage example Introduction In a nutshell Our approach Demo Conclusion TestStep[] steps = new TestStep[2]; MockApplication mock = new MockApplication(); Class[] paramTypes = { int.class }; Method barMethod = mock.getClass().getMethod("bar", paramTypes); JoinPoint.StaticPart staticPart = Factory.makeEncSJP(barMethod); Object[] args = { 10 }; JoinPoint joinPoint = Factory.makeJP(staticPart, mock, mock, args); JoinPointContext context = new JoinPointContext(joinPoint); String adviceSelectorExpression = "id3"; TestStep Step1 = TestStepFactory.createControlledTestStep( (AspectObject) AfterAdviceExampleAspect.aspectOf(), context, adviceSelectorExpression); steps[0] = Step1; // our contribution MockApplication_Test mockTest = new MockApplication(mock); Method checkPost = mockTest.getClass().getMethod(“check$adv$pre$opDrop”,…); CheckMethodTestStep checkStep = new MethodTestStep(mock,checkPost,args,…); steps[1] = checkStep;

16. Demo OCL annotation to Java Introduction In a nutshell Our approach Demo Conclusion

17. Demo aUnit in action Introduction In a nutshell Our approach Demo Conclusion

18. Our contribution – missing piece of the puzzle Introduction In a nutshell Our approach Demo Conclusion Modeling aspects Generating oracles Running oracles Extend the mapping between UML and Java Extend the Dresden tool Extend the aUnit tool

19. Conclusion Related Work  Theme/UML  ArgoUML (Dresden toolbox)  JAOUT (JML) Future Work  Fully implement the framework and adapt to future releases of aUnit, Dresden and AspectJ 5  Propose extensions to Aspect-UML to model module interaction via new OCL constraints Related Work  Theme/UML  ArgoUML (Dresden toolbox)  JAOUT (JML) Future Work  Fully implement the framework and adapt to future releases of aUnit, Dresden and AspectJ 5  Propose extensions to Aspect-UML to model module interaction via new OCL constraints Introduction In a nutshell Our approach Demo Conclusion

20. Thank You AspectWrapper CHALFOUN Pierre & BUIST Eric