Analyse und Verbesserung der Architektur eines nebenläufigen und verteilten Softwaresystems

worked on by: Patrick Schlott

Outline

In dieser Arbeit geht es darum die Nebenläufigkeitseigenschaften von Saros als Gesamtsystem zu analysieren und einige dabei gefundene Probleme zu beheben. Der Fokus liegt dabei auf der Datensicherheit von nebenläufig verwendeten Ressourcen. Darüber hinaus sollen die Nebenläufigkeitseigenschaften von Saros dokumentiert werden, um nachfolgenden Entwicklern die Arbeit zu erleichtern und den Umgang mit nebenläufigen Programmabläufen zu vereinheitlichen.

In dieser Arbeit wird nach einem iterativen, spezifikationsgetriebenen Ansatz vorgegangen. Dabei wird die Analyse anhand einer System-Spezifikation durchgeführt.

Um diese Spezifikation aufzustellen, wird zunächst eine grobe Version erstellt. Anhand dieser ersten Spezifikation können dann Nebenläufigkeitseigenschaften definiert werden. Anschließend werden diese Eigenschaften mit dem existierenden System verglichen. Dabei gefundene Unstimmigkeiten werden behoben oder dokumentiert. Mit dem erlangten Wissen kann dann wiederum die Spezifikation erweitert werden, um neue Eigenschaften aufzustellen, die analysiert werden können.

Auf diese Weise können sowohl Dokumentation als auch Implementierung fortwährend verbessert werden, sodass sich beide immer weiter annähern.

Bei der Erstellung der Spezifikation wird dabei konkret nach dem Vorbild des in "The 4+1 View Model of Architecture" [1] beschriebenen Verfahrens vorgegangen. Dabei wird das Softwaresystem von unterschiedlichen Standpunkten aus betrachtet, um so eine möglichst umfassende Spezifizierung des Systems zu ermöglichen, ohne die einzelnen Artefakte/Diagramme zu überladen.

Da es bei dieser Arbeit um Nebenläufigkeiten geht wird der Fokus auf dem Logical-View und dem Process-View liegen. Der Logical-View dient dabei dazu die funktionalen Top-Level-Komponenten des Systems herauszuarbeiten. Anhand dieser Komponenten wird dann der Process-View erstellt, in dem den logischen Komponenten Aufgaben zugeordnet werden und die Nebenläufigkeitseigenschaften dieser Aufgaben spezifiziert werden.

Die Entwicklung der Views wird von Szenarien vorangetrieben. Dazu werden zunächst die wichtigste Szenarien (Kern-Use-Cases) in Saros formuliert und anhand dieser werden die Views erstellt. Wenn das geschehen ist, werden die Views mit dem vorhandenen System abgeglichen und Unstimmigkeiten herausgearbeitet. Wenn das geschehen ist, werden neue Szenarien hinzugenommen und die Spezifikation wird an diese neuen Szenarien angepasst.

Thesis Requirements

• Analyse der Nebenläufigkeitseigenschaften in Saros
• Beheben von Nebenläufigkeitsproblemen in Saros
• Dokumentation der Nebenläufigkeitseigenschaften in Saros

[1] Philippe Kruchten, "The 4+1 View Model of Architecture," IEEE Software, vol. 12, no. 6, pp. 42-50, Nov. 1995, (Online: http://www.computer.org/csdl/mags/so/1995/06/s6042-abs.html)

Meilensteinplanung

A milestone is a scheduled event signifying the completion of a major deliverable or a set of related deliverables. A milestone has zero duration and no effort -- there is no work associated with a milestone. It is a flag in the workplan to signify some other work has completed. Usually a milestone is used as a project checkpoint to validate how the project is progressing and revalidate work. (Source: http://www.mariosalexandrou.com/definition/milestone.asp)

Nr.	Status	Zeitraum	Bis KW	Aufgaben	Ergebnis
Vorarbeiten
1		-	KW14	Masterarbeit anmelden
2a		April 13	KW18	Vorgehen festlegen
2b		April 13	KW18	Erste Version der Spezifikation erstellen
Laufende Session untersuchen
3a		Mai/Juni 13	KW23	Architektur definieren
3b		Mai/Juni 13	KW23	Analyse von Nebenläufigkeitseigenschaften
3c		Mai/Juni 13	KW23	Möglichkeiten zur Verbesserung beschreiben
Einladungsprozess
4a		Juni/Juli 13	KW27	Architektur definieren
4b		Juni/Juli 13	KW27	Analyse von Nebenläufigkeitseigenschaften
4c		Juni/Juli 13	KW27	Möglichkeiten zur Verbesserung beschreiben
Implementierung
5		Juli 13	KW28	List gefundener Probleme aufstellen und zu behandelnde Probleme festlegen
6		Juli 13	KW31	Ausgesuchtes Problem a behandeln
7		August 13	KW35	Ausgesuchtes Problem b behandeln
Schriftliche Ausarbeitung
8		September 13	KW37	Erste Version der Arbeit fertig
9		September 13	KW39	Finale Version der Arbeit fertig
10		Oktober 13	KW40	Abgabe der Arbeit