Architectural patterns for complex real time systems
This presentation is the property of its rightful owner.
Sponsored Links
1 / 53

Architectural Patterns for Complex Real-Time Systems PowerPoint PPT Presentation


  • 103 Views
  • Uploaded on
  • Presentation posted in: General

Architectural Patterns for Complex Real-Time Systems. Bran Selic ObjecTime Limited [email protected] Overview. Software architectures An architectural description language Architectural design patterns Pattern 1: Recursive control Pattern 2: Layering Summary. Software Architectures.

Download Presentation

Architectural Patterns for Complex Real-Time Systems

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Architectural patterns for complex real time systems

Architectural Patterns for Complex Real-Time Systems

Bran Selic

ObjecTime Limited

[email protected]


Overview

Overview

  • Software architectures

    • An architectural description language

  • Architectural design patterns

    • Pattern 1: Recursive control

    • Pattern 2: Layering

  • Summary


Software architectures

Software Architectures

  • General definition [Bass, Clements, Kazman]:

    “The structures of a software system, consisting of software components of a system and their externally visible properties and relationships.”

  • Many different architectures of a software system:

    • module architecture

    • uses (compilation) architecture

    • run-time architecture

    • process architecture

    • physical architecture

    • class (inheritance) architecture


Run time architecture

Run-Time Architecture

The run-time organization of significant software components interacting through interfaces, those components being composed of successively smaller components and interfaces

Key elements:

  • significant = abstraction (irrelevant detail omitted)

  • organization = components and their structural relationships

  • interactions = inter-object (end-to-end) behavior

  • interfaces = abstraction (conjunction of structure and behavior)

  • architectures occur at different levels of detail


Why architecture is important

Why Architecture is Important

A

A

A

B

C

B

C

Mediator

B

C

  • Enables communication between stakeholders

    • exposes how individual requirements are handled

  • Drives system construction

    • decomposition into units of responsibility and parallel development

  • Determines a system’s capacity for evolutionary growth

X

X

Mediator


The run time program structure

The Run-Time Program Structure

PingPongGame

player1:Player

player2:Player

partner

ball

partner

start

ball

start

  • Main program components and their relationships

Ada.Text_IO


Basic run time structural patterns

Basic Run-Time Structural Patterns

Container

Part

PartA

PartB

Container

Part

  • Containment:

Part

composition (existence dependency)

aggregation (information hiding)

  • Peer-to-peer interaction:

  • Layering:

Layer N+1

Layer N


Specifying architectures

Specifying Architectures

with Ada.Text_IO; use Ada.Text_IO;

Procedure PingPongGame is

task type Player is

entry partner (player: in access Player); -- my opponent’s id

entry start (server: in Boolean);-- start game

entry ball;-- accept ball

task body Player is

opponent : access Player;-- my opponent’s task id

begin

accept other (p) do opponent := p; end other;

accept start (myServe) do

if myServe then opponent.ball end if;

end start;

loop

accept ball do Put (“+”); end ball;

opponent.ball;

end loop;

end Player;

PingPongGame

player1:Player

player2:Player

player1 : access Player := new Player;

player2 : access Player := new Player;

begin

player1.partner (player2);

player2.partner (player1);

player1.start (True);

player2.start (False);

end PingPongGame;

Ada.Text_IO

  • Architectures should be seen not read!


Architectural patterns for complex real time systems

Software architectures

An architectural description language

Architectural design patterns

Pattern 1: Recursive control

Pattern 2: Layering

Summary


Uml rt an architecture description language

UML-RT: An Architecture Description Language

  • A formal and executable language specified using UML

    • allows early analysis of high-level models (architectures)

  • Designed for complex event-driven real-time systems

  • Combines a graphical syntax with a textual syntax

    • graphics for modeling high-level (architectural) aspects

    • text for detail (e.g., Ada, C++, Java)

  • Full-cycle language (analysis, design, implementation)

    • single formalism throughout development

    • facilitates iterative and incremental development

  • Suitable for full automatic code generation from models


