Warenkorb
0 Artikel | US$ 0,00
ID 6173
Gerlicher, Ansgar: Konzeption und Realisierung einer webbasierten Anwendung mit dem
Java (TM) 2 Enterprise Edition Framework - Am Beispiel eines Systems zur
Unterstützung der Übersetzung von Arbeitstexten in der Automobilindustrie
Hamburg: Diplomica GmbH, 2002
Zugl.: Stuttgart, Fachhochschule, Diplomarbeit, 2001
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
Inhalt
Diplomarbeit Ansgar Gerlicher
iii
KAPITEL 1.
Einleitung
1
1.1. Aufbau der Diplomarbeit
- - - - - - - - - - - - - - - - - - - - 3
KAPITEL 2.
Motivation & Zielsetzung
5
2.1. Das Problem
- - - - - - - - - - - - - - - - - - - - - - - - - 5
2.2. Die Lösung
- - - - - - - - - - - - - - - - - - - - - - - - - - 7
KAPITEL 3.
Anforderungsanalyse
9
3.1. Erste Use Cases
- - - - - - - - - - - - - - - - - - - - - - - - 11
3.1.1. ToDo-Liste checken:
- - - - - - - - - - - - - - - - - - - - - - - 11
3.1.2. Liste zu langer Textbausteinkombinationen checken:
- - - - - - - - - 11
3.1.3. Textbaustein übersetzen:
- - - - - - - - - - - - - - - - - - - - - 11
3.1.4. Textbaustein kürzen:
- - - - - - - - - - - - - - - - - - - - - - - 12
3.2. Main Use-Case
- - - - - - - - - - - - - - - - - - - - - - - - 13
3.3. Use-Case Text suchen
- - - - - - - - - - - - - - - - - - - - - 14
3.4. Use-Case ,,Übersetzungsstatistik betrachten"
- - - - - - - - - - - 17
3.5. Use-Case ,,ToDo-Liste checken"
- - - - - - - - - - - - - - - - - 19
3.5.1. Aufbau der ToDo-Liste
- - - - - - - - - - - - - - - - - - - - - - 20
3.5.2. ToDo-Liste Szenario
- - - - - - - - - - - - - - - - - - - - - - - 21
3.6. Use-Case,,Textbaustein bearbeiten"
- - - - - - - - - - - - - - - 24
3.6.1. Ablauf der Textbaustein kürzen und übersetzen Use-Cases
- - - - - - 26
3.6.2. Textbaustein bearbeiten Szenario
- - - - - - - - - - - - - - - - - 27
3.6.3. Die Benutzerschnittstelle des Übersetzungsdialogs
- - - - - - - - - - 28
3.6.3.1. Textprüfung
- - - - - - - - - - - - - - - - - - - - - - - - - 30
3.6.3.2. AWAT/STARI Prüfung
- - - - - - - - - - - - - - - - - - - - 31
3.6.4. Textliste
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 31
3.7. Use-Case ,,Liste zu langer Textbausteinkombinationen checken"
- - 34
3.7.1. Performanz des Use-Case zu lange Textbausteinkombinationen checken
37
3.7.2. Die Benutzerschnittstelle zu lange Textbausteinkombinationen checken
40
3.8. Use-Case ,,zu lange Textbausteinkombination bearbeiten"
- - - - - 42
3.8.1. Ablauf des Use-Case ,,zu lange Textbausteinkombination bearbeiten"
- 43
3.8.2. Zu lange Textbausteinkombination bearbeiten Szenario
- - - - - - - - 44
3.8.3. Benutzerschnittstelle zu lange Textbausteinkombination bearbeiten
- - 45
3.9. Erweiterte Anforderungen
- - - - - - - - - - - - - - - - - - - 47
3.9.1. Der Login Dialog
- - - - - - - - - - - - - - - - - - - - - - - - 47
3.9.2. Das Anwendungsmenü
- - - - - - - - - - - - - - - - - - - - - - 48
3.9.3. Das Startmenü
- - - - - - - - - - - - - - - - - - - - - - - - - - 49
KAPITEL 4.
Analyse & Design
51
4.1. Model-View-Controller
- - - - - - - - - - - - - - - - - - - - - 51
4.2. Die Java 2 Enterprise Edition Architektur
- - - - - - - - - - - - - 53
4.2.1. Multi-Tier Modell
- - - - - - - - - - - - - - - - - - - - - - - - 53
4.2.2. Client-Tier
- - - - - - - - - - - - - - - - - - - - - - - - - - - 54
4.2.3. Web-Tier
- - - - - - - - - - - - - - - - - - - - - - - - - - - - 55
4.2.4. EJB-Tier
- - - - - - - - - - - - - - - - - - - - - - - - - - - - 56
4.2.5. EIS-Tier
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 56
4.3. Architekturüberlegungen
- - - - - - - - - - - - - - - - - - - - 57
4.3.1. EJB-Zentrische Anwendung
- - - - - - - - - - - - - - - - - - - - 57
Inhalt
Diplomarbeit Ansgar Gerlicher
iv
4.3.2. Controller Komponenten
- - - - - - - - - - - - - - - - - - - - - 57
4.3.2.1. Frontkomponente
- - - - - - - - - - - - - - - - - - - - - - - 59
4.3.2.2. RequestProcessor
- - - - - - - - - - - - - - - - - - - - - - - 59
4.3.2.3. WebController
- - - - - - - - - - - - - - - - - - - - - - - - 59
4.3.2.4. EJBController
- - - - - - - - - - - - - - - - - - - - - - - - - 59
4.4. Analyse
- - - - - - - - - - - - - - - - - - - - - - - - - - - 60
4.4.1. Der Übersetzer
- - - - - - - - - - - - - - - - - - - - - - - - - - 60
4.4.2. Das Account Objekt
- - - - - - - - - - - - - - - - - - - - - - - 61
4.4.3. Textsuche
- - - - - - - - - - - - - - - - - - - - - - - - - - - - 62
4.4.4. Die ToDo-Liste
- - - - - - - - - - - - - - - - - - - - - - - - - 63
4.4.5. Textbausteine
- - - - - - - - - - - - - - - - - - - - - - - - - - 65
4.4.6. Der Übersetzungsdialog
- - - - - - - - - - - - - - - - - - - - - - 69
4.4.7. Die Textliste
- - - - - - - - - - - - - - - - - - - - - - - - - - - 71
4.4.8. Übersetzungsstatistik
- - - - - - - - - - - - - - - - - - - - - - - 72
4.4.9. Liste zu langer Textbausteinkombinationen
- - - - - - - - - - - - - 73
4.4.10. Zu lange Textbausteinkombination bearbeiten
- - - - - - - - - - - 74
4.4.11. StateMachine
- - - - - - - - - - - - - - - - - - - - - - - - - - 76
4.4.12. Der ModelUpdateManager
- - - - - - - - - - - - - - - - - - - - 77
4.4.13. Die Events
- - - - - - - - - - - - - - - - - - - - - - - - - - - 77
4.4.14. Der ModelManager
- - - - - - - - - - - - - - - - - - - - - - - 78
4.4.15. Der ScreenFlowManager
- - - - - - - - - - - - - - - - - - - - - 79
4.5. Design
- - - - - - - - - - - - - - - - - - - - - - - - - - - - 83
4.5.1. Servlets
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 83
4.5.2. Java Server Pages
- - - - - - - - - - - - - - - - - - - - - - - - 83
4.5.3. TagLibraries und Custom Tags
- - - - - - - - - - - - - - - - - - 84
4.5.4. XML
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 84
4.5.5. EJBs
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 86
4.5.6. Design am Beispiel
- - - - - - - - - - - - - - - - - - - - - - - - 87
4.5.7. Exceptions
- - - - - - - - - - - - - - - - - - - - - - - - - - - 90
4.5.8. Der Aufbau eines Views
- - - - - - - - - - - - - - - - - - - - - 91
4.5.9. Einlesen der XML Dateien
- - - - - - - - - - - - - - - - - - - - 93
4.5.10. Wahl des RequestHandler
- - - - - - - - - - - - - - - - - - - - 94
4.5.11. Der SearchWebHandler
- - - - - - - - - - - - - - - - - - - - - 95
4.5.12. Der SearchFlowHandler
- - - - - - - - - - - - - - - - - - - - - 96
4.5.13. Der Insert Custom Tag
- - - - - - - - - - - - - - - - - - - - - - 97
4.5.14. Das SearchBean
- - - - - - - - - - - - - - - - - - - - - - - - 98
4.5.15. Die SearchWebImpl
- - - - - - - - - - - - - - - - - - - - - - - 99
4.5.16. Der SearchEvent
- - - - - - - - - - - - - - - - - - - - - - - - 100
4.5.17. Der SearchEJBHandler
- - - - - - - - - - - - - - - - - - - - - 100
4.5.18. Die Liste geänderter Models
- - - - - - - - - - - - - - - - - - - 101
4.5.19. Der SearchContextEJB
- - - - - - - - - - - - - - - - - - - - - 102
4.5.20. Das SearchDAOEJB
- - - - - - - - - - - - - - - - - - - - - - 103
4.5.21. Ausnahmen der Architektur
- - - - - - - - - - - - - - - - - - - 104
KAPITEL 5.
Implementierung
105
5.1. Java
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 105
5.2. Alternative Plattformen
- - - - - - - - - - - - - - - - - - - - - 105
5.3. Die Entwicklungsumgebung
- - - - - - - - - - - - - - - - - - 106
5.3.1. JBuilder
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 106
5.3.1.1. Entitiy Bean Modeler
- - - - - - - - - - - - - - - - - - - - - 107
5.3.1.2. Java Bean Wizard
- - - - - - - - - - - - - - - - - - - - - - - 107
5.3.1.3. JBuilder EJB Container
- - - - - - - - - - - - - - - - - - - - 107
5.3.1.4. Inprise Application Server
- - - - - - - - - - - - - - - - - - - 108
5.3.2. Die J2EE Referenzimplementierung
- - - - - - - - - - - - - - - - 108
Inhalt
Diplomarbeit Ansgar Gerlicher
v
5.3.3. Das Application Deployment Tool
- - - - - - - - - - - - - - - - - 109
5.3.4. Funktionsschwächen und Fehlerquellen
- - - - - - - - - - - - - - - 110
5.3.4.1. Debugging
- - - - - - - - - - - - - - - - - - - - - - - - - - 110
5.3.4.2. Erneutes Deployen nach Änderung
- - - - - - - - - - - - - - - 110
KAPITEL 6.
Test
113
6.1. Vorgehensweise
- - - - - - - - - - - - - - - - - - - - - - - - 113
6.2. Performanz
- - - - - - - - - - - - - - - - - - - - - - - - - - 114
6.2.1. Enterprise JavaBeans
- - - - - - - - - - - - - - - - - - - - - - - 114
6.2.1.1. Overhead
- - - - - - - - - - - - - - - - - - - - - - - - - - - 115
6.2.1.2. Restriktionen
- - - - - - - - - - - - - - - - - - - - - - - - - 115
6.2.1.3. Performanz gegen Stabilität
- - - - - - - - - - - - - - - - - - 116
6.2.1.4. Perfomanzunterschiede zwischen EJB Typen
- - - - - - - - - - - 116
6.3. Einsatz der Beans
- - - - - - - - - - - - - - - - - - - - - - - 118
KAPITEL 7.
Deployment
119
7.1. Topologie
- - - - - - - - - - - - - - - - - - - - - - - - - - - 119
7.2. Das Application Deployment Tool
- - - - - - - - - - - - - - - - 121
7.3. JARs, WARs und Deployment Descriptoren
- - - - - - - - - - - 123
7.3.1. JARs
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 123
7.3.2. WARs
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 123
7.3.3. Deployment Descriptor
- - - - - - - - - - - - - - - - - - - - - - 123
7.3.3.1. EJB strukturelle Informationen:
- - - - - - - - - - - - - - - - - 123
7.3.3.2. Informationen zum Anwendungsaufbau:
- - - - - - - - - - - - - 123
KAPITEL 8.
Zusammenfassung & Ausblick
125
Abbildungsverzeichnis
129
Literaturverzeichnis & CD-ROM
131
Glossar
133
Diplomarbeit Ansgar Gerlicher
1
KAPITEL 1
Einleitung
Die Entwicklung webbasierter Software Systeme und Anwendungen ist ein Thema mit
dem sich zur Zeit immer mehr Firmen beschäftigen. Eine verteilte webbasierte
Anwendung bringt viele Vorteile mit sich.
Auf eine Web Anwendung kann mit Hilfe eines standard Web Browsers zugegriffen
werden. Dies erspart eine aufwändige Installation und Wartung von Client Software.
Software Updates können zentral durchgeführt werden und stehen allen Clients sofort
zur Verfügung. Die Web-Anwendung kann auch sehr leicht einer großen Benutzergruppe
zugänglich gemacht werden, ohne große Vertriebswege zu benötigen. Auch für den
Entwickler einer webbasierten Anwendung gibt es Vorteile. Er spart sich viel Arbeit bei
der Programmierung einer Client Software, denn ein Web Browser stellt schon viel
Basisfunktionalität zur Verfügung (z.B. Unicode Unterstützung). Diese Eigenschaften
machen sich z.B. sogenannte Application Service Provider (ASP) zu nutze und stellen
verschiedene webbasierte Dienste und Anwendungen, wie z.B. vertikale (,,B-2-B") und
horizontale (,,Nischen" und Endanwender) Portale, zur Verfügung. Das mySAP
Enterprise
Portal der Firma SAP
(TM)
ist dafür ein Beispiel.
Der Trend hin zu verteilten webbasierten Anwendungen nimmt also zu und es gibt
mittlerweile viele Technologien, um solche Systeme zu realisieren. Zwei Beispiele dafür
sind die Active Server Pages
1
(ASP) und Hypertext Preprocessor
2
(PHP) . ASP sind,
genau wie PHP , Technologien um dynamische Webseiten und damit webbasierte
Anwendungen zu erstellen. Diese Technologien basieren auf Skript-Code, der in einer
HTML
3
Seite eingebettet und bei einer Anfrage eines Client Browsers zur Laufzeit
1. Microsoft
2. Apache Software Foundation
3. HyperText Markup Language
Einleitung
2
Diplomarbeit Ansgar Gerlicher
interpretiert wird. Es ist damit möglich, sehr schnell und effizient verteilte webbasierte
Anwendungen zu entwickeln, solange die Komplexität dieser Anwendungen in einem
gewissen Rahmen bleibt. Eine weitere Technologie für die Entwicklung webbasierter
Anwendungen, die den beiden oben genannten sehr ähnlich ist, ist die Java Server
Pages
4
(JSP) Technologie. Diese Technologie basiert im Gegensatz zu ASP und PHP auf
der stark typisierten, objektorientierten Sprache Java.
Je nach Anforderung an die umzusetzende Anwendung, gilt es die richtige Wahl der
verwendeten Technologie zu treffen. Ausschlaggebend für diese ist der Anwendungsfall.
Für kleinere Projekte sind durchaus skriptbasierte Technologien wie z.B. PHP, ASP oder
JSP ideal, die geringe Anforderungen an den Entwickler sowie die zugrunde liegende
Plattform stellen. Wird ein verteiltes System komplexer, so mangelt es den
skriptbasierten Systemen oft an einfacher Erweiterbarkeit und Performanz, was zum
großen Teil auch mit der Tatsache zusammenhängt, daß oft typenlose, oder schwach
typisierte Sprachen zum Einsatz kommen. Ein Nachteil dieser Programmiersprachen
gegenüber stark typisierten und objektorientierten Sprachen ist, daß im Allgemeinen bei
steigender Komplexität, der Programmieraufwand exponential ansteigt. Die JSP
Technologie bringt, unter anderem, die Vorteile einer objektorientierten Sprache mit
sich. Für sehr große und komplexe Anwendungen ist dies alleine aber nicht ausreichend.
Das hauptsächliche Problem ist, daß bei den genannten Technologien, die
Anwendungslogik immer mit der Präsentationslogik gekoppelt vorliegt. Man möchte
diese aber trennen, da bei der Entwicklung einer großen Anwendung oft verschiedene
spezialisierte Teams beteiligt sind. Ein Team mit Grafikdesignern kümmert sich dabei
z.B. um das Design, ein anderes mit Webprogrammierern um die Präsentationslogik und
ein drittes mit Anwendungsentwicklern und Datenbankspezialisten um die
Anwendungslogik und die Datenbankzugriffe. Um dies zu erreichen wurde mit der Java 2
Enterprise Edition
5
eine Plattform geschaffen, die diese Trennung vollzieht. Die
Präsentationslogik wird hier in einem sogenannten WebContainer z.B. von JSPs
abgehandelt, während die Anwendungslogik im EJBContainer
6
in sogenannten
Enterprise Beans liegt. Die J2EE Technologie verspricht durch eine komponentenbasierte
Architektur gute Erweiterbarkeit, Skalierbarkeit, Flexibiliät und Performanz.
4. SUN Microsystems
5. http://java.sun.com/j2ee/
6. EJB: Enterprise Java Bean. Siehe Kapitel Analyse & Design zur Erklärung von WebContainer und EJBContainer
Aufbau der Diplomarbeit
Diplomarbeit Ansgar Gerlicher
3
Diese Arbeit befaßt sich mit der Realisierung einer webbasierten verteilten Anwendung
unter Verwendung des Java 2 Enterprise Edition Framework. Das Anwendungsdesign
orientiert sich am Java Application Programming Model von SUN
7
.
Die Wahl zur Java Technologie fiel auch aufgrund der immer größer werdenden
Verbreitung und der damit verbundenen einfacheren Integrationsfähigkeit und
Anpassbarkeit an andere relevante Systeme. Im Vordergrund stand auch die
Erweiterbarkeit und Flexibilität der Anwendung, um sie möglichst einfach von einem
bestehenden System in ein neues, sich zur Zeit noch in der Entwicklung befindendes
System, überführen zu können. Außerdem war es wichtig Erfahrungswerte für spätere
Projekte zu sammeln, die mit der gleichen Technologie umgesetzt werden sollen.
Die Umsetzung des Systems orientiert sich an den Vorschlägen des Rational Unified
Process (RUP)
8
. Für die Konzeption und Beschreibung der Anwendung und deren Abläufe
wurde die Unified Modeling Language (UML) eingesetzt.
1.1 Aufbau der Diplomarbeit
·
Das Kapitel Motivation und Zielsetzung geht kurz auf den Geschäftsbereich (das
Business) und dessen Problematik ein und wie eine Lösung dieser Problematik
aussehen könnte.
·
Danach werden im Kapitel Anforderungsanalyse die Anforderungen, die an das
System gestellt wurden, beschrieben und spezifiziert.
·
Im Kapitel Analyse & Design wird auf die verwendete Architektur und deren Aufbau
eingegangen. Danach wird aus der Anforderungsspezifikation das Anwendungsdesign
abgeleitet und anhand eines Beispiels erklärt.
·
Das Kapitel Implementierung geht auf die Entwicklungsumgebung ein. Es wird erklärt
mit welchen Tools entwickelt wurde und welche Schwierigkeiten es dabei gab.
·
Das Kapitel Test geht auf die Vorgehensweise beim Testen und auf die Performanz der
verschiedenen Enterprise Bean Typen ein.
·
Deployment (Verteilung) ist das Thema in Kapitel 7. Hier wird auf eine mögliche
Rechnertopologie eingegangen. Danach wird kurz das Vorgehen bei der Installation
erklärt.
7. Wie beschrieben in: Nicholas Kassem and the Enterprise Team. Designing Enterprise Applications. SUN Microsystems,
2000. Web: http://java.sun.com/j2ee/blueprints/eis_tier/application_programming/index.html
8. RUP ist ein Software-Engineering-Prozeß: s. Kruchten, Philippe. Der Rational Unified Process. Addison-Wesley, 1999,
S. 17
Diplomarbeit Ansgar Gerlicher
5
KAPITEL 2
Motivation & Zielsetzung
DaimlerChrysler entwickelt, produziert und vermarktet Fahrzeuge verschiedener
Sparten, im Wesentlichen PKW und Nutzfahrzeuge. Die Fachabteilung GSP hat die
Aufgabe, Arbeitstexte und Richtzeiten zu erstellen, zu standardisieren und zu
publizieren. Diese Texte und Zeiten bilden die Datenbasis, auf der die DaimlerChrysler
Werkstätten Reparaturaufträge und Rechnungen erstellen.
Die Übersetzung dieser Texte in 18 Sprachen wird von DaimlerChrysler internen
Übersetzern (auch außerhalb Deutschlands) oder auch externen Dienstleistern realisiert.
Zur Zeit gibt es zwei Arten wie die Texte übersetzt werden. Zum einen existiert eine
Implementierung eines Pflegesystems (ASRA), die eine Online-Übersetzung ermöglicht.
Aufgrund technischer Limitationen (keine UNICODE-Fähigkeit) ist dieses Pflegesystem
aber nur für west-europäische Sprachen (wie z.B. Englisch) einsetzbar. Alle anderen
Sprachen, wie z.B. Japanisch, werden über ein offline-System übersetzt. Das bedeutet,
daß regelmäßig Übersetzungsaufträge für diese Sprachen erstellt werden, die den
(externen oder internen) Dienstleistern zugeschickt werden. Die Abbildung 2.1. zeigt das
,,Business" in einem Business Use-Case Model.
2.1 Das Problem
Gab es in der Vergangenheit bei DaimlerChrysler neue Arbeitstexte zu übersetzen, so
wurden bisher aus einer Datenbank für jede Sprache verschiedene Textdateien
generiert. Den Übersetzern wurden dann die Textdateien zugeschickt, sie erstellten darin
die Übersetzungen und schickten die Dateien dann wieder zurück. Diese Textdateien
enthielten unter anderem die Quelltexte, Textreferenzen und Steuerzeichen. Die
Textreferenzen sollten dem Übersetzer beim Bearbeiten der Quelltexte (die meist in
Deutsch waren) eine Hilfe sein, in dem sie den, zu übersetzenden Textbaustein, in einem
Motivation & Zielsetzung
6
Diplomarbeit Ansgar Gerlicher
anderen Kontext zeigten. Die Steuerzeichen gaben an, wo der Übersetzer genau seine
Übersetzung eingeben mußte und sollten dem System helfen, die Übersetzungen später
wieder automatisiert in die Datenbank einzupflegen.
Hatte der Übersetzter nun zum Beispiel ein Steuerzeichen aus Versehen überschrieben,
war der ganze Text nutzlos, denn er konnte nicht mehr fehlerfrei eingelesen werden.
Auch war es ein großer Verwaltungsaufwand, jedem Übersetzer die richtige Textdatei
zukommen zu lassen und diese, wenn sie vom Übersetzer zurückkam, wieder richtig
einzusortieren. Problematisch war auch die Kompatibilität der Texte zu bestehenden
Darstellungssystemen. D.h. die Texte durften nur bestimmte Zeichen enthalten und
Texte, die aus Textbausteinen zusammengesetzt wurden, durften eine vorgeschriebene
Gesamtlänge nicht überschreiten. Hatte ein Übersetzer z.B. ein unerlaubtes Zeichen
verwendet, mußte der Fehler gefunden werden und die Prozedur begann von neuem.
Nach der Übersetzung aller Texte wurde die Länge der Textbausteinkombinationen
überprüft und zu lange Textbausteine gekürzt. Dies war äußerst aufwendig.
Heute gibt es für die west-europäischen Sprachen ein Online-System zur Übersetzung
von Texten (ASRA). Dieses System wurde in Smalltalk entwickelt und basiert auf einem
Smalltalk Client, der eine Verbindung zur Datenbank aufbaut, in der die Texte
gespeichert sind. Dieser Client hat den Nachteil, daß er bei jedem Übersetzer einmal
ABBILDUNG 2.1.
Business Use-Case Modell
WIS - Werkstatt Informations System
Fachabteilung
Daten administrieren
Texte online übersetzen
Texte einpflegen
Übersetzungsaufträge
herausgeben
Übersetzer
Texte offline übersetzen
Werkstatt
verwendet
erstellt und publiziert
bekommt Auftrag
bekommt
übersetzt
Die Lösung
Diplomarbeit Ansgar Gerlicher
7
installiert werden muß und daß viele Berechnungen auf dem Client Rechner geschehen,
wodurch das System oft überlastet ist.
Für die anderen 14 Sprachen wie z.B. Japanisch, Chinesisch, Russisch, Griechisch usw.
gibt es dieses Online-System noch nicht. Diese werden wie oben beschrieben offline
übersetzt.
2.2 Die Lösung
Das neue System soll nun diesen Übersetzungsprozess vereinfachen und ihn vor allem
effektiver machen. Dabei hat man sich mittlerweile darauf geeinigt ein browserbasiertes
System zu entwickeln, da es weltweit eingesetzt werden soll und man sich den hohen
Installationsaufwand, den man zur Zeit mit dem Smalltalk Client hat, ersparen will. Jeder
Übersetzer soll das System über ein Webinterface verwenden können.
Was bei der Problembeschreibung als erstes auffällt ist, daß der Übersetzer auf
aufwendige Weise mitgeteilt bekommt, welche Texte er zu übersetzen hat. Er bekommt
halbjährlich eine Textdatei zugeschickt in der alle zu übersetzenden Texte aufgeführt
sind, die innerhalb dieses Zeitraumes angefallen sind. Diese Texte könnten eigentlich
Stück für Stück bearbeitet werden, denn sie entstehen ja nicht alle auf einmal. Das
System soll dem Übersetzer also eine Möglichkeit bieten, um zu sehen, ob neue Texte
angefallen sind. Diese soll er jederzeit - also nicht erst nach einem halben Jahr -
übersetzen können.
Wenn man das Problem weiter betrachtet, erkennt man, daß eine häufige Fehlerquelle
die Steuerzeichen in der Textdatei sind, die aus Versehen überschrieben werden. Also
braucht der Übersetzer eine Eingabemaske, die ihm hilft, den übersetzten Text
einzugeben, ohne dabei Steuerzeichen beachten zu müssen. Die Maske soll den
Quelltext anzeigen und darüberhinaus, soll eine Hilfe durch Textreferenzen gegeben
werden.
Wenn er mit der Übersetzung eines Textes fertig ist, soll der Text direkt in die Datenbank
eingetragen werden, um sofort für das System zur Verfügung zu stehen. Außerdem muß
der Textbaustein gleichzeitig auf unerlaubte Zeichen überprüft werden und falls welche
vorhanden sind, muß der Übersetzer direkt darauf aufmerksam gemacht werden. Die
Kürzung der zu langen Textbausteinkombinationen soll auch vereinfacht werden. Dazu
soll es eine Liste geben, die alle zu langen Textbausteinkombinationen aufführt. Die
einzelnen Textbausteinkombinationen sollen dabei in ihre Textbausteine differenziert
werden und somit die Wahl, welcher Textbaustein gekürzt wird, vereinfachen. Dies alles
Motivation & Zielsetzung
8
Diplomarbeit Ansgar Gerlicher
sind Funktionalitäten, die teilweise auch von der bisherigen Online-Implementierung
bereitgestellt wurden, nun aber auch für alle Sprachen zur Verfügung stehen sollen. Es
werden die Funktionen, die das System haben soll, noch einmal zusammengefasst:
Funktionale Anforderugen:
1.
Der Übersetzer soll checken können, ob neue Texte zum Übersetzen vorhanden sind:
ToDo-Liste checken.
2.
Er soll Texte einfach ohne weitere Umstände übersetzen können und dabei eine
zusätzliche Hilfestellung durch Textreferenzen bekommen. Nach dem Übersetzen
sollen die Texte geprüft und gespeichert werden können und dann dem System sofort
zur Verfügung stehen. Es soll also die Online-Übersetzung für alle Sprachen (inkl.
Japanisch etc.), d.h. UNICODE-Fähigkeit der Applikation und Anbindung an die
Datenbank, möglich gemacht werden. Die Übersetzungstätigkeit soll optimiert
werden: Text übersetzen.
3.
Der Übersetzer soll sehen können, welche Textbausteinkombinationen zu lange Texte
ergeben: Liste zu langer Textbausteinkombinationen checken.
4.
Ein Textbaustein soll einfach gekürzt werden können: Textbaustein kürzen.
Nicht-funktionale Anforderungen:
1.
Anwenderfreundlichkeit: Der Übersetzer hat eine komfortable Eingabemaske und
kann sich seine Arbeitszeit frei einteilen. Das System soll die Eingabemöglichkeit für
spezielle Sprachen erlauben (Betriebssystemunterstützung, z.B. IMEs = Input
Method Editors).
2.
Zuverlässigkeit: Es wird sichergestellt, das keine falschen Zeichen eingegeben
werden können, oder Steuerzeichen überschrieben werden, was zu fehlerhaften
Übersetzungen führt. Korrekte Darstellung der Zeichensätze auf dem Bildschirm.
3.
Performance: Der Übersetzungsprozeß kann viel schneller ablaufen als bisher, da es
weniger Overhead gibt und z.B. keine Textdateien mehr erstellt und verschickt
werden müssen. Das alte Online-System wird durch ein leistungsfähigeres System
ersetzt.
4.
Wartbarkeit: Anpassung der Applikation an das verteilte Einsatzgebiet im Intranet,
d.h. keine aufwändige Client-Installation durch eine browserbasierte Anwendung.
Es soll also eine neues System entwickelt werden, das nicht nur das alte System ablöst,
sondern den Übersetzungsprozess insgesamt und auch für die anderen 14 Sprachen
vereinfacht und den Administrationsaufwand verringert.
Diplomarbeit Ansgar Gerlicher
9
KAPITEL 3
Anforderungsanalyse
Eine Aufgabe der Anforderungs- (Requirement-) Analyse besteht darin, eine
Übereinkunft mit dem Kunden und den Anwendern (Stakeholders) über das zu erreichen,
was das System eigentlich leisten soll. Weiter soll sie den System-Entwicklern ein
besseres Verständnis von den Anforderungen an das System vermitteln und die
Funktionen des Systems definieren
1
.
Von Hewlett-Packard wurden in Zusammenarbeit mit DaimlerChrysler zu diesem Zweck
Dokumente erstellt, die eine Vision des Systems mit den funktionalen und nicht-
funktionalen Anforderungen textuell beschreiben.
2
Da es leider in diesem Projekt nicht
möglich war, direkt mit den Stakeholdern in Kontakt zu treten um, wie das eigentlich
üblich wäre, nach einer ersten Iteration die Anforderungen zu reviewen,
Änderungswünsche aufzunehmen (Änderungsmanagement) und Unklarheiten zu
beseitigen, wurde die Anforderungsanalyse von diesen Dokumenten ausgehend
vollzogen. Bei Unklarheiten, übernahm die Rolle der Stakeholder soweit möglich mein
Betreuer René Morcinietz. Auch existierte schon eine Demoanwendung an der man sich
orientieren konnte.
Für die Planung der technischen Inhalte der einzelnen Iterationen, die Abschätzung der
Kosten und der benötigten Entwicklungszeit, bildet die Anforderungsanalyse die Basis.
Zusätzlich soll sie eine Benutzerschnittstelle für das System beschreiben. Auf die Kosten
und die Entwicklungszeit wird hier allerdings nicht eingegangen, da diese Diplomarbeit
technisch orientiert ist und daher keine wirtschaftlichen Aspekte beinhaltet. Obwohl
diese Thematik in der Praxis äußerst entscheidend und meist für den Projekterfolg bzw.
den Projektstart ausschlaggebend ist.
1. Vgl. Kruchten, Philippe. Der Rational Unified Process. Addison-Wesley, 1999, S. 141
2. Siehe Anhang: Atramo-Spezifikation.
Anforderungsanalyse
10
Diplomarbeit Ansgar Gerlicher
Zum Begriff der Anforderung:
·
Eine Anforderung ist eine Bedingung oder eine Fähigkeit, der ein System entsprechen
muß.
·
Man kann sie in zwei Kategorien unterteilen: funktionale- und nicht-funktionale
Anforderungen.
Dieses Kapitel beschreibt mit Unterstützung der UML die funktionalen und nicht-
funktionalen Anforderungen an das System, so wie sie auch in dieser Arbeit umgesetzt
wurden. Auf dieser Ebene wird noch nicht auf die verwendete Technologie eingegangen,
es geht rein um das was die Anwendung machen soll. Wie das ganze dann realisiert ist,
steht in einem anderm Kapitel. Abbildung 3.1. zeigt ein erstes Use-Case Model.
In diesem Modell gibt es drei Akteure. Der Übersetzer ist dabei der wichtigste, denn
vorallem für ihn soll dieses neue System eine Erleichterung sein. Die Fachabteilung ist
natürlich auch sehr daran interessiert, denn sie muß die gesamten Texte einpflegen.
Dies macht sie über ein anderes System (ASRA Editorial System). Die ASRA Datenbank
speichert alle Texte. Auf sie greift auch unser neues Übersetzungssystem, hier ASRA
Translation Module genannt, zu. Aus dieser Datenbasis wird die ToDo-Liste dann
generiert.
ABBILDUNG 3.1.
Erstes Use-Case Modell
ASRA Translation Module
ASRA Editorial System
Übersetzer
Texte einpflegen
Textbaustein übersetzen
To Do Liste checken
Textbaustein kürzen
Liste zu langer
Textbausteinkombinationen
checken
ASRA
Fachabteilung
Erste Use Cases
Diplomarbeit Ansgar Gerlicher
11
Das ,,ToDo-Liste checken" hat für den Übersetzer den Vorteil, daß er seine Zeit frei
einteilen kann und nicht alle Texte auf einmal übersetzen muß. Für die Fachabteilung hat
es den Vorteil, daß der Aufwand die Textdateien zu verschicken wegfällt, da sich jeder
Übersetzer selbstständig um seine Arbeit kümmern kann. Ähnlich verhält es sich beim
,,Liste zu langer Textbausteinkombinationen checken". Hier generiert das System auf
Anfrage des Übersetzers eine Liste zu langer Textbausteinkombinationen. Der
Übersetzer kann nun eine Kombination auswählen und dann die entsprechenden
Textbausteine kürzen.
3.1. Erste Use Cases
Im Folgenden, werden die einzelnen Use-Cases im Modell genauer besprochen.
3.1.1. ToDo-Liste checken:
Flow of Events :
Basic Flow:
1. Der Übersetzer wählt aus dem Startmenü den Punkt ,,ToDo-Liste"
2. Die ToDo-Liste wird angezeigt
Preconditions:
· Übersetzer muß angemeldet sein
· Das Startmenü wird angezeigt
3.1.2. Liste zu langer Textbausteinkombinationen checken:
Flow of Events :
Basic Flow:
1. Der Übersetzer wählt aus dem Startmenü den Punkt ,,zu lange Texte"
2. Die Liste der zu langen Textbausteinkombinationen wird angezeigt
Special Requirements:
· Der Übersetzer muß in eine Sprache übersetzen, die bestimmte Textlängen vor
schreibt (nach AWAT/STARI)
Preconditions:
· Übersetzer muß angemeldet sein
· Das Startmenü wird angezeigt
3.1.3. Textbaustein übersetzen:
Flow of Events :
Basic Flow:
1. Der Übersetzer wählt aus dem Startmenü den Punkt ,,ToDo-Liste"
2. Die ToDo-Liste wird angezeigt
3. Der Übersetzer wählt einen Textbaustein zum Übersetzen
4. Der Übersetzungsdialog mit dem Quelltext und den Textreferenzen wird darge-
Anforderungsanalyse
12
Diplomarbeit Ansgar Gerlicher
stellt
5. Der Übersetzer tippt seine Übersetzung in die Übersetzungsmaske
Special Requirements:
· Online-Übersetzung von ASRA Texten in jede von ASRA unterstützte Sprache
(UNICODE- Fähigkeit der Applikation und Anbindung an die Datenbank).
· Korrekte Darstellung der Zeichensätze auf dem Bildschirm.
· Eingabemöglichkeit für spezielle Sprachen erlauben (Betriebssystemunterstüt-
zung, z.B. IMEs = Input Method Editors).
Preconditions:
· Übersetzer muß angemeldet sein
· Das Startmenü wird angezeigt
Postconditions:
· Nach dem Übersetzen kann der Text geprüft und gespeichert werden
· Wird ein Textbaustein erfolgreich übersetzt, wird automatisch auf den nächsten
Textbaustein (falls vorhanden) gesprungen.
· Der übersetzte Baustein wird aus der ToDo-Liste entfernt.
3.1.4. Textbaustein kürzen:
Flow of Events :
Basic Flow:
1. Der Übersetzer wählt aus dem Startmenü den Punkt ,,zu lange Texte Liste"
2. Die Liste der zu langen Textbausteinkombinationen wird angezeigt
3. Der Übersetzer wählt aus einer Textbausteinkombination einen Textbaustein
4. Der ,,Text kürzen" Dialog wird mit Quelltext und Textreferenzen dargestellt
5. Der Übersetzer tippt den gekürzten Text in die Maske ein
Preconditions:
· Übersetzer muß angemeldet sein
· Das Startmenü wird angezeigt
Postconditions:
· Nach dem Übersetzen kann der Text geprüft und gespeichert werden
Der Use-Case ,,Texte einpflegen" ist außerhalb unserer Anwendung zu finden und
deshalb auch nicht relevant. Der Übersetzer muß sich bei jedem Use-Case erst einmal
einloggen. Dies ist unter anderem erforderlich, um sicherzustellen, daß nur Übersetzer,
die auch die Rechte haben Texte zu ändern, dies tun können. Außerdem wird dadurch
der Übersetzer und seine Spracheinstellungen, d.h. von welcher Quellsprache in welche
Zielsprache übersetzt wird, festgestellt. Die Spracheinstellungen werden für jeden
Übersetzer einmal, beim Anlegen des Übersetzers in der Datenbank, festgelegt. Das
Startmenü ist die erste Schnittstelle des Benutzers zum System. Es wird jedesmal nach
dem Login angezeigt.
Hiermit sind die Grundlegenden Use-Cases des System definiert. In den, in
Zusammenarbeit von Hewlett-Packard und DaimlerChrysler entstandenen
Dokumenten
1
, werden weitere Anforderungen beschrieben. Diese zusätzlichen
1. Siehe Anhang Atramo Spezifikation.
Main Use-Case
Diplomarbeit Ansgar Gerlicher
13
Anforderungen sind größtenteils detailliertere Beschreibungen der hier festgestellten
Use-Cases, definieren die Benutzerschnittstelle oder sind zusätzliche ,,komfort"
Funktionen um die Arbeit mit dem System noch angenehmer zu machen. Diese
Dokumente liefern eine ,,Vision" der Anwendung. In diesen Dokumenten werden auch
zwei neue Use-Cases beschrieben, die bisher noch nicht aufgeführt wurden: Textsuche
und Übersetzungsstatistik.
Im Folgenden wird auf die einzelnen Use-Cases des Systems genauer eingegangen und
damit (und durch ergänzende Spezifikation) die Anforderungen an das System definiert.
Das aktuelle Use-Case Model wird diesmal ohne die Akteure ASRA und Fachabteilung
gezeigt, da sie für diese Anwendung hier zunächst nicht relevant sind.
3.2. Main Use-Case
In Abbildung 3.2: ,,Main Use-Case Diagram" sind die verschiedenen Möglichkeiten die
dem Übersetzer zur Verfügung stehen aufgezeigt. So kann er nach Texten suchen
(Textsuche), die ToDo-Liste checken und die Liste mit zu langen
Textenbausteinkombinationen checken. Der ,,ToDo-Liste" Dialog wird erweitert durch das
Betrachten der Übersetzungsstatistik und das Bearbeiten eines Textbausteins. Dem
Kürzen eines Textbausteins geht der Use-Case ,,Zu lange Textbausteinkombinationen
bearbeiten" voraus, welches eine Erweiterung des ,,Liste zu langer
Textbausteinkombinationen checken" Use-Case ist. Eine Erweiterung durch eine
optionale Funktionalität wird hier durch die <<extend>> Beziehung angegeben. Die
Use-Cases ,,Textbaustein übersetzen" und ,,Textbaustein kürzen" sind Generalisierungen
der selben Basisfunktionalität des Use-Cases ,,Text bearbeiten".
Als Nächstes werden die verschiedenen Use-Cases im Detail betrachtet. Dazu wird jeder
Use-Case noch einmal einzeln aufgeführt und durch ein Sequenz- und
Aktivitätendiagramm ergänzt. Das Sequenzdiagramm
1
soll hier nur, auf einer abstrakten
Ebene, einen Einblick in die Abläufe im System geben. Ergänzende Spezifikationen in
textueller Form bieten eine weitere Sicht auf die Anwendung. Um dem Leser eine
1. Die Szenarios enden meist unerwartet mit dem Logout und Beenden der Anwendung. Dies wird zwar in der Realität so
selten vorkommen, dient aber hier der Übersichtlichkeit des Diagramms. Dadurch rückt der wichtige Teil des Szenarios
in den Mittelpunkt und unwichtige oder an anderer Stelle beschriebene Abläufe werden weggelassen. Das Diagramm
wird kürzer und verständlicher.
Anforderungsanalyse
14
Diplomarbeit Ansgar Gerlicher
Vorstellung einer möglichen Realisierung zu geben, werden die Screenshots der der
Benutzerschnittstellen des Prototypen gezeigt.
3.3. Use-Case Text suchen
Die Suche ergibt eine Menge von Textbausteinen, welche an den
Übersetzungsbildschirm weitergeleitet werden. In diesem kann der Anwender die
einzelnen Texte untersuchen und auch ändern.
Flow of events:
ABBILDUNG 3.2.
Main Use-Case
Damit der Übersetzer nachträglich
Textbausteine ändern oder auch
Korrekturlesen kann, müssen diese
aus der Datenbank herausgefiltert
werden. Dieser Dialog ermöglicht
es dem Anwender, eine bestimmte
Auswahl von Textbausteinen zu
finden.
ABBILDUNG 3.3.
Textsuchen Use-Case
ASRA Translation Module
Textbaustein übersetzen
To Do Liste checken
Textbaustein kürzen
Liste zu langer
Textbausteinkombinationen
checken
Text suchen
Übersetzungsstatistik betrachten
Textbaustein bearbeiten
Zu lange
Textbausteinkombination
bearbeiten
Übersetzer
<<extend>>
<<extend>>
<<extend>>
<<extend>>
Textsuche
Übersetzer
Suche einschränken
<<include>>
Einschränken der Suche geschieht durch
angeben folgender Informationen:
Suchzeitraum, Bausteinart, Benutzer, Text mit Wildcard optional
Use-Case Text suchen
Diplomarbeit Ansgar Gerlicher
15
Basic Flow:
1. Dieser Use-Case startet mit dem Auswählen des Menüpunktes ,,Suchen".
2. Die Anwendung stellt daraufhin eine Suchmaske mit den default Sucheinschrän-
kungen dar.
3. Der Benutzer schränkt durch Angeben von Suchzeitraum, Bausteinart, Benutzer
und des zu suchenden Textes (mit Wildcardoption), die Suche weiter ein.
4. Der Benutzer klickt auf den Button ,,Suchen starten".
5. Das System durchsucht daraufhin die Datenbank:
5.1. War die Suche erfolgreich ist der Use-Case beendet.
5.2. Wurde nichts gefunden, wird der Übersetzer darauf aufmerksam gemacht und
die Suchmaske wird dargestellt. Der Übersetzer kann seine Suchangaben er-
neut spezifizieren.
5.3. Wurden zu viele Suchergebnisse gefunden, wird der Übersetzer darauf auf-
merksam gemacht und die Suchmaske wird angezeigt. Der Übersetzer kann
seine Suchangaben erneut spezifizieren.
Alternate Flows:
2.1. Wählt der Übersetzer einen anderen Menüpunkt aus dem Anwendungsmenü,
wird der Use-Case beendet.
4.1. Wählt der Benutzer auf der Suchmaske den Button ,,Cancel", so wird die Such-
maske zurückgesetzt und alle Änderungen in der Suchmaske gehen verloren.
Preconditions:
· Übersetzer muß angemeldet sein
· Das Startmenü oder die ToDo-Liste muß angezeigt werden.
Postconditions:
· War die Suche erfolgreich wird auf den Übersetzungsdialog weitergeleitet und die
gefundenen Texte können dort bearbeitet werden.
Extension points: keine
Die Abbildung 3.4. zeigt ein ,,Text suchen" Szenario:
ABBILDUNG 3.4.
Text suchen Szenario
Startmenü
Suchdialog
ATraMo Anwendung
Übersetzer
5: beenden
4: logout
3: Suche starten
2: Suche einschränken
1: Suche auswählen
1.1.1: Suchdialog anzeigen
4.1: Logindialog anzeigen
3.1.1: gefundene texte im Übersetzungsdialog anzeigen
3.1: Datenbank durchsuchen
1.1: Suchdialog anzeigen
Nach erfolgreichem Login
Anforderungsanalyse
16
Diplomarbeit Ansgar Gerlicher
Die Benutzerschnittstelle des ,,Text suchen" Use-Case enthält die Möglichkeit, die Suche
einzuschränken. In der Suchmaske können dazu folgende Angaben gemacht werden:
·
Geändert vom: Datum im Format tt/mm/jjjj an dem der gesuchte Text frühestens
geändert wurde. Default: 01/01/1977.
·
Geändert bis: Datum im Format tt/mm/jjjj an dem der gesuchte Text spätestens
geändert wurde. Default: aktuelles Datum.
·
Sprache: legt fest, in welcher Sprache der Suchtext ist. Hierbei kann der Übersetzer
zwischen seiner Quell- und Zielsprache wählen. Default: Quellsprache.
·
Suchtext: der zu suchende Text. Optional können % Zeichen als Wildcard vor und
nach dem Text angegeben werden. Das Feld darf auch leer sein, dann werden alle
Texte gesucht.
·
Benutzer: schränkt auf den Benutzer ein, der den Text zuletzt geändert hat. Als
Auswahl steht auch ,,alle Benutzer" zur Verfügung, dann wird die Suche hierdurch
nicht eingeschränkt. Default: Der aktuell angemeldete Übersetzter.
·
Bausteintyp: gibt den zu suchenden Bausteintyp an. Default: ActivityText.
Abbildung 3.6 zeigt den Ablauf als Activity Diagram.
ABBILDUNG 3.5.
Suchmaske UI
ABBILDUNG 3.6.
Activity Diagram Ablauf der Textsuche
<<instantiate>>
Benutzer
[Default: current User]
Bausteintyp
[Default:ActivityTxt]
Sprache
[Default: SrcLanguage]
Suchtext
GeaendertVom
[Default:01/01/1977]
GeaendertBis
[Default:today]
Suchdialog
+sucheStarten:void
+suchmaskeZuruecksetzen:void
Suchmaske:Suchdialog
System
Übersetzer
darstellen Textsuche Dialog
Cancel auswählen
Datenbank durchsuchen
Übersetzungsdialog mit
Suchergebnis darstellen
Suche einschränken
Suche starten auswählen
Kein oder zu viele Suchergebnisse
Suchmaske wird zurückgesetzt
Menüpunkt Textsuche wird gewählt
Bemerkung: Use-Case kann jederzeit
durch Wählen eines Menüpunktes im
Anwendungsmenü abgebrochen werden
Use-Case ,,Übersetzungsstatistik betrachten"
Diplomarbeit Ansgar Gerlicher
17
Um einen besseren Eindruck zu bekommen, wie der Suche-Dialog aussehen könnte,
zeigt die Abbildung 3.7. einen Screenshot des Prototypen:
3.4. Use-Case ,,Übersetzungsstatistik betrachten"
Die Übersetzungstatistik zeigt den Stand der Übersetzung für alle Textbausteine in der
Zielsprache des angemeldeten Übersetzers an. Dabei wird für jeden Textbaustein, die
Gesamtanzahl, die Zahl geänderter, die Zahl neuer und die Zahl bisher übersetzter
Textbausteine in Prozent angegeben.
ABBILDUNG 3.7.
Screenshot Dialog Textsuche
Anforderungsanalyse
18
Diplomarbeit Ansgar Gerlicher
Flow of events:
Basic Flow:
1. Dieser Use-Case startet mit dem Auswählen des Menüpunktes ,,Statistik".
2. Die Anwendung stellt daraufhin die Übersetzungstatistik mit dem Übersetzungs-
grad für alle Textbausteine für die Zielsprache des angemeldeten Übersetzers in
Prozent dar.
3. Der Use-Case endet mit dem Verlassen der Übersetzungsstatistik über das
Menü oder den ,,Zurück" Button.
Alternate Flows: keine.
Preconditions:
· Übersetzer muß angemeldet sein
· Die ToDo-Liste muß angezeigt werden.
Postconditions: keine
Extension points: keine.
Die Abbildung 3.8 zeigt einen Screenshot der Statistik:
ABBILDUNG 3.8.
Screenshot Statistik Dialog
Use-Case ,,ToDo-Liste checken"
Diplomarbeit Ansgar Gerlicher
19
3.5. Use-Case ,,ToDo-Liste checken"
In der ToDo-Liste werden alle aktuellen Aufgaben des angemeldeten Übersetzers
angezeigt. Diese Liste verändert sich nach den Aktionen des Anwenders. Wurden z.B.
alle zu bearbeitenden Textbausteine eines Typs übersetzt, wird der Textbaustein Typ aus
der Liste entfernt. Werden keine Aufgaben mehr in der Liste angezeigt, so wurden alle
Textbausteine übersetzt. Es wird für jeden Textbaustein die Anzahl der geänderten
hinzugefügt wurden, nachdem die ToDo-Liste erstellt wurde. Dies kann das System nicht
ermitteln. Die neuen Texte werden aber auch ohne Refresh beim nächsten Login des
Übersetzers angezeigt.
Flow of events:
Basic Flow:
1. Dieser Use-Case startet mit dem Auswählen des Menüpunktes ,,ToDo-Liste".
2. Das System lädt für jeden Textbausteintyp die Anzahl der geänderten und neuen
Texte und stellt sie dar. Während des Ladevorgangs wird der Ladestatus in der
Statusleiste des Browsers angezeigt.
3. Der Use-Case endet sobald ein anderer Menüpunkt aus dem Anwendungsmenü
gewählt wird, oder der Übersetzer den Suche Menüpunkt aus der ToDo-Liste
anklickt.
Alternate Flows: keine
Preconditions:
· Übersetzer muß angemeldet sein
· Das Startmenü muß angezeigt werden.
Postconditions:
· Der aktuelle Ladestand der ToDo-Liste wird gespeichert und der Ladevorgang
wird beim nächsten Aufruf der ToDo-Liste an der Stelle fortgesetzt.
Extension points:
2.1. Der Übersetzer wählt aus der ToDo-Liste einen Text zum Bearbeiten aus. Das
oder neuen Texte angezeigt, die
übersetzt werden sollen. Gibt es in
einer Textbausteinart keine zu
übersetzenden Texte, wird diese
Bausteinart nicht angezeigt. Neben
der Auswahl eines Textes kann der
Übersetzer zusätzlich von der ToDo-
Liste aus die Übersetzungsstatistik
einsehen, die Textsuche aufrufen, und
die ToDo-Liste refreshen. Das
Refreshen der Liste ist dann
notwendig, falls außerhalb der Atramo
Anwendung neue Texte
ABBILDUNG 3.9.
Use-Case ToDo-Liste checken
Texte bearbeiten
Statistik anzeigen
Übersetzer
ToDo Liste refresh
ToDo-Liste
checken
<<extend>>
<<extend>>
<<extend>>
Anforderungsanalyse
20
Diplomarbeit Ansgar Gerlicher
kann jederzeit schon während des Ladevorgangs geschehen. Der Use-Case
Texte bearbeiten wird gestartet.
2.2. Der Menüpunkt Übersetzungsstatistik wird vom Übersetzer ausgewählt. Der
Use-Case Übersetzungsstatistik wird gestartet.
2.3. Der Menüpunkt Refresh wird ausgewählt. Der ToDo-Liste Use-Case beginnt
von neuem.
3.5.1. Aufbau der ToDo-Liste
Das Laden der ToDo-Liste geschieht Textbaustein für Textbaustein, bis alle
Textbausteine nach neuen bzw. geänderten Texten durchsucht und dargestellt wurden.
Während die Liste aufgebaut wird, kann der Benutzer schon einen Textbaustein zum
Übersetzen auswählen. Nachdem die Liste komplett geladen wurde, sind die
Menüpunkte: Statistik, Suche und Refresh sichtbar. Doch wie baut sich die Liste genau
auf? Folgendes Activity Diagram zeigt den Ablauf noch einmal:
Das Laden der ToDo-Liste kann jederzeit unterbrochen werden, indem der Übersetzer
einen Menüpunkt aus dem Anwendungsmenü, oder einen Textbaustein zum Übersetzen
wählt.
ABBILDUNG 3.10.
Activity Diagram Aufbau der ToDo-Liste
Übersetzer
System
Ladevorgang beendet,
ToDo-Liste wird angezeigt
Speichern des aktuellen
Ladestandes
Ladestand in Browser
Statuszeile anzeigen.
Textbaustein nach
neuen/geänderten
Texten prüfen
Use-Case Text
übersetzten wird
gestartet
Textbaustein mit geänderten und
neuen Texten darstellen.
Textbausteintyp
zum Übersetzen
auswählen
Keine Texte vorhanden, Nächster
Textbaustein
Neue/geänderte Texte vorhanden
Use-Case kehrt zurück
ToDo-Liste wird gestartet
Nächster Textbaustein
Alle Texte wurden überprüft
Wurde die ToDo-Liste komplett geladen,
kann der Übersetzer aus den Menüpunkten:
Statistik, Suche, Refresh wählen.
Use-Case ,,ToDo-Liste checken"
Diplomarbeit Ansgar Gerlicher
21
3.5.2. ToDo-Liste Szenario
Ein Szenario wäre z.B.: Ein Übersetzer meldet sich im System an und wählt dann im
Startmenü den ,,ToDo-Liste" Link. Nachdem sich die ToDo-Liste aufgebaut hat, kann er
sehen, ob er viel zu tun hat, oder sich noch mit dem Übersetzen Zeit lassen kann.
Das Sequenzdiagramm zeigt den Ablauf noch etwas genauer. Nach dem erfolgreichen
Login wird der Link ,,ToDo-Liste" im Startmenü angeklickt (1.). Das führt dazu, daß vom
Startmenü eine Nachricht an die Anwendung geschickt wird (1.1.), um die ToDo-Liste
anzuzeigen. Die Anwendung initialisiert die ToDo-Liste (1.1.1.) und es werden daraufhin
die Informationen der einzelnen Textbausteine geladen und dargestellt (1.1.1.1.).
Informationen sind in diesem Fall, wieviele geänderte und wieviele neue Texte es zu
übersetzen gibt und beim wievielten Textbaustein die Liste sich gerade befindet,
während sie sich aufbaut. Nachdem die Liste komplett angezeigt wurde, der Übersetzer
z.B. gesehen hat, daß es nichts zu übersetzen gibt, logt er sich in diesem Fall wieder aus
(2.). Der Logindialog wird wieder aufgerufen (2.1.). Die Anwendung wird beendet (3.)
indem der Benutzer den Browser schließt.
ABBILDUNG 3.11.
ToDo-Liste Szenario
Startmenü
To Do Liste
Übersetzer
ATraMo Anwendung
1.1.1.1: Laden und Anzeigen von Textbaustein Informationen
1: To Do Liste auswählen
1.1.1: Initialisierung
3: beenden
2: logout
1.1: To Do Liste anzeigen
2.1: Logindialog anzeigen
Nach erfolgreichem Login
Anforderungsanalyse
22
Diplomarbeit Ansgar Gerlicher
Das Userinterface der ToDo-Liste zeigt für die verschiedenen Textbausteine die Anzahl
der geänderten und der neuen Texte an. Es kann hier eine Auswahl getroffen werden,
welchen Textbausteintyp der Benutzer übersetzen möchte. Dabei hat er die Wahl
zwischen geänderten (falls vorhanden) oder neuen (falls vorhanden) Texten eines
Textbausteins.
Methoden der ToDoListeTextbaustein Klasse:
·
NeueTexteÜbersetzen: Ruft den Übersetzungsdialog mit den gewählten neuen
Textbausteinen auf.
·
GeänderteTexteÜbersetzen: Ruft den Übersetzungsdialog mit den gewählten
geänderten Textbausteinen auf.
Um dem Leser auch noch eine Vorstellung zu geben, wie die ToDo-Liste aussehen
könnte zeigt die Abbildung 3.13 einen Screenshot des Prototypen.
In diesem Klassendiagramm zum Userinterface sieht
man die drei Methoden der Klasse ToDoListe:
·
ToDoListeRefresh: Neu Laden der ToDo-Liste
·
Textsuche Aufrufen: Der Use-Case Textsuche wird
gestartet
·
StatistikAnzeigen: Die Übersetzungsstatistik wird
angezeigt.
Der ToDoListeTextbaustein hat als Attribute:
·
NeueTexte: Anzahl der zu übersetzenden neuen
Texte.
·
GeänderteTexte:Anzahl der zu übersetzenden
geänderten Texte.
ABBILDUNG 3.12.
ToDo-Liste UI
a
a. Benutzerschnittstellendiagramme wie dieses, dienen nur der Veranschaulichung. Die gezeigten Klassen sind abstrakt
und sollen in der Implementierung so nicht umgesetzt werden.
1
1..*
ToDoListe
+ToDoListeRefresh:void
+TextsucheAufrufen:void
+StatistikAnzeigen:void
ToDoListeTextbaustein
-NeueTexte:int
-GeänderteTexte:int
+NeueTexteÜbersetzten:void
+GeänderteTexteÜbersetzen:void
Use-Case ,,ToDo-Liste checken"
Diplomarbeit Ansgar Gerlicher
23
ABBILDUNG 3.13.
Screenshot ToDo-Liste Dialog
Anforderungsanalyse
24
Diplomarbeit Ansgar Gerlicher
3.6. Use-Case,,Textbaustein bearbeiten"
Wird ein Textbausteintyp (neue oder geänderte Texte) aus der ToDo-Liste ausgewählt,
so kann es sein, daß mehrere Texte dieses einen Typs existieren. Der
Übersetzungsdialog verwaltet alle zu übersetzenden Texte des gewählten
Textbausteintyps in einer Liste. Wird ein Textbaustein aus einer zu langen
Textbausteinkombination gewählt, so enthält diese Liste nur einen Text. ,,Textbaustein
kürzen" und ,,Textbaustein übersetzen" sind Generalisierungen von ,,Textbaustein
bearbeiten" und besitzen damit die selbe Basisfunktionalität. Wo sie sich unterscheiden
wird im folgenden ,,Flow of events" speziell gekennzeichnet. Der Use-Case ,,Text Liste
betrachten" ist eine Erweiterung des Textbaustein bearbeiten und zeigt die Liste der zu
übersetzenden Texte des Übersetzungsdialog mit Quell- und Zielsprachtext (sofern
vorhanden) an. Die Textliste zeigt immer nur maximal 20 Texte gleichzeitig an und
bietet die Möglichkeit einen Text zum Bearbeiten auszuwählen. Wird ein Text
ausgewählt, so wird der Übersetzungsdialog mit dem ausgewählten Text angezeigt.
Wenn es mehr als 20 Texte gibt, kann der Benutzer innerhalb der Textliste ,,blättern"
um z.B. die nächsten oder vorherigen 20 Texte anzeigen zu lassen.
Für die Anwendung selber macht es keinen Unterschied, ob ein Textbaustein gekürzt,
oder ein geänderter Textbaustein erneut übersetzt wird. In beiden Fällen muß der
bearbeitete Text überprüft und gespeichert werden. Der Kontext, aus dem heraus ein
Textbaustein bearbeitet wird, ist dennoch wichtig. Denn je nachdem, von wo aus der
Übersetzungsdialog (Use-Case ,,Textbaustein bearbeiten") aufgerufen wurde, kehrt der
Übersetzer nach der Bearbeitung wieder auf die ToDo-Liste oder auf einen anderen
Dialog zurück.
Texte bearbeiten ist eine zentrale
Funktion der Anwendung und
geschieht im Übersetzungsdialog.
Der Übersetzungsdialog wird durch
Wählen eines zu übersetzenden
Textbausteintyps aus der ToDo-
Liste, oder eines Textbausteins aus
dem ,,zu lange
Textbausteinkombination" Dialog
aufgerufen.
ABBILDUNG 3.14.
Use-Case Textbaustein bearbeiten
Übersetzer
Text Liste betrachten
Textbaustein bearbeiten
Extension points
List button wird angeklickt
Textbaustein kürzen
Textbaustein übersetzen
<<extend>>
Use-Case,,Textbaustein bearbeiten"
Diplomarbeit Ansgar Gerlicher
25
Der ,,Textbaustein bearbeiten" Use-Case umfaßt folgende Basisfunktionalität:
· Text eingeben
· Eingabe rückgängig machen (undo)
· Text prüfen und speichern
· Zum nächsten Text in der Liste springen
· Zum vorherigen Text in der Liste springen
· Zum letzten Text in der Liste springen
· Zum ersten Text in der Liste springen
· Den Übersetzungsdialog beenden
Flow of events:
Basic Flow:
1. Der Use-Case startet, sobald der Übersetzer einen Textbaustein auswählt.
2. Der Übersetzungsdialog wird dargestellt.
3. Der Übersetzer bearbeitet den Text.
4. Der Übersetzer speichert die Übersetzung durch drücken des ,,Speichern" But-
ton.
5. Das System überprüft den eingegebenen Text auf ungültige Zeichen.
6. Der Text wird in der Datenbank gespeichert.
Textbaustein übersetzen:
7.1. Wird ein Text übersetzt, wird der nächste Text in der Liste angezeigt und der
Use-Case beginnt von vorne.
Textbaustein kürzen:
7.2. Wird ein Text gekürzt, so wird der ,,zu lange Texte" Dialog wieder aufgerufen
und der Use-Case endet.
8. Der Use-Case endet, sobald der ,,Ende" Button gedrückt wird, oder ein Menü-
punkt im Anwendungsmenü gewählt wird.
Alternate Flows:
3.1. Der Übersetzer wählt den nächsten, vorherigen, ersten oder letzten Text in der
Liste und der Use-Case beginnt von neuem.
6.1. Der Text enthält ungültige Zeichen. Eine Fehlermeldung wird angezeigt und
der Text wird nicht gespeichert. Der Use-Case beginnt von neuem ab 2.
Textbaustein übersetzen:
7.1.1 Existiert kein Text mehr in der Liste, endet der Use-Case und die ToDo-Liste
wird angezeigt.
Preconditions:
· Übersetzer muß angemeldet sein
· Die ToDo-Liste oder der ,,zu lange Texte Dialog" muß angezeigt werden.
Postconditions:
Textbaustein übersetzen:
· Wird der Use-Case normal beendet (nicht über das Anwendungsmenü), so wird
die ToDo-Liste wieder angezeigt.
Textbaustein kürzen:
· Wird der Use-Case normal beendet (nicht über das Anwendungsmenü), so wird
der ,,zu lange Textbausteinkombination" Dialog wieder angezeigt.
Extension points:
Textbaustein übersetzen:
· Wird der ,,Liste" Button angeklickt, so wird die Liste aller Texte des zu überset-
zenden Textbausteins angezeigt.
Textbaustein kürzen:
· Wird der ,,Liste" Button angeklickt, so wird der zu kürzende Textbaustein nochmal
angezeigt.
Anforderungsanalyse
26
Diplomarbeit Ansgar Gerlicher
3.6.1. Ablauf der Textbaustein kürzen und übersetzen Use-Cases
,,Textbaustein kürzen" hat einen etwas anderen Ablauf als das ,,Textbaustein
übersetzen", da hier aus einem anderen Kontext heraus der Übersetzungsdialog
aufgerufen wird. Was die Use-Cases gemeinsam haben wird durch den Use-Case
,,Textbaustein bearbeiten" beschrieben.
Der Unterschied besteht vor allem darin, daß beim ,,Textbaustein kürzen" immer nur ein
Text bearbeitet werden muß, während beim Übersetzen auch mehrere Texte in der
,,Übersetzungsliste" enthalten seien können. Weiter sind die Endbedingungen
unterschiedlich. Beim ,,Textbaustein kürzen" wird nach dem erfolgreichen Speichern des
Textes nicht wieder die ToDo-Liste angezeigt, sondern der ursprüngliche Dialog, nämlich
der ,,zu lange Textbausteinkombination" Dialog. Ein Aktivitätsdiagramm soll dies
graphisch darstellen:
Ist der Text in Ordnung, so wird er gespeichert und der ursprüngliche Dialog wird wieder
angezeigt. Der Use-Case ist beendet. Zum Vergleich zeigt die Abbildung 3.16. das
Aktivitätsdiagram für ,,Textbaustein übersetzen":
Erklärung: Von der ToDo-Liste aus wird der Use-Case gestartet, indem der Übersetzer
einen Textbausteintyp auswählt. Der Übersetzungsdialog wird nun mit einer Liste aller
zu übersetzenden Texte initialisiert. Dieser Schritt wurde im Diagramm zu ,,Textbaustein
kürzen" weggelassen, da es dort immer nur einen Text gibt und die Liste somit die
Länge eins hat. In diesem Use-Case kann die Liste beliebig viele Texte enthalten. Beim
Erklärung: Vom Dialog ,,zu lange
Textbausteinkombination" aus wird
der Use-Case gestartet, indem ein
Textbaustein ausgewählt wird.
Daraufhin wird der
Übersetzungsdialog dargestellt.
Der Übersetzer kürzt nun den Text.
Durch anschließendes Anklicken
des ,,Speichern" Buttons prüft das
System den Text. Ist der Text nicht
in Ordnung, wird der
Übersetzungsdialog mit einer
Fehlermeldung wieder angezeigt
(Basisfunktionalität).
ABBILDUNG 3.15.
Activity Diagram Textbaustein kürzen
Übersetzer
kürzt den Text
Text speichern
Überprüfen des Textes
auf unerlaubte Zeichen
Dialog "zu lange
Textbausteinkombination"
wird angezeigt
Darstellen des
Übersetzungsdialog
mit aktuellem Text
"Speichern" Button klicken
Text in Ordnung
Auswahl eine Textbausteins
Text enthält ungültige Zeichen,
Fehlermeldung wird angezeigt
Ende der Leseprobe aus 138 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2001, Konzeption und Realisierung einer webbasierten Anwendung mit dem Java (TM) 2 Enterprise Edition Framework, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/221629
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter +49(0)176-85996762 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare