Der Perfekte Vortrag

Andreas Zeller

Ziele des Seminars

• Erste Schritte zu wissenscha"lichen

Herausforderungen

• Technischen Stoff strukturieren und präsentieren

• Soziale und kommunikative Fähigkeiten
verbessern

You may wish to

* impress people with your
Ziel des Vortrags brainpower
* tell them you know all
and everything
* tell them how you went in
there and back
All this is wrong.
 From Simon Peyton Jones,
“How to give a great
Ziel des Vortrags research talk”

• Zuhörer für die Sache begeistern

• Die Grundidee intuitiv vermitteln
• Zuhörer fragen, einbeziehen, provozieren
• Zuhörer glücklich machen

Vorbereitung

• Material prüfen
• Zentrale Beiträge und Ideen sammeln
• Vortrag strukturieren
• Detaillierte Skizze machen

Selbst-Check

• Sind die Beiträge glaubhaft?

• Sind die Beispiele hilfreich?
• Kann ich das besser machen?
• Was sind die Hauptbeiträge überhaupt?
• Und wie werden sie unterstützt?
 Selbst-Check

• Wenn jemand nur eins aus meinem

Vortrag behält, was sollte das sein?

Der perfekte Vortrag

• Hug0Pratt
•

Wake up!
Your Audience
 Au%au des Vortrags

• Motivation
• Lösung (einschließlich Fehlschläge)
• Ergebnisse
• Schluss

“Jabberwock” von Lewis

Carrol – “Der Zipferlak” in
der Übersetzung von
Christian Enzensberger

Motivation

• Stelle den Rahmen vor

Es war einmal ein Dorf auf der grünen Wiese…

• Stelle ein konkretes Problem vor

(und mache es zum Problem der Zuhörer)
Böser Zipferlak grei" Bauernvolk an!

• Der Stand der Dinge reicht nicht aus

Mistgabeln scheitern an Panzerung
 Lösung und Ergebnisse

• Zeige neuen Ansatz und Lösungen

Held kommt mit scharfgebifftem Schwert

• Zeige, wie Ansatz konkretes Problem löst

Mit Eins! und Zwei! und bis auf's Bein!
Die biffe Klinge ritscheropf!

• Gilt dies auch allgemein?

Geht dies auch für andere Ungeheuer? Wieso?

Dein Schwert: Beispiele

• Motiviere die Zuhörer

• Stelle Grundidee vor
• Zeige, wie Grundidee funktioniert
• Erst Beispiele, dann verallgemeinern

Übersicht

• Erzähle eine Geschichte

• Folien unsichtbar machen
• Viele Beispiele bringen
What’s wrong
• Zu den Hörern sprechen with this slide?
• Fragen und Nachfragen erwarten
 Thomas Ball Andreas Zeller*
Microsoft Research Saarland University
edmond, Washington
Übersicht
Saarbrücken, Germany
all@microsoft.com zeller@cs.uni-sb.de

• Keine Übersicht am Anfang

predictions require a long failure history, which may not exist for
y of the the entity at hand; in fact, a long failure history is something one
ms, we • Keine
would like toÜbersicht in der Mitte
avoid altogether.
stically A second source of failure prediction is the program code itself:
re is no
versally
• Am besten:
In particular, Gar metrics
complexity keine Übersicht
have been shown to correlate
with defect density in a number of case studies. However,
on the indiscriminate use of metrics is unwise: How do we know the
predict • Besser: Nach 5 Minuten Diagramm zeigen
chosen metrics are appropriate for the project at hand?
. The
In this work, we apply a combined approach to create accurate
ects; in
also be
• Diagramm als einprägsames Bild auffassen
failure predictors (Figure 1): We mine the archives of major
software systems in Microsoft and map their post-release failures
back to individual entities. We then compute standard complexity
metrics for these entities. Using principal component analysis, we
determine the combination of metrics which best predict the
and failure probability for new entities within the project at hand.
eering]: Finally, we investigate whether such metrics, collected from
Product failures in the past, would also good predictors for entities of
oftware other projects, including projects be without a failure history.
!"#$%&&'()#*+,-)#./)/

*+,)
!"# 7)2(/+. *+,)
*+,)
$%&%'%() $%&%'%()
rincipal

0"#1/,#,%2)34'&'/2'#5/*&-4'2#)%#.'5'()2#*+#'+)*)*'2
nsumes
ency of -.&/&0 -.&/&0 -.&/&0
st. We
are the
tion.
past: If
e other
o in the 6"#74'.*()#5/*&-4'#,4%8/8*&*)9#5%4#+':#'+)*)*'2
bases—
-.&/&0 4%/5"2)
hat one 12),/3&+2
62+'%'/5/&0
ccurate
Figure 1. After mapping historical failures to entities, we can
use their complexity metrics to predict failures of new entities.
_________________________________________________________________________________

*
Andreas Zeller was a visiting researcher with the Testing,
Verification and Measurement Group, Microsoft Research in the
Fall of 2005 when this work was carried out.
Folieninhalt

• Auf das wichtigste konzentrieren

(d.h. maximal 5 Punkte pro Folie)

