Come progettare correttamente le classi per un grande progetto?

4

Se dobbiamo rappresentare le classi in un diagramma di classe per un grande progetto che non è ancora completamente progettato e le classi devono essere tabelle effettive in un database, come dovremmo prevedere e progettare le classi?

Diciamo che abbiamo un progetto che avrà più di 15 tabelle, tutte queste tabelle devono essere classi nel diagramma delle classi?

Come sarebbero progettate le classi in questo tipo di situazione? Il linguaggio che viene utilizzato è Java e il diagramma delle classi deve essere preparato in UML. So come progettarli, ma non so se le tabelle dovrebbero rappresentare le classi in questo caso.

    
posta Eve 02.08.2012 - 04:33
fonte

6 risposte

8

La progettazione delle classi da mappare direttamente ai tavoli può essere vista come un anti-pattern. C'è un oggetto naturale - Disadattamento di impedenza relazionale che si ottiene quando si utilizzano OO e DB relazionali.

Progettare la tua applicazione in base al suo dominio indipendentemente dalla sua archiviazione dei dati è spesso una pratica consigliata. Domain Driven Design è una tecnica che potresti trovare utile.

    
risposta data 02.08.2012 - 10:05
fonte
3

Non sembra un grande progetto se hai poco più di 15 tavoli. Tuttavia, il punto principale è quale approccio e progettazione di sviluppo hai intenzione di avere?

La modellazione dei dati deve essere eseguita prima dei progetti di classe. Mentre esegui la modellazione dei dati, puoi anche continuare a lavorare sulla Tecnica di modellazione dell'architettura . Esistono diverse alternative da considerare e tutto ciò dipenderà dalle specifiche del progetto. Strumenti come il diagramma ER possono aiutarti a progettare diagrammi di alto livello e classe bassa.

A seconda del tipo di applicazione, è possibile ottenere alcuni suggerimenti sulla strutturazione delle classi da esempi di progetti open source. Permettetemi di menzionare un punto importante, poiché il vostro progetto avanza potrebbe essere necessario modificare leggermente la struttura o aggiungere livelli aggiuntivi a seconda dei requisiti e della progettazione.

Ci sono alcuni buoni riferimenti da guardare:

risposta data 02.08.2012 - 05:06
fonte
1

In generale, direi di no. Dovresti considerare di avere una classe DTO che rispecchi la struttura della tabella, ma il suo unico uso è il trasferimento dei dati. Dovrebbero esserci altre classi nel livello di persistenza che supportano le particolari funzioni richieste dall'applicazione (ad esempio, potresti avere una classe Customer che contiene più istanze di Address , quindi avrebbe senso che ottenere un cliente richieda anche che tu Ottieni tutti gli indirizzi associati. Tutti gli accessi ai dati devono essere eseguiti dalle tue classi DAO o manager, quindi tutta la tua applicazione deve preoccuparsi di creare o utilizzare un cliente). Se la tua logica aziendale deve preoccuparsi della tabella in cui sono archiviati alcuni dati, stai sbagliando.

    
risposta data 02.08.2012 - 20:12
fonte
1

Dovresti iniziare con la modellazione dei casi d'uso e la modellazione dei processi, ma mai con i diagrammi delle classi.

I processi ti diranno in che modo le entità si relazionano l'una con l'altra.

In realtà, non hai bisogno di tutte le tue classi persistenti in un diagramma di solito - non c'è una storia dietro a questo! È una bella foto di famiglia, forse sarebbe bello aiutare a tracciare gli elementi del sistema in un secondo momento, ma di solito ti viene detto, come regola generale, che un diagramma UML non dovrebbe mai contenere più di 15 elementi, in quanto rende facile sbagliare la progettazione .

Immagina il tuo sistema come un cubo di Rubik. Per capire come risolvere il cubo di Rubik, di solito guardi uno, due o tre lati. Non appiattisci il cubo!