Architectural patterns for complex real time systems

Capsules: Architectural Objects

Ports

  • A special kind of active object

Encapsulation

shell


Architectural patterns for complex real time systems

Capsules: Behavior

transitionS1toS2: {int x;

x = 0;

p2.send(s1); p3.send(s2); … };

S1

S1

S2

S3

  • Optional hierarchical state machine (signal handler with run-to-completion semantics)

S1

S2


Protocols reusable behavior patterns

Protocols: Reusable Behavior Patterns

call

ack

number

call

ack

transfer

talk

time

  • Interaction contracts between capsules

    • e.g., operator-assisted call

Caller

Operator

Callee


Architectural patterns for complex real time systems

Dexter

Alice

Charlie

Bob

caller

callee

protocol state machine

significant sequences

callee

caller

operator

initial

operator

connecting

connected

Protocol Specifications

  • A collaboration that may be required on multiple occasions and situations

OperatorAssistedCall


Protocol roles

Protocol Roles

Outgoing signals

Incoming signals

signal

signal

source

target

call

number

ack

ack

call

transfer

caller

caller

callee

caller

caller

callee

protocol state machine

significant sequences

caller

operator

callee

initial

connecting

connected

  • Specifies one party in a protocol

OperatorRole


Architectural patterns for complex real time systems

Ports: Boundary Objects

Capsule

S1

Environment

S2

  • Fully isolate a capsule’s implementation from its environment (in both directions)

  • Each port is typed with a single protocol role


Architectural patterns for complex real time systems

Combining Capsules

«capsule»sender : Fax

remote:FaxProt

«capsule»receiver : Fax

remote:FaxProt

  • Using connectors

Connector

  • Connectors model communication channels

  • Each connector supports a single protocol

  • Static typing rules apply (compatible protocols)


Architectural patterns for complex real time systems

c : Control

c : Control

remote:FaxProt

«capsule»sender:Fax

sendCtrl : Control

«capsule»receiver:Fax

receiveCtrl : Control

remote:FaxProt

Composition: Structural Patterns

Relayport

FaxCall

  • The composite is also a first-class object!


Composite capsule semantics

Composite Capsule Semantics

f1:FaxCall

  • Run-time assertion: the complete internal structure of a composite is automatically created (recursively, if necessary) when the capsule is created

f1 := create(FaxCall);

«capsule»sender:Fax

«capsule»receiver:Fax


Architectural patterns for complex real time systems

Benefits of Run-Time Assertion

  • Architectural enforcement: only explicitly prescribed architectural structures can be instantiated

    • it is not possible to bypass (corrupt) the architecture by low-level programming

  • Simplification: low-level program code that dynamically creates (destroys) components and the connections between them is eliminated

    • in some systems this can be as much as 35% of all code

  • Major net gain in productivity and reliability


Architectural patterns for complex real time systems

End Ports

c : SystemControl

capsule state machine

senderCtrl : Control~

receiveCtrl : Control~

initial

c : Control

c : Control

connecting

«capsule»sender:Fax

«capsule»receiver:Fax

connected

  • Ports directly connected to the state machine

ImplementationEnd Port

Public End Port


Architectural patterns for complex real time systems

Software architectures

An architectural description language

Architectural design patterns

Pattern 1: Recursive control

Pattern 2: Layering

Summary


Architectural patterns for complex real time systems

About Design Patterns

  • A design pattern is a proven generalized solution to a generalized problem that can be used to derive a specific solution to a specific problem

  • Represent distilled reusable experience

  • Major benefits of using patterns:

    • Simplify and speed-up design

    • Reduce risk

    • Facilitate communications between designers


Architectural patterns for complex real time systems

Software architectures

An architectural description language

Architectural design patterns

Pattern 1: Recursive control

Pattern 2: Layering

Summary


