Topic 2: Balance between formal
and informal methods,
engineering and artistry,
evolution and rebuild
Edward A. Lee
Professor
UC Berkeley
ARO Workshop on Software
Reliability for FCS
May 18-19, 2004
Nashville, TN, USA
Center for Hybrid and embedded software systems
Topic 2: Balance between formal and informal methods,
engineering and artistry, evolution and rebuild

Is the objective of formal methods proof or understanding?





How should models relate to programs?






declarative? concurrent? constraints?
value of raising the level of abstraction? enabling rebuild?
can we get better formal properties?
acceptance?
Do visual notations help? Which ones help most?



are models the source code or abstractions of the source?
do they represent individual traces or families of behaviors?
Are non-procedural languages viable? Will they help?


proof for certification?
proof for identifying overlooked behaviors?
does the approach change if the emphasis is different?
relationship with testing?
Simulink? Statecharts?
UML static structure? UML use case? UML ...?
Are source code annotations acceptable? useful?
Lee, UC Berkeley 2
Topic 2: Balance between formal and informal methods,
engineering and artistry, evolution and rebuild

Is the objective of formal methods proof or understanding?





How should models relate to programs?






declarative? concurrent? constraints?
value of raising the level of abstraction? enabling rebuild?
can we get better formal properties?
acceptance?
Do visual notations help? Which ones help most?



are models the source code or abstractions of the source?
do they represent individual traces or families of behaviors?
Are non-procedural languages viable? Will they help?


proof for certification?
proof for identifying overlooked behaviors?
does the approach change if the emphasis is different?
relationship with testing?
Simulink? Statecharts?
UML static structure? UML use case? UML ...?
Are source code annotations acceptable? useful?
Lee, UC Berkeley 3
Some Objectives of Formal Methods






semantic grounding for languages
precise specification
proof of properties
proof of correctness
promoting understanding
reducing the need for testing
Lee, UC Berkeley 4
A Success Story: Type Systems






semantic grounding for languages
precise specification
proof of properties
proof of correctness
promoting understanding
reducing the need for testing
But type systems only address certain properties of the static
structure of programs. Can the concept be extended to other
properties, including dynamic (behavioral) ones?
Lee, UC Berkeley 5
Desperately in Need of a Success Story:
Concurrency and Synchronization

Prevailing methods date to the 1960’s [Dijstra]




threads
semaphores
mutexes
Tauntingly Simple Rules:


Always grab mutex locks in the same order [Lea]
Very hard to apply
• in today’s OO languages, it is not part of the interface
definition of a method what locks it grabs.
Lee, UC Berkeley 6
A Story: Code Review in the Chess Software
Lab
Lee, UC Berkeley 7
Code Review in the Chess Software Lab
A Typical Story

Code review discovers that a method needs to be synchronized to
ensure that multiple threads do not reverse each other’s actions.
No problems had been detected in 4 years of using the code.
Three days after making the change, users started reporting deadlocks
caused by the new mutex.
Analysis of the deadlock takes weeks, and a correction is difficult.

But code review successfully identified the flaw.



