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
