Videoautomat Desktop

Aus Salespoint

Version vom 18:57, 5. Apr. 2009

Einleitung

Frameworks erleichtern die Programmierarbeit in vielerlei Hinsicht. Sie können Datenstrukturen und Prozesse eines bestimmten Anwendungsgebietes vordefinieren und darüber hinaus einen sauberen Entwurf erzwingen. Dennoch bedeutet ihre Verwendung zunächst einen erhöhten Einarbeitungsaufwand für den Programmierer. Um diesen zu minimieren wurde die folgende Abhandlung geschrieben. Grundlage für das Verständnis dieses Tutorials ist der Technische Überblick über das Framework SalesPoint. Wer diesen bisher noch nicht gelesen hat, wird gebeten diese Abkürzung zu nehmen.

Auf Basis von SalesPoint wird exemplarisch ein Videoautomat Schritt für Schritt zusammengesetzt. Dabei wird dem Leser empfohlen die einzelnen Schritte per copy & paste selbst zu vollziehen. Darüber hinaus wird an geeigneten Stellen dazu aufgefordert, das Programm zu kompilieren und auszuführen, um den Zusammenhang von SalesPoint-Konstrukten und Anzeige zu verdeutlichen. Zunächst wird der zu entwickelnde Automat anhand der vom Automatenbetreiber formulierten Anforderung kurz umrissen.

Aufgabenstellung

Die Videothek HOMECINEMA bietet mit Hilfe eines Videoverleihautomaten einen vereinfachten 24-Stunden-Service an: Am Videoverleihautomaten erhalten registrierte, erwachsene Kunden Videobänder gegen Bezahlung. Die Rückgabe der Bänder soll ebenfalls möglich sein. Der Automat hat ein Sortiment von 10 Filmen, die in je 5 Exemplaren vorhanden sind.

Überblick

Im weiteren Verlauf, werden einige Annahmen gemacht, die kurz erläutert werden müssen. Es wird davon ausgegangen, dass die Videoautomaten von HOMECINEMA untereinander nicht vernetzt sind. Somit können die Automaten als eigenständige, vollfunktionstüchtige Verkaufs- bzw. Verleihstellen betrachtet werden und das zu entwerfende Programm repräsentiert genau einen Automaten. Ein Automat besitzt genau ein Display, vorstellbar wäre ein Touch-Screen, als Interaktionsfläche für die Kunden und den Betreiber. Eine Person meldet sich an, autorisiert durch ein Kennwort und kann entsprechend ihrer Berechtigungen Verleih-, Rückgabe- oder administrative Vorgänge vollführen. Übertragen auf die Framework-Konstrukte bedeutet das, dass es neben dem Shop genau einen SalesPoint geben wird. Auf diesem laufen die verschiedenen Vorgänge. Diese Vorgänge werden jeweils als SaleProcess implementiert und dienen der Interaktion mit dem Nutzer, dem User. Abbildung 1.1 fasst diese essentiellen Zusammenhänge noch einmal in einem UML-Klassendiagramm zusammen.

Hinweis: Der Name der Oberklasse wird in einem UML-Klassendiagramm in dem Klassenkasten rechts oben notiert. Beispielsweise sagt das untenstehende Diagramm aus, dass VideoShop von der Klasse Shop erbt.

vereinfachtes Klassendiagramm Abbildung 1.1: vereinfachtes Klassendiagramm

Außerdem sind in dem Diagramm noch diverse Datenstrukturen als Attribute von VideoShop und AutomatUser zu sehen. Zum Einen dient ein MoneyBag, welches eine Spezialisierung von Stock ist, dem Aufbewahren der verschiedenen Geldscheine und -stücke, zum Anderen wird ein CountingStock benötigt, der die verfügbaren Videos des Automaten verwaltet. Beide Bestände beziehen die verfügbaren Elemente von jeweils einem Catalog. Die Klasse EUROCurrencyImpl stellt dabei den Währungskatalog dar.

Hinweis: Die Namen der Attribute stimmen im übrigen nicht mit denen in der Implementation überein.

Die entliehenen Videos des Kunden werden im Gegensatz zum VideoShop in einem StoringStock gespeichert, da in diesem Fall die einzelnen Videos entsprechend ihres Ausleihdatums unterschieden werden müssen. Wer mit der Unterscheidung zwischen Storing- und CountingStock oder von Katalogen und Beständen Probleme hat, sollte noch einmal den Technischen Überblick aufsuchen.

Details zu den obigen und den weiteren Entwurfsentscheidungen werden im Verlauf des Tutorials näher erläutert. Teilweise werden bewusst für dieses Beispiel nicht unbedingt notwendige Konstruktionen gewählt, an anderer Stelle wird vereinfacht, um einen kompakten und möglichst umfassenden Einblick in SalesPoint zu gewährleisten.

Hinweise

Auf den folgenden Seiten wird nahezu jeder einzelne Programmierschritt erläutert,wobei auf import-Anweisungen verzichtet wird, um die Übersichtlichkeit zu erhöhen. Es sei an dieser Stelle jedoch noch einmal ausdrücklich darauf hingewiesen, dass sofern eine Klasse oder Methode vom Compiler als unbekannt zurückgewiesen wird, möglicherweise lediglich ein import vergessen wurde. Sofern keine moderne Integrated Development Environment benutzt wird, die entsprechende import-Anweisungen automatisch ergänzen kann, wird empfohlen, einen Blick in das Application Programming Interface (API) von SalesPoint zu werfen, um die Paketzugehörigkeiten festzustellen.

In den Codebeispielen sind Abschnitte, die bereits erläutert und daher weggelassen wurden, durch drei Punkte angedeutet.

Trotz mehrmaligem Korrektur-Lesen lässt es sich nicht vermeiden, dass die vorliegende Dokumentation noch Rechtschreibfehler sowie Fehler in Codeabschnitten enthalten kann. Für entsprechende Korrekturmeldungen ist der Autor dieser Seiten dankbar.

Der Grundaufbau

Aufbau des Shops

Begonnen wird mit der zentralen Klasse einer jeden SalesPoint-Anwendung, dem Shop. Es wird eine neue Klasse VideoShop erzeugt, als Ableitung von Shop.

Der Konstruktor von VideoShop ruft den Konstruktor der Oberklasse durch den Befehl super() auf.

package videoautomat;
public class VideoShop extends Shop {
    public VideoShop() {
        super();
    }
}