Lee, UC Berkeley 8
Code Review Doesn’t Always Work
Another Typical Story
/**
CrossRefList is a list that maintains pointers to other CrossRefLists.
…
@author Geroncio Galicia, Contributor: Edward A. Lee
@version $Id: CrossRefList.java,v 1.78 2004/04/29 14:50:00 eal Exp $
@since Ptolemy II 0.2
@Pt.ProposedRating Green (eal)
@Pt.AcceptedRating Green (bart)
Code that had been in
*/
public final class CrossRefList implements Serializable {
use for four years,
…
central to Ptolemy II,
protected class CrossRef implements Serializable{
with an extensive test
…
// NOTE: It is essential that this method not be
suite, design reviewed to
// synchronized, since it is called by _farContainer(),
yellow, then code
// which is. Having it synchronized can lead to
reviewed to green in
// deadlock. Fortunately, it is an atomic action,
// so it need not be synchronized.
2000, causes a deadlock
private Object _nearContainer() {
during a demo on April
return _container;
26, 2004.
}
private synchronized Object _farContainer() {
if (_far != null) return _far._nearContainer();
else return null;
}
…
}
}
Lee, UC Berkeley 9
And Doubts Remain
/**
CrossRefList is a list that maintains pointers to other CrossRefLists.
…
@author Geroncio Galicia, Contributor: Edward A. Lee
@version $Id: CrossRefList.java,v 1.78 2004/04/29 14:50:00 eal Exp $
@since Ptolemy II 0.2
@Pt.ProposedRating Green (eal)
@Pt.AcceptedRating Green (bart)
Safety of this code
*/
depends on policies
public final class CrossRefList implements Serializable {
…
maintained by entirely
protected class CrossRef implements Serializable{
unconnected classes.
…
The language and
private synchronized void _dissociate() {
_unlink(); // Remove this.
synchronization
// NOTE: Deadlock risk here! If _far is waiting
mechanisms provide no
// on a lock to this CrossRef, then we will get
way to talk about these
// deadlock. However, this will only happen if
// we have two threads simultaneously modifying a
systemwide properties.
// model. At the moment (4/29/04), we have no
// mechanism for doing that without first
// acquiring write permission the workspace().
// Two threads cannot simultaneously hold that
// write access.
if (_far != null) _far._unlink(); // Remove far
}
}
Lee, UC Berkeley 10
Image “borrowed” from an Iomega advertisement for Y2K
software and disk drives, Scientific American, September 1999.
What it Feels Like to Use the
synchronized Keyword in Java
Lee, UC Berkeley 11
A Stake in the Ground
Nontrivial concurrent programs based on
processes, threads, semaphores, and mutexes
are incomprehensible to humans.

No amount of process is going to change this.
• the human brain doesn’t work this way.

Formal methods may help
• scalability?
• understandability?

Better concurrency abstractions will help more
Lee, UC Berkeley 12
Another Desperately Needed Success
Story: Real Time





Programming languages have no
time in their semantics.
Temporal properties are viewed as
“non-functional”
RTOS methods are a retrofit
(priorities, deadlines).
QoS overlaid on untimed methods is
also a retrofit.
Priorities are widely misused in
practice.
Lee, UC Berkeley 13
The Need
Research is needed in design methods that
integrate concurrency and time into their core
semantics.
Lee, UC Berkeley 14
Topic 2: Balance between formal and informal methods,
engineering and artistry, evolution and rebuild

Is the objective of formal methods proof or understanding?





How should models relate to programs?






declarative? concurrent? constraints?
value of raising the level of abstraction? enabling rebuild?
can we get better formal properties?
acceptance?
Do visual notations help? Which ones help most?



are models the source code or abstractions of the source?
do they represent individual traces or families of behaviors?
Are non-procedural languages viable? Will they help?


proof for certification?
proof for identifying overlooked behaviors?
does the approach change if the emphasis is different?
relationship with testing?
Simulink? Statecharts?
UML static structure? UML use case? UML ...?
Are source code annotations acceptable? useful?
Lee, UC Berkeley 15
Models vs. Programs




What is a “program”?
What is a “model”?
When should they be distinct?
When should they be the same?
Lee, UC Berkeley 16
Is this a Model or a Program?
Lee, UC Berkeley 17
Platforms
software
design gap
A platform is a set of
designs.
Relations between
platforms represent
design processes.
A “language” is a
specification of a
platform.
Lee, UC Berkeley 18
Progress
Many useful technical
developments
amounted to creation of
new platforms.
microarchitectures
 operating systems
 virtual machines
 processor cores
 configurable ISAs

Lee, UC Berkeley 19
Desirable
Properties
From above:
 modeling
 expressiveness
From below:
 correctness
 efficiency
Lee, UC Berkeley 20
Recent
Action
Giving the red platforms
useful modeling
properties:
 QoS
 Verification
 UML
 MDA
Getting from the red to
the blue:
 certified compilers
 synthesis of tools
Lee, UC Berkeley 21
Better
Platforms
Platforms with
modeling properties
that reflect
requirements of the
application, not
accidental
properties of the
implementation.
Lee, UC Berkeley 22
Actor-Oriented
Platforms
Actor oriented
models compose
concurrent
components
according to a
model of
computation.
Lee, UC Berkeley 23
More Stakes in the Ground

Models and programs need not and must not
be separate artifacts.


“programs” must be given in “languages” that
reflect properties of interest to the application
(e.g. time).
Discussion of QoS without “language”
semantics is not enough.


e.g. specifying temporal properties in
languages with no temporal semantics.
elevate from “API’s” to new platforms.
Lee, UC Berkeley 24
Models = Programs
Which raises new questions:

Is it useful to have multiple models/programs for the
same design?


UML static structure diagram and C++ program
If so, how to maintain coherence and consistency?





Code generators?
Round trip?
Aspect weaving?
Multi-view modeling?
Meta modeling?
Research is needed in the fundamentals of model
transformation and multi-view modeling.
Lee, UC Berkeley 25
Topic 2: Balance between formal and informal methods,
engineering and artistry, evolution and rebuild

Is the objective of formal methods proof or understanding?





How should models relate to programs?






declarative? concurrent? constraints?
value of raising the level of abstraction? enabling rebuild?
can we get better formal properties?
acceptance?
Do visual notations help? Which ones help most?



are models the source code or abstractions of the source?
do they represent individual traces or families of behaviors?
Are non-procedural languages viable? Will they help?


proof for certification?
proof for identifying overlooked behaviors?
does the approach change if the emphasis is different?
relationship with testing?
Simulink? Statecharts?
UML static structure? UML use case? UML ...?
Are source code annotations acceptable? useful?
Lee, UC Berkeley 26
Another Stake in the Ground
Language research is stalled because people think that
new languages must replace the old languages, and
because notations are not “languages” unless you can
edit them in emacs.
Research is needed in languages that complement
existing languages and play in concert with them.



coordination languages
actor-oriented languages
visual notations for higher-level abstractions
Lee, UC Berkeley 27
Suppose this is a Program
Then where are the features of a modern language?
• abstraction mechanisms (is hierarchy enough?)
• classes, subclasses, and inheritance
• interfaces, types, polymorphism
• aspects
Lee, UC Berkeley 28
Simulink is an Instance of a Family of
Actor-Oriented “Languages”
Object orientation:
class name
What flows through
an object is
sequential control
data
methods
call
return
Actor orientation:
actor name
data (state)
parameters
ports
Input data
Output data
What flows through
an object is
streams of data
Lee, UC Berkeley 29
Modern Examples of Actor-Oriented
“Languages”
















These differ
hugely in syntax
and semantics,
but all share the
idea of
concurrent
communicating
components.
Simulink (The MathWorks)
Labview (National Instruments)
Modelica (Linkoping)
OPNET (Opnet Technologies)
Polis & Metropolis (UC Berkeley)
Gabriel, Ptolemy, and Ptolemy II (UC Berkeley)
OCP, open control platform (Boeing)
GME, actor-oriented meta-modeling (Vanderbilt)
SPW, signal processing worksystem (Cadence)
System studio (Synopsys)
ROOM, real-time object-oriented modeling (Rational)
Easy5 (Boeing)
Port-based objects (U of Maryland)
I/O automata (MIT)
VHDL, Verilog, SystemC (Various)
…
Lee, UC Berkeley 30
Actors in 2004: “Capsules” (UML-RT) and
“Composite Structures” (UML-2)

UML-RT borrowed from Selic’s ROOM the notion of
“capsules,” which structurally look like actors.

UML-2 is introducing the notion of “composite structures,”
which also look like actors.

UML capsules and composite structures specify abstract
syntax (and a concrete syntax), but no semantics.

What this says is that there is huge potential for actororiented design to be done wrong…
Lee, UC Berkeley 31
Examples of Models of Computation













Dataflow
Discrete events
Continuous time
Finite state machines
Synchronous reactive
Time driven
Publish and subscribe
Communicating sequential processes
Process networks
Push/Pull
Click
TinyOS
…
Lee, UC Berkeley 32
Yet Another Stake in the Ground
Actor-oriented design has the potential for
impact on the scale that object-oriented has
had, but much more work is needed.
Research is needed in actor-oriented methods



modularity techniques (classes, inheritance,
interfaces, type systems, aspects)
models of computation
visual notations
Lee, UC Berkeley 33
Topic 2: Balance between formal and informal methods,
engineering and artistry, evolution and rebuild

Is the objective of formal methods proof or understanding?





How should models relate to programs?






declarative? concurrent? constraints?
value of raising the level of abstraction? enabling rebuild?
can we get better formal properties?
acceptance?
Do visual notations help? Which ones help most?



are models the source code or abstractions of the source?
do they represent individual traces or families of behaviors?
Are non-procedural languages viable? Will they help?


proof for certification?
proof for identifying overlooked behaviors?
does the approach change if the emphasis is different?
relationship with testing?
Simulink? Statecharts?
UML static structure? UML use case? UML ...?
Are source code annotations acceptable? useful?
Lee, UC Berkeley 34
Bad Visual Notations Abound
Lee, UC Berkeley 35
(Mis)Uses of Visual Notations
Visual notations should be used to express
aspects of design that are not well expressed
by text:


Static structure
Concurrency
They should not be used to replace text:



Flowcharts
State machines
Executable UML
Lee, UC Berkeley 36
Another Stake in the Ground
Visual notations, judiciously used, can help.


Representation of concurrent systems is visually
concurrent.
They encourage hierarchical abstraction
But languages today are weak


Hierarchy is the only abstraction mechanism in
most (no classes, inheritance, interfaces, or
aspects).
Scalability is limited
Lee, UC Berkeley 37
Conclusion



Bad design can be done in any language.
No amount of formal analysis will turn a bad design into
a good design.
Bad designs evolve into worse designs, never into
good designs.
Artistry is the essence of good design.




Languages are the medium of expression.
High quality media are essential for durable art.
Tools (formal and informal) are … well… tools.
High quality tools enable but do not guarantee artistry.
Lee, UC Berkeley 38