Friedrich-Alexander-Universität UnivisSuche FAU-Logo
Techn. Fakultät Willkommen am Department Informatik FAU-Logo
Logo I4
Lehrstuhl für Informatik 4
Betriebssystemtechnik
 
  Vorlesung
    - UnivIS-Infos
    - Inhalt
    - Voraussetzungen
    - Prüfungen
    - Folien
 
  Übungen
    - Inhalt
    - Tipps
       * Teamarbeit mit svn
       * Tools
       * AOStuBS-System
    - Aufgaben
       * A 1
       * A 2
       * A 3
       * A 4
       * A 5
       * A 6
       * A 7
 
  Evaluation
Department Informatik  >  Informatik 4  >  Lehre  >  SS 2008  >  Betriebssystemtechnik  >  Übungen  >  Aufgabe 2

Aufgabe 2: Domänenanalyse

Lernziele

  • Praktische Anwendung der in der Vorlesung gelernten Techniken zur Domänenanalyse
  • Kenntnisse über die Funktionen und Möglichkeiten der Zielplattform (GameBoy Advance)
  • Präsentation und Diskussion der Ergebnisse für die jeweilige Teildomäne

Aufgabenbeschreibung

In dieser Aufgabe soll als Gemeinschaftsprojekt für unsere Domäne "AOStuBS - Eine Betriebssystemfamilie für den GameBoy Advance" eine Domänenanalyse durchgeführt werden.

Ausgabetermin Vorgabe Abgabetermin + Präsentation (!)
24.04.2008 LaTeX-Grundgerüst im OSE-Repository (siehe unten) 08.05.2008, 16:00 (Präsentation)

Bearbeitung

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):

  1. Festlegung, welche Domäne überhaupt modelliert werden soll
  2. Sammeln relevanter Informationen über die Domäne
  3. Erstellung eines Domänenmodells

Das Domänenmodell dokumentiert sozusagen die Ergebnisse der ersten beiden Schritte und besteht aus folgenden Teilen:

  1. Domänendefinition: Eine textuelle Abgrenzung der zu modellierenden Domäne
  2. Domänenlexikon: Definition aller relevanter Begriffe der Domäne
  3. Konzeptmodelle: Eine informell textuelle oder auf geeigneten Modellierungstechniken beruhende Beschreibung der relevanten Konzepte der Domäne, ihrer Zusammenhänge und Abhängigkeiten
  4. Merkmalmodell: Eine strukturierte Darstellung der wiederverwendbaren und konfigurierbaren Eigenschaften der Systeme der Domäne
Das Domänenmodell soll in einem LaTeX-Dokument beschrieben werden, das mit SVN versionsverwaltet wird. Dabei soll schon während der Bearbeitung der Aufgabe häufiger mal mit dem Repository synchronisiert werden ("update" und "commit"), damit die jeweiligen Gruppen auch Abhängigkeiten zwischen den Features ihrer Domäne und den anderen Domänen zuordnen können (siehe unten). Domänenanalyse ist ein iterativer Prozess - es ist am Anfang normal, dass man häufig alles ändert.

Vorträge

Damit jeder ein tieferes Verständnis für das Gesamtmodell erhalten kann, ist außerdem pro Teildomäne ein Kurzvortrag (ca. 5-10 Min.) zu halten. Die Kurzvorträge sollen in der Übung am 08.05.2008 gehalten werden.

Abgabe

Die Aufgabe läuft über zwei Wochen. Damit ihr eine Chance habt, frühzeitig Rückmeldung zu eurer Analyse zu bekommen, erfolgt die Abgabe iterativ in mehreren Schritten.

  1. Eine erste Version, die mindestens schon mal die Domänendefinition, das Domänenlexikon und das Merkmalmodell enthält, muss bis zum 30.04.2008, 8:00 (Mittwochmorgen) abgegeben werden (durch "commit" in das Repository). Wir erwarten nicht, dass zu diesem Zeitpunkt bereits vollständige Merkmalbeschreibungen und Konzeptmodelle vorliegen, aber wir sollten bereits einen guten Eindruck bekommen können. Je nach Bedarf vereinbaren wir dann ggf. Besprechungstermine mit einzelnen Gruppen, voraussichtlich am Montag, den 05.05.2008.
  2. Die endgültige Version der Domänenanalyse wird dann bis zum 08.05.2007, 8:00 (eine Woche später) abgegeben.
  3. Die Vortragsfolien solltet ihr Christoph mindestens 24 Stunden vor dem Vortragstermin (also am Mittwoch) als PDF-Dokument schicken.

