 |
Betriebssystemtechnik (OSE) - SS 2006
Diese Seite wird gerade bearbeitet!
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.
| Ausgabetermin |
Vorgabe |
(spätester) Abgabetermin |
| 28.06.2006 |
Das initale AO-Stubs System |
05.07.2006 |
| 28.06.2006 |
Präsentation der Ergebnisse |
06.07.2006 |
Lernziele
- Umgang mit pure::variants
- 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:
-
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.
-
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.
-
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 AO-Stubs System auszuschecken und auszuprobieren. Als nächstes können dann Featuremodell und Komponentenmodell sukkzesive 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 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.
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 6.7.2006 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 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".
|
|