Hinweis: In diesem Beispiel des Videoautomaten wird jede Klasse in einer separaten Datei gespeichert. Die Klassen des Automaten werden zu einem Paket videoautomat zusammengefasst. Klassen eines Pakets werden normalerweise in einem Verzeichnis gespeichert, das den Namen des Pakets trägt. Darüberhinaus muss am Anfang einer Klasse eine Zeile der Form: package paketname; stehen, die aussagt, welchem Paket die Klasse angehört.

Um die Anwendung ausführen zu können, ist eine Klasse erforderlich, die die von der Java Virtual Machine zur Ausführung benötigte main-Methode implementiert. Zu diesem Zweck wird eine neue Klasse MainClass angelegt. In der main-Methode wird eine Instanz von VideoShop erzeugt, welche an die statische Methode Shop.setTheShop(Shop s) übergeben wird. Dieser Aufruf bewirkt, dass die übergebene Instanz zur einzigen und global erreichbaren erhoben wird. Auf diese globale Instanz kann über die ebenfalls statische Methode Shop.getTheShop() von überall aus zugegriffen werden. Das hier angewandte Entwurfsmuster Singleton ist insofern zweckmäßig, da über dieses einzelne Shopobjekt nahezu alle global benötigten Daten gekapselt werden können.

Hinweis: Statisch bedeutet, die Variable oder die Methode ist keine Eigenschaft der Instanz sondern eine Eigenschaft der Klasse selbst und ist somit unabhängig vom Zustand des Objektes. Shop.getTheShop() ist statisch und kann auf der Klasse Shop aufgerufen werden. Eine statische Variable wird von allen Instanzen einer Klasse geteilt und kann z.B. genutzt werden, um die Anzahl der erzeugten Instanzen zu zählen oder Informationen zwischen ihnen auszutauschen. D.h. alle Instanzen haben Zugriff auf ein und die selbe Variable und können diese ungewollt überschreiben. Der Einsatz von static muss wohl bedacht sein, sonst können z.B. zwei unabhängige SalesPoints sich gegenseitig den aktuellen Bargeldbestand überschreiben, wenn dieser auf statische Weise gespeichert ist. Statische Variablen bergen also eine gewisse Gefahr und werden üblicher Weise für Konstanten verwendet, die für alle Instanzen gleich bleiben.

Zuletzt wird noch ein Aufruf ergänzt, der die Instanz von VideoShop zur Ausführung bringt.

package videoautomat;
public class MainClass {
 
	public static void main(String[] args) {
		VideoShop myTutorialShop = new VideoShop();
		Shop.setTheShop(myTutorialShop);
		myTutorialShop.start();
	}
}

Nun existiert bereits eine lauffähige Anwendung. Nach der erfolgreichen Übersetzung des Programms und der Ausführung von MainClass öffnet sich das Shopfenster, so wie es durch das Framework vordefiniert ist. Machen Sie sich ein wenig damit vertraut. Einstellungen wie Auflösung, Fensterposition und Windowmode werden nach Beenden der Anwendung automatisch in die erstellte salespoint.config gespeichert, welche nach einem Refresh auftauchen sollte.

Der Videoautomat

Die eigentliche Interaktion mit der Anwendung findet aber nicht über das Shopfenster statt, sondern über die Klasse SalesPoint. In dieser Anwendung soll VideoAutomat diese Klasse implementieren:

package videoautomat;
public class VideoAutomat extends SalesPoint {
 
	public VideoAutomat() {
		super(VideoShop.CAPTION_AUTOMAT);
	}
}

Der Konstruktor der Klasse SalesPoint erwartet einen String, welcher als Identifikationsmerkmal dient und unter Anderem im Fensterrahmen angezeigt wird. Entsprechend muss auch beim Aufruf von super() ein String übergeben werden. Um die darzustellenden Strings leichter und an einer Stelle bearbeiten zu können, wird eine String-Konstante im VideoShop zur Verfügung gestellt. Wie man erkennen kann, wird diese Variable statisch verwendet und durch final vor weiteren Änderungen geschützt.

public class VideoShop extends Shop {
		.
		.
		.
    public static final String CAPTION_AUTOMAT = "VIDEOAUTOMAT RLD";
		.
		.
		.
}

Damit der Automat auch sichtbar ist, muss die Klasse VideoAutomat instantiiert und beim Shop angemeldet werden. Dazu wird folgende Zeile der main-Methode in MainClass angefügt:

public class MainClass {
    public static void main(String arqs[]) {
		.
		.
		.
        myTutorialShop.addSalesPoint(new VideoAutomat());
    }
}

Bei erneuter Übersetzung und Ausführung erscheint nun, zusätzlich zu dem Shopframe, der Videoautomat mit dessen Standard-FormSheet.

Das Menü des Ladens

Damit nach dem Schließen des Videoautomaten die Anwendung nicht jedesmal neu gestartet werden muss, um diesen zu rekonstruieren, wird als nächster Schritt das Menü des Shopfensters erweitert.

Derzeit besteht das Menü des Videoladens aus den Untermenüs Shop, mit der Möglichkeit einen der möglicherweise mehreren Salespoints auszuwählen sowie dem Database-Manager mit dem man das Speichersystem modifizieren kann und MultiWindow, in welchem gewählt werden kann, ob die verschiedenen Frames der Anwendung in separaten Fenstern oder in Registerkarten innerhalb des Shopfensters angezeigt werden sollen. Das Menü soll im Folgenden um einen Eintrag ergänzt werden, dessen Aktivierung eine neue Instanz der Klasse VideoAutomat erzeugt und dem Videoladen hinzufügt.

Dafür muss die Methode createShopMenuSheet() der Klasse VideoShop überschrieben werden. Sie liefert wie der Name schon sagt das MenuSheet des Ladens. Die Klasse MenuSheet kapselt den Namen des Menüs, wie z.B. MultiWindow. Ein Menü kann darüberhinaus weitere MenuSheet-Instanzen beinhalten - die Untermenüs. Außerdem kann eine MenuSheet-Instanz Objekte der Klasse MenuSheetItem beinhalten, diese sind ähnlich wie Buttons direkt mit einer Aktion verknüpft.

Im Beispiel wird zunächst das Standard-MenuSheet des Ladens über den Aufruf super.createShopMenuSheet() zurückgegeben. Diesem wird ein neues Untermenü zugeordnet, welchem zuvor eine neue Instanz von MenuSheetItem zugefügt worden ist. Dem Konstruktor des Menüeintrags muss eine Implementation des Interface Action übergeben werden.

