Friedrich-Alexander-Universität UnivisSuche FAU-Logo
Techn. Fakultät Willkommen am Department Informatik FAU-Logo
Logo I4
Lehrstuhl für Informatik 4
Betriebssystemtechnik
 
  Vorlesungsüberblick
  Voraussetzungen
  Skript
  Übungen
  Fragensammlung
  Schein, Prüfung
Department Informatik  >  Informatik 4  >  Lehre  >  SS 2003  >  OSE  >  Übung

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.

  Impressum   Datenschutz Stand: 2003-09-09 09:58   OS