SlideShare ist ein Scribd-Unternehmen logo
User-Toolkits zur dienstbasierten
                 Entwicklung mobiler Applikationen


                             Peter Dornbusch, Martin Huber

               CDTM - Center for Digital Technology and Management
                         Arcisstraße 21 - 80290 München
                      dornbusc@in.tum.de; huber@cdtm.de


      Abstract: Die erfolgreiche Entwicklung und Einführung neuer mobiler
      Applikationen stellt besondere Herausforderungen an die Kosteneffizienz der
      Dienst-Entwicklung und die Identifizierung bzw. Befriedigung von
      Kundenbedürfnissen. Klassische Prozesse der Software-Entwicklung können diese
      Anforderungen oftmals nicht erfüllen. In dem vorliegenden Papier wird ein
      Framework vorgestellt, dass durch Integration des Kunden und eine modulare
      Systemarchitektur eine effiziente Entwicklung ermöglicht. Dabei konfigurieren
      Nutzer die Zusammenstellung und das Zusammenspiel von verschieden
      Basisdiensten und generieren dadurch neue Dienste. Durch Community-
      Funktionen können die von einzelnen Nutzern entwickelten Applikationsideen
      weiteren Nutzern verfügbar gemacht werden. In einem evolutionären Prozess
      können diese Dienste durch Beiträge aus der Gemeinschaft der Nutzer weiter
      verbessert werden. Die verschiedenen Iterationen innerhalb des nutzerdominierten
      Entwicklungsprozesses stehen dem Nutzer unmittelbar zur Verfügung, so dass
      durch diverse Anpassungen (Personalisierung) der Basisdienste und der
      Ablauflogik (Workflow-Engine) Schritt für Schritt eine erfolgreiche und
      kundenoptimal gestaltete Anwendung entsteht. Aufgrund der modularen
      Architektur, die sich auf Basisdienste stützt und einer davon abstrahierten
      Ablauflogik, kann das Framework leicht um weitere Basisdienste ergänzt werden
      und ist damit offen für Erweiterungen.



1. Einleitung
Seit der Versteigerung der UMTS-Lizenzen und den damit verbundenen hohen
Investitionen, versuchen die Mobilfunk- und Serviceprovider mögliche „Killer“-
Applikation zu identifizieren. Allerdings stellen die hohen Kosten der Konzeption,
Entwicklung und Markteinführung einer neuen mobilen Applikation und die
Ungewissheit des Markterfolges erhebliche Barrieren dar. Erste ernüchternde Ergebnisse
einiger Mobilfunkbetreiber zeigen, dass bei neu eingeführten mobilen Applikationen -
entwickelt mit klassischen Methoden wie zum Beispiel Marktforschung - die
Wahrscheinlichkeit eines Markterfolges aufgrund verfehlter Kundenbedürfnisse äußerst
gering ist.
Ein Weg der Risikominimierung liegt in einer Optimierung des Entwicklungsprozesses,
wie sie in zum Beispiel in [Dor03] vorgeschlagen wird. Insbesondere Werkzeug-
unterstütztes Rapid Prototyping kann hilfreich bei einer frühzeitigen Kosten/Nutzen-
Analyse sein.

Das vorliegende Papier stellt eine Alternative bzw. eine Ergänzung vor, die durch
Integration der Nutzer in den Entwicklungsprozess und einem Framework bestehend aus
Basisdiensten und einer Workflow-Engine (Ablauflogik) eine schnelle und kosten-
günstige Realisierung mobiler Applikationen ermöglicht. Durch die frühzeitige
Kundenintegration ist sichergestellt, dass die Bedürfnisse der Kunden optimal befriedigt
werden können und der Dienst damit eine hohe Wertschätzung und Zahlungsbereitschaft
bei den Nutzern hervorruft.

In einer ersten Implementierung ist unser Framework bereits für die prototypische
Umsetzung von neuen Anwendungsideen einsetzbar. Für eine Umsetzung und
Skalierung auf ein Live-System von Netz- bzw. Servicebetreibern müssen noch weitere
Integrationsaspekte gelöst werden.

Die Integration des Nutzers bei der Realisierung neuer Innovationen haben u.a. von
Hippel [Hi01] und Thomke [Th02] im Bereich von materiell ausgeprägten Produkten
sehr ausführlich untersucht. Dabei konnte gezeigt werden, dass die Integration des
Nutzers in den Entwicklungsprozess, insbesondere bei „sticky information“, also schwer
explizierbaren Informationen zu den Kundenbedürfnissen, sehr vorteilhaft ist. Außerdem
zeigen Untersuchungen im Bereich von Open–Source-Software-Projekten [Fr01],
[Le00], [He02], dass die Fähigkeit der schnellen Iteration von Dienstversionen und
Community-Mechanismen Entwicklungsvorhaben beschleunigen können und zu
besserer Qualität führen. Daneben konnte gezeigt werden, dass für innovative
Technologien die „technology adoption“ bei der Markteinführung durch frühzeitige
Kundenintegration deutlich beschleunigt werden kann und damit die Wahrscheinlichkeit
für einen Markterfolg erhöht wird.

Unser Framework ermöglicht mit wenigen, aber leistungsfähigen Basisdiensten eine
Vielzahl von Applikationen. Im folgenden Kapitel stellen wir die Gesamtarchitektur
unseres Systems vor. Anschließend beschreiben wir die einzelnen Basisdienste und
veranschaulichen unser Konzept an einem Beispiel.


2. Technisches Konzept
Der oben erläuterte Grundgedanke, den Nutzer bzw. Kunden (auch den technisch
weniger versierten) die Möglichkeit zu geben an der Entwicklung einer mobilen
Applikation mitwirken zu lassen, stellt hohe Anforderungen an die Benutzerschnittstelle
und die Einfachheit eines solchen Konzepts.
Die Gesamtplattform besteht einerseits aus der Logik zur Konstruktion und Ausführung
und andererseits aus einer Kommunikationsplattform zur Diskussion und Evaluierung
der kreierten Applikationen. Jede Applikation, die von einem Benutzer erzeugt wurde,
kann freigeschaltet und der Community zur Weiterentwicklung zur Verfügung gestellt
werden. Ein Versionskontrollsystem und ein mit dem Applikation verknüpftes
„schwarzes Brett“ erlauben eine koordinierte Zusammenarbeit in der Community.

Abbildung 1 stellt die einzelnen Schichten unserer Architektur dar. Die Community-
Komponente wird aus Gründen der Übersichtlichkeit hier nicht dargestellt. Benutzer-
definierte Applikationen werden aus einer Menge von Basisdiensten zusammengestellt.
Die Ausführung der einzelnen Applikationen ist an Ereignisse geknüpft. Ein Event-
Handler überwacht kontinuierlich eingehende Ereignisse und stößt ggf. die ent-
sprechende Anwendung an. Ein Ereignis kann hierbei zum Beispiel an ein Zeitintervall
oder aber an eine Benutzeroberfläche auf dem Endgerät gekoppelt sein. Als Basisdienste
sind in der Abbildung beispielhaft Module für SMS (Short Messaging Service), MMS
(Multimedia Messaging Service), DB (Datenbank) und LES (Location Enabling Service)
ausgewählt, die in der Applikationsschicht kombiniert werden.

                                       Endgerät
                          GUI
                   HTTP        FTP
                                                                      SMS          MMS
            Event Handler


 Applikationsschicht

  Basisdienste

      LES          SMS            MMS             DB                           …

       Abbildung 1: Gesamtarchitektur mit Endgerät (Nutzer/Kunde) und Anbietersystem


2.1 Visuelle Konstruktion