public class VideoShop extends Shop {
		.
		.
		.
	protected MenuSheet createShopMenuSheet() {
        MenuSheet ms_default = super.createShopMenuSheet();
        MenuSheet ms_new = new MenuSheet(MS_NEW);
        MenuSheetItem msi_automat =
            new MenuSheetItem(MSI_AUTOMAT, new Action() {
            public void doAction(SaleProcess p, SalesPoint sp)
                throws Throwable {
                addSalesPoint(new VideoAutomat());
            }
        });
        ms_new.add(msi_automat);
        ms_default.add(ms_new);
        return ms_default;
    }
}

Hinweis: Das Interface Action gehört dem Package sale des Frameworks an und darf nicht mit javax.swing.Action verwechselt werden.

Die zu implementierende Methode doAction(SaleProcess process, SalesPoint point) des Interface definiert, was innerhalb der Aktion geschieht. In diesem Fall erfolgt die Implementierung des Interfaces durch eine sogenannte anonyme Klasse. Alternativ kann eine neue Klasse erstellt werden, die eine doAction Methode enthält. Die Verwendung anonymer Klassen erschwert die Lesbarkeit und Wiederverwendbarkeit des Quelltextes. Sie sollten nur verwendet werden, wenn ihr Inhalt nur einmal vorkommt oder der Zugriff auf Methoden und Ressourcen schwierig ist, wenn sie als eigene Klasse implementiert sind. Später wird gezeigt, wie Action-Klassen als eigene wiederverwendbare Klassen genutzt werden können. Im konkreten Fall hier wird in der doAction-Methode einfach eine Instanz von VideoAutomat erzeugt und mittels addSalesPoint(SalesPoint sp) beim Laden angemeldet. Der Name des Untermenüs sowie der des Menüeintrags werden in der Klasse VideoShop definiert.

public class VideoShop extends Shop {
		.
		.
		.
    public static final String MS_NEW = "Videoautomat";
    public static final String MSI_AUTOMAT = "Start automat";
    public static final String MSG_ACCESS = "Acces denied!!!";
}

Nach erneuter Übersetzung und Ausführung kann ein neuer Videoautomat über den entsprechenden Eintrag im Menü des Shopfensters gestartet werden.

Der Videokatalog

Die Videos eines Automaten zeichnen sich durch einen Titel und die jeweilige Anzahl, sowie den Einkaufspreis für den Betreiber und den Verkaufspreis für den Kunden aus. Entsprechend bietet sich zu ihrer Datenhaltung ein CountingStock an. Ein solcher Bestand referenziert auf die Einträge des ihm zugeordneten Katalogs und speichert deren verfügbare Anzahl. Die Katalogeinträge wiederum besitzen die Attribute Bezeichnung und Preis.

Dem entsprechend wird zunächst ein Catalog benötigt, der die Videonamen und -preise enthält. Da es sich dabei um ein Interface handelt, bedarf es einer Klasse, die dieses Schnittstellenverhalten implementiert. Im Framework existiert bereits eine vordefinierte Klasse namens CatalogImpl, die für die meisten Zwecke ausreichen dürfte. Der Konstruktor dieser Klasse verlangt einen Bezeichner, der den Katalog eindeutig von anderen unterscheidet. Es wird zunächst folgende Zeile der Klasse VideoShop hinzugefügt:

public class VideoShop extends Shop {
    public static final CatalogIdentifier<CatalogItemImpl> C_VIDEOS = 
                        new CatalogIdentifier<CatalogItemImpl>("VideoCatalog");
		.
		.
		.
}

Diese Konstante soll der künftige Bezeichner für den Videokatalog sein. Kataloge werden in SalesPoint (ähnlich der Java Collection API) nach den ihren Einträgen getypt. Dasselbe gilt für ihre Bezeichner. Um nicht immer die generischen Parameter mit angeben zu müssen ist es zweckmäßig eine eigene Klasse dafür anzulegen:

package videoautomat;
 
public class VideoCatalog extends CatalogImpl<CatalogItemImpl> {
	public VideoCatalog(CatalogIdentifier<CatalogItemImpl> id) {
		super(id);
	}
}

Der Katalog wird im Konstruktor von VideoShop wie folgt instantiiert:

public class VideoShop extends Shop {
		.
		.
		.
    public VideoShop() {
		.
		.
		.
        addCatalog(new VideoCatalog(C_VIDEOS));
    }
}

Der Videokatalog ist durch die Aufnahme in die Katalogsammlung des Ladens von jeder Klasse der Anwendung aus erreichbar, jedoch ist der Aufruf, um an den Katalog zu gelangen unangenehm lang und wird vermutlich mehr als einmal verwendet. Zur Erleichterung wird eine statische Hilfsmethode in der Klasse VideoShop geschaffen, die den Videokatalog zurückgibt.

public class VideoShop extends Shop {
		.
		.
		.
	public static VideoCatalog getVideoCatalog() {
		return (VideoCatalog) Shop.getTheShop().getCatalog(C_VIDEOS);
	}
}

Nun existiert zwar ein Katalog, jedoch ohne Einträge. Damit im weiteren Verlauf des Programmierens und Testens einige Daten zur Verfügung stehen, wird die MainClass um folgende Methode ergänzt:

public class MainClass {
		.
		.
		.
	public static void initializeVideos() {
 
		VideoCatalog videoCatalog = VideoShop.getVideoCatalog();
		Category c1 = new Category("Action");
		Category c2 = new Category("Science Fiction");
		List<Video> videos = new ArrayList<Video>();
		try {
			videos.add(new Video("Event Horizon", "event_horizon", 1999, c2));
			videos.add(new Video("H.E.A.T.", "heat", 1999, c1));
			videos.add(new Video("Matrix", "matrix", 1499, c2));
			videos.add(new Video("Sin City", "sin_city", 2199, null));
			videos.add(new Video("Taken (Blue-Ray)", "taken", 3199, c1));
			videos.add(new Video("Terminator", "terminator", 999, c1));
			videos.add(new Video("Terminator 2", "terminator2", 999, c1));
			videos.add(new Video("Terminator 3", "terminator3", 1299, c1));
			videos.add(new Video("True Lies", "true_lies", 999, c1));
			videos.add(new Video("The X-Files", "xfiles", 999, c2));
		} catch (URISyntaxException e) {
			e.printStackTrace();
		} catch (NullPointerException e) {
			e.printStackTrace();
		}
 
		for (Video video : videos) {
			videoCatalog.add(video, null);
		}
	}
}

