1. Topic 2: Balance between formal and informal methods, engineering and artistry, evolution and rebuild Edward A. Lee Professor UC Berkeley Center for Hybrid and embedded software systems ARO Workshop on Software Reliability for FCS May 18-19, 2004 Nashville, TN, USA

2. 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? 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?

3. Lee, UC Berkeley 3 Topic 2: Balance between formal and informal methods, engineering and artistry, evolution and rebuild 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?

4. 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

5. 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?

6. 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.

7. Lee, UC Berkeley 7 A Story: Code Review in the Chess Software Lab

8. Lee, UC Berkeley 8 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.

9. Lee, UC Berkeley 9 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) */ 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.

10. 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 0.2 @Pt.ProposedRating 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.

11. Lee, UC Berkeley 11 What it Feels Like to Use the synchronized Keyword in Java Image “borrowed” from an Iomega advertisement for Y2K software and disk drives, Scientific American, September 1999.

12. 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

13. 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.

14. Lee, UC Berkeley 14 The Need Research is needed in design methods that integrate concurrency and time into their core semantics.

15. Lee, UC Berkeley 15 Topic 2: Balance between formal and informal methods, engineering and artistry, evolution and rebuild 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?

16. 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?

17. Lee, UC Berkeley 17 Is this a Model or a Program?

18. 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

19. Lee, UC Berkeley 19 Progress Many useful technical developments amounted to creation of new platforms. microarchitectures operating systems virtual machines processor cores configurable ISAs

20. Lee, UC Berkeley 20 Desirable Properties From above: modeling expressiveness From below: correctness efficiency

21. Lee, UC Berkeley 21 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

22. Lee, UC Berkeley 22 Better Platforms Platforms with modeling properties that reflect requirements of the application, not accidental properties of the implementation.

23. Lee, UC Berkeley 23 Actor-Oriented Platforms Actor oriented models compose concurrent components according to a model of computation.

24. 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.

25. 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.

26. Lee, UC Berkeley 26 Topic 2: Balance between formal and informal methods, engineering and artistry, evolution and rebuild 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?

27. 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

28. 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

29. 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:

30. 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.

31. 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…

32. 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 …

33. 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

34. Lee, UC Berkeley 34 Topic 2: Balance between formal and informal methods, engineering and artistry, evolution and rebuild 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?

35. Lee, UC Berkeley 35 Bad Visual Notations Abound

36. 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

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

38. 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.