Il diagramma delle classi è modellato sui requisiti di sistema ed è importante creare soluzioni basate su tali requisiti. Se ho detto diagramma di classe dovrei aderire rigorosamente ad esso? Che dire del refactoring? Cosa succede se il diagramma non fornisce un principio di progettazione che ritengo sia stato escluso?
Risposta breve: No.
Il tuo output dovrebbe funzionare (sperabilmente testato) codice che esegue la funzione aziendale che dovrebbe svolgere. Il modo in cui svolgi questo compito non dovrebbe essere richiesto (di nuovo, a meno che tu non lavori per la NASA).
Un'analogia zoppa: salgo su un taxi e dico loro dove andare. Lascio perdere a loro per guidarmi lì. Mi fido di loro per farmi arrivare lì in modo sicuro e in modo tempestivo. Non ho intenzione di sedermi lì e microgestire il tassista e dirgli quando accendere il suo segnale di svolta, quanto premere l'acceleratore, o quando ottenere il gas. Questo è il suo lavoro.
Hai schemi di classe nei tuoi requisiti? Dovrebbe far parte di una specifica, non delle tue esigenze, ma immagino che i negozi di tutti siano diversi;) È importante aderire alle tue specifiche. In caso contrario, si potrebbe avere un impatto su un'altra area dell'applicazione senza nemmeno saperlo quando si devia. Se la specifica è errata, la riapri, comunichi la modifica e la rivedi e poi cambi il codice. Anche quando non sei d'accordo. Potresti non sapere tutti i motivi per cui è stata scelta un'implementazione rispetto a un'altra.
Prima di prendere una decisione, vengono presentati i seguenti punti da prendere in considerazione, l'idea è di esaminare i fattori che influenzerebbero in generale un caso come il tuo.
Punto 0: è necessario implementare tutte le regole aziendali qualunque sia lo stile di implementazione.
Punto 1: in UML, i diagrammi di classe sono solo una parte dell'intero modello. Esistono altri diagrammi che utilizzano classi definite come Use Case, Sequence, ecc.
Punto 2: nelle applicazioni OO che utilizzano RDBMS è necessario decidere se la propria applicazione è stata creata utilizzando un Primo approccio all'oggetto o un Primo approccio ai dati. Sulla base di questo il modello di dominio è costruito. I due tipi di modello possono essere molto diversi. Vedi: Oggetto Imp. Relazionale. missmatch.
Punto 3: in OO e parzialmente come risultato del punto 3, gli oggetti che rappresentano il livello del database possono essere diversi dagli oggetti utilizzati in altri livelli o servizi dell'applicazione. Se si utilizzano i servizi Web, è probabile che l'API definisca gli oggetti in modo diverso rispetto alla definizione del livello aziendale e alla definizione del livello dati.
Punto 4: i modelli UML hanno fasi, generalmente definite da una metodologia come in Mapping Models to Dev. Processo , ogni fase può produrre un modello diverso. Cambiare un modello di fase di implementazione è ovviamente il meno auspicabile e il più critico a causa del suo impatto.
Punto 5: dovresti considerare l'impatto del cambiamento sulla fase del ciclo di vita del progetto, i suoi dati esistenti, se presenti e su altri colleghi lavoratori e DBA.