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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

wie ein HTML-Browser. Unter anderem ist Ziel des Entwurfs. Clients können verschiedene Ausprägungen einnehmen. Die Datenbankschicht repräsentiert eine relationale Datenbank.1 gibt einen Überblick über die Komponenten. die durch die J2EE definiert werden. . 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. dargestellt: • Der Client symbolisiert hier die Benutzerschnittstelle. clientseitig möglichst unabhängig vom installierten Betriebssystem zu sein. Einschränkungen hierbei sind. • • • Abbildung 3. welche je nach Performanceanforderungen ausgewählt werden muss. die in der J2EE-Architektur verwendet werden. Aus diesem Grund soll die Interaktion des Benutzers mit dem System über HTML-Browser erfolgen.1 Allgemeine Systemarchitektur J2EE Die allgemeine Systemarchitektur von J2EE ist von zentraler Bedeutung für den Systementwurf. Java Applet oder eine Java Applikation. die dem Benutzer zur Interaktion mit dem System bereitgestellt wird. Hier werden die verschieden Schichten.Die Java 2 Enterprise Edition 23 3. dass die Clients einen aktuellen HTML-Browser mit Unterstützung von DHTML und Javascript bieten.

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

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

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

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

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

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

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 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. 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. um Daten zu senden? Wird der Browsertyp des Clients unterstützt? etc. Erstellt eine zusammengestellte Ansicht von einzelnen Komponenten. ob die Anfrage weiterverarbeitet wird.1 Designvorlagen für die Präsentationsschicht 3. Dieses Pattern bietet eine Klassenstruktur. die unabhängig von den eigentlichen Worker-Klassen Anfragen bearbeitet und für die spätere Bearbeitung vorbereitet. wobei viele Aktivitäten zur Ansichtsverarbeitung weitergeleitet wird.1. Der erste prüft die Anfrage und entscheidet. die nicht zur Formatierung der Präsentation verwendet wird.1 Intercepting Filter Das Pattern Intercepting Filter bildet die erste Instanz. Verbindet eine Verwaltungskomponente mit dem Front Controller und dem View Helper Pattern. oder ob die Anfrage aufgrund eines Fehlers abgebrochen wird. Zwei Typen von Intercepting Filter existieren. Verbindet eine Verwaltungskomponente mit den Front Controller und dem View Helper Pattern. . Tabelle 3.4.

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

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

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

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

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

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

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.

Die Java 2 Enterprise Edition 40 Der Client fordert beim VOA Daten an.7 Service Locater Das Service Locator Pattern abstrahiert die JNDI Benutzung und versteckt die Komplexität des Findens von EJB-Komponenten.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. 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. Ein Value List Handler kann entweder als Java Objekt oder als Stateful Session Bean implementiert werden.2. 3. 3. Die Ausführung als Java Objekt wird nur dann empfohlen. der z. wenn kein EJB-Container für die Anwendung verwendet wird.4.2. Vorteile eines Service Locator Objekts sind: • • • • Wiederverwendung durch verschiedene Clients Reduzierung der Codekomplexität Kontrolle an zentraler Stelle Bessere Performance durch Cachefunktionalität . diese Daten werden vom VOA gesammelt und mit Hilfe eines Value Objects dem Client zurückgegeben. Ansonsten wird eine Session Bean zur Implementierung eines Value List Handlers empfohlen.4. Der Value List Handler präsentiert dem Client die Daten mit Hilfe eines Iterators. B.

Der Client benötigt nur die Information. 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.Die Java 2 Enterprise Edition 41 Abbildung 3. Die gesamte Komplexität des Zugriffs auf das JNDI-Interface wird von dem ServiceLocator-Objekt verborgen. .10 Sequenzdiagramm Service Locator Abbildung 3. ein Home-Objekt einer speziellen EJB) weiterarbeiten. Der Client fordert über eine Instanz der ServiceLocator-Klasse einen speziellen Dienst an.B. welchen Dienst er benötigt.

1 Data Access Object Ein Data Access Object (DAO) wird als Schicht zwischen der persistenten Datenhaltung und Komponenten wie Servlets.4. 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. 3.3 Designvorlagen für die Integrationsschicht Service Activator 3.Die Java 2 Enterprise Edition 42 3. bzw. da diese die Daten direkt über den Container erhalten.3.3 zeigt eine Auflistung aller in [Alu01] beschriebenen Vorlagen für die Integrationsschicht. Session Beans oder Beanverwaltete Entity Beans empfohlen. Stellt transparenten Zugriff auf Datenquellen zur Verfügung. .2 Service Activator Das Service Activator Pattern beschreibt einen Dienst.4.4. die durch eine Clientmessage aktiviert werden.3 Integrationsschicht Tabelle 3. auszuführen. Tabelle 3.3. Pattern Name Data Access Object Übersicht Abstrahiert Datenquellen. um asynchrone Aktionen. Ermöglicht asynchrone Ausführung von Diensten. ablegen.

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

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

Legende: Arbeitsschritt Arbeitsschrittübergang Die durch die Fragestellungen erarbeitete erweiterte Darstellung des Geschäftsprozesses sieht wie folgt aus: .Problemanalyse 45 Akquisition Annahme Spezifikation erstellen ReDesign Auftragssteuerung laufende Abwicklung (Interviews) Statistische Auswertung Abbildung 4.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. da die UML für die Besprechungen mit der Geschäftsführung kein geeignetes Mittel war.