Zielplattform, Dokumentation

Die Zielplattform ist, wie bereits mehrfach erwähnt, der GameBoy Advance. Dazu und zu dem verbauten ARM-7-Prozessor gibt es einige Informationen im Netz; hier eine kleine Liste:

Teildomänen

Im Rahmen dieser und der folgenden Aufgaben soll die Betriebssystemfamilie AOStuBS entstehen. Die Gesamtdomäne, die von den Systemen am Ende abgedeckt werden soll, wurde von uns in Teildomänen zerlegt. Die Zuordnung der Arbeitsgruppen zu Teildomänen ist der folgenden Tabelle zu entnehmen. Jede Gruppe hat einen Koordinierungsbeauftragten, der für die Koordination mit den anderen Gruppen zuständig ist und für diese als primärer Ansprechpartner dient.
(Teil-)Domäne Gruppe
d1-app
d2-display
Philipp Caliebe
Matthäus Chajdas
Johannes Held
Michael Zollhöfer
d3-sound Jörg Brendel
Christian Brunner
Andreas Oetken
d4-com Andre Frimberger
Dimitrij Kotrev
Christopher Mutschler
Die fett gedruckten Personen sind die Koordinierungsbeauftragten.

Zur Koordinierung haben wir auch eine Mailingliste eingerichtet: ose-2008 BEI i4.informatik.uni-erlangen.de

Erläuterungen zu den vorgeschlagenen Teildomänen

Um die Variations- und damit Konfigurationsmöglichkeiten eurer AOStuBS-Domäne auszuloten, müsst ihr euch zumindest teilweise an der Zielplattform orientieren. Deswegen ist ein Studium des entsprechenden Teils der Plattformdokumentation (siehe oben) unumgänglich.

Es folgen Beschreibungen für die einzelnen vorgeschlagenen Teildomänen; diese Beschreibungen sind jedoch nur als Anregung zu sehen und sollen eure eigene Kreativität nicht einschränken!

Domäne app

Die Domäne app beinhaltet die eigentliche Applikation für das resultierende AOStuBS-System; auch die Applikation sollte skalierbare Features im Sinne des Produktlinienansatzes aufweisen. Naheliegend bei der verwendeten GBA-Plattform ist die Entwicklung eines (simplen) GameBoy-Spiels; als Ausgangspunkt kann das von Olaf für OOStuBS programmierte "Pacmännchen" dienen, ihr könnt aber natürlich auch andere Spiele portieren und untersuchen oder eigene Spielideen verwirklichen.

Diese Domäne ist der treibende Faktor für die anderen Domänen, da sie von den angebotenen Features direkt abhängt! Die entsprechende Gruppe wird daher implizit die technische Leitung des Gesamtprojekts an sich ziehen.

Domäne display

Diese Domäne umfasst das Output-Medium "GBA-Display". Die (konfigurierbaren) Merkmale dieser Domäne können sich teilweise an den Möglichkeiten der Hardware orientieren (Dokumentation siehe oben). Dazu gehört z. B. ein simpler Textmodus genauso wie ein ausgefeilterer Graphikmodus, der z. B. Tiling verwendet. Dazwischen lassen sich sicher noch sehr viele feinere Abstufungen definieren, die sich dann auf die Skalierbarkeit des Teilsystems auswirken, aber wahrscheinlich auch auf die angebotene API.

Wichtig ist, dass ihr euch mit den Entwicklern der Domäne app auseinandersetzt, um über benötigte Merkmale zu reden und euch auf sinnvolle Schnittstellen zu einigen.

Domäne sound