Architectural patterns for complex real time systems

End user

End user

line card N

End user

Example System

  • A multi-line packet switch that uses the alternating-bit protocol as its link protocol

AB protocol

line card 1

AB

sender

SWITCH

..

.

ABreceiver

unreliable telecom lines

AB

sender

ABreceiver


Alternating bit protocol 1

Alternating Bit Protocol (1)

packetizer

Sender

Receiver

unpacker

data(1)

pktA

data(1)

ack

ackA

ack

data(2)

pktB

data(2)

ack

ackB

ack

  • A simple one-way point-to-point packet protocol

AB protocol

…etc.


Alternating bit protocol 2

Alternating Bit Protocol (2)

RcvdPktA

pktA/^data

ack/^ackA

timeout/^ackB

WaitPktB

WaitPktA

timeout/^ackA

pktB/^data

ack/^ackB

RcvdPktB

  • State machine specification

Sender SM

Receiver SM

AcceptPktA

ackB/^ack

data/^pktA

timeout/^pktB

WaitAckA

WaitAckB

timeout/^pktA

ackA/^ack

data/^pktB

AcceptPktB


Additional considerations

Additional Considerations

AB linesmanager

  • Support infrastructure

SWITCH

operatorinterface

Systemoperator

ABreceiver

AB

sender

DB

interface

DBase


Control

Control

The set of (additional) mechanisms and actions required to bring a system into the desired operational state and to maintain it in that state in the face of various planned and unplanned disruptions

  • For software systems this includes:

    • system/component start-up and shut-down

    • failure detection/reporting/recovery

    • system administration, maintenance, and provisioning

    • (on-line) software upgrade


Retrofitting control behavior

Retrofitting Control Behavior

AcceptPktA

WaitAckA

WaitAckB

AcceptPktB

JustCreated

HardwareAudit

AnalysingFailure

ReadyToGo

GettingData

Failed


Control versus function

Control versus Function

  • Control behavior is often treated in an ad hoc manner, since it is not part of the primary system functionality

    • typically retrofitted into the framework optimized for the functional behavior

    • leads to controllability and stability problems

  • However, in highly-dependable systems as much as 80% of the system code is dedicated to control behavior!


Some key observations

Some Key Observations

  • Control predicates function

    • before a system can perform its primary function, it first has to reach its operational state

  • Control behavior is often independent of functional behavior

    • the process by which a system reaches its operational state is often the same regardless of the specific functionality of the component


The control automaton

The Control Automaton

JustCreated

GettingData

AnalysingFailure

HardwareAudit

ReadyToGo

Failed

Operational

  • In isolation, the same control behavior appears much simpler


Basic design principles

Basic Design Principles

  • Separate control from function

    • separate control components from functional components

    • separate control and functional interfaces

    • imbed functional behavior within control behavior

  • Centralize control

    • if possible, focus control in one component

    • place control policies in the control components and control mechanisms inside the controlled components


The basic structural pattern

The Basic Structural Pattern

  • Set of components that need to be controlled as a unit

Central

Controller

Controlinterface

. . .

ControlledComponent 1

ControlledComponent N

Functional

(service)interface


Recursive application

Recursive Application

Central

Controller

Central

Controller

Central

Controller

. . .

ControlledComponent 1

ControlledComponent N

ControlledComponent 1

ControlledComponent N

. . .

. . .

  • Hierarchical control

    • scales up to arbitrary number of levels


Realization with uml rt

Realization with UML-RT

JustCreated

«capsule»

CompSet

GettingData

AnalysingFailure

«capsule»c1:Comp1

«capsule»cN:CompN

HardwareAudit

ReadyToGo

Failed

Operational

  • Composite plays role of centralized controller


Exploiting inheritance

Exploiting Inheritance

AbstractController

ports

controlPort: CtrlProtocol

  • Abstract control classes can capture common control behavior and structure

  • Different subclasses capture function-specific behavior

