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

This topic: SE > WebHome > ThesesHome > ThesisConcurrencySaros
Topic revision: 10 Oct 2013, PatrickSchlott