Towards a Generic Aspect
Oriented Design Process
Andrew Jackson, Siobhán Clarke
Distributed Systems Group
Trinity College Dublin
Problems?
We surveyed 22 AOD approaches
(aosd-europe.net - 9000+ downloads)
Different levels of
concern
separation are
supported
AOD Approach
AOD Processes
Heuristics for AOD not are
not typically across all
approaches – AOSDUC,
AVA and Theme are
examples of exceptions
Many different
levels of design
abstraction
High-middle-low
AOD Languages
There is scope for language
integration – The better
language features can be
composed into a new AOD
language
2
Survey uncovered…
UML is a basis for many AOD
languages and processes
UML
Extension needed to
support crosscutting
Meta model
Approaches place emphasis
on particular views
Behavioral &
structural views
Crosscutting must be
described in all views
Crosscutting and noncrosscutting concern design
Concern model
design
Typically not
well defined
Composition
specification
Many approaches are proglanguage dependant – needs
to be more generic
Also needs to be visual
Composition
semantics
3
Problem…

AOD is useful on its own – it can be complemented by
full methodology support!
 AORE/AOA >>> AOD
 Concerns may be identified and classified before
the designer needs to translate requirements into
architecture conformant design
 AOD >>> OOP/AOP
 Allows expression of concerns that are not directly
resizable i.e. performance…
4
AOD within the Development Methodology
Core Requirements
Domain Analysis
Requirements Gathering Session
Methodology Survey
Requirements Gathering
Requirements Analysis
System specification
Architecture Design
System Design
Modularisation of concerns
Composition of concerns
Conflicts or cooperation
Traceability to earlier & later stages
Mapping of earlier & later constructs
Development
Testing
Deployment
Training
Maintenance
XP
General Requirements
Open, customizable & independent
Artefact and process metrics
Extend successful methodologies
System Quality Assurance
Support staged adoption
Process Quality Assurance
Provide product line/family support
5
RUP
Initial Process Meta-Model
Open & traceability – allows
mappings to many pre-design
activities AO / non-AO
Extend methods – testing is more
and more becoming central to
existing methods
Concern identification
& classification
Design test(s)
Product lines, allows commonalities to
be captured and applied in different
scenarios
Design composition
Reuse design(s)
Specification(s)
Verify
Core requirements
Design concern
Module(s)
Refine
PIM/PSM – traceability through
incremental specialisation
Formal methods integration & metrics
can be applied
6
Refinement
Concern and/or
composition analysis
High level design
Design process (CAM)
Refine
Platform independent and/or composition
design detail defined
Middle level design
Design process (DAOP)
Refine
Platform specific concern design and/or composition
Refine
Design process (CORBA)
Low level design
7
A case study

Auction System – Evaluate fondue





http://lgl.epfl.ch/research/fondue/casestudies/auction/problem-description.html
Like ebay.com ubid.com - web
Buy items at auction
 Highest bid wins… join – bid = message notification
Sell items by auction
 Closes after a certain time period
And all the regular stuff
 Login-out
 Manage account