Was hier passiert ist relativ leicht ersichtlich. Wir holen uns zuerst den VideoKatalog aus dem Shop mit der vorhin erstellten Methode getVideoCatalog(), erstellen daraufhin 2 Kategorien in unserem Anwendungsfall Genres, nach denen wir später die Videos besser sortieren können und fügen dann nach und nach einzelne Videos mit Titel,Bildtitel, Preiswert in Cent und Genrekategorie in eine zuvor erstellte Arraylist ein, aus der wir in der For-Schleife zum Schluss alles in unseren Katalog schieben. Was uns dazu fehlt ist natürlich die VideoKlasse die von CatalogItemImpl erbt, um in unseren VideoCatalog zu passen und Descriptive und Categorizable implementiert, um das später implementierte Descriptive-Formsheet zu ermöglichen und die Categories nutzbar zu machen. Dem Konstruktor von CatalogItemImpl muss mindestens ein String und ein Value übergeben werden. Value ist ein Interface und es existieren zwei Implementationen dieser Schnittstelle im Framework. Zum Einen NumberValue, welches einen numerischen Wert kapselt und QuoteValue, das ein Paar von Werten repräsentiert, z.B. einen Ein- und Verkaufswert. In diesem Fall wird dem Konstruktor unter anderem eine Instanz von QuoteValue übergeben, welche wiederum mit zwei IntegerValue erzeugt wird. IntegerValue ist lediglich eine Spezialisierung von NumberValue, welche einen int-Wert kapselt, der hierbei der Wert in Cent ist. Der RecoveryConstructor ist nötig für die DB-Speicherung. HINWEIS FÜR DEN FREEKY!!!!!!!!!!!!!!!! Der ResourceManager dient hier primär zum Beschaffen von binären Formaten wie vor allem Bildern. Hier ruft er über den Typ PNG, im Projektordner res die einzelnen Bilder ab. Diese entweder dem downloadbaren Sourceverzeichnis entnehmen oder einfach den Aufruf durch null ersetzen.

package videoautomat;
 
public class Video extends CatalogItemImpl implements Descriptive, Categorizable {
 
 
 
	private Category category = null;
 
 
 
	@RecoveryConstructor(parameters = { "m_sName" })
 
	public Video(String name) {
 
		super(name);
 
	}
 
 
 
	public Video(String name, String image, int price, Category category)
 
			throws URISyntaxException, NullPointerException {
 
		super(name, new QuoteValue(new IntegerValue(250), new IntegerValue(
 
				price)), ResourceManager.getInstance().getResource(
 
				ResourceManager.RESOURCE_PNG, "videos." + image).toURI());
 
		this.category = category;
 
	}
 
 
 
	protected CatalogItemImpl getShallowClone() {
 
		return null;
 
	}
 
 
 
	public StyledDocument getDescription() {
 
		StyledDocument styledDocument = new DefaultStyledDocument();
 
		SimpleAttributeSet attributes = new SimpleAttributeSet();
 
		try {
 
			styledDocument.insertString(0, "This is the Description for ", attributes);
 
			ColorConstants.setForeground(attributes, Color.GREEN);
 
			FontConstants.setFontSize(attributes, 16);
 
			styledDocument.insertString(styledDocument.getLength(), getName(), attributes);
 
		} catch (BadLocationException e) {
 
			e.printStackTrace();
 
		}
 
		return styledDocument;
 
	}
 
 
 
	public Category getCategory() {
 
		return category;
 
	}
 
 
 
}

Abschließend wird in der main-Methode der MainClass die neue Methode zur Ausführung gebracht, damit die Änderungen wirksam werden. Wir nutzen dazu die Methode initializeData zur Kapselung, da diese später aus dem DatabaseManager jederzeit über den gleichnamigen Button dort aufgerufen werden kann, was die Dinge durchaus erleichtert.

public class MainClass {
    public static void main(String arqs[]) {
		.
		.
		.
	public void initializeData() {
		initializeVideos();
 
	}  
    }
		.
		.
		.
}

Der Videobestand

Nach der Fertigstellung des Katalogs kann im Folgenden der Bestand aufgebaut werden. Wie bereits im Abschnitt Der Videokatalog erwähnt, sollen die Videos des Automaten in einem CountingStock gespeichert werden. Auch für dieses Interface existiert eine vordefinierte Klasse mit dem gewohnten Impl am Ende des Namens. Ein jeder Bestand bezieht sich auf einen Katalog, so dass dieser konsequenterweise neben dem String-Bezeichner dem Konstruktor von CountingStockImpl übergeben werden muss. Ähnlich den Katalogen sind auch die Bestände nach ihren Einträgen getypt, zusätzlich aber auch noch mit den Eintragstypen des zugehörigen Katalogs. Allein aus diesem Grund lohnt es sich, eine eigene Klasse hierfür zu definieren:

package videoautomat;
 
public class AutomatVideoStock extends
		CountingStockImpl<StockItemImpl, CatalogItemImpl> {
	public AutomatVideoStock(
			StockIdentifier<StockItemImpl, CatalogItemImpl> siId,
			Catalog<CatalogItemImpl> ciRef) {
		super(siId, ciRef);
	}
}

StockItemImpl ist dabei die Standardimplementation eines Bestandseintrages. Wir werden später noch einmal etwas genauer darauf zurückkommen. Am Anfang der Shop-Klasse muss der Identifikator für den neuen Bestand deklariert werden:

public class VideoShop extends Shop {
			.
			.
			.
      public static final StockIdentifier<StockItemImpl, CatalogItemImpl> CC_VIDEOS = 
                          new StockIdentifier<StockItemImpl, CatalogItemImpl>("VideoStock");
			.
			.
			.
}

Jetzt können wir den eigentlichen Stock anlegen. Dazu wird analog zum Videokatalog in den Konstruktor von VideoShop folgende Zeile eingefügt:

public class VideoShop extends Shop {
		.
		.
		.
    public VideoShop() {
		.
		.
		.
        addStock(new AutomatVideoStock(CC_VIDEOS, getCatalog(C_VIDEOS)));
    }
		.
		.
		.
}

Auch beim Videobestand lohnt es sich eine Hilfsmethode zu schreiben, die selbigen zurückliefert.

public class VideoShop extends Shop {
		.
		.
		.
        public static AutomatVideoStock getVideoStock() {
		return (AutomatVideoStock) Shop.getTheShop().getStock(CC_VIDEOS);
	}
}

Der neue Bestand ist wiederum leer. Durch das Hinzufügen einer Zeile in die Initialisierungsmethode der Videos in MainClass können dem Videobestand die benötigten Testdaten zugefügt werden.

public static void initializeVideos() {
 
		VideoCatalog videoCatalog = VideoShop.getVideoCatalog();
		AutomatVideoStock videoStock = VideoShop.getVideoStock();
                .
                .
                .
 
		for (Video video : videos) {
			.
			videoStock.add(video.getName(), 5, null);
		}
	}

