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…