Wie in Teil 3 unserer Blogserie geschildert, gibt es einige Gemeinsamkeiten, aber auch einige Unterschiede zwischen Entity-Relationship-Diagrammen und UML-Klassendiagrammen. Wie sich die Modellarten in Terminologie und Notation unterscheiden, möchten wir in diesem 4. und letzten Teil der Serie betrachten.
Unterschiede in der Terminologie
Hier ein Überblick über die unterschiedliche Terminologie anhand der vier grundlegenden Elemente von Peter Chens Entity-Relaltionship-Diagramm:
Das Pendant zum Objekt im Klassendiagramm, das einen konkreten Gegenstand beschreibt, ist im ER-Diagramm die Entität.
Die Kardinalitäten können außerdem unterschiedlich graphisch dargestellt werden. Je nachdem, welche weiterentwickelte Variante des ER-Diagramms verwendet wird, z.B. die Notation nach Bachmann, die Krähenfuß-Notation oder eben die Chen-Notation.
Unterschiede in der Darstellung
Hier die grundlegenden Elemente eines ER-Diagramms graphisch dargestellt:
Der Name des Beziehungstyps ist immer in der Raute vermerkt. Dabei könnte man auch die beiden Schlüsselwörter „is-a“ für eine Vererbungsbeziehung oder „is-part-of“ für eine Ganze-Teile-Beziehung verwenden. Analog dazu sind die Notationselemente Generalisierung für Vererbungen und Aggregation/Komposition für Ganze-Teile-Beziehungen im UML-Klassendiagramm zu sehen.
Im Vergleich zu Abbildung 1 hier die Notation der grundlegenden Elemente des UML-Klassendiagramms:
Fazit
Das Entity-Relationship hat durchaus seine Daseinsberechtigung, ist aber nicht so mächtig, wie das Klassendiagramm. Um ein Datenmodell im Sinne eines Anforderungsmodells zu erstellen, ist es gut einsetzbar. Werden im Projekt ER-Diagramme und Klassenmodelle verwendet, stellt sich die Frage, ob bestehende ER-Diagramme überführt werden sollten oder nicht, um die Anzahl an Modellarten so gering wie möglich zu halten. Besonders im Hinblick darauf, dass alle Beteiligten und Stakeholder die verwendeten Notationen lesen und verstehen können müssen.
Und noch ein Tipp an dieser Stelle: worauf es beim Einsatz vom Modellen für die Anforderungsdokumentation ankommt und welche Vor- und Nachteile es gibt, sind sehr anschaulich im Lehrplan zum Certified Professional for Requirements Engineering im Foundation Level beschrieben. Es lohnt sich nachzuschlagen.
Damit möchten wir die Blogserie zu Entity-Relationship-Diagrammen abschließen und hoffen, ein wenig Neues und Interessantes für Sie gefunden zu haben. Wenn Sie den Anfang verpasst haben sollten, so finden Sie hier den Teil 1 der Serie.
Quellenangaben:
Das ganze Thema UML Klassen ist sehr neu für mich. Wenn ich das aber richtig verstanden habe ist es so, das mir ein Tool welches im UML arbeitet auch immer einen fertigen Quelltext in einer C Sprache oder Java ausgibt als Gerüst, welches ich nur noch modelieren muss oder ?
Hallo Herr Vetter,
Ja, UML-Tools bieten Generatoren, die aus einem Klassendiagramm das Gerüst implementieren. Das Verhalten in den einzelnen Operationen muss dann manuell programmiert werden.
Im Bereich des Requirements Engineering setzen wir allerdings Klassendiagramme mit einem anderen Ziel ein:
Wir wollen NICHT Code generieren, sondern die Diagramme nutzen, um die fachlichen Begriffe und Daten in einer eindeutigen Weise zu definieren und zueinander in Zusammenhang zu setzen. Das so entstehende Begriffsmodell oder Informationsmodell dient dann als Grundlage für die Anforderungen, kann aber auch schon Anforderungen beinhalten.
Das Begriffsmodell kann später in der Entwicklung in einem Designschritt als Grundlage für die Implementierung dienen, muss dafür jedoch im Allgemeinen noch erweitert / verändert werden.
Viele Grüße,
Ihre SOPHISTen