1 Anforderungsanalyse - Kontoverwaltung

Advanced Software Engineering Übung, LVNr:
Übungsleiter: Ivona Brandic
Dokument: Beispiel 1 v.1.6
Projekttitel: Kontoverwaltungssystem
Gruppenmitglieder:
MatNr:
a0102290
a0000378
Nachname:
Zohmann
Remely
Vorname:
Christian
Günther
e-mail:
[email protected]
[email protected]
Datum: 04.11.2006
1
1 Anforderungsanalyse
1.1 Kurzbeschreibung
Es soll eine 3-tier Internetapplikation erstellt werden. Für die Realisierung der serverseitigen
Komponenten soll Java EE, EJB 3.0 und JBoss verwendet werden. Zur Speicherung der Daten
wird eine MySQL Datenbank verwendet die mittels JDBC angesprochen wird. Das client-seitige
User Interface wird sowohl in JSP als auch mittels JavaServlets realisiert. Ein Interface wird zum
auslesen der Daten verwendet, das andere zum einlesen der Daten Die User-Interfaces müssen
browserfähig sein.
Das Kontoverwaltungssystem dient zur Verwaltung von Bankkonten. Mit Hilfe des
Kontoverwaltungssystems soll es dem registrierten Benutzer ermöglicht werden mittels eines
Web-Browsers im Internet, Geldbeträge elektronisch von einem Konto auf das Konto eines
anderen registrierten Benutzers zu überweisen. Bei der Gestaltung der Benutzeroberfläche wird
ein besonderer Wert darauf gelegt, dass sie möglichst einfach aufgebaut ist und dadurch intuitiv
benutzbar wird. Gespeichert werden die gesamten Kunden- und Kontendaten zentral in einer
MySQL-Datenbank.
Das Kontoverwaltungssystem soll folgende Funktionen ermöglichen:





Benutzer einloggen/ausloggen
Kontostand abfragen
Online Kontoauszug
Konto Einzahlung/Auszahlung
Beträge auf ein Konto eines anderen Users überweisen
1.2 Funktionale Anforderungen
1.2.1 Beschreibung der Funktionalität
Wie bereits unter Punkt 1.1. erwähnt soll das Kontoverwaltungssystem einem Kunden auf
einfachem Weg elektronische Geschäftstransaktionen ermöglichen. Nach erfolgreicher
Registrierung hat der Kunde die Möglichkeit sich in das Kontoverwaltungssystem einzuloggen.
Erst nach dem Login stehen ihm die wesentlichen Funktionen unseres Systems zur Verfügung.
Der Benutzer hat die Möglichkeit den Kontostand abzufragen, sich den Kontoauszug online
anzusehen, Einzahlungen sowie Auszahlungen zu veranlassen und Geld auf ein anderes Konto
zu transferieren. Bei Missbrauch des Kontos kann dies vom Kunden zur jeder Zeit gesperrt
werden.
Um einen besseren Überblick der Funktionalität zu ermöglichen, soll das folgende Use Cases
Modell und deren Beschreibungen, die Funktionen des Kontoverwaltungssystems erörtern.
2
Use Case: login
Ziel:

User ins System einloggen
Kategorie:
 primär
Vorbedingung:
 User muss registriert sein
Nachbedingung bei Erfolg:
 User kann auf Funktionen der Kontoverwaltungssystems zugreifen
3
Nachbedingung bei Fehlschlag:
 User nicht eingeloggt (falsche Passwort, falscher Username)
 Fehlermeldung am Bildschirm ausgeben
Akteure:
 User
Use Case: Kontostand abfragen
Ziel:

Bekanntgabe des aktuellen Kontostandes
Kategorie:
 primär
Vorbedingung:
 User muss eingeloggt sein
Nachbedingung bei Erfolg:
 Ausgabe des aktuellen Kontostandes am Bildschirm
Nachbedingung bei Fehlschlag:
 Fehlerausgabe am Bildschirm
Akteure:
 User
Use Case: Online Kontoauszug
Ziel:

Ausgabe der getätigten Geldüberweisungen
Kategorie:
 primär
Vorbedingung:
 User muss eingeloggt sein
Nachbedingung bei Erfolg:
 Buchungszeilen ausgeben
