ID 6507
Tiedemann, Marcus: Informationstransfer von Webdiensten zu mobilen Geräten mit
J2ME
Hamburg: Diplomica GmbH, 2003
Zugl.: Fachhochschule Südwestfalen, Technische Universität, Diplomarbeit, 2003
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2003
Printed in Germany
Kurzfassung
Unabhängig vom technischen Fortschritt werden mobile und/oder drahtlose Geräte
im Vergleich zu stationären immer einige Nachteile aufweisen, insbesondere im
Hinblick auf die Display-Größe, die Eingabe-Möglichkeiten, den verfügbaren Spei-
cher und die für Übertragungen zur Verfügung stehende Bandbreite.
Im Rahmen dieser Arbeit wird ein Mechanismus entwickelt, der Anfragen an Web-
dienste entgegen nimmt und deren Resultate in einem für den jeweiligen Client op-
timierten Format zurück sendet. Dieses System wird zunächst mit Hilfe der Unified
Modeling Language und der Spezifikations-Sprache TROLL modelliert. Anschlie-
ßend wird die Funktionalität durch eine Implementierung am Beispiel von Wörter-
buch-Anfragen demonstriert.
Abstract
Independent of the technical progress, mobile and/or wireless devices will always
possess some disadvantages in comparison to stationary ones, especially with regard
to the display-size, the possibilities of input, and the available memory and band-
width.
In this thesis a mechanism is designed, which receives requests to web services and
sends the results back in a format optimized for the respective client. This system is
at first modeled by using the Unified Modeling Language and the specification lan-
guage TROLL. Subsequently, the functionality is demonstrated by an implementa-
tion considering as example requests to an online dictionary.
I
NHALTS
-V
ERZEICHNIS
I
Inhaltsverzeichnis
Kapitel 1: Einleitung und Aufgabenstellung ... 1
Kapitel 2: Grundlagen ... 3
2.1 Grundlagen der Mobilkommunikation... 3
2.1.1 Mobile und drahtlose Kommunikation ... 3
2.1.2 Anwendungen ... 5
2.1.3 Mobile und drahtlose Endgeräte ... 7
2.1.4 Drahtlose
Telekommunikations-Systeme ... 7
2.2 Mobilität in verteilten Berechnungen ... 8
2.3 Link Everything Online (LEO) ... 10
2.3.1 Geschichtlicher
Überblick... 10
2.3.2 Das
Online-Wörterbuch ... 11
Kapitel 3: Die Unified Modeling Language ... 15
3.1 Grundlagen und historische Entwicklung... 15
3.2 Meta-Modellierung und Erweiterungs-Mechanismen ... 16
3.3 Anwendungsfall-Diagramme ... 17
3.4 Sequenz-Diagramme... 20
3.5 Kollaborations-Diagramme... 22
3.6 Klassen-Diagramme... 22
3.7 Zustands-Diagramme ... 25
3.8 Aktivitäts-Diagramme... 29
Kapitel 4: TROLL ... 32
4.1 Entstehungsgeschichte und Grundlagen ... 32
4.2 Die Übertragung der UML-Bestandteile auf die TROLL-Konstrukte... 34
4.2.1 Die
Objekt-Klassen ... 34
4.2.1.1 Die Objekt-Klasse Midlet... 36
4.2.1.2 Die Objekt-Klasse HTML-Formular... 37
4.2.1.3 Die Objekt-Klasse Servlet ... 38
4.2.1.4 Die Objekt-Klasse ExtractData... 39
4.2.2 Die
Subsysteme ... 41
4.2.2.1 Das Midlet-Subsystem ... 42
4.2.2.2 Das HTML-Formular-Subsystem ... 43
4.2.2.3 Das Servlet-Subsystem ... 43
4.2.3 Das gesamte Objekt-System ... 45
I
NHALTS
-V
ERZEICHNIS
II
Kapitel 5: Die Java 2 Micro Edition ... 47
5.1 Die Betriebssystem-Schicht ... 49
5.2 Die Virtuelle Maschine ... 51
5.2.1 Die Connected Virtual Machine (CVM)... 51
5.2.2 Die Kilobyte Virtual Machine (KVM)... 51
5.3 Die Konfigurations-Schicht ... 53
5.3.1 Die Connected Limited Device Configuration (CLDC) ... 54
5.3.2 Die Connected Device Configuration (CDC) ... 55
5.4 Die Profil-Schicht ... 56
5.4.1 Das Mobile Information Device Profile (MIDP) ... 56
5.4.1.1 Der Lebenszyklus eines Midlets ... 57
5.4.1.2 Netzwerk-Unterstützung ... 61
5.4.1.3 Benutzer-Schnittstellen ... 64
5.4.1.4 Persistente Speicherung ... 67
5.4.2 Andere
Profile ... 68
5.5 Das Kompilieren und Ausführen von J2ME-Programmen... 69
Kapitel 6: Die Implementierung ... 72
6.1 Das Benutzer-Handbuch ... 72
6.1.1 Das
HTML-Formular ... 72
6.1.2 Das
Midlet... 75
6.2 Die interne Realisierung der Funktionalitäten ... 80
6.2.1 Das
HTML-Formular ... 82
6.2.2 Das
Midlet... 83
6.2.2.1 Der Speicher-Verbrauch zentraler Datentypen ... 83
6.2.2.2 Die Verbindung zum Servlet... 87
6.2.2.3 Die Abspeicherung der übermittelten Wortpaare ... 89
6.2.3 Das
Servlet ... 93
6.2.3.1 Die Skalierbarkeit ... 94
6.2.3.2 Die Kommunikation mit dem Midlet und dem HTML-Formular 96
I
NHALTS
-V
ERZEICHNIS
III
Kapitel 7: Alternativen ... 98
7.1 Alternativen zum LEO-Online-Wörterbuch ... 98
7.2 Alternativen zum Servlet ... 100
7.3 Alternativen zu J2ME ... 102
7.3.1 WAP... 102
7.3.1.1 Grundlagen und Funktionsweise... 102
7.3.1.2 Vergleich von WAP und J2ME / MIDP ... 105
7.3.2 BREW ... 106
7.3.2.1 Grundlagen und Funktionsweise... 106
7.3.2.2 Vergleich von BREW und J2ME... 107
Kapitel 8: Zusammenfassung und Ausblick ... 109
Anhang: Drahtlose Telekommunikations-Systeme ... 111
A
BKÜRZUNGS
-V
ERZEICHNIS
IV
Abkürzungs-Verzeichnis
AMPS
Advanced Mobile Phone System
API
Application Programming Interface
AWT
Abstract Window Toolkit
AuC
Authentifizierungs-Zentrale (Authentication Centre)
BDS
BREW-Distributions-System
bps
bytes per second
BREW
Binary Runtime Environment for Wireless
BSC
Feststations-Steuerung (Base Station Controller)
BSS
Feststations-System (Base Station Subsystem)
BTS
Sende-/Empfangs-Stationen (Base Transceiver Station)
CDC
Connected Device Configuration
CDMA
Code Division Multiple Access
CE
Compact
Edition
CEO
Chief Executive Officer
CLDC
Connected Limited Device Configuration
CORBA
Common Object Request Broker Architecture
CPU
Central Processing Unit
CVM
Connected Virtual Machine
EIR
Geräteidentifikations-Register (Equipment Identity Register)
EJB
Enterprise Java Bean
FTP
File Transfer Protocol
GCF
Generic Connection Framework
GPRS
General Packet Radio Service
GPS
Global Positioning System
GSM
Groupe Spéciale Mobile, Global System for Mobile Communication
HLR
Heimat-Register (Home Location Register)
HSCSD
High Speed Circuit Switched Data (Kanalbündelung)
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
ISAR
Informationssysteme und Archiv München
ITU
International Telecommunication Union
J2EE
Java 2 Enterprise Edition
J2ME
Java 2 Micro Edition
J2SE
Java 2 Standard Edition
JAD
Java Application Descriptor
A
BKÜRZUNGS
-V
ERZEICHNIS
V
JAR
Java
Archive
JDBC
Java Database Connectivity
JNI
Java Native Interface
JSP
Java Server Page
JVM
Java Virtual Machine
KB
Kilobyte
KVM
Kilobyte Virtual Machine
LEO
Link Everything Online
MB
Megabyte
MHz
Megahertz
MIDP
Mobile Information Device Profile
MIV
Münchner
Informations-Verbund
MS
Mobilstation
MSC
Dienstvermittlungs-Stellen (Mobile Services Switching Centre)
NMT
Nordic Mobile Telephone System
NSS
Mobilvermittlungs-System (Network and Switching Subsystem)
ODiMoD
Online Dictionary for Mobile Devices
OMC
Betriebs- und Wartungs-Zentrale (Operation and Maintenance Centre)
OMG
Object Management Group
OS
Betriebssystem (Operating System)
OSS
Betriebs- und Wartungs-System (Operation Subsystem)
PC
Personal
Computer
PDA
Personal Digital Assistent
PDAP
PDA Profile
RAM
Random Access Memory
RMI
Remote Method Invocation
ROM
Read Only Memory
RSS
Funk-Feststations-System (Radio Subsystem)
SDK
Software Developer's Kit
SIM
Subscriber Identity Module
SMS
Short Message Service
TCP
Transmission Control Protocol
TCP/IP
Transmission Control Protocol / Internet Protocol
TROLL
Textual Representation Object Logic Language
TV
Fernsehen
(Television)
UDP
User Datagram Protocol
UML
Unified Modeling Language
A
BKÜRZUNGS
-V
ERZEICHNIS
VI
UMTS
Universal Mobile Telecommunication System
URL
Uniform Resource Locator
VLR
Besucher-Register (Visitor Location Register)
WAP
Wireless Application Protocol
WML
Wireless Markup Language
WWW
World Wide Web
XML
Extensible Markup Language
K
APITEL
1: E
INLEITUNG UND
A
UFGABENSTELLUNG
1
K
K
A
A
P
P
I
I
T
T
E
E
L
L
1
1
:
:
E
E
I
I
N
N
L
L
E
E
I
I
T
T
U
U
N
N
G
G
U
U
N
N
D
D
A
A
U
U
F
F
G
G
A
A
B
B
E
E
N
N
S
S
T
T
E
E
L
L
L
L
U
U
N
N
G
G
1
Niemand kann exakt vorhersagen, wie die Computer in zehn oder zwanzig Jahren
aussehen werden. Nur ein Trend ist erkennbar: sehr viele Computer werden portabel
sein und sich drahtloser Technik bedienen, wie z.B. Notebooks oder Palmtops.
Natürlich wird sich der technische Fortschritt auch in diesem Gebiet weiter entwi-
ckeln, aber es ist anzunehmen, dass in absehbarer Zeit die Nachteile bzw. Beschrän-
kungen von mobilen Geräten z.B. bezüglich Display-Größe, Prozessor-Leistung,
Bandbreite und Speicher-Kapazität
1
gegenüber stationären bestehen bleiben werden
[JWH97].
Das Internet wird diesem Trend bislang allerdings nicht gerecht, denn die Hauptlast
des Auffindens und vor allem des Sondierens von relevanten Informationen bzw. des
Aussortierens von Unwichtigem liegt beim Nutzer und verbraucht damit Ressourcen
auf dessen Endgerät [JWH97].
Auch werden von Informations-Systemen große Datenmengen übertragen, unabhän-
gig davon, ob das Display des Endgeräts in der Lage ist, diese zufrieden stellend an-
zuzeigen, oder ob sein Speicher groß genug ist, sie aufzunehmen.
Die Konsequenz ist, dass es vorkommen kann, dass ein mobiles Gerät theoretisch
durchaus fähig wäre, bestimmte gesuchte Daten zu empfangen und auch zu verarbei-
ten, es aber praktisch daran scheitert, dass die gleichzeitig übertragene Menge zu
groß für den verfügbaren Speicher ist und/oder das übermittelte Format (z.B. HTML)
nicht vernünftig gelesen bzw. angezeigt werden kann. Und auch schon das Übertra-
gen von großen Datenmengen, von denen am Ende nur ein kleiner Teil gebraucht
wird, sollte aus Gründen der begrenzten Energie vermieden werden.
Eine Lösung dieses Problems wäre, ein zweites Internet zu schaffen, nämlich eines
für mobile Geräte (bzw. allgemein solche mit beschränkten Ressourcen) neben dem
bisherigen, welches dann für ressourcenstärkere, also im wesentlichen stationäre Ge-
räte zuständig wäre. Dieser Ansatz würde aber deutlich zu weit gehen, denn die an-
geforderten Informationen selbst unterscheiden sich ja zum Großteil nicht, nur eben
z.B. die gleichzeitig übertragene Menge oder das Format der Anzeige.
1
Die Unterschiede zwischen mobilen und stationären Geräten werden ausführlich in Kapitel 2 be-
schrieben.
K
APITEL
1: E
INLEITUNG UND
A
UFGABENSTELLUNG
2
Die weitaus effizientere Lösung wäre, die Webdienste selbst unverändert zu lassen
und statt dessen ein System zwischen zu schalten, das Anfragen entgegen nimmt, an
die entsprechenden Dienste weiter leitet, die Resultate empfängt und diese schließ-
lich in Abhängigkeit vom Client-Typ umgeformt an die jeweilige Anwendung zu-
rück liefert.
Genau solch ein System soll im Rahmen dieser Arbeit entwickelt und mit der Java 2
Micro Edition (J2ME) implementiert werden. Als Beispiel-Anwendung dient eine
Anfrage an das Online-Wörterbuch LEO, und das System soll in Form eines Serv-
lets realisiert zwischen Anfragen von stationären und mobilen Geräten unterschei-
den können.
Dabei sollen für den Entwurf die Unified Modeling Language (UML) und eine
TROLL-Erweiterung verwendet werden. Es ist hierbei zu untersuchen, welche Be-
standteile der UML geeignet sind, um sie auf die TROLL-Konstrukte abzubilden.
In Kapitel 2 werden zunächst einige zum Verständnis dieser Arbeit notwendige
Grundlagen der Mobilkommunikation dargestellt; auch der Begriff der Mobilität
wird hier eine entscheidende Rolle spielen. Am Ende dieses Kapitels wird das Onli-
ne-Wörterbuch LEO noch kurz beschrieben. Kapitel 3 beschäftigt sich mit der UML,
wobei deren Bestandteile sowohl allgemein vorgestellt als auch gleich konkret auf
das zu entwickelnde System übertragen werden. In Kapitel 4 wird die TROLL-
Modellierung angegangen, eingeleitet mit einer allgemeinen Darstellung von
TROLL. Kapitel 5 wendet sich langsam der Implementierung zu, denn hier wird die
Java 2 Micro Edition vorgestellt. Kapitel 6 beschäftigt sich mit der Implementierung
selbst, wobei natürlich nicht der komplette Quellcode abgedruckt ist, sondern nur auf
einige bedeutende oder interessante Stellen eingegangen wird. In Kapitel 7 werden
sowohl zum Online-Wörterbuch als auch zum Servlet und zu J2ME einige Alternati-
ven vorgestellt. Kapitel 8 schließlich enthält die Zusammenfassung und den Aus-
blick.
K
APITEL
2: G
RUNDLAGEN
3
K
K
A
A
P
P
I
I
T
T
E
E
L
L
2
2
:
:
G
G
R
R
U
U
N
N
D
D
L
L
A
A
G
G
E
E
N
N
2
In diesem Kapitel werden die Grundlagen dargestellt, die für das Verständnis dieser
Arbeit notwendig sind.
Dazu gehört eine Abgrenzung der Begriffe ,,mobil" und ,,drahtlos", eine nähere Er-
läuterung des Wortes ,,Mobilität" selbst sowie einige ausgewählte Anwendungen und
mögliche Endgeräte. Außerdem wird auf die Problematik eingeschränkter Ressour-
cen bei mobilen Geräten eingegangen, und schließlich werden ergänzt durch den
Anhang die vier Generationen drahtloser Telekommunikations-Systeme vorge-
stellt. Den Abschluss dieses Kapitels bilden einige Informationen über das LEO-
Online-Wörterbuch, das für die Beispiel-Implementierung des in dieser Arbeit mo-
dellierten Systems von Bedeutung ist.
2.1 Grundlagen der Mobilkommunikation
Die folgenden Ausführungen beleuchten den Themenbereich der Mobilkommunika-
tion weniger aus der Perspektive der Elektrotechnik als vielmehr aus der Informatik-
Sicht und stützen sich im Wesentlichen auf [Sch00] und [Wol02].
2.1.1 Mobile und drahtlose Kommunikation
Wie in der Einleitung (Kapitel 1) erwähnt, geht der Trend in Richtung portabler
Computer. Aus diesem Grund sollen an dieser Stelle zunächst die Begriffe ,,drahtlos"
und ,,mobil" voneinander abgegrenzt werden, die im täglichen Sprachgebrauch oft-
mals synonym verwendet werden, aber in Wirklichkeit unterschiedliche Bedeutun-
gen haben.
Es existieren zwei verschiedene Formen von Mobilität [Lüd01]:
Mobilität des Endgeräts (Terminal Mobility): Jeder Teilnehmer eines Mobil-
funk-Systems, also z.B. ein Handy-Besitzer, kann sich völlig frei mit seinem
Endgerät im Versorgungs-Gebiet des Funknetzes bewegen, ohne dass er über ein
Kabel mit einem festen Netzanschluss verbunden sein muss.
Persönliche Mobilität (Personal Mobility): Einige Mobilfunk-Systeme, wie
z.B. GSM und UMTS, die im Anhang noch näher erläutert werden, bieten jedem
ihrer Teilnehmer die Möglichkeit, von einem beliebigen, standardkonformen
Endgerät aus die von ihm abonnierten Telekommunikations-Dienste zu nutzen.
K
APITEL
2: G
RUNDLAGEN
4
Dazu muss er lediglich seine Teilnehmer-Karte auch SIM-Karte genannt (SIM
= Subscriber Identity Module) einlegen. Die Gebühren-Abrechnung erfolgt
dann unabhängig vom Besitzer des gerade benutzten Endgerätes zu Lasten des
Teilnehmers, dem diese Karte gehört.
Drahtlose Kommunikation dagegen beschreibt den Zugriff auf ein Kommunikati-
ons-Netz bzw. den Austausch von Daten mit einem Kommunikations-Partner ohne
die Zuhilfenahme eines Drahtes oder einer Glasfaser. Im Rahmen dieser Arbeit kann
drahtlose Kommunikation mit Funk-Kommunikation gleichgesetzt werden; allge-
meiner beschrieben werden elektromagnetische Wellen zum Transport der Daten
eingesetzt, so dass also kein Medium wie bei der leitungsgebundenen Kommunikati-
on vorhanden ist.
Jedes Kommunikations-Gerät lässt sich nach [Sch00] einer der folgenden Klassen
zuordnen, was zugleich nochmals den Unterschied zwischen mobiler und drahtloser
Kommunikation verdeutlicht:
Fest und leitungsgebunden: Typische Arbeitsplatzrechner fallen in diese Kate-
gorie. Weder vom Gewicht noch vom Energieverbrauch her können diese Geräte
mobile Nutzer unterstützen. Aus Kostengründen und auf Grund der hohen Leis-
tungsfähigkeit werden Festnetze zur Kommunikation eingesetzt.
Mobil und leitungsgebunden: Viele der heute tragbaren Rechner (Laptops,
Notebooks etc.) fallen in diese Kategorie. Benutzer tragen diese Rechner bei-
spielsweise von Hotel zu Hotel und verbinden sich mit dem Festnetz über das
Telefonnetz mit Hilfe eines Modems.
Fest und drahtlos: In diese dritte Klasse fallen beispielsweise Vernetzungen in
historischen Gebäuden, in denen man keine weiteren Löcher für ein Kommuni-
kationsnetz bohren möchte, aber dennoch normale Arbeitsplatzrechner mit Netz-
anbindung einsetzen will. Ein anderes Beispiel ist die Überbrückung der ,,letzten
Meile" zu einem Kunden mit Funk, damit nicht Festnetze eines anderen Netz-
betreibers genutzt werden müssen und eine teure Neuverkabelung eingespart
werden kann.
Mobil und drahtlos: Die wirklich interessanten Anwendungen fallen in diese
letzte Kategorie, bei der kein Kabel einen Anwender behindert und eventuell ei-
ne Auswahl an drahtlosen Netzen zur Verfügung steht, die nahtlos nacheinander
genutzt werden können. Das wohl bekannteste Beispiel ist das GSM-
K
APITEL
2: G
RUNDLAGEN
5
Mobilfunknetz, welches bereits von fast 700 Millionen Teilnehmern genutzt und
auf das im Anhang noch näher eingegangen wird.
2.1.2 Anwendungen
Es gibt eine Vielzahl von Anwendungen, die geradezu prädestiniert sind für einen
Einsatz von drahtloser und mobiler Kommunikation. Die folgenden Beispiele sollen
einige dieser Einsatzbereiche herausheben.
Die meisten Fahrzeuge werden zumindest in naher Zukunft mehrere drahtlose
Kommunikations-Systeme und mobile Anwendungen integrieren, wie beispielsweise
digitalen Rundfunk, Ad-hoc-Netze zum Austausch von Daten in Notfall-Situationen
oder zum Einhalten eines Sicherheits-Abstandes, vielfältige Sprach- und Datendiens-
te zur individuellen Kommunikation oder GPS (Global Positioning System) für Na-
vigations-Systeme, was bereits heute bei vielen Fahrzeugen zum Standard gehört.
Auch oder gerade bei Notfällen und Katastrophen zeigen sich die Möglichkeiten und
Vorteile der Funk-Kommunikation. Notärzte können mit Hilfe einer hochwertigen
Funk-Anbindung bereits auf der Fahrt ins Krankenhaus lebenswichtige Daten einer
verletzten Person übermitteln oder Rat von anderen Ärzten einholen. Mit diesen Da-
ten können im Krankenhaus schon vor dem Eintreffen des Patienten weitere Spezia-
listen hinzugeholt oder die adäquaten Vorbereitungen für eine Operation getroffen
werden. Darüber hinaus sind Funkkommunikations-Systeme auch die einzigen
Kommunikations-Systeme, die Naturkatastrophen wie Orkane, Flutwellen oder Erd-
beben überstehen (ausgenommen natürlich solche Mobilfunksysteme wie GSM, die
auf einem Infrastruktur-Netz von Basisstationen beruhen).
Außendienst-Mitarbeiter oder Vertreter benötigen ständigen Kontakt und soforti-
gen Zugriff auf die Datenbanken ihres Unternehmens. Mit einem drahtlosen Zugang
kann ein tragbarer Rechner zu einem vollständigen mobilen Büro werden.
Der Ersatz leitungsgebundener Netze durch Funk-Kommunikation kann sowohl
aus technischen als auch aus ökonomischen Gründen sinnvoll sein. Bei der Anbin-
dung einer abgelegenen Wetterstation ist es z.B. sinnvoller, Satelliten einzusetzen,
statt eine Verkabelung über mehrere tausend Kilometer aufzubauen. Ein weiteres
Beispiel sind Messen, die eine hochflexible Kommunikations-Infrastruktur benöti-
gen, die für jede Veranstaltung unterschiedlich konfiguriert werden muss. Hier ist
K
APITEL
2: G
RUNDLAGEN
6
eine Verkabelung oft viel zu umständlich und zeitintensiv, so dass es effizienter ist,
einzelne Messestände über Funk anzubinden.
Ohne drahtlose Kommunikation kann schlicht und einfach die Idee oder die Vision
vom allgegenwärtigen Internet nicht verwirklicht werden. Hierbei sind verschiedene
Dimensionen und Einsatzbereiche denkbar. Möglich wäre z.B. ein Reiseführer, der
über GPS die Position des Touristen lokalisiert und in Abhängigkeit davon unter-
schiedliche Informationen anzeigt, beispielsweise über das Gebäude, vor dem der
Tourist gerade steht.
Ein gerade für die Zukunft entscheidender Einsatzbereich ist die mobile Unterhal-
tung (dazu zählen auch Spiele). Denn wie eine Statistik über die Anwendungen von
i-Mode in Japan aussagt, stammen die populärsten von ihnen aus eben diesem Be-
reich, wie Abbildung 1 zu entnehmen ist.
Mobile Unterhaltung
44%
Telefonbuch
29%
Veranstaltungs-Tickets
9%
Telebanking
7%
Öffentliche Verkehrsmittel
7%
City Guide
4%
Abbildung 1: Populäre Anwendungen von i-Mode [Sel02]
K
APITEL
2: G
RUNDLAGEN
7
2.1.3 Mobile und drahtlose Endgeräte
Bereits heute sind viele unterschiedliche mobile Geräte auf dem Markt, die über
Funk kommunizieren, und es ist zu erwarten, dass es in Zukunft noch sehr viel mehr
geben wird. Es existiert keine präzise Klassifikation dieser Geräte, weder hinsichtlich
der Größe, des Gewichts, des Aussehens noch der Rechenleistung, denn die Über-
gänge sind fließend. Die folgende Abbildung zeigt einige Beispiele solcher Geräte
mit unterschiedlicher Leistungsfähigkeit.
steigende Leistung
Palmtops:
- kleine Tastatur
- einfache Version der
Standard-Programme
Mobiltelefone:
- Sprache, Daten
- einfache Textanzeigen
Pager:
- nur Empfang
- sehr kleine
Anzeigen
- einfache
Textnachrichten
Sensoren,
embedded
systems
PDAs:
- einfache Grafik-Anzeigen
- Handschrift-Erkennung
- vereinfachtes WWW
Laptops:
- voll funktionsfähig
- Standard-
Anwendungen
Abbildung 2: Mobile und drahtlose Endgeräte [Wol02]
2.1.4 Drahtlose Telekommunikations-Systeme
Im Laufe der Zeit wurden verschiedene drahtlose Telekommunikations-Systeme /
Mobilfunk-Netze entwickelt und eingesetzt. Diese unterscheiden sich sowohl tech-
nisch (analoge und digitale Systeme) als auch hinsichtlich der für Übertragungen zur
Verfügung stehenden Bandbreite. Obwohl die angebotene Bandbreite stets zunahm,
lag sie doch immer deutlich unter der von leitungsgebundenen Systemen.
K
APITEL
2: G
RUNDLAGEN
8
Drahtlose Telekommunikations-Systeme lassen sich in vier Generationen unterteilen
[Ali02]:
1. Generation: analoge Systeme
2. Generation: digitale Systeme
3. Generation: UMTS
4. Generation
Eine ausführlichere Erläuterung dieser einzelnen Generationen ist im Anhang dieser
Arbeit zu finden.
2.2 Mobilität in verteilten Berechnungen
Die Kommunikation zwischen verschiedenen Endgeräten ob drahtlos oder nicht
ist im Allgemeinen aus technischer Sicht kein Problem. Schwieriger wird es, wenn
mindestens ein Kommunikations-Partner mobil ist, nicht unbedingt aufgrund der
notwendigen Funk-Übertragung, sondern wegen vieler Besonderheiten, die im Grun-
de mit der Mobilität an sich nichts zu tun haben, sondern vielmehr Folgen davon
sind.
Denn unabhängig vom technischen Fortschritt muss z.B. ein Mobiltelefon (genauso
wie viele andere portable Geräte) immer
tragbar, also so klein und leicht wie möglich sein (hierbei sind allerdings allein
dadurch Grenzen gesetzt, dass ein Mensch das Telefon bedienen und die Anzei-
ge erkennen können muss)
drahtlos sein, d.h. es bezieht seine Energie aus einem Akku
Die entscheidenden Unterschiede von Mobiltelefonen im Vergleich zu stationären
Rechnern sind somit folgende [KT01]:
Tragbare Endgeräte besitzen eine eingeschränkte Benutzer-Schnittstelle. Die
Geräte sind durch kleine, niedrig auflösende und meist monochrome Displays
nur für die Darstellung geringer Informations-Mengen geeignet. Auch die Be-
nutzer-Eingaben durch mehrfach belegte Telefon-Tastaturen oder Stift-
Eingaben sind nicht mit den Möglichkeiten zu vergleichen, die eine vollständige
Tastatur und eine Maus bieten.
Die kompakten Geräte verfügen nur über geringe Rechen-Leistung und Spei-
cher-Kapazität. Leistungsfähigere Hardware findet keinen Platz in den immer
kleiner werdenden Begleitern.
K
APITEL
2: G
RUNDLAGEN
9
Eine begrenzte Stromversorgung über Akkus und Batterien erfordert einen
eminent sparsamen Umgang mit der verfügbaren Energie und schränkt so die
Benutzung dieser Geräte erheblich ein.
Auf zwei Begriffe möchte ich an dieser Stelle noch kurz eingehen:
Die beiden in 2.1.1 beschriebenen Formen der Mobilität (Mobilität des Endgeräts
und persönliche Mobilität) basieren auf Bewegungen von Hardware, also z.B. Mobil-
telefonen oder Laptops, d.h. physikalische Mobilität oder Mobile Computing.
Daneben existiert auch die Möglichkeit, dass nicht die Geräte selbst, sondern nur
Teile ihrer Software mobil sind. In diesem Falle spricht man von Mobile Computa-
tion oder (virtueller) Software-Mobilität [Car99].
Ein typisches Beispiel für Software-Mobilität sind mobile Agenten. Darunter ver-
steht man Software-Programme, die zur Erledigung der ihnen zugewiesenen Aufga-
ben in andere Umgebungen, d.h. z.B. auf andere Server, migrieren können. Nach
Beendigung ihrer Arbeit senden sie entweder ihre Ergebnisse zu ihrer ursprünglichen
Umgebung, oder sie kehren selbst dorthin zurück. Der entscheidende Vorteil dabei
ist, dass durch die Migration eine eigentlich entfernte Aktion zu einer lokalen ge-
macht werden kann [GM01] und am Ende nur diejenigen Daten zu einem entfernten
Gerät transferiert werden müssen, die zur Weiterverarbeitung des Ergebnisses unbe-
dingt notwendig sind, was sowohl eine Entlastung des Netzwerkes als auch das Um-
gehen von Netzwerk-bedingten Verzögerungen zur Folge hat.
Ein mögliche Anwendung wäre beispielsweise die Suche nach Informationen in Do-
kumenten, die auf entfernten Servern liegen. Statt jede Datei zu übertragen, zu
durchsuchen und vielleicht bei einem Großteil festzustellen, dass sie ungeeignet sind,
erledigt ein mobiler Agent diese Arbeit direkt auf dem jeweiligen Server und schickt
nur die Ergebnisse an seinen ,,Auftraggeber" zurück.
Die Grenzen zwischen Hardware- und Software-Mobilität sind allerdings fließend.
So kann ein mobiler Agent (letztendlich nichts anderes als ein ganz ,,normales" Pro-
gramm), der sich beispielsweise auf einem Laptop befindet, auf zwei Wegen an sein
Ziel gelangen: Entweder wird er über ein Netzwerk übermittelt (virtuell, Software-
Mobilität), oder er wird mitsamt dem Laptop ans Ziel gebracht (physisch, Hardware-
Mobilität) [Car99].
Im Rahmen dieser Arbeit hat man es aber ausschließlich mit Hardware-Mobilität zu
tun. Denn der entscheidende Unterschied zum gerade erwähnten Laptop-Beispiel ist,
K
APITEL
2: G
RUNDLAGEN
10
dass man einem Mobiltelefon-Besitzer nicht vorschreiben kann, sich an einen be-
stimmten Ort zu bewegen. Und selbst wenn dies gelingen würde, d.h. wenn sich das
Mobiltelefon direkt neben dem Server, auf dem das Servlet ausgeführt wird, befinden
würde, so bedeutete das für die Kommunikation keinen Unterschied. Natürlich ist es
ein Unterschied, ob sich der Mobiltelefon-Besitzer neben dem Server oder am ande-
ren Ende der Welt befindet, aber nur in der Hinsicht, dass eine längere Strecke über-
brückt oder verschiedene Basis-Stationen einbezogen werden müssten, nicht aber,
dass man die Wahl z.B. zwischen einer Übertragung per HTTP und einem Kopier-
vorgang innerhalb der Verzeichnisse eines Servers hat. Und nur diese Ebene ist für
einen J2ME-Entwickler von Interesse; wie genau die HTTP-Verbindung aufgebaut
und aufrecht erhalten wird, definieren andere.
2.3 Link Everything Online (LEO)
LEO ist ein Service der TU München. Er enthält das für die Beispiel-
Implementierung dieser Arbeit entscheidende Online-Wörterbuch, darüber hinaus
aber noch einige andere Komponenten. Hier soll zunächst ein grober Überblick über
seine Geschichte gegeben und danach speziell auf das Online-Wörterbuch eingegan-
gen werden.
2.3.1 Geschichtlicher Überblick
Die Geschichte von LEO [LEO03a] begann im Jahre 1992. Zu dieser Zeit gab es im
Bereich der Münchner Hochschulen eine Reihe von FTP-Servern, die unabhängig
voneinander verwaltet wurden. Die Konsequenz war, dass viele Softwarepakete
mehrfach vorhanden waren, Verwaltungsarbeit mehrfach anfiel und sich die Suche
nach einem bestimmten Paket für den Anwender als sehr aufwendig herausstellte.
Diese Missstände wollte man beseitigen durch ein Archiv,
dessen Angebot über mehrere Server verteilt werden konnte,
das dem Anwender einen transparenten Zugriff unabhängig von der physikali-
schen Ablage eines Pakets zur Verfügung stellte und
das durch eine übersichtliche Verzeichnisstruktur einen effizienten Zugriff er-
laubte.
Aus diesen Überlegungen heraus entstand der Münchner Informations-Verbund
(MIV).
K
APITEL
2: G
RUNDLAGEN
11
1993 versuchte man, das World Wide Web (WWW) zu integrieren; insbesondere
wurde eine Fülle von Einstiegs-Punkten geschaffen. Da sich der Umfang des Ange-
bots erweitert und sich auch die Teilnehmerstruktur geändert hatte, wurde ein neuer
Name gefunden - Informationssysteme und Archiv München (ISAR).
Im Laufe der Zeit entwickelte sich ISAR zu einem umfangreichen und beliebten In-
formationssystem. Aufgrund der mittlerweile kommerziellen Belegung des Namens
ISAR war es 1994 an der Zeit für eine eigenständige Identität. Ein neuer Name wur-
de gesucht er sollte wiederum einen Bezug zu München haben und im Mai 1994
mit Link Everything Online (LEO) gefunden. Am 5. Juni 1994 wurde die dazu
reservierte Domain leo.org aktiviert und das LEO-Angebot ins WWW integriert.
In LEO wurden mehrere neue Angebote übernommen, wie z.B.:
Stadt-Informationen zu München
ein WWW-basierter Zugang zum Software-Archiv, das immer noch das Herz
von LEO darstellte, und
das deutsch-englische Online-Wörterbuch, auf das im Rahmen dieser Arbeit zu-
gegriffen werden soll
Im Laufe der Jahre wurden einige technische wie organisatorische Veränderungen
am System vorgenommen. So wurde z.B. 1998 der Versuch gewagt, angesichts der
knappen öffentlichen Kassen LEO zumindest teilweise durch Werbung zu finanzie-
ren zu der Zeit eine noch nicht annähernd so weit verbreitete Methode wie heute.
Die Zugriffszahlen für LEO stiegen stetig an; im Januar 2003 wurde mit 54.899.930
Zugriffen eine neue Höchstmarke erreicht (diese Zahl entspricht rund 20 Zugriffen
pro Sekunde!).
2.3.2 Das Online-Wörterbuch
Das Online-Wörterbuch von LEO wurde am 05.08.1995 in Betrieb genommen
[LEO03c]. Es enthält mittlerweile einen Bestand von rund 170.000 Wörtern, wobei
viele Einträge von außen, d.h. von freiwilligen Helfern, angeregt wurden. Die Nut-
zung wurde über die Jahre immer intensiver, und so hatte man am 15.01.2003 den
bisherigen Rekord von mehr als 2.300.000 Wort-Anfragen (also fast 27 pro Sekunde)
zu verzeichnen. Die neueste Version dieses Online-Wörterbuchs, die im folgenden
anhand einiger Screenshots vorgestellt werden soll, datiert vom 17.07.2002.
K
APITEL
2: G
RUNDLAGEN
12
Wenn man das Online-Wörterbuch über die LEO-Hauptseite http://www.leo.
org oder direkt unter http://dict.leo.org/?lang=de aufruft (lässt man
das ,,?lang=de" weg, gelangt man zur englischsprachigen Umgebung), so erhält man
die Ansicht, die in Abbildung 3 dargestellt ist.
Abbildung 3: LEO-Online-Wörterbuch (Start-Ansicht), 25.02.2003
Im hier rot markierten Bereich hat man dann die Möglichkeit, ein deutsches oder
englisches Wort einzugeben, an dessen Übersetzung man interessiert ist. Als Beispiel
habe ich hier das Wort ,,Diplomarbeit" gewählt.
Ferner hat man die Wahl zwischen einigen Optionen, die zum Teil schon am linken
unteren Rand von Abbildung 3 sowie vollständig in Abbildung 4 ersichtlich sind.
K
APITEL
2: G
RUNDLAGEN
13
Abbildung 4: Optionen für die Übersetzung beim LEO-Online-Wörterbuch,
25.02.2003
Wenn die Optionen so wie in Abbildung 4 gewählt wurden, erhält man als Resultat
die Tabelle, die in Abbildung 5 zu sehen ist.
Die URL dieser Seite lautet:
http://dict.leo.org/
?search=Diplomarbeit
&searchLoc=1
&relink=off
&spellToler=std
§Hdr=off
&tableBorder=1
&cmpType=relaxed
&lang=en.
K
APITEL
2: G
RUNDLAGEN
14
Wie man sieht, werden sowohl das zu übersetzende Wort als auch die gewählten
Optionen in der URL codiert. Das bedeutet, dass, wenn dieses Schema bekannt ist,
man direkt die Resultats-Seite erzeugen kann, ohne eine Eingabe innerhalb eines
HTML-Dokuments vornehmen zu müssen. Dies ist ein entscheidender Vorteil für
den Zugriff von einem mobilen Gerät aus, wie die Implementierung (siehe Kapitel 6)
zeigen wird.
Abbildung 5: Die Resultate der Übersetzung
K
APITEL
3: D
IE
U
NIFIED
M
ODELING
L
ANGUAGE
15
K
K
A
A
P
P
I
I
T
T
E
E
L
L
3
3
:
:
D
D
I
I
E
E
U
U
N
N
I
I
F
F
I
I
E
E
D
D
M
M
O
O
D
D
E
E
L
L
I
I
N
N
G
G
L
L
A
A
N
N
G
G
U
U
A
A
G
G
E
E
3
Dieses Kapitel befasst sich mit der Modellierung des Systems unter Verwendung der
Unified Modeling Language (UML). Nach einer kurzen Vorstellung der Geschichte
der UML und ihrer Grundlagen soll zunächst die Struktur oder Klassifizierung der
Modellelemente, die sogenannte Meta-Modellierung, erläutert werden, gefolgt von
einer Darstellung der Möglichkeiten zur Erweiterung der UML. Anschließend wer-
den die wichtigsten Komponenten der UML jeweils zunächst erklärt und schließlich
sofern sinnvoll auf das im Rahmen dieser Arbeit zu entwickelnde System über-
tragen.
Die Gliederung orientiert sich an den verschiedenen Diagramm-Arten, die von der
UML vorgegeben werden, bleibt aber auf diejenigen beschränkt, die für den Entwurf
der Beispiel-Anwendung benötigt werden.
Dabei soll sich dieses Kapitel wie auch das nächste auf einer allgemeineren Ebe-
ne bewegen als die Implementierung in Kapitel 6 und primär die Funktionen des Sys-
tems veranschaulichen, ohne bereits auf die Beispiel-Anwendung ,,LEO-Online-
Wörterbuch" beschränkt zu sein. Die Begriffe ,,Servlet" und ,,Midlet" (vgl. 5.4.1)
sollen aber auch, wenn dies nicht die einzige Möglichkeit der Realisierung ist (vgl.
Kapitel 7) mangels geeigneter allgemeinerer Begriffe auf dieser Ebene bereits ver-
wendet werden.
3.1 Grundlagen und historische Entwicklung
Die Eigenschaften und das Verhalten eines Software-Systems sind nicht direkt, d.h.
ohne Hilfsmittel, erfassbar. Ein zentrales Hilfsmittel sind hierbei geeignete Modelle,
die sowohl die statische Struktur als auch das dynamische Verhalten des Systems
sichtbar machen. Modelle helfen nicht nur dem Entwickler beim Design bzw. bei der
Vorbereitung der Implementierung, sie sind auch das wesentliche Mittel zur Kom-
munikation zwischen allen Personen, die an der Entwicklung des Systems beteiligt
sind oder die später damit arbeiten wollen.
Durch die UML wird ein Satz von Modellelementen mit zugeordneten grafischen
Symbolen definiert, aus denen Modelle konstruiert werden können. Diese Modell-
elemente zeichnen sich dadurch aus, dass ihre Syntax und Semantik weitgehend for-
mal und damit unmissverständlich definiert sind.
K
APITEL
3: D
IE
U
NIFIED
M
ODELING
L
ANGUAGE
16
Die UML wurde von Grady Brooch, Dr. James Rumbaugh und Dr. Ivar Jacobson
entwickelt. Die Arbeiten begannen 1996; ein Jahr später wurde die Version 1.0 bei
der Object Management Group (OMG) als Standardisierungs-Vorschlag eingereicht
und eine Beschreibung veröffentlicht. Zurzeit (Anfang 2003) aktuell ist die Version
1.4. Die Version 2.0 wurde zwar bereits im Dezember 1999 vorgestellt [Sch02], mit
einer Verabschiedung ist aber in nächster Zeit nicht zu rechnen [HK03].
Sofern sie nicht konkret auf dieses System bezogen sind, lehnen sich die folgenden
Ausführungen an [FS98], [HK99], [HK03] und [Neu02] an.
3.2 Meta-Modellierung und Erweiterungs-Mechanismen
Eine Modellierungs-Sprache sollte zumindest in einigen Punkten erweiterbar sein,
damit auf benutzerspezifische Anforderungen reagiert werden kann (,,Erweiterungs-
Prinzip"). Zu diesem Zweck wurden alle Konzepte der UML selbst in Form eines
UML-Klassen-Diagramms
2
beschrieben, was auch als Meta-Modellierung bezeichnet
wird. Das Metamodell ist ein vordefiniertes Klassen-Modell, das alle Modellkonzep-
te als sogenannte Meta-Modellklassen reifiziert
3
. Die Semantik der Konzepte und ihr
erlaubtes Zusammenspiel werden durch die Attribute und Beziehungen der Metamo-
dell-Klassen spezifiziert.
Im Rahmen der UML werden drei Arten von Erweiterungs-Mechanismen unter-
schieden:
markierte Werte (tagged values) zur Definition einer speziellen Markierung
bzw. Kennzeichnung eines Modellelement-Typs
Beschränkungen (constraints) zum Definieren einer zusätzlichen Bedingung
für eine Beschränkung, die sich auf einen Modellelement-Typ bezieht
Stereotypen
Letztgenannte werden im Folgenden näher erläutert.
2
Eine vollständige Beschreibung aller Komponenten eines Klassen-Diagramms würde in dieser Ar-
beit zu weit führen, zumal dies zu den Grundlagen der Informatik zählt. Im Zweifel kann z.T. Unter-
punkt 3.6, ansonsten die o.a. Literatur zu Rate gezogen werden.
3
Reifikation (von res (lat.) = Ding, Sache) bedeutet, dass ein Konzept ,,verdinglicht", d.h. selbst als
Klasse bzw. als Objekt modelliert wird.
K
APITEL
3: D
IE
U
NIFIED
M
ODELING
L
ANGUAGE
17
Stereotypen ermöglichen eine Erweiterung des Metamodells, indem jedes Modell-
element mit beliebig vielen Stereotypen weiter kategorisiert, d.h. klassifiziert werden
kann. Beispielsweise können Klassen, also Instanzen der Metaklasse Class, derge-
stalt klassifiziert werden, dass sie Objekte des Problembereichs beschreiben («enti-
ty»), Schnittstellen-Objekte repräsentieren («boundary») oder eine Steuerungsfunkti-
on darstellen («control»). Dementsprechend ist der ,,Sichtbarkeits-Bereich" eines
Stereotyps z.B. ein bestimmtes Software-System.
Es gibt zwei grundsätzliche Möglichkeiten der Darstellung von Stereotypen: Zum
einen können sie textuell angegeben werden (in doppelten Spitzklammern («...») in
der Nähe des zugehörigen Modellelement-Namens), zum anderen ist eine grafische
Veranschaulichung möglich. Bei dieser hat man die Wahl zwischen den drei Mög-
lichkeiten, die aus Abbildung 6 zu entnehmen sind: Das Stereotyp-Symbol wird zu-
sätzlich zur textuellen Beschreibung oder statt dessen verwendet, oder das Symbol
des Stereotyps ersetzt das Modellelement-Symbol (ganz links ist die Variante der
reinen textuellen Repräsentation zu sehen).
«Stereotyp»
Klasse
«Stereotyp»
Klasse
Klasse
Klasse
Abbildung 6: Alternative Darstellungen für Stereotypen am Beispiel des Modellele-
ments ,,Klasse" [HK03]
3.3 Anwendungsfall-Diagramme
Ein Anwendungsfall (Englisch: use case) ist eine typische Interaktion zwischen ei-
nem Computersystem und einem Benutzer (Akteur). Letztere benutzen entweder das
System durch die Initiierung der Ausführung von Anwendungsfällen, oder sie wer-
den vom System benutzt, indem sie zur Realisierung einzelner Anwendungsfälle
selbst Funktionalitäten zur Verfügung stellen. Anwendungsfälle beschreiben folglich
das Verhalten, das von einem zu entwickelnden System erwartet wird.
Obwohl es zum Auffinden von Anwendungsfällen (zunächst) hilfreich ist, bei den
Akteuren von konkreten Individuen auszugehen, die in Zukunft einmal mit dem Sys-
tem arbeiten sollen, repräsentieren die Akteure keine Objekte, sondern Rollen, die
von Objekten eingenommen werden können. Ein Individuum kann dabei mehrere
Rollen ausfüllen.
K
APITEL
3: D
IE
U
NIFIED
M
ODELING
L
ANGUAGE
18
[FS98] formulieren die wesentlichen Eigenschaften von Anwendungsfällen wie
folgt:
Ein Anwendungsfall erfasst eine dem Benutzer sichtbare Funktion
Ein Anwendungsfall kann klein oder groß sein
In einem Anwendungsfall erreicht der Benutzer ein abgrenzbares Ziel
Zur Visualisierung dieser Anwendungsfälle wurde 1994 von Jacobson eine Notation
eingeführt, die inzwischen auch Bestandteil der UML ist: das Anwendungsfall-
Diagramm.
Hierbei können die Akteure
4
auf zwei verschiedene Arten repräsentiert werden. Zum
einen findet man die Darstellung als Strichmännchen, unter dem in Textform der
Name des Akteurs geschrieben wird, zum anderen können Akteure durch ein Recht-
eck, welches das Schlüsselwort «actor» und den Namen enthält, veranschaulicht
werden. Diese Variante bietet sich insbesondere an, wenn ein Akteur keine konkrete
Person darstellt, sondern ein externes System, das Informationen vom betrachteten
System benötigt (z.B. ein E-Mail-System).
Die Anwendungsfälle werden durch Ellipsen beschrieben, die den Namen des An-
wendungsfalls enthalten. Die Grenze des Systems wird durch ein die Anwendungs-
fälle umfassendes Rechteck veranschaulicht.
Es sind aber nicht nur Beziehungen zwischen den Akteuren und den Anwendungsfäl-
len möglich, sondern auch (gerichtete) Beziehungen zwischen je zwei Anwendungs-
fällen. Hierbei existieren zwei Arten: Die Include-Beziehung besagt, dass das Ver-
halten des untergeordneten in den übergeordneten Anwendungsfall eingefügt wird.
Eine Extend-Beziehung dagegen bedeutet, dass das Verhalten des untergeordneten in
den übergeordneten Anwendungsfall eingefügt werden kann. Da hierdurch eine opti-
onale Beziehung ausgedrückt wird, besitzt jede Extend-Beziehung eine Bedingung,
bei deren Erfüllung der jeweilige Anwendungsfall eingefügt werden kann.
Grafisch werden diese Beziehungen durch Abhängigkeitspfeil (meist gestrichelt) mit
der Bezeichnung «include» bzw. «extend» dargestellt. Die Bedingung der Ex-
tend-Beziehungen wird im Allgemeinen unter diesem Pfeil in eckigen Klammern
angegeben.
4
Akteure werden durch die Metaklasse Actor, einer Subklasse von Classifier, im Metamodell
repräsentiert.
K
APITEL
3: D
IE
U
NIFIED
M
ODELING
L
ANGUAGE
19
«i
nc
lu
de
»
«inc
lude
»
«i
nc
lu
de
»
«include»
«include»
Informationen
herausfiltern
Anfrage
stationär
Anfrage
mobil
Ergebnisse zu-
rücksenden
HTML-Seite
laden
Benutzer
mobil
Benutzer
stationär
Abbildung 7: Anwendungsfall-Diagramm
Für das im Rahmen dieser Arbeit zu entwickelnde System gibt es zwei Anwendungs-
fälle. Beide beinhalten eine Anfrage eines Benutzers an einen Webdienst (in der Bei-
spiel-Implementierung das Wörterbuch), jedoch ist zu unterscheiden, ob die Anfrage
von einem mobilen oder einem stationären Gerät kommt.
In beiden Fällen müssen zunächst die relevanten Informationen aus dem HTML-
Code herausgefiltert werden. Für ein stationäres Gerät müssen diese in eine HTML-
Tabelle eingebunden und in Form von HTML-Tags zurück gesendet werden, so dass
die Ergebnisse als Reaktion auf das Ausfüllen und Abschicken des Online-
Formulars direkt im Browser angezeigt werden können.
Stammt die Anfrage von einem mobilen Gerät, werden nur die Informationen selbst
(im Beispiel also Wortpaare aus Original und Übersetzung) verschickt und vom Mid-
let mit einem eigens dazu zur Verfügung gestellten User-Interface angezeigt.
Diese Zusammenhänge zeigt Abbildung 7.
K
APITEL
3: D
IE
U
NIFIED
M
ODELING
L
ANGUAGE
20
3.4 Sequenz-Diagramme
Sequenz-Diagramme sowie die im folgenden Unterpunkt behandelten Kollaborati-
ons-Diagramme können unter dem Oberbegriff der Interaktions-Diagramme zusam-
mengefasst werden. Mit Interaktions-Diagrammen beschreibt man, wie / mit wel-
chem Verhalten Gruppen von Objekten zusammenarbeiten. Hierbei wird üblicher-
weise das Verhalten eines bestimmten Anwendungsfalls erfasst. Im Gegensatz zu
Anwendungsfall- und Klassen-Diagrammen stehen hier nicht die strukturalen Zu-
sammenhänge, sondern das (dynamische) Verhalten des Systems im Vordergrund.
In den entsprechenden Schaubildern werden Objekte und Nachrichten, die zwischen
diesen Objekten ausgetauscht werden, dargestellt.
In einem Sequenz-Diagramm wird ein Objekt als ein Kasten über einer vertikalen
Linie, der sogenannten Lebenslinie (Lifeline), gezeichnet. Ein Pfeil zwischen den
Lebenslinien bedeutet eine Nachricht zwischen zwei Objekten. In vertikaler Rich-
tung wird dabei die Zeit verdeutlicht: eine Nachricht, die im Diagramm weiter unten
eingezeichnet ist, tritt nach einer weiter oben dargestellten Nachricht auf.
Normalerweise ist diese Zeitachse ordinal
5
skaliert, d.h. die Größe der vertikalen
Abstände bzw. Zwischenräume zwischen den Nachrichten hat keine Bedeutung. In
Spezialfällen z.B. bei der Modellierung von Echtzeitverarbeitung kann die Zeit-
achse auch metrisch skaliert werden. Da dies im Rahmen dieser Arbeit aber nicht
notwendig und auch gar nicht exakt möglich ist (die einzelnen Zeitabstände hängen
von der exogen gegebenen Netzauslastung ab), wird die übliche ordinale Skalierung
verwendet.
Durch die Form der Pfeilspitze einer Nachricht wird die Art des Kontrollflusses an-
gegeben:
synchroner Kontrollfluss (wie ein Prozedur-Aufruf)
asynchroner Kontrollfluss (Nachricht wird wie ein Signal losgeschickt,
ohne dass der Sender auf eine Antwort wartet)
unspezifizierter Kontrollfluss
5
Ordinale Skalen erlauben über die Klassifikation quantitativer Eigenschafts-Ausprägungen hinaus
die Zuordnung von Rangwerten, können also Größer/Kleiner- bzw. Besser/Schlechter-Urteile treffen;
Schulnoten oder Präferenz-Urteile sind hierfür typische Beispiele. Genaue Abstände zwischen den
einzelnen Rangwerten lassen sich bei ordinal skalierten Daten allerdings nicht abgeben (hierzu dienen
Intervall- und Verhältnis-Skalen) [FO98].
Ende der Leseprobe aus 137 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2003, Informationstransfer von Webdiensten zu mobilen Geräten mit J2ME, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/221924
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare