Architecture and Hardware/Software/System Engineering Integration Nenad Medvidovic

advertisement
Architecture and
Hardware/Software/System
Engineering Integration
Nenad Medvidovic
CS Department and CSSE
Viterbi School of Engineering
University of Southern California
neno@usc.edu
http://csse.usc.edu/~neno/
Why Architecture?
•
•
•
•
•
•
•
Early, high-level system model
Stakeholder understanding and communication
Focus on specific system properties
Separation of concerns
Early analysis and simulation
Tool-supported implementation
Improved processes and project management
21st Century Systems
• Novel computing platforms
–
–
–
–
Smart phones
Mobile robots
Motes
Sensors
• Novel usage scenarios
–
–
–
–
–
–
Search-and-rescue
Environment exploration
Traffic management
Medicine / Assisted living
Wireless sensor nets
Mobile grids
• Novel SE challenges
–
–
–
–
–
–
–
Distribution
Decentralization
Mobility
Heterogeneity
Resource constraints
Context awareness
Real-time requirements
Some Challenges
• Resource constraints
– Demand highly efficient computation,
communication, and memory footprint
– Demand unorthodox solutions
• Hardware and software heterogeneity
– Proprietary operating systems
– Dialects of programming languages
– Device-specific data formats
– Lack of support for inter-device interaction
– Lack of support for code mobility
Four Elements of the Solution
•
•
•
•
Modeling
Analysis
Deployment
Adaptation
From Models to Systems
Strategy
Analyzer
Agent
SAKBUI
Deployment
Advisor
HQ UI
Strategy
AnalysisKB
Comman
der UI
Weather
Repository
Simulation
Agent
Clock
Map
Resource
Manager
Weather
Analyzer
Soldier
UI
Resource
Monitor
Soldier
UI
Comman
der UI
From Models to Systems
Strategy
Analyzer
Agent
SAKBUI
Deployment
Advisor
HQ UI
Strategy
AnalysisKB
Comman
der UI
Weather
Repository
Host 1
Host 2
Simulation
Agent
Clock
Map
Resource
Manager
Weather
Analyzer
Resource
Monitor
Soldier
UI
Host 3
Soldier
UI
Host 4
Comman
der UI
Host 5
From Models to Systems
From Models to Systems
From Models to Systems
System Models in XTEAM
System Models
in DeSi
12
Analysis
How do we know
How do we know
is “better” than
?
Analysis in
XTEAM
From Architecture to Implementation
• Architectures provide high-level concepts
– Components, connectors, ports, events, configurations
• Programming languages provide low-level constructs
– Variables, arrays, pointers, procedures, objects
• Bridging the two often is an art-form
– Middleware can help “split the difference”
• Existing middleware technologies
– Support some architectural concepts (e.g., components, events)
– but not others (e.g., connectors, configurations)
– Impose particular architectural styles
• What about systems engineering support?
What is needed is “architectural middleware”
Architectural Middleware
• Native support for architectural concepts as middleware
constructs
• System design support via an accompanying ADL
• Quality assurance via analysis and simulation of architectural
models
• Round-trip development from architecture to implementation
and back
• Automated transformation of architectural models to
implementations
Prism Family of Middleware Platforms
From Implementation to Deployment
• Architecture in context
• A system’s deployment architecture is a
mapping of its components onto a set of
hardware hosts in a manner that preserves
their connectivity as expressed in the software
architectural model.
• This concept begs several questions
What do we do
What do we do
What do we do
X
X
if one or more components go down?
What do we do
X
X
if one or more hosts go down?
3. What do we do
X
X
if one or more network links go down?
What do we do
if a resource is overloaded?
The Big Picture
Component Repository
Domain Expert
Repopulate
Model
Design-time
Runtime
Analysis
Deployment
Model
Software
Architect
QoS Pref.
Monitor
Hardware System
Users
Deployment and Dynamic Adaptation
SD
Engine
Comp A
Repository
Comp B
Admin
Architecture 2
DLL
Monitor
DLL
Repository
Effector
Unicast Connector
DLL
Comp A
Byte
Array
DeSi Adapter Arch.
Connector D
Admin
Comp C
Repository
SD
Engine
Architecture 1
An Enduring Challenge
•
Guiding Insight
– System users have varying QoS
preferences for the system services
they access
• Impacts their satisfaction with the system
•
Research Question
– How could we improve system’s
deployment architecture to maximize
users’ satisfaction?
• Where users’ satisfaction depends on the
system’s ability to meet their QoS
preferences
• And where there are several possible, but
partial solutions: caching, hoarding,
replication, redeployment, …
•
Research Objective
– Devise a general solution that is
applicable to many classes of
application scenarios
A (not-so-shameless) Plug
Questions
Download