1 / 21

Developing Adaptable Software Architectures for Real-Time Systems Using Design Patterns

Developing Adaptable Software Architectures for Real-Time Systems Using Design Patterns. Lawrence Chung, Kendra Cooper, Anna Yi The University of Texas at Dallas. Why, What, How. Software adaptation is an inevitable process Real-time systems also need adaptability

kessie-best
Télécharger la présentation

Developing Adaptable Software Architectures for Real-Time Systems Using Design Patterns

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. Developing Adaptable Software Architectures for Real-Time SystemsUsing Design Patterns Lawrence Chung, Kendra Cooper, Anna Yi The University of Texas at Dallas

  2. Why, What, How • Software adaptation is an inevitable process • Real-time systems also need adaptability • (Micro-architectural) design patterns are considered promising, potentially with orders of magnitude in improvements (perhaps concerning architectural adaptability) • But, lack of systematic methodology for developing adaptable (real-time) software using design patterns • Our proposal: An NFR approach (treat adaptability as a (soft) goal to achieve)

  3. An Example: HACS (Home Appliance Control System)

  4. Proteus as a Framework How to build such a system? 1. Post adaptability requirements, along with other NFRs and FRs • Refine NFRs and prioritize them 3. Consider architectural alternatives • Consider design patterns 5. Analyze tradeoffs among the architectures and design patterns 6. Select among the alternatives of architectures and corresponding design patterns that best satisfice the NFRs 7. Compose the selected design patterns into parts of the selected architectural design

  5. Developing Adaptable Software Using Design Patterns • An architectural design is a solution • There should be a corresponding problem • Hence, need for establishing traceability • But, starting with the problem • Adaptability is a Non-Functional Requirement (NFR) – hard to define, conflicting with other NFRs, often subjective, etc.

  6. An NFR Approach • The NFR Framework for dealing with NFRs • Establishes traceability between problem and solution • Graded contributions: make, help, hurt, break • Tradeoff analysis • Softgoal interdependency graph (SIG) • AND/OR decompositions, explore alternatives

  7. Automatic- Manual- Transformability - [HACS] High Cohesion [Architecture, HACS] Low Coupling [Architecture,HACS] + + Loose Coupling [Architecture, HACS] Low # Connection [Architecture, HACS] + + + Mediated Connection [Architecture, HACS] Indirect Connection [Architecture, HACS] + + + Reactor Pattern [Architecture, HACS] Wrapper Pattern [Architecture, HACS] Strategy Pattern [Architecture, HACS] !Speed Adaptability [HACS] [HACS] Detectability [Change in environment] Enactability Recognizability [Change in HACS] [Change in HACS] Satisficing Adaptability Requirement - SIG for Adaptable HACS with Design Patterns and Tradeoffs

  8. Design Patterns • Solutions to recurring problems • Architectural solutions as the highest-level Hence, component-/connection-oriented • Micro-architectural “design patterns” started by GoF Data structure and algorithm oriented • Cf. “idioms” for program patterns • Important part of Java 2 Platform, Enterprise Edition (J2EE) -- an open standard for implementing and deploying component-based enterprise applications. Also for J2ME (Java 2 Platform, Mobile Edition)

  9. Design Patterns for Adaptable Software request( ) Wrapper request( ) Client specific_request( ) Wrappee specific_request( ) Wrapper Pattern: Intent:To encapsulate lower-level functions within type-safe, modular, and portable class interfaces Helps to: 1)  avoid tedious, error-prone, and non-portable programming of low-level IPC mechanisms 2)  combine multiple related, but independent, functions into a single cohesive abstraction. Structure:

  10. Design Patterns for Adaptable Software Reactor Pattern: Intent:To decouple event demultiplexing and event handler dispatching from the services performed in response to events. Helps to: 1) demultiplex multiple types of events from multiple sources of events efficiently within a single thread of control 2) extend application behavior without requiring changes to the event demultiplexing/dispatching framework. Structure:

  11. Design Patterns for Adaptable Software Strategy Pattern: Intent:To define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Helps to: extend the policies for advertising, listening, creating, accepting, and executing a service handler without modifying the core algorithm. Structure:

  12. Client Mobile Device Home_Appliance_Controller in Wrapper  activate (appliance) activate(appliance) ac.activate_thru_socket( ) ac.activate_thru_rmi( ) Server Microwave_Oven in Wrappee  activate_thru_socket( ) Server Microwave_Oven in Wrappee activate_thru_rmi( ) Home_Appliance_Controller Strategy Cook_SetTemp() Client Mobile Device Context(activate) Case context: not-so-hungry: CookMostlyFinalAdjustOnArrival() very-hungry: FastCookFastSetTemp() romantic: SlowCookSlowSetTemp() hungry_tired_maybe_late: … { hungry_tired_maybe_late } Strategy CookMostlyFinalAdjustOnArrival() Strategy FastCookFastSetTemp() Strategy SlowCookSlowSetTemp() { FastCook; FastSetTemperature } { SlowCook; SlowSetTemperature} Figure 7. Composition of Tailored Design Patterns for HACS Invocation Adapatation Composition of Design Patterns

  13. Knowledge base of Architectural Patterns • Search for architectural patterns for adaptable real-time system can be difficult and time-consuming • A repository for efficient search and reuse of knowledge about architectural patterns for adaptability and about their implications • Inference rules organized along hierarchies

  14. Conclusions • Contributions • A systematic methodology for using design patterns in developing adaptable (real-time) software • Future Work • Future applications, e.g., to J2EE • Populating KB • Mapping pattern language categories to SIG

  15. Open Services Gateway initiative (OSGi) Framework Features • Component-based run-time framework for Java applications (bundles) • Java API for managing bundle life-cycle • Bundles installed or uninstalled on-demand from the network

  16. The “compilation” of the Connection Management Pattern from the Acceptor, Connector, Reactor, Strategy and the Wrapper Façade patterns

  17. The conventional method of accepting service requests: • Initialization, • Task-1, • Task-2, • … • … • …

  18. The Acceptor Pattern: Advises decoupling of Initialization task from other tasks • Initialization, • Task-1, • Task-2, • … • … • …

  19. Wrapper Pattern The Reactor Pattern: Provides synchronous demultiplexing of asynchronous events to their corresponding event-handlers Strategy Pattern Various strategies ATM, IP, SONET Uniform interface Low level functions AcceptorPattern • Initialization, • Task-1, • Task-2, • … • … • … … all this is for the connection acceptor

  20. On the connection requestor (client) side… send_connect_request( ) Application makes connection request Connection handler Various strategies Cached Connect strategy, X strategy, Y strategy,…

  21. Connection Management Pattern Acceptor-Connector Pattern we saw… Connector Acceptor, Strategy, Wrapper, combination Reactor +

More Related