In den letzten Posts habe ich eine Einführung in Xtext und Co. gegeben, welche als Technologie dazu dienen sollen, das oben genannte System umzusetzen. Nun ist es an der Zeit, einmal kurz von der Praxis wegzugehen und festzulegen, wie das System aussehen soll, d.h. welche Funktionen es besitzen soll und wie es in seiner Verwendung aussehen soll.
Dazu sind erst einmal die funktionalen Anforderungen an das System wichtig. Der Kern des Systems ist es natürlich, Akzeptanztests zu erstellen. Da wir uns hier auf datenbankgestützte Anwendungen beziehen, muss ein Akzeptanztest stets sicherstellen, dass eine bestimmte Funktion einer zu entwickelnden Software einen bestimmten Datensatz in der Datenbank ändert oder erstellt. Um dies zu überprüfen, muss der Benutzer in der Lage sein, einen Anfangszustand in der Datenbank zu beschreiben, indem er zum Beispiel bestimmte Daten erzeugt, und außerdem einen Endzustand zu bestimmen, welcher am Ende des Tests überprüft wird.
Zum Erstellen der Akzeptanztests verwendet der Benutzer eine Fachsprache, welche die nötigen Funktionen mitbringen und prinzipiell mit jeder Datenbank funktionieren muss. Um dies umzusetzen, muss die Fachsprache ein Meta-Modell verwenden, welches Datenbank-ähnliche Strukturen bietet. Für jede Datenbank muss ein konkretes (Domänen-)Modell existieren, welches auf dem Meta-Modell basiert. So sollte es möglich sein, das Akzeptanztest-System für verschiedene Domänen zu benutzen.
Nachfolgend habe ich eine Liste mit funktionalen Anforderungen an das System ausgearbeitet. Diese habe ich in Gruppen eingeteilt, dabei wird zwischen den Funktionen unterschieden, welchem unmittelbar vom Benutzer in Anspruch genommen werden und denen, die das System an sich sonst noch anbieten muss.
Funktionen bezogen auf den Benutzer/die DSL
- der Benutzer kann Anfangs- und Endzustand der Daten für einen Akzeptanztest in einer geeigneten DSL beschreiben
- die DSL muss Möglichkeiten bieten, Daten zu erzeugen, auf Vorhandensein zu überprüfen und ggf. zu löschen
- der Benutzer muss ein Modell auf Basis der Datenbank erzeugen bzw. selbst erstellen können, welches als Grundlage für die Beschreibung der Testdaten dient
- der Benutzer muss in der Lage sein, basierend auf Entitäten aus dem jeweiligen Modell eigene Fachliche Begriffe zu definieren, welche er in der DSL verwenden kann
- erstellte Akzeptanztests sollten aufeinander aufbauen können, d.h. eine DSL-Datei kann eine andere importieren und deren Definitionen weiterverwenden
- der Benutzer sollte in der Lage sein, die Akzeptanztests aus dem Programm aufzurufen
Automatische Funktionen des Systems
- das System erstellt automatisch auf dem Modell basierende Persistenz-Klassen aus dem formulierten Akzeptanztest hinaus
- formulierte Akzeptanztests müssen in Artefakte verwandelt und in einer automatisierten Umgebung nutzbar gemacht werden
- möglichst viele Funktionen sollten dem Benutzer durch Assistenten u.Ä. abgenommen werden
Erweiterte Funktionen
- das Importieren der Datenbankstruktur in eine Modell muss in Bezug auf sehr große Datenbanken auf bestimmte Schemas/einzelne Tabellen beschränkbar sein
- das System muss in der Lage sein, die technische Sicht der Datenbank von der fachlichen Sicht zu trennen (ggf. über eine Transformation im Modell)
Daraus ergeben sich auch einige nichtfunktionale Anforderungen, auf welche ich jetzt aber nicht gesondert eingehen möchte. Zu erwähnen wäre hierbei jedoch beispielsweise die leichte Benutzbarkeit des Systems, welche mit der Benutzerzielgruppe des Fachbereichsmitarbeiters bzw. Analysten einhergeht.
Basierend auf diesen Anforderungen werde ich beginnen, eine Architektur bzw. zunächst einmal einen Ablaufplan für die Verwendung und Funktionalität des Systems zu erarbeiten. Dies wird in den nächsten Beiträgen Gegenstand der Betrachtung sein.
Keine Kommentare:
Kommentar veröffentlichen