(Abbildung 4. 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. für das eine Softwarelösung angestrebt wird. .2 Systemerhebung 4.2. Der Call Agent führt unter Aufsicht des Supervisors die Telefonate durch.1 Strukturanalyse Die folgenden Abschnitte sollen einen Überblick über das organisatorische Gefüge des Unternehmens. Die Verrechnung mit den Kunden und den Call Agents wird von der Buchhaltung übernommen. Inbound steht dabei für die Entgegennahme von eingehenden Anrufen. dass das Call Center bestimmte Personen anruft und Befragungen durchführt. Gemeinsam mit Mitarbeitern der EDV-Abteilung steuert der Supervisor den Auftrag.Problemanalyse 46 Abbildung 4.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. 4. Der Supervisor entwickelt dann die Auftragsspezifikation. geben. Outbound hingegen bedeutet. Das zu Entwickelnde Softwaresystem soll ausschließlich im Inboundbereich eingesetzt werden.2) Von Bedeutung für die Systemabgrenzung ist des weitern die Gliederung des Call Centers in die Bereiche Inbound und Outbound [Iuk00].

2. 4. Ziel ist es. Großes Augenmerk wird dabei auf Qualität gelegt. Direkt-Mailing. jedoch soll dies in absehbarer Zeit realisiert werden.1.Problemanalyse 47 4. dass dieses System für den Marktforschungsbereich konzipiert wurde und deshalb den Anforderungen eines Call Centers nicht gerecht wird. technischen und personellen Verflechtungen.) 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. Es ist derzeit noch keine klare Trennlinie der beiden Unternehmensbereiche erkennbar. 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. Meinungs. jeden Kundenwunsch zu realisieren.1 Unternehmensstruktur Das Unternehmen gliedert sich in die zwei Bereiche: • • die Markt-. Weiters ist das Call Center oft Auftragnehmers der Marktforschungsbereichs.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. Der Grund dafür liegt wohl darin..und Mediaforschung das Call Center Beide Bereiche sind eng miteinander verschachtelt.2. Dies zeigt sich in den räumlichen.1. .. .

Derzeitige Anzahl der Telefonarbeitsplätze: • • Linz: 38 Mühlviertel: 13 (derzeit nur Outbound .1. Weiters gibt es derzeit eine Filiale im Mühlviertel. Dies bedeutet. da diese Verteilung einem “Headquater–System“ mit Sitz in Linz gleicht und die Filialen untereinander vernetzt werden müssen. 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. das eine weite örtliche Verstreuung des Call Centers absehbar ist. Das bedeutet. . Buchhaltung hier ihren Sitz haben. Allerdings wird sich diese Struktur in nächster Zukunft ändern. 20) Dies stellt eine wesentliche Anforderung an das neue System. 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.Ausbau zu min.2.

. 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.4 Mitarbeiter Bezüglich der Mitarbeiter wurde an das Unternehmen nur die Frage über die Mitarbeiteranzahl gestellt. Die hohe Zahl an Teilzeitbeschäftigten bedingt ein ständiges “Kommen und Gehen“ von Angestellten.1.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. dass eine kurze Einschulungszeit ein wesentlicher Faktor ist.und Werktvertragsverhältinis: • • 360 externe Mitarbeiter Marktforschung 238 Mitarbeiter im Call Center Die Arbeitsrotation ist in einem 4-Schichten Betrieb eingeteilt.3 Filialstruktur mit Zentrale 4.2. Deshalb ist anzunehmen. Dies hat zur Folge. dass die EDV–Kenntnisse der einzelnen Mitarbeiter in ihrer Qualität weit gestreut sind.

2.5 Organigramm des Call Centers Da leider kein schriftliches Organigramm des Call Centers existierte.2. 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. Die Aufgabenanalyse lässt sich durch die in der Systemabgrenzung dargestellten Grafik (Abbildung 4.1..2) zusammenfassen. 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 . Abbildung 4.. um detaillierte Informationen zur Erstellung der Auftragsspezifikation zu erhalten: • • • • Wie wird die Spezifikation entworfen? (mündlich. 4.2 Aufgabenanalyse Um die Lesbarkeit der Ist-Analyse für den Auftraggeber zu erhöhen.) 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? .Problemanalyse 50 4.1 Erstellung von Auftragsspezifikationen Folgende Fragen wurden an das Unternehmen gestellt. wurden bei der Darstellung der Aufgaben (Operationen) die gleichen Bezeichnungen verwendet. etc. Als wichtige Aufgaben (Operationen) in Zusammenhang mit dem zu entwickelnden Softwaresystem konnten die Erstellung und Auswertung von Protokollen identifiziert werden.2.2. schriftlich. wie sie im Unternehmen intern verwendet werden.4 Organigramm 4.

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

B. etc. Protokolle gliedern sich in • Standardteil Informationen die immer erfasst werden müssen (z. Bearbeiter. Sie sind einer der Kernpunkte der laufenden Geschäftsabwicklung.: Uhrzeit. Suchen eines Protokolls.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.) Keine „Just in Time“–Zusendung der Protokolle an den Kunden (Berücksichtigung von “Nullmeldungen“ an den Kunden) Keine „Just in Time“–Erfassung der Anrufe . etc. Verrechnungsart. 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. 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.

