Scientific Writing Some personal observations

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.