An AspectOriented Implementation Method Srgio Soares CIn UFPE

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

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

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

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

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

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

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

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

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

Aspect. J – aspect-oriented programming with Java 10

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

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

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

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

Aspect-oriented development Concerns Concern Software requirements identifier OOP AOP n n Classes Interfaces Aspects W E A V E R Executable software UI and business logic use OOP Distribution, data management, and concurrency control use AOP 15

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

Aspect. J framework <<Aspect>> Synchronization <<Aspect>> Timestamp <<Aspect>> Pessimistic. Synchronization <<Aspect>> Optimistic. Synchronization Timestamped. Type CC <<Aspect>> Optimized. Timestamp Timestaped. Repository Concurrency. Manager <<Aspect>> Data. Collection. Customization Persistence. Control <<Aspect>> Transaction. Control <<Aspect>> Client. Side D <<Aspect>> Server. Side DM IPersistence. Mechanism Remote (from java. rmi) 17

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

19

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

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

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

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

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

New activity example n Validate Functional Prototype n n n 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: . . . 25

Experimentation n Formal study with graduate students n analysis of the progressive approach n n n n 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 26

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

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

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

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

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

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

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

Study n Results using the progressive approach n n n 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 n not enough participants low degree of precision (confidence interval) Framework to perform others experiments 34

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

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

Tool support Software Java source files AJa. TS Transformations descriptions Transformation engine – AJa. TS Eclipse plug-in Aspect. J framework Generated aspects Programmer 37

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

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

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

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