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