Quanta modellazione UML dovresti fare?
Ho usato la modellazione UML un paio di volte in circa un decennio fa e mi sto riprendendo con essa. Ho scoperto che chiarisce il design di un'applicazione che si traduce in un'implementazione più rapida e semplice. Allora ho trovato UML diretto e semplice, ma è diventato molto più complesso, coprendo più tipi di modellazione insieme a un vocabolario più ampio rispetto a quando l'ho usato l'ultima volta.
Anche se ci sto ancora pensando, sembra che le nuove aggiunte a UML siano semplicemente modi diversi di catturare lo stesso design. Sembrano anche passare da una modellazione di alto livello a una di basso livello, offuscando i confini tra progettazione e implementazione.
Supponendo che tu stia progettando un'applicazione abbastanza complessa come Adobe Illustrator, ad esempio, quanto dei diversi tipi di modellazione dovrebbe esercitare il tuo design? Sono alla carta dove scegli ciò che ha senso per il tuo design, o è un pasto completo di 7 portate in cui il tuo design trae il massimo vantaggio dall'utilizzo di tutto ciò? Se è al la carte, come determini quali tipi di modellazione coprono ciò di cui hai bisogno?
Risposte
UML copre infatti un insieme molto ampio di esigenze di modellazione, dai progetti più elementari, alla codifica quasi visiva, soprattutto se si considerano standard vicini come OCL . Se tutte queste cose sono state prese in considerazione, immagino non sia per divertimento, ma perché i membri del comitato che rappresentano gli interessi della loro azienda ci hanno lavorato duramente perché c'è un reale bisogno.
Quindi non esiste una risposta univoca su quanto UML sia il livello giusto:
- Immagino che se stai progettando un software per una centrale nucleare o un nuovo jet da combattimento, è certamente un livello di complessità che richiede molta progettazione, molta verifica del modello e forse anche verifica automatizzata di precondizioni, postcondizioni e invarianti documentato nei vincoli.
- Se stai lavorando su un prodotto software di grandi dimensioni che coinvolge diversi team agili, potresti non essere affatto interessato alla convalida anticipata e alla documentazione estrema. Ma forse alcuni diagrammi dei componenti per discutere o comprendere il quadro più ampio possono aiutare i team a cooperare. Forse su scala ridotta, alcuni diagrammi di classe e diagrammi di sequenza possono aiutare a discutere la struttura e le dinamiche di ciò che stai per codificare nella versione corrente.
- Forse qualche diagramma può aiutarti a esprimere molto bene le cose che sembravano piuttosto malvagie nella tua mente, come ad esempio un diagramma di stato. Forse anche una combinazione di UML con nuove pratiche, come il caso d'uso 2.0, può aiutarti a lavorare in modo iterativo e incrementale sui requisiti, lavorando in modo agile ma fornendoti comunque alcuni semplici diagrammi dei casi d'uso come sottoprodotto che potrebbero aiutarti a tenere traccia delle caratteristiche correlate e facilitare successivamente test di non regressione e lavori di manutenzione.
La risposta, come ha sottolineato Erik sono da ricercare dalla tua parte, in base alle tue reali esigenze. Tuttavia, si possono fare un paio di raccomandazioni per guidarti:
- Non è una buona idea usare UML come linguaggio di programmazione visuale . Non è mai stato questo l'intento. Il codice è meglio espresso nel codice. I diagrammi sono più per le idee generali che portano a quel codice.
- Quanto più dettagliati sono i tuoi diagrammi, tanto più dispendioso in termini di tempo e difficile sarà mantenerli . Per i diagrammi delle classi, tendo ad esempio a mostrare solo le classi e alcune caratteristiche chiave; mai tutti i dettagli. Queste caratteristiche chiave che rendono il design raramente cambiano. Ma tutti gli attributi e le operazioni rimanenti molto spesso si evolvono molto rapidamente, soprattutto nelle fasi iniziali, rendendo istantaneamente obsoleti tutti i diagrammi dettagliati.
- I diagrammi dettagliati hanno senso solo se si dispone di uno strumento per generare UML automaticamente dal codice .
- Più funzioni UML avanzate vengono utilizzate, più dettagli di progettazione saranno fraintesi (o non compresi affatto) dai colleghi sviluppatori: non tutti possono dedicare abbastanza tempo a comprendere tutta la sua sottile semantica, e poiché UML non è né compilabile né eseguibile, non non c'è modo di verificare di aver compreso correttamente ciò che dicevano le specifiche UML 2.5.1.
- L'osservazione precedente è rafforzata dal fatto che alcuni fondatori di UML a volte sognano un'edizione "Essenziale" semplificata che si limiti ai concetti fondamentali necessari nell'80% dei casi (basta seguire Ivar Jacobson e Graddy Booch abbastanza a lungo su Twitter per catturare qua e là alcuni di questi pensieri).
- Infine, per modellare l'architettura, UML, sebbene sia molto completo, si è rivelato molto complesso da usare: poiché il linguaggio è molto preciso, è necessario elaborare molti più dettagli della tua architettura prima di poterla modellare correttamente in UML, separando la struttura del codice, dalla distribuzione in fase di esecuzione. Questo è il motivo per cui le tecniche di modellazione alternative prendono piede (ad esempio il modello C4 , che consente con pochissimi simboli grafici, di elaborare rapidamente su un cartone un'architettura di alto livello, e di rimandare i perfezionamenti e i dettagli a quando sono necessari (e in UML se necessario aiuta)).
Per prima cosa devi capire perché stai creando un documento di progettazione di qualsiasi tipo. I motivi principali per me sono:
- Suddividi il problema in blocchi gestibili
- Comunicare le idee di design agli altri
- Esperimenti mentali su diversi design
Una volta che hai obiettivi chiari, puoi iniziare a rispondere alle domande più dettagliate che poni, come quanti dettagli sono troppi, UML è adatto, quale insieme di forme userò ecc.
Penso che scoprirai che hai bisogno di più di un tipo di diagramma per diverse parti del sistema e per diversi tipi di pubblico. Assicurati di scegliere bei colori e fallo apparire bene sulle diapositive!