GEMSS Quarterly Progress Report

Werbung
Software Engineering Übung, LVNr:
Übungsleiter: Ivona Brandic
Dokument: Endabgabe v.1.2
Projekttitel: Kontoverwaltungssystem mit SPRING (Phase 2)
Gruppenmitglieder:
MatNr:
a0102290
a0000378
Nachname:
Zohmann
Remely
Vorname:
Christian
Günther
e-mail:
[email protected]
[email protected]
Datum: 01.12.2006
1
1 Anforderungen
1.1 Projektname
Kontoverwaltungssystem
Erstellt mit dem Java Framework Spring
1.2 Kurzbeschreibung
In der Phase 2 soll die bereits bestehende Internetapplikation aus Phase 1, die sich mit EJB3.0
beschäftigt hat, erweitert werden. Die Funktionalität aus Phase 1 soll weiter bestehen bleiben.
Zur Realisierung des Projektes soll die Model-View-Controller (MVC) Methodik verwendet
werden. Es sollen mindestens zwei verschiedenen Views realisiert werden. Falls notwendig wird
die Applikation soweit erweitert, dass die MVC Methodik sinnvoll angewendet werden kann. Ein
Servlet dient als Controller, POJOs als Model und JSP Seite(n) als View(s).Um sicherzugehen,
dass die Anwendung fehlerfrei funktioniert sollen mittels JUnit die verschiedenen Klassen der
Applikation getestet werden (z.B.: Controller Klasse).
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
Kontenübersicht
1.3 Funktionale Anforderungen
1.3.1 Beschreibung der Funktionalität
Wie bereits unter Punkt 1.2. 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. Die Anforderungen für das Kontoverwaltungssystem mit Spring wurden
erweitert, sodass ein sinnvoller Einsatz der MVC Methodik gewährleistet werden kann. Die
Erweiterung bedeutet, dass im Sinne vom Springframework eine zusätzliche Sicht implementiert
wurde. Diese zusätzliche Sicht liefert eine Übersicht über alle bestehenden Konten mit dem
aktuellen Kontostand.
2
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.
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
Nachbedingung bei Fehlschlag:
3


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
Use Case: Geld überweisen
Ziel:
 Elektronisches Geld von einem Konto auf ein anderes Konto überweisen
Kategorie:
 primär
4
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
Vorbedingung:
 User muss eingeloggt sein
Nachbedingung bei Erfolg:
 Verringerung des Kapitalstandes am Konto
Nachbedingung bei Fehlschlag:
 Fehlerausgabe am Bildschirm
5
Akteure:
 User
Use Case: Kontenübersicht
Ziel:

Ausgabe aller Konten samt Name des Inhabers und aktuellem Kontostand
Kategorie:
 primär
Vorbedingung:
 Nachbedingung bei Erfolg:
 Kontenübersicht ausgegeben
Nachbedingung bei Fehlschlag:
 Fehlerausgabe am Bildschirm
Akteure:
 Admin
1.3.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, die das Einloggen in das System ermöglicht. Das
zweite Fenster, welches nach einem erfolgreichen Login erreicht wird, stellt den Kontoauszug
dar, dass mittels dem „Controller“ erstellt wird. Die Seite Kontoauszug ermöglicht die Navigation
zu folgenden drei Seiten:
 Überweisung:
o Diese Seite ermöglicht das Überweisen eines Geldbetrages von einem Benutzer
zu einem anderen
 Einzahlung:
o Hier kann der Benutzer einen Geldbetrag auf sein eigenes Konto einzahlen
 Auszahlung:
o Hier kann der Benutzer einen Geldbetrag von seinem eigenen Konto abziehen
6
1.4 Nicht-funktionale 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.
7

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.
8
2
Klassendesign
2.1 Gesamtklassendesign
2.2 Wichtige Designentscheidungen
9
3 Architekturbeschreibung EJB
3.1 Klassendiagramm
3.2 Paketstruktur
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
3.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
10
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
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
3.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.
3.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.
11
4 Architekturbeschreibung Spring
4.1 Klassendiagramm
4.1.1 Bus-Paket
4.1.2 Web-Paket
12
4.1.3 Web-Paket
4.2 Paketstruktur
13
5 Architekturdiagramm

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/springkonto (lokal)

Middle Tier
 Web Container Tier
Der Web Container Tier umfasst einerseits ein Servlet (Controller) und JSP Seiten
(View). Beim Aufruf des Kontoverwaltungssystems (siehe Link oben) wird zuerst die
„index.jsp“ aufgerufen, die den Benutzer direkt zur Login Seite weiterleitet. Nach
erfolgreicher Anmeldung wird die Seite „kontoauszug“ aufgerufen, die durch den
„springkontoauszugController“ durchgeschleift wird. Der Controller sammelt alle
notwendigen Daten, die anschließend in der View „kontoauszug.htm“ ausgegeben
werden.


