Aspect-Oriented Software Development (AOSD)

1
Aspect-OrientedSoftware Development(AOSD)

• An Introduction
• Shmuel Katz
• Part of this lecture
• Johan Brichau Theo DHondt
• johan.brichau_at_vub.ac.be, tjdhondt_at_vub.ac.be

2
Topics

• Introduction---a little philosophy
• Programming with aspects AspectJ
• More details on AspectJ
• Requirements for aspects
• Aspect specifications and proof obligations
• Categories of Aspects
• Design for Aspectsextending UML
• More Aspect languages
• Composition Filters
• CeasarJ

3
More topics

• Verification for aspects using static analysis
  and model checking
• Applications for aspects
• Middleware
• Security
• Product lines
• Interference and other interactions among aspects

4
Course requirements

• Final Exam 70
• Write some aspects in AspectJ (an extension of
  Java), in pairs 20
• Attend lectures and provide feedback
  10
• BUT if final exam grade is lt50, the final grade
  is 100 of the final exam grade

5
Goals of the course

• Enjoy a (2 point) course where a new modularity
  concept is presented
• Become acquainted with how aspects can be
  incorporated into system development at various
  stages
• Learn AspectJ to allow writing aspects
• Survey the variety of aspect languages and
  verification techniques
• See how aspects could help in ongoing research or
  in defining new topics

6
Software Engineering Complexity
Functional Requirements

Non-functional Requirements

Software Development Requirements
gt
Complexity
Need for adequate software engineering techniques
7
Evolution of Software Engineering
Complex code Difficult to read write Poor
evolvability Poor maintainability Poor
reusability
Machine-level Programming
8
Evolution of Software Engineering
Easier to read write Poor evolvability Poor
maintainability Poor reusability
Language features for common program patterns
Structured Programming
9
Evolution of Software Engineering
Easier to read write Improved
evolvability Improved maintainability Improved
reusability
Procedural abstractions Parameter passing
Recursion
Procedural Programming
10
Evolution of Software Engineering
Easier to read write Better evolvability Bette
r maintainability Better reusability
Module abstractions
Modular Programming
11
Evolution of Software Engineering
Easier to read write Better evolvability Bette
r maintainability Better reusability
Encapsulation Polymorphism Inheritance
Object-oriented Programming
12
Evolution of Software Engineering
Aspect-orientation
Component orientation
Generative Programming
....
13
Separation of Concerns
Let me try to explain to you, what to my taste is
characteristic for all intelligent thinking. It
is, that one is willing to study in depth an
aspect of ones subject matter in isolation for
the sake of its own consistency, all the time
knowing that one is occupying oneself only with
one of the aspects. We know that a program must
be correct and we can study it from that
viewpoint only we also know that it should be
efficient and we can study its efficiency on
another day But nothing is gained on the
contrary by tackling these various aspects
simultaneously. It is what I sometimes have
called the separation of concerns
E.W. Dijkstra
14
Separation of Concerns
Concern Something the developer needs to care
about (e.g. functionality, requirement,..)
Separation of concerns handle each concern
separately

• Modular programming
• Organize code by grouping functionality
• Need for language mechanisms
• Drives evolution of languages paradigms

14
15
Separation of Concerns
16
Crosscutting Concerns
Concern Implementation
A Object 1
B Object 2
C Object 3
D Object 4
E Object 1,2,3
Typical examples synchronisation, error
handling, timing constraints, user-interface,
... Also concerns of a specific application,
e.g. login functionality in webshop, business
rules, ...
17
Crosscutting Concern Example

• Implementation of Apache Tomcat webserver
• Analyzed implementation of 3 concerns
• XML parsing concern
• URL pattern matching concern
• Logging concern

18
XML parsing concern
Good modularization XML parsing is implemented
in its own module
19
URL pattern matching concern
Good modularization URL pattern matching is
implemented in 2 modules
20
Logging concern
Bad modularizationlogging is implemented in a
lot of different places, spread throughout other
modules
21
Crosscutting concerns

• Evolution ?
• Reuse ?
• Maintenance ?

Cumbersome! It requires breaking all
modularisations that are crosscut!
Need for better language / better paradigm
22
Tyranny of the Dominant Decomposition
Given one out of many possible decompositions of
the problem... (mostly core functionality
concerns) ...then some subproblems cannot be
modularized!
(non-functional, functional, added after the
facts,...)

