Y3s ha scritto: > Il giorno 03/feb/08, alle ore 22:00, Domenico Chierico ha scritto: > >> On Feb 3, 2008 9:41 PM, Enrico Franchi <[EMAIL PROTECTED]> >> wrote: >> >>>> Quando lavori da solo è un po una rottura usarlo. >>> Anche quando lavoro in gruppo. Certo, se per una serie di ragione i >>> miei compari non sono in grado di leggere il codice e la >>> documentazione e hanno bisogno di rappresentazioni grafiche... ok. >>> Anche UML ha un suo senso. Viceversa preferisco del buon codice, >>> scritto bene, non più complesso del necessario e una buona suite di >>> test che mostri anche come il codice va usato e come non va usato. >>> >> e se devi definire le interfacce prima di scrivere il codice per >> parallelizare l'implementazione di alcune componenti del software ? >> >> Scrivi tutti gli stub dei moduli ? >> Riesci ad avere una visione d'insieme di una grande applicazione a >> mente ? > > Il punto è: che bisogno c'è di usare una cosa inutile e complessa > come uml? perchè non utilizzare semplicemente un linguaggio altamente > espressivo, che ha anche il vantaggio di fornirti un prototipo > eseguibile? > > >> IMHO e' solo questione del modello di sviluppo che si segue... si >> probabilmente quando si parla di Agile non c'e' proprio bisogno di >> uml, ma se cominciamo a vedere un approccio Waterfall dove chi fa >> l'analisi e' una persona diversa da chi fa il progetto che e' diversa >> dalle persone che implementano l'applicazione... allora formalizzare i >> flussi di informazioni fra tutte queste persone potrebbe avere un >> senso... dato che il codice si scrive alla fine >> > > Waterfall? Gli anni '80 sono passati da un po' eh ;-) > Comunque, nessuno nega che la formalizzazione dei flussi di > informazioni tra persone diverse dello stesso team o tra team diversi > sia necessaria, ma io (e penso altri) non capisco perchè uml. Non > capisco i vantaggi di uml rispetto a un altro linguaggio più > espressivo. Probabilmente perchè avere un diagramma fa più fico nelle > riunioni? >
Pensa che ho avuto una discussione simile nell'ambito SQL su cosa fosse meglio usare: un diagramma E/R o del semplice codice pseudo SQL. La mia tesi a favore del codice SQL era la facilità di modifica e versionamento (specialmente se condiviso) mentre un diagramma grafico è una rottura da gestire. La sua tesi era che non si deve scrivere codice nella fase di design (ok, ma un diagramma E/R non è codice?). Manlio Perillo _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python