AOSD and AIP

1
AOSD and AIP

• Therapon Skotiniotis Karl Lieberherr
• Northeastern University
• Boston, MA 02115 USA

2
Outline

• Crosscutting Concerns
• How AIP and AOSD handle these type of concerns
• Clear some of the terminology
• Shared concepts
• Join point models
• AIP using AOSD, AOSD using AIP
• Unmatched
• AIP but not in AOSD
• AOSD but not AIP

3
Crosscutting Concerns

• In AIP
• Faceplate
• Graphic Display
• Graphic Element
• History Collector
• History Collector and Object Trend
• Master to denote dependence
• Aspect Object Architecture Document pp.117
• Inheritance is an attribute with control over the
  depth to which it applies

• AOSD Aspects
• Integration into Afw to provide default behavior
• Core and heavily used Concerns within AIP
• Better performance and abstract out technical
  /implementation details (OPC)
• Non-Orthogonal behavior
• No specific mechanism to handle non-orthogonal
  behavior.

4
Crosscutting Concerns AIP
Aspect Object Types
Aspect Directory
a1
a2
5
Capturing Crosscutting Concerns

• In AIP
• Aspects define a piece of information
• Aspect Objects are the real world entities made
  up of Aspect Definitions
• Aspects can be viewed differently depending on
  their usage within the AIP system
• Source code level

• AOSD
• An Aspect can have more than one piece of
  information
• Open Classes
• AspectJ introductions XEROX
• HyperJ slices IBM
• Aspectual Collaborations NEU
• Subject-Oriented Programming
• Evolved to Multi-dimensional Separation of
  concerns
• Binary code level (instrumentation)

6
Crosscutting Concerns AIP
Aspect Object Types
Aspect Directory
JoinPoint
a1
SOP
a2
7
Capturing Crosscutting Concerns

• Both allow for the same fragments of code to
  be viewed according to a subjects extrinsic
  view of the system.
• Intrinsic view remains static
• reusability
• encapsulation
• JoinPoint in AIP
• AspectObject Types.
• Definition at compile-time and/or runtime (COM).
• Duplicate information, verbose (need do specify
  at each Aspect Object Type def)

8
Capturing Crosscutting Concerns (cont)

• Subjective Programming has evolved to
  HyperSpaces
• IBMs HyperJ supports this paradigm
• Bytecode Level
• Capture Program slices at bytecode level
• Allows reattachement of slices to produce
• A new self contained slice
• A new complete program

check is the concern mapped from one
Hyperspace to another, as a Dimension
9
Capturing Crosscutting Concerns (cont)

• AspectJ
• Program analysis using call graph analysis
• Notion of abstract aspects and pointcuts to
  promote reuse
• Design approaches to achieve higher reusability
• Requires all source code
• Advice is weaved. You are running a transformed,
  TANGLED version, of your code.

foo()
foo()
foo()
10
Capturing Crosscutting Concerns (cont)

• AIP
• Hooks provide a set of points at which checks can
  be made
• NameHooks
• Trackers /Enumerators
• A means to keep track of changes to AIP Aspects
  of interest for this Aspect Object

foo()
foo()
foo()
11
Capturing Crosscutting Concerns (cont)

• Ideally we are on the same track
• Ability to specify points within your execution
  to which you want to add extra behavior
• Specify these points
• Specify program code that will be attached to
  these points
• What triggers the points and thus the code that
  is attached to each point
• The point, and how you glue the points together
  matters !

foo()
foo()
foo()
12
Client Server and the Framework Approach

• AIP
• Afw to provide the necessary services
• ASO
• Delegates requests
• Responsible for activation order and Aspect
  definition retrieval from Aspect Directory
• Framework enforces an interaction specification
  contract, with an API

• AOSD
• Aspect Moderator Framework Constantinides
  et.al.
• Requests are delegated to a Proxy
• From the Proxy then to the Moderator to activate
  and execute Aspectual code
• Interaction specification is enforced through
  Java interfaces.

13
Client Server and the Framework Approach (cont)

• AIP
• Afw to provide the necessary services
• ASO
• Delegates requests
• Responsible for activation order and Aspect
  definition retrieval from Aspect Directory
• Framework enforces an interaction specification
  contract, with an API

• AOSD
• JAC AOPSYS
• Aspects ? Java Wrappers
• AspectComponentManager
• Delegates Requests
• Responsible for order of activation and enforces
  composition rules
• Interaction specification through composition
  rules and deployment of Reflection

14
Structure Shyness

• AIP
• Most information is found within structures
  scattered around the Network
• Retrieval of information implies traversal of
  these Structures
• Abstracting traversal specification allows for
  less brittle code ( operators in Name Paths)
• Facilitates ease of use by programmers

• AOSD
• DemeterJ/DJ NEU
• Structures
• Class Hierarchies
• Objects at runtime
• Abstraction mechanisms allow for Adaptive
  Programming
• from A via B to
• Reusable
• Not tightly couples with underlying structure

15
Structure Shyness
from BusRoute through BusStop to Person
busStops
BusRoute
BusStopList
buses
0..
BusStop
BusList
waiting
0..
passengers
Bus
PersonList
Person
0..
16
Structure Shyness
from BusRoute through BusStop to Person
villages
BusRoute
BusStopList
busses
VillageList
busStops
0..
0..
BusStop
BusList
Village
waiting
0..
passengers
Bus
PersonList
Person
0..
17
Loose ends (AIP)

• AIP
• Extra grouping facilities
• Aspect Category
• Composite Aspect Object Type
• Control over inheritance
• Connectivity in AIP handles more complex runtime
  deployment
• Connectivity package
• Connector
• Connectivity Component
• Notion of Types for Aspects

• AOSD/OOP
• Could be (mostly)simulated through careful design
  of Class hierarchies (e.g. Mouse example)
• No control over depth of inheritance. Need to
  alter your design (patterns)
• Runtime deployment is ad-hoc
• Specific to each technology AMF or JAC
• There is still no formal notion of Types for
  Aspects

18
Loose ends (AOSD)

• AIP
• COM allows for dynamic alteration of the Aspect
  Objects. Appears to be too wordy
• Does no accommodate Traversal Related concerns (
  is there no need ?)
• Collaborations of Aspect Objects can only be
  facilitated through Composite Aspect Objects
• Not aspectual
• Less reusable

• AOSD/OOP
• Dynamic JoinPoint model allows for more generic
  (and complex) introductions of advice.
• Traversal Related concerns can be addressed
  through Demeter Tools
• Aspectual Collaborations can abstract over
  collaborations of Classes/Aspects

19
Capturing Crosscutting Concerns (cont)

• Aspectual Collaborations (AC)
• Allows the definitions of Classes with expected
  behavior to be filled in later.
• Provides a generalized solution with higher
  potential for reuse and program extensions of
  collaborating entities
• Separate Compilation and Type Safe

Composition Rules
Provided?
Expected
20
Client Server and the Framework Approach (cont)

• Benefits
• Runtime deployment of Aspectual code
• Runtime reconfiguration
• Software Stability
• Well tested framework provides the system base
• Enforcing interaction protocol between the
  framework and software components provides stable
  system extension and integration
• Software manageability
• Separation of Core system code from customer
  specific code
• Integration of third party software
• Integration of third party software must ensure
  the API/interaction specification between the
  Framework and Third Party Software