Document [original]

Mixed Reality in the Loop

Schriftliche Arbeit eingereicht bei der

Fakultät für Elektrotechnik, Informatik und

Mathematik der Universität Paderborn

zur Erlangung des Grades

Dr. rer. nat.

von

JÖRG STÖCKLEIN

Paderborn, den 08.06.2011

Ein iteratives, prototypenbasiertes

Entwurfsvorgehen für die Entwicklung

von Mixed Reality Anwendungen

DISSERTATION

Gutachter:

Prof. Dr. Franz J. Rammig, Universität Paderborn, Germany

Prof. Dr. Volker Paelke, Institut de Geomàtica, Spain

Abstract

Mixed Reality in the Loop – Ein iteratives, prototy-

penbasiertes Entwurfsvorgehen f¨ur die Entwicklung

von Mixed Reality Anwendungen

Mixed Reality in the Loop ist ein iteratives, prototypenbasiertes Ent-

wurfsvorgehen f

ur Mixed Reality Anwendungen. Das Vorgehen besteht

aus einem iterativen Prozess, an dessen Ende immer eine testbare

Designrepr

asentation der Anwendung, kurz ein Prototyp, steht, der

ur die n

achste Iteration verwendet wird. Die Iterationen werden

kurz gehalten, so dass st

andig eine testbare Designrepr

asentation der

Anwendung gew

ahrleistet ist. Dem Mixed Reality in the Loop-Entwurfs-

vorgehen steht ein eigens daf

ur entwickeltes Architekturmuster zur

Seite, das es erlaubt, die einzelnen Teile der Anwendung in insgesamt

vier Kategorien einzuteilen, die separat und unabh

angig voneinan-

der weiterentwickelt werden k

onnen. Der zentrale Vorteil bei Mixed

Reality in the Loop gegen

uber anderen Verfahren ist die Entwicklung

entlang des Mixed Reality Kontinuums. So bieten das Entwurfsvor-

gehen und der iterative Entwicklungsprozess die M

oglichkeit, in einer

rein virtuellen Welt mit der Implementierung der MR Anwendung

zu beginnen und in den sp

ateren Phasen schrittweise die virtuellen

Teile durch ihre realen Gegenst

ucke zu ersetzten. Das bedeutet f

die fr

uhen Entwicklungsphasen eine Implementation in einer fest

definierten virtuellen Umgebung, die komplett unter der Kontrolle

des Entwicklers liegt. Um eine Einsch

atzung des Entwicklungsstandes

der Prototypen zu erhalten wurde f

ur jede Komponente eine eigene

Metrik entworfen, die den Entwicklungsstand anhand verschiedener

Parameter errechnet.

iii

ABSTRACT

Mixed Reality in the Loop – An iterative prototype-

based design method for the development of mixed

reality applications

Mixed Reality in the Loop is an iterative, prototype-based design method

for mixed reality applications. The design method includes an iterative

process which results a testable design representation of the applicati-

on, what is referred as prototype, at each iteration. This prototype is

also used for further development in the next iteration. To achieve a

persistent design representation of the application, the design method

has short iterations. The Mixed Reality in the Loop design method in-

cludes an additional software architecture supporting a classification

of single application parts in four categories. Each classified part can

be developed separately and independently, The central advantage

over other design methods is the development along the mixed reality

continuum. The Mixed Reality in the Loop design method provides the

opportunity to begin the development of a mixed reality application

in a pure virtual environment and to iteratively replace the virtual

parts with its real counterparts in later phases of the development

process. That imply a defined virtual environment in early develop-

ment phases which is completely under control of the developer. To

get an estimation of the development status for the prototype a metric

for each of the four components has been designed, calculating the

development status with the help of various parameters.

Hinweise

In dieser Arbeit wurden die Verweise auf Kapitel oder Abbildun-

gen speziell formatiert, um die entsprechende Referenz schneller zu

finden. Verweise sind folgendermaßen aufgebaut:

Kapitel

><Seite>

Kapitel

steht f

ur das Kapitel, in dem die Referenz steht und die

unten angeh

angte

Seite

gibt die jeweilige Seite an. Diese Forma-

tierung existiert jedoch nur, sobald sich die Referenz nicht auf der

aktuellen Seite befindet. Diese Formatierung erlaubt es dem Leser,

schneller die Quelle des Verweises zu finden.

HINWEISE

Inhaltsverzeichnis

Abstract iii

Hinweise v

Inhaltsverzeichnis ix

1Einf¨

uhrung 1

1.1Motivation.................................... 2

1.2ZielderArbeit.................................. 4

1.3AktuellerStandderArbeit........................... 7

1.4StrukturierungderArbeit ........................... 7

1.5Zusammenfassung ............................... 8

2Grundlagen 11

2.1Vorgehensmodelle ............................... 12

2.1.1Typen von Vorgehensmodellen . . . . . . . . . . . . . . . . . . . . 13

2.1.2Wasserfallmodell............................ 14

2.1.3Spiralmodell............................... 17

2.1.4V-Modell................................. 19

2.1.5Norm ISO/IEC 12207 ......................... 20

2.1.6Norm DIN ISO 13407 ......................... 23

2.1.7Modellgetriebene Softwareentwicklung (MDSD) . . . . . . . . . 25

2.1.8Feature Driven Development (FDD) . . . . . . . . . . . . . . . . . 28

2.1.9RationalUnifiedProcess........................ 30

2.1.10 Extreme Programming (XP) . . . . . . . . . . . . . . . . . . . . . . 31

2.1.11 Scrum .................................. 34

2.1.12 Prototyping ............................... 39

2.1.13 Vorgehensmodelle Zusammenfassung . . . . . . . . . . . . . . . . 43

2.2Architekturmuster ............................... 43

2.2.1Model-View-Controller ........................ 45

2.2.2Presentation-Abstraction-Control . . . . . . . . . . . . . . . . . . . 47

2.2.3Zusammenfassung........................... 49

2.3Modellbildung und Simulation kontinuierlicher Systeme . . . . . . . . . 49

2.3.1In-the-LoopSimulation ........................ 51

2.3.2Zusammenfassung........................... 53

vii

INHALTSVERZEICHNIS

2.4Reality-Virtuality Kontinuum (RV) . . . . . . . . . . . . . . . . . . . . . . 54

2.4.1Realit¨

at.................................. 54

2.4.2Virtuelle Realit¨

at ............................ 55

2.4.3AugmentedVirtuality ......................... 56

2.4.4AugmentedReality........................... 56

2.5Zusammenfassung ............................... 57

3Stand der Forschung 59

3.1¨

Ubersicht..................................... 59

3.2Mixed Reality Entwurfskonzepte . . . . . . . . . . . . . . . . . . . . . . . 60

3.3Entwurfskonzepte mit Werkzeugumgebung . . . . . . . . . . . . . . . . 66

3.4Softwareumgebungen und -l¨

osungen .................... 87

3.5Zusammenfassung ............................... 95

4Mixed Reality in the Loop 97

4.1Anforderungsanalyse.............................. 98

4.2Vorgehensweise................................. 101

4.3EntwickelteMethoden............................. 103

4.3.1MVCE - Model-View-Controller-Environment . . . . . . . . . . . 104

4.3.2DieMRiL-Metrik............................ 109

4.3.3DasAkteurmodell ........................... 120

4.3.4DasEntwurfsvorgehen......................... 124

4.4Erl¨

auterung des Entwurfsvorgehens an einem Beispiel . . . . . . . . . . 128

4.4.1¨

UberblickdesBeispiels ........................ 129

4.4.2Realisierung des Beispiels . . . . . . . . . . . . . . . . . . . . . . . 131

4.4.3FazitdesBeispiels ........................... 135

4.5DieSoftwareumgebung ............................ 136

4.5.1Erweiterungen des propriet¨

aren Autorensystems 3DVIA Virtools 136

4.5.2MiReAS - Eine Mixed Reality Softwareumgebung . . . . . . . . . 148

4.6Zusammenfassung ............................... 157

5Beispiel 159

5.1¨

Uberblick..................................... 159

5.1.1DerZeppelin .............................. 161

5.2Prototypenentwicklung ............................ 163

5.2.1DieInitialphase............................. 164

5.2.2Der erste Prototyp: Eine einfache VR Version . . . . . . . . . . . 168

5.2.3Der zweite Prototyp: Virtueller Prototyp mit Physiksimulation . 170

5.2.4Der dritte Prototyp: Verfeinerung der Steuerung . . . . . . . . . . 174

5.2.5Der vierte Prototyp: Verbesserte real existierende Umgebung . . 178

5.2.6

Der f

unfte Prototyp: Virtueller Prototyp mit einfacher Gesten-

steuerung ................................ 181

5.2.7

Der sechste Prototyp: Virtueller Prototyp mit verbesserter Phy-

siksimulation .............................. 185

5.2.8Der siebte Prototyp: Virtueller Prototyp in realer Umgebung . . 189

viii

INHALTSVERZEICHNIS

5.2.9

Der achte Prototyp: Realer Zeppelin mit AR-Unterst

utzung und

verbesserterSteuerung......................... 192

5.2.10

Der neunte Prototyp: Realer Zeppelin mit AR-Unterst

utzung und

verbesserter Hardware-Steuerung . . . . . . . . . . . . . . . . . . 195

5.2.11 Der zehnte Prototyp: Realer Zeppelin in virtueller Umgebung . 196

5.3Zusammenfassung ............................... 199

6Synopsis 201

6.1Mixed Reality in the Loop im Vergleich . . . . . . . . . . . . . . . . . . . 201

6.2Zusammenfassung ............................... 205

7Zusammenfassung und Ausblick 207

7.1Zusammenfassung ............................... 207

7.2Ausblick ..................................... 210

7.2.1VisuelleNotation............................ 210

7.2.2Entwicklungswerkzeug f¨

ur die visuelle Notation . . . . . . . . . 211

7.2.3Automatische Generierung von ausf¨

uhrbaren Prototypen . . . . 212

7.3Zusammenfassung ............................... 213

Abbildungsverzeichnis 217

Abk¨

urzungsverzeichnis 221

Literaturverzeichnis 234

Publikationen 237

INHALTSVERZEICHNIS

KAPITEL 1

Einf¨uhrung

MRiL

Mixed Reality in the Loop

In diesem Kapitel versuche ich mein entwickeltes

”

Mixed Reality in

the Loop“-Entwurfsvorgehen (abgek

urzt: MRiL) zu motivieren, indem

ich aufzeige, dass in der Entwicklung vom Mixed Reality Anwendun-

gen ein Vorgehen fehlt, das entlang des Mixed Reality Kontinuums

aufbaut und mit Hilfe von Prototypen eine immer testbare Designre-

asentation bietet. Anschließend an die Motivation erl

autere ich die

Ziele, die ich mir f

ur diese Arbeit gesetzt habe und die mit Hilfe

des

”

Mixed Reality in the Loop“-Entwurfsvorgehens erreicht werden

sollen. Daraufhin stelle ich kurz den aktuellen Stand der Arbeit vor.

EINF ¨

UHRUNG

Zum Ende des Kapitels folgt eine Beschreibung der Strukturierung

dieser Arbeit.

1.1 Motivation

Mit der Entwicklung schneller Hardware, sowohl der CPUs als auch

der Grafikeinheiten, ergab sich die M

oglichkeit, reale Videobilder

in Echtzeit

analysieren zu k

onnen. Ende der Neunziger Jahre be-

gannen Forscher mit der Echtzeitanalyse der Videobilder, um so die

Struktur der aufgenommenen Objekte zu ermitteln. Mit Hilfe kleiner

schwarz-weiß Piktogramme, der sogenannten Marker, gelang es, Po-

sition und Orientierung eines Objektes im dreidimensionalen Raum

nur unter Zuhilfenahme eines, von einer Videokamera aufgenom-

menen, 2D-Bildes zu ermitteln und an dieser Position ein virtuelles

3D-Objekt zu positionieren. Augmented Reality (AR), also die ange-

reicherte Realit

at, war geboren. In den folgenden Jahren wurde das

Thema Augmented Reality detailliert erforscht, sowohl im Theoreti-

schen, indem der Begriff AR definiert und in Zusammenhang mit

der echten Realit

at gesetzt wurde, als auch im Praktischen, indem

Softwarel

osungen angeboten wurden, die es einer breiten Masse an

Entwicklern erm¨

oglichten, selbst AR Anwendungen zu realisieren.

Anf

anglich wurden die technischen Methoden, die es erm

oglichten,

Augmented Reality anzuwenden, verst

arkt entwickelt und erforscht.

Nachdem die ersten reinen API

-basierten Softwarel

osungen f

ur die

breite Masse der Entwickler zur Verf

ugung standen, konzentrierten

sich viele Forscher auf die grundlegenden Kamera-Tracking

Verfah-

ren und deren Verbesserung. Die ersten Konferenzen, die sich speziell

mit Augmented Reality und sp

ater auch mit dem erweiterten Gebiet

von Mixed Reality (MR) auseinander setzten, wurden veranstaltet, dar-

unter beispielsweise die IEEE ISMAR, die zum ersten Mal im Jahre

1998 stattfand [

IEE98

]. An den dort vorgestellten Beitr

agen ist gut zu

erkennen, welche Themen im Bereich Mixed Reality

uber die Jahre

die Aufmerksamkeit der Forscher erhielten. Und genau hier ist zu

sehen, dass viel Energie in die Erforschung der Basistechnik geflos-

sen ist, allerdings erst sehr viel sp

ater erkannt wurde, dass sich die

Entwicklung von MR Anwendung von der Entwicklung traditioneller

Software in vielen Punkten unterscheidet.

In dieser Arbeit ist unter dem Begriff Echtzeit ein weiches Echtzeitverhalten zu verstehen, das sich

an der menschliche Wahrnehmung f

ur bewegte Bilder orientiert. Da ein Mensch ab ca. 16 Bilder pro

Sekunde eine fl¨

ussige Bewegung erkennt, liegen die Reaktionszeit somit bei ≤63ms.

2API = Application Programming Interface – Eine Programmierschnittstelle auf Quelltextebene.

Mit Tracking bezeichnet man die kontinuierliche Positionsbestimmung realer Objekte im Raum. Die

Positionsbestimmung kann Zwei- oder Dreidimensional erfolgen.

1.1 MOTIVATION

Es stellte sich nach einiger Zeit der Entwicklung von MR Anwendun-

gen heraus, dass es nicht ausreicht, nur eine reine Low Level API-

basierte Programmierunterst

utzung zu nutzen. Durch die zunehmen-

de Komplexit

at der Projekte, die eine MR Unterst

utzung integrierten,

kamen die Entwickler bald an die Grenzen ihrer M

oglichkeiten struk-

turiert zu entwickeln. Da kein einheitliches Vorgehen f

ur den Entwurf

von AR Anwendungen existierte, mussten viele L

osungen individuell

f¨

ur jedes Projekt entworfen werden, testbare Designrepr¨

asentationen

der Software waren nicht vorhanden, so dass die Projekte erst kurz

vor Ende der Entwicklung wirklich getestet werden konnten. Des

Weiteren waren die Entwickler an die Technik gebunden, auf die

sie sich zu Beginn der Entwicklung festgelegt hatten. Da im Laufe

der Zeit einige konkurrierende L

osungen aufkamen, die jedoch nicht

unbedingt untereinander kompatibel waren, teilweise aber Vorteile

gegen

uber der Konkurrenz boten, war es den Entwicklern nur schwer

m¨

oglich, die Basistechnologien einfach zu wechseln.

Aus dieser Problematik heraus entstanden die ersten High Level

Entwicklungsumgebungen, die es sich zur Aufgabe gemacht hat-

ten, die MR Anwendungsentwicklung von den Basistechnologien zu

trennen. Ein fr

uhes Beispiel einer solchen Entwicklungsumgebung

ist DART [

MGDB04

], das im Kapitel

390

vorgestellt wird. Auch die

von uns entwickelte Integration in die Szenegraph-Bibliothek Java3D

zielte auf diese Trennung von Basistechnologie und Anwendungs-

entwicklung ab [

GRSP02

]. Die Trennung von Basistechnologie und

Anwendungsprogrammierung war ein Schritt in die richtige Rich-

tung, allerdings fehlte zu dieser Zeit komplett ein Entwurfsvorgehen,

das beschreiben konnte, wie Entwickler Mixed Reality Anwendungen

effizient programmieren k¨

onnen.

In den folgenden Jahren wurde auch der Bereich des Entwurfsvorge-

hens erforscht und es wurden Verfahren vorgestellt, die sowohl das

Entwurfsvorgehen selbst als auch ein eigenes Modell zur Entwicklung

anboten. Was allerdings nicht vorgestellt wurde, war ein Vorgehen

einschließlich Werkzeugumgebung, das es erm

oglichte, Mixed Reality

Anwendungen mit einer immer testbaren Designrepr

asentation zu

realisieren. Genau hier setzt meine Arbeit an und versucht diese L

ucke

zu schließen.

Mit

”

Mixed Reality in the Loop“ steht dem Entwickler von Mixed

Reality Anwendungen ein Entwurfsvorgehen zur Verf

ugung, das ihn

durch die Phasen der Entwicklung der Anwendungen leitet. Mehr

noch, das Vorgehen ist ein iterativer Prozess, an dessen Ende immer

ein testbarer Prototyp der Anwendung steht, der f

ur die n

achste Itera-

tion verwendet wird. Die Iterationen werden kurz gehalten, so dass

andig eine testbare Designrepr

asentation der Anwendung existiert.

EINF ¨

UHRUNG

Dem

”

Mixed Reality in the Loop“-Entwurfsvorgehen steht ein eigens

daf

ur entwickeltes Architekturmuster zur Seite, das es erlaubt, die ein-

zelnen Teile der Anwendung in insgesamt vier Kategorien einzuteilen,

die separat und unabh

angig voneinander weiterentwickelt werden

k¨

onnen.

Der zentrale Vorteil bei

”

Mixed Reality in the Loop“ gegen

uber an-

deren Verfahren ist jedoch die Entwicklung entlang des Mixed Reality

Kontinuums (siehe zur Begriffserkl

arung Kapitel

2.454

). So bieten das

Entwurfsvorgehen und der iterative Entwicklungsprozess die M

oglich-

keit, in einer rein virtuellen Welt mit der Implementierung der MR

Anwendung zu beginnen und in den sp

ateren Phasen schrittweise

die virtuellen Teile durch ihre realen Gegenst

ucke zu ersetzten. Das

bedeutet f

ur die fr

uhen Entwicklungsphasen eine Implementation

in einer fest definierten virtuellen Umgebung, die komplett unter

der Kontrolle des Entwicklers liegt. In der sp

ateren Entwicklung,

sobald die Grundfunktionalit

at der Anwendung ausreichend stabil

auft, k

onnen Teile dieser Umgebung dann durch reale Komponenten

ersetzt werden. So ist es beispielsweise m

oglich, neue Algorithmen

zuerst in einer sehr eingeschr

ankten Umgebung auf ihre Korrektheit

uberpr

ufen und nach erfolgreichem Abschluss dieser Tests die

Algorithmen in Komponenten der realen Welt einzusetzen. Des Weite-

ren ist es m

oglich, Teile der Anwendung schon zu implementieren,

obwohl die realen Komponenten entweder noch nicht existieren oder

die technischen Bedingungen noch nicht geschaffen sind, mit ihnen

aus der Anwendung heraus zu interagieren. Auch der Weg zur

uck,

aus der realen Welt in die virtuelle Welt, ist mit

”

Mixed Reality in

the Loop“ m

oglich. So k

onnen z. B. neue Versionen von Algorithmen

zuerst in der virtuellen Welt validiert werden, bevor sie die Kompo-

nenten der realen Welt steuern.

Zusammenfassend bietet das

”

Mixed Reality in the Loop“-Entwurfs-

vorgehen einen L

osungsweg, wie schrittweise aus einer virtuellen

Anwendung eine Mixed Reality Anwendung entstehen kann. Es bietet

ein Vorgehen, um eine Transition vom virtual Prototyping und der

finalen Anwendung erfolgreich zu realisieren.

1.2 Ziel der Arbeit

Diese Arbeit hat zum Ziel, ein werkzeuggest

utztes, prototypenbasier-

tes, iteratives Entwurfsvorgehen f

ur Mixed Reality Anwendungen zu

entwickeln. Dieses Entwurfsvorgehen soll entlang des Mixed Reality

Kontinuums f¨

uhren und folgende Konzepte beinhalten:

1.2 ZIEL DER ARBEIT

Entwurfsvorgehen:

Das Vorgehen zur Entwicklung von Mixed Reality

Anwendungen soll auf einem iterativen, prototypenbasierten

Ansatz basieren. Es soll eine Werkzeugunterst

utzung bieten, so

dass die Entwicklung softwaretechnisch getragen wird.

Architekturmuster:

Die Grundlage des Entwurfsvorgehens soll ein

Architekturmuster sein, das die iterative Anwendungsentwick-

lung unterst

utzt. Es basiert auf dem bekannten MVC Architek-

turmuster (Kapitel

2.2.145

) und wurde um eine Komponente

erweitert, um die Besonderheit bei Mixed Reality Anwendungen

zu unterst¨

utzten.

Akteurmodell:

Zur Verfeinerung des Architekturmusters soll ein ei-

genes Akteurmodell verwendet werden. Dieses gew

ahrleistet bei

der Entwicklung der Mixed Reality Prototypen kurze Iterationen

und gew

ahrleistet somit eine st

andig testbare Repr

asentation

der aktuellen Anwendung.

Metrik:

Es soll eine Metrik entwickelt werden, die den entsprechen-

den Entwicklungstand des aktuellen Prototypen charakterisieren

kann. Diese Metrik soll das Architekturmuster ber

ucksichtigen

und auf der Entwicklung der einzelnen Komponenten basieren.

Verglichen mit anderen aktuellen Arbeiten im Bereich des Mixed

Reality Entwurfs hat diese Arbeit folgende Herausstellungsmerkmale:

Die Entwicklung der Anwendung geschieht entlang des Mixed

Reality Kontinuums, was bedeutet, dass die Applikation aus der

reinen virtuellen Welt in die reale Welt entwickelt wird. Kom-

ponenten und Objekte, die am Anfang der Entwicklung virtuell

definiert werden, k

onnen im Laufe der Entwicklung zu realen

Objekten

ubergehen. Auch der umgekehrte Fall ist m

oglich, dass

reale Objekte wieder zu virtuellen Objekten werden. Diese Tran-

sition zwischen der realen und der virtuellen Welt ist sinnvoll,

wenn am Anfang der Entwicklung die realen Objekte noch nicht

zur Verf

ugung stehen, oder wenn im Laufe der Entwicklung auf

eine spezielle Auspr

agung getestet werden soll und deshalb nur

die beteiligten Objekte in der realen Form vorhanden sein sollen.

Die Anwendung ist in kleine Komponenten, die sogenannten

Akteure, die anhand des vorgestellten Architekturmusters klas-

sifiziert und entsprechend entwickelt werden k

onnen, aufgeteilt.

Eine Metrik erlaubt den Entwicklungsstand bezogen auf Klassi-

fizierung der einzelnen Akteure und so den gesamten Entwick-

lungsstand der Mixed Reality Anwendung zu ermitteln.

EINF ¨

UHRUNG

Die softwarem

aßige Wiederverwendbarkeit der Akteure wird

mit Hilfe des Adapter-Prinzips gel

ost, so dass in den meisten

allen die Akteure nicht neu programmiert werden m

ussen.

Durch eine definierte Schnittstelle ist so auch der Austausch von

virtuellen zu realen Akteuren m¨

oglich.

Ein eigenes iteratives, prototypenbasiertes Entwurfsvorgehen

erlaubt kurze Iterationszyklen und eine st

andig testbare Re-

asentation der Mixed Reality Anwendung. Durch die Wieder-

verwendbarkeit k

onnen die Iterationszyklen noch k

urzer gehal-

ten werden.

Durch die Entwicklung entlang des Mixed Reality Kontinuums

und der Klassifizierung des Architekturmusters k

onnen Kom-

ponenten w

ahrend der Entwicklung unterschiedlich priorisiert

werden.

Eine Softwareumgebung, die das komplette Entwurfsvorgehen

unterst¨

utzt und so die Entwicklung einer Mixed Reality Anwen-

dung von der rein konzeptionellen Ebene in die Machbarkeit

uberf¨

uhrt.

Nach der Entwicklung der konzeptionellen Grundlagen dieser Arbeit

wurde das Entwurfsvorgehen zun

achst an einem kleineren Beispiel

getestet. Dieses entstand ohne eine spezielle Entwicklungsumgebung,

so dass zuerst ein kleiner Umfang des Entwurfsvorgehens validiert

werden konnte.

ahrend der Arbeit entstanden zwei voneinander unabh

angige Ent-

wicklungsumgebungen, die unterschiedliche Aspekte der Entwick-

lung fokussierten. Die erste Entwicklungsumgebung basiert auf einem

propriet

aren 3D Autorenwerkzeug, das es dem Entwickler von An-

wendungen erm

oglicht, diese visuell (und nicht wie sonst

ublich

textuell) zu entwickeln. Dieses propriet

are Werkzeug wurde mit Hilfe

von Plug-ins dahingehend erweitert, dass die Entwicklung von Mixed

Reality Anwendungen erm

oglicht wurden. Allerdings war es nicht

oglich, alle Konzepte des Entwurfsvorgehens zu realisieren. Aus

diesem Grund wurde ein komplett eigenes Werkzeug, das speziell

ur das

”

Mixed Reality in the Loop“-Entwurfsvorgehen ausgearbeitet

wurde, entworfen. Hier war es m

oglich, alle Aspekte von MRiL zu

verwenden. Mit Hilfe dieses Werkzeuges wurde dann ein komplexes

Beispiel realisiert, um die Anwendbarkeit von MRiL zu demonstrie-

ren.

1.3 AKTUELLER STAND DER ARBEIT

1.3 Aktueller Stand der Arbeit

Aktuell ist das Entwurfsvorgehen konzeptionell vollst

andig (siehe

Kapitel

497

). Die beiden Entwicklungsumgebungen sind komplett im-

plementiert und einsatzbereit. Da die Entwicklungsumgebungen, die

auf dem propriet

aren 3D Autorenwerkzeug basieren, mit Hilfe von

Plug-ins realisiert wurden, ist nicht jede Funktionalit

at f

ur alle denkba-

ren F

alle implementiert. Hier m

ussten f

ur konkrete Projekte entweder

die vorhandenen Plug-ins angepasst oder neue Plug-ins entwickelt

werden. Dies ist jedoch im Sinne des Autors, da die Entwicklung

einer Mixed Reality Anwendung die Implementierung spezialisierter

Plug-ins nicht ausschließt sondern, gerade durch die einfache Einbin-

dung in die Entwicklungsumgebung, erm

oglicht. Auch in der aus

dieser Arbeit hervorgegangenen eigenen Entwicklungsumgebung ist

es erw

unscht, spezielle Funktionalit

at selbst mit Hilfe von Akteuren

zu entwickeln. Die Grundstrukturen f

ur solche Entwicklungen sind

allerdings in beiden Entwicklungsumgebungen explizit vorhanden.

Bei den Beispielen, die mit Hilfe der eigenen Entwicklungsumgebung

entstanden sind, ist die Implementierung zum gr

oßten Teil vollendet.

Da es sich bei dem Beispiel allerdings um ein interdisziplin

ares Projekt

mehrerer Fachgruppen, sowohl an der Universit

at Paderborn als auch

an der Fachhochschule D

usseldorf, handelt, konnten einige Punkte

nur konzeptionell entwickelt werden (siehe dazu Kapitel

5159

). Leider

wurde die Entwicklung einer erforderlichen Hardwarekomponente

nicht fristgerecht vollendet, so dass die Prototypen, die diese Kom-

ponente erfordern, nicht vollst

andig implementiert werden konnten.

Konzeptionell allerdings wurden alle Beispiele komplett entwickelt.

1.4 Strukturierung der Arbeit

Dem aktuellen Kapitel folgt das Kapitel

uber die Grundlagen. Hier

werden bekannte Vorgehensmodelle (Kapitel

2.112

) und Architektur-

muster (Kapitel

2.243

) sowie eine kurzer

Uberblick

uber Modellbildung

und Simulation (Kapitel

2.349

) vorgestellt und eine Einf

uhrung in Mi-

xed Reality (Kapitel

2.454

) gegeben. Die vorgestellten Themen sollen

ein grundlegendes Wissen in den jeweiligen Bereichen vermitteln, so

dass auch ein Leser, der in diesen Gebieten nicht bewandert ist, die

Arbeit verstehen kann.

Es folgt das Kapitel ¨

uber die aktuellen Forschungsergebnisse in dem

Bereich dieser Arbeit. Dieses Kapitel unterteilt sich in die Mixed Reality

Entwurfskonzepte (Kapitel

3.260

), die Entwurfskonzepte mit Werk-

EINF ¨

UHRUNG

zeugumgebung (Kapitel

3.366

) und den reinen Softwareumgebungen

und Softwarel

osungen (Kapitel

3.487

). In jedem Gebiet wurden Arbei-

ten ausgew

ahlt, die sich in Teilen dieser Arbeit gleichen, allerdings

nicht den kompletten Umfang dieser Arbeit besitzen. Die jeweiligen

Unterschiede wurden in einer Tabelle kenntlich gemacht.

Kapitel

497

ist das erste der beiden Hauptkapitel. Hier wird das kom-

plette

”

Mixed Reality in the Loop“-Entwurfvorgehen vorgestellt. Bei

der Anforderungsanalyse (Kapitel

4.198

) wird festgestellt, f

ur welche

Anwendungen sich das Vorgehen eignet. Die Vorgehensweise (Kapitel

4.2101

) beschreibt das Verfahren, wie Anwendungen mit dem Ent-

wurfsvorgehen zu entwickeln sind. Die ben

otigten Methoden (Kapitel

4.3103

) werden im darauf folgenden Kapitel beschrieben. Mit Hilfe

eines kleinen Beispiels (Kapitel

4.4128

) soll gezeigt werden, wie sich

das Entwurfsvorgehen auch ohne Werkzeugunterst

utzung verwen-

den l¨

asst. Nach dem Beispiel werden die zwei Softwareumgebungen

(Kapitel

4.5136

) vorgestellt, die auf dem

”

Mixed Reality in the Loop“-

Entwurfsvorgehen basieren.

Um sowohl das Entwurfsvorgehen als auch eine der Softwareumge-

bungen zu

uberpr

ufen, wird in Kapitel

5159

ein nicht triviales Beispiel

entwickelt, das zehn aufeinander aufbauende Prototypen umfasst.

Bei der Realisierung der einzelnen Prototypen wird das Entwurfsvor-

gehen und die Berechnung der Metrik komplett angewendet, so dass

sich immer der Stand des aktuellen Prototypen ableiten l

asst. Die ein-

zelnen Prototypen fokussieren dabei gr

oßtenteils jeweils eine andere

Auspr

agung der Anwendung, beispielsweise eine Verfeinerung des

Modells oder eine ¨

uberarbeitete Steuerung.

Im Kapitel

6201

wird abschließend mein Vorgehen den aus der Litera-

tur bekannten und in Kapitel

359

vorgestellten Arbeiten gegen

uber-

gestellt und verglichen. Die einzelnen f

ur mein Vorgehen relevanten

Arbeiten werden noch einmal kurz zusammengefasst und die Unter-

schiede zu meinem Vorgehen aufgezeigt.

Im letzten Kapitel (Kapitel

7207

) fasse ich die Ergebnisse meiner Ar-

beit zusammen und gebe einen Ausblick auf zuk

unftige Forschungs-

schwerpunkte, die aufbauen auf dem hier vorgestellten Entwurfsvor-

gehen erarbeitet werden k¨

onnten.

1.5 Zusammenfassung

In diesem Kapitel habe ich motiviert, warum es sinnvoll ist, ein Ent-

wurfsvorgehen entlang des Mixed Reality Kontinuums zu entwickeln.

Ich habe die Ziele dieser Arbeit aufgezeigt und erl¨

autert, in wie weit

1.5 ZUSAMMENFASSUNG

sich das hier vorgestellt Entwurfsvorgehen von anderen Arbeiten un-

terscheidet. Es wurde der aktuelle Stand der Entwicklung des Vorge-

hens erl

autert und die Strukturierung der gesamten Arbeit vorgestellt.

Im nun folgenden Kapitel gehe ich auf grundlegende Verfahren in

den Bereichen ein, die ich in meiner Arbeit ben¨

otige.

EINF ¨

UHRUNG

KAPITEL 2

Grundlagen

Dieses Kapitel behandelt die grundlegenden Methoden und Strategi-

en, auf der meine Arbeit basiert. In Kapitel

2.112

werden verschiedene

Vorgehensmodelle vorgestellt, die f

ur die Erstellung von Softwarean-

wendungen entwickelt wurden und noch heute im Einsatz sind. Das

Kapitel

2.243

beschreibt unterschiedliche Architekturmuster, die f

verschiedene Probleme in der Softwareentwicklung geschaffen wur-

den. Die verschiedenen In-the-Loop Simulationsverfahren, die u. a. zur

Entwicklung von mechatronischen Systemen verwendet werden, sind

in Kapitel

2.349

aufgef

uhrt und werden dort kurz erl

autert. Kapitel

2.454

erkl

art das Reality-Virtuality Kontinuum (RV), welches Grundlage

meines Entwicklungsprozesses ist, und erl¨

autert es an Beispielen.

Die hier vorgestellten Methoden, Strategien, Verfahren und Definitio-

nen sind in der Literatur wohl bekannt und gelten als Standard bzw.

Grundlage in der Softwareentwicklung. Die meisten Verfahren werden

seit vielen Jahren in der Softwareentwicklung erfolgreich eingesetzt,

gerade im Bereich Vorgehensmodelle und Architekturmuster. Teil-

weise sind die Methoden auch schon

uberholt, werden allerdings f

das grundlegende Verst

andnis der in Kapitel

359

vorgestellten Stand

der Forschung aufgef

uhrt. Dieses Kapitel bietet somit einen groben

Uberblick

uber die Methoden, Strategien, Verfahren und Definitionen,

die zum Verst

andnis meiner Arbeit dienen sollen. Aus diesem Grund

beziehe ich mich in diesem Kapitel teilweise auf Artikel der freien

Enzyklop

adie Wikipedia [

Wik11

], referenziere jedoch immer f

ur die

einzelnen Themen die grundlegenden wissenschaftlichen Ver

offentli-

chungen bzw. Fachb

ucher, so dass die einzelnen vorgestellten Themen

immer wissenschaftlich belegt sind.

GRUNDLAGEN

2.1 Vorgehensmodelle

Ein Vorgehensmodell im Allgemeinen organisiert einen Prozess der

gestaltenden Produktion in verschiedene, strukturierte Phasen, denen

wiederum entsprechende Methoden und Techniken der Organisation

zugeordnet sind. Die Aufgabe eines Vorgehensmodells ist es, die allge-

mein in einem Gestaltungsprozess auftretenden Aufgabenstellungen

und Aktivit

aten in einer deutlich erkennbaren logischen Ordnung

darzustellen.

Ein Vorgehensmodell in der Softwareentwicklung im Speziellen ist

ein angepasstes Vorgehensmodell, welches bei der professionellen

Anwendungsentwicklung verwendet wird. Es dient dazu, die Softwa-

reentwicklung

ubersichtlicher zu gestalten und in der Komplexit

beherrschbar zu machen.

Komplexe Software ist nur schwer zu erstellen und zu warten, so dass

sich Softwareentwickler eines Planes zur Entwicklung von Software

bedienen. Dieser Plan – das so genannte Vorgehensmodell – unterteilt

den Entwicklungsprozess in

uberschaubare, zeitlich und inhaltlich

begrenzte Phasen. Die Software wird daher Schritt f

ur Schritt fertig-

gestellt. Dem eigentlichen Entwicklungsprozess stehen dabei sowohl

das Projektmanagement als auch die Qualit

atssicherung begleitend

zur Seite.

Vorgehensmodelle spalten die einzelnen Aktivit

aten auf verschiedene

Phasen im Entwicklungsprozess auf. Diese werden dann, ggf. mit

geringen Modifikationen, einmalig (z. B. Wasserfallmodell, siehe Ka-

pitel

2.1.214

) oder mehrfach (z. B. Spiralmodell, siehe Kapitel

2.1.317

)

durchlaufen. Bei mehrmaligen Durchlauf erfolgt eine iterative Ver-

feinerung der einzelnen Softwarekomponenten. Um die optimalen

Vorgehensmodelle herrscht Uneinigkeit. In der Regel unterscheiden

sie beim Entwicklungsprozess mindestens zwei große T

atigkeitsgrup-

pen: Die, von der programmiertechnischen Realisierung unabh

angige,

Analyse von Gesch

aftsprozessen (Gesch

aftsprozessmodell und Daten-

modell) einerseits und die EDV-technische Realisierung (Design und

Programmierung) andererseits.

Vorgehensmodelle unterscheiden sich wesentlich in ihrem Detaillie-

rungsgrad. Dabei sind z. B. der OOTC-Approach [

IOOTC97

] oder der

Rational Unified Process [

KR96

] detailliert ausgearbeitete Vorgehens-

weisen, die den an der Entwicklung Beteiligten konkrete Arbeitsan-

weisungen an die Hand geben. Das V-Modell (Kapitel

2.1.419

) nimmt

diesbez

uglich

ubrigens eine hybride Stellung ein, da es sowohl ein

Prinzip (jeder Stufe der Entwicklung entspricht eine Testphase) als

2.1 VORGEHENSMODELLE

auch (wie zumeist gebr¨

auchlich) ein detailliertes Modell ist.

Agile Softwareentwicklung ist der Oberbegriff f

ur den Einsatz von

Agilit

at (lat. agilis, zu deutsch

”

flink, beweglich“) in der Softwareent-

wicklung. Die Agile Softwareentwicklung besch

aftigt sich mit Me-

thoden, die den Entwickler kreativ arbeiten und Verwaltungsaspekte

zur

ucktreten lassen. Je nach Kontext bezieht sich der Begriff auf Teil-

bereiche der Softwareentwicklung – wie im Fall von Agile Modeling

– oder auf den gesamten Softwareentwicklungsprozess – exempla-

risch sei Feature Driven Development (Kapitel

2.1.828

) oder Extreme

Programming (Kapitel

2.1.1031

) angef

uhrt. Agile Softwareentwicklung

versucht mit geringem b

urokratischem Aufwand und wenigen Regeln

auszukommen.

2.1.1 Typen von Vorgehensmodellen

Es existieren insgesamt drei unterschiedliche Typen von Vorgehens-

modellen [Wik11]:

Software-Entwicklungsprozesse:

Sie dienen zur Steuerung der Soft-

wareentwicklung von der Konzeption bis zum endg

ultigen Einsatz

inklusive der anfallenden

Anderungen einer Software. Es gibt viele

verschiedene Prozesse, wobei die unten angegebenen die bekanntesten

dieser Klasse sind [Wik11]:

•Wasserfallmodell

•Spiralmodell

•V-Modell

Software-Lebenszyklusmanagement:

Sie erweitert die Phasen

uber

den gesamten Lebenszyklus einer Software. Das Vorgehensmodell

definiert die Anforderungen an betriebliche Prozesse (das

”

WAS“)

und beschreibt die konkreten, EDV-technisch realisierten Prozesse

(das

”

WIE“). Dieser Typ ist eine Mischung aus Ist-Beschreibung und

normativer Vorgabe. Je nach Standardisierungsgrad werden verschie-

dene Entwicklungsstufen vergeben. Unternehmen k

onnen sich diese

Entwicklungsstufen von externen Stellen zertifizieren lassen. Ein rele-

vantes Beispiel hierf¨

ur ist [Wik11]:

•Norm ISO/IEC 12207

Softwareentwicklungs-Philosophie:

Eine konkrete Programmierer-

Philosophie bzw. ein bestimmter Ansatz, wie Software nach Ansicht

GRUNDLAGEN

der Entwickler am besten entwickelt werden sollte. Diese Philosophien

beinhalten sehr oft auch Prozesselemente und werden daher ebenfalls

als Prozessmodell bezeichnet. Die unten angegebenen Modelle sind

nur ein kleiner, aber f¨

ur diese Arbeit relevanter, Teil:

•Norm DIN ISO 13407

•ModellgetriebeneSoftwareentwicklung (MDSD)

•Feature Driven Development (FDD)

•Rational Unified Process (RUP)

•Extreme Programming (XP)

•Scrum

•Prototyping

In den folgenden Kapiteln werden die oben genannten Vorgehens-

modelle kurz vorgestellt und beschrieben. Einiger der Modelle wer-

den ausf

uhrlicher beschrieben, da sie zum Teil Grundlage meines

Entwurfsvorgehens sind. Der Vollst

andigkeit halber und wegen des

Verst

andnisses stelle ich auch teilweise sehr fr

uhe Vorgehensmodelle

der Softwareentwicklung vor.

2.1.2 Wasserfallmodell

Das Wasserfallmodell ist ein lineares und nicht-iteratives Vorgehens-

modell, bei dem der Entwicklungsprozess in Phasen organisiert wird.

Dabei gehen die Phasenergebnisse wie bei einem Wasserfall immer

als bindende Vorgaben f¨

ur die n¨

achsttiefere Phase ein [Wik11].

Jede Phase im Wasserfallmodell hat vordefinierte Start- und Endpunk-

te, die eindeutig definierte Ergebnisse liefern. In Meilensteinsitzungen

am jeweiligen Phasenende werden die Ergebnisdokumente verabschie-

det. Zu den wichtigsten Dokumenten z

ahlen dabei das Lastenheft

sowie das Pflichtenheft. In der betrieblichen Praxis gibt es viele Va-

rianten des reinen Modells. Es ist aber das traditionell am weitesten

verbreitete Vorgehensmodell [Wik11].

Das Wasserfallmodell wurde in seiner urspr

unglichen Form zum ers-

ten Mal von Dr. Winston W. Royce 1970 pr

asentiert [

Roy87

]. Man

konnte aber bereits schon fr

uher die Grundstrukturen des heutigen

Wasserfallmodells in verschiedenen Publikationen der U.S. Air Force

2.1 VORGEHENSMODELLE

und aus der Industrie erkennen. Es fand z. B. Einfluss bei der Entwick-

lung eines Air Defense Software Systems namens SAGE (semi automated

ground environment) in den 1950ern [MRZ11].

Der Name

”

Wasserfall“ kommt von der h

aufig gew

ahlten grafischen

Darstellung der f

unf bis sechs als Kaskade angeordneten Phasen, wie

in Abbildung

2.116

zu sehen. Eigentlich ist das Wasserfallmodell eine

Verbesserung des einfachen Phasenmodells, das Herbert D. Benington

bereits 1956 vorgestellt hatte [

Ben56

]. In dem als Nine Phase Stage-

wise Model bekannten Ansatz wurde der Entwicklungsprozess f

Software in insgesamt 9Phasen eingeteilt. Royce’s Einteilung der

Phasen erfolgte so, dass jede Phase von ihrer vorhergehenden Phase

abh

angig ist. Somit war es m

oglich, den Prozess in Einzelteile zu

zerlegen [MRZ11].

Dass sich das Modell urspr

unglich nicht sonderlich durchsetzte lag

vor allem daran, dass kein Informationsfluss (engl. feedback) entgegen

des eigentlichen Phasenverlaufs existierte. Diese zu einem sp

ateren

Zeitpunkt eingef

uhrte Erweiterung des Modells, die auch als R

uck-

kopplung bezeichnet wird, ist auch die Ursache daf

ur, warum das

von Barry Boehm in den 80er Jahren vorgestellte Modell nicht nur

großes Interesse und viele Anwender fand, sondern noch heute als

das Wasserfall Modell bezeichnet wird [

Boe81

]. Die R

uckkopplung

erm

oglichte die Behebung aufgetretener Fehler in der n

achsth

oheren

Phase, sofern in der aktuellen Phase Fehler erkannt wurden. Das

Wasserfallmodell kann im Allgemeinen dort erfolgreich angewen-

det werden, wo sich Anforderungen, Leistungen und Abl

aufe in der

Planungsphase relativ pr¨

azise beschreiben lassen [MRZ11].

Es existieren zwei Varianten des Wasserfallmodells, eine Variante

mit 5Stufen und eine erweiterte Variante mit 6Stufen, die auch in

Abbildung 2.116 zu sehen ist.

Die 5-stufige Variante beinhaltet folgende Phasen [Wik11]:

1. Anforderungsanalyse und -spezifikation (engl. Requirement

analysis and specification)

Systemdesign und -spezifikation (engl. System design and specifi-

cation)

Programmierung und Modultests (engl. Coding and module tes-

ting)

Integrations- und Systemtest (engl. Integration and system testing)

Auslieferung, Einsatz und Wartung (engl. Delivery, deployment

and maintenance)

GRUNDLAGEN

Legende

Planung

Analyse

Entwurf

Realisierung

Testen

Nutzung

Konzeptionierung Entwicklung Einsatz

Phasen:

Abbildung 2.1: Ein erweitertes Wasserfallmodell mit R¨

uckkopplung.

Die erweiterte 6-stufige Variante ist in die folgenden Phasen aufge-

teilt [Wik11]:

1. Planung (mit Erstellung des Lastenhefts, Projektkalkulation,

Projektplan) (engl. Systems Engineering)

2. Analyse (mit Erstellung des Pflichtenhefts, Produktmodell,

GUI-Modell und evtl. schon Benutzerhandbuch) (engl. Analysis)

3. Entwurf (UML, Struktogramme) (engl. Design)

4. Realisierung (engl. Coding)

5. Testen (engl. Testing)

6. Nutzung und Wartung (engl. Maintenance)

Beim Wasserfallmodell muss jede Aktivit

at in der vorgegebenen Rei-

henfolge und in der vollen Breite vollst

andig durchgef

uhrt werden,

bevor eine neue Aktivit

at angefangen werden kann. Am Ende jeder

Aktivit

at steht ein fertiggestelltes Dokument, d. h. das Wasserfall-

Modell ist ein dokument-getriebenes Modell. Der Entwicklungsablauf

ist rein sequenziell, d. h. jede Aktivit

at muss komplett beendet sein,

bevor mit der n

achsten Aktivit

at begonnen werden kann. Das Wasser-

fallmodell orientiert sich am so genannten Top-Down-Verfahren. Es ist

einfach, verst

andlich und ben

otigt nur wenig Managementaufwand.

2.1 VORGEHENSMODELLE

Eine Benutzerbeteiligung ist nur in der Anfangsphase vorgesehen,

anschließend erfolgen der Entwurf und die Implementierung ohne

Beteiligung des Benutzers bzw. Auftraggebers. Weitere

Anderungen

stellen danach Neuauftr¨

age dar [Wik11].

Da es schwierig ist, bereits zu Projektbeginn alles endg

ultig und im De-

tail festzulegen, besteht das Risiko, dass die letztendlich fertiggestellte

Software nicht den tats

achlichen Anforderungen entspricht. Um dem

zu begegnen, wird oftmals ein unverh

altnism

aßig hoher Aufwand in

der Analyse- und Konzeptionsphase betrieben. Zudem erlaubt das

Wasserfallmodell nicht bzw. nur sehr eingeschr

ankt im Laufe des aktu-

ellen Projekts

Anderungen aufzunehmen. Die fertiggestellte Software

bildet folglich nicht den aktuellen, sondern den Anforderungsstand

zu Projektbeginn wieder. Da gr

oßere Softwareprojekte meist auch

eine sehr lange Laufzeit haben, kann es vorkommen, dass eine neue

Software bereits zum Zeitpunkt ihrer Einf

uhrung inhaltlich veraltet

ist [Wik11].

2.1.3 Spiralmodell

Das Spiralmodell ist ein Vorgehensmodell in der Softwareentwick-

lung, das im Jahr 1988 von Barry W. Boehm [

Boe88

] in seinem Artikel

”

A Spiral Model of Software Development and Enhancement“ be-

schrieben wurde. Es ist ein generisches Vorgehensmodell und daher

offen f

ur bereits existierende Vorgehensmodelle. Das Management

kann immer wieder eingreifen, da man sich spiralf

ormig voran ent-

wickelt [

Wik11

]. Das Spiralmodell geh

ort zu den inkrementellen bzw.

iterativen Vorgehensmodellen. Es ist eine Weiterentwicklung des Was-

serfallmodells, in der die Phasen mehrfach spiralf

ormig durchlaufen

werden. Es sieht also eine zyklische Wiederholung der einzelnen Pha-

sen vor. Dabei n

ahert sich das Projekt langsam den Zielen an, selbst

wenn sich die Ziele w

ahrend des Projektfortschrittes ver

andern. Durch

das Spiralmodell wird nach Boehm das Risiko eines Scheiterns bei

großen Softwareprojekten entscheidend verringert [Bal08].

Das Spiralmodell fasst den Entwicklungsprozess in der Software-

entwicklung als iterativen Prozess auf. Jeder Zyklus ist in einzelne

Quadranten unterteilt, die folgende Aktivit

aten enthalten (siehe Ab-

bildung 2.218):

1.Festlegung der Ziele:

In dieser Teilphase werden die Ziele der

laufenden Phase festgelegt, Alternativen identifiziert und Rah-

menbedingungen beschrieben.

2.Risikoanalyse:

Dieser Teil einer Iteration sch

atzt die Risiken ab

GRUNDLAGEN

Prototyp 1 Prototyp 2

betriebs-

fähiger

Prototyp

Risiko-

analyse

Risiko-

analyse

Risiko-

analyse

Konzept der

Anforderungen

Konzept

für Betrieb

Anforderungs-

plan

Grober Entwurf Feiner Entwurf

Verifikation

und

Validierung

Verifikation

und

Validierung

ImplementierungAbnahme

Testplanung

Entwicklungs-

planung

Anforderungen

Code

Integration

Test

Kosten

Review

1. Festlegung der Ziele 2. Risikoanalyse, Risiko eliminieren

4. Planung der nächsten Iteration 3. Entwicklung und Tests

Fortschritte

Abbildung 2.2: Spiralmodell nach Boehm.

und versucht sie zu reduzieren, z. B. durch Prototyping, Simulati-

on oder Analysen. Es werden Alternativen evaluiert, sollten die

Risiken zu hoch sein.

3.Entwicklung und Tests:

Das Zwischenprodukt wird w

ahrend

dieser Teilphase realisiert und verifiziert.

4.Planung der n¨

achsten Iteration:

Soll ein Projekt weiter gef

uhrt

werden, wird in dieser Teilphase die Planung der n

achsten aus-

zuf¨

uhrenden Schritte erarbeitet.

Ein wesentlicher Aspekt des Spiralmodells ist die Risikobetrachtung,

die von anderen Vorgehensmodellen meist vernachl

assigt wird. Hier-

bei werden zun

achst alle Risiken, die im Projekt auftreten k

onnen,

identifiziert und anschließend bewertet. Wird ein Risiko als zu hoch

bewertet versucht werden Alternativen mit geringerem Risiko gesucht.

Wird keine Alternative gefunden und das Risiko bleibt bestehen gilt

das Projekt als gescheitert. Wenn hingegen keine Risiken mehr exis-

tieren, so ist das Projekt kann das Projekt erfolgreich abgeschlossen

werden [Wik11].

2.1 VORGEHENSMODELLE

2.1.4 V-Modell

Das V-Modell ist eine abstrakte und umfassende Methode f

ur das

Projektmanagement zur Entwicklung und Realisierung von Softwa-

reprojekten. Dabei resultiert die Bezeichnung V-Modell einerseits aus

dem ersten Buchstaben von

”V

orgehensmodell“, andererseits aus der

V-f

ormigen Darstellung der Projektelemente aus Spezifikation und

Zerlegung (im absteigenden Ast) und Realisierung und Integration

im aufsteigenden Ast (siehe Abbildung 2.319).

Zeit

Detailisierung

Systemanforderungs-

analyse

Systemarchitektur

Systementwurf

Softwareentwurf

Softwarearchitektur Unit-Tests

Integrationstests

System Integration

Abnahme & Nutzung

Legende

Konzeptionierung Entwicklung Einsatz

Phasen:

Abbildung 2.3: Phasen des V-Modells ¨

uber Zeit und Detaillisierung.

Die Idee des V-f

ormigen Vorgehens wurde von Barry Boehm im Jahre

1979 vorgestellt [

Boe79

]. Das erste V-Modell wurde 1988 in Deutsch-

land f

ur milit

arische Zwecke entwickelt, ausgehend aus dem im Jahre

1986 gestarteten Projekt SEU-WS (Softwareentwicklungsumgebung

ur Waffen- und Waffeneinsatzsysteme) des Bundesverteidigungsmi-

nisteriums. In dieses erste V-Modell wurden dann bis April 1990 die

Erkenntnisse aus dem Projekt SEU-IS (Softwareentwicklungsumge-

bung f

ur Informationssysteme) integriert und die verbesserte Version

des V-Modells per Erlass vom Februar 1991 durch den Bundesminister

ur Verteidigung als Entwicklungsstandard f

ur die Softwareerstellung

bei der Bundeswehr festgeschrieben. Inzwischen wird das V-Modell

aber auch in der Privatwirtschaft eingesetzt [Wik11].

In der Regel wird eine neue Variante des V-Modells aus der jeweils

vorhergehenden Variante entwickelt, sobald ein Verbesserungsbedarf

GRUNDLAGEN

erkannt wird. Im Gegensatz zu einem klassischen Phasenmodell wer-

den im V-Modell lediglich Aktivit

aten und Ergebnisse definiert und

es wird keine strikte zeitliche Abfolge gefordert. Insbesondere fehlen

die typischen Abnahmen, die ein Phasenende definieren. Dennoch ist

es m

oglich, die Aktivit

aten des V-Modells zum Beispiel auf ein Was-

serfallmodell (Kapitel

2.1.214

) oder ein Spiralmodell (Kapitel

2.1.317

)

abzubilden [Wik11].

Ein zentraler Punkt des V-Modells ist die Detailisierung. Zu Beginn

wird

uber eine Systemanforderungsanalyse ermittelt, was die zu ent-

wickelnde Software leisten soll. Nach Abschluss dieser Phase erfolgt

die erste Detailisierung, in der die Ergebnisse der Systemanforderungs-

analyse f

ur die Entwicklung der Systemarchitektur verwendet werden

(siehe auch Abbildung

2.319

). Ist die Entwicklung an der Systemarchi-

tektur abgeschlossen, wird in einem weiteren Detailisierungsschritt

der Systementwurf erarbeitet. Weitere Detailisierungschritte folgen,

namentlich die Softwarearchitektur und der Softwareentwurf, d. h.

die eigentliche Realisierung der Software. Dies ist die feinste Stufe

der Detailisierung und nach Vollendung der Softwarearchitektur ist

die Software im Prinzip fertiggestellt. Was fehlt sind die Tests, die

das korrekte Arbeitender Software pr

ufen. Bei den Tests wird nun die

Detailisierung mit jeder Phase wieder verringert, so dass erst einzelne

Module (Units) auf ihre Funktionalit

at gepr

uft werden, danach das

Zusammenspiel der einzelnen Module miteinander (Integrationstests),

folgend von den Tests der Software auf den einzelnen Arbeitsplatz-

rechnern (Systemtests). Sind alle Tests erfolgreich wird die Software

abgenommen und kann genutzt werden [Wik11].

Ein Nachteil des V-Modells, der sofort auff

allt, ist die geringe Einbin-

dung des Benutzers in den Entwicklungsprozess und das Fehlen von

Prototypen f

ur Tests. Somit wird die Software erst einmal komplett

entwickelt. Dies hat zur Folge, dass die Systemanforderungsanalyse

sehr detailliert ausfallen muss, da logische Fehler, wurden sie nicht

erkannt, sehr schwer zu beheben sind.

2.1.5 Norm ISO/IEC 12207

ISO/IEC 12207 definiert einen Rahmen f

ur Prozesse im Lebenszyklus

von Software (engl. Software Life-Cycle Processes) [

ISO95

]. In Abbil-

dung

2.421

sind die verschiedenen Phasen eines Lebenszyklus von

Software dargestellt. Die Norm beschreibt auf einer sehr abstrak-

ten Ebene alle wichtigen Prozesse des Lebenszyklus einer Software,

von der Ideenfindung bis hin zur Stilllegung und den Beziehungen

untereinander. Die in der Norm definierten Prozesse bestehen aus

Aktivit

aten, die in sich wiederum aus einzelnen Aufgaben bestehen.

2.1 VORGEHENSMODELLE

ISO/IEC 12207 definiert eine Prozessstruktur unter Verwendung einer

allgemein akzeptierten Terminologie, sie legt sich nicht fest auf ein

bestimmtes Lebenszyklusmodell oder eine bestimmte Entwicklungs-

methode. Es werden keine Details bez

uglich des Konzepts bei der

Durchf

uhrung der Aktivit

aten und Aufgaben und auch keine Vor-

schriften bez

uglich Namen, Formaten oder Inhalten von Dokumenten

vorgegeben [Wik11].

Zus

atzlich beschreibt ISO/IEC 12207 wie der Standard auf eine be-

stimmte Organisation oder auf ein konkretes Projektvorhaben zuge-

schnitten werden kann [Wik11].

Analyse/Entwurf Implementierung

Test

Einführung

Anforderungen

Pflege/Wartung

Änderungen

Organisatorische Aspekte Informationstechnische Aspekte

Legende

Konzeptionierung Entwicklung Einsatz

Phasen:

Abbildung 2.4: Phasen eines Softwarelebenszyklus.

Die Norm beschreibt folgende drei Prozesse [ISO95]:

– Prim¨

arprozesse:

Die grundlegenden Prozesse f

ur die Verwendung

der ISO/IEC 12207. Folgende Prozesse sind dabei involviert:

GRUNDLAGEN

Beschaffung:

Stellt die Aktivit

aten des Beschaffers von Software

und Dienstleistungen dar

Lieferung:

Beschreibt die Aktivit

aten des Lieferers von Software

und Dienstleistungen

Entwicklung: Aktivit¨

aten der Entwicklung der Software

Betrieb:

Zu diesen Aktivit

aten z

ahlen Systemeinf

uhrung und

Systemtests sowie die Benutzerunterst¨

utzung

Wartung:

Fehlerbehebung und Beseitigung von M

angel, Ver-

besserung des Durchsatzes, Anpassung an ein ver

andertes

Umfeld, etc.

– Unterst¨

utzende Prozesse:

Diese Prozesse unterst

utzen andere Pro-

zesse, in dem sie spezielle Funktionalit

aten zur Verf

ugung stel-

len, die nachfolgend beschreiben werden:

Dokumentation:

Dokumentieren der gesamten Software

uber

die verschiedenen Phasen hinweg

Konfigurationsmanagement:

Aktivit

aten f

ur organisatorische

und verhaltensm

aßige Regeln auf den Produktlebenslauf

der Software von seiner Entwicklung ¨

uber Herstellung bis

hin zur Betreuung

Qualit¨

atssicherung:

Aktivit

aten zum Sicherstellen des festge-

legtes Qualit¨

atsniveaus der Software

Verifizierung: Formale ¨

Uberpr¨

ufung der Prozesse

Validierung:

Aktivit

at zur inhaltlichen

Uberpr

ufung der Pro-

zesse

Joint Review:

Aktivit

at zur Abstimmung zwischen dem Kun-

den und dem Lieferant/Entwickler

Audit:

Untersuchungsverfahren zur Bewertung der Erf

ullung

von den Anforderungen und Richtlinien der Prozesse

Problembehebung:

Aktivit

at zur Behebung von Problemen bei

Prozessen

– Unternehmensprozesse:

Die Unternehmensprozesse sollen speziel-

le Prozesse auf Unternehmensebene verwalten und verbessern:

Management:

Umfasst die Steuerung von Kernprozessen im

gesamten Prozess, mit dem Fokus auf Strukturierung der

organisatorischen Rollen und deren Aufgaben

Infrastruktur:

Aktivit

aten zur Bereitstellung der notwendigen

Infrastruktur wie z.B. Hardware, Software oder Werkzeuge

2.1 VORGEHENSMODELLE

Optimierung:

Messen,

Uberpr

ufen, Verbessern der Lebenszy-

klusprozesse

Schulungsmaßnahmen:

Aktivit

at zur Schulung der Benutzer

der Software

Da die Norm ISO/IEC 12207 einen Lebenszyklus einer Software be-

schreibt, ist diese nicht mit den anderen Vorgehensmodellen vergleich-

bar. Trotzdem kann man Aussagen bzgl. einiger Eigenschaften des

Vorgehensmodells treffen. Die drei Prozesse, die die Norm vorschl

agt,

sind gr

oßtenteils nebenl

aufig, d. h. parallel bearbeitbar. Das ist ein

großer Vorteil, da sich mehrere Teams mit verschiedenen Aufgaben

gleichzeitig besch

aftigen k

onnen.

Uber die gew

ahlte Implementierung

und das Vorgehen bei der eigentlichen Softwareentwicklung wird

nichts vorgeschrieben, d. h. hier k

onnen wieder klassische Modelle

(Wasserfall-Modell. Spiralmodell) benutzt werden. Die Norm ist aus-

gelegt f

ur gr

oßere Projekte, denn f

ur kleine bis mittlere Produktionen

urde zuviel Mehrarbeit in die Organisation und Verwaltung fließen.

2.1.6 Norm DIN ISO 13407

Die Norm DIN EN ISO 13407 (Benutzerorientierte Gestaltung interak-

tiver Systeme) [

ISO99

] beschreibt einen prototypischen benutzerorien-

tierten Softwareentwicklungsprozess. Sollten die Empfehlungen der

Norm DIN EN ISO 13407 erf

ullt werden kann ein spezieller Entwick-

lungsprozess als konform betrachtet werden. Die DIN EN ISO 13407

wurde im November 2000 in der deutschen Fassung als DIN-Norm

ver¨

offentlicht [Wik11].

Die Norm besteht in ihrem Aufbau sowohl aus den Beschreibungen

der Planung benutzerorientierter Gestaltung, als auch aus Erl

auterun-

gen zur Entwicklung interaktiver Systeme, die sich darauf konzentrie-

ren, benutzerfreundliche Systeme zu erschaffen. Sie beschreiben in

kurzer,

ubersichtlicher und f

ur eine Norm gut lesbaren Form einen

iterativen Entwicklungsprozess, bei dem Nutzer- und Aufgabeneigen-

schaften die Entwicklung der Software bestimmen. Außerdem enth

alt

die Norm weitere Richtlinien und Tabellen f

ur das Berichten

uber

benutzerorientierte Aktivit¨

aten [Wik11].

Die Norm stellt nutzerorientierte Gestaltung als eine fach

ubergreifen-

de Aktivit

at dar, die Wissen

uber menschliche Faktoren und ergono-

mische Kenntnisse und Techniken umfasst. Der ISO-Prozess besteht

aus vier wesentlichen Phasen [ISO99]:

1.Nutzungskontext verstehen:

Das Ergebnis dieser Phase ist eine

GRUNDLAGEN

Anforderungsanalyse

Benutzeranalyse

TätigkeitsanalyseEvaluation

Prototyp

Legende

Konzeptionierung Entwicklung Einsatz

Phasen:

Entwurf

Abbildung 2.5: DIN EN ISO 13407: Der Entwicklungsprozess

Beschreibung der relevanten Benutzer, ihrer Arbeitsaufgaben

und ihrer Umgebung.

2.Anforderungen spezifizieren:

ahrend dieser Phase werden

die Zielgr

oßen aus der bereits vorhandenen Dokumentation auf

einer Kompromissebene abgeleitet. Dabei wird die Teilung der

Systemaufgaben in solche, die von Menschen und in solche, die

von der Technik durchgef¨

uhrt werden, sollen bestimmt.

3.L¨

osungen produzieren:

Dies kann im Sinne eines Prototyping

oder eines anderen iterativen Prozesses erfolgen. Diese Proto-

typen k

onnen noch reine Papierentw

urfe (Mock-ups) oder aber

schon lauff¨

ahige Programmversionen sein.

4.L¨

osungen bewerten:

Die L

osungen werden auf die Erf

ullung

der zuvor festgelegten Anforderungen gepr

uft. Dazu k

onnen

Experten-Reviews, Usability-Tests, Befragungen oder auch eine

Mischung daraus dienen. Die dabei entdeckten Abweichungen

werden dann auf ihre Relevanz hin bewertet und sind Ausgangs-

punkt der n¨

achsten Iteration des Entwicklungsprozesses.

Dieses Verfahren ist komplement

ar zu bestehenden Prozessmodellen

des Software-Engineering und erg

anzt diese. Der benutzerorientierte

Gestaltungsprozess sollte der Norm zufolge bereits im fr

uhesten Sta-

2.1 VORGEHENSMODELLE

dium des Projekts beginnen und sollte dann wiederholt durchlaufen

werden, bis das System die Anforderungen erf¨

ullt [Wik11].

Die DIN EN ISO 13407 stellt einen interaktiven, benutzerzentrierten

Entwurfsprozess dar, der Prototypen f

ur die Benutzeranalyse verwen-

det. Zu Anfang der Entwicklung werden die Anforderungen an die

Software festgelegt. Diese Anforderungen k

onnen im laufenden Pro-

zess nicht mehr ver

andert oder erweitert werden, so dass diese Phase

sehr ausf

uhrlich und gewissenhaft erarbeitet werden sollte. Sind die

Anforderungen an die Software bekannt, beginnt die erste Iteration

mit der Benutzeranalyse, bei der die relevanten Aufgaben der Benut-

zer identifiziert werden. Die n

achste Phase analysiert die T

atigkeit, die

einerseits vom Benutzer und andererseits von der Software geleistet

werden soll. Es folgt die Entwicklung eines Prototypen, der von den

Benutzern getestet werden kann. Die Ergebnisse dieser Tests werden

in der n

achsten Phase evaluiert und bewertet. Daraus folgt die n

achste

Iteration, oder, falls die Software den Anforderungen entspricht, der

Entwurf. Bei dem Prozess werden die Prototypen in jeder Iteration

neu entwickelt, es findet keine Weiterentwicklung statt.

Die DIN EN ISO 13407 wurde Anfang 2011 durch die Norm DIN EN

ISO 9241-210 [

ISO11

] ersetzt, auf die ich allerdings in dieser Arbeit

nicht weiter eingehen werde.

2.1.7 Modellgetriebene Softwareentwicklung (MDSD)

Modellgetriebene Softwareentwicklung (engl. Model Driven Software

Development, MDSD) ist ein Oberbegriff f

ur Techniken, die aus for-

malen Modellen automatisiert lauff

ahige Software bzw. kompilierba-

ren Quelltext erzeugen [

SVEH07

]. Dabei werden dom

anenspezifische

Sprachen (engl. Domain-Specific Languages, DSL) zusammen mit ent-

sprechenden Codegeneratoren und Interpretern eingesetzt [Wik11].

Bei MDSD nach Stahl et al. [

SVEH07

] geht es darum, sich bei der

Entwicklung von Softwaresystemen m

oglichst nicht zu wiederholen

(DRY-Prinzip – Don’t-Repeat-Yourself). Weil allein mit den Mitteln der

jeweiligen Programmiersprache nicht immer passende Abstraktionen

zur Beschreibung verschiedener Sachverhalte (Domain) eines Softwa-

resystems gefunden werden k

onnen, werden unabh

angig von der

Zielsprache entsprechende Abstraktionen in Form von dom

anenspe-

zifischen Sprachen erschaffen. Diese werden dann entweder generativ

oder interpretativ auf die Zielplattform abgebildet [SVEH07].

Nat

urlich hat der Einsatz dieser Variante eine Auswirkung auf allen

Ebenen eines Projektes, sowohl technisch und fachlich als auch im

GRUNDLAGEN

Managementbereich. Deshalb beschreibt die MDSD nicht nur, wie

man DSLs, Generatoren usw. entwickelt, sondern auch, wie man

diese in (haupts

achlich agilen) Entwicklungsprozessen sinnvoll inte-

griert [SVEH07].

Durch den erh

ohten Abstraktionsgrad der DSLs sind die Problem-

beschreibungen wesentlich klarer, einfacher und weniger redundant

festgehalten. Dies erh

oht nicht nur die Entwicklungsgeschwindig-

keit, sondern sorgt innerhalb eines Projektes f

ur klar verstandene

Dom

anenkonzepte. Das Konzept der omnipr

asenten Sprache (engl.

Ubiquitous Language) aus dem Domain-Driven Design wird hier auf die

Konzeptebene der Softwarearchitektur angewandt [SVEH07].

Weiterhin wird die Evolution der Software durch die Trennung der

technischen Abbildung und der fachlichen Modelle wesentlich verein-

facht. Auch das Testen f

allt leichter, da nicht mehr jede einzelne Zeile

Quelltext getestet werden muss, sondern nur noch exemplarisch die

Modelle. Dom

anenspezifische Validierung in den Entwicklungswerk-

zeugen sorgt f¨

ur sehr kurze Turnarounds [SVEH07].

ur MDSD existieren eine Vielzahl an Werkzeugen, die jeweils nur

einzelne Aspekte, wie z. B. die Modellierung, oder alle Funktionalit

unterst¨

utzen [Wik11].

•Reine Modellierungswerkzeuge:

Sie dienen lediglich zur grafi-

schen Darstellung und unterst

utzen keine automatischen Trans-

formationen. Das Modell wird hier in ein Austauschformat (bei-

spielsweise XMI

) exportiert und mit gesonderten Transformato-

ren weiterbearbeitet.

•Reine Transformatoren:

Diese dienen ausschließlich der Trans-

formation von Modellen und beinhalten keine grafischen Model-

lierungsfunktionalit

aten. Die Modelle werden in einem bestimm-

ten Austauschformat in ein internes Modellformat importiert,

transformiert und danach wieder exportiert.

•Integrierte MDD-Werkzeuge:

Diese bieten Modellierung, Mo-

delltransformationen und Codegenerierung geb

undelt in einem

Werkzeug.

Uberfl

ussige Export- und Importvorg

ange, Kompati-

bilit

atsprobleme beim Datenaustausch und R

ustaufwand bzgl.

Integration werden vermieden. Die Navigierbarkeit und Syn-

chronisation zwischen fachlichem und technischem Modell und

Implementierungscode wird optimal unterst¨

utzt.

1XMI steht f¨

ur XML Metadata Interchange und ist ein Austauschformat f¨

ur Metadaten in XML.

2.1 VORGEHENSMODELLE

Anforderungen

Analyse

EntwicklungValidierung

Low-Level Design

Einsatz

Auf Text basierend

Plattformunabhängiges Modell

Plattformabhängiges Modell

Quellcode

Anwendung

Legende

Konzeptionierung Entwicklung Codegenerierung

Phasen:

Abbildung 2.6: Modellgetriebene Softwareentwicklung.

Der Entwicklungsprozess beim MDSD kann variabel sein. Gr

oßten-

teils ist es aber ein iterativer Top-Down Ansatz, der Prototypen mit

ber

ucksichtigt. Alleine schon die Vorgehensweise, wie die Modelle ent-

wickelt werden, und dass die Codegenerierung und das Erstellen der

endg

ultigen Applikation computergest

utzt verl

auft, macht einen itera-

tiven Prozess unter Benutzung von Prototypen sinnvoll. In Abbildung

2.627

wird ein generischer MDSD Prozess dargestellt. Die Annota-

tionen an den

Uberg

angen von einer Phase zur n

achsten beinhalten

die jeweilige Form der Applikation. Nachdem die Anforderungen

benannt sind, werden sie meist in textbasierte Form (DSL) an die

Entwickler weiter gegeben. Diese analysieren die Anforderungen und

entwickeln ein erstes Modell, das meist plattformunabh

angig ist. Ist

das Modell zufriedenstellend, wird das Low-Level Design entwickelt,

sodass das Modell auf der sp

ateren (Hardware-)Plattform lauff

ahig ist.

Ist die Anpassung, vollendet wird die Applikation mit Hilfe von Code-

generatoren in Quelltext transformiert und

ubersetzt. Dies geschieht

automatisch und am Ende des Prozesses steht die lauff

ahige Applika-

tion. Diese wird nun eingesetzt und getestet. Sollten Fehler auftreten

oder die Applikation um Funktionalit

at erweitert werden, m

ussen die

Anderungen erst im plattformunabh

angigen Modell korrigiert bzw.

zugef¨

ugt werden.

GRUNDLAGEN

2.1.8 Feature Driven Development (FDD)

Funktionsgetriebene Softwareentwicklung (engl. Feature Driven Deve-

lopment, FDD) wurde von Jeff De Luca im Jahre 1998 als eine schlanke

Methode f

ur zeitkritische Softwareentwicklung definiert [

DL98

]. Seit

der Zeit wurde FDD kontinuierlich weiterentwickelt. FDD stellt den

Feature-Begriff in den Mittelpunkt der Entwicklung. Jedes Feature

stellt einen Mehrwert f

ur den Kunden dar. Die Entwicklung wird

anhand eines Feature-Plans organisiert. Eine wichtige Rolle spielt der

Chefarchitekt (engl. Chief Architect), der st

andig den

Uberblick

uber

die Gesamtarchitektur und die fachlichen Kernmodelle beh

alt. Bei

oßeren Teams werden einzelne Entwicklerteams von den Chefpro-

grammierern (engl. Chief Programmer) gef¨

uhrt [WRL05] [PF02].

FDD definiert ein Prozess- und ein Rollenmodell, die gut mit exis-

tierenden klassischen Projektstrukturen harmonieren. Daher f

allt es

vielen Unternehmen leichter, FDD einzuf

uhren als XP (siehe Kapitel

2.1.1031

) oder Scrum (siehe Kapitel

2.1.1134

). Des Weiteren ist FDD

ganz im Sinne der agilen Methoden sehr kompakt und l

asst sich auf

wenigen Seiten komplett beschreiben [DL04].

Entwicklung des

Gesamtmodell

Erstellen der

Featureliste

Planung für

jedes Feature

Entwurf

jedes Features

Konstruktion

jedes Features

Legende

Gesamtmodell Featureplanung Featureentwurf

Phasen:

Abbildung 2.7: Feature Driven Development.

FDD-Projekte durchlaufen f

unf Prozesse, wie sie in Abbildung

2.7

sehen sind.

Prozess 1- Entwicklung eines Gesamtmodells: Im ersten Prozess

definieren die Fachexperten und Entwickler unter Leitung des

Chefarchitekten Inhalt und Umfang des zu entwickelnden Sys-

tems. In Kleingruppen werden Fachmodelle f

ur die einzelnen

Bereiche des Systems erstellt, die in der Gruppe vorgestellt, ggf.

uberarbeitet und schließlich integriert werden. Das Ziel dieser

ersten Phase ist ein Konsens

uber Inhalt und Umfang des zu

entwickelnden Systems sowie das fachliche Kernmodell [

DL04

Prozess 2- Erstellung einer Feature-Liste:

Die aus dem ersten Pro-

zess festgelegten Systembereiche werden von dem jeweiligen

2.1 VORGEHENSMODELLE

Chefprogrammierer in Features detaillieren. Es wird ein drei-

stufiges Schema verwendet: Fachgebiete (engl. Subject Areas)

bestehen aus Gesch

aftst

atigkeiten (engl. Business Activities), die

durch Schritte (engl. Steps) ausgef

uhrt werden. Die Schritte ent-

sprechen den Features. Die Features werden nach dem einfa-

chen Schema

Aktion

> <

Ergebnis

> <

Objekt

aufgeschrieben.

Ein Feature darf maximal zwei Wochen zu seiner Realisierung

ben

otigen. Das Ergebnis dieses zweiten Prozesses ist eine ka-

tegorisierte Feature-Liste, deren Kategorien auf oberster Ebene

von den Fachexperten aus dem ersten Prozess stammen [

DL04

Prozess 3- Planung jedes Feature: Projektleiter, Entwicklungsleiter

und die Chefprogrammierer planen die Reihenfolge, in der Fea-

tures realisiert werden sollen. Dabei richten sie sich nach den

Abh

angigkeiten zwischen den Features, der Auslastung des

jeweiligen Programmierteams sowie der Komplexit

at der Fea-

tures. Auf Basis des Plans werden die Fertigstellungstermine je

Gesch

aftsaktivit

at festgelegt. Jede Gesch

aftsaktivit

at bekommt

einen Chefprogrammierer als Besitzer zugeordnet. Außerdem

werden f

ur die bekannten Kernklassen Entwickler als Besitzer

festgelegt (engl. Class Owner List) [DL04].

Prozess 4- Entwurf jedes Feature: Die Chefprogrammierer

weisen die anstehenden Features den Entwicklerteams auf Basis

des Klassenbesitztums zu. Die Entwicklerteams erstellen ein

oder mehrere Sequenzdiagramme f

ur die Features, die Chef-

programmierer verfeinern die Klassenmodelle auf Basis der Se-

quenzdiagramme. Die Entwickler schreiben dann erste Klassen-

und Methodenr

umpfe. Schließlich werden die erstellten Ergeb-

nisse inspiziert. Bei fachlichen Unklarheiten k

onnen die Fachex-

perten hinzugezogen werden [DL04].

Prozess 5- Konstruiere jedes Feature:

Die Entwickler programmie-

ren die im vierten Prozess vorbereiteten Features. Zur Qualit

ats-

sicherung werden bei der Programmierung sowohl Komponen-

tentests als auch Code-Inspektionen eingesetzt [DL04].

FDD ist ein sehr kompaktes Vorgehensmodell, das sich im Allgemei-

nen schnell in Unternehmen umsetzten l

asst, vorausgesetzt die zu

entwickelnde Software kann auf die f

ur die Entwicklung zentralen

Features reduziert werden. Um eine schnelle Fertigstellung der ein-

zelnen Features zu erreichen, sollten diese nicht zu komplex sein,

da sonst die Implementierung viel Zeit kosten w

urde. Da jedoch bei

FDD der Fokus nicht auf kurzen Iterationen zwischen den Softwa-

reversionen liegt, kann der oben genannte Punkt im Allgemeinen

vernachl

assigt werden. Im weitesten Sinne kann mein Verfahren, das

GRUNDLAGEN

ich in dieser Arbeit vorstelle, auch als FDD gesehen werden, allerdings

wird in meinem Prozess auf die kurzen Iterationen geachtet und des-

halb die Features, die implementiert werden sollen, sehr feingranular

aufgeteilt.

2.1.9 Rational Unified Process

Der Rational Unified Process (RUP) [

WIN+06

] ist ein kommerzielles Pro-

dukt der Firma Rational Software, die seit 2002 Teil des IBM Konzerns

ist. IBM entwickelt den RUP und die zugeh

orige Software weiter. Die

neunte Version vom Jahre 2006 ist die derzeit die aktuelle Version.

Der RUP benutzt die Unified Modeling Language (UML) als Notati-

onssprache. Der RUP wurde von Philippe Kruchten [

KR96

] in seiner

Urform erstmals 1996 vorgestellt.

Der RUP war m

oglich geworden, als sich die bekannten Program-

mierer Grady Booch, Ivar Jacobson und James Rumbaugh des Unter-

nehmens Rational Inc. auf ein einheitliches Notationssystem einigen

konnten. Als Resultat dieser Bem

uhungen entstand die UML. Die Stan-

dardisierung und Weiterentwicklung der Sprache wurde an die Object

Management Group (OMG)

ubergeben. Mit einer gemeinsamen Sprache

konnte nun eine gemeinsame objektorientierte Methode entwickelt

werden. Der Unified Process ist dabei ein Metamodell f

ur Vorgehens-

modelle zur Softwareentwicklung und wurde parallel zur Unified

Modelling Language von den oben genannten Personen entwickelt und

ver¨

offentlicht [Wik11].

Der Unified Process basiert auf mehreren Prinzipien [Wik11]:

•Anwendungsf¨

allen

•Architektur im Zentrum der Planung

•inkrementellem und iterativen Vorgehen

Eine konkrete Implementierung des oben beschriebenen Unified Pro-

cess ist der Rational Unified Process. Die erste Version des RUP aus

dem Jahre 1999 [

Kru99

] [

JBR99

] f

uhrte die Vorschl

age der drei oben

genannten Begr

under f

ur eine einheitliche Methode zur Modellierung

zusammen [Wik11].

Der Rational Unified Process legt grundlegende Arbeitsdisziplinen fest

(siehe auch Abbildung

2.831

). Die Kernarbeitsdisziplinen sind die

Gesch

aftsprozessmodellierung (engl. Business Modeling), die Anfor-

derungsanalyse (engl. Requirements), Analyse & Design (engl. Ana-

lysis & Design), die Implementierung (engl. Implementation) und der

2.1 VORGEHENSMODELLE

Phasen

Iterationen

Konzeptionsphase Entwurfsphase Konstruktionsphase Übergabephase

Initialisierung Entwurf

Entwurf

Konstr.

... Über-

gang 1

Über-

gang 2

Geschäftsprozess-

modellierung

Anforderungsanalyse

Analyse & Design

Konfigurations- &

Änderungsmanagement

Test

Auslieferung

Projektmanagement

Infrastruktur

Implementierung

Arbeitsdiszilinen

Abbildung 2.8: Rational Unified Process.

Test (engl. Test) und die Auslieferung (engl. Deployment). Zu den un-

terst

utzenden Arbeitsdiszilinen geh

ort das Konfigurations- &

Ande-

rungsmanagement (engl. Configuration & Change Management), das

Projektmanagement (engl. Project Management) und die Infrastruktur

(engl. Environment) [Wik11].

Orthogonal zu den Arbeitsdisziplinen gibt es im Rational Unified Pro-

cess vier Phasen, in der jeder der Diszilinen mehr oder weniger intensiv

zur Anwendung kommt. Die Phasen sind die Konzeptionsphase (engl.

Inception), die Entwurfsphase (engl. Elaboration), die Konstruktions-

phase (engl. Construction) und die

Ubergabephase (engl. Transition).

Diese Phasen sind in sich in Iterationen unterteilt, so dass der Rational

Unified Process ein iteratives Vorgehensmodell ist. Resultate der Phasen

sind die so genannten Meilensteine (engl. Milestones) [Wik11].

2.1.10 Extreme Programming (XP)

Extreme Programming (XP), oder auch Extremprogrammierung, ist eine

Methode, die das L

osen einer Programmieraufgabe in den Vorder-

grund der Softwareentwicklung stellt und dabei einem formalisierten

Vorgehen geringere Bedeutung zumisst. Diese Vorgehensweise de-

GRUNDLAGEN

finiert ein Vorgehensmodell, welches sich den Anforderungen des

Kunden in kleinen Schritten ann¨

ahert [AH02].

Extreme Programming wurde von Kent Beck, Ward Cunningham und

Ron Jeffries w

ahrend ihrer Arbeit im Projekt Comprehensive Compensa-

tion System (C3-Projekt) bei Chrysler zur Erstellung von Software ent-

wickelt. Die Arbeiten am C3-Projekt begannen 1995 und wurden 2000

nach der

Ubernahme durch Daimler eingestellt. Die dabei entwickelte

Software wurde im Bereich der Lohnabrechnung eingesetzt [Sys06].

Lifecycle

Entwicklung

Integration

Testen

Risikoanalyse

Nutzenanalyse

Prototyping

Akzeptanz

Entwicklungsrahmen

Start

Iteration

Abbildung 2.9: Lebenszyklus des Extreme Programming.

XP ist ein durch fortlaufende Iterationen und den Einsatz mehrerer

Einzelmethoden strukturierendes Vorgehensmodell (siehe Lebenszy-

klus in Abbildung

2.9

). Es entstand durch die Synthese verschiedener

Disziplinen der Softwareentwicklung und basiert auf in der Praxis

bew

ahrten Methoden, auch Best Practice

genannt. XP folgt einem

strukturierten Vorgehen und stellt die Teamarbeit, Offenheit und stete

Kommunikation zwischen allen Beteiligten in den Vordergrund. Dabei

ist die Kommunikation eine Grunds

aule von Extreme Programming.

Die Methode geht davon aus, dass der Kunde die Anforderungen

an die zu erstellende Software zu Projektbeginn noch nicht komplett

kennt und nicht hinreichend strukturieren kann beziehungsweise

das mit der Realisierung betraute Entwicklerteam nicht

uber alle In-

formationen verf

ugt, um eine verl

assliche Aufwandssch

atzung

uber

die notwendige Dauer bis zum Abschluss zu geben. Im Laufe eines

Projektes

andern sich nicht selten Priorit

aten und Gewichte. Zu Be-

Die Bezeichnung Best Practice stammt aus der Betriebswirtschaft und bezeichnet eine bew

ahrte bzw.

optimale Vorgehensweise in einem Unternehmen.

2.1 VORGEHENSMODELLE

ginn geforderte Funktionen der Software werden m

oglicherweise in

einer anderen Form ben

otigt oder im Laufe der Zeit sogar komplett

hinf¨

allig [Wik11].

Bei einer konsequenten Ausrichtung an XP soll die zu erstellende

Software schneller bereitgestellt sowie eine h

ohere Softwarequalit

und Zufriedenheit des Kunden erreicht werden, als es mit den tra-

ditionellen Ans

atzen m

oglich ist. Der Kunde soll ein einsatzbereites

Produkt erhalten, an dessen Herstellung er aktiv teilgenommen hat.

Neue Funktionalit

at wird permanent entwickelt, integriert und getes-

tet. Um zu der zu entwickelnden Funktionalit

at zu gelangen, werden

jeweils die Schritte Risikoanalyse, Nutzenanalyse, die Bereitstellung ei-

ner ersten ausf

uhrbaren Version (Prototyping) und ein Akzeptanztest

durchgef¨

uhrt [Bec00].

Nach Vertretern dieses Vorgehensmodells ist XP ein Risikomanage-

ment. Es bejaht das Risiko, geht aktiv darauf ein und versucht, es zu

minimieren. Dieser implizite Umgang mit dem Faktor Risiko steht

im Gegensatz zu eher expliziten Vorgehensweisen, wie der Aufstel-

lung einer Risikoliste [

DeM03

]. Softwareentwicklungsprojekte sind

unterschiedlichen Gefahren ausgesetzt, f

ur die XP L

osungen anbieten

soll [Wik11].

Dem Kunden bietet XP, gerade durch seine kurzen Entwicklungszy-

klen, jederzeit die M

oglichkeit, steuernd auf das Projekt einzuwir-

ken. Dadurch soll erreicht werden, dass sich das Produkt aktuellen

Anforderungen anpasst, statt

uberholten Anforderungen aus einer

angst vergangenen Analysephase zu gen

ugen und damit bereits bei

Einf

uhrung veraltet zu sein. Zudem kann der Kunde bereits nach

kurzer Zeit ein unvollst

andiges, aber zumindest funktionst

uchtiges

Produkt einsetzen. Der Kunde ist im besten Fall jederzeit auf dem-

selben aktuellen Informationsstand bez

uglich des Projektes wie das

Entwicklerteam [Wik11].

Aus der Sicht der Programmierer existiert keine strikte Rollentren-

nung, da die Aufgabenverteilung abh

angig von Situation und F

ahig-

keiten geschieht. Der allgemeine Wissensaustausch und die stetige

Kommunikation beugen einem Wissensmonopol vor. Dies soll den

Einzelnen entlasten, wohingegen der Druck auf einer Person lastet,

wenn diese sich als Einzige in einem Modul auskennt [Wik11].

Dem Projekt bietet XP die M

oglichkeit, Risiken zu minimieren. So

sollte unter richtiger Anwendung von XP der Kunde Software erhal-

ten, deren Umfang ihn nicht

uberrascht. Das Team soll ferner gegen

Krankheit Einzelner nicht mehr so anf

allig sein. Ein ehrlicher Umgang

mit dem Kunden soll die Glaubw

urdigkeit und Zufriedenheit steigern

GRUNDLAGEN

und die Angst minimieren, die unter Umst

anden zwischen Kunde

und Entwicklung vorherrscht [Wik11].

XP stellt aus wirtschaftswissenschaftlicher Sicht eine Form der Orga-

nisation dar, die direkt die Prozesse der Wertsch

opfung

beschreibt.

In den Wirtschaftswissenschaften werden zur Bewertung von Extreme

Programming auch Erkenntnisse anderer Sozialwissenschaften, insbe-

sondere der Soziologie, genutzt [Wik11].

Vereinzelt wird Extreme Programming als informelle und damit unver-

bindliche Methode bezeichnet. Das trifft jedoch weder den Ansatz

noch das Ziel. Tats

achlich ist die Formalisierung der Methode des

Extreme Programming bewusst flach und schlank gehalten. Hinge-

gen muss ein Einvernehmen zwischen Kunden und Programmierern

hinsichtlich der Verbindlichkeit der erstellten Unterlagen hergestellt

werden, solange diese noch nicht durch neuere Fassungen ersetzt

wurden. Weiter muss der Vorgang des Ersetzens einer Fassung einer

Unterlage durch eine neuere Fassung dieser Unterlage soweit formali-

siert sein, dass beide Parteien Kenntnis von dieser Ersetzung haben

und diese Ersetzung annehmen [Wik11].

Extreme Programming ist die Summe einzelner, gemeinsam zur Op-

timierung des Nutzens eingesetzter Erfolgsmethoden. XP definiert

sich selbst mit diesen Prinzipien, allerdings nicht als Patentl

osung f

alle Probleme. Da, wo es speziellen oder individuellen Anforderun-

gen nicht gen

ugt, soll es angepasst werden. Viele Prinzipien greifen

verzahnt ineinander. Einzelne Praktiken sind an sich nicht neu und

werden teilweise bereits lange genutzt, oder sind sogar von trivialer

und doch oft untersch

atzter Natur. Die Praktiken sind die greifbaren,

konkreten Maßnahmen, die sich aus den Werten und den Prinzipien

ableiten lassen [Wik11].

2.1.11 Scrum

Scrum (engl. das Gedr

ange) ist ein Vorgehensmodell, dass auf Treffen

(engl. Meetings), Artefakten, Rollen, Werten und Grund

uberzeugun-

gen basiert und beim Entwickeln von Produkten im Rahmen agiler

Softwareentwicklung hilfreich ist. Teammitglieder organisieren ihre

Arbeit weitgehend selbst und w

ahlen auch die eingesetzten Software-

Entwicklungswerkzeuge und -Methoden. Ken Schwaber, Jeff Suther-

land und Mike Beedle haben Scrum erfunden und in der Softwareent-

wicklung etabliert [

BDS+99

]. Als Methode zur Entwicklung von Soft-

Der Begriff Wertsch

opfung ist in einer Geldwirtschaft das Ziel produktiver T

atigkeit. Diese

transformiert vorhandene G

uter in G

uter mit h

oherem Geldwert. Die allgemeine Formel lautet:

Wertsch¨

op f ung =Gesamtleistung −Vorleistungen.

2.1 VORGEHENSMODELLE

ware wird Scrum das erstmalig im Buch

”

Wicked Problems, Righteous

Solutions“ [

DS90

] beschrieben. Scrum in Produktionsumgebungen

wird zum ersten Mal im Artikel

”

The New New Product Development

Game“ [

Gam86

] erl

autert und sp

ater in der Ver

offentlichung

”

The

Knowledge Creating Company“ [NT95] weiter ausgef¨

uhrt [Wik11].

Im Jahre 2003 legte Ken Schwaber ein Zertifizierungsprogramm f

Scrum Master auf. Das Ziel, heute wie damals, ist es, die Software-

Entwicklung durch das Nutzen von Scrum zu professionalisieren.

Inzwischen wird das Training Certified Scrum Master unter der Schirm-

herrschaft der Scrum Alliance durchgef¨

uhrt [Wik11].

Produkt Backlog Sprint Backlog Sprint Überarbeitete und lauffähige

Version der Software

30 Tage

24 Std.

Abbildung 2.10: Der Scrum-Prozess.

Scrum erf

ullt die Bedingungen der agilen Software-Entwicklung, die

2001 im Agilen Manifest u. a. von Ken Schwaber und Jeff Sutherland

mit formuliert wurden [BBvB+01]:

•

Individuen und Interaktionen gelten mehr als Prozesse und

Tools.

•

Funktionierende Programme gelten mehr als ausf

uhrliche Do-

kumentation.

•

Die stetige Zusammenarbeit mit dem Kunden steht

uber Ver-

tr¨

agen.

•

Der Mut und die Offenheit f

Anderungen steht

uber dem

Befolgen eines festgelegten Plans.

Bei Scrum gibt es drei klar getrennte Rollen, die von Mitarbeitern

ausgef

ullt werden, die im selben Projekt zusammen arbeiten und

damit auch dasselbe Ziel haben. Damit jeder f

ur das, was er kann,

zust

andig und verantwortlich ist, werden die Zust

andigkeiten wie

folgt aufgeteilt:

GRUNDLAGEN

Product Owner:

Der Product Owner legt das gemeinsame Ziel fest,

welches das Team zusammen mit ihm erreichen muss. Zur De-

finition der Ziele dienen ihm User Stories. Er stellt das Budget

zur Umsetzung dieser User Stories zur Verf

ugung. Er setzt re-

gelm

aßig die Priorit

aten der einzelnen Product-Backlog-Elemente

(siehe unten). Dadurch legt er fest, welches die wichtigsten Fea-

tures sind, aus denen das Entwicklungsteam eine Auswahl f

den n¨

achsten Sprint trifft [Wik11].

Team:

Das Team sch

atzt die Aufw

ande der einzelnen Backlog-Elemente

ab und beginnt mit der Implementierung der f

ur den n

achsten

Sprint machbaren Elemente. Dazu wird vor dem Beginn des

Sprints ein weiteres Planungstreffen durchgef

uhrt, bei dem die

am h

ochsten priorisierten Elemente des Backlogs und konkrete

Aufgaben aufgeteilt werden. Das Team arbeitet selbstorganisiert

im Rahmen einer Time Box (dem Sprint) und hat das Recht

(und die Pflicht), selbst zu entscheiden, wie viele Elemente des

Backlogs nach dem n

achsten Sprint erreicht werden m

ussen, man

spricht dabei von commitments [Wik11].

Scrum Master:

Der Scrum Master hat die Aufgabe, die Prozesse der

Entwicklung und Planung durchzuf

uhren und die Aufteilung

der Rollen und Rechte zu

uberwachen. Er h

alt die Transparenz

ahrend der gesamten Entwicklung aufrecht und unterst

utzt da-

bei, Verbesserungspotentiale zu erkennen und zu nutzen. Er ist

keinesfalls f

ur die Kommunikation zwischen Team und Product

Owner verantwortlich, da diese direkt miteinander kommunizie-

ren. Er steht dem Team zur Seite, ist aber weder Product Owner

noch Teil des Team. Der Scrum Master sorgt mit allen Mitteln

daf

ur, dass das Team produktiv ist, also die Arbeitsbedingungen

stimmen und die Teammitglieder zufrieden sind. Er tritt somit

ur die ordnungsgem

aße Durchf

uhrung und Implementierung

von Scrum im Rahmen des Projektes ein [Wik11].

Bei der Rollenaufteilung wurde ber

ucksichtigt, dass das Team sich

selbst organisiert. Der Product Owner gibt nicht vor, welches Team-

mitglied wann was macht und wer mit wem zusammenarbeitet. Bei

Scrum wird von der Annahme ausgegangen, dass das Team sich intui-

tiv selbst organisiert, und zu jeder Aufgabe dynamisch eine optimale

innere Organisationsstruktur bildet, die sich relativ schnell an die sich

wandelnden komplexen Aufgaben anpasst. Der Scrum Master hat die

Pflicht, darauf zu achten, dass der Product Owner nicht in diesen ad-

aptiven Selbstorganisationsprozess eingreift und das Team st

ort oder

Verantwortlichkeiten an sich nimmt, die ihm nicht zustehen [Wik11].

2.1 VORGEHENSMODELLE

Artefakte

Wie in Abbildung

2.1035

dargestellt besteht der Lebenszyklus von

Scrum aus Backlogs und Sprints. In dem Prozess existieren insgesamt

folgende Backlogs [Wik11]:

Product Backlog:

Das Product Backlog enth

alt die Features des zu

entwickelnden Produkts. Es umfasst alle Funktionen, die der

Kunde w

unscht, zuz

uglich technischer Abh

angigkeiten. Vor

jedem Sprint werden die Elemente des Product Backlogs neu

bewertet und priorisiert. Dabei k

onnen bestehende Elemente

entfernt sowie neue hinzugef

ugt werden. Hoch priorisierte Fea-

tures werden von den Entwicklern im Aufwand gesch

atzt und

in den Sprint Backlog

ubernommen. Ein wesentliches Merkmal

des Backlogs ist die Tiefe der Beschreibung von einzelnen Featu-

res. Hoch priorisierte Features werden im Gegensatz zu niedrig

priorisierten sehr detailliert beschrieben. Somit wird viel Zeit

ur die wesentlichen Elemente und wenig f

ur unwesentliche

verwendet [Wik11].

Sprint Backlog:

Das Sprint Backlog enth

alt alle Aufgaben, die notwen-

dig sind, um das Ziel des Sprints zu erf

ullen. Eine Aufgabe sollte

dabei nicht l

anger als 16 Stunden dauern. L

angere Aufgaben

sollten in kurze Teilaufgaben zerlegt werden. Bei der Planung

des Sprint werden nur so viele Aufgaben eingeplant, wie das

Team an Kapazit¨

at aufweisen kann [Wik11].

Burndown Chart:

Das Burndown Chart ist eine graphische, pro Tag

zu erfassende Darstellung des noch zu erbringenden Restauf-

wands pro Sprint. Im Idealfall f

allt die Kurve kontinuierlich

(daher Burndown) und der Restaufwand ist somit am Ende des

Sprints gleich Null. Am Chart ist anhand der Verl

angerung der

negativen Steigung bereits w

ahrend des Sprints erkennbar, ob

der zu Beginn gesch¨

atzte Aufwand realisierbar ist [Wik11].

Impediment Backlog:

In das Impediment Backlog werden alle Hin-

dernisse des Projekts eingetragen. Der Scrum Master ist daf

zust

andig, diese Hindernisse gemeinsam mit dem Team aus-

zur¨

aumen [Wik11].

Zyklusmodell

Sprint:

Zentrales Element des Entwicklungszyklus von Scrum ist

der Sprint. Ein Sprint bezeichnet die Umsetzung einer Iterati-

on, Scrum schl

agt ca. 30 Tage als Dauer einer Iteration vor. Vor

GRUNDLAGEN

dem Sprint werden die Produkt-Anforderungen des Kunden in

einem Product Backlog gesammelt. Auch technische und admi-

nistrative Aufgaben werden dort aufgenommen. Das Product

Backlog muss nicht vollst

andig sein; es wird laufend fortgef

uhrt.

Die Anforderungen f

ur den ersten Sprint sind meistens rasch

aufgestellt. Die Anforderungen werden informell skizziert. F

einen Sprint wird ein Sprint Backlog erstellt. In diesen werden

Anforderungen

ubernommen, die w

ahrend des Sprints umge-

setzt werden sollen. Die Entscheidung, welche Anforderungen

umgesetzt werden, wird vom Kunden nach von ihm festgelegten

Priorit

aten getroffen. Zum Sprint organisiert sich das Entwick-

lungsteam selbst, braucht also keine detaillierten methodischen

Vorschriften [Wik11].

Daily Scrum:

An jedem Tag findet ein kurzes (maximal 15-min

utiges)

Daily Scrum, heißt eine Sitzung (engl. Meeting), statt. Das Team

stellt sich gegenseitig die folgenden Fragen:

•”

Bist du gestern mit dem fertig geworden, was du dir vor-

genommen hast?“

•”

Welche Aufgaben wirst du bis zum n

achsten Meeting

bearbeiten?“

•”Gibt es ein Problem, das dich blockiert?“

Die Sitzung dient dem Informationsaustausch des Teams unter-

einander. Hier geht es darum, dass m

oglichst alle alles wissen.

Falls neue Hindernisse erkannt wurden, m

ussen diese vom

Scrum Master bearbeitet werden. Dazu werden sie in das Im-

pediment Backlog eingetragen. Gr

oßere Projekte werden durch

das Einf

uhren von Scrum-of-Scrum Meetings,Product Owner Daily

Scrums und ScrumMaster Weekly gesteuert [Wik11].

Review:

Nach einem Sprint wird das Sprint-Ergebnis einem infor-

mellen Review durch Team und Kunden unterzogen. Hierzu

wird das Ergebnis des Sprints (also die laufende Software) vor-

gef

uhrt, eventuell werden technische Eigenschaften pr

asentiert.

Der Kunde pr

uft, ob das Sprint-Ergebnis seinen Anforderungen

entspricht, eventuelle

Anderungen werden im Product Backlog

dokumentiert [Wik11].

Retrospektive:

In der Retrospektive wird die zur

uckliegende Sprint-

Phase betrachtet. Es handelt sich dabei nicht um Lessons Lear-

ned

, sondern um einen zun

achst wertfreien R

uckblick auf die

Lessons Learned ist ein Fachbegriff des Projektmanagements und bezeichnet allgemein die Auswer-

tung von Erfahrungen in Projekten, die zuvor durchgef¨

uhrt wurden.

2.1 VORGEHENSMODELLE

Ereignisse des Sprints. Alle Teilnehmer notieren dazu die f

sie wichtigen Ereignisse auf Zetteln und ordnen sie dem Zeit-

strahl des Sprints zu. Anschließend schreiben die Teilnehmer

alle Punkte auf, welche ihnen zu den Themen Best Practice, bzw.

Verbesserungspotential einfallen. Jedes Verbesserungspotential

wird priorisiert und einem Verantwortungsbereich (Team oder

Organisation) zugeordnet. Alle der Organisation zugeordneten

Themen werden vom Scrum Master aufgenommen und in das

Impediment Backlog eingetragen. Die gesamten teambezogenen

Details werden in das Product Backlog aufgenommen. Sollte f

die Retrospektiven und deren Vorbereitung nicht genug Zeit

einger

aumt werden, bleiben die Erkenntnisse und Ergebnisse

oberfl

achlich und die Resultate nach jedem Sprint

ahneln sich.

Dann l

auft man Gefahr, dass die Retrospektiven an Stellenwert

verlieren oder ganz gestrichen werden, weil die Ergebnisse der

Retrospektiven vorhersehbar sind [Wik11].

2.1.12 Prototyping

Prototyping, oder auch Prototypenbau, ist eine Methode der Softwa-

reentwicklung, die schnell zu ersten Ergebnissen (den sogenannten

Prototypen) f

uhrt und fr

uhzeitiges Feedback bez

uglich der Eignung

eines L¨

osungsansatzes erm¨

oglicht [Wik11].

Der Begriff des Prototyping im Bereich der Softwareentwicklung trat

erstmals Anfang der achtziger Jahre in ersten Publikationen in Er-

scheinung. Zu dieser Zeit vollzogen sich teils drastische Wandel im

Bereich der Softwareentwicklung. Man war auf der Suche nach neuen

Designkonzepten und Entwicklungsstrategien um Schw

achen bzw.

Unzul

anglichkeiten vorhandener Entwicklungsmodelle f

ur Software

zu umgehen, da insbesondere in umfangreichen Projekten zuneh-

mend Probleme im Bereich der Anforderung bzgl. des Endprodukts

auftraten [CS89] [KOSS11].

Im Jahre 1979 sollte eine weitl

aufig angelegte amerikanische Studie

aren, worin die Gr

unde f

ur ein oftmaliges Scheitern von Software-

projekten unter Verwendung herk

ommlicher Entwicklungsmodelle

aren. Es zeigte sich, dass viele Softwareprojekte nicht etwa an un-

zureichenden Entwicklungsumgebungen oder Entwicklungswerkzeu-

gen, sondern zunehmend am Problem mangelnder Kommunikation

zwischen Auftraggebern, Benutzern und Entwicklern scheiterten. Die

zur damaligen Zeit g

angigen Entwicklungsmodelle setzten auf so

genannte Life Cycle Plans auf. Das wohl bekannteste und gebr

auch-

lichste derartige Modell war das Wasserfallmodell (Kapitel

2.1.214

Das Problem bei diesen Modellen war, dass die Benutzer nur zu

GRUNDLAGEN

Anforderungs-

analyse

Anforderungs-

definition

Benutzerschnitt-

stellen Prototyp

Architektur- und

Komponenten-

design

Architektur- und

Komponenten-

Prototyp

Implementierung

Systemtest

Einsatz und

Wartung

Informale Beschreibung

der Benutzer benötigt

Benutzerschnittstellen Prototyp

und komplette Spezifikation

Systemarchitektur, Strukturierung

der Komponenten,

Komponentenarchitektur und

Komponenten Prototyp

Programm und Dokumentation

Endprodukt

Zeit

Abbildung 2.11: Entwicklungsprozess nach Pomberger [PW94].

Beginn eines Projektes im Rahmen der Aufgabenbeschreibung bzw.

-spezifikation mit einbezogen wurden, jedoch vom weiteren Entwick-

lungsprozess konsequent ausgeschlossen waren. Dies machte zwar

den Entwicklungsprozess

uberschaubar und kalkulierbar, resultierte

allerdings in Software, die oftmals nicht den Erwartungen der Auftrag-

geber und Nutzer aufgrund unzureichender Aufgabenbeschreibung

entsprach. Unklarheiten und Fehler, die bereits im Rahmen der Anfor-

derungsanalyse auftraten, zogen sich somit bis ins Endprodukt durch,

wobei im schlimmsten Fall die Software nahezu unbrauchbar geraten

konnte [BKK92] [KOSS11].

Das Prototyping als Softwareentwicklungsmodell unterscheidet sich

grunds

atzlich nicht von traditionellen, auf dem Life Cycle-Prinzip ba-

sierenden Entwicklungsmodellen. Vielmehr stellt es eine Erg

anzung

zu herk

ommlichen Modellen dar. Prototyping bildet ein Kernanliegen

dieses Paradigmas ab, den Benutzer w

ahrend des gesamten Entwick-

lungsfortschritts einbinden, um m

oglichst gute Kommunikation zwi-

schen Entwicklern und Benutzern zu gew

ahrleisten und eventuelle

Ungenauigkeiten in der Softwarespezifikation jederzeit ausbessern zu

onnen. Dadurch k

onnen etwaige Unklarheiten und Unzul

anglichkei-

ten fr

uhzeitig erkannt und auch im Laufe des Entwicklungsprozesses

gekl

art werden, eines der gr

oßten M

angel vorausgehender Model-

2.1 VORGEHENSMODELLE

le [CS89] [KOSS11].

Das Konzept des Prototyping versucht relativ fr

uh im Entwicklungs-

prozess funktionsf

ahige Prototypen von Teilfunktionen der Software

zu entwickeln, welche Teilaspekte des Gesamtprojektes in ihrer Funk-

tionsweise demonstrieren und vom sp

ateren Nutzer getestet bzw. in

Zusammenarbeit mit dem Entwickler verbessert werden k

onnen. Da

Prototypen nur Basiseigenschaften von Teilaspekten des Programms

beschreiben, k

onnen sie schnell und kosteng

unstig erstellt werden, wo-

bei auch experimentelles Vorgehen erm

oglicht wird. Die Prototypen

an sich definieren zwar Teilaspekte der zu erstellenden Software, sind

aber selbst als solche nicht Teil des endg

ultigen Produktes. Derartige

Prototypen k

onnen dann sukzessive entsprechend den Nutzerbed

urf-

nissen erweitert oder aber auch g¨

anzlich verworfen und durch einen

anderen Prototypen ersetzt werden. Durch diesen evolution

aren An-

satz bei der Softwareentwicklung entsteht die Software stufenweise

in Zusammenarbeit mit den Nutzern [PW94] [KOSS11].

Ansatzmethoden beim Prototyping

Es existieren drei verschiedene Ans

atze, wie die Prototypen zu erstel-

len sind [KOSS11].

Throw-Away Ansatz:

Bei der Verwendung eines Throw-Away Ansat-

zes wird ein nicht vollst

andiges, aber im Sinne der Anforderun-

gen lauff

ahiges Programm beschrieben. Dies wird dann dem

Benutzer zur experimentellen Auswertung

ubergeben. Der Proto-

typ wird nach der Auswertung nicht weiterverwendet, sondern

verworfen. Die gewonnenen Ergebnisse werden bei der Neukon-

struktion eines neuen Prototypen verwendet [KOSS11].

Inkrementeller Ansatz:

Beim inkrementellen Ansatz wird zu Beginn

ein stabiler Programmkern aufgebaut, dem danach schrittwei-

se neue Funktionen oder auch neue Systemteile hinzugef

ugt

werden. Programmteile, die dem Prototypen noch fehlen, wer-

den durch Simulationen vervollst

andigt. Dieser Prototyp besteht

gewissermaßen aus zwei verschiedenen Teilen, einem fest im-

plementieren Softwareteil und einem Simulationsteil. Nachteil

dieses Konzeptes ist, dass ein neu hinzugef

ugter Programm-

teil das Gesamtsystem in der Regel in einem so hohem Maße

beeinflusst, so dass fr

uhere Entwurfsentscheidungen korrigiert

werden m¨

ussen [KOSS11].

Evolution¨

arer Ansatz:

Diese Ansatzmethode legt die jeweiligen Ar-

chitekturkonzepte zu keinem Zeitpunkt fest. Das erm

oglicht zu

GRUNDLAGEN

jeder Zeit das Aufnehmen neue Anforderungen. Die Architektur

passt sich den Umgebungsanforderungen an. So ist der Proto-

typ beim Beenden der evolution

aren Ansatzmethode das fertige

Endprodukt. Die Idee des evolution

aren Ansatzes geht bis in

die 60er Jahre zur

uck, aber sie ist bis heute noch sehr schwer

umzusetzten [KOSS11].

Arten von Prototypen

Je nach den vorliegenden Anforderungen werden unterschiedliche

Prototypen ben

otigt. Es k

onnen vier verschiedene Arten unterschieden

werden [KOSS11]:

Vollständiges System

Verschiedene Features

Funktionalität

Horizontaler Prototyp

Vertikaler Prototyp

Scenario

Abbildung 2.12: Horizontaler und vertikaler Prototyp.

Demonstrationsprototyp:

Dieser Prototyp soll vor allem die Benut-

zerschnittstelle, allerdings auch die Handhabung und die prin-

zipiellen Einsatzm

oglichkeiten des zuk

unftigen Endproduktes

zeigen. F

ur Demonstrationsprototypen wird in vielen F

allen der

Throw-Away Ansatz gew¨

ahlt [KOSS11].

Funktionaler Prototyp:

Bei dieser Art Prototyp werden eine oder

mehrere Aspekte der Funktionalit

at implementiert. Dabei gibt es

zwei unterschiedliche Vorgehensweisen, zum einen den horizon-

talen Prototyp und zum anderen den vertikalen Prototyp (siehe

auch Abbildung

2.12

). Der horizontale Prototyp deckt eine Viel-

zahl an Funktionalit

at, die aber nicht komplett implementiert ist.

2.2 ARCHITEKTURMUSTER

Beispiel w

are eine Benutzerschnittstelle, die schon komplett ent-

wickelt ist, bei der aber die Verarbeitung der Eingaben fehlt. Der

vertikale Prototyp spezialisiert sich meist auf nur eine spezielle

Aufgabe, daf

ur ist diese aber auch voll implementiert. Als Bei-

spiel, bei einer Benutzerschnittstelle w

are diese bis auf wenige

Bedienelemente leer, daf

ur w

urde allerdings die Funktionalit

hinter den vorhandenen Bedienelementen schon komplett imple-

mentiert sein. Auch f

ur den funktionalen Prototyp wird h

aufig

der Throw-Away Ansatz gew¨

ahlt [KOSS11].

Labormuster (Labormodell):

Dieser Prototyp dient den Entwicklern

intern als Bewertungsgegenstand, der Fragen der technischen

Umsetzung und der Realisierbarkeit kl¨

aren soll [KOSS11].

Pilotsystem:

Pilotsysteme sind Weiterentwicklungen der Labormus-

ter, die so ausgereift sind, dass sie nicht nur im Labor sondern

auch schon im Anwendungsbereich selbst eingesetzt werden

k¨

onnen. [KOSS11]

2.1.13 Vorgehensmodelle Zusammenfassung

Die in diesem Kapitel vorgestellten Vorgehensmodelle sind die klassi-

schen Methoden zur Entwicklung von Software. Sie sind allgemein-

ultige Modelle, die f

ur die Entwicklung fast jedes Softwareprojektes

verwendet werden k

onnen. Sie bieten keine speziellen L

osungen f

bestimmte Projekte und sind oft nicht durch Softwarewerkzeuge un-

terst

utzt. Allerdings basiert auch mein vorgestelltes Entwurfsvorgehen

auf Prinzipien der hier vorgestellten Vorgehensmodelle. Begriffe wie

Iteration, Prototyp und kurze Zyklen werden sich auch in meinem

Entwurfsvorgehen wiederfinden.

In Kapitel

3.260

gehe ich auf speziell f

ur Mixed Reality entwickelte

Vorgehensmodelle und Entwurfskonzepte ein, die den Stand der

aktuellen Forschung widerspiegeln.

2.2 Architekturmuster

Im Bereich der Softwareentwicklung sind Architekturmuster (auch:

Architekturstil, engl. architectural style) in den Arten von Mustern auf

oberster Ebene einzuordnen. Im Gegensatz zu Idiomen

oder Ent-

Idiome sind den Mustern (engl. pattern) zugeordnet. Buschmann definiert:

”

Ein Idiom ist ein

programmiersprachenspezifisches Muster und damit ein Muster auf einer niedrigen Abstraktionsebene.

Ein Idiom beschreibt, wie man bestimmte Aspekte von Komponenten oder Beziehungen zwischen ihnen

mit den Mitteln einer bestimmten Programmiersprache implementiert.“ [BMRS98]

GRUNDLAGEN

wurfsmustern

bestimmen sie nicht ein konkretes (meist kleines oder

lokales) Teilproblem, sondern den Grundaufbau, also das Fundament

der Anwendung. [BMRS98]

Architekturmuster lassen sich in vier verschiedene Kategorien eintei-

len [Wik11]:

Chaos zu Struktur (engl. Mud-to-structure):

Diese speziellen Mus-

ter sollen helfen, die Vielzahl an Komponenten und Objekten

eines Softwaresystems zu organisieren. Die Funktionalit

at des

Gesamtsystems wird hierbei in kooperierende Subsysteme auf-

geteilt. Diese Kategorie beinhaltet folgende Muster:

•Pipes und Filter

•Schichtenarchitektur (auch: mehrschichtige bzw.

N-Tier-Architektur)

•Schwarzes Brett (engl. Blackboard)

Verteilte Systeme:

Diese Kategorie unterst

utzt die Verwendung ver-

teilter Ressourcen und Dienste in Netzwerken (z. B. service-

orientierte Architekturen, Orchestrierung). Die beiden Modelle

Mikrokernel und Pipes und Filter) unterst

utzen eine Verteilung

auch, aber eher zweitrangig. Folgende Muster fallen unter diese

Kategorie:

•Broker bzw. Vermittler

•Client-Server

Interaktive Systeme:

Interaktive Systeme sollen die Mensch-Com-

puter-Interaktionen strukturieren und vereinfachen. In dieser

Kategorie stehen folgende Muster:

•Model-View-Controller (MVC)

•Presentation-Abstraction-Control (PAC)

Adaptive Systeme:

Bei diesem Muster wird die Erweiterungs- und

Anpassungsf

ahigkeit von Softwaresystemen besonderes unter-

st¨

utzt. Es fallen folgende Muster unter diese Kategorie:

•Mikrokernel

•Reflexion

•Dependency Injection

Entwurfsmuster (engl. design patterns) sind bew

ahrte L

osungs-Schablonen f

ur wiederkehrende

Entwurfsprobleme in Softwarearchitektur und Softwareentwicklung. [GHJV96]

2.2 ARCHITEKTURMUSTER

In meiner Arbeit habe ich das bekannte MVC-Modell verwendet und

dahingehend erweitert, dass es in mein Entwurfsvorgehen eingepasst

wurde. Deshalb werde ich hier nur die beiden Architekturmodelle

MVC und PAC aus der Kategorie der Interaktiven Systeme vorstellen.

2.2.1 Model-View-Controller

Das Model-View-Controller (MVC, zu deutsch

”

Modell, Pr

asentation,

Steuerung“) Architekturmuster dient bei der Entwicklung von Soft-

ware zur Strukturierung in drei Einheiten: Dem Datenmodell (engl.

Model), der Pr

asentation (engl. View) und Programmsteuerung (engl.

Controller). Das Ziel dieses Musters ist ein flexibler Programment-

wurf, der sp

atere

Anderungen oder Erweiterungen erleichtert und

eine Wiederverwendbarkeit der einzelnen Komponenten erm

oglicht.

MVC ist in der Entwicklung von Benutzerschnittstellen (engl. User

Interfaces, kurz UI) ein weit verbreitetes Muster. Es wurde im Jahre

1979 zun

achst exakt f

ur UIs in Smalltalk durch Trygve Reenskaug, der

damals an Smalltalk im Xerox PARC arbeitete, beschrieben (Seeheim-

Modell) [

Ree03

]. Mittlerweile gilt MVC aber als De-facto Standard f

den Grobentwurf aller komplexen Softwaresysteme, teils mit Diffe-

renzierungen und oftmals mehreren, jeweils nach dem MVC-Muster

aufgeteilten, Modulen [Wik11].

Model (M)

View (V) Controller (C)

Direkte Assoziation

Indirekte Assoziation

change notification

queryData()

changeDisplay()

user action

changeData()

Abbildung 2.13: Model-View-Controller Architekturmuster.

In Abbildung

2.13

sind die drei Komponenten Model,View und Con-

troller und deren Beziehung zueinander zu sehen. In der Abbildung

GRUNDLAGEN

repr

asentiert die durchgezogene Linie eine direkte Assoziation, die

gestrichelte eine indirekte Assoziation (z. B.

uber einen Observer

). Die

Annotation an den Pfeilen beschreibt die Aktionen bzw. Funktionen,

die jeweils aufgerufen werden k

onnen. So schickt z. B. das Model eine

Benachrichtigung an den View, dass sich die Daten des Model ge

andert

haben (change notification) woraufhin der View dann die neuen Daten

vom Model abfragt (queryData() ) und sie dann darstellt.

Je nach Realisierung h

angen die Komponenten unterschiedlich stark

voneinander ab und sind f¨

ur folgende Aufgaben gedacht:

Model:

Es beinhaltet die darzustellenden Daten und ist vom View

und vom Controller unabh

angig. Die Bekanntgabe von

Ande-

rungen an relevanten Daten im Model geschieht nach dem Ent-

wurfsmuster Beobachter (engl. Observer). Das Modell ist das zu

beobachtende Subjekt, auch Publisher, genannt [Wik11].

View:

Der View ist f

ur die Darstellung der Daten aus dem Model und

die Entgegennahme von Benutzerinteraktionen zust

andig. Dem

View sind sowohl sein Controller als auch das Model bekannt,

dessen Daten er darstellt. F

ur die Weiterverarbeitung der vom

Benutzer

ubergebenen Daten ist er aber nicht zust

andig. Im

Regelfall wird der View

uber

Anderungen von Daten im Mo-

dell mithilfe des Entwurfsmusters Beobachter unterrichtet und

kann sich daraufhin die aktualisierten Daten besorgen. Der View

verwendet das Entwurfsmuster Kompositum8[Wik11].

Controller:

Der Controller kann einen oder mehrere Views verwalten

und nimmt von ihnen Benutzeraktionen entgegen, die er dann

auswertet entsprechend agiert. Zu jedem View existiert ein Model.

Es ist nicht die Aufgabe der Steuerung, Daten zu manipulieren.

Der Controller entscheidet aufgrund der Benutzeraktion im View,

welche Daten im Model ge

andert werden m

ussen. Er enth

alt

weiterhin Mechanismen, um die Benutzerinteraktionen des View

einzuschr

anken. View und Controller verwenden zusammen das

Entwurfsmuster Strategie

, wobei der Controller der Strategie

entspricht. Der Controller kann in manchen Implementierungen

Der Observer geh

ort zur Kategorie der Verhaltensmuster (engl. Behavioural Patterns). Es dient zur

Weitergabe von ¨

Anderungen an einem Objekt an von diesem Objekt abh¨

angige Strukturen. [GHJV96]

Das Kompositum (engl. Composite) geh

ort zu der Kategorie der Strukturmuster (Structural Patterns).

Es wird angewendet, um Teil-Ganzes-Hierarchien zu repr

asentieren, indem Objekte zu Baumstrukturen

zusammengef

ugt werden. Die Grundidee des Kompositionsmusters (Composite-Pattern) ist, in einer

abstrakten Klasse sowohl primitive Objekte als auch ihre Beh

alter zu repr

asentieren. Somit k

onnen

sowohl einzelne Objekte, als auch ihre Kompositionen einheitlich behandelt werden. [GHJV96]

Die Strategie (engl. Strategy)geh

ort zu der Kategorie der Verhaltensmuster (Behavioural Patterns).

Das Muster definiert eine Familie austauschbarer Algorithmen.. [GHJV96]

2.2 ARCHITEKTURMUSTER

ebenfalls zu einem Beobachter des Model werden, um bei

Ande-

rungen der Daten den View direkt zu manipulieren [Wik11].

Der Vorteil der Dekomposition nach dem Model-View-Controller Ar-

chitekturmuster, die hier am Beispiel von Benutzerschnittstellen be-

schrieben wurde, ist, dass die Aspekte der Visualisierung und der

Interaktion von der unterliegenden Applikation getrennt behandelt

werden k

onnen. Mit dem Model-View-Controller Architekturmuster

wird ein modulares Design erm

oglicht, bei dem

Anderungen einer

Komponente keine Auswirkungen auf die Implementation der

ubri-

gen Komponenten haben. Ein weiterer Vorteil ist die M

oglichkeit der

Verwendung mehrere Views und Controller f¨

ur ein Model.

2.2.2 Presentation-Abstraction-Control

Das Architekturmuster Presentation-Abstraction-Control (PAC, was ins

Deutsche

ubersetzt bedeutet

”

Darstellung-Abstraktion-Steuerung“)

wird zur Strukturierung von interaktiven Softwaresystemen vewren-

det. Es ist eine Weiterentwicklung des in Kapitel

2.2.145

vorgestellten

MVC Models und wurde von Prof. Jo

elle Coutaz im Jahre 1987 vor-

gestellt [

Cou87

]. Mit dem PAC Muster k

onnen interaktive Systeme

so entwickeln werden, dass diese aus einzelnen Teilen bestehen, die

jeweils einen Teil der Aufgaben des gesamten Systems abbilden und

damit eine hohe Flexibilit

at des Systems gew

ahren. PAC stellt sicher,

dass die Teile zu einem funktionierenden Ganzen zusammengesetzt

werden k¨

onnen [Wik11].

Top-Level-Agent

Abstraction (A)Presentation (P)

Control (C)

Intermediate-Level-Agent

Abstraction (A)Presentation (P)

Control (C)

Intermediate-Level-Agent

Abstraction (A)Presentation (P)

Control (C)

Bottom-Level-Agent

Abstraction (A)Presentation (P)

Control (C)

Bottom-Level-Agent

Abstraction (A)Presentation (P)

Control (C)

Abbildung 2.14: Aufbau von Presentation-Abstraction-Control(PAC).

PAC teilt ein System in zwei Richtungen auf: Zum einen in die drei

Einheiten grafische Benutzungsschnittstelle (engl. Presentation), Ver-

GRUNDLAGEN

mittlung und Kommunikation (engl. Control) und das Datenmodell

(engl. Abstraction) – dies ist

ahnlich dem MVC Muster – und zum

anderen hierarchisch in verschiedene Elemente, die jeweils einen Teil

der Aufgaben des Systems abbilden. Diese Teile werden im PAC

Muster als Agenten bezeichnet und sie stellen die erste Stufe der

Strukturierung w¨

ahrend des Architekturentwurfes dar [Wik11].

Die Hierarchie von PAC ist in insgesamt drei Ebenen unterteilt, wie

in Abbildung

2.1447

zu erkennen ist. Die oberste Ebene besteht aus

einem einzigen so genannten Top-Level-Agent, der f

ur das System alle

globalen Aufgaben

ubernimmt, z. B. Datenbankzugriffe. Auf der zwei-

ten Ebene liegen die Intermediate-Level-Agents, die eine Schnittstelle

zwischen der untersten (Bottom-Level) und der obersten (Top-Level)

Ebene bilden und mehrere Bottom-Level-Agents zu einer Einheit zu-

sammenfassen. Dabei besteht die M

oglichkeit, dass in dieser Ebene

die Teilsysteme weiter hierarchisch aufgeteilt werden k

onnen, so dass

ein Teilsystem auch aus einem oder mehreren anderen bestehen kann,

was bedeutet, dass ein Intermediate-Level-Agent auch mehrere ande-

re Intermediate-Level-Agents zusammenfassen kann. Die dritte Ebene

besteht aus den Bottom-Level-Agents, welche die eigentlichen Funk-

tionen des interaktiven Systems abbilden, wobei jeder seine eigene,

oglichst abgeschlossene, Funktion beinhaltet und m

oglichst

uber

keine Abh

angigkeiten zu anderen Bottom-Level-Agents verf

ugen soll-

te [Wik11].

Der Architekturentwurf beginnt mit der Aufteilung der geforderten

Funktionalit

at auf mehrere Bottom-Level-Agents. Anschließend wird bei

dem Top-Level-Agent festgelegt, welche Funktionalit

at dieser erbringen

soll. Die Hierarchie wird daraufhin mit der Festlegung der Intermediate-

Level-Agents vervollst

andigt, die eine Kombination aus Bottom-Level-

Agents darstellen und diesen den Zugriff auf den Top-Level-Agent

vermitteln [Wik11].

Wie schon oben beschrieben wird jeder Agent in drei Komponenten

aufgeteilt. Die erste Komponente entspricht der grafischen Benutzero-

berfl¨

ache (Presentation), die die komplette Ein- und Ausgabe umfasst

(anders bei dem MVC Muster, bei dem diese noch aufgeteilt wird in

View und Controller). Die zweite Komponente repr

asentiert die Ab-

straktion (Abstraction), die das Datenmodell des jeweiligen Agenten

realisiert. Die dritte Komponente, die Vermittlung und Kommunika-

tion (Control), stellt die Verbindung zwischen den beiden anderen

Komponenten her und erm

oglicht die Kommunikation mit ande-

ren Agenten. Damit ist diese Komponente die zentrale Schnittstelle

ur die Zusammenarbeit der einzelnen Teile eines Systems im PAC-

Muster [Wik11].

2.3 MODELLBILDUNG UND SIMULATION KONTINUIERLICHER SYSTEME

Es ist nicht zwingend notwendig, dass jeder Agent alle drei Kompo-

nenten beinhaltet, sondern jeder Agent bringt die Benutzerschnittstelle

und das Datenmodell f

ur seine Aufgabe mit. Es ist somit vorstellbar,

dass z. B. ein Intermediate-Level-Agent nur in einem Fenster ihm unter-

geordnete Agenten zusammenfasst und anzeigt, selber aber daf

ur kein

Datenmodell ben

otigt. Jeder Agent muss allerdings die Steuerungs-

komponente beinhalten, da ansonsten eine Kommunikation zwischen

Komponenten und mit anderen Agenten nicht m

oglich w

are [

Wik11

2.2.3 Zusammenfassung

MVC und PAC eignen sich hervorragend, um Komponenten entspre-

chend ihrer Funktionalit

at aufzuteilen und so getrennt zu entwickeln.

ur meinen Entwurfsprozess habe ich das MVE Architekturmuster

als Grundlage gew

ahlt und erweitert, da ich die Hierarchie von PAC

nicht ben

otigte. Die Aufteilung in kleinere Teile kann in meinem

Entwurfsprozess optional innerhalb der einzelnen Komponenten des

erweiterten MVE Architekturmusters vorgenommen werden.

2.3 Modellbildung und Simulation kontinuierlicher

Systeme

In vielen Bereichen der Entwicklung von kontinuierlichen Systemen

wird heutzutage die Simulation als Werkzeug genutzt. Durch die

Simulation erlangt man ein besseres Verst

andnis

uber komplexe, dy-

namische Systeme und sie erleichtert die Entwicklung dieser Systeme.

In diesem Abschnitt beziehe ich mich nur auf die Simulation kontinu-

ierlicher Systeme. Bei der Simulation beispielsweise diskreter Systeme

(z. B. Digitalschaltungen) muss das resultierende Modell nicht not-

wendigerweise mit Differenzialgleichungen beschreiben werden.

Grundlage der Simulation ist ein mathematisches bzw. physikalisches

Modell des kontinuierlichen Systems, welches anhand von Beobach-

tungen bzw. theoretischer Grundlagen entwickelt wird. Dieses Modell

sollte das zu analysierende System hinreichend gut beschreiben. Die

aus dem Modell resultierenden Differenzialgleichungen k

onnen durch

einen Computer berechnet und gel

ost werden. Modelle k

onnen, je

nach Anforderung, beliebig komplex werden, meist reichen jedoch

Approximationen des Systems aus, um verwertbare Daten zu erhalten.

Um den Aufwand der Berechnung gering zu halten, sollte das Modell

nur genau das beschreiben, was f

ur die sp

atere Auswertung n

otig

ist [

Sch04

]. Die Daten der Simulation k

onnen, je nach Zielsetzung,

GRUNDLAGEN

vielf

altig genutzt werden, z. B. um das reale System oder das Modell

zu verbessern.

Die Durchf

uhrung von Simulationen kann verschiedene Gr

unde ha-

ben, z. B.

Entwicklung: ¨

Uberpr

ufung und Optimierung des Systems und seiner

Parameter vor der eigentlichen Prototypenentwicklung.

Wiederholbarkeit:

Simulationen k

onnen immer mit denselben Vor-

raussetzungen wiederholt werden, was zu gleichen Ergebnissen

uhrt. Daher gestaltet sich eine Fehleranalyse leicht, da Fehler

reproduzierbar werden.

Beobachtbarkeit:

Viele technische Systeme sind nur schwer zu beob-

achten. Durch die Simulation ist es m

oglich, die Vorg

ange, die

sonst nicht sichtbar w

aren, zu visualisieren. Dabei ist sowohl

der zeitliche (z. B. Zeitlupe) als auch der optische Aspekt (z. B.

Visualisierung von nicht sichtbaren Vorg¨

angen) zu nennen.

Gefahrenvermeidung:

Das Entwickeln an realen Systemen kann zu

einer Gef

ahrdung von Mensch und Maschine f

uhren, die durch

die Simulation verhindert wird.

Training: ¨

Uber die Simulation kann der Benutzer lernen, das System

zu bedienen, ohne sich und andere in Gefahr zu bringen oder

das reale System zu besch¨

adigen.

Kosten:

Die Entwicklung von Simulatoren ist g

unstiger als die Her-

stellung realer Prototypen, gerade in den ersten Phasen der

Entwicklung.

ur die Simulation gibt es zwei grunds

atzlich verschiedene Arten

der Durchf

uhrung, Offline oder in Echtzeit. Die Offline-Simulation

generiert Daten, die nach Abschluss der Simulation analysiert werden

onnen. Auf diesen Daten k

onnen verschiedene Visualisierungen

ausgef

uhrt werden und es ist m

oglich, die Simulation zu stoppen,

zu verlangsamen oder r

uckw

arts laufen zu lassen. Eine Echtzeit-

Visualisierung, d. h. die Daten werden zeitlich korrekt wiedergegeben,

ist m

oglich, aber eine Interaktion mit dem System kann in einer Offline-

Simulation nicht erreicht werden. Sollte etwas am System ver

andert

werden, muss die Offline-Simulation komplett neu ausgef

uhrt werden.

Das andere Verfahren zur Durchf

uhrung einer Simulation ist die

Echtzeit-Simulation. Sie erlaubt die Interaktion des Benutzers mit dem

System w

ahrend der Laufzeit und kann auf

Anderung der Parameter

2.3 MODELLBILDUNG UND SIMULATION KONTINUIERLICHER SYSTEME

reagieren. In der Echtzeitsimulation, gerade auch wenn die Simulation

mit realen Sensoren bzw. Aktuatoren gekoppelt ist, ist es nicht mehr

oglich die zeitliche Abfolge zu ver

andern oder zu verlangsamen.

Damit wird die Beobachtbarkeit der Ereignisse etwas eingeschr¨

ankt.

2.3.1 In-the-Loop Simulation

In der Elektrotechnik und im Maschinenbau beziehungsweise der

Mechatronik haben sich Methoden f

ur einen strukturierten Entwurfs-

prozess etabliert, die eine Simulation eines Systems und seiner Ein-

zelkomponenten auch im Kontext der Zusammenarbeit mit realen

Systemkomponenten erm

oglichen. Hierbei handelt es sich h

aufig um

Regelkreise oder Prozesssteuerungen [CMPH08].

Regler

Führungsgröße

e(t)

Reglerabweichung

Regelstrecke

u(t)

Stellgröße

d(t) Störgröße

Regelgröße

y(t)

w(t)

Rückführung

Abbildung 2.15: Aufbau eines allgemeinen Regelkreises.

Neben den hier vorgestellten mechatronischen Regelkreisen existie-

ren auch Regelkreise f

ur rein elektrische Systeme. Allgemein k

onnen

Regelkreise f

ur jedes komplexe System existieren, so dass die Tr

ager-

struktur nicht notwendigerweise aus dem Bereich des Maschinenbaus

stammen muss, wie in Abbildung

2.15

zu erkennen ist. Die Abbildung

zeigt einen einfachen Regelkreis der aus einer Regelstrecke, einem

Regler und einer R

uckkopplung der Regelgr

oße

(dem Istwert) be-

steht. Dabei wird die Regelgr

oße

mit der F

uhrungsgr

oße w (dem

Sollwert) verglichen und die Regelabweichung

e=w−y

berechnet.

Die Regelabweichung wird dem Regler

ubergeben, der daraus die

Stellgr

oße

gem

aß der gew

unschten Dynamik berechnet. Die Stell-

oße

und die St

orgr

oße

werden der Regelstrecke

ubergeben,

die daraus die Regelgr

oße

bildet. Im Gegensatz zum allgemeinen

Regelkreis k

onnen Mechatronischen Regelkreise wie in Abbildung

2.1652 dargestellt werden.

Wie in Abbildung

2.1652

zu sehen gibt es beim mechatronischen Regel-

kreis ein Grundsystem, dass sich in einer Umgebung befindet. Dieses

bildet die Tragestruktur des gesamten Systems und ist normalerweise

dem Bereich Maschinenbau zuzuordnen. Im Grundsystem befinden

sich Sensoren, die Informationen der Umgebung aufnehmen oder den

Zustand des Grundsystems feststellen. Die Informationen der Senso-

ren werden durch Hard- und Softwarekomponenten verarbeitet. Die

GRUNDLAGEN

Grundsystem

Informations-

verarbeitung

Aktuatoren Sensoren

mechatronischer

Regelkreis

Signalfluss Energiefluss

Energie Umgebung

Umgebung Umgebung

Abbildung 2.16: Aufbau eines mechatronischen Regelkreises.

Informationsverarbeitung steuert

uber Aktuatoren das mechanische

Grundsystem.

Ein solches System kann in verschiedenen Stufen simuliert werden,

bevor am Ende der Entwicklung ein fertiges System entsteht.

Model-in-the-Loop (MiL)

Die erste Phase der Simulation ist die Model-in-the-Loop Simulation

(MiL), in der das zu simulierende Komponente mit speziellen Werk-

zeugen (z. B. MATLAB/Simulink oder Labview) modelliert und in das

Simulationsmodell der Umgebung eingebettet wird. In dieser Phase

wird die Funktionalit

at gepr

uft und ggf. das Modell angepasst. Das

Modell existiert nur in den Werkzeugen und die Funktionalit

at wird

dort simuliert.

Software-in-the-Loop (SiL)

Bei der Software-in-the-Loop Simulation (SiL) wird das zuvor in oberen

Abschnitt beschriebene Modell nun in einen Code f

ur eine bestimm-

te Plattform

ubersetzt. Dieser Code wird dann simuliert, d. h. er

wird nicht auf der speziellen Hardwareplattform ausgef

uhrt, sondern

in einem Hardwaresimulator. Dabei sollten die simulierten Daten

oglichst den Daten der MiL Simulation gleichen. Werkzeuge wie

beispielsweise MATLAB/Simulink bieten eine Codegenerierung in

Plattformabh

angigen Quelltext an, so dass der Schritt vom Modell

zum Code keine Schwierigkeiten beinhaltet.

2.3 MODELLBILDUNG UND SIMULATION KONTINUIERLICHER SYSTEME

Grundsystem

Steuergerät

Aktuatoren Sensoren

MiL Simulator

Signalfluss Energiefluss

Energie Umgebung

Umgebung Umgebung

Funktionalität

Hardware Software

Modell

generiert

Abbildung 2.17: Model-in-the-Loop Simulation.

Hardware-in-the-Loop (HiL)

Die letzte Phase ist die Hardware-in-the-Loop Simulation (HiL), bei

der nun der Code, der in der SiL Simulation generiert wurde, auf

der entsprechenden Hardware (Embedded System) ausgef

uhrt wird.

Die Hardware wird mit der Simulationsumgebung gekoppelt, die die

Eingaben und Ausgaben der Hardware ¨

ubernimmt und auswertet.

Marin Schlager beschreibt in seinem Buch

”

Hardware-in-the-Loop

Simulation: A Scalable, Component-based, Time-triggered Hardware-

in-the-loop Simulation Framework“ [

Sch08

] die grundlegenden Prin-

zipen der Entwicklung von HiL-Simulatoren. Gerade im Bereich der

sicherheitskritischen Realzeitsysteme ist es wichtig, das eine korrekte

Ausf

uhrung in jeder Situation gew

ahrleistet ist, auch bei sehr un-

wahrscheinlichen Situationen. Dabei sind Hardware-in-the-Loop (HiL)

Simulationen ein gebr

auchlicher Weg um die Realzeitsysteme zu vali-

dieren.

2.3.2 Zusammenfassung

ur mein Problem ergab sich, dass alle drei In-the-Loop-Techniken f

den Design-Prozess geeignet sind und sich in das Architekturmuster

perfekt eingliedern. So war es m

oglich, die verschiedenen Arten der

Simulationen in einem Beispiel, das in Kapitel

5159

beschrieben wird,

einzubinden. Es wurde in diesem Beispiel iterativ von der ersten bis

zur dritten In-the-Loop-Technik zuerst das Modell, gefolgt von der

Software bis hin zur Hardware eine H

ohensteuerung entwickelt und

GRUNDLAGEN

Grundsystem

Steuergerät

Aktuatoren Sensoren

SiL Simulator

Signalfluss Energiefluss

Energie Umgebung

Umgebung Umgebung

Funktionalität

Hardware Software

Modell

generiert

Abbildung 2.18: Software-in-the-Loop Simulation.

validiert. Dabei wurden unterschiedliche Werkzeuge verwendet, die

die unterschiedlichen Stufen unterst¨

utzten.

2.4 Reality-Virtuality Kontinuum (RV)

Das Reality-Virtuality Kontinuum (RV)

wurde 1994 von Paul Mil-

gram et. al. in der Ver

offentlichung

”

Augmented reality: A class of

displays on the reality-virtuality continuum“ [

MTUK94

] definiert. Es

umschließt alle Mischformen von Virtualit

at (oder besser virtuelle

Realit

at) und Realit

at, die jeweils die Grenzen des Kontinuums bilden,

wie an Abbildung

2.2055

zu sehen ist Der Raum zwischen den beiden

Extremen wird

”

Mixed Reality“ (MR), also Vermischte Realit

at bzw.

Gemischte Realit

at, genannt. Die bekanntesten Zwischenformen sind

dabei die Augmented Virtuality (AV, zu deutsch erweiterte Virtualit

at)

und die Augmented Reality (AR, zu deutsch erweiterte Realit¨

at).

2.4.1 Realit¨at

Die Realit

at ist das rechte Ende des Reality-Virtuality Kontinuum

(siehe Abbildung

2.2055

) und beschreibt die Wirklichkeit, so wie sie

ein Mensch wahrnimmt. Dieses kann durch eine einfache Darstellung

eines Videobildes

uber einen Bildschirm geschehen oder auch durch

In dieser Arbeit werde ich das Reality-Virtuality Kontinuum auch als Mixed Reality Kontinuum

bezeichnen, da sich die Anwendungen, die mit meinem Entwurfsvorgehen entwickelt werden, im

Bereich der gemischten Realit¨

at ansiedeln.

2.4 REALITY-VIRTUALITY KONTINUUM (RV)

Grundsystem

Steuergerät

Aktuatoren Sensoren

HiL Simulator

Signalfluss Energiefluss

Energie Umgebung

Umgebung Umgebung

Funktionalität

Hardware Software

Modell

generiert

Abbildung 2.19: Hardware-in-the-Loop Simulation.

Virtualität RealitätErweiterte Virtualität Erweiterte Realität

Gemischte Realität

Abbildung 2.20: Reality-Virtuality Continuum von Milgram [MTUK94].

die direkte Betrachtung ohne zus

atzliche elektronische Hilfsmittel.

Die Realit

at ben

otigt keine Positionsbestimmung, da hier nur rein

reale Objekte dargestellt werden. Auch aufwendige Visualisierungen

fallen hier weg. Software, die rein auf der Realit

at basiert, ist z.B. eine

Videokamera, die einfach die Realit

at als Abfolge von Einzelbildern

auf dem Computer speichert.

2.4.2 Virtuelle Realit¨at

Als virtuelle Realit

at (engl. Virtual Reality, kurz VR), wird die Dar-

stellung und gleichzeitige Wahrnehmung der Wirklichkeit und ihrer

physikalischen Eigenschaften in einer in Echtzeit computergenerierten,

interaktiven virtuellen Umgebung bezeichnet. Es wird versucht die

Wirklichkeit so gut wie m

oglich abzubilden und die physikalischen

Eigenschaften zu simulieren. Beispiele sind Flug- oder Fahrzeugsimu-

GRUNDLAGEN

latoren, die versuchen die Gravitationskr

afte nachzuempfinden. Aber

auch einfache virtuelle Umgebungen, die nicht die physikalischen

Eigenschaften zu simulieren versuchen, werden zur virtuellen Realit

gez

ahlt. Hierzu z

ahlen auch Großraumprojektionen und CAVEs

. F

virtuelle Systeme werden meist leistungsstarke Rechner und Grafik-

systeme ben

otigt, die in der Lage sind die virtuelle Umgebung in

Echtheit darzustellen. F

ur CAVEs werden zus

atzlich Trackingsyste-

ben

otigt um die korrekte Projektion f

ur den Benutzer bestimmen

zu k¨

onnen.

2.4.3 Augmented Virtuality

Als erweiterte Virtualit

at (engl. Augmented Virtuality, kurz AV) werden

Systeme angesehen, die gr

oßtenteils aus einer VR-Umgebung bestehen

und Teile der Realit

at in die VR-Umgebung einbeziehen. Beispiele

aren ein reales Video, was in der virtuellen Umgebung dargestellt

wird, oder reale Audioquellen wie z. B. eine T

urklingel, die an die

virtuelle Umgebung weitergeleitet wird. Leistungsstarke Rechner und

Grafiksysteme sind f

ur die Verwendung von AV notwendig, da die

Umgebung zum gr

oßten Teil virtuell ist. Tracking kann in Einzelf

allen

otig sein, um z. B. das reale Bild mit der virtuellen Umgebung zu

synchronisieren.

2.4.4 Augmented Reality

Bei der erweiterte Realit

at (engl. Augmented Reality, kurz AR) steht

im Gegensatz zur virtuellen Realit

at, bei der der Benutzer komplett

in einer virtuellen Welt eintaucht, die Darstellung zus

atzlicher In-

formationen im Vordergrund. F

ur die visuelle Modalit

at f

uhrt dies

zu wesentlich h

arteren Anforderungen an die Positionsbestimmung

(Tracking) und Kalibrierung. Unter einem AR-System (kurz ARS) ver-

steht man das System der technischen Bestandteile, die n

otig sind,

um eine Augmented-Reality Anwendung aufzubauen, die da w

aren:

Kamera, Trackingger¨

ate, Unterst¨

utzungssoftware usw.

Die Literatur verwendet meist die Definition der erweiterten Realit

von Azuma [Azu97]:

•

Die virtuelle Realit

at und die Realit

at sind miteinander kombi-

niert (teilweise ¨

uberlagert).

CAVE steht f

”

Cave Automatic Virtual Environment“, zu deutsch

”

ohle mit automatisierter,

virtueller Umwelt“.

Mit Tracking bezeichnet man die kontinuierliche Positionsbestimmung realer Objekte im Raum. Die

Positionsbestimmung kann Zwei- oder Dreidimensional erfolgen.

2.5 ZUSAMMENFASSUNG

•Die Interaktivit¨

at erfolgt in Echtzeit.

•

Reale und virtuelle Objekte haben einen dreidimensional Bezug

zueinander.

Diese Definition beschr

ankt sich leider nur auf die technischen Merk-

male, die allerdings nur ein Teilaspekt der erweiterten Realit

at sind.

AR wird in anderen Arbeiten (beispielsweise bei

”

Cybertechnolo-

gien als Werkzeug im Bauwesen“ [

EB08

]) als eine Ausweitung der

Sinneswahrnehmung des Menschen durch Sensoren von Umgebungs-

eigenschaften definiert, die der Mensch selbst nicht wahrnehmen kann.

Beispiele f¨

ur diese Definition sind Radar, Infrarot, Distanzbilder, etc.,

die die Normale Sichtweise des Benutzers erweitern k¨

onnen.

2.5 Zusammenfassung

In diesem Kapitel wurden zu Anfang die verschiedenen Vorgehensmo-

delle und Architekturmuster vorgestellt, die Grundlage dieser Arbeit

sind. Die herausragenden Aspekte der einzelnen Modelle und Mus-

ter wurden in den jeweiligen Unterkapiteln kurz herausgestellt und

erl

autert. Weiterhin wurde der Aufbau der Modelle und Muster dar-

gestellt und durch Abbildungen verdeutlicht. Die wichtigsten Quellen

wurden f¨

ur weiterf¨

uhrende Nachforschungen angegeben.

Im Kapitel

”

Modellbildung und Simulation“wurden die In-The-Loop-

Simulationen vorgestellt, die Teil meines Entwurfsvorgehens sind.

Es wurden die einzelnen Simulationstechniken in einzelnen Kapitel

vorgestellt und an Grafiken deren Vorgehen verdeutlicht.

Als eine weitere Grundlage dieser Arbeit wurde das von Milgram

eingef

uhrte Reality-Virtuality Kontinuum in diesem Kapitel vorgestellt

und beschrieben. Dabei wurde der Begriff Mixed Reality eingef

uhrt

und die einzelnen Zwischenformen Realit

at, virtuelle Realit

at, er-

weiterte Virtualit

at und angereicherte Realit

at wurden in einzelnen

Abschnitten kurz erkl¨

art.

GRUNDLAGEN

KAPITEL 3

Stand der Forschung

In diesem Kapitel wird der aktuelle Stand der Forschung in den Ge-

bieten Mixed Reality Entwurfskonzepte und Software Frameworks

vorgestellt, auf denen der MRiL-Entwurfsprozess basiert bzw. die er

zu verbessern versucht. Dabei werden aktuelle Arbeiten in den Gebie-

ten vorgestellt und kurz umrissen. Diese Arbeiten sind als Grundlage

zum einen des Entwurfsprozesses selbst und zum anderen des MiRe-

AS Software Framework zu sehen.

3.1 ¨

Ubersicht

Abbildung 3.1: Anwendungen basierend auf dem ARToolKit.

Die Technik, Augmented Reality bzw. Mixed Reality Konzepte softwa-

rem

aßig zu verwenden, ist schon einige Jahre alt und wurde gerade

durch das ARToolKit [

KB99

] f

ur viele Entwickler erstmals einsetzbar.

Dabei wurde mit dem ARToolKit eine Software-Umgebung bereitge-

stellt, die es dem Entwickler erm

oglichte, einfach und unkompliziert

eigene Inhalte in AR zu realisieren (linkes Bild in Abbildung

3.1

STAND DER FORSCHUNG

allerdings ben

otigte die Verwendung des ARToolKits Programmierer-

fahrung in C und speziell in OpenGL. Da bei den ersten Versionen des

ARToolKits die Grafik, die Videobildaufzeichung und das Tracking

softwaretechnisch verbunden waren, war es nicht m

oglich, diese Kom-

ponenten zu trennen und Teile in anderen Bibliotheken zu verwenden.

Ein fr

uher Versuch sich zumindest von der Programmiersprache C zu

trennen, wurde in [

GRSP02

] vorgestellt, bei dem das ARToolKit mit

Hilfe der JNI

in Java eingebunden wurde (mittleres und rechtes Bild

in Abbildung

3.1

). Des Weiteren wurde die OpenGL Grafikschnittstel-

le gekapselt und in die damals aktuelle Szenegraphbibliothek Java3D

eingebunden [

GSS04b

]. So war es m

oglich auf einem h

oheren Level

AR Applikationen zu entwickeln [

GSS04c

] [

GSS04a

]. Da die Entwick-

lung von Java3D eingestellt wurde, war auch die Anbindung an das

ARToolKit obsolet.

Um komplexere Anwendungen im Bereich Mixed Reality zu entwi-

ckeln ben

otigt es jedoch mehr als nur eine Softwareumgebung. Wich-

tig ist auch ein Entwurfsvorgehen, um die neuen Herausforderungen,

die bei der Entwicklung von bzw. mit Mixed Reality entstehen, zu

bew

altigen. In diesem Bereich sind auch schon einige Arbeiten ent-

standen. Das

”

Mixed Reality in the Loop“- Entwurfsvorgehen (MRiL)

basiert auf den Grundlagen der iterativen Entwicklung von Software,

die bereits im Kapitel

vorgestellt wurden, dem Virtual Prototyping

vorgestellt von Rix [

RHT95

] und Krassi [

Kra08

] und dem Prinzip der

”

Hardware in the Loop“ (HiL) Simulationen, das bei Schlager [

Sch08

]

ver¨

offentlicht wurde.

Sowohl das Konzept als auch die Implementierung des MRiL-Ent-

wurfsvorgehens ist im Allgemeinen nahe verwandt mit existierenden

Arbeiten im Bereich der Entwicklung von Benutzerschnittstellen ,

speziell mit Arbeiten aus dem Bereich der

”

Mixed Reality User In-

terfaces“, wie beispielsweise den Arbeiten von Cuppens [

CRC06

Ishii [Ish08] und De Boeck [DBVRC07].

Nachfolgend werden die aktuellen Arbeiten in diesem Gebiet kurz

vorgestellt und umrissen.

3.2 Mixed Reality Entwurfskonzepte

In den letzten Jahren haben sich eine Reihe namhafter Experten-

gruppen mit der Entwicklung neuartiger Software-Entwurfskonzepte

ur und mit Mixed Reality befasst. Grund daf

ur ist die steigende

ava

ative

nterface, eine Schnittstelle in Java, um plattformabh

angigen C/C++-Code in Java

einzubinden.

3.2 MIXED REALITY ENTWURFSKONZEPTE

Komplexit

at dieser Anwendungen und das Fehlen passender Ent-

wurfskonzepte gerade im Bereich Mixed Reality.

Virtual Prototyping - Virtual environments and the product design

process

In seinem Buch

”

Virtual Prototyping - Virtual environments and the

product design process“ [

RHT95

] fasste Rix et al. den damals neuen

Begriff des

”

Virtual Prototyping“ durch verschiedene Arbeiten mehre-

rer Wissenschaftlern zusammen. Rix erkl

art den virtuellen Prototypen

als

”

einen bedeutenden Zwischenschritt zum Endprodukt. Anhand

der gegebenen Design Information

[· · · ]

wird es m

oglich sein, einen

Prototypen mit dem Computer zu generieren, der sowohl f

ur realisti-

sche Pr

asentationen als auch zur Interaktion mit dem Produkt schon

in fr

uhen Entwicklungsphasen geeignet ist“

. Rix erwartete

”

durch die

Entwicklung dieser Technologie und die Integration in den Produkt-

Entwicklungsprozess bedeutende Vorteile im industriellen Einsatz“3.

Dabei waren die Hauptargumente die Zeit- und Kostenersparnis und

die Steigerung der Qualit

at eines Produkts. Aus diesem Grund wur-

den zwei Workshops im Herbst 1994 abgehalten, die zum Ziel hatten,

die damaligen Konzepte und Methoden von

”

Virtual Prototyping“

zusammenzutragen. Zu diesem Zeitpunkt existierte allerdings noch

kein Entwurfsvorgehen f¨

ur jegliche Art von virtuellem Prototyping.

VP - Virtual environments and the product design process

Autoren Rix, Haas, Jos´

eJahr 1995

Bereich Grundlagen, Theorie

Beschreibung Vorstellung des Begriffs Virtual prototyping

Merkmale: + Definition des Begriffs

+ Anwendungsbeispiele

- Nur VR

- Kein konkretes Entwurfsvorgehen

- Kein Modell

Aus

”

Virtual Prototyping - Virtual environments and the product design process“ [

RHT95

], Seite

viii (eigene ¨

Ubersetzung)

Aus

”

Virtual Prototyping - Virtual environments and the product design process“ [

RHT95

], Seite

viii (eigene ¨

Ubersetzung)

STAND DER FORSCHUNG

Dynamic Virtual Prototyping for Control Engineering

Boris Krassi erl

autert in seinem Buch

”

Dynamic Virtual Prototyping

for Control Engineering“ [

Kra08

], dass

”

virtuelle Prototypen, oder

digitale Mockups, die Basis der digitalen Entwicklung sind. Virtual

Prototyping ist seit Jahren ein n

utzliches Werkzeug im Bereich der

Control System Analyse und nach und nach w

achst das Interesse an

der direkten Entwicklung von Kontrollsystemen auf Basis von virtuel-

len Prototypen. W

urde man die L

ucke zwischen dem Control Design

und dem Virtual Prototyping schließen, k

onnte man die Redundanz

von Modellen vermeiden, Designfehler minimieren, Anpassungen

von Produkt

anderungen erleichtern, die Zusammenarbeit zwischen

Produkt- und Lifecycle-Prozessen verbessern und die Zeit bis zur

Produkteinf

uhrung verk

urzen. Erschwert wird dies jedoch durch die

Heterogenit

at, Komplexit

at, Inkompatibilit

at und Unvollst

andigkeit

der Modelle, vergleicht man die virtuellen Prototypen und Modelle,

die f

ur die Entwicklung von Kontrollsystemen ben

otigt werden“

Krassi stellt in seinem Buch nun Konzepte, Methoden und Werkzeuge

vor, um das Control System Development im dynamischen virtuellen

Prototyping – einer Unterklasse des virtuellen Prototyping – zu inte-

grieren. Das Buch zeigt, dass virtuelle Prototypen auch in Bereichen

eingesetzt werden k

onnen, die normalerweise sehr pr

azise Modelle

ur die Entwicklung ben

otigen. Das vorliegende Buch konzentriert

sich allerdings nur auf den Bereich Control Engeneering und auch

die

Uberf

uhrung der virtuellen Prototypen zu realen Prototypen wird

vernachl¨

assigt.

Dynamic Virtual Prototyping for Control Engineering

Autor Krassi Jahr 2008

Bereich Grundlagen, Anwendungen

Beschreibung Verkn¨

upfung zweier Gebiete

Merkmale: + Konzepte, Methoden, Werkzeuge

+ Anwendungsbeispiele

- Nur VR

- Nur der Bereich Control Engeneering

- Nur dynamisches Prototyping

Aus

”

Dynamic Virtual Prototyping for Control Engineering“ [

Kra08

], Vorwort (eigene

Ubersetzung)

3.2 MIXED REALITY ENTWURFSKONZEPTE

Abbildung 3.2: TUI von Ishii. [Ish08]

The tangible user interface and its evolution

Auch Ishii hat schon in seinen Arbeiten, die er in

”

The tangible user

interface and its evolution“ [

Ish08

] aus dem Jahre 2008 zusammen-

fasst, versucht, das Prinzip der grafischen Benutzerschnittstelle zu

ver

andern. Dies ist

ahnlich dem in dieser Arbeit vorgestellten Vor-

gehen, das MVC Architekturmuster zu erweitert. In seiner Arbeit

beschrieb er die Entwicklung der sogenannten Tangible User Interfaces

(TUI), was zu Deutsch bedeutet: f

uhlbare bzw. greifbare Benutzer-

schnittstellen.

”

Die Tangible Media Group des MIT Media Laboratory stellte schon

Mitte der 90er Jahre von der GUI zu TUIs um. Dabei repr

asentieren

TUIs einen neuen Ansatz der Vision von Mark Weiser [

Wei91

]

uber

STAND DER FORSCHUNG

ubiquitous computing (was soviel bedeutet wie die Allgegenw

artigkeit

der rechnergest

utzten Informationsverarbeitung), indem digitale Tech-

nologie in die Strukturen der physikalischen Umgebung eingewoben

wird und so die Technologie unsichtbar erscheint. Anstatt Pixel zu

Benutzerschnittstellen zu verschmelzen, benutzen TUIs eine physi-

kalische Form, die sich nahtlos in die physikalische Umgebung des

Benutzers einpasst. Ziel der TUIs ist das haptische K

onnen bei der

Interaktion auszunutzen, ein Ansatz der sich signifikant von den GUIs

unterscheidet. Dabei bleibt die Hauptidee bestehen: Verleihe physi-

kalischen Gegenst

anden digitale Informationen [

IU97

], benutze sie

als Repr¨

asentation und kontrolliere damit die digitalen Gegenst¨

ucke.

TUIs machen somit digitale Informationen direkt durch unsere H

ande

manipulierbar und sind mit Hilfe unserer peripheren Sinne

uber ihre

physikalische Verk

orperung wahrnehmbar, siehe Abbildung

3.2

oben

links“5.

Mit Hilfe der Definition von TUIs entwickelte Ishii 1999 die erste

Generation von TUIs, die sogenannte Urban Planning Workbench oder

kurz Urp [UI99].

”

Urp verwendet maßstabsgetreue physikalische Modelle architektoni-

scher Bauwerke, um damit eine Simulation der Schatten, der Lichtre-

flexionen sowie der Windbewegung und der Verkehrsbelastung einer

Stadt zu konfigurieren und zu kontrollieren, dargestellt in Abbildung

3.263

oben rechts“

. Dabei sind die physikalischen Modelle der Bau-

werke die greifbaren (tangible) Repr

asentanten der digitalen Modelle.

”

Um die Position oder Orientierung eines Geb

audes zu

andern muss

der Benutzer nur das physikalische Modell bewegen anstatt mit einer

Maus die graphische Repr

asentation am Bildschirm auszuw

ahlen und

zu verschieben. Die physikalische Form der Modellgeb

aude in Urp

und die Informationen, die mit der Position und Orientierung auf der

Arbeitsfl

ache verkn

upft sind, repr

asentieren und kontrollieren somit

den Status der Simulation“7.

Urp hatte allerdings das Problem, dass alle Modelle, sowohl phy-

sikalisch als auch digital, vordefiniert sein mussten. Der Benutzer

konnte w

ahrend der Arbeit mit Urp die Formen nicht

andern. Mit

diesem Hintergrund entstand die zweite Generation der TUIs von

Ishii., SandScape [IRP+04].

”

Die Entstehung neuer Abtast- (sensing) und Anzeigetechnologien

machte es m

oglich, die Entwicklung von dynamischen Formen in

TUIs zu integrieren. Vorgeschlagen wurde die Richtung hin zu digi-

5Aus ”The tangible user interface and its evolution“ [Ish08], Seite 34 (eigene ¨

Ubersetzung)

6Aus ”The tangible user interface and its evolution“ [Ish08], Seite 34 (eigene ¨

Ubersetzung)

7Aus ”The tangible user interface and its evolution“ [Ish08], Seite 35 (eigene ¨

Ubersetzung)

3.2 MIXED REALITY ENTWURFSKONZEPTE

talen/physikalischen Materialien, die nahtlos F

uhlen (sensing) und

Anzeigen miteinander verbinden. Anstatt vordefinierte diskrete Objek-

te mit statischen Formen zu benutzen, entwickelte die Tangible Media

Group einen neuen Typ der organischen TUIs, der ein kontinuierliches

uhlbares Material (

ahnlich Ton oder Sand) verwendete. Als Beispiele

wurden der Illuminating Clay [

PRI02

] und SandScape [

IRP+04

] (siehe

Abbildung

3.263

unten) entwickelt. Mit der Entwicklung von flexiblem

Materialien, die vollflexible Sensoren und Anzeigen integrieren, zeigt

die Kategorie der organischen TUIs ein großes Potenzial um Ideen in

f¨

uhlbarer Form auszudr¨

ucken“8.

Allgemein versucht Ishii eine physikalische/reale Repr

asentation di-

gitaler Daten zu erzeugen, mit dem der Benutzer interagieren kann,

die jedoch gleichzeitig wieder die digitalen Daten

andern. Dieselbe

Vorgehensweise ist auch bei vielen Mixed Reality Anwendungen zu

finden: Es wird versucht Informationen, aus der realen Welt zu ex-

trahieren und diese dann digital zu verarbeiten. Dabei ist es wichtig,

dass das Feedback zum Benutzer mit der physikalischen/realen Welt

konform geht, so dass eine gewisse Verschmelzung der realen und

der digitalen Welt entsteht. Ishii setzt hier mehr den Fokus auf die

Benutzerschnittstellen und stellt einige Prototypen von TUIs vor, geht

allerdings nicht auf die allgemeine Entwicklung ein. In dieser Arbeit

steht jedoch die Entwicklung solcher Applikationen im Vordergrund

und es wird versucht, eine Vorgehensweise bei der Entwicklung von

MR Anwendungen zu finden.

The tangible user interface and its evolution

Autor Ishii Jahr 1999

Bereich Grundlagen, Anwendungsbeispiele

Beschreibung Beispiele und Methoden f¨

ur TUIs

Merkmale: + Konzepte, Methoden, Werkzeuge

+ Anwendungsbeispiele

+ Mixed Reality

- Beschr¨

ankt auf Benutzerschnittstellen

- Kein Entwurfsvorgehen

- Kein Prototyping-Ansatz

8Aus ”The tangible user interface and its evolution“ [Ish08], Seite 35 (eigene ¨

Ubersetzung)

STAND DER FORSCHUNG

Weitere Entwurfskontzepte

Weitere interessante Arbeiten im Themengebiet des modellbasierter

Entwurf und der grafische Programmierung sowie die Prinzipien

und Leitlinien der Mensch-Maschine-Interaktion f

ur Mixed Reality

Systeme, deren konkrete Vorstellung jedoch den Rahmen dieser Arbeit

uberschreiten w

urde, finden sich u. a. bei den Pr

asentationen des

MRUI07-Workshop, der auf der VR 2007 stattgefunden hat. [

DFL06

]

Eine weitere sehr gute Quelle f

ur vertiefende Informationen ist der

j¨

ahrlich stattfindende SEARIS Workshop. [SEA08]

3.3 Entwurfskonzepte mit Werkzeugumgebung

Im vorangegangenen Kapitel wurden reine Konzepte (teilweise mit

konkreten Implementierungen) vorgestellt. In diesem Kapitel beinhal-

ten die vorgestellten Konzepte gleichzeitig noch eine Werkzeugum-

gebung zur Entwicklung eigener Projekte im Bereich Mixed Reality.

Teilweise bieten die Arbeiten auch automatische Generatoren, die aus

den gegebenen Konzepten ausf

uhrbare Programme generieren. Ich

ochte hier nur die wichtigsten Arbeiten in diesem Bereich vorstellen,

die auch einen Bezug zu meiner Arbeit haben.

A model-based design process for interactive virtual environments

Ein spezielles Entwurfsvorgehen stellt Cuppens bereits 2006 in seiner

Arbeit

”

A model-based design process for interactive virtual envi-

ronments“ [

CRC06

] vor. Es ist ein modellbasierter Entwurfsprozess

ur virtuelle Umgebungen, im Speziellen die Benutzerschnittstellen

innerhalb dieser virtuellen Umgebungen. Cuppens f

uhrt an, dass

”

die

Entwicklung der Benutzerschnittstellen in diesen virtuellen Umgebun-

gen kein unkomplizierter Prozess und somit f

ur Nicht-Programmierer

nicht einfach verst

andlich und anwendbar ist. Das Papier stellt einen

modellbasierter Entwurfsprozess f

ur genau diese im hohen Maße

interaktiven Anwendungen vor, um die Diskrepanz zwischen Desi-

gner und Programmierer zu minimieren. Der Prozess basiert sowohl

auf den Anforderungen eines modellbasierter Entwurfsprozesses f

Benutzerschnittstellen und Werkzeugen und Toolkits f

ur virtuelle

Umgebungen“9.

Bei dem Entwurfsprozess, der in Abbildung

3.367

visuell dargestellt

Aus

”

A model-based design process for interactive virtual environments“ [

CRC06

], Seite 225 (eigene

Ubersetzung)

3.3 ENTWURFSKONZEPTE MIT WERKZEUGUMGEBUNG

Abbildung 3.3: Entwurfsprozess von Cuppens [CRC06].

ist, wird zu Beginn ein Aufgabenmodell (Task Modell) mit Hilfe der

ConcurTaskTree (CTT) Notation [

Pat99

] erstellt, und

uber das Interac-

tion Description Model (IDM) erweitert.

”

Nachdem ein Task Model

einmal entworfen wurde, kann der Algorithmus, der von Luyten

et al. [

LCCV03

] beschrieben wurde, dazu benutzt werden, um das

Dialog Model automatisch von der CTT zu extrahieren. Das Dialog

Model basiert auf den Enabled Task Sets (ETS) [

Pat99

], die vom Task

Modell der Applikation abgeleitet werden.

[· · · ]

Die resultierenden

ETSs k

onnen auf verschiedene Zust

ande der Anwendung abgebildet

werden, die alle Interaktionsaufgaben des jeweiligen Zustands bein-

halten.

[· · · ]

Nachdem das Dialog Model extrahiert wurde, k

onnen

die unterschiedlichen Zust

ande der Anwendung mit den Interakti-

onstechniken verbunden werden, die von den IDMs definiert wurden.

Des Weiteren muss der Entwickler nun das Dialog Model mit dem

Presentation Model zusammenf¨

ugen. [· · · ]Nach Beendigung des ge-

samten Entwurfsprozesses werden die spezifizierten Modelle f

ur eine

automatisierte Generierung einer lauff

ahigen Version der virtuellen

STAND DER FORSCHUNG

Umgebungs-Anwendung verwendet. “10

Das von Cuppens vorgestellte Entwurfsvorgehen basiert auf einem

linearen Ansatz und sieht keine Iterationen und dementsprechend

keine Entwicklung mehrerer Prototpyen vor. Weiterhin bezieht es den

Aspekt der Mixed Reality nicht mit ein, der Prozess ist ausschließlich

f¨

ur reine virtuelle Umgebungen entworfen worden.

A model-based design process for interactive virtual environments

Autoren Cuppens, Raymaekers, Coninx Jahr 2006

Bereich Entwurfsvorgehen

Beschreibung Spezielles Entwurfsvorgehen in VR

Merkmale: + Konzepte, Methoden, Werkzeuge

+ Anwendungsbeispiele

+ Automatische Generierung

- Beschr¨

ankt auf Benutzerschnittstellen

- Nur VR

- Nicht iterativ

Mixed Reality: A model of Mixed Interaction

Eine weitere Arbeit im Bereich Entwurf, die sich speziell auf die Inter-

aktion in Mixed Reality bezieht, ist

”

Mixed Reality: A model of Mixed

Interaction“ von Coutrix und Nigay aus dem Jahre 2006 [

CN06

”

Bei

Mixed Reality Systemen wird versucht, die physikalische und die

elektronische (digitale) Umgebung nahtlos zu verkn

upfen. Obschon

Mixed Reality Systeme sich stetig weiter verbreiten, existiert noch

kein klares Verst

andnis

uber das Interaktionsparadigma. Um dieses

Problem zu zu l

osen, wird in dem Artikel ein neues Interaktionsmo-

dell [

BL04

] mit dem Namen Mixed Interaction Model vorgestellt“

Dabei ist es

”

das Ziel des Interaktionsmodells dem Designer ein Fra-

mework anzubieten, die ihn durch der Erschaffung von interaktiven

Systemen leiten“

. Ein Interaktionsmodell kann dabei entlang der

folgenden drei Dimensionen charakterisiert werden [BL04]:

Darstellung/Klassifizierung:

Entspricht dem Potential, eine aussa-

gekr

aftige Auswahl existierender Schnittstellen zu beschreiben

Aus

”

A model-based design process for interactive virtual environments“ [

CRC06

], Seite 231 (eigene

Ubersetzung)

11Aus ”Mixed Reality: A model of Mixed Interaction“ [CN06], Seite 43 (eigene ¨

Ubersetzung)

12Aus ”Mixed Reality: A model of Mixed Interaction“ [CN06], Seite 43 (eigene ¨

Ubersetzung)

3.3 ENTWURFSKONZEPTE MIT WERKZEUGUMGEBUNG

und zu klassifizieren.

Erzeugung:

Entspricht dem Potential, dem Designer dabei zu helfen,

neue Designs zu entwerfen.

Komparativit¨

at:

Entspricht dem Potential, mehrere Designalternati-

ven zu beurteilen.

”

Das Mixed Interaction Model setzt den Schwerpunkt auf die Ver-

upfung der physikalischen und digitalen Welt und die Interaktion

des Benutzers mit der dadurch entstandenen Mixed Reality Umge-

bung.

[· · · ]

Das Hauptkonzept des Mixed Interaction Model ist dabei

das mixed object“13.

mixed object

physical

properties

digital

properties

doi

doo

loi

loo

accquired

physical

data

generated

physical

data

Abbildung 3.4: Mixed Object [CN06]

”

Ein reales Objekt besteht aus einer Menge verschiedener physikali-

scher Eigenschaften. Gleiches gilt f

ur ein digitales Objekt, welches

aus einer Menge verschiedener digitaler Eigenschaften besteht. Ein

mixed object ist nun eine Kombination beider Mengen: Eine Menge

physikalischer Eigenschaften, die mit einer Menge digitaler Eigen-

schaften verkn

upft sind. Um die Verkn

upfung der beiden Mengen zu

beschreiben, werden zwei Arten

(d,l)

ber

ucksichtigt. Einerseits die

Verkn

upfungen zwischen physikalischen und digitalen Eigenschaften

eines Objektes, die linking modalities genannt werden, andererseits die

Verkn

upfungen zur Interaktion des Benutzers mit der Mixed Reality

Umgebung, die interaction modalities heißen. Aus Sicht des Systems

onnen also zwei Arten von Verkn

upfung f

ur ein mixed object identifi-

ziert werden, wie in Abbildung 3.4 zu sehen ist“14:

•Die Eingabeverkn¨

ufungen (doi,loi)sind zust¨

andig f¨

ur:

13Aus ”Mixed Reality: A model of Mixed Interaction“ [CN06], Seite 43 f. (eigene ¨

Ubersetzung)

14Aus ”Mixed Reality: A model of Mixed Interaction“ [CN06], Seite 44 (eigene ¨

Ubersetzung)

STAND DER FORSCHUNG

Beschaffung einer Untermenge von physikalischen Eigen-

schaften mit Hilfe des Devices doi(object input device).

Interpretieren der empfangenen physikalischen Daten be-

uglich der digitalen Eigenschaften mit Hilfe der Sprache

loi(object input language).

•Die Ausgabeverkn¨

ufungen (doo,loo)sind zust¨

andig f¨

ur:

Generierung von Daten auf Basis der Menge der digita-

len Eigenschaften mit Hilfe der Sprache

loo

(object output

language),

2.¨

Ubersetzten der generierten physikalischen Daten in er-

kennbare physikalische Eigenschaften mit Hilfe des Devices

doo(object output device).

”

Ein mixed object kann nun (1) auf einer Eingabeverkn

ufung, (2) auf

einer Ausgabeverkn

ufung oder (3) auf einer Ein- und Ausgabever-

kn¨

ufung basieren“15.

picture

physical

properties

identifier,

information

related to

the picture

(author, etc.)

camera

head

mounted

display

loi

loo

image

Abbildung 3.5: Ein Bild in NaviCam [RN95]

”

In Abbildung

3.5

wir das Beispiel des NaviCam Systems von Reki-

moto [

RN95

] betrachtet und ein augmented picture als mixed object mo-

delliert. Dabei zeichnet die Kamera die physikalischen Eigenschaften

dieses Objektes auf. Das Foto wird dann in ein Identifizierungsmerk-

mal des erkannten Bildes

ubersetzt. Die zu diesem Bild zugeh

origen

Informationen werden nachfolgend auf einem Head-Mounted Dis-

play (HMD) angezeigt. Die Verkn

upfungen bei diesem Beispiel sind

elementar, allerdings k

onnen die Ein- und Ausgabeverkn

ufung auch

zusammengesetzt sein. Die Zusammensetzung der Ein- und Ausga-

beverkn

ufungen wurde basierend auf dem CARE (Complementarity,

15Aus ”Mixed Reality: A model of Mixed Interaction“ [CN06], Seite 44 (eigene ¨

Ubersetzung)

3.3 ENTWURFSKONZEPTE MIT WERKZEUGUMGEBUNG

Assignment, Redundancy and Equivalence) Framework charakteri-

siert [NC97] [VN00]“16.

”

Zusammenfassend kann also ein mixed object anhand seiner Ein- und

Ausgabeverkn

ufung charakterisiert werden, wobei die Verkn

upfungen

ihrerseits entweder nicht vorhanden, elementar oder zusammenge-

setzt sind“17.

”

Eine Mixed Interaction bedingt ein mixed object.

[· · · ]

Um eine Mi-

xed Interaction zu modellieren wurde das Instrumental Interaction mo-

del [

BL04

] durch die Definition des mixed object und die Definition der

Art der Interaktion, die als eine Kopplung eines Devices

mit einer

Sprache lbeschreiben ist, erweitert“18.

In der Arbeit wurde mit Hilfe der mixed object versucht, die reale bzw.

physikalische Umgebung zu erfassen und sofwaretechnisch abzubil-

den. Die mixed object sind eine M

oglichkeit, die realen Eigenschaften

der Umgebung zu kapseln bzw. digitale Ereignisse der Umgebung

zur Verf

ugung zu stellen. In meiner Arbeit gehe ich allerdings einen

anderen Weg, da ich die Umgebung als gegeben und unver

anderlich

(bzgl. der programmierten Anwendung) sehe. Durch eine Erweiterung

des MVC Architekturmusters kann dieses erreicht werden.

Mixed Reality: A model of Mixed Interaction

Autoren Coutrix, Nigay Jahr 2006

Bereich Entwurfsvorgehen

Beschreibung Interaktion in Mixed Reality

Merkmale: + Modell, Methoden, Werkzeuge

+ Anwendungsbeispiele

+ Mixed Reality

- Beschr¨

ankt auf Interaktionen

- Nicht iterativ

High-level modeling of multimodal interaction techniques using

NiMMiT

Ein weiteres Projekt im Bereich Entwurf von VR/MR Interaktionstech-

niken ist NiMMiT

. In der Arbeit von von De Boeck et al. mit dem

16Aus ”Mixed Reality: A model of Mixed Interaction“ [CN06], Seite 44 (eigene ¨

Ubersetzung)

17Aus ”Mixed Reality: A model of Mixed Interaction“ [CN06], Seite 44 (eigene ¨

Ubersetzung)

18Aus ”Mixed Reality: A model of Mixed Interaction“ [CN06], Seite 44 (eigene ¨

Ubersetzung)

19NiMMiT steht f¨

ur Notation for Modeling Multimodal interaction Techniques.

STAND DER FORSCHUNG

Titel

”

High-level modeling of multimodal interaction techniques using

NiMMiT“ [

DBVRC07

] wird eine grafische Notation f

ur multimodale

VR Interaktionstechniken vorgestellt, die auf der Statechart-Notation

von David Harel [Har87] basiert.

”

NiMMiT erlaubt es dem Designer multimodaler Interaktionstech-

niken schnell Alternativen zu testen oder sehr einfach existieren-

de L

osungen zu adaptieren je nach Evaluation von Benutzertests,

was den Entwicklungszyklus signifikant verk

urzt. Die automatische

Ausf

uhrung der Interaktionstechniken wird von NiMMiT unterst

utzt

indem die Diagramm-Repr

asentation interpretiert wird. Des Weite-

ren wird durch die High-Level Beschreibung die Wiederverwendung

einzelner L¨

osungen vereinfacht“20.

ur De Boeck sollte eine Notation, die eine Interaktionstechnik be-

schreiben will, folgenden Anforderungen entsprechen [DBVRC07]:

•Ereignisgetrieben (event driven)

•Zustandsgetrieben (state driven)

•Datengetrieben (data driven)

•

Unterst

utzung einer Kapselung f

ur die hierarchische Wiederver-

wendbarkeit

Die Notation von NiMMiT basiert auf allen oben angef

uhrten An-

forderungen, so dass sich eine Interaktionstechnik folgendermaßen

beschreiben l¨

asst:

”

NiMMiTs Notation ist sowohl ereignis- als auch zustandsgetrieben,

so dass ein Diagramm grunds

atzlich der Gestalt von Statecharts ent-

spricht. Eine Interaktionstechnik wird immer mit einem Startzustand

initialisiert. Ein Zustand reagiert auf eine beschr

ankte Menge von

Ereignissen (Events), beispielsweise Spracheingabe, Zeigerbewegung

oder einen Click auf einen Button. Wird ein Event erkannt wird ei-

ne Task chain ausgef

uhrt, zu sehen in Abbildung

3.673

a).

[· · · ]

Die

Ausf

uhrung einer Task chain ist strikt linear, was bedeutet, dass der

achste Task einer Task chain dann und nur dann ausgef

uhrt wird,

wenn der vorherige Task erfolgreich beendet wurde. Abbildung

3.673

b) zeigt eine Task chain mit zwei Tasks.

[· · · ]

Ein Ausgangsport ei-

nes vorangegangenen Tasks ist typischerweise mit dem Eingangsport

des nachfolgenden Task verbunden. Diese Eingangsports k

onnen so-

wohl optional als auch obligatorisch sein. Sollte ein obligatorischer

Aus

”

High-level modeling of multimodal interaction techniques using NiMMiT“ [

DBVRC07

], Seite

2(eigene ¨

Ubersetzung)

3.3 ENTWURFSKONZEPTE MIT WERKZEUGUMGEBUNG

a) Startzustand mit möglichen Events b) Task chain c) Datenfluss zwischen Tasks u. Label

d) Zustandsübergang e) Bedingter Zustandsübergang

Abbildung 3.6: Grafische Repr¨

asentation von NiMMiT [DBVRC07].

Eingangsport eines Tasks einen nicht zul

assigen Wert erhalten, wird

die Ausf

uhrung der kompletten Task chain abgebrochen. Um Daten

zwischen Tasks unterschiedlicher Task chains miteinander nutzen oder

um Daten f

ur sp

atere Verwendung speichern zu k

onnen, wurden

High-Level Variablen in Form von Labels eingef

uhrt, wie in Abbildung

3.673

c) gezeigt wird. Nach der erfolgreichen Ausf

uhrung einer Task

chain findet ein Zustands

ubergang statt, zu sehen in

3.673

d). Hier

kann nun in einen neuen Zustand gewechselt oder wieder zur

uck

in denselben Zustand gesprungen werden (in einer Schleife). In ei-

nem neuen Zustand k

onnte die beschriebene Interaktionstechnik nun

auf eine andere Menge von Ereignissen reagieren. Einer Task chain

onnen mehrere verschiedene Zustands

uberg

ange assoziiert werden:

Der Wert des Label einer Task chain legt fest welcher Zustands

ubergang

ausgef

uhrt wird. Abbildung

3.673

e) zeigt eine Task chain mit dem Label

’ID’ und drei m¨

ogliche Zustands¨

uberg¨

ange“21.

Mit Hilfe der grafischen Notation kann der Designer schnell Inter-

aktionstechniken realisieren. Damit diese allerdings auch getestet

werden k

onnen, bedarf es einer schnellen Umsetzung der Diagram-

me in ausf

uhrbaren Programmcode. Der NiMMiT Editor bietet diese

Funktionalit

at an. Da NiMMiT f

ur die Erstellung virtueller Umgebung

entwickelt wurde, ist es mit dem Editor m

oglich, die Interaktionstech-

niken

uber ein XML Austauschformat zu exportieren und dieses in

die f

ur NiMMiT entwickelte virtuelle Umgebung zu laden. Diese f

uhrt

Aus

”

High-level modeling of multimodal interaction techniques using NiMMiT“ [

DBVRC07

], Seite

3f. (eigene ¨

Ubersetzung)

STAND DER FORSCHUNG

Conversion

Execution

Load

Abbildung 3.7: Die NiMMiT Toolchain [DBVRC07].

dann die Interaktionstechniken aus. Der Ablauf wird in Abbildung

3.774

noch einmal verdeutlicht. Nachdem die Interaktionstechnik im

Editor entwickelt wurde, wird sie in XML umgewandelt und in die

virtuelle Umgebung geladen, die sie dann ausf¨

uhrt.

NiMMiT ist f

ur die Entwicklung von Interaktionstechniken gut geeig-

net: Gerade mit der grafischen Repr

asentation lassen sich schnell neue

Techniken entwickeln. Jedoch basiert NiMMiT auf einer rein virtuellen

Umgebung, die statisch definiert und somit schwer erweiterbar ist. Da

sich mit NiMMiT nur Interaktionstechniken schnell evaluieren lassen,

ist es f¨

ur einen kompletten Entwurfsprozess nicht geeignet.

High-level modeling of multim. interaction techniques

Autoren De Boeck, Coninx et al. Jahr 2007

Bereich Entwurfsvorgehen

Beschreibung Multimodale Interaktionstechniken in VR

Merkmale: + Konzept, Modell, Werkzeuge

+ Anwendungsbeispiele

+ Automatische Generierung

+ Grafische Repr¨

asentation

- Beschr¨

ankt auf Interaktionstechniken

- Nur VR

- Nicht iterativ

3.3 ENTWURFSKONZEPTE MIT WERKZEUGUMGEBUNG

A Design-Oriented Information-Flow Refinement of the ASUR In-

teraction Model

Eine weiteres Modell einschließlich grafischer Notation wurde in der

Ver

offentlichung

”

A Design-Oriented Information-Flow Refinement

of the ASUR Interaction Model“ von Emmanuel Dubois und Phi-

lip Gray aus dem Jahre 2008 vorgestellt [

DG08

]. Basierend auf den

beiden Arbeiten

”

ASUR++: A Design Notation for Mobile Mixed Sys-

tems“ [

DGN02

] aus dem Jahre 2002 und

”

Requirements and Impacts

of Model driven engineering on Mixed Systems Design“ [

DCD05

] aus

dem Jahre 2005 beschreibt die Arbeit ein Modell und eine Modellie-

rungstechnik zum Erfassen der Schwerpunkte der Benutzerinteraktion

ahrend der Anforderungsanalyse in einer fr

uhen Phase der Entwick-

lung von Mixed Reality Systemen.

command

Spresentation

perception sense

action sense

User

name

location

share level

Component

Rtool

description

Sobject

role

Stool

Robject

role

Sinfo

Aout Ain

nature

dimension

Computer System

action sense

perception sense

description

Adapter

action sense

perception sense

description

Real Entity

Abbildung 3.8: Komponenten bei ASUR [DCD05].

”

ASUR ist ein auf grafischer Darstellung basiertes Modell zur Be-

schreibung von Benutzer-System Interaktionen in Mixed Reality Sys-

temen. ASUR soll bei der Beurteilung helfen, physikalische und di-

gitale Welten so zu verbinden, dass benutzerfreundliche Resultate

erzielt werden. Zus

atzlich wir es in Verbindung mit der traditionellen

Benutzer-System Aufgabenbeschreibung verwendet, um Objekte zu

identifizieren, die bei der Interaktion beteiligt sind und zwischen den

Grenzen der beiden Welten liegen. Aus Sicht der Benutzerinteraktion

hilft das Modell die Resultate der Anforderungsanalyse zu beschrei-

ben und die globale Entwurfsphase von Mixed Reality Systemen zu

unterst

utzen. AUSR unterst

utzt die Beschreibung von digitalen und

STAND DER FORSCHUNG

physikalischen Entit

aten, die ein Mixed Reality System ausmachen,

u. a. Adapter (

Ain

Aout

), die die Kluft zwischen der digitalen

und physikalischen Welt

uberbr

ucken, digitale Werkzeuge (

Stool

)

bzw. Konzepte (

Sinfo

Sobj

), ein oder mehrere Benutzer (

)

und reale Objekte, die als Werkzeuge (

Rtool

) involviert sind oder

den Fokus der Aufgabe darstellen (

Robj

). Weiterhin dr

ucken gerich-

tete Beziehungen (Linien mit Pfeilen) den physikalischen und/oder

digitalen Fluss von Informationen und die Verbindung zwischen Kom-

ponenten aus. Um diese Elemente besser spezifizieren zu k

onnen, d. h.

AUSR Komponenten und Beziehungen, wurden eine Anzahl an Cha-

rakteristika identifiziert“

. Die unterschiedlichen Komponenten incl.

ihrer Bezeichnungen, die in ASUR existieren, sind in Abbildung

3.8

zu sehen.

Die ASUR Komponenten (

Compontent

) k

onnen somit einem der

folgenden vier Typen angeh¨

oren [DCD05]:

Computer System (S ):

Die Komponente repr

asentiert das Compu-

tersystem und alle digitalen Entit

aten, die an einer Interaktion

beteiligt sind.

Ahnlich den realen Objekten kann das Compu-

tersystem auch in zwei Teile aufgeteilt werden. Zum einen in

die digitalen Entit

aten, die entweder das Verhalten oder das

Erscheinungsbild anderer digitaler Entit

aten ver

andern (

Stool

), zum anderen die digitalen Entit

aten, die ein Ziel einer In-

teraktion und somit Ziel einer Ver

anderung darstellen. Dabei

wird zwischen Objekten, die nur Feedback-Informationen liefen

(Sinfo ) und anderen Objekten (Sobject ) unterschieden.

User (U ):

Der Benutzer repr

asentiert den Anwender des Systems.

ASUR unterst

utzt sowohl Einzel- als auch Mehrbenutzeranwen-

dungen.

Real Entity (R ):

Die realen Entit

aten repr

asentieren reale Objekte.

Das k

onnen sowohl physikalische Werkzeuge (

Rtool

) sein,

die vom Benutzer verwendet werden k

onnen, um eine Funktion

auszu

uben, oder physikalische Objekte (

Robject

), auf die sich

eine Funktion bezieht.

Adapter (A ):

Adapter schlagen eine Br

ucke zwischen der digita-

len und der physikalischen Welt. Dabei unterscheidet ASUR

zwischen Eingabeadapter (

Ain

), die Daten von der physika-

lischen Welt in die digitale Welt

ubertragen (z. B. eine Kamera)

Aus

”

A Design-Oriented Information-Flow Refinement of the ASUR Interaction Model“ [

DG08

Seite 467 (eigene ¨

Ubersetzung)

3.3 ENTWURFSKONZEPTE MIT WERKZEUGUMGEBUNG

und Ausgabeadaptern (

Aout

), die numerische Daten an die

physikalische Welt liefern (z. B. ein Bildschirm).

Camera Wand User_0

Screen

Pointer

Activator

3D volume

Pointer Activator3D volume

Abbildung 3.9: Beispiel eines ASUR Diagramms [DG08].

In Abbildung

3.9 ”

wird die Interaktion eines Benutzers und einer

digitalen 3D Umgebung mit Hilfe eines

”

magischen Zauberstabes“

gezeigt. Der Benutzer User 0verwendet und bewegt einen physikali-

schen

”

Zauberstab“ Wand, der mit Hilfe einer Kamera Camera (

Ain

) verfolgt wird. Die Kamera sendet die Position des Zauberstabes

an einen digitalen Aktivator (

Stool

), der vielleicht noch auf andere

digitale Entit

aten wirkt. Die Kamera sendet des Weiteren die Position

an das Zeigerobjekt Pointer (

Sinfo

). Das Zeigerobjekt ist eigent-

lich eine Repr

asentation der Spitze des physikalischen Zauberstabes

(angedeutet durch den gestrichelten Pfeil); diese Repr

asentation ist

gerade f

ur die Bereitstellung eines Interaktion-Feedbacks zweckm

aßig.

Sobald die Funktionalit

at aktiviert ist, werden Daten wie beispiels-

weise der Rotationswinkel des Zauberstabes an den 3D-Raum 3D

volume (

Sobj

) transferiert. Letztendlich wird der 3D Raum, der

Aktivator und das Zeigerobjekt auf dem Bildschirm Screen (

Aout

)

dargestellt. Eine detailliertere Beschreibung dieses Beispiels mit allen

modellierten Charakteristika ist in [DCD05] zu finden“23.

”

ASUR ist eine reine Modell-Notation: w

ahrend ASUR eine hervorra-

gende Orientierungshilfe f

ur die Entwickler beschreibt, ist das entwi-

ckelte Modell nicht ausf

uhrbar und muss per Hand in den entspre-

Aus

”

A Design-Oriented Information-Flow Refinement of the ASUR Interaction Model“ [

DG08

Seite 467 (eigene ¨

Ubersetzung)

STAND DER FORSCHUNG

chenden Quelltext konvertiert werden. ASUR bietet keine explizite

Unterst¨

utzung von Kollaboration“24.

Mit ASUR ist es sehr einfach m

oglich, eine Mixed Reality Applikation

auf Basis eines Modells zu entwickeln. Mit Hilfe der vorhandenen

Komponenten, die ASUR zur Verf

ugung stellt, ist eine Abdeckung

der digitalen und physikalischen Objekte gegeben. ASUR unterst

utzt

allerdings nicht eine Entwicklung entlang des Mixed Reality Kontinu-

ums. Objekte, die entweder in der digitalen oder physikalischen Welt

verankert wurden, verbleiben w

ahrend der gesamten Entwicklung

darin. Will man die Objekte

andern, so bedarf es einer kompletten

Umstrukturierung der beteiligten Objekte. ASUR bietet weiterhin

nicht die M

oglichkeit, aus dem entwickelten Modell eine lauff

ahige

Applikation zu generieren, wie es beispielsweise bei NiMMiT (siehe

Abschnitt

”

High-level modeling of multimodal interaction techniques

using NiMMiT“ auf Seite 71) m¨

oglich ist.

Information-Flow Refinement of the ASUR Interaction Model

Autoren Dubois, Gray Jahr 2008

Bereich Modell und Notation

Beschreibung Modellierung von Interaktionstechniken in MR

Merkmale: + Konzept, Modell, Werkzeuge

+ Anwendungsbeispiele

+ Grafische Notation

+ Mixed Reality

- Keine Entwicklung entlang d. MR Kontinuums

- Keine Automatische Generierung

- Nicht iterativ

The Engineering of Mixed Reality Systems

In dem aus dem Jahre 2010 stammenden Buch

”

The Engineering of Mi-

xed Reality Systems“ [

DGN10

], herausgegeben von Emmanuel Dubois

et al., wird speziell auf die Entwicklung von Mixed Reality Systemen

eingegangen. Es ist eine Zusammenfassung vieler Artikel bekannter

Wissenschaftler aus den drei großen Bereichen Interactiondesign, Soft-

ware Design und Implementierung sowie Anwendungen von Mixed

Reality.

”

Human Computer Interaction (HCI – zu Deutsch: Mensch-

Maschine-Interaktion) ist nicht mehr auf die Interaktion des Benutzers

mit dem Computer

uber die Tastatur und Bildschirm beschr

ankt: zur

24Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 298 (eigene ¨

Ubersetzung)

3.3 ENTWURFSKONZEPTE MIT WERKZEUGUMGEBUNG

Zeit ist es eine der herausfordernden Aufgaben von interaktiven Sys-

temen, die Integration von physikalischen und digitalen Aspekten auf

benutzbare Konzepte zu verkn

upfen. Die Herausforderung bei der

Entwicklung solcher Mixed Reality (MR) Systeme liegt in der fließen-

den und harmonischen Fusion der physikalischen und der digitalen

Welten. Beispiele solcher Systeme beinhalten Tangible User Interfa-

ces (TUIs – zu deutsch: Greifbare Benutzerschittstellen), Augmented

Reality, Augmented Virtuality und Embodied Interfaces

. Alleine

die Vielf

altigkeit der Begriffe in diesem Bereich hebt das wachsen-

de Interesse an MR Systemen hervor und die hieraus resultierende

dynamische und herausfordernde Dom¨

ane“26.

Im Allgemeinen sind die Arbeiten aus dem ersten Teil (Interactionde-

sign) und dem zweiten Teil (Software Design und Implementierung)

des Buches sind hervorzuheben. Insbesondere sind

”

An Integrating

Framework for Mixed Systems“ von C

eline Coutrix und Laurence Ni-

gay und

”

Fiia: A Model-Based Approach to Engineering Collaborative

Augmented Reality“ von Christopher Wolfe et al. hier erw

ahnenswert

uns sollen im Folgenden n¨

aher vorgestellt werden.

Im Artikel

”

An Integrating Framework for Mixed Systems“ wird

erl

autert, dass

”

in dem sehr dynamischen Mixed Reality Bereich ein

Vergleich der vorhandenen Mixed (Reality) Systems und die daraus

folgende Designspace Exploration sehr schwer realisierbar sind. Um

dieses Entwurfsproblem zu l

osen, stellt der Artikel eine einheitliche

Betrachtungsweise auf Mixed Systems vor, indem auf sogenannte mixed

objects

, die bei der Interaktion involviert sind, der Fokus gelegt

wird. Der vorgestellte integrierte Framework besteht aus zwei sich

gegenseitig erg

anzend Aspekten der mixed objects: Es definiert sowohl

die inh

arenten als auch die extrinsischen Charakteristika eines Objekts

unter Ber

ucksichtigung der seiner Rolle bei der Interaktion. Solche

Charakteristika eines Objekts sind f

ur den feingranularen Vergleich

existierender Mixed Systems n

utzlich. Dabei wird die taxonomische

achtigkeit dieser Charakteristika an aus der Literatur bekannten

Mixed Systems diskutiert. Die generative M

achtigkeit wird anhand

eines von den Autoren entwickelten Systems namens Roam erkl

art“

In Abbildung

3.1080

ist das Schema der Charakteristika von mixed

Schnittstellen, die durch Objekte der realen Welt definiert sind.

”

Embodiment“ meint nicht nur

die physische Verk

orperung von Objekten, sondern bezieht auch andere Aspekte der realen Welt wie

Sprache und soziale Faktoren mit ein. H

aufig wird auch der Oberbegriff

”

Ubiquitous Computing“

verwendet.

26Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 1(eigene ¨

Ubersetzung)

mixed object sind hybride physikalisch-digitale Objekte, die die physikalische und digitale Welt

uberspannen. Sie wurden schon im Kapitel

368

”

Mixed Reality: A model of Mixed Interaction“ [

CN06

]

vorgestellt.

28Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 9(eigene ¨

Ubersetzung)

STAND DER FORSCHUNG

SENSED ACQUIREDG

Abbildung 3.10: Charakterisierung von mixed objects [DGN10].

objects zu sehen.

”

Die physikalischen Eigenschaften werden

uber zwei

orthogonale (sensed/generated)-Achsen definiert, korrespondierend

zu den Eingabe-Ausgabe Achsen aus Bricks [

FIB95

[· · · ]

Unter Be-

ucksichtigung der Besonderheit, dass digitale Eigenschaften sym-

metrisch zu den physikalischen Eigenschaften sein sollen, k

onnen

digitale Eigenschaften

uber zwei orthogonale (acquired/materialized)-

Achsen definiert werden. Eine digitale Eigenschaft kann

uber jede

Art von Verbindung erlangt (engl. acquired) und/oder materialisiert

werden. Diese Menge an Charakteristika ist unabh

angig vom Typ der

Verbindung.“29.

Als Beispiel f

ur die Verwendung von mixed objects wird der Digitale

Tisch genutzt, zu sehen in Abbildung

3.1181

”

Der Benutzer verwen-

det und bewegt den Radiergummi – das mixed tool. Diese Aktion,

basierend auf den physikalischen Eigenschaften des Objekts, wird

von der Eingabeverbindung (hier: eine Kamera und ein Computer-

Vision Algorithmus) erkannt, um dann die entsprechenden digitalen

Eigenschaften

location

und

recognized movements

zu aktua-

lisieren. Die

Anderungen in den digitalen Eigenschaften des mixed

tools werden danach von der interaction language zu einer elementaren

Aufgabe (elementary task) interpretiert: Die (x, y)-Position wird in die

elementare Aufgabe “L

osche Zeichnung an Position (x, y) auf dem

Tisch“

uberf

uhrt. Die elementare Aufgabe wird dann auf das Task

Objekt angewendet und die digitalen Eigenschaften der mixed drawing

werden infolgedessen modifiziert. Die mixed drawings zeigt ihre inter-

ne digitale Ver

anderung

uber die Aktualisierung der Anzeige ihrer

Ausgabeverbindung – dem Feedback f¨

ur den Benutzer“30.

Zusammenfassend kann

uber die Arbeit von C

eline Coutrix und Lau-

rence Nigay gesagt werden, dass sie mit diesem Artikel eine neue

29Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 16 ff. (eigene ¨

Ubersetzung)

30Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 20 f. (eigene ¨

Ubersetzung)

3.3 ENTWURFSKONZEPTE MIT WERKZEUGUMGEBUNG

Abbildung 3.11: Interaktion: Benutzer und mixed objects [DGN10].

Sichtweise auf die Entwicklung von Interaktionen in Mixed Reality

Systemen mit Hilfe der mixed objects erm

oglicht haben.

”

Sie haben die

inh

arenten als auch die extrinsischen Charakteristika der mixed objects

vorgestellt, bei dem das Objekt entweder als Werkzeug oder aber eine

Aufgabe gesehen werden kann. Indem

ahnliche existierende Systeme

mit Hilfe der vorgestellten Charakteristika klassifiziert werden konn-

ten, wurde damit ihre taxonomische M¨

achtigkeit demonstriert“31.

Als weitere hervorzuhebende Arbeit in diesem Buch ist der Artikel

”

Fiia: A Model-Based Approach to Engineering Collaborative Aug-

mented Reality“von Christopher Wolfe et al. zu nennen. Er beschreibt

die visuelle Notation Fiia zu Formulierung der Entwicklung von kol-

laborativen AR Anwendungen. Diese visuelle Notation basiert auf der

”

Actor & Adaptor“-Metapher, die ich f

ur meine Arbeit auch verwendet

habe.

31Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 29 (eigene ¨

Ubersetzung)

STAND DER FORSCHUNG

”

AR Anwendungen ben

otigen h

aufig eine Kollaboration von Personen

oder Personengruppen. Obwohl eine Reihe an Werkzeugen existieren,

die die Entwicklung solcher AR Systeme unterst

utzen (z. B. das AR-

ToolKit oder das Groupkit), bleibt jedoch eine große Kluft zwischen

der Spezifikation und der Implementierung dieser Systeme “

. Diese

Kluft versucht der Autor mit Hilfe von Fiia zu schließen.

”

Fiia.Net ist ein Werkzeug (basierend auf der visuellen Notation Fiia),

welches die Entwicklung von kollaborativen AR Applikationen verein-

fachen soll. Mit Hilfe der Fiia modeling language kann der Entwickler

die Struktur seiner Anwendung spezifizieren, um so die Details der

Vernetzung zu abstrahieren und die Spezifikation der Adapter zwi-

schen der physikalischen und realen Welt auf einer hohen Ebene zu

definieren. Das Fiia.Net Laufzeitsystem bildet dieses konzeptionelle

Modell auf eine Laufzeitumgebung ab“33.

”

Die Fiia Entwurfsnotation ist ein Architekturmuster oder besser eine

visuelle Notation, mit der kollaborative AR Applikationen software-

technisch entwickelt werden k

onnen. Viele andere Architekturmuster

haben das Ziel, die Schwierigkeiten bei der Programmierung entwe-

der der Groupware (also kollaborativen Anwendungen) oder der AR

Anwendungen zu minimieren. Es ist zur Zeit kein Architekturmuster

bekannt, das beide Gebiete unterst¨

utzt“34.

”

Architekturmuster legen Regeln fest, die es Entwicklern erm

ogli-

chen, die Groupware-Systeme in ihre Komponenten aufzuteilen, so

dass der

”

Teile-und-Hersche“ Ansatz (engl.: devide and conquer) der

Softwareentwicklung angewendet werden kann. Beispiele f

ur dieses

Vorgehen sind das Clover-Modell [

LN02

] und PAC* [

CCN97

], die dem

Entwickler Ratschl

age geben, wie die Benutzerschnittstelle bzw. die

Applikation unter Ber

ucksichtigung der Gruppenaufgaben Produktion,

Kommunikation und Koordination am geeignetsten aufgeteilt werden

kann. Beide Architekturen sind rein konzeptionell, was bedeutet, dass

sie sich nicht mit den Problemen befassen, wie die Vorschl

age auf

einem verteilten System implementiert werden sollen. Die Entwick-

ler stehen also der schwierigen Aufgabe gegen

uber, die Vorschl

age

in ausf

uhrbaren Code zu transformieren. Phillips liefert eine detail-

lierte Zusammenfassung der konzeptionellen Architekturmuster f

Groupware-Anwendungen [Phi99]“35.

”

Aus den Architekturmustern f

ur die Entwicklung von AR Anwen-

dungen ist ASUR [

DG08

] erw

ahnenswert.

Ahnlich wie bei Fiia erlaubt

32Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 293 (eigene ¨

Ubersetzung)

33Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 293 (eigene ¨

Ubersetzung)

34Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 298 (eigene ¨

Ubersetzung)

35Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 298 (eigene ¨

Ubersetzung)

3.3 ENTWURFSKONZEPTE MIT WERKZEUGUMGEBUNG

ASUR die Modellierung der Applikation mit Hilfe von Szenarios, die

aus Komponenten und Verbindungen zwischen diesen bestehen. “

ASUR wurde schon in diesem Kapitel auf Seite 75 vorgestellt.

”

Es existiert eine Vielzahl an Werkzeugen f

ur die Entwicklung von

Groupware, allerdings nur wenige f

ur die Entwicklung von AR Ap-

plikationen. Ein Werkzeug f

ur beide Arten ist den Verfassern des

Artikels nicht bekannt“37.

”

Die meisten Werkzeuge zur Entwicklung von Groupware (wie bei-

spielsweise Groupkit [

RG96

], ALV [

HBR+94

] oder Clock [

UG99

]) be-

dingen, dass alle Benutzer mit dem System in gleicher Weise intera-

gieren, so dass es nicht m

oglich ist, eine heterogene Rollenverteilung

der Benutzer und der Systeme zu realisieren. Als einziger Ansatz in

diesem Bereich unterst

utzt Networking shared dictionary [

MGRB06

] die

Verwendung von heterogenen Klienten“38.

”

Mehrere Groupware-Tooklits unterst

utzen dynamische Adaption, die

zur Transition zwischen Szenen genutzt werden kann. Schmalsteig

et al. liefert einen Ansatz zur Migration von Klienten in VR Anwen-

dungen [

SH02

]. Realisiert wird dies

uber eine geteilte Szenegraph

Datenstruktur mit Hilfe von Replikation. Der Code und der Szene-

graph k

onnen so mit Hilfe einer Device-Anpassung auf neue Klienten

migriert werden“39.

”

Die meisten Werkzeuge, die f

ur die Entwicklung von AR Anwendun-

gen gedacht sind, widmen sich speziell dem Problem der Ermittlung

der Kameraposition und Orientierung und der Ermittlung der Positi-

on von physikalischen Objekten.

[· · · ]

Augmented Reality Werkzeuge

sind typischerweise Bibliotheken, die in einer großen Auswahl von

Programmiersprachen eingebunden und benutzt werden k

onnen, z. B.

das ARToolKit [

KB99

] oder ARTag [

Fia05

]. Beide verwenden spezielle

Bildmuster (Pattern, Tags), die an die reale Umgebung angebracht

werden. Diese werden dann programmiertechnisch mit Objekten der

virtuellen Welt verkn

upft. Die Position und Orientierung der Kame-

ra kann dann

uber die Analyse der Tags im aufgezeichneten Bild

errechnet werden. GoblinXNA verfolgt einen

ahnlichen Ansatz mit

dem Unterschied, dass es in die XNA Entwicklungsumgebung von

Microsoft integriert ist [

OLWF07

]. Weitere Probleme, mit denen sich

Augmented Reality Werkzeuge befassen, sind beispielsweise Lokali-

sierung, Gestenerkennung und Grafik [

Fis02

[· · · ]

Fiia kann nun als

Generalisierung der vorgestellten Ans

atze gesehen werden, indem es

36Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 298 (eigene ¨

Ubersetzung)

37Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 298 (eigene ¨

Ubersetzung)

38Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 298 (eigene ¨

Ubersetzung)

39Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 299 (eigene ¨

Ubersetzung)

STAND DER FORSCHUNG

weit mehr Flexibilit

at liefert, zum einen auf der konzeptionellen und

verteilten Architektur-Ebene, zum anderen in der Bereitstellung der

notwendigen Infrastruktur f

ur die Realisierung von AR Anwendun-

gen“40.

”

Fiia ist eine Entwurfsnotation f

ur kollaborative AR Anwendungen.

Mit Hilfe des Werkzeugs Fiia.Net werden diese Entw

urfe zu ausf

uhrba-

ren Anwendungen realisiert. Fiia ist weiter ein modellbasierter Ansatz

der es erlaubt, ein abstraktes High-Level Modell eines Systems als

verteile Anwendung mit physikalischen und virtuellen Objekten auto-

matisch zu erzeugen. Verglichen mit fr

uheren Ans

atzen enth

alt Fiia

drei prinzipielle Fortschritte“41:

High-Level Notation:

Fiia verwendet eine High-Level Notation zur

Modellierung sowohl der Groupware als auch der Augmented

Reality einschließlich der Funktionalit

at von gemeinsamer Da-

tennutzung (Data Sharing) und der virtuellen/physikalischen

Adapter.

Szenario-basierter Entwurf:

Fiia nutzt einen Szenario-basierten Ent-

wurf und eine Szenario-basierte Implementation.

Einfacher Modell-Code ¨

Ubergang:

Fiia bietet einen einfachen

Uber-

gang vom abstrakten Modell zur ausf

uhrbaren Anwendung an.

Abbildung

3.1285

zeigt ein Beispiel eines Fiia Diagramms (hier die von

Wolfe entwickelte Anwendung mit Namen Raptor). Der Entwickler

(Designer) interagiert bei dieser Anwendung mit dem Editor, der es

erlaubt, die Szene zu manipulieren, das Terrain zu gestalten, Spielele-

mente einzuf

ugen und diesen dann Verhalten zuzuordnen. Elemente

werden in Form eines Szenegraphen gespeichert. Dieser Szenegraph

ist in der Komponente Scene gespeichert. Der Editor ist eine Actor-

Komponente ( ), was bedeutet, dass diese Komponente in der Lage

ist, Aktionen zu initiieren. Die Scene ist eine Store-Komponente ( ),

das heißt ein passiver Datenspeicher. [DGN10]

Der Entwickler benutzt den Editor mit Hilfe eines Multitouch-Tisches,

der in Abbildung

3.1285

durch das Table Surface dargestellt ist. Das

Table Surface bieten Eingabe- und Ausgabem

oglichkeiten f

ur den rea-

len Multitouch-Tisch (benutzt wird ein Microsoft Surface [

Mic11

]).

Interagiert wird mit dem Table Surface

uber einen bidirektionalen

Informationsfluss. Das wird im Diagramm durch die beiden Stream-

Verbindungen ( ) angedeutet (die Bidirektionalit

at wird durch

40Aus ”The Engineering of Mixed Reality Systems“ [DGN10], Seite 299 (eigene ¨

Ubersetzung)

41Aus ”The Engineering of Mixed Reality Systems.“ [DGN10], Seite 299 (eigene ¨

Ubersetzung)

3.3 ENTWURFSKONZEPTE MIT WERKZEUGUMGEBUNG

Scene

Editor

Table

Surface

Game PC

Tabletop PC

Scene

Displayer

Display

Designer Tester

Abbildung 3.12:Fiia Modell einer Anwendung [DGN10].

die Doppelpfeile an beiden Enden der Linie dargestellt). Der Editor

erfragt den aktuellen Status des Multitouch-Tisches mit Hilfe der

Call-Verbindung ( ) und aktualisiert die Anzeige des Tisches

uber

die Stream-Verbindung. Allgemein repr

asentieren Streams einen asyn-

chronen Datenfluss, der f¨

ur die Kommunikation diskreter Ereignisse

oder kontinuierlicher Daten, beispielsweise Audio oder Video, ver-

wendet werden kann. Im Gegensatz dazu steht die Call-Verbindung,

die den traditionellen synchronen Aufruf von Methoden repr

asen-

tiert. [DGN10]

Gleichzeitig, w

ahrend der Entwickler die Szene im Editor bearbei-

tet, k

onnen Testbenutzer (Tester) die Anwendung auf dem Display

anschauen. Der Displayer-Aktor aktualisiert die Darstellung entspre-

chend den

Anderungen des Entwicklers. Beide Versionen der Scene,

sowohl die der Entwickler als auch die von den Testbenutzern, werden

uber eine Sychronisationsverbindung ( ) konsistent gehalten. Eine

Synchronisationsverbindung sorgt daf

ur, dass zwei oder mehr Daten-

speicher konsistent bleiben, so dass

Anderungen automatisch an alle

Stores propagiert werden. [DGN10]

Die Diagramme von Fiia werden als verteiltes System implementiert.

In diesem Beispiel werden zwei Computer verwendet; Ein Computer,

der den Multitouch-Tisch ansteuert (Tabletop PC) und vom Entwickler

benutzt wird, und ein Computer, der die Darstellung der Szene f

STAND DER FORSCHUNG

die Testbenutzer aufbereitet (Game PC). Fiia Diagramme spezifizieren

jedoch nicht die Details des verteilten Systems. Sie abstrahieren die

wichtigen Aufgaben wie beispielsweise die Aufteilung der Komponen-

ten, den verwendeten Algorithmus zur Daten

ubertragung zwischen

Knoten und die Konsistenzverwaltung f

ur die Datensynchronisati-

on. Das Fiia.Net-Werkzeug kann bei der sp

ateren Umwandlung in

ausf

uhrbare Anwendungen diese abstrakten Aufgaben automatisch

bestimmen. Das erlaubt es dem Entwickler, sich auf die Funktiona-

lit

at seiner Anwendung zu konzentrieren und nicht die Details der

Implementation zu betrachten. [DGN10]

Fiia bietet

uber eigene Notation eine gute und einfache M

oglichkeit,

verteilte Mixed Reality Anwendungen konzeptionell zu realisieren

und mit Hilfe des mitgelieferten Fiia.Net-Werkzeuges in eine ausf

uhr-

bare Anwendung zu

uberf

uhren. Fiia bietet leider nicht die M

oglich-

keit, eine Anwendung entlang des Mixed Reality Kontinuums zu

entwickeln. So ist es schwierig, Komponenten, die als virtuelles Ob-

jekt definiert sind, in real existierende Komponenten zu

uberf

uhren.

Fiia bietet hier weder einen Automatismus noch ein Vorgehen an. So

usste f

ur jeden Prototypen das komplette Modell

uberarbeitet wer-

den, um eine entsprechende Entwicklung entlang des Mixed Reality

Kontinuums zu realisieren. Das ist allerdings nicht w

unschenswert.

Die Groupware-Eigenschaften und die automatische Generierung

ausf¨

uhrbarer Applikationen sind jedoch bei Fiia hervorzuheben.

Fiia: Model-Based Approach to Engineering Collaborative AR

Autoren Wolfe, Smith, Phillips, Graham Jahr 2010

Bereich Modell und Notation

Beschreibung Entwicklung von kollaborativen MR-Anwend.

Merkmale: + Notation, Modell, Werkzeuge

+ Anwendungsbeispiele

+ Grafische Notation

+ Automatische Generierung

+ Groupware-Eigenschaften

- Keine Entwicklung entlang d. MR Kontinuums

- Nicht iterativ

Weitere Entwurfskonzepte

Eine große Anzahl an weiteren Entwurfskonzepten wurde schon im

vorherigen Abschnitt ab Seite 78 erw

ahnt. Auch hier sei des Weiteren

3.4 SOFTWAREUMGEBUNGEN UND -L ¨

OSUNGEN

der j

ahrlich stattfindende SEARIS Workshop f

ur weitere, tiefergehende

Informationen zu diesem Themenfeld erw¨

ahnt [SEA08].

3.4 Softwareumgebungen und -l¨osungen

Die im letzten Kapitel vorgestellten Arbeiten stellen neben einem kon-

zeptionellen Entwurf gleichzeitig eine Software zur (automatischen)

Erzeugung von ausf

uhrbaren Programmen zur Verf

ugung. Die mit

Hilfe der verschiedenen, im letzten Kapitel vorgestellten Konzepte

entwickelten Anwendungen bieten somit nur eine sehr abstrakte Sicht.

Das bedeutet, dass die Entwickler eine Sicht auf ihre Anwendun-

gen nicht auf quelltextbasis erhalten, sondern auf Modellebene die

Anwendungen entwickeln.

Eine Grundvoraussetzung f

ur einen praktikablen Entwurfsprozess ist

die Bereitstellung von Werkzeugen, die eine rasche Entwicklung von

Mixed Reality Komponenten unterst

utzten. Hier existiert eine Vielzahl

von Arbeiten in diesem Bereich, angefangen von API

-basierenden

Low-Level Ans

atzen

uber Software-Frameworks bis hin zu komplexen

High-Level Autoren-Werkzeugen. Ich beschr

anke mich hier auf die

Arbeiten, die mein System beeinflusst haben.

Im folgenden Kapitel m

ochte ich gerne einige dieser Softwareumge-

bungen und -l

osungen kurz vorstellen, die es erlauben, eigene An-

wendungen auf eine etwas konkreteren Art zu entwickeln. Vorgestellt

werden verschiedene Softwareumgebungen, die es dem Entwickler

erm

oglichen, Virtual und Mixed Reality Anwendungen zu entwerfen.

Fr¨uhe API-basierte VR Frameworks

Ein sehr fr

uhes API-basiertes Framework, das ausschließlich f

ur VR

Anwendungen verwendet werden kann, ist VRJuggler [

BJH+01

]. Es ist

ein objektorientierts C++ VR-System, kann plattform

ubergreifend ver-

wendet werden und steht unter einer Open Source Lizenz. VRJuggler

erlaubt eine beliebige Kombinationen von Eingabeger

aten, Grafik-

APIs und Plattformkonfigurationen. Eine VR-API mit einem Fokus

auf Simulationen ist Delta3D [

DMJ05

]. Dieses Framework basiert auf

der h

aufig im wissenschaftlichen Bereich eingesetzten Szenengraph-

Bibliothek OpenSceneGraph [

Ope10

] und vereint eine erhebliche An-

zahl an Open Source Bibliotheken beispielsweise f

ur Charakteranima-

tion, Physik oder K

unstliche Intelligenz und bietet daher eine enorme

42API = Application Programming Interface – Eine Programmierschnittstelle auf Quelltextebene.

STAND DER FORSCHUNG

Funktionsvielfalt. Delta3D kann zusammen mit der Skriptsprache Py-

thon benutzt werden und liefert einen umfangreichen Szenen-Editor

namens STAGE.

Autorenbasiertes MR Framework AMIRE

Application

Authoring Framework

Component Layer

Gem Collection

Inter-object communication layer

Component Interfaces Gem interfaces

Component

In Slots

Out Slots

Internal

State

Abbildung 3.13: AMIRE Framework und Komponente [DGHP02].

Einer der ersten Versuche von den reinen APIs hin zu einer autoren-

basierten Entwicklung zu gelangen, war das AMIRE

Werkzeug, das

als Teil des europ

aischen IST Projektes entwickelt wurde [

GHP+02

AMIRE stellt ein Autorenframework zur Verf

ugung (siehe Abbildung

3.13

), auf den die Anwendungen basieren. Die Basis dieses Frame-

works sind die sogenannten Gems.Gems sind eine Sammlung von

Techniken und Algorithmen, die f

ur Programmierer gedacht sind.

Die Grundgedanke bei diesen Gems ist, dass Entwickler ihre Ideen,

Algorithmen und Werkzeuge mit anderen Entwicklern (und den Ent-

wicklern von AMIRE) teilen und so die Ressourcen wiederverwendet

werden k

onnen. Durch eine große Beteiligung von vielen Programmie-

rern entwickelt sich so eine große Basis an innovativen L

osungen f

eine Vielzahl von Problemen im Mixed Reality Bereich. Ein Problem

bei der Bereitstellung der Gems ist allerdings, dass viele Ideen und

Algorithmen nicht f

ur die Wiederverwendung programmiert wurden

bzw. die Schnittstellen sehr unterschiedlich sind. Auch ist es schwierig,

allgemeine Prozesse f

ur Mixed Reality Anwendungen von L

osungen

Dritter zu finden und wieder zu verwenden. Die L

osung, die AMIRE

vorschl

agt, ist, etablierte L

osungen f

ur einzelne Aufgaben in einer MR

Gem Collection zu sammeln [GHP+02].

Die Mixed Reality Komponenten (oder einfach Komponenten) sind die

grundlegenden Elemente im Entwicklungsprozess.Dabei repr

asentie-

ren Komponenten konkrete L

osungen f

ur dom

anenspezifische Proble-

43AMIRE steht f¨

ur ”Authoring MIxed REality“.

3.4 SOFTWAREUMGEBUNGEN UND -L ¨

OSUNGEN

me und kombinieren bzw. erweitern typischerweise die Gems in Rich-

tung High-Level Funktionalit

at von MR Anwendungen. Komponenten

sind als dom

anenspezifische Elemente definiert. Abstrakt betrachtet

teilen sich Komponenten in geometrische Modelle und Verhalten auf,

wobei Verhalten sowohl die Animation als auch die Simulation ei-

nes spezifischen Verhaltens beinhalten kann. Einige w

unschenswerte

Auspr

agungen der Komponenten sind folgende: strukturiert, wieder-

verwendbar in unterschiedlichen Versionen, wiederverwendbar in

unterschiedlichen Anwendungen, erweiterbar, flexibel [GHP+02].

Authoring

Expert

Component

Expert

Gems

Expert

Evaluation

Expert

Framework

MR Gem

MR Component

Legende

Framework

Expert

Application

Abbildung 3.14: Experten bei einer AMIRE-Entwicklung [DGHP02].

Das MR Framework von AMIRE dient schließlich als Bindeglied zwi-

schen den Gems und den Komponenten. Weiterhin bietet es eine High-

Level API und eine Schnittstelle f

ur die Komponenten an. Das MR

Framework beinhaltet sowohl ein Laufzeit-Framework als auch ein

Autoren-Framework. Dies stellt bei der Anwendungsentwicklung

sicher, dass die dom

anenspezifischen Experten an den daf

ur vorge-

sehen Baustellen arbeiten k

onnen, wie in Abbildung

3.14

zu sehen

ist [

GHP+02

]. Bei einer Entwicklung einer Anwendung sind f

unf

dom

anenspezifische Experten beteiligt: Der Gem Expert entwickelt

neue ben

otigten Gems bzw. findet schon existierende aus der Gem Col-

lection. Der Component Expert entwickelt die Komponenten mit Hilfe

der vorhandenen Gems. Der Framework Expert integriert die Kompo-

nenten schließlich in das Framework, so dass der Authoring Expert

sie in der Anwendung verwenden kann. Eine

uberpr

ufende Rolle hat

der Evaluation Expert, der das komplette Projekt evaluiert und ggf. bei

den entsprechenden Experten Korrekturen vorschl

agt. Jeder dieser

STAND DER FORSCHUNG

Experten muss somit nur Teilaufgaben

ubernehmen, und zwar genau

in dem Gebiet, in dem seine Kompetenzen liegen.

Konzeptionell leistet AMIRE gute Arbeit im Bereich Mixed Reality

Anwendungsentwicklung. Ein Problem ist jedoch, dass normalerweise

osungen sehr schwer auf die Gems-Ebene reduziert werden k

onnen,

da sie meist in einem komplexeren Zusammenhang entwickelt wur-

den. Des Weiteren ist es schwierig, eine einheitliche, gut verst

andliche

Schnittstelle f

ur alle zur Verf

ugung gestellten Gems zu entwerfen, so

dass bei der Entwicklung einer Applikation meist viel Arbeit in die

eigentlichen Bausteine, den Gems und den Components fließt und so

die eigentliche Entwicklung verkompliziert. F

ur diese Arbeit fehlte

auch das Entwurfsvorgehen, das bei AMIRE nicht konkret entwickelt

wurde.

Autorenbasiertes MR Framework AMIRE

Autoren Europ¨

aisches IST Projekt Jahr 2002

Bereich Framework

Beschreibung Mixed Reality Framework

Merkmale: + Iterativ

+ Komponentenbasiert

+ Anwendungsbeispiele

- Kein konkretes Entwurfsvorgehen

- Keine Entwicklung entlang d. MR Kontinuums

The Designer’s AR Toolkit: DART

Im Mixed Reality Bereich ist DART

eines der ersten erfolgreichen

Autoren Werkzeuge, die Mixed Reality Erweiterung in die Anwen-

dung Director, einer kommerziellen Autorenl

osung von Adobe, inte-

griert [

MGDB04

]. MacIntyre stellte DART im Jahre 2004 vor. Da es sich

um eine Erweiterung einer propriet

aren Software handelt, musste sich

MacIntyre an das von Director vorgegebene konzeptionelle Modell

halten, das aus der Theater-Metapher basiert. In Director existieren

Akteure, die sichtbare und interaktive Objekte repr

asentieren, eine

uhne (stage), auf dem die Akteure platziert werden, und Kameras,

die die Akteure auf der B

uhne darstellen. DART erweiterte diese Meta-

pher konsequent indem es spezielle Akteure, sogenannte DART-Aktors

und Kameras lieferte, die f

ur Mixed Reality Anwendungen ben

otigt

wurden. In Abbildung

3.1591

ist die Integration von DART in Director

44Abk. f¨

ur ”The Designer’s AR Toolkit“, das Augmented Reality Werkzeug f¨

ur Designer.

3.4 SOFTWAREUMGEBUNGEN UND -L ¨

OSUNGEN

zu sehen.

Abbildung 3.15:DART von MacIntyre [MGDB04].

”

DART will besonders die fr

uhen Entwurfsaktivit

aten unterst

utzten,

speziell die schnelle Umsetzung von Storyboards zu Prototypen, so

dass der experimentelle Teil des Entwurfs sehr fr

uh und sehr oft

getestet werden kann. DART erlaubt es dem Entwickler komplexe

Beziehungen zwischen der physikalischen und der virtuellen Welt

zu spezifizieren und unterst

utzt 3D Animatic

-Akteure (informeller,

skizzenbasierter Inhalt) zus

atzlich zu den besser aufbereiteten Inhal-

ten. Die Entwickler k

onnen Video und Sensordaten synchronisiert

aufzeichnen und abspielen, was es erlaubt, unabh

angig von der echten

Kamera zu arbeiten und spezifische Teile der Anwendung effizient zu

testen“46.

DART ging denselben Weg, den ich am Anfang meiner Arbeit ge-

gangen bin, indem ein propriet

ares Werkzeug, das schon eine große

Verbreitung bei Anwendern hatte, mit Komponenten aus dem Bereich

Mixed Reality erweitert wurde. Dadurch musste nur ein kleiner Teil

der Software entwickelt werden und man konnte auf schon bestehen-

de und gut funktionierende Strukturen zur

uck greifen. Diese festen

Strukturen k

onnen sich allerdings auch zum Nachteil entwickeln,

45Eine Animatic, auch Story Reel genannt, ist ein gefilmtes Storyboard.[Wik11]

Aus

”

DART: a toolkit for rapid design exploration of augmented reality experiences“ [

MGDB04

Seite 197 (eigene ¨

Ubersetzung)

STAND DER FORSCHUNG

gerade in meinem Fall, wie man in Kapitel

4.5.1136

nachlesen kann.

DART hatte das Problem, dass sich viele Entwickler von Director

abgewendet haben und stattdessen auf Flash umgestiegen sind, so

dass die Entwicklung von DART eingestellt wurde.

DART: toolkit for rapid design exploration of AR experiences

Autoren MacIntyre, Gandy, Dow, Bolter Jahr 2004

Bereich Framework

Beschreibung Mixed Reality Framework in Director

Merkmale: + Theatermetapher

+ Professionelle Entwicklungsumgebung

+ Anwendungsbeispiele

- Kein konkretes Entwurfsvorgehen

- Keine Entwicklung entlang d. MR Kontinuums

- Nicht iterativ

Studierstube

Ein weiteres bekanntes System im Bereich Mixed Reality ist das Stu-

dierstube System [SFH+02] von Dieter Schmalstieg, entwickelt an der

Technischen Universit

at Wien und weiterentwickelt an der Techni-

schen Universit

at Graz. Studierstube basiert auf der Szenegraph-API

Coin3D, einem Open Inventor Clone der norwegischen Firma Kongs-

berg Oil & Gas Technologies [

Tec11

], und einer Middleware f

ur die

I/O-Abstraktion namens OpenTracker [

RS01

], welche einen flexiblen

Einsatz von Tracking-Ger

aten erlaubt. Studierstube erlaubt eine einfa-

che Entwicklung von Mehrbenutzer AR-Anwendungen, sowohl auf

klassischen Computern als auch auf mobilen Endger

aten mit der spe-

ziellen allerdings kommerziellen Version Studierstube ES. Die Verwen-

dung von mobilen Endger

aten wird auch im Bereich Mixed Reality

immer interessanter, da es die heutige Leistung erlaubt, die komplette

Verarbeitung lokal auf dem mobilen Ger

at auszuf

uhren. Noch vor

einigen Jahren was das nicht m

oglich, und mobile AR Anwendungen

mussten mit Hilfe von Bild

ubertragung und Bildberechnung auf dem

PC gel

ost werden, wie das Beispiel der AR-Enigma aus dem Jahre

2002 [

PSG+02

] oder die testbare Design-Repr

asentation f

ur mobiles

AR Authoring [GPR+02] zeigt.

Studierstube ES l

auft auf mehreren (mobilen) Plattformen (z. B. Win-

dows, Windows CE, Symbian, Andriod und iOS

). Alle relevanten

47iOS Ger¨

ate sind nicht offiziell unterst¨

utzt, es existiert jedoch eine Entwicklerversion.

3.4 SOFTWAREUMGEBUNGEN UND -L ¨

OSUNGEN

Studierstube ES

Applikation

Studierstube ES

Applikation

Studierstube ES

Applikation

Applications

Studierstube ES

Muddleware

Studierstube

Scenegraph

Studierstube IO Studierstube Tracker

Studierstube Core Studierstube Math

Studierstube Software Stack

Operating System

Windows, WIndows Mobile,

Symbian, MacOS, Linux

APIs

DirectShow, Symbian Camera, OpenMAX, Direct3D,

OpenGL ES, OpenGL, Winsock, etc.

Hardware

CPU, GPU, FPU, Display, Touchscreen, Buttons, Audio, Camera, Wifi, Bluetooth

Plattform

Abbildung 3.16: Aufbau von Studierstube ES [SW07].

Details der Entwicklung von AR Anwendungen werden von Studier-

stube ES ber

ucksichtigt: Grafikausgabe, Videoverarbeitung, Tracking,

Multimedia, Speicherverwaltung und Synchronisation von Mehrbe-

nutzer Mehrbenutzern (siehe Abbildung

3.1693

). Studierstube ES bietet

eine große Zahl von Schnittstellen (Muddleware

,Studierstube Scene-

graph,Studierstube Tracker, etc. und, da es von Grund auf f

ur mobile

Endger

ate programmiert wurde und nicht auf existierenden L

osun-

gen basiert, eine sehr hohe Performance. Damit ist die Entwicklung

von komplexen AR Anwendungen auf mobilen Endger

aten f

ur den

kommerziellen Markt bzw. im akademischen Rahmen sehr schnell

realisierbar. Da Studierstube ES speziell auf mobile Endger

ate opti-

miert wurde, werden 3D Beschleunigung der eingesetzten Grafikpro-

zessoren, Fließkommazahl- und Fixpunktzahlarithmetik sowie die

Verwendung der verbauten Kameramodule unterst

utzt, soweit diese

auf der mobilen Plattform vorhanden sind. Das erm

oglicht mobile AR

Anwendungen, die vor wenigen Jahren nur auf Desktop-PC m¨

oglich

waren. Durch die Integration vom Studierstube ES in die Softwareum-

Muddleware ist eine Netzwerkl

osung f

ur mobile Endger

ate und stammt von denselben Entwicklern

wie Studierstube ES.

STAND DER FORSCHUNG

gebung der einzelnen mobilen Plattformen ist die Einbindung in

eigene Projekte sehr einfach. Da es sich, wie bereits erw

ahnt, um eine

kommerzielle L

osung handelt, ist die Benutzung von Studierstube ES

leider nur Entwicklern vorenthalten, die eine Lizenz besitzen.

Studierstube

Autoren Schmalstieg et al. Jahr 2002

Bereich Framework

Beschreibung Mixed Reality Framework

Merkmale: + Komplexes Framework

+ Mobile Plattformen

+ Anwendungsbeispiele

- Kein konkretes Entwurfsvorgehen

- Entwicklung nicht entlang d. MR Kontinuums

- Nicht iterativ

Weitere High-Level Werkzeuge der letzten Jahre

Broll beschreibt in seiner Arbeit, die 2008 auf der 3DUI-Konferenz

vorstellt wurde, ein visuelles Autorenwerkzeug f

ur 3D Interaktions-

techniken [

BHB08

]. Das Konzept

”

Interactive Bits“ ist ein komponen-

tenbasierter Ansatz zur visuellen Spezifikation von Mixed Reality

Interaktionstechniken, Objektverhalten oder vollst

andiger Mixed Rea-

lity Prototypen. Das Werkzeug kombiniert synchronen Kontroll- und

Datenfluss mit asynchronen Events und Netzwerkkommunitation.

Spezifiziert wird es

uber eine XML-basierte Beschreibung, die die Ob-

jekte, die Komponenten und den Kontroll- bzw. Datenfluss definiert.

Sandor et al. beschreiben in ihrer Arbeit

”

Immersive mixed-reality

configuration of hybrid user interfaces“ [

SOBF05

] ein Mixed Reality

System, welches Anwendern erlaubt, eine Mixed Reality Applika-

tion zur Laufzeit zu konfigurieren und eine Vielzahl von Anzeige-

und Interaktionsger

aten beliebig zu kombinieren. Dabei wird eine

Datenfluss-orientierte Visualisierung durch verbindende Linien zwi-

schen grafischen 2D-Symbolen verwendet. Diese Methode habe ich

auch in meinem ersten Ansatz verwendet, indem ein propriet

ares 3D

Autorensystem als Grundlage f

ur die Entwicklung von Mixed Reality

Applikationen verwendet wurde. Ein Unterschied allerdings ist, dass

die Software, die ich verwendet habe, eine Kontrollfluss-orientierte vi-

suelle Programmierung verwendete. N

aheres kann in Kapitel

4.5.1136

nachgelesen werden.

3.5 ZUSAMMENFASSUNG

Envir3D ist ein Modellierungswerkzeug, mit dem 3D Inhalte visu-

ell spezifiziert werden. Dabei steht immer ein abstraktes Modell der

Benutzungsschnittstelle zur Evaluierung und Verfeinerungen zur Ver-

ugung. Dieses wird zur Erzeugung einer VRML-Darstellung verwen-

det [VCBT04].

Ein Beispiel f

ur ein High-Level Authoring-Werkzeug, das allerdings

nicht f

ur Mixed Reality Anwendungen gedacht war, ist 3DVIA Vir-

tools [

Das09

]. In Kapitel

4.5.1136

wird 3DVIA Virtools und die von mir

entwickelte Mixed Reality Erweiterung n¨

aher vorgestellt.

Es existieren auch in diesem Bereich noch viele andere gute Werkzeu-

ge. Eine gute Quelle ist hier wieder der j

ahrlich stattfindende SEARIS

Workshop, der eine vertiefende Quelle f

ur diese Entwicklungen bie-

tet. [

SEA08

] Die f

ur meine Arbeit wichtigsten Arbeiten habe ich jedoch

vorgestellt.

3.5 Zusammenfassung

In diesem Kapitel wurden aktuelle Forschungsergebnisse in den f

diese Arbeit relevanten Bereichen

”

Mixed Reality Entwurfskonzepte“,

”

Entwurfskonzepte mit Werkzeugumgebung“ und

”

Softwareumge-

bungen und -l

osungen“ vorgestellt und bewertet. Es wurden die f

diese Arbeit wichtigsten Beitr

age in den jeweiligen Gebieten kurz

beschrieben, die Merkmale herausgestellt und deren Vor- und Nach-

teile angef

uhrt. Bei den fr

uheren Arbeiten galt das Hauptaugenmerk

vorwiegend einer einzelnen Auspr

agung, wie beispielsweise der Vor-

stellung eines neuen Frameworks oder einer neuen Methode der

Modellierung, w

ahrend bei sp

ateren Arbeiten die Zusammenf

uhrung

mehrerer Auspr

agungen im Vordergrund stand. Waren es zu Be-

ginn nur einfache API-basierte Frameworks, die es dem Benutzer

erm

oglichten, Mixed Reality Anwendungen zu realisieren, so entwi-

ckelten sich sp

ater daraus komplette Werkzeuge, die es erm

oglichten,

auf abstrakte Weise seine Anwendung zu entwerfen. Zusammenfas-

send kann man sagen, dass alle Arbeiten in ihrem speziellen Gebiet

ihre Vorteile haben.

Was allerdings noch nicht in der Literatur versucht wurde, ist, eine

Anwendung entlang des Mixed Reality Kontinuums zu entwickeln. So

muss man bei allen Arbeiten die realen und virtuellen Objekte schon

zu Beginn der Entwicklung festlegen, eine sp

atere Transformation

ist nicht vorgesehen. Dabei ist es gerade bei der Entwicklung von

Mixed Reality Applikationen sinnvoll, reale Komponenten zu Beginn

virtuell zu modellieren, sei es, weil die realen Objekte noch nicht

STAND DER FORSCHUNG

existieren oder weil die technischen Grundlagen zur Erkennung der

realen Objekte noch nicht existiert. Allein bei DART [

MGDB04

] ist es

oglich, die Entwicklung auf zuvor aufgezeichneten Daten (sowohl

Video als auch Position und Orientierung) fortzusetzen. So kann

auch bei Abwesenheit der ben

otigten Hardware zur Erkennung von

realen Objekten bzw. der realen Objekte selbst (sei es, weil die Objekte

noch nicht existieren oder sich an einem anderen Ort befinden) die

Entwicklung fortgesetzt werden. DART jedoch beschr

ankt sich nur

auf Video bzw. Tracking-Informationen, eine Transition von virtuellen

zu realen Objekten findet hier nicht statt. In meinem Ansatz ist die

Transition von virtuellen zu realen Objekten (und zur

uck) m

oglich,

um so eine w

ahrend der Entwicklung gr

oßtm

ogliche Unterst

utzung

zu erhalten.

Viele der sp

ateren hier vorgestellten Arbeiten stellen eine eigene Vor-

gehensweise bzw. ein eigenes Modell vor. Das ist durchaus sinnvoll,

da die Entwicklung von Mixed Reality Anwendungen mit

ublichen

Entwicklungswerkzeugen und -Abl

aufen nicht vollst

andig abgedeckt

wird. Eine Unterscheidung zwischen den realen, physikalischen Ob-

jekten und den virtuellen Objekten wird bei allen Arbeiten im Bereich

Mixed Reality gemacht, sei es Fiia,ASUR oder Studierstube. Mein

Ansatz geht indes noch einen Schritt weiter und kategorisiert die vor-

handenen Objekte einer Anwendung in vier spezielle Arten, die dem

MVC-Ansatz (siehe Seite

2.2.145

) angelehnt ist. Diese Aufteilung er-

laubt eine feingranularere Entwicklung einzelner Komponenten. Des

Weiteren wird damit auch die Entwicklung entlang des Mixed Reality

Kontinuums unterst

utzt, was bedeutet, dass Objekte bzw. Komponen-

ten zuerst virtuell entworfen und sp

ater durch reale, physikalische

Komponenten bzw. Objekte ersetzt werden. Dieser Schritt l

asst sich

auch umkehren, so dass reale Objekte wieder durch ihre virtuellen

Gegenst

ucke ersetzt werden k

onnen. Das erm

oglicht bei der Entwick-

lung eine gezielte Fokussierung auf eine spezielle Auspr

agung einer

Anwendung, indem nicht ben

otige Funktionalit

at auf ein Minimum

reduziert wird.

Im Allgemeinen ist in der Literatur zu erkennen, dass die Bedeu-

tung von speziellen Vorgehensweisen und Modelle f

ur Mixed Reality

Anwendungen mit steigender Leistungsf

ahigkeit, sowohl der klas-

sischen PCs als auch der mobilen Endger

ate, zunimmt. Da sich die

Entwicklung von Mixed Reality Anwendung von der Entwicklung

klassischer Anwendungen stark unterschiedet und sich noch keine

allgemein g

ultige Vorgehensweise kristallisiert hat, ist ein erh

ohter

Forschungsbedarf in diesem Gebiet vorhanden. Das sieht man auch

speziell an den vielen, eigenst

andigen Konferenzen und Workshops

im Bereich Mixed Reality.

KAPITEL 4

Mixed Reality in the Loop

Das folgende Kapitel beschreibt das eigentliche

”

Mixed Reality in

the Loop“-Entwurfsvorgehen (MRiL). Den Anfang macht die Anfor-

derungsanalyse, in der die Anforderungen an die zu entwickelnde

Applikation beschrieben und erl

autert werden. Nachdem die Anfor-

derungen klar definiert sind, wird die Vorgehensweise des MRiL be-

schrieben. Da MRiL neue bzw. angepasste Methoden ben

otigt, werden

im Kapitel

4.3103

diese vorgestellt. Beginnend mit dem MVCE-Modell

wird die Grundstruktur des Entwurfsvorgehens erkl

art. Darauf auf-

bauend wird das Akteurmodell beschrieben, welches ben

otigt wird

um die Entwicklung zu strukturiert. In Kapitel

4.3.4124

wird das das ei-

gentliche Entwurfsvorgehen beschrieben, welches auf einem iterativen

Vorgehen basiert.

Um das Vorgehen besser verst

andlich zu machen, wird in Kapitel

4.4128

ein kleines Beispiel, eine Entwicklung nach MRiL, beschrieben.

Dieses Beispiel ist klein gehalten uns soll nur die Besonderheiten von

MRiL aufzeigen.

Damit MRiL sinnvoll angewendet werden kann, wird eine Software-

und Werkzeugumgebung ben

otigt, die diesen Prozess unterst

utzt. Es

wurden insgesamt zwei exemplarische Softwareumgebungen im Rah-

men dieser Arbeit entwickelt. Bei der ersten Umgebung lag der Fokus

auf der einfachen und visuellen Erstellung von Prototypen und basiert

auf einer propriet

aren Softwarel

osung. Sie unterst

utzt den Prozess

aber nicht vollst

andig, gerade im Bezug auf die Akteure gab es dort

Defizite. Die zweite Umgebung basiert auf einer Open Source Grafik-

bibliothek und versucht alle Aspekte der MRiL Vorgehens abzubilden.

Dabei wurde auf die einfache visuelle Programmierung verzichtet

und auf textuelle imperative Programmierung zur

uckgegriffen. F

MIXED REALITY IN THE LOOP

Experten, die einer Programmiersprache m

achtig sind, ist die letzte

Umgebung zu bevorzugen. Anwendern, die aus z. B. dem Bereich

Design stammen, wird die erste Softwarel¨

osung mehr zusagen.

Eine Reihe an eigenen Ver

offentlichungen zum Thema MRiL, u.a.

”

Mixed reality in the loop – design process for interactive mecha-

tronical systems“ [

SGP10

”

MVCE – A Design Pattern to Guide the

Development of Next Generation User Interfaces“ [

SGP+09

”

Mi-

xed Reality Design of Control Strategies“ [

GSBP09

”

Modellbasier-

ter Entwurf von Mixed Reality-Interaktionstechniken f

ur ein Indoor-

Zeppelin“ [

GPS+09

”

A Design Method for Next Generation User

Interfaces inspired by the Mixed Reality Continuum“ [

SGPP09

”

Mi-

ReAS: a mixed reality software framework for iterative prototyping

of control strategies for an indoor airship“ [

SPGP10

] und

”

Iterati-

ves Mixed-Reality-Prototyping und virtuelle Studiopr

asentation einer

Steuerung f

ur ein Indoor-Lufschiff“ [

PSHG10

], wurde auf verschie-

denen nationalen und internationalen Konferenzen vorgestellt und

uberwiegend positiv bewertet.

4.1 Anforderungsanalyse

Um das

”

Mixed Reality in the Loop“-Entwurfsvorgehen erfolgreich

einsetzten zu k

onnen werden bestimmte Voraussetzungen an die zu

entwickelnde Applikation gestellt. Da der zugrundeliegene Ansatz

des Entwurfs auf einem prototypenbasierten Vorgehen (siehe Kapitel

2.1.1239

basiert, sollten w

ahrend der Entwicklung der Software meh-

rere verschiedene Prototypen vorgesehen sein. Sollte die Entwicklung

keine Prototypen erfordern, w

are MRiL nicht das richtige Entwurfs-

vorgehen. Die Entwicklung der Prototypen ist noch mit der Bedingung

der schrittweisen Verfeinerung verkn

upft. Nicht jeder Prototyp sollte

eine komplett andere Funktionalit

at bieten, sondern die Prototypen

sollten auf einander aufbauen und nach und nach mehr Funktiona-

lit

at erhalten. Sollte die Entwicklung der Applikation fordern, dass

mehrere Prototypen mit komplett unterschiedlicher Funktionalit

entwickelt werden, ist die Entwicklung mit MRiL nicht optimal aber

durchaus m¨

oglich.

Selbst wenn eine Entwicklung einer Applikation die Herstellung von

Prototypen beinhaltet, muss MRiL noch nicht der passende Ansatz

sein. Es sollte mindestens eines der folgenden vier Kriterien f

ur die

Prototypenentwicklung zutreffen, um MRiL erfolgreich anwenden zu

k¨

onnen:

Darstellung:

Damit ist sowohl die Verfeinerung der rein virtuellen

4.1 ANFORDERUNGSANALYSE

Visualisierung als auch die

Anderung der Darstellung von rein

virtuell

uber gemischte Realit

at hin zur reinen Realit

at gemeint.

Steuerung:

Die Steuerstrategien der zu entwickelnden Prototypen

wird verfeinert. Dabei sollte die Entwicklung von einfachen,

Tastatur- oder Maus-basierten Steuerungen hin zu komplexen,

neuartigen Steuerstrategien verfeinert werden.

Modell:

Das Modell der Software wird verfeinert. Es ist m

oglich,

von einem rein virtuellen Modell zu einem realen Modell zu

migrieren.

Umgebung:

Die Umgebung hat Einfuss auf die Applikation. Auch

hier, wie bei der Darstellung, kann mit einer rein virtuellen

Umgebung begonnen werden, die dann nach und nach realer

wird. Die Umgebung wird nie zu 100% erfasst, sondern Teile der

Umgebung werden

uber Sensoren erkannt und der Applikation

zur Verf¨

ugung gestellt.

Der Ansatz ist nicht f

ur jede Art von Applikation sinnvoll. Es sollte

mindestens einer der im Folgenden aufgef

uhrten Punkte zutreffen,

damit die Verwendung von MRiL erfolgreich angewendet werden

kann:

Mixed Reality Applikation:

Bei der Entwicklung von Mixed Reality

Applikationen, im speziellen Augmented Reality Applikationen,

kann das MRiL-Entwurfsvorgehen erfolgreich eingesetzt wer-

den. Mixed Reality Applikationen zeichnen sich durch die Ein-

beziehung der realen Umgebung in die Software aus. Teile der

realen Umgebung k

onnen dabei durch verschiedene Sensoren er-

kannt und der Software zur Verf

ugung gestellt werden. Beispiele

hierf

ur sind Ultraschall Entfernungssensoren oder Videotracker

(z. B. Studierstube, ART+) zur Erkennung von Position und Ori-

entierung.

Mixed Reality Benutzerschnittstellen:

Eine gesonderte Klasse von

Applikationen sind Mixed Reality Benutzerschnittstellen (MR

User Interfaces, auch Next Generation User Interfaces (NGUI) ge-

nannt), die neue Benutzerschnittstellen f

ur Mixed Reality Appli-

kationen implementieren. Durch die Verwendung des MRiL-Ent-

wurfsvorgehens k

onnen die neuartigen Benutzerschnittstellen

in fr

uhen Phasen auch ohne die spezielle Hardware, die norma-

lerweise ben¨

otigt wird, getestet werden.

Mechatronische Systeme:

Software f

ur die Steuerung von mechatro-

nischen Systemen ist sehr gut mit dem MRiL-Entwurfsvorgehen

MIXED REALITY IN THE LOOP

zu realisieren. Dabei wird mehr die Entwicklung der Software

als die Einbettung in Hardwarecontroller (Entwicklung des ein-

gebetteten Systems) in den Vordergrund gestellt. Es ist aber auch

oglich, die Software sp

ater auf speziellen f

ur die Anwendung

Controllern auszuf

uhren, dabei wird hier auf das Prinzip von

MiL, SiL und HiL (Siehe Kapitel 2.3.151) zur¨

uckgegriffen.

ur bestimmte Klassen von Applikationen ist die Verwendung von

des MRiL-Entwurfsvorgehens nicht sinnvoll, da die klassischen Ent-

wurfsprozesse dort besser geeignet sind:

Klassische Applikationen:

Damit ist die Klasse von Anwendungen

gemeint, die als Standardsoftware bezeichnet werden kann. Da-

zu z

ahlen Officeanwendungen, Datenbanken, etc. Diese Pro-

gramme basieren gr

oßtenteils auf den Eingabem

oglichkeiten,

die von einem Betriebssystem zur Verf

ugung gestellt werden,

und verwenden die normale fensterbasierte Ausgabe.

WIMP1:

Anwendungen, die auf einer grafischen Benutzeroberfl

ache

basieren, die mit Hilfe einer Maus bedient werden k

onnen sind

ur die Entwicklung mit MRiL nicht geeignet. Beispiele f

ur solche

Anwendungen sind dialogbasierte Programme, die

uber die

Maus und die Tastatur gesteuert werden.

Webbasierte Inhalte2:

Webanwendungen sollten vorzugsweise mit

klassischen Ans

atzen der Softwareentwicklung realisiert werden,

da die MRiL hier keine Vorteile sondern eher Nachteile bringen

w¨

urde.

Eingebettete Systeme:

Diese Art von Software ben

otigt meist spezi-

elle Werkzeuge, die das Programm auf die passende Plattform

kompilieren. Daher ist hier auch einer der klassischen Ans

atze

f¨

ur die Entwicklung sinnvoll.

Damit sind die Anwendungen, die mit Hilfe des MRiL-Entwurfs-

vorgehen entwickelt werden k

onnen, klar eingegrenzt. Vorgestellt

wurden sowohl Anwendungen, die von MRiL unterst

utzt werden, also

auch Software, die nicht unterst

utzt wird und sinnvollerweise einem

anderen Entwurfvorgehen folgen sollte. Die nachfolgende Tabelle

zeigt nochmals im

Uberblick, welche Applikationen mit Hilfe von

MRiL entwickelt werden k¨

onnen:

1WIMP steht f¨

ur Windows Icons Menus Pointer.

Als webbasierte Anwendungen, auch Webanwendung oder Webapplikation genannt, wird Software

bezeichnet, die auf einem Webserver ausgef

uhrt wird und beim Anwender mit Hilfe eines Webbrowsers

angezeigt wird.

100

4.2 VORGEHENSWEISE

Geeignet f¨

ur MRiL

Applikation Ja Teilweise Nein

Mixed Reality Applikation

MR Benutzerschnittstellen ×

Mechatronische Systeme × ×

Eingebettete Systeme × ×

Webbasierte Inhalte ×

Klassische Applikationen ×

Zusammenfassend zeigt die unten angegebene Tabelle die Kriterien,

nach denen das MRiL-Entwurfsvorgehen f

ur eine Anwendungsent-

wicklung verwendet werden kann:

Relevanz

Kriterien Wichtig Optional Unwichtig

AR / MR ×

Prototyping ×

Komponentenbasiert ×

Akteurbasiert ×

Plattformabh¨

angig ×

Programmiersprache ×

Damit sind die Anforderungen an eine Applikation bestimmt. Im

folgenden Kapitel wird die Vorgehensweise des MRiL-Entwurfsvor-

gehen beschrieben.

4.2 Vorgehensweise

Das in dieser Arbeit entwickelte MRiL Entwurfsvorgehen basiert auf

mehreren, speziell angepassten Vorgehensmodellen und dem Model-

View-Controller Architekturmuster (Siehe Kapitel

2.2.145

), welches

ur MRiL eine Erweiterung erfahren hat. Um eine Applikation nach

dem MRiL-Entwurfsvorgehen zu entwickeln, muss folgendermaßen

vorgegangen werden:

1. Beschreibung in schriftlicher Form (Optional)

Um die sp

atere Applikation in die vier Komponenten unterteilen

zu k

onnen ist es sinnvoll die Funktionsweise der Anwendung

schriftlich aufzuzeichnen. In dieser Form k

onnen dann die Iden-

tifizierungen des n

achsten Schritts leichter realisiert werden.

101

MIXED REALITY IN THE LOOP

Diese schriftliche Zusammenfassung der Anwendung sollte so

genau wie m

oglich sein, es sind jedoch normalerweise zu Beginn

einer Entwicklung noch nicht komplett alle Aspekte bekannt,

so dass die erste Fassung der Beschreibung eher ungenau und

oberfl

achlich sein wird. Zu Beginn reicht diese Beschreibung

allerdings aus, um mit der Identifizierung beginnen zu k

onnen.

2. Identifizierung einzelner Elemente

Die einzelnen Elemente der Applikation sollten zu Beginn der

Entwicklung identifiziert werden. Da es sich beim MRiL-Ent-

wurfsvorgehen um einen iterativen Prozess handelt, kann diese

Identifizierung erst recht grob und ungenau sein. In sp

ateren

Iterationen k

onnen die Elemente weiter verfeinert werden. Bei

der Identifizierung sollte allerdings schon darauf geachtet wer-

den, dass die Elemente der Applikation nicht in mehr als eine

Komponente der MVCE Architekturmusters fallen.

3. Kategorisierung identifizierter Elemente

Nach der Identifizierung der einzelnen Elemente einer Applika-

tion m

ussen diese nun in die MVCE-Komponenten kategorisiert

werden. Nach der Kategorisierung k

onnen schon die Schnittstel-

len zwischen den Elementen definiert werden, die ja

uber das

MVCE Architekturmuster vorgegeben sind.

4. Unterteilung in Akteure. (Optional)

Die Unterteilung der identifizierten Elemente in Akteure ist ein

optionaler Schritt, der jedoch sinnvoll ist, wenn die Softwareum-

gebung dies unterst

utzt. Vorteil ist, dass die einzelnen Akteure

einzeln verfeinert werden k

onnen. Ohne Akteure m

usste jeweils

eine gesamte MVCE-Komponente verfeinert werden. Je nach

Komplexit

at dieser Komponente k

onnte eine Verfeinerung l

ange-

re Zeit in Anspruch nehmen. Bei einer geringen Komplexit

at,

wie sie normalerweise in fr

uhen Prototyp-Stadien vorzufinden

ist, ist der Aufwand der Verfeinerung ohne Akteure jedoch

nicht viel aufw

andiger, so dass am Anfang der Entwicklung

auf die Unterteilung in Akteure verzichtet werden kann. Sollte

die Softwareumgebung allerdings die Unterteilung in Akteure

unterst¨

utzen (siehe 4.5.2148), sollte sie auch durchf¨

uhrt werden.

5. Erster Prototypen mit Platzhalter

Nach Identifikation und Unterteilung kann das Grundger

ust der

Elemente bzw. Akteure in einer Softwareumgebung implemen-

tiert werden. Eine Implementation der definierten Schnittstellen

der Komponenten bzw. Akteure ist denkbar, eine Funktionalit

muss allerdings zu diesem Zeitpunkt noch nicht vorhanden

sein. Der erste Prototyp wird in den meisten F

allen nur das

102

4.3 ENTWICKELTE METHODEN

Programmger

ust mit den Schnittstellen und Verbindungen zwi-

schen den Komponenten bzw. Akteuren abbilden.

6. Iterationen zur Verfeinerung

Der Prototyp kann nun durch das iterative Entwurfsvorgehen

weiter verfeinert werden. Je nach festgelegtem Schwerpunkt bei

der Entwicklung k

onnen alle Komponenten gleichzeitig oder

aber einzelne Komponenten verfeinert implementiert werden.

Durch dieses Vorgehen besteht z. B. die M

oglichkeit, zuerst die

Komponenten des Controllers zu verfeinern, um sie schon in

uhen Prototypen zu testen, andere Komponenten jedoch in

einem sehr fr

uhen Entwicklungsstadium beizubehalten. Es ist

auch m

oglich, von einer verfeinerten Komponente zur

uck zu

einer fr

uheren Implementation zu gehen, wenn z. B. andere

Komponenten isoliert betrachtet werden sollen. Beispiele f

ur die

verschiedenen Arten der Vorgehensweise bei der Verfeinerung

zeigt Kapitel 5159

7. Fertige Applikation

Nachdem jede Komponente zu ihrer gew

unschten Form ver-

feinert ist kann der Prototyp als fertige Applikation bezeichnet

werden. Soll diese Applikation zu einem sp

ateren Zeitpunkt

weiter entwickelt werden, stehen ihr die gesamten Prototypen

der vergangenen Iterationen zur Verf

ugung. D. h. die Entwick-

ler k

onnen f

ur eine Komponente wieder auf ein sehr fr

uhes

Stadium der Entwicklung zugreifen um beispielsweise f

ur ande-

re Komponenten eine kontrollierte Umgebung zu erhalten. Es

ist also M

oglich auch nach der Fertigstellung der Applikation

wieder in nachfolgenden Iterationen weiter zu entwickeln.

Damit die hier vorgestellte Vorgehensweise realisierbar ist, mussten

Methoden zur Unterst

utzung des Verfahrens entwickelt werden. In

nun folgenden Kapitel werden diese Methoden vorgestellt und be-

schrieben.

4.3 Entwickelte Methoden

Zur Realisierung des MRiL-Entwurfsvorgehen mussten mehrere Me-

thoden entwickelt werden. Diese Methoden basieren meist auf schon

in der Literatur bekannten Verfahren, wurden aber f

ur das MRiL-Ent-

wurfsvorgehen angepasst oder erweitert. Im einzelnen sind das:

MVCE:

Das aus dem Entwurf von Benutzerschnittstellen bekannte

Model-View-Controller Architekturmuster wurde um die Kom-

103

MIXED REALITY IN THE LOOP

ponente

”

Environment“ erweitert und ergibt nun das MVCE

Architekturmuster. Es ist die Grundlage des MRiL-Entwurfs-

vorgehens, welches voraussetzt, einzelne Teile der Anwendung

zu einer der vier Komponenten zuzuordnen. Die klassifizierten

Teile der Anwendung k

onnen dann unabh

angig von den ande-

ren MVCE Komponenten entwickelt und verfeinert werden. Die

Aufteilung in die einzelnen Komponenten erm

oglicht dar

uber

hinaus die gemeinsame Visualisierung des Entwicklungstand

jeder einzelnen Komponente gemeinsam in einem Kiviatgraph.

Die MRiL Metrik:

Um eine Einsch

atzung

uber den Entwicklungs-

tand der Applikation zu erhalten muss m

ussen f

ur die einzelnen

Komponenten des MVCE Architekturmusters eigene Metriken

entwickelt werden. Die Metriken sind essenziell f

ur eine sinn-

volle Visualisierung des Entwicklungstand im Kiviatgraphen.

Akteurmodell:

Zur Verfeinerung der MVCE-Komponenten wurde

das Akteurmodell entwickelt, das die M

oglichkeit bietet, die

jeweiligen Komponenten feingranularer zu unterteilen. Die Ak-

teuere k

onnen einzeln und unabh

angig voneinander entwickelt

und

uber sogenannte Adapter erweitert werden. Das Akteur-

modell ist f

ur die sp

atere Implementation des MRiL-Entwurfs-

vorgehen nicht zwingend erforderlich. Sollte die verwendete

Entwicklungsumgebung das Akteurmodell unterst

utzten, sollte

die Aufteilung allerdings durchgef¨

uhrt werden.

Das Entwurfsvorgehen:

Das vorgestellte Entwurfsvorgehen basiert

auf einem iterativen Prototyping Prozess, der in jedem Schritt

Teile der Applikation verfeinert bzw. weiter entwickelt. Nach

jeder Iteration steht ein neuer Prototyp zur Verf

ugung, der f

Tests verwendet werden kann. Bei der Verfeinerung ist es uner-

heblich, ob alle Komponenten gleichzeitig oder nur eine spezielle

Komponente verfeinert werden.

Die einzelnen oben aufgez

ahlten Methoden werden im einzelnen in

den nachfolgenden Kapiteln ausf¨

uhrlich beschrieben.

4.3.1 MVCE - Model-View-Controller-Environment

Das Model-View-Controller Architekturmuster ist unter anderem in

der Benutzerschnittstellen-Entwicklung so erfolgreich, da es die ein-

zelnen Aufgaben in drei unterschiedliche und voneinander getrennte

Komponenten unterteilt. Daher k

onnen die interaktiven und visuellen

Aspekte einer Benutzerschnittstelle getrennt von der eigentlichen Ap-

plikation bearbeitet werden. Das Modell (

odel) repr

asentiert dabei

104

4.3 ENTWICKELTE METHODEN

die Daten der Applikation und kapselt diese. Die Darstellung (

iew)

kapselt die visuellen Elemente wie z. B. die Schaltfl

achen, Textbo-

xen oder Visualisierungen. Die Steuerung (

ontroller)

implementiert

die Interaktionsdetails zwischen der Applikation und dem Benut-

zer, beispielsweise Mausklicks oder Tastatureingaben. Diese leitet

er dann weiter an das Modell welches dann die

Anderungen der

jeweiligen Interaktion ausf

uhrt. Das Modell wiederum benachrich-

tigt die Darstellung, das sich Daten ge

andert haben, so dass sich

die Benutzerschnittstelle passend

andern kann. MVC erm

oglicht also

modulares Design, indem die einzelnen Komponenten nicht voneinan-

der abh

angig sind. Es erm

oglicht weiterhin die Benutzung mehrerer

Darstellungen und unterschiedlicher Controller innerhalb derselben

Applikation f

ur dasselbe Modell. Diese Eigenschaften sind gerade im

MRiL-Entwurfsvorgehen w

unschenswert, da so modular und kompo-

nentenweise implementiert werden kann.

Ein zentrales Merkmal des MRiL-Entwurfsvorgehen ist die Integration

der realen Umgebung in die digitale Anwendung. Die Applikation

ben

otigt Informationen

uber Objekte oder Koordinaten der realen

Welt, dessen Geometrie und Verhalten aber nicht unter der Kontrolle

der Applikation steht. Reale Objekte k

onnen unter dem Einfuss von

realen Manipulationen oder externen Kr

aften stehen. Daher muss

es f

ur die Applikation eine M

oglichkeit geben, die Ver

anderungen

der realen Objekte zu erkennen. In der Praxis besteht solch ein Real

World Model einer Mixed Reality Applikation aus der Kombination

aus statischen Informationen, z. B. Geometriedaten, die als fest gelten,

und dynamischen Informationen, z. B. die Position und Orientierung

des Nutzers bzw. eines zentralen Objektes. Diese dynamischen Da-

ten k

onnen

uber spezielle Sensoren w

ahrend der Laufzeit ermittelt

werden. Sensordaten k

onnten als Controller-Events im MVC Modell

gehandhabt werden, allerdings w

urde dies zu einem sehr un

ubersicht-

lichen Modell der Applikation f¨

uhren.

Um daher Mixed Reality tats

achlich in einer digitalen Anwendung

zu ber

ucksichtigen, wurde das Model-View-Controller Architektur-

muster [

Ree03

] (siehe auch

2.2.145

) um eine Dimension

”

Umgebung“

(

nvironment) erweitert, so dass die Sonderstellung der Umgebung

bei Mixed Reality Anwendungen abgedeckt wird. Diese Erweiterung

ist in Abbildung 4.1106 zu sehen. Ein Problem bei MR-Applikationen

ist, dass die Umgebung nicht zu 100 Prozent erfasst werden kann

bzw. muss. Durch verschiedene Sensoren und Techniken k

onnen In-

formationen wie Position und Orientierung von Objekten, bestimmte

technische oder physikalische Eigenschaften oder Zustands

anderun-

Steuerung wird im weiteren Text durch das englischen Wort

”

Controller“ ersetzt, da sich dieser

Begriff in diesem Zusammenhang in der Literatur durchgesetzt hat.

105

MIXED REALITY IN THE LOOP

change notification

Model (M)

View (V) Controller (C)

change notification

queryData()

changeDisplay()

user action

changeData()

Environment (E)

change notification

queryData()

Direkte Assoziation

Indirekte Assoziation

Abbildung 4.1: MVCE Architekturmuster

gen erfasst werden. Es ist aber fast unm

oglich und auch nicht sinnvoll,

alle Informationen der Umgebung zu erhalten. F

ur eine performante

MR-Applikation sollten nur Informationen der Umgebung abgefragt

werden, die wirklich ben

otigt werden. Beispielsweise sollte eine Ap-

plikation, die die H

ohe eines Objektes der Umgebung erfordert, diese

auch m

oglichst direkt geliefert bekommen und sie nicht

uber kompli-

zierte Algorithmen umst¨

andlich berechnen m¨

ussen. Letzteres w¨

urde

ur die Berechnung der realen H

ohe viel Ressourcen und Rechen-

zeit ben

otigen. Besser w

are es, diese Information mit Hilfe z. B. eines

ohensensors zu realisieren, der an dem abzufragenden Objekt ange-

bracht ist.

In Abbildung

4.1

wird die Integration der Komponente

”

Umgebung“

dargestellt. Sie ist

ahnlich dem Modell an die Darstellung gekoppelt

und tauscht ihrerseits Daten mit dem Modell aus. Ein entscheidender

Unterschied ist, dass der Controller keinen Einfluss auf die Umge-

bung hat. Das weist auf die Sonderstellung gegen

uber dem Modell

hin. Der Controller ist nicht in der Lage, Daten der Umgebung zu

ver

andern. Auch das Abfragen der Daten geht

uber den Umweg des

Modells, da dies die Daten der Umgebung empf

angt und passend

aufbereitet. Die Darstellung und das Modell benutzten dieselben Me-

thoden zur Interaktion mit der Umgebung, auch werden beide von der

Umgebung benachrichtigt, sollte sich an den Daten etwas ge

andert

haben. Die Darstellung wird versuchen, die ge

anderten Daten dann

zu visualisieren. Das Modell kann die Daten der Umgebung weiter

verarbeiten und ggf. auch die Darstellung

uber Ver

anderungen am

Modell informieren.

Uber die Darstellung, die die Benutzeraktionen

106

4.3 ENTWICKELTE METHODEN

an den Controller weiterleitet, ist es nun auch m

oglich,

Anderungen

der Umgebung als Benutzerinteraktion zu interpretieren. Daf

ur sendet

die Umgebung ein Notifikation an die Darstellung, dass sich Daten

andert haben. Die Darstellung kann diese

Anderung als Eingabe des

Benutzers interpretieren und eine Meldung einer Benutzerinteraktion

an den Controller senden. So sind Mixed Reality Benutzerschnitt-

stellen mit Hilfe von MVCE einfach realisierbar und strukturiert zu

implementieren.

Es folgt nun eine detaillierte

Ubersicht der einzelnen Komponenten

von MVCE, ihren Eigenschaften und der Verwendung:

Model:

Das Modell kapselt die eigentlichen Daten der Applikation.

Das Modell ist im allgemeinen eine passive Komponente, d. h.

es kann sich nicht selbstst

andig

andern.

Anderungen werden

nur

uber den Controller realisiert. Es ist indes m

oglich , dass

sich

Anderungen auf mehrere Teile des Modells auswirken,

die intern im Modell berechnet werden k

onnen. Als Beispiel

onnte der Controller die Position eines Modells

andern und

das Modell k

onnte zus

atzlich aus der gegebenen Position die

Farbe der Geometrie

uber eine interne Funktion neu bestimmten.

View:

In der Darstellung wird das Modell komplett oder auch nur

teilweise visualisiert. In MVCE kann es eine oder mehrere unter-

schiedliche Darstellungen vom selben Modell geben, die spezifi-

sche Teile des Modells darstellen. Als Beispiel k

onnten das zwei

Ansichten sein, die eine visualisiert die virtuelle 3D Umgebung,

eine andere nur die Kollisionsmodelle der Physikbibliothek. Die

Darstellung erh

alt Notifikationen bei

Anderung der Umgebung

und des Modells um seine Darstellung anpassen zu k

onnen. Die

Informationen muss die Darstellung allerdings selbst bei der

Umgebung bzw. beim Modell erfragen. Da weder Umgebung

noch Modell wissen, was die jeweilige Darstellung f

ur Daten

ben

otigt, ist es sinnvoller, dass sich die Darstellung selbst um

die Beschaffung der Daten k

ummert, als wenn Umgebung und

Modell die

Anderungen an jede Darstellung schicken. So wird

das Datenvolumen zwischen den Komponenten kleinstm

oglich

gehalten.

Controller:

Der Controller ist f

ur die Verarbeitung der Benutzerein-

gaben zust

andig. Die Eingaben k

onnen sowohl

uber den View

mitgeteilt als auch intern erzeugt werden. Eine Interaktion mir

einer grafischen Benutzerschnittstelle w

are ein Beispiel f

ur den

ersten Fall, eine Bewegung mit einer Wiimote

ein Beispiel f

Die Wiimote ist ein Gamecontroller der Spielkonsole Wii von Nintendo, der auch mit Standard-

107

MIXED REALITY IN THE LOOP

den zweiten Fall. Auch Komponenten, die keine Benutzerein-

gabe erfordern, jedoch zu gegebenen Zeitschritten das Modell

andern, werden im Controller gekapselt. Beispielsweise w

urde

eine Physiksimulation, die auf den Daten des Modells arbeitet,

als Controller angesehen.

Environment:

Die Umgebung ist die Komponente in MVCE, in der

die Applikation wenig Einfluss aus

uben kann. In dieser Kompo-

nente wird nicht die komplette Umwelt abgebildet, sondern nur

ein kleiner Teil, der f

ur die Applikation sinnvoll und wichtig

ist. Dieser Teil der Umgebung wird meist

uber Sensoren erfasst

und der Darstellung bzw. dem Modell zur Verf

ugung gestellt. Es

gilt, dass alle Komponenten, die mit der Umwelt interagieren, in

der Umgebungs-Komponente von MVCE realisiert werden. Als

Beispiel kann ein Objekt, welches

uber einen visuellen Tracker

erfasst wird, seine Position

andern. Der Tracker, der die Verbin-

dung zur Umgebung darstellt, teilt diese

Anderung dem Modell

mit, das seinerseits die Daten aktualisiert. Keine der anderen

Komponenten hat Einfluss auf die Umgebung und kann diese

nicht manipulieren. Es ist eine reine

”

Read-Only“-Komponente,

die der Darstellung und dem Modell Daten zur Verf

ugung stellt.

Welche Daten das sind, entscheiden die Sensoren, die die Umge-

bung analysieren, z. B. Position und Orientierung eines Objektes,

ohe und Entfernung aber auch Geschwindigkeit und Lage im

Raum. Letzteres kann gut zur Interaktion von realen Objekten

mit der Applikation genutzt werden und wird oft im Bereich

”Mixed Reality User Interfaces“ eingesetzt.

Durch diese Aufteilung der Komponenten l

asst sich die Applikation

sehr modular entwickeln. Ein weiterer Vorteil der Einteilung in die

vier Komponenten MVCE ist, dass die Software anhand des Enwick-

lungsstaus der einzelnen Komponenten analysiert werden kann. In

Abbildung

4.2109

ist ein Kiviatgraph zu sehen, der den Enwicklungs-

status einer Applikation repr

asentiert. Hierbei werden die einzelnen

Komponenten von der Mitte aus zu den R

andern abgetragen, je nach

ihrem aktuellen Status. Im Kiviatgraphen entspricht die Mitte einer

sehr geringen Komplexit

at bzw. Realismus. Die ersten Prototypen

einer Applikation werden somit in der Mitte des Kiviatgraphen an-

gesiedelt sein. Je weiter die Komponenten entwickelt werden und

komplexer bzw. realer werden, um so weiter entfernt sich die Kom-

ponenten aus der Mitte. Das heißt, je weiter eine Komponente zum

Rand abgetragen werden kann, desto komplexer bzw. realer ist sie.

Rechnern

uber Bluetooth angeschlossen werden kann.

Uber die Wiimote k

onnen Beschleunigungen und

die Lage des Gamecontrollers im Raum ermittelt werden. So k

onnen z. B. Gesten des Benutzers erkannt

und als Interaktion genutzt werden.

108

4.3 ENTWICKELTE METHODEN

Environment (E)

Controller (C)

increasing

realism/complexity

Model (M)

View (V)

Abbildung 4.2: Kiviatgraph zu Analyse des Entwicklungsstatus.

Der Kiviatgraph erm

oglicht somit eine genauere Analyse des Ent-

wicklungsstandes der MVCE-Komponenten. Bei der Entwicklung von

Mixed Reality Applikationen kann es

ofter sinnvoll sein, von einer

komplexen zur

uck auf eine etwas einfachere Implementation einer ein-

zelnen Komponente zur

uck zu gehen, um beispielsweise eine andere

komplexere Komponente sicher testen zu k

onnen bzw. Seiteneffek-

te auszuschließen.

Uber den Kiviatgraphen kann man diese beiden

Prototypen der Applikation gut unterscheiden, da sich die einzelnen

aufgetragenen Komponenten

andern, anders als h

atte man nur einen

Wert, der die Entwicklung beschreibt, wie das bei einer normalen

Softwareentwicklung der Fall ist (z. B.

uber eine Versionsnummerie-

rung). Theoretisch k

onnte der Kiviatgraph auch noch feingranularer

aufgezeichnet werden, beispielsweise

uber alle Akteure (siehe Kapitel

4.3.3120

) in der Applikation. Diese Information w

are in einigen Situa-

tionen sinnvoll, im Allgemeinen reicht allerdings der allgemeine Stand

der MVCE-Komponenten, da auch diese Informationen einfacher zu

lesen sind.

ur die Bewertung des Entwicklungsstatus der einzelnen Komponen-

ten war es allerdings notwendig, eine geeignete Metrik zu definieren.

Diese MRiL-Metrik wird im folgenden Kapitel beschrieben.

4.3.2 Die MRiL-Metrik

Bei der Bewertung des Entwicklungsstatus der Applikation kann der

in Kapitel

4.3.1104

vorgestellte Kiviatgraph genutzt werden, Um eine

109

MIXED REALITY IN THE LOOP

definierte Aussage treffen zu k

onnen, wird f

ur jede Achse des Ki-

viatgraphen eine eigene Metrik ben

otigt, die aussagt, in wie weit die

Applikation in der entsprechenden Dimension entwickelt ist. Detail-

liert werden folgende Metriken ben¨

otigt:

Modell-Metrik:

Ein Maß, welches angibt, in wie weit das Modell der

Applikation entwickelt ist.

View-Metrik:

Metrik f

ur die visuelle Komponente einer Applikation.

Controller-Metrik:

Eine Einheit zur Beschreibung der Entwicklung

des Controllers.

Environment-Metrik:

Metrik f

ur die Einordnung der Umgebung in

die Applikation.

ur jedes dieser Maße wird eine eigene Metrik ben

otigt, da sich die

Methoden zur Bestimmung f

ur jede Dimension im Kiviatgraphen

zum Teil grundlegend unterscheiden. Angelehnt sind die Metriken an

Arbeiten aus dem Bereich der Wiederverwendbarkeit von Software-

Komponenten, u. a. die Arbeiten von Boxall et al. [

BA04

] und Wa-

shizaki et al. [

WYF03

]. Dabei werden Daten, die schon aus der finalen

Quelle stammen, h

oher gewertet als simulierte Daten. Daten, die nur

ur bestimmte Prototypen benutzt werden und in der finalen Appli-

kation nicht vorhanden sind (hier virtuelle Daten genannt), werden

komplett unber

ucksichtigt, da diese Daten eigentlich nicht wiederver-

wendet werden k¨

onnen.

Modell-Metrik

Um die Metrik f

ur das Modell zu bestimmen, ben

otigt man eine

Definition des Modells der finalen Applikation. In diesem Kontext

kann das Modell folgendermaßen definiert werden:

110

4.3 ENTWICKELTE METHODEN

Definition 4.3.2.1 – Modell

Ein Modell ist die Summe aller Daten

σn

, die es der Applikation

zur Verf

ugung stellt bzw. die die Applikation auslesen und/oder

ver

andern kann. Die Daten k

onnen dabei virtuell, simuliert oder

real sein (

), was aussagt, ob die Daten aus der endg

ultigen Quelle

stammen (real) oder noch in irgendeiner Form simuliert werden

(simuliert). Sollten die Daten im sp

ateren Modell nicht existieren,

so sind sie virtuell.

M:=

∑

i=0

ei(4.1)

n: Anzahl der Daten von σn

ei=





0 : σiist ein virtuelles Datum

0, 5 : σiist ein simuliertes Datum

1 : σiist ein reales Datum

Das Modell wird hier auf einer objektorientierten Ebene definiert

und beinhaltet nicht Parameter wie beispielsweise die Anzahl der

Zeilen im Quelltext. Da das Modell abstrakt angesehen werden soll,

muss auch die Definition und die daraus resultierende Metrik abstrakt

gehalten werden. Dies ist mit der Definition

4.1

des Modells erreicht

worden. Es werden hier nur die Ein- bzw. Ausgaben eines Modells

betrachtet, also die Schnittstellen zur Applikation. Des Weiteren wird

dabei ber

ucksichtigt, ob die Daten, die zur Verf

ugung gestellt werden,

schon den endg¨

ultigen Daten entsprechen.

Um nun eine passende Metrik f

ur das Modell zu definieren, betrachtet

man das Modell der finalen Applikation und vergleicht es mit dem

zur Zeit vorhandenen Modell. Die Modell-Metrik l

asst sich daher

folgendermaßen definieren:

Definition 4.3.2.2 – Modell-Metrik

Die Model-Metrik

ΓM

ist Quotient vom vorliegenden Modell zum

finalen Modell.

ΓM:=Mproto

Mf inal

, 0 ≤ΓM≤1 (4.2)

Mproto : Modell des aktuellen Prototypen

Mf inal : finales Modell

111

MIXED REALITY IN THE LOOP

Mit der Definition des Modells durch

4.1

wird sicher gestellt, dass

Prototypen nie einen gr

oßeren Wert erhalten als das finale Modell.

Somit liegt der skalare Wert der Modell-Metrik

ΓM

immer zwischen

0und 1. Dieser Wert kann auf der Modell-Achse des Kiviatgraphen

abtragen werden, wobei 0dem Punkt auf dem innersten und 1dem

Punkt auf dem

außersten Kreis des Kiviatgraphen entspricht, wie es

an Abbildung 4.3112 dargestellt ist.

Model (M)

1,0

0,2

0,4

0,6

0,8

Abbildung 4.3: Modell-Metrik dargestellt im Kiviatgraphen.

Sollte sich das finale Modell

andern, da es z. B. in der weiteren Ent-

wicklung erweitert wird, m

ussen die Werte f

ΓM

neu berechnet

werden, da sonst ein Vergleich mit

alteren Versionen des Modells

nicht m¨

oglich ist.

Ein andere M

oglichkeit bei der Weiterentwicklung und Erweiterungen

von Prototypen ist die Version des Prototypen mit in die Modell-

Metrik ΓMeinfließen zu lassen.

Definition 4.3.2.3 – Modell-Metrik (Weiterentwicklung)

Die Modell-Metrik

ΓMn

ist Quotient einer Weiterentwicklung des

Modells (n−1)zum finalen weiterentwickelten Modell n.

ΓMn:= (n−1) + Mproto

Mf inaln

,n−1≤ΓM≤n,n∈N+(4.3)

Mproto : aktuelles Modell auf Basis vom Modell (n-1)

Mf inaln: finales weiterentwickeltes Modell n

Der Wert der Modell-Metrik Model-Metrik

ΓMn

liegt nun zwischen

dem Vorg

angermodell

(n−1)

und der finalen Weiterentwicklung

Das bedeutet f

ur die grafische Repr

asentation mit Hilfe des Kiviat-

112

4.3 ENTWICKELTE METHODEN

graphen, dass ein neuer Bereich (von

(n−1)

) hinzugef

ugt werden

muss, wie in Abbildung 4.4113 zu sehen ist.

Model (M)

1,0

0,2

0,4

0,6

0,8

!"!

1,2

1,4

1,6

1,8

2,0

Abbildung 4.4: Kiviatgraph eines weiterentwickelten Modells.

Problematisch ist bei mehreren Weiterentwicklungen, dass der Kiviat-

graph immer gr

oßer und daher auch un

ubersichtlicher wird. Um dem

vorzubeugen, kann auch nur die Entwicklung des aktuellen Prototy-

pen verwendet werden. Damit k

onnen jedoch nur die Entwicklungen

der aktuellen Entwicklungsstufe miteinander verglichen werden.

View-Metrik

Ahnlich der Modell-Metrik kann auch die View-Metrik definiert wer-

den. Zuvor muss jedoch der View definiert werden, um darauf danach

eine Metrik anwenden zu k

onnen. Dabei muss der View der finalen

Applikation bekannt sein, da die Klassifizierung der Objekte davon

abh¨

angt.

113

MIXED REALITY IN THE LOOP

Definition 4.3.2.4 – View

Der View ist die Summe aller Objekte

ωn

, die von der Applikation

visualisiert werden. Diese Objekte k

onnen dabei bez

uglich ihrer

Existenz in folgende Klassen aufgeteilt werden: tempor

ar, virtuell

oder real (

φi

). Objekte, die genau so in der finalen Applikation

vorhanden sind, bezeichnet man als real. Objekte, die zwar in der

finalen Applikation vorhanden sind, allerdings in irgendeiner Weise

anders dargestellt werden, bezeichnet man als virtuell. Sollten Ob-

jekte nur in Zwischenversionen und nicht in der finalen Applikation

vorhanden sein, so nennt man diese tempor¨

ar.

V:=

∑

i=0

φi(4.4)

n: Anzahl der Objekte von ωn

φi=





0 : ωiist ein tempor¨

ares Objekt

0, 5 : ωiist ein virtuelles Objekt

1 : ωiist ein reales Objekt

Auch bei dieser Definition des Views wird ein abstraktes Maß zugrun-

de gelegt. Dabei kann sich die Granularit

at der einzelnen Objekte

sehr stark unterscheiden, je nachdem, in welchen Fokus sie stehen.

Dabei ist indes zu beachten, dass sich die Granlarit

at w

ahrend der

Entwicklung zur Finalen Version nicht

andern darf, da sonst keine

eindeutige Metrik berechnet werden kann. Aus der Definition des

Views ergibt sich folgende Metrik:

Definition 4.3.2.5 – View-Metrik

Die View-Metrik

ΘV

ist Quotient des vorliegenden Views zum

finalen View.

ΘV:=Vproto

Vf inal

, 0 ≤ΘV≤1 (4.5)

Vproto : View des aktuellen Prototypen

Vf inal : finaler View

Genau wie bei der Definition des Modells wird auch bei der Definition

des Views in

4.4

darauf geachtet, dass keine Zwischenversion einer

Applikation einen Wert

V≥1

bez

uglich der finalen Applikation

bekommen kann. Dieser Wert kann dann im Kiviatgraphen abgetragen

114

4.3 ENTWICKELTE METHODEN

werden, genau wie es auch beim Modell in Abbildung

4.3112

zu sehen

ist.

ur Weiterentwicklungen der finalen Version der Applikation kann

die View-Metrik genauso erweitert werden, wie die Modell-Metrik:

Definition 4.3.2.6 – View-Metrik (Weiterentwicklung)

Die View-Metrik

ΘVn

ist Quotient einer Weiterentwicklung des

Views (n−1)zum finalen weiterentwickelten View n.

ΘVn:= (n−1) + Vproto

Vf inaln

,n−1≤ΘV≤n,n∈N+(4.6)

Vproto : aktueller View auf Basis vom View (n-1)

Vf inaln: finaler weiterentwickelter View n

ΘVn

liegt nun zwischen

(n−1)

und

und kann genau wie der Wert

der Modell-Metrik f

ur Weiterentwicklungen auf dem Kiviatgraphen

abgetragen werden.

Controller-Metrik

Der Controller kann sich von einem Prototyp zu anderen sehr stark

unterscheiden, da genau hier die unterschiedlichsten Bedienungskon-

zepte implementiert und getestet werden. Daher kann der Controller

nicht

ahnlich dem Modell oder dem View definiert werden. Die imple-

mentierten Controller-Strategien k

onnen nicht nach ihrer Komplexit

gemessen werden, da dies keine Aussage

uber die Qualit

at der Strate-

gie aussagt. Somit muss der Controller eine Metrik erhalten, die mehr

die Benutzbarkeit widerspiegelt.

F¨

ur den Controller ist es daher sinnvoll, sich an der Usability-Metrik

nach Jakob Nielsen [

Nie93

] [

Nie94

] anzulehnen. Bei der Usability-

Metrik nach Nielsen sind die Erfolgsrate, die Ausf

uhrungszeit und

die Fehlerrate die wichtigsten Kenngr

oßen zur Einordnung des Con-

trollers. Optional kann die Zufriedenheit und die Erlernbarkeit zur

Metrik hinzugezogen werden. Gerade bei neu entworfenen Benut-

zerschnittstellen, bei denen noch nicht abzusehen ist, in wie weit sie

vom Anwender verstanden werden und effizient verwendbar sind,

ist eine Erhebung der optionalen Kenngr

oßen vorteilhaft, um so die

Akzeptanz der Benutzer zu erfahren.

115

MIXED REALITY IN THE LOOP

Im speziellen sollten folgende Kriterien die Metrik bestimmen:

Obligatorisch

Erfolgsrate:

Ist es dem Benutzer gelungen, eine gegebene Auf-

gabe ¨

uberhaupt zu l¨

osen?

Ausf¨

uhrungszeit:

Wie lange hat der Benutzer ben

otigt, um eine

gegebene Aufgabe zu bew¨

altigen?

Fehlerrate:

Wie viele Fehler hat der Benutzer bei der Bew

alti-

gung der Aufgabe begangen?

Optional

Zufriedenheit:

Wie zufrieden ist der Benutzer mit dem Control-

ler?

Erlernbarkeit:

Wie viel Zeit hat der Benutzer ben

otigt, um sich

die Steuerung anzueignen?

Die ersten drei Kriterien k

onnen mit Hilfe entsprechend vorbereiteter

Tests objektiv gemessen werden. Im Gegensatz dazu ist die Zufrie-

denheit eine subjektive Gr

oße, die je nach Vorlieben des Benutzers

extrem unterschiedlich ausfallen und nicht objektiv bestimmt werden

kann. Dementsprechend sollte die Zufriedenheit des Benutzers op-

tional ber

ucksichtigt und eine geringere Gewichtung als die anderen

Kenngr

oßen erfahren. Allerdings kann bei Tests mit vielen Benut-

zern eine Tendenz der Zufriedenheit abgeleitet werden, die besonders

bei neuen Benutzerschnittstellen vorteilhaft ist. Die Erlernbarkeit des

Controllers sollte auch nur optional behandelt werden, da auch die-

se Bestimmung subjektiv ist, da jeder Benutzer sowohl verschiede

Vorkenntnisse als auch unterschiedliches Lernverhalt besitzt. Bei sehr

komplizierten Steuerungen sollte allerdings auf diese Messung nicht

verzichtet werden, da auch hier Tendenzen sichtbar sind.

Definition 4.3.2.7 – Controller

Der Controller ist f

ur die Steuerung der Applikation zust

andig.

Da sich die unterschiedlichen Arten der Controller jedes Prototyps

essenziell unterscheiden k

onnen, existiert keine mathematische De-

finition eines Controllers wie es bei dem View oder beim Modell

der Fall ist. Die Metrik wird ¨

uber Benutzertests ermittelt.

ur die Controller-Metrik k

onnen die aus den Usability-Tests ermit-

telten Werte verwendet werden, um einen eindeutigen Wert zu be-

kommen, so dass Controller

uber die Controller-Metrik miteinander

verglichen werden k¨

onnen:

116

4.3 ENTWICKELTE METHODEN

Definition 4.3.2.8 – Controller-Metrik

Die Contoller-Metrik

ΨC

ist die Summe der Ergebnisse der un-

terschiedlichen Benutzertests geteilt durch die Anzahl der durch-

gef¨

uhrten Benutzertests.

ΨC:=

∑

i=0

αCi

n, 0 ≤ΨC≤1, n∈N+(4.7)

n: Anzahl der unterschiedlichen Usability-Tests

αCi: Ergebnis des Usability Tests Ci

Dabei ist αCifolgendermaßen definiert:

αCi:=1−1

∑

j=1

ζj(4.8)

mit ζi:=ξi−minm

k=1(ξk)

maxm

k=1(ξk)−minm

k=1(ξk),m∈N+(4.9)

ξi: nicht normierter Messwert ides Usability-Test

ζi: normierter Messwert ides Usability-Test, 0 ≤ζi≤1,

m: Anzahl der ermittelten Werte in einem Usability-Test

Die Controller-Metrik

ΨC

aus

4.7

liefert einen Wert zwischen 0und

1, der, wie auch die Werte der anderen Metriken, auf dem Kiviatgra-

phen dargestellt werden k

onnen. Dabei werden die Daten aus den

Benutzertests normiert und der arithmetische Mittelwert mit Hilfe der

Gleichung

4.8

bestimmt. Die Normierung geschieht

uber die Formel

4.9

, die das Minimum und das Maximum der Messwerte bestimmt

und so den aktuellen Messwert in den Bereich von [0..1]legt.

Bei der Angabe zur Zufriedenheit des Benutzers muss darauf geachtet

werden, wie die Daten, die der Benutzer macht, gewertet werden.

urde das deutsche Schulnotensystem als Grundlage genommen

werden, bei dem eine

1.0

eine sehr hohe Zufriedenheit und eine

6.0

eine ungen

ugende Zufriedenheit des Benutzers ausdr

uckt, stimmt die

Berechnung mit Hilfe der Formel

4.8

. Bei Bewertungssystemen, bei

denen ein h

oherer Wert eine gr

oßere Zufriedenheit darstellt, muss die

Formel allerdings entsprechend umgestellt werden:

117

MIXED REALITY IN THE LOOP

Definition 4.3.2.9 – Controller-Metrik mit inverser Gewichtung

Bei Bewertungssystemen, bei denen ein h

oherer Wert eine besse-

re Leistung ausdr

uckt, muss die Formel

4.8

zur Berechnung des

arithmetischen Mittels ge¨

andert werden.

αCi:=1

∑

j=1

ζj(4.10)

Alle anderen Formeln und Definitionen k

onnen beibehalten werden.

Uber die Gleichung

4.10

onnen nun auch Bewertungsysteme ver-

wendet werden, die mit h

oheren Werten auch eine bessere Leistung

bzw. Zufriedenheit ausdr

ucken. Diese

Anderung ist wichtig, damit

die Darstellung im Kiviatgraphen analog zu den anderen Metriken ist.

So w

urde ein Wert, der gr

oßer als ein anderer ist, immer ein besseres

Ergebniss darstellen und im Kiviatgraphen weiter außen dargestellt

werden.

Environment-Metrik

Die Environment-Metrik kann gr

oßtenteils analog zur View- bzw.

Modell-Metrik definiert werden. Dabei kann die Umgebung (Environ-

ment) folgendermaßen definiert werden:

Definition 4.3.2.10 – Environment

Das Environment ist die Summe aller Daten

ηn

, die der Applika-

tion aus der realen Umgebung bereitgestellt werden. Diese Daten

onnen dabei bez

uglich ihrer Herkunft als real oder simuliert klas-

sifiziert werden (

δi

). Daten, die aus der realen Umgebung mit Hilfe

von Sensoren ausgelesen werden, werden real genannt. Alle ande-

ren Daten k¨

onnen als simuliert angesehen werden.

E:=

∑

i=0

δi(4.11)

n: Anzahl der Daten von ηn

δi=0, 5 : ηiist ein simuliertes Datum

1 : ηiist ein reales Datum

Bei der Definition des Environments werden die Daten, die der Appli-

kation aus der realen Umgebung geliefert werden, ber

ucksichtig. Je

118

4.3 ENTWICKELTE METHODEN

nach Entwicklungsstand k

onnen diese Daten in jeglicher Art simuliert

sein oder aus der realen Umgebung stammen. In fr

uhen Entwick-

lungsphasen werden diese Daten meist simuliert. F

ur die Applikation

ist die Art der Daten, also ob sie simuliert oder real sind, transparent.

Simuliert kann in diesem Zusammenhang auch bedeuten, das immer

nur ein fester Wert zur

uck geschickt wird, es wird hier also nicht die

Qualit

at der Simulation mitbewertet. Das ist gewollt, denn es wird hier

nicht die Qualit

at der Simulation der Umgebung betrachtet, sondern

der Anteil an realen Daten, die der Applikation bereitgestellt werden.

Aus der Definition des Environments kann nun die Environment-

Metrik analog zu der Modell- bzw. View-Metrik definiert werden:

Definition 4.3.2.11 – Environment-Metrik

Die Environment-Metrik

ΩE

ist Quotient vom vorliegenden Envi-

ronment zum finalen Environment.

ΩE:=Eproto

Ef inal

, 0 ≤ΩE≤1 (4.12)

Eproto : Environment des aktuellen Prototypen

Ef inal : finales Environment

Die Definition

4.12

stellt sicher, das die Environment-Metrik

ΩE

immer

einen Wert zwischen

[0..1]

erh

alt. So kann

ΩE

auf der entsprechenden

Achse des Kiviatgraphen abgetragen werden, wobei auch hier ein

gr¨

oßerer Wert einer h¨

oheren Entwicklungsstufe entspricht.

Ebenso l

asst sich f

ur die Weiterentwicklung eines Prototypen eine

Definition der Environment-Metrik definieren:

Definition 4.3.2.12 – Environment-Metrik (Weiterentwicklung)

Die Environment-Metrik

ΩEn

ist Quotient einer Weiterentwicklung

des Environments

(n−1)

zum finalen weiterentwickelten Environ-

ments n.

ΩEn:= (n−1) + Eproto

Ef inaln

,n−1≤ΩE≤n,n∈N+(4.13)

Eproto : aktuelles Environment auf Basis von Environment (n-1)

Ef inaln: finales weiterentwickeltes Environment n

119

MIXED REALITY IN THE LOOP

ΩEn

liegt nun zwischen den Werten

(n−1)

und

und kann genau

wie der Wert der Modell- bzw. View-Metrik f

ur Weiterentwicklungen

auf dem Kiviatgraphen abgetragen werden.

Zusammenfassung

Die vier hier vorgestellten Metriken k

onnen im MRiL-Entwurfsvor-

gehen dazu verwendet werden, einen erstellten Prototypen bez

uglich

seines Entwicklungsgrades zu klassifizieren. Dies geschieht, indem die

Metriken ermittelt werden und auf den entsprechenden Achsen des

Kiviatgraphen abgetragen werden. Da sich das MRiL-Entwurfsvor-

gehen sowohl f

ur die schnelle Entwicklung von Prototypen als auch

ur die Evaluierung von neuen Eingabemethoden eignet, muss f

ur jede

dieser beiden Priorit

aten der Aufwand zur Bestimmung der einzel-

nen Metriken mitber

ucksichtigt werden. Insbesondere die Ermittlung

der Controller-Metrik kann viel Zeit und Resourcen an Benutzern

kosten, wenn ausf

uhrliche Tests an einer großen Gruppe an Anwen-

dern ausgef

uhrt werden sollen. Die Tests und deren Auswertung

kann sehr viel Zeit kosten. Deshalb stehen die beiden Ziele

”

schnelle

Prototypenentwicklung“ und

”

ausf

uhrliche Evaluierung neuer Be-

nutzerschnittstellen“ entgegengesetzt zueinander. F

ur die schnelle

Prototypenentwicklung sind keine bzw. nur in einem geringen Maße

ausgef

uhrte Benutzertests f

ur die Bestimmung der Controller-Metrik

sinnvoll. Hier k

onnte schon ein Test mit einem der Entwickler reichen.

Anders ist es bei der Entwicklung von neuen Benutzerschnittstellen.

Hier sollten ausf

uhrliche Tests zumindest f

ur die final entwickelten

Strategien durchgef

uhrt und ausf

uhrlich analysiert werden. So ist

es m

oglich, eine sehr genaue Bestimmung der Controller-Metrik zu

erhalten, die dann mit anderen Entwicklungen in diesem Bereich

verglichen werden kann.

4.3.3 Das Akteurmodell

Im vorherigen Kapitel wurde das MVCE Architekturmodell vorge-

stellt, das es erlaubt, die zu entwickelnde Applikation in vier un-

terschiedliche Komponenten zu unterteilen und diese dann getrennt

voneinander zu entwickeln. Um bei der Entwicklung eine noch feinere

Granularit

at der Elemente zu erhalten, basiert das MRiL-Entwurfs-

vorgehen auf sogenannten Akteuren (engl. Actors), die wiederum

unabh

angig voneinander entwickelt werden k

onnen. Die Verwendung

von Akteuren sind beim MRiL-Entwurfsvorgehen optional, d. h. diese

Unterteilung ist bei der Entwicklung nicht zwingend erforderlich,

allerdings wirkt sie sich positiv auf die Implementierung aus. Da die

120

4.3 ENTWICKELTE METHODEN

Akteure untereinander

uber festgelegte Ports miteinander kommu-

nizieren, ist eine getrennte Entwicklung der einzelnen Akteure nach

Festlegung der Schnittstellen leicht m¨

oglich.

f((x1 x2 ... xn),

(a1 a2 ... ai))

= ((y1 y2 ... ym),

(b1 b2 ... bj))

Capsulated Component(s)

Input Port x1

Input Port x2

Input Port xn

•••

Output Port y1

Output Port y2

Output Port ym

•••

Internal Input a1

Internal Input a2

Internal Input ai

•••

Internal Output b1

Internal Output b2

Internal Output bj

•••

Aktor

Abbildung 4.5: Abstrakter Aufbau eines Akteurs.

In Abbildung

4.5

ist Aufbau eines Akteurs abstrakt dargestellt. Ein

Akteur besteht aus einer Anzahl vom Eingangs-Ports, die skalare

Werte, Vektoren oder Matrizen als Wert annehmen k

onnen. Der Ak-

teur benutzt diese Werte zur Erzeugung seiner Ausgaben. Dies kann

uber einfache Transformationen bis hin zu komplizierten Funktionen

reichen. Ein Akteur kann des Weiteren noch interne Eingabe-Ports

besitzen, die mit verarbeitet werden. Diese internen Eingabe-Ports

stammen aus gekapselten Komponenten, beispielsweise dedizierter

Hardware oder interne Softwarekomponenten, die

uber diesen Akteur

abgefragt werden kann. Dabei kann ein Akteur sowohl eine einzelne

als auch mehrere Komponenten in sich kapseln, die sowohl Ausgaben

produzieren als auch Eingaben annehmen. Gerade Akteure, die zur

Komponente Controller geh

oren, besitzen solche internen gekapselten

Komponenten, da sie h

aufig spezielle Hardware kapseln m

ussen. Die

Ausgaben werden einerseits

uber die Ausgabe-Ports zur Verf

ugung

gestellt und k

onnen andererseits

uber interne Ausgabe-Ports aus-

gegeben werden. Intern werden die Ausgaben auch wieder an die

gekapselten Komponenten

ubertragen, die beispielsweise eine dedi-

zierte Hardware darstellt. Die internen Ausgabe-Ports sind, genau wie

die internen Eingabe-Ports, wichtig f

ur die Kommunikation zwischen

121

MIXED REALITY IN THE LOOP

dem Akteur und den gekapselten Komponenten. Die Akteure k

onnen

nun untereinander verbunden werden, so dass ein Datenflussnetz-

werk entsteht.

Uber eine entsprechende

”

Verdrahtung“ der einzelnen

Akteure entsteht so die Applikationslogik einer Applikation. Dabei

wird jeder Akteur einer bestimmten MVCE-Komponente zugeordnet.

Es ist zu beachten, dass ein Akteur keinen zwei Komponenten zu-

geordnet werden darf, damit die Aufteilung in Modell, Darstellung,

Umgebung und Controller nicht verletzt wird.

Adaptor

Aktor

Capsulated Component(s)

f(x) g(x)

Abbildung 4.6: Abstrakter Aufbau eines Eingabe-Ausgabe-Adapters.

Um die Entwicklung der Akteure zu vereinfachen wurde das Prin-

zip des Adapters eingef

uhrt. Adapter erweitern die Funktionalit

eines Akteurs, indem Sie

uber ihre interne Logik passende Werte

an die Eingabe- bzw. Ausgabeports der Akteure liefern bzw. entge-

gennehmen. Adapter haben ihrerseits eine Menge an Eingabe- und

Ausgabeports, so dass sie f

ur das Datenflussnetzwerk wie normale

Akteure wirken. Weiterhin k

onnen Adapter auch Komponenten kap-

seln, die intern Ausgaben erzeugen und Eingaben erwarten. Dabei

kann ein Adapter sowohl keine Komponente kapseln, so dass keine

internen Ein- und Ausgabe-Ports existieren und ein Adapter auch als

Protokollkonverter gesehen werden kann. Es k

onnen jedoch auch ein

oder mehrere Komponenten in einem Adapter gekapselt werden, wie

es auch beim Akteur der Fall ist. Damit sind Erweiterungen von Ak-

teuren denkbar, die ihrerseits keine Komponenten kapseln, allerdings

durch einen Adapter spezielle Komponenten zur Verf

ugung gestellt

werden.

Es gibt insgesamt drei unterschiedliche Arten von Adaptern: den

Eingabe-Adapter, der nur die Eingaben des jeweiligen Akteurs kapselt

und durch eigene Eingabe-Ports ersetzt, den Ausgabe-Adapter, der

122

4.3 ENTWICKELTE METHODEN

die Ausgaben des Akteurs kapselt und den Eingabe-Ausgabe-Adapter,

der sowohl die Ein- als auch die Ausgaben des Akteurs kapselt. In

Abbildung

4.6

ist der Aufbau eines Eingabe-Ausgabe-Adapters zu

sehen. Er nimmt Daten aus dem Datenflussnetzwerk an und berechnet

die Eingaben f

ur den gekapselten Akteur

uber die Funktion

f(x)

. Die

Ausgaben, die der Akteur zur Verf

ugung stellt, wandelt der Adapter

anschließend mit der Funktion

g(x)

um und gibt diese an das Daten-

flussnetzwerk weiter. Adapter k

onnen, genau wie Akteure, interne

Ein- und Ausgaben verarbeiten, um so z. B. zus

atzliche Hardware

anzusprechen. Des Weiteren hat der Eingabe-Ausgabe Adapter die

oglichkeit, Daten zwischen den beiden Funktionen

f(x)

und

g(x)

auszutauschen. So hat z. B. die Funktion

g(x)

die M

oglichkeit, auf die

Eingabedaten des Adapters zuzugreifen.

Aktor

Component

Adapter 1

Adapter 2

Component

Abbildung 4.7: Schachtelung von Adapern.

Mit dem Prinzip des Adapters lassen sich sehr elegant Spezialisie-

rungen bzw. Verfeinerungen von Akteuren realisieren. So m

ussen

die Akteure nicht komplett neu programmiert werden, um auf neue

Daten reagieren zu k

onnen. Es reicht aus, einen Adapter vor den

Akteur zu schalten, der die passende Transformation der Daten vor-

nimmt.

Uber Adapter ist es auch m

oglich, inkompatible Ports in

einem Datenflussnetzwerk miteinander zu verbinden. Ein Adapter

ubernimmt in einem solchen Fall die Transformation der Daten in das

ur den Akteur geforderte Format. So ist ein Austausch bestimmter

Softwarebibliotheken (beispielsweise unterschiedliche Bibliotheken

zur Berechnung von physikalischen Effekten) einfach m

oglich, da das

Datenflussnetzwerk zum gr¨

oßten Teil unver¨

andert bleiben kann.

Ein

uber einen Adapter erweiterter Akteur kann von außen betrachtet

wiederum als einzelner Akteur betrachtet werden. So ergibt sich die

oglichkeit, mehrere Adapter zu verschachteln, wie in Abbildung

4.7

dargestellt ist. So ist es m

oglich, einen Akteur, der zu Anfang nur

Grundfunktionalit

at anbot, schrittweise

uber iterative Kapselung von

123

MIXED REALITY IN THE LOOP

Adaptern allm

ahlich Funktionalit

at zuzuf

ugen. Dies entspricht dem

Prinzip der Vererbung in der objektorientierten Programmierung, bei

der auch einem Objekt mit jeder weiteren Vererbung mehr Funktiona-

lit

at zugef

ugt wird. Diese M

oglichkeit der iterativen Verfeinerung bzw.

Erweiterung eines Akteurs finden wir im Grundprinzip vom MRiL

wieder, da dieser Prozess auf einem iterativen Prozess aufsetzt. Somit

onnen in einem Iterationsschritt die Verfeinerungen der Akteure

uber die Verschachtelung von Adaptern gel

ost werden.

Uber dieses

Prinzip lassen sich sehr kleine Iterationszyklen erreichen, so dass die

Erstellung von Prototypen zu Testzwecken schnell und mit wenig

Aufwand realisiert werden kann.

4.3.4 Das Entwurfsvorgehen

Konzeption Implementierung Tests Bewertung

Abbildung 4.8: Abstrakte ¨

Ubersicht des iterativen Prototyping Prozess.

Wie schon in Kapitel

4.2101

kurz erw

ahnt, ist die Grundlage des MRiL-

Entwurfsvorgehen ein iterativer Prototyping Prozess. Im Wesentlichen

basiert dieser Prozess auf dem von Pomberger vorgstellten Prototy-

ping Entwicklungsprozess [

PW94

], der in Kapitel

2.1.1239

vorstellt

wurde. Es wurden allerdings einzelne Phasen anders definiert. Die

Grundlage der kurzen Iterationen stammt aus dem Scrum Vorgehens-

modell [

BDS+99

], das in Kapitel

2.1.1134

vorgestellt wurde. Abbildung

4.8

zeigt die abstrakte

Ubersicht des gesamten Prozesses. Der Prozess

ist in vier Phasen unterteilt, die aus der Konzeptionierung, der Imple-

mentierung, der Testphase und der Bewertungsphase bestehen. Diese

Phasen werden in mehreren Iterationen durchlaufen.

In der detaillierteren Ansicht des Prozesses in Abbildung

4.9125

ist der

konkrete Aufbau des Prozesses zu erkennen. Die einzelnen abstrakten

Phasen sind hier in die konkreten Phasen eingebettet worden. So

wird die Konzeptionierung in der Initialisierungsphase des Prozesses

bearbeitet. Die Implementierung geschieht in der Verfeinerungsphase,

die Tests werden in der Prototypphase durchgef

uhrt. Die Bewertung

der Tests werden in der gleichnamigen Bewertungsphase ermittelt. Im

Einzelnen haben die vier Phasen folgende Aufgaben:

Initialisierung:

In der Initialisierungsphase wird der Prototyp auf

124

4.3 ENTWICKELTE METHODEN

Initialisierung

Verfeinerung

Bewertung

Prototyp

Abbildung 4.9: Konkreter Aufbau des iterativen Prototyping Prozess.

den n

achsten Verfeinerungsschritt vorbereitet. Zu Beginn der

Entwicklung, wenn noch kein Prototyp aus einer fr

uheren Itera-

tion vorliegt, wird in dieser Phase das grundlegende Verhalten

des ersten Prototypen festgelegt.

Verfeinerung:

Am existierenden Prototypen werden die Verfeine-

rungen vorgenommen. Verfeinerung kann bedeuten, dass eine

Komponente komplexer wird, dass sie aufgeteilt wird bzw. dass

mehrere Teiler einer Komponente verschmolzen werden. Dassel-

be gilt selbstverst

andlich auch f

ur Akteure, falls die Applikation

in solche aufgeteilt wurde. Da zu Beginn der Entwicklung noch

kein Prototyp aus einer vorherigen Phase vorhanden ist, wird

hier das grundlegende Verhalten, wie es in der Initialisierung

festgelegt wurde, implementiert. Meist wird in dem ersten Pro-

totypen der Funktionsumfang und die Komplexit

at sehr einfach

gehalten.

Prototyp:

In dieser Phase sind alle vorangegangenen Verfeinerungen

abgeschlossen und ein neuer Prototyp steht zur Verf

ugung. Mit

diesem Prototypen k

onnen nun Benutzer- und Useablility-Tests

durchgef

uhrt und analysiert werden. Der entstandene Prototyp

gilt als Basis f¨

ur weitere Iterationen.

Bewertung:

In dieser Phase werden die Ziele des n

achsten Prototypen

anhand der Bewertung der zuvor durchgef

uhrten Tests festgelegt

und die daraus folgenden Verfeinerungen definiert. Sollten sich

vorhandene Schnittstellen

andern oder neue hinzu kommen,

werden sie hier definiert.

Nach diesem groben

Uberblick werden nun die einzelnen Phasen

detailliert beschrieben.

125

MIXED REALITY IN THE LOOP

Die Initialisierungsphase

Initialisierung

Prototyp

Festlegen der

Änderungen

(Verfeinerung,

Aufteilung,

Zusammenfügung)

Auswählen der zu

benutzenden

Komponenten

Erster Durchlauf

Festlegen der zu

implementierenden

Komponenten

Abbildung 4.10: Detailansicht der Initialisierungsphase.

Die Initialisierungsphase wird zur Vorbereitung der Verfeinerungs-

phase ben

otigt. Hier wird festgelegt, welche Komponenten verfeinert

werden sollen und auf welchen zuvor schon implementierten Kompo-

nenten aufgebaut wird. Zu Beginn der Entwicklung einer Applikation

wird in dieser Phase das Verhalten des ersten Prototyps festgelegt,

welches dann in der Verfeinerungsphase implementiert wird. Diese

Phase sollte nach M

oglichkeit nicht viel Zeit verbrauchen. Das kann

man erreichen, wenn nur wenig w

ahrend der Verfeinerungsphase

ver

andert wird. Es sollte jedoch nicht zu wenig ver

andert werden, da

sich dann die Prototypen nicht weit genug unterscheiden und so keine

sinnvollen Schl¨

usse aus der Entwicklung gezogen werden k¨

onnen.

In dieser Phase wird konzeptionell an der Applikation entwickelt,

Implementierungen sind nicht vorgesehen. Es werden die Vorraus-

setzungen f

ur die n

achste Verfeinerungssphase geschaffen. Im ers-

ten Durchlauf wird die Grundfunktionalit

at des ersten Prototypen

festgelegt. Da hier noch nicht auf einen aus einer vorherigen Pha-

se stammenden Prototypen zur

uckgegriffen werden kann und auch

nicht auf schon vorhandene implementierte Komponenten, sollten der

Funktionsumfang und die Komplexit

at recht einfach gehalten werden,

um die Implementierungsphase zeitlich kurz zu halten.

Die Verfeinerungssphase

In der Verfeinerungsphase werden die konzeptionellen

Anderungen

und Verfeinerungen, die in der Initialisierungsphase entwickelt wur-

den, implementiert. Es werden zuerst die Komponenten in die Appli-

kation eingebunden, die f

ur den jeweiligen Schritt ben

otigt werden.

126

4.3 ENTWICKELTE METHODEN

Verfeinerung

Prototyp

Einbau der schon

vorhandenen

Komponenten

Änderungen der

Komponenten

(Verfeinerung

Aufteilung,

Zusammenfügung)

Erster Durchlauf

Implementierung

der Komponenten

des ersten

Prototypen

Abbildung 4.11: Detailansicht der Verfeinerungsphase.

Diese werden dann je nach Konzept erweitert, verfeinert, aufgeteilt

oder zusammengef¨

ugt.

Im ersten Durchlauf des Prozesses werden hier die Teile f

ur den

ersten Prototypen implementiert. Normalerweise sollten zu diesem

Zeitpunkt noch keine Verfeinerungen der einzelnen Komponenten

entwickelt werden, da Ziel des ersten Durchlaufs die Fertigstellung

eines rudiment¨

aren Prototypen ist.

Diese Phase ben

otigt die meiste Zeit im Entwurfsvorgehen, kann

jedoch von mehreren Entwicklern gleichzeitig bearbeitet werden (vor-

ausgesetzt es wird an mehr als einer Stelle entwickelt).

Die Prototypphase

Prototyp

Prototyp Fertig

Funktions- und

Benutzertests

des Prototypen

Bewertung

Bewertung der

Funktions- und

Benutzertests

Abbildung 4.12: Detailansicht der Prototypphase.

Die Prototypphase wird dazu verwendet, den Prototypen, der in

der Verfeinerungsphase entwickelt wurde, zu testen. In dieser Pha-

se k

onnen Benutzertests durchgef

uhrt werden und die neuen bzw.

verfeinerten Komponenten auf ihre Tauglichkeit getestet werden. Kom-

127

MIXED REALITY IN THE LOOP

ponenten, die in der Verfeinerungsphase weiter entwickelt wurden,

sollten in der Prototypphase genauestes untersucht werden, sowohl

auf ihre funktionale Korrektheit als auch auf die Benutzbarkeit. Hier-

zu lassen sich sehr gut Benutzertests verwenden, die dann

uber die

Qualit

at der Applikation Aufschluss geben. Die Ergebnisse dieser

Tests k

onnen in der Bewertungsphase ausgewertet und f

ur den nach-

folgenden Durchlauf in die Entwicklung mit eingebracht werden.

Sollte der Prototyp sein Endstadium erreicht haben, kann in der

Prototypphase die Endkontrolle der Funktionalit

at und Benutzbarkeit

ausf

uhrlich getestet werden. Nach erfolgreichen Tests ist die Applika-

tion fertig und kann verwendet werden. Sollten sp

atere

Anderungen

gew

unscht werden, k

onnen einfach weitere Iterationen verwendet

werden, um diese ¨

Anderungsw¨

unsche zu realisieren.

Die Bewertungsphase

Bewertung

Testbewertung zur

Festlegung der

Verfeinerungen

Definition der zu

ändernden

Komponenten

Festlegung der zu

verwendenden

Komponenten

Abbildung 4.13: Detailansicht der Bewertungsphase.

In der Bewertungsphase werden die Ergebnisse der Prototypphase

ausgewertet und die Ziele des n

achsten Prototypen festgelegt. Es wird

in dieser Phase entschieden, welche Komponenten ge

andert werden

sollen und ob auf bereits vorhandene, allerdings weniger verfeinerte

Komponenten bei der n

achsten Iteration zur

uckgegriffen werden soll.

Nachdem der Entwurfsprozess erl

autert wurde, ist es sinnvoll, diesen

an einem kleinen Beispiel exemplarisch durchzuf

uhren. Nachfolgend

stelle ich ein solches Beispiel vor und beschreibe, wie hier MRiL

eingesetzt wurde.

4.4 Erl¨auterung des Entwurfsvorgehens an einem

Beispiel

Die zuvor vorgestellten Methoden wurden an einem kleineren Bei-

spiel angewendet, um deren Anwendbarkeit zu testen. Es wurde

128

4.4 ERL ¨

AUTERUNG DES ENTWURFSVORGEHENS AN EINEM BEISPIEL

hier noch keine spezielle Softwareumgebung verwendet sondern das

Beispiel wurde in reinem Java implementiert. Realisiert wurde das

Beispiel im Rahmen eine Bachelorarbeit, die zum Ziel hatte, meh-

rere wissensbasierte Verfahren zur Wegeplanung zu entwerfen und

zu vergleichen [

Bol10

]. Um das MRiL-Entwurfsvorgehen auf diese

Aufgabe anwenden zu k

onnen, wurde diese Applikation auf einem

Multitouch-Tisch (siehe Abbildung

4.14129

) implementiert und eine

neue Bedienung hinzugef¨

ugt [SBK+10].

Abbildung 4.14: Beispielapplikation auf einem Multitouch-Tisch.

4.4.1 ¨

Uberblick des Beispiels

Als Aufgabe f

ur die Bachelorarbeit wurde der Entwurf und der Ver-

gleich wissensbasierter Verfahren zur Wegeplanung gestellt. Die Idee

war hierbei, verschiedene Arten von Wegeplanungsalgorithmen mit

dem Hintergrund zu testen, dass autonome Roboter einen kurzen,

nicht gef

ahrlichen Weg in einer gegebenen Werkshalle finden soll-

ten. Dabei sollte zum einen die Wegstrecke und zum anderen die

Gefahren der Wegstrecke ber

ucksichtigt werden. So wurden stati-

are Fertigungsanlagen definiert, die einen gewissen Raum immer

ur sich beanspruchten, allerdings teilweise in freie Gebiete hineinra-

gen konnten. Die autonomen Roboter k

onnen diesen Raum f

ur ihre

Wegeplanung nutzen, m

ussen allerdings warten, falls die Fertigungs-

anlagen diesen Raum zeitweise belegen. Daher kann es zwar einen

sehr kurzen Weg durch eine Werkshalle geben, jedoch durch die War-

tezeiten der autonomen Roboter muss dies nicht der schnellste Weg

129

MIXED REALITY IN THE LOOP

sein.

Die Arbeit sollte auf einem schon vorhandenen Software-Framework

der Hochschule Harz aufgebaut werden [

SGR08

]. Das Framework

bot eine schon vorhandene Realisierung einer 3D Darstellung samt

Management und Import verschiedener 3D Modelle und Texturen

aus entsprechenden Dateien an. Eine Wegeplanung war grunds

atzlich

implementiert, sollte allerdings im Rahmen der Arbeit neu entwi-

ckelt werden. In der Bachelorarbeit sollte zun

achst der Framework

um passende Schnittstellen erweitert und im zweiten Schritt verschie-

dene Wegeplanungen implementiert werden. Konzeptionell wurde

die Applikation soweit entwickelt, dass sie augmentiert in der realen

Umgebung benutzt werden sollte, wobei die Hindernisse, die von

der Wegeplanung umgangen werden sollten,

uber reale Objekte, soge-

nannte

”

Tangibles“, realisiert wurden. Implementiert wurde allerdings

nur soweit, dass die Applikation auf einem Multitouch-Tisch lauff

ahig

war.

Das Konzept, dass die Grundlage der Anwendung bildete, wurde mit

Hilfe des MRiL-Entwurfsvorgehens realisiert. Dabei wurden folgen-

de Teile der Applikation den entsprechenden MVCE-Komponenten

zugeteilt:

Model:

Jeder implementierte Algorithmus zur Wegeplanung wird

der Modell-Komponente zugeordnet.

View:

Sowohl eine 2D- als auch eine 3D-Ansicht der Szene wurde

dem View zugeordnet.

Controller:

Der Controller beinhaltet alle Interaktionsmethoden, an-

gefangen von einfachen Klicks mit der Maus bis zu sp

ateren

Interaktionen mit Tangibles.

Environment:

Die reale Umwelt, die der Applikation zur Verf

ugung

gestellt wurde. Anfangs wurde kein Teil der realen Umgebung

erkannt, sp

ater wurden die Tangibles in der realen Umgebung

zur Positionierung verwendet. In der AR-Version sollten noch

weitere Aspekte der Umgebung verwendet werden.

Auf eine weitere Einteilung in Akteure wurde in diesem Beispiel

verzichtet, da dies vom eingesetztem Software-Framework nicht un-

terst¨

utzt wurde.

130

4.4 ERL ¨

AUTERUNG DES ENTWURFSVORGEHENS AN EINEM BEISPIEL

4.4.2 Realisierung des Beispiels

Zu Beginn der Entwicklung wurde das vorhandene Software-Frame-

work auf die bevorstehende Aufgabe vorbereitet und soweit konfigu-

riert, dass es effizient eingesetzt werden konnte. Nachdem die Teile

der Applikation, wie oben beschrieben, in ihre MVCE-Komponenten

eingeteilt wurden, begann die Implementierung des ersten Prototy-

pen. Dieser sollte nicht sehr komplex sein und nur sicherstellen, dass

Framework und das Zusammenspiel der einzelnen Komponenten

funktioniert. Da die 3D Darstellung schon vom Framework bereitge-

stellt wurde, wurde schon zu Anfang eine sehr detaillierte Darstellung

gew

ahlt, wie in Abbildung

4.15131

zu sehen ist. Dabei wurde der au-

tonome Roboter (1) sowie die Fertigungsanlagen (5) durch Platzhalter

visualisiert, die im Framework vorhanden waren. Die Grundfl

ache

der Werkshalle wurde in der 3D Darstellung

uber eine Textur (2)

definiert, die die Ausmaße repr

asentiert. Der Start- und Endpunkt (3

und 4) wurden zuerst fest gew

ahlt, sollte jedoch in einem sp

ateren

Prototypen frei w¨

ahlbar sein.

E M

Abbildung 4.15:3D Darstellung des ersten Prototypen.

Als Controller des ersten Prototypen kam eine einfache 2D-GUI zum

Einsatz (siehe Abbildung

4.16132

), die es erm

oglichte, die Wegepla-

nung zu starten, stoppen und zu pausieren. Dies wurde

uber Kreise

im oberen Bildteil von Abbildung

4.16132

realisiert. Die Fertigungs-

anlagen wurden

uber Maus-Interaktionen gesetzt, in der die Art,

131

MIXED REALITY IN THE LOOP

Anzahl, Position und Orientierung der einzelnen Fertigungsanlagen

gesetzt werden konnten. Da f

ur sp

atere Prototypen eine AR-Version

geplant war, die auf reale Objekte reagieren sollte, wurde schon in

diesem Prototyp die Interaktion mit dem Benutzer

uber das TUIO-

Protokoll

[

KBBC05

] realisiert, so dass die 2D GUI die entsprechenden

TUIO-Befehle simulierte. Da die Anbindung an das TUIO-Protokoll

vom Framework angeboten wurde, war die die Implementation einer

TUIO-basierten GUI ohne großen Aufwand zu realisieren.

Abbildung 4.16: Rudiment¨

are GUI zur Steuerung der Prototypen.

ur die Wegeplanung des ersten Prototypen kam der in der Litera-

tur bekannte

A∗

-Algorithmus [

Sto00

] [

Rab00a

] [

Rab00b

] zum Einsatz.

Dieser gilt als robuster Algorithmus, der ohne Ausnahme einen Weg

findet, solle ein Pfad vom Start- zum Endpunkt existieren. Der

A∗

Algorithmus sollte als Referenz f

ur die folgenden Wegeplanungsal-

gorithmen gelten, um diese vergleichen zu k

onnen. Im Rahmen der

Bachelorarbeit sollten verschiedene Wegeplanungsalgorithmen, die

aus dem Bereich Organic Computing stammen, miteinander bzgl.

Robustheit, Wegl¨

ange und Effizienz verglichen werden.

Am Kiviargraph in Abbildung 4.15131 wurde der Entwicklungsstand

TUIO steht f

angible

ser

nterface

bject. Das TUIO-Protokoll erlaubt die

Ubertragung (

uber

Netzwerk) einer abstrakten Beschreibung von interaktiven Oberfl

achen (und auch

uber Kamera getracke

Objekte), die beispielsweise den Zustand oder die Position eines Objektes enthalten.

132

4.4 ERL ¨

AUTERUNG DES ENTWURFSVORGEHENS AN EINEM BEISPIEL

des ersten Prototypen dargestellt. Es ist zu erkennen, dass die Umge-

bung in diesem Prototypen nicht ber

ucksichtigt wurde, allerdings die

Darstellung schon ein hohes Niveau besitzt. Der Controller, der im

ersten Prototypen durch die 2D GUI realisiert wurde, ist noch sehr

rudiment

ar genau wie das das Modell, das durch den zugrundeliegen-

den Algorithmus zur Wegeplanung definiert wird. Nach Fertigstellung

des ersten Prototypen gab es noch viel Potential zur Verfeinerung.

Um die Aufgabenstellung der Bachelorarbeit schnellst m

oglich zu

realisieren, wurde in der Bewertungsphase f

ur den zweiten Proto-

typen festgelegt, einen komplexeren Algorithmus, den Ant Colony

Optimization-Algorithmus (ACO) [

DBS06

], zu implementieren und

eine abstrakte 2D Darstellung des Szenarios zu integrieren, die es

erlaubt, die gefundenen Wege der Algorithmen besser zu visualisie-

ren. Da im ersten Prototypen die Simulation an die 3D Darstellung

gekoppelt war, musste hier noch eine Entkopplung der Darstellung

und der Simulation erfolgen. Das war erforderlich, da der ACO ein

heuristischer, biologisch-inspirierter Algorithmus ist und erst nach

einer gewissen Anzahl an Durchl¨

aufen eine geeignete L¨

osung findet.

E M

Abbildung 4.17:2D Ansicht des zweiten Prototypen.

In Abbildung

4.17

ist die 2D-Ansicht des zweiten Prototypen zu

sehen. Die Fertigungsanlagen werden durch ein graues Quadrat dar-

gestellt. Die Kreise um diese Quadrate sind die Gefahrenbereiche, in

denen Teile der Fertigungsanlage tempor

ar reinragen k

onnen. Der

Weg des autonomen Roboters ist in zwei Teile geteilt. Der erste Teil ist

der zur

uckgelegte Weg (hier gr

un dargestellt), der zweite Teil ist der

133

MIXED REALITY IN THE LOOP

geplante Weg, den der Roboter noch zur

ucklegen muss. Am Kiviatgra-

phen erkennt man, dass das Modell des Prototypen verfeinert wurde,

da hier der ACO-Algorithmus gew

ahlt werden kann. Die Darstellung

ist etwas komplexer geworden, da die abstrakte 2D Darstellung zur

schon vorhandenen 3D Darstellung hinzugekommen ist. Sowohl der

Controller als auch die Umgebung haben keine Verfeinerung erfahren

und sind deshalb unver¨

andert gegen¨

uber dem ersten Prototypen.

Nach Fertigstellung des zweiten Prototypen waren die Tests erfolg-

reich und es war m

oglich, die beiden implementierten Algorithmen

miteinander zu vergleichen. In der nachfolgenden Iteration sollte nun

ein letzter Algorithmus, der Particle Swarm Optimization-Algorith-

mus (PSO) [

KE95

] [

LQH06

], implementiert werden. Weiterhin ergab

sich durch eine Zusammenarbeit mit einer Projektgruppe die M

oglich-

keit, die Benutzerschnittstelle auf einen Multitouch-Tisch zu reali-

sieren [

SBK+10

]. Da das Framework schon eine Anbindung an das

TUIO-Protokoll hatte, war die Umsetzung nicht sehr kompliziert, da

auch die Tracking-Software des Mulitouch-Tisches auf dem TUIO-

Protokoll basierte.

E M

Abbildung 4.18: Multitouch-Oberfl¨

ache des dritten Prototypen.

In der Abbildung

4.18

ist die Benutzerschnittstelle auf dem Multi-

touch-Tisch zu sehen. Die Fertigungseinheiten k

onnen

uber Tangibles.

die hier als schwarze Zylinder zu erkennen sind, auf dem Tisch positio-

niert werden. Weiterhin wurde die M

oglichkeit geschaffen, bestimmte

Parameter der implementierten Algorithmen

uber den Multitouch-

Tisch zu ver

andern. Eine 3D-Darstellung der Szene wurde

uber ein

134

4.4 ERL ¨

AUTERUNG DES ENTWURFSVORGEHENS AN EINEM BEISPIEL

L-Shape realisiert, das hinter dem Multitouch-Tisch platziert wurde.

So war eine gleichzeitige Darstellung der abstrakten 2D Ansicht und

der realistischen 3D Darstellung m

oglich. Am Kiviatgraphen ist zu

erkennen, dass durch die Implementierung des PSO-Algorithmus und

die M

oglichkeit der Ver

anderung der Parameter der Algorithmen das

Modell weiter verfeinert wurde. Auch die Ansicht wurde verfeinert, da

die vormals einfachen Modelle durch realistische 3D-Modelle ersetzt

wurden. Die Verfeinerung des Controllers ergab sich durch die Inter-

aktion

uber en Multitouch-Tisch und der Benutzung von

”

Tangibles“

als reale Repr

asentanten der Fertigungsanlagen. Die Verwendung der

”

Tangibles“ hat auch Einfluss auf die Verfeinerung der Umgebung, da

nun Teile der realen Umgebung erkannt und verarbeitet werden.

Der letzte Prototyp wurde aus zeitlichen Gr

unden nur theoretisch

vorbereitet. Anstelle des im vorangegangenen Prototypen verwende-

ten Multitouch-Tisches einschließlich der 3D-Darstellung

uber das

L-Shape sollte eine Augmented Reality Anwendung entwickelt wer-

den. Das Tracking sollte auch ¨

uber ”Tangibles“ realisiert werden, die

jedoch nun im 3D Raum getrackt werden sollten. Auf der Position

dieser

”

Tangibles“ sollte dann eine 3D-Darstellung der Fertigungs-

anlagen

”

augmentiert“ werden. Durch diesen Schritt w

urden die

3D-Darstellung und die realen

”

Tangibles“ zu einer Einheit zusam-

mengef

ugt werden. Alle vorhandenen Informationen, die derzeit auf

der 2D-Benutzerschnittstelle des Mutlitouch-Tisches zu sehen sind,

sollten in die reale Umgebung gezeichnet werden. Die AR-Applikation

atte dementsprechend die Darstellung und die Umgebung im Ki-

viatgraphen verfeinert. Modell und Controller w

aren gleich geblieben,

da sich an der grunds

atzlichen Benutzung der Applikation wenig

ge¨

andert h¨

atte.

4.4.3 Fazit des Beispiels

An diesem kleinen Beispiel wurde das MRiL-Entwurfsvorgehen ge-

testet. Es kam keine spezielle Softwareumgebung, die das Vorge-

hen unterst

utzt, zum Einsatz. Deshalb konnten nur die generellen

Aspekte angewendet werden. Allerdings unterst

utzte das Framework

teilweise die Verarbeitung von Tracking-Informationen, was die Rea-

lisierung von MR-Interaktionen erleichterte. Die Einteilung in die

MVCE-Komponenten war hilfreich, da sie die Entwicklung erleichtert

und beschleunigt hat. Des Weiteren war die Erstellung von Prototypen

mit Hilfe der MVCE-Einteilung schnell zu realisieren.

Da das hier eingesetzte Framework nicht auf das MRiL-Entwurfsvor-

gehen angepasst war, konnten viele Vorteile, wie z. B. der Einteilung in

Akteure und die Verfeinerung durch Adapter, nicht verwendet werden.

135

MIXED REALITY IN THE LOOP

Grunds

atzlich war die Verwendung von MRiL aber vorteilhaft, da die

schnelle Anpassung an innovative Benutzerschnittstellen sehr einfach

m¨

oglich war.

Es ist zu sehen, dass MRiL grunds

atzlich auch ohne spezielle Werk-

zeugunterst

utzung anwendbar ist. Um allerdings eine optimale Un-

terst

utzung des MRiL Entwurfsvorgehens zu erhalten, sollte dieser

mit Hilfe spezieller Entwicklungswerkzeuge angewendet werden. Da

es allerdings keine Werkzeuge dieser Art gab, wurden zwei L

osungen

implementiert, die im Folgenden beschrieben werden.

4.5 Die Softwareumgebung

Um MRiL in der Entwicklung einsetzten zu k

onnen, ben

otigt man

eine Softwareumgebung, die das Vorgehen unterst

utzt. Dabei ist es

wichtig, dass die grunds

atzlichen Prinzipen von MRiL in den Werk-

zeugen unterst

utzt werden. Um zu Beginn der Arbeit die Ans

atze von

MRiL anwenden zu k

onnen, wurde auf eine propriet

are 3D Entwick-

lungsumgebung zur

uckgegriffen, die durch unterschiedliche eigene

Erweiterungen auf das Entwurfsvorgehen angepasst wurde. Da sich

im Laufe der Arbeit aber herausstellte, dass nicht alle Aspekte des

Entwurfsvorgehens mit dieser Softwarel

osung abgebildet werden

konnten, habe ich mich entschieden, eine komplett eigene Entwick-

lungsumgebung im Rahmen einer Masterarbeit an der FH D

usseldorf

entwickeln zu lassen [

Pog09

]. Hier wurde das MRiL-Entwurfsvor-

gehen komplett in Software abgebildet, so dass es keine Unterschiede

zwischen dem Konzept und der sp

ateren Implementierung auftraten.

Im Folgenden Kapitel

4.5.1

stelle ich 3DVIA Virtools und die Er-

weiterungen, die die Entwicklung von Mixed Reality Anwendungen

erm

oglichen, kurz vor und beschreibe dann in Kapitel

4.5.2148

die

eigens f¨

ur MRiL entwickelte Softwareumgebung MiReAS.

4.5.1 Erweiterungen des propriet¨aren Autorensystems 3DVIA

Virtools

Um das MRiL-Entwurfsvorgehen zu Beginn dieser Arbeit schnell

evaluieren zu k

onnen und Anwendern mit wenig Programmierer-

fahrung ein Werkzeug an die Hand zu geben, mit dem sie schnell

Applikationen entwerfen k

onnen, wurde auf eine propriet

are Ent-

wicklungsumgebung zur

uckgegriffen und diese mit Hilfe von Plug-

ins erweitert. Ich habe mich f

ur das Autorensystem 3DVIA Virtools

(vormals Virtools) von Dassault Systems in der Version 4.0entschie-

136

4.5 DIE SOFTWAREUMGEBUNG

den [

Das09

]. Hier war einiges an Erfahrung schon vorhanden, so dass

die Entwicklung eigener Komponenten f

ur dieses System in kurzer

Zeit m

oglich war. Diese Umgebung wurde in einigen Ver

offentlichen

und Demonstratoren verwendet, beispielsweise

”

Entwicklung von

Augmented Reality-Pr

asentationen mit einem High-Level Authoring

System – eine Fallstudie“ [

GSR+06

”

Development of an augmented

reality game by extending a 3D authoring system“ [

GSKF07

”

Mixed

Reality Authoring“ [

GS07

”

HYUI: a visual framework for prototy-

ping hybrid user interfaces“ [

GFLS08

] und

”

Authoring of 3D and AR

Applications for Educational Purposes“ [SGDZ08].

Abbildung 4.19: Die Entwicklungsumgebung 3DVIA Virtools.

3DVIA Virtools - ¨

Ubersicht

3DVIA Virtools

ist eine komplette Entwicklungs- und Verteilungs-

plattform mit einem innovativen Ansatz zur interaktiven Erstellung

von 3D-Inhalten. Eine Innovation dieser Plattform gegen

uber anderen

Entwicklungsumgebungen in diesem Gebiet besteht darin, dass die

imperative Programmierung zum gr

oßten Teil durch eine visuelle

Programmierung ersetzt wurde, dem so genannten Behavior Graph,

zu sehen in Abbildung

4.20138

. Der Behavior Graph ist ein gerichteter

63DVIA Virtools wird nachfolgend nur noch Virtools genannt.

137

MIXED REALITY IN THE LOOP

Graph von miteinander verbundenen Building Blocks (die Grundele-

mente der visuellen Programmierung in Virtools, siehe Abbildung

4.20138

), der das Programm darstellt. Virtools bietet eine große Aus-

wahl an schon vorhandenen Building Block an, die

uber einfach Aufga-

ben, wie Transformation eines 3D Objekts, bis hin zu sehr komplexen

Aufgaben, wie die Bewegungssteuerung eines Charakters, verf

ugt.

Die Funktion der einzelnen Building Blocks ist sehr gut dokumen-

tiert und meist an Beispielen erkl

art, so dass die Entwicklung von

Applikationen selbst f

ur programmierunerfahrene Anwender einfach

oglich. Durch graphische hierarchische Zusammenfassung schon

bestehender Buidling Blocks ist es weiterhin m

oglich, eigene, neue,

wiederverwendbare Building Blocks zu erzeugen, diese zu speichern

und in anderen Projekten weiter zu verwenden (In Abbildung

4.20138

ist z. B. der Building Block

”

Get Phantom State“ ein zusammenge-

fasster Building Block). Neben der Wiederverwendbarkeit kann das

visuelle Programm durch diese Zusammenfassungen in neue Building

Blocks ¨

ubersichtlicher gestaltet werden.

Abbildung 4.20: Behavior Graph mit verbundenen Building Blocks.

Sollte die visuelle Programmierung f

ur manche Probleme nicht ausrei-

chen bzw. die Komplexit

at der visuellen Programme zu groß werden,

gibt es die M

oglichkeit, Teile des Programms in einer der Skript-

sprachen VSL (

irtools

cripting

anguage) oder LUA [

ICdF99

] (ab

Version 5.0von Virtools) zu erstellen und in einem Building Block

zu kapseln, wie in Abbildung

4.21139

zu sehen.

Uber VSL/LUA kann

jede Funktionalit

at von Virtools verwendet werden, so dass die Pro-

grammierung

uber die Skriptsprache keine Nachteile bietet. Vorteil ist

z. B. die k

urzere Form der Programme, gerade bei Konstrukten wie

Schleifen und Bedingungen.

Sollten die integrierten Building Blocks f

ur spezielle Aufgaben nicht

ausreichen bzw. der Programmablauf sowohl

uber Building Blocks

138

4.5 DIE SOFTWAREUMGEBUNG

VSL Building Block

Abbildung 4.21: VSL Skript Manager und VSL Building Block.

als auch

uber Skripts zu lange dauern bzw. zu komplex werden,

besteht die M

oglichkeit, eigene Building Blocks

uber das mitgelieferte

SDK in C/C++ zu entwickeln. Das SDK bietet vollen Zugriff auf alle

Funktionen in Virtools, es besteht die M

oglichkeit sowohl auf die

Behavior Engine als auch auf die Render Engine zuzugreifen und dort

Manipulationen vorzunehmen. Die eigenen Building Blocks k

onnen

genau wie die internen in einen Behavior Graphen eingef

ugt werden

und unterscheiden sich grunds

atzlich nicht von diesen. Zus

atzlich zu

Building Blocks k

onnen so genannte Manager mit dem SDK entwickelt

werden, die globale Funktionen

ubernehmen k

onnen. Manager folgen

dem Prinzip eines Singleton (vgl. [

GHJV96

] Seite 156 ff.), d. h. es

existiert immer nur jeweils eine Instanz dieses Managers innerhalb

eines Programms. In den einzelnen Building Blocks kann auf diese

Manager global zugegriffen werden. Somit l

asst sich dort globale

Funktionalit¨

at kapseln.

Neben den unterschiedlichen Programmierarten bietet Virtools eine

komplexe und moderne 3D Rendering Engine, die effizient auch große

Szenen darstellen kann. Sie basiert auf Microsofts DirectX 9.0c und

integriert fortgeschrittene Techniken wie Schattenwurf, Shaderintegra-

tion, Rendertargets, etc., die einfach

uber die bereitgestellten Bulding

Blocks benutzt werden k

onnen. Diese Techniken sind auf einer hohen

Abstraktionsebene in Virtools implementiert, so dass sich der Ent-

wickler nicht um technische Details k

ummern muss. Um Modelle in

Virtools benutzten zu k

onnen, werden f

ur alle g

angigen 3D Design

Programme wie Maya oder 3D Studio Max Export-Plug-ins bereitge-

stellt, die die Modelle in das f

ur Virtools lesbare Format speichern.

139

MIXED REALITY IN THE LOOP

Damit ist sichergestellt, dass die Inhalte, egal mit welcher Software

entwickelt, mit Virtools weiterverarbeitet werden k¨

onnen.

Bei Fertigstellung der Anwendung kann diese als lauff

ahiges Pro-

gramm exportiert bzw. in einem webbasierten Player wiedergegeben

werden. Damit kann die Anwendung auf verschiedenen Plattformen

und mit unterschiedlichen Benutzergruppen getestet werden. Leider

verbietet die strenge Lizenzpolitik von Dassault Systems eine einfache

Handhabung, dazu mehr im Abschnitt

”

3DVIA Virtools - Nachteile“

in Kapitel 4148.

Als Entwicklungsumgebung bietet Virtools zusammenfassend folgen-

de Merkmale:

Behavior Graph: ¨

Uber den Behavior Graphen kann Programmlogik

und Algorithmik visuell programmiert werden.

Bibliothek vordefinierte Programmbl¨

ocke: ¨

Uber die mitgelieferten

Building-Blocks von Virtools k

onnen visuelle Programme erstellt

werden. Sie werden in den Behavior Graphen eingef

ugt und

untereinander verbunden.

Skriptsprachenanbindung:

Zu der visuellen Programmierung bietet

Virtools zus

atzlich die M

oglichkeit, Teile der Algorithmik in

einer textuellen imperativen Skriptsprache zu realisieren. Dabei

stehen die Skriptsprachen VSL und LUA zur Verf¨

ugung.

Entwicklung eigener Building Block ¨

uber SDK:

Ist die Implemen-

tierung

uber Building-Blocks nicht ausreichen, zu komplex wer-

den oder die Ausf

uhrungszeit bestimmter Programmteile opti-

miert werden, k

onnen

uber das mitgelieferte SDK diese Abschnit-

te in C/C++ realisiert und Virtools als eigenst

andige Building

Blocks bzw. Manager zur Verf¨

ugung gestellt werden.

Moderne 3D Render Engine:

Die Darstellung der 3D-Inhalte wird

durch eine moderne auf DirectX 9.0c basierende 3D Render

Engine realisiert, die u.a. Schattenberechnung, Shaderintegration

und Rendertargets unterst¨

utzt.

Export:

Die fertige Anwendung kann aus Virtools exportiert werden

und sowohl in einem webbasierten Player abgespielt als auch in

eine ausf¨

uhrbare Datei abgespeichert werden.

3DVIA Virtools - Konzepte

3DVIA Virtools beinhaltet f¨

unf Schl¨

usselkomponenten:

140

4.5 DIE SOFTWAREUMGEBUNG

•

Die graphische Benutzerschnittstelle zur Entwicklung von An-

wendungen durch visuelle Programmierung von Objekten und

Verhalten.

•

Die Behavior Engine zur Ausf

uhrung von interaktiven Anwen-

dungen.

•Die Render Engine zur Visualisierung der Anwendung in Echt-

zeit.

•

Die Virtools Skriptsprache f

ur die Low-Level Programmierung

bestimmter Funktionen.

•Das SDK f¨

ur benutzerspezifische Behaviors.

Die graphische Benutzerschnittstelle von Virtools wir in jedem Schritt

in der Entwicklung genutzt. Sie beinhaltet u. a. Ein 3D Layout zur

Darstellung des Inhalts der Anwendung in Echtzeit. Hier wird die

komplette virtuelle 3D Szene dargestellt. Unter Verwendung der zur

Verf

ugung stehenden grafische Werkzeuge k

onnen 3D Objekte, Kame-

ras, Lichter, etc. erzeugt, ver

andert selektiert und manipuliert werden.

Uber Drag & Drop kann Entit

aten einer virtuellen 3D Szene Verhal-

ten hinzugef

ugt werden. Dieses Verhalten wird

uber die Behavior

Buildung Blocks visuell erzeugt und in einer schematischen Ansicht

dargestellt. Ausgef

uhrt wird dieses Verhalten durch die Behavior

Engine, die zu Anfang jedes darzustellenden Bildes ausgef¨

uhrt wird.

Die Behavior Engine f

uhrt sowohl selbst entwickelte als auch von Vir-

tools mitgeliefertes Building Blocks aus. Die mitgelieferten Building

Blocks umfassen u. a. die Kategorien Kamera, CHaracter, Kollisions-

erkennung, Optimierung, Pfadfindung, Mesh-Modifikation, Logik,

Partikel, Sound, etc. Die Behavior-Bibliothek kann durch selbst ent-

wickelte Building Blocks erweitert werden. Diese werden mit dem

mitgelieferten SDK in C++ programmiert und in Virtools eingebunden

werden.

Virtools Render Engine kann f

ur viele Plattformen verwendet werden

und kann von DirektX 5

uber DirectX 9.0c bis OpenGL 2.0konfigu-

riert werden, so dass eine große Anzahl an Konfigurationen abgedeckt

werden kann. Die Render Engine unterst

utzt in den neueren Konfigu-

rationen programmierbare Vertex- und Pixel-Shader bis Version 3.0,

die in DirextX mit HLSL, CgFX oder Assembler und in OpenGL in

GLSL programmiert werden k

onnen. F

ur den Import von Modellen

bietet Virtools Plug-ins f

ur alle g

angigen 3D Modeling Systeme an,

die sowohl Modelle als auch Animationen nach Virtools exportieren

onnen. Dynamische Erzeugung und L

oschung von Objekten und

141

MIXED REALITY IN THE LOOP

Modellen wird mit der Render Engine komplett unterst

utzt. F

ur die

Animation von Charakteren bietet die Render Engine ein Skin and

Bones System an, mit dem sich Bewegungen nat¨

urlich animieren las-

sen. Die gesamte Funktionalit

at der Render Engine l

asst sich auch f

selbst geschriebene Building Blocks ¨

uber das SDK verwenden.

Die Skriptsprachen VSL und LUA sind in Virtools voll integriert und

werden

uber einen speziellen Editor direkt programmiert. Virtools be-

sitzt f

ur die Skriptprogrammierung eine intelligentes Farbsystem, eine

kontextsensitive Vervollst

andigung und eine Anzeige von Argumen-

ten einer Funktion. Weiterhin bietet Virtools f

ur die Skriptprogrammie-

rung einen kompletten Debug-Mode mit Breakpoints, anzeigen und

andern von Variableninhalten und eine Schritt-Ausf

uhrung (Sinlge-

Step) an.

Das SDK von Virtools ist eine Sammlung von Entwicklungswerkzeu-

gen, die aus Biblioteken, sowohl statisch als auch dynamisch, und

Header-Dateien bestehen. Sie bieten vollen Zugriff auf alle Low-Level

Funktionen von Virtools. Mit dem SDK k

onnen Entwickler sowohl

eigenst

andige Applikationen, die auf Virtools basieren, als auch Erwei-

terungen von Virtools selbst entwickeln. Erweiterung k

onnen dabei

Behaviors, Medien-Importer, Manager, Render Engine Plug-ins oder

Rasterizer sein.

3DVIA Virtools - Erweiterungen

Damit Virtools das MRiL-Entwurfsvorgehen zum Teil unterst

utzten

konnte, mussten einige eigene Komponenten mit Hilfe des SDKs

realisiert werden. Im Einzelnen waren das folgende Erweiterungen:

Tracking:

Diese Building Blocks sind f

ur die Registrierung von realen

Objekten in der virtuellen Welt zust¨

andig.

•ReacTIVision Building Blocks und Manager f¨

ur ein bildba-

siertes 2D Tracking [GFLS08]

•

ARToolkitPlus Building Blocks und Manager f

ur ein bildba-

siertes 3D Tracking [GSKF07]

•

OptiTrack Building Blocks und Manager f

ur ein 2D/3D

Infrarot-Tracking [GSR+06]

•

OpenCV Building Blocks und Manager f

ur ein bildbasiertes

2D/3D Tracking [GFLS08]

142

4.5 DIE SOFTWAREUMGEBUNG

Kommunikation:

Building Blocks, die f

ur eine Kommunikation zwi-

schen Virtools und anderen Applikationen, z. B. MATLAB/Si-

mulink, zust¨

andig sind.

•

COMMUVIT Building Block und Manager zur synchronen

Kommunikation mit externen Tools [SGDZ08]

Eingabe:

Diese Kategorie von Building Blocks beinhaltet die Anbin-

dung verschiedener Eingabe-Hardware an Virtools.

•

Wiimote Building Blocks zur Steuerung der virtuellen In-

halte [GSKF07]

•

OpenHaptics Building Block und Manager zur Steuerung

von haptischen Ger¨

aten [GSKF07]

Ausgabe:

Building Blocks, die Ergebnisse auf spezieller Hardware

ausgeben k¨

onnen.

•

Ausgabe

uber einen externen Midiadapter, um so Midi-

gesteuerte Ger¨

ate ansprechen zu k¨

onnen [GFLS08]

Abbildung 4.22:2D Tracking mit ReacTIVision in Virtools.

Die wichtigsten Erweiterungen f

ur das MRiL-Entwurfsvorgehen sind

die Tracking Building Blocks, mit denen es m

oglich ist, 2D bzw. 3D

143

MIXED REALITY IN THE LOOP

Positionen aus einem Videobild zu berechnen. Das 2D Tracking mit Re-

acTIVision(siehe Abbildung

4.22

) kann f

ur eine einfache Registrierung

von realen Objekten genutzt werden, bei denen die Tiefeninformation

nicht wichtig ist (z. B. Infotext, der an ein reales Objekt gebunden sein

soll). Der Vorteil der 2D Registrierung ist die Performance und die

Robustheit dieser Methode. Daher kann das 2D Tracking auch gut f

reale Benutzerschnittstellen eingesetzt werden. Die Implementierung

von ReacTIVision hat weiterhin den Vorteil, dass die Erkennung durch

eine eigenst

andige Anwendung realisiert wird und die Tracking-Daten

mittels TUIO-Protokoll [

KBBC05

]

uber ein Netzwerk versendet wer-

den. D. h. Hauptanwendung und Trackinganwendung k

onnen auf

verschiedenen Rechnern laufen so dass die Performance gesteigert

werden kann.

Abbildung 4.23: Tracking mit ARToolKitPlus Building Blocks.

ur das 3D-Tracking sind zwei verschiedene Verfahren verwendet

worden, zum einen ein bildbasiertes Tracking

uber Marker mit Hilfe

vom ARToolKitPlus (siehe Abbildung

4.23

), zum anderen ein Infrarot-

144

4.5 DIE SOFTWAREUMGEBUNG

Tracking mit Hilfe von OptiTrack (siehe Abbildung

4.24145

). Das

Tracking mit ARToolKitPlus geschieht

uber ein Videobild, in wel-

chem spezielle Marker gesucht werden. Werden diese gefunden, ist

ARToolKitPlus in der Lage, die 3D Position dieser Marker im Ka-

meraraum zu bestimmen. Daf

ur ist aber eine Kalibrierung auf die

jeweilige Kamera und auf das jeweilige Objektiv der Kamera not-

wendig. F

ur Virtools wurde diese Funktionalit

at in mehrere logische

Building Blocks aufgeteilt. F

ur die globale Erkennung wurde ein spe-

zieller Building Block entwickelt, der einmal pro Frame aufgerufen

wird, das aktuelle Videobild ausliest und dieses analysiert. Damit

nur jeweils eine Instanz vom ARToolKitPlus zur Laufzeit aktiv ist,

wurde diese in einem Manager gekapselt, der die Funktionalit

at f

die einzelnen Building Blocks im Behavior Graphen zur Verf

ugung

stellt. Einzelne Marker werden durch jeweils einen Building Block

im Behavior Graphen abgebildet und reagieren somit nur auf einen

spezifischen Marker. Diese Building Blocks fragen den Manager nach

ihren Daten. Falls der spezielle Marker im Videobild erkannt wur-

de liefert der Manager die Position zur

uck. Je nach Anzahl der im

Bild befindlichen Marker und der Gr

oße des Videobildes kann die

Erkennung viel Rechenleistung beanspruchen.

Abbildung 4.24: Infrarot-Tracking mit OptiTrack Building Blocks.

Das Infrarot-Tracking funktioniert im Prinzip wie das oben beschriebe-

ne bildbasierte Tracking, mit dem Unterschied, dass die OptiTrack-API

zur Erkennung benutzt wird. Beim Infrarot-Tracking kann nicht zwi-

schen verschiedenen Markern unterschieden werden, da diese keine

ID-Informationen kodiert haben. Daher ist es im 3D Tracking nur

oglich, ein einzelnes Objekt per Infrarot zu tracken und eindeutig

145

MIXED REALITY IN THE LOOP

zuzuweisen. Vorteil des Infrarot-Trackings ist die hohe Genauigkeit

und die gr

oßere Entfernung, gemessen an bildbasierten Trackingver-

fahren, in der die Erkennung funktioniert. Des Weiteren ist, gegeben

durch die schnelle Bildwiederholrate der Infrarot-Kamera (im vorlie-

genden Fall: 120 Bilder pro Sekunde), ein genaues Tracking m

oglich,

bei dem die Latenzen sehr gering sind. Das kann zwar auch beim

bildbasierten Tracking erreicht werden, jedoch werden dann spezielle

Kameras ben

otigt und die Leistung des Rechners muss ausreichend

sein um die Einzelbilder zu analysieren.

Eine zweite bildbasierte Tracking-Methode wurde mit Hilfe der offe-

nen Bibliothek OpenCV realisiert. Diese ist aber erst in einem fr

uhen

Stadium der Entwicklung und wurde, nachdem auf MiReAS gewech-

selt wurde, nicht weiter entwickelt. Grund f

ur die Entwicklung eines

OpenCV-basierten Trackers war die Unabh

angigkeit von anderen

Tracking-Verfahren und die dadurch resultierende Freiheit in der

Entwicklung.

COMMUVIT

Abbildung 4.25:COMMUVIT Building Block und Simulink Modell.

Eine weitere wichtige Erweiterung in Virtools ist die Anbindung an

externe Anwendungen. Dies wurde

uber das von Henning Zabel ent-

wickelte Werkzeug COMMUVIT [

SGDZ08

] [

LZE+06

] [

LZB07

] reali-

siert, das eine

Ubergabe von jeglichen Daten zwischen Anwendungen

zur Verf

ugung stellt. Ein wichtiger Punkt ist, dass COMMUVIT die

Anwendungen auch zeitlich koppelt, so dass die Werte immer aktuell

sind. In unseren Beispielen haben wir COMMUVIT verwendet, um

physikalisch korrekte Modelle in MATLAB/Simulink zu berechnen

und in Virtools zu visualisieren und damit zu interagieren. Abbildung

4.25

zeigt eine Virtools-Anwendung, die zur Berechnung der Bewe-

gung der roten Kugel ein MATLAB/Simulink Modell hinterlegt hat,

das f¨

ur jeden Frame die physikalisch richtige Position berechnet.

Um neue Interaktionsm

oglichkeiten zu schaffen, wurden zwei Buil-

ding Blocks realisiert, die unterschiedliche Eingabehardware in Vir-

146

4.5 DIE SOFTWAREUMGEBUNG

tools zur Verf

ugung stellen. Zum einen ist das der Wiimote Building

Block, der es erlaubt, die Wiimote (die eigentlich zur Benutzung der

Spielekonsole Wii von Nintendo gedacht ist) in Virtools-Projekten zu

benutzen. Gerade durch die eingebauten Beschleunigungssensoren

ist es eine kosteng

unstige Alternative zu anderen Speziall

osungen.

Uber die Beschleunigungssensoren ist es m

oglich eine einfache Ges-

tenerkennung zu realisieren, die f

ur die Steuerung benutzt werden

kann.

Uber die eingebaute Kamera wird weiterhin ein 2D Tracking

zur Verf

ugung gestellt, so dass eine Pointer-basierte Interaktion mit

Hilfe der Wiimote m¨

oglich ist.

Abbildung 4.26: Eingabe ¨

uber das OpenHaptics Interface in Virtools.

Der OpenHaptics Building Block (siehe Abbildung

4.26

) wurde spe-

ziell f

ur das haptische Feedback zum Benutzter realisiert. Gesteuert

werden kann damit z. B. ein SensAble Phantom Omni Haptic Devi-

ce [

Sen10

], das dem Benutzer als Eingabemedium dient.

Uber das

Phantom kann ein Punkt im 3D Raum incl. Richtung angesteuert wer-

den. Der Programmierer hat die M

oglichkeit, eine gewisse Gegenkraft

auf das Eingabeger

at zu geben, so dass das Gef

uhl eines Widerstandes

entsteht.

Uber verschiedene Parameter lassen sich unterschiedliche

haptische Materialeigenschaften programmieren.

Uber die oben beschriebenen Building Blocks, die die Funktionalit

von Virtools erweiterten, ließen sich einige Konzepte des MRiL-Ent-

wurfsvorgehens realisieren, wie es in Kapitel

5159

beschrieben wird.

Allerdings konnten nicht alle Konzepte in Virtools realisiert werden,

da die Struktur von Virtools dies nicht zuließ.

147

MIXED REALITY IN THE LOOP

3DVIA Virtools - Nachteile

Leider gab es bei der Verwendung von Virtools auch einige Nachteile,

die u. a. daf

ur verantwortlich waren, dass eine eigene Entwicklungs-

umgebung realisiert wurde. Zu diesen Nachteilen z¨

ahlen:

MRiL Prozess nicht komplett abbildbar:

Infolge der vorgegebenen

Struktur von Virtools war es nicht m

oglich, das gesamte MRiL-

Entwurfsvorgehen abzubilden. Damit aber dieser Prozess kom-

plett evaluiert werden konnte, war es essenziell, eine Entwick-

lungsumgebung zu besitzen, die diese Abbildbarkeit leistete.

Lizenzproblematik:

Leider wurde infolge einer Lizenz

anderung in

neueren Versionen von Virtools untersagt, selbst geschriebene

Bulding Blocks weiterhin der Community zur Verf

ugung zu

stellen. Des Weiteren ist der Webplayer in den neueren Versio-

nen nicht mehr in der Lage selbst geschriebene Building Blocks

zu laden und auszuf

uhren. Dementsprechend m

ussen f

ur je-

de Demo eigene ausf

uhrbare Dateien kompiliert werden, falls

auf dem Zielsystem kein Virtools installiert ist. Leider m

ussen

diese Demos einen Lizenzschl¨

ussel haben, so dass es schwierig

ist, Demos auf Konferenzen oder Messen vorzustellen oder im

wissenschaftlichen Rahmen zu ver¨

offentlichen.

Propriet¨

ar:

Da Virtools eine propriet

are Software ist, gestaltet sich

eine Anpassung auf eigene Bed

urfnisse

außerst schwierig.

Uber

das SDK kann viel Funktionalit

at realisiert werden, leider aber

nicht alles. Daher war es auch nicht m

oglich, das komplette

MRiL-Entwurfsvorgehen auf Virtools abzubilden, da wichtige

Strukturen und Funktionsweisen nicht ver¨

anderbar waren.

Aus den oben genannten Gr

unden war es notwendig, eine eigene, auf

das MRiL-Entwurfsvorgehen zugeschnittene Entwicklungsumgebung

zu programmieren. Es wurde besonders darauf geachtet, dass eine

quelltextoffene Implementation einer 3D Grafikbibliothek als Grund-

lage diente, um ggf. Konzepte nachtr

aglich ins System integrieren zu

k¨

onnen.

4.5.2 MiReAS - Eine Mixed Reality Softwareumgebung

Die Ergebnisse, die mit der Entwicklungsumgebung basierend auf Vir-

tools entstanden sind, waren zum großen Teil akzeptabel. Da jedoch

die von uns entwickelten Erweiterungen in Virtools nicht das komplet-

te MRiL-Entwurfsvorgehen abdecken, insbesondere die Rollen von

148

4.5 DIE SOFTWAREUMGEBUNG

Akteuren, wurde eine Softwareumgebung entwickelt, die speziell f

meinen MRiL Prozess entworfen wurde. Diese Softwareumgebung

wurde an der Hochschule D

usseldorf im Rahmen einer Masterar-

beit [

Pog09

] nach den Vorgaben des MRiL-Entwurfsvorgehens entwi-

ckelt und tr

agt den Namen MiReAS:

xed

ality

ctor

imulation.

MiReAS kann als Werkzeug f

ur schnelles Prototyping sowie f

ur die

einfache Entwicklung von Mixed Reality Anwendungen verwendet

werden. Durch die konsequente Umsetzung des MRiL Vorgehens ist

MiReAS eine ideale Plattform f

ur die Entwicklung und die Tests von

Mixed Reality Anwendungen.

Damit MiReAS die Vorraussetzungen f

ur den MRiL-Entwurfsprozess

erf¨

ullt, mussten folgende Anforderungen erf¨

ullt werden:

•Bereitstellung einer komponentenbasierten Architektur mit der

oglichkeit, Komponenten einfach zu adaptieren, auszutau-

schen oder wieder zu verwenden

•

Verwendung einer Quelltext-offenen 3D Renderbibliothek ba-

sierend auf einem Szenegraphen zur einfachen Erstellung von

Szenarios

•

Unterst

utzung essenzieller Mixed Reality Funktionalit

at, bei-

spielsweise die Verwendung von Videoger

aten und Tracking-

systemen sowie die einfache Erweiterbarkeit auf neue Tracking-

systeme

•

Unterst

utzung einer großen Anzahl von Eingabeger

aten bzw.

die M¨

oglichkeit, solche einfach in das System einzubinden

•

Anbindung an eine Physiksimulation, systemintern

uber eine

schnelle Physikbibliothek aus dem Game-Sektor, dar

uber hin-

aus allerdings auch

uber externe Programme wie z. B. MAT-

LAB/Simulink f¨

ur mathematisch pr¨

azisere Berechnungen

•Einfache Nutzung von Netzwerkschnittstellen zur Verteilung

•

Benutzerfreundliche und einfach anwendbare Systemkonfigura-

tion

uber Konfigurationsdateien im XML Format bzw. grafische

Benutzerschnittstellen

Konzepte von MiReAS

Das zentrale Konzept von MiReAS ist das Prinzip des

”

Actors & Adap-

tors“. Akteure (engl. Actors) sind aktive Elemente einer Anwendung,

die in einem Szenario betrachtet und gesteuert werden sollen. F

ur eine

149

MIXED REALITY IN THE LOOP

typische Mixed Reality Anwendung sind dies Eingabeger

ate sowie

interaktive und/oder dynamische Szenenelemente. Im Kontext von

Mixed Reality sind hier sowohl virtuelle als auch reale steuerbare

Systeme als Akteur zu verstehen. Die Grundlagen zum Akteurmodell

k¨

onnen in Kapitel 4.3.3120 nachgelesen werden.

Actor2

InputA<float>

InputB<Vector>

InputC<Matrix>

OutputA<float>

OutputB<Object>

Actor1

OutputA<Matrix>

OutputB<Vector>

OutputC<float>

Actor3

InputA<float>

InputB<Vector> OutputA<Matrix>

Actor4

InputA<Matrix>

InputB<Vector>

InputC<Matrix>

OutputA<float>

Inkompatible

Datentypen

Mehrfach

verbundener

Eingang

Abbildung 4.27: Datenflussnetzwerk basierend auf Akteure.

In MiReAS sind Akteure in der Lage, Steuer-und Informationsdaten

uber Ports zu senden beziehungsweise zu empfangen. Ports k

onnen

dabei einen beliebigen Datentyp annehmen, z. B. vektorielle Werte f

zusammenh¨

angende Daten oder skalare Werte f¨

ur einzelne Datenlei-

tungen. Selbst komplexe Objekte k

onnen als Datentyp verschickt bzw.

empfangen werden. Die Ports k

onnen beliebig miteinander verschaltet

werden, allerdings m

ussen die jeweiligen Datentypen des Ein- und

Ausgangs kompatibel sein. Ein Ausgangsport kann mit mehreren Ein-

gangsports verbunden werden, Eingangsports k

onnen indes nur mit

einem Ausgangsport verbunden sein. In jedem Zeitschritt aktualisiert

ein Akteur seinen Zustand indem er die Werte an seinen Eingangs-

ports liest, diese verarbeitet und die neu berechneten Werte an seine

Ausgangsports anlegt. Damit ist es m

oglich ein interaktives Daten-

flussnetzwerk aufzubauen, welches das Verhalten der Anwendung

steuert. In Abbildung

4.27

ist so ein Datenflussnetzwerk zu sehen.

Hier wird des Weiteren dargestellt, dass weder zwei Ports miteinander

verbunden werden k

onnen, die inkompatible Datentypen haben, noch

Ausg¨

ange mehrfach belegt werden d¨

urfen.

Akteure, die

uber die gleichen Ein- und Ausgangsports verf

ugen,

onnen problemlos untereinander ausgetauscht werden. So k

onnen

z. B. Prototypen von Akteuren entwickelt werden, die ein bestimmtes

Portinterface bieten und direkt in die Software eingebunden werden.

Im Laufe der Entwicklung k

onnen diese Prototypen mit neueren bzw.

anderen Versionen von Akteuren getauscht werden, ohne das das

150

4.5 DIE SOFTWAREUMGEBUNG

Datenflussnetzwerk ge¨

andert werden muss.

VelocityMeter

Propeller

PhysicalActor

ForceAtCenter<float[]>

AngularVelocity

<float>

f(x)

TorqueAtCenter<float[]> Pose<Matrix4x4>

Position<Vector3>

Orientation<Vector3>

Position

Orientation

Power

<float>

Parameter

LinearVelocity

<float>

Abbildung 4.28: Kopplung zwischen einem Akteur und Adaptern.

Ein bereits implementierter Akteur kann durch sogenannte Adapter

(engl. Adaptors) erweitert werden. Adapter haben ebenso wie Akteu-

re eine Menge an Eingangs- und Ausgangsports. Wird ein Adapter

einem Akteur zugewiesen, erh

alt der Akteur s

amtliche Ports des Ad-

apters. Diese Ports k

onnen dann von außen so angesprochen werden,

als wenn sie Teil des jeweiligen Akteurs w

aren. Um die Ports des

Adapters mit den Ports des Akteurs zu verbinden, muss eine entspre-

chende Funktionalit

at in den Adapter implementiert werden. Beispiele

ur Adapter w

aren zum einen, inkompatible Ports miteinander zu

verbinden, indem der Adapter intern eine Umwandlung durchf

uhrt

und die gewandelten Signale an die entsprechenden Eingangsports

des Akteurs bzw. die Ausgangsports des Adapters weiterleitet. Die

grunds

atzliche Funktionalit

at von Adaptern kann in Kapitel

4.3.3120

nachgelesen werden.

Der Vorteil eines Adapters gegen

uber einer Vorschaltung bzw. Nach-

schaltung eines neuen Akteurs ist die automatische Verschaltung.

Verbindungen m

ussen nicht neu gesetzt werden, was vor allem bei

mehrfachem Verwenden von Adaptern der

Ubersichtlichkeit des Da-

tenflussnetzwerk dient.

Dieses Konzept gestattet komplexe, aufeinander aufbauende Struk-

turen, die aus einfachen, wiederverwendbaren Einzelkomponenten

zusammengesetzt sind. In einer ersten Iteration des MRiL-Prozesses

kann ein Akteur z. B. ein einfaches physikalisches Objekt ohne spezi-

elle Funktionen sein, d. h. ein physikalisches K

orper mit Eing

angen

ur Kraft und Drehmoment sowie Ausg

angen f

ur Positionsinforma-

tionen. Durch das Aufsetzen eines eingangsseitigen Adapters f

ur die

Simulation eines Propellers mit Eing

angen f

ur Position und Orientie-

rung sowie angelegte Energie wird aus dem einfachen physikalischen

orper ein aktiv steuerbares System. Durch einen ausgangsseitigen

151

MIXED REALITY IN THE LOOP

Adapter kann z. B. ein Sensor zur Geschwindigkeitsmessung aufge-

setzt werden. Dieses einfache Beispiel f

ur eine Kopplung zwischen

einem Akteur und einem Adapter ist in Abbildung

4.28

zu sehen.

Andere Arten von Adaptern sind z. B. Typkonvertierungen f

ur in-

kompatible Ports, Erweiterungen f

ur intelligente Steuerungen (z. B.

Reglersteuerungen, etc.) oder alle Arten von Sensoren und Akteuren.

Abbildung 4.29: Das Plug-in-System von MiReAS.

Ein weiteres Konzept von MiReAS ist ein flexibles Plug-in-System,

welches erlaubt, alle ben

otigten Komponenten separat zu implemen-

tieren, einzubinden und zu nutzen. Da Plug-ins zur Laufzeit geladen

werden k

onnen, wird mit ihnen das modulare Konzept sowie die

Erweiterbarkeit von MiReAS unterst

utzt. F

ur die gr

oßtm

ogliche Flexi-

bilit

at sind sowohl der 3D-Renderer als auch die Trackingsysteme bzw.

Videoger

ate als Plug-in realisiert und k

onnen w

ahrend der Laufzeit

geladen werden. Auch Akteuren oder Adapter sind

uber Plug-ins

realisiert. Somit ist auch die Entwicklung von Anwendungen in einem

großen Team m

oglich, da sich die einzelnen Programmierer nur auf

ihre Plug-ins konzentrieren m¨

ussen.

MiReAS unterscheidet zwischen zwei Arten von Plug-ins. System-

Plug-ins, die essenziell f

ur die Funktionalit

at sind und Erweiterungs-

Plug-ins, mit denen vor allem Szenenelemente und Funktionserwei-

terungen f

ur bestimmte Aufgaben erstellt werden k

onnen. Unter die

System-Plug-ins fallen Komponentien wie der 3D Renderer, Tracker

und Videoquellen, wobei Akteure, Adapter und Sensoren unter die

Erweiterungs-Plug-ins fallen.

Damit die unterschiedlichen systeminternen sowie extern-angebun-

denen Komponenten innerhalb eines einzelnen Simulationsschrittes

aktualisiert werden k

onnen, wurde MiReAS mit einem dreistufigen

Simulationszyklus realisiert. Dies geschieht indem die Akteure, die

uber Ports miteinander verbunden sind, ihre Ausgabeports erst am

Ende eines Simulationsschrittes aktualisieren. Diese Technik vermei-

det, dass die Reihenfolge der einzelnen Aktualisierungen eine Aus-

152

4.5 DIE SOFTWAREUMGEBUNG

Simulationszyklus

preUpdate

Update Physics

Update Video

Update Tracker

Update postUpdate

Update States Update Ports

Update Frame

Zeitschritt

Abbildung 4.30: Der Simulationszyklus von MiReAS

wirkung auf die Simulation hat. Anders ist dies bei Berechnungen,

die noch im selben Frame visualisiert werden sollen, wie z.B. Phy-

sikberechnungen. Diese Berechnungen m

ussen vor dem aktuellen

Frame behandelt werden. F

ur eine gr

oßtm

ogliche Flexibilit

at wurde

deshalb ein Simulationszyklus wie in Abbildung

4.30153

entworfen.

Jede Komponente, die in diesen Simulationszyklus eingebunden wird,

kann in jedem dieser drei Abschnitte Funktionalit

at hinterlegen. Es

sollte allerdings weiterhin die M

oglichkeit geben, innerhalb dieser

Zykluselemente Priorit

aten zu vergeben, um einen m

oglichst verz

oge-

rungsfreien Ablauf der Simulation zu gew

ahrleisten. Daher wurde z. B.

eine Visualisierung als letzte Phase im Simulationszyklus realisiert.

Um Rapid Prototyping zu unterst

utzten, wurde eine geeignete Metho-

de zur Konfiguration der Anwendung durch den Entwickler realisiert,

die ohne großen Programmieraufwand m

oglich ist. Es m

ussen le-

diglich die ben

otigten Akteure und Adapter einmal implementiert

werden. Die Basis dieser Konfiguration bildet ein hierarchisches Da-

tenmodell, welches im XML-Format abgelegt werden kann. Eine Szene

wird durch einen Szenegraph abgebildet, in der alle Akteure, Adapter

und Ger

ate samt Einstellungen integriert sind. Ben

otigte Dateien wer-

den in einer eigenen Ordnerstruktur abgelegt. Ist eine erste Iteration

erfolgreich abgeschlossen, kann die n

achste Iteration direkt auf der

bisherigen XML-Datei aufbauen und ben

otigte

Anderungen direkt

implementieren.

In der derzeitigen Entwicklung befindet sich eine grafische Benutzero-

berfl

ache, die den Zugriff auf alle Systemkomponenten erlaubt, um die

Konfiguration des Systems noch benutzerfreundlicher zu gestalten.

153

MIXED REALITY IN THE LOOP

Abbildung 4.31: Konfiguration ¨

uber XML.

Systemstruktur von MiReAS

ur die Implementierung des MiReAS-Systems wurde C++ als Pro-

grammiersprache gew

ahlt. Das Design der Applikation wurde ob-

jektorientiert ausgelegt, so dass die n

otigen Komponenten modular

programmiert werden konnten. Eine Reihe Opensource-Bibliotheken,

die Basisfunktionalit

aten zur Verf

ugung stellen, wurden genutzt um

den Implementierungsaufwand zu begrenzen. Bei der Auswahl wurde

darauf geachtet, dass eine freie Verwendung sowie eine eventuelle

anderung der Bibliotheken m

oglich ist. Auch sollten die Biblio-

theken plattform

ubergreifend verwendet werden k

onnen. Entwickelt

wurde das System jedoch vollst

andig auf einer Windows-Plattform,

so dass eine Portierung auf ein anderes System zwar m

oglich ist,

allerdings nicht entwickelt wurde.

Die verschiedenen Funktionen von MiReAS wurden in eigenen dy-

namischen Bibliotheken implementiert, um so eine hohe Modula-

rit

at des Systems zu gew

ahrleisten. Die Bibliotheken k

onnen daher

unabh

angig voneinander entwickelt werden, solange die Schnittstel-

154

4.5 DIE SOFTWAREUMGEBUNG

len gleich bleiben. Beispielsweise werden die Grundfunktionen ei-

niger Bibliotheken, z. B. der Physik- und der Input-Bibliothek,

uber

Opensource-Bibliotheken realisiert, die bei Bedarf durch andere Bi-

bliotheken ausgetauscht werden k¨

onnen.

mireas::ApplicationLayer

ConsoleApplication GUIApplication

Application

mireas::LibraryLayer

Network Physics

Core

InputBase

Externe Komponenten (Opensource Bibliotheken)

FLTK

Poco

PAL

gmtl

OIS

Abbildung 4.32: Die Systemstruktur von MiReAS

In Abbildung

4.32

wird die Softwarestruktur von MiReAS dargestellt.

Die externen Komponenten, die

uber Opensource-Bibliotheken reali-

siert sind, bieten bereits fertige Strukturen, die von MiReAS genutzt

werden, z. B. die Unterst

utzung von unterschiedlichen Eingabeger

aten,

eine Physiksimulation, mathematische Funktionen und eine 2D-GUI-

Bibliothek. Das eigentliche MiReAS-System kann in zwei Kompo-

nenten geteilt werden: den Library-Layer und den Applications-Layer.

Der Library-Layer beinhaltet die gesamte Simulationslogik und ist in

die Bibliotheken Base,Input,Core,Physics und Network unterteilt. Der

Applications-Layer enth

alt die ausf

uhrbaren Anwendungen. Je nach

Wunsch des Anwenderprogrammierers kann die fertige Applikation

von einer Konsolenanwendung (ConsoleApplication), die durch eine

XML-Konfigurationsdatei erstellt wird, oder eine Applikation mit gra-

fischer Benutzeroberfl

ache (GUIApplication) abgeleitet werden. Dabei

bietet die GUI eine flexiblere M

oglichkeit zum Eingriff in das laufende

Programm und kann zur Laufzeit nachkonfiguriert werden. In der

Bibliothek Application werden gemeinsam verwendete Funktionen,

wie z. B. das Konfigurationssystem implementiert.

Es wurden folgende externe Opensource-Bibliotheken f

ur die Ent-

155

MIXED REALITY IN THE LOOP

wicklung von MiReAS genutzt:

POCO (Portable Components):

Eine Bibliothek f

ur die Entwicklung

von portablen, netzwerkzentrierten Anwendungen. Implemen-

tiert sind z. B. ein Threadsystem, ein System zum Laden von dy-

namischen Bibliotheken, Sockets und Netzwerkprotokollen, ein

Konfigurationssystem und ein XML-Parser [

Obi10

]. In MiReAS

wurde gerade das System zum Einlesen von Konfigurationsin-

formationen aus XML-Dateien intensiv genutzt.

GMTL (Generic Math Template Library):

Eine mathematische, auf

Template-Klassen basierende Bibliothek, die Funktionen der li-

nearen Algebra zur Verf

ugung stellt [

BMS10

]. Diese werden

vor allem in 3D-Anwendungen ben

otigt. Des Weiteren bein-

haltet GMTL allgemeine mathematische Funktionen, die platt-

form¨

ubergreifend dieselbe Funktionalit¨

at bieten.

OIS (Object-Oriented Input System):

Eine Bibliothek zur Abstrakti-

on von Plattform-Schnittstellen. OIS bietet die M

oglichkeit der

Abstraktion s

amtlicher Standard-Eingabeger

ate wie z. B. Tasta-

tur, Maus oder Joystick [

Cas10

]. Weitere Eingabeger

ate, die z. B.

ur Mixed Reality Anwendung ben

otigt werden, k

onnen

uber

OIS einfach integriert werden. OIS wurde f

ur die Verwendung in

MiReAS durch eigene Input-Handler erweitert, z. B. eine bessere

Anbindung an die Nintendo Wiimote.

PAL (Physics Abstraction Layer):

Bibliothek zur Abstraktion physi-

kalischer Simulationen [

Boe09

]. In PAL erm

oglicht die Nutzung

eine Vielzahl von Physik-Bibliotheken innerhalb einer einzel-

nen Anwendung. Die einzelnen Physik-Bibliotheken m

ussen

jeweils als Plug-in vorhanden sein bzw. als PAL-Plug-in imple-

mentiert worden sein. Somit besteht eine große Flexibilit

at bei

der Auswahl der Physik-Bibliotheken. Nachteil der Abstrakti-

on ist jedoch die fehlende Unterst

utzung spezieller Merkmale

bestimmter Physik-Bibliothek, es k

onnen nur allgemeine Funk-

tionen genutzt werden. In MiReAS wird das PAL-Plug-in der

BulletEngine als Standard Bibliothek genutzt [Cou10].

FLTK (Fast Light Toolkit):

Eine Bibliothek, die eine plattformunab-

angige grafische Benutzerschnittstelle bereitstellt [

Spi10

]. Die

Bibliothek basiert auf OpenGL und

uber den integrierten Desi-

gner FLUID (

ast

ight

ser-

nterface

esigner) k

onnen Benut-

zerschnittstellen sehr schnell grafisch erstellt werden.

Diese Bibliotheken sind auch in der Abbildung

4.32155

zu sehen und

werden von den verschiedenen Layern in der MiReAS Architektur

156

4.6 ZUSAMMENFASSUNG

genutzt. Alle verwendeten Bibliotheken stehen unter einer Open-

Source-Lizenz, z. B. GPL, LGPL, Boost License, etc., und sind somit

allgemein zug

anglich und

anderbar. Des Weiteren wurde darauf ge-

achtet, dass die verwendeten Bibliotheken f

ur mehrere Betriebssyste-

me zur Verf

ugung stehen, so dass eine Cross-Plattform Tauglichkeit

grunds¨

atzlich vorstellbar ist.

Weitere Einzelheiten zur Implementierung k

onnen in der Master-

Arbeit von Patrick Pogscheba nachgelesen werden [Pog09].

4.6 Zusammenfassung

In diesem Kapitel wurde beschrieben, was das MRiL-Entwurfsvor-

gehen ist und wie es anwendet werden kann. Zu Beginn wurden die

Vorraussetzungen definiert, die ben

otigt werden, damit das MRiL-Ent-

wurfsvorgehen erfolgreich bei einer Applikationsentwicklung ange-

wendet werden kann. Dabei ist es wichtig, dass die zu entwickelnde

Anwendung in die MVCE-Komponetnen aufgeteilt werden kann und

aus einem der Bereiche Mixed Reality Applikationen, Mixed Reality

Benutzerschittstellen oder mechatronische Systeme stammt. Diese An-

wendungen lassen sich sehr gut durch das MRiL-Entwurfsvorgehen

entwickeln.

Nach Kl

arung der Voraussetzungen wurde auf grobe Vorgehenswei-

se des MRiL-Entwurfsvorgehens eingegangen. Hier wurde gezeigt,

wie ein Entwickler erfolgreich den Prozess an seiner Applikation an-

wenden kann. Die einzelnen Schritte bei der Entwicklung wurden

beschrieben und erkl¨

art.

Der Vorgehensweise folgte die Beschreibung der f

ur das MRiL-Ent-

wurfsvorgehen entwickelten Methoden. Dazu geh

orte das MVCE

Architekturmuster, das die Anwendung in vier verschiedene Kompo-

nenten einteilt und es erm

oglicht, diese Komponenten unabh

angig

von einander zu entwickeln bzw. verfeinern. Die MRiL-Metrik erlaubt

eine Bewertung des Entwicklungsstaus der Applikation anhand der

MVCE Komponenten.

Uber das Akteurmodell wurden dann verschie-

dene Teile der Applikation nochmals gekapselt. Akteure sind eine

Verfeinerung des MVCE Architekturmusters und teilen die jeweiligen

Komponenten in kleinere autarke Teile auf. Daraufhin wurde das Ent-

wurfsvorgehen nochmals in allen Details beschrieben und erkl

art, wie

das MRiL-Entwurfsvorgehen verwendet wird. Diese Akteure lassen

sich konzeptionell mit Hilfe von Adaptern erweitern um so eine Ver-

feinerung der Komponenten mit geringem programmiertechnischen

Aufwand zu bew¨

altigen.

157

MIXED REALITY IN THE LOOP

Das Entwurfsvorgehen beschreibt den iterativen Entwurfsprozess. Ab-

strakt gesehen werden die Phasen Konzeption, Implementierung, Tests

und Bewertung durchlaufen und ggf. wiederholt. Konkret wird in

jeder Initialisierungsphase des MRiL-Entwurfsvorgehens der nachfol-

gende Verfeinerungsschritt geplant. In der Verfeinerugsphase werden

die

Anderungen implementiert und so die Komponenten bzw. Ak-

teure verfeinert. Nach der Verfeinerung entsteht ein neuer Prototyp,

der

uber funktionale Tests oder Benutzertests validiert und analysiert

wird. Hier entscheidet sich, ob eine weitere Iteration n

otig ist oder

ob der Prototyp funktional fertig ist. Sollte eine weitere Iteration vor-

genommen werden, werden in der Bewertungsphase die Ziele des

n¨

achsten Prototypen festgelegt.

Damit der MRiL Prozess softwaretechnisch unterst

utzt wird, wurden

zwei unterschiedliche Softwareumgebungen entwickelt. Als erstes

wurde die propriet

are Entwicklungsumgebung Virtools dahingehend

erweitert, dass der MRiL Prozess zum gr

oßten Teil abgebildet werden

konnte. Hierf

ur wurden mehrere Plug-ins entwickelt, die u. a. das

Tracking, Benutzung neuer Eingabeger

ate und die Interapplikations-

Kommunikation erm

oglichten. Damit konnte das MRiL-Entwurfsvor-

gehen angewendet werden, da die Anwendung in die entsprechenden

MVCE-Komponenten aufgeteilt und diese Komponenten dann ver-

feinert werden konnte. Leider konnte das Prinzip der Akteure nicht

in Virtools umgesetzt werden, da es keine M

oglichkeit gab, dieses

abzubilden. Aus diesem Grund wurde eine komplett neue Softwa-

reumgebung, die speziell auf das MRiL-Entwurfsvorgehen angepasst

war, entwickelt. MiReAS wurde auf Opensource-Bibliotheken entwi-

ckelt und bietet alle M¨

oglichkeiten, die das MRiL-Entwurfsvorgehen

ben

otigt, vom MVCE Architekturmuster bis hin zur Akteurmodell.

Letzteres ist in MiReAS ein zentraler Punkt bei der Entwicklung, da

jede Komponente der Applikation

uber einen Akteur abstrahiert wird.

Damit Akteure verfeinert werden k

onnen und nicht immer von Grund

auf neu implementiert werden m

ussen, wurde das Prinzip des Ad-

apters, der einen Akteur mit neuer Funktionalit

at kapseln kann, in

MiReAS realisiert.

In diesem Kapitel wurde somit das komplette MRiL-Entwurfsvor-

gehen mit der entsprechenden Softwareumgebung vorgestellt und

erl

autert. Im folgenden Kapitel wird nun gezeigt, wie der MRiL Pro-

zess an einem nicht trivialen Beispiel erfolgreich eingesetzt wurde.

Es werden die einzelnen Schritte der Entwicklung vorgestellt und es

wird auf auftretende Probleme hingewiesen.

158

KAPITEL 5

Beispiel

Nach der Vorstellung des MRiL-Entwurfsvorgehes im letzten Kapitel

konzentriert sich dieses Kapitel auf die Anwendung von MRiL auf

ein nicht triviales Beispiel. Als Softwaregrundlage diente hier das

Werkzeug MiReAS

4.5.2148

unter Verwendung u. a. des Akteurmo-

dells und des Prinzip des Adapters

4.3.3120

. In diesem Kapitel wird

detailliert die Entwicklung der Prototypen dieser Beispielapplikation

beschrieben und jede Iteration der Entwicklung erl

autert. Insgesamt

wurden w

ahrend der Entwicklung sieben Prototypen entwickelt, die

jeweils eine geforderte Funktionalit

at implementierten. Angefangen

von einer sehr einfachen, abstrakten Applikation, die die Funktions-

weise verdeutlichen soll, bis hin zu komplexen Prototypen, die f

Tests einer speziellen Auspr

agung der Applikation verwendet wurden.

Am Ende wurde ein Prototyp entwickelt, der als fertige Applikation

bezeichnet werden kann.

5.1 ¨

Uberblick

An der Fachhochschule D

usseldorf wurde im Fachbereich Elektro-

technik ein ferngesteuerter Indoor-Zeppelin zu Forschungszewecken

aufgebaut. In Kooperation mit der VR-Abteilung des Fachbereich

Medien der Fachhochschule D

usseldorf sollten im Rahmen des Pro-

jektes MoVeIT (Mobilit

at, Verteilung und Interaktion: Realisierung

einer Testumgebung f

ur Multimediaanwendungen) neue, intuitive

Steuerstrategien f

ur diesen Zeppelin entwickelt werden. F

ur die Ent-

wicklung dieser Strategien sollte das in dieser Arbeit vorgestellte

MRiL-Entwurfsvorgehen angewendet und mit Hilfe von MiReAS

159

BEISPIEL

realisiert werden.

Die Idee f

ur die Entwicklung neuer Steuerstrategien entstand aus der

Tatsache, dass die normale Steuerung des Zeppelins mit Hilfe einer

Funkfernsteuerung kompliziert und schwer zu erlernen ist. Das liegt

zum einen an den wenigen Freiheitsgraden, die durch die Bauweise

des Zeppelins gegeben sind, und zum anderen durch die Tr

agheit des

Zeppelins. Um ihn pr

azise und genau zu steuern ist es f

ur den Be-

nutzer wichtig, die zu erzielende Bewegung in richtigen Bewegungen

der einzelnen Freiheitsgrade des Zeppelins aufzuspalten, dabei die

Tr¨

agheit mit zu ber¨

ucksichtigen und ggf. gegenzusteuern. Die ersten

Versuche, den Zeppelin kontrolliert zu steuern, wurden deshalb in

einer großen Halle durchgef

uhrt, um die Kollisionsgefahr mit Hinder-

nissen zu minimieren. Nach mehreren Stunden intensiver

Ubung war

schließlich ein Benutzer in der Lage, den Zeppelin halbwegs sicher zu

fliegen.

Um auch einer gr

oßeren Gruppe an Benutzern die Bedienung des

Zeppelins zu erm

oglichen, war die Idee, die klassische Steuerung des

Zeppelins durch eine neue, intuitivere Steuerung zu ersetzten. Da die

Umsetzung einer neuen intuitiven Steuerung sehr of das

”

Trail-and-

Error“-Prinzip verwendet, gerade wenn es sich um das Finetuning

bestimmter Parameter der Steuerung handelt, war der Einsatz des

realen Zeppelins f

ur diese Tests schon von Beginn an ausgeschlos-

sen. Durch unsachgem

aße Handhabung kann der Zeppelin schnell

besch

adigt oder zur Gefahr f

ur Personen werden, so dass die Entwick-

lung einer neuen Steuerung pr

adestiniert f

ur eine VR Simulation ist.

Des Weiteren gab es viele Ideen einer intuitiven Steuerung, so dass

mehrere dieser Ideen getestet werden sollten. Auch hier war eine VR

Simulation die beste L¨

osung.

Zu diesem Zeitpunkt entstand die Idee das MRiL-Entwurfsvorgehen

zu verwenden und die Prototypen mit Hilfe der MiReAS-Software zu

entwickeln. Die

Uberlegung war, erst eine sehr einfache Applikation

zu entwickeln, die grob das Verhalten des Zeppelins simuliert, um

so Steuerstrategien mit diesem Prototypen entwickeln und testen zu

onnen. Um in weiteren Entwicklungsschritten auf den vorherigen

Prototypen aufzubauen, wurde MiReAS dazu verwendet, langsam die

VR-Komponenten in MR bzw. reale Komponenten zu ersetzten. So

konnte die Steuerung immer feiner getestet werden, erst an einfachen,

sp¨

ater an komplexen Simulationen sowohl virtuell als auch real.

ur die Berechnung der Metriken war es notwendig, den endg

ultigen

Prototypen der Anwendung zu spezifizieren. Das war in allen Berei-

chen nicht sehr kompliziert, da schon der reale Zeppelin existierte

und die Applikation diesen steuern sollte.

Uber die Metriken war eine

160

5.1 ¨

UBERBLICK

Einsch

atzung des Entwicklungsstatus mit Hilfe des Kiviatgraphen

oglich. F

ur die Controller-Metrik wurden allerdings keine groß ange-

legten Benutzertests durchgef

uhrt, da hier die Zeit und die Personen

fehlten. Es wurden hier nur die Aussagen der Entwickler ber

ucksich-

tigt um so eine Einsch

atzung der verwendeten Controller-Strategie zu

erhalten.

Insgesamt wurden f

ur dieses Beispiel zehn aufeinander aufbauende

Prototypen entwickelt und getestet, wobei zwei Beispiele nur kon-

zeptionell entwickelt wurden, da hier die Hardware, die eingesetzt

werden sollte, nicht rechtzeitig fertiggestellt werden konnte. Alle Pro-

totypen wurden aufeinander aufbauend entwickelt und mit Hilfe von

dem Werkzeug MiReAS realisiert.

5.1.1 Der Zeppelin

Abbildung 5.1: Modell des Zeppelins.

Das Modell des Zeppelins (Abbildung

5.1

, hier beim Testen des AR-

Prototypen mit Markern) besteht aus einer speziellen Kunststoffh

ulle

mit einer L

ange von drei Metern und einem Durchmesser von einem

Meter. Bef

ullt wird die H

ulle mit Helium, was den erforderlichen

Auftrieb des Zeppelins liefert. Dabei betr

agt die Tragkraft des Zep-

pelins exklusiv der Elektronik und der Motoren ca. 250 Gramm. Am

Heck des Zeppelins befindet sich ein Propeller, der sich

uber einen

DC-Motor rechts bzw. links drehen l

asst. Unten an der H

ulle ist ei-

ne Gondel befestigt, die die Bordelektronik fasst. An beiden Seiten

161

BEISPIEL

der Gondel befindet sich jeweils ein weiterer Propeller, der auf einer

drehbaren Achse gelagert ist.

yaw

roll pitch

b c

Abbildung 5.2: Der Zeppelin im Detail.

Der Propeller am Heck des Zeppelins (Abbildung

5.2

– c) ist f

das Gieren

zust

andig und kann

uber den DC-Motor in beide Rich-

tungen betrieben werden. Die beiden Schubmotoren an der Gondel

(Abbildung

5.2

– b) erm

oglichen die Bewegung in der Ebene, die von

der Gierachse und der Rollachse

aufgespannt wird, also vorw

arts,

uckw

arts, aufw

arts oder abw

arts. Beide Schubmotoren sind

uber eine

Drehachse miteinander verbunden, die je nach Stellung die Schub-

richtung der Propeller vorgibt. Dabei ist die Drehung um diese Achse

auf 360

◦

beschr

ankt (aus der Normalstellung die horizontal nach

vorne zeigt, jeweils 180

◦

in beide Richtungen). Beide Schubmotoren

erm¨

oglichen eine maximale Geschwindigkeit von ca. 6, 1m

Die Gierachse, auch Hoch- bzw. Vertikalachse (engl. yaw axis), bezeichnet die vertikale Achse eines

Luftfahrzeugs, um die sich das Fahrzeug dreht. Als Gieren bezeichnet man eine Drehbewegung um

diese Achse. In Abbildung 5.2 – a sind die Achsen zur Verdeutlichung in den Zeppelin eingezeichnet.

2Die Rollachse (engl. roll axis) wird auch als L¨

angsachse bezeichnet.

162

5.2 PROTOTYPENENTWICKLUNG

Abbildung 5.3: Handels¨

ubliche 4-Kanal Funkfernbedienung.

In der Gondel befindet sich eine Platine mit der Bordelektronik, die

aus der Motorsteuerung sowie der Kommunikation mit der Fernbedie-

nung besteht. Wie im Flugzeug-Modellbau

ublich wird der Zeppelin

uber eine handels

ubliche 4-Kanal Fernbedienung, wie in Abbildung

5.3163

zu sehen, gesteuert.

Uber die einzelnen Hebel der Fernbedie-

nung k

onnen der Heckrotor, die Drehachse und die beiden Schub-

motoren gesteuert werden. Beide Schubmotoren sind miteinander

gekoppelt, so dass sie nur gemeinsam steuerbar sind. Daraus ergibt

sich, das drei der vier Kan

ale der Fernbedienung mit Funktionen

belegt sind. Der linke Hebel ist vertikal f

ur die Steuerung der Schub-

motoren belegt, der rechte Hebel ist vertikal f

ur f

ur den Winkel der

Schubmotoren zust

andig. Des Weiteren ist der linke Hebel auf der ho-

rizontalen Achse f

ur den Heckmotor verantwortlich. Die horizontale

Achse des rechten Hebels ist nicht belegt.

5.2 Prototypenentwicklung

Wie schon im

Uberblick erw

ahnt, bedarf es einer gewissen Erfahrung,

den Zeppelin pr

azise zu steuern. Die korrekte Steuerung der drei

beschriebenen Freiheitsgrade (Rotation und Translation in einer Ebe-

ne) gelingt aufgrund der Tr

agheit des Zeppelins nur mit viel

Ubung.

Selbst kleinste Impulse der einzelnen Rotoren k

onnen große Auswir-

kungen auf die Bewegung des Zeppelins haben. Daher ist ein h

aufiges

Gegensteuern f¨

ur exakte Man¨

over unumg¨

anglich.

Bei der Prototypentwicklung sollen nun verschiedene Techniken ent-

163

BEISPIEL

wickelt werden, die die Steuerung des Zeppelins vereinfachen und

auch f

ur unge

ubte Benutzer anwendbar sind. Die Kommandos an die

einzelnen Rotoren sollen durch eine High-Level Steuerung abstrahiert

werden, so dass sich der Zeppelin durch einfach Befehle wie beispiels-

weise ”Vorw¨

arts“, ”R¨

uckw¨

arts“, ”Aufw¨

arts“ oder ”Abw¨

arts“ steuern

asst. Die Fernsteuerung soll weiterhin durch andere Eingabeger

ate

ersetzt werden, die eine intuitivere Steuerung des Zeppelins verspre-

chen, beispielsweise Gestensteuerung oder Stellvertreterobjekte.

Da die Arbeit am realen Zeppelin einerseits mit hohen laufenden

Kosten

verbunden ist und andererseits durch die Kooperation der

FH D

usseldorf und der Universit

at Paderborn der Zeppelin nicht an

beiden Standorten verf

ugbar war, sollte die Entwicklung mit Hilfe

einer Simulation durchgef

uhrt werden. Die zu entwickelnden Steu-

erstrategien sollten erst an der Simulation getestet und sp

ater dann

auf den realen Zeppelin

ubertragen werden. Diese Schritte sollten mit

Hilfe des MRiL-Entwurfsvorgehens realisiert und unter Verwendung

des Werkzeuges MiReAS implementiert werden.

Die folgenden Abschnitte beschreiben die iterative Entwicklung der

zehn Prototypen mit Hilfe des MRiL-Entwurfsprozesses am Beispiel

des Zeppelins. Dabei wurden alle Prototypen mit Hilfe des MiRe-

AS Frameworks entwickelt. Bis auf die letzten drei Prototypen, die

nur konzeptionell entwickelt wurden, sind alle Prototypen komplett

lauff¨

ahig.

5.2.1 Die Initialphase

Zu Beginn der Initialisierungsphase wurde die endg

ultige Applikation

in schriftlicher Form festgehalten, um so eine Basis f

ur die Entwick-

lung zu erhalten. Die schriftliche Ausarbeitung, die dem ersten Schritt

der Vorgehensweise aus Kapitel

4.2101

entspricht, wurde so detailliert

wie m

oglich verfasst, um die Entwicklung zu vereinfachen und die

Berechnung der Metriken zu erm

oglichen00. Aus der schriftlichen

Form wurden im folgenden Schritt die einzelnen Teile der Appli-

kation identifiziert und in die einzelnen Komponenten des MVCE

Architekturmusters eingeordnet. Diese erste Einteilung war eine sehr

grobe Einteilung der Komponenten, die allerdings sowohl f

ur die

Entwicklung als auch f

ur die Berechnung der einzelnen Werte der

Metrik ausreichte.

Daraus entstand die unten angegebene Tabelle mit den folgenden

Komponenten:

Da durch die Kunststoffh

ulle des Zeppelin leider immer etwas Helium diffundiert, muss sie h

aufig

nachgef¨

ullt werden, eine F¨

ullung mit Helium kostet derzeit ca. 40,00 e.

164

5.2 PROTOTYPENENTWICKLUNG

Komponente MVCE-Kategorien

Zeppelin Modell, View

Steuerung Controller, View

Umgebung Environment, Modell, View

Metadaten View

, Modell, Controller, Envi-

ronment

Aus der obigen Tabelle ist ersichtlich, in welche Kategorien die ein-

zelnen Komponenten der Applikation fallen. Dabei entsprechen die

hervorgehobenen Komponenten der prim

aren MVCE-Kategorie, der

sie zugeordnet werden. Der Zeppelin muss dementsprechend als Mo-

dell vorliegen, um das Verhalten abzubilden, sollte aber auch eine

visuelle Repr

asentation besitzen. Die Steuerung wird im Controller

abgebildet, kann jedoch auch eine visuelle Repr

asentation haben. Die

Umgebung ist sowohl dem Environment zugeordnet, da wir keinen

Einfluss in der Software auf Ereignisse der Umgebung haben, kann

aber auch eine Entsprechung im Modell und im View haben, wenn

in sp

ateren Prototypen die Daten der Umgebung zur Kollisionser-

kennung benutzt werden sollen. Die Metadaten stehen in diesem

Zusammenhang f

ur z. B. Debuginformationen, die in allen Kategorien

erzeugt werden k¨

onnen und im View visualisiert werden sollen.

Nach der ersten groben Einteilung der Komponenten kann nun mit

der Arbeit am ersten Prototypen begonnen werden. Zun

achst werden

alle Akteure des ersten Szenarios identifiziert. Das erste Szenario soll

einfach gehalten werden und zur Planung und Kommunikation des

Entwicklungsteams dienen. Des Weiteren soll die Entwicklung des

ersten Prototypen schnell und unkompliziert sein. So sind im ersten

Szenario wenig Akteure und auch der View und der Controller sind

einfach gehalten. Die Umgebung ist rein virtuell und basiert weder

auf simulierten noch auf realen Daten der echten Umgebung. Eine

Interaktion mit der Umgebung ist nicht vorhanden, sie besitzt nur eine

visuelle Repr

asentation. Das Modell des Zeppelins ist repr

asentiert

durch eine Transformation, die das visuelle Modell des Zeppelins

in der virtuellen Welt positioniert. Die Steuerung erfolgt

uber die

Tastatur des Rechners.

Es wurden somit f

ur das erste Szenario die aufgef

uhrten Akteure

definiert, die in der nachfolgenden Tabelle angegeben sind:

165

BEISPIEL

Akteur Modell View

Controller Environm.

Zeppelin × ×

Umgebung ×

Tastatur ×

ur die Einordnung des Prototypen und die Aussage

uber den Ent-

wicklungsstand m

ussen die Metriken, die in Kapitel

4.3.2109

definiert

wurden, berechnet werden. Dazu ist es notwendig eine Definition

der endg

ultigen Applikation zu erstellen. Dies wurde schon im ers-

ten Schritt in schriftlicher Form realisiert, so dass jetzt nur noch die

jeweiligen MVCE-Komponenten extrahiert und beschrieben werden

ussen. Dies wurde f

ur die Modell-Metrik

ΓM

, die View-Metrik

ΘV

und die Environment-Metrik ΩEdurchgef¨

uhrt.

In den nun folgenden Tabellen werden die Komponenten, die aus-

schlaggebend f

ur die finale Version sind, aufgef

uhrt, ob es sich um Ein-

bzw. Ausgaben handelt und, wenn dies m

oglich ist, von welchem Typ

sie sind und in welchem Wertebereich sie liegen. F

ur das endg

ultige

Modell

Mf inal

ergab sich folgende Einteilung, die als Berechnungs-

grundlage der Modell-Metrik ΓMverwendet wurde:

Modell-Komponenten Eingabe Ausgabe

Heckrotor [−1, 0, . . . , 1, 0]–

Seitenrotoren [−1, 0, . . . , 1, 0]–

Winkel Seitenrotoren [−180, 0, . . . , 180, 0]–

Flugh¨

ohe –[0, 0, . . . , 10, 0]

Das Modell beschreibt hier die Ein- und Ausgaben der Hardware

des Zeppelins, die von der Software verwendet werden k

onnen. Der

ohensensor wurde dabei speziell entwickelt und soll f

ur die fortge-

schrittenen Steuerstrategien zum Einsatz kommen. Dabei wurde der

ohensensor zu Anfang als Softwarekomponente realisiert, die die

ohe des Zeppelins in der virtuellen Umgebung zur

uckgibt. Sp

ater

wurde eine spezielle Hardwarekomponente in den Zeppelin verbaut,

die die reale H

ohe des Zeppelins mit Hilfe von Luftdruck ermittelte.

ahlen wir die in der oben angegebenen unterschiedlichen Ein- und

166

5.2 PROTOTYPENENTWICKLUNG

Ausgabequellen f

ur das endg

ultige Modell

Mf inal

zusammen erhalten

wir einen Wert von Vier (Mf inal =4).

ur das Environment

Ef inal

wurden folgende Parameter f

ur die Be-

rechnungsgrundlage der Environment-Metrik ΩEfestgestellt:

Environment-

Komponenten Eingabe Ausgabe

Hindernisse –Tracking

Umgebung –Tracking

Umwelteinfl¨

usse –

Gyroskop,

Tracking

Beim Environment soll in sp

ateren Prototypen Hindernisse erkannt

und die Position der Umgebung relativ zu einer festen Kamera be-

stimmt werden, um so bestimmte Man

over ausf

uhren zu k

onnen. Des

Weiteren sollen Umwelteinfl

usse, die auf den Zeppelin wirken, wie

z.,B. Gegen- oder Seitenwind, mit Hilfe eines Gyroskops

oder eines

Camera-Tracking erkannt und darauf reagiert werden. Damit ergeben

sich laut obiger Tabelle drei Komponenten f

ur das finale Environment

(Ef inal =3).

F¨

ur den View Vf inal wurden folgende Parameter f¨

ur ΘVfestgelegt:

View-

Komponenten Eingabe Ausgabe

Zeppelin –Realer Zeppein

Umgebung –Reale Umgebung

Zustand

Flugh

ohe, Positi-

on, etc.

Visualisierung in VR/AR

Modell Modellparameter

Visualisierung des Mo-

dells

ur den View soll der endg

ultige Prototyp der reale Zeppelin in der

realen Umgebung sein, vorzugsweise sollen bestimmte Parameter

entweder durch AR- oder durch VR-Techniken visualisiert werden.

Die Techniken richten sich dabei nach der aktuellen Darstellung. Wir

Da sich der Zeppelin bei Gegenwind um die Querachse (pitch axis in Abbildung

5.2162

) neigt, kann

er ¨

uber ¨

uber ein Gyroskop erkannt werden.

167

BEISPIEL

erhalten somit vier Komponenten f

ur finalen View ist somit (

Vf inal =

4).

Der eingesetzte Controller wird (zumindest bei neuen Steuerstrategi-

en) mit Hilfe von Benutzertests gewertet, um einen Wert f

ur die Metrik

zu erhalten. Diese Benutzertests sind hier allerdings klein gehalten

und werden meist nur von den Entwicklern selbst ausgef¨

uhrt. Somit

ist die Einordnung eher subjektiv.

5.2.2 Der erste Prototyp: Eine einfache VR Version

Wie schon im Kapitel

5.2.1164

beschrieben soll der erste Prototyp

zur Planung und Kommunikation des Entwicklungsteams dienen

und dementsprechend einfach gehalten werden.

Uber diesen sehr

einfachen virtuellen Prototypen k

onnen Man

over visualisiert und so

besser im Team besprochen werden.

Abbildung 5.4: Bilder aus dem ersten Prototypen.

Die Entwicklungszeit f

ur diesen Prototypen war sehr kurz, dabei wur-

de die meiste Zeit die Modellierung des 3D-Modells des Zeppelins

verwendet. Das 3D Modell wurde in MiReAS als spezieller Akteur

(RenderableActor) implementiert.

Uber einen KeyboardManipulator, der

auf Tastatureingaben reagieren kann, wurde die Transformation des

Zeppelins in der virtuellen Welt gesteuert. Die Umgebung wurde

durch eine einfache Bodenplatte (Groundplane) realisiert. Des Weiteren

wurden zwei einfache 3D Objekte in die Szene eingef

ugt, um die der

Zeppelin gesteuert werden kann. Es wurde jedoch keine Kollisionser-

kennung in diesen Prototypen eingebaut, so dass der Zeppelin auch

durch diese Objekte gesteuert werden kann. In Abbildung

5.4

sind

einige Screenshots vom ersten Prototypen abgebildet.

Um nun

uber die Metriken festzustellen, wie weit der Prototyp entwi-

ckelt ist, muss dieser mit dem finalen Prototypen verglichen werden.

In der folgenden Tabelle werden die in dem Szenario verwendeten

168

5.2 PROTOTYPENENTWICKLUNG

Komponenten entsprechend klassifiziert und der Wert der Metrik

berechnet.

Modell-Metrik ΓM

σiTyp ei

Zeppelin Transformation Virtuell 0

ΓM=0

4=0

Der Wert f

ur die Modell-Metrik

ΓM

ist somit f

ur diesen Prototypen 0,

da noch keines der erwarteten Komponenten implementiert ist. Die

Bewegung des Zeppelins ¨

uber eine einfache Manipulation der Trans-

formationsmatrix ist eine rein virtuelle L

osung f

ur diesen Prototypen.

View-Metrik ΘV

ωiTyp φi

3D Modell des Zeppelins Virtuell 0,5

Virtuelle Umgebung Tempor¨

ar 0

ΘV=0,5

4=1

Die View-Metrik

ΘV

ist f

ur diesen Prototypen

, da als einzige Kompo-

nente der Zeppelin als virtuelles 3D Modell existiert. Es ist zwar eine

virtuelle Umgebung in dem Szenario vorhanden, allerdings entspricht

es nicht der Realit

at, ist also nur tempor

ar f

ur diesen Prototypen

implementiert.

Environment (E)

Controller (C)

Model (M)

View (V)

Abbildung 5.5: Kiviatgraph des ersten Prototypen.

Die Environment-Metrik

ΩE

ist bei diesem Prototypen

, da keine

Informationen der realen Umgebung, weder simuliert noch per Sensor,

ermittelt werden.

Da die Steuerung

uber die Tastatur des Computers geschieht, wur-

169

BEISPIEL

den keine Benutzertests durchgef

uhrt, so dass sich auch hier f

ur die

Controller-Metrik ΨC0 ergibt.

Werden nun die einzelnen Metriken auf die entsprechenden Achsen

des Kiviatgraphen abgetragen, erhalten wir den Entwicklungsstand

ur den vorliegenden Prototypen, wie er in Abbildung

5.5169

darge-

stellt ist. An dem Kiviatgraphen kann man gut erkennen, dass die

Entwicklung in einem sehr fr

uhen Stadium ist. Der einzige Wert, der

nicht Null ist, ist der View, da hier schon ein einigermaßen genaues

Modell des Zeppelins als Visualisierung verwendet wird. Alle ande-

ren Komponenten sind nur tempor

ar, sie werden fr

uher oder sp

ater

ersetzt.

5.2.3 Der zweite Prototyp: Virtueller Prototyp mit Physiksi-

mulation

Auf dem ersten Prototypen aufbauend wurde der zweite Prototyp

entwickelt, bei dem das realistische Verhalten des Zeppelins im Mittel-

punkt stand. Wurde im ersten Prototypen die Position des Zeppelins

uber die direkte Manipulation des Transformationsmatrix realisiert,

sollte beim zweiten Prototyp ein physikalisches Modell zum Einsatz

kommen, welches das Verhalten des Zeppelins realistisch nachbilden

sollte.

Abbildung 5.6: Bilder des zweiten Prototypen.

Um dieses Ziel zu erreichen, mussten einige

Anderungen an dem

bisherigen Prototypen vorgenommen werden. Das visuelle Modell

des Zeppelins erhielt zu allererst eine Kollisionsgeometrie, so dass es

oglich war, Kollisionen mit der Umgebung zu erkennen. Da das 3D

Modell des Zeppelins, das zur Darstellung verwendet wurde, eine

zu hohe Anzahl an Polygonfl

achen enthielt, musste eine vereinfachte

Version des Zeppelins f

ur die Kollisionserkennung erzeugt werden. In

Abbildung

5.7171

ist der Unterschied zwischen den beiden Modellen

170

5.2 PROTOTYPENENTWICKLUNG

sichtbar. Zu Erkennen ist, dass die Geometrie zur Kollisionserkennung

gegen

uber dem visuellen 3D Modell des Zeppelins stark vereinfacht

wurde. Die Qualit

at des vereinfachten Kollisionsmodells reicht jedoch

aus, um eine genaue Simulation zu erhalten.

Abbildung 5.7:3D Modell vs. Kollisionsmodell des Zeppelins.

In MiReAS wurde nun das Modell des Zeppelins um physikalische

Eigenschaften erweitert, indem dort der vorhandene RenderableAc-

tor durch einen PhysicalActor ersetzt wurde. Dieser beinhaltet zum

einen die 3D Geometrie, die dargestellt werden soll, zum anderen

die Kollisionsgeometrie, die unsichtbar nur f

ur die physikalischen

Berechnungen genutzt wird. An diesen PhysicalActor k

onnen nun Ak-

tuatoren angeh

angt werden, die physikalische Kr

afte auf den Zeppelin

aus

uben. Einerseits existieren die physikalische Effekte wie die Auf-

triebskraft oder den aerodynamischen Widerstand und andererseits

gibt es die einzelnen Propeller des Zeppelins, die dem physikalischen

Modell zugef

ugt werden m

ussen. Die Achse der Schubrotoren wird

uber einen modellierten DC-Motor gesteuert. Alle Motoren und Pro-

peller beziehen sich auf den entsprechenden Knoten im 3D-Modell,

so dass diese auch die exakte Position besitzen. Damit die Drehrich-

tung der Schubmotoren in der virtuellen Umgebung besser sichtbar

ist, sind auf diese rote Kegel aufgesetzt. Abbildung

5.6170

zeigt drei

Screenshots aus dem fertigen Prototypen.

Wenn wir nun die Modell-Komponente des Prototypen betrachten,

kommen wir auf folgendes Ergebnis f

ur die Berechnung der Modell-

Metrik ΓM:

Modell-Metrik ΓM

σiTyp ei

Physikalisches Modell Virtuell 0

Heckrotor Simuliert 0,5

Seitenrotoren Simuliert 0,5

Fortsetzung auf der n¨

achster Seite

171

BEISPIEL

Fortsetzung von der vorherigen Seite

σiTyp ei

Winkel Seitenrotoren Simuliert 0,5

ΓM=1,5

4=3

Das physikalische Modell, was wir in diesem Prototypen eingebaut

haben, ist rein virtueller Natur, da es in der finalen Version durch

den realen Zeppelin gegeben ist und wir diese Eigenschaft nicht

beeinflussen k

onnen. Durch das physikalische Modell des Zeppelins

sind wir jedoch in der Lage, die Bewegung des Zeppelins durch die

korrekten Kr

afte an den Rotoren zu simulieren. Damit erhalten wir

einen Wert von 3

8f¨

ur die Modell-Metrik ΓM.

Der View wurde dahingehend aufgewertet, dass Schatten dem Sze-

nario zugef

ugt wurden. Durch die Visualisierung der Drehrichtung

der Rotoren wurde weiterhin eine Darstellung von Modellparametern

eingef

ugt, die die Darstellung erweitert. Da sich allerdings nichts an

der visuellen Repr

asentation des Umgebung ge

andert hat, ist der Wert

f¨

ur die View-Metrik nicht viel h¨

oher als der des ersten Prototypen:

View-Metrik ΘV

ωiTyp φi

3D Modell des Zeppelins Virtuell 0,5

Virtuelle Umgebung Tempor¨

ar 0

Visualisierung Modellparameter

Virtuell 0,5

ΘV=1

Zu sehen ist, dass sich der Wert f

ur die View-Metrik verbessert hat,

da nun Parameter des Modells visualisiert werden und dem Benutzer

die M

oglichkeit zur Kontrolle bieten. Da die Umgebung noch immer

nicht die Realit

at widerspiegelt, fließt sie nicht in die Bewertung mit

ein.

Wie bei dem ersten Prototypen ist der Wert der Environemnt-Metrik

ΩE

0, da keine Daten der Umwelt der Applikation zur Verf

ugung

gestellt werden.

Die Steuerung wurde

uberarbeitet und es ist nun m

oglich, den Zep-

pelin

uber einen Joystick oder einen Gamecontroller zu steuern. Mit

Hilfe einer Fernsteuerung, die

uber USB an den Computer angeschlos-

sen werden kann (siehe Abbildung

5.8173

) kann der virtuelle Zeppelin

genau so gesteuert werden wie der reale Zeppelin. Ein Benutzer, der

ubt in der Steuerung des realen Zeppelins ist, kam auf Anhieb

mit der Steuerung des virtuellen Zeppelins zurecht und konnte ihn

schnell kontrolliert steuern. Um eine Einsch

atzung dieser Steuerung

172

5.2 PROTOTYPENENTWICKLUNG

Abbildung 5.8: USB Fernsteuerung.

zu bekommen, wurde ein kleiner Test mit den Entwicklern und dem

ubten Benutzer durchgef

uhrt, bei dem der Zeppelin zwischen den

beiden Hindernissen in einer Acht gesteuert werden sollte, ohne dabei

die Hindernisse zu ber

uhren. Es wurden die Zeit und die Kollisionen

protokolliert und mit Hilfe der Contoller-Metrik

ΨC

der Wert 0.2

berechnet.

Die Akteure in diesem Prototypen sind somit folgendermaßen defi-

niert:

Akteur Modell View

Controller Environm.

Zeppelin × ×

Heckrotor × ×

Seitenrotoren × ×

Kollisionsmodell ×

Umgebung × ×

Fernsteuerung ×

Der Zeppelin wurde weiter unterteilt und es wurden der Heckrotor

und die beiden Seitenrotoren sowohl im Modell als auch im View

zugef

ugt. Des Weiteren wurde die Kollisionsgeometrie dem Modell

zugef

ugt, damit Kollisionen erkannt werden k

onnen. Die Umgebung

findet sich auch im Modell wieder, da der Zeppelin mit den beiden

Hindernissen kollidieren kann. Die Tastatur wurde durch die USB

Fernsteuerung ersetzt und ist nun f¨

ur die Steuerung zust¨

andig.

In der Abbildung

5.9174

sind nun die einzelnen Metriken in den Kiviat-

graphen eingetragen worden. Im Gegensatz zum ersten Prototypen

ist nun sowohl der Wert f

ur die Modell-Metrik als auch der Wert

5Dieser Wert ist durch die kleine Gruppe an Teilnehmern jedoch nicht repr¨

asentativ.

173

BEISPIEL

Environment (E)

Controller (C)

Model (M)

View (V)

Abbildung 5.9: Kiviatgraph des zweiten Prototypen.

ur die Controller-Metrik auf einen Wert

gestiegen. Der Wert f

den View konnte sich

uber die Visualisierung der Modellparameter

verdoppeln. Die Schatten werten zwar den visuellen Eindruck auf,

spielen allerdings in der Bewertung des Views keine Rolle.

5.2.4 Der dritte Prototyp: Verfeinerung der Steuerung

Mit dem verbesserten Modell, das im letzten Prototypen eingebaut

wurde, verh

alt sich der Zeppelin im allgemeinen Fall realit

atsnah.

Der Prototyp kann nun als Grundlage f

ur die Entwicklung einer

verbesserten Steuerung verwendet werden. Im dritten Prototyp soll

nun die Steuerung verbessert werden, um die Erfolgsrate zu erh

ohen.

Dabei soll das Eingabeger

at dasselbe bleiben wie im zweiten Prototyp,

allerdings soll der Benutzer nicht mehr direkten Einfluss auf die

einzelnen Motoren haben, sondern den Zeppelin intuitiver steuern

k¨

onnen.

Abbildung 5.10: Bilder aus dem dritten Prototypen.

Bei der zu entwickelnden Steuerung soll der Benutzer die H

ohe

174

5.2 PROTOTYPENENTWICKLUNG

und den Kurs des Zeppelins angeben, woraufhin der Zeppelin dann

versucht, diese Vorgaben umzusetzen. Hierf

ur wurden zun

achst vir-

tuelle Sensor-Plug-ins entwickelt, die einen H

ohensensor sowie einen

Kompass(-sensor) abbilden. Zur Regelung der H

ohe wurden

uber

einen PID-Regler

die Informationen des virtuellen H

ohensensors in

Steuersignale der Antriebsmotoren so umgesetzt, dass sie den Zeppe-

lin auf der eingestellten H

ohe halten.Da die Antriebsrotoren nur zwei

Freiheitsgrade besitzen (Vortrieb und Auftrieb), ist die Realisierung

eines solchen Reglers aufw¨

andig.

Zielhöhe

Aktuelle Höhe

Gewählter Vorwärtsschub

Höhendifferenz

resultierender

Winkel

resultierene Leistung

Aktuelle Position t

Berechnete Position t+1

Abbildung 5.11: Berechnung des Winkels und der Leistung.

In Abbildung

5.11

ist die Methode der Berechnung zur H

ohenregu-

lierung abgebildet. Dabei wird zun

achst die H

ohendifferenz zum

Zeitpunkt

zwischen der momentanen H

ohe des Zeppelins und der

gew¨

ahlten H¨

ohe berechnet. Aus dem gew¨

ahlten Vorw¨

artsschub, den

der Benutzer eingestellt hat, kann nun der resultierende Winkel f

die Antriebsmotoren berechnet werden. Damit der Zeppelin sowohl

die H

ohe als auch den gew

ahlten Vorw

artsschub erlangt, wird die

resultierende Leistung der Motoren berechnet und eingestellt. Damit

sollte der Zeppelin rechnerisch zum Zeitpunkt

t+1

an die berech-

nete Position gelangen. Da die Tr

agheit hier nicht mit ber

ucksichtigt

wird, wurde ein PID Regler verwendet, der die Berechnung konti-

nuierlich neu berechnet und dabei versucht, starke Schwingungen

zu mindern. Abbildung

5.12176

verdeutlicht noch einmal genau die

Zusammenh

ange zwischen der H

ohenreglung und dem Vorschub, die

im Rahmen einer Bachelorarbeit [

Lau08

] bereits vor der Realisierung

des Prototypen konzipiert wurden.

Auch der Kurs wurde

uber einen entsprechenden Regler, der die

Informationen des Kompasssensors verarbeitet, realisiert. Die Steuer-

werte f

ur den jeweiligen Kurs werden f

ur den Heckrotor berechnet.

Da dieser jedoch nur einen Freiheitsgrad besitzt, ist die Implementie-

rung des Reglers einfacher als bei der H

ohensteuerung. Analog zur

Kursabweichung wird die St¨

arke des Heckrotors geregelt.

Der Regelkreises eines PID-Reglers (proportional–integral–derivative controller) besteht aus einem

P-Anteil, einem I-Anteil und einem D-Anteil.

175

BEISPIEL

Abbildung 5.12: Berechnungsgrundlage der H¨

ohenregelung [Lau08]

Damit der Benutzer ein Feedback der eingegebenen H

ohe und des

Kurses hat, wurden diese beiden Parameter visualisiert. In Abbildung

5.10174

sind diese Visualisierungen zu sehen. Dabei gibt der blaue

Kreis die vom Benutzer eingestellt H

ohe an, der gelbe Kreis die aktu-

elle H

ohe des Zeppelins und das rote Kreissegment die Abweichung

des eingestellten Kurses zur aktuellen Flugrichtung.

Zum Testen der Kurskontrolle wurde in das Szenario eine virtuelle

Windquelle positioniert, In Abbildung

5.10174

ist diese Windquelle

mit einem Drahtgitter-Zylinder in der Mitte der Szene visualisiert.

Befindet sich der Zeppelin innhalb des Wirkbereiches der virtuellen

Windquelle, wird das physikalische Modell des Zeppelins von diesem

beeinflusst.

Die Zielwerte des Kurses und der H

ohensteuerung werden mit Hilfe

der Fernbedienung, die schon beim zweiten Prototypen zum Einsatz

kam, eingestellt. Solange der Benutzer Steuersignale sendet, wird

der jeweilige Zielwert eingestellt. Setzt der Benutzer die Steuerung

aus, wird der aktuelle Wert von H

ohe bzw. Kurs als Zielwert f

ur die

Regelung festgelegt. Dies vereinfacht die Steuerung, da die Zielwerte

direkt auf die Eingaben des Benutzers reagieren.

Bei dem dritten Prototypen hat sich weder am View noch am Modell

176

5.2 PROTOTYPENENTWICKLUNG

etwas ver

andert. Dem View wurde zwar die Visualisierung der H

ohe

und des Kurses hinzugef

ugt, allerdings

andert das nicht den Wert

der von uns definierten View-Metrik, da schon im zweiten Prototy-

pen Parameter visualisiert wurden. Als Akteure m

ussen diese beiden

Visualisierungen indes mit angef

uhrt werden. Das Modell ist dasselbe

wie im zweiten Prototypen, nur dass sich die Methode, wie der Be-

nutzer damit interagiert, ver

andert hat. Ge

andert hat sich allerdings

der Controller, der nun die Low-Level Motorsteuerung abstrahiert

und eine H

ohen- und Kurssteuerung anbietet. Des Weiteren wurde

eine virtuelle Windquelle implementiert, die Umwelteinfl

usse wider-

spiegelt. Damit ist die erste Komponente im Bereich Environment

integriert.

Environment-Metrik ΩE

ηiTyp δi

Umwelteinfl¨

usse Simuliert 0,5

ΘV=1

Wie im zweiten Prototypen wurde nur ein Benutzertest im kleinen

Rahmen unter den Entwicklern durchgef

uhrt. Der Aufbau war hier

auch derselbe wie zuvor. Es sollte wieder zwischen den Hindernissen

eine Acht geflogen werden, ohne dass der Zeppelin mit den Hinder-

nissen kollidiert. Erschwerend hinzu kam die Windquelle, die sich in

der Mitte zwischen den beiden Hindernissen befand. Hier musste je-

doch nicht der Benutzer den Kurs neu setzten, sondern der Controller

musste die entstandene Kurs

anderung korrigieren. Es waren nur die

Reaktionen der Benutzer interessant, da die sich auf die automatische

Kurskorrektur einrichten mussten. Nach der Bewertung berechnete

sich ein Wert f¨

ur die Controller-Metrik von 0.457.

F¨

ur den dritten Prototypen ergibt sich folgende Aufteilung:

Akteur Modell View

Controller Environm.

Zeppelin × ×

Heckrotor × ×

Seitenrotoren × ×

Kollisionsmodell ×

Umgebung × ×

Fernsteuerung ×

Kurs ×

H¨

ohe ×

Wind × ×

Neu als Akteur hinzugekommen sind der Kurs und die H

ohe, die

7Der Wert wurde zur ¨

Ubersichtlichkeit im Kiviatgraphen abgerundet.

177

BEISPIEL

visualisiert werden. Der virtuelle Wind, der die Umgebung wider-

spiegelt, wird dem Environment zugeordnet, hat allerdings auch eine

visuelle Repr

asentation. Als Controller dient wie im zweiten Prototy-

pen die USB Fernsteuerung, die jetzt jedoch anders verwendet wird,

da sie nicht mehr direkt die Rotoren steuern.

Environment (E)

Controller (C)

Model (M)

View (V)

Abbildung 5.13: Kiviatgraph des dritten Prototypen.

Damit ergibt sich f

ur den Kiviatgraphen das Bild, das in Abbildung

5.13

zusehen ist. Der Wert f

ur den Controller hat sich merklich verbes-

sert und durch die Verwendung des virtuellen Windes wurde auch

die Environment-Metrik etwas erh

oht. Durch die Verwendung der

neuen Steuerung ist die Kontrolle des Zeppelins einfacher geworden

und die Benutzer lernen schneller den Zeppelin zu beherrschen. Al-

lerdings ben

otigt diese Steuerung auch eine gewisse Lernphase, weil

die Elemente des Controllers erlernt und eingepr

agt werden m

ussen.

Im n

achsten Schritt soll nun eine realistischere Umgebung entstehen,

um den Zeppelin unter fast realen Bedingungen steuern zu k¨

onnen.

5.2.5 Der vierte Prototyp: Verbesserte real existierende Um-

gebung

Nach erfolgreichem Test der ersten verbesserten Steuerung wurde

ur den vierten Prototypen eine verbesserte und real existierende

Umgebung angestrebt. Hierzu wurde ein 3D-Modell des Lichthofs

der Fachhochschule D

usseldorf modelliert und eingebaut, wie in

Abbildung 5.14179 zu sehen.

Das visuelle 3D Modell wurde exakt nach den architektonischen Vor-

gaben modelliert und eine daraus entwickelte, einfachere Version

diente zur Kollisionserkennung (Abbildung

5.15179

). Da der Zeppelin

178

5.2 PROTOTYPENENTWICKLUNG

Abbildung 5.14: Bilder aus dem vierten Prototypen.

in dieser Umgebung schon mehrfach geflogen wurde, konnte mit Hilfe

des realistischen Umgebungseindrucks die Steuerung und das Ver-

halten des Zeppelins besser beurteilt werden. Dies sollte noch einmal

das physikalische Modell des Zeppelins auf Korrektheit ¨

uberpr¨

ufen.

Abbildung 5.15:3D Modell vs. Kollisionsmodell der Umgebung.

Dieser Prototyp ist ein Zwischenschritt zur Einf¨

uhrung der n¨

achsten

Verbesserung der Steuerung. Es war wichtig, dass hier die Umgebung

exakt modelliert wurde, damit im n

achsten Schritt die neue Steuerung

mit dem virtuellen und realen Zeppelin verglichen werden konnte.

Deshalb wurden hier auch die Kurs- und H

ohenkontrolle wieder

durch die einfachere Steuerung aus dem zweiten Prototypen ersetzt.

Es ergeben sich f¨

ur den vierten Prototypen folgende Akteure:

Akteur Modell View

Controller Environm.

Zeppelin × ×

Heckrotor × ×

Seitenrotoren × ×

Kollisionsmodell ×

Umgebung × ×

Fortsetzung auf der n¨

achster Seite

179

BEISPIEL

Fortsetzung von der vorherigen Seite

Akteur Modell View

Controller Environm.

Fernsteuerung ×

Da die neue Steuerung vom dritten Prototypen wieder entfernt wur-

de, sind auch die entsprechenden Akteure nicht mehr im Szenario

vorhanden. Die Umgebung ist nun auch im Environment vorhan-

den, da es sich um ein Abbild der realen Umgebung handelt und

der Zeppelin mit der Umgebung kollidieren kann. Dabei wird die

virtuelle Umgebung als simulierte reale Umgebung gesehen, das be-

deutet, die Applikation kann nicht auf die Daten zugreifen, außer es

urde in passender Sensor existieren. Die Kollision ist dabei von der

visuellen Darstellung gekapselt. Somit erh

oht sich der Wert f

ur die

Environment-Metrik folgendermaßen:

Environment-Metrik ΩE

ηiTyp δi

Hindernisse Simuliert 0,5

Umgebung Simuliert 0,5

ΘV=1

Die Darstellung wurde durch die real existierende virtuelle Umge-

bung aufgewertet, so dass sich der Wert der View-Metrik ein wenig

erh

oht hat. Die Modellparameter aus dem dritten Prototypen (Kurs

und H

ohe) wurden zwar nicht mehr visualisiert, allerdings wurde

weiterhin die Drehrichtung der Rotoren angezeigt, so dass sich der

Wert f¨

ur die Visualisierung von Modellparametern nicht ¨

andert.

View-Metrik ΘV

ωiTyp φi

3D Modell des Zeppelins Virtuell 0,5

Virtuelle Umgebung Virtuell 0.5

Visualisierung Modellparameter

Virtuell 0,5

ΘV=3

Der Wert f

ur die Controller-Metrik ist derselbe wie im zweiten Pro-

totyp. Es wurden keine Benutzertests f

ur die Metrik durchgef

uhrt,

allerdings wurde dieser Prototypen von einem erfahrenen Anwender

ausf

uhrlich getestet, um den virtuellen Prototyp und den realen Zep-

pelin vergleichen zu k

onnen. Das Ergebnis war, dass sich der virtuelle

Prototypen f

ur die meisten F

alle hinreichend genau so verhielt, wie

der reale Zeppelin. Auf diesem Ergebnis aufbauend konnte die Arbeit

an neuen Steuerstrategien aufgenommen werden.

Im Kiviatgraphen in Abbildung

5.16181

ist die Ver

anderung des vier-

180

5.2 PROTOTYPENENTWICKLUNG

Environment (E)

Controller (C)

Model (M)

View (V)

Abbildung 5.16: Kiviatgraph des vierten Prototypen.

ten Prototypen gut zu erkennen. Der Wert der Controller-Metrik ist

wieder auf dem Niveau vom zweiten Prototypen, das Modell ist

unver

andert und die Werte vom View und vom Environment sind

gegen

uber dem Vorg

anger etwas gestiegen. Noch bewegt sich die gan-

ze Entwicklung eher im unteren Drittel des Graphen, Der Grund ist,

dass zum vorliegenden Zeitpunkt der ganze Prototyp in VR existiert

und noch keine realen Akteuere zur Anwendung gekommen sind.

Am Ende der Entwicklung des vierten Prototypen wurde die verbes-

serte Steuerung des dritten Prototypen wieder eingebaut, jedoch ohne

die Visualisierung des Kurses und der H

ohe. Damit ließ sich nun

auch diese Steuerung in einer real existierenden Umgebung testen.

Die Ergebnisse sind mit denen aus dem dritten Prototypen identisch,

so dass der Wert der Controller-Metrik gleich blieb. Die gr

un gestri-

chelte Linie in Abbildung

5.16

zeigt diese Auspr

agung des vierten

Prototypen.

5.2.6 Der f¨unfte Prototyp: Virtueller Prototyp mit einfacher

Gestensteuerung

Nachdem der Zeppelin mit der einfachen und der High-Level Steue-

rung in einer vertrauten real existierenden Umgebung getestet werden

konnte, sollte nun im f

unften Prototypen eine weitere Verbesserung

der Steuerung implementiert werden.

Die USB Fernsteuerung soll nun durch eine einfache Gestenerkennung

ersetzt werden, die Man

over des Zeppelins intuitiver ausf

uhren soll.

Der Zeppelin soll

uber die Kommandos Hoch,Runter,Links,Rechts,

Vorw

arts und R

uckw

arts gesteuert werden. Diese Kommandos sollen in

181

BEISPIEL

Abbildung 5.17: Bilder aus dem f¨

unften Prototypen.

oglichst intuitive Gesten gewandelt werden. Die Gesten sollen mit

Hilfe der Wiimote, einem Eingabeger

at der Spielekonsole Nintendo

Wii, das

uber einen 3-Achsen Beschleunigungssensor die Lage des

Controllers im Raum erkennen kann, in die entsprechenden Komman-

dos umgesetzt werden. Die Wiimote kann

uber Bluetooth mit Hilfe der

Bibliothek OIS [

Cas10

] in MiReAS genutzt werden. F

ur ein genaues

Tracking ist der 3-Achsen Sensor, der in der Wiimote verbaut wurde,

zu unpr

azise, allerdings reicht er f

ur eine Gestenerkennung aus. Auf

Basis der Accelerometer Gesture Recogniser Bibliothek (AGR), die

mit Hilfe der Hidden Markov Modellen (HMMs) [

SPHB08

] eine Ges-

tenerkennung realisiert

wurde ein Plug-in f

ur MiReAS entwickelt.

AGR erlaubt Gesten f

ur 3D Beschleunigungsdaten zu trainieren und

trainierte Gesten zu erkennen.

Vorwärts Rückwärts

Abbildung 5.18: Gesten zur Schubkraftregulierung des Zeppelins.

Die Kommandos f

ur die Steuerung des Zeppelins wurden

uber ent-

sprechende Gesten realisiert. In Abbildung

5.19183

und Abbildung

5.18

sind die Gesten dargestellt, die den Zeppelin steuern. Sie wur-

den mit dem von AGR mitgelieferten Programm

”

GestureCreator“

trainiert und die entsprechenden HMM-Modelle zur Erkennung der

Weitere Details der Realisierung der Gestenerkennung sind in der Masterarbeit von Pogsche-

ba [Pog09], zu finden.

182

5.2 PROTOTYPENENTWICKLUNG

Gesten in MiReAS importiert. Beim Training der Gesten wurde die

Bewegung mehrfach aufgenommen, um so Fehler bei der Eingabe zu

kompensieren. Bei der Erkennung der Gesten haben sich gekr

ummte

Bewegungen robuster gegen

uber Fehlinterpretationen erwiesen, bei

geradlinigen Bewegungen traten zu viele Fehlerkennungen auf.

Die Schubkraft des Zeppelins nach vorne bzw. hinten wird

uber

den Neigungswinkel der Wiimote geregelt, wie in Abbildung

5.18182

dargestellt. Dieser kann

uber den 3-Achsen Beschleunigungssensor

direkt berechnet werden. Um eine gewisse Toleranz f

ur die Ruhelage

der Wiimote zu gew

ahrleisten, wurde der Neigungswinkel erst ab

einem bestimmten Schwellwert ber¨

ucksichtigt.

Links Rechts

Runter

Hoch

Abbruch

Abbildung 5.19: Gesten zur Navigation des Zeppelins.

Soll der Zeppelin nach links oder rechts fliegen, muss der Benutzer die

Wiimote mit einem schnellen Impuls in die entsprechende Richtung

bewegen. Soll der Zeppelin hoch oder runter fliegen, muss entspre-

chend die Wiimote mit einem schnellen Impuls in die gew

unschte

Richtung bewegt werden. Damit diese Gesten nicht f

alschlicherwei-

se, beisielsweise bei der Einstellung der Schubkraft, erkannt werden

onnen, muss der Benutzer die B-Taste der Wiimote w

ahrend der Ein-

gabe der Geste gedr

uckt halten (angedeutet durch die rot eingef

arbten

Taste in Abbildung

5.19

). Dadurch wird gew

ahrleistet, dass bei unge-

wollten Bewegungen der Wiimote keine Gesten erkannt werden. Ist

eine Geste erkannt, wird die Aktion, die mit der Geste verbunden ist,

so lange ausgef

uhrt, bis der Benutzer die Abbruch-Geste ausf

uhrt. Da-

durch werden alle Aktionen, die der Zeppelin gerade ausf

uhrt, ohne

Verz

ogerung abgebrochen. Die Geste f

ur den Abbruch aller Aktionen

sollte f

ur den Benutzer einfach zu merken und auch einfach in der

Ausf

uhrung sein, so dass sie schnell in Notsituationen ausgef

uhrt

werden kann. Die Entscheidung fiel auf das Sch

utteln der Wiimote,

da diese Geste auch schon erfolgreich z. B. beim iPhone von Apple als

entsprechende Geste bekannt war.

Diese Art von Steuerung vereinfacht die Benutzung des Zeppelins,

183

BEISPIEL

da sich der Benutzer nur f¨

unf Gesten f¨

ur die jeweiligen Kommandos

merken muss. Die Schwierigkeit in der Steuerung liegt jedoch nun in

der strikt sequenziellen Ausf

uhrung der Kommandos. Es ist mit den

vorgestellten Gesten nicht m

oglich, eine Kurs- bzw. H

ohen

anderung

ahrend der Vorw

arts oder R

uckw

artsbewegung des Zeppelins zu

initiieren, die Kommandos werden hier strikt getrennt. Das bedeutet

bei einer Kurs- bzw. H

ohen

anderung, dass der Benutzer den Schub

auf Null zur

ucksetzten und die Geste zur Kurs- bzw. H

ohen

anderung

ausf

uhren muss. Sobald der gew

unschte Kurz bzw. die gew

unschte

ohe erreicht ist, muss der Benutzer die Aktion durch die Abbruch-

geste beenden und kann dann wieder den Schub des Zeppelins setzen.

Soll sowohl Kurs als auch H

ohe ver

andert werden, muss dies auch

sequenziell geschehen, z. B. kann erst die H

ohe und danach der Kurs

andert werden. Es w

are auch eine parallele Ausf

uhrung der einzel-

nen Aktionen m

oglich gewesen, allerdings h

atte das zu einer sehr viel

komplizierteren Steuerung gef¨

uhrt.

Bei dem f

unften Prototypen ergab sich somit folgende Aufteilung der

Akteure:

Akteur Modell View

Controller Environm.

Zeppelin × ×

Heckrotor × ×

Seitenrotoren × ×

Kollisionsmodell ×

Umgebung × ×

Wiimote ×

Gestenerkennung ×

Kurs ×

H¨

ohe ×

Die Visualisierung der H

ohe und des gew

ahlten Kurses wurde wieder

eingebaut, so dass der Benutzer ein Feedback bekam. Anstatt der USB

Fernsteuerung wurde nun die Wiimote eingebunden und zus

atzlich

die Gestenerkennung als Plug-in eingebaut. Die anderen Akteure

waren dieselben wie im vierten Prototypen.

Auch bei diesem Prototypen wurde ein kleiner Benutzertest mit den

Entwicklern und einem erfahrenen Benutzer, der den Zeppelin mit

der normalen Fernbedienung sehr gut steuern konnte, durchgef

uhrt.

Die gestellte Aufgabe war, den Zeppelin einmal schnellstm

oglich um

den Lichthof zu steuern, ohne dabei mit der Umgebung zu kollidieren.

Es zeigte sich, dass der erfahrene Benutzer mit der Fernbedienung

aus dem vierten Prototypen schneller die Aufgabe l

oste, jedoch war

die Fehlerrate und auch die Zeit, die die unerfahrenen Entwickler

ben

otigten, mit der Gestensteuerung sehr viel besser. Es wurde ein

184

5.2 PROTOTYPENENTWICKLUNG

Wert von 0.65 (gerundet) f¨

ur die Controller-Metrik berechnet.

Environment (E)

Controller (C)

Model (M)

View (V)

Abbildung 5.20: Kiviatgraph des f¨

unften Prototypen.

Im Kiviatgraphen ist zu sehen, dass sich die Gestensteuerung

uber die

Wiimote positiv auf die Controller-Metrik ausgewirkt hat. Die anderen

Werte sind in Bezug auf den vierten Prototypen gleich geblieben, weil

sich nur die Steuerung ge¨

andert hat.

5.2.7 Der sechste Prototyp: Virtueller Prototyp mit verbesser-

ter Physiksimulation

Nach erfolgreichen Tests der ersten Konzepte f

ur neue Interaktions-

techniken sollte nun in diesem sechsten Prototypen eine verbesserte

physikalische Simulation eingebaut werden.

Abbildung 5.21: Bilder des sechsten Prototypen (einfache Umgebung).

Anstatt der aktuell implementierten Game-Physik Bibliothek, die die

Simulation des Zeppelins

ubernimmt, soll ein komplexes und pr

azises

physikalisches Modell des Zeppelin mit Hilfe des Softwarepaketes

Software MATLAB/Simulink [

Mat11a

Mat11b

] erstellt und simuliert

185

BEISPIEL

werden. F

ur MATLAB /Simulink existiert eine Vielzahl an Toolbo-

xen, die Funktionsbl

ocke zur Verf

ugung stellen. Diese sind teilweise

von Universit

aten bzw. ambitionierten MATLAB/Simulink Benutzern

erstellt worden und stehen zur freien Verf

ugung. Daher ist MAT-

LAB/Simulink f

ur pr

azise Simulation sehr gut geeignet und wird

auch in der Industrie und Forschung h

aufig f

ur die L

osung solcher

Probleme eingesetzt.

Das Modell des Zeppelins sollte unabh

angig von MiReAS entwi-

ckelt und simuliert werden. Um eine Kopplung zwischen der Softwa-

re MiReAS und MATLAB/Simulink zu realisieren, wurde zun

achst

COMMUVIT benutzt, das auch schon bei der Kopplung von Virtools

und MATLAB/Simulink Modellen Verwendung fand (siehe Kapi-

tel

4.5.1136

). Da es sich bei COMMUVIT um eine externe, einzeln

ausf

uhrbare Anwendung handelte, haben wir uns indes f

ur eine in-

tegrierte L

osung entscheiden, die in MiRaAS integriert wurde. So

wurde ein spezielles Netzwerk-Plug-in sowohl in MiReAS als auch in

MATLAB/Simulink eingebaut, das es erlaubt, zwischen den beiden

Programmen zu kommunizieren. Wichtig dabei ist, dass die

Ubertra-

gung der Daten synchron geschieht, so dass keine Probleme bei der

Kopplung entstehen k

onnen. Dies ist insbesondere wichtig bei

Ubert-

ragungen von externen Kr

aften und Impulsen zum physikalischen

Modell.

Abbildung 5.22: Das MATLAB/Simulink Modell des Zeppelins.

In Simulink werden die Bewegungsgleichungen berechnet, die Pog-

scheba in seiner Masterarbeit [

Pog09

] erarbeitet und implementiert

hat. Hierzu wird ein spezieller Equations of Motion-Block in MAT-

LAB/Simulink erstellt, wie in Abbildung

5.22

zu sehen ist. Dieser

Block f

uhrt eine doppelte Integration von Kraft und Drehmoment aus,

186

5.2 PROTOTYPENENTWICKLUNG

um die korrekte Position und Orientierung zu errechnen. In dem Mo-

dell existieren des Weiteren Bl

ocke zur Simulation der Corioliskraft,

des aerodynamisches Widerstandes, der Auftriebskraft und der An-

triebsmotoren. Die so berechneten Kr

afte werden summiert und dem

Block, der f

ur die Bewegungsgleichungen zust

andig ist, bereitgestellt.

Dieser errechnet mit den Werten die Position, Orientierung und Ge-

schwindigkeit des Zeppelins und sendet diese Informationen

uber den

Block

”

SimCom“, der eine Netzwerkschnittstelle kapselt, an MiReAS.

Die von MiReAS empfangenen Daten k

onnen nun benutzt werden,

um das visuelle Modell des Zeppelins korrekt auszurichten und zu

animieren. Die Informationen

uber die Motorleistungen, die

uber den

Controller eingestellt werden, und weitere externe Kr

afte, liefert Mi-

ReAS im Gegenzug an das MATLAB/Simulink Modell zur

uck. Auf

dieser Basis berechnen sich dann die neuen Werte f

ur den n

achsten

Simulationsschritt.

Das in MATLAB/Simulink entworfene Modell des Zeppelins ist allei-

ne schon durch die Verwendung der exakten Berechnungsmethoden

genauer als die allgemeine Festk

orpersimulation der Game-Physik

Engine. Um eine noch genauere Simulation zu erhalten, k

onnten z. B.

Verfahren, die in [

Kor06

] vorgestellt wurden, implementiert werden.

Das implementierte Modell des Zeppelins reicht allerdings komplett

ur unsere Zwecke aus, so dass auf eine weitere Verfeinerung verzich-

tet wurde.

Eine Kollisionserkennung wurde der Einfachheit halber direkt in

MiReAS mit Hilfe von PAL (Physics Abstraction Layer, siehe Kapi-

tel

4.5.2148

) implementiert. Kontaktpunkte zwischen dem Zeppelin

und anderen Objekten werden mit Hilfe von PAL generiert, nach

MATLAB/Simulink geschickt und dort in Impulse und Kr

afte umge-

rechnet, die den Zeppelin vom Kollisionsobjekt abstoßen, um so eine

Durchdringung der beiden Objekte zu verhindern. Leider funktio-

nierte die Kollisionsverarbeitung mit Hilfe von PAL nicht so gut wie

die Kollisionserkennung der Game-Physik Engine. Hier w¨

are Bedarf

der Verbesserung, auf die jedoch aus zeitlichen Gr

unden verzichtet

wurde.

Betrachten wir nun die Akteure, die sich in diesem Prototypen wie-

derfinden, so erhalten wir folgende Aufteilung:

Akteur Modell View

Controller Environm.

Zeppelin ×

Heckrotor × ×

Seitenrotoren × ×

Fortsetzung auf der n¨

achster Seite

187

BEISPIEL

Fortsetzung von der vorherigen Seite

Akteur Modell View

Controller Environm.

Kollisionsmodell ×

Simulink Modell ×

Kommunikation ×

Umgebung × ×

Wiimote ×

Gestenerkennung ×

Kurs ×

H¨

ohe ×

Durch die Auslagerung des Zeppelin-Modells nach MATLAB/Simu-

link ist in MiReAS nur noch das visuelle Zeppelinmodell vorhan-

den. Hinzu kam das Simulink-Modell, das extern die physikalischen

Berechnungen ausf

uhrt und sie MiReAS zur Verf

ugung stellt. Da-

zu wird ein Kommunikations-Akteur ben

otigt, der Daten von MAT-

LAB/Simulink empf¨

angt bzw. diese dorthin sendet.

Der Wert f

ur die Modell-Metrik hat sich nun ge

andert, da nun auch

noch die Berechnung der Flugh¨

ohe hinzukam:

Modell-Metrik ΓM

σiTyp ei

Physikalisches Modell Virtuell 0

Heckrotor Simuliert 0,5

Seitenrotoren Simuliert 0,5

Winkel Seitenrotoren Simuliert 0,5

Flugh¨

ohe Simuliert 0,5

ΓM=2

4=1

Zu Beginn der Entwicklung dieses Prototypen wurde auf eine ein-

fache Umgebung und eine einfache Steuerung zur

uckgegriffen, um

sich auf die Entwicklung des Modells in MATLAB/Simulink bzw.

die Kommunikation zwischen MiReAS und MATLAB/Simulink zu

konzentrieren. Bilder aus dieser Phase sind in Abbildung

5.21185

sehen. Sp

ater wurde allerdings wieder in dieselbe Umgebung und

auf dieselbe Steuerung wie in Prototyp 5umgestellt, so dass sich f

diese beiden Varianten des sechsten Prototypen folgender Kiviatgraph

ergab:

Die Punkte, die mit der transparent-gestrichelten Linie verbunden

sind, repr

asentieren den Prototypen mit der einfachen Steuerung und

Umgebung, die anderen den endg

ultigen sechsten Prototypen. Das

Modell ist etwas verbessert, da nun auch die Flugh

ohe mit simuliert

wird.

188

5.2 PROTOTYPENENTWICKLUNG

Environment (E)

Controller (C)

Model (M)

View (V)

Abbildung 5.23: Kiviatgraph des sechsten Prototypen.

5.2.8 Der siebte Prototyp: Virtueller Prototyp in realer Umge-

bung

Die Entwicklung der virtuellen Prototypen ist nun bis auf wenige Klei-

nigkeiten abgeschlossen. Als n

achster Schritt folgt nun der

Ubergang

von der virtuellen Umgebung in den realen Raum.

Abbildung 5.24: Bilder des siebten Prototypen.

Hierzu wird die virtuelle Umgebung aus aus dem Prototypen entfernt.

Das Kollisionsmodell wird jedoch beibehalten, um die Interaktion zwi-

schen realem Raum und virtuellem Zeppelin zu erm

oglichen. Die

entfernte virtuelle Umgebung wird durch ein Live-Video desselben

Raumes ausgetauscht. Um die reale Umgebung sowohl mit dem vir-

tuellen Zeppelin als auch mit dem Kollisionsmodell zu registrieren,

werden in der realen Umgebung Marker an definierten Punkten plat-

ziert (Abbildung

5.24

). Diese Marker k

onnen von MiReAS erkannt

werden und stellen eine Beziehung zwischen der virtuellen und rea-

len Welt her. Erst

uber diese Beziehung ist es m

oglich, den virtuellen

Zeppelin im realen Raum fliegen zu lassen und auch auf die reale

189

BEISPIEL

Umgebung zu reagieren.9

Bei diesem Prototypen w

urde sich zur Visualisierung der Szene ein

Head-Mounted Display (HMD) anbieten, wir haben uns allerdings f

eine normale Videokamera entschieden, da wir so auch in der Lage

waren, nachtr

aglich mit Hilfe des aufgenommenen Videomaterials

Offline-Versuche durchzuf

uhren. Bei den Aufnahmen stellten sich

schnell einige Probleme beim Tracking der Marker heraus. Sind die

mit 20cm Gr

oße relativ großen Marker zu weit entfernt, konnte ein

durchg

angiges Verfolgen der Marker nicht immer garantiert werden.

Auch spielte die Ausleuchtung und der Winkel zwischen Marker

und Kamera eine große Rolle bei der Erkennung. Diese Probleme

sind jedoch bei visuellem Markertracking bekannt und k

onnen durch

geschickte Platzierung und gute Ausleuchtung behoben werden.

Ein weiteres Problem sind Verdeckungen von virtuellen Objekten

mit realen Objekten. Da nur das Videobild vorhanden ist, fehlen die

Tiefeninformationen, um das virtuelle Modell verdecken zu k

onnen.

Hier kann jedoch das Kollisionsmodell verwendet werden, das bei

der Berechnung der sichtbaren Pixel erkennen l

asst, ob das Videobild

oder das virtuelle Objekt zu sehen ist. So kann entweder das Pixel

vom Videobild oder das Pixel vom Zeppelin je nach Entscheidung

gezeichnet werden. Diese Methode kann direkt auf modernen Gra-

fikkarten entschieden werden und ben

otigt kaum Rechenzeit. Diese

Technik wurde u. A. in der Arbeit

”

Entwicklung virtueller Kreaturen

in 3D- und AR-Umgebungen“ [GSS04c] vorgestellt.

Bei den Akteuren hat sich im siebten Prototypen Folgendes ge

andert:

Akteur Modell View

Controller Environm.

Zeppelin ×

Heckrotor × ×

Seitenrotoren × ×

Kollisionsmodell ×

Simulink Modell ×

Kommunikation ×

Umgebung ×

Fernsteuerung ×

Da in diesem Prototypen der Schwerpunkt auf die Integration des

virtuellen Zeppelins in die reale Umgebung gelegt wurde, haben

wir die Gestensteuerung wieder durch die einfache USB Fernbedie-

nung ersetzt. So konnte uns der ge

ubte Benutzer ein Feedback

uber

die Qualit

at der Visualisierung und des Modells geben, da er diesel-

Vorraussetzung zur realistischen Interaktion zwischen virtuellem Zeppelin und realer Umgebung

ist die exakte Modellierung des Kollisionsmodells.

190

5.2 PROTOTYPENENTWICKLUNG

ben Man

over einmal mit dem virtuellen Prototypen und einmal mit

dem realen Zeppelin nachfliegen und beurteilen konnte. Hier zeigte

sich ein weiteres Mal, dass das physikalische Modell, das in MAT-

LAB/Simulink berechnet wurde, sehr exakt war. Leider war, wie auch

schon zuvor erw

ahnt, die Kollisionserkennung zwischen Zeppelin

und Kollisionsmodell teilweise unpr

azise und tr

age. Da keine visuelle

Repr

asentation der Umgehung mehr in dem Prototypen vorhanden

war, entfiel auch der entsprechende Akteur. Somit war die Umge-

bung nur noch durch einen Environment Akteur repr

asentiert, hinter

dem ein Tracking System stand. Das Tracking System erkannte die

visuellen Marker in der Videoaufnahme und berechnete daraus die

die Position und Orientierung des Kollisionsmodells.

Uber die La-

ge des Kollisionsmodells konnten nun die Kollisionskr

afte zwischen

dem Zeppelin und der Umgebung in MATLAB/Simulink berechnet

werden.

So ergab sich f¨

ur die Environment-Metrik folgernder Wert:

Environment-Metrik ΩE

ηiTyp δi

Hindernisse Simuliert 0,5

Umgebung Real 1

ΘV=1

Die Hindernisse sind zwar der realen Umgebung angepasst, allerdings

wird die Kollision noch simuliert. Die Umgebung ist komplett real

und muss mit Hilfe eines Trackingverfahrens erkannt werden. Da eine

bekannte Umgebung gew

ahlt wurde, reicht ein einfaches visuelles

Marker-Tracking aus, um die Position und Orientierung der Kamera

im Raum zu berechnen und damit sowohl den Zeppelin als auch das

Kollisionsmodell auszurichten.

An der View-Metrik hat sich auch etwas ge¨

andert, da nun nicht eher

die virtuelle, sondern die reale Umgebung visualisiert wird.

View-Metrik ΘV

ωiTyp φi

3D Modell des Zeppelins Virtuell 0,5

Umgebung Real 1,0

Visualisierung Modellparameter

Virtuell 0,5

ΘV=1

Die Visualisierung der realen Umgebung ließ den Wert der View-

Metrik nun auf

ansteigen. Durch diese Ver

anderungen ergibt sich

folgender Kiviatgraph:

191

BEISPIEL

Environment (E)

Controller (C)

Model (M)

View (V)

Abbildung 5.25: Kiviatgraph des siebten Prototypen.

Die Werte der Environment-Metrik und der View-Metrik sind gestie-

gen, da jedoch die einfachere Steuerung wieder benutzt wurde, ist

der Wert der Controller-Metrik gefallen. F

ur die Modell-Metrik ist der

Wert gleich geblieben bzgl. des sechsten Prototypen, da auch hier das

MATLAB/Simulink Modell aus dem sechsten Prototypen verwendet

wurde.

5.2.9 Der achte Prototyp: Realer Zeppelin mit AR-Unterst¨ut-

zung und verbesserter Steuerung

Die folgende Iteration konnte leider auf Grund fehlender Hardware-

unterst

utzung nur theoretisch betrachtet werden. Es wurde allerdings

das Konzept entwickelt und k

onnte in Zukunft umgesetzt werden,

wenn die Hardware entwickelt wurde. Im achten Prototypen geht

es um die Einbindung des realen Zeppelins mit der im dritten Pro-

totypen aus Kapitel

5.2.4174

vorgestellten Steuerung. Hierzu soll die

Fernbedienung des Zeppelins (Abbildung

5.26193

, rechts)

uber USB

mit den entsprechenden Werten f

ur die Motorensteuerung gespeist

werden. Die M

oglichkeit, die Fernsteuerung

uber USB anzusteuern

ist allerdings nicht fertig entwickelt.

In den Zeppelin wird ein Embedded System Modul eingebaut, das

aus einer Controller-Einheit, einem H

ohensensor und einem Kompass

besteht. Links in Abbildung

5.26193

ist die Platine des Moduls zu se-

hen, wie es in der Gondel des Zeppelins platziert ist. Das Modul soll

ater komplett f

ur die Kurs- und H

ohenregelung alleine zust

andig

sein, zun

achst jedoch werden die Daten der beiden Sensoren

uber die

Fernbedienung an MiReAS weitergeleitet. Mit diesen realen Werten

kann die schon entwickelte Steuerung arbeiten und es ist m

oglich,

192

5.2 PROTOTYPENENTWICKLUNG

Abbildung 5.26: Zeppelinplatine und Fernbedienung mit USB Modul

den Algorithmus zur Kurs- bzw. H

ohenregulierung auch mit dem

realen Zeppelin zu testen. Sp

ater kann dieser Algorithmus dann auf

das Embedded System Modul

ubertragen werden und so autonom

die Regelung

ubernehmen. In diesem Prototypen soll der Zeppelin

mit Hilfe eines Trackings verfolgt werden, um so die gelieferten Wer-

te auch validieren zu k

onnen. Dabei k

onnen die Position und die

ohendaten durch AR-Techniken am getrackten Zeppelin visualisiert

werden. Alternativ zum Embedded System Modul k

onnte auch das

Tracking die Informationen zum Kurs und zur H¨

ohe liefern.

Im achten Prototypen haben wir demzufolge diese Akteure:

Akteur Modell View

Controller Environm.

Zeppelin × ×

Heckrotor ×

Seitenrotoren ×

Kollisionsmodell ×

Umgebung ×

Umwelteinfl¨

usse ×

Kommunikation ×

Fernsteuerung ×

Flugh¨

ohe × ×

Kurs × ×

In diesem Prototypen befindet sich der realen Zeppelin in der realen

Umgebung, allerdings wird immer noch ein Modell des Zeppelins

zur Berechnung des Kurses und der H

ohenregulierung ben

otigt. In

diesem Modell sind Heck- und Seitenmotoren vorhanden, da die Um-

drehung und der Stellwinkel f

ur diese am realen Zeppelin berechnen

werden m

ussen. Die Umgebung und die Umwelteinfl

usse sowie das

Kollisionsmodell geh

oren hierbei zum Environment. Die Kommuni-

kation zwischen der Fernbedienung und dem MiReAS System muss

als Akteur vorhanden sein, damit die ben

otigten Daten empfangen

werden k¨

onnen.

193

BEISPIEL

Bei der Betrachtung der Environment-Metrik kann folgender Wert

ermittelt werden:

Environment-Metrik ΩE

ηiTyp δi

Hindernisse Real 1,0

Virtuelle Umgebung Real 1,0

Umwelteinfl¨

usse Real 1,0

ΘV=1

Hier haben wir nun einen Wert von

, so dass wir alle im Vorfeld

definierten Punkte realisiert haben. Der Wert f

ur die View-Metrik sieht

dementsprechend so aus:

View-Metrik ΘV

ωiTyp φi

3D Modell des Zeppelins Real 1,0

Umgebung Real 1,0

Visualisierung Modellparameter

Real 1,0

Visualisierung Zustandsparame-

ter Real 1,0

ΘV=1

Auch bei dieser Metrik ermitteln wir einen Wert von

, da alle Vor-

gaben erreicht worden sind. Dasselbe gilt auch f

ur den Wert der

Modell-Metrik:

Modell-Metrik ΓM

σiTyp ei

Physikalisches Modell Virtuell 0

Heckrotor Real 1,0

Seitenrotoren Real 1,0

Winkel Seitenrotoren Real 1,0

Flugh¨

ohe Real 1,0

ΓM=1

Wir ben

otigen immer noch ein virtuelles physikalisches Modell, um

den Kurs und die H

ohenregulierung zu realisieren. Alle anderen

Bestandteile des Modells spiegeln die realen Bauteile des Zeppelins

wieder. Auch die Flugh

ohe ist ein realer Wert, der

uber den H

ohen-

sensor im Zeppelin gemessen wird.

Zusammenfassend ergibt sich nun folgender Kiviatgraph:

Wir machen hier die Annahme, dass der Wert der Controller-Metrik

194

5.2 PROTOTYPENENTWICKLUNG

Environment (E)

Controller (C)

Model (M)

View (V)

Abbildung 5.27: Kiviatgraph des achten Prototypen.

demselben Wert aus dem dritten Prototypen aus Kapitel

5.2.4174

ent-

spricht, da es sich um dieselbe Steuerung handelt. Da wir diesen

Prototypen nur konzeptionell entwickelt haben, konnten wie keine

Benutzertests durchf

uhren. Wir h

atten nun den Prototypen in den drei

ubrigen Metriken soweit entwickelt, wie wir es zuvor festgelegt hatten.

Bei der Entwicklung kann nun der Schwerpunkt auf eine verbesserte

Steuerung gelegt werden.

5.2.10 Der neunte Prototyp: Realer Zeppelin mit AR-Unterst¨ut-

zung und verbesserter Hardware-Steuerung

Der neunte Prototyp ist eine konsequente Weiterentwicklung des

achten Prototypen und konnte daher nur konzeptionell entwickelt

werden. Die Steuerung ist in diesem Prototypen nun komplett auf

dem Embedded System umgesetzt worden, nachdem die Algorithmen

zun¨

achst im achten Prototypen mit MiReAS getestet worden sind.

Abbildung 5.28: Bilder des neunten Prototypen.

195

BEISPIEL

Wie im achten Prototypen werden Informationen direkt an dem mit

Markern verfolgten Zeppelin visualisiert. Hierzu geh

oren die Anzeige

des zur

uckgelegten Pfades sowie die aktuelle Richtung, in der sich der

Zeppelin bewegt. Des Weiteren werden die Positionsdaten ¨

uber dem

Zeppelin angezeigt. Durch ein entsprechendes Plug-in werden diese

Zusatzinformationen im Kreis um den Zeppelin angeordnet. Leider

konnte die H

ohenregelung auf Grund der fehlenden Anbindung

der Fernbedienung an MiReAS, die die Sensor- und Reglerdaten

senden sollte, nicht visualisiert werden. Aus demselben Grund konnte

auch die Gestensteuerung nicht in diesen Prototypen implementiert

werden.

Environment (E)

Controller (C)

Model (M)

View (V)

Abbildung 5.29: Kiviatgraph des neuneten Prototypen.

Gerne h

atten wir die Gestensteuerung des f

unften Prototypen aus

Kapitel

5.2.6181

eingebaut, jedoch war das wegen der fehlenden Anbin-

dung der Fernbedienung an MiReAS nicht m

oglich. Da sich ansonsten

an diesem Prototypen gegen

uber dem achten Prototyp nichts weiter

andert hat als die konzeptionelle Idee der Gestensteuerung,

andert

sich am Kiviatgraph auch nur der Wert der Controller-Metrik. Der

hier eingetragene Wert ist einfach vom f

unften Prototypen

ubertragen

worden, w

urde man den Prototypen realisieren, m

usste man den Wert

allerdings noch validieren.

5.2.11 Der zehnte Prototyp: Realer Zeppelin in virtueller Um-

gebung

Auch dieser Prototyp wurde nur konzeptionell entwickelt, es wurde

jedoch schon teilweise mit der Entwicklung begonnen. Leider war der

Prototyp zum Zeitpunkt des Verfassens dieses Textes noch nicht fertig,

so dass hier nur auf Teilergebnisse zur¨

uckgegriffen werden kann.

196

5.2 PROTOTYPENENTWICKLUNG

Abbildung 5.30: Konzeptbilder des zehnten Prototypen.

In diesem Prototypen wird gezeigt, dass bei der Weiterentwicklung

der Steuerung wieder zur

uck in die Virtualit

at gewechselt werden

kann. Allerdings soll hier nicht der virtuelle Zeppelin zum Einsatz

kommen, sondern der reale Zeppelin, der sich in einer virtuellen

Umgebung bewegt. So ist es m

oglich, neue Konzepte der Steuerung

direkt am realen Zeppelin zu testen, jedoch die Gefahr zu minimie-

ren, den Zeppelin zu besch

adigen. Denkbar w

are ein intelligentes

Steuersystem, das Fehler des Benutzers erkennt und zu korrigieren

versucht. Beispiel hierf

ur w

are eine Kollisionsvermeidung auf Basis

von Ultraschallsensoren, die den Abstand des Zeppelins zu m

oglichen

Hindernissen misst und ggf. in die Steuerung eingreift, sollte sich der

Zeppelin einem Hindernis n¨

ahern.

Damit im Zuge der Testreihen dieser Ausweichstrategien der Zeppe-

lin nicht besch

adigt wird, bietet sich hier eine virtuelle Umgebung

an, in der sich der Zeppelin bewegt. Eine virtuelle Umgebung bietet

ein hohes Maß an Kontrolle, da die Gestaltung der Umgebung frei

gew

ahlt werden kann, um darin dann die Steuerung zu testen. Wei-

terhin k

onnten virtuelle Kr

afte, wie schon im dritten Prototypen aus

Kapitel

5.2.4174

vorgestellt, eingebaut werden, die die Steuerung des

Zeppelins erschweren und den intelligenten Steueralgorithmus testen

sollen.

Um virtuelle Kr

afte und Kollisionen mit virtuellen Objekten zu rea-

lisieren, muss auf die Rotorensteuerung des Zeppelins zugegriffen

werden. Kollidiert der Zeppelin mit einem virtuellen Objekt, muss die

resultierende Kraft und die Richtung berechnet werden und der Zep-

pelin in diese Richtung gesteuert werden. Dabei wird die Kontrolle

der Benutzers bzw. des intelligenten Algorithmus f

ur kurze Zeit außer

Kraft gesetzt. Leider funktioniert diese Methode nur bedingt, da bei

hohen Impulsen, die normalerweise bei Kollisionen auftreten, der Zep-

pelin durch seine Tr

agheit nicht sofort seine Richtung

andert. F

ur den

Test einer Steuerung ist dieser Nachteil allerdings zu vernachl

assigen.

197

BEISPIEL

Um eine virtuelle Umgebung zu realisieren, w

urde man den Zeppelin

in einer ausreichend großen Halle fliegen lassen.

Uber ein festinstallier-

tes Tracking-System, das die Position einer Kamera (oder eines HMDs)

in dieser Halle ermittelt, kann nun die virtuelle Umgebung eingeblen-

det werden. Der Benutzer muss nun entweder

uber einen Monitor

oder

uber ein HMD den Zeppelin in dieser virtuellen Umgebung

fliegen. Um virtuelle Objekte auch vor dem realen Zeppelin darstellen

zu k

onnen, m

usste auch der Zeppelin mit Hilfe des Tracking-Systems

verfolgt und die Position im Raum bestimmt werden. So kann bei

der Bilddarstellung entschieden werden, welches Objekt n

aher zum

Betrachter liegt und somit dargestellt wird.

Betrachten wir die Environment-Metrik bei diesem Prototypen, erhal-

ten wir folgenden Wert:

Environment-Metrik ΩE

ηiTyp δi

Hindernisse Virtuell 0,5

Virtuelle Umgebung Real 0,5

Umwelteinfl¨

usse Virtuell 0,5

ΘV=1

Da die komplette Umgebung wieder virtuell ist, erhalten wir einen

Wert von 1

2. Bei der View-Metrik haben wir folgende Aufteilung:

View-Metrik ΘV

ωiTyp φi

3D Modell des Zeppelins Real 1,0

Umgebung Virtuell 0,5

Visualisierung Modellparameter

Real 1,0

Visualisierung Zustandsparame-

ter Virtuell 0,5

ΘV=3

Die Umgebung und die Zustandsparameter sind virtuell

, Modell-

parameter und der Zeppelin sind real, so dass sich ein Wert f

ur die

View-Metrik von

ergibt. Am Wert der Model-Metrik ver

andert sich

nichts, da es sich um den realen Zeppelin handelt und somit die rea-

len Baugruppen angesprochen werden. Ein virtuelles physikalisches

Modell muss indes immer noch vorhanden sein, um Kollisionskr¨

afte

berechnen zu k¨

onnen.

Die Zustandsparameter beziehen sich auf die virtuelle Umgebung und sind aus diesem Grund als

virtuell anzusehen.

198

5.3 ZUSAMMENFASSUNG

Environment (E)

Controller (C)

Model (M)

View (V)

Abbildung 5.31: Kiviatgraph des zehnten Prototypen.

In Abbildung

5.31199

ist der Kiviatgraph f

ur den zehnten Prototypen

zu sehen. Es wurde angenommen, dass die Steuerung aus dem neun-

ten Prototypen verwendet wurde. F

ur die intelligente Steuerung kann

leider keine Angabe

uber den Wert der Controller-Metrik gemacht

werden, da diese Steuerung nur konzeptionell existiert. Man erkennt,

dass der Wert f

ur das Environment und f

ur den View geringer ist als

im neunten Prototypen, da die virtuelle Umgebung verwendet wird.

Das Modell bleibt jedoch bezogen auf den neunten Prototypen gleich.

5.3 Zusammenfassung

In diesem Kapitel wurde beschrieben, wie sich eine nicht triviale

Applikation mit dem MRiL-Entwurfsvorgehens entwickeln l

asst. Mit

Hilfe der Software MiReAS, die das MRiL-Entwurfsvorgehen un-

terst

utzt, wurden insgesamt sieben Prototypen komplett und drei

Prototypen konzeptionell entwickelt. Die Aufteilung der Applikation,

einerseits in die MVCE-Komponenten und andererseits in Akteure,

hat die Entwicklung der Prototypen beschleunigt. Da am Anfang

der Entwicklung definiert wurde, wie der endg

ultige Prototyp ausse-

hen sollte, konnte mit Hilfe der vorgestellten Metriken der Entwick-

lungsstatus

uber einen Kiviatgraphen grafisch angegeben werden. So

war die Klassifizierung der Prototypen nach Status der Entwicklung

schnell m¨

oglich.

Es zeigt sich, dass die Initialisierungsphase kritisch in der Entwicklung

der Applikation ist. Hier haben Fehler im grundlegenden Design

schwere Folgen f

ur die sp

atere Entwicklung. Deshalb sollte f

ur die

Initialisierungsphase ausreichend Zeit veranschlagt werden, so dass

Probleme schon zu Beginn erkannt und gel

ost werden k

onnen. Gerade

199

BEISPIEL

die Einteilung in die MVCE-Kategorien muss sorgf

altig geschehen,

allerdings ist es auch sp

ater m

oglich, eine Komponente in zwei MVCE

Kategorien aufzuteilen. Es kann aber sein, dass dann einige Akteure,

die zu dieser Komponente geh

oren, getrennt werden m

ussen, was

zus¨

atzlich Arbeit bedeutet.

Ist die Initialisierungsphase beendet, kann nun begonnen werden, den

ersten Prototypen zu entwickeln. Dies muss nicht, wie es hier der

Fall war, eine sehr einfache Version der Applikation sein, es kann

auch sofort ein komplexer Prototyp entwickelt werden, was jedoch

zeitlich aufw

andiger wird. Des Weiteren ist es sinnvoll schnell eine

einfache Anwendung zu haben, in der auch sp

ater schnell einige

Ideen realisiert werden k

onnen, beispielsweise in unserem Fall die

verbesserte physikalische Simulation aus Kapitel 5.2.7185, bei der wir

zur

uck zur einfachen Umgebung gewechselt haben, um besser die

Simulation debuggen zu k¨

onnen.

Abschließend ist zu sagen, dass die Entwicklung der Prototypen

mit Hilfe von MiReAS

uber das MRiL-Entwurfsvorgehen schnell zu

realisieren war. Ein großer Vorteil war der akteurbasierte Aufbau, so

dass bei der Entwicklung schnell auf schon vorhandene Komponenten

zur

uckgegriffen und so z. B. die Steuerung einfach gewechselt werden

konnte. So war es m

oglich, Fehler, die sich bei der Programmierung

eingeschlichen hatten, schnell zu isolieren und zu entfernen, auch

wenn an mehreren Akteuren gleichzeitig entwickelt wurde. Indem

zu einem stabilen Stand gewechselt wurde, konnten die einzelnen

Akteure bzw. Komponenten getrennt validiert und so Fehler schneller

gefunden werden.

200

KAPITEL 6

Synopsis

In diesem Kapitel m

ochte ich noch einmal kurz mein

”

Mixed Reality

in the Loop“-Entwurfsvorgehen mit den herausragenden Arbeiten

in diesem Bereich vergleichen und die Gemeinsamkeiten und Unter-

schiede der Verfahren aufzeigen.

6.1 Mixed Reality in the Loop im Vergleich

Das vorgestellte

”

Mixed Reality in the Loop“-Entwurfsvorgehen bietet

eine L

osung zur Entwicklung von Mixed Reality Anwendungen unter

Zuhilfenahme des Mixed Reality Kontinuums. Das ist einzigartig

in der Literatur, es lehnt sich allerdings an anerkannte Verfahren

einiger Wissenschaftler an. Die Arbeiten, auf die sich

”

Mixed Reality

in the Loop“ bezieht, habe ich bereits in Kapitel

359

beschrieben.

Ich m

ochte hier, nachdem ich mein Verfahren vorgestellt habe, eine

Zusammenfassung der Gemeinsamkeiten und Unterschiede an drei

in Kapitel 359 vorgestellten Arbeiten geben.

A model-based design process for interactive virtual environments

Cuppens verwendet in seinem Vorgehen (siehe Kapitel

366

) ein modell-

basierten Entwurfsprozess, um mit Hilfe eines visuell dargestellten

Task Model und einem textbasierten Interaction Description Model eine

lauff

ahige virtuelle Anwendung zu generieren. Die visuelle

”

Program-

mierung“ des Task Model ist ein wesentlicher Aspekt in seiner Arbeit

um die Entwicklung auch f

ur Anwender, die wenig oder keinen Hin-

201

SYNOPSIS

tergrund in der imperativen Programmierung haben, anwendbar zu

machen. Diesen Schritt bin ich in meiner ersten Werkzeugumgebung,

die mit Hilfe des propriet

aren Autorenwerkzeuges Virtools entstan-

den ist, auch gegangen. Hier lag der Fokus auf der Benutzbarkeit

der Werkzeugumgebung durch einen Personenkreis, der eher im Be-

reich Entwickler f

ur 3D-Inhalte anstatt in der reinen Programmierung

von Anwendungen angesiedelt war. Mit Hilfe der visuellen Program-

mierung und den von mir angebotenen Plug-ins war es dem Perso-

nenkreis m¨

oglich, Mixed Reality Anwendungen ohne das technische

Wissen um die Basistechnologie zu entwerfen. Mit Hilfe der Abstrak-

tion wurde einem gr

oßeren Kreis von Personen die Entwicklung von

Mixed Reality Anwendungen erm

oglicht. Dieses Prinzip findet man

nicht nur bei Cuppens, auch und gerade MacIntyre zeigt mit seiner

Werkzeugumgebung DART (siehe Kapitel

390

), dass sich mit Hilfe von

Personen, die im Gebiet von Kunst und Design bewandert sind, sehr

interessante MR Anwendungen entwickeln lassen.

Bei Cuppens existiert zwar kein iteratives Entwurfsvorgehen, jedoch

ist die automatische Generierung der abstrakten Darstellung in eine

ausf

uhrbare Anwendung vergleichbar mit einem iterativen Prozess.

So k

onnen auch hier die Ergebnisse schnell evaluiert werden und

ggf.

uber das Model und einer entsprechend neuen Generierung der

Anwendung in sehr kurzer Zeit ein neuer Prototyp entwickelt werden.

Diese Methode entspricht in Allgemeinen dem iterativen, prototypen-

basierten Verfahren, das ich vorgestellt habe. Das Model von Cuppens

bietet allerdings nicht explizit die M

oglichkeit der Verfeinerung der

Komponenten an.

Mein Vorgehen unterscheidet sich von der Methode bei Cuppens, da

es bei der Entwicklung einer Anwendung entlang des Mixed Reality

Kontinuums f

uhrt, Cuppens indes rein virtuelle Anwendungen er-

zeugt und keine M

oglichkeit bietet, reale Komponenten in seinem

Prozess zu verarbeiten. Auch beschr

ankt er sich auf die Implemen-

tierung von Benutzerschnittstellen in virtuellen Umgebungen, sein

Ansatz kann allerdings auch f

ur andere rein virtuelle Anwendungen

Verwendung finden.

Mixed Reality: A model of Mixed Interaction

In der Arbeit von Coutrix et al. (siehe Kapitel

368

) wird auf die Ver-

upfung der digitalen mit der physikalischen Welt fokussiert. Mit

Hilfe des Mixed Interaction Model wird dem Entwickler hier ein Frame-

work angeboten, das ihn bei der die Realisierung seiner Anwendung

unterst

utzen soll. Dabei ist das Hauptkonzept das mixed object, eine

202

6.1 MIXED REALITY IN THE LOOP IM VERGLEICH

Komponente, die gewisse Eigenschaften des digitale Modells mit den

entsprechenden Eigenschaften des physikalischen Objekts verkn

upft.

Diese mixed objects beinhalten somit die komplette Basistechnologie,

um die physikalischen Objekte zu erkennen und die entsprechen-

den Eigenschaften zu extrahieren. Auch erm

oglichen sie die Ausgabe

an physikalische Objekte, die jedoch im gegebenen Beispiel auf die

Ausgabe auf ein HMD beschr¨

ankt sind.

Die Verwendung von mixed objects ist ein sinnvoller Schritt um physi-

kalische Objekte in einer digitalen Anwendung zu erfassen und zu

kapseln. Die Basistechnologie kann hier perfekt vor dem Entwicker

versteckt werden, so dass dieser sich nur die Eigenschaften der mixed

objects definieren muss. Denselben Weg gehe ich mit den Akteuren,

die auch die Funktionalit

at in sich kapseln. Allerdings k

onnen die

Akteure nicht nur eine Verbindung zwischen digitalen und physi-

kalischen Daten sein, sondern k

onnen auch rein virtuell bzw. rein

physikalisch sein. Je nach Entwicklungsstand kann zwischen den ein-

zelnen Versionen der Akteure gewechselt werden, vorausgesetzt es

existieren die entsprechenden Implementierungen. Jedoch w

urden die

bei Coutrix et al. vorgestellten mixed objects in meinem Ansatz zwei

getrennte Akteure ergeben, da die Hin- und R

uckrichtung getrennt

betrachtet w

urde. Auch sieht mein Ansatz vor, dass physikalische

Objekte, die nicht unter der Kontrolle der Anwendung stehen, der

Komponente Environemnt angeh

oren. Diese kann von der Anwen-

dung nur abgefragt, allerdings nie ver

andert werden. Beispiel w

are

ein getracktes physikalisches Objekt, das zwar vom Benutzer der An-

wendung ver

andert werden kann (durch Manipulation des realen

Objekts), aus der Anwendung heraus jedoch keine M

oglichkeit der

Manipulation besteht.

Daher ist der Ansatz von Coutrix et al. etwas unterschiedlich zu mei-

ner Sichtweise, was sich auch in den Softwarekomponenten widerspie-

gelt. Des Weiteren sieht Coutrix et al. keine iterative Vorgehensweise

ur seine Methode vor und behandelt ausschließlich die Entwicklung

von Interaktionstechniken in Mixed Reality.

A Design-Oriented Information-Flow Refinement of the ASUR In-

teraction Model

ASUR von Dubois (siehe Kapitel

375

) bietet ein Modell und eine grafi-

sche Notation zur Entwicklung von Mixed Reality Anwendungen mit

dem Schwerpunkt auf Benutzerinteraktion. Das auf grafische Darstel-

lung basierende Modell beschreibt dabei die Interaktion zwischen dem

Benutzer und dem Mixed Reality System. Es soll helfen, die digitale

203

SYNOPSIS

und physikalische Welt miteinander zu verbinden und eine benutzer-

freundliche Anwendung zu erhalten. ASUR unterscheidet in seinem

Modell zwischen unterschiedlichen Komponenten, erw

ahnenswert

sind hier die Adapter und die realen Entit¨

aten.

Wie in meinem Ansatz verwendet ASUR in seinem Modell eine Art

Environment, das hier aus den zwei Komponenten Adapter und Real

Entity zusammengesetzt sind. Die Adapter k

onnen sowohl f

ur die

Eingabe von Daten (z. B. von einer Kamera) als auch f

ur die Ausgabe

(z. B. auf einem Monitor) verwendet werden. Ein Adapter stellt somit

die Schnittstelle zur physikalischen Welt dar und kann Daten aus

ihr extrahieren. Allerdings definiert ASUR die grafische Ausgabe auf

einem Monitor genau mit solch einem Ausgabeadapter; dies wird im

Gegensatz dazu in meinem Vorgehen

uber die View-Komponenten

realisiert, die als nicht physikalisch angesehen werden.

In ASUR existieren zudem Adapter, die eine Schnittstelle zur physi-

kalischen Welt darstellen, die Real Entities, also reale Objekte in der

physikalischen Welt, deren Eigenschaften

uber die Adapter den Digita-

len Komponenten zur Verf

ugung gestellt werden. Die Kombination

aus beidem, den Adaptern und den Real Entities erm

oglicht erst die

Entwicklung von Mixed Reality Anwendungen. In meinem Ansatz

entspricht genau diese Kombination den E-Komponenten aus dem

MVCE-Architekturmuster, mit dem oben beschriebenen Unterschied,

dass bei mir die grafische Ausgabe nicht als Ausgabeadapter verstan-

den wird. E-Komponenten in meinem Vorgehen sind reale Objekte,

die in der realen, ”physikalischen“ Umgebung existieren, auf die die

Anwendung keinen Einfluss nehmen, sie jedoch auslesen kann. Dass

die Umgebung physikalisch existiert, ist nur teilweise richtig, da die

Entwicklung nach meinem Ansatz entlang des Mixed Reality Kon-

tinuums geschieht, und so auch die Umgebung in fr

uhen Phasen

virtuell ist. Der Unterschied hier ist allerdings, dass die Umgebung

nie unter der Kontrolle der Anwendung steht, so wie es auch bei den

Real Entities in ASUR der Fall ist.

Den Real Entities stehen in ASUR noch die digitalen Entit

aten zur Sei-

te, die mit Hilfe des Adapters verschiedene Eigenschaften der realen

Objekte auslesen k

onnen. All das ist in einer E-Komponente in mei-

nem Vorgehen gekapselt. Sollen mehrere Eigenschaften eines realen

Objektes erfasst werden, so kann der Entwickler entweder eine wei-

tere E-Komponente integrieren oder die vorhandene E-Komponente

dahingehend erweitern, dass sie auch die gew

unschten Informationen

liefert.

Da die Entwicklung bei ASUR nicht entlang des Mixed Reality Konti-

nuums geschieht und des weiteren kein iterativer, prototypenbasierter

204

6.2 ZUSAMMENFASSUNG

Prozess ist, wird die Transition von virtuellen zu realen Objekten nicht

unterst

utzt. Die M

oglichkeit der Transition ist allerdings prinzipiell

gegeben, auch wenn einige Teile des entwickelten Modells ver

andert

werden m

ussen. So kann der Entwickler die virtuellen Komponen-

ten in Real Entities (durch Ersetzung) umwandeln, muss jedoch ggf.

Adapter und neue digitale Entit

aten hinzuf

ugen, die die Eigenschaf-

ten des realen Objektes abbilden. Da diese Transition nicht durch

Weiterentwicklung sondern durch Ersetzung geschieht, ist eine Wie-

derverwendung der schon vorhandenen Komponenten nicht m

oglich.

Anders als in meinem Vorgehen, bei dem die Komponenten (bei mir

Akteure) durch Adapter erweitert werden und so die restlichen Kom-

ponenten der Anwendung nicht angepasst werden m

ussen. Da ASUR

keine automatische Generierung von lauff

ahigen Programmcode hat,

ist die

Anderung des Modells aufw

andiger als beispielsweise bei Cup-

pens. Mein Ansatz bietet zwar auch keine automatische Generierung,

da allerdings die vorhandenen Komponenten weiterentwickelt wer-

den und so nur kleine

Anderungen anfallen, h

alt sich der Aufwand

in annehmbaren Grenzen.

6.2 Zusammenfassung

In diesem Kapitel habe ich kurz die Gemeinsamkeiten und die Un-

terschiede meines

”

Mixed Reality in the Loop“-Entwurfsvorgehens

mit anderen, relevanten Arbeiten aus der Literatur, die ich im Kapitel

359

ausf

uhrlich beschrieben habe, vorgestellt. Im Allgemeinen ist fest-

zustellen, das es sinnvoll ist, Mixed Reality Anwendungen einerseits

getrennt von der Basistechnologie, andererseits entlang des Mixed Rea-

lity Kontinuums zu entwickeln. Da sich die Basistechnologien schnell

andern k

onnen, hat man mit der Abstraktion eine M

oglichkeit, die

unterliegende Technik zu

andern ohne die Anwendung an sich anzu-

passen. Dieses Vorgehen wird in der Softwareentwicklung sehr h

aufig

eingesetzt, es ist also eine konsequente Weiterentwicklung bei Mixed

Reality Anwendungen. Die Entwicklung entlang des Mixed Reality

Kontinuums ist genau deshalb auch sinnvoll. So kann bei fehlender

Basistechnologie bzw. vor Fertigstellung dieser die Entwicklung der

Anwendung schon begonnen werden und in sp

ateren Prototypen die

Komponenten mit der Basistechnologie erweitert werden. Ein anderer

wichtiger Punkt ist die Entwicklung der Anwendung aus einer vom

Programmierer kontrollierbaren virtuellen Umgebung hin in zur rea-

len Umgebung. So k

onnen sicherheitsrelevante Algorithmen zuerst

in der virtuellen Umgebung auf ihre Funktionsweise hin

uberpr

uft

werden, bevor sie in der realen Welt verwendet werden.

Aus dem Stand der Forschung geht hervor, dass mein Verfahren auf re-

205

SYNOPSIS

nommierten Ans

atzen der Entwicklung von im Bereich der Mixed Rea-

lity basiert. Das zeigen die hier vorgestellten Arbeiten. Weiterf

uhrend

stellt mein Entwurfsvorgehen eine konsequente Weiterentwicklung

dieser bekannten Verfahren darstellt, in dem es versucht, die Vorteile

der einzelnen Verfahren zu kombinieren und so die Entwicklung vom

MR Anwendungen weiter vereinfacht.

206

KAPITEL 7

Zusammenfassung und Ausblick

Dieses Kapitel schließt meine Arbeit mit einer Zusammenfassung

der Ergebnisse und einem Ausblick ab. Die Zusammenfassung bietet

einen

Uberblick

uber die entstandenen Ergebnisse, die ich in dieser

Arbeit vorgestellt habe. Ich versuche die Ergebnisse in Beziehung zu

den Zielen zu stellen, die ich in Kapitel

1.24

vorgestellt habe. Dar

uber

hinaus biete ich am Ende dieses Kapitel einen Ausblick, wie sich

MRiL in Zukunft weiter entwickeln ließe und welche Erweiterungen

vorstellbar w¨

aren.

7.1 Zusammenfassung

In der hier vorliegenden Arbeit habe ich ein werkzeuggest

utztes ,

prototypenbasiertes, iteratives Entwurfsvorgehen f

ur Mixed Reality

Anwendungen vorgestellt. MRiL wird entlang des Mixed Reality Kon-

tinuums angewendet, so dass die Entwicklung einer Anwendungen

aus der Virtualit

at in die Realit

at stattfindet. Mit Hilfe des iterati-

ven prototypenbasierten Ansatzes ist eine st

andig testbare Designre-

asentation der Anwendung vorhanden, die zu Evaluationszwecken

verwendet werden kann. Folgende Punkte wurden im Einzelnen vor-

gestellt:

Entwurfsvorgehen:

Das Entwurfsvorgehen stellt die zentrale Vorge-

hensweise bei der Entwicklung einer Mixed Reality Anwendung

mit MRiL dar. Basierend auf einem iterativen Prototyping Pro-

zess verfeinert es in jedem Schritt die jeweiligen Teile einer

207

ZUSAMMENFASSUNG UND AUSBLICK

Anwendung und stellt nach jeder Iteration einen testbaren Pro-

totypen zur Verf¨

ugung.

Architekturmuster:

Um den Entwurf einer Mixed Reality Anwen-

dung zu vereinfachen, steht das MVCE Architekturmuster zur

Verf

ugung, das Teile der Anwendung bestimmten Komponenten

zuordnet. Ist eine Anwendung nach dem MVCE Architekturmus-

ter klassifiziert, so lassen sich die jeweiligen Teile unabh

angig

voneinander weiterentwickeln. Dabei legt MVCE die Beziehun-

gen fest, wie welche Komponenten miteinander interagieren

onnen. Beispielsweise ist es einer Mixed Reality Anwendung

nicht m

oglich, Daten der Environment-Komponente zu

andern,

da sich die Manipulation physikalischer Eigenschaften realer

Objekte nicht durch die Anwendung steuern l

asst. Die Umge-

bung kann nur erfasst, allerdings nicht ge

andert werden. Mit

diesem Prinzip lassen sich auch virtuelle Objekte bzw. Umge-

bungen realisieren, die jedoch von der Anwendung als reale,

nicht kontrollierbare Komponenten angesehen werden.

Akteurmodell:

Eine Verfeinerung der Aufteilung in MVCE Kompo-

nenten bietet das Akteurmodell. Hinsichtlich der vorhandenen

Werkzeugunterst

utzung ist die Aufteilung in Akteure sinnvoll,

da sie einerseits eine fein granularere Weiterentwicklung der

Mixed Reality Anwendung bietet und andererseits direkt softwa-

reseitig durch ein Entwicklungswerkzeug unterst

utzt wird. Dem

Akteur steht im Entwicklungswerkzeug der Adapter zur Seite,

der es erlaubt, den Akteur mit mehr Funktionalit

at auszustatten

und die Schnittstellen des Akteurs zu erweitern.

Metrik:

Zur genaueren Analyse des Entwicklungsstandes der Mixed

Reality Anwendung wurden f

ur jede der MVCE-Komponenten

eigene Metriken entwickelt. Diese Metriken sollen den Stand der

Entwicklung entlang einer bestimmten Komponente ermitteln

und k

onnen mit Hilfe eines Kiviatgraphen dargestellt werden.

Alle Komponenten basieren auf der Annahme der Funktionalit

der fertig entwickelten Anwendung, einzig die Metrik f

ur den

Controller bildet eine Ausnahme. Sie stellt die Benutzbarkeit der

vorliegenden Anwendung dar, vorausgesetztes es werden spezi-

elle Nutzertests durchgef

uhrt. Dies ist gerade in der Entwicklung

von neuen Mixed Reality Interaktionstechniken n

utzlich, so die

Metrik dem Entwickler ein relativ gutes Feedback gibt.

Werkzeugunterst¨

utzung:

Mit dem Ziel, dass das MRiL-Entwurfsvor-

gehen bei Mixed Reality Anwendungen ebenfalls auf Softwa-

reebene unterst

utzt wird, wurden insgesamt zwei Softwareum-

gebungen in dieser Arbeit vorgestellt. Die erste, die mehr an

208

7.1 ZUSAMMENFASSUNG

Designer gerichtet war anstatt an Programmierer, basierte auf

dem propriet

aren Werkzeug 3DVIA Virtools und wurde mit Hil-

fe von Plug-ins realisiert, die dem Anwendungsentwickler zur

Verf

ugung standen. Diese Umgebung entstand zu Beginn dieser

Arbeit und deckt nicht alle Aspekte von MRiL ab. Damit MRiL

komplett von einer Werkzeugumgebung unterst

utzt wird, wurde

MiReAS entwickelt. MiReAS wurde unter Ber

ucksichtigung von

MRiL entworfen und unterst

utzt den Entwurfsprozess daher na-

tiv. Hier wird mit Hilfe von Akteuren und Adaptern die Mixed

Reality Anwendung entworfen und implementiert. Da MiReAS

auf der Programmiersprache C++ und der OpenSceneGraph-

Grafikbibliothek basiert, ist die Entwicklung von Mixed Reality

Anwendungen jedoch eher f

ur Entwickler mit Programmierhin-

tergrund geeignet als f¨

ur Designer.

Testbare Designrepr¨

asentation:

Angesichts der Tatsache, dass das

hier vorgestellte iterative MRiL-Entwurfsvorgehen nach jeder

Iteration einen lauff

ahigen Prototypen als Ergebnis liefert, sind

Benutzertests auch in fr

uhen Entwicklungsphasen m

oglich. So

onnen Fehler in der fr

uhen Entwicklungsphasen schnell er-

kannt und korrigiert werden. Weiterhin erlaubt die Aufteilung

in die MVCE Komponenten und die Wiederverwendung von Ak-

teure und deren Erweiterung durch Adapter gezielt entwickelte

Prototypen, die speziell eine Komponente f

ur Benutzertests be-

reitstellen.

MRiL wurde an mehreren exemplarischen Beispielen angewendet,

wobei sowohl nur die Vorgehensweise als auch beide Werkzeuge ver-

wendet wurden. Das erste Beispiel, das im Kapitel

4.4128

beschrieben

wurde, basiert auf dem reinen Vorgehen und wurde ohne Zuhilfe-

nahme eines Werkzeuges entwickelt. Hier sollte das Entwurfsvor-

gehen angewendet und evaluiert werden, um zu erfahren, ob ein

sinnvoller Einsatz m

oglich ist. Die Werkzeugumgebung, die auf Vir-

tools basiert, wurde schon im Vorfeld bei mehreren Projekten und

Ver

offentlichungen verwendet, die in Kapitel

4.5.1136

erw

ahnt wur-

den. F

ur die schnelle und einfache Entwicklung von Demonstratoren

von, in Programmiersprachen nicht versierten, Entwickler ist diese

Umgebung sehr gut geeignet, da die Programmierung der Anwendun-

gen visuell erfolgte. Leider deckte die auf 3DVIA Virtools basierende

Werkzeugumgebung nicht das komplette Entwurfsvorgehen abdeckt,

was es n

otig machte, eine eigene L

osung zu entwickeln. Mit MiReAS,

vorgestellt in Kapitel

4.5.2148

, erschien eine Werkzeugumgebung, die

alle Aspekte des MRiL-Entwurfsvorgehens beinhaltete. Mit MiReAS

wurde ein sehr umfangreicher Demonstrator erfolgreich realisiert, der

in Kapitel

5159

beschrieben wurde. Mit Hilfe der Entwicklung dieses

209

ZUSAMMENFASSUNG UND AUSBLICK

Demonstrators war dann m

oglich, MRiL komplett von Entwicklern

zu evaluieren.

Das

”

Mixed Reality in the Loop“-Entwurfsvorgehen bietet ein sinn-

volles Verfahren zur Entwicklung von Mixed Reality Anwendungen.

Durch die Werkzeugunterst

utzung mit MiReAS ist es nicht nur kon-

zeptionell m

oglich, eine MR Anwendung zu entwerfen, sondern auch

schnell Prototypen in einer sehr fr

uhen Phase der Entwicklung zu

realisieren. Mit Hilfe des iterativen Prozesses k

onnen die einzelnen

Komponenten sehr feingranular verfeinert werden und durch kurze

Iterationszyklen erh

alt der Entwickler einen st

andig testbaren Pro-

totypen, der f

ur die Evaluation verwendet werden kann. Die vor-

gestellte Metrik bietet ein Maß sowohl f

ur den Entwicklungstand

der einzelnen Komponenten als auch f

ur die Benutzerfreundlichkeit

der Anwendung, wenn Benutzertests f

ur die Controller-Komponente

durchgef¨

uhrt wurden.

7.2 Ausblick

ur die Zukunft k

onnte man sich einige Erweiterungen f

ur MRiL

vorstellen, die die Entwicklung von Mixed Reality Anwendungen

weiter vereinfachen und verk

urzen k

onnten. Vorstellbar w

are eine

grafische Notation f

ur die modellbasierte Entwicklung mit MRiL. Um

die grafische Notation in der Entwicklung auch sinnvoll einsetzten

zu k

onnen, w

are eine Werkzeugunterst

utzung vorstellbar, in der der

Entwickler seine MR Anwendung entwirft. Hieraus w

urde sich dann

die dritte Erweiterung ergeben, die automatische Generierung von

ausf

uhrbaren Prototypen aus dem grafischen Modell. Beide Erweite-

rungen w

urden die Entwicklung von Mixed Reality Anwendungen

mit dem MRiL-Entwurfsvorgehen mehr in den modellbasierten Ent-

wurf heben, so dass sich der Entwickler nicht mehr um die technische

Implementierung der Anwendung Gedanken machen m

usste. Es w

are

ein konsequenter Schritt in Richtung des schnellen Prototypings.

7.2.1 Visuelle Notation

MRiL hat zur Zeit keine grafische Repr

asentation f

ur das Modell der

Anwendung. Das liegt an der Entwicklungsgeschichte von MRiL. Da

die erste softwareseitige Realisierung auf 3DVIA Virtools basierte

und dieses Werkzeug eine visuelle Programmiersprache anbot, wur-

de auf eine grafische Notation verzichtet. Im sp

ateren Verlauf bei

der Entwicklung von MiReAS wurde kein Fokus auf eine grafische

Notation gelegt, da die Entwicklung der einzelnen Akteure und Ad-

210

7.2 AUSBLICK

apter und deren Schnittstellen auch textuell sehr gut funktionierten.

Das lag gr

oßtenteils an den Entwicklern, die ein tiefgehendes Hinter-

grundwissen in imperativen Programmiersprachen hatten und mit

der textuellen Darstellung einer Anwendung gut arbeiten konnten.

Den Entwicklern, die zuvor mit Hilfe von 3DVIA Virtools die An-

wendungen entwickelt hatten, fiel die Verwendung von der MiReAS

Werkzeugumgebung schwerer, da sie nicht das Hintergrundwissen

hatten. Um auch diese Entwickler zu unterst

utzten, w

are eine visuelle

Notation des Modells der Anwendung sinnvoll.

Vorstellen k

onnte man sich eine Notation in der Art von ASUR (siehe

Kapitel

375

), um das Modell der Mixed Reality Anwendung zu definie-

ren. Hier konnten die Beziehungen zwischen den einzelnen Akteuren

und damit die Schnittstellen zwischen ihnen definiert werden. Um

das Prinzip der Adapter zu realisieren, k

onnte man sich eine hier-

archische Notation vorstellen,

ahnlich dem Komponentendiagramm

in UML 2[

JRH+07

]. Da ein Akteur auch nach der Erweiterung mit

einem Adapter ein Akteur bleibt, ist es in der obersten Ebene eines

Modells unwichtig, ob und mit wie vielen Adaptern ein Akteur erwei-

tert wurde. Einzig die Art und die Anzahl der Schnittstellen k

onnen

sich per Erweiterung des Akteurs ¨

andern.

Mit Hilfe der visuellen Notation k

onnte die Mixed Reality Anwen-

dung einfach beschrieben und konzeptionell aufgebaut werden. Dieser

Prozess k

onnte bei der Vorgehensweise aus Kapitel

4.2101

den zwei-

ten bis vierten Punkt visuell unterst

utzen und w

urde eine kompakte

visuelle Ansicht auf die zu entwickelnde Mixed Reality Anwendung

geben. Gerade bei einem Team von mehreren Entwicklern d

urfte sich

hier die Definition der einzelnen Schnittstellen als einfacher erweisen.

7.2.2 Entwicklungswerkzeug f¨ur die visuelle Notation

Aufgesetzt auf MiReAS w

are ein Entwicklungswerkzeug denkbar,

das es erlaubt, mit Hilfe der grafischen Notation die Mixed Reality

Anwendung zu entwerfen. Die Entwicklung von MR Anwendungen

urde sich von der Programmierung zur Modellierung verschieben.

Iteriert w

urde nur noch im visuellen Modell der Anwendung. Das

Entwicklungswerkzeug m

usste eine M

oglichkeit bieten, aus dem Mo-

dell entweder Konfigurationsdateien f

ur MiReAS, Quelltext oder, wie

in n

achsten Abschnitt vorgeschlagen, einen ausf

uhrbaren Prototypen

zu generieren. Die Austauschbarkeit der Komponenten mit

alteren

Versionen im visuellen Modell, die dem der Softwarekomponenten

in MiReAS entsprechen, k

onnte

uber eine Versionierung realisiert

werden. Bei einer Verfeinerung eines Akteurs (beispielsweise durch

das Anf

ugen eines Adapters), k

onnte der Akteur eine neue Versi-

211

ZUSAMMENFASSUNG UND AUSBLICK

onsnummer erhalten. Im sp

ateren Verlauf der Entwicklung h

atte der

Anwender nun die M

oglichkeit im grafischen Modell anzugeben, wel-

che Version er f

ur die einzelnen Akteure verwenden m

ochte. Dabei

ist zu beachten, dass sich die Schnittstellen bei den aktuellen Versio-

nen zu den

alteren Versionen des Akteurs ge

andert haben k

onnen.

Dadurch entstandene Probleme m

ussten entweder durch den Ent-

wickler manuell entfernt werden, wobei das Entwicklungswerkzeug

osungsvorschl

age bieten k

onnte. Auch eine automatische Aufl

osung

von inkompatiblen Schnittstellen w

are denkbar, da alle Informatio-

nen sowohl

uber die neuen als auch

uber die alten Schnittstellen

vorhanden sind. F

ur das Entwicklungswerkzeug k

onnten noch wei-

tergehende Techniken aus dem modellbasierten Entwurf integriert

werden, wie beispielsweise automatische Optimierungsverfahren oder

Fehlererkennungen.

7.2.3 Automatische Generierung von ausf¨uhrbaren Prototypen

Eine konsequente Erweiterung zum in Abschnitt

7.2.2211

vorgestellten

Entwicklungswerkzeug f

ur die visuelle Notation ist die automatische

Generierung von ausf

uhrbaren Prototypen, wie sie beispielsweise bei

der Arbeit von Cuppens et al. (Kapitel

366

) und bei NiMMiT von De

Boeck et al. (Kapitel

371

) der Fall ist. Anstatt Konfigurationdateien f

MiReAS oder Quelltext zu generieren, k

onnte sofort ein lauff

ahiger

Prototyp aus dem Modell erzeugt werden, der f

ur die Evaluation

verwendet werden kann. W

are ein Entwicklungswerkzeug f

ur die

visuelle Notation vorhanden, w

urde die automatische Generierung

grunds

atzlich unkompliziert zu realisieren sein. Im ersten Schritt

urden die Akteure und Adapter in MiReAS realisiert und daraus

Quelltext erzeugt. Nachfolgend k

onnte man die MR Anwendung mit

Hilfe der normalen C/C++ Kompilier

ubersetzten und w

urde ein

ausf¨

uhrbares Programm erhalten.

Akteure, die neue Hardware kapseln, m

ussten sowohl im Entwick-

lungswerkzeug also auch in MiReAS implementiert werden.

Ahnlich

wie bei AMIRE (siehe Kapitel

388

) w

urde mehrere Arten von Ent-

wicklern existieren, zum einen der Anwenderentwickler, der f

ur die

Realisierung der MR Anwendung zust

andig ist, zum anderen der

Systementwickler, der die erforderlichen Komponenten in das Ent-

wicklungssystem integriert. Dabei w

urde der Anwendungsentwickler

mit Hilfe der visuellen Notation entwickeln, der Systementwickler

allerdings mit einer imperativen Programmiersprache (bei MiReAS

w¨

are das C++).

212

7.3 ZUSAMMENFASSUNG

7.3 Zusammenfassung

In diesem Kapitel habe ich die Ergebnisse meiner Arbeit zusammen-

gefasst und noch einmal die wichtigsten Punkte des

”

Mixed Reality

in the Loop“-Entwurfsvorgehens aufgezeigt. Im zweiten Teil habe ich

einen Ausblick gegeben, welche forschungsrelevanten Weiterentwick-

lungen bei MRiL m

oglich sind. Dabei handelte es sich einerseits um

Arbeiten im theoretischen Umfeld, wie die Entwicklung einer visuel-

len Notation f

ur MRiL, und andererseits im praktischen Umfeld, wie

die Entwicklung eines Werkzeuges f

ur die Verwendung der visuellen

Notation.

Abschließend ist zu erw

ahnen, dass das MRiL-Entwurfsvorgehen die

Entwicklung von Prototypen und die daraus resultierende M

oglich-

keit, schon in fr

uhen Phasen der Entwicklung eine testbare Desi-

gnrepr

asentation zu erhalten und durch Benutzertest zu

uberpr

ufen,

durchaus erleichtert und zu besser benutzbaren MR Anwendungen

f¨

uhren kann.

213

ZUSAMMENFASSUNG UND AUSBLICK

214

Abbildungsverzeichnis

2.1Ein erweitertes Wasserfallmodell mit R¨

uckkopplung. . . . . . . . . . . . 16

2.2SpiralmodellnachBoehm............................ 18

2.3Phasen des V-Modells ¨

uber Zeit und Detaillisierung. . . . . . . . . . . . 19

2.4Phasen eines Softwarelebenszyklus. . . . . . . . . . . . . . . . . . . . . . 21

2.5DIN EN ISO 13407: Der Entwicklungsprozess . . . . . . . . . . . . . . . 24

2.6Modellgetriebene Softwareentwicklung. . . . . . . . . . . . . . . . . . . . 27

2.7Feature Driven Development. . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.8RationalUnifiedProcess............................. 31

2.9Lebenszyklus des Extreme Programming.................... 32

2.10 DerScrum-Prozess................................ 35

2.11 Entwicklungsprozess nach Pomberger [PW94]................ 40

2.12 Horizontaler und vertikaler Prototyp. . . . . . . . . . . . . . . . . . . . . 42

2.13 Model-View-Controller Architekturmuster. . . . . . . . . . . . . . . . . . 45

2.14 Aufbau von Presentation-Abstraction-Control(PAC). . . . . . . . . . . . 47

2.15 Aufbau eines allgemeinen Regelkreises. . . . . . . . . . . . . . . . . . . . 51

2.16 Aufbau eines mechatronischen Regelkreises. . . . . . . . . . . . . . . . . 52

2.17 Model-in-the-Loop Simulation. . . . . . . . . . . . . . . . . . . . . . . . . 53

2.18 Software-in-the-Loop Simulation. . . . . . . . . . . . . . . . . . . . . . . . 54

2.19 Hardware-in-the-Loop Simulation. . . . . . . . . . . . . . . . . . . . . . . 55

2.20 Reality-Virtuality Continuum von Milgram [MTUK94]........... 55

3.1Anwendungen basierend auf dem ARToolKit. . . . . . . . . . . . . . . . 59

3.2TUI von Ishii. [Ish08].............................. 63

3.3Entwurfsprozess von Cuppens [CRC06]. .................. 67

3.4Mixed Object [CN06].............................. 69

3.5Ein Bild in NaviCam [RN95] ......................... 70

3.6Grafische Repr¨

asentation von NiMMiT [DBVRC07]............. 73

3.7Die NiMMiT Toolchain [DBVRC07]. ..................... 74

3.8Komponenten bei ASUR [DCD05]....................... 75

3.9Beispiel eines ASUR Diagramms [DG08]. .................. 77

3.10 Charakterisierung von mixed objects [DGN10]. ............... 80

3.11 Interaktion: Benutzer und mixed objects [DGN10]. ............. 81

3.12 Fiia Modell einer Anwendung [DGN10]. .................. 85

3.13 AMIRE Framework und Komponente [DGHP02]. ............. 88

215

ABBILDUNGSVERZEICHNIS

3.14 Experten bei einer AMIRE-Entwicklung [DGHP02]............. 89

3.15 DART von MacIntyre [MGDB04]........................ 91

3.16 Aufbau von Studierstube ES [SW07]...................... 93

4.1MVCEArchitekturmuster........................... 106

4.2Kiviatgraph zu Analyse des Entwicklungsstatus. . . . . . . . . . . . . . . 109

4.3Modell-Metrik dargestellt im Kiviatgraphen. . . . . . . . . . . . . . . . . 112

4.4Kiviatgraph eines weiterentwickelten Modells. . . . . . . . . . . . . . . . 113

4.5Abstrakter Aufbau eines Akteurs. . . . . . . . . . . . . . . . . . . . . . . 121

4.6Abstrakter Aufbau eines Eingabe-Ausgabe-Adapters. . . . . . . . . . . . 122

4.7SchachtelungvonAdapern........................... 123

4.8Abstrakte ¨

Ubersicht des iterativen Prototyping Prozess. . . . . . . . . . 124

4.9Konkreter Aufbau des iterativen Prototyping Prozess. . . . . . . . . . . . 125

4.10 Detailansicht der Initialisierungsphase. . . . . . . . . . . . . . . . . . . . 126

4.11 Detailansicht der Verfeinerungsphase. . . . . . . . . . . . . . . . . . . . . 127

4.12 Detailansicht der Prototypphase. . . . . . . . . . . . . . . . . . . . . . . . 127

4.13 Detailansicht der Bewertungsphase. . . . . . . . . . . . . . . . . . . . . . 128

4.14 Beispielapplikation auf einem Multitouch-Tisch. . . . . . . . . . . . . . . 129

4.15 3D Darstellung des ersten Prototypen. . . . . . . . . . . . . . . . . . . . . 131

4.16 Rudiment¨

are GUI zur Steuerung der Prototypen. . . . . . . . . . . . . . 132

4.17 2D Ansicht des zweiten Prototypen. . . . . . . . . . . . . . . . . . . . . . 133

4.18 Multitouch-Oberfl¨

ache des dritten Prototypen. . . . . . . . . . . . . . . . 134

4.19 Die Entwicklungsumgebung 3DVIAVirtools................. 137

4.20 Behavior Graph mit verbundenen Building Blocks. . . . . . . . . . . . . 138

4.21 VSL Skript Manager und VSL Building Block. . . . . . . . . . . . . . . . 139

4.22 2D Tracking mit ReacTIVision in Virtools. . . . . . . . . . . . . . . . . . . 143

4.23 Tracking mit ARToolKitPlus Building Blocks. . . . . . . . . . . . . . . . . 144

4.24 Infrarot-Tracking mit OptiTrack Building Blocks. . . . . . . . . . . . . . . 145

4.25 COMMUVIT Building Block und Simulink Modell. . . . . . . . . . . . . 146

4.26 Eingabe ¨

uber das OpenHaptics Interface in Virtools. . . . . . . . . . . . 147

4.27 Datenflussnetzwerk basierend auf Akteure. . . . . . . . . . . . . . . . . . 150

4.28 Kopplung zwischen einem Akteur und Adaptern. . . . . . . . . . . . . . 151

4.29 Das Plug-in-System von MiReAS. . . . . . . . . . . . . . . . . . . . . . . . 152

4.30 Der Simulationszyklus von MiReAS . . . . . . . . . . . . . . . . . . . . . 153

4.31 Konfiguration ¨

uberXML. ........................... 154

4.32 Die Systemstruktur von MiReAS . . . . . . . . . . . . . . . . . . . . . . . 155

5.1ModelldesZeppelins. ............................. 161

5.2DerZeppelinimDetail. ............................ 162

5.3Handels¨

ubliche 4-Kanal Funkfernbedienung. . . . . . . . . . . . . . . . . 163

5.4Bilder aus dem ersten Prototypen. . . . . . . . . . . . . . . . . . . . . . . 168

5.5Kiviatgraph des ersten Prototypen. . . . . . . . . . . . . . . . . . . . . . . 169

5.6Bilder des zweiten Prototypen. . . . . . . . . . . . . . . . . . . . . . . . . 170

5.7 3D Modell vs. Kollisionsmodell des Zeppelins. . . . . . . . . . . . . . . . 171

5.8USBFernsteuerung................................ 173

216

ABBILDUNGSVERZEICHNIS

5.9Kiviatgraph des zweiten Prototypen. . . . . . . . . . . . . . . . . . . . . . 174

5.10 Bilder aus dem dritten Prototypen. . . . . . . . . . . . . . . . . . . . . . . 174

5.11 Berechnung des Winkels und der Leistung. . . . . . . . . . . . . . . . . . 175

5.12 Berechnungsgrundlage der H¨

ohenregelung [Lau08]............ 176

5.13 Kiviatgraph des dritten Prototypen. . . . . . . . . . . . . . . . . . . . . . 178

5.14 Bilder aus dem vierten Prototypen. . . . . . . . . . . . . . . . . . . . . . . 179

5.15 3D Modell vs. Kollisionsmodell der Umgebung. . . . . . . . . . . . . . . 179

5.16 Kiviatgraph des vierten Prototypen. . . . . . . . . . . . . . . . . . . . . . 181

5.17 Bilder aus dem f¨

unftenPrototypen. ..................... 182

5.18 Gesten zur Schubkraftregulierung des Zeppelins. . . . . . . . . . . . . . 182

5.19 Gesten zur Navigation des Zeppelins. . . . . . . . . . . . . . . . . . . . . 183

5.20 Kiviatgraph des f¨

unftenPrototypen...................... 185

5.21 Bilder des sechsten Prototypen (einfache Umgebung). . . . . . . . . . . . 185

5.22 Das MATLAB/Simulink Modell des Zeppelins. . . . . . . . . . . . . . . 186

5.23 Kiviatgraph des sechsten Prototypen. . . . . . . . . . . . . . . . . . . . . 189

5.24 Bilder des siebten Prototypen. . . . . . . . . . . . . . . . . . . . . . . . . . 189

5.25 Kiviatgraph des siebten Prototypen. . . . . . . . . . . . . . . . . . . . . . 192

5.26 Zeppelinplatine und Fernbedienung mit USB Modul . . . . . . . . . . . 193

5.27 Kiviatgraph des achten Prototypen. . . . . . . . . . . . . . . . . . . . . . 195

5.28 Bilder des neunten Prototypen. . . . . . . . . . . . . . . . . . . . . . . . . 195

5.29 Kiviatgraph des neuneten Prototypen. . . . . . . . . . . . . . . . . . . . . 196

5.30 Konzeptbilder des zehnten Prototypen. . . . . . . . . . . . . . . . . . . . 197

5.31 Kiviatgraph des zehnten Prototypen. . . . . . . . . . . . . . . . . . . . . 199

217

ABBILDUNGSVERZEICHNIS

218

Abk¨urzungsverzeichnis

ηi. . . . . . . . . . . . Datum in der Environment-Metrik

ΓM. . . . . . . . . . Modell-Metrik

ωi. . . . . . . . . . . Datum in der View-Metrik

ΩE. . . . . . . . . . Environment-Metrik

ΨC. . . . . . . . . . . Controller-Metrik

σi. . . . . . . . . . . . Datum in der Modell-Metrik

ΘV. . . . . . . . . . View-Metrik

ACO . . . . . . . . Ant Colony Optimization

AGR . . . . . . . . . Accelerometer Gesture Recogniser

AMIRE . . . . . . Authoring Mixed Reality

API . . . . . . . . . . Application Programming Interface

AR . . . . . . . . . . Augmented Reality

AV . . . . . . . . . . Augmented Virtuality

CARE . . . . . . . Complementarity, Assignment, Redundancy and Equivalence

CAVE . . . . . . . Cave Automatic Virtual Environment

CPU . . . . . . . . . Central Processing Unit

DART . . . . . . . Designer’s AR-Toolkit

DC . . . . . . . . . . Direct Current

DIN . . . . . . . . . Deutsches Institut f¨

ur Normung

DSL . . . . . . . . . Domain-Specific Language

EDV . . . . . . . . . Elektronische Datenverarbeitung

FDD . . . . . . . . . Feature Driven Development

FLTK . . . . . . . . Fast Light Toolkit

FLUID . . . . . . . Fast Light User-Interface Designer

FPS . . . . . . . . . . Frames Per Second

FPU . . . . . . . . . Floating Point Unit

GLSL . . . . . . . . Graphics Library Shading Language

GMTL . . . . . . . Generic Math Template Library

GPL . . . . . . . . . GNU General Public License

GPU . . . . . . . . . Graphics Processing Unit

GUI . . . . . . . . . Graphical User Interface

HCI . . . . . . . . . Human Computer Interaction

HIL . . . . . . . . . . Hardware in the Loop

HLSL . . . . . . . . High Level Shading Language

HMD . . . . . . . . Head-Mounted Display

219

ABBILDUNGSVERZEICHNIS

HMM . . . . . . . Hidden Markov Model

HUI . . . . . . . . . Haptical User Interface

HYUI . . . . . . . . Hybrid User Interface

IEC . . . . . . . . . . International Electrotechnical Commission

IO . . . . . . . . . . . Input-Output

ISO . . . . . . . . . . International Organization for Standardization

IST . . . . . . . . . . Informationsgesellschaftstechnologien

JNI . . . . . . . . . . Java Ntive Iintrface

LGPL . . . . . . . . GNU Lesser General Public License

LUA . . . . . . . . . Virtools Scripting Languale

MDSD . . . . . . . Model Driven Softare Development

MIL . . . . . . . . . Model in the Loop

MiReAS . . . . . Mixed Reality Actor Simulator

MoVeIT . . . . . . Mobilit¨

at, Verteilung und Interaktion

MR . . . . . . . . . . Mixed Reality

MRiL . . . . . . . . Mixed Reality in the Loop

MVC . . . . . . . . Model-View-Cotroller

MVCE . . . . . . . Model-View-Cotroller-Environmnet

NiMMiT . . . . . Notation for Modeling Multimodal Interaction Techniques

OIS . . . . . . . . . . Object-oriented Input System

OMG . . . . . . . . Object Management Group

OOTC . . . . . . . Object-Oriented Technology Center

OpenCL . . . . . Open Computing Language

OpenCV . . . . . Open Source Computer Vision

OpenGL . . . . . Open Graphics Library

OS . . . . . . . . . . . Operating System

PAC . . . . . . . . . Pesentation-Abstraction Layer

PAL . . . . . . . . . Physics Abrstaction Layer

PID-Regler . . Proportional–Integral–Derivative Regler

POCO . . . . . . . Portable Components

PSO . . . . . . . . . Particle Swarm Optimization

RUP . . . . . . . . . Rational Unified Process

RV . . . . . . . . . . . Reality-Virtuality Kontinuum

SDK . . . . . . . . . Software Development Kit

SEARIS . . . . . . S

oftware

ngineering and

rchitectures for

ealtime

nteractive

ystems

SIL . . . . . . . . . . Software in the Loop

TUI . . . . . . . . . . Tangible User Interface

TUIO . . . . . . . . Tangible User Interface Object

UML . . . . . . . . Unified Modeling Language

URP . . . . . . . . . Urban Planning Workbench

VR . . . . . . . . . . Virtual Reality

VSL . . . . . . . . . Virtools Scripting Languale

WIMP . . . . . . . Windows Icons Menus Pointer

XMI . . . . . . . . . XML Metadata Interchange

XML . . . . . . . . . Extensible Markup Language

220

ABBILDUNGSVERZEICHNIS

XNA . . . . . . . . XNA’s Not Acronymed

XP . . . . . . . . . . . Extreme Programming

221

ABBILDUNGSVERZEICHNIS

222

Literaturverzeichnis

[AH02]

Ambler, Scott W. und Theresa Hudson:Agile Modeling: Effective Prac-

tices for eXtreme Programming and the Unified Process. John Wiley & Sons,

Inc., New York, M¨

arz 2002. ISBN 0-471-20282-7.

[Azu97]

Azuma, Ronald T.: A Survey of Augmented Reality. In: Presence: Teleope-

rators and Virtual Environments, Nummer 6in 4, Seiten 355–385, August

1997.

[BA04]

Boxall, Marcus A. S. und Saeed Araban:Interface metrics for reusability

analysis of components. In: Software Engineering Conference, 2004. Procee-

dings. 2004 Australian, ASWEC ’04, Seiten 40–51, Washington, DC, USA,

September 2004. IEEE Computer Society.

[Bal08]

Balzert, Helmut:Lehrbuch der Softwaretechnik: Softwaremanagement. Spek-

trum Akademischer Verlag, zweite Auflage, Februar 2008. ISBN 3-8274-

1161-0.

[BBvB+01]

Beck, Kent, Mike Beedle, Arie van Bennekum, Alistair Cockburn,

Ken Schwaber und Jeff Sutherland:Manifesto for Agile Software Develop-

ment.2001, URL (zuletzt besucht am 10.11.2009):

http://agilemanifesto.

org/.

[BDS+99]

Beedle, Mike, Martine Devos, Yonat Sharon, Ken Schwaber und Jeff

Sutherland:SCRUM: An extension pattern language for hyperproductive

software development. Pattern Languages of Program Design, Januar 1999.

[Bec00]

Beck, Kent:Extreme Programming. Das Manifest. Addison-Wesley, zweite

Auflage, September 2000. ISBN 3-8273-1709-6.

[Ben56]

Benington, Herbert D: Production of large computer programs. Proceedings

of the 9th international conference on advanced programming methods

for digital computers, Januar 1956.

[BHB08]

Broll, Wolfgang, Jan Herling und Lisa Blum:Interactive Bits: Prototy-

ping of Mixed Reality Applications and Interaction Techniques through Visual

Programming.3DUI IEEE Symposium on 3D User Interfaces, 0:109–115,

M¨

arz 2008. ISBN 1-4244-2047-6.

223

LITERATURVERZEICHNIS

[BJH+01]

Bierbaum, Allen, Christopher Just, Patrick Hartling, Kevin Mei-

nert, Albert Baker und Carolina Cruz-Neira:VR Juggler: a virtual

platform for virtual reality application development. In: Virtual Reality, 2001.

Proceedings. IEEE, Seiten 89 –96, M¨

arz 2001.

[BKK92]

Budde, Reinhard, Karin Kuhlenkamp und Karlheinz Kautz:Prototy-

ping: an approach to evolutionary system development. Springer Verlag, New

York, M¨

arz 1992. ISBN 0-387-54352-X.

[BL04]

Beaudouin-Lafon, Michel:Designing interaction, not interfaces. In: Procee-

dings of the working conference on Advanced visual interfaces, AVI ’04, Seiten

15–22, New York, NY, USA, 2004. ACM. ISBN 1-58113-867-9.

[BMRS98]

Buschmann, Frank, Regine Meunier, Hans Rohnert und Peter

Sommerlad:Pattern-orientierte Software-Architektur . Ein Pattern-System.

Addison-Wesley, zweite Auflage, Januar 1998. ISBN 3-8273-1282-5.

[BMS10]

Bierbaum, Allen, Kevin Meinert und Ben Scott:Graphics Math Template

Library (GMTL).2010, URL (zuletzt besucht am 20.09.2010):

http://ggt.

sourceforge.net/.

[Boe79]

Boehm, Barry W.: Guidelines for Verifying and Validating Software Require-

ments and Design Specifications. In: Samet, P. A. (Herausgeber): Euro IFIP

79, Seiten 711–719. North Holland, 1979.

[Boe81]

Boehm, Barry W.: Software engineering economics. classes.cec.wustl.edu,

1981.

[Boe88]

Boehm, Barry W.: A spiral model of software development and enhancement.

Software Engineering: Barry W. Boehm’s Lifetime Contributions to Soft-

ware Development, Management, and Research, Mai 1988.

[Boe09]

Boeing, Adrian:Physics Abstraction Layer (PAL). Februar 2009, URL

(zuletzt besucht am 03.02.2011): http://pal.sourceforge.net/.

[Bol10]

Bolte, Mario:Entwurf und Vergleich wissensbasierter Verfahren zur Wege-

planung autonomer Einheiten. Bachelorarbeit, Universit

at Paderborn, M

arz

2010.

[Cas10]

Castaneda, Phillip:Object Oriented Input System (OIS).2010, URL

(zuletzt besucht am 01.02.2011):

http://sourceforge.net/projects/

wgois/.

[CCN97]

Calvary, Ga

elle, Jo

elle Coutaz und Laurence Nigay:From single-user

architectural design to PAC*: a generic software architecture model for CSCW.

In: Proceedings of the SIGCHI conference on Human factors in computing

systems, CHI ’97, Seiten 242–249, New York, NY, USA, 1997. ACM. ISBN

0-89791-802-9.

224

LITERATURVERZEICHNIS

[CMPH08]

Commerell, Walter, Heinz-Theo Mammen, Klaus Panreck und Joa-

chim Haase:Simulation technischer Systeme Anforderungen und Perspektiven.

Advances in Simulation for Production and Logistics Applications, Okto-

ber 2008.

[CN06]

Coutrix, C

eline und Laurence Nigay:Mixed reality: a model of mixed

interaction. In: AVI ’06: Proceedings of the working conference on Advanced

visual interfaces, Seiten 43–50, New York, NY, USA, 2006. ACM. ISBN

1-59593-353-0.

[Cou87]

Coutaz, Jo

elle:PAC, an Object Oriented Model for Dialog Design. In: Bul-

linger, Hans-J

org und Brian Shackel (Herausgeber): Human-Computer

Interaction - INTERACT ’87, Seiten 431–436. Elsevier Science Publishers,

1987.

[Cou10]

Coumans, Erwin:Game Physics Simulation.2010, URL (zuletzt besucht

am 21.09.2010): http://bulletphysics.org.

[CRC06]

Cuppens, Erwin, Chris Raymaekers und Karin Coninx:A model-based

design process for interactive virtual environments. Lecture Notes in Computer

Science, Seiten 225–236, Mai 2006. ISBN 3-540-34145-1.

[CS89]

Connell, John L und Linda Shafer:Structured rapid prototyping: an

evolutionary approach to software development. Computing Series. Yourdon

Press, M¨

arz 1989. ISBN 0-13-853573-6.

[Das09]

Dassault Systems:3DVIA Virtools - A complete development and deploy-

ment platform with an innovative approach to interactive 3D content creation.

Mai 2009, URL (zuletzt besucht am 18.05.2010):

http://www.3ds.com/

products/3dvia/3dvia-virtools/.

[DBS06]

Dorigo, Marco, Mauro Bitattari und Thomas St

utzle:Ant colony

optimization. Computational Intelligence Magazine, IEEE, 1(4):28–39,2006.

[DBVRC07]

DeBoeck, Joan, Davy Vanacken, Chris Raymaekers und Karin Co-

ninx:High-level modeling of multimodal interaction techniques using NiMMiT.

Journal of Virtual Reality and Broadcasting, 4(2), September 2007.

[DCD05]

Dupuy-Chessa, Sophie und Emmanuel Dubois:Requirements and Impacts

of Model driven engineering on Mixed Systems Design. In: 1

eres Journ

ees sur

l’Ing´

enierie Dirig´

ee par les Mod`

eles (IDM’05), Seiten 43 –54,2005.

[DeM03]

DeMarco, Tom:B

arentango: Mit Risikomanagement Projekte zum Erfolg

f¨

uhren. Hanser Fachbuch, M¨

arz 2003. ISBN 3-446-22333-9.

[DFL06]

Dachselt, Raimund, Pablo Figueroa und Irma Lindt:Specification

of Mixed Reality User Interfaces: Approaches, Languages, Standardization.

Workshop on IEEE VR 2006, M¨

arz 2006.

225

LITERATURVERZEICHNIS

[DG08]

Dubois, Emmanuel und Philip Gray:A Design-Oriented Information-Flow

Refinement of the ASUR Interaction Model. In: Gulliksen, Jan, Morton

Harning, Philippe Palanque, Gerrit van der Veer und Janet Wesson

(Herausgeber): Engineering Interactive Systems, Band 4940 der Reihe Lecture

Notes in Computer Science, Seiten 465–482. Springer Berlin / Heidelberg,

2008.

[DGHP02]

orner, Ralf, Christian Geiger, Michael Haller und Volker Paelke:

Authoring mixed reality - a component and framework based aproach. First

International Workshop on Entertainment Computing (IWEC 2002), Mai

2002.

[DGN02]

Dubois, Emmanuel, Philip D. Gray und Laurence Nigay:ASUR++:

A Design Notation for Mobile Mixed Systems. In: Proceedings of the 4th

International Symposium on Mobile Human-Computer Interaction, Mobile HCI

’02, Seiten 123–139, London, UK, 2002. Springer-Verlag. ISBN 3-540-44189-

[DGN10]

Dubois, Emmanuel, Philip Gray und Laurence Nigay (Herausgeber):

The Engineering of Mixed Reality Systems. Springer, London, 2010. ISBN

978-1-84882-732-5.

[DL98]

DeLuca, Jeff:The Original FDD Processes. Februar 1998, URL (zu-

letzt besucht am 26.05.2011):

http://www.nebulon.com/articles/fdd/

originalprocesses.html.

[DL04]

DeLuca, Jeff:Version 1.3of the Feature Driven Development processes. No-

vember 2004, URL (zuletzt besucht am 26.05.2011):

http://www.nebulon.

com/articles/fdd/download/fddprocessesA4.pdf.

[DMJ05]

Darken, R., P. McDowell und E. Johnson:Projects in VR: the Delta3D

open source game engine. Computer Graphics and Applications, IEEE,

25(3):10 –12, Mai 2005.

[DS90]

DeGrace, Peter und Leslie Hulet Stahl:Wicked Problems, Righteous

Solutions: A Catolog of Modern Engineering Paradigms. Prentice Hall, Mai

1990. ISBN 0-13-590126-X.

[EB08]

Encarna

c¸˜

ao, J.L. und G. Brunetti:Cybertechnologien als Werkzeug im

Bauwesen. Schriftenreihe der Stiftung Bauwesen, 13:13 –31,2008.

[Fia05]

Fiala, Mark:ARTag, a Fiducial Marker System Using Digital Techniques.

Computer Vision and Pattern Recognition, IEEE Computer Society Confe-

rence on, 2:590 –596,2005.

[FIB95]

Fitzmaurice, George W., Hiroshi Ishii und William A. S. Buxton:

Bricks: laying the foundations for graspable user interfaces. In: Proceedings

of the SIGCHI conference on Human factors in computing systems, CHI ’95,

226

LITERATURVERZEICHNIS

Seiten 442–449, New York, NY, USA, 1995. ACM Press/Addison-Wesley

Publishing Co. ISBN 0-201-84705-1.

[Fis02]

Fisher, Scott S.: An Authoring Toolkit for Mixed Reality Experiences. In:

In Proceedings of the International Workshop on Entertainment Computing

(IWEC2002): Special Session on Mixed Reality Entertainment, Seiten 487 –494,

2002.

[Gam86]

Game, The New New Product Development:Hirotaka Takeuchi and

Ikujiro Nonaka. Harvard Business Review, Januar-Februar 1986.

[GHJV96]

Gamma, Erich, Richard Helm, Ralph Johnson und John Vlissi-

des:Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software.

Addison-Wesley, 1996. ISBN 3-8273-1862-9.

[GHP+02]

Grimm, Paul, Michael Haller, Volker Paelke, Silvan Reinhold, Chri-

stian Reimann und J

urgen Zauner:AMIRE - Authoring Mixed Reality. In:

The First IEEE International Augmented Reality Toolkit Workshop, Darmstadt,

Germany, September 2002.

[Har87]

Harel, David:Statecharts: A visual formalism for complex systems. Sci.

Comput. Program., 8:231–274, Jui 1987.

[HBR+94]

Hill, Ralph D., Tom Brinck, Steven L. Rohall, John F. Patterson und

Wayne T. Wilner:The Rendezvous language and architecture for constructing

multi-user applications. ACM TOCHI, (1):81 –125,1994.

[ICdF99]

Ierusalimschy, Roberto, Waldemar Celes und Luiz Henrique de Fi-

gueiredo:Lua - An Extensible Extension Language, Band 26 der Reihe

Software: Practice and Experience, Seiten 635–652. John Wiley & Sons, Ltd.,

Januar 1999.

[IEE98]

ISMAR – The IEEE International Symposium on Mixed and Augmented Reality,

1998.

[IOOTC97]

IBM Object-Oriented Technology Center, CORPORATE: Developing

object-oriented software: an experience-based approach. Prentice-Hall, Inc.,

Upper Saddle River, NJ, USA, 1997. ISBN 0-13-737248-5.

[IRP+04]

Ishii, Hiroshi, Carlo Ratti, Ben Piper, Y. Wang, Assaf Biderman und

E. Ben-Joseph:Bringing Clay and Sand into Digital Design – Continuous

Tangible user Interfaces. BT Technology Journal, 22:287–299, Oktober 2004.

[Ish08]

Ishii, Hiroshi:The tangible user interface and its evolution. Communications

of the ACM, 51(6):32–36, Juni 2008.

[ISO95] ISO/IEC: 12207, Information technology – Software life cycle processes,1995.

[ISO99] ISO/IEC: 13407, Benutzer-orientierte Gestaltung interaktiver Systeme,1999.

227

LITERATURVERZEICHNIS

[ISO11]

ISO/IEC: 9241-210, Ergonomie der Mensch-System-Interaktion – Teil 210:

Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme,2011.

[IU97]

Ishii, Hiroshi und Brygg Ullmer:Tangible bits: towards seamless interfaces

between people, bits and atoms. In: Proceedings of the SIGCHI conference on

Human factors in computing systems, CHI ’97, Seiten 234–241, New York,

NY, USA, 1997. ACM. ISBN 0-89791-802-9.

[JBR99]

Jacobson, Ivar, Grady Booch und James Rumbaugh:The Unified Software

Development Process. Addison-Wesley, Februar 1999. ISBN 0-201-57169-2.

[JRH+07]

Jeckle, Mario, Chris Rupp, J

urgen Hahn, Barbara Zengler und Ste-

fan Queins:UML 2glasklar. Hanser Fachbuchverlag, 2007. ISBN 3-446-

22575-7.

[KB99]

Kato, Hirokazu und Mark Billinghurst:Marker Tracking and HMD

Calibration for a Video-based Augmented Reality Conferencing System. In: 2nd

International Workshop on Augmented Reality (IWAR 99), Seiten 85–94, Los

Alamitos, CA, USA, Oktober 1999. IEEE Computer Society.

[KBBC05]

Kaltenbrunner, Martin, Till Bovermann, Ross Bencina und Enrico

Costanza:TUIO - A Protocol for Table Based Tangible User Interfaces. In:

6th International Workshop on Gesture in Human-Computer Interaction and

Simulation (GW 2005),2005.

[KE95]

Kennedy, James und Russell Eberhart:Particle swarm optimization.

Neural Networks, 1995. Proceedings., IEEE International Conference on,

4:1942–1948,1995.

[Kor06]

Kornienko, Andrei:System Identification Approach for Determining Flight

Dynamical Characteristics of an Airship from Flight Data. Doktorarbeit, Uni-

versit¨

at Stuttgart, August 2006.

[KOSS11]

Kropatschek, Martin, Alexander Obert, Roland Sattler und Stefan

Schmied:Softwareentwicklungsmodelle – Prototyping. April 2011, URL

(zuletzt besucht am 18.04.2011):

http://cartoon.iguw.tuwien.ac.at/

fit/fit01/prototyping/welcome.html.

[KR96]

Kruchten, Philippe und WInston W. Royce:A rational development

process. CrossTalk, Januar 1996.

[Kra08]

Krassi, Boris:Dynamic Virtual Prototyping for Control Engineering. VDM

Verlag Dr. M

uller Aktiengesellschaft & Co. KG, Saarbr

ucken, November

2008. ISBN 3-639-08926-X.

[Kru99]

Kruchten, Philippe:Der Rational Unified Process. Eine Einf

uhrung.

Addison-Wesley, zweite Auflage, August 1999. ISBN 3-8273-1543-3.

228

LITERATURVERZEICHNIS

[Lau08]

Lauff, Martin:Entwicklung und Test einer Zeppelinsteuerung auf Basis eines

Atmel MEGA 2560 8Bit Mikrokontrollers. Masterarbeit, Fachhochschule

D¨

usseldorf, 2008.

[LCCV03]

Luyten, Kris, Tim Clerckx, Karin Coninx und Jean Vanderdonckt:

Derivation of a Dialog Model from a Task Model by Activity Chain Extraction.

In: Interactive Systems. Design, Specification, and Verification, Band 2844 der

Reihe Lecture Notes in Computer Science, Seiten 83–83. Springer Berlin /

Heidelberg, 2003. ISBN 3-540-39929-1.

[LN02]

Laurillau, Yann und Laurence Nigay:Clover architecture for groupware.

In: Proceedings of the 2002 ACM conference on Computer supported cooperative

work, CSCW ’02, Seiten 236–245, New York, NY, USA, 2002. ACM. ISBN

1-58113-560-2.

[LQH06]

Lei, Kaiyou, Yuhui Qiu und YiHe:A novel path planning for mobile robots

using modified particle swarm optimizer. Systems and Control in Aerospace

and Astronautics, 2006. ISSCAA 2006.1st International Symposium on,

Seiten 981–984,2006.

[LZB07]

Lietsch, Stefan, Henning Zabel und Jan Berssenbruegge:Computatio-

nal Steering of Interactive and Distributed Virtual Reality Applications. ASME

Conference Proceedings, 2007(48035):1023–1032,2007.

[LZE+06]

Lietsch, Stefan, Henning Zabel, Martin Eikermann, Veit Witten-

berg und Jan Berssenbr

ugge:Light Simulation in a Distributed Driving

Simulator. In: Bebis, George, Richard Boyle, Bahram Parvin, Darko

Koracin, Paolo Remagnino, Ara Nefian, Gopi Meenakshisundaram,

Valerio Pascucci, Jiri Zara, Jose Molineros, Holger Theisel und Tom

Malzbender (Herausgeber): Advances in Visual Computing, Band 4291 der

Reihe Lecture Notes in Computer Science, Seiten 343 –352. Springer Berlin /

Heidelberg, 2006.

[Mat11a]

MathWorks:MATLAB – Die Sprache f

ur technische Berechnungen.

2011, URL (zuletzt besucht am 02.02.2011):

http://www.mathworks.de/

products/matlab/.

[Mat11b]

MathWorks:Simulink – Simulation und Model-Based Design.2011, URL

(zuletzt besucht am 02.02.2011):

http://www.mathworks.de/products/

simulink/.

[MGDB04]

MacIntyre, Blair, Maribeth Gandy, Steven Dow und Jay David Bol-

ter:DART: a toolkit for rapid design exploration of augmented reality expe-

riences. UIST ’04: Proceedings of the 17th annual ACM symposium on

User interface software and technology, 6:197 –206, Oktober 2004. ISBN

1-58113-957-8.

229

LITERATURVERZEICHNIS

[MGRB06]

McEwan, Gregor, Saul Greenberg, Michael Rounding und Michael

Boyle:Groupware Plug-ins: A Case Study of Extending Collaboration Functio-

nality through Media Items. In: CollabTech 2006, Seiten 42 –47. University of

Calgary, 2006.

[Mic11]

Microsoft:Microsoft Surface 2.0. April 2011, URL (zuletzt besucht am

12.04.2011): http://www.microsoft.com/surface.

[MRZ11]

uller, Markus, Markus Rerych und Mario Zittera:Software-

entwicklungsmodelle – Wasserfallmodell. April 2011, URL (zuletzt be-

sucht am 18.04.2011):

http://cartoon.iguw.tuwien.ac.at/fit/fit01/

wasserfall/welcome.html.

[MTUK94]

Milgram, Paul, Haruo Takemura, Akira Utsumi und Fumio Kishino:

Augmented reality: A class of displays on the reality-virtuality continuum.

Telemanipulator and Telepresence Technologies, SPIE Vol. 2351:282–292,

Januar 1994.

[NC97]

Nigay, Laurence und Jo

elle Coutaz:Multifeature Systems: The CARE

Properties and Their Impact on Software Design. In: Multimedia Interfaces:

Research and Applications, chapter 9. AAAI Press, 1997.

[Nie93]

Nielsen, Jakob:Iterative user-interface design. In: Computer, Band 26, Seiten

32–41. IEEE Computer Society, November 1993.

[Nie94]

Nielsen, Jakob:Usability inspection methods. In: Conference companion on

Human factors in computing systems, CHI ’94, Seiten 413–414, New York,

NY, USA, 1994. ACM. ISBN 0-89791-651-4.

[NT95]

Nonaka, Ikujiro und Hirotaka Takeuchi:The Knowledge-Creating Com-

pany: How Japanese Companies Create the Dynamics of Innovation. Oxford

University Press, September 1995. ISBN 0-19-509269-4.

[Obi10]

Obiltschnig, G

unter:POCO C++ Libraries.2010, URL (zuletzt besucht

am 20.09.2010): http://pocoproject.org/.

[OLWF07]

Oda, Ohan, Levi J. Lister, Sean White und Steven Feiner:Developing

an augmented reality racing game. In: Proceedings of the 2nd international con-

ference on INtelligent TEchnologies for interactive enterTAINment, INTETAIN

’08, Seiten 2:1–2:8, ICST, Brussels, Belgium, Belgium, 2007. ICST (Insti-

tute for Computer Sciences, Social-Informatics and Telecommunications

Engineering). ISBN 978-963-9799-13-4.

[Ope10]

OpenSceneGraph Community:OpenSceneGraph website.2010, URL (zu-

letzt besucht am 01.09.2010): http://www.openscenegraph.org.

[Pat99] Paterno, Fabio:Model-Based Design and Evaluation of Interactive Applicati-

ons. Springer-Verlag, London, UK, 1st Auflage, 1999. ISBN 1-85233-155-0.

230

LITERATURVERZEICHNIS

[PF02]

Palmer, Stephen R. und John M. Felsing:A Practical Guide to the Feature-

Driven Development Prentice Hall International. Prentice Hall International,

2002. ISBN 0-13-067615-2.

[Phi99]

Phillips, G.: Architectures for Synchronous Groupware. Technischer Bericht

1999-425, School of Computing — Queen’s University, Kingston, Ontario,

Canada, Mai 1999.

[Pog09]

Pogscheba, Patrick:Mixed Reality in the Loop. Masterarbeit, Fachhoch-

schuhle D¨

usseldorf, November 2009.

[PRI02]

Piper, Ben, Carlo Ratti und Hiroshi Ishii:Illuminating clay: a 3-D

tangible interface for landscape analysis. In: Proceedings of the SIGCHI confe-

rence on Human factors in computing systems: Changing our world, changing

ourselves, CHI ’02, Seiten 355–362, New York, NY, USA, 2002. ACM. ISBN

1-58113-453-3.

[PW94]

Pomberger, Gustav und Rainer Weinreich:The Role of Prototyping in

Software Development. Proceedings of the 13th Intl. Conference on the

Technology of Object-Oriented Languages and Systems (TOOLS Europe),

M¨

arz 1994.

[Rab00a]

Rabin, Steve:

A∗

Aesthetic Optimizations, Band 1der Reihe Game Program-

ming Gems, Kapitel 3.4, Seiten 264–271. Charles River Media, 2000.

[Rab00b]

Rabin, Steve:

A∗

Speed Optimizations, Band 1der Reihe Game Programming

Gems, Kapitel 3.5, Seiten 272–287. Charles River Media, 2000.

[Ree03]

Reenskaug, Trygve:The Model-View-Controller (MVC). Its Past and Pre-

sent”, Januar 2003.

[RG96]

Roseman, Mark und Saul Greenberg:Building real-time groupware with

GroupKit, a groupware toolkit. ACM Trans. Comput.-Hum. Interact., 3:66–

106, M¨

arz 1996.

[RHT95]

Rix, Joachim, Stefan Haas und Jos

eTeixeira:Virtual Prototyping - Virtual

environments and the product design process. Chapman & Hall, London, 1995.

ISBN 0-412-72160-0.

[RN95]

Rekimoto, Jun und Katashi Nagao:The world through the computer:

computer augmented interaction with real world environments. In: Proceedings

of the 8th annual ACM symposium on User interface and software technology,

UIST ’95, Seiten 29–36, New York, NY, USA, 1995. ACM. ISBN 0-89791-

709-X.

[Roy87]

Royce, W. W.: Managing the development of large software systems: concepts

and techniques. In: ICSE ’87: Proceedings of the 9th international conference on

Software Engineering, Seiten 328–338, Los Alamitos, CA, USA, 1987. IEEE

Computer Society Press. ISBN 0-89791-216-0.

231

LITERATURVERZEICHNIS

[RS01]

Reitmayr, Gerhard und Dieter Schmalstieg:OpenTracker-An Open

Software Architecture for Reconfigurable Tracking based on XML. In: VR

’01: Proceedings of the Virtual Reality 2001 Conference (VR’01), Seite 285,

Washington, DC, USA, 2001. IEEE Computer Society. ISBN 0-7695-0948-7.

[Sch04]

Scherf, Helmut E.: Modellbildung und Simulation dynamischer Systeme.

Eine Sammlung von Simulink-Beispielen. Oldenbourg Wissenschaftlicher

Verlag, zweite Auflage, September 2004. ISBN 3-486-20018-6.

[Sch08]

Schlager, Martin:Hardware-in-the-Loop Simulation: A Scalable,

Component-based, Time-triggered Hardware-in-the-loop Simulation Framework.

VDM Verlag Dr. M

uller Aktiengesellschaft & Co. KG, Saarbr

ucken, April

2008. ISBN 3-8364-6216-8.

[SEA08]

SEARIS Working Group:Software Engineering and Architectures for Realtime

Interactive Systems. Juli 2008, URL (zuletzt besucht am 28.7.2009):

http:

//www.searis.net/index.php5/Main_Page#Past_Workshops.

[Sen10]

SensAble Technologies Inc.: PHANTOM Omni Haptic Device. August

2010, URL (zuletzt besucht am 15.08.2010):

http://www.sensable.com/

haptic-phantom-omni.htm.

[SFH+02]

Schmalstieg, Dieter, Anton Fuhrmann, Gerd Hesina, Zsolt Szala-

vari, L. Miguelm Encarnacao, Michael Gervautz und Werner Purgat-

hofer:The Studierstube Augmented Reality Project. Presence, Massachusetts

Institute of Technology, 11(1):33 –54, Februar 2002.

[SGR08]

Schimmel, Brian, Christian Geiger und Holger Reckter:Projekt-

gruppe

”

3D Desktop Tower Defence“. Technischer Bericht, Hochschule Harz,

Medieninformatik, 2008.

[SH02]

Schmalstieg, Dieter und Gerd Hesina:Distributed Applications for Colla-

borative Augmented Reality. Virtual Reality Conference, IEEE, 0:59,2002.

[SOBF05]

Sandor, Christian, Alex Olwal, Blaine Bell und Steven Feiner:

Immersive mixed-reality configuration of hybrid user interfaces. In: Fourth IEEE

and ACM International Symposium on Mixed and Augmented Reality, 2005.

Proceedings., Seiten 110 –113, Oktober 2005.

[SPHB08]

Schl

omer, Thomas, Benjamin Poppinga, Niels Henze und Susanne

Boll:Gesture recognition with a Wii controller. In: Proceedings of the 2nd

international conference on Tangible and embedded interaction, TEI ’08, Seiten

11–14, New York, NY, USA, 2008. ACM. ISBN 978-1-60558-004-3.

[Spi10]

Spitzak, Bill:FLTK: Fast Light Toolkit.2010, URL (zuletzt besucht am

21.09.2010): http://www.fltk.org/.

[Sto00]

Stout, Brian:The Basics of

A∗

for Path Planning, Band 1der Reihe Game

Programming Gems, Kapitel 3.3, Seiten 254–263. Charles River Media, 2000.

232

LITERATURVERZEICHNIS

[SVEH07]

Stahl, Thomas, Markus V

olter, Sven Efftinge und Arno Haase:

Modellgetriebene Softwareentwicklung. Techniken, Engineering, Management.

d.punkt Verlag, zweite Auflage, Mai 2007. ISBN 3-89864-448-0.

[SW07]

Schmalstieg, Dieter und Daniel Wagner:Experiences with Handheld

Augmented Reality. Mixed and Augmented Reality, IEEE / ACM Interna-

tional Symposium on, 0:1–13,2007. ISBN 978-1-4244-1749-0.

[Sys06]

System, Chrysler Comprehensive Compensation:Chrysler Goes To

”Extremes”. Chrysler Group, LLC, Juni 2006.

[Tec11]

Technologies, Kongsberg Oil & Gas:Coin3D – 3D Graphics Development

Kit.2011, URL (zuletzt besucht am 15.04.2011):

http://www.coin3d.org/

[UG99]

Urnes, Tore und T.C. Nicholas Graham:Flexibly Mapping Synchronous

Groupware Architectures to Distributed Implementations. In: In Proceedings of

Design, Specification and Verification of Interactive Systems, Seiten 133 –148.

Springer-Verlag, 1999.

[UI99]

Underkoffler, John und Hiroshi Ishii:Urp: a luminous-tangible work-

bench for urban planning and design. In: Proceedings of the SIGCHI conference

on Human factors in computing systems: the CHI is the limit, CHI ’99, Seiten

386–393, New York, NY, USA, 1999. ACM. ISBN 0-201-48559-1.

[VCBT04]

Vanderdonckt, Jean, Chow Kwok Chieu, Laurent Bouillon und

Daniela Trevisan:Model-based design, generation, and evaluation of virtual

user interfaces. In: Web3D ’04: Proceedings of the ninth international conference

on 3D Web technology, Seiten 51–60, New York, NY, USA, 2004. ACM. ISBN

1-58113-845-8.

[VN00]

Vernier, Frederic und Laurence Nigay:A Framework for the Combination

and Characterization of Output Modalities. In: in Proceedings of DSV-IS2000,

LNCS, Springer-Verlag, Seiten 32–48. Springer- Verlag, 2000.

[Wei91]

Weiser, Mark:The computer for the 21st century. Scientific American,

3(265):94–104, September 1991.

[Wik11]

Wikimedia Foundation Inc.: Wikipedia, die freie Enzyklop

adie. April 2011,

URL (zuletzt besucht am 18.04.2011): http://de.wikipedia.org/.

[WIN+06]

Wahli, Ueli, Majid Irani, Ana Negrello, Celio Palma, Jason Smith

und Matt Magee:Rational Business Driven Development for Compliance.

IBM Redbooks publication, November 2006. ISBN 0-7384-9657-X.

[WRL05]

Wolf, Henning, Stefan Roock und Martin Lippert:eXtreme Program-

ming. dpunkt, zweite Auflage, 2005. ISBN 3-89864-339-5.

233

LITERATURVERZEICHNIS

[WYF03]

Washizaki, Hironori, Hirokazu Yamamoto und Yoshiaki Fukazawa:

A Metrics Suite for Measuring Reusability of Software Components. In: Procee-

dings of the 9th International Symposium on Software Metrics, Seiten 211–223,

Washington, DC, USA, 2003. IEEE Computer Society. ISBN 0-7695-1987-3.

234

Publikationen

[GFLS08]

Geiger, Christian, Robin Fritze, Anke Lehmann und J

org St

ocklein:

HYUI: A Visual Framework for Prototyping Hybrid User Interfaces. TEI ’08:

Proceedings of the 2nd International Conference on Tangible and Embedded

Interaction, Seiten 63 –70, Februar 2008. ISBN 1-60558-004-3.

[GPR+02]

Geiger, Christian, Volker Paelke, Christian Reimann, Waldemar

Rosenbach und J

org St

ocklein:Testable Design Representations for Mobile

Augmented Reality Authoring. ISMAR ’02: Proceedings of the 1st International

Symposium on Mixed and Augmented Reality, Seite 281, September 2002.

ISBN 0-7695-1781-1.

[GPS+09]

Geiger, Christian, Patrick Pogscheba, J

org St

ocklein, Hartmut

Haehnel und Malte C. Berntssen:Modellbasierter Entwurf von Mixed

Reality-Interaktionstechniken f

ur ein Indoor-Zeppelin. Augmented & Virtual

Reality in der Produktentstehung, Seiten 205 –223, Juni 2009. ISBN 978-3-

939350-71-2.

[GRSP02]

Geiger, Christian, Christian Reimann, J

org St

ocklein und Volker

Paelke:JARToolKit – A Java Binding for ARToolKit. Augmented Reality

Toolkit, The First IEEE International Workshop, September 2002. ISBN

0-7803-7680-3.

[GS07]

Geiger, Christian und J

org St

ocklein:Mixed Reality Authoring. Journal

of Three Dimensional Images, 21(1):41 –46, M¨

arz 2007.

[GSBP09]

Geiger, Christian, J

org St

ocklein, Jan Berssenbr

ugge und Volker

Paelke:Mixed Reality Design of Control Strategies. ASME 2009 International

Design Engineering Technical Conferences & Computers and Information

in Engineering Conference, August 2009.

[GSKF07]

Geiger, Christian, J

org St

ocklein, Florian Klompmaker und Robin

Fritze:Development of an Augmented Reality Game by Extending a 3D Aut-

horing System. ACE ’07: Proceedings of the International Conference on

Advances in Computer Entertainment Technology, Seiten 230 –231, Juni

2007. ISBN 1-59593-640-0.

[GSR+06]

Geiger, Christian, J

org St

ocklein, Holger Reckter, Stephan Streuber

und Robin Fritze:Entwicklung von Augmented Reality-Pr

asentationen mit

235

PUBLIKATIONEN

einem High-Level Authoring System - eine Fallstudie. Augmented & Virtual

Reality in der Produktentstehung, 188:145 –149, Juni 2006. ISBN 3-939350-

07-9.

[GSS04a]

Geiger, Christian, Tim Schmidt und J

org St

ocklein:Rapid Development

of Expressive AR Applications. ISMAR ’04: Proceedings of the 3rd IEEE/ACM

International Symposium on Mixed and Augmented Reality, November

2004.

[GSS04b]

Geiger, Christian, J

org St

ocklein und Tim Schmidt:Entwicklung phy-

sikbasierter AR-Anwendungen mit Java. Augmented & Virtual Reality in der

Produktentstehung, 149:51 –61, Juli 2004. ISBN 3-935433-58-1.

[GSS04c]

Geiger, Christian, J

org St

ocklein und Tim Schmidt:Entwicklung virtuel-

ler Kreaturen in 3D- und AR-Umgebungen. Virtuelle und Erweiterte Realit

at, 1.

Workshop der GI-Fachgruppe VR/AR, 1:253 –264, September 2004. ISBN

3-8322-3225-7.

[PSG+02]

Paelke, Volker, J

org St

ocklein, Lennart Groetzbach, Christian Gei-

ger und Waldemar Rosenbach:The AR-ENIGMA: A PDA based Interactive

Illustration. SIGGRAPH 2002: International Conference on Computer Gra-

phics and Interactive Techniques, Seite 260, Juli 2002. ISBN 1-58113-525-4.

[PSHG10]

Pogscheba, Patrick, J

org St

ocklein, Jens Herder und Christian Gei-

ger:Iteratives Mixed-Reality-Prototyping und virtuelle Studiopr

asentation einer

Steuerung f

ur ein Indoor-Lufschiff. In: 7. GI-Workshop

”

Virtuelle und Erweiterte

Realit

at“, Band 7. Fachgruppe VR/AR der Gesellschaft f

ur Informatik e.V.,

September 2010.

[SBK+10]

ocklein, J

org, Mario Bolte, Florian Klompmaker, Christian Geiger

und Karsten Nebe:Interaktive Illustration heuristischer Optimierungsverfahren

zur Wegeplanung. Augmented & Virtual Reality in der Produktentstehung,

274:191 –207, Juni 2010. ISBN 978-3-939350-93-4.

[SGDZ08]

ocklein, J

org, Christian Geiger, Gundula D

orries und Henning

Zabel:Authoring of 3D and AR Applications for Educational Purposes. Interna-

tional Conference REV, Seite CRROM, Juni 2008.

[SGP+09]

ocklein, J

org, Christian Geiger, Volker Paelke, Patrick Pogscheba

und Anke Lehmann:MVCE – A Design Pattern to Guide the Development

of Next Generation User Interfaces. IEEE Symposium on 3D User Interfaces

2009, M¨

arz 2009.

[SGP10]

ocklein, J

org, Christian Geiger und Volker Paelke:Mixed Reality

in the Loop – Design Process for Interactive Mechatronical Systems. Virtual

Reality Conference (VR), 2010 IEEE, Seiten 303 –304, M

arz 2010. ISBN

978-1-4244-6236-0.

236

PUBLIKATIONEN

[SGPP09]

ocklein, J

org, Christian Geiger, Volker Paelke und Patrick Pog-

scheba:A Design Method for Next Generation User Interfaces inspired by the

Mixed Reality Continuum. HCI International 2009:12th International Confe-

rence on Human-Computer Interaction, Juli 2009.

[SPGP10]

ocklein, J

org, Patrick Pogscheba, Christian Geiger und Volker

Paelke:MiReAS: A Mixed Reality Software Framework for Iterative Prototyping

of Control Strategies for an Indoor Airship. AFRIGRAPH ’10: Proceedings of

the 7th International Conference on Computer Graphics, Virtual Reality,

Visualisation and Interaction in Africa, Seiten 27 –36, Juni 2010. ISBN

978-1-4503-0118-3.

237

PUBLIKATIONEN

238