1

An Aspect-Oriented Implementation Method

Sérgio SoaresCIn – UFPE

Orientador: Paulo Borba

2

Motivation

OOP allows modularization/separation of concerns Reuse, maintainability, and

productivity User interface, distribution, business

logic, and data management

but has limitations ...

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

Concerns spread and tangled with business logic, UI, and with each other concurrency control distribution data management

OO information system using design patterns

5

The major problem

User interface DistributionBusiness logicData management

Concurrency control

6

User interface DistributionBusiness logicData management

Concurrency control

The major problem

7

How can we

avoid those OO limitations?

support developers?

increase productivity?

Research

8

Using aspect-oriented programming (AOP)

User interface DistributionBusiness logic Data management Concurrency control

9

Using aspect-oriented programming (AOP)

User interface DistributionBusiness logicData management

Concurrency control

10

AspectJ – aspect-oriented programming with Java

11

Joint point model

object A

object B

and returns or throws

a method is called

dispatch

dispatch

a method is called

and returns or throwsa method executes

and returnsor throws

a method executesand returns or throws

Behavior might be changed at join points…

Source: AspectJ Tutorialaspectj.org

12

Advices

Define additional code that should be executed… before after

after returning after throwing

or around

specified join points

13

Static crosscutting

Change types hierarchy Add new members to types Define compile-time errors and

warnings Wrap checked exceptions into

unchecked ones

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

Aspect-oriented development

Softwarerequirements

Concern identifier

AOP

OOP

Aspects

ClassesInterfaces Executable

software

WEAVER

Concerns

UI and business logic use OOP Distribution, data management,

and concurrency control use AOP

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

AspectJ framework

DM

CC

D

Synchronization<<Aspect>>

PessimisticSynchronization<<Aspect>>

OptimisticSynchronization<<Aspect>>

ConcurrencyManager

PersistenceControl<<Aspect>>

TransactionControl<<Aspect>>

DataCollectionCustomization<<Aspect>>

IPersistenceMechanism

ClientSide<<Aspect>>

ServerSide<<Aspect>>

Remote

(from java.rmi)

TimestampedType

Timestamp<<Aspect>>

OptimizedTimestamp<<Aspect>>

TimestapedRepository

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

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

Implemented concerns

time

yx

a a a a b b b ba a a a

Regular approach

User interface DistributionFunctional requirementsPersistent data management Concurrency control

Milestone (end of iteration)

a and b are use cases, sets of use cases, or use-cases scenarios

22

User interface DistributionFunctional requirementsPersistent data management Non-persistent data managementConcurrency control

Milestone (end of iteration)Functional iteration

Progressive approach

Implemented concerns

time

a a a a

y’x’

b b b ba a a a

a and b are use cases, sets of use cases, or use-cases scenarios

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

Combining with RUP

ImplementerClient

ImplementComponent

ImplementPersistence

ImplementDistribution

ControlConcurrency

... ...

ArchitectProject

ManagerDesigner

Validate FunctionalPrototype

Implementer

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

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

Experimentation

Null hypothesis

The times using a progressive approach for aspect-oriented development are not different than using a non-progressive approach

28

Subjects expertise - academic

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8 9 10 11 12 13Subjects

Expert

ise

Java

Databases

JDBC

Dist. Sys

RMI

Servlets

OO design

AspectJ

Use-Cases

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8 9 10 11 12 13

Subjects

Expert

ise

Java

Databases

Dist. Sys

AspectJ

Expertise

1 - OITC 2 - < 6m 3 - 6m-2y

4 - 2y-4y 5 - 4y-6y 6 - > 6y

29

Subjects expertise - industrial

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8 9 10 11 12 13

Subjects

Expe

rtis

e

Java

Databases

JDBC

Dist. Sys

RMI

Servlets

OO design

AspectJ

Use-Cases

Soft. Dev.

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8 9 10 11 12 13

Subjects

Exp

ertis

e

Java

AspectJ

Soft. Dev.

Expertise

1 - OITC 2 - < 6m 3 - 6m-2y

4 - 2y-4y 5 - 4y-6y 6 - > 6y

30

Study

Analysis t-test some differences were statistically

significant and others were not times to implement and test

31

Study data – times to change requirements

Requirements change

0,00

50,00

100,00

150,00

200,00

250,00

300,00

350,00

Change 1 Change 2

Tim

e (

min

ute

s)

Non-progressive

Progressive

-56%-89%

32

0

100

200

300

400

500

600

700

800

900

1000

Iteration 1 Iteration 2 Iteration 3

Tim

e (

min

ute

s)

Non-progressive

Progressive

Study data – time to deliver executable prototypes

-75%

-72% -66%

33

Study data – times do deliver first usable/testable prototype

0

100

200

300

400

500

600

700

1 2 3 4 5 6 7 8 9 10 11

use-case scenarios

tim

e (

min

ute

s)

Non-progressive

Progressive

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

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

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

Tool support

Eclipse plug-in

Transformation engine – AJaTS

AJaTSTransformations

descriptions

AJaTSTransformations

descriptionsSoftware Java

source files

Software Java source files

AspectJframework

Generated aspects

Generated aspects

Programmer

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

Conclusions Aspect patterns and framework

reuse Experiments

guide the implementation method study framework

Tool support productivity increase aspect refactoring in the future

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

Research group

Software Productivity Group

http://www.cin.ufpe.br/spg