Auftragsstatus geben sollen. Die eingegangenen Anrufe werden zunächst tabellarisch in Excel erfasst. 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.2.2. dass nicht alle Daten direkt am Bildschirm erfasst werden können.Problemanalyse 53 Dieser Teilprozess sollte nach Möglichkeit in einem Zug erledigt werden. 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. Da das Generieren der Auswertungen abhängig von der Verarbeitung der Protokolle ist. Über diese Erfassung werden dann Statistiken generiert. 4. Auftragseffizienz bzw.4 Verrechnungen Da die Automatisierung der Verrechnungen in der ersten Ausbaustufe der Softwarelösung nicht vorgesehen wurde. da sich im Gesprächsverlaufs ein völlig anderes Gesprächsbild ergeben kann. .2. Durch diese Methodik können speziell auf den Kunden zugeschnittene Auswertungen generiert werden. wurden in der Interviewphase auch keine detaillierteren Fragen zu diesem Thema gestellt. die Basis für die graphische Aufbereitung sind. Es ist zu berücksichtigen dass Auswertungen bis zu einem gewissen Grad standardisierbar sind. wobei zu berücksichtigen ist.3 Erstellen von Auswertungen Folgende Fragen wurden zum Bereich Auswertungen gestellt: • • • • • Welche Kategorien von Auswertungen gibt es? Gibt es auch Auswertungen. 4. die ihm einen Überblick über sein Auftragsvolumen.

und Ablaufanalyse 4. 4. Organisation und Management der Call-Agents.2) zusammenfassen.2. Kundenbetreuung und stellt gleichzeitig ein übergeordnetes Management dar. Der Supervisor vertritt gegenüber dem Kunden zweite Kompetenz.2.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. Sein Zuständigkeitsbereich liegt vor allem in Kundenbetreuung.und Kommunikationsfluss aufgrund der flachen Hierarchieebenen sehr wenig formalisiert ist und auch die Mitarbeiter nicht zwischen informellen und formellen Datenflüssen unterscheiden. Wesentliche Daten.3 Da in dem untersuchten Unternehmen der Informations.Problemanalyse 54 Grundsätzlich gibt es zwei Arten von Verrechnungen: Abrechnungen mit dem Kunden und Abrechnungen mit den Call-Agents. Des weiteren wurden die Interviewten nach dem Datenaustausch zwischen den Stellen detailliert befragt. Die Ablaufanalyse lässt sich durch die in der Systemabgrenzung dargestellte Grafik (Abbildung 4. . Die Abrechnung wird zuerst in Excel erfasst und anschließend in ein Spezialprogramm namens “Perfect“ eingegeben. 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. wurden diese beiden Punkte in einem Kapitel zusammengefasst. den jeweiligen Stellen die Kompetenzen und Aufgaben zuzuordnen. Sie ist zuständig für Kundenakquirierung. Folgendes Bild ergab sich: Die Geschäftsleitung stellt die erste Kompetenz gegenüber dem Kunden dar.3.

2 Auftragssteuerung Die erste Frage zur Auftragssteuerung betraf eine detaillierte Beschreibung der Aufgabenverteilung. für den Kunden auf. 4.und Mitarbeiterebene von Nöten. Wesentlich sind dabei Datensicherheit und Vermeidung von Inkosistenzen. 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.2. Der Mitarbeiter der EDV-Abteilung administriert das System und betreut das Netzwerk. unter Berücksichtigung des CD (Corporate Design) des Call Centers. Darüber hinaus ist seine Aufgabe vom Kunden benötigte Datenformate zur Verfügung zu stellen. Dies beinhaltet • • Zuteilung der Call-Agents auf die Kunden Verarbeitung von Feedbacks der Call-Agents . Für das neue System bedeutet dies.Problemanalyse 55 Der Call-Agent erfüllt die laufende Auftragsabwicklung wobei sie dem Supervisor immer wieder Feedback über den Status geben.3. Der Mitarbeiter der Buchhaltung führt Abrechnungen für die Mitarbeiter und Kunden durch. Der Mitarbeiter der Graphikabteilung bereitet die Auswertungen. dass alle Abteilungen Zugriff auf Daten benötigen und diese in jeweilig angepasster Form aufzubereiten sind. Alle Abteilungen benötigen Zugriff auf die verschiedensten Daten. Die Abteilungshierarchie ist sehr flach gehalten und es herrscht ein reger Informationsfluss zwischen den Abteilungen. Zu dem ist ein Zugriffssteuerung auf Abteilungs.

Win98 für die Call-Agents Weiters WinNT.Softwarestruktur Zur Bestandsaufnahme der vorhandenen Hard. Mac Internetanbindung: LiWest (KabelTV) .2. 1 Mac–Server wobei Novell das Hauptnetzwerk bildet Alle Clients mit fixen IP . 2 WinNt–Server.Server.Integration (Telephony Application Programming Interface). Netzwerk: • • • Leistungsstärke von 10/100MBit Netzwerkserver: 3 Novell . dem Stand der Zeit entsprechender Server vorhanden? Folgendes Bild der vorhandenen Hard. da sich das Anforderungsprofil des Auftrags während der Auftragsabwicklung ändern kann.3 Hard. 4.3.Problemanalyse 56 • Verarbeitung von Feedbacks der Kunden Die Auftragssteuerung obliegt einem ständigen Controlling und ReDesign. Für ein neues System bedeutet dies die Einbindung von Controllingverfahren und die Einbindung von durchdachten Administrationsmodulen.Adressen Plattformen der Clients: • • Win95.und Softwarestruktur konnte erhoben werden: Telefonanlage: Kapsch mit TAPI .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.

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

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

2. Die Länge der Auswertungen ist auftragsabhängig und schwankt zwischen 4 und 10 Seiten. Abhängigkeiten zwischen Daten: keine Auswertungen: • Datenvolumen: Auftragsabhängig wird wöchentlich oder monatlich für jeden Auftrag eine Auswertung erstellt. Erfassung der Protokolle durch die EDV und Archivierung in Ordnern) siehe Abbildung 4. 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.5 Die Archivierung von Protokollen in Ordnern ist uneffizient (Platzbedarf. Zusendung an den Kunden. Schwachstellenanalyse • • • • • • • 4. Zeitaufwand zum Suchen eines Protokolls. Art und Erfordernisse der Datensicherung: Backup Wachstum des Datenvolumens: In Zukunft ist eine Vergrößerung des Call Centers bis zum Faktor 5 geplant. Durchschnittlich sind 20 Auftraggeber pro Monat zu verzeichnen.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.) 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) • • • . etc. Abhängigkeiten zwischen Daten: Abhängig von Protokollen.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.

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-

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. Insbesondere ist es seitens des Call Centers wichtig. Dabei werden primär folgende Dienste angeboten: .2 Systemeinsatz und Systemumgebung Die zu entwickelnde Softwarelösung ist für den Einsatz im Inbound-Bereich vorgesehen. 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. 5. Im Rahmen der Systemspezifikation wurden keine Änderungen dieser beiden Punkte mehr vorgenommen. daher wird im folgenden nur mehr die Zielsetzung dargestellt. das vorhandene Know-how zur Verfügung zu stellen und geeignete Rahmenbedingungen zu schaffen.Systemspezifikation 63 5. eingehende Telefongespräche für den Kunden entgegenzunehmen. Die Aufgabe des Inbound-Bereichs ist es. welche von der Softwarelösung erfüllt werden sollen. 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. Wesentliche Punkte.1 Ausgangssituation und Zielsetzung Die Ausgangssituation und Systemabgrenzung wurde bereits in der Problemanalyse detailliert beschrieben.

