scientific writing some personal observations kim guldstrand larsen ucb
TRANSCRIPT
Scientific Writing Some personal observations
Kim Guldstrand Larsen
UCb
2UCb
Tools and BRICS
Logic• Temporal Logic• Modal Logic• MSOL • •
Algorithmic• (Timed) Automata Theory• Graph Theory• BDDs• Polyhedra Manipulation• •
Semantics• Concurrency Theory• Abstract Interpretation• Compositionality• Models for real-time & hybrid systems• •
HOL TLP
Applications
PVS ALF
SPINvisualSTATE UPPAAL
3UCb
A very complex system
Klaus Havelund, NASA
4UCb
Spectacular Software Bugs
ARIANE-5 INTEL Pentium II floating-point division
470 Mill US $
Baggage handling system, Denver 1.1 Mill US $/day for 9 months
Mars Pathfinder Radiation theraphy, Therac-25 …….
5UCb
Embedded Systems
80% of all existing software is embedded in interacting devices.
Demand on increasing functionality with minimal resources.
6UCb
How?
Unified Model = State Machine!
a
b
x
ya?
b?
x!
y!b?
Control states
Inputports
Outputports
7UCb
TamagotchiA C
Health=0 or Age=2.000
B
Passive Feeding Light
Clean
PlayDisciplineMedicine
Care
Tick
Health:=Health-1; Age:=Age+1
AA
A
A
AA
A
A
Meal
Snack
B
B
ALIVE
DEAD
Health:= Health-1
8UCb
Digital Watch Statechart=UML, David HARELStatechart=UML, David HAREL
9UCb
SYNCmaster
10UCb
SP
IN, G
erald H
olzm
ann
AT
&T
11UCb
visualSTATE
Hierarchical state systems
Flat state systems Multiple and
inter-related state machines
Supports UML notation
Device driver access
VVS w Baan Visualstate, DTU (CIT project)
12UCb
UP
PA
AL
Larsen et al
13UCb
Tool Support
TOOLTOOL
System Description A
Requirement F Yes, Prototypes Executable Code Test sequences
No!Debugging Information
Tools: UPPAAL, visualSTATE, SPIN, ESTEREL, TeleLogic, Statemate, Formalcheck,..
Tools: UPPAAL, visualSTATE, SPIN, ESTEREL, TeleLogic, Statemate, Formalcheck,..
14UCb
Tool Support
TOOLTOOL
System Description A
Requirement F Yes, Prototypes Executable Code Test sequences
No!Debugging Information
• Mathematical Formalisms for modelling and specifying System Behaviour • Methods for Analysis Algorithms/Datastructures• Experiment/Implementation• Case Studies• Tool Building
• Mathematical Formalisms for modelling and specifying System Behaviour • Methods for Analysis Algorithms/Datastructures• Experiment/Implementation• Case Studies• Tool Building
Writing Scientific Paper(s)
16UCb
CollaborationArne Skou
J. Stage
K. Nørmark
U.H. Engberg
P.D. Mosses
E. Brinksma
W.R. Cleaveland
T. Margari
B. Steffen
S. Skyum
G. Winskel
Mogens Nielsen
Finn V. Jensen
G. Boudol
Bent Thomsen
Liu Xinxin
Robin Milner
Klaus Havelund
Anders Børjesson
Wang Yi
P. Pettersson
C. Weise
Justin Pearso
J. Staunstrup
H.R. Andersen
H. Hulgaard
G. Behrmann
K. Kristoffersen
J. Lind-Nielsen
H. Leerberg
N.B. Theilgaard
T. Hune
Bengt Jonsson
J. Bengtsson
W.O.D. Griffioen
F. Larsson
L. Aceto
P. Bouyer
A. Burgueno
Hans Hüttel
Jens C. Godskesen
Michael Zeeberg
U. Holmer
Karlis Cerans
J.H. Andersen
J. Niederman
F. Laroussinie
P. Pettersson
H.E. Jensen
J.H. Andersen
Kristian Lund
Bodentien Nicky O.
Vestergaard Jacob
Friis Jakob
T. Iversen
M. Laursen
R.G. Madsen
S.K. Mortensen
C.B. Thomasen
F. Cassez
Alexandre David
Oliver Möller
Ansgar Fehnker
Judi Romijn
Tobias Amnell
Pedro R. D'Argenio
Bertrand Jeannet
Frits Vaandrager
M. Hendriks
Henning Dierks
Radek Pelanek
Zoltan Esik
17UCb
Writing a Paper / Papers
1. Work on a (relevant) CS question2. Write a scientific paper3. Submit the paper to an appropriate
journal/conference4. If accepted then
1. Add one line to CV2. Present work at scientific meeting
(and get ideas for the next papers)
5. Else: Go to Step 1.6. In any case: Go to Step 1.
18UCb
What is a Scientific Paper
A scientific paper is a written and published report describing original research results
Primary Publication, i.e. the first publication of original research results repeatable and testable available
Technical report/web (I/we did it [first])Conference paper (It works, it’s neat, and there is more to
come)JournalTextbooks or research monographs
9393
3232
(10)(10)
BRICSDBLP Bib Server
BRICSDBLP Bib Server
19UCb
Why Do People Write Papers?
Idealist: Any scientific paper furthers our knowledge of the field. It is a contribution to the community of our peers.
Realist: My point of view is that “Our currency is reputation” (Moshe Vardi at our Research Evaluation). Good scientific papers are one of the means to increase reputation in our scientific community. Our peers decide the weight of a primary publication (citations is a possible measure).
20UCb
ww.citeseer.com
………..558. M. Lee: 1510559. M. Maher: 1509560. J. Jaffar: 1505561. J. Lenstra: 1504562. A. Swami: 1503563. Z. Li: 1502564. S. Hammarling: 1502565. G. Stewart: 1499566. D. Shmoys: 1499567. K. Larsen: 1495568. J. White: 1494569. G. Winskel: 1493570. L. Stockmeyer: 1491571. X. Wang: 1491
The 10.000 most cited CS authorsout of 629.254
The 10.000 most cited CS authorsout of 629.254
…521. J. Ferrante: 1882522. M. Lee: 1882523. A. Cox: 1878524. R. Needham: 1878525. J. Foley: 1877526. F. Glover: 1877527. K. Larsen: 1873528. T. Dietterich: 1872529. J. Kubiatowicz: 1871530. D. Lenoski: 1871531. S. Geman: 1870532. D. Gelernter: 1869533. J. Kramer: 1869534. Y. Yang: 1861
21UCb
www.citeseer.com
Context Doc 132.2 128 (6): K.G. Larsen and A. Skou. Bisimulation through probabilistic testing (preliminary report). In Proc. 16th ACM Symp. Princ. of Prog. Lang., pages 344--352, 1989.
Context Doc 67.4 46 (3): J. Bengtsson, K.G. Larsen, F. Larsson, P. Pettersson, and W. Yi. UPPAAL- a tool suite for the automatic verification of real-time systems. In Proceedings of Hybrid Systems III. LNCS 1066.pages 232-243. Spriger Verlag. 1996.
Context Doc 42.1 39 (10): K. G. Larsen and L. Xinxin. Compositionality through an operational semantics of contexts. Journal of Logic and Computation, 1:761--795, 1991.
Context Doc 41.4 31 (0): K. G. Larsen, P. Pettersson, and W. Yi. Model-checking for real-time systems. In Horst Reichel, editor, Proceedings of the 10th International Conference on Fundamentals of Computation Theory, volume 965 of Lecture Notes in Computer Science, pages 62--88, Dresden, Germany, August 1995. Springer-Verlag.
Context Doc 34.3 21 (3): Larsen, K. G., P. Pettersson and , Y. Wang: "UPPAAL in a nutshell". To appear: International Journal on Software Tools for Technology Transfer, Springer Verlag, September 1997.
Context Doc 132.2 128 (6): K.G. Larsen and A. Skou. Bisimulation through probabilistic testing (preliminary report). In Proc. 16th ACM Symp. Princ. of Prog. Lang., pages 344--352, 1989.
Context Doc 67.4 46 (3): J. Bengtsson, K.G. Larsen, F. Larsson, P. Pettersson, and W. Yi. UPPAAL- a tool suite for the automatic verification of real-time systems. In Proceedings of Hybrid Systems III. LNCS 1066.pages 232-243. Spriger Verlag. 1996.
Context Doc 42.1 39 (10): K. G. Larsen and L. Xinxin. Compositionality through an operational semantics of contexts. Journal of Logic and Computation, 1:761--795, 1991.
Context Doc 41.4 31 (0): K. G. Larsen, P. Pettersson, and W. Yi. Model-checking for real-time systems. In Horst Reichel, editor, Proceedings of the 10th International Conference on Fundamentals of Computation Theory, volume 965 of Lecture Notes in Computer Science, pages 62--88, Dresden, Germany, August 1995. Springer-Verlag.
Context Doc 34.3 21 (3): Larsen, K. G., P. Pettersson and , Y. Wang: "UPPAAL in a nutshell". To appear: International Journal on Software Tools for Technology Transfer, Springer Verlag, September 1997.
22UCb
www.citeseer.com
23UCb
www.citeseer.com
24UCb
www.citeseer.com
25UCb
How to write a scientific paper
The main message: The preparation of a scientific paper has
almost nothing to do with literary skill. It is a question of collaboration and organization.
Rule of Thumb: In your presentation, follow a logical
progression from problem to solution.
26UCb
Typical Organization
Title / List of authors / AbstractIntroduction / compelling example /
related work / overviewDevelopmentConclusion (if any)Acknowledgments / references
27UCb
Title
It should be informativeIt should be conciseIt should be catchy / memorableIt is best original, but it does not
need to be funny
The title is a label, not a sentence
28UCb
Title – examples
Gérard Boudol, Kim G. Larsen: ``Graphical versus Logical Specifications''
Kim G. Larsen, Arne Skou: "Bisimulation Through Probabilistic Testing“
Klaus Havelund, Kim G. Larsen: ``The Fork Calculus''
K.G. Larsen, F. Laroussinie, C.Weise: ``From Timed Automata to Logic – and Back''
29UCb
Titles – more examples
Kim G. Larsen, Carsten Weise, Wang Yi and Justin Pearson: ``Clock Difference Diagrams.''
J. Lind-Nielsen, H.R. Andersen, G. Behrman, H. Hulgaard, K. Kristoffersen and K.G. Larsen: ``Verification of Large State/Event Systems using Compositionality and Dependency Analysis”
F. Cassez, K.G. Larsen: ``The Impressive Power of Stopwatches''
Kim G. Larsen, Gerd Behrmann, Ed Brinksma, Ansgar Fehnker, Thomas Hune, Paul Pettersson, Judi Romijn: ``As Cheap as Possible: Efficient Cost-Optimal Reachability for Priced Timed Automata''
G. Behrmann, K. G. Larsen, R. Pelanek: “To Store or Not to Store.”
30UCb
The List of Authors
Alphabertically orderedOrdered by degrees of contributionStudent first, supervisor secondAny other scheme
I have almost always used alphabetical order.
31UCb
Authorship and Credits
An author of a paper should be defined as one who takes intellectual responsibility for the research results being reported.
Give lavish acknowledgments. (One feels miffed after reading a paper in which one has not been given proper credit.)Give credit where it is due. It does not cost anything, and it creates friends. Science is more of a social activity than you might think.
32UCb
Introduction
A bad beginning makes a bad ending
FACT: The introduction often decides the destiny of a paper.
The introduction is often the only part of your paper that will be read.
The introduction should not be (too) technical.
33UCb
Introduction
It should present and motivate first, and in all possible clarity, the nature and scope of the problem investigated.
It should review related literature (to orient reader and please reviewer).
Clearly state achievement of paper Overview the rest of the paper
A compelling example is always good. Link to the Introduction during the remainder of
the paper.
34UCb
Pitfalls
ExaggerationSeeking the effect for the sake of
seeking effect: “this paper bridges a much need gap”.
Misspelling (always use a splel-checker)
35UCb
How to Present Your Results
Technical preliminaries/background (setting the scene)
Progressive development of the material (organized in logical sections).
Remember to state where your contribution lies.
Anticipate, and answer, the possible questions that a reader might have.
36UCb
How to Present Your Results
Present your results in as logical a way as possible. If reader needs A to understand B, then first present A, then B.
Always introduce technical terms before using them.
37UCb
On Formalization
Primary objective is clarity:be as formal as it takes to make your point – but no more!!
Lift your results to the most abstract/general level – I.e. convey main technique rather than mathematical fiddling.
38UCb
Related Work
MandatorySituates the novelty and significance of
your work. Answers at least the questions: where do the ideas come from? have similar ideas been published earlier what is really new in the paper
Where: introduction or conclusion or stand-alone.
39UCb
Conclusion
Option 1: NoneOption 2: Minimal
recapitulate problem and the contribution
assesses the significance of the contribution
outline of future work
40UCb
Submission
The Actors
Author(s)Editor(s) / program committee
membersThe refereesThe intended audience, andTime
41UCb
Review
The task of a referee is to evaluate in a timely manner a paper for publication (in journal or conference proceedings)
Evaluation / Critical JudgmentTimeliness
42UCb
Receiving a Referee Report
Before reading a referee report1. Take a deep breath2. Remember that a good report is
always valuable3. somebody spent time reading your
paper4. Use the reports to improve In this job one
needs a thick skin
In this job oneneeds a thick skin
43UCb
To Remember
Our currency is reputation. It takes a lot of hard work and (scientific) socal skills to build one, but it takes very little to destroy it
Try to evaluate your own work using the standards you apply to somebody else’s, but do not be your own worst enemy.