Entwurfsempfehlungen für die Anwendungsentwicklung mit mehrschichtigen Architekturen am Beispiel J2EE

Diplomarbeit zur Erlangung des akademischen Grades

DIPLOMINGENIEUR
in der Studienrichtung

INFORMATIK

Angefertigt am Institut für Angewandte Informatik
Betreuung:

Univ.-Doz. Mag. Dr. Siegfried Reich
Von:

Pointner Dietmar
Linz, November 2002

Eidesstattliche Erklärung
Ich erkläre an Eides statt, dass ich die vorliegende Diplomarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die wörtlich oder sinngemäß entnommen Stellen als solche kenntlich gemacht habe.

Linz, 19. November 2002

Kurzfassung
Wegen der hohen Verbreitung des Internets und dessen Einflussnahme in Unternehmensabläufe nehmen webbasierte mehrschichtige Anwendungen einen immer höheren Stellenwert ein. Typische Einsatzgebiete dieser Art der Anwendungen sind unternehmenskritische Aufgaben, d. h. von der zuverlässigen Funktion der Anwendung hängt die Wirtschaftlichkeit des Unternehmens ab. Als Basis für die Entwicklung solcher Systeme wird häufig die Java 2 Enterprise Edition (J2EE) eingesetzt, welche von Sun Microsystems spezifiziert wurde und von unterschiedlichen Herstellern unterstütz wird. Bei der Entwicklung von mehrschichtigen Anwendungen für Webapplikationen ist das Entwurfsstadium eine besonders kritische Phase, da ein umfangreiches Wissen über das Zusammenspiel von verschiedensten Technologien benötigt wird und die Implementierung solcher Systeme auf verschiedenste Art und Weise erfolgen kann. Ziel dieser Arbeit ist es daher, Entwurfsempfehlungen für die Anwendungsentwicklung mit mehrschichtigen Architekturen am Beispiel J2EE zu entwickeln und zu dokumentieren. Zur Erreichung dieses Ziels wird einerseits eine Literaturanalyse durchgeführt, in der vorhandene Richtlinien und Empfehlungen analysiert werden, andererseits in einer Fallstudie ein Prototyp auf Basis von J2EE entworfen. Die Ergebnisse der Fallstudie erweitern die Literaturanalyse um praktische Erfahrungen. Als Fallstudie dient eine Call Center Anwendung, da diese typischerweise als eine mehrschichtige Webanwendung entworfen werden kann. Um die praktische Relevanz dieser Arbeit sicher zu stellen und, um Anforderungen aus dem realen Betrieb eines Call Centers in die Betrachtung zu integrieren, wird der Entwurf des Prototyps durch ein Call Center (market calling MarketinggesmbH in Linz) unterstützt. Ergebnis dieser Arbeit ist eine Bewertung von Designvorlagen für J2EE-Anwendungen und allgemeine Empfehlungen für den Einsatz der J2EE. Der Einsatz von Patterns bring Vorteile für die Wiederverwendbarkeit und Modularisierung, die Entwicklung erfordert aber eine bestimmte Mindestgröße des Entwicklerteams, da der Entwurf und die Implementierung der verschiedenen Schichten ein umfangreiches Wissen über verschiedene Aufgaben und Technologien erfordert.

The experiences resulting from the case study undermine the results of the literature analysis with practical findings. in a first step a literature study has been conducted. The Java 2 Enterprise edition (J2EE). In addition to that. the development of this prototype is supported by a call center company (market calling MarketinggesmbH in Linz). which includes the design of a J2EE based prototype application has been implemented. which is specified by Sun Microsystems and which is supported by several manufacturers. In order to ensure the practical relevance of this thesis and to take real world requirements into account. . because this type of applications can be typically implemented as a multi-tier web application. The use of patterns leads to a better reusability and modularisation. The case study is a call center application. As these types of applications are typically used for critical tasks. For these reasons. the goal of this thesis is to define and document recommendations for the application development with multi-tier applications. In order to reach this objective. enterprises are depending more and more on the reliability of web based multi-tier applications. During this phase the developers need an extensive knowledge about the interaction of various technologies und there are different ways to implement these applications. The result of this thesis are an evaluation of patterns for the J2EE Platform and common recommendations for the implementation of J2EE applications. is commonly used as a basis for the development of such systems. a case study. because the design and implementation of J2EE applications needs an extensive knowledge about various technologies. A critical task in the development of web based multi-tier applications is the design phase. but it enforces a minimum developer team size.Abstract Web based multi-tier enterprise applications are increasingly important for application development. The reasons for this trend are the increasing diffusion of the Internet and its influence on business processes.

................................................................................................................................................................................1 Allgemeine Systemarchitektur J2EE.......................................1 Systemabgrenzung....... 28 3.....2...............................3 Systembeschreibung........ 25 3............................2....4 Zusammenfassung...............1 Strukturanalyse... 42 3..........................................3 Entwurf ...................2 Aufgabenanalyse ........................4 Vorgehensweise....2.............2.............................................. 50 4.......1..................................................................................1 Problemanalyse .......................................................................2 Systemerhebung ...4 Patterns (Schablonen)........................2..4. 10 Einleitung ..................................1 Systemabgrenzung ...und Ablaufanalyse ................................................ 10 1.. 44 4............................................................................................................................1..............4.....................................................................2 Businessschicht .......................... 23 3......................... 16 2............ 29 3.....................................1 Präsentationsschicht ........ 18 2............ 21 Die Java 2 Enterprise Edition................... 46 4........................................................................................................................................................................4............................. 57 4....................................................................................... 34 3....................................... 10 1...................................................................... 54 4......................... 14 2....2..................................2 Entity Beans .......... 15 2......................... 11 1.......................................2 Systemspezifikation (Anforderungsdefinition) ....2 Enterprise JavaBeans....1 Mehrschichtige unternehmenskritische Anwendungen. 21 3............... 58 ......................... 18 2...................3 Bestandteile von EJBs ...................Inhaltsverzeichnis 5 Inhaltsverzeichnis Kapitel 1 ...... 44 Problemanalyse ................................ 29 3...........4....................3 Kommunikations.........................................2 Ziel der Diplomarbeit ..........................2 Systemerhebung .........3 Integrationsschicht ...................................... 12 Kapitel 2 .........................................................................................................................................................5 Datenanalyse ....................... 19 Kapitel 3 ............. 14 Vorgehensmodell zur Entwicklung eines Softwareprodukts ................ 43 Kapitel 4 ..............................................................1 Session Beans................................................................................................................................ 46 4............................................................................................ 44 4.. 11 1....................2.........................4 Dokumentenanalyse ..............................................................1............ 16 2.............. 26 3..............3 Call Center als Fallstudie............................................................................................ 25 3...

.........................................5 Management/Geschäftsleitung...................................... 65 5......................................... 67 5...................................... 78 6...Inhaltsverzeichnis 6 4.3...3 Protokolle .................................4 Benutzerverwaltung.2......................3..........................1 Zuverlässigkeit .........3.................................. 71 5...........4............................................................................... 70 5............................ 60 Kapitel 5 .....1 Ausgangssituation und Zielsetzung...................................... 74 6.............................................. 81 6...................2 Handhabung ............................................................................................................................................... 73 6....................................5 Projektverwaltung .................... 82 6....3............1 Übersicht Allgemeiner Geschäftsprozess ........................................................................................2........................6 Glossar und Index. 73 6..........................3 Modell ...................4 Nichtfunktionale Anforderungen.......... 62 Systemspezifikation .................................................4......3.................................... 71 5.............1 Elementbeschreibung der DTD...4.......................................................................................2 Supervisor ............. 73 6......................3 Call–Agent ....................................4.................3 Systembeschreibung ..................2.... 75 6...........................................................1 EDV-Administrator... 64 5............................................................................................................................................................ 71 5........................................... 71 5........... 72 5................6 Erweiterbarkeit.................................... 73 6....2................................................................................2......4 Kunde ......................... 80 6........................3....................................... 83 .......................5 Dokumentationsanforderungen ....2 Definition der wichtigsten Kriterien .. 63 5...............................2 Systemeinsatz und Systemumgebung ........................................ 66 5............................................................... 68 5............... 81 6.................................................. 62 5.3 Benutzerschnittstellen und funktionale Anforderungen..............3............4.... 73 Entwurf.......................3..........2 Übersicht SOLL–Datenfluss ............................... 72 Kapitel 6 ....................6 Schwachstellenanalyse................. 71 5.....................2 Beispiel eines Protokolls .................................................1 Datenbankauswahl ........ 70 5...... 77 6..........................................................................4 Offenheit und Skalierbarkeit ..............3 Zeitverhalten ................................... 66 5...............................1 Allgemeines......3 Protokollvorlagen................4 XSLT-Transformation ..... 71 5.....2 Datenmodell ..............................................................................................................7 Unterstützung der Migration ........ 72 5.................................4........5 Wartbarkeit............ 59 4........... 63 5.............................................................................................3........................4..2........................... 69 5........

.. 96 7......... 103 8......................................2 Rollenverteilung bei der Entwicklung von J2EE Anwendungen ...........................................................................................3 6... 91 Implementierung . 91 7.......................2.............. 101 Designrichtlinien .................................6 Prototyp ............................2.. 91 7.....................................3.................................................2 EJB-Installierer (EJB Deployer) ........ 125 Anhang A .........3 Integrationsschicht .............. 128 7...................................3............................. 92 7.................................................3 Präsentationsschicht (Presentation Tier) ..............................................................2..... 86 6.............................. 86 Kapitel 7 ..........................................................7..........................................................4 EJB-Server Anbieter und EJB-Container Anbieter..............2..................2 Businessschicht ............................................7..... 92 7................................................................. 92 7.............................................. 102 8.............................................................................1 Präsentationsschicht .................................2 Value Objects ....... 93 7.............. 97 7...............................6 6........................7........................................... 98 Kapitel 8 .....................................................................................................1 EJB-Entwickler ....3...3...............................1 Businessschicht (Business Tier)...... 84 6.1 Einführung.................................................5 Deployment ........4 Programmierung ...............................................................1 Empfehlungen für die Technologieentscheidung............2...........................................................2......................... 91 7............................................................................3 Anwendungsentwickler (EJB Assembler) ..... 122 Literaturverzeichnis...................... 84 6................ 96 7........................................ 128 Fragenkatalog ................Ist-Analyse ...............................................2.................. 104 8..................................................... 94 7....................... 97 7.... 118 8..........................3 Auswahl des Applikationsservers ........................................................................4 Allgemeine Aussagen zu den Patterns ...................2 Entwicklungswerkzeuge ... 122 Zusammenfassung und Ausblick ...................................................... 110 8........... 120 Kapitel 9 ........................................................................... 92 Werkzeuge und Plattform....................................................................................................................................7 .................1 Applikationsserver ................. 83 Identifikation der Komponenten...............2 Bewertung der J2EE Patterns . 93 7......................2..Inhaltsverzeichnis 7 Auswertung für Kunden ................4 Auswahl des Entwicklungswerkzeugs .... 101 8....................

.......................................2 Sequenzdiagramm der Kommunikation in J2EE ................................................ 98 Abbildung 7.........................6 Prototyp der Kundenschnittstelle .........11 Sequenzdiagramm ServiceActivator...........6 Sequenzdiagramm Business Delegate .. 15 Abbildung 3.......5 Sequenzdiagramm eines Front Controllers .....................................................................................................1 Systemarchitektur J2EE [MID99]............ 39 Abbildung 3.............................................. 43 Abbildung 4.. 77 Abbildung 6.......................................................................1 Entwurf des zu automatisierenden Geschäftsprozesses ............. 69 Abbildung 5..........8 Sequenzdiagramm Session Facade ....................................4 Organigramm . 99 Abbildung 7................3 Allgemeiner Schnittstellenentwurf ....................................................7 Sequenzdiagramm Value Object.....4 Login-Dialog.......................................6 Benutzerdaten ändern.................................................................................................................................. 67 Abbildung 5....................... 24 Abbildung 3..........1 Soll Datenflussdiagramm................. 52 Abbildung 4...................... 41 Abbildung 3..................................................5 Weg eines Protokolls ... 60 Abbildung 4...........9 Sequenzdiagramm Value Object Assembler ...................................................................3 Filialstruktur mit Zentrale .1 Vorgehensmodell bei der Problemanalyse aus [Pom96] .. 49 Abbildung 4........................................... 38 Abbildung 3. 70 Abbildung 6........ 99 Abbildung 7........Abbildungsverzeichnis 8 Abbildungsverzeichnis Abbildung 2..........3 Deployment mit der Referenzimplementierung..................................... 36 Abbildung 3..2 Zu automatisierender Geschäftsprozess (UML Aktivitätsdiagramm)46 Abbildung 4....................... 97 Abbildung 7......... 24 Abbildung 3.....................................10 Sequenzdiagramm Service Locator ................................ 68 Abbildung 5.........................8 Datenflussdiagramm ............. 45 Abbildung 4. 94 Abbildung 7............7 Entwurf des Datenflussdiagramms ............... 37 Abbildung 3.................3 Bestandteile eine Enterprise JavaBean und seine Ablaufumgebung ................6 Weg eines Protokolls ........................................................................ 28 Abbildung 3.......................................1 ER-Diagramm des Datenmodells ..........................................................5 Prototyp der Benutzerschnittstelle für den Call Agent .....2 DTD eines Protokolls........... 50 Abbildung 4............................................................................... 78 Abbildung 7.....2 Benutzergruppenverwaltung ...........5 Benutzerliste .....4 Sequenzdiagramm Intercepting Filter....... 32 Abbildung 3................ 57 Abbildung 4.................................... 61 Abbildung 5...................................................................................................................2 Entwicklungsumgebung TogetherJ...... 100 . 31 Abbildung 3.................... 67 Abbildung 5................... 65 Abbildung 5............................................4 Call–Agent / Auftrag Zuteilung .....................1 Verbreitung der Applikationsserver [CZ2202] .....

............................................4 Entity Beans...............Tabellenverzeichnis 9 Tabellenverzeichnis Tabelle 3.................. 30 Tabelle 3......................................... 86 Tabelle 6..... 104 ..........................................2 Mögliche Rollen eines Benutzers ....5 Beschreibung der Hilfskomponenten............................................ 89 Tabelle 6...............2 Designvorlagen für die Businessschicht .................................................. 85 Tabelle 6........ 88 Tabelle 6...............................3 Sessionfacades und ihre Businessmethoden ...3 Designvorlagen für die Integrationsschicht ............7 Allgemeine Schnittstellenelemente.....................................6 Value Objects .............. 95 Tabelle 8............................. 75 Tabelle 6......1 Designvorlagen für die Präsentationsschicht ..............9 Schnittstellenelemente der Projektverwaltung.................. 35 Tabelle 3......................................... 85 Tabelle 6..............1 Klassifikation von Datenbanken . 93 Tabelle 7...........................2 Entwicklungswerkzeuge für J2EE ........ 90 Tabelle 7............1 Bewertungsschema für Designvorlagen (Patterns) ........................ ihre Schlüsselklassen und Value Objects .................................. 42 Tabelle 6......................... 87 Tabelle 6...................................8 Schnittstellenelemente der Benutzerverwaltung ....................1 Application Server Comparison Matrix [FLA02].............................................................. 86 Tabelle 6.......10 Schnittstellenelemente der Protokollerfassung . 83 Tabelle 6...................

1 Mehrschichtige unternehmenskritische Anwendungen Für mehrschichtige unternehmenskritische Anwendungen existiert der offene Standard J2EE (Java 2. J2EE definierte Standards für die Entwicklung von mehrschichtigen Anwendungen. Verteilte Transaktionen: Java Transaction API (JTA). J2EE bietet Technologien für: • • • • • • Datenbankzugriff: Java Database Connectivity (JDBC). die diesen Komponenten zur Verfügung gestellt werden. Transaktionsunterstützung) durch die J2EEPlattform der Entwickler der Anwendung entlastet [J2E01]. Außerdem wird durch die automatische Bereitstellung von vielen Applikationsdetails (z. um deren Entwicklung zu erleichtern und zu beschleunigen und die Interoperabilität zu verbessern. Servlets und als zentralen Bestandteil die Enterprise JavaBeans (EJB). Eine J2EE-konforme Anwendung basiert auf standardisierten. Netzwerkkommunikation: Remote Method Invocation (RMI). modularen Komponenten und einer Menge von Diensten. transparenter Datenbankzugriff.Einleitung 10 Kapitel 1 Einleitung 1. Asynchrone Kommunikation: Java Message Service (JMS). Namensdienste: Java Naming and Directory Interface (JNDI). Klientenanbindung: Java Server Pages (JSP) . B. . Enterprise Edition).

Für den Outbound–Bereich gibt es schon gute Softwarelösungen. 1. Um dieses Ziel zu erreichen. auf die im Entwurf nicht Rücksicht genommen werden muss. Die Dienstleistungen eines Call Centers gliedern sich unter anderem in die Bereiche Inbound und Outbound [IUK00]. . Enterprise-Beans sind Komponenten verteilter. da diese typischerweise als eine mehrschichtige Webanwendung entworfen werden kann. da hier der Gesprächsverlauf vom Call Center vorgegeben wird. Outbound hingegen bedeutet. wird einerseits eine Dokumentenanalyse der Fachliteratur durchgeführt. die für den Entwurf einer J2EE basierten Softwarelösung zu beachten sind. dass das Call Center bestimmte Personen anruft und Befragungen durchführt. um mögliche konzeptionelle Fehler im Entwurfsstadium zu reduzieren. und insbesondere EJB. Inbound steht dabei für die Entgegennahme von eingehenden Anrufen. dass bei der Entwicklung von Anwendungen auf Basis von J2EE.Einleitung 11 EJB wird wie folgt von Sun Microsystems definiert [DEN00. Ein Grund dafür ist die transparente Verwendung von verschiedensten Technologien.2 Ziel der Diplomarbeit In dieser Diplomarbeit sollen daher allgemein gültige Designrichtlinien für den Entwurf von Enterprise JavaBeans erarbeitet werden. verteilte Anwendungen. 54]. andererseits werden Erfahrungen in einem Projekt (Fallstudie) gesammelt.3 Call Center als Fallstudie Als Fallstudie wurde vom Autor eine Call Center Anwendung ausgewählt. Beispielsweise können bei der Kommunikationsform RMI (Remote Method Invocation) bei falscher Verwendung Performanzprobleme im späteren Betrieb auftreten. die Gefahr von konzeptionellen Fehlern im Entwurfsstadium groß ist. Erfahrung zeigen [Alu01. Daraus werden Faktoren abgeleitet. 7]: Enterprise JavaBeans ist eine Architektur für komponentenorientierte. 1. transaktionsorientierter Geschäftsanwendungen.

Einleitung

12

Für den Inbound–Bereich sind nur wenige Angebote am Markt, da hier die Anforderungen des Kunden den Gesprächsablauf vorgeben und somit die Software schnell und flexibel an die jeweiligen Kundenwünsche angepasst werden muss. Des weiteren müssen die Daten im Inbound–Bereich für die Auftraggeber in vielen Fällen (z.B. bei Umleitung der Eingehenden Firmentelefonate in der Mittagspause zum Call Center) just in time abrufbar sein, d.h. sämtliche Daten sollen für den Auftraggeber über das Internet abrufbar sein. Außerdem sind im Call Center–Bereich die Arbeitsabläufe von der Auftragsannahme bis zur statistischen Auswertung und Verrechnung sehr gut standardisierbar. Das Einsparungs- und Qualitätssicherungspotential durch eine Softwareunterstützung des gesamten Geschäftsprozesses sind somit sehr hoch. Im Rahmen der Diplomarbeit soll nun eine Software-Architektur entwickelt werden, die durch den konsequenten Einsatz von Web–Technologien in Verbindung mit einer Entwicklungsplattform für unternehmenskritische Anwendungen die oben beschriebenen Problembereiche bewältigt. In der Vorphase zu dieser Diplomarbeit konnte ein Kooperationspartner (market calling MarketinggesmbH in Linz) gefunden werden, der im Moment mit dieser Problemstellung konfrontiert ist. Der Prototyp wurde in Kooperation mit diesem Call Center entwickelt. Diese Kooperation soll die praktische Relevanz der Diplomarbeit sicherstellen und hilft, dass Anforderungen aus dem realen Betrieb eines Call Centers in die Betrachtung eingehen.

1.4 Vorgehensweise
Bei der Vorgangsweise zum Lösen des Problems orientiert sich der Autor an dem Buch „Software Engineering, Prototyping und objektorientierte Software - Entwicklung“ [Pom96]. Folgende Phasen der Softwareentwicklung werden für die Lösung des oben beschriebenen Softwaresystems durchlaufen:

1. Problemanalyse Erstellung einer Istzustandsanalyse Hier soll das Problemfeld identifiziert und abgegrenzt werden. Im Rahmen

Einleitung

13

der Istzustandsanalyse werden das aktuelle (Organisations-)System und die betroffenen Betriebsabläufe analysiert und die Benutzerwünsche erfasst. 2. Systemspezifikation Entwicklung eines Pflichtenhefts (Anforderungsdefinition) Dieses Dokument soll genau festlegen, was das geplante Softwaresystem leisten soll und welche Prämissen für dessen Realisierung gelten. Inhalt: a. Ausgangssituation und Zielsetzung b. Systemeinsatz und Systemumgebung c. Benutzerschnittstellen d. Funktionale Anforderungen e. Nichtfunktionale Anforderungen f. Fehlerverhalten 3. Entwurf und Implementierung a. Entwurf der Benutzerschnittstellen b. Objektorientierter Entwurf c. Datenbankentwurf d. Implementierung eines Prototypen Dieses Dokument beinhaltet Abschnitte, welche all die oben genannten Entwicklungsschritte dokumentieren. Kapitel 3 beschreibt eine Literaturanalyse, Kapitel 4 beschreibt dabei die Problemanalyse, Kapitel 5 beschreibt die Systemspezifikation und die Kapitel 6 und Kapitel 7 beschreiben Entwurf und Implementierung. In Kapitel 8 werden Designrichtlinien aus den vorangegangenen Kapiteln und den während des Entwurfs gemachten praktischen Erfahrungen abgeleitet. Kapitel 9 stellt eine Zusammenfassung dieser Arbeit dar.

Die Java 2 Enterprise Edition

14

Kapitel 2

Vorgehensmodell zur Entwicklung eines Softwareprodukts
Das folgende Kapitel stellt eine Zusammenfassung der wesentlichen Schritte des Softwareentwicklungszykluses, wie er von Pomberger, Blaschek in [Pom96] empfohlen wird, dar. Diese Vorgehensweise für die Entwicklung des Softwareprodukts wurde aus folgenden Gründen gewählt: • • Sie ist umfassend, d.h. sie stellt alle Phasen des Softwareentwicklungszykluses detailliert dar. Eine überschneidungsfreie Vorgehensweise ist somit möglich. Sie geht auf die Besonderheiten bei der prototypingorientierten Entwicklung ein. Da das Ziel der Diplomarbeit der Entwurf eines Prototyps ist, war dies ein wesentliches Auswahlkriterium. Sie ist allgemein gehalten (keine Spezialisierung auf bestimmte Branchen oder Sprachen), sodass es für den spezifischen Fall der Entwicklung einer Enterprise JavaBeans basierten Software–Lösung für den Call Center–Bereich gut anwendbar ist.

Die folgenden Kapitel enthalten eine Zusammenfassung des Vorgehensmodells aus [Pom96]. Ziel dieses Kapitels ist einerseits die Auswahl eines geeigneten Vorgehensmodells und andererseits eine kurze Darstellung der wesentlichen Phasen der Softwareentwicklung, um so die Basis für die anschließende Umsetzung (Kapitel

1 Vorgehensmodell bei der Problemanalyse aus [Pom96] Die Auswahl einer zweckmäßigen Technik für die Erhebung des Istzustands hängt von der Art. welche Aufgaben unter welchen Umgebungsbedingungen computergestützt gelöst werden sollen. um sinnvolle und vollständige Fragebögen erstellen zu können. Weiter empfehlenswerte Vorgehensweisen sind die Berichtsmethode. um festzustellen. Einfacher und flexibler. .1 Problemanalyse Das Ziel der Problemanalyse besteht in der Festlegung. was informationstechnisch unterstützt werden soll. dass der Analytiker bereits genaue Kenntnis des Anwendungsgebietes haben muss. 2. Bei der Istzustandsanalyse wird in folgenden Schritten vorgegangen: Systemabgrenzung Systemerhebung Systembeschreibung Abbildung 2. weiterführende Informationen zu den einzelnen Phasen der Softwareentwicklung kann der Leser aus [Pom96] entnehmen. Im Sinne einer systematischen Vorgehensweise bei der Problemanalyse empfiehlt sich zu Beginn eine Analyse des Istzustands durchzuführen.Die Java 2 Enterprise Edition 15 4 bis 7) zu schaffen. der Größe und der Zielsetzungen des Projekts ab. Detailliertere. die Mitarbeit des Analytikers im entsprechenden Anwendungsbereich oder das Datenflussdiagramm. aber schwierig zu verarbeiten und zu dokumentieren sind Einzel.und Gruppeninterviews. Eine häufig eingesetzte Technik ist die Fragebogentechnik. in der die Analytiker detaillierte Fragen an alle Mitarbeiter des zu untersuchenden Bereichs stellen. Das setzt allerdings voraus.

