3. In VisualStudio 2008: File Open Web Site..., und das Verzeichnis WebBank auswählen.

Transkript

1 1 Summary Die WebBank ist eine kleine, aber vollständige Web-Anwendung mit GUI Controller Anwendungslogik Persistenzschicht Datenbank Die Anwendung ist eine Bank, in der es Kunden und Konten gibt. Kunden können Geld von ihrem auf andere Konten (dieser Anwendung) überweisen, und sich Kontoauszüge erstellen lassen. Mehr ist nicht möglich. Im folgenden werden Installationshinweise gegeben, sowie die verschiedenen Entwicklungsdumente präsentiert. 2 Installation 1..zip-File auspacken, legt Verzeichnis WebBank an. 2. Visual Studio 2008 starten. 3. In VisualStudio 2008: File Open Web Site..., und das Verzeichnis WebBank auswählen. 4. Im Solution Explorer erscheint die Anwendung. 5. Bevor man die Anwendung starten kann, muss zunächst eine Datenbank angelegt werden. Dazu Rechtsklick im Solution Explorer auf das App Data-Verzeichnis, Add New Item... auswählen, und eine SQL Database auswählen. Der vorgeschlagene Name Database.mdf ist bereits richtig. Schließlich noch Add klicken. 6. Dann kann man im Solution Explorer die Datei Default.htm auswählen und View in Browser bzw. Start Debugging. 7. Man erhält eine Einstiegsseite, von der aus man nur zur Login Seite gelangt. Ab da befindet man sich in der eigentlichen Anwendung. 3 Erster Start der Anwendung Wenn die Anwendung zum ersten Mal gestartet wird, ist die zugehörige Datenbank vollkommen leer (s. o.) d. h. es gibt weder Konten noch Kunden, und auch keine entsprechenden Tabellen. Daher gibt es über den Menüpunkt Backdoor die Möglichkeit, zuerst die Tabellen anzulegen (Button Tabellen anlegen), und dann neue Kunden und Konten anzulegen: Vorname: (beliebig) Nachname: (beliebig) Konto Nr: (muss neu und 5-stellig sein) Pin: (muss 4-stellig sein und aus Ziffern bestehen, am besten immer 1234) Betrag: (anfänglicher Geldbetrag auf dem Konto mindestens ein Konto muss Geld enthalten, da Überziehen des Kontos nicht erlaubt ist, und bei einem Kontostand 0 keine Überweisung möglich ist) 1

