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

1
Developing Adaptable Software Architectures for
Real-Time Systems Using 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

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

• Initialization,
• Task-1,
• Task-2,

19
Various strategies ATM, IP, SONET
Strategy Pattern
Uniform interface
Low level functions
Acceptor Pattern

• 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