1
An Aspect-Oriented
Implementation Method
Sérgio Soares CIn – UFPE
Orientador: Paulo Borba
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
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 Distribution
Business logic
Data management Concurrency control
User interface Distribution
Business logic
Data management
The major problem
7
How can we
avoid those OO limitations?
support developers?
increase productivity?
Research
Using aspect-oriented programming (AOP)
User interface Distribution
Business logic
Data management
9
Using aspect-oriented programming (AOP)
User interface Distribution
Business logic
Data management Concurrency control
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 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
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
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
Software requirements
Concern identifier
AOP OOP
Aspects Classes
Interfaces Executable
software W
E A V E R Concerns
UI and business logic use OOP
Distribution, data management, and
concurrency control use AOP
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
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
IPersistenceMechanism connect()
disconnect() beginTransaction() commitTransaction() rollbackTransaction() getCommunicationChannel() releaseCommunicationChannel()
HttpServlet
<<UserInterface>>
HWPersistenceMechanism
<<PersistenceMechanism>>
ComplaintRepositoryRDBMS
<<PersistentDataCollection>>
Complaint getCode()
<<BusinessBasic>>
ComplaintRepositoryArray
<<NonpersistentDataCollection>>
IComplaintRepository insert(Complaint)
remove(code) update(Complaint) search(code) : Complaint ServletUpdateComplaint
<<UserInterface>>
ComplaintRecord update(Complaint)
<<BusinessCollection>>
HWFacade
<<Facade>>
<<Business-DataInterface>>
<<PersistenceMechanismInterface>>
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
x y
a a a a a b a b a b a b
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
User interface Distribution
Functional requirements
Persistent data management
Non-persistent data management
Milestone (end of iteration) Functional iteration
Progressive approach
Implemented concerns
time
a a a a
x’ y’
b b b b
a a a a
a and b are use cases, sets of use cases, or use-cases
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
Combining with RUP
Implementer Client
Implement Component
Implement Persistence
Implement Distribution
Control Concurrency
... ...
Architect Project
Manager Designer
Validate Functional Prototype
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: ...
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
Subjects expertise - academic
Expertise
29
Subjects expertise - industrial
Expertise
1 - OITC 2 - < 6m 3 - 6m-2y 4 - 2y-4y 5 - 4y-6y 6 - > 6y
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
-89% -56%
Study data – time to deliver executable prototypes
-75%
-72% -66%
33
Study data – times do deliver
first usable/testable prototype
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
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
AJaTS
Transformations descriptions
AJaTS
Transformations descriptions Software Java
source files Software Java
source files
AspectJ framework
Generated aspects Generated
aspects Programmer
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
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