Die angebotenen akustischen Systemeinrichtungen werden von der Domäne sound abgedeckt. Der GBA bietet verschiedene Möglichkeiten zum akustischen Output an (Dokumentation siehe oben), darunter synthetisierte Töne, aber auch Wave-Output. Zusätzliche Variationsmöglichkeiten im Implementierungsumfang bieten sich durch softwareseitige Funktionalitäten. Dazu gehört die Klasse der Audiofilter, wie z. B. (konfigurierbare) Hall-Effekte.

Domäne com

Die Domäne com umfasst die Kommunikationsmöglichkeiten der Plattform mit gleichartigen anderen Plattformen. Zu möglichen Variationspunkten gehören synchrone/asynchrone Kommunikationsschnittstellen, die verwendeten Protokolle mit den zugehörigen Eigenschaften, oder die Möglichkeit zum Multiplexen von mehreren Anwendungsverbindungen z. B. über ein Port-Konzept. Außerdem lassen sich Primitiven zur lokalen und zur entfernten Interprozesskommunikation (IPC) anbieten.

Weiteren Spielraum bieten die verschiedenen Kommunikationsmodi, die vom GBA angeboten werden (Dokumentation siehe oben).

Domäne thread

Die Domäne thread beinhaltet die Threading-Fähigkeiten von AOStuBS. Eine Konfiguration könnte z. B. keinen Threadsupport vorsehen, sodass die Anwendung implizit einfädig entwickelt werden muss. Falls Threadsupport aktiviert ist, lässt sich z. B. der Scheduler variieren; hier geben klassische Betriebssystemlehrbücher einiges her. Variationspunkte sind z. B. (Nicht-)Präemptivität (und damit die Notwendigkeit einer Timeransteuerung), die Schedulingstrategie (falls sich die Unterschiede zwischen ihnen bei der Applikation bemerkbar machen!), oder die Synchronisationsmöglichkeiten innerhalb der Anwendung.

Repository-Organisation

Alle Dokumente zur Domänenanalyse (und später auch dem Entwurf) sollen im Projektverzeichnis unter doc/<my-domain>/ gespeichert werden. Dazu "checkt" ihr das Repository am besten zunächst mal aus:

wanja@faui48a>svn co --username wanja https://www4.informatik.uni-erlangen.de:8088/i4ose/ose-2008
wanja@faui48a>cd ose/doc/

In diesem Verzeichnis findet ihr dann ein Unterverzeichnis <my-domain>/, in dem sich jeweils die Datei <my-domain>.tex befindet. Das ist eure Vorgabe. Das jeweilige Unterverzeichnis <my-domain>/fig ist für etwaige Abbildungen gedacht. Weitere Informationen zum Umgang mit SVN (Login, Hinzufügen von Dateien, "committen", etc.) findet ihr auf der Tools-Seite.

Da das händische Malen von Merkmaldiagrammen recht aufwändig ist, integriert die Vorgabe bereits das LaTeX-pst-featdiag-Paket von Georg Blaschke. Das Merkmaldiagramm wird als LaTeX-Code eingegeben. Weitere Informationen dazu gibt es in der Übung, einiges findet sich auch noch mal in Schriftform auf der Tools-Seite.

Zusätzlich stellen wir Euch als Hilfestellung eine (relativ) vollständige Domänenanalyse bereit, die als Beispiel dienen soll. Sie behandelt die aus der Vorlesung bekannte Wetterstation. Die Analyse findet ihr unter doc/examples/. Sie dient als Richtschnur für Stil und Umfang einer Domänenanalyse.

Da es sich bei AOStuBS um ein Gemeinschaftsprojekt handelt, soll das Ergebnis der Domänenanalyse ein einzelnes PDF-Dokument mit allen Teildomänen sein. Die Teildomänen-spezifischen LaTeX-Dokumente werden dazu von einem gemeinsamen Master-Dokument (doc/aostubs.tex) eingebunden. Ihr solltet eure Sektionen mit Labels versehen, so dass andere Gruppen (z. B. für Merkmalabhängigkeiten) auf diese verweisen können. Wir empfehlen deshalb, häufig ein svn update bzw. svn commit durchzuführen, damit ihr im Blick behaltet, was die anderen Gruppen so treiben.

  Impressum Stand: 2008-04-25 20:31   DL, WH