1 / 25

Towards a Generic Aspect Oriented Design Process

Andrew Jackson, Siobhán Clarke Distributed Systems Group Trinity College Dublin. Towards a Generic Aspect Oriented Design Process. Problems?. We surveyed 22 AOD approaches (aosd-europe.net - 9000+ downloads). Different levels of concern separation are supported.

harken
Download Presentation

Towards a Generic Aspect Oriented Design Process

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Problems? We surveyed 22 AOD approaches (aosd-europe.net - 9000+ downloads) Different levels of concern separation are supported Many different levels of design abstraction High-middle-low AOD Approach AOD Processes AOD Languages Heuristics for AOD not are not typically across all approaches – AOSDUC, AVA and Theme are examples of exceptions There is scope for language integration – The better language features can be composed into a new AOD language

  3. Survey uncovered… UML is a basis for many AOD languages and processes UML Extension needed to support crosscutting Approaches place emphasis on particular views Meta model Behavioral & structural views Crosscutting must be described in all views Crosscutting and non-crosscutting concern design Composition specification Concern model design Many approaches are prog-language dependant – needs to be more generic Also needs to be visual Typically not well defined Composition semantics

  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 Core Requirements Domain Analysis Requirements Gathering Modularisation of concerns Requirements Analysis Composition of concerns XP System specification Conflicts or cooperation Architecture Design RUP Traceability to earlier & laterstages System Design Mapping of earlier & laterconstructs Methodology Survey Requirements Gathering Session Development General Requirements Testing Deployment Open, customizable & independent Training Artefact and process metrics Maintenance Extend successful methodologies System Quality Assurance Support staged adoption Provide product line/family support Process Quality Assurance

  6. 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 Core requirements Reuse design(s) Design composition Specification(s) Design concern Module(s) Verify Refine PIM/PSM – traceability through incremental specialisation Formal methods integration & metrics can be applied

  7. 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 Low level design Design process (CORBA)

  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 Inputs to the process were tangled use cases User-goal level: Bid-Offer-Increases credit Sub Functional: Search-Close-Identify user Concern identification & classification Concern identification & classification Concern identification & classification Design concern Module(s) Design composition Specification(s) Concern identification allows: reject input / accept AO input / build non AO model Concern identification allows: reject input / accept AO input / build non AO model Design concern Module(s) Design by reuse No crosscutting - so just build a declaratively complete concern Design composition Specification(s) Specify integration – resolving conflicts and cooperation issues Design composition Specification(s) Design concern Module(s) Refine Refine

  10. Process result – first pass

  11. Refinement Iteration 2 Through designing the input concerns the crosscutting concerns became clear Concern identification & classification Concern identification & classification Concern identification & classification 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 Design concern Module(s) Design concern Module(s) Design concern Module(s) Design by reuse Design composition Specification(s) Design composition Specification(s) Observer was predefined in previous work and instead of re-defining I decided to reuse it!!! Design composition Specification(s) Crosscutting composition was then specified Test &Refine Refine

  12. Process result – second pass

  13. Refinement Iteration 3 Concern identification & classification Concern identification & classification Through Testing the design by composition a new concern emerged – the “setup” concern Concern identification & classification Design concern Module(s) Design composition Specification(s) Design concern Module(s) Design the composition specification in relation to all the other concern as setup affects the entire system Design by reuse Design composition Specification(s) Design composition Specification(s) Design concern Module(s) Design the crosscutting setup concern Refine Refine

  14. End result Next phase would be to implement… AO or OO?

  15. Design & Composition Concern Concern Used when input provides clear descriptions of concerns and concern relationships – may be used in waterfall methodologies – or where requirements/architecture are stable Used when input is imperfect or changeable – also in methodologies that require products after each release i.e. XP Concern Composition Concern Composites Composite Concern Concern Composition Concern Concern Composition Composition (a) Continual cumulative composition More useful when a component based approach is being taken. Is applicable where systems decomposed into separate sub systems (c) Hierarchical composition (b) Once off composition Composition Concern Concern Concern Concern Composite Composite Concern Concern

  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 End Thank you…. Questions\Comments Lunch?

  18. 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 ………

  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. Concern id & classification ignore Analyse inputs Reanalyse Separated concerns identified & classified Inputs are scattered and tangled Identify concerns relevant during design Create poorly modularised design Identify all concerns Refine Classify concerns Verify Non-crosscutting concerns Crosscutting concerns Other classifications

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

  23. Design by reuse Search design repository Test design No Match >= 1 Match Assess design relevance Do or do not select for reuse Design new concern & compositions Do Not Do Contextualize reused Designs Verify Assess potential for reusability Yes - reusable Reengineer & Decontextualize Add to design repository Design prepared for reuse

  24. Concern Module Design Design concern module Identify & design sub-concern modules Non-crosscutting 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 Test design Refine

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

More Related