2 Damit man Überweisungen ausführen kann, benötigt man mindestens zwei Konten. Danach kann man die WebBank in ihrer beabsichtigen Form benutzen. Offensichtlich handelt es sich bei dieser Art, Konten anzulegen, um eine völlig illegale, jeder Form der Softwareentwicklung widersprechende, backdoor... 4 Anforderungsdument Wir betrachten eine (sehr) kleine Bank mit einem festen Satz von Kunden. Zu einem Kunden sollen sein Vor- und Nachname gespeichert werden. Jeder dieser Kunden hat genau ein Bankkonto. Zu einem Bankkonto sollen die Kontonummer und der Kontostand gespeichert werden. Um Zugriff zu (s)einem Konto zu erlangen, muss ein Benutzer neben der Kontonummer die zugehörige PIN angeben. Ohne eine solche Authentisierung darf kein Zugriff auf das System erfolgen. 4.1 Use Case 1 Überweisungen Kunde A will einen Betrag x an Kunde B (beide Kunden der Bank) überweisen. Das ist nur möglich, wenn der Kontostand von Kunde A x ist. Durch die Überweisung wird der Kontostand von Kunde A um x erniedrigt, der von Kunde B um x erhöht. Der Kunde kann zu einer Überweisung einen Verwendungszweck angeben. Für eine Überweisung benötigt die Bank sowohl den Namen als auch die Kontonummer des Empfängers. Außerdem natürlich noch den zu überweisenden Betrag. Überweisungen müssen transaktional sein, d.h. bei einem Fehler darf es nicht sein, dass das Geld bei Kunde A abgebucht worden ist, ohne auf dem Konto des Kunden B aufzutauchen. Als besonderen Service sind die Angaben des Benutzers zu überprüfen: Gibt es das Zielkonto überhaupt? Passt der Name des Empfängers zum Konto? Außerdem muss das System natürlich prüfen, ob das Konto (von Kunde A) gedeckt ist. 4.2 Use Case 2 Kontoauszug Ein Kunde wünscht einen Kontoauszug. Der Zeitraum ist beliebig wählbar. In einer tabellarischen Übersicht werden die Überweisungen, an denen der Kunde beteiligt war, aufgelistet. Der Kunde muss entnehmen können, wann er an/von wem wie viel Geld erhalten/gezahlt hat. Am Anfang der Liste soll der Kontostand zu Beginn des gewählten Zeitraums stehen, am Ende der am Ende. (Dieser sollte dem anfänglichen +- der aufgelisteten Überweisungsbeträge entsprechen.) 4.3 Randbedingungen Das System soll als Webanwendung realisiert werden. Es muss daher mehrbenutzerfähig sein. Die Daten sollen in einer Datenbank gespeichert werden. Die Anwendung hat exklusiven Zugriff auf die Datenbank. (D. h.: Es gibt keine anderen Programme, die auf die Datenbank zugreifen.) Das System-Design soll modular sein, d. h. GUI, Anwendungslogik und Anbindung der Datenbank verfügen über wohldefinierte Schnittstellen. Jegliche Kommunikation wird über diese Schnittstellen erledigt: GUI Anwendungslogik DB-Anbindung 5 Entwicklungsdumente nach Fusion Es folgen die Entwicklungsdumente für die WebBank: 2

3 5.1 Analyse 1. Objektmodell 2. Szenarien 3. Operationsmodell (Kontrakte) 4. LifeCycles 5.2 Design 1. GUI-Design Entwurf einer graphischen Oberfläche 2. Realisierung der Systemoperationen durch Objektinteraktionsgraphen 3. Klassenbeschreibungen, besonders neue Klassen und Realisierung der Assoziationen Parallel dazu: Data Dictionary. 6 Objektmodell Client firstname lastname PIN 1 Account 1 Account accountnumber balance 1 1 IssuingAccount ReceivingAccount * Transfer * date amount reasonfortransfer 3

4 7 Szenarien 7.1 Szenario 1: Erfolglose Anmeldung :User :System login("10001", "wrongpin") Error: wrong PIN Zur Anmeldung muss man seine Kontonummer samt passender PIN angeben. 7.2 Szenario 2: Überweisung(en) ausführen :User :System login("10001", "correctpin") transfer("john Doe", "55500", 3000, "Money back") transfer("john Doe", "55500", , "Lottery") Error: Not enough money. logout() Eine Überweisung kann nur durchgeführt werden, wenn man erfolgreich angemeldet ist. Dazu gibt man Name und Kontonummer des Empfängers an, außerdem natürlich auch den zu überweisenden Betrag. Man kann nicht mehr überweisen, als auf seinem Konto ist. 4

5 7.3 Szenario 3: Falsche Überweisungsdaten :User :System login("10001", "correctpin") transfer("john Doe", "10002", 3000, "reason") Error: data mismatch. transfer("john Doe", "99999", 3000, "reason") Error: Receiving account does not exist. logout() Wenn der Name nicht zur Kontonummer passt, oder diese nicht existiert, gibt es einen entsprechenden Fehler. 7.4 Szenario 4: Kontoauszug anfordern :User :System login("10001", "correctpin") getstatement(startdate, enddate) List<Statement> logout() 5