Ogni singolo diagramma dovrebbe raccontare una storia sul tuo sistema: forse dice la tassonomia di una famiglia di classi, forse dice come il sistema viene usato dai diversi attori, forse dice come viene giocato un determinato scenario, forse indica come un determinato insieme di oggetti interagisce tra loro per risolvere un problema o come un componente è strutturato internamente.

Ecco perché di solito dovresti avere molti piccoli diagrammi: forse potresti chiedere a uno strumento speciale di riunirli, ma dal momento che sei un essere umano, e la maggior parte dei tuoi compagni di lavoro sono anche umani, non sarai mai in grado per cogliere l'intero sistema in una sola volta.

Una delle maggiori sfide nell'ingegneria del software (al contrario di altre metodologie, come Agile) è accettare che il tuo cranio sia limitato. Che tu possa afferrare circa 10 + -5 cose, e questo è quanto. O devi ingrandire o ridurre, nascondere i dettagli, devi girare il cubo o fare qualcosa in generale.

Devo ancora trovare un'applicazione che sia stata progettata come un unico, enorme diagramma di classe e che non contenga errori di progettazione gravi, visibile solo guardando il diagramma per 10 minuti o, più spesso, guardando il changelogs, dove si dovevano apportare modifiche serie.

Di solito dico alle persone di disegnare i flussi di dati per ciascuno dei casi d'uso: quali dati arrivano, quali dati vengono fuori, quali dati sono necessari per ottenere i risultati. Quindi chiedi che tipo di punti dolenti possono esserci per ogni passo.

Riprese di un grande ritratto di famiglia di classi persistenti - questo è piuttosto limitato. Ovviamente, dovresti raccogliere le classi necessarie per essere mantenute su questi diagrammi di flusso, ma forse è meglio se uno strumento lo fa per te.

Il design non riguarda come risolvere una particolare implementazione. Affrontalo più tardi. Per prima cosa, scopri, che tipo di lezioni hai bisogno. Una classe UML è un costrutto astratto: potrebbe anche non tradurre mai per le classi Java mai. Una classe UML è solo un modo di dire: "beh, avremo cose che hanno queste caratteristiche significative dal nostro attuale punto di vista". Una classe Java è un modo per dire alla macchina come allocare memoria e per quale scopo.

Una volta che UML ti dice ciò che ti serve, solo allora puoi iniziare a pensare a come realizzarlo.

E sì, usa Domain-Driven Design (il libro blu con lo stesso titolo è abbastanza carino).

(E so che sarò incolpato dai ragazzi Agile che non sono abbastanza agile, ma non ci occupiamo di questo, stiamo parlando di UML: la maggior parte dei ragazzi che fanno Agile non ha mai veramente capito UML, e loro non vogliono preoccuparsi di questa domanda che spero.)

    
risposta data 06.08.2012 - 01:54
fonte
0

Per una domanda così generica, posso solo darti una risposta generica: dipende.

Esistono applicazioni basate sui dati (molto noiose da creare) che offrono esattamente ciò che il cliente desidera. In tal caso, il tuo dominio (se ne hai davvero bisogno) è un duplicato esatto dello schema del tuo database.

Esistono anche applicazioni in cui il database non è altro che un modo per mantenere lo stato in caso di arresto anomalo dell'applicazione. In tal caso, la progettazione del database non è così importante (presupponendo che non ci siano molti utenti concorrenti) e il modello di database probabilmente sarà un duplicato del tuo modello di dominio.

Esistono anche applicazioni in cui il database viene modellato utilizzando le giuste tecniche di modellazione e il dominio dell'applicazione viene modellato utilizzando le giuste tecniche OOAD. La differenza tra loro potrebbe essere risolta usando un ORM o un mappatore manuale.

    
risposta data 02.08.2012 - 16:26
fonte
0

Le tabelle non guidano necessariamente la progettazione della classe.

Ad esempio, non tutti i programmi si connettono a un DB. Se le tabelle guidano la progettazione della classe, tale programma non dovrebbe avere classi.

    
risposta data 15.08.2012 - 14:37
fonte

Leggi altre domande sui tag