Richard N. TaylorInstitute for Software ResearchUniversity of California, Irvine

taylor@uci.eduwww.ics.uci.edu/~taylor

an approach based on software architectures

Designing, Implementing and Dynamically Changing Applications

Outline

Architecture-based software engineeringArchitectural stylesDynamic changeEngineering environmentCurrent projects

Architecture-Based Software Engineering

Requirements and domain engineering precedeOOD may supplement; coding follows

“An approach to software systems development which uses as its primary abstraction a model of the system’s components, connectors, and interconnection topology”

Examples

CompilersUnix-style pipe-and-filter applicationsA family of video gamesGuidance-navigation-control systems for

rotorcraftAn open software development

environment

Benefits

Intellectual control over complexity via abstraction via well-understood patterns of

composition

Communication of system design via explicit description of system

structure and properties

Basis for controlled, predictable, dynamic adaptation via separation of computation

from communication

Reduced costs and improved time to market via reuse of components, families, and

domain knowledge via better focused testing

Higher quality products via reuse of trusted components via early analysis capabilities

Improved chances for interoperability via explicit, exposed interfaces via separation of computation from

communication

What’s Needed to Support It?

Appropriate descriptive formalisms Architecture description languages (ADLs)

Tools to carry out analyses, support editing, generate code,

support run-time dynamism, etc.

Processes to create or recover architectures to integrate architecture-based development into the

broader development and organizational contexts

So What’s New?

The degree to which architectures are made explicit, and how they are described

Using the description as the basis for evolution (static and dynamic) it is not a throw-away model

The degree to which communication is separated from computation

The prominence given to connectors

Outline

Architecture-based software engineeringArchitectural stylesDynamic changeEngineering environmentCurrent projects

Architectural Styles

“Walk like this!”“Why should I walk like that?”Canonical structures and rules

provide context focus attention promote shared understanding carry hard-won domain knowledge and

proven solution techniques

Classical Styles

Pipe-and-filterBlackboardClient-server“Three tier”State machine

The C2 Style

Autonomous components own thread and non-shared address space

All communication is by asynchronous events which must pass through a connector connectors may be complex and powerful

Some additional rules to promote reuse(A variety of implementation techniques)

Intellectual Heritage

Domain-specific software architectures concurrent, loosely coupled, distributed, dynamic

apps

Smalltalk’s model-view-controller paradigmField’s event-based integrationAbstraction and separation of concernsOO typingLisp, et.al.s dynamic properties

A Second Look at the C2 Style

Asynchronous, event-based communication among autonomous components, mediated by active connectors

No component-component linksEvent-flow rules:

Hierarchical application

Notifications fall

Requests rise Component

Connector

“push”

“pull”

Connector

A Simple Example: KLAX

KLAX™ game 16 components, approx.

4k SLOC, 100kb compiled implemented from scratch in

the C2 architectural style[TMA+96]

Clocklogic

StatusADT

ChuteADT

WellADT

PaletteADT

Next tileplacing logic

Tile matchlogic

Relative poslogic

Statuslogic

Statusartist

Wellartist

Chuteartist

Paletteartist

Tileartist

Layoutmanager

Graphicsbinding

KLAX: Adaptability

Spelling KLAX spell words from falling letters replaces 3 components

High score list adds 3 new components

Multi-player networked KLAX a match adds a tile to

opponents’ chute

Clocklogic

StatusADT

ChuteADT

WellADT

PaletteADT

Next tileplacing logic

Tile matchlogic

Relative poslogic

Statuslogic

Statusartist

Wellartist

Chuteartist

Paletteartist

Tileartist

Layoutmanager

Graphicsbinding

Letterartist

Next letterplacing logic

Word matchlogic

High scoreADT

High scoreartist

High scorelogic

ClientADT

Clientartist

KLAX: Combinations

Spelling KLAX spell words from falling letters replaces 3 components by “the team”

High score list adds 3 new components by ICS 125b team

Multi-player networked KLAX a match adds a tile to

opponents’ chute by ICS 125b team

Clocklogic