Um ein User-Toolkit zu realisieren, welches intuitiv von einem nicht technik-affinen
Nutzer bedient werden kann, haben wir Elemente visueller Programmiersprachen (VP)
aufgegriffen. VPs verwenden als Basis graphische Symbole. Diese Symbole werden
dann in Graphen als Knoten oder Kanten eingesetzt. In [SIF96] wird eine visuelle
Programmiersprache definiert als

[...] eine formale Sprache mit visueller Syntax oder visueller Semantik zur vollständigen
Beschreibung der Eigenschaften von Software. Syntax und Semantik visueller
Programmiersprachen beziehen meist den zwei- oder dreidimensionalen Raum ein,
während verbale Programmiersprachen auf eindimensionalen Zeichenketten beruhen.
Bekannte Beispiele für visuelle Programmiersprachen sind LabView von National
Instruments [NI03], das besonders für den Bereich der Mess- und Regelungstechnik
verbreitet ist und Lego Mindstorms, zur Programmierung kleiner aus Lego(-Technik)
gebauten Robotern, das in Zusammenarbeit von Lego und dem Massachusetts Institute
of Technology (MIT) entwickelt wurde [LEGO], [Sey93]. Letztere wurde entwickelt,
um Kindern ohne Vorkenntnisse spielerisch das Erlernen einer Programmiersprache zu
ermöglichen und zeigt, dass mit visuellen Programmiersprachen in bestimmten
Domänen tatsächlich Programmierung leichter vermittelt werden kann. Die positiven
Erfahrungen von Lego Mindstorm, als intuitiv bedienbare Programmiersprache, die es
auch Nutzergruppen ohne Vorkenntnisse ermöglicht, Aufgaben zu übernehmen, die
klassischerweise die Kenntnisse einer formalen Programmiersprache voraussetzen, kann
für User-Toolkits fruchtbar eingebracht werden. LabView hingegen ist eine
datenflussorientierte Programmiersprache; ein Konzept an dem sich auch das hier
vorgestellte Framework orientiert.


2.2 Sprachelemente

Unser Ansatz für eine visuelle Sprache ist so einfach wie möglich gehalten, da mit User-
Toolkits insbesondere Applikationen kreiert werden sollen, die eine (Re-)Kombination
bestehender Basisdienste sind und keine hohe Mächtigkeit der visuellen Sprache
erfordern. Der innovative Charakter der Applikation, der durch den User über das
Toolkit eingebracht wird liegt hier mehr in den Kundenbedürfnissen, den marktlichen
Aspekten und den unterschiedlichen Nutzungskontexten. [Hau97] spricht in diesem
Zusammenhang zum einen von zweckinduzierten Innovationen, die mit bestehenden
Mitteln, also einer bestehenden technischen Dienstplattform, einen neuen Zweck, also
eine neue Applikation, erfüllt. Zum anderen von inkrementalen Innovationen, bei denen
Mittel und Zweck zwar prinzipiell unverändert bleiben, jedoch durch neuartige
Kombinationen oder inkrementelle Verbesserungen im Endergebnis eine deutliche
Steigerung erreicht werden kann. Auf mobile Anwendungen übertragen bedeutet dies,
dass die technische Plattform (Basisdienste) unverändert bleibt, jedoch durch
geringfügige Änderungen oder neuartige Kombinationen eine deutliche Verbesserung
der Applikation erreicht werden kann.

Die Sprache besteht aus Diensten, bedingten Anweisungen, zusätzlichen Funktionen und
Konstanten. Schleifen in Form von Graphzyklen sind nicht möglich, um die Komplexität
der Sprache gering zu halten und damit auch mögliche Fehlerquellen bei der
Programmierung durch Nutzer mit wenig Programmierkenntnissen auszuschließen. Im
Folgenden werden die Merkmale der Sprachelemente kurz diskutiert:




                Abbildung 2 Graphische Repräsentation eines Basis-Dienstes
Dienste: Dienste fassen immer eine Menge an Funktionalität einer spezifischen Domäne
zusammen. Da in unserem System Dienste keine Zustände haben, bestehen Dienste aus
einer Menge von Methoden.




  Abbildung 3: Graphische Repräsentation einer Bedingung (if distance) mit bedingtem Dienst
                                      (SMS-Service)
Bedingte Anweisungen: Diese sind nah an die Basisdiensten angelegt. Abstrakte
bedingte Anweisungen sind nicht möglich. Zum Beispiel stellen ortsbezogene
Bedingungen die Verknüpfung der Ortsfunktion mit einem Vergleich dar. Bedingte
Kommunikation überprüft beispielsweise, ob das entsprechende Postfach des Benutzers
eine oder mehrere SMS, MMS oder E-Mails enthält.

Zusätzliche Funktionen: Dazu gehören arithmetische Funktionen und String-Operatoren.

Konstanten: Alle Dienst- und Funktionseingänge können auch mit Konstanten belegt
werden.


2.3 Basisdienste

Im Folgenden führen wir für ein besseres Verständnis des Konzeptes einige Basisdienste
auf, die bereits realisiert wurden:

SMS/MMS: Diese beiden Dienste stellen in erster Linie die Möglichkeit bereit, SMS
bzw. MMS an ein anzugebendes Endgerät zu verschicken. Dazu ist es nötig, den
Empfänger und den Nachrichteninhalt zu spezifizieren. Eine weitere Aufgabe ist der
Abruf empfangener Nachrichten.

Telefon (Sprachdienst): Der Telefondienst verbindet zwei Teilnehmer miteinander,
indem die Sprachkanäle zweier Teilnehmer zusammengeschaltet werden.

In der Kommunikationstechnik ist eine Telefonverbindung im Allgemeinen nicht
zustandslos, sondern es werden hier unterschiedliche Zustände, wie Verbindungsaufbau,
Warten auf Verbindungsannahme usw. unterschieden. Da unser System zustandslos ist,
wartet der Dienst bis beide Teilnehmer erfolgreich verbunden wurden. Etwaige
Störungen bei der Etablierung der Verbindung verarbeitet in diesem Fall die
Ablauflogik.
Location-Services: Der Location-Service lokalisiert einen spezifizierten Benutzer. Der
Rückgabewert ist die Benutzerposition angegeben durch Längen- und Breitengrad.

E-Mail: Wie bei SMS/MMS muss hier auch der Empfänger spezifiziert werden, wobei
bei einem E-Mail-Dienst dies über eine entsprechende Adresse geschieht. Ebenso kann
eine Überschrift und ein Nachrichtentext angegeben werden.

Buddy-List (Kontakt-Liste): Eine Buddy-List ist vergleichbar mit einem privaten
Telefonbuch.

Nutzerinformationen: Das Ergebnis dieses Dienstes sind nähere Informationen über
einen bestimmten Nutzer.


2.4 Konfiguration

Um individuelle Laufzeitparameter zu spezifizieren, wird zu jeder entworfenen
Applikation, immer auch eine Konfiguration erstellt. Zum Beispiel wird in der Entwurf-
phase ein User nur abstrakt in die Anwendung eingebunden. Welcher Benutzer aber
tatsächlich gemeint ist, wird erst in der Konfiguration bestimmt, um den Entwurf von der
eigentlichen Anwendung zu trennen und damit eine bessere gemeinschaftliche Entwick-
lung in der Community zu ermöglichen. Für ein intuitives Verständnis durch den Nutzer
kann die abstrakte Modellierung aber mit einer konkreten Konfiguration belegt werden.


2.5 Ausführung

Die Ausführung übernimmt eine Workflow-Engine, die registrierte Ereignisse verwaltet.
Die Workflow-Engine kann unterschiedliche realisiert sein und soll hier nur in den
prägenden Eigenschaften beschrieben werden. Wenn ein Ereignis eintritt, wird die ent-
sprechende Applikation ausgeführt. In der jetzigen Implementierung können Ereignisse
ausgelöst werden, wenn ein bestimmter Zeitpunkt erreicht ist oder aber eine Nachricht
(SMS, Email, etc) eingegangen ist. Da es sich bei den Anwendungen/Programmen um
einfache Graphen handelt, ist die Ausführungslogik ebenfalls sehr einfach.

