Ein Bild entsteht - EBC im Web (Teil 1)

malen Vor einiger Zeit habe ich damit begonnen das Paradigma EBC in meinen Arbeitsgebrauch auf zu nehmen. Inzwischen sind ein paar Beispiele entstanden und auch viele Beiträge in den Diskussionsgruppen. Aber alles was bis dahin entstanden ist, kann man mehr unter dem Lichte des Proof of Concept sehen.
Um die EBC Technologie weiter voran zu treiben, braucht sie Beispiele. Vor allem welche, die man nachvollziehen kann. Nun das klingt logisch, doch wie so oft liegt der Teufel im Detail.
  • Welche Art von Applikation?
  • Wie realistisch sollte sie umgesetzt werden?
  • Wie geht man mit Veränderung um?
  • Und, wie geht man grundsätzlich an die Umsetzung eines solchen Beispiels heran?
Das alles sind Fragen, die ich mir in den letzten Tagen immer wieder gestellt habe, bis ich zu dem Schluss gekommen bin, das Ganze schrittweise umzusetzen und nicht Alles im Voraus durch zu planen. 
Ich beginne also ganz einfach mit der Ideenfindung, dann erfinde ich sinnvolle Leistungsanforderungen, finde die Domänen- und Datenobjekte, formuliere die Prozesse im System und zu guter Letzt versuche ich das Konzept auch noch in Code umzusetzen.
Das sollte machbar sein.

Was für eine Idee...

In der heutigen Zeit ist es schon fast eine Beleidigung, wenn man keine Web-Applikation als Beispiel anbietet und um mich diesem ... zu unterwerfen, habe ich, was für ein Wunder, beschlossen eine Web-Applikation zu entwickeln, die im Bereich datengetriebene Applikation angesiedelt ist. Aus gegebenem Anlass wähle ich ein Projekt aus meinem näheren Umfeld.
Ich möchte ein Bezahlsystem umsetzen, das in einer Web-Applikation eingebettet ist, um erweiterte Inhalte einem Anwender zur Verfügung stellen zu können.

Die Story

“Die Kunden möchten erweiterte Inhalte zum Standard einer Web-Applikation nutzen. Die erweiterten Inhalte sind kostenpflichtig. Um dem Kunden dieses Inhalte zur Verfügung stellen zu können muss er zu seinen schon bekannten Profildaten, Bezahlinformationen hinterlegen und die Art des Bezahlproduktes angeben.”
Das klingt nicht schwer. Zumal der gesamte Bezahlprozess durch einen Dienstleister zur Verfügung gestellt wird. Ihm reichen ein paar Daten zu einem Kunden aus und anschließend übernimmt er die Konto- und Bonitätsprüfung, Kreditkarten Check usw. usf. Ich konzentriere mich also auf wenige Prozesse rund um die Datenvalidierung und die Statusmeldungen vom Bezahldienstleister.
Damit ist die Idee des Beispiels formuliert. Nun “erfinde” ich die Leistungen des Systems und greife abermals in die Kiste der mir schon bekannten Spezifikationen.

Die Story als Konzept

Da ich es mag mit Bildern zu kommunizieren und auch der UML nicht abgeneigt bin, formuliere ich die geforderten Leistungen des Systems in einem Use Case Diagram. Um sicher zu stellen, dass das Diagramm korrekt verstanden wird, möchte ich einmalig den Inhalt des Diagramms zusätzlich in Worten beschreiben.
Leistungsbeschreibung
Leistungen des Systems
Der Anwender ist der Akteur des Systems, er erwartet Leistungen vom System, die seinen Wunsch, kostenpflichtige Inhalte nutzbar zu machen, erfüllen. Die folgenden Leistungen sollen vom System bereitgestellt werden.
  • Der Anwender kann eine Buchung durchführen,
  • Die Buchung besteht aus den Schritten:
    • Produkt auswählen,
    • Rechnungsanschrift eingeben und
    • Zahlungsart auswählen,
  • Eine Buchung wird mit einer Email bestätigt und
  • Die Daten der Zahlungsarten werden während des Buchungsvorganges verifiziert.
Damit ist das Grundgerüst für die Applikation in Form einer Leistungsbeschreibung aufgestellt worden. Der nächste Schritt wird sein, die Domäne und die Dazugehörigen Daten zu beschreiben.
Soweit so gut, damit der Post nicht zu lang wird, möchte ich die Beschreibung der Domäne und der Daten in einem nächsten Post veröffentlichen.

Jan