StatusADT

ChuteADT

WellADT

PaletteADT

Next tileplacing logic

Tile matchlogic

Relative poslogic

Statuslogic

Statusartist

Wellartist

Chuteartist

Paletteartist

Tileartist

Layoutmanager

Graphicsbinding

Letterartist

Next letterplacing logic

Word matchlogic

High scoreADT

High scoreartist

High scorelogic

ClientADT

Clientartist

Rolling Your Own Style

What goals is the style designed to help you achieve? performance? initial development time? understandability? long term adaptability?

It’s a bit of a tricky business… rules, methods, consistency, well-defined, over-

constrained

Outline

Architecture-based software engineeringArchitectural stylesDynamic changeEngineering environmentCurrent projects

Dynamic Change

Why? Reasons for change: errors, improvements Dynamic: may have no choice

Where? What’s the abstraction level of the concept

being changed? What levels do the mechanisms available offer?

How?

Conceptual View of Architecture-Based Runtime Change

Consistency

Dynamic Change Example

Internet

request

add-

on

Dynamic Change Example public void performInstall(ExtensionWizard ew) { ew.send( ArchADTC2.defineType("Planner", IArchADT.COMPONENT_TYPE, "Planner") ); ew.send( ArchADTC2.defineType("Planner", IArchADT.COMPONENT_TYPE, "PlannerArtist") ); ew.send( ArchADTC2.setAttribute("Planner", IArchADT.COMPONENT_TYPE, "Planner", ArchADTComponent.C2_IMPLEMENTATION_MODULE, "Planner.class") ); ew.send( ArchADTC2.setAttribute("Planner", IArchADT.COMPONENT_TYPE, "PlannerArtist", ArchADTComponent.C2_IMPLEMENTATION_MODULE, "PlannerArtist.class") ); ew.send( ArchADTC2.addInstance("Planner", "Planner", "planner") ); ew.send( ArchADTC2.addInstance("Planner", "PlannerArtist", "plannerArtist") ); ew.send( ArchADTC2.weld("Planner", "Bus1", ArchADTComponent.BOTTOM_PORT, "planner", ArchADTComponent.TOP_PORT) ); ew.send( ArchADTC2.weld("Planner", "planner", ArchADTComponent.BOTTOM_PORT, "Bus2", ArchADTComponent.TOP_PORT) ); ew.send( ArchADTC2.weld("Planner", "Bus3", ArchADTComponent.BOTTOM_PORT, "plannerArtist", ArchADTComponent.TOP_PORT) ); ew.send( ArchADTC2.weld("Planner", "plannerArtist", ArchADTComponent.BOTTOM_PORT, "Bus4", ArchADTComponent.TOP_PORT) ); ew.send( ArchADTC2.setAttribute("Planner", IArchADT.COMPONENT, "planner", ArchShellComponent.ARCHSHELL_RUNNING, ArchShellComponent.RUNNING_TRUE) ); ew.send( ArchADTC2.setAttribute("Planner", IArchADT.COMPONENT, "plannerArtist", ArchShellComponent.ARCHSHELL_RUNNING, ArchShellComponent.RUNNING_TRUE) ); }

add-on install script add-oncomponents& connectors

(compiled)

query &modify

Next shipmentlogic

Clocklogic

PortsADT

VehiclesADT

WarehousesADT

Portartist

Warehouseartist

Vehicleartist

Router

Graphicsbinding

Graphicalrouter

Planner

Architecture-Based DynamismComponent and connector addition, removal,

replacement, and reconnectionRequires consistency maintenance

some guaranteed by a priori analysis on-the-fly constraint enforcement faithful architectural model mapping changes to the implementation

Requires minimal disruption state preservation, replication, migration near-continuous service availability reverting to reliable configurations

Key Facilitator: Connectors

Traditionally used in system modeling explicit in design, indiscrete in implementation

Provide a critical abstraction for dynamism should remain discrete, flexible entities in the implementation mediate communication between components specify communication mechanism independent of component

behavior encapsulate change application policy boundaries for confining change scope

