Paolovox ha scritto:
In pratica sarebbe l'equivalente nel settore ingegneristico al progetto e al calcolo strutturale che descrive dalla raccolta dei requisiti e lo studio di fattibilità, al processo di sviluppo complessivo del sistema e tutti gli artefatti da produrre, tenendo conto dei rischi e stimando il costo monetario, di risorse umane e hardware.
Mannoooo... Semplicemente sono pittogrammi, disegnini assolutamente inutili in situazioni concrete e complesse.
Hai presente i diagrammi di flusso? Nessuno sano di mente riterrebbe che siano utili a qualcosa (se non a modellare che so le modalità di disdetta degli abbonamenti Sky).
UML (e formalisimi simili) soffrono dei medesimi problemi, ovvero
- diventano giganteschi. Chi sa cosa fa un diagramma UML che ricopre un campo da calcio? nessuno
- "nascondono" mille e mille sottogliezze che sono insite nel problema (e nella soluzione) di cui non v'è traccia nei pittogrammi UML
Poi l'UML a quanto sto capendo studiando è una sorta di framework che permette di descrivere tutti questi aspetti, utilizzando specifici diagrammi (casi d'uso, attività, classi, architettura, ...), cosicchè il coding diventa quasi l'ultimo problema dato che sarebbe una pseudo traduzione del diagramma delle classi e forse, forse spetta al programmatore decidere quale miglior algoritmo utilizzare (vittima del dispotismo aziendale).
Seeeeee... questa è la robaccia che viene insegnata oggi, da chi, spesso, non ha mai lavorato in una industria del software.
PRO: per progetti distribuiti e complessi è impensabile non utilizzare un modello di processo software (RUP preferibilmente, Agile), che pianifichi il tutto con un bel diagramma di Gantt e tutti i diagrammi UML con tutta la documentazione necessaria.
Ma va là (in breve)
CONS: la figura professionale dell'analista e ing. del software è davvero difficile in primis perchè per quanto un esperto di dominio possa istruirli circa il frammento di mondo nel quale lavorerà il sistema e sulle esigenze da soddisfare badando ai vincoli, penso che debbano ogni volta farsi una cultura in base al sistema da sviluppare (medicina, finanza, trasporti, .......................).
L'ingegnere del software, al massimo, può progettare i tortellini
Mi è stato detto sull'utilizzo dell'UML per le basi di dati che è più ridondante e meno coinciso rispetto l'ER (antenato UML); che nell'ambito della progettazione di database permette di formalizzare meglio, risolvendo qualsiasi ambiguità (piccolo bug dell'UML che stanno risolvendo).
Ma va là squared
Bon, mica dovete "fidarvi" di me (anche se il mio consiglio principale è: segui i miei consigli )
Appena lavorerete ad un progetto diverso dalle 4 cazzatelle accademiche, o del programmello di 10.000 righe per il fornaio, vedrete che "magicamente" i diagrammi UML serviranno per prendere appunti (sul retro dei fogli, intendo, per riciclarli).
Mentre i "fantastici" ER, che servono a poco o a nulla, soprattutto se si usano CASE che hanno la cattiva idea di creare diagrammi del tutto incomprensibili e giungle di vincoli di integrità referenziali praticamente impossibili da districare anche per gente come me che sviluppa db da decenni, una sia pur vaga utilità la mantengono.
Nota a margine: per i database (relazionali, è bene precisarlo) si adottano da decenni e decenni strumenti e tecniche ormai consolidati, perchè l'ambito è assai più specifico rispetto al mondo "universalista" di UML, in particolare combo case-framework.
Mentre E' possibile da un diagramma ER ottenere un (passabile) database con strumenti automatici, ovviamente da rifinire e sistemare "a mano", ciò non accade affatto con UML.
In una, anzi due parole:
snake oil