Nachbedingung bei Fehlschlag:
 Fehlerausgabe am Bildschirm
Akteure:
 User
4
Use Case: Geld überweisen
Ziel:

Elektronisches Geld von einem Konto auf ein anderes Konto überweisen
Kategorie:
 primär
Vorbedingung:
 User muss eingeloggt sein
Nachbedingung bei Erfolg:
 Geld wird vom überweisendem Konto abgezogen und auf das Konto des Empfängers
gutgeschrieben
 Abzug des zu überweisenden Betrages am Konto des Senders
 Erhöhung des Kontotandes auf Seiten des Empfängers
Nachbedingung bei Fehlschlag:
 Falscher Tan
 Ausgabe am Bildschirm
Akteure:
 User
Use Case: Geld Einzahlung
Ziel:

Geld auf das eigene Konto überweisen
Kategorie:
 primär
Vorbedingung:
 User muss eingeloggt sein
Nachbedingung bei Erfolg:
 Erhöhung des Kapitalstandes am Konto
Nachbedingung bei Fehlschlag:
 Fehlerausgabe am Bildschirm
Akteure:
 User
Use Case: Konto Auszahlung
Ziel:


Geld vom eigenen Konto abbuchen
(z.B. Abhebung am Bankomat)
Kategorie:
 primär
5
Vorbedingung:
 User muss eingeloggt sein
Nachbedingung bei Erfolg:
 Verringerung des Kapitalstandes am Konto
Nachbedingung bei Fehlschlag:
 Fehlerausgabe am Bildschirm
Akteure:
 User
1.2.2 Bedienungsoberfläche
Das Programm soll den Benutzer auf möglichst schnelle Weise ermöglichen, die Funktionalität,
die er benötigt, aufzurufen. Dies erfordert klarerweise eine leichte Bedienbarkeit. Es soll nicht der
Fall sein, dass ein Benutzer beispielsweise über umständliche Menüstrukturen oder ein paar
Linkebenen tiefer erst die Aufgabe realisieren kann, die er beabsichtigt.
Die Bedienungsoberfläche wird innerhalb eines Webbrowsers dargestellt. Die folgenden zwei
Abbildungen zeigen, wie die Bedienungsoberfläche im Internet Explorer dargestellt wird. Das
erste Fenster zeigt eine Bedienungsoberfläche, welche mittels eines Servlets generiert wird. Das
zweite Fenster, welches nach einem erfolgreichen Login erreicht wird, wird mittels einer JSP
Seite generiert.
6
1.3 Nichtfunktionale Anforderungen
Nichtfunktionale Anforderungen sind Anforderungen, die nicht unmittelbar zur Funktionalität eines
Software-Systems gehören. Dennoch können nichtfunktionale Anforderungen genauso kritisch
für den Erfolg eines Systems sein wie die funktionalen Anforderungen.
 Korrektheit
Die programmtechnische Umsetzung unserer Anforderungen sollen vollständig und fehlerfrei
umgesetzt werden. Somit soll sichergestellt werden, dass das Programm korrekt läuft. Im
Allgemeinen kann nicht sichergestellt, dass unsere Software vollständig fehlerfrei läuft.
Dennoch soll versucht werden, eine große Anzahl an Fehlern zu vermeiden. Um dies zu
gewährleisten, versuchen wir einerseits Fehler von vornherein zu vermeiden durch z.B.
offene Kommunikation, gut dokumentiertem Code, JUNIT Tests.
 Robustheit
Unsere Software soll alle möglichen Eingaben des Users annehmen können. Auch auf
falsche Eingaben muss die Applikation sinnvoll reagieren. Es darf nicht passieren, dass das
Programm bei irgendwelchen Eingaben abstürzt. Weiters soll nach Fertigstellung eines
Prototyps durch verschiedene und ausführliche Tests verschiedene Eingaben des Users
überprüft werden. Bemerken wir, dass ein Programmzustand nicht beachtet wurde, so muss
die Behandlung dieses Falles implementiert werden.
 Benutzbarkeit
