Sie werden im Zuge dieser Übung folgende Pattern implementieren:

• State
• Prototype
• Mediator

Ziel dieser Übung ist es, eine einfache, interaktive Kommandozeilenapplikation zu schreiben, die die Interaktion mit einem ATM (Bankomat) simuliert. Dieser ATM ist eine absolute Neuheit, da er keine Geldabhebungsfunktion hat, sondern nur Geldüberweisungen tätigen kann (ATM steht also nicht für automated teller machine, sondern account transaction machine). Als Interface dient ein einfaches Menü, bei dem man durch vorgegebene Menüpunkte Aktionen auswählen kann. Auf Basis des aktuellen Zustandes sollen dann gewisse Aktionen ausgeführt werden.

1. Domain

Die Schlüsselwörter der Domaine sind:

• ATM: Ein Automat, bei dem man mithilfe einer EC-Karte Bargeld beheben und einzahlen kann. Auch bekannt als Bankomat.
• Bankkonto: Wird durch eine eindeutige Nummer identifiziert. Repräsentiert ein Konto, von welchem Geld auf andere Konten überwiesen werden kann.
• PIN: 4-stellige Prüfnummer, welche Transaktionen im Zusammenhang mit dem zugeordneten Konto autorisiert
• Transaktion: Eine Transaktion beinhaltet in dieser vereinfachten Anwendung nur den Betrag, welcher zwischen den Accounts transferiert wird.

Für diese Übung ist das Konzept der EC-Karte obsolete, da es sich um eine rein digitale Anwendung handelt. Zur Autorisierung ist daher nur das Wissen über die Nummer des Bankkontos und dessen PIN notwendig, auch wenn der PIN eigentlich der Karte zugeordnet ist und nicht dem Konto.

2. Konfiguration

Die Konfiguration repräsentiert das Kernbankensystem. Hier werden die Konten und die History aller Transaktionen gespeichert. Hier ein Beispiel für eine gültige Konfiguration:

{
	"accounts": [
		{
			"number": "123456789012",
			"owner": "Thomas E.",
			"transactions": [
				{
					"amount": "-50",
					"dateTime": "2016-06-07T19:59:20Z"
				},
				{
					"amount": "150",
					"dateTime": "2016-06-08T23:41:54Z"
				}

			]
		},
		{
			"number": "234567890123",
			"owner": "David L.",
			"transactions": []
		}
	]
}

Das Programm muss die Konfiguration beim Start gegen die unter 2.1 genannten Einschränkungen validieren.

2.1 Einschränkungen

• Die Kontonummer muss 12-stellig sein
• Die Kontonummer muss einzigartig sein
• Alle Werte sind als Strings kodiert. (Ein JSON könnte theoretisch auch Zahlen darstellen, hier werden allerdings Strings verwendet.)

Falls die Konfiguration nicht gültig ist, soll sich das Programm mit einer Fehlermeldung beenden.

3. Architektur der Anwendung

Das Programm stellt eine interaktive Konsolenanwendung dar. Der Benutzer soll aus einer Liste an Menüpunkten eine Aktion wählen können. Nach der Ausführung der Aktion wird das Menü erneut angezeigt.

Das Programm soll grundsätzlich aus 3 Komponenten bestehen. Diese Komponenten kommunizieren über einen Mediator und sind dadurch lose miteinander gekoppelt.

3.1 Menü-Modul

Dieses Modul gibt das Menü auf der Console aus und nimmt die Menü-Auswahl entgegen. Folgende Menü-Punkte sollen zur Verfügung stehen:

• EC-Karte einführen
• EC-Karte entfernen
• PIN eingeben
• Geld überweisen

3.2 Aktions-Input-Modul

Dieses Modul ist dafür zuständig, für eine ausgewählte Aktion weitere Informationen vom User abzufragen. Die Information, welche Aktion (Menü-Punkt) ausgewählt wurde, wird vom Menü-Modul zur Verfügung gestellt. Die Kommunikation soll, wie unter 3. schon erwähnt, über den Mediator erfolgen.

Folgende Informationen sind für die einzelnen Aktionen nötig:

Aktion	Information
EC-Karte einführen	Account-Nummer
PIN eingeben	PIN
Geld überweisen	Fremd-Account-Nummer, Betrag

3.3 ATM-Modul

Das ATM-Modul verwendet das State-Pattern um die verschiedenen Zustände, die während der Bedienung eines ATMs möglich sind, zu handhaben. Folgendes State-Diagramm beschreibt die möglichen Zustände und ihre Übergänge:

Jegliche Kommunikation mit anderen Modulen soll auch hier über den Mediator erfolgen.

3.3.1 Transaktionslog

Wenn eine Geldüberweisung durchgeführt wird, wird die entsprechende Transkation in den beiden Accounts hinterlegt. Zusätzlich soll ein Snapshot dieser Überweisung in einem Transaktionslog gesichert werden. Dieser Transaktionslog wird in Memory gehalten und muss nicht persistiert werden.

Ein Snapshot besteht aus folgenden Informationen:

• aktuellen Zeitstempel
• Quell-Account der Transaktion
• Ziel-Account der Transaktion
• der Betrag (Transaktion)

Um zu verhindern, dass ein solcher Snapshot im Nachhinein durch Veränderungen am Account ebenfalls verändert wird, soll mithilfe des Prototyp-Patterns eine neue Instanz der beiden Accounts im Snapshot gespeichert werden. Achten Sie darauf, dass auch von den Transaktionen des Accounts eine neue Instanz erstellt wird (Deep-Copy).