Betriebssystemtechnik (OSE) - SS 2003
Aufgabe 3: Domänenentwurf
In dieser Aufgabe soll die Implementierung der Programmfamilie
weitgehend geplant werden. Außerdem wird die Abbildung von
Features auf Implementierungskomponenten festgelegt und mit Hilfe von
Consulat durchgeführt.
Ausgabetermin |
Vorgabe |
(spätester) Abgabetermin |
19.05.2003 |
-- |
02.06.2003 |
Bearbeitung und Abgabe
Die Bearbeitung erfolgt wieder in der Gruppe. Abzuliefern ist bis zum
o.g. Datum ein PDF Dokument, das eine funktionale Hierachie graphisch
zeigt und die Funktionen kurz beschreibt. Darüber hinaus sind
Klassenskelette und eine Consulat Komponentenbeschreibung zu
erstellen. Beides muss in das für die Entwicklung der
OSE-Systemfamilie genutzte CVS-Repository eingecheckt werden. Die
Bearbeitung sollte auf den manlobbi Rechnern erfolgen.
Hinweise zum Erstellen von funktionalen Hierarchien und zum Finden
einer Klassenstruktur kommen weiter unten. Hier wird zunächst die
Struktur und Benutzung des CVS-Repositories erläutert.
CVS Entwicklungsumgebung
CVS ist ein Versionsverwaltungssystem für Dateien, das das
gemeinsame Arbeiten vieler Entwickler am selben Projekt erlaubt, ohne
dass diese sich versehentlich gegenseitig ihre Änderungen kaputt
machen. Dazu werden alle Dateien des Projekts in einem zentralen
Verzeichnisbaum - dem Repository - gespeichert. Die Entwickler können
sich ein lokale Kopie "auschecken". Wenn Änderungen gemacht
wurden, werden diese von den Entwicklern "eingecheckt" und stehen dann
allen anderen zur Verfügung. Um Änderungen anderer in die
lokale Kopie aufzunehmen, kann man diese "aktualisieren". Um eine neue
Datei CVS bekannt zu machen, muss man sie "hinzufügen".
Eine ausführliche Beschreibung der CVS Kommandos findet man auf
der CVS Homepage. Hier das
für euch wichtigste in Kürze:
- Auschecken:
cvs -d /proj/i4bs/ose-cvs checkout
ose-a
bzw. ose-b
.
- Aktualisieren:
cvs update -d
.
- Hinzufügen:
cvs add Dateiname
oder Verzeichnisname
.
- Einchecken:
cvs commit -m "mein Kommentar zur
Aenderung"
.
Die Kommandos wirken sich jeweils auf das aktuelle Verzeichnis und
Unterverzeichnisse aus.
Die Struktur des ose-a bzw. ose-b Verzeichnisbaums ist nach dem
Auschecken wie folgt:
ose-X
Makefile
-- damit kann man zur Zeit eine Consulat
Projektdatei und eine Doku generieren
doc
html
-- hier landet die generierte Doku (index.html)
pure.dsc
-- Beispiel für eine Komponentenbeschreibung
sys
-- hier finden sich die verschiedenen
Subsystemquelltexte
comm
Fadenkommunikation und -synchronisation: G2 (ose-a) bzw. G9 (ose-b)
debug
Debugging und Monitoring: G1 (ose-a) bzw. G12 (ose-b)
driver
Gerätetreiberx: G5 (ose-a) bzw. G10 (ose-b)
init
Systeminitialisierung: Olaf
int
Unterbrechungsbeh. und -sychronisation: G6
lib
Container- und E/A-Bibliothek: G3 (ose-a) bzw. G11 (ose-b)
mem
Speicherverwaltungsstrategien: G4 (ose-a) bzw. G13 (ose-b)
platform
Übersetzungsumgebung: Olaf
thread
Fadenverwaltung und -umschaltung: G7 (ose-a) bzw. G8 (ose-b)
configured
-- hier landet der konfigurierte Code
Die Verzeichnisse init
, plaform
und
int
sind bei ose-a und b identisch. Jede Gruppe darf nur
Dateien einchecken, die in ihrem eigenen Verzeichnis liegen. Ihr
solltet aber von Zeit zu Zeit aktualisieren, um zu sehen, was die
anderen machen, insbesondere, wenn euer Subsystem von dem anderen
abhängt.
Die funktionale Hierarchie
Funktionale Hierachien werden in der Vorlesung behandelt. Sie zeigen
die zu implementierenden "Funktionen" (nicht im Sinne von C/C++,
sondern allgemein) und deren Abhängigkeiten. Die Struktur ist per
Definition nicht zyklisch, meistens ein Baum. Wenn doch zyklische
Beziehungen zwischen den identifizierten Funktionen auftauchen, hilft
meist Verfeinerung und das Bilden eines "Sandwiches" (->VL).
Die funktionale Hierarchie wird schrittweise verfeinert, bis die
Implementierung jeder Funktion durch eine oder wenige Klassen bzw. C
Funktionen realisitisch erscheint.
Für die Abgabe erwarte ich ein PDF Dokument mit der funktionalen
Hierachie, wobei man die Verfeinerungen komplexer Funktionen in separate
Bilder auslagern kann. Die Funktionen sollten kurze Namen haben und
nachfolgend in wenigen Sätzen erläutert werden.
Die Klassenhierachie
Oft lassen sich die Funktionen einer funktionalen Hierarchie und deren
Abhängigkeiten direkt durch Klassen und Vererbung implementieren:
Angenommen Funktion A benötigt Funktion B, dann kann das durch
eine Klasse A, die von B erbt, umgesetzt werden. Damit wird
automatisch auch der Zugriff auf Basisklassen von B erlaubt, was in
der funktionalen Hierarchie ebenso vorgesehen ist. Das Weglassen von
Funktionen erfolgt auf der Implementierungsebene, indem die Anwendung
nicht eine Blattklasse instanziiert, sondern sich eine
Klasse auf beliebiger Ebene herausgreift. Damit wird automatisch ohne
weitere Konfigurierungmaßnahmen Code eingespart.
Eine sture Umsetzung des gerade beschriebenen Entwurfsschemas
würde bedeuten, dass es nur Vererbungsbeziehungen zwischen den
Klassen geben dürfte. In einigen Fällen lässt sich die
Variabilität, die das Feature Modell ausdrückt, so aber
nicht umsetzen.
Wenn z.B. A auf eine statisch festgelegte Variante von B zugreift
bietet sich ein Klassenalias an (a). Klassenaliase werden durch
Generierung entsprechender typedefs von Consulat direkt
unterstützt. Wenn von B mehrere Instanzen existieren können
und die Beziehung von A Objekten auf diese Instanzen flexibel zur
Laufzeit umgesetzt werden soll, bietet sich (b) an. Variante (c) sieht
eine abstrakte Schnittstelle zwischen A und beliebigen Varianten von B
vor. Diese Variante verbraucht die meisten Ressourcen und sollte,
falls das dynamische Binden nicht wirklich nötig ist, in unserem
Kontext vermieden werden.
Das Ausdrücken von Features durch Klassenaliase und die Auswahl
zu übersetzender Klassen beeinflusst nicht die
Übersichtlichkeit des Codes. Wenn sich aber Features nur durch
Konfigurieren innerhalb einer Klasse realisieren lassen, sollen #ifdefs und
Präprozessorflags benutzt werden. Consulat kann anhand von
Features entsprechende Flags generieren. Der Name der Flags selbst und der
generierten Dateien, in denen sie definiert werden, sollte mit "fame"
beginnen (wichtig!).
Die Klassen sollen als Skelette, d.h. ohne Funktionsrümpfe,
eingegeben (und eingecheckt!) werden. Daraus kann man dann automatisch
eine Dokumentation generieren. Das geht mit 'make doxy' im ose-X
Verzeichnis. Das Ergebnis landet unter doc/html und kann z.B. mit dem
konqueror betrachtet werden. Bitte beschreibt eure Klassen mit
Kommentaren und beachtet die Konventionen des benutzten doxygen Systems (-> manual,
documenting the code).
Für Klassen, die ihr euch von anderen Subsystemen
wünscht, sollte ihr ebenfalls (in eurem Verzeichnis) ein Skelett
anlegen. Die Klassen sollten "XSubsystem_Name", also
z.B. XCOMM_Semaphore, heißen. Bitte checkt eure Änderungen
häufig ein und seht euch frühzeitig an, was die anderen
für euch bereitstellen bzw. was sie von euch erwarten.
Die Komponentenbeschreibung
Zum Abbilden von Features auf Implementierungsmodule (hier Komponenten
genannt) benötigt Consulat eine "Komponentenbeschreibung" (Endung
.dsc). Wie diese Aussehen muss ist im Consulat Manual (F1 Hilfe) kurz
beschrieben. Ich habe euch außerdem ein Beispiel unter
doc/pure.dsc eingecheckt, das alles Wesentliche abdecken sollte. Eure
Beschreibung müsst ihr in eurem Verzeichnis unter
Subsystemname.dsc ablegen.
Um experimentieren zu können, ob ein Feature zur Auswahl der
richtigen Komponenten führt, müsst ihr außerdem euer
Feature Modell unter Subsystemname.fm ablegen. Wechselt dann ins
ose-X Verzeichnis und ruft make
auf. Daraufhin erzeugt
das Makefile ein Consulat Projekt, indem es alle
Komponentenbeschreibungen zu einer verbindet und eine Projektdatei
generiert, die alle Feature Modelle referenziert. Dann wird
automatisch Consulat gestartet. Dort seht ihr die Feature Modelle
aller Subsysteme (sofern eingecheckt) und könnt Features beliebig
selektieren. Wie ihr an der Feature Liste seht, landen alle Feature in
einem Namensraum. Konflikte bitte schnell bereinigen. Wenn ihr den
Menüpunkt "Always regerate" selektiert, könnt ihr unter
"Configured Components" sehen, wie sich die aktuelle Feature Auswahl
auf die Komponenten und ihre Teile auswirkt. Wenn alles richtig ist,
kann mit "Generate" ein Übersetzungsbaum erstellt werden, der
die generierten Dateien und Links auf den zu übersetzenden Code
enthält.
Achtung: Wenn ihr die Komponentenbeschreibung ändert, muss
Consulat verlassen und mit make
neu gestartet werden.
Übrigens: Ich habe eine neue Consulat Version
installiert. Das Bearbeiten der Feature Modelle ging jetzt gut.
Noch was
Bitte beginnt, indem ihr den Entwicklungsbaum auscheckt und dort euer
Feature Modell eincheckt. Generell solltet ihr möglichst oft
aktualisieren und eure Änderungen einchecken. Damit bekommen die
anderen und hoffentlich auch ihr schneller einen Eindruck, ob die
Arbeiten der Gruppen irgendwie zusammenlaufen.