1. Scientific Writing Some personal observations Kim Guldstrand Larsen UCb

2. 2 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 SPIN visualSTATEUPPAAL

3. UCb 3 A very complex system Klaus Havelund, NASA

4. UCb 4 Spectacular Software Bugs z ARIANE-5 z INTEL Pentium II floating-point division 470 Mill US $ z Baggage handling system, Denver 1.1 Mill US $/day for 9 months z Mars Pathfinder z Radiation theraphy, Therac-25 z …….

5. UCb 5 Embedded Systems z80% of all existing software is embedded in interacting devices. zDemand on increasing functionality with minimal resources.

6. UCb 6 How? Unified Model = State Machine! a b x y a? b? x! y!b? Control states Input ports Output ports

7. UCb 7 Tamagotchi A C Health=0 or Age=2.000 B PassiveFeeding Light Clean PlayDisciplineMedicine Care Tick Health:=Health-1; Age:=Age+1 A A A A A A A A Meal Snack B B ALIVE DEAD Health:= Health-1

8. UCb 8 Digital Watch Statechart=UML, David HAREL

9. UCb 9 SYNCmaster

10. UCb 10 SPIN, Gerald Holzmann AT&T

11. UCb 11 visualSTATE zHierarchical state systems zFlat state systems zMultiple and inter- related state machines zSupports UML notation zDevice driver access VVS w Baan Visualstate, DTU (CIT project)

12. UCb 12 UPPAAL Larsen et al

13. UCb 13 Tool Support TOOL 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,..

14. UCb 14 Tool Support TOOL 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

15. Writing Scientific Paper(s)

16. UCb 16 Collaboration Arne 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

17. UCb 17 Writing a Paper / Papers 1.Work on a (relevant) CS question 2.Write a scientific paper 3.Submit the paper to an appropriate journal/conference 4.If accepted then 1.Add one line to CV 2.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.

18. UCb 18 What is a Scientific Paper zA scientific paper is a written and published report describing original research results zPrimary Publication, i.e. ythe first publication of original research results yrepeatable and testable yavailable xTechnical report/web (I/we did it [first]) xConference paper (It works, it’s neat, and there is more to come) xJournal xTextbooks or research monographs 93 32 (10) BRICS DBLP Bib Server BRICS DBLP Bib Server

19. UCb 19 Why Do People Write Papers? zIdealist: Any scientific paper furthers our knowledge of the field. It is a contribution to the community of our peers. zRealist: 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).

20. UCb 20 ww.citeseer.com ……….. 558. M. Lee: 1510 559. M. Maher: 1509 560. J. Jaffar: 1505 561. J. Lenstra: 1504 562. A. Swami: 1503 563. Z. Li: 1502 564. S. Hammarling: 1502 565. G. Stewart: 1499 566. D. Shmoys: 1499 567. K. Larsen: 1495 568. J. White: 1494 569. G. Winskel: 1493 570. L. Stockmeyer: 1491 571. X. Wang: 1491 The 10.000 most cited CS authors out of 629.254 The 10.000 most cited CS authors out of 629.254 … 521. J. Ferrante: 1882 522. M. Lee: 1882 523. A. Cox: 1878 524. R. Needham: 1878 525. J. Foley: 1877 526. F. Glover: 1877 527. K. Larsen: 1873 528. T. Dietterich: 1872 529. J. Kubiatowicz: 1871 530. D. Lenoski: 1871 531. S. Geman: 1870 532. D. Gelernter: 1869 533. J. Kramer: 1869 534. Y. Yang: 1861

21. UCb 21 www.citeseer.com ContextContext 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. ContextDoc 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. Context 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. ContextDoc 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: ContextDoc "UPPAAL in a nutshell". To appear: International Journal on Software Tools for Technology Transfer, Springer Verlag, September 1997. ContextContext 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. ContextDoc 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. Context 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. ContextDoc 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: ContextDoc "UPPAAL in a nutshell". To appear: International Journal on Software Tools for Technology Transfer, Springer Verlag, September 1997.