Der Aufruf add(String id, int count, DataBasket db) bewirkt, dass von dem Katalogeintrag mit der Bezeichnung id insgesamt count-Stück in den Bestand aufgenommen werden. Der DataBasket, der zum Schluss übergeben wird, hat etwas mit der Sichtbarkeit der vollführten Aktion zu tun. Vorerst reicht es zu wissen, dass hier durch die Übergabe von null das Hinzufügen unmittelbar wirksam wird.

Zum Schluss noch die Klasse, die StockItemImpl erbt und es uns dadurch möglich macht später auf unserem VideoStock zu arbeiten.

package videoautomat;

public class VideoCassette extends StockItemImpl {

@RecoveryConstructor(parameters = { "m_sName" }) public VideoCassette(String key) { super(key); }

}

StandardFormsheet

Wie im Technischen Überblick erläutert wird, kann auf einem Display ein FormSheet und/oder ein MenuSheet angezeigt werden.

Als Bgegrüßungsschirm reicht uns unser schönes Standardformsheet vollkommen, jedoch müssen neue Buttons eingefügt werden. Das Anpassen des StandardFormsheets eines SalesPoints geschieht durch das Überschreiben der Methode getDefaultFormSheet().So zum Beispiel in der Klasse VideoAutomat.

protected FormSheet getDefaultFormSheet() {
		FormSheet fs = super.getDefaultFormSheet();
		fs.addContentCreator(new StartFSContentCreator());
 
		return fs;
	}

Hier holen wir uns lediglich das StandardFormsheet der Parentklasse und ergänzen es um einen Contentcreator, welcher eine Möglichkeit darstellt Buttons und Anzeigen zu kapseln, jedoch nicht erforderlich ist.

Der FormSheetContentCreator

Die Anordnung der Elemente eines Formulars kann in einem FormSheetContentCreator vorgenommen werden, der dann dem Formular zugefügt wird.

Zur Anpassung der Buttonleiste wird dementsprechend ein FormSheetContentCreator in der Erzeugermethode definiert und dem Tabellenformular hinzugefügt. FormSheetContentCreator ist eine abstrakte Klasse und fordert zur Ableitung der Klasse und Implementierung der Methode createFormSheetContent(FormSheet fs) auf. Die Implementierung könnte an dieser Stelle als anonyme Klasse erfolgen, jedoch bietet eine eigene Klasse einige Vorteile. Es wird die Trennung zwischen Anwendungslogik und Oberfläche verbessert, was später besonders bei den Prozesses deutlich wird. Außerdem kann dieser FormSheetContentCreator so für mehrere FormSheets wiederverwendet werden.

package videoautomat.contentcreator;
public class StartFSContentCreator extends FormSheetContentCreator {
	public static final int FB_LOGON = 1;
 
	public static final int FB_REGISTER = 2;
 
	protected void createFormSheetContent(FormSheet fs) {
		fs.removeAllButtons();
 
		fs.addButton("Login", FB_LOGON, new RunProcessAction(
				new SaleProcessLogOn()));
 
		fs.addButton("Register", FB_REGISTER, new RunProcessAction(
				new SaleProcessRegister()));
	}
 
}

Die Methode removeAllButtons() tut das, was der Name verspricht, während addButton(String name, int id, sale.Action a) einen Formbutton erzeugt und dem Formular hinzufügt. Formbutton ist die Framework-Version eines Buttons und besitzt eine Beschriftung, eine ID zur eindeutigen Unterscheidung und eine mit diesem Knopf assoziierte Aktion. Die ID kann unter anderem dazu verwendet werden, einen Button außerhalb der Deklaration des FormSheet referenzieren zu können. Dies ermöglicht z.B. nachträglich die Aktion des Buttons zu verändern. Es sollten jedoch alle Änderungen der Darstellung an einer Stelle erfolgen, um die Übersicht behalten zu können und den Quelltext les- und wartbarer zu halten, besonders wenn mehrere Teammitglieder am gleichen Programm arbeiten. Hier wird beispielsweise die RunProcessAction genutzt, um den Code zum Starten eines Prozesses wiederzuverwenden. Dies ist keine Framework-Klasse und sieht folgendermaßen aus:

package videoautomat.contentcreator.stdactions;
public class RunProcessAction implements Action {
	private SaleProcess process;
 
	private DataBasket basket;
 
	public RunProcessAction(SaleProcess process) {
		this.process = process;
	}
 
	public RunProcessAction(SaleProcess process, DataBasket basket) {
		this.process = process;
		this.basket = basket;
	}
 
	public void doAction(SaleProcess saleProcess, SalesPoint salePoint)
			throws Throwable {
		if (basket != null)
			salePoint.runProcess(process, basket);
		else
			salePoint.runProcess(process);
	}
 
}

Sie ist im Package videoautomat.contentcreator.stdactions; abgelegt und implementiert das Interface Action. Im ersten Konstruktor wird die Instanz des Prozesses übergeben, der durch diese Aktion gestartet werden soll. Im zweiten Konstruktor wird zusätzlich ein DataBasket übergeben, der beim Starten des Prozesses ihm zugewiesen wird. Das Starten erfolgt in der doAction Methode, die als Parameter den verwendeten SaleProcess und den SalesPoint übergeben bekommt. Somit kann auf diesem SalesPoint die runProcess Methode ausgeführt werden. Aufgrund dieser Parameterisierbarkeit, kann diese Klasse immer genutzt werden, wenn ein Prozess über eine Aktion gestartet werden soll. Man spart sich also jedesmal als anonyme Klasse das Action-Interface zu implementieren und die Anweisungen zum Starten jedesmal erneut zu schreiben.

Hinweis: Die Anordnung der Buttons ist durch die Reihenfolge ihres Hinzufügens bestimmt.

SaleProcessLogon und SaleProcessRegister sind SalesProcesses, von denen jeweils einer auf einem Salespoint aktiv laufen darf. Sie werden über die jeweiligen Buttons aufgerufen, wie oben dargestellt, aber erst später implementiert.

Der Usermanager

Bevor mit dem ersten Prozess der Anwendung, der Nutzerregistrierung, begonnen werden kann, muss die Nutzerverwaltung angelegt werden. Zur Erinnerung: es können lediglich registrierte Kunden am Automaten Filme entleihen. Entsprechend braucht die Anwendung eine Datenstruktur, anhand derer der Automat erkennen kann, wer Kunde ist und wer nicht.

SalesPoint bietet dafür die Klassen User und UserManager an.

