Systematische Softwareentwicklung


	> SSE > Entwurf > Design der Modelle

"Je planmäßiger die Menschen vorgehen, desto wirksamer trifft sie der Zufall."
(Friedrich Dürrenmatt)

Design der Modelle

"Design" bedeutet hier nicht das "Aussehen" der Software, sondern das "Entwerfen" der Software, d.h. die Ableitung der wesentlichen Modelle aus der Spezifikation. Daran sollte auf jeden Fall der Anlalytiker beteiligt sein, der in der Analysephase des Projekts die Spezifikation mit dem Ansprechpartner des Kunden gemeinsam aufgestellt hat, weil dieser sowohl die Fachlichkeit des Kunden kennengelernt hat als auch die entscheidenden Mitglieder des Projektteams (oder zumindest den Projektleiter) wahrscheinlich schon lange kennt. Außerdem wird der Analytiker auch genug Erfahrung und aktuelles IT-Know-How mitbringen, um die wesentlichen Befürchtungen und Probleme des Entwicklerteams zu kennen.

In dieser Design- oder Entwurfsphase werden vorrangig drei Hauptmodelle entwickelt: das Datenmodell, das Objektmodell der Geschäftslogik (engl. business logic, also middle tier) sowie das Präsentationsmodell. Wenn Sie die Architektur nach dem n-tier-Modell entwerfen, werden Sie bei größeren Anwendungen auch Objektmodelle im presentation tier und data tier bauen, wenn Sie auf die Serverfarmen mehrerer Unternehmen gleichzeitig zugreifen, werden Sie mit mehreren Datenmodellen arbeiten und wenn Sie verschiedene Typen von Clients (Browser, Windows, Handy) implementieren werden Sie mehrere Präsentationsmodelle benötigen. Bei den meisten Anwendungen kommen Sie aber sicherlich mit den drei Hauptmodellen aus.

Die Erstellung der Modelle ist jeweils eine Wissenschaft für sich - es gibt beispielsweise Entwickler, die sich ausschließlich auf den Entwurf von Datenmodellen spezialisiert haben. Andere wiederum haben über mehrere Projekte hinweg im Laufe von einigen Jahren viel Erfahrung mit ganz bestimmten objektorientierten Plattformen gesammelt und sind von daher absolut fit im Entwurf von Klassenhierarchien.

Es geht mir in dieser Abhandlung insgesamt um die systematische Arbeitsweise bei der Entwicklung von Software. Daher ist es mir sehr wichtig zu betonen, dass diese Modelle erstellt werden sollten, aber ich will hier nicht im Detail erläutern, wie das geht. Dafür gibt es bereits reichlich Literatur und Tools. Ich gebe daher nur einen kurzen Überblick.

...

...

...

...

Klassenmodell

...

Datenmodell

In den Anwendungsfällen werden Sie bereits Basisdaten erkannt haben, die eigentlich weitgehend konstant sind und an vielen Stellen in dem Software-System benutzt werden, z.B. Städtenamen, Verbandsmitglieder, LKW-Typen, Lagerhallenbezeichnungen. Sie werden auch schon für die Funktionsanwendungsfälle Datengruppierungen erkannt haben, die dort typisch sind und als Stammdaten für mehrere Detail- oder auch Funktionsanwendungsfälle gelten, z.B. Artikeldaten, Kundendaten, Projektdaten, Rechnungsdaten, Adressdaten, technische Datenblätter.

Dies sind Ihre ersten Entitäten (engl. entities), also Einzelinformationen und Informationseinheiten. Sie werden auch schon Beziehungen (engl. relations oder relationships) zwischen diesen Entitäten erkannt haben, z.B. Stücklisten bestehen aus Artikeln, Kunden erhalten mehrere Rechnungen, Datenblätter gehören zu Maschinen. Ein Datenmodell wird auch als ER-Model (Entity-Relationship-Model) bezeichnet. Sie nutzen für die Erstellung des Datenmodells ein Werkzeug, dass manchmal in die Entwicklungsumgebung integriert ist, manchmal aber besser auch separat erworben wird. Sie können damit die Strukturen (Spaltennamen und -typen) Ihrer Datentabellen festlegen, Standardwerte für Informationen vorgeben, Regeln für Informationen definieren (z.B. "zwischen 0 und 100" bei Prozentangaben) und auch die Beziehungen zwischen den Datentabellen mitsamt der Kardinalitäten definieren.

Die Erstellung des Datenmodells ist ein erster akribischer Test der Spezifikation durch Entwickler, die mit der Fachlichkeit noch nicht sehr vertraut sind. Daher sollte der Analytiker dabei sein und sehr genau darauf achten, wo seine Spezifikation wackelt und daher noch weiterer Analysebedarf besteht.