2.5.1 Methodenaufrufe
Damit eine Methode ausgeführt werden kann, müssen drei Bedingungen erfüllt sein:

1. Alle benötigten Parameter dieser Funktion müssen mit einem entsprechenden
Rückgabewert einer anderen Methode belegt sein.

2. Alle eingehenden Parameter einer Methode müssen bereits gesetzt sein. Dass
bedeutet, dass Quellfunktionen bzw. Dienste bereits ausgeführt wurden.

3. Ist die Methode innerhalb einer Bedingung, so muss die Bedingung erfüllt sein. Nur
wenn die Bedingungen erfüllt ist, kann eine Methode ausgeführt werden.
Es wird keinerlei Aussage über den Zeitpunkt der Ausführung getroffen. Der
Ausführungszeitpunkt wird autonom vom Interpreter bestimmt.

2.5.2 Beenden der Ausführung
Zur Beendigung einer Applikation kommt es, wenn sich kein Dienst mehr ausführen
lässt. Dies ist der Fall, wenn entweder tatsächlich alle Dienste ausgeführt wurden oder
aber wenn ein Dienst nicht mehr ausgeführt werden kann, weil die Eingangsparameter
nicht gesetzt sind oder gesetzt werden können.

2.5.3 Ausführung eines Programms

Zur Ausführung wird auf Zyklenfreiheit geprüft und dann Sequentialisiert. :

Überprüfung auf Zyklenfreiheit:

Um die prinzipielle Ausführbarkeit des Programms zu gewährleisten, muss sichergestellt
werden, dass der entstandene Graph G zyklenfrei ist. Dies bedeutet in diesem Zusam-
menhang, dass kein Dienst (Knoten des Graphen) direkt oder indirekt von sich selbst
abhängig sein darf. Dazu wird für jeden Teilgraph des Graphen überprüft, ob er nach
dieser Festlegung zyklenfrei ist. Trifft dies für alle Knoten von G zu, so ist auch G
zyklenfrei. Um einen einzelnen Dienst zu überprüfen, muss man zuerst feststellen von
welchen anderen Knoten dieser abhängig ist. Hierbei gibt es zwei unterschiedliche Arten
von Abhängigkeit. Ist festgestellt worden, dass keine Zyklenabhängigkeiten vorhanden
sind, so muss überprüft werden, ob das Programm ausgeführt werden kann. Um die
Ausführung einer Instanz zu gewährleisten, müssen alle benötigten Parameter mit einem
Wert belegt sein.

Sequenzialisierung:

Um das Programm ausführen zu können, muss der zuvor aufgebaute Graph sequentiali-
siert werden. Dies ist nötig, da nicht allen benutzten Instanzen gleich von Anfang an ihre
benötigten Parameter zur Verfügung stehen, sondern diese teilweise erst von anderen
bereitgestellt werden müssen. Um mögliche Startpunkte für die Ausführung zu erhalten,
werden zunächst einmal alle Instanzen gesucht, die keinerlei Abhängigkeiten von an-
deren aufweisen und die nicht das Ziel einer Wertzuweisung oder eine bedingte Instanz
sind. Diese Startpunkte können nun direkt ausgeführt werden, bzw. sind die, die als
erstes ausgeführt werden müssen. Danach wird für jede Instanz, die nicht zu dieser
ersten Gruppe gehört, überprüft, ob alle ihre Parameter von einem Dienst stammen, der
zu der Gruppe der Startpunkte gehört. Ist dies der Fall, so kann der Dienst ausgeführt
werden und wird zu den bereits Ausgeführten hinzugefügt. Im anderen Fall wird einfach
mit dem nächsten Dienst fortgefahren und der gerade geprüfte wird wieder an den
Schluss der Sequenz angehängt. Für bedingte Dienste muss ferner noch überprüft
werden, ob sie aufgrund der Bedingung ausgeführt werden können oder nicht, das heißt,
ob die Bedingung erfüllt ist oder nicht. Dies wird nun solange wiederholt, bis alle
Dienste ausgeführt sind. Dadurch ergibt sich eine mögliche – nicht eindeutige -
Reihenfolge für die Ausführung.
3. Beispielapplikation
An einem Beispiel wollen wir den Toolkit veranschaulichen. Abbildung 4 zeigt den
Dienst „Schwiegermutter-Warner“. In der Entwurfssicht finden sich die einzelnen Basis-
dienste und die Nachrichtenflüsse zwischen den Basisdiensten. Zwei Benutzer werden
lokalisiert und ihr Abstand zueinander wird bestimmt.

Wenn die Benutzer sich näher als 500 m kommen, wird an einen der Benutzer eine SMS
gesendet. In der Konfiguration wird nun noch spezifiziert, um welche Nutzer es sich
handelt. In unserem Fall ist es beispielsweise der Nutzer (also der Dienstentwickler)
selbst und dessen Schwiegermutter.

Wie schon anhand dieser schematischen Beispielapplikation deutlich wird, wirken sich
schon inkrementelle Änderungen der Ablauflogik (z.B. Änderung des Radius von 500m
auf 3km) auf die Charakteristik der mobilen Applikation aus. Durch einen vielfältigen
„Trial and Error“ Prozess durch den Nutzer bzw. die Gemeinschaft der Nutzer und die
evolutionäre Weiterentwicklung der Applikationsidee kann so nach mehreren Iterationen
eine marktfähige und den Kundenbedürfnissen entsprechende Applikation geschaffen
werden [Hi01]. Bei der Gestaltung des „Trial and Error“ Prozesses muss abgewogen
werden, welche Freiräume und welche Restriktionen zugelassen werden, um einerseits
einen großen Möglichkeitsraum zu gewährleisten, andererseits den Prozess sowohl für
den Kunden als auch den Betreiber, insbesondere hinsichtlich der anfallenden Kosten,
attraktiv zu machen. Die (Wertschöpfungs-)Beiträge innerhalb des Entwicklungs-
prozesses kommen dabei maßgeblich vom Kunden/Nutzer und ermöglichen so für einen
Anbieter eine veränderte Kostenstruktur für die Realisierung neuer mobiler
Applikationen. In der Betriebswirtschaft wurde u.a. von Ramirez [Ram99] unter dem
Begriff der “value co-production“, in ähnlichem Kontext die Vorteilhaftigkeit der
Kundenintegration sehr breit diskutiert.
Abbildung 4: Beispielapplikation für einen „Schwiegermutter-Warner“



In der bereits vorliegenden Implementierung des Toolkits (Abbildung 4) kann das
„Look-and-Feel“ der Benutzeroberfläche in unterschiedlichen Designs und mit
verschiedenen Beschriftungen gestaltet werden, um eine intuitiv zugängliche und
nutzerfreundliche Benutzerschnittstelle zu realisieren.


4. Fazit und Ausblick
In dem vorliegenden Papier haben wir einen ersten Entwurf für einen User-Toolkit zur
mobilen Applikationsentwicklung vorgestellt. In der jetzigen Phase ist vor allem noch
nicht geklärt, wie entwickelte Anwendungen in den Normalbetrieb migriert werden
können. Dies soll im Zuge eines 2004 anlaufenden Forschungsprojektes zusammen mit
einem Industriepartner aus dem Bereich ISP bearbeitet werden. Dennoch steht bereits
zum jetzigen Zeitpunkt ein mächtiges Tool zur Verfügung, welches die Möglichkeiten
und Grenzen eines Toolkits für die Entwicklung mobiler Applikationen skizziert.
Literaturverzeichnis
[Dor03] Peter Dornbusch, Martin Huber, Matthias Möller, Rapid Prototyping of mobile
        Applications, Proceedings of 8th International Workshop on Mobile Multimedia
        Communications, 2003 (to appear)