Der Nutzermanager ist eine Art Containerklasse, in der alle Nutzer gespeichert werden. Ebenso wie beim Shop wurde bei der Klasse UserManager auf das Entwurfsmuster Singleton zurückgegriffen, d.h. es gibt genau eine Instanz des Nutzermanagers, die über UserManager.getGlobalUM() referenziert werden kann.

Der Automatennutzer

Anwender des Programms können durch die Klasse User dargestellt werden. Ein User besitzt einen Namen, über den er eindeutig identifiziert werden kann. Darüber hinaus besteht die Möglichkeit ein Passwort zu setzen, sowie Rechte auf mögliche Aktionen zu vergeben.

Damit die entliehenen Videos eines Kunden in der ihn repräsentierenden Instanz gekapselt werden können, muss eine neue Klasse von User abgeleitet werden. Abgesehen vom Kunden gibt es die Nutzergruppe der Betreiber bzw. Administratoren. Da diese sich im Prinzip nur darin unterscheiden, dass sie über mehr Rechte verfügen, genügt es, eine einzige Klasse für Kunden und Administratoren zu definieren. Die Unterscheidung bezüglich der verschiedenen Rechte erfolgt über einen Parameter im Konstruktor der neuen Klasse.

package videoautomat;
public class AutomatUser extends User implements Recoverable {
 
	public static final String CAPABILITY_ADMIN = "admin";
 
	@PersistenceProperty(follow = false)
	private UserVideoStock ss_videos = null;
 
	@RecoveryConstructor(parameters = { "m_sName" })
	public AutomatUser(String user_ID) {
		super(user_ID);
	}
 
	public AutomatUser(String user_ID, String passWd, boolean admin) {
		super(user_ID);
		setPassWd(garblePassWD(passWd));
		ActionCapability ac = new ActionCapability(CAPABILITY_ADMIN,
				VideoShop.MSG_ACCESS, new Action() {
 
					@Override
					public void doAction(SaleProcess p, SalesPoint sp)
							throws Throwable {
						UIGate gate = (UIGate) p.getCurrentGate();
						gate.setNextTransition(new Transition() {
 
							public Gate perform(SaleProcess owner, User usr) {
								return ((SaleProcessLogOn) owner)
										.getAdministrationGate();
							}
 
						});
 
					}
 
				}, admin);
		setCapability(ac);
		ss_videos = new UserVideoStock(user_ID, VideoShop.getVideoCatalog());
	}
 
	public void renderAdditionalInfoArea(JPanel panel, boolean isSelected) {
		JLabel videos = new JLabel(ss_videos.size(null) + " videos rented");
		videos.setForeground(isSelected ? Color.white : Color.gray);
		videos.setFont(new Font(null, Font.PLAIN, 14));
		panel.add(videos);
	}
 
	public UserVideoStock getVideoStock() {
		return ss_videos;
	}
 
	public void recover(Map<String, Object> data, Object recoveryContext,
			boolean reInit) {
		if (!reInit)
			ss_videos = new UserVideoStock(getName(), VideoShop
					.getVideoCatalog());
	}
 
	/**
	 * free internal resources
	 * 
	 */
	public void DatasourceOnChange() {
		super.DatasourceOnChange();
		if (ss_videos != null)
			ss_videos.unsubscribe();
	}
}

Im Gegensatz zum VideoShop werden hier die Videos in einem StoringStockImpl verwaltet. In einem solchen wird nicht nur die Anzahl gewisser Katalogeinträge gespeichert, sondern es wird jedes einzelne StockItem separat behandelt. Die Bestandseinträge der Videos werden über die Klasse VideoCassette definiert.

Ähnlich dem Videokatalog und dem Videobestand des Automaten ist es auch hier zweckmäßig (wegen der Typisierung), eine neue Klasse UserVideoStock anzulegen, die ebendiese generischen Parameter festlegt:

package videoautomat;
public class UserVideoStock extends
		StoringStockImpl<VideoCassette, CatalogItemImpl> {
	public UserVideoStock(String sName, CatalogImpl<CatalogItemImpl> ciRef) {
		super(sName, ciRef);
	}
}

Die Nutzerregistrierung

Im Gegensatz zu Katalog und Bestand des Automaten benötigen wir hier keinen eigenen Identifikator, da der UserVideoStock stets nur beim Nutzer und nie im Shop selbst registriert wird. Deswegen überladen wir auch den String - Konstruktor anstelle des Identifikator - Konstruktors.

Weiterhin ist zu erkennen, dass beim Setzen des Passworts nicht das Passwort selbst, sondern der Rückgabewert der Methode garblePassWD(passWd) übergeben wird. Dabei handelt es sich um eine Sicherheitsmaßnahme. Damit das Passwort nicht im Klartext abgespeichert wird und ausgelesen werden kann, wird es vorher umschlüsselt. Welcher Algorithmus dabei verwendet wird, kann ebenfalls über die Klasse User gesetzt werden. Der voreingestellte Algorithmus für die Umschlüsselung ist einfach umkehrbar und daher für sicherheitsrelevante Kontexte nicht zu empfehlen. Wird das Passwort mit der Methode isPassWd(String s) überprüft, ist darauf zu achten, dass der übergebene String vorher ebenfalls umschlüsselt wird.

Die boolesche Variable wird erst zu einem späteren Zeitpunkt für die Rechtevergabe benötigt.

Zum Schluss sollen einige Testkunden und ein Administrator der Nutzerverwaltung zugefügt werden. Als Passwort wird der vereinfachten Testbarkeit halber jeweils eine leere Zeichenkette übergeben.

public class VideoShop extends Shop {
		.
		.
    public void initializeData() {
		.
		initializeUsers();
	}
		.
    public static void initializeUsers() {
		try {
			UserManager.getInstance().addUser(
					new AutomatUser("Administrator", "", true));
		} catch (DuplicateUserException e) {
		}
		for (int i = 0; i < 10; i++) {
			try {
				UserManager.getInstance().addUser(
						new AutomatUser("Customer" + i, "", false));
			} catch (DuplicateUserException e) {
			}
		}
	}
    }

An dieser Stelle sind nun die Nutzerverwaltung und einige Testnutzer angelegt. Es sollen sich jedoch auch weitere Kunden registrieren können, die sich in geeigneter Weise anmelden müssen. Hierzu wird der Prozess SaleProcessRegister erzeugt, der nun im Weiteren erläutert wird.

