Newsgroup: it.comp.java
Titolo: UML & progetti

Ciao a tutti,
vorrei chiedere opinioni su UML.
Ho letto alcuni articoli riguardo questo linguaggio di modellazione.
Non l'ho mai impiegato in alcun progetto, ne' utilizzato alcun tool di 
modellazione.
Purtroppo sono sempre incerto nel voler dedicare parecchie ore per 
modellizzare un problema con questo linguaggio.
Per questo vorrei alcune opinioni.
-Quando vale la pena di usarlo ? In progetti per cui si prevede un alto 
grado di manutenzione/estensione in futuro ?
-Qualche mese fa ho guardato ArgoUML (ed anche la versione commerciale 
Poseidon). Qualcuno di voi ha avuto esperienze con questi due strumenti?
-Per lo sviluppo uso eclipse (e mi trovo benissimo). Ho letto 
dell'esistenza di alcuni plugin UML. Sono ad un livello di maturita' per 
cui valga la pena di provarli?
Grazie in anticipo,
Nicola

UML può rappresentare vari diagrammi di modellazione, tutti
sostanzialmente indipendenti fra loro. L'unico che (in pratica) è
vicino alla scrittura del codice è il diagramma delle classi, da cui
di solito i tools ti consentono di generare i sorgenti.
Il tuo dubbio è sicuramente legittimo. A mio modesto avviso, il
diagramma delle classi è utile sempre nella fase in cui progetti le
classi. Gli altri diagrammi servono a rappresentare in varie salse la
comprensione del dominio, è utile nei progetti complessi per arrivare
alla progettazione delle classi e della UI, possono essere
indispensabili per comunicare l'analisi fra collaboratori. Se però il
dominio non è complesso e la progettazione delle classi ti è chiara,
si tratta di lavoro abbastanza inutile. UML non è un linguaggio per
documentare il progetto, in fase di manutenzione difficilmente sarà
utile.

 utile.
Direi invece che in fase di manutenzione può essere la base di partenza
per il refactoring del codice; cìò porterebbe a nuovi diagrammi UML e,
credo, ad una corretta gestione di codice e documentazione.
Certo la strada per utilizzare UML è lunga e tortuosa soprattutto perchè 
richiede un cambio di mentalità che non tutti sono disposti ad accettare.
Io comincerei a dare un'occhiata a 
www.extremeprogramming.it
Saluti a tutti
Enzo.

 degli oggetti.
Non ho detto che il diagramma delle classi è la progettazione del
software nella sua interezza. Ho detto che è la fase più vicina alla
scrittura del codice.
E comunque non sono d'accordo che il diagramma di classi ti costringa
ad un paradigma non ad oggetti. IMHO è vero che la logica ad oggetti
la si rappresenta meglio con i diagrammi opportuni, ma essendo il
diagramma delle classi una mera rappresentazione del codice dipende da
come lo realizzi. Certo non ti rappresenta cose che non può
rappresentare, ma a quel punto nemmeno il codice lo fa.

 rappresentare, ma a quel punto nemmeno il codice lo fa.
Per pura statistica,
-) vi e' mai capitato che per un progetto di una certa dimensione , almeno 6
mesi con almeno 10 persone coinvolte, qualcuno facesse il diagramma delle
classi PRIMA del codice ?
-) se si chi lo faceva ? i singoli programmatori , o un Architect lo faceva
per tutti gli altri ?
 ciao Nicola
 
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

classi PRIMA del codice ?
Si... assolutamente SI !!!
E non solo quelloo delle classi, quando servono anche i collaboration
diagram (seconodo me questi ultimi sono usati troppo poco)
Nell'azienda per cui lavoro si opera solo in questo modo.
-) se si chi lo faceva ? i singoli programmatori , o un Architect lo
faceva
per tutti gli altri ? 
Più Architect lo fanno per tutti gli altri


QUindi se io sono un coder mi arriva gia' la firma delle classi e faccio
solo l'algoritmo.
Credo che non accetterei mai di lavorare a queste condizioni.
Vorrei anche vedere un confronto di costi fra fare un progetto in questo
modo e
e fare lo stesso progetto in modo + tradizionale ( come fanno il 99% dei
progetti )
Io credo che l'Architect una volta che ha fatto la firma del metodo puo'
direttamente programmare la classe visto che e' il minore dei tempi.
Mentre deve andare a spiegare la cosa al developer in pratica raddoppiando
tempi costi e possibilita' di errore visto che magari il coder capisce male
Ciao Nicola


 direttamente programmare la classe visto che e' il minore dei tempi.