• Was auch schlecht ist: vollständige Sätze auf

einer Folie unterzubringen – sie sind viel zu
lang und schwer zu lesen; außerdem verleiten
sie dazu, sie laut vorzulesen. Read full
sentence
aloud
 http://www.youtube.com/
watch?v=Rp8dugDbf4w
Death by Powerpoint

Foliengestaltung

• Oberstes Ziel: Klarheit

• Alles vermeiden, was vom Inhalt ablenkt
• Folien sollten das gesprochene Wort
unterstützen

• Diagramme sind immer besser als Text

• Aufzählungen vermeiden (wie diese)

<?xml version="1.0" encoding="UTF-8"?>

<defects project="eclipse" release="3.0">
<package name="org.eclipse.core.runtime">
<counts>
bug density

<count id="pre" value="16" avg="0.609" points="43" max="5">

<count id="post" value="1" avg="0.022" points="43" max="1">
</counts>
<compilationunit name="Plugin.java">
<counts>
<count id="pre" value="5"> Plugin.java had 5 failures )
before and one failure after
<count id="post" value="1"> release (``post''). The
package contains 43 files
(``points'') and encountered 16
failures before and one failure
after release; on average each
file in this package had 0.609
failures before and 0.022
failures after release (``avg'')

Bugs • Fixes • Changes

 Mathematik

! tε
fh,ε (x, y) = εEx,y Lx,yε (εu) ϕ(x) du
0
!
= h Lx,z ϕ(x)ρx (dz)
" # ! tε ! $
1
+h Ey Lx,yx(s) ϕ(x) ds − tε Lx,z ϕ(x)ρx (dz)
tε 0
# ! tε ! tε $%
1
+ Ey Lx,yx(s) ϕ(x) ds − Ex,y Lx,yε(εs) ϕ(x) ds
tε 0 0
&
= hLx ϕ(x) + hθε (x, y)
(64)

Formal Background
Concrete state v ∈ V with v = (x1 , x2 , . . . , xn )
xi – Return value of an inspector

Trace t = (v1 , m1 , v1! ), (v2 , m2 , v2! ), . . .

! "

with vi ∈ V and mi – name of a mutator

State abstraction abs: V → S
Model with transitions s !→ s " and states
m
s, s ! ∈ S

Transition condition s !→ s " with s, s ! ∈ S iff

m

∃(v, m, v " ) ∈ t · abs(v) = s ∧ abs(v " ) = s "

Mathematik

• Kurz: Vermeiden.
• Formeln sind für Papier, nicht für Folien
• Nur wenige Menschen können komplexe
Formeln in 30 Sekunden verstehen

• Es reicht, zu zeigen, dass es eine Theorie gibt.

• Beispiele sind wichtiger als Formeln!
 Diagramme

• Einfache, klare Diagramme nutzen

• Genau eine Botschaft pro Diagramm

7%

Körpersprache
Stimme 38% 55%
Inhalt

Model Sizes
150
130

100
Classes

53
50
22
15
5 8
2 2 4 1 1 1 2 1
0
1 2 3 4 5 6 7 8 9 10 11 12 13 +
States

Bilder und Animationen

• Bilder und Animationen funktionieren gut in

Diagrammen

• Alles andere sollte wohl überlegt sein

• Nicht zur Verzierung verwenden
• Nicht zur Ablenkung verwenden
• Graphische Klischees vermeiden
 http://www.indezine.com/
articles/
Was ist falsch? slidesfromhell2.html

http://www.youtube.com/
watch?v=Rp8dugDbf4w
Death by Powerpoint

Nach Einfachheit streben

• Einfache Botscha"en sind leichter zu vermitteln

• Einfache Beispiele passen auf eine Folie
• Einfache Folien lassen alle zuhören
• Einfache Behauptungen sind öfter a)gemein
• Einfach = Schwer!
 Der Vortrag

• Folien nicht vorlesen (von Papier oder Folie)

• Langsam, laut und klar sprechen
• Persönlich sprechen (“Ich” statt “man”)
• Tonhöhe und Sprachpausen nutzen

Der Gelee-Faktor

• Jeder Vortragende ist nervös (ich auch)

• Beine zittern
• Luft wird knapp
• Hirn geht in Stand-by
• … doch keiner wird es bemerken –
oder sich gar sorgen!

Der Gelee-Faktor

Vor dem Vortrag:

• Hände waschen
• Hinsetzen
• Durch Folien durchgehen
• Erste Sätze auswendig lernen
(kein Hirn vonnöten)
 Kontakt mit Zuhörern

• Direkt zu Zuhörern sprechen

• Rhetorische Fragen stellen
(“Was so) das arme Bauernvolk tun?”)

• Augenkontakt zu Zuhörern suchen

(nicht zu den Folien, nicht zum Professor)

• Eigene Begeisterung herüberbringen!

Einige große Redner

Everything is precisely
choreographed in here.
Steve Jobs Note the slide design,
focusing on the very
essential.
Source: Apple
 Look how Lessig’s words
are in sync with his talk.
Lawrence Lessig Source: http://
www.presentationzen.com/
presentationzen/2008/03/
larry-lessigs-l.html

