Towards a Generic Aspect Oriented Design Process

Andrew Jackson, Siobhán ClarkeDistributed Systems GroupTrinity College Dublin

2

Problems?

AOD LanguagesAOD Processes

Many different levels of design

abstractionHigh-middle-low

Heuristics for AOD not are not typically across all

approaches – AOSDUC, AVA and Theme are

examples of exceptions

We surveyed 22 AOD approaches (aosd-europe.net - 9000+ downloads)

There is scope for language integration – The better

language features can be composed into a new AOD

language

AOD Approach

Different levels of concern

separation are supported

3

Survey uncovered…

Concern model design

Composition specification

Behavioral & structural views

Meta model

UML is a basis for many AOD languages and processes

Extension needed to support crosscutting

Crosscutting must be described in all views

Crosscutting and non-crosscutting concern design

Approaches place emphasis on particular views

Many approaches are prog-language dependant – needs to be more genericAlso needs to be visual

Composition semantics

Typically not well defined

UML

4

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…

5

AOD within the Development Methodology

Domain Analysis

Requirements Gathering

Requirements Analysis

System specification

Architecture Design

System Design

Development

Testing

Deployment

Training

Maintenance

System Quality Assurance

Process Quality Assurance

Modularisation of concerns

Composition of concerns

Conflicts or cooperation

Traceability to earlier & later stages

Mapping of earlier & later constructs

RUP

XP

Met

hodo

logy

Sur

vey

Req

uire

men

ts G

athe

ring

Ses

sion

General Requirements

Open, customizable & independent

Artefact and process metrics

Support staged adoption

Provide product line/family support

Core Requirements

Extend successful methodologies

6

Initial Process Meta-Model

Design concern Module(s)

Design composition Specification(s)

Verify Refine

Concern identification & classification

Design test(s)

Reuse design(s)

Open & traceability – allows mappings to many pre-design

activities AO / non-AO

Extend methods – testing is more and more becoming

central to existing methods

Product lines, allows commonalities to be captured and applied in

different scenarios

PIM/PSM – traceability through incremental specialisation

Formal methods integration & metrics can be applied

Core requirements

7

Design process (CAM) RefineHigh level design

Design process (DAOP) RefineMiddle level design

Design process (CORBA)Low level design

Platform independent and/or composition design detail defined

Platform specific concern design and/or composition

Concern and/or composition analysis

Refinement

Refine

8

A case study Auction System – Evaluate fondue

http://lgl.epfl.ch/research/fondue/case-studies/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

9

Refinement Iteration 1

Concern identification & classification

Design concern Module(s)

Design composition Specification(s)

Refine

Concern identification & classification

Design concern Module(s)

Design by reuse

Design composition Specification(s)

Refine

Concern identification & classification

Design concern Module(s)

Design composition Specification(s)

Inputs to the process were tangled use casesUser-goal level: Bid-Offer-Increases creditSub Functional: Search-Close-Identify user

Concern identification allows: reject input / accept AO input / build non AO model

Concern identification allows: reject input / accept AO input / build non AO model

No crosscutting - so just build a declaratively complete concern

Specify integration – resolving conflicts and cooperation issues

10

Process result – first pass

11

Concern identification & classification

Design concern Module(s)

Design composition Specification(s)

Refine

Concern identification & classification

Design concern Module(s)

Design by reuse

Design composition Specification(s)

Test &Refine

Concern identification & classification

Design concern Module(s)

Design composition Specification(s)

New crosscutting found other concerns altered :View, Registration,

Transfer Credit, Join, Message, Observe

Design Crosscutting concern by beginning at the crosscutting interface and work toward defining the particular views

Through designing the input concerns

the crosscutting concerns became

clear

Observer was predefined in previous work and instead of re-defining I decided to reuse it!!!

Crosscutting composition was then specified

Refinement Iteration 2

12

Process result – second pass

13

Concern identification & classification

Design concern Module(s)

Design composition Specification(s)

Refine

Concern identification & classification

Design concern Module(s)

Design by reuse

Design composition Specification(s)

Refine

Concern identification & classification

Design concern Module(s)

Design composition Specification(s)

Design the crosscutting setup concern

Through Testing the design by composition a new concern emerged

– the “setup” concern

Design the composition specification in relation to all the

other concern as setup affects the entire system

Refinement Iteration 3

14

End result

Next phase would be to implement… AO or

OO?

15

Design & CompositionConcern

CompositionConcern

Concern Composition

Concern

Concern

Concern

Composition(a) Continual cumulative composition

(b) Once off composition

Concern

Concern

Concern

Composition

Concern Composition

Concern

Concern

Concern

Concern

(c) Hierarchical compositionC

ompo

site

Com

posi

te

Com

posi

tes

Com

posi

te

Used when input is imperfect or changeable – also in

methodologies that require products after each release

i.e. XP

Used when input provides clear descriptions of concerns and

concern relationships – may be used in waterfall methodologies – or

where requirements/architecture are stable

More useful when a component based approach is being taken. Is

applicable where systems decomposed into separate sub

systems

16

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

17

The EndThank you….

Questions\CommentsLunch?

18

Initial Language

UML 2.0 meta-model extension

AO meta-model (e.g. Theme)

AspectJ profile HyperJ profile ………

Platform independent

Platform specific

Modelling crosscutting and non-crosscutting concerns

19

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

20

Extras Here are the extra slides I am amending – it is my

intuition that these may help me answering questions on the process…

21

Analyse inputs

Identify concerns relevantduring design

Create poorly modularised design

Reanalyse

Identify all concerns

Inputs are scattered and tangled

Separated concerns identified & classified

Classify concerns

Crosscutting concerns Non-crosscutting concerns

Other classifications

Verify

Refine

ignore

Concern id & classification

22

Design Tests

Verify Refine

Design test(s)

Reuse design test(s)

Design tests for composition Specification(s)

Design test(s) for concern modules

Compose design test(s) for Composite concern modules

Reuse composition specifications test(s)

23

Contextualize reused Designs

Search design repository

Assess design relevance

Do or do not select for reuse

Do

Design new concern & compositions

Assess potential for reusability

Do Not

Reengineer & Decontextualize

Add to design repository

Yes - reusable

No Match>= 1 Match

Design prepared for reuse

Test design

Verify

Design by reuse

24

Design concern module

Non-crosscutting

Define concern Interface

Crosscutting

Define concern crosscutting Interface

Create structural design views

Create structural design views of crosscutting

Create behavioralDesign views

Create behavioural design views of crosscutting

Test designVerify

Identify & designsub-concern modules

Refine

Other classifications

Concern Module Design

25

Design composition specification

Determine structural composition

Define how structure is to be composed

Determine behavioral composition

Define where structure is to be composed

Define where behavior is to be composed

Define how behavior is to be composed

Identify & resolve conflict issues

Test compositionVerify

Refine

Determine order for composition

Composition Specification Design