|
|
 |
|
Betriebssystemtechnik (OSE) - SS 2006
Aufgabe 2: Domänenanalyse
In dieser Aufgabe soll für einen Teilbereich unserer Domäne "AO-Stubs - Eine Betriebssystemfamilie
für RCX" eine Domänenanalyse durchgeführt
werden.
| Ausgabetermin |
Vorgabe |
(spätester) Abgabetermin + Präsentation |
| 11.05.2006 |
OSE_Vorgabe2.tgz
(Zur Vorgabe siehe auch Hinweise unten)
|
22.5.2006 (normalerweise Vorlesungstermin) |
Lernziele
- Praktische Anwendung der in der Vorlesung gelernten Techniken zur Domänenanalyse.
- Kenntnisse über die Funktionen und Möglichkeiten des RCX (Zielplattform).
- Präsentation und Diskussion der Ergebnisse für die jeweilige Teildomäne.
Bearbeitung und Abgabe
Auch die Bearbeitung dieser Aufgabe erfolgt wieder gruppenweise.
Das ist dieses Mal auch besonders wichtig, da viel diskutiert werden
sollte.
Zu einer Domänenanalyse gehören drei Schritte (siehe Vorlesungsfolien):
- Festlegung, welche Domäne überhaupt modelliert werden soll.
- Sammeln relevanter Informationen über die Domäne.
- Erstellung eines Domänenmodells.
Das Domänenmodell dokumentiert sozusagen die Ergebnisse der
ersten beiden Schritte und besteht aus folgenden Teilen:
- Domänendefinition: Eine textuelle Abgrenzung der zu
modellierenden Domäne.
- Domänenlexikon: Definition aller relevanter Begriffe der Domäne.
- Konzeptmodelle: Eine informell textuelle oder auf geeigneten
Modellierungstechniken beruhende Beschreibung der relevanten Konzepte
der Domäne, ihrer Zusammenhänge und Abhängigkeiten.
- Feature-Modell: Eine strukturierte Darstellung der
wiederverwendbaren und konfigurierbaren Eigenschaften der Systeme
der Domäne.
Das Domänenmodell soll in einem PDF-Dokument beschrieben
werden, das mit svn (Subversion) versionsverwaltet
wird. Dabei soll schon während der Bearbeitung der Aufgabe
häufiger mal hochgeladen (commit) und aktualisiert (update) werden, damit die jeweiligen Gruppen auch
Abhängigkeiten zwischen den Features ihrer Domäne und den
anderen Domänen zuordnen können (weiteres dazu siehe unten). Domänenanalyse ist
ein iterativer Prozess - es ist am Anfang normal, dass man häufig
alles ändert.
Damit jeder einen Eindruck
von dem Gesamtmodell erhalten kann, ist außerdem pro
Teildomäne ein Kurzvortrag
(ca. 5-10 Min.) im Rahmen des Vorlesungstermins am 22.5. zu halten. Die
Vortragsfolien solltet ihr mir mindestens einen Tag vor
dem Vortrag (Abgabetermin) als PDF Dokument schicken.
Anwendungsfälle und Anforderungen
Damit ihr euch bei der Domänenanalyse nicht "im Feature-Dschungel verliert",
haben wir ein paar Anwendungsfälle und weitere Anforderungen
zusammengestellt. Beachtet bitte, dass es nicht Aufgabe ist die
Anwendungen selber zu implementieren, sondern aus den
Anwendungsbeschreibungen die Anforderungen an das Betriebssystem zu ermitteln (z.B.
benötigte Geräte, Multithreading, Speicherverwaltung usw.)
Diese Anforderungen könnt ihr als feature
starter set verwenden, welches
den absoluten Mindestumfang der späteren AO-Stubs
Betriebssystemproduktlinie darstellt. Ihr sollt aber auch noch
weitere Features identifizieren und beschreiben. Behaltet dabei jedoch
die angestrebte Zielplattform und insbesondere das Ziel der
"Skalierbarkeit nach oben und unten" im Blick.
Zielplattform
Die Zielplattform ist, wie bereits mehrfach erwähnt, der RCX-Baustein
des Lego MINDSTORMS. Zu dieser Plattform findet ihr tonnenweise
Informationen im Netz. Einen guten Einstieg bietet die
Informationssammlung zu Mindstorms
von Stephan Höhrmann an der Uni Kiel.
Anwendungsfall 1: Tresor
Mit dem RCX soll ein "Tresor" aus
Legosteinen gebaut werden, dessen Tür vom Motor nur dann
geöffnet wird, wenn der Benutzer sich korrekt authentifizieren
kann. Zur Authentifizierung dient eine Streifenkarte, die mithilfe des
Lichtsensors gelesen wird. Die Streifenkarte enthält eine Art
Barcode, bestehend aus mehreren schwarzen Streifen von
unterschiedlicher Breite und mit jeweils unterschiedlichem Abstand. Die
folgenden Funktionen werden unterstützt:
- Abschließen: Der Tresor ist im Zustand offen.
Der Benutzer kann nun eine Streifenkarte durch den Lichtsensor ziehen,
um den Tresor zu schließen. Das System "merkt" sich die
Streifenkarte und geht in den Zustand geschlossen.
- Aufschließen: Der Tresor ist im Zustand geschlossen.
Der Benutzer kann nun eine Streifenkarte durch den Lichtsensor ziehen
um den Tresor zu öffnen. Wenn die Streifenkarte mit derjenigen
übereinstimmt, die zum Schließen des Tresors verwendet wurde
(d.h. gleiche Anzahl von Streifen mit der jeweils richtigen Breite und
dem jeweils richtigen Abstand zum nächsten), so geht der Tresor in
den Zustand geöffnet.
Andernfalls wird ein Fehlerton ausgegeben und der Tresor bleibt im
Zustand geschlossen.
Anwendungsfall 2: Fernsteuerung für RCX
Mit Hilfe eines RCX-Bausteins A soll ein anderer RCX-Baustein B
über die
Infrarotschnittstelle ferngesteuert werden. Sei B ein RCX, der eine
beliebige Anwendung (z.B. einen autonomen Roboter) implementiert. Es
ist nun möglich, mit den Knöpfen von A Kommandos
Start, Stop, Schneller, Langsamer
an B zu senden. B quittiert jedes Kommando. Der Benutzer
erhält auf dem Display von A eine Rückmeldung, ob sein
Kommando angekommen ist. Weitere Anforderungen sind:
- RCX A (Fernsteuerung):
Das zugrundeliegende System soll minimal bzgl. seiner
Ressourcenanforderungen sein, um die Fernsteuerung später
möglichst kostengünstig fertigen zu können.
- RCX B (Roboter): Die Fernsteuerfunktionalität soll weitestgehend
unabhängig von
der eigentlichen Anwendung des Roboters sein. Im Idealfall muss der
Anwendungscode nicht geändert werden um das Feature
"Fernsteuerung" hinzuzufügen.
Anwendungsfall 3: Raumerkundung mit verteilten Agenten
Eine Menge N von RCX-basierten Robotern wird
eingesetzt und einen Raum systematisch zu kartographieren. Dazu werden
die einzelnen Roboter von einem Fixpunkt F (Raumeingang) aus in
unterschiedliche Richtungen losgeschickt. Mit Hilfe des
Kollisionssensors werden Hindernisse erkannt und auf der internen Karte
vermerkt. Sobald der Raum vollständig erkundet
ist oder der für die Karteninformationen zur Verfügung
stehende
Speicher voll ist, bewegt sich ein RCX zurück zu Punkt F. Für
die Zusammenarbeit der verschiedenen RCX gibt es dabei zwei Varianten:
- Variante 1: Stößt ein RCX
auf einen anderen RCX, so findet über die Infrarotschnittstelle
ein Austausch der Karteninformationen statt sowie eine Aufteilung der
noch verbleibenden Arbeit.
- Variante 2: Wie Variante 1, jedoch
findet zusätzlich eine Speicheroptimierung statt. Nach dem
Austausch der Karteninformationen und der Aufteilung der verbleibenden
Arbeit sind sämtliche Karteninformationen ja doppelt (d.h. in
beiden RCX) vorhanden. Als dritter Schritt findet deshalb eine
Aufteilung der Karte statt. Jeder RCX merkt sich nur die für ihn
relevante Hälfte der Karteninformationen und gibt den Speicher
für alle anderen Kartenteile wieder frei.
Sonstige Anforderungen an AO-Stubs
Neben den oben genannten Anwendungsfällen gibt es noch einige weitere
Anforderungen, die zu berücksichtigen sind:
- Unterstützung von Echtzeit-Anwendungen: AO-Stubs soll auch für
harte Echtzeitanwendungen eingesetzt werden
können. Dieses ist natürlich insbesondere als Variante
für den Scheduler zu berücksichtigen, betrifft aber auch alle
anderen Subsysteme. Für jedes Subsystem muss es eine Konfiguration
mit deterministischen Laufzeitverhalten geben, so dass eine WCET (worst
case execution time) berechnet werden kann.
- Entwicklungsunterstützung: Um die Entwicklung
sowohl des Betriebssystems als auch von Anwendungen einfacher zu
machen, soll AO-Stubs optionale Debugging-Features bereitstellen. Dazu
zählen z.B. Ablaufverfolgung (tracing), Konsistenzprüfungen oder
Stapelüberlaufkontrolle.
Teildomänen
Im Rahmen dieser und der
folgenden Aufgaben soll die Betriebssystemfamilie AO-Stubs entstehen. Die
Gesamtdomäne, die von den Systemen am Ende abgedeckt werden soll,
wurde von uns in der letzten Übung in Teildomänen
zerlegt. Die Zuordnung der Arbeitsgruppen zu Teildomänen ist der
folgenden Tabelle zu entnehmen. Jede Gruppe soll einen Koordinierungsbeauftragten benennen,
der für die Koordination mit den anderen Gruppen zuständig
ist und für diese als primärer Ansprechpartner dient.
Repository-Organisation und Vorgabe
Repository-Organisation
Alle Dokumente
zur Domänenanalyse sollen im Projektverzeichnis unter doc/analysis/<my-domain>/
gespeichert werden.
Dazu checked ihr das Repository am besten zunächst mal aus und
fügt ein Verzeichnis für eure Teilgruppe hinzu, unter dem ihr
alle Quelldateien für euer Domänenmodell speichern könnt:
lohmann@faui48>svn co --username lohmann https://www4:8088/i4ose/ose-2006/trunk ose-2006
lohmann@faui48>cd ose-2006/doc/analysis
lohmann@faui48>mkdir debug
lohmann@faui48>svn add debug
lohmann@faui48>svn commit
Das eigentliche
PDF-Dokument soll direkt im doc/analysis Verzeichnis landen.
Das Namensschema für die PDF-Dateien ist d1-debug.pdf,
d2-stdlib.pdf usw.
Weitere Informationen zur Verwendung von svn findet ihr auf der Tools Seite.
Vorgabe
Da das händische Malen von Feature-Diagrammen recht aufwändig ist,
empfehlen wir die Verwendung von LaTeX mit dem pst-featdiag
Package von Georg Blaschke. Alternativ kann man damit auch nur die Feature-Diagramme
selbst in LaTeX beschreiben und als EPS-Abbildungen in andere
Textsysteme einbinden. Die Vorgabe
enthält dazu
Vorlagen für LyX und LaTeX. Weitere Informationen zu pst-featdiag
findet ihr auf der Tools Seite. Die Vorgabe
enthält auch schon eine grobe Gliederung für ein
Domänenmodell, aber die könnt ihr natürlich nach
Herzenslust erweitern. Und wer sich so gar nicht mit LyX oder LaTeX
anfreunden mag, der kann natürlich auch Word, OpenOffice oder
wasauchimmer verwenden. Hauptsache am Ende kommt PDF raus :-)
|
|
|
|
