1. 1 An Aspect-Oriented Implementation Method Sérgio Soares CIn – UFPE Orientador: Paulo Borba

2. 2 Motivation OOP allows modularization/separation of concerns Reuse, maintainability, and productivity User interface, distribution, business logic, and data management but has limitations...

3. 3 The major problem OO limitations Spread code several units to implement a concern Tangled code several concerns mixed in a single unit Design patterns can help, but are limited

4. 4 Concerns spread and tangled with business logic, UI, and with each other concurrency control distribution data management OO information system using design patterns

5. 5 The major problem User interface Distribution Business logic Data management Concurrency control

6. 6 User interface Distribution Business logic Data management Concurrency control The major problem

7. 7 How can we avoid those OO limitations? support developers? increase productivity? Research

8. 8 Using aspect-oriented programming (AOP) User interface Distribution Business logic Data management Concurrency control

9. 9 Using aspect-oriented programming (AOP) User interface Distribution Business logic Data management Concurrency control

10. 10 AspectJ – aspect-oriented programming with Java

11. 11 Joint point model object A object B and returns or throws a method is called dispatch a method is called and returns or throws a method executes and returns or throws a method executes and returns or throws Behavior might be changed at join points… Source: AspectJ Tutorial aspectj.org

12. 12 Advices Define additional code that should be executed… before after after returning after throwing or around specified join points

13. 13 Static crosscutting Change types hierarchy Add new members to types Define compile-time errors and warnings Wrap checked exceptions into unchecked ones

14. 14 Define an implementation method to deal with several concerns UI, distribution, business logic, data management, and concurrency control complement programming techniques and design patterns support developers deal with aspect-oriented software development AspectJ Research

15. 15 Aspect-oriented development Software requirements Concern identifier AOP OOP Aspects Classes Interfaces Executable software WEAVERWEAVER Concerns UI and business logic use OOP Distribution, data management, and concurrency control use AOP

16. 16 Towards an aspect-oriented implementation method A case study restructuring an OO software to an AO software AOP is useful suggestion of AspectJ improvements dependencies and impacts between aspects distribution vs. data management aspect framework and patterns to implement the concerns

17. AspectJ framework DM CC D Synchronization > PessimisticSynchronization > OptimisticSynchronization > ConcurrencyManager PersistenceControl > TransactionControl > DataCollectionCustomization > IPersistenceMechanism ClientSide > ServerSide > Remote (from java.rmi) TimestampedType Timestamp > OptimizedTimestamp > TimestapedRepository

18. 18 Implementation method Tailored to a specific software architecture already used in several real OO information systems allows more precise guidelines some types can be automatically generated tool support

20. 20 Implementation method An alternative implementation approach non-functional requirements initially abstracted distribution, persistence, and concurrency control allows early functional requirements validation can increase productivity decreases tests complexity

21. 21 Implemented concerns time y x aaaabbbbaaaa Regular approach User interface Distribution Functional requirements Persistent data management Concurrency control Milestone (end of iteration) a and b are use cases, sets of use cases, or use-cases scenarios

22. 22 User interface Distribution Functional requirements Persistent data management Non-persistent data management Concurrency control Milestone (end of iteration) Functional iteration Progressive approach Implemented concerns time aaaa y’ x’ bbbbaaaa a and b are use cases, sets of use cases, or use-cases scenarios

23. 23 Implementation method How to combine with use-case driven development and RUP impact on the process dynamics use of the progressive approach impact on its activities management, requirements, analysis and design, implementation, and test changes and new activities

24. 24 Combining with RUP Implementer Client Implement Component Implement Persistence Implement Distribution Control Concurrency... Architect Project Manager Designer Validate Functional Prototype Implementer

25. 25 New activity example Validate Functional Prototype Purpose: validating the functional prototype in order to identify possible requirement changes. Steps:... Input artifacts: The prototype implemented in the Implement Component activity. Resulting artifacts: A list of requirement changes or a document stating the prototype validation without changes. Workers:...

26. 26 Experimentation Formal study with graduate students analysis of the progressive approach implementation time requirements change time test execution time pre-validation prototype time post-validation prototype time using some use cases of a real software did not consider concurrency control

27. 27 Experimentation Null hypothesis The times using a progressive approach for aspect-oriented development are not different than using a non-progressive approach

28. 28 Subjects expertise - academic Expertise 1 - OITC 2 - < 6m 3 - 6m-2y 4 - 2y-4y 5 - 4y-6y 6 - > 6y

29. 29 Subjects expertise - industrial Expertise 1 - OITC 2 - < 6m 3 - 6m-2y 4 - 2y-4y 5 - 4y-6y 6 - > 6y

30. 30 Study Analysis t-test some differences were statistically significant and others were not times to implement and test

31. 31 Study data – times to change requirements -56% -89%

32. 32 Study data – time to deliver executable prototypes -75% -72%-66%

33. 33 Study data – times do deliver first usable/testable prototype

34. 34 Study Results using the progressive approach requirements changes and times to deliver executable prototypes were faster programmers felt easier to implement and test some differences to the regular approach were not significant not enough participants low degree of precision (confidence interval) Framework to perform others experiments

35. 35 Study Other conclusions the progressive approach might be more effective with more complex changes implementation and tests times were not different less implementation and test complexity through separation of concerns

36. 36 Tool support Aspect generation based on the aspect framework and patterns Extension of an existing tool and language for Java transformation with AspectJ allows, in the future, to define aspect refactorings

37. 37 Tool support Eclipse plug-in Transformation engine – AJaTS AJaTS Transformations descriptions Software Java source files AspectJ framework Generated aspects Programmer

38. 38 Conclusions Implementation method activities, implementation approaches, guidelines inserted into a real development process Aspects can affect each other distribution aspects affect data management aspects analysis and design are essential to identify those possible interferences

39. 39 Conclusions Aspect patterns and framework reuse Experiments guide the implementation method study framework Tool support productivity increase aspect refactoring in the future

40. 40 Future work Extend the implemented aspects Identify new concerns to implement as aspects functional aspects? Refactoring of aspect-oriented software from OO or AO from AO to AO

41. 41 Research group Software Productivity Group http://www.cin.ufpe.br/spg