Betriebssystemtechnik (OSE) - SS 2005

Aufgabe 5: Implementierung 1

Mit dieser Aufgabe beginnt die Implementierungsphase für AO-Stubs, 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.

Lernziele

• Umgang mit pure::variance
• Einarbeitung in das initiale AO-Stubs (der OO-Stubs Port für H8)
• Sammeln von ersten Erfahrungen mit der RCX Hardware und den eingesetzten Tools

Bearbeitung

Die Bearbeitung erfolgt wieder in der Gruppe. Für euer jeweiliges Subsytem von AO-Stubs 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), 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).

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

Für die Bearbeitung der Aufgaben könnt ihr auch die L4 manlobbie nutzen, in der drei Linux-PCs mit angeschlossenen RCX-Towern stehen (zum Flashen bzw. Kommunizieren mit der Hardware) sowie diverse SunRays. Außerdem stehe ich am Dienstag und Mittwoch(7./8. Juni) von 10:00-11:00 in der manlobbie für Fragen und Hilfestellungen zur Verfügung.

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. Bis zur nächsten Übung (9.6.) soll aber auf jeden Fall ein funktionsfähiges Featuremodell und ein einfaches Komponentenmodell vorhanden sein, mit dem man auch schon mal etwas generieren kann.

Die Übung am 9.6. findet als Rechnerübung im CIP-Pool 0.0156 statt. Sie dient der Koordination der Arbeiten, etwaiger Hilfestellung und als zusätzliche Bearbeitungszeit. Die Teilnahme ist, wie bei der Tafelübung, verpflichtend. (Koordination funktioniert nun mal nur dann, wenn alle dabei sind...)

Die Übung am 16.6. findet wie gewohnt im Aquarium (0.031) statt. Bis zu diesem Zeitpunkt sollen Featuremodell und Komponentenmodell "fertig" und die Komponenten zumindestens als Rumpfklassen vorhanden sein. In der Übung stellt jede Gruppe dann kurz den geplanten Implementierungsumfang ihres Subsystems vor (anhand der pure::variance-Modelle, ihr braucht keine Folien vorzubereiten). Dabei soll dann geklärt werden, ob wichtige Features fehlen und wo bislang unerkannte Abhängikeiten existieren.

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::variance Dokumentation: Die pure::variance Doku 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".