Die Verrechnung mit den Kunden und den Call Agents wird von der Buchhaltung übernommen. Gemeinsam mit Mitarbeitern der EDV-Abteilung steuert der Supervisor den Auftrag. 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. (Abbildung 4. Weiters werden über die Gespräche Statistiken erzeugt und z. Der Supervisor entwickelt dann die Auftragsspezifikation.B. welches von den Interviewern als Gesprächsgrundlage zu verwenden ist.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. Für jedes Gespräch wird ein Protokoll ausgefüllt und zu definierten Zeitpunkten dem Kunden per Fax oder Email zugesandt. Die Legende dazu sieht folgenderweise aus: 5.2) .1 Übersicht Allgemeiner Geschäftsprozess Die Geschäftsleitung akquiriert beim Kunden Aufträge und schließt anschließend den Vertrag mit dem Kunden ab. ein mal pro Woche dem Kunden übermittelt.2. In den folgenden Diagrammen wird der allgemeine Geschäftsprozess sowie der ISTund Soll-Datenfluss dargestellt. Der Call Agent führt unter Aufsicht des Supervisors die Telefonate durch.

Systemspezifikation 65 5.2. In jeden Fall wird das elektronische Protokoll automatisch archiviert und es erfolgt eine automatisierte Weiterleitung an den Kunden. Wenn der Kunde spezielle Auswertungen oder Datenformate wünscht. so werden diese individuell von der Grafik und EDVAbteilung erstellt und dem Kunden übermittelt (Abbildung 5. 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. ob eine direkte elektronisch Erfassung möglich ist.1).1 Soll Datenflussdiagramm Idealer Weise nimmt der Call Agent den eingehenden Anruf gleich elektronisch auf. 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.2 Übersicht SOLL–Datenfluss Abbildung 5. Auch die Verrechnung mit dem Kunden und den Call Agents kann vom System automatisiert übernommen werden. .

Gruppen und Rollen verwalten können. 5.1. .Systemspezifikation 66 5. dass die Administration zentral ist und die Möglichkeit einer Fernwartung besteht.1 EDV-Administrator Die Gruppe EDV-Administratoren übernimmt verwaltungstechnische Aufgaben für das System. 5.3. die TCO (Total Cost of Ownership) zu verringern. Es eignet sich daher die Internettechnologie sehr gut. Dies stellt einerseits den modularen Aufbau des Systems dar und dient gleichzeitig als Schnittstellenbeschreibung für die interagierenden Benutzergruppen. Diese Lösung setzt voraus: • • • • Ein eigener Webserver Clients mit modernen Web–Browsern (Internet-Explorer ab Version 4. 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.1 Verwaltung der Mitarbeiter Der EDV-Administrator muss alle Benutzer. All diese Maßnahmen tragen dazu bei. Rollen sollen definiert und Benutzern und Gruppen zugeordnet werden können.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). um Teile des Einschulungsproblems und die Vernetzung von Filialen in den Griff zu bekommen. Eine rein webbasierende Lösung hat zu dem den Vorteil.3. Benutzer sollen bestimmten Gruppen zugeordnet werden könne.

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