6 Nachdem man sich erfolgreich angemeldet hat, kann man einen Kontoauszug anfordern. Unsere vorläufige Idee ist, dass dieser als Liste von Überweisungen zurück gegeben wird. Der Benutzer (bzw. seine GUI) ist selbst für eine übersichtliche Aufbereitung und Darstellung verantwortlich. 7.5 Szenario 5: Kontostand abfragen :User :System login("10001", "correctpin") getbalance() 5100 logout() Ein angemeldeter Benutzer kann seinen Kontostand erfragen. 8 Operationsmodell (Systemoperationen/Kontrakte) 8.1 Anmelden Operation: login(accountnumber : String, pin : String) : boolean Description: Meldet einen Benutzer als Kunden an. Die Anmeldung erfolgt über die Kontonummer, da diese eindeutig ist. (Jeder Kunde hat genau ein Konto.) Führt eine Authorisierung (PIN) durch. Precondition: Exceptions: Fehlermeldung, falls accountnumber kein existierendes Konto ist, pin falsch ist, oder der Benutzer bereits angemeldet ist. Result Values: Type: System operation Postcondition: LoggedInUser wurde mit dem Besitzer des Kontos mit der Kontonummer accountnumber assoziiert. 6

7 8.2 Abmelden Operation: logout() : boolean Description: Meldet den aktuellen Benutzer wieder ab. Precondition: Exceptions: Result Values: Type: System operation Postcondition: LoggedInUser ist mit keinem Client assoziiert. 8.3 Kontostand abfragen Operation: getbalance() : float Description: Liefert den Kontostand des angemeldeten Kunden zurück. Precondition: Exceptions: kein Benutzer angemeldet Result Values: LoggedInUser.account.balance Type: System operation Postcondition: System ist unverändert 8.4 Kontoauszug anfordern Operation: Description: Precondition: Exceptions: Result Values: getstatement(startdate : Date, enddate : Date) : Statement Liefert einen Kontoauszug für den spezifizierten Zeitraum zurück. Dieser beschreibt alle Überweisungen, die das Konto des aktuellen Kunden betreffen. Außerdem enthält er die Kontostände vor und nach diesen Überweisungen zurück. startdate < enddate kein Benutzer angemeldet Es wird ein neu erzeugter Kontoauszug zurück geliefert. Dieser enthält 1. die Buchungen bus, jeweils korrespondierend zu den Überweisungen im angegebenen Zeitraum, die das Konto des angemeldeten Benutzers betreffen 2. den übergebenen Zeitraum (startdatum, enddatum) Type: Postcondition: 3. den Kontostand zu Beginn, und den Kontostand nach Ausführung der relevanten Überweisungen aus dem spezifizierten Zeitraum System operation Kontoauszug erzeugt, System ist unverändert (Kontoauszug wird nicht gespeichert). 7

8 8.5 Überweisung tätigen Operation: transfer(toclient:string, toaccount:string, amount:float, reason:string) : boolean Description: Führt eine Überweisung vom Konto des angemeldeten Kunden (Quellkonto) auf das Konto mit der Kontonummer toaccount eines anderen Kunden durch. Precondition: Exceptions: 1. kein Benutzer angemeldet 2. amount 0 3. Zielkonto = Quellkonto 4. amount > Betrag des Quellkontos 5. toclient Besitzer des Kontos toaccount Result Values: Type: System operation Postcondition: Die Überweisung ist durchgeführt, d. h. 9 LifeCycles 1. der Kontostand des Kontos des angemeldeten Benutzer wurde um amount verringert 2. der Kontostand des toaccount Kontos wurde um amount erhöht 3. es wurde eine neue Überweisung u angelegt, u.date wurde auf das aktuelle Datum gesetzt, u.amount auf amount, u.reasonfortransfer auf reason 4. die beiden beteiligten Konten (das Quellkonto und das Zielkonto) wurden mit der neuen Überweisung u über die Assoziationen IssuingAccount und ReceivingAccount assoziiert. Der LifeCycle verwendet nur die beiden folgenden Zustände START: Starten des Systems (login-fenster) KONTO: erfolgreich angemeldet, bereit zur Durchführung weiterer Aktionen (wie z. B. Tätigen einer Überweisung) Seine Produktionen sind: START ::= login(number, pin).# KONTO login(number, pin).#error START ε KONTO ::= getbalance().#balance KONTO getstatement().#statement KONTO transfer(toclient, toaccount, amount, reason).(# #error) KONTO logout().# START logout().# Die erste Produktion sagt: Zu Beginn (START) kann man beliebig oft versuchen, sich anzumelden (ist die PIN falsch, so bleibt man in START). Wenn man es aufgeben will, kann man das System verlassen (ε). Nach erfolgreicher Anmeldung befindet man sich in KONTO. Dort kann man sich jederzeit den Kontostand oder einen Kontoauszug ansehen, oder eine Überweisung tätigen. Schließlich kann man sich abmelden (zurück zu START) oder das System ganz verlassen. 8