Der Prozess fordert zur Eingabe des Nutzernamens, Passwort und Passwortwiederholung auf. Sind alle Angaben korrekt und der Nutzer existiert noch nicht, so wird er beim Klick auf OK angelegt und der Prozess endet erfolgreich. Tritt ein Fehler auf, so springt man zur Eingabemaske zurück und bekommt eine Fehlermeldung. Durch Abbrechen kann der Prozess zu jeder Zeit beendet werden, ohne dass dabei eine Änderung an den internen Daten erfolgt.

Deklaration des Prozesses

Wie im Technischen Überblick erläutert wird, ist ein SaleProcess eine Folge von Zuständen und Zustandsübergängen. Die Zustände werden dabei durch das Interface Gate, die Zustandsübergänge durch das Interface Transition beschrieben. Während eine Transition atomar behandelt, d.h. nicht unterbrochen wird, kann an einem Gate der Kontrollfluss unterbrochen werden und somit auch Interaktion mit dem Anwender stattfinden. Eine Implementation von Gate, die die Kommunikation über ein FormSheet und/oder MenuSheet ermöglicht, ist die Klasse UIGate.

Im Folgenden wird die Klasse SaleProcessRegister als Spezialisierung von SaleProcess implementiert. Dabei muss die abstrakte Methode getInitialGate() implementiert werden, welche das Start-Gate zurückliefert. Würde der Prozess weitere Gates haben, wären analog dazu weitere Methoden hinzuzufügen. Das ist sinnvoll, um die Definition und Erstellung eines Gates möglichst zentral zu haben. Alternativ wäre es auch möglich dies am Ende einer Transition auszuführen, jedoch würde das u.U. erneut die Übersichtlichkeit mindern. Bei den weiteren Prozessen im Tutorial mit mehreren Gates findet immer die erste Alternative ihre Anwendung. Etwas abweichend davon wird in diesem Prozess der ContentCreator des initialen FormSheets bei einem Zustandsübergang wiederverwendet und nicht jedesmal durch die getInitialGate()-Methode neu erzeugt. Doch mehr dazu im letzten Unterkapitel.

package videoautomat;
public class SaleProcessRegister extends SaleProcess {
    private static final long serialVersionUID = -609214820437461076L;
   public SaleProcessRegister() {
      super("Register Proecess");
   }
 
   protected Gate getInitialGate() {
 
      FormSheet register = new FormSheet("Register", 
                                 new RegisterContentCreator("Please type in your data!"), 
                                 false);
      return new UIGate(register, null);
   }
 
}

Ähnlich wie bei der Anzeige des Videobestandes wird ein FormSheet erstellt. Ihm wird im Konstruktor der Titel und ein FormSheetContentCreator übergeben. Das FormSheet selbst würde nur ein leeres Fenster darstellen. Der Inhalt wird durch die Klasse RegisterContentCreator erzeugt. Würde man nun die Anwendung übersetzen, bekäme man einen Fehler oder, falls sie doch zu starten geht, spätestens bei der Betätigung des Register-Buttons. Dies passiert, weil die Klasse RegisterContentCreator noch nicht erstellt wurde. Dies geschieht nun im nächsten Abschnitt.

Die Klasse RegisterContentCreator

Wie schon beim SingleTableFormSheet des Videobestandes, erweitert auch die Klasse RegisterContentCreator die Klasse FormSheetContentCreator. Jedoch kann diesmal ein String übergeben werden, der als Text über den Eingabefeldern erscheint.

package videoautomat.contentcreator;
public class RegisterContentCreator extends FormSheetContentCreator {
   public RegisterContentCreator(String message){
		.
		.
		.
   }
   protected void createFormSheetContent(FormSheet fs) {
		.
		.
		.
   }
}

Diese Klasse ist also konfigurierbar und man kann ihre Darstellung von außen verändern. Damit bei einer Falscheingabe der Nutzername nicht erneut eingegeben werden muss und die Werte ausgelesen werden können, bietet diese Klasse zahlreiche get- und set-Methoden. Diese stehen nur für die Daten, die gesetzt oder ausgelesen werden können. Nach außen hin sieht man also nur diese Methoden ohne eigentlich zu wissen, wie die Darstellung der Daten erfolgt. Dies ist ein wichtiger Beitrag die Oberfläche von der Anwendungslogik zu trennen. Die Klassen, die die Daten weiterverarbeiten, sind nur an diesen Methoden interessiert und nicht an ihrer visuellen Darstellung. So wird auch die Änderungsfreundlichkeit erhöht, da so leicht Oberflächenkomponenten ausgetauscht werden können ohne andere Stellen im Programm anzupassen. Die Klasse bietet folgende Methoden, deren Benutzung später gezeigt wird.

package videoautomat.contentcreator;
public class RegisterContentCreator extends FormSheetContentCreator {
   private JTextArea errorMessage;
   private JLabel message;
   private JTextField userName;
   private JPasswordField password;
   private JPasswordField confirmedPassword;
        	.
                .
                .
   public String getUserName(){
      return userName.getText();
   }
   public char[] getPassword(){
      return password.getPassword();
   }
   public char[] getConfirmedPassword(){
      return confirmedPassword.getPassword();
   }
   public void setUserName(String userName){
      this.userName.setText(userName);
   }
   public void setErrorMessage(String message){
      errorMessage.setText(message);
   }
}

Die createComponent Methode erzeugt wie bisher den darzustellenden Inhalt. Diesmal wird aber mit zusätzlichen Swing-Komponenten gearbeitet, um eine eigene Eingabemaske zu erzeugen. Sie verwendet nun die Daten, die mit den set- Methoden gesetzt wurden, um die Daten entsprechend zu visualisieren. Die get-Methoden lesen die Daten wieder aus den Swing-Komponenten aus. Die Verwendung von Swing soll an dieser Stelle nicht weiter erläutert werden, dazu finden sich zahlreiche Tutorials im Internet. Das Interessante liegt hier bei der Zuweisung der Buttons.

package videoautomat.contentcreator;
public class RegisterContentCreator extends FormSheetContentCreator {
        	.
        	.
        	.
   public RegisterContentCreator(String message){
      errorMessage      = new JTextArea();
      this.message      = new JLabel();
      userName          = new JTextField();
      password          = new JPasswordField();
      confirmedPassword = new JPasswordField();
      this.message.setText(message);
      errorMessage.setForeground(Color.RED);
      errorMessage.setBackground(this.message.getBackground());
      errorMessage.setEditable(false);
   }
   protected void createFormSheetContent(FormSheet fs) {
      JOptionPanel panel = new JOptionPanel(null, 16, 4, JOptionPanel.CENTER, JOptionPanel.CENTER);
 
      userName.setPreferredSize(new Dimension(150, 20));
      panel.addOption("User Name", userName);
 
      password.setPreferredSize(new Dimension(150, 20));
      panel.addOption("Password", password);
 
      confirmedPassword.setPreferredSize(new Dimension(150, 20));
      panel.addOption("Confirm Password", confirmedPassword);
 
      errorMessage.setPreferredSize(new Dimension(200, 50));
      panel.addOption("", errorMessage);
      fs.setComponent(panel);
      fs.removeAllButtons();
      fs.addButton("OK", 1, new TransitWithAction(new RegisterOKTransition(this)));
      fs.addButton("Cancel", 2, new RollBackAction());
   }
}

