1 / 29

Modeling Aspect-Oriented Compositions

Modeling Aspect-Oriented Compositions. Thomas Cottenier - Motorola Labs / Illinois Institute of Technology Aswin van den Berg - Motorola Labs Tzilla Elrad - Illinois Institute of Technology. Outline. Model-Driven Software Development Crosscutting Concerns

tallys
Download Presentation

Modeling Aspect-Oriented Compositions

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. Modeling Aspect-Oriented Compositions Thomas Cottenier - Motorola Labs / Illinois Institute of Technology Aswin van den Berg - Motorola Labs Tzilla Elrad - Illinois Institute of Technology

  2. Outline • Model-Driven Software Development • Crosscutting Concerns • Aspect-Oriented Software Design • Our Objectives for AOSD • Our Metamodel for AOSD

  3. Model-Driven Software Developmentin Motorola • Communicating Real-time Embedded Systems • Simulation, Verification, • Use-Case Validation • (Optimized) Code Generation • Software Reuse SDL2000, SDL Statecharts Early fault-detection, Iterative, Agile Telelogic TAU G1/G2, Mousetrap Pluggability, Reuse of legacy code

  4. PRODUCT REQUIREMENTS STANDARD DESIGN NOTATIONS UK USA RMTR air_in taxi_in taxi_out air_out CODE GENERATOR MIDDLEWARE, OS, PLATFORM DESIGN SIMULATION PRODUCT CODE UNIT TEST Model-Driven Software Developmentin theory

  5. UK Monitoring RMTR air_in taxi_in taxi_out air_out UK Synchro. RMTR air_in taxi_in taxi_out air_out UK Persistency RMTR air_in taxi_in UK USA RMTR taxi_out air_in taxi_in air_out taxi_out air_out UK Real-time RMTR air_in taxi_in taxi_out UK Caching RMTR air_out air_in taxi_in taxi_out air_out UK Security RMTR UK MM RMTR air_in air_in taxi_in taxi_in taxi_out taxi_out air_out air_out Model-Driven Software Developmentin practice

  6. Crosscutting Concerns e.g., Logging: Calls to logging component represent about 15% of model size Different Use Cases/Scenarios implementations within a single module CCC follows different composition rules • Scattering • The code for a concern is spread out. Single concern affects multiple modules. • Tangling • Concern implementations are interleaved in a single module. • Crosscutting Concern • Concern can not be modularized in the decomposition mechanism of the language.

  7. Aspect-Oriented Software Design

  8. CROSSCUTTING REQUIREMENTS UK UK UK USA USA USA RMTR RMTR RMTR air_in air_in air_in taxi_in taxi_in taxi_in taxi_out taxi_out taxi_out air_out air_out air_out CONNECTOR ASPECT MODELS CORE MODEL FULL MODEL Our Objectives for AOSDModularization of Crosscutting Concerns CORE REQUIREMENTS

  9. CROSSCUTTING REQUIREMENTS UK UK UK USA USA USA RMTR RMTR RMTR air_in air_in air_in taxi_in taxi_in taxi_in taxi_out taxi_out taxi_out air_out air_out air_out PLATFORM CODE VALIDATION (TEST-HARNESS) CODE VALIDATION (TEST-HARNESS) FULL MODEL VALIDATION ASPECT MODEL VALIDATION ASPECT MODEL VALIDATION CORE MODEL VALIDATION CONNECTOR ASPECT MODELS CORE MODEL FULL MODEL Our Objectives for AOSDSimulation andValidation of Modular Units CORE REQUIREMENTS

  10. Aspect Library Our Objectives for AOSDReuse of modular units

  11. Our Objectives for AOSD(Optimized) Code Generation

  12. ? Our Objectives for AOSDPluggability and Reuse of Legacy Code

  13. Our Objectives for AOSDSimplicity, Adoptability Software development teams have enough on their minds. It is a challenge to convince teams to use new methodologies/processes. The benefit needs to be crystal clear. The learning curve needs to be low. The adoption threshold should not exist, (gradual adoption).

  14. Our Objectives for AOSD • Modularization of cross-cutting concerns • Simulation and validation of modular units • Reuse of modular units • (Optimized) Code Generation • Pluggability and Reuse of legacy code • Simplicity, Adoptability

  15. Our Objectives for AOSD Aspect models should not be core-model specific and, vice versa, Core models should be oblivious to extensions.

  16. M M M Our Objectives for AOSD M M instead of

  17. Our Objectives for AOSD We need to simulate and validate the woven model with the available modeling tools. I.e., no heavy-weight extension with new diagrams

  18. Our Objectives for AOSD instead of

  19. Our Metamodel for AOSDAspect-Oriented Language Elements • join point (JP) model • principled points in program execution such as method calls, field accesses, and object constructions • means of identifying JPs • picking out join points of interest (predicate) • pointcuts: set of join points • means of specifying behavior at JPs • what happens at the points of interest • advice declarations

  20. Our Metamodel for AOSDAspect-Oriented Language Elements • join point (JP) model • JPs not visible in the model at design phase • means of identifying JPs • pointcuts are part of the Connector • means of specifying behavior at JPs • advice and intertype declarations are parts of the Aspect Bean

  21. Our Metamodel for AOSDModel Driven Architecture Source Meta Model Transformation Structural Meta Model Target Meta Model <aspect><pointcutname="hashtable_update" expression="Map_t::update" type="call" <parametername="p" type="Map_t"/><parametername="d1" type="(.)*"/> <returnname="result" type="Boolean“ value=“false”/> </pointcut> <advicename="log_update“ CIM What? Model Transformation Engine Engine MetaPrograming API PIM How? Transformation Behavioral Meta Model PSM Strategies

  22. Our Metamodel for AOSDAspectSDL JP Meta Model Aspect Bean Meta Model Structural Meta Model of Weaver Target Meta Model <aspect><pointcutname="hashtable_update" expression="Map_t::update" type="call" <parametername="p" type="Map_t"/><parametername="d1" type="(.)*"/> <returnname="result" type="Boolean“ value=“false”/> </pointcut> <advicename="log_update“ AspectSDL: Model transformation engine for Aspect-Oriented SDL statechart composition Model Transformation Engine Engine MetaPrograming API Behavioral Meta Model of Weaver Weaving Strategies

  23. Our Metamodel for AOSDJoin Point Metamodel

  24. Our Metamodel for AOSDJoin Points

  25. Our Metamodel for AOSDAspect Beans

  26. Our Metamodel for AOSDExample

  27. Our Metamodel for AOSDAspect Connector

  28. Our Metamodel for AOSDExample <pointcutname="hashtable_update" expression="Map_t::update" type="call"> <parametername="p" type="Map_t"/> <parametername="d1" type="(.)*"/> <returnname="result" type="Boolean“ value=“false”/> </pointcut> <advicedefinitionname="log_update“ method="HashMap_Logger::HashMap_Update_Failure" bind-to="hashtable_update" type="after"> <argument name="tableName" type="Charstring" bind-to="p" value=“byname"/> </advicedefinition>

  29. Questions?

More Related