č come dire che l'ingegnere una volta disegnato il progetto di una casa si 
mette poi lui a trafficare con cemento e mattoni
puņ farlo per una casa piccola... ma per costruzioni grandi ci sono sempre 
gli sviluppatori che scrivono il codice mentre l'architetto disegna 

Credo che non accetterei mai di lavorare a queste condizioni.
Che titolo di studio hai ? Quanti anni di esperienza hai ? :)

 Che titolo di studio hai ? Quanti anni di esperienza hai ? :)
Sono ingegnere con 8 anni di esperienza.
Forse non avendo mai lavorato con questa metolodogia me la immagino peggiore
di quanto non sia.
Comunque credo che nel mondo non la usa quasi nesssno.
Io seguo altre scuole, Extreme Programming come riferimento, magari un po'
meno extreme, ma su quel genere.
Prendiamo 5 Architect senior che progettano/realizzano lo stesso progetto di
2 Architect che danno in giro in giro firme UML a 10 coder junior
La prima squadra secondo me massacrano la seconda e il progetto lo fanno
prima, meglio e a costo inferiore.


2 Architect che danno in giro in giro firme UML a 10 coder junior
Si certo se mi ci metto io lo faccio meglio che 3 ragazzi neolaureati e
ci metto pure meno (modestia a parte) :)
Però non si possono sempre avere 5 persone con 8 anni di esperienza...
E' una questione di trovare le persone giuste (e non è facile), di
pagarle il dovuto (ancor meno facile) etc. etc.
Considera anche un altro aspetto: un modello che architetti e
sviluppatori consente facilmente di delocalizzare lo sviluppo.

 
Ciao,
Mi potreste dire che strumenti usate per l'architettura? Sempre e solo 
diagrammi UML (che tipo?) o qualcos'altro di contorno (che sò, una 
qualche descrizione standardizzata o cose del genere); dovrei iniziare a 
far fare delle cose che solitamente facevo da solo ad un nuovo 
programmatore, per cui mi servirebbe qualcosa di più trasmissibile 
(quando ero da solo, non stavo a disegnarmi n schemi per poi dire a me 
stesso 'devi fare così')
Avete anche da consigliarmi un qualche libro/url sull'argomento?
grazie!
DKano

 sviluppatori consente facilmente di delocalizzare lo sviluppo.
e altrettanto facilmente di progettare una pila di cacca!
Gli architetti *devono* scrivere il codice, se non lo fanno molto
probabilmente è perchè non sono capaci o perchè la loro azienda è legata a
modelli antiquati e sbugiardati come il waterfall (chi ha seguito Craig
Larman quest'anno alla Java Conference ha un'ottima panoramica storica di
come è nato e perchè non ha mai funzionato).
Anche nei metodi più classici gli architetti partecipano personalmente
alla stesura del codice nelle prime iterazioni, abbandonando man mano
l'attività. Nei metodi agili gli architetti comunenemente intesi invece
non ci sono proprio...
BTW, il paragone con l'edilizia continua purtroppo a creare danni
inenarrabili: quando ce ne libereremo?
uL (Senior Architect :) )
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 uL (Senior Architect :) )
Nicola ( Senior Architect :) e non ho mai smesso un solo progetto di
pogrammare :) l'UML mi piace molto farlo reverse a prodotto finito hehe )


inenarrabili: quando ce ne libereremo?
Ce ne libereremo solamente quando il software avrà la stessa
affidabilità di un prodotto dell'edilizia, oppure di un'automobile.

 affidabilità di un prodotto dell'edilizia, oppure di un'automobile.
Cioè, mai (per il palazzo, l'automobile sta invece diventando sempre più
simile ad un sw, invece). BTW, il sw non può avere la stessa affidabilità
di un prodotto dell'edilizia, perchè per quest'ultimo i requisiti sono
stabili, per il sw no. E' una cosa che si predica ormai da 40 anni, ma
molti sono ancora alla ricerca di questo sacro graal che magicamente
porterà il sw ad essere come un palazzo. E' per questo che bisogna
eliminare questa analogia sbagliata... 
uL


 pogrammare :) l'UML mi piace molto farlo reverse a prodotto finito hehe )