Das nebenstehende Bild zeigt einen ersten Entwuf eines Datenmodells, der eine Woche Zeit beansprucht hat. Sie sehen an einigen Lücken, dass dieses Modell noch nicht fertig ist, aber Sie sehen an den sauber getrennten Bereichen auch, dass die Analyse und Spezifikation erfolgreich verlaufen war und klar abgegrenzte Übersichtsanwendungsfälle ergeben hat.

Die Designphase wird - wie alle anderen Phasen und überhaupt das ganze Projekt auch - iterativ inkrementell durchlaufen, d.h. in einem ersten Design-Durchlauf wird zunächst mit einer konzeptionellen Sicht grob entworfen, in einem weiteren Durchlauf werden mit spezifizierender Sicht Details definiert und in einem anderen Durchlauf wird dann mit implementierender Sicht eine Umsetzung in das echte System erfolgen. Bei größeren Projekten können hier noch mehr Iterationen stattfinden, wobei das System immer weiter verfeinert wird und daher inkrementell wächst.

Während gerade das Bild eine konzeptionelle Sicht zeigte sehen Sie jetzt nebenstehend ein Bild der implementierenden Sicht. Denn es wird zunächst in der konzeptionellen Sicht nur ein logisches Datenmodell erstellt, welches nur allgemeine abstrakte Datentypen kennt (z.B. Nummer, Text). Erst bei der spezifizierenden Sicht werden die Datenbanksysteme festgelegt, so dass dann die physikalischen Modelle erstellt werden können. Diese enthalten dann wirklich schon die Datentypen, Regeln und Beziehungen des jeweiligen Datenbanksystems. Mit der implementierenden Sicht werden dann wirklich die echten Datenbanken aus den physikalischen Modellen realisiert, die dann auch mit Daten gefüllt werden können.

Das soeben gezeigte logische Modell wurde in dem Projekt sowohl in Microsoft Access (als Zwischenlösung für die Datenübernahme aus dem Altsystem) als auch in Oracle (für die endgültige Lösung) implementiert. Dazu wurden aus dem einen logischen Modell zwei physikalische Modelle abgeleitet (was von ordentlichen Modellierungstools unterstützt wird), aus denen dann die Datenbanken halbautomatisch erstellt werden konnten. Dazu generieren die Tools Skripte, die dann im Datenbanksystem gestartet werden können oder die Tools erstellen direkt die Datenbanken in den Datenbanksystemen.

In dem genannten Projekt wurde nebenstehende Access-Datenbank direkt aus dem Tool erstellt. Hier muss zwar noch aufgeräumt werden, aber die meiste Arbeit hat das Tool erledigt - und zwar gar nicht mal schlecht.

Das nebenstehende Bild zeigt einen Ausschnitt des gleichen Datenmodells ein halbes Jahr später. Es sind Tabellen hinzugekommen, Beziehungen haben sich geändert, Typen wurden genauer spezifiziert (NULL zugelassen oder nicht) und Bereiche getauscht, aber das logische Modelle wurde konsequent gepflegt und sieht daher jederzeit aus "wie neu".

Bei dem Design des Datenmodells ist darauf zu achten, dass es vollständig normalisiert wird, d.h. alle folgenden Normalformen durchlaufen werden:
1. Normalform: Die Feldinhalte müssen einfach - also atomar - sein. Dazu werden die Daten in Tabellen mit Zeilen und Spalten eingetragen.
2. Normalform: Jeder Zeile wird ein Schlüsselfeld hinzugefügt, über das jede Zeile eindeutig identifiziert werden kann. Jedes Feld muß funktional vom Schlüsselfeld abhängig sein. Der Schlüssel kann sich aus mehreren Feldern zusammensetzen.
3. Normalform: Es dürfen keine funktionalen Abhängigkeiten zwischen Nicht-Schlüssel-Feldern existieren. Die Tabelle darf somit keine transitiven Abhängigkeiten aufweisen. Dazu wird die Tabelle so lange in kleinere Tabellen mit Verweisen zerlegt, bis funktionale Abhängigkeiten nur noch zwischen den Tabellen bestehen und nicht mehr zwischen Nicht-Schlüssel-Feldern.
Boyce-Codd Normalform: Sie liegt zwischen der 3. und 4. Normalform und arbeitet mit der Existenz von Kandidatenschlüsseln. Eine Tabelle befindet sich in der Boyce-Codd Normalform, wenn sie sich für alle Felder, die alternative Kandidatenschlüssel sind, in der dritten Normalform befindet.
4. Normalform: Eine Tabelle darf keine paarweise auftretenden, mehrwertigen Abhängigkeiten aufweisen, d.h. die 4. Normalform erfordert, dass die Tabelle keine unabhängigen zusammengesetzten Primärschlüssel enthält.
5. Normalform (Project-Join-Normalform): Eine Tabelle enthält keine paarweisen zyklischen Abhängigkeiten des Primärschlüssels, die aus drei oder mehr Komponentenfeldern zusammengesetzt sind. Relationen in Fünfter Normalform lassen sich nicht weiter aufteilen.