• Not only for a given decomposition
• But for all possible decompositions
• Not only in object-orientation!
• Also in other paradigms
• Not only in implementation!
• Also in analysis design stages

23
Introduction to AOSD
Evolution of Software Engineering techniques
Why AOSD ?
Advanced Separation of Concerns
Aspect-orientation, Aspectual decomposition
What is AOSD ?
Asymmetrical vs symmetrical approaches
Aspect-orientation in the software development
lifecycle
24
Aspectual Decomposition

• Modularize crosscutting concerns
• Code scattering (one concern in many
  modules)
• Code Tangling (one module, many concerns)

24
25
Aspectual Decomposition
Many existing programming languages, including
object-oriented languages, procedural languages
and functional languages, can be seen as having a
common root in that their key abstraction and
composition mechanisms are all rooted in some
form of generalized procedure.
Gregor Kiczales
26
Explicit invocation
27
Aspects
Implicit invocation
28
Implicit Invocation
Aspect captures its own invocation that crosscuts
other modules
Objects are invoked by other objects through
message sends
29
Aspects
Aspect
Control over implicit invocation
Aspect applicability code
Aspect functionality code
Aspects functional implementation
30
Joinpoints
Program
A join point is a point of interest in some
artefact in the software lifecycle through which
two or more concerns may be composed.
Object 1 data
Object 4 data
Object 2 data
Object 3 data
Examples in implementation artefact - message
sends - method executions - error throwing -
variable assignments - ...
Aspect
joinpoint ?
31
Join point Model
A join point model defines the kinds of join
points available and how they are accessed and
used.

• Specific to each aspect-oriented programming
  language
• E.g. AspectJ join point model key points in
  dynamic call graph

32
Pointcuts
A pointcut is a predicate that matches join
points. A pointcut is a relationship join point
-gt boolean, where the domain of the relationship
is all possible join points.
Aspect
Aspect applicability code
Aspect functionality code
33
Advice
Aspect
Aspect applicability code
Aspect functionality code
34
Example Synchronised buffer
class Buffer char data int
nrOfElements Semaphore sema bool isEmpty()
bool returnVal sema.writeLock()
returnVal nrOfElements 0
sema.unlock() return returnVal
Synchronisation concern Buffer functionality
concern
Tangling! Crosscutting concerns!
35
Synchronisation Concern
When a Buffer object receives the message
isEmpty, first make sure the object is not being
accessed by another thread through the get or put
methods
36
Synchronisation as an Aspect
When a Buffer object receives the message
isEmpty, first make sure the object is not being
accessed by another thread through the get or put
methods
When to execute the aspect (pointcut)
Composition of when and what (kind of
advice) What to do at the join point (advice)
37
Synchronisation as an Aspect
class Buffer char data int
nrOfElements bool isEmpty() bool
returnVal returnVal nrOfElements 0
return returnVal
before reception(Buffer.isEmpty)
sema.writeLock() after reception(Buffer.isEmpt
y) sema.unlock()
38
Example Domain-specific Aspect Language
class Stack push(...) ... pop() ...
...
coordinator BoundedStackCoord selfExclusive
pop,push mutExclusive pop,push
Synchronisation concern is separated from other
concerns using an aspect language for
synchronisation
39
Advice code

• Domain-specific Aspect Languages
• Language targeted towards one kind of
  aspectCOOL RIDL (Synchronisation)RG (Loop
  fusion optimization)
• Describe a concern
• But
• Limited in expressiveness
• New Language for each kind of aspect??
• General-purpose Aspect Languages
• More-general aspects possible
• describe crosscutting

39
40
Other Examples

• Loggingwrite something on the screen/file every
  time the program does X
• Error Handlingif the program does X at join
  point L then do Y at join point K
• Persistenceevery time the program modifies the
  variable v in class C, then dump a copy to the
  DB
• User Interfacesevery time the program changes
  its state, make sure the change is reflected on
  the screen

40
41
Advantages of aspects

• A system concern is treated in one place, and
  can be easily changed
• Evolving requirements can be added easily with
  minimal changes to previous version
• Configurable components become practical (On
  demand computing)
• Reuse of code that cuts across usual class
  hierarchy to augment system in many places