Business Logic Tier
Hier wird der reibungslose Ablauf der Geschäftslogik sichergestellt. Die „Business
Logic“ beinhaltet die Funktionalität der aus Phase 1 bekannten EJB Klasse und
Entity Klassen. In Phase 2 beinhaltet die „Business Logic“ die Klasse
„KontoManager“, „Ueberweisung“ und „Benutzer“.
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.
14
6 User Interface Beschreibung
6.1 GUI Screenshot / User Interface Skizzen
Screenshot 1: login.jsp
Screenshot 2: kontoauszug.jsp
Screenshot 3: ueberweisung.jsp
15
Screenshot 4: einzahlung.jsp
Screenshot 5: auszahlung.jsp
Screenshot 6: admin.jsp
16
6.2 Beschreibung des GUI / User Interface
6.2.1 Standarduser
Die GUI des Kontoverwaltungssystems wurde einfach und übersichtlich gehalten. Für den
Standardbenutzer gibt es eine relevante Seite, die über einen Webbrowser aufgerufen werden.
http://localhost:8080/springkonto (lokal)
Die aufgerufene 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
kontoauszug.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. Außerdem gibt es
drei Links, die es dem Benutzer ermöglichen hat folgende Transaktionen zu tätigen:
 Überweisung
 Einzahlung
 Auszahlung
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.
6.2.2 Admin
Auf die Sicht des Administrators kommt man nicht über ein Login, sondern lediglich durch das
Aufrufen folgender Adresse:
http://localhost:8080/springkonto/admin (lokal)
Diese Seite listet alle Benutzer auf, die im Kontoverwaltungssystem persistent gespeichert
wurden. Die Ausgabe umfasst Kontonummer, Name und den Kontostand.
17
7 MVC Mechanismus
7.1 Beschreibung
Der Model-View Controller ist ein Framework, welcher sich zur Erstellung von Webbasierten
Applikationen eignet. Durch die vorgegebene Struktur des Frameworks kann die Aufrufabfolge
von Webseiten sehr schlicht gehalten werden. Außerdem erlaubt der MVC die multiple
Darstellung von ein und demselben Objekt. Zusammenfassend kann man den MVC als eine
Kollaboration von Klassen zum Erstellen von Benutzerschnittstellen beschreiben.
Der MVC umfasst drei Arten von Objekten:
 Modelle: Anwendungsobjekte
Die Modelle entsprechen den Java Beans. Die im Kontoverwaltungssystem verwendeten
Beans werden in unserem Fall im „springkonto-servlet.xml“ File definiert. Diese Beans stellen
Klassen in dem Projekt dar und es ist möglich diese Beans zu konfigurieren. Die
Konfiguration funktioniert beispielsweise über Properties, so ist es möglich Referenzen auf
andere Beans zu setzen.
 Sichten (views): zur grafischen Darstellung eines Modells
Zwei grundlegende Sichten sind unserem Projekt sind „kontoauszug.jsp“ und „admin.jsp“. In
beiden werden Daten aus der DB dargestellt. Im „kontoauszug.jsp“ werden die Benutzer- und
Kontodaten eines eingeloggten Users dargestellt. Im „admin.jsp“ werden die Kontodaten aller
Benutzer aufgelistet.
 Steuerung (controller): definiert, wie das Userinterface auf Benutzereingaben reagiert
Die Controller-Klassen übernehmen die Steuerung der web-basierten Applikation. In unserer
Applikation gibt es eine Controller-Klasse für jede JSP-Seite.
 LoginFormController..java
 SpringkontoauszugController.java
 EinzahlungFormController.java
 AuszahlungFormController.java
 UeberweisungFormController.java
 AdminController.java
