PDA to IT-Workflow

Transcrição

PDA to IT-Workflow

Informatik-Masterarbeit an der Universität
Freiburg (Schweiz)
PDA to IT-Workflow
September 2003
Sascha Iseli
Wagnerstrasse 8
3007 Bern
1. Referent:
2. Referent:
Prof. Dr. Andreas Meier
PD. Dr. Tony Hürlimann
Betreuerin:
Dona Mommsen
Weiterer Verteiler:
-
Marc Grimmer (Ascom)
Thomas Wettstein (ehem. Ascom)
Markus Braunschweiler (ehem. Ascom)
Patrick Enggist (ehem. Ascom)
Die vorliegende Diplomarbeit konnte ich in Zusammenarbeit mit meinem Teilzeitarbeitgeber Ascom
durchführen. Meine Diplomarbeit sollte der Ascom neue Erkenntnisse im Bereich der mobilen
Kommunikation liefern und als Wissensbasis sowie Entscheidungsgrundlage für die Zukunft dienen.
Die Zusammenarbeit mit der Ascom war lehrreich und intensiv. Für die geleistete Unterstützung
möchte ich an dieser Stelle herzlich danken. Namentlich möchte ich Patrick Enggist danken, welcher
die Idee zu der vorliegenden Arbeit hatte und welcher mich in der Anfangsphase unterstützte und
begleitete. Danken möchte ich auch meinen Mitarbeitern Markus Braunschweiler und Thomas
Wettstein, welche in den zahlreichen Kaffeepausen aufmunternde Worte und gute Tipps spendeten.
Douglas Miles sowie Gerald Mengeisen möchte ich danken für die fachliche Unterstützung und zu
guter Letzt geht natürlich ein ganz grosses «Merci» für die dauerhafte Unterstützung und Begleitung
dieser Arbeit an Marc Grimmer.
Sascha Iseli, September 2003
Einleitung
PDA to IT-Workflow (P2W)
Inhaltsverzeichnis:
Bildverzeichnis: ..................................................................................................................... 5
Tabellenverzeichnis:............................................................................................................. 7
Abstract: .............................................................................................................................. 8
1.
Einleitung...................................................................................................................... 9
1.1.
Problemstellung.................................................................................................................. 9
1.2.
Zielsetzung ......................................................................................................................... 10
1.3.
Vorgehensweise ............................................................................................................... 10
2.
Grundlagen ................................................................................................................ 11
2.1.
Workflows........................................................................................................................... 11
2.1.1.
2.1.2.
2.1.3.
2.2.
Workflow-Management-Systeme (WfMS)................................................................... 15
2.2.1.
2.2.2.
2.2.3.
2.2.4.
2.3.
Hyper Text Transfer Protocoll (HTTP) .................................................................................. 28
Servlets...................................................................................................................................... 31
Notationen .......................................................................................................................... 33
2.5.1.
2.5.2.
2.5.3.
3.
Java............................................................................................................................................ 21
Geräteeigenschaften und Konfiguration der VM ................................................................. 22
Profile ......................................................................................................................................... 23
MIDlets....................................................................................................................................... 24
HelloWorld................................................................................................................................. 26
Internet und «mobile» Kommunikation ...................................................................... 28
2.4.1.
2.4.2.
2.5.
Ziele eines Workflow-Management-Systems (WfMS) ........................................................ 15
Die Workflow Management Coalition (WfMC) ..................................................................... 17
Das Workflow Referenzmodell der WfMC............................................................................ 17
Klassifizierung von Workflow-Management-Systemen (WfMS)........................................ 18
Java auf mobilen Geräten .............................................................................................. 21
2.3.1.
2.3.2.
2.3.3.
2.3.4.
2.3.5.
2.4.
Definition.................................................................................................................................... 11
Wie ein Prozess modelliert wird............................................................................................. 12
Ein Beispiel ............................................................................................................................... 13
Die Object Management Group (OMG) ................................................................................ 33
Unified Modelling Language (UML)....................................................................................... 33
Beispiel für die «Unified Modelling Language» Beispiel .................................................... 38
Entwicklung ............................................................................................................... 40
3.1.
Analyse des Ascom Workflow-Management-Systems (WfMS) ............................ 40
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.
3.2.
Analyse der zu erstellenden Software ........................................................................ 46
3.2.1.
3.2.2.
3.2.3.
3.3.
Was beinhaltet das Workflow-Management-System der Ascom?.................................... 41
Das Voice Workflow Modell .................................................................................................... 42
Wie ein Auftrag von einem externen Client übernommen wird ......................................... 45
Wie ein Workflow synchronisiert wird.................................................................................... 45
Der PDA als Client im Workflow-Management-System (WfMS) der Ascom................... 46
Anwendungsfalldiagramme (Use Cases) ............................................................................. 46
Anwendungsfallbeschreibung ................................................................................................ 47
Aktivitätsdiagramm................................................................................................................... 52
Design.................................................................................................................................. 56
3.3.1.
3.3.2.
3.3.3.
Systemarchitektur .................................................................................................................... 56
Klassendiagramme .................................................................................................................. 57
Sequenzdiagramme................................................................................................................. 58
- Seite 3 -
Einleitung
3.4.
Implementation Client ..................................................................................................... 63
3.4.1.
3.4.2.
3.4.3.
3.4.4.
3.4.5.
3.4.6.
3.4.7.
3.4.8.
3.4.9.
3.4.10.
3.5.
Implementation Server .................................................................................................... 78
3.5.1.
3.5.2.
3.5.3.
4.
Entwicklungsumgebung mit Forte 4 Java Mobile Edition................................................... 63
Exkurs: Netzwerkprobleme in der VM................................................................................... 65
User Interface bei einem PDA................................................................................................ 66
Netzwerkverbindungen mit dem PDA ................................................................................... 69
Persistente Datenspeicherung auf dem PDA ...................................................................... 71
Die Navigation in P2W............................................................................................................. 72
Programme auf einem Palm PDA.......................................................................................... 74
Spezialitäten der Applikation .................................................................................................. 75
Simulationen mit dem Palm OS Emulator ............................................................................ 76
Mocha PPP ............................................................................................................................... 77
Serverentwicklung mit Websphere Studio............................................................................ 78
Access-Datenbank (Administration) ...................................................................................... 79
Domino Notes-Datenbank....................................................................................................... 81
Inbetriebnahme und Installation .......................................................................... 84
4.1.
Server .................................................................................................................................. 84
4.1.1.
4.1.2.
4.1.3.
4.1.4.
4.1.5.
4.1.6.
4.2.
Client.................................................................................................................................... 88
4.2.1.
4.2.2.
4.2.3.
4.3.
Tomcat Server .......................................................................................................................... 84
Konfiguration des Tomcat Servers ........................................................................................ 85
Notwendige Java APIs ............................................................................................................ 85
Filestruktur auf dem Server .................................................................................................... 86
Administrationskonsole ........................................................................................................... 86
Konfigurationsfile...................................................................................................................... 87
Installation und Konfiguration der Virtual Machine (VM) auf dem PDA ........................... 88
Installation der P2W Applikation und der Testprogramme ................................................ 88
Verbindung zum Internet......................................................................................................... 89
Bedienungshandbuch P2W ........................................................................................... 90
4.3.1.
4.3.2.
4.3.3.
Einloggen und Workflow downloaden ................................................................................... 91
Workflow editieren.................................................................................................................... 93
Workflow synchronisieren ....................................................................................................... 94
5. Ausblick und Schlussbetrachtung............................................................................. 95
6.
Literatur und Verweise............................................................................................ 97
Glossar ................................................................................................................................. 100
Anhang A: Accessdatenbank......................................................................................... 104
Anhang B: Palm OS Emulator (POSE)......................................................................... 106
Anhang C: Mocha Soft PPP............................................................................................ 107
Anhang D: Beiliegende CD ............................................................................................. 108
- Seite 4 -
Einleitung
Bildverzeichnis:
Abbildung 1: Systemübersicht................................................................................................................. 9
Abbildung 2: Ablauf eines einfachen Geschäftsprozesses ................................................................... 13
Abbildung 3: Verschiedene Durchlaufzeiten Quelle: [Nohr] ................................................................. 16
Abbildung 4: Ziele − Zielerreichung Quelle: [Nohr] ................................................................................ 16
Abbildung 5 Referenzmodell gemäss WfMC Quelle: [WfMC] ............................................................... 17
Abbildung 6: Das 3K-Modell Quelle: [Nohr]........................................................................................... 18
Abbildung 7: Klassifikation von WfMS Quelle: [Nohr] ........................................................................... 19
Abbildung 8: Die vier WfMS Klassen Quelle: [Nohr] ............................................................................. 19
Abbildung 9: Verschiedene Sparten der Java-Pakete Quelle: [J2ME].................................................. 22
Abbildung 10: Aufbau der Java 2 Micro Edition Quelle: [Giguère 2000, Seite 23]................................ 23
Abbildung 11: Das Mobile Information Device Profile Quelle: [Topley 2002, Seite 45] ........................ 23
Abbildung 12: MIDP Skeleton................................................................................................................ 25
Abbildung 13: Lebenszyklus eines MIDlet Quelle: [Topley 2002, Seite 57].......................................... 25
Abbildung 14: Korrektes Beenden eines MIDlets.................................................................................. 26
Abbildung 15: HelloWorld MIDlet .......................................................................................................... 27
Abbildung 16: Ausgabe des HelloWorld MIDlet .................................................................................... 27
Abbildung 17: HTTP-Request und Response ....................................................................................... 28
Abbildung 18: Servlet Gerüst Quelle: [Callaway 1999, Seite 80] .......................................................... 32
Abbildung 19: Service Methode Quelle: [Callaway 1999, Seite 84] ...................................................... 32
Abbildung 20: Anwendungsfalldiagramm allgemein ............................................................................. 34
Abbildung 21: Klassendiagramm Quelle: [Oestereich 2001, Seite 260] ............................................... 34
Abbildung 22: Aktivitätsdiagramm allgemein......................................................................................... 35
Abbildung 23: Kollaborationsdiagramm Quelle: [Oestereich 2001, Seite 295] ..................................... 35
Abbildung 24: Sequenzdiagramm allgemein......................................................................................... 36
Abbildung 25: Zustandsdiagramm Quelle: [Oestereich 2001, Seite 304] ............................................. 36
Abbildung 26: Komponentendiagramm allgemein ................................................................................ 37
Abbildung 27: Einsatzdiagramm allgemein ........................................................................................... 37
Abbildung 28: Anwendungsfalldiagramm für HelloWorld ...................................................................... 38
Abbildung 29: Klassendiagramm von HelloWorld ................................................................................. 39
Abbildung 30: Sequenzdiagramm von HelloWorl.................................................................................. 39
Abbildung 31: Der Client vom Ascom WfMS......................................................................................... 41
Abbildung 32: Übersicht der Aktivitäten im Voice Workflow.................................................................. 42
Abbildung 33: Genereller IT-Workflow .................................................................................................. 42
Abbildung 34: Übersicht der Aufträge für Elektromonteure................................................................... 43
Abbildung 35: Formular eines Auftrages ............................................................................................... 44
Abbildung 36: Ablauf eines Auftrages ................................................................................................... 45
Abbildung 37: Use Case «Elektromonteur» .......................................................................................... 46
Abbildung 38: Use Case «Administrator» ............................................................................................. 47
Abbildung 39: Aktivitätsdiagramm Login ............................................................................................... 52
Abbildung 40: Aktivitätsdiagramm Synchronisation von Workflows...................................................... 53
Abbildung 41: Aktivitätsdiagramm Workflow downloaden..................................................................... 54
Abbildung 42: Aktivitätsdiagramm Workflow editieren und Titel anzeigen............................................ 55
Abbildung 43: Systemarchitektur........................................................................................................... 56
Abbildung 44: Klassendiagramm........................................................................................................... 57
Abbildung 45: Sequenzdiagramm Login ............................................................................................... 59
Abbildung 46: Sequenzdiagramm Download ........................................................................................ 60
Abbildung 47: Sequenzdiagramm Synchronisation .............................................................................. 61
Abbildung 48: Sequenzdiagramm WF Titel und Funktionen................................................................. 62
Abbildung 49: Forte 4 Java Mobile Edition............................................................................................ 63
Abbildung 50: Auto Comment Tool der IDE .......................................................................................... 64
Abbildung 51: Fehler in der VM von SUN ............................................................................................. 65
Abbildung 52: Klassendiagramm des User Interfaces .......................................................................... 66
Abbildung 53: Source Code eines Formulares...................................................................................... 67
Abbildung 54: Screenshot eines Formulares ........................................................................................ 67
Abbildung 55: Screenshot der Optionen ............................................................................................... 67
Abbildung 56: Screenshot Result Forms............................................................................................... 68
Abbildung 57: Screenshot mit Exit Button ............................................................................................. 68
Abbildung 58: STDOUT File vom PDA Emulator .................................................................................. 68
Abbildung 59: Kommunikationsweg Palm Quelle: [Funknetz]............................................................... 69
- Seite 5 -
Einleitung
Abbildung 60: Beispiel einer Internetverbindung................................................................................... 70
Abbildung 61: Screenshots der Internetverbindung .............................................................................. 70
Abbildung 62: Kommunikationsablauf ................................................................................................... 71
Abbildung 63: persistente Speicherung................................................................................................. 71
Abbildung 64: Hilfsvektor für den Speicherzugriff ................................................................................. 72
Abbildung 65: Generierung des Hilfsvektors ......................................................................................... 72
Abbildung 66: Navigation von P2W....................................................................................................... 73
Abbildung 67: Kompilierungsvorgang.................................................................................................... 74
Abbildung 68: P2W auf Handys ............................................................................................................ 75
Abbildung 69: Palm OS Emulator.......................................................................................................... 76
Abbildung 70: Anwendung von Mocha PPP.......................................................................................... 77
Abbildung 71: Websphere Studio.......................................................................................................... 78
Abbildung 72: Userverwaltung............................................................................................................... 79
Abbildung 73: Datenbankverbindung .................................................................................................... 79
Abbildung 74: SQL Abfrage................................................................................................................... 80
Abbildung 75: Verbindungsaufbau zu Domino Datenbanken ............................................................... 81
Abbildung 76: Die verschiedenen Kategorien im WfMS ....................................................................... 82
Abbildung 77: Eigenschaften eines Notes Dokumentes ....................................................................... 83
Abbildung 78: Konfiguration mit dem web.xml ...................................................................................... 85
Abbildung 79: File Struktur auf dem Server .......................................................................................... 86
Abbildung 80: Administrationskonsole .................................................................................................. 87
Abbildung 81: Konfiguration der J2ME VM ........................................................................................... 88
Abbildung 82: Konfiguration P2W Applikation....................................................................................... 88
Abbildung 83: Webclipping von Palm Quelle: zum Palm m505 mitgelieferte CD ................................. 89
Abbildung 84: Grundsätzlicher Ablauf der P2W Applikation ................................................................. 90
Abbildung 85: Pull-Down Menüs ........................................................................................................... 90
Abbildung 86: Workflow downloaden .................................................................................................... 91
Abbildung 87: Login............................................................................................................................... 91
Abbildung 88: Fehlermeldung beim Loginvorgang................................................................................ 92
Abbildung 89: Auftragsliste.................................................................................................................... 92
Abbildung 90: Auftragdetails.................................................................................................................. 92
Abbildung 91: Auftrag übernehmen....................................................................................................... 92
Abbildung 92: Workflow editieren.......................................................................................................... 93
Abbildung 93: Lokale Aufträge .............................................................................................................. 93
Abbildung 94: Funktionen...................................................................................................................... 93
Abbildung 95: Anzahl synchronisierbarer Aufträge ............................................................................... 93
Abbildung 96: Workflow synchronisieren .............................................................................................. 94
Abbildung 97: Synchronisation .............................................................................................................. 94
Abbildung 98: Synchronisationsmeldung .............................................................................................. 94
Abbildung 99: Prognose von J2ME Quelle: [Zelos]............................................................................... 96
Abbildung 100: ODBC Datenquellen................................................................................................... 104
Abbildung 101: ODBC Administrator................................................................................................... 104
Abbildung 102: Datenbank .................................................................................................................. 105
Abbildung 103: User und Passwort der Datenbank ............................................................................ 105
Abbildung 104: Konfiguration des Palm Emulators............................................................................. 106
Abbildung 105: Mocha PPP Screenshot ............................................................................................. 107
Abbildung 106: Konfiguration des Palms für Mocha PPP ................................................................... 107
- Seite 6 -
Einleitung
Tabellenverzeichnis:
Tabelle 1: Hardwareeigenschaften Quelle: [Topley 2002] .................................................................... 24
Tabelle 2: Anforderungen an die Software Quelle:[Topley 2002] ......................................................... 24
Tabelle 3: Headerinformationen eines Requests .................................................................................. 29
Tabelle 4: HTTP Response ................................................................................................................... 30
Tabelle 5: Anwendungsfallbeschreibung HelloWorld............................................................................ 38
Tabelle 6: Workflow editieren und Details betrachten........................................................................... 48
Tabelle 7: Workflow Auswahl und Titelübersicht................................................................................... 48
Tabelle 8: Workflows synchronisieren................................................................................................... 49
Tabelle 9: Synchronisierbare Workflows anzeigen ............................................................................... 49
Tabelle 10: Einen Workflow downloaden .............................................................................................. 50
Tabelle 11: Login ................................................................................................................................... 50
Tabelle 12: Die Verbindung zum Server auf- oder abbauen................................................................. 51
Tabelle 13: Den Server stoppen............................................................................................................ 51
Tabelle 14: Den Server starten.............................................................................................................. 51
Tabelle 15: Parameter für die Datenbankverbindung ........................................................................... 80
Tabelle 16: Verbindungsparameter zum WfMS .................................................................................... 81
Tabelle 17: Verwendete Software ......................................................................................................... 83
Tabelle 18: Umgebungsvariablen.......................................................................................................... 84
Tabelle 19: Konfigurationsfile ................................................................................................................ 87
- Seite 7 -
Einleitung
Abstract:
Die vorliegende Diplomarbeit wurde in
Zusammenarbeit mit dem Praxispartner
Ascom Informatik durchgeführt. In diesem
Projekt wurde ein Prototyp erstellt, der ein
bestehendes Workflow-Management-System
(WfMS) erweitert. Erweitert in dem Sinne, dass
das WfMS mit einem Portable Digital Assistant
(PDA) benutzt werden kann. Der PDA kann
von einem beliebigen Ort mit einem Handy via
Internet Daten aus dem WfMS beziehen. Er
kann diese Daten Offline bearbeiten und nach
Belieben
wieder
mit
dem
System
synchronisieren. Der User hat somit die
Möglichkeit, Geschäftsdaten unabhängig von
seinem Standort einzusehen. Der Prototyp soll
sich genau gleich wie der bereits bestehende
WfMS-Client verhalten.
Der Prototyp kann von den Elektromonteuren
eingesetzt werden, die in der Ascom die
interne Telefonie betreuen. Die Wartung der
internen
Telefonie
wird
durch
den
bestehenden WfMS-Client gemanagt. Dem
Elektromonteur wird mit diesem Prototyp
ermöglicht, dass er orts- und zeitunabhängig
Daten aus dem WfMS einsehen und
bearbeiten kann. Die Administration der
Userverwaltung ist durch ein Web-Interface
gelöst. Die Userdaten werden in einer
Datenbank gepflegt.
Der PDA besitzt die Funktion eines Clients,
welcher mit einem Servlet kommuniziert, das
in einer Tomcatumgebung eingebettet ist. Das
Servlet sowie die Administrationskonsole
werden durch ein XML-File konfiguriert. Das
Servlet führt ein Logfile, welches die getätigten
Aktionen festhält.
This thesis was realised in co-operation with
the IT department of Ascom. In this project an
existing
workflow-management-system
(WfMS) was extended by a prototyp. The
extension supports the use of the WfMS with a
portable digital assistant (PDA).
The mobile PDA, located anywhere allows
transfering data from a portable telephone via
internet to the WfMS. After processing the data
off-line the PDA provides a synchronization
with the system.
Hence, the user has got the possibility to have
a look at business data independently of his
location. The same behaviour of the PDA and
the existing WfMS client ensures the
transaction without difficulties. The prototype
can be used by the electrical mechanics
managing the internal telephone network of the
Ascom. The existing WfMS maintains the
internal telephone network. The electrical
mechanic is able to process data of the WfMS
independently of location and time.
The user administration is solved by a webinterface. The user data is maintained in a data
base. The PDA has got the function of a client
communicating with a servlet embedded in a
tomcat environment. The servlet as well as the
administration console is configured by a XMLfile. The servlet saves all activities in a log file.
Schlüsselwörter / Keywords:
Workflow, Workflow-Management-System (WfMS), Portable Digital Assistent (PDA), Java 2 Micro
Edition (J2ME), Java Servlets, Handy, Lotus Notes, Client-Server, XML, Java Server Pages (JSP)
- Seite 8 -
Einleitung
1. Einleitung
«The future is mobile», so der Trend in der Kommunikationsbranche. PDAs und Handys verschmelzen
immer mehr zu einem Gerät. Das Projekt das in dieser Arbeit beschrieben ist, soll eine Grundlage
schaffen, um sich vom Ascom WfMS, unabhängig vom Standort und ungebunden an das Intranet,
Informationen zu beschaffen und diese nutzen zu können.
1.1. Problemstellung
Die Ascom Informatik unterhält ein Workflow-Management-System (WfMS), welches Bestellvorgänge
und Anschlussänderungen im Bereich der internen Telefonie managt. Die Ascom beschäftigt in der
Informatikabteilung rund 20 Elektromonteure. Diese erledigen zeitweise in der betriebseigenen
Werkstatt Reparaturarbeiten. Neben Reparaturarbeiten sind die Elektromonteure jedoch den grössten
Teil ihrer Arbeitszeit ausserhalb des Hauses. Diejenigen Elektromonteure, welche im Bereich der
internen Telefonie arbeiten, müssen bei einem Büroumzug vor Ort die Telefone ersetzen. Dabei ist die
telefonische Erreichbarkeit des Umziehenden zu gewährleisten. Dies bedeutet, dass ein
Elektromonteur beim alten Standort das Telefon entfernt und derselbe – oder auch ein anderer –
Elektromonteur das Telefon an einem neuen Ort wieder installiert.
Dieser Arbeitsablauf beginnt mit dem Stellen eines Antrages für ein neues Telefon und endet mit der
Installation des Telefons – ein Verlauf, der ideal in einem elektronischen Workflow abgebildet werden
kann. Dies wurde bei der Ascom Informatik auch so umgesetzt und ist Bestandteil des vorhanden
WfMS der Ascom.
Die Arbeit der Elektromonteure soll deutlich vereinfacht werden. Bis zum heutigen Zeitpunkt mussten
die Elektromonteure ihre Aufträge immer mit dem WfMS-Client Lotus Notes beziehen und
abschliessen. Dies mussten sie von einem am Intranet angeschlossenen Computer aus erledigen.
PDA
Workflow
Sendemast
Server
Abbildung 1: Systemübersicht
Genau dieser Arbeitsablauf soll mit dem Projekt «PDA to IT-Workflow» (P2W) vereinfacht werden. Der
Elektromonteur soll seine Workflows unabhängig von seinem Standort betrachten und bearbeiten
können. P2W soll diese Aufgabe übernehmen. Der Elektromonteur soll mit PDA und Handy die
notwendigen Daten des Workflows beziehen können.
- Seite 9 -
Einleitung
1.2. Zielsetzung
Die Diplomarbeit sollte das bestehende WfMS mit einem neuen Medium erweitern. Es sollte möglich
sein, dass Daten vom WfMS mit einem Portable Digital Assistant (PDA) gelesen werden können. Mit
einem PDA und einem Handy wird eine Verbindung zu einem Server aufgebaut. Dieser Server leitet
die Anfragen vom PDA an das WfMS weiter und sendet die vom WfMS erhaltenen Daten zum PDA
zurück. Die Daten auf dem PDA sollten in einer ähnlichen Form gezeigt werden, wie sie im WfMS auf
dem Client (Lotus Notes) dargestellt werden. Der Anwender sollte die erhaltenen Daten auf seinem
PDA speichern und auch offline bearbeiten können. Sind die Daten einmal bearbeitet, sollte er die
Möglichkeit haben, die Daten wieder mit dem WfMS zu synchronisieren. Anders gesagt: Der Server
sollte die entsprechenden Daten dem WfMS schicken und die nötigen Aktionen unternehmen, welche
bei einer Manipulation der Workflowdaten auf dem herkömmlichen Client unternommen werden
würden.
Ein User muss sich beim Systemverantwortlichen anmelden können. Dieser wird ihm ein
entsprechendes Konto zur Benutzung des P2W einrichten. Nun kann sich der Elektromonteur mit
seinem PDA (P2W-Client) auf dem P2W-Server anmelden. Der Server sollte die Autorisierung
überprüfen und ihm die offenen Aufträge in einer Liste aufzeigen. Beim Anklicken der verschiedenen
Aufträge sollen die Details ersichtlich und bearbeitbar sein. Alle Aufträge, die einmal übernommen
wurden, sollen auch offline bearbeitet werden können. Die Abbildung 1 zeigt nur eine grobe Übersicht
der Architektur von P2W.
Die Diplomarbeit sollte eine Entscheidungsgrundlage bilden, anhand deren entschieden werden kann,
ob der erstellte Prototyp weiterentwickelt und zu einem späteren Zeitpunkt eingesetzt werden wird. Die
erarbeiteten Erkenntnisse mit dem WfMS sollten zeigen, ob und wie ein externer Client mit dem WfMS
arbeiten kann.
Im Laufe des Projektes wurde die Abteilung «Webapplication» der Ascom Informatik geschlossen. Wo
dieser Entscheid Einfluss auf das Projekt hat, wird speziell darauf hingewiesen.
1.3. Vorgehensweise
In einem ersten Arbeitsabschnitt wurde das bestehende WfMS analysiert. Die für das Projekt
relevanten Workflows des WfMS wurden herausgesucht. Die Entwicklung des Projekts wurde mittels
Analyse, Design und Implementation angegangen. In der Analyse wurden die Use Cases, deren
Beschreibungen und die Aktivitätsdiagramme erstellt. In der Designphase wurden die
Systemarchitektur festgelegt und die Sequenzdiagramme gezeichnet. Alle erstellten Diagramme
wurden in der «Unified Modelling Language» (UML) gezeichnet (siehe Kapitel 2.5.2) .
Analyse- und Designphase bildeten die Basis für die Implementation, welche am Schluss erfolgte. Das
Projekt wurde vollumfänglich in Java (siehe Kapitel 2.3.1) programmiert.
- Seite 10 -
Grundlagen
2. Grundlagen
Der Grundlagenteil festigt die theoretische Basis zum Verständnis des Projekts. Der erste Teil dieses
Kapitels beschäftigt sich mit Workflows und Workflow-Management-Systemen. Bei beiden Punkten
wird Wert auf eine präzise Definition und Erklärung gelegt. Die vorhandenen Diagramme sind alle mit
der UML Notation erstellt worden. Mit einfachen Beispielen wird die Theorie dem Leser verständlicher
gemacht. Ein weiterer Teil der Theorie befasst sich mit der Thematik von Java auf mobilen Geräten.
Dieser Teil behandelt Grundsätzliches zur Java Virtual Machine (VM) auf einem Portable Digital
Assistant (PDA), sie wird anhand eines einfachen Beispiels erklärt. Danach werden Grundsätze des
Internets und von Servlets aufgezeigt. Der letzte Teil dieses Kapitels beschäftigt sich mit den in
diesem Projekt verwendeten Notationen. Es wird erklärt, wie UML-Diagramme verwendet, gezeichnet
und gelesen werden. Ein Schwerpunkt in diesem letzten Teilkapitel ist der Zusammenhang zwischen
den verschiedenen Diagrammen. Auch hier hilft ein einfacheres Beispiel zum Verständnis.
2.1. Workflows
Um Workflow-Management-Systeme (WfMS) begreifen zu können, muss man sich zuerst mit den
Eigenschaften von Workflows beschäftigen. Wenn der Begriff Workflow nicht klar verständlich ist,
macht es wenig Sinn WfMS zu betrachten. Die Definition von Workflows sollte ein wenig Licht ins
Dunkle bringen:
2.1.1. Definition
Workflow: «Ein Workflow ist eine zum Teil automatisiert − von einem Workflow-Management-System
gesteuert − ablaufende Gesamtheit von Aktivitäten, die sich auf Teile eines Geschäftsprozesses oder
andere organisatorische Vorgänge beziehen. Ein Workflow besteht aus Abschnitten, so genannte
Subworkflows, die weiter zerlegt werden können. Er hat einen definierten Anfang, einen organisierten
Ablauf und ein definiertes Ende.» [Böhm 1997, Seite 3]
Workflow-Management: «Ein Workflow-Management umfasst alle Aufgaben, die bei der
Modellierung, Spezifikation, Simulation sowie bei der Ausführung und Steuerung der Workflows erfüllt
werden müssen» [Borghoff 2000, Seite 346]
Workflow-Management-System: «Dies ist ein aus mehreren Werkzeugen bestehendes System, das
die Aufgaben des Workflow-Management durch Softwareausführung unterstützt» [Borghoff 2000,
Seite 346]
Process: A formal view of a business process, represented as a coordinated (parallel and/or serial)
set of process activities that are connected in order to achieve a common goal. [Fischer 2003]
Business Process: A set of one ore more likes procedures or activities which collectively realise a
business objective or policy goal, normally within the context of an organizational structure defining
functional roles and relationships. [Fischer 2003]
Activity: A description or a piece of work that forms one logical step within a process. An activity may
be a manual activity, which does not support computer automation , or a workflow (automated) activity.
A workflow activity requires human and/or machine resources to support process execution; where
human resource is required an activity is allocated to a workflow participant. [Fischer 2003]
Workflow Management : Automation of procedures or workflows where documents, information or
tasks are passed from one participant to another in a way that is governed by rules or procedures.
[Fischer 2003]
Workflow Management System: A system that defines, creates and manages the execution of
workflows through the use of Software, running on one or more workflow engines, which is able to
interpret the Process definition, interact with workflow participants and, where required, invoke the use
of IT tools and applications. [Fischer 2003]
- Seite 11 -
Grundlagen
Process Definition: The representation of a business process in a form which support automated
manipulation, such as modelling, or enactment by a workflow management system, The process
definition consists of a network of activities and their relationships, criteria to indicate the start and
termination of the process, and information about the individual activities, such as participants,
associated IT applications and data, etc. [Fischer 2003]
Process Instance: The representation of a single enactment of a process. [Fischer 2003]
Gemäss diesen Definitionen ist ein Workflow nichts anderes als eine Folge von Aktivitäten. Das
Beispiel im Kapitel 2.1.3 zeigt den Ablauf eines einfachen Geschäftsprozesses. Workflows können mit
Flussdiagrammen oder mit UML dargestellt werden. Die Ascom stellt ihre Workflows mittels
Flussdiagrammen dar (siehe hierzu die Abbildung 33). Werden Workflows mit UML visualisiert, so
eignen sich die Aktivitätsdiagramme am besten.
2.1.2. Wie ein Prozess modelliert wird
Modellierung von Prozessen dient der Verständlichkeit und der Übersicht der Geschäftstätigkeiten.
Anhand von Modellen, können Optimierung, Vereinfachungen und Änderungen von Abläufen
einfacher erarbeitet werden.
Die Frage stellt sich nun, wie ein Prozess modelliert werden kann. Um Prozesse zu modellieren,
werden der Übersicht halber grafische Darstellungsformen gewählt. Diese sind um ein Vielfaches
verständlicher als Tabellen und Beschreibungen. Ebenso ist bei einer grafischen Darstellung die
Normierung einfacher. Einzelne Prozessschritte werden mit einem Rechteck dargestellt. Die
verschiedenen Schritte werden mit Pfeilen verbunden, welche den Ablauf klären. Eine parallele oder
sequentielle Abarbeitung kann anschaulich dargestellt werden.
Wichtig ist bei der Modellierung von Prozessen, dass die Unternehmensstruktur und deren
Organisation mitberücksichtigt werden. Diese Struktur bestimmt oft den Laufweg eines Dokumentes
oder einer Bestellung1. Um ein Modell zu erstellen, bestehen in der Regel zwei Ansätze:
Man verwendet die «Bottom-Up» oder die «Top-Down» Methode. Bei der «Top-Down» Methode ist
die Aufgabe des Unternehmens der Startpunkt. Bei «Bottom-Up» hingegen die effektive Aktivität. Wie
bei vielen Modellierungen kann auch hier nicht gesagt werden, welche der beiden Methoden die
passende ist. In der Regel empfiehlt sich eine Mischform beider Methoden.
Im Folgenden werden die wichtigsten Modellierungsschritte aufgezeigt und die wichtigsten Punkte
erläutert. [Böhm 1997]
-
Bestimmung des Auslösers.
Zustandsänderung eines Objektes. Zum Beispiel das Aufgeben eines Auftrages oder das
Genehmigen eines solchen Auftrages.
Festlegung der Start- und Endpunkte.
Zustandsänderungen in der Datenbasis. Hier sollte die Frage geklärt werden, auf welchen
Zustand von Daten aufgebaut wird und wie diese Daten am Ende der Abarbeitung aussehen
werden.
Ermittlung der fachlichen Aktivitäten.
Reihenfolge der Aktivitäten.
Aktivitäten einfügen, die verwendet werden, um Ortsveränderungen miteinzubeziehen. Ebenso
sollte an dieser Stelle der Faktor Zeit einbezogen werden.
Zuerst wird der Normalablauf beschrieben, dann sollten Sonderfälle und verschiedene Variationen
behandelt werden.
Modellierung der Ausnahmen.
Die Modellierung sollte nach Möglichkeit in einem objektorientierten Ansatz erfolgen. Komponenten,
die mehrmals verwendet werden können, müssen identifiziert und richtig eingesetzt werden. Die
«Wiederverwendbarkeit» verringert den Modellierungsaufwand. Die Fehlerquote sowie der
Bereinigungsaufwand dieser Fehler sinken dementsprechend.
1
Oft muss eine Bestellung vom Vorgesetzten genehmigt werden, daher muss zur Modellierung das Organigramm
berücksichtigt werden.
- Seite 12 -
Grundlagen
Die Modellierung sollte so erfolgen, dass wenn sich das Unternehmensmodell ändert (z.B. Änderung
im Organigramm), dies auch automatisch einen Einfluss auf die Modellierung und den Ablauf des
Prozesses hat. Dies benötigt eine regelmässige Synchronisation mit den Unternehmensdaten. Dieser
Schritt ist enorm wichtig, denn er kann einen gewaltigen Zeitaufwand auslösen, wenn das
Unternehmen umstrukturiert wird, und dem Abgleich mit den Unternehmensdaten zuwenig Gewicht
gegeben wurde.
2.1.3. Ein Beispiel
Betrachten wir einen einfachen Geschäftsprozess eines kleineren Unternehmens: Ein Mitarbeiter
braucht ein spezielles Bauelement für einen bestimmten Auftrag. Er wählt die benötigte Komponente
aus einem branchenüblichen Katalog heraus und bestellt diese. Da die Firmenstruktur eine
Genehmigung vom Vorgesetzten für jede Bestellung verlangt, muss der Mitarbeiter ihm diese
Bestellung zuerst zum Visieren vorlegen. Der Vorgesetzte kann nun die Bestellung genehmigen oder,
falls er ein alternatives oder stärker präferiertes Produkt kennt, diese mit dem Vermerk des
alternativen Produktes zum Mitarbeiter zurückweisen. Der Mitarbeiter kann mit den Angaben des
Vorgesetzten prüfen, ob das alternative Produkt die Spezifikationen seines Auftrages erfüllt. Dieser
Vorgang kann sich beliebig wiederholen. Ist der Vorgesetzte mit dem Bestellungsvorschlag des
Mitarbeiters einverstanden, kann er die Bestellung genehmigen, und diese wird zum Beispiel vom
Postboten auf die Post gebracht oder vom Sekretariat mit anderen Bestellungen zusammen
verschickt. Die Abbildung 2 zeigt diesen Ablauf in einem UML-Aktivitätsdiagramm.
Bestellen eines Artikels
Vorgesetzter entscheidet über Bestellung
Bestellung
zurückgewiesen
Bestellung akzeptiert
Bestellung wird verschickt
Abbildung 2: Ablauf eines einfachen Geschäftsprozesses
Die Abbildung 2 zeigt die verschiedenen Aktivitäten des Geschäftsprozesses «Bestellen». Der Ablauf
eines solchen Prozesses wird in einem WfMS als Workflow abgebildet. Dieser Vorgang kann mit Hilfe
eines Workflow-Management-Systems (WfMS) optimiert respektive automatisiert werden. Die
Bestellformulare sind in digitaler Form vorhanden. Der Mitarbeiter kann ein solches Formular an
seinem Arbeitsplatz ausfüllen und dieses an seinen Vorgesetzten per E-Mail verschicken. Dieser kann
das Formular − im Falle einer Genehmigung der Bestellung − an den Postboten oder an das
Sekretariat weiterschicken. Im Falle einer Ablehnung der Bestellung kann der Vorgesetzte das
Formular mit dem entsprechenden Verweis erweitern und an den Mitarbeiter zurückschicken. Alle
Beteiligten in der Firma können den Status ihrer Bestellung zu jedem Zeitpunkt einsehen. Im Falle des
beschriebenen Geschäftsprozesses mag es nicht gerade effizientsteigernd klingen, wenn man diesen
Geschäftsprozess mit einem teuren WfMS optimiert. Es gibt aber viele Firmen, die ähnliche
Geschäftsprozesse aufweisen, aber mehr Prozessbeteiligte haben. In solchen Fällen eignet sich ein
WfMS.
- Seite 13 -
Grundlagen
Prozesse in Firmen könnten folgendermassen optimiert werden:
-
Der Zustand des Ablaufes kann jederzeit und von allen Teilnehmern kontrolliert werden. Die
Transparenz bezüglich der Auftragsabwicklung ist gewährleistet.
Die Zuständigkeit ist klar definiert. Unklare Zuständigkeit ist ein häufig anzutreffendes Problem.
Mittels einem WfMS kann dies weitgehend umgangen werden, da die Ablaufprozesse klar
definiert wurden.
Genauere Terminzusagen ergeben sich aus den letzten zwei Punkten.
Ein Wechsel von Medien (Papier, Fax, Telefon, E-Mail) kann vermieden werden.
Der Hauptverantwortliche (Manager) kann sich auf seine Tätigkeiten konzentrieren und muss nicht
die laufenden Aufträge kontrollieren, um über deren Status Auskunft geben zu können.
Diese Vorteile helfen dem Unternehmen, Arbeitsabläufe zu strukturieren und somit zu optimieren. Ein
weiterer Vorteil der Untersuchung von Geschäftsprozessen hinsichtlich deren Automation besteht
darin, dass diese neu strukturiert und verbessert werden können. Diese Optimierungen können mit
einem WfMS erreicht werden.
- Seite 14 -
Grundlagen
2.2. Workflow-Management-Systeme (WfMS)
Die Grundlagen und Darstellungsmöglichkeiten eines Workflows sind im vorangegangenen Kapitel
aufgezeigt worden. Jetzt soll dem Leser in einfacher Weise die Handhabung von Workflows näher
gebracht werden. Zuerst werden die Ziele, die den Einsatz von WfMS rechtfertigen, aufgezeigt.
Danach folgt eine Übersicht der gängigsten Definitionen. Der dritte und der vierte Teil erklärt die
Standardisierung von WfMS. Der fünfte Teil widmet sich der Klassifizierung der WfMS.
2.2.1. Ziele eines Workflow-Management-Systems (WfMS)
In der heutigen Zeit werden in Unternehmen vermehrt Informationssysteme zur Optimierung von
Geschäftsabläufen eingesetzt. So werden auch WfMS zu diesem Zweck eingesetzt. Diese
Management Systeme konzentrieren sich vor allem auf die Steuerung der Geschäftsprozesse.
Ziel eines WfMS ist es, solche Aktivitäten möglichst optimal miteinander zu verbinden. Der
Informationsfluss wird mit einem WfMS automatisiert, was die Weitergabe, die Bearbeitung und der
Abschluss von Prozessen innerhalb eines Unternehmens (auf strategischer, funktionaler und
operativer Ebene) deutlich erleichtert. Workflow-Systeme verkürzen in der Regel die Zeit zwischen
den einzelnen logischen Schritten, da die nächste Stelle die erforderlichen Informationen automatisch
erhält und nicht zuerst noch Informationen zu der zu bearbeitenden Aktivität zusammentragen muss.
Das Management-System verteilt die richtige Arbeit zum richtigen Zeitpunkt an den richtigen
Mitarbeiter, dieser erhält augenblicklich alle notwendigen Informationen, Dokumente und Hinweise.
Werden Workflow-Systeme richtig angewendet, erreicht ein Unternehmen [Borghoff 2000]:
-
Klar prozessorientiertes Arbeiten
Verminderung von Fehlerquellen
Qualitätssteigerung
Produktivitätssteigerung
Kostensenkung
Erhöhung der Informationsverfügbarkeit
Eine Erhöhung der Informationsverfügbarkeit bringt nicht nur einen psychologisch positiven Effekt,
sondern kann auch zu einer Produktivitätssteigerung führen. Information ist das einzige Gut, deren
Wert sich beim Teilen steigert. Wie schon erwähnt, ist der Einsatz von WfMS nur sinnvoll, wenn die zu
verarbeitenden Vorgangstypen eine geringe Komplexität und eine hohe Strukturierbarkeit aufweisen.
Die Universität Linz verglich zwei verschiedene Vorgangstypen in Bezug auf die Durchlaufzeit:
- Seite 15 -
Grundlagen
Abbildung 3: Verschiedene Durchlaufzeiten
Quelle: [Nohr]
Erstaunlich ist, dass die Liegezeit des mit einem WfMS um rund 50% grösser ist als ohne WfMS. Wird
aber die totale Durchlaufzeit betrachtet, so schneidet ein WfMS deutlich besser ab. Die längere
Liegezeit könnte natürlich auch durch Unachtsamkeiten der Mitarbeiter hervorgerufen werden. Liest
ein Mitarbeiter nicht umgehend die neu eintreffenden Mails, so können sich schnell grössere
Verzögerungen ergeben. Ein weiterer interessanter Vergleich bietet die Betrachtung der Ziele und
deren Annäherung.
Abbildung 4: Ziele − Zielerreichung
Quelle: [Nohr]
- Seite 16 -
Grundlagen
Die Abbildung 4 zeigt eine deutliche Steigerung der bewerteten Parameter. Die Kostenreduktion zeigt,
dass es sich durchaus lohnen kann, in ein WfMS zu investieren. Dies natürlich immer mit dem
Vorbehalt, dass das Problem dafür geeignet sein muss. Ein WfMS eignet sich für Prozesse, die eine
hohe Strukturierung aufweisen und eine geringe Komplexität haben. Werden WfMS für komplexe
Probleme verwendet, so erreichen diese Systeme oft das Gegenteil.
2.2.2. Die Workflow Management Coalition (WfMC)
Die Workflow Management Coalition (WfMC) ist eine ähnliche Vereinigung wie die Object
Management Group2 (OMG). Beide Organisationen haben sich zum Ziel gesetzt Standards auf
gewissen Informatikgebieten zu definieren. Die WfMC beschäftigt sich mit dem Festlegen von
Standards für Workflow Management Systeme [WfMC]. Die Organisation gibt jedes Jahr ein
Handbuch für Workflow Management Systeme heraus [Fischer 2003].
Die WfMC setzte sich im Jahre 1998 aus mehr als 200 Mitgliedern zusammen. Mitglieder sind u.a.
Xerox, HP, IBM, Microsoft und SAP.
Die Vereinigung unterhält drei Themengruppen, welche sich mit unterschiedlichen Bereichen
befassen:
-
-
Workflowreferenzmodell
Definition der Workflow Terminologie
Definition der Schnittstellen zwischen den einzelnen Komponenten des Referenzmodelles. Diese
fünf Schnittstellen sind standardisiert und definieren die Datenaustauschformate (Application
Programming Interface)
2.2.3. Das Workflow Referenzmodell der WfMC
Die WfMC erarbeitete das Referenzmodell, welches die Workflowsystem-Architektur modelliert. Das
Modell definiert Merkmale, Funktionen, Eigenschaften und Schnittstellen (Interfaces) eines Systemes.
Ebenso werden die Systemgrenzen und Schnittstellen beschrieben.
Abbildung 5 Referenzmodell gemäss WfMC
Quelle: [WfMC]
Die Schnittstelle 1 (in der Abbildung 5 mit «Interface 1» bezeichnet) dient zum Austausch von
Workflow-Beschreibungen, die von der Ablaufkomponente (WF Enactment Service) ausgeführt
werden sollen. Diese Schnittstelle ist in der Regel in einer so genannten «Workflow Process Definition
Language» (WPDL) implementiert. Systementwickler verwenden das Application Programming
2
Siehe Kapitel 2.5.1
- Seite 17 -
Grundlagen
Interface (API) zur Überführung der Workflow Spezifikation in das gewünschte Workflow System.
Ebenso dient diese API zur Konvertierung von der internen in die externe WPDL Darstellung.
Die Schnittstelle 2 ermöglicht dem User eine Interaktion mit dem Workflowsystem. Client
Anwendungen laufen unabhängig und werden vom Anwender kontrolliert. Das «Workflow Application
Programming Interface» (WAPI) baut eine Verbindung zu Workflowkomponenten (Subworkflows) auf,
um die Ausführung/Auslösung von Workflows zu steuern und um den Status von Workflows
abzufragen. Die Schnittstelle 3 arbeitet ohne Interaktion eines Anwenders. Das WorkflowManagement-System kann durch einen internen Event eigene Applikationen starten, ausführen und
kontrollieren. Natürlich können WfMS auch untereinander verbunden und gekoppelt werden. Die
Verbindung zu externen Management Systemen regelt die Schnittstelle 4. Zu guter Letzt haben wir
noch die fünfte Schnittstelle, welche ausschliesslich für administrative Zwecke wie Monitoring und
Datenaustausch zwischen Workflowkomponenten gedacht ist. Der «Workflow Enactment Service»
welcher im Zentrum der Abbildung 5 zu sehen ist, besteht aus einer oder mehreren Workflow Engines.
Sie bildet die Runtime-Umgebung für die Workflows. Es ist die Komponente, die die WorkflowDefinitionen interpretiert und den Arbeitsablauf speichert. Die Applikationen und Anwender-Tools sind
die so genannten Clients, mit denen der Workflow bearbeitet wird. [Nohr]
2.2.4. Klassifizierung von Workflow-Management-Systemen (WfMS)
Um sich im breiten Angebotsfeld der WfMS zurechtzufinden, bedarf es einer Klassifizierung der
verschiedenen Systeme. Workflowsysteme lassen sich nach gewissen Kriterien unterscheiden. Zur
Darstellung dieser Unterschiede wird häufig das 3K-Modell verwendet. Generell kann gesagt werden,
dass WfMS Prozesse im Bereich Kommunikation, Koordination und Kooperation unterstützen, daher
der Name 3K-Modell.
Abbildung 6: Das 3K-Modell
Quelle: [Nohr]
Der ideale Punkt für den optimalen Arbeitsablauf ist in der Abbildung 6 in der Mitte zu finden. Er
bedeutet ein Optimum an Kommunikation, Kooperation und Koordination. Für einen Geschäftsprozess
ist ein gemeinsamer Informationsraum im herkömmlichen Sinne jedoch kaum realisierbar.
WfMS werden gemäss [Nohr] nach zwei Kriterien klassifiziert: Einerseits auf Grund der Struktur der
modellierten Geschäftsprozesse, andererseits nach dem Architekturmodell.
- Seite 18 -
Grundlagen
Die erste Einteilung beschäftigt sich hauptsächlich mit der Analyse der Organisation und der
vorhandenen Prozesse. Die Organisation sowie die Prozesse werden in den Workflows abgebildet
und strukturiert. Erst gut modellierte und strukturierte Modelle lassen sich problemlos elektronisch
unterstützten.
Bei dieser Einteilung kann von so genannten «Push-» oder «Pull-Systemen» gesprochen werden.
Push-Systeme steuern die Abläufe aktiv. Das System gibt dem Anwender die benötigten
Informationen automatisch. Die Pull-Systeme verhalten sich im Gegensatz dazu eher passiv. Der
Anwender muss sich die Informationen selber beschaffen oder die nötigen Aktionen aus eigener
Initiative starten. Die Aufgabe der Steuerung liegt beim Anwender. WfMS werden in der Regel auf
Grund des Prozess-Strukturierungsgrad und der Prozess-Frequenz unterschieden.
Abbildung 7: Klassifikation von WfMS
Quelle: [Nohr]
Auf dieser Basis werden WfMS in drei Klassen aufgeteilt.
-
Collaborate-WfMS
Produktions-WfMS
Ad-hoc-WfMS
Diese Klassen bestimmen demnach auch das Einsatzgebiet der verschiedenen WfMS.
Standardmässig wird noch eine weitere Klasse verwendet, diese basiert hauptsächlich auf
elektronischer Formularbearbeitung und wird «Administrations-WfMS» genannt. In der «IT-Welt» wird
oft von einem so genannten «low-cost/low-volume»-Produktions-WfMS gesprochen. Die vier WfMS
können in einem Koordinatensystem mit den Achsen «Wertschöpfungsgrad» und
«Wiederholungsgrad» dargestellt werden.
Abbildung 8: Die vier WfMS Klassen
Quelle: [Nohr]
- Seite 19 -
Grundlagen
Die Einsatzgebiete der WfMS: [Nohr]
-
-
-
Produktions-WfMS: Das Einsatzgebiet hierfür sind stark strukturierbare und genau geregelte
Abläufe, die viele Arbeiter unternehmensweit einbeziehen. Das WfMS übt in diesem Falle eine
aktive Rolle bei der Steuerung der Prozesse. Die Unternehmensdaten wie Ablauf- und
Aufbauorganisation ist dem System hinterlegt. Beispiele: SAP Business Workflow, Staffware,
Flowmark (IBM).
Collaborate-WfMS: Der Schwerpunkte dieser Systeme liegt bei gruppenorientierten Aufgaben,
wie zum Beispiel Produkteentwicklung. Teile der Abläufe werden fix definiert, es sind aber noch
flexible Eingriffe in das System möglich. Beispiele: Enterprise Workflow, InConcert, Team WARE
Flow,...
Ad-hoc-WfMS: Ihr Einsatz ist dort zu finden, wo sich Prozesse häufig ändern oder wo Prozesse
relativ wenig verwendet werden. Beispiele: Keyflow, Ensemble,...
Administrations-WfMS: Sie unterstützten sowohl wohlstrukturierte wie auch wenig strukturierte
Prozesse. Da der Wertschöpfungsgrad und die Anforderung an die Durchlaufzeiten klein sind,
wurden bei diesen Systeme diverse Funktionen zur Unterstützung von Prozessen weggelassen.
Die zweite Einteilung unterscheidet Workflowsysteme anhand des Kontroll- und
Informationsflusses: [Nohr]
-
-
-
E-Mail basierend: Dieses Modell eignet sich gut um sogenannte Umlaufmappen abzubilden. Die
E-Mails werden von einer Stelle an die nächste geschickt. Dieses System bietet aber keinen
eigentlich Einblick in den Arbeitsablauf, da die E-Mails nur von Punkt A nach Punkt B geschickt
werden, ohne dass zum Beispiel Punkt C Kenntnis vom Stand der Arbeit hat. Der aktuelle Status
ist in diesem Falle nicht transparent.
Gemeinsame Datenbank: Die Ablage der Formulare erfolgt auf einer gemeinsame Datenbank.
Bei jedem Zugriff auf die Datenbank wird ein lokales Replikat (Kopie) erstellt. Dieses System hat
den Nachteil, dass die Datenbank einen Flaschenhals bildet. Ebenso ist der Zugriff auf die
Datenbank für andere Mitarbeiter eingeschränkt. Die Transparenz des Auftragstatus ist in diesem
Falle auch nicht für jeden Mitarbeiter gegeben.
Client-Server-Datenbank: Bei diesem System überwachen mehrere Server die Ausführung eines
Workflows und verwalten die Dokumente und Aktivitäten. In diesem System ist die Transparenz
des Auftragstatus am grössten.
Vielfach werden WfMS mit einer reinen Groupware verglichen. Dieser Vergleich ist aber in keiner Art
und Weise korrekt. Groupware beinhaltet einen unstrukturierten Ablauf, respektive es finden keine
kontrollierten Arbeitsübergaben statt. Ein Groupeware System kann vereinfacht als Fileserver
betrachtet werden, bei dem jeder Entwickler Zugriff auf seine eigenen Daten hat sowie auf Daten von
anderen Entwicklern, sofern diese freigegeben wurden. Dieser kurze Vergleich mit Groupware sollte
veranschaulichen, dass WfMS eine gewisse Strukturierung voraussetzen, was bei Groupware nicht
der Fall ist. Abbildung 6 zeigt, dass bei Groupeware die Kooperation am grössten ist. Bei WfMS steht
allerdings die Koordination im Vordergrund.
Das WfMS, welches in der vorliegenden Arbeit verwendet wird ist Lotus Notes. Lotus Notes wird als
Produktions-WfMS verstanden. Wird der Kontroll- und Informationsfluss betrachtet, wird es bei den
Client-Server Datenbanken eingestuft.
- Seite 20 -
Grundlagen
2.3. Java auf mobilen Geräten
In den letzten Jahren wuchs der Verkauf von Handys und PDA stetig. Mit einer Abnahme dieses
Trends ist nicht zu rechnen (siehe Abbildung 99). Die Nachfrage nach individuelleren Programmen für
Handys und PDAs ist steigend. Einerseits versuchen grosse Hersteller, Kunden mittels integrierten
Spielen zum Kauf ihrer Geräte zu bewegen, andererseits existiert die Forderung der Industrie nach
programmierbaren Geräten. Aus diesem Grunde ist verständlich, dass Softwarehersteller wie SUN
bestrebt sind, eine Plattform zu errichten, die das flexible Programmieren von Handys und PDAs
möglich macht. Im Falle von SUN ist es nahe liegend, dass eine solche Lösung auf Java basiert.
2.3.1. Java
Wird der Begriff Java verwendet, taucht die Assoziation mit der Programmiersprache Java auf. Dies ist
allerdings nur bedingt korrekt. Wird von Java gesprochen, muss zwischen der Programmiersprache
Java, der Java Virtual Machine (VM) und der Java-Plattform unterschieden werden.
Die Programmiersprache Java ist eine objektorientierte Sprache, welche eine C-ähnliche Syntax
aufweist. Sie ist eine mächtige Programmiersprache ohne viel Komplexität [Flanagan 2000, Seite 3].
Java ist unter Programmierern sehr populär geworden, davon ausgegangen wird, dass mit wenig
Aufwand viel programmiert werden kann − was zum Teil auch stimmt. Die Arbeit mit Java ist auf alle
Fälle angenehmer als das Programmieren von schwierigeren und wenig mächtigeren Sprachen wie C
oder PERL.
Die Programmiersprache Java gilt als plattformunabhängig. Dies bedeutet, dass eine Java Applikation
auf einem Macintosh, einer SUN oder auf einem PC verwendet werden kann. Diese Eigenschaft bringt
uns zum Java-Interpreter, respektive zu der so genannten Java Virtual Machine. Damit die Java
Programme auf den verschiedenen Systemen auch verwendet werden können, müssen natürlich die
systemabhängigen VMs vorhanden sein. Die Firma SUN [Sun] bietet VMs für das eigene System
Solaris und für Microsoft Windows (95/98/NT) an. Sun hat drei Java-Plattformen auf dem Markt:
-
J2EE: Java 2 Enterprise Edition
J2SE: Java 2 Standard Edition
J2ME: Java 2 Micro Edition
Die «Enterprise Edition» eignet sich für die Entwicklung von Unternehmensapplikationen. Die
«Standard Edition» wird auf den PCs und auf Workstations verwendet. Zu Beginn des Jahres 2001
stellte SUN ihre Java 2 Micro Edition (J2ME) vor. Diese «Micro Edition» kann für eingebettete
Systeme wie PDAs und Mobiltelefone verwendet werden. Die Abbildung 9 zeigt eine Übersicht der
Anwendungsmöglichkeiten und Endgeräte der drei verschiedenen Java Plattformen.
Empfehlungen und Spezifikationen zur Programmiersprache Java werden durch den «Java
Community Process» (JCP) erstellt. Der JCP bietet auch so genannte «Java Specification Requests»
(JSR) an. Diese Dokumente enthalten die Spezifikationen zu den entsprechenden Themen. Die JSR,
die in dieser Arbeit verwendet wurden, befinden sich auf der beiliegenden CD oder können im Internet
unter [Java Spec] bezogen werden.
- Seite 21 -
Grundlagen
Abbildung 9: Verschiedene Sparten der Java-Pakete
Quelle: [J2ME]
2.3.2. Geräteeigenschaften und Konfiguration der VM
Die Java 2 Micro Edition (J2ME) unterteilt die Geräte nach ihrer Leistungsfähigkeit (Prozessor),
Anzeigeeigenschaften (Displaygrösse, Farben) sowie Eingabemöglichkeiten (Stift, Tastatur) in
«Connected Limited Device Configuration» (CLDC) und «Connected Device Configuration» (CDC).
Typische CLDC-Plattformen sind Mobiltelefone und PDAs, die etwa 512 kB Speicher aufweisen,
batteriebetrieben werden und eine maximale Übertragungsrate von 9600 Bps aufweisen. Die CDCPlattform deckt Geräte ab, die zwischen den CLDC- und Desktop-Systemen liegen. In dieser Sparte
befinden sich Bildtelefone, Spielkonsolen und «High-End»-PDAs. Die CDC weisen eine höhere
Datenübertragungsrate als CLDC Geräte auf.
Beide Konfigurationen erweitern die Java «Virtual Machine» (VM). Demnach verfügt ein PDA über
eine andere VM als ein Bildtelefon. Da die Prozessoren von PDAs oft keine Fliesskommazahlen
kennen, fehlen die Datentypen float und double in der PDA-VM. Die CLDC-Spezifikation definiert die
Funktionen, die eine VM aufweisen muss. Es ist in diesem Falle dem Hersteller freigestellt, ob er eine
bereits bestehende VM verwendet oder ob er eine eigene entwickelt. Aus diesem Grunde sind auch
verschieden CLDC-VM erhältlich. Die folgende Auflistung zeigt die gängigsten VMs:
-
Kilobyte Virtual Machine (KVM) von SUN
Waba Virtual Machine von Wabasoft
Jbed Virtual Machine von Esmertec AG (CH)
J9 von IBM
Die vorliegende Arbeit beruht, wenn nicht auf eine andere VM verwiesen wird, auf der Virtual Machine
von SUN. Der Grund, weshalb die vorliegende Arbeit mit dieser VM durchgeführt wurde, findet sich
nicht direkt bei der VM, sondern eher bei der Entwicklungsumgebung (IDE), die von den Herstellern
zur Verfügung gestellt wird. Die Entwicklungsumgebung von SUN überzeugte durch Einfach- und
Übersichtlichkeit. Siehe hierzu auch Kapitel 3.4.1.
- Seite 22 -
Grundlagen
2.3.3. Profile
Profile erweitern die Konfiguration der VM. Es werden zusätzliche, gerätespezifische Klassen zur
Verfügung gestellt. Die Abbildung 10 zeigt den schematischen Aufbau der Java 2 Micro Edition.
Abbildung 10: Aufbau der Java 2 Micro Edition
Quelle: [Giguère 2000, Seite 23]
In der Abbildung 10 wird das PDA Profile noch vom Mobile Information Device Profil (MIDP) getrennt.
Der neuste Stand der Entwicklung ist, dass die beiden Profile zusammengelegt wurden und eigentlich
kaum mehr eine gerätespezifische Unterscheidung machen. Vereinzelte Applikationen funktionieren
grundsätzlich nur auf MIDP (vor allem Mobiltelefone) und nicht auf PDAs.
Das PDAP und das Mobile Information Device Profile (MIDP) sind nahezu identisch - für die
vorliegende Arbeit wurde allerdings das MIDP verwendet. Die restlichen Profile benötigen eine CDCKonfiguration, welche in dieser Arbeit nicht verwendet und auf die auch nicht weiter eingegangen wird.
Das MIDP erweitert das CLDC um einige wichtige Klassen. Der Schwerpunkt in diesem Profil (siehe
Abbildung 11) ist die grafische Darstellung, die Netzwerkanbindungen und Speichermöglichkeiten,
welche im Kapitel 3.4 noch näher erklärt werden.
Abbildung 11: Das Mobile Information Device Profile
Quelle: [Topley 2002, Seite 45]
- Seite 23 -
Grundlagen
In Abbildung 11 ist der Inhalt des MIDP (siehe folgendes Kapitel) grafisch dargestellt. Das MIDP
beinhaltet noch so genannten «OEM» Code, dieser integriert Funktionen wie Installieren, Entfernen
und Managen von MIDlets. Um das MIDP zu nutzen, müssen gewisse Soft- und Hardwarekriterien
erfüllt werden. Diese Kriterien sind in den Tabellen 1 und 2 festgehalten.
Hardware
Speicher
Display
Eigenschaften
mindestens 128 kByte Ram
mindestens 96 Pixel breit und 54 Pixel hoch
Bei einem PDA ist der Bildschirm 160*160 Pixel gross
Tabelle 1: Hardwareeigenschaften
Quelle: [Topley 2002]
Hardware
Display
Tastatur
Netzwerk
Speicher
Eigenschaften
Es muss möglich sein, Zugriff auf den Bildschirm zu
bekommen, als wäre der Bildschirm eine
Bitmapgrafik
Die Software muss Zugang zu den Eingaben des Users
haben, damit das Programm auf bestimmte Eingaben
reagieren kann
In einigen Fällen ist eine Netzwerkverbindung nötig.
Dies verlangt einen Zugriff auf die Netzwerksockets.
Die Software muss Zugriff auf einen Speicherbereich
haben, damit sie ihre Zustände speichern kann,
falls das Gerät unabsichtlich ausgeschaltet wird.
Tabelle 2: Anforderungen an die Software
Quelle:[Topley 2002]
2.3.4. MIDlets
Java Programme, die auf einem MIDP-Gerät ausgeführt werden, werden MIDlets genannt. MIDlets
haben nicht einen klar definierten Startpunkt, so wie normale Java Programme eine «main» Methode
haben. MIDlets sind wie Java Applets und werden in einer MIDlet-Umgebung (so genannte MIDlet
Suite) verwaltet. Ein MIDlet wird von der abstrakten Klasse javax.microedition.MIDlet.MIDlet
abgeleitet. Auf dem PDA wird nicht ein isoliertes MIDlet gestartet, sondern die MIDlet-Suite. In dieser
Umgebung können dann die verschiedenen MIDlets ausgewählt und gestartet werden. Alle MIDlets in
einer Suite verwenden denselben Speicherbereich. Es ist nicht möglich auf den Speicherbereich einer
anderen Suite zuzugreifen.
Ein MIDlet wird gemäss dem folgenden Skeleton3 aufgebaut:
3
Skeleton ist in diesem Falle ein «Codegerüst»
- Seite 24 -
Grundlagen
Abbildung 12: MIDP Skeleton
Aus dem Code von Abbildung 12 ist zu entnehmen, dass sich ein MIDlet in drei verschiedenen
«Zuständen» befinden kann:
-
startApp
pauseApp
destroyApp
Wenn ein MIDlet gestartet wird, so befindet sich dieses im Zustand «Paused». Das MIDlet wird durch
den User oder durch eine Aufforderung eines anderen MIDlets aktiviert. Taucht bei der Ausführung
des Konstruktors ein Fehler (Exception) auf, so wird das MIDlet beendet. Den Lebenszyklus eines
MIDlets zeigt die Abbildung 13.
Abbildung 13: Lebenszyklus eines MIDlet
Quelle: [Topley 2002, Seite 57]
Da ein MIDP Gerät über knappe Ressourcen verfügt, sollte damit sparsam umgegangen werden.
Nicht mehr verwendete Referenzen sollen unverzüglich gelöscht und freigegeben werden. Dies soll
vor allem beim Beenden eines MIDlets beachtet werden. Ebenso soll vermieden werden, dass das
MIDlet während eines Speichervorganges beendet wird. Das Codebeispiel aus Abbildung 14
verhindert einen Abbruch während eines Speichervorganges.
- Seite 25 -
Grundlagen
Abbildung 14: Korrektes Beenden eines MIDlets
In der «destroyApp()» Methode werden alle Referenzen auf Ressourcen gelöscht, im Hintergrund
laufende Threads beendet und alle aktiven Timers gestoppt. Soll das MIDlet auf diese Art beendet
werden, so soll der Methode «destroyApp()» der Parameter «true» übergeben werden. In diesem Fall
hat das MIDlet keine Chance, diesen Abbruch zu stoppen. Wird aber diese Methode mit dem
Parameter «false» aufgerufen, so kann das MIDlet in Form einer «MIDletStateChangeException»
anzeigen, dass noch etwas abgearbeitet werden muss. Die «try-catch» Klausel aus Abbildung 14 zeigt
dies. Ist das MIDlet noch beschäftigt, so wird mit dem Aufruf der Methode «destroyApp(false)» eine
Exception ausgelöst und es wird automatisch die «catch» Klausel ausgeführt und die
«notifyDestroyed()» Methode wird übersprungen. Somit ist verhindert worden, dass das MIDlet in
einem falschen Moment beendet wird. Löst die «destroyApp(false)» Methode aber keine Exception
aus, so wird das MIDlet beendet, als wäre die Methode mit dem Parameter «true» aufgerufen worden.
2.3.5. HelloWorld
Das bekannte «HelloWorld» Programm darf hier natürlich nicht fehlen. Die Abbildung 15 zeigt den
Code dieses einfachen Beispielprogramms. Wie dem Code zu entnehmen ist, wurde das
«HelloWorld» in einem MIDlet realisiert. Dies ist nicht zwingend notwendig, es kann auch eine
einfache J2ME Klasse mit einer «main» Methode geschrieben werden, in der sich ein
System.out.println("Hello World");
befindet. Ein solches Programm zeigt die Meldung auf dem Bildschirm an und beendet sich selber
umgehend. Die gewünschte Ausgabe ist somit für den Anwender nicht sichtbar.
- Seite 26 -
Grundlagen
Abbildung 15: HelloWorld MIDlet
Die Ausgabe auf dem Palm OS Emulator (POSE) sähe gemäss Abbildung 16 aus.
Abbildung 16: Ausgabe des HelloWorld MIDlet
- Seite 27 -
Grundlagen
2.4. Internet und «mobile» Kommunikation
Dieses Kapitel behandelt die relevanten Grundlagen, die das Internet und/oder die Kommunikation mit
dem Internet betreffen. Des Weiteren werden die Grundlagen von Servlets erklärt, da in diesem
Projekt die Server-Seite mit einem Servlet umgesetzt wurde.
Zuerst wird allerdings erklärt, wie eine so genannte Webseite auf einen Computer (Client) gelangt:
Ein Computer möchte eine Verbindung zu der Webseite (www.ebund.ch) aufbauen. Der Webbrowser
schickt eine Anfrage an den gewünschten Server und wartet auf eine entsprechende Antwort. Nach
der Antwort wird die Verbindung zum Server unterbrochen. Das Protokoll, das für diese Verbindung
verwendet wird, nennt sich Hyper Text Transfer Protocoll (HTTP) und wird im folgenden Unterkapitel
erklärt. Das folgende Beispiel erklärt den Ablauf, wenn ein User im Webbrowser die Uniform Resource
Locator4 (URL) http://www.ebund.ch/index.html eingibt.
1. Der Browser fragt den Domain Name Server5 (DNS) nach der IP von www.ebund.ch
2. Der DNS gibt den Wert 195.65.4.246 zurück
3. Der Webbrowser baut nun eine Verbindung zu der IP 195.65.4.246 auf. Da die Verbindung mit
TCP erfolgt, wird der Port 80 verwendet.
4. Der Browser sendet nun den GET-Befehl (Siehe Abbildung X) «GET index.html»
5. Der Server www.ebund.ch sendet die Datei «index.html» an den Browser
6. Der Browser zeigt den Inhalt der Datei an
7. Der Browser zeigt die zur Seite gehörenden Bilder an [Tannenbaum 2000, Seite 722]
2.4.1. Hyper Text Transfer Protocoll (HTTP)
Das HTTP ist das Standardprotokoll, das im Internet verwendet wird, es ist in der RFC 822 genauer
definiert. Bei der Entwicklung wurde grossen Wert darauf gelegt, dass das Protokoll allgemein
verwendet werden kann. Es wurde vor allem darauf geachtet, dass eine objektorientierte Nutzung
möglich ist. Aus diesem Grund besteht der HTTP-Befehl aus drei Teilen. Zuerst wird Methodennamen
(GET) angegeben, dann folgt ein Parameter (index.html) und zum Schluss wird noch das Protokoll mit
der entsprechenden Version angegeben. Zum Beispiel:
GET index.html HTTP /1.1
Die Abbildung X zeigt eine Übersicht der verschiedenen HTTP-Methoden. Die Abbildung 17 zeigt den
Ablauf einer HTTP-Transaktion.
Abbildung 17: HTTP-Request und Response
Wie die Abbildung 17 zeigt kann ein http-Befehl in eine Anfrage und eine Antwort unterteilt werden. In
folgenden Abschnitt wird der http-Request betrachtet
4
Eine URL besteht aus drei Teilen:
1. Teil: Art des Protokolls (z.B. http)
2. Teil: Name des Servers -> Domainname (z.B. www.ebund.ch)
3. Teil: Name der Datei respektive Dokumentpfad (z.B. index.html)
5
Ein Domain Name Server ruft einen Resolver auf, der die IP ermittelt und retourniert [Tannenbaum 2000, Seite 659]
- Seite 28 -
Grundlagen
Der Inhalt des Request Befehls beinhaltet:
- Dokumentenanforderung : «Bitte schicke mir das Dokument /index.html»
- Ebenso werden Informationen zu dem Client mitgeschickt. Zum Beispiel wird dem Server
gesagt, dass der Client ein Microsoft Internet Explorer 5.0 ist und dass die gewünschte
Sprache deutsch ist.
Ein Request beinhaltet immer so genannte «Header-Informationen», dies sind Informationen zu den
Clienteigenschaften und können gemäss der Tabelle 3 aussehen:
Header
Accept: image/png, image/gif, *.*
Accept-Language: de
User-Agent: Morzilla/4.0
Host: www.amazon.com
If-Modified-Since: Datum Zeit
Eigenschaften
Bevorzugte Dokumentenformate. Angabe mittels MIMETypes (Multipurpose-Internet-Mail-Extension-Standrd)
Bevorzugte Sprache
Browser-Kennung (hier Internet Explorer)
Name des Hosts, an den der Client wendet
Dokument nur liefern, wenn es sich seit der
angegeben Zeit verändert hat.
Tabelle 3: Headerinformationen eines Requests
Die GET-Methode ist die gängigste Methode. Diese Methode wird hauptsächlich für statische
Webseiten verwendet. Im folgenden Kapitel werden die Grundlagen der Servlets beschrieben und
diese verwenden in der Regel die POST Methode. Diese Methode unterscheidet sich im Wesentlichen
darin, dass die Resultate einer GET-Methode im Cache (Zwischenspeicher) gespeichert werden und
bei einem erneuten Aufrufen dieser Methode werden die Daten aus dem Zwischenspeicher bezogen.
Bei der POST-Methode wird davon ausgegangen, dass es sich um dynamische Daten handelt, daher
werden keine Daten im Zwischenspeicher abgelegt. Diese Methode wird zum Beispiel verwendet,
wenn dem Server Daten übergeben werden möchte. Im folgenden Kapitel werden Servlets
beschrieben und diese nutzen eben diese POST-Methode.
Der Inhalt eines Responses ist:
- Angefordertes Dokument: «Alles hat geklappt, und zusätzlich schicke ich noch das
angeforderte Dokument».
- Informationen über den Server: Es wird zum Beispiel angegeben, dass es sich um einen
Apache Server handelt.
Ein Request kann natürlich auch ein Dokument anfordern, das auf dem Server gar nicht vorhanden ist,
aus diesem Grund muss ein Response auch die entsprechenden Meldungen zurückgeben können.
Die erste Zeile eines HTTP-Responses kann folgendermassen aussehen:
HTTP/1.1 200 OK
Der erste Teil (HTTP/1.1) gibt das Protokoll an, der zweite Teil gibt einen so genannten Statuscode6
(Siehe hierzu die Tabelle 4) und der letzte Teil gibt eine kurze Erklärung an.
6
Die Tabelle 3.1 in [Callaway 1999, Seite 44] zeigt eine generelle Übersicht der Statusmeldungen.
- Seite 29 -
Grundlagen
Code
200 OK
301 Moved Permanently
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
500 Internal Server Error
Erklärung
OK, die Response enthält das angeforderte Dokument
Angeforderte Ressource ist unter neuer URL zu erreichen.
Die URL wird mit dem Location-Header übergeben.
Syntaxfehler im Request
Die Ressource ist passwortgeschützt. Der Client wird
aufgefordert,
sich mit Benutzername und Kennwort zu autorisieren.
Zugriff verweigert, ohne Möglichkeit zur Autorisation.
Das angeforderte Dokument existiert nicht.
Ein Fehler des Servers macht die Bearbeitung der
Anfrage unmöglich.
Tabelle 4: HTTP Response
Ein Webserver erfüllt demnach die folgenden Aufgaben:
-
Horcht den Port 80 nach HTTP-Responses ab.
Schickt Dokumente an einen Client.
Schickt Angaben über sich.
Kann ein Programm auf dem Server ausführen, das ein Dokument erzeugt.
- Seite 30 -
Grundlagen
2.4.2. Servlets
Normalerweise sind Webseiten statische Dateien die von einem Client bezogen werden können.
Statische Webseiten lassen nur eine «Einwegkommunikation» zu. Der Client kann höchstens
entscheiden, welche Seiten er anfordern möchte. Dieses «Ein-Wegkommunikation» kann unter
anderem7 mit so genannten Servlets in eine «Zwei-Wegkommunikation» erweitert werden.
Servlets sind spezielle Java-Programme, die HTML-Dateien dynamisch generieren. Das heisst nach
einem HTTP-Response wird eine HTML-Datei generiert und dem Client zurückgeschickt. Diese Datei
ist allerdings nicht physikalisch in einem File abgespeichert, sondern wird dynamisch gehalten. Dies
bedeutet, dass bei einer erneuten gleichen Anfrage die Webseite neu generiert werden muss. Da die
Webseiten bei jedem Aufruf vom Server neu generiert werden, spricht man in einem solchen Fall von
«serverseitiger» Ausführung. Die Servlets werden in Java programmiert, kompiliert und der Byte-Code
wird auf dem Server installiert.
Servlets haben folgende Eigenschaften und Vorteile [Callaway 1999, Seite 70]:
- Programm ist bereits kompiliert:
Die Servlets werden programmiert und in Byte-Code kompiliert. Das kompilierte
Programm wird auf dem Server installiert. So sind Servlets deutlich schneller als zum
Beispiel Java Server Pages (JSP).
- Stabil
Da Servlets bereits kompiliert sind, sind gewisse Programmfehler wie zum Beispiel das
illegale «Casten» von Objekten ausgeschlossen.
- Cross-Plattform
Da Servlets in Java geschrieben sind, können sie auf jeder Plattform verwendet werden,
die Java-Programme akzeptiert. «write once, run anywhere»
- Cross-Server
Alle gängigen Serverhersteller unterstützen die Anwendung von Java-Programmen und
somit auch von Servlets
- «Langlebigkeit»
Servlets sind langlebige Objekte, das heisst sie bleiben solange bestehen, bis sie explizit
«zerstört» werden.
- Servlets können dynamisch geladen werden
Servlets werden nur geladen, wenn sie auch verwendet werden. Dieses dynamische
Laden bewirkt, dass Servlets nur Server-Ressourcen braucht, wenn das Servlet
verwendet wird.
- Erweiterbar
Java-Programme sind mit den verschiedenen Programm-Bibliotheken erweiterbar, was
auch für Servlets gilt.
- Protokollunabhängig
Servlets unterstützen File Transfering Protocol (FTP), Telnet Sessions, POP3 E-Mail
Funktionen, Simple Mail Transfer Protocol (SMTP) sowie weitere Protokolle
Die Programmierung von Servlets ist identisch zu normalen Java-Programmen. Servlets verwenden
zusätzlich zwei neue Klassen. Nämlich die «GenericServlet»- oder die «HttpServlet»-Klasse. Wird ein
Servlet programmiert, so wird immer die Service-Methode (siehe Abbildung 18) des
«GenericServlets» oder des «HttpServlets» mit den gewünschten Funktionen überschrieben. Servlets
haben noch zwei weitere Methoden, die verwendet werden. Die «Init»- und die «Destroy»-Methode.
Die Init-Methode wird verwendet um das Servlet zu initialisieren und wird beim Laden des Servlets
automatisch ausgeführt. Die Destroy-Methode löscht das Servlet-Objekt (vergleiche oberen Abschnitt
beim Punkt «Langlebigkeit»). Diese beiden Methoden müssen nicht zwingend implementiert werden,
es liegt aber auf der Hand, das eine Initialisierung und ein explizites Löschen von Objekten zu einem
sauberen Programmierstil gehören.
7
Folgende Techniken ermöglichen auch eine «Zwei-Wegkommunikation»:
Common Gateway Interface (CGI)
Active Server Pages (ASP), Java Server Pages (JSP)
- Seite 31 -
Grundlagen
Abbildung 18: Servlet Gerüst
Quelle: [Callaway 1999, Seite 80]
In Abbildung 18 kann an Stelle der Service-Methode auch eine «doPost»- oder «doGet»-Methode
verwendet werden. Die «doPost»-Methode behandelt so genannte POST-Requests und die «doGet»Methode die GET-Requests. (Siehe Kapitel 2.4.1) Um ein «Hello-World»-Servlet zu erstellen, muss
die Service-Methode aus Abbildung 18 mit derjenigen aus Abbildung 19 ausgewechselt werden.
Abbildung 19: Service Methode
Quelle: [Callaway 1999, Seite 84]
Die Service-Methode aus Abbildung 19 schreibt HTML-Tags in einen PrintWriter (siehe hierzu
[Flanagan 2000, Seite 355]). Das so generierte HTML-File wird dem Client geschickt und in seinem
Webbrowser angezeigt.
- Seite 32 -
Grundlagen
2.5. Notationen
Die in dieser Dokumentation verwendeten Notationen beruhen auf dem Unified Modelling Language
(UML) Standard der Version 1.4. Der aktuellste Standard ist UML Version 2.0, welcher im Sommer
2001 veröffentlicht wurde. Das Problem ist allerdings, dass sich die gängigste Literatur immer noch
auf die Version 1.4. oder zum Teil sogar noch auf die Version 1.3. bezieht. UML ist eine Sprache und
eine Notation zur Modellierung. Die UML wurde von der Object Management Group (OMG) zum
Standard erklärt. Federführend in deren Entwicklung waren vor allem Grady Booch, Ivar Jacobson und
Jim Rumbaugh [Booch 1998 und 1999].
Bevor die Notation etwas genauer betrachtet wird, sollte ein wenig auf die Geschichte der UML und
deren Gründerkonsortium eingegangen werden.
2.5.1. Die Object Management Group (OMG)
Die OMG wurde 1989 mit dem Ziel gegründet, die objektorientierte Technik und die verteilte
Verarbeitung zu fördern und zu verbreiten. Gründungsmitglieder waren 3COM, American Airlines,
CANON, Data General, Hewlett Packard, Philips Telecommunications, Sun Microsystems und Unisys.
Inzwischen zählt die OMG mehr als 700 Mitglieder. Populärstes Nichtmitglied ist in diesem Falle wohl
einmal mehr Microsoft. Zum jetztigen Zeitpunkt ist Microsoft immerhin Passivmitglied.
Die OMG wurde vor allem bekannt durch ihre Standardisierung von Commen Object Request Broker
Architecture (CORBA), der UML und anderen Spezifikationen für Analyse- und Designvorgänge im
Bereich der Softwareentwicklung. Die Spezifikationen der OMG werden heute weltweit zur
Entwicklung von verteilten Applikationen verwendet.
2.5.2. Unified Modelling Language (UML)
UML eignet sich für die Beschreibung von Softwarelösungen. Sie kann sehr vielseitig verwendet
werden: Es können Datenbankanwendungen, Echtzeitsysteme, verteilte Systeme, Workflows usw.
beschrieben werden. Das Ziel der OMG ist, mit UML eine konsistente Sprache zu entwickeln, die sich
zur Beschreibung einer Vielzahl von Problemen eignet. Mit UML sollen Projekte analysiert und
implementiert werden können − und zwar unabhängig von deren Komplexität. UML ist komplett
unabhängig von der Programmiersprache, die meisten Spezifikationen von Programmiersprachen
lassen sich ebenfalls mit UML darstellen.
UML ist sehr umfangreich und kann in verschiedene Diagramme unterteilt werden. Diese Diagramme
werden aufgrund der gewünschten Betrachtungsweise des Problemes unterschieden: UMLDiagramme können in drei Gruppen unterteilt werden: In statische, verhaltensbeschreibende und
implementationsspezifische Diagramme.
Zu den statischen Diagrammen gehören.
Anwendungsdiagramm (engl. Use Case Diagram):
Mit Hilfe der Use Cases sollen die Möglichkeiten eines Systemes visualisiert werden. Diese
Visualisierung ist sehr hilfreich, um mit Kunden über das entstehende Produkt zu diskutieren und
mögliche Änderungen der Kunden frühzeitig einzubringen. Dank einer verständlichen Visualisierung
sind die Zeichnungen auch für «Nicht-Informatiker» verständlich. Die Anwendungsfallbeschreibung ist
nichts anderes als die «Use Cases» in Worte zu fassen, um diesen eine gewisse Struktur zu geben.
Diese Beschriebung wird meist in einer Tabelle dargestellt. Siehe hierzu die Tabelle 5.
- Seite 33 -
Grundlagen
Rechnung bezahlen
Akteur1
Abbildung 20: Anwendungsfalldiagramm allgemein
In der Tabelle 5 ist aufgelistet, welche Akteure betroffen sind, was verwendet wird, wie der Ablauf des
Prozesses und wie der Endzustand aussieht, welche Abweichungen vorkommen sowie eine kurze
Beschreibung des Prozessablaufes. Mit diesem Schritt kann vor allem der Übergang zu den
Aktivitätsdiagrammen vereinfacht werden. Ein Anwendungsfall wird, wie Abbildung 20 zeigt, als ovaler
Kreis dargestellt. Das Anwendungsfalldiagramm zeigt aber auch gewisse Beziehungen zwischen
verschiedenen «Use Cases». Es wird zwischen so genannten «include» und «extende» Beziehungen
unterschieden. Die «include» Beziehung soll zeigen, dass es sich beim «Use Case» − auf den gezeigt
wird − um einen «Use Case» handelt, der auch von anderen «Use Cases» verwendet wird. Bei der
«extend» Beziehung will gesagt werden, dass der «Use Case», auf den die Pfeilspitze zeigt, den
ursprünglichen «Use Case» erweitert.
Klassendiagramm (engl. Class Diagram):
Sie beschreiben die Struktur von Objekten und deren statische Beziehungen zu anderen Objekten.
Klassendiagramme beinhalten auch Packages, Interfaces und Instanzen. Die Beschreibung eines
Objektes beinhaltet Operationen und Attribute. Klassendiagramme können in Packages verpackt
werden. Eine Klasse wird in diesem Diagramm mit einem Rechteck gezeichnet, welches mit zwei
Linien in drei Teile unterteilt wird. Im oberen Drittel wird der Klassennamen angegeben, in der Mitte
befinden sich die Attribute und im unteren Drittel werden die Operationen der Klasse aufgelistet. Die
Abbildung 21 zeigt ein einfaches Klassendiagramm
Abbildung 21: Klassendiagramm
Quelle: [Oestereich 2001, Seite 260]
Mit den obigen Diagrammen werden die statischen Eigenschaften eines Systemes beschrieben. Die
folgenden Diagrammtypen beschreiben das dynamische Verhalten. Sie werden unter dem Begriff
Verhaltensdiagramme (engl. behavior diagrams) zusammengefasst.
- Seite 34 -
Grundlagen
Aktivitätsdiagramm (engl. Activity Diagram):
Aktivitätsdiagramme zeigen grundsätzlich den Ablauf eines Prozesses auf. Zwischen den Schritten
bestehen meistens Zeitdifferenzen. Es können Wartezeiten auftauchen, ebenso kann die Plattform
wechseln, was zum Beispiel bei Client-Server Applikationen der Fall ist. Mit solchen Diagrammen
kann visualisiert werden, wo die Methoden ausgeführt werden. Wird zum Beispiel eine Methode von
einem Client aus auf dem Server aufgerufen, so kann die Trennung «Client-Server» mit den
sogenannten «Swimlanes» gekennzeichnet werden. Das Diagramm wird durch eine vertikale Linie
getrennt. Dies zeigt, dass zum Beispiel die linke Seite auf dem Client und die rechte Seite auf dem
Server ausgeführt werden. Die Abbildung 22 zeigt ein solches Aktivitätsdiagramm ohne «Swimlanes»,
in Abbildung 39 ist ein Aktivitätsdiagramm mit «Swimlanes» zu sehen.
Abbildung 22: Aktivitätsdiagramm allgemein
Meistens entsprechen die einzelnen Schritte des Aktivitätsdiagrammes einem Anwendungsfall.
Kollaborationsdiagramm (engl. Collaboration Diagram):
Ein Kollaborationsdiagramm ist eine alternative Visualisierung, um Abläufe in einem Programm
darzustellen. Dieses Diagramm zeigt Verbindungen zwischen Objekten und deren Interaktionen. Sie
weisen eine gewisse Ähnlichkeit mit den Sequenzdiagrammen auf. Der Unterschied besteht darin,
dass die Sequenzdiagramme an einen zeitlichen Ablauf gebunden sind. Kollaborationsdiagramme
sind nicht zeitbezogen. Objekte werden als Rechteck dargestellt, Verbindungen zwischen den
Objekten sind mit Pfeilen visualisiert und Meldungen, die zwischen den Objekten verschickt werden,
werden mit einem Text über dem Pfeil vermerkt. Die Abbildung 23 zeigt ein Kollaborationsdiagramm.
Abbildung 23: Kollaborationsdiagramm
- Seite 35 -
Grundlagen
Sequenzdiagramm (engl. Sequence Diagram):
Diese Diagramme zeigen Interaktionen zwischen Objekten in zeitlicher Abhängigkeit. Es ist auch
ersichtlich, wann ein Objekt instanziert wird. Eine Übersicht der aufgerufenen Methoden ist ebenso
gewährleistet. In Sequenzdiagrammen werden Objekte ebenfalls als Rechtecke dargestellt. Eine nach
unten verlaufende gestrichelte Line symbolisiert die Lebenszeit des Objektes. Wird durch Aufrufen
einer Methode ein anderes Objekt benötigt, wird dies durch einen Pfeil mit der Beschreibung des
Methodennamens visualisiert. Die Abbildung 24 zeigt einen einfachen Aufruf eines Objektes.
Hello
Show
show("Text")
Abbildung 24: Sequenzdiagramm allgemein
Sequenzdiagramme haben zwei Dimensionen: Die horizontale Dimension zeigt die beteiligten Objekte
und die vertikale zeigt den Zeitverlauf. Der horizontalen Reihenfolge wird keine Bedeutung
zugesprochen.
Zustandsdiagramm (engl. State Chart Diagram):
Ein Zustandsdiagramm entspricht eigentlich einer «State Event Machine». Das Diagramm beschreibt
das Verhalten eines Objektes oder einer Abhängigkeit. Es zeigt die verschiedenen Zustände eines
Objektes auf, die das Objekt während seiner «Lebenszeit» einnehmen kann. Die Zustandsdiagramme
implementieren im Wesentlichen die State Machine von Mealy8 oder Moore9. Ein Beispiel eines
Zustanddiagramms ist in Abbildung 25 zu sehen.
Abbildung 25: Zustandsdiagramm
8
9
Mealy State Event Machine: Ausgänge sind abhängig vom Zustand und den Eingängen
Moore State Event Machine: Ausgänge sind nur vom Zustand abhängig
- Seite 36 -
Grundlagen
Die letzte der drei UML Diagrammklassen sind die Implementationsdiagramme (engl. Implementation
Diagrams). Diese zeigen Aspekte der Implementation. Implementationsdiagramme unterteilen sich in
Komponenten- und Einsatzdiagramme.
Komponentendiagramm (engl. Component Diagram):
Dieses Diagramm zeigt Komponenten mit ihren Abhängigkeiten auf. Es werden auch statische
Beziehungen dargestellt. Eine Komponente beinhaltet meist eine komplexe Struktur. Ähnlich wie eine
Klasse können auch Komponenten instanziert werden. Mit dem Unterschied, dass sich im Inneren
einer Komponenten oft eine Mehrzahl von Klassen befindet. Komponenten sollten nach Möglichkeit
austauschbar sein. Komponenten werden gemäss Abbildung 26 dargestellt. Der gestrichelte Pfeil
signalisiert die Abhängigkeitsbeziehung.
Kompnente 1
Schnittstelle1
Komponente 2
Abbildung 26: Komponentendiagramm allgemein
Das Innenleben von Komponenten wird meist in drei Services unterteilt. Zum einen sind da die so
genannten Factory Services, welche zum Instanzieren von Klassen verwendet werden und die
Observer Services, die für Ereignisbenachrichtigungen auf einem abstrakten Niveau verantwortlich
sind [Oestereich 2001]. Zu guter Letzt ist noch der Object Service zu erwähnen, welcher fachliche
Operationen zur Verfügung stellt. Unter fachlichen Operationen verstehen sich zum Beispiel so
genannte «get-» und «set-Methoden».
Einsatzdiagramm (engl. Deployment Diagram):
Diese Diagramme beschreiben wo sich die verschiedene Prozesse, Komponenten und Objekte
physikalisch befinden, respektive wo sie laufen. Ein einfaches Beispiel eines Einsatzdiagrammes zeigt
die Abbildung 27.
Abbildung 27: Einsatzdiagramm allgemein
Im Diagramm werden Knoten und Kommunikationsverbindungen dargestellt. Als Knoten wird in
diesem Falle ein physikalisch vorhandener Rechner betrachtet.
- Seite 37 -
Grundlagen
2.5.3. Beispiel für die «Unified Modelling Language» Beispiel
Um eine Übersicht der gängigen Diagramme und die «Entwicklung» eines Programmes mit UML
aufzuzeigen, wird das «HelloWorld»-Programm mit UML «entwickelt». Das Beispiel beinhaltet ein
Anwendungsfalldiagramm, deren Beschreibungen, ein Sequenzdiagramm und ein Klassendiagramm.
Das Anwendungsfalldiagramm in Abbildung 28 sieht in diesem Beispiel relativ einfach aus: Es ist nur
ein Akteur beteiligt, welcher die Applikation startet. Die Aktion, die ausgeführt werden soll, ist die
Ausgabe des Textes «Hello World».
"Hello World" auf den
Bildschirm schreiben
Anwender
Abbildung 28: Anwendungsfalldiagramm für HelloWorld
Normalerweise wird zu den Anwendungsfalldiagrammen noch eine Anwendungsfallbeschreibung in
einer Tabellenform erstellt, diese würde hier wie gemäss der Tabelle 5 aussehen.
Name:
Akteur
Beschreibung
Verwendet
Vorbedingung
Ablauf
Endzustand
HelloWorld auf den Bildschirm schreiben
Anwender
Der Anwender startet das Programm.
Eine Javaumgebung muss installiert sein.
1. Der Anwender startet das Programm
Auf dem Bildschirm erscheint ein Fenster mit dem Text
"HelloWorld!"
Variationen
Bemerkungen
Tabelle 5: Anwendungsfallbeschreibung HelloWorld
Da dieses Beispiel relativ einfach und überschaubar ist, kann auf Einträge wie «Bemerkungen» und
«Variationen» verzichtet werden. Bei grösseren und komplexeren Aufgaben sind diese Einträge aber
hilfreich und haben eine ergänzende und erklärende Wirkung. Das Klassendiagramm ist in der
Abbildung 29 zu sehen.
- Seite 38 -
Grundlagen
java.awt.Frame
+add(Position:java.awt.BorderLayout, Object:java.awt.Label):void
+setSize(Breite:int, Hoehe:int):void
+show():void
HelloWorld
java.awt.Label
+main(argv[]:String *):void
Fenster
:HelloWorld
saghello
:awt.Label
Abbildung 29: Klassendiagramm von HelloWorld
Abbildung 30 ist das Sequenzdiagramm. Sequenzdiagramme zeigen die zeitlichen Abläufe einer
Applikation, respektive eines Teiles einer Applikation.
:HelloWorld
main(argv[]:String *):void()
HelloWorld()
Fenster
awt.Label(Ausgabetext:String, Position: awt.Label)
sagHallo
awt.Frame::add(Position:java.awt.BorderLayout, Object:awt.Label):void
awt.Frame::setSize(Breite:int, Hoehe:int):void
awt.Frame::show():void
Abbildung 30: Sequenzdiagramm von HelloWorl
- Seite 39 -
Entwicklung
3. Entwicklung
Wichtige Teile dieses Kapitels sind die Analyse des bestehenden WfMS der Ascom Informatik und die
Analyse der zu erstellenden Software. Im ersten Teil dieses Kapitels wird das bestehende und bereits
modellierte WfMS der Ascom untersucht. Im zweiten Teil wird auf die verschiedenen Anwendungsfälle
und deren Beschreibung eingegangen. Ebenso wird in diesem Teil auf die Aktivitätsdiagramme
eingegangen. Die ersten zwei Teile können als Analyse der Aufgabe betrachtet werden. Das dritte
Unterkapitel beschäftigt sich mit dem Design des Programms. Beim Design wird der Schwerpunkt auf
die Systemarchitektur und die Sequenzdiagramme gelegt. Die Klassendiagramme runden diesen Teil
ab. Im letzten Unterkapitel wird auf die Implementation eingegangen. Hier werden die Client- und die
Serverseite etwas genauer betrachtet. Ebenso finden sich hier Informationen über die
Entwicklungsumgebungen und Simulationswerkzeuge.
Softwareentwicklung bedingt viel Schreib- und Papierarbeit. Eine saubere Analyse und ein sauberes
Design des Projektes ersparen eine Menge Programmieraufwand, was sich schliesslich auch im
finanziellen Bereich positiv auswirkt. Mit einer übersichtlichen Analyse werden Probleme oft schon in
einem frühen Stadium entdeckt. Schwierigkeiten können rechtzeitig mit dem Kunden besprochen
werden, ebenso kann der Kunde flexibler Wünsche während der Analyse einbringen. Ohne eine
genaue Analyse könnten solche Wünsche erst am Schluss des Projektes eingebracht werden. Die
Umsetzung von Änderungen am Ende des Projektes ist jedoch enorm teuer. Ebenso können
konzeptionelle Fehler, die erst am Ende eines Projektes erkannt werden, und welche z.T. eine
«Nichtrealisierung» des Projektes bedeuten, Firmen in eine finanzielle Schieflage bringen. Genau
solche Probleme können mit einer sauberen Analyse und mit einem sorgfältigen Design umgangen
werden. Mit der Folge, dass das Produkt in der Regel kostengünstiger erstellt wurde und erst noch
stärker dem Kundenwunsch entspricht, da er in die Problemanalyse einbezogen wurde.
3.1. Analyse des Ascom Workflow-Management-Systems (WfMS)
Bevor auf den zu erstellenden Prototyp eingegangen wird, soll das WfMS der Ascom untersucht
werden.
Die Analyse soll folgende Fragen beantworten können:
-
Wo können die Workflowdaten bezogen werden?
Wie kann ein Workflow mit einem externen Client übernommen werden?
Was müssen bei einem übernommenen Workflow auf dem WfMS für Änderungen vorgenommen
werden
Wie kann ein übernommener Workflow mit dem WfMS synchronisiert werden?
Diese Fragen sollen am Ende dieses Kapitels beantwortet sein. Das WfMS der Ascom wird in einer
Domino-Datenbank von Lotus gepflegt. Bearbeitet und eingesehen können die einzelnen Workflows
des WfMS mit dem Lotus Notes Client. Lotus Notes wird in der Ascom auch als E-Mail Client
verwendet. Im Lotus Notes werden auch Dokumentationen, Protokolle und Anwenderdokumente
verwaltet. Das WfMS der Ascom wurde umfassend dokumentiert. Alle Modellierschemen und
Beschreibungen der Workflows sind vorhanden und über den Client einsehbar. Dies erspart eine
erneute Modellierung der bestehenden Workflows.
- Seite 40 -
Entwicklung
3.1.1. Was beinhaltet das Workflow-Management-System der Ascom?
Das WfMS der Ascom beinhaltet − wie in Abbildung 31 ersichtlich ist − drei Gruppen. Eine Gruppe
beinhaltet die «Rent a Client»-Workflows (RaC), eine weitere die Voice Workflows und die letzte die
Netzwerk Workflows. Die RaC Workflows managen Gerätevermietungen, Softwareerweiterungen,
Büroumzüge und Rückgabe von Geräten. Die Netzwerkworkflows bearbeiten die Handhabung von
Netzwerkanschlüssen. Das heisst, es werden Neuanschlüsse, Anschlussumzüge und
Anschlussrückgaben gemanagt. Diese beiden Gruppen werden nicht näher betrachtet, da sie für die
vorliegende Arbeit nicht von Bedeutung sind. Die vorliegende Arbeit befasst sich nur mit den «VoiceWorkflows». Die Abbildung 31 zeigt die Startseite des WfMS (grüner Rahmen markiert die VoiceWorkflows).
Abbildung 31: Der Client vom Ascom WfMS
Der IT Voice Workflow wurde in der Ascom im April 2001 überall in der Schweiz als elektronisches
Bestellformular mit integrierter Prozessunterstützung eingeführt. Das Formular beginnt mit der
Bestellung des Kunden, führt über die «Unterschrift» des Vorgesetzten und endet mit dem Erbringen
der Dienstleistung durch die Informatik oder der lokalen Elektriker. Es ermöglicht dem Kunden zu jeder
Zeit einen Einblick in den Status des Auftrags. Das heisst, der Kunde kann mit seinem Ticket10 den
Stand der Arbeit betrachten. Er sieht also, dass das Formular zum Beispiel erst auf dem «virtuellen»
Schreibtisch eines Vorgesetzten ist. Die IT-Unterstützung des Ablaufs durch ein WfMS soll die
Durchlaufzeit und die Transparenz der Bestellung verbessern und die Papierformulare ersetzten. Die
Abbildung 31 zeigt den Screenshot eines Administrator Clients. Beim normalen Client fehlt der
Administrationsknopf unten links. Der «normale» Client kann nur Aufträge erfassen, einsehen und
bearbeiten. Ebenso kann er den Status seines eigenen Auftrags einsehen.
Interessant für die Analyse ist bestimmt der Punkt «Auftrags Status einsehen» in Abbildung 31. Die
Abbildung 32 zeigt eine Übersicht der laufenden Workflows. Sie zeigt die verschiedenen Aktivitäten im
«Voice-Workflow».
10
Jeder Kunde bekommt eine Auftragsnummer, ein sogenanntes Ticket, damit er den Status seines Auftrages einsehen kann.
- Seite 41 -
Entwicklung
Abbildung 32: Übersicht der Aktivitäten im Voice Workflow
Anhand der obigen Aktivitäten kann auf das Prozessmodell geschlossen werden. Ersichtlich wird aus
der Abbildung auch, dass für einen Elektromonteur bestimmt nicht alle Aktivitäten von gleicher
Relevanz sind. Welche Schritte für den Elektromonteur entscheidend sind, sollte aus dem
Prozessmodell ersichtlich sein.
3.1.2. Das Voice Workflow Modell
Der Prozessablauf folgt nach dem Erstellen einen Auftrages einem klar definierten Ablauf. Dieser kann
in die folgenden fünf Schritte aufgeteilt werden:
Kunde erstellt einen Antrag:
Der Kunde füllt sein Formular aus: (siehe
Abbildung 35) Er muss in diesem Formular den
Kostenstellenleiter angeben, da dieser den
Antrag bewilligen muss. Ist das Formular
ausgefüllt, kann der Anwender den Auftrag
weiterleiten. (Das Formular wird einfach in
einem E-Mail an den Kostenstellenleiter
weitergeschickt).
Vorgesetzter bearbeitet Auftrag:
Der
Kostenstellenleiter
bekommt
das
ausgefüllte Formular via E-Mail. Er muss
dieses Formular − sofern er das Gesuch
bewilligt
−
an
den
Mandatsträger
weiterschicken. Lehnt er das Gesuch ab, so
wird das Formular mit dem Vermerk «Gesuch
abgelehnt»
an
den
Antragssteller
zurückgeschickt. Das Weiterschicken des
Formulars wird mit der Unterschrift der
jeweiligen Person gleichgesetzt.
Der zweite Vorgesetzte bearbeitet den
Antrag:
Dieser Schritt wird, sofern kein zweiter
Vorgesetzter vorhanden ist, übersprungen.
Ansonsten ist der Ablauf identisch wie der
«Vorgesetzter bearbeitet Auftrag».
Bearbeitung des Auftrages durch den
Mandatsträger:
Der Mandatsträger, in diesem Fall der Chef
Elektriker, hat nun die Möglichkeit, den Auftrag
zurückzuweisen oder diesen an die Informatik
(Ascom Net) weiterzuleiten.
- Seite 42 -
Abbildung 33: Genereller IT-Workflow
Entwicklung
Umsetzung:
Der Ausführungstermin wird abgeklärt und dem Kunden via E-Mail mitgeteilt. Sollten sich
Verzögerungen ergeben, muss dies dem Kunden ebenso mitgeteilt werden. Zusätzlich kann der
Kunde jederzeit den Status des Auftrages abfragen.
Vergleichen wir Abbildung 32 mit Abbildung 33, so zeigt sich, dass die Kategorien aus der Abbildung
32 immer einer Aktivität in der Abbildung 33 entsprechen. Der Ablauf zwischen diesen Aktivitäten wird
vom WfMS gesteuert. Diesem Modell kann entnommen werden, dass ein Elektromonteur nur zum
Einsatz kommt, wenn ein Mandatsträger einen Auftrag bewilligt. Diese Aufträge sammeln sich in den
beiden Kategorien «Elektriker Vorort in Arbeit» und «Elektriker Standort Alt in Arbeit». Die Abbildung
34 ist eine Erweiterung von Abbildung 32. Sie zeigt die verschiedenen laufenden Aufträge, welche für
den Elektromonteur von Interesse sind.
Abbildung 34: Übersicht der Aufträge für Elektromonteure
Wurde ein Auftrag noch nicht übernommen, so ist in der Spalte «Verantwortlicher» kein
Personenname eingetragen, sondern lediglich eine Bezeichnung der geforderten Eigenschaften des
Elektrikers: «[VELEC_ZD01]» bedeutet beispielsweise, dass dieser Auftrag von einem Elektromonteur
aus dem Gebäude ZD01 übernommen werden muss. Die jeweiligen Elektromonteure haben in ihrem
Notes Client nur Einsicht in jene Aufträge, die für ihre Gruppe bestimmt sind. Wird ein Auftrag von
einem Elektromonteur im WfMS übernommen, so wird sein Name als Verantwortlicher eingetragen,
und der Auftrag kann von keinem anderen Elektromonteur mehr angenommen werden. Demnach
können Elektromonteure nur Aufträge übernehmen, die sich in der Kategorie «Elektriker Vorort in
Arbeit» und «Elektriker Standort alt in Arbeit» befinden.
Das Auftragsformular muss in die Analyse einbezogen werden, da der Elektromonteur auf seinem
Client dieses Formular sieht und eben dieses auf dem PDA nachgebildet werden soll. Die Abbildung
35 zeigt einen Ausschnitt eines solchen Formulars. Wichtig ist noch der Hinweis, dass der
Elektromonteur das Formular nicht verändern oder ergänzen kann. Er kann das Formular nur als
Informationsbasis für seinen Auftrag nutzten.
- Seite 43 -
Entwicklung
Abbildung 35: Formular eines Auftrages
Das Formular erscheint als interaktives Dokument. Der Clientbenutzter kann zwar die «Checkboxes»
neu anwählen oder löschen. Ein Editieren des Formulars nach der Genehmigung des Vorgesetzten
entspricht bestimmt nicht einem üblichen Vorgang. Es können zwar Änderungen am Dokument
vorgenommen werden, diese werden allerdings nicht gespeichert und haben somit auch keine
Auswirkungen auf den weiteren Verlauf. Alle Änderungen werden vom WfMS schlicht ignoriert.
Das Formular auf dem PDA solle gemäss der Abbildung 35 aufgebaut werden. Der Elektromonteur
kann anhand des Formulars entscheiden, ob er diesen Auftrag übernehmen möchte oder nicht. Will er
den Auftrag nicht übernehmen, kann er das Formular wieder schliessen, was keinen Einfluss auf den
Auftrag hat. Übernimmt er hingegen den Auftrag, wird der Name des entsprechenden Monteurs als für
den Auftrag verantwortlich eingetragen. Siehe hierzu Abbildung 34.
Öffnet der Elektromonteur einen Auftrag, den er bereits übernommen hat, so kann er diesen
abschliessen oder zurückweisen. Er kann das Formular natürlich auch wieder schliessen, ohne dass
er den Auftrag explizit abschliesst. Die Abbildung 36 zeigt eine Übersicht der Möglichkeiten, die der
Elektromonteur zur Bearbeitung eines Auftrages hat. In der Darstellung ist die Möglichkeit nicht
berücksichtigt, dass ein Elektromonteur seine Aufträge ohne Statusänderung verlassen kann.
- Seite 44 -
Entwicklung
Abbildung 36: Ablauf eines Auftrages
Die Abbildung 36 zeigt eine weitere Erkenntnis: Der Elektromonteur hat nur Zugriff auf die
Workflowschritte sieben und acht. Aufträge die beendet wurden, werden im «Schritt» 98 archiviert und
zurückgewiesene Aufträge werden dem «Schritt» 79 zugewiesen.
3.1.3. Wie ein Auftrag von einem externen Client übernommen wird
Um mit dem PDA die Workflows im WfMS modifizieren zu können, müssen einzelne Schritte des
Arbeitsablaufes von diesem neuen Client aus bewerkstelligt werden. Dazu muss analysiert werden,
welche Mutationen im WfMS nötig sind. Um diese Schritte besser nachvollziehen zu können, stellt das
WfMS den Notes Designer Client zur Verfügung, ein Entwicklungswerkzeug, mit dem Knöpfe, Felder,
Formulare sowie Aktionen erstellt und betrachtet werden können. Dieses Werkzeug macht ersichtlich,
dass zur Übernahme eines Auftrages der Name des Elektromonteurs in das Feld
«Auftraguebernehmen» geschrieben werden muss. Diese Aktion ist für einen externen Java Client
kein Problem, da mit Java auf alle Felder in einem Notes Dokument zugegriffen werden kann.
3.1.4. Wie ein Workflow synchronisiert wird
Der Notes Domino Designer bietet auch bei diesem Problem Hilfe an. Aus dem Designer ist
ersichtlich, dass die Statusänderung der Workflows mit einem Softwareagenten11 umgesetzt wird. Der
anzusprechende Agent nennt sich «ANSTEP». Analysiert man den Source Code von diesem - in
LotusScript geschriebenen – Agenten ist ersichtlich, dass dieser Agent die Art der Aktion
(«abschliessen» oder «zurückweisen») und die eineindeutige Identifikationsnummer12 kennen muss.
Mehr Parameter braucht der Softwareagent für eine Synchronisation nicht. Alle anderen Angaben sind
im Formular bereits enthalten. Das WfMS weiss auf Grund der angewählten Aktion, in welchem
Ablaufschritt sich das Formular befindet, ebenso ist bekannt, wer den Auftrag erledigt hat, nämlich
derjenige, den ihn übernommen hat.
11
«Lassen Sie uns Agenten definieren als zielgerichtete Softwareeinheiten; für einen speziellen Zweck geschaffen.
«Zielgerichtet» grenzt sie von Subroutinen ab: Agenten haben eigene Ideen, wie sie ihre Aufgabe lösen können, ihre eigene
Tagesordnung. «Spezieller Zweck» grenzt sie von multifunktionalen Applikationen ab: Agenten sind normalerweise viel
kleiner.»[Softwareagenten]
12
Eine Dokument ID. In Notes nennt sich diese «UNID».
- Seite 45 -
Entwicklung
3.1.5. Der PDA als Client im Workflow-Management-System (WfMS) der Ascom
Die Entnahme eines Workflows mit dem PDA muss dieselben Aktionen auslösen, die auch mit dem
Notes Client ausgelöst werden würden. Der Einfluss des P2W-Clients auf den Voice Workflow darf
nicht ersichtlich sein. Ebenso sollen dieselben Softwareagenten angesprochen werden. Der einzige
Unterschied ist, dass die Userverwaltung nicht über die Notesadministration funktioniert.13 Ebenso
darf es nicht zu einem Datenverlust kommen, ausser der Anwender verliert den PDA. Diese Gefahr
besteht aber auch bei einem Verlust des Laptops oder bei einem Harddisk-Crash. Ein Backup der
Harddisk kann dieses Problem zwar vermindern, aber auch nicht gänzlich ausschliessen.
3.2. Analyse der zu erstellenden Software
In der Phase der Software Analyse sollen verschieden Punkte geklärt werden. Einerseits sollte
bekannt sein, welche Personen mit dem System arbeiten werden, anderseits sollen alle
Geschäftsprozesse identifiziert werden.
3.2.1. Anwendungsfalldiagramme (Use Cases)
In der Abbildung 37 sind die möglichen Anwendungsfälle eines Elektromonteurs zu sehen. Generell ist
zu sagen, dass er Zugriff auf Workflow Details hat und diesen editieren kann. Unter Editieren ist in
diesem Falle gemeint, dass er Workflows übernehmen, abschliessen oder ignorieren kann. Ebenso
kann der Elektromonteur seine Workflows mit dem Server synchronisieren und neue Workflows vom
Server beziehen. Die Synchronisiation sowie das Downloaden von Workflows ist in jedem Falle mit
einem Login verbunden. Damit ein Login durchgeführt werden kann, ist eine Verbindung zum Server
notwendig.
P2W Client
WF Detail und
Editieren
WF Auswahl und
Titel
Synchronisierbare
WFs anzeigen
Verbindung
auf/abbauen
Synchronisation
Elektromonteur
Login
WF downloaden
Abbildung 37: Use Case «Elektromonteur»
13
Mehr dazu im Kapitel 4.1.5
- Seite 46 -
Entwicklung
Der Administrator kann den Server starten und stoppen. Ebenso erhält er eine Übersicht der
registrierten Benutzter. Der Administrator kann Benutzerdaten ändern, löschen, sperren und
entsperren. Er kann auch neue Benutzer anlegen. Dieser Anwendungsfall ist in Abbildung 38 zu
sehen.
P2W Serveradministration
Server starten
Server stoppen
Neuer Benutzer
anlegen
«erweitert»
«erweitert»
Benutzer löschen
Benutzer verwalten
«erweitert»
Administrator
Benutzerdaten
bearbeiten
Abbildung 38: Use Case «Administrator»
3.2.2. Anwendungsfallbeschreibung
Die folgenden Tabellen beschreiben die Use Cases aus Abbildung 37 und 38. Sie werden mit den
folgenden Bedingungen erweitert:
-
Was verwendet wird
Welche Vorbedingungen an das System gestellt werden
Wie der Ablauf aussieht
Wie der Endzustand aussieht
Welche Variationen vorkommen können
- Seite 47 -
Entwicklung
Name:
Aktor
Beschreibung
Verwendet
Vorbedingung
Ablauf
Endzustand
Variationen
WF Detail und Editieren
Elektromonteur
Der Elektromonteur sieht den WF im Detail. Er kann den
Auftrag abschliessen oder zurückweisen.
Es müssen lokale WFs vorhanden sein.
1. Der Elektromonteur wählte einen WF aus der Auswahl
aus.
2. Der angewählte WF wird angezeigt.
3. Statusänderung optional (Abschliessen oder
zurückweisen) und dann zurück zur Übersicht.
Übersicht der WFs.
Wird ein WF abgeschlossen oder zurückgewiesen, so
darf dieser WF nicht mehr bearbeitbar sein. Der WF ist
nun synchronisierbar.
Bemerkungen
Tabelle 6: Workflow editieren und Details betrachten
Name:
Aktor
Beschreibung
Verwendet
Vorbedingung
Ablauf
Endzustand
WF Auswahl und Titel
Elektromonteur
Dem Elektromonteur werden die Titel der WFs angezeigt.
Ebenso hat er die Möglichkeit WFs vom Server zu
beziehen oder WFs, die synchronisierbar sind, zu
synchronisieren.
Auf dem PDA ist der P2W Client installiert.
1. Der Elektromonteur startet den P2W Client.
2. Dem Elektromonteur wird eine Übersicht der lokal
gespeicherten WFs gezeigt.
3. Er kann nun Details der verschiedenen WFs
betrachten, WFs synchronisieren, WFs downloaden oder
das Programm verlassen.
Folgende Endzustände sind möglich:
- Programm beendet
- WFs synchronisieren
- WFs downloaden
- Detailansicht eines WFs
Variationen
Bemerkungen
Tabelle 7: Workflow Auswahl und Titelübersicht
- Seite 48 -
Entwicklung
Name:
Aktor
Beschreibung
Verwendet
Vorbedingung
Ablauf
Endzustand
Variationen
Synchronisation
Elektromonteur
Der Elektromonteur kann fertig bearbeitete WFs mit dem
Server synchronisieren
Login
Auf dem PDA ist der P2W Client installiert und gestartet
1. Der Elektromonteur wählt im Startmenü
"synchronisieren".
2. Nach der Login Prozedur werden alle
synchronisierbaren WFs mit dem Server, resp. mit dem
WfMS synchronisiert.
3. Die synchronisierten WFs werden, sofern sie fehlerfrei
synchronisert werden, auf dem PDA gelöscht.
Alle synchronisierbaren WFs sind synchronisiert und lokal
gelöscht. Der Aktor befindet sich wieder im Startmenü mit
der WF Titelübersicht
Wenn beim Synchronisieren keine Fehler auftreten,
werden die WFs auf dem PDA gelöscht. Tritt allerdings
ein Fehler beim Synchronisieren auf, so werden die
lokalen WFs nicht gelöscht!
Bemerkungen
Tabelle 8: Workflows synchronisieren
Name:
Aktor
Beschreibung
Verwendet
Vorbedingung
Ablauf
Endzustand
Variationen
Synchronisierbare WFs anzeigen
Elektromonteur
Dem Elektromonteur wird beim Start des Programmes
angezeigt, wieviele WFs synchronisierbar sind.
Auf dem PDA ist der P2W Client installiert
1. Der Elektromonteur startet das Programm.
2. Dem Elektromonteur wird angezeigt, wieviele WFs
synchronisierbar sind.
3. Der Elektromonteur kann nun die WFs
synchronisieren.
Die synchronisierbaren WFs sind synchronisiert.
Der Elektromonteur will die WFs erst später
synchronisieren und arbeitet weiter, ohne zu
synchronisieren.
Bemerkungen
Tabelle 9: Synchronisierbare Workflows anzeigen
- Seite 49 -
Entwicklung
Name:
Aktor
Beschreibung
Verwendet
Vorbedingung
Ablauf
Endzustand
Variationen
WF downloaden
Elektromonteur
Der Elektromonteur kann vom Server neue WFs
herunterladen.
Login
Auf dem PDA ist der P2W Client installiert und gestartet.
Es muss eine Verbindung zum Internet bestehen
1. Der Elektromonteur wählt im Startmenü "download
WFs".
2. Nun muss sich der Elektromonteur einloggen.
3. Dem Elektromonteur wird eine Titelübersicht aller
downloadbaren WFs angezeigt.
4. Der Elektromonteur kann einen WF anwählen und
downloaden.
Der Elektromonteur hat einen WF heruntergeladen, er
befindet sich wieder in der Übersicht der downloadbaren
WFs. Er kann nun weiter WFs downloaden.
Der Elektromonteur kann die Verbindung zum Server
unterbrechen. Tritt ein Fehler beim Downloaden auf wird
der WF nicht gespeichert. Ein erneuter Download für
diesen WF ist nötig.
Bemerkungen
Tabelle 10: Einen Workflow downloaden
Name:
Aktor
Beschreibung
Verwendet
Vorbedingung
Ablauf
Endzustand
Variationen
Login
Elektromonteur
Der Elektromonteur meldet sich beim P2W Server an.
Der Server überprüft Username und Passwort, welches
sich in einer Access Datenbank befindet.
Der P2W Client ist gestartet und es besteht eine
Internetverbindung.
1. Der Client baut eine Verbindung zum Server auf.
2. Der Elektromonteur muss sein Username und
Passwort eingeben.
3. Der P2W Server überprüft die erhaltenen Daten.
Der Elektromonteur ist beim System angemeldet
Gibt der Elektromonteur drei Mal ein falsches Passwort
ein, so wird der User gesperrt. Das Konto eines
gesperrten Users kann nur vom Systemadministrator
reaktiviert werden. Ist es nicht möglich eine Verbindung
zum Server aufzubauen, wird der User darüber informiert.
Bemerkungen
Tabelle 11: Login
- Seite 50 -
Entwicklung
Name:
Aktor
Beschreibung
Verwendet
Vorbedingung
Ablauf
Endzustand
Verbindung auf/abbauen
Elektromonteur
Die Verbindung zum P2W Server wird auf- oder abgebaut
Der P2W Client ist gestartet
Verbindung zum Server wird auf- oder abgebaut. Beide
"Verbindungsänderungen" werden im Logfile des Servers
festgehalten.
Der Elektromonteur ist beim Server an- oder abgemeldet.
Variationen
Bemerkungen
Tabelle 12: Die Verbindung zum Server auf- oder abbauen
Name:
Aktor
Beschreibung
Verwendet
Vorbedingung
Ablauf
Endzustand
Server stoppen
Administrator
Der Administrator will den Server stoppen
Server ist im aktiven Zustand.
1. Betriebssystem ist gestartet.
2. Script zum Stoppen ausführen.
Server wurde gestoppt und ist für Anfragen nicht mehr
ansprechbar.
Variationen
Bemerkungen
Tabelle 13: Den Server stoppen
Name:
Aktor
Beschreibung
Verwendet
Vorbedingung
Ablauf
Endzustand
Server starten
Administrator
Der Administrator will den Server starten.
1. Betriebssystem gestartet.
2. Server korrekt installiert.
Der Administrator kann den Server mit einem Script
starten, Initialisierung wird gestartet
Der Server läuft und die Benutzer können an ihn
Anfragen stellen. Server ist initialisiert.
Variationen
Bemerkungen
Tabelle 14: Den Server starten
- Seite 51 -
Entwicklung
3.2.3. Aktivitätsdiagramm
In Abbildung 39 ist das Aktivitätsdiagram des Login-Vorganges zu sehen. Wird das Programm
gestartet, erscheint eine Menüauswahl. Wird nun Synchronisation oder Download angewählt, muss
eine Verbindung zu Server aufgebaut werden. Der PDA versucht eine Verbindung mit dem Server
aufzubauen. Gelingt dies, so kann der Anwender seinen Loginname und sein Passwort eingeben.
Diese werden über die erfolgreich aufgebaute Verbindung an den Server geschickt.
Der Server überprüft den erhaltenen Loginnamen sowie das Passwort und schickt dem Client den
Status der Überprüfung. War die Eingabe korrekt, kann der Loginvorgang als abgeschlossen
betrachtet werden. Nach einem erfolgreichen Login können Aufträge eingesehen und abgeschlossene
Aufträge mit dem Server synchronisiert werden.
Abbildung 39: Aktivitätsdiagramm Login
- Seite 52 -
Entwicklung
In Abbildung 40 wird dem Anwender visualisiert, wieviele synchronisierbare Aufträge er lokal auf
seinem PDA hat. Er kann nun entscheiden, ob er die abgeschlossenen Aufträge synchronisieren oder
ignorieren möchte. Will er seine Aufträge synchronisieren, wird er zum Login weitergeleitet. Möchte er
die Workflows zu einem späteren Zeitpunkt synchronisieren, wird der Synchronisationsvorgang
beendet und es erscheint wieder die Menüauswahl (Siehe Abbildung 39). Wurde der Loginvorgang
erfolgreich durchgeführt, synchronisiert der Server alle abgeschlossenen Aufträge. Konnte der Server
die Workflows korrekt synchronisieren, werden die lokal auf dem PDA gespeicherten Workflows
gelöscht. Konnte der Server diese jedoch nicht korrekt sysnchronisieren, beginnt der
Synchronisationsprozess von neuem.
Client
Server
Anzahl synchronisierbare WFs anzeigen.
Synch?
Nein
Ja
Login
WFs mit Server synchronisieren
Fehlermeldung
Ja
Server synchronisiert
Fehler?
Nein
lokale synchronisierte WFs werden gelöscht
Abbildung 40: Aktivitätsdiagramm Synchronisation von Workflows
- Seite 53 -
Entwicklung
Die Abbildung 41 beschreibt den Vorgang des «Downloaden» von Workflows. Vorbedingung ist die
erfolgreiche Anmeldung beim Server. Zuerst wird dem Anwender eine Übersicht der möglichen
Aufträge gezeigt (siehe Abbildung 34). Er kann einen Workflow auswählen und die Details von diesem
Workflow einsehen. Die Details werden ihm getreu dem Notes Client angezeigt und er kann auf der
letzten Seite des Formulars den Auftrag übernehmen. Der PDA übergibt dem Server die notwendigen
Daten, für die Entnahme des entsprechenden Auftrags. Konnte der Server die Übernahme des
Auftrages fehlerfrei durchführen, wird der übernommene Workflow lokal auf dem PDA gespeichert.
Konnte der Server die Statusänderung auf dem WfMS nicht vornehmen, wird auf dem PDA eine
Fehlermeldung generiert und der PDA kehrt wieder zur Übersicht der downloadbaren Workflows
zurück.
Abbildung 41: Aktivitätsdiagramm Workflow downloaden
- Seite 54 -
Entwicklung
Wie mit den lokalen Workflows auf dem PDA gearbeitet wird, zeigt die Abbildung 42. Zuerst werden in
der Standardübersicht die lokal vorhandenen Aufträge angezeigt. Diese können durch Auswählen
detaillierter betrachtet werden. Soll ein übernommener Auftrag abgeschlossen oder zurückgewiesen
werden, kann auf der letzten Seite des Formulars der gewünschte Befehl aktiviert werden. Der
ausgewählte Auftrag wird unter den synchronisierbaren Workflows gespeichert und bei den lokalen
Workflows gelöscht. Der Anwender kann einen abgeschlossen oder zurückgewiesenen Auftrag nicht
mehr einsehen. Er kann diesen nur noch mit dem System synchronisieren. Dies erscheint in erster
Linie etwas unsinnig, entspricht allerdings dem Workflow-Vorgang. Ein abgeschlossener Auftrag kann
auch mit dem Notes Client vom Elektromonteur nicht mehr betrachtet werden.
Client
Lokale WFs anzeigen
Details anzeigen
Zurück zur Übersicht?
Ja
Nein
{OR}
Auftrag zurückweisen
Auftrag beenden
WF speichern und sperren
Beenden?
Nein
Ja
Abbildung 42: Aktivitätsdiagramm Workflow editieren und Titel anzeigen
- Seite 55 -
Entwicklung
3.3. Design
3.3.1. Systemarchitektur
Die Systemarchitektur des Servers ist in Abbildung 43 zu sehen. Der Server ist das Bindeglied
zwischen dem PDA, dem WfMS und der Administrationsdatenbank. Will sich ein P2W-User beim
Server anmelden, so überprüft der Server in der Accessdatenbank das Passwort und die Rechte
(siehe Kapitel 3.5.2). Wenn der P2W-User einen Auftrag beziehen möchte, so bezieht der Server
ebenfalls zuerst den Auftrag aus dem WfMS und sendet ihn an den PDA weiter. Der Server wurde mit
einem Java Servlet (siehe hierzu Kapitel 2.4.2) realisiert. Das Servlet wird mit einem XML-File
konfiguriert.
Abbildung 43: Systemarchitektur
Im Logfile werden alle Transaktionen festgehalten. Das WfMS befindet sich nicht auf demselben
Rechner wie das Servlet. Das Servlet baut eine Internetverbindung zum WfMS sowie zur
Userdatenbank auf. Das Konfigurationsfile liefert die für die entsprechenden Verbindungen
notwendigen Parameter.
- Seite 56 -
Entwicklung
3.3.2. Klassendiagramme
Die Abbildung 44 zeigt das Klassendiagramm des Clients. Der Client besteht aus vier Klassen. Die
Klasse «GenerateForms» ist eine reine «Graphical User Interface»-Klasse (GUI), welche die
verschiedenen Formulare generiert und an das MIDlet in Form eines «Form-Objektes» zurückgibt. Die
«P2WClientMIDlet» dient der Darstellung und der Verwaltung der verschiedenen Kommandos. Sie
instanziert die restlichen drei Klassen zu Beginn des Programmes. Aus diesem Grunde sind die Pfeile
als Instanzierung und nicht als Vererbung zu betrachten. Es wurde eine saubere Trennung von
Kontrolleinheit und Design angestrebt. Dies konnte auch so realisiert werden, mit der einzigen
Ausnahme, dass die P2WClientMIDlet Klasse auch einige spezielle Formulare darstellt. Die Klasse
«Connect» dient der Netzwerkverbindung. Sie baut eine Verbindung zum Server auf und sendet die
entsprechenden Befehle. Diese Klasse retourniert die vom Server erhaltenen Daten an die MIDletKlasse, welche die Daten zum Teil selber darstellt oder diese an die «GenerateForms» Klasse
weitergibt.
P2WClientMidlet
Connect
GenerateForm s
Store
Abbildung 44: Klassendiagramm
Die Klasse «Store» verwaltet die intern gespeicherten Daten. Gespeicherte Workflows und
Konfigurationsdaten werden in dieser Klasse gespeichert und gelesen. Die gespeicherten oder
gelesenen Daten werden an die MIDlet-Klasse zurückgegeben, welche diese Daten weiterverarbeitet.
- Seite 57 -
Entwicklung
3.3.3. Sequenzdiagramme
Die Abbildung 45 visualisiert den Ablauf des Loginvorganges. Der Elektromonteur möchte Aufträge
vom System auf seinen PDA laden oder abgeschlossene Aufträge mit dem System synchronisieren,
was ein Login verlangt. Der Elektromonteur muss der Applikation seinen Usernamen und sein
Passwort angeben. Das MIDlet versucht eine Verbindung zum Server aufzubauen. Der Server
registriert jeden Verbindungsversuch und schreibt diesen in ein Logfile. Bekommt das MIDlet eine
positive Bestätigung vom Server, so sendet dieses den Usernamen und das Passwort an den Server.
Der Server testet, ob der Usernamen existiert und ob das Passwort zum angegebenen Namen passt.
Der Status dieser Abfrage wird ebenfalls im Logfile vermerkt. Derselbe Status wird dem MIDlet
geschickt, welches den Anwender informiert. Versucht der User mehr als dreimal mit einem falschen
Passwort Zutritt zum System zu bekommen, wird dieser User auf der «Userdatenbank» gesperrt und
kann nur noch vom Systemadministrator reaktiviert werden.
In Abbildung 46 ist ein Synchronisationsablauf von lokal gespeicherten Aufträgen zu sehen. Der
Elektromonteur wählt im Hauptmenü «Synchronisation WFs», und die Aufträge werden nach einem
erfolgreichen Login mit dem System synchronisiert. Zuerst wird im persistenten14 Speicher des PDAs
nach synchronisierbaren Aufträgen gesucht. Diese angeschlossenen oder zurückgewiesenen Aufträge
werden danach dem Server zugeschickt. Dem Server wird allerdings nur die Dokument-ID (UNID) und
die Eigenschaft des Auftrages (abgeschlossen oder zurückgewiesen) übergeben. Der Server öffnet
nach Erhalt der Daten eine Verbindung zum Datenbankserver des WfMS und ruft den Agenten,
welcher für die notwendigen Aktionen zuständig ist, mit den notwendigen Parametern auf. Die
Verbindungsklasse zum Datenbankserver gibt eine Statusmeldung an den Server zurück, welcher ins
Logfile geschrieben wird. Diese Statusmeldung wird auch an den Client weitergeschickt und dem
Elektromonteur visualisiert. Ist diese Meldung positiv, was heisst, dass die Workflows korrekt
synchronisiert wurden, werden die auf dem PDA gespeicherten − soeben synchronisierten −
Workflows gelöscht. Dies verhindert ein erneutes Synchronisieren von bereits synchronisierten
Workflows, was auf der Serverseite für Probleme sorgen würde.
Die Abbildung 47 zeigt, wie ein bestimmter Auftrag auf den PDA geladen werden kann. Der
Elektromonteur wählt den Menüpunkt «Download WF» im Hauptmenü aus. Nach erfolgreichem Login
wird der Server benachrichtigt, dass der Elektromonteur alle übernahmebereiten Aufträge einsehen
möchte. Der Server bekommt über die Notesverbindungsklasse alle Daten der entsprechenden
Workflows. Diese Daten werden dem Client geschickt. Die Workflowtitel werden dem Elektromonteur
angezeigt. Er kann nun die Details eines gewünschten Auftrages einsehen. Immer am Ende eines
solchen Formulares sind gewisse Aktionen möglich. In diesem Falle kann er wieder zurück zur
Übersicht, oder er kann den Auftrag auf seinen PDA runterladen, was einer Übernahme des Auftrages
gleich kommt. Wird der Auftrag übernommen, so wird dies dem Server mitgeteilt. Dieser erhält die
eindeutige ID (UNID) und den Namen des Elektromonteurs. Auf Grund dieser Daten kann die
Notesverbindungsklasse dem WfMS mitteilen, welcher Auftrag von wem übernommen wird. Diese
Notesverbindungsklasse gibt wiederum eine Statusmeldung zurück, welche aussagt, ob die
gewünschte Aktion erfolgreich war. Konnte diese Aktion fehlerfrei durchgeführt werden, so wird der
Client informiert, dass dieser den entsprechenden Workflow auf seinem PDA persistent unter den
bearbeitbaren Workflows speichern kann. Auch diese Meldung wird dem Elektromonteur visualisiert.
Das letzte Diagramm ist in Abbildung 48 abgebildet und erklärt, wie die lokal gespeicherten Aufträge
betrachtet und bearbeitet werden können. Der Elektromonteur startet im Übersichtsmenü den Befehl
«lokale Workflows bearbeiten». Das MIDlet gibt diese Aufforderung an die PDA-Datenbankklasse
weiter, welche in der Datenbank nach lokalen, nichtsynchronisierten Workflows sucht. Die gefundenen
Workflows werden zurückgegeben und das MIDlet zeigt dem Elektromonteur eine Übersicht der
Aufträge. Will der Elektromonteur Details eines Auftrages betrachten, so kann er den gewünschten
Auftrag anwählen und die Datenbankklasse liefert dem MIDlet das Formular, ausgefüllt mit den
entsprechenden Daten. Auf der letzten Seite dieses Formulars kann der Elektromonteur den Auftrag
abschliessen oder zurückweisen. Dies wird wiederum via der Datenbankklasse vom MIDlet an die
Datenbank weitergeleitet. Der Elektromonteur bekommt vom MIDlet eine Meldung, ob die Aktion
erfolgreich ausgeführt werden konnte.
14
Unter persistenter Speicherung versteht man ein dauerhaftes Speichern von Daten. Die Daten bleiben nach dem Ausschalten
des Gerätes erhalten.
- Seite 58 -
start
login(usrname, passwort)
Elektromonteur
connect()
connect()
- Seite 59 login_status
login_status
testLogin(usrname, passwort)
log_status
write(time, "connection")
Logfile
log_status
write(time, usrname, login_status)
Server
Server
conn_status
Connection
MIDlet
Client
DBConnection
Entwicklung
Abbildung 45: Sequenzdiagramm Login
Abbildung 46: Sequenzdiagramm Download
- Seite 60 -
getwf_status, safe_satus
getWF(wfTx)
getwf_status, wfT1, wfT2...
Elektromonteur getAllTitles()
getAllTitles()
Connection
getwf_status, safe_satus
getWF(wfTx)
getwf_status, wfT1, wfT2...
MIDlet
safe_status
safe(wfx)
getwf_status
getWF(usrname, wfTx)
getwf_status, wf1, wf2...
getAllTitles(usrname, key)
PDA_DB
Client
getAll(usrname, key)
LogFile
getwf_status
log_status
write(time, usrname, "copy wf", getwf_status)
Server
Server
Notes
getwf_status
getAll(usrname, key)
NotesDBConnection
Entwicklung
Abbildung 47: Sequenzdiagramm Synchronisation
- Seite 61 -
synchronize()
PDA_DB
del_status
deleteAllSynch()
synch_status
Server
Server
synch_status
synch(usrname, synchdaten)
LogFile
log_status
write(time, usrname, "synch", synch_status)
synch_daten
getAllSynch()
Connection
synch_status, del_status
synch_status, del_status
Elektromonteur
synchronize()
MIDlet
Client
Notes
synch_status
NotesDBConnection
Entwicklung
Entwicklung
MIDlet
PDA_DB_Handler
PDA_DB
Elektromonteur
showLocTitle()
showLocTitle()
showLocTitle()
vector[titel_status, titel, titel...]
vector[titel_status, titel, titel...]
vector[status, titel, titel...]
showLocDetail(title)
vector[wf_status, daten]
do(funkt, titel)
do(funkt, titel)
do(funkt, titel)
fnkt_status
fnkt_status
fnkt_status
Abbildung 48: Sequenzdiagramm WF Titel und Funktionen
- Seite 62 -
Entwicklung
3.4. Implementation Client
3.4.1. Entwicklungsumgebung mit Forte 4 Java Mobile Edition
Da die Softwareentwicklung der Ascom Informatik mit IBM-Produkten umgesetzt wird, lag die
Entscheidung der Entwicklungsumgebung auf der Hand. IBM bietet die Entwicklungsumgebung
«Websphere Studio Device Developper»(WSDD) gratis im Internet an. Das WSDD ist eine
Entwicklungsumgebung, welche auf eine Javaprogrammierung für PDAs ausgelegt ist. Im Laufe der
Entwicklung ergaben sich jedoch Probleme bei der Netzwerkverbindung mit der VM von IBM (siehe
Exkurs), welche einem Wechsel auf Forte 4 Java Mobile Edition erforderlich machten.
Die Entwicklungsumgebung von Forte ist einfach in der Handhabung und schnell erlernbar. Die
Hilfetools sind umfangreich und bieten auf fast alle Fragen eine Antwort. Die Abbildung 49 zeigt einen
Ausschnitt der Entwicklungsumgebung. «MIDlet Suites» und MIDlets können mit den praktischen
Wizzards15 erstellt werden.
Abbildung 49: Forte 4 Java Mobile Edition
Die Integrated Developper Environment (IDE) kann den Javadoc16 Code bis zu einem gewissen Grad
automatisieren. Der «Javadoc Generator» lädt alle Felder, Methoden und Klassen in ein Fenster. Die
zur jeweiligen Methoden passenden Tags werden angezeigt und können initialisiert werden. Die
Abbildung 50 zeigt das «Auto Comment Tool». Praktisch ist, dass auf der linken Seite mit einem
grünen Symbol gleich die Korrektheit des Javadoc Codes visualisiert wird.
15
Assistent welcher Schritt für Schritt das Gewünschte erstellt
Java Programme können mit dem Dokumentationsgenerator Javadoc dokumentiert werden. Dieser Generator erstellt aus
dem Javacode Dokumentationen in HTML-Format.
16
- Seite 63 -
Entwicklung
Abbildung 50: Auto Comment Tool der IDE
Leider barg die IDE von Sun auch eine Enttäuschung. Auch sie schaffte es nicht, die Netzwerkklassen
fehlerfrei zu implementieren. (Siehe hierzu den Exkurs im folgenden Kapitel.)
Ein grosser Vorteil der IDE ist jedoch die Generierung der *.prc-Files, welche mit einem einfachen
«Mausklick» erzeugt werden können (siehe Kapitel 3.4.7).
Der Markt für PDA-Entwicklungsumgebungen ist relativ gross und stetig am Wachsen. Die folgende
Aufzählung von Produkten zeigt die wesentlichsten Anbieter von IDEs für J2ME Entwicklungen:
-
Esmertec Jbed: [Esmertec] Esmertec ist eine Schweizer Firma, die eine VM und eine eigene
Entwicklungsumgebung auf dem Markt hat.
IBM J9: [IBM] IBM bietet eine eigene Entwicklungsumgebung, welche mit einer eigenen VM
arbeitet. Es ist geplant, dass in einem späteren «Releases» auch die VM von SUN verwendet
werden kann.
Waba VM: [Waba] Waba ist ein Opensource Projekt für Windows Handhelds und Palms
Forte 4 Java Mobile Edition: [Forte].
Wireless Toolkit: [Wireless] Kompilierungstool von Sun. Dieses Tool erzeugt die *.prc-Files und
kann auch zur Entwicklung von einfacheren Applikationen verwendet werden.
- Seite 64 -
Entwicklung
3.4.2. Exkurs: Netzwerkprobleme in der VM
Zu Beginn konnte keine Verbindung zu einem Servlet hergestellt werden. Die Lösung fand ich erst
nach längerem Probieren und Fragen in Forums. Der Standard Code, um eine Verbindung zu einem
Servlet aufzubauen ist in Abbildung 51 zu sehen. Dieser Code wurde aus einem Beispiel von der
offiziellen J2ME-Seite von Sun kopiert [MIDP-Servlet].
Abbildung 51: Fehler in der VM von SUN
Der rote Pfeil markiert die Ursache der Netzwerkprobleme: Mit dem Befehl os.flush(); wird der
OutputStream «geflusht», d.h. er wird abgeschlossen und gelöscht. Das Löschen dieses Streams
sollte vermeiden, dass gleiche Daten mehrmals verschickt werden. Dies verändert jedoch ungewollt
die Requestparameter und führt zu einem so genannten «Chunked Encoding», bei dem die Daten
«häppchenweise» übermittelt werden. Diese Codierung wurde mit HTTP 1.1 eingeführt, um Daten von
unbestimmter Grösse zu übertragen. Das Problem ist, dass Servlets keine Anfragen in «Chunked
Encoding» verstehen und demzufolge der Tomcat Server keine Verbindung zwischen dem PDA und
dem Servlet aufbauen kann. Im Rahmen der vorliegenden Arbeit wurde das Problem umgangen,
indem der entsprechende Befehl auskommentiert wurde. Es ist anzunehmen, dass SUN diesen Fehler
in der nächsten Version beheben wird.
- Seite 65 -
Entwicklung
3.4.3. User Interface bei einem PDA
Die Fähigkeiten eines grafischen User Interfaces (GUI) sind bei Geräten mit kleinen Displays meist
stark eingeschränkt. Nicht anders ist es bei einem PDA und vor allem auch bei einem Handy. Da VMs
bei mobilen Geräten im Vergleich zu einer herkömmlichen VM redimensioniert werden, ist es nahe
liegend, dass auch die Schnittstelle zum Anwender minimiert wurde. Die Abbildung 52 zeigt das
Klassendiagramm des User Interfaces Klassen der J2ME.
Display
Alert
Form
Displayable
Screen
Canvas
List
TextBox
Abbildung 52: Klassendiagramm des User Interfaces
Ein wichtiger Unterschied ist zwischen der Klasse Screen und der Klasse Canvas zu finden. Ersteres
gilt für sogenannte «High-Level-» und letzteres für das «Low-Level MIDlet User Interface». Mit dem
Low Level User Interface ist es möglich, direkt einzelne Pixels zu setzten, was den Aufwand eines
User Interfaces beträchtlich erhöht. Mit dem High Level Interface lassen sich Applikationen mit einem
aufwendigen GUI schneller und effizienter erstellen. Dafür sind die Möglichkeiten eingeschränkter:
Farbige Darstellungen sind (noch) nicht möglich und einige Elemente, wie z.B. Formulare, sind noch
nicht ausgereift. Da das vorliegende Projekt auf einem High Level User Interface basiert, wird auf die
Möglichkeiten und Restriktionen nun detaillierter eingegangen.
Die Klasse «Form» ist, wie aus Abbildung 52 zu sehen ist, eine Unterklasse (Subklasse) der Klasse
«Screen». Die Klasse «Form» erbt von seiner Superklasse die Möglichkeit mit so genannten
«Commands» umzugehen, welche verwendet werden, um die Applikation zu bedienen. Das Beispiel17
aus Abbildung 53 zeigt den Source Code eines simplen Programms, welches dem Anwender ein
Formular anzeigt. Der Anwender kann in einem Textfeld seinen Namen eingeben und den Button
«Print» klicken. Darauf erscheint auf einem neuen Bildschirm der Name, der zuvor eingegeben wurde.
Siehe hierzu die Abbildung 54.
17
Alle in dieser Dokumentation besprochenen PDA Programme befinden sich auf der beiliegenden CD. Siehe hierzu den
Anhang D
- Seite 66 -
Entwicklung
Abbildung 53: Source Code eines Formulares
Der in Abbildung 53 abgebildete Code zeigt nicht den kompletten Source Code, sondern nur die zwei
entscheidenden Methoden. Die Screenshots des ersten Formulares sind in Abbildung 54 ersichtlich.
Abbildung 54: Screenshot eines
Formulares
Die Abbildung 54 wirft beim Betrachten eine Frage auf.
«Wieso ist der normale Text («Dies ist ein einfaches....») auf
die Mitte zentriert und beginnt nicht in der oberen linken
Ecke?» Die Antwort ist schnell zur Hand: Dies ist ein
Darstellungsfehler der VM-Implementation. Alle Textfelder
beginnen auf dem PDA in der Mitte. Diese Gegebenheit
muss der Anwender wie der Entwickler akzeptieren. Dieser
Fehler ist unumgänglich.
Der Button, der sich unten links im Screenshot befindet,
kann verschiedene Aktionen auslösen. Diese Aktionen
werden im so genannten «CommandListener» behandelt. Im
vorliegenden Projekt regeln diese Kommandos die
Navigation der verschiedenen «Bildschirme».
Ein hilfreicher Vorteil der Sun KVM gegenüber der IBM KVM ist,
dass solche Kommandos automatisch auch über die Optionen
(wie in Abbildung 55 dargestellt) erreichbar sind. Bei der IBM
KVM müssten die Menüs mühsam von Hand programmiert
werden. Bei Kommandos ist wichtig, dass die Klasse, in der sie
verwendet werden, unbedingt der «CommandListener»
implementiert werden muss. Ebenso sollte in jedem Formular der
CommandListener gesetzt werden.
form.setCommandListener(this);
Die obige Codezeile fügt einem Formular den CommandListener
bei. Siehe hierzu auch die Abbildung 53 mit dem Source Code.
Abbildung 55: Screenshot der
Optionen
Wird der Button «Print» betätigt, so erscheint ein neues Formular. In der «startApp()» Methode wurde
das Formular mit dem Namen «form» instanziert. Im Commandlistener wird nach dem Betätigen des
«Print» Buttons ein neues Formular mit dem Namen «result» instanziert und angezeigt. Diesem
Formular wird noch ein «exit» Button beigefügt, um die Applikation zu beenden.
- Seite 67 -
Entwicklung
Die Abbildung 56 zeigt das Result Formular mit dem Namen, der
im Screenshot aus Abbildung 54 eingegeben wurde. Der
erwähnte «Exit»-Button fehlt im abgebildeten Screenshot. Dieser
Button fehlt aber nicht wirklich, er wurde nur nicht gleich definiert.
Die Kommandos lassen sich auf gemäss ihren Aktionen
definieren. Der «Exit»-Button beendet das Programm und der
«Print» Button generiert ein neues Formular. Die KVM von SUN
definiert in dem Sinne folgende Aktionen. Back-, OK-, Cancel-,
Stop- und Screen-Buttons. Unser «Print»-Button ist vom Typ
«Screen» und der «Exit» logischerweise vom Typ «Exit».
Abbildung 56: Screenshot Result
Forms
Buttons vom Typ «Exit» werden nie auf dem Bildschirm
dargestellt, sie werden immer unter dem Menüpunkt «Go»
aufgelistet. Bei den Bildschirmbuttons ergibt sich ein weiteres
Problem: Werden mehr als drei Buttons angemeldet, erscheinen
nur − wohl aus Platzgründen − die ersten drei. Ebenso, wenn die
Buttons eine zu lange Beschriftung haben (mehr als 6 Zeichen),
ist nicht der ganze Beschriftungstext zu lesen. Alle Kommandos
werden aber immer noch in der Menüliste aufgeführt. Die
fehlenden Buttons können jedoch für einige Verwirrung sorgen.
Der aufmerksame Leser fragt sich jetzt wohl, wieso sich im
Source Code ein
Abbildung 57: Screenshot
mit Exit Button
System.out.println("Der eingegebene ....")
befindet (siehe Abbildung 53). Jeder «System.out-Befehl», der
auf dem Emulator ausgeführt wird, wird in ein File geschrieben.
Die Abbildung 58 zeigt das Logfile des Palm Emulators. Die KVM auf einem PDA ignoriert die
«System.out»-Befehle, sie dienen lediglich einer Flusskontrolle auf dem Emulator und können zum
Debugging verwendet werden.
Abbildung 58: STDOUT File vom PDA Emulator
Natürlich bietet das User Interface einer KVM noch mehr als die genannten Formulare und Textfelder.
Es können verschiedene Alarmtypen, Checkboxes, Schieber, Ticker und vieles mehr verwendet
werden. Die Literaturliste im Kapitel 6 kann in diesem Falle weiterhelfen. Ebenso befinden sich auf der
beigelegten CD verschiedene Programmbeispiele.
- Seite 68 -
Entwicklung
3.4.4. Netzwerkverbindungen mit dem PDA
Je kleiner ein Computer und je begrenzter die Speichermöglichkeiten desto wichtiger ist die
Kommunikation mit der Aussenwelt. Im Falle eines PDAs ist eine Kommunikation mit der Aussenwelt
unumgänglich. Der kleine Speicherplatz beschränkt die Funktionsfähigkeit des Gerätes enorm. Eine
Form der Kommunikation mit der Aussenwelt kann die Synchronisation mit einem Computer sein. So
können Daten auf dem Computer gesichert oder ausgelagert werden. Ebenso können neue
Programme installiert werden. Braucht man aber für eine Datensicherung oder für neue Daten immer
den Anschluss an einen Computer, verliert ein mobiles Gerät klar an Mobilität: Datenbezug und
Datensicherung können nur stationär durchgeführt werden, was bestimmt nicht als mobil betrachtet
werden kann. Aus diesem Grunde beinhaltet die KVM Möglichkeiten, mit der Aussenwelt Kontakt
aufzunehmen. Die Vorgehensweise ist denkbar einfach: Mit einem Handy wird die Verbindung zur
Aussenwelt hergestellt. Da die PDAs immer mehr mit den Handys zusammenwachsen, respektive
ineinander integriert werden, ist damit zu rechnen, dass in absehbarer Zeit ein PDA kein externes
Handy mehr verwenden muss, um mit der Aussenwelt zu kommunizieren. Die folgenden Erklärungen
basieren auf der Annahme, dass der PDA mit einem Handy eine Verbindung zu einer Funknetz-Zelle
[Funknetz] aufbauen kann. Die Abbildung 59 illustriert wie der PDA via Handy zum Beispiel auf ein
ISDN-Netz und somit auf das Internet zugreifen kann.
Abbildung 59: Kommunikationsweg Palm
Quelle: [Funknetz]
Der PDA kann via Handy den Kontakt zu Basisstationssystem (BSS) aufnehmen, welches die
Funkversorgung für ein bestimmtes geografisches Gebiet, einer sogenannten Funkzelle, übernimmt.
Das BSS ist meist mit einer Funkverbindung zu einem Mobile-Services Switching Centre (MSC)
verbunden, welche als Vermittlungszentrale funktioniert. Von einer MSC können die Daten an weitere
MSC oder auf das Festnetz geschickt werden.18 Via Festnetz kann dann eine Verbindung zu einem
Internetprovider aufgebaut werden und somit die Verbindung zum Internet hergestellt werden.
Soviel zum technischen Ablauf einer Kommunikationsverbindung zwischen einem PDA und dem
Internet. Nun wieder zu den Netzwerkfähigkeiten des PDAs. Die KVM bietet eine Vielzahl von
Protokollen19, mit denen eine Kommunikation aufgebaut werden kann. Das einzige Protokoll, bei
welchem garantiert ist, dass es auf jedem KVM Gerät problemlos funktioniert, ist das Hypertext
18
19
Weitere Informationen zu Mobilfunk können unter [Tannenbaum 2000] bezogen werden
Datagramms, Socket, Hypertext Transfer Protocol (HTTP)
- Seite 69 -
Entwicklung
Transfer Protocol20 (HTTP). HTTP wird in der Request for Comments 2616 (siehe [RFC zu HTTP])
sowie in Kapitel 2.4.1 beschrieben. Normalerweise sendet ein HTTP Server Hypertext Markup
Language (HTML) Seiten an seinen Client. Das Problem ist nun, dass ein PDA keinen Browser
besitzt, der dieses HTML korrekt interpretieren kann. Dies ist allerdings ein Problem, das das
vorliegende Projekt nicht tangiert, da die Programme für Server und Client selbst erstellt werden. Das
Programm des Servers muss die notwendigen Daten lesbar an den PDA schicken können. Das
Programm aus Abbildung 60 ist nichts anderes als ein Client, welcher ein Servlet auf einem Server
aufruft und Daten vom Servlet empfängt.
Abbildung 60: Beispiel einer Internetverbindung
Das Beispiel aus Abbildung 60 ist nur ein Ausschnitt aus dem ConnectionMIDlet. Die Methode
«connectServlet» öffnet eine Verbindung zum Servlet «HelloPDA» und sendet eine einfache Anfrage
an das Servlet. Diese einfache Anfrage beinhaltet keine Parameter. Dadurch wird im Servlet eine
Methode aufgerufen, welche einen einfachen Text retourniert. Dieser Text wird vom PDA empfangen
und in einer Textbox angezeigt.
Abbildung 61: Screenshots der Internetverbindung
Auf der linken Seite der Abbildung 61 ist der Eingabebildschirm zu sehen und auf der rechten Seite
sind die empfangenen Daten in der Textbox sichtbar. Der Verbindungsaufbau ist ziemlich einfach.
Die Abbildung 60 zeigt die Methode, welche die Verbindung zum Servlet aufbaut, auf seine Antwort
wartet und die Antwort einem String zuweist. Zuerst wird eine HttpConnection mit einem Parameter
- Seite 70 -
Entwicklung
instanziert. Dieser Parameter ist die Unified Ressource Location (URL) und gibt an, wo das Servlet zu
finden ist. In einem weiteren Schritt wird der Request (siehe Kapitel 2.4) definiert. In diesem Falle
handelt es sich um einen «GET» Request. Weiter müssen noch einige so genannte Properties gesetzt
werden. Die Properties geben Auskunft über die Codierung des Inhaltes, die Art des Inhaltes, den
Client sowie die Sprache (wegen Sonderzeichen).
Client
Server
GET Request
Antwortstream
Abbildung 62: Kommunikationsablauf
Die Daten werden in so genannten Byte-Streams (OutputStream und InputStream) verschickt. Der
Kommunikationsablauf ist in Abbildung 62 zu sehen.
3.4.5. Persistente Datenspeicherung auf dem PDA
Damit Daten auf einem PDA auch gespeichert werden, wenn dieser ausgeschaltet wird, darf ein
Konzept zur persistenten Datenspeicherung in der KVM nicht fehlen. Leider kann J2ME keine internen
Datenbanken ansprechen. So könnte eine Speicherung elegant gelöst werden. Dies hätte allerdings
zur Folge, dass das Programm gerätespezifisch würde. Ebenso kann J2ME keine Systemdaten wie
zum Beispiel Einträge aus dem Adressbuch lesen. Die KVM von SUN löste dieses Problem, indem
eine eigene Datenbank mit Java auf dem PDA implementiert werden kann. Dieses Konzept nennt sich
«RecordStore». Bei den «RecordStores» handelt es sich um Datensätze, die persistent abgelegt
werden. Das Beispiel aus Abbildung 63 zeigt ein einfaches Programm, das Namen speichern kann.
Abbildung 63: persistente Speicherung
Der Name des «RecordStores») ist in diesem Beispiel «NAMEN» (siehe Abbildung 63). Besteht dieser
RecordStore zur Startzeit noch nicht, wird der «RecordStore» instanziert. Die auf den Namen folgende
boolsche Variable regelt diese Instanzierung. Ist diese Variable auf «false» gesetzt und der
«RecordStore» existiert noch nicht, so wird eine «RecordStoreException» ausgelöst. Die Daten
werden mit einem «DataOutputStream» in den «RecordStore» geschrieben. Das Schreiben von Daten
in den Speicher ergibt grundsätzlich keine Probleme, das Löschen und Lesen birgt in diesem Fall aber
einige Schwierigkeiten. Sobald gewisse Records gelöscht werden, können beim Lesen und Schreiben
Fehler auftauchen. Die verschiedenen Records werden mit so genannten Indizes referenziert. Wird
ein Record gelöscht, so bleibt der Index bestehen, enthält aber keine Daten mehr. Die Datenbank
«RecordStore» kümmert sich nicht um die referentielle Integrität [Meier 2001, Seite 44] der Daten.
Wird der leere Index zu einem später Zeitpunkt gelesen, wird eine «Exception» ausgelöst. Dieses
- Seite 71 -
Entwicklung
Problem kann gelöst werden, indem immer ein Vector mit den gültigen Indizes mitgeführt wird. Ein
Beispiel eines solchen Vectors zeigt die Abbildung 64. Zu beachten ist, dass die IDs des
«RecordStores» bei «1» beginnen und nicht bei «0», wie es zum Beispiel bei Vektoren üblich ist.
Index
RecordStore
6
Daten 5
Vector
5
4
3
Daten 3
Daten 2
2
1
Daten 0
Index
6
3
4
2
3
1
1
0
Abbildung 64: Hilfsvektor für den Speicherzugriff
Mit Hilfe eines solchen Vektors können die Speicherzugriffe ohne Fehler erfolgen. Beim Schreiben wie
beim Löschen muss einfach darauf geachtet werden, dass der Hilfsvektor aktualisiert wird. Der Vektor
wurde im vorliegenden Projekt mit einer Methode ständig neu generiert. Die Abbildung 65 zeigt ein
Codefragment aus der Methode «getIDs()»21.
Abbildung 65: Generierung des Hilfsvektors
Mit einem «RecordEnumerator» wird über den «RecordStore» iteriert, bei jedem gültigen Eintrag wird
die ID des Records in den Hilfsvektor geschrieben.
3.4.6. Die Navigation in P2W
Die Abbildung 66 zeigt die Navigation in der P2W-Applikation für den Palm. In der Abbildung wurden
die Bildschirme, die mit dem Server verbunden sind, grau hinterlegt. Wird ein grauer Kasten betreten,
wird der User mit dem Server verbunden, verlässt er diesen, so meldet er sich vom System ab. Die
Bezeichnung «sel» versteht sich als Selektierung eines Elementes aus einer Liste. Generell kann
gesagt werden, dass die meisten Bildschirme aus Listen oder sogenannten Forms bestehen. Die
Merkmale der Listen sind die selektierbaren Elemente in der oberen Bildschirmhälfte, die mit einem
beginnen. Bei diesen Aufträgen ist immer nur die erste Seite dargestellt. Die Aktion befindet sich
immer auf der letzten Seite und ist über einen «Pull Down» Menübefehl erreichbar (siehe Kapitel 4).
Die verschiedenen «Pull Down» Optionen wie «Info», «Copyright» und «Exit» wurden der
Übersichtlichkeit halber nicht dargestellt. Die Pfeile aus der Abbildung 66 stellen den so genannten
«Navigationsweg» dar, die Beschriftung gibt Auskunft über die Art des Befehls.
21
Siehe hierzu die Javadoc auf der beiliegenden CD
- Seite 72 -
Entwicklung
Abbildung 66: Navigation von P2W
- Seite 73 -
Entwicklung
3.4.7. Programme auf einem Palm PDA
Die letzten Unterkapitel erklärten, wie Java Programme für einen PDA erstellt werden können. Die
Frage stellt sich nun, ob diese Programme wie ein normales Java Programm kompiliert werden und
die *.class-Datei auf den Palm geladen und so gestartet werden kann?
Die Antwort auf diese Frage muss verneint werden. Ganz so einfach wie bei einem normalen JavaProgramm ist dieser Vorgang leider nicht. Palmprogramme haben die Endung *.prc oder *.pdb, wobei
sich letzteres auf palmspezifische Datenbanken bezieht. Aus einem Programm sollte nun ein File
generiert werden, welches das nötige Format aufweist. Mit der Entwicklungsumgebung von Forte
können *.prc Files direkt aus dem Javacode generiert werden (siehe Kapitel 3.4.1).
Sun verwendet für diesen Kompilierungsvorgang das Java-Programm «MakePalmApp». Dieses
Programm erzeugt eine palmkonforme Applikation und wird auch von verschiedenen anderen
Entwicklungsumgebungen wie zum Beispiel «Wireless Toolkit» genutzt.
Forte kompiliert in einem ersten Schritt das Java-Programm in ein *.class-File. Darauf folgt die so
genannte «Preferifizierung», welche dem Programm Daten hinzufügt, die das Ausführen des
Programmes erleichtern. Dieser Vorgang hat zur Folge, dass die *.class-Dateien rund 15 % grösser
werden. Danach wird das Programm mittels einem «Packager“ in ein *.jar-Archiv gepackt. Dieses
*.jar-Archiv wird mit einem Konverter in ein *.prc-File konvertiert und dieses kann dann auf den PDA
geladen und gestartet werden. Die Abbildung 67 zeigt den Kompilierungsvorgang. Für den Anwender
von Forte sind die einzelnen Schritte nicht ersichtlich. Der Anwender wählt in der IDE «Execute» und
aus dem gewünschten Java Programm wird ein PDA-Programm generiert. Forte bietet auch die
Möglichkeit, Java-Programme in andere Formate zu kompilieren, so dass die Applikationen auch auf
Handys funktionieren. Siehe hierzu das folgende Unterkapitel.
Ein Nachteil von Java auf PDAs ist die zusätzliche VM. Die VM muss separat auf den PDA geladen
werden. Kritiker von J2ME sehen dies als einen beträchtlichen Nachteil von J2ME und kritisieren
ebenso den Geschwindigkeitsverlust, der durch die VM entsteht.
MIDlet.java
Kompilieren
Auf das Endgerät laden
MIDlet.class
MIDlet.prc
konvertieren
Preverifizieren
Package
MIDlet.class
MIDlet.jar
Abbildung 67: Kompilierungsvorgang
- Seite 74 -
Entwicklung
3.4.8. Spezialitäten der Applikation
Ein durchaus erfreulicher Aspekt dieses Projektes ist, dass die Applikation auf allen «Java-fähigen»
Handys verwendbar ist. In diesem Falle kann man von echter Maschinenunabhängigkeit sprechen.
Durch das kleinere Display des Handys ist die Darstellung jedoch um ein Vielfaches schlechter als auf
einem PDA. Ansonsten zeigt J2ME seine Stärken und das Potential zur Programmiersprache für
mobile Geräte. Hier kommt eine weitere Stärke der Entwicklungsumgebung von Forte dazu. Die
erstellten Java Programme lassen sich problemlos für andere Endgeräte verwenden. Der Anwender
kann in der IDE den gewünschten Gerätetyp auswählen und die IDE kompiliert, verifiziert und
generiert das Programm für den ausgewählten Gerätetyp. Abbildung 68 zeigt die Applikation P2W auf
verschiedenen Geräten.
Abbildung 68: P2W auf Handys
In der Abbildung 68 ist auf der linken Seite ein Handy mit einem farbigen und «normalen» Display zu
sehen. In der Mitte ein Handy mit minimalen Anforderungen punkto Displaygrösse, Speicher und
Eingabefunktionen. Rechts ist das «Java-fähige» Motorola i85s dargestellt. Auf allen drei
Mobiltelefonen funktioniert die P2W-Applikation einwandfrei.
- Seite 75 -
Entwicklung
3.4.9. Simulationen mit dem Palm OS Emulator
Der Palm OS Emulator (POSE) ist ein Hard- und Software Emulator22 für PC und MacintoshPlattformen. Vorteile eines solchen Emulators sind (Abbildung 69):
-
Vor dem Kauf können verschiedene Palm Modelle getestet und betrachtet werden.
Fremde und selbst erstellte Programme können gestestet werden.
Es können saubere Screenshots gemacht werden.
Es bestehen Debug23 Möglichkeiten.
Die IDE (Forte) kann die entwickelte Software direkt auf den Emulator laden. Der Emulator wird
danach automatisch gestartet.
Der Emulator bietet dem Anwender dieselben Funktionen wie ein realer Palm. Anstelle eines Stiftes
kann die Maus verwendet werden. Die Graffiti24 Funktion kann ebenso genutzt werden. Alle
Hardwarebuttons können analog zum realen Gerät verwendet werden.
Abbildung 69: Palm OS Emulator
Die Downloadinformationen, Installationshinweise sowie Konfigurationen werden im Anhang B
beschrieben. Ist der POSE einmal installiert, sollte das Betriebssystem des gewünschten PDA's
installiert werden. Zu diesem Zweck ist dem Emulator das kleine Program «ROM Transfer.prc»
beigelegt. Mit diesem Programm kann das lizensierte Betriebsystem des PalmOS ROM auf den POSE
geladen werden. Das entsprechende ROM ist dem Emulator nicht beigelegt25, da es ein lizenziertes
Produkt ist.
22
Dieser Emulator kann unter [Palm] gratis heruntergeladen werden.
Diese Debugmöglichkeiten sind jedoch noch nicht so ausgereift. Respektive kaum brauchbar. Die einzige
«Debugmöglichkeit» ist der Befehl «System.out.println()».
24
Schreiben mit dem Stift auf dem Touchscreen.
25
Es ist jedoch kein Problem, verschiedene Betriebssysteme (ROM Dateien) auf dem Internet zu finden. Allerdings muss
gesagt werden, dass die Weitergabe und der Bezug über das Internet von ROM Dateien eine illegale Aktion darstellt. Die
Weitergabe von ROM Dateien ist nur Palm Inc. gestattet.
23
- Seite 76 -
Entwicklung
3.4.10. Mocha PPP
Die dänische Softwarefirma MochaSoft [MochaSoft] entwickelte eine praktische Software, damit ein
PDA mit dem Internet verbunden werden kann, ohne dass dabei ein Mobiltelefon verwendet werden
muss. Das Programm «Mochasoft PPP» simuliert dem PDA ein Modem. Mit diesem emulierten
Modem kann ein PDA mit dem Internet kommunizieren. Das Programm ist für alle gängigen
Plattformen erhältlich. Leider ist das Programm nicht «PDA-Produkt-übergreifend», es muss für die
verschiedenen PDAs immer der jeweilige Emulator verwendet werden. Eine weitere Einschränkung
des Programms ist, dass die Verbindung zum PC zwingend ein serielles Kabel benötigt. Gemäss
Angaben von Mocha Soft sollte in der nächsten Zeit eine Version erscheinen, die auch USB
unterstützt. Die Abbildung 70 zeigt den schematischen Aufbau von Mocha PPP. Der Computer
emuliert für den PDA ein Modem, mit dem auf das Internet zugegriffen werden kann.
Abbildung 70: Anwendung von Mocha PPP
Installationshinweise und Konfigurationen befinden sich in Anhang C oder unter [MochaSoft].
- Seite 77 -
Entwicklung
3.5. Implementation Server
3.5.1. Serverentwicklung mit Websphere Studio
Die Serverentwicklung wurde, im Gegensatz zur Clientimplementation, auf einem Produkt von IBM
erstellt. Das Websphere Studio (WS) ist eine hilfreiche Umgebung zur Entwicklung von Java Server
Pages (JSP), Servlets, Java Beans und HTML Seiten.
Mit dem WS können HTML- und JSP-Seiten mit einfachen Mitteln erstellt werden. Tabellen, Formulare
und JSP-Include Tags können mit einem Wizzard erstellt werden. Ein Hilfsmittel zur Erstellung von
JSP-Seiten ist der JSP-Compiler, welcher ein zeitraubendes Testen im Browser erspart. Ein weiteres
Feature im WS ist die Ansicht der Beziehungen unter den verschiedenen HTML-, JSP- und Java-Files.
Abbildung 71 zeigt die Beziehungen der Administrationskonsole.
Abbildung 71: Websphere Studio
Da die Administration mit JSP-Seiten und Java Beans realisiert wurde, konnte die Unterstützung von
WS voll ausgeschöpft werden. Im WS kann eine direkte Verbindung zu einem beliebigen Server
erstellt werden. Diese Verbindung ermöglicht, dass erstellte Files nach einer Voransicht direkt auf dem
Server publiziert werden können. Die entsprechenden Files werden in den korrekten Ordner des
Servers kopiert. Voraussetzung ist natürlich eine richtige Konfiguration des Servers und der
Verbindung. Der komplette Java Code (Java Beans und das Servlet) wurde ebenfalls im WS erstellt.
Das WS verwendet für Java Code nicht einen eigenen Editor; dieser kann frei gewählt werden. Leider
konnte das WS den Javadoc Code nicht automatisch generieren, dies musste via Dos-Box erledigt
werden. Ein weiteres Problem ist die Formatierung (Einrücken) des JSP-Codes, welche auch nicht
automatisiert wurde. Das WS ist ein älteres Produkt, welches im Frühjahr 2002 durch das Websphere
Studio Application Developper (WSAD) abgelöst wurde und die Features von Visual Age 4 Java und
des WS vereinte. WSAD wäre für diese Entwicklung sicher passender gewesen, konnte aber wegen
den mangelnden Ressourcen des Laptops nicht verwendet werden (siehe Kapitel 5).
- Seite 78 -
Entwicklung
3.5.2. Access-Datenbank (Administration)
Nach einer ersten Analyse war man sich einig, dass für die Administration die bereits bestehende
Ascom Oracle-Datenbank verwendet werden sollte. Diese Lösung wäre vor allem erstrebenswert
gewesen, wenn die Applikation einmal verwendet werden würde. Da dies allerdings nicht eintreten
sollte, entschied man sich für eine einfache und lokal gehaltene Access Datenbank (siehe Kapitel 5).
Die Unterschiede, in der Verwendung einer Access oder Oracle Datenbank, sind nicht gravierend. Die
Access-Datenbank für die Userverwaltung besteht aus einer einzigen Tabelle und einigen Einträgen.
Abbildung 72 zeigt diese Tabelle.
Abbildung 72: Userverwaltung
Die Benutzerverwaltung hätte durch eine Erweiterung der vorhandenen Datenbank der Abteilung
Human Ressource umgesetzt werden können. Da für die Applikation P2W jedoch nur wenige Attribute
benötigt werden, und auf der HR-Datenbank viele sensible Daten zugänglich sind, wurde eine
Anbindung nicht in Erwägung gezogen.
Damit der Server die Datenbank findet, muss in der Systemadministration diese Datenbank
angemeldet werden. Der Vorgang wird im Anhang A beschrieben. Die Verbindung zur AccessDatenbank wird in Java über eine JDBC-ODBC-Bridge hergestellt. Die «Java Database Connectivity»
(JDBC) macht eine «Open Database Connectivity» (ODBC) zur entsprechenden Datenbank. Diese
Verbindung wird «JDBC-ODBC-Bridge» genannt.
Der Datenbanktreiber «sun.jdbc.odbc.JdbcOdbcDriver» ist die effektive Treiberklasse26, die Java
verwendet, um eine Verbindung zur Datenbank aufzubauen. Der «dbusername» und das «dbpass»
aus Abbildung 73 sind die Zugangsdaten zur Datenbank. Diese Parameter wurden in der Datenbank
definiert (siehe Anhang A). Um die «Connection» aufzubauen, wird die Methode «getDBConnection()»
aufgerufen (siehe Abbildung 74). Diese gibt ein «Connection Objekt» zurück und das Objekt stellt die
Verbindung zur Datenbank her.
Abbildung 73: Datenbankverbindung
Wie aus der Methode von Abbildung 73 (rot markiert) ersichtlich ist, werden vier Parameter verwendet.
Diese Parameter sind in der Tabelle 15 beschrieben.
26
Dieser Treiber kann von Sun unter [JDBC-Bridge] gratis bezogen werden
- Seite 79 -
Entwicklung
Parameter für die Datenbank Connection
Wert
dbname
jdbc:odbc:PDA_USER
dbdriver
sun.jdbc.odbc.JdbcOdbcDriver
dbusername
user
dbpass
user
Tabelle 15: Parameter für die Datenbankverbindung
Die Werte der beschriebenen Parameter werden beim Initialisierungsvorgang aus einem XML-File
gelesen. Sie können zu jeder beliebigen Zeit einer anderen Situation angepasst werden. Einzige
Voraussetzung ist, dass der Server neu gestartet wird, was zur Folge hat, dass das Konfigurationsfile
neu eingelesen wird. Der Datenbankname ist «PDA_USER» (siehe Anhang A). Das Präfix
«jdbc:odbc:» bezeichnet die Art, mit der auf die Datenbank zugegriffen wird. Hier über die «JDBCODBC-Bridge».
Ist eine Verbindung zu Datenbank aufgebaut, kann mit der «Standard Query Language» (SQL) eine
Abfrage vorbereitet werden. Diese Abfrage kann dann auf die Datenbankverbindung angewendet
werden und die erhaltenen Daten können entsprechend gespeichert werden. Die Abbildung 74 zeigt
ein Codefragment, das eine solche Abfrage durchführt. Die Verbindung zur Datenbank wird mit der
vorher beschriebenen Methode «getDBConnection()» durchgeführt (grün markiert).
Abbildung 74: SQL Abfrage
Betrachten wir Abbildung 74, so sehen wir, wie in einem ersten Schritt der Verbindung gemeldet wird,
dass eine Abfrage vorbereitet werden soll (1.). Im zweiten Schritt (2.) wird die Abfrage ausgeführt und
in ein so genanntes «Resultset» geschrieben. Über dieses «Resultset» kann iteriert und die Daten
können einem Vectorelement zugeordnet werden.
- Seite 80 -
Entwicklung
3.5.3. Domino Notes-Datenbank
Die Daten des WfMS der Ascom Informatik sind in einer Domino Notes-Datenbank untergebracht.
Domino Notes-Datenbanken unterscheiden sich von herkömmlichen Datenbanken. Die Daten in
relationalen Datenbanken wie Access und Oracle sind meist fix strukturiert. Jedes Attribut hat einen
klar definierten Datentyp (z.B. String mit der Länge 64). Die Daten in einer Domino-Datenbank
erscheinen unstrukturiert. Die Felder können verschiedene Datentypen aufweisen. Text, formatierter
Text, Grafiken, Musik, Videos, usw. Daten können in verschiedenen Ansichten − so genannten Views
− betrachtet werden. Diese Views können mehrere Dokumente beinhalten. Die Domino Daten werden
in einem so genannten Notes Storage File (NSF) gespeichert. Aus diesem Grunde haben die Domino
Datenbanken die Endungen *.nsf.
Der Ablauf einer Domino-Datenbankabfrage erinnert im weitesten Sinne an einen Zugriff auf eine
Access Datenbank. In erster Linie muss eine Verbindung zur Datenbank aufgebaut werden. Nach
erfolgreicher Verbindung muss die Datenbank angegeben werden und danach kann die Abfrage
gestartet und die Daten ausgewertet werden. Der Unterschied besteht darin, dass nicht einzelne
Felder, sondern so genannten Views abgefragt werden. In den Views wird dann Dokument um
Dokument durchgegangen und die gesuchten Dokumentfelder herausgelesen. Um eine Verbindung
zu der Domino-Datenbank aufzubauen, muss das Notes spezifische Java Application Programming
Interface (API) importiert werden. Das «NCSO.jar»27 muss im Classpath des Servers referenziert sein.
Die Datenbankanbindung mit Java zu Domino wird unter anderem im Buch [Muhs 2003] ausführlich
besprochen. Lotus Notes bietet ein hilfreiches und downloadbares Online [9] Manual an. Die
Abbildung 72 zeigt den Verbindungsaufbau und die Vorbereitung zur Datenabfrage.
Abbildung 75: Verbindungsaufbau zu Domino Datenbanken
Die Methode aus Abbildung 75 beinhaltet verschiedene Parameter, welche zuerst erklärt werden. Die
rot markierten Parameter werden aus dem XML-Konfigurationsfile gelesen. Dies ermöglicht eine
gewisse Flexibilität in Bezug auf das WfMS. Der Ort des Servers sowie der Datenbankname können
schnell und einfach angepasst werden. Ändert allerdings die Struktur im WfMS, so ist eine Änderung
im Source Code unumgänglich. Die häufigsten Änderungsmöglichkeiten sind mit diesen zwei
Parametern allerdings abgedeckt. Die Tabelle 16 zeigt die rot markierten Parameter mit ihren Werten.
Parametername
host
dbname
loginname
pass
Wert
SrvDev
DevCorner/NISESA/PDATEST_rac_ord.nsf
nisesa
*******
Tabelle 16: Verbindungsparameter zum WfMS
27
Die notwendigen APIs befinden sich auf der beigelegten CD
- Seite 81 -
Entwicklung
Da in diesem Projekt auf ein eigenes WfMS (Kopie des Originals) zugegriffen wird, muss mit dem
persönlichen Username auf die Datenbank zugegriffen werden. Für ein Projekt im vorliegenden
Rahmen ergab es keinen Sinn, einen globalen allgemeinen User neu zu definieren. Möchte die
Applikation tatsächlich verwendet werden, sollte man auf alle Fälle einen globalen User erfassen. Ein
globaler User bietet den Vorteil, dass für eine Datenbankverbindung zum WfMS nicht das persönliche
Passwort verwendet werden muss und die Authentifizierung des Users zu einem späteren Zeitpunkt
und losgelöst von einer Verbindung zur Datenbank durchgeführt werden kann.
Um auf die Domino-Datenbank zuzugreifen, muss zuerst eine Session kreiert werden. Dies wird in
Abbildung 75 an der gelb markierten Stelle umgesetzt. Der Parameter «IOR» ist nichts anderes als
eine 32-stellige Zahl, die den Host referenziert. Mit der Session wird die Datenbank verbunden (grün
markiert). Mit «getView()» wird die notwendige Ansicht (View) auf die Datenbank aufgerufen (braun).
Um über diese View zu iterieren, muss eine Art Enumerater gebildet werden (blau). Aus diesem
Enumerater wird das erste Element bezogen (violett), und anhand dieses Elements kann auf die
einzelnen Felder zugegriffen werden. Dieses Element beinhaltet nun die verschiedenen Dokumente.
In der Abbildung 76 ist der NotesClient abgebildet, welcher die verschiedenen Dokumente zu Beginn
der While-Schlaufe darstellt. Die jeweiligen Überschriften stellen Kategorien dar, welche auch noch
speziell selektiert werden müssen, da nicht alle Daten für diese Applikation verwendet werden.
Abbildung 76: Die verschiedenen Kategorien im WfMS
Die Zugehörigkeit zu diesen Kategorien wird zu Beginn der While-Schlaufe überprüft, um die
entsprechenden Dokumente herauszufiltern. Aus den Dokumenten werden wiederum die Feldinhalte
herausgelesen und in einer Variablen oder einem Vektor zwischengespeichert. Die einzelnen
Feldnamen können im Notes Client wie in Abbildung 77 über die Dokumenteigenschaften
herausgefunden werden.
- Seite 82 -
Entwicklung
Abbildung 77: Eigenschaften eines Notes Dokumentes
Der gelb markierte Eintrag in Abbildung 77 ist der Feldname und der rot markierte ist der Wert des
Feldes. Wichtig bei den Verbindungen zu einer Domino Notes-Datenbank ist, dass die Verbindung
nach einer Abfrage jedes Mal geschlossen wird28.
Jedes Dokument hat eine eindeutige ID. Diese ID wird in der Domino Notes-Datenbank «UNID»
genannt. Mit dieser ID kann direkt auf ein Notes Dokument zugegriffen werden. Diese Referenzierung
erleichtert, sofern die «UNID» bekannt ist, das Schreiben von Daten. Beim Lesen der Daten wird über
die Dokumente iteriert, um die UNID herauszufinden. Dies erleichtert die darauf folgenden
Schreibzugriffe, bei denen die UNID bekannt ist.
Nachfolgend in Tabelle 17 eine Übersicht der verwendeten Software und deren Versionen:
Programm
Version
Forte 4 Mobile Edition
Palm OS Emulator (POSE)
Tomcat Server
WebSphere Studio
Access
Java Developpment Kit (jdk)
Lotus Notes
Lotus Notes Designer
Bezogen von
[Forte]
[Palm]
[Tomcat]
Ascom Informatik
Ascom Informatik
[Java Dev]
Ascom Informatik
Ascom Informatik
Tabelle 17: Verwendete Software
28
Die Verbindungen zur Domino Notes-Datenbank müssen nach jeder Abfrage sauber geschlossen werden, um nicht die
maximale Anzahl offener Verbindungen zu überschreiten. Falls dies beim Testen der Software trotzdem vorkommt, muss auf
den Timeout der bestehenden Verbindungen gewartet werden, da der Datenbankserver weitere Verbindungen ablehnt.
- Seite 83 -
Inbetriebnahme und Installation
4. Inbetriebnahme und Installation
Dieses Kapitel behandelt die Inbetriebnahme und Installation der in diesem Projekt erstellten
Komponenten. Die Anleitung soll Schritt für Schritt nachvollziehbar sein. Um die volle Funktionalität
der Applikation P2W testen zu können, ist eine Verbindung zum WfMS der Ascom nötig. In der
Applikation sind jedoch drei kleine Beispiele beigelegt, die auch ohne direkte Verbindung mit dem
WfMS getestet werden können.
Die folgenden Erklärungen beziehen sich auf Microsoft Windows Betriebssysteme. Wird ein anderes
Betriebssystem verwendet, sollte für die Installation die Homepage der Hersteller kontaktiert werden.
4.1. Server
Damit der PDA mit dem WfMS der Ascom verbunden werden kann, ist ein Webserver notwendig, der
die vom PDA kommenden Befehle weiterleitet (siehe Kapitel 3.3.1). Diese Einheit wurde in Form eines
Servlets realisiert. Dieses Servlet wurde in einer lokalen Tomcat Umgebung getestet. In der
Produktionsumgebung ist es ebenfalls ein Tomcat Application Server gewesen.
Bekanntester Server ist der Apache-Webserver, welcher von der Apache Software Foundation (ASF)
entwickelt wurde. Dieser Webserver hatte allerdings den Nachteil, dass serverseitig keine Java
Programme ausführbar waren. Im Rahmen des Jakarta-Projekts wurde der Servlet Container
«Tomcat» entwickelt. Mit einem von der ASF entwickelten Protokoll liess sich der Apache Webserver
mit dem Tomcat Servlet Container verbinden. Dieses Protokoll nennt sich «Apache JServ Protokoll»
(AJP). Auf Grund der URL-Struktur konnten Anfragen an den Servlet-Container weitergeleitet werden.
Dies ermöglicht eine flexible Handhabung von serverseitigen Java Programmen. Das Jakarta Projekt
wuchs in den letzten Jahren und passte sich den Anforderungen der Informatik an. «Catalina» war das
Resultat dieses Prozesses. «Catalina» ist ein Mini-Application-Server, der aus einem ServletContainer, einem JSP-Compiler und einem Webserver besteht. Die Versionen 4.X29 von Tomcat
beruhen auf Catalina und benötigen daher keinen Apache Webserver mehr. Im vorliegenden Projekt
wurde mit einem solchen Tomcat Server gearbeitet.
4.1.1. Tomcat Server
Vor der Installation eines Tomcat-Servers muss ein Java Development Kit (JDK) installiert werden. Für
das vorliegende Projekt wurde JDK 1.4.0. eingesetzt. Es ist empfehlenswert, dass die «BinaryVersion» des Servers bezogen wird. Diese kann einfach entpackt und mit der «Setup-Funktion»
installiert werden. So kann das Kompilieren des Servers umgangen werden.
Sind JDK und der Tomcat installiert, müssen die Systemvariablen angepasst werden. Die
Systemvariablen findet man unter «Start / Settings / Control Panel / System Properties». Dort wählt
man «Environment» (Umgebung) aus. Jetzt können die notwendigen Umgebungsvariablen definiert
werden.
Die notwendigen Umgebungsvariablen sind in Tabelle 18 aufgelistet:
Variablenname
Wert
CATALINA_HOME
Installationspfad des Tomcat Servers
JAVA_HOME
Installationspfad des Java Development Kits
Tabelle 18: Umgebungsvariablen
29
Die früheren Tomcat Versionen benötigten immer noch einen Apache Server.
- Seite 84 -
Ist dies erledigt, ist die Installation des Tomcat Servers beendet. Der Server kann unter dem
Menüpunkt Programme gestartet werden. Mit einem Browser kann seine Funktionalität getestet
werden. Wird im Browser die URL http://localhost:8080/index.html eingegeben, erscheint die Startseite
vom Tomcat.
4.1.2. Konfiguration des Tomcat Servers
Da die P2W-Applikation als Servlet läuft, muss dieses beim Server «angemeldet» werden. Ebenso
muss dem Server gesagt werden, wie das Servlet angesprochen wird und wie der Klassennamen des
gewünschten Servlets lautet. Dies wird im File «web.xml» gemacht. Das File muss gemäss Abbildung
78 erweitert werden.
Abbildung 78: Konfiguration mit dem web.xml
Die Erweiterung des «web.xml» wird bei einem Neustart des Tomcats mitberücksichtigt. So kann der
Server nun auch das entsprechende Servlet finden. Das Testprogramm für den PDA verwendet das
Servlet «HelloPDA», dieses sollte ebenfalls wie in Abbildung 78 angemeldet werden. Die Servlets
müssen sich aber in der gewünschten Webumgebung des Tomcats befinden. Die kompilierten
Servlets sollten sich im Pfad «.../Apache Tomcat 4.0/webapps/ROOT/Web-inf/classes» befinden.
Anstelle des Verzeichnisses «ROOT» kann natürlich die eigene Webapplikation stehen. Dies würde
allerdings eine aufwendigere Konfigurationsprozedur verlangen. Die restlichen, kompilierten JavaProgramme sollten ebenfalls in diesen Ordner kopiert werden.
4.1.3. Notwendige Java APIs
Der Server nimmt Verbindung zm WfMS der Ascom Informatik auf. Dieses ist bekanntlich in einer
Notes Datenbank untergebracht. Verbindungen zu Notes-Datenbanken sind im Java 2 Standard
Edition (J2SE) nicht integriert. Aus diesem Grund muss das entsprechende Java Application
Programming Interface (API) dem Server hinzugefügt werden. Das Java Archiv «Notes.jar» und
«NCSO.jar» soll in den Ordner «.../Apache Tomcat 4.0/lib» kopiert werden. In diesem Ordner befinden
sich Java-Archive, die beim Start des Tomcats in seine Umgebung geladen werden. Normalerweise
sollten die Pfade der Java Archive im «Classpath» referenziert werden, dieser wird aber vom Tomcat
ignoriert. Damit das XML-Konfigurationsfile eingelesen werden kann, benötigt der Tomcat noch die
beiden XML-Archive «xerces.jar» und «xalan.jar» Diese müssen in denselben Pfad kopiert werden.
- Seite 85 -
4.1.4. Filestruktur auf dem Server
Damit bei der Installation des Servers keine Komplikationen auftreten, soll dieselbe Filestruktur wie in
Abbildung 79 erstellt werden.
Abbildung 79: File Struktur auf dem Server
4.1.5. Administrationskonsole
Wurden die obigen Schritte erfolgreich durchgeführt, steht einem ersten Test nichts mehr im Wege.
Bevor die Administrationskonsole allerdings gestartet wird, soll die Datenbank gemäss dem Anhang A
konfiguriert werden. Sind alle Java Server Pages Files und die kompilierten Java Klassen im richtigen
Ordner abgelegt, wird die Konsole einwandfrei arbeiten. Der Administrator kann sich mit dem
Usernamen «Admin» und dem Passwort «admin» beim System anmelden. Es wird empfohlen, dass
das Initialisierungspasswort sofort in ein beliebiges Passwort geändert wird.
Ist
der
Tomcat
Server
gestartet,
so
kann
die
Konsole
über
die
URL
«http://<rechnername>:8080/jsp/start.jsp» gestartet werden. Abbildung 80 zeigt die Konsole.
- Seite 86 -
Abbildung 80: Administrationskonsole
Die Administrationskonsole bietet dem Administrator die Möglichkeit, neue User zu erfassen, diese zu
editieren, zu sperren/entsperren und zu löschen.
4.1.6. Konfigurationsfile
Konfigurationsfiles mit XML haben den Vorteil, dass sie nicht auf dem gleichen Rechner vorhanden
sein müssen wie der zu konfigurierende Server. Ebenso ist das XML File bezüglich des
Betriebssystems unabhängig. Aus diesem Grund wurde für das vorliegende Projekt diese Methode
verwendet. Das XML-File wird in der Initialisierungsphase des Servlets mit Java eingelesen und die
Parameter werden für einen späteren Gebrauch gespeichert. Tabelle 19 zeigt die
Konfigurationsparameter des Servers:
Name:
dbusername
dbpass
dbname
dbdriver
host
notesdbname
loginname
pass
Wert:
user
user
jdbc:odbc:PDA USER
sun.jdbc.odbc.JdbcOdbcDriver
SrvDev
DevCorner/NISESA/PDATEST rac ord.nsf
nisesa
********
localtion
d:\Programme\Apache Tomcat
Tabelle 19: Konfigurationsfile
- Seite 87 -
4.2. Client
Um Applikationen auf einen PDA zu laden, muss auf dem PC die entsprechende Software installiert
sein. Standardmässig wird diese dem Gerät mitgeliefert. Die Bedienungsanleitung sollte in diesem
Falle dem Produkt beiliegen. (Die folgenden Erklärungen beziehen sich auf die Installation von
Programmen auf einen Palm-PDA.) VM für andere Geräte müssen beim entsprechenden Hersteller
bezogen werden. Bei den nachfolgenden Erklärungen ist zu beachten, dass die verschiedenen
Programme für einen Palm PDA kompiliert wurden, und nicht auf anderen Geräten verwendet werden
können. Möchten die Programme auf einem anderen Gerät verwendet werden, müssen diese für die
entsprechende VM neu kompiliert werden. Dies kann mit dem auf der CD beiliegenden Forte gemacht
werden.
4.2.1. Installation und Konfiguration der Virtual Machine (VM) auf dem PDA
Bevor Java Programme auf einem PDA verwendet werden können, muss die VM auf den PDA
geladen werden. Diese ist unter [24] oder auf der beiliegenden CD verfügbar. Das File «MIDP.prc» ist
die VM. Sie kann mit dem entsprechenden Synchronisationstool auf den PDA geladen werden. Nun
sind einfache Java Programme auf dem PDA lauffähig. Damit aber eine Verbindung mit dem Internet
hergestellt werden kann, müssen noch zwei Netzwerkparameter gesetzt werden. Siehe hierzu
Abbildung 81.
Abbildung 81: Konfiguration der J2ME VM
4.2.2. Installation der P2W Applikation und der Testprogramme
Die kompilierten Java-Programme können, nachdem sie in *.prc Files konvertiert wurden, mit einem
Synchronisationsprogramm auf den PDA geladen werden. Will man die Applikationen auf dem POSE
ausführen, müssen die Programme gemäss Anhang B installiert werden. Die Programme können
gestartet werden, indem mit dem Stift auf das entsprechende Icon getippt wird. Wurde das Programm
neu installiert, befindet es sich in der Kategorie «Unfiled». Kategorien sind vergleichbar mit
verschiedenen Ordnern auf dem PC. Die Kategorien sind oben rechts zu finden und können mit dem
PDA-Stift gewechselt werden. Auf dem linken Screenshot der Abbildung 82 sind die
Standardverzeichnisse zu sehen. Die Testprogramme benötigen keine weiteren Konfigurationen. Bei
der P2W-Applikation muss der Server mit dem Servlet angegeben werden. Die zwei rechten Bilder der
Abbildung 82 zeigen diesen Konfigurationsschritt.
Abbildung 82: Konfiguration P2W Applikation
- Seite 88 -
4.2.3. Verbindung zum Internet
Die P2W-Applikation sowie das Netzwerk-Testprogramm benötigen einen Anschluss an das Internet.
Zu Testzwecken reicht ein PC, der an das Internet angeschlossen ist, und auf welchem der Palm OS
Emulator installiert ist. Wie dieser anzuwenden ist, kann dem Anhang B entnommen werden. Eine
weitere Möglichkeit ist das Testen mit dem PDA, dem «Mocha PPP» und einem PC, der wiederum an
das Internet angeschlossen ist. Diese Variante ist in Anhang C erklärt. Die Palmhersteller haben noch
ein weiteres Verfahren entwickelt, um mit einem Palm PDA auf das Internet zu gelangen. Das
sogenannte «WebClipping» ist im Handbuch des PDAs beschrieben. Der ungefähre Ablauf ist der
Abbildung 83 zu entnehmen.
Abbildung 83: Webclipping von Palm
Quelle: zum Palm m505 mitgelieferte CD
Um eine effektive Verbindung zum Internet aufzubauen, benötigt man ein Handy sowie ein Datenkabel
zur Verbindung von PDA und Handy. Hat das Mobiltelefon eine Infrarotschnittstelle, kann diese
anstelle des Datenkabels verwendet werden. Die weitere Vorgehensweise erfolgt gerätespezifisch.
Die Informationen können der Betriebsanleitung des jeweiligen Gerätes entnommen werden.
- Seite 89 -
4.3. Bedienungshandbuch P2W
Sind das P2W-Programm und die VM auf dem PDA installiert, kann die Applikation gestartet werden.
Einzige Vorbedingung ist, dass der User bei der Administration angemeldet ist. Sinnvoll und
naheliegend sind Kenntnisse der Workflows auf dem WfMS. Da dieses WfMS immer noch besteht und
verwendet wird, sollte der Anwender die Formulare und das Vorgehen des bestehenden Systems
kennen. Die Handhabung der vorliegenden Applikation erfolgt genau gleich wie mit dem Notes Client.
Der Ablauf wird in Abbildung 84 noch einmal gezeigt.
Beim System
anmelden
Aufträge einsehen
Aufträge übernehmen
Auftrag bearbeiten
Auftrag abschliessen
oder zurückweisen
Abbildung 84: Grundsätzlicher Ablauf der P2W Applikation
Die P2W-Applikation hat diverse «Pull-Down» Menüs. Die Abbildung 85 zeigt die wichtigsten
Menüpunkte. Die Menüs können mit dem rot markierten Symbol auf dem Touch Screen angezeigt
werden.
Abbildung 85: Pull-Down Menüs
- Seite 90 -
Im Menü «Java Preferences» können Einstellungen bezüglich der Darstellung und der Verwendung
der Buttons gemacht werden. Dieser Menüpunkt wurde automatisch von der VM hinzugefügt. Ebenso
die «Preference Help», welche dem Anwender Informationen zum ersten Menüpunkt gibt. Der
Menüpunkt «Info» wurde durch uns hinzugefügt und gibt allgemeine Informationen bezüglich der
P2W-Applikation. Das «Copyright» gibt Auskünfte über den Entwickler und die Version des
Programmes. Der letzte Punkt startet das Konfigurationmenü des P2W Programms. Im Menüpunkt
«GO» befindet sich immer den Befehl «Exit» welcher die Applikation beendet. Unter dem Menüpunkt
«Action» sind Informationen und Version bezüglich der VM von Sun abrufbar.
4.3.1. Einloggen und Workflow downloaden
Um einen Auftrag vom System zu übernehmen, muss der erste
Menüpunkt der Hauptübersicht «Funktionen» angewählt werden.
Dieser ist in Abbildung 86 rot markiert. Ein Antippen mit dem Stift
genügt. Danach erscheint der Login Bildschirm, wo der
Username und das Passwort eingegeben werden kann.
Abbildung 86: Workflow
downloaden
Dieser Bildschirm wird in Abbildung 87 gezeigt. Das Passwort
wird eingegeben, indem in die gelbe markierte Schaltfläche
getippt wird. (Es ist auf die Gross- und Kleinschreibung des
Passwortes zu achten). Ein spezielles Fenster öffnet sich, in das
das Passwort eingegeben werden muss. Sind diese Parameter
eingegeben, so kann der rot markierte «Login»-Button aktiviert
werden.
Es ist darauf zu achten, dass bereits eine Verbindung zum
Internet30 besteht, da der PDA nun auf die URL (Webseite mit
Servlet) zugreifen muss. Mit dem «Home»-Button (grün markiert)
kann wieder zum Hauptmenü zurückgewechselt werden.
30
Siehe hierzu das Handbuch des jeweiligen PDA’s
- Seite 91 -
Abbildung 87: Login
Nun werden die eingegebenen Parameter dem Server geschickt. Dieser überprüft die Daten mit den
Daten aus der Administrationsdatenbank. Ist das Passwort falsch, wird dies dem Anwender in einem
Fenster gemeldet. Siehe hierzu Abbildung 88 mit den Fehlermeldungen. Der Server sperrt das Konto
eines Users, der dreimal ein falsches Passwort eingegeben hat. Dies wird dem User angegeben und
ist ebenfalls in der Abbildung 88 zu sehen. Sollte dieser Fall eintreten, so muss mit dem
Systemadministrator der P2W-Applikation Kontakt aufgenommen werden. Er kann das gesperrte
Konto wieder aktivieren.
Abbildung 88: Fehlermeldung beim Loginvorgang
Gleichzeitig wird die URL im Konfigurationsmenü auf die richtige Syntax überprüft. Ist die Syntax der
Konfiguration korrekt, aber der Servletname wurde falsch eingegeben, so wird der PDA ebenfalls eine
Fehlermeldung anzeigen.
Nachdem der Server den Namen und das Passwort erfolgreich überprüft hat, macht er eine Anfrage
an das WfMS, um Aufträge gemäss den in der Administrationsdatenbank definierten Rechte zu
beziehen. Dieser Vorgang kann bis zu einer Minute dauern. Hat der Server die Aufträge vom WfMS
erhalten, schickt er diese an den PDA zurück. Dieser stellt die Aufträge in Form einer Liste
zusammen, zu sehen in Abbildung 89.
Abbildung 89:
Auftragsliste
Nun sind alle übernehmbaren Aufträge auf dem PDA
zwischengespeichert. Die einzelnen Aufträge können geöffnet
werden, indem ein Auftrag mit dem Stift ausgewählt wird. In der
Abbildung 89 steht im Titel oben rechts (gelb markiert) «Externe
WFs». Diese Angabe zeigt dem Anwender, dass es sich bei den
aufgelisteten Workflows um Aufträge handelt, die sich auf dem
System befinden und noch nicht übernommen wurden.
Die Abbildung 90 zeigt einen Auftrag im Detail. Dieser Auftrag
kann übernommen werden, indem auf die letzte Seite geblättert
und dort im «Pull Down»-Menü der Befehl «Übernehmen»
aktiviert wird. Dieser Menüpunkt ist nur auf der letzten Seite des
Auftrages sichtbar. Dies soll sicherstellen, dass der komplette
Auftrag eingesehen wurde. Mit den gelb markierten Buttons kann
vorwärts oder rückwärts geblättert werden. Oben rechts ist die
aktuelle Seitenzahl (grün) und die totale Seitenanzahl (rot)
angegeben. Mit dem Button «Liste» kommt man ohne
Änderungen auf dem WfMS auf die Übersicht der verschiedenen
Aufträge zurück (siehe Abbildung 89).
Abbildung 91: Auftrag
übernehmen
Abbildung 90:
Auftragdetails
In der Abbildung 91 ist das «Pull-Down»-Menü dargestellt, mit
dem ein Auftrag übernommen werden kann. Nach der
Auftragübernahme,
wechselt
der
PDA
zurück
zur
Auftragsübersicht (Abbildung 89).
Jetzt könnte ein weiterer Auftrag übernommen werden. Ist dies nicht gewünscht, so wird mit dem
Button «Home» die Verbindung zum Server abgebrochen (was auch über das «Pull-Down»-Menü
möglich wäre) und zur der PDA kehrt zur Startseite zurück. Die übernommenen Aufträge sind lokal auf
dem PDA gespeichert und dem WfMS entnommen. Im Notes Client erscheinen die übernommenen
Aufträge, als wären sie über den Notes Client übernommen worden.
- Seite 92 -
4.3.2. Workflow editieren
editieren
Mit dem rot markierten Menü aus Abbildung 92 können die lokal
gespeicherten Aufträge betrachtet werden. Dieser Vorgang
benötigt keine Verbindung zum Internet. Nachdem dieses Menü
angetippt wurde, erscheint eine Informationsseite - die
Auftragsübersicht. Mit dem Button «Show» können die lokalen
Aufträge aus der lokalen Datenbank gelesen werden. Die
Auftragsübersicht, wie wir sie bereits aus dem Menüpunkt
«Download» kennen, ist in Abbildung 93 abgebildet.
Im rechten oberen Bildschirmteil ist wieder die gelb markierte
Beschreibung ersichtlich. «Lokale WFs» meint die vom
Anwender übernommenen Aufträge. Das heisst, dass die
aufgelisteten Aufträge im WfMS im Namen des Users
entnommen wurden. Mit dem Button «Home» wird wiederum zur
Funktionsauswahl des Startbildschirmes gewechselt.
Abbildung 93: Lokale
Aufträge
Jetzt können durch Antippen des gewünschten Auftrages die Details betrachtet werden. Auch hier
sind die Auftragsformulare auf mehrere Seiten verteilt. Das Blättern zwischen den Seiten funktioniert
gleich wie bei der Detailansicht vom «Download». Der Anwender kann die Aufträge abschliessen oder
zurückweisen. Diese beiden Funktionen befinden sich auch auf der letzten Seite des Formulares in
einem «Pull-Down»-Menü. Siehe hierzu die Abbildung 94.
Abbildung 94: Funktionen
Wird ein Auftrag abgeschlossen oder zurückgewiesen, können
die Details des Auftrages - analog zum WfMS - nicht mehr
betrachtet werden. Der Auftrag wird auf der lokalen Datenbank
bis auf die Auftragsnummer gelöscht. Nach dem Aktivieren
einer der beiden Funktionen erscheint wieder die Übersicht der
bearbeitbaren Workflows.
Wird der Auftrag hingegen nicht abgeschlossen, kann mit dem
Button «Liste» ohne Änderungen zur Übersicht zurückgekehrt
werden. In der Liste erscheint nun, falls ein Auftrag
abgeschlossen oder zurückgewiesen wurde, ein weiterer Eintrag.
Dieser Eintrag ist in Abbildung 95 zu sehen. Er sagt aus, wieviele
Aufträge synchronisiert werden können.
- Seite 93 -
Abbildung 95: Anzahl
synchronisierbarer
Aufträge
4.3.3. Workflow synchronisieren
synchronisieren
Damit die abgeschlossenen oder zurückgewiesenen Aufträge mit
dem System synchronisiert werden können, muss eine
Verbindung zum Internet hergestellt werden. Nach dem Antippen
des in Abbildung 96 rot markierten Menüs erscheint eine kurze
Erklärung zum Synchronisationsvorgang. Mit dem Button
«Home» gelangt man wieder zur Übersicht der Funktionen
(Abbildung 86).
Der Button «Workflows synchronisieren» bezieht die
synchronisierbaren Aufträge aus der lokalen Datenbank und zeigt
dem Anwender die verschiedenen Auftragsnummern. Dies ist in
Abbildung 97 zu sehen. Im grün markierten Feld werden die
Aufträge mit Funktion und Auftragsnummer angezeigt. Wird der
gelb markierte Button «Synch» betätigt, so wird der
Synchronisationsvorgang vorbereitet. Es erscheint wieder der
Login-Bildschirm von Abbildung 87. Nachdem korrekt beim
System eingeloggt worden ist, werden die zu synchronisierenden
Aufträge an den Server geschickt.
Abbildung 97:
Synchronisation
Abbildung 98:
Synchronisationsmeldung
Der Server synchronisiert sie mit dem WfMS. Das WfMS schickt
eine Bestätigung an den Server, die diese an den PDA
weiterschickt. Die Bestätigung ist in Abbildung 98 zu sehen. Nach
dem Synchronisieren werden die Parameter der synchronisierten
Aufträge auf dem PDA gelöscht. Bei einem erneuten Versuch die
Aufträge zu synchronisieren, meldet P2W, dass keine
synchronisierbaren Workflows vorhanden sind.
- Seite 94 -
Ausblick und Schlussbetrachtung
5. Ausblick und Schlussbetrachtung
Diplomarbeiten in Zusammenarbeit mit einem Praxispartner geben dem Diplomanden die Chance,
Einblick in die Wirtschaftswelt zu erhalten. Dieser Einblick ist mit Sicherheit eine sehr lehrreiche
Erfahrung. Der Student bekommt ausserdem den Druck der Wirtschaft auf die Kosten zu spüren. In
der Informatik ist dies ein neues Phänomen. Die momentane Wirtschaftslage verschont auch die
Informatikabteilungen nicht; immer öfters werden Informatikabteilungen redimensioniert. So auch in
der Ascom Informatik. Leider wurde infolge eines operativen Entscheides der Firmenleitung die
Abteilung «Webapplication» während der Projektdauer aufgelöst, was zur Folge hat, dass das
vorliegende Produkt nie verwendet werden wird. Diese Tatsache hat wiederum zur Folge, dass der
Ausblick dieser Arbeit eher fiktiver Natur ist.
Leider konnte das Projekt nicht so abgeschlossen werden, wie es eigentlich geplant war. Um eine
Synchronisation der Daten zu realisieren, hätte noch einiger Aufwand betrieben werden müssen. Der
Grund für den Mehraufwand ist in der Architektur eines Softwareagenten (ANSTEP-Agent) des
Workflows zu suchen. Dieser Agent wurde in Lotus Script geschrieben und entspricht nicht dem
«Model View Controll»-Konzept (MVC). Das MVC sieht vor, dass das User Interface sowie die
kontrollierende Einheit sauber getrennt und auch getrennt verwendet werden können. Der AnstepAgent braucht jedoch in jedem Falle den Notes Client zur Ausführung einer Synchronisation. Da der
Agent nicht aus einzelnen Komponenten besteht, ist ein Verzicht auf die Notesumgebung unmöglich
- was einem Verstoss gegen das MVC-Konzept entspricht. Der Agent müsste so umgeschrieben
werden, dass direkt auf der Applikationsebene Daten vom Servlet an den Notes-Server übergeben
werden können. Da der ANSTEP-Agent der komplexeste und umfangreichste Agent im WfMS ist,
resultiert aus einer solchen Umprogrammierung ein grösserer Mehraufwand. Dieser ist auf rund fünf
Arbeitstage zu schätzen, vorausgesetzt, dass der Programmierer Kenntnisse des WfMS und von
Lotus Script hat. Aus finanziell verständlichen Gründen wurde dieser Zusatzaufwand nicht
übernommen. Das MIDPServlet hingegen liefert bei der Synchronisation von Aufträgen alle
notwendigen Daten. Am vorliegenden Projekt hätte nichts mehr erweitert werden müssen, um eine
saubere Synchronisation mit einem neuen Agenten zu realisieren. Es drängt sich also die Frage auf,
warum denn dieses Problem bei der Analyse des WfMS nicht erkannt worden war: Zum Zeitpunkt der
Analyse wäre eine Implementation noch finanzierbar gewesen und selbst die Spezialisten des WfMS
waren sich einig, dass alle Agenten von einem Java-Programm angesprochen werden können. Aus
diesem Grund wurde dieser Punkt nicht genauer untersucht.
Unabhängig von den oben beschriebenen Problemen ist die Qualität der momentan verfügbaren KVM
für PDAs zu bemängeln. Die Darstellung der Formulare besticht nicht gerade durch Übersichtlichkeit
und Lesbarkeit. Da sich die Entwicklung der KVMs noch in den «Kinderschuhen» befindet, ist damit zu
rechnen, dass dieses Problem in neueren Versionen behoben wird. Gemäss Aussagen von Sun solle
im Herbst 2003 eine neue Version verfügbar sein.
Des Weiteren sollen Java-Programme auf PDAs deutlich schneller werden. Da kann man sicher
gespannt auf eine neue KVM-Version warten. Das Potential zum Durchbruch für den Einsatz von Java
auf mobilen Geräten ist aber in jedem Fall vorhanden. Die Entwicklung der KVM von IBM (KVM J9)
sollte ebenfalls beobachtet werden. Diese KVM enthält zurzeit noch einige Fehler, welche hoffentlich
in einer neueren Version behoben werden (siehe Kapitel 3.4.2). Die Entwicklungsumgebung von IBM
(Websphere Application Device Developper) überzeugte deutlich mehr als Forte 4 Mobile Edition.
Leider konnte die IBM-Entwicklungsumgebung nicht mit der KVM von Sun verwendet werden. Das
wäre eine ideale Kombination gewesen.
Das vorliegende Projekt wurde mit einem Pentium II mit 128 MB RAM erstellt, was sich als absolut
ungenügend erwies. Die Wartezeiten der Simulationen auf dem POSE betrugen zum Teil mehrere
Minuten, was den Entwickler einige Nerven kostete. Es war auch nicht möglich, gleichzeitig die
Serverumgebung (WebSphere Studio) und die Clientumgebung (Forte) zu bearbeiten, da zuwenig
RAM vorhanden waren, um beide Umgebungen zu starten. Rückblickend betrachtet muss gesagt
werden, dass der verwendete Laptop für dieses Projekt untauglich war.
Das Projekt an sich war eine sehr interessante und lehrreiche Aufgabe. Es deckte ein breites und
vielseitiges Gebiet der Informatik ab, ebenso konnte ein Einblick in neue Technologien gewonnen
werden. Der Aufwand der Arbeit überstieg den Rahmen einer Diplomarbeit, lohnte sich aber dennoch,
wenn das Resultat und die neu gewonnenen Kenntnisse betrachtet werden. Diese Arbeit zeigt, dass in
den kleinen PDAs ein gewaltiges Potential steckt. Betrachtet man die steigenden Absatzzahlen der
- Seite 95 -
Ausblick und Schlussbetrachtung
PDAs und die stärkere Integration von J2ME (siehe Abbildung 99) in Handys, sind Spekulationen über
vermehrte Applikationen für mobile Geräte durchaus gerechtfertigt.
Abbildung 99: Prognose von J2ME
Quelle: [Zelos]
Mobilität wird in einer schnelllebigen Zeit immer wichtiger und entscheidet - wenn nicht heute, so
bestimmt morgen - über Sieg oder Niederlage, respektive über Verkaufen oder nicht Verkaufen. In
diesem Sinne noch einmal: «The future is mobile!»
Die erreichten Resultate in Hinblick auf einen externen Client für das WfMS der Ascom Informatik sind
hilfreich und können in einer Weiterführung des Projektes bestimmt verwendet werden. Die
vorliegende Arbeit zeigt, dass es grundsätzlich möglich ist, das WfMS der Ascom mit einem externen
Client zu verwenden. Der erstellte Prototyp erreichte die geforderten Resultate und könnte mit einer
neueren KVM verwendet und auch weiterentwickelt werden. Ebenso könnten mit den erstellten J2MEKlassen andere PDA-Applikationen effizient erstellt werden.
- Seite 96 -
Literatur und Verweise
6. Literatur und Verweise
[Bergsten 2001]
Bergsten Hans, Java Server Pages, O’Reilly, 1. Auflage,
ISBN: 1-56592-746-X, 2001
[Böhm 1997]
Böhm Markus, Workflow-Management, dpunkt, 1. Auflage,
ISBN: 3-920-993-73-X, 1997
[Booch 1998]
Booch Grady, Rumbaugh James, Jacobson Ivar, UML Reference Manual,
Addison-Wesley, ISBN: 0-2013-0998-X, 1998
[Booch 1999]
Booch Grady, Rumbaugh James, Jacobson Ivar, UML User Guide, AddisonWesley, ISBN: 0-2015-7168-4, 1999
[Borghof 2000]
Borghoff Uwe M., Johann H. Schlichter, Rechnergestützte Gruppenarbeit,
Springer, ISBN: 3-5406-2873-8, 2000
[Callaway 1999]
Callaway Dustin R., Inside Servlets, Addison-Wesley, 3. Auflage,
ISBN: 0-20137-963-5, 1999
[Softwareagenten]
Definitionen Softwareagenten, Webseite, zugegriffen am 1. Mai 2003,
available: http://www.fhwedel.de/~si/seminare/ws99/Ausarbeitung/agent/agent2.htm
[Esmertec ]
Esmertec, Webseite, zugegriffen am 1. September 2003, available:
http://www.esmertec.ch
[Fischer 2003]
Fischer Layna, The workflow handbook 2003, Workflow Management
Coalition, ISBN: 0-9703-5094-5, 2003
[Flanagan 2000]
Flanagan David, Java in a nutshell, O’Reilly, 3. Auflage,
ISBN: 3-89721-190-4, 2000
[Forte]
Forte 4 Java, Webseite, zugegriffen am 30. August 2003, available:
http://wwws.sun.com/software/sundev/jde/
[Funknetzbilder]
Funknetzbilder, Webseite, zugegriffen am 1. Mai 2003, available:
http://www.go4sim.com/download_dateien/de/gsm_funknetz.pdf
[Giguère 2000]
Giguère Eric, Java 2 Micro Edition, Wiley, 1. Auflage,
ISBN: 0-471-39065-8, 2000
[IBM]
IBM Entwicklungsumgebung, Webseite, zugegriffen am 1. September 2003,
available: http://www-3.ibm.com/software/wireless/wme/
[J2ME]
J2ME, Webseite, zugegriffen am 29. August 2003, available:
http://java.sun.com/j2me/docs/j2me-ds.pdf
[Java Dev]
Java Development Kit (JDK), Webseite, zugegriffen am 1. Mai 2003, available:
http://java.sun.com
[Java Spec]
Java Specification RequestsWebseite, zugegriffen am 28. August 2003,
available: http://www.jsr.org
[JDBC-Bridge]
JDBC-ODBC Bridge, Webseite, zugegriffen am 1. September 2003, available:
http://java.sun.com/products/jdbc/
- Seite 97 -
[Lotus Notes]
Lotus Notes, Webseite, zugegriffen am 1. Mai 2003, available:
http://www.lotus.com
[McLaughlin 2001]
McLaughlin Brett, Java und XML, O’Reilly, 1. Auflage,
ISBN: 3-89721-280-3, 2001
[Meier 2001]
Meier Andreas, Relationale Datenbanken, Springer Verlag, 4. Auflage, ISBN:
3-540-41468-1, 2001
[MIDP]
MIDP VM für den PDA, Webseite, zugegriffen am 1. September 2003,
available: http://java.sun.com/products/midp/
[MIDP-Servlet]
MIDP-Servlet Webseite, zugegriffen am 1. September 2003, available:
http://wireless.java.sun.com/midp/articles/servlets
[MochaSoft]
MochaSoft Webseite, zugegriffen am 1. Mai 2003, available:
http://www.mochasoft.dk
[Muhs 2003]
Muhs Thomas, Java-Anwendungen für Notes/Domino entwickeln, AddisonWesley, ISBN: 3-827-318076, 2003
[Oestereich 2001]
Oestereich Bernd, Objektorientierte Softwareentwicklung, Oldenburg, 5.
Auflage, ISBN: 3-486-25573-8, 2001
[OMG]
OMG, Webseite, zugegriffen am 1. Mai 2003, available:
http://www.omg.org/uml/
[Palm]
Palm OS Emulator (POSE), Webseite, zugegriffen am 1. September 2003,
available: http://www.palmos.com/dev/tools/emulator/
[Reese 2000]
Reese George, JDBC and Java, O’Reilly, 2. Auflage,
ISBN: 1-56592-616-1, 2000
[RFC zu HTML]
RFC zu HTML, Webseite, zugegriffen am 1. Mai 2003, available:
http://www.ietf.org/rfc/rfc1867.txt
[RFC zu HTTP]
RFC zu HTTP, Webseite, zugegriffen am 1. Mai 2003, available:
http://www.ietf.org/rfc/rfc2616.txt
[Sun]
Sun Microsystems, The Java Community Process, Webseite, zugegriffen am
1. Mai 2003, available: http://java.sun.com/aboutJava/communityprocess/
[Tannenbaum 2000]
Tannenbaum Andrew S., Computernetzwerke, Prentice Hall, 3. Auflage,
ISBN: 3-8273-7011-6, 2000
[Tomcat]
Tomcat Server, Webseite, zugegriffen am 1. September 2003, available:
http://jakarta.apache.org/tomcat
[Topley 2002]
Topley Tim, J2ME in a nutshell, O’Reilly, 1. Auflage,
ISBN: 0-596-00253-X, 2002
[Turau 2000]
Turau Volker, Java Server Pages, dpunkt, 1. Auflage,
ISBN:3-932588-66-5 ,2000
[UML]
UML Beispiel, Webseite, zugegriffen am 1. Mai 2003, available:
http://www.rittershofer.de/info/umlkompakt/index.htm
[Nohr]
Vorlesungsunterlagen von Prof. Holger Nohr, Hochschule Medien,
Informationswirtschaft, File « wfm.pdf » auf beigelegter CD, available:
http://www.iuk.hdm-stuttgart.de/nohr/Hauptseite.html
- Seite 98 -
[Vossen 1996]
Vossen Gottfried, Becker Jürg, Geschäftsprozessmodellierung und
Workflowmanagement, Thomson Publishing, 1. Auflage,
ISBN: 3-8266-0124-6, 1996
[Waba]
WABA, Webseite, zugegriffen am 30. August 2003, available:
http://www.wabasoft.com/
[Wireless]
Wireless Toolkit, Webseite, zugegriffen am 30. August 2003, available:
http://java.sun.com/products/j2mewtoolkit/download-2_0.html
[WfMC]
Workflow Management Coalition (WfMC), Webseite, zugegriffen am 22. Mai
2003, available: http://www.wfmc.org
[Zelos]
Zelos Group, Webseite, zugegriffen am 1. Mai 2003, available:
http://www.zelos.com
- Seite 99 -
Glossar
Glossar
AJP
Apache JServ Protocol:
Protokoll, das verwendet wird, um JSP-Seiten vom Apache Web Server
an den Tomcat Server weiterzuleiten.
ASCII
American Standard Code for Information Interchange:
Binäre Codierung des Alphabetes.
BSS
Basis Station System:
Ein Sende- und Empfangsmast einer Funknetz-Zelle. Das BSS ist über
eine Funk oder Glasfaserleitung mit der Vermittlungsstation MSC
verbunden.
CLDC
Connected Limited Device Configuration:
Die CLDC setzt auf der VM eines mobilen Gerätes auf. CLDC-Geräte
haben weniger Speicher, kleinere Displays und geringere
Übertragungsraten als CDC Geräte.
DFÜ
Daten Fern Übertragung:
Datenverkehr, der über ein Netzwerk verläuft.
GUI
Grafisches User Interface:
Der Anwender arbeitet, wenn er ein Programm interaktiv verwenden
kann, immer mit dem GUI. Das GUI kann Textfelder, Buttons, Listen,
usw. enthalten.
HR
Human Ressource:
In der werden die Datensätze, die über die Mitarbeiter gehalten werden,
als HR Datenbank bezeichnet.
HTML
Hyper Text Markup Language:
Sprache, die die Darstellung und Formatierung eines Textes beschreibt.
Diese Sprache wird bei Internetseiten verwendet.
HTTP
Hyper Text Transfer Protokoll:
Dieses Protokoll regelt die Übertragung von HTML-Seiten.
ID
Identifier:
Bei Datenbanken und auch bei Vectoren/Arrays werden die Elemente mit
einer aufsteigenden Zahl nummeriert.
- Seite 100 -
Glossar
Abkürzung
Beschreibung
IDE
Integrated Development Environment:
Entwicklungsumgebung in der Programme entwickelt werden. Zum Teil
können Codegerüste automatisch generiert werden
IP
Internet Protokoll:
Ein Netzwerkprotokoll, das den Transport von Daten im Internet
verwaltet. Wird oft mit dem TCP Protokoll genannt.
ISDN
Integrated Services Digital Network:
Das ist ein Prinzip, das verwendet wird, um Daten und Sprache digital zu
übertragen
IT
Information Technology:
Unternehmen verwenden diese Abkürzung häufig für die
Informatikabteilung
J2EE
Java 2 Enterprise Edition:
Java Version für Grossrechner und Servers
J2ME
Java 2 Micro Edition:
Java Version für mobile Geräte wie Handys und PDAs
J2SE
Java 2 Standard Edition:
Java Version für PCs
JDBC
Java Database Connectivity:
Ein API, mit dem auf relationale Datenbanken zugegriffen werden kann.
JDK
Java Developpment Kit:
Java Entwicklungstool. Entspricht im Prinzip dem Java Compiler, der
Virtual Machine und der Runtime.
JSP
Java Server Page:
Java Code kann mit speziellen Tags in HTML Code eingebunden
werden. Diese Programme werden auf der Serverseite ausgeführt.
JSR
Java Specification Request:
Empfehlungen und Spezifikationen zu Java.
JVM
Java Virtual Machine:
Die Umgebung, die Java Programme ausführt. Ohne eine Virtual Machine
können keine Java Programme ausgeführt werden.
KVM
Kilobyte Virtual Machine:
Virtual Machine für den PDA. Der Name Kilobyte kommt daher, weil diese
VM nur einige Kilobyte gross ist.
MIDP
Mobile Information Device Profile:
Erweitert die Profile einer VM für mobile Geräte.
MIDP werden bei CLDC Geräten verwendet.
MSC
Mobile Switching Centre:
Ist mit mehreren BSS, anderen MSC und dem Telekommunikationsnetz
verbunden. MSC ist eine Vermittlungszentrale zwischen mobilen
Anschlüssen wie Handys und dem Festnetz.
- Seite 101 -
Glossar
Abkürzung
Beschreibung
MVC
Model View Control:
Konzept zur Entwicklung von Software. GUI sollte von der logischen
Applikation getrennt sein, so dass GUI und/oder die logischen
Applikationen wiederverwendet werden können.
NSF
Notes Storage File:
Notes Datenbanken haben die Endung *.nsf.
ODBC
Open Database Connectivity:
Ein Vorgehen, mit welchem auf beliebige Datenbanken zugegriffen
werden kann.
OMG
Object Management Group:
Eine Vereinigung von verschiedenen Unternehmen, die sich zum Ziel
gesetzt haben, die verteilten Applikationen zu standardisieren.
P2W
Palm 2 IT-Workflow
PC
Personal Computer:
PDA
Portable Digital Assistant:
Handcomputer wie Palms, Visiors…
PDAP
PDA Profile:
MIDP für einen PDA. Wird heute nicht mehr verwendet, da es annähernd
daselbe wie das MIDP ist.
POSE
Palm Operating System Emulator:
Dieser Emulator emuliert einen Palm PDA.
RaC
Rent a Client:
Workflow der Ascom Informatik für Vermietung von Geräten.
RAM
Random Access Memory:
Arbeitsspeicher eines Computers.
SQL
Standard Query Language:
Sprache, mit der eine Abfrage auf einer Datenbank durchgeführt werden
kann.
TCP
Transmission Control Protocol:
Packetorientiertes Protokoll, das Daten in Packete verpackt und diese
über ein Netzwerk oder das Internet verschickt.
UML
Die Unified Modelling Language ist eine Sprache und Notation zur
Spezifikation, Konstruktion, Visualisierung und Dokumentation von
Modellen für Softwaresysteme [10, Seite 193].
URL
Uniform Resource Locator:
www.ascom.ch ist zum Beispiel eine URL. Es ist eine Internetadresse.
VM
Virtual Machine:
Siehe JVM
- Seite 102 -
Glossar
Abkürzung
Beschreibung
WAPI
Workflow Application Programming Interface:
Schnittstelle im Workflow Referenzmodell, die eine Verbindung zu
Workflowkomponenten aufbaut.
WfMC
Workflow Management Coalition:
Eine ähnliche Vereinigung wie die OMG; standardisiert allerdings WfMS.
WfMS
Workflow Management System:
Ein System, das Workflows in definiert, kreiert und verwaltet.
WPDL
Workflow Process Definition Language:
Zum Austausch von Workflowbeschreibungen. Im
Workflow Referenzmodell wird die WPDL zur
Beschreibung der Prozessdefinitionen verwendet.
WS
Websphere Studio:
IDE von IBM um JSP, HTML und Java Servlets zu erstellen.
WSAD
Websphere Studio Application Developper:
Vereinigung vom Visual Age 4 Java und dem Websphere Studio.
WSDD
Websphere Studio Device Developper:
Plug In für das WSAD. Mit dieser IDE können Applikationen für mobile
Geräte erstellt werden.
XML
Extensible Markup Language:
Datenaustausch zwischen unterschiedlichen Plattformen wird mit XML
erleichtert.
- Seite 103 -
Anhang A: Accessdatenbank
Damit der Server die Datenbank findet, muss diese in der Systemadministration angemeldet werden.
Die Datenbank wird in der Systemsteuerung unter
Abbildung 100: ODBC Datenquellen
angemeldet. Wird das Icon der Systemsteuerung aus Abbildung 100 angeklickt, öffnet sich das
Fenster aus Abbildung 101 geöffnet.
Abbildung 101: ODBC Administrator
Beim ODBC-Administrator muss eine neue Datenquelle hinzugefügt werden. Dies kann durch
Betätigen des rot markierten Buttons gemacht werden. Im neu geöffneten Fenster werden die
verschiedenen Treiber angezeigt. Im Falle einer Microsoft Access Datenbank wird der entsprechende
Treiber angewählt (blau markiert). Nach dem Befehl «Fertig stellen» kann die Datenbank konfiguriert
werden.
- Seite 104 -
Abbildung 102: Datenbank
Im grün markierten Feld aus Abbildung 102 kann der Datenbanknamen, mit dem die Datenbank in den
SQL-Queries angesprochen werden möchte, angegeben werden. Mit dem Button «Auswählen» (gelb)
wird die Datenbank mit dem physikalischen Ort referenziert. Unter «Erweitert» (blau) können
Username und Passwort für den Zugriff eingegeben werden. Dies zeigt Abbildung 103
Abbildung 103: User und Passwort der Datenbank
- Seite 105 -
Anhang B: Palm OS Emulator (POSE)
Anhang B: Palm OS Emulator (POSE)
Der Emulator kann von [Palm] heruntergeladen werden. Die Installation wird durch Ausführen der
«setup.exe» gestartet. Danach müssen die «Properties» gesetzt werden. Die Angaben aus Abbildung
101 beziehen sich auf Anwendungen, in denen der Palm Zugriff auf das PC-interne DFÜ Netzwerk
benötigt. Um die notwendigen Einstellungen vorzunehmen, muss mit der rechten Maustaste auf den
Emulator geklickt, dann kann der Menüpunkt «Settings -> Properties» angewählt werden. Die
Abbildung 104 zeigt das erscheinende Fenster. Die gelb hinterlegten Einstellungen müssen
vorgenommen werden. Von zentraler Bedeutung ist, dass die NetLib auf das interne DFÜ umgeleitet
wird.
Abbildung 104: Konfiguration des Palm Emulators
Ohne diese Konfiguration ist es nicht möglich, mit dem Palm Emulator und dem Programm «Mocha
PPP»31 auf das Internet zu gelangen. Sinnvoll ist noch, dass die Session beim Beenden des
Emulators gespeichert wird. Software für den Palm Emulator kann unter dem Menüpunkt «Install
Application/Database» installiert werden.
31
siehe Kapitel 3.4.10
- Seite 106 -
Anhang C: Mocha Soft PPP
Anhang C: Mocha Soft PPP
Da Mocha PPP denselben Port wie die «Palm-PC» Synchronisation verwendet, muss Mocha PPP vor
einer gewünschten Synchronisation gestoppt werden. Ansonsten ist eine Datensynchronisation mit
dem PC nicht möglich. Als sehr praktisch hat sich die Logfunktion erwiesen. Diese Funktion schreibt
allen «Traffic» in ein ASCII Text File. Dies kann vor allem bei der Fehlersuche hilfreich sein.
Abbildung 105: Mocha PPP Screenshot
Die Konfiguration des Palms stellte sich allerdings nicht ganz so einfach heraus, wie die Webseite
angibt. Folgende Konfiguration eignet sich für Palm OS 4.
Abbildung 106: Konfiguration des Palms für Mocha PPP
Die Abbildung 106 zeigt die drei Konfigurationsschritte, die vorgenommen werden müssen. Das Menü
Preferences ist unter den Systemmenüs des Palms zu finden. Probleme ergeben sich vor allem, wenn
der Emulator hinter einer Firewall steht und auf das Internet zugreifen möchte. In diesem Fall muss bei
einem PDA Internet Browser wie zum Beispiel AvantGo der Proxyserver angegeben werden. Solange
man aber nur intern auf einen Server, oder wie in diesem Fall auf den Localhost zugreifen möchte, ist
dieses Programm sehr komfortabel. Leider kann man Mocha PPP nicht mit dem Palm OS Emulator
(POSE) verwenden. Dieses Feature ist zwar nicht zwingend notwendig, wäre aber sicher interessant.
- Seite 107 -
Anhang D: Beiliegende CD
Anhang D: Beiliegende CD
Auf der beiliegenden CD befindet sich:
-
Source Code
Javadoc des Clients und des Servers
Dokumentation im «PDF» Format
Diverse «PDF» Dokumente
Forte 4 Java Micro Edition
Palm OS Emulator
Mocha PPP
Tomcat Server
Userdatenbank für Microsoft Access
Verwendetes JDK
Alle notwendigen «jar-Files»
- Seite 108 -
Erklärung
Erklärung:
Ich versichere, dass ich die vorstehende Arbeit
selbständig angefertigt und entsprechend den Grundsätzen
wissenschaftlicher
Ehrlichkeit
abgefasst
habe.
Es ist mir bekannt, dass andernfalls die Abteilung
gemäss dem Abteilungsbeschluss vom 28.11.1984 das
Recht hat, den auf Grund dieser Arbeit verliehenen
Titel zu entziehen.
……………………………………………………, den ………………………………
……………………………………………
(Unterschrift)
- Seite 109 -

PDA to IT-Workflow

Transcrição

Documentos relacionados

netcomp 3b deutsch.indd - Movis Mobile Vision GmbH

Navigation mit digitalen Karten FUGAWI MARINE ENC

pdf-Flayer - dream

Anleitung

Ralf Klüppel

Einführung in die Nutzung eines PDA

Personal Digital Assistants - Schweizerische Ärztezeitung

Mobile Navigator 7 - DaybyDay ISSN 1860-2967

Halterungen für Intermec CN3

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

Geschäftsprozessmodellierung und Workflow