[Fr01] Egon Franck, C. Jungwirth, Open versus Closed Source, Working Paper No. 4,
        Universität Zürich, 2001
[Hau97] Hauschildt, J.: Innovationsmanagement. Franz Vahlen Verlag, München, 2. Auflage,
        1997
[He02] Joachim Henkel,Open Source Software from Commercial Firms – Tools, Complements,
        and Collective Invention, Discussion Paper No. 02-27, German Economic Association of
        Business Adminsitration, 2002
[Hi01] Von Hippel, E.: Perspective: User Toolkits for Innovation, The Journal of Product
        Innovation Management Vol. 18, pp. 247-257., 2001
[Le00] Josh Lerner, Jean Tirole, The Simple Econimics of Open Source, Harvard Business
        School, 2000
[LEGO] Lego, http://mindstorms.lego.com, 2003
[NI]    National Instrument, http://www.ni.com, 2003
[SIF96] Stefan Schiffer, Visuelle Programmierung - Potential und Grenzen, 1996
 [Ra99] Ramirez, R.: Value Co-Production: Intellectual Origins and Implications for Practice and
        Research, Strategic Management Journal, Vol. 20, pp. 49-65., 1999
[Th02] Thomke, S. and von Hippel, E.: Customers as Innovators: A new Way to Create Value,
        Harvard Business Review, Vol. 80, No. 2., 2002

Weitere ähnliche Inhalte

Andere mochten auch

Ejercicio para controlar el estrés
Ejercicio para controlar el estrésEjercicio para controlar el estrés
Ejercicio para controlar el estrés
USET
 
S3 para ser feliz. lindooo(español)
S3 para ser feliz. lindooo(español)S3 para ser feliz. lindooo(español)
S3 para ser feliz. lindooo(español)
USET
 
Personnaliser son site sur ICOM Channel
Personnaliser son site sur ICOM ChannelPersonnaliser son site sur ICOM Channel
Personnaliser son site sur ICOM ChannelI-COM Software
 
S1 encuadre (1)
S1 encuadre (1)S1 encuadre (1)
S1 encuadre (1)
USET
 
Genaro Garcia
Genaro GarciaGenaro Garcia
Genaro Garcia
congresoandicom
 
Presentación Proyecto Centro Guadalinfo Almensilla (Sevilla)
Presentación Proyecto Centro Guadalinfo Almensilla (Sevilla)Presentación Proyecto Centro Guadalinfo Almensilla (Sevilla)
Presentación Proyecto Centro Guadalinfo Almensilla (Sevilla)
Guadalinfo Almensilla
 
Herraminetas 2.0 en educación digital
Herraminetas 2.0 en educación digitalHerraminetas 2.0 en educación digital
Herraminetas 2.0 en educación digital
Guadalinfo Almensilla
 
Powerpoint anniv richard
Powerpoint anniv richardPowerpoint anniv richard
Powerpoint anniv richardmandarine47
 
11 phot d'art_divers
11 phot d'art_divers11 phot d'art_divers
11 phot d'art_diversJuan Nuin
 
Clas 1 unidad 2
Clas 1 unidad 2Clas 1 unidad 2
Clas 1 unidad 2
San Sebastián University
 
Plaquette audimut
Plaquette audimutPlaquette audimut
Plaquette audimut
Phenix Santé Audimut
 
100 Zitate from The secret
100 Zitate from The secret100 Zitate from The secret
100 Zitate from The secret
livecoachforyou
 
Vortrag Zkm
Vortrag ZkmVortrag Zkm
Vortrag Zkm
ZiegsKuchelMueller
 
Campamento crsa detalle
Campamento crsa detalleCampamento crsa detalle
Campamento crsa detalle
USET
 
Contribuer à drupal
Contribuer à drupalContribuer à drupal
Contribuer à drupal
Artusamak
 
Präsentation Gesundheitsspezialisten
Präsentation GesundheitsspezialistenPräsentation Gesundheitsspezialisten
Präsentation Gesundheitsspezialisten
sanushotels
 
Social Media Guideline - A propos de #Twitter
Social Media Guideline - A propos de #TwitterSocial Media Guideline - A propos de #Twitter
Social Media Guideline - A propos de #Twitter
X-PRIME GROUPE
 
Unsere schoene stadt
Unsere schoene stadtUnsere schoene stadt
Unsere schoene stadt
YPEPTH
 
Capacitación de líderes de hombres jóvenes de barrio
Capacitación de líderes de hombres jóvenes de barrioCapacitación de líderes de hombres jóvenes de barrio
Capacitación de líderes de hombres jóvenes de barrio
USET
 

Andere mochten auch (20)

Ejercicio para controlar el estrés
Ejercicio para controlar el estrésEjercicio para controlar el estrés
Ejercicio para controlar el estrés
 
S3 para ser feliz. lindooo(español)
S3 para ser feliz. lindooo(español)S3 para ser feliz. lindooo(español)
S3 para ser feliz. lindooo(español)
 
Personnaliser son site sur ICOM Channel
Personnaliser son site sur ICOM ChannelPersonnaliser son site sur ICOM Channel
Personnaliser son site sur ICOM Channel
 
S1 encuadre (1)
S1 encuadre (1)S1 encuadre (1)
S1 encuadre (1)
 
Genaro Garcia
Genaro GarciaGenaro Garcia
Genaro Garcia
 
Presentación Proyecto Centro Guadalinfo Almensilla (Sevilla)
Presentación Proyecto Centro Guadalinfo Almensilla (Sevilla)Presentación Proyecto Centro Guadalinfo Almensilla (Sevilla)
Presentación Proyecto Centro Guadalinfo Almensilla (Sevilla)
 
Carrière
CarrièreCarrière
Carrière
 
Herraminetas 2.0 en educación digital
Herraminetas 2.0 en educación digitalHerraminetas 2.0 en educación digital
Herraminetas 2.0 en educación digital
 
Powerpoint anniv richard
Powerpoint anniv richardPowerpoint anniv richard
Powerpoint anniv richard
 
11 phot d'art_divers
11 phot d'art_divers11 phot d'art_divers
11 phot d'art_divers
 
Clas 1 unidad 2
Clas 1 unidad 2Clas 1 unidad 2
Clas 1 unidad 2
 
Plaquette audimut
Plaquette audimutPlaquette audimut
Plaquette audimut
 
100 Zitate from The secret
100 Zitate from The secret100 Zitate from The secret
100 Zitate from The secret
 
Vortrag Zkm
Vortrag ZkmVortrag Zkm
Vortrag Zkm
 
Campamento crsa detalle
Campamento crsa detalleCampamento crsa detalle
Campamento crsa detalle
 
Contribuer à drupal
Contribuer à drupalContribuer à drupal
Contribuer à drupal
 
Präsentation Gesundheitsspezialisten
Präsentation GesundheitsspezialistenPräsentation Gesundheitsspezialisten
Präsentation Gesundheitsspezialisten
 
Social Media Guideline - A propos de #Twitter
Social Media Guideline - A propos de #TwitterSocial Media Guideline - A propos de #Twitter
Social Media Guideline - A propos de #Twitter
 
Unsere schoene stadt
Unsere schoene stadtUnsere schoene stadt
Unsere schoene stadt
 
Capacitación de líderes de hombres jóvenes de barrio
Capacitación de líderes de hombres jóvenes de barrioCapacitación de líderes de hombres jóvenes de barrio
Capacitación de líderes de hombres jóvenes de barrio
 

Ähnlich wie ZüRich Ii Mobile App Final V3

Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
Brockhaus Consulting GmbH
 
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
Peter Affolter
 
Zühlke Whitepaper Client Technologien
Zühlke Whitepaper Client TechnologienZühlke Whitepaper Client Technologien
Zühlke Whitepaper Client Technologien
Thomas Memmel
 
Fonda: Erfolgsfaktor Benutzeroberfläche
Fonda: Erfolgsfaktor BenutzeroberflächeFonda: Erfolgsfaktor Benutzeroberfläche
Fonda: Erfolgsfaktor Benutzeroberfläche
Fonda Wien
 
Code-Generierung vereinfacht IoT-Entwicklung
Code-Generierung vereinfacht IoT-EntwicklungCode-Generierung vereinfacht IoT-Entwicklung
Code-Generierung vereinfacht IoT-Entwicklung
bhoeck
 
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Peter Affolter
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Christian Guenther
 
BTEXX Fachartikel: Zukunftssichere Anwendungen mit SAP gestalten
BTEXX Fachartikel: Zukunftssichere Anwendungen mit SAP gestaltenBTEXX Fachartikel: Zukunftssichere Anwendungen mit SAP gestalten
BTEXX Fachartikel: Zukunftssichere Anwendungen mit SAP gestalten
BTEXX GmbH
 
16-seitige Broschüre CompanyMessenger_deutsch
16-seitige Broschüre CompanyMessenger_deutsch16-seitige Broschüre CompanyMessenger_deutsch
16-seitige Broschüre CompanyMessenger_deutsch
Thomas Teufel
 
BTEXX Fachartikel: UCD – Formel für bessere Intranets?
BTEXX Fachartikel: UCD – Formel für bessere Intranets?BTEXX Fachartikel: UCD – Formel für bessere Intranets?
BTEXX Fachartikel: UCD – Formel für bessere Intranets?
BTEXX GmbH
 
Slides zum Impulsreferat: HCL UDP - DNUG Stammtisch Salzburg
Slides zum Impulsreferat: HCL UDP - DNUG Stammtisch SalzburgSlides zum Impulsreferat: HCL UDP - DNUG Stammtisch Salzburg
Slides zum Impulsreferat: HCL UDP - DNUG Stammtisch Salzburg
DNUG e.V.
 
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Thomas Schulz
 
Projektmanagement-Software Leitfaden
Projektmanagement-Software LeitfadenProjektmanagement-Software Leitfaden
Projektmanagement-Software Leitfaden
Projekt Magazin
 
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-StandardMicrosoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Digicomp Academy AG
 
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Peter Affolter
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DNUG e.V.
 
Sponsorenbeschreibung Tools4AgileTeams 2012
Sponsorenbeschreibung Tools4AgileTeams 2012Sponsorenbeschreibung Tools4AgileTeams 2012
Sponsorenbeschreibung Tools4AgileTeams 2012Martin Seibert
 
Zinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.deZinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.de
Kenner Soft Service GmbH
 
Social Software – Status Quo Im Web 2.0
Social Software – Status Quo Im Web 2.0 Social Software – Status Quo Im Web 2.0
Social Software – Status Quo Im Web 2.0 SebStS1
 
Social Software – Status Quo Im Web 2.0
Social Software – Status Quo Im Web 2.0Social Software – Status Quo Im Web 2.0
Social Software – Status Quo Im Web 2.0SebStS1
 

Ähnlich wie ZüRich Ii Mobile App Final V3 (20)

Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
 
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
Artikel Schweizer Bank: SOA als Grundlage für «Composite Applications"​
 
Zühlke Whitepaper Client Technologien
Zühlke Whitepaper Client TechnologienZühlke Whitepaper Client Technologien
Zühlke Whitepaper Client Technologien
 
Fonda: Erfolgsfaktor Benutzeroberfläche
Fonda: Erfolgsfaktor BenutzeroberflächeFonda: Erfolgsfaktor Benutzeroberfläche
Fonda: Erfolgsfaktor Benutzeroberfläche
 
Code-Generierung vereinfacht IoT-Entwicklung
Code-Generierung vereinfacht IoT-EntwicklungCode-Generierung vereinfacht IoT-Entwicklung
Code-Generierung vereinfacht IoT-Entwicklung
 
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
Artikel Professional Computing: Mit SOA zu effizientem Business Process Manag...
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
 
BTEXX Fachartikel: Zukunftssichere Anwendungen mit SAP gestalten
BTEXX Fachartikel: Zukunftssichere Anwendungen mit SAP gestaltenBTEXX Fachartikel: Zukunftssichere Anwendungen mit SAP gestalten
BTEXX Fachartikel: Zukunftssichere Anwendungen mit SAP gestalten
 
16-seitige Broschüre CompanyMessenger_deutsch
16-seitige Broschüre CompanyMessenger_deutsch16-seitige Broschüre CompanyMessenger_deutsch
16-seitige Broschüre CompanyMessenger_deutsch
 
BTEXX Fachartikel: UCD – Formel für bessere Intranets?
BTEXX Fachartikel: UCD – Formel für bessere Intranets?BTEXX Fachartikel: UCD – Formel für bessere Intranets?
BTEXX Fachartikel: UCD – Formel für bessere Intranets?
 
Slides zum Impulsreferat: HCL UDP - DNUG Stammtisch Salzburg
Slides zum Impulsreferat: HCL UDP - DNUG Stammtisch SalzburgSlides zum Impulsreferat: HCL UDP - DNUG Stammtisch Salzburg
Slides zum Impulsreferat: HCL UDP - DNUG Stammtisch Salzburg
 
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
Vorteile und Einsatzfelder integrierter Toolsets zur Modellierung von Manufac...
 
Projektmanagement-Software Leitfaden
Projektmanagement-Software LeitfadenProjektmanagement-Software Leitfaden
Projektmanagement-Software Leitfaden
 
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-StandardMicrosoft Project meets PMBOK - den internationalen Projektmanagement-Standard
Microsoft Project meets PMBOK - den internationalen Projektmanagement-Standard
 
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
Artikel Netzguide eGovernment: Flexible Infrastruktur dank serviceorientierte...
 
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdfDACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
DACHNUG50 Event driven Architecture - Bernd Gewehr - Voessing de.pdf
 
Sponsorenbeschreibung Tools4AgileTeams 2012
Sponsorenbeschreibung Tools4AgileTeams 2012Sponsorenbeschreibung Tools4AgileTeams 2012
Sponsorenbeschreibung Tools4AgileTeams 2012
 
Zinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.deZinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.de
 
Social Software – Status Quo Im Web 2.0
Social Software – Status Quo Im Web 2.0 Social Software – Status Quo Im Web 2.0
Social Software – Status Quo Im Web 2.0
 
Social Software – Status Quo Im Web 2.0
Social Software – Status Quo Im Web 2.0Social Software – Status Quo Im Web 2.0
Social Software – Status Quo Im Web 2.0
 

