Das "a", zweiter Teil (Bachelorarbeit oder Studienarbeit)
Dies ist die Fortsetzung einer Bachelorarbeit aus dem Jahr 2009,
die das selbe Thema hatte, aber nur die Hälfte davon abgearbeitet hat.
Worum geht es hier?
Angenommen, Sie haben auf einem Linux-Rechner die Anwendung
OpenOffice Writer mit einem leeren Dokument geöffnet
und betätigen nun die Taste "A" auf Ihrer Tastatur.
Das Zeichen "a" erscheint auf dem Bildschirm.
Preisfrage: Was ist seit dem Tastendruck intern in der Software alles abgelaufen?
Die Aufgabe dieser Arbeit besteht darin, eine verständliche und anschauliche
Beschreibung (samt geeigneter visueller Übersichten) dieser Abläufe anzufertigen:
- Welche Subsystemen/Funktionseinheiten/Komponenten/Module sind an der Abarbeitung des Tastaturereignisses beteiligt?
- Wie spielen sie hier zusammen?
- Was ist darüber hinaus allgemein deren Rolle?
- Was läuft im vorliegenden Fall konkret in ihnen ab? (Die wichtigsten Unterprogrammaufrufe und Erläuterung ihrer Bedeutung)
Zweck der Arbeit
Die Beschreibung soll zu verschiedenen Zwecken verwendet werden:
- In der Vorlesung "Softwaretechnik" als ein Beispiel zur Illustration einer komplexen Softwarearchitektur, das einmal vorab ausführlich eingeführt wird, und auf das man sich im Verlauf der Veranstaltung immer mal wieder beziehen kann zur Verdeutlichung verschiedener Ideen und Probleme in den Bereichen Architektur, Modularität, Qualitätssicherung, Wiederverwendung und Projektmanagement.
- Für einen Vortrag, der sich an Laien richtet, um ihnen zu verdeutlichen, wie ungeheuer komplex moderne Software ist (und dass sie, daran gemessen, z.B. gar nicht unzuverlässig, sondern im Gegenteil verblüffend zuverlässig ist).
Arbeitsweise
Diese Arbeit hat zwei Aspekte:
- Herausfinden des Ablaufs
- Darstellen des Ablaufs
Herausfinden des Ablaufs
Das Herausfinden erfordert jemanden, der sich am wohlsten fühlt, wenn er oder
sie in Massen von Quellcode quasi baden kann: Die Arbeit gibt die
Gelegenheit, einige Teile des Linux-Betriebssystemkerns (geschrieben in C)
aus der Nähe kennen zu lernen, ferner einige Teile von X-Windows (ebenfalls
C), KDE (C++) und natürlich
OpenOffice (Java).
Aber man
kann die Teile nicht nur kennen lernen, man
muss es auch.
Es wird vermutlich nötig sein, die Software geeignet zu instrumentieren und
dann selbst zu übersetzen, damit man die Abläufe von außen dynamisch
verfolgen kann und nicht darauf angewiesen ist, seinen Weg durch den
Quellcode durch Lesen ganz alleine zu finden.
Eine Reihe kniffliger technischer Detailprobleme wird zu bewältigen sein,
z.B.: Wie läßt man das Fenstersystem im Debugger laufen, um die Abläufe zu
verfolgen, wenn der Debugger selbst seine Ausgaben über dieses Fenstersystem
anzeigen soll? (Lösung ist vermutlich: Debugger auf einem zweiten
X-Window-Server anzeigen).
Es gilt hier, herauszufinden:
- Welche einzelnen Softwareroutinen werden in welcher Reihenfolge aufgerufen?
- Welche Argumente werden Ihnen übergeben und was bedeuten Sie?
und dabei unwichtige und vor allem wiederholte Aufrufe so weit auszublenden,
dass man nicht in Informationen ertrinkt.
Hat man dies geleistet, geht es ans Darstellen dieses Ablaufs.
Darstellen des Ablaufs
- In der Rohversion sollte man jeden verbliebenen Aufruf durch eine kurze Erläuterung beschreiben
- In der langen Schriftform fasst man diese Aufrufe soweit in Gruppen zusammen, dass die einzelnen Funktionsbausteine (Module) in ihren Aufgaben noch erkennbar bleiben, deren Innenleben aber zusammengefasst wird.
- In der kürzeren Form wird daraus ein Foliensatz, der nur noch so viel Detail enthält, dass man ihn in ca. 60 Minuten vortragen kann und dabei auch ohne Vorkenntnisse über die Systeme ein Verständnis für deren Aufbau und Funktionsweise erwirbt. Hierzu sollte auch eine schematische Visualisierung (vermutlich ein Kästchen-und-Pfeile-Bild) als eine Art Skelett für die Erklärung entwickelt werden und dann auf verschiedenen Detailniveaus in Ausschnitten und Varianten immer wieder auf den Folien zum Einsatz kommen.
Die eigentliche Studien- oder Bachelorarbeit, die man abgibt, besteht zum Großteil aus diesen obigen Dokumenten, plus zusätzlich einer Beschreibung des Vorgehens, wie man zu ihnen gelangt ist.
Grundsätzliches
Wie war das bitte mit Teil 1?
Diese gleiche Arbeit wurde bereits 2009 ausgeschrieben und von
FranzZieris erfolgreich durchgeführt.
Die Ergebnisse sind in
seiner Ausarbeitung
nachzulesen (siehe auch
ThesesHome).
Sie waren gut und sollen weiterverwendet werden, aber es gibt noch einige Bereiche
des Ablaufs, die darin kaum oder gar nicht beschrieben sind.
Diese Lücken zu füllen ist der Zweck von
Das "a", Teil 2
.
FranzZieris ist inzwischen in unserer Gruppe wissenschaftlicher Mitarbeiter
und würde die Arbeit hauptsächlich betreuen.
Meilensteine
Nr. |
Zeit |
|
KW |
Aufgaben |
Ergebnis |
1a |
|
23.01.13 |
KW4 |
X: Event-Erstellung dokumentieren |
Vollständig |
1b |
|
30.01.13 |
KW5 |
X: Event-Verarbeitung dokumentieren |
Vollständig |
2a |
|
06.02.13 |
KW6 |
Übergang Kernel → X dokumentieren |
Vollständig |
2b |
|
13.02.13 |
KW7 |
Übergang X → OO dokumentieren |
|
3 |
|
13.03.13 |
KW11 |
Ausgabe (von OO auf den Bildschirm) dokumentieren |
|
4 |
|
17.04.13 |
KW16 |
Verarbeiten der gesammelten Daten |
|
Nur eine kleine Anmerkung: der Java-Anteil in
OpenOffice ist (leider? glücklicherweise?) unglaublich gering! Siehe dazu
http://www.ohloh.net/p/openoffice/analyses/latest und
http://www.inf.fu-berlin.de/inst/ag-se/teaching/S-BSE/160_zieris-dasA-thesis.pdf, Seite 18 (Folien der Abschlusspräsentation)
--
FranzZieris - 30 Jun 2011