Das Kontoverwaltungssystem soll intuitiv benutzbar sein. Das heißt, es soll für den User, der
ein Konto hat und mit dem Tätigen von Transaktionen vertraut ist, ohne viel
Erklärungsaufwand klar sein, wie das System zu benutzen ist. Dies wird erreicht durch eine
einfache Organisation der Homepage und durch die Verwendung bankengerechter Termini.
Bei eventuellen Fehleingaben des Users (z.B. nicht vorhandene Kontonummer) wird der User
vom Kontoverwaltungssystem darauf aufmerksam gemacht.
 Performance
Das Kontoverwaltungssystem soll ein gutes Zeit- und Verbrauchsverhalten aufweisen, d.h.
das System soll schnell auf Benutzereingaben reagieren (Reaktionszeit < 1 Sekunde). Zu
beachten ist jedoch, dass die vom Nutzer wahrgenommene Antwortzeit auch wesentlich von
zentralen Komponenten der produktiven Umgebung abhängen wie z.B. der
Internetanbindung (Transferzeit).
 Widerverwendbarkeit
Dieses Kriterium besagt, inwieweit ein Softwaresystem oder ein Teilsystem in anderen
Softwareprodukten wieder verwendet werden kann. Auf der Designebene soll es ermöglichen
andere Funktionalitäten oder Softwareprodukte auf Basis des Designs unserer Applikation zu
erweitern. Um die Widerverwendbarkeit des Designs zu gewährleisten, müssen unsere
Diagramme klar verständlich und übersichtlich sein. Daher soll in den Diagrammen gerade
soviel Information vorhanden sein, dass es noch übersichtlich bleibt.
 Sicherheit & Vertraulichkeit
Es wird derzeit keine Realisierung von kryptografischen Eigenschaften geben. Die einzige
Sicherheitsvorkehrung die wir in unserem System einbauen ist die Überprüfung auf
Vorhandensein des Usernamens und Passwortes in der Datenbank, sowie die
Zusammengehörigkeit von Namen und Passwort. Es kommt zu keiner Verschlüsselung von
Datenübertragungen.
7
2 Architektur & Design
2.1 Architekturüberblick
 Client Tier
Ein Web Browser übernimmt die Rolle des Client Tiers. Getestet wurde das
Kontoverwaltungssystem mit dem Internet Explorer 6.0 und dem Mozilla Firefox 2.0.
Aufgerufen wird das Kontoverwaltungssystem im Web Browser über
http://localhost:8080/KontoClient/LoginServlet (lokal)

Middle Tier
 Web Container Tier
Der Web Container Tier umfasst einerseits ein Servlet (LoginServlet.java) und eine
JSP Seite (Uebersicht.jsp). Beim Aufruf des Kontoverwaltungssystems (siehe Link
oben) wird zuerst das Servlet aufgerufen. Nach erfolgreicher Anmeldung wird an die
JSP Seite weitergeleitet, welche die restliche Funktionalität zur Verfügung stellt.
 Business Logic Tier
