developing adaptable software architectures for real-time systems using design patterns
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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 (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)
An Example: HACS (Home Appliance Control System)
Proteus as a Framework1. Post adaptability requirements,
along with other NFRs and FRs
2. Refine NFRs and prioritize them
3. Consider architectural alternatives
4. 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
How to build such a system?
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.
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
SIG for Adaptable HACS with Design Patterns and Tradeoffs
High Cohesion[Architecture, HACS]
Low # Connection[Architecture, HACS]
Mediated Connection[Architecture, HACS]
Loose Coupling[Architecture, HACS]
Low Coupling[Architecture,HACS]
++
++ +
!Speed[HACS]
Transformability[HACS]
Detectability[Change in environment]
Adaptability[HACS]
Automatic-Manual-
Recognizability[Change in HACS]
Enactability[Change in HACS]-
-
Strategy Pattern[Architecture, HACS]
Wrapper Pattern[Architecture, HACS]
Reactor Pattern[Architecture, HACS]
++ +
Indirect Connection[Architecture, HACS]
Satisficing Adaptability Requirement
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)
Design Patterns for Adaptable Software
Client Wrapper
request( )
Wrappee
specific_request( )
request( )
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:
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:
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:
Figure 7. Composition of Tailored Design Patterns for HACS
ClientMobile Device
Home_Appliance_Controller in Wrapper activate (appliance)
Server Microwave_Oven in Wrappee activate_thru_socket( )
activate(appliance)
ac.activate_thru_socket( )
Server Microwave_Oven in Wrappeeactivate_thru_rmi( )
ac.activate_thru_rmi( )
Case context:not-so-hungry: CookMostlyFinalAdjustOnArrival()very-hungry: FastCookFastSetTemp()romantic: SlowCookSlowSetTemp()hungry_tired_maybe_late: …
Home_Appliance_Controller Strategy Cook_SetTemp()
{ hungry_tired_maybe_late }
ClientMobile Device
Context(activate)
Strategy CookMostlyFinalAdjustOnArrival()
Strategy FastCookFastSetTemp()
{ FastCook; FastSetTemperature }
Strategy SlowCookSlowSetTemp()
{ SlowCook; SlowSetTemperature}
InvocationAdapatation
Composition of Design Patterns
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
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
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
HT
TP
Lo
gg
ing
SN
MP
Sec
uri
ty
Cal
end
ar
OSGi Framework
JVM (J2ME/PersonalJava)
Embedded/Real-time OS
Network
Embedded Device
The “compilation” of the Connection Management Pattern from the Acceptor, Connector, Reactor, Strategy and the Wrapper Façade patterns
The conventional method of accepting service requests:
• Initialization,
• Task-1,• Task-2,• …• …• …
• Initialization,
• Task-1,• Task-2,• …• …• …
The Acceptor Pattern:
Advises decoupling of Initialization
task from other tasks
• Initialization,
• Task-1,• Task-2,• …• …• …
Acceptor Pattern
The Reactor Pattern:
Provides synchronous
demultiplexing of asynchronous events to their corresponding event-handlers
Various strategies
ATM,IP,
SONET
Strateg
y
Pattern
Low level functionsUniform interface
WrapperPattern
… all this is for the connection acceptor
On the connection requestor (client) side…
Applicationmakes connectionrequest
Connection handler
Various strategies
Cached Connect strategy,X strategy,
Y strategy,…
send_connect_request( )
Connector
Acceptor, Strategy,Wrapper,
combination
Reactor+
Acceptor-Connector Pattern
Connection Management Pattern
we saw…