Die Normalisierung der Daten entfernt die Redundanzen, so dass die Daten klar beschrieben werden, eindeutige Beziehungen zwischen Datenteilen bestehen, die Datenintegrität gewährleistet ist, ein schneller Zugriff auf die Daten möglich ist und nicht zuletzt Platz beim Speichern der Daten gespart wird.

Es handelt sich bei der Normalisierung um eine bewährte Technologie, die schon seit vielen Jahren erfolgreich von Programmierern eingesetzt wird. Wird beim Design des Datenmodells von vornherein mit ER-Diagrammen gearbeitet und jeder Datentabelle grundsätzlich ein internes Schlüsselfeld zugeordnet, so sind bereits wichtige Schritte auf dem Weg zur normalisierten Datenbank erledigt.

Ich pflege meine logischen Datenmodelle - wenn irgendwie möglich - so, dass sich keine Linien kreuzen und alle Beziehungen sich 1:n von links nach rechts über das Diagramm ziehen. Dies erfordert viel Disziplin und ich kenne bereits mehrere Leute, die das ziemlich albern finden, aber es hat einen entscheidenen Vorteil: ich kann einen wichtigen Test durchführen. Wenn ich eine Konstruktion erkenne, die ich "small diamond" ("kleiner Diamant") nenne, stimmt in der Regel etwas mit den Beziehungen nicht. Oft gibt es dann eine redundante Beziehung, was von den Normalisierungsstufen nicht abgedeckt wird. Falls eine solche Beziehungskiste aber erforderlich ist, muss sie auf jeden Fall im business tier oder presentation tier plausibilisiert und damit abgedichtet werden. Als "small diamond" bezeichne ich eine rautenförmige Beziehungskonstruktion zwischen vier bis etwa acht Tabellen.

Das nebenstehende Bild zeigt einen solchen "small diamond": Ursprünglich gehörte ein Projekt (tblProject) zu einem Planabschnitt (tblSegmentAssetsPlan) und stand n:m mit Arbeitstypen (tblWorkType) in Beziehung, d.h. ein Projekt bestand aus mehreren Arbeitstypen und ein Arbeitstyp kam bei mehreren Projekten vor. Später stellte sich der fachliche Zusammenhang heraus, dass ein Planabschnitt durch mehrere Arbeitstypen beschrieben wird. Wie kann nun sicher gestellt werden, dass die zugeordneten Arbeitstypen des Projekts alle zum gleichen Planabschnitt gehörten, und zwar zu dem vom Projekt verwendeten Planabschnitt? Tatsächlich wurde die zuerst gefundene Beziehung von den Planabschnitten zu den Projekten überflüssig und barg sogar ein Fehlerrisiko.

...

Bei der späteren Implementierung wird zu beachten sein, dass je nach Bedarf verschiedene Methoden für den Datenzugriff existieren: bei tabellarischen Darstellungen wird eher per Abfrage (View) zugegriffen, bei einzelnen "punktuellen" Informationen wird eher eine Gespeicherte Prozedur (Stored Procedure) aufgerufen und bei komplexen Ermittlungen mit Fallunterscheidungen über mehrere Tabellen hinweg wird evtl. stufig mehrfach vom mittleren tier aus zugegriffen.

...

Modellierung
- Klassenhierarchie; Integrationsmodell (OOA-Modell)
- BO-Modell
- Datensammlung; Datenmodell (ER-Modell)
- GUI; Simulationsmodell (fachlicher Prototyp)

Identifikation von Klassen, Assoziationen, Aggregationen, Generalisierung, Subsysteme
Zustandsautomaten

Architekturentwurf
- Anbindung an Benutzeroberfläche
- Anbindung an Datenhaltung
- Verteilung auf vernetzte Computer
Implementierungsentwurf
- Verfeinerung des Architekturentwurfs
- Anpassung an Programmiersprache

Risikomanagement: In dieser Phase Risiken herausarbeiten, die das Design des Softwaresystems birgt bzw. die anhand des Designs erkennbar werden.