9 10 GUI Design Es gibt insgesamt 5 verschiedene Fenster, die den Systemoperationen entsprechen: Login (für Systemoperation login ) Kontoübersicht (für Systemoperation getbalance ) Kontoauszug (für Systemoperation getstatement ) Überweisung (für Systemoperation tranfer ) Logout (für Systemoperation logout ) Man kann beliebig zwischen den Fenstern hin- und herwechseln. Für getbalance, getstatement und transfer muss man angemeldet sein. Ist man das nicht, wird man beim Versuch, diese Fenster zu öffnen, automatisch auf die Login-Seite umgelenkt. Die Login- und die Logout-Seiten sind immer erreichbar. Man kann sich aber nicht ein zweites Mal anmelden (dies ergibt sich auch aus dem LifeCycle). 11 Objektinteraktiongraphen Das Operationsmodell beschreibt nur den Effekt der Systemoperationen. Zur Benutzung einer Systemoperation ist dies auch völlig ausreichend. Der Entwickler muss aber die Systemoperationen auch in einem Programm realisieren. Dazu muss zusätzlich der Ablauf einer Systemoperation beschrieben werden. Zu diesem Zweck werden die OIGs benutzt. Es ist nicht unüblich, zur besseren Gliederung oder zur Ausnutzung gemeinsamer Realisierungsanteile weitere Operationen einzuführen. Diese müssen dann natürlich auch ins Operationsmodell aufgenommen werden OIG zur Systemoperation getstatement s = getstatement(startdate,enddate) :Account 3: laterout = filterdatein(enddate,now(), Payout) 4: inout = filterdatein(startdate,enddate, Payout) 5: laterin = filterdatein(enddate,now(), Payment) 6: inin = filterdatein(startdate,enddate, Payment) 1: Payout = getpayouttoaccount 2: Payment = getpaymenttoaccount 7: create(startdate, enddate, balance, laterout, inout, laterin, inin) s:statement {new} Die Systemoperation geht zuerst an das SessionController-Objekt. Dieses holt das Konto des aktuell angemeldeten Benutzers, und delegiert die Operation an das zugehörige Konto. Was das Konto daraufhin macht, ist oben dargestellt: 1. Das Konto bestimmt zuerst sämtliche Überweisungen, die Geld von dem Konto weg transferieren (Payout), und hin transferieren (Payment). 2. Dann bestimmt das Konto 4 Mengen von Überweisungen (in 3 6): laterout - Auszahlungen, die nach enddate stattgefunden haben inout - Auszahlungen, die zwischen startdate und enddate stattgefunden haben laterin - Einzahlungen, die nach enddate stattgefunden haben inin - Einzahlungen, die zwischen startdate und enddate stattgefunden haben 9

