1 / 51

Motorola WEAVR : Model-Driven Software Development in a Large Industrial Context

Motorola WEAVR : Model-Driven Software Development in a Large Industrial Context. by Thomas Cottenier Software and System Engineering Research Lab, Motorola Labs Directed by Dr. Tzilla Elrad, Illinois Institute of Technology. January 2007. Motorola WEAVR Outline. Introduction

hidi
Download Presentation

Motorola WEAVR : Model-Driven Software Development in a Large Industrial Context

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. Motorola WEAVR: Model-Driven Software Developmentin a Large Industrial Context by Thomas Cottenier Software and System Engineering Research Lab, Motorola Labs Directed by Dr. Tzilla Elrad, Illinois Institute of Technology January 2007

  2. Motorola WEAVROutline • Introduction • What is a Software Model? • Model-Driven Software Development • Aspect-Oriented Software Development • Motorola WEAVR • Further Work • Conclusions

  3. Motorola WEAVR How to Manage Software Complexity? Evolution of Software Design: Monolithic → Modular Abstraction Focus only on relevant properties – omit what is not relevant Decomposition Divide software into separately named and addressable modules Encapsulation Group related things together. InformationHiding Hide implementation details from the outside Separation of Concerns • Ensure that each module only deals with one concern • Low Coupling among the modules • High Cohesion within one module

  4. Models Models@runtime Aspect-Oriented Programming Source Code 1990’s Object Oriented Programming Procedural Programming 1980’s How to Manage Software Complexity? Aspect-Oriented Software Development Metamodeling 2000’s Model-Driven Engineering

  5. Motorola WEAVR Introduction Applications = Computations + Composition Object-Oriented Programming Applications = Objects + Aggregation, Association, Inheritance, Polymorphism, .. Component-Based Software Development Applications = Component Interfaces + Scripts Service-Oriented Architecture Applications = Service Interfaces + Business Processes Model-Driven Development Applications = Libraries + Models

  6. Motorola WEAVR Introduction Problems: - Brittle Composition Mechanisms Software reuse mechanisms do not scale Separate Composition from Computation Domain-Specific Abstractions - Purely Hierarchical Decomposition Some concerns cannot be modularized according to an hierarchical decomposition Aspect-Oriented Software Development

  7. Motorola WEAVR What is a Software Model? Different types of systems: • Transformational systems: Data-Processing systems, Compilers, Search-Engines, Computation Intensive systems, etc.. • Reactive systems ATM, vending machines, phones, cars, missile and avionic systems, telecom infrastructure, human-machine interface of may ordinary software

  8. Motorola WEAVR What is a Software Model? Different types of systems: • Transformational systems: Data-Processing systems, Compilers, Search-Engines, Computation Intensive systems, etc.. Procedural, Functional, Object-Oriented, etc programming languages provide excellent support for Transformational systems!

  9. Motorola WEAVR What is a Software Model? Different types of systems: • Reactive systems ATM, vending machines, phones, cars, missile and avionic systems, telecom infrastructure, human-machine interface of may ordinary software Procedural, Functional, Object-Oriented, etc programming languages DO NOT provide the right abstractions

  10. 1. void actionPerformed(ActionEvent evt) { 2. switch(this.STATE){ 3. case Init: 4. serviceA.methodA(); 5. if(evt.getSource() == Enter){ 6. serviceB.methodB(); 7. if(evt.getActionCommand() == “Previous”){ 8. serviceC.methodC(); 9. this.STATE = Previous; 10. return; 11. }else 12. if(evt.getActionCommand() == “Next”){ 13. serviceD.methodB(); 14. this.STATE = Next; 15. return; 16. } 17. }else 18. if (evt.getSource() == Cancel){ 19. } 20. break; 21. case Previous: 22. serviceA.methodE(); 23. break; 24. case Next: 25. if(evt.getActionCommand() == “Proceed”){ 26. serviceA methodC(); 27. } 28. break; 29. } 30. methodF(); 31. this.STATE = Done; 32. return; 33. } Motorola WEAVR Reactive Systems Example: Java Applet

  11. Motorola WEAVR Reactive Systems Statechart is a decomposition that better fits the problem domain than the procedural decomposition

  12. 1. void actionPerformed(ActionEvent evt) { 2. switch(this.STATE){ 3. case Init: 4. serviceA.methodA(); 5. if(evt.getSource() == Enter){ 6. serviceB.methodB(); 7. if(evt.getActionCommand() == “Previous”){ 8. serviceC.methodC(); 9. this.STATE = Previous; 10. return; 11. }else 12. if(evt.getActionCommand() == “Next”){ 13. serviceD.methodB(); 14. this.STATE = Next; 15. return; 16. } 17. }else 18. if (evt.getSource() == Cancel){ 19. } 20. break; 21. case Previous: 22. serviceA.methodE(); 23. break; 24. case Next: 25. if(evt.getActionCommand() == “Proceed”){ 26. serviceA methodC(); 27. } 28. break; 29. } 30. methodF(); 31. this.STATE = Done; 32. return; 33. } Motorola WEAVR Reactive Systems

  13. Motorola WEAVR Reactive Systems Modules that: • are repeatedly prompted by the outside world and continuously respond to external inputs • behavior is highly dependent on module history Abstractions: • State • Transition • Decision Actions Today, most systems are hybrid systems (reactive and transformational)!

  14. Motorola WEAVR What is a Software Model? UML: Collection of Languages that provide complementary decomposition abstractions • Object-Oriented and procedural decomposition: Class Diagrams, Sequence Diagrams • Reactive decomposition: State Machine diagrams • Workflow decomposition: Activity Diagram • Runtime structure decomposition: Composite-Part Diagram + Execution: Action Language

  15. Motorola WEAVR What is a Software Model? Object-Oriented Workflow State Machine Run time Structure + Execution: Action Language Procedural

  16. Motorola WEAVRModel-Driven Software Development Different Types of Modeling Practices: • Sketches (e.g. Visio) • Blue-prints/Elaboration (e.g IBM Rational) • Executable Models (e.g IBM Rational) • Translatable Models (e.g. Telelogic, iUML)

  17. Motorola WEAVRMDD Blue-prints/Elaboration (e.g IBM Rational)

  18. Motorola WEAVRMDD Model Translation

  19. Domain Standard Notations UK USA RMTR air_in taxi_in taxi_out air_out GENERICCODE GENERATOR DESIGN SIMULATION UNIT TEST Motorola WEAVRModel-Driven Software Development PRODUCT REQUIREMENTS VALIDATION MIDDLEWARE, OS, PLATFORM PRODUCT CODE VERIFICATION

  20. Motorola WEAVRModel-Driven Software Development Example: Resource Access Server

  21. Motorola WEAVRModel-Driven Software Development Example: Resource Access Server

  22. Motorola WEAVRModel-Driven Software Development Example: Resource Access Server VALIDATION

  23. Motorola WEAVRModel-Driven Software Development Example: Resource Access Server

  24. Motorola WEAVRModel-Driven Software Development Example: Resource Access Server Realization Mappings 4.b. 4.a.

  25. Motorola WEAVRModel-Driven Software Development Specification Implementation

  26. Motorola WEAVRModel-Driven Software Development Example: Resource Access Server

  27. Motorola WEAVRModel-Driven Software Development Demo.

  28. Motorola WEAVRAspect-Oriented Software Development • Socket creation in Tomcat • - fits nicely into one package (3 classes) Good Modularity

  29. Motorola WEAVRAspect-Oriented Software Development • Class Loading in Tomcat • - mostly in one package (9 classes) Good Modularity

  30. Motorola WEAVRAspect-Oriented Software Development Logging in Tomcat - scattered across the packages and classes - error handling, security, business rules, … Poor Modularity

  31. Crosscutting Concerns in Models

  32. Motorola WEAVRAspect-Oriented Software Development Goal of AOSD Enable the modular (not scattered) implementation of crosscutting concerns. Aspect Explicit abstraction for representing crosscutting concerns Aspect-Oriented Programming Language that provides mechanisms to capture aspects Aspect Weaver Composition mechanism that coordinates aspects with the rest of the code

  33. AOSD – TerminologyCrosscutting Concerns Scattering In a given implementation, the code for a concern is spread out. Single concern affects multiple modules. Tangling Multiple concerns are interleaved in a single module Crosscutting Concern The inherent structure of the concern can not be modularized in the decomposition mechanism of the language (Objects or procedures), because it follows different composition rules. • class Point { • void setX(int x) { • Tracer.traceEntry(“Entry Point.set”); DisplayTracker.updatePoint(this); • this.x = x; • Tracer.traceExit(“Exit Point.set”); } • }

  34. AOSDCrosscutting Concerns • Synchronization • Real-time constraints • Error-checking • Object interaction constraints • Memory management • Persistency • Security • Caching • Logging • Monitoring • Testing • Domain specific optimization • ...

  35. Motorola WEAVR

  36. WEAVR Model weaving Engine Resource Initialization Aspect Initialization Exception Handling Aspect

  37. Motorola WEAVRExamples: Fault-Tolerance Exception Handling

  38. Motorola WEAVRExamples: Fault-Tolerance Exception Handling

  39. Motorola WEAVRExamples: Fault-Tolerance Example: Resource Access Server Realization Mappings 4.b. 4.a.

  40. Motorola WEAVRModel-Driven Software Development Specification Implementation

  41. Motorola WEAVRExamples: Fault-Tolerance Exception Handling

  42. Motorola WEAVRAspect-Oriented Modeling

  43. Motorola WEAVRExamples: Fault-Tolerance 10.a. Recoverability restore backup

  44. Motorola WEAVRExamples: Fault-Tolerance 11.d. 10.a. Atomicity

  45. Motorola WEAVRModel-Driven Software Development Example: Resource Access Server

  46. Motorola WEAVRMotorola WEAVR Demo.

  47. Motorola WEAVRFurther Work AspectX classX x classY AspectY WEAVR partially addresses the most important issue with AOSD • Dependency Inversion Does dependency inversion impedes system modularity, evolvability? • Aspect/Core semantic interactions Guaranties on the quality attributes of woven software? • Interferences between aspects AOSD destroys the locality of the run-time control flow. We need full global knowledge in order to reason about the correctness of the system! • Syntactic Joinpoint Designators Does my join point specification match my intention of the joint point? AOP introduces new ways the correctness of a program can break down Current joint point languages are too low level

  48. Motorola WEAVRFurther Work How to guarantee the correctness of woven Models? Validation, Simulation, Model Checking, testing of woven models?

  49. Motorola WEAVRConclusions • Modeling allows a system to be decomposed according to complementary decomposition abstractions. Use the abstraction that fits problem domain the best • Model-Driven Software Development – fully automatic code generation from executable models • Aspect-Oriented Software Development – provide abstractions for crosscutting concerns • Motorola WEAVR: Aspect-Oriented Software Development through model transformation Our Contribution • Aspect-Oriented Language for State Machines – New Joinpoint model • Inference of Implementation Joinpoints from Pointcuts expressed in terms of the Specification – Increased Modularity • Concepts fully implemented in WEAVR tool • Tool deployed in an industrial context – Expected Results by end 2007: Reduction of 40% of model size in WiMAX infrastructure project

More Related