Leseprobe
Inhaltsverzeichnis
Abstract
Einleitung
Voraussetzungen
Einsatzort
Projekt „Himalaya“
Ausgangssituation
I Projektbeschreibung
I.1 Allgemeine Ziele des Projekts
I.2 Eigenschaften der Dokumentengenerierung
I.3 Zusätzliche Anforderungen
I.4 Lösungsansatz
I.5 Technische Umgebung
II Server-Komponente zur Dokumentenerzeugung
II.1 Anforderungsanalyse
II.1.1 Use Cases
II.2 Analyse/Design
II.2.1 Fachlicher Überblick des Klassenmodells
II.2.2 Paketstruktur des Klassenmodells
II.2.3 Detailbeschreibung des Klassenmodells
II.2.4 Konfigurations- und Ablagemöglichkeiten
II.3 Implementierung
II.3.1 DocServiceWrapper
II.3.2 WLSInfos
II.3.3 Dispatcher
II.3.4 Form
II.3.5 InternalForm
II.3.6 FormVar
II.3.7 RawData
II.3.8 ValueData
II.3.9 Jobparameter
II.3.10 FormService
II.3.11 FormDescription
II.3.12 Controller
II.3.13 Engine
II.3.14 EngineMetaData
II.3.15 XSLEngine
II.3.16 GenEngine
III Client-Komponente zur Eingabe des Dokumenteninhalts
III.1 Anforderungsanalyse
III.1.1 Use Cases
III.2 Analyse/Design
III.2.1 Erweiterung der Paketstruktur
III.2.2 Überblick des erweiterten Klassenmodells
III.3 Implementierung
III.3.1 GUIDocserviceMain
III.3.2 GUIGenericBuilder
III.3.3 Deployment des Clients
IV Ablauf der Dokumentengenerierung
V Abschließende Bewertung
Quellenverzeichnis
Dankwort
Für die Betreuung während des Diplomsemesters sowie für die Bestimmung des Diplomthemas bedanke ich mich bei Herrn Prof. Dr. J. Dunkel.
Außerdem möchte ich mich bei Herrn Christian Geveke für die freigestellte Zeit in der dvg Hannover Datenverarbeitungsgesellschaft mbH und seiner Unterstützung zur Erstellung dieser Arbeit bedanken. Herrn Martin Grube danke ich für die nützlichen Ratschläge im Bereich der Unified Modelling Lan-guage (UML).
Weiterhin bedanke ich mich bei allen Freunden und Bekannten die mich bei der Erstellung dieser Arbeit tatkräftig unterstützt haben.
Die vorliegende Diplomarbeit wurde in der Zeit vom 06.05. - 05.08.2002 bei der dvg Hannover Datenverarbeitungsgesellschaft mbH, Laatzener Str.5, 30539 Hannover unter der Anleitung von Herrn Prof. Dr. J. Dunkel (Erstprüfer) und Herrn C. Geveke (Zweitprüfer) ange-fertigt.
Erklärung
Ich versichere hiermit, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen Quellen und Hilfsmittel als die angegebenen genutzt habe.
Ort, Datum Stefan Tantow
Abstract
Die vorliegende Arbeit beschreibt und analysiert die Implementierung eines Dienstes zur dynami-schen Dokumentengenerierung in der Programmiersprache Java. Für die Realisierung des Dienstes wird die Extensible Markup Language(XML) und die Extensible Stylesheet Language(XSL) in Ver-bindung mit dem Formatting Objects Standard genutzt. Die Dokumentengenerierung erfolgt, indem XML-Daten in ein vorher generiertes XSL-Formular integriert werden. Es wird anschließend ein dar-stellbares Format erzeugt, um das Ergebnis präsentieren zu können. Die Formate können individuell vom Nutzer des Dienstes (meist ein bestehendes Anwendungssystem) eingestellt bzw. konfiguriert werden. Ein weiterer wichtiger Aspekt ist die Erstellung der XSL-Formulare. Daher wird in dieser Arbeit auch ein Formulardesigner vorgestellt, mit dessen Hilfe der Nutzer ohne Programmierkennt-nisse individuelle Formulare jeder Art generieren kann. Dabei spielt das Verwaltungsmanagement der Formulare sowie die Verarbeitung dieser durch den Server auch eine wichtige Rolle.
Im zweiten Teil der Arbeit wird eine Demonstrationsanwendung zur Nutzung des Dienstes vorgestellt bzw. implementiert. Diese kann dem Designer der Formulare als Testwerkzeug dienen, um anwendungsindividuell generierte Formulare, die mit Daten gefüllt werden, auf Korrektheit zu prüfen. Mit Hilfe des Acrobat Readers © kann das Ergebnis betrachtet und ausgedruckt werden.
Einleitung
Voraussetzungen
Für das Verständnis der Diplomarbeit werden folgende Grundkenntnisse vorsausgesetzt: Beschreibungs-/Programmiersprachen :
Extensible Markup Language(XML), Extensible Stylesheet Language(XSL), Formatting Objects, Java Applikationsserver :
Java 2 Enterprise Edition (J2EE), Implementierung von Enterprise Java Beans (EJB) OO-Design :
Begriffe im Bereich der Unified Modelling Language (UML) z.B. Klassendiagramme, Use-Cases oder Sequenzdiagramme
Einsatzort
Diese Diplomarbeit entstand während des zweiten Praxissemesters bei der dvg Hannover Datenverarbeitungsgesellschaft mbH.
Nach eigenen Angaben: „Die dvg ist mit über 1.700 Mitarbeitern und Umsatzerlösen in Höhe von 403,3 Mio. Euro in 2001 führender Informationstechnologie - Dienstleister der deutschen Sparkas-senorganisation. Das Unternehmen mit Firmensitz in Hannover unterhält eines der größten Rechen-zentren Europas.“
Das Rechenzentrum der dvg ist eines der modernsten Europas, wobei alle Abhebungen an den über 63.000 angeschlossenen Sparkassen-Geldautomaten in 12 Ländern direkt über den zentralen Netzknoten des Rechenzentrums in Hannover laufen.
Zu den Tätigkeitsschwerpunkten gehören
- Entwicklung und Integration von Anwendungssystemen,
- Hard- und Software-Beratung,
- IT-Services und
- Rechenzentrumsbetrieb.
Projekt „Himalaya“
Im Projekt „Himalaya“ entwickelt die dvg Hannover Softwarebausteine zur Unterstützung von Ver-triebsprozessen der Finanzdienstleistungsbranche auf Basis einer netzzentrierten Frontendarchitektur.
Zu den Softwarebausteinen gehören acht flexibel kombinierbare Teilprozesse:
- Geschäftsportfolio,
- Vertriebsunterstützendes Aufgaben- und Terminsystem (VAS),
- Database-Marketing,
- Beratungsbausteine,
- Teilerneuerung Kundensystem,
- Giro,
- Einlagenmanagement und
- Zahlungsverkehr
Für jeden Teilprozess müssen Geschäftsdokumente erzeugt werden.
Ziel des Konzepts ist es, ein hohes Qualitätsniveau des Dienstleistungsangebots zu gewährleisten und zugleich durch höhere Produktivität eine Verbesserung der Kostensituation zu erreichen. Die oben genannten Geschäftsvorfälle werden grundsätzlich fallabschließend bearbeitet. Die Navigation durch die Subprozesse eines Geschäftsvorfalls wird dabei über die „Himalaya“-Anwendung gesteuert.
Zu dieser modernen Technologie gehört die Anwendung und Nutzung von Applikationsserver im Rahmen der 3-Tier Architektur. Diese Architektur dient zur Trennung von Präsentation auf den Clients und den fachlichen Anwendungen auf dem Applikationsserver. Die juristischen Daten werden auf Hostsystemen gehalten.
Ausgangssituation
Dieser Diplomarbeit liegt folgende Ausgangssituation zugrunde:
Die Implementierung eines Dokumentengenerierungsdienstes in der Programmiersprache C++ ist bereits vorhanden und befindet sich bereits in der Pilotierung. Es werden zwei Systeme zur Dokumentengenerierung verwendet. Für institutsindividuelle und dynamische Formulare wird das Officepaket Applixware © genutzt. Die Verarbeitung von statischen Formularen z.B. Kredit-formulare des Sparkassenverlages erfolgt über ein zusätzliches Dokumentenverarbeitungssystem. Das Textverarbeitungssystem vom Officepaket Applixware © dient dabei zum Formulardesign der dynamischen Formulare. Die Integration der Inhaltsdaten in die Formulare zur Laufzeit erfolgt über die Makrosprache von Applix. Dabei werden einem Makro die Inhaltsdaten übergeben, welches diese dann in das entsprechende Formular einfügt. Als Ergebnis wird von Applix eine Datei im Postscript-Format zurückgeliefert. Da zur Darstellung der Acrobat Reader © verwendet werden soll, ist hierfür eine Konvertierung von Postscript(Applix) nach PDF erforderlich. Diese Konvertierung erfolgt über Ghostscript. Das generierte PDF Dokument wird über das Acrobat Reader ©-Plug-In des Browsers angezeigt. Zu dem existieren eine Menge von Konvertiermodulen um unterschiedliche Dateiformate zu erzeugen.
Abbildung 1: Grundsätzlicher Ist-Aufbau des Dokumentendienstes der dvg
Abbildung in dieser Leseprobe nicht enthalten
Diese Lösung hat folgende Nachteile:
Die gesamte Ansteuerung des Servers funktioniert über Corba. Corba ist eine programmiersprachenund plattformunabhängige Architektur für verteilte Objekte. Kernstück dieser Architektur ist der „Object Request Broker“ (ORB), der als Vermittlungszentrale zwischen den Objekten dient. Wie die Praxis (auch in der dvg) gezeigt hat, ist der Einsatz einer auf Corba-basierten Lösung aufgrund der hohen Komplexität des Systems mit hohen Wartungs- bzw. Administrationsaufwand verbunden. Unter anderem erhöht sich dadurch auch die Fehleranfälligkeit. Des Weiteren ergeben sich bei der geplanten Portierung nach Java folgende Problemstellungen:
Aus verschiedenen Gründen (z.B. Performance oder hardwarenahe Funktionen) können existierende C++ Bibliotheken nicht nach Java portiert werden oder sie sind nicht als Java Bibliotheken verfügbar. Beispielsweise ist die Verarbeitung von großen Bytestreams von zu konvertierenden Daten in C++ erheblich performanter. Dadurch müssen manche Funktionalitäten weiterhin in der Programmiersprache C++ genutzt werden.
Kapitel I Projektbeschreibung
Die Dokumentengenerierung für institutsindividuelle bzw. dynamischen Formulare der dvg wird mit dem Officepaket Applixware © durchgeführt. Applixware © ist vergleichbar mit Microsoft Office © und stellt keine Ideallösung dar. Außerdem handelt es sich um keinen offenen Standard und wur-de ursprünglich auch nicht als Dokumentengenerierer konzipiert. Durch die Applix-Makrosprache zur Dokumentenaufbereitung entstehen besonders bei großen Dokumentenmengen wesentliche Per-formancenachteile. Hinzu kommt das Applixware © zum Formulardesign nicht besonders benutzer-freundlich ist.
Neben Applixware © werden auch andere Dokumentengenerierer und Formatkonvertierer verwen-det. Gleichzeitig ist geplant, das weitere derartige Module zukünftig ohne größere Aufwände dem Dokumentendienst hinzugefügt werden. Für die Realisierung wurde hierfür ein generischer Ansatz basierend auf konfigurierbaren modularen „Engines“ (Funktionseinheiten) gewählt. „Engines“ wer-den zur Laufzeit aus Metainformationen einer Konfigurationsdatei erzeugt. Diese Metainformationen beinhalten unter anderem die Ein- und Ausgabeformate und mögliche Aufrufe von externen Kom-mandos. Zusätzlich wurde auch ein Mechanismus implementiert, um mehrstufige „Engine“-Aufrufe für die Konvertierung von einem Eingabeformat in ein Ausgabeformat zu ermöglichen.
Beispiel: Konvertierung von ASCII nach PDF
Ein einfacher Text soll in das PDF-Format konvertiert werden. Da es keinen direkten Konverter gibt, werden zwei Konvertierungsstufen durchgeführt:
1. ASCII nach Postscript
2. Postscript nach PDF
Für die Diplomarbeit wird jedoch nur eine „Engine“ verwendet, da die Zielstellung die Untersuchung eines Dokumentengenerierers auf Basis von XML und XSL:FO ist.
Erklärung der Begriffe zur Diplomarbeit:
Inhalt (Content)
Der Begriff „Inhalt“ ist wie folgt definiert:
Von unterschiedlichen Geschäftsprozessen (Anwendungssysteme) werden Daten verschiedener Arten an den Dokumentengenerierungsdienst übermittelt.
Zu diesen Daten gehören:
- ASCII-Zeichenketten (Strings)
- Bytestreams (z.B. Bilder)
- dynamische Tabellen mit unterschiedlicher Zeilenlänge
Die jeweiligen fachlichen Anwendungen übergeben dabei Felddaten in Form von Text für Platzhaltervariablen, dynamische Tabellen oder Bytestreams.
Formular
Der Begriff „Formular“ ist wie folgt definiert:
Ein Formular wird im Dokumentengenerierungsprozess mit Inhalt gefüllt. Es kann folgende Komponenten enthalten:
- statischen Text (z.B. Tabellenüberschriften, Anreden),
- kundenspezifische Inhalte (Logos, Textbausteine)
- sowie Platzhalter (Variablen) für Text, Bilder oder Tabellen
Die Formulare liegen in unterschiedlichen proprietären Formaten als Datei vor. Die Metadaten dieser Formulare werden über Repositorys verwaltet.
Jobparameter
Unter Jobparametern versteht man spezielle Parameter für einen bestimmten Dokumentengenerie-rungsprozess. Diese steuern das zu erzeugende Dokument indem folgende Parameter übergeben wer-den können:
- das Zielformat des zu generierenden Dokuments. Im Rahmen der Diplomarbeit ist dieses For-mat PDF.
- bei institutsindividuellen Formularen ein Institutsname (z.B. von einer Organisation). Dieser muss auch zusätzlich in einem Formularrepository angegeben werden.
Dokument
Das Dokument ist als ein generiertes Ergebnis vom dynamischen Dokumentendienst definiert. Es beinhaltet die vom jeweiligen Anwendungssystem übermittelten Felddaten an den dafür vorgesehenen Platzhaltern (Variablen) des Formulars (siehe Begriffserklärung Formular). Das generierte Dokument liegt je nach gewünschtem Zielformat unter Berücksichtigung der Jobparameter als Ergebnis vor. Mit diesem Dokument kann die Anwendung eine Weiterverarbeitung durchführen (z.B. Speicherung in eine Datenbank oder Anzeige über den Acrobat Reader ©).
I.1 Allgemeine Ziele des Projekts
- Das Hauptziel ist die Bereitstellung eines Dokumentenverarbeitungssystems das die Funktionalitäten der beiden existierenden Dokumentenverarbeitungssysteme für statische und dynamische Formulare in sich vereint und zusätzlich die Performance verbessert wird.
- Des Weiteren soll die Benutzerfreundlichkeit des Formulardesigners erhöht werden.
- Ein bestehendes Anwendungssystem wird um die Funktionalität einer Dokumentengenerierung erweitert. Daher werden Daten aus den Anwendungen über den Dokumentendienst und ein da-zugehöriges Formular zu einem Dokument verarbeitet und an die Anwendung zurückgegeben. Das Formular besitzt bestimmte Platzhalter, welche über den Dienst mit den Anwendungsdaten ersetzt werden.
- In dieser Arbeit soll der Mischvorgang der Inhaltsdaten in die Formulare über XML in Ver-bindung mit XSL-Formatting Objects erfolgen. Der Ablauf der Integration ist dabei wie folgt beschrieben:
Die übermittelten Daten aus den Anwendungen werden in das XML-Format transferiert und mit einem entsprechenden XSL:FO-Stylesheet (Formular) in ein XSL:FO-Dokument mit den XMLDaten transformiert. Anschließend erfolgt eine Vermischung der XML- bzw. XSL:FO-Daten und Konvertierung in ein darstellbares Format (z.B. PDF).
- Das Ergebnis soll ein Dokument sein, welches über ein Renderingprozess (Datenvermischung) eines Formatting Objects Processor (FOP) durchgeführt wird. Die Anwendung kann anschließend das generierte Dokument anzeigen.
- Außerdem soll eine benutzerfreundliche Schnittstelle für den Entwickler des bestehenden An-wendungssystems realisiert werden, damit dieser die anfallenden Daten dem Dienst übermitteln kann.
- Ein weiteres Ziel ist die Implementierung eines Demo-Clients, um vorhandene Formulare auf Fehler zu prüfen. Dieses geschieht, indem dynamische Eingabemasken für die Formularfelder zu bearbeiten sind, um anschließend das Ergebnis zu betrachten. Aus diesem Grund soll als weiteres Ziel die Demoapplikation eine Vorschaufunktion mit anschließender Druckmöglich-keit beinhalten.
Diese Anwendung sollte demnach auch benutzerfreundlich und ergonomisch dargestellt sein, damit auch ein Nicht-Programmierer z.B. der Formulardesigner diese Applikation bedienen kann.
- Als letztes Ziel soll es die Möglichkeit der Erzeugung von Formularen im XSL-Kontext geben. Jeder Bediener muss ein XSL-Formular ohne Programmierkenntnisse erstellen können. Ein denkbarer Formulardesigner ist XSLFast von jCatalog ©, welcher auch in dieser Arbeit untersucht und eingesetzt wird.
Mit diesem Tool kann eine Layout erzeugt werden, welches unter anderem statischen Text und Platzhalter für Text bzw. Bilder beinhalten kann.
Nach der Formularerstellung muss das Layout dem eigentlichen Dienst publiziert werden.
Zu diesen Informationen gehören unter anderem ein eindeutiger symbolischer Formularname sowie der vollständige Pfad und Dateiname.
I.2 Eigenschaften der Dokumentengenerierung
Bei der dynamischen Dokumentengenerierung wird ein Dokument mit bestimmten dynamischen und statischen Inhalt erzeugt und in einem vorgegebenen Format abgelegt.
Für den Dokumentengenerierungsprozess relevante Steuerungsinformationen, wie zum Beispiel das Zielformat, werden in Jobparametern hinterlegt. Um ein solches Dokument zu generieren werden In-haltsdaten von geschäftsbezogenen Daten aus Anwendungssystemen mit einem dazugehörigen For-mular vermischt. Anschließend wird das Dokument in einem angegebenen Format zurückgegeben.
Abbildung in dieser Leseprobe nicht enthalten
Vereinfacht könnte folgende Formel aufgestellt werden, wobei das Formular mit den Inhaltsdaten zu einem Dokument vermischt wird:
Dokument = Formular + Inhaltsdaten(Felddaten)
I.3 Zusätzliche Anforderungen
- Der Dokumentendienst soll keine fachlichen Abhängigkeiten zu den Anwendungen besitzen. Damit ist ein allgemeiner Einsatz durch Wiederverwendbarkeit der Quellcodes auch in anderen Projekten möglich.
- Die eigentliche Anwendung (Das Anwendungssystem, welche den Dokumentendienst aufruft) soll in ihrer Funktionsweise nicht beeinträchtigt werden, wenn der Dokumentendienst nicht verfügbar ist.
- Die Formulare sollen vom Dokumentengenerierungsdienst angesprochen werden, wobei diese in einem Formularrepository gehalten werden sollen. In diesem Repository sind jedoch nur die Metadaten zum Formular enthalten. Es soll erreicht werden, dass das Repository eine zentrale Konfigurationsdatei im XML-Format ist, aber die eigentlichen Formulare in einem bestimmten Formularpfad auf dem jeweiligen Dokumentengenerierungsdienst-Server verwaltet werden.
- Da die Formulare meist nicht direkt von einem Entwickler bzw. Programmierer generiert werden, sollte es eine zentrale Administration der Formulare geben.
Es muss somit die Möglichkeit bestehen, dass ein Formulardesigner die entwickelten Formulare auf einem Server hinterlegen kann, so dass diese sofort zur Verarbeitung von einem Anwendungssystem (Client) genutzt werden können.
I.4 Lösungsansatz
Die Diplomarbeit untersucht zwei verschiedene Anwendungen:
Der erste Teil der Diplomarbeit behandelt den Softwareentwicklungsprozess eines dynamischen Dokumentendienstservers. Dabei erfolgt die Dokumentengenerierung über den Formatting Objects Processor (FOP) in Verbindung mit Xalan von Apache ©.
In der Arbeit wird nur auf das Ausgabeformat PDF eingegangen, da der Acrobat Reader © sich in-zwischen auf dem Markt durchgesetzt hat und auf jedem Standardrechner installiert ist. Die gesamte Dokumentengenerierung erfolgt in einem Geschäftsprozess (Server-Komponente).
Im zweiten Teil der Diplomarbeit wird ein Demo-Client als Testwerkzeug für den Entwickler bzw. Formulardesigners implementiert (Client-Komponente).
Abbildung I.1: Grundsätzlicher Aufbau der Architektur
Abbildung in dieser Leseprobe nicht enthalten
Server-Komponente
Da für einen Dokumentendienstserver eine zentrale Administrationsumgebung, Skalierbarkeit sowie Portierbarkeit wichtige Voraussetzungen sind, wird für die Diplomarbeit eine ApplikationsserverLösung basierend auf dem J2EE-Standard verwendet.
Ein Server für die Dokumentengenerierung bietet vor allem Vorteile bei der Verwaltung von Formu-laren. Bei einer Nutzung des Dienstes ohne Server (Clientlösung), müssten alle Formulare auf das lokale Dateisystem vom Client transferiert werden, wobei ständig auf die Aktualität der Formulare zu achten ist.
Des Weiteren würde die gesamte Rechenzeit der Dokumentengenerierung auf dem Client geschehen. Dieses kann zu Einbußen der Performance führen. Durch diesen Performancedefizit können auch die eigentlichen Anwendungen betroffen sein, indem während des Dienstaufrufs diese in ihrer Funktionsweise beeinträchtigt werden.
Außerdem wird der Server von der Client-Komponente über eine EJB-Schnittstelle (Session Bean) angesprochen, so dass dem Client eine bedienerfreundliche Schnittstelle für die Dokumentengenerierung zur Verfügung steht. (siehe Abbildung I.1)
Client-Komponente
Die Client-Komponente ist als grafische Benutzeroberfläche (GUI) konzipiert und soll die Verbindung zur Server-Komponente veranschaulichen (Schnittstelle zum Server).
Um eine zentrale Verteilung (Deployment) der Clientapplikation zu ermöglichen, wird Java Web Start (JWS) von Sun in Verbindung mit einem Webserver (Apache) genutzt.
Die eigentliche Clientapplikation wird mit Java-Swing-Elementen realisiert.
I.5 Technische Umgebung
Diese Diplomarbeit wurde mit folgenden technischen Hilfsmitteln entwickelt: Rational Rose Enterprise Edition, Together 6.0, Java 2 SDK 1.4.0 mit Java Web Start, JCreator Pro V2.0, Apache Webserver und einer BEA Weblogic Applicationserver Instanz.
Im zweiten Teil der Diplomarbeit wird zur GUI-Implementierung der GUI-Designer von Borland (JBuilder 6.0 Enterprise Edition) genutzt.
Für die Formulargenerierung wird XSLFast von jCatalog © verwendet, wobei die fertigen Dokumente über den Acrobat Reader © von Adobe © angezeigt werden.
Kapitel II Server-Komponente zur Dokumentenerzeugung
Im ersten Teil wird der Softwareentwicklungsprozess eines dynamischen Dokumentengenerierungsdienstes dargestellt. In der Anforderungsanalyse werden zunächst die wichtigsten Use Cases (Anwendungsfälle) des zu entwickelnden Servers beschrieben. Außerdem werden Überlegungen zum Konfigurationsmanagement sowie zur Verwaltung der Formulare durchgeführt. Des Weiteren werden das Klassenmodell, Klassenbeschreibungen der jeweiligen Pakete sowie die Interaktionen der Klassen untereinander erläutert.
II.1 Anforderungsanalyse
II.1.1 Use Cases
Abbildung II.1: Use Cases des Dokumentengenerierungsdienstes
Abbildung in dieser Leseprobe nicht enthalten
1. Dokument erzeugen
Akteur :
Anwendungssystem
Zusammenfassung :
Der Use Case beschreibt die Generierung eines Dokuments für einen speziellen dynamischen Dokumentengenerierungsprozess (Job).
Beschreibung :
Eine vom Entwickler implementierte Anwendung (z.B. Ein Bestelldienst) erzeugt Daten (z.B. Name oder Bestellinformationen), welche später ausgedruckt werden sollen. Das Dokument wird durch den Dokumentengenerierungsdienst aus den angegebenen Inhaltsdaten und Jobpa-rametern erzeugt. Die Inhaltsdaten bestehen aus Schlüssel/Wert-Paaren. Der Schlüssel stellt den Platzhalter im Formular dar, welcher später durch den Wert ersetzt wird. Der Dienst lie-fert mit diesen Angaben ein fertiges Dokument zurück, welches anschließend gedruckt werden kann.
Vorbedingung :
1. Der Server muss gestartet sein.
2. Ein eindeutiges Formular mit Inhaltsdaten muss übergeben werden.
3. Die Jobparameter (z.B. Zielformat) für einen Dokumentengenerierungsprozess müssen ange- geben sein.
Ablauf :
Der Dienst „Dokument erzeugen“ wird mit den übergebenen Informationen aufgerufen.
Ergebnis :
Das generierte Dokument im angegebenen Format.
Ausnahmen :
1. Der Dokumentendienst ist nicht gestartet und kann die Anfragen nicht bearbeiten. Der Dienst muss gestartet werden.
2. Ein eindeutiger Formularname bzw. das Formular kann nicht gefunden werden. Das Formular muss dem Dienst bekannt gemacht werden.
3. Die Jobparameter werden vom Dienst nicht unterstützt oder sind nicht implementiert. Die ent- sprechenden Parameter müssen den Jobparametern hinzugefügt werden.
2. Formularkatalog besorgen
Akteur :
Anwendungssystem
Zusammenfassung :
Der Use Case beschreibt eine optionale Möglichkeit alle vorhandenen Formulare des Systems zu erfahren.
Beschreibung :
Der Formularkatalog beinhaltet alle im System bekannten Formulare. Dadurch kann überprüft werden, welche Formulare auf dem Server vorhanden sind.
Vorbedingung :
Der Server muss gestartet sein.
Ablauf :
Der Dienst „Formularkatalog besorgen“ wird aufgerufen.
Ergebnis :
Die Formularnamen aller vorhandenen Formulare im Repository des Servers.
Ausnahmen :
1. Der Dokumentendienst ist nicht gestartet und kann die Anfragen nicht bearbeiten. Der Dienst muss gestartet werden.
2. Es sind keine Formulare im Repository vorhanden. (Der Formularkatalog ist leer) Formulare müssen dem Dienst bekannt gegeben werden.
3. Formularvariableninformationen besorgen
Akteur :
Anwendungssystem
Zusammenfassung :
Der Use Case beschreibt eine optionale Möglichkeit Informationen über den Formularinhalt eines bestimmten Formulars zu erhalten (Metadaten zum Formularinhalt).
Beschreibung :
Dem Anwendungssystem werden Variablen, sonstige dynamischen Inhalte (Spaltennamen von Tabellen) sowie der physische Formularname des zu bearbeitenden Formulars mitgeteilt.
Vorbedingung :
1. Der Server muss gestartet sein.
2. Eine entsprechende Formularinhaltsinformation muss vorliegen.
Ablauf :
Der Dienst „Formularvariableninformationen besorgen“ wird mit dem entsprechenden Formularnamen aufgerufen.
Ergebnis :
Alle vorhandenen Variablennamen und deren Beschreibungen werden in einer Liste zurückge-geben.
Ausnahmen :
1. Der Dokumentendienst ist nicht gestartet und kann die Anfragen nicht bearbeiten. Der Dienst muss gestartet werden.
2. Es sind keine Formulare im Repository vorhanden. (Der Formularkatalog ist leer) Formulare müssen dem Dienst bekannt gegeben werden.
3. Das angefragte Formular ist nicht im Repository vorhanden.
Bei der Anforderungsanalyse der Formularerstellung handelt es sich um ein Vorgehensmodell ein Formular zu erstellen und dieses anschließend dem Dienst zu übermitteln.
Die Anwendungsfälle enthalten keine Implementierungsabsichten und dienen als zusätzlicher Informationsträger zum eigentlichen Dienst.
Abbildung II.2: Use Cases zur Formularerstellung
Abbildung in dieser Leseprobe nicht enthalten
4. Formular erstellen
Akteur :
Formulardesigner (Administrator)
Zusammenfassung :
Der Use Case beschreibt die Erstellung eines Formulars.
Beschreibung :
Mit einem unabhängig vom Dienst genutzten Formulardesigner (hier XSLFast von jCatalog ©), wird ein Formular erstellt. Nach der Erstellung wird das Formular in einem bestimmten Format gespeichert (hier im XSL-Format).
Vorbedingung :
Informationen über Variableninhalt und das Layout müssen dem Dokumentengenerierungsdienst vorliegen. Eine entsprechende Formularinhaltsinformation muss vorliegen.
Ablauf :
1. Der Bediener erzeugt ein Formular mit Platzhaltern für die dynamischen Daten.
2. Das Formular ist in einem bestimmten Format gespeichert
(bestehendes Formularverzeichnis des Servers).
Ergebnis :
Ein generiertes Formular mit statischem und/oder dynamischem Inhalt in einem bestimmten Format und Formularverzeichnis auf dem Dateisystem gespeichert.
Ausnahmen :
Der Formulardesigner ist nicht installiert oder gestartet.
Der Formulardesigner muss installiert und gestartet werden.
[...]