10 Diese werden mit Hilfe der Operation filterdatein (s. u.) bestimmt. 3. Das Konto erzeugt (in 7) einen neuen Kontoauszug und gibt diesem den aktuellen Kontostand, start- und enddate, und die 4 gerade bestimmten Mengen von Überweisungen mit. Daraus berechnet der Kontoauszug sowohl die Kontostände vor bzw. nach Durchführung der Überweisungen als auch die Buchungen, die je eine relevante Überweisung als Einzelposten auf dem Kontoauszug beschreiben sollen. An dieser Stelle dekomponieren wir den OIG, indem wir für die Realisierung dieser Funktion einen separaten OIG erstellen. Dadurch werden beide OIGs verständlicher. 4. Der erzeugte Kontoauszug wird als Ergebnis zurück gegeben OIG zur Erstellung eines Kontoauszugs create(startdate, enddate, balance, laterout, inout, laterin, inin) {new} s : Statement 3: create() 6*: insertboingbydate(bu) 7*: insertboingbydate(bu) {new} : List<Boing> 1: setdates(startdate, enddate) 2: setbalances(balance) 4*[sa in laterout]: incrbalances(sa.amount) 5*[se in laterin]: decrbalances(se.amount) 6*[ia in inout]: bu = makenegboing(ia) 6*[ia in inout]: balancebefore += ia.amount 7*[ie in inin]: bu = makeposboing(ie) 7*[ie in inin]: balancebefore = ie.amount Initial (in 1, 2) werden beide Kontostände auf den übergebenen (aktuellen) Kontostand gesetzt. Für die später - bzw. in -Überweisungen werden der Kontostand-Danach bzw. sowohl der Kontostand-Danach als der Kontostand-Davor entsprechend angepasst (in 4 7). Aus jeder Überweisung wird eine korrespondierende Buchung erzeugt und in den Kontoauszug aufgenommen (in 6*, 7*, die Implementierung hält eine Sortierung aufrecht und fügt nicht mit Add() hinten (oder vorne) an, sondern mit InsertBuchungByDate() chronologisch richtig): Dabei wird im Prinzip eine neue Buchung erstellt. Die Attribute werden fast vollständig aus der zugrunde liegenden Überweisung übernommen. Der Name des Transaktionspartnern ergibt sich aus dem Besitzer des Quellkontos, von dem auf unser Konto eingezahlt wird. bu = makeposboing(tr) {new} s : Statement 1:sa = getissuingaccount() 2: u = getclienttoaccount(sa) tr:transfer sk : Account 3: name = getname() u : Client 4: create(tr.date,tr.amount, tr.reasonfortransfer,name) {new} bu : Boing Fast identisch verläuft das Erstellen der Buchung zu einer Auszahlung. Hier muss lediglich der Betrag negiert werden (denn der Kontostand wird ja verringert). Der relevante Name des Transaktionspartners ergibt sich in diesem Fall aus dem Besitzer des Zielkontos. 12 Klassenbeschreibungen 12.1 Neue Designklassen SessionController 10

11 Boing Statement Attribute siehe OIGs und Data Dictionary Realisierung der Assoziationen Account: 1:1 Client Account. Wird zu Attribut Account:Account im Client, kein Attribut in Account (d.h. es kann nur von Client zu Account navigiert werden). IssuingAccount: *:1 Transfer Account. Wird zu Attribut IssuingAccount:Account in Transfer, kein Attribut in Account. ReceivingAccount: *:1 Transfer Account. Wird zu Attribut ReceivingAccount:Acoount in Transfer, kein Attribut in Account. Damit ist auch klar, wie die Datenbanktabellen aussehen: <<Table>> Account OID : uniqueidentifier AccountNumber : varchar(15) Balance : real <<Table>> Client OID : uniqueidentifier FirstName : varchar(20) LastName : varchar(20) PIN : varchar(50) Account : uniqueidentifier <<Table>> Transfer OID : uniqueidentifier Date : datetime Amount : real ReasonForTransfer : varchar(255) IssuingAccount : uniqueidentifier ReceivingAccount : uniqueidentifier Aus der Realisierung folgt, dass sämtliche Kunden durchsucht werden müssen, um zu einem Konto den Besitzer zu finden (eventuell ineffizient), während sehr effizient auf das Konto eines Kunden zugegriffen werden kann Beschreibung der einzelnen Klassen Siehe Source Code. 11