Wie bereits erwähnt, werden den Buttons wieder Action Klassen übergeben. Auch diesmal sind es wieder Hilfsklassen, die sich wiederverwenden lassen. In diesem Fall lösen diese Aktionen einen Zustandsübergang aus. Die beiden Klassen sind wieder selbst implementiert und sehen wie folgt aus:

.
               	.
               	.
public class TransitWithAction implements Action {
   private static final long serialVersionUID = 2264074797074037762L;
   private Transition transition;
   public TransitWithAction(Transition transition){
      this.transition = transition;
   }
   public void doAction(SaleProcess saleProcess, SalesPoint salePoint) throws Throwable {
      UIGate currentGate = (UIGate)saleProcess.getCurrentGate();
      currentGate.setNextTransition(transition);
   }
 
}
 
 
		.
		.
		.
public class RollBackAction implements Action {
    private static final long serialVersionUID = -6870469433795382578L;
   public void doAction(SaleProcess saleProcess, SalesPoint salePoint) throws Throwable {
      UIGate currentGate = (UIGate)saleProcess.getCurrentGate();
      currentGate.setNextTransition(GateChangeTransition.CHANGE_TO_ROLLBACK_GATE);
 
   }
 
}

Im beiden Fällen wird auf dem aktuellen Gate die Methode setNextTransition ausgeführt, um den Zustandsübergang mit einer entsprechenden Transition durchzuführen.

Im Falle des OK-Buttons wurde der Action eine spezielle Transition übergeben und dieser zusätzlich die this Referenz des RegisterContentCreator mitgegeben. Warum dies gemacht wurde und wie die Transition aussieht, wird im nächsten Abschitt erklärt.

Einen Zustandsübergang definieren

Der Technischen Überblick beschreibt, dass die internen Bearbeitungsvorgänge in einer Transition durchzuführen sind. Für diesen Fall ist das die RegisterOKTransition, die prüft, ob der Nutzer schon vorhanden ist und die beiden Passwörter übereinstimmen. Die Klasse liegt im Package transition und implementiert das Interface Transition des Frameworks. Das Interface gibt vor, dass die Methode perform(SaleProcess sp, User user) zu implementieren ist.

package videoautomat.transition;
public class RegisterOKTransition implements Transition {
    private static final long serialVersionUID = -600112154098222643L;
 
   private RegisterContentCreator creator;
   public RegisterOKTransition(RegisterContentCreator creator) {
      this.creator = creator;
   }
   public Gate perform(SaleProcess sp, User user) {
                .
                .
                .
   }
}

Wie zu erkennen ist, wird im Konstruktor die Referenz des RegisterContentCreator übergeben. Dies ist die this-Referenz aus dem vorherigen Abschnitt. Da die Transition die Daten aus der Eingabe verarbeitet, braucht sie Zugriff auf dieses Objekt. Durch die Übergabe im Konstruktor kann die perform(SaleProcess sp, User user)-Methode nun auf die Daten zugreifen und diese verarbeiten.

public Gate perform(SaleProcess sp, User user) {
      StringBuffer errors = new StringBuffer("");
      if ("".equals(creator.getUserName())){
         errors.append("You have to choose a user name!n");
      }
      if (!Arrays.equals(creator.getPassword(), creator.getConfirmedPassword())){
         errors.append("The passwords are different!n");
 
      }
 
      if (UserManager.getGlobalUM().getUserNames().contains(creator.getUserName())){
         errors.append("User already exists!n");
      }
      if (errors.length() != 0){
         creator.setErrorMessage(errors.toString());
         FormSheet register = new FormSheet("Register", creator, false);
         return new UIGate(register, null);
      }
      UserManager.getGlobalUM().addUser(new AutomatUser(creator.getUserName(), creator.getPassword(), false));
      return sp.getCommitGate();
   }

Zuerst wird geprüft, ob die Daten korrekt eingegeben wurden. Der erste Vergleich prüft, ob überhaupt ein Nutzername eingeben wurde. Fehlt der Nutzername, so wird eine Fehlermeldung vorbereitet. Der zweite Vergleich prüft die beiden Passwörter auf Gleichheit und der dritte, ob der Nutzer schon existiert. Zum Auslesen der Daten werden die jeweiligen Methoden genutzt, die der RegisterContentCreator dafür zur Verfügung stellt.

Der vierte Vergleich prüft nun, ob ein Fehler auftrat und bestimmt dann die Verzweigung. Man hätte natürlich beim ersten Auftreten eines Fehlers darauf reagieren können. So werden aber gleich alle Fehler erkannt und dem Nutzer mitgeteilt. So spart er sich u.U. mehrere Durchläufe, bis alles korrekt eingegeben ist.

Laut Zustandsübergangsdiagramm geht der Prozess zum ersten Gate zurück, wenn ein Fehler auftritt. Dies passiert im Rumpf des vierten Vergleiches. In diesem Fall wird der RegisterContentCreator wiederverwendet und nur der Fehlertext gesetzt. D.h. alle bisherigen Eingaben bleiben bestehen. Alternative hätte man auch eine neue Instanz erstellen können und über die Methoden die Eingaben gesetzt. Je nach Anwendungsfall kann man sich für den einen oder anderen Weg entscheiden.

Nach dem Setzen der Fehlernachricht wird ein neues Gate erstellt und mit dem alten RegisterContentCreator verknüpft. Anschließen wird das Gate zurückgegeben und somit als nächstes angezeigt. Anstatt das Gate hier zu erstellen, könnte man auch eine selbst definierte getGate-Methode im Prozess nutzen, und dann dieses Gate zurückgeben. Die Methode könnte auch einige Paramter haben, um, wie in diesem Beispiel, Daten an das FormSheet übermitteln zu können. Dieses Verfahren wird an späterer Stelle im Tutorial gezeigt.

Trat kein Fehler auf, so wird der Nutzer, unter Verwendung der eingegebenen und geprüften Daten, erstellt und der Prozess wechselt zum CommitGate, womit er erfolgreich beendet wäre.