Software Development in an Academic
Environment: Lessons learned and not
learned
Christopher Brooks
CHESS Executive Director
With material from:
Edward A. Lee
H. John Reekie
UC Berkeley CS169,
November 1, 2007
Intros
• Who is graduating this semester?
–
–
–
–
Going to industry?
Going to academia?
Don’t know?
Don’t care?
–
–
–
–
Going to industry?
Going to academia?
Don’t know?
Don’t care?
• Who is graduating in 2008?
• Languages
– Java?
– C#
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
2
Christopher Brooks
• I’m a release engineer, training electrical
engineers in the art of software
engineering.
• I’ve worked with Professor Edward A. Lee
since 1992, first on Ptolemy Classic (C++)
and now on Ptolemy II (Java).
• I took CS 169 with Prof Brewer in mid90’s, before the .com era
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
3
Software Engineering at Berkeley
•
•
•
•
No Formal Program: Part of CS
Survey of CS Baccalaureate grads:
2003-2006: 196 respond of 409 grads
Of the 196:
–
–
–
–
127 (65%) employed
39 (20%) in grad school
18 (9%) seeking employment
12 (6%) Other Endeavors
• 97 Employer/Titles listed
• 30 “Software Engineers”
• 59 Titles contain the word “Engineer”
Source: http://career.berkeley.edu/Major/CompSci.stm
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
4
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
5
Lower Division Computer Science
Prerequisites
• CS 61A (Structure and Interpretation of
Computer Programs), 61B (Data Structures), 61C
(Machine Structures)
• Math 1A and Math 1B (can be satisfied with
Advanced Placement),
• Math 54 (Linear Algebra and Differential
Equations)
• CS 70 (Discrete Mathematics and Probability
Theory)
• EECS 42 (Electronics). (We highly recommend
taking EECS 43, a one-unit laboratory course
taken P/NP, during the same semester as EECS
42.)
Source: http://www.eecs.berkeley.edu/csugrad/index.shtml
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
6
Required Courses for Satisfaction of the CS
Major
•
•
L&S CS majors must earn 27 units in upper division technical courses,
including:
Required Course: CS 170 (Algorithms)
•
Breadth courses choose
•
•
Any two additional Computer Science courses.
Technical electives.
two from the following:
–
–
–
–
–
–
–
CS 160. User Interfaces
CS 161. Computer Security
CS 162. Operating Systems and System Programming
CS 164. Programming Languages and Compilers
CS 169. Software Engineering
CS 184. Foundations of Computer Graphics
CS 186. Introduction to Databases
–
Including Undergraduate Business Administration
•
•
•
•
•
UGBA 103 Introduction to Finance (Prereq: UGBA 101A)
UGBA 119 Strategic Planning (101A-101B, 102A-102B, 103, 105, and senior standing. )
UGBA 140 Introduction to Management Science ??
UGBA 146 Planning and Design of E-Business Sys (Prereg: CS3)
UGBA 152 Negotiation and Conflict Resolution (Prereg: UGBA 105)
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
7
Software Engineering
• Not much coding
– Mostly bug fixing
• More management as time goes on
– Team Dynamics and Virtual Teams
– Project Management
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
8
Classes I wish I had taken
• Group Dynamics Classes
– How do teams operate
• Intellectual Property
- Patents
- Copyrights
• Project Management
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
9
PMI: Project Management
Institute
• “A Guide to the Project Management
Body of Knowledge “ (aka PMBOK)
• PMI Certification
– Certified Associate in Project Management
(CAPM)
– Project Management Professional (PMP)
– Program Management Professional (PgMP)
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
10
Ptolemy II:
• Ptolemy II: Set of Java packages supporting
–
–
–
–
heterogeneous,
concurrent modeling,
simulation, and
design of component-based systems.
• The kernel: definition and manipulation of
clustered hierarchical graphs, which are
collections of entities and relations between those
entities.
• The actor package extends the kernel so that
entities have functionality and can communicate
via the relations.
• The domains extend the actor package by imposing
models of computation on the interaction between
entities.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
11
Ptolemy II: Our Laboratory for
Experiments with Models of Computation
Concurrency management supporting
dynamic model structure.
Large, behaviorallypolymorphic component
library.
Director from a library
defines component
interaction semantics
Type system for
transported data
Visual editor supporting an abstract syntax
Source: Edward A. Lee
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
12
Ptolemy II: Functionality of Components is Given in C or
Java (which can wrap C, C++, Perl, Python, MATLAB, Web
services, Grid services, …)
Source: Edward A. Lee
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
13
Example: Discrete Event Models
DE Director implements
timed semantics using an
event queue
Reactive actors
Event source
Signal
Components send timestamped events to other
components, and components
react in chronological order.
Time line
Software Development in an Academic Environment
Source: Edward A. Lee
Nov 1, 2008 UCB CS169
14
Production vs. Research
Source: http://www.esi.es/Families/E1.4b-Method-Catalogue/CAFE/Details1-v0.1.html
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
15
Extreme Programming
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
16
Nightly Build
•
Build and test the system regularly
– Every night
•
Why? Because it is easier to fix problems earlier than later
– Easier to find the cause after one change than after 1,000 changes
– Avoids new code from building on the buggy code
•
Aiken: Test is usually subset of full regression test
– “smoke test”
– Just make sure there is nothing horribly wrong
Keutzer: I disagree with this point. Typical case should be to run
entire regression test
Jim McCarthy (Director of MSVC++ Group): “If you build it, it will
ship”
Build a release every night, run tests – makes integration easier.
•
•
•
Software Development in an Academic Environment
Aiken
Nov 1, 2008 UCB CS169
17
Ptolemy II Nightly Build
– Ptolemy II has ~6700 tests for ~2100 Java files
contain 675,000 lines of code.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
18
Code Coverage
• The fireOneRound() method is not covered
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
19
Coding Style Features
• Code should have a consistent style
– Decided by one person (Professor, CTO)
– Enforced by a tool
• Document using complete sentences with
good grammar
– Be nice to yourself and others that use your
code.
• Identifiers use complete words
(CamelCase)
– This aids in readability and accessibility – the
developer knows that the variable or method is
numberOfEspressos, not numEsp or n.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
20
Testing Documentation: doccheck
Doccheck is a javadoc plug-in from Sun that
points out common problems.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
21
Regression Tests: Test Plan
• Strategy:
• Goals:
A good strategy would be?
– Ensure basic functionality according to the
Design Spec.
– Ensure that the functionality does not regress
(i.e. previously fixed bugs do not reappear or
cause new bugs).
– Focus on stress, capacity, and boundary
conditions.
• Scope: Regression testing targets
commands or program functions.
– All commands and / or programs
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
22
Design and Code Reviews
• Objective is “publishable software”
• Defined roles for participants
– Author has the last word
• Mechanism for new group members to learn
to differentiate good from bad software.
All technical reviews are based on the idea
that developers are blind to some of the
trouble spots in their work...
-Steve McConnell
John Reekie and the Ptolemy team
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
23
Code Rating
•
A simple framework for
–
–
•
quality improvement by
peer review
change control by
improved visibility
Four confidence levels
–
–
–
–
Red. No confidence at all.
Yellow. Passed design
review. Soundness of the
APIs.
Green. Passed code review.
Quality of implementation.
Blue. Passed final review.
Backwards-compatibility
assurance.
• What is this about
really?
– Confidence in
quality
– Commitment to
stability
Source: John Reekie
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
24
Orca and testing
• Orca “an open-source framework for
developing component-based robotic
systems “
(http://orcarobotics.sourceforge.net/)
• Orca uses CMake
(http://www.cmake.org)
to configure the system
• Orca uses the Dart2 Dashboard to
show nightly build output
http://129.78.210.237:8081/orca2/D
ashboard/
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
25
Orca Dashboard http://129.78.210.237:8081/orca2/Dashboard/
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
26
Orca Dashboard Coverage
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
27
Orca Dashboard Coverage Detail
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
28
Orca Dashboard Coverage Detail
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
29
Lessons not learned: Process Problems
• Review process decayed
• No read-ahead
– This is a walkthrough, not a review
• No follow up
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
30
Automatic Tools
• Static code checkers
– gcc
– Coverity – not Free
– Java tools like FindBugs and PMD
• Memory checkers
– Electric Fence (for C)
– Purify – not Free
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
31
Software Tools
•
•
•
•
•
JUnit (xUnit)
Eclipse
Maven
CMake/CTest
Ant – be fully buzzword compliant, but
know how to use make.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
32
Lessons not Learned: Threads
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
33
The Problem with Threads
• Edward A. Lee: IEEE Computer,
May 2006 article
• “For concurrent programming to become
mainstream, . . .
• we must discard threads as a programming
model”.
• “Nondeterminism should be judiciously and
carefully introduced when needed, . . .
• and it should be explicit in programs.”
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
34
To See That Current Practice is Bad,
Consider a Simple Example
“The Observer pattern defines a one-tomany dependency between a subject object
and any number of observer objects so
that when the subject object changes
state, all its observer objects are notified
and updated automatically.”
Design Patterns, Eric Gamma, Richard Helm, Ralph Johnson, John
Vlissides (Addison-Wesley Publishing Co., 1995. ISBN:
0201633612):
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
35
Observer Pattern
Source: Wikipedia
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
36
Observer Pattern in Java
public void addListener(listener) {…}
public void setValue(newValue) {
myValue = newValue;
for (int i = 0; i < myListeners.length; i++) {
myListeners[i].valueChanged(newValue)
}
}
Will this work in a
Thanks to Mark S. Miller for the multithreaded context?
details of this example.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
37
Observer Pattern
With Mutual Exclusion (Mutexes)
public synchronized void addListener(listener) {…}
public synchronized void setValue(newValue) {
myValue = newValue;
for (int i = 0; i < myListeners.length; i++) {
myListeners[i].valueChanged(newValue)
}
}
Javasoft recommends against this.
What’s wrong with it?
See also Allen Holub’s Java World Article “The Observer pattern and
mysteries of the AWTEventMulticaster”
http://www.javaworld.com/javaworld/jw-03-1999/jw-03-toolbox.html
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
38
Mutexes are Minefields
public synchronized void addListener(listener) {…}
public synchronized void setValue(newValue) {
myValue = newValue;
for (int i = 0; i < myListeners.length; i++) {
myListeners[i].valueChanged(newValue)
}
}
valueChanged() may attempt to acquire
a lock on some other object and stall. If
the holder of that lock calls
addListener(), deadlock!
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
39
After years of use without problems, a Ptolemy Project code review found
code that was not thread safe. It was fixed in this way. Three days later,
a user in Germany reported a deadlock that had not shown up in the test
suite.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
40
Simple Observer Pattern Becomes
Not So Simple
public synchronized void addListener(listener) {…}
public void setValue(newValue) {
while holding lock, make copy
synchronized(this) {
of listeners to avoid race
myValue = newValue;
conditions
listeners = myListeners.clone();
notify each listener outside of
}
synchronized block to avoid
deadlock
for (int i = 0; i < listeners.length; i++) {
listeners[i].valueChanged(newValue)
}
}
This still isn’t right.
What’s wrong with it?
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
41
Simple Observer Pattern:
How to Make It Right?
public synchronized void addListener(listener) {…}
public void setValue(newValue) {
synchronized(this) {
myValue = newValue;
listeners = myListeners.clone();
}
for (int i = 0; i < listeners.length; i++) {
listeners[i].valueChanged(newValue)
}
}
Suppose two threads call setValue(). One of them will set the value last,
leaving that value in the object, but listeners may be notified in the opposite
order. The listeners may be alerted to the value changes in the wrong order!
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
42
If the simplest design patterns yield such
problems, what about non-trivial designs?
/**
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 with 100% code
// synchronized, since it is called by _farContainer(),
coverage, design
// which is. Having it synchronized can lead to
reviewed to yellow, then
// deadlock. Fortunately, it is an atomic action,
// so it need not be synchronized.
code reviewed to green
private Object _nearContainer() {
in 2000, causes a
return _container;
deadlock during a demo
}
private synchronized Object _farContainer() {
if (_far != null) return _far._nearContainer();
else return null;
}
…
on April 26, 2004.
}
}
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
43
Edward Lee’s Claim
Nontrivial concurrent software written
with threads is incomprehensible to
humans and cannot be trusted!
Maybe better abstractions would lead
to better practice…
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
44
Succinct Problem Statement
Threads are wildly nondeterministic.
The programmer’s job is to prune away the
nondeterminism by imposing constraints on
execution order (e.g., mutexes) and limiting
shared data accesses (e.g., OO design).
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
45
Perhaps Concurrency is Just Hard…
Sutter and Larus observe:
“humans are quickly overwhelmed by
concurrency and find it much more difficult
to reason about concurrent than sequential
code. Even careful people miss possible
interleavings among even simple collections
of partially ordered operations.”
H. Sutter and J. Larus. Software and the
concurrency revolution. ACM Queue, 3(7), 2005.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
46
If concurrency were intrinsically hard, we would
not function well in the physical world
It is not
concurrency that
is hard…
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
47
…It is Threads that are Hard!
Threads are sequential processes that
share memory. From the perspective of
any thread, the entire state of the
universe can change between any two
atomic actions (itself an ill-defined
concept).
Imagine if the physical world did that…
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
48
Yet threads are the basis for all
widely used concurrency models, as
well as the basis for I/O interactions
and network interactions in modern
computers.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
49
Succinct Solution Statement
Instead of starting with a wildly
nondeterministic mechanism and asking the
programmer to rein in that nondeterminism,
start with a deterministic mechanism and
incrementally add nondeterminism where
needed.
The question is how to do this and still get
concurrency.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
50
Actor-Oriented Design
The established: Object-oriented:
class name
What flows through
an object is
sequential control
data
methods
call
return
The alternative: “Actor
oriented:”
actor name
data (state)
parameters
ports
Input data
Things happen to objects
Actors make things happen
What flows through
an object is
evolving data
Output data
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
51
The First (?) Actor-Oriented Programming
Language
The On-Line Graphical Specification of Computer Procedures
W. R. Sutherland, Ph.D. Thesis, MIT, 1966
MIT Lincoln Labs TX-2
Computer
Bert Sutherland with a light
pen
Bert Sutherland used the first acknowledged objectoriented framework (Sketchpad, created by his
brother, Ivan Sutherland) to create the first actororiented programming language (which had a visual
syntax).
Partially constructed actor-oriented
model with a class definition (top) and
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
52
Examples of Actor-Oriented
Coordination Languages
•
•
•
•
•
•
•
•
•
•
•
•
CORBA event service (distributed push-pull)
ROOM and UML-2 (dataflow, Rational, IBM)
VHDL, Verilog (discrete events, Cadence, Synopsys, ...)
LabVIEW (structured dataflow, National Instruments)
Modelica (continuous-time, constraint-based, Linkoping)
OPNET (discrete events, Opnet Technologies)
SDL (process networks)
Occam (rendezvous)
Ptolemy (various, Berkeley)
Simulink (Continuous-time, The MathWorks)
SPW (synchronous dataflow, Cadence, CoWare)
…
The semantics of these differ considerably,
Many of these are
domain specific.
Many of these
have visual
syntaxes.
but all can be modeled as
with appropriate choices of the set T.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
53
11 Steps to successfully
completing a software project
1. Create a one page charter
2. Separation of concerns: MVC: gui vs backend
3. Start writing tests early, use a code coverage tool
4. Use a nightly build
5. Use a consistent coding style and use a tool to enforce the style
6. Use tools: memory leaks, warnings, spelling errors, performance
problems, other compilers, other operating systems.
7. Document your code. Writing documentation first can prevent
hours of wasted time.
8. Don’t debug for more than an hour by yourself – get help.
9. Design Review and Code Review (or at least desk check)
10. Expect the unexpected: wacky user input, wacky user
interaction
11. Don’t be afraid to throw away code and start over.
Software Development in an Academic Environment
Nov 1, 2008 UCB CS169
54
Descargar

Software Development in an Academic Environment: …