Why Software Reuse Has Failed – & How to Make It Work for You Douglas C.

Download Report

Transcript Why Software Reuse Has Failed – & How to Make It Work for You Douglas C.

Why Software Reuse Has Failed
– & How to Make It Work for You
Douglas C. Schmidt
[email protected]
Institute for Software
Integrated Systems
(ISIS)
Vanderbilt University
Douglas
Schmidt
The Road Ahead
CPU & network performance has increased by 3-8
orders of magnitude in past decades
10 Megahertz to
3+ Gigahertz
1,200 bits/sec to
10+ Gigabits/sec
Extrapolating these trends another decade or so yields
• ~100 Gigahertz desktops
• ~100 Gigabits/sec LANs
• ~100 Megabits/sec wireless
• ~10 Terabits/sec Internet backbone
Unfortunately, software quality &
productivity hasn’t improved as
rapidly or predictably as hardware –
especially for distributed real-time &
embedded (DRE) systems
Douglas
Schmidt
Why Hardware Improves So Consistently
Advances in hardware & networks stem largely from
R&D on standardized & reusable APIs & protocols
x86 & Power PC chipsets
TCP/IP
Douglas
Schmidt
Why Software Fails to Improve as Consistently
In general, software has not been as standardized or
reusable as hardware, especially for DRE systems
F-15
A/V-8B
F/A-18
UCAV
Proprietary & Stovepiped Application & Infrastructure Software
Nav
Air
Frame
Nav
HUD
AP
FLIR
Air
Frame
GPS
IFF
IFF
Application
Software
Cyclic
Exec
Cyclic
Exec
1553
VME
Link16
FLIR
FLIR
HUD
HUD
Air
Frame
Nav
AP
AP
Nav
AP
GPS
IFF
GPS
Air
Frame
Application
Software
Vx
Works
1553
VME
Link16
Application
Software
Vx
Works
GPS
HUD
FLIR
IFF
Application
Software
1553
VME
Link16
Standard/COTS Hardware & Networks
Douglas
Schmidt
What’s Hard About Software & Software Reuse?
Human Nature
Technical Complexities
Accidental Complexities
•Low-level APIs & debug tools
• Organizational impediments
•Algorithmic decomposition
• Economic impediments
Inherent Complexities
• Administrative impediments
• Political impediments
• Psychological impediments
•Quality of service (QoS)
•Causal ordering
•Scheduling & synchronization
•Deadlock
www.cs.wustl.edu/~schmidt/reuse-lessons.html
Douglas
Schmidt
Technical Complexities that Impact Reuse
Key complexities in the problem space
• Inherent complexities in network-centric,
dynamic, large-scale “systems of
systems”
• Stringent simultaneous quality of service
(QoS) demands
• Highly diverse, complex, & increasingly
integrated/autonomous application
domains
Key complexities in the solution space
• Many accidental & inherent
complexities
• Continuous evolution & change
• Highly heterogeneous (& legacy
constrained) platform, language, & tool
environments
It’s hard to map problems to systematically
reusable solution artifacts
Douglas
Schmidt
Key Reuse Challenges for Software Developers
Developers & users of reusable software face
challenges in multiple dimensions
Logical
View
Process
View
Use Case
View
Physical
View
Development
View
Douglas
Schmidt
Key Reuse Challenges for Software Developers
Determining units of abstraction
for system (de)composition,
reuse, & validation
Logical
View
• Popular technologies & tools provide
inadequate support for
– Checking pre-/post-conditions & invariants
– Specifying & analyzing dependencies
– Expressing design intent more clearly
using domain concepts
Douglas
Schmidt
Key Reuse Challenges for Software Developers
• Popular technologies & tools
provide inadequate support for
– Configuring & customizing
components for application
requirements & run-time
environments
– Automated mapping of
components onto nodes in
target environments
Physical
View
Integrating/deploying diverse new &
reusable application components in a
networked environment to ensure endto-end QoS requirements
Douglas
Schmidt
Key Reuse Challenges for Software Developers
• Popular technologies & tools
provide inadequate support for
– Identifying & reducing
performance & robustness
risks earlier in system lifecycle
– Satisfying multiple (often
conflicting) QoS demands
Devising execution architectures, concurrency
models, & communication styles that ensure
multi-dimensional QoS & correctness of
new/reusable components
Process
View
• e.g., secure, real-time,
reliable
– Satisfying QoS demands in
face of fluctuating/insufficient
resources
• e.g., mobile ad hoc
networks (MANETs)
Douglas
Schmidt
Key Reuse Challenges for Software Developers
• Popular technologies & tools
provide inadequate support for
avoiding
– Cyclic dependencies, which
make unit testing & reuse
hard
– Excessive link-time
dependencies, which bloat
the size of executables
– Excessive compile-time
dependencies, where small
changes trigger massive
recompiles
Development
View
(De)composing systems into
reusable modules (e.g., packages,
subsystems, libraries) that
achieve/preserve QoS properties
Douglas
Schmidt
Key Reuse Challenges for Software Developers
Capturing functional & QoS
requirements of systems &
reconciling them with other
views during evolution
Use Case
View
• Popular technologies & tools provide inadequate support for
– Ensuring semantic consistency & traceability between requirements &
software artifacts
– Visualizing software architectures from multiple views
Douglas
Schmidt
Promising Reuse Solution Approaches
Air
Frame
AP
Nav
Event
Channel
WTS
Replication
Service
Multi-faceted
Software
Development
Object Request Broker
GPS
IFF
FLIR
Cross-cutting Concerns
Synchronization
Persistence
Memory Management
Fault Tolerance
Model-based
analysis,
generation, &
integration
& domain-specific
languages
Component middleware &
frameworks that integrate
real-time, fault-tolerance, &
security properties
Verification & validation
technologies, e.g., model
checking & static analysis
Formalizing best practices
& design expertise
Douglas
Schmidt
Promising Reuse Solution Approaches
Devising composable
abstractions whose
interfaces & QoS properties
can be specified/analyzed
via metadata
…
Logical
View
• Components encapsulate “business” logic
• Components interact via ports
• Provided ports, e.g.,facets
• Required ports, e.g., receptacles
• Event sink & source ports
• Containers provide execution environment
Components/containers can also
• Communicate via a middleware bus and
• Reuse common middleware services
• Aspect-oriented techniques can help with
integration
…
…
…
Container
Container
Middleware Bus
Replication
Security
A/V Streaming
Persistence
Scheduling
Notification
Load Balancing
Douglas
Schmidt
Promising Reuse Solution Approaches
Physical
View
Model-driven development & analysis
techniques for optimizing, verifying, &
automating the deployment &
configuration process
Gigabit Ethernet
Douglas
Schmidt
Promising Reuse Solution Approaches
• Synthetic workload & simulated
components
• Replaced incrementally with
actual applications & components
Software architecture execution
modeling/simulation techniques & tools;
distributed continuous quality assurance
Process
View
EO
TBM
AAW
AAW
EG
Sched
AAW
EG
• Automate the QA
process
Build & Test Scoreboard
Kill
Eval
Illum
AAW
AAW
MG
AAW
Gigabit Ethernet
TMB
MG
Douglas
Schmidt
Promising Reuse Solution Approaches
• Packages view – shows element
tree defined by project's build
class path
• Type hierarchy view – shows the
sub- & supertype hierarchies
• Outline view – shows the structure
of a compilation unit or class file
• Browsing perspecitve – allows
navigating models using separate
views for projects, packages,
types & members
• Wizards for creating elements –
e.g., project, package, class,
interface
• Editors – syntax coloring, content
specific code assist, code resolve,
method level edit, import
assistance, quick fix & quick assist
Development
View
Development environments that provide
multiple views & minimize dependencies
between large-scale software artifacts to
Douglas
optimize development & test cycles
Schmidt
Promising Reuse Solution Approaches
Automated tracing of
(in)consistency between
requirement specifications &
associated software artifacts
Domain-Specific Modeling
Languages
Use Case
View
Matlab
Matlab
Artifact
Code-Gen.
Code-Gen.
Generator
if (inactiveInterval != -1) {
int thisInterval =
(int)(System.currentTimeMillis() lastAccessed) / 1000;
• One way to automate tracing
between higher-level specifications
& lower-level implementations is to
leverage model-driven development
techniques & tools
if (thisInterval > inactiveInterval) {
invalidate();
ServerSessionManager ssm =
ServerSessionManager.getManager();
ssm.removeSession(this);
}
}
}
private long lastAccessedTime = creationTime;
/**
* Return the last time the client sent a request
associated with this
* session, as the number of milliseconds since
midnight, January 1, 1970
* GMT. Actions that your application takes, such as
getting or setting
* a value associated with the session, do not affect
the access time.
*/
public long getLastAccessedTime() {
Configuration
Specification
return (this.lastAccessedTime);
}
this.lastAccessedTime = time;
Code
Analysis Tool
Douglas
Schmidt
Proven Systematic Reuse Technologies
• Frameworks
• Product-line Architectures
NETWORKING
ADTs
Reactor
Strings
Mission Computing Services
Middleware Infrastructure
INVOKE
S
Operating System
APPLICATIONSPECIFIC
FUNCTIONALITY
CALLBACKS
Files
Networking Interfaces
• Patterns & Pattern
Languages
Hardware (CPU, Memory, I/O)
• Component
Middleware
GUI
Locks
DATABASE
• Model-Driven
Development Tools
Naming
Events
Logging
Locking
Middleware Bus
Douglas
Schmidt
Product-line Architecture Example: Boeing Bold Stroke
Nav Sensors
Vehicle
Mgmt
Data Links
Mission
Computer
Radar
Expendable
Management
Expendables
• Avionics mission computing product-line architecture for
Boeing aircraft
Bold Stroke
Architecture
• DRE system with 100+ developers, 3,000+ software
components, 3-5 million lines of C++
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
• Based on COTS hardware,
networks, operating systems,
languages, & middleware
• Used as Open Experimentation Platform for DARPA IXO
PCES, MoBIES, SEC, NEST,
& MICA programs
Douglas
Schmidt
Applying COTS to Boeing Bold Stroke
COTS & standards-based middleware,
language, OS, network, & hardware
platforms
• Real-time CORBA middleware services
• ADAPTIVE Communication
Environment (ACE)
• C++/C & Real-time Java
• VxWorks operating system
• VME, 1553, & Link16
• PowerPC
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
www.cs.wustl.edu/
~schmidt/TAO.html
Douglas
Schmidt
Benefits of Using COTS
•Save a considerable amount of
time/effort compared with
handcrafting capabilities
•Leverage industry “best
practices” & patterns in prepackaged & ideally standardized
form
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Limitations of Using COTS
• QoS of COTS components is not
always suitable for mission-critical
systems
• COTS technologies address some, but
not all, of the domain-specific
challenges associated with developing
mission-critical DRE systems
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
What we need is a reuse
technology for organizing
& automating key roles &
responsibilities in an
application domain
Douglas
Schmidt
Motivation for Product-line Architectures (PLAs)
Nav
Air
Frame
HUD
Nav
AP
FLIR
Air
Frame
GPS
IFF
IFF
Cyclic
Exec
AP
Cyclic
Exec
F-15
Legacy DRE systems have
historically been:
• Stovepiped
• Proprietary
• Brittle & non-adaptive
• Expensive
• Vulnerable
Nav
HUD
HUD
FLIR
AP
FLIR
GPS
IFF
GPS
Cyclic
Exec
A/V-8B
Air
Frame
GPS
Nav
AP
FLIR
Air
Frame
Cyclic
Exec
F/A-18
HUD
IFF
UCAV
Consequence: Small
HW/SW changes
have big (negative)
impact on DRE
system QoS &
maintenance
Douglas
Schmidt
Motivation for Product-line Architectures (PLAs)
F/A 18
product
variant
A/V 8-B
product
variant
F-15
product
variant
Air
Frame
FLIR
HUD
GPS
UCAV
product
variant
AP
Nav
IFF
Domain-specific Services
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
OS & Network Protocols
Product-line
architecture
Hardware (CPU, Memory, I/O)
• Frameworks factors out many reusable general-purpose & domain-specific
services from traditional DRE application responsibility
• Essential for product-line architectures (PLAs)
• Product-lines & frameworks offer many configuration opportunities
• e.g., component distribution & deployment, user interfaces & operating
systems, algorithms & data structures, etc.
Douglas
Schmidt
Overview of Product-line Architectures (PLAs)
• PLA characteristics are
captured via Scope,
Commonalities, & Variabilities
(SCV) analysis
• This process can be applied to
identify commonalities &
variabilities in a domain to
guide development of a PLA
•Applying SCV to Bold Stroke
• Scope defines the domain & context of
the PLA
• Bold Stroke component architecture,
object-oriented application frameworks,
& associated components, e.g., GPS,
Airframe, & Display
Reusable Application
Components
Air
Frame
FLIR
HUD
Reusable Architecture
Framework
GPS
AP
Nav
IFF
Domain-specific Services
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
OS & Network Protocols
Douglas
Schmidt
Applying SCV to the Bold Stroke PLA
• Commonalities describe the attributes that are common across all members of
the PLA family
• Common object-oriented frameworks & set of component types
• e.g., GPS, Airframe, Navigation, & Display components
• Common middleware
infrastructure
• e.g., Real-time CORBA
& a variant of
Lightweight CORBA
Component Model
(CCM) called Prism
GPS
Component
Display
Component
Airframe
Component
Heads Up
Display
Bold Stroke Common Components
Domain-specific Services
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
OS & Network Protocols
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Applying SCV to the Bold Stroke PLA
• Variabilities describe the
attributes unique to the different
members of the family
GPS
Component
• Product-dependent
component implementations
(GPS/INS)
• Product-dependent
component connections
• Product-dependent
component assemblies (e.g.,
different weapons systems for
different customers/countries)
Display
Component
Airframe
Component
Heads Up
Display
Bold Stroke Common Components
GPS = 40 Hz
GPS = 20 Hz
Nav
Air
Frame
HUD
AP
FLIR
IFF
GPS
F/A 18 F
Nav
GPS=20Hz
Air
Frame
Air
Frame
HUD
AP
FLIR
GPS
IFF
Nav
GPS
AP
FLIR
HUD
F 15K
IFF
UCAV
• Different hardware, OS, &
network/bus configurations
Domain-specific Services
Patterns & frameworks are
essential for developing
reusable PLAs
Common Middleware Services
Distribution Middleware
Host Infrastructure Middleware
OS & Network Protocols
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Applying Patterns & Frameworks to Bold Stroke
Reusable object-oriented application
domain-specific middleware framework
• Configurable to variable infrastructure
configurations
• Supports systematic reuse of mission
computing functionality
• 3-5 million lines of C++
• Based on many architecture & design
patterns
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Patterns & frameworks
are also used
throughout COTS
software infrastructure
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Overview of Patterns
•Present solutions
to common
software problems
arising within a
certain context
•Help resolve
key software
design
forces
•Capture recurring structures &
dynamics among software
participants to facilitate reuse of
successful designs
•Generally codify expert
knowledge of design strategies,
constraints & “best practices”
•Flexibility
•Extensibility
•Dependability
•Predictability
•Scalability
•Efficiency
AbstractService
service
Client
Proxy
service
Service
1
1
service
The Proxy Pattern
Douglas
Schmidt
Overview of Pattern Languages
Motivation
•Individual patterns &
pattern catalogs are
insufficient
•Software modeling methods
& tools largely just illustrate
what/how – not why –
systems are designed
Benefits of Pattern Languages
• Define a vocabulary for talking about software
development problems
• Provide a process for the orderly resolution of
these problems
• Help to generate & reuse software architectures
Douglas
Schmidt
Taxonomy of Patterns & Idioms
Type
Description
Examples
Idioms
Restricted to a particular language,
system, or tool
Scoped locking
Design
patterns
Capture the static & dynamic roles &
relationships in solutions that occur
repeatedly
Active Object,
Bridge, Proxy,
Wrapper Façade,
& Visitor
Architectural
patterns
Express a fundamental structural
organization for software systems that
provide a set of predefined subsystems,
specify their relationships, & include the
rules & guidelines for organizing the
relationships between them
Half-Sync/HalfAsync, Layers,
Proactor,
PublisherSubscriber, &
Reactor
Optimization
principle
patterns
Document rules for avoiding common
design & implementation mistakes that
degrade performance
Optimize for
common case,
pass information
between layers
Douglas
Schmidt
Legacy Avionics Architectures
Key System Characteristics
•Hard & soft real-time deadlines
•~20-40 Hz
•Low latency & jitter between
boards
•~100 usecs
•Periodic & aperiodic processing
•Complex dependencies
•Continuous platform upgrades
Avionics Mission
Computing Functions
•Weapons targeting
systems (WTS)
•Airframe & navigation
(Nav)
•Sensor control (GPS,
IFF, FLIR)
•Heads-up display
(HUD)
•Auto-pilot (AP)
Board 1
1553
4: Mission
functions
perform
avionics
operations
3: Sensor
proxies
process data
& pass to
missions
functions
2: I/O via
interrupts
1: Sensors
generate
data
VME
Board 2
Douglas
Schmidt
Legacy Avionics Architectures
Key System Characteristics
•Hard & soft real-time deadlines
•~20-40 Hz
•Low latency & jitter between
boards
•~100 usecs
•Periodic & aperiodic processing
•Complex dependencies
•Continuous platform upgrades
Limitations with Legacy Avionics
Architectures
•Stovepiped
•Proprietary
•Expensive
•Vulnerable
•Tightly coupled
•Hard to schedule
•Brittle & non-adaptive
Nav
Air
Frame
WTS
AP
FLIR
GPS
IFF
4: Mission
functions
perform
avionics
operations
3: Sensor
proxies
process data
& pass to
missions
functions
Cyclic
Exec
2: I/O via
interrupts
Board 1
1553
1: Sensors
generate
data
VME
Board 2
Douglas
Schmidt
Decoupling Avionics Components
Context
Problems
Solution
• I/O driven DRE
application
• Tightly coupled
components
• Complex
dependencies
• Hard to schedule
• Apply the Publisher-Subscriber
architectural pattern to distribute
periodic, I/O-driven
data from a single point of
source to a collection of
consumers
• Expensive to evolve
• Real-time constraints
Structure
Publisher
produce
Event Channel
attachPublisher
detachPublisher
attachSubscriber
detachSubscriber
pushEvent
creates
*
Event
Dynamics
Subscriber
: Publisher
: Event Channel
: Subscriber
attachSubscriber
consume
produce
: Event
pushEvent
event
pushEvent
event
receives
consume
Filter
filterEvent
detachSubscriber
Douglas
Schmidt
Applying the Publisher-Subscriber Pattern to Bold Stroke
Bold Stroke uses the PublisherSubscriber pattern to decouple sensor
processing from mission computing
operations
• Anonymous publisher & subscriber
relationships
• Group communication
• Asynchrony
Considerations for implementing the
Publisher-Subscriber pattern for
mission computing applications include:
• Event notification model
• Push control vs. pull data interactions
• Scheduling & synchronization strategies
• e.g., priority-based dispatching &
preemption
• Event dependency management
• e.g.,filtering & correlation mechanisms
Subscribers
HUD
WTS
Air
Frame
Nav
4: Event Channel
pushes events
to
subscribers(s)
push(event)
Event
Channel
push(event)
GPS
IFF
5: Subscribers
perform
avionics
operations
FLIR
Publishers
3: Sensor
publishers
push events
to event
channel
2: I/O via interrupts
Board 1
1553
1: Sensors
generate
data
VME
Board 2
Douglas
Schmidt
Ensuring Platform-neutral Inter-process Communication
Context
Problems
Solution
• Mission
computing
requires
remote IPC
• Applications need capabilities to:
• Support remote communication
• Provide location transparency
• Handle faults
• Stringent DRE
• Manage end-to-end QoS
requirements
• Encapsulate low-level system details
• Apply the Broker
architectural pattern to
provide platform-neutral
communication between
mission computing
boards
Server Proxy
Client Proxy
marshal
unmarhal
receive_result
service_p
* calls
1
Client
call_service_p
start_task
Structure
*
1
Broker
message main_loop
exchange srv_registration
srv_lookup
xmit_message
manage_QoS
1
*
message
exchange
marshal
unmarshal
dispatch
receive_request
* calls
1
Server
start_up
main_loop
service_i
Douglas
Schmidt
Ensuring Platform-neutral Inter-process Communication
Context
Problems
Solution
• Mission
computing
requires
remote IPC
• Applications need capabilities to:
• Support remote communication
• Provide location transparency
• Handle faults
• Stringent DRE
• Manage end-to-end QoS
requirements
• Encapsulate low-level system details
: Client
: Client Proxy
operation (params)
: Broker
• Apply the Broker
architectural pattern to
provide platform-neutral
communication between
mission computing
boards
: Server Proxy
: Server
register_service
connect
marshal
Dynamics
start_up
assigned
port
send_request
unmarshal
dispatch
operation (params)
receive_reply
result
marshal
unmarshal
result
Douglas
Schmidt
Applying the Broker Pattern to Bold Stroke
Bold Stroke uses the Broker pattern
to shield distributed applications
from environment heterogeneity,
e.g.,
Subscribers
HUD
Air
Frame
push(event)
•Programming languages
5: Event Channel
pushes events
to subscribers(s)
Event
Channel
•Operating systems
push(event)
•Networking protocols
•Hardware
WTS
Nav
GPS
IFF
FLIR
Publishers
A key consideration for
implementing the Broker pattern
for mission computing applications
is QoS support
•e.g., latency, jitter, priority
preservation, dependability,
security, etc.
6: Subscribers
perform
avionics
operations
4: Sensor
publishers
push events
to event
channel
3: Broker
handles I/O
via upcalls
Broker
2: I/O via interrupts
Board 1
1553
1: Sensors
generate
data
VME
Board 2
Douglas
Schmidt
Benefits of Patterns
Subscribers
Nav
WTS
HUD
push(event)
Air Frame
• Improves development team
communication
Event
Channel
• Convey “best practices” intuitively
push(event)
GPS
• Enables reuse of software
architectures & designs
IFF
FLIR
Publishers
Broker
• Transcends language-centric
biases/myopia
• Abstracts away from many
unimportant details
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
www.cs.wustl.edu/
~schmidt/patterns.html
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Limitations of Patterns
Subscribers
Nav
WTS
HUD
push(event)
Air Frame
Event
Channel
• Can be deceptively simple
push(event)
GPS
• Require significant tedious &
error-prone human effort to
handcraft pattern
implementations
IFF
FLIR
Publishers
Broker
• Leaves many important details
unresolved
We therefore need
more than just
patterns to achieve
systematic reuse
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
www.cs.wustl.edu/
~schmidt/patterns.html
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Summary of Reuse Platform Paradigms
“Write Code That Reuses Code”
APPLICATIONSPECIFIC
FUNCTIONALITY
LOCAL
INVOCATIONS
Class Library Architecture
Math
IPC
ADTs
Files
Strings
GUI
EVENT
LOOP
GLUE
CODE
Locks
Reactor
ADTs
Strings
INVOKES
Files
• A class is a unit of abstraction &
implementation in an OO programming
language, i.e., a reusable type that often
implements patterns
• Classes in class libraries are typically passive
NETWORKING
Framework Architecture
APPLICATIONSPECIFIC
FUNCTIONALITY
CALLBACKS
GUI
Locks
• A framework is an integrated set of classes
that collaborate to produce a reusable
architecture for a family of applications
• Frameworks implement pattern languages
DATABASE
Component Architecture
Naming
Events
Logging
Locking
Middleware Bus
• A component is an encapsulation unit with
one or more interfaces that provide clients
with access to its services
• Components can be deployed & configured
Douglas
via assemblies
Schmidt
Applying Frameworks to Bold Stroke
Application-specific functionality
Sensor
Management
Networking
Route
Planning
Real-time
Database
Framework
characteristics
Heads-up
Display
GUI
• Frameworks exhibit
“inversion of control” at
runtime via callbacks
• Frameworks provide
integrated domainspecific structures &
functionality
• Frameworks are “semicomplete” applications
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
www.cs.wustl.edu/
~schmidt/ACE.html
Douglas
Schmidt
Benefits of Frameworks
• Design reuse
• e.g., by guiding application
developers through the steps
necessary to ensure successful
creation & deployment of
software
AdminClient
Admin
Controllers
Admin
Views
Proxy
PickingClient
Picking
Controllers
Thin UI Clients
Broker
Picking
Views
Proxy
Broker
Distribution
Infrastructure
OS-Access
Layer
Component
Repository
Communication
Component
Configurator
Services
Broker
Broker
Scheduler/
ActivationList
Reactor
Service
Request
Logging
Handler
ThreadPool
Service
Request
Service
Request
WarehouseRepHalfX
*
Concurrency
Infrastructure
Douglas
Schmidt
Benefits of Frameworks
package org.apache.tomcat.session;
• Design reuse
• e.g., by guiding application
developers through the steps
necessary to ensure successful
creation & deployment of
software
• Implementation reuse
• e.g., by amortizing software
lifecycle costs & leveraging
previous development &
optimization efforts
import
import
import
import
import
import
import
org.apache.tomcat.core.*;
org.apache.tomcat.util.StringManager;
java.io.*;
java.net.*;
java.util.*;
javax.servlet.*;
javax.servlet.http.*;
/**
* Core implementation of a server session
*
* @author James Duncan Davidson [[email protected]]
* @author James Todd [[email protected]]
*/
public class ServerSession {
private StringManager sm =
StringManager.getManager("org.apache.tomcat.session");
private Hashtable values = new Hashtable();
private Hashtable appSessions = new Hashtable();
private String id;
private long creationTime = System.currentTimeMillis();;
private long thisAccessTime = creationTime;
private int inactiveInterval = -1;
ServerSession(String id) {
this.id = id;
}
public String getId() {
return id;
}
public long getCreationTime() {
return creationTime;
}
public ApplicationSession getApplicationSession(Context context,
boolean create) {
ApplicationSession appSession =
(ApplicationSession)appSessions.get(context);
if (appSession == null && create) {
// XXX
// sync to ensure valid?
}
//
//
//
//
}
appSession = new ApplicationSession(id, this, context);
appSessions.put(context, appSession);
XXX
make sure that we haven't gone over the end of our
inactive interval -- if so, invalidate & create
a new appSession
return appSession;
void removeApplicationSession(Context context) {
appSessions.remove(context);
}
Douglas
Schmidt
Benefits of Frameworks
• Design reuse
• e.g., by guiding application
developers through the steps
necessary to ensure successful
creation & deployment of
software
• Implementation reuse
• e.g., by amortizing software
lifecycle costs & leveraging
previous development &
optimization efforts
• Validation reuse
• e.g., by amortizing the efforts of
validating application- &
platform-independent portions
of software, thereby enhancing
software reliability & scalability
Douglas
Schmidt
Limitations of Frameworks
• Frameworks are powerful, but hard to
develop & use effectively for many
application developers
• Significant time required to evaluate
applicability & quality of a framework for a
particular domain
• Debugging is tricky due to inversion of
control
• V&V is tricky due to “late binding”
• May incur performance degradations due to
extra (unnecessary) levels of indirection
Mission Computing Services
Middleware Infrastructure
We therefore need
something simpler than
frameworks to achieve
systematic reuse
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
www.cs.wustl.edu/
~schmidt/PDF/Queue-04.pdf
Douglas
Schmidt
Applying Component Middleware to Bold Stroke
Product-line component model
Positioning Unit
RateGen
Pulse
Rate
GPS
Refresh
Ready
LEDDisplay
Refresh
GetLocation
MyLocation
Instrument Cluster
GUIDisplay
Refresh
GPSLocation
• Configurable for product-specific
functionality & execution environment
• Single component development policies
• Standard component packaging
mechanisms
• 3,000+ software components
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Benefits of Component Middleware
• Creates a standard
“virtual boundary” around
application component
implementations that
interact only via welldefined interfaces
• Define standard
container mechanisms
needed to execute
components in generic
component servers
• Specify the infrastructure
needed to configure &
deploy components
throughout a distributed
system
…
…
…
Container
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
…
…
<ComponentAssemblyDescription id="a_HUDDisplay"> ...
<connection>
<name>GPS-RateGen</name>
<internalEndPoint><portName>Refresh</portName><instance>a_GPS</
instance>
</internalEndPoint>
<internalEndPoint>
<portName>Pulse</portName><instance>a_RateGen</instance>
</internalEndPoint>
</connection>
<connection>
<name>NavDisplay-GPS</name>
<internalEndPoint><portName>Refresh</portName><instance>a_NavDi
splay</instance>
</internalEndPoint>
<internalEndPoint><portName>Ready</portName><instance>a_GPS</in
stance>
</internalEndPoint>
</connection> ...
</ComponentAssemblyDescription>
Douglas
Schmidt
Limitations of Component Middleware
DRE Applications
Middleware
Services
•Limit to how much application
functionality can be refactored into
reusable COTS component
middleware
Middleware
Operating System
& Protocols
Hardware &
Networks
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Limitations of Component Middleware
Load Balancer
FT CORBA
Workload &
Replicas
RT/DP CORBA + DRTSJ
Connections &
priority bands
RTOS + RT
Java
IntServ + Diffserv
CPU & memory
•Limit to how much application
functionality can be refactored into
reusable COTS component
middleware
•Middleware itself has become hard to
provision/use
Network latency
& bandwidth
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Limitations of Component Middleware
•Limit to how much application
functionality can be refactored into
reusable COTS component
middleware
•Middleware itself has become hard to
provision/use
•Large # of components can be
tedious & error-prone to configure &
deploy without proper integration tool
support
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Limitations of Component Middleware
RT-CORBA
Apps DRE
RT-CORBA
Services
RT-CORBA
J2ME
DRTSJ
Applications
Apps
Apps
Middleware
J2ME
Services
Services
Middleware
J2ME
DRTSJ
Services
DRTSJ
Operating System
& Protocols
Hardware &
Networks
•Limit to how much application
functionality can be refactored into
reusable COTS component
middleware
•Middleware itself has become hard to
provision/use
•Large # of components can be
tedious & error-prone to configure &
deploy without proper integration tool
support
• There are many
middleware technologies
to choose from
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Applying MDD to Boeing Bold Stroke
Model-driven development
(MDD)
Positioning Unit
RateGen
Pulse
Rate
GPS
Refresh
Ready
LEDDisplay
Refresh
GetLocation
MyLocation
Instrument Cluster
GUIDisplay
• Apply MDD tools to
• Model
• Analyze
• Synthesize
Refresh
GPSLocation
<CONFIGURATION_PASS>
<HOME>
<…>
<COMPONENT>
<ID> <…></ID>
<EVENT_SUPPLIER>
<…events this
component supplies…>
</EVENT_SUPPLIER>
</COMPONENT>
</HOME>
</CONFIGURATION_PASS>
• Provision
middleware & application
components
• Configure product-specific
component assembly &
deployment environments
Mission Computing Services
Middleware Infrastructure
• Model-based component
integration policies
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
www.isis.vanderbilt.edu/
projects/mobies
Douglas
Schmidt
Applying MDD to Boeing Bold Stroke
EMBEDDED PLATFORM MODEL
UML/Rose
ESML/GME
PICML/GME
PowerPC/
ACE+TAO/
BOLDSTROKE
APPLICATION MODELING TOOLS
Formal mission specs,
subsystem models, &
computational constraints
are combined into integrated
MDD tool chain & mapped to
execution platforms
Interaction is based on
mission-specific
ontologies & semantics
ARIES
TimeWeaver
TimeWiz
Cadena
ANALYSIS TOOLS
Stateflow
C/C++
Statecharts
SMV
Ptolemy
SPIN
Simulink
Mission Computing Services
Middleware Infrastructure
Real-time Java
XML
Ptolemy
CODE GENERATORS
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
www.rl.af.mil/tech/
programs/MoBIES/
Douglas
Schmidt
Avionics Mission Computing
Modeling Languages
Benefits of MDD
• Increase expressivity
• e.g., linguistic support to better capture
design intent
• Increase precision
..
Artifact
Generator
• e.g., mathematical tools for cross-domain
modeling, synchronizing models, change
propagation across models, modeling
security & other QoS aspects
• Achieve reuse of domain semantics
• Generate code that’s more “platformindependent” (or not)!
• Support product-line
architecture development
& evolution
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
Douglas
Schmidt
Limitations of MDD
Model & Component
Library
Applications
$
$
Mission Computing Services
Middleware Infrastructure
Operating System
Networking Interfaces
Hardware (CPU, Memory, I/O)
$
•Modeling technologies
are still maturing &
evolving
• i.e., non-standard
tools
•Magic (& magicians) are
still necessary for
success
Douglas
Schmidt
Overview of Generative Software Technologies
“Write Code That Writes Code”
Aspect-Oriented Technologies
SessionExpiration
ServerSessionManager
ServerSession
Model-Driven Technologies
Domain-Specific Modeling
Languages
privat e lon g la stAcc essed = cr eatio nTim e;
pri vate int inact iveIn terva l = - 1;
package org. apac he.to mcat. sessi on;
synchro nized voi d inv alida te() {
Enum erat ion e num = appS essio ns.k eys() ;
import org.a pach e.tom cat.c ore.* ;
import org.a pach e.tom cat.u til.S tring Mana ger;
import java. io.* ;
import java. net. *;
import java. util .*;
import javax .ser vlet. *;
import javax .ser vlet. http. *;
appS essio n.inv alida te();
syn chron ized void reap () {
Enum erat ion e num = sess ions. keys ();
/**
*
* @aut hor J ames Dunc an Da vidso n [du ncan @eng. sun.c om]
* @aut hor J ason Hunt er [j ch@en g.sun .com ]
* @aut hor J ames Todd [gon zo@en g.sun .com ]
*/
}
pub lic v oid putVa lue(S tring name , Ob ject value ) {
if ( name == n ull) {
Stri ng ms g = s m.get Strin g("s erver Sessi on.va lue.i ae") ;
vali date ();
}
whil e (e num.h asMor eElem ents( )) {
Obje ct ke y = e num.n extEl emen t();
Serv erSes sion sessi on = (Ser verSe ssion )sess ions. get( key);
}
/**
* Core impl emen tatio n of a ser ver s essi on
*
* @aut hor J ames Dunc an Da vidso n [du ncan @eng. sun.c om]
* @aut hor J ames Todd [gon zo@en g.sun .com ]
*/
void a ccess ed() {
// s et l ast a ccess ed to this Acce ssTim e as it wi ll be lef t ove r
// f rom the p revio us ac cess
last Acce ssed = thi sAcce ssTim e;
this Acce ssTim e = S ystem .curr entT imeMi llis( );
// XXX
// sync' d fo r saf ty -- no o ther thre ad sh ould be ge tting som ethin g
// from this whil e we are r eapin g. T his i sn't the m ost o ptim al
// solut ion for t his, but w e'll dete rmine some thing else lat er.
package org. apac he.to mcat. sessi on;
import org.a pach e.tom cat.u til.* ;
import org.a pach e.tom cat.c ore.* ;
import java. io.* ;
import java. net. *;
import java. util .*;
import javax .ser vlet. http. *;
whil e (e num.h asMor eElem ents( )) {
Obje ct ke y = e num.n extEl emen t();
Appl icati onSes sion appSe ssio n =
(Appl icati onSes sion) appS essio ns.ge t(key );
voi d val idat e() {
// i f we have an i nacti ve in terv al, c heck to se e if we'v e exc eeded
it
if ( inac tiveI nterv al != -1) {
int thisI nterv al =
(int) (Syst em.cu rrent Time Milli s() - last Acces sed) / 10 00;
sess ion.r eap() ;
sess ion.v alida te();
}
}
if ( thisI nterv al > inact iveI nterv al) {
inval idate ();
thro w new Ille galAr gumen tExc eptio n(msg );
public class Ser verSe ssion {
public class Ser verSe ssion Manag er im plem ents Sessi onMan ager {
}
pri vate Stri ngMan ager sm =
Stri ngMa nager .getM anage r("or g.ap ache. tomca t.ses sion" );
pri vate Hash table valu es = new H asht able( );
pri vate Hash table appS essio ns = new Hasht able( );
pri vate Stri ng id ;
pri vate long crea tionT ime = Syst em.c urren tTime Milli s();;
pri vate long this Acces sTime = cr eati onTim e;
private int inac tiveI nterv al = -1;
syn chron ized void remo veSes sion( Serv erSes sion sessi on) {
Stri ng i d = s essio n.get Id();
pri vate Stri ngMan ager sm =
Stri ngMa nager .getM anage r("or g.ap ache. tomca t.ses sion" );
pri vate stat ic Se rverS essio nMana ger manag er; / / = n ew Se rver Sessi onMan ager( );
remo veVa lue(n ame); // remov e an y exi sting bind ing
valu es.p ut(na me, v alue) ;
}
}
}
}
sess ion. inval idate ();
sess ions .remo ve(id );
public long get LastA ccess edTim e() {
if ( vali d) {
retu rn la stAcc essed ;
} el se {
Stri ng ms g = s m.get Strin g("a pplic ation Sessi on.se ssio n.ise ");
}
pro tecte d in t ina ctive Inter val = -1;
pub lic O bjec t get Value (Stri ng na me) {
if ( name == n ull) {
Stri ng ms g = s m.get Strin g("s erver Sessi on.va lue.i ae") ;
Ser verSe ssio n(Str ing i d) {
this .id = id;
pub lic v oid remov eSess ions( Conte xt c ontex t) {
Enum erat ion e num = sess ions. keys ();
sta tic {
mana ger = new Serv erSes sionM anag er();
}
thro w new Ille galAr gumen tExc eptio n(msg );
whil e (e num.h asMor eElem ents( )) {
Obje ct ke y = e num.n extEl emen t();
Serv erSes sion sessi on = (Ser verSe ssion )sess ions. get( key);
Appl icati onSes sion appSe ssio n =
sessi on.ge tAppl icati onSe ssion (cont ext, false );
}
}
pub lic s tati c Ser verSe ssion Manag er g etMan ager( ) {
retu rn m anage r;
}
retu rn v alues .get( name) ;
}
pub lic S trin g get Id() {
retu rn i d;
pri vate Hash table sess ions = new Has htabl e();
pri vate Reap er re aper;
pub lic E nume ratio n get Value Names () {
retu rn v alues .keys ();
}
}
pub lic l ong getCr eatio nTime () {
retu rn c reati onTim e;
}
pub lic A ppli catio nSess ion g etApp lica tionS essio n(Con text cont ext,
bool ean creat e) {
Appl icat ionSe ssion appS essio n =
(App licat ionSe ssion )appS essi ons.g et(co ntext );
pub lic v oid setMa xInac tiveI nterv al(i nt in terva l) {
inac tive Inter val = inte rval;
pub lic i nt g etMax Inact iveIn terva l() {
retu rn i nacti veInt erval ;
}
// XXX
// sync' d fo r saf ty -- no o ther thre ad sh ould be ge tting som ethin g
// from this whil e we are r eapin g. T his i sn't the m ost o ptim al
// solut ion for t his, but w e'll dete rmine some thing else lat er.
appS essio n = n ew Ap plica tion Sessi on(id , thi s, co ntex t);
appS essio ns.pu t(con text, app Sessi on);
retu rn s essio n.get Appli catio nSes sion( ctx, true );
}
pub lic H ttpS essio n fin dSess ion(C onte xt ct x, St ring id) {
Serv erSe ssion sSes sion= (Serv erSe ssion )sess ions. get(i d);
if(s Sess ion== null) retu rn nu ll;
}
syn chron ized void reap () {
Enum erat ion e num = appS essio ns.k eys() ;
// X XX
// m ake sure that we ha ven't gon e ove r the end of ou r
// i nact ive i nterv al -- if s o, i nvali date and c reate
// a new appS essio n
void a ccess ed() {
// s et l ast a ccess ed to this Acce ssTim e as it wi ll be lef t ove r
// f rom the p revio us ac cess
last Acce ssed = thi sAcce ssTim e;
this Acce ssTim e = S ystem .curr entT imeMi llis( );
}
void va lidat e() {
// i f we have an i nacti ve in terv al, c heck to se e if
// w e've exce eded it
}
retu rn s Sessi on.ge tAppl icati onSe ssion (ctx, fals e);
whil e (e num.h asMor eElem ents( )) {
Obje ct ke y = e num.n extEl emen t();
Appl icati onSes sion appSe ssio n =
(Appl icati onSes sion) appS essio ns.ge t(key );
retu rn a ppSes sion;
privat e lon g la stAcc essed = cr eatio nTim e;
/**
* Used by c ontex t to confi gure the sessi on ma nager 's in acti vity timeo ut.
*
* The S essi onMan ager may h ave s ome defau lt se ssion time out , the
* Conte xt o n the othe r han d has it' s tim eout set b y the dep loyme nt
* descr ipto r (we b.xml ). Th is me thod lets the Conte xt co nfor gure the
* sessi on m anage r acc ordin g to this valu e.
*
* @para m mi nutes The sessi on in acti vity timeo ut in minu tes.
*/
pub lic v oid setSe ssion TimeO ut(in t mi nutes ) {
if(- 1 != minu tes) {
// T he ma nager work s wit h se conds ...
inac tiveI nterv al = (minu tes * 60) ;
}
}
if(- 1 != inac tiveI nterv al) {
sess ion. setMa xInac tiveI nterv al(i nacti veInt erval );
}
// X XX
// s ync t o ens ure v alid?
}
}
public HttpS essi on cr eateS essio n(Con text ctx) {
Stri ng s essio nId = Sess ionId Gene rator .gene rateI d();
Serv erSe ssion sess ion = new Serv erSes sion( sessi onId) ;
sess ions .put( sessi onId, sess ion) ;
}
if ( appS essio n == null && cr eate ) {
thro w new Ille galSt ateEx cept ion(m sg);
}
}
public long get LastA ccess edTim e() {
retu rn l astAc cesse d;
}
if ( appSe ssion != n ull) {
appSe ssion .inva lidat e();
}
pri vate Serv erSes sionM anage r() {
reap er = Reap er.ge tReap er();
reap er.s etSer verSe ssion Manag er(t his);
reap er.s tart( );
}
pub lic v oid remov eValu e(Str ing n ame) {
valu es.r emove (name );
}
}
}
appS essio n.val idate ();
voi d rem oveA pplic ation Sessi on(Co ntex t con text) {
appS essi ons.r emove (cont ext);
}
}
}
}
/**
* Calle d by cont ext w hen r eques t co mes i n so that acces ses and
* inact ivit ies c an be deal t wit h ac cordi ngly.
*/
voi d val idat e()
Aspect-Oriented Language
Technology
• Code Analyzer
• Weaver
• Code Transformation
ServerSession
package org. apac he.to mcat. sessi on;
import org.a pach e.tom cat.c ore.* ;
import org.a pach e.tom cat.u til.S tring Mana ger;
import java. io.* ;
import java. net. *;
import java. util .*;
import javax .ser vlet. *;
import javax .ser vlet. http. *;
void va lidat e() {
// i f we have an i nacti ve in terv al, c heck to se e if
// w e've exce eded it
if ( inac tiveI nterv al != -1) {
int thisI nterv al =
(int) (Syst em.cu rrent Time Milli s() - last Acces sed) / 10 00;
if ( thisI nterv al > inact iveI nterv al) {
inval idate ();
/**
* Core impl emen tatio n of a ser ver s essi on
*
* @aut hor J ames Dunc an Da vidso n [du ncan @eng. sun.c om]
* @aut hor J ames Todd [gon zo@en g.sun .com ]
*/
Serve rSess ionMa nager ssm =
S erver Sessi onMan ager .getM anage r();
ssm.r emove Sessi on(th is);
}
}
public class Ser verSe ssion {
pri vate Stri ngMan ager sm =
Stri ngMa nager .getM anage r("or g.ap ache. tomca t.ses sion" );
pri vate Hash table valu es = new H asht able( );
pri vate Hash table appS essio ns = new Hasht able( );
pri vate Stri ng id ;
pri vate long crea tionT ime = Syst em.c urren tTime Milli s();;
pri vate long this Acces sTime = cr eati onTim e;
pri vate long last Acces sed = crea tion Time;
pri vate int inact iveIn terva l = - 1;
syn chron ized void inva lidat e() {
Enum erat ion e num = appS essio ns.k eys() ;
Ser verSe ssio n(Str ing i d) {
this .id = id;
}
}
whil e (e num.h asMor eElem ents( )) {
Obje ct ke y = e num.n extEl emen t();
Appl icati onSes sion appSe ssio n =
(Appl icati onSes sion) appS essio ns.ge t(key );
appS essio n.inv alida te();
}
thro w new Ille galAr gumen tExc eptio n(msg );
}
pub lic l ong getCr eatio nTime () {
retu rn c reati onTim e;
}
remo veVa lue(n ame); // remov e an y exi sting bind ing
valu es.p ut(na me, v alue) ;
}
pub lic l ong getLa stAcc essed Time( ) {
retu rn l astAc cesse d;
pub lic O bjec t get Value (Stri ng na me) {
if ( name == n ull) {
Stri ng ms g = s m.get Strin g("s erver Sessi on.va lue.i ae") ;
}
pub lic A ppli catio nSess ion g etApp lica tionS essio n(Con text cont ext,
bool ean creat e) {
Appl icat ionSe ssion appS essio n =
(App licat ionSe ssion )appS essi ons.g et(co ntext );
import org.a pach e.tom cat.u til.* ;
import org.a pach e.tom cat.c ore.* ;
import java. io.* ;
import java. net. *;
import java. util .*;
import javax .ser vlet. http. *;
pub lic E nume ratio n get Value Names () {
retu rn v alues .keys ();
}
appS essio n = n ew Ap plica tion Sessi on(id , thi s, co ntex t);
appS essio ns.pu t(con text, app Sessi on);
pub lic v oid remov eValu e(Str ing n ame) {
valu es.r emove (name );
}
pub lic v oid setMa xInac tiveI nterv al(i nt in terva l) {
inac tive Inter val = inte rval;
}
retu rn a ppSes sion;
pub lic i nt g etMax Inact iveIn terva l() {
retu rn i nacti veInt erval ;
}
}
voi d rem oveA pplic ation Sessi on(Co ntex t con text) {
appS essi ons.r emove (cont ext);
}
// XXX
// sync' d fo r saf ty -- no o ther thre ad sh ould be ge tting som ethin g
// from this whil e we are r eapin g. T his i sn't the m ost o ptim al
// solut ion for t his, but w e'll dete rmine some thing else lat er.
/**
* Calle d by cont ext w hen r eques t co mes i n so that acces ses and
* inact ivit ies c an be deal t wit h ac cordi ngly.
*/
/**
* Retur n th e las t tim e the clie nt s ent a requ est
associa ted w ith this
* sessi on, as th e num ber o f mil lise conds sinc e mid night ,
January 1, 1 970
* GMT. Act ions that your appli cati on ta kes, such as
getting or s etti ng
* a val ue a ssoci ated with the s essi on, d o not affe ct th e
access time.
*/
pub lic l ong getLa stAcc essed Time( ) {
pub lic v oid remov eSess ions( Conte xt c ontex t) {
Enum erat ion e num = sess ions. keys ();
whil e (e num.h asMor eElem ents( )) {
Obje ct ke y = e num.n extEl emen t();
Serv erSes sion sessi on = (Ser verSe ssion )sess ions. get( key);
Appl icati onSes sion appSe ssio n =
sessi on.ge tAppl icati onSe ssion (cont ext, false );
}
pri vate Hash table sess ions = new Has htabl e();
pri vate Reap er re aper;
if ( appSe ssion != n ull) {
appSe ssion .inva lidat e();
}
pri vate Serv erSes sionM anage r() {
reap er = Reap er.ge tReap er();
reap er.s etSer verSe ssion Manag er(t his);
reap er.s tart( );
}
this .las tAcce ssedT ime = time ;
/**
* Used by c ontex t to confi gure the sessi on ma nager 's in acti vity timeo ut.
*
* The S essi onMan ager may h ave s ome defau lt se ssion time out , the
* Conte xt o n the othe r han d has it' s tim eout set b y the dep loyme nt
* descr ipto r (we b.xml ). Th is me thod lets the Conte xt co nfor gure the
* sessi on m anage r acc ordin g to this valu e.
*
* @para m mi nutes The sessi on in acti vity timeo ut in minu tes.
*/
pub lic v oid setSe ssion TimeO ut(in t mi nutes ) {
if(- 1 != minu tes) {
// T he ma nager work s wit h se conds ...
inac tiveI nterv al = (minu tes * 60) ;
}
}
pub lic v oid acces sed( Conte xt ct x, R eques t req , Str ing i d ) {
Appl icat ionSe ssion apS= (Appl icat ionSe ssion )find Sessi on( ctx, id);
if( apS= =null ) ret urn;
Serv erSe ssion serv S=apS .getS erve rSess ion() ;
serv S.ac cesse d();
apS. acce ssed( );
// c ache it - no n eed t o com pute it a gain
req. setS essio n( ap S );
}
pub lic H ttpS essio n cre ateSe ssion (Con text ctx) {
Stri ng s essio nId = Sess ionId Gene rator .gene rateI d();
Serv erSe ssion sess ion = new Serv erSes sion( sessi onId) ;
sess ions .put( sessi onId, sess ion) ;
retu rn ( this. lastA ccess edTim e);
}
}
}
/**
* Updat e th e acc essed time info rmat ion f or th is se ssion .
This me thod
* shoul d be call ed by the conte xt w hen a requ est c omes in
for a p artic ular
* sessi on, even if th e app licat ion does not r efere nce i t.
*/
pub lic v oid acces s() {
this .las tAcce ssedT ime = this .thi sAcce ssedT ime;
this .thi sAcce ssedT ime = Syst em.c urren tTime Milli s();
this .isN ew=fa lse;
}
}
lastAc cesse dTim e = 0 L;
lastAc cesse dTim e = ( (Long ) str eam.r eadO bject ()).l ongVa lue() ;
maxI nact iveIn terva l = ( (Inte ger)
stream. readO bjec t()). intVa lue() ;
isNe w = ((Boo lean) stre am.re adOb ject( )).bo olean Value ();
if(- 1 != inac tiveI nterv al) {
sess ion. setMa xInac tiveI nterv al(i nacti veInt erval );
}
retu rn s essio n.get Appli catio nSes sion( ctx, true );
}
pub lic H ttpS essio n fin dSess ion(C onte xt ct x, St ring id) {
Serv erSe ssion sSes sion= (Serv erSe ssion )sess ions. get(i d);
if(s Sess ion== null) retu rn nu ll;
retu rn s Sessi on.ge tAppl icati onSe ssion (ctx, fals e);
}
syn chron ized void reap () {
Enum erat ion e num = appS essio ns.k eys() ;
voi d acc esse d() {
// s et l ast a ccess ed to this Acce ssTim e as it wi ll be lef t ove r
// f rom the p revio us ac cess
whil e (e num.h asMor eElem ents( )) {
Obje ct ke y = e num.n extEl emen t();
Appl icati onSes sion appSe ssio n =
(Appl icati onSes sion) appS essio ns.ge t(key );
last Acce ssed = thi sAcce ssTim e;
this Acce ssTim e = S ystem .curr entT imeMi llis( );
appS essio n.val idate ();
}
}
}
}
voi d val idat e()
sess ion. inval idate ();
sess ions .remo ve(id );
sta tic {
mana ger = new Serv erSes sionM anag er();
thro w new Ille galAr gumen tExc eptio n(msg );
// X XX
// s ync t o ens ure v alid?
ssm.r emove Sessi on(th is);
}
}
}
privat e lon g la stAcc essed Time = cre atio nTime ;
syn chron ized void remo veSes sion( Serv erSes sion sessi on) {
Stri ng i d = s essio n.get Id();
}
retu rn v alues .get( name) ;
// X XX
// m ake sure that we ha ven't gon e ove r the end of ou r
// i nact ive i nterv al -- if s o, i nvali date and c reate
// a new appS essio n
Serve rSess ionMa nager ssm =
S erver Sessi onMan ager .getM anage r();
sess ion.r eap() ;
sess ion.v alida te();
}
}
pro tecte d in t ina ctive Inter val = -1;
}
}
if ( thisI nterv al > inact iveI nterv al) {
inval idate ();
whil e (e num.h asMor eElem ents( )) {
Obje ct ke y = e num.n extEl emen t();
Serv erSes sion sessi on = (Ser verSe ssion )sess ions. get( key);
}
Modeling of generators
Generating generators
Provably correct generators
Embeddable generators
if (ina ctive Inte rval != -1 ) {
int thisI nterv al =
(int) (Syst em.cu rrent Time Milli s() lastAcc essed ) / 1000;
syn chron ized void reap () {
Enum erat ion e num = sess ions. keys ();
pri vate Stri ngMan ager sm =
Stri ngMa nager .getM anage r("or g.ap ache. tomca t.ses sion" );
pri vate stat ic Se rverS essio nMana ger manag er; / / = n ew Se rver Sessi onMan ager( );
}
if ( appS essio n == null && cr eate ) {
// XXX
// sync' d fo r saf ty -- no o ther thre ad sh ould be ge tting som ethin g
// from this whil e we are r eapin g. T his i sn't the m ost o ptim al
// solut ion for t his, but w e'll dete rmine some thing else lat er.
/**
*
* @aut hor J ames Dunc an Da vidso n [du ncan @eng. sun.c om]
* @aut hor J ason Hunt er [j ch@en g.sun .com ]
* @aut hor J ames Todd [gon zo@en g.sun .com ]
*/
pub lic s tati c Ser verSe ssion Manag er g etMan ager( ) {
retu rn m anage r;
pub lic v oid putVa lue(S tring name , Ob ject value ) {
if ( name == n ull) {
Stri ng ms g = s m.get Strin g("s erver Sessi on.va lue.i ae") ;
pub lic S trin g get Id() {
retu rn i d;
}
•
•
•
•
ServerSessionManager
package org. apac he.to mcat. sessi on;
public class Ser verSe ssion Manag er im plem ents Sessi onMan ager {
}
Model-Driven Generator
Technology
Matlab
Matlab
Config.
Code-Gen.
Code-Gen.
Generator
Configuration
Specification
Code
Analysis Tool
Douglas
Schmidt
Technology Evolution
Programming Languages
& Platforms
Model-Driven Development (MDD)
Model
Level of Abstraction
Generated
Model
Code
Platform
• State chart
• Data & process flow
Large
Semantic
Gap
Operating
Systems
Hardware
• Petri Nets
C/Fortran
Assembly
Machine code
Douglas
Schmidt
Technology Evolution
Programming Languages
& Platforms
•New languages & platforms have
raised abstraction level significantly
•“Horizontal” platform reuse
alleviates the need to redevelop
common services
Level of Abstraction
Model
Application Code
Generated
ApplicationCode
Code
Framework
Domain Specific
Pattern
Framework
Language
Platform
Platform
Frameworks
•There are two problems, however:
Components
Frameworks
C++/Java
Class Libraries
C/Fortran
Operating
Systems
Assembly
Machine code
Hardware
•Platform complexity evolved faster
than 3rd-generation languages
•Much application/platform code still
(unnecessarily) written manually
•Particularly for D&C aspects
Douglas
Schmidt
Technology Evolution
Programming Languages
& Platforms
Model-Driven Development (MDD)
Model
Level of Abstraction
Generated Code
Application
Code
Framework
Domain Specific
Pattern
Framework
Language
Platform
Platform
Frameworks
Manual
translation
Saturation!!!!
Components
Frameworks
C++/Java
Class Libraries
C/Fortran
Operating
Systems
Assembly
Machine code
Hardware
Semi-automated
Domain-specific
modeling languages
• ESML
• PICML
• Mathematic
• Excel
• Metamodels
Domain-independent
modeling languages
• State Charts
• Interaction Diagrams
• Activity Diagrams
• OMG is evaluating MDD via MIC PSIG
• www.omg.org/news/meetings/
tc/agendas/mic.htm
Douglas
Schmidt
Technology Evolution
Programming Languages
& Platforms
Model
Level of Abstraction
Generated Code
Application
Code
Platform
Platform
Frameworks
Saturation!!!!
Model-Driven Development (MDD)
Needs
Automation
Needs
Automation
Domain-specific
modeling languages
• ESML
• PICML
• Mathematic
• Excel
• Metamodels
Domain-independent
modeling languages
• State Charts
• Interaction Diagrams
• Activity Diagrams
Components
Frameworks
Needs Automation
C++/Java
Class Libraries
C/Fortran
Operating
Research is needed to automate
Systems
Assembly
DSMLs & model translators
Machine code
Hardware
Douglas
Schmidt
Generic Modeling Environment (GME)
“Write Code That Writes Code That Writes Code!”
GME Architecture
Application
Developers
(Modelers)
Decorator
Decorator
COM GME Editor COM
Constraint
Browser
Manager
Add-On(s)
Translator(s)
COM
GModel
XML
GMeta
XML
MDD Tool
Developers
(Metamodelers)
CORE
XML
DB #1
Metamodel
UML / OCL
Paradigm Definition
ODBC
… XML … DB #n
Storage Options
Supports “correct-by-construction” of DRE systems
Douglas
Schmidt
GME is open-source: www.isis.vanderbilt.edu/Projects/gme/default.htm
MDD Application Development with GME
•Application
developers use
modeling environments
created w/MetaGME to
build applications
–Capture elements &
dependencies
visually
Douglas
Schmidt
MDD Application Development with GME
•Application
developers use
modeling environments
created w/MetaGME to
build applications
–Capture elements &
dependencies
visually
–Model interpreter
produces something
useful from the
models
•e.g., code,
simulations,
deployment
descriptions &
configurations
<connection>
<name>compressionQosPredictor_qosLevels</name>
<internalEndpoint>
<portName>qosLevels</portName>
<instance xmi:idref="CompressionQosPredictor_F3C2CBE0-B2CE-46CC-B446F64D91B44E56"/>
</internalEndpoint>
<internalEndpoint>
<portName>compressionQosPredictor</portName>
<instance xmi:idref="LocalResourceManagerComponent_7EF8B77A-F5EA4D1A-942E-13AE7CFED30A"/>
</internalEndpoint>
</connection>
<connection>
<name>scalingQosPredictor_qosLevels</name>
<internalEndpoint>
<portName>qosLevels</portName>
<instance xmi:idref="ScaleQosPredictor_F3024A4F-F6E8-4B9A-BD56A2E802C33E32"/>
</internalEndpoint>
<internalEndpoint>
<portName>scalingQosPredictor</portName>
<instance xmi:idref="LocalResourceManagerComponent_7EF8B77A-F5EA4D1A-942E-13AE7CFED30A"/>
</internalEndpoint>
</connection>
Douglas
Schmidt
MDD Tool Development in GME
•Tool developers use
MetaGME to develop a
domain-specific
graphical modeling
environment
–Define syntax &
visualization of the
environment via
metamodeling
Douglas
Schmidt
MDD Tool Development in GME
•Tool developers use
MetaGME to develop a
domain-specific
graphical modeling
environment
–Define syntax &
visualization of the
environment via
metamodeling
–Define static
semantics via Object
Constraint Language
(OCL)
Douglas
Schmidt
MDD Tool Development in GME
•Tool developers use
MetaGME to develop a
domain-specific
graphical modeling
environment
–Define syntax &
visualization of the
environment via
metamodeling
–Define static
semantics via Object
Constraint Language
(OCL)
–Dynamic semantics
implemented via
model interpreters
Douglas
Schmidt
Component Deployment & Configuration
SW
Creator
1
A1
SW
Creator2
A2
Implementations
Deployment
requirements
Goals of D&C Phase
– Promote component reuse
– Build complex applications by assembling
existing components
– Automate common services configuration
– Declaratively inject QoS policies into
applications
– Dynamically deploy components to target
heterogeneous domains
– Optimize systems based on component
configuration & deployment settings
Infrastructure
Interfaces
Shipping
SW Deployer
Deployment
Tools (generic)
Deployment
Interfaces
Deployment
Infrastructure
Douglas
OMG Deployment & Configuration (D&C) specification (ptc/05-01-07)
Schmidt
Component Deployment & Configuration
SW
Creator
1
A1
SW
Creator2
A2
Implementations
Deployment
requirements
OMG D & C Spec
(PIM & PSMs)
XMLSchema
Generation
IDL
Generation
D&C
Profile
Infrastructure
Interfaces
Interchange
Formats
Shipping
SW Deployer
Deployment
Tools (generic)
Deployment
Interfaces
Deployment
Infrastructure
Douglas
OMG Deployment & Configuration (D&C) specification (ptc/05-01-07)
Schmidt
MDD Example: Deployment & Configuration Aspects
Specification & Implementation
–Defining, partitioning, & implementing app functionality as
standalone components
Packaging
–Bundling a suite of software binary modules & metadata
representing app components
Installation
–Populating a repository with packages required by app
Configuration
–Configuring packages with appropriate parameters to satisfy
functional & systemic requirements of an application without
constraining to physical resources
Planning
–Making deployment decisions to identify nodes in target
environment where packages will be deployed
Preparation
–Moving binaries to identified entities of target environment
Launching
–Triggering installed binaries & bringing app to ready state
QoS Assurance & Adaptation
–Runtime (re)configuration & resource management to
maintain end-to-end QoS
OMG Deployment &
Configuration (D&C)
specification (ptc/05-01-07)
Douglas
Schmidt
Challenge 1: The Packaging Aspect
TIMER
20Hz
GPS
AIRFRAME
NAV DISP
• Application components are bundled
together into assemblies
• Several different assemblies tailored
towards delivering different end-toend QoS and/or using different
algorithms can be part of the package
–e.g., large-scale DRE systems
require 100s-1,000s of components
• Packages describing the components
& assemblies can be scripted via
XML descriptors
Douglas
Schmidt
Packaging Aspect Problems
Ad hoc techniques for ensuring component
syntactic & semantic compatibility
Main
Component
Executor
Inherent Complexities
Main
Component
Executor
Component
Specific
Context
CCMContext
CCMContext
Executors
Executors
Executors
Executors
Executors
Executors
Executors
Executors
CCMContext
CCMContext
EnterpriseComponent
EnterpriseComponent
Servant
Container
Component
Specific
Context
Servant
POA
Ad hoc means to
determine pub/sub
support
RT Event
Channel
Container
POA
Distribution &
deployment done in
ad hoc manner
Douglas
Schmidt
Packaging Aspect Problems
Accidental Complexities
Existing practices
involve handcrafting
XML descriptors
<!– Associate components with impls -->
<assemblyImpl>
<instance xmi:id="RateGen">
<name>RateGen Subcomponent</name>
<package href="RateGen.cpd"/>
XML file in
excess of 3,000 </instance>
lines, even for <instance xmi:id="GPS">
medium sized
<name>GPS Subcomponent</name>
scenarios
<package href="GPS.cpd"/>
</instance>
<instance xmi:id="NavDisplay">
<name>NavDisplay Subcomponent</name>
<package href="NavDisplay.cpd"/>
Modifications to the
assemblies requires
</instance>
modifying XML file
</assemblyImpl>
Douglas
Schmidt
MDD Solution for Packaging Aspect
Approach:
• Develop a Platform-Independent Component Modeling Language
(PICML) to address inherent & accidental complexities of packaging
– Capture dependencies visually
– Define semantic constraints using
Object Constraint Language (OCL)
– Generate domain-specific
metadata from models
– Correct-by-construction
• PICML is developed using Generic
Modeling Environment (GME)
www.cs.wustl.edu/~schmidt/PDF/RTAS-PICML.pdf
Douglas
Schmidt
Example Metadata Generated by PICML
• Component Interface Descriptor (.ccd)
• Describes the interface, ports, properties of a single
component
• Implementation Artifact Descriptor (.iad)
• Describes the implementation artifacts (e.g., DLLs, OS,
etc.) of one component
• Component Package Descriptor (.cpd)
• Describes multiple alternative implementations of a
single component
• Package Configuration Descriptor (.pcd)
• Describes a configuration of a component package
• Top-level Package Descriptor (package.tpd)
• Describes the top-level component package in a
package (.cpk)
• Component Implementation Descriptor (.cid)
• Describes a specific implementation of a component
interface
• Implementation can be either monolithic- or assemblybased
• Contains sub-component instantiations in case of
assembly based implementations
• Contains inter-connection information between
components
• Component Packages (.cpk)
• A component package can contain a single component
• A component package can also contain an assembly
Component
Packaging
Component &
Home Properties
Implementation
Artifact
Descriptors
(.iad)
Component
DLLs
Packaging
Tools
Component
Package
Descriptors
(.cpd)
Component
Interface
Descriptors
(.ccd)
Assembly
Tools
Component
Implementation
Descriptor
(*.cid)
Component
Packages
(*.cpk)
Component &
Home Properties
Application
Assembly
Based on OMG (D&C)
specification (ptc/03-06-03)
Douglas
Schmidt
Example Output from PICML Model
A Component Implementation Descriptor (*.cid) file
• Describes a specific implementation
of a component interface
• Describes component
interconnections
<monolithicImpl> [...]
<deployRequirement>
<name>GPS</name>
<resourceType>GPS Device</resourceType>
<property><name>vendor</name>
<value>
<type> <kind>tk_string</kind> </type>
<value> <string>My GPS Vendor</string> </value>
</value>
</property>
</deployRequirement>
[... Requires Windows OS ...]
</monolithicImpl>
<connection> <name>GPS Trigger</name>
<internalEndpoint> <portName>Pulse</portName>
<instance href="#RateGen"/>
</internalEndpoint>
<internalEndpoint> <portName>Refresh</portName>
<instance href="#GPS"/>
</internalEndpoint>
</connection>
<connection> <name>NavDisplay Trigger</name>
<internalEndpoint> <portName>Ready</portName>
<instance href="#GPS"/>
</internalEndpoint>
<internalEndpoint> <portName>Refresh</portName>
<instance href="#NavDisplay"/>
</internalEndpoint>
</connection>
Douglas
Schmidt
Challenge 2: The Configuration Aspect
Component middleware is characterized by a large configuration
space that maps known variations in the application requirements
space to known variations in the middleware solution space
Hook for
marshaling
strategy
Hook for the event
demuxing strategy
Hook for the
connection
management
strategy
Hook for
the request
demuxing
strategy
Hook for the
concurrency
strategy
Hook for the
underlying
transport
strategy
Douglas
Schmidt
Configuration Aspect Problems
Middleware developers
– Documentation & capability
synchronization
– Semantic constraints & QoS
evaluation of specific configurations
Application developers
– Must understand middleware
constraints & semantics
• Increases accidental complexity
– Different middleware uses different
configuration mechanisms
XML Configuration
Files
XML Property
Files
CIAO/CCM provides
~500 configuration
options
Douglas
Schmidt
MDD Solutions for Configuration Aspect
Approach:
•Develop an Options Configuration Modeling Language (OCML)
w/GME to ensure semantic consistency of option configurations
•OCML is used by
–Middleware developers to
design the configuration model
–Application developers to
configure the middleware for a
specific application
•OCML metamodel is platformindependent
•OCML models are platformspecific
www.cs.wustl.edu/~schmidt/PDF/RTAS-process.pdf
Douglas
Schmidt
Applying OCML to CIAO+TAO
•Middleware developers specify
•Configuration space
•Constraints
•OCML generates config model
Douglas
Schmidt
Applying OCML to CIAO+TAO
•Middleware developers specify
•Configuration space
•Constraints
•OCML generates config model
•Application developers provide
a model of desired options &
their values, e.g.,
•Network resources
•Concurrency & connection
management strategies
Douglas
Schmidt
Applying OCML to CIAO+TAO
•Middleware developers specify
•Configuration space
•Constraints
•OCML generates config model
•Application developers provide
a model of desired options &
their values, e.g.,
•Network resources
•Concurrency & connection
management strategies
•OCML constraint checker flags
incompatible options & then
•Synthesizes XML descriptors
for middleware configuration
•Generates documentation
for middleware configuration
•Validates the configurations
Douglas
Schmidt
Challenge 3: Planning Aspect
Component integrators must make appropriate deployment decisions,
identifying nodes in target environment where packages will be deployed
Select the
appropriat
e package
to deploy
on
selected
target
Select appropriate
target platform to
deploy packages
Determine current
resource allocations
on target platforms
Douglas
Schmidt
Planning Aspect Problems
How to ensure a particular deployment configuration meets QoS requirements
How do you correlate QoS
requirements of packages
to resource needs
How do you
determine
current resource
allocations?
How do you ensure that
the selected targets will
deliver required QoS
Douglas
Schmidt
MDD Solution for Planning Aspect
Approach
• Develop Component Workload Emulator (CoWorkEr) Utilization Test
Suite (CUTS) w/GME to allow architects to detect, diagnose, & resolve
system QoS problems before system integration phase
• CoWorkEr is an component
assembly of monolithic
components responsible for
generating respective workload
• CoWorkEr ports can be connected
to define operational strings
• Workload Modeling Language
(WML) is used to define CoWorkEr
behavior
• WML is translated to XML
metadata descriptors that
configure CoWorkErs
www.cs.wustl.edu/~schmidt/PDF/CUTS.pdf
Douglas
Schmidt
MDD Solution for Planning Aspect
CUTS Workflow for Architects
1. Compose scenarios to exercise
critical system paths/layers
Model
Experiment
Experimenter
2. Associate QoS properties with
scenarios (e.g., latency, jitter, or
thruput) & assign properties to
components specific to
paths/layers
3. Configure workload generators
to run experiments, generate
path-/layer-specific deployment
plans, & measure QoS along
critical paths/layers
4. Feedback results into models
to verify if deployment plan &
configurations meet QoS
requirements
Associate
QoS
Characteristics
1
2
Component Interaction
CUTS
4
3
IDL
Feedback
Test bed
Synthesize
&
Execute
Script
files
Deployment
.cpp
Plan
Douglas
Schmidt
Integrating MDD & Middleware for Planning
Deployment Plan
CoWorkEr
models system
components,
requirements,
& constraints
XML to
IDL
R-F
Plan
Analyzers
LISP to
IDL
R-F
Plan
Managers
F-R
F-R
2D Bin
packing
path
Priority
Sched.
path
2D Bin
packing
Priority
Sched.
R-F
Applications that fetch
XML or LISP and call
appropriate plug-ins
Output
Adapters
F-R
Deployment Manager
To
DAnCE
To
OpenCCM
Resource Allocation &
Control Engine (RACE)
middleware provides
deployment planners
• Deployment And
Configuration
Engine (DAnCE)
maps plans to
computing nodes
• RACE controls
reallocations
Gigabit Ethernet
Douglas
Schmidt
Example: ACE+TAO+CIAO Build Scoreboard
•Nerve center of quality control
•www.dre.vanderbilt.edu/
scoreboard
•Updated by automatic builds
•40+ builds on ~8 OS platforms
•Many configurations tested
•Participating machines located at
•Washington University
•UC Irvine
•BBN Technologies
•Remedy, Netherlands
•Object Sciences Corps (OSC)
•Hunleth.com
•Riverace Corp
•ISIS/Vanderbilt
•PrismTechnologies
•Object Computing Inc. (OCI)
•LMCO ATL
•Monitored by the “build-czar” &
by all core developers
Douglas
Schmidt
Ingredients for Success with Systematic Reuse
Key Technologies
Experienced Senior Architects
Standard
Middleware,
Frameworks, &
Components
• Responsible for communicating
completeness, correctness, &
consistency of all parts of the
software architecture to the
stakeholders
Solid Key Developers
Patterns &
Pattern
Languages
• Design responsibility
(maintenance, evolution) for a
specific architectural topic
Enlightened Managers
Model-driven
Software
Development
• Must be willing to defend the
sacrifice of some short-term
investment for long-term payoff
Business Drivers
• i.e., need a “succeed or die”
business case
Douglas
It’s crucial to have an effective process for growing architects & key developers
Schmidt
Traits of Dysfunctional Software Organizations
Process Traits
• Death through quality
• “Process bureaucracy”
• Analysis paralysis
• “Zero-lines of code seduction”
• Infrastructure churn
• e. g., programming to low-level APIs
Organizational Traits
• Disrespect for quality developers
• “Coders vs. developers”
• Top-heavy bureaucracy
Sociological Traits
• The “Not Invented Here” syndrome
• Modern method madness
www.cs.wustl.edu/~schmidt/editorials.html
Douglas
Schmidt
Traits of Highly Successful Software Organizations
Strong leadership in business &
technology
• e.g., understand the role of software
technology
• Don’t wait for “silver bullets”
Clear architectural vision
• e.g., know when to buy vs. build
• Avoid worship of specific tools &
technologies
Effective use of prototypes & demos
• e.g., reduce risk & get user feedback
Commitment to/from skilled developers
• e.g., know how to motivate software
developers & recognize the value of
thoughtware
Douglas
Schmidt
Concluding Remarks
Take-home Points
• Reuse has failed due to lack of
• Systematic application
• Developer education & training
• Management commitment
• Systematic reuse is achievable,
though not easy
• A good process is necessary, but
not sufficient
• Start by focusing on low-hanging
fruit
False Prophets
• Languages
• Methodologies
• Process
• Middleware & MDD
• Organization-central solutions
• Technology-centric solutions
There is no substitute for thinking & hard work!
www.dre.vanderbilt.edu/~schmidt/
Douglas
Schmidt