ZüRich Ii Mobile App Final V3

  • 1. User-Toolkits zur dienstbasierten Entwicklung mobiler Applikationen Peter Dornbusch, Martin Huber CDTM - Center for Digital Technology and Management Arcisstraße 21 - 80290 München dornbusc@in.tum.de; huber@cdtm.de Abstract: Die erfolgreiche Entwicklung und Einführung neuer mobiler Applikationen stellt besondere Herausforderungen an die Kosteneffizienz der Dienst-Entwicklung und die Identifizierung bzw. Befriedigung von Kundenbedürfnissen. Klassische Prozesse der Software-Entwicklung können diese Anforderungen oftmals nicht erfüllen. In dem vorliegenden Papier wird ein Framework vorgestellt, dass durch Integration des Kunden und eine modulare Systemarchitektur eine effiziente Entwicklung ermöglicht. Dabei konfigurieren Nutzer die Zusammenstellung und das Zusammenspiel von verschieden Basisdiensten und generieren dadurch neue Dienste. Durch Community- Funktionen können die von einzelnen Nutzern entwickelten Applikationsideen weiteren Nutzern verfügbar gemacht werden. In einem evolutionären Prozess können diese Dienste durch Beiträge aus der Gemeinschaft der Nutzer weiter verbessert werden. Die verschiedenen Iterationen innerhalb des nutzerdominierten Entwicklungsprozesses stehen dem Nutzer unmittelbar zur Verfügung, so dass durch diverse Anpassungen (Personalisierung) der Basisdienste und der Ablauflogik (Workflow-Engine) Schritt für Schritt eine erfolgreiche und kundenoptimal gestaltete Anwendung entsteht. Aufgrund der modularen Architektur, die sich auf Basisdienste stützt und einer davon abstrahierten Ablauflogik, kann das Framework leicht um weitere Basisdienste ergänzt werden und ist damit offen für Erweiterungen. 1. Einleitung Seit der Versteigerung der UMTS-Lizenzen und den damit verbundenen hohen Investitionen, versuchen die Mobilfunk- und Serviceprovider mögliche „Killer“- Applikation zu identifizieren. Allerdings stellen die hohen Kosten der Konzeption, Entwicklung und Markteinführung einer neuen mobilen Applikation und die Ungewissheit des Markterfolges erhebliche Barrieren dar. Erste ernüchternde Ergebnisse einiger Mobilfunkbetreiber zeigen, dass bei neu eingeführten mobilen Applikationen - entwickelt mit klassischen Methoden wie zum Beispiel Marktforschung - die Wahrscheinlichkeit eines Markterfolges aufgrund verfehlter Kundenbedürfnisse äußerst gering ist.
  • 2. Ein Weg der Risikominimierung liegt in einer Optimierung des Entwicklungsprozesses, wie sie in zum Beispiel in [Dor03] vorgeschlagen wird. Insbesondere Werkzeug- unterstütztes Rapid Prototyping kann hilfreich bei einer frühzeitigen Kosten/Nutzen- Analyse sein. Das vorliegende Papier stellt eine Alternative bzw. eine Ergänzung vor, die durch Integration der Nutzer in den Entwicklungsprozess und einem Framework bestehend aus Basisdiensten und einer Workflow-Engine (Ablauflogik) eine schnelle und kosten- günstige Realisierung mobiler Applikationen ermöglicht. Durch die frühzeitige Kundenintegration ist sichergestellt, dass die Bedürfnisse der Kunden optimal befriedigt werden können und der Dienst damit eine hohe Wertschätzung und Zahlungsbereitschaft bei den Nutzern hervorruft. In einer ersten Implementierung ist unser Framework bereits für die prototypische Umsetzung von neuen Anwendungsideen einsetzbar. Für eine Umsetzung und Skalierung auf ein Live-System von Netz- bzw. Servicebetreibern müssen noch weitere Integrationsaspekte gelöst werden. Die Integration des Nutzers bei der Realisierung neuer Innovationen haben u.a. von Hippel [Hi01] und Thomke [Th02] im Bereich von materiell ausgeprägten Produkten sehr ausführlich untersucht. Dabei konnte gezeigt werden, dass die Integration des Nutzers in den Entwicklungsprozess, insbesondere bei „sticky information“, also schwer explizierbaren Informationen zu den Kundenbedürfnissen, sehr vorteilhaft ist. Außerdem zeigen Untersuchungen im Bereich von Open–Source-Software-Projekten [Fr01], [Le00], [He02], dass die Fähigkeit der schnellen Iteration von Dienstversionen und Community-Mechanismen Entwicklungsvorhaben beschleunigen können und zu besserer Qualität führen. Daneben konnte gezeigt werden, dass für innovative Technologien die „technology adoption“ bei der Markteinführung durch frühzeitige Kundenintegration deutlich beschleunigt werden kann und damit die Wahrscheinlichkeit für einen Markterfolg erhöht wird. Unser Framework ermöglicht mit wenigen, aber leistungsfähigen Basisdiensten eine Vielzahl von Applikationen. Im folgenden Kapitel stellen wir die Gesamtarchitektur unseres Systems vor. Anschließend beschreiben wir die einzelnen Basisdienste und veranschaulichen unser Konzept an einem Beispiel. 2. Technisches Konzept Der oben erläuterte Grundgedanke, den Nutzer bzw. Kunden (auch den technisch weniger versierten) die Möglichkeit zu geben an der Entwicklung einer mobilen Applikation mitwirken zu lassen, stellt hohe Anforderungen an die Benutzerschnittstelle und die Einfachheit eines solchen Konzepts.
  • 3. Die Gesamtplattform besteht einerseits aus der Logik zur Konstruktion und Ausführung und andererseits aus einer Kommunikationsplattform zur Diskussion und Evaluierung der kreierten Applikationen. Jede Applikation, die von einem Benutzer erzeugt wurde, kann freigeschaltet und der Community zur Weiterentwicklung zur Verfügung gestellt werden. Ein Versionskontrollsystem und ein mit dem Applikation verknüpftes „schwarzes Brett“ erlauben eine koordinierte Zusammenarbeit in der Community. Abbildung 1 stellt die einzelnen Schichten unserer Architektur dar. Die Community- Komponente wird aus Gründen der Übersichtlichkeit hier nicht dargestellt. Benutzer- definierte Applikationen werden aus einer Menge von Basisdiensten zusammengestellt. Die Ausführung der einzelnen Applikationen ist an Ereignisse geknüpft. Ein Event- Handler überwacht kontinuierlich eingehende Ereignisse und stößt ggf. die ent- sprechende Anwendung an. Ein Ereignis kann hierbei zum Beispiel an ein Zeitintervall oder aber an eine Benutzeroberfläche auf dem Endgerät gekoppelt sein. Als Basisdienste sind in der Abbildung beispielhaft Module für SMS (Short Messaging Service), MMS (Multimedia Messaging Service), DB (Datenbank) und LES (Location Enabling Service) ausgewählt, die in der Applikationsschicht kombiniert werden. Endgerät GUI HTTP FTP SMS MMS Event Handler Applikationsschicht Basisdienste LES SMS MMS DB … Abbildung 1: Gesamtarchitektur mit Endgerät (Nutzer/Kunde) und Anbietersystem 2.1 Visuelle Konstruktion Um ein User-Toolkit zu realisieren, welches intuitiv von einem nicht technik-affinen Nutzer bedient werden kann, haben wir Elemente visueller Programmiersprachen (VP) aufgegriffen. VPs verwenden als Basis graphische Symbole. Diese Symbole werden dann in Graphen als Knoten oder Kanten eingesetzt. In [SIF96] wird eine visuelle Programmiersprache definiert als [...] eine formale Sprache mit visueller Syntax oder visueller Semantik zur vollständigen Beschreibung der Eigenschaften von Software. Syntax und Semantik visueller Programmiersprachen beziehen meist den zwei- oder dreidimensionalen Raum ein, während verbale Programmiersprachen auf eindimensionalen Zeichenketten beruhen.
  • 4. Bekannte Beispiele für visuelle Programmiersprachen sind LabView von National Instruments [NI03], das besonders für den Bereich der Mess- und Regelungstechnik verbreitet ist und Lego Mindstorms, zur Programmierung kleiner aus Lego(-Technik) gebauten Robotern, das in Zusammenarbeit von Lego und dem Massachusetts Institute of Technology (MIT) entwickelt wurde [LEGO], [Sey93]. Letztere wurde entwickelt, um Kindern ohne Vorkenntnisse spielerisch das Erlernen einer Programmiersprache zu ermöglichen und zeigt, dass mit visuellen Programmiersprachen in bestimmten Domänen tatsächlich Programmierung leichter vermittelt werden kann. Die positiven Erfahrungen von Lego Mindstorm, als intuitiv bedienbare Programmiersprache, die es auch Nutzergruppen ohne Vorkenntnisse ermöglicht, Aufgaben zu übernehmen, die klassischerweise die Kenntnisse einer formalen Programmiersprache voraussetzen, kann für User-Toolkits fruchtbar eingebracht werden. LabView hingegen ist eine datenflussorientierte Programmiersprache; ein Konzept an dem sich auch das hier vorgestellte Framework orientiert. 2.2 Sprachelemente Unser Ansatz für eine visuelle Sprache ist so einfach wie möglich gehalten, da mit User- Toolkits insbesondere Applikationen kreiert werden sollen, die eine (Re-)Kombination bestehender Basisdienste sind und keine hohe Mächtigkeit der visuellen Sprache erfordern. Der innovative Charakter der Applikation, der durch den User über das Toolkit eingebracht wird liegt hier mehr in den Kundenbedürfnissen, den marktlichen Aspekten und den unterschiedlichen Nutzungskontexten. [Hau97] spricht in diesem Zusammenhang zum einen von zweckinduzierten Innovationen, die mit bestehenden Mitteln, also einer bestehenden technischen Dienstplattform, einen neuen Zweck, also eine neue Applikation, erfüllt. Zum anderen von inkrementalen Innovationen, bei denen Mittel und Zweck zwar prinzipiell unverändert bleiben, jedoch durch neuartige Kombinationen oder inkrementelle Verbesserungen im Endergebnis eine deutliche Steigerung erreicht werden kann. Auf mobile Anwendungen übertragen bedeutet dies, dass die technische Plattform (Basisdienste) unverändert bleibt, jedoch durch geringfügige Änderungen oder neuartige Kombinationen eine deutliche Verbesserung der Applikation erreicht werden kann. Die Sprache besteht aus Diensten, bedingten Anweisungen, zusätzlichen Funktionen und Konstanten. Schleifen in Form von Graphzyklen sind nicht möglich, um die Komplexität der Sprache gering zu halten und damit auch mögliche Fehlerquellen bei der Programmierung durch Nutzer mit wenig Programmierkenntnissen auszuschließen. Im Folgenden werden die Merkmale der Sprachelemente kurz diskutiert: Abbildung 2 Graphische Repräsentation eines Basis-Dienstes
  • 5. Dienste: Dienste fassen immer eine Menge an Funktionalität einer spezifischen Domäne zusammen. Da in unserem System Dienste keine Zustände haben, bestehen Dienste aus einer Menge von Methoden. Abbildung 3: Graphische Repräsentation einer Bedingung (if distance) mit bedingtem Dienst (SMS-Service) Bedingte Anweisungen: Diese sind nah an die Basisdiensten angelegt. Abstrakte bedingte Anweisungen sind nicht möglich. Zum Beispiel stellen ortsbezogene Bedingungen die Verknüpfung der Ortsfunktion mit einem Vergleich dar. Bedingte Kommunikation überprüft beispielsweise, ob das entsprechende Postfach des Benutzers eine oder mehrere SMS, MMS oder E-Mails enthält. Zusätzliche Funktionen: Dazu gehören arithmetische Funktionen und String-Operatoren. Konstanten: Alle Dienst- und Funktionseingänge können auch mit Konstanten belegt werden. 2.3 Basisdienste Im Folgenden führen wir für ein besseres Verständnis des Konzeptes einige Basisdienste auf, die bereits realisiert wurden: SMS/MMS: Diese beiden Dienste stellen in erster Linie die Möglichkeit bereit, SMS bzw. MMS an ein anzugebendes Endgerät zu verschicken. Dazu ist es nötig, den Empfänger und den Nachrichteninhalt zu spezifizieren. Eine weitere Aufgabe ist der Abruf empfangener Nachrichten. Telefon (Sprachdienst): Der Telefondienst verbindet zwei Teilnehmer miteinander, indem die Sprachkanäle zweier Teilnehmer zusammengeschaltet werden. In der Kommunikationstechnik ist eine Telefonverbindung im Allgemeinen nicht zustandslos, sondern es werden hier unterschiedliche Zustände, wie Verbindungsaufbau, Warten auf Verbindungsannahme usw. unterschieden. Da unser System zustandslos ist, wartet der Dienst bis beide Teilnehmer erfolgreich verbunden wurden. Etwaige Störungen bei der Etablierung der Verbindung verarbeitet in diesem Fall die Ablauflogik.
  • 6. Location-Services: Der Location-Service lokalisiert einen spezifizierten Benutzer. Der Rückgabewert ist die Benutzerposition angegeben durch Längen- und Breitengrad. E-Mail: Wie bei SMS/MMS muss hier auch der Empfänger spezifiziert werden, wobei bei einem E-Mail-Dienst dies über eine entsprechende Adresse geschieht. Ebenso kann eine Überschrift und ein Nachrichtentext angegeben werden. Buddy-List (Kontakt-Liste): Eine Buddy-List ist vergleichbar mit einem privaten Telefonbuch. Nutzerinformationen: Das Ergebnis dieses Dienstes sind nähere Informationen über einen bestimmten Nutzer. 2.4 Konfiguration Um individuelle Laufzeitparameter zu spezifizieren, wird zu jeder entworfenen Applikation, immer auch eine Konfiguration erstellt. Zum Beispiel wird in der Entwurf- phase ein User nur abstrakt in die Anwendung eingebunden. Welcher Benutzer aber tatsächlich gemeint ist, wird erst in der Konfiguration bestimmt, um den Entwurf von der eigentlichen Anwendung zu trennen und damit eine bessere gemeinschaftliche Entwick- lung in der Community zu ermöglichen. Für ein intuitives Verständnis durch den Nutzer kann die abstrakte Modellierung aber mit einer konkreten Konfiguration belegt werden. 2.5 Ausführung Die Ausführung übernimmt eine Workflow-Engine, die registrierte Ereignisse verwaltet. Die Workflow-Engine kann unterschiedliche realisiert sein und soll hier nur in den prägenden Eigenschaften beschrieben werden. Wenn ein Ereignis eintritt, wird die ent- sprechende Applikation ausgeführt. In der jetzigen Implementierung können Ereignisse ausgelöst werden, wenn ein bestimmter Zeitpunkt erreicht ist oder aber eine Nachricht (SMS, Email, etc) eingegangen ist. Da es sich bei den Anwendungen/Programmen um einfache Graphen handelt, ist die Ausführungslogik ebenfalls sehr einfach. 2.5.1 Methodenaufrufe Damit eine Methode ausgeführt werden kann, müssen drei Bedingungen erfüllt sein: 1. Alle benötigten Parameter dieser Funktion müssen mit einem entsprechenden Rückgabewert einer anderen Methode belegt sein. 2. Alle eingehenden Parameter einer Methode müssen bereits gesetzt sein. Dass bedeutet, dass Quellfunktionen bzw. Dienste bereits ausgeführt wurden. 3. Ist die Methode innerhalb einer Bedingung, so muss die Bedingung erfüllt sein. Nur wenn die Bedingungen erfüllt ist, kann eine Methode ausgeführt werden.
  • 7. Es wird keinerlei Aussage über den Zeitpunkt der Ausführung getroffen. Der Ausführungszeitpunkt wird autonom vom Interpreter bestimmt. 2.5.2 Beenden der Ausführung Zur Beendigung einer Applikation kommt es, wenn sich kein Dienst mehr ausführen lässt. Dies ist der Fall, wenn entweder tatsächlich alle Dienste ausgeführt wurden oder aber wenn ein Dienst nicht mehr ausgeführt werden kann, weil die Eingangsparameter nicht gesetzt sind oder gesetzt werden können. 2.5.3 Ausführung eines Programms Zur Ausführung wird auf Zyklenfreiheit geprüft und dann Sequentialisiert. : Überprüfung auf Zyklenfreiheit: Um die prinzipielle Ausführbarkeit des Programms zu gewährleisten, muss sichergestellt werden, dass der entstandene Graph G zyklenfrei ist. Dies bedeutet in diesem Zusam- menhang, dass kein Dienst (Knoten des Graphen) direkt oder indirekt von sich selbst abhängig sein darf. Dazu wird für jeden Teilgraph des Graphen überprüft, ob er nach dieser Festlegung zyklenfrei ist. Trifft dies für alle Knoten von G zu, so ist auch G zyklenfrei. Um einen einzelnen Dienst zu überprüfen, muss man zuerst feststellen von welchen anderen Knoten dieser abhängig ist. Hierbei gibt es zwei unterschiedliche Arten von Abhängigkeit. Ist festgestellt worden, dass keine Zyklenabhängigkeiten vorhanden sind, so muss überprüft werden, ob das Programm ausgeführt werden kann. Um die Ausführung einer Instanz zu gewährleisten, müssen alle benötigten Parameter mit einem Wert belegt sein. Sequenzialisierung: Um das Programm ausführen zu können, muss der zuvor aufgebaute Graph sequentiali- siert werden. Dies ist nötig, da nicht allen benutzten Instanzen gleich von Anfang an ihre benötigten Parameter zur Verfügung stehen, sondern diese teilweise erst von anderen bereitgestellt werden müssen. Um mögliche Startpunkte für die Ausführung zu erhalten, werden zunächst einmal alle Instanzen gesucht, die keinerlei Abhängigkeiten von an- deren aufweisen und die nicht das Ziel einer Wertzuweisung oder eine bedingte Instanz sind. Diese Startpunkte können nun direkt ausgeführt werden, bzw. sind die, die als erstes ausgeführt werden müssen. Danach wird für jede Instanz, die nicht zu dieser ersten Gruppe gehört, überprüft, ob alle ihre Parameter von einem Dienst stammen, der zu der Gruppe der Startpunkte gehört. Ist dies der Fall, so kann der Dienst ausgeführt werden und wird zu den bereits Ausgeführten hinzugefügt. Im anderen Fall wird einfach mit dem nächsten Dienst fortgefahren und der gerade geprüfte wird wieder an den Schluss der Sequenz angehängt. Für bedingte Dienste muss ferner noch überprüft werden, ob sie aufgrund der Bedingung ausgeführt werden können oder nicht, das heißt, ob die Bedingung erfüllt ist oder nicht. Dies wird nun solange wiederholt, bis alle Dienste ausgeführt sind. Dadurch ergibt sich eine mögliche – nicht eindeutige - Reihenfolge für die Ausführung.
  • 8. 3. Beispielapplikation An einem Beispiel wollen wir den Toolkit veranschaulichen. Abbildung 4 zeigt den Dienst „Schwiegermutter-Warner“. In der Entwurfssicht finden sich die einzelnen Basis- dienste und die Nachrichtenflüsse zwischen den Basisdiensten. Zwei Benutzer werden lokalisiert und ihr Abstand zueinander wird bestimmt. Wenn die Benutzer sich näher als 500 m kommen, wird an einen der Benutzer eine SMS gesendet. In der Konfiguration wird nun noch spezifiziert, um welche Nutzer es sich handelt. In unserem Fall ist es beispielsweise der Nutzer (also der Dienstentwickler) selbst und dessen Schwiegermutter. Wie schon anhand dieser schematischen Beispielapplikation deutlich wird, wirken sich schon inkrementelle Änderungen der Ablauflogik (z.B. Änderung des Radius von 500m auf 3km) auf die Charakteristik der mobilen Applikation aus. Durch einen vielfältigen „Trial and Error“ Prozess durch den Nutzer bzw. die Gemeinschaft der Nutzer und die evolutionäre Weiterentwicklung der Applikationsidee kann so nach mehreren Iterationen eine marktfähige und den Kundenbedürfnissen entsprechende Applikation geschaffen werden [Hi01]. Bei der Gestaltung des „Trial and Error“ Prozesses muss abgewogen werden, welche Freiräume und welche Restriktionen zugelassen werden, um einerseits einen großen Möglichkeitsraum zu gewährleisten, andererseits den Prozess sowohl für den Kunden als auch den Betreiber, insbesondere hinsichtlich der anfallenden Kosten, attraktiv zu machen. Die (Wertschöpfungs-)Beiträge innerhalb des Entwicklungs- prozesses kommen dabei maßgeblich vom Kunden/Nutzer und ermöglichen so für einen Anbieter eine veränderte Kostenstruktur für die Realisierung neuer mobiler Applikationen. In der Betriebswirtschaft wurde u.a. von Ramirez [Ram99] unter dem Begriff der “value co-production“, in ähnlichem Kontext die Vorteilhaftigkeit der Kundenintegration sehr breit diskutiert.
  • 9. Abbildung 4: Beispielapplikation für einen „Schwiegermutter-Warner“ In der bereits vorliegenden Implementierung des Toolkits (Abbildung 4) kann das „Look-and-Feel“ der Benutzeroberfläche in unterschiedlichen Designs und mit verschiedenen Beschriftungen gestaltet werden, um eine intuitiv zugängliche und nutzerfreundliche Benutzerschnittstelle zu realisieren. 4. Fazit und Ausblick In dem vorliegenden Papier haben wir einen ersten Entwurf für einen User-Toolkit zur mobilen Applikationsentwicklung vorgestellt. In der jetzigen Phase ist vor allem noch nicht geklärt, wie entwickelte Anwendungen in den Normalbetrieb migriert werden können. Dies soll im Zuge eines 2004 anlaufenden Forschungsprojektes zusammen mit einem Industriepartner aus dem Bereich ISP bearbeitet werden. Dennoch steht bereits zum jetzigen Zeitpunkt ein mächtiges Tool zur Verfügung, welches die Möglichkeiten und Grenzen eines Toolkits für die Entwicklung mobiler Applikationen skizziert.
  • 10. Literaturverzeichnis [Dor03] Peter Dornbusch, Martin Huber, Matthias Möller, Rapid Prototyping of mobile Applications, Proceedings of 8th International Workshop on Mobile Multimedia Communications, 2003 (to appear) [Fr01] Egon Franck, C. Jungwirth, Open versus Closed Source, Working Paper No. 4, Universität Zürich, 2001 [Hau97] Hauschildt, J.: Innovationsmanagement. Franz Vahlen Verlag, München, 2. Auflage, 1997 [He02] Joachim Henkel,Open Source Software from Commercial Firms – Tools, Complements, and Collective Invention, Discussion Paper No. 02-27, German Economic Association of Business Adminsitration, 2002 [Hi01] Von Hippel, E.: Perspective: User Toolkits for Innovation, The Journal of Product Innovation Management Vol. 18, pp. 247-257., 2001 [Le00] Josh Lerner, Jean Tirole, The Simple Econimics of Open Source, Harvard Business School, 2000 [LEGO] Lego, http://mindstorms.lego.com, 2003 [NI] National Instrument, http://www.ni.com, 2003 [SIF96] Stefan Schiffer, Visuelle Programmierung - Potential und Grenzen, 1996 [Ra99] Ramirez, R.: Value Co-Production: Intellectual Origins and Implications for Practice and Research, Strategic Management Journal, Vol. 20, pp. 49-65., 1999 [Th02] Thomke, S. and von Hippel, E.: Customers as Innovators: A new Way to Create Value, Harvard Business Review, Vol. 80, No. 2., 2002