Entwurfdok

Entwurfsdokument AirBrowser
Projektgruppe AirWeb
21.02.2001
1
Inhaltsverzeichnis
1. EINLEITUNG ......................................................................................................................................................... 3
1.1. ÄNDERUNGSÜBERSICHT ...................................................................................................................................... 3
1.2. ANLAGEN ............................................................................................................................................................ 3
2. STATISCHES MODELL ....................................................................................................................................... 4
2.1. OOD-KLASSEN ................................................................................................................................................... 4
2.2. GESAMTÜBERSICHT ............................................................................................................................................ 4
2.3. EINGABE – PACKAGE AWP.INPUT ........................................................................................................................ 6
2.3.1. Diagramm ................................................................................................................................................... 6
2.3.2. Schnittstelle ................................................................................................................................................. 6
2.3.3. Unterschiedliche Quellen ............................................................................................................................ 6
2.4. SOUND-TEILSYSTEM – PACKAGE AWP.SOUND ..................................................................................................... 7
2.4.1. Diagramm ................................................................................................................................................... 7
2.4.2. Übersicht ..................................................................................................................................................... 7
2.5. GUI UND INTERNET EXPLORER – PACKAGE AWP.VISUAL.................................................................................... 8
2.5.1. IEx-Schnittstelle .......................................................................................................................................... 8
2.5.2. GUI ............................................................................................................................................................. 8
2.6. DATENHALTUNG UND KONFIGURATION.............................................................................................................. 9
2.6.1. AWFile ........................................................................................................................................................ 9
2.6.2. AWProgramSetup........................................................................................................................................ 9
2.6.3. Datendatei ................................................................................................................................................... 9
2.7. STEUERUNG ...................................................................................................................................................... 12
2.7.1. Raumarten – AWRA .................................................................................................................................. 12
2.7.2. Slotarten – AWSA ...................................................................................................................................... 12
Diagramme der Slots I ........................................................................................................................................ 13
Diagramm der Slots II......................................................................................................................................... 14
2.8. GRAPHISCHE DIALOGE ...................................................................................................................................... 15
2.9. OPTIONSDIALOG ............................................................................................................................................... 15
3. DYNAMISCHES MODELL ................................................................................................................................ 16
3.1. USE CASES ........................................................................................................................................................ 16
3.1.1. Akteur – System ......................................................................................................................................... 16
3.1.2. Liste der Programmfunktionen ................................................................................................................. 16
3.2. PROGRAMMSTART............................................................................................................................................. 17
3.3. GRUNDSÄTZLICHE EREIGNISBEHANDLUNG ....................................................................................................... 17
3.3.1. Diagramm ................................................................................................................................................. 17
3.3.2. Beschreibung des Ablaufs ......................................................................................................................... 17
3.4. BLÄTTERN ........................................................................................................................................................ 18
3.4.1. Diagramm ................................................................................................................................................. 18
Verlaufsbeschreibung.......................................................................................................................................... 18
3.5. RAUMWECHSEL................................................................................................................................................. 19
4. SONSTIGES .......................................................................................................................................................... 20
4.1. INHALT.............................................................................................................................................................. 20
4.2. ENTWICKLUNGSUMGEBUNG.............................................................................................................................. 20
4.3. PROZEßDOKUMENTATION ................................................................................................................................. 20
4.4. QUALITÄTSSICHERUNG ..................................................................................................................................... 20
2
1. Einleitung
Aufbauend auf der Problem- und Anforderungsanalyse soll dieses Dokument festlegen, wie die
vorgegebenen Anforderungen realisiert werden sollen.
1.1. Änderungsübersicht
Datum
Kommentar
4.2.2001
Erste Version
15.2.2001
Erweiterte Version
21.2.2001
Schlußfassung
1.2. Anlagen
Zu diesem Dokument gehören folgende Anlagen:
-
Die per Javadoc erzeugten Methodenbeschreibungen zu den Klassendiagrammen
Die Formatierungskonventionen für den Javacode vom Prototypen
Noch zu beachten:
-
Anforderungsdefinition in der korrigierten Fassung vom 23.1.2001
Anlage zur Anforderungsdefinition 1 (Sounds und Slots)
Anlage zur Anforderungsdefinition 2 (Fortgesetzte Änderungen der Anf.-Def.)
3
2. Statisches Modell
2.1. OOD-Klassen
Die nachfolgenden UML-Klassendiagramme enthalten die objektorientierte Architektur des Programms.
Zunächst sollte hier auffallen, daß zusätzlich zur Namenskonvention des Prototypen alle Klassennamen
mit AW beginnen, um die Namen im Quelltext leicht von denen der Sprache Java unterscheiden zu
können. Das Programm wird in fünf Themenbereiche eingeteilt:
THEMENBEREICH
KLASSEN
Eingabe durch verschiedene Geräte
awp.input.AW*
Zentrale Steuerung, Datenhaltung und Konfiguration
awp.control.AW*
Sound
awp.sound.AW
GUI und Internet Explorer
awp.visual.AW*
Programmstart und Globales
awp.AW*
2.2. Gesamtübersicht
Eingetragen sind die Pakete und die wichtigsten Klassen, insbesondere die Schnittstellen(-Klassen) der Pakete.
4
awp.control
AWSlot
AWSA_EnterURL
...
AWSA_GoToExam ple
AWSA_Help
awp
6..9
AWGlobals
1
AWRoom
AWAirBrow ser
AWRA_Room Mark
AWRA_Room Main
AWRA_Room Program
n
AWURLHelper
1
AWProgram Setup
AWFlat
AWFile
1
1
1
1
AWController
1
1
1
1
AWSound
AWSound
AWSound
AWIExInterface
AWIExInterface
AWIExInterface
1
awp.sound
1
AWInput
AWInput
AWInput
1
AWMainWindow
AWMainWindow
AWMainWindow
awp.visual
1
1
awp.input
5
2.3. Eingabe – package awp.input
2.3.1. Diagramm
AWChangeDeviceEvent
AWMainWindow
AWKeyListener
AWController
AWMouseInputListener
AWUniEvent
AWEvSpeechCommand
AWJ3DJoystick
AWEvJoystick
AWSpeechHandler
2.3.2. Schnittstelle
Durch ein Eventkonzept wird versucht, die sehr unterschiedlich anzusprechenden Quellen von
Eingabesignalen zu vereinheitlichen. Zentaler Übergabepunkt an den Controller ist die Klasse AWInput,
die eine der Klassen AWUniEvent oder AWChangeDeviceEvent an den Controller übergibt.
Das bedeutet u. a., daß die Umrechung in logische Koordinaten und Aktionen in diesem Paket erfolgt.
2.3.3. Unterschiedliche Quellen
Maus- und Tastaturevents kommen bereits vom Java GUI und müssen nur weitergeleitet werden.
Der Joystick wird kontinuierlich von einem Java3D-Thread abgefragt, wobei jedesmal ein entsprechender
Event mit der aktuellen Position an den Controller geschickt wird.
Im Falle der Spracherkennung gibt es ein spezielles API, das sich ebenfalls leicht an dieses Eventkonzept
anpassen läßt.
6
2.4. Sound-Teilsystem – package awp.sound
2.4.1. Diagramm
AWSound
1
1
AWSndEffectProcessor
1
1
1
AWSndDistributor
1
1
1
AWSndListener
n
n
AWSoundA3D
AWSndVirtualSource
AWSndTextToSpeech
AWSndEffect
AWSndA3DEffect
AWSpeechEffect
AWSndEffect_Gain
AWSndEffect_Gain
AWSndEffect_Gain
A3D
Speech
2.4.2. Übersicht
Die Klassen zur Bearbeitung von Soundereignissen und der A3D-Schnittstelle entsprechen denen des
Prototyps. Nähere Informationen können der damals erstellten ausführlichen Dokumentation entnommen
7
werden. Die Aktivierung der Effekte und Zusammenstellung des Klangbildes der einzelnen Räume wird
im Gegensatz zum Prototypen nicht mehr von SoundScene-Managern, sondern von den Klassen im Paket
awp.control übernommen (liegt also ausserhalb des Sound-Pakets).
Neu hinzu kommt hier die Sprach-Engine, die entsprechend aufbereitete Text-Strings vorlesen kann.
2.5. GUI und Internet Explorer – package awp.visual
Der Controller hat Zugriff auf zwei Klasen in diesem Paket.
2.5.1. IEx-Schnittstelle
Die Schnittstelle von AWIExInterface stellt alle Funktionen zur Verfügung, die im AIRBrowser vom
InternetExplorer benötigt werden. AWIEx ist als Java-Interface realisiert, welches die benötigten
Funktionen definiert. Die Verwaltung einer dieses Inferface implementierenden Instanz liegt in den
Händen von AWMainWindow, da es sich um ein GUI-Element handelt.
Von der implementierenden Klasse gibt es auch noch eine Verbindung zum Kontroller in umgekehrte
Richtung. Der IEx unterrichtet den Kontroller davon, wenn er eine neue Seite dargestellt hat oder wenn er
gescrollt hat, durch Aufruf entsprechender Methoden im Kontroller.
2.5.2. GUI
Die Klasse AWMainWindow repräsentiert die graphische Oberfläche. Sie baut das Hauptfenster auf und
bettet den IEx ein. Außerdem ist hier die Verbindung zu den Input-Klassen, da hier die Event-Listener
angemeldet werden.
8
2.6. Datenhaltung und Konfiguration
2.6.1. AWFile
AWFile dient dazu, die Programmdaten ein- und auszulesen, und zwar sowohl für die Datendatei, die
Datei mit den Programmoptionen und die Datei mit den Markern.
AWFile liefert dabei strukturierte Information, im Prinzip unabhägig von der tatsächlichen Beschaffenheit
der persistenten Datei. Die Struktur der Übergabe orientiert sich an XML, deshalb besteht jeder Eintrag
(bzw. jede Zeile) aus einem Tag zusammen mit seinen Attributen und deren Werten. Dabei ist zu
beachten:
-
alle Tags und Attribute in Großbuchstaben
-
ein ununterbrochenes Textstück, d.h. ein Bereich, der nicht von „<>“ umschlossen ist, ist auch ein
Tag mit dem Text als Attributwert.
Beim Einlesen der Datendatei wird der Filehandle zwischen den Räumen und den Slots durchgereicht,
damit diese Objekte jeweils ihre Information dort auslesen; wenn sie dann auf ein End-Tag stoßen, geben
sie das Filehandle wieder an die übergeordnete Klasse zurück.
Die XML-Dateien müssen, damit normale Umlaue verstanden werden, folgende erste Zeile besitzen:
<?xml version="1.0" encoding="ISO-8859-1" ?>
2.6.2. AWProgramSetup
Die Klasse AWProgramSetup ist für die Programmoptionen zuständig. Sie kann also die
Programmoptionen laden und speichen sowie den Dialog realisieren und anschliessend die Informationen
an den Controller übergeben.
Der Dialog zum Einstellen der Programmoptionen s.u.
2.6.3. Datendatei
Die Datendatei ersetzt einen festimplementierten Teil, um während der Entwicklung leichter Änderungen
am Programmverhalten vorzunehmen
Die Datei besitzt folgendes Format (* = Mehrfaches Auftreten hintereinander möglich):
9
Datei
Beschreibung
<AIRWEB>
*
<DEFPOS ID=“<id>” X=”<x>” Y=”<y>” >
</DEFPOS>
Die Koordinaten der Hearcons.
<id> ist das Schlüsselwort (z.B. „R“)
für die POS-Tags in den SLOT-Tags
s. u.
<x> und <y> sind die Koordinaten des
Hearcons
*
<DEFSPEAKER ID=”<id>” USE=”<engine>” >
</DEFSPEAKER>
Die verschiedenen Stimmen.
<id> ist das Schlüsselwort (z.B. „F“)
für die SPEECH-Tags in den SLOTTags s. u.
<engine> ist die
Sprecherberschreibung
*
<LINKTYPE ID=“<bez>“ HREF=“<wav>“ >
</LINKTYPE>
Zuordnung Linkarten zu Geräuschen.
<bez> ist die Bezeichung der Linkart:
„OUTSIDE“, „VIEWBACK“,
„SHORT“, „MIDDLE“ „LONG“ (s.a
.Attribute des A-Tags in der
Inhaltssprache).
<wav> ist der Dateiname der
Sounddatei.
*
<MARKHINT HREF=“<wav>“ ></MARKHINT>
Alle möglichen Markergeräusche.
<wav> ist dier Dateiname der
Sounddatei.
<INNERRADIUS MIN=“<min>“ MAX=“<max>“ >
</INNERRADIUS>
Radius der Trefferfläche.
<min> und <max> sind die Minimalund Maxiumalwerte, die der Benutzer
wählen kann. <max> darf nicht größer
sein, als dass sich die Trefferflächen
zweier Hearcons überlappen.
<OUTERRADIUS MIN=“<min>“ MAX= “<max>“ > Radius, wo das Heracon zu hören ist.
</OUTERRADIUS>
<min> ist der Wert, falls der Benutzer
„Hearcons nicht in der Mitte hören“
wählt, und <max> falls der Benutzer
„Hearcons in der Mitte hören“ wählt.
*
<ROOM>
... (s.u.)
</ROOM>
Die Räume
</AIRWEB>
10
*
Datei
Beschreibung
<ROOM NAME=“<name>” >
<name> ist einer der Raumbezeichner
s.u., z.B. „RoomProgram“
<SLOT>
… (s.u.)
</SLOT>
Die Slots
</ROOM>
Datei
Beschreibung
<SLOT ID=”<id>” >
<id> ist eine der Slotarten s.u., z.B.
„MultipleForward“.
<POS ID=”<id>” ></POS>
Die Position dieses Hearcons.
<id> ist der mit dem DEFPOS-Tag
eingeführte Bezeichner.
<HINT HREF=”<wav>” ></HINT>
Das Geräusch dieses Slots.
<wav> ist der Dateiname der
Sounddatei.
<ICON HREF=“<icon>“ ></ICON>
Das Icon dieses Slots.
<icon> ist der Dateiname der
Bilddatei.
*
<SPEECH SAY=“<text>” SPEAKER=”<id>” >
</SPEECH>
Der Vorlesetext (Dieser Tag erscheint
z.B. beim Slottyp „MultipleForward“
mehrmals)
<text> ist der Text, der gelesen wird.
<id> ist das mit DEFSPEAKER
eingeführte Schlüsselwort.
*
<VOICE ID=“<id>“ ></VOICE>
Die verschiedenen Stimmen.
<id> ist das mit DEFSPEAKER
eingeführte Schlüsselwort.
</SLOT>
11
2.7. Steuerung
Für die spezifischen Aktionen der Räume und der Slots gibt es jeweils eine Klasse. Daraus ergeben sich
drei verschiedene Räume und 21 verschiedene Slots. Die spezielle Funktionalität eines Raums bzw. eines
Slots sind dort gebündelt. Dies steht im Gegensatz zum Prototypen, wo die speziellen Funktionalitäten im
Soundteilsystem, im GUI-Teil usw. angesiedelt waren.
Grundsätzlich gibt es folgenden Verlauf: AWController gibt eine Information an AWFlat, den Verwalter
aller Räume. Dieser verteilt die Information an alle relevanten Räume, also Söhne von AWRoom. Der
jeweilige Raum, Verwalter seiner Slots, gibt diese Information weiter an seine Slots. In der Instanz von
AWFlat, den Instanzen von Söhnen von AWRoom und den Instanzen von AWSlot werden dann die
Funktionalität „gemacht“.
Die 21 Slotarten sind untereinander nach ähnlichen Funktionaliäten gruppiert, so daß die gemeinsame
Funktionalität in der jeweilig gemeinsamen Oberklasse implementiert werden kann.
2.7.1. Raumarten – AWRA
Aus den Raumbezeichnern ergeben sich die Klassennamen für die Raumklassen-Klassen durch
voranstellen von „AWRA_, also z.B. aus „RoomMark“ wird die Klasse „AWRA_RoomMark“.
Bezeichner
Raum
RoomProgram
Programmraum
Default für maximaler Hörradius: Max.
RoomMain
Leseraum
Default für maximaler Hörradius: Min.
RoomMark
Markerraum
Default für maximaler Hörradius: Min.
2.7.2. Slotarten – AWSA
Jeder Slot hat eine eindeutige ID. Anhand dieser ID können die Slotaktionen bestimmt und ausgeführt
werden
Aus den Slotarten ergeben sich die Klassennamen für die Aktionen-Klassen durch Voranstellen von
„AWSA_“, also z.B. aus „MultipleForward“ wird die Klasse „AWSA_MultipleForward“.
Die Slotaktionen (ID) :
ChangeToTextroom
GoToReference
ChangeToProgramroom
GoToExample
ChangeToTextroomOrProgramroom
GoToStructure
EndAirweb
DeleteMarkerFromThisRoom
Help
GoToPreviousMarkedPage
EnterURL
GoToNextMarkedPage
ChangePreferences
JumpBack10Markers
SetMarkerMenu
JumpForward10Markers
MultipleBack
DeleteAllMarkersOfThisType
MultipleForward
ChangeToAllMarkerrooms
ChangeToOtherMarkerrooms
12
2.7.3. Diagramme der Slots I
AWSlot
AWSA_RoomChange
AWSA_ToFixed
AWSA_ToVariable
AWSA_ChangeToTextroom AWSA_ChangeToOtherMarkerroom s
AWSA_Dialog
AWSA_ChangeToProgram room
AWSA_ChangeToAllMarkerroom s
AWSA_ChangePreferences
AWSA_ChangeToTextroom OrProgram room
AWSA_EnterURL
AWSA_M ultiple
AWSA_GoTo
AWSA_MultipleBack
AWSA_MultipleForw ard
AWSA_GoToStructure
AWSA_GoToExam ple
AWSA_GoToReference
13
2.7.4. Diagramm der Slots II
AWSlot
AWSA_DeleteM ark
AWSA_SetMarkerMenu
AWSA_DeleteAllMarkersOfThisType
AWSA_EndAirw eb
AWSA_DeleteMarkerFrom ThisRoom
AWSA_Help
AWSA_JumpM ark
AWSA_Jum pBack10Markers
AWSA_GoToPreviousMarkedPage
AWSA_Jum pForw ard10Markers
AWSA_GoToNextMarkedPage
14
2.8. Graphische Dialoge
Einige seltener benötigte Funktionen werden nur graphisch zugänglich sein. Dies sind Dialog zur Eingabe
einer URL und der Optionsdialog
2.9. Optionsdialog
Den Optionendialog zeigt folgende Abbildung:
Die hier eingetragenen Werte werden beim Verslassen des Programms persistent gespeichert.
Achtung: Eine weitere Option, nämlich das Eingabegerät, wird auch beim Verlassen des Programms
gespeichert. Dabei wird immer das gerade aktuelle Eingabegerät gespeichert, so das diese Einstellung hier
im graphischen Dialog nicht auftaucht.
AirBrowser Optionen
Start
OK
Startseite
file://index.html
Aktuelle Seite
Startraum
Abbrechen
Standard
Textraum
Audio
Lautstärke Stimme
Lautstärke Geräusche
Geräusche in der Mitte hören
Winkel der Hearcon-Ebene
Programmraum
Leseraum
Markerräume
90
Größe der Trefferflächen
Min.
Max.
Stimmenwechsel erlauben
15
3. Dynamisches Modell
3.1. Use Cases
3.1.1. Akteur – System
Alle vorkommenden Anwendungsfälle sind durch eine einheitliche Form gekennzeichnet: Es ist jeweils
nur ein Akteur beteiligt, und auch auf der Seite der Anwendung lassen sich die einzelnen Fälle
unabhängig voneinander betrachten, es sind also Use-Cases mit einer 1:1-Beziehung zu untersuchen.
Auch komplexe Anwendungssituationen, die mehrere Schritte erfordern, lassen sich leicht auf diese
Grundfunktionen zurückführen.
Aktion
Benutzer
Für einige charakteristische Use-Cases werden hier im folgenden die internen Abläufe in Form von
Sequenzdiagrammen dargestellt.
3.1.2. Liste der Programmfunktionen
-
Programmstart
Programmende
Blättern vor/zurück
Raumwechsel
Wechsel ins Menu
Optionen einstellen
Startseite
Startraum
Lautstärke Text
Lautstärke Geräusche
Geräusche in der Mitte hörbar
Stimmenwechsel
Eingabegerät
Größe der Trefferflächen
Winkel der Hearcon-Ebene
Hilfe
URL eingeben
Link wählen
Marker setzen/auswählen
16
3.2. Programmstart
Der Verlauf ist folgendermaßen:
-
-
Einlesen der Datendatei (mit den Raumkonfogurationen)
Einlesen der Datei mit den Programmoptionen und den Markerlisten, die Initialisierung der
entsprechenden Klassendaten (d.h. Auslösen der nötigen Ereignisse) erfolgt simultan, da die
entsprechenden Klassen das Einlesen der Datei(-Abschnitte) selbst erledigen.
Initialisierung von A3D
Akustik des Startraums aufbauen, ggf. auch Icons
Initialisierung des Internet Explorer,
Startseite laden, das dadurch ausgelößte Event wertet die XML-Info aus der Startseite bzgl.
Linkgröße etc. aus
3.3. Grundsätzliche Ereignisbehandlung
3.3.1. Diagramm
Folgendes Diagramm veranschaulicht die grundsätzliche Ereignisbehandlung.
aw p.input.*
AWIExInterface
AWProgramSetup
AWFlat
AWController
AWSA_*
AWRA_*
AWIExInterface
und
AWMainWindow
AWSound
(1)
(2)
(3)
(4a)
(4b)
(4c)
3.3.2. Beschreibung des Ablaufs
Der Ablauf ist folgendermaßen :
Ereignisse auslösen können die Klassen AWInput, AWProgramSetup und AWIExInterface, wie in der
Abbildung unter Punkt (1) dargestellt. AWInput gibt dabei die Benutzung der Eingabegeräte weiter, also
die Benutzung der Maus, des Joysticks, der Tastatur oder der Sprachsteuerung. AWProgramSetup lößt
mehrere Ereignisse aus, wenn die Programmoptionen per Dialog geändert worden sind, auf diese Weise
verbreiten sich dann die neuen Einstellungen. AWIExInterface lößt Ereignisse aus, wenn eine neue Seite
17
dargestellt wurde oder wenn gescrollt wurde, daraufhin müssen z.B. die Slots mit den Linklisten sich die
neuen Listen vom IEx-Interface holen.
Unter Punkt (2) und (3) in der Abbildung ist dann dargestellt, wie der Controller diese Informationen
weitergibt. Zum einen nimmt er einige Einstellungen am Sound und an der Darstellung selbst vor, wie
unter Punkt (2) dargestellt. Im wesentlichen werden diese Informationen aber an AWFlat usw. übergeben,
so daß die entsprechenden Räume und Slots darauf mit ihrer speziellen Funktionalität reagieren können,
dies ist unter Punkt (3) dargestellt.
Die Räume und die Slots realisieren dann die Aktionen, in dem Sie den Sound und die GUI steuern und
auch als Ereignisauslöser gegenüber dem Controller agieren, wie unter Punkt (4a), (4b) und (4c)
dargestellt. Der Slot für die Programmoptionen triggert außerdem noch den Dialog zum Einstellen der
Programmoptionen, wie unter Punkt (4c) dargestellt.
3.4. Blättern
Die Eingabeverwaltung am Beispiel Blättern bei Joystick als aktives Eingabegerät ist im Diagramm zu
sehen.
3.4.1. Diagramm
AWJ3DJoystick
Joystickknopf
w ird
gedrückt
AWController
aw p.input.*
AWRA_RoomMain
AWFlat
AWSA_MultipleForw ard
AWIExInterface
AWSound
handleInputEvent
Seite
w ird
geladen
3.4.2. Verlaufsbeschreibung
Der Verlauf ist folgendermaßen:
-
Joystick wird gerade abgefragt, Taste 2 ist gedrückt.
Joystick-Task sendet Event mit Koordinaten und Info über gedrückte Taste an AWInput.
In AWInput erfolgt die Verwaltung und Umrechnung in das eingaberätunabhängige Ereignis
AWUniEvent.
AWInput gibt das universale Event an den Controller.
18
-
-
Der Controller gibt das Event an AWFlat und so fließt das Event bis zum passenden Slot, in diesem
Fall AWSA_MultipleForward.
Angenommen, es wurde schon zweimal Knopf1 gedrückt, dann hat sich AWSA_MultipleForward
dies gemerkt. Die Klasse überprüft, ob die Koordinaten noch innerhalb ihrer Trefferfläche liegen,
Falls ja, wird jetzt die Aktion des zweiten Menüeintrags ausgelößt, z.B. „Blättern zur nächsten Seite“
Dies erfolgt, indem die entsprechenden Funktionen beim Sound und in der GUI (und eventuell im
Controller) aufgerufen werden.
Der Internet-Explorer lädt die neue Seite ein und lößt dann das Ereignis „Neue Seite wurde geladen“
aus, dies Eregnis gibt er dem Controller, der diese Information dann an alle interessierten Klassen
weiterverteilt.
3.5. Raumwechsel
Der Verlauf ist folgendermaßen:
-
Eingabeevent s.o.
Akustik des alten Raums deaktivieren
Icons tauschen
Akustik des neuen Raums aufbauen
19
4. Sonstiges
4.1. Inhalt
HTML-Seiten zum Testen des Browsers und für die Hilfefunktion sind bereits erstellt und im CVS
erhältlich. Die Beschreibungssprache für die zusätzliche Audio-Information in diesen Dokumenten ist
dem Anforderungsdokument zu entnehmen.
4.2. Entwicklungsumgebung
Zu den für die Implementierung verwendeten Werkzeugen gehören neben der im Anforderungsdokument
erwähnten Laufzeit-Systemumgebung (A3D, Windows, etc.) folgende Software: Borlands J-Builder DIE,
CVS Versionsverwaltung, Das Java SDK.
4.3. Prozeßdokumentation
Es ist zu erwarten, daß die in diesem Dokument beschriebenen Schnittstellen während der Entwicklung
noch erweitert werden. Die Dokumentation ist dem stets anzupassen. Dies kann auf drei verschiedene
Arten geschehen.
-
-
-
Grundlegende Veränderungen am Entwurf sollten regelmäßig in diesem Dokument ergänzt werden.
Dazu gehören alle Modifikationen an öffentlichen Schnittstellen und grundsätzliche Änderungen im
Verhalten der einzelnen Komponenten .
Auf Teilbereiche beschränkte neue Erkenntnisse und Implementationsdetails werden von den
jeweiligen ‚SpezialistInnen‘ in separaten Dokumenten beschrieben, wenn diese für die Gruppe von
Interesse sind. In den Entwurf werden dann entsprechende Verweise aufgenommen.
Der Quelltext sollte einerseits zum besseren Verständnis dokumentiert sein, und andererseits den
Ablauf der Entwicklung widerspiegeln, indem entsprechende Hinweise auf Veränderungen oben in
die Datei und in die CVS-Kommentare geschrieben werden. Für die Quelltextkommentare gelten die
Konventionen des Hilfsprogramms Javadoc.
4.4. Qualitätssicherung
Im Gegensatz zum Prototyp muß beim AirBrowser verstärkt auf die Zuverlässigkeit geachtet werden, da
hier der Funktionsumfang und der Anspruch an die Benutzbarkeit größer sind.
Die implementierten Klassen sollten mindestens im Verbund getestet werden, ein Modultest einzelner
Klassen ist dort sinnvoll, wo das Verhalten der Komponente im Gesamtprogramm nicht ausreichend
erkennbar ist.
Bei der Zeitplanung erscheint es angebracht, einen Meilenstein zu setzen, ab dem die Funktionalität nicht
mehr verändert und nur noch an der Zuverlässigkeit gearbeitet wird.
20