Informationstransfer von Webdiensten zu mobilen Geräten mit J2ME

Tiedemann, Marcus

Leseprobe

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.

NHALTS

-V

ERZEICHNIS

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

NHALTS

-V

ERZEICHNIS

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

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

BKÜRZUNGS

-V

ERZEICHNIS

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

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

BKÜRZUNGS

-V

ERZEICHNIS

JAR

Java

Archive

JDBC

Java Database Connectivity

JNI

Java Native Interface

JSP

Java Server Page

JVM

Java Virtual Machine

Kilobyte

KVM

Kilobyte Virtual Machine

LEO

Link Everything Online

Megabyte

MHz

Megahertz

MIDP

Mobile Information Device Profile

MIV

Münchner

Informations-Verbund

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

Betriebssystem (Operating System)

OSS

Betriebs- und Wartungs-System (Operation Subsystem)

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

Fernsehen

(Television)

UDP

User Datagram Protocol

UML

Unified Modeling Language

BKÜRZUNGS

-V

ERZEICHNIS

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

APITEL

1: E

INLEITUNG UND

UFGABENSTELLUNG

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

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.

Die Unterschiede zwischen mobilen und stationären Geräten werden ausführlich in Kapitel 2 be-

schrieben.

APITEL

1: E

INLEITUNG UND

UFGABENSTELLUNG

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.

APITEL

2: G

RUNDLAGEN

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.

APITEL

2: G

RUNDLAGEN

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-

APITEL

2: G

RUNDLAGEN

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

APITEL

2: G

RUNDLAGEN

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

Telebanking

Öffentliche Verkehrsmittel

City Guide

Abbildung 1: Populäre Anwendungen von i-Mode [Sel02]

APITEL

2: G

RUNDLAGEN

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.

APITEL

2: G

RUNDLAGEN

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.

APITEL

2: G

RUNDLAGEN

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,

APITEL

2: G

RUNDLAGEN

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).

APITEL

2: G

RUNDLAGEN

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.

APITEL

2: G

RUNDLAGEN

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.

APITEL

2: G

RUNDLAGEN

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

&sectHdr=off

&tableBorder=1

&cmpType=relaxed

&lang=en.

APITEL

2: G

RUNDLAGEN

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

APITEL

3: D

NIFIED

ODELING

ANGUAGE

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.

APITEL

3: D

NIFIED

ODELING

ANGUAGE

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

beschrieben, was auch als Meta-Modellierung bezeichnet

wird. Das Metamodell ist ein vordefiniertes Klassen-Modell, das alle Modellkonzep-

te als sogenannte Meta-Modellklassen reifiziert

. 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.

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.

Reifikation (von res (lat.) = Ding, Sache) bedeutet, dass ein Konzept ,,verdinglicht", d.h. selbst als

Klasse bzw. als Objekt modelliert wird.

APITEL

3: D

NIFIED

ODELING

ANGUAGE

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

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.

APITEL

3: D

NIFIED

ODELING

ANGUAGE

[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

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.

Akteure werden durch die Metaklasse Actor, einer Subklasse von Classifier, im Metamodell

repräsentiert.

APITEL

3: D

NIFIED

ODELING

ANGUAGE

«i

«inc

lude

«i

«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.

APITEL

3: D

NIFIED

ODELING

ANGUAGE

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

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

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

Titel

Informationstransfer von Webdiensten zu mobilen Geräten mit J2ME

Autor

Marcus Tiedemann (Autor:in)

Erscheinungsjahr

2003

Seiten

137

Katalognummer

V221924

ISBN (eBook)

9783832465070

ISBN (Buch)

9783838665078

Dateigröße

2730 KB

Sprache

Deutsch

Schlagworte

computing j2me geräte internet troll

Produktsicherheit

Diplom.de

Arbeit zitieren

Marcus Tiedemann (Autor:in)

, 2003, Informationstransfer von Webdiensten zu mobilen Geräten mit J2ME, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/221924

Kommentare

Noch keine Kommentare.

Melden Sie sich an, um einen Kommentar zu schreiben

Informationstransfer von Webdiensten zu mobilen Geräten mit J2ME

Autor

Kategorie

Institution / Hochschule

Note

Leseprobe

Details

Kommentare

Ihre Vorteile als Autor