Friedrich-Alexander-Universität UnivisSuche FAU-Logo
Techn. Fakultät Willkommen am Department Informatik FAU-Logo
Logo I4
Lehrstuhl für Informatik 4
Betriebssystemtechnik
 
  Vorlesung
    - UnivIS-Infos
    - Inhalt
    - Voraussetzungen
    - Prüfungen
    - Folien
 
  Übungen
    - Inhalt
    - Tipps
       * Teamarbeit mit svn
       * Tools
       * AOStuBS-System
    - Aufgaben
       * A 1
       * A 2
       * A 3
       * A 4
       * A 5
       * A 6
       * A 7
 
  Evaluation
Department Informatik  >  Informatik 4  >  Lehre  >  SS 2008  >  Betriebssystemtechnik  >  Übungen  >  Aufgabe 5

Aufgabe 5: Implementierung (1)

Lernziele

  • Umgang mit pure::variants
  • Einarbeitung in das initiale AOStuBS (dem OOStuBS-Port für ARM)
  • Sammeln von ersten Erfahrungen mit der GBA-Hardware und den eingesetzten Tools
  • Erstellen eines Projektplans

Aufgabenbeschreibung

Mit dieser Aufgabe beginnt die Implementierungsphase für AOStuBS, die uns bis zum Ende des Semesters beschäftigen wird. In dieser Aufgabe geht es dabei zunächst um die Erstellung der benötigten pure::variants-Modelle und die Definition der Schnittstellen. Außerdem soll sich jede Gruppe einen Projektplan für die Implementierung überlegen.

Ausgabetermin Vorgabe Abgabetermin
05.06.2008 Das initiale AOStuBS-System im Repository 12.06.2008

Bearbeitung

Die Bearbeitung erfolgt wieder in der Gruppe. Für euer jeweiliges Subsystem von AOStuBS soll erstellt werden:

  1. Das pure::variants-Featuremodell (Problemraum), in dem die Features selektierbar sind, die ihr implementieren wollt. Dabei sollen auch die entsprechenden Abhängigkeiten und Konflikte modelliert werden.
  2. Das pure::variants-Komponentenmodell (Lösungsraum; auch Familienmodell genannt), in dem die Zuordnung der einzelnen Features zu ihren Implementierungskomponenten erfolgt und weitergehende Transformationen (wie z. B. das Übernehmen von Attributen in ein ps:flagfile oder Generieren von Klassenaliasen mit ps::classalias) durchgeführt werden.
  3. Der Rumpf der jeweiligen Implementierungskomponenten (als leere Klassen bzw. Funktionen) sowie die Beschreibung der wichtigsten Schnittstellen (im Quellcode mit doxygen).
Am besten beginnt ihr damit, das initiale AOStuBS-System auszuchecken und auszuprobieren. Als nächstes können dann Featuremodell und Komponentenmodell sukzessive verfeinert werden. Für letzteres müssen die bestehenden Implementierungskomponenten entsprechend aufgeteilt und entkoppelt werden bzw. neue Komponenten hinzugefügt werden.

Das Endziel ist eine feingranualar konfigurierbare BS-Familie. Für die Gruppen, deren Arbeit auf den bestehenden Subsystemen in AOStuBS aufsetzt, bedeutet dieses, dass sie sich auch eine Menge Gedanken darüber machen müssen, welche Teile des ehemaligen OOStuBS sie wie übernehmen wollen und welche nicht. Auch bezüglich der Schnittstellen ist das wichtig. Will heißen: OOStuBS ist ein guter Ausgangspunkt, aber bitte die bestehenden Strukturen nicht einfach "blind" übernehmen.

Projektplan

Außer den Feature- und Familienmodellen sollte jede Gruppe in doc/aostubs.tex einen kleinen Projektplan entwickeln. Darin sollten für jede Woche grobe Teilziele festgehalten werden und einzelne Arbeitspakete jeweils verantwortlichen Personen zugeordnet werden.

Abgabe

Die Abgabe erfolgt (logischerweise) durch häufiges Einchecken ins Repository. Das ist insbesondere deshalb wichtig, da ihr ja euch auch zwischen den Gruppen austauschen müsst. Ihr müsst für die Abgabe nicht bei uns persönlich erscheinen. Dafür müsst ihr aber eure Lösung in der Übung am 12.06.2008 kurz vorstellen. Folien sind nicht nötig. Es reichen die pure::variants-Modelle und darauf basierend eine Beschreibung der erreichten Variabilität und mit welchen Techniken ihr diese im Code umsetzt.

Weitere Hinweise

  • Namenskonventionen für Features: Für Features werden englische Bezeichner verwendet. Damit es keine Konflikte gibt, soll außerdem der "unique name" jeweils das Subsystems als Präfix erhalten. Also z. B. guard_locking oder mem_global_heap.
  • pure::variants-Dokumentation: Die pure::variants-Dokumentation ist in das Hilfesystem von Eclipse integriert und dazu da, benutzt zu werden :).
  • Doxgen-Dokumentation: Die Dokumentation zu doxygen findet sich unter http://www.doxygen.org/. Dort findet sich auch eine Kurzübersicht über die wichtigsten "documentation blocks".
  Impressum Stand: 2008-06-06 12:22   OS, WH