8
Refinement Iteration 1
Concern identification
& classification
Design concern
Module(s)
Inputs identification
to the process were
tangled
use cases
Concern
Concern
identification
User-goal
level: Bid-Offer-Increases
credit
& classification
& classification
Sub Functional: Search-Close-Identify user
Design concern
Design composition
Concern
identification
allows:
reject input /
Module(s)
Specification(s)
accept
AO model
model
acceptAO
AOinput
input/ /build
build non
non AO
Design by reuse
No crosscutting - so just build a
declaratively complete concern
Design composition
Specification(s)
Design
composition
Specify integration
– resolving
conflicts and
Specification(s)
Design concern
cooperation
issues
Module(s)
Refine
Refine
9
Process result – first pass
10
Refinement Iteration 2
Through designing
the input concerns
Concern
identification
the crosscutting
& classification
concerns
became
clear
Design concern
Module(s)
Concern identification
& classification
Concern identification
& classification
New crosscutting found other concerns altered
Designconcern
Crosscutting
concern by beginning at
Design
:View, Registration,
Design
concern
the
crosscutting
interface
and work
toward
Module(s)
Transfer
Credit, Join,
Message,
Observe
Module(s)
defining the particular views
Design by reuse
Design composition
Specification(s)
Design composition
Specification(s) Observer
wascomposition
predefined in previous work and instead
Design
of re-defining I decided to reuse it!!!
Specification(s)
Refine
Crosscutting composition was then specified
Test &Refine
11
Process result – second pass
12
Refinement Iteration 3
Concern identification
& classification
Through Testing the design
by
Concern
identification
composition
a new concern emerged –
& classification
the “setup” concern
Design concern
Module(s)
Design concern
Module(s)
Design the composition
Design by reuse
specification in relation to all the
other concern as setup affects the
Design composition
entire system
Specification(s)
Design composition
Specification(s)
Design the crosscutting setup concern
Refine
Refine
13
Concern identification
& classification
Design composition
Specification(s)
Design concern
Module(s)
End result
Next phase would be to
implement… AO or
OO?
14
Concern
Concern
Used when input provides clear
descriptions of concerns and concern
Concern – may beComposition
relationships
used in
waterfall methodologies – or where
requirements/architecture are stable
Concern
Composition
Concern
Composite
Used when input
is imperfect
Concern
or changeable – also in
methodologies that require
Concern
products after
each release
i.e. XP
Concern
Composition
Concern
Concern
Composite
(a) Continual cumulative composition
More useful when (c)
a component
based
Hierarchical
composition
approach is being taken. Is applicable
Composition
where
systems decomposed into
Concern
separate sub systems
Composite
Composites
Design & Composition
15
Composition
(b) Once off composition
Concern
Concern
Concern
Future and ongoing work


Process
 Case study – Auction and other systems will be used
to test different configurations of the design process
 Look at process simulation???
Language
 Integration of three models of AO
 AspectJ
 Component
 Subject oriented
16
The End
Thank you….
Questions\Comments
Lunch?
17
Initial Language
UML 2.0 meta-model extension
Modelling crosscutting and
non-crosscutting concerns
Platform
independent
AO meta-model (e.g. Theme)
Platform specific
AspectJ profile
HyperJ profile
18
………
Auction System Design
Result of following the AOD process using an integration
AOSUC, Theme/UML and SUP processes
Now - walk through the process describing one
instantiation of this process
19
Extras

Here are the extra slides I am amending – it is my
intuition that these may help me answering questions
on the process…
20
ignore
Concern id & classification
Analyse inputs
Reanalyse
Separated concerns
identified & classified
Identify concerns relevant
during design
Inputs are scattered
and tangled
Create poorly
modularised design
Identify all concerns
Refine
Classify concerns
Verify
Crosscutting concerns
21
Non-crosscutting concerns
Other classifications
Design Tests
Design test(s)
Reuse design test(s)
Design test(s) for
concern modules
Design tests for composition
Specification(s)
Compose design test(s) for
Composite concern modules
Reuse composition
specifications test(s)
Verify
Refine
22
Design by reuse
Search design repository
No Match
Test design
>= 1 Match
Assess design relevance
Design new
concern & compositions
Assess potential
for reusability
Do or do not
select for reuse
Do Not
Do
Contextualize reused
Designs
Yes - reusable
Reengineer &
Decontextualize
Add to design repository
Design prepared 23
for reuse
Verify
Concern Module Design
Design concern
module
Non-crosscutting
Identify & design
sub-concern modules
Crosscutting
Other classifications
Define concern
Interface
Define concern
crosscutting Interface
Create structural
design views
Create structural design
views of crosscutting
Create behavioral
Design views
Create behavioural design
views of crosscutting
Verify
Refine
Test design
24
Composition Specification Design
Design composition
specification
Determine order for
composition
Determine structural
composition
Determine behavioral
composition
Define where structure
is to be composed
Define where behavior
is to be composed
Define how structure
is to be composed
Define how behavior
is to be composed
Identify & resolve conflict issues
Verify
Test composition
Refine25