Communication using asynchronous messages reduces component communication dependencies how stateful is an event?

Outline

Architecture-based software engineeringArchitectural stylesDynamic changeEngineering environmentCurrent projects

Architecture-Based Engineering Environment

Functional areas: Architecture development and analysis From model to implementation Evolution: static and dynamic

Rationale capture

Multi-model support

Our approach: bootstrapping

Multi-model Support: xADL

XML-based representation of ADLs core model C2-specific additions extensions done for Darwin, ACME, SADL

Available at http://www.ics.uci.edu/pub/arch/papers/KGOMT-SE.pdf

Outline

Architecture-based software engineeringArchitectural stylesDynamic changeEngineering environmentCurrent projects

Research Hypotheses

Software architecture is an appropriate basis for supporting adaptation

C2 provides important advantages as the architectural basis

Experience with C2 has validated these hypotheses for software in “unconstrained” environments

Experience with C2 has validated these hypotheses for software in “unconstrained” environments

What Are The Constraints? (I)

In C2 terms … Determining appropriate component granularity for

adaptive changes Determining effect of variation in component size on

characteristics of on-board architectural model Tradeoff size against other performance constraints

Example: memory usage vs. compression/decompression overhead

“Know the Size”“Know the Size”

What Are The Constraints? (II)

In C2 terms … Establishing real-time guarantees for delivery of C2

requests & notifications Establishing real-time guarantees for handling sensor

interrupts Establishing minimum times for making an adaptive

change Determining maximum simultaneity of actions Predicting and maximizing connector throughput

“Know the Time”“Know the Time”

What Are The Constraints? (III)

In C2 terms … Minimizing overhead of adaptations Minimizing overhead of maintaining on-board

architectural model Establishing failure semantics and overhead

of failure recovery Minimizing other contributors to overhead

power consumption, communication protocols, …

“Know the Overhead”“Know the Overhead”

The Silicon Nanosatellite

Nanosatellite ConstellationsDense LEO constellations

500 to 1000 satellites at ~700 km altitude at least 2 satellites always above 30o elevation for

all surface locations one satellite always within 1000 km range

Local clusters (“platooning”) co-orbiting clusters up to 10 km diameter in LEO arbitrary “formation flying” up to 10 km diameter in

GEO “rigid array” orbits

Adaptation general-purpose versus specialized nanosatellites changes in orbital configuration failure and threat recovery

a14

a13

a12

a11

a10

a9

b9

b10

b11

b12

b13

c9

c10

c11

c12

c13

c14

d9

d10

d11

d12

d13

d14

Ad-hoc Networks

No pre-existing network infrastructure self configuring

node discoveryrouting discovery

multihop spontaneous networks

highly portableshort livedmembership diversity and tenure

Highly fault tolerantRouting tensions

per-node volume of routing data latency of route discovery route discovery overhead

Adaptation in Ad-hoc Networks

Power consumption power per bit network longevity

On-the-air format RF spectrum frame encoding error correction

Antenna diversity

Burst communications

Geospatial routingSemantic protocols

Demonstration

Architecture-based adaptation for ad-hoc network nodes dynamic adaptation using microprotocols reconstitute open source protocols as embedded

C2 microprotocolsAX.25 (media access and link layer)DSR (Dynamic Source Routing)

run protocol stack in emulated RF environmentBLT simulates satellite uplink/downlink bit error and

latencySPANNER simulates ground RF losses and noise

protocol stack will adapt to changing RF conditions and/or battery reserves

Summary of the C2 Project

An architectural style (“the C2 Style”) Asynchronous, event-based communication among

autonomous components, mediated by active connectors

Descriptive formalisms C2SADEL & graphical notations

Supporting tools Architecture development and analysis From model to implementation Evolution: static and dynamic Multi-model support

Summary

Architecture-based software engineering addresses the core issue of system design takes some old and mainstream ideas and makes

them betterdesign notations, domain knowledge rep.

leverages event-based interaction paradigm leverages results in middleware provides a viable basis for software reuse? provides a viable basis for dynamic adaptation