richard n. taylor institute for software research university of california, irvine [email protected]...
Post on 21-Dec-2015
214 views
TRANSCRIPT
Richard N. TaylorInstitute for Software ResearchUniversity of California, Irvine
[email protected]/~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