42
AspectJ Figure Editor

• 42

43
AspectJ Figure Editor
aspect modularity cuts across class modularity
DisplayUpdating

• 43

44
AspectJ Figure Editor
aspect DisplayUpdating pointcut
move(FigureElement figElt) target(figElt)
(call(void FigureElement.moveBy(int, int))
call(void Line.setP1(Point))
call(void Line.setP2(Point))
call(void Point.setX(int))
call(void Point.setY(int)))
after(FigureElement fe) move(fe)
Display.update(fe)

• 44

45
Modularity for Cross-cutting

• For distributed
• Deadlock detection is the system stuck?
• Monitoring gathering information on messages
• Fault-tolerance resending messages on new paths
• For Object Oriented
• Monitoring and debugging
• Adding security Encode/decode messages
• Preventing overflow Catch and correct when
  needed
• Enforcing a scheduling policy
• Analyzing QOS and Performance

46
Oblivious Base Systems

• The base system is unaware of the aspect, and can
  operate without it
• Linked to implicit invocation
• Often seen as a characteristic of AOSD
• Take it or leave it view of aspects
• May not always be reasonable when the base
  depends on the existence of an aspect treating a
  concern

47
Weavers

• Compilers (or interpreters) of an Aspect Language
• Weaves the aspects crosscutting code into the
  other modules

Source-to-source transformations
Bytecode transformations
Reflection
Aspect-aware virtual machines
48
Asymmetric vs. SymmetricDecompositions
Described until now
Asymmetric Symmetric
Crosscutting concerns modularized in special module (aspect). All concerns modularized in same kind of module
49
Symmetric Approaches
Multidimensional Separation of Concerns
50
Symmetric Approaches
composition specification in terms of join
points
51
The Synchronised buffer, revisited
class Buffer char data int
nrOfElements bool isEmpty() bool
returnVal returnVal nrOfElements 0
return returnVal
class Synchronizer Semaphore sema bool
lock() return sema.writeLock bool
unlock() return sema.unlock()
52
AOSD
... Requirements Engineering
... Architecture
... Design
Aspect-oriented...
... Programming
... Verification techniques
... Middleware
53
AO Requirements Engineering
Arcade, ARGM, Aspectual Use Cases, Cosmos,
AOREC,...

• Need to identify aspects early in development
  process
• Representation of crosscutting concerns in
  requirements analysis

54
A Security Requirement Aspect
Constrain all requirements specified in all user
viewpoints by the top-level security
requirement. Constrain all requirements in
administrator viewpoint by the security
policy for administrators. Constrain all
requirements in manager viewpoint by the
security policy for managers.
pointcut
advice kind
advice behavior
55
AO Design
AODM, Theme/UML, SUP, UFA, AML, CoCompose ....

• Specification of aspects at the design level
• Notation
• Composition specification
• Precise semantics of aspect integration

56
Theme/UML Example
Adapted from S. Clarke 2005
57
Theme/UML Example
Adapted from S. Clarke 2005
58
AO Programming
JAsCo, CaesarJ, AspectS, Object Teams, HyperJ,
JBOSS AOP, Compose, DemeterJ, AspectC, ...

• Aspect languages aspectual language features
• Advice models
• Join point models
• Pointcut languages
• Development support
• IDEs

59
(No Transcript)
60
AO Middleware

• Increasing complexity in distributed middleware
• Aspect technology to the rescue
• Hiding distribution details
• Common domain-specific services
• ...

60
61
AO Verification Techniques

• Adaptation of software verification techniques to
  accomodate AO
• Verification of aspect weaving
• Aspect interactions / interferences

61
62
AOSD Timeline

Advanced Separation of Concerns
Aspect-Oriented Software Development
1997
2001
2002
2004
2000
Introduction of AOP
First AOSD Conference
AOSD EU
AOP Workshops
Advanced Separation of Concerns Workshops
63
EU Network on AOSD
64
Conclusions

• Separation of Concerns
• Crosscutting concerns phenomenon
• Aspect-orientation
• Modularisation of crosscutting concerns
• Aspects implicit invocation
• Join points, pointcuts, advices
• Aspect-oriented Software Development
• AO in the entire software development lifecycle

65
Moreover
The fun has just begun !
Kiczales 2003
Aspect-orientation is a young and dynamic
research area