12 13 Data Dictionary 13.1 Objektmodell Name Typ Beschreibung Client Class Ein Kunde ist eine Person, die (genau) ein Konto bei der Bank besitzt. User Class Der Mensch(?), der das System benutzen soll. Account Class In einem Konto wird verwaltet, wie viel Geld ein Kunde bei der Bank deponiert hat. Transfer Class Eine Überweisung protolliert, dass Geld zwischen zwei Konten geflossen ist. firstname Attribute (Client) Der Vorname eines Kunden. lastname Attribute (Client) Der Nachname eines Kunden. PIN Attribute (Client) Ein geheimer Code. Ein Benutzer authentisiert sich damit als Besitzer des Kontos. accountnumber Attribute (Account) Die eindeutige Identifikationsnummer eines Kontos. balance Attribute (Account) Das aktuelle Saldo eines Kontos. date Attribute (Transfer) Hält zu einer Überweisung fest, wann diese getätigt worden ist. amount Attribute (Transfer) Die Geldsumme, die bei einer Überweisung bewegt worden ist. reasonfortransfer Attribute (Transfer) Ein Freitext, mit dem ein Kunde seine Überweisung näher beschreiben kann. Account Association Jeder Kunde besitzt genau ein Konto bei der Bank. IssuingAccount Association Quellkonto einer Überweisung, d.h. das Konto, von dem abgebucht wird. ReceivingAccount Association Zielkonto einer Überweisung. An einer Überweisung sind immer genau zwei Konten beteiligt: Das Quellkonto, von dem das Geld weg-, und das Zielkonto, zu dem das Geld hinfließt. 12

13 13.2 Designklassen Name Typ Beschreibung SessionController Class Schnittstelle zur GUI. Stellt alle Systemoperationen zur Verfügung. LoggedInUser Attribute (SessionController): Der aktuell angemeldete Benutzer (oder null) Boing Class Ein Posten auf einem Kontoauszug, d.h. die Daten einer Überweisung. Im Gegensatz zu einer Überweisung ist hier nur der Name des Transaktionspartners enthalten. Der Betrag kann hier auch negativ sein. (Wird nicht gespeichert.) date Attribute (Boing) Wie bei transfer amount Attribute (Boing) Wie bei transfer reasonfortransfer Attribute (Boing) Wie bei transfer txpartnername Attribute (Boing): Name des Senders bzw. Empfängers einer Überweisung Statement Class Aufstellung aller für ein Konto relevanter Überweisungen eines Zeitraums. (Wird nicht gespeichert.) startdate Attribute (Statement): Startdatum des Kontoauszugs enddate Attribute (Statement): Endedatum des Kontoauszugs balancebefore Attribute (Statement): Kontostand am Startdatum des Kontoauszugs balanceafter Attribute (Statement): Kontostand am Enddatum des Kontoauszugs boings Attribute (Statement): Liste der Buchungsvorgänge (List<Boing>) in zeitlicher Reihenfolge zwischen Start- und Enddatum des Kontoauszugs Systemoperationen Name Typ Argumente Beschreibung login SysOp Kontonummer, PIN Meldet einen Kunden an. logout SysOp keine Meldet einen Kunden ab. getstatement SysOp Start- und Enddatum Liefert den Kontoauszug zu einem spezifizierten Zeitraum. getbalance SysOp keine Liefert den aktuellen Kontostand. transfer SysOp Name Empfänger, KontoNr Empfänger, Betrag, Verwendungszweck Führt eine Überweisung aus. 13