Topic 2: Balance between formal and informal methods, engineering and artistry, evolution and rebuild Edward A. Lee Professor UC Berkeley Center for Hybrid

Topic 2: Balance between formal and informal methods, engineering and artistry, evolution and rebuild

Edward A. LeeProfessorUC Berkeley

Center for Hybrid and embedded software systems

ARO Workshop on Software Reliability for FCS

May 18-19, 2004

Nashville, TN, USA

Lee, UC Berkeley 2


Is the objective of formal methods proof or understanding? proof for certification? proof for identifying overlooked behaviors? does the approach change if the emphasis is different? relationship with testing?

How should models relate to programs? 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? 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? Simulink? Statecharts? UML static structure? UML use case? UML ...?

Are source code annotations acceptable? useful?

Lee, UC Berkeley 3







Lee, UC Berkeley 4

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 5

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 6

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 7A Story: Code Review in the Chess Software LabA Story: Code Review in the Chess Software Lab

Lee, UC Berkeley 8

Code Review in the Chess Software LabA 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 9

Code Review Doesn’t Always WorkAnother 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 [email protected] Green (eal)@Pt.AcceptedRating Green (bart)*/public final class CrossRefList implements Serializable { … protected class CrossRef implements Serializable{ … // NOTE: It is essential that this method not be // synchronized, since it is called by _farContainer(), // which is. Having it synchronized can lead to // deadlock. Fortunately, it is an atomic action, // so it need not be synchronized. private Object _nearContainer() { return _container; }

private synchronized Object _farContainer() { if (_far != null) return _far._nearContainer(); else return null; } … }}

Code that had been in use for four years, central to Ptolemy II, with an extensive test suite, design reviewed to yellow, then code reviewed to green in 2000, causes a deadlock during a demo on April 26, 2004.

Lee, UC Berkeley 10

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 [email protected] Green (eal)@Pt.AcceptedRating Green (bart)*/public final class CrossRefList implements Serializable { … protected class CrossRef implements Serializable{ … private synchronized void _dissociate() { _unlink(); // Remove this. // NOTE: Deadlock risk here! If _far is waiting // on a lock to this CrossRef, then we will get // deadlock. However, this will only happen if // we have two threads simultaneously modifying a // 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 } }

Safety of this code depends on policies maintained by entirely unconnected classes. The language and synchronization mechanisms provide no way to talk about these systemwide properties.

Lee, UC Berkeley 11

What it Feels Like to Use the synchronized Keyword in Java

Imag

e “

borr

ow

ed

” fr

om

an

Iom

eg

a a

dvert

isem

en

t fo

r Y2

K

soft

ware

an

d d

isk

dri

ves,

Sci

en

tifi

c A

meri

can

, S

ep

tem

ber

19

99

.

Lee, UC Berkeley 12

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 13

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 14

The Need

Research is needed in design methods that integrate concurrency and time into their core semantics.

Lee, UC Berkeley 15







Lee, UC Berkeley 16

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 17

Is this a Model or a Program?

Lee, UC Berkeley 18

Platforms

A platform is a set of designs.

Relations between platforms represent design processes.

A “language” is a specification of a platform.

software design gap

Lee, UC Berkeley 19

Progress

Many useful technical developments amounted to creation of new platforms.

microarchitectures operating systems virtual machines processor cores configurable ISAs

Lee, UC Berkeley 20

Desirable Properties

From above: modeling expressiveness

From below: correctness efficiency

Lee, UC Berkeley 21

RecentActionGiving 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 22

BetterPlatforms

Platforms with modeling properties that reflect requirements of the application, not accidental properties of the implementation.

Lee, UC Berkeley 23

Actor-Oriented Platforms

Actor oriented models compose concurrent components according to a model of computation.

Lee, UC Berkeley 24

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 25

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 26







Lee, UC Berkeley 27

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 28

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 29

Simulink is an Instance of a Family of Actor-Oriented “Languages”

Actor orientation:

actor name

data (state)

ports

Input data

parameters

Output data

What flows through an object is

streams of data

class name

data

methods

call return

What flows through an object is

sequential control

Object orientation:

Lee, UC Berkeley 30

Modern Examples of Actor-Oriented “Languages”

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) …

These differ hugely in syntax and semantics, but all share the idea of concurrent communicating components.

Lee, UC Berkeley 31

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 actor-oriented design to be done wrong…

Lee, UC Berkeley 32

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 33

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 34







Lee, UC Berkeley 35

Bad Visual Notations Abound

Lee, UC Berkeley 36

(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 37

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 38

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.

Documents

Topic 2: Balance between formal and informal methods, engineering and artistry, evolution and rebuild Edward A. Lee Professor UC Berkeley Center for Hybrid