Freitag, 9. Mai 2014

Noch mehr Zusammenhänge durch die CRUD-Matrix.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Die angekündigten Qualitätsanforderungen des letzten Posts müssen noch ein bisschen warten. Nach dem Studium von [HRU14] erscheint mir eine weitere Modellierung sehr sinnvoll. Im letzten Post wurde die modellgetriebene Möglichkeit beschrieben, mit Hilfe dreier Perspektiven, Anforderungen zu modellieren. Das Klassendiagramm hat dabei die Sicht auf die Datenperspektive geöffnet und uns eine Reihe von Klassen beschert. In unserem Beispiel fanden wir drei Entity-Klassen: Lehrer, Schüler und Klasse. Wie wir alle wissen, ist eine Klasse eine Vorlage für ein zu erschaffendes Objekt. Die Klasse Lehrer ist die Vorlage für den konkreten Lehrer Michael. Er kann erschaffen werden, seine Werte können gelesen werden, sie können verändert werden und er kann gelöscht (entlassen) werden. Diese Aktionen erklären wir uns allgemein hin mit den Buchstaben C, R, U und D. C steht für Create, R für Read, U für Update und D für Delete.

Bevor wir die Datenperspektive im letzten Post diskutiert haben, behandelten wir das Modellieren von Use Cases in den Posts Wie User Stories Use Cases gebären. und Szenarien setzen sich zu Use Cases zusammen.. Ein Use Case setzte sich dabei aus genau einem Hauptszenario und ggf. mehreren Alternativ- und Ausnahmeszenarien zusammen. Innerhalb dieser Szenarien wird sich die Stelle finden, wo der konkrete Lehrer erzeugt wird. Es wird andere Szenarien, ja andere Use Cases geben, in denen die Werte des Lehrers gelesen und geändert werden. Noch ein anderer Use Case wird unter Umständen den Lehrer löschen. Damit können Aktionen eines Lehrers in mehreren Use Cases auftauchen. Diesen beschriebenen Zusammenhang kann man sinnvoll in einer CRUD-Matrix darstellen.



[HRU14] stellte sich in seinem Buch die Frage: "Wozu benötigt man eine solche Matrix? Wenn Sie einen Use Case genauer untersuchen, sehen Sie, dass er Auswirkungen auf eine Entity hat. Sie können dann auch schon einmal prüfen, wo diese Entity sonst noch verwendet wird, d.h. welche Use Cases sollte ich wenigstens etwas genauer betrachten, um zumindest die Auswirkungen auf diese eine Entity zu verstehen, damit wir uns bei einer ersten Implementierung dieses Use Case nicht den Weg in die Zukunft verbauen. Wir können in dieser Matrix auch Zeilen und Spalten tauschen, um Dinge, die gemeinsam Sachen bearbeiten, näher zusammenzubringen und daher aus Projektgründen in einem Release zu entwickeln. Es ist also ein Hilfsmittel, um den Überblick zu behalten, um ein bisschen Projektmanagement zu machen, um Prioritäten zu diskutieren." [S.167, HRU14]

Innerhalb der CRUD-Matrix können wir also nachvollziehen, in welchen Use Cases ein Objekt erzeugt wird und ob es überhaupt Use Cases gibt, die es manipulieren. Haben wir z.B. den Fall, dass ein Objekt nur manipuliert wird, dann haben wir es nie erzeugt und werden es nie löschen. Hat das einen Sinn? Diese Frage müssen wir uns stellen. Aus der CRUD-Matrix wird der Lebenszyklus eines Objekts in Bezug auf die Use Cases ersichtlich.

In unserem System haben wir mit Hilfe von User Stories Szenarien entwickelt, die wir dann zu Use Cases zusammengesetzt haben. Es stehen also User Stories und Use Cases in Beziehung. Diese Beziehung können wir ebenfalls in das Diagramm mit aufnehmen. User Stories und Use Cases stehen in einer m:n-Beziehung. Warum machen wir das? Weil die User Story bei uns die Planungseinheit ist, die es in einem Sprint umzusetzen gilt. Nun können wir genau erkennen, ob es durch das Objekt Lehrer einen Nutzen für unseren Kunden gibt. Zwar sollen User Stories so geschnitten sein, dass sie keine Abhängigkeiten aufweisen. Das halte ich jedoch für sehr schwierig. Mit Hilfe der CRUD-Matrix verhindern wir Umsetzungen, in denen der Kunde auf Objekte zugreifen kann, die nie erzeugt wurden.



Mit Hilfe der CRUD-Matrix können Sie Fehler im Ablauf finden. Sie dient einer sinnvollen Abhängigkeitsanalyse und ist eine Hilfe für die Projektplanung. Die CRUD-Matrix beschreibt nicht nur die Verbindung von Use Case und Entity-Klasse, sie spezifiziert sie und macht damit den Zusammenhang wesentlich besser sichtbar. Für unsere weiteren Überlegungen heißt das, eine Beziehung zwischen zwei Objekten kann durch spezifische Attribute näher beschrieben sein.



An dieser Stelle scheint mir eine weitere Form der Visualisierung durch UML möglich. Im Use-Case-Diagramm sind Use Cases mit Akteuren in Beziehung gesetzt. Somit stehen die Use Cases der CRUD-Matrix natürlich auch mit Akteuren in Verbindung. Das Erzeugen von Objekten, das Lesen und Manipulieren von Objekten und das Löschen sind spezifische Interaktionen. Mit Hilfe des Sequenzdiagrammes kann diese Folge von Interaktionen in einer geordneten Form dargestellt werden.



Durch diese Diagramme werden Zusammenhänge aus unterschiedlichen Sichten betrachtet. User Stories hängen in diesem System mit Use Cases zusammen. Innerhalb von Use Cases sind Szenarien zusammengefasst, die Instanzen von Klassen manipulieren können. Diese Manipulationen werden durch Akteure ausgelöst, die in bestimmten Interaktionsfolgen diese Manipulationen vornehmen können.

  • [HRU14] Peter Hruschka: "Business Analysis und Requirements Engineering", Carl Hanser Verlag, München, 2014


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

1 Kommentar:

  1. Moment mal, ich kenne diese Matrix. Das ist was aus den 80er Jahren, ich habe das in einem Buch von Ed Yourdon gelesen, nur eben als Function/Data Matrix

    Leider finde ich nicht die aktuelle Seite, aber irgendwo in diesem Buch muss es sein:
    http://yourdon.com/strucanalysis/wiki/index.php/Table_of_Contents

    AntwortenLöschen