UML ha una jungle di diagrammi.
Diagrammi dei profili, diagrammi delle classi, diagrammi dei pacchetti ...
Tuttavia, (IMH-e-non-troppo-esperto-O) vedo abbastanza che fare ogni schema è eccessivo.
Pertanto, quali diagrammi UML sono più adatti in un contesto web, più specificamente un blog (vogliamo costruirlo da zero).
Capisco che solo perché ho usato UML Diagrams non implica che il nostro codice sarebbe fantastico e geniale ... ma sicuramente sarebbe meglio del codice non pianificato ...
Come linea guida generale:
Alcuni tipi di diagrammi (ad esempio il diagramma temporale) hanno usi piuttosto specializzati, altri tendono verso un livello di dettaglio in cui il codice effettivo svolge un lavoro migliore (ad esempio i diagrammi di sequenza), e altri ancora sembrano destinati a progetti giganteschi ma hanno un'utilità discutibile anche lì (diagrammi dei pacchetti? Qualsiasi IDE può mostrarti i tuoi pacchetti).
Il diagramma è meno importante delle conversazioni che hai quando comunichi i concetti tra i vari stakeholder in un progetto. Dopo anni di sviluppo del software, mi sono ritrovato a cercare di catturare le informazioni in modo schematico anche meno negli ultimi anni rispetto a quando ero all'inizio. Oggigiorno, potrei elaborare alcuni semplici casi d'uso su una lavagna quando discuto dei concetti, e farò spesso ricorso a un diagramma di flusso semplice ma classico se sto cercando di capire come un cliente vuole che un sistema funzioni. Se sono particolarmente preoccupato, userò la fotocamera del mio telefono per acquisire l'immagine sulla lavagna per aiutarmi a ricordare cose specifiche.
Il design up-front strongmente documentato non è molto snello. Scoraggia il cambiamento e fissa il tuo pensiero attorno a un singolo piano di attacco che potrebbe finire nel torto per il progetto nel suo complesso. Desiderate essere in grado di rinviare quanto più possibile il vostro disegno all'ultimo minuto, al fine di ridurre le possibilità che un grande cambiamento rovinerà i vostri progetti e programmi in seguito. Questo non vuol dire che UML non dovrebbe essere usato, ma piuttosto che dovrebbe essere usato con parsimonia, come mezzo per migliorare la comunicazione di concetti, e non come mezzo per definire i sistemi che si intende costruire.
UML è stato progettato come linguaggio di comunicazione tra le persone coinvolte. (programmatori-programmatori, programmatori-uomini d'affari, uomini d'affari-utenti) Le persone esprimono i loro modelli mentali in un linguaggio semplice e unitario che tutti comprendono.
Devi chiederti di quante comunicazioni hai bisogno.
Una regola empirica è fare i diagrammi di alto livello per darti panoramica e passare del tempo su cose complicate o non così comuni. Scrivere / disegnare il tuo modello mentale in UML ti costringe a comprenderlo pienamente e a risolvere molti bug prima di scrivere una singola riga di codice.
A parte alcuni diagrammi di grandi dimensioni che verranno utilizzati per comunicare l'architettura generale della tua applicazione in termini di server, layer o grandi moduli, non penso che tu possa prevedere quali diagrammi avrai bisogno in anticipo.
Attendi fino all'ultimo momento responsabile. Vedrai quando ne avrai bisogno . Di solito è
Ad ogni modo, i tuoi modelli diventeranno probabilmente obsoleti non appena avrai scritto alcune righe di codice o ottenuto un primo feedback da parte dei clienti, quindi non preoccuparti di pianificare tutto in anticipo o di lucidare così tanto i tuoi diagrammi.
Serve tutto il necessario per comprendere e comunicare il sistema. Per il software di blogging, non penserei che ne abbiate bisogno di molti. Modella tanto quanto è necessario per capire il sistema. Smetti di modellare quando smette di aggiungere la tua comprensione.
Se sei nuovo di UML potresti voler fare alcuni diagrammi in dettaglio per aumentare la tua comprensione dei diagrammi. Una volta compreso un tipo di diagramma abbastanza bene da poterlo fare nella tua mente, la necessità di diagrammi effettivi diminuisce.
Se esci con le versioni del diagramma, ti aiuterà a giudicare se è probabile che siano attuali. Confrontare il design attuale con i diagrammi più vecchi può essere utile per determinare quali aree del progetto variano in modo significativo rispetto al progetto originale.
A meno che non si stiano utilizzando strumenti che generano il codice dai diagrammi o incorporino le specifiche del diagramma nel codice, è probabile che non si sincronizzino con il codice. Gli schemi dettagliati tenderanno a diventare significativamente più scorretti nel tempo. che diagramma di panoramica. I diagrammi della panoramica richiederanno anche meno manutenzione per mantenerli aggiornati.
Potresti trovare utile generare diagrammi che:
Generare diagrammi utili nella pianificazione del progetto. Se un diagramma non è necessario per capire e / o comunicare qualcosa sul progetto, non perdere tempo con esso. Sentiti libero di usare un diagramma non UML se aiuta a capire. UML potrebbe non essere il modo migliore per modellare il database.
Direi che è necessario adattare i diagrammi UML al livello di modellazione di tutte le parti interessate e al tempo necessario per completare il progetto.
Se il team non conosce UML e non ha tempo, è possibile solo il diagramma di classe derivante dal codice invertito. Ogni membro può aggiungere i suoi commenti nel diagramma delle classi che è già una buona soluzione per la documentazione. In questo caso il modello è solo una vista grafica del codice. Ciò coprirebbe quasi il 90% delle esigenze di modellazione se fatto con attenzione e non aggiungerà altro tempo al progetto.
Se disponi di conoscenze avanzate degli stakeholder, tutti i diagrammi potrebbero apportare un reale valore al progetto al fine di coprire le esigenze di un progetto di modellazione completo. Ciò potrebbe aggiungere un tempo significativo alla consegna del progetto, ma la qualità della consegna dovrebbe essere migliore.
UML è bello, brillante e può essere adattato a qualsiasi progetto se usato con moderazione. Non bere e guidare, ad esempio, allo stesso tempo: -)
Leggi altre domande sui tag design web-development uml