Unterschiede zwischen einem konzeptionellen UML-Klassendiagramm und einem ERD?

Question

Wenn ich ein konzeptuelles Klassendiagramm erstelle, in dem jede Klasse "Name" und "Attribute" erfasst, aber nicht "Operationen", habe ich dann nicht grundsätzlich etwas erstellt, was sonst als ERD betrachtet würde? Ich versuche zu verstehen, was die Unterschiede zwischen dem Erstellen eines konzeptionellen Klassendiagramms, wie ich es beschrieben habe, und dem Aufrufen eines ERDs? Wenn das immer noch zwei verschiedene Tiere sind, kann mir bitte jemand erklären, was die Unterschiede sind?

Answer 1

wurde leider wenig Unterschied in der Ausdruckskraft von beiden (wenn wir uns auf die Attribute, Klassen und Assoziationen Teil konzentrieren nur), wenn Sie Entity-Relationship-Diagramme Erweiterte verwenden (die häufigste Fall heute)

Es stimmt, sie aussehen auf der grafischen Ebene sehr unterschiedlich, da sie unterschiedliche Symbole für die Elemente verwenden, aber die "Semantik" ist ziemlich ähnlich. Beide erlauben Vererbung (wieder, ich spreche über EER), n-ary Assoziationen, Assoziationsklassen, ...

Answer 2

Das Klassendiagramm enthält nur die Klassen in Ihrem Objektmodell mit eventuellen Verknüpfungen/Beziehungen, die Diagrammelemente verbinden. Diese Verbindungen entsprechen jedoch nicht unbedingt den physikalischen Beziehungen wie in einem ERD-Diagramm, sondern repräsentieren logische Verbindungen.

Das Klassendiagramm ist nur das Objektmodell Ihrer Anwendung und enthält keine persistenzspezifischen Informationen. Wenn Sie über das Klassendiagramm nachdenken, vergessen Sie die Datenbank oder andere Speicher, die Sie verwenden können.

Das ERD-Diagramm auf der anderen Seite ist ein Persistenz-spezifisches Diagramm, das die Entitäten (Tabellen) anzeigt, die in einer (meist) relationalen Datenbank existieren. Außerdem werden die physischen Beziehungen (und Kardinalitäten) zwischen diesen Tabellen und allen anderen datenbankspezifischen Informationen angezeigt. Das ERD-Diagramm kann manchmal ähnlich dem Klassendiagramm aussehen, aber das bedeutet nicht, dass es dasselbe wie ein Klassendiagramm ist.

Answer 3

Es hängt von der Situation ab, wo Sie nicht möchten, die ER-D zu tun. Aber stellen Sie sich vor, wenn Sie eine separate Datenschicht haben, in der die Datenlogik behandelt wird. In diesem Fall dürfen viele Details der Daten nicht mit der Anwendungsschicht geteilt werden. Und Ihr Klassendiagramm sollte nicht über die Anwendungsschicht hinausgehen. Ich muss betonen, dass beide Diagramme nicht gleich sind. Und es gibt Situationen, in denen Sie beides tun müssen, hauptsächlich in der Multi-Tier-Architektur, und es gibt Situationen, in denen Sie vielleicht nur das Klassendiagramm verwenden können; z.B. einstufige Anwendung.

Ich befürworte stark die Ansicht, dass Klassendiagramm das E-R-Diagramm nicht aufhebt.

Answer 4

Designklassendiagramme werden aus konzeptuellen Modell- und Kollaborationsdiagrammen erstellt. Design-Klassendiagramme sind:

1. Klassen, Assoziationen und Attribute
2. Methoden
3. Typen von Attributen
4. Schiffbarkeit
5. Abhängigkeiten

Answer 5

Die ER-Diagramme ich gesehen habe (die meisten häufig ERWin IE Notation) haben sich auf das Design für eine Datenbank konzentriert. Sie beschäftigen sich mit Primärschlüsseln, Fremdschlüsseln, haben unbenannte Beziehungen und haben in der Regel keine Generalisierung/Spezialisierung.

Ein gutes UML konzeptuellen Klassendiagramm, auf der anderen Seite, ist nicht betroffen mit Schlüsseln, spiegelt die Problemdomäne und hat Assoziationsend-Eigenschaften, die mindestens Hinweis bei der Semantik, warum Dinge verwandt sind. Dies hilft dabei, die Domäne an jüngere Entwickler zu kommunizieren, sodass sie nicht raten müssen.