Sender

Receiver

. . .


Exploiting hierarchical states

Exploiting Hierarchical States

AnalysingFailure

JustCreated

GettingData

Failed

AbstractController

HardwareAudit

ports

controlPort: CtrlProtocol

Operational

Sender

ReadyToGo


Architectural patterns for complex real time systems

Software architectures

An architectural description language

Architectural design patterns

Pattern 1: Recursive control

Pattern 2: Layering

Summary


Semantics of layering 1

Semantics of Layering (1)

AB sender

operator interface

Operating System

  • An asymmetric relationship with one-way dependencies

  • Layering is not the same as composition:

    • individual layers are separate entities

    • e.g., applications do not contain the OS


Semantics of layering 2

Semantics of Layering (2)

  • In complex systems, layering is a complex multidimensional relationship

    • e.g., 7-layer model of Open System Interconnection (OSI)

Level 7

Level 6

Level 5

Level 4

Network

Operating

System

Link

Hardware


Implementation components

Implementation Components

A

B

C

D

operator interface

AB sender

Timing Service

  • Private sub-components required to realize the functionality offered by component through its public interface

Internal implementation component

External implementation component


Interface types for layering

Interface Types for Layering

  • Need to differentiate two interface types:

    • Usage interface: implementation-independent interface through which a component provides its services (function and control)

    • Implementation interface (service access point): implementation-specific interface through which a component accesses an external service

  • Front-end/back-end views:

Implementation

Interface

Usage

Interface


Implementation interfaces

Implementation Interfaces

A

B

C

D

operator interface

AB sender

90o

Timing Service

  • Implementation interfaces are public interfaces but can be viewed as being in a different “plane” (dimension) from service interfaces


Modeling layers with uml rt

Modeling Layers with UML-RT

«capsule»

UpperLayer

InternalComp

«capsule»TimingService

  • Implementation interfaces are modeled by implementation end ports that can be connected externally to service ports of other capsules

Serviceaccess

point


Architectural patterns for complex real time systems

Software architectures

An architectural description language

Architectural design patterns

Pattern 1: Recursive control

Pattern 2: Layering

Summary


Software architectures1

Software Architectures

  • Software architecture, including run-time architecture, is crucial:

    • as a vehicle for communication between stakeholders

    • as a design and implementation framework

    • as a framework for system evolution

  • Programs obscure architecture

    • too much detail hides the big picture

    • leads to “architectural decay” over time

  • We require means to:

    • specify architectures clearly

    • enforce them through development and evolution


Architectural description languages

Architectural Description Languages

  • Requirements for an ADL

    • High level of abstraction

    • Graphical syntax for ease of understanding

    • Describes both structure and behavior

    • Can be applied recursively

    • Generates verifiable models

      • formal

      • executable

    • Can be used to automatically generate implementations

      • can be combined with implementation languages for specifying detail


Architectural design

Architectural Design

  • A good ADL removes incidental complexity allowing us to focus more closely on the difficult problem of architectural design

  • The use of well-chosen design patterns can help us immensely in this task

  • Many good architectural patterns already exist but new ones are emerging as computing and communications technologies evolve at a rapid pace

  • More research is required on understanding how patterns interact with each other (pattern combination)


Architectural patterns for complex real time systems

The task of engineering, including software engineering, is to build systems that will be of use to people. In this activity we should keep in mind that technology is not an end but a means—hence, we should choose technologies based on their suitability to the task at hand rather than personal preference.


Bibliography

Bibliography

  • Bass, L., P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley, 1998.

  • Gamma, E, et al., Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

  • Selic, B. and J. Rumbaugh, “Using UML for Modeling Complex Real-Time Systems, Rational/ObjecTime whitepaper, April 1998. (www.objectime.com)

  • Selic, B., G. Gullekson, and P. Ward, Real-Time Object-Oriented Modeling, John Wiley & Sons, 1994.


  • Login