Dovresti creare diagrammi di classe prima o dopo l'implementazione?

A mio modo di vedere se ne crei uno prima di ottenere il vantaggio di:

• Pianificare in anticipo
• Panoramica del progetto

ma perdi:

• Tempo (facendo il lavoro probabilmente finirai per ripetere quando scrivi il codice)

D'altra parte, potrei semplicemente crearli tutti dopo aver scritto il mio codice solo per tenerlo come riferimento per i futuri sviluppatori.

Quale serve allo scopo dei diagrammi di classe e quale è più vantaggioso?

Se le crei prima, faranno parte della fase di progettazione.

Se li crei dopo, puoi semplicemente usarli per la documentazione. Documentare è meglio e più veloce se lo fai durante la progettazione e la codifica.

A proposito, non perdi tempo a progettare! La parte di codifica sarà più veloce. E meglio

Dopotutto, pensi che progettare un grattacielo o un ponte sia una perdita di tempo invece di iniziare a costruirlo?

Un compromesso è iniziare a creare del codice fittizio durante la fase di progettazione (solo prototipi di classi / funzioni) e utilizzare questo scheletro di codice per costruire i diagrammi di classe.

Quando li ho creati prima della codifica, li vediamo come documenti "temporanei". Cioè, creiamo i diagrammi e mettiamo i nostri pensieri sulla carta. Iniziamo a programmare da quei diagrammi di classe. Li buttiamo fuori. Non vale la pena dedicare del tempo per mantenerli una volta iniziata la codifica. E se desideri modelli di classe aggiornati, utilizza uno strumento per crearli dal codice.

In entrambi i casi rimarranno come parte della documentazione. Nessuno li aggiornerà quando vengono apportate modifiche all'implementazione. I diagrammi non avranno date su di essi, quindi non saprai nemmeno a quale versione del codice si riferiscono. Quando una nuova persona viene aggiunta al progetto, gli darai i diagrammi che dicono "Ecco alcuni diagrammi che sono stati creati ad un certo punto durante la progettazione o l'implementazione. Non sappiamo quanto siano aggiornati."

Questo fa parte della progettazione e quindi dovrebbe essere creato prima dell'implementazione. Ciò non significa che non possano essere perfezionati durante / dopo l'implementazione per riflettere lo stato attuale delle implementazioni.

Fornire un progetto dopo l'implementazione è ciò che definirei "codifica da cowboy" e sicuro che puoi prosperare nel selvaggio west selvaggio, ma ricorda che i cowboy di solito finiscono morti in un punto o nell'altro.

Dipende dalla profondità del design. Alcune persone insistono nel scrivere diagrammi di classe anche per le classi più banali, perché "è una buona pratica". Penso che sia una perdita di tempo disegnare qualcosa quando sai già esattamente come verrà implementato. Quando si crea un nuovo design, qualcosa che non è familiare, è sicuramente utile disegnare prima alcuni diagrammi.

Non uso mai gli strumenti UML, perché di solito il design cambia così tanto durante l'implementazione che devo ridisegnare il diagramma. Suppongo che un buon strumento a due vie gestisca questi cambiamenti, ma non ne ho mai usato uno buono (ho usato solo quelli gratuiti). Invece, disegno su carta o su una lavagna per aiutarmi a riordinare il design. Dopo averlo implementato e sono ragionevolmente sicuro che sia corretto, farò un diagramma più formale.

Inoltre, non dimentichiamo gli altri tipi di diagrammi. Ho sempre trovato i diagrammi di sequenza 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 quanta più programmazione possibile prima di iniziare a scrivere codice" e penso che sia un buon approccio.

Trovo che l'atto di disegnare un diagramma di solito mi avvisa della mancanza di informazioni. Questo accadrà anche se sto solo digitando un editor di codice senza aver disegnato il diagramma, ma le istanze saranno distanziate ulteriormente (perché passerò il tempo a scrivere algoritmi, calcoli, test e simili) e quindi potrei concedere più tempo a passare prima di ottenere le informazioni mancanti.

Inoltre, se il disegno che hai vagamente nella tua testa risulta essere una merda, lo noterai più rapidamente se lo diagrammi per primo. Perciò almeno disegno qualcosa di veloce e informale. Se si trasforma in uno schema elettronico che altri possono usare come riferimento dipenderà dal progetto.

La creazione del diagramma di classe deve essere eseguita durante e dopo perché il modello deve essere interattivo con le modifiche al codice e ai requisiti. Per prima cosa devi creare un diagramma di classe per iniziare il tuo progetto. Aiuterebbe a visualizzare ad un livello superiore di astrazione i tuoi oggetti. Sarai in grado di creare un'architettura software stabile e intelligente. Quindi devi codificare e a volte noterai che l'architettura che sembra funzionare bene in UML non è davvero possibile nel codice. Quindi si modifica il codice e l'architettura. Infine aggiorni il tuo modello con la modifica del codice e generi la documentazione.

Nel mio ultimo progetto i decisori hanno cambiato le mie esigenze più di 50 volte nell'ultimo anno. È davvero doloroso e UML mi aiuta a mantenere la tracciabilità dei cambiamenti e perché. UML dovrebbe consentire la fusione tra modello e codice in qualsiasi momento in modo iterativo (ad es. 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 funzione preferita è l'unione del modello che mi consente di aggiornare il mio modello in qualsiasi momento senza perdere le informazioni sul modello. Mi piacciono anche le entità che modellano direttamente nel diagramma di classe e creare il database usando stereotipo e ibernazione. Davvero potente e completo da oggetto a database !!

Prima : ti aiuterà a organizzare e comunicare i tuoi pensieri. Non entrare nei dettagli qui.

Dopo : viene generato automaticamente dal codice come parte del processo di compilazione, ovviamente (spero che tu non sia troppo attaccato a uml)

Entrambi sono utili, ma le cose precedenti possono essere gettate via non appena vengono implementate ... è già obsoleto comunque a questo punto.

Con Topcased , creo i miei diagrammi di classe durante la fase di progettazione. Quindi faccio clic sul pulsante "Genera codice" per produrre un canvas della mia implementazione. Quindi inserisco i segnaposto con il codice.

Vado a votare la risposta (C) Non preoccuparti.

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 lezioni cambierà, allora stai già ammanettando te stesso e impedendo al tuo sé futuro di essere in grado di risolvere correttamente il problema. Se pensi di dover attenersi ad alcuni diagrammi di classe preesistenti, allora lavori per la NASA o ti stai sparando ai piedi.

Successivamente, sono documentazione non necessaria. Se non riesci a capire cosa stanno facendo le lezioni o come sono correlate tra loro con una piccola ispezione del codice, allora hai un buco nel tuo set di abilità come sviluppatore di software.

Naturalmente, 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.