Io fino al 1998 ero innamorato di UML ed affini, sono partito anni prima
con OMT, Coad-Yourdon e OOSE. Ora lo uso quando serve, per documentare,
per fare statement of work, qualche volta per fare chiarezza su cose
particolarmente complicate. Ma ne guarderei bene dal darlo in pasto a dei
poveri programmatori, peggio se non parlano la mia lingua, peggio su
peggio se in un altro fuso orario
Comunque ognuno deve scottarsi da solo e intraprendere il proprio cammino!
uL


 DKano
The Pragmatic programmer
ciao


 eliminare questa analogia sbagliata... 
Un attimo :-), l'analogia palazzo/software è certamente sbagliata in 
partenza perché una cosa è un'architettura immobile (palazzo) e un'altra 
una mobile e dinamica (software), ma sicuramente con questo non vorremo 
giustificare l'esistenza dei bug come inevitabile!...
Posto che anch'io sono per le tecniche di agile development, il TDD 
(Test Driven Development) mi sembra uno dei migliori approcci oggi 
disponibili, anche se a mio modestissimo parere delle linee guida 
generali in un progetto ci devono essere. In genere io mi limito a 
design di alto/altissimo livello durante la progettazione iniziale, i 
dettagli poi vengono a galla via via durante lo sviluppo.
pole
-- 
ammentos - a lightweight persistence framework for JDK5
http://www.sourceforge.net/projects/ammentos
http://ammentos.biobytes.it

 giustificare l'esistenza dei bug come inevitabile!...
no di certo, intendevo solo che la soluzione non va cercata continuando
l'analogia, che è errata. Il PM classico di un progetto software, in cui
in fondo rientra UP e di conseguenza anche l'uso tipico che si fa di UML,
si basa invece su ragionamenti molto simili a quelli del palazzo!
Tutto qua, non era una giustificazione ai bug... ;)


 Tutto qua, non era una giustificazione ai bug... ;)
Ne ero certo ;)


 generali in un progetto ci devono essere.
Ci mancherebbe altro.
Se riguardi bene indietro qua nessuno ha detto che non si progetta piů.
Assolutamente si progetta e tanto !!.
L'argomento del dibattito e' il idagramma delle classi UML , che se fatto in
fase di Progetto, di fatto porta il/i Progettisti a scrivere le firme dei
metodi delle classi.
A quel punto in teoria si potrebbe dare le firme ai developer, magari
delocalizzati.
Io ho espresso forti riserve su un approccio di questo tipo, di cui si parla
molto, ma poi sul campo non lo ho mai visto applicare, e credo che se mi
arrivassero a me le firme quando programmo avrei grossi problemi. Se
viceversa sono io che progetto le classi, e scrivo le firme, di fatto il
passaggio e' breve e ci butto dentro pure il codice.
Considera che una mia classe di solito si aggira sulle 500 righe.
Togli i javadoc, togli le firme che metto con un parametro per riga, togli 2
commenti qua e la ,non so neanche se arrivo a 50 righe di codice
Direi che in un'ora scarsa chiudo la classe , pittosot che perdere molto piů
di un'ora a spiegare le mie idee malate a un collega, magari in Tibet in uno
splendido villaggio ai piedi delle grandi montagne.
Preferisco una progettazione piu' complessiva , e una suddivisione in unita'
piu' indipendenti e coese. A quel punto ogni singolo developer, architect o
meno, puo' sviluppare come piu' lo aggrada, tanto la qualita' e' garantita a
monte.
Se un giorno una unita' di N classi e' una porcheria si butta e si rifa' da
capo. Il buon progetto non ne risentira'.
Ciao Nicola


 Se riguardi bene indietro qua nessuno ha detto che non si progetta più.
Chiedo venia, ammetto di non aver seguito tutto il thread dall'inizio :P
 > Io ho espresso forti riserve su un approccio di questo tipo, di cui 
si > parla molto, ma poi sul campo non lo ho mai visto applicare, e credo
 > che se mi arrivassero a me le firme quando programmo avrei grossi
 > problemi. Se viceversa sono io che progetto le classi, e scrivo le
 > firme, di fatto il passaggio e' breve e ci butto dentro pure il
 > codice.
Perfettamente d'accordo. Qualche firma magari la si può ammettere in 
fase di design in quelle interfacce che rappresentano i punti di 
contatto (o di "snodo" come mi piace chiamarle) tra le unità di codice. 
Così si riesce anche a compilare pur lavorando in team separati :)
Ciao!