..) ....3....Festlegen der Datenfelder .. Auftrag Gösser Gewinnspiel / Gösser Hotline / Röfix Tourismusverband Oberösterreoch / Röfix Sperren Gösser Gewinnspiel / Röfix / Tourismusverband Oberösterreich .3 Verwaltung der Call-Agents Dies beinhaltet die Zuteilung einzelner Call–Agents zu bestimmten Aufträgen.3 Call–Agent Die Call–Agents erledigen die laufende Auftragsabwicklung.1 Erfassen eines Gesprächsprotokolls • • • Abbildung des Gesprächsverlaufs in das elektronische Protokoll „Just in Time“ .. etc.3....Systemspezifikation 68 • • Anlegen eines neuen Auftrags zu einem Kunden Dies beinhaltet die Erstellung der Eingabemaske für einen Auftrag (Erstellung des elektronischen Protokolls) ...Festlegen des Datentypus (ja/nein.Echtzeiterfassung im System „Just in Time“ .4 Call–Agent / Auftrag Zuteilung 5.....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 • • • .3.Einbinden von Informationsquellen Ändern der Eingabemaske 5. text. 5. Abbildung 5... Diese beinhaltet im wesentlichen die Erfassung der Gespräche in die vom Supervisor vorgefertigten elektronischen Protokolle. Call-Agent Mayr Josef Huber Franz Heinz Ludwig .3...2.Festlegen des Begrüßungstextes für den Call Agent .. Optionsfeld.

5 Prototyp der Benutzerschnittstelle für den Call Agent 5. 5.3.Mühlviertel P.4. seinem Auftrag zugeordneten Protokolle einsehen.4 Kunde Jeder Kunde soll die Möglichkeit haben..3.05.05.00 15:53 Protokoll ProtokollNR FragebogenNr Tourismusverband .00/10:33 17.00/12:42 Abschließen in OP-Liste Löschen DM DM DM automatisiertes Fax / EMail System Kunde Abbildung 5.Systemspezifikation 69 Neues Protokoll Gösser Hotline Gewinnspiel Call-Agent Datum Uhrzeit Heinz Ludwig 17.2 Standardisierte Auswertungen Voraussetzung dafür ist. sich “Just in Time“ zu informieren.4.1 Protokollarchiv Der Kunde muss via Internet mittels Benutzername und Passwort Zugriff auf seine Auftragsdaten haben.IN01..05.05. Dies erfolgt durch Zugriff auf einen geschützten Bereich am Web-Server des Call-Centers (Protokollarchiv). dass sich das Call Center mit dem Kunden auf ein einheitliches Auswertungsschemata einigt.05.05.00/12:00 16. Die graphische Aufbereitung der Auswertungen . Offene Protokolle Gösser / Hotline 17.3.05.00/14:56 Adresse Firma Herr/Frau Land Plz Protokoll-Archiv Auftragsauswahl Ort Straße TelNr EMail 15. 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 .9810 1234567 info 50 % nicht verrechnet Begrüßungstext Tourismusverband Mühlviertel guten Tag. 5... Er kann alle. italienisch .00/10:42 16.00/11:45 Sonderwünsche Röfix / Hotline 17.

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

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

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

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

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

.org/docs/todo. Rollen für dieses System sind: • • Administrator Supervisor 2 http://industry. (*) teilweise Tabelle 6. wobei über eine Rollenzuordnungstabelle die Rollen für die einzelnen Benutzer festgelegt werden können.html 4 http://www.at. Als eine der zentralen Tabellen existiert die users-Tabelle.2. die SQL92-konform sind.postgresql.1 genannten Datenbanken. 6.. N .java. Diese Tabelle speichert alle Benutzer des Systems. 342f] entworfen.com/products/jdbc/drivers 3 http://www. verwendbar sein. Nein. Ja.3 Modell Das Datenmodell wird als Entity Relationship Modell [Mar99.com/development/todo.mysql.html .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 ..sun.1 Klassifikation von Datenbanken Das im Rahmen dieser Diplomarbeit entwickelte Softwareprodukt wird mit allen in Tabelle 6. Der Migrationsaufwand wird dabei gering sein..

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

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

email? . contact? ) . company? . tel? . protokoll_no .2 DTD eines Protokolls 6. <!ELEMENT general ( agent . question+ ) > Jedes Protokoll • • • beinhaltet generelle Information (general). hat mindestens eine Frage (question+). country? . calling_date . zip? . fax? . kann Kontaktinformationen beinhalten (contact?). calling_time .1 Elementbeschreibung der DTD <!ELEMENT protokoll (( general .Entwurf 78 Abbildung 6. town? . web? ) > Kontaktinformation besteht aus • • • • • Anrede (salutation?) Name (name) Firma (company?) Strasse (street?) PLZ (zip?) . name . street? .3. 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? .

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 ) . beinhalten einfachen Text (#PCDATA)* (parsed character data). caption ) > Fragen bestehen aus • • • • einer Überschrift bzw. 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+ . die nicht genauer Beschrieben wurden. 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. . choice? . choice* .

Entwurf 80 6.1 gezeigte Dokument Typ Definition erfüllt.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.2 Beispiel eines Protokolls Hier soll ein Beispiel eines Protokolls gezeigt werden.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> .acomp. <protokoll> <general> <agent>huber</agent> <protokoll_no>P01122222<protokoll_no> <calling_date>12.12.3.3.at</email> <web>www. dass die im Abschnitt 6.

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

Anzeige-Stylesheet Dieses Stylesheet wird für die Transformation des XML-Dokuments zu einer DetailAnsicht (HMTL) verwendet. Die grundlegende Funktion dieser Komponente ist die Transformierung eines XMLDokuments mit Hilfe eines XSL-Stylesheets zu einem Ausgabedokument. welche einem Benutzer zugewiesen werden können. 6. Tabelle 6. Über die Rollenzuordnungstabelle können dem Benutzer eine oder mehrere Rollen zugewiesen werden.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. Folgende Stylesheets werden entwickelt: Formular-Stylesheet Dieses Stylesheet wird für die Transformation des XML-Dokuments zu einem HTML-Formular verwendet. E-Mail-Stylesheet Dieses Stylesheet wird für die Transformation des XML-Dokuments zu einer E-Mail verwendet. .2 zeigt die Rollen.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.

Administration des Systems Kunden verwalten. Wichtige Anforderungen an dieses Berichtssystem sind: • • • Unterstützung von relationalen Datenbanken Veröffentlichung im Web Flexible Erstellung von Berichten .Entwurf 83 Rolle Administrator Supervisor Call Agent Management Grafik Buchhaltung Beschreibung Benutzer verwalten.3.5 Projektverwaltung Die Projektverwaltung dient dem Supervisor zur Koordination der einzelnen Projekte. das auf relationale Datenbanken aufbaut. Projekte verwalten .6 Auswertung für Kunden Wie in der Systemdefinition beschrieben (5.2 Mögliche Rollen eines Benutzers 6. Diese Funktionalität des Systems wird mit Hilfe eines Berichtssystems. Call Agents verwalten Protokolle erfassen Einsichtnahme in den Projektverlauf. 6. realisiert werden.4) soll der Kunde jederzeit Zugriff auf seine Protokolle und Auswertungen haben. 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. Statistiken Erstellen von Auswertungen für den Kunden Einsichtnahme in Informationsmaterial für die Buchhaltung Tabelle 6.

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

Sie stellen allgemeine Dienste. . Komponente User Project Protocol Schlüsselklasse und Value Object UsersKey UserVO ProjectKey ProjectVO ProtocolKey ProtocolVO Tabelle 6. Tabelle 6. ihre Schlüsselklassen und Value Objects Hilfskomponenten Hilfskomponenten sind Komponenten. die von den verschiedenen Schichten benötigt werden. Tabelle 6. 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.5 enthält die Komponenten und deren Beschreibung.4 zeigt die den Entity Beans zugeordneten Schlüsselklassen und Value Objects.3 Sessionfacades und ihre Businessmethoden Entity Beans Der Datenbankzugriff wird durch die Entity Beans User.4 Entity Beans. Die genaue Auflistung der persistenten Felddeklarationen wird im Kapitel 6. die von den oben genannten Session Facades und von der Präsentationsschicht verwendet werden. zur Verfügung. int limit):Enumeration updateProject(ProjectVO project):void deleteProject(String project_nr):void getProject(String project_nr):ProjectVO getProjectList(int limitstart.7.2 beschrieben.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. Project und Protocol durchgeführt.

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

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

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

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

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

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

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

An dritter Stelle liegt der Applikationsserver Sun One mit 7%.000.1 1.995.3 1.0.2 1.1 1.0.39.995.2 1.0 Server v7.2 Enterprise v6.1 1.1 Advanced V4.0 1.2 3.1 1. 2.1 zeigt einen Auszug jener Produkte aus dieser Matrix.10. Tabelle 7.000.000 15.1 Enterprise Pro JBoss JBoss v.2 1.1 zeigt die am weitesten verbreiteten Applikationsserver auf J2EEBasis.2 1.000.2 1. Teile von J2EE unterstützen.2 1.4.2 1.3 Werkzeuge und Plattform 7.0 EJB 2. welche die größte Marktverbreitung haben oder frei verfügbar sind.19.0.0.2 1.2 1.1 1.1. Hersteller Produkt Bea WebLogic Version Express v7.0 1.2 1.0.2 1.2 1.1 1.0.2 1.5 1.1 Enterprise v6.1 Application Server Comparison Matrix [FLA02] Abbildung 7. Diese sind der BEA WebLogic und IBM Websphere mit jeweils 34% vom Marktvolumen.1 Borland IBM Enterprise Websphere Server V5.000 10.0.0 JSP JMS J2EE Preis in US$ 1.2 1.1 2.2 1.2 1.1 IPlanet iPlanet Standard v6.2 1.1 Enterprise V4.Frei Frei Frei 995.995.0 1.0.000.2 1.2 1.1 1.35.5 Oracle 9i Application Standard Server Enterprise 1.2 1.2.1 1.2 1. Die restlichen Applikationsserver teilen sich 25% vom Marktvolumen [CZ2202].2 1.2 1.6 v3.1 1.1 v3.0.0 Lutris Enhydra v 3.0 Tabelle 7.20. Eine sehr guten Überblick über die verfügbaren Produkte und deren Eigenschaften gibt die Application Server Comparison Matrix [FLA02].0.Implementierung 93 7.1 1.1 1.2 1.2 1.3.1 1.000 35. die J2EE bzw.000.1 Applikationsserver Am Markt befinden sich verschiedenste Produkte.1 1.0. .0.0 1.0.12.

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

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

3 Auswahl des Applikationsservers Für die Auswahl des im Rahmen der Diplomarbeit verwendeten Applikationsservers sind folgende Kriterien wichtig: • • • standardkonform zu J2EE 1.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.4 Auswahl des Entwicklungswerkzeugs Für die Auswahl des im Rahmen der Diplomarbeit verwendeten Entwicklungswerkzeugs sind folgende Kriterien wichtig: • • • • • J2EE 1.Implementierung 96 Eine Integration von UML Modellierungs-Werkzeugen bietet mittlerweile auch fast jeder Hersteller. Hierbei nehmen die Werkzeuge von Rational und TogetherSoft eine herausragende Rolle ein. da die Entwicklungswerkzeuge von diesen Firmen aus der Entwicklung von UML Modellierungswerkzeugen hervorgegangen sind.3.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. Hierbei unterscheiden sich die verschiedenen Hersteller vor allem in den unterstützten UML Diagrammtypen. 7. Da die Referenzimplementierung von Sun durch die verschiedenen Entwicklungswerkzeuge am besten unterstützt wird. Da die verfügbare Demoversion eine Laufzeit von 30 Tagen hat.3. wird dieses Werkzeug für die Implementierung des Prototypen eingesetzt. wird für den Prototypen dieser Server eingesetzt. . 7.

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

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

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

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

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

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

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

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

bzw. falls Anfragen häufig übersetzt.2. andere müssen modifiziert. Ziel: Ein möglichst einfacher und dennoch leicht erweiterbarer Mechanismus zum Aufbereiten und Filtern einer Anfrage.1. die wiederum je nach Bedarf wiederverwendet werden können.1 beschriebene Architektur der Intercepting Filter beschreibt eine modularen Aufbau von Filterelementen. Dieses Pattern eignet sich vor allem. Einige Anfragen werden einfach an die zuständige Komponente weitergeleitet. nachbehandelt werden.bzw.4. bevor diese weitergeleitet werden können.Designrichtlinien 105 Antwortmöglichkeiten verwalten.1. 8.2 Front Controller Die Präsentationsschicht bearbeitet Anfragen und kontrolliert den Ablauf der Anwendung für jeden Benutzer des Systems. 3 1-2 einfach . Kontrollmechanismen können in einem zentralen oder dezentralen Prozess durchgeführt werden. geprüft oder dekomprimiert werden. 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. Problem: Eine Anfrage eines Web-Clients muss zur Weiterverarbeitung von mehreren Komponenten vor. überprüft werden müssen. Bewertung: Die im Abschnitt 3.

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

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

D. h. um auf Anfragen des Clients reagieren zu können. Auch wenn auf den ersten Blick die Struktur etwas kompliziert aussieht. soll dieses Pattern verwendet werden. Dieses Pattern beschreibt eine gängige Kombination aus Front Controller. 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. welche Antwort dem Client geliefert wird. Bewertung: Für Projekte.Designrichtlinien 108 Problem: Es wird eine durchgängige Systemstruktur in der Präsentationsschicht benötigt. ist für komplexe Anwendungen ein Vorlage für den gesamten Aufbau der Präsentationsschicht sehr gut einsetzbar. 3-N variabel komplex . Ziel: Ziel ist es. ist dieses Pattern zu bevorzugen. ist die Implementierung dieses Patterns naturgemäß komplex. Dispatcher. Da bei großen Projekten das Antwortveralten der Applikation sehr kompliziert sein kann. eine Vorlage für die Systemstruktur der gesamten Anwendung der Präsentationsschicht zu bieten. 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. die komplexe Entscheidungsmechanismen bezüglich Antwortverhalten benötigen.

eine Vorlage für die Systemstruktur der gesamten Anwendung der Präsentationsschicht zu bieten. Problem: Es wird eine durchgängige Systemstruktur in der Präsentationsschicht benötigt. Bewertung: Im Gegensatz zum Service to Worker soll dieses Pattern verwendet werden.5 Dispatcher View Das System kontrolliert den Arbeitsablauf und Datenzugriff. Auch hier ist wiederum zu sagen dass die verwendete Struktur doch sehr komplex anmutet. Da aber die angeforderten Informationen direkt in der URL kodiert sind.2. 3-N variabel einfach . ist die Weiterleitung an die benötigten Views ein eher einfaches Problem. Dispatcher. Ziel: Ziel ist es. 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. Dieses Pattern beschreibt eine gängige Kombination aus Front Controller. 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. von welchen es eine Präsentation der Daten generiert. um auf Anfragen des Clients reagieren zu können. hinsichtlich Erweiterbarkeit und Wartbarkeit ist diese Vorlage aber auf jeden Fall zu empfehlen. falls das Antwortverhalten der Applikation ein eher einfaches ist. Dispatcher.Designrichtlinien 109 8. Views und View Helper Komponenten. Views und View Helper Komponenten.1. Dieses Pattern beschreibt eine gängige Kombination aus Front Controller.

1 Business Delegate Das Business Delegate Pattern dient zur Entkopplung der Präsentationsschicht von der Businessschicht. Ziel: Durch die Implementierung des Business Delegate Patterns soll das oben beschriebene Problem gelöst werden. das schwierig zu Warten ist. . Durch die Zusammenfassung von komplexen Abläufen durch nur einen Methodenaufruf wird der Zugriff der Präsentationsschicht auf die Businesslogik vereinfacht.Designrichtlinien 110 8.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.2. Nur so kann der spätere Wartungsaufwand möglichst gering gehalten werden. Änderungen an der Businesslogik erfordern nur Änderungen in der Business Delegate Komponente. nicht aber in der Präsentationsschicht. Problem: Durch die direkte Kopplung der Präsentationsschicht mit der Businessschicht (Direkter Zugriff der Präsentationsschicht auf Komponenten der Businesslogik) entsteht ein System.2. Bewertung: Die Entkopplung der verschiedenen Schichten durch speziell dafür vorgesehene Komponenten ist wichtig.2. da Änderungen in der Businesslogik auch Änderungen in der Präsentation erfordern.

h.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. Bewertung: Durch die Notwendigkeit der Reduzierung der Netzwerkkommunikation muss dieses Pattern häufig eingesetzt werden. 8.Methoden kann die Netzwerkkommunikation verringert werden. Ziel: Durch die Zusammenfassung mehrere atomarer Elemente mit Hilfe von Value Objects und dazugehöriger Set . das der Zugriff auf 3 3 einfach .2. Get . Problem: Beim Zugriff auf die Daten von Entity-Beans erfolgt bei jeder Datenanforderung ein RMI-Aufruf. Durch die Zusammenfassung von komplexen Abläufen in der Businesslogik wird zudem der Zugriff der Präsentationsschicht auf die Businessschicht erleichtert. Durch diesen hohen Kommunikationsaufwand können Probleme hinsichtlich Performanz auftreten. D.bzw. aufgrund des technischen Umstandes. 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.2 Value Object Value Objects dienen zur Kommunikation zwischen Komponenten und Schichten.2. da die Art und Weise der Interaktion der verschiedenen Komponenten einfach zu Verstehen ist. welcher einen dementsprechend hohen Netzwerkkommunikationsaufwand erfordert.

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

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. Daten die voneinander abhängig sind als Ganzes in eine Entity Bean zu sammeln. Problem: Die direkte Abbildung des Datenmodells auf Entity Beans führt zu einer feinkörnigen Struktur der Entity Beans. Dies fordert eine hohe Anzahl an Remote Referenzen und Interaktionen zwischen den einzelnen Beans. 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 .4 Composite Entity Das Pattern Composite Entity beschreibt eine Möglichkeit. ist die Session Facade zu empfehlen. in denen verschiedene Teilsysteme getrennt werden können. Die Zusammenfassung komplexer Teilsysteme führt zu einem leichter wartbaren Code.2. 8. Die dadurch entstehenden Vorteile rechtfertigen den Aufwand der Implementierung dieser Komponente. da die Art und Weise der Interaktion der verschiedenen Komponenten einfach zu verstehen ist.Designrichtlinien 113 Bewertung: Bei komplexen Anwendungen.2.

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

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

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

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

Problem: Viele J2EE Anwendungen verwenden verschiedene Datenquellen wie relationale Datenbanken. Dateien.1 Data Access Object Das Data Access Object abstrahiert und kapselt den Zugriff auf persistente Datenquellen. etc. von den Datenquellen abstrahierten Zugriffs auf persistente Datenquellen verringert sich die Abhängigkeit von Logik und Daten. Durch den direkten Zugriff von J2EE Komponenten auf diese Datenquellen entsteht eine direkte Abhängigkeit der Komponenten zu diesen Daten.3.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. Die Verwendung verschiedener Datenquellen erfordert verschiedene Implementierungen für den Zugriff auf diese Daten. Durch die Implementierung dieses Patterns verringert sich in den anderen Komponenten die Implementierung der JNDI Aufrufe maßgeblich.2. 8.2. objektorientierte Datenbanken. Im Buch [ALU01] werden für die Implementierung verschieden Vorlagen geboten. . die man als Basis für einen Service Locator verwenden kann. 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.

komplex . Dies ist nur über das JMS API möglich. die die Persistenzverwaltung nicht vom Container verwalten lassen. 8.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. ist ein DAO zu empfehlen. und wird nicht von der EJB-Spezifikation festgelegt. Je nach Implementierung kann diese auch aufwändig sein. Der Hauptvorteil ergibt sich durch die Trennung von Logik und Datenhaltung. Komponenten. Die in EJB 2. Bei Applikationen bzw.2.Designrichtlinien 119 Bewertung: Bei Verwendung eines DAO kann der Datenzugriff nicht mehr vom EJB-Container verwaltet werden. Problem: Clients möchten Dienste von EJB-Komponenten asynchron aktivieren. Der asynchrone Zugriff auf Stateful Session Beans oder Entity Beans ist nicht vorgesehen.0 eingeführten Message Driven Beans können nur als Stateless Session Bean implementiert werden. 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. 2 2 einfach .

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

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

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

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

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

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

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

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

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

1 Dienstleistungen des Market Calling • • Welche Dienstleistungen werden angeboten ? Wo liegen die Schwerpunkte (Inbound oder Outbound) ? 1. Unternehmensstruktur Market Calling 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 .2 Filialen • • • Wo liegen die Standorte ? Wo ist die Zentrale ? Wo werden die meisten Interviewer beschäftigt ? 1.how) ? Herrscht ein intensiver Datenaustausch vor ? .Anhang A 129 1.

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

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

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

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.06/1992 Volksschule in Windhaag Hauptschule Windhaag Höhere technische Bundeslehranstalt für Elektrotechnik in Linz.07. Webprogrammierung . 7a. Spezialisiert auf die Realisierung von Internetprojekten.1973 Windhaag bei Freistadt Österreich ledig Schulische Ausbildung 09/1979 .07/1983 09/1983 – 07/1987 09/1987 . Anbindung von Webdatenbanken. Reifeprüfung im Mai 1992 Akademische Weiterbildung 10/1992 . Paul-Hahn-Str. 4040 Linz 07.jetzt Studium der Mechatronik an der JK Universität Linz Studium der Informatik an der JK Universität Linz Spezialisierung auf Webdatenbanken..Lebenslauf 133 Lebenslauf Allgemeine Daten zur Person Name: Anschrift: Geburtsdatum: Geburtsort: Staatsangehörigkeit: Familienstand: Dietmar Pointner Teistlergutstr.