ob und welche Operationen automatisiert werden können. . welche Teile in die Analyse einbezogen werden und welche Teile auszuklammern sind und andererseits in der Erfassung der für das Produkt relevanten Umgebungsbedingungen. Einerseits soll sich eine Istzustandanalyse mit jenen Teilen des Systems befassen. die bereits vorhanden sind. Sie soll Aufschluss geben über: • Die organisatorische Gliederung des zu untersuchenden Systems oder Unternehmensbereichs • Die hierarchische Systemgliederung • Art und Umfang der Verbindungen zu anderen Systemkomponenten oder Unternehmensbereichen • Die Anzahl der System-Benutzer 2.1. Klarheit zu bekommen über das organisatorische Gefüge des Systems oder Unternehmensbereichs.2 Systemerhebung Die Systemerhebung bildet den Kern der Istzustandsanalyse. 2. sich Klarheit darüber zu schaffen. nach denen die unterschiedlichen Prozesse zusammenwirken oder nach denen Führungskräfte und Sachbearbeiter vorgehen. andererseits sollten in der Istzustandsanalyse spätere Ausbauwünsche der Softwarelösung erhoben werden. alle (Entscheidungs-) Regeln kennen zulernen. Strukturanalyse: Der Zweck der Strukturanalyse besteht darin. um dann entscheiden zu können. Aufgabenanalyse: Der Zweck der Aufgabenanalyse besteht darin. Dabei ist es wichtig. für den eine Softwarelösung angestrebt wird.Die Java 2 Enterprise Edition 16 2. Umfang und Art der im zu untersuchenden System oder Unternehmensbereich anfallenden Aufgaben (Operationen) und Besonderheiten des internen Ablaufs dieser Operationen zu erheben.1.1 Systemabgrenzung Der Zweck der Systemabgrenzung besteht einerseits darin. Die Analysetätigkeit kann in folgende Schwerpunkte gegliedert werden: 1.

