Software Engineering Group

Open and Running Theses

  Thema Betreuer
  Abschlussarbeiten im Kontext des Open Source Projekts Kieker Monitoring Framework: siehe auch Liste der offenen Themen kieker-logo
     
Konstruktion und Evaluation eines Code-Generator-Ansatzes mit CoCoME Reiner Jung
Vergleich von Modell-basierten Pointcut-Spezifikationsansätzen Reiner Jung
Entwicklung einer Methode zur Bestimmung der Trace-Funktion eines Code-Generators Reiner Jung
     
Konzeption und Implementierung eines Systemabhängigkeitsgraphen für C#/C++-Applikationen auf Basis des Quelltextes Christian Wulf
  Transformation von Neo4J-basierten Systemabhängigkeitsgraphen zu C#/C++-Code Christian Wulf
  Effektives Laufzeitmanagement von P&F Architekturen durch Verwendung von Stage-Metadaten Christian Wulf
  Compare Apache Storm with TeeTime (Bachelorarbeit) Christian Wulf
  Compare Apache MapReduce with TeeTime (Bachelorarbeit) Christian Wulf
  Automatic Field Privatization using PARROT Christian Wulf
  Automatic Refactoring with the Null Object Pattern using PARROT Christian Wulf
  Automatic Annotating Class State Properties using PARROT
(@Cache, @FileAccess, @NetworkAccess, @ReductionVariable, @Immutable)
Christian Wulf
  Pattern Mining in Open Source Apps for Parallelization Christian Wulf
  Metrics for Detecting Parallelism Potential in Source Code
(Self-Parallelism)
Christian Wulf
  A Hardware-Sensitive Performance-Test Framework for Java
(Assertion for Time Intervals, Hardware-based Time Interval)
Christian Wulf
  Automatic Detection of Design Patterns via Static & Dynamic Analysis
(Observer, Strategy, ...)
Christian Wulf
  Automatic Detection of Performance Anti-Patterns via Static & Dynamic Analysis
(Accessive dynamic allocation [of strings], Memory leaks: less frees than mallocs, ...)
Christian Wulf
  A Java Code Generator for System Dependence Graphs Christian Wulf
  Automatic Detection of Parallelizable Arrays using PARROT
(Annotating with do-all/do-across)
Christian Wulf
     
  Design and Implementation of a Kieker Monitoring Writer for ExplorViz Christian Zirkelbach
  Instrumenting Android Applications in ExplorViz Christian Zirkelbach
  Instrumenting Javascript Applications in ExplorViz Christian Zirkelbach

 

Die obige Liste an Themen ist nicht erschöpfend. Für weitere Themen wenden Sie sich bitte direkt an die jeweiligen Mitarbeiter.

Außerdem sind eigene Vorschläge Willkommen!

Running Theses

Thema Betreuer des Themas
Monitoring of Distributed Systems with Kieker
(Distributed Trace Reconstruction, Feasibility & Performance Evaluation, Profiling Plugin Extension)
Christian Wulf
Adding Java 7 and 8 Support for PARROT
(using ExtendJ, evaluate with several open-source programs)
Christian Wulf
Conception and Implementation of Distributed Pipe-and-Filter Architectures
(DSL for Nodes, Approach for Communication (TCP, ...), Fault-tolerance)
Christian Wulf
   

Student Theses

Useful Hints

Hinweise für das wissenschaftliche Schreiben

Pdf-Download

Vorgehen und Hinweise für Seminararbeiten

Pdf-Download

Vorgehen und Hinweise für Abschlussarbeiten

Pdf-Download

Latex-Vorlage (deutsch und englisch) für Proposals, Abschlussarbeiten und Präsentationen

Link zu den Vorlagen

 

Was hat ein Proposal mit einem Entwicklungsprozess zu tun?

Grundsätzlich spielt der Entwicklungsprozess eine zentrale Rolle in der Softwaretechnik. Daher geben wir hier einige Hinweise zum Entwicklungsprozess bei der Betreuung von Abschlussarbeiten in der Arbeitsgruppe Software Engineering.

Prinzipiell kann das Verhältnis zwischen Arbeitsgruppe und Studentin/Student mit dem Verhältnis zwischen Kunden und Software-Häusern verglichen werden. Daher wird im folgenden die Studentin/der Student als Software-Haus und die Arbeitsgruppe als Kunde bezeichnet.

Zunächst wird eine ca. einseitige Anforderungsbeschreibung durch den Kunden erstellt (entspricht einem Aushang). Dann schreibt das Software-Haus ein Pflichtenheft (entspricht dem Proposal für das Abschlussarbeitsvorhaben). Dieses Pflichtenheft muss vom Kunden abgenommen werden. Nach Ablieferung des Produkts (entspricht der Abgabe der Abschlussarbeit) wird dieses gegen das Pflichtenheft geprüft und beurteilt (entspricht der Note).

Der Vorteil eines expliziten Pflichtenheftes besteht für das Software-Haus darin, dass es klar sein sollte, was genau zu tun ist, damit das Produkt fertig ist. Der Kunde kann dann nicht noch nachträglich weitere Anforderungen stellen. Für den Kunden besteht der Vorteil darin, zu wissen, was von der Arbeit zu erwarten ist.

Bekanntermaßen ist dieses starre Vorgehen natürlich nicht praktikabel, so dass es gelegentlich zu Neuverhandlungen bzgl. der im Pflichtenheft festgelegten Ziele kommen kann.

Guidelines for seminars and student theses

If you have any comments, questions or additions, please contact Willi Hasselbring

Fundamentally, these guidelines apply to any scientific work conducted in the Software Engineering Group (and many hints apply to (scientific) writing in general), whether you write a seminar paper, an individual project / Bachelor thesis, or a Diploma/Master thesis. These differ primarily in the amount of time available, the expected length of the text and of the degree of novelty of the work. In the following, we will refer to any piece of work as a “paper”. These are only general guidelines, in specific seminars or for your specific thesis, additional or different guidelines may be arranged.

Guidelines for writing a paper or thesis

Structure


Please follow the following coarse-grain structure:

  1.     Title page containing topic, author, name of university, school, department and group, supervisor(s), date
  2.     Abstract
  3.     Table of contents
  4.     Introduction, making clear motivation and explaining structure of paper
  5.     …
  6.     Conclusion, incl. critical reflection
  7.     Bibliography

 

Citing URLs


URLs should not be put into the text, but should rather be included as a footnote or in the bibliography. If the cited page is not another kind of document (e.g. a technical report), use the BiBTeX misc entry type. When you use a bibliography style that recognized the BiBTeX url field, put the URL into this field (otherwise the howpublished field of the misc entry type and the note field of other entry types may be used, in these cases put the url into a url{...} command. Please give the date of last access in the note field, or, if your BiBTeX supports it, in a dedicated field (e.g. lastchecked). Please use the DIN/EN 28601 date format YYYY-MM-DD.

Format (technical and layout requirements)


You should write your paper using LaTeX and BiBTeX. It is expected that you deliver the sources (including a BiBTeX .bib file) and a PDF version of your paper. You should not normally try to fiddle around with the layout LaTeX produces.

You can use the latex template provided at  thesis.zip for your paper.

Graphics/figures


For including graphics in your paper, you should use vector graphics (unless, of course, it is a screenshot or photo or the like) in the EPS or PDF format (caution: it is also possible to store bitmap graphics in these formats). Always put graphics into a figure environment, provide a proper caption and let LaTeX place the figure.

Literature search


The literature given by us is only considered as a starting point for your work. It is expected that you search for additional relevant literature on your own. The links given in the references for scientific work may help you.

Spell checking


Before submitting any version of your paper, use a spell checker!

Evaluation criteria


Your paper will be evaluated particularly for the following criteria.

  •     Originality (depending on the type of work)
  •     Understanding (you should make clear that YOU have understood the material presented)
  •     Understandability (it should be possible for others with an appropriate background, i.e. another CS student, to understand what you have written)
  •     Linguistic presentation (clear, systematic, stringent, understandable)
  •     Soundness
  •     Appropriate level of detail and overall length
  •     Grammatical and orthographical correctness
  •     Consistent use of terminology
  •     Technical presentation (layout, carefulness)
  •     Critical analysis of cited sources
  •     Independent work

 

Guidelines for conducting a presentation

General hints


You can prepare summary notes for yourself, but you are expected to talk freely. You should calcute 2 to 3 minutes time per slide. You should practise your talk in front of someone you know before the actual presentation. In this way, you can check if you know what you want to say for each slide, and your auditor can check if there is a main thread, most importantly, and give general comments on your presentation.

Layout

  •         Use the same general layout for all slides. Use a simple, clear layout.
  •         Use landscape orientation.
  •         Font size: at least 18pt
  •         Font family: use a Sans Serif Font (Verdana, Arial, Optima, Computer Modern Sans, …)
  •         Do not show more than 7 items in a list on slide. Do not show entire sentences.
  •         If possible, use graphics rather than text to present your content.

 

Structure


    The structure of the talk should be as follows:

  •         Title slide: Topic, Presenter
  •         Outline
  •         …
  •         Summary


    The talk should end with the summary slide, not with an additional “Questions?” slide, so the audience has time to read your summary while preparing questions. The coarse outline should either be visible on each slide in a small scale, or you should get back to the outline when switching between major parts of your talk, so the audience knows in which phase of your talk you are.

Scientific Work

Note:

Please also have a look at the guidelines for seminars and student theses in the Software Engineering Group.

 

Literature search

  • Citeseer (BiBTeX (must be used with great care), Fulltext, Citation)

  • Web of Science (Citation) (only from licensed IP addresses)


Some advice to pursue a PhD project

  • Advice for Finishing that Damn Ph.D. (PDF) by Daniel M. Berry

 

Publication venuesty



LaTeX and BiBTeX information

  • LaTeX help web pages, University of Florida (LaTeX and BiBTeX, HTML)

 

Some hints for (scientific) writing

  • James G. Paradis, Vanessa Zimmerman: “The MIT Guide to Science and Engineering Communication” – 2. edition. – Cambridge: The MIT Press, 2002. ISBN 0-262-66127-6. BIS nat 397 CO 3896,2. (in particular chapters 1, 3-6, 8-9, presentations: particularly ch. 15)

  • Fred D. White: “Communicating Technology: Dynamic Processes and Models for Writers” – Pearson Higher Education, 1996. ISBN 0-06-500508-2. (particularly chapters 6-7, focus on English language: chapters 8-9)

 

Specific English language information

  •  Michael Swan: “Practical English usage”. – 2. edition. – Oxford [u.a.] : Univ. Press, 1995. ISBN 0-19-431198-8 (hb) 0-19-431197-X (pb). BIS: S ang 201 LR 4083,2,1995,2 and N ang 201 BL 4116,2,1995,2 (hints on English language use, especially for non-native speakers)

Giving a talk/presentation

 

Reviewing a manuscript

  •     Alan Jay Smith, “The task of the referee,” IEEE Computer, April 1990, pp. 65-71, DOI 10.1109/2.55470 (PDF)

 

Upcoming Events

Research Projects

  • more...

     ExplorVizLogo160x37[1].png    iobserve-logo-small    logo-science20

     

    Future-Ocean-logo    kieker-logo       PubFlow

     

    teetime-logo  HOSST_Banner.jpg  CloudM!G 

Teaching