Modellierung eines Systems nach der Definition des UML-Anwendungsfalls

Question

... was kommt als nächstes?

Nachdem Sie definiert haben, welche Akteure welche Aktionen tun, welchen Weg gehen Sie? Modellieren Sie die Datenbank oder möchten Sie lieber mit den Klassen beginnen?

Ich dachte, der bessere Ansatz wäre, mit einem klassenähnlichen Modellierungsdiagramm zu beginnen, um sich auf die Beziehungen zwischen Objekten zu konzentrieren. Das hat sich als falsch erwiesen, weil ich zu sehr in die Detailklassen gegangen bin und selbst wenn das System "zu funktionieren schien", als ich zur Datenbankmodellierung ging, würde alles natürlich nicht zu den Positionen passen, die ich in der vorherigen Phase gewählt hatte .

Ich lese über Leute sagen, dass man Anwendungslogik in eine Datenbank setzen und seine Geschwindigkeit beim Abrufen von Daten nutzen sollte, im Gegensatz zum Erstellen großer Objekte im Speicher, die abgefragt werden und eine Abstraktion der zugrunde liegenden Datenbank bereitstellen. Ich dachte immer, dass die db dort ist, um meine Daten zu speichern und eine schnelle Möglichkeit zu bieten, darauf zuzugreifen. Aber vielleicht irre ich mich, ich meine, muss ich wirklich eine Datenbank bauen, die in der gleichen Logik ist, die ich auf eine Gruppe von Klassen setzen würde? Verfügt die Datenbank nicht über die Werkzeuge, um dies zu erreichen?

Ich denke, ich bin nicht in der Identifizierung der richtigen Stelle, wo ich anfangen soll, wenn ich mit der Datenbank beginnen, finde ich es schwer, nicht nur als "Ort, um meine Daten zu speichern, machen wir App-Logik auf einer höheren Ebene "Sache, wenn ich mit Klassen beginnen die Datenbank endet wie eine unnatürliche Darstellung von Klassen, fühle ich das Gefühl, etwas wichtiges zu verpassen, etwas wie nicht die richtige Zweckbestimmung das richtige Werkzeug.

Wie gehen Sie damit um? Wenn es um die Entscheidung geht, ob Sie mit der Modellierung der db oder der Klassen beginnen sollen, hat sich nach Ihrer Erfahrung gezeigt, welcher Ansatz zu einer natürlichen und sauberen Implementierung geführt hat? ersten

Vielen Dank im Voraus

Answer 1

Ich hatte Erfolg mit Robustness Analysis.

Dieser Artikel konzentriert sich auf die Robustheit Analyse, die die Erzähltext von Anwendungsfällen und Identifizierung ein erster erraten Satz von Objekte beinhaltet die Analyse, die in jedem Anwendungsfall teilnehmen, dann Klassifizierung dieser Objekte in drei Typen:

1. Grenzobjekte, die von Akteuren bei der Kommunikation mit dem System verwendet werden.
2. Entity-Objekte, die in der Regel Objekte aus dem Domänenmodell sind (das Thema von "Driving Design: Die Problem Domain," Jan. 2001).
3. Steuerobjekte (die wir Controller in der Regel nennen, weil sie oft nicht reale Objekte sind), die als „Klebstoff“ zwischen Objekte und Entity Grenze objects.Figure 1 dienen zeigt die visuelle Symbole für diese drei Typen von Objekten.

Die Entitätsobjekten sind diejenigen, die (usuallly) in der Datenbank am Ende/

Auf Zuordnung zwischen den Klassen und der Datenbank, würde ich S.Lott's article on "The ORM Problem" empfehlen (er ist auch ein Teilnehmer auf Stackoverflow

Answer 2

Wenn Test Driven Development verwenden, die Komponententests schreiben. Ihre Klassen werden im weiteren Verlauf beschrieben.

Sie können Ihre Geschäftslogik ohne eine Datenbank (Mock- oder Stub-Objekte) entwickeln oder Ihre Datenbank entwickeln, während Sie mit Ihren Tests fortfahren.

Denken Sie daran, dass Ihre Datenbank und Ihr Domänenmodell nicht aufeinander abgestimmt sein sollten.