Modellazione di un sistema dopo aver definito il caso d'uso UML

Question

... quali sono le prospettive?

Dopo aver definito quali attori fanno quali azioni, in che direzione vai? Modella il database o preferisci iniziare con le classi?

Ho pensato che l'approccio migliore fosse iniziare con un diagramma di modellazione simile a una classe, per concentrarmi sulle relazioni tra oggetti. Ciò si è rivelato sbagliato perché sono andato troppo in profondità nel dettaglio delle classi e, anche se il sistema "sembrava funzionare", quando sono andato alla modellazione del database, tutto non si adattava naturalmente alle posizioni che ho scelto nella fase precedente .

Ho letto di persone che affermano che si dovrebbe inserire la logica dell'applicazione in un database e sfruttare la sua velocità nel recupero dei dati, al contrario di costruire oggetti di grandi dimensioni in memoria che vengono interrogati e forniscono l'astrazione del database sottostante. Ho sempre pensato che il db fosse lì per archiviare i miei dati e fornire un modo rapido per accedervi. Ma forse mi sbaglio, voglio dire, devo davvero costruire un database che abbia la stessa logica che metterei su un gruppo di classi? Il database non ha gli strumenti per raggiungere questo obiettivo?

Penso di non riuscire a identificare il punto giusto da cui iniziare, se scelgo di iniziare con il database trovo difficile non solo pensarlo come un posto dove archiviare i miei dati, facciamo la logica delle app a un livello superiore " cosa, se comincio con le classi il database finisce per sembrare una rappresentazione innaturale delle classi, sento la sensazione di perdere qualcosa di importante, qualcosa come non assegnare lo scopo giusto allo strumento giusto.

Come gestisci questo? Quando si tratta di decidere se iniziare con la modellazione del db o delle classi, nella tua esperienza, che tipo di approccio ha dimostrato di portare a un'implementazione naturale e pulita?

Grazie in anticipo

Answer 1

Ho avuto successo utilizzando Analisi di robustezza .

  

Questo articolo è incentrato sulla solidità   analisi, che comporta l'analisi del   testo narrativo di casi d'uso e   identificare un set di prima ipotesi di   oggetti che parteciperanno a ciascuno   caso d'uso, quindi classificandoli   oggetti in tre tipi:

     

  
1. Oggetti limite, che gli attori usano per comunicare con il sistema.
  
2. Oggetti entità, che di solito sono oggetti dal modello di dominio   (oggetto di " Driving Design: The   Dominio problematico, " Gennaio 2001).
  
3. Oggetti di controllo (che di solito chiamiamo controller perché essi   spesso non sono oggetti reali), che   fungere da "colla" tra confine   oggetti e oggetti entità. Figura 1   mostra le icone visive per questi tre   tipi di oggetti.
  

Gli oggetti entità sono quelli che (di solito) finiscono nel database /

Sulla mappatura tra le classi e il database, consiglierei L'articolo di S.Lott su " The ORM Problem " (è anche un partecipante su StackOverflow

Answer 2

Se si utilizza Test Driven Development, scrivere prima i test unitari. Le tue lezioni verranno delineate man mano che procedi.

Puoi scegliere di sviluppare la tua logica aziendale senza un database (oggetti finti o stub) o sviluppare il tuo database mentre prosegui con i test.

Ricorda che il tuo database e il modello di dominio non devono essere mappati l'uno sull'altro.