Title: AOSD and AIP
1AOSD and AIP
- Therapon Skotiniotis Karl Lieberherr
- Northeastern University
- Boston, MA 02115 USA
2Outline
- 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
3Crosscutting 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.
4Crosscutting Concerns AIP
Aspect Object Types
Aspect Directory
a1
a2
5Capturing 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)
6Crosscutting Concerns AIP
Aspect Object Types
Aspect Directory
JoinPoint
a1
SOP
a2
7Capturing 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)
8Capturing 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
9Capturing 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()
10Capturing 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()
11Capturing 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()
12Client 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.
13Client 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
14Structure 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
15Structure Shyness
from BusRoute through BusStop to Person
busStops
BusRoute
BusStopList
buses
0..
BusStop
BusList
waiting
0..
passengers
Bus
PersonList
Person
0..
16Structure 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..
17Loose 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
18Loose 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
19Capturing 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
20Client 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