.Die Java 2 Enterprise Edition 17 3. getrennt nach Dateien und Einzeldaten • Wertebereich der Daten • Verwendete Datenträger • Ordnungsstrukturen. 4. in der die einzelnen Operationen ausgeführt werden müssen und über den Datenfluss zwischen den Operationen. Aufbau • Verteiler • Archivierung 5.) • Grad der Formalisierung. Für jedes Dokument soll eine Beschreibung folgenden Inhalts angelegt werden: • Bezeichnung • Inhalt • Zweck (Kontrollbeleg. Sortierkriterien • Häufigkeit der Verarbeitung • Häufigkeit der Veränderungen • Art und Erfordernisse der Datensicherung • Wachstum des Datenvolumens • Abhängigkeiten zwischen Daten 6. Klarheit über den Umfang und die Art der zu verarbeitenden Daten zu bekommen. Datenanalyse: Der Zweck der Datenanalyse besteht darin. die in dem zu untersuchenden Bereich verwendet und produziert werden. etc. Nummernsysteme. Dokumentenanalyse: Der Zweck der Dokumentenanalyse besteht darin. Ablaufanalyse Die Ablaufanalyse gibt Aufschluss über die Reihenfolge. Kommunikationsanalyse: Die Kommunikationsanalyse beschäftigt sich im Gegensatz zur Ablaufanalyse mit den informellen Beziehungen zwischen den Operationen. Fertigungsanleitung. Im einzelnen sollen dabei die folgenden Erhebungen durchgeführt werden: • Datenvolumen. alle Dokumente und Protokolle zu erheben.

beschrieben. die bei der Systemabgrenzung und bei der Systemerhebung ermittelten Ergebnisse zu ordnen und so zu strukturieren und mit erklärenden Worten zu versehen. zu erstellen.Die Java 2 Enterprise Edition 18 7. jedoch nicht Gegenstand der Implementierung sind. Die Schwachstellenanalyse hat den Zweck. Schwachstellenanalyse Aus den Ergebnissen der vorangegangenen Analyseschritte kann nun festgestellt werden. 2.3 Systembeschreibung Das Ziel der Systembeschreibung besteht darin. Darunter wird die Beschreibung aller Informationen. was das geplante Softwaresystem leisten soll und welche Prämissen für dessen Realisierung gelten. die für den Systemeinsatz erforderlich. in der die Benutzer mit dem System kommunizieren. 2. der genau festlegt. verstanden. . sowohl die einzelnen Operationen als auch das Gesamtsystem nach diesen Fragestellungen zu untersuchen. Systemeinsatz und Systemumgebung: Hier werden die Voraussetzungen. die für den Systemeinsatz gegeben sein müssen. welche Mängel. 3.1. Der Aufbau und Inhalt der Systemspezifikation gliedert sich folgendermaßen: 1. dass eine in sich geschlossene und vollständige Systembeschreibung darstellen. welche Unvollständigkeiten und Redundanzen das System aufweist. Ausgangssituation und Zielsetzung: Dieser Abschnitt enthält eine allgemeine Beschreibung der Ausgangssituation mit Bezug auf die Istzustandsanalyse.2 Systemspezifikation (Anforderungsdefinition) Die Systemspezifikation hat das Ziel einen Kontrakt zwischen Auftraggeber und Software-Entwickler. 2. die Projektziele und eine Abgrenzung dieser Ziele zur Systemumgebung. um die Schwachstellen des Istzustands aufzudecken. Benutzerschnittstellen: Dieser Abschnitt beschreibt die Art und Weise.

auf möglichst kostengünstige Weise eine den Qualitätsanforde- . 5. 7. Die Dokumentation eines Systems ist sowohl Grundlage für die richtige Anwendung des Softwareprodukts (Benutzerhandbuch) als auch für die Systempflege. Zuverlässigkeit. auch ein Glossar über die verwendeten Begriffe und einen ausführlichen Index mit einzuschließen. wie z. unter welchen Bedingungen die Systemabnahme erfolgen soll. Test und Installation und Dokumentation und Wartung werden im Falle einer Weiterentwicklung des Prototyps zu einem kommerziellen Produkt hinzugefügt. gewünschte Antwort. 6. 2. mit dem Ziel.B. sondern als Referenz und Nachschlagewerk verwendet wird. Die Phasen Implementierung.Die Java 2 Enterprise Edition 19 4. 9. Portabilität.und Verarbeitungszeiten aufgezählt. Funktionale Anforderungen: Die vom Benutzer erwarteten Systemfunktionen werden in diesem Abschnitt definiert. Glossar und Index: Da die Systemspezifikation in der Regel nicht sequentiell gelesen. der im Rahmen dieser Diplomarbeit behandelt wird. Nichtfunktionale Anforderungen: Hier werden alle Anforderungen nichtfunktionaler Art. Abnahmekriterien: Dieser Abschnitt legt fest.3 Entwurf Der Entwurf des Prototyps ist die letzte Phase des Softwareentwicklungszykluses. Fehlverhalten: In diesem Abschnitt werden die verschiedenen Fehlerarten und das geforderte Systemverhalten nach Auftreten eines Fehlers diskutiert. Die Kriterien beziehen sich sowohl auf die funktionalen als auch auf die nichtfunktionalen Anforderungen. 8. Der Zweck des Entwurfs besteht darin. ist es zweckmäßig. Dokumentationsanforderungen: Der Umfang und die Art der Dokumentation wird hier festgelegt. die Architektur des Softwaresystems festzulegen.

Wartung. Der Entwurfsprozess umfasst grob skizziert folgende Tätigkeiten (vgl. Festlegung der Schnittstellen der Komponenten.Die Java 2 Enterprise Edition 20 rungen entsprechende Implementierung zu erreichen. Es muss auf Fragen der Erweiterbarkeit. dazu [Som85]): • • Problemadäquate Zerlegung des Gesamtsystems in Teilsysteme und Spezifikation der Wechselwirkungen zwischen den Teilsystemen. Zerlegung der Teilsysteme in Komponenten (Module) und Spezifikation der Anforderungen an diese Komponenten. d. • . etc. dass die Architektur an sich ändernde Anforderungen leicht angepasst werden kann. den in der Systemspezifikation festgelegten Funktionsumfang verfügbar zu machen und zu gewährleisten. Ausgehend von einer Systemspezifikation wird in der Entwurfsphase die Systemarchitektur mit dem Ziel entworfen. Rücksicht genommen werden.h. Entwurf der Algorithmen zur Bereitstellung der durch die Komponentenschnittstellen definierten Funktionalität. Portabilität.

sie beinhaltet dazu die Java Servlets. Bei JavaServer Pages handelt es sich um eine Erweiterung der Java Servlets. verteilten Anwendungen. in die Java-Befehle eingebettet sind.2 veröffentlicht [J2E99]. . da sie die Möglichkeit bieten. server. Die Spezifikation der J2EE definiert eine Plattform für die Entwicklung von internetfähigen. JavaServer Pages bestehen größtenteils aus HTML.und plattformunabhängig die Funktionalität eines Servers zu erweitern. die dynamisch Inhalte in HTML.oder XML-Vorlagen einfügt. Sie haben in den letzten Jahren bei der Realisierung von dynamischen Internetseiten eine große Verbreitung erlangt. Java Servlets sind Java-Programme.Die Java 2 Enterprise Edition 21 Kapitel 3 Die Java 2 Enterprise Edition Im Dezember 1999 hat Sun Microsystems die Spezifikation und die Referenzimplementierung der Java 2 Enterprise Edition (J2EE) in der Version 1. indem sie dynamisch und interaktiv Seiteninhalte generieren. die die Funktionalität eines Web-Servers erweitern. Sie wurden entwickelt. Die Plattform soll die Entwicklung durch die Automatisierung von Basisaufgaben der Programmierung und durch den Einsatz von standardisierten modularen Komponenten vereinfachen.oder XML-Befehlen. um die Präsentation stärker von der Programmierung zu trennen. JavaServer Pages und Enterprise JavaBeans.

das die Logik eines Geschäftsprozesses implementiert [Rom99. Zu unterscheiden sind verschiedene Typen von JavaBeans: Entity Beans sind typischerweise Objekte.Die Java 2 Enterprise Edition 22 Enterprise JavaBeans sind eine Komponentenarchitektur zur Entwicklung und zum Einsatz von objektorientierten. welche Nachrichten an sie verschicken. Eine Message Driven Bean (steht seit EJB 2. Diese Komponenten sind vom Client. Daten zu speichern oder gespeicherte Daten zu verändern [Merk00. Der EJBContainer ist dabei jene Komponente von J2EE. Abgelegt werden die Daten der Entity Beans zum Beispiel in einer relationalen Datenbank [Den00.und Zustandsverwaltung und vom Multithreading. Zwei Ausprägungen der Session Beans sind zu unterscheiden. greift die Session Bean auf andere Enterprise JavaBeans und Dienste zu. 19f]. Eine Session Bean stellt üblicherweise ein Objekt dar. welche die Laufzeitumgebung für EJBs zur Verfügung stellt. die persistent gespeichert werden. Um die zugehörige Funktionalität zur Verfügung zu stellen. dass die Beans grundsätzlich auf unterschiedlichen Plattformen ohne Änderung des Quellcodes und ohne neue Kompilierung einsetzbar sind. . befreit wird [Mate99. insbesondere ermöglichen sie mehreren Clients den parallelen Zugriff auf transaktionsgesicherte Daten.0 zur Verfügung) ist eine spezielle Komponente. Die Komponente nimmt Aufgaben entgegen und führt diese aus. Mit Hilfe von Enterprise JavaBeans können verteilte Objekte serverseitig unter Einsatz entsprechender Tools entwickelt werden. Im Unterschied zu Entity Beans beinhalten die Session Beans keine Daten. getrennt. 212]. ein Client kann die Komponente nicht direkt über ein Komponenteninterface ansprechen. Die Enterprise JavaBeans-Architektur erleichtert die Erstellung von Applikationen. Sie dienen dazu. h. verteilten. beispielsweise von der Low-Level-Transaktions. Durchgeführt werden die Aufgaben vielmehr-gesteuert über vom Anwendungsentwickler gesetzte Parameter-durch den Application Server. Ein weiterer Vorteil von Enterprise JavaBeans ist darin zu sehen. die Daten aus einer Datenbank repräsentieren. skalierbaren Applikationen. die Stateless Session Beans und die Stateful Session Beans. 47]. 118f]. D. welche JMS-Nachrichten empfangen kann. da der Anwendungsentwickler von grundlegenden Programmieraufgaben. die vom EJB-Container zur Verfügung gestellt werden. sondern die Kommunikation verläuft nur über das JMS – API [Rom99. 83f].

1 Allgemeine Systemarchitektur J2EE Die allgemeine Systemarchitektur von J2EE ist von zentraler Bedeutung für den Systementwurf. Die Datenbankschicht repräsentiert eine relationale Datenbank. • • • Abbildung 3. wie ein HTML-Browser. die in der J2EE-Architektur verwendet werden. Java Applet oder eine Java Applikation.1 gibt einen Überblick über die Komponenten. dass die Clients einen aktuellen HTML-Browser mit Unterstützung von DHTML und Javascript bieten. welche je nach Performanceanforderungen ausgewählt werden muss. dargestellt: • Der Client symbolisiert hier die Benutzerschnittstelle.Die Java 2 Enterprise Edition 23 3. die durch die J2EE definiert werden. die dem Benutzer zur Interaktion mit dem System bereitgestellt wird. Die Schicht der JavaServer Pages und Servlets beinhaltet folgende Aufgaben: o Bereitstellung der Benutzerschnittstellen o Verarbeitung der Benutzeranfragen o Kommunikation mit der dahinter liegende Schicht der Enterprise JavaBeans Die Enterprise JavaBeans repräsentieren die Geschäftslogik der Anwendung und soll eine eindeutige Trennung von Benutzerschnittstellen und Anwendungslogik gewährleisten. Aus diesem Grund soll die Interaktion des Benutzers mit dem System über HTML-Browser erfolgen. . Hier werden die verschieden Schichten. clientseitig möglichst unabhängig vom installierten Betriebssystem zu sein. Einschränkungen hierbei sind. Clients können verschiedene Ausprägungen einnehmen. Unter anderem ist Ziel des Entwurfs.

Die Java 2 Enterprise Edition 24 Abbildung 3. welches die Kommunikation zwischen diesen Schichten darstellt.2 zeigt ein Beispiel-Sequenzdiagramm.1 Systemarchitektur J2EE [MID99] Abbildung 3.2 Sequenzdiagramm der Kommunikation in J2EE . Abbildung 3.

2. Logisch wird eine Session Bean als serverseitige Erweiterung des Clientprogramms betrachtet. da sie typischerweise die Logik eines Geschäftsprozesses realisiert.2 Enterprise JavaBeans 3. Zustandslose Session Beans sind häufig allgemeinen Zwecken dienende. die auf der Basis einiger Parameter eine Anfrage ausführen und ein Ergebnis zurückliefern. 226]. 3. Man kann sich eine zustandlose Session Bean als eine Menge von Prozeduren oder Stapelprogrammen vorstellen. Dieser Zustand wird Konversationszustand genannt. Ein Client hat über den EJB-Container den exklusiven Zugriff auf eine bestimmte Session-Bean-Instanz und kann deren Funktionalität nutzen.1.2. 63]. repräsentiert eine Session Bean ein Geschäftsobjekt.Die Java 2 Enterprise Edition 25 3. wiederverwendbare SoftwareDienste [Mon00. Dabei umfasst der Begriff „Client“ andere Beans auf dem Server und Clientprogramme auf einem Clientrechner. Für die Realisierung ihrer Funktionalität kann die Session Bean andere Beans und die Services. Wenn eine Methode an einer zustandslosen Session Bean aufgerufen wird. Sie führt Aufgaben im Namen des Clients aus und verwaltet einen Zustand für diesen Client.1 Zustandslose Session Beans Eine zustandslose Session Bean ist eine Sammlung verwandter Dienste.1 Session Beans Wie bereits erwähnt. die Durchführung einer Überweisung einer Banken-Software oder die Verwaltung eines Materiallagers sein. ohne das bekannt ist. die jeweils durch eine Methode repräsentiert werden. In der Praxis könnte die Funktionalität einer Session Bean das Aufstellen einer Bilanz in einem Finanzbuchhaltungssystem. weil er eine noch andau- . verwenden [Den00. die Bean verwaltet keinen Zustand zwischen den einzelnen Methodenaufrufen. die der EJB-Container zur Verfügung stellt. Sie beinhalten keinen Status von einem Methodenaufruf zum nächsten.2 Zustandsbehaftete Session Beans Eine zustandsbehaftete Session Bean ist eine Erweiterung der Client-Applikation. 3. wird diese Methode ausgeführt und ihr Ergebnis zurückgegeben.2.1. welche Anfragen an die Bean vorher gestellt worden sind oder welche folgen.

weil der Entwickler sich auf die Geschäftslogik konzentrieren und die Verantwortlichkeit für die Persistenz an den EJB-Container delegieren kann.2 Entity Beans Eine Entity Bean ist ein Objekt. dass die Bean unabhängig von der Datenbank entwickelt werden kann. die später dazu verwendet wird. da Stateless Session Beans nur eine Anfrage eines Clients bearbeiten und dann einem anderen Client zur Verfügung stehen [Mon00. gibt der Entwickler an. die in einem Zwei-Schichten-System in der Client-Applikation untergebracht wäre. Wenn man die Bean in Betrieb nimmt.1 Container-verwaltete Persistenz Container-verwaltete Entity Beans sind diejenigen Komponenten. Wenn man die Felder definiert hat. heißen Container-verwaltete Felder.2. Dabei werden zwei Arten von Persistenz unterschieden: 3. die auf die Datenbank abgebildet werden. An einer zustandsbehafteten Session Bean aufgerufene Methoden können Daten in diesen Konversationszustand schreiben oder aus ihm lesen. Der Vorteil der Container-verwalteten Persistenz liegt darin. Die meisten Beans werden primitive Java-Typen verwenden. 226]. Container-verwaltete Felder können beliebige primitive Java-Typen oder serialisierbare Objekte sein. Sie repräsentieren die Logik. weil es einfacher ist. diese Daten werden dann von allen Methoden der Bean gemeinsam genutzt. Als Nachteil ergibt sich daraus eine langsamere Ausführungsgeschwindigkeit. das typischerweise Daten aus einer Datenbank repräsentiert und eine objektorientierte Schnittstelle zu diesen Daten bereitstellt. und beschrieben hat. .Die Java 2 Enterprise Edition 26 ernde Konversation zwischen der zustandsbehafteten Session Bean und dem Client repräsentiert. Java Primitive auf relationale Datentypen abzubilden. welche Felder in der Entität vom Container verwaltet werden sollen und wie diese auf die Datenbank abgebildet werden. Zustandsbehaftete Session Beans sind normalerweise Szenario-spezifisch.2.2. wenn es um die Persistenz in einer relationalen Datenbank geht. die am einfachsten zu entwickeln sind. erzeugt der Container automatisch die notwendige Logik. um den Zustand der BeanInstanz automatisch zu speichern. die automatisch verwaltet werden sollen. wie diese auf die Datenbank abzubilden sind. Felder. 3.

aktualisiert und entfernt werden. um zu definieren. 161] von Bean verwalteter Persistenz besteht darin.2. Die Bean-verwaltete Persistenz gestattet dem Entwickler mehr Flexibilität darin. 161] der Bean-verwalteten Persitenz besteht darin. 160f]. Der Nachteil [Mon00. Aber manchmal wird es auch schwieriger. Man muss die Struktur der Datenbank verstehen und die Logik entwickeln. dass mehr Arbeit zur Definition der Bean notwendig ist. Container-verwaltete Beans können sowohl relationale als auch Objekt-Datenbanken verwenden. jedes Feld der Bean-Instanz auf eine Spalte in der Datenbank abzubilden oder die Bean in eine Datei zu serialisieren. welche Datenbank verwendet wird und wie die Felder der Bean-Klasse auf die Datenbank abgebildet werden sollen. Die Bean-verwaltete Persistenz ist im Wesentlichen immer dann im Vorteil gegenüber der Container-verwalteten Persistenz. dass sie kompliziertere Abbildungswerkzeuge benötigen. wie der Zustand zwischen der Bean-Instanz und der Datenbank verwaltet wird. wie die Felder der Bean auf die Datenbank abgebildet werden sollen. Um den Code für die Persistenz schreiben zu können. muss man wissen. eine Kombination aus verschiedenen Datenbanken oder mit anderen Ressourcen definiert werden. In manchen Fällen reicht es. Beispielsweise könnte der Zustand einer Bean anhand eines komplexen relationalen DatenbankJoins definiert sein [Mon00.Die Java 2 Enterprise Edition 27 ihren Zustand zu speichern. EntityBeans. dass diese Bean an einen bestimmten Typ und eine bestimmte Struktur in der Datenbank gebunden ist. 3. profitieren von der Bean-verwalteten Persistenz.2 Bean-verwaltete Persistenz Die Bean-verwaltete Persistenz ist aufwändiger als die Container-verwaltete Persistenz. weil die Persistenz-Logik explizit in der Bean-Klasse programmiert werden muss. den Zustand der Bean-Instanz auf die Datenbank abzubilden. . Ein weiterer Nachteil [Mon00. die durch komplexe Joins. Der Nachteil Container-verwalteter Beans besteht darin.2. Jede Änderung in der Datenbank oder der Struktur der Daten erfordert Änderungen in der Definition der Bean-Instanz. mit der die mit einer Entität verbundenen Daten erzeugt. wenn die Werkzeuge zur Inbetriebnahme nicht dazu geeignet sind.

Die Java 2 Enterprise Edition 28 3.Deskriptor die Beschreibung der objektrelationalen Zuordnung. Transaktionsverwaltung. Dadurch wird der Container in die Lage versetzt. sondern immer nur über das zugehörige Home Objekt bzw.3 Bestandteile eine Enterprise JavaBean und seine Ablaufumgebung Der Deployment . also der Abbildung der Objektstruktur auf das relationale Datenmodell der verwendeten Entity Beans [WI0302]. zu versehen [WI0302]. das EJB Objekt. Abbildung 3. bezüglich Transaktion und Sicherheit.Deskriptor enthält eine deklarative Beschreibung (als XML-Dokument) des Verhaltens der EJB zur Laufzeit u. Der Client tritt nie mit einer EJB direkt in Kontakt. Dies ist zum einen das Home Interface. Methodenaufrufe von Seiten des Clients mit Zusatzfunktionalität bezüglich Persistenz.3 Bestandteile von EJBs Enterprise JavaBeans bestehen aus mehreren Teilen. Weiters beinhaltet der Deployment . ist aber eher unter dem Namen EJB Remote Interface bekannt). a. Zum anderen ist dies das EJB Remote Interface (das Interface heißt tatsächlich EJBObject. das alle Businessmethoden der Bean auflistet. Erzeugen und Löschen der betreffenden EJB auflistet. Auch hier wird die zugehörige EJB-Klasse automatisch generiert. . etc. Daraus wird mit Hilfe des Applikationsservers die zugehörige Implementierung (die EJB Home Klasse) generiert. welches alle Methoden zum Suchen.

Integrationsschicht Dieser Bereich beschreibt die Patterns Data Access Object und Service Activator. asynchrone Dienste zu aktivieren.2) eine zentrale Rolle zur Steuerung des Gesamtsystems ein. es werden Vorlagen für Servlets und Java Server Pages beschrieben. wann und wie die Session Beans zum Einsatz kommen. Diese Patterns werden folgendermaßen klassifiziert: • Präsentationsschicht Dieser Teil bietet Vorlagen für die Präsentationsschicht einer Anwendung. Das Data Acces Object Pattern stellt eine allgemeine Schnittstelle zu zu einem persistenten Speichermechanismus dar. die für die Bereitstellung der Benutzerschnittstellen und das Session Management verantwortlich sind.sun. sollen die wichtigsten Patterns für die Entwicklung dieser Anwendung beschrieben werden. Diese Schablonen werden im J2EE Patterns Catalog1 beschrieben [Alu01].4. Das heißt.1 zeigt eine Auflistung aller in [Alu01] beschriebenen Vorlagen für die Präsentationsschicht. Präsentationsschicht • • 3.java. Es legt fest.1. 1 http://developer.1 Tabelle 3.4 Patterns (Schablonen) Für die Entwicklung von mehrschichtigen Anwendungen mittels J2EE stellt Sun Microsystems mehrere Schablonen für den Entwurf zur Verfügung.4. wie die Entity Beans richtig eingesetzt werden und wie ein Business Prozess auf EJBs richtig abgebildet wird. Dabei nimmt der Front Controller (siehe 3.Die Java 2 Enterprise Edition 29 3.html . Mit dem Service Activator Pattern besteht die Möglichkeit.com/developer/restricted/patterns/J2EEPatternsAtAGlance. Um eine Grundlage für den Entwurf zu schaffen. Businessschicht Dieser Teil beschreibt Vorlagen für den richtigen Einsatz von EJB-Komponenten.

um Daten zu senden? Wird der Browsertyp des Clients unterstützt? etc. Verbindet eine Verwaltungskomponente mit den Front Controller und dem View Helper Pattern. Der erste prüft die Anfrage und entscheidet. . Unter anderem können folgende Probleme mit dieser Vorlage behandelt werden: • • • • • • • Hat sich der Client bereits authentifiziert? Hat der Client eine gültige Session? Ist der Client aus einem vertrauenswürdigen Netzwerk? Verstößt der Anfragepfad gegen eine Integritätsbestimmung? Welches Enkodierungsformat verwendet der Client.1. wobei viele Aktivitäten zur Ansichtsverarbeitung weitergeleitet wird. Tabelle 3. die Anfragen eines Clients behandelt. Der andere Type bearbeitet die Anfrage und gibt die möglicherweise veränderte Anfrage für die Verarbeitung weiter. die nicht zur Formatierung der Präsentation verwendet wird. oder ob die Anfrage aufgrund eines Fehlers abgebrochen wird. die unabhängig von den eigentlichen Worker-Klassen Anfragen bearbeitet und für die spätere Bearbeitung vorbereitet. Erstellt eine zusammengestellte Ansicht von einzelnen Komponenten.1 Intercepting Filter Das Pattern Intercepting Filter bildet die erste Instanz. Zwei Typen von Intercepting Filter existieren. ob die Anfrage weiterverarbeitet wird.Die Java 2 Enterprise Edition 30 Pattern Name Intercepting Filter Front Controller View Helper Composite View Service To Worker Dispatcher View Übersicht Hilfsklassen zur Vorbehandlung und Nachbehandlung einer Anfrage Eine zentrale Kontrollklasse zum behandeln einer Anfrage Kapselt Logik.1 Designvorlagen für die Präsentationsschicht 3. Dieses Pattern bietet eine Klassenstruktur.4. Verbindet eine Verwaltungskomponente mit dem Front Controller und dem View Helper Pattern.

2 Front Controller Der Front Controller stellt einen zentralen Einstiegspunkt des Systems für die Behandlung von Anfragen zur Verfügung. welche dann in der richtigen Reihenfolge abgearbeitet werden. Wenn der Benutzer auf die verschiedenen Ansichten direkt zugreift. ohne einen zentralen Dienst zu benutzen. wird die resultierende Anfrage an das Target-Objekt weitergeleitet und von diesem verarbeitet. Der Filtermanager verwaltet die Filterverarbeitung. FilterOne und FilterTwo sind spezielle Filter. Inhaltsfindung.4. um eine Integration von Systemdiensten.1. können folgende Probleme auftreten: • Jede Anzeige benötigt eigene Systemdienste. Das FilterChain-Objekt ist eine sortierte Sammlung von unabhängigen Filtern. Wurde die Anfrage durch die Filter erfolgreich abgearbeitet. welches die Arbeitsweise des Patterns Intercepting Filter veranschaulichen soll. Es wird ein FilterChain-Objekt mit den dazugehörigen Filtern erzeugt.4 Sequenzdiagramm Intercepting Filter Abbildung 3. was oft zu duplizierten Code führt . 3.4 zeigt ein Sequenzdiagramm.Die Java 2 Enterprise Edition 31 Abbildung 3. die von der FilterChain zur Verarbeitung der Anfrage verwendet werden. Ansichtsverwaltung und Navigation zu gewährleisten.

Außerdem ist eine verteilte Kontrolle schwieriger zu warten.4. weil sich dadurch Änderungen oft auf verschiedene Komponenten ausbreiten [Alu01.5 zeigt ein Sequenzdiagramm. keinen direkten Zugriff auf Datenbanken.1. Dieses Pattern ist allgemein gehalten und empfiehlt generell.3 View Helper Dieses Pattern wird zur Trennung der Ansicht (View) und der Anwendungslogik verwendet. Abbildung 3. Die Kapselung der Anwendungslogik in Hilfskomponenten hat das Ziel.Die Java 2 Enterprise Edition 32 • Ansichtsnavigation wird den einzelnen Anzeigen überlassen. welches die Kommunikation zwischen einem Front Controller. dem Client und anderen Hilfsklassen darstellt Abbildung 3. 172].5 Sequenzdiagramm eines Front Controllers Das Dispatcher Objekt übernimmt die Aufgabe der Auswahl der benötigten Ansicht und leitet an diese die Anfrage weiter. 3. Das kann zur Vermischung von Inhalt und Navigation führen. einen möglichst modularen Aufbau der Anwendung zu erreichen und die Wiederverwendbar- . EJB-Komponenten und andere Dienste von View-Komponenten. um eine möglichst hohe Unabhängigkeit der Ansicht von der Logik zu erreichen.

Dies hat den Vorteil. Die Dispatcher Komponente kann entweder als eigene Klasse oder direkt im Front Controller implementiert werden. Dieses Pattern beschreibt eine Kombination aus Front Controller und View Helper Patterns gemeinsam mit einem speziellen Dispatcher Objekt.4 Composite View Das Composite View Pattern bildet eine Vorlage. Beispiele für solche Komponenten sind: • • • • • • Hauptnavigation Suchformular Detailnavigation Listen Formulare etc. diese Komponente entscheidet anhand der Anfrage. wie mehrere Ansichtselemente zu einer Ansicht zusammengefasst werden. d. Dies steht im Gegensatz zum in Kapitel 3. . und sich diese Änderungen verteilt auf mehrere Benutzerschittstellen auswirken.1. Eine Composite View verwendet diese atomaren Ansichten und fasst sie zu einer fertigen Benutzerschnittstelle zusammen. 3.6 beschriebenen Pattern Dispatcher View. das eine wichtige Rolle einnimmt.1.1. Die grundlegenden Aufgaben eines Dispatchers sind das View-Management. dass Teile der Benutzerschnittstelle individuell verändert werden können. wo der Dispatcher eine eher untergeordnete Rolle einnimmt.4.5 Service to Worker Das Service to Worker Pattern beschreibt eine Kombination von Patterns aus [Alu01]. Der Focus liegt hierbei beim Front Controller und dem Dispatcher Objekt.h. Dies erhöht wiederum die Wiederverwendbarkeit.4. Die Benutzerschnittstelle einer Anwendung besteht häufig aus verschiedenen Komponenten (atomare Ansichten).Die Java 2 Enterprise Edition 33 keit zu erhöhen welches einem generelles Argument für mehrschichtige Anwendungen entspricht. welche Ansichten (Views) dem Client als Antwort zur Verfügung gestellt werden.4. 3.

ohne aus dynamisch generierten Daten Entscheidungen treffen zu müssen.1. desto mehr passt es in das Pattern Service To Worker.2 Businessschicht Tabelle 3. direkt in die Anfrage kodiert sein.4. Je größer die Aufgaben dieser Komponente sind.5 beschriebenen Pattern Service to Worker wird hier der Dispatcher Komponente einer weniger wichtige Rolle zugeteilt. 3. . bzw. welche Ansicht als nächstes folgt.4. Dabei könnte die benötigte View. deren Helper Komponenten selbst.1. wie die Präsentationsschicht als gesamtes System realisiert werden kann. 3. entscheidet dabei die View.Die Java 2 Enterprise Edition 34 Dabei kann der Dispatcher anhand statisch vorgegebenen Informationen oder dynamisch anhand verschiedenster Informationen entscheiden.2 gibt eine Übersicht aller in [Alu01] beschriebenen Vorlagen für die Businessschicht. Im Gegensatz zu dem in Kapitel 3.4. Welche Daten dem Benutzer präsentiert werden.6 Dispatcher View Das Dispatcher View Pattern zeigt eine mögliche Systemstruktur. die vom Client erwartet wird.

und Business Schichten durch Bereitstellung einer einheitlichen Schnittstelle zu den Service Klassen.4. dass Ausnahmebehandlungen der EJBs und anderer Dienste auf Applikationsebene gebracht werden können.1 Business Delegate Das Business Delegate Pattern dient zur Entkopplung der Präsentationsschicht von der Businessschicht. . wenn an der Struktur der EJB-Komponenten Änderungen erforderlich sind. Durch eine einheitliche Schnittstelle zur Businessschicht muss die Präsentationsschicht nicht dringend verändert werden. Es versteckt die Komplexität der darunterliegenden Implementierung der Details der Dienste wie Lookup und Details der EJB-Struktur. Versteckt Geschäftskomplexität und zentralisiert den Arbeitsablauf. Ein weiterer Vorteil der Business Delegate Komponente ergibt sich durch die Möglichkeit. Unterstütz Datenaustausch zwischen einzelnen Schichten mit wenig Netzwerkkommunikation. Sammelt Objekte von verschiedenen Datenquellen in ein Objekt.2 Designvorlagen für die Businessschicht Value Object Session Facade Composite Entity Value Object Assembler Value List Handler Service Locator 3.2. Die Entkopplung der Präsentationsschicht und der Businessschicht erleichtert Änderungen der Struktur der Businessschicht.Die Java 2 Enterprise Edition 35 Pattern Name Business Delegate Übersicht Entkoppelt Präsentations. Ergebnispuffer und Ergebnisverwaltung. Verwaltet Anfragenausführen. Daraus resultieren möglicherweise bessere Fehlermeldungen für den Benutzer. Kapselt die Komplexität des Suchens und Erzeugens von Diensten. Tabelle 3. Beschreibt den Entwurf von grobkörnigen Entity Beans durch Gruppierung von Abhängigen Objekten in einzelne Entity Beans.

Das bedeutet dass.Die Java 2 Enterprise Edition 36 Abbildung 3. . Sie fassen mehrere atomare Informationselemente zu einer komplexen Struktur zusammen. falls eine Komponente Daten einer anderen Komponente benötigt. dass weniger Netzwerkkommunikation zur Übertragung von Daten erforderlich ist. Abbildung 3. Alle Zugriffe des Clients auf Services werden über die Business Delegate Komponente durchgeführt.2 Value Object Value Objects dienen zur Kommunikation zwischen Komponenten und Schichten. Ohne Value Object muss jedes atomare Datenelement einzeln angefordert werden und benötigt je nach gewünschter Information dementsprechend viele Netzwerkverbindungen. Die Zusammenfassung atomarer Datenelemente zu komplexeren Strukturen hat den Vorteil.4.6 zeigt ein einfaches Sequenzdiagramm.6 Sequenzdiagramm Business Delegate 3. diese bei Verwendung von Value Objects nur einmal eine Netzwerkverbindung herstellen muss. Außerdem werden Value Objects von den Entity Beans für die Zwischenspeicherung ihrer persistenten Datenfelder verwendet.2. wie eine Business Delegate Komponente eingesetzt werden kann.

Die Java 2 Enterprise Edition

37

Abbildung 3.7 Sequenzdiagramm Value Object

Abbildung 3.7 zeigt ein Sequenzdiagramm, wie Value Objects eingesetzt werden können. Der Client fordert von der Komponente BusinessObject Daten an und bekommt eine eigene Kopie des Value Objects geliefert. Danach kann der Client lokal diese Daten verarbeiten. 3.4.2.3 Session Facade Die Session Facade dient zur Kapselung der Komplexität der Interaktionen zwischen Geschäftsobjekten in einem Arbeitsablauf. Eine Session Facade wird als eine Session Bean implementiert und fasst einen logisch zusammenhängenden Arbeitsablauf in einem Geschäftsprozess zusammen und bietet den Clients dieser Session Bean ein einfacher zu benutzendes Interface. Abbildung 3.8 zeigt ein Sequenzdiagramm, welches die Arbeitsweise einer Session Facade erklärt. Der Client benutzte die Session Facade, um mittels einfacher Methodenaufrufe kompliziertere Aktionen durchzuführen. Die Session Facade kann dabei direkt auf Entity Beans zugreifen, andere Session Beans verwenden, auf andere Objekte wie ein Data Access Object zugreifen oder auch wieder Dienste einer anderen Session Facade verwenden. Die Session Facade

Die Java 2 Enterprise Edition

38

übernimmt dabei die Steuerung von komplizierteren Arbeitsabläufen und kontrolliert die Kommunikation zwischen Client und Geschäftsobjekten.

Abbildung 3.8 Sequenzdiagramm Session Facade

Eine Session Facade kann entweder als zustandslose Session Bean oder als zustandsbehaftete Session Bean realisiert werden. Geschäftsprozesse, die durch einen einzelnen Methodenaufruf durchgeführt werden, können als zustandslose Session Bean realisiert werden. Geschäftsprozesse die mehrere Methodenaufrufe benötigen werden besser als zustandsbehaftete Session Bean realisert. Es besteht auch die Möglichkeit von 3.4.2.4 Composite Entity Das Pattern Composite Entity beschreibt eine Möglichkeit, Daten, die voneinander abhängig sind, als ganzes in eine Entity Bean zu sammeln. Diese Art der Entity Beans verwalten nicht nur einen einzelnen Eintrag einer Tabelle, sondern vielmehr Daten aus mehreren Tabellen, die untereinander in Beziehung stehen. Es repräsentiert also einen gesamten Graphen von Datenobjekten. Folgende Vorteile ergeben sich aus dieser Vorgangsweise: • Reduziert Beziehungen zwischen Entity Beans Dieses Pattern übernimmt eine zentrale Rolle bei der Verwaltung der Beziehungen und der Objekthierarchie von Daten. Verbessert die Überschaubarkeit durch eine geringere Anzahl von Entity Beans Verbessert die Performance durch weniger Netzwerkkommunikation

• •

Die Java 2 Enterprise Edition

39

• •

Reduziert die Abhängigkeit vom Datenbankschema Erhöht die Objektgranularität Der Client kann durch eine einzelne Anfrage die gesamten Benötigten Daten mit Hilfe eines Composite Value Object erhalten.

Ein Problem von Composite Entities ist der erhöhte Aufwand zum Speichern und Laden der relevanten Daten. Da beim Laden oder Speichern nicht immer alle Daten verarbeitet werden sollten, ist ein intelligenter Lade bzw. Speichermechanismus erforderlich. 3.4.2.5 Value Object Assembler Das Pattern Value Object Assembler sammelt Daten von verschieden Komponenten wie Entity Beans, Session Beans oder Data Access Objects, und verpackt diese in spezielle Composite Value Objects. Der Client kann durch einen einzelnen Methodenaufruf alle gewünschten Daten erhalten. Clients dürfen in diesem Fall die Daten nur zum Lesen verwenden, diese aber nicht verändern bzw. in einer veränderten Form zurückgeben. Da der Client bei Verwendung dieses Patterns nicht die genaue Struktur der Geschäftsobjekte, von denen er Daten benötigt, kennen muss, verringert sich dessen Abhängigkeit von der Struktur des übrigen Systems.

Abbildung 3.9 Sequenzdiagramm Value Object Assembler

Abbildung 3.9 zeigt ein Sequenzdiagramm, welches den Ablauf der Interaktion einer Value Object Assembler (VOA) Komponente mit anderen Komponenten beschreibt.

der z.Die Java 2 Enterprise Edition 40 Der Client fordert beim VOA Daten an. Vorteile eines Service Locator Objekts sind: • • • • Wiederverwendung durch verschiedene Clients Reduzierung der Codekomplexität Kontrolle an zentraler Stelle Bessere Performance durch Cachefunktionalität . Die Ausführung als Java Objekt wird nur dann empfohlen.7 Service Locater Das Service Locator Pattern abstrahiert die JNDI Benutzung und versteckt die Komplexität des Findens von EJB-Komponenten. folgendes Interface zur Verfügung stellen könnte: • • • • • getSize() liefert die Anzahl der Ergebnisse in der Ergebnismenge getCurrentElement() liefert das aktuelle Element in der Liste getNextElement() liefert das nächste Element in der Liste getPreviousElement() liefert das vorangegangene Element in der Liste resetIndex() setzt den Index auf das erste Element in der Liste Je nach Anforderung können natürlich weitere Methoden definiert werden. Ansonsten wird eine Session Bean zur Implementierung eines Value List Handlers empfohlen.6 Value List Handler Das Pattern Value List Handler dient dem Client zum Zugriff auf Daten in Listenform und repräsentiert eine Ergebnismenge einer Abfrage. wenn kein EJB-Container für die Anwendung verwendet wird. 3.4.2. B. Ein Value List Handler kann entweder als Java Objekt oder als Stateful Session Bean implementiert werden.2. diese Daten werden vom VOA gesammelt und mit Hilfe eines Value Objects dem Client zurückgegeben. Der Value List Handler präsentiert dem Client die Daten mit Hilfe eines Iterators. 3.4.

Der Client fordert über eine Instanz der ServiceLocator-Klasse einen speziellen Dienst an. Der Client benötigt nur die Information.B. Die gesamte Komplexität des Zugriffs auf das JNDI-Interface wird von dem ServiceLocator-Objekt verborgen. . Danach kann der Client mit dem zurückgelieferten Service (z.10 zeigt ein Sequenzdiagramm welches den Ablauf einer Serviceanfrage mit Hilfe eines Service Locator Objekts darstellt. ein Home-Objekt einer speziellen EJB) weiterarbeiten. welchen Dienst er benötigt.Die Java 2 Enterprise Edition 41 Abbildung 3.10 Sequenzdiagramm Service Locator Abbildung 3.

Vorteile eines DAO sind: • • • • Transparente Benutzung von Datenquellen Leichtere Migration des Systems Reduziert Codekomplexität in Geschäftsobjekten Zentralisiert alle Datenzugriffe in eine separate Schicht Das DAO kann nicht bei containerverwalteten Entity Beans verwendet werden. bzw. Session Beans oder Beanverwaltete Entity Beans empfohlen.2 Service Activator Das Service Activator Pattern beschreibt einen Dienst.1 Data Access Object Ein Data Access Object (DAO) wird als Schicht zwischen der persistenten Datenhaltung und Komponenten wie Servlets.3 Integrationsschicht Tabelle 3. da diese die Daten direkt über den Container erhalten.3.3 Designvorlagen für die Integrationsschicht Service Activator 3. auszuführen. die durch eine Clientmessage aktiviert werden. Tabelle 3.Die Java 2 Enterprise Edition 42 3.3 zeigt eine Auflistung aller in [Alu01] beschriebenen Vorlagen für die Integrationsschicht.4.3. um asynchrone Aktionen. 3. ablegen. Pattern Name Data Access Object Übersicht Abstrahiert Datenquellen.4. Ermöglicht asynchrone Ausführung von Diensten. Stellt transparenten Zugriff auf Datenquellen zur Verfügung. .4.

Dabei wird aber auch auf spezifische Probleme. Ist die Aktion vollständig abgeschlossen.11 zeigt ein Sequenzdiagramm.MessageListener Interface.Die Java 2 Enterprise Edition 43 Abbildung 3. die einem Anwendungsentwickler dabei helfen. welche bei einer eingehenden Nachricht aufgerufen wird.11 Sequenzdiagramm ServiceActivator Abbildung 3.jms. Die Nachricht wird ausgewertet und aktiviert die gewünschte Aktion bei den Geschäftsobjekten. die beim Entwurf von J2EE-Anwendungen entstehen können.4. wird dem Client.4 Zusammenfassung Die in den vorangegangenen Abschnitten dargestellten Designvorlagen können für die verschieden Schichten in einer mehrschichtigen Anwendung verwendet werden. Es werden Strategien vorgestellt. 3. welches in der JMS Spezifikation beschrieben wird. der die Aktion angestoßen hat. einen möglichst modularen und gut erweiterbaren Entwurf zu erstellen. die Businessschicht und die Integrationsschicht. eingegangen. welches die Arbeitsweise einer Service Activator Komponente beschreibt. eine Bestätigung gesandt. Diese Komponente implementiert eine onMessage() Methode. Die Einteilung erfolgt in die Präsentationsschicht. Die ServiceActivator Komponente ist die Hauptklasse dieses Patterns und implementiert das javax. .

Nach einem ersten. In den folgenden Kapiteln werden zuerst die an das Unternehmen gestellten Fragen und anschließend die daraus gewonnen Teilergebnisse der Problemanalyse. 4.1 Systemabgrenzung Zur Systemabgrenzung. ausführlichen Gespräch mit der Geschäftsleitung des Call-Centers wurde ein Fragebogen (siehe Anhang A) entwickelt. Kenntnislücken zu schließen und Unklarheiten zu beseitigen. Diese Skizze wurde in der Interviewphase der Geschäftsleitung und den Supervisoren mit der Bitte um Ergänzungen und Änderungen vorgelegt. wurde aufgrund des Kenntnisstands der ersten Gespräche mit der Geschäftsleitung eine Skizze des zu automatisierenden Geschäftsprozesses angefertigt. welche anschließend gemeinsam mit der Geschäftsleitung des Call Centers überarbeitet und auf seine Korrektheit überprüft wurde. die in die Analyse mit einbezogen werden sollen und die relevanten Umweltbedingungen feststellen soll.1): . der einerseits den bisherigen Kenntnisstand des Authors über die Problemanalyse zusammenfasst und andererseits das Ziel hatte. welche jene Teile identifizieren soll.Problemanalyse 44 Kapitel 4 Problemanalyse Als Analysetechnik für die Erhebung des Istzustands wurde vom Autor die Fragebogentechnik in Kombination mit Einzel.und Gruppeninterviews gewählt. Die ursprüngliche Skizze sah folgendermaßen aus (Abbildung 4. Die Ergebnisse des Fragebogens wurden in einer Istanalyse zusammengefasst.

da die UML für die Besprechungen mit der Geschäftsführung kein geeignetes Mittel war.1 Entwurf des zu automatisierenden Geschäftsprozesses Für die Analyse des Geschäftsprozesses gemeinsam mit der Geschäftsführung wurde eine einfache grafische Dartstellungsform gewählt.Problemanalyse 45 Akquisition Annahme Spezifikation erstellen ReDesign Auftragssteuerung laufende Abwicklung (Interviews) Statistische Auswertung Abbildung 4. Legende: Arbeitsschritt Arbeitsschrittübergang Die durch die Fragestellungen erarbeitete erweiterte Darstellung des Geschäftsprozesses sieht wie folgt aus: .

2 Zu automatisierender Geschäftsprozess (UML Aktivitätsdiagramm) Die Geschäftsleitung akquiriert beim Kunden Aufträge und schließt anschließend den Vertrag mit dem Kunden ab.2 Systemerhebung 4. dass das Call Center bestimmte Personen anruft und Befragungen durchführt.Problemanalyse 46 Abbildung 4. Die Verrechnung mit den Kunden und den Call Agents wird von der Buchhaltung übernommen. Nach Abwicklung der Telefonate durch die Call Agents werden die statistischen Auswertungen von der Grafik-Abteilung mit Unterstützung der EDV-Abteilung durchgeführt und an den Kunden Weitergeleitet. Der Supervisor entwickelt dann die Auftragsspezifikation.2. 4. (Abbildung 4. Outbound hingegen bedeutet.1 Strukturanalyse Die folgenden Abschnitte sollen einen Überblick über das organisatorische Gefüge des Unternehmens. Der Call Agent führt unter Aufsicht des Supervisors die Telefonate durch. Das zu Entwickelnde Softwaresystem soll ausschließlich im Inboundbereich eingesetzt werden. geben.2) Von Bedeutung für die Systemabgrenzung ist des weitern die Gliederung des Call Centers in die Bereiche Inbound und Outbound [Iuk00]. für das eine Softwarelösung angestrebt wird. Inbound steht dabei für die Entgegennahme von eingehenden Anrufen. . Gemeinsam mit Mitarbeitern der EDV-Abteilung steuert der Supervisor den Auftrag.

2.Problemanalyse 47 4.und Mediaforschung das Call Center Beide Bereiche sind eng miteinander verschachtelt.. Dies zeigt sich in den räumlichen. dass dieses System für den Marktforschungsbereich konzipiert wurde und deshalb den Anforderungen eines Call Centers nicht gerecht wird. Großes Augenmerk wird dabei auf Qualität gelegt. Der Grund dafür liegt wohl darin. Ziel ist es. Meinungs. Dieses Ziel wird mit dem derzeitigem System (IT) nur unter Einsatz von hohem persönlichem Engagement und erheblichem Mehraufwand an Arbeitszeit und Engagement der einzelnen Personen erreicht. .. technischen und personellen Verflechtungen. . jeden Kundenwunsch zu realisieren.2. Weiters ist das Call Center oft Auftragnehmers der Marktforschungsbereichs. jedoch soll dies in absehbarer Zeit realisiert werden. 4.2 Dienstleistungen des Call Centers Zur Erhebung der Dienstleistungen des Call Centers wurden dem Unternehmen folgende Fragen gestellt: • • Welche Dienstleistungen werden angeboten? Wo liegen die Schwerpunkte (Inbound oder Outbound)? Die Dienstleistungen des Call Centers lassen sich wie folgt darstellen: Das Dienstleistungsangebot gliedert sich in die Bereiche • • • • • Inbound–Telefonie (Hotlineservice) Outbound–Telefonie (Kundendialog) Datenbank (Wartung der Adressdatenbank.1.) Werbeaktivität Organisation Das umfassende Leistungsangebot und die individuelle Anpassung jedes Auftrags an den Kunden erfordern ein hohes Maß an Flexibilität der einzelnen Mitarbeiter und Abteilungen.1 Unternehmensstruktur Das Unternehmen gliedert sich in die zwei Bereiche: • • die Markt-. Es ist derzeit noch keine klare Trennlinie der beiden Unternehmensbereiche erkennbar.1. Direkt-Mailing.

dass Kernabteilungen wie Geschäftsleitung.Problemanalyse 48 Wesentliche organisatorische Problembereiche sind: • • • mehrfache Erfassung der Daten zusätzlicher Aufwand in der Auftragsabwicklung enge Zusammenarbeit der einzelnen Abteilungen 4. Dies bedeutet. da ein Filialbau geplant ist.3 Filialen–Standortverteilung Folgende Fragen wurden zur Erhebung der Standortverteilung an das Unternehmen gestellt: • • • Wo liegen die Standort? Wo ist die Zentrale? Wo werden die meisten Interviewer beschäftigt? Die Antworten auf diese Fragen sahen wie folgt aus: Die Zentrale des Call Centers befindet sich in Linz. da diese Verteilung einem “Headquater–System“ mit Sitz in Linz gleicht und die Filialen untereinander vernetzt werden müssen.2. Buchhaltung hier ihren Sitz haben. Weiters gibt es derzeit eine Filiale im Mühlviertel.Ausbau zu min. Das bedeutet. Derzeitige Anzahl der Telefonarbeitsplätze: • • Linz: 38 Mühlviertel: 13 (derzeit nur Outbound . das eine weite örtliche Verstreuung des Call Centers absehbar ist.1. 20) Dies stellt eine wesentliche Anforderung an das neue System. Allerdings wird sich diese Struktur in nächster Zukunft ändern. .

Deshalb ist anzunehmen. Die hohe Zahl an Teilzeitbeschäftigten bedingt ein ständiges “Kommen und Gehen“ von Angestellten.3 Filialstruktur mit Zentrale 4.4 Mitarbeiter Bezüglich der Mitarbeiter wurde an das Unternehmen nur die Frage über die Mitarbeiteranzahl gestellt.1. Der derzeitiger Mitarbeiterstand lässt sich folgendermaßen aufzählen: Mitarbeiter in einem fixen Angestelltenverhältnis: • • • 38 Mitarbeiter Marktforschung 5 Mitarbeiter Call Center 5 Mitarbeiter sowohl in der Marktforschung als auch im Call–Center Mitarbeiter in einem Teilzeit. dass die EDV–Kenntnisse der einzelnen Mitarbeiter in ihrer Qualität weit gestreut sind.Problemanalyse 49 Buchhaltung CTI-Clients EDV Data housing Zentrale Managment und Geschäftsleitung CTI-Clients Filiale A CTI-Clients Filiale C CTI-Clients Filiale B Abbildung 4.und Werktvertragsverhältinis: • • 360 externe Mitarbeiter Marktforschung 238 Mitarbeiter im Call Center Die Arbeitsrotation ist in einem 4-Schichten Betrieb eingeteilt. dass eine kurze Einschulungszeit ein wesentlicher Faktor ist.2. . Dies hat zur Folge.

Als wichtige Aufgaben (Operationen) in Zusammenhang mit dem zu entwickelnden Softwaresystem konnten die Erstellung und Auswertung von Protokollen identifiziert werden.. wie sie im Unternehmen intern verwendet werden. welches folgendes Aussehen hat: Geschäftsleitung Grafikabteilung EDV-Abteilung Buchhaltung Supervisor 1 Supervisor 2 Supervisor n Call Agent 1 Call Agent 2 Call Agent n Call Agent 1 Call Agent 2 Call Agent n .) Wer entwirft diese Spezifikation? Was beinhaltet diese Spezifikation? (Erhebung der Kundendaten? Benötigte Protokolle? Benötigte Auswertungen?) Welche Informationsquellen werden nach der Erstellung der Auftragsspezifikation dem Call Agent zur Verfügung gestellt? . musste mit folgenden Fragen die Aufbauorganisation erfragt werden: • • In welche Abteilungen gliedert sich das Call Center? Sind die Abteilungen hierarchisch oder flach gegliedert? Gemeinsam mit der Geschäftsleitung wurde ein Organigramm skizziert.2.1 Erstellung von Auftragsspezifikationen Folgende Fragen wurden an das Unternehmen gestellt. schriftlich.2.5 Organigramm des Call Centers Da leider kein schriftliches Organigramm des Call Centers existierte. etc.1.2. Die Aufgabenanalyse lässt sich durch die in der Systemabgrenzung dargestellten Grafik (Abbildung 4.Problemanalyse 50 4. um detaillierte Informationen zur Erstellung der Auftragsspezifikation zu erhalten: • • • • Wie wird die Spezifikation entworfen? (mündlich.2.. wurden bei der Darstellung der Aufgaben (Operationen) die gleichen Bezeichnungen verwendet.2) zusammenfassen. Abbildung 4. 4.2 Aufgabenanalyse Um die Lesbarkeit der Ist-Analyse für den Auftraggeber zu erhöhen.4 Organigramm 4.

4.2 Protokolle Da aus den ersten Gesprächen schon hervorging. etc. dass in der Spezifikation mit dem Auftraggeber die Zustellung spezieller Datenformate vereinbart werden? Aufgrund der erhaltenen Antworten kann folgender Ablauf der Erstellung von Auftragsspezifikationen dargelegt werden: 1. Das Protokoll selbst dient schon als Spezifizierungsmittel da hier alle Standarddaten bereits vorgegeben sind. Die Form der Auswertungen und Datenübermittlung wird nach den Kundenwünschen festgelegt (Fax. e-mail. wurden bei den Interviews entsprechend viele Fragen gestellt. etc. auf CD-ROM. Antworten? Welche Daten werden immer aufgenommen? (Uhrzeit. 2. Die Spezifikation wird in einem Kundengespräch handschriftlich entworfen. dass Protokolle und ihre weitere Verarbeitung von zentraler Bedeutung für die Entwicklung des Softwareprodukts sind. Im Falle der Notwendigkeit eines ReDesigns entwickelt der Supervisor (2. bzw. Kundendaten. welche der Call-Agent über das Unternehmen zur Beantwortung der möglichen Fragen benötigt.2. Kompetenz). werden vom Kunden in Form von Internetlinks. etc. welche das Protokoll betreffen: • • • • • • Wie ist der Aufbau eines Protokolls? Welche Fragestellungen gibt es. das die Notwendigkeit einer geeigneten Schnittstelle zu gängigen Formaten bedeutet. durch Broschüren. durch wen? Welchen Weg geht das Protokoll im Unternehmen? . Dauer. Kompetenz) die anstehenden Änderungen. Email.) Ist es möglich. Kataloge und sonstige Print Infos zur Verfügung gestellt 3.2. Dabei werden auch spezielle Datenformate angeboten. Die Informationen. Diese Aufgabe obliegt in erster Linie der Geschäftsleitung (1.). Post.) Wo wird das Protokoll abgelegt? Erfolgt eine Zusendung des Protokolls an den Auftraggeber? Wenn ja. Weiters sollten die Informationsquellen so weit als möglich in das System integriert sein.Problemanalyse 51 • • Welche Form der Ergebniszustellung kann in der Auftragsspezifikation vereinbart werden? (per Fax.

B. etc. Protokolle gliedern sich in • Standardteil Informationen die immer erfasst werden müssen (z. Sie sind einer der Kernpunkte der laufenden Geschäftsabwicklung.Problemanalyse 52 • Wie häufig ändern sich Protokolle? Die Antworten ließen sich gut grafisch abbilden und können wie folgt zusammengefasst werden: Protokolle bilden den Gesprächsverlauf eines Anrufs auf Papier ab. Bearbeiter. etc.) Keine „Just in Time“–Zusendung der Protokolle an den Kunden (Berücksichtigung von “Nullmeldungen“ an den Kunden) Keine „Just in Time“–Erfassung der Anrufe .: Uhrzeit. Tag.) kundenspezifischen Teil Daten die anhand der Spezifikation festgelegt wurden • Der Weg eines Protokolls: handschriftliches Ausfüllen des Gesprächsprotokolls Zusendung an den Kunden Erfassung der Protokolle mit IT und Excel Archivierung in Ordnern Call-Agent /Interviewer Supervisor Abbildung 4. Verrechnungsart. Datum.5 Weg eines Protokolls Legende: Arbeitsschritt Arbeitsschrittübergang führt durch Folgende Nachteile sahen die Befragten an diesem Weg des Protokolls: • • • • Das Protokoll muss 4-stufig bearbeitet werden Die Archivierung von Protokollen in Ordnern ist uneffizient (Papierstau. Suchen eines Protokolls.

Auftragseffizienz bzw. die ausschließlich intern verwendet werden? Wie sehen Kundenauswertungen typischerweise aus? Sind die Auswertungen standardisierbar? Was geschieht bei der graphischen Aufbereitung der Protokolle? Folgende Informationen bezüglich der Erstellung von Auswertungen konnten in Erfahrung gebracht werden: Auswertungen sind Statistiken für den Kunden. Das zeitliche Intervall ist zumeist wöchentlich und monatlich.2. die ihm einen Überblick über sein Auftragsvolumen.2. Auftragsstatus geben sollen. 4. da sich im Gesprächsverlaufs ein völlig anderes Gesprächsbild ergeben kann.3 Erstellen von Auswertungen Folgende Fragen wurden zum Bereich Auswertungen gestellt: • • • • • Welche Kategorien von Auswertungen gibt es? Gibt es auch Auswertungen.Problemanalyse 53 Dieser Teilprozess sollte nach Möglichkeit in einem Zug erledigt werden. Da das Generieren der Auswertungen abhängig von der Verarbeitung der Protokolle ist. . dass nicht alle Daten direkt am Bildschirm erfasst werden können.2. Über diese Erfassung werden dann Statistiken generiert. wobei zu berücksichtigen ist. Es ist zu berücksichtigen dass Auswertungen bis zu einem gewissen Grad standardisierbar sind. Die eingegangenen Anrufe werden zunächst tabellarisch in Excel erfasst. die Basis für die graphische Aufbereitung sind.2. Es ist daher die Machbarkeit einer rein elektronischen Gesprächserfassung zu prüfen. können diese wiederum nicht „Just in Time“ dem Kunden übermittelt werden. 4. wurden in der Interviewphase auch keine detaillierteren Fragen zu diesem Thema gestellt.4 Verrechnungen Da die Automatisierung der Verrechnungen in der ersten Ausbaustufe der Softwarelösung nicht vorgesehen wurde. Durch diese Methodik können speziell auf den Kunden zugeschnittene Auswertungen generiert werden.

wurden diese beiden Punkte in einem Kapitel zusammengefasst. Die Abrechnung wird zuerst in Excel erfasst und anschließend in ein Spezialprogramm namens “Perfect“ eingegeben. Die Ablaufanalyse lässt sich durch die in der Systemabgrenzung dargestellte Grafik (Abbildung 4. 4.3.2. den jeweiligen Stellen die Kompetenzen und Aufgaben zuzuordnen.1 Aufgaben der einzelnen Mitarbeiter In der Interviewphase wurde zum Erfragen der Aufgaben der einzelnen Mitarbeiter das zuvor gemeinsam erstellte Organigramm verwendet und die Interviewten wurden gebeten. die für die Abrechnung benötigt werden sind • • • Welcher Call-Agent hat wie viele Calls getätigt Welcher Kunde hatte wie viele Calls Verrechnungsart Kommunikations.und Kommunikationsfluss aufgrund der flachen Hierarchieebenen sehr wenig formalisiert ist und auch die Mitarbeiter nicht zwischen informellen und formellen Datenflüssen unterscheiden.und Ablaufanalyse 4.Problemanalyse 54 Grundsätzlich gibt es zwei Arten von Verrechnungen: Abrechnungen mit dem Kunden und Abrechnungen mit den Call-Agents. Organisation und Management der Call-Agents. Kundenbetreuung und stellt gleichzeitig ein übergeordnetes Management dar. Sie ist zuständig für Kundenakquirierung. Der Supervisor vertritt gegenüber dem Kunden zweite Kompetenz. Sein Zuständigkeitsbereich liegt vor allem in Kundenbetreuung.3 Da in dem untersuchten Unternehmen der Informations. Des weiteren wurden die Interviewten nach dem Datenaustausch zwischen den Stellen detailliert befragt. Wesentliche Daten. Folgendes Bild ergab sich: Die Geschäftsleitung stellt die erste Kompetenz gegenüber dem Kunden dar.2. .2) zusammenfassen.

Dies beinhaltet • • Zuteilung der Call-Agents auf die Kunden Verarbeitung von Feedbacks der Call-Agents . 4. Der Mitarbeiter der Buchhaltung führt Abrechnungen für die Mitarbeiter und Kunden durch. Der Mitarbeiter der EDV-Abteilung administriert das System und betreut das Netzwerk. Alle Abteilungen benötigen Zugriff auf die verschiedensten Daten.und Mitarbeiterebene von Nöten. Darüber hinaus ist seine Aufgabe vom Kunden benötigte Datenformate zur Verfügung zu stellen. Die Abteilungshierarchie ist sehr flach gehalten und es herrscht ein reger Informationsfluss zwischen den Abteilungen.2 Auftragssteuerung Die erste Frage zur Auftragssteuerung betraf eine detaillierte Beschreibung der Aufgabenverteilung. Für das neue System bedeutet dies. Wesentlich sind dabei Datensicherheit und Vermeidung von Inkosistenzen. unter Berücksichtigung des CD (Corporate Design) des Call Centers.Problemanalyse 55 Der Call-Agent erfüllt die laufende Auftragsabwicklung wobei sie dem Supervisor immer wieder Feedback über den Status geben. für den Kunden auf. dass alle Abteilungen Zugriff auf Daten benötigen und diese in jeweilig angepasster Form aufzubereiten sind. Der Mitarbeiter der Graphikabteilung bereitet die Auswertungen. Anschließend wurden an die Interviewten noch folgende Fragen gestellt: • • • • • Welcher Interviewer bearbeitet welche Kunden? Wer entwickelt die Protokolle? Wer übernimmt die IT-Konfiguration zur Erfassung der Protokolle? Wer legt die Form der Auswertungen fest? Wer ist für die Zustellung und Archivierung zuständig? Die Antworten ergaben folgende Darstellung der Auftragssteuerung: Die Steuerung der laufenden Geschäftsabwicklung liegt in der Hand des Supervisors.3. Zu dem ist ein Zugriffssteuerung auf Abteilungs.2.

3. Netzwerk: • • • Leistungsstärke von 10/100MBit Netzwerkserver: 3 Novell .2. Mac Internetanbindung: LiWest (KabelTV) .Softwarestruktur Zur Bestandsaufnahme der vorhandenen Hard. da sich das Anforderungsprofil des Auftrags während der Auftragsabwicklung ändern kann. 1 Mac–Server wobei Novell das Hauptnetzwerk bildet Alle Clients mit fixen IP .und Softwarestruktur wurden folgende Fragen gestellt: • • • • • • • Welches Telefonsystem ist vorhanden? Wie sieht die Netzwerkstruktur aus? (10/100 Mbit? Fixe IPs?) Welche Plattformen sind vorhanden ? Welcher Internetzugang ist vorhanden? Wie ist die Mitarbeiterzufriedenheit mit dem Netzwerk und dem Internetzugang in Bezug auf Geschwindigkeit und Verfügbarkeit? (40 User?!) Welche Browser–Versionen sind in Verwendung? Ist ein leistungsfähiger. 2 WinNt–Server.Server. dem Stand der Zeit entsprechender Server vorhanden? Folgendes Bild der vorhandenen Hard. Win98 für die Call-Agents Weiters WinNT.und Softwarestruktur konnte erhoben werden: Telefonanlage: Kapsch mit TAPI . 4.3 Hard.Problemanalyse 56 • Verarbeitung von Feedbacks der Kunden Die Auftragssteuerung obliegt einem ständigen Controlling und ReDesign.Adressen Plattformen der Clients: • • Win95.Integration (Telephony Application Programming Interface). Für ein neues System bedeutet dies die Einbindung von Controllingverfahren und die Einbindung von durchdachten Administrationsmodulen.

Diese sind das Protokoll.4 Weg eines Protokolls Da die Software-Lösung im Wesentlichen den bisherigen Weg eines Protokolls automatisieren soll. wird die Ablaufanalyse des Wegs eines Protokolls hier nochmals dargestellt.6 Weg eines Protokolls 4.2.Problemanalyse 57 4. Protokoll: • • • • • • Bezeichnung: Inhalt: Zweck: Grad der Formalisierung: Verteiler: Archivierung: Protokoll Ergebnis des Telefoninterviews Interviewaufzeichnung unterschiedlich (je nach Untersuchungsgegenstand) Supervisor. welche im zu automatisierenden Bereich verwendet und produziert werden. Kunde.3. Im Wesentlichen gibt es zwei Dokumente. erhoben. die bei der Aufgabenanalyse bei den Unterpunkten Protokolle und Erstellen von Auswertungen angeführt sind. welches vom Supervisor erstellt und vom Call Agent ausgefüllt wird.4 Dokumentenanalyse Die benötigten Informationen für die Erstellung der Dokumentenanalyse wurden durch jene Fragen. und die Auswertung.2. handschriftliches Ausfüllen des Gesprächsprotokolls Zusendung an den Kunden Erfassung der Protokolle mit IT und Excel Archivierung in Ordnern Call-Agent /Interviewer Supervisor Abbildung 4. Grafikabteilung Ordner in der Grafikabteilung Auswertung: • • Bezeichnung: Inhalt: Auswertung Bericht über die Ergebnisse der Telefon- . welche von der Grafikabteilung generiert wird.

Problemanalyse 58 • • • • Zweck: Grad der Formalisierung: Verteiler: Archivierung: Datenanalyse interviews Kundeninformation stark Supervisor. Fax Häufigkeit der Verarbeitung: ca. 5 mal: Erfassen.2. Auswerten. An den Wochenenden ging die Anzahl der zu erstellenden Protokolle auf ein zehntel zurück.12. anschließend kaum verändert.2000 bis 17-12. Aus diesem Grund musste vor der Erstellung der Datenanalyse nochmals um detailliertere Informationen nachgefragt werden. Protokolle: • Datenvolumen: Im Beobachtungszeitraum (4. wobei am Wochenbeginn eine deutlich höhere Anzahl von zu erstellenden Protokollen zu verzeichnen war. Da die Softwarelösung primär das handschriftliche Erfassen der Protokolle und die anschließende Auswertung der Protokolle ersetzen soll. Geschäftsleitung Ordner in der Grafikabteilung 4. Wertebereich der Daten: Text Verwendete Datenträger: Papier. andererseits wurde ihnen seitens des Interviewenden zu wenig Beachtung geschenkt. Bei dieser zweiten Interviewrunde wurden die vorhandenen Daten in die untenstehende Aufzählung eingetragen und die Interviewpartner wurden aufgefordert. Kunde. Versenden. führt der Weg zur Abschätzung des Umfangs und der Art der zu verarbeitenden Daten über eine Abschätzung der Anzahl zu verarbeitenden Protokolle.5 Beim ersten Interviewdurchgang wurden jene Fragen. Archivieren.2000) wurden durchschnittlich 400 Protokolle pro Tag erstellt. welche eine umfassende Datenanalyse ermöglichen sollten einerseits nicht ausreichend beantwortet. das bereits ausgefüllte Protokoll wird gar nicht mehr verändert • • • • . Buchhaltung Häufigkeit der Veränderungen: der Aufbau wird für jeden Auftrag neu erstellt. da diese auftragsabhängig ist und ein Protokoll je nach Auftrag zwischen 5 und 15 Fragen (1 bis 4 Seiten) enthalten kann. die fehlenden Daten zu ergänzen. Die genaue Länge eines Protokolls kann nicht definiert werden.

Zeitaufwand zum Suchen eines Protokolls. Erfassung der Protokolle durch die EDV und Archivierung in Ordnern) siehe Abbildung 4. Abhängigkeiten zwischen Daten: Abhängig von Protokollen.) Keine “Just in Time“–Zusendung der Protokolle an den Kunden (Protokolle werden gesammelt und nur zu einem definierten Zeitpunkt dem Kunden zugestellt) Keine “Just in Time“–Erfassung der Anrufe (Die Protokolle werden handschriftlich ausgefüllt und anschließend in die jeweiligen EDV–Programme eingegeben werden) • • • . Durchschnittlich sind 20 Auftraggeber pro Monat zu verzeichnen. Wertebereich der Daten: Text und Grafik Verwendete Datenträger: Festplatte und Papier Häufigkeit der Verarbeitung: wöchentlich oder monatlich Häufigkeit der Veränderungen: die Rohversion der Auswertung wird mehrmals (2 bis 3 Mal) überarbeitet.2. Art und Erfordernisse der Datensicherung: Backup Wachstum des Datenvolumens: In Zukunft ist eine Vergrößerung des Call Centers bis zum Faktor 5 geplant.6 Aus den Ergebnissen der vorangegangen Analyseschritte können im wesentlichen folgende Schwachstellen identifiziert werden: • Ein Protokoll muss 4-stufig bearbeitet werden (handschriftliches Ausfüllen vom Call Agent. Abhängigkeiten zwischen Daten: keine Auswertungen: • Datenvolumen: Auftragsabhängig wird wöchentlich oder monatlich für jeden Auftrag eine Auswertung erstellt. etc. Schwachstellenanalyse • • • • • • • 4. Zusendung an den Kunden. Die Länge der Auswertungen ist auftragsabhängig und schwankt zwischen 4 und 10 Seiten.Problemanalyse 59 • • • Art und Erfordernisse der Datensicherung: keine EDV-mäßige Datensicherung Wachstum des Datenvolumens: In Zukunft ist eine Vergrößerung des Call Centers bis zum Faktor 5 geplant.5 Die Archivierung von Protokollen in Ordnern ist uneffizient (Platzbedarf.

Problemanalyse

60

Stärken des vorhandenen Systems sind eine flexible Auftragsverarbeitung, wobei auf individuelle Kundenwünsche eingegangen werden kann.

4.3 Systembeschreibung
Zur Systembeschreibung, welche die bei der Systemabgrenzung und bei der Systemerhebung ermittelten Ergebnisse ordnen und strukturieren soll, wurde aufgrund des Kenntnisstands der ersten Gespräche mit der Geschäftsleitung eine Skizze des zu automatisierenden Datenflusses angefertigt. Diese Skizze wurde in der Interviewphase der Geschäftsleitung, zwei Supervisoren und dem Leiter der EDV-Abteilung vorgelegt und diese wurde ersucht Ergänzungen und Änderungen vorzunehmen. Die ursprüngliche Skizze sah folgendermaßen aus: Interview

IT

SPSS
Protokolle spezielle Daten Bericht Bericht Protokolle

Graphische Aufbereitung

Auftraggeber

Ablage und Archiv

Abbildung 4.7 Entwurf des Datenflussdiagramms

Der Versuch die Datenflüsse in einem Diagramm darzustellen, erwies sich als nicht trivial. Es bedurfte sehr genauem Nachfragen und einiger Diskussionen bis das nachfolgende Datenflussdiagramm (Abbildung 4.8) erstellt werden konnte

Problemanalyse

61

Abbildung 4.8 Datenflussdiagramm

Jeder eingehende Anruf wird vom Call Agent angenommen und es werden von ihm die wesentlichen Daten in einem Protokoll festgehalten. Dieses Protokoll wird anschließend an den Kunden weitergeleitet und unter Kontrolle des Supervisors elektronisch erfasst. Das Protokoll wird außerdem archiviert. Das elektronisch erfasste Protokoll wird von der Grafik und EDV-Abteilung mit SPSS und Freehand zu einer Auswertung weiterverarbeitet. Teile des elektronisch erfassten Protokolls werden von der Buchhaltung zur Verrechnung mit den Kunden und den Call-Agents unter zu Hilfenahme der Programme Excel und Perfekt weiterverarbeitet. Wenn der Kunde ein spezielles Datenformat wünscht, wird das elektronisch erfasste Protokoll außerdem noch von der EDV-Abteilung mit Hilfe von MS-Access, dBase und Excel in das gewünschte Datenformat transferiert. Die durch die Weiterbearbeitung in der Grafik-, EDV- und Buchhandlungsabteilung entstandenen Auswertungen, Verrechnungen und Dateien werden einerseits dem Kunden zugestellt und andererseits in Ordnern archiviert. Der Call Agent erhält ebenfalls seine Abrechnung von der Buchhaltungsabteilung zugestellt. Die Geschäftsleitung hat jederzeit Einsicht in die archivierten Auswertungen, Verrechungen und Dateien.

Systemspezifikation

62

Kapitel 5

Systemspezifikation
Aufgrund der Ergebnisse der Problemanalyse wurde gemeinsam mit der Geschäftsleitung des Call Centers eine Systemspezifikation entwickelt. Die Vorgehensweise für die Entwicklung der Systemspezifikation gestaltete sich so, dass zuerst auf Basis der Problemanalyse ein erster Prototyp der Systemspezifikation entwickelt wurde. Anschließend wurden jene Punkte, welche dem Autor bei diesem ersten Entwurf unklar waren, in einem persönlichen Gespräch mit der Geschäftsführung des Call Centers abgeklärt und anschließend wurde ein zweiter Prototyp der Systemspezifikation erstellt. Dieser zweite Prototyp wurde der Geschäftsleitung zur Begutachtung gegeben, welche ihn anschließend mit der EDV-Abteilung durchdiskutierte. Die so entstandenen Verbesserungsvorschläge wurden in den Prototyp der Systemspezifikation eingearbeitet und das fertige Pflichtenheft wurde der Geschäftsleitung zur Abnahme vorgelegt. Diese prototyping-orientierte Vorgehensweise konnte problemlos abgewickelt werden, lediglich auf die Entwicklung der Abnahmekriterien des Endprodukts musste aufgrund der angespannten Terminsituation der Geschäftsleitung verzichtet werden. Da das Ziel der Diplomarbeit der Entwurf eines nicht verkäuflichen Prototyps ist, kann dieses Ziel auch ohne diese Abnahmekriteriendefinition erreicht werden. Sollte der Prototyp anschließend zu einem kommerziellen Produkt weiterentwickelt werden, ist katalog beizufügen. der Systemspezifikation natürlich ein Abnahmekriterien-

das vorhandene Know-how zur Verfügung zu stellen und geeignete Rahmenbedingungen zu schaffen.1 Ausgangssituation und Zielsetzung Die Ausgangssituation und Systemabgrenzung wurde bereits in der Problemanalyse detailliert beschrieben.und Mitarbeiterebene Zur Verfügungstellung von Controlling–Elementen zur Auftragssteuerung Just in Time-Service für Kunden und Angestellte Echtzeiterfassung der Daten und Echtzeitanalysen • • • • • • • • Zur Erreichung dieser Projektziele ist eine enge Zusammenarbeit zwischen beiden Partnern unabdingbar. eingehende Telefongespräche für den Kunden entgegenzunehmen. Die Aufgabe des Inbound-Bereichs ist es. Dabei werden primär folgende Dienste angeboten: . 5. Im Rahmen der Systemspezifikation wurden keine Änderungen dieser beiden Punkte mehr vorgenommen.Systemspezifikation 63 5. daher wird im folgenden nur mehr die Zielsetzung dargestellt. Wesentliche Punkte. Insbesondere ist es seitens des Call Centers wichtig. Protokollen und Call-Agents Verbesserung des Kundenservices Es soll den Kunden standardmäßig ein umfassendes Leistungspaket zur Verfügung gestellt werden Zur Verfügung stellen von Schnittstellen für die einzelnen Abteilungen Zugriffssteuerung auf Abteilungs. sind: • Optimierung des Prozessablaufs Das System muss auf den im folgenden beschriebenen Prozessablauf optimiert sein Einfachere Verarbeitung der Protokolle Das Erfassen und Verarbeiten der Protokolle muss in einem minimierten Arbeitsaufwand erfüllbar sein Erhöhung des Automatisierungsgrades in den Bereichen Verrechnungswesen Auswertungen für den Kunden interne Statistiken automatische Administration von Kunden.2 Systemeinsatz und Systemumgebung Die zu entwickelnde Softwarelösung ist für den Einsatz im Inbound-Bereich vorgesehen. welche von der Softwarelösung erfüllt werden sollen.

Für jedes Gespräch wird ein Protokoll ausgefüllt und zu definierten Zeitpunkten dem Kunden per Fax oder Email zugesandt.2. Weiters werden über die Gespräche Statistiken erzeugt und z. Gemeinsam mit Mitarbeitern der EDV-Abteilung steuert der Supervisor den Auftrag. In den folgenden Diagrammen wird der allgemeine Geschäftsprozess sowie der ISTund Soll-Datenfluss dargestellt. Die Legende dazu sieht folgenderweise aus: 5. ein mal pro Woche dem Kunden übermittelt. Der Call Agent führt unter Aufsicht des Supervisors die Telefonate durch.2) . welches von den Interviewern als Gesprächsgrundlage zu verwenden ist. (Abbildung 4.Systemspezifikation 64 • • • • • • • Informationshotline für ein Unternehmen Neueinführung von Produkten Auftragsannahme Serviceanfragen Aktionen Gewinnspiele Reklamationen und Beschwerden Es wird dabei nach Auftragserteilung mit dem Kunden ein Gesprächsprotokoll entwickelt. Der Supervisor entwickelt dann die Auftragsspezifikation. Nach Abwicklung der Telefonate durch die Call Agents werden die statistischen Auswertungen von der Grafik-Abteilung mit Unterstützung der EDV-Abteilung durchgeführt und an den Kunden Weitergeleitet.B.1 Übersicht Allgemeiner Geschäftsprozess Die Geschäftsleitung akquiriert beim Kunden Aufträge und schließt anschließend den Vertrag mit dem Kunden ab. Die Verrechnung mit den Kunden und den Call Agents wird von der Buchhaltung übernommen.

1). Standardauswertungen können vom System automatisiert vorgenommen werden und direkt an den Kunden „Just in Time" übermittelt werden. Der Schritt der handschriftlichen Erfassung durch Protokoll und die anschließende Eingabe des handschriftlichen Protokolls in die IT durch den Call Agent würde dadurch weg fallen. In jeden Fall wird das elektronische Protokoll automatisch archiviert und es erfolgt eine automatisierte Weiterleitung an den Kunden. Aufgrund der schwierigen Standardisierbarkeit der eingehenden Anrufe muss in einer Machbarkeitsstudie überprüft werden. Die Verteilung der Verrechnung an den Kunden und den Call Agent soll auch in Zukunft noch persönlich erfolgen. Auch die Verrechnung mit dem Kunden und den Call Agents kann vom System automatisiert übernommen werden.Systemspezifikation 65 5. ob eine direkte elektronisch Erfassung möglich ist. so werden diese individuell von der Grafik und EDVAbteilung erstellt und dem Kunden übermittelt (Abbildung 5. Wenn der Kunde spezielle Auswertungen oder Datenformate wünscht. .2.2 Übersicht SOLL–Datenfluss Abbildung 5.1 Soll Datenflussdiagramm Idealer Weise nimmt der Call Agent den eingehenden Anruf gleich elektronisch auf.

Es eignet sich daher die Internettechnologie sehr gut. Gruppen und Rollen verwalten können. Dies stellt einerseits den modularen Aufbau des Systems dar und dient gleichzeitig als Schnittstellenbeschreibung für die interagierenden Benutzergruppen.3. 5.3 Benutzerschnittstellen und funktionale Anforderungen Maßgeblich entscheidend für die funktionellen Anforderungen ist die geplante dezentrale Standortsverteilung und die hohe Zahl an Call Center Mitarbeitern (siehe Kapitel Problemanalyse). dass die Administration zentral ist und die Möglichkeit einer Fernwartung besteht. die TCO (Total Cost of Ownership) zu verringern.1.Systemspezifikation 66 5. . um Teile des Einschulungsproblems und die Vernetzung von Filialen in den Griff zu bekommen. Rollen sollen definiert und Benutzern und Gruppen zugeordnet werden können. Netscape ab Version 4) TCP/IP als Netzwerkprotokoll Angemessen Bandbreite zwischen Zentrale und Filialen abhängig von der Anzahl der Benutzer des Systems Der folgende Anforderungskatalog gliedert sich nach den Benutzergruppen die mit diesem System interagieren werden. Diese Lösung setzt voraus: • • • • Ein eigener Webserver Clients mit modernen Web–Browsern (Internet-Explorer ab Version 4. Eine rein webbasierende Lösung hat zu dem den Vorteil.1 EDV-Administrator Die Gruppe EDV-Administratoren übernimmt verwaltungstechnische Aufgaben für das System. All diese Maßnahmen tragen dazu bei.3. Benutzer sollen bestimmten Gruppen zugeordnet werden könne. 5.1 Verwaltung der Mitarbeiter Der EDV-Administrator muss alle Benutzer.

2.......3.. 5.2 Allgemeine Schnittstelle Über eine Schnittstelle zum System sollen Daten in einem vom Kunden gewünschten Format zur Verfügung gestellt werden können..2. Zusätzlich administriert er noch seine Call-Agents.1 Verwaltung der Kunden Die Verwaltung der Kunden umfasst folgende Tätigkeiten: • • Anlegen eines neuen Kunden Ändern vorhandener Kundendaten 5. Das genaue Format und die Funktionalität sind im Konzeptentwurf festzuhalten....2 Verwaltung der Auftragsspezifikation (Protokollverwaltung) Im Rahmen der Protokollverwaltung tätigt der Supervisor folgende Aktionen: .....Text Importfunktion MSAccess / MSExcel Abbildung 5.3........ Abbildung 5.Systemspezifikation 67 Mitarbeiter Mayr Ulrike Huber Irene Heinz Ludwig ..3 Allgemeiner Schnittstellenentwurf 5..... Benutzerrecht Management Account Supervisor Paßwort f098sfiu vc734fkj kjq3ujcw .....2 Supervisor Der Supervisor verwaltet seine Kunden (Kundendaten) und dessen Aufträge..2 Benutzergruppenverwaltung 5.. Der folgende Prozessablauf ist nur ein allgemeiner Schnittstellenentwurf...3. Sperren Buchhaltung mayrulri huberire heinzlud ......1..... Dazu muss er die Auftragsspezifikation in das System übertragen. EDV Graphik Call-Agent .... Exportfunktion System ASCII .3..

Festlegen des Datentypus (ja/nein.. 5...Festlegen der Datenfelder ..) .3 Call–Agent Die Call–Agents erledigen die laufende Auftragsabwicklung. Diese beinhaltet im wesentlichen die Erfassung der Gespräche in die vom Supervisor vorgefertigten elektronischen Protokolle...3.3.... Abbildung 5...Festlegen des Begrüßungstextes für den Call Agent .. etc....Echtzeiterfassung im System „Just in Time“ . Optionsfeld.1 Erfassen eines Gesprächsprotokolls • • • Abbildung des Gesprächsverlaufs in das elektronische Protokoll „Just in Time“ . text.3.. Auftrag Gösser Gewinnspiel / Gösser Hotline / Röfix Tourismusverband Oberösterreoch / Röfix Sperren Gösser Gewinnspiel / Röfix / Tourismusverband Oberösterreich .....Systemspezifikation 68 • • Anlegen eines neuen Auftrags zu einem Kunden Dies beinhaltet die Erstellung der Eingabemaske für einen Auftrag (Erstellung des elektronischen Protokolls) ...2..Zusendung des Protokolls Echtzeitzusendung des fertig abgeschlossenen Protokolls an den Kunden (via Email oder Fax) Bereitstellung einer “offenen Protokolle“–Liste Ist eine Übersicht über alle Protokolle die noch nicht abgeschlossen werden konnten Bereitstellung eines Protokollarchivs Archiv in dem alle Protokolle zu einem Auftrag aufgelistet sind (Zugriffssteuerung auf Mitarbeiterebene Anfordern von Informationsquellen (Internetlinks) aus dem System heraus • • • .4 Call–Agent / Auftrag Zuteilung 5. Call-Agent Mayr Josef Huber Franz Heinz Ludwig .3 Verwaltung der Call-Agents Dies beinhaltet die Zuteilung einzelner Call–Agents zu bestimmten Aufträgen.3.Einbinden von Informationsquellen Ändern der Eingabemaske 5..

3.00 15:53 Protokoll ProtokollNR FragebogenNr Tourismusverband . W as kann ich für Sie tun ? Anliegen des Anrufers Tourismusverband Hotline Mühlviertel Sprache Broschüren / Kataloge Salzkammergut Broschüre Wegbeschreibung Allgemeine Info deutsch englisch französisch Hauptkatalog Sommer Hauptkatalog Winter Kultur Röfix Hotline .. Die graphische Aufbereitung der Auswertungen .00/12:00 16.2 Standardisierte Auswertungen Voraussetzung dafür ist.00/10:42 16. Dies erfolgt durch Zugriff auf einen geschützten Bereich am Web-Server des Call-Centers (Protokollarchiv).4 Kunde Jeder Kunde soll die Möglichkeit haben.00/11:45 Sonderwünsche Röfix / Hotline 17..05..05. 5. 5.3. dass sich das Call Center mit dem Kunden auf ein einheitliches Auswertungsschemata einigt..00/14:56 Adresse Firma Herr/Frau Land Plz Protokoll-Archiv Auftragsauswahl Ort Straße TelNr EMail 15.4. seinem Auftrag zugeordneten Protokolle einsehen.3.IN01.00/12:42 Abschließen in OP-Liste Löschen DM DM DM automatisiertes Fax / EMail System Kunde Abbildung 5.05. Offene Protokolle Gösser / Hotline 17.05.5 Prototyp der Benutzerschnittstelle für den Call Agent 5. Er kann alle.9810 1234567 info 50 % nicht verrechnet Begrüßungstext Tourismusverband Mühlviertel guten Tag.05.00/10:33 17.Systemspezifikation 69 Neues Protokoll Gösser Hotline Gewinnspiel Call-Agent Datum Uhrzeit Heinz Ludwig 17.1 Protokollarchiv Der Kunde muss via Internet mittels Benutzername und Passwort Zugriff auf seine Auftragsdaten haben. sich “Just in Time“ zu informieren.05. italienisch .4.Mühlviertel P.05.

05. Statistiken Auftragsauswahl Monatsbericht Wochenbericht Tagesbericht Kontaktzeiten .05. Die Kontaktzeiten für die aktuelle Woche 20.05..00/12:00 16... Samstag Sonntag 0 10 20 30 40 50 Abbildung 5.00/11:23 17.00 . Folgende Statistiken sollen vom System zur Verfügung gestellt werden.. .und Zählfunktionen über die Call-Agents Auftragsarchiv (monatliche Auswertungen) 5..06.00/11:33 .06.4 Nichtfunktionale Anforderungen Im Folgenden werden die nichtfunktionalen Anforderungen gemäß [ROB99] dargestellt.6 Prototyp der Kundenschnittstelle 5. Summen.. Zu diesem Zweck führt es Statistiken über Mitarbeiter und Aufträge.05..00 Montag Dienstag Mittwoch Donnerstag Protokollarchiv Auftragsauswahl Freitag 15.5 Management/Geschäftsleitung Das Management ist zuständig für das Controlling laufender Aufträge und die Kundenbetreuung.Systemspezifikation 70 erfolgt automatisiert und der Kunde kann übers Internet darauf "Just in Time" zugreifen..3....00/10:42 16.. • • • Auflistung der Gespräche je Call-Agent Durchschnitts-.27.

4 Offenheit und Skalierbarkeit Das System solle eine Unabhängigkeit von der Datenbank (kleinere Filialen können mit kleineren Datenbanken ausgestattet werden) ermöglichen. Es gilt hier das Prinzip der Erwartungstreue. die Entgegennahme eines Anrufs) nicht nachteilig beeinflusst werden.4. Als Grenze für dieses Verhalten werden 3 Klicks bzw. über den Zeitraum eines Kalenderjahres betrachtet. 5. dass zeitkritische Situationen (wie z.1 Zuverlässigkeit Das System muss eine einwandfreie Auftragsabwicklung garantieren.4. Deshalb ist auch die Möglichkeit einer Fernwartung gegeben.3 Zeitverhalten Das System muss garantieren. der gesamten Unternehmens- .6 Erweiterbarkeit Da vorerst nur der Inbound–Bereich Gegenstand dieses Projekts ist. 2 Sekunden festgelegt. In jedem Fall muss die Zuverlässigkeit messbar und. 5. muss auf die gesamte Dienstleistungspalette des Call Centers bzw. um bei Ausfall des Hauptservers einen reibungslosen Arbeitsbetrieb garantieren zu können. Die Zuverlässigkeit des Systems muss durch geeignete Maßnahmen planbar sein. 5.2 Handhabung Die einzelnen Benutzerschnittstellen müssen auf intuitive Handlungen optimiert sein.B.4. 98 % betragen (ausgeschlossen sind hier Ausfälle durch höhere Gewalt).5 Wartbarkeit Als webbasierende Lösung beschränkt sich der Wartungsbereich auf eine reine Serveradministration. 5. Weitere wichtige Usability Kriterien werden in [Nie00] beschrieben.4. 5.Systemspezifikation 71 5. Die Evaluierung der intuitiven Handhabung obliegt den Testpersonen. Eine solche Maßnahmen ist z.4.4. Jedoch nur unter der Voraussetzung. dass die betriebsspezifischen Netzwerkeinstellungen (Firewall) auf diese Möglichkeit angepasst werden. B. das System in zweifacher Ausfertigung zu installieren. um bei etwaigen höheren Anforderungen eine leistungsfähigere Datenbank einsetzen zu können.

Dieser Schritt darf nicht abrupt erfolgen. Durch den modularen Aufbau dieses Systems wird erreicht.und Auftragsdaten.7 Unterstützung der Migration Der Begriff Migration bezeichnet den Ablauf der Ablösung eines alten Systems durch ein Neues. Einblick in den Projektstatus nehmen zu können. . 5.Systemspezifikation 72 gruppe Rücksicht genommen werden. 5. der detailliert die Funktionsweise des Systems erklärt. 5.5 Dokumentationsanforderungen Die Systementwickler sind verpflichtet. Nach Abschluss der Systementwicklung ist dem Call Center ein Abschlußbericht zu übermitteln. den Schritt des Entwicklungsprozesses zu dokumentieren um dem Call Center jederzeit die Möglichkeit zu bieten. dass die Adaptierung anderer Geschäftszweige (im speziellen Outbound–Bereich) nicht eine Neuentwicklung fordert.6 Glossar und Index Ein Glossar und ein Index wurden dem zweiten Prototypen der Systemspezifikation vor Übergabe an die Geschäftsleitung beigefügt. Hinzu kommt die Erstellung eines Handbuchs in entsprechender Form und entsprechendem Umfang. Die Datenübernahme aus dem alten System beschränkt sich auf die Erfassung der Kunden.4. Es empfiehlt sich die schrittweise Ablösung des alten Systems (zeitlich begrenzte zweigleisige Datenerfassung).

dass man einen Algorithmus für ihre Lösung formulieren kann. Ausgehend von den Erkenntnissen aus der Analyse der Systemspezifikation und der Eigenschaften von Java 2 Enterprise Edition wird eine Aufgabe in Teilaufgaben zerlegt und dieser Vorgang wiederholt.Entwurf 73 Kapitel 6 Entwurf 6.1 Allgemeines Für den Entwurf des Softwaresystems wählt der Autor die Topdown-Methode [Pom96. bis die Teilaufgaben so einfach geworden sind. soll dieses System . Das Kapitel 6.2 Datenmodell 6. 48].3 (Protokolle) behandelt das spezielle Problem der Protokollverwaltung. 6.2. Es handelt sich dabei also um eine sukzessive Konkretisierung von abstrakt beschriebenen Lösungsideen. Darauf aufbauend werden alle Komponenten identifiziert. um von der Analyse und Systemspezifikation schrittweise zu den Realisierungsdetails zu gelangen. Der Entwurf beginnt mit der Festlegung des Datenmodells. die für die spätere Implementierung erforderlich sind.1 Datenbankauswahl Grundsätzlich können Datenbanken in OODMS (Objekt Orientated Database Management Systems) und RDMS (Relational Database Management System) eingeteilt werden. welches als Basis für den Entwurf der Komponenten dient. Da die meisten Unternehmen noch RDMS einsetzten.

um eine hohe Integrationsmöglichkeit in die Softwarestruktur eines Unternehmens zu gewährleisten. dass von der Datenbank die Abfragesprache SQL99 unterstützt wird. ODBC-Treiber bedeutet.2 Definition der wichtigsten Kriterien Tabelle 6. dass die Datenbank ohne Lizenzkosten einsetzbar sind. Frei bedeutet. JDBC-Treiber bedeutet. SQL99 konform bedeutet.2. dass für diese Datenbank ein JDBC-Treiber zur Verfügung gestellt wird. Diese Datenbanken lassen sich in die Kategorien „Frei“ und „Kommerziell“ einteilen. dass von der Datenbank die Abfragesprache SQL92 unterstützt wird. SQL92 konform bedeutet. Verschiedene Produkte von Datenbankherstellern stehen zur Auswahl. . SQL92 konform.1 zeigt eine Klassifikation von weit verbreiteten DBMSs anhand der Kriterien Frei. dass für diese Datenbank ein ODBC-Treiber zur Verfügung gestellt wird.Entwurf 74 auch auf diese Art von Datenbanken aufbauen. dass für dieses Produkt Lizenzkosten an den Hersteller abzuführen sind 6. JDBC-Treiber und ODBC-Treiber. Kommerziell bedeutet.

java.sun.mysql. (*) teilweise Tabelle 6.html 4 http://www.com/products/jdbc/drivers 3 http://www.. 6. die SQL92-konform sind.org/docs/todo.at. Rollen für dieses System sind: • • Administrator Supervisor 2 http://industry.. N .1 Klassifikation von Datenbanken Das im Rahmen dieser Diplomarbeit entwickelte Softwareprodukt wird mit allen in Tabelle 6. 342f] entworfen..3 Modell Das Datenmodell wird als Entity Relationship Modell [Mar99.postgresql. Als eine der zentralen Tabellen existiert die users-Tabelle. Der Migrationsaufwand wird dabei gering sein. verwendbar sein.Entwurf 75 Kriterium Datenbank mSQL MySQL3 PostgreSQL4 DB2 Informix Cloudscape Ingres Interbase Microsoft SQL Server Oracle Progress Sybase Frei SQL92 konform SQL99 konform JDBC– Treiber2 ODBC– Treiber J J J N N N N N N N N N N J J J J J J J J J J J N N J J J N N N J (*) J (*) N N J J J J J J J J J (beta) J J J J J J J J J J J J J J J J . Nein.1 genannten Datenbanken. Diese Tabelle speichert alle Benutzer des Systems..com/development/todo. wobei über eine Rollenzuordnungstabelle die Rollen für die einzelnen Benutzer festgelegt werden können.html . Ja.2.

zur leichteren Auswertung dieser Daten und Suchfunktionen werden diese Daten aber auch in einzelnen Spalten der Tabelle abgelegt. Protokolle. Diese Tabelle speichert Kontaktinformationen zu einem Benutzer. Beschreibung. Das aufgezeichnete Protokoll wird als XML-Text in die Spalte xml_data gespeichert. Diese Informationen befinden sich auch im XMLText. welche für jedes Projekt einen Eintrag speichert. welches die Beschreibung für einen Protokolleintrag beinhaltet. Abbildung 6. Call Agent und weitere wichtige Protokollinformationen abgelegt. werden in der protocolls-Tabelle gespeichert. Ein Projekt kann dabei mehrere Protokolle besitzen. Uhrzeit. Für die Projektverwaltung gibt es die projects-Tabelle. der zugeordnete Supervisor. ein Protokoll wird genau einem Projekt zugeordnet. Weiters werden für jedes Protokoll Datum.1 zeigt das Datenmodell als UML Diagramm.Entwurf 76 • • • • Call Agent Management Grafik Buchhaltung Weiters hat jeder Benutzer einen Eintrag in der adresses-Tabelle. Detaildaten sind der Projektname. die einem Projekt zugeordnet sind. . der zugeordnete Auftraggeber und ein XML-Template.

Eine andere Variante währe die Beschreibung des Aufbaus eines Protokolls mit einem XML-Schema [XMLSchema01]. ist es schwierig. Eine Beschreibung des Protokolls ist in den nachfolgenden Kapiteln zu finden. . CallAgent.1 ER-Diagramm des Datenmodells 6. Aus diesem Grund sollen die einzelnen Protokolle im XML-Format gespeichert werden. Nur Informationen. alle Informationen auf ein relationales Schema abzubilden. die bei jedem Protokoll immer gleich sind (Datum. Dies ändert aber nichts wesentliches am Konzept dieses Entwurfs. etc.2 zeigt eine vom Autor für das Format eines Protokolls entwickelte DTD (Document Type Definition).) sollen auch in einer Spalte der Protokoll-Tabelle gespeichert werden. Uhrzeit. Abbildung 6.3 Protokolle Die aufgezeichneten Protokolle sollen in der Datenbank abgelegt werden. Da für die verschiedenen Projekte verschieden strukturierte Protokolle aufgezeichnet werden.Entwurf 77 Abbildung 6. welche für die Validierung eines Protokolls verwendet werden kann.

fax? . zip? . company? . calling_date . tel? . hat mindestens eine Frage (question+). charging ) > Generelle Information • • • • • beinhaltet einen Call Agent (agent) beinhaltet ein Datum (calling_date) beinhaltet die Uhrzeit (calling_time) beinhaltet eine Protokollnummer (protokoll_no) beinhaltet Informationen über die Verrechnung (charging) <!ELEMENT contact ( salutation? .Entwurf 78 Abbildung 6. street? .3. town? . name .2 DTD eines Protokolls 6. protokoll_no . web? ) > Kontaktinformation besteht aus • • • • • Anrede (salutation?) Name (name) Firma (company?) Strasse (street?) PLZ (zip?) . contact? ) . <!ELEMENT general ( agent . country? . calling_time . kann Kontaktinformationen beinhalten (contact?). email? .1 Elementbeschreibung der DTD <!ELEMENT protokoll (( general . question+ ) > Jedes Protokoll • • • beinhaltet generelle Information (general).

choice? . . caption ) > Fragen bestehen aus • • • • einer Überschrift bzw. choice* . free_text? ) > Eine Eins aus Mehreren-Antwortauswahl besteht aus • • • verschiedenen Antwortmöglichkeiten (answer_choice+) einer Antwort (choice) und möglicherweise einer zusätzliche Freitext-Antwort (free_text?) <!ELEMENT many_of_many (answer_choice+ . free_text? ) > Eine Mehrere aus Mehreren-Antwortauswahl besteht aus • • • verschiedenen Antwortmöglichkeiten (answer_choice+) mehreren Antworten (choice*) und möglicherweise einer zusätzliche Freitext-Antwort (free_text?) Alle oben vorkommenden Elemente. beinhalten einfachen Text (#PCDATA)* (parsed character data). die nicht genauer Beschrieben wurden. Frage (caption) einer Freitext-Antwort (free_text) oder einer Eins aus Mehreren-Antwortauswahl (one_of_many) oder einer Mehrere aus Mehreren-Antwortauswahl (many_of_many) <!ELEMENT free_text (#PCDATA)* > Eine Freitext-Antwort ist ein einfacher Text <!ELEMENT one_of_many (answer_choice+ .Entwurf 79 • • • • • • Stadt (town?) Land (country?) Telefon (tel?) Fax (fax?) Email (email?) WWW-Adresse (web ?) <!ELEMENT question (( one_of_many | free_text | many_of_many ) .

<protokoll> <general> <agent>huber</agent> <protokoll_no>P01122222<protokoll_no> <calling_date>12.3.at</web> </contact> <question> <caption>Welches Prospektmaterial möchten Sie?</caption> <many_of_many> <answer_choice>Allgemein</answer_choice> <answer_choice>Produktbeschreibung</answer_choice> <answer_choice>Imageprospekt</answer_choice> <answer_choice>Keines</answer_choice> <choice>Allgemein</choice> <choice>Produktbeschreibung</choice> </many_of_many> </question> <question> <caption>Wie alt sind Sie?</caption> <one_of_many> <answer_choice>bis 20 Jahre</answer_choice> <answer_choice>20 bis 40 Jahre</answer_choice> <answer_choice>älter als 40 Jahre</answer_choice> <answer_choice>Keine Angaben</answer_choice> <choice>20 bis 40 Jahre</choice> </one_of_many> </question> </protokoll> .Entwurf 80 6.2001</calling_date> <calling_time>13:23</calling_time> <charging>50%</charging> </general> <contact> <name>Max Moritz</name> <company>AComp</company> <tel>+43 7443 2323</tel> <email>offic@acomp.1 gezeigte Dokument Typ Definition erfüllt.acomp.3.12. dass die im Abschnitt 6.2 Beispiel eines Protokolls Hier soll ein Beispiel eines Protokolls gezeigt werden.at</email> <web>www.

3.html . die sich auf das Layout der Frage beziehen.3. Eine Vorlage wird über einem Editor erstellt. welche mit Hilfe eines XSLT-Prozessors die benötigten Anzeigeinformationen (HTML) erzeugen. Eine Vorlage für ein Protokoll ist ein nicht ausgefülltes Protokoll (XML-Dokument).3 Protokollvorlagen Für jedes Projekt wird eine Vorlage generiert. Der benötigte XSLT-Prozessor wird in eine EJB-Komponente integriert. Diese Komponente wird als eine zustandslose Session-Bean realisiert und verwendet die XML-APIs JAXP1. Einmal als Formular. Dafür werden bei den einzelnen Fragetypen Attribute hinzugefügt. Andererseits als EMail oder Fax zur Einsichtnahme durch den Kunden.sun. Beispielsweise kann man aus XML-Daten und einem dementsprechenden Stylesheet HTML erzeugen. XSLT-Transformation 6.Entwurf 81 6. welches die oben beschriebene DTD erfüllt. Folgende Funktionen sollen von diesem Editor bereitgestellt werden: • • • • • • Neu Frage einfügen Frage löschen Editieren des Fragetextes Einstellung des Typs der Frage (free_text.15 von Sun Microsystems. welcher grundlegende Funktionen für das Hinzufügen von Fragen zur Verfügung stellt. Eine Protokollvorlage wird für die Erstellung eines Protokolls durch den Call Agent benötigt. die in der Projekt-Tabelle als XMLText gespeichert wird.4 Die Darstellung der einzelnen Protokolle hat unterschiedliche Ausprägungen. many_of_many) Hinzufügen von Antwortmöglichkeiten Layout-Eigenschaften einstellen Für diese Funktion wird die DTD in einer späteren Ausbaustuffe erweitert. damit der Call Agent das Protokoll befüllen kann. Diese APIs stellen eine Sammlung 5 Java APIs for XML Processing (JAXP) http://java. one_of_many. das XML-Daten mit Hilfe eines XSL-Stylesheets in ein neues Format überführt.com/xml/jaxp/index. Für diese Funktionalität werden für die verschiedenen Anzeigeformen jeweils verschiedene XSL-Stylesheets erzeugt. Ein XSLT-Prozessor ist ein Programm.

6.4 Benutzerverwaltung Die Benutzerverwaltung ist eine zentrale Komponente des Systems und bietet folgende Funktionen: • • • Neuen Benutzer erfassen Benutzer verwalten Rollenzuordnung Alle Informationen über einen Benutzer werden in die Tabellen users und adresses abgelegt. . Anhand dieser Rollenvergabe bietet das System dem Benutzer jeweils die richtigen Benutzerschnittstellen. Die grundlegende Funktion dieser Komponente ist die Transformierung eines XMLDokuments mit Hilfe eines XSL-Stylesheets zu einem Ausgabedokument.Entwurf 82 von Javaklassen und Interfaces zur Programmierung mit XML zur Verfügung welches in Zukunft auch in die Java 2 Standard Edition (J2SE) integriert werden. E-Mail-Stylesheet Dieses Stylesheet wird für die Transformation des XML-Dokuments zu einer E-Mail verwendet. Anzeige-Stylesheet Dieses Stylesheet wird für die Transformation des XML-Dokuments zu einer DetailAnsicht (HMTL) verwendet. Folgende Stylesheets werden entwickelt: Formular-Stylesheet Dieses Stylesheet wird für die Transformation des XML-Dokuments zu einem HTML-Formular verwendet.2 zeigt die Rollen. welche einem Benutzer zugewiesen werden können. Über die Rollenzuordnungstabelle können dem Benutzer eine oder mehrere Rollen zugewiesen werden. Tabelle 6.

2 Mögliche Rollen eines Benutzers 6.6 Auswertung für Kunden Wie in der Systemdefinition beschrieben (5. das auf relationale Datenbanken aufbaut. Wichtige Anforderungen an dieses Berichtssystem sind: • • • Unterstützung von relationalen Datenbanken Veröffentlichung im Web Flexible Erstellung von Berichten .5 Projektverwaltung Die Projektverwaltung dient dem Supervisor zur Koordination der einzelnen Projekte. Statistiken Erstellen von Auswertungen für den Kunden Einsichtnahme in Informationsmaterial für die Buchhaltung Tabelle 6. Dazu werden folgende Funktionalitäten benötigt: • • • Auftrag anlegen Protokollvorlage erzeugen Call Agent zuordnen Alle Informationen zum Projekt werden in den Tabellen projects und callers_projects abgelegt. realisiert werden.3.4) soll der Kunde jederzeit Zugriff auf seine Protokolle und Auswertungen haben. Call Agents verwalten Protokolle erfassen Einsichtnahme in den Projektverlauf. Projekte verwalten .Entwurf 83 Rolle Administrator Supervisor Call Agent Management Grafik Buchhaltung Beschreibung Benutzer verwalten. 6. Diese Funktionalität des Systems wird mit Hilfe eines Berichtssystems. Administration des Systems Kunden verwalten.

und Businessschicht. Als Bindeglied zwischen diesen Schichten werden spezielle Value Objects verwendet. Die in der Systemspezifikation gestellte Anforderung der Plattformunabhängigkeit ist hier nicht gegeben. 6 http://www. wiegen die funktionalen Vorteile dieses Berichtssystem den Nachteil der Plattformabhängigkeit auf.1 Businessschicht (Business Tier) Die Businessschicht stellt die Implementierung der Geschäftslogik zur Verfügung. 6. welches auf verschiedenste Daten zugreifen kann. 6. Berichte über einen vorhanden Webserver im Internet zu publizieren und Berichte dynamisch zu generieren.7 Identifikation der Komponenten Die benötigten Komponenten orientieren sich an das J2EE-Entwurfsmodell und werden in die Businessschicht (Business-Tier) und die Präsentationsschicht (Presentation-Tier) gegliedert. Tabelle 6. Dies gewährleistet eine Entkopplung zwischen Präsentations. Da aber das öffentlich zugängliche Berichtssystem im Internet von der internen Applikation aus Sicherheitsgründen getrennt wird.com/products/crystalreports/ . Diese Software bildet ein vollständiges Berichtssystem.Entwurf 84 • • XML-Unterstützung Echtzeitberichte Eine für diese Aufgabenstellung geeignete Software ist „Crystal Reports“6 von der Firma Crystal Decisions.7.3 zeigt die von den Komponenten zur Verfügung gestellten Businessmethoden. Die durch die Präsentationsschicht verwendeten Komponenten werden in Session Facades gekapselt. Vorraussetzung für die Verwendung von „Crystal Reports“ ist ein Microsoft Windows Betriebssystem. aber auch zwischen einzelnen EJB-Komponenten dienen. welche zur Kommunikation zwischen diesen Schichten. Außerdem bietet es die Funktionalität.crystaldecisions.

4 Entity Beans. Die genaue Auflistung der persistenten Felddeklarationen wird im Kapitel 6.Entwurf 85 Komponente Usermanagement: SessionFacade Businessmethoden createUser(UserVO user):void updateUser(UserVO user):void deleteUser(String login):void getUser(String login):UserVO getUserList(int limitstart. ihre Schlüsselklassen und Value Objects Hilfskomponenten Hilfskomponenten sind Komponenten.4 zeigt die den Entity Beans zugeordneten Schlüsselklassen und Value Objects. Tabelle 6. Sie stellen allgemeine Dienste. int limit):Enumeration updateProtocol(ProtocolVO protocol):void deleteProtocol(String protocol_nr):void getProtocol(String protocol_nr):ProtocolVO getOpenProtocols():Enumeration ProjectManagement: createProject(ProjectVO project):void SessionFacade ProtocollRecording: createProtocoll(ProtocolVO protocol):void SessionFacade Tabelle 6. Komponente User Project Protocol Schlüsselklasse und Value Object UsersKey UserVO ProjectKey ProjectVO ProtocolKey ProtocolVO Tabelle 6. die von den verschiedenen Schichten benötigt werden.7. die von den oben genannten Session Facades und von der Präsentationsschicht verwendet werden. int limit):Enumeration updateProject(ProjectVO project):void deleteProject(String project_nr):void getProject(String project_nr):ProjectVO getProjectList(int limitstart. zur Verfügung.5 enthält die Komponenten und deren Beschreibung. Tabelle 6. .2 beschrieben. Project und Protocol durchgeführt.3 Sessionfacades und ihre Businessmethoden Entity Beans Der Datenbankzugriff wird durch die Entity Beans User.

Name. AdressVO Adressinformation Project_nr. Als grundlegende Komponente wird ein Front Controller implementiert. Caller. welche Ansicht dem Benutzer als nächstes präsentiert wird und welche Aktionen in der Businessschicht ausgelöst werden.6 Value Objects 6. Project_nr. Diese Kompononente stellt Methoden zur Auffindung von EJBs mit Hilfe des JNDI-APIs zur Verfügung. XML_Template. die vom Client ausgelöst werden können.2 Value Objects Value Objects dienen zur Kommunikation zwischen Komponenten und Schichten. Roles.3 Präsentationsschicht (Presentation Tier) Die Präsentationsschicht verwendet Java Servlets und Java Server Pages zur Bereitstellung von Benutzerschnittstellen. Außerdem werden Value Objects von den Entity Beans für die Zwischenspeicherung ihrer persistenten Datenfelder verwendet. Tabelle 6. Workerkomponenten weiterleitet. Customer Protocoll_nr. Charging Tabelle 6.6 stellt die verwendeten Value Objects dar. das alle möglichen Aktionen. Active. Tabelle 6.Entwurf 86 Komponente XML_Tool Beschreibung Diese Komponente stellt Methoden zur Transformierung von XML-Daten mit Hilfe eines XSL-Stylesheet zur Verfügung. Date. Password. . XML_Data. Dazu muss ein Kommunikationsschema entwickelt werden. Supervisor. Value Object UserVO AdressVO ProjectVO ProtocolVO Elemente Login. Time. beschreibt. Sie fassen mehrere atomare Informationselementen zu einer komplexen Struktur zusammen. Kommunikation mit der Businessschicht und zum Verarbeiten von Anfragen der Web-Clients. Mit Hilfe dieser Aktionen wird entschieden.7. der zentral alle Requests entgegen nimmt und diese an spezielle View –bzw.5 Beschreibung der Hilfskomponenten Service Locator 6. Description.7.

die diese Rolle benutzen darf. Allgemeine Schnittstellenelemente Tabelle 6. Dies sind wichtige Navigationselemente. jedoch an die jeweilige Rolle angepasst. die immer leicht erreicht werden können.Entwurf 87 Für die Präsentationsschicht müssen Benutzerschnittstellen (Views).7. Element Hauptnavigation Navigationselemente Benutzerverwaltung Projektverwaltung Protokollerfassung Controlling Buchhaltung Tabelle 6.1 Benutzerschnittstellen Die Benutzerschnittstellen werden jeweils für die verschiedenen Rollen definiert. die bei jeder Ansicht dargestellt werden.3.7 zeigt jene Elemente.7 Allgemeine Schnittstellenelemente Diese werden in den Benutzerverwaltung Die Benutzerverwaltung benötigt Schnittstellenelemente zur Administration der Benutzer. folgenden Kapiteln beschrieben.8 dargestellt. 6. Workerkomponenten und Kontrollkomponenten identifiziert werden. Diese Schnittstellenelemente werden in Tabelle 6. Je nach Rollenzuordnung des Benutzers werden diesem nur jene Navigationselemente zur Verfügung gestellt. Bestimmte Schnittstellenelemente wie die Hauptnavigation werden jedem Benutzer zur Verfügung gestellt. .

Sperren . Pro Benutzer können folgende Aktionen ausgelöst werde: .9 aufgelistet und beschrieben.8 Schnittstellenelemente der Benutzerverwaltung Projektverwaltung Die Projektverwaltung stellt Schnittstellen zur Administration der Projekte zur Verfügung. .Entwurf 88 Element Menü Beschreibung Ein Menüelement. Passwort .Neuen Benutzer erfassen .Benutzerliste Eine Auflistung aller Benutzer des Systems in Tabellenform.und Kontaktinformationen .Rollenzuordnung Benutzerliste Benutzerformular Ein Formular zum Verändern oder neu Anlegen von Tabelle 6. Diese Schnittstellenelemente werden in Tabelle 6. das folgende Aktionen bietet: . Inhalt: .Login.Adress.Löschen .Editieren Benutzerdaten.

Pro Projekt können folgende Aktionen ausgelöst werde: .Projektname .Eine aus mehreren Antwortmöglichkeiten .Protokollvorlage editieren/anlegen Ein Formular zum Verändern oder neu Anlegen von Projekten.Frage hinzufügen . Inhalt: .Freitextfrage hinzufügen .Supervisorzuordnung .Allgemeine Projektinformationen ändern .Mehrere aus mehreren Antwortmöglichkeiten .CallAgent-Zuordung Der Protokollvorlageneditor bietet folgende Funktionalität: .Löschen .Frage hinzufügen .Begrüßungstext festlegen .Beschreibung .10 zeigt eine Auflistung aller Bereitgestellten Schnittstellenelemente der Protokollerfassung.Sperren . das folgende Aktionen bietet: Neues Projekt erfassen Projektliste Eine Auflistung aller Projekte in Tabellenform. . Tabelle 6.Frage löschen Tabelle 6.Entwurf 89 Element Menü Beschreibung Ein Menüelement.9 Schnittstellenelemente der Projektverwaltung Projektliste Projektformular Protokollvorlageneditor Protokollerfassung Die Schnittstellen der Protokollerfassung unterstützen den Call Agent bei der laufenden Entgegennahme der Anrufe.

Allgemeiner Freitext. .10 Schnittstellenelemente der Protokollerfassung . Aktionen nach dem Ausfüllen des Formular: .Abbrechen noch nicht abgeschlossen wurden. Dient zur späteren Einsichtnahme durch den Call Agent. Hier werden alle Informationen über ein Gespräch aufgenommen: .Kontaktinformationen des Gesprächspartners .Entwurf 90 Element Projektauswahl Beschreibung Bietet eine Auflistung aller dem Call Agent zugeordneten Projekte. die vom Call Agent ausgefüllt wurden. Hier kann das Protokoll aber nicht mehr verändert werden. falls das Anliegen des Gesprächspartners nicht in das vorgefertigte Schema passt Offene Protokolle Eine Auflistung aller Projekte die vom Call Agent Protokollarchiv Protokollformular Dieses Formular ist ein zentrales Element für den Tabelle 6.Abschliessen .In OP-Liste aufnehmen (Offene Protokolle) . das hier noch nachbearbeitet und abgeschlossen werden kann. Durch Auswahl eines Protokolls gelangt der Call Agent zum Formular.Abbrechen Eine Auflistung aller Protokolle zu einem gewählten Projekt.Aufnahme der Anliegen des Gesprächspartners über vordefinierte Frage-Antwortmöglichkeiten . Durch Auswahl eines Projekts wird dem Call Agent ein leeres Protokollformular präsentiert.Abschliessen .In OP-Liste aufnehmen . Call Agent.

Anbieter EJB-Container – Anbieter . 7.Implementierung 91 Kapitel 7 Implementierung 7.2 Rollenverteilung bei der Entwicklung von J2EE Anwendungen Die EJB Architektur ermöglicht eine gezielte Verteilung der Rollen. die bei der Entwicklung von mehrstufigen Client/Server Anwendungen vorkommen. Abschnitt 7.3 Entwicklungswerkzeuge und Applikationsserver beschrieben. Dadurch kann der Entwicklungsprozess vereinfacht werden. auf separate Personengruppen. die zur Zeit am Markt erhältlich sind.2 gibt dabei einen Überblick über die Rollenverteilung bei der Entwicklung von J2EE Anwendungen. welche von Sun in der J2EE Spezifikation [Sha01] beschrieben wird. Weiters werden im Abschnitt 7. da in jeder Gruppe nur bestimmte Fähigkeiten notwendig sind. Folgende Rollen werden definiert: • • • • • EJB-Entwickler EJB-Installierer (EJB Deployer) Anwendungsentwickler (EJB Assembler) EJB-Server .1 Einführung Dieser Abschnitt beschreibt die Implementierungsphase des Prototypen der Anwendung.

2.2.3 Anwendungsentwickler (EJB Assembler) Der Anwendungsentwickler implementiert Clientanwendungen unter Verwendung vorhandener Beans. werden nur Systeme (Application Server) angeboten. Er kann sich dabei auf die Repräsentation der Daten und die Benutzerinteraktion konzentrieren. Er benötigt wenig Kenntnisse bezüglich Java. Da die Schnittstelle zwischen Container und Server immer noch nicht klar spezifiziert ist und da beide Systeme eng zusammenhängen. in der die Bean ausgeführt werden soll. 7. für die er Komponenten entwickelt [WI0302]. etc. die beide Aufgaben. in einem System vereinen [WI0302]. Der EJB – Entwickler benötigt Kenntnisse über Enterprise Java Beans und die Anwendungsdomäne.2. EJB oder der Anwendungsdomäne [WI0302]..Implementierung 92 7. indem er die zu einem EJB gehörenden Interfaces und Klassen erstellt und diese zusammen mit einem Deployment Deskriptor als Komponente zur Verfügung stellt. . die die Ausführung von Beans mit den geforderten Diensten ermöglicht. und entsprechend der Anforderungen bezüglich Sicherheit und Transaktionsverhalten. aus. die er vom EJB Entwickler bekommt.2 EJB-Installierer (EJB Deployer) Der Installierer installiert fertige Beans in einem EJB Server und modifiziert ihre Attribute (im Deployment Descriptor) entsprechend der technischen Umgebung. also dem EJB Server und der dahinterliegenden Infrastruktur. Der Installierer kennt sich mit dem technischen Umfeld.1 EJB-Entwickler Der EJB – Entwickler erstellt Geschäftsobjekte. dass die EJB über einen JNDI-kompatiblen Namensdienst im System gefunden werden kann.4 EJB-Server Anbieter und EJB-Container Anbieter Der EJB – Server Anbieter offeriert eine Umgebung. in der EJB – Container ablaufen können. Er ist besonders dafür zuständig. während der EJB – Container Anbieter Container Software herstellt.2. also Server und Container. 7. da er die grundlegende Geschäftslogik über Enterprise Java Beans zur Verfügung gestellt bekommt [WI0302]. 7.

2 1.995.2 1.1 1.2 1.1 Application Server Comparison Matrix [FLA02] Abbildung 7.1 Enterprise V4.0.000 35.1 Applikationsserver Am Markt befinden sich verschiedenste Produkte.2 1.0.1 1.1 Borland IBM Enterprise Websphere Server V5.2 1. 2.000.1 1.0.1 1.1.2 1.0 1.6 v3.12.1 v3.2 1.2 1. . Hersteller Produkt Bea WebLogic Version Express v7.1 1. Diese sind der BEA WebLogic und IBM Websphere mit jeweils 34% vom Marktvolumen.0 1.3 Werkzeuge und Plattform 7.000 15.2 1.0. welche die größte Marktverbreitung haben oder frei verfügbar sind.2 1.0.1 Enterprise v6.0.995.1 1.0 JSP JMS J2EE Preis in US$ 1.0.5 1. die J2EE bzw.1 IPlanet iPlanet Standard v6.2 1.1 1.5 Oracle 9i Application Standard Server Enterprise 1.0.0 Server v7.0 1.1 zeigt einen Auszug jener Produkte aus dieser Matrix.20.1 zeigt die am weitesten verbreiteten Applikationsserver auf J2EEBasis.1 Advanced V4.000. Tabelle 7.0.1 2.35.0.3.2 1.2 1.2 1.0.2.995.Implementierung 93 7.2 1.2 1.0.39.2 1.2 1.3 1.000.2 Enterprise v6.000 10.1 Enterprise Pro JBoss JBoss v.2 3.Frei Frei Frei 995.1 1.10.0 1.0.19.2 1.2 1.0 EJB 2. Eine sehr guten Überblick über die verfügbaren Produkte und deren Eigenschaften gibt die Application Server Comparison Matrix [FLA02].1 1.1 1.1 1.2 1.0 Lutris Enhydra v 3.000.2 1.2 1.4. Die restlichen Applikationsserver teilen sich 25% vom Marktvolumen [CZ2202].2 1.1 1. Teile von J2EE unterstützen.0 Tabelle 7.1 1. An dritter Stelle liegt der Applikationsserver Sun One mit 7%.2 1.000.

1 Application Server Comparison Matrix behandelt. Enterprise Edition enthalten und kann laut Sun zum Entwickeln von J2EE-Anwendungen verwendet werden. Ein weiterer frei verfügbarer Server stammt von Sun und ist im Java 2 Software Development Kit.Implementierung 94 Andere 25% Bea Weblogic 34% Sun One 7% IBM Websphere 34% Abbildung 7. 7. JBoss verwendet dabei für die Servlet und JSP Funktionen andere frei Erhältliche Produkte wie den Servlet-Container Tomcat7.0 verfügbar unterstützt dieser Server EJB 2.0 und Clustering. 7 http://jakarta. Da die Erstellung von EJBs und die Veröffentlichung dieser Komponenten einen hohen Aufwand durch die Erstellung von Interfaces und XMLDescriptoren erfordert.1 Verbreitung der Applikationsserver [CZ2202] Im Bereich der frei verfügbaren Server ist der JBoss-Server ein herausragendes Projekt.html . ist eine Unterstützung des Entwicklungsprozesses durch spezielle Werkzeuge erforderlich. Für den Produktionseinsatz wird dieser Server jedoch nicht empfohlen und wird deshalb auch nicht in der Tabelle 7.3.org/tomcat/index.2 Entwicklungswerkzeuge Prinzipiell können Anwendungen für die J2EE-Plattform mit jedem Quelleditor erstellt werden. Mittlerweile in der Version 3.apache.0.

Andere. Hersteller wie Oracle oder IBM. die das gewünschte Pattern in seinen Grundfunktionen implementiert.com/software/sundev/jde/ http://www.com/products/xde/javaed/index. von der Applikationsserverentwicklung unabhängige Entwicklungswerkzeuge.com/ http://www. Der Entwickler muss dann nur mehr an bestimmten Stellen seine eigene Funktionalität ergänzen. welche Entwicklungswerkzeuge und Applikationsserver anbieten. Die verschiedenen Werkzeuge unterstützen dabei aber nicht immer alle am Markt verfügbaren Applikationsserver. B. Dies bietet z.jsp http://www. Dabei ist es möglich. über einen Assistenten eine Anwendungsvorlage zu erstellen.html http://www. . unterstützen dabei in vielen Funktionen die eigenen Applikationsserver am besten.Implementierung 95 Produktname Edition IBM WebSphere Studio IO . die Entwicklungsumgebung Together ControlCenter von TogetherSoft.2 Entwicklungswerkzeuge für J2EE Tabelle 7. IBM Websphere) zufrieden stellend.com/ http://www.com/ Tabelle 7.com/jbuilder/ http://www-3.rational. nicht aber Server von anderen Herstellern. unterstützen oft nur die wichtigsten.rational.Software ArcStyler Oracle9i Developer Suite Rational Rose for Java Developers Rational XDE Professional Java Edition Sun One Studio 4 Together ControlCenter Webgain Studio URL Borland JBuilder Enterprise http://www. Ein weiteres Merkmal von Entwicklungswerkzeugen ist eine Integration der von Sun in [ALU01] definierten Vorlagen für die Entwicklung von J2EE Anwendung.com/products/rose/java/jprof.com/ip/develop/ids/index.oracle.arcstyler.webgain.2 listet eine Sammlung von Entwicklungswerkzeugen für J2EE Anwendungen auf. am Markt befindlichen Server (BEA Weblogic.borland.jsp http://wwws.com/software/ad/adstudio/ http://www.sun.ibm.togethersoft.

Da die verfügbare Demoversion eine Laufzeit von 30 Tagen hat. Hierbei unterscheiden sich die verschiedenen Hersteller vor allem in den unterstützten UML Diagrammtypen. 7. wird für den Prototypen dieser Server eingesetzt.1 Unterstützung durch Entwicklungswerkzeuge frei verfügbar Die oben genannten Vorraussetzungen bieten einerseits der Applikationsserver des JBoss Projekts und andererseits die Referenzimplementierung von Sun Microsystems.4 Auswahl des Entwicklungswerkzeugs Für die Auswahl des im Rahmen der Diplomarbeit verwendeten Entwicklungswerkzeugs sind folgende Kriterien wichtig: • • • • • J2EE 1. da die Entwicklungswerkzeuge von diesen Firmen aus der Entwicklung von UML Modellierungswerkzeugen hervorgegangen sind. Hierbei nehmen die Werkzeuge von Rational und TogetherSoft eine herausragende Rolle ein.3.Implementierung 96 Eine Integration von UML Modellierungs-Werkzeugen bietet mittlerweile auch fast jeder Hersteller.1 kompatibel Unterstützung von frei verfügbaren Applikationsservern UML – Modellierung Unterstützung der J2EE Patterns aus [ALU01] frei verfügbare Demoversion Die oben genannten Kriterien unterstützt nur die Entwicklungsumgebung TogetherJ von TogetherSoft. . 7.3 Auswahl des Applikationsservers Für die Auswahl des im Rahmen der Diplomarbeit verwendeten Applikationsservers sind folgende Kriterien wichtig: • • • standardkonform zu J2EE 1. wird dieses Werkzeug für die Implementierung des Prototypen eingesetzt.3. Da die Referenzimplementierung von Sun durch die verschiedenen Entwicklungswerkzeuge am besten unterstützt wird.

wobei die in [Alu01] beschriebenen Patterns als Basis dienen. Abbildung 7.4 Programmierung Die Programmierung erfolgt mit Hilfe der Entwicklungsumgebung TogetherJ von Togethersoft (Abbildung 7.5 Deployment Die Veröffentlichung der EJBs erfolgt mit dem DeployTool der Referenzimplementierung des EJB-Servers von Sun Microsystems. Dabei wird das von TogetherJ erzeugte EAR-Archiv der Anwendung ausgewählt und auf den J2EE- . Der automatisch erzeugte Quellcode wird mit Hilfe von Assistenten erzeugt. Die Programmierung der Anwendungslogik erfolgt im Quellcodeeditor.Implementierung 97 7. wobei Teile der Quellcodes von TogetherJ selbst erzeugt werden.2). Abbildung 7.2 Entwicklungsumgebung TogetherJ 7. Der Entwurf kann dabei mit Hilfe des UML-Designers umgesetzt werden.3 zeigt die Benutzeroberfläche dieses Werkzeugs. mit dessen Hilfe man Anwendungen auf den J2EE Server von Sun installieren kann.

6 zeigen einige Bildschirmausdrucke der Benutzerschnittstellen. Abbildung 7.Implementierung 98 Server übertragen. Weiters wurde zur Erstellung des Layouts der Benutzerschnittstellen der HTML-Editor Adobe GoLive 6. Anhand des Benuzterlogins wird dem Benutzer die jeweilige Benutzerschnittstelle präsentiert.4 zeigt einen Bildschirmausdruck des Login-Dialogs. Nach dem Deployment-Vorgang stehen die einzelnen EJBs den Anwendungen zur Verfügung. . Abbildung 7. Der Login-Dialog ist der zentrale Einstiegspunkt zum System.0 verwendet.6 Prototyp Die Implementierung des Prototyps erfolgte mit den oben beschriebenen Werkzeugen. Abbildung 7.4 bis Abbildung 7.3 Deployment mit der Referenzimplementierung 7.

4 Login-Dialog Abbildung 7. Hier können die Eigenschaften und Zugriffsrechte von Benutzern verändert werden. Abbildung 7.Implementierung 99 Abbildung 7.5 Benutzerliste .5 zeigt die Benutzerschnittstelle für die Benutzerverwaltung.

6 zeigt das Formular zum Ändern der Benutzereigenschaften.6 Benutzerdaten ändern .Implementierung 100 Abbildung 7. Hier können Benutzerdaten und die diesen Benutzer zugewiesenen Rollen verändert werden. Abbildung 7.

Diese wurden bei der Fallstudie verwendet. die wesentlichen Erkenntnisse des Entwurfs beziehen sich daher auf die mit dem Pattern . beziehen sich auf die Phase des Entwurfs. Die Empfehlungen. wann J2EE für ein Projekt eingesetzt werden soll. Die entwickelten Empfehlungen stellen die wichtigsten Erkenntnisse aus dieser Phase dar und sollen zukünftigen Systementwicklern eine Orientierung bieten. Wie im Abschnitt 3. Diese Kriterien werden im Anschluss definiert und es wird die dazugehörende Empfehlung mit Begründung angegeben. die Projektkomplexität. andererseits auf die beim Entwurf zu beachtenden Besonderheiten. beziehen sich auf die Phase nach der Systemspezifikation. Die Empfehlungen.4 dargestellt. Sie sind Empfehlungen und beziehen sich einerseits auf die Eignung von J2EE für bestimmte Aufgabenstellungen. Die entwickelten Kriterien sollen die Technologieauswahlentscheidung unterstützen. Wesentliche Kriterien für die Eignung von J2EE zur Lösung der Projektaufgabe sind die Teamgröße. die Benutzeranzahl. die Wiederverwendbarkeit und die Erweiterbarkeit.Designrichtlinien 101 Kapitel 8 Designrichtlinien Die hier dargestellten Designrichtlinien für J2EE resultieren aus einer Zusammenfassung der Dokumentenanalyse und der in der Fallstudie gemachten Erfahrungen. welche Besonderheiten beim Entwurf eines auf der J2EE basieren Systems zu beachten sind. gibt es zur Erleichterung des Entwurfs eines J2EE Systems bereits Entwurfsvorlagen.

Design Benutzeranzahl Definition: Anzahl der Personen. Die Mindestgröße für das Team der technischen Umsetzung kann mit ca. Dabei wird ein angemessenes Antwortzeitverhalten gewährleistet. etc. Servlet. JSP. Im Abschnitt 8. Dafür werden verschiedenartige Qualifikationen benötigt und es erscheint daher nicht empfehlenswert. Diese Personen können folgende Aufgaben übernehmen: • • • • • Entwurf und Projektkoordinierung Clientprogrammierung (JSP.5 Personen beziffert werden. Anwendungen verteilt auf mehreren Servern ausführen zu lassen. Diese Aufgaben und Techniken umfassen beispielsweise die Clientprogrammierung (HTML. 4 .2 werden die einzelnen Patterns analysiert und einer Bewertung unterzogen. dass eine einzelne Person alle diese Aufgaben bewältigen und Techniken erlernen soll.Designrichtlinien 102 Katalog von [Alu01] gemachten Erfahrungen. HTML) EJB Programmierung Serverkonfiguration Datenbankprogrammierung.). desto geeigneter sind EJBs. die das System gleichzeitig benützen sollen. Empfehlung: Je größer das Team. 8. . da es viele verschiedenartige Aufgaben und Techniken beim Entwurf von J2EE-Anwendungen gibt. Empfehlung: Je höher die Benutzeranzahl. Begründung: Das Team sollte für den Einsatz von EJBs eine bestimmte Mindestgröße haben. Durch diese Verteilung lässt sich das System in Bezug auf die Benutzeranzahl leicht skalieren. Servlets. Javaclient.1 Empfehlungen für die Technologieentscheidung Teamgröße Definition: Anzahl der bei einem Softwareprojekt mitwirkenden Personen. desto geeigneter sind EJBs. Begründung: Mit der Technik der EJB ist es möglich. die Integration vorhandener Systeme oder die Datenbankanbindung.

In den folgenden Abschnitten werden die einzelnen Patterns nach folgendem Schema bewertet bzw. Die Verteilung der Anwendung auf mehrere Rechner erhöht die Verlässlichkeit des Systems. desto geeigneter sind EJBs. Empfehlung: Je höher die Anforderungen an die Erweiterbarkeit sind. 8. Wiederverwendbarkeit Definition: Möglichkeit der mehrmaligen Benutzung einzelner Komponenten in einem System oder verschiedenen Systemen. kategorisiert: .4 dargestellten Patterns für die Entwicklung von mehrschichtigen Anwendungen mittels J2EE erwiesen sich in der Fallstudie grundsätzlich als gut brauchbar. Erweiterbarkeit Definition: Möglichkeit das System um neue Funktionalitäten zu ergänzen. Begründung: Durch die Verwendung von EJB lässt sich das System einfach um zusätzliche Komponenten erweitern.2 Bewertung der J2EE Patterns Die im Abschnitt 3. die einfach angepasst und/oder in andere Systeme integriert werden können. desto geeigneter sind EJBs. Begründung: Die Architektur der J2EE stellt den Transaktionsmechanismus auf verteilter Komponentenebene zur Verfügung.Designrichtlinien 103 Projektkomplexität Definition: Struktur eines Systems. Dies ist Voraussetzung für die Entwicklung von komplexen Systemen. Die Struktur besteht aus den Einzelteilen und deren Zusammenwirken. Empfehlung: Je höher die Projektkomplexität. Begründung: Durch den komponentenorientierten Aufbau der EJBs besteht jedes System aus einzelnen Teilen. Die Komponentenstruktur ermöglicht die Erweiterung des Systems im laufenden Betrieb. desto geeigneter sind EJBs. Erfahrung: Je höher die Anforderungen an die Wiederverwendbarkeit sind.

Implementierungsaufwand Bewertung des Implementierungsaufwands einzelner Komponenten.Designrichtlinien 104 Kategorie Problem Beschreibung Beschreibung des Problems.2.1 Bewertungsschema für Designvorlagen (Patterns) Um die Bewertungen direkt den Beschreibungen der Patterns zuordnen zu können. werden der folgende Abschnitt wie Abschnitt 3. Bewertung der Brauchbarkeit in der konkreten Fallstudie oder allgemeine Beurteilung durch die im Rahmen dieser Diplomarbeit gemachten Erfahrungen mit J2EE.1.4 in Präsentationsschicht. Tabelle 8. das mit Hilfe dieses Patterns gelöst werden soll. 8.1 Intercepting Filter Der Mechanismus zur Anfragebearbeitung in der Präsentationsschicht erhält viele verschiedene Typen von Anfragen und kann verschiedene Typen von . Ziele Bewertung Ziele. Businessschicht und Integrationsschicht gegliedert.2.1 Präsentationsschicht Die hier bewerteten Design Patterns sind • • • • • Intercepting Filter Front Controller View Helper Service to Worker Dispatcher View 8. die mit Hilfe dieses Patterns verfolgt werden. Strukturkomplexität Bewertung der Strukturkomplexität anhand der Anzahl der beteiligten Komponenten und deren Vernetzung.

bzw.1. Problem: Eine Anfrage eines Web-Clients muss zur Weiterverarbeitung von mehreren Komponenten vor.1 beschriebene Architektur der Intercepting Filter beschreibt eine modularen Aufbau von Filterelementen.1. bzw. andere müssen modifiziert. Dieses Pattern eignet sich vor allem. überprüft werden müssen.4.Designrichtlinien 105 Antwortmöglichkeiten verwalten. bevor diese weitergeleitet werden können.2. 3 1-2 einfach . Einige Anfragen werden einfach an die zuständige Komponente weitergeleitet. die wiederum je nach Bedarf wiederverwendet werden können. falls Anfragen häufig übersetzt.2 Front Controller Die Präsentationsschicht bearbeitet Anfragen und kontrolliert den Ablauf der Anwendung für jeden Benutzer des Systems. Bewertung: Die im Abschnitt 3. Kontrollmechanismen können in einem zentralen oder dezentralen Prozess durchgeführt werden. geprüft oder dekomprimiert werden. nachbehandelt werden. 8. Ziel: Ein möglichst einfacher und dennoch leicht erweiterbarer Mechanismus zum Aufbereiten und Filtern einer Anfrage. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Durch die einfache und klare Struktur dieses Patterns ist die konkrete Umsetzung als leicht zu bewerten.

nicht in den einzelnen Views mehrfach implementieren werden. die im Kontext eine Einheit bilden. D. die bei jeder Anfrage durchgeführt werden. da die Anfragebehandlung und die geeignete Weiterleitung der Anfragen an Views und Arbeitskomponenten eine komplexe Aufgabe ist. benötigt die Implementierung eine hohe Aufmerksamkeit.h.2. Ziel: Ziel des Front Controllers ist es. Ansichtsmanagement und Navigation zu gewährleisten. So müssen Aktivitäten. da ansonsten für eine komplexe Anfrageverarbeitung ein eigener Entwurf entwickelt werden müsste. 1-2 Je nach Implementierung komplex . Dies verhindert die Codevervielfältigung.Designrichtlinien 106 Problem: Das System benötigt einen zentralen Einstiegspunkt. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Da der Front Controller eine zentrale Rolle im Anfragemanagement einnimmt. Dienste. Bewertung: Dieses Pattern war bei der Fallstudie sehr gut brauchbar. einen zentralen Einstiegspunkt für alle Anfragen zu schaffen. Bei großen Systemen sollten aber die verschiedenen Systemdienste in mehrere Front Controller gruppiert werden. welche aus dynamischen Geschäftsdaten erzeugt werden.3 View Helper Das System generiert Präsentationsinhalte. 8. um die Integration von Systemdiensten. Inhaltsbeschaffung.1. sollen jeweils durch einen eigenen Front Controller erreichbar sein. Der Entwurf des Front Controllers erfordert ein fundiertes Wissen über das gesamte System.

Bewertung: Dieses Pattern sollte in jeder J2EE-Anwendung konsequent verwendet werden. steuert den Datenzugriff und generiert die Präsentation der Daten. Dies soll eine größere Unabhängigkeit von Änderungen auf beiden Seiten gewährleisten. Es ist daher schwierig. 8.4 Service to Worker Das System kontrolliert den Arbeitsablauf.Designrichtlinien 107 Problem: Die Präsentationsschicht ist häufigen Änderungen unterworfen. 2 1 einfach . Probleme bei der Wartung oder bei der ersten Umsetzung des Systems sind vorprogrammiert. Bei der Fallstudie kann die Brauchbarkeit dieses Patterns als sehr hoch eingestuft werden. Bei konsequenten Einsatz dieses Patterns ist der Implementierungsaufwand durch die Wiederverwendung der View Helper Komponenten mit Sicherheit geringer.1. Ziel: Ziel dieses Patterns ist die Trennung der Implementierung der Präsentation von der Implementierung der Zugriffe auf Datenquellen und Systemdienste. eine Anwendung zu entwickeln und zu warten. als bei Codevervielfältigung in den einzelnen Views. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Durch die einfache und klare Struktur dieses Patterns ist die konkrete Umsetzung als leicht zu bewerten. wenn die Trennung von Präsentation und Anwendungslogik nicht konsequent durchgeführt wird. wenn der Zugriff auf Geschäftsdaten mit der Logik der Präsentation verwoben wird.2.

Dieses Pattern beschreibt eine gängige Kombination aus Front Controller. Ziel: Ziel ist es. wenn die geforderte Antwort nicht direkt in der URL der Anfrage kodiert ist und aus verschiedenen Zuständen der Applikation entschieden werden muss. Views und View Helper Komponenten. ist dieses Pattern zu bevorzugen. Auch wenn auf den ersten Blick die Struktur etwas kompliziert aussieht. ist die Implementierung dieses Patterns naturgemäß komplex.Designrichtlinien 108 Problem: Es wird eine durchgängige Systemstruktur in der Präsentationsschicht benötigt. Da bei großen Projekten das Antwortveralten der Applikation sehr kompliziert sein kann. h. 3-N variabel komplex . Dispatcher. soll dieses Pattern verwendet werden. um auf Anfragen des Clients reagieren zu können. D. welche Antwort dem Client geliefert wird. Bewertung: Für Projekte. die komplexe Entscheidungsmechanismen bezüglich Antwortverhalten benötigen. eine Vorlage für die Systemstruktur der gesamten Anwendung der Präsentationsschicht zu bieten. ist für komplexe Anwendungen ein Vorlage für den gesamten Aufbau der Präsentationsschicht sehr gut einsetzbar. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Die Implementierung dieses Patterns erfordert detailliertes Wissen über die Gesamtstruktur der Präsentationsschicht der Anwendung.

1. Das geforderte Antwortveralten wird direkt in den URLs der Ansichten kodiert und bei Aufruf dieser URLs wird die benötigte View haupsächlich über kodierten Informationen in der URL ermittelt. Da aber die angeforderten Informationen direkt in der URL kodiert sind. 3-N variabel einfach . hinsichtlich Erweiterbarkeit und Wartbarkeit ist diese Vorlage aber auf jeden Fall zu empfehlen.Designrichtlinien 109 8. Problem: Es wird eine durchgängige Systemstruktur in der Präsentationsschicht benötigt. eine Vorlage für die Systemstruktur der gesamten Anwendung der Präsentationsschicht zu bieten. ist die Weiterleitung an die benötigten Views ein eher einfaches Problem. Dieses Pattern beschreibt eine gängige Kombination aus Front Controller. um auf Anfragen des Clients reagieren zu können. falls das Antwortverhalten der Applikation ein eher einfaches ist.5 Dispatcher View Das System kontrolliert den Arbeitsablauf und Datenzugriff. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Die Implementierung dieses Patterns erfordert detailliertes Wissen über die Gesamtstruktur der Präsentationsschicht der Anwendung. Dispatcher. Dieses Pattern beschreibt eine gängige Kombination aus Front Controller. von welchen es eine Präsentation der Daten generiert. Ziel: Ziel ist es. Auch hier ist wiederum zu sagen dass die verwendete Struktur doch sehr komplex anmutet. Bewertung: Im Gegensatz zum Service to Worker soll dieses Pattern verwendet werden. Dispatcher. Views und View Helper Komponenten.2. Views und View Helper Komponenten.

Bewertung: Die Entkopplung der verschiedenen Schichten durch speziell dafür vorgesehene Komponenten ist wichtig.2. .2. Nur so kann der spätere Wartungsaufwand möglichst gering gehalten werden.2.1 Business Delegate Das Business Delegate Pattern dient zur Entkopplung der Präsentationsschicht von der Businessschicht.Designrichtlinien 110 8. Durch die Zusammenfassung von komplexen Abläufen durch nur einen Methodenaufruf wird der Zugriff der Präsentationsschicht auf die Businesslogik vereinfacht. nicht aber in der Präsentationsschicht.2 Businessschicht Die hier bewerteten Design Patterns sind: • • • • • • • Business Delegate Value Object Session Facade Composite Entity Value Object Assembler Value List Handler Service Locator 8. Änderungen an der Businesslogik erfordern nur Änderungen in der Business Delegate Komponente. da Änderungen in der Businesslogik auch Änderungen in der Präsentation erfordern. Problem: Durch die direkte Kopplung der Präsentationsschicht mit der Businessschicht (Direkter Zugriff der Präsentationsschicht auf Komponenten der Businesslogik) entsteht ein System. Ziel: Durch die Implementierung des Business Delegate Patterns soll das oben beschriebene Problem gelöst werden. das schwierig zu Warten ist.

Durch diesen hohen Kommunikationsaufwand können Probleme hinsichtlich Performanz auftreten. das der Zugriff auf 3 3 einfach .Methoden kann die Netzwerkkommunikation verringert werden. Durch die Zusammenfassung von komplexen Abläufen in der Businesslogik wird zudem der Zugriff der Präsentationsschicht auf die Businessschicht erleichtert.2. aufgrund des technischen Umstandes. Problem: Beim Zugriff auf die Daten von Entity-Beans erfolgt bei jeder Datenanforderung ein RMI-Aufruf.2. Get .bzw. Bewertung: Durch die Notwendigkeit der Reduzierung der Netzwerkkommunikation muss dieses Pattern häufig eingesetzt werden. Ziel: Durch die Zusammenfassung mehrere atomarer Elemente mit Hilfe von Value Objects und dazugehöriger Set . h. welcher einen dementsprechend hohen Netzwerkkommunikationsaufwand erfordert.Designrichtlinien 111 Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Der Implementierungsaufwand dieses Patterns kann als einfach bewertet werden. D. da die Art und Weise der Interaktion der verschiedenen Komponenten einfach zu Verstehen ist.2 Value Object Value Objects dienen zur Kommunikation zwischen Komponenten und Schichten. Der Grund für den Einsatz dieses Patterns ist aber ein rein technischer. Sie fassen mehrere atomare Elemente zur einer komplexeren Struktur zusammen und dienen zum Informationsaustausch. 8.

um den Geschäftsprozess zu steuern. Dies ist Problematisch. 1 2 einfach .Designrichtlinien 112 Entity Beans nur über das Remote Interface der Bean erfolgen kann. Trotzdem soll hier nicht außer acht gelassen werden. Problem: Bei komplexen Anwendungen kann die enge Vernetzung der einzelnen EJBs zu schwer wartbaren Quellcode führen. muss dieses Pattern verwendet werden. da die Abhängigkeiten zwischen diesen Beans hoch wird.2. Ziel: Durch die Einführung von Session Facades kann die Komplexität von Geschäftsprozessen versteckt werden. Die Clients dieser Facade verwenden nur die von ihr zur Verfügung gestellten Methoden.2. da hier die Trennung von Logik und der zugrunde liegenden Technik nicht mehr gegeben ist.3 Session Facade Die Session Facade dient zur Kapselung der Komplexität der Interaktion zwischen Geschäftsobjekten in einem Arbeitsablauf. dass bei anderem technischen Hintergrund die Implementierung des Value Object Patterns häufig entfallen könnte. Dies Verhindert eine enge Kopplung zwischen den verschiedenen Teilsystemen der Anwendung. Eine Session Facade wird als eine Session Bean implementiert und fasst einen logisch zusammenhängenden Arbeitsablauf in einem Geschäftsprozess zusammen. 8. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Der Implementierungsaufwand kann als einfach bewertet werden.

Problem: Die direkte Abbildung des Datenmodells auf Entity Beans führt zu einer feinkörnigen Struktur der Entity Beans. da die Art und Weise der Interaktion der verschiedenen Komponenten einfach zu verstehen ist. Dies kann zu folgenden Problemen führen: • • • • Hohe Abhängigkeit des Business Modells zum Datenmodell Clients sind stark vom Datenmodell abhängig Hohe Anzahl an Entity Beans Netzwerkperformance schlecht 3-N variabel einfach . ist die Session Facade zu empfehlen.2.2. Dies fordert eine hohe Anzahl an Remote Referenzen und Interaktionen zwischen den einzelnen Beans. in denen verschiedene Teilsysteme getrennt werden können. Daten die voneinander abhängig sind als Ganzes in eine Entity Bean zu sammeln. Die Zusammenfassung komplexer Teilsysteme führt zu einem leichter wartbaren Code.Designrichtlinien 113 Bewertung: Bei komplexen Anwendungen.4 Composite Entity Das Pattern Composite Entity beschreibt eine Möglichkeit. Die dadurch entstehenden Vorteile rechtfertigen den Aufwand der Implementierung dieser Komponente. 8. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Der Implementierungsaufwand dieses Patterns kann ähnlich wie beim Business Delegate Pattern als einfach bewertet werden.

B. Falls Zugriffsoptimierungen notwendig sind. Strategien wie die Lazy Loading Strategy [ALU01.Designrichtlinien 114 Ziel: Das Pattern Composite Entity verwaltet nicht nur die Daten einer einzelnen Tabelle. was zur Folge hat. 8. Abhängigkeiten zwischen diesen Daten werden direkt in einer einzelnen grobkörnigen Entity Bean implementiert. 3 3 komplex . können z. das von den Clients weiterverarbeitet werden kann. Die Persistenzverwaltung der Daten muss auf jeden Fall in der Bean implementiert werden.2. 317] implementiert werden. 317] und die Store Optimization Strategy [ALU01.5 Value Object Assembler Das Pattern Value Object Assembler sammelt Daten von verschieden Quellen und liefert ein Value Object. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Die Implementierung des Composite Entity Patterns gestaltet sich je nach Optimierungsstrategie mehr oder weniger aufwendig. Die Persistenzverwaltung muss hier die Entity Bean übernehmen (Bean managed persistence). dass Optimierungsstrategien für den Datenzugriff von der Entity Bean übernommen werden muss. sondern verwaltet eine ganze Datenstruktur die logisch zusammenhängt. Bewertung: Durch die oben genannten Nachteile einer feinkörnigen Abbildung des Datenmodells auf Entity Beans ergibt sich die Notwendigkeit der Verwendung dieses Patterns.2.

Falls der Client diese Daten von den einzelnen Komponenten direkt anfordert. das der Einsatzzweck für die Präsentation von Daten bestimmt ist. Ziel: Der Value Object Assembler sammelt die geforderten Daten und erstellt ein spezielles Value Object. Es werden dabei Referenzen auf die Komponenten benötigt. 3-N 3 einfach . von denen wiederum die einzelnen Value Objects angefordert werden. Bewertung: Das Value Object Assembler Pattern kann nur zum Lesen der Daten benutzt werden. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Die Implementierung dieses Patterns kann als einfach bewertet werden. kommt dieses Pattern häufig zum Einsatz. erzwingt dies eine hohe Abhängigkeit des Clients von der Business Logik und vom Datenmodell. das vom Client weiterverarbeiten werden kann. Entity Beans. etc. Diese Value Objects werden wiederum zu einem neuen Value Object zusammengefasst und an den Client zurückgegeben. Diese bedeutet.Designrichtlinien 115 Problem: Clients benötigen Daten von verschiedenen Business Komponenten wie Session Beans. DAOs. Außerdem verschlechtert dies die Netzwerkperformance durch eine hohe Anzahl an Methodenaufrufen über das Netzwerk. da das Sammeln der Daten einfach ist. Da bei vielen „Real World Applikationen“ Daten von verschiedenen Komponenten zur Präsentation gebraucht werden. Hauptvorteil ist die Unabhängigkeit des Clients zur restlichen Logik des Systems.

die durch Entity Beans repräsentiert wird. Weiters können mit Hilfe dieses Patterns Caching-Strategien umgesetzt werde.6 Value List Handler Das Pattern Value List Handler dient dem Client zum Zugriff auf Daten in Listenform. Der Value List Handler präsentiert dem Client die Daten mit Hilfe eines Iterators. dass eine EJB Finder Methode ressourcenintensiv ist um ein Liste von Objekten zu finden.und Anfragefunktionen große Anzahl an Datensätzen liefern. falls der Client zum Beispiel nur die ersten Datensätze des Ergebnisses anzeigen möchte. dass man die nicht mehr die Standardfunktionalität eines EJB Containers verwendet.Designrichtlinien 116 8. Dies reduziert die zu übertragenden Daten. In einigen Fällen können diese Such. Bewertung: Der Einsatz von Value List Handlers bietet eine Alternative für die EJB Finder Methoden von Entity Beans. sondern eigene Mittel zum Zugriff auf Daten der Anwendung implementiert. Da dieses Pattern über ein DAO auf die Daten zugreift. umgeht man damit die Datenstruktur. einzelne Datensätze des Ergebnisses anzufordern. Problem: Die meisten J2EE Applikationen besitzen Such.2. Ziel: Die Verwendung eines Value List Handlers bietet dem Client die Möglichkeit. Problem dabei ist. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System 3 2 einfach . Dabei ist es nicht von Vorteil.und Anfragefunktionalität zum Zugriff auf Daten.2. da eine Menge von EJB Referenzen dazu nötig sind. Argument dafür ist. das gesamte Abfrageergebnis zurückzuliefern.

Es ergeben sich dadurch nur Vorteile.2.7 Service Locater Das Service Locator Pattern dient zum Zugriff auf Ressourcen über das JNDI-Interface. Da in einer J2EE Anwendung häufig JNDI Aufrufe auftreten.2. Weiters bietet dieses Objekt einen zentralen Einstiegspunkt zur Lokalisierung von Diensten und bietet die Möglichkeit von Cache-Funktionalität. Die einfach Struktur des Value List Handlers und die einfach Funktionalität zur Verwaltung der Listen ist mit wenig Aufwand zu Implementieren. wobei eine einfach Implementierung einer der wichtigsten Gründe darstellt. ergibt sich eine Quellcodevervielfachung dieser Aufrufe. vereinfachter Zugangspunkt dazu nur zu empfehlen. Bewertung: Dieses Pattern stellt eine wichtige Vorgangsweise zur Objektfindung dar. Problem: Der Zugriff auf Ressourcen über das JNDI-Interface ist ein Zentraler Bestandteil fast jeder Teilkomponente des Systems. 8. Da die Kommunikation mit dem JNDI-Interface mehrer Schritte benötigt. . Dies versteckt die Komplexität der Kommunikation mit dem JNDI und reduziert die Codekomplexität. ist ein zentraler. Ziel: Durch die Benutzung eines Service Locator Objekts soll ein eine Abstraktionsebene zwischen Komponenten und JNDI-Interface eingeführt werden.Designrichtlinien 117 Implentierungsaufwand: Der Implementierungsaufwand gestaltet sich je nach Erfordernissen an die Listenfunktionalität eher als gering. Die verschiedenen Komponenten müssen häufig Referenzen auf andere Komponenten über das JNDI-Interface erzeugen.

Ziel: Die Einführung eines DAO zum zentralen.3 Integrationsschicht 3 3 einfach Die hier bewerteten Design Patterns sind: • • Data Access Object Service Activator 8.2. 8. die man als Basis für einen Service Locator verwenden kann.1 Data Access Object Das Data Access Object abstrahiert und kapselt den Zugriff auf persistente Datenquellen.2. Problem: Viele J2EE Anwendungen verwenden verschiedene Datenquellen wie relationale Datenbanken. von den Datenquellen abstrahierten Zugriffs auf persistente Datenquellen verringert sich die Abhängigkeit von Logik und Daten. Die Verwendung verschiedener Datenquellen erfordert verschiedene Implementierungen für den Zugriff auf diese Daten. Dateien. objektorientierte Datenbanken.Designrichtlinien 118 Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Die Implementierung eines Service Locator Objekts ist je nach Cache-Strategie einfach bis komplex. Durch die Implementierung dieses Patterns verringert sich in den anderen Komponenten die Implementierung der JNDI Aufrufe maßgeblich. Im Buch [ALU01] werden für die Implementierung verschieden Vorlagen geboten. Durch den direkten Zugriff von J2EE Komponenten auf diese Datenquellen entsteht eine direkte Abhängigkeit der Komponenten zu diesen Daten. etc. .3.

Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Der Aufwand der Implementierung hängt stark von den verwendeten Datenquellen ab und der Implementierungsstrategie ab. Je nach Implementierung kann diese auch aufwändig sein. und wird nicht von der EJB-Spezifikation festgelegt. Bei Applikationen bzw. 8.0 eingeführten Message Driven Beans können nur als Stateless Session Bean implementiert werden. die die Persistenzverwaltung nicht vom Container verwalten lassen. ist ein DAO zu empfehlen.Designrichtlinien 119 Bewertung: Bei Verwendung eines DAO kann der Datenzugriff nicht mehr vom EJB-Container verwaltet werden.3. Die Vorteile durch vereinfachten Datenzugriff und Entkopplung des Systems von den Datenquellen heben diesen Implementierungsaufwand aber wieder auf.2 Service Activator Dieses Pattern beschreibt eine Vorgangsweise zum aktivieren von Diensten über eine asynchrone Schnittstelle.2. 2 2 einfach . Der asynchrone Zugriff auf Stateful Session Beans oder Entity Beans ist nicht vorgesehen. Komponenten. Dies ist nur über das JMS API möglich. Der Hauptvorteil ergibt sich durch die Trennung von Logik und Datenhaltung. Die in EJB 2.komplex . Problem: Clients möchten Dienste von EJB-Komponenten asynchron aktivieren.

8. . B. Der Client muss nicht auf die Fertigstellung der Aufgabe warten. wenn Aktionen ausgeführt werden sollen.Designrichtlinien 120 Ziel: Die Verwendung des Service Activator Patterns ermöglicht das asynchrone Ausführen von Diensten. die vom Client erzeugt werden muss. Hier ist es nicht unbedingt notwendig. aber keine konkreten Empfehlungen gegeben. die von einem Client aktiviert werden können. in der Fallstudie als gut geeignet erwiesen.2. wie eingangs erwähnt. die keine Message Driven Beans unterstützen (EJB Spezifikation < 2. Die Umsetzung einer MessageListener Komponente ist einfach und wird in [ALU01] in groben Zügen beschrieben. welche Einsatzgebiete für das jeweilige Pattern geeignet sind. Faxversand). Die Notwendigkeit von asynchronen Diensten tritt häufig auf.0). Bewertung: Dieses Pattern eignet sich vor allem für Container. Die Aktivierung eines asynchronen Dienstes erfolgt mit einer JMS Nachricht.4 Allgemeine Aussagen zu den Patterns 4 4 komplex Obwohl sich die Patterns. dass der Client auf die Fertigstellung wartet. Auch dies kann über eine zusätzliche Abstraktionsschicht vereinfacht werden. die grundsätzlich eine längere Zeit dauern (z. Beispielsweise werden für die Systemstruktur folgende Patterns zur Verfügung gestellt: Dispatcher View. gibt es doch zwei wesentliche Kritikpunkte: - Es werden verschiedene Entwurfsvorlagen für die Präsentationsschicht vorgestellt. Strukturkomplexität: Anzahl der Objekte Anzahl der Verbindungen zur Systemumgebung Einbindung in das System Implentierungsaufwand: Der Implementierungsaufwand kann als moderat bezeichnet werden.

- Der Großteil der Patterns hat durch ihren Aufbau das Ziel die Netzwerkkommunikation zu verringern. . Dispatcher in View Strategy und Dispatcher in Controller Strategy. Dieser einseitige Focus vernachlässigt teilweise das Ziel der einfachen und vor allem systemunabhängigen Anwendungsentwicklung.Designrichtlinien 121 Service to Worker.

und Anwendungsplattform bietet verschiedene Technologien. da Unternehmen immer häufiger weltweit tätig sind und dadurch an die Anwendungen auch weltweit zur Verfügung gestellt werden müssen. ist die Gefahr . Als Basis für mehrschichtige Anwendungen stellt Sun Microsystems den offenen Standard Java 2 Enterprise Edition (J2EE) zur Verfügung. die für die Entwicklung mehrschichtiger Anwendungen erforderlich sind (siehe Kapitel 1 und Kapitel 3). auf der Javatechnologie basierende Entwicklungs. Grund dieser Entwicklung sind einerseits die voranschreitende Globalisierung und die rasante Weiterentwicklung der Internettechnologie. Business-Logik und Benutzerschnittstellen. Andererseits bietet diese Anwendungsstruktur Vorteile wie beispielsweise vom Client unabhängige Schnittstellen. Die Globalisierung wird hier als Grund angeführt. Diese.Zusammenfassung und Ausblick 122 Kapitel 9 Zusammenfassung und Ausblick Webbasierte mehrschichtige Applikationen werden immer mehr in vielen Bereichen der Anwendungsentwicklung eingesetzt. Da die Zusammenarbeit dieser Technologien in J2EE auf den Entwurf einer konkreten Anwendung Einfluss nimmt. die Möglichkeit der Verteilung der Anwendung und die Trennung von Daten. Solche Anwendungen erfordern und ermöglichen die ortsunabhängige Zusammenarbeit und Informationsverteilung.

Weiters werden in diesem Abschnitt konkrete Designvorlagen für den Entwurf von Anwendungen auf Basis von J2EE vorgestellt. Die in dieser Fallstudie gemachten Erfahrungen erweitern die Ergebnisse der Literaturanalyse um praktische Erfahrungen. Dabei wird erstens auf die von Sun Microsystems standardisierte Vorgangsweise eingegangen und zweitens die vom Autor durchgeführte Implementierungsphase beschrieben. Kapitel sieben beschreibt die Vorgehensweise bei der Implementierung von J2EE Anwendungen. Diese Fallstudie behandelt eine Anwendung für ein Call Center. Vom Anwendungsentwickler wird ein komplexes Wissen über diese Technologien vorausgesetzt. andererseits in einer Fallstudie ein Prototyp auf Basis von J2EE entworfen. Für die im Rahmen dieser Fallstudie zu entwerfende mehrschichtige Anwendung wurde eine Istanalyse und eine Systemspezifikation erarbeitet. in der vorhandene Richtlinien und Empfehlungen analysiert werden. Der Schwerpunkt der Implementierung liegt in der Überprüfung der Umsetzbarkeit des im Kapitel sechs dargestellten Entwurfs. Im vierten und fünften Kapitel wurde auf die Fallstudie eingegangen. Zur Erreichung dieses Ziels wurde einerseits eine Literaturanalyse durchgeführt. Hierbei wird im Besonderen auf die Enterprise Java Beans eingegangen. Ziel dieser Diplomarbeit war es daher Designrichtlinien für den Entwurf von mehrschichtigen Anwendungen auf Basis von J2EE zu Bewerten. Die Kapitel eins und zwei schufen die zur Zielerreichung notwendigen Grundlagen. Im Kapitel drei wird ein Überblick über die Java 2 Enterprise Edition gegeben. wie man auf Basis von XML und XSLT einen Formulardesigner erstellen kann. Beim Entwurf wurde besonders darauf geachtet. Zur Sammlung von Erfahrungen mit dem Entwurf von J2EE Anwendungen wurde im Kapitel sechs die webbasierte mehrschichtige Anwendung für die Fallstudie „Call Center“ entworfen. die im vorangegangenen Kapitel beschrieben Designvorlagen zu berücksichtigen. Außerdem wird eine Möglichkeit beschrieben. .Zusammenfassung und Ausblick 123 von konzeptionellen Fehlern im Entwurfsstadium groß. da diese ein zentraler Bestandteil von J2EE sind. deren Anforderung eine typisch mehrschichtige Struktur erforderte.

Der Einsatz von Patterns ist vielversprechend in Hinblick auf Modularität und Wiederverwendbarkeit. ob sich die Implementierung des Patterns gegenüber einer einfacheren Lösung lohnt. erhöht jedoch meist die Komplexität. Die Ergebnisse der Arbeit lassen sich wie folgt bewerten: • Jedes Pattern ist gut verwendbar. Sie erfordern verschiedenste Anforderungen an das Know-how der Mitarbeiter.Zusammenfassung und Ausblick 124 Die in Kapitel drei dargestellten Patterns wurden auf Grund der in Kapitel sechs und sieben gemachten Erfahrungen bewertet. • Mehrschichtige Anwendungen sind durch den Einsatz von verschiedenen Technologien für den Entwurf und Implementierung komplex. um die verschiedenen Aufgaben beim Entwurf und der Implementierung bewältigen zu können. • Für die Entwicklung einer Anwendung auf Basis von J2EE gibt es verschiedenste Anbieter von Entwicklungswerkzeugen. Diese Bewertungen werden neben den Empfehlungen für die Technologieentscheidung in Kapitel acht dargestellt. da die Modularität und die Widerverwendbarkeit hoch ist. . Der Einsatz ist aber oft komplex in der Anwendung und es muss für das Projekt individuell entschieden werden. • Mehrschichtige Anwendungen benötigen daher eine bestimmte Teamgröße für die Entwicklung. Es empfiehlt sich für die Anwendungsentwicklungen eine Studie über vorhandene Werkzeuge und Frameworks. Applikationsservern und Frameworks.

Rimbert Rudisch. 2000 [Cal99] Call Center Technologies.com Inc. USA. Heidelberg. erweiterte Auflage. 2001 [Aus00] Gerhard Austaller. 2000 [Beh00] Henning Behme und Stefan Mintert: XML in der Praxis.com/components/appservermatrix. Addison–Wesley. dpunkt. http://www. Max Mühlhäuser. Solaris kommt mit Application-Server [Den00] Stefan Denninger und Ingo Peters: Enterprise JavaBeans. Datenbanken. Best Practices and Design Strategies.verlag. München. Seite 14. Addison– Wesley. Dan Malks: Core J2EE Patterns. 05/2001 [CZ2202] Computer Zeitung 22/02.jsp. Siegfried Reich.org/. 06/2002 . 2.. 2000 [Ehm98] G. Andreas Hartl.uni-linz.html. John Crupi. Christoph Lechleitner.ac. Best Practices and Resource Library.ifs. http://www. http://www. Application Server Comparison Matrix.at/ifs/research/publications/ papers00. Gerti Kappel.Literaturverzeichnis 125 Literaturverzeichnis [Alu01] Deepak Alur. Gulliver Beans: Generating Device Optimized and Individualized Content for WAP Applications. Sun Microsystems Press. München. 1998 [Fla02] Flashline.call-centers. Ehmayer und S.flashline. Verteilung. Reich: Java in der Anwendungsentwicklung Objektorientierung.

com/j2ee. Das Fundament. 2000 . 1999 Andreas Kurz: Data Warehousing–Enabling Technology.ifs. 02/2001 [Kap99] [Kur99] G.verlag. 04/2001 [Kap00] Modeling Customizable Web Applications - A Requirement's Perspective. http://www. Rimbert Rudisch. 05/2001 [J2E01] Java 2 Platform.1999. Christoph Lechleitner. W.unilinz. 2000.sun. http://www. Heidelberg. Prentice Hall.middleware-company. 2001 [Nie00] Jakob Nielson: Designing Web Usabilty: The Practice of Simplicity. v1. In: Java Spektrum (2000) Mai/Juni.: Die Geister. Indianapolis. Hapner M. New Riders Publishing.unilinz. 04/2001 [J2E99] The Java 2 Platform. O’Reilly.Tutorium zur Programmierung von Enterprise-JavaBeans. Enterprise Edition . James J. G. Schwinger. Enterprise Edition (J2EE). Gerti Kappel.1 vom 17.Literaturverzeichnis 126 [Har00] Gerhard Austaller.com. 1.ac.at/ifs/research/publications/papers00.html. die ich rief . Andreas Hartl.html. Köln. 1999 [Mon00] Monson-Haefel R.sun. W. V. http://java. München. Max Mühlhäuser. http://java. B. Bonn. Siegfried Reich. Palo Alto.Informationssysteme für E-Commerce. Reschitzegger. Kappl. Gulliver Beans: A Tool for Fine Tuning Data Delivery in ECommerce Applications Accepted for publication in: Proceedings EMISA 2000 . Auflage. 1999 [Mate99] Matena. Odell: Objektorientierte Modellierung mit UML. November 13th -16th.com/j2ee/ overview.ac.. 12.at/ifs/research/publications/papers00.ifs. Hitz: UML @ Work.: Enterprise JavaBeansTM Specification. 2000 Kyoto International Conference on Digital Libraries: Research and Practice. Kappl und M. 1999 [Mar99] James Martin. MITP–Verlag. Elisabeth Kapsammer. 1999 [Merk00] Merkle.html.: Enterprise JavaBeans. S. 47-52 [MID99] http://www.Overview. dpunkt.

Carl Hanser Verlag. Shannon: Java 2 Platform Enterprise Edition Specification. 2000 [Roß99] Peter Roßbach und Hendrik Schreiber: Java Server und Servlets. 2002 [XSC01] XML Schema: Formal Description. in: Gustav Pomberger und Günther Blaschek. 2.html. Auflage.de/iuk/glossar. Enterprise Edition. Sommerville: Software Engineering. 48.Literaturverzeichnis 127 [Pom96] Gustav Pomberger und Günther Blaschek: Software Engineering. Addison-Wesley. Addison–Wesley. Enterprise Java Beans. Software Engineering. http://www. [Sha01] B. http://www.w3. 1999 [Rom99] Ed Roman: Mastering Enterprise JavaBeans and the Java 2 Platform.springer. 2001 [Spr00] [Tse99] IUK–Glossar. 1996. 1985. 03/2001 Wichtige Begriffe der Call Center-Technik. John Wiley & Sons. Auflage. München.tse- hamburg.htm. S. Sun microsystems.de/Betriebsvereinbarungen/Material/ACDGlossar. W3C Working Draft. Kritische Betrachtungen zu einer modernen Software-Architektur. 2. Carl Hanser Verlag.org/TR/2001/WD-xmlschema-formal-20010320/ . München. München. http://www. Verlag Vieweg. James Robertson: Mastering the Requirements Process. Addison-Wesley. 03/2001 [WI0302] Wirtschaftsinformatik 44 (2002) 3. 1996 [Rob99] Suzanne Robertson. v1. 2nd edition. 20 March 2001. Seit 217-224. 1999 [Som85] I.3.

Anhang A 128 Anhang A Fragenkatalog .IstAnalyse für die market calling Marketing GmbH Prozessoptimierung für den Inbound – Bereich .

Unternehmensstruktur Market Calling 1.how) ? Herrscht ein intensiver Datenaustausch vor ? .1 Dienstleistungen des Market Calling • • Welche Dienstleistungen werden angeboten ? Wo liegen die Schwerpunkte (Inbound oder Outbound) ? 1.2 Filialen • • • Wo liegen die Standorte ? Wo ist die Zentrale ? Wo werden die meisten Interviewer beschäftigt ? 1.Anhang A 129 1.3 Abteilungen • • • • • Wie viele Mitarbeiter sind beschäftigt ? In welche Abteilung gliedert sich das Market Calling ? Sind die Abteilung hierarchisch oder flach gegliedert ? Kompetenzverteilung (wo liegt das know .

Geschäftsprozeß • Stimmt folgende Prozeßstruktur ? Aquirierung Annahme Spezifikation ReDesign Auftragssteuerung laufende Abwicklung (Interviews) Statistische Auswertung .Anhang A 130 2.

Dauer.1 Was beinhaltet diese Spezifikation • • • • • • Erhebung der Kundendaten ? Protokolle allgemein ? Auswertungen allgemein ? Informationsquellen für den Interviewer.) ? Wo wird das Protokoll abgelegt ? Zusendung an den Auftraggeber ? Welchen Weg geht das Protokoll durch das Unternehmen ? Wie häufig ändern sich Protokolle ? 2.3 Auswertungen • • • • • Welche Kategorien von Auswertungen gibt es ? Interne Auswertungen (Abrechnung. .) ? Kundenauswertungen ? Sind Auswertungen standardisierbar ? Wie geschieht die graphische Aufbereitung ? 2. Kundendaten. . (www. .2 Protokolle • • • • • • • Wie ist der Aufbau eines Protokolls ? Welche Fragestellungen gibt es. email.. Antworten ? Welche Daten werden immer aufgenommen (Uhrzeit..1.. Papier..) ? Verlangen Auftraggeber die Zustellung spezieller Datenformate ? 2..Anhang A 131 2..2 Auftragssteuerung • • • • • • Aufgabenverteilung Welcher Interviewer bearbeitet welche Kunden? Protokollentwicklung ? IT – Konfiguration ? Festlegen der Auswertungen ? Zustellung und Archivierung ? .) ? Wie erfolgt die Protokollzustellung (fax.) ? Wer entwirft diese Spezifikation ? 2.... bzw...1 Auftragsspezifikation • • Wie wird die Spezifikation entworfen (mündlich.1. print..1.

und Softwarestruktur • • • • • • • Telefonsystem ? Netwerkstruktur ? 10/100 Mbit ? fixe IPs ? Welche Plattformen sind vorhanden ? Internet vorhanden ? Zufriedenheit mit dem Netzwerk. Internetzugang (40 User!!) Welche Browser – Versionen sind in Verwendung ? Ist ein leistungsfähiger Server vorhanden ? 4.3 Laufende Abwicklung bzw. Hard.Anhang A 132 2. Unterschied Inbound – Outbound Welche unterschiede gibt es im Arbeitsablauf zwischen Inbound und OutboundBereich? . Datenfluss • Stimmt folgende Übersicht ? Interview IT Protokolle Graphische SPSS Aufbereitung spezielle Daten Bericht Bericht Protokolle Auftraggeber Ablage und Archiv 3.

Anbindung von Webdatenbanken. 7a.06/1992 Volksschule in Windhaag Hauptschule Windhaag Höhere technische Bundeslehranstalt für Elektrotechnik in Linz.jetzt Studium der Mechatronik an der JK Universität Linz Studium der Informatik an der JK Universität Linz Spezialisierung auf Webdatenbanken. Spezialisiert auf die Realisierung von Internetprojekten.07/1983 09/1983 – 07/1987 09/1987 . Paul-Hahn-Str.07.1973 Windhaag bei Freistadt Österreich ledig Schulische Ausbildung 09/1979 .Lebenslauf 133 Lebenslauf Allgemeine Daten zur Person Name: Anschrift: Geburtsdatum: Geburtsort: Staatsangehörigkeit: Familienstand: Dietmar Pointner Teistlergutstr.06/1993 10/1993 .. Berufliche Tätigkeiten 07/1988 08/1989 09/1992 08/1997 – 12/1999 12/1999 – jetzt Ferialpraktikum bei der Firma Elektro Pachner in Freistadt Ferialpraktikum bei der Firma ChemServ in Linz Computerarbeiten bei der Firma Marketingservice Linz Mitarbeit an einem Datenbank-Projekt für den oberösterreichischen Tiergesundheitsdienst Teilhaber der Firma XorteX-EDV. Webprogrammierung . 4040 Linz 07. Reifeprüfung im Mai 1992 Akademische Weiterbildung 10/1992 .

Sign up to vote on this title
UsefulNot useful