 |
Betriebssystemtechnik (OSE)
-SS 2005
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 |
| 28.04.2005 |
OSE_Vorgabe2.tgz
Verbesserte Version vom 29.4.05
(Zur Vorgabe siehe auch Hinweise unten)
|
11.5.2004
16:00 (also am Mittwoch vor
der Übung) |
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 der Tafelübung zu halten. Die
Vorträge finden in der Übung am 12.5. statt. 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-2005/trunk ose-2005
lohmann@faui48>cd ose-2005/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-thread.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 :-)
|
|
