1. Towards a Generic Aspect Oriented Design Process Andrew Jackson, Siobhán Clarke Distributed Systems Group Trinity College Dublin

2. 2 Problems? AOD LanguagesAOD Processes Many different levels of design abstraction High-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. 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 generic Also needs to be visual Composition semantics Typically not well defined UML

4. 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. 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 Methodology Survey Requirements Gathering Session General Requirements Open, customizable & independent Artefact and process metrics Support staged adoption Provide product line/family support Core Requirements Extend successful methodologies

6. 6 Initial Process Meta-Model Design concern Module(s) Design composition Specification(s) VerifyRefine 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. 7 Design process (CAM)Refine High level design Design process (DAOP) Refine Middle 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. 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. 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 cases User-goal level: Bid-Offer-Increases credit Sub Functional: Search-Close-Identify user 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. 10 Process result – first pass

11. 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. 12 Process result – second pass

13. 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. 14 End result Next phase would be to implement… AO or OO?

15. 15 Design & Composition Concern Composition Concern Composition Concern Composition (a) Continual cumulative composition (b) Once off composition Concern Composition Concern Composition Concern (c) Hierarchical composition Composite Composites Composite 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. 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. 17 The End Thank you…. Questions\Comments Lunch?

18. 18 Initial Language UML 2.0 meta-model extension AO meta-model (e.g. Theme) AspectJ profileHyperJ profile……… Platform independent Platform specific Modelling crosscutting and non-crosscutting concerns

19. 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. 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. 21 Analyse inputs Identify concerns relevant during 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. 22 Design Tests VerifyRefine 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. 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. 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 behavioral Design views Create behavioural design views of crosscutting Test designVerify Identify & design sub-concern modules Refine Other classifications Concern Module Design

25. 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