Quale dovrebbe essere creato prima come diagramma ER o diagramma di classe?

Question

Il primo passo in cui ho creato un DFD. Poi sono passato a creare un Class Diagram. E mentre lo facevo sentivo che dovevo prima creare il diagramma ER. Dato che c'erano molti dettagli che non potevano essere catturati in un diagramma di classe. Quindi, la mia domanda dovrebbe creare i primi diagrammi di classe O ERD?

i vostri preziosi input sono apprezzati ragazzi !!! grazie per la lettura

Answer 1

Quando la modellazione, tendo a pensare in termini di fare diagrammi in qualsiasi ordine ha più senso per me al momento. A volte questo è il diagramma delle classi prima, a volte quello è il diagramma delle relazioni tra entità, a volte questo è persino il diagramma delle sequenze. La cosa principale da ricordare è che stai cercando di capire le cose e scriverle in modo che anche le altre persone possano capirle; preoccuparsi di quale sia il modo migliore per ordinare i tuoi pensieri non è così utile quanto limitarti a scrivere le parti che hai do capire.

[EDIT]: FWIW, ho anche la tendenza a iniziare la modellazione su carta o lavagna e passare a utilizzare un computer solo quando mi sto avvicinando a quello che ho capito. (Immagino che non mi piaccia disegnare sui computer.) La chiave è che la modellazione riguarda la comprensione e non (molto) dei computer.

Answer 2

I diagrammi ER fanno l'effetto di avvio perché contengono meno informazioni rispetto al diagramma degli oggetti, che include molte più informazioni sui metodi sugli oggetti e sugli alberi di ereditarietà: entrambi gli elementi mancheranno il diagramma ER.

Come tale, è meglio iniziare con la gerarchia degli oggetti (class diagram) e poi mov al lato mappatura delle cose;)

Answer 3

I puristi OO tendono a eseguire prima il diagramma Class. Le persone con uno sfondo di database prima fanno il diagramma ER e "derivano" il diagramma di classe da questo (questo approccio è disapprovato dai puristi di OO)

Preferisco un approccio ibrido.

Identificare prima le entità. Questo dovrebbe essere lo stesso sia dal punto di vista del database che dell'applicazione (classi).

Dopo aver concordato le entità ad alto livello, procedere con diagramma di classe e diagramma ER in direzioni parallele, poiché le "relazioni" sono diverse in ciascuna. (Se sei l'unica persona che lavora su di loro, inizia con il diagramma di classe prima e poi con l'ERD, ma identifica prima il destinatario).

A mio parere le entità di alto livello dovrebbero essere uguali, sia sul database che sull'applicazione (Java/C# ...). Ed è molto facile procedere con la base comune, specialmente se ci sono diverse persone che lavorano su parti diverse (classi, database).

Answer 4

Direi che dipende molto dalla tua applicazione. & Conosco un po 'di UML e so che è possibile modellare la molteplicità delle relazioni così come le chiavi primarie usando solo diagrammi di classe standard UML, così spesso il diagramma delle classi è sufficiente. Mi piace iniziare con il diagramma delle classi, perché mi piace usare l'analisi e la progettazione orientata agli oggetti, i casi d'uso, le realizzazioni del caso e le classi analitiche. Dall'altro lato, una buona progettazione del database richiede la normalizzazione e talvolta la denormalizzazione, diverse ottimizzazioni per l'interrogazione dei dati ... Ma per quello, prima dovrei sapere per cosa cercherò e forse come. Personalmente vedo la parte relazionale della maggior parte delle applicazioni come un meccanismo di memorizzazione, penso al sistema in termini di programmazione orientata agli oggetti. Ciò è particolarmente utile, ad esempio con Ruby on Rails, che grazie al pattern Active Record estrae totalmente dal modello relazionale, quindi non devo fare il modello due volte.