Konfiguriert werden diese Controller im „springkonto-servlet.xml“ File. Die Controllerklassen
entsprechen ebenfalls Beans und werden über die Properties konfiguriert. In diesen
Properties wird definiert wie die Kontrollerklassen angesprochen werden können. Referenzen
auf andere Klassen werden gesetzt und eine Folgeview kann bestimmt werden. Die
Konfiguration der Controllerklassen dient auch dazu um Daten vom Benutzer über die JSPSeite einlesen zu können. Diese Werte können dann über setter/getter-Methoden
referenzierter Klassen den Instanzvariablen zugewiesen werden. Werden Werte über die
18
JSP-Seiten eingelesen, dann werden noch Validatorklassen dazwischengeschalten, die die
eingegebenen Werte auf ihre Gültigkeit überprüfen. Entsprechen die eingegebenen Werte
nicht dem Gültigkeitsbereich, dann wird nicht die Folgeview aufgerufen, sondern eine
Korrektur der einzugebenden Werte veranlasst.
7.2
Klassendiagramm
7.2.1 Kontoauszug
19
8 Persistente Datenspeicherung
Um die Daten zu Speichern wird eine MySQL Datenbank verwendet, die unter:
www.swe.geschenkestube.at/mysqladmin erreichbar ist.
8.1 Datenbank / ERD
Ü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.
8.2 Spring - Adaptierungen
Die Funktionserweiterung gegenüber der 1. Abgabe hat es nicht erfordert zusätzliche Daten in
der Datenbank persistent zu speichern. Daraus ergibt sich, dass mit der gleichen Datenbank von
der 1. Abgabe weiter gearbeitet werden konnte. Die zu speichernden Daten, sind die relevanten
Daten der User wie Name, Passwort, Kontonummer und Kontostand. Außerdem werden die
Transaktionen der User gespeichert, diese umfassen Empfänger, Sender, Verwendungszweck
und einen Betrag. In der 1. Abgabe gab es dafür zwei Klassen, die die Speicherung mittels EJB
ermöglicht hatten. Diese Klassen waren „Benutzer.java“ und „Ueberweisung.java“. Mittels der
Annotationen @entity, @table und @column und diese beiden Klassen für die verwendete
relationale Datenbank umgemapped und konnten somit persistent in die Datenbank geschrieben
werden.
Diese beiden Klassen haben an ihrer Funktionalität unter Spring nichts eingebüßt. Die
Annotationen wurden überflüssig, da sie EJB 3.0 spezifisch waren. Für Spring ist relevant, dass
die notwendigen Instanzvariablen alle über getter/setter-Methoden zugreifbar sind, aber das war
ohnehin schon gewährleistet.
Die Verbindungseinstellungen werden bei Spring im relevanten „servlet.xml“ gespeichert. In
unserem Fall ist es das „springkonto-servlet.xml“. In diesem File werden alle für die
Webapplikation notwendigen Beans definiert. Ebenso haben wir eine Bean definiert, welche die
Verbindungseinstellungen für die DB als Werte hat. Die Beandefinition schaut folgendermaßen
aus:
<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
20
<property name="driverClassName"><value>com.mysql.jdbc.Driver</value></property>
<property name="url">
<value>jdbc:mysql://swe.geschenkestube.at/swews</value>
</property>
<property name="username"><value>swews</value></property>
<property name="password"><value>swews</value></property>
</bean>
Im „springkonto-servlet.xml“ gibt es zwei weitere Beandefinitionen, die unmittelbar mit dem
Datenbankzugriff in Verbindung stehen.
<bean id="kontoManDao" class="db.KontoManagerDaoJdbc">
<property name="dataSource">
<ref bean="dataSource"/>
</property>
</bean>
<bean id="kontoMan" class="bus.KontoManager">
<property name="kontoManagerDao">
<ref bean="kontoManDao"/>
</property>
</bean>
Diese Definitionen stehen einerseits für ein Interface und für eine Klasse, die dieses Interface
implementiert. In der Klasse „db.KontoManagerDaoJdbc“ werden die Methoden des Interfaces
„db.KontoManagerDaoJdbc“ implementiert. In diesen Methoden werden die SQL-Abfragen auf
die Datenbank abgesetzt. Das Springframework stellt eine Klasse („JdbcTemplate“) zur
Verfügung, die das Absetzen der SQL-Abfragen sehr vereinfacht.
21
9 Client Interfaces
9.1 Interface 1
Durch den Aufruf der Seite http://localhost:8080/springkonto wird man automatisch an die LoginSeite weitergeleitet. Diese Loginseite erwartet als Eingabe die Kontonummer und das Passwort
desjenigen Kunden. Die eingegeben Daten werden an die BusinessLogic weiterleitet, wo
anschließend die Daten die im Loginfenster eingegeben wurden, an die Datenbank weitergeleitet
werden. In der Datenbank wird überprüft ob Kontonummer und Passwort vorhanden sind und
zusammen passen. Nach erfolgreicher Überprüfung wird der Benutzer an die Kontoauszugsseite
weitergeleitet.
9.2 Interface 2
Nach erfolgreichem Login wird der Kunde automatisch an die Kontoauszugsseite weitergeleitet.
Hier kann der User seinen Kontostand sowie auch seine Transaktionen einsehen. Bei bedarf
kann der Benutzer zu folgenden Seiten weiternavigieren.
o Überweisung
o Einzahlung
o Auszahlung
22
9.3 Interface 3
Dieses Interface ermöglicht dem Kunden Geld auf sein Onlinekonto einzuzahlen. Wie in der
Abbildung zu sehen ist, werden als Eingabe, Betrag und Verwendungszweck verlangt.
Anschließend kann der Kunde auf „einzahlen“ klicken und der Betrag wird auf seinem Konto gut
geschrieben.
9.4 Interface 4
Dieses Interface ermöglicht dem Kunden Geld vom Onlinekonto abzubuchen. Wie in der
Abbildung zu sehen ist, werden als Eingabe, Betrag und Verwendungszweck verlangt.
Anschließend kann der Kunde auf „abbuchen“ klicken und der Betrag wird auf seinem Konto
abgebucht.
9.5 Interface 5
Dieses Interface ermöglicht dem Kunden Geld von seinem Onlinekonto zu einem Konto eines
anderen Benutzers zu überweisen. Wie in der Abbildung zu sehen ist, werden als Eingabe,
Empfänger, Betrag und Verwendungszweck verlangt. Anschließend kann der Kunde auf
„überweisen“ klicken und der Betrag wird auf seinem Konto abgebucht und auf dem Konto des
Empfängers überwiesen.
23
10 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.
10.1 TestKontoManager
Die Klasse TestKontoManager dient zum Testen der Klasse KontoManager in der BusinessLogic.
Diese Klasse legt mittels der Methode setUp() einen Benutzer und eine Buchungszeile an.
Die Methode testGetBenutzer() liest den angelegten Benutzer aus, und vergleicht mittels
assertEquals ob die vorgegebenen Daten mit den Daten im Objekt übereinstimmen.
Die Methode testGetBuchunszeilen() liest die angelegte Buchungszeile, aus dem Objekt
Überweisung aus. Anschließend wird mit der Methode assertEquals verglichen, ob die
vorgegebenen Daten mit den Daten im Objekt übereinstimmen.
10.2 TestKontoManagerDaoJdbc
Diese Testmethode dient zum Testen der JDBC Klasse im Paket „db“ der BusinessLogic. Mittels
der setUp() Methode wird eine Verbindung zur MYSQL Datenbank hergestellt.
Die Methode testGetBenutzerList() ruft mittels „kmdao.getBenutzerListDao("1111", "zohmann")“
die Methode im Interface auf und übergibt Kontonummer (1111) und Passwort (zohmann) an die
JDBC Klasse, die anschließend eine DB-Query ausführt. Stimmen Kontonummer und Passwort
in der Datenbank überein, wird die komplette Zeile aus der Datenbank in das Objekt Benutzer
gespeichert. Diese gespeicherten Daten im Objekt werden anschließend mit den von uns
vorgegeben Daten verglichen. Stimmen diese Daten überein, war der Test erfolgreich.
Die Methode testGetBuchungezeilenList() ruft mittels „kmdao.getUeberweisungListDao("2222");“
die Methode im Interface auf und übergibt die Kontonummer (2222) an die JDBC Klasse, die
anschließend eine DB-Query ausführt. Diese Query sieht in der Tabelle Überweisung nach, und
liefert alle Einträge zurück wo die Kontonummer entweder im Empfänger- oder Senderfeld
vorkommt. Anschließend werden die übergebenen Werte mit den vorgegeben Werten verglichen.
Die Methode testEinzahlung() ruft mittels „kmdao.einzahlungDao("2222", 666, "Irgendwas");“ die
Methode im Interface auf und übergibt die Kontonummer des Empfängers (2222) den Betrag
(666) und den Verwendungszweck (Irgendwas) an die JDBC Klasse, die anschließend eine DBQuery ausführt. Diese Query legt in der Tabelle Überweisung einen neuen Eintrag an mit den von
uns vorgegeben Werten. Anschließend werden diese Werte zurück an die Testklasse
ausgegeben und verglichen
10.3 TestSpringkontoauszugsController
Diese Testklasse teste den SpringkontoauszugController. Hier wird getestet ob der Controller die
richtigen Daten an die View liefert. In der Testklasse werden die zu testenden Daten aus der
springkonto-serlvet.xml Datei eingelesen. Anschließend werden mittels der assertEquals
Methode die Daten verglichen. Stimmen die Daten überein, wurde der Test erfolgreich absolviert
und der Controller lieferte die richtigen Daten an die View (Kontoauszug).
24
Herunterladen
Explore flashcards