Il modo in cui lo vedo se ne crei uno prima di ottenere il vantaggio di:
ma perdi:
D'altra parte, potrei semplicemente crearli tutti dopo aver scritto il mio codice solo per tenerlo come riferimento per i futuri sviluppatori.
Quale è lo scopo dei diagrammi delle classi e quale è più vantaggioso?
Se li crei prima, faranno parte della fase di progettazione.
Se li crei dopo, puoi semplicemente usarli per la documentazione. Ma documentare è meglio e più veloce se lo fai durante la progettazione e la codifica.
A proposito, non perdi tempo nel progettare! La parte di codifica sarà più veloce. E meglio.
Dopo tutto, pensi che progettare un grattacielo o un ponte sia una perdita di tempo invece di iniziare a costruirlo?
Un compromesso è iniziare a creare codice fittizio durante la fase di progettazione (solo prototipi di classi / funzioni) e utilizzare questo codice scheletro per creare i diagrammi delle classi.
Quando li ho creati prima della codifica, li vediamo come documenti "temporanei". Cioè, creiamo i diagrammi e mettiamo i nostri pensieri sulla carta. Iniziamo la codifica da questi diagrammi di classe. Poi li buttiamo fuori. Non vale la pena passare il tempo per mantenerli una volta iniziata la codifica. E se vuoi modelli di classe aggiornati, usa uno strumento per crearli dal codice.
In entrambi i casi rimarranno uniti come parte della documentazione. Nessuno li aggiornerà quando vengono apportate modifiche all'implementazione. I diagrammi non avranno date su di essi in modo da non sapere nemmeno quale versione del codice fanno riferimento. Quando una nuova persona viene aggiunta al progetto, gli viene dato un diagramma che dice "Ecco alcuni diagrammi che sono stati creati in un determinato momento durante la progettazione o l'implementazione." Non sappiamo quanto siano aggiornati. "
Questo fa parte del design e quindi dovrebbe essere creato prima dell'implementazione. Questo non vuol dire che non possano essere raffinati durante / dopo l'implementazione per riflettere lo stato corrente delle implementazioni.
Fornire un progetto dopo l'implementazione è ciò che chiamerei "codifica dei cowboy" e sicuramente puoi prosperare nel selvaggio west selvaggio, ma ricorda che i cowboy di solito finiscono per morire in un punto o nell'altro.
Dipende dalla profondità del design. Alcune persone insistono a scrivere diagrammi di classe anche per le classi più banali, perché "è una buona pratica". Penso che sia uno spreco di tempo disegnare qualcosa quando sai già esattamente come verrà implementato. Quando crea un nuovo design, qualcosa che non ti è familiare, è sicuramente utile disegnare prima alcuni diagrammi.
Non uso mai gli strumenti UML, perché il design di solito cambia così tanto durante l'implementazione che devo ridisegnare il diagramma. Suppongo che un buon strumento a due vie possa gestire questi cambiamenti, ma non ne ho mai usato uno buono (ho usato solo quelli gratuiti, però). Invece, disegno su carta o su una lavagna per aiutarmi a riordinare il design. Dopo averlo implementato e sono ragionevolmente sicuro che sia valido, farò un diagramma più formale.
Inoltre, non dimentichiamo gli altri tipi di diagrammi. Ho sempre trovato che i diagrammi di sequenza sono tra i più utili e li uso spesso quando c'è molta comunicazione tra i componenti.
Prima dell'implementazione. Come ha detto una volta uno dei miei ex colleghi, "mi piace fare più programmi possibili prima di iniziare a programmare", e penso che sia un buon approccio.
Trovo che l'atto di disegnare un diagramma di solito mi avvisi di informazioni mancanti. Questo accadrà anche se sto semplicemente digitando un editor di codice senza aver disegnato il diagramma, ma le istanze saranno distanziate tra loro (perché passerò del tempo a scrivere algoritmi e calcoli e test e simili) e quindi potrei concedere più tempo a passare prima di ottenere le mie informazioni mancanti.
Inoltre, se il disegno che hai vagamente nella tua testa risulta essere una schifezza, lo noterai più rapidamente se lo disegni prima. Quindi, perlomeno, disegno qualcosa di veloce e informale. Se si trasforma in un diagramma elettronico che altri possono usare come riferimento dipenderà dal progetto.
La creazione del diagramma di classe dovrebbe essere fatta, durante e dopo perché il modello deve essere interattivo con il codice e le modifiche dei requisiti. Per prima cosa devi creare un diagramma di classe per iniziare il tuo progetto. Aiuterebbe a visualizzare a un livello più alto di astrazione i tuoi oggetti. Sarai in grado di creare un'architettura software stabile e intelligente. Quindi è necessario codificare e talvolta si noterà che l'architettura che sembra essere in UML non è realmente possibile nel codice. Quindi modifichi il tuo codice e la tua architettura. Infine aggiorni il tuo modello con la modifica del codice e generi documentazione.
Nel mio ultimo progetto, i responsabili delle decisioni hanno cambiato le mie richieste oltre 50 volte nell'ultimo anno. È davvero doloroso e UML mi aiuta a mantenere la tracciabilità dei cambiamenti e perché. UML dovrebbe consentire la fusione di modelli e codice in qualsiasi momento in modo iterativo (ad esempio da codice a modello, da modello a codice, da entrambi, da codice dopo refactoring ecc ...) Uso Omondo EclipseUML per Helios e sono davvero contento di questo strumento. La mia caratteristica preferita è l'unione dei modelli che mi consente di aggiornare il mio modello in qualsiasi momento senza perdere le informazioni del modello. Mi piacciono anche le entità che modellano direttamente nel diagramma delle classi e creano il database usando stereotipi e ibernazione. Davvero potente e completo da oggetto a database !!
Prima : aiuterà a organizzare i tuoi pensieri e a comunicare le tue intenzioni. Non entrare nei dettagli qui.
Dopo : viene generato automaticamente dal codice come parte del processo di compilazione, ovviamente (spero tu non sia troppo attaccato a uml)
Entrambi sono utili, ma il materiale prima può essere buttato via non appena è implementato ... è già obsoleto comunque a questo punto.
Vado a votare per la risposta (C) Non disturbare.
Sono in gran parte inutili. Personalmente, non mi preoccupo mai di guardarli quando vengono forniti.
Non sono necessari prima dello sviluppo, perché il design cambierà comunque. E se non pensi che il design delle tue classi cambierà, allora ti stai già ammanettando e impedendo al tuo io futuro di essere in grado di risolvere correttamente il problema. Se pensi di dover rispettare alcuni schemi di classe preesistenti, allora lavori per la NASA o ti stai sparando ai piedi.
In seguito, sono documentazione non necessaria. Se non riesci a capire cosa stanno facendo le classi o come sono collegate tra loro con una piccola ispezione del codice, allora hai un buco nel set di abilità come sviluppatore di software.
Certo, questa risposta sembra davvero arrogante e supponente; Oh bene.
Con Eiffel e gli strumenti associati questa è solo una differenza di punto di vista che punta tutti agli stessi file sottostanti.
Leggi altre domande sui tag uml