22. UCb 22 www.citeseer.com

23. UCb 23 www.citeseer.com

24. UCb 24 www.citeseer.com

25. UCb 25 How to write a scientific paper zThe main message: The preparation of a scientific paper has almost nothing to do with literary skill. It is a question of collaboration and organization. zRule of Thumb: In your presentation, follow a logical progression from problem to solution.

26. UCb 26 Typical Organization zTitle / List of authors / Abstract zIntroduction / compelling example / related work / overview zDevelopment zConclusion (if any) zAcknowledgments / references

27. UCb 27 Title zIt should be informative zIt should be concise zIt should be catchy / memorable zIt is best original, but it does not need to be funny zThe title is a label, not a sentence

28. UCb 28 Title – examples  Gérard Boudol, Kim G. Larsen: ``Graphical versus Logical Specifications''  Kim G. Larsen, Arne Skou: "Bisimulation Through Probabilistic Testing“ zKlaus Havelund, Kim G. Larsen: ``The Fork Calculus'' zK.G. Larsen, F. Laroussinie, C.Weise: ``From Timed Automata to Logic – and Back''

29. UCb 29 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'' zG. Behrmann, K. G. Larsen, R. Pelanek: “To Store or Not to Store.”

30. UCb 30 The List of Authors zAlphabertically ordered zOrdered by degrees of contribution zStudent first, supervisor second zAny other scheme zI have almost always used alphabetical order.

31. UCb 31 Authorship and Credits zAn 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.

32. UCb 32 Introduction zA bad beginning makes a bad ending zFACT: 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.

33. UCb 33 Introduction zIt should present and motivate first, and in all possible clarity, the nature and scope of the problem investigated. zIt should review related literature (to orient reader and please reviewer). zClearly state achievement of paper zOverview the rest of the paper zA compelling example is always good. zLink to the Introduction during the remainder of the paper.

34. UCb 34 Pitfalls zExaggeration zSeeking the effect for the sake of seeking effect: “this paper bridges a much need gap”. zMisspelling (always use a splel-checker)

35. UCb 35 How to Present Your Results zTechnical preliminaries/background (setting the scene) zProgressive development of the material (organized in logical sections). zRemember to state where your contribution lies. zAnticipate, and answer, the possible questions that a reader might have.

36. UCb 36 How to Present Your Results zPresent your results in as logical a way as possible. If reader needs A to understand B, then first present A, then B. zAlways introduce technical terms before using them.

37. UCb 37 On Formalization zPrimary objective is clarity: be as formal as it takes to make your point – but no more!! zLift your results to the most abstract/general level – I.e. convey main technique rather than mathematical fiddling.

38. UCb 38 Related Work zMandatory zSituates the novelty and significance of your work. Answers at least the questions: ywhere do the ideas come from? yhave similar ideas been published earlier ywhat is really new in the paper zWhere: introduction or conclusion or stand- alone.

39. UCb 39 Conclusion zOption 1: None zOption 2: Minimal yrecapitulate problem and the contribution yassesses the significance of the contribution youtline of future work

40. UCb 40 Submission The Actors zAuthor(s) zEditor(s) / program committee members zThe referees zThe intended audience, and zTime

41. UCb 41 Review zThe task of a referee is to evaluate in a timely manner a paper for publication (in journal or conference proceedings) zEvaluation / Critical Judgment zTimeliness

42. UCb 42 Receiving a Referee Report Before reading a referee report 1.Take a deep breath 2.Remember that a good report is always valuable 3.somebody spent time reading your paper 4.Use the reports to improve In this job one needs a thick skin In this job one needs a thick skin

43. UCb 43 To Remember zOur 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 zTry to evaluate your own work using the standards you apply to somebody else’s, but do not be your own worst enemy.