Hier wird der reibungslose Ablauf der Geschäftslogik durch den Einsatz der
relevanten EJB’s (sichergestellt.

DB Tier
 Wie in der obigen Grafik zu sehen ist, kommt es beim Kontoverwaltungssystem
zum Einsatz von MySQL. In der Datenbank werden die für die Geschäftslogik
notwendigen Daten persistent gespeichert.
8
2.2 Klassendiagramme
Das Kontovewaltungssystem besteht aus 3 Teilen:
 Serverpacket
 Interface
 Client
Das Serverpacket besteht aus den Klassen Server, Benutzer und Ueberweisung.
Das Interfacepacket besteht aus der Interfaceklasse IServer
Das Clientpacket besteht aus den JSP und Servletseiten
2.2.1 Serverpacket
Die Serverklasse ist die Stateful Sessionbean Klasse. Mittels dieser Klasse wird es ermöglicht
Überweisungen, Einzahlung und Auszahlungen zu machen. Login und Kontoauszug sind weitere
Funktionalitäten die diese Klasse zur Verfügen stellt. Die Klassen Benutzer und Ueberweisung
sind die Entitybean Klassen. Diese Klassen sind sozusagen eine Spiegelung der
Datenbanktabellen. Mithilfe des Entitymanagers wird über diese Klassen in die Datenbank
geschrieben.

Server
Extends: Implements: IServer
Wichtige Klassenvariablen
o protected Benutzer benutzer
o protected Ueberweisung ueberweisung
o protected EntityManager em
o public String myDriver
o public String myUrl
o public String myUser
o public String myPass
Funktionalität:
Mit dieser EJB „Stateful Sessionbean“ Klasse wird es dem Benutzer ermöglicht,
Geld auf sein Konto ein uns auszuzahlen, sowie auch eine Überweisung von
9
einem Konto auf ein anderes. Um eine Übersicht von allen Transaktionen eines
Benutzers zu bekommen kann mit der Methode „kontoauszug“ alle
Überweisungen angezeigt werden. Der Kontostand kann ebenfalls ausgeben
werden.

Benutzer
Extends: Implements: Serializable
Wichtige Klassenvariablen
o private String name
o private String passwort
o private int kontonummer
o private double kontostand
Funktionalität:
Diese EJB „Entity“ Klasse ist ein Abbild des jeweiligen Tabels in der Datenbank.
Mittels dieser Klasse wird es ermöglicht in die Datenbank zu schreiben, bzw. aus
der Datenbank auszulesen

Ueberweisung
Extends: Implements: Serializable
Wichtige Klassenvariablen
o private int sender
o private int empfaenger
o private String verwendungszweck
o private double betrag
o private int id
Funktionalität:
Diese EJB „Entity“ Klasse ist ein Abbild des jeweiligen Tabels in der Datenbank.
Mittels dieser Klasse wird es ermöglicht in die Datenbank zu schreiben, bzw. aus
der Datenbank auszulesen
2.2.2 Interfacepacket
Die Interfaceklasse IServer stellt eine Verbindung zwischen Client und Server her. Mittels dieser
Klasse kann der Client Methoden des Servers aufrufen

Ueberweisung
Extends: Remote
Implements: Funktionalität:
ReservierungsServer stellt das Interface dar, anhand dessen Client Methoden
„remote“ aufgerufen werden können.
2.2.3 Clientpacket
Das Clientpacket besteht aus den verschiedenen JSP und Servletklassen. Mit diesen Klassen
wird es dem User ermöglicht über einen Browser die verschiedenen Funktionen (Methoden) des
Servers aufzurufen.
10
2.3 Beschreibung der Interfaces
Beschreibung siehe Punkt 2.2.2 Interfacepaket
11
Implementierung
2.4 Paketdiagramme
2.5 Komponentendiagramme
2.6 Deployment-Diagramme
12
3 Datenspeicherung & Zugriff
Um die Daten zu Speichern wird eine MySQL Datenbank verwendet, die unter:
www.swe.geschenkestube.at/mysqladmin erreichbar ist.
3.1 Datenbankmodell (ERD-Modell)
ÜBERWEISUNG
BENUTZER
1
n
Im Table BENUTZER werden die Daten des Users gespeichert. Dabei handelt es sich um den
Namen, Passwort, Kontonummer und Kontostand. Jeder Benutzer kann mehrer Überweisungen
tätigen.
Im Table ÜBERWEISUNG wird die Kontonummer des Senders und Empfängers, der
Verwendungszweck und der zu überweisende Betrag gespeichert.
3.2 Datenzugriff 1 (z.B. JDBC)
Der Datenzugriff läuft immer nach einem festgelegten Schema fest und kann in folgende Phasen
aufgeteilt werden
1. Herstellen der Verbindung zu einem DBMS
 Treiberklasse laden (z.B. Class.forName("com.mysql.jdbc.Driver"); )
 Aufbau der Verbindung zum DBMS ( getConnection (String url, String user, String
password)
2. Absetzen eines SQL-Statements
 Für eine geöffnete Verbindung können mehrere Statements erzeugt werden
 Jedes SQL-Statement wird dabei durch ein Objekt realisiert, das die Schnittstelle
java.sql.Statement implementiert: Statement stmt=con.createStatement();
 Mögliche Abfrage: ResultSet rs=stmt.executeQuery("Select Name from Benutzer");
3. Auswerten des Ergebnisses
 Generell kein Problem, da Methode executeUpdate() lediglich einen einfachen intWert zurückliefert
 Ein wenig komplizierter ist die Auswertung eines SELECT-Befehls der mit der
Methode executeQuery() agbesetzt wird: Rückgabewert vom Typ ResultSet
4. Schließen des SQL-Statements
5. Schließen der Verbindung
 Dafür bietet die Schnittstelle Connection die Methode close() an
13
3.3 Datenzugriff 2 (z.B. Java Persistance API)
Mittels der EJB 3.0 Entity Beans ist es ebenfalls möglich auf relationale Datenbanken
zuzugreifen. Aus der Sicht des Programmierers verschwindet hier die Lücke zwischen der
Struktur eines Java Objekts in der Anwendung und der Struktur der in der relationalen DB
gespeicherten Daten. Das heißt, dass das Mapping von einem Benutzer der Java Klasse
Benutzer auf den Benutzer, der in der Datenbank gespeichert ist, wird automatisch vom EJB
Container bewerkstelligt. Vorraussetzung ist es die Java Klasse Benutzer als Entity Bean Klasse
(@Entity) zu erstellen. Folgender Zusatz @Table(name = "Benutzer") teilt dem Container den
Namen der Tabelle in der relationalen Datenbank mit. Die Instanzvariablen der Entity Bean
Klasse werden vom EJB Container defaultmäßig zu den Spalten in der DB gemapped. Mit @Id
kann ein Attribut welches den Primärschlüssel stellt, gekennzeichnet werden.
Da die EJB 3 Entity Beans lediglich POJOs (Plain old java objects) darstellen, können sie mittels
des keywords „new“ instanziert werden. Um aber nun die Speicherung und den Zugriff auf die
Objekte zu gewährleisten, wird ein EJB 3.0 EntityManager gebraucht. In unserem Fall wird dies
folgendermaßen erreicht
@PersistenceContext(unitName="Konto")
protected EntityManager em;
Die EntityManager.persist() Methode ermöglicht es eine Entity Bean Instanz in der
Datenbank zu speichern. Die EntityManager.find() Methode hilft nun die gewünschten
Daten aus der Datenbank zu lesen und sie als Java Objekt zur Verfügung zu stellen. Um die
verschiedensten Arten von Anfragen auf die DB zu machen, steht die EJB Query Language (EJB
QL) zur Verfügung.
Um die Entity Beans ausführen zu können, werden sie in ein JAR File gepackt. Die Funktionalität
kann nur gewährleistet werden, wenn auch ein persistence.xml im META-INF Verzeichnis
vorhanden ist und richtig konfiguriert wurde. Ein weiters File wird im Deploy-Verzeichnis des
Application Servers erwartet. Das mysql-dm.xml File verwaltet die Information für den
Verbindungsaufbau zur gewünschten Datenbank. Diese Information beinhalten die URL der
Datenbank und Zugangsdaten wie Username und Passwort um auf die Datenbank zugreifen zu
können.
3.4 Vergleich zwischen Datenzugriffmethode 1 und
Datenzugriffmethode 2
Ein wesentlicher Unterschied zwischen der Datenzugriffmethode 1 (JDBC) und der
Datenzugriffmethode 2 (Java Persistance API) ergibt sich bei der Verwaltung der
Datenanbindungsdaten. Bei der Datenzugriffmethode 1 werden diese Daten (wie z.B. URL der
DB und Zugangsdaten) direkt in die Java Klasse geschrieben, im Gegensatz dazu werden diese
Daten bei der Datenzugriffmethode 2 zentral in einem File (mysql-dm.xml) verwaltet. Das heißt,
dass in diesem File die Zugangsdaten zu mehreren verschiedenen Datenbanken gleichzeitig zur
Verfügung gestellt werden können.
Die Datenzugriffmethode 2 wirkt um einiges intuitiver als die Datenzugriffmethode 1, da der
Zuggriff über die Java Persistance API dem objektorientierten Konzept von Java entgegenkommt.
Die Speicherung, Aktualisierung und das Laden von Objekten einer Entity Bean Klasse stellt
keinen großen Aufwand mehr da. Bei Datenbankabfragen (JDBC) kommt es zum Einsatz der
SQL Query Language. Bei der Datenzugriffsmethode 2 kommt die EJB Query Language zum
Einsatz.
14
4 Test
Das Kontoverwaltugngssystem wurde mit Hilfe von JUnit getestet. JUnit ist ein Framework zum
Testen von Java-Programmen, das besonders für automatisierte Unit-Tests einzelner Units
(meist Klassen oder Methoden) geeignet ist. Es basiert auf Konzepten, die ursprünglich unter
dem Namen SUnit für Smalltalk entwickelt wurden. Ein JUnit-Test kennt nur zwei Ergebnisse:
Entweder der Test gelingt (dann ist er „grün“) oder er misslingt (dann ist er „rot“). Das Misslingen
kann als Ursache einen Fehler (Error) oder ein falsches Ergebnis (Failure) haben, die beide per
Exception signalisiert werden.
4.1 Test Suite
Die Klassen Server, Uberweisung und Benutzer wurden mit Hilfe von JUnit auf richtige
Funktionalität getestet.
Folgende Methoden der Klassen wurden getestet:
Server:
o public void testLogin()
o public void testGetBenutzername()
o public void testGetKontostand()
o public void testKontonummerVorhanden()
Benutzer:
o public void testGetPasswort()
o public void testGetKontonummer()
o public void testGetKontostand()
Ueberweisung:
o public void testGetSender()
o public void testGetEmpfaenger(
o public void testGetVerwendungszweck()
o public void testGetBetrag()
o public void testSetNewSender()
4.2 Test Case 1 (Server)
Mit Hilfe der Annotation „@Before“ wird zuerst die setUp() Methode aufgerufen, die einen Lookup
zum Interface herstellt. Erst anschließend werden die Testmethoden ausgeführt. Es werden jene
Methoden getestet die eine Annotation „@Test“ besitzen.
Die Testmethode testLogin() ruft die Methode login() in der Klasse Server auf. Es soll
sichergestellt werden, dass ein Zugriff auf die Datenbank erfolgt. Die Methode login() übergibt
Namen und Passwort an die Datenbank. Stimmen Namen und Passwort in der Datenbank
überein wird ein String „Sie sind eingeloggt“ an den Client zurück geschickt.
Die Testmethode testGetBenutzername() ruft die Methode getBenutzername() in der Klasse
Server auf. Sie soll vergleichen ob bei eingegebener Kontonummer der richtige Benutzername
retuniert wird.
Die Testmethode testGestKontostand() ruft in der Klasse Server die Methode getKontostand()
auf. Die Methode soll vergleichen, ob bei angegebener Kontonummer, der richtige Kontostand
retuniert wird.
15
Die Testmethode testKontonummerVorhanden() ruft die Methode kontonummerVorhanden() in
der Klasse Server auf. Diese Methode soll sicherstellen, ob die Kontonummer, die bei der
Überweisung eingeben wird, auch im System vorhanden ist.
4.3 Test Case 2 (Benutzer)
Mit Hilfe der Annotation „@Before“ wird vor dem Testen die setUp() Methode aufgerufen, die ein
Objekt Benutzer erstellt. Dieses Objekt besitzt folgende Informationen:
b = new Benutzer("Huber", "Maier", 4444, 300);
Huber = Benutzername
Maier = Passwort
4444 = Kontonummer
300 = Kontostand
Die verschiedenen Testmethoden sollen sicherstellen, dass ein Zugriff auf die Objektdaten
möglich ist.



testGetPasswort()
o ruft die Methode getPasswort() in der Klasse Benutzer auf. Es wird überpürft ob
das eingegeben Passwort mit jenem Passwort im Objekt Benutzer „b“
übereinstimmt
testGetKontonummer()
o ruft die Methode getKontonummer() in der Klasse Benutzer auf. Es wird überprüft
ob die eingegeben Kontonummer mit jener im Objekt Benutzer „b“ übereinstimmt
testGetKontostand()
o ruft die Methode getKontostand() in der Klasse Benutzer auf. Es wird überprüft
ob der eingegebene Kontostand mit jenem im Objekt Benutzer „b“ übereinstimmt
4.4 Test Case 3 (Ueberweisung)
Mit Hilfe der Annotation „@Before“ wird vor dem Testen die setUp() Methode aufgerufen, die ein
Objekt Ueberweisung erstellt. Dieses Objekt besitzt folgende Informationen:
u = new Ueberweisung(1111, 2222, "irgendwas", 333.3);
1111 = Kontonummer des Senders
2222 = Kontonummer des Empfängers
Irgendwas = Verwendungszweck
333.3 = Der zu überweisende Betrag
Die verschiedenen Testmethoden sollen sicherstellen, dass ein Zugriff auf die Objektdaten
möglich ist.



testGetSender()
o ruft die Methode getSender() in der Klasse Uberweisung auf. Es wird überprüft
ob der eingegeben Integerwert mit jenem gespeicherten Integerwert im Objekt
Ueberweisung „u“ übereinstimmt
testGetEmpfaenger()
o ruft die Methode getEmpfaenger() in der Klasse Uberweisung auf. Es wird
überprüft ob der eingegeben Integerwert mit jenem gespeicherten Integerwert im
Objekt Ueberweisung „u“ übereinstimmt
testGetVerwendungszweck()
o ruft die Methode getVerwendungszweck() in der Klasse Uberweisung auf. Es
wird überprüft ob der eingegeben String mit jenem gespeicherten String im
Objekt Ueberweisung „u“ übereinstimmt
16


testGetBetrag()
o ruft die Methode getBetrag() in der Klasse Uberweisung auf. Es wird überprüft ob
der eingegeben Doublewert mit jenem gespeicherten Doublewert im Objekt
Ueberweisung „u“ übereinstimmt
testSetNewSender()
o testet die Methode setSender() in der Klasse Ueberweisung. Die Instanzvariable
„Sender“ der Klasse Ueberweisung wird mit einem neuen String überschrieben.
Anschließend wird getestet, ob das überschreiben erfolgreich war.
17
5 Benutzerdokumentation
5.1 Beschreibung der GUI
Die GUI des Kontoverwaltungssystems wurde einfach und übersichtlich gehalten. Für den
Benutzer gibt es zwei relevante Seiten, die über einen Webbrowser aufgerufen werden.
http://localhost:8080/KontoClient/LoginServlet (lokal)
Die erste Seite ermöglicht es sich im Kontoverwaltungssystem anzumelden. Im ersten
Eingabefeld welches mit Kontonummer bezeichnet ist, wird eine dem System bekannte
Kontonummer erwartet. Die erwartete Kontonummer ist ausschließlich numerisch. Das zweite
Eingabefeld welches mit Passwort bezeichnet ist, erwartet das zur Kontonummer zugehörige
Passwort. Bei korrekter Eingabe beider Eingabefelder wird man zur nächsten Seite
Uebersicht.jsp weitergeleitet, andernfalls wird man aufgefordert das Login erneut zu probieren.
Auf der folgenden Seite wird der angemeldete Benutzer willkommen geheißen. Die Kontodaten
des Benutzers und der aktuelle Kontostand werden angezeigt. Außerdem wird ein OnlineKontoauszug angezeigt, welcher die Transaktionen des Benutzers auflistet.
Auf der linken Seite des Fensters ist es möglich Transaktionen abzusetzen. Der Benutzer hat
folgende Transaktionsmöglichkeiten:
 Einzahlung
 Auszahlung
 Überweisung
Die Einzahlung und die Auszahlung erfordern lediglich die Eingabe eines Betrages. Bei der
Überweisung muss zusätzlich die Kontonummer des Empfängers angegeben werden, außerdem
kann ein Verwendungszweck angegeben werden. Durchgeführt wird die Transaktion mittels
„Submit“-Button. Nach Absetzen der Transaktion wird die Übersicht-Seite automatisch
aktualisiert, also mit aktuellen Kontostand und einer neuen Transaktion im Online-Kontoauszug.
Die Abmeldung vom Kontoverwaltungssystem wird durch den „Abmelden“-Button rechts oben
ermöglicht.
18
5.2 Installationsanleitung
Vorrausgesetzte Software:


JDK 1.5:
Application Server:
http://java.sun.com/javase/downloads/index.jsp
http://www.jboss.com/products/jbossas/downloads
Installation des Kontoverwaltungssystems :
Im Deploy-Verzeichnis des Applikationsservers müssen sich folgende Dateien befinden
(C:\Programme\jboss-4.0.4.GA\server\default\deploy):
 Konto.jar
 KontoClient.war
 mysql-ds.xml
Ins Verzeichnis C:\Programme\Java\jre1.5.0_05\lib\ext ist die folgende Datei zu stellen
 mysql-connector-java-5.0.3.bin.jar
Starten des Kontoverwaltungssystems:
 Start des Applicationservers
19