Der Schluss
• Auf den Anfang beziehen
…und wenn sie nicht gestorben sind, …

• Zusammenfassen
…und das wichtigste ist: …

• Offene Punkte
…aber es warten noch mehr Zipferlaken im Dunkeln

• Folgen
Wenn Sie also einen Zipferlaken sehen …

Detecting Anomalies Program Comprehension

DeferredWriteFile HashTableOfObject

<init>

Failing runs Passing runs

<init>

•
!exists,!isDirty,
toString!=null,getParent=FAIL, clone!=null, containsKey(),

Documentation
getName!=null size=0 get()

add() create()
put()

<init> add() <init> add()

•“Normal
exists,isDirty, getLocation(), put(),
toString!=null,getParent=FAIL, setDerived(), clone!=null,
containsKey(),
size>0

Specification
getName!=null writeWovenBytes()
get()

isEmpty() ¬isEmpty isEmpty() ¬isEmpty

behavior
remove()
! clear()
clear()
! LineNumberGen • Model Checking
is correct behavior”
PointcutDeclaration
setInstruction()
• Static Analysis <init>

Differences point to error location

getLineNumber!=null,
getSourceLine=0
getPointcut!=null,
makeResolvedPointcutDefinition=FAIL, postParse()
setSourceLine() makeAttribute=FAIL

getLineNumber!=null,
<init> parseStatements()
getSourceLine>0

setInstruction()
getPointcut!=null,
resolveStatements(),
makeResolvedPointcutDefinition!=null,
generateCode()
getLineNumber=FAIL, makeAttribute!=null
updateTarget()
getSourceLine>0

Building Models

v:Vector Assessing Changes

Searching Failure Causes <init> add()
Version 1 Version 2
add()

!
add() add()
add() <init> add() <init> add()

isEmpty() ¬isEmpty() isEmpty() ¬isEmpty isEmpty() ¬isEmpty

remove() v:Vector
remove() clear()
remove() clear() clear()

• Which mutators void testVector()

Differences point to potential errors
cause the failure? {
v.add(1);

• Simplifying with v.remove(1);

assert(v.isEmpty());
delta debugging }

Finding Violations
Can I call
<init> setDerived()
here?
!exists,!isDirty,
toString!=null,getParent=FAIL,
getName!=null

create()

exists,isDirty, getLocation(),
toString!=null,getParent=FAIL, setDerived(),
getName!=null writeWovenBytes()
 Detecting Anomalies Program Comprehension
DeferredWriteFile HashTableOfObject

<init>

Failing runs Passing runs

<init>

• Documentation
!exists,!isDirty,
toString!=null,getParent=FAIL, clone!=null, containsKey(),
getName!=null size=0 get()

add() create()
put()

<init> add() <init> add()

•“Normal
exists,isDirty, getLocation(), put(),
toString!=null,getParent=FAIL, setDerived(), clone!=null,
containsKey(),
size>0

Specification
getName!=null writeWovenBytes()
get()

isEmpty() ¬isEmpty isEmpty() ¬isEmpty

behavior
remove()
! clear()
clear()
! LineNumberGen • Model Checking
is correct behavior”
PointcutDeclaration
setInstruction()
• Static Analysis <init>

Differences point to error location

getLineNumber!=null,
getSourceLine=0
getPointcut!=null,
makeResolvedPointcutDefinition=FAIL, postParse()
setSourceLine() makeAttribute=FAIL

getLineNumber!=null,
<init> parseStatements()
getSourceLine>0

setInstruction()
getPointcut!=null,
resolveStatements(),
makeResolvedPointcutDefinition!=null,
generateCode()
getLineNumber=FAIL, makeAttribute!=null
updateTarget()
getSourceLine>0

Building Models

v:Vector Assessing Changes

Searching Failure Causes
Model Mining add()
<init> Version 1 Version 2
add()

!
add() add()
add() <init> add() <init> add()
isEmpty() ¬isEmpty()
isEmpty() ¬isEmpty isEmpty() ¬isEmpty
remove() v:Vector
remove() clear()
remove() clear() clear()

• Which mutators void testVector()

Differences point to potential errors
cause the failure? {
v.add(1);

• Simplifying with v.remove(1);

assert(v.isEmpty());
delta debugging }

Again, think visual!

Finding Violations
Can I call
<init> setDerived()
here?
!exists,!isDirty,
toString!=null,getParent=FAIL,
getName!=null

create()

exists,isDirty, getLocation(),
toString!=null,getParent=FAIL, setDerived(),
getName!=null writeWovenBytes()

Noch Fragen?

• Gute Vorträge stoßen viele Fragen an!

• Fragen verbinden den Vortragenden mit dem
Publikum – und zeigen neue Wege auf

• Am peinlichsten sind keine Fragen

(Hat überhaupt jemand zugehört?)

Zusammenfassung

• Erzähle eine Geschichte

• Folien unsichtbar machen
• Viele Beispiele bringen
• Zu den Hörern sprechen
• Fragen und Nachfragen erwarten
 Annals of Improbable
Research 12(5), 2006
Doug Zongker http://isotropic.org/
papers/chicken.pdf